[한영자막] 에이전트 개발, 하지 말아야 할 것부터 배우세요

URL: https://www.youtube.com/watch?v=eAm9kuLmGDA 날짜: 2026-08-11 채널: Tech Bridge 발표자: Frank Coyle(컴퓨터 과학자, 30년 이상 교육, 현재 Berkeley에서 강의)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트형 AI(Agentic AI)를 제대로 설계하려면 무엇을 해야 하는지뿐 아니라, 실패를 부르는 안티패턴(anti-pattern)을 먼저 알아야 한다.== 특히 Claude Certified Architect 시험의 실제 프로덕션 시나리오를 통해, 에이전트 루프를 통제하고 컨텍스트를 제한하며 도구와 하위 작업을 분리하는 방법을 설명한다.

• LLM은 도구를 직접 실행하는 주체가 아니라, 도구 호출에 필요한 구조와 인자를 제안하는 확률적 다음 단어 예측기다.
• stop_reason을 확인하지 않고 응답을 곧바로 사용하면 도구 호출 중단, 토큰 고갈, 부분 응답을 놓칠 수 있다.
• 하나의 에이전트에 도구와 컨텍스트를 과도하게 몰아주면 비용과 혼란이 늘어나므로, 전문화·컨텍스트 격리·요약·압축이 필요하다.
• CI에서는 대화형 모드를 제거하고, 시간이 허용될 때는 배치 처리로 비용을 줄여야 한다.

발표자의 전체 철학은 “실패하지 않는 완벽한 설계”가 아니라 “만들고, 실패 원인을 관찰하고, 안티패턴을 제거하며 개선하는 실험”이다. 영상은 Claude 시험 소개에서 출발해 고객 지원 루프, Claude Code 규칙, 멀티 에이전트 연구, 개발 생산성, CI, 구조화된 데이터 추출까지 이어진다.

1. 에이전트 시대에 필요한 태도와 시험의 맥락

컴퓨터 과학 지식만으로 자동으로 취업이 보장되던 시대가 약해진 만큼, 실제 에이전트 시스템이 실패하는 지점을 이해하는 것이 새로운 준비가 된다.

1.1. 발표자의 문제의식: AI가 바꾼 컴퓨터 과학의 진입 경로

1. 발표자와 강의 배경

   1. Frank Coyle: 자신을 컴퓨터 과학 분야의 사람이라고 소개하며 30년 넘게 컴퓨터 과학을 가르쳐 왔다고 말한다.
   2. 현재의 역할: 현재 Berkeley에서 가르치고 있으며, 과거와 현재의 학생들이 공통으로 AI 때문에 어려움을 겪고 있다고 설명한다.

2. ‘컴퓨터 과학=마법의 취업 경로’라는 공식의 붕괴

   1. 변화한 현실: 컴퓨터 과학이 더 이상 취업으로 가는 마법 같은 통로가 아니게 되었다.
   2. 교육적 대응: 발표자는 학생들이 에이전트형 AI의 세계에 대비할 수 있도록 새로운 학습 방식과 실험 계획을 찾고 있다.

1.2. Claude Certified Architect 시험이 제공하는 학습 지도

1. 시험의 성격

   1. 출시 시점: Claude Certified Architect 시험은 3월에 출시된 매우 새로운 시험이라고 소개된다.
   2. 대상과 비용: Claude·Anthropic 생태계에 속한 기업이 이용할 수 있고, 개인은 99달러를 내고 응시할 수 있다.
   3. 재응시 제한: 개인은 6개월에 한 번 시험을 볼 수 있다.
   4. 진행 방식: 시간 제한이 있고 감독(proctored)을 받으며, 단순한 지식 확인이 아니라 시나리오 기반의 객관식 문제로 구성된다.
   5. 현실 제약의 반영: 문제의 선택지는 실제 운영 환경의 제약과 프로덕션 시나리오를 바탕으로 한다.

2. 다섯 가지 출제 영역

   1. 에이전트 아키텍처(Agentic Architecture): 전체 시험의 27%를 차지하며, 루프·오케스트레이션·제어 흐름을 다룬다.
   2. Claude Code 설정과 워크플로: Claude Code 시스템을 구성하고 작업 흐름에 적용하는 영역으로 20%를 차지한다.
   3. 프롬프트 엔지니어링과 구조화된 출력: 프롬프트를 설계하고 JSON 등 구조화된 형식으로 출력을 만드는 방법을 다룬다.
   4. 도구 설계와 Model Context Protocol(MCP) 통합: 에이전트가 사용할 도구의 경계를 정하고 MCP를 연결하는 역량을 확인한다.
   5. 컨텍스트 관리와 신뢰성(Context Management and Reliability): 토큰·컨텍스트를 관리하고 일관되고 안전한 실행을 확보하는 영역이다.
   6. 시험 여부와 무관한 가치: 발표자는 이 영역들이 시험 준비에만 필요한 것이 아니라, 에이전트형 AI가 던질 실무 문제를 준비하는 데도 유효하다고 말한다.

