생각해 볼 문제 참고 답안

이 파일은 이 책의 열 개 장에 수록된 생각해 볼 문제에 대한 참고 답안의 개요를 모았습니다. 대부분은 열린 문제라서 하나의 정답이 없습니다. 참고 답안은 AI가 생성하고 사람이 가볍게 검토했으며, 독자가 비교하고 발상을 얻는 용도로만 제공합니다. 독자 여러분도 LLM과 책의 내용을 함께 활용하여 이 문제들을 더 깊이 논의해 보기를 권합니다.

1장: AI 에이전트 시작하기

1. (★★) 에이전트 시스템에 한 가지 능력만 더할 수 있다면 더 강력한 모델, 더 풍부한 컨텍스트, 더 많은 도구 중 무엇을 선택하시겠습니까? 어떤 조건에서 선택이 달라질까요?

‘뇌/눈/손발’ 공식에 따라 먼저 약한 고리를 찾습니다. 일반적으로는 컨텍스트를 보강하여 관측 공간을 넓히는 일을 우선합니다. 업무가 모델의 사고 능력을 넘어서면 더 강력한 모델로 바꿉니다. 행동 공간이 부족하다면(예: 사내 시스템에 접근할 수 없음) 도구를 추가합니다. 실패 궤적을 분석하여 병목이 지각, 의사 결정, 행동 가운데 어디에 있는지 찾으면 판단할 수 있습니다.

2. (★★★) ReAct 루프에서 라운드마다 비슷한 양의 기록이 추가되고 접두부 캐시를 재사용하지 않은 채 매번 전체 과거 궤적을 다시 처리하면, 누적 입력 토큰 처리량이 대략 제곱으로 증가합니다. 캐시와 과금 방식에 따라 실제 비용은 달라질 수 있습니다. 중요한 정보를 잃지 않으면서 이 증가를 줄일 수 있을까요?

가능한 접근법은 다음과 같습니다. 컨텍스트 압축은 초기 궤적을 요약하여 결론과 핵심 상태만 남깁니다(2장의 다층 압축). 외부화 학습은 중간 결과를 파일이나 지식 베이스에 쓰고 컨텍스트에 계속 두는 대신 필요할 때 검색합니다. 업무를 하위 에이전트로 나눌 수도 있습니다.

3. (★★) ‘모델이 곧 에이전트’라는 패러다임은 도구 호출을 결정할 때 모델이 점점 더 자율적이 된다는 뜻입니다. 하지만 이 장에서는 하네스(harness) 엔지니어링이 오히려 더 중요해진다고 주장합니다. 두 흐름은 어떻게 공존할 수 있을까요? 앞으로 에이전트 프레임워크의 핵심 가치는 어디에 있을까요?

말과 고삐에 비유할 수 있습니다. 모델이 강해지고 자율성이 커질수록 실수가 미치는 범위도 넓어지므로 제약, 검증, 수정이 더 필요해집니다. 프레임워크의 가치는 ‘LLM 호출 오케스트레이션’에서 하네스의 다섯 요소를 아우르는 보증 계층, 즉 권한 분류, 회로 차단기, 오류 복구, 컨텍스트 압축, 도구 생태계로 이동합니다.

4. (★★) 제거 실험에서는 ‘도구 결과 피드백’이 없자 에이전트가 무한 루프에 빠졌습니다. 프로덕션 환경에서는 도구 결과 누락 외에 어떤 상황이 에이전트의 루프를 유발할 수 있을까요? 어떤 감지·종료 메커니즘을 설계하시겠습니까?

다른 원인으로는 도구가 같은 오류를 반복해서 반환하는 상황, 존재하지 않는 도구를 환각하여 호출하는 상황, 컨텍스트 압축에서 핵심 상태가 빠지는 상황, 사고 내용이 제거되어 모델 API가 오류를 내는 상황, 업무 자체에 해법이 없는 상황이 있습니다. 최대 반복 횟수 같은 중단 조건을 설정하고, 같은 도구와 인수 지문으로 이루어진 반복 호출을 감지하며, 실패 임곗값을 넘으면 사람의 개입으로 에스컬레이션하십시오.

5. (★) 이 장은 작동 컨텍스트, 행동 인터페이스, 전략이라는 세 차원에서 에이전트 제품 다섯 개를 분석했습니다. 매일 사용하는 AI 제품 하나를 같은 세 차원에서 분석하고 아키텍처가 적절한지 판단해 보십시오. 직접 설계한다면 무엇을 개선하시겠습니까?

열린 문제입니다. 이 장의 표를 따라 눈(볼 수 있는 정보 원천), 손발(행동 공간이 열려 있는지, 내부적으로 사고할 수 있는지), 전략(에이전트 실행 루프의 패턴)을 적는 것이 핵심입니다.

6. (★★) 항공권 예약 전용 고객 서비스 시스템을 설계한다면 워크플로 패턴과 자율 에이전트 패턴 중 무엇을 선택하시겠습니까? 한 시스템에서 두 패턴을 섞을 수 있을까요?

워크플로를 골격으로 사용합니다. 본인 확인 → 검색 → 결제 → 예약의 네 노드로 ‘결제 전에 예약할 수 없음’ 같은 규정 준수 순서를 보장하고 프롬프트 인젝션 공격 표면을 한 노드 안으로 제한합니다. 열린 구간(요구 파악, 예약 변경, 항공편 취소 시 대안 추천)에서는 자율 에이전트로 전환합니다. 고위험 작업(고액 결제, 환불)에는 사람의 확인을 추가합니다.

7. (★★★) 가드레일 절에서는 도구 위험도 평가를 언급했습니다. 도구가 일반적으로는 저위험이지만 특정 매개변수 조합에서 고위험이 된다면(예: delete_file로 일반 파일 삭제와 시스템 파일 삭제) 동적 위험 평가를 어떻게 설계하시겠습니까?

평가 대상을 ‘도구’에서 ‘도구 + 인수’로 세분화하고 호출 시점에 가역성, 권한, 영향 범위를 기준으로 위험을 계산합니다. 모델 판단 대신 경로 허용 목록·차단 목록과 정규식 같은 규칙 기반 결정론적 검사를 사용합니다. 프롬프트 인젝션 조작을 막도록 검증은 구조화된 데이터만 살펴야 합니다.

8. (★★) 이 장의 에이전트 제품 표에서는 모든 에이전트의 행동 공간이 ‘개방형’이었습니다. 미리 정의된 선택지에서만 고를 수 있는 제한된 행동 공간이 개방형보다 나은 상황은 언제일까요?

규정 준수가 중요하고 위험이 높으며 오류를 되돌릴 수 없는 상황입니다. 환불과 결제에서 제한된 선택지는 곧 ‘제약’이므로 설계상 오류가 발생할 수 없도록 본질적으로 실수를 방지합니다.

9. (★★) 인간 참여형 개입 메커니즘에서는 에이전트가 ‘우아하게 제어권을 넘겨야’ 합니다. 하지만 실제로 사용자가 오프라인이거나 답변이 늦거나 모호한 지시를 할 수 있습니다. 이때 에이전트는 어떻게 해야 할까요?

안전 실패 원칙을 따릅니다. 확인이 오지 않으면 기본적으로 실행하지 말고 고위험 작업을 멈춥니다. 가역적이고 저위험인 부분을 먼저 처리하고 고위험 부분을 문서화하여 사람이 결정하면 에이전트가 재개할 수 있게 합니다. 시간 제한 정책과 함께 메시지·이메일 같은 비동기 통신 도구로 알리고, 지시가 모호하면 의도를 명확히 합니다.

10. (★★★) 들어가며에서는 ‘좋은 설계 원칙은 모델의 반복 주기를 넘어 살아남아야 한다’고 말하지만, 그 원칙을 구현하는 구체적인 엔지니어링 수단은 모델 능력이 발전하면서 낡을 수 있습니다. 그런 에이전트 엔지니어링 수단을 하나 들고 그 이유를 설명해 보십시오.

예시 1: 제약 샘플링으로 도구 호출을 엄격한 형식에 맞추도록 강제하는 방식입니다. 잘못된 JSON을 출력하거나 파라미터를 빠뜨리는 모델을 위한 신뢰성 보완책입니다. 모델의 형식 준수 능력이 높아지면 효용이 줄 수 있지만, 고위험 시나리오에서는 결정론적인 형식 검증을 계속 유지해야 합니다.

예시 2: 모델이 새로운 지식을 지속적으로 흡수하지 못하는 문제를 보완하기 위해 외부 지식 베이스를 도입하는 방식입니다. 모델이 미래에 신뢰할 수 있는 지속 학습 능력을 갖추면 지식 관리의 일부가 외부 시스템에서 모델 파라미터로 이동할 수 있습니다. 다만 외부 지식 베이스는 실시간 갱신, 정확한 검색, 접근 제어, 출처 추적에서 독립적인 가치가 있으므로 완전히 사라지기보다는 적용 범위가 줄어들 가능성이 큽니다.

예시 3: 모든 능력을 모델 API의 표준 도구 호출 인터페이스로만 노출하고 사용자 정의 호출 형식을 금지하는 방식입니다. Skills는 다른 경로를 보여 줍니다. 능력과 사용법을 텍스트로 설명하고 모델이 범용 명령줄 도구를 통해 실행하게 합니다. 모델의 관점에서는 범용 실행기 위에 놓인 사용자 정의 텍스트 호출 프로토콜을 이해하고 따르는 것과 같습니다. 모델이 임의의 인터페이스를 이해하는 능력이 높아지면 “항상 표준 도구 호출 형식을 사용해야 한다”는 더 이상 보편적인 원칙이 아닙니다. 표준 형식은 상호 운용성, 구조화된 검증, 능력이 낮은 모델에는 여전히 유용하지만 상황에 따라 선택하는 엔지니어링 수단이어야 합니다.

예시 4: 프롬프트와 모든 도구 정의를 미리 컨텍스트 맨 앞에 두도록 요구하는 방식입니다. 초기 모델은 지시 이행 능력이 제한적이어서 익숙한 고정 위치를 벗어난 프롬프트나 도구 정의를 제대로 인식하고 실행하지 못하는 경우가 많았습니다. Skills는 실행 중 필요에 따라 프롬프트를 컨텍스트 중간에 불러오고, 동적 도구 탐색은 새로 발견한 도구 정의를 기존 궤적 뒤에 추가합니다. 지시 이행 능력이 높아지고 모델이 이런 동적 로딩 방식을 위한 전용 사후 학습을 받으면 프롬프트와 도구 정의를 더 이상 컨텍스트 맨 앞에 고정할 필요가 없습니다.

2장: 컨텍스트 엔지니어링

1. (★★★) 실험 2-3에서는 대화 기록에 슬라이딩 윈도를 사용하면 에이전트가 같은 도구 호출을 반복한다는 사실을 발견했습니다. 하지만 전체 기록을 보존하면 컨텍스트가 무한히 커집니다. KV Cache 접두부를 깨뜨리지 않으면서 정보 손실을 피하고 컨텍스트 길이를 통제할 전략을 설계해 보십시오.

① 폐기 대신 압축합니다. 메시지는 삭제하거나 편집하지 않고 추가만 하며 임곗값(예: 창의 80%)에 가까워지면 오래된 도구 결과를 일괄 압축합니다. ② 계층형 메커니즘을 사용합니다. 큰 출력은 디스크에 영속화하고 요약만 남기며, 잡음은 완전히 삭제하고 대화 흐름을 보존하는 보관 요약을 유지합니다. ③ 하위 에이전트를 격리하여 중간 상태가 주 컨텍스트에 들어오지 않게 합니다.

2. (★★) Qwen3의 Chat Template 사고 사슬 유지 메커니즘은 ‘마지막 실제 사용자 메시지 이후’의 사고 내용만 유지합니다. ReAct 루프가 수백 번의 도구 호출에 걸치면 누적된 사고 내용이 컨텍스트를 많이 차지할 수 있습니다. 매우 긴 루프에 맞게 이 메커니즘을 어떻게 바꾸시겠습니까? DeepSeek R1은 한때 과거의 모든 사고 내용을 제거하도록 요구했지만 DeepSeek V4는 반대로 모든 reasoning_content를 돌려주도록 의무화했습니다. 상반된 두 전략의 장단점은 무엇이며, 이러한 반전은 무엇을 시사합니까?

