Workflow인가 Agent인가? AI 에이전트 핵심 용어와 아키텍처 한 번에 정리하기 (D2 리뷰)

최근 팀 내에서 "이거 에이전트 맞나요?", "그럼 하네스는 누가 만들죠?" 같은 질문이 오갈 때마다 서로 다른 그림을 그리고 있다는 걸 느꼈다. 누군가는 "Context에 넣어두면 된다"고 하고, 누군가는 "그건 Memory 아니냐"고 되묻는다. MCP와 A2A도 마찬가지다. 기존 REST API랑 뭐가 다르냐는 질문에 바로 답하기 어려웠다. 네이버 D2 블로그에 올라온 "에이전트, 개념부터 같이 정리해봐요" 세션(원문 링크)도 같은 문제의식에서 출발한다. Anthropic·OpenAI·MCP·A2A 스펙 원문을 다시 읽고 실물을 확인해본 결과를 공유하는 발표다. 이 글에서는 그 문제의식을 따라가면서, 용어들을 실무 관점에서 다시 정리해본다.

기술 개요 & 등장 배경

용어 혼란이 생기는 근본 원인은 "에이전트"라는 단어가 구현 난이도가 전혀 다른 두 가지를 동시에 가리키기 때문이다. 하나는 미리 정해진 순서대로 LLM 호출과 도구 실행을 엮어 놓은 워크플로우(workflow)이고, 다른 하나는 LLM이 다음에 무엇을 할지 스스로 결정하며 반복 실행하는 에이전트(agent)다. 워크플로우는 분기와 실행 순서가 코드에 고정돼 있어 예측 가능하지만, 에이전트는 모델이 스스로 제어 흐름을 쥐기 때문에 유연한 대신 결과를 예측하기 어렵다. 여기에 더해 "하네스(harness)"라는 말이 등장한다. 하네스는 LLM 자체가 아니라, LLM의 출력을 받아 도구를 실행하고 그 결과를 다시 모델에 넣어주는 반복 루프 전체를 감싸는 실행 환경을 가리킨다. 터미널에서 명령을 실행하고 파일을 읽고 쓰는 코딩 에이전트 도구들이 전형적인 하네스 사례다. 모델이 "두뇌"라면 하네스는 그 두뇌가 실제로 행동할 수 있게 해주는 몸통에 가깝다.

핵심 개념 & 동작 원리

워크플로우와 에이전트의 제어 흐름 차이를 그림으로 보면 명확하다.

[워크플로우]
입력 → (고정 분기) LLM 호출1 → 도구A 실행 → LLM 호출2 → 출력
        ※ 분기/순서는 코드에 하드코딩

[에이전트 + 하네스]
입력 → 하네스 루프 시작
       ┌─────────────────────────────┐
       │ LLM이 다음 행동 결정          │
       │   → 도구 호출 or 종료 판단    │
       │ 하네스가 도구 실행, 결과 반환 │
       └─────────────────────────────┘
       (LLM이 "끝났다"고 판단할 때까지 반복)
→ 출력

이 루프 안에서 모델이 참조하는 정보가 바로 Context다. Context는 한 번의 추론 호출에 실제로 들어가는 입력 전체, 즉 컨텍스트 윈도우 안의 토큰들을 말한다. 반면 Memory는 세션이 끝나도 사라지지 않도록 외부(파일, DB, 벡터 저장소 등)에 보관해두는 정보다. 둘의 관계는 단순하다. Memory는 저장소이고, Context는 그중 지금 이 순간 모델에게 실제로 보여주는 부분이다. 매 턴마다 Memory 전체를 Context에 밀어 넣을 수 없기 때문에, 무엇을 꺼내서 보여줄지 선택하는 로직이 별도로 필요하다.

도구 연동 쪽에서는 MCP(Model Context Protocol)와 A2A(Agent2Agent)가 구분된다. MCP는 LLM 애플리케이션이 외부 도구·데이터 소스에 접근하는 방식을 표준화한 클라이언트-서버 프로토콜이고, A2A는 서로 다른 에이전트끼리 작업을 위임하고 상태를 주고받는 방식을 표준화한 프로토콜이다. 기존 REST API는 호출하는 쪽이 엔드포인트와 스키마를 미리 알고 있다는 전제가 깔려 있는데, MCP·A2A는 LLM이 런타임에 "무엇을 호출할 수 있는지"를 스스로 발견하고 선택해야 한다는 전제에서 설계된 프로토콜이라는 점이 결정적인 차이다.

