28. 멀티턴과 에이전트 맥락의 프롬프트

5부의 마지막 장입니다. 지금까지의 모든 기법이 여러 턴·자율적 행동이라는 가장 복잡한 맥락에서 어떻게 결합되는지 봅니다.

멀티턴 — 대화로서의 프롬프팅

단발 질문이 아니라 주고받는 대화로 작업할 때, 프롬프트는 한 번이 아니라 매 턴 쌓입니다. 15장에서 컨텍스트 관리(누적·오염·부패)를, 24장에서 체이닝을 다뤘는데, 멀티턴은 그 일상적 형태입니다.

멀티턴의 강점 — 점진적 정교화

대화의 장점은 한 번에 완벽할 필요가 없다는 것입니다. 초안을 받고 → 보고 → "더 짧게", "이 부분만 바꿔"로 다듬어 갈 수 있습니다. 이는 4장의 "반복적 개선"을 대화로 실현하는 것입니다.

턴1: "신제품 출시 이메일 초안 써줘. [정보]"
턴2: "좋아. 두 번째 문단이 너무 길어. 절반으로."
턴3: "마지막에 행동 유도 문구 추가해줘."

💡 팁: 멀티턴에서 수정 요청은 구체적으로 하세요(5장). "별로야, 다시"보다 "두 번째 문단을 절반으로, 더 친근한 톤으로"가 훨씬 효과적입니다. 모델은 무엇을 어떻게 고칠지 알아야 합니다.

멀티턴의 함정 — 15장 복습

대화가 길어지면 누적·오염·부패가 쌓입니다(15장). 특히 여러 번 수정하다 보면, 초반 지시가 묻히거나 폐기된 버전의 흔적이 남아 혼선을 줍니다. 대화가 꼬이면 새 맥락에서 현재 확정본 + 다음 요청만 들고 다시 시작하는 게 빠를 때가 많습니다.

📌 핵심: 멀티턴은 점진적 개선의 힘과 컨텍스트 누적의 위험을 동시에 가집니다. 다듬기엔 좋지만, 길어질수록 정리(압축·격리)가 필요합니다.

에이전트 — 모델이 스스로 다음 단계를 정한다

24장 끝에서 예고한 구분입니다. 체이닝에서는 사람이 단계를 미리 정합니다. 에이전트(agent)에서는 모델이 스스로 다음에 무엇을 할지 정합니다 — 어떤 도구를 쓸지, 언제 멈출지, 어떤 순서로 진행할지를 모델이 판단합니다.

flowchart TB
    subgraph CHAIN["체이닝 (사람이 흐름 설계)"]
        c1["단계1"] --> c2["단계2"] --> c3["단계3"]
    end
    subgraph AGENT["에이전트 (모델이 흐름 결정)"]
        goal["목표"] --> think["판단: 다음에 뭘?"]
        think --> act["행동 (도구 호출 등)"]
        act --> obs["결과 관찰"]
        obs --> think
        think -->|완료 판단| fin["종료"]
    end

    classDef step fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class c1,c2,c3,goal,think,act,obs step
    class fin good

에이전트는 보통 "목표 → 판단 → 행동(도구) → 결과 관찰 → 다시 판단"의 루프를 돕니다. 목표를 달성했다고 스스로 판단할 때까지 반복합니다. 코딩 에이전트, 리서치 에이전트 등이 이 형태입니다.

에이전트에서 프롬프트·컨텍스트의 역할

자율성이 커질수록, 오히려 좋은 컨텍스트 설계가 더 중요해집니다. 모델이 매 단계 올바로 판단하려면, 그 시점의 컨텍스트가 정확하고 깔끔해야 하기 때문입니다. 3부의 원칙이 여기서 정점을 찍습니다.

한 제공자가 "컨텍스트를 귀하고 유한한 자원으로 다루는 것이 신뢰할 수 있는 에이전트를 만드는 핵심"이라 한 것이 바로 이 맥락입니다(17장). 에이전트는 컨텍스트 엔지니어링의 가장 본격적인 무대입니다.

자율성이 커질수록 — 위험도 커진다

에이전트는 강력하지만, 스스로 행동하기에 위험도 큽니다. 한 단계의 환각·오판이 다음 행동으로 전파·증폭되고, 도구를 통해 실제 결과(파일 변경, 데이터 전송, 외부 호출)를 낳을 수 있습니다.

