오즈코딩스쿨 디자인 캠프 - 예쁜 화면이 전부가 아니었다 — 프로덕트 디자이너 직무부터 UI 구성 요소까지 (day10)

 

 

오늘 수업은 두 챕터로 나뉘었다. 앞부분은 프로덕트 디자이너라는 직무를 제대로 들여다보는 시간이었고, 뒷부분은 그 직무가 매일 다루는 UI 구성 요소를 하나씩 짚는 시간이었다. 결이 다른 두 주제 같지만, 둘 다 "예쁜 화면"이라는 막연한 인상을 한 꺼풀씩 벗기는 시간이라는 점에서 이어져 있었다.

솔직히 캠프를 시작하기 전엔 디자이너는 결국 보기 좋은 화면을 만드는 사람이라고 막연히 생각했다. 그런데 수업이 거듭될수록 그 생각이 자꾸 깨진다. 오늘은 그 깨짐이 가장 컸던 날이었다. 도구를 잘 다루거나 화면을 예쁘게 만드는 건 프로덕트 디자이너에게 필요한 역량의 일부일 뿐이라는 걸 다섯 가지 역량과 실제 채용 공고를 보면서 분명히 알게 됐고, 그 "화면"마저도 무수한 부품과 상태로 촘촘히 짜인 구조라는 걸 뒤 챕터에서 확인했다.

프로덕트 디자이너에게 필요한 다섯 가지 역량

좋은 디자이너가 되려면 보기 좋은 화면이나 능숙한 툴만으로는 부족하다는 이야기로 수업이 시작됐다. 강사님은 다섯 가지 역량을 꼽았는데, 어느 하나가 특별히 중요하다기보다 다섯이 균형을 이루는 게 핵심이라고 했다. 이 중 하나라도 크게 떨어지면 결국 결과물의 품질이 낮아진다는 것.

역량한 줄 정의핵심 키워드

문제 해결 능력	현상이 아니라 본질을 파고든다	정확한 정의, 가설, 반복
사용자 중심 사고	서비스의 주인은 디자이너가 아니라 사용자	리서치, 맥락, 공감
심미성	시각적 신뢰와 즐거움의 결합	첫인상, 일관성, 가독성
기능성과 실용성	고민 없이 다음 단계가 예측되는 설계	직관적 흐름, 조작 편의성, 단순함
커뮤니케이션	협업을 이끄는 디자인 언어	의도 설명, 피드백 수용, 공감대

문제 해결 능력은 "디자인은 문제를 풀어내는 과정"이라는 문장으로 요약됐다. 사용자가 결제를 자꾸 포기한다면 버튼 색을 바꿀까 고민하는 게 아니라, 왜 포기하는지부터 물어야 한다는 것. 정확한 정의 → 가설 설정 → 반복적 시도의 세 단계로 움직이는데, 이게 한 번에 끝나는 직선이 아니라 계속 되돌아오며 반복하는 과정이라는 점이 인상 깊었다.

현상만 보고 바로 해결책으로 달려가지 말고, "왜?"라는 질문을 반복하면서 진짜 원인을 파악해야 한다.

이 대목에서 간호사로 일하던 시절이 겹쳤다. 환자가 약을 자꾸 거른다고 할 때, 약을 더 예쁜 컵에 담는다고 해결되진 않았다. "왜 안 드세요"부터 물어야 삼키기 힘든 건지, 부작용이 무서운 건지, 시간을 잊는 건지가 보였다. 표면 현상이 아니라 원인을 먼저 보는 그 감각이 디자인의 첫 단추와 정확히 같은 결이라는 생각이 들었다.

사용자 중심 사고의 핵심 문장은 "우리가 만드는 서비스의 주인은 디자이너가 아니라 사용자"라는 것이었다. 은행 앱 하나를 두고도 20대 대학생은 간편송금이, 60대 은퇴자는 연금 관리가 주된 목적이 된다. 같은 도메인, 같은 앱이라도 어떤 사용자를 중심에 두느냐에 따라 화면의 목표와 구조가 달라진다.

내가 이걸 좋아하는가가 아니라, 이 사용자가 이 상황에서 무엇을 가장 필요로 하는가를 먼저 물어야 한다.

