PR에 코멘트를 달았다.
options변수 재할당되는 곳이 없는 거 같은데,let으로 둬도 될 것 같아요.
답이 왔다.
해당 메서드가
mutating으로 선언돼서var가 필요합니다.let으로 바꾸면 빌드가 실패합니다.
이 회신, 형식적으로는 맞다. 컴파일러가 진짜 그렇게 시키니까. 근데 본질을 빗나갔다. 한 번 정리해 둘 만한 일이라 적는다. (실제 코드 시그니처 문제는 별도 글에 따로 적음.)
무엇이 빗나갔는가
내가 짚은 건 var/let의 표면적 선택이 아니라 함수 의도랑 시그니처의 정합성이었다. self를 안 바꾸는 함수에 mutating이 붙어서 호출부의 var가 “강제된” 상태였고, 그 비정상이 var/let 표면으로 드러난 것뿐.
답변자는 그 본질을 안 보고 컴파일러 출력만으로 회신함. 코드 누가 짰는지는 모르지만 — 답변자가 그 코드를 진짜로 읽었으면 “mutating인데 self를 안 바꾸네"가 먼저 눈에 들어왔을 거다. 안 들어왔다는 건 코드 정합성을 보지 않고 **“컴파일러가 시키는 대로 응대했다”**는 신호.
AI가 만든 코드 + AI가 회신한 PR
오해 없이 말하면, 코드를 AI가 만들든 사람이 만들든 결과물이 좋으면 상관 없다. 문제는 리뷰 응대까지 AI한테 맡길 때.
리뷰는 코드 자체보다 코드의 의도에 대한 대화다. 리뷰어가 의도를 짚으면 작성자는 그 의도를 같이 고민해야 함. 작성자가 그 코드 짜놓고 의도를 모르면 이미 위험 신호. 거기에 “컴파일이 통과하니 맞아요” 같은 표면적 답을 AI한테 받아서 그대로 붙이면, 리뷰는 사람-AI 대화가 되어버림. 리뷰어 입장에선 응대 못 받은 거다.
이게 작은 PR 한 건의 문제로 안 끝난다. 그런 회신을 반복해서 받으면 리뷰어는 다음부터 같은 작성자 PR에 의견 길게 안 쓰게 됨. “어차피 본질에 닿는 응대가 안 올 텐데” 하는 학습이 누적되면 팀의 리뷰 깊이가 점점 얕아짐.
AI를 어떻게 쓰는 게 옳은가
PR 리뷰에서 AI 쓸 거면 답변 자동화 도구가 아니라 본인 의견 형성 도구로 써야 한다.
- “리뷰어가 이렇게 짚었는데 왜 그렇게 보일까?” → AI에게 분석 요청
- “내가 짠 코드 의도가 무엇이었더라?” → AI에게 시그니처 해석 요청
- “더 나은 패턴은 무엇일까?” → AI에게 대안 제시 요청
- “내 회신이 리뷰어가 짚은 본질에 닿나?” → AI에게 1차 점검 요청
이렇게 받은 자료를 본인이 한 번 더 읽고, 본인 언어로 회신해야 한다. 그래야 리뷰가 사람-사람 대화로 유지됨.
작성자 입장에서 만든 체크리스트
회신을 작성하기 전에 한 번 더 묻는 자기 체크리스트.
- 리뷰어가 지적한 본질이 무엇인가? — 표면 vs 의도
- 내 답변이 그 본질에 닿는가? — 같은 층위에서 응대하고 있는가
- AI에게 받은 답을 그대로 붙이고 있는가? — 본인이 진짜로 그렇게 생각하는가
- 내가 이 코드를 다시 짠다면 동일하게 짤 것인가? — 의도가 한 번 더 검증되는가
- 리뷰어가 다시 답할 여지를 남겼는가? — 닫는 응대 vs 여는 응대
체크리스트라고 했지만 실은 짧은 자가 점검에 가깝다. 처음 몇 번만 의식적으로 하면 그 다음부턴 자동으로 걸러짐.
리뷰어 입장에서 할 수 있는 것
반대편에서도 할 수 있는 게 있다. 응대가 표면적이라고 느껴지면 한 번 더 같은 본질을 다른 표현으로 짚어주는 것. “var/let 표면 말고 mutating이 진짜 필요한지에 대한 의견을 듣고 싶었어요” 정도면 충분함. 본질을 명시적으로 끌어내는 것도 리뷰의 일부.
다만 이걸 반복하는 비용은 리뷰어가 진다. 그래서 작성자 쪽 자가 점검이 먼저고, 리뷰어의 본질 강조는 안전망 정도로 두는 게 균형 같음.
교훈
AI 시대에 사람의 일은 코드를 짜는 일에서 코드의 의도를 책임지는 일로 옮겨가고 있다. 그 책임을 다시 AI한테 떠넘기는 순간 PR 리뷰는 무의미한 핑퐁이 됨.
리뷰는 작성자랑 리뷰어 사이의 대화고, 그 대화는 사람의 의도가 살아 있을 때만 의미가 있음. 코드는 AI가 짤 수 있지만, 그 코드를 왜 그렇게 짰는지에 대한 책임까지 AI가 대신 질 수는 없다.