모든 AI 에이전트 데모는 똑같은 방식으로 끝나는 것 같습니다.

"Slack에 연결할 수 있습니다."

"그리고 Jira."

"그리고 HubSpot."

"그리고 Google Drive."

"그리고 Salesforce."

"그리고..."

어느 순간부터 대화의 흐름이 비즈니스 문제를 해결하는 것에서 통합(integration)을 수집하는 것으로 바뀝니다.

저는 이것이 잘못된 방향이라고 생각합니다.

제가 본 가장 신뢰할 수 있는 AI 에이전트들은 모든 것에 연결된 것들이 아니었습니다.

그들은 더 적은 결정을 내리도록 강제된 것들이었습니다.

아무도 눈치채지 못하는 아키텍처(architecture)의 실수

사람들이 AI 에이전트에 대해 이야기할 때, 보통 기능(capabilities)에 집중합니다.

문서를 검색할 수 있는가?

이메일을 보낼 수 있는가?

CRM 레코드를 업데이트할 수 있는가?

티켓을 생성할 수 있는가?

이것들은 합리적인 질문들입니다.

하지만 아키텍처(architecture)는 에이전트가 무엇을 _할 수 있는지_에 대한 것만이 아닙니다.

에이전트가 무엇을 절대로 결정하도록 허용해서는 안 되는지를 정의하는 것에 관한 것입니다.

추가되는 모든 권한은 결정 공간(decision space)을 확장합니다.

새로운 통합(integration)이 추가될 때마다 또 다른 실패 모드(failure mode)가 도입됩니다.

이것이 복잡성이 기능 수보다 훨씬 빠르게 증가하는 이유입니다.

모델 품질보다 결정 경계(decision boundaries)가 더 중요합니다

지원 티켓(support tickets) 처리를 담당하는 에이전트를 상상해 보십시오.

두 가지 가능한 설계가 있습니다.

첫 번째는 에이전트에게 다음과 같은 권한을 부여합니다:

• 고객 기록 읽기
• 티켓 상태 업데이트
• 환불 처리
• 후속 이메일 발송
• 문제 에스컬레이션(escalate)

두 번째는 에이전트가 다음과 같은 일을 할 수 있도록 허용합니다:

• 티켓 요약
• 다음 조치 권장

그 외의 모든 것은 사람이 승인합니다.

두 시스템 모두 동일한 언어 모델(language model)을 사용합니다.

차이점은 아키텍처(architectural)에 있습니다.

두 번째 시스템은 무언가 잘못되었을 때 영향 범위(blast radius)가 훨씬 작습니다.

이는 대개 운영 환경(production environments)에서 더 나은 절충안(trade-off)이 됩니다.

모든 통합(integration)은 운영 부채를 생성합니다

커넥터(connector)를 하나 더 추가하는 것은 구현 단계에서는 쉬워 보입니다.

하지만 이를 유지 관리하는 것은 전혀 다른 이야기입니다.

이제 여러분은 다음 사항들을 고려해야 합니다:

• 인증 (authentication)
• 권한 매핑 (permission mapping)
• API 버전 변경
• 재시도 (retries)
• 모니터링 (monitoring)
• 감사 로깅 (audit logging)
• 실패 복구 (failure recovery)

이 중 어느 것도 제품 데모에는 나타나지 않습니다.

그 모든 것들은 6개월 후에나 나타납니다.

그것이 제가 통합(integration)을 얼마나 빨리 추가할 수 있는지로 측정하지 않는 이유입니다.

저는 통합이 얼마나 많은 운영 복잡성(operational complexity)을 초래하는지로 측정합니다.

컨텍스트는 워크플로(workflow)와 가까이 있어야 합니다

제가 계속해서 목격하는 문제 중 하나는 컨텍스트 파편화(context fragmentation)입니다.

고객과의 대화는 한 플랫폼에 존재합니다.

파일은 다른 어딘가에 있습니다.

프로젝트 논의는 또 다른 도구에 있습니다.

AI는 문제 자체를 해결하는 것보다 컨텍스트를 수집하는 데 더 많은 시간을 소비합니다.

여러 시스템 간에 데이터를 이동시키는 것은 거버넌스(governance) 복잡성 또한 증가시킵니다.

권한(permissions)을 추론하기가 더 어려워집니다.

감사 추적(audit trails)을 재구성하기가 더 어려워집니다.

이것이 통합 AI 워크스페이스(unified AI workspaces)가 점점 더 흥미로워지는 이유 중 하나입니다. 모든 SaaS 도구를 대체하기 때문이 아니라, 불필요한 컨텍스트 스위칭(context switching)을 줄여주기 때문입니다.

아키텍처 리뷰 중에 던져야 할 더 나은 질문

다음과 같이 묻는 대신:

"이 AI 에이전트는 얼마나 많은 도구에 연결될 수 있는가?"

저는 다음과 같이 묻는 것을 선호합니다:

"만약 이 통합 기능이 내일 사라진다면, 비즈니스가 여전히 작동할 것인가?"

만약 대답이 '예'라면, 그것은 아마 핵심 의존성(core dependency)이 아닐 것입니다.

만약 대답이 '아니오'라면, 그것은 아키텍처 관점에서 훨씬 더 많은 주의를 기울일 가치가 있습니다.

모든 통합이 동일한 수준의 신뢰를 가져야 하는 것은 아닙니다.

마지막 생각

가장 강력한 AI 아키텍처가 승리하는 이유는 그것들이 가장 정교하기 때문인 경우가 드뭅니다.

그것들이 승리하는 이유는 예측 가능하기(predictable) 때문입니다.

작은 결정 경계(decision boundaries).

명확한 권한(permissions).

관찰 가능한 동작(observable actions).

제어된 자동화(controlled automation).

AI 시스템이 내릴 수 있는 결정이 많아질수록, 그 결정들은 더욱 신중하게 설계되어야 합니다.

아키텍처는 AI에게 무제한의 능력을 부여하는 것에 관한 것이 아닙니다.

그것은 능력이 정확히 어디에서 멈춰야 하는지를 아는 것에 관한 것입니다.