AI 코드 생성 감독 전략 — 전량 읽기가 불가능한 시대의 현실적 타협점
생성 코드의 몇 %를 실제로 읽나요?
지난달, Claude Sonnet이 REST API 엔드포인트 12개를 1분 만에 작성했어요. 라우팅·검증·에러 핸들링까지 포함해 약 500줄이었죠. 저는 그걸 읽는 데 20분이 걸렸습니다. 그것도 집중해서요. 이 속도 차이를 처음 체감했을 때 든 생각은 "나는 AI가 쓴 코드의 몇 퍼센트나 읽고 있나?"였어요.
저는 전량 읽기가 불가능하다고 생각합니다. 리스크 기반 선별 감독이 현실적 타협점이에요. 왜냐면 AI 코드 생성 속도와 사람의 이해 속도 사이의 격차가 너무 크기 때문이죠.
제가 코드 감독 비율을 측정해본 3개월
6월에 진행한 대시보드 프로젝트에서 측정했어요. AI가 생성한 코드는 총 3,200줄, 제가 실제 읽은 건 650줄이었습니다. 비율로 따지면 20% 남짓이에요. 나머지 80%는 실행만 해봤죠.
읽은 650줄의 내역을 보니 패턴이 보이더라고요. 인증 로직 150줄, 권한 검사 80줄, DB 마이그레이션 120줄, 결제 연동 200줄, 나머지는 핵심 비즈니스 로직이었어요. 고위험 영역은 100% 읽었지만, 유틸 함수나 테스트 코드는 거의 안 읽었습니다.
r/ClaudeAI의 한 스레드에서 비슷한 고민을 하는 개발자들을 봤어요. 출처: Since you started working with AI, what percentage of your code do you estimate you've read? (r/ClaudeAI) 어떤 이는 자기 생성 코드의 절반도 채 안 읽는다고 털어놨고, 또 다른 개발자는 "이제 Claude가 뭘 하는지 보기 위해 도구를 만들었다"고 했죠. 출처: Made this to see what Claude was doing. Now I basically work from it (r/ClaudeAI) 생성 코드를 관찰하는 별도 도구를 만들 정도면, 이미 직접 읽기는 포기한 겁니다.
제가 해봤더니, 유틸 함수 200개를 다 읽는 것보다 인증 로직 50줄을 정밀 분석하는 게 버그를 더 많이 잡았어요. 감독의 핵심은 비율이 아니라 어디를 읽느냐였습니다.
AI 코드를 전량 읽어야 할까요?
"생성 코드를 안 읽으면 블랙박스 아닌가요?" 이 반론은 부분적으로 맞아요. 안 읽으면 당연히 모르죠. 하지만 제 경험상 고위험 영역만 100% 읽어도 리스크의 80%는 커버됩니다. 나머지 20%는 경계 테스트로 잡았어요.
"AI가 틀릴 수 있잖아요." 맞습니다. 그래서 전량 읽기보다 경계 테스트가 효율적이에요. 엣지 케이스 10개 입력해보면 AI가 놓친 버그가 드러나거든요. 제가 6월에 잡은 버그 12건 중 9건이 테스트에서 발견됐습니다.
"코드를 안 읽으면 실력이 안 늘어나는 거 아닌가요?" 이건 전제를 다시 봐야 해요. 읽는 비율보다 읽는 부분의 질이 중요합니다. AI가 생성한 인증 로직 150줄을 정밀 분석하면서 OAuth2 흐름을 이해한 게, 유틸 함수 500줄 훑어보는 것보다 학습 효과가 컸어요.
제가 쓰는 감독 전략 3가지
첫 번째는 리스크 기반 선별 리뷰예요. 인증·권한·결제·DB 스키마는 무조건 100% 읽습니다. 나머지는 실행 테스트로 대체하죠. 이 기준으로 감독 시간을 70% 줄였어요.
두 번째는 경계 테스트입니다. AI 코드에 빈 문자열, null, 음수, 길이 초과 입력을 넣어봐요. 엣지 케이스 10개만 돌려도 대부분의 실수가 드러납니다. 제가 잡은 버그 중 75%가 여기서 나왔어요.
세 번째는 관찰가능성 도구예요. 로그와 디버거로 런타임 행동을 보는 겁니다. 코드 500줄 읽는 대신 실행 로그 50줄을 보면 뭐가 잘못됐는지 바로 보이거든요. 제가 쓰는 건 콘솔 로그와 브라우저 디버거뿐이에요. 복잡한 도구 필요 없습니다.
결론 — 감독의 기준은 신뢰가 아니라 검증 가능성입니다
AI 코드 감독의 본질은 신뢰에서 검증으로 전환하는 겁니다. 전량 읽기는 신뢰를 쌓는 방식이지만, 속도가 안 맞아요. 검증은 테스트와 관찰로 결과를 확인하는 거예요. 제가 6월에 감독 비율 20%로도 버그 12건을 잡은 건, 읽는 대신 검증했기 때문입니다.
자신의 감독 비율을 한 번 측정해보세요. 한 달간 AI가 쓴 코드와 실제 읽은 코드를 세어보면, 현실이 보입니다. 제 경우엔 그 수치가 20%였고, 그게 오히려 효율적이었어요.
당신은 AI 코드의 몇 %를 읽습니까? 그 비율이 낮다고 해서 잘못된 건 아닙니다. 중요한 건 어디를 읽느냐니까요.
자주 묻는 질문
Q. 고위험 영역은 어떻게 판단하나요?
A. 3가지 기준으로 봅니다. 첫째, 외부에 노출되는가(API·인증·권한). 둘째, 데이터를 변경하는가(DB·결제·파일). 셋째, 복구 비용이 높은가(마이그레이션·암호화·외부 API 연동). 이 중 하나라도 해당하면 100% 읽어요.
Q. 경계 테스트는 구체적으로 어떻게 하나요?
A. 6가지 입력을 기본으로 넣어봅니다. 빈 문자열, null, 음수, 최댓값 초과, 특수문자(SQL 인젝션 패턴), 동시 요청이에요. 제가 6월에 이 조합으로 잡은 버그가 9건입니다. 각 입력마다 에러 처리와 응답을 확인하세요.
Q. 감독 비율 20%는 어떻게 계산했나요?
A. 커밋 diff를 기준으로 측정했어요. AI가 생성한 줄 수(git diff --stat 합계)를 분모로, 제가 실제 읽은 줄 수(에디터에서 스크롤하며 이해한 부분)를 분자로 나눴습니다. 한 달치 커밋 30개를 집계하니 3,200줄 중 650줄이었어요.
Q. vibe coding이 뭔가요?
A. AI가 생성한 코드를 전혀 읽지 않고 실행 결과만 보고 받아들이는 방식입니다. 프로토타입이나 실험 단계엔 유용하지만, 프로덕션에선 위험해요. 최소한 고위험 영역은 읽어야 합니다.