AI 코드 리뷰를 한동안 쓰다 보면 두 종류의 감상이 함께 생깁니다. “이걸 잡아 주네” 와 “이건 왜 못 보지” 입니다. 두 감상은 무작위가 아니라 꽤 뚜렷한 경계를 따라 갈립니다. 그 경계를 알면 리뷰를 어디에 배치할지가 정해지고, 기대와 실제가 어긋나서 생기는 실망도 없어집니다.
잘 잡는 것 — 코드만 읽어도 보이는 결함
AI 리뷰가 안정적으로 잡는 것은 변경된 코드 안에서 완결되는 결함입니다. 대표적으로 셋입니다.
첫째, 빠진 출력 이스케이프. 변수 하나가 echo 로 그대로 나가는 자리는 문맥이 없어도 보입니다. 사람은 코드 리뷰를 스무 번쯤 하면 이런 줄을 눈으로 훑고 지나치는데, AI 는 지치지 않습니다.
둘째, 빠진 권한 · nonce 확인. 저장 처리 함수인데 current_user_can() 이나 check_admin_referer() 가 없으면 지적합니다. 이것도 함수 하나만 읽고 판단할 수 있는 종류입니다.
셋째, 눈에 띄는 논리 실수. 조건이 뒤집혔거나, 반복문 밖에 있어야 할 초기화가 안에 있거나, 반환값을 쓰지 않고 버리는 자리 같은 것들입니다.
이 셋에는 공통점이 있습니다. 실행하지 않아도, 다른 파일을 열지 않아도 판정할 수 있다는 것입니다.
못 잡는 것 — 실행해야 아는 것
런타임 동작이 첫 번째 사각지대입니다. 어떤 값이 실제로 들어오는지, 그 값이 비어 있을 때가 있는지, 외부 API 가 무엇을 돌려주는지는 코드에 적혀 있지 않습니다. AI 는 “여기서 null 이 올 수 있습니다” 라고 가능성을 말할 수는 있지만, 실제로 오는지는 돌려 봐야 압니다.
훅 실행 순서는 워드프레스에서 특히 자주 무는 함정입니다. 같은 필터에 세 플러그인이 붙어 있고 우선순위가 서로 다를 때, 우리 콜백이 무엇을 받고 무엇을 넘기는지는 설치된 플러그인 조합이 정합니다. 변경된 파일만 보는 리뷰는 이 조합을 볼 수 없습니다.
의도와의 일치가 가장 근본적인 사각지대입니다. AI 는 “이 코드가 무엇을 하는가” 는 잘 설명하지만 “이것이 우리가 하려던 일인가” 는 답할 근거가 없습니다. 요구사항이 코드 밖에 있기 때문입니다. 완벽하게 짜인 코드가 엉뚱한 기능일 수 있고, 그 판정은 사람만 할 수 있습니다.
그래서 어디에 배치하는가
AI 리뷰를 사람보다 앞에 두는 것이 실용적입니다. 기계적으로 잡히는 결함이 먼저 걸러지면, 사람은 “여기 이스케이프 빠졌어요” 를 적는 데 주의를 쓰지 않고 의도와 설계에 집중할 수 있습니다. 리뷰의 병목은 언제나 사람의 주의력입니다.
그 다음 층은 실행입니다. 훅 순서와 런타임 값은 결국 돌려 봐야 하므로, 변경이 실제 환경과 가까운 곳에서 한 번 도는 단계를 둡니다. 자동 테스트가 있으면 가장 좋고, 없다면 스테이징에서 해당 경로를 손으로 밟는 것만으로도 위 사각지대의 대부분이 드러납니다.
마지막으로 리뷰 요청을 쓰는 법도 결과를 바꿉니다. “리뷰해 줘” 보다 “이 변경의 의도는 A 이고, B 를 깨뜨리지 않아야 한다. 그 관점에서 봐 줘” 가 훨씬 쓸모 있는 지적을 만듭니다. 의도를 코드 밖에서 알려 주면, 위에서 말한 사각지대 하나가 부분적으로 메워집니다.
리뷰 뒤에 이어지는 배포와 검증 절차는 로컬에서 프로덕션까지 연재에서 다루고, AI 를 개발 흐름에 붙이는 다른 이야기는 AI 활용 아카이브에 있습니다. 실제 사이트에서 이 절차가 어떻게 도는지는 작업 과정에 그대로 공개돼 있습니다.