📚 지식 노트

발표자: Cursor 개발자. 이전에는 Meta React 팀에서 React Compiler를 만들었고, Netflix에서 테크 리드와 엔지니어링 매니저로 일했다. 아래 내용은 영상을 보고 정리한 요약이다.

한 줄 요약

에이전트를 믿을 수 있어야 많이 맡길 수 있고, 믿음은 말이 아니라 검증과 강제 장치로 쌓는다.

신뢰 곡선 — 매니저와 팀원의 관계와 같다

팀원을 믿지 못하는 매니저는 어깨 너머로 모든 일을 확인하는 마이크로매니징에 빠진다. 에이전트도 같다. 출력 하나하나를 지켜보고 있으면 에이전트를 몇 개 이상 늘릴 수 없다. 하나도 못 믿는데 백 개를 띄울 수는 없으니까요.

발표자는 이 곡선을 오르는 데 지름길이 없다고 강조한다. 아직 첫 단계인데 에이전트 수백 개를 띄우면 토큰만 낭비한다.

① 검증(verification)이 가장 중요한 기술

검증은 에이전트가 직접 앱을 실행하고 확인하는 능력다. 사용자가 앱을 쓰는 방식 그대로 에이전트도 쓸 수 있게 한다. 웹·Electron 앱은 Chrome DevTools Protocol(CDP), iOS 앱은 시뮬레이터 도구를 쓴다. 그러면 에이전트가 화면을 조작하고, CPU 트레이스와 힙 스냅숏도 직접 찍는다.

• 검증이 좋은 코드를 보장하지는 않지만, 적어도 맞는 코드는 보장한다.
• 검증 수단이 없으면 사람이 검증자가 된다. 직접 빌드를 열어 보고, 스크린숏과 콘솔 오류를 복사해 건네야 한다. 사람이 병목이 되어 병렬화할 수 없다.
• 검증 수단이 없을 때 에이전트는 트레이스 스크린숏만 보고 원인을 자신 있게 단정했다. 하지만 대개 틀렸다.

feature map — 에이전트에게 주는 앱 지도

앱을 조작할 수 있어도 에이전트는 어떤 기능이 어디에 있는지 몰라 헤맸다. 그래서 기능마다 다음을 적은 문서를 둔다.

• 사용자 입장에서 그 기능에 가는 길
• 하위 기능과 키보드 단축키
• CDP로 고를 때 쓰는 DOM 속성(선택자)

이 지도가 있으면 “???”만 적힌 스크린숏 같은 엉성한 버그 리포트도 해당 기능에 연결해 재현할 수 있다. 발표자는 이 지도를 만드는 스킬과 최신으로 유지하는 스킬을 따로 둔다.

② 관찰한 실패를 스킬로 만든다

에이전트가 원인을 단정했는데 도구 호출 기록을 보니 관련 코드를 읽지도 않았던 일이 있었다. 이때 “못 믿겠다”로 끝내지 않고 그 실패를 스킬로 만들었다. 예를 들면 “추측하지 말고 코드를 찾아 읽어라, 하위 에이전트를 써라” 같은 것이다.

• 에이전트는 실력은 좋지만 업무 맥락이 전혀 없는 신입과 같다. 스킬은 그 신입에게 주는 온보딩 문서다.
• 좋은 입력(고품질 토큰)을 주면 모델이 더 높은 수준의 패턴에 맞춰 답한다.
• 처음에는 수동적으로 지켜보지 말고 적극적인 조수석 운전자가 되어야 한다. 도구 호출과 생각 과정을 열어 어디서 틀리는지 찾고, 찾을 때마다 스킬로 만든다.
• 이런 스킬을 하나씩 모은 것이 발표자의 플러그인(pstack)이 되었다.

스킬은 eval로 관리한다

eval은 에이전트용 단위 테스트다. 특별한 프레임워크 없이도 만들 수 있다.

1. 코디네이터 에이전트가 “스킬이 해야 할 일”의 채점 기준(루브릭)을 만든다.
2. 하위 에이전트 여러 개를 각자의 폴더에서 돌린다. 폴더 이름은 평가임을 눈치채지 못하게 짓는다. 에이전트는 평가받는다는 걸 알면 행동이 달라진다.
3. 다른 모델로 심판(judge) 을 두어 채점 편향을 교차 확인한다. 쓰는 여러 모델에서 모두 돌려 본다.
4. 점수가 나오므로 /loop로 “모두 10점이 될 때까지” 반복해 스킬을 다듬을 수 있다(hill climbing).

