칼럼은 아니고

[11/12] 넷플릭스는 왜 같은 영화에 다른 썸네일을 보여줄까? | ‘굿 윌 헌팅’으로 정리하는 데이터 기반 UX

이로새박 — Wed, 12 Nov 2025 20:50:00 +0900

오늘 UX/UI 1주차 자료를 보다가 가장 흥미로웠던 내용이 있었다.

바로 넷플릭스(Netflix)의 Artwork Personalization, 즉 “썸네일 개인화”였다.

배운 내용을 바탕으로, 넷플릭스가 어떻게 데이터를 활용해 UX를 개선했는지 위 사례로 정리해본다

https://netflixtechblog.com/artwork-personalization-c589f074ad76

1. 문제 정의

넷플릭스는 유저 데이터를 분석하면서 한 가지 패턴을 발견했다고 한다.

홈 화면에서 콘텐츠 탐색 시간이 길어질수록 이탈률이 함께 증가한다.
추천 알고리즘이 아무리 좋아도, 썸네일이 취향에 맞지 않으면 클릭하지 않는 현상이 반복되었다.
즉, “추천은 맞는데, 이미지가 설득하지 못한다”는 문제.

원인

같은 영화라도 모든 유저에게 단일 썸네일만 보여주는 구조였음.
유저의 선호 장르·배우·시청 패턴과 “썸네일 이미지” 사이에 적합성 미스매치 발생.
넷플릭스 자체 연구에 따르면, 유저는 영화·시리즈를 고를 때 이미지 한 장에 가장 크게 반응한다고 한다.

결과적으로, 썸네일이 매력적이지 않으면

→ 클릭 X

→ 시청 시작률 감소

→ 탐색 시간 증가

→ 이탈 증가

라는 흐름이 만들어졌다.

2. 가설 수립

넷플릭스가 세운 가설은 아주 명확하다.

“유저의 취향과 맥락(Context)에 맞는 이미지(썸네일)를 보여주면
클릭률(CTR)과 시청 시작률이 증가할 것이다."

여기서 말하는 맥락은 다음과 같다.

좋아하는 장르
자주 보는 배우
최근의 시청 패턴
사용하는 기기 종류(TV/모바일)
시청 시간대

이 맥락 정보와 여러 이미지 후보를 매칭하면

유저마다 최적의 썸네일을 다르게 보여줄 수 있다는 가설이었다.

3. 해결 방법

가설을 검증하기 위해, 넷플릭스는 다음과 같은 시스템을 구축했다.

1) 콘텐츠별로 다양한 썸네일 확보

한 콘텐츠(예: 굿 윌 헌팅)당 아래 처럼 여러 버전을 준비했다.

배우 중심 이미지
감성적 스틸컷
코미디 톤의 컷
액션 느낌의 컷

2) User Context 분석

다음과 같은 행동 데이터를 통해 개인 취향을 추정했다.

장르 선호도
시청 이력
배우 선택 패턴
디바이스·시간대

3) ML 적용 – Contextual bandit model

쉽게 말하면

“이 유저에게 어떤 이미지가 ‘보상(=클릭·시작)’을 가져올 가능성이 높을까?”

를 실시간으로 학습하는 알고리즘이다.

예시 :굿 윌 헌팅

넷플릭스가 직접 설명한 대표 사례는 바로 이 영화다.

코미디/드라마 선호 User→ 로빈 윌리엄스의 따뜻한 얼굴 중심 썸네일 노출
감성·로맨스 선호 User → 맷 데이먼 중심의 감정적 스틸컷 노출

같은 영화라도 전혀 다른 느낌의 이미지가 등장한다.

4. 검증 과정

넷플릭스는 A/B 테스트를 기반으로 다음 지표들을 모니터링했다.

모니터링 지표

CTR (Click Through Rate)
Play Start Rate(시청 시작률)
10분 이상 시청 지속률
탐색 시간 감소 여부
페이지별 이탈률 변화

오프라인 검증 방식

기존 로그 데이터를 활용해

Inverse Propensity Scoring
Doubly Robust Estimator
같은 통계 기반 평가 기법으로 모델 성능을 사전에 검증했다.
(여긴 내 지식 밖)

기술적인 검증

개인화 레이어 추가로 인해 시스템에 부하가 생기지 않는지 아래도 같이 검증

이미지 로딩 시간
캐시 히트율

넷플릭스는 이미지를 개인화하는 시스템이

초당 2천만 건(20M RPS) 이상의 요청을 처리할 수 있어야 한다고 밝히기도 했다.

5. 결과

넷플릭스는 정확한 숫자를 모두 공개하지 않았지만, 다음과 같은 성과를 명시했다.

클릭률(CTR) 유의미하게 상승
시청 시작률 증가
탐색 시간 감소 → 이탈률 감소
전체 추천 시스템의 설득력 강화

즉, 같은 영화라도

“누구에게 어떤 이미지로 보여주느냐”가 UX에 큰 영향을 미친다는 사실을

데이터로 증명해낸 것이다.

굿 윌 헌팅의

로빈 윌리엄스 vs 맷 데이먼 썸네일은

이 변화의 대표 상징처럼 소개된다.

마무리

이번에 배운 ‘데이터 기반 UX’ 개념이 넷플릭스 사례로 딱 이해됐다.

UX 개선이라고 해서 거대한 기능을 만드는 것이 아니라,

이미지 한 장의 최적화가 클릭률과 체류시간을 바꿀 수 있다는 것.

추천 시스템은 “무엇을 보여줄까”에서 끝나지 않는다.

앞으로는 “어떤 비주얼로 보여줄까”까지 고민해야 한다는 점이 인상 깊었다.

[11/04] 큰 흐름을 잘잡아야 한 방향으로 간다

이로새박 — Tue, 4 Nov 2025 22:36:40 +0900

흐름을 정립하며

오늘 오전에 예상치 못한 활동을 하게 되었다.

경쟁사 UI 분석을 담당해주신 팀원분의 결과물이 티켓예매 파트와는 살짝 결이 달라서 이를 수정해야되나 얘기가 나오게 되었다.

