02 · 발표 전사 — 에이전트, 개념부터 같이 정리해봐요

섹션의 시각은 슬라이드 전환을 기준으로 합니다. 본문은 faster-whisper large-v3-turbo 자동 전사를 슬라이드와 대조해 오인식을 교정하고, 말버릇과 반복을 줄여 존댓말 산문으로 다듬은 뒤 wwe 보존 윤문을 거친 기록입니다.

전사와 슬라이드를 대조할 때는 다음 범위를 고려해야 합니다.

• turbo 전사가 비어 있던 49:11 부근 30초와 알아듣기 어려운 몇 곳은 large-v3로 다시 전사해 채웠습니다.
• 영상에 잡히지 않은 덱 1·2·8·12·22·25·29·35·42·48쪽은 해당 섹션에 슬라이드 노트를 적지 않았습니다.
• 확정하기 어려운 단어는 추측해 바꾸지 않고 원 전사에 [?]를 붙였습니다.

대표 교정은 채찍 PT→ChatGPT, 와일루프→while 루프, 리액트→ReAct, “파이너에 써라”→Final Answer, 플랫모드→plan mode, 클로즈닷 MD→CLAUDE.md, 배시→Bash, 오프스→Opus, 페이블→Fable, 엔트로픽→Anthropic, 믿업→밋업입니다.

00:00 인사와 발표 배경

오늘 Tech Meetup 주제를 “에이전트 개념부터 같이 정리해보자"라는, 어찌 보면 꽤 모호한 것으로 잡았습니다. 먼저 이 주제로 밋업을 연 배경을 설명드리겠습니다.

작년에는 에이전트, 올해는 하네스라는 용어를 일상에서 아무렇지 않게 쓰고 있습니다. 그런데 대화를 해 보면 각자가 생각하는 에이전트와 하네스의 개념이 조금씩 다릅니다. 내가 잘 이해하지 못해서 상대의 말을 못 알아듣는 건지, 아니면 상대가 틀린 건지 헷갈리는 경험을 저는 많이 했습니다.

그러다 에이전트 아키텍처 스터디를 하게 됐는데, 거기서도 용어 문제가 계속 생겼습니다. 그래서 에이전트와 하네스, 여기에 잇따라 나오는 용어들이 어딘가에 깔끔하게, 공통의 개념으로 정리돼 있는지 직접 서베이를 해 봤습니다. 결과는 같은 개념을 벤더사마다, 아티클마다 다르게 부르고 있다는 것이었습니다.

그래서 용어에 매달리지 말고 “이런 개념들이 이런 걸 가리키는구나” 하고 이야기할 수 있는 자리가 있으면 좋겠다고 생각했습니다. 제가 정리한 개념이 정확히 맞지 않을 수도 있습니다. 그래도 정리하는 자리가 있어야 후속 논의가 이어질 수 있을 것 같아서 밋업을 준비했습니다.

양을 계속 줄이려 했는데 줄어들지 않아 시간은 90분으로 잡았습니다. Q&A는 중간에 받지 못할 수 있을 만큼 빠듯합니다. 질문은 채팅에 남겨 주시거나 나중에 메일로 보내 주시면 제가 취합해서 공유드리겠습니다.

00:00 가져갈 것 두 가지

귀한 시간을 내서 들어오셨으니 가져가는 것이 있었으면 해서 발표 목적을 두 가지로 잡았습니다. 첫 번째는 워크플로우와 에이전트를 구분할 수 있게 되는 것입니다. 각각이 무엇인지 개념적으로 알고 가시면 됩니다. 두 번째는 하네스가 모델 밖의 어떤 구성요소를 가리키는지 설명할 수 있게 되는 것입니다. 이 두 가지에 초점을 뒀습니다.

슬라이드 노트: 덱 3쪽. “끝나면 이 두 가지를 할 수 있게 되는 것이 목표입니다” / ① 워크플로우와 에이전트를 구분할 수 있다 / ② “하네스"가 모델 밖의 어떤 구성요소를 가리키는지 설명할 수 있다.

02:36 오늘의 흐름

오늘 다루는 내용은 크게 세 장입니다. 첫 번째는 에이전트, 두 번째는 하네스, 세 번째는 도구입니다. 마지막에 간단히 마무리하겠습니다.

슬라이드 노트: 덱 4쪽. 1절 에이전트란 — 워크플로우와의 경계 / 2절 하네스 — 모델을 감싸는 실행 골격 / 3절 도구 — 에이전트의 행동 범위 / 4절 마무리.

02:50 1절 에이전트란 — 워크플로우와의 경계

첫 번째는 에이전트입니다. “에이전트는 이것이다” 하고 설명하기보다, 에이전트를 이야기할 때 워크플로우와 혼용하거나 혼동하는 경우가 꽤 있어서 그 경계를 먼저 개념적으로 정리해 보려고 합니다.

슬라이드 노트: 덱 5쪽. “가져갈 판단 기준 하나 · 다음 실행 순서를 누가 소유하는가. 코드가 소유하면 워크플로우, 모델이 소유하면 에이전트입니다.”

03:11 워크플로우와 에이전트 — 다음 순서를 누가 정하느냐

개념은 텍스트로 가져왔습니다. 워크플로우와 에이전트는 둘 다 내부에서 LLM을 씁니다. 워크플로우는 저희가 원래 파이프라인이라고도 부르던 용어인데, LLM을 쓸 수도 있고 안 쓸 수도 있습니다. 그런데 내부에서 LLM을 쓰면 에이전트라고 혼동하는 경우가 있어서 이 둘을 나란히 가져왔습니다.

둘의 가장 큰 차이가 뭘까, 어떤 기준을 둬야 명확할까 생각해 봤을 때 “다음 순서를 누가 정하느냐"를 기준으로 삼으면 좋겠다고 판단했습니다. 지금 있는 상태에서 다음 상태로 넘어갈 때 그 순서가 코드로 정해져 있고, 누군가 코드를 읽었을 때 “이다음에는 이런 게 진행되는구나” 하고 알 수 있으면 워크플로우입니다. 코드를 봐도 다음이 무엇인지 모르겠다면, 모델이 정하는 쪽입니다. 제가 내린 정의는 이렇습니다.

슬라이드 노트: 덱 6쪽. 워크플로우 = LLM 호출과 도구 실행을 미리 정해둔 코드 경로로 엮은 것, 다음 순서는 코드가 정한다. 에이전트 = LLM이 관측 결과를 보고 다음 행동을 스스로 선택하며 목표까지 반복하는 것, 다음 순서는 모델이 정한다. 인용: “An LLM agent runs tools in a loop to achieve a goal.” (Simon Willison, 2025-09) — 위 정의는 Anthropic, Building Effective Agents (2024-12)를 그대로 따른 것.

04:14 같은 환불 문의, 두 방식 — 워크플로우

그림으로 보는 편이 정확할 것 같아서, 하나의 시스템을 두 가지로 풀어낸 예를 가져왔습니다. 같은 환불 문의를 푸는 시스템이라고 하겠습니다. 워크플로우는 순서를 코드가 고정합니다.

풀어서 설명하면 이렇습니다. CS 환불 문의에 답변해 주는 시스템을 만든다고 했을 때, 사용자는 CS 카테고리를 선택하고, 환불할 상품을 고르고, 문의 본문을 작성할 수 있습니다. 그러면 코드 내부에서는 먼저 CS 정책 검색을 합니다. CS 카테고리로 환불 정책 문서를 가져오고, 상품 ID로 상품 정보를 조회합니다. 그다음 프롬프트에 이 정책과 상품 정보, 문의 본문을 담아 LLM에게 답변을 생성시키고, 그 답변을 사용자에게 넘깁니다.

이런 경우가 워크플로우입니다. 지금 이 상태에서 다음 상태가 무엇인지 명확하게 읽히는 시스템입니다.

다만 약점이 있습니다. 사용자가 CS 카테고리를 결제로 잘못 골랐다고 해 보겠습니다. 결제 정책 검색 결과가 들어왔는데 문의 본문은 “환불하고 싶어요"입니다. 그러면 LLM의 가장 큰 단점인 할루시네이션이 발동해서 없는 정책대로 답변할 수 있습니다. 그린 적 없는 경로는 갈 곳이 없다는 것이 이 방식의 약점입니다.

04:14 같은 환불 문의, 두 방식 — 에이전트

에이전트는 카테고리나 상품 선택 없이 “저 환불하고 싶어요"라는 질의만 들어옵니다. 최종 답변까지의 경로를 코드로 정의할 수 없습니다. 그래서 모델에게 도구를 쥐여 줍니다. 구매 내역을 조회하는 능력, CS 정책을 검색하는 능력, 모호하면 사용자에게 되묻는 능력입니다.

이 능력들로 에이전트는 내부에서 순서를 고정하지 않고, 그때그때 스스로 판단하면서 도구를 호출합니다. 최종 답변을 할 수 있다고 판단하면 그때 사용자에게 답을 보냅니다.

에이전트는 워크플로우와 달리 카테고리 같은 입력이 잘못돼 있어도 모델이 알아서 관측해서 사용자에게 되물을 수 있습니다. 예상 밖의 케이스에도 조금 더 유연하게 대응할 수 있다는 장점이 있습니다. 반면 어떤 도구를 조회할지, 심지어 똑같은 질의가 들어와도 그때그때 내부 동작이 달라질 수 있다는 것이 약점입니다.

슬라이드 노트: 덱 7쪽. 왼쪽 패널 “워크플로우 — 다음 순서를 코드가 정한다” (CS 정책 검색 → 상품 정보 조회 → 프롬프트 조립 → LLM 답변 생성), 약점은 예상 밖 케이스. 오른쪽 패널 “에이전트 — 다음 순서를 모델이 정한다” (구매 내역 조회 / CS 정책 검색 / 사용자에게 되묻기, tool_use와 tool_result 반복), 약점은 비용을 예측할 수 없다는 것.

