Atrium: 코딩 에이전트 옆에서 구동하는 AI 조사 플랫폼 투어

저는 Snowflake의 엔지니어 Mayank이며, 보안 및 연결성 분야를 지원하고 있습니다. Atrium은 제가 직접 업무 케이스워크를 위해 만든 도구입니다. 내부용 시스템이라 코드나 회사 관련 세부 정보는 없으며, 작동 방식과 이렇게 설계된 이유에 대한 아키텍처 레벨 투어입니다.

대부분의 AI 코딩 에이전트는 조사하는 능력은 뛰어납니다. 문제점을 제시하면 데이터를 쿼리하고, 로그를 읽고, 제가 적절한 탭을 여는 것보다 빠르게 답변을 작성합니다. 하지만 잘 못 하는 것은 자신의 작업 과정을 증명하는 것입니다. 지원 업무에서 신뢰성 있는 답변에 빈틈이 있으면 느린 답변보다 더 나쁩니다. 왜냐하면 그 답변이 고객에게 전달되기 때문입니다.

Atrium은 이 문제에 대한 저의 해답입니다. Atrium은 코딩 에이전트의 터미널 세션 바로 옆에서 실행되는 경량 웹 앱으로, 케이스 전체 수명 주기(intake, SLA 추적, 구조화된 문제 진술, AI 인사이트, 다른 계열 모델을 통한 에이전트 작업에 대한 적대적 검토(adversarial review), 고객 답변 최종 점검)를 포괄합니다. 에이전트가 조사를 수행하고, Atrium은 작업을 시작할 때 틀을 잡고 끝날 때 도전하며 검증하는 역할을 합니다.

여기에 투어를 소개합니다.

아키텍처

  CRM 미러(mirror) ──► ┌─────────────────────────────────────────┐ ◄──► Slack
                 │ Atrium (Python + Tornado)              │      (검증 작업)
                 │                                         │
...

이 그림에서 중요한 두 가지가 있습니다. 첫째, 에이전트는 검토자에게 직접 말을 걸지 않습니다. Atrium이 그 사이에 위치하기 때문에, 제가 언제 검토를 실행할지, 그리고 무엇을 되돌려 보낼지를 결정합니다. 둘째, 모든 것이 에이전트 자체의 터미널을 통해 흐릅니다. Atrium은 CLI(Command Line Interface)의 훅(hooks)과 이벤트를 감지하며, 사용자 입력이 도착하는 방식과 동일하게 CLI에 피드백을 주입하여 답변합니다.

제가 이것을 만든 이유

AI 에이전트가 지원 케이스를 조사할 때, 그 실수는 거의 요란하지 않습니다. 그것은 근거가 되는 쿼리 없이 주장만 하거나, 조용히 건너뛴 진단 단계처럼 보이거나, 증거가 완전히 뒷받침하지 못하는 증상에서 근본 원인으로의 비약처럼 보입니다. 각각은 자체로는 괜찮아 보입니다. 이것이 문제입니다.

만약 제가 에이전트가 수행한 모든 것을 수동으로 재검증해야 한다면, 절약된 시간은 다시 소모됩니다. 따라서 AI 지원의 실제 병목 지점(bottleneck)은 속도가 아니라 신뢰입니다. 저는 고객에게 전달하기 전에 에이전트가 무엇을 했고 왜 그렇게 했는지 확인해야 합니다. Atrium은 이러한 과정을 가시화하고, 에이전트가 말로만 넘어가기 어려운 '제2의 의견'을 제공하는 데 중점을 두고 구축되었습니다.

투어: 시작부터 끝까지 하나의 사례(case)

1. 사례 작업 공간 (Case workspace)

Atrium은 저희 CRM의 미러(mirror)에서 사례를 가져오기 때문에, 대기열(queue), 사례 이력(case history), 상태가 다른 브라우저 탭이 아닌 에이전트 세션과 같은 창에 표시됩니다. SLA 타이머는 사례별로 추적되므로, 다음 사례를 처리하기 전에 어떤 것이 마감 기한에 임박했는지 확인할 수 있습니다.

2. AI 인사이트 (AI insights)

제가 파고들기 시작하기 전에 Atrium은 해당 사례에 대해 네 가지 종류의 인사이트를 제공합니다:

유사 과거 사례(Similar past cases): 이전에 해결된 문제를 다시 해결하는 것을 방지합니다.
가능한 근본 원인(Likely root causes): 초기 가설 세트(set of hypotheses)로 활용됩니다.
SLA 위험 플래그(SLA risk flags): 즉각적인 주의가 필요한 사례를 표시합니다.
제안된 다음 단계(Suggested next steps): 시작할 수 있는 구체적인 지점을 제공합니다.

