코드 리뷰가 더 이상 중요하지 않다는 논쟁이 널리 퍼져 있습니다. 그 논리는 모델이 코드를 작성했으니, 다른 모델이 이를 검사할 수 있으며, diff(차이점)를 읽는 인간은 이제 건너뛸 수 있는 느리고 비용이 많이 드는 단계라는 것입니다. 저는 이것이 문제의 핵심을 정반대로 파악하고 있다고 생각합니다.

코드 리뷰가 중요성을 잃은 것이 아닙니다. 확장성(Scaling)을 잃은 것입니다. 이제 인간이 코드를 읽거나 그에 대해 추론하는 속도보다 더 빠르게 코드를 생성할 수 있습니다. 엔지니어가 diff를 읽는 것이 최후의 방어선이었던 기존 모델은, 단 한 번의 오후 동안 한 사람이 머릿속에 담을 수 있는 것보다 더 많은 변경 사항이 생성되기 시작한 순간 조용히 무너졌습니다. 리뷰를 건너뛰는 것은 이 문제를 해결하지 못합니다. 그저 이미 실패하고 있는 유일한 점검 단계를 제거하고 그 자리에 아무것도 두지 않는 것뿐입니다.

해답은 검증(Verification)을 속도를 따라갈 수 있는 요소들로 옮기는 것입니다. 저는 Rust 코어를 기반으로 하나의 리포지토리에 수십 개의 언어 SDK를 갖춘 문서 지능 엔진인 xberg를 구축해 왔으며, 이것이 쓰레기를 배포하지 않으면서도 생성 속도에 맞춰 배포할 수 있게 해주는 설정입니다.

정적 분석(Static analysis)과 타입(Types)이 저렴한 작업을 수행합니다

첫 번째 계층은 프로그램을 실행하지 않고도 기계가 확인할 수 있는 모든 것, 즉 린팅(Linting), 정적 분석(Static analysis), 타입 체크(Type checks)입니다. 이것은 여러분이 구매할 수 있는 가장 저렴한 검증이며, 테스트가 실행되기도 전에 전체 범주의 오류를 잡아냅니다. 타입 오류(Type error), 사용되지 않는 바인딩(Unused binding), 위험한 캐스트(Dangerous cast), 팀으로서 합의한 린트 규칙(Lint rule) 등 이 중 어느 것도 인간이 알아차릴 필요가 없습니다.

다국어(Polyglot) 리포지토리의 경우, 이것은 그 자체로 하나의 프로젝트가 됩니다. 저는 하나의 설정으로 구동되는 두 개의 독립적인 Rust 바이너리인 polylint를 구축하게 되었는데, 언어별로 별도의 린터(Linter)와 포매터(Formatter)를 pre-commit에 연결하는 것 자체가 유지보수 비용(Maintenance tax)이었기 때문입니다. 핵심은 도구가 아닙니다. 핵심은 기계적인 점검(Mechanical checks)이 로컬과 CI 모두에서 모든 변경 사항에 대해 실행되어야 하며, 아무도 이를 건너뛰고 싶어 하지 않을 만큼 충분히 빨라야 한다는 것입니다.

포괄적인 테스트(Comprehensive tests)는 동작을 증명합니다

정적 분석 (Static analysis)은 코드가 잘 형성되었는지는 알려주지만, 코드가 올바른지는 알려주지 않습니다. 그것이 바로 테스트가 필요한 이유이며, 생성 속도(generation speed) 측면에서 테스트 스위트 (test suite)는 그 어떤 인간보다 훨씬 더 많은 리뷰를 수행하고 있습니다.

여기서 제 역할을 다하는 테스트는 엔드 투 엔드 (end-to-end) 테스트와 통합 (integration) 테스트입니다. 단위 테스트 (Unit tests)도 유용하지만, 단위 테스트들이 모두 통과(green) 상태라 하더라도 시스템 전체가 잘못된 동작을 할 수 있습니다. 여러분이 원하는 것은 사용자가 사용하는 방식과 동일하게 소프트웨어의 실제 경로를 실행하는 테스트입니다. 즉, 실제 입력값, 실제 경계값, 실제 실패 모드 (failure modes)를 다루는 테스트 말입니다. 제가 xberg의 추출 파이프라인에 새로운 포맷을 추가할 때, 중요한 테스트는 파서를 모킹 (mock)하고 호출 여부를 확인하는 테스트가 아니라, 해당 포맷의 실제 파일을 엔드 투 엔드로 실행하고 출력을 확인하는 테스트입니다.

