Agile은 속도가 아니라 방향을 검증하는 방식이다

AI가 코드를 더 빨리 만들게 되면서, 개발에서 속도는 점점 덜 희귀한 자원이 되고 있다.

이제 혼자서도 화면을 만들고, API를 붙이고, 배포까지 갈 수 있다. 예전에는 팀이 필요하던 작업이 한 사람의 오후 작업이 되기도 한다.

문제는 그래서 더 빨리 옳은 제품을 만들 수 있느냐는 것이다.

속도는 방향을 대신하지 못한다. 오히려 방향이 틀렸을 때, 빠른 속도는 낭비를 더 빠르게 키운다.

Agile은 빠르게 개발하기 위한 이름이 아니다. 틀린 방향을 오래 붙잡지 않기 위한 검증 방식에 가깝다.

이 문서는 Agile의 역사, 핵심 개념, 오해, 한계, 그리고 AI 시대에 이 사고방식이 왜 여전히 유효한지를 정리한다. Agile 입문서가 아니다. Agile을 알고 있지만 왜 작동하는지, 왜 실패하는지, AI가 들어온 지금 어떻게 다시 생각해야 하는지를 다룬다.

이 글을 읽는 방법

이 글은 Agile을 빠른 개발 방법론으로 소개하지 않는다.

먼저 Agile이 왜 등장했는지, 어떤 문제를 해결하기 위한 것이었는지 살펴본다. 그 다음 Scrum, Kanban, XP 같은 도구들이 무엇을 검증하기 위한 장치인지 정리한다. 이후 AI 시대의 기업, 창업자, 1인 개발자에게 Agile이 어떤 의미로 다시 필요해지는지 다룬다.

이미 Agile을 알고 있다면 2026년에 Agile을 다시 묻는 이유와 AI가 만든 결과를 Agile하게 검증하는 기준부터 읽어도 된다.

Agile을 처음 접하거나 맥락부터 이해하고 싶다면 Agile 이전: Waterfall이 만들어낸 문제부터 시작하면 된다.

이 글은 읽다 지쳐도 된다. 목적은 한 번에 전부 이해하는 것이 아니라, 필요할 때 돌아와서 검증 기준으로 쓰는 것이다.

2026년에 Agile을 다시 묻는 이유

2001년 Agile Manifesto가 나왔을 때, 개발 속도는 사람의 손이 만드는 것이었다. Scrum이 처음 설명됐던 1990년대에도, Kent Beck이 XP를 제안했을 때도, 코드는 사람이 한 줄씩 쳤다.

그 시대의 핵심 긴장은 이것이었다. "무엇을 만들어야 하는지 안다. 하지만 만드는 데 너무 오래 걸린다."

2026년의 긴장은 다르다.

바이브 코딩 시대의 개발 루프

Claude Code, Cursor, GitHub Copilot이 일상적인 개발 루프에 들어왔다. 화면 레이아웃을 설명하면 코드가 나온다. API 구조를 말하면 엔드포인트가 만들어진다. 데이터 처리 로직을 설명하면 함수가 완성된다.

정교한 설계보다 원하는 결과의 느낌을 AI에게 전달하면서 반복적으로 수정해가는 이 흐름을, 최근에는 흔히 "바이브 코딩(Vibe coding)"이라고 부르기도 한다.

1인 개발자가 오후 몇 시간 만에 작동하는 프로토타입을 만들고, 다음 날 랜딩 페이지를 붙이고, 사흘 후 첫 사용자를 받는 일이 이제 예외가 아니다. 예전에는 팀이 몇 주를 써야 나오던 것이 한 사람의 하루 작업이 된다.

생성 속도보다 검증 능력이 병목이 됐다

만드는 것이 빨라졌다. 하지만 그 빠른 속도는 새로운 문제를 만들었다.

예전에는 "이게 맞나?" 하고 의심할 시간이 자연스럽게 있었다. 코드를 짜면서 생각했다. 기획서를 쓰면서 다듬었다. 느린 속도가 자연스러운 검증 시간을 만들었다.

AI가 빠르게 만들어주면, 확인하기 전에 이미 다음 기능이 보인다. 다음 기능을 만들고, 또 다음이 보인다. 이 루프가 계속 돌아간다.

빠른 완성이 위험한 것이 아니다. 빠른 확신이 위험하다.

"이게 맞는 것 같은데"를 확인하기 전에 다음으로 넘어가는 것, 그것이 AI 시대의 새로운 방향 상실 패턴이다. 방향이 틀렸을 때 오래 붙잡지 않기 위한 장치 — 그것이 Agile이었다. 그런데 지금은 그 장치가 더 빠르게 작동해야 할 이유가 생겼다.

AI 에이전트가 들어온 팀의 새로운 긴장

혼자 만드는 개발자만의 문제가 아니다. 팀이 있는 기업에서도 비슷한 긴장이 생기고 있다.

지금 개발 현장에서 벌어지는 일들을 구체적으로 보면 이렇다.

AI 에이전트가 비동기로 여러 작업을 동시에 처리하는 팀이 생겼다
PR이 사람보다 AI에 의해 더 많이 만들어지기 시작했다
코드 작성 속도는 올랐지만 코드를 이해하는 속도는 그대로다
창업자가 MVP를 하루 만에 만들었지만 사용자를 못 얻는다
코드 작성보다 요구사항 검증이 병목이 됐다

이 상황에서 경영진은 본다. AI 도구를 쓰면 더 빠르게 만들 수 있다. 그러면 더 많이 만들 수 있어야 한다.

"우리도 AI 써서 속도 높이자." "AI 쓰면 더 빨리 되는 거 아니야?"

이 압박은 자연스럽다. 하지만 이 압박 아래서 팀은 만들어야 할 것을 확인하기 전에 만들기 시작한다. 방향을 검증하는 시간이 줄고, 구현하는 시간이 늘어난다.

결과는 기존의 Agile 왜곡과 같다. 더 빠른 속도로 틀린 방향으로 달린다.

그래서 Agile은 2026년에 더 필요하다

Agile Manifesto의 핵심은 "자주 확인하라"다.

구현이 느렸을 때, 자주 확인하는 것은 구현 사이클을 더 짧게 만드는 것이었다. 구현이 빨라진 지금, 자주 확인하는 것은 더 중요해졌다. 확인 없이 달리는 속도가 더 빨라졌기 때문이다.

이 문서는 그 확인의 방식을 다룬다.

Agile 이전: Waterfall이 만들어낸 문제

Waterfall은 단계가 순서대로 흐르고, Agile은 짧은 루프를 반복한다

Agile이 무엇인지 이해하려면 그 이전에 무엇이 있었는지부터 봐야 한다.

소프트웨어 개발이 산업화되기 시작하던 1970년대, 많은 조직이 제조업에서 쓰던 방식을 그대로 가져왔다. 공장에서 자동차를 만들 때처럼 소프트웨어도 순서대로 만들면 된다고 생각했다. 기획이 끝나면 설계가 시작되고, 설계가 끝나면 개발이 시작되고, 개발이 끝나면 테스트가 시작된다. 각 단계는 앞 단계가 완전히 끝나야 시작할 수 있다.

이 방식을 Waterfall이라고 부른다. 위에서 아래로 흐른다는 뜻이다.

Waterfall은 논리적으로 보인다. 설계 없이 개발하면 안 된다. 요구사항 없이 설계하면 안 된다. 당연한 말이다.

하지만 소프트웨어는 공장에서 만드는 물건과 다른 점이 있다. 자동차 설계도는 완성되기 전에 작동하는 자동차를 보여줄 수 없다. 소프트웨어는 작동하는 버전을 일찍 보여줄 수 있다.

Waterfall의 문제는 바로 여기서 시작된다.

늦은 피드백이 만드는 비용

Waterfall 방식에서 실제로 작동하는 소프트웨어를 볼 수 있는 것은 모든 개발이 끝난 뒤다. 기획에 6개월, 설계에 3개월, 개발에 9개월이 걸렸다면, 18개월이 지나야 비로소 "이게 맞나?"를 확인할 수 있다.

18개월이 지나면 시장이 바뀌어 있을 수 있다. 처음에 가정했던 사용자의 문제가 더 이상 그 사람들의 가장 큰 문제가 아닐 수 있다. 경쟁자가 이미 비슷한 것을 출시했을 수도 있다.

더 심각한 문제는 방향이 틀렸을 때의 수정 비용이다.

개발 시작 직전에 요구사항이 바뀌면 설계만 다시 하면 된다. 개발 중간에 방향이 바뀌면 코드를 다시 써야 한다. 개발이 끝난 뒤에 방향이 틀렸다는 것을 알면 거의 전부를 다시 해야 한다.

이것을 변경 비용 곡선이라고 부른다. 늦게 발견할수록 수정 비용은 기하급수적으로 커진다.

Waterfall은 이 곡선 위에서 가장 비싼 지점에 피드백을 놓는다.

Chaos Report와 소프트웨어 프로젝트 실패율

Standish Group은 1994년부터 소프트웨어 프로젝트의 성공률을 추적해왔다. 1994년 초기 보고서를 기준으로, 프로젝트의 약 31%가 취소됐고 52%가 예산 초과 또는 일정 지연을 겪었으며 완전한 성공은 16%에 불과했다고 보고됐다. 이후 수치는 개선되는 경향을 보이지만, 소프트웨어 프로젝트에서 늦은 피드백이 실패 비용을 키운다는 경향 자체는 반복적으로 관찰됐다.

이 실패의 원인을 보면 공통된 패턴이 있다. 요구사항이 불명확했고, 사용자 참여가 부족했으며, 기대와 현실의 간격이 너무 컸다.

Waterfall에서 사용자가 관여하는 시점은 보통 기획 초기와 최종 검수 단계다. 그 사이 18개월 동안 개발팀은 초기에 이해한 요구사항을 바탕으로 만든다. 사용자의 생각이 그 사이에 바뀌어도 반영할 방법이 없다.

문서가 현실을 대체한 문제

Waterfall에서는 각 단계가 문서로 이어진다. 요구사항 문서가 설계 문서를 만들고, 설계 문서가 개발 명세를 만든다.

이 문서들은 현실을 모델링한다. 문제는 현실이 바뀌면 문서가 뒤처진다는 것이다.

개발자는 문서를 보고 만든다. 문서가 현실의 요구를 정확히 반영하지 못하면, 개발자가 아무리 잘 만들어도 틀린 것을 만들게 된다.

Agile은 이 문제에 대한 반응이었다. 문서 대신 실제로 작동하는 소프트웨어를 자주 보여주자. 그러면 방향이 틀렸을 때 일찍 알 수 있다.

Agile Manifesto: 원문이 실제로 말하는 것

2001년 2월, 유타주 스노우버드 스키 리조트에 17명의 소프트웨어 개발자들이 모였다. 이들은 이미 각자의 방식으로 더 나은 개발 방법을 실험하고 있었다. XP(Extreme Programming), Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development 등 서로 다른 방식이었지만 공통된 생각이 있었다.

기존 방식은 너무 무겁다. 더 가볍고 더 빠르게 반응할 수 있어야 한다.

이 모임에서 나온 것이 Agile Manifesto다. 4개의 가치와 12개의 원칙으로 구성된 짧은 선언문이다.

4가지 가치

원문을 그대로 옮기면 이렇다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

중요한 것은 마지막 문장이다. Agile Manifesto는 문서, 계약, 계획이 필요 없다고 말하지 않는다. 그것들보다 상호작용, 작동하는 소프트웨어, 협력, 변화 대응에 더 높은 가치를 둔다고 말한다.

이 뉘앙스를 잃으면 "Agile = 문서 없이 코딩"처럼 오해하게 된다.

12가지 원칙

