모든 코드 라인을 다 읽는 것을 멈추세요!

저는 업무에서 Claude Code를 아주 헤비하게 사용하고 있습니다. 예를 들어, 하루 8시간 동안 6개의 서로 다른 로봇과 동시에 대화하며, 6개의 티켓(ticket)을 동시에 처리하고 있습니다. 너무나 많은 결과물을 쏟아내고 있어서 우리 팀은 그 PR(Pull Request)의 양을 감당하지 못할 정도입니다. 결과물을 따라가지 못하고 있기 때문이죠. 사용하면 할수록, 저는 이 사실을 확신하게 됩니다.

우리는 코드 리뷰를 잘못하고 있습니다.

그리고 우리의 프로세스는 이미 2026년에 무너지고 있습니다. 우리의 기본 가정은 시대에 뒤떨어져 있습니다:

"사람이 모든 라인을 작성했으니, 사람도 모든 라인을 읽어야 한다."

그런 세상은 빠르게 사라지고 있습니다. 2026년에 2016년 방식처럼 리뷰를 계속한다면, 당신의 프로세스는 무너질 것입니다. 당신이 엔지니어든, 매니저든, 혹은 프로덕트 매니저(Product Manager)든 — 이 문제는 당신이 하는 모든 방식에 영향을 미칠 것입니다.

우리는 어셈블리(Assembly)를 읽는 것을 멈췄습니다 — 하지만 이것은 완전히 똑같은 변화는 아닙

우리는 전에도 비슷한 상황을 겪은 적이 있습니다. 어셈블리(Assembly)에서 고수준 언어(higher-level languages)로 넘어갔을 때, 아무도 "이봐, 우리는 여전히 어셈블리 출력물 전체를 리뷰해야 해"라고 말하지 않았습니다. 우리는 추상화(abstraction)를 신뢰했습니다. 우리는 그저 고수준 코드를 리뷰하는 것만으로도 충분했습니다. 우리의 초점을 옮긴 것이죠. 이 AI 생성(AI-generated)으로 인한 변화도 이와 유사하지만, 백 배는 더 거대하며 한 가지 결정적인 차이점이 있습니다.

자, 시작해 봅시다. 우리는 이미 수많은 블랙박스(black boxes)를 끊임없이 용인하고 있습니다. 당신은 설치하는 모든 npm 패키지를 읽지 않습니다. 아무도 TypeScript가 컴파일하여 만들어낸 JavaScript를 리뷰하지 않습니다. 아무도 Terraform으로 작성할 때 AWS가 프로비저닝(provision)하는 서버 설정(server configs)을 읽지 않습니다. 당신은 SQL 쿼리를 작성하고, 쿼리 플래너(query planner)가 어떻게 실행할지 결정하도록 맡깁니다.

여기 결정적인 차이점이 있습니다. 제가 방금 예로 든 컴파일러(Compilers)와 같은 것들은 결정론적(deterministic)이며 공식적으로 검증(formally verified)되었습니다. 하지만 LLM은 그렇지 않습니다. Claude에 입력된 두 개의 동일한 프롬프트가 매우 다른 코드를 생성할 수 있습니다. 더 심각한 것은, AI 에이전트(AI agents)가 컨텍스트(context)가 비대해짐에 따라 자신의 지침으로부터 능동적으로 벗어난다는 점입니다. 당신의 CLAUDE.md 파일에 "기본값을 삽입하지 마세요"라고 적혀 있더라도, 에이전트는 3,000 토큰(tokens)이 지난 시점에서 이를 수행할 수도 있습니다. 이것이 더 나은 모델이 나오면 해결될 문제인지는 모르겠습니다. 왜냐하면 이것은 애초에 이러한 모델들이 작동하는 방식의 매우 근본적인 부분인 것처럼 보이기 때문입니다.

그렇다면 어떻게 코드 리뷰 병목 현상(bottleneck) 문제를 해결할 수 있을까요? 더 나은 가드레일(guardrails)을 통해서입니다.

