Claude-LRC 리뷰를 사용하여 프로덕션 환경을 더 안정적으로 만드는 방법

Claude와 같은 도구 덕분에 코드 생성 (Code generation)은 이제 빠르고 비교적 저렴해졌습니다. 수십 년 동안 코드를 작성하는 것은 비용이 많이 들었고 이를 검토하는 것은 비교적 저렴했으며, 대부분의 엔지니어링 프로세스는 이러한 현실을 바탕으로 구축되었습니다.

코드 생성 자체가 제약 사항이었기 때문에, 소수의 시니어 엔지니어들이 많은 개발자의 결과물을 검토할 수 있었습니다.

오늘날에는 단 한 명의 엔지니어가 이전보다 훨씬 적은 시간 내에 마이그레이션 (Migrations), API, 테스트 (Tests), 인프라 코드 (Infrastructure code), 문서화 (Documentation), 그리고 리팩터링 (Refactors)을 생성할 수 있습니다.

AI는 코드 생성을 풍부하게 만들었습니다.

대부분의 엔지니어링 프로세스는 여전히 이에 적응하는 중입니다.

코드 생성은 극적으로 가속화되었습니다.

검토 (Scrutiny)가 희소한 자원이 되었습니다.

새로운 실패 모드 (The New Failure Mode)

AI가 생성한 코드의 가장 큰 위험은 충분한 검토를 받지 못한 가정 (Assumptions)에서 발생합니다.

인간은 항상 불완전한 코드를 작성해 왔습니다.

프로덕션 안정성 (Production stability)은 대개 누군가가 어려운 질문을 던짐으로써 확보됩니다.

Claude가 생성한 코드는 종종 합리적으로 보입니다.

컴파일도 됩니다.

테스트도 통과합니다.

컨벤션 (Conventions)도 따릅니다.

프로덕션 장애는 종종 검토를 피해 간 가정들로부터 발생합니다.

• 부하를 증폭시키는 재시도 루프 (Retry loop).
• 누락된 권한 확인 (Authorization check).
• 동시성 엣지 케이스 (Concurrency edge case).
• 스테이징 (Staging)에서는 작동하지만 프로덕션 (Production)에서는 어려움을 겪는 마이그레이션.
• 실제 트래픽 하에서 조용히 실패하는 캐시 무효화 (Cache invalidation) 전략.

AI가 코드 출력을 증가시킴에 따라, 검토가 필요한 코드의 양도 함께 늘어납니다.

동일한 리뷰어, 스태프 엔지니어 (Staff engineers), 보안 엔지니어 (Security engineers), 그리고 테크니컬 리드 (Technical leads)들이 이전보다 훨씬 더 많은 양을 평가해야 하는 상황입니다.

리뷰가 서둘러 진행되면 리뷰 품질이 저하되고, 리뷰가 과부하되면 배포 (Delivery)가 느려집니다.

두 결과 모두 소프트웨어 품질을 개선하지 못합니다.

중앙 집중식 리뷰는 무너집니다. 그러니: 분산시키세요!

소수의 시니어 엔지니어 그룹이 더 이상 전체 리뷰 부담을 짊어질 수 없습니다.

그 모델은 코드 생성이 자연스럽게 제한되었던 환경에는 적합했습니다.

오늘날 Claude 및 기타 AI 도구들은 모든 개발자가 이전보다 훨씬 더 많은 코드를 생성할 수 있게 해줍니다.

앞으로 나아갈 방향은 개발 프로세스 전반에 걸쳐 검토(Scrutiny)를 분산시키는 것입니다.

더 많은 개발자가 숙련된 리뷰어들이 던지는 것과 같은 종류의 질문에 접근할 수 있어야 합니다.

코드가 공식적인 리뷰 대기열(Review queue)에 도달하기 전에 더 많은 가설(Assumptions)에 대한 검토가 이루어져야 합니다.

검토가 소수의 과부하된 인원에게만 집중되는 대신, 팀 전체에 걸쳐 더 많이 이루어져야 합니다.

리뷰는 확장(Scale)되어야 합니다.

그리고 리뷰를 확장한다는 것은 리뷰를 분권화(Decentralizing)한다는 것을 의미합니다.

인간 리뷰어는 여전히 필수적입니다.

검토가 매일 양치질을 하는 것처럼 각 개인에게 자연스러운 일이 될 때, 그들의 전문성은 더 큰 영향력을 발휘합니다.

리뷰는 양치질만큼이나 도처에 존재하고 당연한 것이 되어야 합니다

가장 저렴하고 효과적인 리뷰는 코드가 커밋(Commit)되기 전에 발생합니다.