Manifesto에는 4가지 가치를 뒷받침하는 12가지 원칙이 있다. 요약하면 이런 내용들이다.

고객 만족을 최우선으로. 가치 있는 소프트웨어를 지속적으로 일찍 제공해서 고객을 만족시키는 것이 최우선이다.

변화를 환영하라. 개발 후반이라도 요구사항 변경을 환영한다. Agile 프로세스는 변화를 경쟁 우위로 활용한다.

자주 배포하라. 몇 주에서 몇 달 주기로 작동하는 소프트웨어를 배포한다. 짧을수록 좋다.

비즈니스와 개발자가 함께 일하라. 고객과 개발자는 프로젝트 내내 함께 일해야 한다.

동기를 부여받은 개인들 중심으로. 프로젝트는 동기 있는 사람들을 중심으로 만들어야 한다. 필요한 환경과 지원을 주고 신뢰해야 한다.

대면 대화. 팀 내외에서 정보를 전달하는 가장 효과적인 방법은 대면 대화다.

작동하는 소프트웨어가 진척의 척도. 완성된 문서나 계획이 아니라, 실제로 작동하는 소프트웨어로 진척을 측정한다.

지속 가능한 개발. 개발자, 사용자, 스폰서 모두 일정한 속도를 무기한 유지할 수 있어야 한다.

기술적 탁월함과 좋은 설계. 지속적인 기술 탁월성과 좋은 설계에 대한 관심이 Agility를 높인다.

단순함. 하지 않아도 되는 일의 양을 최대화하는 기술이다.

자기 조직적 팀. 최고의 아키텍처, 요구사항, 설계는 자기 조직적 팀에서 나온다.

정기적 회고. 팀은 주기적으로 더 효과적으로 일하는 방법을 반성하고 조정한다.

이 12가지를 보면 "빠르게 만들어라"는 원칙이 없다. 있는 것은 "자주 확인하라", "변화에 반응하라", "지속 가능하게 가라"다.

Manifesto가 나온 맥락

이 선언문을 쓴 사람들은 대부분 이미 실제 현장에서 대안적인 방식을 시도하고 있었다. Kent Beck의 XP는 1999년에 나왔고, Scrum은 1990년대 중반부터 Ken Schwaber와 Jeff Sutherland가 만들어오고 있었다.

이들이 공유한 문제의식은 같았다. 너무 많은 소프트웨어 프로젝트가 실패하고 있다. 그 이유는 대부분 기술적 문제가 아니라 프로세스와 커뮤니케이션 문제다.

Manifesto는 이 공통된 문제의식에 이름을 붙인 것이다.

Agile의 주요 방법론들

Agile은 하나의 구체적인 방법론이 아니다. Agile Manifesto의 가치와 원칙을 구현하는 여러 방법론들이 있다. 그중 가장 많이 쓰이는 것들을 살펴본다.

Scrum

Scrum은 현재 가장 널리 쓰이는 Agile 프레임워크다. 소프트웨어 개발뿐 아니라 다른 많은 분야에서도 쓰인다.

Scrum의 핵심은 Sprint라는 고정된 시간 주기다. 보통 1~4주, 가장 흔하게는 2주를 사용한다. Sprint 안에서 팀은 목표를 정하고, 그 목표를 달성하기 위한 작업을 하고, Sprint가 끝나면 결과를 검토한다.

Scrum의 역할

Product Owner는 무엇을 만들어야 하는지를 결정한다. 비즈니스 가치와 우선순위를 관리하고, Product Backlog를 유지한다. Product Owner는 "왜"와 "무엇"을 담당한다.

Scrum Master는 프로세스를 지원한다. 팀이 Scrum을 제대로 이해하고 실행하도록 돕고, 장애물을 제거하고, 팀이 방해받지 않고 일할 수 있는 환경을 만든다. Scrum Master는 "어떻게"를 담당하지 않는다. "어떻게"는 팀이 결정한다.

Development Team은 실제로 무언가를 만드는 사람들이다. 개발자, 디자이너, QA 등 필요한 역할을 가진 사람들로 구성된다. Scrum에서 팀은 자기 조직적이다. 누가 무엇을 할지는 팀이 스스로 결정한다.

Scrum의 이벤트들

Sprint Planning은 Sprint가 시작될 때 하는 회의다. 이번 Sprint에서 무엇을 할지 결정한다. Product Backlog에서 Sprint Backlog로 항목을 가져온다.

Daily Scrum(또는 Daily Standup)은 매일 하는 짧은 동기화 미팅이다. 어제 무엇을 했는가, 오늘 무엇을 할 것인가, 진행을 막는 것이 있는가 — 이 세 질문을 중심으로 팀이 장애물을 인식하고 협력한다. 진행 보고가 아니라 방향 확인의 자리다.

Sprint Review는 Sprint가 끝날 때 하는 검토 세션이다. 완성된 것을 보여주고 피드백을 받는다. 중요한 것은 이것이 단순한 데모가 아니라 실제 피드백을 얻는 자리여야 한다는 것이다.

Sprint Retrospective는 팀이 스스로 어떻게 일했는지를 돌아보는 세션이다. 무엇이 잘 됐는가. 무엇이 잘 안 됐는가. 다음에 무엇을 다르게 할 것인가. 많은 팀이 이것을 생략하거나 형식적으로 진행하는데, 그러면 Scrum의 핵심 학습 루프가 없어진다.

Scrum의 각 이벤트는 방향을 검증하는 장치다

Scrum의 이벤트들을 단순히 일정표로 보면 형식이 된다. 각각이 어떤 방향 검증을 위한 것인지를 알아야 의미 있게 작동한다.

Sprint Planning은 "이번에 어떤 가설을 확인할 것인가"를 결정하는 자리다. 할 일 목록을 가져오는 것이 아니라, 이번 주기에 무엇을 배울지를 정하는 것이다.

Daily Scrum은 방향이 맞는지 팀이 매일 확인하는 짧은 루프다. "어제 막힌 것이 방향에 영향을 주는가"를 묻는 것이지, 진행 상황을 보고하는 것이 아니다.

Sprint Review는 데모가 아니라 방향 검증의 자리다. 실제 사용자나 고객이 만든 것을 써보고 "이게 내 문제를 해결하는가"를 확인하는 것이 목적이다. 내부 팀끼리 박수치는 자리가 되면 방향 검증이 빠진 것이다.

Sprint Retrospective는 감상회가 아니라 다음 루프를 바꾸는 장치다. "지난번과 이번이 무엇이 달랐는가, 다음 루프에서 무엇을 바꿀 것인가"가 핵심이다. Action Item이 없으면 루프가 개선되지 않는다.

Product Owner는 할 일을 정하는 사람이 아니라 가설의 우선순위를 책임지는 사람이다. "이 기능이 이 사용자의 이 문제를 해결할 것이다"는 가설 — 그것의 우선순위와 검증 기준을 관리하는 것이 Product Owner의 실질적 역할이다.

Product Backlog와 Sprint Backlog

Product Backlog는 제품에 필요한 모든 것을 우선순위 순으로 정렬한 목록이다. 맨 위에 가장 중요하고 잘 정의된 것, 아래로 갈수록 모호하고 우선순위가 낮다. 계속 변하는 살아있는 문서다.

Sprint Backlog는 이번 Sprint에서 할 것들을 Product Backlog에서 꺼내온 목록이다. Sprint가 시작되면 팀이 직접 관리한다.

User Story

Backlog 항목은 보통 User Story 형태로 쓴다. "[역할]로서, 나는 [기능]을 원한다. 그래야 [이유]를 달성할 수 있다." — 기능 명세가 아니라 누가 왜 필요한지를 남기는 것이 목적이다.

User Story에는 Acceptance Criteria(인수 기준)가 붙는다. 완료의 조건을 명시하지 않으면 "완료"가 사람마다 달라진다.

Definition of Done

Definition of Done(DoD)은 팀이 합의한 "완료"의 정의다. "코드 작성 완료"가 완료인가? 테스트 작성까지가 완료인가? 코드 리뷰까지가 완료인가? QA 통과까지가 완료인가? 배포까지가 완료인가?

이 정의가 팀마다, 조직마다 다르다. 중요한 것은 팀이 명시적으로 합의해야 한다는 것이다. 암묵적인 "완료"는 나중에 문제를 만든다.

Velocity

Velocity는 팀이 Sprint마다 완료하는 Story Point의 양이다. Story Point는 작업의 크기와 복잡도를 상대적으로 측정하는 단위다.

Velocity는 예측을 위한 도구다. 팀이 Sprint마다 평균 40 Story Point를 완료한다면, 120 Story Point짜리 프로젝트는 대략 3 Sprint가 걸릴 것이라고 예측할 수 있다.

Velocity의 문제는 목표로 쓰기 시작할 때다. "이번 Sprint에 50 Story Point를 달성해야 한다"는 목표가 되면, 팀은 Story Point 추정을 조작하기 시작한다. Goodhart's Law다. 측정치가 목표가 되면 더 이상 좋은 측정치가 아니다.

Kanban

Kanban은 Toyota의 생산 시스템에서 나왔다. 1940년대 Toyota에서 재고를 관리하기 위해 만든 카드 시스템을 소프트웨어 개발에 적용한 것이다.

Scrum이 시간 주기(Sprint)를 중심으로 한다면, Kanban은 흐름(Flow)을 중심으로 한다.

Kanban 보드

Kanban 보드는 작업의 상태를 시각화한다. 가장 기본적인 형태는 세 컬럼이다. To Do, In Progress, Done.

팀마다 컬럼을 다르게 구성한다. 예를 들면 이런 식이다. 백로그 → 분석 → 개발 → 리뷰 → 테스트 → 배포 → 완료.

이 보드의 목적은 작업이 어디서 막히는지를 보는 것이다. 특정 컬럼에 카드가 쌓이기 시작하면, 거기에 병목이 있다는 신호다.

WIP Limit

Kanban의 핵심 개념은 WIP(Work In Progress) Limit이다. 동시에 진행할 수 있는 작업의 수를 제한한다.

예를 들어 개발 컬럼의 WIP Limit이 3이라면, 동시에 개발 중인 작업은 최대 3개다. 이미 3개가 진행 중이면 새 작업을 시작하지 않는다.

이것이 직관에 반하게 느껴질 수 있다. 바쁜 것처럼 보이고 싶으면 여러 개를 동시에 진행해야 하지 않나?

하지만 동시에 많은 것을 진행하면 각각이 느려진다. 컨텍스트 전환 비용이 발생한다. 각각이 완료되는 시점이 늦어진다. WIP Limit은 흐름을 빠르게 하기 위해 한 번에 하는 것을 제한한다.

Scrum vs Kanban

Scrum은 시간 주기가 있다. Sprint가 끝나면 검토하고 계획을 세운다. Kanban은 시간 주기가 없다. 작업이 완료되면 다음 작업을 당긴다(Pull).

Scrum은 팀 전체가 Sprint 목표를 향해 함께 일한다. Kanban은 개인이 자신의 작업 흐름을 관리한다.

Scrum은 역할이 정의된다. Product Owner, Scrum Master, Development Team. Kanban은 기존 역할을 그대로 유지한다.

어느 것이 더 낫냐는 맥락에 따라 다르다. 계획 가능한 작업이 많고 팀이 함께 방향을 맞춰야 한다면 Scrum이 맞을 수 있다. 예측하기 어려운 지원 업무나 지속적으로 들어오는 요청을 처리한다면 Kanban이 맞을 수 있다.

많은 팀이 둘을 섞어 쓴다. Scrumban이라고 부르기도 한다.

Dechive Note

Kanban은 일을 더 많이 하기 위한 보드가 아니다. 흐름이 어디서 막히는지 보기 위한 검증 장치다. WIP Limit은 속도를 제한하는 것이 아니라, 병목을 드러내서 팀이 그것을 해결하게 만드는 구조다. 카드가 쌓이는 컬럼이 답을 알고 있다.

