먼저 미리 말씀드릴 것이 있습니다: 지난주에 데모를 선보였던 그 AI 에이전트는 실제 사용자와 접촉했을 때 살아남을 수 있는 모델이 아닐 가능성이 높습니다.

이는 여러분의 구현 방식을 비난하는 것이 아닙니다. 이는 우리가 AI 에이전트 프로젝트 전반에서 계속해서 목격하고 있는 패턴입니다.

데모는 잘 작동합니다. 이해관계자들은 열광합니다. 하지만 프로덕션(Production) 단계에 들어서면 그 과정에서 취했던 모든 아키텍처적 지름길들이 드러나게 됩니다.

• 문제를 완전히 이해하기도 전에 프레임워크(Framework)를 선택했습니다.
• 메모리 레이어(Memory layer)가 복잡해 보인다는 이유로 건너뛰었습니다.
• 에이전트가 예측 불가능하게 행동하기 시작하자 나중에야 오케스트레이션(Orchestration)을 덧붙였습니다.

이 가이드는 2025년에 AI 에이전트를 구축할 때 실제로 중요한 아키텍처 결정 사항에 초점을 맞춥니다. 이 글은 노트북 데모가 아닌, 프로덕션 시스템을 출시하는 팀의 관점에서 작성되었습니다.

첫 번째: 무엇이 실제로 무언가를 AI 에이전트로 만드는가?

_AI 에이전트(AI agent)_라는 용어는 느슨하게 사용되곤 하므로, 명확하게 정의해 보겠습니다.

AI 에이전트는 단순히 시스템 프롬프트(System prompt)가 더 긴 챗봇이 아닙니다.

AI 에이전트는 언어 모델(Language model)이 다음과 같은 과정을 수행하는 시스템입니다:

• 목표에 대해 추론(Reasoning)함
• 행동을 선택함
• 외부 도구(External tools)를 사용함
• 결과를 관찰함
• 다음에 무엇을 할지 결정함

...이 모든 과정이 단일 응답이 아닌 연속적인 루프(Loop) 내에서 이루어집니다.

언어 모델은 추론을 담당합니다.

그 외의 모든 것—메모리(Memory), 오케스트레이션(Orchestration), 도구(Tools), 권한(Permissions), 평가(Evaluation), 재시도(Retries), 그리고 에러 핸들링(Error handling)—은 여러분의 책임입니다.

이러한 구분이 중요한 이유는 대부분의 프로덕션 실패가 모델의 실패가 아니기 때문입니다.

그것은 바로 **아키텍처의 실패(Architecture failures)**입니다.

1단계: 코드를 작성하기 전에 범위를 정의하라

이 단계는 개발자들이 서두르는 단계이며...

...거의 항상 나중에 후회하게 되는 단계입니다.

다음과 같이 묻지 마십시오:

"내 에이전트가 무엇을 해야 하는가?"

대신 다음과 같이 물으십시오:

"에이전트가 정확히 어떤 결정을 내려야 하며, 언제 작업을 인간에게 넘겨야 하는가?"

코드 한 줄을 쓰기 전에, 에이전트의 결정 프로세스를 쉬운 영어(Plain English)로 문서화하십시오.

만약 비기술적인 사람이 워크플로(Workflow)를 따라갈 수 없다면...

...여러분의 시스템 프롬프트 또한 따라가지 못할 가능성이 높습니다.

간단한 테스트

**"에이전트(Agent)\

당신이 작성한 지침만으로 신입 사원이 업무를 완수할 것이라고 믿을 수 있습니까?

만약 그렇지 않다면...

여러분의 범위(scope)가 충분히 명확하지 않은 것입니다.

예시 (Example)

❌ 너무 광범위함 (Too broad)

모든 고객 지원 요청을 처리하십시오.

✅ 구체적이고 테스트 가능함 (Specific and testable)

요청을 분류하고, 지식 베이스 (knowledge base)를 검색하며, 답변 초안을 작성하십시오. 신뢰도가 80% 미만으로 떨어질 때마다 사람에게 에스컬레이션 (escalate) 하십시오.

두 번째 버전은 구축, 측정 및 개선이 가능한 형태입니다.

첫 번째 버전은 단순히 환각 (hallucination)을 요구하는 것과 같습니다.

2단계: 적절한 아키텍처 패턴 선택하기

대부분의 프로덕션 에이전트 (production agents)는 세 가지 패턴 중 하나에 해당합니다.

ReAct (Reasoning + Acting, 추론 + 행동)

에이전트는 다음 루프를 따릅니다:

추론 (Reason) → 행동 (Act) → 관찰 (Observe) → 반복 (Repeat)

이는 대부분의 단일 목적 에이전트에게 가장 좋은 시작점입니다.

이 패턴의 한계는 추론 체인 (reasoning chains)이 길어지고 모델이 이전의 결정 사항을 놓치기 시작할 때 나타납니다.

Plan-and-Execute (계획 및 실행)

한 번에 한 단계씩 추론하는 대신, 모델은 먼저 전체 실행 계획을 생성합니다.

