AI 에이전트라는 말을 들으면 먼저 챗봇을 떠올리기 쉽습니다. 하지만 이 시리즈에서 말하는 AI 에이전트는 단순히 답변을 더 잘하는 챗봇이 아닙니다.
AI 에이전트는 사용자의 목표를 받아서 필요한 맥락을 찾고, 도구를 호출하고, 중간 상태를 보고, 결과를 검증하는 실행 시스템에 가깝습니다. 그래서 좋은 에이전트 설계는 모델 선택보다 먼저 목표, 도구, 맥락, 상태, 검증, 승인 흐름을 분리하는 데서 시작합니다.
이 글은 AI 에이전트 실전 설계 시리즈의 1편입니다. 앞으로 MCP, RAG, memory, workflow, observability, eval, security를 다루기 전에, 에이전트를 어떤 지도로 볼지 먼저 정리합니다. MCP 구성요소는 이전에 정리한 MCP tools resources prompts 차이 글과 함께 보면 좋습니다.
AI 에이전트는 챗봇보다 넓은 실행 흐름이다
챗봇은 대체로 사용자의 질문을 받고 답변을 생성합니다. 물론 최신 챗봇도 검색, 파일 읽기, 이미지 생성 같은 기능을 붙일 수 있습니다. 그래서 겉으로 보면 챗봇과 에이전트의 경계가 흐릿해 보입니다.
차이는 답변을 생성하느냐가 아니라, 다음 행동을 선택하고 실행 흐름을 이어가느냐에 있습니다.
LangChain 문서는 에이전트를 주어진 작업이 끝날 때까지 모델이 도구를 반복해서 호출하는 구조로 설명합니다. OpenAI Agents SDK 문서도 agent loop, tool invocation, handoffs, guardrails, sessions, tracing 같은 실행 요소를 함께 다룹니다.
즉, 에이전트는 모델 하나가 아닙니다. 모델 주변에 붙는 실행 장치까지 포함한 구조입니다.
챗봇, RAG 앱, 워크플로 자동화, 에이전트 비교
네 가지를 구분하면 훨씬 쉽습니다.
- 챗봇: 사용자의 질문에 답변을 생성한다
- RAG 앱: 문서를 찾아 답변의 근거로 넣는다
- 워크플로 자동화: 사람이 정한 순서대로 작업을 실행한다
- AI 에이전트: 목표를 보고 다음 행동과 도구 사용을 동적으로 선택한다
예를 들어 회의록을 보고 후속 작업을 정리해 달라는 요청을 생각해보겠습니다. 챗봇은 사용자가 회의록을 붙여 넣으면 요약해 줍니다. RAG 앱은 회의록 저장소에서 관련 문서를 찾아 요약합니다. 워크플로 자동화는 매일 오전 9시에 새 회의록을 찾아 정해진 형식으로 태스크를 만듭니다.
AI 에이전트는 조금 다릅니다. 먼저 회의록을 찾고, 참석자와 결정 사항을 확인하고, 빠진 정보가 있으면 추가 문서를 찾고, 태스크 관리 도구를 호출할지 판단하고, 실제 생성 전에는 사람 승인을 요청할 수 있습니다.
여기서 중요한 것은 에이전트가 항상 더 낫다는 뜻이 아닙니다. 경로가 미리 정해져 있고 예외가 적다면 워크플로 자동화가 더 안전하고 싸고 빠를 수 있습니다.
AI 에이전트를 구성요소로 나눠 보기
에이전트를 설계할 때는 아래 구성요소를 따로 봐야 합니다.
- 목표: 사용자가 무엇을 끝내고 싶은가
- 모델: 어떤 판단을 모델에게 맡길 것인가
- 맥락: 문서, 데이터, 이전 대화를 어떻게 넣을 것인가
- 도구: 검색, 파일, API, DB, 브라우저 중 무엇을 호출할 것인가
- 상태: 중간 결과와 장기 기억을 어디에 둘 것인가
- 검증: 결과가 맞는지 어떻게 확인할 것인가
- 승인: 위험한 실행 전에 사람이 어디서 개입할 것인가
이 구분이 없으면 에이전트는 금방 불안정해집니다. 도구 호출이 실패했는데 최종 답변만 남거나, 이전 대화의 잘못된 기억을 계속 가져오거나, 사용자가 승인하지 않은 쓰기 작업을 실행할 수 있습니다. 도메인 로직과 AI 호출을 어디서 나눌지는 LLM 서비스 경계 글에서도 다룬 적이 있습니다.
에이전트는 모델이 알아서 해주는 것이 아닙니다. 모델이 판단할 수 있는 범위와 판단하면 안 되는 범위를 나누는 설계입니다.
도구를 호출한다고 모두 에이전트는 아니다
많은 글이 tool calling을 에이전트의 핵심처럼 설명합니다. 맞는 말이지만 충분하지는 않습니다. 날씨 API를 한 번 호출해서 답하는 시스템은 tool calling을 쓰지만, 꼭 에이전트라고 부를 필요는 없습니다. 사용자의 요청이 단순하고 실행 경로가 거의 고정되어 있기 때문입니다.
반대로 코드 리뷰 에이전트를 생각해보면 이야기가 달라집니다.
- 변경 파일을 읽는다
- 테스트 결과를 확인한다
- 위험한 변경을 찾는다
- 필요하면 관련 문서를 검색한다
- 리뷰 코멘트를 작성한다
- 확신이 낮은 부분은 사람에게 표시한다
이 흐름에서는 모델이 한 번 답변하고 끝나지 않습니다. 도구 결과를 보고 다음 행동을 고르고, 중간 상태를 쌓고, 최종 산출물을 검증해야 합니다. 이런 구조가 에이전트에 더 가깝습니다.
AI 에이전트 설계에서 가장 먼저 정할 것
첫 번째 질문은 어떤 모델을 쓸까가 아닙니다. 먼저 아래 질문을 던지는 편이 좋습니다.
- 이 작업은 정말 경로가 매번 달라지는가?
- 모델이 직접 선택해야 할 도구는 무엇인가?
- 단순 조회 도구와 쓰기 도구를 분리했는가?
- 외부 시스템에 영향을 주는 작업은 승인 단계를 거치는가?
- 중간 결과를 나중에 디버깅할 수 있는가?
- 실패했을 때 다시 시도할 기준이 있는가?
- 결과 품질을 평가할 테스트셋이나 체크리스트가 있는가?
이 질문에 답하지 못한 상태에서 도구만 많이 붙이면, 에이전트는 유연해지는 것이 아니라 예측하기 어려운 자동화가 됩니다.
작은 예시: 블로그 초안 작성 에이전트
이 블로그 운영 흐름을 일반화해서 보면 좋은 예가 됩니다. 공개 발행까지 자동으로 맡기는 것이 아니라, draft와 publish를 분리하는 방식입니다.
- 목표: 승인된 주제로 WordPress draft를 만든다
- 맥락: 큐 항목, 시리즈 blueprint, 기존 관련 글을 읽는다
- 도구: 웹 검색, 관련 글 검색, 이미지 생성, WordPress draft 생성 도구를 사용한다
- 상태: factpack, article.md, article_package.json, preview URL을 남긴다
- 검증: package validator와 Yoast readiness를 확인한다
- 승인: publish는 사람이 명시적으로 승인할 때만 실행한다
이렇게 보면 에이전트는 자동 발행기가 아닙니다. 사람이 정한 경계 안에서 초안을 만들고, 검증 자료를 남기고, 공개 단계는 승인 뒤로 미루는 시스템입니다.
이 구조는 대부분의 업무 자동화에도 그대로 적용할 수 있습니다. 결제, 배포, 삭제, 고객 알림처럼 되돌리기 어려운 작업은 에이전트가 바로 실행하지 않게 해야 합니다. 특히 도구 호출 위험은 MCP 보안 글에서 더 자세히 이어볼 수 있습니다.
AI 에이전트가 필요한 경우와 필요 없는 경우
AI 에이전트가 잘 맞는 경우는 대체로 이런 작업입니다.
- 입력 형태가 매번 다르다
- 필요한 자료를 먼저 찾아야 한다
- 어떤 도구를 쓸지 상황에 따라 달라진다
- 중간 결과를 보고 다음 행동을 바꿔야 한다
- 결과 검증과 사람 승인이 필요하다
반대로 실행 순서가 항상 같고, 입력과 출력 형식이 정해져 있으며, 실패 조건이 명확하다면 굳이 에이전트까지 가지 않아도 됩니다. 빠르고 싸고 예측 가능한 처리가 더 중요할 수 있습니다.
에이전트는 자동화의 상위 버전이 아닙니다. 불확실성이 큰 작업에서 모델의 판단을 제한적으로 빌리는 방식입니다.
이 시리즈에서 사용할 AI 에이전트 기준
앞으로 이 시리즈에서는 AI 에이전트를 다음 기준으로 다룹니다.
AI 에이전트는 목표를 받아, 필요한 맥락을 모으고, 도구를 호출하고, 상태를 관리하고, 결과를 검증하며, 위험한 실행은 승인 흐름으로 통제하는 시스템입니다.
이 기준을 세워두면 다음 주제들이 자연스럽게 이어집니다. 2편에서는 Tool calling은 어디까지 맡겨야 안전할까를 다룹니다. 이어서 MCP, RAG, Memory, observability, eval, security로 확장하겠습니다.
첫 편에서 기억할 것은 하나입니다. AI 에이전트의 핵심은 자율성이 아니라 경계입니다. 무엇을 모델에게 맡기고, 무엇을 시스템이 고정하고, 무엇을 사람이 승인할지 정하는 것이 설계의 시작입니다.
