AI 와의 대화 — 프롬프트 엔지니어링의 개막
1.1 들어가며 — 가장 작은 질문에서 시작한다
들어가며 에서 우리는 4 거인이 도달한 같은 결론 — "설계 없이는 코드 한 줄도 없다" — 이 4년의 진화 끝에 기록된 자리라는 사실을 확인했다. 그 진화의 가장 첫 발걸음은 의외로 작은 질문에서 시작되었다. 왜 명령조로 쓴 한 줄이 정중한 부탁보다 더 정확한 코드를 만드는가. 이 작은 질문이 한 시대를 열었다.
본 장은 그 시대의 이름인 프롬프트 엔지니어링(Prompt Engineering) 을 다룬다 concept/prompt-engineering. 이 단어가 처음 등장한 2022년부터 2024년경까지 약 2년 반 동안, 전 세계 개발자들은 "AI 에게 어떻게 말하면 더 좋은 답이 나오는가" 라는 질문에 매달렸다. 그 결과로 수십 가지 기법이 발견되었고, 그중 네 가지가 핵심으로 살아남았다. 역할(Role) · 맥락(Context) · 형식(Format) · 루프(Loop, 곧 생각의 사슬) 의 네 슬롯, 그리고 그 위에 보너스로 박히는 명령조의 통계적 우위 라는 작은 발견.
본 장은 이 네 기법을 단순히 나열 하지 않는다. 우리는 그것들이 왜 그 시점에 그 형태로 등장했는가 를 따라가고, 그것들이 왜 곧 한계에 부딪혔는가 를 짚는다. 그 한계가 다음 장 — 컨텍스트 부패(Context Rotting) — 의 출발점이 된다. 본 장의 결론을 미리 적자면 이렇다 — 프롬프트 엔지니어링은 시작점이지, 도착지가 아니다. 그러나 이 시작점을 정확히 이해하지 않고서는 그 다음의 어떤 기법도 제 자리를 찾지 못한다.
1.2 핵심 개념 — 프롬프트 엔지니어링의 정의와 4 대 기법
1.2.1 정의 — 한 번의 질문 을 설계하는 기술
프롬프트 엔지니어링(Prompt Engineering) 은 LLM(Large Language Model, 대규모 언어 모델) 에게 원하는 결과를 얻기 위해 한 번의 질문 을 설계·최적화하는 기술이다 concept/prompt-engineering. 핵심 단어는 한 번 이다. 시스템적 입력 파이프라인이 아니라, 한 줄의 자연어 입력 을 어떻게 짜야 모델이 가장 정확한 응답을 내놓는가. 이 미시적 질문이 2022년부터 2024년 초반까지 이 분야의 모든 활동을 정의했다.
이 기술이 학문적 영역 으로 자리 잡은 이유는 분명하다. 당시 GPT-3.5 와 같은 초기 모델은 컨텍스트 윈도우가 4K~8K 토큰에 불과했고, 추론 능력은 인간 시니어 엔지니어에 미치지 못했다. 모델은 잠재적으로 다양한 분야의 지식을 갖고 있었지만, 그 지식을 어떻게 끌어내는가 는 입력 텍스트의 미묘한 차이에 좌우되었다. 같은 질문을 다르게 표현하면 응답의 질이 극적으로 달라졌다. 그 차이를 체계화 하려는 시도가 곧 프롬프트 엔지니어링이라는 분야를 탄생시켰다.
1.2.2 4 대 기법 — 역할 · 맥락 · 형식 · 루프(생각의 사슬)
이 시기에 발견된 핵심 기법은 네 가지로 압축된다. 학술 논문은 페르소나(Persona) · CoT · ReAct · 명령조 같은 어휘로 부르지만, 현장의 엔지니어가 매일 쓰는 작업 어휘로 옮기면 더 단순해진다 — 역할(Role) · 맥락(Context) · 형식(Format) · 루프(Loop, 곧 생각의 사슬). 이 네 단어가 우리가 한 번의 질문에 박을 수 있는 네 개의 슬롯 이다.
첫째, 역할(Role). 모델에게 누구로서 답하라 를 지정하는 슬롯이다. 단순한 질문 대신 "너는 20년 경력의 시니어 백엔드 아키텍트다" 같은 페르소나를 주입하면, 모델이 방대한 텍스트 코퍼스(corpus) 안에서 해당 전문성에 부합하는 가중치를 우선 탐색하도록 유도되어 답변의 질이 비약적으로 상승한다. 이는 모델이 가진 지식이 늘어나는 것 이 아니라, 이미 가진 지식 중 어느 영역을 깨울 것인가 의 문제다. 같은 질문이라도 "개발자에게 답해줘" 와 "신입 개발자에게 답해줘" 는 결과가 다르다.
예시 (역할): "너는 PostgreSQL(포스트그레SQL) 14 의 무중단(zero-downtime) 마이그레이션을 100 회 이상 수행한 시니어 DBA(Database Administrator) 다."
둘째, 맥락(Context). 모델에게 어떤 상황에서 답하라 를 알려주는 슬롯이다. 같은 질문도 맥락이 다르면 답이 다르다. 트래픽 1만의 사이드 프로젝트와 트래픽 1억의 운영 시스템은 같은 SQL 도 다르게 짜야 한다. 맥락은 사용자의 제약 조건 과 기존 결정 을 한 줄씩 기록하는 것이다. 기술 스택, 데이터 규모, 가용성 요구, 이미 고려한 대안과 그 거절 이유 — 이 맥락이 비어 있으면 모델은 교과서적 답 만 내놓는다.
예시 (맥락): "우리 시스템은 일일 평균 5,000 만 트랜잭션, PostgreSQL 14 (RDS Multi-AZ), Aurora 마이그레이션 검토 후 비용으로 거절됨. 무중단이 절대 조건이며, 다운타임 > 30 초는 SLA 위반."
셋째, 형식(Format). 모델에게 어떤 모양으로 답하라 를 기록하는 슬롯이다. 이 슬롯이 비면 모델은 보통 5 단락의 친절한 산문 으로 답한다. 그러나 우리가 원하는 것은 종종 마크다운 표 한 컷, 체크리스트 7 줄, JSON 스키마 한 블록 이다. 형식 슬롯이 채워지면 응답을 다음 단계 — 코드 입력, 문서 삽입, API 호출 — 로 바로 흘려 보낼 수 있다. 형식은 단순한 미적 선택이 아니라 워크플로우의 다음 단계와의 인터페이스 다.
예시 (형식): "응답은 다음 형식으로: (1) 후보 SQL 옵션 3 개를 마크다운 표로 제시 — 행: 옵션, 열: 무중단 여부 / 예상 락(lock) 시간 / 롤백 방법. (2) 권장안 1 개를 왜 와 함께 한 단락으로. (3) 검증 SQL 한 블록 (BEGIN ... ROLLBACK)."
넷째, 루프(Loop) — 곧 생각의 사슬(Chain-of-Thought, CoT). 모델에게 바로 결론으로 가지 말고, 단계별로 풀어 보고, 만약 틀렸으면 다시 풀어 보라 를 기록하는 슬롯이다. 학술적으로는 2022년 Google Research 가 발표한 "Let's think step by step" (단계별로 천천히 생각해줘) 의 발견 term/cot 이지만, 실무자의 어휘로는 루프 가 더 정확하다. 모델이 생각 → 답변 → 자가 검토 → 수정 → 답변 의 사이클을 한 프롬프트 안에서 돌게 하는 것이기 때문이다. 한 줄을 추가했을 뿐인데 수학·논리·다단계 결정 문제의 정확도가 추론 모델 수준 으로 올라간다는 발견은 당시 충격적이었다. 그리고 이 루프 가 다음 단원에서 다룰 리액트(ReAct, Reasoning + Acting) 라는 외부 도구 호출 패턴 term/react-prompting 으로 확장되어, 결국 오늘날의 모든 코딩 에이전트 (Claude Code, Cursor, Codex, Gemini) 의 골격이 된다.
예시 (루프 / 생각의 사슬): "먼저 위 옵션 3 개의 lock 동작을 단계별로 시뮬레이션해줘 (각 SQL 한 줄씩 → PostgreSQL 의 어떤 lock 이 잡히는가 → 동시에 들어오는 INSERT 가 막히는가). 그 다음 각 옵션을 자가 평가하고, 가장 위험한 옵션부터 제외해줘. 마지막에 권장안만 남겨줘."
이 네 슬롯은 서로 배타적이지 않다. 가장 강력한 한 번의 프롬프트는 네 슬롯을 동시에 채운다. 그리고 이 네 단어 — 역할 / 맥락 / 형식 / 루프 — 가 프롬프트 엔지니어링의 일상 어휘 다. 본 책의 모든 후속 챕터에서 우리가 박을 명세(Spec), 컨텍스트 엔지니어링, 하네스 엔지니어링 도 본질적으로 이 네 슬롯의 확대 버전 이다 — 한 번의 질문에 들어가던 네 슬롯이, 시스템 단위로 펼쳐진 형태가 곧 그 다음 패러다임들이다.
보너스 발견 — 명령조의 통계적 우위. 이 시기에 한 가지 작은 발견이 있었다. AI 에게 정중하게 부탁하는 것보다, 단호하고 지시적인 명령조 — 심지어 한국어 반말 — 를 사용할 때 코드 생성의 정확도가 통계적으로 유의미하게 상승한다는 실증적 연구 결과들이 보고되었다. 이는 단순한 문화적 선호 가 아니라, 모델이 인간 피드백 기반 강화학습(RLHF, Reinforcement Learning from Human Feedback) 을 거치는 과정에서 명확하고 통제된 지시어 에 더 높은 보상값을 갖도록 최적화되었다는 점을 시사하는 대목이었다. 정중함이 아니라 명확함이 모델의 응답 품질을 결정하는 변수였다 — 위 네 슬롯을 모두 반말의 명령조 로 기록하는 편이 공손한 청유형 보다 통계적으로 더 정확한 응답을 끌어낸다.
1.3 역사적 맥락 — Copilot 과 ChatGPT, 그리고 그 사이의 5 개월
1.3.1 첫 분기점 — 2022년 6월, GitHub Copilot 의 정식 출시
소프트웨어 생태계에 AI 가 실질적인 조력자 로 등장한 최초의 분기점은 2022년 6월, GitHub Copilot(깃허브 코파일럿) 의 정식 출시로 기록된다 entity/github-copilot. 월 10 달러의 구독형 모델로 시장에 도입된 이 서비스는 고스트 텍스트(Ghost Text) 라는 혁신적인 사용자 경험을 선보였다. 개발자가 IDE(Integrated Development Environment, 통합 개발 환경) 안에서 코드를 타이핑할 때, 커서의 위치와 이전 코드의 맥락을 분석하여 다음에 입력될 코드를 회색 텍스트로 미리 제안하고, Tab 키 한 번에 즉시 수용할 수 있게 한 이 기능은 개발 생산성의 새로운 지평을 열었다.
그러나 이 시기의 AI 는 본질적으로 통계적 확률에 기반한 고도화된 자동 완성기 에 머물러 있었다. Copilot 은 왜 이 코드가 이런 형태여야 하는가 를 알지 못했다. 단지 비슷한 맥락에서 인간 개발자가 다음에 무엇을 타이핑했는가 를 통계적으로 추정해 제안했다. 그러므로 Copilot 의 도움을 가장 많이 받는 사람은 제안된 코드가 적절한지 즉시 판단할 수 있는 숙련 개발자 였고, 가장 위험한 사용자는 제안을 그대로 수용하는 초보자 였다. 이 위험은 이후 AI slop(AI 쓰레기) 라는 단어로 일반화된다.
1.3.2 두 번째 분기점 — 2022년 10월 30일, ChatGPT 의 출시
5개월 뒤인 2022년 10월 30일, OpenAI(오픈AI) 의 ChatGPT(챗지피티) 가 출시되며 진정한 의미의 대화형 AI 코딩 시대 가 본격 개막되었다. 출시 5일 만에 100만 명 이상의 활성 사용자를 확보하며 전 세계적인 돌풍을 일으킨 이 서비스는, 자연어 명령을 통해 복잡한 알고리즘을 구현하고 버그를 수정하는 능력을 과시했다. 그러나 당시에 탑재된 GPT-3.5 모델은 복잡한 소프트웨어 아키텍처를 단번에 이해하거나 다단계의 논리적 결함을 스스로 교정할 만큼의 고도화된 추론 성능을 갖추지 못했다.
ChatGPT 가 등장한 직후의 풍경은 흥미롭다. 개발자들은 이 도구를 완벽한 코딩 비서 로 다루지 않았다. 대신 어떻게 질문해야 좋은 답이 나오는가 라는 질문에 매달렸다. 같은 코드 문제를 다섯 가지 방식으로 다르게 질문해 보는 실험이 매일 트위터(X)에 올라왔다. 어떤 표현이 더 정확한 답을 끌어내는지, 어떤 페르소나가 더 깊은 추론을 활성화하는지 — 이 실험들의 누적이 곧 프롬프트 엔지니어링이라는 분야의 학문적 정립으로 이어졌다.
1.3.3 명령조와 RLHF — 작은 발견이 보여준 큰 지도
이 시기의 가장 흥미로운 발견 하나는, 앞서 언급했던 명령조의 통계적 우위 였다. 모델이 RLHF 과정을 통해 명확하고 단호한 지시어 에 더 높은 보상을 받도록 학습되었다는 가설은 단순한 도구 사용법을 넘어, AI 와 인간의 인터페이스가 어떻게 진화할 것인가 에 대한 단서를 보여 주었다. 우리는 AI 에게 친절히 부탁하는 사람 이 아니라 명확히 명령하는 사람 이 되어야 한다. 이는 비인간적인 자세가 아니라, 기계라는 도구의 본성에 맞춘 인간의 적응 이다. 망치에게 부드럽게 말한다고 못이 더 잘 박히지는 않는다.
이 발견이 4년 뒤 명세 주도 개발(Spec-Driven Development, SDD) 의 핵심 원리 — 명세는 모호함의 적이다 — 와 같은 방향을 가리키고 있었다는 점이 흥미롭다. 명령조의 통계적 우위는 작은 발견 이었지만, 그것이 가리키는 방향은 큰 지도 였다. 본 책 7장의 명세 주도 개발 은 이 방향의 끝에서 만나는 형태다.
1.4 도구의 관점 — 4 기법이 어떻게 결합되는가
1.4.1 하나의 작업, 네 기법의 조합
프롬프트 엔지니어링의 4 대 기법은 분리되어 작동하지 않는다. 실제 워크플로우에서는 거의 항상 조합되어 등장한다. 예컨대 한 백엔드 개발자가 데이터베이스 마이그레이션 스크립트 를 작성하기 위해 ChatGPT 에 입력하는 프롬프트는 다음과 비슷한 모양일 것이다. "너는 PostgreSQL 마이그레이션 전문가다(역할). 다음 스키마 변경을 무중단(zero-downtime)으로 적용하는 단계별 SQL 을 작성해줘. 단계별로 천천히 생각하고, 필요하면 EXPLAIN ANALYZE 결과를 가정해서 검증해라(CoT + 명령조)."
이 짧은 프롬프트 안에 역할 부여, 명령조, CoT 가 동시에 들어 있다. 만약 이 작업이 외부 정보가 필요한 작업 — 예컨대 PostgreSQL 의 최신 버전 동작 변경 사항 확인 — 이었다면 ReAct 가 자연스럽게 결합되어 모델이 외부 도구를 호출하는 형태로 진화했을 것이다. 이렇듯 4 기법은 어휘 다. 어휘는 따로 외울 수 있지만, 실제 문장 은 어휘들의 조합으로 만들어진다.
1.4.2 ReAct 의 사이클 — 현대 코딩 에이전트의 원형
[[DIAGRAM:1-1]]
위 다이어그램이 ReAct 사이클의 본질이다. Reasoning → Acting → Observation → Reasoning → ... 의 반복. 이 단순한 사이클이 오늘날 우리가 쓰는 모든 코딩 에이전트의 뼈대다. Claude Code 가 파일을 읽고 코드를 수정하고 테스트를 돌리는 흐름, Cursor 가 코드베이스를 탐색하고 변경 사항을 제안하는 흐름, GitHub Copilot 의 Agents 가 이슈를 받고 PR(Pull Request, 풀 리퀘스트) 을 만드는 흐름 — 모두 ReAct 사이클의 강화판이다.
여기서 한 가지 중요한 통찰이 기록된다. 우리가 프롬프트 엔지니어링은 끝났고 이제 에이전트의 시대 라고 말할 때, 그 에이전트 의 내부에는 여전히 프롬프트 엔지니어링의 가장 정교한 형태 가 작동한다. 사용자가 보지 못할 뿐, 에이전트는 매 사이클마다 자기 자신에게 역할 부여 + CoT + 도구 호출 의 조합을 던진다. 프롬프트 엔지니어링은 사라지지 않았다. 사용자의 시야 밖으로 이동 했을 뿐이다.
1.4.3 4 기법 한 컷 비교
[[DIAGRAM:1-2]]
두 번째 다이어그램이 4 슬롯 — 역할 / 맥락 / 형식 / 루프 — 의 의미와 예시를 한 컷에 담는다. 본 장의 시각적 요약 이다. 이 4 슬롯을 머리 한쪽에 박아두는 것이 본 장의 실용적 목표 중 하나다 — 다음 챕터부터 우리가 논할 컨텍스트 엔지니어링 과 하네스 엔지니어링 도 결국 이 4 슬롯의 시스템 단위 확장 이기 때문이다.
1.5 닫으며 — 한계가 다음 시대를 부른다
프롬프트 엔지니어링은 강력했지만 곧 한계에 부딪혔다. 그 한계의 이름은 컨텍스트 윈도우(Context Window) 다. 한 번의 질문이 아무리 정교해도, 대화가 길어지면 모델은 초반의 지시를 잊어버린다. 코드베이스가 커지면 한 질문에 모든 맥락을 담을 수 없다. 트랜스포머(Transformer) 아키텍처의 특성상 입력 시퀀스가 길어질수록 모델이 문맥의 가운데에 위치한 정보 를 놓치는 Lost in the Middle 현상이 심화된다 term/context-window.
이 한계가 다음 장의 출발점이다. 우리는 곧 프롬프트 엔지니어링의 영광이 어떻게 컨텍스트 부패(Context Rotting) 의 절망으로 전환되는지 를 보게 된다. 그리고 그 절망이 어떻게 컨텍스트 엔지니어링(Context Engineering) 이라는 새 패러다임을 강제하는지를. 본 장은 그 출발점 — 우리가 한 번의 질문을 정교화하던 시대 — 의 마지막 조각이다.
이 시대가 우리에게 남긴 진짜 유산은 네 기법 그 자체가 아니라, 그것을 발견한 자세 다. AI 에게 어떻게 말해야 더 좋은 답이 나오는가 를 매일 실험하던 그 자세, 작은 차이가 큰 결과를 만든다는 직관 — 이 직관이 본 책의 모든 후속 장에서 반복적으로 등장하는 컨텍스트 정밀도 와 명세 정확성 의 출발점이다. 지금도 우리가 CLAUDE.md 의 한 줄을 정성 들여 다듬는 이유는, 본질적으로 2022년 한 트위터 사용자가 "step by step" 한 줄을 추가해 보던 그 자세의 연장이다.
다음 Chapter 2 는 그 한계의 해부학이다. 컨텍스트 부패(Context Rotting) — 윈도우의 한계가 만드는 망각.
1.6 용어 정리
- 프롬프트 엔지니어링 (Prompt Engineering): LLM 에게 한 번의 질문 을 설계·최적화하는 기술 — 4 슬롯의 결합으로 정의
- 4 슬롯 ① 역할 (Role): 모델에게 누구로서 답하라 를 지정하는 슬롯 — 도메인 가중치 활성화
- 4 슬롯 ② 맥락 (Context): 모델에게 어떤 상황에서 답하라 를 알려주는 슬롯 — 제약·전제·기존 결정 박기
- 4 슬롯 ③ 형식 (Format): 모델에게 어떤 모양으로 답하라 를 기록하는 슬롯 — 다음 단계와의 인터페이스
- 4 슬롯 ④ 루프 (Loop, 곧 Chain-of-Thought / CoT): 생각 → 답변 → 자가 검토 → 수정 의 사이클을 한 프롬프트 안에 기록하는 슬롯
- 리액트 (ReAct, Reasoning + Acting): 추론과 외부 도구 호출을 번갈아 수행하는 패턴 — 루프의 외부 도구 호출 확장, 현대 코딩 에이전트의 원형
- 명령조의 통계적 우위 (Imperative Tone Advantage): 정중함보다 단호한 명령조가 통계적으로 더 정확한 응답을 끌어내는 현상 — RLHF 보상 구조에서 비롯
- 환각 (Hallucination): 모델이 사실이 아닌 내용을 사실처럼 만들어내는 현상
- 인간 피드백 기반 강화학습 (RLHF, Reinforcement Learning from Human Feedback): 모델을 인간 평가자의 피드백으로 미세조정하는 학습 방법 — 명령조 우위의 기술적 근거
- 통합 개발 환경 (IDE, Integrated Development Environment): 코드 편집기·디버거·빌드 도구가 통합된 개발자용 소프트웨어
- 고스트 텍스트 (Ghost Text): Copilot 이 다음 코드를 회색으로 미리 보여주는 UX 패턴
1.7 더 읽을거리
위키 카드:
- concept/prompt-engineering — 프롬프트 엔지니어링 정의와 4 기법
- term/cot — Chain-of-Thought 메커니즘과 사용 시점
- term/react-prompting — ReAct 사이클 자세히
- entity/github-copilot — Copilot 의 자체 진단과 진화
- entity/altman — Sam Altman 의 판단의 본질 발언
1차 출처:
- Wei et al. "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", Google Research, 2022
- Yao et al. "ReAct: Synergizing Reasoning and Acting in Language Models", 2022
- GitHub Copilot 정식 출시 — 2022년 6월
- OpenAI ChatGPT 출시 — 2022년 10월 30일
Diagram 명세 블록
[[DIAGRAM:1-1]] ReAct 사이클 — 현대 코딩 에이전트의 원형
┌────────────────────────────────────────────────────────────────────┐
│ [Diagram 1-1] ReAct (Reasoning + Acting) 사이클 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Question (사용자 질문 / 작업 지시) │ │
│ └────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Reasoning (생각 — 무엇을 알아야 하는가) │ ◀──┐ │
│ └────────────────────┬──────────────────────────────┘ │ │
│ ▼ │ │
│ ┌───────────────────────────────────────────────────┐ │ │
│ │ Acting (도구 호출 — 검색·DB·파일·코드 실행) │ │ │
│ └────────────────────┬──────────────────────────────┘ │ │
│ ▼ │ │
│ ┌───────────────────────────────────────────────────┐ │ │
│ │ Observation (도구 응답을 받아 다음 추론의 입력으로) │ ───┘ │
│ └────────────────────┬──────────────────────────────┘ │
│ ▼ │
│ (충분하면 Final Answer) │
│ │
│ ╳ 핵심: 단방향 질의응답 ❌ → *생각 ↔ 행동 ↔ 관찰* 의 반복 │
│ ╳ 효과: 환각 감소 · 최신 정보 접근 · 복잡 작업 분해 · 추적 가능성 │
│ ╳ 진화: 2022 Yao et al. 논문 → 2024+ Claude Code · Cursor · Codex │
│ │
├────────────────────────────────────────────────────────────────────┤
│ 출처: [term/react-prompting](https://ai.llmwiki.kr/vibe-coding/term/react-prompting/), Yao et al. 2022 │
└────────────────────────────────────────────────────────────────────┘
[[DIAGRAM:1-2]] 프롬프트의 4 슬롯 — 역할 · 맥락 · 형식 · 루프
┌────────────────────────────────────────────────────────────────────┐
│ [Diagram 1-2] 한 번의 프롬프트에 박히는 4 슬롯 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 슬롯 무엇을 박는가 예시 한 줄 │
│ ──── ───────────── ───────── │
│ │
│ ① 역할 누구로서 답할지 "너는 시니어 DBA 다." │
│ (Role) 도메인 가중치 활성화 │
│ │
│ ② 맥락 어떤 상황에서 "트래픽 5천만/일, │
│ (Context) 제약·전제·기존 결정 PostgreSQL 14, Aurora 거절"│
│ │
│ ③ 형식 어떤 모양으로 "마크다운 표 + 권장안 1 + │
│ (Format) 다음 단계와의 인터페이스 검증 SQL 블록" │
│ │
│ ④ 루프 단계별로 풀고 자가 검토 "단계별로 시뮬레이션 → │
│ (Loop = 생각의 사슬 (CoT) 자가 평가 → 위험순 제외" │
│ /CoT) │
│ │
│ ╳ 4 슬롯은 *동시에* 채워질 때 가장 강력하다 │
│ ╳ 보너스: 위 네 슬롯을 *반말의 명령조* 로 박으면 정확도 추가 상승 │
│ ╳ 다음 챕터부터 등장할 *컨텍스트 엔지니어링·하네스* 도 │
│ 이 4 슬롯의 *시스템 단위 확대 버전* 이다 │
│ │
├────────────────────────────────────────────────────────────────────┤
│ 출처: [concept/prompt-engineering](https://ai.llmwiki.kr/vibe-coding/concept/prompt-engineering/) + [term/cot](https://ai.llmwiki.kr/vibe-coding/term/cot/) 통합 │
└────────────────────────────────────────────────────────────────────┘