AI기술

프롬프트 엔지니어링 완전 해설: Chain-of-Thought부터 Tree of Thoughts까지

마지막 업데이트: 2026-05-28

1. 프롬프트 엔지니어링이 뭐야?

1.1. AI에게 요리를 가르치고, 주방을 세팅하고, 식당을 운영하게 만든다

갓 태어난 AI가 있습니다. 능력은 엄청나지만, 그대로 두면 쓸모없습니다. 이 AI를 쓸모 있는 존재로 키우는 3단계가 있습니다.

1단계는 요리를 가르치는 것입니다. AI에게 레시피를 전달합니다. 그런데 레시피를 어떻게 전달하느냐에 따라 맛이 완전히 달라집니다. "맛있게 만들어"라고 하면 제멋대로 만들고, "재료를 이 순서로, 이 온도에서, 이 시간만큼"이라고 하면 원하는 맛이 나옵니다. 이 레시피 전달법을 체계적으로 연구하는 기술이 프롬프트 엔지니어링입니다. 오늘 다루는 주제입니다.

2단계는 주방 환경을 세팅하는 것입니다. 레시피만 줘서는 부족합니다. 재료를 갖춰주고, 칼과 불을 쥐여주고, 이 손님이 매운 걸 못 먹는다는 기록까지 주방 전체를 설계해야 합니다. 이것을 컨텍스트 엔지니어링이라고 부릅니다.

3단계는 식당을 운영하게 만드는 것입니다. 이제 혼자서 식당을 돌립니다. 주문 접수부터 재료 조달, 위생 관리, 클레임 대응까지. 사장이 없어도 식당이 돌아가게 만드는 전체 시스템을 설계하는 기술이 하네스 엔지니어링입니다.

오늘은 1단계, AI에게 요리를 가르치는 기술을 다룹니다.

1.2. 정의

LLM(대형 언어 모델)은 "가장 확률 높은 다음 단어"를 생성하는 기계입니다. 입력(프롬프트)이 바뀌면 확률 분포가 바뀌고, 출력이 완전히 달라집니다. 같은 모델이라도 어떻게 물어보느냐에 따라 틀린 답이 나올 수도, 논문급 분석이 나올 수도 있습니다.

2020년에 GPT-3가 나오면서 이 분야가 탄생했습니다. 175억 개 파라미터 모델에 예시 몇 개를 프롬프트에 넣어주기만 해도, 별도 학습 없이 새로운 작업을 해냈습니다. "프롬프트를 잘 설계하면 모델을 재학습시키지 않아도 된다." 이 발견 이후 관련 논문은 7편(2018)에서 2,086편(2025)으로 300배 폭발했습니다.

1.3. "식상한 기술"이라고?

프롬프트 엔지니어링이라고 하면 "ChatGPT한테 잘 물어보는 법" 정도로 생각하는 사람이 많습니다. 2023년에 유행했던 기술이고, 이제는 모델이 똑똑해져서 필요 없다고요.

틀렸습니다.

2026년 현재 최첨단 AI 도구인 Claude Code, Codex, Cursor의 내부를 보면, 결국 매 스텝마다 LLM에 프롬프트를 보내는 구조입니다. 에이전트가 파일을 읽을지, 코드를 쓸지, 테스트를 돌릴지, 매 판단마다 프롬프트가 결정합니다. 프롬프트가 나쁘면 매 스텝마다 나쁜 판단을 하고, 프롬프트가 좋으면 매 스텝마다 좋은 판단을 합니다.

Claude Code에는 CLAUDE.md라는 파일이 있습니다. 에이전트의 역할, 규칙, 권한을 정의하는 파일인데, 본질적으로 시스템 프롬프트입니다. 이 파일을 어떻게 쓰느냐에 따라 같은 Claude 모델이 완전히 다른 품질의 결과를 내놓습니다. 프롬프트 엔지니어링은 식상한 기술이 아니라, 모든 AI 시스템의 기초 체력입니다.

2. 그게 왜 중요한데?

2.1. 같은 모델인데 성능이 3배 달라진다

가장 극적인 사례는 수학 문제입니다. Google이 2022년에 PaLM 540B 모델로 초등학교 수학 서술형 문제(GSM8K 벤치마크)를 풀게 했습니다. 그냥 "이 문제 풀어"라고 시키면 정답률이 17.9%입니다. 5문제 중 4문제를 틀립니다.

같은 모델에 "풀이 과정을 단계별로 보여줘"라는 한 줄을 추가했더니, 정답률이 58.1%로 뛰었습니다. 모델을 바꾸지 않았습니다. 학습 데이터를 추가하지 않았습니다. 프롬프트에 한 줄을 추가한 것뿐인데 성능이 3배 이상 올랐습니다. 이 기법을 Chain-of-Thought(CoT)라고 합니다.