1.3. 여섯 개 프로덕션 시나리오와 ‘하지 말아야 할 것’의 관점

1. 시험이 제공하는 시나리오 풀

   1. 총 여섯 개: Anthropic은 여섯 개의 프로덕션 시나리오를 제공한다.
   2. 무작위 선택: 시험에서는 여섯 개 중 네 개를 무작위로 고르고, 문제는 선택된 네 시나리오를 중심으로 출제된다.

2. 영상에서 예고한 시나리오

   1. 고객 지원 해결 에이전트: 에이전트 루프, 제어, stop_reason이 핵심이다.
   2. Claude를 이용한 코드 생성: 프로젝트 규칙을 계층적으로 관리하는 CLAUDE.md가 핵심이다.
   3. 멀티 에이전트 연구 시스템: 에이전트를 어떻게 분배하고, 허브 앤 스포크(hub-and-spoke)에서 누가 오케스트레이터가 될지, 각 에이전트가 얼마나 알아야 할지가 문제다.
   4. 코드를 이용한 개발자 생산성: 하위 작업을 격리하고 각 작업을 독립된 작은 세계에 두는 것이 핵심이다.
   5. Claude Code의 지속적 통합(CI): 대화형 실행을 파이프라인에 남겨 두지 않고 자동 실행해야 한다.
   6. 구조화된 데이터 추출: 발표자가 마지막 시나리오로 언급하지만, 이 영상에서는 구체적인 패턴을 자세히 전개하지 않는다.

3. 안티패턴을 먼저 보는 이유

   1. 해결책은 여러 개일 수 있음: 같은 문제를 해결하는 방법은 여러 가지일 수 있다.
   2. 오답은 강한 신호가 됨: 반면 무엇을 하지 말아야 하는지는 문제의 핵심을 빠르게 드러내고, 시험 문제에서 올바른 선택을 고르는 단서가 된다.
   3. 설계 방향의 역전: 하지 말아야 할 것을 알면 그 반대편에 해야 할 설계 원칙이 선명해진다.

2. 실험·제작·패턴으로 이어지는 에이전트 설계 철학

에이전트 개발은 읽기만 하는 활동이 아니라 만들고 실행하며 실패를 관찰하는 활동이고, 그 과정에서 패턴과 안티패턴을 축적해야 한다.

2.1. 실패를 ‘만들기(make)’의 일부로 보기

1. Sister Corita Kent의 문장

   1. 직접 인용: “Nothing is a mistake. There’s no win and no fail. There’s only make.”라고 소개한다.
   2. 한국어 의미: “아무것도 실수가 아니다. 승리도 실패도 없고, 오직 만드는 일이 있을 뿐이다”라는 뜻이다.

2. 실행 중심의 실험

   1. 반복 강조: “experiment, experiment, experiment”라고 반복하며 실험을 핵심 태도로 둔다.
   2. 읽기와 만들기의 결합: 읽는 것만으로 끝내지 말고 직접 해보고 무언가를 만들어야 한다.
   3. 실패의 정상성: 만든 것이 자주 작동하지 않는 것은 자연스러운 과정이다.

3. Thomas Edison의 사례

   1. 직접 인용: “I have not failed. I’ve only found 10,000 ways that don’t work.”라고 말한다.
   2. 에이전트 개발에의 적용: 작동하지 않는 설계도 관찰 가능한 데이터이며, 반복 실험을 통해 안티패턴 목록과 더 나은 패턴을 얻을 수 있다.

2.2. 객체의 디자인 패턴에서 에이전트의 패턴·안티패턴으로

1. 기존 디자인 패턴의 역사

   1. 시점: 객체지향 프로그래밍과 함께 1990년대 초 디자인 패턴 운동이 등장했다.
   2. 당시의 대상: 당시에는 객체를 어떻게 설계하고 조합할지에 대한 패턴을 다뤘다.

