Agent가 LLM과 다른 순간은 언제부터인가

이 글은 「AI 공부 지도 20부작」의 8편 (B1) 입니다.
앞 편: F5 — Embedding 이 의미를 숫자로 바꾸는 방식 · F6 — 학습이라는 게 뭘 학습한다는 건가
다음 편: B2 — 프롬프트가 모델 안에서 하는 일

0. 들어가기 전에

F 시리즈 여섯 편을 지나오신 분들이라면, 지금쯤 LLM 이 “단어를 벡터로 바꾸고, 벡터를 섞고, 다음 단어를 확률로 고르는 계산 덩어리” 라는 감각이 어느 정도 붙어 있을 거예요. P2 에서 저는 이걸 한 비유로 묶었습니다.

LLM 은 엔진이다. Agent 는 그 엔진이 들어간 자동차 한 대 전체다.

엔진은 연소 원리로 에너지를 뽑아내는 아주 정교한 부품이지만, 엔진만 길에 던져 놓으면 아무 데도 못 갑니다. 핸들이 없어서 방향을 못 틀고, 바퀴가 없어서 못 굴러가고, 연료 시스템이 없어서 연속으로 못 돌고, 계기판이 없어서 지금 어디를 달리는지도 모르죠. 엔진은 차가 되기 위한 한 부품일 뿐이에요.

Agent 도 똑같습니다. LLM 한 번 호출로 끝나는 건 엔진 한 번 돌린 거예요. 거기에 목표를 받는 창구, 지금 어디까지 했는지 보는 계기판, 밖에 작용하는 팔다리 (도구), 실패하면 다시 도는 루프, 결과를 보고 다음 행동을 바꾸는 적응 회로 를 전부 붙여야 “차 한 대” 가 됩니다. 이게 B1 에서 잡을 감각이에요.

요즘 뉴스에는 “agent” “에이전틱 AI” “AI employee” 같은 말이 거의 매일 나옵니다. 회장님이 어느 회사 기사에서 “AI agent 를 도입했다” 라는 문장을 보셨다고 쳐요. 그 회사에 실제로 뭐가 들어간 건지, 챗봇 하나를 좀 꾸민 건지 진짜 작업 시스템을 붙인 건지, 이 단어만 봐서는 알 수가 없어요. 그래서 이 글에서는 agent 를 부풀어 있는 단어에서 구조 있는 개념으로 끌어내리는 게 목적입니다.

이 글을 다 읽고 나면 다음 세 가지가 되실 거예요.

• 한 문장으로 “LLM 과 agent 의 차이는 이거다” 라고 답할 수 있음
• Claude Code · Cursor 가 왜 agent 이고 ChatGPT 는 왜 애매한지 설명할 수 있음
• 누가 “AI agent 솔루션을 팔겠다” 고 왔을 때, 그게 진짜 agent 인지 그냥 API wrapper 인지 5가지 질문으로 판별할 수 있음

시작할게요.

1. “에이전트” 라는 말이 자꾸 부풀려지는 이유

“agent” 라는 단어, 요즘 너무 많이 씁니다. 저도 기술 뉴스를 훑다 보면 하루에 수십 번 보는 것 같아요. “agentic retrieval“, “agentic workflow”, “AI agent employee”, “autonomous agent“, “agent-based AI” 같은 복합어까지 포함하면 거의 마케팅 유행어 수준이 됐어요.

유행어가 된 단어는 경계가 무너집니다. 지금 agent 라는 말이 그 단계예요. 원래는 기술적으로 꽤 구체적인 뜻을 가지고 있었는데, 마케팅 쪽에서 쓰기 시작하면서 “그냥 AI 가 들어간 뭔가” 라는 정도로 희미해졌어요.

어느 정도로 희미해졌냐면, 제가 관찰한 쓰임새만 정리해도 최소 네 가지 층위가 섞여 있습니다.

(1) 진짜 agent 를 말할 때. LLM 이 도구를 쓰고, 실패하면 다시 시도하고, 결과를 보고 다음 행동을 바꾸는 시스템. Claude Code 에서 “이 버그 고쳐” 라고 했을 때 돌아가는 게 이거예요. 가장 엄밀한 쓰임새.

(2) 챗봇에 살짝 기능을 얹은 걸 agent 라고 부를 때. “AI agent 가 당신의 질문에 답합니다” 같은 홍보 문구. 실제로는 retrieval 한 번 붙은 FAQ 봇인 경우가 많아요. 1회성 응답으로 끝나면 agent 가 아닌데, 단어는 이미 붙어 버렸어요.

(3) 자동화 파이프라인 한 토막을 agent 라고 부를 때. n8n · Zapier 같은 워크플로 도구에서 “LLM 노드” 를 하나 넣으면 그걸 “agent” 라고 부르는 경우가 있어요. 흐름 전체는 사람이 설계했는데, LLM 이 낀 노드만 따로 agent 로 불리는 거죠. 이건 좀 과장된 쓰임.

(4) SF 소설 같은 agent. “자율적으로 일하는 AI employee”, “인간 대신 출근하는 에이전트” 같은 말. 현실에 존재하는 시스템을 가리키는 게 아니라 미래에 그랬으면 좋겠다 는 비전에 가까워요. 현재 기준으로는 과장입니다.

