웹 서비스에 들어가는 AI 에이전트는 모델과 프롬프트만 결합한 프로토타입 단계를 벗어나고 있다. 재사용 가능한 스킬, 파일 기반 메모리, MCP 인프라, 행동 평가, 실행 하네스에 대한 관심은 하나의 운영 과제로 모인다. 에이전트가 프로덕션에 들어간 뒤 수행하는 행동을 어떻게 통제할 것인가라는 문제다.

현재 자료만으로 특정 아키텍처가 표준으로 확정됐다고 보기는 어렵다. 다만 운영 로직을 불투명한 프롬프트 안에 두지 않고, 검토·테스트·버전 관리·교체가 가능한 구성 요소로 분리하려는 흐름은 분명하다.

프롬프트가 Control Plane이 될 수 없는 이유

프롬프트는 모델에 지시를 내리지만, 어떤 도구를 허용할지, 어떤 상태를 보존할지, 회귀를 어떻게 감지할지, 작업 실패 후 무엇을 할지까지 독립적으로 보장하지 않는다. 에이전트가 비공개 데이터를 읽거나 외부 서비스를 호출하고 웹 애플리케이션의 상태를 변경하기 시작하면, 이는 문장 작성이 아니라 시스템 설계 문제가 된다.

반복되는 에이전트 행동을 문서화해 평가 기준으로 삼는 접근은 이러한 변화를 잘 보여준다. 최종 답변만 채점하는 대신 기대 행동을 정의하면, 모델이나 도구, 컨텍스트가 바뀐 뒤 발생하는 행동 변화를 점검할 기반을 만들 수 있다.

실행 하네스는 모델 주위에 또 하나의 경계를 만든다. TrueForge는 LLM을 에이전트로 실행하는 오픈소스 하네스로 소개됐으며, 오케스트레이션이 별도의 엔지니어링 단위로 자리 잡는 흐름을 보여준다. 구현마다 차이는 있겠지만 이 계층은 반복 횟수 제한, 도구 정책, 오류 처리, 결과 기록을 적용하기에 적합한 위치다.

어떤 프로덕션 제어 계층이 형성되고 있나?

현재 논의를 네 가지 상호 보완적인 계층으로 정리할 수 있다. 각 계층은 에이전트가 작업을 수행할 때 나타나는 서로 다른 불확실성을 다룬다.

스킬 측면에서는 AI SDLC와 에이전트 스킬 구축 가이드가 스킬을 일회성 프롬프트가 아닌 개발 수명주기의 대상으로 다룬다. 에이전틱 스킬 감쇠에 관한 논의가 반복의 중요성을 강조한다는 점도 스킬을 지속적으로 관찰하고 개선해야 한다는 판단을 뒷받침한다.

메모리에서는 에이전트 메모리가 파이프라인이 아니라 파일 형식이어야 한다는 제안이 중요한 설계 가능성을 제시한다. 상태가 명시적인 산출물이 되면 커스텀 처리 체인 안에 메모리 로직을 감추는 방식보다 검사, 버전 관리, 이동이 쉬워질 수 있다. 다만 제공된 자료만으로 특정 형식이 최종 표준이 될 것이라고 단정할 수는 없다.

MCP가 해결하는 문제와 남겨 두는 문제는 무엇인가?

Model Context Protocol은 에이전트와 도구 또는 컨텍스트 제공자 사이의 인터페이스를 다룬다. 다섯 가지 중점 영역을 제시한 MCP 로드맵과 MCP 서버 구축·보안·서비스 운영을 다룬 실무 자료는 관심사가 단순 연결에서 인프라 운영으로 확장되고 있음을 보여준다.

그러나 프로토콜 자체가 완전한 거버넌스 시스템은 아니다. MCP 서버가 도구를 찾고 호출하는 방식을 표준화하더라도, 어떤 ID에 접근 권한을 줄지, 자격 증명을 어떻게 발급·폐기할지, 어떤 인자를 검증할지, 반환 가능한 데이터 범위와 감사 대상 작업을 어떻게 정할지는 배포팀의 책임으로 남는다.

웹 시스템에서는 이 구분이 특히 중요하다. 프로토콜은 상호운용성을 제공하고 Control Plane은 조직의 정책을 집행한다. 자동화를 위한 관리형 Control Plane 설계에서도 실행 연결성과 권한, 정책, 감독 기능을 함께 설계해야 한다는 유사한 원칙을 확인할 수 있다.

웹 개발팀은 어떤 순서로 검증해야 하나?

첫 실험부터 에이전트에 광범위한 프로덕션 권한을 주는 것은 피해야 한다. 결과를 검증할 수 있고 영향을 되돌릴 수 있는 좁은 워크플로를 고른 뒤, 자율성이나 권한을 확대하기 전에 제어 장치를 단계적으로 추가하는 편이 안전하다.

1. 작업 계약 작성: 입력, 출력, 완료 조건, 금지된 행동을 명시한다.
2. 스킬 분리: 지침과 컨텍스트 파일을 루트 프롬프트에서 분리하고 리뷰 가능한 버전 관리 산출물로 둔다.
3. 도구 범위 제한: 꼭 필요한 작업만 노출하고, 인프라가 지원한다면 읽기 전용 권한과 단기 자격 증명을 우선한다.
4. 실행 추적 기록: 비밀 정보를 노출하지 않으면서 도구 호출, 결과, 오류, 중요한 결정을 남긴다.
5. 행동 평가 구축: 정상 사례뿐 아니라 데이터 누락과 도구 장애에서 최종 결과와 행동 순서를 함께 테스트한다.

여러 역할이 협업하는 실행 구조를 검토한다면 Nova MCP가 AI를 제품 제작 팀으로 구성하는 방식도 참고할 수 있다. 다만 프로덕션 도입 여부는 조직 고유의 데이터 경계, 권한, 현실적인 장애 조건을 반영한 실험으로 판단해야 한다.

결론

• 프롬프트는 에이전트의 한 구성 요소이며, 프로덕션에는 런타임·권한·메모리·평가 제어가 필요하다.
• 스킬과 컨텍스트는 일회성 텍스트가 아니라 버전 관리되는 산출물로 다뤄야 한다.
• MCP는 연결을 표준화할 수 있지만 인증, 접근 정책, 감사를 대체하지 않는다.
• 프로덕션 작업 권한을 주기 전에 범위가 좁고 되돌릴 수 있는 워크플로부터 검증해야 한다.

관련 글

• Ventura React: 이 경량 컴포넌트 라이브러리는 새 프로젝트에도 적합할까?
• Nova MCP: Cursor와 Claude를 제품 제작 팀으로 바꾸는 방법
• Ansible Automation Orchestrator: 관리형 Control Plane 설계

참고 자료

• Agent Behavior - AI 에이전트의 반복 행동을 문서화해 평가 기준으로 삼는 표준
• Claude로 커머스 에이전트 구축하기
• 에이전틱 스킬 감쇠 : 숙련은 여전히 반복에서 나온다
• 에이전트 메모리는 파이프라인이 아니라 파일 형식이어야 한다
• TrueForge - LLM을 실제 에이전트로 실행하는 오픈소스 하네스
• Learn the AI SDLC – The Complete Guide to Building Agent Skills
• MCP in practice: building, securing, and serving Model Context Protocol servers
• 새로운 MCP 로드맵 - 앞으로 집중할 5가지 영역