기술 산업이 새로운 가속기를 찾았다는 것은 더 이상 생소한 이야기가 아닙니다. GitHub에서 공개한 데이터에 따르면, Copilot과 같은 AI 도구를 사용하는 개발자들은 작업을 최대 55% 더 빠르게 완료할 수 있습니다. 그 약속은 명확하고 매혹적입니다: 적은 노력으로, 더 짧은 시간에, 더 많은 코드를 제공하는 것입니다.

하지만 구독료를 지불하기 전에 던져야 할 질문에 주목하는 사람은 거의 없습니다: 우리가 가속화하는 방향이 올바른가?

당신이 비포장도로이고 구덩이가 가득한 거대한 도로를 달리는 자동차 여행을 상상해 보세요. 차가 미친 듯이 튀기 시작하고, 통제력을 잃거나 차량에 손상을 입히지 않기 위해 속도를 줄여 계획했던 속도의 1/4로 계속 나아갑니다. 이런 상황에서 더 강력한 엔진(페라리 같은)을 가진 차가 있다면, 계획된 속도를 유지하거나 심지어 높이는 데 도움이 될 것이라고 생각하십니까? 만약 당신의 팀이 매주 수요일마다 바뀌는 우선순위, 쉽게 무시되는 Planning 목표, 그리고 영원히 지속되는 upstream 의존성으로 고통받고 있다면, AI가 당신의 문제를 해결해주지 않을 것입니다.

오히려 그것은 그 문제를 증폭시킬 것입니다. 혼란스러운 환경에서 개발 컨베이어 벨트를 가속하는 것은 혁신을 창출하지 않고, 빛의 속도로 기술 부채를 만듭니다. 그리고 최악인 것은: 당신의 회사는

100개의 기업에 애자일 (Agile) 방법론을 사용하는지 묻는다면, 99개는 그렇다고 답할 것입니다. 하지만 State of Agile Report에 따르면, 매년 조직 문화와 변화에 대한 저항(예: 비즈니스 정렬의 부재)이 진정한 애자일 성공을 가로막는 가장 큰 장애물임을 지적하고 있습니다.

실제로 우리가 목격하는 것은 **애자일 시어터 (Agile Theater, 애자일 연극)**의 확산입니다:

• **데일리 (Daily)**는 근무 시간을 정당화하기 위한 상태 보고 (status report) 심문으로 변질됩니다.
• **스프린트 플래닝 (Sprint Planning)**은 팀이 목표를 약속하지만, 이틀 뒤 '고객의 긴급 요청'에 의해 그 목표가 짓밟히게 되는 공상 과학 세션이 됩니다.
• **회고 (Retrospective)**는 수행되기는 하지만, 공허한 의식이 됩니다.

_upstream_은 개발자가 유용한 첫 번째 코드 라인을 작성하기 전에 일어나야 하는 모든 것을 나타냅니다. 제품 사양(specifications)이 얕거나, 반복(iteration) 도중에 디자인이 변경되거나, 팀이 느리고 관료적인 부서의 승인에 의존해야 한다면, 엔지니어링 스쿼드(squad)는 압박을 받게 됩니다.

많은 기업의 현실은 작업이 흐르는(flow) 것이 아니라, 밀려 들어온다는(pushed) 것입니다. 개발자는 Jira에서 차단된(blocked) 여러 개의 카드를 떠안게 되며, 이미 다른 영역에서 지연되고 결함이 있는 상태로 태어난 비현실적인 목표를 달성하려 노력하며 스트레스를 받습니다. 이러한 시나리오에서 팀은 자율성을 잃고, 불을 끄고 절반뿐인 요구사항을 해독하려고 애쓰는 반응적인 "기능 공장(feature factory)"으로 변질됩니다.

그리고 바로 이 지점에서 AI의 성급한 도입이 위험한 선을 넘게 됩니다.

동료 개발자들과 이 주제에 대해 이야기해 보았을 때, 서로 다른 기술 분야와 심지어 서로 다른 국가의 기업에서 일하고 있음에도 불구하고 매우 유사한 문제에 직면해 있다는 사실이 놀라웠습니다. 예를 들어, LLM의 붐이 일어나기 전에는 프로젝트 매니저(GP)나 프로덕트 매니저(Product Manager)가 기능(feature)의 비즈니스 규칙을 완전히 매핑하지 못했을 때 그 사실이 명확히 드러났습니다. 그들은 자신이 할 수 있는 방식으로 설명했고, 개발자는 카드를 읽으면서 해당 작업 범위(scope)의 깊이(또는 그 결여)를 즉시 식별할 수 있었습니다. "이 부분은 고객과 더 명확히 이해해야 합니다."라고 손을 들고 말하기가 쉬웠던 것입니다.