수정 방향은 슬라이딩 윈도 유지입니다. 최근 몇 라운드의 사고는 그대로 보존하고 창 밖에서는 고정된 라운드 수가 아니라 토큰 예산에 따라 롤링 압축을 실행하여 구조화된 상태 표시줄(현재 목표, 확인된 사실, 배제한 경로, 할 일)을 만듭니다. 압축은 고정 위치에서 한 번만 수행하므로 매 라운드가 아니라 한 번만 캐시 재구축 비용을 냅니다. R1의 제거 방식은 토큰을 절약하고 접두부를 안정적으로 유지하여 캐시에 유리하며 과거 CoT가 입력에 나타나지 않는 학습 분포와 일치합니다. 하지만 매 라운드 처음부터 사고하므로 장기 계획을 잃고 실수를 반복합니다. V4의 의무 반환 방식은 사고의 일관성을 유지하고 장기 에이전트 업무 성능을 높이지만 토큰 비용이 크고 매 라운드 접두부가 비대해지며 비사고 모드에서 매끄럽게 전환할 수 없습니다. 이 반전은 순수 대화에서는 사고가 낭비지만 에이전트 상황에서는 사고가 상태이며, 업계가 후자 쪽으로 이동했음을 보여 줍니다.

3. (★★) 컨텍스트 인식 압축 실험에서는 약 14만 8천 자를 약 2천 자로 압축했습니다. 이렇게 극단적으로 압축하면 ‘되돌릴 수 없는 정보 손실’ 위험이 있지 않을까요? 어떻게 대응할 수 있을까요?

위험이 있습니다. 압축은 손실 투영이므로 질문이 보존하지 않은 차원을 겨냥하면 실패합니다. 해법은 ‘손실 압축 + 무손실 색인’입니다. 모든 사실에 추적 가능한 출처 URL을 붙이고 원시 출력은 디스크에 저장한 채 컨텍스트에는 요약 미리보기만 둡니다. 아키텍처 결정, 의미 무결성(시간, 회사명), 검증 상태, UUID·해시 같은 식별자를 명시적 보존 우선순위로 삼아 그대로 유지합니다. 적응형 윈도잉으로 압축 시점도 늦춥니다.

4. (★★) 에이전트 상태 표시줄은 암묵적인 상태를 명시적으로 만듭니다. 하지만 상태 표시줄 자체에 잘못된 정보가 있다면(예: 도구 카운터의 버그) 에이전트가 그 정보를 바탕으로 해로운 결정을 내릴 수 있습니다. 이 ‘메타정보 신뢰성’ 문제를 어떻게 줄일 수 있을까요?

모델은 상태 표시줄을 거의 무조건 신뢰하므로 오류가 그대로 전파됩니다. 대응책은 다음과 같습니다. ① 결정론적 코드로 유지하고 LLM이 긴 기록을 한꺼번에 세지 않게 합니다. 꼭 필요하다면 항목별로 추출하고 코드로 합산합니다. ② 상태 표시줄 정확도를 일급 프로덕션 지표로 추적합니다. ③ 실제 세계의 신뢰할 수 있는 관찰에서만 정보를 가져와 상태 표시줄 오염을 막습니다.

5. (★★) 프롬프트 엔지니어링 제거 실험에서는 정보가 무질서하면 성공률이 30% 넘게 떨어졌습니다. 하지만 실제 개발에서는 여러 사람이 서로 다른 시점에 시스템 프롬프트를 관리하는 일이 많습니다. 시스템 프롬프트가 시간이 흐를수록 무질서해지지 않게 하려면 어떤 엔지니어링 관행을 사용하시겠습니까?

① 프롬프트를 코드처럼 다룹니다. 버전 관리와 검토를 적용하고 제품 관리자가 비즈니스 규칙을 정의하며 엔지니어가 인코딩합니다. ② Tau-Bench 방식의 벤치마크를 회귀 테스트로 삼고 변경 전후에 제거 실험을 실행하여 영향을 찾습니다. ③ 구조를 강제합니다. 규칙을 쌓아 두는 대신 SOP 주도 흐름을 사용하고 XML/Markdown으로 계층화합니다. ④ 조각을 ‘캐시 가능/캐시 파괴’로 분류하고 이름을 붙여 동적 내용을 캐시 경계 뒤에 배치합니다. ⑤ 비대해진 내용은 필요할 때 불러오는 스킬로 나눕니다.

6. (★★★) 이 장에서는 ‘컨텍스트 내 학습의 본질은 사고가 아니라 검색이다’라고 제안합니다. 이 주장이 맞다면 ‘컨텍스트에 더 많은 정보를 넣는’ 현재의 모든 최적화 방향을 다시 평가해야 합니다. 이 한계를 어떻게 극복해야 한다고 생각하십니까?

이 ‘검색 엔진의 절반’에 증류 계층을 추가합니다. ① 컨텍스트 증류/상태 표시줄로 코드가 결론을 미리 계산하여 바로 검색하게 합니다. ② 능동적 압축으로 원시 기록을 고밀도 구조화 지식으로 바꿉니다. ③ 하위 에이전트를 격리하여 잡음이 주 컨텍스트에 들어오지 않게 합니다. ④ 상호 작용을 세 번째 축으로 삼아 외부 장치가 모델이 생각해 낼 수 없었던 새 정보를 관찰하고 되써 넣게 합니다. ⑤ 편집·조합 가능한 KV Cache ‘메모’와 세션 간 기억 통합 같은 최전선 방향을 탐구합니다.

7. (★★★) 스킬의 점진적 공개는 에이전트가 필요하다고 판단할 때만 전체 내용을 불러옵니다. 하지만 이 판단 자체가 모델의 능력에 의존합니다. 모델이 자신이 무엇을 모르는지 모르면 스킬 로딩을 제대로 실행할 수 없습니다. 이 ‘메타인지’ 문제를 어떻게 해결할 수 있을까요?

① 스킬 메타데이터(이름, 설명)를 컨텍스트에 상주시켜 모델이 항상 ‘자신에게 무엇이 있는지’ 알게 합니다. ② 스킬 설명을 기능 소개가 아니라 “Use when / Don’t use when” 같은 라우팅 조건으로 작성하여 모호한 설명을 피합니다.

8. (★★) 스킬 메커니즘에서 에이전트가 SKILL.md의 지침을 동적으로 불러온 뒤 후속 작업에서 이를 안정적으로 따를 수 있을까요? 스킬 패턴에 대한 모델별 지원에는 어떤 차이가 있습니까?

스킬을 주입하는 방식에 따라 다릅니다. 시스템 프롬프트에 주입하면 지시 이행은 가장 강하지만 KV Cache가 깨집니다. 일반 파일처럼 읽어 컨텍스트 중간에 두면 지시 이행이 약할 수 있습니다. 컨텍스트 끝에 주입하면 잘 따르지만 도구를 호출할 때마다 스킬 부분의 KV를 다시 계산해야 해서 비용이 큽니다.

9. (★★★) 이 장에서는 시스템 타임스탬프나 도구 목록 순서 같은 동적 정보가 바뀌면 KV Cache 접두부 적중이 깨질 수 있다고 강조합니다. 도구가 많고 도구 집합이 자주 바뀌는 프로덕션 시스템에서 캐시 적중률을 극대화하려면 컨텍스트 레이아웃을 어떻게 설계하시겠습니까?

① 안정적인 소수 핵심 도구(예: 일곱 개)와 범용 실행기를 두고 구체적인 능력은 스킬의 점진적 공개로 제공합니다. 도구 정의는 고정된 순서로 정적 접두부에 고정합니다. ② 하위 에이전트가 부모 에이전트와 같은 접두부를 유지하게 합니다.

3장: 사용자 메모리와 지식 베이스

1. (★★) 사용자 메모리 시스템에서 같은 사용자가 서로 다른 세션에 모순되는 정보(예: 서로 다른 집 주소 두 개)를 제공하면 메모리 시스템은 이 충돌을 어떻게 처리해야 할까요?

Mem0 방식의 ‘추출-비교-결정’ 파이프라인을 사용합니다. 먼저 벡터 검색으로 비슷한 과거 기억을 찾은 뒤 LLM이 ADD/UPDATE/DELETE/NOOP을 결정하게 합니다. 예를 들어 ‘Shanghai로 이사함’은 ‘Beijing에 거주함’을 UPDATE하여 덮어써야 합니다. 버전 관리 측면에서는 주소 유형 정보는 타임스탬프와 함께 최신 버전만 유지하되 경력 유형 정보는 전체 이력을 보존합니다. 검색에서는 컨텍스트 접두부(사람, 시간, 의도—세 번 수정된 계좌 이체 사례처럼)를 활용해 어느 항목이 최종적으로 유효한지 판단할 수 있습니다.

2. (★★) Contextual Retrieval은 각 청크에 원문 문서의 컨텍스트를 추가합니다. 하지만 원문 문서 자체의 구조가 어수선하거나 모순된 정보가 있다면 이 방식이 오류를 전파하거나 증폭할 수 있습니다. 검색 단계에 ‘정보 품질’ 신호를 어떻게 도입하시겠습니까?

‘지식 베이스 최신성·거버넌스’에서 방법을 빌립니다. 청크에 버전 번호, 유효·만료 시각, 출처 같은 메타데이터를 붙입니다. 검색할 때 만료된 내용을 걸러 내거나 접두부에 ‘이 항목은 특정 날짜에 폐지됨’을 명시합니다. 재순위화 단계에서는 의미 관련성만 보지 말고 출처의 권위와 시간적 최신성을 점수에 반영합니다. 색인할 때 접두부 생성 LLM이 기억의 버전 기반 충돌 감지처럼 청크 간 모순도 감지하여 표시하게 합니다.

3. (★★★) Agentic RAG에서는 에이전트가 검색할 시점과 검색 대상, 검색 지속 여부를 능동적으로 결정합니다. 하지만 모델이 자신이 무엇을 모르는지 모르면 검색을 제대로 시작할 수 없습니다. 이 ‘메타인지’ 문제를 어떻게 해결할 수 있을까요?

① “정보가 충분한지 평가하라”를 프롬프트/스킬의 명시적 단계로 하드코딩합니다. 실험 3-9처럼 먼저 하위 질문을 병렬로 검색하고 ‘과실범의 양형에 전과가 어떤 영향을 미치는가’라는 빠진 연결 고리를 발견한 뒤 2차 검색을 실행합니다. ② JSON Cards 개요나 OpenViking의 L0/L1 요약 같은 가벼운 메타정보를 컨텍스트에 상주시켜 전체적인 시야를 제공합니다. 그러면 에이전트가 ‘저장소에 무엇이 있는지’ 알 수 있습니다.

4. (★★) 멀티모달 정보 추출은 검색하기 전에 차트를 텍스트 설명으로 변환합니다. 이 ‘번역’ 과정에서 시각 정보의 공간 관계가 손실될 수 있습니다. 순수 텍스트 설명으로 완전히 전달할 수 없는 차트 정보의 구체적인 예를 들고 그 정보를 보존할 방안을 설계해 보십시오.

시스템 아키텍처 다이어그램의 논리 관계, 선 그래프에서 두 곡선이 교차하는 위치, PDF 표에서 셀과 머리글의 행·열 대응이 예입니다. 첫 번째 방안은 네이티브 멀티모달 처리이고 두 번째는 멀티모달 이미지 분석 도구를 제공하는 것입니다.

5. (★★★) Rich Sutton의 ‘Bitter Lesson’은 일반적인 방법(검색과 학습)이 결국 사람이 만든 특징보다 우수해진다고 주장합니다. 이 장에서 만든 전체 지식 시스템(청킹 전략, 색인 구조, 검색 파이프라인)도 일종의 ‘수작업 설계’일까요? 모델 능력이 충분히 강해지면 단순히 ‘모든 것을 입력하는’ 방식으로 이 설계를 대체할 수 있을까요?

