포르투갈어 버전

기술 산업이 새로운 가속기를 발견했다는 것은 더 이상 놀라운 뉴스가 아닙니다. GitHub에서 발표한 데이터에 따르면, Copilot과 같은 AI 도구를 사용하는 개발자는 작업을 최대 55% 더 빠르게 완료할 수 있습니다. 그 약속은 명확하고 매혹적입니다. 더 적은 노력과 더 짧은 시간 안에 더 많은 코드를 전달하는 것입니다.

하지만 구독료를 지불하기 전에 반드시 던져야 할 질문에 주목하는 사람은 거의 없습니다. 우리는 가속화하기 위해 올바른 방향으로 가고 있는가?

자동차 여행 중에 거대하고 비포장된, 구멍이 숭숭 난 도로를 만났다고 상상해 보십시오. 차가 심하게 흔들리기 시작하는 것을 보고, 통제력을 잃거나 차량이 손상되는 것을 피하기 위해 속도를 줄여 계획했던 속도의 1/4로 여행을 계속하기로 결정했습니다. 이런 상황에서 더 강력한 엔진(페라리 같은)을 가진 자동차를 갖는 것이 계획된 속도를 유지(또는 심지어 증가)하기 위해 가속하는 데 도움이 될 것이라고 생각하십니까? 만약 당신의 팀이 매주 수요일마다 바뀌는 우선순위, 요약적으로 무시되는 계획(Planning) 목표, 그리고 끝없는 상류(upstream) 의존성으로 고통받고 있다면, AI는 당신의 문제를 해결해주지 않을 것입니다.

반대로, AI는 문제를 증폭시킬 것입니다. 혼란스러운 환경에서 개발 파이프라인(development pipeline)을 가속화하는 것은 혁신을 만들어내는 것이 아니라, 빛의 속도로 기술 부채(technical debt)를 생성할 뿐입니다. 그리고 무엇보다 최악인 것은, 당신의 회사가 아마도 "우리는 애자일(Agile)하다"라는 라벨을 내세우며 이런 일을 하고 있을 것이라는 점입니다.

이 글에서 우리는 "스크럼 연극(Scrum Theater)"이 AI와 결합하여 어떻게 제품의 신뢰성(및 팀의 사기)을 파괴하고 있는지, 그리고 왜 워크플로 설계(workflow design)가 이 도로를 포장할 수 있는 유일한 방법인지 분석할 것입니다.

"우리는 스크럼(Scrum)을 한다"는 태도의 필요성

"우리는 스크럼(Scrum)을 한다"는 태도의 필요성

만약 100개 회사에 애자일 방법론(agile methodologies) 사용 여부를 물어본다면, 99곳이 '예'라고 답할 것입니다. 하지만 _State of Agile Report_는 매년 조직 문화와 변화에 대한 저항(비즈니스 정렬 부족 등)이 애자일의 진정한 성공을 가로막는 가장 큰 장애물임을 지적합니다.

실제로는 **애자일 극장(Agile Theater)**의 확산만 목격됩니다:

• **데일리 스크럼(The Daily)**은 투입된 시간을 정당화하기 위한 상태 보고서 심문으로 변질됩니다.
• **스프린트 계획 회의(The Sprint Planning)**는 팀이 2일 후에 '긴급 고객 요구사항'에 의해 무시될 목표를 설정하는 공상 과학 세션이 됩니다.
• **회고(The Retrospective)**는 열리기는 하지만, 공허한 의식으로 변질됩니다. 제기된 실행 계획은

upstream(상류)_은 개발자가 유용한 코드의 첫 줄을 작성하기 전에 일어나야 하는 모든 것을 나타냅니다. 제품 사양(product specifications)이 얕거나, 반복 주기(iteration) 중간에 설계가 변경되거나, 팀이 느리고 관료적인 부서의 승인에 의존해야 한다면, 엔지니어링 스쿼드(engineering squad)는 짓눌리게 됩니다.

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

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

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

오늘날에는 역학 관계가 변했습니다. 준비가 부족한 매니저는 회의에서 이해한 아주 적은 양의 정보와 녹취록을 가지고 AI에 던져 넣으며, "요구사항을 생성해 줘"라고 요청한 뒤, "완벽해, 끝났어"라고 생각합니다. 여기서 어떤 결과가 나올 것이라고 기대하십니까? 실제로 일어나는 일은, 개발자가 완료 정의 (Definition of Done, DoD), 준비 완료 정의 (Definition of Ready, DoR), 그리고 매우 전문적으로 보이는 수락 기준 (Acceptance Criteria)까지 갖춘 50줄짜리 결점 없는 설명이 담긴 카드를 받는 것입니다. 하지만 이는 본질적으로 일반적이고 피상적입니다. 개인적으로 저는 근거 없는 50줄의 글을 읽는 것보다, 요구사항을 생성하는 데 사용된 실제 프롬프트 (Prompt)를 받는 것이 "차라리 덜 나쁘다"고 생각합니다.

결국, 카드를 작성한 사람조차 자신이 정확히 무엇을 요구하고 있는지 모릅니다. AI는 명확성이라는 환상을 만들어냈습니다. 그리고 실제로 어떤 일이 벌어질까요? 개발자는 단순히 기술적인 솔루션을 해결하는 것뿐만 아니라, 훨씬 이전에 PM과 고객 사이에서 정의되었어야 할 비즈니스 규칙 (Business Rules)을 역공학 (Reverse-engineer) 해야 하는 상황에 놓이게 됩니다.

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