그렇다면 팀원분이 잘못된 것을 하신건가? 오, 그건 절대 아니다.

경쟁사 분석이 논리흐름의 어디에 들어가느냐에 따라 나와야 될 결과물이 달라지는데, 우리 팀은 이 흐름이 정립되지 않다보니 누군가 열심히 만들어둔 작업물이 무용지물이 될수도 있는 상황에 놓인 것이다.

방향을 잡고, 이전걸 고치는 작업이 많다보니 "일단 해!"라는 기조가 있었는데, 비로소 이를 벗어나야 될 상황에 처한 것이다.

그래서 우리의 논리 흐름을 위해서 큰 틀을 팀원분들과 다시 맞춰보았다.

그렇게 해서 흐름을 잡았다.

우선적으로는, 실제로 우리 팀이 어떤 사고 과정으로 어떤 작업을 해왔는지 다시 복기했고, 이러한 과정속에서 작업간의 앞뒤 순서를 끼워맞춰보며 틀을 짰다.

우리 프로젝트는 실제로, "User의 메인서비스 디자인에 대한 불만"에 있었기에, 이 리얼함을 정말 서비스 선정으로 삼고 싶었다.

그렇기에, 그 다음 이야기는 그 불만을 담은 '리뷰'와 관련 있어야하고, 그 리뷰들을 정리하여 문제를 도출하는 affinity diagram이 자연스럽게 다음 순서를 가지게 되었다.

~~그 이후, 경쟁사들과의 UI를 비교해나가면서, 현재 서비스 디자인을 고쳐나가야할 인사이트를 얻고 (결론적으로 빠지는 과정)~~

이후 5why로 문제의 본질에 다가가면서, "XXX를 OOO하게 고쳐야돼"를 정의해야한다!

튜터님과의 튜터링을 통해서 위 과정을 처음의 큰 한 덩어리로 보았고, 이후 다음 페이즈들 까지 간략 정리해서 정말정말정말 틀을 제대로 짜게 되었다!

이렇게 정리해보니, 아직 Phase 1도 덜 끝나고, Phase 2도 IA만 한듯안한듯 수준이지만, 그래도 뭐부터 어떻게 해야할지 그 감을 팀원들과 함께 잡고 갈 수 있어서 확실히 필요한 시간이었다고 생각한다.

IA의 경우 막막하긴 했다.

사실 프로젝트 가이드에서 이를 하라고는 했지만, 논리적으로 우리의 생각의 흐름을 짤때에, 대체 어떤 역할을 어떻게 해야하는지 명확하게 이해가 되지 않았다.

하지만 "일단 해" 이 기조로 팀원들과 우다다다 했다.

추후 튜터링으로 "지금처럼 너무 디테일하게 갈 필요는 없고, 이 과정에서 인사이트를 얻어오는 느낌으로 진행하세요" 라는 말을듣고 너무너무 다행이었다.

그러니까 분석을 통해 문단간격, UI 쓰임새 같은 디자인적 캐치를 하고 '왜그렇게 표현했을까' 생각하며 의견을 주면 될 거 같은데, 이렇게 하면 확실히 추후 과정에서 필요한 과정이 되는 것 같았다.

위 캡쳐의 4처럼 내일 팀원들과 함께 디자인카타하듯이 진행해볼 예정.

[11/03] NOL ticket : 좌석선택은 UI가 user와 싸우는 구간이었다

이로새박 — Mon, 3 Nov 2025 23:06:33 +0900

감정을 중심으로 한 Affinity Diagram... 더 효율적인거 인정!

어제 기능 중심으로 묶은 Affinity Diagram을 튜터님께 지적받으면서,

결국 우리의 것.. 눈물을 머금고 보내주고, 다시 배운대로 처음부터 진행해보기로 했다.

근데 사실 해놓은거 놓아주는걸 며칠사이 계속하다보니 이제 아깝지도 않다ㅋㅋㅋㅋㅋ 역시사람은 적응의 동물

하지만 이 역시 오늘도 시행착오가 없진 않았다!

자료조사를 바탕으로 한.. 이전 리뷰 놓아주기

사실 이전에 모아놓은 리뷰를 바탕으로, 기존 Raw한 리뷰 정리하고 잘 Mapping해주고, 각 Cluster에서 인사이트 및 문제점 도출 다 했었다!

하지만.. 이제 직접 User들의 불만과 그 문제점을 직접 서비스로 경험해보니.. 음? 그런 불만이 왜나왔지? 잘되는디..

그러다가 NOL ticket 자료조사 한 내 용이 갑자기 내 전두엽을 스쳤다.

그렇다. NOL ticket은 본래, 인터파크 티켓이었고 올해 4월에 리브랜딩 되었다.

그리고 리브랜딩 될때 티켓예매 관련 UI 및 UX를 그들만의 방식으로 개선하였다!

그렇기 때문에 올해 4월 이전의 리뷰들의 불만은 이 이후로 개선된 것이다!

그래서 거의 다 완성된 Affinity Diagram에서 ㅠㅠ 올해 4월 이전의 리뷰들을 모두 제거하고 다시 진행하였다.

그래도 정말정말 다행인 점은 이를 재진행 후 현재 App서비스와 비교했을때, 불만점이 완벽하게 일치했다는 것!!!

그렇게 우여곡절 끝에 다시 Clustering한 결과는 다음과 같다!

그리고 이들의 Cluster Name을 눈에 들어오게 정리하고, 이로 도출되는 인사이트 및 문제점!

그중 가운데 두개를 우리 프로젝트의 Main개선점으로 잡고, 사이드의 두개를 전반적인 UI리디자인 시 함께 부가적으로 수용하며 제작해나갈 예정이다.

이는 좌선선택 Cluster의 댓글 정리/통합 및 나의 언어로 작성해 본 문제점인데, 괜찮은 것 같아서 일단 keep해둘 예정

어찌되었건 확실히 튜터님은 튜터님이다..

