AI-Assisted Engineering Talk #23/27

에이전트의 정의는 놀라울 만큼 단순합니다. 루프 안에서 모델이 도구를 사용하는 것. 그것이 전부이옵니다. Anthropic이 coding, computer use, search 에이전트를 만들면서 배운 교훈 역시 명쾌합니다 — “We learned the hard way.” 초기에 복잡성을 쌓을수록 반복 속도가 죽었고, 결국 돌아온 곳은 환경·도구·시스템 프롬프트라는 세 가지 기본 구성요소였습니다. 그리고 환경은 유스케이스에 의존하므로, 실질적 설계 자유도는 도구 세트와 프롬프트 단 두 가지뿐이옵니다.

에이전트의 구조

에이전트 = 루프 속 모델의 도구 사용

에이전트를 규정하는 구성요소는 세 가지이옵니다. (1) Environment — 에이전트가 작동하는 시스템, (2) Tools — 행동과 피드백의 인터페이스, (3) System Prompt — 목표, 제약, 이상적 행동의 정의. 프레임워크나 오케스트레이션 레이어가 아니라, 이 세 가지가 에이전트의 본질을 결정합니다.

설계 결정은 두 가지뿐이다

환경은 유스케이스에 의존하므로, 개발자가 가진 실질적 설계 자유도는 두 가지뿐이옵니다. 어떤 도구 세트를 제공할 것인가, 그리고 어떤 프롬프트로 지시할 것인가. 궤적 캐싱, 도구 호출 병렬화, 진행 표시 같은 최적화는 올바른 행동이 확보된 후에 추가합니다.

복잡성은 반복 속도를 죽인다

“We learned the hard way.” — 초기에 복잡성을 쌓을수록 반복 속도가 급격히 저하됩니다. 세 가지 기본 구성요소(환경, 도구, 시스템 프롬프트)에 집중하는 것이 가장 높은 ROI를 제공합니다. 최적화는 올바른 행동이 확보된 이후에 추가하는 것이지, 처음부터 설계하는 것이 아닙니다.

같은 backbone이 다른 에이전트를 만든다

Anthropic이 빌드한 coding, computer use, search 에이전트는 제품 표면과 범위와 역량이 매우 다르지만, 거의 동일한 backbone 코드를 공유합니다. 차이는 도구 세트와 시스템 프롬프트에서 옵니다. 이는 루프 자체가 아니라 도구와 프롬프트가 에이전트를 차별화하는 본질적 요소임을 실증하는 것이옵니다.

““We learned the hard way — complexity kills iteration speed.” Barry Zhang — Anthropic이 세 가지 에이전트를 만들며 체득한 핵심 교훈” ## 에이전트를 빌드하기 전에

모든 것에 에이전트를 만들지 말라

에이전트는 복잡하고 가치 있는 태스크를 스케일하는 수단이지, 모든 유스케이스의 drop-in upgrade가 아닙니다. 의사결정 트리를 명시적으로 매핑할 수 있다면 워크플로우가 비용 효율적이고 통제 가능합니다.

태스크 복잡성과 가치

모호한 문제 공간인가? 토큰 비용을 정당화하는 가치가 있는가? 이 두 질문에 “예"가 아니면 에이전트가 아닌 워크플로우가 답이옵니다.

핵심 역량 탈위험

궤적의 심각한 병목이 없는지 확인합니다. 에이전트 경로 상 하나의 단계가 지속적으로 실패한다면, 전체 루프의 ROI가 무너집니다.

에러 비용과 발견 가능성

고위험이면서 발견하기 어려운 에러가 존재하면 자율성을 제한해야 합니다. 코딩이 이상적인 에이전트 유스케이스인 이유: 출력이 unit test와 CI로 검증 가능하기 때문이옵니다.

에이전트의 눈으로 보라

에이전트의 context window에 자신을 놓아라

개발자는 자기 관점에서 에이전트를 개발하고, 에이전트의 실수에 당혹합니다. 그러나 각 스텝에서 모델은 10∼20k 토큰의 제한된 컨텍스트에 대해 추론할 뿐이옵니다. 그 컨텍스트가 충분하고 일관적인지 직접 확인해야 에이전트가 세상을 보는 방식을 이해할 수 있습니다. 에이전트를 탓하기 전에, 에이전트에게 무엇을 보여주었는지를 먼저 돌아보는 것이지요.

Claude로 Claude를 이해한다

시스템 프롬프트를 Claude에 보여주고 모호성 여부를 묻습니다. 도구 설명의 파라미터 적정성을 확인합니다. 전체 궤적을 던지고 “왜 이 결정을 했는가, 더 나은 결정을 위해 무엇이 필요한가"를 묻습니다. 자기 이해를 대체하지는 않지만, 에이전트 관점에 근접하는 실용적 방법이옵니다.

““Put yourself in the agent’s context window.” Barry Zhang — 에이전트의 실수를 탓하기 전에, 에이전트에게 무엇을 보여주었는지를 먼저 확인하라” ## 미래 방향

Budget-aware가 프로덕션 배포를 연다

워크플로우와 달리 에이전트의 비용과 지연은 통제가 어렵습니다. 시간·비용·토큰 단위로 예산을 정의하고 강제하는 방법을 찾는 것이 프로덕션 배포의 열쇠이옵니다. 이것이 해결되면 훨씬 더 많은 유스케이스가 열립니다.

