AI 감사팀이 실서비스 치명 결함 찾았다

혼자 암호화폐 네트워크를 만들어 운영하는 개발자가 AI 에이전트로 보안 감사 절차를 짜고, 그 절차로 실제 가동 중인 네트워크의 치명적 취약점을 찾아낸 과정을 공개했다. 아토(Atto) 프로젝트의 펠리페 로틸료(Felipe Rotilho)가 8월 18일 블로그에 올린 8분 분량의 기록이다. 더 흥미로운 대목은 뒤에 있다. 이후 새로 나온 코덱스(Codex) 모델이 완전히 다른 경로로 같은 결함을 독립적으로 찾아냈다.

무슨 일인가 / 배경

아토는 실 네트워크에서 일반 거래를 약 202밀리초에 확정한다. 저자는 이를 두고 자신이 아는 범위에서 세계에서 가장 빠른 암호화폐라고 적었다. 자랑스러운 성과지만 불편한 사실이 딸려 있었다. 지갑, 통합 문의, 커뮤니티 지원, 공개 API까지 거의 모든 기술 경로가 한 사람에게 수렴한다는 점이다. 저자는 육아와 본업을 병행하며 이 일을 한다.

돈을 다루는 소프트웨어에서 1인 체제의 진짜 위험은 피로가 아니다. 같은 잘못된 가정이 설계와 구현과 리뷰를 아무 저항 없이 통과해버린다는 것이다. 아토의 노드는 거래와 계정 체인 상태, 투표, 피어 트래픽을 검증한다. 실수 하나가 원장이나 사용자 자금에 닿는다. 전문 감사 업체와 이야기해봤지만 다른 일과 병행해 자비로 굴리는 프로젝트에 감당할 수 있는 금액이 아니었다. 그래서 손에 있는 도구로 1차 방어선을 직접 만들기로 했다.

핵심 짚어보기

첫 시도는 실패했다. 이미 개발에 코덱스를 쓰고 있었으니 '리뷰어를 늘리면 되겠다'는 생각으로 노드를 넓은 영역으로 쪼개 네트워킹, 저장, 합의, 의존성, 설정에 각각 서브에이전트를 붙였다. 문제는 컨텍스트였다. 아토는 다른 암호화폐에 비해 작은 편이지만 AI의 컨텍스트 창을 막기에는 충분히 크다. 네트워킹 질문 하나가 직렬화와 검증, 상태 전이, DB 쓰기, 복구까지 건너간 뒤에야 결함이라 부를 근거가 모인다. 작업자들은 단서를 붙들다 컨텍스트가 차버리거나, 다음 조사에 필요한 증거를 빼먹은 요약만 돌려줬다. 결국 저자 본인이 '어느 질문이 열려 있고 어느 커밋 기준의 주장인지' 기억하는 조정 계층 노릇을 했다. 리뷰어는 늘었지만 감사 절차는 없었던 셈이다.

전환점은 도구를 오픈클로(OpenClaw)에서 헤르메스(Hermes)로 옮기고 칸반 기능을 접한 순간이었다. 카드 한 장을 할 일이 아니라 '컨텍스트 경계'로 쓰기 시작한 것이 해법이었다. 카드마다 구체적인 질문 하나, 정확한 커밋, 관련 파일, 의존성, 증거를 쌓을 디렉터리를 담았다. 작업자는 감사를 만든 대화 전체가 아니라 카드와 앞선 작업의 산출물만 받는다. 탐색 담당은 구조를 훑고 의심 경로만 표시하면 되고, 심각한 단서는 기획 단계에서 새 카드로 쪼개고, 검증과 재현은 최초 리뷰와 분리해 진행했다.

핵심 규율은 이 분할을 '허용'이 아니라 '의무'로 만든 것이다. 후속 카드 생성을 선택지로 두면 작업자들은 대개 혼자 다 끝내려 들었다. 팬아웃을 명시적 단계로 강제한 뒤 탐색 카드 4장이 집중 조사 17건과 재현 과제 6건으로 벌어졌고, 각 경로가 자기 증거와 상태를 따로 유지했다.

감사 방법 자체를 먼저 학습시킨 대목도 눈에 띈다. 저자는 새로운 일을 시킬 때 첫 과제로 '그 일을 어떻게 하는지 배우게 한다'는 규칙을 세워뒀다. 그래서 첫 과제는 아토 점검이 아니라 코드 감사 방법을 익혀 스킬 문서로 만드는 일이었다. 결과물은 code-auditor라는 별도 프로필과 두 개의 스킬이었다. 하나는 커밋을 고정하고 구조와 위협 모델을 그린 뒤 '결함'과 '보강 아이디어'를 구분하며 증거와 검증 경로를 요구한다. 다른 하나는 잔액 보존, 계정 순서, 투표 처리, 재생 공격 경계, 영속성처럼 아토에 중요한 불변식을 덧붙인다. 감사 중 저장소는 읽기 전용으로 두고, 보고서와 로그와 재현 코드만 별도 디렉터리에 쓰게 했다.

그렇게 정착된 절차가 찾아낸 것은 보강 제안 수준이 아니었다. 일부 수신 투표 경로가 서명을 검증하기 전에 투표 안에 담긴 대표자 공개키를 신뢰하고 있었다. 이미 실 네트워크에서 돌고 있던 합의 취약점이었다.

1인기업 실전 적용 포인트

• 에이전트를 늘리기 전에 절차를 만들어라. 서브에이전트 5개에 영역만 나눠주면 조정 부담이 사람에게 돌아온다. 먼저 '탐색 → 분해 → 개별 조사 → 검증 → 보고' 5단계를 문서로 고정한 뒤 각 단계에 에이전트를 배치한다.
• 작업 카드에 컨텍스트를 봉인하라. 질문 1개, 커밋 해시, 파일 목록, 증거 저장 경로를 카드마다 적는다. 대화 이력이 아니라 산출물만 다음 단계로 넘기면 컨텍스트 폭발과 '어느 버전 얘기인지 모르는' 혼선이 함께 사라진다.
• 팬아웃을 선택이 아닌 의무로. 프롬프트에 '단서를 발견하면 직접 파지 말고 새 작업으로 분리한다'를 명령형으로 넣는다. 이 한 줄이 탐색 4건을 조사 17건으로 벌린 장치였다.
• 작업 대상은 읽기 전용으로 잠근다. 진단 중인 에이전트에게 수정 권한을 주지 않는다. 원인 규명 전에 코드를 손보면 무엇이 문제였는지가 증거와 함께 지워진다.

전망 / 주의점

이 사례를 'AI가 사람 감사를 대체한다'로 읽으면 위험하다. 저자 자신이 보안 감사는 도구 호출처럼 모델에 기본 내장된 능력이 아니라고 못박았다. 모델은 코드를 많이 읽고도 신뢰 경계를 놓치고, 보강 제안을 취약점으로 착각하고, 도달 불가능한 위험해 보이는 경로를 보고한다. 워크플로가 제대로 물리기까지 여러 번의 시도와 조정이 필요했다는 서술도 그대로 남아 있다.

그래도 방향은 분명하다. 예산 때문에 외부 감사를 포기하던 1인 프로젝트가 '전문 감사의 대체'가 아니라 '상시 1차 방어선'을 손에 넣었다는 점, 그리고 서로 다른 모델이 독립적으로 같은 결함에 도달했다는 점은 이 절차가 우연이 아니었음을 보여준다.

출처: Atto Blog (https://atto.cash/blog/age-of-continuous-audits)