XP (Extreme Programming)

XP는 Kent Beck이 1990년대 후반에 만든 방법론이다. 기술적 실천을 중심으로 한다. 좋은 것들을 극단까지 밀어붙이자는 것이 아이디어다.

테스팅이 좋다면 항상 테스트를 먼저 작성하자(TDD). 코드 리뷰가 좋다면 항상 두 명이 함께 코딩하자(Pair Programming). 통합이 자주 일어나야 한다면 하루에도 여러 번 통합하자(Continuous Integration).

Test-Driven Development (TDD)

TDD는 테스트를 먼저 작성하고 그 테스트를 통과하는 코드를 작성하는 방식이다.

Red → Green → Refactor의 주기를 반복한다. 실패하는 테스트를 작성하고(Red), 그 테스트를 통과하는 최소한의 코드를 작성하고(Green), 코드를 개선한다(Refactor).

TDD의 장점은 설계를 개선한다는 것이다. 테스트하기 어려운 코드는 보통 설계가 나쁜 코드다. 테스트를 먼저 생각하면 자연스럽게 더 모듈화된 설계가 나온다.

단점은 익숙해지기까지 시간이 걸리고, 처음에는 느리게 느껴진다는 것이다. 특히 UI가 많이 포함된 개발에서는 TDD를 적용하기 어렵다.

Pair Programming

두 명이 하나의 컴퓨터 앞에서 함께 코딩하는 것이다. 한 명은 코드를 작성하고(Driver), 다른 한 명은 전략을 생각하고 리뷰한다(Navigator). 역할을 자주 바꾼다.

직관적으로는 비효율적으로 보인다. 두 명이 하나의 작업을 한다. 하지만 실제로는 코드 품질이 높아지고 버그가 줄고 지식이 팀 안에 더 잘 공유된다는 연구 결과들이 있다. 단, 맥락에 따라 다르다. 단순 반복 작업에서는 효과가 크지 않다.

Continuous Integration (CI)

코드를 자주 통합하는 것이다. 하루에도 여러 번 메인 브랜치에 코드를 병합한다.

CI의 목적은 통합의 고통을 줄이는 것이다. 오랫동안 분기해서 작업하다 합치면 충돌이 크고 해결이 어렵다. 자주 합치면 충돌이 작고 해결이 쉽다.

현재 대부분의 소프트웨어 팀이 CI를 쓰고 있다. CI 도구(GitHub Actions, Jenkins, CircleCI 등)가 자동으로 테스트를 실행하고 빌드가 통과하는지 확인한다.

Dechive Note

XP는 개발자가 더 열심히 코딩하기 위한 방식이 아니다. 빠른 변화 속에서도 코드가 무너지지 않게 만드는 기술적 검증 장치다. TDD는 코드를 먼저 설계하게 만들고, Pair Programming은 혼자 보지 못하는 것을 드러내고, CI는 변경이 전체를 망가뜨리지 않았는지 매번 확인한다.

AI가 코드를 만들어주는 지금, XP의 기술적 실천들은 더 중요해진다. AI는 테스트를 생략해도 작동하는 코드를 만들 수 있다. 하지만 테스트 없는 코드는 방향을 바꿀 수 없는 코드다.

SAFe와 대규모 Agile의 문제

Scrum, Kanban, XP는 소규모 팀을 위한 방법론이다. 수십 명, 수백 명이 일하는 대규모 조직에서 Agile을 적용하려면 다른 접근이 필요하다.

이를 위해 만들어진 것들이 SAFe(Scaled Agile Framework), LeSS(Large-Scale Scrum), Nexus 등이다.

SAFe는 가장 복잡한 형태다. PI Planning(Program Increment Planning), Agile Release Train, Solution Train 등 복잡한 구조를 갖는다. 많은 기업이 SAFe를 도입했지만 효과에 대해서는 논란이 많다.

Agile 커뮤니티 안에서도 비판이 있다. Manifesto를 만든 사람 중 일부는 SAFe가 Agile의 핵심 가치를 잃었다고 말하기도 한다. 너무 많은 규칙과 프로세스가 오히려 적응성을 없앤다는 것이다.

대규모 조직에서 진정한 Agile을 구현하는 것은 여전히 어려운 문제다. 이 문서에서 깊이 다루기보다는, 이 영역이 여전히 진행 중인 실험의 영역이라는 것을 인식하는 것이 더 정직한 입장이다.

Agile이 "빠른 개발 방법론"으로 오해된 이유

Agile이 널리 퍼지면서 원래 의미에서 벗어나는 일이 생겼다. 이것을 이해하는 것은 Agile을 제대로 쓰기 위해 중요하다.

도구가 목적을 대체한 문제

Scrum이 보급되면서 Scrum의 형식이 앞에 나오기 시작했다. Daily Standup을 한다. Sprint를 돌린다. Retrospective를 한다. 이것들이 Agile의 실천으로 여겨졌다.

하지만 형식을 따른다고 Agile해지는 것이 아니다.

Daily Standup에서 세 가지 질문에 답하지만 팀이 실제로 서로 돕지 않으면, 그것은 매일 하는 진행 보고에 불과하다.

Sprint를 2주마다 돌리지만 Sprint Review에서 아무런 피드백도 얻지 못하면, 그것은 짧은 주기의 Waterfall이다.

Retrospective에서 같은 말만 반복하고 아무것도 바뀌지 않으면, 그것은 형식적인 절차에 불과하다.

Certified Scrum Master의 확산

Scrum Alliance와 Scrum.org는 Scrum Master 자격증을 발급하기 시작했다. 며칠짜리 교육을 받으면 "Certified Scrum Master"가 될 수 있다.

자격증 자체가 나쁜 것은 아니다. 하지만 조직들이 자격증을 Agile 능력의 증거로 보기 시작하면서 문제가 생겼다. 자격증을 가진 Scrum Master가 팀에 들어와 프로세스를 강요하지만, 실제로 팀의 문제를 해결하는 것과는 거리가 있는 경우가 생겼다.

"Agile Transformation"이라는 이름의 리브랜딩

많은 기업이 "Agile Transformation"을 선언했다. 하지만 실제로 바뀐 것은 표면적인 것들뿐인 경우가 많았다.

팀 이름이 바뀌었다. 회의 이름이 바뀌었다. 포스트잇 보드가 생겼다. 하지만 의사결정 구조는 여전히 위계적이고, 요구사항은 여전히 위에서 내려오고, 피드백 루프는 여전히 없다.

"Agile"이 이름은 됐지만 실질이 빠진 것이다.

속도 압박과 Agile의 왜곡

Agile이 "빠르게 배포하는 방법"으로 이해되면서, 경영진이 Agile을 채택해 속도를 높이려는 경우가 생겼다.

"우리도 Agile하게 하면 더 빨리 만들 수 있겠지."

이 기대 아래서 팀은 속도를 높이라는 압박을 받는다. Sprint 속도를 높여야 한다. 더 많은 Story Point를 완료해야 한다.

이것은 Agile의 목적과 반대다. Agile은 더 빠르게 만들기 위한 것이 아니라, 더 올바른 것을 만들기 위한 것이다.

속도 압박 아래에서 팀은 자주 품질을 타협한다. 테스트를 줄이고, 기술 부채를 쌓고, 리뷰를 서두른다. 단기적으로는 빨라 보이지만 장기적으로는 느려진다.

중요한 것은 스프린트 주기가 아니라 피드백 루프다

Agile의 핵심을 한 문장으로 말하면 피드백 루프다.

방향이 맞는지 자주 확인한다. 틀렸으면 수정한다. 다시 만들고 다시 확인한다.

이 루프가 작동하려면 세 가지가 필요하다.

첫째, 확인할 것이 있어야 한다. 작동하는 소프트웨어. 실제로 동작하고 사용자가 써볼 수 있는 것이어야 한다. 디자인 목업이나 문서가 아니라.

둘째, 누군가 확인해야 한다. 실제 사용자나 고객. 개발팀끼리만 보면 방향 확인이 안 된다. 만든 사람은 자기가 만든 것을 보는 관점이 다르다.

셋째, 확인한 것이 다음 방향에 반영되어야 한다. 피드백을 받았는데 아무것도 바뀌지 않으면 루프가 완성되지 않는다.

많은 팀이 이 세 가지 중 하나 이상을 놓친다.

데모를 하지만 실제 사용자가 아니라 내부 이해관계자에게만 보여준다. 피드백을 받지만 Backlog에 넣고 언젠가 보자고 한다. Sprint Review를 하지만 아무것도 바뀌지 않는다.

피드백 없는 Sprint는 짧은 주기의 Waterfall이다.

Sprint를 2주마다 돌린다고 Agile한 것이 아니다. 2주마다 방향이 맞는지 확인하고 조정한다면 Agile하다.

피드백의 종류

피드백에는 여러 종류가 있다.

사용자 피드백. 실제로 제품을 사용하는 사람들의 반응. 가장 가치 있는 피드백이지만 얻기 가장 어렵기도 하다. 사용자 인터뷰, 유저 테스트, 설문, 실제 사용 데이터 등으로 얻는다.

데이터 피드백. 분석 도구를 통해 얻는 정량적 정보. 어떤 기능을 쓰는지, 어디서 이탈하는지, 얼마나 자주 돌아오는지. 정량적이라는 장점이 있지만 "왜"를 말해주지 않는다.

팀 내 피드백. 코드 리뷰, 설계 검토, QA. 기술적 품질에 대한 피드백이다. 방향보다 실행의 질에 대한 피드백이다.

시장 피드백. 경쟁 제품의 변화, 시장 트렌드, 업계 동향. 더 느리고 간접적이지만 전략적 방향에 영향을 준다.

이 중 가장 직접적인 것은 사용자 피드백이다. Agile에서 "고객과의 협력"을 가치로 두는 이유가 여기 있다.

피드백 루프의 속도

피드백 루프는 빠를수록 좋다. 하지만 현실적인 제약이 있다.

매일 피드백을 얻을 수 있다면 좋지만, 매일 사용자 인터뷰를 하기는 어렵다. 매일 데이터가 쌓이더라도 유의미한 패턴이 보이려면 시간이 필요하다.

Sprint의 의미는 피드백을 받을 수 있는 최소한의 주기를 만드는 것이다. 2주에 한 번이라도 실제 피드백을 받는다면, 달에 한 번이나 6개월에 한 번보다 훨씬 빠르게 방향을 수정할 수 있다.

AI 시대와 Agile: 어떻게 달라졌나

AI가 개발에 들어오면서 Agile의 맥락이 달라지고 있다.

AI 이전: 구현이 병목이었다

AI 이전에 소프트웨어 개발에서 가장 느린 부분은 구현이었다. 무엇을 만들어야 하는지 알더라도 실제로 만드는 데 시간이 걸렸다.

이 맥락에서 Agile의 "빠르게 만들고 자주 배포"는 구현 속도를 높이는 것처럼 보였다.

AI 이후: 방향이 병목이 됐다

AI가 들어오면서 구현의 속도가 빨라졌다. Claude Code, GitHub Copilot, Cursor 같은 도구들은 코드 생성 속도를 크게 높였다.

이제 "무엇을 만들어야 하는가"를 아는 사람이 훨씬 빠르게 만들 수 있다.

문제는 "무엇을 만들어야 하는가"를 아는 것은 AI가 해결해주지 않는다는 것이다.

AI에게 "사용자가 좋아할 기능을 만들어줘"라고 해도 AI는 그 판단을 할 수 없다. AI는 명시적인 요청을 구현할 수 있다. 하지만 그 요청이 사용자의 실제 문제를 해결하는지는 알 수 없다.

