한 프로젝트 관리자가 간트 차트를 펼쳤습니다. 소프트웨어 개발 구간이 70일로 가장 두꺼웠습니다. 그는 AI 코딩 도구를 도입하면 이 구간을 3일로 줄일 수 있다고 계산했습니다. 도구를 붙이고 나서 실제 일정을 다시 들여다봤을 때, 차트에는 이전에 없던 항목이 생겨 있었습니다. 범위 정의 40일. 개발은 여전히 40일이었습니다.

프로세스 총 길이는 줄어들지 않았습니다. 오히려 이전에는 보이지 않던 단계가 수면 위로 올라왔습니다. AI 도구가 속도를 높여줄 것이라 기대했는데, 실제로는 숨겨져 있던 단계를 가시화했을 뿐입니다. 이 차이를 이해하는 것이 AI 도입 계획을 세우는 1인 사업자나 기획자에게 지금 가장 실질적인 출발점입니다.

코드가 빨라졌는데, 납기는 왜 그대로인가

AI 코딩 도구는 분명히 코드를 빠르게 작성합니다. 이 점은 사실입니다. 반복 패턴, 보일러플레이트, 표준 함수 구현에서는 체감 속도 차이가 큽니다. 깃허브의 코파일럿 연구에서 특정 작업 기준 55%의 속도 향상이 측정됐다는 수치도 있습니다. 문제는 그 55%가 전체 프로젝트 사이클 중 얼마만큼의 비중을 차지하는 구간인가 하는 점입니다.

코드 작성이 전체 프로젝트 일정의 20%라면, 그 20%를 절반으로 줄여봤자 전체 일정은 10% 단축됩니다. 나머지 80%—요건 수집, 리뷰, 의사결정, 검수, 배포 조율—는 AI가 직접 개입하기 어려운 구간입니다. 단계마다 사람이 판단하고 확인하고 승인하는 과정이기 때문입니다.

여기에 구체적인 장면을 하나 더 들어보겠습니다. 어떤 팀이 개발자에게 "판매 완료 시 사용자에게 이메일을 발송하라"는 요건을 전달했습니다. 이 한 문장으로 개발자가 파악해야 하는 것은 무엇일까요. 판매 완료 상태가 결제 승인인지 배송 완료인지 환불 기간 종료인지부터 따져야 합니다. 이메일 수신자는 구매자인지 담당 영업사원인지도 모릅니다. 발송에 실패하면 재시도할 것인지, 한다면 몇 번이나 얼마 간격으로 해야 하는지도 명시되어 있지 않습니다.

이런 모호함이 있으면 코드는 하루 안에 쓸 수 있어도 수정과 확인이 수십 번 반복됩니다. 개발이 길어지는 이유는 개발자가 느려서가 아니라, 개발자가 코드를 짜면서 동시에 요건을 발견해야 했기 때문입니다. AI 도구는 이 발견 과정을 대신해 주지 않습니다.

AI가 실제로 드러낸 것

프로세스에 AI를 얹으면 예상하지 못한 일이 일어납니다. 이전에는 개발자의 경험과 판단력이 채워주던 모호함이 표면으로 드러납니다. 숙련된 개발자는 불완전한 요건을 받아도 과거 경험에서 나온 추정으로 채웁니다. "아마 이런 뜻이겠지"가 작동하는 것입니다. AI 도구는 그 추정이 명시적으로 요청되지 않으면 임의로 채우거나, 반대로 "이 부분은 어떻게 처리할까요?"라고 되묻습니다.

두 경우 모두 요건 정의 작업이 수면 위로 올라옵니다. 앞의 간트 차트 사례에서 범위 정의 40일이 새로 생긴 것은 이 도구가 만들어낸 새로운 문제가 아닙니다. 원래부터 그 단계가 필요했는데, 개발자의 암묵지로 숨겨져 있었을 뿐입니다.

다른 방향에서 보면, AI 도입이 조직의 프로세스 결함을 드러내는 일종의 진단 계기가 된다는 해석도 가능합니다. 속도보다 조직의 숨겨진 취약점을 가시화하는 데 더 직접적인 효과를 내는 상황이 많다는 뜻입니다. 이 관점에서 AI 코딩 도구의 도입은 기대와 다른 방향으로 가치를 만들어냅니다.