3. 구조화된 문제 진술 (Structured problem statement)

LLM은 원본 사례를 고정된 섹션이 포함된 구조화된 요약으로 변환합니다:

증상 및 오류 메시지(Symptoms and error messages)
환경 및 구성(Environment and configuration)
타임라인 및 고객 영향(Timeline and customer impact)
시도된 내용 및 현재 가설(What's been tried, and current hypotheses)
개념(Concepts): 기술 스택과 전문 용어(jargon)를 일반 언어로 풀어 설명하여, 사례가 생소한 영역에 걸쳐 있더라도 요약본을 쉽게 읽을 수 있게 합니다.

저는 실제 업무 사례에서 이를 테스트해 보았는데, 코딩 에이전트에게 질문을 단 하나도 하지 않고도 심층적인 조사를 안내할 만큼 충분히 상세합니다.

4. 조사 (Investigation)

조사 자체는 평소와 같이 코딩 에이전트의 터미널 세션에서 이루어집니다. Atrium은 에이전트를 대체하거나 자체 채팅으로 감싸지 않습니다. 대신 CLI(Command Line Interface)의 후크(hooks)와 이벤트(events)를 수신하여, 에이전트가 진행하는 것을 실시간으로 알게 됩니다.

5. 적대적 검토 (Adversarial review)

에이전트가 초안을 작성하면, 저는 검토를 실행하기 위해 클릭합니다. 이것이 Atrium의 핵심 기능이므로 아래에서 별도의 섹션으로 다룹니다.

고객에게 전달되는 답변은 전용 정제 화면에서 최종 점검을 거칩니다. 엔지니어는 어조 옵션을 설정하여, 답변이 모델처럼 들리기보다 실제로 보내는 사람의 목소리처럼 들리도록 만듭니다.

7. Slack에서의 검증 (Validation in Slack)

저희의 일부 검증 작업은 Slack에서 이루어집니다. Atrium은 이러한 작업을 미러링하여 제 케이스워크 옆에 배치하고, 신속한 상태 점검(sanity check)을 수행합니다.

심층 분석하는 적대적 검토 (The adversarial review, in depth)

이 검토 과정에는 어떤 프롬프트보다 중요한 세 가지 설계 선택 사항이 있습니다. 누가 검토할지, 무엇을 확인할지, 그리고 그 결과가 에이전트에게 어떻게 전달될지입니다.

다른 모델 계열의 검토자 (A reviewer from a different model family)

검토자는 코딩 에이전트와는 다른 LLM 계열의 다른 모델로 실행됩니다. 자신의 스타일로 작업물을 판단하도록 요청받은 모델은 자신과 유사한 경향을 보입니다. 이는 다음과 같이 문서화되어 있습니다: Panickssery, Bowman, and Feng (NeurIPS 2024)에 따르면, LLM 평가자는 인간 주석가가 동등하다고 평가하더라도 자신들의 결과물을 다른 모델의 결과물보다 더 높은 점수를 주는 경향이 있습니다. 따라서 다른 계열의 검토자는 에이전트의 습관이나 사각지대를 공유할 가능성이 낮아, 적절한 곳에서 반론을 제기할 가능성이 더 높습니다.

또한 이 검토는 제가 실행하도록 클릭했을 때만 작동합니다. 저는 언제 에이전트의 작업물이 도전을 받을 준비가 되었는지 결정하며, 모든 검토는 배경 잡음(background noise)이라기보다는 의도적인 단계입니다.

모드 1: 초안 확인 (Draft check)

모드 1은 답변을 테스트합니다. 고객에게 전달되는 초안을 가져와 그 뒤에 있는 조사 내용을 교차 검증합니다. 이 과정에서 에이전트와는 독립적으로 케이스 자료를 상호 참조하고 자체 SQL 쿼리를 실행하여, 초안이 제시하는 각 요점을 확인하거나 반박합니다. 증거가 불일치하거나 아예 없는 경우, 그 지점을 제기합니다.

독립적인 쿼리가 중요한 부분입니다. 에이전트의 기록(transcript)만 읽는 리뷰어는 추론 과정은 확인할 수 있지만 사실 관계를 확인할 수는 없습니다. 데이터로 되돌아갈 수 있는 리뷰어만이 에이전트가 실제로 검증하지 않은 주장을 잡아낼 수 있습니다.

모드 2: 런타임 재구축(Runtime rebuild)

모드 2는 경로(path)를 테스트합니다. 에이전트의 실행 과정을 재구축하여 다음 세 가지 질문에 따라 확인합니다:

올바른 흐름을 사용했는가? 조사가 해당 유형의 사례에서 요구하는 접근 방식을 따랐는가?
핵심 기술(key skills)이 누락되었는가? 모드 2는 로컬 및 원격 기술 모두를 재점검하여 에이전트가 적용해야 할 기술을 건너뛰었는지 확인합니다.
논리적 비약이나 공백은 없는가? 에이전트가 그 사이에 증거 없이 한 결론에서 다음 결론으로 이동한 지점이 있는지 확인합니다.

답변은 운 좋게 맞을 수 있고, 경로가 합리적으로 보일지라도 답변 자체가 틀릴 수 있습니다. 두 모드를 모두 실행하면 이러한 모든 실패를 포괄할 수 있습니다.

버전 관리 패킷으로서의 피드백

두 모드에서 얻은 발견 사항(Findings)은 에이전트에게 버전 관리된 패킷으로 전달되며, 사용자 입력이 도착하는 것과 동일한 방식으로 CLI 창에 직접 주입됩니다. 에이전트는 검토 결과를 받기 위해 특별한 통합이 필요하지 않습니다. 다른 모든 지침처럼 이 패킷을 읽고 작업을 수정하며, 저는 여전히 최종 답변이 나가는 곳까지 가기 전에 이를 검토합니다.

내부 작동 원리(Under the hood)

Tornado를 사용한 이유

Atrium은 Tornado 기반의 Python 앱이며, 선택 이유는 이 앱이 시간을 보내는 활동에 달려 있었습니다:

실시간 UI 업데이트: 에이전트가 작업하는 동안 브라우저 뷰가 WebSockets을 통해 최신 상태를 유지합니다.
비동기 이벤트 처리(Async event handling): CLI 후크 및 이벤트가 다른 작업이 진행되는 동안 도착하며, Tornado의 비동기 모델은 이를 차단 없이 처리합니다.
경량성 및 빠른 시작: 작동 중인 에이전트 세션 옆에서 실행되어야 하므로 느린 부분이 될 수 없습니다.
패킷 주입(Packet injection): 피드백을 CLI로 다시 작성하는 것은 다른 모든 것과 함께 하나의 비동기 작업에 불과합니다.

상태(State)

Atrium은 로컬 파일이 아닌, 개인 Snowflake 데이터베이스에 상태를 보관합니다.

Vesta에서 Atrium으로

Atrium은 2세대 버전입니다. 이전 버전인 Vesta는 Streamlit 앱이었습니다. Vesta가 아이디어를 증명했지만, 기능이 쌓이면서 무거워졌고 오직 한 사람만이 사용할 수 있었습니다. Tornado를 기반으로 재구축하면서, 별도의 목적지가 되는 대신 터미널 세션 옆에 위치하도록 처음부터 설계된 빠르고 가벼운 앱을 얻기 위해 Streamlit의 편리함을 포기해야 했습니다.

구축 과정 (How I build it)

저는 Atrium을 코딩 에이전트에게 한 줄씩 프롬프팅하여 만드는 것이 아닙니다. 저는 작업을 자율적인 에이전트들에게 위임하고, 이들이 작업을 수행하며 새로운 기술을 습득하도록 함으로써 개발합니다. 저의 역할은 아키텍처 설계, 검토 표준 설정, 그리고 다음에 무엇을 구축할지 결정하는 것입니다.

다음 계획 (What's next)

현재 Slack 유효성 검사 흐름(validation flow)은 간단한 건전성 점검을 거칩니다. 다음으로는 이 흐름에 대해 복잡한 사례를 위한 동일한 적대적 LLM(adversarial LLM) 검사를 실행할 계획입니다. 따라서 유효성 검사를 통과하는 작업물은 이미 처리되는 사례들과 마찬가지로 두 가지 모드의 검토를 받게 될 것입니다.

핵심 요약 (Takeaways)

에이전트가 조사하게 하고, 스스로 평가하게 하지 마세요. 검토는 별도의 모델(이상적으로는 다른 계열의 모델)에서 수행해야 합니다.
답변과 경로를 분리하여 확인하세요. 주장(claims)을 데이터와 대조하여 검증하고 에이전트가 도달한 과정을 재구축하는 것은 서로 다른 실패 지점을 포착합니다.
에이전트가 이미 작동하는 곳에서 만드세요. 후크(Hooks)를 사용하고, 피드백을 입력으로 주입하세요. 커스텀 에이전트를 만들거나 새로운 채팅 창을 열 필요가 없습니다.
인간이 트리거 역할을 유지하세요. 검토는 제가 작업물이 준비되었다고 결정할 때 실행되며, 제 승인 없이는 어떤 것도 고객에게 전달되지 않습니다.

만약 비슷한 것을 구축하고 있거나, 에이전트의 작업을 검증 가능한 방식으로 만들 다른 방법을 발견했다면, 댓글로 알려주시면 감사하겠습니다.