"테스트 통과했는데 왜 리젝하세요?"
AI한테 코드를 짜달라고 하면 요즘은 정말 잘 나와요. 돌려보면 동작도 잘하고요. 그런데 한 개발자가 "나는 AI가 짠 코드가 잘 작동해도 반려한다"고 이야기해서 공감이 많이 모였어요. 처음 들으면 "동작하면 된 거 아니야?" 싶은데, 읽어보면 이게 단순한 고집이 아니라 코드 품질에 대한 꽤 근본적인 질문을 던지고 있거든요.
핵심 주장은 이거예요. "작동한다(it works)"와 "좋은 코드다(it's good)"는 완전히 다른 기준이라는 거죠. 우리가 코드를 짜는 진짜 목적은 '지금 한 번 돌리는 것'이 아니라 '앞으로 몇 년간 사람이 읽고 고치고 확장하는 것'이잖아요. 그 관점에서 보면 AI 코드는 동작이라는 첫 관문은 쉽게 통과하지만, 그 너머의 기준에서 자주 걸린다는 거예요.
동작하는 코드를 왜 반려하는가
글쓴이가 드는 이유들을 풀어볼게요. 첫째, 이해되지 않는 코드는 부채다. AI가 어디선가 가져온 듯한 영리한 한 줄짜리 해법을 던져주는데, 정작 "왜 이렇게 동작하는지"를 팀원이 아무도 설명 못 하면, 나중에 버그가 나도 손을 못 대요. 코드를 머지하는 순간 그건 'AI 코드'가 아니라 '우리 팀이 책임지는 코드'가 되거든요. 책임질 수 없는 걸 들이는 셈이죠.
둘째, 맥락(context)을 모른다. 우리 프로젝트엔 우리만의 컨벤션, 기존 유틸 함수, 도메인 규칙이 있어요. AI는 그걸 모르고 비슷한 기능을 또 만들거나, 우리 패턴과 어긋나는 스타일로 짜놓는 경우가 많아요. 동작은 하는데 코드베이스의 결을 거스르는 거죠. 이런 게 쌓이면 일관성이 무너지고, 일관성이 무너지면 읽는 비용이 폭증해요.
셋째, 엣지 케이스를 슬쩍 비껴간다. AI는 '가장 그럴듯한 정답'을 만들어내는 데 최적화돼 있어서, 눈에 띄는 해피 패스(정상 흐름)는 잘 처리하지만, 빈 입력·동시성·실패 복구 같은 구석진 경우를 조용히 빠뜨리기 쉬워요. 테스트가 통과한다는 건 '내가 짠 테스트 범위 안에서' 통과한다는 뜻일 뿐이고요.
그럼 AI를 쓰지 말라는 걸까
그건 아니에요. 여기서 균형을 잡는 게 중요해요. 이 글의 메시지는 "AI를 거부하라"가 아니라 "AI 코드도 사람이 짠 코드와 똑같은 리뷰 기준을 통과해야 한다"는 거예요. 오히려 더 엄격해야 할 수도 있어요. 사람이 짠 코드는 적어도 그 사람이 '왜 이렇게 했는지' 설명할 수 있지만, AI 코드는 그 의도가 비어 있는 경우가 많으니까요.
실무에서 이걸 적용하는 방법은 단순해요. AI가 준 코드를 그대로 붙여넣지 말고, "내가 이걸 처음부터 설명할 수 있나?"를 스스로 물어보는 거예요. 설명이 안 되면 이해될 때까지 다시 쓰거나, 더 단순한 형태로 풀어내는 거죠. 똑똑한 한 줄보다, 팀 전체가 6개월 뒤에도 읽을 수 있는 다섯 줄이 더 좋은 코드인 경우가 많아요.
업계 맥락에서 보면
이건 새로운 논쟁의 연장선이에요. 예전부터 '복사-붙여넣기 프로그래밍'이나 '스택오버플로우 코드를 이해 없이 가져오기'의 위험은 늘 지적돼왔거든요. AI는 그 행위의 속도와 양을 폭발적으로 키운 거예요. 그래서 GitHub Copilot 같은 도구가 보편화될수록, 역설적으로 코드 리뷰의 가치와 '읽기 좋은 코드'의 중요성이 더 커지고 있어요. 생산 속도는 AI가 올려주지만, 그 코드를 신뢰할 수 있게 만드는 건 여전히 사람의 판단이라는 거죠.
한국 개발자에게 주는 시사점
주니어일수록 이 부분을 의식적으로 연습했으면 해요. AI가 짜준 코드로 기능을 빠르게 완성하는 건 좋은데, 거기서 멈추면 실력이 안 늘거든요. 받은 코드를 한 줄씩 "이건 왜 필요하지?" 하고 뜯어보는 습관이, 장기적으로는 가장 큰 차이를 만들어요. 팀 차원에서도 PR 템플릿에 "AI 도움을 받았다면, 작성자가 모든 라인을 설명할 수 있어야 한다" 같은 원칙을 넣어두면 좋고요.
한줄 정리: '작동하는 코드'는 출발선이지 결승선이 아니에요. 동작 여부가 아니라 '6개월 뒤에도 우리 팀이 이해하고 고칠 수 있는가'가 진짜 합격 기준이죠. 여러분은 AI가 준 코드를, 머지 버튼을 누르기 전에 한 줄씩 설명할 수 있나요?
🔗 출처: Hacker News