안녕하세요, swimmingcode입니다. "에이전트"라는 말, 요즘 여기저기서 들으셨을 겁니다. 그런데 막상 무슨 뜻이냐고 물으면 사람마다 답이 다릅니다. Anthropic이 2024년 12월 19일 공개한 'Building effective agents' 문서는 이 용어를 정리하는 기준점 하나를 제시합니다

"그거 그냥 챗봇 아니야? 왜 갑자기 다 에이전트라고 부르지?"

답은 "이름만 바뀐 게 아니다"입니다.

이 레터에서 다루는 것:

워크플로와 에이전트, Anthropic은 어떻게 정의 하였는가
챗봇과 뭐가 다른가 — 루프로 움직이는 구조
MCP의 활용

챗봇에서 에이전트로 넘어가는 순간

지금까지 익숙한 AI 사용법은 한 번 물으면 한 번 답하는 구조였습니다. 다음 행동은 늘 사람이 다시 프롬프트를 입력해야 나왔습니다. "에이전트"라는 말은 이 구조가 달라졌다는 신호로 쓰입니다.

정의는 제각각

Anthropic도 이 혼란을 문서 첫머리에서 인정합니다. 어떤 고객은 에이전트를 "장시간 독립적으로 작동하는 완전 자율 시스템"으로 부르고, 어떤 고객은 "정해진 절차를 그대로 따르는 구현체"까지 에이전트라고 부릅니다. Anthropic은 이 전부를 '에이전틱 시스템(agentic system)'으로 묶은 뒤, 그 안에서 '워크플로'와 '에이전트'를 구조적 기준으로 나눕니다.

에이전트란 무엇인가 — Anthropic의 정의

워크플로와 에이전트

① 정의가 다릅니다

Anthropic 공식 문서는 이렇게 정의합니다.

"Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."

번역하면 이렇습니다 — 워크플로는 사람이 미리 짜놓은 경로대로 LLM과 도구가 움직이는 시스템이고, 에이전트는 LLM 스스로 다음에 뭘 할지, 어떤 도구를 쓸지 그때그때 판단하며 진행 방식 자체를 통제하는 시스템입니다. 챗봇에 익숙한 분들께는 후자가 낯설 겁니다 — 사람이 매번 다음 지시를 내리지 않아도 됩니다.

핵심은 이 한 문장입니다

② 움직이는 방식이 다릅니다

Anthropic은 에이전트의 실체를 이렇게 요약합니다.

"They are typically just LLMs using tools based on environmental feedback in a loop."

에이전트는 목표를 받으면(사람의 지시 또는 대화로 시작) 계획을 세우고 독립적으로 작업을 진행합니다. 이 과정에서 매 단계마다 "환경으로부터 받는 사실 확인" — 즉 도구를 호출한 결과나 코드 실행 결과 — 를 보고 지금까지의 진행 상황을 스스로 평가합니다. 막히거나 판단이 필요한 지점에서만 사람에게 되돌아오고, 작업이 끝나거나 정해둔 정지 조건(예: 최대 반복 횟수)에 닿으면 멈춥니다. 챗봇은 이 루프가 없습니다 — 한 번 답하고 끝입니다. 사람이 일할 때도 결과를 보고 다음에 뭘 할지 정하는 것과 같은 원리입니다 — 다만 에이전트는 이 확인과 판단을 스스로, 쉬지 않고 반복합니다.

이 루프, 실제로 어떻게 보이나

저희가 매일 쓰는 예 — MCP로 도구에 연결

③ 연결 방식이 다릅니다

"발행할 레터 초안을 완성해줘"라는 목표만 주면, Claude는 승인된 기획 문서를 스스로 찾아 읽고, 필요한 참고 문서를 확인하고, 초고를 쓴 뒤 규격에 맞는지 다시 점검합니다. 사람이 다음 단계를 일일이 지시하지 않아도 이 과정이 이어집니다. 이걸 가능하게 하는 연결 통로가 Model Context Protocol(MCP)입니다 — Anthropic이 공개한 표준으로, 저희는 이걸로 Claude를 여러 외부 도구·문서와 매일 연결해 씁니다.