2. 새로운 대상과 관찰법

   1. 에이전트 패턴: 이제는 객체뿐 아니라 에이전트를 구성하고 조정하는 패턴이 필요하다.
   2. 안티패턴의 중요성: 에이전트가 무엇을 해야 하는지를 알려면 무엇을 하지 않아야 하는지도 알아야 한다.
   3. 영상의 전개 방식: 이후 사례들은 각 시나리오의 안티패턴을 먼저 제시하고, 그에 대응하는 운영 원칙을 설명한다.

3. 루프가 에이전트형 AI에 부여하는 실행력

루프는 유행하는 프롬프트 기법이 아니라, 모델 호출·도구 실행·결과 확인을 반복하는 에이전트 시스템의 제어 구조다.

3.1. ‘루프를 설계한다’는 새로운 개발자의 역할

1. 최근의 루프 열풍

   1. Boris Cherny의 표현: 그는 코드를 쓰지 않고 루프를 쓴다고 말한다는 사례가 소개된다.
   2. Peter Steinberger의 표현: OpenClaw의 대가로 소개된 Peter Steinberger는 더 이상 코딩하지 않고 에이전트에 프롬프트를 주는 루프를 설계한다고 말한다.
   3. 발표자의 반문: 발표자는 “루프가 정말 새로운 것인가?”라고 되묻고 컴퓨팅의 기초로 돌아간다.

2. 프로그래밍 언어 논쟁에서 얻는 교훈

   1. 초기 컴퓨팅의 논쟁: Fortran과 Cobol 등 프로그래밍 언어가 폭발적으로 늘어나면서 각 언어가 서로 더 낫다고 주장하는 싸움이 있었다.
   2. Böhm과 Jacopini의 1966년 증명: 어떤 언어가 튜링 완전(Turing complete)이 되어 컴퓨터가 계산할 수 있는 모든 것을 계산하려면 세 가지 구성만 있으면 된다는 점을 보였다.
   3. 세 가지 구성: 문장을 순서대로 실행하는 순차 실행, if-then 조건문, 반복 실행을 위한 루프다.

3. 에이전트형 AI에서 루프의 의미

   1. 기존 흐름: 지금까지는 프롬프트를 보내고, 필요하면 조건문을 적용하는 순차적 흐름이 중심이었다.
   2. 루프의 추가: 모델 응답을 보고 도구를 실행한 뒤 다시 모델에 결과를 보내는 반복이 추가되면서 시스템이 더 강력해진다.
   3. 흥미로운 지점: 발표자는 이 루프가 에이전트형 AI를 흥미롭게 만드는 핵심이라고 설명한다.

4. 시나리오 1 — 고객 지원 해결 에이전트와 stop_reason

고객 지원 에이전트의 핵심은 모델의 첫 응답을 최종 답으로 간주하지 않고, 중단 이유를 판독하며 도구 호출 루프를 안전하게 끝내는 것이다.

4.1. 도구 결과를 맹목적으로 사용하는 안티패턴

1. 나쁜 흐름

   1. 직접 사용: 에이전트에게 무언가를 시킨 뒤 응답을 그대로 받아 사용하는 방식은 위험하다.
   2. 놓치는 상태: 응답이 최종 답인지, 도구를 호출하라는 중간 신호인지, 토큰이 모자라 중단된 부분 답인지 구분할 수 없다.

2. 필요한 제어

   1. 반복 구조: while True 형태의 루프 안에서 모델을 호출한다.
   2. 판정 지점: 매 호출 뒤 응답의 stop_reason을 확인해 다음 행동을 결정한다.

4.2. LLM 호출과 실제 도구 실행의 분리

1. 첫 번째 블록 — 모델 호출

   1. 입력: 모델에 messages를 전달한다. 이는 프롬프트, 지금까지의 대화, 컨텍스트 윈도우에 들어 있는 메시지의 순서다.
   2. 도구 설명: 모델에는 사용할 수 있는 도구와 컨텍스트가 함께 제공된다.
   3. 모델의 한계: LLM은 확률적 다음 단어 예측기이며, 도구를 직접 실행할 수 없다.

2. 모델이 실제로 하는 일

   1. 호출 계획 생성: 어떤 도구를 사용할지, 도구가 무엇을 할 수 있는지, 어떤 인자를 넣을지 판단한다.
   2. 구조화된 요청 반환: 실행 가능한 도구 호출과 파라미터를 반환하며, 실제 실행은 애플리케이션 코드가 담당한다.
   3. 핵심 오해 교정: “LLM이 도구를 실행한다”라고 말하는 것은 편의상 표현일 뿐, 모델 자체가 외부 작업을 수행하는 것은 아니다.

