AI의 무게로 인해 SDLC가 무너지고 있는 이유

30년간 이어온 엔지니어링 정통성과 아무도 충분히 이야기하지 않는 변화

저는 현재 엔지니어링 팀 전반에서 벌어지고 있는 특정한 종류의 조직적 아이러니(irony)에 대해 많은 생각을 해왔습니다.

한 기업이 AI 생산성 서사에 매료되어 GitHub Copilot이나 Claude, 혹은 이 둘의 조합을 도입합니다. 그리고 처음 2주 동안 개발자들은 마치 슈퍼히어로가 된 듯한 기분을 느낍니다. 하루가 걸리던 코드가 한 시간 만에 완성됩니다. 기능 모듈의 초안이 거의 즉각적으로 나타납니다. 모두가 흥분합니다.

그러다 약 한 달이 지나면 이상한 일이 발생합니다. 스프린트 속도(sprint velocity)가 실제로 올라가지 않습니다. 티켓 해결 시간(Ticket resolution time)은 완고하게 제자리에 머물러 있습니다. 백로그(backlog)는 줄어들지 않습니다. 그리고 경영진은 조용히 질문하기 시작합니다. "잠깐 — 우리는 모든 곳에 AI를 도입했는데, 왜 아무것도 빨라지지 않는 거지?"

거의 보편적인 답변은, 그들이 마차 안에 제트 엔진을 설치했다는 것입니다.

전통적인 SDLC의 구조

약 30년 동안 소프트웨어 엔지니어링은 소프트웨어 개발 생명주기(SDLC, Software Development Life Cycle)를 중심으로 구조화되어 왔습니다. 조직이 엄격한 폭포수(Waterfall) 모델을 운영하든 빠른 애자일(Agile) 스프린트를 운영하든, SDLC의 _구조적 핵심_은 기능적으로 동일하게 유지되어 왔습니다. 즉, 예측 가능한 게이트(gates)를 통과하는 순차적이고 인간 중심적인 진행 방식입니다.

[1. 계획 (Planning)] ──> [2. 설계 (Design)] ──> [3. 코딩 (Coding)] ──> [4. 테스트 (Testing)] ──> [5. 배포 (Deployment)] ──> [6. 운영 (Ops)]

이 프레임워크는 원래의 맥락에서는 완전히 타당했던 두 가지 근본적인 가정(assumptions)을 바탕으로 설계되었습니다.

가정 1: 인간의 인지 능력이 유일한 엔진이다. 모든 코드 한 줄, 모든 아키텍처 다이어그램, 모든 테스트 스크립트, 그리고 모든 배포 설정은 반드시 인간 개발자에 의해 수동으로 생성되어야 합니다. 파이프라인의 속도는 인간의 처리량(throughput)에 의해 제한됩니다.

가정 2: 핸드오프(Hand-offs)는 결정론적이다. 단계 B가 안전하게 시작되기 전에, 단계 A는 반드시 PRD(제품 요구 사항 문서), 컴파일된 빌드, 승인된 디자인 사양과 같은 정적인 산출물(artifact)과 함께 깔끔하게 종료되어야 합니다. 진행은 선형적입니다.

인간이 진정으로 유일한 실행 엔진이었을 때는 이러한 가정들이 잘 유지되었습니다. 하지만 단 몇 초 만에 작동하는 코드를 초안으로 작성할 수 있는 AI 시스템을 도입하는 순간, 두 가지 가정 모두 산산조각 나기 시작합니다.

속도의 병목 현상 (The Velocity Bottleneck)

제가 계속해서 목격하고 있는 구체적인 실패 모드는 다음과 같습니다.

조직이 고급 LLM(대규모 언어 모델)을 개발자 워크플로에 통합하면, 역사적으로 가장 많은 _실제 시간(clock time)_을 소비했던 단계인 원시 구문(raw syntax) 작성 단계가 몇 주에서 몇 초로 단축됩니다. 이는 진정으로 측정 가능하며 놀라운 역량의 향상입니다.

하지만 즉각적인 코드 생성 엔진을 전통적인, 몇 주가 소요되는 기업 승인 및 수동 테스트 프레임워크 안에 가두어 버린다면, 생산성 향상은 완전히 사라집니다. 병목 현상은 사라지지 않습니다. 단지 이동할 뿐입니다.

만약 자율 에이전트(autonomous agent)가 한 시간 안에 컴파일 가능한 10개의 완전한 기능 업데이트 초안을 작성할 수 있지만, 팀의 피어 리뷰(peer-review) 일정 예약과 QA(품질 보증) 대기열이 항목당 5일이 소요된다면, 파이프라인은 해당 기능들을 처리하는 데 여전히 50일이 걸립니다. 교통 체증에 갇힌 자동차에 로켓 연료를 부은 격입니다.

전통적인 게이트(gates)는 AI 속도의 입력을 흡수하도록 설계되지 않았습니다. 그것들은 인간이 코드를 작성하는 속도가 느리기 때문에 입력이 느리게 도착한다는 가정하에 구축되었습니다.

유령 생산성과 부채의 이동 (Phantom Productivity and the Debt Shift)

어쩌면 더 위험할 수도 있는 두 번째 실패 모드가 있습니다. 제가 **유령 생산성(phantom productivity)**이라고 부르는 것입니다.

