개발생산성 - analysis_ai

AI 코드 리뷰를 ‘빠른 코드 생성’ 수단이 아닌 PR을 깊게 검토해 코드베이스 건강을 지키는 도구로 활용하는 방법이 있습니다. Nolan Lawson이 직접 구축한 다중 모델 리뷰 전략의 워크플로와 실전 판단 기준을 정리했습니다.

AI 코드 리뷰, “빠르게 많이” 말고 “천천히 제대로”가 정말 가능할까요?

안녕하세요! 여러분은 AI 코딩 도구를 어떻게 활용하고 계세요? 저는 솔직히 한동안 “어떻게 하면 더 빠르게 코드를 뽑아낼 수 있을까”에만 집중했거든요. 그러다 GeekNews에서 Nolan Lawson의 글을 발견하고 생각이 완전히 뒤집혔습니다 😮 “AI로 더 나은 코드를 더 천천히 쓴다”는 제목부터가 기존 통념과 정반대라 눈을 의심했어요. Lawson은 Microsoft Edge 팀에서 오랫동안 일해온 시니어 엔지니어인데, 본인이 직접 Claude skill을 구축하고 실무에 적용한 경험을 아주 솔직하게 공유했습니다.

GeekNews 커뮤니티에서도 “구현은 빠르지만 검토에 시간을 쓴다는 경험이 공감된다”는 반응이 나오는가 하면, “AI 리뷰에 드는 시간이 직접 작성과 비슷할 수 있다”는 회의적 시각도 있었어요. 그래서 직접 원문을 처음부터 끝까지 읽어보고, Lawson이 실제로 어떤 워크플로를 구축했는지 꼼꼼히 정리해봤습니다.

1. AI 코딩의 두 가지 방향 — slop cannons vs. 품질 중심

Nolan Lawson은 AI 코딩 도구를 사용하는 방식이 크게 두 가지로 나뉜다고 말합니다. 첫 번째는 우리가 흔히 “vibe coding”이라고 부르는 방식, 즉 저품질 코드를 빠르게 대량으로 생산하는 접근입니다. 그는 이런 개발자를 “slop cannons”이라고 표현했는데, 검증되지 않은 수백 줄짜리 대형 PR을 쏟아내는 방식이죠. 빠르긴 하지만 코드베이스에 누적되는 기술 부채는 어마어마합니다.

두 번째는 Lawson이 직접 실천하는 방식 — AI를 PR 깊이 검토하는 도구로 활용해 고품질 코드를 천천히 만드는 것입니다. 이 접근은 “10배 생산성”과는 거리가 멀어요. 오히려 코드 한 줄을 추가하기 전에 수십 가지 실패 시나리오를 검토하게 됩니다. Lawson은 LLM이 단순히 코드 생성기가 아니라 매우 유연한 도구라는 점을 강조해요. 목적을 어떻게 설정하느냐에 따라 쓰임새가 완전히 달라집니다.

① Slop Cannon Pattern — 검증 없는 대량 생산 방식

에이전트에게 “이 기능 만들어줘”라고 던지고 400줄짜리 PR을 받아서 바로 머지하는 패턴입니다. 속도는 빠르지만 그 PR이 실제로 어떻게 동작하는지, 어디서 실패할 수 있는지는 아무도 모릅니다. 시간이 지나면 이 “빠른 PR”들이 레거시 코드의 어두운 구석이 되어 기술 부채로 돌아옵니다. Lawson은 이 방식이 단기 속도를 높여줄 수는 있지만 코드베이스 건강을 희생한다는 점을 분명히 합니다.

💡 실제 활용 시나리오 예시:
스타트업 초기 단계에서 마감 압박에 쫓겨 AI가 생성한 OAuth 인증 코드를 검토 없이 머지했다가, 3개월 뒤 보안 감사에서 토큰 만료 처리 로직의 치명적 결함이 발견됐습니다. 당시 PR을 제대로 검토했다면 15분이면 발견할 수 있는 문제였지만, 이미 프로덕션에 배포된 상태라 전체 사용자 세션을 무효화하는 긴급 패치가 필요했습니다.

② Quality-First Pattern — 느리지만 코드베이스를 살리는 방식