3. 두 번째 블록 — 도구 실행

   1. tool_use 판정: stop_reason이 도구 사용을 나타내면 모델이 도구를 요청한 것이므로 루프를 멈추지 않는다.
   2. 애플리케이션 실행: 코드가 모델이 추출한 파라미터로 도구를 실행한다.
   3. 결과 재주입: 모델의 응답과 도구 실행 결과를 메시지에 추가해 다시 모델 호출로 돌아간다.

4.3. 루프 종료, 사람 개입, 토큰 고갈

1. 정상 종료

   1. 성공한 도구 결과: 모델이 도구 실행 결과를 보고 성공했다고 판단하면 더 이상 도구를 호출하지 않고 답변을 만든다.
   2. 루프 탈출: 발표자는 이 상태를 continues라고 표현하며, 더 실행할 도구가 없는 경우 루프를 끝내고 답을 취한다고 설명한다.

2. Human-in-the-loop

   1. 신뢰도 확인: 최종 답변을 바로 고객에게 보내기 전에 사람이 개입해 신뢰도를 확인할 수 있다.
   2. 분기: 충분히 좋아 보이면 답변을 유지하고, 그렇지 않으면 사람에게 에스컬레이션한다.

3. 토큰 고갈 처리

   1. 별도의 중단 이유: stop_reason에는 토큰을 모두 사용해 더 이상 생성하지 못했다는 상황도 나타날 수 있다.
   2. 부분 응답 경고: 이때 반환된 답은 모델이 중간에 멈춘 부분 답변일 수 있다.
   3. 운영 조치: 부분 답을 완성된 답으로 취급하지 말고, 재시도·축약·사람 검토 등 별도의 조치를 취해야 한다.

5. 시나리오 2 — Claude Code 코드 생성과 계층적 규칙

코드 생성 에이전트는 한 번의 프롬프트보다 프로젝트의 규칙을 지속적으로 주입하는 구조가 중요하며, Claude Code에서는 CLAUDE.md 계층이 그 역할을 한다.

5.1. CLAUDE.md에 지식과 규칙을 모으기

1. 파일의 목적

   1. 프로젝트 지침: Claude Code가 알아야 할 규칙과 정보를 Markdown 파일에 적어 둔다.
   2. 응답 제어: 에이전트가 프로젝트의 관례와 작업 방식을 따르도록 지속적인 컨텍스트를 제공한다.

2. 계층 구조

   1. 최상위 레벨: 프로젝트 최상단에 하나의 CLAUDE.md를 둔다.
   2. 프로젝트 내부: 프로젝트 폴더 안쪽에도 해당 범위에 맞는 파일을 둘 수 있다.
   3. 디렉터리 레벨: 더 안쪽의 개별 디렉터리에도 그 디렉터리에만 적용되는 규칙을 지정할 수 있다.

5.2. 범위에 맞는 규칙으로 응답을 통제하기

1. 계층화의 효과

   1. 전역 규칙과 지역 규칙의 분리: 전체 프로젝트 규칙과 특정 디렉터리의 세부 규칙을 한 곳에 뒤섞지 않는다.
   2. 작업 맥락에 맞는 제어: 에이전트가 현재 작업 위치에 맞는 지침을 읽고 그 범위에 맞게 응답하게 한다.

2. 시나리오의 핵심 교훈

   1. 한 번의 거대한 프롬프트 지양: 모든 규칙을 매번 수동으로 붙여 넣는 대신 계층적 파일 구조로 관리한다.
   2. 일관성 확보: 코드 생성의 결과는 모델의 즉흥적 응답뿐 아니라 프로젝트 규칙의 계층에 의해 통제되어야 한다.

6. 시나리오 3 — 멀티 에이전트 연구 시스템

멀티 에이전트 시스템에서는 모두가 모든 일을 하는 만능 에이전트보다, 한 가지 역할과 적은 수의 도구에 집중하는 전문 에이전트가 낫다.

6.1. 만능 에이전트와 과도한 도구의 안티패턴

1. 문제의 출발점

   1. 분배의 어려움: 여러 에이전트가 조사하고 결과를 가져오게 할 때, 어떤 일을 누구에게 맡길지와 결과를 어떻게 모을지가 문제다.
   2. 오케스트레이션 질문: 허브 앤 스포크 구조에서 오케스트레이터는 누구인지, 각 에이전트가 얼마나 많은 정보를 알아야 하는지 정해야 한다.

