리뷰어는 12초 만에 AI 코멘트를 수락하지만, 그 코멘트가 어떤 저장소 규칙(repository rule)을 강제하는지 또는 무엇이 잘못될 수 있는지 설명하지 못합니다. 수락 자체는 효율적으로 보일 수 있으나, 이는 이해도를 나타내는 취약한 증거입니다. 맞춤형 리뷰 지침(Custom review instructions)은 의사결정 시점에서 연구되어야 하며, 이해도(comprehension)와 안전한 거부(safe refusal)는 별도로 측정되어야 합니다.

GitHub의 7월 17일 코드 리뷰 커스터마이징 변경 로그(code review customization changelog)는 최신으로 확인된 공식 신호입니다. 이는 헤드 브랜치(head-branch) 맞춤형 지침, 설정, 그리고 방화벽/러너(firewall/runner) 제어에 대해 설명합니다. 7월 10일 GitHub 사례 연구(GitHub case study)에 따르면, 도구 교체 초기에는 비용이 더 많이 들고 더 적은 이슈를 발견했습니다. 그러나 이후 지침을 재작성함으로써 리뷰 품질을 유지하면서 평균 리뷰 비용을 약 20% 절감했습니다. 이는 벤더(vendor)가 보고한 사례 결과이며, 보편적인 벤치마크(benchmark)는 아닙니다. 확인되지 않은 7월 27일의 2차 주장들은 거부되었습니다.

연구 질문 (Research question)

저장소별 지침(repository-specific instructions)이 존재할 때, 리뷰어가 안전하지 않은 수락을 늘리지 않으면서 코멘트의 근거, 결과 및 한계를 더 잘 설명할 수 있는가?

“사용자가 그것을 신뢰하는가?”라고 묻지 마십시오. 참가자들에게 제한된 병합 결정(bounded merge decision)을 내리고 이를 설명하도록 요청하십시오.

연구 조건 (Study conditions)

상쇄 균형 내 피험자 간 연구(counterbalanced within-subject study)에서 동일한 4개의 합성 풀 리퀘스트(synthetic pull requests)를 사용합니다:

조건 C는 GitHub에 대한 비난이 아니라 신뢰 경계(trust boundary)를 테스트합니다. PR이 코드와 지침을 모두 변경한다는 점을 명확히 보여주십시오. 기본 정책(base policy) 하에서 리뷰를 중단, 분할 또는 계속해야 하는지 질문하십시오.

시나리오 카드 (Scenario card)

의사결정권자: 풀 리퀘스트(pull-request) 리뷰어
결과: 변경 사항 병합 권한 부여 동작
가역 가능 시점: 병합 전까지
...

각 선택 이후에 관련 규칙(rule), 근거가 되는 라인/테스트(supporting line/test), 결정 반증 사례(decision falsifier), 그리고 PR이 자체 리뷰 지침을 변경했는지 여부를 질문합니다. 신뢰도(confidence)나 유창함(eloquence)이 아닌, 미리 정의된 루브릭(rubric)을 점수화합니다.

측정 지표 (Measures)

증거 회상(evidence recall), 결과 정확도(consequence accuracy), 헤드 정책 경계 탐지(head-policy boundary detection), 안전하지 않은 수락(unsafe acceptance), 정당한 거절(justified refusal), 그리고 결정까지 걸린 시간(time to decision)을 점수화합니다. 수락(acceptance) 비율 자체만으로도 진단이 가능합니다. 수락률이 낮다는 것은 혼란을 의미하거나, 혹은 적절하게 더 엄격한 리뷰가 이루어지고 있음을 의미할 수 있습니다.

정상 경로 및 실패 경로 (Normal and failure paths)

정상 경로(Normal path): 참가자가 승인된 지침을 검토하고, 올바른 코멘트를 코드 및 테스트 증거와 연결하며, 반증 사례를 진술하고, 수정이 필요한 결정을 내립니다.

실패 경로(Failure path): 헤드 브랜치(head branch)가 지침을 약화시키고 코멘트가 수락을 권장하는 경우입니다. 만약 참가자들이 권한이 변경되었음을 인지하지 못한 채 이를 따른다면, 파일럿(pilot) 확장을 중단하고 출처(provenance)를 재설계해야 합니다. 즉, 베이스(base)/헤드(head) 지침의 차이(diff)를 보여주고, 출처를 라벨링하며, 독립적인 리뷰를 요구해야 합니다.

만약 참가자들이 위험을 감지했지만 그 출처를 찾지 못한다면, 더 빠른 클릭을 훈련시키기보다는 정보 구조(information architecture)를 수정해야 합니다.

프로토콜 및 중단 조건 (Protocol and stop conditions)

• 표현된 언어를 실제로 리뷰하는 사람들을 모집합니다. 경력(seniority)을 정답으로 간주하지 않고 경험을 기록합니다.
• 시나리오 순서를 무작위화하고 조건 라벨을 순환(rotate)시킵니다.
• 지침 변형(instruction variants) 전반에 걸쳐 코드 난이도와 결과(consequence)를 일정하게 유지합니다.
• 중재자 노트(moderator notes), 참가자 진술, 루브릭 점수를 분리합니다.
• 프로토타입이 의도된 정답을 유출하거나, 시나리오에 방어 가능한 결정이 없는 경우 중단합니다.
• 안전하지 않은 수락(unsafe acceptance)이 팀이 사전에 선언한 상한선을 초과하면 배포(rollout)를 일시 중지합니다.
• 키보드 및 확대(zoom) 사용을 포함하여 반복합니다. 색상 없이도 지침의 출처(provenance)를 인지할 수 있는지 확인합니다.

쌍을 이룬 루브릭 차이를 분석하고 표본 크기, 누락된 세션, 코더 간 불일치(coder disagreements), 제외 사례를 보고합니다. 이러한 고정 요소(fixtures)들은 실제 운영 품질을 증명하거나 GitHub의 비용 결과를 재현할 수는 없습니다.

가시적인 소스 레이블(source labels)이나 diff와 지침을 함께 배치하는 것이 증거가 될 수 있습니다. 안전하지 않은 수락(unsafe acceptance)이 감소한다면, 결정 속도가 느려지는 것도 가치가 있을 수 있습니다. 러너/방화벽(Runner/firewall) 제어는 별개의 실행 제약 조건이지, 이해도(comprehension)의 증거가 아닙니다.

마지막 플랫폼 연구 옵션

MonkeyCode는 프로토콜이 확정된 후에만 별도의 프로토타입 환경으로 포함될 수 있습니다. 검증된 자료에 따르면, 이는 해외 온라인 옵션, 관리형 서버 측 클라우드 개발 환경(managed server-side cloud development environments), 모델/태스크/요구사항 관리, 빌드/테스트/미리보기, 그리고 무료 시작 액세스를 제공하는 오픈 소스 AGPL-3.0 AI 개발 플랫폼입니다. 저는 그곳에서 이 연구를 수행하지 않았습니다. 공식 캠페인 링크를 사용하여 검토할 경우, 참가자를 독립적으로 모집하고 유도하지 마십시오.

공개 사항: 이 기사는 공식 캠페인 링크를 사용하여 MonkeyCode를 홍보합니다. 저는 MonkeyCode 사용자이며 프로젝트와 관련이 없으며, 이 링크를 통해 어떠한 수수료도 받지 않습니다.

AI 지원 공개: 이 기사는 AI의 지원을 받아 초안이 작성되었으며, 인용된 1차 자료를 바탕으로 검토되었습니다.