스킬을 고칠 때마다 eval을 다시 돌린다. 그래도 스킬 유지에는 결국 취향과 관찰이 많이 필요하다고 한다.

로컬에서 시작해 클라우드로

처음에는 에이전트가 앱을 어떻게 다루는지 눈으로 볼 수 있는 로컬에서 시작한다. 검증 스킬이 믿을 만해지면 클라우드 에이전트가 같은 스킬로 일하게 한다. 그러면 개인이 아니라 팀 전체가 득을 본다.

예를 들어 버그 리포트가 들어오면 클라우드 에이전트가 자기 컴퓨터에서 앱을 띄워 재현한다. 그리고 “재현되지만 main에서는 이미 고쳐졌으니 새 빌드만 내면 된다” 같은 결과를 사람이 손대기 전에 알려 준다.

비유하면 엔지니어는 이제 주방장다. 요리를 직접 다 하지 않고, 주방(환경)을 설계하고 일을 나눠 준다.

③ 제약과 아키텍처 — 가장 짧은 길이 가장 좋은 길이 되게

바이브 코딩으로 빨리 만든 새 프로젝트(그린필드) 가 가장 위험하면서도 기회가 크다고 한다. 가드레일이 없으면 에이전트는 매번 가장 편한 방법으로 문제를 풀고, 시간이 지나면 아무도 이해하지 못하는 코드가 된다. 반대로 큰 회사의 오래된 코드베이스는 “가장 덜 숙련된 사람도 사고를 못 치게” 만든 프레임워크·관례·권한 제한이 이미 있어서, 에이전트도 꽤 잘 해낸다.

발표자는 새 앱을 600개가 넘는 PR로 엄격한 구조(사내 코드명 Dune)로 다시 짰다. 그 뒤로는 코드를 거의 직접 보지 않는다. 디자이너·PM도 안심하고 기능을 더한다.

강제의 층

무른 층만 있으면 코드베이스는 시간문제로 엉망이 된다고 한다. 그래서 단단한 층에 투자한다.

• 금지 예시: React useEffect 사용을 CI에서 막는다. 코드 주석도 금지한다. 에이전트가 쓰는 주석은 대부분 코드와 상관없는 과거 이야기이기 때문이다. 예를 들어 그 PR에만 한 말을 영구 규칙처럼 주석으로 남긴다.
• 원칙: 에이전트는 지름길을 좋아하므로, 가장 짧은 길이 곧 가장 좋은 길이 되도록 구조를 짠다.
• 같은 리뷰 코멘트를 반복한다면 코드 냄새다. 코멘트 대신 lint 규칙·CI 실패로 바꾸거나, 그 문제가 아예 생길 수 없게 만든다.
• 엄격한 컴파일러(예: Rust)는 “컴파일되면 대체로 맞다”는 신뢰를 준다. 기술 스택 선택도 중요하다.
• PR은 작고 원자적으로 나눈다. git 이력이 좋은 맥락이 되고, 문제가 생기면 그 PR만 되돌리면 된다.

Q&A에서 나온 것

• 토큰 비용: 처음 구조를 다시 짜고 검증을 붙이는 데 토큰이 많이 든다. 하지만 사람을 더 뽑는 것과 비교한 ROI로 판단하라고 한다. 혼자서는 몇 년 걸릴 일이고, 구조가 잡히면 작은 모델도 일을 잘 해낸다.
• 다른 직군: 엄격한 구조 덕분에 PM·디자이너가 직접 고친 버그도 리뷰해 보면 바로 승인할 수 있는 수준이었다.

이 사이트에 적용하면

이 사이트도 같은 생각을 작게 따르고 있다.

• 실패를 단단한 검사로: 조용히 무시되던 Web Audio 코드와 정의되지 않은 함수 호출 같은 지난 버그를 npm run check의 검사 스크립트로 만들었다.
• 에이전트가 직접 검증: 기능을 고치면 headless Chrome(CDP)으로 페이지를 열어 픽셀·콘솔 오류까지 확인한다.
• 함정 기록: 페이지마다 밟았던 함정을 docs/에 적어 다음 작업이 같은 실수를 하지 않게 한다. 이것은 무른 층이라, 되풀이되는 함정은 테스트로 옮긴다.