앱 하나를 처음부터 설계해보기

화면 원칙을 하나씩 배울 때는 모두 이해한 것 같다가도, 막상 새 프로젝트를 시작하면 손이 멈출 때가 많다. 문제 정의는 어떻게 시작해야 하는지, 기능은 어디까지 넣어야 하는지, 첫 화면에는 무엇이 보여야 하는지, 테스트는 언제 해야 하는지 한꺼번에 밀려오기 때문이다.

실무 감각은 이럴 때 생긴다. 원칙을 따로 외우는 것이 아니라, 하나의 제품 안에서 연결해보는 순간이다. 그래서 이번 장에서는 가상의 앱 하나를 처음부터 설계해보겠다. 중요한 것은 화려한 결과물이 아니라, 무엇을 왜 이렇게 결정했는가다.

이번에 설계할 앱: 세탁 수거 예약 서비스

사례로 다룰 앱은 1인 가구와 맞벌이 가구를 위한 세탁 수거 예약 앱이다. 이름은 편의상 오늘세탁이라고 하자. 사용자는 앱에서 수거 시간을 예약하고, 문 앞에 세탁물을 두고, 세탁이 끝나면 다시 배송받는다.

이 서비스를 고른 이유는 단순하다. 겉으로 보기에는 예약 앱이지만, 실제로는 UI/UX의 거의 모든 기본 문제가 들어 있기 때문이다. 사용자는 빠르게 예약하고 싶어 하고, 가격이 불안하고, 시간이 헷갈리면 떠나고, 주소와 결제처럼 민감한 정보를 입력해야 하며, 오프라인 운영과도 경험이 이어진다. 즉, 화면만 예쁘게 만든다고 해결되지 않는 프로젝트다.

이 장에서 우리가 만들 것은 완성형 서비스 전체가 아니다. 첫 출시를 위한 핵심 예약 경험이다. 범위를 좁히지 않으면 프로젝트는 늘 산으로 간다.

문제를 한 줄로 정의하기

좋은 프로젝트는 보통 예쁜 화면이 아니라 좋은 문제 문장으로 시작한다. "세탁 앱을 만들자"는 문제 정의가 아니다. 그건 아이디어에 가깝다. 우리가 먼저 붙잡아야 하는 것은 사용자의 막막함이다.

오늘세탁의 문제 문장은 이렇게 정리할 수 있다.

평일에 세탁소에 들를 시간이 없는 직장인은 세탁을 계속 미루게 되고, 특히 셔츠나 드라이클리닝 의류처럼 관리가 필요한 옷일수록 불편과 스트레스가 커진다.

여기에 비즈니스 관점을 붙이면 더 선명해진다.

우리는 사용자가 앱 설치 후 첫 예약까지 빠르게 도달하게 만들어야 하며, 첫 경험에서 신뢰를 얻어야 재이용이 일어난다.

이 문장은 중요한 기준을 준다. 이 프로젝트의 핵심은 브랜드 감성을 과시하는 것도, 기능을 많이 넣는 것도 아니다. 첫 예약을 쉽게 만들고, 불안을 줄이는 것이다.

누구의 문제를 먼저 풀 것인가

모든 사용자를 동시에 만족시키려 하면 제품은 금방 두루뭉술해진다. 그래서 첫 버전에서는 대표 사용자를 좁혀야 한다.

이번 프로젝트의 1차 타깃은 이런 사람이다.

• 평일 퇴근 시간이 일정하지 않은 20~30대 직장인

• 셔츠, 블라우스, 코트처럼 관리 세탁이 필요한 옷이 있는 사람

• 앱 사용에는 익숙하지만 세탁 대행 서비스는 자주 써보지 않은 사람

한 명을 떠올리면 더 구체적이다. 예를 들어 이런 사용자다.