오늘날에는 역학 관계가 바뀌었습니다. 준비가 부족한 매니저가 회의에서 이해한 적은 내용과 전사(transcription)를 가져와 AI에 던져 넣고는 "요구사항을 생성해 줘"라고 요청한 뒤, "완벽해, 업무 끝"이라고 생각합니다. 그 결과로 무엇을 기대하시나요? 실제로 일어나는 일은 개발자가 완료 정의 (Definition of Done, DoD), 준비 완료 정의 (Definition of Ready, DoR), 그리고 매우 전문적으로 보이는 수락 기준(acceptance criteria)이 포함된 50줄짜리 완벽한 설명이 담긴 카드를 받는 것입니다. 하지만 본질적으로 그것들은 일반적이고 피상적입니다. 저는 개인적으로 근거 없는 50줄을 읽는 것보다, 요구사항을 생성하는 데 사용된 프롬프트(prompt) 자체를 받는 것이 "차라리 나은" 선택이라고 생각합니다.

결국, 카드를 작성한 사람조차 자신이 정확히 무엇을 요청하고 있는지 모릅니다. AI가 명확성이라는 환상을 만들어낸 것입니다. 그리고 실제로 어떤 일이 벌어질까요? 개발자는 기술적인 솔루션을 해결해야 할 뿐만 아니라, 원래 프로젝트 매니저(GP)와 고객 사이에서 사전에 정의되었어야 할 비즈니스 규칙(business rules)을 역공학(reverse engineering)해야 하는 상황에 처하게 됩니다.

지금 이 순간에도 여러분 회사의 얼마나 많은 프로세스에서 이런 일이 일어나고 있는지 생각해 보십시오. 기술 문서, 사용자 문서, 요구사항 정의 등 말입니다.

기술 부채의 가속기로서의 AI

인터넷을 돌아다니다가 철학자이자 저널리스트인 카를 크라우스(Karl Kraus)의 인용구를 본 적이 있습니다. 그는 맹목적인 진보를 비판하며 이렇게 말했습니다. "인류가 심연을 향해 행진하고 있다면, 나는 자동차를 타고 가기보다 차라리 걸어서 가겠다."

자신의 책임이나 건강한 워크플로우(workflow)가 명확하지 않은 팀에게 생성형 AI(Generative AI) 도구를 제공하는 것은 정확히 이와 같습니다. 심연을 향해 발 대신 자동차로 갈아타는 것입니다. 만약 회사가 걸어서 이 심연으로 추락하는 데 100일이 걸렸다면, 이제는 초고속 엔진을 달고 10일 만에 도착하게 됩니다. 만약 플래닝(Planning)이 무시되었고 수행해야 할 범위(scope)가 모호하다면, 나머지 프로세스를 가속화하는 것은 단지 잘못된 것을 훨씬 더 빠르게 만드는 것일 뿐입니다.

AI는 에픽 (epics) 전체, 제품 문서, 테스트 로드맵, 그리고 코드를 매우 빠르고 방대한 양으로 만들어냅니다. 하지만 적절한 계획과 필요한 모니터링이 없다면, 전체 가치 흐름 (value stream)의 신뢰성은 급락합니다. GitClear의 연구와 같은 사례들은 소프트웨어 품질의 저하와, 특히 프로덕션(production) 배포 후 최대 2주 이내에 발생하는 코드 처닝 (code churn, 코드의 급격한 폐기 및 변경)의 급격한 증가를 수학적으로 증명하고 있으며, 이는 병든 전체 체인의 마지막 증상일 뿐입니다.

기술 산업은 전문가들이 기술적 및 조직적 부채의 시한폭탄이라고 부르는 것을 만들어내고 있으며, 여기서 고립된 속도는 위험한 부채로 변합니다. 이러한 "겉치레 스크럼 (Scrum de Fachada)"를 겪는 기업들의 실질적인 결과는 시스템적입니다. 매니저들은 무엇이 실제로 가치를 창출하는지에 대한 통제력을 잃고, QA 팀은 인위적으로 생성된 일관성 없는 시나리오들에 파묻히며, 개발자들은 몇 달 후에는 유지보수하거나 해독할 수 없는 요구사항과 시스템을 물려받게 됩니다.

하지만 문제는 결코 도구가 아니었습니다. AI는 환상적인 엔진이지만, 문제는 핸들의 정렬 불량(misalignment)을 보완하기 위해 이 엔진을 사용하려고 시도하는 것입니다.

도로를 닦기: 속도보다 명확성

이 글을 읽으며 여러분은 이렇게 생각할지도 모릅니다: "세상에, 정말 그렇네. 당장 우리 회사에서 스크럼(Scrum) 사용을 중단하자고 제안해야겠어". 혼란스러운 상황 앞에서, 새로운 기적의 프레임워크(framework)를 찾거나 스크럼을 지속적 흐름(continuous flow)으로 교체하려는 시도는 많은 기업의 본능적인 반응입니다. 하지만 팀을 재평가하지 않고 관리 도구만 바꾸는 것은 단지 이 연극의 배우를 교체하는 것에 불과합니다.