AI를 코드 생성이 아닌 코드 검토와 실패 모드 분석에 활용하는 패턴입니다. PR을 머지하기 전에 에이전트에게 “이 코드가 어떻게 동작하는지, 어디서 실패할 수 있는지” 물어보고, 그 답변을 바탕으로 수정과 검증을 반복합니다. 원시 생산성(코드 라인 수)은 늘지 않지만, 코드베이스의 장기적 건강은 극적으로 좋아집니다. Lawson이 강조하는 것은 이 방식이 LLM 이전부터 지향하던 “신중하고 체계적이며 품질에 집착하는 프로그래밍”을 AI로 더 강력하게 만든 형태라는 점입니다.

💡 실제 활용 시나리오 예시:
DB 마이그레이션 PR을 작성한 뒤 에이전트에게 롤백 시나리오와 트랜잭션 실패 케이스를 물어봤더니, 대용량 테이블에서 배타 락이 걸릴 수 있는 상황을 잡아냈습니다. 배포 전에 배치 처리 방식으로 로직을 변경해 수십만 행 테이블에서도 서비스 중단 없이 마이그레이션을 완료한 사례입니다.

2. 버그 탐지보다 더 중요한 것 — 검증과 우선순위

Lawson이 인용한 Mythos 연구는 충격적인 결과를 보여줍니다. LLM 에이전트는 코드베이스에서 버그를 매우 잘 찾을 수 있다는 것인데요, 미검토 코드베이스에서 수많은 버그를 실제로 발견해냈습니다. 최신 Anthropic(Claude)과 OpenAI 모델들은 미묘한 버그 탐지 능력과 오탐 회피 능력에서 약간씩 차이가 있지만, 버그를 찾는 능력 자체는 충분히 검증됐습니다. 여기서 핵심이 있어요.

그런데 진짜 문제는 따로 있습니다. 버그를 찾는 것 자체보다 발견된 버그의 우선순위 지정과 검증이 훨씬 더 어렵다는 거예요. 모델이 100개의 잠재적 문제를 찾았을 때, 어떤 게 실제로 중요한 버그이고 어떤 게 오탐인지, 어떤 순서로 고쳐야 하는지를 판단하는 건 여전히 사람의 영역입니다. 이 판단을 잘 못 하면 중요하지 않은 문제에 시간을 쏟다가 치명적인 버그를 놓치게 됩니다.

① False Positive 문제 — 오탐이 AI 리뷰 신뢰를 무너뜨린다

단일 모델 하나에만 의존해서 버그 리뷰를 하면 오탐률이 높아집니다. 모델이 “이건 버그입니다”라고 보고했는데 실제론 정상 동작인 경우, 개발자는 시간을 낭비할 뿐 아니라 AI 리뷰 자체에 대한 신뢰를 잃게 됩니다. Lawson이 다중 모델 접근을 선택한 핵심 이유가 바로 이것입니다. 여러 모델이 서로 독립적으로 같은 문제를 지적했을 때만 신뢰할 수 있는 버그로 취급하는 방식으로 오탐을 극적으로 줄입니다.

💡 실제 활용 시나리오 예시:
단일 모델 리뷰에만 의존하던 팀이 “SQL N+1 쿼리 문제”라는 보고를 받고 수 시간을 디버깅했지만, 실제로는 ORM이 자동으로 배치 처리를 하고 있어서 전혀 문제가 없었습니다. 이후 두 개 이상의 모델이 동일하게 지적한 항목만 수정하는 정책으로 바꿨더니 AI 리뷰 관련 낭비 시간이 90% 줄었습니다.

② 우선순위 없는 버그 리스트 — 오히려 독이 된다

버그를 많이 찾는 것보다 중요한 버그를 먼저 고치는 판단력이 핵심입니다. Critical 보안 취약점과 “주석이 약간 오해를 살 수 있다”는 Low 이슈를 동등하게 취급하면 안 됩니다. Lawson의 시스템은 Critical/High/Medium/Low 4단계로 엄격히 분류하고, Critical과 High를 먼저 해결하는 것을 원칙으로 합니다. 이 우선순위 체계가 있어야만 AI 코드 리뷰가 실제로 도움이 되는 방향으로 작동합니다.

