Lean UX와 Agile UX

Lean UX는 디자인 씽킹, 애자일 개발 방법론, 린 스타트업 세 가지의 교집합에 위치한 UX 접근법이다. 방법론적으로는 빠른 프로토타이핑과 고객 피드백을 기반으로 제품 경험을 설계하고 가치를 이끌어내며, 핵심은 기획·디자인·개발 모든 구성원이 공동의 목표(co-creation)를 갖고 하나의 팀으로 융합되어 작업하는 것이다.

Agile UX는 기존 폭포수(Waterfall) 방식에서 출시 전 검증 단계에만 투입되던 UX를 애자일 이터레이션 사이클에 통합한 접근법이다. 두 모델의 차이는 협업의 밀도에 있다. Agile UX에서는 디자인팀과 개발팀이 긴밀히 협업하되 작업은 별개로 진행하는 반면, Lean UX에서는 디자이너와 개발자가 초기 디자인부터 프로토타입 완성 전 과정을 같은 팀으로 함께 수행한다.

엔씨소프트 모바일A팀 김수영 팀장의 실무 사례에서 Agile UX를 적용해 얻은 교훈은 다음과 같이 요약된다. 잘 된 점으로는 공동 목표 워크숍을 통한 서비스 컨셉 일치, 개발자까지 스케치를 활용한 빠른 커뮤니케이션, co-creation 워크샵을 통한 문제 공동 해결, 작업물을 팀 외부에 공개해 열린 피드백을 수용한 방식 등이 있다. 반면 부족함에서 배운 점으로는 이터레이션마다 명확한 목표를 설정하고 의사결정 기준으로 삼아야 한다는 것, 사내 위키 등을 통한 진척 상황 가시화, task를 팀이 함께 잘게 쪼개는 계획 방식, 가능하면 같은 공간에서 실무진이 직접 소통하는 환경의 중요성이 강조되었다.

두 방법론의 공통 전제는 반복적 개선을 통한 점진적 완성이며, 무엇을 만들 것인가보다 어떻게 협업할 것인가에 더 많은 설계 에너지를 투입하는 것이 성공의 열쇠다.

김수영 팀장과의 인터뷰([pxd talks 38])는 위 사례를 좀 더 구체적으로 보여준다. KTH 시절 첫 애자일 전환 시도에서는 파워포인트 대신 NHN의 '디자인 스튜디오' 툴을 도입하고 구글 애널리틱스로 데이터에 근거한 개선을 추구했지만, 서비스 축이 모바일로 옮겨가면서 복잡한 설계 툴 대신 바로 스케치하는 방식으로 정착했다. 2011년의 첫 시도는 실패로 평가됐고, 2012년 개발 팀장들과 비공식 그룹을 꾸려 파일럿 프로젝트에 애자일을 적용하며 2주 간격의 회고(레트로스펙티브)를 도입한 것이 조직 문화 정착의 전환점이 되었다. 회고를 거듭하며 직군마다 얼마나 다른 관점으로 문제를 보는지 확인하고 목표를 맞춰가는 과정에서 구성원의 몰입도가 높아졌다.

실무에서는 반영하기 애매한 아이디어를 억지로 쳐내기보다 백로그 위시리스트에 모두 기록해두어 제안자를 안심시키고 훗날을 대비하는 방법을 쓴다. MVP의 기준은 '앱스토어에 등록할 수 있는 완성도'가 아니라 '사용자가 써볼 수 있는 최소 수준'이며, '조금만 더 잘하자'는 생각이 진짜 사용자를 위한 것인지 만드는 사람의 욕심인지 항상 되물어야 한다는 지적도 있다. 데이터를 대할 때는 무조건 따르는 data-driven이 아니라 확신이 설 때까지 다른 데이터로 교차 검증하는 data-informed 태도가 필요하며, 미시적 수치 개선에만 매몰되면 Local Optimization의 함정에 빠질 수 있다는 경계도 함께 제시된다.

이 인터뷰는 Lean UX 환경에서 UX 디자이너의 미래 역할에 대한 관점도 보여준다. 김수영은 UX 디자이너가 Project Manager보다는 팀의 목표를 붙잡고 다른 직군의 의견을 모으는 Project Facilitator(애자일의 스크럼 마스터에 가까운 역할)에 더 적합하다고 본다. 다만 Lean UX가 만능은 아니라는 한계도 짚었는데, 더블 다이아몬드의 Develop-Deliver 단계(수치 관찰과 잦은 개선)에는 Lean 방식이 유효하지만 Discover-Define 단계, 즉 핵심 가설을 세우는 과정에는 큰 도움이 되지 않으며 사용자에 공감하는 별도의 시간이 필요하다.

