소프트웨어 업계는 익숙한 환상에 빠져 있다. 2000년대에는 해외 아웃소싱, 2010년대에는 마이크로서비스가 그 주인공이었다. 매번 같은 꿈을 꿨다. 개발자 생산성을 단숨에 끌어올릴 ‘마법의 총알’, 즉 관리자가 단 한 번의 결정으로 더 빠르고 저렴하며 완벽한 소프트웨어를 낼 수 있게 해주는 해결책이다. 그리고 오늘날 그 새로운 지렛대는 생성형 AI다. 설명은 매혹적으로 단순하다. 개발 속도를 늦추는 병목이 ‘코드를 작성하는 일’이라면, LLM이 코드를 즉시 써줄 수 있으니 개발 속도는 폭발적으로 향상될 것이라는 주장이다.

하지만 소프트웨어 개발의 한계는 타이핑 속도에 있지 않다. 실제 병목은 언제나 그 외의 모든 과정에 있었다. 무엇을 만들지 결정하고 방향성을 맞추며, 이미 존재하는 생태계에 통합하고 보안과 규정을 통과시킨 뒤, 실제 운영 환경에 올리는 일까지. 이 모든 과정이 진짜 속도를 좌우한다.

AI는 문법, 기본 구조, 반복적인 코드를 처리하는 데 도움을 줄 수 있다. 하지만 동시에 다른 문제를 악화시킬 수도 있다. ‘복잡성을 값싸게 만들어버린다’는 점이다. 누구나 손쉽게 코드를 생성할 수 있게 되면, 오히려 구조적 복잡도가 폭발적으로 증가할 수 있다.

그렇다면 이 문제를 어떻게 해결할 수 있을까? 답은 플랫폼이다. 혹은 ‘포장된 도로(paved road)’나 ‘황금 경로(golden path)’라 불리는 접근법이다. 이름은 달라도 핵심은 같다. 개발자에게 일정한 가드레일과 방향성을 제공함으로써, 조직 전체의 개발 생산성을 근본적으로 높일 수 있다는 것이다.

생산 vs. 생산성

현재까지의 증거가 유용한 이유는, 그것이 하나의 편안한 결론을 제시하지 않기 때문이다. 예를 들어 METR의 무작위 대조 실험에서는 복잡한 저장소에서 이미 익숙하게 작업하던 숙련된 오픈소스 개발자가 AI 도구를 사용할 때 오히려 작업을 완료하는 데 약 19% 더 오래 걸린 것으로 나타났다. 흥미로운 점은 스스로는 작업을 더 빨리 끝낼 것이라고 믿고 있었다는 것이다. 전혀 다른 환경에서, 깃허브가 보고한 통제된 실험에서는 깃허브 코파일럿을 사용한 개발자가 특정하고 독립적인 프로그래밍 과제를 훨씬 빠르게 완료했으며, 작업 경험도 더 긍정적으로 느꼈다고 밝혔다.

그렇다면 어느 쪽일까? AI는 가속 장치인가, 아니면 닻인가? 정답은 ‘그렇다’이다. 그리고 바로 그 모호함이 핵심이다. 건강한 시스템에 AI를 투입하면 속도가 배가된다. 그러나 분열된 시스템에 AI를 도입하면 혼란이 배가된다. 결과는 어떤 모델을 선택하느냐보다, 그 모델이 작동하도록 허용한 환경이 어떠하냐에 좌우된다. “AI가 개발자를 생산적으로 만든다”라는 주장은 도구의 문제가 아니다. 아니, 도구의 문제여서는 안 된다. 그것은 시스템의 문제다.

그 환경의 문제는 새로운 것이 아니다. ‘프롬프트 엔지니어링’이 직업명이 되기 훨씬 전부터 필자는 제한받지 않는 개발자의 자유가 이미 기업 현실과 충돌하고 있다고 지적해왔다. 자유는 처음에는 민첩성처럼 느껴지지만, 시간이 지나면 곧 난립, 분절, 그리고 누구도 예산에 포함하지 않았던 통합 비용으로 바뀐다. 생성형 AI는 이 흐름을 되돌리지 않는다. 오히려 가속시킨다. 나쁜 결정을 늦춰주던 마찰이 사라지기 때문이다.