구현 속도가 빨라졌다는 것은 방향 판단의 중요성이 커졌다는 것이다.

같은 시간에 더 많은 것을 만들 수 있다. 하지만 방향이 틀리면, 같은 시간에 더 많은 잘못된 것을 만들게 된다.

AI와 함께 일할 때의 방향 확인 위험

AI로 개발할 때 특유의 위험이 있다.

AI는 요청에 빠르게 응답한다. 다음 기능을 만들어달라고 하면 만들어준다. 그것을 배포하면 또 다음 기능이 보인다. 이 사이클이 매우 빠르게 돌아간다.

이 속도에서 "잠깐, 이게 맞는 방향인가?"를 묻는 것이 오히려 어렵게 느껴질 수 있다. 빠르게 달리는 중에 멈추는 것이 어렵다.

하지만 멈추지 않으면 방향 확인이 없다. 빠르게 달리는데 방향이 없으면, 빠르게 틀린 곳으로 가는 것이다.

AI가 Agile 루프의 어느 부분을 바꾸는가

Agile 루프는 질문 → 가설 → 구현 → 관찰 → 수정의 반복이다.

AI는 이 중 "구현"의 속도를 크게 높인다. 작은 기능을 몇 시간이 아니라 몇 분 만에 만들 수 있다.

"관찰"에도 AI가 도움이 될 수 있다. 데이터를 분석하고, 패턴을 찾고, 보고서를 만드는 것을 AI가 도와줄 수 있다.

하지만 "질문"과 "가설"은 여전히 사람의 영역이다. 어떤 사용자의 어떤 문제를 해결하려 하는가. 이 기능이 그 문제를 해결할 것이라는 가설은 어디서 왔는가.

그리고 "수정"의 판단도 사람의 영역이다. 관찰한 것이 가설을 지지하는가, 아닌가. 다음 방향을 어떻게 바꿔야 하는가.

AI가 Agile 루프를 빠르게 만들어주는 것이 맞다. 하지만 AI가 빠르게 해주는 부분이 루프의 일부분이라는 것을 인식해야 한다.

AI가 만든 코드의 검증 문제

AI가 코드를 만들면 그 코드가 실제로 의도한 대로 동작하는지 확인해야 한다. AI는 실수를 한다. 종종 자신감 있게 틀린 코드를 만들기도 한다.

기술적 검증(테스트)과 방향적 검증(이게 맞는 기능인가)을 구분해야 한다.

기술적 검증: 코드가 명세대로 동작하는가. 이것은 테스트로 확인한다.

방향적 검증: 이 기능이 사용자의 실제 문제를 해결하는가. 이것은 사용자와의 접촉으로 확인한다.

AI가 만든 코드가 기술적으로 동작해도, 방향적으로 맞지 않을 수 있다. 기능이 동작한다는 것과 기능이 필요하다는 것은 다른 문제다.

기업에서 Agile은 무엇을 다시 검증해야 하는가

AI 도구가 팀에 들어왔다. 개발자가 Copilot을 쓰고, 기획자가 AI로 문서를 만들고, 팀장이 AI에게 보고서를 물어본다.

그러면 팀이 더 Agile해졌는가.

대부분의 경우, 그렇지 않다.

어느 팀에서 일어난 일을 예로 들면 이렇다. AI를 도입한 뒤 2주 Sprint 동안 기능 8개를 만들었다. 이전보다 두 배 가까운 속도였다. 경영진은 만족했다. 그런데 30일 뒤 리텐션 지표를 보니 아무것도 변하지 않았다. 8개의 기능 중 실제로 반복 사용된 것은 하나였고, 나머지는 사용자가 찾지 않았다. 속도가 올라간 것이지, 방향이 검증된 것이 아니었다.

AI 도입은 팀을 Agile하게 만들지 않는다

AI는 개인의 생산성을 높인다. 코드를 더 빠르게 만들고, 문서를 더 빠르게 쓴다.

하지만 Agile의 핵심은 팀이 방향을 검증하는 루프다. 이 루프는 개인의 생산성과 다른 문제다.

Sprint Review에서 실제 사용자의 피드백을 받는가. Retrospective에서 실제로 무언가가 바뀌는가. Product Owner가 가설을 명확히 쓰는가. 팀이 방향이 맞는지 자주 묻는가.

이것들은 AI가 빠르게 해주지 않는다. 오히려 AI가 구현 속도를 높이면, 방향 확인 없이 계속 달릴 수 있는 속도도 높아진다.

더 많은 티켓 처리량은 더 나은 제품을 의미하지 않는다

Jira 티켓이 빠르게 닫힌다. Velocity가 올라간다. Sprint마다 더 많은 Story Point가 완료된다.

그래서 제품이 더 나아지고 있는가.

이 두 가지가 연결된다는 보장이 없다. 빠르게 완료되는 작업이 사용자에게 가치를 주는 작업인지를 별도로 확인해야 한다.

AI가 들어온 뒤 티켓 처리 속도가 높아진 팀들이 있다. 그런데 리텐션은 그대로이거나 오히려 떨어진 경우가 있다. 더 많이 만들고 있지만 더 좋은 것을 만들고 있지 않다.

"완료된 티켓의 수"가 아니라 "사용자가 실제로 원하는 문제를 해결한 기능의 수"가 팀의 진짜 진척 지표다.

Product Owner의 역할은 더 중요해진다

AI가 구현 속도를 높였다는 것은 Product Owner의 질문이 더 중요해졌다는 것이다.

"이게 정말 필요한가?" "이 기능이 누구의 어떤 문제를 해결하는가?" "이걸 만드는 데 쓸 시간을 다른 데 쓰는 것이 더 낫지 않은가?"

Product Owner가 이 질문을 명확히 하지 않으면, 개발팀은 AI와 함께 매우 빠르게 많은 것을 만들 수 있다. 그 중 어떤 것이 실제로 필요한 것인지는 확인되지 않은 채.

AI 시대의 Product Owner는 기능 목록을 관리하는 사람이 아니다. 팀이 만들어야 할 것의 가설을 책임지는 사람이다. 그 가설이 명확하지 않으면, AI가 빠르게 만들어주는 것은 단지 빠른 낭비가 된다.

AI가 만든 산출물의 Definition of Done을 다시 써야 한다

AI가 코드를 만들었다. 그 코드가 "완료"인 기준은 무엇인가.

기존 Definition of Done은 이런 기준들을 포함했다.

코드 리뷰 통과
테스트 작성 완료
QA 통과
배포 가능 상태

AI 시대에는 이 기준에 새로운 항목이 필요하다.

이 코드를 팀이 설명할 수 있는가
이 기능이 어떤 사용자 문제를 해결하는지 한 문장으로 쓸 수 있는가
AI가 과하게 만든 부분(불필요한 복잡성, 쓰이지 않을 기능)은 없는가
이 기능을 관찰할 이벤트 로그나 지표가 있는가

AI는 요청한 것을 만들어준다. 그 요청이 실제로 필요한 것인지, 만든 것이 의도와 같은 방식으로 작동하는지 — 이것은 팀이 확인해야 한다.

Sprint Review는 데모가 아니라 방향 검증의 자리여야 한다

AI가 구현 속도를 높인 팀에서 Sprint Review는 더 많은 것을 보여줄 수 있는 자리가 됐다.

하지만 더 많은 것을 보여준다고 Sprint Review가 더 유효해지는 것이 아니다.

Sprint Review의 목적은 만든 것이 방향에 맞는지 확인하는 것이다. 실제 사용자나 고객이 참여해서 피드백을 주는 것이 이상적이다.

AI로 더 빠르게 만든 것들이 Sprint Review에서 실제 사용자의 검증을 받지 못하고 내부 박수만 받으면, 더 빠르게 방향을 잃는 것이 된다.

기업 Agile의 진짜 병목은 의사결정 속도다

AI가 구현 속도를 높이면, 팀의 다음 병목이 드러난다. 대부분의 기업에서 그 병목은 의사결정이다.

"이 기능을 만들어도 되는가"를 결정하는 데 얼마나 걸리는가. Product Owner가 방향을 바꾸는 결정을 하기까지 얼마나 걸리는가. Sprint Review에서 나온 피드백이 다음 Sprint에 반영되기까지 얼마나 걸리는가.

구현은 빨라졌는데 의사결정은 그대로라면, 팀은 결정을 기다리며 더 많은 시간을 낭비한다.

Agile의 "변화에 대응하기"는 의사결정이 빠를 때만 작동한다. AI가 구현 속도를 높인 것은 의사결정 속도도 함께 높아야 한다는 것을 더 명확하게 드러낸다.

1인 개발자와 Solo SaaS에서의 Agile

Agile은 대부분 팀을 전제로 설계됐다. Product Owner, Scrum Master, Development Team이 모두 다른 사람이어야 한다. Daily Standup은 팀이 동기화하기 위한 것이다. Sprint Review는 고객에게 보여주기 위한 것이다.

그렇다면 혼자 만드는 1인 개발자에게 Agile은 어떤 의미가 있는가.

혼자일 때 방향이 틀리기 더 쉽다

팀에서 일할 때는 자연스럽게 다른 사람들의 관점이 들어온다. 기획자가 "사용자가 이걸 원할까?"를 묻는다. 디자이너가 "이게 사용하기 어렵지 않을까?"를 묻는다. 다른 개발자가 코드 리뷰에서 "이 접근이 맞는가?"를 묻는다.

혼자 일하면 이 교차점이 없다. 내 생각만 있고, 내 판단이 바로 실행된다. 방향을 확인하는 마찰이 없다.

이것이 양날의 검이다. 빠르게 결정하고 실행할 수 있다. 하지만 방향이 틀렸을 때 발견하기 어렵다.

내가 만드는 것에 빠지는 문제

만드는 사람은 자기가 만든 것에 애착이 생긴다. 이 기능이 실제로 필요한지를 객관적으로 보기 어려워진다.

이것을 IKEA 효과라고 부르기도 한다. 직접 만든 것을 더 가치 있게 평가하는 경향이다.

혼자 일할 때 이 경향이 더 강해진다. 외부 관점을 가져다줄 사람이 없기 때문이다.

AI와 함께 일할 때 이 경향이 더 심해질 수 있다. AI가 내 요청을 빠르게 구현해주면, 내가 원하는 것이 더 빠르게 현실이 된다. 하지만 내가 원하는 것이 사용자가 필요한 것인지는 확인되지 않는다.

혼자서 방향을 확인하는 방법들

1인 개발자가 방향을 확인하는 데 쓸 수 있는 몇 가지 방법들이 있다.

조기 공개와 베타 사용자. 완성되기 전에 일부 사용자에게 보여준다. 폴리싱되지 않은 것을 보여주기가 불편할 수 있지만, 이른 피드백일수록 수정 비용이 싸다. Product Hunt, Reddit, 관련 커뮤니티, 트위터 등에 공유한다.

개인 사용자 인터뷰. 실제로 사용할 것 같은 사람들과 대화한다. 기능을 설명하지 않고, 그 사람들이 어떤 문제를 겪고 있는지 먼저 듣는다. "이 기능 어때요?"보다 "이 상황에서 지금 어떻게 하고 있어요?"가 더 유용한 정보를 준다.

로그와 분석. 실제로 어떤 기능이 쓰이는지, 어디서 이탈하는지 데이터로 본다. Posthog, Mixpanel, 또는 간단한 서버 로그라도 있으면 행동 데이터를 얻을 수 있다.

정기적인 자기 리뷰. 주 1회 또는 격주로 "지금 만드는 것이 맞는 방향인가"를 스스로 물어보는 시간을 만든다. 이 시간이 없으면 계속 달리다가 방향을 잃기 쉽다.

