작년부터 팀은 AI 프로그래밍 도구를 사용하기 시작했고, 모두 코드 작성이 빨라졌다고 느꼈지만, 한 해가 지나니 이상한 현상을 발견했습니다: 코드 작성 시간은 줄었지만, Code Review 시간은 점점 길어졌습니다. 이전에는 한 개의 PR을 검토할 때 논리를 살짝 훑고 두 가지 질문을 하면 끝났지만, 지금은 각 변경 사항을 반복해서 확인해야 합니다: 이 부분이 AI가 작성한 것인지 사람이 작성한 것인지? 경계 조건을 처리했는지? 숨겨진 성능 문제가 있는지? 마지막까지 검토하면, 내가 다시 작성하는 것보다 더 피곤합니다.
AI가 코드를 빨리 작성하지만, 검토는 느림
올해 초, 저는 팀의 핵심 프로젝트를 담당하게 되었습니다. 팀의 몇몇 동료들은 Cursor와 Copilot을 사용했고, 생산성이 정말 높았습니다. 하지만 저가 검토할 때마다 이상한 점을 느꼈습니다.
예를 들어, 동료가 기능 모듈을 제출했는데, 코드가 실행되는 것은 문제가 없었지만, 줄별로 살펴보니 한 컴포넌트에 세 개의useEffect가 연결되어 있었고, 그 중 두 개는 기능이 겹쳐 있었습니다. 작성자는 주의하지 못했다고 하며, AI가 자동으로 완성한 것이라고 했습니다. 이런 문제는 보통의 일상이 되었습니다: AI가 생성한 코드는 실행될 수 있지만, 구조가 혼란스럽고 논리가 중복되며 경계 조건을 누락했습니다.
과거 사람이 작성한 코드는 작성자의 사고 과정을 느낄 수 있습니다. AI가 작성한 코드는 마치 대합실처럼 보이는데, 뭐가 다 있지만 불편합니다. 리뷰할 때는 논리가 맞는지만 보지 말아야 하고, 작성자에게 중복을 삭제하고 누락된 부분을 보충하고 구조를 정리해야 합니다. 이 과정을 거치면 시간이 자연스럽게 두 배로 늘어납니다.
이, 몇 가지 AI 코드의 "일반적인 문제점"
리뷰할 때 자주 마주치는 AI의 흔적을 몇 가지 요약했습니다.
1. 논리는 맞지만 경계가 없습니다.
AI는 주요 프로세스를 원활하게 만드는 데 능숙하지만, 널리 지정자, 타임아웃, 동시성과 같은 문제를 스스로 처리하지 못합니다. 예를 들어, 쿼리 인터페이스를 작성할 때 AI는data.list.map(...)를 작성하지만,data이 비어 있는지 판단하지 않습니다. 리뷰할 때 이를 보충해야 합니다.data?.list?.map또는if (!data) return null를 추가해야 합니다.
2. 과도한 설계, 간단한 문제를 복잡하게 만듭니다.
는 때때로 AI가 간단한 일을 특별히 "고급스럽게" 만듭니다. 예를 들어 레이블링을 추가하면, AI는 완전한 커스텀 Hook을 작성해주고 그 안에 useRef、useCallback、useEffect를 사용하며, 40~50줄에 걸쳐 길게 작성합니다. 하지만 실제로는 debounce 함수 하나만 필요합니다. 이런 코드를 리뷰할 때는 먼저 그 구현을 이해한 후에, 과도한지 여부를 판단해야 합니다.
3. 주석과 이름은 "컴퓨터 번역"처럼 보입니다
AI가 생성한 변수 이름은 data、items、config처럼 구체적인 의미를 알 수 없습니다. 함수 주석은 없거나 "데이터를 가져옵니다" 같은 헛소리일 수 있습니다. 리뷰할 때 의미 있는 이름으로 변경하거나 필요한 주석을 추가해주어야 하며, 그렇지 않으면 다음 사람이 이해하지 못합니다.
세부, 제 개인적인 전략: 리뷰를 덜 힘들게 하려면 어떻게 해야 할까요
오랜 시간이 지난 후, 제가 몸소 몇 가지 괜찮은 방법을 찾아냈습니다
- AI가 먼저 검토하도록 AI: PR을 제출하기 전에 작성자가 코드를 다른 AI(다른 모델)에 다시 검토하도록 요청하고, 제안에 따라 한 번 수정합니다
- 차별적으로 대우: 도구 클래스, 단위 테스트, 문서 주석은 AI에게 자유롭게 작성시킬 수 있습니다; 핵심 비즈니스 로직은 수작업으로 작성하거나 심도 있게 수정하는 것이 좋습니다
- 작은 규칙을 만들어라: 예를 들어 "useEffect는 정리 함수가 있어야 합니다", "API 호출에는 로딩과 오류 상태가 있어야 합니다". AI는 반드시 따를 수 없지만, 리뷰할 때 빠르게 비교할 수 있습니다
이러한 방법은 문제를 완전히 해결하지 못하지만, 적어도 리뷰 시간을 수용 가능한 범위로 끌어올 수 있습니다
네, 성찰
저는 지금 AI 프로그래밍에 대한 태도가 모순적입니다. 한쪽으로는 이것이 제가 많은 반복적인 노동을 절약해주고 있지만, 다른 한쪽으로는 부담을 리뷰 단계로 옮겨버렸습니다. 과거에는 한 사람이 코드를 작성하고 모두가 검토했지만, 지금은 한 사람이 AI 코드를 작성하고 다른 한 사람이 그의 취약점을 검토합니다.
이것은 AI의 잘못이 아니며도 도구의 잘못이 아니라, 우리가 아직 AI와 협력하는 방법을 배우지 못했기 때문입니다. 앞으로 더 나은 리뷰 프로세스가 생길 수도 있거나 AI가 스스로 자신을 검토할 수도 있겠지만, 현재로서는AI가 제를 덜 야근하게 만들지는 않았지만, 야근 내용이 '작성'에서 '검토'로 바뀌었습니다.
5. 마지막으로
만약 당신도 비슷한 감정을 경험하고 있다면좋아요를 눌러 알려주세요 이것이 혼자가 아님을. 댓글에서 이야기해보세요: 당신의 팀은 AI 코드로 인해 리뷰가 느려졌습니까?