별도의 실행 레이어 (execution layer)가 각 단계를 수행합니다.

장점:

• 더 쉬운 디버깅 (debugging)
• 더 예측 가능한 실행
• 에이전트 계획에 대한 명확한 가시성

트레이드오프 (Trade-off):

실행이 시작되기 전 계획 단계에 더 많은 시간이 소요됩니다.

Multi-Agent Architecture (멀티 에이전트 아키텍처)

오케스트레이터 (orchestrator)가 여러 개의 특화된 에이전트들을 조정합니다.

각 에이전트는 하나의 책임에 집중합니다.

예를 들어:

• 운동 코치 (Workout Coach)
• 영양 코치 (Nutrition Coach)
• 일정 관리 에이전트 (Scheduling Agent)
• 리서치 에이전트 (Research Agent)

이것이 우리가 Raeda AI 피트니스 코칭 플랫폼을 개발하면서 따랐던 아키텍처입니다.

조정 레이어 (coordination layer)가 특화된 운동 및 영양 에이전트들을 관리합니다.

각 에이전트는 독립적으로 테스트할 수 있어, 디버깅 복잡성을 획기적으로 줄여줍니다.

권장 사항

ReAct로 시작하십시오.

아키텍처 다이어그램이 더 깔끔해 보인다는 이유 때문이 아니라, 단일 에이전트가 진정으로 병목 현상 (bottleneck)이 될 때만 멀티 에이전트 아키텍처로 넘어가십시오.

3단계: 도구를 만들기 전에 메모리 설계하기

메모리 (Memory)는 아마도 AI 에이전트 아키텍처에서 가장 간과되는 부분일 것입니다.

또한 이는 수많은 미묘한 운영 환경(production)에서의 실패를 야기하는 원인이기도 합니다.

1. 인-컨텍스트 메모리 (In-Context Memory)

이것은 단순히 현재의 프롬프트 창 (prompt window)을 의미합니다.

빠릅니다.

단순합니다.

하지만 제한적입니다.

창이 가득 차게 되면...

모델은 무언가를 잊어버렸다고 당신에게 알려주지 않습니다.

그저 단순히 이야기를 지어내기 시작할 뿐입니다.

2. 외부 메모리 (External Memory)

외부 메모리는 다음과 같은 벡터 데이터베이스 (vector database) 내에 정보를 저장합니다:

• Pinecone
• Weaviate
• Qdrant

모든 것을 프롬프트에 쑤셔 넣는 대신, 에이전트는 의미론적 검색 (semantic search)을 사용하여 가장 관련성이 높은 정보만을 검색(retrieve)합니다.

이는 확장성 (scalability)을 극적으로 향상시킵니다.

3. 에피소드 메모리 (Episodic Memory)

이것을 장기 대화 메모리라고 생각하세요.

모든 상호작용을 저장하는 대신...

요약본을 저장하세요.

이를 통해 다음과 같은 응답이 가능해집니다:

"지난번에 귀하의 배포 파이프라인 (deployment pipeline)에 대해 논의했었는데요..."

수천 개의 이전 메시지를 불러오지 않고도 말이죠.

경험 법칙 (Rule of thumb)

첫 번째 도구를 작성하기 전에 이 세 가지 메모리 계층을 모두 설계하세요.

기존 에이전트에 메모리를 사후에 끼워 넣는 것은 처음부터 올바르게 설계하는 것보다 훨씬 더 어렵습니다.

4단계: 개발자가 아닌 모델을 위한 도구 정의 작성하기

도구 설명은 종종 API 문서처럼 취급되곤 합니다.

그것은 실수입니다.

기억하세요:

언어 모델 (language model)이 이 정의들을 읽습니다.

부실한 도구 설명은 다음과 같은 결과를 초래합니다:

• 잘못된 도구 선택
• 환각된 파라미터 (hallucinated parameters)
• 워크플로우 (workflow) 실패

모든 도구에는 다음이 포함되어야 합니다:

✅ 서술적인 이름

search_knowledge_base

대신에

kb_query_v2

✅ 다음을 설명하는 설명 (description):

• 언제 사용해야 하는지
• 왜 사용해야 하는지
• 기대되는 출력 (expected output)

✅ 엄격한 입력 스키마 (input schemas)

가능한 한 모호한 선택적 파라미터 (optional parameters)를 피하세요.

도구 세트를 작게 유지하세요.

저희의 경험에 따르면:

잘 정의된 6개의 도구를 가진 에이전트가 느슨하게 정의된 15개의 도구를 가진 에이전트보다 일관되게 더 나은 성능을 보입니다.

도구의 복잡성이 증가할수록...

선택 정확도는 감소합니다.

5단계: 운영 환경에 적합한 스택 선택하기

오케스트레이션 (Orchestration)

• LangGraph → 멀티 에이전트 시스템 (Multi-agent systems)
• LangChain → 더 단순한 워크플로우 (Simpler workflows)
• Raw SDKs → 경량 에이전트 (Lightweight agents)