2. 나쁜 설계

   1. 하나의 에이전트에 전부 제공: 한 에이전트에 수많은 도구를 장착하고 어떤 일이든 시키는 방식은 안티패턴이다.
   2. 목수 비유: 집에 목수를 불렀는데 그 사람이 배관공 도구, 목수 도구, 전기공 도구를 모두 들고 와서 무엇이든 할 수 있다고 말한다면, 발표자는 오히려 전문 목수를 원할 것이라고 비유한다.
   3. 판단의 분산: 도구와 역할이 많아질수록 에이전트가 무엇에 집중해야 하는지 모호해지고 결과의 품질과 예측 가능성이 떨어진다.

6.2. 전문화와 단일 책임

1. 함수형 프로그래밍과의 연결

   1. 한 가지 일: 함수형 프로그래밍에서 함수가 한 가지 일을 해야 한다는 생각을 에이전트 설계에도 적용한다.
   2. 도구 수 제한: 각 에이전트에 한 가지 역할과 한두 개 정도의 도구만 제공하면 목적과 실패 범위가 명확해진다.

2. 설계 원칙

   1. 전문화: 조사자, 비평자, 데이터 추출자처럼 역할을 잘게 나눠 각 에이전트가 자기 목적에 집중하게 한다.
   2. 과적재 금지: “specialize, don’t overload”, 즉 전문화하고 과도하게 싣지 않는 것이 핵심이다.

6.3. 컨텍스트 유출과 그룹싱크 방지

1. 메인 컨텍스트로의 유출 안티패턴

   1. 컨텍스트 스필오버: 하위 에이전트의 긴 사고와 결과가 메인 컨텍스트에 그대로 섞이면 컨텍스트가 불필요하게 커진다.
   2. 비용 증가: 컨텍스트는 토큰이고 토큰은 비용이므로, 컨텍스트가 늘어날수록 비용도 커진다.
   3. 정확도 저하: 정보가 지나치게 많아지면 LLM이 혼란을 느끼고 답변 정확도가 낮아질 수 있다.
   4. 큰 창의 함정: 백만 토큰 컨텍스트 윈도우가 있다고 해서 모든 정보를 넣어야 하는 것은 아니며, 필요한 정보만 제한해서 전달해야 한다.

2. 비평 에이전트의 입력을 제한하기

   1. 필요한 입력: 어떤 주장을 검토하는 비평 에이전트에는 claim과 evidence만 전달한다.
   2. 전달하지 않는 것: 그 주장을 만든 과정의 사고 흐름과 불필요한 중간 컨텍스트는 주지 않는다.
   3. 독립적 판단: 결과와 근거에 집중하게 하면 이전 에이전트의 사고 경로에 끌려가지 않고 비평할 여지가 생긴다.

3. 그룹싱크(groupthink) 비유

   1. 협업의 위험: 여러 에이전트가 서로 대화하고 협력하면 모두가 하나의 생각으로 수렴하는 그룹싱크가 생길 수 있다.
   2. 피자 파티 비유: 파티에서 원래 피자를 원하지 않던 사람도 분위기를 망치기 싫어 결국 다른 사람을 따라 피자를 먹게 되는 상황에 비유한다.
   3. 에이전트에의 적용: 에이전트도 비슷하게 서로 영향을 주고받으며 이견을 잃을 수 있다.
   4. 피자 조각 원칙: 각 에이전트에는 문제 전체가 아니라 자기 역할에 필요한 한 조각만 제공해야 독립적인 판단을 유지할 수 있다.

7. 시나리오 4 — 개발자 생산성과 하위 작업 격리

개발 작업에서 가장 큰 안티패턴은 모든 하위 작업의 원본 출력을 주 스레드에 쌓는 것이며, 해결책은 포크·요약·압축으로 메인 컨텍스트를 보호하는 것이다.

7.1. 무제한 컨텍스트와 원본 출력 덤프의 안티패턴

1. 나쁜 흐름

   1. 전체 출력 투입: 각 하위 작업이 수행한 모든 출력과 내부 진행을 주 스레드에 그대로 덤프한다.
   2. 컨텍스트 범람: 하위 작업이 늘어날수록 메인 컨텍스트가 가득 차고 중요한 정보가 묻힌다.
   3. 무한 성장: 컨텍스트를 제한 없이 키우는 것은 비용과 혼란 때문에 좋지 않다.

2. 권장 방향

   1. 하위 출력 격리: 하위 작업의 실행 공간을 주 스레드와 분리한다.
   2. 필요한 결과만 전달: 원본 로그·중간 과정이 아니라 메인 작업에 필요한 요약만 가져온다.
   3. 긴 세션 압축: 세션이 길어지면 컨텍스트를 압축해 계속 작업할 수 있게 한다.

