“To-do 앱 만들어줘”에 두 가지 다른 반응
ChatGPT 일반 채팅 모드에서 “간단한 To-do 앱 만들어줘”라고 부탁하면, AI는 보통 코드를 텍스트로 출력한다. 그 코드를 복사해서 프로젝트에 넣고, 실행하고, 에러가 나면 다시 물어보는 일은 사용자가 한다.
반면 Claude의 Claude Code, ChatGPT의 Codex 같은 ‘코딩 에이전트 모드’에서는 AI가 파일을 읽고, 코드를 수정하고, 명령을 실행하고, 실패 결과를 보고 다시 고치는 루프까지 수행한다. 한 번의 지시로 코드 변경안, 실행 결과, 테스트 로그까지 만들어주고, 사용자는 이를 검토해 통합한다.
차이는 모델이 더 똑똑해서만이 아니라, 모델 주변에 ‘도구와 실행 루프’가 붙어 있기 때문이다. 앞의 채팅 모드는 ‘텍스트 생성기’로 동작한 거고, 뒤는 ‘AI 에이전트(Agent)’로 동작한 것이다.
이전 글들에서 프롬프트 설계, 외부 도구 연결, RAG를 다뤘다. 이것들을 모두 합쳐서 ‘AI가 스스로 판단하고 움직이는 구조’를 만든 것이 에이전트다. 이 글에서는 에이전트가 정확히 뭔지, 어떻게 만들어지는지, 언제 쓰면 좋은지를 정리한다.
에이전트가 뭔가: 판단 → 행동 → 관찰의 반복
‘한 줄 요약: 에이전트는 “목표를 주면 스스로 단계를 계획하고, 도구를 써서 실행하고, 결과를 보고 다음을 판단하는” AI다.’
에이전트의 기본 재료는 세 가지다.
| 재료 | 역할 |
|---|---|
| 두뇌 (LLM) | 다음 할 일을 판단 |
| 손발 (도구) | 파일 읽기, 명령 실행, 웹 검색 같은 실제 행동 |
| 반복 루프 | 결과를 보고 다음 행동을 정하는 흐름 |
동작은 이런 사이클을 돈다.
1. 사용자가 목표를 준다: "To-do 앱 만들어줘" 2. LLM이 다음 행동을 결정한다: "먼저 프로젝트 폴더를 만들자" 3. 도구를 써서 행동 실행: mkdir 명령 실행 4. 결과를 관찰: "폴더 생성 성공" 5. 다음 행동 결정: "이제 index.html 파일을 만들자" 6. ... 목표 달성까지 반복 ...
이 ‘관찰 → 판단 → 행동’ 루프가 에이전트의 핵심이다. 챗봇은 한 번 답하고 끝나지만, 에이전트는 결과를 보고 다음 행동을 이어간다.
이렇게만 있으면 ‘돌아가긴 하는’ 에이전트지만, 실제 서비스에서 쓰려면 세 가지가 더 필요하다. ‘지시문'(목표와 규칙을 정해준 문서), ‘상태 관리'(작업하면서 기억해야 할 중간 결과), 그리고 ‘가드레일'(권한 제한과 안전장치). 이 세 가지는 뒤에서 차례로 다룬다.
자동화 수준은 사다리로 올라간다
‘한 줄 요약: 에이전트는 LLM 앱의 “최종 진화형”이 아니다. AI에게 맡기는 자동화 수준의 한 단계일 뿐이다.’
LLM을 사용하는 애플리케이션은 ‘얼마나 AI에게 맡기느냐’의 정도가 다르다. 아래로 갈수록 AI의 자율성이 높아지고, 만드는 난이도와 위험도도 함께 올라간다.
1단계. AI에게 한 번 묻고 답받기 (단일 LLM 호출) (가장 단순) 2단계. AI가 자료 검색이나 도구를 쓰면서 답하기 (RAG/도구) 3단계. AI가 정해진 순서로 여러 단계를 거쳐 답하기 (Workflow) 4단계. AI가 다음 단계 자체를 판단하며 작업하기 (Single-Agent) 5단계. 여러 AI가 역할을 나눠 협업하기 (Multi-Agent) (가장 복잡)
많은 경우 1~2단계로도 충분하다. 업계 가이드(Anthropic, OpenAI)의 공통된 권고는 ‘단순한 것부터 시작하고, 꼭 필요할 때만 위로 올라가라’는 것이다. 에이전트가 더 최신이고 더 좋다는 뜻이 아니다. 한 번의 답변으로 되면 단일 호출이 낫고, 정해진 순서가 있으면 workflow가 낫고, 다음 행동을 미리 정하기 어려울 때에만 agent가 필요하다.
Workflow vs Agent: 같아 보이는데 다르다
‘한 줄 요약: Workflow는 “미리 정해진 순서로 실행”, Agent는 “매번 AI가 다음 할 일을 판단”. 얼마나 AI에게 맡기느냐의 차이다.’
에이전트라는 말이 유행하면서, 비슷해 보이는데 실제로는 다른 구조들이 같은 이름으로 불리는 경우가 있다. 가장 중요한 구분은 ‘Workflow(워크플로)’와 ‘Agent(에이전트)’의 차이다.
Workflow: 개발자가 미리 흐름을 정함
[1단계] 사용자 질문 받기 [2단계] LLM으로 카테고리 분류 [3단계] 분류에 따라 다른 함수 호출 [4단계] 결과를 LLM으로 요약 [5단계] 사용자에게 답변 전달
단계가 고정되어 있고, 각 단계에서 LLM이 쓰이더라도 ‘다음에 뭘 할지’는 개발자가 코드로 정해둔다. 예측 가능하고 디버깅하기 쉽다.
Agent: AI가 다음 할 일을 판단
[목표] "이 버그를 고쳐줘" → AI: "먼저 에러 로그를 봐야겠다" → 로그 읽기 → AI: "이 파일이 원인인 것 같다" → 파일 열기 → AI: "이 줄을 고쳐야 한다" → 코드 수정 → AI: "테스트를 돌려보자" → 실행 → AI: "다시 실패했다, 다른 부분도 봐야겠다" → 반복
각 단계를 AI가 판단한다. 유연하지만 예측 불가능하고, 잘못된 판단이 누적되면 엉뚱한 방향으로 간다.
| 구분 | Workflow | Agent |
|---|---|---|
| 제어 | 개발자가 흐름 설계 | LLM이 다음 단계 판단 |
| 예측 가능성 | 높음 | 낮음 |
| 자율성 | 낮음 | 높음 |
| 디버깅 | 쉬움 | 어려움 |
| 비용 | 낮은 편 | 높은 편 (반복 호출) |
| 적합한 작업 | 정형화된 반복 작업 | 방식이 미리 정해지지 않은 열린 작업 |
Workflow도 분기, 병렬 처리, 평가-개선 같은 패턴으로 꽤 유연할 수 있다. 정확히는 ‘유연성이 낮다’기보다 ‘AI에게 맡기는 자율성은 낮고, 대신 결과의 예측 가능성은 높다’가 더 맞는 설명이다.
2026년 시점의 업계 가이드의 공통된 권고: ‘실무의 기본값은 “에이전트부터 만들자”가 아니라 “단일 LLM 호출 → workflow → agent” 순서로 복잡도를 올리는 것.’ Agent는 더 멋있어 보이지만 비용·예측불가능성이 크다. 정말 AI의 자율 판단이 필요한 작업에서만 쓰는 것이 현실적이다.
에이전트의 기본형: Single-Agent부터 시작
‘한 줄 요약: 에이전트 하나가 도구들을 쓰며 목표를 달성하는 것이 기본. 복잡하게 여러 에이전트를 엮기 전에 이것부터 잘 만들어라.’
가장 단순한 에이전트 구조는 ‘Single-Agent(단일 에이전트)’다. 에이전트 한 명이 여러 도구를 쓰면서 목표를 달성한다.
[사용자 목표]
↓
┌─────────────────────────┐
│ Single Agent (LLM) │
│ ↑ ↓ │
│ 결과 행동 │
│ ↑ ↓ │
│ ┌────────────────┐ │
│ │ 도구 모음: │ │
│ │ - 파일 읽기 │ │
│ │ - 파일 쓰기 │ │
│ │ - 코드 실행 │ │
│ │ - 웹 검색 │ │
│ └────────────────┘ │
└─────────────────────────┘
↓
[최종 결과]
Claude Code, Cursor, Codex, Antigravity 같은 코딩 도구의 기본 작업 단위는 보통 이런 ‘하나의 에이전트가 파일/터미널/검색 도구를 쓰며 반복하는 루프’다. 다만 최신 제품들은 병렬 worktree, cloud agent, 여러 모델 동시 실행 같은 제품 레벨의 멀티 에이전트 기능도 얹고 있다. 핵심 동작 단위는 Single이고, 그 위에 제품 기능이 얹히는 구조다.
Single-Agent의 장점은 단순함이다. 디버깅하기 쉽고, 비용 예측이 가능하고, 흐름을 따라가기 쉽다. 처음부터 여러 에이전트를 나누는 것보다, 하나의 에이전트에 좋은 도구와 명확한 지시를 주는 편이 대개 더 단순하고 안정적이다. Anthropic과 OpenAI 모두 공식 가이드에서 같은 방향으로 권한다.
Multi-Agent: 정말 필요할 때만
‘한 줄 요약: 여러 AI 에이전트가 역할을 나눠 협업하는 구조. 복잡해 보이지만 Single-Agent로 해결 안 되는 경우에만 쓴다.’
작업이 복잡해지면 “여러 에이전트가 협업하면 더 좋지 않을까?”라는 생각이 든다. 이것이 ‘Multi-Agent(다중 에이전트)’ 구조다.
[사용자 목표]
↓
[Coordinator Agent (지휘자)]
↓
┌────────┬────────┬────────┐
│ │ │ │
[Research] [Writer] [Reviewer]
에이전트 에이전트 에이전트
↓ ↓ ↓
(각자 도구 세트)
예시: “도쿄 3박 4일 여행 계획 세워줘”
- Coordinator: 여행 계획 전체 조율
- Research Agent: 항공권, 호텔, 명소 검색
- Writer Agent: 일정표 작성
- Reviewer Agent: 계획 검토 및 충돌 체크
이론적으로는 깔끔하지만, 현실에서는 복잡도가 기하급수적으로 올라간다. 에이전트 간 통신 실패, 역할 중복, 무한 대기, 비용 폭증 같은 문제가 빠르게 생긴다.
그래서 업계 가이드는 일관된 메시지를 낸다. ‘Multi-Agent는 Single-Agent로 해결 안 되는 경우에만 쓰자.’ 여러 전문 영역이 명확히 분리되고, 병렬 처리 이득이 크고, 각 에이전트의 역할이 충분히 독립적일 때에만 권한다.
실무적으로는 처음부터 Multi-Agent를 짜지 말고, Single-Agent로 시작해서 명확한 한계가 드러났을 때 필요한 부분만 쪼개는 방식이 안전하다.
언제 에이전트를 쓰나
‘한 줄 요약: “단계가 미리 정해져 있지 않고”, “중간 결과를 보고 판단해야 하고”, “반복 시도가 필요한” 작업이면 에이전트가 적합하다.’
에이전트가 만능이 아니다. 다음 체크리스트로 판단하면 된다.
| 질문 | Yes면 에이전트 적합 |
|---|---|
| 단계를 미리 정해둘 수 없는가? | 예 (코딩, 리서치 등) |
| 중간 결과에 따라 방향이 바뀌는가? | 예 (에러 수정 등) |
| 실패해도 다시 시도할 여유가 있는가? | 예 |
| 결과 검증이 가능한가? (테스트, 린터 등) | 예 (권장) |
반대로 ‘매번 정해진 답이 나와야 하고, 예측 가능한 시간/비용이 중요한’ 작업은 에이전트보다 Workflow가 낫다.
에이전트가 잘 맞는 영역
- ‘코딩 작업’: 에러를 보며 고쳐가는 루프와 궁합이 좋음 (Claude Code, Cursor 등의 성공 이유)
- ‘심층 리서치’: 여러 소스를 검색하며 답을 조합
- ‘브라우저 자동화’: 웹 페이지를 보고 클릭/입력 반복
- ‘데이터 분석’: 쿼리 실행, 결과 확인, 다음 쿼리 설계
에이전트가 잘 안 맞는 영역
- ‘단순 FAQ/정책 안내 챗봇’: workflow/RAG가 더 안전 (다만 ‘주문 조회, 환불 판단, 티켓 생성’ 같은 액션이 필요한 고객 지원은 오히려 에이전트가 적합할 수 있다 – 단, 권한·승인·감사 로그 필수)
- ‘결정 분기가 정해진 업무’: workflow가 더 안전
- ‘실시간 저지연 서비스’: 에이전트는 반복 호출로 느릴 수 있음
- ‘규제가 엄격한 분야’: 예측불가능성이 리스크
실무에서 부딪히는 문제들
‘한 줄 요약: 무한 루프, 비용 폭증, 오류 전파, 평가 어려움이 에이전트의 4대 함정이다.’
1. 무한 루프
에이전트가 같은 행동을 반복하거나, 잘못된 방향으로 계속 파고들 수 있다. “이 코드 고쳐줘” → 고침 → 다른 에러 → 고침 → 또 다른 에러… 결국 50번 반복 후에도 해결 안 되는 경우가 나온다.
기본 방어:
- ‘최대 반복 횟수’ 제한 (10~20회 등)
- ‘진행 없음 감지’ (같은 에러 반복되면 중단)
- ‘사람 개입 지점’ 설정 (N번 시도 후에는 사용자에게 물어봄)
2. 비용 폭증
에이전트는 한 번의 사용자 요청 안에서 LLM 호출과 도구 호출을 여러 번 반복한다. 그래서 단일 챗봇 호출보다 비용과 지연시간이 크게 늘 수 있다. 특히 루프 제한이 없거나, 검색·코드 실행·대형 모델 호출이 반복되면 비용이 빠르게 커진다. 잘못 설계하면 사용자 한 명의 요청에 예상을 한참 넘는 금액이 결제될 수도 있다.
방어:
- 사용자별/요청별 토큰 상한 설정
- 간단한 작업은 작은 모델, 복잡한 판단만 큰 모델로 라우팅
- 중간 결과 캐싱
3. 오류 전파
에이전트가 초반에 잘못된 전제를 세우면 그 위에 계속 작업을 쌓아 올린다. 뒤늦게 발견되면 되돌리기 어렵다.
방어:
- 중간 체크포인트에서 사용자 확인
- 위험한 작업(파일 삭제, DB 변경 등)은 human-in-the-loop 필수
- 실행 로그를 통한 추적 가능성 확보
4. 평가가 어렵다
에이전트 시스템의 품질을 어떻게 측정할까? “답변이 맞나”보다 복잡하다. 중간 단계 판단, 도구 사용 적절성, 최종 결과까지 모두 봐야 한다.
이 평가 문제는 다음 글의 주제라, 여기선 언급만 하고 넘어간다.
자율성은 0 또는 1이 아니다: 권한 레벨 설계
‘한 줄 요약: 에이전트는 “완전 자동” vs “수동”이 아니다. 작업마다 자율성 수준을 다르게 설계하는 것이 프로덕션의 핵심이다.’
“에이전트 = 위험한 완전 자동화”는 흔한 오해다. 실제로는 어떤 도구는 자동 실행하게 하고, 어떤 도구는 승인 후 실행하게 하며, 어떤 작업은 사람에게 넘기게 만들 수 있다. 프로덕션 에이전트의 핵심은 ‘얼마나 똑똑한가’보다 ‘어디까지 맡길 것인가’를 설계하는 것이다.
권한 레벨을 나누는 예시:
| 레벨 | 예시 | 승인 필요도 |
|---|---|---|
| 읽기 | 파일 읽기, DB 조회, 웹 검색 | 낮음 (자동 가능) |
| 쓰기 | 파일 수정, 티켓 생성, PR 생성 | 중간 (승인 권장) |
| 외부 전송 | 이메일 발송, Slack 전송, 알림 | 높음 (승인 필수) |
| 파괴적 작업 | 파일 삭제, 결제, DB 변경 | 매우 높음 (여러 단계 확인) |
OpenAI와 Anthropic의 공식 가이드 모두 ‘가드레일(guardrails, 안전장치)’의 핵심으로 ‘권한 제한, 입력 검증, 도구 사용 제한, 사람이 중간에 개입하는 단계(human-in-the-loop)’를 함께 설명한다.
### 📦 [ 개발자를 위한 추가 메모 ]
일반 독자는 여기부터는 건너뛰어도 된다. 아래는 직접 에이전트를 만들려는 개발자용 보충이다.
‘프레임워크’: LangChain, LangGraph, LlamaIndex, OpenAI Agents SDK, Anthropic의 claude-agent-sdk 등. 처음이면 공급사 제공 SDK부터 시작하면 학습 곡선이 완만하다.
‘상태(State) 관리’: 에이전트 대화가 길어지면 컨텍스트가 빠르게 찬다. 중간 결과를 요약하거나 장기 메모리에 저장하는 전략이 필요하다. Claude Agent SDK의 ‘checkpointing'(작업 지점 저장)처럼 중간 상태를 기록하는 기능도 활용 가능.
‘도구(Tool) 설계’: 에이전트 성능의 상당 부분은 도구 설명(description)을 얼마나 잘 쓰느냐에 달려 있다. 도구 이름과 파라미터 설명을 프롬프트처럼 세심하게 설계해야 한다.
‘실행 추적(Observability)’: 에이전트가 ‘어떤 판단으로 어떤 도구를 호출했는지’ 추적 가능해야 디버깅과 비용 분석이 된다. OpenTelemetry 같은 표준 추적 도구와 연동되는 SDK가 많다.
‘하네스(Harness, 작업 환경 세트)’: 코딩 에이전트에서는 프롬프트만큼 ‘작업 환경’도 중요하다. 테스트, 린터, 타입체커, 문서, 코드 규칙, PR 템플릿, 작업 로그가 잘 준비되어 있을수록 에이전트가 스스로 고치고 검증할 수 있다. 이런 환경 전체를 ‘하네스’라고 부른다. OpenAI Codex 팀, Martin Fowler 등이 최근 강조하는 개념. 다음 글에서 이어서 다룬다.
‘AGENTS.md’: 코딩 에이전트를 위한 README 같은 파일. 설치 명령, 테스트 명령, 코드 스타일, 보안 주의사항을 적어둔다. 사람을 위한 README와 별개로 ‘에이전트가 일하는 방법’을 알려주는 설명서. 오픈소스 프로젝트에서 빠르게 확산 중이다.
마치며: 에이전트는 목적이 아니다
정리하면:
- 에이전트 = LLM + 도구 + 반복 루프 + 지시문 + 상태 + 가드레일. ‘관찰 → 판단 → 행동’을 반복하며 목표를 달성한다.
- LLM 앱은 ‘단일 호출 → RAG/도구 → Workflow → Single-Agent → Multi-Agent’라는 복잡도 사다리의 스펙트럼이다. 에이전트가 최종 진화형이 아니라, 복잡도 선택지 중 하나다.
- Workflow는 “개발자가 흐름을 정함”, Agent는 “LLM이 다음 단계를 판단함”. 가능하면 단순한 쪽부터 시작한다.
- Single-Agent가 기본, Multi-Agent는 Single로 안 되는 경우에만.
- 자율성은 0/1이 아니다. 작업별로 권한 레벨(읽기/쓰기/외부 전송/파괴적)을 나눠 설계하는 것이 프로덕션의 핵심이다.
- 실무 함정: 무한 루프, 비용 폭증, 오류 전파, 평가 어려움. 네 가지 모두 방어 장치가 필요하다.
에이전트는 멋있는 키워드지만 ‘목적’이 되면 안 된다. ‘이 문제를 에이전트로 풀어야 할까, 그냥 workflow로 풀어도 될까’를 먼저 묻는 것이 실무 판단이다.
다음 글에서는 이 에이전트를 ‘어떻게 잘 돌아가게 만들지’를 다룬다. 평가(Evals), 가드레일(Guardrails), 트레이스, 그리고 요즘 코딩 에이전트 진영에서 주목받는 ‘하네스(Harness)’까지. 에이전트를 실험용에서 프로덕션으로 올리는 데 필요한 것들이다.