속도론에 대한 반론을 정직하게 들어봐야 합니다

다른 입장도 있습니다. AI가 실제로 개발 사이클 전체를 단축시켰다는 보고가 없는 것은 아닙니다. 소규모 팀이나 명확한 요건이 이미 갖춰진 프로젝트에서는 AI 도입 후 납기가 실제로 줄었다는 사례도 있습니다. 특히 혼자 개발과 기획을 모두 담당하는 1인 사업자라면 요건을 스스로 완전히 통제하기 때문에, 코딩 속도 향상이 전체 일정 단축으로 이어질 수 있습니다.

AI 코딩 도구가 프로세스 속도를 높이지 않더라도 개발 비용을 낮춘다는 다른 효과도 있습니다. 외주 개발비 절감, 프로토타입 제작 비용 감소는 납기와 별개로 실질적인 경영 지표에 영향을 줍니다. 이 점을 무시하면 AI 도입의 실질적 가치를 과소평가하게 됩니다.

그러나 이 반론들이 유효한 범위는 제한적입니다. 조직 단위의 프로세스, 여러 역할이 협업하는 프로젝트, 도메인 전문 지식이 필요한 요건—이런 조건에서는 AI 코딩 속도보다 앞단의 품질이 병목을 결정합니다. 코파일럿 연구 역시 개별 개발자 단위의 생산성을 측정했습니다. 조직 단위 프로세스의 납기가 줄었는지는 다른 질문입니다.

앞단을 먼저 점검해야 하는 이유

병목이 요건 정의와 입력값 품질에 있다면, 살펴봐야 할 것은 코드 생성 도구보다 앞에 있습니다.

요건 작성을 구체화하는 훈련이 출발점입니다. "이메일 발송"이 아니라, "구매 상태가 'paid'로 전환된 시점에 구매자 이메일로 주문 확인 메일 발송, 실패 시 3분 간격으로 최대 3회 재시도"처럼 쓰는 방식입니다. 이 구체화 작업 자체에 AI를 활용할 수 있습니다. 모호한 요건을 붙여넣고 "이 요건에서 불명확한 부분을 질문 형태로 나열해 줘"라고 요청하면, 놓친 조건들이 즉시 드러납니다. AI를 생산 도구가 아니라 검토 도구로 쓰는 방식입니다.

도메인 전문가를 요건 작성 초기에 참여시키는 것도 효과가 큽니다. 많은 조직에서 현업 담당자는 개발 완료 후 검수 단계에 처음 등장합니다. 그 시점에 "우리가 원하는 게 아닌데요"라는 피드백이 돌아오면 개발은 처음부터 다시 시작됩니다. AI 도입 여부와 무관하게, 이 구조 자체가 일정 지연의 주요 경로입니다.

프로세스의 실제 병목을 기록하는 것도 빠뜨릴 수 없습니다. 일정이 지연됐을 때 어느 단계에서 며칠이 늘어났는지를 추적하는 조직은 많지 않습니다. 대부분 "개발이 늦었다"로 귀결됩니다. 단계별 리드타임을 실제로 기록하면 병목이 어디 있는지가 보입니다. 이 기록 없이 AI 도구를 도입하면, 어느 병목을 해소하려는 건지 모르는 채로 도구만 늘어납니다.

이런 접근은 AI를 빠른 손으로 쓰는 것이 아니라, 사람이 해야 할 판단의 품질을 높이는 데 쓰는 방식입니다. 무엇을 만들 것인지를 명확히 정리하는 능력, 전문가의 판단을 제때 끌어오는 능력, 프로세스를 구조적으로 보는 능력—이것은 도구가 정교해질수록 더 차별화되는 영역입니다. AI 시대에 인간의 판단력과 태도가 더 중요해진다는 방향은, 기술의 발전 속도와 반비례하지 않습니다.

지난 분기 프로젝트에서 일정이 지연됐을 때 어느 단계에서 며칠이 늘어났는지 기록이 남아 있는 조직과 그렇지 않은 조직은, AI 도구를 도입할 때 출발점 자체가 달라집니다.