짚을 것과 넘길 것

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

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

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

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

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

실제로 1억 5천만 줄의 코드를 분석한 한 조사는, AI 도구가 퍼진 뒤 작성된 지 2주도 안 돼 되돌려지거나 갈아엎어지는 코드의 비율이 뚜렷이 늘었다고 보고한다(GitClear, 2024–25). 빠르게 나온 코드가 늘 맞는 코드는 아니었던 셈이다. 다른 추정은 한발 더 나아간다. 이렇게 쌓인 부채에 따로 손대지 않으면, 5개월에서 19개월 사이에 팀의 속도가 도리어 뒤로 간다는 시뮬레이션도 있다(James Shore, 2026).

출처: James Shore, 「You Need AI That Reduces Your Maintenance Costs」 (2026)

그런데도 도구가 코드를 더 많이 쏟아내는 것을, 우리는 너무 쉽게 '생산성이 올랐다'고 말한다. 어떤 회사는 구성원별 토큰 사용량을 대시보드에 띄워 누가 1등인지 경쟁을 붙이고, 가장 적게 쓴 사람을 팀장이 따로 불러 면담한다고 한다. 많이 쓰는 것이 곧 잘하는 것이라는 듯이. 하지만 2주도 못 가 지워질 코드를 더 빨리, 더 많이 만든 것을 과연 생산성이라 부를 수 있을까. 그건 생산성이 아니라 그냥 양(量)이다. 측정하기 쉬운 숫자를, 정작 측정해야 할 가치로 착각한 것에 가깝다.

토큰을 얼마나 썼는지, 줄을 몇 줄 쳐냈는지는 실시간으로 눈에 보인다. 하지만 그 코드가 살아남았는지는 한참 뒤에야 드러난다. 그래서 매번 보기 쉬운 쪽이 이긴다. 쏟아낸 줄 수가 늘었다는 사실 자체는 아무것도 증명하지 않는다. 생산성은 코드의 양이 아니라, 그 코드가 무엇을 풀었고 얼마나 오래 살아남았는가로만 매겨진다.

빠른 양이 어디로 흘렀는지는 사고가 터지고 나서야 드러난다. 제대로 검토되지 않은 AI 코드가 프로덕션에서 장애를 내고, AI가 정리해 올린 보고서만 믿고 내린 결정이 뒤늦게 어긋난 것으로 드러난다. 그런 일이 몇 번 반복되면 회사는 놀라서 AI 사용을 통째로 되돌리기도 한다. 빨리 만든 값을, 그제야 한꺼번에 치르는 것이다.

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

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

값을 매기기 어려운 건 그다음이다. 가령 AI가 정리해 올린 지표가 "평소와 다를 게 없다"고 말한다고 하자. 숫자만 보면 틀린 말이 아니다. 하지만 그 바닥을 아는 사람에게는 평소의 몇 배에 달하는 움직임일 수 있다. AI가 학습한 세상의 평균에는 평범한 수치라도, 이 도메인의 기준에서는 결코 평범하지 않은 것이다. 동작하지 않는 코드도 아니고 틀린 보고서도 아니다. 다만 '여기'의 의미를 놓쳤을 뿐이다.

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

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

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

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

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

여기엔 흔한 반문이 따라붙는다. 그러면 사람이 더 꼼꼼히 보면 되지 않느냐는 것이다. 그런데 양이 어느 선을 넘으면, 더 열심히 보는 것만으로는 따라잡히지 않는다. 쏟아지는 결과물을 끝까지 눈으로 좇으려다 보면, 어느새 결론만 훑고 넘기게 되기 때문이다. 그러니 경계를 긋는다는 건 '덜 본다'는 뜻이 아니다. 어떤 것은 눈으로 한 번 보고 마는 대신, 언제든 다시 돌려볼 수 있는 형태로 옮겨 적어 둔다는 뜻이기도 하다. 그렇게 기계에 맡길 수 있는 것을 맡길수록, 끝내 사람만이 내릴 수 있는 판단에 더 오래 머물 수 있다.

일하는 시간의 무게중심도 그래서 옮겨간다. 도구가 없던 시절 하루가 만드는 데 여섯, 판단하는 데 둘이었다면, 이제는 만드는 일을 도구에 넘긴 만큼 그 비율이 뒤집힌다. 명령하는 데 둘, 판단하는 데 여섯. 그런데도 하루의 대부분을 여전히 직접 무언가를 찍어내는 데 쓰고 있다면, 도구를 손에 쥐고도 옛 방식으로 일하고 있는 것이다.

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

'안 본다'는 말에는 두 종류가 있다

요즘은 "코드 리뷰를 아직도 하느냐"는 말을 어렵지 않게 듣는다. 도구가 다 짜주는데 사람이 한 줄씩 들여다보는 건 한물갔다는 것이다. 그 말을 들을 때마다 나는 잠깐 멈추게 된다. 같은 말이라도 사뭇 다른 두 자리에서 나올 수 있기 때문이다. 정말 안 봐도 되는 자리에 이르러서 하는 말일 수도 있고, 무엇을 봐야 하는지 아직 마주해보지 못해서 하는 말일 수도 있다.