B2B 스타트업에서의 Lean UX: 일반적인 린 스타트업의 Build-Measure-Learn 이터레이션은 제품을 실사용자에게 배포해 반응을 바로 측정할 수 있는 B2C 상황을 전제로 한다. 반면 배포 대상 자체가 마땅치 않고 실제 반응 측정도 어려운 B2B 시장에서는 순서가 뒤집혀, 일단 팔아보고(Sell) 고객 반응을 배워(Learn) 이를 토대로 만든 뒤(Build) 다시 파는(Sell) Sell-Learn-Build-Sell 사이클이 더 잘 맞는다. 빅데이터 기반 금융 솔루션 스타트업 Strevus의 사례에서는 코드를 짜기 전부터 세일즈 팀이 고객을 만나 니즈를 수집하고, 인터랙션 프로토타입으로 데모를 미리 셀링한 뒤 반응이 좋은 버전을 발전시키는 방식으로 이 사이클을 운영했다. 이 과정에서 UX 디자이너는 개발자 옆에서 함께 작업하며 디자인 피드백을 받아 다시 User story를 도출하는 애자일 사이클과 맞물려 움직인다.

B2B Lean UX가 겪는 특유의 어려움도 있다. ① 특정 문제에 대한 특수한 솔루션일수록 시장 규모가 작아 스케일업이 어렵고, 이 때문에 고객 선택 시 해당 니즈가 다음 고객과도 연결되는지를 함께 고려해야 한다. ② 구매자(Buyer)와 실사용자(User)가 분리되어 있어, 사용자가 만족해도 구매자라는 문지기를 넘지 못하면 제품이 닿지 않는다. ③ 세일즈 과정에서 아이디어가 노출되어 고객사나 경쟁사가 이를 자체 개발할 위험도 반복 속도를 늦추는 요인이다. Strevus는 세부 기능(Feature) 단위로 흩어져 있던 User story를 퍼소나와 'A day in life' 기법으로 유기적 시나리오로 통합해, 개발팀이 자신이 만드는 기능이 실제 어떤 맥락에서 쓰이는지 이해하도록 했다.

End-user 접근이 막힌 상황의 리서치 우회법: B2B에서는 세일즈(Sales)와 구매자(Buyer)라는 장벽 때문에 UX팀이 실제 최종 사용자를 직접 만나기 어려운 경우가 많다. 이럴 때 쓸 수 있는 방법으로 ① 세일즈 팀원에게 실제 최종 사용자 역할을 맡겨 진행하는 거짓 인터뷰(Mock-interview)/역할극, ② 같은 고객군을 상대하는 헤드헌팅·컨설팅 회사와 정보를 교환하는 컨소시엄 협력, ③ 해당 분야에서 실제 일했던 사람을 단기 컨설턴트로 채용하는 방법이 있다. 세 방법 모두 실제 사용자 인터뷰보다 디테일과 신뢰도는 떨어지지만, 접근이 원천적으로 막힌 상황에서 쓸 수 있는 고육지책이다.

책 리뷰 『Lean UX』(Jeff Gothelf, Josh Seiden): 이 재용은 이 책이 Lean UX를 '린 스타트업과 UX의 교집합'으로 정의한다고 소개하며, 그 뿌리를 디자인 사고·애자일 개발·린 스타트업 세 방법론에서 찾는다. Lean UX가 실무에 가져오는 진짜 변화는 절차나 문서가 아니라, 디자이너가 홀로 완벽한 문서를 만들어 개발자에게 넘기던 방식에서 전체 팀이 함께 만들고 고치는 협업 방식으로 옮겨가는 관점 전환(mindset shift)이다. 이 변화가 정착하려면 산출물(output)이 아닌 매출·회원수 같은 결과물(outcome)을 중시하도록 조직 문화·계약 방식 자체가 바뀌어야 하며, 저자는 waterfall 방식의 상징인 BDUF(Big Design Up Front)가 Lean UX 확산과 함께 사라질 것이라 전망한다.