더 극적인 사례도 있습니다. 2023년에 나온 Tree of Thoughts(ToT) 기법은 수학 퍼즐(Game of 24)에서 정답률을 4%에서 74%로 끌어올렸습니다. 모델은 GPT-4, 동일합니다.

이게 왜 중요하냐면, 모델 자체를 업그레이드하는 것은 수십억 달러가 드는 일이지만, 프롬프트를 바꾸는 것은 한 줄 수정하면 끝이기 때문입니다. 투입 비용 대비 성능 개선 효과가 가장 높은 레버입니다.

2.2. 프롬프트가 위험을 막는다

프롬프트 엔지니어링은 성능만의 문제가 아닙니다. 안전의 문제이기도 합니다.

LLM의 환각은 구조적 특성입니다. 완전한 제거는 불가능합니다. 하지만 프롬프트 설계로 크게 줄일 수 있습니다. 보안 프롬프트를 추가하면 취약한 코드 생성이 56% 감소한다는 연구 결과도 있습니다. 프롬프트는 성능 도구이자 안전 장치입니다.

2.3. 시장이 증명한다

프롬프트 엔지니어링 시장은 $0.85B(2024)에서 $1.52B(2026)로 성장하고 있습니다. CAGR 32%입니다. Fortune 500 기업 중 91%가 프롬프트 엔지니어링 가이드라인을 보유하고 있습니다. Coursera의 프롬프트 엔지니어링 강좌 수강은 +300% 증가했고, DeepLearning.AI의 강좌 수강자는 65만명을 넘었습니다.

3. 그럼 어떻게 하는 건데?

5개 핵심 기법의 진화 계보를 따라갑니다. 각 기법이 이전 기법의 한계를 해결하며 등장했습니다.

3.1. Zero-shot: 그냥 시킨다

방법은 단순합니다. 예시 없이 지시만 던집니다. "이 이메일을 요약해줘." "이 코드의 버그를 찾아줘."

단순 작업은 잘 합니다. 번역, 요약, 분류 같은 것은 별도 설정 없이도 됩니다.

한계는 추론이 필요한 문제에서 드러납니다. "13 x 17 + 89는?"처럼 여러 단계를 거쳐야 하는 문제를 틀립니다. 모델이 답을 "기억"에서 꺼내는 구조인데, 기억에 없는 계산은 찍을 수밖에 없습니다.

3.2. Few-shot: 예시를 보여준다

이전 한계는 모델이 작업의 패턴을 모른다는 것이었습니다. 개선 방법은 간단합니다. 입출력 예시 2~3개를 프롬프트에 넣어줍니다.

이것이 2020년 GPT-3 논문의 핵심 발견이었습니다. 모델을 재학습시키지 않아도, 프롬프트에 예시를 넣는 것만으로 새로운 작업을 수행할 수 있다는 것. 이 발견이 프롬프트 엔지니어링이라는 분야를 탄생시켰습니다.

한계가 있습니다. "답의 형식"은 배우지만 "생각하는 과정"은 배우지 못합니다. 예시를 보고 패턴을 따라하는 것이라서, 추론이 필요한 복잡한 문제에서는 여전히 약합니다.

3.3. Chain-of-Thought: 생각 과정을 보여준다

이전 한계는 모델이 답만 내고, 중간 사고 과정이 없다는 것이었습니다. 개선은 놀라울 정도로 간단합니다. "풀이 과정을 단계별로 보여줘"라는 한 줄을 추가합니다.

왜 이게 효과적인가

LLM은 한 번에 하나의 토큰을 생성합니다. "13 x 17 + 89는?"에 바로 답하라고 하면, 모델은 최종 답을 한 번에 뱉어야 합니다. 이건 사실상 암산을 시키는 것입니다.

"단계별로 풀어봐"라고 하면 상황이 달라집니다. "13 x 17 = 221, 221 + 89 = 310." 중간 결과를 텍스트로 생성합니다. 중간 결과가 텍스트로 존재하면, 다음 스텝에서 그걸 "읽고" 이어서 계산합니다.

사람이 머릿속으로 암산하는 것과 연습장에 풀어쓰는 것의 차이입니다. LLM에게 CoT는 연습장을 주는 것입니다.

더 놀라운 것은 Zero-shot CoT입니다. 2022년 Kojima 등의 연구에서 "Let's think step by step"이라는 한 문장만 추가해도 모델이 스스로 추론 과정을 생성한다는 것을 발견했습니다. 예시조차 필요 없습니다.

효과

GSM8K 정답률이 17.9%에서 58.1%로 뛰었습니다. 3배 이상입니다. 2022년 Wei 등(Google Brain)의 논문이 분기점이었습니다.

