AI 에이전트가 신뢰를 얻는 세 순간: 작업 전·중·후 설명가능성
해당 블로그는 Priyanka Kukreja 원저자의 글 'Before, during, after: The three moments AI Agents earn your trust'을 번역한 것입니다. 더 나은 이해를 위해서 약간의 의역이 반영되었습니다.
AI의 성능을 의심하던 시대는 지났습니다. 이제 병목은 신뢰입니다.
설명가능성을 다룬 지난 글에서 저희는 관측가능성(observability)과 설명가능성(explainability)을 분명히 구분했습니다. 에이전트가 무엇을 했는가와 왜 그렇게 했는가의 차이죠. 그리고 사람이 설명가능성을 필요로 하는 세 가지 작업, 곧 검증, 디버깅, 감사를 짚었습니다.
그런데 이 설명들이 개발자의 일상 작업 흐름 속 어디에 자리해야 할까요. 에이전트가 작업을 완전히 끝낸 뒤에야 요약을 보여 준다면 이미 사용자를 놓친 셈입니다. 세 가지 핵심 작업을 제대로 지원하려면 설명가능성이 제품 워크플로 안으로 직접 짜여 들어가야 합니다. 그 순간들이 정확히 어디에 있는지 살펴보겠습니다.
세 가지 미래, 하나의 공통점
워크플로 안에서의 위치가 왜 중요한지 이해하려면 AI 산업 전체가 어디로 향하는지를 보면 됩니다. Anthropic은 최근 AI 발전 시나리오 분석을 발표하며 세 갈래의 길을 제시했습니다.
- 첫 번째 시나리오: 발전이 정체되지만 이미 충분히 유능한 오늘날의 모델들이 경제 전반으로 확산됩니다.
- 두 번째 시나리오: AI 연구소들이 효율 개선을 계속 쌓아 가고 사람은 여전히 방향을 정하고 결과를 판단합니다.
- 세 번째 시나리오: AI 시스템이 스스로를 재귀적으로 개선하기 시작하고 사람은 "대부분의 노력을 감독, 검증, 확인 쪽으로" 옮깁니다.
(가능성이 더 높은) 두 번째와 세 번째 시나리오에서 사람의 역할이 어떻게 바뀌는지 보세요. 사람은 더 이상 작업을 직접 하는 주체가 아니라 작업을 검증하는 주체가 됩니다. Anthropic은 이미 자사 내부에서 이런 일이 벌어지고 있다고 말합니다. 자사 코드베이스에 머지되는 코드의 80% 이상을 이제 Claude가 작성하거든요. 코드 생성이 빨라지자 사람의 리뷰가 병목이 됐습니다. Anthropic은 암달의 법칙(Amdahl's law)을 인용합니다. 한 과정의 일부를 아무리 빠르게 만들어도 빨라지지 않은 부분이 전체 속도의 상한을 정한다는 법칙이죠.
이것이 세 미래를 관통하는 공통점입니다. 어느 쪽에 도달하든 희소해지는 사람의 활동은 코드를 작성하는 일이 아니라 그 코드를 신뢰할지 결정하는 일입니다.
결과만 신뢰할 때의 한계
지난 1년간 AI 에이전트를 둘러싼 산업의 핵심 질문은 오로지 성능에 관한 것이었습니다. 저희는 이렇게 물었죠. 에이전트가 X를 할 수 있는가? {X: 버그 수정 | 서비스 리팩토링 | 실험 실행 | 등등}. 이제 산업 벤치마크와 실사용 데이터 양쪽에서 답을 얻었습니다. 에이전트가 쏟아 내는 결과물의 속도를 한번 보세요.
- 커밋 변동성: GitHub은 2025년 한 해 동안 약 10억 건의 커밋을 처리했는데 2026년 중반에는 주당 2억 7,500만 건을 추적하고 있었습니다(참고). 올해 산업 전체가 140억 건의 커밋을 향해 가는 속도입니다. 에이전트가 이제 기계 속도로 코드를 커밋합니다.
- 네트워크 트래픽: Cloudflare는 자사 네트워크에서 자율 AI 에이전트가 생성한 주간 요청이 단 한 달 만에 두 배 넘게 늘었다고 보고했습니다(참고).
- 작업 지평(Task Horizon): METR의 측정에 따르면 에이전트가 안정적으로 작동할 수 있는 시간의 길이가 약 4개월마다 두 배로 늘고 있습니다. 2년 전 길어야 4분짜리 작업이 한계였던 에이전트가 이제 12시간을 사람 개입 없이 돌아갑니다(참고).
이렇게 끈끈한 도입 곡선을 끌어가는 힘은 결과에 대한 근본적인 신뢰입니다. 개발자들은 에이전트가 충분히 많은 티켓을 닫고 충분히 많은 불안정한 테스트를 고치고 충분히 많은 동작하는 PR을 보내는 모습을 지켜봤습니다. 성능은 더 이상 질문거리조차 아닙니다.
하지만 "결과를 신뢰한다"는 데는 유통기한이 있습니다.
에이전트가 훨씬 더 넓은 영향 범위(blast radius)를 가진 긴 작업을 떠맡으면서 "에이전트가 대체로 맞다"는 범위 밖으로 떨어지는 엣지 케이스의 양이 누적되기 시작합니다. 여러분의 제품이 이 단계에 이르렀다면 우선 축하드립니다. 그리고 행운을 빕니다. 한 줄 한 줄 사람이 리뷰하는 일이 수학적으로 불가능해지는 수준의 에이전트 산출량에 도달했다는 뜻이거든요.
이것이 궁극의 압박입니다. 사람이 검증할 수 있는 한계를 넘는 코드가 쏟아지는데 실패의 대가는 그 어느 때보다 커졌습니다. 이 AI 우선 세계를 헤쳐 나가는 유일한 길은 설명가능성을 값싸게 만드는 AI 도구를 만드는 것입니다.
다시 말해 모든 AI 도구는 결국 설명가능성 도구가 되는 길로 향하고 있습니다.
물론 여기엔 뻔한 농담이 따라붙습니다. 그럼 설명하는 자는 누가 설명하나요? AI 도구를 설명하는 AI 도구를 설명하는 AI 도구가 끝없이 이어지는 그림이죠. 하지만 이 재귀는 늘 그래 왔듯 같은 자리에서 멈춥니다. 바로 사람입니다. 첫 번째 설명가능성 글에서 다룬 설명가능성 스택의 요점은 감시자를 무한히 쌓는 것이 아니라 그 사슬 어디에 사람이 앉아 있든 그에게 닿는 "왜"가 실행 가능하도록(actionable) 보장하는 것이었습니다.
기반 모델 전반에서 가중치가 범용화되고 있습니다. 그래서 다음 국면의 승자는 모델이 근소하게 더 나은 제품이 아닙니다. 사슬 끝에 있는 사람을 빠르고 정확하며 조금 덜 괴롭게 만들어 주는 제품이 이깁니다 ;-)
설명가능성 워크플로
대부분의 팀은 설명가능성을 사후 산출물로 취급합니다. 에이전트가 작업을 끝내면 그제야 요약을 만들어 내죠. 그건 일의 3분의 1에 불과합니다. 진정한 설명가능성은 세 개의 서로 다른 순간에 일어나며 각 순간은 서로 다른 종류의 "왜"를 필요로 합니다.
1. 작업 전: 사고 과정을 보여 주세요
잘못된 결정을 가장 값싸게 잡아내는 자리는 작업이 일어나기 전입니다.
에이전트가 파일 하나라도 건드리기 전에 다음에 답할 수 있어야 합니다. 제가 이해한 여러분의 요청은 이것이고 저는 이렇게 단계로 나눴으며 다른 대안 대신 이 접근을 택한 이유는 이것입니다.
이것이 추론과 계획(planning) 레이어이며 의도 불일치가 드러나는 지점입니다. 가령 에이전트에게 "불안정한 결제 테스트를 고쳐 줘"라고 요청한다고 해 보죠. 한 가지 유효한 계획은 불안정을 일으키는 레이스 컨디션(race condition)을 찾아 고치는 것입니다. 다른 하나는 재시도 래퍼를 추가하는 것이고요. 세 번째는 테스트를 통째로 삭제하는 것입니다. 셋 다 기술적으로는 문제를 "고치"지만 여러분의 의도는 그중 하나뿐이었습니다. 계획은 이런 어긋남을 일찌감치 드러내 줍니다. 에이전트가 토큰을 태우거나 오후 내내 뒷수습을 디버깅하기 전에 방향을 다시 잡도록 도와주죠.
이 단계에서 여러분의 제품이 답해야 할 질문: 에이전트가 내 의도를 이해했는가, 그리고 작업을 쪼갠 방식이 그 의도와 맞아떨어지는가?
2. 작업 중: 탐색 과정을 보여 주세요
에이전트는 프롬프트에서 PR까지 직선으로 걸어가지 않습니다. 갈래를 치고 막다른 길에 부딪히고 되돌아왔다가 다시 보정합니다. 그 탐색은 최종 디프에서는 보이지 않지만 사용자가 신뢰를 쌓는 데는 양보할 수 없는 요소입니다.
여기서 여러분이 원하는 것은 원시 도구 로그가 아닙니다. 설명가능성을 다룬 원래 글에서 "로그를 보여 준다"가 왜 누구에게도 도움이 안 되는지 설명했습니다. 여러분이 원하는 것은 결정 추적(decision trace)입니다. 에이전트가 어떤 경로를 탐색했는지, 어떤 경로가 무의미(no-op)했는지, 그리고 결정적으로 한 갈래를 택하기 직전에 어떤 구체적 정보를 봤는지 말이죠.
예를 들어 "캐싱 접근을 탐색했더니 인증된 요청에서는 캐시 레이어가 우회된다는 사실을 발견했고 대신 쿼리를 고치는 쪽으로 전환했습니다"라는 설명은 리뷰어가 판단의 근거를 5초 만에 검증하게 해 줍니다. 같은 정보가 400줄짜리 원시 도구 호출 사이에 흩어져 있다면 여러분의 AI 제품이 "설명가능성을 처리한다"고 한들 사실상 숨겨진 것이나 다름없습니다.
이 단계에서 여러분의 제품이 답해야 할 질문: 에이전트가 올바른 사고의 사슬을 따르고 있는가? 알맞은 경로를 골랐고 유효한 입력을 넣었으며 돌아온 결과를 제대로 해석한 뒤 다음으로 넘어갔는가?
3. 작업 후: 그 영향을 보여 주세요
워크플로의 이 부분은 가장 자주 빠뜨려지는데도 위험은 가장 큽니다.
에이전트는 그 작업의 모든 영향, 특히 눈앞의 디프에는 보이지 않는 영향까지 설명하기 전까지는 작업을 설명한 것이 아닙니다. 코드 변경 요약은 그저 PR 설명일 뿐입니다. 영향의 전 범위를 빠짐없이 보여 줄 때만 진짜 설명이 됩니다. 흔한 제품 실수는 전자를 만들어 놓고 후자라고 믿는 것입니다.
예를 들어 보죠. 에이전트가 한 줄짜리 변경으로 PR을 엽니다. 코드베이스 전반의 철자 불일치를 바로잡기 위해 enum 값을 cancelled에서 canceled로 바꾸는 변경이죠. 디프는 깔끔합니다. 타입 체커도 만족합니다. 에이전트가 테스트까지 성실히 업데이트한 덕분에 레포의 모든 테스트가 통과합니다. PR에서 확인할 수 있는 모든 신호로 보면 이건 상상할 수 있는 가장 안전한 변경, 단순한 오타 수정입니다.
다만 그 값은 이 레포 안에서만 사는 게 아닙니다. 큐에 실리는 이벤트로 직렬화되고 두 단계 아래의 결제 서비스가 구독 청구를 멈추기 위해 cancelled를 문자열로 매칭합니다. 어떤 에러도 나지 않습니다. 어떤 호출도 울리지 않습니다. 결제 서비스는 그저 조용히 취소를 인식하지 못하게 되고 구독을 취소한 고객은 계속 청구를 받습니다.
디프만 보는 리뷰어는 철자 수정을 검증하는 셈입니다. 전체 영향 범위, 곧 이 값은 서비스 경계를 넘나들며 이것을 소비하는 쪽은 여기다까지 보는 리뷰어는 실제 결정을 검증합니다.
이건 일회성 엣지 케이스가 아닙니다. 오늘날 코드를 리뷰하는 방식에 난 큰 구멍입니다. 코드 리뷰는 늘 눈앞에 있는 것을 기준으로 삼아 왔지만 변경의 결과는 디프의 경계를 거의 존중하지 않습니다. 그래서 저희는 이 단계의 설명가능성을 높은 기준에 맞춰야 한다고 믿습니다. 단지 "무엇이 바뀌었는가"가 아니라 그 변경 때문에 시스템이 무엇을 다르게 할지를 빠짐없이 이해하는 수준 말이죠.
이 단계에서 여러분의 제품이 답해야 할 질문: 이 변경이 실제로 무엇을 하는가, 내가 볼 수 없는 부분까지 빠짐없이?
설명가능성이 곧 제품입니다
워크플로의 세 단계에서 한발 물러나 공통점을 보겠습니다.
- 작업 전, 에이전트는 자신의 의도를 설명합니다.
- 작업 중, 에이전트는 자신의 판단을 설명합니다.
- 작업 후, 에이전트는 자신이 일으킨 결과를 설명합니다.
이 셋은 로드맵에서 하나씩 체크할 세 개의 기능이 아닙니다. 사람이 에이전트의 작업을 두고 결정을 내려야 하는 세 지점에 적용되는 하나의 의무입니다. 진행하게 둘지, 아니면 통제권을 넘겨받아 다른 방향으로 끌고 갈지 말이죠.
이것이 산업이 수렴해 가는 감독(oversight) 역할의 진짜 모습입니다. 에이전트를 감독하는 사람은 모든 줄을 읽지 않습니다. 한 사람이 직접 들여다볼 수 있는 양을 넘어서는 산출물을 두고 그 세 가지 질문에 거듭 답할 뿐입니다. 그래서 감독의 품질은 그에게 닿는 설명의 품질에 묶여 있습니다.
산업 스스로의 예측이 맞아서 사람의 역할이 감독과 검증으로 수렴한다면, 설명가능성은 AI 도구 위에 얹는 있으면 좋은 기능이 아닙니다. 그 자체가 제품입니다.
CodeRabbit에서 저희가 출발점으로 삼는 전제가 바로 이것입니다. 저희가 내놓는 모든 것에서 설계 질문은 동일합니다. 이 작업을 검증하는 사람은 무엇을 알아야 하며 어느 순간에 그것을 알아야 하는가?
관련해서 AI 에이전트를 신뢰하시나요에서 관측가능성과 설명가능성의 차이를 더 깊이 다뤘습니다. 에이전트가 의도를 이해하는 문제는 AI 코드 리뷰의 진짜 병목, 의도 이해에서, 사람과 AI의 역할 분담은 AI 코드 리뷰 vs 사람 코드 리뷰에서 이어 보실 수 있습니다.