Fable을 이기는 ‘짧은 목줄’ AI 코딩 방법

17 hours ago 1

보안 중요 소프트웨어에서 AI 코딩 에이전트를 쓰려면 자율 실행을 맡기기보다, 개발자가 변경을 계속 통제하는 Short Leash 방식이 필요함
여러 에이전트가 병렬로 코드를 만들고 검토하는 “vibe”식 접근은 코드베이스 이해를 약화시키고, AI가 off the rails 상태가 된 뒤에야 문제를 발견하게 만들 수 있음
핵심 절차는 계획 수립, 단계 분해, 권한 프롬프트의 diff 검토, 잦은 거부와 개입, 하위 작업별 커밋, 마지막 리뷰로 이어짐
PR 리뷰에서는 AI와 인간을 함께 써야 실수를 줄일 수 있으며, AI는 흔한 오류를 빠르게 잡고 인간은 더 높은 수준의 문제와 방향을 판단함
AI가 작성에 관여한 PR은 제출자가 한 줄씩 직접 검토하고, PR 설명에 사용한 모델을 AI Disclosure로 명시해야 신뢰를 얻을 수 있음

AI 코딩 에이전트를 쓰기 위한 전제

이 방법은 보안 중요 시스템에서 고품질 소프트웨어를 만들기 위한 AI 에이전트 사용 경험을 바탕으로 함
대상은 AI를 학습의 적으로 봐야 하는 초보 개발자가 아니라, 자신의 전문 영역에서 “frontier AI models”보다 뛰어난 전문 개발자임
목표는 AI를 성능 향상 도구로 쓰면서도 소프트웨어 품질을 희생하지 않는 것임
경험의 범위에는 AI 에이전트 한계 탐색, 자체 AI 리뷰 도구 제작, AI 코딩 에이전트 Crush의 커스텀 포크 유지가 포함됨

AI 에이전트를 쓰는 세션에서는 두 가지 문제가 자주 생길 수 있음
- 처음 아이디어가 나쁘고 더 나은 접근이 있다는 사실을 뒤늦게 발견함
- 에이전트가 원하지 않는 방향으로 off the rails 상태가 됨
여러 병렬 에이전트와 오케스트레이터가 동시에 작업하고 개발자가 코딩 과정에서 빠지면, 코드베이스 이해를 직접 쌓기 어려워짐
품질을 신경 쓰지 않는 상황에서는 이런 방식도 괜찮을 수 있지만, 품질이 중요한 경우에는 다른 접근이 필요함
Fable 5가 작성하거나 검토한 코드는 동작하더라도 비효율적이고 보기 나쁠 수 있음
모델이 의존할 훈련 데이터가 적은 니치 영역에서는 이런 문제가 더 자주 생길 수 있음
특정 CEO들의 마케팅과 달리, 이 관점에서는 모델이 훈련 데이터 너머로 사고할 수 없음

Short Leash 방식은 아무나 쓸 수 있는 방법이 아니며, 전문 소프트웨어 개발자에게 맞춰져 있음
frontier model을 쓰지 않아도 Fable을 이기는 결과를 낼 수 있다는 점이 장점임
작업 전에는 계획 단계에서 과제를 조사하고 계획을 세움
- 큰 작업은 tasks skill 같은 도구로 진행 상황을 추적하고 단계로 나눔
- 이 부분은 여러 “vibe engineering” 방식과 공통점이 있음
이후의 핵심은 AI를 계속 짧은 목줄에 묶어두는 것임
- “YOLO” 모드 또는 “dangerously skip permissions”를 쓰지 않음
- 사용자가 게임을 하는 동안 AI가 혼자 일하게 두지 않음
- 권한 프롬프트에서 적용 예정 변경의 diff를 보여주는 코딩 에이전트를 사용함
- 개발자가 AI가 제안하는 변경을 실제로 분석함
- 권한 프롬프트의 diff로 코드베이스 이해를 최신 상태로 유지하고 AI를 통제함
- AI가 원치 않는 작업을 하려 하면 권한을 거부함
- 필요할 때 자주 개입해 AI가 방향을 잃지 않게 함
하위 작업이 끝날 때마다 커밋을 만들어, AI가 이전 작업을 망치거나 삭제하는 상황을 막음
- 이런 일이 실제로 발생할 수 있으며, Opus에서 본 사례가 있음
마지막 단계에는 리뷰를 수행함

PR 작성에 AI가 쓰였다면 PR 설명의 AI Disclosure 섹션에 사용한 정확한 모델을 공개해야 함
이 공개에는 여러 목적이 있음
- 유지관리자에게 AI 사용 사실을 알림
- 약한 모델을 썼다면 더 나은 모델을 제안할 수 있게 함
- AI를 몰래 들여오려는 것이 아니라는 신호를 줌
AI를 사용한 PR은 반드시 PR “작성자”가 직접 리뷰해야 함
AI 보조 PR은 실제로는 인간 도움을 받은 AI의 PR에 가깝기 때문에, 제출자는 자신이 제출하는 내용을 이해해야 함
제출자는 자신의 PR을 다른 사람의 PR처럼 보고 line-by-line으로 직접 리뷰해야 함
자체 리뷰가 끝난 뒤에는 자신의 승인을 확인하고 유지관리자에게 검토를 요청할 수 있음
이 과정은 제출자가 코드베이스를 이해하고 있음을 만들고 보여주는 역할을 함