에이전트를 믿을 수 있는 환경 만들기

신뢰가 병렬화를 막는다

에이전트를 쓰는 단계는 동시에 맡기는 에이전트 수로 나눌 수 있다.

단계	모습
1~5개	대화마다 지켜보며 계속 방향을 고친다. 사람이 자리를 비우면 아무 일도 안 되거나 엉뚱한 일이 된다
수십~수백 개	사람이 없어도 에이전트가 높은 품질로 일한다. 개인이나 팀 단위의 「소프트웨어 공장」에 가깝다

첫 단계에서 빠져나오기가 가장 어렵다. 방법이 분명하지 않기 때문이다. 에이전트를 더 늘리지 못하는 이유는 아직 에이전트의 결과를 믿지 못해서다. 믿지 못하는 채로 서브에이전트를 100개 띄우면 엉성한 PR, 회귀, 버그만 쏟아진다. 그래서 질문은 「어떻게 하면 에이전트를 더 믿을 수 있나」가 된다.

처리량은 목표가 아니라 부산물이다. 엔지니어가 가진 지식을 스킬·도구·코드베이스로 에이전트에 옮겨 넣어야 그 엔지니어가 모든 일의 병목이 되지 않고, 그렇게 쌓인 것이 신뢰가 된다.

소프트웨어를 만드는 일은 조립 라인의 대량 생산이 아니라 창작에 가깝다. 에이전트가 재료 손질을 맡아도 최종 요리의 책임은 셰프에게 있고, 셰프의 일은 주방을 꾸리는 것이다. 라인 쿡과 수셰프를 어떻게 배치할지, 어떤 장비와 훈련을 줄지, 설거지 담당은 몇 명을 둘지. 누가 자꾸 무언가에 걸려 넘어진다면 그 사람을 탓하지 않고 걸림돌을 치운다. 코드베이스도 같다.

1. 검증: 에이전트가 자기 일을 확인하게 한다

검증(verification)은 정확성, 즉 기능이 의도대로 동작하는지(결제 버튼이 정말 결제하는지)에 대한 경험적 증거를 준다.

수준	방법
검증 스킬	에이전트에게 앱을 실행하고, Chrome DevTools Protocol 같은 디버깅 프로토콜로 성능 트레이스·힙 스냅샷을 찍고 분석하는 법을 가르친다
형식 검증	Lean, TLA+ 같은 형식 기법으로 비즈니스 불변식이 늘 참임을 증명한다. 훨씬 어렵고 아직 열린 문제다

형식 기법을 쓰지 못해도 검증 스킬만으로 멀리 간다. 사람이 손으로 하던 확인(트레이스 찍기, 힙 스냅샷 보기)을 에이전트가 앱을 직접 띄워 하게 하면, PR이 쏟아지는 속도에 검증이 따라간다.

검증 스킬의 두 부품

부품	역할
CLI	앱 실행·트레이스 수집·증거 확보를 매번 같은 방식으로 한다. 세션마다 스크립트를 새로 짜게 두면 결과가 달라진다. 스킬 폴더 안에 CLI를 두고 다양한 경우를 처리하도록 계속 다듬는다
기능 지도(feature map)	사이트맵처럼 앱에 어떤 기능이 있고, 사용자가 어떻게 도달하는지(단축키, 클릭할 DOM 요소), 각 기능이 무엇을 하는지 적은 물질화된 기억이다. 스킬 폴더에 두고 자동화로 갱신한다

앱을 실행할 수 있어도 기능 지도가 없으면 에이전트는 「스크린샷 + 물음표」 같은 모호한 제보가 무엇을 가리키는지 추측만 한다. CLI(재현 가능한 조작)와 기능 지도(무엇이 어디 있는지)를 합쳐야 에이전트가 사용자의 요청을 이해하고 확인까지 한다.

테스트도 검증 수단이다

테스트는 에이전트가 자기 결과를 확인하는 가장 흔한 수단이다. 투자할 만한 테스트는 다음과 같다.

