애자일(Agile): SW프로세스의 추상과 구현
애자일은 절차가 아니라 원칙 집합이다. 선언문은 무엇을 더 중시하는가를 제시하지만, 어떻게 구현할 것인가는 정의하지 않는다. 따라서 애자일은 아래 두 층으로 분리해서 봐야 한다.
- 철학: Manifesto 수준의 가치와 원칙
- 구현: XP, Scrum 등 구체적 실행 방법
문제는 대부분 구현이 아니라, 철학과 구현 사이의 간극에서 발생한다.
익스트림 프로그래밍: 조건이 충족될 때만 성립하는 방법
익스트림 프로그래밍(XP)은 짧은 주기와 강한 피드백 루프를 전제로 한다.
주요 구성 요소는 다음과 같다.
- 반복적 개발: 짧은 주기로 동작 가능한 소프트웨어를 지속적으로 제공
- 테스트 주도 개발: 코드보다 테스트를 먼저 작성하여 동작을 정의
- 짝 프로그래밍: 두 명이 동시에 코드 품질과 설계를 검증
- 지속적 통합: 변경 사항을 자주 병합하고 자동으로 검증
- 고객 참여: 요구사항을 실시간으로 반영
- 단순한 설계: 현재 요구사항에 집중하고 지속적으로 리팩토링
이 구조는 다음 전제를 요구한다.
- 요구사항 결정 권한이 단일 주체로 수렴되어야 한다
- 변경 비용이 관리 가능한 수준이어야 한다
- 테스트 코드가 설계의 일부로 유지되어야 한다
- 팀이 지속적으로 같은 컨텍스트를 공유해야 한다
이 전제가 깨지면 XP는 빠르게 붕괴한다.
실패 패턴
-
요구사항 결정 주체 분산 여러 이해관계자가 동시에 요구를 제시하면, 테스트는 안정적인 기준이 아니라 변동하는 목표가 된다.
-
테스트 유지 비용 폭증 요구사항 변경이 잦은데 테스트 구조가 이를 흡수하지 못하면, 테스트는 신뢰 가능한 검증 수단이 아니라 유지 비용이 된다.
-
리팩토링 불가능 상태 짧은 주기를 유지하기 위해 구조 개선이 지연되면, 이후 변경 비용이 기하급수적으로 증가한다.
-
고객 참여의 오용 기술적 제약을 고려하지 않은 요구가 필터 없이 유입되면, 시스템은 점진적으로 일관성을 잃는다.
정리
XP는 빠른 피드백 구조를 극단적으로 밀어붙인 방법이다. 그러나 이는 조건이 충족될 때만 성립한다.
애자일의 단계: 탐색, 몰입, 조정
탐색
비즈니스 요구사항을 수집하고 이를 작업 단위로 분해하는 단계다.
이 단계의 핵심은 다음이다.
- 요구사항의 경계 정의
- 우선순위 설정 기준 확립
- 작업 단위의 크기 조정
실패는 대부분 여기서 시작된다.
실패 패턴
- 요구사항이 기술 제약을 반영하지 않음
- 우선순위 기준이 명확하지 않음
- 작업 단위가 지나치게 크거나 작음
탐색 단계가 불안정하면 이후 모든 단계는 보정 비용을 계속 발생시킨다.
몰입
선정된 작업을 실제로 수행하는 단계다.
일반적으로 다음과 같이 분류된다.
- 필수 기능
- 가치 제공 기능
- 선택적 기능
이 단계의 핵심은 선택이 아니라 배제다. 무엇을 하지 않을지를 명확히 하지 않으면, 모든 작업이 동시에 진행되면서 집중도가 붕괴된다.
조정
진행 상황을 기반으로 계획을 수정하는 단계다.
핵심 요소는 다음과 같다.
- 현재 상태의 가시성
- 변경 비용 평가
- 우선순위 재조정
실패 패턴
- 진행률이 아니라 작업량으로 판단
- 이미 진행 중인 작업을 빈번하게 변경
- 변경 비용을 고려하지 않은 재계획
조정은 유연성을 제공하지만, 동시에 시스템을 불안정하게 만들 수 있다.
스크럼: 역할 기반으로 추상을 제한하는 방법
스크럼은 애자일 철학을 구조화하려는 시도다.
핵심 구성은 다음과 같다.
- 역할 정의: Product Owner, Scrum Master, Development Team
- 이벤트 정의: Sprint, Daily Scrum, Review, Retrospective
- 짧은 반복 주기
이 구조의 핵심은 역할을 통해 의사결정 경로를 제한하는 것이다.
장점
- 요구사항 결정 책임이 명확해진다
- 논의 범위가 구조적으로 제한된다
- 진행 상태를 일정 단위로 관측할 수 있다
실패 패턴
-
Product Owner 부재 요구사항이 단일 창구로 수렴되지 않으면, 스크럼은 XP보다 빠르게 붕괴한다.
-
이벤트 형식화 회의가 의사결정이 아니라 보고 절차로 변하면 의미가 사라진다.
-
역할과 권한 불일치 역할은 정의되어 있지만 실제 권한이 없다면 구조는 작동하지 않는다.
정리
스크럼은 애자일을 구현하기 위한 제약 조건을 명시적으로 도입한 방법이다. 이 점에서 현실 조직에 더 적합하다.
결론
애자일은 방법이 아니라 방향이다.
문제는 이 방향이 다음 조건을 요구한다는 점이다.
- 요구사항 결정 구조의 단일화
- 변경 비용에 대한 인식
- 테스트와 설계의 결합
- 역할과 권한의 일치
이 조건이 충족되지 않으면, 애자일은 다음과 같은 형태로 변형된다.
- 폭포수와 애자일의 혼합
- 지속적 변경과 구조 붕괴
- 테스트 없는 반복 개발
결과적으로 애자일은 도입 자체보다, 조건을 충족시키는 것이 더 어려운 프로세스다.
애자일의 가치는 특정 방법론에 있지 않다. 현장의 피드백을 구조적으로 반영하려는 시도 자체에 있다.
그러나 그 시도를 유지하기 위한 비용과 조건은 결코 가볍지 않다.
애자일은 대체 뭘까
애자일은 어설프게 NASA를 따라하려다가 철야에 시달리는 수많은 실무 기술자들에게, 박사님이 아닌 고졸이라도 납득할 수 있는 구조를 제안해 주기 위한 노력이다. 그러나, 그 애자일 역시 박사님들에 의해 만들어져서 그런지, 현장의 실전과 애자일의 파생 방법론들의 걸음걸이는 조금 다른 것 같다. 그럼에도 불구하고, 어설프게 양복을 빼 입은 채로 남극으로 걸어가려는 신사가 있어야, 현장 전문가의 지원을 등에 업고 남극을 지배하는 ‘아문센 탐험대’가 생긴다. 그래서, 결국 애자일의 첫 주소는 ‘양복을 입은 채 남극으로 갈 계획을 세운 신사’였다면 현재 파생 방법론이 나아가는 것은 ‘개썰매를 지배하는 아문센’이 되어 가는 것이다. 그런 만큼 애자일은 ‘좋은 개썰매를 위해서는 개를 배불리 먹여야 한다’는 최소 원칙을 위해 나아가야 한다. 중간에 어떤 개는 얼어 죽고, 어떤 개는 식량으로 소모되더라도 그 빈도를 줄여 나가고, 마침내 죽은 개도, 죽은 대원도 없는 ‘남극의 안전한 정복’을 이루어 내는 것이 애자일의 미래가 아닐까 싶다.
그리고 그 개를 배불리 먹이기 위해서, 개썰매의 형태를 이누이트 시골 마을에서 조언받고, 시베리아 어느 동네의 털옷을 입고 사냥도 해야 한다는 것이다. 그래서 개썰매의 공기 저항이나, ‘북극곰의 간은 먹으면 죽는다’는 위험 정보의 수집과 방어에 대해 누구보다 정밀한 탐구가 요구된다.
결국 이러한 논의가 이루어지기 위해서는 개를 부품이 아닌 ‘나를 위해 열심히 일해 주는 노동자’라고 생각해야 탐구의 물꼬가 튼다. 그리고 그 현주소는, 아쉽게도 이곳 한국에서는 아직 먼 나라 이야기라고 생각한다.