Return on Attention: Why AI Code Reviews Are Wearing Us Out
PR volume went up, ticket quality didn't, and the gap got filled with LLMs on both sides of the review: bots reviewing, bots replying, bots occasionally arguing with bots about priorities that only existed in a teammate's head. Our CEO named the actual problem, and it's bigger than code review.
개요 #
팀이 커지면 코드도 많아진다. 그런데 코드가 많아진다고 그만큼 서로가 아는 맥락까지 늘어나진 않는다. 한 개발팀이 겪은 문제가 정확히 여기서 시작됐다. PR은 늘었고, 리뷰는 느려졌고, 그 틈을 AI가 메웠다. 봇이 리뷰를 달면 다른 봇이 답을 달고, 가끔은 봇끼리 존재하지도 않는 우선순위를 두고 논쟁까지 벌였다.
몇 주 뒤 이 팀의 CEO가 슬랙에 남긴 한마디가 문제의 본질을 짚었다. 병목은 코드 리뷰가 아니라 숙련된 동료의 유한한 주의력이라는 것. 값싸게 쏟아낸 장황한 글이 정작 읽는 사람에게는 비싼 비용을 물린다는 이야기다.
봇이 리뷰하고, 봇이 답하는 풍경 #
이 팀은 올해 사람이 늘면서 PR 물량도 함께 불었다. 티켓이 생기는 속도보다 코드가 파이프라인을 지나는 속도가 더 빨랐다. 문제는 양이 아니라 이해였다. 큰 PR 하나를 읽으려면 "이게 무슨 문제를 푸는지, 왜 이 방식인지, 뭐가 핵심이고 뭐가 부차적인지"를 처음부터 따라가야 했다.
리뷰가 어려워지고 느려지자 사람들은 속도를 맞출 도구에 손을 뻗었다. 모든 PR에 자동으로 붙는 AI 리뷰 봇이 하나 있었고, 여기에 더해 많은 팀원이 각자 선호하는 LLM과 코딩 에이전트를 로컬에서 돌려 리뷰 코멘트 초안을 뽑았다. 둘을 합치면 결과는 뻔하다. 봇이 코멘트를 달고, 다른 봇이 거기에 답한다. LLM이 자신 있게 "버그"라고 보고한 것 중 일부는 애초에 존재하지도 않는 문제였다. 모델은 그게 진짜가 아니라는 걸 알 방법이 없으니까. AI 코딩 보조의 진짜 약점, 바로 자신만만한 오답이다.
무엇이 문제였나 #
코멘트가 그걸 썼다는 동료의 말투처럼 들리지 않았다. 장황했고, 순간에 필요하든 아니든 온갖 참고 링크와 인용이 다 붙어 있었다. 평소 각자의 말로 담백하게 코드를 이야기하던 팀이었는데, PR은 AI가 뱉은 군더더기로 채워지기 시작했다.
불만은 크게 두 갈래였다.
첫째, 맥락을 얻으려고 PR 밖으로 나가야 했다. 코멘트 자체에 필요한 내용이 없거나, 반대로 채워 넣은 말이 너무 많아서 사람이나 모델을 따로 찾아 물어봐야 했다. 원래 PR 코멘트의 존재 이유는 "그것만 보면 다른 데 안 가도 되는 것"인데 정반대가 됐다.
둘째, 중복과 다시 읽는 비용. 1분이면 직접 읽을 코드를 굳이 문단으로 풀어 설명하는 건 시간을 아껴주지 않는다. 오히려 코멘트가 아껴줬어야 할 시간 위에 읽는 시간을 얹는다.
한 팀원은 이렇게 말했다. "지금 뭐가 맞는 균형인지는 모르겠지만, 패러다임 자체가 바뀐 건 분명하다." 맞는 말이다. 다만 지금 하는 방식이 유일한 방식이라고 단정할 이유도 없다.
진짜 희소 자원은 '주의력' #
CEO의 지적은 이 지점을 정확히 겨눴다. PR 리뷰를 둘러싼 불만은 진짜였지만, 그건 증상이지 병 자체가 아니었다. 실제 병목은 리뷰라는 특정 작업이 아니라, LLM이 찍어내는 콘텐츠에 쉽게 압도되는 사람의 유한한 주의력이었다.
그는 이걸 Return-on-Attention(ROA), 즉 '주의력 대비 수익'이라 불렀다. 남에게 읽어달라고 요청하는 모든 단어는, 그 사람이 읽는 데 드는 비용만큼의 값어치를 해야 한다는 원칙이다. 값싸게 만들어 비싸게 소비시키는 글을 서로에게 떠넘기는 건 안티패턴으로 취급해야 한다는 것.
근거로 같은 주 안에서 나온 두 사례를 들었다. 하나는 반복 서술이 잔뜩 들어간 ADR 문서였다. 동료가 그 반복을 전부 읽어야 했으니 ROA가 형편없었다. 다른 하나는 디렉터리 하나를 gitignore 처리한, 코드로는 딱 한 줄에 열 글자짜리 PR이었다. 그런데 설명이 1,430자에 달했다. 리뷰하는 사람 입장에서 역시 최악의 ROA다.
두 사례 모두 코드 품질 이야기가 아니다. 30초의 편집 수고를 아끼려고 남의 주의력을 얼마나 써도 되는가에 대한 이야기다.
같은 개념의 공개판도 있다. noslopgrenade.com은 이를 "슬롭 수류탄(slop grenade)"이라 부른다. 사람이라면 한 문장으로 끝냈을 자리에 AI가 뱉은 거대한 답변을 그대로 붙여 넣는 행위다. 채팅과 이메일을 겨냥한 표현이지만 코드 리뷰에서 벌어지는 실패와 똑같다. LLM은 과제에 필요한 것보다 훨씬 많은 단어를 공짜로 만들어내지만, 그 잉여의 비용은 사라지지 않는다. 그저 읽는 사람에게로 옮겨갈 뿐이다.
인정하기 싫은 부분 #
글쓴이는 자신에게서도 같은 이끌림을 느꼈다고 고백한다. 리뷰어로서가 아니라 생각하는 사람으로서다. 문제를 충분히 붙들고 씨름하기도 전에 모델에게 넘겨버리는 구간이 있었고, 그럴 때 자기 작업의 규율이 느슨해지는 게 느껴졌다. 답이 틀려서가 아니라, 먼저 스스로 풀어보고 나서 질문하는 그 순서를 건너뛰기 시작했기 때문이다.
또 하나, Claude의 특정 습관과 씨름 중이라고 한다. 설계 결정을 코드 주석에 서술하는 버릇이다. "우리는 저것 말고 이걸 택했다" 같은 문장이 시키지도 않았는데 튀어나오는데, 한 번도 도움이 된 적이 없다. 그런 결정은 맥락과 날짜와 작성자가 붙는 PR 설명이나 커밋 메시지에 들어가야 한다. 코드 주석에 박혀 있으면, 누군가 마음을 바꾸고 아무도 그 주석 지우는 걸 기억 못 하는 다음 순간에 곧장 틀린 정보가 되는 소음일 뿐이다. 그래서 이 패턴을 코드베이스에 쓰지 못하게 막는 스킬을 직접 만드는 중이라고 한다.
선은 어디에 있나 #
봇 리뷰 자체가 문제는 아니다. 잘못 쓰는 게 문제다.
리뷰어가 스스로는 못 찾았을 각도를 제시하거나, 버그와 놓친 엣지 케이스, diff 안에 앉아 있던 진짜 문제를 잡아줄 때 봇은 유용하다. 두 번째 눈으로 실제로 돕는 것이다.
하지만 아껴주는 것보다 더 많은 주의력을 읽는 사람에게 물리는 순간, 유용함은 끝난다. 리뷰가 존재하는 이유는 가치를 배포하고 사람 사이에 지식을 넘기기 위해서다. 코드 품질이 중요한 건 그 목적에 봉사하기 때문이지 그 반대가 아니다. 코멘트가 코드를 조금 낫게 만들었더라도 리뷰어를 더 지치게 했다면, 그건 할 만한 거래가 아니다.
결국 당신 이름으로 남는다 #
글쓴이가 쓰는 규칙 하나. 리뷰 코멘트를 올리는 순간, 그건 당신에게 귀속된다. 코딩 에이전트가 공동 저자일 수는 있지만, 나중에 후속 대응을 할 사람은 그 에이전트가 아니다. PR 작성자가 질문이나 반박을 들고 찾아올 상대도 에이전트가 아니라 당신이다.
PR 작성자는 그 코멘트가 어떻게 쓰였는지 알 길이 없다. 물론 눈치는 챌 것이다. 특히 em 대시를 여기저기 뿌려놨다면 더더욱. 어쨌든 그들은 그 코멘트를 당신의 판단, 당신의 목소리로 읽고, 당신이 한 글자 한 글자 직접 친 것과 똑같이 당신에게 책임을 묻는다.
그러니 제출 버튼을 누르기 전 기준은 하나다. "나라면 이 길이로, 이 톤으로 이렇게 말했을까?" 답이 '아니오'라면 해법은 더 좋은 프롬프트가 아니다. 편집이다. 당신답지 않은 부분을 덜어내면 된다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.