튜터님 말씀대로 방향을 다시잡으니, 시간이 좀 더 걸렸더라도 그 다음과정으로 매끄럽게 논리가 전개된다!

기능으로 나누었으면, 애초에 Cluster가 너무 많이 생성되어서 결국 수 많은 통합되지 않은 문제점들이 도출되고, 추후 이를 통합하는 과정도 매끄럽지 않기에...

NOL ticket, 선정한 이유 정리해보기

그럼에도, 우리 Affinity Diagram의 한가지 틈이 있다면, "예매과정과 관련된 리뷰들" 안에서 정리했다는 점이다.

여러 리뷰들 중 이미 특정Flow를 집중하겠다고 선택하고 들어갔는데, 현재 그 근거가 부족했다.

NOL을 선정한 이유중 가장 큰 이유가 Main기능에 대해 불만표출하는 리뷰들에 있었는데,

이를 잘 버무리면서도 정말 우리가 선정해왔던 스토리를 잘 풀어내서 그 첫 시작을 꾸며내고 싶었다.

그렇게 아래와 같이 러프하게 만들어낸 것 같다.

"목표가 뚜렷한 UX/UI 개선에도 불구하고, 이전 디자인 및 흐름을 그리워하는 User들"로 근거를 잡았고,

정말로 그런 리뷰들을 보고 우리가 이 주제를 선정한거니, 나름 만족스럽게 뽑은것같다.

다만, 튜터님이 피드백해준대로, 맨앞에 "야놀자가 인터파크를 인수한것"을 위치시켜, 나중에 발표때 현 흐름을 듣는사람이 더 와닿게 바꾸고,

또 "매크로"관련 내용도 중간에 삽입해서 뒤의 내용과 더 연결성있게 만들어야지!

티켓예매 디자인, 나중에 어떻게 바꾸지?

결국 좌석선택 UI및 UX를 잘 변경하는것이 우리의 Main 과제가 되어버렸는데,

이를 어떻게 바꿀지 팀원들과 앞서 먼저 토의해보았다.

우선 나의 의견은 다음과 같았다.

Hinge to Touch!

좌석선택 element, aka 포도알이 너무작아서 결국 모두 두손가락으로 확대해야한다!

두 손가락으로 확대는 결국, 평소 모바일기기를 쥐는 그립과 다르다! -> 사용자 경험 떨어뜨린다!

그 과정을 한번의 터치로 바꾸자!

추후 이 아이디어가 차용될지는 모르겠지만.. 어쨋든 의견 하나라도 확실히 있는 나? 나쁘지 않아

튜터님의 제안에 하나 깜짝 놀란게,

결국 Persona가 "공연에 참여하는게 의의인 User" , "좋은 자리에서 꼭 관람하고 싶은 User" 두개일때,

예매 Open전에 그들에게 미리 좌석구역 선택권을 주면 공정성이 생기지 않을까? 라는 의견.

한 90%정도 와닿는데, 우선 이 의견대로 추후 Flow 그려내볼 예정!

내가 Flow를 중시여기는거 스스로 아는데도, UI적으로만 해결보려하는 생각에 갇혀서 생각지 못한듯..

그외 크리틱

이전 Study모집 서비스 디자인 기획 과제에 대한 튜터님과의 피드백시간

드디어 오고야 말았다.

내가 자신에 차서, 너무너무 열심히 안하다가 결국 완성치 못한..

그래도 완성못한건 완성못한거고, 그 외 부분에서 튜터님이 좋았던 부분을 말씀해주셔서 어깨는 조금 올라갔다.

서비스 기획에 대한 고찰, 그리고 이를 디자인적으로 풀어내는 아이디어, 트랜드에 맞게 Liquid Glass로 만들어보려는 시도

음 다행이다.

특히 기분 좋았던 말은,

"시니어가 주니어를 뽑을 때 보는 것은, 결국 틀에 맞춰진 포폴이 아니라 '이런 독창적 시도를?' 포인트인데, 나중에 그건 전혀 걱정 없겠네요", "미적으로 감각이 없으면 이렇게 못하는데?"

튜터님의 어화둥둥 나쁘지 않아! 감사합니다.

하지만, 너무 많은 아이디어가 있었기에 보는 사람이 하나에 집중하지 못하게 되는 점을 꼽아주셨다.

세개의 Main Idea중 오히려 하나를 고친다고 생각해야지 중요 쟁점이 잘보여서 추후 포폴을 만들때는 하나를 파는것이 더 좋다.

그리고 new서비스 기획에서는 지금처럼 가설을 토대로 하는것이 맞고, 지금도 그런 형태의 과제라 start가 괜찮았지만, 기존 서비스 리디자인을 할때는 더 많은 데이터기반으로 시작해야되는 것을 명심하라.

추후 데이터사용, 개발, AI관련 내 실력이나 커리어를 포폴에 섞어 내는것은 매우 긍정적이나 8:2의 2정도의 비중으로 꼭 해줄것. 아니면 "그래서 얘는 뭘하고 싶은거지? UI디자이너 하고픈거 맞나?" 라는 생각이 들더라 (실제 튜터님 사례)

아, 튜터님들과 튜터링할때는 언제나 현업자의 시선을 좋은쪽으로든 나쁜쪽으로든 얻어 갈 수 있어 유익하고 재밌는거 같다.

두서없이 갈겨썼는데 일단 끗

[10/31] NOL ticket : affinity map.. 너 어렵다잉

이로새박 — Mon, 3 Nov 2025 22:14:50 +0900

일단 대충 나중에 적을 수 있게

캡쳐 쓕팍쓕팍 넣고, 나중에 작성할래!

아니 캡쳐도 안할래!

[10/30] NOL ticket : 너로정했다!

이로새박 — Mon, 3 Nov 2025 22:10:58 +0900

그동안 많이 뜸해진 나의 블로그

사실 오늘 날짜는 11월 3일이지만, 다시 한 번 학습을 기록하는 습관을 가져오는 마음으로!
UI 팀프로젝트가 시작한 기념으로!

작성해 나가 볼 예정...