7.2. 로그 스캔을 통한 컨텍스트 포크 패턴

1. 하위 에이전트에 맡길 작업

   1. 구체적 지시: “모든 로그에서 오류를 스캔하라”는 작업을 별도 에이전트에 맡긴다.
   2. 독립 스레드: context fork로 별도의 실행 스레드를 만든다.

2. 포크의 효과

   1. 오염 방지: 포크된 에이전트가 생각하고 처리하면서 추가한 토큰은 메인 컨텍스트를 오염시키지 않는다.
   2. 요약 반환: 에이전트는 로그의 문제 위치를 요약하고, 메인 컨텍스트에는 그 요약만 합친다.
   3. 정보량 제어: 문제를 해결하는 데 필요하지 않은 원본 로그와 중간 추론을 주 스레드에 재주입하지 않는다.

7.3. 토큰 수 확인과 컨텍스트 압축

1. 임계치 기반 관리

   1. 토큰 카운트 확인: 마지막 블록에서 현재 토큰 수를 확인할 수 있다.
   2. 150,000 토큰 기준: 토큰이 150,000개를 넘으면 compact를 실행하는 식으로 한도를 설정할 수 있다.

2. 압축 알고리즘

   1. Anthropic과 Cohere: 발표자는 두 회사가 거대한 컨텍스트를 어떤 방식으로든 줄이는 컨텍스트 압축 알고리즘을 제공한다고 언급한다.
   2. 구현의 불확실성: 발표자도 내부 구현이 정확히 어떻게 되어 있는지는 잘 모르겠다고 말한다.
   3. 실무적 의미: 구현을 모두 알지 못하더라도, 긴 세션에서 컨텍스트를 관리하고 요약·압축하는 기능 자체를 설계에 포함해야 한다.

7.4. 컨텍스트 압축에 관한 부가 일화

1. 거리에서 받은 책

   1. 발표자의 경험: 길에서 사람들이 나눠 주는 작은 책을 보면 받아 보라고 말한다.
   2. 책의 사례: Sam Bagwell이라는 사람의 책을 언급하며, 본인은 Sam과 아무런 관계가 없다고 덧붙인다.

2. 페이지 32의 내용

   1. 커스텀 로직: 그 회사가 컨텍스트 압축을 위한 사용자 정의 로직을 제공한다는 내용이 온라인 책 32페이지에 있다고 말한다.
   2. 확장 가능성: 기본 클래스를 확장해 자신에게 중요한 데이터를 보존하는 고유한 데이터 압축 방식을 만들 수 있다고 소개한다.
   3. 발표자의 평가: 이처럼 어떤 정보를 중요하게 볼지에 따라 자체 압축 로직을 만들 수 있다는 점이 흥미로운 관점이라고 평가한다.

8. 시나리오 5 — Claude Code의 지속적 통합(CI)

CI 파이프라인은 사람이 매번 허가를 눌러 주는 대화형 세션이 아니라, 미리 정의된 규칙에 따라 멈추지 않고 실행되는 자동화된 흐름이어야 한다.

8.1. 대화형 모드를 파이프라인에 넣는 안티패턴

1. 문제의 형태

   1. 항상 interactive로 실행: 파이프라인의 모든 작업을 대화형 모드로 두는 것은 적절하지 않다.
   2. 중단되는 질문: Claude가 “이 작업을 할까요?”, “저 작업을 할까요?”, “권한을 받아도 될까요?”라고 물으며 중단할 수 있다.

2. CI의 설계 방향

   1. 비대화형 실행: 파이프라인에서는 필요한 권한과 정책을 미리 설정하고 처음부터 끝까지 실행되게 해야 한다.
   2. 직렬 흐름 유지: 사람이 매 단계 승인하지 않아도 작업이 계속 진행되는 설정 방법을 사용한다.
   3. 안전한 사전 설계: 대화형 확인을 없애는 것이 무제한 권한을 주라는 뜻은 아니며, 자동화 전에 허용 범위와 실패 처리 정책을 정해야 한다.

8.2. 배치 처리로 토큰 비용 줄이기

1. 배치의 개념

   1. 작업 묶기: 프롬프트와 수행할 작업을 모아 배치로 제출한다.
   2. 비동기 실행: 즉시 대화형 결과가 필요하지 않은 작업을 백그라운드에서 처리한다.