수작업 설계가 맞으며 컨텍스트가 길어질수록 일부 단계(청킹, 융합 튜닝)의 중요성은 줄 수 있습니다. 하지만 검은 고양이/흰 고양이 사례는 ‘모든 것을 입력하는’ 것만으로도 부족함을 보여 줍니다. 어텐션은 소프트 검색이므로 문서 간 집계와 통계에는 여전히 색인 시점의 사전 증류가 필요합니다. 지식 만료와 갱신, 권한·테넌트 격리, 감사 가능성, 비용 같은 엔지니어링 제약은 모델 능력과 무관합니다. 색인 시점의 검색 + LLM 증류 자체도 일반적인 ‘검색 + 학습’ 방법이므로 Bitter Lesson과 대립하지 않습니다.

6. (★★★) 모델 능력이 향상되더라도 도메인별 지식 베이스가 계속 중요할까요? 미래의 강력한 기반 모델이 도메인 지식 베이스의 모든 정보를 담아 지식 베이스가 필요 없어질 수 있을까요?

여전히 중요합니다. 학습 데이터에는 마감 시점이 있지만 지식 베이스는 언제든 갱신할 수 있습니다. 사내 프로세스나 비공개 판례 등은 애초에 공개 말뭉치에 없습니다. 여러 사용자가 공유하려면 권한 필터링과 테넌트 격리가 필요하며 매개변수 속 지식은 호출자별로 맞출 수 없습니다. 외부 저장소는 감사와 버전 관리가 가능하고 만료된 내용을 내릴 수 있지만 매개변수 기억으로는 거의 불가능합니다. 매개변수 경로(사후 학습 / User as Engram)를 택해도 ‘기억은 쉽지만 그 사실을 다중 홉 사고에 활용하기는 어렵다’는 문제를 마주합니다.

7. (★) RAPTOR는 상향식 계층 요약으로 트리 색인을 만들고 GraphRAG는 개체 관계로 그래프 구조 색인을 만듭니다. 두 구조화 색인은 각각 어떤 유형의 질의에 잘 답할까요?

RAPTOR는 거시 개념에서 세부 사항으로 내려가는 ‘계층 간 탐색’ 질의에 적합합니다. 예를 들어 먼저 ‘SIMD 명령어 집합’ 요약을 찾은 뒤 SSE 세부 사항으로 내려가 개요와 세부 수준을 모두 다룹니다. GraphRAG는 다중 홉 관계 사고(‘내 의사가 근무하는 병원의 주소’처럼 관계 사슬을 탐색), 개체 중의성 해소(동명이인인 두 ‘Dr. Zhang’이 서로 다른 노드), ‘A와 B의 관계는 무엇인가’ 유형의 질의에 적합합니다. 커뮤니티 요약은 주제별 군집도 제공합니다.

8. (★★) 파일 시스템 패러다임은 파일 시스템처럼 계층 구조로 지식을 조직합니다. 전통적인 벡터 데이터베이스 RAG와 비교할 때 어떤 상황에서 이 접근법이 유리할까요?

일반 텍스트는 사용자가 직접 읽고 편집하고 수정할 수 있으며 Git으로 버전을 관리하고 롤백할 수 있어 사람과 기계가 함께 지식을 유지·검토하는 상황에 적합합니다. write_file 능력이 있으면 에이전트가 경험을 자율적으로 기록하여 자기 진화 기억 주기(외부화 학습)를 만들 수 있습니다. L0/L1/L2 점진적 공개에서는 대부분의 질의를 L1에서 판단할 수 있어 토큰을 절약합니다. 단, Wikipedia처럼 교차 링크와 색인 페이지를 만들어야 합니다. 그렇지 않으면 고립된 파일이 많을수록 검색이 더 어려워집니다.

9. (★★★) 구조화된 데이터(예: 사법 판결 데이터베이스)에서 ‘판단 요인’과 ‘요인 중요도 계층’을 자동 발견하는 일은 본질적으로 에이전트가 데이터에서 규칙을 귀납하는 것입니다. 데이터 주도 지식 추출이 사람이 만든 전문가 규칙과 같은 수준의 품질을 달성할 수 있을까요?

장점은 CAIL2018 실험처럼 ‘상향식’ 요인 발견이 사람의 선입견이 아니라 데이터에 맞고, 전문가가 명시적으로 적기 어려운 수만 건의 판결에 흩어진 암묵적인 절충 경험을 포착하며, 정량화할 수 있다는 점입니다. 한계는 LLM 추출 오류가 지식을 오염시키고 데이터 자체의 편향을 물려받으며 군집 프로토타입은 상관관계만 반영할 뿐 인과관계를 설명하지 못한다는 점입니다. 절충안은 데이터 주도 모델링에 전문가의 스키마·결과 검토를 결합하는 것입니다. 모델이 질문을 이끌고 통계가 설명을 뒷받침합니다.

4장: 도구

1. (★★) MCP 표준은 도구 정의를 에이전트 프레임워크에서 분리합니다. 하지만 표준화 때문에 스트리밍 출력, 양방향 통신, 상태 유지 세션 같은 복잡한 도구 상호 작용 패턴을 표준 프로토콜 안에서 표현하기 어려울 수 있습니다. 앞으로 MCP가 가장 확장해야 할 능력은 무엇이라고 생각하십니까?

가장 필요한 확장은 세션 간 이벤트 기반 능력입니다. MCP는 이미 여러 차례의 상호작용, 변경 구독, 장기 실행 작업을 지원하지만, 핵심은 에이전트를 계속 온라인 상태로 유지하는 것이 아니라 능력 호출을 표준화하는 데 있습니다. 새 이메일이나 외부 콜백으로 에이전트를 깨우고, 여러 이벤트를 대기열에 넣어 재개하고 재시도하는 일은 여전히 에이전트 프레임워크의 역할입니다. 이러한 오케스트레이션을 위한 더 통일된 규약이 마련되면 프로토콜의 단순성을 해치지 않으면서 MCP의 적용 범위를 넓힐 수 있습니다.

2. (★★) 비동기 에이전트 아키텍처에서는 이벤트 큐의 우선순위 전략을 설계 시점에 정해야 합니다. 하지만 새 메시지가 현재 업무보다 급한지 판단하는 것처럼 우선순위 판단 자체에 의미 이해가 필요하다면 누가 판단해야 할까요? 규칙 엔진일까요, 또 다른 LLM 호출일까요? 각각의 비용은 무엇입니까?

계층형 하이브리드가 적절합니다. 유형이 명확한 이벤트는 규칙으로 하드코딩합니다. 지연 시간이 없고 결정성이 강하지만 ‘당장 멈춰’와 ‘오늘 날씨는 어때?’의 의미 차이는 이해하지 못합니다. 의미가 모호한 이벤트는 이벤트 라우터 역할을 하는 경량 분류 LLM에 보냅니다. 수백 밀리초의 지연, 추가 비용, 오판 가능성이 따르며 Sidecar와 마찬가지로 프롬프트 인젝션을 막도록 구조화된 필드만 읽어야 합니다.

3. (★★) MCP 생태계에서는 서로 다른 MCP 서버가 기능이 크게 겹치는 도구를 제공할 수 있습니다. 출처는 다르지만 기능이 비슷한 도구가 여러 개일 때 에이전트는 어떻게 선택해야 할까요? 서로 다른 출처의 같은 이름 도구가 약간 다르게 작동한다면(예: 하나는 요약, 다른 하나는 전체 텍스트 반환) 에이전트가 차이를 인식하고 활용할 수 있을까요?

선택 기준은 통합 전에 설명을 검토하고 버전을 고정하며 최소 권한 자격 증명을 구성하는 것입니다. 같은 이름의 도구가 가려져 민감한 호출이 악의적인 주체로 라우팅되는 일을 경계해야 합니다. 실행 시에는 계층형 분류와 동적 탐색으로 후보를 좁힙니다. 모델이 동작 차이를 인식할 수 있는지는 도구 설명의 품질에 달려 있습니다.

4. (★★★) 에이전트가 사용자를 대신하여 외부 세계와 상호 작용할 때 본질적으로 정체성을 선택해야 합니다. 전용 이메일과 전화번호 같은 독립적인 가상 정체성으로 제3자처럼 행동할까요, 아니면 사용자의 개인 계정을 사용자 본인처럼 직접 조작할까요? 전자는 자율적으로 백그라운드에서 작동할 수 있지만 제3자가 비인간 정체성을 신뢰하지 않을 수 있습니다. 후자는 컨텍스트와 권한이 더 완전하지만 승인, 신뢰, 보안 경계 문제를 일으킵니다. 각 방식은 어떤 상황에서 선택해야 할까요?

기본값은 가상 정체성입니다. 백그라운드에서 자율적으로 작동하고 감사할 수 있으며 실수하거나 침해당해도 사용자의 전체 디지털 정체성을 노출하지 않습니다. 비서가 자기 사무용 이메일을 사용하는 것과 같습니다. CAPTCHA/IP 평판 문제(주거용 프록시)는 처리해야 합니다. 계정 본인 확인이나 Pine의 고객 서비스 통화처럼 3자 통화 확인 등 반드시 사용자의 정체성을 써야 하는 상황에서는 인간 참여형 인증을 사용합니다. VNC/RDP를 통해 사용자가 직접 로그인하고 화면으로 확인하게 합니다. 판단 기준은 상대방이 계정 소유자의 직접 참여를 요구하는지, 작업 위험도와 자격 증명의 범위가 어느 정도인지입니다.

5. (★★) 큐 기반 이벤트 처리에서는 모델이 마지막 이벤트에만 집중하는 경향이 있습니다. 이 장에서는 에이전트 상태 표시줄 마커와 요약으로 문제를 줄였습니다. 하지만 큐에 이벤트 20개(도구 결과 10개 + 사용자 메시지 5개 + 시스템 경고 5개)가 밀려 있다면 모델이 핵심 정보를 놓치지 않도록 어떤 순서와 형식으로 보여 주시겠습니까?

먼저 규칙과 경량 LLM으로 분류하고 중복을 제거합니다. 경고와 사용자 인터럽트 같은 긴급 이벤트는 별도의 cancel 방식으로 처리하여 배치에 섞지 않습니다. 너무 긴 도구 결과 10개는 잘라 파일에 영속화하고 시작, 끝, 경로만 남깁니다. 컨텍스트 끝의 시스템 상태 표시줄에 이벤트 유형별 개수와 각 항목에 답하라는 요구를 담은 요약 목록을 추가합니다.

6. (★★) 이 장에서는 ‘실행-검증-피드백’ 루프를 제안합니다(예: 코드를 쓴 뒤 linter 자동 실행). 이러한 ‘작업 직후 자동 검증’ 패턴을 어떤 도구 상황에 더 적용할 수 있을까요? 검증 자체의 비용이나 위험이 작업보다 커서 이 패턴을 적용하기 어려운 작업도 있을까요?

일반화할 수 있는 상황으로는 설정을 바꾼 뒤 샌드박스에서 실제로 실행하여 적용 여부를 확인하는 일, 문서·프레젠테이션을 만든 뒤 스크린샷으로 렌더링하고 모델의 멀티모달 능력으로 레이아웃을 확인하는 일이 있습니다. 이메일 발송, 전화 걸기, 송금처럼 되돌릴 수 없고 멱등하지 않은 작업은 적용하기 어렵습니다. 관찰할 대상이 없거나 검증 자체가 또 다른 현실 세계의 사건을 일으키기 때문입니다. 이때는 사전 수단인 제안자-검토자 사전 승인으로 전환해야 합니다.

7. (★★) 이 장에서는 수천 개의 도구 앞에서 에이전트의 선택 정확도가 떨어지는 ‘도구 폭발’ 문제를 제기합니다. 능동적인 도구 탐색 외에 어떤 접근법이 있을까요? 인간 전문가가 방대한 도구 모음을 다루는 방식을 참고해 보십시오.

① 계층형 그룹화로 먼저 ‘서버/앱’을 찾은 뒤 구체적인 도구를 고릅니다. ② 스킬 방식의 ‘필요할 때 찾아보기’를 사용합니다. 참고서를 찾는 것처럼 목차는 컨텍스트에 상주시키고 세부 내용은 필요할 때 불러옵니다. ③ 자주 쓰는 소수의 기본 도구는 ‘손이 닿는 곳’인 컨텍스트에 상주시켜 두고 나머지는 카탈로그 색인으로 접근합니다.

5장: 코딩 에이전트와 코드 생성

