에이전트 개념 정리 — 워크플로우 · 하네스 · Context/Memory · MCP/A2A

LLM으로 답을 생성하는 시스템도 다음 실행 순서를 코드로 고정할 수 있습니다. 반대로 모델이 관측 결과를 보고 도구를 고르는 시스템은 같은 요청에도 다른 경로를 거칠 수 있습니다. 이 차이를 기준으로 워크플로우와 에이전트를 구분하고, 모델 밖에서 실행을 담당하는 하네스와 도구 설계로 이어집니다.

1장 · 에이전트 — 워크플로우와의 경계

판단 기준: 다음 순서를 누가 정하는가

발표자는 LLM 사용 여부와 실행 순서의 결정 주체를 구분합니다. 워크플로우도 LLM을 호출할 수 있으므로 LLM이 들어 있다는 사실만으로 에이전트라고 부르기는 어렵습니다. 코드를 읽어 다음 실행을 알 수 있는지, 모델이 중간 결과를 보고 다음 행동을 정하는지가 발표에서 제시한 구분입니다.

슬라이드는 표의 정의를 Anthropic의 Building Effective Agents(2024-12)에서 가져왔다고 밝히고, Simon Willison(2025-09)의 문장 *“An LLM agent runs tools in a loop to achieve a goal."*을 함께 인용합니다.

→ 전사 03:00–04:14

예시: 같은 CS 환불 문의를 두 방식으로

환불 문의에 답하는 예시에서는 사용자가 선택한 카테고리로 다음 단계를 고정할 수도 있고, 모델이 구매 내역과 정책을 조회하며 필요한 정보를 되물을 수도 있습니다.

워크플로우의 실패 예시는 사용자가 카테고리를 결제로 고르고 본문에는 “환불하고 싶어요"라고 쓴 경우입니다. 결제 정책이 프롬프트에 들어오면 LLM이 없는 환불 정책을 근거로 답할 수 있다는 것이 발표자의 설명입니다. 에이전트는 관측 결과에 따라 되물을 수 있지만, 같은 질의에도 도구 호출과 대화 턴이 달라져 비용 예측과 디버깅이 어려워집니다.

아래는 발표자가 제시한 실행 예시입니다. 같은 입력이 반드시 이 순서를 따른다는 뜻은 아닙니다.

→ 전사 04:14–09:08

에이전트의 실체는 while 루프

발표에서 에이전트는 요청을 받아 모델의 판단과 도구 실행을 반복하는 while 루프로 설명됩니다. 모델이 tool_use를 내면 하네스(런타임)가 실행하고, tool_result를 Context에 붙여 다시 모델에 전달합니다. 이 예시의 종료 신호는 도구 호출이 없는 응답입니다.

사용자 요청 → [ 모델: 도구를 부를지, 끝낼지 ]
                  │ tool_use              ▲ tool_result (관측을 Context에 붙임)
                  ▼                       │
              [ 도구 실행 — 하네스(런타임)가 실행 ] ─┘
              도구 호출이 없는 응답 → 최종 응답
              최대 턴 · 오류에 닿으면 하네스가 끊는다

루프의 종료 조건은 하네스에도 둡니다. 설계상 도구 호출 10번이면 충분한 작업을 모델이 20번, 30번 반복할 수 있기 때문입니다. 발표자가 “루프가 터진다"고 소개한 상황입니다. 최대 호출을 10번으로 정해 모델의 판단과 무관하게 10번째에 최종 응답을 내도록 강제하는 구성이 예로 나옵니다.

→ 전사 09:02–10:40

ReAct와의 관계

발표자는 ReAct와 현대 Agent Loop가 관측·판단·실행을 반복한다는 점에서 같은 구조라고 설명합니다. 차이는 호출과 종료 형식의 규약을 두는 곳입니다. 고전 ReAct는 프롬프트에서 텍스트 형식을 약속하고 코드가 파싱하며, tool calling을 학습한 모델은 구조화된 호출을 내고 런타임이 실행합니다.

ReAct를 ChatGPT 초기 프롬프트 엔지니어링에서 널리 쓰던 패턴으로 소개하면서, 발표자는 관심이 컨텍스트 엔지니어링과 하네스 엔지니어링으로 옮겨 왔다고 봅니다. 모델 비교표의 tool calling 지원 항목도 이 흐름의 사례로 들었습니다.

