워크플로와 에이전트

확인 날짜 안내

기본은 원본 발행 2024-12-19 기준이고, "이후의 정의" 문단만 효과적인 컨텍스트 엔지니어링(2025-09-29) 기준이다. 원본 맨 위에 "이 글이 설명한 도구 지형의 상당 부분이 2024년 12월 이후 바뀌었다"는 안내가 있다. 아래 구분과 원칙은 그 글 기준이고, 프레임워크·모델 이름 같은 사실은 다시 확인해야 한다. 효과적인 에이전트 만들기 2026-10-18 점검: 이 페이지의 변하는 사실은 원본이 든 예시(프레임워크 이름)뿐이라 "(원본 당시 예시)"로 표시하고 날짜 계산에서 뺐다. 나머지는 정의·원칙이다.

정의#

"에이전트"는 여러 방식으로 정의된다. 어떤 고객은 오랜 시간 독립적으로 움직이며 여러 도구로 복잡한 일을 해내는 완전 자율 시스템을 에이전트라 부르고, 어떤 고객은 미리 정한 워크플로를 따르는 더 처방적인 구현을 그렇게 부른다. Anthropic은 이 모두를 **에이전트형 시스템(agentic systems)**으로 묶되, 구조상 중요한 구분을 둔다. 효과적인 에이전트 만들기

근거: 효과적인 에이전트 만들기

이후의 정의 (2025-09-29 기준): Anthropic의 컨텍스트 엔지니어링 글은 이 글에서 워크플로와 에이전트의 차이를 강조했다고 돌아보고, 그 뒤로는 에이전트를 "루프 안에서 자율적으로 도구를 쓰는 LLM"(루프 풀이: 용어 사전의 "에이전트 루프")이라는 단순한 정의로 보게 됐다고 말한다. 효과적인 컨텍스트 엔지니어링 이 글도 에이전트를 보통 "환경 피드백을 받아 루프 안에서 도구를 쓰는 LLM"이라고 설명하므로 두 정의는 같은 방향이다. 효과적인 에이전트 만들기 → 컨텍스트 엔지니어링

출발점: 가장 단순한 해법#

원본은 LLM 애플리케이션을 만들 때 가능한 가장 단순한 해법을 찾고, 필요할 때만 복잡도를 올리라고 권한다. 이것은 에이전트형 시스템을 아예 만들지 않는다는 뜻일 수도 있다. 효과적인 에이전트 만들기

• 에이전트형 시스템은 흔히 지연과 비용을 내주고 더 나은 작업 성능을 얻는다. 이 맞바꿈이 언제 말이 되는지 따져야 한다. 효과적인 에이전트 만들기
• 많은 애플리케이션에는 검색(retrieval)과 맥락 내 예시로 단일 LLM 호출을 최적화하는 것으로 보통 충분하다. 효과적인 에이전트 만들기
• 복잡도는 결과를 입증 가능하게 개선할 때만 더한다. 성공의 열쇠는 성능을 재고 구현을 반복하는 것이다. 효과적인 에이전트 만들기
• 결론부 표현: LLM 분야의 성공은 가장 정교한 시스템을 만드는 것이 아니라 필요에 맞는 시스템을 만드는 것이다. 단순한 프롬프트로 시작해 포괄적 평가로 최적화하고, 더 단순한 해법이 부족할 때만 여러 단계의 에이전트형 시스템을 더한다. 효과적인 에이전트 만들기

패턴별로 언제 쓰고 언제 쓰지 않는지는 에이전트 시스템 패턴 고르기에 정리했다.

기본 블록: 증강 LLM(augmented LLM)#

에이전트형 시스템의 기본 블록은 검색(retrieval), 도구, 메모리 같은 증강을 더한 LLM이다. 원본은 당시 모델이 스스로 검색 쿼리를 만들고, 맞는 도구를 고르고, 무엇을 남길지 정하며 이 능력을 적극적으로 쓴다고 말한다. 효과적인 에이전트 만들기

• 구현에서 집중할 두 가지: 이 능력을 구체적 용도에 맞추는 것, 그리고 LLM에게 쉽고 잘 문서화된 인터페이스를 주는 것. 효과적인 에이전트 만들기
• 구현 방법 중 하나로 원본은 당시 막 공개한 MCP를 든다. 간단한 클라이언트 구현으로 늘어나는 서드파티 도구 생태계와 연결할 수 있다는 설명이다. 효과적인 에이전트 만들기

편집자 해석: 원본이 말하는 증강(검색, 도구, 메모리)은 컨텍스트 엔지니어링이 다루는 컨텍스트 구성 요소(도구, 외부 데이터, 메시지 기록 등)와 겹치는 대상으로 볼 수 있다. 근거: 컨텍스트 엔지니어링 글은 시스템 지시, 도구, MCP, 외부 데이터, 메시지 기록을 관리 대상으로 꼽는다. 효과적인 컨텍스트 엔지니어링

