늦은 밤, 모니터 세 대가 켜진 개발자의 작업방 책상. AI 코딩 어시스턴트가 1초 만에 수십 줄의 함수를 쏟아내고 있지만, 개발자는 그 코드를 보며 미간을 찌푸린 채 다시 모호한 기획서를 뒤적거린다. '메일 발송 기능을 만들어달라'는 한 줄의 요청 뒤에 숨겨진 수많은 예외 케이스를 정의하느라, 정작 코딩 시간보다 고민하는 시간이 더 길다.

지금 개발자 커뮤니티에서는 AI가 코드를 짜주니 이제 개발자는 프로젝트 매니저(PM, 프로젝트 관리자)처럼 관리만 하면 된다는 낙관론이 뜨겁다. 하지만 현장의 온도는 다르다. 도구는 빨라졌는데 왜 전체 일정은 그대로인지, 아니면 오히려 더 꼬이는지에 대한 냉소적인 반응이 터져 나온다. 단순히 타이핑 속도가 빨라진다고 해서 프로젝트가 빨리 끝난다면, 우리는 모두 타자 연습 학원에 다녔어야 했을 것이다. 이 장면 뒤에는 AI라는 최신 도구로도 해결하지 못한, 고전적인 프로세스의 병목 현상이 자리 잡고 있다.

'The Goal'과 'Toyota Way'가 증명한 프로세스 병목의 원리

간트 차트(Gantt chart, 일정 관리 도구)를 펼치면 가장 길게 늘어진 막대는 언제나 소프트웨어 개발 단계다. 프로젝트 관리자가 생산성을 높이겠다고 가장 먼저 손대는 곳도 바로 여기다. 보통은 인력을 더 투입하거나 최근 뜨거운 감자인 AI를 도입해 코딩 속도를 높이려는 시도를 한다. 하지만 이는 비즈니스 프로세스 모델 및 표기법(BPMN, Business Process Model and Notation)으로 전체 흐름을 뜯어봤을 때 나타나는 착시일 뿐이다. 개발자 커뮤니티에서는 단순히 코드를 빨리 짜는 것이 생산성 향상이라는 믿음에 대해 격렬한 논쟁이 벌어진다. 작업 시간이 길다고 해서 반드시 그 지점이 문제의 근원인 것은 아니라는 점이 지금 다시금 주목받고 있다.

더 미지컬 맨-먼스(The Mythical Man-Month)가 경고했듯 지연되는 프로젝트에 인력을 추가 투입하는 것은 오히려 상황을 악화시킨다. 개발은 단순히 타이핑 속도의 문제가 아니라 복잡한 비즈니스 문제를 컴퓨터가 이해할 수 있는 논리적 솔루션으로 번역하는 고도의 인지 과정이다. 지금 많은 팀이 겪는 진짜 병목은 코딩 자체가 아니라 모호한 요구사항을 해석하고 정의하는 단계에서 발생한다. 예를 들어 판매 완료 후 메일을 보내라는 단순한 요청조차 구체적인 발송 조건이나 예외 상황에 대한 정의가 없으면 개발자는 구현을 시작하지 못하고 멈춘다. AI가 코드를 순식간에 생성한다고 해도 입력값이 부실하면 결국 잘못된 결과물을 뱉어내고 이를 다시 수정하는 핑퐁 과정에서 더 많은 시간이 낭비된다.

이 지점에서 도요타 방식(The Toyota Way)과 더 골(The Goal)이 제시하는 프로세스 최적화의 원리가 강력한 설득력을 가진다. 두 고전이 증명하는 핵심은 병목 지점에 예측 가능하고 품질 높은 입력값을 제공해야 한다는 원칙이다. 법무 검토 프로세스가 느리다고 해서 무작정 변호사를 더 채용하는 것이 해결책이 아니듯, 개발 속도가 느리다고 AI 코딩 툴만 도입하는 것은 근본적인 처방이 될 수 없다. 변호사가 서류 미비로 인해 담당자들에게 일일이 연락하며 시간을 허비하고 있다면 서류의 완성도를 높이는 것이 최우선이다. 개발 프로세스 역시 마찬가지다. 개발자가 불필요한 추측이나 질문 없이 바로 구현에 착수할 수 있도록 상세한 문제 정의와 최종 결과물에 대한 명확한 가이드라인이 제공될 때 비로소 전체 프로젝트의 처리량이 폭발적으로 증가한다. 결국 최적화의 핵심은 가장 오래 걸리는 작업 자체가 아니라 그 작업에 투입되는 입력값의 품질에 있다.

AI의 '광속 코딩'이 해결하지 못하는 요구사항의 모호함

개발자가 바로 체감하는 변화는 코드 작성 속도보다 제어권의 이동이다. 최근 커뮤니티에서는 AI-generated code(AI 생성 코드)가 쏟아지며 개발 속도가 비약적으로 빨라졌다는 찬사가 뜨겁다. 하지만 현장의 분위기는 조금 다르다. 단순히 타이핑 속도가 빨라진다고 해서 프로젝트 전체 기간이 단축되지 않는다는 사실을 개발자들은 이미 뼈저리게 알고 있다. 만약 타이핑 속도가 생산성의 핵심이었다면 모든 개발자가 타자 연습부터 시작했을 것이다. 소프트웨어 개발의 본질은 단순히 코드를 치는 행위가 아니라, 복잡한 문제를 컴퓨터가 이해할 수 있는 해결책으로 번역하는 과정이기 때문이다.