험난했단 UI 주제 정하기 -> 나의 성향을 찾다?

팀프로젝트가 시작되었던 30일, 사실 우리 조는 굉장히 늦게 주제가 정해졌다.

주제를 정하는데에 많이 공을 들였기에, 앞선 우여곡절이 후회되지는 않는다.

팀플의 주제는 프로젝트의 마지막날까지 영향을주는 중요한 것이면서도, 가장 먼저 정해야하는 것..

그렇기에 이 시간만큼 난감한 시간은 없다.

우선 팀원끼리 각자 평소에 불편함을 느끼는 서비스를 가져와서 공유해보기로 하였다.

내가 가져온 주제는 카카오버스와 구글 드라이브

카카오 버스의 경우에는 단순히 '범용성을 가지는 지도어플 종류'에서 생각해낸 주제이다.

평소에 버스를 탈때 주로 사용하면서도, 매번 조금씩 불편함을 겪기에 먼저 떠올랐고, 그렇게 처음으로 이 어플을 한 화면 한 화면 집중적으로 탐색했다.

그리고 느낀 결론 : 음, 그냥 내가 익히기 싫어서 불편했구나!

하나하나 뜯어보니, UX의 흐름도 꽤나 간단하고 UI도 심플하고.. 음, 생각보다 많이 잘 만들었는데?

그래서 바로 다른 주제를 하나 다시 떠올려보았다.. 그게바로 구글 드라이브

내가 구글 드라이브에서 느꼈던 불편함은 크게 두가지였다.

1. 모바일환경과 PC환경에서의 일치하지 않는 경험

- 나의 구글드라이브 사용빈도 80%는 웹이나, 가끔 외부에서 드라이브 내 파일 혹은 자료를 보거나 공유해야할때 모바일 앱으로 사용한다.

그러나, 하단 네비바의 기능이나 파일 업로드 같은 디테일한 사항들이 PC와는 다르게 구현되었고, 그렇기에 자주 버벅거렸다.

2. 서비스의 본질과 닿아있지 않은 네비게이션 바

- 드라이브라는 것은 결국, '클라우드로 구성된 내 외장드라이브'이다. 즉, 내가 구성한 디렉토리 구성을 홈화면에 구성하는 것, 그것이 드라이브의 본질 기능이라고 생각한다. 그러나 해당 기능은 네비게이션바의 가장 우측에 위치해있었고, 즐겨찾기, 공유받은 파일 등이 더 메인기능을 차지했다.

이렇게 내가 평소에 불편한 서비스를 생각해내면서, 나의 성향을 확실히 더 아는 계기가 되었다.

나는 UX중에서도 userflow에 더 민감한 사람이구나

하지만.. 현 프로젝트의 쟁점은 UI적인 개선도 포함되어있으므로, 조금더 UI적인 접근이 가능한 서비스를 살펴보게 되었다.

이외에 타 팀원들이 선택한 주제들은 위와 같다.

메가커피의 쿠폰/적립 바코드를 real-time으로 키는게 생각보다 너무 번거롭다! -> 이 시간을 UI적으로 개선하여 줄여보자!

ㄴ 개인적으로 나도 오프라인으로 연계하는 서비스들에서 항상 불편함과 귀찮음을 느끼는 사람으로써 굉장히 구미가 당기는 프로젝트 주제 였으나, 이를 경험해보지 못한 팀원이 있어서 아쉽게도 무산되었다.

코레일의 경우에도 내가 산 표를 다른 사람에게 전달하는 그 과정을 개선하자는 아이디어가 나왔다.

이의 경우 모든 팀원들이 사용해봤고, 또 범용성이 큰 서비스이기 때문에, 주제로 선정될뻔 하였으나, 위의 카카오버스와 마찬가지로, 막상 분석해보니 생각보다 가감해야할 요소가 적다고 판단되었기에 무산되었다.

하지만 이렇게 팀원들이 의견을 공유함으로써 생긴 목표점이 생겼다.

바로 범용성있는 서비스안에서 선정하는 것!

그러던 와중에 아주 구미가 당기는 주제가 튀어나왔다.

일해라 SRT!!

코레일과 비슷하지만, 아주아주 UX및 UI가 트랜드에 뒤떨어져있는 기가막힌 놈이 하나 굴러왔다.

UI도 UI지만, UX자체도 전혀 공들이지 않고 만든 티가 팍팍났다!

나도 그랬지만, 팀원들 모두 "이거다!!"라는 마음이었다.

정말 거의 모든 userflow를 파고파고 또 팠는데 팔때마다 문제점이 튀어나왔다.

오히려 이러한 문제점이 잘보였기 때문에, 우선적으로 app 탐색에 너무 몰두했는지도 모른다.

사실 나의 경우, "이거 결국 레퍼런스만으로 해결 가능한 주제인데? 독창성은 내기 힘들지도"라는 생각도 들었지만, 그럼에도 너무 매력적인 진주처럼 보이는 녀섴이었다...

하지만 진주처럼 빛나서 너무 현혹된것일까?

결국 디자인을 평가하는 가장 큰 근거는 User이다.

그렇다.. 우리가 SRT를 놓아주게 된 계기는 바로 user의 평가이다.

사실 우리의 직관과 마찬가지로, User의 AppStore 평가도 진짜 엉망이었다.

하지만 문제는.... 열에 열은 모두 기술적 문제에 대한 지적이었다!

기술적 제한이 너무 압.도.적.이어서 UX/UI적으로 근거로 내세울 review가 정말 없었다..

그러나 나의 경우, 지금까지 해놓은게 조금 아깝기도 하고, 주제를 정하고 달려나가는 다른 조들을 보고 조바심이 났기에, 어떻게든 srt로 끌고나가고자하는 마음이 조금 컸던 것 같다.

그래서 내가 내세운 논리!

리뷰 봤다! → 시스템욕 엄청 많다 → 하지만 사용자가 이것이 개발적문제인지 디자인적문제인지 확실하게 구분지어서 쓴 댓글은 아닐꺼잖씀? → 그래서 그런것도 자세히 봤다 

