AI가 코드를 짜는 시대, 나는 리뷰를 못 따라가고 있었다

솔직히 말하면, 요즘 PR을 제때 리뷰하지 못하고 있습니다. 개발 속도는 빨라졌는데 리뷰 속도는 그대로입니다. 예전엔 하루 이틀이면 처리하던 게 이제는 며칠씩 밀립니다. 처음엔 제가 게을러진 탓인가 싶었습니다. 돌아보니 그게 아니었습니다.

AI 도구를 쓰면서 코드가 쏟아지는 속도가 달라졌습니다. 한 사람이 만들어내는 코드 양이 예전과 비교가 안 됩니다. PR 하나에 담긴 변경사항이 500줄, 1000줄을 넘기는 일이 잦아졌습니다. 그걸 제대로 읽으려면 코드 의도를 파악하고 놓친 케이스를 찾아야 합니다. 시간이 두 배로 듭니다. 그런데 PR은 세 배로 늘었습니다. 어디선가 반드시 구멍이 생길 수밖에 없는 구조입니다.

이런 고민을 하던 중에 "코드 리뷰를 없애는 방법"이라는 글을 읽었습니다. 제목만 보면 도발적인데, 핵심은 이겁니다. AI가 코드를 생성하는 시대에 인간이 코드 한 줄 한 줄을 검토하는 건 이미 구조적으로 한계에 왔으니, 리뷰의 무게중심을 코드 아래에서 코드 위로 옮겨야 한다는 것입니다. 즉, 코드 자체보다 코드가 만들어지기 전 단계, 스펙과 수용 기준을 검증하는 쪽으로 인간의 역할을 이동하자는 얘기입니다.

이 글을 읽고 제가 느낀 건 "맞다"가 아니라 "아, 이게 구조적인 문제였구나"였습니다. 리뷰가 힘들어진 게 제 문제가 아니라는 걸 확인한 셈입니다. 동시에 새로운 고민이 생겼습니다. 스펙을 리뷰하는 건 좋은데, 그게 실제로 가능한가요? 코드를 짜면서 비로소 발견되는 예외 상황이나 비즈니스 로직이 더 많은 게 현실입니다. 스펙이 완벽할 수 없다는 건 개발자라면 다 아실겁니다.

그러다 보니 결국 이런 생각까지 왔습니다. AI가 코드를 짜는 시대에 개발자가 해야 할 일은 코드를 검토하는 게 아니라, 코드가 가야 할 방향을 결정하는 것입니다. 스펙을 쓰는 것도 포함되지만 그보다 더 근본적인 얘기입니다. 시스템이 어떤 구조를 가져야 하는지, 어떤 제약이 중요한지, 어떤 의도로 설계됐는지를 명확하게 유지하는 것. AI는 주어진 맥락 안에서 코드를 잘 짭니다. 그 맥락을 잘 만드는 게 이제 개발자의 핵심 역할이 되고 있습니다.

그 맥락이 어떤 형태여야 하는지에 대해서는 아직 업계에 합의된 답이 없습니다. 하지만 제가 생각하는 방향은 하나입니다. 코드와 함께 존재하는 구조화된 메타데이터입니다. 단순한 주석이나 README가 아니라, API 설계, DB 스키마, 핵심 비즈니스 규칙, 모듈 간 의존 관계를 코드와 동기화된 형태로 명시적으로 관리하는 것입니다. 코드가 집이라면 메타데이터는 설계도입니다. 벽지 색깔보다 건물의 하중 구조가 중요하듯, 구현 디테일보다 시스템이 왜 이 모양인지를 데이터로 남기는 것입니다.

이게 갖춰지면 리뷰의 모양도 달라질 수 있습니다. 500줄의 코드를 처음부터 끝까지 읽는 대신, 메타데이터의 변경 diff를 먼저 봅니다. "할인 정책 예외 케이스 하나 추가됨"을 확인하고 그 의도가 타당한지 판단합니다. 코드 리뷰가 아니라 의도 리뷰에 가깝습니다. 특정 모듈이 바뀌었을 때 연쇄적으로 영향받는 곳도 그래프로 파악할 수 있다면, 리뷰어가 시스템 전체를 머릿속에 담고 있어야 하는 부담도 줄어듭니다. 물론 메타데이터를 코드만큼 성실하게 유지해야 한다는 전제가 있고, 그게 쉽지 않다는 것도 압니다. 그래도 방향으로서는 맞다고 생각합니다.

9년 동안 개발하면서 코드를 잘 짜는 게 실력이라고 생각했습니다. 지금도 그 생각이 완전히 바뀐 건 아닙니다. 하지만 AI가 코드를 대신 짜주는 세계에서 "잘 짜는 것"의 의미가 조금씩 달라지고 있다는 건 분명합니다. 코드보다 코드 앞에 오는 것, 의도와 구조와 판단을 잘 다루는 사람이 점점 더 중요해지는 것 같습니다.

쌓이는 PR을 억지로 다 읽으려 하는 건 해법이 아닙니다. 구조를 바꿔야 합니다. 코드를 더 열심히 검토하는 게 아니라, 코드를 둘러싼 정보의 밀도를 높이는 쪽으로. 아직 이걸 제대로 실천하고 있는 팀을 본 적은 없습니다. 저도 마찬가지입니다. 그래서 여전히 고민 중입니다.