심미성은 그냥 보기 좋게 만드는 게 아니라 시각적 신뢰와 직결된다는 이야기였다. 잘 정돈된 화면은 사용자에게 신뢰를 주고 브랜드 이미지를 끌어올린다. 첫인상이 0.05초 만에 형성된다는 이야기는 day8에서 배운 본능적 단계와 그대로 이어졌고, 보기 좋은 디자인이 실제로 더 사용하기 좋다고 인식되게 만드는 심미적-사용성 효과까지 다시 등장했다. 깔끔한 레이아웃, 세련된 색감, 일관되고 가독성 있는 타이포그래피가 여기에 쓰인다.

기능성과 실용성은 직관적인 흐름, 조작의 편의성, 단순함의 미학 세 가지로 정리됐다. 직관적인 흐름은 사용자가 고민하지 않고도 다음 단계를 예측할 수 있는 설계다. 다음에 뭘 눌러야 할지 고민하게 만드는 화면은 (의도한 게 아니라면) 좋은 화면이 아니라는 것. 불필요한 요소를 걷어내고 핵심 기능에 집중하게 하는 단순함도 여기 들어간다.

커뮤니케이션은 마지막이지만 정말 중요하다고 강조됐다. 디자이너는 개발자, 기획자, 마케터 사이에서 최선의 결과물을 조율하는 중재자다. 혼자 완벽한 화면을 만들어도 팀과 소통이 안 되면 좋은 프로덕트가 나오기 어렵다. 의도 설명(결정의 근거 전달), 피드백 수용(구현 난이도·비즈니스 방향 존중), 공감대 형성(같은 목표를 공유하기)이 핵심이다. 다른 직군과 대척점에 서는 게 아니라, 모두가 사용자의 문제를 해결한다는 하나의 방향으로 가도록 이끄는 일이라는 말이 와닿았다.

피그마가 정의하는 제품 디자인 프로세스

피그마 공식 자료로 제품 디자인 프로세스도 짚었다. 비즈니스 모델을 시각화하고 사용자 요구를 구조화하는 전략적 과정으로 정의되는데, 다섯 단계로 나뉜다.

단계핵심

목표 설정	제품 목표를 조직의 방향성과 일치시킨다
리서치	데이터 기반 인사이트로 타깃 사용자를 이해한다
제품 전략·기획	비즈니스 목표 달성을 위한 디자인 전략을 제안한다
실행	개발 협업과 QA로 구현 완성도를 높인다
출시 이후	시장에 안착시키고 지속적으로 보완한다

가장 중요한 포인트는 이 단계가 한 번만 일어나는 직선이 아니라 출시 이후에도 계속 반복되는 사이클이라는 것이다. 리서치를 해보니 목표 수정이 필요하다면 언제든 이전 단계로 돌아갈 수 있는 유연함이 필수다. 전통적인 디자인이 "출시하면 끝"이었다면, 제품 디자인은 출시 이후 사용자가 어떻게 쓰는지 보고 계속 보완하는 중장기적 관점을 가진다.

UX와 UI, 그리고 제품 디자인의 자리

이 프로세스를 이해하려면 UX·UI·제품 디자인의 관계를 구분해야 했다.

구분초점범위

UI 디자인	시각적 구현, 픽셀 단위 정밀도, 심미적 감각	좁음
UX 디자인	사용성, 사용자 중심 관점	중간
제품 디자인	비즈니스·전략·사용자 경험 전체	넓음

UI가 화면의 시각적 완성도에 집중한다면, UX는 그보다 넓게 사용성과 사용자 경험을 다룬다. 제품 디자인은 더 큰 그림을 본다. 화면뿐 아니라 그 이면의 전략, 비즈니스 목표, 프로젝트 관리, 로드맵, ROI(투자 대비 수익률)까지 만나는 지점에서 움직인다. 강사님은 프로덕트 디자이너를 기획자 관점에 UX·UI 디자인까지 확장된 역할로 정리했고, 연차가 쌓여 PM·PO로 올라갈수록 장기적인 비즈니스 비전이 더 중요해진다고 했다.

채용 공고(JD)로 직무를 읽다

직무를 머리로만 이해하는 대신, 실제 채용 공고(JD)를 보며 기업이 어떤 디자이너를 원하는지 확인했다. 먼저 강사님이 가져온 두 공고를 봤다.

