짚을 것과 넘길 것

요즘 들어 리뷰를 하다 말고 멈칫하는 순간이 잦아졌다.

도구가 코드를 빠르고 정확하게 내놓는다. 예전 같으면 한참 들여다봐야 했을 코드가, 이제는 꽤 표준적인 모습으로 단숨에 나온다. 그 코드를 앞에 두고 나는 자주 묻게 된다. 이걸 어디까지 봐야 하는가. 한 줄 한 줄 의도를 따지는 일이 아직 내 몫인가, 아니면 이미 도구에게 넘겨도 되는 일인가.

리뷰가 느려 보이기 시작할 때

생산 속도가 빨라지면, 꼼꼼히 보는 일이 어느 순간 흐름을 막는 것처럼 보이기 시작한다. 다들 빠르게 짓고 빠르게 넘기는데, 거기서 멈춰 "이건 왜 이렇게 하셨어요"라고 묻는 사람은 자칫 속도를 갉아먹는 사람이 된다.

그래서 편한 결론이 하나 있다. 동작에 문제가 없고 도구가 내놓을 법한 표준적인 모양이면, 그냥 합의하고 넘어가자는 것이다. 틀린 말은 아니다. 다만 나는 그 결론이 너무 빨리 내려질 때 마음이 불편하다. '동작에 문제가 없다'와 '이 자리에 맞다'는 같은 말이 아니기 때문이다.

실제로 1억 5천만 줄의 코드를 분석한 한 조사는, AI 도구가 퍼진 뒤 작성된 지 2주도 안 돼 되돌려지거나 갈아엎어지는 코드의 비율이 뚜렷이 늘었다고 보고한다(GitClear, 2024–25). 빠르게 나온 코드가 늘 맞는 코드는 아니었던 셈이다.

그리고 하나는 분명히 해두고 싶다. 도구가 코드를 더 많이 쏟아내는 것을, 우리는 너무 쉽게 '생산성이 올랐다'고 말한다. 하지만 2주도 못 가 지워질 코드를 더 빨리, 더 많이 만든 것이 대체 어떤 의미의 생산성인가. 그건 생산성이 아니라 그냥 양(量)이다. 측정하기 쉬운 숫자를, 측정해야 할 가치와 바꿔치기한 것에 가깝다. 쏟아낸 줄 수가 늘었다는 사실 자체는 아무것도 증명하지 않는다. 생산성은 코드의 양이 아니라, 그 코드가 무엇을 풀었고 얼마나 오래 살아남았는가로만 매겨진다.

"내 능력의 90%는 가치가 0달러로 떨어졌다. 남은 10%의 영향력은 1000배가 됐다. 다시 보정해야 한다."
— 켄트 벡(Kent Beck), 「90% of My Skills Are Now Worth $0」(2023)

리뷰는 원래 무엇을 보는 일이었나

생각해보면 리뷰는 오타나 문법을 잡는 일이 아니었다. 그런 것은 가장 값싼 축에 속하고, 지금은 도구가 가장 잘하는 일이기도 하다.

"AI가 내놓는 한 조각 한 조각을, 코드 양으로는 무척 생산적이지만 어딘가 미덥지 않은 동료가 보낸 풀 리퀘스트처럼 다뤄야 한다."
— 마틴 파울러(Martin Fowler), The New Stack 인터뷰(2026)

리뷰가 진짜로 하는 일은 의도와 코드 사이의 거리를 좁히는 것이었다. 이 코드가 우리가 생각한 그것을 정말로 말하고 있는지, 놓일 자리에 맞게 쓰였는지를 맞춰보는 일. 그건 규칙을 대조하는 일이 아니라 판단하는 일이다.

그렇다면 도구가 규칙 대조를 가져갈수록 리뷰의 가치는 사라지는 게 아니라 위로 옮겨간다. 기계가 채워주는 표준이 흔해질수록, 사람이 보아야 할 것은 오히려 또렷해진다. 옳은 코드인지가 아니라, 지금 여기에 맞는 코드인지.