1. (★★) 코드 생성은 에이전트의 ‘메타 능력’이라고 불립니다. 하지만 코드를 실행하면 보안 위험이 생깁니다. 에이전트가 생성한 코드에 취약점이 있거나 무한 루프에 빠지거나 리소스를 고갈시킬 수 있습니다. 샌드박스로 위험 일부를 줄일 수 있지만 네트워크·파일 시스템 접근을 막는 등 코드가 할 수 있는 일도 제한합니다. 보안과 능력 사이의 최적 균형을 어떻게 찾을 수 있을까요?

상황에 따라 샌드박스 격리를 컨테이너/microVM 등급으로 나눕니다. 기본적으로 네트워크를 차단하고 필요할 때 허용 목록 프록시로 접근을 승인합니다. 소스 코드는 읽기 전용으로 마운트하고 API 키는 샌드박스 밖에 둡니다. 샌드박스 리소스 한도를 설정하고 시간 제한으로 수명 주기를 관리합니다.

2. (★★★) 에이전트가 에이전트를 만드는 에이전트 부트스트래핑은 ‘지능의 자기 복제’를 이룹니다. 하지만 부트스트래핑을 반복할 때마다 새로운 편향이나 오류가 생길 수 있습니다. 오류가 세대를 거치며 누적될까요? 부트스트랩된 에이전트의 성능 저하를 어떻게 막을 수 있을까요?

각 세대가 이전 세대의 산출물 위에서 계속 복제한다면 일부 결함이 누적될 수 있습니다. 핵심은 충분히 어렵고 검증 가능한 업무, 예를 들어 난도가 충분히 높은 프로그래밍 업무를 사용하는 것입니다.

3. (★★) 코드 생성 에이전트는 로그 파싱 형식이 바뀌어도 자동으로 적응할 수 있습니다. 하지만 형식 변경이 의도한 수정이 아니라 버그라면 에이전트의 적응력이 문제를 가립니다. 에이전트는 ‘적응해야 할 변경’과 ‘보고해야 할 이상’을 어떻게 구분해야 할까요?

적응하기 전에 진단합니다. 새 형식을 아키텍처 문서와 PRD에 대조하여 예상된 변경인지 판단합니다(실험 5-8의 발상). 버전 관리 기록을 확인하여 출처 없는 표류가 아니라 정당한 코드 커밋에 대응하는지 확인합니다. τ-bench의 log_mismatch처럼 적응하기로 해도 조용히 용인하지 말고 경고를 기록하고 이슈를 자동으로 만듭니다. 불확실하면 인간 참여형 확인으로 라우팅합니다. 원칙은 적응과 보고를 병행하여 적응이 이상 신호를 삼키지 않게 하는 것입니다.

4. (★★) 이 장에서는 PPT 생성, 동영상 편집, 로그 시각화에 제안자-검토자 메커니즘을 반복해서 사용합니다. 검토자의 미적 선호가 대상 사용자와 다르다면, 예를 들어 검토자는 정보 밀도가 적절하다고 보지만 사용자는 너무 빽빽하다고 느낀다면 피드백 루프가 잘못된 국소 최적점에 수렴할 수 있습니다. 사용자 선호 피드백을 검토자 루프에 어떻게 통합할 수 있을까요?

사용자 피드백을 가장 높은 우선순위의 구조화된 이벤트로 에이전트 궤적에 주입합니다. 사용자 선호를 MEMORY.md에 써서 외부화하고 통합하여 업무 전반에 적용되게 합니다. 사용자가 직접 살펴볼 수 있도록 Markdown 대신 HTML 형식으로 문서를 전달합니다.

5. (★★) 이 장에서는 코딩 에이전트가 실행과 디버깅에서 얻은 경험을 코드베이스로 통합하는 여러 방법을 보여 줍니다. 지식 베이스 파일 작성, 아키텍처 문서 갱신, 프로젝트 지침 파일 유지, 작업 순서를 코드로 인코딩하는 방법입니다. 이 경험을 시스템 프롬프트의 규칙으로 더 증류하면 규칙 집합이 계속 늘어납니다. 축적된 규칙에서 중복되거나 오래된 항목을 찾아 제거하는 ‘가비지 컬렉션’을 어떻게 수행할 수 있을까요? 성공적인 코드 수정 한 번이 8장의 의미에서 아직 지속적인 진화가 아닌 이유는 무엇입니까?

GC 접근법은 linter, CI, 도구 검증으로 인코딩할 수 있는 규칙을 프롬프트 밖으로 옮기고, 규칙 적중률과 충돌을 추적하여 코드베이스에 주기적으로 재검증하며, Markdown과 Git으로 출처·버전·롤백 능력을 보존하는 것입니다. 성공적인 패치는 현재 사례를 해결했다는 사실만 보여 줍니다. 지속적인 진화가 되려면 수정이 추적 가능한 작업 증거에서 나와야 하고 후속 업무를 개선해야 하며 기존 업무의 회귀 테스트와 안전 검증도 통과해야 합니다.

6. (★) ‘원격 근무에 친화적인 팀은 AI 에이전트에도 친화적인 경우가 많습니다.’ 지식 문서화 측면에서 여러분의 팀이나 조직은 ‘AI 준비’가 얼마나 되어 있습니까? 가장 큰 장애물은 무엇입니까?

열린 문제입니다. 이 장의 대리 지표로 자가 점검할 수 있습니다. 원격으로 합류한 새 구성원이 저장소와 문서만으로 독립적으로 일할 수 있습니까? 의사 결정을 문서에 기록하는지, 이슈/PR에 컨텍스트를 적는지, 빌드·테스트 명령에 CLAUDE.md/AGENTS.md 같은 지침 파일이 있는지, 암묵지를 개발자 안내서로 증류했는지 확인하십시오. 가장 흔한 큰 장애물은 ‘옆자리 동료에게 물어보기’에 의존하는 구두 전달과 화이트보드 문화입니다. 에이전트는 구두 합의를 읽지 못하고 문서만 읽을 수 있습니다.

7. (★★★) Simon Willison은 에이전트의 ‘치명적 삼요소’(비공개 데이터 접근, 신뢰할 수 없는 콘텐츠 노출, 외부 통신 능력)를 제안했습니다. 이 장에서는 네 번째 요소로 영속 기억을 추가합니다. 네 요소를 모두 다뤄야 하는 프로덕션 환경에서 보안 전략을 어떻게 설계하시겠습니까?

네 종류의 경계를 따라 방어 계층을 둡니다. 데이터 경계에서는 자격 증명을 마운트하지 않고 소스 코드를 읽기 전용으로 제공하며 가시성을 최소화합니다. 입력 신뢰 경계에서는 출처를 표시하고 외부 콘텐츠를 ‘참고용 데이터이며 지시 효력 없음’으로 격하합니다(충성 행동 규범). 출력 영향 경계에서는 기본적으로 네트워크를 차단하고 허용 목록으로 외부 연결을 제한하며, 차단 목록 대신 명령을 의미적으로 파싱하고, 독립적인 Sidecar 검토와 인간 참여형 확인을 사용합니다. 중요한 작업은 컨텍스트 외부의 메커니즘이 검토해야 합니다. 세션 간 경계에서는 MEMORY.md 쓰기에 외부 콘텐츠와 같은 신뢰 검토를 적용합니다. 목표는 인젝션을 당하더라도 공격을 실행할 수 없게 하는 것입니다.

8. (★★) Artifact 패턴에서는 에이전트가 생성한 SQL이나 프런트엔드 코드를 사용자의 브라우저나 데이터베이스에서 직접 실행할 수 있습니다. 하지만 생성된 SQL이 파괴적인 작업을 실행하거나 HTML에 취약점이 있을 수 있습니다. 시스템 보안을 어떻게 보장할 수 있을까요?

SQL은 최소 권한 읽기 전용 계정으로 질의를 실행하고 CPU, 메모리 등에 리소스 한도를 걸어 고갈을 막습니다. HTML/UI는 A2UI 같은 선언형 프로토콜을 우선합니다. 에이전트는 인터페이스 설명 JSON만 출력하고 클라이언트가 신뢰하는 구성 요소 카탈로그로 렌더링하여 임의 코드를 실행하지 않습니다. 임의 HTML이 꼭 필요하다면 인젝션을 막도록 샌드박스 환경에 표시해야 합니다.

9. (★★) 비즈니스 규칙을 데이터베이스의 실제값과 대조하는 검증으로 인코딩하고, 모델이 호출 전에 정책 조건을 확인하도록 도구 매개변수를 설계하면 코드 구조로 에이전트 행동을 제한할 수 있습니다. 이 ‘규칙으로서의 코드’ 패턴은 자연어로 표현한 규칙과 비교해 어떤 장점과 한계가 있을까요?

장점은 모호하지 않고 결정론적이며 복잡한 조건 조합에 강하다는 것입니다. 정책 사실은 모델의 자기 보고값이 아니라 데이터베이스 실제값과 서버 측 시계에서 가져오므로 환각이나 프롬프트 인젝션으로 우회할 수 없습니다. 되돌릴 수 없는 작업을 막는 최후의 방어선입니다. expected_* 매개변수는 사고를 안내하는 의무 체크리스트 역할도 합니다. 한계는 코드가 사용자에게 정책을 설명하지 못하고 우회책을 찾지 못하며 유지보수 비용이 든다는 것입니다. 결론적으로 자연어 규칙을 보완하며 대체하지는 않습니다.

10. (★★) Artifact 패턴에서는 에이전트가 SQL이나 시각화 코드를 생성하여 하위 구성 요소가 직접 실행하므로 LLM이 대량의 데이터를 처리할 필요가 없습니다. ‘에이전트가 코드를 생성하고 시스템이 실행하는’ 분업은 전통적인 ‘에이전트가 직접 답하는’ 패턴과 비교해 어떤 장단점이 있을까요?

장점은 데이터가 LLM이라는 ‘중간자’를 거치지 않고 데이터베이스에서 프런트엔드로 바로 흘러 빠르고 토큰을 절약하며 대량 데이터를 옮겨 적을 때 환각 오류가 없어 많은 데이터를 제시하기에 적합하다는 점입니다. 코드를 감사하고 재사용할 수 있으며 파이프라인으로 조합할 수도 있습니다(SQL 결과를 시각화 코드에 바로 입력). 단점은 LLM이 질의 결과를 보지 못하므로 데이터 내용을 바탕으로 추가 요약과 의사 결정을 할 수 없어 모델이 데이터를 소화한 뒤 사고해야 하는 업무에는 적합하지 않다는 점입니다.

6장: 에이전트 평가

1. (★★) LLM-as-a-Judge는 언어 모델로 언어 모델의 출력을 평가합니다. 이런 ‘자기 평가’에는 특정 답변 스타일에 늘 높은 점수를 주지만 사람의 판단과는 어긋나는 식의 체계적인 맹점이 있을까요? 이러한 편향을 어떻게 감지하고 교정할 수 있을까요?

있습니다. 길이 편향, 답변 스타일 편향, 같은 계열 모델을 공략하는 현상(Goodhart의 법칙)입니다. 사람의 정답 기준 예시 100~200개를 만들고 심판과 사람 사이의 Cohen’s kappa를 측정하며, 점수와 답변 길이의 상관관계를 주기적으로 감사하고, 레드팀이 적대적 사례를 만들게 하여 감지합니다. 루브릭에 장황함 감점과 길이 상한을 명시하고 서로 다른 모델 계열의 이질적인 심판을 사용하여 교정합니다.

2. (★★★) 평가 데이터셋의 ‘유출 방지’ 설계는 매우 중요합니다. 하지만 오픈 소스 생태계에서는 벤치마크 데이터가 공개되면 곧 학습 데이터에 들어갑니다. 이 ‘쫓고 쫓기는 게임’에 끝이 있을까요? 데이터 유출에 근본적으로 강한 평가 방법을 설계해 보십시오.

정적인 문제 은행에는 끝이 없고 계속 뒤쫓을 수밖에 없습니다. 근본적인 해법은 ‘생성 메커니즘’은 공개하되 ‘구체적인 인스턴스’는 비공개로 유지하는 것입니다. τ²-bench와 AndroidWorld처럼 매번 무작위로 인스턴스화하는 매개변수화 템플릿을 사용하고 고정된 답안 순서가 아니라 최종 환경 상태로 검증합니다.