07:06 에이전트의 동작 — 관측을 보고 다음 행동을 고른다

워크플로우 예시는 앞에서 설명드렸으니 넘어가고, 에이전트가 내부적으로 어떻게 동작하는지를 한 번 더 풀어 봤습니다. 똑같은 입력이 들어왔다고 해서 항상 이 순서를 타는 것은 아닙니다. 하나의 예시입니다.

입력으로 “저 환불하고 싶어요"가 들어오면 모델이 생각합니다. 어떤 상품인지 모른다, 구매 내역부터 봐야 한다. 그러고는 조회 도구를 호출합니다. 그 결과 이 사용자가 최근에 티셔츠, 운동화, 모자를 구매했고 아직 구매 확정 전이라는 것을 알게 됩니다. 모델은 다시 생각합니다. 셋 중 무엇을 말하는지는 사용자만 안다. 그래서 되묻습니다. 사용자가 “티셔츠요"라고 답하면, 이제 환불 조건을 확인해야 하니 CS 정책 검색으로 환불 정책을 가져옵니다.

“7일 이내, 미개봉이면 환불 가능"이라는 정책이 들어오면 모델은 또 생각합니다. 티셔츠 주문일이 9월 12일이고 오늘은 9월 17일이니 조건을 충족한다, 답할 수 있다. 그래서 “환불 가능합니다. 접수해 드릴까요?“라고 답합니다.

이렇게 어떤 질의가 들어와도 내부적으로 유연하게 대응할 수 있습니다. 대신 어떤 조회를 몇 번 하고 몇 턴을 대화할지가 문의마다 다르고, 같은 질의인데도 내부에서 해결하는 방식이 달라질 수 있습니다. 그래서 디버깅이 너무 어렵다는 것이 단점입니다.

슬라이드 노트: 덱 9쪽. “에이전트 — 관측을 보고 다음 행동을 매번 고릅니다” / 약점 — 어떤 조회를 몇 번 하고 몇 턴을 대화할지가 문의마다 다르다 → 비용을 미리 예측할 수 없다.

09:08 에이전트의 실체는 while 루프

앞에서 워크플로우와 에이전트를 봤는데, 저는 에이전트를 내부적으로 그냥 while 루프라고 생각합니다. 사용자의 요청이 들어와서 최종 응답이 나갈 때까지 내부에서는 계속 while 루프를 돕니다. 모델이 도구를 더 부를지, 아니면 끝내고 최종 응답을 할지를 모델이 선택합니다. 그 안에서 도구를 실행하고, 실행 결과를 보고 다시 생각하는 과정이 반복됩니다.

그래서 에이전트의 실체는 while 루프입니다. 다만 2절에서 설명드릴 하네스에서는, 시스템을 설계할 때 에이전트 내부의 도구 호출이 10번 정도면 다 풀 수 있겠다고 보고 최대 10번으로 제한할 수 있습니다. 모델이 조금 멍청해서, 혹은 우리가 지시를 잘못 내려서 내부적으로 도구를 20번, 30번씩 막 실행하는 경우가 있습니다. 커뮤니티 같은 곳에서 “루프가 터진다"고 하는 표현이 그 상황입니다.

이렇게 루프가 터지는 것을 시스템적으로 막기 위해, 하네스에서는 최대 도구 호출을 여기서는 10번으로 제한하겠다고 정할 수 있습니다. 그러면 모델이 판단하지 않아도 10번까지 호출한 시점에 무조건 최종 응답을 내도록 설계할 수 있습니다. 이 부분은 뒤의 하네스에서 더 이야기하겠습니다.

슬라이드 노트: 덱 10쪽. “에이전트의 실체는 종료 조건까지 도는 while 루프입니다” / agent loop — 종료 조건까지 반복, 최대 턴 · 오류에 닿으면 하네스가 끊는다.

10:40 ReAct와의 관계

이 while 루프를 보고 “어디서 본 것 같은데?” 하고 생각하실 수 있습니다. ChatGPT가 처음 나왔을 때는 프롬프트 엔지니어링이었습니다. 지금은 컨텍스트 엔지니어링, 그다음에 하네스 엔지니어링까지 왔지만 시작은 프롬프트 엔지니어링이었고, 그 안에서 가장 인기가 많았고 지금도 거의 채택돼 있는 것이 ReAct입니다.

ReAct는 텍스트 규약으로 정합니다. 생각하고, 액션하고, 관측하고, 이를 반복하다가 Final Answer라는 프리픽스가 나오면 루프가 끝난다는 것을 프롬프트로 약속했습니다. 그런데 이 방식이 정말 유의미하니, 지금은 LLM이 이것을 아예 학습했습니다. 모델 표를 보면 tool calling이 지원된다 안 된다는 항목이 있는데, 지원된다는 모델은 내부적으로 tool calling이 학습된 형태라서 “이 순서로 답변해야 한다"는 시스템 프롬프트 없이도 쓸 수 있습니다.

에이전트 루프를 설명하면 “이거 ReAct예요?” 하고 물으시는 분들이 간혹 있어서 한 번 더 설명드렸습니다.

슬라이드 노트: 덱 11쪽. “이 루프는 ReAct 와 같은 구조의 tool-calling loop 입니다” / 고전 ReAct(2022)는 규약을 시스템 프롬프트에 직접 정의하고 코드가 텍스트를 파싱, 현대 Agent Loop는 모델이 tool calling을 지원하도록 학습되어 호출이 구조화된 블록으로 나옴. 형식은 프롬프트로 약속하고 파싱은 코드가 / 형식은 모델이 학습했고 실행은 런타임이.

12:00 에이전트가 워크플로우보다 좋은 것은 아니다

뒤에서 계속 쓸 예시를 무엇으로 할지 고민했는데, 앞의 환불 시스템은 너무 추상적이고 눈에 보이지 않았습니다. 그래서 이 발표의 대부분의 예시는 Claude Code로 가져왔습니다. Codex도 똑같습니다. Claude Code와 Codex에서 우리가 보고 있는 것이 무엇인지 설명하는 편이 좋겠다고 생각했습니다. Claude Code에서 사용자가 지침을 내리고 최종 답변을 얻을 때까지가 결국 하나의 루프입니다. 그림의 동그라미가 도구이고, 여기서는 Edit와 Bash 도구만 쓰입니다. 도구를 호출하고 결과를 받는 과정이 반복되다가 최종 답변이 나옵니다. 우리가 아주 자주 마주치는 그 장면 하나가 에이전트 루프라고 이해하시면 됩니다.

그런데 이렇게 설명하면 에이전트가 되게 좋아 보입니다. 모든 걸 할 수 있을 것 같고, 워크플로우는 분기 처리를 다 해야 해서 귀찮아 보이니 “에이전트로 문제를 다 풀면 되겠다"고 생각할 수 있습니다. 저도 처음에는 그랬습니다. 에이전트가 문제를 다 풀어 주는데 굳이 코드로 분기를 태울 필요가 있나 싶었습니다.

작년에 비슷한 주제로 밋업을 했을 때도 똑같이 말씀드렸습니다. 문제를 풀기 위한 순서도를 화이트보드 같은 곳에 그릴 수 있고 플로우를 명확하게 그릴 수 있다면 워크플로우가 맞습니다. 굳이 불안정한 에이전트를 쓸 이유가 없습니다. 반대로 아무리 써 봐도 분기만 늘어나고 예외 케이스만 늘어나서 그것을 관리하는 것 자체가 너무 힘들다면 에이전트가 맞습니다.

슬라이드 노트: 덱 13쪽. “실행 경로를 미리 그릴 수 있으면 에이전트를 쓰지 않습니다. 그릴 수 없을 때 — 중간 결과를 봐야 다음이 정해질 때 — 에이전트가 필요합니다.” 워크플로우가 맞는 경우: 단계가 고정되고 매번 같다 / 일관성·사후 추적이 중요하다 / 실패 비용이 크고 되돌리기 어렵다. 에이전트가 맞는 경우: 중간 결과를 봐야 다음 단계가 정해진다 / 예상하지 못한 상태를 만나 대응해야 한다 / 검증 수단이 있어 틀려도 잡을 수 있다.

14:39 실무의 형태 — Agentic Workflow

그런데 이 두 가지만 보면, AI로 풀고 싶은데 여태 못 풀던 문제 앞에서 “워크플로우로 할까, 에이전트로 할까"를 놓고 논의하는 경우가 꽤 있습니다. 저는 둘 중 하나를 고르는 것이 아니라고 봅니다. 프로덕션에서는 워크플로우의 안정성과 에이전트의 유연성을 합쳐서 Agentic Workflow 형식으로 많이 씁니다. 파이프라인 전체는 워크플로우로 고정하고, 판단이 필요한 구간만 에이전트에게 위임하는 것입니다.

지금까지 확실하게 발견한 엣지 케이스는 워크플로우로 저렴하게 처리합니다. 판단이 필요한데 아직 조건문이나 분기로 풀 만큼 케이스를 발견하지 못한 것들은 에이전트에게 위임할 수 있습니다. 에이전트도 못 풀 것 같은 것은 CS 담당자에게 라우팅하는 식으로, 고정된 파이프라인 안에 에이전트에게 위임하는 구간을 만들 수 있습니다.

슬라이드 노트: 덱 14쪽. “실제 프로덕션의 지배적인 형태는 둘의 혼합 — Agentic Workflow 입니다” / 파이프라인 전체는 워크플로우로 고정하고, 판단이 필요한 구간만 에이전트에 위임합니다(Anthropic · OpenAI 가이드 공통). LLM 의도 분류(배송 조회·환불/교환·결제·기타) 뒤 세 갈래: 워크플로우 / Agent에 위임 / 담당자 라우팅.

15:44 반대 방향 — 에이전트가 워크플로우를 도구로 부른다