이후의 구체적인 예시는 주로 Claude Code입니다. 지시부터 최종 답변까지 Edit·Bash 호출과 결과 관측을 반복하는 과정을 루프로 설명하며, Codex도 같은 방식으로 이해할 수 있다고 덧붙입니다.

→ 전사 10:27–13:12

적용 기준: 에이전트가 더 “좋은 것"은 아니다

발표자는 실행 흐름을 화이트보드에 명확히 그릴 수 있으면 워크플로우를 권합니다. 분기와 예외가 계속 늘어 코드로 관리하기 어려워지거나, 중간 결과를 봐야 다음 행동을 정할 수 있을 때 에이전트를 고려하자는 제안입니다. 비용과 예측 가능성에 관한 설계 권고로 읽어야 합니다.

실행 경로를 미리 그릴 수 있으면 에이전트를 쓰지 않는다. 그릴 수 없을 때 — 중간 결과를 봐야 다음이 정해질 때 — 에이전트가 필요하다.

→ 전사 13:12–14:35

실무의 형태: Agentic Workflow, 그리고 반대 방향

발표는 전체 파이프라인을 워크플로우로 고정하고 판단이 필요한 구간을 에이전트에 맡기는 Agentic Workflow를 프로덕션에서 흔한 형태로 소개합니다. 슬라이드는 이를 Anthropic과 OpenAI 가이드의 공통 권고로 제시합니다.

"저 환불하고 싶어요" (카테고리 · 상품 고르지 않음)
  → LLM 의도 분류 (닫힌 집합: 배송 조회 · 환불/교환 · 결제 · 기타 — 코드가 다음을 안다)
      ├ 배송 조회 등 단순      → 워크플로우: 상품 조회 → 답변 (비용 고정)
      ├ 환불 · 교환, 판단 필요 → Agent에 위임: 구매 내역 조회 · CS 정책 검색 · 되묻기
      └ 기타 · 분류 신뢰도 낮음 → 담당자 라우팅 (사람이 답한다)
  → 발송

이 예시는 사용자가 카테고리를 직접 고르는 대신 모델이 의도를 분류합니다. 사용자의 카테고리 오입력 경로를 줄이는 구성이며, 모델의 분류 오류까지 사라진다는 뜻은 아닙니다. 분류 신뢰도가 낮은 문의는 담당자에게 보냅니다. 에이전트의 반복 호출을 환불·교환 갈래에 모으면 어느 문의에서 호출 횟수가 달라지는지 구분하기 쉬워집니다. 다른 갈래도 LLM 분류와 조회를 거치므로 그 구간에 비용이 없다는 의미는 아닙니다.

발표자는 이미 확실히 분류한 케이스를 워크플로우로 처리하고, 조건문으로 고정할 만큼 사례가 모이지 않은 판단은 에이전트에 맡기며, 에이전트도 풀기 어려운 문의는 CS 담당자에게 보내는 구성으로 설명합니다.

포함 관계를 반대로 구성할 수도 있습니다. 코드로 정한 워크플로우를 도구 하나로 제공하면 모델은 그 도구를 언제 부를지 정하고, 내부 순서는 코드가 맡습니다.

환불 처리 (모델에게는 도구 하나)
  ① 주문·배송 조회
  ② LLM 사유 판정            ← 모델이 고르는 건 여기 한 칸
       ├ 변심   → 반품비 차감
       ├ 하자   → 전액 + 품질 등록
       └ 오배송 → 전액 + 재발송
  ③ 공통 구간: 결제 취소 → 알림 발송 → 원장 기록
  → {"refunded": true, "amount": 28000}   ← 모델이 돌려받는 것은 이 한 줄

발표자는 사유 판정도 코드로 만들 수 있어 예시가 다소 인위적이라고 덧붙입니다. 이 예시가 설명하려는 것은 코드로 고정할 구간과 모델에 맡길 구간을 시스템의 성격에 맞게 조립하는 방법입니다.

→ 전사 14:35–17:26

2장 · 하네스 — 모델을 감싸는 실행 골격

왜 하네스인가