2. 비용과 시간의 교환

   1. 비용 절감: 발표자는 배치 모드를 이용하면 토큰 비용을 50% 줄일 수 있다고 설명한다.
   2. 결과 대기: 결과는 즉시 오지 않고 24시간 단위의 약속된 처리 시간을 감수해야 한다고 말한다.
   3. 적합한 상황: 잠을 자거나, 휴가를 가거나, 하루를 쉬는 동안 결과를 기다릴 수 있는 작업에 적합하다.
   4. 선택 기준: 즉시성이 중요하면 일반 실행을 쓰고, 시간이 충분하면 배치로 비용을 절약한다.

9. 영상에서 짧게 언급된 구조화된 데이터 추출

발표자는 여섯 번째 시나리오로 구조화된 데이터 추출을 열거하지만, 앞선 다섯 시나리오처럼 구현 패턴이나 안티패턴을 설명할 시간은 확보하지 못했다.

9.1. 출제 영역으로서의 의미

1. 앞서 언급된 관련 역량

   1. 프롬프트 엔지니어링: 원하는 형식과 필드를 명확히 지시해야 한다.
   2. JSON 구조화: 영상 초반 시험 영역 소개에서 JSON을 사용한 구조화된 출력이 언급된다.

2. 노트 작성상의 범위

   1. 확인 가능한 내용: 이 영상의 자막에서 확인되는 것은 구조화된 데이터 추출이 시나리오 목록에 포함된다는 점이다.
   2. 추정 배제: 발표자가 구체적인 스키마, 검증, 재시도 방식을 말하지 않았으므로 세부 구현을 임의로 추가하지 않는다.

주요 발언 모음

“Nothing is a mistake. There’s no win and no fail. There’s only make.”

“아무것도 실수가 아니다. 승리도 실패도 없고, 오직 만드는 일이 있을 뿐이다.”

“I have not failed. I’ve only found 10,000 ways that don’t work.”

“나는 실패한 것이 아니다. 작동하지 않는 방법 10,000가지를 찾아냈을 뿐이다.”

“The LLM is not executing these tools.”

“LLM은 이 도구들을 실행하는 것이 아니다.”

“Specialize, don’t overload.”

“전문화하라. 과도하게 싣지 마라.”

“If you want to reach out to me, reach out to me, coil at Berkeley.”

발표자는 Berkeley의 자신의 연락처와 웹사이트를 찾아보라고 말하며, 마지막에는 “그게 내 이야기이고 나는 그 이야기를 고수한다”는 식으로 강연을 맺는다.

핵심 데이터 & 수치

• 30년 이상: Frank Coyle이 컴퓨터 과학을 가르쳐 온 기간이다.
• 3월: Claude Certified Architect 시험이 출시된 시점이다.
• 99달러: 개인이 시험에 응시하기 위해 지불하는 비용이다.
• 6개월: 개인이 시험을 다시 볼 수 있는 간격이다.
• 5개 영역: 에이전트 아키텍처, Claude Code 설정·워크플로, 프롬프트·구조화 출력, 도구 설계·MCP 통합, 컨텍스트 관리·신뢰성이다.
• 27%: 시험에서 에이전트 아키텍처가 차지하는 비중이다.
• 20%: 시험에서 Claude Code 설정과 워크플로가 차지하는 비중이다.
• 6개 중 4개: 제공되는 여섯 프로덕션 시나리오 중 시험이 무작위로 선택하는 시나리오 수다.
• 1966년: Böhm과 Jacopini가 튜링 완전 계산에 필요한 세 가지 제어 구조를 보인 해다.
• 3가지 제어 구조: 순차 실행, if-then 조건문, 루프다.
• 1~2개 도구: 발표자가 전문 에이전트 하나에 제공할 도구 수의 예로 제시한 범위다.
• 1,000,000 토큰: 큰 컨텍스트 윈도우가 있어도 모든 정보를 넣어서는 안 된다는 함정의 예시다.
• 150,000 토큰: 컨텍스트 압축을 실행할 수 있는 예시 임계치다.
• 50%: 배치 모드에서 토큰 비용을 줄일 수 있다고 발표자가 설명한 수준이다.
• 24시간: 배치 결과를 기다리는 비동기 처리 시간의 조건으로 발표자가 언급한 값이다.

결론 및 시사점