민지는 31세 직장인이다. 아침에 출근할 때마다 다림질 안 된 셔츠를 보고 스트레스를 받는다. 세탁소 영업시간 안에 방문하기는 어렵고, 주말에는 쉬고 싶다. 세탁 대행이 있다는 것은 알지만, 가격이 얼마나 나오는지, 정말 제시간에 수거하는지, 문 앞에 둬도 괜찮은지 불안하다.

이 설정이 중요한 이유는 명확하다. 민지는 세탁을 즐겁게 하려고 앱을 켜는 사람이 아니다. 귀찮음과 불안을 줄이기 위해 들어온다. 그러니 첫 화면부터 감성보다 확신이 먼저 와야 한다.

사용자 가설을 세우기

문제를 정의했다고 바로 화면을 그리면, 그 화면은 대개 팀의 추측으로 채워진다. 그래서 실무에서는 가설을 먼저 적는 편이 좋다. 가설은 막연한 믿음을 검증 가능한 문장으로 바꿔준다.

오늘세탁의 초기 가설은 다섯 가지로 잡을 수 있다.

첫째, 사용자는 세탁 서비스의 철학보다 내 주소에서 가능한지를 먼저 알고 싶어할 것이다.

둘째, 첫 이용자는 결제보다 먼저 대략적인 가격을 확인하고 싶어할 것이다.

셋째, 사용자가 가장 헷갈리는 지점은 품목 선택보다 수거 시간과 배송 시간의 관계일 것이다.

넷째, 첫 예약 전환율을 떨어뜨리는 큰 원인은 입력 항목 수 자체보다, 왜 이 정보를 지금 넣어야 하는지 이해되지 않는 순간일 것이다.

다섯째, 예약 완료 뒤에 다음 과정을 충분히 설명해주지 않으면 사용자는 서비스를 불안하게 느낄 것이다.

이 다섯 문장은 이후의 설계와 테스트 기준이 된다. 실무에서 중요한 것은 처음부터 정답을 아는 것이 아니라, 무엇이 틀릴 수 있는지 먼저 적어두는 일이다.

기능 목록이 아니라 핵심 경험을 정하기

새 앱을 기획할 때 가장 흔한 실수는 기능을 상상하는 일부터 시작하는 것이다. 쿠폰, 정기권, 리뷰, 추천인 코드, 얼룩 진단, 세탁 완료 알림, 기사 위치 추적, 기업 제휴, 멤버십까지 끝없이 붙는다. 하지만 첫 버전은 그렇게 만들수록 위험해진다.

오늘세탁의 첫 출시에서 꼭 필요한 것은 하나다. 사용자가 첫 예약을 무리 없이 끝내는 경험이다.

그래서 MVP 범위는 이렇게 잡는다.

• 서비스 가능 지역 확인

• 품목 또는 수량 선택

• 예상 가격 확인

• 수거 시간 선택

• 주소 입력

• 결제 수단 등록

• 예약 완료와 진행 상태 확인

반대로 첫 버전에서 과감히 빼는 기능도 정한다.

• 포인트와 쿠폰 체계

• 친구 추천 이벤트

• 세탁 방식 상세 옵션의 과도한 커스터마이징

• 리뷰 커뮤니티

• 가족 계정과 다중 주소 고급 설정

무엇을 만들지가 아니라, 무엇을 만들지 않을지를 정하는 순간 제품이 또렷해진다.

플로우를 설계할 때 먼저 결정해야 할 것

이제 핵심 플로우를 짜야 한다. 여기서 중요한 것은 화면 순서보다 사용자의 질문 순서다. 사용자는 앱 안에서 이런 생각을 할 가능성이 높다.

"우리 집도 되나?" "대충 얼마 나오지?" "오늘 맡기면 언제 가져가나?" "예약은 복잡하지 않나?" "정말 믿고 맡겨도 되나?"

이 질문 순서를 무시하고 팀 편한 순서대로 짜면 플로우가 어색해진다. 예를 들어 회원가입부터 시키면 사용자는 아직 가치도 확인하지 않았는데 개인정보부터 내놓아야 한다고 느낀다. 반대로 결제 직전까지 가격을 숨기면 나중에 불신이 생긴다.