토스의 프로덕트 디자이너 공고는 권한과 책임이 모두 큰 자리였다. 디자이너를 사일로 단위의 작은 CEO로 보고, 6~8명 팀이 독립적으로 움직이며, 리서치·라이팅은 전문가가 돕지만 최종 결정은 디자이너가 한다.

제품의 1인 디자이너로서 모든 화면을 주도적으로 설계하고 의사결정한다. 별도 승인이나 보고는 필요 없다.

요구 역량은 세 가지로 읽혔다. 데이터 기반 문제 해결(내가 원하는 게 아니라 사용자가 원하는 걸 데이터로 증명하기), 뛰어난 UI 완성도(위계가 명확하고 조형적으로 완벽한 화면), 논리적인 협업 능력(팀을 설득하고 데이터로 디자인을 평가·개선하기)이다. 포트폴리오 팁으로 As-is/To-be 전후 화면 비교와 창의적인 문제 해결 사례를 요구한다는 점도 참고할 만했다.

배달의민족 UX 리서처 공고는 결이 달랐다. 리서치 방법론으로 진짜 문제를 발굴·정의하고, 해결 방향을 실행 가능한 수준으로 제시하며, 조직에 리서치 문화를 확산하는 역할이었다. 핵심 역량은 문제 정의 능력, 실행으로 연결하는 능력, 커뮤니케이션으로 정리됐다.

같은 직무, 다른 얼굴 — 공고 뜯어보기

이어서 각자 관심 직무의 공고를 직접 분석했다. 같은 "프로덕트 디자이너"라는 이름인데 회사마다 얼굴이 꽤 달랐다.

회사서비스프로덕트 디자이너에게 요구하는 결

문토	취향 기반 커뮤니티 플랫폼	전방위 — 브랜딩·마케팅·운영까지
포스타입	창작자 플랫폼	UX 설계·디자인 시스템 중심
코니	글로벌 육아 브랜드	UX/UI에 치중, 콘텐츠 디자인 포함
당근	지역 커뮤니티	그로스·제품 간 연결 구조 중심

문토는 스타트업답게 업무 범위가 넓어서, 화면 설계뿐 아니라 브랜딩, 마케팅(캠페인·상세 페이지·랜딩·배너), 출시 이후 운영까지 다뤄야 했다. 포스타입은 비교적 프로덕트 디자이너 본연의 역할에 집중돼 있고 디자인 시스템 구축·운영을 강조했다. 코니는 글로벌 육아 브랜드(연매출 820억 원)로 자체 사이트의 UX 설계와 UI 디자인, 콘텐츠 디자인까지 맡는 UX/UI 치중형이었다. 당근은 화면 하나보다 유저 행동의 흐름과 제품 간 연결 구조 전체를 보는 그로스 관점이 강했다.

가장 크게 남은 깨달음은 이거였다. 스타트업은 거의 전방위로 일하고, 대기업은 프로덕트 디자이너 안에서도 검색·결제처럼 분야가 세분화돼 있다. 그러니 포트폴리오나 자소서를 하나 완성해 모두에게 똑같이 보내는 게 아니라, 가고 싶은 곳의 JD를 계속 들여다보며 맞춰가야 한다.

포트폴리오 하나를 완성해 다 보내지 말고, 공고에 맞춰 어떤 프로젝트를 앞에 두고 무엇을 넣고 뺄지 조정해야 합격 확률이 높아진다.

공고를 찾는 플랫폼으로는 원티드와 사람인 등이 소개됐다.

<!-- 필기 공백: 강사님이 채용 플랫폼 네 곳을 언급했는데, 녹음에서 원티드·사람인 두 곳만 분명히 들렸고 나머지 두 곳 이름이 정확히 잡히지 않았음(서핏/직행 등으로 추정되나 불확실). 확인 후 채워 넣을 것. -->

현직자의 이야기 — 두 영상

수업 후반에는 현직자 인터뷰 영상 두 편을 봤다. 첫 번째는 현직 프로덕트 디자이너들의 Q&A였다. 가장 중요한 역량으로 "문제를 찾는 것"을 꼽은 게 기억에 남는다.

무엇이 문제인지 모르는 게 진짜 문제다.