Self-evolving tools: 자기 도구 개선

이미 모델을 사용하여 도구 설명을 개선하고 있지만, 이것이 meta tool로 일반화될 수 있습니다. 에이전트가 자체 도구 에르고노믹스를 설계하고 개선하면 더 범용적인 에이전트가 가능해집니다.

Multi-agent 통신의 미해결 문제

병렬화, 관심사 분리, 서브에이전트의 메인 에이전트 컨텍스트 윈도우 보호가 멀티에이전트의 장점이옵니다. 그러나 현재의 동기적 user-assistant 턴을 넘어 비동기 통신과 역할 인식 체계를 어떻게 구축할 것인가가 핵심 미해결 문제로 남아 있습니다.

검증된 인사이트

💡 [Insight 1 — 핵심] Skills vs Agents는 줌 레벨의 차이다

같은 발표자 Barry Zhang이 영상 13에서 “Don’t Build Agents, Build Skills"라 했고, 영상 23에서 “How We Build Effective Agents"라 합니다. 표면적으로 모순이지만 같은 메시지의 줌 레벨 차이이옵니다. 영상 23의 “설계 결정 = 도구 + 프롬프트"는 영상 13의 “스킬"과 동일합니다. 루프는 사소하고, 도구와 프롬프트(=스킬)가 가치의 소재. “Don’t Build Agents"의 진의는 “루프를 over-engineer하지 말라"이며, 영상 23의 “keep it simple"과 정확히 합치합니다. Anthropic의 실제 권고: 에이전트 루프는 단순하게 두고, 에너지를 도구 설계와 프롬프트 작성에 집중하라.

💡 [Insight 2 — 확장] 에이전트 간 통신은 새로운 검증 표면이다

멀티에이전트 시스템의 미해결 문제(비동기 통신, 역할 인식)는 “자율성 ≡ 검증 표면의 함수” 명제의 새로운 차원이옵니다. 기존 검증 표면은 human-agent 경계에 집중해왔으나, agent-agent 경계의 검증은 아직 미개척 영역이옵니다. 에이전트가 서로의 출력을 어떻게 검증하는가가 멀티에이전트 프로덕션의 핵심 과제가 됩니다. ## 명제 정합성: 자율성 ≡ 검증 표면

강화: 출력 검증 가능성이 자율성을 결정한다

코딩의 에이전트 적합성 이유로 “출력이 unit test/CI로 검증 가능"을 명시적으로 제시합니다. Error cost + discoverability 체크리스트는 곧 검증 표면이 좁으면 자율성을 제한하라(read-only, HITL)는 운영 규칙이옵니다.

확장: 검증 표면의 세 가지 새 sub-axis

Budget-aware → 자원 예산이 검증 심도에 직접 영향하는 새 sub-axis. Self-evolving tools → 검증 표면의 자기 확장. Multi-agent → agent-agent 경계의 검증 표면. 누적 명제의 외연이 세 방향으로 동시에 넓어집니다.

다른 영상과의 교차점

  • 같은 발표자의 두 영상입니다. 영상 13의 “스킬 = 절차적 지식 폴더"와 영상 23의 “도구 + 프롬프트 = 유일한 설계 자유도"는 같은 원리의 다른 줌 레벨이옵니다. 영상 13은 zoom-in(“루프를 over-engineer하지 마라, 스킬을 채워라”), 영상 23은 zoom-out(“에이전트 = 루프 속 모델, 설계 자유도는 도구와 프롬프트뿐”). Anthropic의 일관된 메시지를 양쪽에서 확인합니다.
  • Factor 2(프롬프트 소유)와 Factor 3(컨텍스트 소유)은 Barry의 “설계 결정 = 도구 + 프롬프트"와 같은 뿌리를 공유합니다. Factor 10(작고 집중된 에이전트)은 “모든 것에 에이전트를 만들지 말라"와 정렬되며, 두 발표 모두 에이전트의 단순성을 핵심 원칙으로 제시합니다.
  • Chris의 “컨텍스트가 AI 코드 생성의 1순위” 선언은 Barry의 “에이전트 context window에 자신을 놓아라"와 같은 원리를 도출합니다. 도구를 만드는 쪽(Anthropic)과 사용하는 쪽(Augment)이 독립적으로 같은 결론에 도달한 것이옵니다.
  • “doable 문제의 단위 = 자동 검증이 가능한 단위"라는 기준은 Barry의 “출력 검증 가능성이 적합성의 핵심 지표"와 정확히 정렬됩니다. 코딩이 에이전트의 이상적 유스케이스인 이유를 양쪽이 같은 논리로 설명합니다.
  • Microsoft의 copilot-instructions.md 체계와 Barry의 시스템 프롬프트 설계 원칙이 만납니다. “에이전트 context window에 자신을 놓아라"는 Microsoft의 환경 청결성 ↔ ROI 상관관계의 실천적 방법론이옵니다.

루프를 복잡하게 만드는 것은 엔지니어링이 아니라 과잉이옵니다. 에이전트에게 무엇을 보여줄 것인가, 어떤 도구를 건네줄 것인가 — 그 두 가지 결정에 모든 에너지를 쏟는 것이 진짜 에이전트 빌드이옵니다.