도구가 자기 자신을 감사했을 때 벌어진 일
AI 코딩 도구를 팀에 도입할 때 우리가 가장 많이 놓치는 질문이 있다. "이 도구가 생성한 코드를, 누가 어떤 방식으로 검증하는가." 최근 오픈소스 프로젝트 SeamStress의 사례는 그 질문을 아주 직접적인 방식으로 건드린다.
SeamStress는 AI 코딩 에이전트가 실수하기 쉬운 '경계 지점(seam)'—돈, 인증, 테넌트 격리가 교차하는 곳—을 집중 리뷰하는 코드 심사 도구다. 개발자 Nate는 여기서 한 발 더 나아가, AI 에이전트에 설치하는 행동 프로토콜 모음인 'SeamStress Scaffold'를 함께 만들었다. 그리고 자신이 세운 원칙대로 행동했다. 코드 리뷰어를 자기 자신의 도구에 겨냥했다.
결과는 냉정했다. 리포지터리를 스캔해 리스크 파일 지도를 만드는 CLI에서, 신뢰되지 않은 입력이 신뢰된 컨텍스트로 넘어가는 구조적 결함이 발견됐다. 파일명에 마크다운 메타문자가 포함될 수 있다는 사실을 스캐너가 전혀 검증하지 않았고, 조작된 파일명으로 에이전트가 '신뢰된 문서'로 인식하는 섹션에 악의적 텍스트를 심을 수 있었다. 9개 발견, 그 중 3개 크리티컬. 가장 심각한 것은 적대적 리포지터리가 에이전트의 신뢰 컨텍스트에 텍스트를 주입할 수 있는 경로였다.
여기서 핵심은 취약점 자체가 아니다. 이 버그는 세 개의 파일이 각각 분리된 상태로는 아무 문제가 없었다는 점이다. 스캐너는 경로를 읽는다. 렌더러는 마크다운으로 쓴다. 프로토콜은 결과를 신뢰하라고 지시한다. 파일 하나하나는 정상이다. 조합이 문제다. AI가 만들어내는 많은 취약점이 바로 이 패턴이다.
'빠른 실수'가 더 비싸지는 곳
dev.to에 올라온 블록체인 엔지니어링 관련 분석은 이 문제를 다른 각도에서 다룬다. ChatGPT, Claude 같은 AI 어시스턴트로 스마트 컨트랙트를 분 단위로 생성할 수 있는 시대가 됐다. 문제는 속도가 아니라 블록체인이라는 환경 자체다.
스마트 컨트랙트는 배포 후 수정이 사실상 불가능하다. 2016년 DAO 해킹, 2022년 Wormhole·Ronin Bridge·Nomad Bridge 공격—이 사건들의 공통점은 문법 오류가 아니라 로직 레벨의 실수였다. 잘못된 접근 모델, 부적절한 트랜잭션 처리, 프로토콜 경제 구조의 설계 결함. AI는 컴파일도 되고 기본 테스트도 통과하는 코드를 생성할 수 있다. 하지만 코드가 '전문가답게 보인다'는 것이 '안전하다'는 뜻이 아니다.
이 분석이 지적하는 '보안 부채(security debt)' 개념은 팀 리드가 진지하게 받아들여야 한다. AI로 빠르게 작동하는 코드를 얻는 동시에, 런칭 이후에야 드러날 숨겨진 리스크를 함께 쌓고 있을 수 있다. 기술 부채와 달리 보안 부채는 이자가 갑자기, 그리고 한꺼번에 청구된다.
컨텍스트가 끊기는 순간이 취약점이 심어지는 순간이다
SeamStress의 Scaffold 프로토콜 문서에는 이런 문장이 있다. "AI 보조 개발은 정확히 seam 버그에 필요한 조건을 제조한다. 많은 빠른 세션, 각각 로컬에서는 정확하지만, 전체를 붙잡고 있는 세션은 없다." 이것은 단순한 수사가 아니라 구조적 진단이다.
Claude Code에서 컨텍스트 롤오버 없이 세션 상태를 관리하는 프로토콜을 설계한 개발자 Semih Erdogan의 사례가 이 문제를 실무 관점에서 보완한다. 그는 자동 압축(/compact)을 비활성화하고, 대신 AI가 직접 HANDOFF.md를 작성해 다음 세션에 정확한 상태를 넘기는 구조를 설계했다. 핵심은 "히든 서머리를 신뢰하는 것이 아니라, 내가 통제할 수 있는 파일을 신뢰한다" 는 원칙이다.
그가 가장 중요하게 여기는 섹션은 Failed Attempts / Avoid다. 성공한 작업은 diff에 남는다. 실패한 시도는 누군가 기록하지 않으면 사라진다. 그리고 다음 AI 세션은 이미 실패한 접근을 다시 시도하느라 시간을 낭비한다. 컨텍스트 경계가 바로 SeamStress가 말하는 'seam'이다.
팀이 설계해야 할 검증 루프
세 사례를 겹쳐보면 패턴이 보인다. AI 코딩 도구의 리스크는 도구 자체의 성능 한계보다 팀이 검증 구조를 설계하지 않았을 때 발생한다. 실용적으로 정리하면 세 레이어다.
첫째, 경계 지점을 명시적으로 정의하라. AI가 빠르게 만들어낸 코드에서 위험한 것은 단일 파일이 아니라 파일 간 결합이다. 돈, 인증, 외부 입력이 교차하는 지점을 팀이 먼저 지도로 만들어야 한다. SeamStress의 접근—리스크 파일 지도를 먼저 생성하고 에이전트에 참조시키는 방식—은 팀 단위로 도입 가능한 패턴이다.
둘째, AI로 AI를 검증하는 루프를 설계하라. SeamStress의 'blind trio' 방식—세 개의 크리틱, 신선한 컨텍스트, 공유 상태 없음, 다른 모델—은 단일 AI 리뷰어의 맹점을 보완한다. 한 모델이 학습 데이터의 패턴을 따라 놓친 것을 다른 모델이 cold 상태로 잡아낼 수 있다. 이건 이론이 아니라 이 사례에서 실제로 작동했다.
셋째, 세션 경계를 명시적 핸드오프로 관리하라. 컨텍스트 창이 교체될 때 AI가 무엇을 잊는지 팀이 통제해야 한다. HANDOFF.md 같은 구조화된 상태 파일은 단순한 메모가 아니다. 다음 AI 세션이 시작하는 신뢰 컨텍스트를 팀이 직접 설계하는 행위다.
감사자를 감사하는 것이 워크플로우다
Nate가 남긴 문장이 계속 머릿속에 남는다. "AI 보조 코드를 더 안전하게 만든다고 주장하는 도구는 자신의 방법론으로 감사를 받아야 하고, 그 정직한 버전에는 그것이 되지 않았던 부분이 포함된다—수정 전까지는."
AI 코딩 도구를 팀에 도입하는 것은 더 이상 특별한 결정이 아니다. 하지만 그 도구가 생성한 코드의 검증 루프를 설계하지 않는 것은 여전히 선택이다. 그리고 그 선택의 비용은 블록체인에서는 수억 원짜리 취약점으로, 일반 서비스에서는 인증 경계의 조용한 붕괴로 청구된다.
도구가 빠를수록, 검증 설계는 더 먼저 해야 한다. AI-First 워크플로우의 성숙도는 결국 거기서 판가름난다.