엉뚱한 문제를 정의하면 아무리 잘 풀어도 진짜 문제는 그대로 남는다는 이야기였다. 사수가 없을 때의 공부법도 현실적이었다. 내 도메인의 앱을 전부 받아 장단점을 정리해 흡수하고, 잘하는 회사의 디자인 팀이 공개하는 콘텐츠를 꾸준히 팔로업하라는 것. 그리고 레퍼런스 이야기가 또 나왔다. 좋은 레퍼런스를 그냥 따라 그려봐도 표절이 될 뿐, 왜 좋은지부터 정의하고 기록하는 게 시작이라는 말은 day6에서 다짐했던 것과 정확히 같아서 더 와닿았다.

두 번째 영상은 AI 시대의 PM에 대한 이야기였다. PM의 핵심은 결국 고객과 시장에 대한 이해이고, 그 역할은 AI가 하든 누가 하든 상관없으니 그 역량에서 최고가 되지 않으면 대체될 수 있다는 다소 서늘한 이야기였다. 유저를 이해하는 방법으로는 계속 물어보고, 실제 행동을 곁에서 관찰하라고 했다("마지막으로 영수증 처리 언제 하셨어요?"처럼 구체적인 경험을 묻는 식이다). AI 시대의 PM은 기술이 지금 어디까지 가능한지 직접 테스트해보고 한계를 설정하는 의사결정이 중요해진다는 점도 짚었다.

 

 

매일 쓰던 화면에, 이름을 붙이다

직무를 큰 그림으로 본 뒤, 수업 후반은 그 그림을 이루는 작은 부품들로 내려왔다. UI 구성 요소를 하나씩 짚는 시간이었는데, 평소 앱을 쓰며 무심코 눌렀던 것들에 이름을 붙이는 작업이라 익숙한데 낯선 묘한 시간이었다. 분명 매일 봤는데 이름은 몰랐던 것들이 대부분이었다. 강사님은 이 요소들을 다섯 갈래로 나눴다.

갈래역할

탐색과 이동	지금 어디에 있고 어디로 갈 수 있는지 알려준다
입력과 선택	사용자가 직접 입력·선택·전환한다
콘텐츠와 정보 표시	정보를 어떻게 묶고 보여줄지 결정한다
상태·피드백·오버레이	시스템이 사용자에게 반응을 돌려준다
패턴·심화	여러 요소가 조합된 구조를 만든다

탐색과 이동 UI

사용자가 지금 어디에 있고 다음에 어디로 갈 수 있는지 이해하게 만드는 요소들이다. 아무리 좋은 콘텐츠가 있어도 내가 어느 화면, 어느 단계에 있는지 모르면 사용자는 혼란스러워하고 결국 이탈한다.

요소역할메모

브레드크럼	진입 경로를 보여주는 위치 표시	깊은 구조의 PC·웹에 적합, 모바일은 뒤로 가기로 대체
페이지네이션	긴 목록을 페이지로 나눠 위치·범위 표시	게시판·상품 목록·검색 결과
무한 스크롤	스크롤할수록 콘텐츠가 자동 로드	콘텐츠 몰입형(인스타·유튜브), 위치 파악은 어려움
메뉴(햄버거·미트볼·벤토)	숨긴 메뉴·옵션을 여는 아이콘	생김새에 따라 이름이 다름

브레드크럼은 직역하면 "빵 부스러기"인데, 헨젤과 그레텔이 숲에서 길을 잃지 않으려 빵 부스러기를 흘린 것처럼 진입 경로를 보여준다는 이름이라 한 번에 외워졌다. 페이지네이션과 무한 스크롤은 어느 쪽이 좋고 나쁘다기보다 서비스 목적에 따라 고르는 문제다. 콘텐츠에 계속 몰입하게 하려면 무한 스크롤이, 특정 위치로 다시 돌아가야 한다면 페이지네이션이 낫다. 메뉴 아이콘은 멘탈 모델이 핵심이었다. 햄버거(가로줄 세 개)는 전체 메뉴, 미트볼(점 세 개)은 추가 옵션, 벤토(격자)는 여러 앱·도구를 떠올리게 한다. 생김새가 곧 기대를 만든다는 게 흥미로웠다.

입력과 선택 UI

사용자가 직접 입력하고, 고르고, 상태를 바꾸는 인터랙션 요소들이다. 로그인, 결제 정보 입력, 설정 변경 같은 화면에서 주로 쓰인다.

