'LGTM' 한 줄에 담긴 책임
코드 리뷰를 해보셨다면 이런 경험이 한 번쯤 있을 거예요. 파일 40개에 1,500줄이 바뀐 PR이 올라오고, 작성자는 '급한 건이라 오늘 안에 머지 부탁드려요'라고 해요. 처음엔 위에서부터 꼼꼼히 읽는데, 스무 번째 파일쯤 가면 집중력이 바닥나요. 결국 'LGTM(Looks Good To Me, 제가 보기엔 괜찮아요)' 한 줄 남기고 Approve를 누르게 되죠. 그런데 이 승인 버튼에는 '이 변경을 프로덕션에 내보내도 된다고 내가 보증한다'는 책임이 들어 있거든요.
오늘 볼 Farol은 바로 이 문제를 노린 오픈소스 프로젝트예요. 소개 문구는 'PR을 승인하는 사람을 위한, 그 PR의 리스크 맵(risk map)'이에요. Farol은 포르투갈어로 '등대'라는 뜻인데요. 리뷰어가 diff를 읽을 때 암초가 어디 있는지 먼저 비춰주겠다는 뜻으로 지은 이름이에요.
리스크 맵이 뭐냐면
지금 쓰는 코드 리뷰 화면은 모든 변경을 똑같은 비중으로 보여줘요. README 오타를 고친 한 줄과 결제 금액 계산 로직을 바꾼 한 줄이 같은 크기, 같은 모양으로 나란히 나와요. 그래서 '여긴 대충 봐도 되고 여긴 꼼꼼히 봐야 해'를 리뷰어가 머릿속에서 직접 판단해야 하죠. 시니어는 경험으로 해내지만, 코드베이스를 잘 모르는 사람한테는 거의 불가능한 일이에요.
리스크 맵은 이 판단을 눈에 보이게 그려주는 거예요. 지하철 노선도에서 환승역이 크게 표시되듯이, PR 안에서 '터지면 크게 터질 곳'을 도드라지게 보여줘요. 이런 도구들이 흔히 참고하는 신호는 이런 것들이에요.
- 영향 범위(blast radius): 바뀐 함수를 몇 군데에서 호출하는지
- 민감 경로: 인증, 결제, DB 마이그레이션, 인프라 설정처럼 실수하면 비싼 영역인지
- 변경 이력(churn): 최근에 버그 수정이 몰렸던 '사고 다발 구역'인지
- 테스트 동반 여부: 로직은 바뀌었는데 관련 테스트는 그대로인지
작성자가 아니라 승인자를 돕는 도구
요즘은 AI 코드 리뷰 봇이 정말 많잖아요. CodeRabbit이나 GitHub Copilot 코드 리뷰 같은 도구는 대부분 코드에 직접 코멘트를 달아서 고치게 하는 방식이에요. 작성자를 돕는 도구에 가깝죠. 그런데 Farol은 대상을 '승인하는 사람'으로 좁혔어요. 버그를 대신 찾아주는 게 목적이 아니에요. 리뷰어가 한정된 집중력을 어디에 써야 하는지 알려주는 게 목적이에요.
이 차이가 생각보다 커요. 마이크로소프트 연구진이 코드 리뷰를 분석한 연구(Bacchelli & Bird, 2013)를 보면, 개발자들은 리뷰의 주목적을 '결함 찾기'라고 기대해요. 그런데 실제로는 코드를 이해하고 지식을 나누는 효과가 더 크게 나타났어요. 한 번에 리뷰하는 양이 일정 수준을 넘으면 결함을 찾는 효율이 뚝 떨어진다는 이야기도 업계에서 오래 나왔고요. 집중력에는 한계가 있으니까, 모든 줄을 똑같이 보는 것보다 위험한 곳에 힘을 몰아주는 게 현실적인 방법이에요.
비슷한 시도들과 비교하면
완전히 새로운 아이디어는 아니에요. GitHub의 CODEOWNERS는 특정 경로가 바뀌면 지정된 담당자를 리뷰어로 꼭 넣게 해서 민감 경로를 관리해왔어요. Danger.js는 'PR이 너무 크다', '마이그레이션 파일이 있는데 설명이 없다' 같은 규칙을 자동으로 경고해주고요. Adam Tornhill의 책 『Your Code as a Crime Scene』에서 출발한 CodeScene은 git 이력을 분석해서 문제가 자주 생기는 핫스팟을 찾아주는 기능을 상용 제품으로 만들었어요.
Farol 같은 도구는 이렇게 여기저기 흩어진 신호를 '이번 PR' 하나에 대한 지도로 모아서, 승인하는 순간에 보여준다는 점이 달라요. 지금은 AI가 코드를 쏟아내면서 PR 크기와 개수가 같이 늘고 있어요. 병목도 '코드 작성'에서 '코드 검증'으로 옮겨가고 있고요. 리뷰어의 집중력을 관리해주는 도구는 앞으로 점점 더 중요해질 거예요.
한국 개발자에게 주는 시사점
당장 써볼 만한 상황은 꽤 분명해요. 첫째, 주니어도 리뷰어로 들어가는 팀이에요. 리스크 맵이 '어디를 봐야 하는지' 알려주는 가이드 역할을 해서, 리뷰하면서 배우는 속도도 빨라질 수 있어요. 둘째, AI가 쓴 코드 비중이 늘어난 팀이에요. AI가 쓴 코드는 겉보기엔 사람이 쓴 코드보다 더 그럴듯할 때가 많아서, 위험한 곳을 먼저 짚어주는 게 큰 도움이 돼요. 셋째, 금융이나 커머스처럼 변경 관리와 감사 대응이 중요한 조직이에요. '이 PR이 왜 위험했고 누가 어떤 근거로 승인했는지' 기록을 남기는 흐름과 잘 맞거든요.
다만 도입하기 전에 팀이 먼저 '우리 팀에게 위험이란 뭔가'를 정리해보길 추천해요. 결제 모듈이 핵심인 팀과 ML 파이프라인이 핵심인 팀은 위험 지도가 완전히 다르거든요. 지도는 도구가 그려줘도, 어디가 암초인지 정하는 건 결국 팀의 몫이에요.
마무리
한 줄 정리: 리뷰를 잘하려면 더 많이 읽기보다 어디를 읽을지 알아야 하고, Farol은 그걸 승인하는 사람 눈앞에 지도로 보여주려는 도구예요.
여러분 팀은 큰 PR을 리뷰할 때 어디부터 보시나요? 그리고 '이 PR은 위험하다'는 판단을 도구에 맡겨도 믿을 만하다고 보시나요?
🔗 출처: Hacker News