💡 실제 활용 시나리오 예시:
결제 처리 모듈 PR에서 총 23개의 이슈가 보고됐는데, Critical 2개(인증 토큰 검증 누락, 금액 오버플로우 가능성), High 3개, Medium 8개, Low 10개였습니다. Critical과 High만 먼저 수정하고 배포해서 리드 타임을 절반으로 줄였고, 나머지는 다음 스프린트에서 처리했습니다.

3. 다중 모델 PR 리뷰 Claude skill 구조

Lawson이 직접 구축한 Claude skill의 핵심은 여러 모델을 병렬로 실행해서 교차 검증하는 것입니다. 사용하는 도구는 Claude sub-agent, OpenAI Codex, Cursor Bugbot 세 가지입니다. 각 도구가 독립적으로 PR을 검토한 뒤, 그 결과를 종합해서 오탐을 제거하고 최종 보고서를 만드는 구조죠. “더 많은 모델을 투입할수록 환각이나 잘못된 버그 보고 가능성이 줄어든다”는 원리입니다.

재미있는 점은, 원본 에이전트는 모든 리뷰어가 완료될 때까지 독립적 조사를 진행하지 않는다는 것입니다. 각 모델이 다른 모델의 의견에 영향받지 않고 독립적으로 판단한 뒤, 마지막에 취합하는 방식으로 편향을 줄입니다. 또한 “버그”의 범위는 프로젝트 기준에 맞춰 넓힐 수 있는데, KISS·DRY 원칙 위반, 접근성 있는 HTML/JSX 작성 여부, SQL 쿼리의 인덱스 최적화 여부 등 팀별 품질 기준을 모두 포함시킬 수 있습니다.

① Claude sub-agent — 심층 맥락 이해와 설계 품질

Claude는 코드베이스 전체 맥락을 이해하는 데 강점이 있습니다. 단순히 코드 패턴을 매칭하는 게 아니라, 이 코드가 전체 시스템에서 어떤 역할을 하는지, 다른 모듈과 어떻게 상호작용하는지를 고려해서 버그를 판단합니다. KISS·DRY 원칙 위반, 접근성 있는 HTML/JSX 작성 여부, 팀별 코드 스타일 가이드 준수 여부 같은 설계 품질 기준도 체크합니다.

💡 실제 활용 시나리오 예시:
새로운 API 엔드포인트 PR에서 Claude sub-agent가 “이 로직은 기존 AuthMiddleware와 중복됩니다 — DRY 원칙 위반”을 지적했습니다. 별도로 작성한 100줄 코드를 기존 미들웨어 10줄 호출로 교체해서 유지보수 포인트를 대폭 줄였고, 이후 인증 로직 변경 시 수정 파일이 1개로 줄어들었습니다.

② Codex — 코드 패턴 및 성능 최적화 분석

Codex는 특히 코드 패턴 인식과 성능 최적화 측면에서 강점을 보입니다. SQL 쿼리에 적절한 인덱스를 사용하는지, 불필요한 반복 연산은 없는지, 메모리 누수 가능성은 없는지 같은 실질적인 성능 문제를 잘 잡아냅니다. Claude가 설계 수준의 품질을 보는 것과 보완적인 역할을 합니다.

💡 실제 활용 시나리오 예시:
사용자 검색 기능 PR에서 Codex가 “users 테이블의 email 컬럼에 인덱스가 없어 풀 스캔이 발생합니다”를 지적했습니다. 데이터가 10만 건이 넘는 시점에서 이 문제를 배포 전에 발견해 복합 인덱스를 추가하니 쿼리 시간이 3초에서 20ms로 줄었습니다.

③ Cursor Bugbot — 보안 취약점과 엣지 케이스 포착

Cursor Bugbot은 보안 취약점과 엣지 케이스 처리에 특화돼 있습니다. 입력 검증 누락, XSS 가능성, CSRF 보호 미흡, 예외 처리 불완전 같은 보안·정확성 관련 버그를 중점적으로 검토합니다. 세 도구가 모두 같은 이슈를 지적하면 Critical로 처리하고, 하나만 지적한 경우엔 추가 검증 과정을 거칩니다.

💡 실제 활용 시나리오 예시:
파일 업로드 기능 PR에서 Cursor Bugbot이 “파일 확장자 검증을 클라이언트 측에서만 하고 서버 측 검증이 없습니다”를 Critical로 보고했습니다. Claude와 Codex도 동일하게 지적해서 즉시 수정했고, 서버 측 MIME 타입 검증을 추가해서 임의 파일 실행 취약점을 방지했습니다.