그래서 일단 시스템 적인것도 확인후, 이를 uI적으로 해결할수있는지 판별함  그래서 일단 제일 욕먹는게 뭔데?

첫번째, 로그인과정! → 그래서 로그인 과정 파봄 (곧 해보면 될일) →아하! UI/UX적으로 해결볼수 있는 것도 많더라

하지만, 그 로그인 과정마저 확인해본 결과.. 기술적 문제가 정말 더 압도적이었다.

디자인적으로 만든 흐름이 보이지만, 앱이 제대로 작동안하는 그런 느낌을 더 받았다.

주제를 바꾸자는 팀원과도 의견차이가 나서, 튜터님께 함께 가보았는데

결국 내가 주제 다시 변경에 완벽 납득하게 한 튜터님의 말씀이 아래와 같다.

결국, 해당 주제로 가게 되더라도, 주제를 선택하고 개선을 하는 근거는 반드시 사용자에게서 나온다!
리뷰가 없다면, user들을 대상으로 한 설문조사라도 반드시 필요하다!

그래서 눈물을 머금고 srt를 보내주었다.. 잘살아야돼 .. 그런데 돈좀 들여서 앱좀 제대로 바꾸자..

생각보다 빠르게 결정된 최종 주제

위와 같은 사례를 겪고 더 추가된 주제선정의 기준이 생겼다!

UX/UI 적으로 개선이 필요한 근거가 있는 리뷰!!! 그 리뷰가 반드시 있는 서비스를 고르자!!!!!

그때 팀원분이 "NOL티켓어때요?"라고 한마디 던졌고, 갑자기 다시 의욕이 생겨버렸다.

나 이상진.. 롯데 15년차, 락페 5년차, 최근엔 muse와 oasis를 다녀온 프로직관러!!!!

대학 졸업작품 때는 공연장/경기장 좌석인기도 3d Map 제작 주제를 냈다가 교수님한테 사업성없다고 대차게 까인 그게 바로 나! (교수님 잘지내시죠? 취업하면 찾아가게씀돠)

그렇게 우리는 NOL ticket에 정착했다!!!!

대혼돈의 우리팀 썸네일..

테크놀로지아!

[10/21] 시나리오 쓰고있네

이로새박 — Tue, 21 Oct 2025 13:09:23 +0900

익숙한 말들

학교 다니면서 그렇게 지긋지긋했던 data structure/hierarchy/cluster 등등..
아 또 너야.. 하면서 얼추 빠삭하니 설렁설렁 공부하려했지만,

까고보니 시각적인 관점에서의 이야기들이었고, 결국 내가 생각하지 못했던 포인트들을 줍줍하려고 열심히 듣게 된거 같음

Clustering in Design = Gestalt Principle

결국 정보의 성격이 비슷한 것 끼리 시각적으로 클러스터화하라는 건데,
이때, 게슈탈트 원리를 생각하며 논리적으로 설명 가능한 구조화가 중요한 것 같다.

이를 figma 및 design적인 term으로 설명하자면, Cluster는 스크린 내부에서 '정보의 성격'에 따라 분류된 Section 혹은 section내 Field정도로 이해하려고 한다.

왼쪽의 각 item들로 클러스터링 한다면,
product 자체의 정보를 담고있는 title,caption,별점으로 구성된 productCluster를 만들수 있겠고,
가격과 관련된 (할인율,정가,할인가) priceCluster,
배달과 관련된 정보들로 deliveryCluster,
마지막으로 User의 행동을 유도할 ctaCluster가 적당 할 것 같다.

현재는 ooooCluster로 네이밍 했지만, 실제 구성할때는 일반적으로 oooo_field로 리펙토링 할 것 같고,

scroll해도 sticky하게 보일 Thumbnail 및 product_field를 한 section / 그리고 ctaCluster역시 cta_section으로 정의할것 같다

(나머지 클러스터들은 그 아래 상세페이지_field, 연락처_field와 함께 body_section으로 정의 할듯)

Visual Hierarchy : 선흐름을 유도하는 시나리오를 써라!

출저 : Sparta

UX 디자이너는 위 처럼 시선의 Flow를 유도하는 시나리오를 써야된다 like 아귀

그리고 그걸 결정하는 것은 크게 세가지 : Typography, Color, Alignment

위의 세가지를 사용해서 왼쪽의 '항공편 검색' 페이지 내에서 시선을 유도하는 UI 만들기 실습을 진행했다.

어떤 요소를 강조하고, 어떠한 시선의 흐름을 생각하려면, 해당 페이지를 이해해야되는데, 사실 이 페이지가 어떤 페이지인지 명확하게 이해되지 않았다. (그러면 좋은 ui가 아니지 않을까?)

그래서 타 항공예약 어플을 탐색하면서 내 나름대로 저 화면을 이해해본다면,

첫 화면에서는 '검색', '여행 일정 선택', '버튼'의 형태로 구성되어있고,

해당 기입란들을 기입 후 '버튼'을 Tab하면 그에 해당하는 '여행 일정 목록'이 나온다.

이와 같은 생각으로 구성한 화면들은 우선적으로 다음과 같다.

우선 AppTitle 부분의 '항공편 검색'은 User가 한눈에 알아 볼 수 있어야 할 제목이기 때문에, 24p Semibold로 강조했다.

해당 화면에서 내가 생각한 시나리오는 다음과 같다.

1. 시선이 우선 중하단 여백으로 간 후, 위아래 버튼과 Navigtion Bar로 간다

-> 여기서 User는 '예약'의 Primary Color와 '가격 비교하기 버튼'의 Sementic Color를 확인 후, 다음과 같은 생각을 하게 된다.

"위 항목들을 작성하면 해당 버튼이 Primary Color로 바뀌며 활성화 되겠구나!"

2. 해당 항목들을 채울때마다, 각 란의 글씨의 투명도는 낮아져서 'task를 수행했다'라는 인식을 주고, 잘못 기입되었는지 여부를 명확히 확인하게한다.

