AI가 쓴 코드, 누가 어떻게 믿나
참고한 자료
에이전트가 코드를 쓰면서 개발의 병목이 구현에서 검토로 옮겨갔다. 사람이 줄마다 보는 대신 AI가 실수하기 어려운 환경을 만들자는 의견과, 그래도 사람이 직접 봐야 할 곳이 있다는 사례가 함께 나온다.
구현은 AI가 하고, 병목은 검토로
한 개발자의 회고에 따르면 에이전트에게 작업을 맡긴 뒤 병합한 PR 기준 생산성이 약 3배가 됐다. 대신 새 병목은 생성된 코드의 검토였다. 업무의 중심도 아키텍처, 마이그레이션 계획, 핵심 로직으로 옮겨갔다.
Linus Torvalds도 Claude Code로 Linux 커널의 읽기 성능 병목을 고치고 있다.
- Claude Code: 코드, 테스트 프로그램, 검토 항목, 패치 소개문 초안
- Torvalds: 성능 측정
여러 스레드가 같은 파일을 읽을 때 생기는 참조 카운트 경합을 줄이는 패치로, 노트북 한 대에서 쟀을 때 스레드 8개의 초당 읽기가 약 1,000만 회에서 3,000만 회 이상으로 늘었다.
사람 대신 환경이 실수를 잡게
Threads에 소개된 개발자 lauren은 AI가 쓴 코드를 더 믿으려면 사람이 줄마다 검토하기보다 AI가 실수하기 어려운 개발 환경을 만들어야 한다고 주장한다.
- 코드 구조와 타입 검사를 강화하고, 테스트와 자동 검증으로 오류를 미리 잡는다.
AGENTS.md같은 지침은 자동화하기 어려운 판단에 쓴다.- 사람은 중요한 설계 검토에 집중한다.
함께 소개된 pstack은 이런 원칙을 에이전트 스킬로 묶었다(Cursor 플러그인이고 Claude Code에도 설치할 수 있다). 불가능한 상태는 타입으로 표현할 수 없게 하고, 고치기 전에 실패하는 테스트부터 쓰며, “컴파일된다” 같은 AI의 자체 보고 대신 실제 결과물을 확인한다. 토큰을 많이 쓴다는 반응도 있었다.
앞의 회고에서 쓴 방법도 같은 방향이다.
- 표준 라이브러리와 기존 패턴을 쓰게 해서 검토할 거리 자체를 줄였다.
- 계획 문서를 구현 순서 목록이 아니라 어떤 QA를 할지 정하는 출발점으로 바꿨다.
- 구현 방법 대신 제약 조건을 줬다. 이미지 처리 목표를 150ms로 쓰려다 15ms로 잘못 적었는데 모델이 해냈고, Electron 노트 앱을 iPhone으로 옮기는 탐색을 맡겼더니 몇 시간 만에 네이티브 Swift로 기본 기능이 돌아가는 앱이 나왔다.
그래도 사람이 봐야 하는 곳
환경을 갖춰도 사람의 검토가 사라지지는 않는다. 회고의 글쓴이는 되돌리기 어려운 부분(비즈니스 로직, 고객 데이터, DB 변경, 암호화)에 검토를 집중했다. Torvalds도 구현은 맡겼지만 성능은 직접 쟀다.
Torvalds 기사 댓글에서는 반응이 갈렸다. 엄격한 검토를 거치면 LLM 코드도 믿을 만하다는 쪽과, LLM 코드는 사람이 쓴 코드와 실수 양상이 달라서 검토가 오히려 더 어렵다는 쪽이다.
내 생각
“사람이 코드를 일일이 검토하기보다 AI가 실수하기 어려운 개발 환경을 만드는 게 중요하다”는 의견과, “회사에서는 내 이름으로 올라가는 코드가 어떤 문제를 일으킬지 모르고 책임도 나에게 있으니 사람의 리뷰가 필수다”라는 의견이 부딪히고 있다. “이 코드 뭐예요?“라는 질문에 “AI가 그렇게 하라던데요”라고 답할 수 있을까?