4. 실제 처리 흐름 — Critical에서 Low까지

Lawson의 워크플로는 단순하지만 강력합니다. 핵심은 “심각도 순서대로, 비용 대비 효율을 따져서” 처리한다는 것입니다. 모든 이슈를 다 고치려다 PR이 무한정 늘어나는 함정을 피하는 게 포인트예요. 이게 생각보다 중요한 이유가 있어요 — 완벽주의가 오히려 배포를 막는 상황을 방지해줍니다.

PR 제출
  ↓
다중 모델 병렬 리뷰 (Claude + Codex + Cursor Bugbot)
  ↓
결과 취합 → 오탐 제거 → 최종 보고서 (Critical/High/Medium/Low)
  ↓
Critical/High 이슈 존재?
  ├─ YES (과다·구조적 결함) → PR 전체 접근 방식 재검토 → 폐기 후 재설계
  ├─ YES (수정 가능) → 에이전트로 수정 (사람이 방향 안내) → 재검토 반복
  └─ NO → Medium/Low 선별 처리
          ├─ 수정 비용 < 이득 → 수정
          └─ 수정 비용 > 이득 → 이슈 등록 후 건너뜀 → 머지

1) Critical/High 이슈 반복 수정 루프

Critical과 High 등급 이슈는 에이전트가 수정하되, 적절한 해결책은 사람이 안내합니다. 에이전트에게 “이 부분 고쳐줘”라고만 하면 안 되고, “왜 이게 문제인지, 어떤 방향으로 고쳐야 하는지”를 사람이 판단해서 방향을 제시해야 합니다. 수정 후 다시 리뷰를 돌려서 Critical과 High가 모두 사라질 때까지 반복합니다. 이 루프가 핵심이에요.

💡 실제 활용 시나리오 예시:
인증 모듈 리팩토링 PR에서 첫 리뷰에 Critical 2개, High 4개가 나왔습니다. Critical을 먼저 수정하고 재검토하니 High 2개가 추가 발견됐습니다. 세 번의 반복 끝에 Critical과 High가 모두 0이 됐고, 이후 남은 Medium 이슈만 선택적으로 처리했습니다.

2) 비용 대비 이득 판단 — 건너뛰는 용기

Lawson이 강조하는 중요한 원칙 중 하나는 “수정 비용 대비 이득이 낮은 항목은 과감히 건너뛴다”는 것입니다. 대표적인 케이스가 “좁은 엣지 케이스를 처리하기 위해 100줄의 코드가 필요한 경우”입니다. 이런 경우엔 기술 부채 이슈로 등록하고 일단 넘어가는 게 현명한 판단입니다. 모든 걸 다 고치려는 완벽주의는 배포를 막을 뿐입니다.

💡 실제 활용 시나리오 예시:
데이터 파싱 로직에서 Medium 이슈로 “아랍어·히브리어 RTL 텍스트 혼합 시 특수 케이스 처리 누락”이 보고됐습니다. 해당 케이스는 전체 트래픽의 0.001%에 해당하고 수정에 사흘이 필요해서, 이슈 트래커에 등록 후 건너뛰고 다음 분기에 전담 처리했습니다.

3) PR 폐기 결정 — 포기가 답일 때

가장 드라마틱한 케이스입니다. Critical 문제가 너무 많아서 “전체 접근 방식 자체가 잘못됐다”고 판단될 경우, PR을 통째로 폐기합니다. 이미 많은 시간을 투자했더라도 계속 고집하는 것보다 처음부터 다시 설계하는 게 낫습니다. Lawson은 이것도 AI 코드 리뷰의 중요한 판단 결과라고 말합니다. 손실 회피 편향을 극복하는 게 핵심입니다.

💡 실제 활용 시나리오 예시:
캐싱 레이어 구현 PR에서 Critical 8개가 나왔는데, 대부분 근본적인 캐시 무효화 전략의 설계 결함이었습니다. 개별 수정이 불가능한 구조적 문제라고 판단해 PR을 폐기하고 Redis Pub/Sub 기반의 완전히 다른 아키텍처로 재설계했습니다. 결과적으로 3주를 절약한 셈이 됐습니다.