여러 에이전트가 나눠 맡을 때

④ 협업 방식이 다릅니다

작업이 커지면 에이전트 하나가 아니라 여러 개가 나눠 맡기도 합니다. Anthropic은 이걸 '오케스트레이터-워커(orchestrator-workers)' 패턴이라고 부릅니다.

"In the orchestrator-workers workflow, a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results."

중앙의 LLM 하나가 하위 작업의 개수와 내용을 미리 정해두지 않고 그때그때 판단해서 나누고, 여러 워커 LLM에 맡긴 뒤 결과를 다시 모읍니다. 코드를 여러 파일에 걸쳐 고쳐야 하는 작업처럼, 하위 작업이 몇 개나 필요할지 미리 예측하기 어려운 일에 적합하다고 Anthropic은 설명합니다. 팀장 한 명이 업무를 쪼개 팀원들에게 나눠 맡기고, 다 끝나면 결과를 모아 정리하는 것과 비슷한 구조입니다.

우리가 쓰는 도구들도 마찬가지입니다

이 구분, 저희만 쓰는 이야기가 아닙니다. 지금 실제로 많이 쓰는 도구 4가지에도 같은 기준이 그대로 적용됩니다.

클로드 코드(Claude Code)와 클로드 앱(claude.ai), 완전히 둘로 나뉘는 건 아니지만 성격은 다릅니다. 클로드 코드는 에이전트에 가깝습니다 — 지금 저희가 쓰고 있는 이 도구처럼 터미널(컴퓨터 명령창)에서 직접 파일을 읽고 고치고, 프로그램을 실행하고, 여러 단계를 스스로 판단해서 목표를 끝까지 처리합니다. "이거 해줘" 하면 계획 세우고 실행까지 알아서 하는 구조예요. 클로드 앱(데스크톱·모바일 포함)은 기본적으로 챗봇 형태입니다 — 질문하면 답하는 대화창이 기본이지만, 웹 검색·파일 만들기·구글 캘린더 연결 같은 "도구 사용" 기능이 계속 붙으면서 "에이전트 기능이 일부 딸린 챗봇" 쪽으로 가는 중이에요. 클로드 코드는 행동(작업 실행) 중심, 클로드 앱은 대화 중심인데 앱 쪽도 점점 행동 기능이 늘고 있다 정도로 이해하시면 됩니다.

챗GPT도 같은 구조입니다. 기본 대화창에 "ChatGPT Work"라는 에이전트 기능이 붙어(2026-07-09 공식 출시) 여러 앱·파일에 걸쳐 행동하고 프로젝트를 몇 시간씩 붙잡아 완성된 결과물을 냅니다. 데스크톱 앱은 Chat(대화)·Work(에이전트)·Codex(코딩 에이전트) 3가지 모드로 나뉘어, 대화 모드와 에이전트 모드가 한 앱 안에 공존합니다.

제미나이도 마찬가지입니다. 기본 대화형 어시스턴트에 "Gemini Spark"라는 24시간 개인 에이전트 기능이 붙습니다(2026-05-19 공식 발표) — Gmail·Docs 같은 Workspace 도구와 연동되고, 기기를 덮거나 잠가도 백그라운드에서 작업이 계속됩니다. 이 Spark는 "Antigravity 하네스" 위에서 동작한다고 구글이 밝혔습니다.

그래서 언제 에이전트를 써야 하나

워크플로가 나을 때도 있습니다

Anthropic은 이 문서에서 에이전트를 무조건 권하지 않습니다. 오히려 반대로 씁니다.

"When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed."

가장 단순한 방법부터 찾고, 필요할 때만 복잡도를 올리라는 뜻입니다. 정해진 절차를 그대로 따라도 되는 일이면 워크플로가 더 예측 가능하고 일관적입니다. 반대로 하위 작업이 무엇이 될지 미리 정하기 어렵고, 그때그때 유연하게 판단해야 하는 일이면 에이전트 쪽이 낫습니다. 둘 중 뭐가 더 좋은 기술이냐의 문제가 아니라, 그 일의 성격에 맞는 쪽을 고르는 문제입니다.