이 네 층위가 한 단어 안에 섞여 있으니까, “우리 회사에 AI agent 를 도입했어요” 라는 문장 한 줄로는 뭐가 들어왔는지 전혀 감이 안 와요. 회장님이 경쟁사 기사를 읽다가 “어? 우리도 도입해야 하나?” 라는 생각이 드셔도, 실제로 도입할 대상이 뭐인지를 먼저 특정해야 거기서부터 판단이 시작돼요.

그래서 정리가 필요한 거예요. 이 글은 agent 의 가장 좁은 정의 를 기준으로 얘기합니다. (1) 번 층위, 즉 LLM 에 도구와 루프가 붙어서 스스로 여러 단계를 실행하는 시스템 만 agent 라고 부르겠습니다. 나머지 (2)(3)(4) 는 그 변형이거나 과장이라고 간주하겠어요.

이게 왜 중요하냐면, 이 좁은 정의가 있어야 agent 를 제대로 평가할 기준 이 생기거든요. 뒤에 나오는 실무자 체크리스트도 여기에 기반합니다.

2. LLM 한 번 호출은 답변기 · LLM 을 시스템 안에 끼우면 agent

가장 짧게 agent 와 LLM 의 경계를 긋는 문장을 하나 드릴게요.

LLM 한 번 호출은 답변기다. LLM 을 시스템 안에 끼워 넣으면 agent 가 된다.

이 한 문장에 거의 모든 핵심이 들어 있어요. 조금 풀어볼게요.

“LLM 한 번 호출” 은 ChatGPT 창에 질문을 한 번 쓰고 답이 오는 걸 말해요. API 로 따지면 messages.create 를 한 번 부르고 끝나는 거죠. 이건 답변기예요. 입력 → 모델 → 출력. 그걸로 끝.

“시스템 안에 끼워 넣는다” 는 말이 핵심이에요. 시스템이라는 게 뭐냐면, LLM 호출 앞뒤로 다른 코드가 있어서, LLM 이 낸 출력을 가지고 뭔가 더 하는 구조 예요. 예를 들면 이런 거.

• LLM 이 “search_web 함수를 불러야 할 것 같다” 라고 출력하면, 바깥 코드가 실제로 검색을 돌리고 결과를 다시 LLM 에 돌려준다.
• LLM 이 낸 답이 “이건 실패했다, 다시 해봐야겠다” 라는 신호이면, 바깥 코드가 LLM 을 한 번 더 부른다.
• LLM 이 “파일을 편집해야 한다” 라고 출력하면, 바깥 코드가 파일을 실제로 편집하고 편집 결과를 LLM 에 보여준다.

이 “바깥 코드가 낀다” 는 게 agent 의 시작점이에요. 바깥 코드가 없으면 LLM 은 그냥 답변기. 바깥 코드가 붙으면 agent.

비유로 한 번 더 가볼게요. LLM 은 아주 똑똑한 조언자 입니다. 조언자에게 “이 문서 요약해 줘” 라고 물으면 요약을 해줘요. 그런데 조언자는 자기 손으로 파일을 열지 못해요. 자기 손으로 검색을 돌리지 못해요. 자기 손으로 코드를 실행하지 못해요. 조언자는 말만 할 수 있어요.

Agent 는 조언자 옆에 실무 직원 이 붙은 구조예요. 직원이 “조언자가 시키는 대로” 파일을 열고, 검색을 돌리고, 코드를 실행하고, 결과를 다시 조언자에게 보여줍니다. 조언자는 결과를 보고 다음 지시를 내려요. 이 왕복이 agent 가 움직이는 방식이에요.

이 구도를 머리에 박아 두시면, 뒤에 나오는 5가지 층이 전부 “조언자와 직원 사이의 소통 규칙” 을 정하는 장치로 읽혀요.

3. Agent 를 agent 로 만드는 5가지 층

Agent 라는 시스템이 실제로 동작하려면 다섯 가지 층이 맞물려 있어야 해요. 하나씩 볼게요.

(1) 목표를 받는 층

Agent 는 사람한테서 “목표” 를 받습니다. “이 버그 고쳐”, “이 논문 요약해”, “이 데이터셋 분석해” 같은 한 문장이요.

이 한 문장이 중요해요. 일반 챗봇은 사용자의 “질문” 을 받아요. 질문은 바로 답하면 끝이에요. 근데 agent 는 “목표” 를 받아요. 목표는 답이 아니라 여러 단계를 거쳐야 닿는 도착점 이에요.

예를 들어 “이 버그 고쳐” 라는 목표 하나를 받으면, agent 는 이걸 자기가 속으로 쪼개요. “어떤 파일을 열어야 할까”, “로그를 먼저 봐야겠네”, “이 함수에 문제가 있는 것 같은데 확인해볼까”, “수정해보고 테스트 돌려봐야겠다”, 하는 식으로요. 사용자는 이 쪼개는 과정을 직접 지시하지 않아요. Agent 가 스스로 해요.

“한 줄의 목표를 여러 단계의 행동으로 번역할 수 있는가” 가 목표 수용 층의 핵심이에요. 이게 안 되면 사용자가 스텝 바이 스텝으로 다 지시해야 하고, 그 순간 agent 가 아니라 그냥 chatbot 이 됩니다.

(2) 상태를 보는 층

Agent 는 지금 자기가 어디까지 했는지 알아야 해요. 이게 “상태” 예요.

상태는 여러 가지로 구성돼요. 어떤 파일을 읽었는지, 어떤 명령을 돌렸는지, 결과가 뭐였는지, 지금 몇 번째 시도인지. 이 모든 게 agent 의 워크스페이스에 쌓여요.

