1. 같은 AI를 누구는 잘 쓰고, 누구는 못 쓰는 이유

ChatGPT가 처음 나왔을 때, "마케팅 이메일 써줘"라고 입력하면 누구나 비슷한 답을 받았습니다. 그런데 어느 순간부터 같은 도구를 두고도 결과 차이가 크게 벌어지기 시작했습니다. 어떤 사람은 ChatGPT에게 한 번에 쓸 만한 보고서를 받고, 어떤 사람은 매번 평범한 답만 받습니다. 똑같은 모델, 똑같은 화면, 똑같은 입력창인데 왜 차이가 날까요.

이 차이를 설명하기 위해 업계는 새로운 용어들을 만들어 냈습니다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링입니다. 단어가 어렵게 들리지만, 풀어 쓰면 각각 "질문을 잘하는 법", "정보를 잘 챙겨주는 법", "AI가 일할 환경을 잘 꾸리는 법"입니다. 이 세 가지는 ChatGPT가 등장한 2022년부터 지금까지 약 3년에 걸쳐 차례로 등장한 개념이고, 지금은 셋이 함께 작동합니다. 그리고 2026년 중반에 네 번째 용어인 루프 엔지니어링("AI가 스스로 반복하게 만드는 법")이 그 위에 얹혔습니다. 이 장에서는 앞의 세 가지를 차례로 보고, 마지막에 네 번째를 짧게 소개합니다.

세 가지를 가장 짧게 비교하면 이렇습니다.

여기서 가장 중요한 것은 셋이 대체 관계가 아니라 포함 관계라는 점입니다. 새 단어가 나왔다고 이전 단어가 폐기되는 것이 아닙니다. 큰 그릇이 작은 그릇을 품는 식으로, 하네스가 컨텍스트를 품고, 컨텍스트가 프롬프트를 품습니다.

2. 왜 이런 진화가 일어났는가

세대가 바뀐 이유는 단순합니다. 매번 다른 것이 발목을 잡았기 때문입니다.

처음에는 모델 자체가 똑똑하지 않았습니다. 같은 질문을 해도 엉뚱한 답이 자주 나왔기 때문에, 어떻게든 질문을 잘 다듬어서 답을 끌어내야 했습니다. 이것이 프롬프트 엔지니어링이 처음 주목받은 이유입니다.

모델이 빠르게 똑똑해지면서 문제가 옮겨갔습니다. 모델은 충분히 답할 능력이 있는데, 우리 회사 약관, 우리 코드, 어제 발표된 자료 같은 자기만의 정보가 모델 머릿속에 없으니 좋은 답이 나오지 않았습니다. 그래서 모델 옆에 필요한 정보를 골라서 같이 넣어주는 작업, 즉 컨텍스트 엔지니어링이 중요해졌습니다.

지금은 또 다른 단계입니다. 모델이 단순 답변에서 그치지 않고 코드를 짜고, 도구를 호출하고, 여러 단계의 작업을 자율적으로 수행하기 시작했습니다. 이 단계에서는 모델에게 어떤 도구를 쥐어줄지, 어디까지 허용할지, 실수했을 때 어떻게 되돌아오게 할지까지 미리 설계해야 합니다. 이 전체 환경 설계가 하네스 엔지니어링입니다.

3. 이 책의 구성

이 책은 네 시대를 시간 순서대로, 그리고 조금씩 깊이를 더해가며 다룹니다. 1장이 큰 지도를 그리는 장이라면, 2장은 그 지도를 손으로 한 번 만져보는 짧은 실습 장이고, 3장은 프롬프트, 4장은 컨텍스트, 5장은 하네스, 6~7장은 실전 사례와 조직 도입, 그리고 8장은 그 위에 한 겹 더 얹히는 루프를 다룹니다.

각 장에는 ChatGPT나 Claude에 그대로 복사해 넣을 수 있는 실습이 포함되어 있습니다. 이론만 읽고 넘어가는 책이 아니라, 손으로 확인하면서 감을 잡는 책입니다. 이번 장의 나머지 절(1-2, 1-3, 1-4)에서는 세 시대 각각의 배경과 핵심 인물, 주요 개념을 한 번씩 짚어보고, 1-5에서 네 번째로 등장한 루프 엔지니어링을 미리 소개합니다.

4. 세 가지 시대를 직접 체험해보기

말로 설명을 듣는 것보다 한 번 해보는 게 빠릅니다. 아래 세 실습은 ChatGPT, Claude, Gemini 어느 것에 넣어도 됩니다. 하나씩 따라 해보면 "프롬프트, 컨텍스트, 하네스가 결국 어떤 식으로 결과를 바꾸는 건지" 감이 잡힐 것입니다.

4.1 실습 1. 프롬프트만 바꿔보기

먼저 아래의 무성의한 한 줄을 입력해 보세요.

마케팅 이메일 써줘.

다음에는 같은 주제에 역할, 맥락, 제약 조건, 형식을 얹은 프롬프트를 넣어 보세요.

당신은 10년 경력의 B2B SaaS 마케팅 전문가입니다.
스타트업 대표에게 보내는 콜드 이메일을 작성해주세요.

제품: AI 기반 고객 지원 챗봇 (월 29,000원)
타겟: 직원 10-50명 규모의 이커머스 스타트업
목표: 무료 체험 신청 유도

조건:
- 제목 포함
- 3문단 이내
- 구체적인 수치(응답 시간 80% 단축 등) 포함
- CTA(행동 유도)는 하나만

같은 주제인데 결과가 얼마나 다르게 나오는지 확인해 보세요. 같은 모델인데 결과가 달라진다는 점, 이게 프롬프트 엔지니어링이 다루는 영역입니다.

4.2 실습 2. 정보를 같이 넣어보기