그래서 오늘세탁은 세 가지 흐름을 비교해본다.

안 A: 회원가입 먼저

홈 → 회원가입 → 주소 입력 → 품목 선택 → 시간 선택 → 결제

이 방식은 운영과 데이터 관리에는 편하다. 하지만 첫 진입 장벽이 높다. 사용자는 아직 이 서비스가 나에게 맞는지 모르는데 가입부터 해야 한다.

안 B: 가능 여부와 가격 확인 먼저

홈 → 주소 확인 → 품목 선택 → 예상 가격 확인 → 시간 선택 → 가입/결제 → 완료

이 방식은 사용자 질문 순서와 가장 가깝다. 서비스 가능 여부와 비용 감을 먼저 주기 때문에 첫 예약 동기가 생긴다.

안 C: 품목부터 빠르게 선택

홈 → 품목 선택 → 시간 선택 → 주소 입력 → 결제

진입은 빨라 보이지만, 주소 입력 뒤 서비스 불가 지역이면 허탈감이 크다. 뒤늦게 막히는 경험은 불만을 키운다.

이 프로젝트에서는 안 B를 선택한다. 이유는 단순하다. 사용자가 가장 불안해하는 정보인 가능 여부와 가격 감을 앞쪽에 두는 편이, 예약 전환과 신뢰 형성에 모두 유리하기 때문이다.

첫 와이어프레임: 화면이 아니라 결정의 초안 만들기

이제 와이어프레임을 그릴 차례다. 여기서 중요한 것은 미감이 아니라 우선순위다. 각 화면마다 "사용자가 여기서 꼭 알아야 할 것 한 가지"를 먼저 정해야 한다.

1. 첫 화면

첫 화면의 목적은 브랜드 소개가 아니다. 사용자를 예약 시작 지점까지 데려가는 것이다. 그래서 상단에는 과감하게 주소 확인 영역을 둔다. 그 아래에는 "지금 예약 가능", "오늘 수거 가능 시간", "예상 가격 예시"를 보여준다. 하단의 주된 행동은 하나다. 수거 예약 시작하기다.

배너를 여러 장 넣고, 세일 문구를 넣고, 추천 메뉴를 늘어놓고 싶어질 수 있다. 하지만 첫 예약을 만들고 싶은 제품에서 그런 요소는 대부분 소음을 만든다.

2. 품목 선택 화면

사용자는 세탁 카테고리를 전문적으로 알지 못한다. 그래서 "일반 세탁", "드라이클리닝", "생활 빨래" 같은 운영 기준만 앞세우면 오히려 헷갈린다. 화면은 사용자의 언어로 풀어야 한다. 예를 들어 셔츠, 바지, 코트, 이불처럼 익숙한 품목 중심으로 보여주고, 각 항목 옆에 예상 가격 범위를 함께 둔다.

이 화면의 핵심은 정교한 분류가 아니라 부담 없이 시작하게 만드는 것이다. 그래서 첫 버전에서는 너무 세세한 옵션을 숨기고, 대표 품목을 중심으로 빠르게 담게 한다.

3. 시간 선택 화면

이 단계는 가장 위험하다. 수거 시간과 배송 시간이 한 화면에 뒤섞이면 사용자는 쉽게 헷갈린다. 그래서 두 영역을 시각적으로 분리한다. 먼저 오늘 또는 내일의 수거 가능 시간대를 고르고, 그 다음 예상 배송일을 보여준다.

여기서 중요한 것은 선택지를 많이 주는 것이 아니다. 오히려 추천 슬롯을 먼저 제안하는 편이 낫다. 예를 들어 "가장 빠름", "퇴근 후 추천", "내일 아침"처럼 대표 옵션을 보여주고, 더 많은 시간을 보고 싶은 사람만 펼쳐보게 한다.

4. 주소와 전달 방식