같은 Opus 모델을 쓰던 Cursor와 Claude Code에서 작업 결과가 다르게 느껴졌다는 경험이 발표의 출발점입니다. 발표자는 그 차이를 모델 밖의 설계, 곧 하네스에 주목하게 된 계기로 소개합니다. 비교 실험으로 원인을 입증한 사례는 아닙니다.

발표자가 고른 하네스 엔지니어링의 정의입니다.

AI 모델 자체의 추론 능력을 제외하고, AI 에이전트가 실제 업무 환경에서 안전하고 안정적으로 실행되도록 주변 환경 · 규칙 · 도구 · 검증 장치를 설계하는 시스템 구축 기술.

정의의 범위에는 환경·규칙·도구·검증 장치를 함께 설계하는 일이 들어갑니다. Harness의 어원인 마구·고삐를 설명하면서, 발표자는 이탈을 막는 기능뿐 아니라 시스템이 의도한 방향으로 실행되도록 유도하는 역할도 강조합니다.

→ 전사 17:26–20:50

하네스 한 장 그림과 Claude Code 실물

발표자는 저장 계층, Context, 루프와 도구, 권한·상한·관측을 하네스의 구성요소로 묶었습니다. 아래 표는 직접 그린 뒤 AI로 정리한 도식에 Claude Code 사례를 대응시킨 것으로, 필요한 요소를 모두 열거한 분류는 아니라는 단서가 있습니다. Claude Code가 자신을 agentic harness라고 부르기도 한다는 설명도 발표자의 소개입니다.

모델 자체는 이 분류에서 제외됩니다. MCP도 도구 한 개보다 사용자가 커스텀 도구를 연결할 수 있게 하는 프로토콜로 설명합니다.

Context는 저장소 하나가 아니라 이번 모델 호출에 넣는 정보입니다. 시스템 프롬프트·사용자 질문·이전 답변과 함께 필요한 저장 정보를 골라 구성하며, Context Window가 유한하므로 매번 무엇을 넣을지 정해야 합니다. 발표에서 말하는 컨텍스트 엔지니어링은 이 선택과 구성 작업입니다.

• State는 현재 진행 상태입니다. plan mode의 네 단계 중 “1·2 완료, 3·4 남음"을 저장하고 Context에 다시 넣어 3단계를 빠뜨리지 않도록 돕습니다.
• 대화 이력은 질문·답변·도구 실행과 결과를 JSON Lines 트랜스크립트로 저장합니다. 터미널이 꺼져도 기록에서 이어갈 수 있게 합니다. 모델에 다시 물어 같은 응답을 얻는 것으로는 이전 실행을 복원할 수 없다는 설명입니다.
• Long-term Memory는 과거 세션에서 “이 사용자가 이걸 하지 말라고 했다” 같은 내용을 추려 메모리 파일로 만드는 계층입니다. 발표자는 사람이 CLAUDE.md를 작성하는 것과 에이전트가 장기 기억을 남기는 일을 구분합니다.
• Domain Knowledge는 CLAUDE.md와 스킬처럼 미리 제공한 지식·지침입니다. 발표의 예는 네이버 내부 N3R과 커넥트로, 모델이 알지 못하는 플랫폼의 용도와 사용법을 스킬로 제공하는 구성입니다.

이 분류는 제품 문서의 분류와도 다릅니다. 발표자에 따르면 Claude Code 문서는 CLAUDE.md가 세션 밖에 남아 실행마다 Context에 주입되므로 “메모리"로 분류합니다. 발표자는 그 내용이 프로젝트 규칙·절차·도메인 지식이라는 점에서 Knowledge로 묶었습니다.

권한·상한·관측은 실행을 제어하고 기록합니다. 발표자는 상한의 예로 Context Window가 대략 80% 이상 차면 auto compact하는 동작과, 같은 오류를 반복하며 도구를 계속 호출할 때 루프를 끊는 동작을 들었습니다. 이 수치는 발표에서 든 사례입니다.

→ 전사 20:47–29:44

없으면 어떻게 되는가

발표자는 하네스 구성요소가 빠졌을 때의 실패를 통해 역할을 설명합니다. 해당 슬라이드는 영상에 잡히지 않아 이 구간은 전사를 바탕으로 정리했습니다.