LangGraph의 그래프 기반 실행 모델 (graph-based execution model)은 디버깅과 상태 관리 (state management)를 현저히 쉽게 만듭니다.

LLM

2025년의 강력한 프로덕션 선택지는 다음과 같습니다:

• GPT-4o
• Claude Sonnet 4

두 모델 모두 다단계 추론 (multi-step reasoning)과 신뢰할 수 있는 도구 사용 (tool usage) 측면에서 뛰어난 성능을 보입니다.

벡터 데이터베이스 (Vector Database)

대중적인 프로덕션 선택지:

• Pinecone
• Weaviate

셀프 호스팅 (self-hosting)이 필요하신가요?

Qdrant를 선택하세요.

클라우드 인프라 (Cloud Infrastructure)

Docker를 사용하여 에이전트를 컨테이너화 (Containerize) 하세요.

다음 환경에 배포하세요:

• AWS ECS Fargate
• Google Cloud Run

가장 중요한 점은:

AI 에이전트를 독립적인 서비스로 유지하는 것입니다.

에이전트 로직을 애플리케이션 백엔드 (application backend) 내부에 묻어두지 마세요.

독립적인 서비스가 확장 (scale), 업데이트, 그리고 롤백 (roll back)하기에 훨씬 쉽습니다.

단계 6: 출시 전 평가 세트 (Evaluation Set) 구축하기

이것은 거의 모든 사람이 건너뛰는 단계입니다.

그리고 나중에 후회하게 됩니다.

사용자를 온보딩 (onboarding)하기 전에...

평가 세트를 만드세요.

다음 사항을 목표로 하세요:

• 50~100개의 대표적인 작업 (tasks)
• 검증된 예상 출력값 (expected outputs)

모든 주요 변경 사항 이후에는 다음을 측정하세요:

• 전체 정확도 (Overall accuracy)
• 도구 호출 정확성 (Tool-call correctness)
• 실패율 (Failure rate)
• 작업 유형별 성능 (Performance by task type)

정교한 ML 파이프라인 (ML pipeline)이 필요하지는 않습니다.

스프레드시트만으로도 충분합니다.

중요한 것은 추측하는 것이 아니라, 진행 상황을 측정하는 것입니다.

결국 마주하게 될 실패 모드 (Failure Modes)

프롬프트 드리프트 (Prompt Drift)

시스템 프롬프트 (System prompts)는 수십 번의 수정을 거치며 진화합니다.

결국...

그것이 실제로 어떤 동작을 유도하는지 아무도 기억하지 못하게 됩니다.

프롬프트를 소스 코드 (source code)처럼 취급하세요.

• 버전 관리 (Version control)
• 풀 리퀘스트 (Pull requests)
• 리뷰 (Reviews)

무한 도구 루프 (Infinite Tool Loops)

에이전트가 다른 답변을 기대하며 동일한 도구를 계속해서 호출하는 현상입니다.

항상 다음 사항을 강제하세요:

• 최대 반복 횟수 (Maximum iterations)
• 타임아웃 제한 (Timeout limits)
• 탈출 조건 (Escape conditions)

컨텍스트 오버플로 (Context Overflow)

대화가 길어짐에 따라...

이전 정보가 사라집니다.

모델은 당신에게 경고를 주지 않을 것입니다.

요약 (summarization)과 컨텍스트 프루닝 (context pruning)을 조기에 구현하세요.

환각된 파라미터 (Hallucinated Parameters)

도구 스키마 (tool schema)가 충분히 명시적이지 않기 때문에 모델이 값을 지어내는 현상입니다.

해결책은 더 나은 프롬프팅 (prompting)이 아닙니다.

더 나은 스키마 (schema) 설계입니다.

마치며

AI 에이전트가 인상적인 데모를 보여주게 만드는 것은 어렵지 않습니다.

하지만 신뢰할 수 있게 작동하고...

확장 가능하며 (at scale)...

예측 불가능한 엣지 케이스 (edge cases)를 처리하는 에이전트를 만드는 것은...

엔지니어링 과제입니다.

그리고 그 과제는 최신 모델을 선택하는 것보다 **아키텍처 (architecture)**를 통해 훨씬 더 많이 해결됩니다.

만약 AI 기반의 SaaS 제품을 계획 중이며 여러분의 아키텍처에 대한 제2의 의견이 필요하다면, MicrocosmWorks 팀은

여러분의 접근 방식을 검토하고 개발이 시작되기 전에 실질적인 기술 로드맵을 공유할 준비가 되어 있습니다.

여러분의 의견은 어떠신가요?

여러분의 AI 에이전트 프로젝트에서 가장 큰 도전 과제는 무엇이었나요?

• 메모리 (Memory) 설계?
• 도구 (Tool) 신뢰성?
• 멀티 에이전트 오케스트레이션 (Multi-agent orchestration)?
• 평가 (Evaluation)?
• 그 외 다른 것?

댓글로 여러분의 경험을 공유해 주세요. 여러분과 실제 엔지니어링 과제에 대해 논의하고 싶습니다.