F1 에서 얘기했던 “LLM 은 파라미터가 고정이고 기억이 없다” 는 말이 여기서 다시 살아나요. LLM 본체는 기억이 없어요. 이번 호출과 다음 호출이 원칙적으로는 단절돼 있어요. 그럼 agent 는 어떻게 “지금까지 뭘 했는지” 를 아느냐. 바깥에 상태를 쌓아 놓고 매번 LLM 에게 다시 보여주는 거예요.

이 바깥 상태가 없으면 agent 는 매 호출마다 처음부터 다시 생각해야 해요. “아까 내가 이 파일 읽었지” 를 까먹고, 똑같은 파일을 또 읽고, 또 읽고. 이게 왜 중요한지는 나중에 M3 · M6 에서 더 깊게 보겠지만, 지금 감각만 잡아도 충분해요.

계기판 비유로 돌아가면, 상태를 보는 층은 계기판 + 블랙박스 예요. 지금 속도·연료·엔진 온도가 다 보이고, 지난 10분 간 어디를 달렸는지도 기록돼 있어요. 이게 없으면 운전자 (LLM) 는 눈 감고 운전하는 거예요.

(3) 도구를 쓰는 층 (tool use)

여기가 agent 의 팔다리에요. LLM 본체는 텍스트만 낼 수 있어요. 그런데 현실에서 뭔가를 하려면 파일을 열고, 검색을 하고, API 를 부르고, 코드를 돌려야 해요. 이 물리적 행동을 LLM 이 직접 할 순 없으니까, “나 이 도구를 쓸게” 라고 LLM 이 출력하고 바깥 코드가 그 도구를 대신 실행하는 구조로 가요.

이게 tool use 또는 function calling 이라고 불리는 거예요. 뒤에 섹션 7에서 자세히 다루니까 여기서는 “팔다리 역할을 하는 층이 있다” 정도만 기억해 주세요.

(4) 한 번에 안 끝나면 다시 하는 층 (retry / loop)

현실에서 agent 가 한 번에 성공하는 일은 드물어요. 파일을 열었는데 없을 수도 있고, 명령을 돌렸는데 에러가 날 수도 있고, 테스트를 돌렸는데 새 실패가 발견될 수도 있어요.

그러면 어떻게 해야 할까요. 여기서 선택지가 갈려요.

답변기형 시스템 은 “실패했습니다” 라고 출력하고 끝나요. 사용자가 다시 지시해야 해요.

Agent 형 시스템 은 “실패했네, 왜 실패했는지 보자, 다른 접근으로 다시 해보자” 를 스스로 해요. 사용자가 끼어들 필요가 없어요.

이 “스스로 다시 도는” 구조가 loop 예요. Loop 가 없으면 agent 라고 부르기 어려워요. 한 번 돌고 끝나는 건 함수 호출이지 agent 가 아니거든요.

Loop 설계는 까다로워요. 너무 오래 돌면 돈이 많이 들고, 너무 짧게 끝나면 풀 수 있는 문제도 못 풀어요. 그래서 “몇 번까지 다시 시도할지”, “어떤 조건에서 포기할지”, “포기하면 사용자에게 뭐라고 보고할지” 같은 규칙들이 agent 설계의 핵심 파트예요. M3 · M6 에서 깊게 봅니다.

(5) 결과를 보고 다음 행동 바꾸는 층 (adaptation)

이게 agent 의 마지막 층, 제일 인간 같은 부분이에요.

Loop 가 “다시 하는 것” 이라면, adaptation 은 “다르게 하는 것” 이에요. 실패했을 때 똑같은 방식으로 다시 시도하면 또 실패해요. “아, 아까는 파일 경로가 틀렸구나, 이번엔 다른 경로로 가보자” 라고 접근 자체를 바꿔야 해요.

이 바꾸는 판단을 누가 할까요. LLM 이 해요. 왜? LLM 은 지금까지의 상태 (파일, 로그, 에러 메시지) 를 다 읽을 수 있고, 그 위에서 “다음엔 뭘 다르게 할까” 를 판단할 수 있는 유일한 부품이거든요. 바깥 코드는 일반적인 규칙만 쓸 수 있고, “이 상황에서는 이렇게 해” 라는 구체적 판단은 LLM 이 맡아요.

Adaptation 이 있어야 agent 가 새로운 상황 에 대응할 수 있어요. 기존 자동화 (Zapier · n8n 같은) 는 adaptation 이 없어요. 사람이 미리 짜놓은 규칙을 그대로 돌릴 뿐이에요. 예기치 않은 에러가 나오면 멈춰요. Agent 는 예기치 않은 상황에서도 스스로 다음 행동을 고를 수 있어요. 이게 기존 자동화와 agent 의 본격적인 분기점 이에요.

다섯 층을 한 그림으로

이 다섯 층이 다 맞물린 게 agent 예요. 한두 개가 빠지면 agent 가 아니에요. 예를 들어 tool use 만 있고 loop 가 없으면 “함수 호출하는 챗봇”. Loop 는 있는데 상태 추적이 엉성하면 “무한 루프에 빠지는 봇”. 다 붙어야 차 한 대가 됩니다.

4. “파일 읽고 검색하고 코드 돌리고 실패하면 다시 시도하는” — 이게 agent 의 진짜 모습

추상적인 얘기만 하면 감이 안 잡히니까 실제 장면 하나를 그려볼게요. 제가 Claude Code 에 어제 시켰던 작업을 예로 들게요.

