AI 에이전트 도입이 파일럿에서 멈추는 이유는 대개 ‘더 똑똑한 모델이 없어서’가 아니다. 현장에서 실제로 막히는 건 두 가지다: 신뢰(보안·감사)와 관측가능성(비용·성능 트래킹). 이 두 축이 서지 않으면, PoC는 데모로 끝나고 프로덕션은 리스크로 보인다. 결국 확장(Expansion)은 기능이 아니라 “통제 가능한 운영”에서 열린다.
dev.to의 OpenClaw 관측가능성 글은 이 지점을 정면으로 찌른다. “에이전트가 정말 통제되고 있나?”라는 질문을 누가 호출했는지, 얼마가 들었는지, 어떤 고위험 툴을 실행했는지, 사후에 추적·감사 가능한지로 분해한다(‘Is Your OpenClaw Truly Under Control?’, ‘How to Monitor Your AI Agent’s Performance and Costs’). 비결은 거창한 게 아니다. 세션 로그로 행위를 재구성하고, OTEL 메트릭/트레이스로 지연과 상태를 붙이고, 알림까지 연결해 행동 감사→운영 관측→실시간 대응의 폐루프를 만든다.
맥락을 더하면, 에이전트는 전통적인 백엔드보다 공격면이 넓다. 동일 입력에도 툴 호출 시퀀스가 달라지는 비결정성 때문에, 코드리뷰만으로는 “가능한 모든 행위 경로”를 감사할 수 없다. 그래서 런타임 가드레일(툴 정책, 루프 디텍터)이 ‘성벽’이라면, 관측가능성은 ‘망루’다. 성벽을 믿게 만드는 건 망루가 기록하는 증거(로그)와 지표(메트릭)다.
이 프레임이 금융권에서는 더 직접적으로 작동한다. 한국산업은행은 DART 등 외부 공개 데이터를 정제·가공해 재무분석 AI 에이전트를 사내 서비스로 시작했고, 망분리·엄격한 보안 요건을 준수하며 “기밀 유출 가능성을 최소화”하는 설계를 강조했다(열린뉴스통신). 여기서 메시지는 명확하다. 금융/B2B는 ‘정확도’만큼이나 데이터 경로의 투명성, 사용 이력의 감사 가능성, 비용 통제가 도입의 전제조건이다. 즉, 관측가능성은 기술 옵션이 아니라 구매 조건(Procurement requirement)이다.
성장 관점의 시사점은 더 날카롭다. 관측가능성은 단순 운영 도구가 아니라 CAC를 낮추는 세일즈 자산이다. 첫째, 보안·감사 로그(누가/무엇을/왜/결과)를 제품 기능처럼 제시하면 보안팀·준법감시·리스크 조직의 반대 비용을 줄여 세일즈 사이클이 단축된다. 둘째, 토큰·세션·툴 호출 단위로 비용을 쪼개 보이면 “LLM 비용은 블랙박스”라는 공포가 사라져 예산 승인 확률이 오른다. 셋째, 장애를 ‘조용히’ 내지 않고 먼저 감지·복구(채널 헬스체크, 자동 재시작)하면 B2B에서 치명적인 신뢰 하락과 Churn을 선제적으로 막는다.
실행 플레이북으로 번역하면 이렇게 된다. (1) 세션 로그를 ‘감사 원장’으로: 사용자 입력→툴콜→툴결과→최종 응답을 한 줄로 재구성하고, 민감정보 패턴 매칭(키/패스워드/프라이빗키) 쿼리를 상시 돌린다(dev.to는 SLS+SPL 예시를 제시). (2) OTEL로 성능·지연을 표준화: 에이전트/게이트웨이/툴을 트레이스로 묶어 병목을 찾고, 알림을 붙여 MTTR을 줄인다. (3) 비용을 기능처럼 노출: /usage, status --usage 같은 저비용(로컬 로그 기반) 계측을 기본값으로 두고, 하트비트 세션 분리·컨텍스트 컴팩션·동시성 제한으로 ‘폭주 비용’을 구조적으로 차단한다(‘How to Monitor…’의 최적화 팁).
전망은 분명하다. 에이전트 시장의 다음 경쟁은 “누가 더 똑똑한가”에서 “누가 더 감사 가능하고 예측 가능한 운영을 제공하는가”로 이동한다. 특히 금융/엔터프라이즈에서는 관측가능성이 곧 GTM이다. 견적서의 핵심 라인은 모델 성능이 아니라 감사로그, 비용 대시보드, 정책 위반 알림, 데이터 마스킹 같은 운영 스펙이 될 가능성이 높다. 제품팀은 기능 로드맵만 볼 게 아니라, 관측가능성을 ‘확장 가능한 신뢰’로 패키징해야 한다. 그 순간, PoC는 비용이 아니라 자산이 되고, 에이전트는 “통제 가능한 자동화”로 조직 안에 뿌리내린다.