프레임워크를 쓸 때#

원본이 든 프레임워크 예는 Claude Agent SDK, AWS의 Strands Agents SDK, Rivet(드래그 앤 드롭 GUI 워크플로 빌더), Vellum(복잡한 워크플로 구축·시험 GUI 도구)이다(원본 당시 예시, 2024-12-19 글 기준, 수집본 기준 목록). 효과적인 에이전트 만들기

• 장점: LLM 호출, 도구 정의·파싱, 호출 연결 같은 저수준 작업을 단순하게 만들어 시작을 쉽게 한다. 효과적인 에이전트 만들기
• 단점: 밑의 프롬프트와 응답을 가리는 추상화 층을 더해 디버깅을 어렵게 만들 때가 많다. 더 단순한 구성으로 충분할 때도 복잡도를 더하고 싶게 만들 수 있다. 효과적인 에이전트 만들기
• 권고: LLM API를 직접 쓰는 것부터 시작한다. 많은 패턴은 코드 몇 줄로 구현할 수 있다. 프레임워크를 쓴다면 밑의 코드를 이해한다. 밑에서 무슨 일이 일어나는지에 대한 잘못된 가정이 고객 오류의 흔한 원인이다. 효과적인 에이전트 만들기
• 프로덕션으로 갈 때는 추상화 층을 줄이고 기본 구성 요소로 만드는 것을 주저하지 말라고 결론부에서 다시 말한다. 효과적인 에이전트 만들기

에이전트를 만들 때의 세 원칙#

1. 에이전트 설계를 단순하게 유지한다.
2. 에이전트의 계획 단계를 명시적으로 보여 투명성을 우선한다.
3. 철저한 도구 문서화와 시험으로 에이전트-컴퓨터 인터페이스(ACI)를 공들여 만든다.

근거: 효과적인 에이전트 만들기. 원본은 이 원칙을 따르면 강력할 뿐 아니라 신뢰할 수 있고, 유지보수할 수 있고, 사용자가 믿는 에이전트를 만들 수 있다고 말한다. ACI 설계 요령은 시스템 프롬프트·도구·예시 설계의 "도구를 프롬프트처럼 다듬기"에 있다.

에이전트는 실제로 어떻게 도는가#

• 에이전트는 사용자의 명령이나 대화로 일을 시작하고, 작업이 분명해지면 독립적으로 계획하고 움직이며, 필요하면 사람에게 돌아와 추가 정보나 판단을 구한다. 효과적인 에이전트 만들기
• 실행 중에는 매 단계 환경에서 "ground truth"(도구 호출 결과, 코드 실행 결과 등)를 얻어 진척을 판단하는 것이 결정적이다. 체크포인트나 막혔을 때 사람의 피드백을 위해 멈출 수 있다. 효과적인 에이전트 만들기
• 작업은 보통 끝나면 종료되지만, 통제를 위해 정지 조건(예: 최대 반복 횟수)을 두는 것도 흔하다. 효과적인 에이전트 만들기
• 정교한 일을 하더라도 구현은 단순한 경우가 많다. 보통 환경 피드백을 받아 루프 안에서 도구를 쓰는 LLM일 뿐이다. 그래서 도구 세트와 그 문서를 분명하고 사려 깊게 설계하는 것이 결정적이다. 효과적인 에이전트 만들기

다른 페이지와의 관계#

• 에이전트 루프: Claude Code 공식 문서(원본 날짜 미상, 수집 2026-10-18)는 Claude Code를 맥락 수집 → 행동 → 결과 확인을 반복하는 에이전트 루프로 설명하고, 도구 사용마다 돌아온 정보가 다음 결정을 이끈다고 말한다. Claude Code 작동 방식 편집자 해석: 위 "에이전트는 실제로 어떻게 도는가"의 "환경 피드백을 받아 루프 안에서 도구를 쓰는 LLM"을 한 제품이 구체적으로 설명한 예로 볼 수 있다. 원본(2024년 글)은 Claude Code의 이 루프를 말하지 않는다.
• 서브에이전트: 원본의 오케스트레이터-워커 워크플로(중앙 LLM이 작업을 나눠 워커 LLM에 맡기고 결과를 종합)와 같은 모양으로 볼 수 있다(편집자 해석, 원본은 Claude Code 서브에이전트를 말하지 않는다).
• 권한 모드: 원본은 에이전트의 자율성이 높은 비용과 오류 누적 가능성을 뜻한다며 샌드박스 환경에서의 폭넓은 시험과 적절한 가드레일을 권한다. 효과적인 에이전트 만들기
• 컨텍스트 엔지니어링: 2025-09-29 글도 "do the simplest thing that works"를 Claude 위에서 에이전트를 만드는 팀에게 여전히 가장 좋은 조언일 것으로 본다. 효과적인 컨텍스트 엔지니어링