그러면 “워크플로우 안에 에이전트를 넣어야 한다"고 또 생각하실 수 있는데, 사실 반대도 가능합니다. 에이전트에게 쥐어 주는 도구 하나, 예를 들어 환불 처리 도구 안에서 워크플로우 형식으로 가져갈 수 있습니다. 환불 처리에 내부적으로 꽤 복잡한 워크플로우가 필요하다면, 모델에게는 도구 하나지만 그 안에는 복잡한 워크플로우가 존재하는 것입니다.

예시로 환불 처리 도구 내부의 워크플로우에서 LLM이 쓰이는 경우를 가져왔습니다. 사용자의 주문과 배송을 조회하고, LLM이 사유를 판정해서 라우팅합니다. 코드로 만들 수도 있는 부분이라 조금 억지스러운 감이 있긴 합니다. 사유가 변심이면 반품비를 차감하고, 하자면 당연히 전액 환불하고, 오배송이어도 전액 환불합니다. 그리고 에이전트에게 돌아가는 것은 환불이 됐고 환불금이 얼마라는 결과 정도입니다.

저는 “에이전트냐 워크플로우냐” 하는 것이 중요한 게 아니라고 생각합니다. AI 시스템을 설계할 때 어느 부분은 코드로 정할 수 있고 어느 부분은 아직 정할 수 없는지 나눠서, 어떻게 조립할지는 시스템의 성격에 따라 정하면 됩니다. 이 장에서는 그 이야기를 하고 싶었습니다.

슬라이드 노트: 덱 15쪽. “반대로 — 에이전트가 워크플로우를 도구로 부르기도 합니다” / 다음 순서를 코드가 소유하는 구간은 워크플로우로 굳혀 도구 하나로 포장하고, 모델은 그것을 언제 부를지만 정합니다. 모델이 돌려받는 것은 {“refunded”: true, “amount”: 28000} 한 줄.

17:30 2절 하네스 — 모델을 감싸는 실행 골격

지금까지 에이전트가 무엇인지, 실제 프로덕트로 나갈 때 어떻게 설계할지를 능력 기준으로 설명했습니다. 그런데 이제 하네스 엔지니어링이 나왔습니다. 제 체감으로는 에이전트라는 말이 이렇게 보편적으로 쓰이게 된 지 얼마 안 된 것 같은데, 벌써 하네스가 나왔습니다. 대부분 “자, 하네스 엔지니어링 하자"고 말하는데 실제로는 생각이 다 다릅니다. 그래서 정리를 해 왔습니다.

슬라이드 노트: 덱 16쪽. 섹션 표지 “하네스 — 모델을 감싸는 실행 골격” / 가져갈 판단 기준 하나 · 모델은 생각하지만, 하네스가 일하게 만듭니다.

18:04 왜 하네스인가 — Cursor에서 Claude Code로

시스템 설계가 정말 중요하구나, 그때는 하네스라고 부르지 않았지만 그렇게 느꼈던 지점이 있어서 적어 봤습니다. 작년에 저희는 Cursor를 썼고, 올해 회사에서 Claude Code로 넘어왔습니다. 작년에 회사 지원을 받아 Claude Code를 같이 써서 두 도구를 동시에 쓴 적이 있는데, 그때도 Opus로 똑같은 모델이었습니다. 그런데 Cursor에서 하는 것과 Claude Code에서 하는 것의 능력이 달랐습니다. 모델은 같은데도요. 그때까지 저는 모델이 중요한 것 아닌가 하고 생각했습니다.

Cursor에서 Claude Code로 옮겼을 때 같은 모델을 골라도, 같은 작업을 시켜도 왜 Claude Code가 더 잘한다고 느꼈을까. 지금 생각해 보니 하네스 설계의 차이였습니다. 제가 느낀 것을 가져와 봤습니다.

슬라이드 노트: 덱 17쪽. “Cursor 에서 Claude Code 로 옮겼을 때 — 같은 모델을 골라도, 같은 작업을 시켜도 왜 더 잘한다고 느꼈을까요?” / 하네스(Harness) 설계의 차이입니다. 모델이 아니라, 모델 바깥이 다릅니다.

19:08 하네스 엔지니어링이란

그러면 하네스 엔지니어링이 무엇인지, 하네스가 무엇인지 찾아봤는데 말하는 내용이 다 달랐습니다. 그중 제가 개인적으로 와닿았던 정의를 가져왔습니다. AI 모델 자체의 추론 능력은 제외하고, AI 에이전트가 실제 업무 환경에서 안전하고 안정적으로 실행되도록 주변 환경, 규칙, 도구, 검증 장치를 설계하는 일 전체를 가리키는 시스템 구축 기술이라고 봅니다.

그래서 하네스 엔지니어링은 “스킬 몇 개 추가하면 돼” 하는 것이 아닙니다. 시스템 관점에서 전체를 봐야 하는 시스템 구축 기술이라고 저는 생각합니다.

슬라이드 노트: 덱 18쪽. “하네스 엔지니어링(Harness Engineering)이란” / AI 모델 자체의 추론 능력을 제외하고, AI 에이전트가 실제 업무 환경에서 안전하고 안정적으로 실행되도록 주변 환경 · 규칙 · 도구 · 검증 장치를 설계하는 시스템 구축 기술.

19:58 억누르는 것이 아니라 방향을 잡아 준다

하네스라는 말이 처음 나왔을 때는 조금 어색할 수 있습니다. 어원을 보면 말의 마구, 고삐입니다. 그래서 AI의 능력을 억누르는 역할만 하는 건가 싶을 수 있는데, 사실 그것도 절반 정도는 맞습니다. 예측 불가능한 이탈을 막는 것은 AI의 능력을 억누르는 일입니다. AI가 똑똑한 만큼 예측하지 못하게 행동할 수 있으니 이탈을 막는 것입니다.

그런데 저는 그보다 먼저, 시스템이 올바른 방향으로 가도록 유도하는 제어장치 역할이 있다고 생각합니다. 올바른 방향으로 유도하는 것이 먼저고, 이탈을 막는 것은 그다음입니다. 하네스에서 중요하게 봐야 하는 것은 이 순서라고 봤습니다.

슬라이드 노트: 덱 19쪽. “억누르는 것이 아니라, 이탈을 막고 방향을 잡아 줍니다” / 어원인 하네스(Harness, 말의 마구 · 고삐)처럼 AI의 능력을 억누르는 것이 아니라, 예측 불가능한 이탈을 막고 올바른 방향으로 유도하는 제어 장치 역할을 합니다.

20:50 하네스 — 모델을 둘러싼 것들

그러면 하네스가 도대체 무엇이냐는 질문이 나옵니다. 저도 그래서 무엇인지 잘 모르겠었습니다. 하네스를 구성하는 요소, 하네스 컴포넌트로 검색해 봤는데 마음에 드는 것이 너무 없었습니다. 그래서 제가 이해한 것을 바탕으로 손으로 그림을 그리고, AI에게 깔끔하게 도식화해 달라고 한 결과가 이 그림입니다. 이것 말고도 요소는 더 많겠지만, 제가 중요하다고 생각하는 것만 가져왔습니다.

슬라이드 노트: 덱 20쪽. “하네스 — 모델을 둘러싼 것들” / 테두리: 권한(자율/승인), 상한(턴·비용·시간), 관측(무엇을 왜 했는지 기록). 저장하는 계층: State(현재값으로 덮어쓴다) · 대화 이력(원본이 붙는다) · Long-term Memory(추려서 남긴다) · Domain Knowledge(사람이 미리 써둔다) → Context(이번 호출에 필요한 것만) → 모델(reasoning · planning) ↔ 도구(읽기·검색·실행·변경 = 행동 공간).

21:30 Claude Code에서 보면 — 구성요소

이렇게만 보면 설명이 어렵고 와닿지 않을 수 있어서, 여기에 Claude Code는 어떻게 했는지를 얹어 봤습니다. Claude Code는 스스로를 에이전틱 하네스라고 부르기도 합니다. 에이전틱하게 동작하는 하네스를 구축했다는 설명입니다. 이 하네스를 Claude Code의 실물로 채웠을 때 제가 생각하는 주요 요소의 예가 이 그림입니다. 하나씩 간단히 설명드리겠습니다.

모델은 제외한다고 했습니다. 모델은 제외하되, 앞에서 이야기한 루프 같은 설계가 요소로 하나 들어갑니다. 그리고 도구가 있습니다. Claude Code는 대규모 코드베이스를 돕는 코딩 어시스턴트 도구로 나왔으니, 코드 파일을 읽고, 편집하고, 찾고, CLI 같은 것을 실행해야 하면 Bash를 쓰는 기본 도구들을 제공합니다. 지금은 이것보다 더 많아졌습니다. 그리고 MCP가 있는데, MCP라는 도구를 제공한다기보다 사용자가 커스텀하게 도구를 넣을 수 있는 프로토콜을 제공한다고 보시는 것이 정확합니다.

다음은 컨텍스트입니다. 하네스 엔지니어링 이전에는 컨텍스트 엔지니어링이었고, 그 전에는 프롬프트였습니다. 컨텍스트가 중요하다는 것은 이번 호출에 필요한 것만 정제해서 모델에게 넘기는 것이 중요하다는 뜻입니다. 모델의 입력에는 항상 컨텍스트라는 텍스트가 들어가고, 이 컨텍스트는 계속 바뀔 수 있습니다. 컨텍스트는 유한하기 때문입니다. 컨텍스트 윈도우가 계속 늘어나는 추세여도 결국 유한하니, 필요한 것만 채워서 이번 턴에 넘깁니다. 그것을 하는 것이 컨텍스트 엔지니어링입니다.