루프가 없으면 한 번 응답하고 끝나며, 도구가 없으면 텍스트로 설명해도 요청한 작업을 실행하지 못합니다. State가 없으면 어디까지 진행했는지, 대화 이력이 없으면 직전에 무엇을 주고받았는지 잃을 수 있습니다.

메모리 디렉토리는 같은 사용자 지적을 다음 세션에도 반영하는 데, Knowledge는 사용자의 환경에 맞는 판단을 하는 데 쓰입니다. 발표자는 이를 빼면 매번 처음 만난 사용자처럼 대응하거나 환경에 맞지 않는 답을 할 수 있다고 설명합니다.

권한과 상한은 행동의 범위와 반복을 제한합니다. 배포·위키 문서 생성 같은 변경을 통제하고, 종료 조건 없이 도구 호출과 토큰·비용이 늘어나는 상황을 막는 역할입니다. 발표의 권고는 이 요소들을 모두 넣으라는 것이 아니라 각 시스템에 필요한 것을 선택하라는 것입니다.

→ 전사 29:44–31:47

Claude Code 설계에서 가져올 것 세 가지

발표자는 2026년 3월에 유출됐다고 소개한 Claude Code 소스의 분석 자료에서 설계 패턴을 골랐습니다. 슬라이드도 분석 자료의 일부 패턴을 가져왔다고 밝힙니다. 아래 내용은 그 발표 설명의 정리입니다.

자주 쓰는 동작에는 전용 도구를 둡니다. 범용 Bash의 cat api.py로 파일을 읽을 수 있어도 cat 출력에는 편집 위치를 찾을 줄번호가 없습니다. 발표자는 grep·find 출력 잘림, sed의 검증 없는 덮어쓰기, Bash 전체에 묶인 권한을 전용 도구를 설계한 이유로 설명합니다.

시스템 프롬프트에는 파일 읽기에는 Read, 검색에는 Grep, 수정에는 Edit, 실행에는 Bash를 쓰도록 선택 기준을 둡니다. 발표자는 도구를 나누는 일과 모델이 고를 기준을 제공하는 일이 함께 필요하다고 해석합니다.

● Edit(src/app/api.py)
  ⎿ Error: File has not been read yet. Read it first before writing to it.

다음 패턴은 의도와 실행 사이의 통제입니다. 발표의 예시에서는 rm -rf나 git push --force 같은 되돌리기 어려운 작업을 그대로 실행하지 않도록 명시적 deny rule → 명시적 allow rule → 명령 위험도 분류 → 애매하면 사용자 승인 순서로 판단합니다. 읽기 10번을 순차로 기다리게 하기보다 읽기·검색은 병렬로 처리하고, 충돌할 수 있는 파일 수정은 순차로 실행하며, 서브에이전트에는 필요한 도구만 제공합니다.

도구 = 스키마 + 읽기/쓰기 여부 + 병렬 가능 여부 + 권한 정책

마지막은 세션 중단을 고려한 복구입니다. 이 구간은 영상에 슬라이드가 없어 전사로만 정리했습니다. 발표자는 Context Window가 차기 전에 대화와 도구 결과를 auto compact하고, 수정 전에 체크포인트를 만들며, 트랜스크립트를 외부에 저장하는 패턴을 소개합니다. Esc로 수정을 중단했을 때 되돌리는 동작과 resume으로 다음 날 작업을 이어가는 동작이 사례로 나옵니다.

이 사례들은 모델의 성능과 별도로 도구 선택, 실행 제어, 상태 복구를 설계해야 한다는 발표자의 판단을 뒷받침합니다.

→ 전사 32:16–39:00

얇아지는 것과 두꺼워지는 것

발표자는 모델의 부족한 판단을 보완하던 절차와 실행을 통제하는 층을 구분합니다. CLAUDE.md나 AGENTS.md에 실수를 막으려고 추가한 절차는 새 모델에서도 필요한지 확인할 대상입니다. 모델이 개선됐어도 불필요한 절차를 계속 따르면 토큰을 더 쓰고 기존 방식의 결과를 반복할 수 있다는 설명입니다. 아래 비교는 슬라이드에 “(가상 사례)“로 표시돼 있습니다.

