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

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

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

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

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

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

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

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

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

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