3. (★★) Scale AI의 네 기준(전문가 지침, 포괄적 범위, 표준 중요도 가중치, 독립적으로 완결된 평가)은 평가의 주관성을 없애려 합니다. 하지만 ‘답변이 유용한가?’, ‘말투가 적절한가?’ 같은 일부 업무 차원은 본질적으로 주관적입니다. 주관적인 차원에 신뢰할 수 있는 루브릭을 어떻게 설계할 수 있을까요?

추상적 기준을 검증 가능한 행동으로 바꿉니다. 등급별로 구체적인 예시와 경계 사례를 제공합니다. 루브릭은 반복적으로 발전시키는 제품입니다. 시험 사용 중 평가자 간 의견 불일치를 모아 점차 사례집으로 발전시킵니다. 여러 심판의 가중치·일관성 검사로 보완하고, 불일치 사례는 사람이 검토하며, 정답 기준 집합에서 일치율을 보정합니다.

4. (★★) τ-bench는 실제 사용자 행동을 시뮬레이션하여 에이전트를 평가합니다. 하지만 시뮬레이션 사용자도 LLM이므로 감정적으로 격앙되거나 표현이 불분명한 사용자 같은 경계 사례를 체계적으로 과소평가할 수 있습니다. 시뮬레이션 사용자 자체의 품질을 어떻게 검증할 수 있을까요?

τ-bench 첫 버전이 주는 교훈은 시뮬레이터가 너무 기계적이고 지침도 너무 단순하여 에이전트가 답을 추측할 수 있었다는 점입니다. 시뮬레이션 대화를 사람이 표본 검사하여 점진적으로 정보를 공개하고 대본 밖의 정보를 지어내지 않는지 확인합니다. 실제 사용자로 소표본 테스트를 실행하여 순위가 시뮬레이션 평가와 일치하는지도 살핍니다.

5. (★★) 쌍대 비교(Bradley-Terry 모델)는 선호가 이행적이라고 가정합니다(A > B이고 B > C이면 A > C). 하지만 사람의 선호는 이행성을 어길 때가 많습니다. 에이전트 평가에서는 어떤 상황에 비이행적 선호가 나타날 수 있을까요? 순위의 신뢰성에는 어떤 영향을 줄까요?

정확하지만 느린 A, 빠르지만 간결한 B, 철저하지만 비싼 C처럼 여러 차원에서 절충해야 하고 심판·업무마다 각 차원의 가중치가 다를 때 나타납니다. Chatbot Arena 순위는 본질적으로 사용자 프롬프트 분포에 의존합니다. BT는 강점을 단일 점수로 압축하므로 비이행성 아래에서는 순위가 불안정하고 대결 분포에 따라 바뀝니다. 능력 차원별로 따로 순위를 정하고 쌍대 승률 행렬을 보고하여 완화할 수 있습니다.

6. (★★) 이 장에서는 ‘관찰 → 가설 → 실험 → 검증’이라는 과학적 방법을 제안합니다. 하지만 실제로 에이전트의 행동 공간은 방대하고 가설 하나를 검증하는 데 수백 번의 평가 실행이 필요할 수 있습니다. 연산 예산이 한정되어 있을 때 평가에서 얻는 정보량을 어떻게 극대화할 수 있을까요?

먼저 실패를 묶어 진단 가치가 높은 작업으로 파일럿 범위를 좁힙니다. 비용이 낮은 단일 변수 쌍대 실험을 하고, 작은 표본은 배포 증거가 아니라 전체 실험으로 가는 관문으로 취급합니다. 통계적으로는 표준 오차로 보수적으로 선별하고 같은 작업에는 McNemar 같은 쌍대 분석을 적용합니다. 예상 차이가 잡음보다 작으면 평가 세트를 늘립니다. 여러 후보를 병렬로 시험할 때는 다중 비교를 보정하고 긍정적 결과를 독립적으로 재현해야 합니다.

7. (★) AndroidWorld 파일럿에서 전체 요소 트리는 성공률을 25%에서 100%로 높였지만 token 사용량을 대조군의 2.498배로 늘렸습니다. 축약 후 성공률은 100%로 유지됐고 token은 0.506배가 됐습니다. 접근성, 상태 검증, 이후 행동에 필요한 정보는 남기면서 의미 없는 UI 노드를 자동으로 제거하려면 어떤 규칙을 설계해야 할까요?

‘기본은 삭제, 보존 근거가 있으면 유지’하는 계층형 규칙을 쓸 수 있습니다. 보이거나 텍스트가 있거나 조작·포커스·스크롤이 가능하거나 상태값·접근성 라벨이 있는 노드는 유지하고, 이 노드까지의 최소 조상 경로와 해석에 필요한 인접 라벨도 남깁니다. 레이아웃 전용 컨테이너는 제거하고 반복 하위 트리는 요약합니다. 전후로 조작 대상 ID, 상태, 값이 보존됐는지 검사하고 스크린샷을 시각적 대체 수단으로 둡니다. 실패 궤적에서 재생한 뒤 조정에 쓰지 않은 앱으로 회귀 테스트합니다. 성공률·token·지연 시간을 공동 가드레일로 삼고 접근성 회귀가 있으면 출시를 막습니다.

8. (★★) τ-bench의 사용자 시뮬레이션은 모든 정보를 한 번에 주지 않고 에이전트의 질문에 따라 점차 공개하는 ‘점진적 정보 공개’를 사용합니다. 이 설계는 평가 결과에 어떤 영향을 줍니까? 시뮬레이션 사용자의 정보 공개 전략이 실제 사용자와 크게 다르다면 평가 결론을 계속 신뢰할 수 있을까요?

공개 전략이 왜곡되면 에이전트가 단지 ‘시뮬레이터에 맞추기’를 배웠을 수 있어(Goodhart) 절대 점수는 참고할 가치가 없어집니다. 모델 사이의 상대적 순위는 여전히 의미가 있을 수 있습니다. 실제 대화로 시뮬레이터를 보정하고 사람이 표본 검사하며 결론이 적용되는 경계를 명확히 밝혀 보완합니다.

7장: 모델 사후 학습

1. (★★) 특정 업무를 위한 미세 조정이 일반적인 도구 호출 같은 모델의 원래 범용 능력을 파괴하는 파국적 망각은 에이전트 상황에서 특히 골치 아픕니다. LoRA는 전체 매개변수 미세 조정보다 기반 가중치를 고정하므로 망각 위험이 낮지만 완전히 면역되지는 않습니다. 미세 조정 중 능력 망각을 더 줄일 전략은 무엇입니까?

데이터 혼합으로 범용/원래 분포 데이터 약 20%를 섞어 새 업무의 비중이 기존 능력을 압도하지 않게 합니다. 학습량을 절제하여 ‘형식이 안정되고 기본 능력이 생기면’ SFT를 중단합니다. 조기 중단으로 붕괴를 막습니다. RL에는 작은 rank(8~32)를 사용하고 KL 페널티를 유지하여 정책을 참조 모델 가까이에 둡니다. 핵심 구성 요소를 고정합니다(예: VLM의 투영 계층만 학습). 업무별로 여러 LoRA 어댑터를 붙여 능력을 격리하고 범용 벤치마크에서 회귀 테스트를 실행합니다.

2. (★★) 사후 학습은 능력을 모델 가중치에 ‘근육 기억’처럼 굳히고, 컨텍스트 내 학습은 추론 중 입력에 지식을 둡니다. 하지만 도메인 지식 같은 일부 능력은 사후 학습으로 배우거나 퓨샷 예시로 제공할 수 있습니다. 주어진 능력을 어느 경로에 둘지 어떤 기준으로 결정하시겠습니까?

먼저 능력을 외부 기호로 충분히 표현할 수 있는지 묻습니다. 사실과 증거는 RAG에, 언어로 표현할 수 있는 원칙은 프롬프트/스킬에, 결정론적 절차와 강제 제약은 프로그램에 둡니다. 의료 영상 이해, 자연스러운 어조, 암묵적 정책 같은 고차원 능력은 도메인이 계속 바뀌더라도 매개변수 갱신이 필요한 경우가 많습니다. 그런 다음 갱신 비용, 호출량, 적시성, 위험을 고려합니다. 탐색 단계에서는 컨텍스트로 빠르게 검증하고 접근법이 안정적이고 효과적이며 널리 일반화할 필요가 입증된 뒤에만 학습합니다. 단, 아무리 안정적인 강제 규칙도 매개변수 기억에만 의존해서는 안 됩니다.

3. (★★) 모델 증류에서는 작은 모델이 큰 모델의 행동을 학습합니다. 증류할 모델은 능력 수준에 따라 크게 세 단계로 나눌 수 있습니다. 대화 모델(단일 턴 대화, 직접 답변), 사고 모델(답하기 전에 긴 사고 사슬 생성), 에이전트 모델(여러 턴의 도구 호출, 환경과 상호 작용)입니다. 세 유형을 증류할 때 각각 어떤 어려움이 있을까요? (힌트: 정확히 무엇을 증류하는지부터 생각하십시오. 출력 스타일일까요, 전체 사고 궤적일까요, 환경과 상호 작용하는 의사 결정 전략일까요? 궤적의 어떤 토큰은 학습해야 하고 어떤 토큰은 학습하면 안 되는 환경 반환값일까요? 성공·실패 신호는 얼마나 늦고 희소할까요?)

대화 모델은 ‘입력 → 출력’ 매핑과 스타일만 학습하므로 표준 SFT로 충분하고 가장 단순합니다. 사고 모델에는 완전한 사고 궤적이 필요하므로 오픈 소스 교사 모델을 사용해야 하며 오답 궤적을 걸러야 합니다. 에이전트 모델에는 실제 시뮬레이션 환경이 필요합니다. 오프라인 학습은 학습자-샘플러 불일치가 생기기 쉬우므로 오픈 소스 교사 모델 기반 On-Policy Distillation을 권장합니다.

4. (★★★) 여러 턴의 에이전트 상호 작용에서는 단일 턴보다 기여도 할당 문제가 심각합니다. 최종 성공이나 실패가 3번째 턴의 결정 때문인지 7번째 턴의 결정 때문인지 판단하기 어렵습니다. 보상 배분 전략을 어떻게 설계하시겠습니까?

중간 단계를 판단할 수 있다면 과정 보상을 추가합니다(V-IRL은 단계마다 ±1). RLVP를 따라 결정론적 규칙으로 행동별 경로 신호를 주어 전부 실패하거나 전부 성공한 집단에도 집단 내 분산을 되살립니다.

5. (★★★) 고객 서비스 에이전트를 개선할 $10,000 같은 고정 예산이 있다면 컨텍스트와 지식, 프롬프트/스킬, 프로그램 제약, 매개변수 학습에 어떻게 배분하시겠습니까? 결정을 좌우할 요인은 무엇입니까?

먼저 평가 집합과 궤적 검증기에 예산을 확보합니다. 그렇지 않으면 나머지 투자를 비교할 수 없습니다. 제품 사실과 정책은 추적 가능한 지식 베이스에 둡니다. 언어로 표현할 수 있는 소수의 서비스 원칙은 프롬프트/스킬로 빠르게 시험합니다. 환불 권한, 개인정보 보호, 약속과 행동의 일관성은 프로그램으로 최종 방어합니다. 자연스러운 어조나 복잡한 의도 이해처럼 규칙으로 인코딩하기 어렵고 충분한 규모로 반복해서 쓰이는 능력에만 매개변수 학습을 투자합니다. 정확한 비율은 병목, 위험, 갱신 빈도, 호출량, 기존 모델의 능력에 따라 달라집니다.

6. (★★★) 명확한 보상 함수가 없고 샘플이 부족한 상황의 자율 모델 학습을 사후 학습의 궁극적인 목표로 보는 견해가 있습니다. 현재 RL 학습 방법은 이 목표에서 얼마나 멀리 있으며, 다음 돌파구는 어디에서 나올 가능성이 가장 높다고 생각하십니까?