테스트	에이전트에게 주는 것
E2E 테스트	실제 사용자 흐름을 흉내 내는 테스트를 기준 정답(ground truth) 으로 둔다. 내부 구현이 어떻게 바뀌든 사용자가 겪는 동작이 맞는지 판정한다
속성 기반 테스트	「절대 일어나면 안 되는 일」을 속성으로 적고, 그 제약을 깨뜨리려는 입력을 수천 개 생성한다. 에이전트가 미처 떠올리지 못한 경계 사례를 기계가 찾는다
차등 테스트	시스템을 교체할 때는 무작위로 고른 입력을 옛 버전과 새 버전에 똑같이 넣고 결과를 비교한다. 옛 시스템 자체가 명세 역할을 한다

예시 테스트는 무엇이 일어나야 하는지를, 속성은 무엇이 일어나면 안 되는지를 말한다. 두 가지가 서로를 보완한다. fast-check로 속성을 쓰는 예는 JavaScript 테스트 모범 사례에 있다.

테스트는 빠르고 결정적이어야 한다. 루프가 느리거나 같은 코드에서 결과가 오락가락하면, 에이전트는 문제를 고치는 대신 다시 돌려 보는 법을 배운다. 플레이키 테스트의 원인과 처리는 테스트를 돌리는 시점에 있다.

프런트엔드에서 에이전트가 브라우저로 직접 확인하게 하는 도구는 DevTools의 AI 지원과 에이전트용 DevTools(MCP)에 있다.

2. 품질: 엔지니어처럼 일하게 하는 스킬

검증은 정확성은 알려 주지만 성능이나 코드 품질은 말해 주지 않는다. 그래서 숙련된 엔지니어의 작업 방식을 스킬로 만든다. 디버깅, 기능 개발, 프로토타이핑처럼 작업 종류별 플레이북을 두고, 경험 많은 엔지니어가 팀 공용 스킬 저장소에 기여한다. 이렇게 모은 스킬 묶음을 플러그인으로 배포하기도 한다.

품질 스킬과 검증 스킬을 합치면 에이전트가 「맞게 동작한다」를 넘어 「품질도 좋다」까지 스스로 확인하고, 실제 성능 지표와 텔레메트리를 근거로 내놓는다.

3. 교정할 때마다 고르는 다섯 층

에이전트를 교정할 때마다 「이 교정을 어느 층에 넣는 것이 가장 효과적인가」를 묻는다. 위쪽일수록 강제력이 세다.

층	수단	성격
1. 코드베이스	따라 하기 좋은 기존 패턴	코드베이스가 가장 좋은 기억이다. 에이전트는 있는 것을 따라 한다
2. 아키텍처·자료 구조	자료 구조, 알고리즘, 모듈 경계로 실수 자체를 불가능하게 만든다	가장 확실한 차단이다
3. 정적 분석	린트 규칙, 컴파일러 진단, CI	강제된다. 같은 실수를 반복하면 규칙으로 만든다
4. 규칙·리뷰 봇·스킬	규칙 파일, 자동 코드 리뷰 봇, 스킬	안내다. 대부분 따르지만 읽지 않거나 무시될 수 있다
5. 스타일 가이드	사람의 코드 리뷰	사람만 강제할 수 있다. PR이 쏟아지면 모든 줄을 보고 지적을 기억하는 것이 불가능하다

스타일 가이드와 사람의 리뷰 지적은 무엇이 빠졌는지 찾는 출발점으로 쓰고, 그 내용을 위쪽 층으로 끌어올린다. 가능하면 1~3층에서 막고, 4층으로 덧댄다. 이상 행동을 볼 때마다 규칙을 키우는 방식은 AI로 개발 가속하기의 「Rule-Growing Development」와 같은 방향이다.

코드베이스가 가장 좋은 기억인 이유

에이전트는 보이는 패턴을 확장한다. 맥락 창에 있는 것을 쓰려 하고, 에이전트가 연 파일이 곧 맥락이다. PR마다 코드를 리팩터링하지 않고 이미 있는 것을 따라 늘린다.