동작에 대한 포괄적인 커버리지 (coverage)가 있어야만 대규모로 생성된 변경 사항을 확신을 가지고 수용할 수 있습니다. 테스트 스위트는 절대 지치지 않고 절대 대충 훑어보지 않는 리뷰어입니다.

에이전트(Agents)는 작성된 가이드라인을 기준으로 리뷰합니다

위의 그 어떤 방법도 소프트웨어를 직접 실행해야 할 필요성을 없애주지는 않습니다. 이는 사람들이 현재 가장 건너뛰고 싶어 하는 단계이며, 동시에 다른 모든 것이 놓치는 것을 잡아내는 단계이기도 합니다.

통과된(Green) 파이프라인은 하나의 신호일 뿐입니다. 그것이 당신의 소프트웨어가 당신이 생각하는 대로 작동한다는 증거는 아닙니다. 자동화된 테스트(Automated tests)는 오직 당신이 확인하기로 생각했던 것들만을 확인합니다. 직접 실행해 보고, 실제 경로를 작동시켜 보며, 가장자리(edges)를 찔러보는 과정이야말로 전체 테스트 스위트(test suite)가 버그와 함께 조용히 공유하고 있는 가정을 찾아내는 방법입니다. QA(Quality Assurance)는 체크가 통과된 후 단순히 체크 표시를 하는 상자가 아닙니다. 생성 속도(generation speed)의 시대에 QA는 엔지니어가 수행하는 가장 레버리지가 높은 작업 중 하나가 됩니다. 왜냐하면 인간이 한 줄 한 줄 작성하지 않은 소프트웨어에 인간의 판단력을 적용할 수 있는 유일한 계층이기 때문입니다.

QA를 지나쳐온 단계가 아니라 핵심 엔지니어링 기능으로 취급하는 팀들이야말로, 이러한 속도에 무너지지 않을 팀들입니다.

오픈 소스는 코드를 무료로 더 좋게 만듭니다

한 가지 계층이 더 있으며, 이는 제가 아는 가장 강력한 계층입니다. 코드를 오픈 소스(Open source)로 공개하면 사내에서 결코 재현할 수 없는 규모로 테스트가 이루어집니다. 수천 명의 사람들이 당신이 상상도 못 한 환경에서, 당신이 생성할 것이라고 생각지도 못한 입력값(inputs)으로 코드를 실행하며, 그들이 마주하고 보고하는 모든 버그는 다시 돌아와 코드를 더욱 견고하게 만듭니다. 그 어떤 내부 테스트 스위트도 그 정도 규모의 실제 사용량(real usage)과 경쟁할 수 없습니다.

감사 가능성(Auditability)과 선량한 시민 의식(good citizenship)도 실재하지만, 코드 자체를 변화시키는 이점은 더 단순합니다. 공개된 코드는 대규모로 테스트된 코드이며, 대규모로 테스트된 코드는 더 나은 코드입니다. xberg의 모든 라이브러리가 부분적으로 이러한 이유 때문에 오픈 소스로 공개되어 있습니다.

그 형태(The shape of it)

이들을 종합하면, 검증 계층(verification layer)은 다음과 같은 모습입니다: 정적 분석(static analysis)과 타입(types)이 저렴한 오류들을 잡아내고, 포괄적인 엔드 투 엔드(end-to-end) 및 통합 테스트(integration tests)가 동작을 증명하며, 에이전트(agents)가 작성된 가이드라인에 따라 1차 리뷰를 수행하고, 당신이 직접 테스트하여 기계가 놓친 것을 잡아내며, 오픈 소스가 당신의 사용자를 당신이 가질 수 있는 가장 거대한 테스트 스위트로 변모시킵니다.

코드 리뷰 (Code review)는 선택 사항이 아니게 되었습니다. 그것은 사람이 아닌 시스템이 되었습니다. 그 시스템을 구축하십시오. 그러면 그것이 제대로 작동하는지에 대해 스스로를 속이지 않으면서도, 모델이 허용하는 만큼 빠르게 움직일 수 있습니다.