요소역할메모

검색 필드	원하는 정보로 바로 접근	플레이스홀더·안내 텍스트로 입력을 돕는다
버튼	행동을 시작하는 기본 요소	프라이머리·세컨더리·비활성 위계
인풋 필드	텍스트 입력 폼	라벨·플레이스홀더·헬퍼·에러 4요소
체크박스	복수 선택	전체 동의 연동 설계 필요
라디오 버튼	단일 선택	결제 수단처럼 하나만 골라야 할 때
토글 스위치	켜짐/꺼짐 상태 전환	현재 상태가 명확히 보여야
칩	가벼운 선택지·태그	필터·빠른 선택
셀렉트·드롭다운	옵션 중 하나 선택	공간 절약

버튼은 위계가 중요했다. 화면에서 가장 중요한 행동은 브랜드 컬러의 프라이머리 버튼으로, 부차적인 행동은 세컨더리 버튼으로 둔다. 구매하기가 프라이머리라면 장바구니 담기는 세컨더리가 되는 식이다. 누를 수 없는 상태는 회색 비활성 버튼으로 보여준다.

인풋 필드는 라벨, 플레이스홀더, 헬퍼 텍스트, 에러 텍스트 네 가지를 잘 설계해야 한다. 라벨은 무엇을 입력하는 칸인지, 플레이스홀더는 입력창 안의 흐릿한 예시(name@example.com처럼), 헬퍼는 하단의 보조 안내, 에러는 잘못 입력했을 때 뜨는 메시지다. 이걸 잘 짜두면 사용자가 무엇을 어떻게 입력할지, 에러가 났을 때 어떻게 대응할지를 바로 알 수 있어 사용성과 곧장 연결된다.

체크박스와 라디오 버튼의 차이는 꼭 기억해 두라고 했다. 체크박스는 복수 선택, 라디오 버튼은 단일 선택이다. 특히 체크박스는 "전체 동의"를 눌렀을 때 하위 항목이 모두 켜지고, 하위 하나를 끄면 전체 동의도 풀리는 식의 세부 인터랙션까지 디자이너가 분기별로 설계해야 한다. 이런 엣지 케이스를 빠짐없이 챙기는 게 프로덕트 디자이너의 일이라는 걸 처음 실감했다.

토글 스위치는 지금 켜진 상태인지 꺼진 상태인지가 명확해야 한다. 켜짐을 초록색, 꺼짐을 연한 회색으로 구분하면 분명한데, 켜져 있어도 회색으로 표시되면 헷갈려서 한 번 더 눌러보게 된다. 강사님도 맥북 설정에서 이걸 자주 헷갈린다고 했는데, 나도 똑같았다. 사소해 보여도 상태를 명확한 신호로 보여주는 일이 중요하다는 게, 간호 기록에서 투약 여부를 한눈에 보이게 표시하던 일과 닮았다는 생각이 들었다.

콘텐츠와 정보 표시 UI

정보와 콘텐츠를 사용자에게 어떻게 묶고 보여줄지 결정하는 요소들이다. 같은 정보라도 어떻게 그룹화하고 표시하느냐에 따라 가독성이 크게 달라진다.

요소역할메모

아코디언	접고 펼치며 정보 표시	FAQ에서 자주, 한 항목 열면 다른 건 닫을지 설계
캐러셀	가로로 넘기는 콘텐츠	뒤로 갈수록 클릭률 급감, 중요 정보를 숨기지 말 것
카드	관련 정보를 한 덩어리로 묶음	밀러의 법칙(청킹)과 연결
리스트·테이블	목록·비교 표시	순서대로면 리스트, 열 비교면 테이블(어드민)
아이콘	빠르게 의미를 전하는 시각 언어	단독은 모호, 텍스트·툴팁 병행, 일관성
프로필·아바타	사용자를 시각적으로 구분	이미지 없을 땐 이니셜·기본 이미지

