에이전트는 코드를 잘 쓰는데, 왜 머지할 때마다 불안할까?

난테 스튜디오는 에이전트가 코드를 쓰는 날이 훨씬 많습니다. 최근 30일 동안 메인 저장소에만 커밋이 587개 들어갔고, 그중 대부분은 에이전트가 썼어요. 그런데 머지 버튼을 누르는 순간은 여전히 사람이 불안합니다.

그런데 어느 날부터 GitHub에 사람 리뷰가 남은 PR이 거의 없다는 걸 확인했습니다. 에이전트는 머지 전에 리뷰했다고 말하지만, 그 기록이 남지 않거나 사람이 따라가지 못하는 날이 늘었습니다. 읽는 시간이 남지 않으니까요.

그래서 Lauren Tan(@poteto)이 Grok Bot으로 PR을 수천 개 낸다고 말할 때, 숫자보다 환경이 궁금했습니다. 감시로 신뢰하는 게 아니라 주방을 만들어 신뢰한다는 이야기였습니다. 난테 스튜디오가 아키텍처 시리즈에서 이미 잡아 둔 린트와 훅, CLI, 출시 파이프라인과도 많이 겹쳤습니다. 이번 글에서는 강연 네 편에서 읽은 메커니즘을 먼저 풀고, 저희 공장과 어디가 같은지 공유하려고 합니다.

먼저 본 영상 네 편

겹치는 내용이 있지만 역할이 다릅니다. 시간을 나누려면 이렇게 보면 됩니다.

• How I Shipped 2000 PRs (약 38분) - 전체 모델이 한자리에 있습니다. 신뢰 사다리, 검증, 규칙 올리는 순서, Dune, 바깥 루프와 안쪽 루프.
• Matt Pocock LIVE (약 65분, 10월 2일) - PR 수가 약 2,500까지 올라간 시점의 대화입니다. 먼저 머지하고 나중에 샘플링하기, 검증 에이전트 무리, 스크립트와 스킬을 나누는 기준.
• Dune 리팩터 워크숍 (중국어 자막본) - 신뢰 곡선, Benny라는 버그 재현 봇, 스킬에 평가가 필요한 이유, 원자적 PR.
• MTS 인터뷰 (약 29분) - 가장 이른 강연입니다. 데모와 Benny의 시작, 에이전트는 취향을 대신하지 않고 곱한다는 말.

시작점이 된 X 글은 여기입니다.

신뢰는 감시에서 오지 않습니다

네 편을 관통하는 한 줄은 이겁니다. 에이전트 출력을 믿을 수 있게 만드는 방법은, 에이전트를 더 자세히 보는 게 아닙니다. 좋은 출력이 자연스럽게 나오게 환경을 짜는 일입니다.

비유는 미슐랭 주방이 잘 맞았습니다. 헤드 셰프가 모든 숟가락을 맛봐서 접시가 일정한 게 아닙니다. 스테이션, 준비, 레시피, 패스에서의 확인이 이미 맛을 시스템에 넣어 둡니다. 셰프는 샘플을 보고 주방을 고칩니다.

감시는 반대입니다. 한 사람이 매 단계를 지켜보고, 그날의 집중력이 품질이 됩니다. 봇이 하나여도 버티기 어렵고, 무리가 되면 더 어렵습니다.

그림 1. 왼쪽은 사람이 병목입니다. 오른쪽은 환경이 대부분을 검사하고, 사람은 샘플을 맛보고 주방을 고칩니다.

질문을 바꾸면 손이 갑니다. "이 에이전트를 믿을까?"보다 "이 주방을 믿을까?"가 주마다 손볼 수 있는 질문에 가깝습니다.

신뢰는 사다리입니다

강연에서 신뢰는 켜고 끄는 스위치가 아니라 사다리로 나옵니다. Dune 워크숍에서는 곡선이라고도 부릅니다. 증거가 쌓일수록 한 칸씩 올라갑니다.

1. 로컬 - 내 머신에서, 사람이 가까이 봅니다.
2. 검증 - 눈만이 아니라 도구와 다른 에이전트가 확인합니다.
3. 클라우드 - 검증이 믿을 만하면 백그라운드에서 돌립니다.
4. 자동 머지 - 실적이 쌓인 종류의 작업만, 매번 사람 승인 없이 들어갑니다.

그림 2. 한 칸씩 올라가고, 검증 칸은 건너뛸 수 없습니다. 사다리는 에이전트마다가 아니라 작업 종류마다 따로입니다.

의존성 버전만 올리는 일과 아키텍처를 건드리는 일은 같은 칸에 두면 안 됩니다. 위 칸으로 보내는 조건은 검증이 그 종류에서 실제로 막아주느냐입니다.

검증이 첫 스킬입니다

실무에서 제일 먼저 옮길 문장은 이겁니다. 에이전트에게 더 많은 일을 가르치기 전에, 자기 일을 검사하게 만드세요.

첫 강연에서 검증은 나머지 모델이 앉는 바닥입니다. ControlGlass 같은 실행과 추적 도구도 그 맥락에서 나옵니다. Matt Pocock과의 대화에서는 검증 에이전트를 여러 두고, 작업을 나눠 주는 코디네이터 에이전트까지 이야기합니다.

