에이전트를 다 만들고 나면, 그 다음엔 뭘 하나요?

진짜 재밌는 건 에이전트가 한 번 돌아간 다음부터임. 프로덕션은 사실상 노가다지: 재시도, 큐 안전하게 관리하기, 무슨 일이 일어나는지 모니터링하기, 승인 절차 밟기, 그리고 미완성된 문제들 해결하기. 모델은 보통 그중 일부일 뿐임.

localhost에서 프로덕션으로 넘어가는 단계가 대부분의 에이전트 데모가 더 이상 인상적이지 않게 되는 지점임.

나한테 중요한 건 "어떤 프레임워크 썼냐"가 아니라 "7단계에서 실행 실패했을 때 무슨 일이 일어났는지 설명할 수 있냐"는 거임.

만약 지속되는 실행 상태, 프롬프트/도구 버전, 재실행 가능한 추적, 부작용에 대한 멱등성, 그리고 돌이킬 수 없는 작업 전 사람의 승인이 없다면, 그건 그냥 호스팅만 좀 더 나은 데모일 뿐임.

에이전트가 한 번 작동하는 건 멋지지. 근데 에이전트가 실패했을 때 그걸 검사할 수 있어야 진짜지...

난 아주 단순하게 유지하고 있고 내 스택은 이거임:

• 에이전트 빌드용으로 LangGraph (트레이스 확인이랑 에이전트 동작 방식을 쉽게 파악하고 싶어서 사용함)
• 호스팅은 간단하게 Render 서버나 Supabase Edge Function 사용
• 모니터링은 전체 트레이스를 보고 문제 생기면 알림 오게 직접 만들었음

기술 현장 서비스용 프로덕션 에이전트를 운영하면서 얻은 인사이트를 여기 공유함: https://x.com/redouane_cc/status/2084621579841839206

도움 되길 바람!

여기서 설명한 스택들은 인디/스타트업 배포용으로는 탄탄함. 하지만 엔터프라이즈 환경에 에이전트를 배포하게 되면 상황이 꽤 달라지는데, 그 격차를 짚고 넘어갈 필요가 있음.

엔터프라이즈 환경에서는 필수 요구사항이 바뀜. zhonglin이 언급한 것 외에도 보통 다음이 필요함:

에이전트에 대한 역할 기반 접근 제어 -- 모든 사용자가 모든 데이터 소스에 대해 모든 에이전트를 실행할 수 있어서는 안 됨. 이건 애플리케이션 코드가 아니라 플랫폼 수준에서 강제되어야 함.

모델 라우팅 레이어 sepa …

아마 이 부분이 가장 무시되는 부분일 겁니다. 에이전트를 만드는 건 쉬운 데모 단계일 뿐이고, 프로덕션에서 신뢰성을 유지하는 것이 진짜 엔지니어링의 시작이죠.

상태 관리, 추적, 재시도, 그리고 인간의 개입(fallback)이 어떤 프레임워크를 선택했느냐보다 보통 더 중요합니다.