Trade-off 분석

구분	Latency	비용	복잡도	운영 부담
워크플로우	낮음, 호출 수 고정	예측 가능	설계 시점에 집중	낮음
에이전트	가변적, 반복 횟수 모델이 결정	상한 설계 필요	런타임 제어 로직 필요	높음, 모니터링 필수
MCP 연동	도구 호출 왕복만큼 증가	도구 목록이 Context 토큰 소모	서버 구현/인증 필요	중간
A2A 연동	에이전트 간 왕복 추가	위임 체인 길이에 비례	작업 상태 추적 필요	높음, 신뢰 경계 설계 필요

백엔드/AI 에이전트 시스템 적용 시 고려사항

실제로 적용할 때 걸리는 함정은 대체로 "경계를 명확히 정하지 않아서" 생긴다. 먼저 Context와 Memory를 섞어서 설계하면, 세션이 길어질수록 컨텍스트 윈도우가 차오르고 오래된 정보가 잘려나가는데 이게 Memory에 저장된 정보였는지 아닌지조차 구분이 안 되는 상황이 온다. Memory에서 Context로 무엇을 꺼낼지 결정하는 선택 로직을 처음부터 별도 컴포넌트로 분리해야 한다. 두 번째는 MCP 서버를 여러 개 붙일 때다. 연결된 도구 목록 전체가 매 호출마다 Context에 설명으로 들어가기 때문에, 서버 개수가 늘수록 정작 중요한 작업 지시가 들어갈 자리가 줄어든다. 세 번째는 에이전트 루프의 종료 조건이다. 하네스가 반복 횟수 상한이나 비용 상한을 강제하지 않으면 모델이 스스로 멈추지 못하는 경우가 실제로 발생한다. 마지막으로 A2A처럼 에이전트끼리 작업을 위임하는 구조에서는 상대 에이전트가 내 권한 범위를 넘어서는 행동을 요청할 수 있으므로, REST API를 설계할 때보다 더 엄격하게 신뢰 경계와 인증을 나눠야 한다.

---

개인 고찰 & 엔지니어링 관점의 시사점

팀 내에서 LLM 기반 애플리케이션을 논의할 때 흔히 발생하는 소통의 병목은 "서로 생각하는 에이전트의 정의와 범위가 다르다"는 점이다. 단순 조건문과 LLM API를 체이닝한 워크플로우를 보고 "완벽한 자율 에이전트"라고 부르거나, 반대로 예측 불가능성이 너무 높은 에이전트를 프로덕션 핵심 로직에 배치하려다 장애를 겪는 사례가 많다.

네이버 D2의 발표와 Anthropic/OpenAI의 스펙을 다각도로 분석하면서 얻은 엔지니어링적 결론은 다음과 같다.

• '에이전트'보다 '워크플로우'로 시작하라: 자율성을 가진 Full Agent는 디버깅과 예측 가능성 확보가 극도로 힘들다. 대부분의 실무 비즈니스 문제(80~90%)는 분기와 실행 순서가 명확히 제어되는 Deterministic Workflow에 도구 연동을 얹는 것만으로도 충분히 안정적인 결과물을 낸다.
• 하네스(Harness)의 역할 고도화: LLM 추론 능력만큼이나 중요한 것이 LLM을 감싸는 실행 환경인 하네스(Harness)의 안전장치다. 무한 루프 방지(Max Iterations), 토큰/비용 상한선, 에러 복구(Self-healing) 및 샌드박스 실행 환경이 하네스 단에서 견고하게 작성되어야만 프로덕션 배포가 가능해진다.
• Context와 Memory의 명확한 레이어 분리: Context Window는 한정된 'RAM'과 같고, Memory는 'HDD/Database'와 같다. RAG 기반 검색 로직이나 세션 매니저를 통해 Memory에서 Context로 올리는 정보의 양과 도구 스키마(Tool Definition)의 토큰 소모를 상시 모니터링해야 '정보 소실(Lost in the Middle)' 현상을 방지할 수 있다.

참고 자료

• D2 원문 — 에이전트, 개념부터 같이 정리해봐요
• Anthropic, Building Effective Agents (워크플로우 vs 에이전트 구분)
• Model Context Protocol 공식 소개 문서
• MCP 스펙 GitHub 저장소