이번엔 프롬프트 자체보다 같이 넣어주는 정보가 결과를 바꾸는 경험입니다. 아래를 그대로 입력해 보세요.

아래 [참고 문서]를 기반으로만 답변하세요.
문서에 없는 내용은 "해당 정보는 확인되지 않습니다"라고 답하세요.

[참고 문서]
---
환불 정책 (2025.01 개정)
- 구매 후 7일 이내: 전액 환불 (배송비 회사 부담)
- 구매 후 8-30일: 제품 미개봉 시 전액 환불 (배송비 고객 부담)
- 구매 후 30일 이후: 환불 불가, 교환만 가능
- 디지털 상품: 다운로드 이전에만 환불 가능
- 예외: 제품 하자 시 90일 이내 전액 환불
---

질문: 2주 전에 산 미개봉 제품 환불 가능해?

이번에는 참고 문서를 통째로 빼고, 질문만 던져 보세요. AI가 "해당 정보를 확인할 수 없습니다"라고 답하거나, 그럴듯해 보이지만 실제 회사 정책과 다른 답을 만들어 낼 것입니다. 프롬프트는 그대로지만 함께 준 정보(컨텍스트)가 결과를 결정한다는 것, 이게 컨텍스트 엔지니어링의 핵심입니다.

4.3 실습 3. AI가 일할 환경 자체를 짜보기

하네스 엔지니어링이라는 단어는 코딩 분야에서 시작됐지만 원리는 어디나 똑같습니다. AI에게 참조할 자료, 지켜야 할 규칙, 다 쓴 뒤 스스로 점검할 체크리스트까지 모두 한 번에 준다는 발상입니다. 여기서는 추리 소설 집필을 예시로 잡았습니다.

먼저 아무 설계 없이 단순하게 요청해 보세요.

추리 소설 3장을 써줘.

그다음 아래의 "하네스"를 통째로 넣어 보세요. 등장인물 설정집, 문체 규칙, 자체 점검 항목까지 들어 있습니다.

당신은 한국 추리 소설 작가 에이전트입니다. 아래의 설정집, 문체 규칙,
검증 체크리스트를 반드시 따라 3장을 집필하세요.

## 캐릭터 설정집 (Story Bible)
주인공 - 서하진 (38세, 여성)
- 직업: 퇴직 형사, 현재 사설 탐정
- 성격: 냉소적이지만 약자에게 약함, 유머는 건조한 자기비하 스타일
- 말투: 짧은 문장, 감탄사 거의 없음, 독백이 많음
- 트라우마: 5년 전 미제 사건, 이것이 퇴직의 원인
- 절대 하지 않는 것: 거짓말, 술, 사건 현장에서 뛰기(무릎 부상)

피해자 - 윤재호 (45세, 남성)
- 직업: IT 스타트업 대표
- 사망 상황: 자택 서재에서 발견, 외상 없음
- 비밀: 회사 자금 횡령 의혹 (경찰은 아직 모름)

## 문체 가드레일
- 시점: 서하진 1인칭 시점만 사용
- 문장: 한 문장 40자 이내 권장, 80자 초과 금지
- 금지 표현: "갑자기", "그런데", "사실은" (추리물의 긴장감을 해치는 표현)
- 분위기: 건조하고 절제된 하드보일드, 감정 묘사는 행동으로만 표현
- 복선: 각 장마다 최소 1개의 복선 삽입 (장 끝에 [복선 메모]로 표시)

## 플롯 뼈대
- 1장: 사건 의뢰, 윤재호의 아내가 서하진을 찾아옴
- 2장: 현장 조사, 서재에서 단서 발견 (경찰이 놓친 것)
- 3장: 첫 번째 용의자, 공동 창업자 인터뷰, 알리바이에 구멍

## 일관성 검증 (각 장 집필 후 수행)
각 장을 쓴 후, 아래 항목을 ✅/❌로 자체 검증하세요:
- [ ] 서하진이 설정과 다른 행동을 하지 않았는가? (거짓말, 술, 뛰기)
- [ ] 1인칭 시점이 깨지지 않았는가?
- [ ] 금지 표현("갑자기", "그런데", "사실은")을 사용하지 않았는가?
- [ ] 80자 초과 문장이 없는가?
- [ ] 복선이 최소 1개 포함되었는가?
❌가 있으면 해당 부분을 수정한 후 다시 검증하세요.

설계 없이 쓴 소설은 매번 캐릭터가 살짝씩 달라지고, 문체도 흔들립니다. 그런데 위 하네스를 같이 주면 결과가 다음과 같이 바뀝니다.

• 설정집(Story Bible)이 참조할 지식의 역할을 합니다. 코딩으로 치면 CLAUDE.md나 API 문서가 같은 역할입니다.
• 문체 가드레일이 하지 말아야 할 것의 경계를 정합니다. 코딩으로 치면 린터 규칙입니다.
• 검증 체크리스트가 스스로 다시 보는 루프가 됩니다. 코딩으로 치면 테스트 실행이 같은 역할입니다.

이게 하네스 엔지니어링입니다. AI에게 "잘 해줘"라고 부탁하는 게 아니라, AI가 어쩔 수 없이 잘하게 되는 환경을 미리 짜두는 일입니다. 소설이든 코드든 보고서든 마케팅 자료든, 이 원리는 그대로 작동합니다.

실습 1은 "질문을 어떻게 던지는가", 실습 2는 "어떤 정보를 같이 주는가", 실습 3은 "어떤 환경에서 일하게 하는가"를 다뤘습니다. 셋 다 AI의 출력을 바꾸지만 손대는 지점이 다릅니다. 이어서 각각이 어떻게 시작됐고 어떤 핵심 개념을 갖고 있는지 한 시대씩 짚어봅니다.