이제 질문이 아니라 작업 흐름을 설계한다
앞 장에서 우리는 좋은 프롬프트의 기본기를 배웠다. 목표를 분명히 하고, 맥락과 자료를 분리하고, 제약 조건과 출력 형식을 계약처럼 정했다. 이 정도만 해도 Claude의 답변은 눈에 띄게 좋아진다. 그러나 실무의 복잡한 일은 한 번의 요청으로 끝나지 않는다.
예를 들어 "경쟁사 분석 보고서를 써 줘"라는 요청을 생각해 보자. 이 안에는 여러 일이 섞여 있다. 자료를 읽어야 하고, 경쟁사를 분류해야 하고, 비교 기준을 정해야 하고, 표를 만들어야 하고, 우리 회사의 전략적 시사점을 뽑아야 하며, 마지막에는 임원에게 보고할 문장으로 다듬어야 한다. 이 모든 일을 한 프롬프트에 밀어 넣으면 Claude는 대체로 그럴듯한 보고서를 만든다. 문제는 그럴듯함 속에 숨어 있는 빈틈이다. 어떤 자료를 근거로 삼았는지 흐려지고, 비교 기준이 중간에 바뀌며, 초안의 문체와 결론의 강도가 어긋날 수 있다.
고급 프롬프팅의 출발점은 "더 긴 프롬프트"가 아니다. 일을 더 작은 판단 단위로 나누는 것이다. Anthropic의 프롬프트 엔지니어링 자료도 명확성, 예시, XML 구조화, 사고 유도, 프롬프트 체이닝을 Claude 활용의 핵심 기법으로 다룬다.1 여기서 프롬프트 체이닝이란 하나의 거대한 요청을 여러 단계의 요청으로 나누고, 각 단계의 산출물을 다음 단계의 입력으로 넘기는 방식이다.
이 장에서는 Claude 성능을 끌어올리는 중심축을 "미세조정"이 아니라 "운용 최적화"로 본다. 프롬프트를 개선하고, 컨텍스트를 정리하고, 호출 구조를 나누고, 결과를 평가하는 루프를 설계하는 것이다. 모델 자체를 바꾸기 전에, 모델에게 들어가는 일의 구조를 먼저 바꾼다. 이것이 Claude를 단순한 대화 상대에서 업무 시스템의 구성 요소로 바꾸는 첫걸음이다.
Prompt chaining: 한 번에 맡기지 말고 단계로 나눈다
복잡한 일을 Claude에게 한 번에 맡기면 실패 원인을 찾기 어렵다. 결과가 나빴을 때 자료 이해가 문제였는지, 분석 기준이 문제였는지, 문체가 문제였는지, 출력 형식이 문제였는지 알 수 없다. 반면 단계를 나누면 어디에서 문제가 생겼는지 보인다.
가장 실용적인 체인은 다음 흐름이다.
| 단계 | Claude에게 맡길 일 | 산출물 | 사람이 확인할 지점 |
|---|---|---|---|
| 조사 | 자료에서 관련 정보 찾기 | 근거 목록, 인용 후보, 쟁점 목록 | 빠진 자료가 있는가 |
| 분석 | 정보의 의미와 패턴 해석 | 비교표, 분류표, 리스크 목록 | 기준이 타당한가 |
| 초안 | 분석 결과를 문서로 구성 | 보고서 초안, 이메일 초안, 제안서 초안 | 독자와 목적에 맞는가 |
| 검토 | 오류, 누락, 과장 찾기 | 수정 제안, 위험 표시, 확인 질문 | 사람 검토가 필요한가 |
| 최종화 | 문체와 형식 다듬기 | 제출용 최종본 | 승인 기준을 충족하는가 |
이 흐름의 장점은 각 단계가 다른 성공 조건을 가진다는 데 있다. 조사 단계에서는 창의적인 문장이 필요 없다. 빠뜨리지 않고 근거를 찾는 것이 중요하다. 분석 단계에서는 문장을 예쁘게 쓰는 것보다 비교 기준과 판단 이유가 중요하다. 초안 단계에서는 흐름과 독자 적합성이 중요하고, 검토 단계에서는 오히려 의심이 중요하다. 최종화 단계에서는 불필요한 설명을 줄이고 제출 가능한 형태로 만드는 것이 중요하다.
하나의 프롬프트에 "자료를 읽고, 분석하고, 보고서로 쓰고, 오류도 고쳐 줘"라고 하면 Claude는 이 모든 모드를 동시에 수행해야 한다. 그러나 모드가 섞이면 답변은 흔들린다. 좋은 체인은 Claude가 한 번에 하나의 역할만 수행하게 한다.
다음은 시장 진입 보고서를 만드는 체인의 예다.
[1단계: 근거 추출]
아래 자료에서 시장 규모, 고객군, 경쟁사, 가격, 규제 리스크와 관련된 문장만 추출하라.
해석하지 말고 원문 근거와 위치만 정리하라.
출력: 근거 ID / 주제 / 원문 요약 / 출처 위치 / 신뢰도[2단계: 분석]
1단계 근거 목록을 바탕으로 시장 진입 기회를 분석하라.
근거 ID를 반드시 연결하고, 근거가 부족한 판단은 '가설'로 표시하라.
출력: 기회 / 근거 ID / 반대 근거 / 확인 필요 질문[3단계: 초안]
2단계 분석 결과를 임원 보고용 2쪽 보고서 초안으로 작성하라.
강한 결론을 먼저 제시하되, 가설과 확인 필요 항목은 숨기지 말라.[4단계: 검토]
초안을 검토하라. 과장된 주장, 근거가 약한 결론, 빠진 리스크, 독자가 물을 질문을 찾아라.
바로 고치지 말고 문제 목록을 먼저 제시하라.[5단계: 최종화]
검토 의견 중 반영할 항목을 반영해 최종본을 작성하라.
단, 확인되지 않은 수치나 사례를 새로 만들지 말라.이 체인의 핵심은 "각 단계의 출력이 다음 단계의 입력으로 쓰인다"는 점이다. 그래서 단계별 출력은 사람이 보기 좋아야 할 뿐 아니라, 다음 Claude 호출이 읽기 쉬워야 한다. 근거 ID, 라벨, 표, JSON 같은 구조가 중요해지는 이유다.
체인을 설계할 때는 단계 수를 무조건 늘리지 말아야 한다. 단계가 많아지면 품질을 통제하기 쉬워지지만, 비용과 시간이 늘어난다. 간단한 업무는 한 번의 프롬프트로 충분하다. 복잡한 업무, 실패 비용이 큰 업무, 사람이 승인해야 하는 업무, 후속 시스템에 넘겨야 하는 업무에서 체인의 가치가 커진다.
실패 지점을 줄이는 체인 설계법
프롬프트 체이닝은 단순히 요청을 쪼개는 기술이 아니다. 실패가 일어날 수 있는 지점을 미리 분리하는 기술이다. 보고서가 틀어지는 이유는 대체로 네 가지다. 자료를 잘못 읽었거나, 기준 없이 해석했거나, 초안에서 과장했거나, 검토 없이 제출했기 때문이다. 체인은 이 네 가지를 서로 다른 단계로 떼어 놓는다.
좋은 체인은 입력과 출력이 명확하다. "분석해 줘"가 아니라 "이전 단계의 근거 목록을 받아서, 각 주장마다 근거 ID를 연결한 비교표를 만들어라"라고 말한다. 그래야 Claude가 어디까지 해야 하고 어디서 멈춰야 하는지 안다.
체인 단계마다 다음 네 가지를 정하면 안정성이 높아진다.
| 설계 요소 | 질문 | 예시 |
|---|---|---|
| 입력 | 이 단계가 읽어야 할 자료는 무엇인가 | 원문 전체, 근거 목록, 이전 초안 |
| 작업 | 이 단계가 수행할 판단은 무엇인가 | 추출, 분류, 비교, 비판, 재작성 |
| 출력 | 다음 단계가 받을 산출물은 무엇인가 | 표, JSON, 체크리스트, 초안 |
| 중단 조건 | 무엇을 추측하지 말아야 하는가 | 근거 없음, 정보 부족, 정책 판단 보류 |
특히 "중단 조건"이 중요하다. Claude는 빈칸을 메우려는 경향이 있다. 초안 작성에서는 이것이 장점이지만, 근거 추출과 법무 검토에서는 위험이 된다. 그래서 단계마다 Claude가 하지 말아야 할 일을 바꿔야 한다. 조사 단계에서는 해석을 금지하고, 분석 단계에서는 근거 없는 단정을 금지하고, 초안 단계에서는 원문에 없는 수치 생성을 금지하고, 검토 단계에서는 수정본 작성보다 문제 식별을 우선하게 한다.
작업이 길어질수록 "체인 계약서"를 만들어 두는 것이 좋다. 예를 들어 팀에서 반복적으로 고객 인터뷰를 분석한다면, 매번 프롬프트를 새로 쓰지 말고 다음과 같은 체인 정의를 저장해 둔다.
<workflow name='customer_interview_analysis'>
<step id='S1' name='extract'>
목적: 인터뷰 원문에서 고객 발언과 관찰 가능한 사실을 추출한다.
금지: 해석, 추정, 제품팀 의견 추가.
출력: quote_id, speaker, quote, topic, sentiment_candidate.
</step>
<step id='S2' name='cluster'>
목적: quote_id를 유지한 채 주제별로 묶는다.
금지: quote_id 없는 주제 생성.
출력: theme_id, theme_name, quote_ids, summary.
</step>
<step id='S3' name='insight'>
목적: 주제별 시사점과 제품 기회를 도출한다.
금지: 근거 없는 우선순위 단정.
출력: insight, supporting_quote_ids, confidence, next_question.
</step>
</workflow>이런 정의는 거창한 시스템이 없어도 쓸 수 있다. Claude.ai 프로젝트 지침에 넣어도 되고, 팀 문서에 저장해도 된다. 중요한 것은 일의 방식이 매번 바뀌지 않도록 만드는 것이다.
사고 예산: 모든 일에 깊은 추론을 쓰지 않는다
Claude에게 "천천히 생각해"라고 하면 답이 좋아질 때가 있다. 하지만 항상 그런 것은 아니다. 단순 요약, 형식 변환, 짧은 이메일 작성처럼 답의 경로가 분명한 일에서는 깊은 추론이 큰 도움이 되지 않는다. 오히려 답변이 느려지고 장황해질 수 있다. 반대로 여러 제약을 동시에 만족해야 하는 기획, 복잡한 코드 디버깅, 긴 문서의 모순 찾기, 법률·정책 리스크 검토처럼 잘못된 판단의 비용이 큰 일에서는 더 많은 사고 시간이 필요하다.
API 관점에서는 이를 extended thinking, adaptive thinking, effort 같은 기능이나 설정으로 다룰 수 있다. Claude 4 계열의 확장 사고 기능은 모델이 최종 답변을 내기 전에 더 많은 추론을 수행하도록 돕고, 공식 문서는 확장 사고를 사용할 때 모델의 사고 과정을 그대로 모두 노출하기보다 요약된 형태나 최종 답변 중심으로 다루는 방식을 설명한다.2 다만 제품과 SDK 버전에 따라 구체적인 파라미터 이름, 사용 가능 모델, 반환 형식은 달라질 수 있다. 이 장에서는 문법보다 운영 원칙을 먼저 익히자.
사고 예산은 "품질을 위해 얼마의 시간과 비용을 쓸 것인가"라는 결정이다. 다음 표처럼 생각하면 쉽다.
| 작업 유형 | 권장 사고 수준 | 이유 |
|---|---|---|
| 단순 요약, 번역, 형식 변환 | 낮음 | 답의 경로가 비교적 분명하다 |
| 고객 문의 분류, 짧은 초안 작성 | 낮음~중간 | 속도와 비용이 더 중요할 수 있다 |
| 보고서 분석, 정책 비교, 코드 리뷰 | 중간~높음 | 여러 기준을 동시에 고려해야 한다 |
| 복잡한 디버깅, 아키텍처 결정, 법무 리스크 검토 | 높음 | 잘못된 결론의 비용이 크다 |
| 대규모 의사결정, 고위험 자동화 설계 | 최고 | 소수의 요청이라도 정확성이 중요하다 |
중요한 것은 "항상 최고 수준"이 아니라 "일에 맞는 수준"이다. 고객이 기다리는 챗봇 응답에 매번 깊은 사고를 쓰면 사용자 경험이 나빠진다. 하루에 수만 건 처리하는 분류 작업에 높은 사고 예산을 쓰면 비용이 급증한다. 반대로 한 달에 한 번 하는 핵심 아키텍처 결정에는 깊은 사고를 쓰는 편이 낫다. 한 번의 잘못된 설계가 몇 달의 재작업으로 돌아올 수 있기 때문이다.
채팅 환경에서는 다음처럼 명시적으로 사고 깊이를 조절할 수 있다.
빠르게 답해도 되는 작업이다.
아래 문장을 고객 안내문 톤으로 다듬어라.
추가 분석은 하지 말고 수정본만 제시하라.깊은 검토가 필요한 작업이다.
아래 정책 초안을 읽고, 먼저 이해관계자별 영향을 검토한 뒤,
모순·누락·운영 리스크를 찾아라.
최종 답변에는 검토표와 수정 제안을 포함하라.여기서 주의할 점이 있다. "생각 과정을 전부 보여 달라"가 항상 좋은 지시는 아니다. 실무에서는 내부 사고의 모든 문장을 보는 것보다, 검토 가능한 근거·가정·결론을 받는 편이 유용하다. 그러므로 "네 생각을 모두 출력해"보다 "판단 근거, 사용한 가정, 확인이 필요한 정보를 분리해 제시하라"라고 요청하는 편이 낫다.
긴 문맥은 큰 책상이지만, 어질러지면 못 찾는다
Claude의 긴 컨텍스트 창은 강력하다. 긴 보고서, 계약서 묶음, 회의록 여러 개, 코드 파일, 연구 자료를 한 번에 넣고 작업할 수 있다. Anthropic은 긴 문맥 실험에서 관련 인용문을 먼저 뽑게 하거나, 문서 내부의 다른 질문·답변 예시를 함께 주는 방식이 긴 문서에서 필요한 정보를 회상하는 데 도움이 될 수 있음을 보였다.3
하지만 긴 컨텍스트 창은 자동으로 좋은 답변을 보장하지 않는다. 큰 책상이 있다고 해서 일을 잘하는 것은 아니다. 책상 위에 계약서, 회의록, 메모, 커피잔, 포스트잇이 뒤섞여 있으면 필요한 문서를 찾기 어렵다. Claude도 마찬가지다. 긴 문맥에서는 "얼마나 많이 넣었는가"보다 "어떤 순서와 구조로 넣었는가"가 중요하다.
긴 문맥에서 자주 생기는 문제는 세 가지다.
자료가 너무 많아 핵심 근거가 묻힌다.
여러 문서의 출처와 날짜가 섞여 판단 기준이 흐려진다.
이전 대화 기록이 길어져 현재 작업과 상관없는 내용까지 영향을 준다.
그래서 긴 문맥 작업에는 컨텍스트 관리 전략이 필요하다. 기본 원칙은 "넣을 수 있다고 다 넣지 않는다"이다. Claude에게 필요한 것은 전체 데이터가 아니라, 현재 작업을 수행하는 데 충분하고 정돈된 데이터다.
문서가 길 때는 먼저 문서 목록표를 만든다. 이것을 컨텍스트 매니페스트라고 부를 수 있다.
<context_manifest>
문서 ID: DOC-001
제목: 2026년 1분기 고객지원 리포트
날짜: 2026-04-05
용도: 고객 불만 유형과 빈도 확인
우선순위: 높음
문서 ID: DOC-002
제목: 엔터프라이즈 고객 인터뷰 12건
날짜: 2026-03-18
용도: 정성적 요구사항 확인
우선순위: 높음
문서 ID: DOC-003
제목: 과거 가격 정책 변경안
날짜: 2025-11-20
용도: 과거 의사결정 배경 확인
우선순위: 중간
</context_manifest>그다음 각 문서를 태그로 감싼다.
<document id='DOC-001' type='support_report' date='2026-04-05'>
[문서 내용]
</document>
<document id='DOC-002' type='interview' date='2026-03-18'>
[문서 내용]
</document>이렇게 하면 Claude가 "이 문서"나 "앞의 내용" 같은 모호한 참조 대신 DOC-001, DOC-002처럼 분명한 식별자를 사용할 수 있다. 긴 문맥에서 출처 ID는 길잡이 표지판이다.
요약, 압축, 인덱싱, 우선순위화
긴 문맥을 다룰 때 가장 흔한 실수는 대화 기록을 계속 누적하는 것이다. 처음에는 편하다. 이전 맥락을 그대로 유지하니 이어서 말하기 쉽다. 그러나 어느 순간부터 Claude가 오래된 결정과 최신 결정을 섞기 시작한다. 이미 폐기한 요구사항을 다시 반영하거나, 초안 단계의 표현을 최종본에 되살릴 수 있다.
이때 필요한 것이 압축이다. 압축은 단순히 짧게 줄이는 것이 아니다. 다음 단계에 필요한 정보를 남기고 불필요한 정보를 버리는 작업이다. 회의 전체를 한 문단으로 요약하면 맥락은 줄지만, 담당자와 기한이 사라질 수 있다. 좋은 압축은 목적별로 다르게 해야 한다.
| 압축 방식 | 적합한 상황 | 남겨야 할 정보 |
|---|---|---|
| 요약 | 전체 흐름 파악 | 핵심 주장, 결정 사항, 쟁점 |
| 추출 | 특정 필드가 필요할 때 | 날짜, 금액, 담당자, 조건 |
| 인덱싱 | 나중에 다시 찾아야 할 때 | 문서 ID, 섹션, 키워드, 위치 |
| 우선순위화 | 정보가 너무 많을 때 | 중요도, 긴급도, 근거 강도 |
| 상태 기록 | 여러 호출을 이어갈 때 | 현재 목표, 완료 단계, 남은 질문 |
예를 들어 긴 프로젝트 대화를 다음 호출에 넘기려면 이런 형태가 좋다.
<state_summary>
현재 목표: 엔터프라이즈 고객용 보안 기능 출시 보고서 작성.
완료된 단계: 자료 추출, 경쟁사 비교, 초안 1차 작성.
확정된 결정:
- 독자는 임원과 보안 책임자다.
- 핵심 메시지는 '감사 가능성과 접근 통제 강화'다.
- 과장된 생산성 수치는 사용하지 않는다.
미해결 질문:
- 베타 고객 사례를 공개해도 되는지 법무 확인 필요.
- 가격 정책 변경 여부는 아직 미정.
다음 단계: 초안에서 근거 약한 문장을 찾아 수정한다.
</state_summary>이 요약은 단순한 대화 요약이 아니라 작업 상태의 압축본이다. Claude가 다음에 무엇을 해야 하는지 알 수 있게 한다. 특히 에이전트나 여러 호출을 이어 가는 시스템에서는 이런 상태 기록이 중요하다. 대화 전체를 계속 들고 가는 대신, 필요한 상태만 들고 가야 비용과 오류를 줄일 수 있다.
긴 문서를 분석할 때는 "먼저 관련 근거를 찾아라"라는 단계를 자주 넣는 것이 좋다. 바로 결론을 쓰게 하면 Claude가 전체 문서의 분위기에 끌려갈 수 있다. 반면 관련 문장이나 섹션을 먼저 추출하게 하면, 답변이 근거에 더 단단히 붙는다.
1단계: 아래 문서에서 '계약 해지', '데이터 보존', '책임 제한'과 관련된 조항만 추출하라.
각 조항에는 문서 ID와 섹션 번호를 붙여라.
2단계: 추출된 조항만 바탕으로 우리 회사의 리스크를 분석하라.
추출 목록에 없는 조항은 근거로 사용하지 말라.이 방식은 긴 문서에서 특히 효과적이다. Claude에게 "책 전체를 읽고 답하라"고 하는 대신, 먼저 책갈피를 만들게 하는 것이다.
Structured outputs: 형식 안정성을 시스템으로 끌어올린다
문서 초안이나 아이디어 발상은 자연어 답변으로 충분하다. 하지만 Claude의 결과를 데이터베이스에 저장하거나, 다음 워크플로우에 넘기거나, 자동 분기 로직에 사용하려면 자연어만으로는 부족하다. "대체로 JSON처럼 보이는 답변"은 운영 시스템에서 위험하다. 필드 하나가 빠지거나, 허용되지 않은 값이 들어가거나, 코드블록 설명 문장이 앞에 붙는 순간 파서가 실패할 수 있다.
Structured outputs는 Claude의 응답을 특정 스키마에 맞게 제한해, 다운스트림 처리에 필요한 파싱 가능한 출력을 얻기 위한 기능이다. 공식 한국어 문서도 구조화된 출력이 Claude의 응답을 특정 스키마를 따르도록 제한해 유효하고 파싱 가능한 출력을 보장한다고 설명한다.4
기본 아이디어는 간단하다. "JSON으로 답해 줘"라고 부탁하는 대신, 어떤 필드가 필요하고 어떤 값만 허용되는지 스키마로 정한다. 예를 들어 고객 문의를 분류한다면 다음과 같은 구조를 생각할 수 있다.
{
"category": "billing | technical | account | other",
"priority": "low | medium | high",
"confidence": 0.0,
"reason": "분류 이유",
"needs_human_review": true
}프롬프트만으로도 이런 형식을 유도할 수 있다. 그러나 운영 단계에서는 프롬프트 지시와 별도로 스키마 검증을 해야 한다. 스키마가 있어야 후속 시스템이 안전하게 동작한다. 구조화 출력의 가치는 답변이 보기 좋아지는 데 있지 않다. Claude의 답변을 소프트웨어가 믿고 처리할 수 있는 데이터에 가깝게 만드는 데 있다.
스키마를 설계할 때는 욕심을 줄이는 편이 좋다. 처음부터 깊은 중첩 구조와 수십 개의 선택 필드를 만들면 디버깅이 어려워진다. 운영에서 자주 쓰는 스키마는 단순하고 엄격한 편이 낫다.
| 설계 원칙 | 좋은 방식 | 피해야 할 방식 |
|---|---|---|
| 필드 수 | 꼭 필요한 필드부터 시작 | 나중에 쓸지도 모를 필드까지 포함 |
| 허용 값 | enum으로 분류값 고정 | 자유 텍스트로 분류값 받기 |
| 누락 처리 | null, unknown, 확인 필요를 명시 | Claude가 빈칸을 추측하게 두기 |
| 설명 필드 | reason, evidence를 분리 | 결과값만 받고 판단 근거를 잃기 |
| 검증 | 서버에서 재검증 | 모델 출력만 믿고 바로 저장 |
구조화 출력은 분류, 추출, 라우팅, 검토 기록에 특히 잘 맞는다. 고객 문의를 담당팀으로 보내거나, 계약서에서 날짜와 금액을 추출하거나, 보안 점검 결과를 위험도별로 분류하거나, 콘텐츠 검수 결과를 정책 위반 유형으로 저장하는 일에 유용하다.
다만 구조가 맞는다고 내용이 맞는 것은 아니다. JSON이 완벽하게 파싱되어도 분류가 틀릴 수 있다. 그래서 구조화 출력은 평가 루프와 함께 써야 한다. 형식 안정성은 시작일 뿐이고, 판단 정확성은 별도의 테스트셋으로 검증해야 한다. 이 부분은 9장에서 자세히 다룬다.
근거가 필요한가, 구조가 필요한가: citations와 structured outputs의 충돌
실무에서는 두 가지 욕심이 동시에 생긴다. 하나는 "근거가 보이는 답변"이고, 다른 하나는 "파싱 가능한 JSON 답변"이다. 예를 들어 계약서 분석 시스템을 만든다고 하자. 법무팀은 각 판단이 어느 조항에서 나왔는지 citation을 원한다. 개발팀은 결과를 데이터베이스에 저장하기 위해 JSON을 원한다. 둘 다 합리적이다.
문제는 기능 조합이 항상 가능한 것은 아니라는 점이다. 구조화 출력은 응답을 정해진 JSON 스키마에 맞추려 하고, citations는 답변 중간에 근거 블록을 끼워 넣어야 한다. 이 두 요구가 같은 응답 안에서 충돌하거나, 특정 SDK·모델·베타 기능 조합에서 제한될 수 있다. 관련 문서 이슈에서도 citations와 structured outputs를 함께 사용할 때 API 오류가 발생할 수 있으며, citation block이 엄격한 JSON 스키마 제약과 맞지 않는 상황이 문제로 설명된다.5
따라서 "둘은 절대 함께 쓸 수 없다"고 외우기보다, 운영 설계에서는 근거 요구와 구조화 요구의 우선순위를 먼저 정하고 현재 문서의 지원 조합을 확인한다고 이해하는 편이 안전하다. 기능 제약은 바뀔 수 있지만, 한 번의 호출에 모든 요구를 억지로 넣지 말아야 한다는 설계 원칙은 오래간다.
첫 번째 대안은 근거 우선 2단계 설계다. 1단계에서는 citation이 포함된 자연어 분석을 받는다. 2단계에서는 그 분석 결과와 근거 ID를 입력으로 넣고, 별도 호출에서 JSON으로 정리한다.
1단계: 문서 근거 찾기
- 각 리스크 판단에 관련 조항과 근거 문장을 연결한다.
- 출력은 사람이 검토할 수 있는 자연어 표로 작성한다.
2단계: 구조화
- 1단계 결과만 바탕으로 risk_id, severity, evidence_id, reviewer_note 필드를 가진 JSON을 만든다.
- 새로운 판단이나 근거를 추가하지 않는다.두 번째 대안은 증거 ID 방식이다. 실제 citation block 대신 문서 ID, 섹션 번호, 문장 ID를 JSON 필드에 넣는다. 이렇게 하면 후속 시스템이 해당 ID를 이용해 원문을 다시 표시할 수 있다.
{
"risk_id": "R-001",
"severity": "high",
"summary": "계약 해지 통지 기간이 짧아 운영 리스크가 큽니다.",
"evidence_refs": ["DOC-002#section-8.2", "DOC-002#section-8.4"],
"needs_legal_review": true
}세 번째 대안은 사용자 화면과 저장 데이터를 분리하는 것이다. 사용자에게는 근거가 달린 설명형 답변을 보여 주고, 내부 저장용으로는 별도 구조화 결과를 만든다. 화면에 보이는 답과 시스템에 저장되는 데이터가 반드시 같은 응답일 필요는 없다.
이런 기능 충돌은 앞으로도 계속 생긴다. web search, code execution, tool use, citations, structured outputs, extended thinking은 각각 강력하지만, 모든 조합이 항상 매끄럽지는 않다. 고급 사용자는 "가능한 기능 목록"보다 "기능 간 우선순위"를 먼저 정한다. 이 작업에서 가장 중요한 것은 근거인가, 형식인가, 속도인가, 비용인가, 아니면 사용자 경험인가? 답이 정해져야 설계가 정해진다.
Claude에서 튜닝 대신 무엇을 최적화할 것인가
많은 사람이 모델 성능을 높인다고 하면 곧바로 미세조정을 떠올린다. 특정 분야 데이터로 모델을 다시 훈련시키면 더 잘할 것 같기 때문이다. 하지만 Claude를 중심으로 실무 시스템을 만들 때 첫 번째 선택지는 대개 미세조정이 아니다. 프롬프트, 컨텍스트, 도구, 호출 구조, 평가를 먼저 최적화해야 한다.
왜 그럴까? 대부분의 실패는 모델이 "그 일을 전혀 몰라서"가 아니라, 필요한 맥락을 못 받았거나, 성공 조건이 모호했거나, 근거 자료가 정리되지 않았거나, 출력 형식이 느슨했거나, 평가 기준이 없어서 발생한다. 이런 문제는 모델을 다시 훈련한다고 자동으로 해결되지 않는다.
Claude 운용 최적화의 순서는 다음과 같이 잡는 것이 안전하다.
| 순서 | 최적화 대상 | 해결하는 문제 |
|---|---|---|
| 1 | 프롬프트 명확화 | 목표, 제약, 출력 형식 불명확 |
| 2 | 예시와 반례 추가 | 판단 기준 흔들림 |
| 3 | 컨텍스트 정리 | 자료 과다, 출처 혼동, 오래된 기록 영향 |
| 4 | 프롬프트 체이닝 | 복잡한 작업의 실패 지점 불명확 |
| 5 | 구조화 출력 | 파싱 실패, 후속 시스템 연동 불안정 |
| 6 | 도구와 검색 연결 | 최신 정보, 내부 데이터, 계산 필요 |
| 7 | 평가셋과 회귀 테스트 | 개선 여부를 감으로 판단 |
| 8 | 모델 라우팅과 비용 최적화 | 작업별 과도한 비용과 지연 |
이 순서를 거치면 "모델이 못한다"라고 생각했던 문제 중 상당수가 시스템 설계 문제였다는 사실이 드러난다. 예를 들어 고객 문의 분류 정확도가 낮다면 먼저 라벨 정의와 예시를 점검해야 한다. 그다음 실제 문의 데이터를 대표하는 평가셋을 만들고, 오분류 사례를 분석해 프롬프트나 스키마를 고친다. 그래도 한계가 있다면 검색, 룰 기반 필터, 사람 검토, 다른 모델과의 조합을 검토한다.
미세조정이 필요할 수 있는 경우도 있다. 매우 특수한 문체를 대량으로 생성해야 하거나, 특정 도메인의 분류 패턴을 반복적으로 학습시켜야 하거나, 지연 시간과 비용 때문에 긴 프롬프트를 매번 넣기 어려운 경우다. 그러나 Claude 중심 설계에서는 그때도 먼저 물어야 한다. "정말 모델 파라미터를 바꿔야 하는가, 아니면 컨텍스트와 평가 루프를 바꾸면 되는가?" 그리고 모델 자체를 조정해야 한다는 결론이 나면, Claude의 현재 지원 범위와 다른 플랫폼·오픈 모델 선택지를 함께 비교해야 한다.
Claude 실전 마스터리는 모델을 바꾸는 기술보다 일을 모델에게 잘 전달하고, 결과를 검증하고, 실패를 격리하는 기술에 가깝다.
실전 예제: 리서치 보고서 체인 만들기
이제 하나의 예제로 묶어 보자. 목표는 "새로운 B2B 보안 기능 출시를 위한 리서치 보고서"를 만드는 것이다. 한 번에 시키면 이런 프롬프트가 된다.
첨부한 자료를 바탕으로 B2B 보안 기능 출시 보고서를 써 줘.
경쟁사도 비교하고 고객 니즈도 분석하고 임원 보고용으로 정리해 줘.나쁜 프롬프트는 아니다. 하지만 실패 지점이 많다. 자료가 제대로 반영됐는지 알기 어렵고, 경쟁사 비교 기준도 불분명하며, 고객 니즈와 제품 메시지가 섞일 수 있다. 이제 체인으로 바꿔 보자.
<step id='1' name='evidence_extraction'>
작업: 제공 자료에서 보안 기능, 고객 요구, 경쟁사 기능, 가격·패키징, 리스크와 관련된 근거를 추출한다.
규칙: 해석하지 말고 자료에 있는 내용만 쓴다.
출력: evidence_id / source_id / topic / evidence_summary / exact_quote_or_location
</step><step id='2' name='theme_clustering'>
작업: 1단계 근거를 주제별로 묶는다.
규칙: evidence_id 없이 새 주제를 만들지 않는다.
출력: theme_id / theme_name / supporting_evidence_ids / short_summary / confidence
</step><step id='3' name='strategy_analysis'>
작업: 주제 묶음을 바탕으로 출시 메시지와 리스크를 분석한다.
규칙: 근거가 약하면 '가설'로 표시한다.
출력: recommendation / rationale / evidence_ids / risk / validation_question
</step><step id='4' name='executive_draft'>
작업: 3단계 분석을 임원 보고용 초안으로 작성한다.
규칙: 결론을 먼저 쓰되, 확인 필요 항목을 숨기지 않는다.
출력: 제목 / 5문장 요약 / 본문 / 의사결정 필요 사항
</step><step id='5' name='review_and_finalize'>
작업: 초안의 과장, 근거 부족, 누락 리스크를 점검한 뒤 최종본을 만든다.
규칙: 먼저 검토표를 제시하고, 그다음 최종본을 작성한다.
출력: 검토표 / 최종 보고서
</step>이 체인은 사람이 중간에 개입하기 쉽다. 1단계 근거 추출이 부실하면 보고서를 쓰기 전에 보완할 수 있다. 2단계 주제 묶음이 잘못되면 분석 전에 고칠 수 있다. 3단계 추천안이 과감하다면 "이 부분은 가설로 낮춰라"라고 조정할 수 있다. 최종 보고서만 보고 수정하는 것보다 훨씬 안전하다.
여기에 사고 예산을 붙이면 더 정교해진다. 1단계 추출은 낮은 사고 수준으로 빠르게 처리할 수 있다. 3단계 전략 분석과 5단계 검토는 높은 사고 수준이 필요하다. 즉, 체인 안에서도 모든 단계에 같은 모델, 같은 설정, 같은 비용을 쓰지 않아도 된다.
| 단계 | 권장 설정 감각 | 이유 |
|---|---|---|
| 근거 추출 | 빠름, 낮은 사고 | 자료 기반 필드 추출 중심 |
| 주제 묶음 | 중간 | 유사도와 분류 판단 필요 |
| 전략 분석 | 높음 | 상충 근거와 리스크 판단 필요 |
| 초안 작성 | 중간 | 구조와 문체 중심 |
| 검토·최종화 | 높음 | 오류 탐지와 책임 있는 표현 필요 |
이렇게 설계하면 Claude 사용이 "한 번 물어보고 마음에 들면 쓰는 방식"에서 "업무 파이프라인을 통제하는 방식"으로 바뀐다.
고급 프롬프트의 체크리스트
고급 프롬프팅은 복잡한 용어를 많이 아는 일이 아니다. 복잡한 일을 안전하게 나누고, 필요한 맥락만 넣고, 결과를 검증 가능한 형태로 받는 일이다. 실제 작업 전에 다음 질문을 확인하자.
| 점검 질문 | 예 / 아니오 |
|---|---|
| 이 작업은 한 번의 호출로 충분한가, 아니면 단계로 나누어야 하는가 | |
| 각 단계의 입력과 출력이 분명한가 | |
| Claude가 추측하지 말아야 할 정보가 명시되어 있는가 | |
| 긴 문서에 문서 ID, 날짜, 출처, 우선순위가 붙어 있는가 | |
| 오래된 대화 기록을 그대로 누적하지 않고 상태 요약으로 압축했는가 | |
| 빠른 응답이 중요한 단계와 깊은 추론이 필요한 단계를 구분했는가 | |
| JSON이나 표가 필요한 경우 스키마와 누락 처리 규칙을 정했는가 | |
| citations와 structured outputs처럼 충돌할 수 있는 기능 조합을 확인했는가 | |
| 최종 결과를 평가할 기준과 실패 사례를 저장할 방법이 있는가 |
이 체크리스트는 개발자에게만 필요한 것이 아니다. 비개발자도 복잡한 문서 작업, 리서치, 회의 정리, 보고서 작성에서 그대로 쓸 수 있다. 차이는 API 파라미터가 아니라 사고방식이다. Claude에게 한꺼번에 모든 것을 맡기지 않고, 일을 나누고, 근거를 남기고, 검토 지점을 만든다.
고급의 끝은 단순함이다
초보자는 Claude에게 짧게 묻는다. 조금 익숙해진 사용자는 길게 설명한다. 더 숙련된 사용자는 구조화한다. 그리고 고급 사용자는 다시 단순하게 만든다. 다만 그 단순함은 처음의 단순함과 다르다. 내부에는 단계, 상태, 근거, 스키마, 평가 기준이 숨어 있다.
좋은 Claude 시스템은 겉으로 보기에는 단순하다. 사용자는 자료를 올리고 "보고서 만들어 줘"라고 말할 수 있다. 그러나 안쪽에서는 자료 추출, 근거 정리, 분석, 초안 작성, 검토, 최종화가 나뉘어 돌아간다. 긴 문맥은 요약과 인덱스로 관리되고, 구조화 출력은 후속 시스템으로 넘어가며, 깊은 사고가 필요한 단계에만 사고 예산을 쓴다.
이 장의 핵심은 한 문장으로 정리할 수 있다.
Claude의 성능은 더 멋진 한 문장 프롬프트가 아니라, 더 좋은 작업 구조에서 나온다.다음 장부터는 이 작업 구조를 API로 구현하는 방법을 배운다. 메시지는 어떻게 구성되는지, 시스템 프롬프트는 어디에 두는지, 스트리밍과 오류 처리는 어떻게 하는지 살펴볼 것이다. 지금까지 배운 프롬프트와 컨텍스트 설계가, 이제 실제 애플리케이션의 호출 구조로 바뀐다.
참고
1Prompt engineering overview - Claude API Docs
2Building with extended thinking - Claude API Docs
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.