워크플로 (workflow)를 생각하기 전에, 한 걸음 물러나 **직무 책임의 명확성 (clarity of functional responsibilities)**을 회복해야 합니다. 만약 매니저가 비즈니스 로직 (business rule) 생성을 AI에게 외주 주고, 개발자 (Developer)가 공백을 메우기 위해 실시간 요구사항 분석가 (requirements analyst) 역할을 강요받고 있다면, 핵심 문제는 _팀 디자인 (Team Design)_에 있습니다.

이 길을 어떻게 닦아야 할지 조사하던 중, 저는 세 가지 구조적 기둥으로 수렴하는 연구들을 발견했습니다.

1. 업스트림 (Upstream)의 회복 (진정한 프로덕트 디스커버리 (Product Discovery)): Marty Cagan은 저서 "Inspired: How to Create Tech Products Customers Love"에서 기술 기업들이 범하는 가장 큰 실수는 리스크 (가치, 사용성, 기술적 타당성, 비즈니스 타당성)를 먼저 조사하고 완화하지 않은 채 엔지니어링 팀에 요구사항을 밀어넣는 것이라고 주장합니다. 프로덕트 디스커버리 (product discovery)는 외주를 줄 수 없습니다. AI가 텍스트를 다듬는 데 도움을 줄 수는 있지만, 비판적 사고와 고객과의 협상을 결코 대체해서는 안 됩니다. 프로덕트 매니저 (product manager)의 역할은 Jira를 최대한 빨리 채우는 것이 아닙니다. 그것은 고객에게 약속한 기한을 보장하는 방법이 아닙니다. 올바른 문제를 해결하고 있는지 보장하는 것이 그들의 역할입니다. 비즈니스 로직 (business rules)은 프롬프트 (prompts)가 되어 개발자들에게 배포되기 전에, 인간에 의해 토론되고 심화되어야 합니다.

2. 타협 불가능한 준비 완료 정의 (Definition of Ready, DoR): Scrum 공식 가이드에서는 지속적인 리파인먼트 (refinement)를 말하지만, 업계에서는 _준비 완료 정의 (Definition of Ready, DoR)_를 품질 게이트 (quality gate)로 채택했습니다. (도요타 생산 방식에서 유래한 Lean Software Development의) 린 (Lean) 사고방식에 따르면, 결함이 있는 원자재를 조립 라인에 투입하는 것은 향후 치명적인 병목 현상 (bottleneck)을 초래합니다. 소프트웨어 개발에서 원자재는 요구사항 (requirement)입니다. DoR는 기술 팀이 깊이 없는 (AI에 의해 생성된 카드와 같은) "원자재"가 워크플로에 진입하여 기술 부채 (technical debt)로 변하기 전에 거부할 수 있는 공식적인 방패입니다.

엔지니어링 팀은 비기능적인 요구사항을 차단할 자율성이 있어야 합니다. 50줄의 일반적인 범위로 AI가 생성한 카드는 '개발 준비 완료(Ready for Development)'로 간주될 수 없습니다. DoR은 요구사항의 엄격한 품질 필터여야 하며, 기술 팀이 상위 단계(upstream)의 혼란을 흡수하는 것을 막아 보호해야 합니다.

3. 흐름 자체가 결과: 조직 설계에 대한 현대 문헌은 팀의 위상(topology)을 이해하기 전에 작업 모델을 강제하려는 시도는 무익하다는 것을 증명합니다. 책임 경계가 명확해질 때(제품 범위가 어디서 끝나고 엔지니어링 범위가 어디서 시작하는지) 비로소 워크플로우를 설계해야 합니다. Scrum, Kanban 또는 _Unfix_의 원칙을 채택하든, 프로세스는 회사 현실에 봉사하여 마찰을 최소화하고, 인지 부하(cognitive load)를 줄이며, 진행 중인 재작업을 방지해야 합니다. 흐름은 개발자의 인지 부하를 줄이도록 설계되어야 합니다. 컨웨이의 법칙(Law of Conway)은 소프트웨어 시스템이 회사의 커뮤니케이션 구조 복사본이라는 것을 말합니다. 만약 제품과 엔지니어링 간의 커뮤니케이션이 단절되거나 AI에게 위임된다면, 코드 아키텍처는 필연적으로 이러한 분열과 혼란을 반영할 것입니다.

인공 지능 도구들은 견고한 조직적 기반 위에서 작동할 때 비로소 진정한 초능력이 됩니다. 누가 무엇을 하는지 정렬하지 않고 개발 속도를 높이는 것은 붕괴로 가는 가장 빠른 길입니다.

결론: 속도보다 방향성