아코디언은 악기 아코디언처럼 접었다 펼치는 데서 온 이름이다. 정보량이 많지만 한 화면에 다 펼칠 필요는 없을 때, 제목만 노출하고 클릭하면 펼쳐지게 한다. 캐러셀은 가로로 넘겨야 보이는 만큼 첫 슬라이드의 클릭률은 높지만 두 번째, 세 번째로 갈수록 급격히 낮아진다. 그러니 중요한 정보를 뒤쪽 슬라이드에만 숨겨두는 건 피해야 한다. 카드는 제목·설명·가격·버튼처럼 관련된 정보를 하나의 단위로 묶는 요소인데, day8에서 배운 밀러의 법칙(청킹)과 자연스럽게 이어졌다. 아이콘은 텍스트보다 빠르게 인식되지만 단독으로는 의미가 모호해질 수 있어, 텍스트를 함께 두거나 툴팁을 붙이고 같은 라이브러리에서 일관되게 쓰는 게 좋다.

상태·피드백·오버레이 UI

사용자의 행동에 반응하고, 현재 상태를 알려주고, 집중을 유도하는 요소들이다. 시스템이 피드백을 주지 않으면 사용자는 버튼이 눌린 건지, 다시 눌러야 하는지 몰라 불안해진다.

요소역할메모

배지	상태·수량을 작게 붙여 표시	99 초과는 99+로 표기
툴팁	보조 설명을 담은 작은 상자	호버·롱프레스, 모바일은 호버가 없음
토스트·스낵바	잠깐 떴다 사라지는 알림	작업 흐름을 끊지 않음, 노출 시간 설계
모달 다이얼로그	화면 위에 겹쳐 집중을 유도	되돌릴 수 없는 결정에만, 남발 금지
로더·스피너	처리 중임을 표시	짧은 대기, 스켈레톤 방식도
프로그레스 바	진행률을 눈으로 보여줌	멈추면 답답, 속도 불규칙하면 로더가 나음
빈 상태(엠티 스테이트)	내용 없을 때 다음 행동을 안내	"장바구니가 비었어요" + 둘러보기 버튼, 404 등

배지는 카카오톡 안 읽은 메시지 개수처럼 작지만 "확인할 게 있다"는 신호를 효율적으로 전한다. 다만 숫자가 세 자리를 넘으면 레이아웃이 틀어지니 99를 넘으면 99+로 표기하는 규칙까지 정해야 한다. 모달은 정말 중요했다. 되돌릴 수 없는 삭제 같은 중대한 결정에만 써야 하고, 모든 확인을 모달로 띄우면 사용자가 무감각해져 진짜 중요한 순간에도 휙 보고 버튼을 눌러버린다. 로더·스피너는 "처리 중"만 보여주고, 프로그레스 바는 "얼마나 진행됐는지"를 보여준다는 차이가 있다. 빈 상태는 그냥 비워두면 사용자가 멈추거나 이탈하니, 왜 비었는지와 다음에 뭘 하면 좋을지를 함께 안내해 다음 행동으로 연결해야 한다. 404나 시스템 점검 같은 에러 페이지도 디자이너가 설계해야 할 상태라는 점이 새로웠다.

패턴·심화 UI

앞의 요소들이 부품이라면, 이 갈래는 부품을 조합한 구조물이다. 여러 요소가 하나의 목적을 위해 묶인 패턴을 다룬다.

요소역할메모

폼	여러 입력 요소가 한 목적으로 묶인 패턴	흐름·오류 타이밍·유효성 검증까지
피커(데이트 피커)	특정 값을 골라 입력	직접 입력보다 오류가 적음
슬라이더	연속적인 값을 조절	모바일은 터치 타깃 크기 고려
스테퍼	한 단계씩 증감	장바구니 수량 변경
FAB(플로팅 액션 버튼)	화면 위에 떠 있는 주요 행동	주목성이 강해 하나만

폼은 개별 요소보다 흐름이 중요하다. 입력 순서, 오류 처리, 완료 버튼까지 한 덩어리로 설계하고, 특히 오류 메시지를 띄우는 타이밍을 신경 써야 한다. 아직 입력 중인데 바로 에러가 뜨면 거슬리니, 최소한의 입력이 완료된 뒤 띄우는 식의 유효성 검증 타이밍까지 폼 작업에 포함된다. 데이트 피커는 사용자가 직접 날짜를 타이핑하면 형식도 제각각이고 불가능한 날짜도 들어오지만, 달력에서 고르게 하면 불가능한 날짜를 막을 수 있어 더 안전하다. 슬라이더는 모바일에서 핸들이 너무 작으면 조작이 어려우니 터치 타깃 크기를 신경 써야 한다(구글 머티리얼 디자인에서 최소 크기를 확인할 수 있다). FAB는 항상 엄지 가까이 떠 있어 주목성이 강한 만큼, 진짜 중요한 행동 하나에만 써야 한다.

