이 포스트는 보안이 중요한 시스템 (security-critical systems)에서 고품질 소프트웨어를 작성하기 위해 AI 에이전트 (AI agents)를 어떻게 적절하게 사용할 것인가에 대한 1년 이상의 연구의 결실입니다.

저는 주로 소프트웨어 개발자, 프로토콜 개발자, 그리고 보안이 중요한 소프트웨어의 유지보수자 (maintainer)로서의 관점에서 이 포스트를 작성할 것입니다.

지난 1년 동안 저는 AI 에이전트 (AI agents)를 깊이 파고들었습니다. 저는 그들의 한계, 즉 무엇을 신뢰할 수 있고 무엇을 신뢰할 수 없는지를 탐구했습니다. 저는 수십억 달러 가치의 AI 리뷰 시스템 (AI-review systems)만큼이나 잘 작동하는 우리만의 AI 리뷰 도구들을 만들었습니다. 저는 Crush라고 불리는 AI 코딩 에이전트 (AI coding agent)의 커스텀 포크 (custom fork)를 직접 유지보수해 왔습니다. 그리고 이 포스트는 AI 도구를 사용하여 고품질 소프트웨어를 만들고자 할 때 가장 좋은 접근 방식이 무엇인지에 대해 제가 배운 것들을 정제한 결과물입니다.

AI를 싫어하는 사람들이 있습니다. 실제로 많은 개발자들은 AI를 싫어해야 마땅합니다. 왜냐하면 AI는 소프트웨어 개발 학습에 있어 적이기 때문입니다. 이 포스트는 그들을 위한 것이 아닙니다. 이 포스트는 자신의 전문 분야에서 그 어떤 "프론티어 AI 모델 (frontier AI models)"보다 뛰어난 실력을 갖춘 소수의 전문가 개발자들을 위한 것입니다. 저는 품질을 전혀 희생하지 않으면서 성능을 높이는 방법으로서 AI를 사용하고자 하는 이 전문가 개발자들을 위해 이 포스트를 씁니다.

현재 접근 방식의 문제점

AI 에이전트 (AI agents)를 많이 사용해 보셨다면, 세션이 진행되는 동안 다음과 같은 일이 발생할 수 있다는 것을 알고 계실 것입니다:

• 당신의 초기 아이디어가 어리석었으며 더 나은 아이디어가 존재한다는 것을 발견할 수 있습니다.
• 에이전트가 "궤도를 벗어나 (off the rails)" 당신이 원하지 않는 일을 하기 시작할 수 있습니다.

저는 유튜버들이 오케스트레이터 (orchestrator)에 의해 관리되는 12개의 병렬 에이전트 (parallel agents)로 구성된 복잡한 시스템을 어떻게 발명했는지, 그리고 그것이 어떻게 동시에 수십억 가지의 일을 수행하는지 설명하는 수십만 조회수의 영상들을 보았습니다. 그들이 어떻게 더 이상 코딩 과정에 관여할 필요가 없게 되었는지에 대해서도 말입니다. 그것은 유튜버가 해변에 앉아 있거나, 화장실에 가거나, 아무 이유 없이 커피를 마시는 동안 그저 쓰레기 (slop)를 쓰고 쓰레기를 리뷰하는 것에 불과합니다.

이러한 "Vibe" 방식(Vibe approach)을 사용한다면 코드베이스에 대한 자신만의 이해를 구축하는 것은 인간으로서 불가능합니다. AI는 여러 번 경로를 이탈할 것이며, 당신은 실제로 소프트웨어를 사용하려고 시도할 때가 되어서야 비로소 그 사실을 알아차리게 될 것입니다. 이 방법은 품질에 신경 쓰지 않는 상황에서는 완벽하게 괜찮을 수 있지만, 만약 당신이 품질을 중시한다면, 다른 접근 방식이 필요합니다.

문제는 Fable 5가 작성하거나 리뷰한 코드조차도 형편없을 것이라는 점입니다:

코드는 작동하지만, 지독하게 비효율적이고 추합니다. 그리고 모델이 의존할 수 있는 학습 데이터(training data)가 많지 않은 일종의 니치(niche) 영역에서 작업하고 있다면 이런 일은 확실히 더 자주 발생할 것입니다. 특정 CEO들이 하는 마케팅 문구와는 반대로, 이 모델들은 자신들의 학습 데이터 너머를 생각할 수 없습니다.

