생성된 패치가 형식(formatting), 명명 규칙(naming), 심지어 로컬 정확성 때문에 리뷰에서 실패하는 경우는 드뭅니다. 실패하는 이유는 리뷰어가 그 패치가 고치려 했던 오류, 읽었던 파일들, 그리고 조용히 내렸던 결정들을 재구성할 수 없기 때문입니다. 이러한 패치를 함께 검토하는 시니어 엔지니어는 종종 처음 10분 동안 diff를 무시하고 대신 정해진 질문의 사다리를 따라 걸어갑니다. 이 답변들이 기록되면, 그 패치는 명확하게 수용 가능하거나 명확하게 잘못된 것으로 판명되고 논쟁은 기록으로 정리됩니다.

린트(Lint)보다 중요한 것은 구조(Ladder)

린트, 타입 체크(type checks), 그리고 유닛 테스트(unit tests)는 코드가 작성된 방식에 대해서만 답을 합니다. 이들은 변경 사항을 만들어낸 추론 과정(reasoning)에 대해서는 아무것도 말해주지 않으며, 바로 이곳에서 생성된 패치들이 가장 자주 잘못됩니다. 어떤 패치는 모든 검사를 통과했음에도 불구하고 아무도 건드리라고 요청하지 않은 모듈을 수정하거나, 프롬프트 내부에서만 유효했던 가정을 하드코딩(hard-code)할 수 있습니다. 따라서 리뷰는 두 가지의 뚜렷한 관문이 필요합니다. 즉, 아티팩트(artifact)에 대한 기계적 관문과 그것의 의도(intent)에 대한 대화형 관문입니다.

순서대로 따지는 다섯 가지 질문

1. 재현성(Reproduction)이 최우선이다. 패치 없이 깨끗한 체크아웃 상태에서 실패가 재현될 수 있는가? 허용 가능한 증거는 명령어, 종료 코드, 그리고 로그 한 줄이다. 솔직한 대답이 '아마도'라면, diff를 열기 전에 세션은 끝난다.
2. 읽기 집합(Read set)을 확인한다. 패치가 수정하는 모듈 외부에 어떤 파일, 테이블 또는 엔드포인트를 읽는가? 허용 가능한 증거는 grep 검색 결과, 추적 기록(trace), 또는 명시적인 import 목록이다. 이는 가장 흔한 막다른 길을 포착한다: 명시된 문제를 해결하기 위해 세 개의 관련 없는 패키지를 건드리는 패치.
3. 계약(Contract)을 확인한다. 이 패치가 보존하겠다고 약속하는 기존 동작은 무엇이며, 그 약속은 어디에서 테스트되는가? 허용 가능한 증거는 여전히 통과하는 기존 테스트의 이름이다. 여기서 침묵한다는 것은 보통 패치가 버그픽스 코스튬을 입은 재작성(rewrite)이라는 것을 의미한다.
4. 롤백(Rollback) 계획을 세운다. 만약 이 패치가 프로덕션 환경에서 잘못되었다면, 그것을 되돌리는 단일 명령어 또는 플래그는 무엇인가? 허용 가능한 증거는 나중에 작성할 계획이 아니라, 그 자체의 revert 경로이다.
5. 책임자(Owner)를 지정한다. 6개월 후에 이 결정에 누가 책임을 지며, 그 기록은 어디에 남겨지는가? 허용 가능한 증거는 이름과 파일이며, 보통 세션이 생성하는 것과 동일한 의사결정 기록이다.

첫 번째와 두 번째 질문만으로도 대부분의 후보들은 몇 분 안에 제거된다. 세 번째부터 다섯 번째 질문까지는 생존자가 오늘 병합(mergeable)될 수 있는지 아니면 후속 티켓이 필요한지를 결정한다.

재현 가능한 아티팩트로 세션 실행하기

1. 세션 디렉토리를 구성하고 후보를 고정한다. 패치를 복사하고 해시하여, 검토하는 바이트가 대화 도중에 변동되지 않도록 한다.
2. 기반 리비전(base revision)을 기록한다. 이것이 없으면, 나중에 읽는 사람이 이 패치가 어떤 트리(tree)를 기반으로 생성되었는지 알 수 없다.
3. 라더(ladder) 질문에 기계가 읽을 수 있는 파일로 답한다. 채팅 스레드의 자유 텍스트는 의사결정 기록이 아니다; JSON이나 YAML이다.
4. 누군가 테스트를 실행하기 전에 완전성을 게이트(Gate)로 삼는다. 답변되지 않은 질문은 파이프라인을 지나치게 하는 것이 아니라, 멈추게 해야 한다.