개발자는 여전히 맥락(Context)을 파악하고 있고 수정에 몇 분밖에 걸리지 않는 동안, 가설에 이의를 제기함으로써 이득을 얻습니다.

공식적인 리뷰를 기다리는 대신, 다음과 같은 질문을 던질 수 있습니다:

• 내가 놓치고 있는 리스크는 무엇인가?
• 내가 전제하고 있는 가설은 무엇인가?
• 회의적인 리뷰어라면 어떤 점을 질문할 것인가?
• 여기에 존재하는 신뢰성(Reliability) 문제는 무엇인가?
• 내가 더 자세히 조사해야 할 보안(Security) 우려 사항은 무엇인가?

이것들은 개발자가 코드를 작성하는 동안 Claude에게 물어볼 수 있는 바로 그러한 종류의 질문들입니다.

이러한 질문들이 일찍 던져질수록, 답변하기도 더 쉬워집니다.

개발 과정 전반에 걸친 광범위한 리뷰는 문제를 조기에 발견할 기회를 더 많이 만들어냅니다.

맥락이 생생할 때 빈번하게 검토를 수행하면 팀이 더 큰 확신을 가지고 더 빠르게 움직이는 데 도움이 됩니다.

엔지니어링 위생(Engineering Hygiene)으로서의 리뷰

리뷰는 특별한 이벤트가 아니라 일상적인 습관이 될 때 가장 가치 있습니다.

아무도 충치가 생길 때까지 양치질을 기다리지 않습니다.

가치는 일관되게 수행되는 작은 예방 조치에서 나옵니다.

소프트웨어 품질도 마찬가지입니다.

커밋 전의 5분간의 리뷰가 배포 후 몇 시간의 디버깅(Debugging)을 방지할 수 있습니다.

가설에 대한 빠른 도전은 장애 회고(Incident Retrospective)의 필요성을 없앨 수 있습니다.

최고의 프로덕션 장애는 아예 발생하지 않는 장애입니다.

이를 위해서는 리뷰를 일상적인 엔지니어링 작업의 일부로 만들어야 합니다.

claude-lrc가 적합한 위치

claude-lrc는 개발자가 작업하는 동안 가설에 의문을 제기할 수 있도록 도움으로써 지속적인 리뷰를 실용적으로 만듭니다.

목표는 개발 과정에 자연스럽게 녹아드는 지속적인 검토(Continuous Scrutiny)입니다.

목표는 개발자가 정기적으로 수행할 수 있는 리뷰입니다.

Claude Code 내부에서.

자연어(Natural Language)를 사용하여.

슬래시 명령어(Slash Commands)를 사용하여.

이미 매일 사용하는 워크플로(Workflows)를 사용하여.

코드 생성과 더불어, claude-lrc는 개발자가 자신이 생성한 코드를 검토할 수 있도록 돕습니다.

개발 전 과정에 걸쳐, claude-lrc는 많은 작은 검토의 순간들로 리뷰를 분산시키도록 돕습니다.

개발자는 더 일찍 가설에 의문을 제기할 수 있습니다.

팀은 공식적인 리뷰 전에 리스크를 드러낼 수 있습니다.

시니어 엔지니어는 가치 높은 판단과 아키텍처 결정에 더 많은 시간을 할애할 수 있습니다.

작은 리뷰.

빈번한 리뷰.

테스트를 실행하는 것과 마찬가지로, 리뷰는 소프트웨어를 구축하는 일반적인 과정이 되어야 합니다.

차세대 엔지니어링 습관

지속적인 리뷰는 차세대 표준 엔지니어링 관행이 되고 있습니다.

버전 관리(Version Control)가 표준이 되었습니다.

테스트(Testing)가 표준이 되었습니다.

지속적 통합(Continuous Integration)이 표준이 되었습니다.

관측 가능성(Observability)이 표준이 되었습니다.

AI 지원 개발(AI-assisted development)은 또 다른 표준 관행에 대한 수요를 창출하고 있습니다.

Claude는 그 어느 때보다 더 많은 코드를 생성하는 데 도움을 줄 수 있습니다.

신뢰할 수 있는 소프트웨어를 전달하는 것은 여전히 세심한 평가와 건전한 판단에 달려 있습니다.

인간의 주의력은 여전히 유한한 자원입니다.

성공하는 팀은 생성(Generation)과 함께 검토(Scrutiny)의 규모를 확장할 것입니다.

그것은 리뷰를 지속적으로 만드는 것을 의미합니다.

그리고 리뷰어뿐만 아니라 모든 사람이 이를 사용할 수 있도록 만드는 것입니다.

우리는 이미 테스트를 지속적인 활동 (Continuous activity)으로 취급하고 있습니다.

코드 리뷰 (Code review) 또한 지속적으로 이루어져야 할까요?