초기 안에서는 위치 권한을 앱 시작과 동시에 요청하는 방식을 생각할 수 있다. 하지만 첫 진입에서 권한 요청은 자주 경계심을 만든다. 특히 세탁 서비스는 실시간 추적 앱이 아니므로 더 그렇다. 그래서 주소 입력 화면에 들어왔을 때만, 현재 위치로 주소 찾기를 보조 기능으로 둔다. 권한은 문맥 안에서 요청한다.

또 한 가지 중요한 것은 세탁물을 어디에 둘지 명확히 하는 것이다. 사용자는 생각보다 이 부분을 불안해한다. 문 앞, 경비실, 직접 전달 중 하나를 고르게 하고, 필요한 경우 짧은 메모를 남기게 한다.

5. 예약 확인과 결제

예약 확인 화면은 그냥 결제 직전 요약이 아니다. 사용자의 마지막 불안을 다루는 화면이다. 품목, 예상 가격, 수거 시간, 배송 예상일, 수거 방식, 결제 시점이 한눈에 보여야 한다.

CTA 문구도 중요하다. 단순히 "다음"이나 "확인"이라고 쓰면 행동의 결과가 모호하다. 여기서는 예약 확정하고 결제하기처럼 결과가 드러나는 문구가 더 적절하다.

6. 완료 화면

많은 앱이 완료 화면을 너무 짧게 다룬다. 하지만 서비스 경험은 여기서 끝나지 않는다. 오히려 여기서부터 운영 경험이 시작된다. 따라서 완료 화면에는 "오늘 8시~10시 수거 예정", "수거 30분 전 알림", "세탁 시작 후 예상 배송일 안내"처럼 다음 단계를 시간 흐름으로 보여주는 것이 좋다.

완료는 끝이 아니라, 안심의 시작이어야 한다.

예외 상태를 설계하지 않으면 실전에서 무너진다

실무 프로젝트가 자주 흔들리는 이유는 정상 흐름만 그리기 때문이다. 하지만 실제 사용자는 정상 상태보다 예외 상태에서 더 많은 감정을 느낀다.

오늘세탁에서 반드시 먼저 잡아야 할 예외 상태는 다음과 같다.

• 서비스 불가 지역인 경우

• 오늘 수거 슬롯이 모두 마감된 경우

• 예상 가격과 실제 검수 가격이 다를 수 있는 경우

• 결제는 됐지만 예약 확정이 지연되는 경우

• 사용자가 부재중이라 수거가 실패한 경우

예를 들어 서비스 불가 지역이라면 단순히 "지원하지 않는 지역입니다"로 끝내면 안 된다. 대신 오픈 알림 신청이나 서비스 예정 지역 안내를 보여줘야 한다. 그래야 막힌 경험이 완전한 실패로 남지 않는다.

또 예상 가격은 매우 민감하다. 이 금액이 확정가인지, 검수 후 달라질 수 있는지 늦게 알리면 신뢰가 흔들린다. 그래서 작은 문구 하나라도 타이밍이 중요하다. 숨기는 것보다 미리 알려주는 편이 거의 항상 낫다.

프로토타입은 무엇을 확인하기 위해 만드는가

와이어프레임이 잡히면 프로토타입으로 넘어간다. 이 단계에서 실무자가 자주 빠지는 함정은 화면을 실제 서비스처럼 멋지게 보이게 만드는 데 집중하는 것이다. 하지만 프로토타입은 전시물이 아니다. 검증 장치다.

오늘세탁의 프로토타입은 고충실도까지 가지 않고, 중간 정도 현실감으로 만든다. 이유는 두 가지다. 첫째, 가격과 시간 관련 문구는 실제처럼 보여야 오해를 확인할 수 있다. 둘째, 아직 비주얼 브랜딩보다 플로우 검증이 더 중요하다.

이번 프로토타입에서 확인하려는 질문은 분명해야 한다.