복잡함은 필요할 때만 더합니다

Anthropic이 이 문서를 마무리하며 제시하는 세 원칙도 같은 방향입니다 — 에이전트 설계는 단순하게 유지하고(simplicity), 에이전트가 계획하는 과정을 사람이 보이게 하고(transparency), 에이전트가 쓰는 도구의 설명서를 공들여 쓰라는(documentation) 것입니다. 화려한 시스템을 만드는 게 목표가 아니라, 그 일에 맞는 시스템을 만드는 게 목표라는 뜻입니다.

그 뒤로 뭐가 달라졌나

⑤ 계속 진화합니다

워크플로와 에이전트를 가르는 기준, 도구 호출 결과를 보고 다음 행동을 정하는 루프 — 이 원리를 실제 서비스로 구현하면서 Anthropic은 한 가지를 더 알게 됐습니다. Anthropic이 공개한 'Scaling Managed Agents' 글에서 이렇게 밝힙니다.

"Harnesses encode assumptions that go stale as models improve."

번역하면, 에이전트를 감싸는 실행 틀("하네스")에는 그 시점 모델의 습성에 맞춘 가정이 담기는데, 모델이 발전하면 그 가정이 낡아버린다는 뜻입니다. 실제 사례를 하나 소개합니다.

"we found that Claude Sonnet 4.5 would wrap up tasks prematurely as it sensed its context limit approaching—a behavior sometimes called 'context anxiety.' We addressed this by adding context resets to the harness. But when we used the same harness on Claude Opus 4.5, we found that the behavior was gone. The resets had become dead weight."

Claude Sonnet 4.5는 작업 도중 컨텍스트(대화·작업 기억) 한도가 다가온다고 느끼면 일을 서둘러 마무리해버리는 행동을 보였습니다 — Anthropic은 이걸 "컨텍스트 불안"이라고 부릅니다. 그래서 하네스에 컨텍스트를 주기적으로 비워주는 장치를 추가해 대응했습니다. 그런데 같은 장치를 Claude Opus 4.5에 그대로 썼더니, 그 행동 자체가 사라져 있었습니다. 어제까지 필요했던 장치가 오늘은 쓸모없는 짐이 된 셈입니다.

그래서 Anthropic은 Managed Agents라는 서비스로 "브레인"(Claude+하네스)과 "손"(도구·실행 환경)과 "세션"(작업 기록)을 서로 분리했습니다. 컴퓨터의 운영체제가 다양한 하드웨어를 하나의 방식으로 다루게 해주는 것과 같은 원리로, 어느 한쪽이 바뀌어도 나머지는 흔들리지 않게 만든 구조입니다.

🔑 핵심

워크플로는 정해진 경로대로만 움직이고, 에이전트는 LLM 스스로 다음 행동을 정합니다 — Anthropic의 구조적 기준입니다. 에이전트는 목표를 받으면 도구 호출 결과 같은 환경 피드백을 보고 다음 행동을 스스로 정하는 루프로 움직이고, MCP 같은 연결 표준으로 외부 도구·문서에 닿으며, 작업이 커지면 오케스트레이터 하나가 여러 워커에 나눠 맡기기도 합니다. 다만 모든 일에 에이전트가 필요한 건 아니고, 이 구조 자체도 Managed Agents처럼 계속 진화하고 있습니다.

다음 발행에서 또 인사드리겠습니다. swimmingcode 드림.

AI를 실무에 어디까지, 어떻게 붙일지 정리하고 싶으시다면

1분 AI 활용 진단

양식을 만들 수 있는 가장 간편한 방법으로, Tally가 제작했습니다.

tally.so

다음 주 수요일에 다시 인사드릴게요. swimmingcode 드림

이 레터가 어떠셨는지 답장으로 알려주시면 다음 편에 반영하겠습니다.

AI 도구·트렌드

챗봇과 에이전트, 무엇이 다른가

초보자도 이해하는 완벽정리 5가지

스위밍코드 님에게 커피와 쪽지 보내기