한도가 바뀝니다. 에이전트가 코드를 얼마나 쓰느냐가 상한이 아닙니다. 얼마나 검증할 수 있느냐가 상한입니다. 생성은 싸졌고, 옳다는 확신이 아직 비쌉니다. 사고가 나면 프롬프트를 탓하기보다, 환경이 왜 못 막았는지부터 보게 됩니다.

규칙은 어디에 둘수록 잘 지켜질까

첫 강연의 실용적인 순서는 이렇습니다. 코드베이스 자체가 실수를 막게 하고, 그다음 정적 분석과 CI, 그다음 규칙과 스킬, 마지막이 스타일입니다.

그림 3. 위가 더 강한 벽입니다. 규칙 파일의 한 문장은 제안이고, 린트는 벽이며, 잘못된 import가 애초에 안 되는 구조는 벽에 부딪히기도 전에 끝나는 길입니다.

에이전트도 사람도 제안보다 벽을 더 잘 따릅니다. 리뷰 코멘트로만 남는 규칙은, 가능하면 한 칸 위로 올리는 편이 맞습니다.

Dune은 쉬운 길을 올바른 길로 만듭니다

Dune은 Lauren이 Grok Bot Electron 클라이언트를 다시 짜며 쓴 작업 제목입니다. 설계 원칙은 한 줄입니다. 쉬운 길이 올바른 길이어야 한다.

강연에서 보이는 구체적 장치는 대략 이렇습니다.

• 기능 단위로 코드를 모아 두어, 에이전트가 저장소를 헤매지 않게 합니다.
• Electron의 메인과 렌더러 import 경계를 빌드가 막습니다. 섞이면 리뷰가 아니라 빌드 문제가 됩니다.
• 의존성 그래프를 CI에서 검사합니다. 구조가 문서가 아니라 검사입니다.
• 에이전트가 자주 남기는 패턴을 금지합니다. 코드를 정당화하는 주석, 남용하기 쉬운 React 훅 같은 것들입니다.

Dune 쪽으로 옮긴 리팩터 PR만 600개가 넘는다고 합니다. 목표가 분명하고 검사 가능하면, 에이전트가 잘하는 "정원 가꾸기" 작업의 예입니다.

프레임워크를 새로 만들 필요는 없습니다. 우리 코드베이스에 물을 한 줄만 던져 보면 됩니다. "에이전트가 여기서 제일 게으른 길을 고르면, 그 끝이 괜찮은가?"

스킬, 평가, Benny

스킬은 특정 일을 위해 에이전트가 불러 쓰는 재사용 지시입니다. Lauren 쪽 묶음은 pstack이라고 부릅니다. 강연에서 남긴 두 가지는 이렇습니다.

• 스킬에는 평가가 필요합니다. "이 스킬이 X를 잘하게 한다"는 주장입니다. 평가 없이 쓰면 짐작입니다.
• 결정 가능한 단계는 CLI나 스크립트로 두고, 판단이 필요한 부분만 스킬에 둡니다. 모델에게 스크립트가 매번 할 수 있는 일을 맡기지 않습니다.

Benny는 버그를 재현하는 봇입니다. MTS 강연에 시작 이야기가 있고, Dune 워크숍에서도 다시 나옵니다. 고치기 전에 버그가 있고 재현된다는 걸 증명하는 일, 즉 검증 작업의 예로 보기 좋습니다.

원자적 PR도 같은 줄기입니다. 작고 한 가지 목적만 가진 변경은 검증과 되돌리기, 샘플링이 쉽습니다. 봇이 여러 대면 더 그렇습니다.

바깥 루프와 안쪽 루프

첫 강연은 일을 두 루프로 나눕니다.

• 바깥 루프: Grok Bot 루틴. 예약되거나 이벤트로 도는 일. 작업 집기, 정리, 분류, PR 열기.
• 안쪽 루프: Cursor. 사람과 에이전트가 가까이서 편집하는 루프.

그림 4. 바깥은 반복되는 일을 계속 돌리고, 안쪽은 취향과 새 패턴을 다듬습니다. 안쪽에서 익힌 맛은 다시 환경으로 돌아갑니다.

어떤 일은 사람이 의자에 있어야 하고, 어떤 일은 그냥 계속 일어나야 합니다. 둘을 섞으면 감시로 돌아갑니다.

먼저 머지하고, 나중에 샘플링하기

Matt Pocock 대화에서 가장 오래 걸리는 문장입니다.

흔한 흐름은 에이전트가 PR을 열고, 사람이 리뷰하고, 머지하는 순서입니다. PR이 수천이면 그 리뷰가 병목입니다. 신뢰 사다리를 오른 종류의 작업에서는 순서를 뒤집습니다. 검증을 통과한 변경은 먼저 들어가게 두고, 사람은 들어간 뒤 샘플을 봅니다. 주방이 아직 좋은 접시를 내는지 확인하는 일에 가깝습니다.