공개 빌드 로그. 트위터나 블로그에 만드는 것을 공개한다. "Build in Public"이라고 부른다. 공개하면 피드백을 받을 수 있고, 피드백을 받기 위해 더 명확하게 생각하게 된다.

가상의 고객과 대화. 자신이 타겟으로 하는 사용자를 구체적인 인물로 만든다. "30대, SaaS 회사 PM, 혼자 데이터를 분석해야 하는데 SQL을 잘 모르는 사람"처럼. 그 사람이 이 기능을 어떻게 쓸지 상상한다.

Solo SaaS에서 Agile 루프를 어떻게 돌리는가

팀이 있는 Scrum을 그대로 적용하기는 어렵다. 하지만 Agile의 핵심 루프 — 만들고 확인하고 수정하는 것 — 은 혼자서도 적용할 수 있다.

1인 개발자를 위한 간단한 Agile 루프를 생각하면 이렇다.

주간 목표 설정. 이번 주에 무엇을 만들 것인가. 구체적으로. "대시보드 개선"이 아니라 "사용자가 지난주 수익을 한눈에 볼 수 있는 위젯 추가". 목표가 구체적일수록 완료 여부를 판단하기 쉽다.

최소 기능으로 구현. 목표를 달성하는 가장 작은 버전을 만든다. 완성도보다 검증을 먼저. 아직 아무도 쓰지 않는 기능의 완성도에 시간을 쓰는 것보다, 실제로 쓰는지 확인하는 것이 먼저다.

실제 사용 확인. 만든 것을 실제 사용자가 쓰는지 본다. 쓴다면 어떻게 쓰는지. 안 쓴다면 왜 안 쓰는지.

주간 회고. 이번 주에 뭘 만들었고, 무엇을 배웠고, 다음 주에 무엇을 할 것인지. 10분이라도 이 시간을 갖는다.

이 루프가 돌아가면, 방향을 확인하는 주기가 생긴다. 한 달 만에 방향이 틀렸다는 것을 아는 것과, 1년 만에 아는 것은 수정 비용이 크게 다르다.

창업자에게 Agile은 사업 가설을 검증하는 방식이다

Solo SaaS, 1인 창업, AI로 만드는 첫 제품 — 이 맥락에서 Agile은 개발 방법론보다 더 넓은 의미가 있다.

이런 상황을 생각해보자. 1인 창업자가 AI를 써서 하루 만에 MVP를 만들었다. 프리랜서들이 청구서를 자동으로 생성하는 기능이었다. 기술적으로 잘 작동했다. 랜딩 페이지도 만들었다. 그런데 아무도 결제하지 않았다. 나중에 알고 보니 타겟 사용자들은 청구서 자체를 만드는 것이 문제가 아니었다. 고객에게 청구서를 보낸 뒤 결제를 받기까지 기다리는 것이 진짜 불편함이었다. 문제 가설부터 틀렸던 것이다. 기능을 만들기 전에 먼저 확인했어야 할 것이 있었다.

창업자에게 Agile의 핵심 루프는 이것이다.

가설을 세운다. 가장 빠르게 확인한다. 틀리면 다음 가설로 간다. 맞으면 더 깊이 판다.

기능 수준의 가설보다 앞선 가설들이 있다. 이것들을 먼저 확인하지 않으면 기능 가설 검증은 의미가 없다.

창업자가 순서대로 확인해야 하는 가설들

문제 가설: 이 사람들이 이 문제를 실제로 겪고 있는가?

가장 먼저 확인해야 한다. 내가 해결하려는 문제가 실제로 존재하는가.

"30대 프리랜서가 청구서를 보낼 때 불편함을 느낀다"는 가설이다. 이것을 확인하지 않으면 나머지 가설을 검증할 이유가 없다.

문제 가설 검증: 그 사람들과 이야기한다. "지금 이 과정이 어떠세요?"를 묻는다. "이런 도구가 있으면 쓰겠어요?"를 먼저 묻지 않는다. 솔루션을 꺼내기 전에 문제를 충분히 듣는 것이 먼저다.

고객 가설: 이 문제를 해결해줄 때 돈을 낼 사람이 있는가?

문제가 실재해도 돈을 낼 만큼 중요한 문제인지는 다른 질문이다. 불편하기는 해도 해결에 비용을 쓸 만큼 크지 않을 수 있다.

고객 가설 검증: 사전 결제를 받아본다. 인터뷰에서 "얼마면 쓰겠어요?"를 직접 묻는다. 사람들이 이미 이 문제를 해결하는 방식이 있고 그것에 돈을 내고 있다면, 고객 가설은 어느 정도 검증됐다.

채널 가설: 이 사람들에게 어떻게 닿을 수 있는가?

좋은 제품을 만들어도 필요한 사람에게 닿지 못하면 쓰이지 않는다.

채널 가설 검증: 타겟 사용자가 어디에 있는가. Reddit, 특정 Slack 커뮤니티, X(트위터), LinkedIn, 이메일 뉴스레터. 그 채널에서 얼마나 쉽게 닿을 수 있는가.

가격 가설: 얼마에 팔 수 있는가?

가격 결정을 나중으로 미루면 "공짜로 쓰다가 유료로 전환"이 얼마나 어려운지를 나중에 발견한다. 가격 가설은 일찍 검증해야 한다.

가격 가설 검증: 초기 사용자에게 일찍 결제를 요청한다. 사전 결제가 가장 강력한 검증이다. 무료로 쓴다고 해서 유료 전환을 원한다는 뜻이 아니다.

리텐션 가설: 한번 쓴 사람이 계속 쓰는가?

첫 사용자를 얻는 것보다 계속 쓰게 만드는 것이 더 어렵다. 리텐션이 없으면 사용자를 계속 새로 얻어야 하는데, 이것은 지속 가능하지 않다.

리텐션 가설 검증: 처음 쓴 사람이 일주일 뒤에도 쓰는가. 한 달 뒤에도 쓰는가. 리텐션이 낮으면 제품이 지속적인 가치를 만들지 못하고 있다는 신호다.

기능 가설: 이 기능이 이 문제를 실제로 해결하는가?

문제, 고객, 채널, 가격, 리텐션이 어느 정도 확인됐을 때, 비로소 기능 수준의 가설 검증이 의미가 있다. 앞선 가설들이 검증되지 않은 상태에서 기능을 세밀하게 완성하는 것은 방향이 없는 작업이다.

MVP는 작은 제품이 아니라 작은 증거다

MVP(Minimum Viable Product)를 "기능이 적은 제품"으로 이해하면, 잘못된 방향으로 작게 만들게 된다.

MVP의 목적은 배우는 것이다. 더 정확히는, 가설을 확인하기에 충분한 최소한이다.

가설이 "이 문제를 가진 사람들이 있고 그들이 돈을 낼 것이다"라면, 이 가설을 확인하는 MVP는 완성된 제품이 아닐 수 있다. 랜딩 페이지 하나일 수도 있다. 직접 손으로 처리하는 서비스일 수도 있다. 5명과의 인터뷰일 수도 있다.

MVP는 "작게 만들어라"가 아니라 "가설을 확인하는 데 필요한 최소한만 만들어라"다.

이 기준으로 보면, AI가 빠르게 MVP를 만들어준다는 것은 가설 검증 루프의 속도가 빨라진다는 것이다. 하지만 그 MVP가 어떤 가설을 확인하는 것인지가 먼저 명확해야 한다.

출시가 아니라 학습이 Sprint의 끝이다

창업자에게 Sprint의 끝은 "배포했다"가 아니다.

배포했다. 그래서 무엇을 배웠는가.

"배포했는데 아무도 안 썼다"도 학습이다. 왜 안 썼는가가 다음 질문이다.

"배포했는데 예상과 다르게 쓰는 사람이 있었다"도 학습이다. 그 사람이 어떻게 쓰는가가 다음 방향이 될 수 있다.

배포하고 다음으로 넘어가면 배울 기회를 잃는다. Sprint의 끝을 "이번에 무엇을 배웠는가"로 정의하면, 피드백 루프가 살아있다.

수익이 생기기 전과 후의 Agile은 다르다

수익이 없을 때 창업자의 Agile 루프는 학습을 최대화하는 것이다. 빠르게 가설을 세우고, 빠르게 확인하고, 틀리면 빠르게 다음으로 간다. 이 단계에서는 "무엇을 만들어야 하는가"를 찾는 것이 목적이다.

수익이 생기기 시작하면 Agile 루프가 바뀐다. 어떤 것이 수익을 만드는지가 더 중요해진다. 리텐션이 왜 생기는지, 이탈이 왜 일어나는지가 핵심 질문이 된다. 이 단계에서는 "어떻게 더 잘 해결할 것인가"를 파고든다.

같은 Agile 루프지만 질문의 무게가 달라진다.

1인 SaaS의 주간 Agile 루프

팀 Scrum을 그대로 가져다 쓸 필요는 없다. 혼자서도 방향을 검증하는 루프를 돌릴 수 있다.

월요일: 이번 주 하나의 가설 이번 주에 확인하고 싶은 것 하나를 정한다. 기능 수준의 가설일 수도 있고, 사용자 행동에 대한 가설일 수도 있다. 하나여야 한다. 여러 개면 어느 것이 무엇을 만들었는지 알 수 없다.

주중: 가설을 확인할 수 있는 최소 구현 가설을 확인하기에 충분한 가장 작은 것을 만든다. AI가 이 부분을 빠르게 해준다.

금요일: 이번 주 배운 것 배포했거나 사용자에게 보여줬다면, 무엇을 배웠는가. 가설이 맞았는가, 틀렸는가. 다음 주 가설은 무엇인가.

이 루프가 습관이 되면, 방향 없이 계속 만들기만 하는 패턴을 막는다.

AI가 만든 결과를 Agile하게 검증하는 기준

AI로 기능을 만들었다. 이제 무엇을 확인해야 하는가.

기술적 검증과 방향적 검증을 구분해서 생각하는 것이 도움이 된다.

기술적 검증은 "제대로 동작하는가"다. 테스트, 버그 확인, 엣지 케이스 처리.

방향적 검증은 "맞는 것을 만들었는가"다. 이것이 더 어렵고 더 중요하다.

방향 검증을 위한 질문들

이 기능은 누구의 문제를 해결하는가?

특정한 사람이 반복해서 겪는 불편함을 해결하는가. 아니면 내가 만들어보고 싶어서 만든 기능인가.

"이 기능이 있으면 편할 것 같다"는 내 가정이다. "이 기능이 없어서 매번 이렇게 해왔다"는 사용자의 실제 문제다. 둘은 다르다.

기능을 만들기 전에 이 질문에 답할 수 있어야 한다. 답이 모호하면 방향이 모호한 것이다.

사용자가 실제로 반복해서 겪는 문제인가?

한 번 불편했던 것을 해결하는 기능은 한 번 쓰인다. 계속 불편한 것을 해결하는 기능은 계속 쓰인다.

사용자가 이 문제를 얼마나 자주 겪는지, 얼마나 심각하게 생각하는지를 확인해야 한다. 인터뷰에서 "네, 그런 문제 있죠"라는 답과 "그게 제일 힘들어요, 매번 이렇게 해야 하는데"라는 답은 다른 무게를 가진다.

AI가 만든 구현은 문제를 해결했는가, 기능만 늘렸는가?

기능이 추가됐다. 그래서 사용자의 문제가 줄었는가.

이 두 가지가 일치하지 않는 경우가 있다. 기능이 있어도 사용자가 원래 하던 방식으로 같은 문제를 겪고 있다면, 기능이 문제를 해결하지 못한 것이다.

기능을 배포한 후 "사용자가 이 기능을 써서 원래 문제를 해결했는가"를 확인해야 한다. 기능 사용률이 아니라 문제 해결 여부가 기준이다.