⚠️ 흔한 실수·미신: "에이전트는 알아서 다 하니 맡겨두면 된다"는 위험한 과신입니다. 자율성이 클수록 통제와 검증 장치가 더 필요합니다. 멈춤 조건, 권한 제한, 사람 승인 지점이 없으면, 작은 오판이 큰 사고로 번질 수 있습니다.

🔧 개발자 노트: 에이전트 신뢰성의 핵심 장치들 — ① 권한 최소화: 위험한 동작(삭제·전송·결제)은 사람 승인(human-in-the-loop)을 거치게, ② 멈춤·반복 한계: 무한 루프·폭주를 막는 최대 단계 수·종료 조건, ③ 컨텍스트 위생: 매 단계 필요한 것만 유지하고 누적을 압축(15·17장), ④ 단계별 검증: 도구 결과·중간 판단을 점검(20·25장), ⑤ 관찰 가능성: 에이전트의 판단·행동을 로깅해 추적. 그리고 26장에서 강조한 도구 설명의 명확성이 에이전트에서 특히 중요한데, 모델의 도구 선택이 전적으로 그 설명에 의존하기 때문입니다. 마지막으로 23장의 평가를 에이전트 전체 궤적(trajectory) 수준에서 수행해, 자율 동작이 의도대로인지 측정하세요.

일반 사용자에게 주는 함의

대부분의 사용자는 에이전트를 직접 만들지 않지만, 코딩 에이전트·리서치 에이전트 등을 사용합니다. 그때 알아두면 좋은 것:

• 에이전트에게도 목표와 제약을 명확히 주세요(5·10장). 자율적이라고 모호해도 되는 게 아닙니다 — 오히려 더 명확해야 폭주를 막습니다.
• 자율 작업의 결과를 검증하세요(20장). 에이전트가 여러 단계를 거쳤다고 다 맞는 건 아닙니다.
• 위험한 작업은 승인 지점을 확인하세요. 무엇을 자동으로 하고 무엇에 허락을 받는지.

🧪 직접 검증법: 에이전트형 도구를 쓸 때, 작은·저위험 작업으로 먼저 시험해 어떻게 판단하고 어디서 멈추는지 관찰하세요. 그 행동 패턴을 이해한 뒤에 큰 작업을 맡기세요. 처음부터 고위험 작업을 통째로 맡기는 것은, 검증되지 않은 자동화에 베팅하는 것입니다.

이 장에서 배운 것

• 멀티턴은 점진적 개선의 힘(반복 다듬기)과 컨텍스트 누적의 위험(15장)을 동시에 가진다. 수정은 구체적으로 하고, 꼬이면 정리·재시작한다.
• 에이전트는 모델이 스스로 다음 단계를 정하는 형태로, "목표→판단→행동→관찰" 루프를 돈다. 체이닝(사람이 흐름 설계)과 구분된다.
• 자율성이 커질수록 좋은 컨텍스트 설계가 더 중요하다. 압축·select·시스템 프롬프트·검증 등 3·4부 원칙이 정점에서 결합된다.
• 자율성은 위험도 키운다 — 오판이 전파·증폭되고 실제 결과를 낳는다. 권한 최소화·멈춤 조건·검증·사람 승인이 필요하다.
• 에이전트를 쓰는 사용자도 목표·제약을 명확히 주고, 결과를 검증하고, 승인 지점을 확인하고, 저위험으로 먼저 시험해야 한다.

✍️ 확인 문제

1. 체이닝과 에이전트의 핵심 차이를 한 문장으로 말하고, 각각이 더 적합한 상황을 하나씩 들어보세요.

1. "에이전트는 자율적이니 목표만 대충 주면 알아서 잘한다"는 주장을, 폭주 위험과 모호함(5장) 관점에서 비판해보세요.

1. (실습) 리서치 에이전트에게 "경쟁사 동향을 조사해 요약" 작업을 맡긴다고 할 때, 폭주·환각을 막기 위해 어떤 제약·검증·승인 장치를 둘지 설계해보세요.

다음 → 6부 · 실무 적용과 운영 (작성 예정)
이전 ← 27. 시스템 프롬프트 설계 · 목차