AI 코드 생성 — "Short Leash" 방법론

이것이 우리를 AI 코딩 에이전트(AI coding agents)를 사용하는 "Short Leash(짧은 목줄)" 방법론으로 안내합니다.

이 방법은 아무나 채택할 수 있는 것이 아닙니다. 오직 전문 소프트웨어 개발자만이 이 방법을 사용할 수 있습니다. 하지만 이 방법의 훌륭한 점은 당신이 최첨단 모델(frontier model)을 사용하지 않더라도 Fable을 능가하는 결과를 이끌어낼 수 있다는 것입니다.

Short Leash 방법론에서는:

• 작업을 조사하고 계획을 수립하기 위해 계획 단계 (planning phase)를 사용하며, 진행 상황을 추적하고 큰 작업을 단계별로 나누기 위해 나의 'tasks skill'과 같은 기능을 사용합니다 (이는 많은 "vibe engineering" 방식과 공통된 점 중 하나입니다. 접근 방식은 다음 불렛 포인트들에서 달라집니다.)
• 절대 "YOLO" 모드 (즉, "위험하게 권한을 건너뛰는 방식")를 사용하지 않습니다.
• AI가 "당신이 비디오 게임을 하는 동안" 혼자 작업하게 두지 않습니다.
• 권한 승인 프롬프트 (permissions prompt)를 통해 곧 적용될 변경 사항의 diff를 보여주는 코딩 에이전트 (coding agent)를 사용합니다.
• 20세기의 광기 어린 사람처럼 앉아서, AI가 제안하는 변경 사항을 실제로 분석합니다.
• (유튜버들이 조장하는 트렌드처럼) 자신을 배제하는 대신, 항상 루프 안에 머무릅니다 (keep yourself in the loop).
• 권한 승인 프롬프트의 diff를 코드베이스에 대한 이해를 최신 상태로 유지하고, AI를 "짧은 목줄 (short leash)"로 통제하는 수단으로 사용합니다.
• AI가 원치 않는 행동을 하려는 것을 발견할 때마다 즉시 권한을 거부 (DENY) 합니다.
• AI가 "궤도를 벗어나는 것 (going off the rails)"을 방지하기 위해 빈번하게, 그리고 필요할 때마다 개입합니다.
• 항상 AI는 "짧은 목줄에 묶여 (kept on a short leash)" 있어야 합니다.
• AI가 이전에 완료된 작업을 망가뜨리거나 삭제하여 사용자를 보호하기 위해, 모든 하위 작업 (subtask)이 끝날 때마다 커밋 (commit)을 수행합니다 (이런 일은 실제로 일어날 수 있으며, 저는 Opus가 그렇게 하는 것을 본 적이 있습니다).
• 마지막으로, 리뷰를 수행합니다.

AI 리뷰를 수행하는 방법

인간만 리뷰하거나 AI만 리뷰한 PR (Pull Request)은 인간과 AI가 모두 리뷰한 PR보다 더 많은 실수를 포함하게 됩니다.

AI는 린터 (linter)처럼 취급될 수 있습니다. AI는 흔한 실수들을 빠르게 잡아내고, 인간은 더 높은 수준의 문제와 필요한 방향성 전환을 잡아낼 것입니다.

따라서 리뷰에 있어서는:

• 모든 PR(Pull Request)을 검토하는 데 AI를 사용해야 합니다.
• AI는 충분한 컨텍스트(이슈, PR 설명, 코드베이스, 변경 사항 등)에 접근할 수 있어야 합니다.
• 검토 시에는 가장 최신이고 뛰어난 모델들을 사용해야 합니다.
• PR 설명에는 PR 작성 과정에서 도움을 받은 정확한 모델들(사용된 경우)을 “AI 공개(AI Disclosure)”라는 제목 아래 명시해야 합니다. 이는 여러 목적에 기여합니다:
• AI가 사용되었음을 유지보수자에게 알려줍니다.
• 약한 모델이 사용되었다면 더 나은 모델을 제안할 수 있게 합니다.
• 개발자가