• 사용자는 첫 화면에서 바로 예약을 시작할 수 있는가

• 주소 확인과 가격 확인의 순서를 자연스럽게 이해하는가

• 수거 시간과 배송 시간을 헷갈리지 않는가

• 결제 직전 불안 요소를 충분히 해소했는가

• 완료 화면을 본 뒤 다음 상황을 예측할 수 있는가

질문이 없으면 프로토타입은 그냥 움직이는 그림이 된다.

첫 테스트: 다섯 명만 봐도 큰 문제가 보인다

테스트 참가자는 세탁 대행을 자주 쓰는 헤비 유저보다, 가끔 쓰거나 써볼까 고민한 경험이 있는 사람으로 모집한다. 오늘세탁의 핵심은 처음 쓰는 사람의 망설임을 줄이는 것이기 때문이다.

테스트 과업은 이렇게 준다.

"이번 주에 입어야 할 셔츠 3장과 재킷 1벌을 맡기려고 합니다. 오늘 퇴근 후 수거 예약을 해보세요."

방법은 알려주지 않는다. 상단 버튼을 누르라고 힌트를 주는 순간, 화면이 쉬운지 어려운지 알 수 없기 때문이다.

테스트 결과는 꽤 선명하게 나왔다.

첫째, 다섯 명 중 네 명이 첫 화면에서 가격 정보를 먼저 찾았다. 예상 가격이 화면 아래로 내려간 버전에서는 신뢰가 약하다는 반응이 나왔다.

둘째, 세 명은 수거 시간과 배송 시간을 같은 종류의 선택으로 이해했다. 한 참가자는 오늘 밤 맡기면 오늘 밤 다시 받는 것으로 잠깐 오해했다.

셋째, 두 명은 위치 권한 요청을 보고 "왜 내 위치를 계속 알아야 하지?"라고 반응했다. 이 문구는 실제 사용 행동을 멈추게 만들었다.

넷째, 네 명이 결제 직전 화면에서 "최종 금액이 이대로 확정되는 건가요?"를 확인하려 했다. 예상 가격과 최종 가격의 관계가 충분히 선명하지 않았다.

다섯째, 모든 참가자가 완료 화면에서 다음 정보를 찾았다. 기사 도착 전 연락 여부, 문 앞에 그냥 두면 되는지, 언제 다시 받는지였다.

재미있는 점은 누구도 색상이나 버튼 모서리부터 말하지 않았다는 것이다. 실제 사용자는 늘 더 현실적인 문제를 먼저 드러낸다.

발견된 문제를 설계 문장으로 바꾸기

테스트가 끝났다고 바로 화면을 고치면 안 된다. 먼저 관찰을 문제 문장으로 바꿔야 한다. 그래야 해결이 엉뚱한 방향으로 흐르지 않는다.

오늘세탁의 핵심 문제는 이렇게 정리할 수 있다.

문제는 이렇게 써야 팀이 같은 곳을 바라볼 수 있다. "사용자가 헷갈려함"만으로는 좋은 해결책이 나오기 어렵다.

두 번째 설계: 무엇을 어떻게 바꿨는가

이제 개선안을 만든다. 중요한 것은 모든 피드백을 다 반영하는 것이 아니라, 핵심 과업을 가장 많이 방해한 문제부터 고치는 것이다.

첫 화면 개편

첫 화면 상단을 브랜드 배너에서 주소 확인과 예약 가능 여부 영역으로 바꾼다. 그리고 그 아래에 대표 품목 기준의 예상 가격 예시를 바로 배치한다. 사용자는 앱이 멋진지보다, 지금 쓸 수 있는지가 더 궁금하다.

CTA도 "시작하기"에서 우리 집 수거 예약하기로 바꾼다. 행동 대상이 더 분명해진다.

시간 선택 구조 분리