기술 부채 가속기로서의 AI

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

책임 소재가 불분명하거나 건강한 워크플로우 (Workflow)가 결여된 팀에게 생성형 AI (Generative AI) 도구를 제공하는 것은 정확히 그와 같습니다. 심연을 향해 달려가는 자동차를 얻기 위해 두 발을 맞바꾸는 격입니다. 만약 걸어서 이 절벽 아래로 떨어지는 데 100일이 걸린다면, 이제는 완전히 동력을 갖춘 자동차를 타고 10일 만에 그곳에 도달하게 됩니다. 만약 계획 (Planning) 단계가 무시되었고 수행해야 할 범위 (Scope)가 모호하다면, 나머지 프로세스를 가속화하는 것은 단지 잘못된 것을 훨씬 더 빠르게 만드는 것뿐입니다.

AI는 에픽 (Epics), 제품 문서 (Product documentation), 테스트 스크립트 (Test scripts), 그리고 코드를 빠르고 방대한 양으로 생성합니다. 하지만 적절한 계획과 필요한 감독이 없다면, 전체 가치 스트림 (Value stream)의 신뢰성은 급락합니다. GitClear의 연구와 같은 사례는 소프트웨어 품질의 저하와 코드 churn (Code churn, 급격한 코드 폐기)의 급격한 증가를 수학적으로 증명하며, 특히 프로덕션 (Production) 배포 후 2주 이내에 이러한 현상이 두드러집니다. 그리고 이는 병든 전체 사슬의 마지막 증상일 뿐입니다.

기술 산업은 전문가들이 기술적 및 조직적 부채의 시한폭탄 (A ticking time bomb of technical and organizational debt)이라고 부르는 상황을 만들어내고 있으며, 여기서 속도 그 자체는 위험한 부채 (Liability)로 변합니다. 이러한 "가짜 스크럼 (Facade Scrum)"을 겪는 기업들의 실질적인 결과는 체계적입니다. 관리자는 무엇이 진정으로 가치를 창출하는지에 대한 통제력을 잃고, QA 팀은 인위적으로 생성된 일관성 없는 (Inconsistent) 시나리오에 파묻히며, 개발자들은 몇 달 후에는 유지보수하거나 해독할 수 없는 요구사항과 시스템을 물려받게 됩니다.

하지만 문제는 결코 도구가 아니었습니다. AI는 환상적인 엔진입니다. 문제는 정렬되지 않은 핸들을 보완하기 위해 이 엔진을 사용하려 한다는 점입니다.

길을 닦기: 속도보다 명확성

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

워크플로우(workflow)를 생각하기 전에, 한 걸음 물러나 **기능적 책임의 명확성 (clarity of functional responsibilities)**을 구출해야 합니다. 만약 관리자가 비즈니스 규칙(business rules) 생성을 AI에 아웃소싱하고, 개발자(Developer)가 그 빈틈을 메우기 위해 실시간 요구사항 분석가(requirements analyst) 역할을 강요받고 있다면, 핵심 문제는 바로 _팀 설계 (Team Design)_입니다.

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

1. 업스트림의 구출 (실질적인 제품 발견, Real Product Discovery): Marty Cagan은 그의 저서 "Inspired: How to Create Tech Products Customers Love"에서 기술 기업들이 저지르는 가장 큰 실수는 리스크(가치, 사용성, 기술적 실현 가능성, 비즈니스 생존 가능성)를 먼저 조사하고 완화하지 않은 채 엔지니어링 팀에 요구사항을 밀어붙이는 것이라고 주장합니다. 제품 발견(Product discovery)은 아웃소싱될 수 없습니다. AI는 텍스트를 다듬는 데 도움을 줄 수 있지만, 비판적 사고와 고객 협상을 결코 대체해서는 안 됩니다. 제품 관리자(Product manager)의 역할은 Jira를 최대한 빨리 채우는 것이 아닙니다. 고객에게 약속한 마감 기한을 보장하는 방법은 Jira를 채우는 것이 아니라, 올바른 문제를 해결하고 있는지 확인하는 것입니다. 비즈니스 규칙은 _프롬프트 (prompts)_로 변환되어 개발자에게 배포되기 전에 인간에 의해 토론되고 심화되어야 합니다.
2. 타협 불가능한 준비 완료 정의 (Definition of Ready, DoR): 공식적인 스크럼 가이드(Scrum guide)는 지속적인 리파인먼트(refinement)에 대해 이야기하지만, 업계에서는 _준비 완료 정의 (Definition of Ready, DoR)_를 품질 게이트(quality gate)로 채택해 왔습니다. 린 사고(Lean thinking, Toyota 생산 방식에서 유래된 Lean Software Development)에 따르면, 결함이 있는 원자재를 조립 라인에 투입하는 것은 하류 공정에서 치명적인 병목 현상을 일으킵니다. 소프트웨어 개발에서 원자재는 바로 요구사항입니다. DoR는 기술 팀이 파이프라인에 진입하여 기술 부채(technical debt)가 되기 전, 깊이가 부족한 "원자재"(AI가 생성한 카드)를 거부할 수 있는 공식적인 방패입니다. 엔지니어링 팀에게는 제대로 작동하지 않는 요구사항을 차단할 수 있는 자율성이 필요합니다.

50줄에 달하는 일반적인 범위(scope)를 담은 AI 생성 카드는 "개발 준비 완료(Ready for Development)\