questions.yml - 데이터를 이용한 사다리 (ladder)

• id: q1_repro
  text: "패치 없이 깨끗하게 체크아웃된 상태에서 실패를 재현할 수 있습니까?"
  ...

#!/usr/bin/env bash

review-session.sh <세션-디렉토리> <후보-패치>

set -euo pipefail
...

#!/usr/bin/env bash

gate.sh <세션-디렉토리> - 모든 사다리 항목에 답변이 있을 때까지 차단

set -euo pipefail
...

두 스크립트는 의도적으로 지루합니다. 그 가치는 순서에 있기 때문입니다. 해시가 아티팩트를 고정하고, 기본 리비전이 컨텍스트를 고정하며, 게이트는 부분적인 대화가 완료된 검토처럼 보이도록 거부합니다.

무료 모델과 무료 서버의 활용처

후보 패치는 사다리가 적용되기 전에 어딘가에서 나와야 합니다. MonkeyCode는 해당 후보를 생성하기 위한 무료 모델 액세스와, 리뷰어의 노트북이 아닌 폐기 가능한 환경에서 재현을 실행할 수 있는 무료 서버 옵션을 제공합니다. 고지: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다. 이 워크플로우에서 제품은 단 두 가지 좁은 단계에만 참여합니다. 세션이 질문할 패치를 초안 작성하는 것과, 질문 하나와 네 개가 검증되는 깨끗한 체크아웃을 호스팅하는 것입니다. 가용성, 허용 범위 및 약관은 변경될 수 있으므로, 계획된 어떤 것에 의존하기 전에 MonkeyCode 자체 문서를 통해 현재 세부 정보를 확인하십시오.

재현을 리뷰어의 장치에서 벗어나게 하는 것은 사소한 이유가 있습니다. 폐기 가능한 호스트에서의 깨끗한 체크아웃은 로컬 캐시, 에디터 플러그인 또는 부분적으로 설치된 종속성 없이 실패가 존재함을 증명합니다. 세션 로그는 다른 누구도 접근할 수 없는 워크스테이션 대신 호스트와 리비전을 기록합니다.

세션이 생성하는 결정표

제한 사항 및 사용하지 말아야 할 경우

이 워크플로우는 재현 가능한 진입점(reproducible entry point)과 헤드리스(headless)로 실행할 수 있는 최소한 하나의 자동화 테스트를 가진 저장소(repository)를 가정합니다. 오타 수정, 의존성 업데이트(dependency bumps), 한 줄 구성 변경 등에는 가치가 낮으며, 이 경우 패치 비용이 사다리 사용 비용보다 더 많이 듭니다. 매주 하나의 후보 패치를 배포하는 팀은 10~15분 세션 오버헤드를 정당화하기 어려울 것이며, 규제 데이터를 처리하는 팀은 호스팅된 무료 서비스에 소스 코드를 푸시하기 전에 공급업체 약관과 내부 정책을 확인해야 합니다.

무료 서버 옵션은 일회용 환경(disposable environment)이며, 프로덕션 자격 증명(production credentials), 고객 데이터 또는 장기 보존되는 비밀 정보(long-lived secrets)를 절대 저장해서는 안 됩니다. 또한 이 사다리(ladder)가 보안 검토(security review), 라이선스 스캔(license scan) 또는 해당 패치가 건드리는 도메인을 이해하는 사람을 대체하지는 못합니다. 기록된 결정 파일은 정확성의 증거가 아니라 프로세스의 증거로 취급해야 합니다.

명명할 가치가 있는 막다른 길 (Dead ends worth naming)

가장 비용이 많이 드는 막다른 길은 커밋되지 않은 로컬 편집(uncommitted local edit) 후에만 실패를 재현하는 패치입니다. 이 경우 첫 번째 질문에 깨끗한 답변이 없습니다. 두 번째는 병합(merge) 후에 발견되는 읽기 세트(read set)로, 보통 아무도 다시 읽지 않는 diff에서 예상치 못한 가져오기(surprise import) 형태로 나타납니다. 둘 다 세션 시작 시에는 잡기 쉽지만, 사건 검토 중 3주 후에 잡기는 비용이 많이 듭니다.

만약 팀이 아무것도 프로비저닝하지 않고도 이 패턴을 시도하고 싶다면, MonkeyCode를 통해 제공되는 무료 모델 액세스 및 무료 서버 옵션은 한 세션을 끝에서 끝까지 실행하여 사다리가 제값을 하는지 확인할 수 있는 합리적인 장소입니다.