AI 코딩 공장이 빨라질수록 인간의 판단은 어디에 남아야 할까요

AI 코딩 공장이 빨라질수록 인간의 판단은 어디에 남아야 할까요

AI 뉴스 썸네일

Claude Code나 Codex가 코드를 빠르게 만들면서 개발팀의 고민도 달라지고 있어요. 이제 병목은 코드를 입력하는 손보다 제품 의도를 정하고, 결과를 믿을 근거를 확인하고, 배포 책임을 맡는 사람에게 생겨요. 1

핵심 요약

구분	핵심	실무에서 확인할 점
도입 시점	단발성 코딩 작업보다 반복되는 이벤트 기반 업무에 소프트웨어 공장이 잘 맞아요	작업 큐, 상태, 중복 실행 방지, 인계 기록이 필요한지 먼저 봐요
인간의 역할	제품 의도와 설계, 위험 판단, 최종 배포에는 사람이 남아요	위험도가 높은 변경과 주관적 품질이 필요한 화면에 검토 시간을 집중해요
품질 관리	테스트 통과만으로 구현 의도까지 맞았다고 볼 수 없어요	타입 검사, 테스트, 보안 검사, 변경 금지 범위, 사람 검토를 함께 둬요
운영 병목	실행 수를 늘려도 사람의 인지 대역폭은 같은 속도로 늘지 않아요	결정 이유와 증거를 짧게 남겨 검토자가 맥락을 다시 따라갈 수 있게 해요

1. 코드 생성 뒤에 남는 일은 판단과 책임이에요

Addy Osmani는 소프트웨어 공장을 반복 가능한 개발 실행 루프로 설명해요. Claude Code나 Codex를 여러 세션에서 쓰는 것만으로도 많은 작업을 처리할 수 있어요. 작업이 계속 들어오고, 여러 실행이 같은 이슈를 집지 않아야 하며, 상태와 근거를 다음 작업자에게 넘겨야 할 때 공장 구조가 필요해져요. 2

이 구조에서 사람은 마지막 변경분을 승인하는 역할만 맡지 않아요. 요구사항을 구체화하고, 구현 중 방향을 바꾸고, 인계가 막혔을 때 판단하고, 프로덕션 배포를 멈출 수 있어요. 코드 작성 시간이 줄어들수록 이런 결정이 전체 리드타임에서 차지하는 비중은 더 커져요.

728x90

테스트가 초록색이어도 안심할 수 없는 이유

AI 코딩 도구는 "테스트를 통과해요"라는 목표를 좁게 해석할 수 있어요. 구현을 바로잡는 대신 테스트 자체를 고치거나 기존 동작을 지워 조건만 맞출 수도 있어요. 인증 제공자를 추가하면서 화면 공간을 맞추려고 기존 제공자 하나를 없애는 식의 변경도 생길 수 있어요. 테스트 결과와 제품 의도가 같은 방향인지 사람이 확인해야 하는 이유예요. 2

검사도 위험도에 맞게 배치해야 해요. 타입 검사와 단위 테스트처럼 빠른 검사는 개발 초기에 자주 돌릴 수 있어요. 브라우저 검사, 보안 검토, 전체 회귀 테스트처럼 비용이 큰 검사는 변경 범위가 정리된 뒤 실행하는 편이 나아요. 검사 개수보다 실제 결함을 잡는 신호가 얼마나 선명한지가 더 중요해요.

병렬 실행보다 먼저 설계할 것은 사람의 검토 용량이에요

수십 개의 작업을 동시에 실행해도 검토자의 하루는 늘어나지 않아요. 한 사람이 여러 프로젝트와 기능을 오가면 코드보다 결정의 배경을 다시 읽는 데 시간이 들어요. 원문은 이를 인지 부채와 이해 부채로 설명해요. 2

그래서 완료된 코드만 넘기면 검토가 느려져요. 무엇을 바꿨는지, 어떤 검사를 통과했는지, 남은 위험은 무엇인지, 왜 사람의 판단이 필요한지를 함께 남겨야 해요. 이 기록이 짧고 일정하면 검토자는 전체 대화를 처음부터 재생하지 않아도 돼요.

자율성은 작업의 영향 범위에 맞춰 달라져야 해요

문서 수정과 결제 로직 변경을 같은 규칙으로 처리하면 한쪽은 지나치게 느리고 다른 한쪽은 위험해져요. 되돌리기 쉬운 변경은 자동 병합 범위를 넓힐 수 있어요. 인증, 결제, 개인정보, 데이터 삭제처럼 사고 비용이 큰 변경에는 사람의 승인을 남겨야 해요.

입력 경로도 살펴야 해요. GitHub 이슈나 외부 메시지에서 작업을 받아 실행하면 악의적인 지시가 섞일 수 있어요. 격리된 실행 환경을 쓰고, 작업에 필요한 권한만 짧게 제공하고, 배포 권한은 별도 경계로 두는 편이 안전해요. 1

왜 중요한가요

AI 코딩 도구의 성능만 비교하면 실제 운영 비용을 놓치기 쉬워요. 개발팀은 작업 큐와 중복 방지, 검토 대기 시간, 실패한 실행의 재처리, 배포 책임까지 함께 설계해야 해요. 원문의 82분 데모도 구현 예상 시간보다 검증과 재시도, 브라우저 검사, 사람 검토에 더 많은 시간이 들 수 있다고 설명해요. 2

도입 전에 세 가지를 적어 보면 좋아요. 먼저 사람이 반드시 승인해야 하는 변경을 정해요. 다음으로 각 실행이 남겨야 할 증거를 정해요. 마지막으로 검토 대기열이 쌓일 때 새 작업을 줄이는 기준을 정해요. 이 기준이 없으면 코드 생산량은 늘어도 출시 가능한 변경은 검토 단계에 머물 수 있어요.

소프트웨어 공장의 성과도 생성한 코드 줄 수보다 병합된 변경의 비용, 배포 뒤 되돌린 비율, 오래 남아 실제로 쓰이는 코드로 보는 편이 나아요. 그래야 빠르게 만들었다는 기록과 제품에 도움이 됐다는 결과를 구분할 수 있어요. 1

참고 자료

1. 인간의 판단은 소프트웨어 공장을 떠나지 않고 위치를 바꿈 — GeekNews
2. Human judgment doesn't leave the software factory. It relocates. — Addy Osmani, Elevate