이 성질은 양날이다. 작은 우회 코드 하나, 우회를 설명하는 주석 하나가 있으면 에이전트가 그것을 베끼고, 며칠~몇 주 만에 바이러스처럼 번져 사실상의 표준 패턴이 된다. 그래서 교정할 때마다 코드와 정적 분석을 바꾸는 데 시간을 쓴다.

주석은 복제된다

에이전트는 주변 주석을 진짜 문제를 풀지 않는 핑계로 삼아 임시방편을 덧붙이기도 한다. 우회를 설명하는 주석이 우회를 정당화하는 셈이다. 그래서 주석을 아예 금지하는 프레임워크도 있다. 이 판단은 관점이 갈린다.

관점	근거
주석을 금지한다	주석이 우회를 정당화하고, 그 패턴이 복제되어 퍼진다
에이전트용 주석을 둔다	위험 지점·불변식을 코드 옆에 표시하면 에이전트가 건드리지 말아야 할 곳을 안다(AI 코딩 실무 가드레일의 「앵커 주석」)

공통점은 주석이 에이전트의 다음 행동을 바꾼다는 것이다. 어떤 주석을 허용할지는 그 주석이 복제될 때 무엇이 퍼지는지로 판단한다.

4. 에이전트 친화 프레임워크

에이전트는 지름길을 좋아한다. 그러니 지름길, 즉 쉬운 길이 곧 옳은 길이 되게 프레임워크를 설계한다. 사람이 쓰기엔 답답할 만큼 잠겨 있어도, 맥락이 적은 에이전트에게는 완벽한 환경이 된다. 앞으로는 엔지니어만 코드에 기여하지 않는다. 디자이너, PM, CEO가 바쁜 와중에 맥락 없이 에이전트를 몰아도 기본적으로 좋은 결과가 나와야 한다.

에이전트 친화 프레임워크의 원칙은 세 가지다.

원칙	내용
기존 기술 부채를 지운다	남아 있는 나쁜 패턴은 복제의 씨앗이다
포장된 길은 하나	무엇을 하든 관례적인 방법을 하나만 두어 에이전트가 추측할 필요가 없게 한다. 코드베이스·CI·린트가 그 길로 안내한다
나쁜 패턴을 보면 린트 규칙부터	당장 다 고치지 못해도 규칙으로 출혈을 멈춘다. 그다음 에이전트에게 정리를 맡긴다

구체적으로는 코드가 어디에 살고 서로 어떻게 import할 수 있는지에 대한 관례를 촘촘히 둔다. 기능은 한 폴더에 모으고, 진입점(라우트), 대화 화면 조각, VM에서 도는 호스트, 클라이언트 같은 개념 사이에 엄격한 경계를 둔다.

예를 들어 Electron 앱에서 메인 프로세스용 코드를 렌더러에서 import하지 못하게 import 의존성 그래프 검사로 강제하면, 무거운 코드가 렌더러에 섞여 프레임(60fps면 16ms)을 넘기는 성능 문제를 범주째 없앤다.

중요한 것은 특정 프레임워크가 아니라, 팀의 뛰어난 엔지니어들이 리뷰 코멘트로만 전하던 암묵지를 프레임워크와 코드베이스에 새겨 넣는 일이다. 코드베이스는 에이전트가 확장할 상태의 스냅샷이므로, 다음 에이전트가 따라 해도 좋을 만큼 깨끗하게 유지한다. 의존 방향을 설계하는 일반 원칙은 프론트엔드에서 의존성 관리하기에 있다.

에이전트 수를 늘리지 못하는 이유는 신뢰가 없어서다. 신뢰는 환경에서 나온다.
검증 스킬은 재현 가능한 CLI와 기능 지도로 만든다. 에이전트가 자기 일을 증거로 확인하게 한다.
교정할 때마다 코드베이스 → 정적 분석 → 규칙·봇·스킬 순으로 가장 강한 층에 넣는다. 사람의 리뷰는 빠진 것을 찾는 출발점이다.
에이전트는 보이는 패턴을 베낀다. 나쁜 패턴은 번지기 전에 린트로 막고 지운다.
지름길이 옳은 길이 되게 코드베이스를 잠그고, 정원사가 계속 가꾼다.

버그 제보