샘플에서 문제가 보이면 그 PR 하나만 고치는 게 아니라, 검사와 경계를 조입니다. 사람 역할이 문지기에서 품질 검사로 옮겨집니다.

이 말은 앞의 검증과 원자적 PR, 강한 강제 순서가 있을 때만 성립합니다. 바닥 없이 "먼저 머지"만 가져가면 희망에 가깝습니다.

에이전트는 취향을 곱합니다

MTS 강연의 문장입니다. 에이전트는 취향을 대신하지 않고 곱합니다.

안심이 되면서도 부담입니다. 판단은 여전히 필요하고, 배수기는 양쪽으로 작동합니다. 취향이 흐리거나 머리 속에만 있으면 그 흐림도 곱해집니다. 할 일은 취향을 머리 밖으로 꺼내 구조, CI, 스킬, 평가에 넣는 일입니다.

난테 스튜디오 공장과 어디가 겹칠까

저희는 2천 개 PR을 목표로 두지 않습니다. 다만 이미 같은 질문을 공장 쪽에 던져 왔고, 아키텍처 시리즈에 측정값을 남겨 두었습니다.

그림 5. 아키텍처 6편에서 정리한 관문입니다. 명령 실행 전 훅, 측정값이 있는 커밋 메시지, PR 검사, 그다음 머지입니다.

공개된 숫자만 다시 적으면 이렇습니다.

• 최근 30일 커밋 587개. 사람 한 명이 전부 읽고 리뷰할 수 없습니다.
• PR마다 도는 검사 목록이 402줄, 린트 스크립트가 124개입니다. 품질은 리뷰 문장보다 검사가 막는 쪽에서 지킵니다.
• 사고 하나가 규칙이 되고, 규칙이 린트가 됩니다. 이미 있던 위반은 기준 목록에 넣고 새 위반만 막습니다. 기준 목록은 줄어드는 쪽으로만 자유롭게 움직이게 두었습니다.
• 사내 CLI는 최상위 명령 41개, 하위 명령 446개입니다. 지난 30일 동안 컴퓨터 네 대에서 71,980번 실행됐고, 대부분은 에이전트가 실행합니다. 결정 가능한 운영은 CLI로 두고, 에이전트는 그 위를 쓰게 한 셈입니다. 자세한 이야기는 3편에 있습니다.
• 출시 빌드는 에이전트 세션에서 빼 두었습니다. 세션은 요청만 하고, 집에 있는 빌드 PC가 깨끗한 환경에서 빌드해 스토어에 올립니다. 출시 작업 136건이 그 큐를 지나갔습니다. 7편입니다.

강연의 말로 옮기면 이렇게 겹칩니다. 린트와 훅은 강제 순서의 위쪽 칸입니다. CLI는 결정 가능한 일을 스크립트에 둔 쪽입니다. 스킬 묶음과 파이프라인 안내 문서는 에이전트에게 올바른 경로를 알려 주는 칸이고, 검증이 약하면 그 칸만으로는 부족합니다. 출시 큐는 바깥 루프에 가깝고, 새 패턴을 정하는 편집은 안쪽 루프에 가깝습니다.

아직 약한 쪽도 있습니다. 스킬마다 평가가 붙어 있지는 않습니다. "먼저 머지하고 샘플링"은 검증이 더 쌓인 종류의 작업에만 열어 두려고 합니다. Benny처럼 고치기 전에 재현을 강제하는 습관도, 일부 경로에만 있습니다.

비슷한 불안을 겪고 있다면

에이전트 출력이 늘수록 머지가 불안해진다면, 먼저 작업 종류 하나를 고르세요. 의존성 업데이트나 작은 정리처럼 검증하기 쉬운 일입니다. 그 종류만 로컬 칸에 두고, 검사가 실제로 막을 때만 한 칸 올립니다.

리뷰에 반복해서 남는 문장이 있으면, 린트나 CI나 import 경계로 올릴 수 있는지 물어보세요. 올릴 수 있으면 올리는 편이 감시보다 싸게 먹힙니다.

스킬을 쓰기 전에, 그 단계가 스크립트로 끝나는지 보세요. 매번 같은 입력이면 CLI가 맞고, 판단이 필요할 때만 스킬이 맞습니다.

고치기 전에 재현을 한 번 두세요. 실패하는 테스트나 재현 절차가 없으면 머지하지 않는 습관만으로도, 검증 칸이 두꺼워집니다.

마치며

강연에서 가져온 건 도구 이름이 아니었습니다. 질문의 위치였습니다. "이 에이전트를 믿을까?" 대신 "믿을 수 있는 주방을 만들었을까?"

그 질문은 느리고, 자극도 적습니다. 그래도 경계 하나, 검사 하나, 평가 하나씩은 주마다 답할 수 있습니다. 난테 스튜디오 공장도 그 속도로 쌓아 온 쪽에 가깝습니다.

Lauren Tan이 공개적으로 풀어 준 덕분에 저희 쪽 관문을 다시 이름을 붙여 볼 수 있었습니다. 영상은 이 요약보다 낫습니다. 시간이 있으면 워크숍과 2천 PR 강연부터 보면 됩니다.