계획을 검토하고, 변경 사항(Diff)은 훑어보세요

구현(implementation)이 점점 더 많이 생성되고 있다면 — 실제로 그렇습니다 — 가장 레버리지가 높은(highest-leverage) 리뷰는 프로세스의 더 앞 단계로 이동합니다: 계획(plans), 제약 조건(constraints), 인터페이스(interfaces), 아키텍처(architecture), 리스크(risks), 테스트(tests).

대부분의 변경 사항에 대해, PR(Pull Request) 요약을 읽을 때 당신은 다음과 같은 질문을 던지게 됩니다: 이 계획이 올바르게 들리는가? 제약 조건이 적절한가? 엣지 케이스(edge cases)가 있는가? PR의 테스트가 동작을 증명하는가? 이것은 모든 줄을 하나하나 읽는 것보다 훨씬 더 높은 레버리지를 가집니다.

인증(auth), 결제(payments), 또는 권한 확인(permission checks)과 같은 항목의 경우, 계획이 견고해 보이더라도 여전히 특정 부분을 줄 단위로 정밀하게 읽고 싶을 것입니다. 왜일까요? 에이전트는 이탈할 것이기 때문입니다. 계획은 모든 구현 오류나 사소한 실수(nitpick)를 포착하지 못할 것입니다. 이와 같은 핵심 코드는 항상 모든 줄에 대해 인간의 눈으로 확인될 가치가 있습니다. 리뷰가 없는 프로세스로 넘어가야 한다는 말이 아닙니다. 모든 코드가 동일한 깊이의 리뷰를 필요로 하지는 않는다는 뜻입니다. 어떤 코드는 훑어보고, 어떤 코드는 모든 줄을 읽어야 합니다. 기술이란 무엇이 무엇인지 아는 것입니다.

아무도 인정하고 싶지 않은 리뷰 병목 현상

여기 추악한 비밀이 있습니다. 코드는 인간이 리뷰할 수 있는 속도보다 훨씬, 훨씬 더 빠르게 작성되고 있습니다.

AI 도입률이 높은 팀은 PR을 98% 더 많이 병합(merged)했지만, PR 리뷰 시간은 91% 증가했습니다.

Faros AI는 10,000명 이상의 개발자를 대상으로 한 텔레메트리 (telemetry) 데이터를 분석하여 이를 확인했습니다. 여러분은 2배 더 많은 결과물을 만들어내고 있지만, 리뷰 시간 또한 2배 더 오래 걸리고 있습니다. 게다가 이는 병렬화 (parallelization)를 고려하기 전의 이야기입니다. 워크트리 (worktrees)를 통해 한 번에 3~5개의 세션을 실행하는 엔지니어들은 동시에 여러 개의 스트림을 생성하고 있습니다.

기존에 일주일에 10개의 PR을 제출하던 팀들은 이제 50~100개의 PR을 마주하고 있습니다. Claude가 모든 엔지니어를 PR 생산 공장으로 만드는 동안, 여러분의 코드 리뷰 방식이 여전히 "모든 라인을 한 줄씩 주의 깊게 읽는 것"에 머물러 있다면, 여러분의 조직은 인간 크기의 깔때기에 연결된 소방 호수 (firehose)와 같은 상태가 될 것입니다. 무언가 변화가 필요합니다.

내가 제안하는 해결책

계층화된 리뷰 시스템 (Tiered review systems).

Tier 1: 완전 자동화 — 린팅 (linting), 정적 분석 (static analysis), 단위 테스트 (unit tests), 보안 스캐닝 (security scanning), 타입 체크 (type checking). 인간의 개입 없음.

Tier 2: 동작, 정확성, 그리고 "이것이 의도와 일치하는가?"에 대한 동료 리뷰 (peer review).

Tier 3: 핵심 경로 (critical paths) — 인증 (auth), 결제 (payments), 개인정보 (PII), 시스템 경계 (system boundaries)에 대한 시니어/보안 리뷰. 대부분의 변경 사항은 Tier 3가 필요하지 않아야 합니다.

