Scrum은 마침내 끝났습니다 🎉 코딩 에이전트 덕분입니다

AI 요약

이 글은 Scrum이 더 나은 방법론에 패배한 것이 아니라, 코딩 에이전트(Coding Agent)의 등장으로 Scrum이 맡아왔던 역할 자체가 사라지고 있다고 주장하는 에세이입니다. 저자는 지난 20년 동안 조직이 매일 스탠드업을 하고, 티켓을 보드에서 옮기고, 작업량을 스토리 포인트(Story Point)로 추정하면서 이를 애자일(Agile)이라고 불렀지만, 실제로는 가벼운 개발 원칙이 복잡한 관료제로 변했다고 지적합니다. Scrum이 널리 퍼진 이유도 그것이 옳아서라기보다 누구나 따라 할 수 있었기 때문이라고 설명합니다.

■ 원칙을 실천으로 바꾸는 과정에서 사라진 Agile의 취지

저자는 Agile Manifesto 자체가 틀린 것이 아니라고 봅니다. 지속적으로 가치를 전달하고, 동기 부여된 구성원을 신뢰하며, 정기적으로 성찰하고 조정하라는 원칙은 지금 읽어도 상식에 가깝다고 말합니다. 문제는 조직이 원칙을 내면화할 경험과 판단력을 갖추지 못했다는 데 있습니다. ‘매일 15분 스탠드업을 합니다’, ‘2주 스프린트를 운영합니다’, ‘작업을 스토리 포인트로 추정합니다’와 같은 실천(practice)은 교육하고 감사하기 쉽습니다. 반면 지속적 가치 전달이나 자율적인 판단은 체크리스트나 Jira 보드에 올릴 수 없습니다.

대규모 조직은 복사하고 교육하고 감사할 수 있는 실천을, 스스로 해석해야 하는 원칙보다 선호하게 됩니다. 저자는 Scrum이 Agile의 가치와 원칙을 참석만 하면 되는 행사와 산출물로 변환한 결과라고 설명합니다. 그 과정에서 번다운 차트(burndown chart)는 성찰을 위한 도구가 아니라 산출량을 감시하는 지표가 되고, 협업은 실제 협력이 아니라 정해진 회의에 참석하는 행위로 축소됩니다. 리더십이 원칙에 헌신하지 않은 채 의식과 도구만 도입하면 Agile 전환은 원래 의도와 정반대의 결과를 낳는다는 주장입니다.

■ 코딩 에이전트가 요구사항을 실행 가능한 형태로 바꿉니다

글의 핵심 사례는 Agile Manifesto의 문장인 ‘비즈니스 담당자와 개발자는 프로젝트 기간 내내 매일 함께 일해야 합니다’입니다. 과거 조직은 이 원칙을 정기적인 스탠드업이나 Slack 채널로 대체했지만, 실제 비즈니스 담당자와 개발자가 같은 문제를 매일 함께 해결하는 일은 드물었다고 저자는 말합니다.

코딩 에이전트와 바이브 코딩(vibe coding)은 이 관계를 바꿀 수 있습니다. 도메인 전문가나 최종 사용자가 직접 에이전트와 대화해 자신이 원하는 것을 작동하는 프로토타입으로 만들 수 있기 때문입니다. 이 경우 ‘함께 일한다’는 말은 회의를 예약하는 일이 아니라, 문제를 가장 잘 아는 사람이 직접 실행 가능한 결과물을 만들어 엔지니어링에 전달하는 흐름이 됩니다. 저자는 기술이 원칙을 더 쉽게 실천하게 만든 것이 아니라, 원칙을 별도의 의식으로 실천해야 할 필요 자체를 줄였다고 표현합니다.

기존의 아이디어 전달 과정은 아이디어에서 Jira 에픽(Jira epic), 정제 회의(refinement session), 사용자 스토리(user story), 인수 조건(acceptance criteria), 추정, 스프린트 약속, 구현, 데모를 거쳐 마지막에 ‘제가 말한 것은 그게 아닙니다’라는 결과에 도달하는 구조였습니다. 저자는 각 단계와 인수인계가 서로 다른 어휘와 이해관계를 가진 사람들이 벌이는 전화 게임이라고 봅니다. 아이디어가 엔지니어에게 도달할 때쯤에는 비즈니스 담당자가 실제로 원했던 바를 담은 대화가, 손실이 발생한 티켓으로 평탄화된다는 설명입니다.

새로운 흐름은 최종 사용자가 원하는 것을 직접 바이브 코딩하고, 그 실행 가능한 형태의 요구사항을 엔지니어링에 전달하는 방식으로 짧아집니다. 문서는 사용자가 무엇을 해야 하는지 설명하지만, 프로토타입은 어떤 필터를 어떤 순서와 기본값으로 제공해야 하는지, 어떤 방식으로 동작해야 하는지를 보여줍니다. 따라서 저자는 실행 가능한 프로토타입(executable prototype)을 지금까지의 요구사항 산출물 중 가장 높은 충실도를 가진 형태로 봅니다. 다만 프로토타입이 곧 제품은 아니며, 그것은 ‘내가 의미한 바는 이것입니다’라고 말하는 검증된 의도(validated intent)일 뿐이라고 분명히 선을 긋습니다.

■ 엔지니어링의 역할은 구현보다 검증과 판단으로 이동합니다

