AI가 코드를 만드는 시대, 병목은 검증으로 옮겨갔어요

AI가 코드를 만드는 시대, 병목은 검증으로 옮겨갔어요

AI 뉴스 썸네일

AI 코딩 도구가 만드는 코드의 양은 빠르게 늘고 있어요. 하지만 개발팀이 그 결과를 이해하고 안전하게 승인하는 속도는 같은 비율로 늘지 않아요.

728x90

Addy Osmani는 이런 생산 체계를 밝은 소프트웨어 팩토리와 다크 소프트웨어 팩토리로 나눠 설명했어요. 둘의 차이는 자동화 수준보다 사람이 어느 결정에 참여하고 무엇을 직접 확인하느냐에 있어요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
생산성	코드 생성과 자동 검사는 저렴하게 늘릴 수 있어요	검토와 판단이 새로운 병목이 돼요
품질	사람이 읽지 않은 코드가 계속 쌓일 수 있어요	테스트가 통과해도 장기 유지보수 문제는 남아요
운영	위험이 낮고 판정 기준이 분명한 작업부터 자동화해요	인증·결제·공개 API에는 사람의 판단이 필요해요
조직	개발자는 코드 작성뿐 아니라 작업 경로와 승인 기준도 설계해요	처리량보다 검증할 수 있는 범위를 먼저 정할 수 있어요

1. 코드 생성보다 검증 능력이 더 중요해졌어요

소프트웨어 팩토리는 여러 AI 코딩 작업을 동시에 실행하고, 테스트와 정적 분석을 거쳐 변경 사항을 제품에 반영하는 운영 방식이에요. 한 개의 거대한 AI가 모든 일을 맡는 구조와는 달라요. 작은 작업을 나누고 각 작업의 실행 범위와 종료 조건을 정하는 쪽에 가까워요. 1

코드 작성, 테스트 실행, 보안 스캔은 컴퓨팅 자원을 더 투입해 비교적 쉽게 늘릴 수 있어요. 반면 설계가 제품 요구와 맞는지, 변경 범위가 적절한지, 장기 운영에 무리가 없는지를 판단하는 일은 숙련된 개발자의 시간이 필요해요. 생성 속도를 높일수록 검토 대기열이 길어지는 이유예요.

사람이 읽지 않은 코드에는 이해 부채가 쌓여요

원문은 코드 규모와 사람이 실제로 이해하는 범위의 차이를 ‘이해 부채’라고 불러요. 자동 테스트가 계속 통과해도 이 차이는 벌어질 수 있어요. 몇 달 뒤 장애가 생기거나 요구 사항이 바뀌면, 팀은 익숙하지 않은 코드를 다시 읽고 설계 의도부터 복원해야 해요. 2

이 문제는 오랫동안 운영한 복잡한 시스템에서 더 커져요. 짧은 실험이나 작은 도구는 문제가 생겨도 전체 구조를 다시 파악하기 쉬워요. 인증, 결제, 권한, 외부 API가 얽힌 서비스는 한 번의 잘못된 변경이 여러 기능과 고객에게 번질 수 있어요. 테스트 성공만으로 안전을 증명하기 어려운 영역이에요.

자동화 범위는 검증 비용에 맞춰야 해요

모든 작업에 같은 자율성을 줄 필요는 없어요. 린트 위반 한 건 수정, 사용하지 않는 코드 제거, 정해진 규칙에 따른 작은 리팩터링처럼 결과를 빠르게 판정할 수 있는 작업은 자동화하기 좋아요. 실패 범위가 작고 되돌리기도 쉬워요.

인증 체계 변경, 결제 계산, 공개 API 계약, 데이터 이전처럼 잘못됐을 때 비용이 큰 작업은 다르게 다뤄야 해요. 구현 전에 제품 요구와 설계를 검토하고, 변경된 코드와 테스트 근거도 사람이 확인하는 편이 안전해요. 자동화 여부를 작업 이름이 아니라 오판 비용과 영향 범위로 나누는 방식이에요.

사람의 검토는 마지막 단계에만 두지 않아요

생성된 코드가 2,000줄이 된 뒤 설계 문제를 찾으면 수정 비용이 커져요. 구현 전 계획과 경계를 먼저 확인하면 검토할 코드의 양을 줄일 수 있어요. 타입, 짧은 호출 경로, 명확한 컴포넌트 경계, 교체할 수 있는 의존성도 자동 검사와 사람의 판단을 돕는 장치가 돼요.

개발자의 역할도 달라져요. 모든 변경을 직접 작성하는 시간은 줄어들 수 있어요. 대신 어떤 작업을 자동화할지, 어느 단계에서 승인을 받을지, 실패하면 어디로 돌아갈지를 설계하는 비중이 커져요. AI가 낸 결과를 승인한 뒤의 책임은 여전히 팀에 남아요.

왜 중요한가요

AI 코딩 도구의 성과를 생성한 코드 줄 수나 처리한 작업 수로만 보면 품질 비용을 놓치기 쉬워요. 배포 뒤 결함률, 재작업 시간, 장애 복구 시간, 개발자가 변경 이유를 설명할 수 있는지까지 함께 봐야 실제 생산성을 판단할 수 있어요. 2

도입 순서는 단순해요. 결과를 즉시 판정할 수 있고 실패 범위가 작은 작업부터 맡겨요. 이후 자동 검사와 승인 기록이 충분히 쌓이면 범위를 넓혀요. 장기 설계와 고객 데이터에 영향을 주는 변경에는 사람이 개입하는 지점을 남겨 두는 편이 좋아요.

참고 자료

1. 소프트웨어 팩토리, 빛과 어둠 — GeekNews
2. Software Factories, Light and Dark — Addy Osmani, Elevate