여기서 병목이 발생하는 지점은 바로 요구사항의 모호함이다. 예를 들어 "send mail to user once sale is completed(판매가 완료되면 사용자에게 메일을 보내라)"라는 요청이 내려왔다고 가정하자. 얼핏 보면 명확해 보이지만 실제 구현 단계에서는 수많은 질문이 쏟아진다. 메일에는 어떤 내용이 들어가야 하는지, 판매 과정에서 오류가 발생했을 때도 에러 메일을 보내야 하는지, 그리고 정확히 어느 시점을 판매 완료로 정의할 것인지에 대한 기준이 없다. AI는 이 모호한 문장을 받으면 즉시 그럴듯한 코드를 내놓지만 그것이 비즈니스 로직에 맞는 정답이라는 보장은 어디에도 없다. 제목만 덩그러니 적힌 기능 요청이 실제 무엇을 의미하는지 파악하는 과정이 개발 시간을 가장 많이 잡아먹는 구간이다.

커뮤니티에서는 AI가 개발자를 프로젝트 매니저로 격상시킬 것이라는 기대가 있었으나 현실은 정교한 handholding(AI 가이드 작업)의 연속이다. AI가 짠 코드가 의도대로 작동하게 하려면 개발자는 AI의 손을 잡고 아주 세밀한 부분까지 다시 가르쳐야 한다. 이 과정에서 domain and product experts(도메인 및 제품 전문가)의 깊은 개입이 필수적으로 요구된다. 이는 인간 개발자와 AI 개발 속도를 단순 비교하는 것이 불공평한 이유이기도 하다. 결국 AI를 제대로 활용하려면 기능과 버그 수정 사항을 아주 작은 단위까지 상세하게 기술해야 하는데 이는 역설적으로 AI 시대에 기획자와 도메인 전문가의 역할이 더 중요해졌음을 의미한다.

기존의 개발 방식과 AI 기반 방식을 비교했을 때 속도 차이가 나는 지점은 구현 단계이지 정의 단계가 아니다. 만약 인간 개발자에게도 AI에게 제공하는 수준의 극도로 상세한 요구사항 정의서와 범위 문서가 제공되었다면 생산성은 이미 폭발적으로 상승했을 것이다. 지금의 논쟁은 AI가 코딩을 얼마나 잘하느냐가 아니라 AI에게 입력할 고품질의 데이터를 누가 어떻게 준비하느냐로 옮겨가고 있다. 병목은 코드 생성기가 아니라 그 생성기에 들어갈 입력값의 품질에 있다.

AI 시대 실무자의 생존법: '타이핑'이 아닌 '정의'의 가치

개발자가 코드를 더 빨리 타이핑한다고 해서 프로젝트가 빨라지지는 않는다. 지금 개발자 커뮤니티에서 가장 뜨거운 논쟁은 AI가 코딩 속도를 높였음에도 왜 전체 일정은 그대로인가 하는 지점이다. AI는 코드를 빠르게 생성하지만, 정작 무엇을 만들어야 하는지에 대한 정의는 여전히 인간의 영역에 머물러 있다. 예를 들어 판매 완료 후 사용자에게 메일을 보내라는 요청을 받았을 때, AI는 메일 발송 함수를 순식간에 짜내지만 판매 완료의 정확한 시점이나 예외 상황에서의 처리 로직은 스스로 정의하지 못한다. 결국 AI가 짠 코드가 정답인지 확인하고 수정하는 핸드홀딩 과정이 추가되며, 이 과정에서 도메인 전문가의 훨씬 더 깊은 개입이 요구된다.

많은 이들이 AI 도입으로 개발자가 단순한 프로젝트 관리자로 변할 것이라 예상하지만 실상은 다르다. 오히려 입력값의 품질을 극단적으로 높이는 설계 능력이 핵심 경쟁력이 되는 구조다. 개발자가 과거부터 갈구해온 것은 정교한 문제 정의와 상세한 결과물에 대한 명세였다. AI 시대의 실무자는 단순히 프롬프트를 잘 쓰는 사람이 아니라, 비즈니스 요구사항을 컴퓨터가 오해 없이 실행할 수 있는 수준의 정밀한 설계도로 변환하는 능력을 갖춰야 한다. 타이핑이라는 단순 노동의 가치는 하락하고, 문제의 본질을 규정하는 정의의 가치가 치솟는 시점이다.

이러한 변화는 전사 아키텍처 사무소(Enterprise Architecture Office, 기업 전체의 IT 인프라와 소프트웨어 구조를 표준화하고 관리하는 조직)의 역할과도 맞닿아 있다. 과거 개발자들이 겪었던 고통의 상당 부분은 기술 부채(Technical Debt, 당장의 빠른 구현을 위해 선택한 임시방편이 미래의 수정 비용을 증가시키는 현상)와 추정치를 마감일로 보는 관행(Estimates as deadlines)에서 비롯되었다. AI가 코드를 양산하는 환경에서는 이러한 부채가 더 빠르게 쌓일 위험이 크다. 따라서 무분별한 코드 생성보다 전체 구조를 조망하고 부채를 관리하는 아키텍처 관점의 역량이 생존을 결정한다. 결국 AI 시대의 개발자는 코드를 쓰는 사람이 아니라, 시스템의 무결성을 정의하고 유지하는 설계자로 진화해야 한다.