3. 출발/도착이 바뀌는 버튼의 경우 해당 란들이 채워지면 Primary에 가까운 색으로 변하는데, 이는 '이제 해당 버튼을 누르면 위아래가 바뀝니다'를 의미한다

4. 모든 란을 채우면 '가격 비교하기 버튼'이 Primary Color로 바뀌며 활성화된다.

(여기서 각 icon크기/Font size,weight는 내일 수정하여 작성할 예정)

그리하여 가격비교하기를 누르면, 다음과 같이 해당 일정에 알맞은 항공편들이 '가격 비교하기'버튼을 밀어내고 activate된다.

해당 서비스에서 가장 중요한 요소는 '가격'이라고 판단했고, User에게 가장 중요한 요소는 이와 함께 '항공시간'이라고 판단했기에,

시선의 흐름을 가격 -> 항공시간으로 주려고 의도했다.

그리하여 가격은 붉은계열/Bold/24p, 항공시간은 짙은푸른계열/Semibold/20P로 설정했다.

그 중 가장 위 조건과 부합하거나, 가장 가격이 싼 항공편은 위 입력란과 같은 색으로 표현된다.

(sementic color이기 때문에, 더 채도가 있는 color로 할까 고민도 했으나, UI통일성면도 그렇고 '위 입력한 조건과 가장 연관된 조건이에요'라는 메시지를 주려면 같은 색도 괜찮다 판단하였다)

이에 더해 List내부에서 강조된 item의 Text는 투명도를 덜주어서 더 명확하게 표시하였다.

(그게 User입장에서 눈이 덜 아픈 design이라 판단했다.)

별거 한건 없어보이지만, 나름 나만의 고민이 들어간 결과이다.

오늘은 약 1년간 기다려온 오에이시스 보러 가야한다.

오늘은 여기서 마무리!

[10/18] 사실 디자이너가 아니라 아키텍트가 아닐까?

이로새박 — Mon, 20 Oct 2025 22:34:15 +0900

사실 디자이너가 아니라 아키텍쳐가 아닐까?

UX와 UI 관련 강의를 계속 듣다보니 자연스럽게 드는 생각이다.

예쁘고 균형 잡힌 Screen도 좋지만, 본질은 User의 액션을 우리의 의도대로 유도하는 것!

의도대로 흘러가기 위한 Flow를 논리적으로 설계하는 것이 매우 중요하고, 그걸 배워나가는 중이라는 것
사실 디렉터나 아키텍트나 디자이너나 요즘 세상에서는 다 한끗차이인 것 같다.

논리적인 행동흐름을 중심으로 고민해야하기 때문에, 이를 앞서간 기능중심 생각은 잘못된 접근이고,
이런 행동흐름이 goal에 부합하는지 데이터적 확인을하기 위해 여러가지 지표들이 있는데, 각 서비스 별로 가장 중요한 북극성 지표가 있는거고,

서비스	북극성 지수	Engagement game
배달의민족	주문 완료 건수	Transaction
유튜브	사용자 1인당 시청 시간	Attention
에어비앤비	예약 완료율	Transaction
토스	주간 활성 사용자 수(WAU)	Transaction
노션	워크스페이스 내 생성된 페이지 수	Productivity
왓챠	사용자 1인당 평균 감상 횟수	Attention

또 그런 핵심지표를 집중공략하기 위해 각 서비스마다 이득이 발생하는 영역/전략을 생각해야되는거고.

	Attention Game	Transaction Game	Productivity Game
예시 서비스	YouTube, Instagram	쿠팡, 배민	Notion, Slack, Figma
핵심 목표	오래 머무르게 하기	거래/구매 발생시키기	생산적인 활동을 완수하게 하기
인게이지 방식	피드 스크롤, 추천 콘텐츠	주문, 결제, 예약	문서 생성, 데이터 입력, 공유
UX 포커스	몰입(Flow)	속도(Speed)	완결성(Completion)
사용자 보상	재미, 자극	결과, 물질적 가치	성취감, 효율성

결국 거듭 말해, User의 task context/flow를 설계하는 architect가 UX 디자이너다! (UI는 그에 대한 도구일뿐)

오늘 공부를 통해 확실하게 이 한문장을 말할 수 있어서 후련하다

나는 UI 이전에, UX디자이너/아키텍트/디렉터가 되고싶다.

그 외에도 오늘 디자인 관련해서 실습한게 많지만,
쓸 내용이 많아서 내일로 미루는걸로

[10/17] 쿠팡이츠 바꿔보기!(2) : HMW/5whys로 아이디어 얻고, scoring으로 확정하기

이로새박 — Fri, 17 Oct 2025 20:51:35 +0900

문제 도출 과정 수정해보기

이전 글에서 문제를 도출하기 위한 aeiou 및 affinity mapping 을 진행했는데,
이처럼 진행하면, 수 많은 각기 다른 기능의 문제 및 아이디어가 도출되고, 나중에 이들을 어떻게 통합하여 UI및 UX를 수립해 나가야 할지 그림이 그려지지 않았다.
그래서 아래의 흐름으로 수정했다.

기존에 다음과 같은 기능별 5가지 리뷰 분류를 Affinity Mapping으로 정의했었는데,

Affinity Mapping은 결국 문제가 도출되어야 하는 과정이기도 하고, 또 기능별이 아니라 'User의 감정'을 토대로 분류하는 것이 좋다고 하더라고.

현재 나에게든, 현업에서든 큰기능 중 수정할 우선순위를 정해야 시간을 효율적으로 쓰기에, 위 과정의 네이밍만 다시하고 그대로 썼다.

그리고 그중 리뷰가 유용하다고 평가한 사용자가 가장 많으면서, 그 불만사항의 내용이 구체적인 결제/주문 process를 우선으로 분석-문제제시-아이디어-제작 하기로 했다.

우선 각 리뷰별로 aeiou를 진행, 그리고 인사이트를 도출했다.

이들은 모두 결제/주문 관련 인사이트 들이기에 다음과정에서 이들을 비슷한 성격끼리 묶어 User가 감정적으로 느끼는 문제를 제시 할 수 있었다.

