프롬프트 엔지니어링에서 MCP 기술로: 도쿄 교통 에이전트를 재구축하며 배운 AI 아키텍처에 대하여

저의 dev.to 포스트 중 하나에 달린 최근 댓글에서 단순하지만 통찰력 있는 질문을 받았습니다:

MCP 이전에는 구체적으로 무엇이 문제였나요: 에이전트 간의 컨텍스트 손실(context loss)이었나요, 아니면 도구 호출(tool-call)의 불일치였나요?

처음에는 답변이 간단할 것이라고 생각했습니다.

하지만 도쿄 교통(Tokyo Transit) 프로젝트를 되돌아보며, 진짜 문제는 그 둘 중 어느 것도 아니었다는 것을 깨달았습니다.

이 프로젝트는 지난 1년 동안 세 번의 주요 반복(iteration)을 거쳤으며, 각 버전은 AI 에이전트(agent), 오케스트레이션(orchestration), 그리고 시스템 아키텍처(system architecture)에 대한 저의 이해가 진화하는 서로 다른 단계를 반영합니다.

돌이켜보면, 이 프로젝트는 AI 생태계 자체가 어떻게 진화해 왔는지를 보여주는 타임라인이 되었습니다.

버전 1: SmolAgents와 "거대 시스템 프롬프트" 시대

첫 번째 버전은 SmolAgents로 구축되었습니다.

당시 에이전트를 실험하던 많은 개발자들과 마찬가지로, 저 역시 충분히 상세한 시스템 프롬프트(system prompt)를 작성하기만 하면 에이전트가 일관되게 동작할 것이라고 믿었습니다.

프로젝트가 커짐에 따라 프롬프트도 함께 커졌습니다.

더 많은 지침(instructions).

더 많은 포맷팅 규칙(formatting rules).

더 많은 예외 사례(edge cases).

더 많은 예외 사항(exceptions).

결국, 시스템 프롬프트는 동작을 제어하는 주요 메커니즘이 되었습니다.

결과는 예측 가능했습니다. 에이전트는 때때로 작동했지만, 신뢰할 수 없었습니다.

가장 큰 문제는 에이전트 간의 컨텍스트 손실(context loss)이 아니었습니다.

도구 호출(tool-call) 실패도 아니었습니다.

진짜 문제는 프롬프트 정렬(prompt alignment)이었습니다.

저는 지침(instructions)을 통해 아키텍처를 관리하려고 시도하고 있었습니다.

버전 2: Google ADK와 상위 수준의 추상화

다음 실험에는 Google ADK를 사용했습니다.

첫 번째 버전과 비교했을 때, ADK는 에이전트 개발을 위해 더 높은 수준의, 더 깔끔하고 구조화된 프레임워크(framework)를 제공했습니다.

많은 오케스트레이션(orchestration) 관련 사항들이 추상화되었습니다.

덕분에 개발 속도가 빨라졌고, 제가 수동으로 관리하던 복잡성의 일부가 줄어들었습니다.

하지만 이는 저에게 중요한 교훈을 주었습니다:

프레임워크가 개발을 단순화할 수는 있지만, 아키텍처 문제를 자동으로 해결해주지는 않는다는 점입니다.

여전히 책임을 정의하고, 동작을 관리하며, 에이전트 워크플로우 (Agent workflows)를 구조화할 수 있는 명확한 방법이 필요했습니다.

버전 3: MCP 및 기술 기반 설계 (Skill-Based Design)

현재 버전은 MCP Python SDK와 기술 기반 설계 (Skill-based design)를 함께 사용합니다.

이 시점에 이르러서야 프로젝트가 마침내 유지보수 가능하다는 느낌이 들기 시작했습니다.

점점 커지는 시스템 프롬프트 (System prompt)에 더 많은 로직을 밀어 넣는 대신, 기능을 명확하게 정의된 책임을 가진 도구 (Tools)와 기술 (Skills)로 분리할 수 있었습니다.

MCP가 마법 같은 것은 아니었습니다.

MCP가 갑자기 에이전트를 더 똑똑하게 만들어준 것도 아니었습니다.

MCP가 제공한 것은 구조 (Structure)였습니다.

기술 (Skills)은 행동 지침 (Behavioral instructions)을 위한 전용 공간을 제공했습니다.

MCP는 도구 (Tools)를 위한 일관된 인터페이스를 제공했습니다.

이들이 결합되어 시스템을 더 쉽게 추론하고, 테스트하고, 개선할 수 있게 만들었습니다.

그렇다면 MCP 이전에는 실제로 무엇이 문제였을까?

돌이켜보면, 가장 큰 문제는 컨텍스트 손실 (Context loss)이나 도구 호출 (Tool-call)의 불일치가 아니었습니다.

그것은 바로 아키텍처 드리프트 (Architectural drift)였습니다.

에이전트가 잘못된 동작을 할 때마다, 저의 해결책은 대개 시스템 프롬프트에 또 다른 지침을 추가하는 것이었습니다.

시간이 흐를수록 프롬프트는 유지보수하기 어렵고 추론하기 힘들어졌습니다.

복잡성을 더 많이 추가할수록 동작의 예측 가능성은 낮아졌습니다.

지나고 보니, 저는 아키텍처 문제를 프롬프트 엔지니어링 (Prompt engineering)으로 해결하려 했던 것이었습니다.

마치며

도쿄 교통 프로젝트 (The Tokyo Transit project)는 여전히 활발히 개발 중입니다.

수정해야 할 버그도 있고, 개선해야 할 점도 많으며, 아직 배울 것이 산더미처럼 남아 있습니다.

하지만 가장 가치 있는 결과물은 교통 도구 그 자체는 아니었습니다.

그것은 저의 접근 방식이 시간이 흐름에 따라 어떻게 변했는지를 확인하는 것이었습니다:

• 거대한 시스템 프롬프트 (Large system prompts)에서
• 더 높은 수준의 에이전트 프레임워크 (Higher-level agent frameworks)로
• 그리고 MCP 및 기술 기반 아키텍처 (Skill-based architecture)로

이 프로젝트는 AI 에이전트가 단순한 실험에서 벗어나, 시간이 지남에 따라 구조화되고 유지보수되며 개선될 수 있는 시스템으로 진화하는 과정 속에서 저 자신의 학습 여정을 기록한 결과물이 되었습니다.

만약 여러분이 에이전트 (Agents), MCP, 또는 AI 프레임워크 (AI frameworks)를 활용해 시스템을 구축해 오셨다면, 한 가지 궁금한 점이 있습니다. 여러분의 시스템 설계 방식을 변화시킨 가장 큰 교훈은 무엇이었나요? 아래 댓글을 통해 여러분의 경험을 자유롭게 공유해 주세요.