코드를 정말로 안 봐도 되는 사람은 있다. 자기 자산을 굴리는 트레이딩 시스템의 코드를 한 줄도 들여다보지 않는다는 사람의 이야기를 들은 적 있다. 대신 수백 개의 검증을 짜두었고, 그것을 통과하면 믿는다는 것이다. 그런데 이건 의도를 덜 본 것이 아니다. 외려 의도를 끝까지 본 결과다. '무엇이 맞는가'를 검증으로 옮겨 적으려면 그 분야를 손끝까지 이해하고 있어야 한다. 검증을 짜는 일 자체가 의도를 정의하는 일이기 때문이다. 그는 의도를 안 본 게 아니라, 의도만 남기고 나머지를 기계에 넘긴 것이다.

"요즘 누가 리뷰하냐"는 쪽의 '안 봄'은 정확히 그 반대편에 있다. 무엇이 맞는지 정의해본 적이 없으니 기계에 옮겨 적을 것도 없고, 그래서 그냥 안 본다. 받은 결과를 읽지도 않은 채 다음 사람에게 넘기고, 받은 사람은 그것을 다시 자기 도구에 밀어 넣어 돌려보낸다. 그렇게 아무도 끝까지 책임지지 않은 결과물이 조직 안을 떠돈다. 같은 '안 본다'라도 하나는 의도를 끝까지 봐서 얻은 자유고, 다른 하나는 의도를 본 적이 없어서 생긴 방치다. 겉모습만 같을 뿐, 정반대 자리에 있다.

여기서 자주 흐려지는 게 하나 있다. '리뷰는 이제 됐다'는 말은, 기계가 걸러낼 수 있는 것과 그래도 사람이 확인해야 하는 것을 가르는 일까지 함께 접어버리곤 한다. 하지만 그 구분이야말로 리뷰의 처음이자 거의 전부였다. 눈에 먼저 들어오는 건 대개 생산성의 외양이다. 빨라 보이고 줄 수가 늘었으니 됐다는 감각. 그 코드가 무엇을 풀었고 자리에 맞는지는 그다음 질문인데, 속도가 빠를수록 그 질문은 자꾸 뒤로 밀린다. 그렇게 구분하기를 멈춘 것을, 구분할 게 없어진 것으로 여기기 쉽다.

함정은 하나 더 있다. AI가 내놓은 결과가 그럴듯해 보이는 건, 보는 사람이 그 분야의 비전문가일 때가 많다. 신문에서 내가 잘 아는 분야 기사를 읽으면 오류가 훤히 보이는데, 모르는 분야 기사는 정확하려니 믿어버리는 그 망각(겔만 기억상실, Gell-Mann amnesia)과 다르지 않다. 매체가 신문에서 LLM으로 바뀌었을 뿐 편향은 그대로다. 앞서 본 그 지표처럼, 평균에 비춰 그럴듯한 답일수록 '여기'의 기준에서 어긋나 있기 쉽다.

"동작하니 됐다"는 판단이 가장 빨리 나오는 건, 무엇이 빠졌는지 알아채기 어려운 자리에서다. 없어야 할 것이 있는 건 누구나 본다. 있어야 할 것이 없는 건 아는 사람만 본다. 그리고 그걸 알아채는 자리는, 도구가 흔해질수록 오히려 더 비싸진다.

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

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

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

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

그렇다면 그 합의는 코드가 올라온 뒤가 아니라 그 전에 이뤄지는 게 낫다. 리뷰에서 정말 답이 막히는 질문은 대개 이런 것들이다. "이 타임아웃은 왜 5초죠, 10초로 늘려도 되나요?" "이 상품은 왜 올린 뒤 24시간을 유지해야 하죠?" 코드는 멀쩡히 돌아가는데, 왜 그렇게 만들었는지는 아무도 모른다. 답을 알던 사람은 이미 떠났고, 이유가 적혀 있던 메시지는 어디 있었는지 찾을 수 없다. 무엇을 풀려 하고 왜 이렇게 접근하는지를 먼저 맞춰두면, 리뷰는 한 줄 한 줄을 심문하는 일에서 합의한 방향과 어긋난 곳을 찾는 일로 바뀐다. 그제야 리뷰는 코드 한 줄이 아니라 전체 변경의 흐름을 본다. 방향을 맞추지 않은 채 코드부터 내미는 것은, 요청만 던지고 알아서 해두라고 맡긴 AI에게 결과물을 받아 든 것과 그리 다르지 않다 — 사람이 쓴 코드라도 그렇다.

물론 반대 방향의 함정도 있다. '이건 이제 안 봐도 된다'는 합의는 늘 한쪽으로만 굴러가기 쉽다. 도구에 맡길 수 있는 영역은 분명 늘겠지만, 안 보기로 한 목록은 근거에 따라 다시 줄어들 수도 있어야 한다. 줄어들 줄 모르는 목록은 합의가 아니라 방심이다. 그리고 무언가를 그 목록에 올리려면, 그것을 먼저 검증으로 옮겨 적어둘 수 있어야 한다. 옮겨놓지도 않고 그냥 빼버린 항목은, 합의된 게 아니라 그저 빠뜨린 것이다.

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

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