가드레일이 곧 제품이 된다

따라서, 우리가 모든 것을 한 줄씩 읽는 것을 멈춘다면 — 그리고 저는 그래야 한다고 말하고 있습니다 — 가드레일 (guardrails)은 더 이상 있으면 좋은 기능 (nice-to-haves)이 아니라 반드시 있어야 하는 기능 (must-haves)이 됩니다. 가드레일은 여러분이 실제로 수행해야 하는 진짜 작업이 됩니다. 현재 상태의 AI는 많은 결함을 가지고 있습니다. 기본값을 조용히 삽입할 수도 있고, 여러분으로부터 적절한 컨텍스트 (context)를 받지 못해 이름을 잘못 지을 수도 있으며, 지침에서 벗어날 수도 있고, 컨텍스트가 너무 비대해지면 완전히 환각 (hallucinate)을 일으킬 수도 있습니다. 따라서 이러한 문제들을 잡아내기 위해 여러분에게는 가드레일이 필요할 것입니다.

제가 가드레일(guardrails)이라고 말할 때, 그것은 테스트(tests)를 의미합니다. 여러분은 대부분의 프로덕션 기업들이 실제로 보유하고 있는 것보다 훨씬 더 많은 테스트 커버리지 (test coverage)가 필요할 것입니다. 핵심 테스트 (critical testing), 통합 테스트 (integration testing), 엔드 투 엔드 테스트 (end-to-end testing), 그리고 발견하는 모든 버그에 대한 회귀 테스트 (regression tests)가 필요합니다. 여러분의 테스트는 여러분이 수행하는 작업의 계약 (contract)이 됩니다. 하지만 테스트를 생성하는 데에도 AI를 사용하는 것에 문제가 있을까요?

물론 그렇습니다. 따라서 테스트 품질 또한 면밀한 검토가 필요하며, 특히 핵심적인 테스트일수록 더욱 그렇습니다. 커버리지 헬퍼 (coverage helper)와 같은 도구를 사용하는 것은 AI에 의해 완전히 조작될 수 있습니다. 중요한 것은 여러분의 테스트가 위험할 수 있는 코드 조각이 실제로 올바르게 작동한다는 것을 증명하는 것입니다. 발생하는 모든 프로덕션 장애 (production incident)에 대해 테스트를 생성해야 합니다. Anthropic의 수석 엔지니어 (principal engineer) 중 한 명인 Thoriq의 조언과 유사하게, 여러분은 여러분이 마주치는 버그와 주의 사항 (gotchas)을 항상 Claude에게 알려주어야 합니다. 또한 GitHub 워크플로 (workflows)의 모든 PR에서 보안 체크 (security checks)가 실행되도록 해야 할 것입니다.

아키텍처 결정 기록 (Architecture Decision Records) 또한 매우 중요해집니다. 여러분의 CLAUDE.md는 이미 이것의 경량화된 버전이라고 볼 수 있습니다. 제가 본 팀들 중 Claude를 가장 잘 활용하는 팀들은 CLAUDE.md를 살아있는 문서 (living document)로 취급합니다. 실수가 발견될 때마다 그들은 CLAUDE.md 파일을 업데이트합니다. 그 CLAUDE.md 파일은 조직의 기억 (institutional memory) — 즉, 학습된 모든 교훈이 복리로 쌓이는 기록 — 이 됩니다. 이러한 접근 방식에서는 관측성 (Observability) 또한 훨씬 더 중요해집니다. Claude에게 로그 (logs), 트레이싱 (tracings), 메트릭 (metrics), 그리고 알림 (alerts)을 읽는 방법을 알려주는 것은 이 전체 워크플로를 훨씬 더 원활하게 만들어 줄 것입니다. 문서화가 잘 되어 있고 무엇을 조사하고 있는지 명확하다면, 여러분은 언제 버그가 발생하는지, 언제 수정해야 하는지, 그리고 어떻게 수정해야 하는지를 알게 될 것입니다.

요약 (TLDR): 제가 다음 주에 실제로 할 일