5. 생산성보다 코드베이스 건강에 집중하는 이유

Lawson의 접근에서 가장 인상적인 부분은 이 방식이 반드시 개발 속도를 높이지 않는다는 것을 솔직하게 인정한다는 점입니다. 코드 라인 수 기준의 생산성은 오히려 줄어들 수도 있어요. 심지어 많은 토큰을 소비한 뒤 처음 계획이 잘못됐다는 결론에 이를 수도 있습니다. 그런데 왜 이 방식을 계속 쓸까요?

리뷰 과정에서 PR 이전부터 이미 존재하던 기존 버그가 발견되기 때문입니다. 이는 단위 테스트 작성과 미묘한 결함 수정으로 이어지고, 장기적으로 코드베이스 전체의 건강을 개선합니다. 복잡한 아키텍처에서는 정상 경로보다 실패 모드가 더 중요하고 흥미롭다고 Lawson은 말합니다. 그 실패 지점을 이해하고 고치는 과정이 코드베이스를 깊이 익히는 최선의 방법이 된다는 거죠.

① 기존 버그 발굴 효과 — 의도치 않은 보너스

새 PR을 리뷰하다 보면 에이전트가 PR과 무관한 기존 코드의 문제를 발견하는 경우가 많습니다. 이게 처음엔 방해처럼 느껴질 수 있지만, 실제로는 숨겨진 기술 부채를 드러내는 귀중한 기회입니다. Lawson은 이를 통해 코드베이스의 잘 알려지지 않은 구석을 배우는 과정이기도 하다고 말합니다.

💡 실제 활용 시나리오 예시:
신규 알림 기능 PR을 리뷰하다가 에이전트가 2년 전에 작성된 알림 발송 기반 코드에서 “멀티스레드 환경의 race condition — 동시 요청 시 중복 발송 가능”을 발견했습니다. 프로덕션에서 간헐적으로 발생하던 중복 발송 버그의 원인이 밝혀졌고, 수정 후 관련 CS 티켓이 70% 감소했습니다.

② 실패 모드 학습 — 아키텍처를 진짜로 이해하기

복잡한 분산 시스템이나 마이크로서비스 아키텍처에서 정상 케이스는 상대적으로 단순합니다. 진짜 복잡성은 실패 케이스에 있어요. 네트워크 파티션이 발생하면? 외부 서비스가 500을 반환하면? 메시지 큐가 가득 차면? 이 질문들을 AI와 함께 파고드는 것이 아키텍처를 깊이 이해하는 방법입니다. 흔히 “vibe coding”에서 떠올리는 “10배 생산성” 개발과는 반대 방향에 가깝습니다.

💡 실제 활용 시나리오 예시:
이벤트 드리븐 결제 처리 시스템의 새 기능 PR에서, 에이전트에게 “이 코드의 실패 시나리오를 모두 나열해줘”라고 요청했더니 Mermaid 시퀀스 다이어그램으로 14가지 실패 경로를 그려줬습니다. 그 중 “결제 완료 이벤트가 두 번 발행될 경우 멱등성 처리 누락” 케이스를 발견해서 이중 결제 사고를 사전 예방했습니다.

6. 느린 AI 코딩을 위한 실천법 4가지

Lawson은 에이전트로 자신도 완전히 이해하지 못한 수백 줄짜리 PR을 만드는 개발자라면 더 느린 방식을 시도해볼 것을 권합니다. 구체적인 실천법 네 가지를 정리했습니다.

실천법	도구/방법	기대 효과
동작 원리 질문	Claude sub-agent	PR 전체 흐름 이해, 블라인드 머지 방지
실패 모드 질문	다중 모델 리뷰	엣지 케이스 사전 포착, 프로덕션 장애 예방
Mermaid 차트 문서화	Markdown 자동 생성	팀 공유 및 온보딩 비용 절감
/grill-me skill	Matt Pocock 방식	개발자 이해도 검증, 숨겨진 결함 발견

1) “어떻게 동작해?” 질문 — 이해하지 못한 코드는 머지하지 않는다