슬라이드 노트: 덱 21쪽. “같은 그림에 Claude Code 의 실물을 얹으면” / 권한: auto · accept 모드 · 도구별 실행 권한. 상한: 오류 반복 시 루프 중단 · Context Window. 관측: 트랜스크립트 · 훅. 기본 도구: Read · Edit · Grep · Bash · Agent, + MCP 도구(사용자가 연결).

21:30 Claude Code에서 보면 — 저장하는 계층 네 가지

이 컨텍스트를 무엇으로 채우느냐입니다. 시스템 프롬프트가 있을 것이고, AI가 한 답변과 사용자가 물어본 것이 있습니다. 그와 별개로 Claude 하위에 있는 것들이 있는데, 실제로 들어가서 보면 확인할 수 있습니다. 이것들을 외부화해서 사용자의 로컬에 파일로 저장해 둡니다. 저는 이것을 네 가지로 분류했습니다.

첫 번째는 작업 목록입니다. State라고 부르는 것 중 가장 명확한 예가 plan mode입니다. 바로 편집하지 말고 계획부터 세우라는 모드입니다. 이번 세션에서 사용자의 요청을 계획해 보니 네 단계가 나왔고, 모델이 이 네 단계를 해야 한다고 생각했다고 합시다. 그런데 하다 보면 사람도 똑같지 않습니까. 오늘 첫 번째, 두 번째, 세 번째, 네 번째를 해야지 했는데 두 번째쯤 가면 정신력이 흐려져서 세 번째를 해야 하는데 “오늘 할 일 다 했다” 하고 끝내 버릴 수 있습니다. 그것을 막기 위해, plan mode에서 네 단계가 있고 지금은 두 번째 단계까지 했고 세 번째, 네 번째가 남았다는 것을 내부적으로 저장합니다. 이것을 State로 관리하다가 두 번째 작업이 끝났다고 판단되면 “첫 번째, 두 번째는 했고 세 번째, 네 번째가 남았다"는 식으로 컨텍스트에 넣어 줍니다.

두 번째는 트랜스크립트입니다. 하나의 세션에서 우리가 질문하고 답변하고, 도구를 실행하고, 도구 결과가 무엇이 나왔는지를 JSON Lines 파일로 외부화해 둡니다. 이것이 있어야, 예를 들어 모르고 터미널을 껐을 때 세션을 다시 시작할 수 있습니다. 이 기록이 없으면 기억에 의존해서 다시 질문하고 답변해야 하는데, 앞에서 말씀드렸듯 모델은 항상 똑같이 행동하지 않아서 같은 결과가 나오지 않습니다. 그래서 외부화해 두고 다시 실행할 수 있게 합니다.

세 번째는 메모리 디렉토리입니다. 사람들이 메모리라고 부르는 것 중 Long-term Memory를 관리하는 곳입니다. 사용자가 이전에 나와 함께 이야기한 것, 패턴들을 트랜스크립트로 계속 남기고, 일정 주기로 “이 사용자가 나에게 이걸 하지 말라고 했다, 이걸 자꾸 지적한다” 같은 것들을 기억해서 메모리 파일로 만들어 둡니다. 사용자가 이렇게 말하면 또 혼날 수 있으니 이렇게 대답해야 한다는 것을, CLAUDE.md에 직접 적는 것이 아니라 모델이 알아서 Long-term Memory로 만들어 두는 것입니다. 사용자별로요.

네 번째는 Knowledge입니다. 이건 우리가 정말 익숙하게 보던 것으로, CLAUDE.md나 스킬이 여기에 해당합니다. 이 Knowledge가 필요한 이유는, 모델이 정말 많은 것을 학습했어도 우리가 아는 모든 지식을 알지는 못하기 때문입니다. 예를 들어 네이버 내부에서만 쓰는 N3R이나 커넥트 같은 것은 Claude가 학습할 수 없는 정보입니다. 이것을 지침 문서로 주지 않으면 “N3R"을 일단 검색해 보고 이상한 소리를 할 수 있습니다. 거기에 “N3R은 어떤 플랫폼이고, 이것을 쓰려면 이렇게 쓰면 된다"는 스킬을 쥐여 주는 것입니다. 이런 것들을 CLAUDE.md와 스킬, 그리고 Knowledge라고 부르기로 정리해 왔습니다.

한 가지 짚을 점이 있습니다. Claude Code 문서가 아주 잘 돼 있는데, 읽어 보면 Claude Code는 CLAUDE.md를 구현상 메모리로 분류합니다. 세션마다 새로 이야기하는 것이 아니라 세션 바깥에 살면서 매 세션 로딩돼서 들어가기 때문입니다. 저는 정리할 때 이것을 메모리로 분류하지 않았습니다. 에이전트 시스템 관점에서 CLAUDE.md는 프로젝트 규칙, 작업 절차, 도메인 지식을 제공하는 것이니, Knowledge로 묶어서 정리했습니다.

슬라이드 노트: 덱 21쪽. “Claude Code 는 CLAUDE.md 를 구현상 ‘메모리’로 분류한다 — 세션을 넘어 지속되며 매 실행의 컨텍스트에 다시 주입되기 때문. 그러나 에이전트 시스템 설계 관점에서는 프로젝트 규칙 · 작업 절차 · 도메인 지식을 제공하는 지속성 있는 지식 · 지침 계층으로 이해하는 편이 더 정확하다.”

21:30 Claude Code에서 보면 — 제어하는 장치와 빠졌을 때

여기까지가 에이전트가 내 말을 찰떡같이 알아듣고 동작하게 하는 구성요소였고, 이 바깥에 있는 것들은 제어하는 장치입니다. 권한은 잘 아실 겁니다. 자동 모드로 둘지 승인을 받을지, 문제가 될 수 있는 도구는 항상 실행 권한을 받도록 할지 같은 것들입니다.

상한도 있습니다. 컨텍스트 윈도우는 앞에서 말씀드렸듯 무한하지 않습니다. 80% 이상 차면 오토컴팩트를 한다든지, 내부적으로 루프가 똑같은 오류를 계속 내면서 도구를 반복 호출해 루프가 터지고 토큰과 비용을 먹는 상황에서 중단할 수 있는 최소한의 제어권을 하네스 설계 요소로 담고 있습니다.

“있으면 좋은 것은 알겠는데” 싶으실 겁니다. 제가 생각하기에 가장 좋은 방법은, 없으면 어떻게 되는지를 보는 것입니다. 거꾸로 이것들이 하네스에서 왜 중요한 요소인지 명시적으로 이해하기 좋습니다.

루프가 없으면 모델을 한 번 호출하고 끝납니다. 사용자의 질문에 텍스트만 내뱉고 끝나니, 요청한 작업을 제대로 하지 못한 채 종료됩니다. 도구가 없으면 말만 합니다. LLM은 기본적으로 텍스트가 들어가서 텍스트가 나오는 모델이라, 액션을 할 수 있는 도구를 주지 않으면 말만 하고 아무것도 하지 못합니다. 옛날 ChatGPT가 그랬습니다. 작업 목록, 즉 현재 상태의 State를 관리하지 않으면 어디까지 했는지 잊어버립니다. 대화 이력이 없으면 직전에 어떤 대화를 했는지 기억하지 못합니다. 메모리 디렉토리가 없으면 매번 처음 보는 사용자처럼 행동해서 맨날 혼납니다. Knowledge가 없으면 그럴듯하게 틀린 판단을 합니다. 내 환경에 맞는 지식이 없으니까요. 이것도 혼납니다.

권한은, 돌이킬 수 없는 행동이 있기 때문입니다. 배포를 한다든지 마음대로 위키에 문서를 올린다든지 하는 행동에 권한 제어를 해 두지 않으면, 에이전트에게 뭔가 시켜 놓고 자리를 비운 사이 위키에 문서를 미친 듯이 생성하거나 배포를 계속 할 수도 있습니다. 그런 권한은 사람에게 위임하도록 막아 둡니다. 상한은, 앞에서 말한 루프 중단 조건 같은 것을 하네스로 설계해 놓지 않으면 무한 루프에 빠지고, 결국 토큰을 계속 쓰게 되어 비용이 엄청나게 들 수 있습니다. 하네스의 요소는 그때그때 필요한 것을 가져다 쓰면 되겠다고 저는 정리했습니다.

29:44 Claude Code 설계 예시 ① — 전용 도구와 선택 기준

좀 더 자세히 보겠습니다. 올해 3월에 아시는 분들은 아시겠지만 Claude Code 소스가 유출됐고, 그때 개발자들이 신나서 소스를 포크 떠서 리버스 엔지니어링을 했습니다. 저도 해 본 것이 있는데, 거기서 제가 중요하다고 생각하는 것이 무엇일까 생각해서 세 가지를 가져왔습니다. 첫 번째는 도구 부분입니다.

이 설계가 없다고 해 보겠습니다. 도구에는 Bash라는 범용 도구가 하나 있습니다. Bash로 cat 명령어를 쓰면 파일을 읽을 수는 있습니다. 그런데 어시스턴트의 역할이 코드를 읽고 수정하는 것이라고 할 때, cat으로 출력하면 어느 부분을 편집해야 할지 짚을 수 없습니다. 그래서 Read로 읽으면 줄번호가 딸려 나오지 않습니까. Read한 다음에 수정하는 것이 일반적이니 줄번호를 친절하게 달아 주자는 식으로 설계한 것입니다.

Edit도 마찬가지입니다. 무언가 수정해 달라고 했을 때 Edit를 바로 도구로 호출한다고 해 보겠습니다. “너 그 파일을 한 번도 읽은 적이 없는데 어떻게 Edit를 하느냐"고 하면서, 도구 내부에서 “파일을 읽지 않았으니 읽고 와서 써라” 하는 식으로 도구를 설계했습니다. 그래서 Bash라는 범용적이고 유연한 도구는 남기되, 자주 쓰는 동작은 전용 도구로 따로 만들었습니다.