Proto-Persona와 pxd의 Agile Persona: 책이 제안하는 Proto-Persona는 현장 리서치 없이 팀원들의 가정(assumption)을 바탕으로 스케치·인구통계 정보·pain point·잠재적 해결책 네 요소를 빠르게 정리한 뒤 이후 리서치로 계속 보완해 나가는 기법이다. pxd는 이미 유사한 개념을 Agile Persona라는 이름으로 제시해 왔는데, 문제와 해결책을 철저히 분리하는 전통적 퍼소나 기법과 달리 Proto-Persona는 처음부터 잠재적 해결책까지 포함한다는 차이가 있다.

Agile Persona의 원형 — 2011년 pxd의 3주 프로젝트 사례: 이 재용은 2011년, 폭포수식 사용자 중심 디자인|UCD에 익숙한 UI 디자이너가 개발자들 사이에 빠르게 확산되던 Agile Process에 어떻게 대응해야 하는지를 고민하며 해외 사례를 조사했다. 당시 해외 문헌들은 Agile 환경의 문제로 ① 디자인 역할의 불명확함, ② 요구사항·컨셉 탐색 단계의 부재, ③ 미완성 상태에서 안정화보다 기능 추가 욕구가 앞서는 경향, ④ 그로 인한 품질 저하를 지적했고 "Agile is good for refining, not defining"(Agile은 다듬는 데는 좋지만 처음 정의하는 데는 도움이 안 된다)는 결론으로 수렴했다. 이를 바탕으로 이 재용은 세 가지 원칙 — 디자인팀이 개발팀과 완전히 한 팀이 될 것, 프로젝트 초반에 최소한의 사용자 조사·모델링을 할 것, 부지런히 참고 사례를 모아 빠르게 프로토타입을 반복할 것 — 을 제시했다.

이 원칙을 실제 3주짜리 프로젝트에 적용한 것이 Agile Persona 기법의 시초다. 전통적인 'user interview → modeling(critical characteristics) → persona → strategy' 순서를 뒤집어 ① peer interview(프로젝트 팀원 2~4명에게 "너는 어때?"라고 묻는 1~2시간짜리 약식 인터뷰) → ② persona assumption(대략의 퍼소나 감 잡기) → ③ questionnaire(key critical characteristics를 4~7개 체크형 문항으로 구성해 응답 즉시 퍼소나 패턴을 판별할 수 있도록 설계한 설문지) → ④ user interview(패턴이 궁금한 응답자를 불러 추가 질문) 순서로 진행해, 첫 주 안에 리서치와 퍼소나·전략 수립을 마쳤다. 둘째 주에는 외부 인원 5명을 초청해 프로젝트 구성원 포함 8명이 각자 프레임웍 2개씩(총 15개)을 그려 발표하는 Framework Sketch Workshop을 열고, 퍼소나의 과업을 가장 잘 해결한 프레임웍·안정적이고 익숙한 구조의 프레임웍·서비스 고유 컨셉을 가장 잘 보여주는 프레임웍 3개를 선정해 팀원들이 각각 발전시킨 뒤 다시 2개로 통합했다. 셋째 주에는 GUI 팀이 워크숍 단계부터 참여해 스타일링을 병행하는 Rapid Design Styling으로 디자인 시안을 완성했다. 이 재용은 이런 압축된 프로세스가 성공하려면 진행자가 사용자 조사·UI 설계 경험은 물론 도메인 지식까지 풍부해야 오류나 시행착오를 피할 수 있다는 점을 가장 중요한 전제 조건으로 꼽았다.

MVP를 둘러싼 논쟁: 이 재용은 책이 제시하는 MVP(Minimum Viable Product)에서 '학습(learning) 목적'과 '시장 가치 전달(value delivery)' 두 초점이 뒤섞여 있다고 비판한다. 학습이 목적이라면 그것은 MVP가 아니라 프로토타입이어야 하며, 검증되지 않은 것을 실사용자 시장에 내놓는 일은 비윤리적이라는 입장이다. 특히 책이 제시하는 가짜 신청 버튼, 가짜 광고, 눌러도 반응 없는 '공갈 버튼' 같은 위장형 MVP 기법에 대해서는 사용자를 속이는 행위라며 강하게 반박하고, MVP는 언제나 실제 가치를 전달하며 시장에서 살아남을 수 있어야 하고 학습·테스트가 목적이면 별도의 프로토타입(혹은 'prototype MVP')을 만들어야 한다고 결론짓는다. Lean UX의 리서치는 사전이 아닌 사후에, 다른 직군과 협업하며 지속적으로 이루어진다는 점이 전통적 UX 리서치와의 차이이며, 저자가 제안하는 3-12-1 시스템(매주 목요일 낮 12시 전까지 3명의 사용자를 인터뷰)이 이 지속적 피드백 루틴의 구체적 실천 방법이다.