에이전트에게 PR이 어떻게 동작하는지 설명하게 하는 것이 시작점입니다. 단순히 코드를 읽는 게 아니라, “이 PR의 핵심 로직을 설명해줘, 각 함수가 어떤 역할을 하는지 포함해서”라고 요청하는 거예요. 이 설명을 읽었을 때 “모르는 부분이 있다”면 그 부분을 이해할 때까지 더 파고듭니다. 이해하지 못한 코드를 머지하지 않는다 — 이 원칙 하나가 코드베이스를 바꿉니다.

💡 실제 활용 시나리오 예시:
외부 팀에서 작성한 WebSocket 연결 관리 PR을 인수인계받아 에이전트에게 동작 설명을 요청했습니다. 설명 중 “하트비트 타임아웃 처리 로직이 모호하다”는 부분을 발견해 원작자에게 확인 요청을 했고, 실제로 엣지 케이스가 누락돼 있었음을 확인했습니다.

2) Mermaid 차트 문서화 — 눈으로 보는 아키텍처

Lawson은 복잡한 PR의 경우 Mermaid 차트가 포함된 Markdown 문서를 에이전트에게 작성하게 한다고 합니다. 플로우차트, 시퀀스 다이어그램, 상태 다이어그램 등을 통해 코드의 동작 흐름을 시각화하면, 팀원들과 공유하기도 훨씬 쉽고 나중에 유지보수할 때도 큰 도움이 됩니다. 문서 작성을 “나중에 해야 할 일”이 아닌 “PR 리뷰의 일부”로 포함시키는 발상입니다.

💡 실제 활용 시나리오 예시:
복잡한 주문 처리 상태 머신 PR에서 에이전트에게 Mermaid 상태 다이어그램을 요청했더니 12개 상태와 30개 전환을 시각화해줬습니다. 이 다이어그램을 팀 위키에 추가했고, 이후 신규 입사자 온보딩에서 해당 모듈 이해 시간이 반나절 이상 줄었습니다.

3) Matt Pocock의 /grill-me skill — 완전 이해 검증

Matt Pocock이 만든 /grill-me skill은 개발자가 PR을 처음부터 끝까지 진짜로 이해했는지 검증하는 도구입니다. 에이전트가 역으로 개발자에게 질문을 던져서 이해도를 테스트하는 방식인데요, “이 부분에서 왜 이 자료구조를 선택했나요?”, “이 예외가 발생하면 어떻게 처리되나요?” 같은 질문을 통해 모르는 부분을 스스로 발견하게 합니다.

💡 실제 활용 시나리오 예시:
/grill-me를 처음 사용했을 때 에이전트 질문 7번 중 3번을 제대로 답하지 못했습니다. 그 3개 중 하나가 실제로 버그 가능성이 있는 부분이었고, 확인해보니 트랜잭션 격리 수준에 대한 잘못된 가정이 있었습니다. 이해도 검증이 곧 버그 발견으로 이어진 사례입니다.

4) 많은 토큰 소비 후 재설계 — 손실 회피 편향 극복

Lawson이 솔직하게 인정하는 부분입니다. 많은 토큰을 쓴 뒤 처음 계획이 잘못됐다는 결론에 이를 수도 있다고요. 이미 많이 투자했다는 이유로 잘못된 방향을 계속 밀어붙이는 손실 회피 편향을 극복해야 합니다. 토큰 비용이 아깝더라도 재설계가 맞다면 그게 더 큰 이득입니다. 이 방식은 코드 줄 수 기준의 생산성을 높이는 게 목표가 아닙니다.

💡 실제 활용 시나리오 예시:
마이크로서비스 간 이벤트 처리 시스템을 Kafka 기반으로 구현하는 PR에 이틀을 투자했지만, 리뷰 결과 현재 팀 규모와 인프라에는 과도하게 복잡하다는 결론이 났습니다. 투자한 시간이 아까웠지만 단순한 REST 훅 방식으로 재설계하니 운영 부담이 80% 줄고 배포 주기가 빨라졌습니다.

7. 이런 분들께 적극 추천합니다