절차를 줄이기 전에는 그 절차 없이도 잘 수행하는지 확인해야 한다는 단서가 붙습니다. 프로젝트 고유의 요구와 권한 경계는 계속 유지합니다.

GitHub MCP에서 gh CLI로 옮긴 사례도 이 관점에서 소개합니다. 이 구간은 슬라이드가 영상에 없어 전사로만 정리했습니다. 발표자는 이슈 생성·목록·조회·코멘트별로 나뉜 몇십 개 도구의 이름·설명·스키마가 Context를 차지한다고 설명합니다. 모델이 CLI 사용법을 읽고 명령을 조립할 수 있으면, CLAUDE.md에 “Git 작업은 gh CLI로 한다"는 지침을 두고 Bash로 실행하게 할 수 있다는 예시입니다. 여러 전용 도구를 계속 제공할 필요가 있는지 다시 살피자는 취지입니다.

통제 계층의 사례로 슬라이드는 Anthropic의 Improving Fable 5’s biology safeguards(2026-08-07)를 인용합니다. 발표의 설명에 따르면 Fable 5는 일부 생물학 과제에서 전문가를 능가했고, 출시 때 거의 모든 생물학 질의를 차단하는 분류기를 두었습니다.

생물학 관련 요청 → 안전 분류기 (위험 · 이중 용도인가 판별 — 모델 밖, 하네스 그림의 권한 칸)
                    ├ 허용          → Fable 5 가 답한다 (일상 건강 · 교육 질문)
                    └ 차단 → fallback → Opus 5 로 우회해 답한다 (바이러스학 · 독성학 · 분자 설계)

슬라이드는 출시 뒤 분류기 규칙을 수정해 오탐을 85% 줄였다고 소개합니다. 발표자는 이를 통제 계층도 측정하고 개선하는 사례로 읽습니다. 데이터 관련 도구를 쓸 때 Fable을 선택했는데 Opus로 바뀐 경험도 덧붙였지만, 본인에게만 생긴 일인지는 모른다는 단서를 달았습니다. 분류기가 요청 의도를 더 잘 구분하도록 개선하는 연구에 관한 설명도 발표를 따른 것입니다.

얇아지는 것은 모델을 보조하던 절차, 두꺼워지는 것은 모델을 통제하는 층이다. “얇게 가져가라"도, “하네스 엔지니어링을 해야 한다"도 맞다. 말하는 대상이 서로 다를 뿐이다.

→ 전사 39:00–45:22

3장 · 도구 — 에이전트의 행동 범위

도구 집합이 곧 행동 범위

하네스에서 도구는 에이전트가 실제로 할 수 있는 작업을 정합니다. 발표자는 사내 논의에서 도구 설계에 관한 질문이 많아 이 부분을 별도 장으로 다뤘습니다.

도구의 이름 · 설명 · 스키마 · 응답 · 에러는 API 문서가 아니라 모델의 다음 행동을 정하는 프롬프트 표면이다.

Claude Code에 Read만 있다면 파일을 읽고 수정 방법을 설명할 수 있지만, 실제 편집에는 Edit 같은 도구가 필요합니다. 같은 차이를 환불 문의에 적용한 예시입니다.

발표자는 제품이 해결할 문제를 정한 뒤, 그 작업을 수행하는 데 필요한 도구를 먼저 명시하라고 권합니다. 모델의 판단 능력이 높아져도 제공하지 않은 실행 수단이 생기지는 않기 때문입니다.

→ 전사 45:22–48:16

호출자가 모델이면 무엇이 달라지는가

기존 구매·환불 API를 감싸고 입력 스키마를 제공하면 도구를 실행할 수 있습니다. 그러나 발표자는 모델이 도구 명세를 읽고 호출하며 응답으로 다음 행동을 정한다는 점까지 설계해야 한다고 봅니다.

모델이 보는 Context에는 get_purchase_history(from, to), search_policy(q), process_refund(order_id, reason) 같은 명세와 사용자 요청 “환불하고 싶어요”, 호출 결과가 함께 들어갑니다. 명세는 도구 선택과 인자 구성을 돕고, 성공·실패 응답은 다음 판단의 근거가 됩니다. 둘 다 유한한 Context를 차지합니다.

