여러분은 자신의 AI 에이전트를 신뢰하시나요?
해당 블로그는 Priyanka Kukreja 원저자의 글 'Do you trust your AI Agent?'을 번역한 것입니다. 더 나은 이해를 위해서 약간의 의역이 반영되었습니다.
여러분의 AI 에이전트는 자신의 풀이 과정을 보여줘야 합니다.
설명 가능성(Explainability)은 AI 에이전트가 실제 문제를 해결하기 위해 배포될지, 아니면 비핵심적인 엔터프라이즈 업무에서 보조 역할에 머무를지를 결정합니다.
1년 전, 에이전틱 AI가 등장하며 모두를 놀라게 했습니다. LLM을 단순한 채팅 도구에서, 여러분을 위해 실제로 무언가를 "해내는" 존재로 탈바꿈시켰죠. 하지만 이제 에이전트가 거의 어디에나 존재하게 되면서, 더 까다로운 문제에 부딪혔습니다. 바로 신뢰를 얻는 일입니다.
에이전트를 "자율적(autonomous)"이라고 부를 수는 있습니다. 그러나 제 이해관계자들, 예를 들면 제 매니저나 고객, 혹은 감사(audit) 검토 팀에게 에이전트가 무엇을, 왜 했는지를 설명하지 못한다면, 그 자율성은 사실 큰 가치가 없습니다.
에이전트가 진지한 업무에 쓰일지, 아니면 위험 부담이 낮은 작업의 보조 역할에 머물지는 결국 단 하나로 귀결됩니다. 사람들이 에이전트가 지금 무엇을 하고 있는지를 정말로 이해할 수 있는가?
설명 가능성이 정말 필요할까요?
먼저, 종종 (잘못) 혼용되는 "설명 가능성(explainability)"과 "관측성(observability)"을 구분하고 넘어갈 필요가 있습니다.
관측성(Observability) 은 "무슨 일이 일어났는가"에 관한 것입니다. 행동, 도구 호출, 입력, 출력, 분기 경로에 대한 단순한 기계적 기록이죠. 이는 대체로 해결된 엔지니어링 문제입니다. 구조화된 로깅을 구축할 수 있으며, 여기서의 과제는 그 로그를 대규모에서도 유용하게 만드는 일입니다.
설명 가능성(Explainability) 은 "왜 일어났는가"에 관한 것입니다. 의사결정 뒤에 놓인 에이전트의 추론, 에이전트가 고려했던 대안들, 그것이 얼마나 확신했는지 등을 이해하는 일이죠. 이쪽은 더 어렵고, 부분적으로는 아직 풀리지 않은 문제입니다.
자, 다음 중 하나라도 해당한다면 에이전트는 자신을 한층 더 설명해야 합니다.
이런 상황에서 에이전트가 스스로를 설명하지 못하면, 결국 신뢰 적자(trust deficit)에 빠지게 됩니다.
이에 관한 전형적인 사례는 에이전트를 다루는 엔지니어링 팀이라면 누구나 잘 아는 장면입니다. 인시던트가 발생하고, 개발자들이 에이전트가 무엇을 했는지 디버깅하려 합니다. 로그를 펼쳐 보니, 에이전트는 X라는 작업을 맡았는데 Y와 Z까지 한 사실을 발견합니다. 타임라인과 근본 원인을 짜맞춰 보려 하지만, 에이전트의 행동에서 실제 결과로 이어지는 경로가 명확하지 않고, 그 행동 뒤에 놓인 추론 역시 불분명합니다.
이 "신뢰" 세금은 조용하지만 확실하게 누적됩니다. 사용자가 에이전트가 무엇을 하는지 이해하지 못하게 되는 순간, 에이전트가 올바른 일을 하리라는 확신을 잃습니다. 시간이 지나면 미션 크리티컬한 작업을 맡기기 전에 망설이게 되고, 결국 생산성 향상분을 통째로 갉아먹는 수동 검토 단계를 덧붙이게 됩니다. 물론 에이전트는 자율성을 제공합니다. 하지만 확신을 쌓아 주지는 못하죠. 그리고 확신이 없으면, 자율성은 (적어도 중요한 일에서는) 더 이상 쓰이지 않습니다.
이는 가상의 실패 시나리오가 아닙니다. AI 배포의 모든 범주에 걸쳐 나타납니다. 정확도가 높은데도 개발자들이 미심쩍어하는 코드 리뷰 에이전트부터, 지원 팀이 모든 상호작용을 그림자처럼 따라다니며 감시하는 고객 대면 에이전트까지요. 품질이 나빠서가 아닙니다. 고객이 문제를 지원 팀으로 에스컬레이션했을 때 무슨 일이 있었는지 아무도 설명할 수 없기 때문입니다.
에이전트가 로그로 남기는 것과 사람이 실제로 이해할 수 있는 것 사이의 이 간극이, 궁극적으로 에이전틱 제품이 시장에서 자리잡지 못하게 만드는 원인입니다.
설명 가능성의 세 가지 역할
설명 가능성에는 세 가지 핵심적인 할 일(jobs-to-be-done)이 있으며, 각각 서로 다른 제품적 대응을 요구합니다.
검증(Verification): 에이전트가 내가 시킨 일을 했는가?
이 사용자는 빠르고 확신도 높은 신호를 원합니다. 디버깅을 하거나 트레이스를 찾으려는 게 아닙니다. 그저 체크 표시 하나를 원할 뿐이죠. 이 사용자에게 도구 호출 로그를 보여주는 것은 잘못된 답입니다. 마치 "결제가 됐나요?"라는 질문에 데이터베이스 쿼리 결과로 답하는 것과 같으니까요.
디버깅(Debugging): 어디서, 왜 잘못됐는가?
이 사용자는 이미 실패를 의심하고 있습니다. 의사결정 경로를 추적하고, 흐름이 갈라진 분기점을 짚어내며, 근본 원인을 이해해야 합니다. 여기서 필요한 것은 단순한 결과나 안심시키는 한마디가 아니라 깊이(depth)입니다.
감사 가능성(Auditability): 무슨 일이 있었는지 남에게 입증할 수 있는가?
여기서 주된 소비자는 사용자 본인이 아닙니다. 그의 매니저, 컴플라이언스 팀, 고객, 혹은 6개월 뒤 과거의 결정을 이해하려 애쓰는 미래의 자기 자신이죠. 따라서 여기서의 산출물은 내보내기가 가능하고(exportable), 변경 불가능하며(immutable), 사전 맥락이 전혀 없는 독자를 위해 구조화되어 있어야 합니다.
이 세 가지를 하나의 인터페이스로 전부 해결하려는 제품은, 결국 그 어느 것도 제대로 해내지 못합니다. 각 유스케이스의 요구 사항이 다르기 때문입니다. 검증은 압축을, 디버깅은 깊이를, 감사 가능성은 구조와 영속성을 필요로 합니다.
설명 가능성 스택(The Explainability Stack)
저는 설명 가능성과 관측성을 단일 기능이 아니라 계층화된 아키텍처로 생각합니다. 각 레이어는 서로 다른 맥락에 놓인 서로 다른 사용자에게 알맞은 답입니다.
- 레이어 0 - 결과(Outcome): 작동했는가? 단순한 이진(binary) 신호입니다. 대부분의 사용자가 일상적인 작업에서 대부분의 경우 원하는 것이 바로 이것입니다.
- 레이어 1 - 내러티브(Narrative): 에이전트가 무엇을, 왜 했는지에 대한 평이한 언어의 요약입니다. "PR을 생성하고, 이슈 세 건을 표시했으며, 42, 87, 203번 줄에 인라인 코멘트를 달았습니다." 일종의 탐사 보고서(expedition report)라고 생각하시면 됩니다. 에이전트가 나갔다 돌아와서, 무엇을 발견했는지 들려주는 것이죠.
- 레이어 2 - 의사결정 트레이스(Decision Trace): 에이전트가 왜 그런 선택을 했는가? 어떤 대안을 고려했고 또 기각했는가? 여기서부터 비로소 행동이 아니라 추론이 보이기 시작합니다.
- 레이어 3 - 도구 및 분기 로그(Tool and Branch Log): 어떤 도구가 어떤 파라미터로 호출됐고, 무엇이 반환됐으며, 어떤 경로가 탐색됐고, 어떤 막다른 길에 부딪혔는가. 무언가 망가졌을 때 엔지니어들이 살아가는 곳이 바로 여기입니다. 여전히 추론이 아니라 출력 기반이지만, 에이전트가 밟은 기계적 경로를 보여줍니다.
- 레이어 4 - 모델 추론(Model Reasoning): 추론 시점(inference time)의 사고 사슬(chain-of-thought)입니다. 모델이 자신의 실제 추론 과정을 드러내기 시작하는 지점이죠. 평가, 모델 개선, 파인튜닝 파이프라인에 매우 가치가 높으며, 동시에 프로덕션 환경에서 무언가 잘못됐을 때 최종 사용자에게도 여전히 유의미합니다.
- 레이어 5~7 - 딥 스택(The Deep Stack): 어텐션 패턴, 뉴런 활성화, 해석 가능성(interpretability) 연구의 영역입니다. 메커니즘 수준 이해의 최전선이죠. 대단히 흥미로운 과학이지만, (아직은) 제품 기능은 아닙니다.
패턴은 일관됩니다. 구현에 가까운 사람일수록 더 깊은 곳까지 들여다보고 싶어 합니다. 주간 에이전트 요약을 검토하는 솔루션 엔지니어는 레이어 1에 살고, 예상치 못한 도구 호출을 디버깅하는 개발자는 레이어 3에 살며, 창발적(emergent) 모델 행동을 연구하는 연구자는 레이어 5에 삽니다. 설명 가능성과 관측성은 모두에게 똑같이 적용되는 단일 규격이 아니라, 여러분의 사용자가 실제로 어디에 앉아 있는지에 따라 정의됩니다.
설명 가능성 스택을 적용하기
설명 가능성 스택에는 두 가지 실용적인 활용처가 있습니다. (1) 올바른 사용자 경험을 정의하는 것, 그리고 (2) 성공 지표가 어디서 무너지고 있는지 진단하는 것입니다.
사용자 경험 정의하기
여러분의 에이전트와 접촉하는 모든 대상을 먼저 나열해 보세요. 예를 들면 최종 사용자, 지원 팀, 세일즈 엔지니어, 컴플라이언스 검토자 등이 있겠죠. 그리고 각각에 대해, 이들이 실제로 어느 레이어를 필요로 하는지 물어보세요. 대부분의 팀은 이것을 "로그 보기" 토글 하나로 뭉뚱그리는데, 이는 비기술적 사용자에게는 너무 많이 보여주고 엔지니어에게는 너무 적게 보여줍니다. 해법은 특정 표면(surface)에 묶인 단계적 공개(layered disclosure)입니다.
- 헤드라인 UI의 레이어 0: PR에 붙은 초록색 체크 표시, 또는 "티켓 3건 해결" 배지
- 비동기 리캡의 레이어 1: Slack에 올라오는 월요일 다이제스트, 또는 주간 이메일 요약
- 원클릭 "왜?" 뒤의 레이어 2: 사용자가 동의하지 않을 수 있는 모든 결정에 대해
- 레이어 3과 4: 개발자 콘솔이나 감사 내보내기(audit export) 뒤에 게이팅
이렇게 분리해 두면 그 보상은 지원(support) 현장에서 드러납니다. 고객이 "에이전트가 잘못된 일을 했어요"라고 말할 때, 결과에서 출발해 필요한 만큼만 더 깊이 내려가며 함께 스택을 짚어 내려갈 수 있습니다. 신뢰는 실제로 이런 방식으로 쌓입니다.
성공 지표 진단하기
건너뛴 레이어마다 비용이 따르며, 그 비용은 배포가 진행될수록 더 크게 불어납니다.
레이어 0이나 1을 건너뛰면 도입(adoption)이 타격을 받습니다. 사용자와의 기본적인 신뢰 루프가 형성되지 않아, 사용자는 두 번째 작업을 결코 맡기지 않습니다. 에이전트는 신기함(novelty) 단계에서 멈춰 버리죠.
레이어 2를 건너뛰면 리텐션(retention)이 타격을 받습니다. 사용자는 자신이 직접 뒤집을(overrule) 수 있다고 확신하는 에이전트에게만 계속 일을 넘깁니다. Cursor의 디프(diff) 뷰와 Codex의 변경 미리보기가 모델 업그레이드 못지않게, 어쩌면 그 이상으로 고착도(stickiness)에 중요한 이유가 바로 이것입니다.
레이어 3을 건너뛰면 엔터프라이즈 거래가 막힙니다. 이 레이어의 중요도는 여러분의 제품이 속한 산업과 규제 환경에 따라 달라집니다.
레이어 4를 건너뛰면 평가(eval)의 토대가 흔들립니다. 추론 트레이스가 없으면 평가 파이프라인은 결과에만 기댄 채 닻을 내립니다. 그러면 에이전트가 결과에 이르는 올바른 경로를 밟았는지, 아니면 그저 테스트 데이터에서 운이 좋았던 것인지 구분하기가 거의 불가능해집니다.
동기 vs. 비동기: 서로 다른 두 제품
설명 가능성에는 대부분의 팀이 충분히 명세하지 않는 시간적 차원(temporal dimension)이 있으며, 이것이 제품 아키텍처를 상당히 바꿔 놓습니다.
동기적(Synchronous) 설명 가능성 은 사용자가 에이전트가 일하는 모습을 실시간으로 지켜볼 수 있게 합니다. 사고 트레이스, 실시간 도구 호출 스트림, 눈에 보이는 코스 수정 같은 것들이죠. 이 방식은 최종 출력과는 다른 목적에 봉사합니다. 실행 도중에 확신을 쌓아 주는 것이죠. 사용자가 에이전트가 비생산적인 경로로 들어섰다가 스스로 바로잡는 모습을 볼 수 있을 때, 그 눈에 보이는 회복이 신뢰를 한층 더 키웁니다. 더 중요하게는, 사용자가 일찍 개입할 기회를 만들어 주어 시간과 토큰을 아끼게 해 줍니다.
비동기적(Asynchronous) 설명 가능성 은 사후(post-facto) 보고서입니다. 에이전트가 실행을 마치고 돌아오면, 어디를 다녀왔고 무엇을 결정했는지에 대한 구조화된 보고가 주어지는 것이죠. 이 형식이야말로 병렬 에이전트 워크로드를 대규모에서 관리 가능하게 만들어 줍니다. 코드베이스 전반에 걸쳐 동시에 리뷰, 의존성 점검, 보안 스캔을 돌리는 에이전트 함대를 운영하고 있다면, 그 하나하나를 실시간으로 지켜볼 수는 없습니다. 이 탐사 보고서 형식이 바로 그 관리 레이어를 제공해 줍니다.
동기와 비동기 설명 가능성은 같은 제품이 아닙니다. 정보 위계가 다르고, 지연(latency) 허용치가 다르며, 사용자와 맺는 "감정적 계약(emotional contract)"도 다릅니다. 하나를 만들었다고 해서 다른 하나가 저절로 따라오는 것은 아닙니다.
골디락스 제약(The Goldilocks Constraint)
이 모든 것의 한가운데에는 섬세한 보정(calibration) 문제가 놓여 있습니다.
설명 가능성이 너무 적으면, 사용자는 에이전트의 추론을 검증할 수 없고, 따라서 중요한 일은 무엇 하나 맡기지 않습니다.
설명 가능성이 너무 많으면, 사용자는 결정 피로(decision fatigue)에 빠집니다. 출력량이 너무 많은 나머지 읽기를 멈추고 모든 것에 기계적으로 도장만 찍기 시작하면, 사용자 참여는 형식적인 시늉으로 전락합니다. 그렇게 되면 도입이 멈춰 서는 것은 시간문제일 뿐입니다.
첫 번째 실패 모드의 위험은 위에서 충분히 다뤘습니다. 하지만 두 번째 실패 모드는 한층 음흉하게 작동합니다. 실질은 없으면서 감독(oversight)이 이루어지고 있다는 겉모습만 만들어내거든요. 규제 환경에서 일하는 사람에게는, 이 간극이 보기보다 훨씬 빠르게 컴플라이언스 책임 문제로 번질 수 있습니다.
이것은 굿하트의 법칙(Goodhart's Law)이 새로운 영역에서 모습을 드러낸 사례이기도 합니다. 어떤 측정값이 목표가 되는 순간, 그것은 더 이상 좋은 측정값이 되지 못합니다. "설명의 양"이 "감독의 품질"을 대신하는 대리 지표가 되어 버리면, 제품은 그 대리 지표를 최적화하면서 정작 측정하려 했던 본질을 잃게 됩니다. 더 많은 로그, 트레이스, 추론 텍스트는 결국 그 어느 것도 더 이상 들여다보지 않는 독자로 귀결될 뿐입니다.
제가 자꾸 되돌아오는 기준점은 이것입니다. 숙련된 인간 동료는 무언가를 독립적으로 작업한 뒤 여러분에게 어떻게 보고할까요? 그들은 모든 검색 쿼리를 일일이 읊거나 브라우저 기록 전체를 공유하지 않습니다. 대신 이렇게 말하죠. "X와 Y를 살펴봤어요. X는 이런 이유로 막다른 길이었고, Y가 앞으로 나아갈 길입니다. 왜 그런지, 그리고 제가 아직 확신하지 못하는 부분은 무엇인지 말씀드릴게요."
렌더링 문제는 아직 열려 있습니다
설명 가능성을 렌더링하는 방식에는 여러 양식이 있습니다. 자연어 내레이션, 구조화된 타임라인, 시각적 디프 렌더링, 접을 수 있는 도구 호출 트리 등이죠. 맥락에 따라 모두 정당한 형식입니다. 더 흥미로운 제품적 질문은 어떤 양식을 고를 것인가가 아니라, 주어진 맥락과 사용자에 맞춰 에이전트 스스로 적절한 양식을 결정하도록 어떻게 권한을 부여할 것인가입니다.
동기적 트레이스에서는 사용자가 그 자리에 있으면서 직접 탐색할 수 있으므로, 좀 더 날것의 구조도 허용됩니다. 반면 독자가 사전 맥락을 전혀 갖지 못한 비동기 보고서에서는, 그들이 날것의 로그를 해석해 주기를 기대할 수 없습니다. 여기서는 큐레이션이 기본 조건(table stakes)이 됩니다. 관련성, 가독성, 파싱 가능성이 그것이죠.
저는 이 문제에 아직 산업 차원의 깔끔한 해법이 있다고 생각하지 않습니다. 하지만 이를 단순한 엔지니어링 로깅 문제가 아니라 제품 디자인 문제로 바라보는 팀이, 더 빨리 그 해법에 도달할 것입니다.
결국 전부는 신뢰입니다
몇 년 뒤, 저희는 어떤 제품이 다른 제품보다 더 성공한 이유를 돌아보게 될 것입니다. 한 가지는 분명해질 겁니다. 더 나은 설명 가능성을 갖춘 제품이 더 큰 사용자 신뢰를 누렸고, 그래서 미션 크리티컬한 과제를 맡는 쪽으로 선택받았다는 사실 말이죠.
기반 모델(foundational model)이 점차 범용 상품(commodity)으로 수렴해 가면서, 진정한 차별점은 제품이 사용자와 얼마나 깊은 유대(bond)를 맺을 수 있는가가 될 것입니다. 그리고 신뢰는, 인간에게든 제품에든, 모든 유대의 토대입니다.
CodeRabbit에서 이것은 단지 이론에 그치지 않습니다. 저희는 모든 제품 전반에 걸쳐 설명 가능성을 구축하고 있습니다. 개발자에게 무슨 일이 있었고 왜 그랬는지를, 출력 더미에 파묻히게 하지 않으면서 어떻게 보여줄 것인가. 바로 이 질문을 저희는 지금 프로덕션에서 풀어 나가고 있습니다. 그 모습이 어떤 것인지는 곧 더 자세히 들려드리겠습니다!