AI가 만든 Biff 코드, 수정 전에 리뷰 지적을 확인하는 법

“고쳤다”는 답을 받기 전에 지적 목록부터 볼 수 있다

Biff의 새 코드 리뷰 스킬은 문제를 찾는 단계와 코드를 고치는 단계를 나눈다. 검토 결과를 날짜별 파일에 남기고, 개발자가 그 목록을 확인한 다음 수정을 진행하는 방식이다. Clojure 웹 프레임워크 Biff의 제작자 Jacob O’Bryant는 10월 25일 공개한 2.0.4 소개에서 자신이 AI 생성 코드를 검토하며 모은 관례를 스킬로 제공한다고 밝혔다.

biff-code-review의 실제 지침은 체크리스트를 .biff/review/날짜/번호.txt에 복사하도록 한다. 위반이 없는 규칙은 체크하고, 위반이 있는 규칙은 비워 둔 채 해당 파일명과 줄 번호를 적는다. 검토를 마치면 사용자에게 파일 경로를 알려 주고 목록이 맞는지 확인받는다.

개발자는 이때 AI가 놓친 지적을 추가할 수 있다. 이후 에이전트는 체크리스트를 바꾸지 않고 코드만 수정하며, 항목을 최종 확인하는 역할은 사용자에게 남는다. 수정 요청의 원래 범위를 다시 볼 수 있다는 점이 핵심이다. 파일 자체가 쓰기 금지로 잠기는 기능은 아니며, 스킬에 적힌 작업 절차다.

일반적인 코드 품질보다 Biff의 구조를 검사한다

검사 대상은 Biff 프로젝트가 따르도록 정한 구체적인 관례다. 규칙 파일에는 모듈 배치, 상태 관리, 데이터 조회 방식처럼 테스트 성공 여부만으로 드러나지 않는 구조적 선택이 들어 있다.

이는 Clojure 언어 전체의 금지 규칙이 아니다. Biff의 구조에 맞는 코드를 만들기 위한 기준이다. 다른 프레임워크에 그대로 붙이면 그 프로젝트의 설계와 충돌할 수 있다.

스타터 README는 테스트·린트를 실행하고 실패를 고치는 biff-code-quality도 별도로 설명한다. 관례 리뷰와 실행 검사는 서로 다른 작업이므로, 리뷰 목록이 정리됐다는 이유만으로 테스트까지 성공했다고 볼 수는 없다.

tasks를 올리고 개발 명령을 실행하면 동기화된다

기존 Biff 프로젝트에서는 biff.tasks 의존성을 2.0.4로 올린 뒤 clj -M:run dev를 실행하는 것이 발표문에 제시된 적용 경로다. 이 과정에서 스킬이 로컬 프로젝트로 동기화된다. 변경 이력에는 문서를 .biff/, 스킬을 .agents/로 복사하는 변경과 2.0.4의 리뷰 스킬 갱신이 기록돼 있다.

처음 시작하는 프로젝트는 스타터가 요구하는 Java 21 이상과 Clojure가 필요하다. 스킬을 가져온 뒤에는 사용하는 코딩 에이전트가 프로젝트의 .agents/skills/를 읽는지도 확인해야 한다. 파일이 생기는 것과 에이전트가 실제로 규칙을 따르는 것은 다른 문제다.

리뷰 범위에도 순서가 있다. 미커밋 변경이 있으면 그것을 검토하고, 없으면 현재 브랜치에서 main 또는 master에 없는 커밋을 본다. 두 조건에 해당하지 않으면 사용자에게 검토 대상을 묻도록 되어 있다. 저장소 전체를 언제나 훑는 도구로 이해하면 검토 범위를 잘못 기대하게 된다.

auto는 대기를 생략하고, fix는 남은 지적을 이어서 고친다

수정 전에 사람이 확인하려면 기본 흐름을 사용해야 한다. 스킬 호출에 auto를 붙이면 에이전트가 목록을 만든 직후 확인을 기다리지 않고 수정을 시작한다. 그래도 원래 위반했던 항목은 체크하지 않은 채 남겨, 사용자가 나중에 완료를 확인하거나 추가 변경을 요청할 수 있게 한다.

fix는 가장 최근 리뷰 파일을 찾아 그 안의 지적을 이어서 고치는 경로다. 새로운 검토를 할 때마다 같은 문제를 설명하는 대신, 남아 있는 항목을 기준으로 다시 작업시킬 수 있다.

수정 전 확인이 필요한 팀이라면 기본 리뷰로 목록을 먼저 읽고, 누락된 항목을 보탠 뒤 수정을 맡기는 순서가 맞다. 개발자는 남겨 둔 지적 목록을 실제 코드 변경과 대조하며 완료 여부를 판단할 수 있다.