"왜 LeanUX인가?" — pxd Lean UX 연재의 출발점 (2013): pxd 대표 이재용은 Lean UX 시리즈 연재를 시작하며 그 배경을 UX 자체가 태동하던 과정과의 역사적 유사성으로 설명한다. 그는 1990년대 중반 노먼·쿠퍼·홀츠블랫·IDEO·파인 등 여러 전문가가 동시대에 독립적으로 UX 관련 이론을 쏟아낸 현상을 사례로 들며, Lean UX의 부상에서도 같은 세 가지 조짐이 반복된다고 짚는다. ① 기존 방식의 반복적 실패(혁신이 이미 많이 이루어진 도메인에서는 추가 혁신이 점점 어려워짐), ② 완전히 다른 유통 방식의 등장(하드웨어 → 패키지 소프트웨어 → 지속적 배포로 이어지는 변화), ③ 비슷한 아이디어가 여러 사람에 의해 동시에 제기됨(Agile, Lean 등)이 그것이다. 그는 2011년 Michael Shilman을 통해 Lean UX를 처음 접했을 때는 대기업 프로세스에 적용하기 어려울 것이라 예단했지만, 2012년 한 프로젝트에서 MVP+지속적 배포 방식을 시도했다가 뜻대로 되지 않았고, 이후에도 비슷한 시행착오를 반복하며 결국 진지하게 Lean UX를 도입하기로 결심하게 되었다고 밝힌다. pxd 내부적으로는 이미 2011년 7월(`/444`)에 Lean이 처음 소개되었고, UX Intensive 2012(`/521`)와 UI 17 2012(`/662`)에서도 관련 논의가 있었던 만큼, 이 연재는 그간 쌓여온 관심을 본격적인 실천으로 옮기는 선언에 해당한다.

"Lean UX Lab"이라는 이름의 유래 — Cynefin 프레임워크와 안전한 실패(Probe): pxd 랩(Lab)의 명칭 변천사는 Lean UX가 지향하는 실패관을 그대로 보여준다. 랩의 이전 이름은 Probetyping Labs였으며, 이는 "안전한 실패"를 뜻하는 Probe에 초점을 맞춘 프로토타이핑을 적극 활용하겠다는 취지였다. 이후 좀 더 대중적으로 알려진 Lean UX라는 용어를 차용해 현재의 이름으로 바뀌었다.

이 명칭 변화의 배경에는 커너빈 프레임워크(Cynefin Framework)가 있다. 이 프레임워크는 인과관계의 불확실성 정도에 따라 문제 상황을 다섯 가지로 분류한다: ① Simple(단순) — 인과관계가 단순·반복적이라 최선의 방법을 미리 알 수 있음, ② Complicated(복잡) — 원인과 결과가 시공간적으로 분리되어 복잡하지만 반복적이라 분석 가능, ③ Complex(복합) — 인과관계를 사후에야 발견하며 예측이 어려움, ④ Chaos(혼돈) — 원인과 결과 사이에 연관성이 없음, ⑤ Disorder(무질서) — 아직 어떤 유형인지조차 파악되지 않은 상태.

퍼소나나 더블 다이아몬드 같은 전통적 디자인 방법론은 Cynefin 분류상 Complicated 영역의 접근법(sense-analyze-respond)으로, 기존 제품·서비스를 개선하거나 점진적으로 혁신하는 데는 적합하지만, 누구에게 무엇을 팔지조차 명확하지 않은 스타트업이나 신규 시장 개척처럼 분석할 데이터 자체가 없는 Complex 영역에는 적용하기 어렵다. 실제로 스타트업이 실패하는 전형적인 두 패턴은 ① Complex한 상황에 계획적·시스템적 접근(Complicated 방식)을 고집하거나, ② 반대로 무턱대고 만들어 시장 반응만 보는 무계획적 접근(Chaotic 방식)을 취하는 것이다.

Complex 영역에서는 안전한 실패를 통해 배우는 접근이 필요하며, 린 스타트업의 Build-Measure-Learn 반복은 결국 비용 대비 학습 효율을 높이는 Probe(안전한 실패)의 다른 이름이다. "실패해도 계속 도전하면 성공한다"는 통속적 격언과 달리, 현실에서 실패는 결코 공짜가 아니기 때문에 이 반복 자체를 의도적으로 설계된 안전한 프로토타이핑으로 만드는 것이 핵심이다.