도구만 만든 것이 아닙니다. 시스템 프롬프트에도 “파일은 cat 말고 Read 도구를 사용해라, 검색은 grep 말고 Grep을 사용해라, Bash는 실행에만 남겨라” 같은 내용이 있었습니다. 이렇게 프롬프트로 가르쳐 주고 있었습니다. 우리가 설계할 때 가져올 수 있는 부분이 아닐까 생각했습니다.

슬라이드 노트: 덱 23쪽. “자주 쓰는 동작은 전용 도구로 따로 만들고, 언제 무엇을 쓸지까지 가르칩니다” / 이 장치가 없으면: Bash 하나로 다 한다, cat 출력엔 줄번호가 없고, grep·find 출력은 잘리고, sed는 검증 없이 파일을 덮는다. 설계: 읽기 Read(줄번호) · 검색 Grep·Glob · 수정 Edit(먼저 Read 했는지, 바꿀 문장이 하나뿐인지 검사), Bash는 실행(테스트·빌드)에 남긴다. 결과: 하네스가 도구를 나눠 만들고 선택 기준을 주입한 것. 각주: 2026-03 유출된 Claude Code 소스를 리버스 엔지니어링한 분석에서 설계 패턴 일부만 가져왔다.

34:33 Claude Code 설계 예시 ② — 의도와 실행 사이의 통제 층

두 번째는 권한 문제입니다. 권한이면서 도구 문제이기도 합니다. 앞에서 말씀드렸듯 권한 장치가 없으면, rm -rf나 git push –force처럼 한 번 실행하면 되돌릴 수 없는 액션들이 분명히 있습니다. 이런 도구를 권한 관리 없이 두면 에이전트는 “너 이거 나한테 도구로 줬잖아” 하고 알아서 막 실행합니다. 나중에 반드시 문제가 생깁니다.

그래서 Claude Code를 쓰다 보면, 자동으로 완전히 풀어 놓은 분들도 있겠지만 원래 초반에는 git push 같은 것을 하면 내부 룰에 따라 바로 실행하지 않고 사용자 승인을 받고 실행하게 했습니다. 도구별로 권한 정책을 가져간 것입니다.

그리고 도구별로, 읽는 것은 한 번에 여러 번 병렬로 해도 되지만 Edit는 한꺼번에 하면 안 됩니다. 섞일 수 있으니 코드 수정 작업은 순차적으로 해야 합니다. 그래서 읽기나 검색처럼 수정하지 않는 것은 병렬로, 수정하는 도구는 순차적으로 진행하라는 식의 도구 계약을 내부적으로 만들어 두었습니다.

도구에는 이름, 설명, 스키마만 있는 것이 아닙니다. 이 도구가 읽기인지 쓰기인지, 동시에 병렬로 돌려도 되는지, 실행하기 전에 어떤 권한을 얻어야 하는지 아니면 권한 없이 그냥 실행해도 되는지 같은 도구 계약을 내부적으로 관리하고 있었습니다. 설계할 때 가져와도 되겠다고 생각했습니다.

슬라이드 노트: 덱 24쪽. “모델이 도구를 부른다고 바로 실행하지 않습니다 — 의도와 실행 사이에 통제 층을 둡니다” / 이 장치가 없으면: rm -rf · git push –force 같은 비가역 행동을 막을 지점이 없고, 읽기 10번을 한 줄로 서서 기다린다. 설계: 권한 판단을 계층화(명시적 deny rule → 명시적 allow rule → 명령 위험도 분류 → 애매하면 사용자 승인), 읽기·검색은 병렬, 파일 수정은 순차, 서브에이전트에는 필요한 도구만. 도구 = 스키마 + 읽기/쓰기 여부 + 병렬 가능 여부 + 권한 정책.

36:38 정리 — 좋은 시스템은 하네스 구성에서 나온다

세 번째로, Claude Code는 긴 작업이든 세션이든 반드시 깨질 수 있다는 전제로 상한, 트랜스크립트, 관측 쪽을 정비해 두었습니다. 컨텍스트 창을 넘기면 세션이 죽습니다. 대화하다가 컨텍스트 윈도우를 넘어가서 죽어 버리면 안 되니까, 컨텍스트 윈도우가 어느 정도 차면 대화와 도구 결과를 오토컴팩트하는 기능을 Claude Code가 제공합니다.

파일 수정도 있습니다. 저는 자주 겪는데, 에이전트가 파일을 수정하고 있는데 “어, 이렇게 수정하면 안 돼, 방향이 잘못됐어” 싶을 때가 있습니다. 그러면 Esc를 눌러서 인터럽트를 건 다음 “수정하지 마” 하고 말합니다. 분명 도구는 실행 중이었는데도 파일 수정 전으로 원복이 잘 됩니다. 내부적으로 무언가를 수정하기 전에 체크포인트를 두기 때문입니다. 그 작업이 완료되기 전까지는 체크포인트가 남아 있습니다.

또 어제 하던 세션을 이어서 하고 싶을 때가 있습니다. 어제 출근해서 작업했는데 다 못 끝냈고 컴퓨터를 껐다고 해 보겠습니다. 그것을 다시 이어 가고 싶을 때 resume 같은 기능이 있어서 어제 세션을 이어 작업할 수 있습니다. 이것이 가능하려면 외부화가 돼 있어야 합니다. 앞에서 말씀드린 트랜스크립트를 밖으로 옮겨야 합니다. Claude Code는 하나의 세션 안에서 모든 것이 이어지지 않고, 전부 외부화해서 언제든 이어 갈 수 있고 언제든 작업을 되돌릴 수 있게 설계했습니다. 이것이 배울 점이라고 생각해서, AI 시스템을 설계할 때 이런 부분이 필요하다면 참고할 수 있겠다 싶어 가져왔습니다.

정리하면, 좋은 시스템은 좋은 모델에서만 나오는 것이 아닙니다. 당연히 모델이 좋아지면 시스템도 좋아지겠지만, 같은 모델을 두고 하네스를 어떻게 구성하느냐에 따라 시스템의 품질이 높아집니다.

슬라이드 노트: 덱 26쪽. “좋은 시스템은 좋은 모델에서 나오지 않습니다. 같은 모델을 두고 하네스를 어떻게 구성하느냐에서 나옵니다.” / 모델은 생각하지만, 하네스가 일하게 만듭니다.

39:02 잠깐 — 이런 말, 들어보셨나요

이것은 우리가 AI 시스템을 설계하기 전에, Claude Code나 Codex를 쓰는 입장에서 하네스 엔지니어링이 과연 무엇을 뜻하느냐의 이야기입니다. 저도 헷갈렸습니다. “모델이 똑똑해지면 하네스는 얇게 가져가야 한다"고 하면서 동시에 “하네스 엔지니어링을 계속 해야 한다"고 합니다. 처음 들었을 때는 무엇을 얇게 가져가라는 건지 알 수 없었습니다. 그래서 같이 정리해 보면 좋겠다고 생각해서 가져왔습니다.

슬라이드 노트: 덱 27쪽. “이런 말, 들어보셨나요?” / “모델이 똑똑해지면 하네스는 얇게 가져가야 한다” / “하네스 엔지니어링을 해야 한다”

39:33 얇아지는 것 — 모델을 보조하던 절차

예전에 조금 덜 똑똑했던 모델의 실수 때문에 Claude Code에 이런 식으로 절차를 보완했습니다. 모든 코드 수정 전에 마음대로 수정하지 말고 계획을 먼저 작성하라. 원인 후보를 반드시 세 개 제시하라. 구현 에이전트와 검토 에이전트를 따로 두라. 검토 결과를 다시 반영하고 또 검토하라. 이런 것들이 CLAUDE.md나 AGENTS.md에 쌓였습니다. 모델이 판단을 제대로 하지 못해서, 우리가 판단 기준을 계속 넣었던 것입니다.

그런데 모델이 똑똑해지면 이런 절차를 굳이 할 필요가 없습니다. 목표만 줘도 하는 모델인데 이런 절차가 계속 남아 있으면, 모델이 너무 똑똑해서 그것을 잘 따릅니다. 그러면 토큰을 낭비하고 더 좋은 결과를 낼 수 있는데도 결과는 예전과 다를 바가 없게 됩니다. 모델이 똑똑해졌다고 기대하며 작업을 시작했는데 “비슷한데?” 하고 느꼈다면, 하네스를 조금 더 정리할 필요가 있다고 생각합니다.

슬라이드 노트: 덱 28쪽. “예전 모델의 실수 때문에 붙인 절차 — 새 모델에도 계속 둘 필요가 있을까요” / 전: 모델의 부족한 판단을 절차로 보완(계획 작성, 원인 후보 세 개, 구현·검토 에이전트 분리, 재검토). 후: 목표와 완료 기준을 주고 방법은 맡김(문제를 해결하고 관련 테스트로 검증하라 / 공개 API 호환성을 유지하라 / 요구사항이 모호하면 먼저 확인하라). 남는 것은 프로젝트 고유의 요구와 권한 경계. “새 모델이니 다 지우자"가 아닙니다 — 절차 없이도 잘하는지 확인하고, 불필요해진 것을 걷어내는 것이 얇게 가져가기입니다. (가상 사례)

40:51 얇게 가져간 실제 예 — GitHub MCP에서 gh CLI로

이것은 대부분 한 번쯤 겪어 보셨을 텐데, CLAUDE.md 이야기는 와닿지 않는 분이 많을 것 같아서, 우리가 실제로 하네스를 얇게 가져간 적이 있다는 예시를 하나 가져왔습니다. MCP가 처음 나왔을 때 “OSS에 접근해서 뭔가를 할 수 있다"며 GitHub MCP를 다 붙이셨지요[?]. 그런데 지금은 GitHub MCP를 붙이지 않고 gh 커맨드라인, CLI로 넘어간 분들이 많은 것 같습니다.

