한 줄 요약
애자일은 개발 방법론의 이름이 아니라, 2001년 애자일 선언문에 정리된 가치와 원칙의 묶음이에요. 짧은 주기로 작동하는 결과물을 만들고, 그 피드백으로 다음 방향을 정하는 방식이에요.

1. 애자일이란
애자일은 2001년 미국 유타주 스노버드에 모인 17명의 소프트웨어 개발자들이 작성한 애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development) 에서 출발했어요. 문서에 참여한 사람들 중에는 켄트 벡, 알리스테어 코오번, 제프 서덜랜드 등이 있어요.
여기서 중요한 점이 하나 있어요. 이들이 만든 것은 새로운 방법론이 아니라 가치와 원칙이에요. 서로 다른 방식으로 일하던 사람들이 공통으로 동의할 수 있는 기준을 정리한 문서예요.
그래서 "애자일을 도입한다"는 말은 정확히는 "애자일 가치에 맞는 방식(스크럼, 칸반, XP 등) 중 하나를 도입한다"는 뜻이에요.
2. 4가지 가치
선언문은 네 가지 비교로 이루어져 있어요. 왼쪽을 더 중요하게 본다는 구조예요.
| 더 중요하게 보는 것 | 비교 대상 |
|---|---|
| 개인과 상호작용 | 프로세스와 도구 |
| 작동하는 소프트웨어 | 포괄적인 문서 |
| 고객과의 협력 | 계약 협상 |
| 변화에 대응하기 | 계획을 따르기 |
여기서 가장 많이 오해받는 문장이 마지막에 붙어 있어요. 선언문은 오른쪽 항목에도 가치가 있으며, 다만 왼쪽을 더 중요하게 여긴다고 명시해요. 오른쪽을 버리라는 뜻이 아니에요.
3. 12가지 원칙 (요약)
선언문에는 위 가치를 뒷받침하는 12가지 원칙이 함께 실려 있어요. 원문의 내용을 간추리면 이래요.
- 가치 있는 소프트웨어를 일찍, 그리고 지속적으로 전달해 고객을 만족시키는 것이 최우선이에요.
- 요구사항 변경은 개발 후반이라도 받아들여요. 변화를 고객의 경쟁력으로 활용해요.
- 작동하는 소프트웨어를 몇 주에서 몇 달 간격으로 자주 전달하되, 짧은 주기를 선호해요.
- 비즈니스 담당자와 개발자가 프로젝트 기간 내내 매일 함께 일해요.
- 동기가 부여된 사람들을 중심으로 프로젝트를 구성하고, 필요한 환경과 지원을 준 뒤 신뢰해요.
- 가장 효율적인 의사소통 방법은 얼굴을 마주보고 하는 대화예요.
- 진척도를 재는 기본 척도는 작동하는 소프트웨어예요.
- 지속 가능한 속도를 유지해요. 무기한 같은 속도를 이어갈 수 있어야 해요.
- 기술적 우수성과 좋은 설계에 대한 지속적인 관심이 민첩성을 높여요.
- 단순함, 즉 하지 않는 일의 양을 최대화하는 것이 핵심이에요.
- 최선의 아키텍처와 설계는 자기 조직적인 팀에서 나와요.
- 팀은 주기적으로 더 효과적인 방법을 돌아보고, 그에 맞춰 행동을 조정해요.
4. 쉽게 이해하는 설명
[ 폭포수(Waterfall) ]
요구분석 → 설계 → 개발 → 테스트 → 배포
│
결과물은 여기서야 처음 확인
[ 애자일(Agile) ]
┌ 반복 1 ┐ ┌ 반복 2 ┐ ┌ 반복 3 ┐
│계획·개발│ → │계획·개발│ → │계획·개발│
│ ·검증 │ │ ·검증 │ │ ·검증 │
└────┬───┘ └────┬───┘ └────┬───┘
결과물 결과물 결과물
└──── 피드백을 다음 반복에 반영 ────┘
집을 짓는 방식에 비유하면 이해가 빨라요.
폭포수는 설계도를 완성하고 착공해서 완공까지 간 뒤 집주인에게 보여주는 방식이에요. 잘 맞으면 효율적이지만, 다 지은 뒤에 "주방 위치가 잘못됐다"는 말이 나오면 되돌리는 비용이 커요.
애자일은 방 하나를 먼저 완성해서 살아보게 하고, 그 반응을 다음 방 설계에 반영하는 방식이에요. 완성 시점은 늦어 보일 수 있지만, 잘못된 방향으로 오래 가는 위험이 줄어요.
5. 자주 하는 오해
"애자일은 문서를 안 쓴다" — 아니에요. 선언문은 포괄적인 문서보다 작동하는 소프트웨어를 더 중요하게 본다고 했을 뿐, 문서에도 가치가 있다고 명시했어요. 필요한 문서는 씁니다.
"애자일은 계획을 안 세운다" — 아니에요. 계획을 따르는 것보다 변화에 대응하는 것을 더 중요하게 본다는 뜻이에요. 계획 자체를 부정하지 않아요.
"애자일 = 스크럼" — 아니에요. 애자일은 가치와 원칙이고, 스크럼은 그 가치를 실현하는 여러 프레임워크 중 하나예요. 칸반, XP(익스트림 프로그래밍)도 마찬가지예요. 스크럼의 역할과 이벤트 정의는 애자일 선언문이 아니라 별도 문서인 스크럼 가이드에 있어요.
"짧게 자주 배포하면 애자일이다" — 배포 주기는 결과이지 정의가 아니에요. 12번째 원칙처럼 돌아보고 조정하는 과정이 없으면, 주기만 짧은 폭포수가 되기 쉬워요.
6. 핵심 정리
- 애자일은 방법론 이름이 아니라 2001년 선언문에 정리된 가치와 원칙이에요.
- 4가지 가치는 왼쪽 항목을 더 중요하게 본다는 비교 구조이며, 오른쪽을 버리라는 뜻이 아니에요.
- 12원칙의 축은 짧은 주기의 전달, 변화 수용, 사람 중심, 주기적 회고예요.
- 진척도를 재는 기준은 문서나 일정이 아니라 작동하는 소프트웨어예요.
- 스크럼, 칸반, XP는 애자일 가치를 구현하는 서로 다른 방식이에요.
7. 추가 정보
주의사항
- 이 글은 애자일 선언문 원문을 기준으로 정리했어요. 스크럼의 역할·이벤트·산출물 정의는 스크럼 가이드에서 별도로 확인해야 해요.
- SAFe, LeSS 같은 대규모 적용 프레임워크는 각각 별도의 공식 문서를 갖고 있어요. 선언문에서 직접 도출되는 내용이 아니에요.
- 12원칙은 원문 표현을 우리말로 간추린 것이므로, 정확한 문구는 원문에서 확인하시는 것을 권해요.
'개념정리' 카테고리의 다른 글
| 도커(Docker) 개념 정리 — 잘못 쓰면 이렇게 됩니다 (0) | 2026.09.09 |
|---|---|
| SSOT와 DOM 개념 정리 — 정의부터 실무 활용까지 (0) | 2026.09.03 |
| CI/CD란 무엇인가? 비전공자도 이해하는 CI/CD 개념 정리 (0) | 2026.09.02 |
| Claude Code 101 가이드북 (나만의 학습 노트) (0) | 2026.07.25 |
| QA 풀 테스트 진행법과 이슈 트래킹 실무 (0) | 2026.07.24 |