지금 필요한 것은 기능 추가인가, 관찰인가?

다음에 만들 것이 보인다. 하지만 현재 기능이 어떻게 사용되는지 아직 보지 않았다.

기능을 배포한 뒤 바로 다음 기능으로 넘어가면 현재 기능으로 무엇을 배울 기회를 잃는다. 어떤 사용자가 어떻게 쓰는지, 어디서 막히는지, 예상과 다르게 사용하는 부분이 있는지.

때로는 만드는 것을 멈추고 관찰하는 것이 더 중요하다.

이번 변경으로 무엇을 배웠는가?

기능을 배포하고 한 주가 지났다. 이번에 무엇을 배웠는가.

"배운 것 없이 다음으로 넘어간다"는 피드백 루프가 작동하지 않은 것이다. 피드백 루프의 목적이 배움이기 때문이다.

배움은 거창할 필요가 없다. "생각보다 이 버튼을 많이 눌렀다"도 배움이다. "이 기능을 아무도 안 썼다"도 배움이다. "예상하지 못했던 방식으로 쓰는 사람이 있었다"도 배움이다.

이것들이 다음 질문을 만든다.

다음 행동은 추측인가, 검증인가?

다음 기능을 정했다. 그 결정이 어디서 나왔는가.

"이게 좋을 것 같다"는 추측이다. "데이터에서 이 패턴이 보였고, 이것은 이 문제를 시사한다"는 검증에서 나온 판단이다.

추측이 나쁜 것은 아니다. 데이터가 없을 때는 추측에서 시작할 수밖에 없다. 하지만 추측인 것을 알고 있어야 한다. 추측을 확신으로 포장하면 검증하려는 동기가 줄어든다.

"나는 이것이 맞을 것이라고 추측한다. 이번 Sprint에서 이 추측을 확인해보자"가 건강한 태도다.

기능 검증을 위한 실용적 방법들

A/B 테스트. 같은 기능의 다른 버전을 나눠서 보여준다. 어느 쪽이 더 좋은 결과를 내는지 데이터로 확인한다. 트래픽이 충분해야 유의미한 결과가 나온다.

Feature Flag. 기능을 일부 사용자에게만 먼저 활성화한다. 전체 배포 전에 소수 사용자의 반응을 본다. 문제가 있으면 빠르게 끄고 수정한다.

직접 관찰. 사용자가 기능을 쓰는 것을 직접 본다. 화면 녹화 도구(Hotjar, FullStory 등)를 쓰거나, 실제 사용자와 화면을 공유해서 쓰는 것을 보여달라고 한다.

출시 후 인터뷰. 기능을 배포한 뒤 사용자에게 연락한다. 써봤는지, 어떤 경험이었는지 물어본다.

지표 모니터링. 관련 지표가 기능 배포 후 어떻게 변했는지 본다. 어떤 지표를 볼 것인지를 배포 전에 미리 정해두는 것이 좋다.

개인 개발자를 위한 AI 산출물 검증 체크리스트

배포 전에 이 질문들에 답할 수 있어야 한다. 답하기 어려운 질문이 있으면, 그것이 확인되지 않은 가정이다.

기능의 이유

이 기능이 해결하는 사용자 문제를 한 문장으로 말할 수 있는가?
이 기능이 없어도 사용자가 이미 해결하고 있는 방식은 무엇인가?
이 기능을 요청한 사람이 있는가, 아니면 내가 만들고 싶어서 만든 것인가?

AI가 만든 코드의 책임

이 코드가 어떻게 작동하는지 내가 설명할 수 있는가?
AI가 과하게 만든 부분(쓰이지 않을 기능, 불필요한 복잡성)은 없는가?
구현은 됐지만 실제 사용자 흐름에 맞지 않는 부분은 없는가?

배포 후 관찰 설계

이 기능의 사용 여부를 어떻게 알 수 있는가? (이벤트 로그, 지표)
기능이 예상대로 쓰이지 않을 때 알 수 있는 방법이 있는가?
이번 배포로 무엇을 배울 예정인가? (배포 전에 미리 정해두는 것이 좋다)

팀이 AI 산출물을 Agile하게 검토하는 기준

팀 단위에서 AI가 만든 결과를 검토할 때 쓸 수 있는 기준이다.

Sprint 시작 전

Product Owner가 이 기능의 가설을 명확히 썼는가? ("이 기능을 추가하면 이런 결과가 나올 것이다")
이번 Sprint의 목표가 기능 완료인가, 가설 검증인가?
검증 기준을 미리 정했는가?

PR 리뷰에서

코드 스타일뿐 아니라 의도가 코드에 담겨 있는가?
AI가 만든 코드의 경우, 작성자가 코드의 의도를 설명할 수 있는가?
테스트가 기능의 의도를 검증하는가, 단지 코드가 실행되는지만 확인하는가?

Sprint Review에서

실제 사용자나 고객이 참여했는가?
"잘 만들었다"는 내부 평가보다, "사용자가 이것으로 문제를 해결했다"는 증거가 있는가?
AI로 빠르게 만든 것들 중 아직 검증되지 않은 것이 있는가?

배포 후

기능 배포 후 관련 지표(사용률, 리텐션, 오류율)를 보고 있는가?
다음 Sprint에 이번 배포에서 배운 것이 반영되는가?

작은 Agile 루프: 질문 → 가설 → 구현 → 관찰 → 수정

질문에서 시작해서 수정으로 닫히는 Agile 루프. AI는 구현을 가속하지만, 질문과 가설은 사람이 검증한다

Agile의 핵심 메커니즘은 이 루프다. 팀 규모에 관계없이, Scrum을 쓰든 Kanban을 쓰든, 이 루프가 작동해야 Agile하다.

질문

어떤 사용자가, 어떤 상황에서, 어떤 문제를 겪고 있는가.

좋은 질문일수록 구체적이다. "사용자가 이 부분에서 불편해한다"보다 "30대 프리랜서 디자이너가 클라이언트에게 청구서를 보낼 때 세금 계산을 매번 수동으로 해야 해서 실수가 난다"가 더 좋은 질문이다.

질문이 구체적이어야 가설이 구체적이고, 가설이 구체적이어야 검증할 수 있다.

질문을 모른다면 먼저 탐색이 필요하다. 사용자와 이야기하고, 데이터를 보고, 비슷한 제품의 리뷰를 읽는다. 이 탐색 단계에서는 Agile 루프를 돌리는 것보다 정보를 모으는 것이 먼저다.

가설

이 문제를 이 방식으로 해결하면 이런 결과가 나올 것이다.

가설은 예측이다. "청구서 세금 자동 계산 기능을 추가하면, 청구서 작성 시간이 줄고 오류가 줄 것이다"처럼.

가설을 쓸 때 검증 가능한 형태로 쓰는 것이 중요하다. "사용자가 더 만족할 것이다"는 측정하기 어렵다. "청구서 작성에 걸리는 시간이 20% 줄 것이다"는 측정할 수 있다.

가설에는 "만약 맞지 않다면?"도 있어야 한다. 가설이 틀렸을 때 어떻게 알 수 있는가. 이것이 검증의 기준이다.

구현

가설을 확인할 수 있는 가장 작은 버전을 만든다.

Minimum Viable Product(MVP)의 개념이 여기서 나온다. 가장 작고, 가장 단순하고, 가설을 확인할 수 있는 것. 완성도보다 검증을 먼저.

이 단계에서 AI가 크게 도움이 된다. 가설을 확인할 최소 기능을 빠르게 구현하는 것.

주의할 것은, AI가 만드는 것이 "가설을 확인할 수 있는 것"이어야 한다는 것이다. AI에게 "세금 자동 계산 기능 전부 만들어줘"가 아니라 "사용자가 세율을 입력하면 세금이 자동으로 계산되는 기본 기능"부터 만드는 것이다.

관찰

만든 것이 실제로 어떻게 쓰이는지 본다.

가설에서 정한 검증 기준으로 본다. "청구서 작성 시간이 줄었는가?" 이것을 어떻게 측정할 것인가를 배포 전에 정해두는 것이 좋다.

관찰은 열린 마음으로 해야 한다. "이렇게 쓰겠지"라는 기대로 보면 예상과 다른 것을 놓친다. 예상과 다른 것이 오히려 중요한 정보일 때가 많다.

사용자가 기능을 예상과 다르게 쓴다면, 왜 그런지를 이해하는 것이 다음 질문이 된다.

수정

관찰한 것을 바탕으로 다음 질문을 다시 정한다.

수정은 기능을 고치는 것일 수도 있고, 방향 자체를 바꾸는 것일 수도 있고, 이 기능을 포기하는 것일 수도 있다.

포기하는 것도 유효한 수정이다. 가설이 틀렸다는 것을 발견했다면, 그 방향을 계속 붙잡는 것보다 포기하고 다른 가설을 세우는 것이 맞다. 이것이 Agile이 틀린 방향을 오래 붙잡지 않기 위한 것이라는 의미다.

Agile의 자주 하는 실수들

Agile을 알고 있지만 제대로 안 되고 있다면, 보통 이런 실수들 중 하나 이상이 있다.

의식이 되어버린 Agile

Daily Standup을 한다. Sprint를 돌린다. Retrospective를 한다. 하지만 이것들이 의미 없는 의식처럼 느껴진다.

이 증상의 원인은 대부분 "왜 이것을 하는가"를 잊어버렸기 때문이다.

Daily Standup의 목적은 팀이 장애물을 인식하고 서로 돕는 것이다. 그것 없이 세 가지 질문만 답하고 끝나면 의식이다.

Retrospective의 목적은 팀이 실제로 바뀌는 것이다. 같은 불만을 반복하고 아무것도 바뀌지 않으면 의식이다.

의식이 됐다는 신호: 이 미팅이 없으면 어떻게 될까 생각했을 때 별 상관없다는 생각이 드는 것.

Backlog가 무덤이 되는 문제

Backlog에 아이템이 쌓인다. 수십 개, 수백 개. 위에서 몇 개만 계속 작업하고 나머지는 언젠가 보자고 한다.

언젠가는 오지 않는다. Backlog 아래쪽 아이템들은 사실상 "하지 않겠다"는 것과 같다.

해결책은 Backlog를 정기적으로 정리하는 것이다(Backlog Grooming 또는 Backlog Refinement). 더 이상 필요 없는 아이템은 삭제한다. 우선순위를 재정렬한다.

건강한 Backlog는 짧다. 정말 할 것들만 있다.

Velocity를 목표로 삼는 문제

팀의 Sprint Velocity를 높여야 한다는 압박이 생기면 문제가 시작된다.

Velocity는 팀의 생산성을 측정하기 위한 도구가 아니다. 미래를 예측하기 위한 도구다.

Velocity를 높이라고 압박하면 팀은 Story Point 추정을 부풀리기 시작한다. 같은 작업을 3 Story Point로 추정하던 것을 5로 추정한다. Velocity는 높아졌지만 실제로 더 많이 한 것은 아니다.

더 심각한 경우는 Velocity를 높이기 위해 품질을 타협하는 것이다. 테스트를 줄이고, 리뷰를 서두르고, 기술 부채를 쌓는다.

Velocity는 팀 내부에서만 의미 있는 상대적인 숫자다. 팀 간 비교, 팀에 대한 압박 도구로 쓰이면 왜곡이 일어난다.

사용자 없는 Sprint Review

Sprint Review에서 완성된 것을 보여준다. 하지만 보여주는 대상이 내부 이해관계자, 경영진, 팀장들이다.

Agile에서 Sprint Review의 목적은 실제 고객, 실제 사용자로부터 피드백을 받는 것이다. 내부 사람들의 피드백도 가치 있지만, 그것만으로는 방향 검증이 되지 않는다.