격차는 Silver와 Sutton이 지적했듯 현재 RL이 최종 성공이나 실패에서만 학습할 수 있다는 점입니다. 고객이 ‘신용카드 번호의 마지막 네 자리가 필요합니다’라고 말하는 풍부한 피드백을 전혀 활용하지 못해 수백 번의 맹목적인 시도가 필요합니다. 샘플 효율성과 검증 가능한 보상이 주된 병목입니다. 가능한 돌파구는 스스로 원칙을 세우고 실패 한 번에서 방향을 학습하는 생성형 보상 모델, 그리고 환경을 모델링하는 월드 모델 경로입니다.

7. (★★) 이 장에서는 LoRA 미세 조정 비용이 높지 않다고 설명합니다. 그렇다면 사용자(또는 고객사)마다 전용 LoRA를 학습하여 3장처럼 외부 지식 베이스에 저장하는 대신 사용자 메모리나 기업 지식을 매개변수에 쓸 수 있을까요? ‘메모리를 매개변수에 쓰기’가 ‘메모리를 지식 베이스에 저장하기’보다 유리한 상황과 오히려 역효과를 내는 상황은 언제일까요?

LoRA는 많은 사실을 정확히 기억하기 어렵습니다. 그렇게 하려면 지속적인 사전 학습이 필요하여 비용이 급격히 늘어납니다. 기억하더라도 모델이 그 사실을 다중 홉 사고에 활용하기는 어렵습니다. 따라서 LoRA로 사실을 외우게 하는 것은 좋은 기술 경로가 아닙니다. 사실이 자주 바뀌거나 추적 가능한 감사가 필요할 때도 RAG가 더 낫습니다.

8. (★★★) On-Policy Distillation은 더 강한 교사 모델이 학생을 감독합니다. 하지만 OpenAI의 Weak-to-Strong Generalization 연구에서는 약한 모델의 감독 신호가 강한 모델에 잠재했지만 활성화되지 않은 능력을 때로 끌어낼 수 있다는 직관에 반하는 결과를 제안했습니다. 이 발상을 에이전트 학습에 적용하면 ‘작은 모델이 큰 모델을 가르치는’ 역증류를 이룰 수 있을까요?

가능합니다. 핵심은 ‘검증이 생성보다 쉽다’는 것입니다. 약한 모델을 시범자(SFT의 상한은 시범자 수준)가 아니라 검증기/보상 모델로 사용하고 강한 모델이 스스로 탐색하며 약한 모델은 판단만 하게 해야 합니다.

9. (★★) 과정 보상 모델(PRM)은 각 사고 단계를 평가하고 결과 보상 모델(ORM)은 최종 결과만 봅니다. ‘올바른 과정이 잘못된 결과로 이어진 경우’와 ‘잘못된 과정이 운 좋게 올바른 결과로 이어진 경우’ 중 어느 쪽이 더 보상할 가치가 있을까요? 에이전트의 다단계 도구 호출 상황에서는 어떻게 가중하시겠습니까?

운 좋은 성공이 더 위험합니다. 규칙을 어긴 지름길(테스트 파일 수정, 검증 건너뛰기)은 겉보기 성공률을 높이는 경우가 많고 보상 해킹의 온상입니다. RLVP의 ‘결과에 보상하고 경로에 벌점을 준다’를 따릅니다. 잘못된 행동(도구 호출)은 검증하기 쉬우므로 행동마다 감점하고 중간 단계를 쉽게 판단할 수 있을 때 과정 보상을 줄 수 있습니다. 다만 과정 제약을 지나치게 촘촘하게 만들지는 마십시오. 우수한 ‘push-cut’ 방식의 전략은 결과 보상이 허용한 탐색의 자유 덕분에 발견되었기 때문입니다.

10. (★★★) 이 장에서 논의한 평가 데이터셋(예: SWE-Bench Verified, τ²-bench, AndroidWorld)은 평가와 사후 학습에 모두 사용할 수 있습니다. 하지만 평가 집합을 학습에 사용하면 더는 독립적인 평가 집합이 아니므로 학습·테스트 집합을 분리해야 한다는 기본 원칙을 어기지 않을까요? τ²-bench의 동적 매개변수 생성과 AndroidWorld의 매개변수화 템플릿은 이 문제를 어느 정도 줄이지만 템플릿 구조 자체는 고정되어 있습니다. 평가 데이터의 학습 가치를 충분히 활용하면서 평가 독립성을 어떻게 유지할 수 있을까요?

문제 대신 환경을 재사용합니다. 동적 매개변수는 ‘답 암기’만 막을 뿐 템플릿 과적합은 막지 못하므로 한 번도 보지 않은 템플릿 묶음이나 분포 외 상황 전체를 평가용으로 남겨야 합니다(뉴욕에서 V-IRL을 학습하고 낯선 도시 아홉 곳에서 테스트한 것과 비슷합니다). 매개변수화 템플릿으로 학습 변형을 대량 생성하여 커리큘럼 학습을 지원하고 OOD 점수를 진정한 일반화 지표로 삼습니다.

11. (★★★) 이 장은 ‘형식을 먼저, 정신은 나중에’라는 학습 패러다임을 제안합니다. SFT는 ‘형식이 안정되고 기본 능력이 생기면’ 멈추고 RL로 전환합니다. 실제로 SFT가 ‘충분해서’ 전환할 시점을 어떻게 판단할 수 있을까요?

형식 신호는 도구 호출 출력을 안정적으로 파싱·실행할 수 있고 도구 실행 실패율이 보상을 신뢰성 있게 계산할 수 있는 수준까지 떨어지는 것입니다. 효용 신호는 시범 데이터를 더 넣어도 OOD 새 상황의 성능이 더 나아지지 않는 것입니다. 병목이 이미 SFT의 암기 목적 자체에 있어 전환점에 이르렀다는 뜻입니다. 과적합 신호는 검증 집합 성능이 떨어지기 시작하는 순간입니다. 즉시 중단하십시오. V-IRL 실험은 SFT 과잉 학습으로 모델이 학습 분포에 붕괴하면 RL도 OOD 성능을 되살릴 수 없음을 보여 줍니다.

12. (★★★) ReTool의 학습 동역학(실험 7-15 참고)은 아주 긴 응답 소수가 전체 학습 주기를 크게 늘릴 수 있음을 보여 줍니다. 배치의 롤아웃 대부분을 이미 생성했지만 가장 긴 소수의 응답이 끝날 때까지 기다리는 동안 클러스터 GPU 사용률이 매우 낮아집니다. 이런 롱테일 응답 상황에서 학습 클러스터의 리소스 사용률을 어떻게 높일 수 있을까요?

인프라 계층에서는 롤아웃을 학습 클러스터에서 분리하고 비동기 파이프라인으로 구성합니다. 지속적 배치로 유휴 GPU에 새 요청을 채웁니다. 원천에서 롱테일을 압축하려면 DAPO의 Overlong Reward Shaping으로 지나치게 긴 응답에 부드럽게 벌점을 줍니다.

13. (★★★) LLM이 시뮬레이션한 환경(예: 시뮬레이션 검색 엔진이나 사용자)에서 에이전트를 학습하면 에이전트의 공략 대상이 ‘실제 환경의 규칙’에서 ‘시뮬레이터 자체의 편향과 허점’으로 이동합니다. 이런 학습에서 어떤 구체적인 보상 해킹 행동이 생길 수 있으며 어떻게 방지해야 할까요?

대표적인 행동은 ‘시뮬레이션 사용자’에게 과도하게 약속하고 사과·아첨 표현을 늘어놓는 것입니다. 시뮬레이션 사용자는 쉽게 달래지며 실제 사용자와 달리 약속이 지켜졌는지 책임을 묻지 않습니다. 시뮬레이터가 검증하지 않을 사실을 지어내기도 합니다. ‘시뮬레이션 검색 엔진’이 답이 든 문서를 반환하는 경향을 이용하는 유도성 질의를 만들어 진짜 검색을 배우지 않고 지름길을 택할 수도 있습니다. 시뮬레이터나 LLM 심판 점수에서 보상이 나오면 장황하고 틀에 박혔으며 ‘전문적으로 보이는’ 답변으로 점수를 벌 수 있습니다. 더 교묘하게는 정책이 시뮬레이터에 익숙한 분포로 물러나 지식의 맹점을 피합니다. 그곳에서는 피드백이 불안정하고 오판이 잦으므로 에이전트가 ‘시뮬레이터가 잘 아는 세계’에서만 행동하는 법을 배웁니다. 방어의 첫 원칙은 보상을 프로그램으로 검증 가능한 실제 상태에 고정하는 것(업무 완료, 데이터베이스 쓰기, 실제 API 반환값)입니다. 시뮬레이터나 LLM 심판 점수는 보조 신호로만 사용하며 실제 결과와의 상관관계를 주기적으로 감사하고 의심스러운 행동에 벌점을 주는 경로 제약을 결합합니다. 또한 두 종류의 시뮬레이터를 구분해야 합니다. 검색처럼 실제 대응물이 있는 시뮬레이터는 대부분의 상호 작용을 시뮬레이터에서 처리하되 실제 API 호출을 섞고 실제 호출로 시뮬레이터를 주기적으로 보정하는 ‘하이브리드’ 경로를 택합니다(예: ZeroSearch의 커리큘럼 방식 품질 저하). 하지만 시뮬레이션 사용자는 실제 사용자를 학습에 투입할 수 없으므로 ‘시뮬레이션 사용자가 실제 사용자에게 얼마나 충실한가’가 별도의 문제가 되고 온라인 궤적으로만 답할 수 있습니다. 프로덕션 궤적의 실제 사용자 행동과 같은 상황에서 시뮬레이션한 사용자 행동을 비교하여 체계적인 차이를 찾습니다. 실제 사용자는 후속 질문을 하고 참을성을 잃고 갑자기 대화를 끝내지만 시뮬레이션 사용자는 흔히 그렇지 않습니다. 이에 따라 시뮬레이터를 계속 보정해야 합니다. 온라인 실제 지표는 유일한 릴리스 게이트이기도 합니다. 시뮬레이터 안의 점수는 어떤 것도 인정하지 않습니다.

8장: 에이전트의 지속적 진화

1. (★★) 경험 문서를 뒷받침하는 성공 궤적 세 개와 실패 궤적 한 개가 있습니다. 실패는 더 최신 API 버전에서 발생했습니다. 시스템은 경험이 반증된 것인지 적용 조건이 달라진 것인지 어떻게 판단해야 할까요?

개수로 투표하지 말고 먼저 네 증거를 API 버전, 업무 조건, 환경 상태로 층화합니다. 기존 정책이 이전 버전에서만 성공하고 새 버전에서는 일관되게 실패한다면 경험의 적용 범위를 좁히고 새 버전의 후보를 생성합니다. 같은 버전과 전제 조건에서도 실패한다면 신뢰도를 낮추거나 폐기합니다.

2. (★★) 고객 서비스 에이전트의 사용자 만족도는 올라가지만 규칙 위반율도 올라갑니다. 만족도를 유일한 학습 신호로 삼을 수 없는 이유는 무엇입니까? 가드레일 지표를 어떻게 설계하시겠습니까?

만족도는 승인받지 않은 환불, 정보 유출, 과도한 약속에도 보상할 수 있으므로 품질 지표일 뿐 안전 기준선을 덮어쓸 수 없습니다. 가드레일은 적어도 규칙 위반, 개인정보 유출, 근거 없는 주장, 약속과 행동의 불일치, 승인받지 않은 작업을 다뤄야 합니다. 이 지표에는 평균 점수로 상쇄할 수 없는 강제 임곗값을 둡니다. 해결률, 규정을 지킨 우회책, 간결성, 만족도는 규정을 준수한 후보끼리만 비교합니다.

3. (★★★) 같은 ‘거짓 약속’ 문제를 프롬프트, 하네스 검사, 매개변수 학습으로 완화할 수 있습니다. 갱신 위치를 선택할 때 어떤 증거를 사용하시겠습니까?

먼저 근본 원인을 찾습니다. 모델이 도구가 실행되지 않았음을 알면서도 완료 표현을 쓴다면 최소한의 프롬프트 규칙으로 고칠 수 있습니다. 응답 텍스트와 도구 상태를 결정론적으로 비교할 수 있다면 하네스 검사가 더 신뢰할 만하며 고위험 상황의 최종 방어선으로 유지해야 합니다. 문제가 다양한 표현에 걸쳐 있고 광범위한 언어-행동 정렬 능력을 반영한다면 매개변수 학습을 고려합니다. 검증하고 롤백하기 가장 쉬운 최소 변경을 우선하고 실패 집합과 보존한 과거 업무 집합 모두에서 비교합니다.