“블로그 기사 발행 스크립트가 가끔 Polylang 언어 연결을 놓친다. 원인 찾아서 고쳐 줘.” 라는 한 문장을 던졌어요. 그러고 나서 제가 한 일은 없었어요. 커피 한 잔 내리고, 창 밖을 봤죠. 20분 뒤에 돌아와서 보니 Claude 가 이런 걸 하고 있었어요.

1. publish_gate.py 를 먼저 읽었어요. 발행 스크립트가 어떻게 구성돼 있는지 파악하려고요.
2. 그 안에서 Polylang 관련 함수를 찾아서 해당 모듈을 또 열었어요.
3. 테스트를 돌렸는데 지금 환경에서는 에러가 안 나왔어요. 그래서 최근 로그를 찾아서 실패했던 케이스를 뽑았어요.
4. 로그를 보고 “언어 설정 API 호출이 간헐적으로 타임아웃 된다” 는 패턴을 발견했어요.
5. 해결책으로 retry 로직을 넣고, 실패 시 wp-admin 링크를 안내하는 fallback 을 추가했어요.
6. 테스트를 직접 돌려보고 통과하는 걸 확인한 뒤 저에게 보고했어요.

제가 한 일은 딱 한 문장 던진 것 뿐이에요. 나머지 여섯 단계는 Claude 가 스스로 판단하고 실행했어요.

이게 agent 예요. 여기서 다섯 층을 다시 찾아볼까요.

• (1) 목표 수용: “원인 찾아서 고쳐 줘” 라는 한 문장을 받아서 “여러 단계의 행동” 으로 번역함
• (2) 상태 추적: 어떤 파일을 읽었는지, 어떤 테스트를 돌렸는지 계속 기억하고 있음
• (3) 도구 사용: 파일 읽기, 테스트 실행, 로그 검색, 코드 편집 같은 도구를 차례로 불렀음
• (4) 루프: 테스트가 한 번에 재현 안 되자 로그로 우회해서 다시 접근
• (5) 적응: “재현이 안 되면 과거 로그를 뒤지자” 라는 새 전략을 LLM 이 스스로 떠올림

이 장면이 agent 의 일상적인 모습이에요. 영화 같은 “자율 AI” 가 아니라 한 문장 받고 여러 단계 실행하고 결과 보고하는 직원 에 가까워요. 바로 그 수준이 agent 의 현실 사이즈예요.

그리고 이게 엄청 유용한 사이즈 예요. 제가 과거에 이런 버그 추적을 직접 했으면 30분~1시간은 걸렸을 거예요. Agent 가 그 시간을 “커피 한 잔 + 20분” 으로 줄여 준 거죠. 여기서 agent 의 실무 가치가 나와요.

5. 당신이 쓰는 Claude Code · Cursor · Codex 가 agent 인 이유

F 시리즈 읽으신 분들 중에 Claude Code 나 Cursor 를 이미 쓰시는 분들이 많을 거예요. “근데 이게 agent 인지는 명시적으로 못 들어 봤다” 라는 분들도 계실 텐데, 답을 드리면 네, 이 셋은 전부 agent 입니다. 그것도 꽤 정석적인 agent 구현체예요.

하나씩 5가지 층에 대입해 볼게요.

Claude Code

• 목표 수용: 터미널이나 에디터에 “이거 고쳐” 같은 자연어 명령 한 줄
• 상태 추적: 현재 작업 중인 프로젝트 폴더 전체를 context 로 읽을 수 있고, 대화 히스토리를 세션 동안 유지
• 도구 사용: Read, Edit, Write, Bash, Grep, Glob 같은 기본 도구 + MCP 로 확장되는 수십 개의 추가 도구
• 루프: 한 작업이 끝날 때까지 LLM 이 계속 돌면서 상태를 업데이트함. 사람이 중단시키기 전까지는 다음 스텝을 스스로 고름
• 적응: 에러가 나면 다른 접근을 시도하고, 파일이 없으면 다른 경로를 찾고, 테스트가 실패하면 코드를 다시 고침

다섯 층이 전부 있어요. 그것도 상당히 정교하게요.

Cursor

• 목표 수용: Composer 에 자연어 지시 또는 Cmd+K 로 인라인 편집 요청
• 상태 추적: 열려 있는 파일, 프로젝트 인덱스, 대화 히스토리
• 도구 사용: 파일 읽기·편집·생성, 터미널 실행, 웹 검색 (최근 버전)
• 루프: Agent 모드에서는 여러 단계 작업을 스스로 실행
• 적응: 편집 결과가 테스트에서 깨지면 수정, lint 에러가 나면 고침

Claude Code 와 거의 같은 구조예요. 차이는 주로 UI 표면 (VS Code fork 에 집어넣은 건지, 터미널에서 도는 건지) 이지 agent 본체의 원리는 비슷해요.

Codex (OpenAI 의 CLI 코딩 agent)

• 구조는 Claude Code 와 매우 유사해요. 터미널에서 자연어 지시를 받고, 도구를 쓰고, 루프로 돌고, 적응하죠. 세부 UX 가 다르지만 다섯 층이 다 있어요.

이 세 제품의 공통점을 한 단어로 요약하면 “코딩 agent” 예요. 개발자의 작업 환경에 LLM 을 깊이 박아 넣고, 개발자가 수작업으로 하던 “파일 읽고, 수정하고, 테스트하고, 실패하면 다시 해보는” 루프를 LLM 에 위임한 거예요.