이유는 MCP를 보면 도구가 아주 많다는 데 있습니다. 특정 목적별로 도구를 하나하나 세분화해 놓았습니다. 이슈만 해도 이슈를 생성하는 것, 이슈를 리스트업하는 것, 하나를 가져오는 것, 이슈에 코멘트하는 것이 전부 따로 도구로 되어 있었습니다. 도구마다 이름뿐 아니라 설명과 입력 스키마까지 전부 컨텍스트에 쌓이는데, 그것이 몇십 개였습니다. 그것을 모델에게 매번 줬던 것입니다.

당시에 왜 이런 방식을 썼느냐 하면, 명령을 구성하고 결과를 처리하는 것이 그때 모델에게는 어려웠기 때문입니다. 그래서 작업별로 정해진 입력을 받는 도구를 만들어 줬습니다. 지금은 모델이 똑똑해져서, CLAUDE.md에 “GitHub 작업은 gh CLI로 한다"고 써 두면 됩니다. 우리가 별도 도구를 주지 않아도 Bash라는 범용 도구로 사용할 수 있습니다. help로 사용법은 CLI에서 읽고, 그것을 기준으로 명령어를 구성해서 자유롭게 동적으로 가공하는 능력이 생겼습니다. 많은 도구에서 범용 도구 하나와 CLI로 넘어간 것이, 저희가 공통적으로 겪은 “하네스를 얇게 가져간” 예시라고 생각해서 가져왔습니다.

40:51 반대로 — 능력이 오르면 통제 층은 두꺼워진다

“모델이 똑똑해지면 이런 것은 거의 안 써도 되겠네, 도구도 크게 필요 없고 다 CLI를 붙이면 되겠네” 싶을 수 있습니다. 그것도 맞지만, 하네스를 계속 얇게 가져가느냐는 다른 이야기입니다.

실제로 Fable 5가 나왔을 때 너무 똑똑해서, 일부 생물학 과제에서 전문가를 능가한다고 합니다. 그래서 Claude Code에 Fable을 붙일 때 거의 모든 생물학 질의를 차단했다고 합니다. 이것 말고도, 저만 겪은 건지 모르겠는데, 데이터 관련 도구를 쓰다 보니 Fable이 처음에 너무 똑똑해서 그런지 데이터 관련 도구를 호출해야 할 때 자동으로 Opus로 변환되어 버리는 경우가 있었습니다. 생물학 관련 요청이 들어오면 내부적으로 Claude가 이런 하네스 장치를 끼웁니다. 안전 분류기입니다.

어떤 의도로 이 도구를 호출했는지 판별한 다음, 악의적인 의도가 없어 보이면 Fable 5를 그대로 쓰게 하고, 악의적으로 보이면 Opus 5로 모델이 바뀝니다. 이걸 아무리 Fable로 바꿔도 계속 Opus로 넘어갑니다. 이렇게 오히려 모델이 너무 똑똑해서 이런 통제 층이 생긴 것입니다.

이 안전 분류기, 클래시파이어도 Anthropic에서 처음에는 두껍게 가져가다가 점점 의도만 잘 파악해서 정말 악의적인 의도가 있을 때만 걸리게 하려고 분류기 자체를 얇게 만드는 연구를 내부적으로 계속하고 있다고 합니다. 이 부분은 이렇게 가져와 봤습니다.

슬라이드 노트: 덱 30쪽. “반대로 — 능력이 오르면 통제하는 층은 두꺼워집니다” / Fable 5는 일부 생물학 과제에서 전문가를 능가한다 — 그래서 출시 시 거의 모든 생물학 질의를 차단했다. 안전 분류기: 허용이면 Fable 5, 차단이면 fallback으로 Opus 5. 출시 뒤에는 분류기의 규칙을 다시 써 오탐을 85 % 줄였다. 출처: Anthropic, Improving Fable 5’s biology safeguards (2026-08-07).

44:54 정리 — 얇아지는 것과 두꺼워지는 것

그래서 앞으로 어떻게 될 것인가 하면, 얇아지는 것은 모델을 보조하던 절차입니다. 모델이 조금 부족해서 우리가 가이드를 줘야 했던 절차들은 계속 얇아질 것입니다. 반면 모델이 너무 똑똑해서 자꾸 임의로 우회하려고 하는 것을 통제하는 층은 두꺼워질 것이라고 저는 생각합니다.

슬라이드 노트: 덱 31쪽. “얇아지는 것은 모델을 보조하던 절차, 두꺼워지는 것은 모델을 통제하는 층입니다.” / “얇게 가져가라"도, “하네스 엔지니어링을 해야 한다"도 맞습니다 — 가리키는 것이 다를 뿐입니다.

45:22 3절 도구 — 에이전트의 행동 범위

마지막 절입니다. 원래는 에이전트와 하네스만 다루고 이번 밋업을 끝낼까 생각했는데, 내부에서 도구에 대한 의견이 생각보다 많이 나왔습니다. 도구가 그냥 간단한 것처럼 보이지만, 저는 도구 설계를 정말 잘해야 한다고 생각합니다. 그래서 하네스에서 도구만 따로 빼서 이야기하려고 합니다. 뒤에는 MCP 이야기도 나오고, MCP와 혼동되어 나오는 A2A 이야기도 나옵니다.

슬라이드 노트: 덱 32쪽. 섹션 표지 “도구 — 에이전트의 행동 범위” / 가져갈 판단 기준 하나 · 도구의 이름 · 설명 · 스키마 · 응답 · 에러는 API 문서가 아니라, 모델의 다음 행동을 정하는 프롬프트 표면입니다.

45:56 이번 절의 자리

도구가 왜 중요하다고 생각하느냐면, 에이전트에게 어떤 도구를 주느냐에 따라 에이전트가 할 수 있는 일이 너무 달라지기 때문입니다. 2절의 하네스 그림에서 이번에는 여기, 도구 칸을 봅니다.

슬라이드 노트: 덱 33쪽. “2절의 하네스 그림에서, 이번에는 여기를 봅니다” / 모델이 할 수 있는 행동의 공간이 이 한 칸에서 정해집니다. 그리고 여기서 돌아오는 것이 다음 판단의 근거가 됩니다.

46:08 에이전트가 풀 수 있는 문제의 범위는 도구 집합이 정한다

예를 들어 Claude Code에서도 Read 도구만 줬다면 파일을 읽기만 하고, “이 코드를 이 파일에서 이렇게 바꿔 보세요” 하고 텍스트로만 알려 줬을 것입니다. 옛날 ChatGPT처럼요. 그런데 Edit라는 도구를 줬습니다. Edit를 줬으니 파일을 실제로 수정할 수 있게 된 것처럼, 에이전트에게 가장 중요한 것은 어떤 도구를 쥐여 줬느냐에 따라 능력이 크게 달라진다는 점이라고 생각합니다.

모델에게 똑같이 “환불하고 싶어요"라는 문의가 들어왔다고 해 보겠습니다. 도구 집합이 조회뿐이라면 가이드만 줄 수 있습니다. “7일 이내 미개봉이라 환불 가능하니 어디어디에 들어가서 이렇게 환불하세요” 하는 가이드까지는 줄 수 있습니다. 그런데 환불 처리를 실제로 대행하는 도구가 들어오면, “환불 가능한데 환불 처리를 해 드릴까요?” 하고 물었을 때 사용자가 “대신 해 주세요” 하면 환불을 실제로 실행까지 할 수 있습니다.

모델을 더 똑똑하게 만들어도 이런 행동은 생기지 않습니다. 도구 집합이 곧 에이전트가 할 수 있는 행동의 범위입니다. 그래서 AI로 어떤 문제를 푸는 프로덕트를 만들고 싶을 때, 어떤 문제를 풀 것인지, 그 문제를 풀려면 어떤 도구가 필요한지를 리스트업하는 것이 가장 첫 번째라고 요즘 느끼고 있어서 가져왔습니다.

슬라이드 노트: 덱 34쪽. “에이전트가 풀 수 있는 문제의 범위는 도구 집합이 정합니다” / 도구 집합 A(조회만): 읽는 것만 할 수 있다, 말까지 — 아무리 정확해도 처리되지 않는다. 도구 집합 B(조회 + 실행): 환불 접수까지 — 실행까지. 모델을 더 똑똑하게 만들어도 없는 행동은 생기지 않습니다 — 도구 집합이 곧 에이전트가 할 수 있는 행동의 범위입니다.

48:24 호출자가 모델이면 달라지는 것

그런데 AI 시스템을 만든다고 하면 구매 내역 조회, CS 정책 검색, 환불 처리 같은 것은 정책 검색은 애매하지만 대체로 이미 내부 API로 짜여 있습니다. 그래서 “API를 래핑해서 설명과 입력 스키마만 주면 그게 도구 아니냐"고 질문하시는 분들이 있습니다. 일부는 맞는 말입니다. 실제로 그렇게 해도 돌아갑니다.

다만 저는 기존 API와 도구의 가장 큰 차이가 이것이라고 봅니다. API는 호출을 사람이 쓴 코드가 합니다. 처음에 API 명세를 읽고 코드를 한 번 맞게 개발해 두면, API 스펙이 바뀌지 않는 이상 호출에 문제가 없습니다. 그런데 에이전트의 도구는 호출자가 모델입니다. 모델은 이 도구의 응답이 어떤 의미인지, 무엇을 뜻하는지 잘 모릅니다. 그래서 에이전트 도구의 호출자는 모델이라는 점을 항상 명심했으면 좋겠다고 적어 왔습니다. 이걸 보는 이유는 이렇습니다. 모델에 컨텍스트를 넣을 때 도구의 명세를 넣고, 사용자가 실제로 “환불하고 싶어요"라고 질문합니다. 그걸 읽어서 모델에게 전달합니다. 모델이 도구 목록을 보고 하나를 고릅니다. 그 도구 결과를 컨텍스트에 담은 다음, 모델이 “그다음에 어떻게 행동하지?” 하고 이 루프를 계속 판단합니다.