4. (★★★) 에이전트가 도구와 검증기를 수정할 수 있더라도 자신의 갱신을 승인하는 보안 메커니즘은 수정할 수 없어야 합니다. 두 부분 사이의 권한과 코드 경계를 어떻게 나누시겠습니까?

진화 가능한 코드는 패치와 테스트만 생성할 수 있는 저권한 샌드박스에 둡니다. 권한 시스템, API 키, 릴리스 제어기 구성, 갱신 검증기는 보안 메커니즘이므로 샌드박스의 에이전트가 읽거나 쓸 수 없게 합니다. 에이전트가 만든 코드 변경은 릴리스 전에 보안 메커니즘이 격리된 환경에서 재현하고 회귀 테스트해야 합니다.

5. (★★) 경험 지식 베이스가 커지면 검색 오류와 지식 충돌이 학습의 이점을 상쇄할 수 있습니다. 버전 관리, 최신성, 폐기 메커니즘을 어떻게 설계해야 할까요?

각 경험에 출처 궤적, 적용 조건, 환경 버전, 검증 시각, 신뢰도를 보존해야 합니다. 충돌하는 항목은 서로를 조용히 덮어쓰지 말고 조건에 따라 분기하거나 표시합니다. ‘수면 학습’을 주기적으로 실행하여 중복 항목을 병합합니다.

6. (★★★) 매개변수 학습은 자연어 스타일에 강하지만 엄격한 비즈니스 규칙을 보장하지는 못합니다. 매개변수, 지식, 스킬, 코드 제약을 조율하는 의료 고객 서비스의 지속적인 진화 방안을 설계해 보십시오.

사후 학습한 모델인 매개변수는 의료 언어 이해, 자연스럽고 공감하는 표현, 복잡한 의도 인식을 담당합니다. 지식 베이스는 최신 지침, 의약품 정보, 기관 정책을 저장하고 답변에 출처 인용을 요구합니다. 스킬은 상담 정보 수집, 위험 분류, 사람에게 에스컬레이션, 후속 조치의 워크플로를 설명합니다. 서버 측 코드는 본인 확인, 개인정보 최소화, 금기 사항 검사, 응급 위험 에스컬레이션, 권한 경계를 강제합니다. 프로덕션 궤적은 먼저 의료 안전성, 사실 신뢰성, 약속-행동 일관성, 표현 품질을 평가한 뒤 네 종류의 후보 갱신을 만드는 데 사용합니다. 매개변수나 워크플로 변경은 카나리 릴리스 전에 보존한 의료 안전 집합과 사람의 검토를 통과해야 합니다.

9장: 멀티모달리티와 실시간 상호작용

1. (★★) 음성 에이전트의 엔드투엔드 모델은 ASR-LLM-TTS를 하나의 모델로 합쳐 지연 시간을 줄이지만 모듈성을 잃습니다. 엔드투엔드 모델이 음성 인식 같은 특정 단계에서 오류를 내면 직렬 파이프라인보다 디버깅하고 고치기가 훨씬 어렵습니다. 엔드투엔드 음성 에이전트의 관측 가능성 시스템을 어떻게 설계하시겠습니까?

모델이 출력과 함께 Moshi의 ‘내적 독백’ 텍스트 스트림과 음향 이벤트 마커(<emotion>, <noise>)처럼 사람이 읽을 수 있는 중간 표현을 내보내게 합니다. ‘자기 캐스케이딩’으로 오류 계층을 찾습니다. 같은 모델이 먼저 전사한 뒤 사고하게 하고 엔드투엔드 결과와 비교하여 오류가 지각에 있는지 사고에 있는지 확인합니다. 오프라인에서는 준언어 이해, 턴 전환 판단 같은 차원별 회귀 테스트를 실행합니다.

2. (★) Step-Audio R1은 MPS 이중 뇌 아키텍처로 ‘말하면서 사고하기’를 구현합니다. 하지만 사람은 ‘말하면서 사고할’ 때 충분히 생각하지 않은 말을 하거나 스스로 고치거나 군말을 사용하곤 합니다. 에이전트의 ‘말하면서 사고하기’도 이런 인간 특성을 모방해야 할까요?

신호 가치가 있는 ‘불완전함’은 모방해야 합니다. 멈춤과 군말은 사고를 외부로 드러내고 지연 시간을 가릴 수 있으며 LLM이 삽입 위치를 정하게 합니다. 하지만 신뢰를 무너뜨리는 자기 수정은 모방하면 안 됩니다. 해법 1의 빠른-느린 모순(“사라는 거야, 말라는 거야?!”)은 신뢰를 무너뜨립니다. MPS 실험은 CoT의 시작 부분이 주로 질문을 다시 말한다는 점을 보여 줍니다. 배경 설명으로 일찍 말을 시작하는 것은 안전하며 잘못 말한 뒤 바로잡을 필요가 없습니다.

3. (★★) SoM(Set-of-Mark)과 구조화 변형(DOM 요소 색인)은 Computer Use의 시각적 위치 찾기를 열린 좌표 예측에서 닫힌 ID 선택으로 바꿉니다. 하지만 분할 모델이나 DOM을 사용하여 UI 요소를 먼저 감지하고 주석을 붙여야 합니다. 인터페이스에 비표준 컨트롤이나 동적으로 바뀌는 요소가 있으면 주석이 불완전하거나 부정확할 수 있습니다. 이때 좌표 예측으로 돌아가야 할까요?

좌표 예측을 폴백으로 유지해야 합니다. 주석에 의존하지 않고 비표준 컨트롤과 동적 요소에 적용할 수 있는 유일한 경로입니다. 주석을 붙일 수 있는 요소에는 계속 ID 선택을 사용하는 하이브리드 행동 공간이 더 실용적입니다. 좌표 예측에서는 해상도를 맞추고 비례 스케일링을 해야 하며, 그렇지 않으면 체계적인 오프셋이 생깁니다.

4. (★★) XLeRobot 같은 1천 달러대 로봇 플랫폼은 원격 조작 데이터 수집 비용을 낮춥니다. 하지만 원격 조작 데이터의 품질은 조작자의 숙련도에 크게 좌우됩니다. 미숙한 조작자의 저품질 데이터가 VLA 모델 학습에 어떤 영향을 줄까요? 데이터 수집 단계에서 저품질 데이터를 어떻게 자동으로 걸러낼 수 있을까요?

VLA는 주로 모방 학습에 의존하므로 저품질 시범은 떨림, 우회, 망설임, 실패한 동작을 올바른 전략처럼 가르칩니다. 이는 아키텍처보다 데이터가 중요하다는 7장의 판단과 맞닿습니다.

5. (★★★) 이 장에서는 음성, Computer Use, 로보틱스라는 세 상호 작용 모달리티를 다룹니다. 모두 직렬 파이프라인에서 엔드투엔드 모델로 진화한다는 공통 흐름이 있습니다. 이 흐름이 계속된다면 5년 뒤 에이전트 상호 작용 계층은 어떤 모습일까요?

Thinking Machines Lab의 주장처럼 상호 작용성은 하네스에 덧붙이는 것이 아니라 모델 안에 내장되어 지능과 함께 확장될 것입니다. Computer Use는 프레임별 스크린샷에서 연속 관찰로 이동합니다. 체화 지능을 위한 월드 모델이 종합적으로 실현되겠지만 최전선 사고 모델이 빠르게 발전하므로 빠른 사고와 느린 사고의 분리는 사라지지 않을 것입니다. 상호 작용 모델과 최첨단 사고 모델이 빠른 사고자와 느린 사고자로 협업하는 아키텍처가 장기적인 형태가 될 수 있습니다.

6. (★★★) 현재 Computer Use는 ‘스크린샷 → 행동 → 스크린샷’이라는 이산적인 루프에서 작동하며 관찰 하나하나가 정적인 프레임입니다. 하지만 사람은 화면을 연속적으로 지각하여 애니메이션 재생, 로딩 진행, 동영상 내용을 이해합니다. 즉 오늘날의 Computer Use는 시간적 시각 이해가 필요한 업무를 처리할 수 없습니다. 연속적인 시각 스트림을 이해하도록 지각 계층을 어떻게 다시 설계하시겠습니까?

최종 프레임만 제공하는 대신 동영상 콘텐츠에서 핵심 프레임을 추출하여 모델에 제공하도록 ‘관찰 인터페이스’를 다시 설계해야 합니다. AOI(Agent Observation Interface) 논문을 참고하십시오.

7. (★★) DOM/Accessibility Tree 요소 색인은 표준 웹 애플리케이션에서는 잘 작동하지만 Canvas/WebGL 렌더링이나 크로스 플랫폼 사용자 정의 컨트롤처럼 접근 가능한 구조 정보를 제공하지 않아 시각적 주석이나 좌표 예측에만 의존하는 소프트웨어 인터페이스가 늘고 있습니다. Computer Use는 순수한 시각 접근법에 집중해야 할까요, 구조화 경로와 시각 경로를 모두 유지해야 할까요? 두 경로를 유지하는 비용과 이점은 무엇입니까?

단기적으로는 두 경로가 공존합니다. 구조화 색인을 사용할 수 있을 때는 분할 오탐 없이 위치 찾기가 가장 정확하고 안정적입니다. 네이티브 소프트웨어, Canvas, 게임에는 순수 시각이 유일한 선택입니다. 모델 자체가 지정된 좌표를 클릭하는 강한 그라운딩 능력을 갖추면 구조화 색인의 이점이 크지 않습니다. 장기적으로는 순수 시각 경로의 상한이 더 높습니다.

8. (★★) VLA 모델은 행동 청킹을 사용합니다. 본문에서 언급했듯 π₀의 일반적인 구성은 50Hz로 미래 행동 25~50개를 생성하여 추론 지연을 실행 시간 안에 숨깁니다. 하지만 실행 중 환경이 갑자기 바뀌면(예: 물체가 이동함) 미리 생성한 행동 시퀀스가 무효가 됩니다. 행동 청킹의 효율성과 환경 변화에 대한 반응성의 균형을 어떻게 맞출 수 있을까요?

청킹은 본질적으로 반응성과 매끄러움을 맞바꿉니다. 청크가 길수록 반응은 둔해집니다. 청크 길이는 ‘추론 시간 < 청크 실행 시간’이라는 하한만 충족하면 되며 무작정 늘리지 마십시오. 실행 중에도 지각 모델을 계속 돌리고 갑작스러운 환경 변화를 감지하면 남은 행동을 버리고 다시 추론하십시오. 음성 상황의 ‘barge-in’과 같습니다. 청크 길이도 동적으로 조절할 수 있습니다. 정적인 장면에서는 긴 청크로 연산을 절약하고 동적인 장면에서는 짧은 청크로 반응 지연을 줄입니다.

9. (★★★) 이 장의 세 상황(음성, Computer Use, 로보틱스)은 모두 ‘지각-사고-행동’ 루프의 지연 문제를 겪으며 빠른 사고와 느린 사고를 병렬화하는 방향으로 진화합니다. 음성에서는 ‘잘못 말한 뒤 수정하기’, Computer Use에서는 ‘먼저 클릭하고 나중에 보기’, 로보틱스에서는 ‘한 걸음 내딛고 나중에 보기’로 나타납니다. 빠른 사고에 따른 행동이 되돌릴 수 없는 결과를 낳지 않도록 어떻게 보장할 수 있을까요?

가역성에 따라 행동의 등급을 나눕니다. 빠른 사고는 가역적인 행동만 실행할 수 있고 되돌릴 수 없는 작업은 느린 사고의 승인을 받아야 합니다. 빠른 모델에는 되돌릴 수 없는 결과를 일으키는 도구 호출을 허용해서는 안 됩니다.

10장: 멀티 에이전트 협업