발표자가 강조한 예시는 오류 응답입니다. 사용자가 “최근 3개월 구매 내역을 확인해줘"라고 했지만 리소스 제한 때문에 도구가 한 번에 최대 7일만 조회할 수 있다고 가정합니다.

이 표는 오류 메시지에 따라 모델이 취할 수 있는 다음 행동을 비교한 예시입니다. 기존 API의 E104는 개발자가 문서나 담당자를 통해 뜻을 알아내 예외 처리할 수 있습니다. 에이전트가 복구하도록 설계하려면 응답에 필요한 조건을 제공해야 한다는 것이 발표자의 주장입니다.

→ 전사 48:16–52:52

도구의 위층을 설계할 때 묻는 다섯

이 표는 Anthropic의 Writing effective tools for AI agents(2025-09-11)에서 가져왔다고 발표자가 밝힌 설계 항목입니다. 도구의 크기, 선택 기준, 복구 정보, 출력량, 재시도의 부작용을 함께 봅니다.

작업을 묶을 때는 재사용 범위를 확인해야 합니다. 사용자 ID와 캘린더 ID 조회가 일정 등록에만 쓰이면 일정 등록 도구 안에서 실행할 수 있습니다. 모델이 매번 호출 순서와 의존성을 추론하게 할 필요가 줄어듭니다. 다른 작업에서도 재사용하는 경우는 구분해야 한다는 단서입니다.

발표자는 get/fetch/load처럼 역할을 구별하기 어려운 이름이 모델의 시험 호출과 토큰 사용을 늘릴 수 있다고 설명합니다. 약어 응답은 모델이 뜻을 추측하게 하고, 쓰기 도구의 중간 실패는 재시도가 중복 작업을 만들 수 있으므로 응답과 실행을 함께 설계해야 합니다.

발표가 인용한 도구 개선 과정입니다.

도구 초안 (먼저 대충 만든다)
 → 평가 태스크 생성 (실제 업무 기반 수십 개)
 → 에이전트 루프로 실행 (API를 직접 돌린다)
 → 트랜스크립트 분석 (어디서 막혔나)
 → 도구를 고친다 (설명 · 스키마 · 응답)
 → 처음으로 반복 — 여기서 나온 관찰이 다음 수정이 된다

“Even small refinements to tool descriptions can yield dramatic improvements.” — 도구 설명을 조금만 다듬어도 결과가 크게 달라진다.

발표자는 도구 정의를 평가셋과 트랜스크립트로 측정하며 릴리스마다 고치는 대상으로 설명합니다. 예전에 10줄, 20줄씩 쓴 설명도 모델이 개선된 뒤에는 필요한지 다시 확인할 수 있습니다.

→ 전사 52:52–57:56

도구 계약: 스키마에 실행 정책을 붙인다

도구의 명세와 응답에 실행 정책을 함께 기록하자는 제안입니다. 발표는 2장의 Claude Code 사례를 환불 도구에 적용해 읽기·쓰기 여부, 병렬 실행 여부, 승인 조건을 명시합니다.

tool: process_refund(order_id, reason)
  고객의 상품 환불 요청을 처리한다 — 결제 취소 · 알림 발송
  ─ 텍스트 층 (3-1에서 다룬 것): name · description · input_schema · response · error
  읽기 / 쓰기  — write
  병렬 가능    — no
  권한         — requires approval

발표자는 병렬 가능 여부를 yes/no로 정하는 데서 더 나아가 최대 동시 호출 수도 기록할 수 있다고 덧붙입니다. 계약을 관리하는 방식에 따라 필요한 메타데이터는 늘어날 수 있습니다.

→ 전사 58:02–59:02

MCP — 도구를 만드는 자리가 조직 쪽으로

발표의 MCP 예시는 쇼핑 어시스턴트와 고객센터 어시스턴트가 구매·환불·배송 조직의 API를 함께 사용하는 상황입니다. 실제 사내 과제가 아니라 설명용 예시라는 단서가 있습니다.

각 에이전트 조직이 API를 감싸 도구로 만들면 구매 API가 바뀔 때 각 조직의 도구를 수정해야 합니다. 예시에서는 API를 가진 조직이 MCP 서버를 운영하고 도구의 설명·입력·응답을 관리하며, 에이전트 조직은 사용할 서버를 연결합니다.