다 강조하면 결국 아무것도 강조되지 않는다.

헷갈리는 용어 정리

비슷해 보이는 용어들을 마지막에 다시 짚었다. 실무에서도 혼용되는 경우가 많아 정확히 구분해 두면 커뮤니케이션이 분명해진다고 했다.

용어한 줄 구분

모달	화면 위에 떠서 입력·확인을 요구. 닫기 전엔 뒤 화면을 조작할 수 없음
팝업	새 창·작은 영역으로 잠시 등장. 뒤 화면을 조작할 수 있음
드롭다운	평소엔 숨었다가 선택하면 옵션이 펼쳐짐
아코디언	제목만 보이다가 접고 펼침
라디오 / 체크박스	라디오는 단일 선택, 체크박스는 복수 선택
툴팁	호버·클릭 시 뜨는 보조 설명
토스트	잠깐 떴다가 사라지는 알림

가장 헷갈렸던 건 모달과 팝업의 차이였다. 둘 다 기존 화면 위에 새 레이어를 띄우지만, 모달은 닫거나 확인하기 전까지 뒤 화면을 조작할 수 없고, 팝업은 떠 있어도 뒤 화면으로 돌아가 조작할 수 있다는 점이 달랐다.

실습 — 익숙한 화면에 이름표 붙이기

과제는 피그마 파일에 흩어진 UI 요소에 이름을 붙이고, 오늘 배운 다섯 갈래로 분류하는 것이다. 심화 과제는 내가 자주 쓰는 앱을 캡처해 UI 용어를 직접 작성해보는 것. 컴포넌트의 용도와 상태값은 구글 머티리얼 디자인에서 자세히 확인할 수 있다고 해서, 참고 자료로 함께 챙겨두기로 했다.

정리하며

오늘의 결론은 제목 그대로다. 예쁜 화면이 전부가 아니었다. 문제를 정의하고, 사용자를 이해하고, 팀을 설득하고, 비즈니스까지 고민하는 일이 모두 디자이너의 몫이라는 걸, 다섯 가지 역량과 여러 공고를 통해 분명히 봤다. 특히 환자를 볼 때 "왜"부터 묻던 습관이 디자인의 첫 단추인 문제 정의와 같은 결이라는 걸 알게 된 게 가장 컸다. 직무를 바꿨다고 생각했는데, 의외로 이어지는 감각이 있다는 게 묘하게 든든하다.

뒤 챕터의 UI 요소들도 결국 같은 이야기로 모였다. 화면 하나에도 켜짐과 꺼짐, 빈 상태, 에러, 로딩 같은 수많은 경우를 빠짐없이 설계해야 한다는 점이 가장 인상 깊었다. 사용자에게 보이는 매끈한 화면은 빙산의 일각이고, 그 아래엔 "이때는 이렇게, 저때는 저렇게"를 정해둔 무수한 분기가 깔려 있었다. 환자에게 일어날 수 있는 모든 경우 — 부작용, 예외 상황, 응급 — 를 미리 떠올리고 대비하던 일이, 화면의 모든 상태를 설계하는 일과 닮았다는 생각이 들었다. 좋은 설계는 눈에 보이지 않는 곳을 얼마나 촘촘히 챙겼느냐에서 갈리는 모양이다.

당장의 다짐은 세 가지다. 관심 있는 직무의 JD를 여러 개 모아 캠프 기간 동안 집중해서 키울 메인 역량을 정해보는 것. 자주 쓰는 앱을 하나 골라 캡처하고 각 요소에 오늘 배운 이름을 붙여보는 것. 그리고 day6에서 시작한 습관 — 좋다고 느낀 레퍼런스는 저장만 하지 말고 왜 좋은지 한 줄이라도 적어두는 것 — 을 계속 이어가는 것. 도구는 바뀌고 직무는 확장되겠지만, 문제를 보는 눈과 기록하는 습관은 남을 테니까.