사용자를 Sprint Review에 참여시키기 어렵다면, 사용자 인터뷰를 Sprint 중에 별도로 하거나, 배포 후 실사용 데이터로 피드백을 받는 방법을 찾아야 한다.

완료됐지만 안 쓰이는 기능들

"완료"된 기능들이 실제로 사용자에게 가닿지 않는 경우가 있다.

배포했지만 아무도 그 기능의 존재를 모른다. 기능은 있지만 UX가 너무 어렵다. 기능은 있지만 실제 사용자 흐름과 맞지 않는 곳에 있다.

"완료"의 정의에 "실제로 사용자가 쓸 수 있는 상태"가 포함되어야 한다. 코드가 병합됐다고 완료가 아니라, 사용자가 실제로 접근해서 쓸 수 있어야 완료다.

Retrospective에서 아무것도 안 바뀌는 문제

Retrospective에서 같은 문제가 반복해서 나온다. "소통이 부족하다", "요구사항이 명확하지 않다", "테스트할 시간이 부족하다".

나왔는데 왜 아무것도 안 바뀌는가.

Action Item이 없기 때문이다. "더 잘 소통해보자"가 아니라, "다음 Sprint부터 Sprint Review에 Product Owner가 참석한다"처럼 구체적인 행동이 있어야 한다.

그리고 이전 Retrospective의 Action Item을 다음 Retrospective에서 확인해야 한다. "지난번에 이렇게 하기로 했는데, 됐는가?"

이 확인이 없으면 Retrospective는 불만을 토로하는 자리가 된다.

Agile을 도구로 쓰는 문제

Jira, Trello, Linear 등 Agile 관련 도구들이 많다.

도구가 프로세스를 결정하기 시작하면 문제가 생긴다. Jira가 있으니까 Epic을 만들고 Story를 만들고 Sub-task를 만들어야 한다. Jira가 원하는 방식대로 팀이 일한다.

도구는 프로세스를 지원해야 한다. 프로세스가 도구를 따라가면 안 된다. 팀에 맞는 프로세스를 먼저 정하고, 그 프로세스를 지원하는 도구를 고르거나 맞게 설정해야 한다.

Agile의 한계

Agile이 모든 상황에 맞는 것은 아니다. 이것을 인식하는 것이 중요하다.

명확한 방향이 있을 때

방향이 이미 명확하고, 남은 것이 실행뿐이라면 Agile 루프의 이점이 줄어든다.

예를 들어, 잘 정의된 규제 요구사항을 구현하는 것. 요구사항이 명확하고 변하지 않는다. 여기서 "방향이 맞는지" 자주 확인하는 것은 오버헤드다.

Agile이 효과적인 것은 불확실성이 높을 때다. 무엇을 만들어야 하는지 모를 때, 사용자가 무엇을 원하는지 확인이 필요할 때.

하드웨어와 물리적 제품

소프트웨어는 빠르게 변경하고 배포할 수 있다. 하드웨어는 그렇지 않다.

반도체를 설계하고 양산하는 것은 Agile하게 하기 어렵다. 설계가 끝나면 수개월이 지나야 실제 칩이 나온다. 그 사이에 방향을 바꾸는 비용이 엄청나다.

하드웨어 제품에서 Agile을 적용할 수 있는 부분은 주로 소프트웨어 부분이나 프로토타이핑 단계다. 양산 단계에서 Agile은 맞지 않는다.

규제가 강한 산업

의료 기기, 항공, 금융 규제 소프트웨어 등에서는 변경의 자유가 제한된다.

기능을 변경하면 새로운 규제 승인이 필요하다. 이 프로세스가 수개월 걸린다. Sprint마다 변경하고 배포하는 것이 현실적으로 불가능하다.

이 분야에서 Agile을 적용할 수 있는 부분은 제한적이다. 규제 요구사항이 확정되기 전 탐색 단계, 내부 도구, 규제 대상이 아닌 부분에 적용할 수 있다.

대규모 인프라 변경

데이터베이스 마이그레이션, 아키텍처 전환, 레거시 시스템 교체 같은 작업은 Agile하게 하기 어렵다.

이 작업들은 중간 상태가 종종 더 나쁘다. 절반만 마이그레이션된 데이터베이스는 원래 시스템보다 더 복잡하다. 이런 작업은 계획을 세우고 완전히 실행하는 것이 더 나을 수 있다.

물론 큰 변경을 작은 단계로 나누는 것은 가능하다. 하지만 각 단계가 독립적으로 가치를 제공하고 배포 가능해야 한다. 그게 안 된다면 Agile하게 접근하기 어렵다.

"Agile"이 회사 정치의 도구가 될 때

"Agile하게 하자"가 "일정을 바꾸자", "요구사항을 유동적으로 유지하자", "책임을 불명확하게 하자"의 완곡한 표현이 되는 경우가 있다.

Agile이 요구사항 변경을 환영하는 것은 맞다. 하지만 그것은 고객의 진짜 필요가 바뀔 때, 더 좋은 방향을 찾았을 때를 말한다. 내부 이해관계자가 계속 생각을 바꾸는 것을 수용하기 위한 변명이 아니다.

Agile의 이름 아래 팀이 끝없이 방향을 바꾸면, 팀은 지치고 아무것도 완성되지 않는다.

Agile이 팀에 맞지 않을 때

Agile은 특정한 팀 문화와 맞을 때 잘 작동한다. 자기 조직적이고, 서로 신뢰하고, 피드백을 편하게 주고받을 수 있는 팀.

이것이 없는 상태에서 Agile 프로세스만 강요하면 오히려 나쁘다. 매일 하는 Standup이 감시 도구가 되고, Retrospective가 비난의 장이 된다.

프로세스보다 문화가 먼저다. Agile한 문화가 없는 곳에 Agile 프로세스를 강요하면 형식만 남는다.

인접 방법론과의 비교

Agile은 혼자 존재하지 않는다. 비슷한 목적이나 보완적인 역할을 하는 다른 방법론들이 있다. 이것들과 Agile의 관계를 이해하면 언제 무엇을 쓸지 더 잘 판단할 수 있다.

Lean

Lean은 Toyota Production System에서 나왔다. Agile보다 먼저 있었고, Agile에 큰 영향을 줬다.

Lean의 핵심은 낭비 제거다. 가치를 만들지 않는 모든 것이 낭비다. 불필요한 재고, 기다림, 불필요한 이동, 결함, 과잉 생산.

소프트웨어에서 Lean을 적용하면: 완성되지 않은 작업(WIP), 불필요한 기능, 기다리는 시간, 재작업 등이 낭비다.

Lean Startup은 Eric Ries가 Lean 원칙을 스타트업 맥락에 적용한 것이다. Build-Measure-Learn 루프가 핵심이다. Agile의 루프와 매우 비슷하다.

Lean은 "낭비를 없애자"는 관점, Agile은 "빠르게 피드백을 얻자"는 관점이다. 실제로는 많이 겹친다.

Shape Up (Basecamp)

Basecamp(현 37signals)에서 만든 방법론이다. Scrum에 대한 명시적인 비판에서 나왔다.

Shape Up의 핵심은 고정 시간, 가변 범위다. Scrum에서는 보통 Sprint 기간이 고정되고 완료 범위가 가변적이다(일정이 밀리면 기능이 줄거나 시간이 늘어난다). Shape Up에서는 시간을 고정하고 그 시간 안에 맞는 솔루션을 찾는다.

6주 사이클을 쓴다. 6주 안에 한 가지 중요한 문제를 해결한다. 6주 후에 반드시 배포할 수 있는 상태여야 한다.

"Appetite"라는 개념을 쓴다. "이 문제를 해결하는 데 최대 6주를 쓸 의향이 있는가"를 먼저 결정한다. 6주보다 작은 것은 Small Batch로 2주 사이클로 처리한다.

Scrum은 팀이 무엇을 할지 계획한다. Shape Up은 시간을 베팅한다.

Agile과의 차이: Shape Up은 Backlog를 쓰지 않는다(Backlog가 무덤이 된다는 비판). 매 사이클마다 무엇을 할지 새로 결정한다. 이전 사이클에서 하지 않은 것은 자동으로 사라진다.

OKR

OKR(Objectives and Key Results)는 인텔에서 시작해서 Google이 대중화한 목표 설정 방법이다.

Objective: 달성하고 싶은 것. 방향. 정성적이어도 된다. Key Results: Objective 달성 여부를 측정하는 지표. 정량적이어야 한다.

OKR은 방향을 설정하는 도구다. Agile은 방향을 향해 가는 방법이다. 이 두 가지는 상호 보완적이다.

OKR로 "이번 분기에 우리가 가야 할 방향"을 정하고, Agile로 그 방향을 향해 Sprint마다 가설을 세우고 검증한다.

OKR 없이 Agile만 있으면 단기 목표는 있지만 전략적 방향이 없을 수 있다. Agile 없이 OKR만 있으면 큰 방향은 있지만 실행 수준의 피드백 루프가 없다.

Design Thinking

Design Thinking은 사용자 중심 문제 해결 방법이다. 공감, 문제 정의, 아이디어 발산, 프로토타입, 테스트의 단계를 거친다.

Agile과의 관계: Design Thinking은 보통 개발 이전 단계다. 무엇을 만들어야 하는지를 발견하는 단계. Agile은 발견한 것을 개발하는 단계.

"Double Diamond"라는 모델이 이것을 잘 보여준다. 첫 번째 다이아몬드에서 문제를 발견하고 좁힌다(Design Thinking). 두 번째 다이아몬드에서 해결책을 발견하고 좁힌다(Agile).

두 방법론을 함께 쓰면 "무엇을 만들어야 하는가"와 "어떻게 만들 것인가" 모두 잘 처리할 수 있다.

Six Sigma

Six Sigma는 품질 관리 방법론이다. 프로세스의 결함을 통계적으로 측정하고 줄이는 것이 목적이다.

DMAIC(Define, Measure, Analyze, Improve, Control) 프로세스를 사용한다.

Agile과의 차이: Six Sigma는 기존 프로세스를 개선하는 데 맞다. 반복적이고 측정 가능한 프로세스가 있어야 한다. Agile은 새로운 것을 탐색하고 만드는 데 맞다. 반복적인 프로세스가 없어도 된다.

제조 프로세스 최적화에는 Six Sigma가 맞다. 새 기능 개발에는 Agile이 맞다.

Agile 지표: 무엇을 보고 판단하는가

Agile에서 쓰이는 지표들과 그 의미, 그리고 함정을 알아야 제대로 쓸 수 있다.

Velocity

Sprint마다 완료되는 Story Point의 양이다.

용도: 예측. "팀이 평균 40 Story Point를 완료한다면, 200 Story Point짜리 프로젝트는 대략 5 Sprint가 걸린다."

함정: 목표로 삼는 것. "이번 Sprint에 50 Story Point를 완료해야 한다"는 Velocity를 왜곡한다. Story Point 추정이 부풀어지거나 품질이 타협된다.

Velocity는 팀이 자신의 용량을 파악하기 위한 도구다. 외부에서 팀을 평가하는 도구로 쓰이면 안 된다.

Velocity는 팀마다 다르다. A팀의 Velocity 50과 B팀의 Velocity 50은 비교할 수 없다. Story Point 추정 기준이 다르기 때문이다.

Cycle Time

작업을 시작한 시점부터 완료된 시점까지의 시간이다.

Kanban에서 자주 쓴다. "이 작업 유형의 평균 Cycle Time이 3일이다"처럼.

Cycle Time이 짧을수록 빠르게 배포할 수 있다. Cycle Time을 줄이려면 WIP를 줄이거나 병목을 찾아야 한다.

함정: Cycle Time을 줄이기 위해 작업을 인위적으로 작게 쪼개면 실제 가치 없는 작은 작업들이 늘어난다.