1. (★★) 공유 컨텍스트를 이용한 멀티 에이전트 협업에서는 후속 에이전트가 앞선 에이전트의 전체 컨텍스트를 물려받습니다. 하지만 이전 에이전트가 쌓은 ‘사고 관성’이 후속 에이전트의 판단에 영향을 줄 수 있습니다. 예를 들어 ‘요구 사항 분석가’의 컨텍스트를 물려받은 ‘코드 검토자’가 코드 품질보다 여전히 요구 사항 관점에서 사고할 수 있습니다. 이런 역할 간 간섭을 어떻게 감지하고 제거할 수 있을까요?

감지할 때는 LLM으로 에이전트 궤적을 분석하여 새 역할이 여전히 이전 역할처럼 행동하는지 판단합니다. 제거할 때는 단계 전환과 함께 시스템 프롬프트와 도구 집합도 바꾸어(질문 도구를 제거하고 linter/테스트 도구를 추가) 새 정체성을 강화합니다. 컨텍스트 끝에는 시스템 상태 표시줄을 덧붙여 현재 역할 정보를 강조합니다. 그래도 역할 간 간섭을 없앨 수 없다면 컨텍스트를 공유하지 않는 협업 방식을 고려합니다.

2. (★★) 관리자 패턴에서는 관리자 에이전트가 업무 분해와 결과 통합을 담당합니다. 하지만 관리자 자신의 능력 상한이 전체 시스템의 능력 상한을 결정합니다. 관리자가 업무를 올바르게 분해하지 못하면 아무리 강한 하위 에이전트도 쓸모가 없습니다. 관리자의 분해 품질을 어떻게 보장할 수 있을까요?

‘약한 계획자가 시스템의 병목이다’라는 Plan-and-Act의 결론을 따라 가장 강력한 모델을 관리자에게 배정합니다. 하네스 차원에서는 검토자 LLM이 실행 전에 분해 결과를 교차 검증하게 합니다. 또한 관리자가 업무를 분해할 때 각 하위 업무의 명확한 인수 조건과 의존성을 정의하도록 요구합니다.

3. (★★) 탈중앙화 패턴은 인간 조직의 모범 사례를 활용합니다. 하지만 인간 조직에도 의사소통 부족, 책임 전가, 목표 충돌 같은 수많은 실패 모드가 있습니다. 에이전트 사회에서 어떤 ‘조직 병리’가 가장 나타나기 쉽다고 생각하십니까? 어떻게 예방할 수 있을까요?

MAST의 세 분류에 대조하면 인터페이스 불명확과 책임 중복, 서로 다른 목표 이해와 하위 단계의 정보 오해, 거짓 ‘완료’ 주장이 있습니다. 오류의 연쇄 증폭(전화 놀이), 역할 간 순환 핸드오프, 수렴하지 않고 표류하는 에이전트 그룹 채팅도 있습니다. 계약 기반 인터페이스와 통일된 메시지 봉투, 인수 검증을 포함한 업무 상태 머신, 독립적인 관점의 교차 검증, 역할 간 책임 전가 감지로 예방합니다.

4. (★★★) 관리자 패턴에서 여러 하위 에이전트가 병렬로 실행될 때 한 하위 에이전트의 발견으로 다른 하위 에이전트의 작업이 무의미해질 수 있습니다(예: 검색 업무에서 한 에이전트가 이미 답을 찾음). ‘하나가 성공하면 모두 중단’하는 효율적인 연쇄 종료 메커니즘을 설계해 보십시오.

하위 에이전트가 관리자에게 target_found를 보내면 관리자가 terminate를 브로드캐스트합니다. 각 하위 에이전트는 ReAct 루프의 안전 지점에서 종료 신호를 주기적으로 확인하고 브라우저 세션 닫기, 잠금 해제, 파일 쓰기 완료 같은 정상적인 정리를 마친 뒤 종료합니다.

5. (★★★) 이 장에서 소개한 낙관적 잠금 메커니즘은 단일 파일의 동시 쓰기 충돌을 해결합니다. 하지만 실제 멀티 에이전트 시스템의 공유 파일 시스템은 파일 간 의미 충돌, 네임스페이스 오염(에이전트가 임의로 파일을 만들어 디렉터리가 혼란스러워짐), 단일 실패 지점(에이전트 하나가 실수로 모든 파일을 삭제함) 같은 문제도 겪습니다. 더 견고한 파일 시스템 거버넌스 메커니즘을 어떻게 설계하시겠습니까?

구역별 거버넌스를 적용합니다. 표 10-4의 네 영역으로 나누고 비공개 스크래치패드로 시행착오 영역을 격리합니다. 의미 충돌에는 오케스트레이션 계층이 디렉터리 단위 잠금 파일을 지정하고 변경 전에 디렉터리 잠금을 획득하도록 요구합니다. 네임스페이스 오염에는 디렉터리·이름 규칙을 적용합니다. 단일 실패 지점에는 버전 관리 시스템을 사용하여 이력에서 롤백할 수 있게 하고 권한을 최소화합니다.

6. (★★★) 시장 메커니즘 기반 에이전트 협업(Pinchwork, RentAHuman)은 거래 관계를 도입합니다. 한 에이전트가 업무를 완수하도록 다른 에이전트(또는 사람)에게 비용을 지불합니다. 고용주 에이전트가 실행자의 납품 품질을 자동으로 어떻게 측정할 수 있을까요? 실행자는 완료했다고 주장하지만 고용주는 품질 미달이라고 판단하면 누가 분쟁을 중재할까요? 악화가 양화를 구축하는 일을 어떻게 막을 수 있을까요?

인수 검사는 에이전트 궤적을 읽는 데 그치지 않고 테스트 실행, 렌더링된 스크린샷, 도구 검사 같은 결정론적인 외부 검증을 사용해야 합니다. 생성-검증 난도의 비대칭을 활용하여 인수 비용을 낮춥니다. 분쟁은 독립적인 제3자 검토 에이전트가 중재하고 자금은 에스크로에 둡니다. 악화가 양화를 구축하지 않게 하려면 과거 납품에 근거한 평판 시스템으로 가격 신호를 품질에 연결합니다.

7. (★★) RentAHuman은 에이전트가 암호화폐로 사람을 고용하게 하여 전통적인 인간-기계 관계를 뒤집습니다. 이 모델이 널리 퍼지면 에이전트 경제에서 사람은 어떤 역할을 맡게 될까요? 에이전트가 완수할 수 없는 물리적 업무만 수행하게 될까요?

사람은 에이전트가 할 수 없는 물리적 업무만 수행하지 않습니다. 현장 지각과 현실 세계의 피드백처럼 생성 시점에 에이전트가 이용할 수 없었던 정보를 제공하고, 최종 인수자와 분쟁 중재자 역할을 하며, 법적·책임 주체로서 승인과 설명 책임을 집니다. 목표를 설정하고 가치 판단을 내리며 정보 비대칭이나 도덕적 경계가 있는 곳에서 견제 역할도 합니다.

8. (★★) 인간 사회에 분업이 필요한 이유는 각 개인의 능력에 한계가 있기 때문입니다. 프런트엔드 개발자는 백엔드를 모를 수 있고 디자이너는 운영을 모를 수 있습니다. 하지만 대규모 모델은 ‘제너럴리스트’에 가깝습니다. 연구에 따르면 순수한 텍스트 사고 업무에서는 동일한 연산량을 부여한 단일 에이전트보다 멀티 에이전트 토론이 낫지 않습니다. 그렇다면 여러 에이전트의 진정한 이점은 어디에 있을까요?

1. 실행 결과나 시각적 스크린샷 같은 외부 피드백을 도입하여 생성 시점에는 없던 정보를 가져옵니다.
2. 목표와 역할 정의가 서로 다른 여러 에이전트가 인간 사회처럼 토론하고 경쟁하여 단일 에이전트의 맹점을 피하도록 돕습니다.
3. 여러 에이전트 사이의 컨텍스트 격리로 컨텍스트 창 한계를 넘어 매우 긴 도구 호출 사슬을 지원합니다.

9. (★★★) 이 장은 ‘공유 컨텍스트’와 ‘비공유 컨텍스트’를 멀티 에이전트 시스템의 핵심 설계 차원으로 봅니다. 공유 컨텍스트에서는 모든 에이전트가 같은 정보를 볼 수 있어 조율이 쉬워 보입니다. 하지만 The Three-Body Problem에서 Trisolaran의 정신은 완전히 투명한데도 기술 발전은 정체됩니다. 종이 클립 사고 실험도 집단이 같은 목표에 수렴하면 다양성을 잃는다는 점을 보여 줍니다. 멀티 에이전트 시스템에서는 효율성과 다양성의 균형을 어떻게 맞출 수 있을까요?

완전한 공유는 사고 관성과 오류 연쇄를 증폭하며 격리가 인지적 다양성을 만듭니다. 서로 다른 프롬프트나 모델로 독특한 사고 편향(브레인스토밍, 토론)을 만들고, 교차 검증기에는 앞선 사고 과정이 아니라 원시 증거만 보여 줍니다.

10. (★★★) 코딩 에이전트에 30단계와 300단계의 예산을 각각 배정합니다. 작업 전략은 어떻게 달라야 할까요? 연구에 따르면 단계 예산을 단순히 늘려도 성능 향상이 보장되지 않으며 에이전트가 얕은 검색 뒤에 성급히 ‘포화’될 수 있습니다. 적은 예산에서는 핵심 기능을 빠르게 완성하고 큰 예산에서는 계획, 테스트, 검토 단계를 추가하여 늘어난 연산 리소스를 충분히 활용하게 하는 ‘예산 인식’ 메커니즘을 설계해 보십시오.

매 단계 프롬프트에 총예산과 남은 예산을 주입하고 남은 비율에 따라 탐색/활용 가중치를 동적으로 조절합니다. 예를 들어 적은 예산(30단계)에서는 계획과 검토를 건너뛰고 핵심 기능과 기본 검증을 곧바로 수행합니다. 큰 예산(300단계)에서는 계획, 구현, 테스트, 검토·개선을 차례로 수행하고 이정표 체크포인트로 진행 상황을 평가하여 얕은 포화를 막습니다.

11. (★★) 이 장은 ‘조기 종료’를 게으른 가짜 완료, 성급한 포기, 거짓 성공의 세 종류로 나눕니다. 세 가지 모두의 해법이 검증으로 수렴하는 이유는 무엇일까요?

공통된 근본 원인은 업무 종료 여부를 모델의 자기 선언으로 결정한다는 점입니다. ‘완료’는 주장이며 증명이 아닙니다. 검증기의 조건은 다음과 같습니다. ① 실제 관찰(테스트 실행, 스크린샷 렌더링, 실제 환불 입금 확인)을 근거로 삼습니다. ② 명시적인 완료 정의에 따라 항목별로 확인하여 게으른 가짜 완료와 거짓 성공을 포착합니다. ③ 실패 결론도 검증하여 성급한 포기를 포착합니다. ④ 명시적인 종료 조건(라운드/예산 상한)과 결합하여 조기 종료의 반대 극단인 폭주 루프로 미끄러지는 일을 막습니다.

12. (★★) 표 10-3은 멀티 에이전트 시스템과 운영체제를 항목별로 대응시킵니다. 표에 몇 행을 더 추가해 보십시오. 가상 메모리와 페이징, 파일 권한, 교착 상태 감지, 스케줄링 알고리즘은 각각 에이전트 세계에서 무엇에 해당할까요? 에이전트 세계에 대응물이 없는 운영체제 개념은 무엇이며 그 이유는 무엇일까요?

가능한 확장은 다음과 같습니다. 가상 메모리/페이징 ↔ 컨텍스트 압축과 검색(뜨거운 정보는 창 안에 두고 차가운 정보는 파일과 기억 저장소로 스왑 아웃했다가 필요할 때 가져옴), 파일 권한 ↔ 도구 허용 목록, 읽기 전용 마운트, 자격 증명 경계, 교착 상태 감지 ↔ 순환 핸드오프와 상호 대기 감지(핸드오프 횟수 상한과 시간 제한), 스케줄링 알고리즘 ↔ 비동기 이벤트 처리(4장)입니다. 대응물이 없는 이유는 강제 방식의 차이입니다. 프로세스의 명령은 하드웨어가 강제하지만 에이전트는 높은 확률로 프롬프트를 따를 뿐입니다.