그래서 첫 번째로 가장 중요한 것은 도구 명세입니다. 도구 명세를 읽고 모델이 필요한 도구를 고르기 때문입니다. 두 번째는 성공이든 실패든 응답이 다음 행동을 정한다는 것입니다. 그래서 응답을 잘 설계해야 합니다. 그리고 명세도 응답도 전부 컨텍스트를 차지하고, 컨텍스트는 유한하므로 불필요한 정보는 덜어 내야 합니다.

슬라이드 노트: 덱 36쪽. “그래서 무엇이 달라지는가 — 한 장면으로” / ① 도구 명세를 읽고 필요한 도구를 고른다 / ② 성공이든 실패든, 응답이 다음 행동을 정한다 / ③ 명세도 응답도 컨텍스트를 차지한다 — 유한하다. 예시 도구: get_purchase_history(from, to) / search_policy(q) / process_refund(order_id, reason).

50:24 도구는 두 층이다

도구를 설계할 때는, API 내부나 DB 조회처럼 이미 동작하는 층이 있을 것입니다. 그런데 그때 우리가 설계해야 하는 것은 무엇이냐 하면, 기본적으로 name, description, input_schema는 알겠습니다. 이 도구가 어떤 도구인지 설명을 쓰고, 어떻게 채워야 하는지 스키마를 주는 것은 압니다. 그것 말고도 제가 가장 중요하게 생각하는 것은 response, 즉 응답이 어떻게 내려가느냐, 그리고 error가 어떻게 내려가느냐입니다. 도구 호출을 잘못했을 때 에러를 보고 그다음에 어떻게 행동할지를 모델이 정하니, 그 부분을 잘 설계해야 한다고 생각합니다.

슬라이드 노트: 덱 37쪽. “도구는 코드 한 층이 아니라 두 층입니다” / 텍스트 층 — 모델이 읽는다: name · description · input_schema · response · error. 코드 층 — 실제로 동작한다: 구현 · 기존 REST API 호출 · DB 조회. 기존 API를 감싸면 코드 층까지는 생긴다.

51:15 오류 응답은 다음에 바꿀 것까지 알려줘야 한다

예시를 하나 가져왔습니다. 오류 코드 이야기입니다. 사용자가 “최근 3개월 구매 내역을 확인해 줘"라고 했다고 합시다. 그런데 이 도구는 내부적으로 리소스 이슈 때문에 한 번에 최대 7일만 조회할 수 있다고 가정하겠습니다. 이때 오류 코드로 “E104” 하나만 반환했다고 해 보겠습니다.

원래 사람이 짜던 코드라면 내부적으로 커뮤니케이션을 하거나 문서에서 “104가 무슨 뜻이에요?” 하고 찾아봅니다. “아, 7일만 조회해야 하는군요” 하고 알아내서 그 에러 코드에 대한 분기를 태웁니다. 그런데 모델은 그 뜻을 모릅니다. 그래서 같은 요청을 무의미하게 다시 부르거나 “실패했습니다"로 끝냅니다. 무엇을 바꿔서 호출해야 하는지 알 수 없는 것입니다.

응답을 이렇게 고치면 더 좋은 도구로 설계한 것입니다. 에러 코드를 사람이 봐도 직관적이게, 예컨대 DATE_RANGE_TOO_LARGE처럼 설계하고, 메시지로 다음 행동을 어떻게 하면 좋을지 힌트를 주면 제일 좋다고 생각합니다. 코드만 주는 것이 아니라 “조회 기간을 7일 이하로 나누어 다시 호출하세요"라는 메시지를 주면, 모델이 “7일 이하로 나눠서 부르면 되겠구나” 하고 생각해서 응답만 읽고 스스로 고칩니다. 그래서 에이전트 도구에서는 복구에 필요한 조건을 응답이 직접 주는 것까지가 도구 설계라고 생각했습니다.

슬라이드 노트: 덱 38쪽. “오류 응답은 실패를 알리면서, 다음에 무엇을 바꿔야 하는지도 알려줘야 합니다” / { “error”: “E104” } → 같은 요청을 다시 부르거나 “실패했습니다"로 끝낸다. { “error”: “DATE_RANGE_TOO_LARGE”, “message”: “조회 기간을 7일 이하로 나누어 다시 호출하세요.” } → 기간을 7일씩 나누어 다시 부른다. 기존 API라면 개발자가 E104의 뜻을 찾아 예외 처리를 개발했습니다 — 에이전트 도구에서는 복구에 필요한 조건을 응답이 직접 전달합니다.

52:58 도구의 위층을 설계할 때 묻는 다섯 가지

이것 말고도 도구를 설계할 때 고려하면 좋을 것이 아주 많습니다. 다섯 가지로 가져왔습니다.

첫 번째는 도구 하나의 크기입니다. 캘린더에 일정을 추가할 수 있는 에이전트를 만든다고 합시다. API로는 사용자 ID를 가져오고, 캘린더 ID를 가져온 다음, 그 캘린더 ID 기준으로 일정을 등록하는 식으로 도구를 분리할 수 있습니다. 그런데 GetUserID와 GetCalendarID가 다른 액션에서 쓰이지 않고 오직 일정 등록에만 필요하다면 굳이 이렇게 나눌 필요가 없습니다. 원자적으로 쪼갤 필요가 없습니다. 이 순서를 항상 모델이 추론해야 하고, 그 과정에서 토큰을 소비하기 때문입니다. 그래서 베스트 케이스는 create_event 하나를 작업 단위로 두고, 셋은 그 안에서 부르도록 설계하는 것입니다.

두 번째는 선택입니다. 가장 많이 일어나는 문제입니다. 저도 개발자로 일하면서 함수 이름을 굉장히 불친절하게 짓는 습관이 있었습니다. get_data, fetch_data, load_data 같은 것들이 있으면 모델은 비슷한 것 중에 아무거나 고르게 됩니다. 불러 보고 “어, 이거 아니네?” 하면 다음 것을 불러 보고, 또 그다음 것을 불러 봅니다. 토큰을 불필요하게 낭비하는 것입니다. 가장 좋은 것은 get_purchase_history처럼 이름과 설명만 읽고 명확하게 다른 도구임을 알 수 있는 것입니다. 많이 겪어 보셨을 겁니다.

세 번째는 복구인데, 앞에서 말씀드린 것과 같아서 넘어가겠습니다.

네 번째는 출력입니다. 컨텍스트 윈도우는 유한합니다. 구매 내역을 가져올 때 API를 래핑해서 5,000건을 내려 주는 도구를 그대로 제공했다고 합시다. 5,000건이 필요하지는 않은데 컨텍스트 윈도우만 불필요하게 잡아먹습니다. limit이나 필터를 달아서 도구를 제공해야 합니다. 또 결과를 약어처럼 뜻을 알 수 없는 값으로 내려 주면 모델이 대충 유추해서 해독하게 되고, 그것이 다음 행동에 영향을 줍니다. 그래서 읽히는 값으로 친절하게 내보내 줄 필요가 있습니다.

다섯 번째는 부작용입니다. 읽기가 아니라 쓰기를 할 때의 도구 설계입니다. 에이전트가 나를 대신해 액션을 하는 경우, 예를 들어 주문을 생성하는 create_order 도구가 있다고 합시다. 이 도구를 실행하다 중간에 문제가 생겨 실패했다고 떨어졌는데 재시도해도 안전한가. 기존 API를 설계할 때와 비슷한 이야기입니다. 재시도가 중복 실행되지 않도록 하고, 일부만 반영된 것인지도 알려 주는 식으로, 기존에 설계하던 대로 하면 좋겠다는 것입니다.

슬라이드 노트: 덱 39쪽. “도구의 위층을 설계할 때 묻는 다섯 — 나쁜 것에서 좋은 것으로” / ① 경계: get_user_id → get_calendar_id → post_event 대신 create_event(user, when). ② 선택: get_data() · fetch_data() · load_data() 대신 get_purchase_history(from, to). ③ 복구: 400 Bad Request 대신 DATE_RANGE_TOO_LARGE · “7일 이하로 나누어 다시 호출”. ④ 출력: 5,000건 전체 · {“st”: 3} 대신 limit · 필터 · {“status”: “shipped”}. ⑤ 부작용: create_order() ×2 대신 idempotency_key · {“applied”: “partial”}.

56:41 도구는 한 번 만들고 끝이 아니다

제가 이것을 제 생각으로만 가져온 것은 아닙니다. Anthropic이 Writing effective tools for AI agents라는 아티클을 아주 친절하고 길게 냈는데, 거기에 앞의 내용이 다 나옵니다. 심지어 Anthropic은 도구를 하나의 평가셋으로 측정해서, 릴리즈할 때마다 반복적으로 고쳐 나갑니다. 설명, 이름, 응답 구조를 그렇게 다듬습니다. 루프를 돌린다기보다, 릴리즈할 때마다 평가하면서 수정해서 릴리즈한다고 합니다.

저도 처음에는 도구 정의를 한 번 쓰고 그대로 배포해서 잘 동작하면 되는 것 아닌가 하고 잘못 알고 있었습니다. 그런데 하네스에서 이야기한 것처럼, 원래는 모델이 조금 똑똑하지 못해서 설명에 10줄, 20줄씩 “너 이거 부를 때 이거 생각해야 되고 저거 생각해야 되고” 하는 식으로 썼습니다. 모델이 똑똑해지면 도구 설명도 조금 더 얇아져도 됩니다. 그 정도만 있어도 알아서 부를 수 있으니까요. 그래서 반복해서 고치는 대상에 도구도 포함된다는 말씀을 드리고 싶었습니다.

