지난 편에서 8가지 프롬프트 구현 패턴을 살펴봤어요. 이번 편에서는 복잡한 추론과 판단이 필요한 작업에서 특히 강력한 세 가지 핵심 기법인 사고 사슬(CoT), 역할 프롬프팅, 프롬프트 체이닝을 깊이 다뤄요.
| 기법 | 사용 시점 | 핵심 팁 |
|---|---|---|
| 사고 사슬(Chain of Thought) | 복잡한 추론, 다요인 의사결정 | AI가 따를 단계를 명시 |
| 역할 프롬프팅(Role Prompting) | 도메인 전문성이나 특정 관점 필요 | 경험과 제약을 구체적으로 |
| 프롬프트 체이닝(Prompt Chaining) | 다단계 작업, 각 단계에서 품질 필요 | 각 단계에 정확히 하나의 역할 |
1. 사고 사슬(Chain of Thought) 프롬프팅: AI의 단계적 추론
프롬프트를 활용한 많은 작업들은 여러가지 발생할 수 있는 제약사항들을 파악하고, 완벽하지 않은 선택지들을 비교하며, 충분하지 않은 정보들을 통해 결정을 내려야하는 과정을 수반해요.
그렇기에 모델이 합리적인 추론 과정을 건너뛰고 바로 답변을 면, 자신감 있게 들리지만 근거가 부족한 결과를 내놓곤 해요. 사고 사슬(CoT, Chain of Thought)는 모델에게 속도를 늦추고 자신의 추론 과정을 의도적으로 생각하게 유도해서 이 행동을 바꿔요. “답이 뭐야?” 대신 “신중하게 접근한다면 이 작업에 대해 어떻게 논리적으로 접근할거야?”라고 묻는 거죠.
1) 사고 사슬 프롬프팅을 언제 사용할까
사고 사슬은 문제 자체에 구조가 있을 때 가장 유용해요. 균형 잡아야 할 여러 제약이 있거나, 답이 중간 추론에 의존하거나, 결론에 어떻게 도달했는지가 중요하거나, 실수가 비싸거나 감지하기 어려울 때요.
그렇다고 해서 사고 사슬은 만병통치약이 아니에요. 작업의 출력이 기계적이거나, 포맷 위주이거나, 깊이보다 속도가 중요하면 피하세요. 사고 사슬은 추가 추론 단계를 도입하므로 더 많은 토큰과 시간 소모를 의미해요. 숙고가 도움이 되지 않는 작업에서 CoT는 낭비가 될 가능성이 커요.
수학 시험에서 “풀이 과정을 쓰세요”와 같아요. 답만 적으면 우연히 맞을 수 있지만, 풀이 과정을 쓰면 논리적 오류를 잡을 수 있고, 어디서 틀렸는지도 알 수 있죠. AI에게도 “생각 과정을 보여줘”라고 하면 더 정확한 답을 얻어요.
2) 기본 CoT: “단계별로 생각해줘”
가장 간단한 형태는 짧은 지시예요.
“답하기 전에 단계별로 생각해줘.”
이것이 효과적인 이유는 모델의 기본 행동을 바꾸기 때문이에요. 이 지시 없이는 모델이 유창함과 속도에 최적화하는 경향이 있어요. 이 지시가 있으면 모델이 추론에 더 많은 노력을 할당하죠.
우리 스타트업이 AWS, GCP, Azure 중 어느 클라우드를 선택해야 할까요?
상황:
- 5명 엔지니어링 팀
- Python/ML 중심 워크로드
- 월 300만 원 예산
- 12개월 내 사용자 10배 확장 필요
추천하기 전에 단계별로 생각해주세요.
마지막 줄은 정보를 추가하지 않아요. 모델이 정보를 사용하는 방식을 바꿔요.
기본 CoT를 비유하면, 급한 결정을 내리기 전 “잠깐, 다시 한번 생각해보자”라고 말하는 것과 같아요. 바로 답하면 직감에 의존하게 되지만, 멈추고 생각하면 더 나은 판단에 도달하죠.
3) 구조화된 CoT: 명시적 추론 단계 정의
더 높은 위험의 결정에서는 더 명시적으로 하는 것이 가치 있어요. “단계별로 생각해”라고 하는 대신, 그 단계가 무엇이어야 하는지 정의하세요.
고객 분석 솔루션을 자체 개발할지 구매할지 평가해줘.
다음 단계를 따라:
1단계: 필요한 핵심 역량 나열
2단계: 개발 비용(엔지니어링 시간 × 단가)과 일정 추정
3단계: 구매 옵션과 연간 비용 조사
4단계: 3년 총소유비용 비교
5단계: 비용 외 요인 식별 (유연성, 유지보수, 벤더 리스크)
6단계: 확신 수준(높음/보통/낮음)과 함께 추천
이 접근법은 두 가지를 해요. 모델의 추론을 내가 중요시하는 차원으로 제약하고, 뭔가 이상하면 누락을 더 쉽게 발견할 수 있게 해요.
4) AI 추론과 최종 출력 분리하기
때로는 추론 과정을 보고 싶지만, 최종 결과물에는 포함하고 싶지 않아요.
이 가격 변경 제안을 분석해줘.
**분석 과정은 <thinking> 태그에,
최종 추천은 <answer> 태그에 넣어줘.**
제안: Pro 플랜을 월 29,000원에서 39,000원으로 인상
이 패턴은 결정을 검토하거나 감사할 때, 근거를 원하는 이해관계자와 협업할 때, 프롬프트를 반복·개선하면서 실패를 진단할 때 특히 유용해요. 투명성을 얻으면서도 사용성을 희생하지 않죠.
추론 분리를 비유하면, 시험 답안지의 “계산 과정란”과 “최종 답란”의 분리와 같아요. 선생님은 풀이 과정을 보고 사고 과정을 확인할 수 있고, 학생은 깔끔한 최종 답을 제출할 수 있죠.
2. 역할 프롬프팅: AI 페르소나 부여로 더 나은 결과 얻기
역할 프롬프팅은 작업 전에 모델에게 특정 직업적 정체성이나 관점을 부여하는 거예요.
표면적으로는 톤 조절처럼 보이지만, 실제로는 훨씬 더 많은 일을 해요. 대규모 언어 모델은 다양한 도메인, 글쓰기 스타일, 전문적 관점의 혼합으로 학습돼요. 안내 없이는 넓고 일반적인 입장으로 기본 설정되어, 안전하고 균형 잡히고 모호한 답을 내놓는 경향이 있죠.
역할을 부여하면 모델에게 어떻게 들려야 하는지만이 아니라, 어떤 멘탈 모델(mental model)에 기반한 프레임워크를 적용할지, 어떤 트레이드 오프가 중요한지, 어떤 정보를 무시할지를 알려주는 거예요. 그래서 역할 프롬프팅이 더 결단력 있고 관련성 높은 답변으로 이어지곤 하죠.
1) 역할 부여가 AI 출력을 바꾸는 방법
잘 정의된 역할은 세 가지 차원에서 모델에 영향을 미쳐요.
관점과 우선순위
모델이 그 역할의 사람처럼 문제를 저울질해요. 변호사는 리스크를, PM은 트레이드오프를, 마케터는 내러티브와 포지셔닝을 살피죠.
언어와 톤
어휘, 격식, 직접성이 역할에 따라 자연스럽게 달라져요. 일반적 설명이 줄고 도메인에 적합한 표현이 늘어요.
범위 경계
명확한 역할은 관련 없는 조언이나 불필요한 이론으로 빠질 확률을 줄여요.
역할 프롬프팅을 비유하면, 회의에서 “마케팅 관점에서 의견 주세요”라고 요청하는 것과 같아요. 일반적으로 의견을 물으면 두루뭉술한 답이 나오지만, 특정 관점을 지정하면 그 렌즈를 통한 날카로운 피드백을 받을 수 있죠.
2) 효과적인 역할 프롬프트 작성법
“전문가”나 “컨설턴트” 같은 직함은 구체적으로 들리지만, 모델의 추론 방식을 의미 있게 바꾸지 못해요. 효과적인 역할은 세 가지를 포함해요.
경험의 깊이(Experience Depth)
이 역할이 얼마나 숙련되었는지 표시해요. 연차나 반복 경험이 지식이 아니라 판단력을 신호해요.
업무적 맥락(Operating Context)
이 역할이 어디서 활동하는지 명시해요. 회사 단계, 산업, 제약이 직함보다 중요해요.
결정의 기준(Decision Bias)
이 역할이 무엇을 우선시하거나 일관되게 반대하는지 명확히 해요.
❌ 모호한 역할:
당신은 유용한 어시스턴트입니다. 이 계약서를 검토해주세요.
✅ 구체적 역할:
당신은 SaaS 계약에 15년 경력을 가진 기업 변호사입니다.
시리즈 B~C 스타트업을 위해 수백 건의 벤더 계약을 검토했습니다.
다음에 초점을 맞춰 이 계약서를 검토해줘:
- 책임 한도와 면책 조항
- 데이터 보호와 보안 의무
- 해지 조건과 퇴출 비용
- 자동 갱신 함정
역할 프롬프트 작성을 비유하면, 배우에게 캐릭터 브리핑을 주는 것과 같아요. “의사 역할이야”라고만 하면 드라마마다 다른 의사가 나오지만, “10년차 응급의학과 전문의, 대형 병원, 생명 우선 판단”이라고 하면 일관된 캐릭터가 연기되죠.
3) 역할과 행동 제약 결합하기
역할은 관점을 형성해요. 제약은 구체적인 행동을 제한하죠.
제약 없이는 역할 기반 출력이 여전히 에둘러 말하거나 과도하게 설명하는 경향이 있어요. 명시적 경계를 추가하면 역할이 실행 가능해져요.
당신은 핀테크 회사의 시니어 PM입니다. 다음으로 알려져 있어요:
- 무자비한 우선순위 결정
- 데이터 기반 의사결정
- 전략에 부합하지 않는 기능 요청에 "아니오" 말하기
영업팀의 기능 요청 10개를 공유할게요.
각각에 대해:
- 우선순위 점수 (1~5)
- 한 문장 근거
- 마음을 바꾸기 위해 필요한 데이터
직접적으로 말해주세요. 평가를 부드럽게 하지 마세요.
역할은 결정 렌즈를, 제약은 모호하고 외교적인 답을 방지하고, 출력 포맷은 항목 간 비교 가능성을 강제해요.
역할+제약 결합을 비유하면, 심사위원에게 채점 기준표를 주는 것과 같아요. “좋은 발표에 투표해주세요”보다 “혁신성 30%, 실현 가능성 40%, 발표력 30%로 채점해주세요”라고 하면 일관되고 비교 가능한 평가가 나오죠.
3. 프롬프트 체이닝 실전: 복잡한 작업을 단계로 분해하기
일부 작업은 단순히 하나의 프롬프트로 잘 처리하기에 너무 복잡해요.
프롬프트가 길어지면 모델은 너무 많은 지시를 동시에 해석하고, 다른 유형의 추론을 동시에 처리하게 돼요. 답변의 정확성 대신 말만 화려한 유창함에 최적화하게 되는 거죠. 여기서 품질이 떨어지기 시작해요.
프롬프트 체이닝은 하나의 복잡한 작업을 더 작고 집중된 프롬프트들의 단계로 분할해서 이 문제를 해결해요. 각 단계에 하나의 책임이 있고, 한 단계의 출력이 다음 단계의 입력이 되죠.
1) 단일 프롬프트 vs. 프롬프트 체인: 결정 방법
작업이 한 종류의 사고를 요구하는지, 여러 종류의 사고를 요구하는지 물어보면 도움이 돼요.
| 단일 프롬프트 사용 | 프롬프트 체이닝 사용 |
|---|---|
| 작업이 명확히 정의됨 | 작업에 여러 뚜렷한 단계가 있음 |
| 한 종류의 추론 | 다른 모드: 분석, 판단, 종합 |
| 짧고 단순한 출력 | 길거나 다중 부분 출력 |
| 속도가 가장 중요 | 품질과 신뢰성이 가장 중요 |
체이닝이 긴 단일 프롬프트를 이기는 이유는, 모든 것을 묶으면 모델이 단계를 건너뛰거나, 오류를 원인까지 추적하기 어렵거나, 한 부분을 개선하면 다른 부분이 깨질 수 있기 때문이에요. 체이닝하면 각 단계에 명확한 성공 기준이 있고, 중간 출력을 검사·검증할 수 있으며, 전체를 다시 쓰지 않고 약한 단계만 반복할 수 있어요.
프롬프트 체이닝 결정을 비유하면, 이사할 때와 같아요. 원룸 이사는 혼자 한 번에 할 수 있지만, 4인 가족 이사는 “짐 분류 → 포장 → 운반 → 배치”로 나눠야 효율적이죠. 작업의 복잡도에 따라 단일인지 체이닝인지 판단하세요.
2) 기본 체이닝 패턴: 리서치 → 전략 → 실행
대부분의 체인은 이 구조를 따라요. 이해/분석 → 결정/종합 → 생산/소통.
프롬프트 1: 리서치
─────────────────
프로젝트 관리 도구의 경쟁 환경을 분석해줘.
상위 5개 플레이어와 핵심 차별화 요소를 식별해줘.
결과를 <analysis> 태그에 넣어줘.
프롬프트 2: 전략
─────────────────
아래 경쟁 분석을 기반으로:
<analysis>
{{프롬프트 1의 출력}}
</analysis>
50명 미만의 리모트 팀을 타겟하는 신규 진입자를 위한
포지셔닝 전략 3개를 추천해줘.
결과를 <strategy> 태그에 넣어줘.
프롬프트 3: 실행
─────────────────
아래 포지셔닝 전략을 기반으로:
<strategy>
{{프롬프트 2의 출력}}
</strategy>
다음을 포함한 1페이지 메시징 프레임워크를 만들어줘:
- 태그라인 옵션 3개
- 핵심 가치 제안 3개
- 상위 3개 경쟁사 비교에 대한 반론 핸들러
각 프롬프트에 하나의 역할이 있어요. 그것이 핵심이에요.
리서치→전략→실행 패턴을 비유하면, 의사의 진료 과정과 같아요. 먼저 검사(리서치), 그다음 진단(전략), 마지막으로 처방(실행). 검사 없이 처방하면 오진이 생기듯, 분석 없이 바로 실행하면 잘못된 방향으로 갈 수 있어요.
다음 편에서는 긴 컨텍스트 관리, 온도 설정, 병렬 처리 같은 고급 프롬프트 엔지니어링 기법을 살펴볼게요.
프롬프트 엔지니어링 시리즈
(4) 사고 사슬(CoT), 역할 프롬프팅, 프롬프트 체이닝