Lead Time

요청이 들어온 시점부터 완료된 시점까지의 시간이다.

Cycle Time이 작업 시작 후의 시간이라면, Lead Time은 요청부터다. 요청이 들어오고 작업이 시작되기까지의 대기 시간이 포함된다.

사용자 관점에서 더 의미 있는 지표다. 사용자가 기능을 요청하고 실제로 쓸 수 있기까지 얼마나 걸리는지.

Sprint Burndown Chart

Sprint가 진행되면서 남은 작업이 얼마나 줄어드는지를 시각화한다.

이상적인 Burndown은 직선으로 내려간다. 매일 일정하게 작업이 완료된다.

현실에서는 처음에 느리다가 Sprint 끝에 급격히 줄어드는 패턴이 많다. 이것은 작업이 Sprint 말에 몰린다는 신호다.

Burndown이 Sprint 말에도 0으로 내려오지 않으면, Sprint 목표를 달성하지 못한 것이다.

함정: Burndown을 좋게 보이기 위해 완료되지 않은 작업을 완료로 표시하거나, Sprint 목표를 낮추는 것.

Cumulative Flow Diagram (CFD)

시간에 따라 각 상태(To Do, In Progress, Done 등)에 있는 작업의 수를 보여준다. Kanban에서 자주 쓴다.

CFD를 보면 흐름이 보인다. 특정 상태에서 작업이 쌓이면 그곳이 병목이다. 작업들이 빠르게 Done으로 이동하면 흐름이 좋은 것이다.

NPS (Net Promoter Score)

"이 제품을 다른 사람에게 추천하겠는가?"를 0~~10으로 묻는다. 9~~10은 Promoter, 7~~8은 Passive, 0~~6은 Detractor. NPS = Promoter 비율 - Detractor 비율.

-100~100 사이의 값이 나온다. 일반적으로 높은 NPS는 긍정적인 신호로 해석되지만, 기준은 업종과 제품 단계에 따라 달라진다.

Agile에서 NPS를 Sprint Review의 지표로 쓸 수 있다. Sprint마다 NPS를 측정하면 사용자 만족도의 트렌드를 볼 수 있다.

함정: NPS는 총체적인 지표라 어떤 부분이 좋고 나쁜지를 말해주지 않는다. 변화의 원인을 찾으려면 추가 분석이 필요하다.

1인 개발자가 실제로 볼 수 있는 지표들

거대 조직의 지표 체계를 1인 개발자가 다 쓸 필요는 없다. 현실적으로 볼 수 있는 지표들이 있다.

활성 사용자 수. DAU(일간 활성 사용자), WAU(주간 활성 사용자), MAU(월간 활성 사용자). 절대값보다 트렌드가 중요하다.

리텐션. 처음 쓴 사용자가 다시 돌아오는 비율. 리텐션이 낮으면 제품이 계속 쓸 이유를 만들지 못하고 있다는 신호다.

특정 기능 사용 여부. 새로 만든 기능을 실제로 쓰는 사람이 있는가. 없다면 왜 없는지.

지원 요청 패턴. 같은 질문이 자주 들어온다면 UX 문제가 있을 수 있다. 또는 기능을 찾지 못하거나 이해하지 못하는 것.

수익. SaaS라면 MRR(월 반복 수익)과 Churn Rate(이탈률). 이탈률이 높으면 제품이 계속 가치를 제공하지 못하는 것.

Dechive Note

Agile 지표는 사람을 평가하기 위한 숫자가 아니다. 방향과 흐름을 관찰하기 위한 신호다. Velocity는 팀을 압박하는 도구가 아니라 예측을 돕는 기준이고, Cycle Time과 Lead Time은 사용자가 가치를 받기까지의 흐름을 보여준다. 지표가 목표가 되는 순간, 팀은 제품이 아니라 숫자를 최적화하기 시작한다 — Goodhart's Law가 Agile 지표에도 그대로 적용된다.

Agile에서 흔히 혼동하는 개념들

Agile 관련 용어들 중 자주 혼동되거나 잘못 이해되는 것들이 있다.

MVP (Minimum Viable Product)

가장 자주 잘못 이해되는 개념 중 하나다.

MVP를 "최소한의 기능을 가진 제품"으로 이해하면, 결과적으로 버그가 많고 기능이 부족한 제품을 만들게 된다.

MVP의 진짜 의미는 "가설을 검증할 수 있는 최소한의 것"이다. 가설이 "이런 문제를 이 방식으로 해결하면 사용자가 쓸 것이다"라면, 그 가설을 확인하는 데 필요한 최소한을 만드는 것이다.

그래서 MVP는 제품이 아닐 수도 있다. 사용자 인터뷰, 랜딩 페이지, 수동으로 처리하는 서비스도 가설을 확인하는 MVP가 될 수 있다.

MVP의 목적은 "배우는 것"이다. 배울 수 있는 최소한을 빠르게 만드는 것.

Sprint와 Iteration

많은 사람이 두 단어를 같은 의미로 쓴다. 엄밀하게는 다르다.

Sprint는 Scrum에서 쓰는 고정 시간 주기다. 보통 1~4주.

Iteration은 더 일반적인 개념이다. 한 사이클 또는 반복. XP에서는 Iteration을 쓴다.

맥락에 따라 같은 의미로 쓰이기도 하지만, Scrum 맥락에서는 Sprint를 쓰는 것이 정확하다.

Scrum Master와 프로젝트 매니저

Scrum Master는 팀이 Scrum을 제대로 이해하고 실행하도록 돕는 역할이다. 팀에게 일을 시키거나 진행을 추적하는 것이 아니다.

프로젝트 매니저는 전통적으로 일정, 예산, 리소스를 관리한다. 팀을 조율하고 이해관계자와 소통한다.

둘은 다른 역할이다. Scrum Master를 프로젝트 매니저처럼 쓰면 안 된다. 하지만 많은 조직에서 기존 프로젝트 매니저에게 Scrum Master 역할을 주면서 혼동이 생긴다.

Product Owner와 프로덕트 매니저

Scrum에서 Product Owner는 Product Backlog를 관리하고 우선순위를 결정한다.

프로덕트 매니저(PM)는 더 넓은 역할이다. 시장 분석, 사용자 연구, 전략 수립, 이해관계자 관리 등을 담당한다.

Product Owner는 Scrum 내의 역할이고, PM은 조직 내의 직함이다. 한 사람이 둘 다 할 수 있고, 다른 사람이 할 수도 있다.

Done의 의미

"완료"의 정의가 팀마다 다르다. 이것을 명확히 하지 않으면 나중에 문제가 생긴다.

코드 작성 완료? 테스트 작성 완료? 코드 리뷰 통과? QA 통과? 스테이징 배포? 프로덕션 배포?

팀이 명시적으로 합의한 Definition of Done이 필요하다. 이것이 없으면 "내가 생각하는 완료"와 "너가 생각하는 완료"가 달라서 혼란이 생긴다.

Agile과 기술적 실천들

Agile은 프로세스만이 아니다. 기술적 실천들이 함께 가야 Agile이 지속 가능하다.

기술 부채와 Agile

빠르게 반복하면 기술 부채가 쌓이기 쉽다. 빠르게 만들기 위해 코드 품질을 타협하면 나중에 속도가 느려진다.

Agile의 12원칙 중 하나가 "지속적인 기술 탁월성과 좋은 설계에 대한 관심이 Agility를 높인다"다.

기술 부채는 Agile의 적이다. 기술 부채가 쌓이면 새 기능을 추가하기 어려워지고, 버그가 늘고, 팀의 속도가 줄어든다.

Agile에서 기술 부채를 관리하는 방법 중 하나는 Backlog에 기술 부채 항목을 포함하는 것이다. "이 부분을 리팩토링해야 한다"를 Product Backlog에 넣고 우선순위를 매긴다.

또 다른 방법은 팀이 Sprint마다 일정 비율의 시간을 기술 부채 해소에 쓰기로 합의하는 것이다.

자동화 테스트

Agile에서 빠르게 배포하려면 자동화 테스트가 있어야 한다.

새 기능을 추가할 때 기존 기능이 망가지지 않았는지 확인해야 한다. 이것을 수동으로 매번 하면 너무 오래 걸린다.

자동화된 테스트 스위트가 있으면 코드 변경 후 테스트를 실행해서 빠르게 확인할 수 있다.

AI 시대에도 이것은 중요하다. AI가 코드를 만들면 그 코드가 기존 기능을 망가뜨리지 않는지 확인해야 한다. 자동화 테스트가 이것을 빠르게 해준다.

지속적인 통합과 배포 (CI/CD)

CI(Continuous Integration)는 코드를 자주 통합하는 것이다. CD(Continuous Delivery 또는 Continuous Deployment)는 언제든 배포 가능한 상태를 유지하는 것, 또는 자동으로 배포하는 것이다.

CI/CD 파이프라인이 있으면 코드 변경이 자동으로 테스트되고, 테스트를 통과하면 배포된다. 사람이 수동으로 배포 과정을 거치지 않아도 된다.

이것이 있어야 Sprint마다 배포가 가능하다. CI/CD 없이 배포가 수동이고 위험하면, 팀은 배포를 미루게 된다.

리팩토링

코드의 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 것이다.

Agile에서 리팩토링은 지속적으로 이루어져야 한다. 기능을 추가할 때마다 코드를 조금 더 나은 상태로 남기는 Boy Scout Rule이 있다. "캠프장을 처음보다 깨끗하게 남겨라."

리팩토링을 별도 시간으로 내기 어려우면, 기능 추가나 버그 수정을 하면서 자연스럽게 함께 하는 것도 방법이다.

마지막으로: 속도는 도구고, 방향은 판단이다

Agile Manifesto가 나온 지 25년이 넘었다. 그 사이 Agile은 방법론이 되었고, 인증 시스템이 되었고, 컨설팅 산업이 되었다. 원래 의도에서 멀어진 것도 많다.

하지만 핵심 질문은 여전히 남아 있다.

지금 만드는 것이 실제로 필요한 것인가.
방향이 맞는지 자주 확인하고 있는가.
틀렸을 때 빠르게 수정할 수 있는가.

AI는 더 빠르게 만들어준다.
하지만 이 질문들에 답하는 것은 여전히 사람의 몫이다.

속도는 도구다.
방향은 판단이다.

Agile은 속도를 높이기 위한 이름이 아니라,
틀린 방향을 오래 붙잡지 않기 위한 검증 루프에 가깝다.

참고자료

이 문서는 다음 자료들을 바탕으로 작성됐다.

Manifesto for Agile Software Development (2001) — Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn 외 17명. 4가지 가치와 12가지 원칙의 원문.
The Scrum Guide — Ken Schwaber, Jeff Sutherland. 2020년 버전. Scrum의 역할, 이벤트, 아티팩트 공식 정의.
Kanban Guide for Scrum Teams — Daniel S. Vacanti, John Coleman. Kanban 원칙의 공식 정리.
Extreme Programming Explained: Embrace Change — Kent Beck. 1999 (2판 2004). XP의 가치, 원칙, 실천들.
Shape Up: Stop Running in Circles and Ship Work that Matters — Ryan Singer. Basecamp. 고정 시간, 가변 범위의 대안 방법론.
The Lean Startup — Eric Ries. 2011. Build-Measure-Learn 루프와 MVP 개념.
Standish Group CHAOS Report — Standish Group. 1994년부터 소프트웨어 프로젝트 성공률을 추적한 보고서.
Agile Estimating and Planning — Mike Cohn. 2005. Story Point, Velocity, Backlog 관리의 실천 지침.
Clean Agile: Back to Basics — Robert C. Martin. 2019. Agile Manifesto 공동 서명자의 현대적 해석.