프로토타입이 요구사항이 되면 백로그의 필요성도 다시 묻게 됩니다. 저자는 스프린트 계획, 스토리 포인트, 일정 추정, 번다운 차트, 장시간의 정제 회의, 신뢰받지 못하는 속도(velocity) 대시보드가 많은 경우 더 이상 정당화되기 어렵다고 말합니다. 특히 코딩 에이전트의 작업 속도는 예측하기 어렵습니다. 사소해 보이는 작업이 여러 번의 반복을 요구할 수 있고, 거대해 보이는 작업이 한 번의 프롬프트로 끝날 수도 있으므로, 이를 피보나치 수열로 추정하는 것은 미신에 가깝다는 주장입니다.

저자가 제안하는 대체 구조는 새로운 방법론이나 새로운 의식을 추가하는 것이 아니라, 역량 중심의 반복 루프(capability-driven loop)입니다. 비즈니스 담당자와 최종 사용자는 의도를 프로토타입으로 바꾸고, 엔지니어링은 그 결과물을 조정하고(steer), 견고하게 만들고(harden), 검증하고(verify), 시스템에 통합합니다. 작업은 스프린트 단위가 아니라 지속적이고 풀 기반(pull-based)으로 흐르며, 성과는 완료한 스프린트 수가 아니라 실제 결과(outcome)로 측정해야 합니다.

이 구조에서는 개발자의 역할이 코드를 직접 타이핑하는 일에서 문제를 이해하고, 구현을 판단하고, 안전성과 확장성, 정확성을 보장하는 일로 이동합니다. 비즈니스 담당자는 구현에서 멀리 떨어져 요구사항만 전달하는 사람이 아니라 직접 프로토타입을 만드는 참여자가 됩니다. 저자는 기존의 비즈니스 분석가, Scrum Master, 프로젝트 관리자, 프록시 제품 책임자(Product Owner) 같은 중간 계층이 최종 사용자와 개발자가 직접 소통할 수 없었던 문제를 보완하기 위해 생겨났다고 설명합니다. 에이전트가 양쪽의 직접적인 작업을 가능하게 하면 이러한 중간 계층의 일부는 존재 이유를 잃게 된다는 논리입니다.

■ Conway’s law와 조직의 커뮤니케이션 구조

이 글은 Conway’s law도 변화의 근거로 사용합니다. Conway’s law에 따르면 시스템은 그것을 만드는 조직의 커뮤니케이션 구조를 반영합니다. 사용자와 코드 사이에 여러 단계의 인수인계가 있으면 소프트웨어에도 각 단계의 단절과 오해, 타협이 흔적으로 남습니다. 반대로 최종 사용자와 개발자가 코딩 에이전트를 매개로 거의 한 번에 연결되면, 소프트웨어가 물려받는 커뮤니케이션 단절의 범위도 줄어든다고 저자는 설명합니다.

이는 Agile Manifesto가 꿈꿨던 교차 기능 협업(cross-functional collaboration)이지만, 이제는 조직이 충분히 훈련되고 규율을 지켜야만 가능한 이상이 아니라 작업의 기본 흐름으로 구현될 수 있다는 주장입니다. 다만 글은 이를 무조건적인 낙관론으로 마무리하지 않습니다. AI는 교정기(corrector)가 아니라 증폭기(amplifier)이므로, 조직이 이미 잘못된 방향으로 가고 있다면 그 기능 장애를 더 빠르게 증폭할 수 있다고 경고합니다.

■ 새로운 병목은 검증입니다

코딩 에이전트로 누구나 ‘대략 작동하는’ 소프트웨어를 만들 수 있게 되면, 희소해지는 역량은 생성이 아니라 검증이 됩니다. 결과물이 정확하고, 안전하고, 성능이 충분하며, 유지보수 가능한지 입증하는 일이 새로운 병목입니다. 에이전트가 스스로 모든 검증을 수행한다고 믿을 수 없으므로, 프로토타입을 제품으로 만들기 위해서는 엔지니어링이 강화(hardening) 계층을 진지하게 책임져야 합니다.

저자는 기술적으로 인상적이지만 실제 가치를 제공하지 않는 ‘좋은 나쁜 코드(good bad code)’와, 겉보기에는 괜찮지만 취약점을 조용히 포함한 코드를 함께 경계합니다. 검증 없이 배포하는 바이브 코더는 빠르게 실패할 수 있으며, 성공하는 팀은 가치 있는 문제에서 출발한 뒤 자동화 테스트, 보안 검토, 사람의 최종 판단을 통해 그 가치를 지속할 수 있게 만드는 팀이라고 설명합니다. Scrum을 없애는 일은 안전망을 없애는 것이 아니라, 원래 안전을 보장하지 못했던 가짜 안전망을 제거하는 일입니다. 스프린트와 스토리 포인트는 소프트웨어의 정확성을 보장하지 않고, 관리 가능한 것처럼 보이는 일정표만 제공했기 때문입니다.

결론적으로 저자는 코딩 에이전트를 Scrum 위에 덧붙이는 방식, 예를 들어 에이전트에게 스토리 포인트를 추정하게 하거나 AI 기반 스탠드업을 운영하거나, 아무도 읽지 않을 Jira 티켓을 대량 생성하는 방식은 기존의 비효율을 더 빠르게 만들 뿐이라고 주장합니다. 코딩 에이전트가 바꾸는 것은 새로운 규칙이 아니라, 원칙을 작동하는 결과물로 실행할 수 있는 능력입니다. 따라서 조직은 해방된 역량을 다시 발견(discovery)과 검증(verification)에 투자해야 하며, Scrum은 목적을 다한 뒤 내려놓을 수 있다는 것이 글의 결론입니다.

원문: dev.to / 번역·요약: Trawling