이걸 실제로 써 보신 분들은 경험으로 아시겠지만, 그냥 ChatGPT 창에 코드 붙여 넣고 물어보는 것과는 체감이 완전히 다릅니다. 왜 다르냐면 agent 냐 답변기냐의 차이거든요.

6. ChatGPT 는 agent 인가 — 애매한 지점들

여기서 좀 까다로운 질문이 나와요. “그러면 ChatGPT 는 agent 인가?” 저는 애매하다 라고 답합니다. 완전히 agent 는 아니지만, 일부 agent 속성을 가진 하이브리드예요. 왜 그런지 층별로 봐볼게요.

• 목표 수용: ChatGPT 는 주로 “질문” 을 받아요. 한 문장 지시로 여러 단계 작업을 시키는 데 점점 익숙해지고 있지만, 기본 모드는 대화형 질의응답이에요.
• 상태 추적: 세션 안의 대화 히스토리는 유지돼요. Memory 기능 (장기 기억) 이 붙어서 사용자별 컨텍스트도 일부 쌓이고요. 하지만 “파일 시스템을 보는 상태” 같은 건 기본적으로 없어요. 붙일 수는 있지만 기본 UX 가 아니에요.
• 도구 사용: 있어요. 웹 검색, Python 실행, DALL-E 이미지 생성, 파일 분석 같은 도구들이 모드에 따라 자동으로 들어와요.
• 루프: 기본은 한 번에 답하고 끝. 사용자가 다시 지시해야 다음 턴이 돌아요. 물론 같은 턴 안에서 모델이 도구를 여러 번 부를 수는 있어요. 파이썬 돌리고, 결과 보고, 또 돌리고 하는 식으로요. 그래서 “한 턴 안의 미니 agent” 같은 구조는 있어요. 하지만 Claude Code 처럼 여러 턴에 걸쳐 자율 실행하는 agent 는 ChatGPT 의 기본 형태가 아니에요.
• 적응: 같은 턴 안에서 도구 호출이 실패하면 다른 접근을 시도하긴 해요. 근데 여러 턴에 걸친 장기 작업에서의 적응은 약해요.

정리하면 ChatGPT 는 “대화형 인터페이스 + 한 턴 안의 미니 agent” 구조예요. 본격 agent 는 아니에요. 사용자가 한 턴에 “전부” 맡기고 다음 턴까지 자동으로 흐르는 걸 기대하면 ChatGPT 는 그 기대에 맞추기 어려워요.

다만 이게 점점 변하고 있어요. OpenAI 가 Operator, GPTs, Agent Mode 같은 걸 붙이면서 agent 쪽으로 확장하고 있거든요. 그래서 “ChatGPT 는 agent 가 아니다” 라는 단정도 몇 달 뒤엔 틀릴 수 있어요. 현재 기준으로 말씀드리면 “애매한 하이브리드” 라는 게 제일 정확해요.

실무적으로는 이렇게 구분하시면 돼요. “한 턴 답변” 이면 ChatGPT. “여러 단계 작업 위임” 이면 Claude Code / Cursor 같은 전용 agent. 둘은 용도가 겹치는 부분도 있지만, 본질적으로는 다른 제품 카테고리예요.

7. Tool use — agent 의 팔다리

Agent 의 다섯 층 중 가장 실무에 직접 닿는 게 tool use (함수 호출) 예요. 여기 한 섹션 떼서 좀 자세히 볼게요.

왕복 구조

Tool use 는 LLM 과 바깥 세계 사이의 왕복 구조예요. 순서로 그리면 이렇습니다.

1. 사용자가 “이 날씨 어때?” 같은 걸 물어요.
2. LLM 이 “이건 내가 모르는 정보다, 도구가 필요하다” 라고 판단해요.
3. LLM 이 JSON 같은 구조화된 출력을 뱉어요. 예를 들면 {"function": "get_weather", "city": "Seoul"} 이런 식.
4. 바깥 코드 (agent harness) 가 그 JSON 을 받아서 실제로 get_weather 함수를 실행해요. 외부 API 를 때리거나, DB 를 조회하거나 하죠.
5. 함수 결과 (예: {"temp": 14, "weather": "흐림"}) 를 다시 LLM 에게 돌려줘요. “네가 부른 함수 결과야” 라는 맥락과 함께요.
6. LLM 이 그 결과를 읽고 “서울은 지금 14도, 흐린 날씨예요” 같은 자연어 답을 만들어요.

이 6단계가 한 왕복이에요. 필요하면 이 왕복이 여러 번 돌 수도 있어요. 예컨대 첫 도구 호출 결과가 부족하면 “아 이걸로는 부족하네, 다른 도구도 불러야겠다” 라고 해서 또 JSON 을 뱉는 식으로요.

왜 이 왕복이 핵심인가

이 왕복 구조가 없으면 LLM 은 “자기가 학습된 데이터” 안에서만 답할 수 있어요. 외부 세계에 손을 못 대요. 오늘 날씨, 최신 뉴스, 내 파일 시스템, 우리 회사 DB — 아무것도 모르죠.

Tool use 가 생기면 LLM 이 “필요한 정보가 있으면 도구를 불러서 가져오는” 방식으로 외부 세계와 연결돼요. 팔다리가 붙은 거예요.

2023년 OpenAI 가 function calling 을 API 에 정식으로 도입한 뒤로 agent 생태계가 폭발했어요. 그 전에는 LLM 출력을 정규표현식으로 파싱해서 도구를 부르는 불안정한 방식을 썼는데, 구조화된 function calling 이 표준이 되면서 agent 구축이 훨씬 안정적으로 바뀌었어요.

