Cursor 엔지니어의 한 달 PR 1,000개 — 에이전트를 믿게 만든 건 프롬프트가 아니라 코드베이스였습니다

한 줄 핵심

에이전트를 믿게 만드는 핵심은 프롬프트가 아니라 검증 가능한 도구, 이를 반복적으로 고치는 스킬, 그리고 에이전트가 실수하기 어려운 코드베이스 설계다.

시간별 요약

1. 0:00
   오프닝 — 한 달에 PR 1,000개, 그리고 매니저와 신입 한 달에 PR 1,000개를 처리하는 수준까지 에이전트 활용이 올라왔고, 그 배경에는 매니저처럼 에이전트를 다루는 방식과 신입을 온보딩하듯 시스템을 설계하는 관점이 있다.
2. 1:23
   신뢰 곡선: 하나도 못 믿으면 백 개는 못 띄운다 에이전트 출력을 일일이 감시하는 단계에서는 병렬화가 불가능하지만, 신뢰가 쌓이면 여러 에이전트의 PR을 자동 병합할 수 있는 수준까지 올라간다.
3. 2:40
   첫 번째 답 → 가장 중요한 스킬은 검증이다 에이전트와 함께 일할 때 가장 중요한 역량은 코드 실행, CPU 트레이스, 힙 스냅샷, 시뮬레이터 구동처럼 실제 환경에서 검증하는 능력이다.
4. 3:37
   검증을 깨달은 계기 — CPU 트레이스와 힙 스냅샷 성능 문제를 분석하려면 실행 흔적과 메모리 상태를 직접 봐야 하며, 추측만으로는 에이전트도 사람도 병목을 풀지 못한다.
5. 4:01
   입사 첫 주 디버깅 실패, 그리고 첫 스킬 첫 주의 디버깅 실패 경험은 검증 스킬의 필요성을 드러냈고, Chrome DevTools나 iOS 시뮬레이터를 제어해 실제로 실행·관찰하는 기능이 에이전트 신뢰의 출발점이 됐다.
6. 6:10
   앱을 띄워줘도 에이전트가 헤맨 이유 앱을 실행시켜도 에이전트가 어디를 봐야 하는지 모르면 여전히 헤매기 때문에, 실행만으로는 충분하지 않고 기능 위치를 안내하는 추가 맥락이 필요하다.
7. 6:36
   피처 맵: 기능까지 가는 길을 적어둔 파일 피처 맵은 기능별 진입 경로, 키보드 단축키, 선택자 정보까지 담아 에이전트가 모호한 사용자 제보나 스크린샷만으로도 기능 위치를 찾아가게 만든다.
8. 8:29
   스킬은 어떻게 만들어졌나 스킬은 에이전트의 반복적인 실패 양상을 관찰하고, 그 실패를 줄이는 지침을 마크다운 형태로 축적하면서 점진적으로 만들어진다.
9. 8:51
   환각을 본 날, 신입에게 주듯 스킬을 썼다 에이전트가 자신 있게 틀리는 순간은 신입 엔지니어를 교육하듯 구체적인 절차와 탐색 규칙을 주어야 하는 신호이며, 추측 대신 검색·하위 에이전트 활용을 강제하는 방향으로 스킬이 진화한다.
10. 11:16
    스킬을 최신으로 유지하는 법 → eval 은 스킬의 유닛 테스트 스킬 변경은 eval로 검증해야 하며, 여러 모델과 하위 에이전트를 동원해 루브릭 기준으로 점검하면서 스킬이 의도대로 작동하는지 계속 확인해야 한다.
11. 14:04
    그 검증은 어떻게 믿나 → 점수·심판 모델·/loop eval 점수만 보지 말고 다른 모델의 심판 역할을 더해 편향을 줄여야 하며, /loop로 반복 개선해 점수가 충분히 높아질 때까지 밀어붙이는 방식이 유효하다.
12. 15:26
    로컬에서 시작해 클라우드로 처음에는 로컬에서 제어 스킬을 다듬고, 신뢰가 쌓인 뒤에야 클라우드 에이전트로 확장하는 단계적 접근이 필요하다.
13. 15:44
    Benny: 버그를 스스로 재현하는 클라우드 에이전트 Benny는 클라우드에서 버그 리포트를 재현해 수정 여부를 확인해 주며, 사람이 직접 오래 붙잡고 확인하던 시간을 크게 줄여 준다.