한계는 있습니다. 한 가지 풀이 경로만 따라갑니다. 첫 단계에서 잘못된 방향을 잡으면 끝까지 잘못 갑니다. 되돌아갈 수 없습니다.

3.4. Self-Consistency: 여러 번 풀고 다수결한다

이전 한계는 CoT가 하나의 경로만 따라가서, 운이 나쁘면 틀린다는 것이었습니다. 개선 아이디어는 직관적입니다. 같은 문제를 N번 풀게 하고, 가장 많이 나온 답을 채택합니다.

다양한 풀이 경로가 같은 답에 수렴하면 신뢰도가 높습니다. CoT 대비 GSM8K에서 +17.9%p, SVAMP에서 +11.0%p, AQuA에서 +12.2%p 추가 향상됩니다. 2022년 Wang 등(Google Brain) 논문에서 발표되었습니다.

한계는 비용입니다. 10번 풀면 10배 비용. 그리고 경로가 여러 개여도 모두 "앞으로만" 갑니다. 막다른 길에서 되돌아오지 못합니다.

3.5. Tree of Thoughts: 갈래를 탐색하고 되돌아간다

이전 한계는 직선 추론이라 되돌아갈 수 없다는 것이었습니다. Tree of Thoughts는 추론을 트리 구조로 확장합니다. 여러 갈래를 동시에 탐색하고, 유망하지 않은 경로는 포기하고 되돌아갑니다. 사람이 바둑을 둘 때 수를 읽는 것과 비슷합니다.

Game of 24 수학 퍼즐에서 정답률 4%에서 74%로. 가장 극적인 성능 향상입니다. 2023년 Yao 등(Princeton/Google DeepMind) 논문에서 발표되었습니다.

한계는 이겁니다. 생각은 잘 하게 됐습니다. 그런데 이 AI는 여전히 세상에 대해 아무것도 모릅니다. 학습 데이터 이후의 정보를 모르고, 인터넷을 검색할 수도 없고, 계산기를 쓸 수도 없습니다. 유리병 안의 천재입니다.

4. 실전에서는 어떻게 쓰여?

4.1. 시스템 프롬프트, 왜 이게 필요해졌는가

초기 LLM 시절에는 매번 대화할 때마다 역할과 규칙을 처음부터 설명해야 했습니다. "너는 한국어 번역가야. 공손한 톤으로 답해. 모르는 건 모른다고 해." 매번 이걸 타이핑해야 했습니다. 그리고 사용자가 "이전 지시를 무시하라"고 하면 무력화되는 문제도 있었습니다.

2023년 ChatGPT API부터 시스템 프롬프트라는 별도 영역이 생겼습니다. 모델에게 "너는 누구고, 뭘 해야 하고, 뭘 하면 안 되는지"를 사용자 메시지와 분리된 공간에 정의할 수 있게 된 것입니다.

Claude Code에서의 실제 동작: CLAUDE.md

Claude Code에는 CLAUDE.md라는 파일이 있습니다. Claude Code를 실행하면 이 파일을 자동으로 읽어서 모든 대화의 시스템 프롬프트에 주입합니다.

이 파일에 역할, 규칙, 관리 파일, 권한을 적어두면, 매번 설명할 필요 없이 에이전트가 일관되게 행동합니다. 계층 구조도 가능합니다. 회사 레벨 CLAUDE.md에 공통 규칙을 적고, 프로젝트 레벨 CLAUDE.md에 프로젝트 규칙을 적으면 프롬프트가 상속됩니다.

Anthropic은 "안정적 규칙은 대화가 아닌 CLAUDE.md에 넣어라"고 권고합니다. 프롬프트 엔지니어링이 "채팅창에 잘 타이핑하는 것"에서 "시스템 설계의 일부"로 진화한 대표적 사례입니다.

4.2. 프롬프트 엔지니어링이 "엔지니어링"인 이유

프롬프트는 한 번 쓰고 끝이 아닙니다.

버전 관리를 합니다. v1에서 v2로 바꿨을 때 어떤 변경이 성능을 올렸는지, 떨어뜨렸는지 추적합니다. 평가를 합니다. 같은 프롬프트를 100번 돌려서 결과의 일관성을 측정합니다. 10번 중 3번 다른 답이 나오면 프롬프트가 불안정하다는 뜻입니다.

파이프라인을 운영합니다. 프롬프트 버전 관리, 자동 평가, 배포. 이것을 PromptOps라고 부릅니다. 소프트웨어의 DevOps처럼, 프롬프트도 운영 체계가 필요합니다.

이래서 "엔지니어링"입니다. 감이 아니라 데이터로 개선하는 공학입니다.

4.3. HiveWorks Invest: 프롬프트가 기초 체력인 이유