도구 정의가 agent 품질을 결정

어떤 도구를 몇 개 주는가 가 agent 품질의 큰 부분을 차지해요. 너무 적으면 agent 가 할 수 있는 게 없고, 너무 많으면 LLM 이 매번 “어떤 도구를 쓸지” 고르는 데 혼란스러워해요. 도구마다 이름 · 설명 · 입력 파라미터 를 잘 짜야 LLM 이 제대로 골라요.

예를 들면 search 라는 이름보다 search_code_in_repo(query: str, file_type: str) 같은 구체적인 이름이 좋아요. 도구 설명에 “언제 써야 하는지” 도 적어야 해요. “이 도구는 프로젝트 내 파일 검색에만 쓰세요. 웹 검색은 다른 도구를 쓰세요” 같은 식으로요.

이 “도구 정의” 단계가 agent 설계의 제일 지루하면서도 제일 중요한 부분이에요. 모델이 좋아도 도구 정의가 엉성하면 agent 가 엉뚱한 행동을 해요. M4 (Harness Engineering) 에서 더 자세히 다뤄요.

8. State — agent 의 기억

5가지 층 중 (2) 번이 상태였죠. 여기서 조금 더 파고들 게요.

F1 에서 “LLM 은 파라미터가 학습 완료 시점에 고정되고, 그 이후로는 변하지 않는다” 라고 했어요. 이게 왜 agent 설계에 중요하냐면, LLM 자체는 세션 간 기억이 없기 때문 이에요.

그래서 agent 의 “기억” 은 항상 LLM 바깥 에서 관리돼요. 종류별로 정리하면 이래요.

(a) 세션 안 컨텍스트 (short-term)

지금 대화 중인 메시지들, 방금 읽은 파일 내용, 방금 실행한 명령 결과. 이것들은 agent 가 매 LLM 호출 때마다 프롬프트에 통째로 붙여서 다시 보냄 니다. 100만 토큰 컨텍스트 같은 말이 나오는 이유가 여기예요. 컨텍스트 크면 세션 안 기억을 더 많이 유지할 수 있어요.

(b) 세션 밖 저장소 (long-term)

워크스페이스 파일, DB, 외부 메모리 시스템. 이건 매 호출 때 전부 붙이지 않고, 필요할 때 tool 로 꺼내서 읽어요. Agent 가 “이전에 쓴 메모를 읽어야겠다” 라고 판단하면 read_file 같은 도구를 불러서 가져오는 식이에요.

(c) 명시적 메모리 시스템

OpenAI 의 Memory 기능이나 Claude 의 Memory Tool 같은 거. 사용자별로 중요한 정보를 별도 저장소에 쌓아 놓고, 대화 초입에 자동으로 가져와요. “이 사용자는 TypeScript 로 코딩한다”, “이 사용자의 프로젝트는 Next.js 다” 같은 걸 기억하게 해주는 거죠.

왜 이 구분이 중요한가

Agent 를 설계하거나 평가할 때 “이 agent 는 어디까지 기억하는가” 가 핵심 질문이에요. 세션이 끝나면 다 잊어버리는 agent 인지, 다음 날 와도 이전 대화를 이어가는 agent 인지, 프로젝트 폴더를 계속 읽어가며 업데이트하는 agent 인지가 UX 와 품질을 크게 좌우해요.

Claude Code 를 예로 들면, 기본적으로 세션 히스토리는 메모리에 남고, CLAUDE.md 라는 파일에 장기 지침을 쓰게 돼 있어요. 다른 프로젝트에서 일할 때는 해당 프로젝트의 CLAUDE.md 를 자동으로 읽어요. 이렇게 “프로젝트별 장기 기억” 을 파일로 외주화한 설계가 Claude Code 의 큰 강점이에요.

기억을 LLM 바깥에 둔다는 발상이 왜 중요한지는 M 시리즈 (M3 · M6) 에서 제대로 파고들 거예요. 여기서는 감각만 잡아 주세요. “agent 의 기억은 LLM 안이 아니라 바깥에 있다”. 이 한 문장이면 충분해요.

9. Loop — agent 가 포기하지 않게 만드는 것

Loop 는 agent 의 지구력이에요. 한 번 실패했을 때 바로 죽는 시스템은 agent 가 아니에요. 사람처럼 “어 이게 안 되네, 다르게 해볼까” 를 반복할 수 있어야 해요.

Loop 의 기본 사이클

판단 → 도구 실행 → 결과 관찰 → (성공?) → 다음 단계 or 종료
                           ↘
                           (실패?) → 원인 분석 → 다른 접근 → 판단으로 복귀

이 사이클이 몇 번 돌 수 있느냐가 agent 의 지구력이에요. 과도한 loop 는 비용이 폭발하니까 대부분의 agent 는 최대 반복 횟수 같은 안전 장치를 둡니다. 예를 들어 “한 작업에 최대 50 스텝까지만 돌고 그 뒤로는 사람에게 보고” 같은 식이에요.

Loop 설계의 트레이드오프

Loop 를 너무 짧게 잡으면 풀 수 있는 문제도 못 풀어요. 복잡한 버그는 5~10스텝으론 안 끝나거든요.

Loop 를 너무 길게 잡으면 돈이 미친 듯이 들어요. LLM API 는 호출당 과금이고, 한 작업에 수백 번 호출하면 금방 수십 달러가 날아가요. 또 오래 돌수록 “엉뚱한 방향으로 탈선할 위험” 도 커져요.