AI 도구로 코드를 빠르게 생성하지만 실제로 어떻게 동작하는지 잘 모르는 채 머지하는 개발자
프로덕션 장애가 반복되고 기술 부채가 쌓여서 코드베이스 건강이 걱정되는 팀 리드
코드 리뷰에 AI를 써봤지만 오탐이 많아 신뢰를 잃고 다시 수동 리뷰로 돌아간 개발자
신중하고 체계적인 개발을 지향하지만 AI 도구를 어떻게 접목할지 방향을 못 잡은 시니어 개발자
보안·정확성이 중요한 도메인(결제, 인증, 의료, 금융)에서 일하는 백엔드 개발자
신규 팀원 온보딩 시 기존 코드베이스를 효과적으로 전달하고 아키텍처 문서를 만들고 싶은 팀장

8. 자주 묻는 질문 (FAQ)

Q. 다중 모델 리뷰를 쓰려면 비용이 너무 많이 들지 않나요?

A. 초기에는 그렇게 느낄 수 있어요. 하지만 비용을 “모델 API 비용 vs. 프로덕션 버그 수정 비용”으로 비교해보면 생각이 달라집니다. Critical 버그 하나를 프로덕션에서 잡는 비용(장애 대응 + 핫픽스 + 고객 신뢰 손실)은 수백 달러의 API 비용과 비교가 안 됩니다. 또한 모든 PR에 다중 모델 리뷰를 적용할 필요는 없고, 복잡하거나 보안에 민감한 PR에만 선택적으로 적용하는 전략으로 비용을 충분히 제어할 수 있습니다.

Q. 주니어 개발자도 이 방식을 활용할 수 있나요?

A. 도메인 지식이 부족한 주니어에게는 처음에 어렵게 느껴질 수 있어요. Lawson도 다중 버그 보고서를 분류하려면 충분한 도메인 지식이 필요하다는 점을 인정합니다. 다만 완전히 불가능한 건 아닙니다. 시니어가 버그 심각도 판단 기준을 명문화하고, 처음엔 시니어와 함께 리뷰 결과를 해석하는 페어 세션을 진행하면 점진적으로 역량을 키울 수 있습니다. /grill-me skill은 오히려 주니어의 학습 도구로 특히 효과적입니다.

Q. 이 방식을 도입하면 개발 속도가 얼마나 느려지나요?

A. 단기 속도는 분명히 느려질 수 있습니다. 하지만 “속도”를 어떻게 측정하느냐가 중요합니다. 코드 라인 수 기준으로는 느려지지만, “버그 없이 배포된 기능 수” 또는 “프로덕션 인시던트 발생률”로 측정하면 팀 전체 속도가 오히려 빨라지는 경우가 많습니다. Lawson은 처음부터 “이 방식이 빠르다”고 주장하지 않았어요. 코드베이스 건강과 장기 유지보수성에 투자하는 방식이라고 솔직히 밝혔습니다.

✍️ 글을 마치며

Nolan Lawson의 접근은 AI 코딩 도구를 바라보는 관점을 근본적으로 바꿉니다. AI는 코드를 빠르게 생성하는 도구가 아니라, 코드베이스를 더 깊이 이해하고 더 안전하게 만드는 파트너가 될 수 있습니다. Claude sub-agent, Codex, Cursor Bugbot을 병렬로 돌리는 다중 모델 리뷰는 오탐률을 거의 0으로 줄이면서 진짜 위험한 버그를 잡아냅니다. 이 방식은 LLM 이전부터 지향하던 신중하고 체계적이며 품질에 집착하는 프로그래밍을 AI로 더 강력하게 만든 형태입니다.

저는 다음 PR부터 /grill-me skill 방식을 먼저 적용해볼 것 같아요. 에이전트가 코드 리뷰를 해주는 것도 좋지만, 역으로 에이전트가 저에게 질문을 던져서 제 이해도를 검증하는 방식이 훨씬 더 깊은 학습을 만들어줄 것 같거든요. 내가 이해하지 못한 코드는 머지하지 않는다 — 이 원칙 하나만 지켜도 코드베이스가 달라질 것 같습니다 😊

여러분은 어떤 부분이 가장 인상적이셨나요? 다중 모델 리뷰 전략, /grill-me skill, 아니면 PR 폐기 결정 기준? 댓글로 자유롭게 의견 남겨주세요!

자료 출처 및 유용한 링크
원문: Using AI to write better code more slowly — Nolan Lawson
GeekNews 원문 커뮤니티 토픽
관련 글: Claude로 코드 품질 자동화하기 실전 가이드