이 지점에서 리더십은 늘 같은 근본적인 실수를 반복한다. ‘생산(Production)’과 ‘생산성(Productivity)’을 혼동하는 것이다. 생산성을 “더 많은 코드를 빠르게 배포하는 것”으로 정의한다면, AI는 인류 최고의 발명품이다. 하지만 실제 운영 환경에서 코드는 독립적인 자산이 아니다. 코드는 보안, 관찰, 유지보수, 통합이라는 책임이 반드시 따라붙는 부채다. 새로운 서비스, 의존성, 프레임워크, 그리고 ‘영리한 추상화’가 추가될 때마다 시스템의 표면적이 넓어지고, 그 표면적은 속도를 취약성으로 바꾸는 지점이 된다.

AI는 표면을 만들어내는 비용을 사실상 0에 가깝게 낮춘다. 과거에는 잘못된 아키텍처 결정이 구현에 필요한 시간 때문에 어느 정도 제약을 받았다. 그러나 이제는 주니어 엔지니어도 구현 세부 사항을 AI 어시스턴트가 처리해주기 때문에 자신이 완전히 이해하지 못한 채 수많은 서비스를 생성하고 그것들을 그럴듯한 코드로 엮을 수 있다. 팀은 처음에는 그 속도에 자부심을 느낄 것이다. 하지만 시스템을 감사하거나 보안 패치를 적용하거나 확장하거나 다른 팀에 인계해야 하는 순간이 오면 상황은 달라진다.

그때가 되면 ‘생산성 향상’이라 믿었던 결과는 결국 운영 비용으로 되돌아온다.

AI 시대의 개발자 생산성을 이야기하려면 배포 효율부터 짚어야 한다. DORA 지표는 여전히 냉정한 현실 검증 도구다. 이 지표는 단순한 작업량이 아니라 처리량과 안정성을 측정한다. 즉, 변경 리드타임, 배포 빈도, 변경 실패율, 복구 소요 시간 같은 항목이다. SPACE 프레임워크도 유용하다. 이 모델은 생산성이 다차원적임을 보여준다. ‘더 빨라진 것처럼 느껴지는 것’이 반드시 ‘실제로 더 빨라진 것’을 의미하지는 않는다.

AI는 반복적인 작업을 줄여 초기 만족도를 높인다. 그것은 분명 중요하다. 하지만 팀이 장황하거나 미묘하게 잘못되었거나 내부 표준에 맞지 않는 AI 생성 코드를 검증·디버깅·수정하는 데 시간을 쓴다면 만족도는 높을 수 있어도 실제 성과는 오히려 떨어질 수 있다.

AI 시대의 생산성을 솔직하게 측정하고 싶은 관리자가 주목해야 할 단 하나의 지표가 있다. ‘준수된 배포까지의 시간(Time to Compliant Deployment)’이다. 즉, 작업이 ‘준비 완료’ 상태에서 실제 프로덕션 환경에서 필수 보안 통제, 관찰 가능성, 정책 검증이 충족된 상태로 실행되기까지 걸린 시간을 추적하라는 의미다.

업계가 여전히 회피하려 하는 부분이 있다. 바로 AI가 ‘자유의 문제’를 더 악화시킨다는 점이다. 게르게이 오로스는 AI가 더 많은 코드를 작성하게 될수록 엔지니어가 추상화 계층의 상위 단계로 이동하게 된다고 지적한다. 개발자의 역할이 코드를 작성하는 일에서 검토, 통합, 그리고 아키텍처적 결정을 내리는 일로 옮겨간다는 것이다. 겉으로 보면 승진처럼 들린다. 멋지지 않은가? 그럴 수도 있다. 하지만 실제로는 팀 내에서 시스템 전반을 이해하는 수준이 고르지 않기 때문에 오히려 부담이 될 수 있다.