쇼핑 어시스턴트 (MCP Client)  ─┬─ 구매 조직 MCP Server ── 구매 내역 조회 도구 → 구매 REST API
고객센터 어시스턴트 (MCP Client) ┼─ 환불 조직 MCP Server ── 환불 처리 도구   → 환불 REST API
                               └─ 배송 조직 MCP Server ── 배송 조회 도구   → 배송 REST API
클라이언트 2 + 서버 3 → 선은 여섯 개 그대로. 줄어든 것은 조합마다 다시 만들던 래퍼다

이 구성에서 구매 API의 변경은 구매 조직이 자기 MCP 서버에 반영합니다. 줄어드는 것은 에이전트와 API 조합마다 따로 만들던 래퍼입니다. 발표자는 에이전트를 만드는 조직과 API를 가진 조직이 나뉘어 있을 때 도구 관리 책임도 이처럼 나눌 수 있다고 설명합니다.

→ 전사 59:02–61:31

MCP와 A2A — 결과를 기대하는가, 판단을 기대하는가

발표자는 Anthropic의 MCP와 Google의 A2A를 기능 호출과 목표 위임으로 구분합니다. 같은 요청 “배송이 너무 늦는데, 취소하고 환불받을 수 있을까?“를 보내더라도 상대에게 기대하는 작업이 다르다는 예시입니다.

A2A의 상대는 자기 도구·루프·Context를 가진 별도의 에이전트입니다. 발표에서는 위임한 쪽이 결과를 받고 상대의 판단 과정은 보지 못하는 형태로 설명합니다. 그 때문에 신뢰하고 맡길 수 있는 작업에 사용해야 한다는 권고로 이어집니다.

→ 전사 61:31–63:23

마무리 — 설계 질문 넷과 세 문장

발표는 설계할 때 확인할 질문으로 마칩니다. 워크플로우와 에이전트의 경계, 도구 집합, 빠진 하네스 요소를 실제 시스템에 대입하는 질문입니다.

• 이 문제의 실행 경로를 지금 순서도로 그릴 수 있는가? 그릴 수 있다면 왜 에이전트가 필요한가?
• 에이전트에 맡기는 구간과 코드가 고정하는 구간의 경계를 어디에 두는가?
• 이 에이전트가 풀 수 있는 문제의 범위, 곧 도구 집합을 명시적으로 그려봤는가? 그 범위 밖의 문제를 만나면 어떻게 되는가?
• 하네스 그림에서 지금 비어 있는 칸은 무엇인가? 비어 있으면 그 자리에서 무슨 일이 생기는가?

마지막 슬라이드에는 이 문장들이 실렸습니다.

에이전트는 모델이 다음 행동을 선택하는 시스템이다. 실행 경로를 미리 그릴 수 있으면 에이전트를 쓰지 않는다. 모델은 생각하지만, 하네스가 일하게 만든다.

발표자는 두 번째 문장을 말로 설명하면서 “비용 측면에서"라는 조건을 붙였고, 세 번째에는 적당히 좋은 모델도 필요하다는 단서를 더했습니다. 이 문장들은 모델의 필요성을 부정하기보다 실행 경로와 모델 밖의 설계에도 관심을 두자는 권고입니다. 설계 질문과 발표에서 뺀 설명은 사내 위키에 공유했다고 하거나 공유할 계획이라고 안내했습니다.

→ 전사 63:23–65:36

발표 배경과 목표

발표자 박슬기는 사내 에이전트 아키텍처 스터디와 자료 조사에서 같은 용어를 서로 다르게 쓰는 문제를 겪었다고 설명합니다. 발표의 목표는 워크플로우와 에이전트를 구분하고, 하네스가 모델 밖의 어떤 구성요소를 뜻하는지 설명할 수 있게 하는 것입니다. 제시한 분류는 완결된 정의보다 후속 논의의 출발점이라는 단서가 붙었습니다.

발표는 에이전트, 하네스, 도구, 마무리 순서입니다. 예정된 슬롯은 90분이었고 실제 영상은 1시간 5분 남짓입니다.

→ 전사 00:00–03:00