그래서 agent 설계에서 “얼마나 오래 돌릴 것인가” 가 실무적으로 제일 골치 아픈 문제 중 하나예요. 작업 복잡도에 따라 적응적으로 조절하는 시스템도 있고, 사용자가 예산을 미리 설정하게 하는 시스템도 있어요.

Loop 중간 개입

좋은 agent 는 loop 를 완전 자율로 끝까지 돌리는 게 아니라 적절한 지점에서 사람에게 확인 받기도 해요. “이 작업을 진행하려면 프로덕션 DB 를 수정해야 하는데 진행할까요?” 같은 확인 다이얼로그예요.

Claude Code 는 기본적으로 위험한 명령 (파일 삭제, force push 등) 에서 확인을 받도록 설계돼 있어요. 이런 “확인 지점” 이 어디에 있느냐가 agent 의 안전성을 크게 결정해요. 완전 자율 agent 는 매력적으로 들리지만, 현실에선 “어디서 멈춰야 할지 아는 agent” 가 훨씬 쓸모 있어요.

10. Harness — agent 의 작업 환경 (다음 편 예고)

여기까지 읽으시면서 “그럼 agent 의 ‘바깥 코드’ 는 누가 만드는 건데?” 라는 의문이 드실 수 있어요. 정확한 질문이에요. 그 바깥 코드 전체를 harness 라고 불러요.

Harness 는 agent 가 올라타는 작업 환경 전체 예요. 도구 정의, 권한 규칙, 컨텍스트 관리, 에러 처리, 상태 저장 방식, 루프 제어, 메모리 시스템. LLM 을 둘러싸고 있는 인프라 전체가 harness 예요.

이 개념이 중요한 이유는 “좋은 agent = 좋은 모델” 이 아니라 “좋은 agent = 좋은 harness” 이기 때문이에요. 같은 모델 (예: Claude Sonnet) 을 쓰더라도 harness 설계에 따라 agent 의 성능이 몇 배씩 차이나요. Claude Code 가 잘 돌아가는 이유의 상당 부분이 harness 설계 때문이지, 모델이 유독 특별해서가 아니에요.

이 주제는 M4 (Harness Engineering) 편에서 제대로 파고들 거예요. 지금은 “agent 는 모델 + harness 로 구성된다” 정도 기억해 주세요.

11. “좋은 agent” 란 — 모델이 좋은 게 아니라 작업 환경이 좋은 것

P2 · P3 에서 비슷한 얘기를 했는데, agent 섹션에서 다시 한 번 강조하고 싶어요.

많은 분들이 agent 얘기를 할 때 “어느 모델이 가장 좋은 agent 인가” 를 물으세요. GPT-5 가 agent 인가, Claude 4.7 이 agent 인가, Gemini 가 agent 인가. 이 질문 자체가 조금 어긋나 있어요.

모델은 엔진이에요. 엔진은 agent 가 아니에요. 엔진 + 차대 + 바퀴 + 계기판 + 연료 시스템 = 차. Agent = 모델 + tools + state + loop + adaptation + harness.

그래서 “좋은 agent” 를 만들려면 모델을 바꿔도 한계가 있어요. 같은 모델 위에서 harness 를 잘 설계하면 훨씬 좋은 agent 가 나와요. 반대로 아무리 좋은 모델을 써도 harness 가 엉성하면 agent 가 엉뚱한 행동을 해요.

이 얘기는 실무에서 AI 도구를 평가할 때 엄청 중요해요. 같은 Claude 4.7 모델을 쓴다고 해서 Claude Code 와 “Claude 4.7 기반 A사 솔루션” 이 같은 품질이 아니거든요. Harness 설계 수준이 다를 수 있어요. 모델만 보지 마시고, “이 agent 는 어떤 도구를 쓰는가, 상태를 어떻게 관리하는가, 루프를 어떻게 통제하는가” 를 같이 보세요.

이 주제를 본격적으로 다루는 게 M 시리즈 (M1 ~ M6) 예요. 특히 M4 (Harness) 와 M5 (Context Management) 가 핵심이에요.

12. 실무자 체크리스트 — agent 도입 · 구매 평가 5가지

회장님이 어느 날 “우리 회사에 AI agent 를 도입하고 싶다” 는 제안을 받으셨다고 쳐요. 아니면 새 agent 스타트업 제품을 평가하셔야 한다고 쳐요. 이때 써먹을 수 있는 5가지 질문을 드립니다. 이 글에서 쌓은 5가지 층을 체크리스트로 바꾼 거예요.

질문 1: “이 agent 는 한 문장 목표를 받아서 여러 단계를 자율로 실행하는가?”

→ 이 질문에 “네” 라고 답 못 하면 그건 agent 가 아니라 그냥 챗봇이에요. “LLM 이 들어간 FAQ 시스템” 을 agent 라고 팔려는 경우가 있어요. 첫 번째 필터.

질문 2: “실패했을 때 다시 시도하는가, 아니면 바로 포기하는가?”

→ Loop 없는 시스템은 agent 가 아니에요. 시연할 때 일부러 실패하는 케이스를 넣어 달라고 하세요. 실패 후 어떻게 대응하는지 보세요.

질문 3: “지금까지 뭘 했는지 기억하고 있는가?”

→ 세션 중간에 “너 지금 뭐 했어?” 를 물어 보세요. 엉뚱한 답을 하면 상태 추적이 엉성한 거예요. 이런 agent 는 복잡한 작업을 맡기기 어려워요.

