AI 에이전트를 신뢰할 수 있게 만들기: 검증, 강제 제약, 관례 기반 아키텍처

한 줄 요약: AI 에이전트에게 안심하고 코드를 맡기려면 먼저 에이전트가 자신의 결과물을 직접 검증하게 해야 하며, 사람의 리뷰 대신 CI·lint 같은 강제 제약과 관례 기반 아키텍처를 두어야 신뢰가 차츰 쌓여 에이전트의 PR 자동 병합까지 갈 수 있다.

핵심 포인트

신뢰가 이번 발표의 주제다. 신뢰가 부족하면 소수의 에이전트만 붙어서 지켜봐야 해 병렬화가 안 되고, 클라우드 에이전트를 한꺼번에 많이 띄우면 token만 낭비한다. 그녀는 5개월 동안 신뢰 곡선을 올라 에이전트의 자동 병합을 실현했고, 일어나 보면 20개의 PR이 메인 브랜치에 들어와 있다.
검증이 신뢰의 출발점이다. 검증 스킬이 없으면 사람이 병목이 되므로, 먼저 에이전트에게 애플리케이션을 실제로 조작하는 법(control glass 스킬과 기능 지도)을 가르친다. 이후 eval을 스킬의 단위 테스트로 삼아 계속 개선하고, 그다음에야 클라우드의 Benny가 오류 제보를 자동으로 재현하는 단계로 확장한다.
엔지니어의 역할은 주방장과 같다. 더는 모든 요리를 직접 만들지 않고 환경을 설계하고 일을 배분한다. 출발점은 로컬인데, 에이전트가 어떻게 조작하는지 지켜볼 수 있기 때문이며, 신뢰가 쌓인 뒤에 클라우드와 자동 병합으로 넓힌다.
제약은 강제로 집행될 수 있어야 믿을 만하다. Dune은 useEffect와 코드 주석을 금지하고, CI로 main과 renderer의 import 경계를 검사하며, '가장 짧은 경로가 곧 최선의 경로'라는 관례 기반 아키텍처로 에이전트를 이끈다. rules, skills, bugbot은 부드러운 보완책일 뿐이며, 사람의 리뷰로만 발견된 문제는 매번 lint나 CI 규칙으로 바꿔야 한다.
token 비용은 투자수익률의 문제다. 초기 리팩터링(600개 넘는 PR)에는 token이 많이 들지만, 그 대가로 가장 단순한 에이전트도 잘 해내고 PM과 디자이너까지 안전하게 기여할 수 있다. 다만 그녀가 일하는 연구소는 token에 제한이 없어 모두에게 같은 방식을 요구할 수는 없다.

2026년 9월 15일Vision Sabbat재생 시간 55:04

▶ YouTube에서 원본 영상 보기

구간별 요약