14. 17:26
    관점 전환 — 이번엔 에이전트가 아니라 코드베이스 에이전트 성능만 볼 것이 아니라, 에이전트가 실수하기 어려운 코드베이스 구조 자체를 설계해야 한다는 관점으로 논의가 이동한다.
15. 17:43
    Rewrite 논쟁과 브라운필드, 그리고 인간 슬롭 기존 코드베이스는 보통 생각보다 품질이 낮고, 대규모 조직은 이미 약한 엔지니어도 망치지 못하게 하는 가드레일을 갖추고 있어 에이전트에도 유리하다.
16. 20:10
    위험한 쪽은 새 프로젝트 완전히 새로 바이브 코딩한 프로젝트는 가드레일이 거의 없어서 에이전트가 편한 방식으로만 풀다가 코드베이스가 통제 불능이 되기 쉽다.
17. 20:21
    가드레일 없는 바이브 코딩, 아침 PR 20개 강한 제약과 CI를 갖춘 코드베이스를 만들면 에이전트가 많은 PR을 자동으로 처리할 수 있고, 그 상태에 도달하기까지는 대규모 리팩터링과 토큰 투자가 필요하다.
18. 22:44
    발표자가 건너뛴 설계도 (화면 속 문서 읽기) 설계 문서를 보면 에이전트 친화적 아키텍처의 의도와 규칙이 더 분명해지며, 실제 구현보다 설계 원칙을 이해하는 데 도움이 된다.
19. 24:35
    Dune: CI 가 전부 검사한다 Dune에서는 use effect를 금지하고, 코드 주석도 제한하는 등 CI가 세세한 규칙을 강제해 에이전트가 흔히 저지르는 실수를 원천 차단한다.
20. 26:14
    금지보다 센 것 — 기능 하나 = 디렉토리 하나 기능별 코드를 한 디렉토리에 모으는 등 강한 구조적 제약을 두면 에이전트가 기존 패턴을 그대로 따라가므로 탐색 비용과 실수 가능성이 줄어든다.
21. 28:01
    룰 파일은 세 번째 층부터 룰과 스킬 같은 소프트한 규칙은 유용하지만, 그것만으로는 부족하므로 더 강한 하드 제약 위에 쌓아야 한다.
22. 28:16
    레이어 5개: 하드(코드·정적 분석) vs 소프트(룰·스킬 코드 구조, CI, lint, 컴파일러 진단 같은 하드 제약이 우선이고, 룰과 스타일 가이드는 보조 수단으로 써야 하며, 문제가 반복되면 인간 리뷰 대신 lint나 CI 실패로 승격해야 한다.
23. 31:07
    PR 은 얼마나 크게 PR에는 하드 캡을 두지 않더라도 가능한 한 작고 원자적으로 나누는 편이 히스토리를 맥락으로 활용하고 롤백하기 좋다.
24. 31:18
    상한 없음, 아토믹 PR, git 히스토리가 컨텍스트 작은 PR은 변경 의도를 선명하게 남겨 주고, 문제 발생 시 원인을 빠르게 좁힐 수 있어 에이전트 작업과도 잘 맞는다.
25. 32:04
    그래서 토큰은 → ROI, 사람을 뽑을까 토큰을 쓸까 초기 토큰 비용은 크지만, 코드베이스를 강하게 재구성해 인력 대신 에이전트가 안정적으로 일하게 만들 수 있다면 그것이 더 나은 ROI가 될 수 있다.
26. 34:51
    정리 — 검증 → 스킬 → eval → 코드베이스 에이전트를 믿게 만드는 순서는 검증 기능을 만들고, 실패를 스킬로 고치고, eval로 유지하며, 마지막에는 코드베이스 자체를 에이전트 친화적으로 바꾸는 것이다.

실무 인사이트

• 에이전트 도입의 첫 과제는 프롬프트 개선이 아니라 실제 실행·관찰·재현이 가능한 검증 경로를 만드는 것이다.
• 반복적으로 틀리는 패턴은 스킬로 축적하고, 그 스킬은 eval로 회귀 테스트해야 유지보수가 가능하다.
• 에이전트 생산성을 높이려면 모델을 더 똑똑하게 만들기보다, 기능 경로를 단순화하고 CI·lint·디렉토리 구조로 하드 가드레일을 거는 편이 효과적이다.