수거 시간과 배송 예상일을 같은 레벨의 버튼 묶음으로 보여주지 않는다. 먼저 수거 시간을 선택하게 하고, 그 다음 화면 또는 명확히 분리된 영역에서 배송 예상일을 설명한다. "오늘 밤 수거, 모레 배송 예정"처럼 한 문장으로 요약해주는 방식이 특히 효과적이다.

권한 요청의 타이밍 조정

앱 진입 직후 위치 권한을 요청하는 방식은 없앤다. 대신 주소 입력 화면에서 "현재 위치로 주소 찾기"를 눌렀을 때만 권한을 요청한다. 요청 문구도 바꾼다. "가까운 수거 가능 지역을 빠르게 찾기 위해 현재 위치를 1회 사용합니다"처럼 이유와 범위를 짧게 설명한다.

가격 신뢰 강화

예상 가격 아래에 작은 회색 글씨로만 안내하던 내용을 더 눈에 띄게 바꾼다. 예를 들어 "검수 후 특수 오염이나 소재에 따라 변동될 수 있어요"라고 쓰는 대신, 예약 확인 화면에서 현재 예상 금액 / 변동 가능 조건 / 실제 확정 시점을 나눠 보여준다. 불편한 진실일수록 늦게 알릴수록 더 나쁘다.

완료 화면을 타임라인 중심으로 변경

완료 화면에 단순한 체크 아이콘만 두지 않는다. 예약 직후 사용자가 궁금해할 다음 단계를 시간 순서대로 보여준다.

• 오늘 19:00~21:00 수거 예정

• 수거 30분 전 알림 발송

• 검수 후 최종 금액 확정

• 2일 뒤 저녁 배송 예정

이렇게 하면 사용자는 예약 이후를 상상할 수 있다. 좋은 완료 화면은 성취감보다 안심을 준다.

두 번째 테스트에서 확인한 것

개선안으로 다시 짧은 테스트를 해보면 보통 양상이 달라진다. 처음에는 큰 문제에 가려졌던 작은 마찰이 보이기 시작한다.

이번에는 수거와 배송 시간을 혼동하는 비율이 크게 줄어든다. 대신 새로운 문제가 보인다. 어떤 사용자는 품목 선택에서 재킷을 일반 세탁으로 넣어도 되는지 망설인다. 즉, 처음에는 플로우 문제가 컸고, 그걸 줄이니 이제 분류의 정확성이 보이기 시작한 것이다.

이때 제품 팀은 욕심이 생긴다. 카테고리를 더 세세하게 쪼개고 싶어진다. 하지만 다시 복잡성이 늘어날 위험이 있다. 그래서 여기서의 해결은 품목 체계를 복잡하게 만드는 것이 아니라, 대표 예시를 더 친절하게 보여주는 것이어야 한다. 예를 들어 "재킷 · 코트는 보통 드라이클리닝으로 맡겨요" 같은 짧은 안내가 더 효과적일 수 있다.

실무는 늘 이런 균형 잡기다. 문제를 본다고 해서 무조건 기능을 추가하는 것이 아니라, 가장 작은 수정으로 가장 큰 혼란을 줄이는 쪽을 먼저 찾는다.

최종 MVP는 어떻게 생기는가

여기까지 오면 비로소 "무엇을 출시할 것인가"를 말할 수 있다. 오늘세탁의 최종 MVP는 다음과 같은 구조를 가진다.

첫 화면에서는 서비스 가능 여부와 가격 감을 빠르게 확인하게 한다. 예약 플로우에서는 품목, 수거 시간, 주소, 전달 방식, 결제를 한 번의 흐름으로 묶되, 각 단계에서 왜 필요한지를 설명한다. 완료 이후에는 운영 과정을 타임라인으로 보여주고, 예약 상태를 추적할 수 있게 한다.

반면 정기권, 쿠폰, 리뷰, 추천인 보상은 제외한다. 나중에 충분히 붙일 수 있지만, 첫 예약 경험을 검증하기 전에는 핵심이 아니다.