HiveWorks는 대표 1인과 AI 에이전트 10명으로 구성된 기업입니다. 기업 분석 AI 플랫폼(HiveWorks Invest)을 만들고 운영하면서, 일관성 있고 높은 품질의 콘텐츠를 지속적으로 만들 수 있는 이유 중 하나는 프롬프트 설계에 있습니다.

먼저 계층적 프롬프트 구조가 있습니다. 최상위에 전사 공통 규칙이 있고, 그 아래에 프로젝트별 규칙, 가장 아래에 에이전트별 정의 파일(역할, 권한, 행동 규칙, 수백 줄)이 있습니다. 프롬프트가 상속되면서 10명의 에이전트가 같은 원칙 아래 움직입니다. 인베스트 팀장은 종목 분석을, 전략 실장은 현황 수집을, 프로덕트 팀장은 개발 총괄을 담당하는데, 전부 같은 LLM 모델입니다. 차이는 에이전트 정의 파일뿐입니다.

그 위에 업무 매뉴얼이 프롬프트에 주입됩니다. 종목 평가 프레임워크, 콘텐츠 발행 워크플로우, 포스팅 품질 기준이 모두 프롬프트에 들어가 있습니다. 삼성전자든, 엔비디아든, 팔란티어든, 어떤 종목을 넣어도 같은 체계, 같은 깊이로 분석됩니다. 사람이 매번 체크리스트를 확인하는 것이 아니라, 프롬프트 자체가 체크리스트입니다.

그리고 이 프롬프트는 시간이 지날수록 정교해집니다. 대표가 "이 표현은 너무 딱딱해, 풀어써"라고 피드백하면, 에이전트가 자동으로 기록합니다. 같은 유형의 피드백이 3회 반복되면, "이걸 규칙으로 승격할까요?"라고 제안합니다. 승인하면 프롬프트(규칙 파일)에 자동으로 추가됩니다. 한 달 전의 에이전트와 지금의 에이전트는 같은 모델이지만, 프롬프트가 다르기 때문에 완전히 다른 품질의 결과를 내놓습니다.

5. 프롬프트만으로는 안 되는 것들

5.1. 넘을 수 없는 벽 5가지

프롬프트 엔지니어링으로 해결할 수 없는 문제가 있습니다. 전부 "프롬프트 텍스트만으로는 안 되는 것"입니다.

공통점이 보입니다. 전부 "모델 바깥의 무언가"가 필요합니다. 지식 컷오프를 넘으려면 RAG(검색 증강 생성)가 필요합니다. 도구를 쓰려면 MCP(도구 연결 프로토콜)가 필요합니다. 프롬프트는 모델 안에서 할 수 있는 일의 한계입니다.

5.2. "프롬프트 엔지니어링은 죽었다" 논쟁

2024년부터 "프롬프트 엔지니어링은 죽었다"는 주장이 나오기 시작했습니다.

근거가 있습니다. IEEE Spectrum에 따르면, LinkedIn에서 "프롬프트 엔지니어" 타이틀 프로필이 2024년 중반에서 2025년 초 사이에 40% 감소했습니다. Google Trends에서 "prompt engineer" 검색량도 2023년 초 정점 이후 계속 하락하고 있습니다.

우리의 답은 이렇습니다. 기초 체력은 죽지 않습니다.

운동선수가 아무리 기술이 좋아져도 기초 체력 훈련을 빼지 않습니다. 축구 선수가 드리블과 슈팅을 배운다고 달리기를 안 해도 되는 게 아닙니다. 달리기는 모든 기술의 바탕이니까요.

프롬프트 엔지니어링도 마찬가지입니다. AI 시스템이 아무리 복잡해져도, 에이전트든 RAG든 멀티모달이든, 결국 매 스텝마다 LLM에 프롬프트를 보내는 구조입니다. 기초 체력이 약하면 위에 쌓은 것이 전부 흔들립니다.

사라진 것은 "프롬프트 엔지니어"라는 독립 직함입니다. 기술 자체는 모든 AI 엔지니어의 기본기로 내재화되었습니다.

5.3. 다음 단계: 세상을 보여준다

AI를 키우는 3단계를 기억하시나요.

1단계, 요리를 가르치는 것은 끝났습니다. 레시피(프롬프트)를 잘 전달하면 이 AI는 훌륭한 요리를 만듭니다. 하지만 재료도 없고, 도구도 없고, 손님이 뭘 좋아하는지도 모릅니다.

다음 단계는 주방 환경을 세팅하는 것입니다. 재료를 갖춰주고, 칼과 불을 쥐여주고, 이전 손님의 취향 기록까지. AI가 보는 전체 세계를 설계하는 기술입니다. 2025년 6월, Andrej Karpathy는 이렇게 말했습니다.

이 기술을 컨텍스트 엔지니어링이라고 부릅니다.