개발자가 30초 만에 버그를 승인하는 이유와 AI 코드 리뷰
해당 블로그는 Konrad Sopala 원저자의 글 'We watched developers approve bugs in 30 seconds'을 번역한 것입니다. 더 나은 이해를 위해서 약간의 의역이 반영되었습니다.
저희는 최근 app.js 컨퍼런스의 CodeRabbit 부스에서 코드 리뷰를 속도 경쟁으로 바꿔 봤습니다. app.js, JS Nation, React Summit 세 행사에서 수백 명의 개발자에게 평소 코드를 어떻게 리뷰하는지 물었죠. 돌아온 답은 게임만큼 유쾌하지 않았습니다.
규칙은 간단했습니다. 화면에 코드 조각이 뜨면 참가자는 30초 안에 자기 휴대폰으로 승인(Approve)하거나 변경 요청(Request changes)을 합니다.
정답을 빨리 맞힐수록 높은 점수를 받기 때문에 압박 속에서 판단해야 합니다. 투표가 마감되면 놓친 버그와 그 수정안을 공개했죠.
라운드를 거듭할수록 같은 일이 반복됐습니다. 버그가 화면에 뜨고 시계가 돌면 방 안의 상당수가 자신 있게 그 코드를 통과시켰습니다. 버그가 얼마나 "뻔한지"는 사람들이 빠른 속도에서 그 버그를 잡아내는지 여부와 거의 관계가 없었습니다.
그리고 여러분과 이야기를 나눴습니다
세 컨퍼런스 동안, 그리고 게임 라운드 사이사이에 저희는 수백 명의 개발자와 실제로 코드를 어떻게 리뷰하는지 대화했습니다. 같은 주제가 몇 번이고 다시 나왔는데 한 번 짚어볼 가치가 있습니다. 대부분이 팀들이 생각하는 리뷰의 작동 방식과 어긋나거든요.
"이미 내장되어 있으니까요"
가장 흔하게 들은 구성은 코드 호스트에 기본으로 딸려 온 리뷰 봇이었습니다. 이미 PR 안에 있고 새 탭을 하나 덜 열어도 되니까요.
그 논리는 이해합니다. 코드 리뷰계의 사무실 냉장고 샌드위치인 셈이죠. 바로 거기 있고 가게는 한참을 걸어가야 하니까요. 그런데 같은 대화에서 리뷰가 출시를 가로막는 병목 중 하나라고 말한 개발자가 바로 그들이었습니다.
무언가가 실제로 팀의 속도를 늦추고 있다면 그 문제를 해결할 도구의 기준이 "미리 설치되어 있었다"는 건 이상한 잣대입니다.
저희는 그 기준을 끌어올릴 가치가 있다고 봅니다. 코드 리뷰는 동료가 직접 남긴 것처럼 읽혀야지, 유의어 사전을 든 린터처럼 읽혀선 안 됩니다. 도구가 레포에 맞춰 휘어진 부분이 아니라, 레포를 도구에 맞추도록 휘게 만든 부분을 짚어야 하죠. 코드 리뷰와 관련된 모든 요소는 리뷰 품질을 중심으로 설계되어야 합니다.
"에이전트가 괜찮다고 했으니 괜찮은 거죠"
저희가 만난 개발자 중 상당수는 코드를 작성한 바로 그 코딩 에이전트로 코드를 리뷰합니다. 별도의 리뷰 단계가 아니라, 도구가 이미 열려 있고 그 도구가 코드를 작성했으니 코드 검사까지 맡기는 식이죠.
저희가 우려하는 건 에이전트가 답을 내놓은 다음입니다. 아무 일도 일어나지 않습니다. 에이전트가 판결을 내리면 개발자는 그대로 받아들이죠. 반박도, 추가 질문도, 비집고 들어갈 틈도 없습니다. 상호작용 전체가 한 방향으로만 흐릅니다.
그렇게 판단은 코드를 생성하라고 만들어진 도구, 풀 리퀘스트를 두고 대화하라고 만들어지지 않은 도구에 외주로 넘어가고 그 대화마저 멈춰 버립니다.
리뷰는 주고받는 과정이어야 합니다. 있는 그대로 받아들이면 손에 쥐는 건 포춘 쿠키 한 장에 불과합니다.
"제가 더 좋고 더 싸게 직접 만들 수 있어요"
여기 직접 사내에서 만들겠다는 개발자가 있습니다. 모델은 바로 거기 있고 API는 싸니, 얼마나 어렵겠냐는 거죠. 며칠씩 짬을 내면 전용 도구가 부르는 값의 일부만으로 자기 스택에 딱 맞는 리뷰어를 갖게 되리라는 계산입니다.
쉬운 일이 아닙니다.
이 주제를 여기서 다시 처음부터 따지지는 않겠습니다. 이미 자세히 다룬 적이 있거든요. 사내 AI 코드 리뷰 도구는 생각보다 비쌉니다. 핵심만 짚자면 모델 호출은 싼 부분입니다. 비싼 건 그 주변을 둘러싼 모든 것입니다. 컨텍스트 엔지니어링, 디프의 모든 줄에 플래그를 달지 않도록 하는 잡음 억제, 통합, 유지보수, 그리고 정작 돈을 받고 만들어야 할 제품 대신 코드 리뷰 도구에 투입되는 엔지니어 수개월의 시간이죠. "비용의 일부"라는 계산은 그 작업에 인건비를 한 푼도 매기지 않을 때만 성립합니다.
직접 만들어 보는 일은 어려운 부분이 애초에 AI가 아니었다는 사실을 가장 비싸게 배우는 방법입니다.
컨퍼런스의 모든 개발자가 동의한 한 가지
도구를 둘러싼 논쟁을 걷어내고 나면, 아무도 이견을 달지 않은 믿음이 하나 있었습니다.
"손으로 다 리뷰하기엔 너무 많은 코드를 출시합니다. 그 배는 이미 떠났고 예전 방식으로 돌아갈 수는 없습니다."
에이전트가 만들어 내는 코드의 양은 우상향하고 있고 조만간 줄어들 기미가 없습니다. 개발자는 이제 손으로 작성하는 코드는 줄었지만 그 어느 때보다 훨씬 많은 코드를 리뷰합니다. 그게 지금 개발자의 일이고 어려운 일입니다. 디프가 점점 커지면서 인지 과부하가 걸릴 때도 있죠. 게다가 저희는 여전히 사람이 작성한 코드를 위해 만들어진 플랫폼, AI가 만든 코드를 위한 게 아닌 플랫폼에서 코드를 리뷰하고 있습니다.
AI 코드 리뷰는 팀이 충분히 성숙했을 때 도입하는 있으면 좋은 기능이 아닙니다. 지금 소프트웨어가 출시되는 방식을 떠받치는 내력벽입니다. 저희가 정의하려고 나선 카테고리가 바로 이것입니다. 문장을 채 끝내기도 전에 컨퍼런스의 모두가 이미 동의하는 보기 드문 주제이기도 합니다.
관련해서 사내 직접 구축의 함정을 더 깊이 파고든 사내 AI 코드 리뷰 도구의 진짜 비용과, 코드를 작성한 에이전트에게 리뷰까지 맡기면 왜 위험한지 다룬 코드 리뷰는 독립적이어야 합니다를 함께 읽어 보시길 권합니다. 사람과 AI의 분업이 궁금하시다면 AI 코드 리뷰 vs 사람 코드 리뷰도 도움이 됩니다.