문제는 여기서 더 복잡해진다. 무언가를 만들어내는 비용이 낮아질수록 그 결과를 조율하는 비용은 높아진다. 모든 팀이 AI를 이용해 각자 맞춤형 솔루션을 생성하도록 허용하면 결국 스택과 프레임워크, 운영 가정이 제각각인 누더기 같은 구조가 만들어진다. 표면적으로는 풀 리퀘스트와 단위 테스트에서 모두 괜찮아 보일 수 있다. 그러나 누군가 그것을 통합하고, 보안을 적용하고, 실제로 운영해야 할 때는 어떤 일이 벌어질까? 그 시점에서 조직은 느려진다. 개발자가 타이핑을 못 해서가 아니라, 시스템이 하나로 정합되지 않기 때문이다.

포장된 도로와 플랫폼

포레스터의 최근 연구는 이 문제의 핵심을 정확히 짚는다. 연구에 따르면 아키텍처 커뮤니티는 “기업 민첩성의 숨은 엔진”이다. 이는 서비스 지향 아키텍처(service-oriented architecture, SOA) 시대처럼 아무도 읽지 않는 다이어그램만 그리던 상아탑식 아키텍트 조직을 다시 만들자는 뜻이 아니다. 오히려 수많은 통합 우회 작업이 만들어내는 막대한 비용을 막자는 것이다. 포레스터는 협업이 부족할 경우 아키텍트들이 전체 업무 시간의 최대 60%를 혁신이 아니라 서로 다른 시스템을 ‘억지로 이어붙이는’ 데 쓴다고 지적했다. 그리고 AI를 통제하지 않은 채 방치한다면 그 비율은 90%까지 치솟을 것이라고 경고했다.

해결책은 AI를 금지하는 것도, 무분별하게 풀어놓는 것도 아니다. 해결책은 ‘도로를 포장하는 것’이다. 필자는 이미 여러 차례 ‘황금 경로’의 필요성에 대해 글을 쓴 바 있다. 황금 경로, 혹은 넷플릭스에서 부르는 포장된 도로는 명확한 방향과 지원이 보장된 프로덕션으로의 경로를 뜻한다. 이는 서로 결합 가능한 서비스, 템플릿, 그리고 가드레일로 구성된 시스템으로, ‘옳은 방식으로 소프트웨어를 만드는 길’을 ‘가장 손쉬운 길’로 만들어준다.

AI 시대에는 황금 경로가 선택 사항이 아니다. 이미 개발자가 짊어진 인지적 부담은 한계에 다다랐다. 그런 상황에서 라이브러리, 모델, 프롬프트 전략, RAG 아키텍처까지 직접 선택하라고 요구하는 것은 번아웃을 부르는 일이다. 플랫폼 팀은 이런 반복적이고 지루한 부분을 표준화해야 한다.

두 가지 상황을 상상해보자. 첫 번째는 이렇다. 한 개발자가 AI에게 마이크로서비스를 만들어달라고 요청한다. AI는 인터넷을 뒤져 임의의 프레임워크를 선택하고, 회사의 보안 정책을 단 하나도 지키지 않는 코드를 작성한다. 개발자는 처음 10분 동안 자신이 아주 빠르게 일하고 있다고 느낄 것이다. 그러나 그 뒤에는 일주일 내내 보안 검토 과정과 싸워야 한다.

두 번째 상황에서는 개발자가 황금 경로의 위에 있다. AI는 내부 템플릿만 사용하도록 제한되어 있다. 그 결과, AI가 생성한 서비스에는 회사의 인증 체계, 로깅 사이드카(logging sidecar), 배포 매니페스트가 이미 연결되어 있다. AI가 작성한 코드는 특별할 것 없는 평범한 코드다. 하지만 그 코드는 규정을 준수하고, 단 10분 만에 배포된다. 이 경우 생산성 향상은 AI가 코드를 잘 써서 얻어진 것이 아니다. 그것은 AI를 유용한 경계 안으로 묶어둔 플랫폼의 힘에서 비롯된 것이다.

앞으로 10년 동안 가장 생산적인 개발자는 가장 자유로운 사람이 아니다. ‘가장 잘 설계된 제약’을 가진 사람일 것이다. 그렇게 해야 복잡한 시스템 문제에 매몰되지 않고, 진짜 해결해야 할 문제에 집중할 수 있기 때문이다. 개발팀의 책임자라면, 당신의 역할은 생산성을 억누르는 제약이 아니라 생산성을 가능하게 하는 제약을 설계하는 것이다.
dl-itworldkorea@foundryco.com