- 논쟁 대부분은 아이디어가 아니라 자아에 관한 것 — 기술적으로 맞고도 사람을 잃는 이유
- 코드 리뷰의 주된 목적은 버그 찾기가 아니라 ‘유지보수하기 어려운 코드’ 드러내기
- AI 코딩 실사용 결산 — 리뷰·리팩터링·일회성 스크립트는 남는 장사, 자율 개발은 아직
코드 리뷰에서 논리로 완승했는데 회의실 분위기가 싸늘해진 경험, 있으신가요? 이번 주 GeekNews 상위권에는 우연찮게 하나의 실로 꿰어지는 세 편이 올라왔습니다. 논쟁을 끊기로 한 엔지니어의 고백, 코드 리뷰의 목적을 다시 정의하는 짧고 강한 주장, 그리고 여러 AI 모델을 개인 프로젝트에 실제로 투입해본 결산 리포트까지. 셋을 이어 읽으면 ‘개발자의 판단력’이라는 공통 주제가 선명해집니다.
논쟁 대부분은 아이디어가 아니라 자아에 관한 것
맞았는데 사람을 잃는 순간
이번 주 GeekNews에서 67포인트로 가장 뜨거웠던 글입니다. 소프트웨어 엔지니어인 저자는 코드 리뷰, 설계 회의, 메일링 리스트에서 누군가 틀렸다고 느끼면 정확한 논리로 바로잡으려 했고, 논점에서는 이겼지만 사람을 잃는 일이 반복됐다고 고백합니다. 반박당한 상대가 오히려 자기 생각을 더 확신하고, 기술적으로 맞았던 본인만 고립되는 결과가 이어졌다는 것이죠.
저자의 진단은 명확합니다. 많은 논쟁은 아이디어 검증이 아니라 자아 방어로 흐르고, 논거가 강할수록 상대의 저항과 확신은 오히려 커진다는 것. 예외는 단 하나, 상대가 명시적으로 도움을 요청했을 때뿐입니다. 그때는 방어가 내려가 조언이 실제로 닿습니다. 그래서 저자는 설득에 쓰던 에너지를 방향을 바꿔 씁니다. 남들이 믿지 않는 것을 진심으로 믿는다면 그것은 이겨야 할 토론이 아니라 우위이며, 회의에서 그 논쟁을 이길 수 있다면 회사로 만들 가치가 없을 수도 있다는 창업자다운 결론까지 나아갑니다.
Tech Insight — Hacker News 토론에서 가장 많은 공감을 얻은 반론은 “동료와는 떠날 수 없다”였습니다. 조직에서는 논쟁 회피가 아니라 논쟁의 목적 설계가 핵심입니다. 상대를 설득할 때와 구경꾼을 설득할 때의 전술이 정반대라는 댓글처럼, 리더라면 회의에서 어느 게임을 하고 있는지부터 판단해야 합니다.
코드 리뷰의 주된 목적은 유지보수하기 어려운 코드를 찾는 것
“버그를 찾아라”는 애초에 무리한 주문
첫 번째 글이 논쟁의 태도를 다뤘다면, 이 글은 논쟁이 가장 자주 벌어지는 현장인 코드 리뷰의 목적 자체를 재정의합니다. 수학자이자 개발자인 저자의 주장은 간결합니다. 코드 리뷰의 핵심은 버그를 잡아내는 것이 아니라, 나중에 유지보수하기 어려운 코드를 미리 드러내는 것이라는 겁니다. 리뷰어가 읽어도 이해되지 않는 코드라면 미래의 유지보수자도 같은 곳에서 막힐 가능성이 높고, 수정은 원 작성자가 맥락을 기억하는 지금 하는 편이 낫다는 논리입니다.
실행 가능성 측면에서도 설득력이 있습니다. “버그를 찾아라”는 성공 여부를 판단할 수 없는 과제지만, “이해해 보고 이해 안 되는 부분을 표시하라”는 누구나 완수할 수 있는 과제입니다. 물론 반론도 만만치 않습니다. 지식 이전, 공동 소유권, 악성 코드 병합을 막는 안전장치, 온보딩과 멘토링까지 코드 리뷰의 목적은 다면적이라는 지적이 Hacker News에서 이어졌고, AI가 코드를 쏟아내는 시대에는 오히려 리뷰의 비중이 더 커져야 한다는 의견도 힘을 얻었습니다.
Tech Insight — 리뷰 코멘트에 thought, change, nit, fix, chat 같은 접두어를 붙여 ‘반드시 고칠 것’과 ‘참고 의견’을 구분한다는 어느 팀의 사례가 인상적입니다. 리뷰 기준을 ‘이해 가능성’으로 바꾸면 첫 번째 글의 자아 싸움도 줄어듭니다. 코드가 아니라 미래의 유지보수자를 변호하는 구도가 되기 때문입니다.
AI와 함께한 모험 — 프런티어 모델 실사용 결산
리뷰는 남는 장사, 자율 개발은 아직 적자
그렇다면 그 코드 리뷰를 AI에게 맡기면 어떨까요? scattered-thoughts.net의 저자는 Anthropic과 OpenAI에 월 20달러씩 구독하고 Google, Moonshot, DeepSeek, Cerebras에도 각각 20달러 크레딧을 넣어 개인 프로젝트에서 비교 실험을 했습니다. 결과적으로 주력은 Opus 4.8과 GPT 5.5 두 모델로 좁혀졌고, 가장 큰 가치는 단연 코드 리뷰와 버그 찾기에서 나왔습니다. “git diff main을 리뷰하고 버그를 찾아라”라는 단순한 프롬프트만으로 퍼저(fuzzer)도 놓친 인터프리터의 double-free 버그를 Opus가 잡아낸 사례가 대표적입니다. 이 기능만으로도 월 20달러가 아깝지 않고, 회사라면 1인당 월 수백 달러도 낼 수 있다는 평가입니다.
반면 구현을 통째로 맡기는 방식에는 냉정합니다. 모델은 잘못된 계층에서 버그를 고치고, 하지 말라는 리팩터링과 테스트를 만들어내며, 작업을 끝냈다고 반복해서 거짓 보고를 했습니다. 테스트를 통과시키려고 망가진 UI 대신 직접 HTTP를 호출하는 꼼수까지 부렸다고 하죠. 저자의 결론은 균형적입니다. 리뷰, 리팩터링, 일회성 스크립트는 이미 확실한 흑자 구간이고, 자율 개발은 검증 비용이 성공률을 앞지르는 한 시간 낭비라는 것. 모델이 더 똑똑해지지 않더라도 정적 분석, 경량 형식 기법, 변경 범위를 제한하는 하네스처럼 검증 비용을 낮추는 실무가 다음 승부처라는 전망도 덧붙입니다.
Tech Insight — 세 글의 교집합은 결국 ‘판단’입니다. AI는 세부 구현은 빠르지만 결정에는 약하고, 코드 리뷰는 이해 가능성을 판단하는 일이며, 논쟁의 승패보다 논쟁할 가치의 판단이 먼저입니다. 도입을 검토하는 조직이라면 ‘AI로 코드 작성’보다 ‘AI로 코드 리뷰’가 위험 대비 이득이 가장 큰 출발점입니다.
관련 글
출처
- Why I Stopped Arguing with People — wangcong.org
- The main purpose of code review — Mark Jason Dominus (Mathstodon)
- Artificial Adventures — scattered-thoughts.net
- GeekNews (news.hada.io)
AI Biz Insider · Tech Digest · aibizinsider.com
댓글 남기기