슬라이드 노트: 덱 40쪽. “Anthropic 은 도구 하나를 평가셋으로 측정하고 반복해서 고칩니다” / 도구 초안 → 평가 태스크 생성(실제 업무 기반 수십 개) → 에이전트 루프로 실행 → 트랜스크립트 분석 → 도구를 고친다(설명 · 스키마 · 응답). 인용: “Even small refinements to tool descriptions can yield dramatic improvements.” (Anthropic, Writing effective tools for AI agents, 2025-09-11)

58:02 도구 정의에 붙는 실행 정책

아까 Claude Code도 내부적으로 도구 계약을 관리한다고 했습니다. 우리도 도구에 이름과 설명, 응답, 에러만 관리하는 것이 아니라 그 위에 이런 실행 정책을 얹어 두면, 나중에 권한을 제어할 때 좋겠다고 생각해서 필수적인 것만 가져왔습니다. 읽기만 하는 도구인지 쓰기를 하는 도구인지, 병렬이 가능한 도구인지를 봅니다. 여기서는 병렬이 yes or no만 있는데, 병렬로 호출할 수 있다면 최대 몇 개까지 동시에 호출할 수 있는지도 계약으로 관리되면 좋겠다고 생각합니다. 그리고 항상 사용자에게 승인을 받고 실행해야 하는 도구인지까지 정책으로 붙으면 좋겠습니다.

물론 이 계약은 어떻게 관리하느냐에 따라 달라질 것이고, 추가로 필요한 메타 정보는 더 있을 수 있습니다.

슬라이드 노트: 덱 41쪽. “도구 정의에는 스키마 말고 실행 정책이 함께 붙습니다” / tool: process_refund(order_id, reason) — 고객의 상품 환불 요청을 처리한다(결제 취소 · 알림 발송). 읽기/쓰기 — write / 병렬 가능 — no / 권한 — requires approval.

59:14 MCP — 도구를 만드는 자리가 조직 쪽으로 옮겨간다

이제 MCP를 가져왔습니다. MCP 도구와 MCP에 대해 헷갈려 하는 분들이 있고, 저도 원래 엄청 헷갈렸던 부분이라, AI 시스템을 설계하는 관점에서 가져와 봤습니다.

이것은 예시입니다. 회사 내부에서 진행되는 과제는 아니고, 쇼핑 어시스턴트와 고객센터 어시스턴트라는 에이전트가 있다고 하겠습니다. 이 둘이 똑같은 도구를 필요로 하는데, 그 도구들은 이미 조직별로 API로 만들어져 있습니다. MCP가 없을 때는, 에이전트를 개발하면서 이 API를 래핑하고, 설명도 예쁘게 달고 입력 스키마도 달아서 에이전트 조직에서 직접 관리했습니다. 고객센터 에이전트도 똑같이 관리했습니다. 그런데 구매 조직의 API가 바뀌었다고 해 보겠습니다. 내부 실행 동작이 바뀌어서 수정해야 할 때, 이쪽 에이전트와 저쪽 에이전트에서 각각 직접 개발하고 관리해야 하는 지점이 생깁니다.

MCP를 두면 쇼핑 어시스턴트와 고객센터 어시스턴트는 도구의 내부를 관리할 필요가 없습니다. 구매 조직, 환불 조직, 배송 조직별로 MCP 서버를 두어 내부에서 관리합니다. 도구를 만들고, 설명을 관리하고, 응답을 제어하는 일이 쓰는 쪽에서 관리하는 쪽, 즉 가진 쪽으로 옮겨 가게 됩니다. 에이전트를 만드는 조직과 API를 가진 조직이 보통 다르지 않습니까. 그런 경우에 내부 변경 사항은 내부에서 수정하고 배포하며, 에이전트들은 어떤 MCP를 가져올지만 판단하면 됩니다. 그 역할을 해 주는 것이 MCP라고, AI 시스템을 설계한다면 이렇게 이해하면 좋겠다고 생각합니다.

슬라이드 노트: 덱 43쪽. “MCP — 도구를 만드는 자리가 조직 쪽으로 옮겨갑니다” / 클라이언트 2(쇼핑 어시스턴트, 고객센터 어시스턴트) + 서버 3(구매·환불·배송 조직). 선은 여섯 개 그대로입니다 — 줄어든 것은 조합마다 다시 만들던 래퍼입니다. 도구를 만들고 설명을 관리하는 자리가 쓰는 쪽에서 가진 쪽으로 옮겨갑니다 — 구매 API가 바뀌면 구매 조직이 자기 서버만 고칩니다.

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

비슷한 이야기로, 작년에 Anthropic이 MCP를 내서 엄청 핫해지자 Google에서 급하게 A2A라는 프로토콜을 냈습니다. 이 둘을 비슷하게 생각하는 경우가 있어서 길게는 못 다루고 짧게 가져왔습니다.

같은 요청이 들어온다고 해 보겠습니다. “배송이 너무 늦는데 취소하고 환불받을 수 있을까?” MCP에 기대하는 것은 이런 것입니다. 이 주문의 배송 상태를 조회하는 기능입니다. 특정 기능의 실행을 기대합니다. 에이전트가 MCP의 도구를 호출하면, 그 도구의 결과가 스키마대로 그대로 돌아옵니다.

A2A는 프로토콜의 전제가 애초에 어떤 에이전트에게 목표를 위임하는 것입니다. “취소와 환불이 가능한지 확인하고, 가능하면 동의를 받아서 진행해 줘” 같은 식입니다. 상대는 자기 도구와 자기 루프, 자기 컨텍스트를 가진 별도의 에이전트입니다. 그래서 이 에이전트가 판단한 결과만 받아 오고, 에이전트 B가 어떤 생각으로 어떤 과정을 거쳐 최종 결과를 냈는지는 호출한 에이전트가 알 수 없습니다. 그래서 정말 믿고 맡겨서 작업을 위임할 수 있는 경우에만 A2A를 쓰는 것이 맞다고 저는 생각합니다. 그런 차이가 있다는 점을 분리해서 봐야겠습니다.

슬라이드 노트: 덱 44쪽. “MCP 와 A2A — 결과를 기대하는가, 판단을 기대하는가” / MCP — 기능 호출, 실행 경로는 호출하는 에이전트가 소유(tools/call → 결과, 스키마대로): “이 주문의 배송 상태를 조회해줘” — 기능 실행을 기대한다. A2A — 목표 위임, 실행 경로는 위임받은 에이전트가 소유(message/send → status · artifact, working → input-required → completed): “취소·환불이 가능한지 확인하고, 가능하면 동의를 받아 진행해줘” — 업무 수행을 기대한다.

1:03:28 4절 마무리

슬라이드 노트: 덱 45쪽. 섹션 표지 “마무리” / 가져갈 것 · 설계할 때 물어볼 질문 넷, 그리고 오늘의 세 문장.

1:03:32 설계할 때 들고 갈 질문 넷

생각보다 일찍 끝났는데, 마무리로 여기 들으시는 분들이 에이전트 시스템을 설계할 때 어떤 질문을 들고 가면 좋을지 네 가지로 정리해 봤습니다. 이 내용은 발표 자료와 함께 위키에 올려 뒀으니, 필요할 때 꺼내 보시면 좋겠습니다.

슬라이드 노트: 덱 46쪽. “에이전트 시스템을 설계할 때, 이 질문들을 들고 가시면 됩니다” / 이 문제의 실행 경로를 지금 순서도로 그릴 수 있는가? 그릴 수 있다면 왜 에이전트가 필요한가? / 에이전트에 맡기는 구간과 코드가 고정하는 구간의 경계를 어디에 두는가? / 이 에이전트가 풀 수 있는 문제의 범위 — 즉 도구 집합 — 를 명시적으로 그려봤는가? 그 범위 밖의 문제를 만나면 어떻게 되는가? / 하네스 그림에서 지금 비어 있는 칸은 무엇인가? 비어 있으면 그 자리에서 무슨 일이 생기는가?

1:03:49 오늘의 세 문장

결국 이 발표에서 말씀드리고 싶었던 것은 이렇습니다. 에이전트는 모델이 다음 행동을 선택하는 시스템입니다. 실행 경로를 미리 그릴 수 있다면 굳이 에이전트를 쓰지 않는 것이 비용 측면에서 맞는 프로젝트입니다. 그리고 모델은 생각하지만 하네스가 일하게 만듭니다. 물론 어느 정도 적당히 좋은 모델은 필요하겠지만, 이 하네스를 설계하는 일에도 관심을 가지면 좋겠다는 말씀을 드리고 싶었습니다.

슬라이드 노트: 덱 47쪽. 에이전트는 모델이 다음 행동을 선택하는 시스템입니다. / 실행 경로를 미리 그릴 수 있으면 에이전트를 쓰지 않습니다. / 모델은 생각하지만, 하네스가 일하게 만듭니다.

1:04:22 감사 인사와 Q&A

오늘 제가 이야기한 것이 내가 이해하고 있던 것과 다르다고 생각하시는 분들도 있을 것 같아 걱정이 됩니다. 피드백은 메일이나 메신저로 주셔도 되니 마음껏 주시면 됩니다. 오늘은 이렇게 맞춰 보고, 시간이 조금 남았으니 채팅으로 질문을 주셔도 됩니다. 없으면 이것으로 끝내고, 개인적으로 질문해 주셔도 됩니다.

올라온 질문은 없는 것 같고, 계속 기다리기도 애매합니다. 오늘 발표는 나중에 녹화본이 올라갑니다. 참고로 시간이 날 때 오늘 이야기한 것을 텍스트로 풀어서 위키에 공유할 예정입니다. 오늘 발표하면서 제가 임의로 뺀 부분이 있을 수 있어서, 그것은 조금 더 친절하게 풀어서 텍스트로 공유하겠습니다. 오늘 발표 들어 주셔서 감사합니다. 이상으로 발표를 마치겠습니다. 감사합니다.

슬라이드 노트: 덱 49쪽. “감사합니다” / 질문 받겠습니다 / 2026-09-17 · Agentic AD2 박슬기.