에이전트는 작동했지만, 유지보수 계획은 작동하지 않았습니다.

이해관계자들에게 깊은 인상을 남기는 가장 쉬운 방법 중 하나는 AI 에이전트가 복잡한 워크플로우 (workflow)를 완료하는 모습을 보여주는 것입니다.

하지만 그와 똑같은 워크플로우를 6개월 후에 유지하는 것은 가장 어려운 일 중 하나입니다.

이 두 가지는 서로 다른 도전 과제입니다.

저는 데모 (demonstration) 중에는 눈부시게 보였으나, 배포 직후 운영상의 골칫덩이가 되어버린 에이전트 시스템들을 검토해 왔습니다.

그 이유는 대개 모델 (model)의 품질 때문이 아닙니다.

바로 아키텍처 (architecture) 때문입니다.

데모 아키텍처의 함정

많은 AI 에이전트 프로젝트는 단순한 목표로 시작합니다.

모델을 연결합니다.

몇 가지 도구 (tools)를 추가합니다.

워크플로우를 자동화합니다.

첫 번째 버전은 잘 작동합니다.

그러면 요구사항들이 들어오기 시작합니다.

에이전트가 CRM 데이터에 접근해야 합니다.

그다음은 티켓팅 시스템 (ticketing systems)입니다.

그다음은 내부 문서입니다.

그다음은 결제 시스템입니다.

그다음은 승인 워크플로우입니다.

그다음은 보안 제어입니다.

깔끔한 아키텍처로 시작했던 것이 점점 늘어나는 통합 (integrations)의 집합체가 되어버립니다.

새로운 기능이 추가될 때마다 또 다른 의존성 (dependency)이 발생합니다.

복잡성은 좀처럼 한꺼번에 찾아오지 않습니다.

그렇기 때문에 팀들이 이를 알아차리지 못하고 실패하는 경우가 많습니다.

유지보수의 승수 효과

대부분의 팀은 구현 (implementation)에 드는 노력은 추산하지만,

유지보수 (maintenance)에 드는 노력을 추산하는 팀은 거의 없습니다.

에이전트에 추가되는 모든 도구는 다음과 같은 요소를 도입합니다:

• 인증 로직 (authentication logic)
• 에러 핸들링 (error handling)
• 권한 제어 (permission controls)
• 모니터링 요구사항 (monitoring requirements)
• API 버전 리스크 (API version risks)

아키텍처 다이어그램은 관리 가능한 수준으로 남아있을지 모릅니다.

하지만 운영 부담은 그렇지 않습니다.

에이전트를 유지보수하는 비용은 연결된 도구의 수보다 더 빠르게 증가합니다.

이 지점에서 많은 팀이 당혹감을 느낍니다.

리뷰 중에 제가 던지는 질문

"에이전트가 얼마나 많은 도구를 사용할 수 있습니까?"라고 묻는 대신,

저는 이렇게 묻습니다:

"팀이 현실적으로 얼마나 많은 도구를 유지보수할 수 있습니까?"

답변은 종종 매우 다릅니다.

기능은 신뢰할 수 있을 때에만 가치가 있습니다.

몇 주마다 깨지는 통합 (integration)은 진정한 기능이 아닙니다.

그것은 사용자 인터페이스 (user interface)를 가진 기술 부채 (technical debt)일 뿐입니다.

왜 더 단순한 아키텍처가 대개 승리하는가

엔지니어들은 종종 단순함의 장기적인 가치를 과소평가합니다.

다음과 같은 더 작은 시스템이:

• 더 적은 의존성

• 더 적은 권한 (permissions)

• 더 적은 워크플로 (workflows)

이러한 작은 시스템은 단순히 이해 가능한 상태를 유지한다는 이유만으로 시간이 지남에 따라 더 큰 시스템보다 더 나은 성능을 낼 수 있습니다.

이해 가능한 시스템은 문제 해결 (troubleshoot)이 더 쉽습니다.

보안을 유지하기가 더 쉽습니다.

진화시키기가 더 쉽습니다.

아키텍처는 단순히 기능 (capability)만을 최적화해서는 안 됩니다.

생존성 (survivability)을 최적화해야 합니다.

내가 계속해서 되새기는 한 가지 규칙

모든 새로운 통합 (integration)은 다음과 같은 간단한 질문에 답할 수 있어야 합니다:

"이것이 어떤 의미 있는 비즈니스 결과 (business outcome)를 이끌어내는가?"

만약 그 답이 불분명하다면, 해당 통합은 아마도 아키텍처에 포함되어서는 안 될 것입니다.

복잡성 (complexity)은 복리로 쌓이기 때문입니다.

그리고 기능 (features)과 달리, 복잡성은 좀처럼 스스로를 드러내지 않습니다.

그저 시스템이 유지보수하기 어려워질 때까지 기다릴 뿐입니다.

보통은 6개월 정도 지났을 때 말입니다.