0:25AI 압박과 명세 우선의 첫 실험
그녀는 AI 최고의 활용법은 함께 코드를 쓰는 동료로 삼는 것이지, 코딩을 대체하게 하거나 생각을 외주로 맡기는 것이 아니라고 본다. 많은 엔지니어가 AI를 잘 활용하는 사람으로 보이고 싶어서 매주 PR 100개를 내야 한다는 압박을 받는다. 그녀 자신의 경험으로는 AI를 쓰면 코드 작성 시간은 줄지만 오히려 리뷰와 수정에 더 많은 시간을 쓴다. 또 AI에게 먼저 명세를 쓰게 하고 명세를 검토한 뒤 개발하는 유행 방식도 시도해 보았다.
▶ 여기서부터 보기
1:25신뢰, 장기간 쌓인 관점과 곡선
주제는 신뢰다. 시니어 엔지니어는 많은 관점을 쌓아 왔기에, 에이전트가 짐작으로 답하고 환각을 일으키면서도 근본 원인을 찾았다고 자신만만하게 말하는 모습을 보면 신뢰를 잃고, 신뢰가 부족하면 에이전트의 가치를 발휘할 수 없다. 이는 부하를 믿지 못하는 매니저가 마이크로매니징만 하게 되는 것과 같다. 약 1년 전 에이전트로 코드를 쓰는 사람이 드물던 때에는 소수의 에이전트만 붙어서 지켜봐야 했고 병렬화도 불가능했다. 지난 5개월 동안 신뢰 곡선을 올라 지금은 에이전트가 PR을 자동 병합하며, 일어나 보면 20개의 PR이 이미 메인 브랜치에 들어와 있고 품질도 괜찮다. 그녀의 기여 그래프는 이 곡선과 서로 대응한다. 첫 달 산출은 낮았고, 지난달 병합된 PR 수는 놀라울 정도였으며, 이번 달은 12일 전에 이미 800개에 가깝다.
▶ 여기서부터 보기
5:55검증이 가장 중요한 능력
에이전트 워크플로에서 그녀가 가장 중요하다고 보는 기술은 검증이다. 에이전트가 코드를 실제로 실행하고, CPU trace나 heap snapshot을 수집하고, iOS 시뮬레이터를 열어 사용자처럼 직접 조작하고 테스트할 수 있어야 한다. 이렇게 하면 루프가 닫힌다. 좋은 코드를 쓴다는 보장은 없지만 적어도 올바른 코드를 쓸 수 있으며, 이는 신뢰를 쌓는 데 큰 한 걸음이다.
▶ 여기서부터 보기
7:25Cursor 경력과 에이전트에게 화면 보는 법 가르치기
그녀는 5개월 전 Cursor에 합류했다. 원래는 클라우드 에이전트 팀에 들어갈 예정이었으나 React 경험이 있어서 같은 React 앱인 agents window를 지원하도록 배치되었다. 첫 주에 그녀는 Chrome DevTools의 플레임 그래프를 직접 봐도 이해하지 못했고, 에이전트도 이해하지 못한 채 자신 있게 엉뚱한 원인을 짚기만 했다. 검증 스킬이 없으면 사람이 병목이 되어 스크린샷과 오류 메시지를 직접 복사해 에이전트에게 건네야 한다. 그래서 그녀는 control glass 스킬을 만들었다(Glass는 agents window의 내부 코드명이다). 이 스킬은 Chrome DevTools Protocol이나 Apple의 시뮬레이터 도구를 통해 애플리케이션을 조작하도록 에이전트에게 가르친다. 그러나 에이전트는 조작은 할 수 있어도 창 안에 어떤 기능이 있는지 몰라서 별도의 기능 지도가 필요했다.
▶ 여기서부터 보기
11:40기능 지도, Pstack, 스킬 평가
기능 지도에는 각 기능에 어떻게 도달해 조작하는지, 키보드 단축키, CDP용 선택 속성이 적혀 있어서, 에이전트는 품질이 아주 나쁜 제보(예를 들어 스크린샷에 물음표만 있는 것)를 받아도 해당 기능을 찾아낼 수 있다. Pstack 플러그인에는 검증 스킬을 만들고 유지하는 기능이 들어 있다. Pstack이라는 이름은 Y Combinator CEO Gary Tan의 GStack을 놀린 것이며(두 사람은 성만 같고 무관하다), 미리 계획한 것이 아니라 에이전트의 실패 패턴을 관찰해 하나씩 스킬로 써 내려가며 쌓인 것이다. 스킬은 본질적으로 markdown이며, 아무 배경지식이 없는 신입에게 가르치는 것과 같다. 스킬 유지는 eval, 즉 에이전트의 단위 테스트로 한다. 조정 에이전트가 채점 기준을 정하고 여러 하위 에이전트를 투입하되(평가받는 중임을 일부러 알리지 않는다), 다른 모델의 심판 에이전트가 교차 검토하며, 만점 10점이 나올 때까지 계속 반복할 수 있다. 하지만 그녀는 스킬 유지가 어렵고 안목과 관찰이 필요하다고 털어놓는다.
▶ 여기서부터 보기
22:35주방장 비유: 로컬 도입에서 클라우드 에이전트까지
그녀는 주방장 비유로 역할의 변화를 설명한다. 엔지니어는 더는 모든 요리를 직접 만들지 않고 주방 환경을 설계해 팀에 일을 나눠 준다. 도입은 로컬에서 시작하는데, 에이전트가 CLI나 데스크톱 앱을 띄우고 인터페이스를 어떻게 호출해 조작하는지 지켜볼 수 있기 때문이다. 그녀 자신은 주로 클라우드 에이전트에 베팅했다. Benny라는 에이전트가 모든 오류 제보를 넘겨받아 클라우드 데스크톱에서 Cursor를 실행하고, 같은 제어 스킬로 문제를 재현한다. 예를 들어 표시 오류는 재현되지만 메인 브랜치에서는 이미 고쳐져 있으니 새 버전만 배포하면 된다고 알려 주는 식이다. 이는 팀 전체에 도움이 되지만, 반드시 먼저 신뢰를 쌓아야 하며 클라우드 에이전트를 한꺼번에 많이 띄워 token을 낭비해서는 안 된다.
▶ 여기서부터 보기
27:15회고와 맹목적 신뢰 경계
인터뷰어는 경로를 되짚는다. 먼저 검증 스킬을 만들어 코드가 적어도 올바른지 확인하고, 로컬에서 신뢰를 쌓은 뒤 클라우드로 확장해 에이전트가 직접 제보를 넘겨받아 PR을 올리게 하며, 마지막에야 자동 병합을 거쳐 메인 브랜치 리뷰로 간다는 것이다. 그녀는 동의하면서, 신뢰는 개인의 기준에 달려 있으므로 이 길에는 지름길이 없다고 말한다. 또 누구도 자신을 맹목적으로 신뢰하지 않기를 바란다고 한다. 플러그인이 시작을 빠르게 해 주지만, 각자 자기만의 스킬 세트로 개조해 자신의 엔지니어링 기준을 스킬에 적고 에이전트가 실제로 지키는지 검증하라고 권한다.
▶ 여기서부터 보기
29:35재작성 논쟁과 코드 드리프트
그녀는 재작성을 고려할 가치가 있다고 주장한다. 기존 프로젝트에 이미 프레임워크, 관례, 가드레일이 있다면 에이전트가 꽤 잘 해낼 수 있는데, 대기업이 가장 역량이 낮은 엔지니어까지 챙기려고 이런 제약을 일찌감치 만들어 두었기 때문이다. 새로 만드는 프로젝트는 가장 큰 위험이자 가장 큰 기회다. 완전히 새로 개발한 Grockbot의 경우 전적으로 vibe coding에 의존해 사람이 코드를 읽지 않으면 가드레일이 전혀 없고, 에이전트가 가장 편한 방식으로 과제를 해결해 코드가 오래되면 통제 불능이 된다. 그래서 그녀는 600개가 넘는 PR을 들여 Grockbot을 새 아키텍처로 리팩터링했고, 지금은 코드를 거의 보지 않는다. token이 많이 들었지만, CI에 제약이 많아 에이전트가 코딩의 번거로움을 흡수하므로 디자이너나 PM 같은 비엔지니어도 안심하고 기능을 추가할 수 있다.
▶ 여기서부터 보기
35:25규모에 맞는 강제 집행과 PR 크기
CI와 PR 크기에 대한 질문에 그녀는 엄격한 상한은 없다고 답한다. 크기는 약 50줄부터 시작해 내용에 따라 훨씬 커질 수 있는데, 예를 들어 파일을 대량 삭제하는 PR은 거의 전부가 삭제다. 그래도 그녀는 에이전트에게 작업을 여러 PR로 나누라고 요구한다. 각 PR이 단순한 작은 변경만 설명하게 하면 git 히스토리가 풍부한 맥락이 되고 되돌리기도 쉬워, 40000줄짜리 PR에 무엇이 들어 있는지 모르는 일이 생기지 않는다. 덧붙이면 Grockbot과 Cursor의 가상화는 새 라이브러리 Pretext가 구동한다.
▶ 여기서부터 보기
38:15Dune과 관례 기반 아키텍처
Dune은 Grockbot 아키텍처의 내부 코드명으로, Electron 앱용 Next.js라고 생각하면 되며 에이전트의 코딩을 위해 설계되었다. CI 검사가 성가실 만큼 많다. useEffect를 금지하고 코드 주석도 금지하는데, 그녀가 보기에 99%의 경우 에이전트가 쓴 주석은 코드와 무관한 이력 서술이기 때문이다. Electron의 renderer는 60 fps를 유지해야 하므로 프레임마다 16밀리초 안에 끝내야 하고, 무거운 연산이 실수로 renderer에 들어가면 버벅거린다. 그래서 이런 경험을 프레임워크에 써 넣어 하드 실패로 만들었다. electron main과 electron renderer 디렉터리를 분리하고, CI가 의존성 그래프를 검사해 디렉터리 간 import를 금지한다. 그녀는 가장 강력한 강제 계층이 관례 기반 아키텍처이며 에이전트가 기존 패턴을 복사하기 좋아하기 때문이라고 본다. 예를 들어 하나의 기능에 속한 모든 코드를 같은 디렉터리에 두면 작업의 약 80%가 대체로 그 안에 들어간다.
▶ 여기서부터 보기
43:35최단 경로, 경계, 소프트 규범
그녀의 첫째 원칙은 가장 짧은 경로가 곧 최선의 경로라는 것이다. 에이전트는 지름길을 좋아하므로 가장 빠른 방법이 곧 가장 좋은 방법이 되게 하는 편이 낫다. 이 프레임워크는 일련의 아이디어와 원칙일 뿐이어서 오픈소스로 공개하지 않는다. 강제는 여러 층으로 나뉜다. CI 검사, 관찰된 나쁜 패턴에 맞춰 쓴 lint, 컴파일러 진단은 모두 CI를 빨갛게 만드는 강제 제약이다. rules, skills, bugbot은 더 부드러워서 에이전트가 여전히 잊을 수 있으므로 겹쳐 쓸 뿐 이것들만 믿어서는 안 되며, 그러면 코드는 조만간 쓰레기가 된다. 기술 선택도 중요하다. 예를 들어 Rust 컴파일러는 엄격해서 unsafe 블록만 금지하면 컴파일 통과만으로도 어느 정도 확신을 가질 수 있다. 매번 사람이 코드 리뷰에서 제약을 지적한다면 그것은 나쁜 징후이며, lint 규칙이나 CI 실패로 바꾸거나 아예 문제를 근본에서 없애야 한다.
▶ 여기서부터 보기
49:45Token 투자수익률과 제품 부서 동기화
엔지니어링 책임자에게 token은 투자수익률의 문제다. 초기에 코드를 리팩터링하고 제약을 세우는 데 token이 많이 들지만, 에이전트가 코딩을 맡으면 10000명 규모의 엔지니어링 조직으로 커질 필요가 없다. 이 일들은 에이전트 시대 이전이라면 그녀 혼자 몇 년이 걸렸을 것이므로, 선택은 사람을 고용할 것인가, 아니면 token을 써서 가장 단순한 에이전트도 잘 해내게 할 것인가이다. 그녀는 자신이 일하는 AI 연구소는 token에 제한이 없어 모두에게 같은 방식을 요구할 수 없다고도 털어놓는다. 제품 같은 부서가 어떻게 따라오느냐는 질문에는 Grockbot이 열쇠라고 답한다. 인터페이스가 iMessage 같아서 비기술 인력도 에이전트를 쉽게 쓸 수 있고, PM과 디자이너가 직접 수정 PR을 올리기도 하며, 그녀가 리뷰해 완벽하다 싶으면 바로 승인한다. 이는 Dune 아키텍처의 엄격한 제약이 비전문가도 높은 수준으로 기여하게 해 준다는 것을 보여 준다.
▶ 여기서부터 보기