이렇게 정리하고 나면 제품은 덜 화려해 보일 수 있다. 하지만 실무에서는 이런 제품이 더 강하다. 이유는 단순하다. 무엇을 잘해야 하는지 알고 있기 때문이다.

이 프로젝트에서 배워야 할 실무 감각

이 사례에서 진짜 중요한 것은 세탁 앱 자체가 아니다. 어떤 종류의 앱을 만들든 비슷하게 적용되는 감각이 있다.

첫째, 프로젝트는 기능이 아니라 문제 문장으로 시작해야 한다. 문제 문장이 흐리면 화면은 금방 장식으로 채워진다.

둘째, 사용자 가설은 적어두어야 한다. 머릿속 추측은 토론이 되기 쉽지만, 문장으로 적힌 가설은 검증 대상이 된다.

셋째, 핵심 플로우는 사용자의 질문 순서를 따라야 한다. 팀의 업무 순서와 사용자의 판단 순서는 다르다.

넷째, 와이어프레임은 예쁜 구조가 아니라 우선순위의 초안이다. 한 화면에 하나의 주된 목적이 있어야 한다.

다섯째, 테스트는 디자인의 품평회가 아니다. 어디서 신뢰가 깨지고, 어디서 멈추는지를 보는 과정이다.

여섯째, 개선은 기능을 더하는 일이 아니라 마찰을 줄이는 일인 경우가 많다.

막막할 때 바로 써먹는 프로젝트 진행 순서

실제 업무에서 새 앱이나 새 기능을 처음 설계해야 한다면, 다음 순서로 생각하면 크게 흔들리지 않는다.

• 사용자의 불편을 한 문장으로 적는다.

• 비즈니스가 얻고 싶은 결과를 한 문장으로 적는다.

• 가장 먼저 공략할 사용자 한 종류를 정한다.

• 첫 성공 경험이 무엇인지 정한다.

• 그 성공까지 가는 핵심 플로우만 남기고 나머지는 뺀다.

• 와이어프레임으로 우선순위를 드러낸다.

• 프로토타입으로 가장 위험한 가설을 검증한다.

• 테스트 결과를 문제 문장으로 다시 쓴다.

• 심각도가 큰 문제부터 수정한다.

• 다시 짧게 검증한다.

이 순서가 특별해 보여서가 아니라, 실무에서는 결국 이 단순함이 팀을 살린다. 복잡한 프로젝트도 실제로는 이런 기본을 얼마나 흔들리지 않고 지키느냐에서 결과가 갈린다.

결국 앱 설계는 화면을 그리는 일이 아니다

앱 하나를 처음부터 설계해보면 금방 알게 된다. 제품을 만드는 일은 화면을 채우는 작업이 아니다. 사용자의 막연한 불편을 구조화하고, 그 불편이 행동으로 바뀌는 순간을 설계하는 일이다.

좋은 프로젝트는 처음부터 완벽하지 않다. 대신 질문이 분명하다. 누구의 어떤 문제를 풀 것인지, 사용자가 어디서 주저할 것인지, 무엇을 먼저 보여줄 것인지, 어디까지 만들고 어디서 멈출 것인지가 정리되어 있다. 이 기준이 있으면 와이어프레임도 덜 흔들리고, 프로토타입도 덜 과장되고, 테스트도 더 정확해진다.

실무 감각은 대단한 영감에서 나오지 않는다. 하나의 흐름을 끝까지 책임져본 경험에서 나온다. 문제를 정의하고, 가설을 세우고, 화면을 연결하고, 사용자의 망설임을 보고, 다시 고치는 과정. 바로 그 반복이 제품을 더 낫게 만들고, 디자이너뿐 아니라 PM, 개발자, 창업자 모두를 더 좋은 설계자로 만든다.

다음 장에서는 이렇게 만든 경험을 한 단계 더 실무적으로 확장해, 이미 운영 중인 기존 서비스를 어떻게 개선하고, 그 과정을 어떻게 문서화할 것인지 살펴본다.