개발자들이 이를 둘러싼 더 넓은 시스템 아키텍처 없이 기본적인 AI 코드 자동 완성(autocomplete) 확장 프로그램을 사용할 때, 그들은 종종 검증되지 않은 방대한 양의 코드를 매우 빠르게 생성합니다. 표면적인 지표는 놀라워 보입니다. 하루당 코드 라인 수가 급증하고, 티켓 커밋(ticket commits) 속도가 가속화됩니다.

하지만 그 코드의 실제 _품질_은 종종 양(volume)을 따라가지 못합니다. AI는 컴파일되지만 미묘한 논리적 오류를 포함하거나, 아키텍처 컨벤션을 위반하거나, 인간 개발자가 수동으로 작성하는 과정에서 발견했을 엣지 케이스(edge cases)를 무시하는 그럴듯해 보이는 구문을 생성합니다. 이러한 문제들은 QA 단계에 도달해서—혹은 더 나쁜 경우 프로덕션 환경에서—비로소 드러납니다.

발생한 것은 생산성 향상이 아닙니다. 이것은 인지적 부담(cognitive burden)이 다운스트림으로 이동하는 것입니다. 코딩 단계에서 얻은 속도는 QA 및 코드 리뷰 단계에서 이자처럼 추출됩니다. 인간 검토자들은 매몰되고, 피드백 주기는 느려집니다. 겉보기에 보이는 스프린트 속도 증가는 숨겨진 부채(hidden debt)의 커지는 산을 가리는 것에 불과합니다.

AI가 빠르게 작성했다는 것이 AI가 올바르게 작성했다는 것을 의미하지 않습니다. 그리고 인간은 여전히 그 모든 줄을 읽어야 합니다.

이것이 구조적으로 의미하는 바

업계는 이제 구조적인 현실에 직면하도록 강요받고 있습니다. 즉, 전통적인 SDLC(Software Development Life Cycle)에 단순히 AI를 _삽입_한다고 해서 복합적인 이득(compounding gains)을 기대할 수 없다는 것입니다. SDLC의 아키텍처—순차적이고, 인간의 게이트가 존재하며, 산출물(artifact)-주도적이라는 특성—는 현대 AI 시스템의 속성과 근본적으로 맞지 않습니다.

AI가 생성한 코드는 **결정론적(deterministic)이 아니라 확률적(probabilistic)**입니다. 전통적인 QA 프로세스는 결정론적인 인간의 출력을 검증하도록 설계되었습니다.

AI는 비동기적이고 비인간적인 속도로 작동합니다. 전통적인 리뷰 게이트는 인간의 처리량에 맞춰 페이스가 조정되어 왔습니다.

AI는 고용량의 출력을 생성하며, 이는 고용량의 수동 검토가 아닌 높은 신뢰도의 검증을 필요로 합니다.

이러한 불일치들은 우발적인 마찰(friction)이 아닙니다. 이것은 구조적 비호환성입니다. 여기에 SDLC 래퍼에 더 많은 AI 도구를 붙이는 것은 변속기(transmission)를 건드리지 않고 엔진만 업그레이드하는 것과 같습니다.

이에 대한 대응으로 나타나고 있는 것은 엔지니어링 파이프라인을 처음 원칙(first principles)부터 설계하는 구조적 진화입니다. 이는 SDLC의 점진적인 개선이라기보다는, AI를 실행 엔진으로 삼고 인간이 그 출력을 통제하는 새로운 아키텍처 모델입니다.

업계에서는 이를 AI 기반 소프트웨어 개발 수명 주기(AI-Driven Software Development Life Cycle), 즉 ADLC라고 부르기 시작했습니다.

다음 포스트에서는 이러한 파이프라인들이 내부적으로 실제로 어떻게 작동하는지 구체적인 아키텍처를 다룰 예정입니다. 여기에는 멀티 에이전트 샌드박스(multi-agent sandbox), 클로즈 루프 평가 프레임워크(closed-loop eval framework) 등이 포함되며, AI가 주요 행위자(primary actor)라고 가정하고 파이프라인을 처음부터 재구축할 때 각 단계가 어떻게 보이는지 설명하겠습니다.

참고 자료 (References)

• Royce, W.W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON. 오늘날까지 이해되는 폭포수 모델(waterfall model)을 정의한 기초 논문입니다.
• Beck, K. et al. (2001). Manifesto for Agile Software Development. 폭포수 모델의 경직성에 대한 애자일(Agile) 대응 방식을 공식화한 문서입니다.
• GitHub. (2022). Research: Quantifying GitHub Copilot's impact on developer productivity and happiness. GitHub 블로그. AI 코딩 도구와 측정된 속도 변화에 대한 초기 경험적 데이터입니다.
• McKinsey Global Institute. (2023). The economic potential of generative AI: The next productivity frontier. McKinsey & Company. 소프트웨어 엔지니어링을 포함한 지식 노동 전반에 걸친 생성형 AI 영향에 대한 광범위한 분석입니다.

이 포스트는 Claude의 도움을 받아 저의 생각을 명확히 표현하기 위해 작성되었습니다 — 아이디어, 기술적 관찰 및 의견은 전적으로 저의 것입니다.

대화를 이어가고 싶으신가요? LinkedIn에서 저를 찾아주세요.