요즘 Claude와 Codex, 안티그래비티를 같이 쓰고 있습니다. 재밌는 건 서로의 작업물을 두고 PR에 리뷰를 작성하게 시켜본 거였는데요. 그걸 기반으로 피드백을 진행해보니 상당히 훌륭했습니다.

거의 대부분 제가 생각한 수준만큼 짚어냈고, 가끔은 제가 못 본 걸 한 차원 높게 잡아내기도 했습니다. “와 너무 좋다…” 싶었어요.

그러면서도 저는 에이전트의 작업물을 계속 직접 확인하고 있었습니다. 솔직히 살짝은 관성이었습니다. 그런데 그러면서도 제가 잡아내는 경우가 분명히 있었으니, 빼놓을 수 없는 과정이기도 했거든요.

애매했던 건 그 이유였습니다. AI 리뷰가 이렇게 잘 돌아가는데, 내가 보는 건 정확히 무엇을 위한 걸까. 그냥 못 미더워서 확인하는 건가…

이해가 병목이라는 이야기

그러다 이해가 새로운 병목이다라는 글을 읽었습니다.

요지는 이렇습니다. 에이전트가 코드를 쏟아내는 속도는 계속 빨라지는데 사람이 그걸 이해하는 속도는 같이 늘지 않습니다. 그래서 개발 속도를 제한하는 건 코드 생성 능력이 아니라 인간의 이해 속도라는 거고요.

여기서 제 애매함을 정리해준 대목이 나왔습니다. “사람이 코드를 이해해야 하는 이유가 무엇이냐”는 질문에 흔히 나오는 답이 “에이전트의 작업을 검증하기 위해서”인데, 글쓴이는 그게 아니라고 봅니다. 검증은 에이전트가 점점 더 잘하게 되니까요.

그럼 사람은 어디에 남느냐. 검증이 아니라 참여를 위해서라는 겁니다. 시스템을 이해하고 있어야 결과에 합격 도장을 찍는 데서 끝나지 않고, 다음에 무엇을 바꿀지 생각할 수 있다는 거고요.

두 리뷰의 목적이 갈라진다

이걸 읽고 제 상황을 다시 보니 목적이 분리되더라고요.

AI의 코드 리뷰는 어떻게 보면 슈퍼 정적인 리뷰입니다. 주어진 diff와 읽어올 수 있는 파일들 안에서, 사람보다 훨씬 넓고 빠르게 결함을 훑습니다. 로직 오류, 놓친 엣지 케이스, 타입 문제. 이 층위에서는 제가 이길 이유가 거의 없습니다.

제가 하는 리뷰는 정적으로 소스를 보더라도 살짝은 동적인 정적 리뷰였습니다. 코드를 눈으로 읽는 동안 머릿속에서 흐름이 지나가거든요. 관련된 기억이 지나가고, 코드에는 적혀 있지 않은 합의와 운영 지식이 지나갑니다. ‘이 필드는 새벽 배치가 덮어쓰는데’, ‘여기는 예전에 한 번 터진 곳인데’ 같은 것들이요.

이건 diff 안에 없는 정보입니다. 리포지토리를 전부 읽혀도 안 나오고요. 애초에 코드에 쓰여 있지 않으니까요.

그래서 이렇게 정리했습니다.

무엇을 보는가누가 유리한가
변경된 코드 자체의 결함AI (병렬로 더 넓게)
변경이 기존 시스템과 부딪히는 지점사람 (코드에 없는 맥락을 가짐)
배포 후 실제 사용자 행동에서 드러나는 문제지표와 사용자

첫 번째 칸은 AI에게 넘길수록 이득입니다. 세 번째 칸은 코드를 아무리 봐도 안 나오고, 빨리 배포해서 써보는 게 빠릅니다. 제가 매달려야 할 곳은 두 번째 칸이었어요.

그래서 저 과정은 참여였습니다

두 번째 칸에서 하는 일을 잘 보면 검증이 아닙니다. 합격이냐 불합격이냐를 판정하는 게 아니라, 이 변경이 제가 아는 시스템의 어디를 건드리는지 대조하는 일이거든요.

이 대조는 이해를 유지하고 있어야만 됩니다. 그리고 이해를 놓으면 이 능력도 같이 사라집니다. 글에서는 그렇게 이해를 미루며 쌓이는 걸 인지 부채라고 부르더라고요. 기술 부채가 나중의 변경 비용을 높이듯, 이해를 생략한 작업은 나중에 판단할 수 없는 상태를 남긴다는 이야기입니다.

아무도 이해하지 못하는 시스템이 어떤 상태인지는 운영을 하면서 봐왔습니다. 다만 그게 남이 남긴 레거시에서만 생기는 게 아니라 방금 내 손에서 생성된 코드에서도 생길 수 있다는 건, 이 글을 읽고 나서야 생각해본 부분이었습니다.

그러니까 관성이라고 생각했던 그 과정은 관성이 아니었습니다. 검증하려고 본 게 아니라 참여하려고 본 거였고, 목적을 몰랐을 뿐이었어요.

두 번째 칸을 줄이는 게 목적입니다

그런데 여기서 한 가지를 짚고 싶습니다. 두 번째 칸이 사람에게 남아 있는 이유는 인간이 본질적으로 우월해서가 아니거든요. 그 정보를 아직 코드나 문서로 꺼내놓지 않았기 때문입니다.

그러니까 제가 할 일은 이 칸을 지키는 게 아니라 줄이는 쪽이었습니다. 머릿속에만 있던 합의와 운영 지식을 문서로, 주석으로, 테스트로 꺼내놓는 거요. 그렇게 명시화된 만큼은 AI도 판단할 수 있게 되니까요.

바라는 건 결국 세 번째 칸만 남는 세상입니다. 코드 결함은 에이전트가 넓게 훑고, 기존 시스템과의 충돌도 명시된 제약을 보고 판단하고, 사람은 배포된 것을 실제로 써보면서 지표와 사용자 행동을 읽는 일에만 매달리는 그림이요.