PR(Pull Request)의 크기를 약 400라인 정도로 제한하세요. 이를 GitHub에서 강제하세요. 누군가 명시적으로 재정의(override)를 시도하는 경우에만 허용하며, 이 경우에도 팀에 알림이 가도록 설정하세요.

리스크 등급 루브릭(risk tier rubric)을 만드세요. 저위험(low-risk) PR은 자동화하세요. 사용자 데이터나 인증(auth)을 수정할 수 있는 고위험(high-risk) PR은 시니어의 검토와 타겟팅된 diff(차이점) 읽기가 필요합니다.

철저한 PR 요약(PR summary)을 요구하세요. PR 요약은 현재 아마도 가장 중요한 산출물(artifact)일 것입니다. 이에 대해서는 별도의 글을 작성할 예정이니 기대해 주세요.

자동화된 체크(automated checks)를 필수 사항으로 만드세요. 타입 체크(Type checking), 보안 스캔(security scans), 테스트 커버리지(test coverage). 이 모든 것들은 이제 선택 사항이 아닌 필수 요구 사항이어야 합니다. 예외는 없습니다.

GitHub에 올라간 후뿐만 아니라, 개발 단계에서 AI 리뷰를 설정하세요. 자신의 터미널에서 코드를 작성한 후, 코드를 리뷰하기 위해 새로운 AI 에이전트(AI agent)를 생성하는 습관을 들이세요. Claude의 새로운 /simplify 명령어를 사용하는 것을 검토해 보세요. 에이전트가 스스로의 숙제를 채점하게 두지 마세요.

Claude가 읽을 수 있도록 규칙을 문서화하세요. 모든 리포지토리(repo)에 CLAUDE.md 파일을 두고, .claude/rules 폴더에 더 심층적인 규칙을 넣으세요. Claude가 실수를 하면 항상 이 파일들을 업데이트하세요.

PR 리뷰 대기열(PR review queue)을 추적하세요. PR 리뷰에 시간이 얼마나 걸리는지에 대한 지표(metrics)를 기록하기 시작하세요. 이곳이 병목 현상(bottleneck)이 가장 먼저 나타나는 지점이며, 이에 대한 좋은 관측성(observability)을 확보해야 합니다.

결론 (The Bottom Line)

역할이 "코드를 작성하고, 코드를 리뷰하는 것"에서 "철저한 Jira 티켓 작업을 설계하고, 티켓을 간결하면서도 상세한 프롬프트(prompt)로 변환하며, 가드레일(guardrails)을 정의한 다음, 그 결과를 검증하는 것"으로 변화하고 있습니다.

이것은 속임수가 아니라 거대한 업그레이드입니다. 하지만 이는 올바른 인프라(infrastructure)를 통해 그 가치를 증명했을 때만 유효합니다. 그러니 기본적으로 모든 코드 라인을 읽는 것을 멈추세요. 하지만 그것을 Claude가 말하는 모든 것을 맹목적으로 신뢰하는 것과 혼동해서는 안 됩니다. 여러분은 가드레일(guardrails), 테스트(tests), 게이트(gates)를 신뢰해야 합니다. 제품 요구사항(product requirements)과 같이 오직 인간만이 판단할 수 있는 영역에는 인간의 판단이 개입되어야 하며, 실제 피해가 발생하는 경계 지점에서는 여전히 인간의 판단을 적용하고 있는지 확인해야 합니다.

그러니 리뷰를 중단하지 마세요. 단지 평생 해왔던 방식 그대로 모든 것을 리뷰하는 것을 멈추라는 것입니다.

저는 Amazon과 The New York Times에서 5년 넘게 소프트웨어 엔지니어(software engineer)로 근무해 왔으며, 최근에는 프로덕션 워크플로(production workflows)에서 Claude를 광범위하게 사용하고 있습니다. 이것은 이론적인 예측이 아니라 현장에서 얻은 관찰 결과입니다. 변화는 이미 일어나고 있습니다. 스스로를 준비시키세요!