위 3개의 문제로 도출되었다.

오늘 진행한 사항

위 도출된 3개의 문제에서 각각 HMW로 질문을 해가며 문제의 근본적인 이유를 찾았고, 이에 맞는 UI/UX적인 해결방안을 찾는 과정을 각3 개 질문마다 밟았다.

결국 2번째 문제의 질문은 얼마 안가 첫번째 문제의 중간 질문으로 귀결되었다.

그래서 결론적으로 1,2번째 문제에서 3개의 해결방안이 3번째 문제에서 하나의 해결방안이 나왔다.

그렇다고 4개의 아이디어를 그냥 구현하면 되나? 그건 아니었다.

결국 위의 문제들을 해결할려고 도출된 아이디어이기때문에 서로 보완되는 경우도 있지만,

둘다 같은 기능을 해결하기 때문에 문제가 되는 경우도 있다.

그래서 각 아이디어들이 구현될 때, 서로에게 어떤 관계인지 파악을 하고 들어가야했다.

그를 위해 사용한 Matrix가 위와 같으며, 결론은 이렇게 났다.

B ⊇ C : 쿠팡캐시 사용 여부에 “마지막 옵션 기억”을 흡수할 수 있음
A + B : 동시 구현 가능 (서로 보완)
D ⊇ B : Modal 안에 쿠팡캐시 옵션도 포함 가능
A ↔ D : 역할 상충 관계 → 둘 중 하나만 선택

결국 A와 D 둘중 하나만 선택하면 되는 문제였다.

이들 중 더 괜찮은 아이디어를 선택하기 위해서 HMW에서 필요해 보였던 기준을 6가지 가져와서 1-5점씩 매기는 Scoring board를 만들었다.

결국 A를 선택하게 되었다.

개인적인 사견이 들어갈 수 밖에 없는 의사결정 시스템이다.

그래서 나의 사견이 들어간 기준은 1.신속성 유지(BI)와 6.구현 난이도/비용 인 것 같다.

빠른 Process를 지향하는 쿠팡의 브랜드 이미지를 살리고 싶었던 의도로 현재 Product Design이 되었고, 이로 인한 사용자의 불편이었다. 이러한 요소를 최대한 보완하고싶었다.

그리고 A처럼 구현하는 것은 단순 한 개체(버튼)을 리디자인 하는 것이고, 추가적인 상황(페이지)가 생기지 않는다. 그렇기에, 개발자 입장에서는 기존에 있던 버튼 객체만 쿠팡의 것으로 쓱 바꾸면 되는것이라 10분이면 끝날 것이다

(사실 D도 데이터 적으로, 추가적인 사항이 필요한 것은 아니라서 크게 오래걸리진 않으나 A가 압도적일 것이다)

아래는 5분만에 만든 아주 조악한 리디자인 경우이다.

와이어프레임을 더 정교하게 만들지 못해 내생각을 도화지에 다 미쳐 못 옮긴게 아쉽다.

[10/15] 쿠팡이츠 바꿔보기!(1) : AEIOU와 Affinity Mapping으로 문제 정의하기

이로새박 — Wed, 15 Oct 2025 23:07:48 +0900

최근에, 현업에서 Customer Data를 기반으로 업데이트를 해나가는 과정에 대해 열심히 배웠다.

이를 Design Thinking이라고 하는데,

해당 과정을 '외식배달 서비스 개선'을 목표로 과제로 진행하게 되었다.

전체적인 해당 분야 서비스를 개선시켜도 되고, 하나만 정해서 개선해도 된다고 하는데,

나의 경우는 주로 사용하는 서비스인 'Coupang Eats'로 정해서 하는게 더 흥미있을 것 같았다.

나는 쿠팡이츠를 사용하면서 크게 불편한 적은 없었던 것 같은데, 확실히 다른 user들의 의견들을 조사하면서 알아가는게 많았다.

어떤 자료가 Design관점에서 필요할까?

제일 처음 막막했던 점은 생각보다 UX/UI와 관련된 댓글이 많이 없었다는 것이다.

내가 iPhone을 쓰기에 먼저 살펴보았던 Apple App Store에서는 다양한 리뷰를 보기가 힘들었고,

그렇다고 전면에 노출되어있는 댓글들은 대부분 쿠폰/무료배달과 관련된 것들이었다.

그래서 생각나는 것들 중에서 먼저 할수 있었던건, 다음 세가지였다.

1. 뉴스기사 확인 - 쿠팡이츠 현재 상황 살펴보기

2. 쿠팡이츠 UX/UI 직접 다뤄보기

3. 쿠팡이츠의 '자주하는질문' 확인하고, 실제 UX 경험해보면서 문제인점 찾아보기

new기사들

뉴스기사 확인을 통해 쿠팡이츠의 현재 이용자수/결제금액/점유율등의 상황이 긍정적이다라는 것을 알 수 있었고,

타 서비스와 비교했을때, '만나서 결제 가능여부'기능 구현이 안되겠구나 싶었다.

그러나 이러한 정보는 UX/UI와 관련이 없거나, 디자인적인 개선으로 해결이 불가능한 상황적 문제인 것 같았고,

또 실제 User의 목소리가 아니기에, 디자인 씽킹의 과정을 접목하기에는 크게 도움이 될 것 같지 않았다.

그래서 위 기사들에서 진행하기보다는,

"우선 그래도 진짜 User 중 한명인 내가 판단해보자! 내 의견도 정성적인 데이터아니야?"

그래서 UX/UI를 직접 꼼꼼하게 경험해보고 분석해보려했다.

그렇게 모든 것들을 경험해보려 노력하며, 약 40장의 캡쳐를 했다..

'더 이상 쓰지 않는 주소 삭제가 힘들다', '리뷰 관련 알림이 많다'등등의 나만의 인사이트는 얻긴했으나..

이들을 구체적으로 정리하는것은 결국 내 의견을 정리하는 것이고.. 이게 정말 현업처럼 실습하는 취지와 맞을까라는 의문도 들었고