경계는 양이 아니라 종류의 문제

그래서 질문을 바꿔야 한다고 생각하게 됐다. "얼마나 리뷰할 것인가"는 틀린 질문이다. 많이 보느냐 적게 보느냐의 문제가 아니다. 진짜 질문은 "무엇은 사람만이 볼 수 있는가"이다.

기계적이고 표준적인 것은 도구에 맡긴다. 사람의 주의는 의도와 맥락, 트레이드오프, 정답이 하나로 떨어지지 않는 것들에 아껴 쓴다. 경계는 리뷰의 분량을 줄이는 선이 아니라, 무엇을 어느 쪽에 둘지 가르는 선이다.

"LLM이 코드의 모든 줄을 썼더라도, 당신이 그 전부를 리뷰하고 테스트하고 이해했다면 그것은 바이브 코딩이 아니다."
— 사이먼 윌리슨(Simon Willison), 「Not all AI-assisted programming is vibe coding」(2025)

같은 이유로, 내가 남기는 코멘트도 두 종류로 나뉜다. 하나는 명백한 것 — 약속한 의도와 코드가 어긋나 있는 지점. 다른 하나는 갈릴 수 있는 것 — 취향이나 무게가 사람마다 다른 지점. 이 둘을 같은 강도로 들이밀 때 리뷰는 무거워진다. 앞엣것은 분명히 짚고, 뒤엣것은 가볍게 건넨다. 경계를 잘 긋는다는 건, 모든 관찰에 같은 무게를 싣지 않는 일이기도 하다.

혼자 그은 선은 반드시 부딪힌다

여기까지는 나 혼자의 정리다. 그리고 정작 어려운 건 그다음이었다.

경계는 내가 혼자 그을 수 있는 것이 아니었다. 누군가는 "이 정도는 당연히 봐야지"라는 선을 말없이 긋고, 누군가는 "그건 도구한테 맡기고 넘기면 되지"라는 선을 말없이 긋는다. 두 개의 보이지 않는 선은 언젠가 반드시 부딪힌다. 말로 꺼내지 않은 기준은, 미뤄둔 갈등일 뿐이다.

그러니 경계를 어디에 둘지는 끝내 도구의 문제가 아니라 사람 사이의 문제다. 팀이 함께 합의해야 하고, 처음 같이 일하는 사이라면 서로의 기준부터 맞춰두어야 한다. 그 대화를 미루면, 매번 작은 코멘트 하나가 기준에 대한 큰 다툼으로 번진다.

그렇다면 그 합의는 코드가 올라온 뒤가 아니라 그 전에 이뤄지는 게 낫다. 무엇을 풀려 하고 왜 이렇게 접근하는지를 먼저 맞춰두면, 리뷰는 한 줄 한 줄을 심문하는 일에서 합의한 방향과 어긋난 곳을 찾는 일로 바뀐다. 그제야 리뷰는 코드 한 줄이 아니라 전체 변경의 흐름을 본다. 방향을 맞추지 않은 채 코드부터 내미는 것은, 요청만 던지고 알아서 해두라고 맡긴 AI에게 결과물을 받아 든 것과 그리 다르지 않다 — 사람이 쓴 코드라도 그렇다.

물론 반대 방향의 함정도 있다. '이건 이제 안 봐도 된다'는 합의는 늘 한쪽으로만 굴러가기 쉽다. 도구에 맡길 수 있는 영역은 분명 늘겠지만, 안 보기로 한 목록은 근거에 따라 다시 줄어들 수도 있어야 한다. 줄어들 줄 모르는 목록은 합의가 아니라 방심이다.

도구가 코드를 대신 써주는 일은, 사실 그렇게 두려운 변화가 아닐지도 모른다. 그것은 도리어 우리가 미뤄두었던 질문을 되묻게 한다. 코드를 짜는 행위 너머에 있는 의도, 맹목적인 속도보다 중요한 방향.

결국 도구의 시대에 우리가 다시 마주해야 하는 것은, 다름 아닌 '사람의 일'이 아닐까.