고정 헤더 영역
상세 컨텐츠
본문
반응형
해당 글은 미디엄에 게시된 아래 링크의 글을 정리한 글입니다.
📊 Gartner 다이어그램의 개념
Gartner(2016)가 제시한 다이어그램은 세 가지 방법론을 순차적으로 결합합니다:
- Design Thinking (아이디어 발상 단계)
- Lean Startup (실험 및 검증 단계)
- Agile (실행 및 제품 출시 단계)
처음에는 매력적으로 보이지만, 잘못 실행되면 워터폴 방식으로 변질될 위험이 있습니다.
🚨 3가지 주요 함정
1. 대규모 사전 계획의 함정
문제점: 다이어그램이 좌측에서 우측으로 순차적으로 진행되는 것처럼 보여, 문제 해결 단계를 실행 전에 완료해야 한다는 잘못된 인식을 줍니다.
예시:
- ❌ 워터폴 방식: "6개월 동안 Design Thinking으로 모든 사용자 니즈를 완벽하게 파악한 후, 3개월 동안 Lean Startup으로 모든 가설을 검증하고, 그 다음에 Agile로 개발을 시작하자"
- ✅ 올바른 방식: 디자인 씽킹, 린 스타트업, 애자일을 동시에 반복적으로 적용하며, 작은 단위로 빠르게 학습하고 개선
실제 사례: 한 금융 앱 팀이 3개월간 사용자 리서치만 진행하고, 2개월간 프로토타입 테스트만 한 후 개발을 시작했습니다. 개발 단계에서 시장 상황이 변했고, 초기 리서치 결과가 무용지물이 되었습니다.
2. 기능별 사일로와 단계 간 인계의 함정
문제점: 각 방법론을 별도의 팀이나 전문가 그룹이 담당하면서 사일로가 형성되고, "생각하는 사람들"과 "실행하는 사람들"로 분리됩니다.
예시:
- ❌ 사일로 방식:
- UX팀이 Design Thinking 단계에서 와이어프레임 완성 → PM팀에 전달
- PM팀이 Lean Startup 방식으로 비즈니스 모델 검증 → 개발팀에 전달
- 개발팀이 Agile 스프린트로 구현
- 각 인계 시점마다 정보 손실과 지연 발생
- ✅ 크로스펑셔널 방식:
- UX 디자이너, PM, 개발자가 하나의 팀으로 함께 일함
- 디자이너가 기술 제약을 이해하고, 개발자가 사용자 니즈를 직접 파악
- 매 스프린트마다 디자인-검증-개발을 함께 진행
실제 사례: 한 이커머스 회사에서 디자인팀이 완벽한 체크아웃 플로우를 설계했지만, 개발팀에 전달되자 기술적 제약으로 70%만 구현 가능하다는 사실이 드러났습니다. 3주간의 재설계가 필요했습니다.
3. 모든 상황에 하나의 방법론 적용의 함정
문제점: 이 세 가지 방법론만이 유일한 해답이라는 인식을 줄 수 있으며, 상황과 조직에 맞지 않아도 강제로 적용하는 경우가 발생합니다.
예시:
- ❌ 획일적 적용: 스타트업부터 대기업까지 동일한 프로세스 강요
- ✅ 상황 맞춤:
- 초기 스타트업: Lean Startup 중심 + 최소한의 디자인
- 성숙한 제품: Design Thinking 강화 + 지속적 개선
- 레거시 시스템: 단계적 전환 전략
🔄 각 방법론 상세 설명 및 올바른 적용 방법
1. Design Thinking (디자인 씽킹)
핵심 개념: 사용자 중심으로 문제를 깊이 이해하고 창의적 솔루션을 찾는 반복적 프로세스
5단계:
- 공감(Empathize): 사용자 관찰 및 인터뷰
- 정의(Define): 핵심 문제 도출
- 아이디어 발상(Ideate): 브레인스토밍
- 프로토타입(Prototype): 빠른 시제품 제작
- 테스트(Test): 사용자 피드백 수집
올바른 적용 예시: 모바일 뱅킹 앱 개발 시:
- 1주차: 고령 사용자 10명 인터뷰 → "복잡한 메뉴 때문에 두려움" 발견
- 2주차: "가장 간단한 송금 경험" 문제 정의
- 3주차: 페이퍼 프로토타입 5가지 제작
- 4주차: 사용자와 함께 테스트 → 즉시 피드백 반영
- 동시에: 개발자가 기술적 제약 확인, PM이 비즈니스 임팩트 측정
잘못된 적용: 3개월간 디자인만 완성하고 개발팀에 "이대로 만들어주세요" 전달
2. Lean Startup (린 스타트업)
핵심 개념: 가설 → 실험 → 측정 → 학습의 빠른 반복 사이클(Build-Measure-Learn)
핵심 원칙:
- MVP (Minimum Viable Product): 최소 기능으로 빠르게 출시
- 검증된 학습: 데이터 기반 의사결정
- 피봇 or 지속: 학습 결과에 따라 방향 전환
올바른 적용 예시: 새로운 AI 추천 기능 개발:
- Week 1 - 가설 수립: "사용자들은 AI 추천으로 구매 전환율이 20% 증가할 것"
- Week 2 - MVP 개발: 간단한 규칙 기반 추천 엔진 (완벽한 AI 아님)
- Week 3 - 측정: 100명 베타 유저에게 배포 → 실제 전환율 5% 증가
- Week 4 - 학습 & 피봇: "추천보다 상품 비교 기능이 더 필요하다" 발견 → 방향 전환
매주 반복하며 진화:
- V1: 기본 추천 → V2: 카테고리별 추천 → V3: 개인화 추천
잘못된 적용: "MVP를 만들었으니 이제 6개월간 완벽한 제품을 만들자" (학습 사이클 중단)
3. Agile/Scrum (애자일/스크럼)
핵심 개념: 짧은 주기(스프린트)로 작동하는 제품을 지속적으로 전달하며, 변화에 유연하게 대응
Scrum 프레임워크:
- 스프린트: 2-4주 단위 작업 주기
- 크로스펑셔널 팀: 모든 필요 역량 보유
- 자기 조직화: 팀이 스스로 방법 결정
- 점진적 가치 제공: 매 스프린트마다 사용 가능한 결과물
올바른 적용 예시: 전자상거래 플랫폼 개선:
Sprint 1 (2주):
- Day 1-2: 디자이너, 개발자, PM이 함께 사용자 인터뷰 분석
- Day 3-5: 함께 간단한 결제 흐름 개선안 스케치 및 프로토타입
- Day 6-10: 개발 및 테스트
- Day 11-12: 실제 사용자에게 배포 및 데이터 수집
- Day 13-14: 회고 및 다음 스프린트 계획
Sprint 2: Sprint 1의 학습 내용을 바탕으로 개선 반복
핵심 포인트:
- 디자인 씽킹(사용자 이해) + 린 스타트업(빠른 검증) + 애자일(반복 개발)이 한 팀에서 동시에 일어남
잘못된 적용: 스프린트는 진행하지만, 디자인은 3스프린트 앞서서 완료하고, 개발팀은 받은 대로만 구현
✅ 올바른 통합 방식: Scrum이 제시하는 해결책
핵심 원칙:
1. 하나의 통합 팀
워터폴 방식:
[디자이너] → [인계] → [PM] → [인계] → [개발자]
올바른 방식:
[디자이너 + PM + 개발자] 함께 협업하며 동시 진행
2. 공동 창조(Co-creation) 매 스프린트마다:
- 함께 문제 발견 (Design Thinking)
- 함께 가설 검증 (Lean Startup)
- 함께 솔루션 구현 (Agile)
실제 예시: 택시 호출 앱 개선 프로젝트:
- 월요일 오전: 전체 팀이 사용자 불만 데이터 분석
- 월요일 오후: 디자이너가 스케치하는 동안 개발자가 기술 가능성 확인
- 화요일: 함께 가장 영향 큰 기능 1개 선택
- 수~목요일: 개발자가 코딩하는 동안 디자이너는 다음 기능 준비하고 PM은 비즈니스 메트릭 설정
- 금요일: 베타 사용자에게 배포 및 피드백 수집
- 다음 주: 학습 내용 바탕으로 개선
3. 지속적 진화 큰 계획 대신 작은 MVP를 빠르게 반복:
- Week 1-2: 기본 기능 (MVP 1.0)
- Week 3-4: 사용자 피드백 반영 (MVP 1.1)
- Week 5-6: 추가 기능 (MVP 2.0)
- 계속 진화...
🎯 결론: "Agile은 마인드셋이지 메서드가 아니다"
저자의 최종 주장:
- Design Thinking과 Lean Startup은 Agile 툴킷의 일부 도구일 뿐
- Agile은 방법론이 아닌 협업과 소통의 마인드셋
- Scrum, XP, DSDM 등 다양한 프레임워크가 모두 Agile 툴킷에 포함됨
- 조직과 상황에 맞는 도구를 선택하고 통합적으로 적용해야 함
핵심 메시지: 세 가지 방법론을 순차적 단계로 보지 말고, 동시에 반복적으로 적용되는 통합 프로세스로 이해해야 진정한 애자일을 실현할 수 있습니다.
반응형