1. 모델과 실행기를 분리하라: LLM은 도구를 직접 실행하지 않으므로, 모델의 구조화된 도구 요청을 애플리케이션 코드가 실행하고 그 결과를 다시 모델에 넣는 루프를 구현해야 한다.
2. 항상 stop_reason을 확인하라: 정상적인 도구 사용 중단인지, 최종 답변인지, 토큰 고갈로 인한 부분 응답인지 확인해야 안전한 종료와 재처리가 가능하다.
3. 사람의 검토 지점을 설계하라: 고객 지원처럼 오류 비용이 큰 흐름에서는 신뢰도 확인 후 사람에게 에스컬레이션하는 Human-in-the-loop를 둔다.
4. 에이전트를 전문화하라: 모든 도구를 한 에이전트에 몰아주지 말고, 한 가지 목적과 한두 개의 도구를 가진 작은 에이전트들로 나눈다.
5. 컨텍스트는 작게 유지하라: 토큰은 비용이고, 과도한 컨텍스트는 모델의 혼란과 그룹싱크를 부른다. 큰 컨텍스트 윈도우도 필요한 정보만 넣어야 한다.
6. 하위 작업은 포크하고 요약만 병합하라: 로그 스캔 등 긴 작업은 별도 컨텍스트에서 처리한 뒤, 메인 스레드에는 문제 해결에 필요한 요약만 반환한다.
7. 긴 세션을 압축하라: 토큰 카운트를 감시하고 임계치를 넘으면 압축을 실행하거나 중요한 정보를 보존하는 자체 압축 로직을 검토한다.
8. CI는 비대화형으로 만들라: 파이프라인이 매 단계 권한을 묻도록 두지 말고, 허용 범위와 실패 정책을 사전에 정의한 뒤 끝까지 자동 실행한다.
9. 지연을 감수할 수 있으면 배치를 사용하라: 즉시 결과가 필요 없는 작업은 배치로 보내 토큰 비용을 낮출 수 있다.
10. 가장 중요한 실천 태도: 실패를 결과의 반대말로 보지 말고, 작동하지 않는 방법을 발견하는 실험으로 받아들여 직접 만들고 반복하라.

핵심 요약 (20줄)

1. Frank Coyle은 30년 이상 컴퓨터 과학을 가르친 Berkeley 강사로 자신을 소개한다.
2. 그는 AI 때문에 컴퓨터 과학이 더 이상 취업을 보장하는 마법 같은 경로가 아니게 되었다고 설명한다.
3. Claude Certified Architect 시험은 3월에 출시되었고 개인은 99달러로 6개월마다 응시할 수 있다.
4. 시험은 에이전트 아키텍처, Claude Code, 프롬프트, 도구·MCP, 컨텍스트·신뢰성을 다룬다.
5. 시험에서는 여섯 개 프로덕션 시나리오 중 네 개가 무작위로 선택된다.
6. 발표자는 에이전트 설계에서 해야 할 일을 이해하려면 안티패턴부터 알아야 한다고 주장한다.
7. Sister Corita Kent의 문장처럼 실패와 승리보다 직접 만들고 실험하는 태도가 중요하다.
8. Böhm과 Jacopini의 1966년 결과는 순차 실행, 조건문, 루프가 계산의 기본 구조임을 보여 준다.
9. 에이전트형 AI는 모델 호출과 도구 실행을 반복하는 루프에서 새로운 실행력을 얻는다.
10. LLM은 도구를 직접 실행하지 않고 도구명과 파라미터를 반환하는 확률적 모델이다.
11. 고객 지원 에이전트는 매 응답의 stop_reason을 확인해 도구 호출 여부를 판단해야 한다.
12. 정상 종료처럼 보이는 응답도 토큰 고갈로 인한 부분 답일 수 있으므로 별도 처리가 필요하다.
13. Claude Code는 프로젝트와 디렉터리별 CLAUDE.md 파일로 규칙을 계층화할 수 있다.
14. 멀티 에이전트 연구에서는 많은 도구를 가진 만능 에이전트보다 전문화된 에이전트가 적합하다.
15. 비평 에이전트에는 주장과 근거만 주어야 이전 에이전트의 사고에 끌려가는 그룹싱크를 줄일 수 있다.
16. 하위 작업의 전체 출력을 메인 스레드에 넣으면 토큰 비용과 혼란이 커진다.
17. context fork로 로그 스캔을 격리하고 메인 컨텍스트에는 요약만 병합해야 한다.
18. 150,000토큰 같은 임계치를 정해 긴 컨텍스트를 압축하는 운영 규칙을 둘 수 있다.
19. CI에서는 대화형 모드를 피하고 시간이 허용되는 작업은 50% 저렴한 배치 처리를 활용할 수 있다.
20. 최종 메시지는 실패하지 않는 것보다 만들고 관찰하고 개선하는 반복이 에이전트 개발의 핵심이라는 점이다.