핵심 내용

  • Lean UX = 디자인 씽킹 + 애자일 개발 방법론 + 린 스타트업의 교집합
  • Agile UX: 디자인·개발 팀이 작업은 따로, 협업은 긴밀히
  • Lean UX: 디자이너·개발자가 초기부터 하나의 팀으로 공동 작업(co-creation)
  • 실무 핵심: 이터레이션마다 공동 목표 설정 → 의사결정 기준으로 활용
  • 진척 가시화(사내 위키 등)로 팀원들의 불안 해소 및 리듬감 유지
  • task 세분화 + 팀 공동 계획이 이터레이션의 유연성과 협업을 높임
  • 스케치 커뮤니케이션: 개발자도 그림으로 아이디어를 내면 빠른 공유 가능
  • 동일 공간 근무가 실무진 직접 소통 속도에 결정적 영향
  • 2주 간격 회고(레트로스펙티브)가 직군 간 관점 차이 확인과 목표 정렬, 몰입도 향상의 전환점
  • 백로그 위시리스트: 반영 애매한 아이디어도 모두 기록해 제안자를 안심시키고 훗날에 대비
  • MVP 기준은 '앱스토어 등록 가능 수준'이 아니라 '사용자가 써볼 수 있는 최소 수준'
  • 의사결정은 data-driven이 아닌 data-informed로, 미시적 수치에만 매몰되는 Local Optimization 경계 필요
  • UX 디자이너의 Lean UX 내 역할: Project Manager보다 Project Facilitator(스크럼 마스터형)에 가까움
  • 더블 다이아몬드의 Develop-Deliver엔 Lean 방식이 유효하나, Discover-Define(핵심 가설 설정)엔 한계가 있어 사용자 공감 시간이 별도로 필요
  • B2B Lean UX는 B2C의 Build-Measure-Learn 대신 Sell-Learn-Build-Sell 사이클이 적합
  • B2B 특유의 난점: 스케일업 어려움 / 구매자-사용자 분리 / 아이디어 유출 위험
  • End-user 접근이 막힌 B2B 환경에서는 Mock-interview·컨소시엄 협력·컨설턴트 채용으로 리서치 우회
  • Lean UX 책의 정의: Design Thinking + Agile + Lean Startup의 교집합, 핵심은 관점 전환(mindset shift)
  • Proto-Persona: 가정 기반 4요소(스케치/인구통계/pain point/잠재적 해결책)로 만드는 퍼소나, pxd의 Agile Persona와 유사
  • Agile Persona 원형(2011): peer interview → persona assumption → questionnaire → user interview 순으로 전통적 퍼소나 프로세스를 뒤집어 1주일 안에 리서치·전략을 완료
  • Framework Sketch Workshop(외부 인원 포함 8명이 프레임웍 15개 스케치 후 3개로 압축) → Rapid Design Styling(GUI팀 조기 합류)으로 3주 내 디자인 시안 완성
  • 압축된 Agile Persona 프로세스가 성공하려면 진행자의 사용자 조사·UI 설계·도메인 지식이 풍부해야 함
  • MVP는 학습이 아닌 시장 가치 전달이 본질 — 가짜 버튼 등 위장 MVP는 비윤리적이라는 비판
  • 3-12-1 시스템: 매주 목요일 정오 전 3명 사용자 인터뷰로 지속적 피드백 확보
  • BDUF(Big Design Up Front)는 Lean UX 확산과 함께 사라질 관행으로 전망됨
  • pxd 랩의 이름 변천: Probetyping Labs → Lean UX Lab, Probe(안전한 실패) 개념이 뿌리
  • 커너빈 프레임워크: Simple/Complicated/Complex/Chaos/Disorder 5분류 — 퍼소나·더블다이아몬드는 Complicated 영역 도구
  • Complex 영역(신규 시장·스타트업)에는 Build-Measure-Learn = Probe 접근이 적합
  • "왜 LeanUX인가?": UX 태동기와 Lean UX 부상 사이의 3가지 역사적 유사성(반복적 실패/유통 방식 변화/동시다발적 아이디어)
  • pxd 내부의 Lean 논의는 2011년 7월(최초 소개)부터 UX Intensive·UI 17 2012를 거쳐 2013년 연재 시작으로 이어짐

관련 개념

출처

최종 업데이트: 2026-07-24 | 출처 7개