질문 4: “도구가 몇 개 있고, 각 도구가 어떤 권한을 가지고 있나?”

→ 도구 목록을 문서로 달라고 하세요. 3~5개 도구만으로 자랑하는 agent 는 쓸모가 제한적이에요. 반대로 도구 50개에 권한 관리가 엉성한 agent 는 위험해요. 균형이 중요해요.

질문 5: “이 agent 의 harness 는 누가 설계했나?”

→ 약간 사악한 질문이지만 정말 중요해요. Harness 설계 경험이 있는 팀이 만들었으면 제품 품질 차이가 확 나거든요. “그냥 OpenAI API 에 프롬프트 붙여서 만들었다” 수준이면 제품으로서의 방어력이 약해요. 몇 달 뒤에 비슷한 제품이 우후죽순 나와도 이길 이유가 없어요.

이 5가지를 던지면 그 agent 가 진짜 agent 인지, 단순 API wrapper 에 마케팅만 붙인 건지 대강 보입니다. 특히 질문 5 가 제일 날카로워요. 질문 1~4 는 답하기 쉬운데 질문 5 는 설계 경험이 없으면 답을 못 해요.

닫는 한 문장

LLM 은 엔진이고 agent 는 차 한 대다. 차를 차로 만드는 건 엔진 혼자가 아니라 목표 수용 · 상태 추적 · 도구 사용 · 루프 · 적응 다섯 층이 맞물려 돌아가는 구조 전체다. Claude Code · Cursor · Codex 는 이 다섯 층을 다 갖춘 정석 agent 이고, ChatGPT 는 일부 층만 가진 하이브리드다. 다음 편에서 이 차가 어떤 연료 (프롬프트) 를 먹고 어떻게 움직이는지 를 봅니다.

다음 읽기

• B2 — 프롬프트가 모델 안에서 하는 일 [준비 중]
• M4 — Harness Engineering 이 agent 품질을 만드는 방식 [준비 중]

시리즈 처음부터: F1 — LLM 이란 무엇인가 · F4 — Attention Is All You Need 해설 · F6 — 학습이라는 게 뭘 학습한다는 건가

자주 묻는 질문 (FAQ)

Q1. “agent” 와 “agentic AI” 는 다른 말인가요?

살짝 달라요. “agent” 는 시스템 하나 를 가리키는 명사예요. Claude Code 는 agent, Cursor 도 agent. “agentic” 은 형용사로 “agent 스러운” 이라는 뜻이에요. “agentic workflow” 는 agent 가 끼어든 워크플로, “agentic retrieval” 은 agent 스럽게 검색하는 방식. 실무에서는 “agentic” 이 좀 더 넓게 쓰이고, “agent” 가 더 엄밀한 정의를 가진다고 생각하시면 돼요. 둘 다 부풀려 쓰이는 중이라 주의는 필요해요.

Q2. AutoGPT · BabyAGI 같은 건 agent 인가요?

맞아요. 2023년에 잠깐 유행했던 그 친구들도 agent 입니다. 다섯 층이 다 있거든요. 목표 받고, 상태 쌓고, 도구 쓰고, 루프 돌고, 적응해요. 다만 당시에는 harness 설계가 미숙해서 루프가 자주 탈선하고 돈이 많이 들었어요. 지금의 Claude Code · Cursor 는 그 세대의 교훈을 받아서 훨씬 안정적으로 진화한 결과물이에요. AutoGPT 를 “초기 실험작”, Claude Code 를 “실용화된 후속작” 정도로 생각하셔도 되겠어요.

Q3. Agent 를 직접 만들고 싶은데 어디서 시작해야 할까요?

제일 빠른 길은 OpenAI Assistants API 나 Anthropic Claude + function calling 으로 간단한 agent 를 만들어 보는 거예요. 도구 2~3개 (파일 읽기, 웹 검색, 계산기) 만 붙이고 간단한 루프를 짜 보시면 감이 잡힙니다. 프레임워크로는 LangGraph 나 CrewAI 같은 게 있는데, 처음에는 프레임워크 없이 “JSON 주고받기 + while loop” 수준으로 직접 짜 보시는 걸 추천드려요. 그래야 agent 의 뼈대가 손에 잡혀요. 프레임워크는 이후에 복잡성이 늘어날 때 도입하세요. 이 주제는 M3 · M4 에서 코드 레벨로 다룰 예정이에요.

---

뉴스레터 구독 안내

매주 월요일, AI · LLM · 에이전트 관련 실무 정리를 한 통씩 보내드립니다. 이런 구조 해설을 차분히 쌓아가고 싶으시면 구독해 주세요.

뉴스레터 구독하기

---

시리즈 안내
– F1: LLM 이란 무엇인가
– F2: Transformer 는 무엇을 했나
– F3: 딥러닝이 그냥 큰 계산인 이유
– F4: Attention Is All You Need 해설
– F5: Embedding 이 의미를 숫자로 바꾸는 방식
– F6: 학습이라는 게 뭘 학습한다는 건가
– B1: Agent 가 LLM 과 다른 순간은 언제부터인가 (현재 글)
– B2: 프롬프트가 모델 안에서 하는 일 [다음]
– (이하 20편까지)

소스 리스트

• 태일러 지식백과사전 — AI 공부 지도 카테고리 (본 시리즈 20편 전체)
• AI 공부 지도 엔트리맵 — 전체 구조 + 3가지 독법
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 공식 docs
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown 영상 — 쉬운 설명 레퍼런스

---

著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.