무엇보다, 단 한명의 qualitative한 리뷰가 현실적인것 같지 않았다.

(그래도 추후 도움이 되긴했던 작업이었다.)

'자주하는질문'은 User들이 불편하다고 느끼고 CS팀에 문의한 것을 토대로 나온 FAQ라고 생각한다.

이말은 즉슨, 해당 내용들은 꽤 많은 User들의 의견이 반영된 '주된 문제'일 수 있다고 생각했다.

그래서, 이를 하나씩 읽어보던 중..

"플레이스토어 리뷰 많아요! 안드로이드 없어도 그냥 웹으로도 확인 가능해요!"

팀원분의 이 귀중한 말을 듣고 바로 리뷰를 직접보는 것으로 내 작업시선을 돌렸다.

리뷰가 아주 많았다! 서비스와 관련된 불만토로도 아주 많았다!
별점 역순으로 그러한 댓글들을 읽어나갔고, UI/UX와 관련성 있어보이는 댓글들은 모조리 스크랩했다.

그렇게 모은 리뷰들을 다시 한번 읽어보며, AEIOU적으로 관련있는 부분을 표시하다가,

표시하는 김에, 비슷한 종류끼리 분류도 해버리자!

라는 생각이 강하게 들었다. 그게 훨씬 효율적인 것 같았다.

(이후 팀원분들과 피드백 하는 과정에서 "이거 Affinity Mapping을 같이 해버린거 아니에요"라는 말을 듣고 그제야 그게 뭔지 제대로 이해가 좀 온 것 같았다)

그렇게 해서 리뷰들에서 내가 찾을 수 있는 주요 문제 상위그룹은 총 5개였다.

1. 바로결제/결제취소 관련

2. 연락 관련

3. 음식리뷰 탐색 관련

4. 알람/평점 관련

5. 매장 차단 기능 관련

이렇게 써보고 나니까 확실히 AEIOU전에 Affinity Mapping을 해버린 느낌이다.

서순이 바뀌었는데 그래도 되는거..겠지...?

어쨋든, 그런건 인지 못했던 과거의 무지한 나는

이 5항목을 중심으로 AEIOU를 진행하고, 각각의 인사이트를 짧게 도출해보았다.

깔끔하게 정리된 것 같은 느낌은 좋으나..

결국 이미 내 마음속의 문제로 5개를 Define 해버린 다음 다시 Define을 위해 분석하는, 서순이 맞지 않는 것 같은 나의 미천한 분석.

내일 튜터님께 들러서 이렇게 해도 되는지, 튜터님이 보는 문제점은 뭔지, 실효성 없어보이는 문제는 뭔지 알아봐야겠다.

기술의 발전은 UI도 낳는다 - 페이지네이션 vs 무한스크롤

이로새박 — Tue, 14 Oct 2025 21:02:21 +0900

https://ko.designus.design/topic/222

페이지네이션과 무한스크롤, 각각 어떤 의도를 가지고 있을까요? | 디자이너스

페이지네이션과 무한스크롤, 각각 어떤 의도를 가지고 있을까요?

ko.designus.design

오늘도 디자인 카타 시간에 흥미로운 주제를 다뤘다.

이번엔 우리가 늘 마주치는 두 가지 UI, 페이지네이션(Pagination)과 무한스크롤(Infinite Scroll)이었다.

(아래 내용은 다 개인의 머리속 생각을 풀어놓은거니 실제와 다른게 있을 수 있다)

페이지네이션: 기억의 UI

페이지는 사용자에게 일종의 **‘index’**다.

한 번 들어갔다 나온 컨텐츠를 다시 찾을 수 있게 하고, 사용자가 특정 컨텐츠의 위치를 기억할 수 있게 한다.

컨텐츠 성격: 정해진 순서(날짜, 업로드 순서)가 있는 게시물이나 커머스 상품에도 적합하다.
컨텐츠 형태: 한 row에 하나씩 나열된 리스트형 UI, 특히 썸네일이 없는 경우 잘 어울린다.
UX 맥락: 화면이 큰 데스크톱/태블릿에서 효과적이다.
사용자 경험: 컨텐츠를 다시 찾기 용이하지만, 다른 페이지로 넘어가는 클릭 액션이 필요하다. 따라서 유저의 의도적 탐색 없이는 컨텐츠 소비가 이어지지 않는다)

무한스크롤: 몰입의 UI

반면 무한스크롤은 각 컨텐츠의 순서와 위계를 의도적으로 숨기는 설계다.

특히 모바일 환경이 주류가 되면서, 작은 화면을 넓게 보이게 하는 효과를 주고, 사용자에게 자유로운 탐색감을 준다.

컨텐츠 성격: 순서나 위계보다는 추천·개인화된 소비가 중요한 서비스에 적합하다.
컨텐츠 형태: 썸네일 기반의 카드형 컨텐츠에서 효과적이다.
UX 맥락: 화면이 작은 모바일 환경에 어울린다.
사용자 경험: 다른 페이지를 누를 필요 없이 스크롤만으로 탐색이 이어진다. 따라서 빠른 의사결정과 다수의 컨텐츠 노출에 유리하다.

기술과 UI의 상관관계

페이지네이션과 무한스크롤의 차이는 단순한 UI 선택이 아니다.

페이지네이션은 질서와 기억을 강조한다.
무한스크롤은 몰입과 노출을 극대화한다.

AI와 머신러닝의 발달로, 이제 서비스는 사용자 개개인에게 맞춤형 컨텐츠를 제공한다.

그 결과, “목록 속에서 특정한 것을 찾기”보다 “관심 가는 것을 빠르게 소비하기”에 최적화된 무한스크롤이 점점 더 많은 서비스에서 쓰이고 있다.

오늘 분석을 통해 다시 한번 느꼈다.

기술의 발전은 결국 새로운 UI를 낳는다.

사용자의 행동과 디바이스 환경이 변하면, UI도 자연스럽게 그에 맞춰 진화한다.