Showing Posts From

Uiux

지라 티켓을 열었을 때 처음부터 느껴지는 중력

지라 티켓을 열었을 때 처음부터 느껴지는 중력

지라 티켓을 열었을 때 처음부터 느껴지는 중력 아침 9시 40분. 노트북을 켰다. 슬랙 알림 27개. 일단 무시. 피그마 먼저 켜야지... 했는데 손이 지라로 간다. 이게 루틴이다. 매일 아침의 의식. 지라를 열면 무언가 내려앉는 기분이 든다. 중력 같은 거.티켓 숫자가 곧 무게 오늘 내 이름이 붙은 티켓은 14개. In Progress 5개, To Do 7개, Review 2개. 숫자만 봐도 어깨가 무겁다. 티켓 하나하나가 돌멩이 같다. 배낭에 담긴 돌. 하나씩 꺼내야 집에 갈 수 있다. 기획자 민준이가 어제 저녁에 티켓 3개를 더 만들었다. Priority: High. Due date: 이번 주 금요일. 금요일이 3일 남았는데 High가 3개. 이미 High가 5개였는데. High의 인플레이션.지라 없을 때가 더 나았다는 생각을 한다. 그땐 슬랙으로 요청 받고, 노션에 리스트 만들고. 지금? 티켓이 날 찾아온다. Assignee: 최디자. 체계가 주는 압박 지라는 투명하다. 너무 투명해서 문제다. 내가 뭘 하고 있는지 다 보인다. 얼마나 안 하고 있는지도 다 보인다. 월요일에 만든 티켓이 아직 In Progress에 있으면 대표님이 스탠드업 미팅에서 물어본다. "디자 씨, 이거 진행 상황이...?" 그럼 나는 말한다. "아, 네. 거의 다 됐어요. 오늘 올릴게요." 거짓말이다. 50%도 안 했다. 근데 티켓 상태는 정직하다. Updated: 3 days ago.개발자 서진이는 티켓을 빠르게 처리한다. 하루에 5개씩 Done으로 옮긴다. 나는 하루에 2개 하면 잘한 날이다. 디자인은 시간이 걸린다고 변명하고 싶다. But 티켓은 물어보지 않는다. Story Point: 3. Due date: 2024-01-25. 그게 전부다. 우선순위의 혼란 High가 8개면 뭐가 먼저인가. 전부 High면 전부 긴급이면 뭐가 긴급인가. 나는 기획자들에게 물었다. "이 중에 진짜 먼저 해야 하는 거 뭐예요?" 민준: "음... 다 중요한데..." PM 수현: "일단 대시보드 개편이 제일 급해요." 대표님: "결제 플로우 먼저 보고 싶은데." 세 개 다 High Priority다. 결국 내가 정해야 한다. 그래서 지라를 닫았다. 우선순위를 정하려면 지라를 보면 안 된다. 지라를 보면 티켓만 보인다. 티켓 너머의 맥락은 안 보인다. 나는 노션을 켰다. 내 개인 페이지에 정리했다.이번 주 목표: 결제 플로우 완성 내일까지: 대시보드 와이어프레임 다음 주: 마이페이지 개편그리고 지라 티켓에 코멘트를 달았다. "이번 주 금요일까지 어려울 것 같아요. 다음 주 화요일 가능할까요?" 민준이 답했다. "네, 괜찮아요!" 아니 그럼 왜 Due date를 금요일로 잡았나. 완료의 쾌감, 미완의 죄책감 티켓을 Done으로 옮길 때 기분이 좋다. 드래그해서 Done 컬럼에 떨어뜨리면 뭔가 사라지는 기분. 돌멩이 하나 꺼낸 기분. 근데 그 기쁨은 2초다. To Do 컬럼에 새 티켓이 2개 생겼다. 자동 생성 봇이 만든 반복 작업 티켓. "Weekly Design System Update" 이 티켓은 매주 생긴다. 나는 매주 Skip한다. 누가 디자인 시스템 업데이트를 궁금해하나. 개발자들은 내가 만들어둔 컴포넌트도 안 쓴다. Done 컬럼에 쌓인 티켓을 볼 때는 뿌듯하다. 이번 스프린트에 12개 완료. 지난주보다 2개 많다. 근데 바로 다음 스프린트 티켓이 보인다. 15개. 끝이 없다. 시스템이 사람을 만들 때 지라를 쓰기 전에는 일이 더 자유로웠다. 뭘 할지 내가 정했다. 물론 무질서했다. 놓치는 것도 많았다. 지금은? 티켓이 날 정한다. Assignee로 지정되면 해야 한다. Due date가 지나면 빨갛게 변한다. 체계는 도움이 된다. 맞다. 안 까먹는다. 명확하다. But 체계 때문에 내가 사라진다. 예전엔 아침에 출근해서 생각했다. "오늘은 이 페이지 디자인을 예쁘게 만들어보자." 지금은 생각한다. "오늘은 High Priority 3개를 처리하자." 디자인이 티켓이 됐다. 예쁘게 만드는 게 목표가 아니라 티켓을 닫는 게 목표가 됐다. 개발자 서진이가 말했다. "지라 보면 일한 것 같은데 실제론 별로 안 한 느낌 들지 않아요?" 맞다. 티켓은 완료했는데 성취감은 없다. Done은 늘었는데 작품은 없다. 중력을 견디는 방법 나는 지라를 하루에 세 번만 본다. 아침, 점심, 퇴근 전. 그 외 시간엔 피그마만 켠다. 티켓을 보지 않고 디자인을 본다. 물론 슬랙에서 티켓 링크가 날아온다. "@디자 이 티켓 확인 부탁드려요." 나는 이모지로 답한다. 👍 나중에 본다. 오후 3시부터 6시까지는 딥 워크 시간이다. 슬랙 알림 꺼둔다. 지라 탭 닫는다. 미팅 잡지 말라고 캘린더에 써뒀다. 이 시간에는 티켓이 아니라 결과물을 만든다. Figma 파일을 연다. 색을 고른다. 레이아웃을 잡는다. 이때가 진짜 일하는 시간이다. 6시에 지라를 다시 연다. 완성한 걸 티켓에 업로드한다. 코멘트를 단다. "초안 완성했습니다. 피드백 부탁드려요." 그럼 티켓이 Review로 간다. 내 손을 떠난다. 가벼워진다. 체계성이 도움이 되려면 지라가 나쁜 건 아니다. 체계가 나쁜 건 아니다. 문제는 체계에 먹히는 거다. 티켓이 일이 되는 거다. 체계는 도구여야 한다. 내가 일을 정리하는 도구. 일이 나를 정리하는 시스템이 아니라. 나는 이제 이렇게 한다. 월요일 아침, 지라를 연다. 이번 주 티켓을 본다. 그리고 내 노션에 옮긴다. 노션에서 내 언어로 정리한다.결제 플로우 개선: 사용자가 덜 헷갈리게 대시보드 재배치: 정보 위계 명확하게 마이페이지: 개인화 느낌 강화티켓 번호는 안 쓴다. Due date도 안 쓴다. 내가 할 일을 내 언어로. 그리고 일한다. 완성되면 지라에 올린다. 지라는 기록이다. 과정이 아니라. 나는 피그마에서 일한다. 지라에서 일하지 않는다. 중력은 있다, 눌리지 않으면 된다 지라를 열 때마다 중력이 느껴진다. 여전히. 티켓 숫자가 무겁다. 여전히. But 이제는 안다. 중력에 눌려 있을 필요는 없다는 걸. 티켓은 요청이다. 명령이 아니라. Due date는 목표다. 마감이 아니라. Priority는 제안이다. 절대값이 아니라. 나는 디자이너다. 티켓 처리하는 사람이 아니라. 지라는 내가 만든 걸 기록하는 곳이다. 내가 지라를 채우는 거다. 지라가 나를 채우는 게 아니라. 오늘도 티켓 3개를 Done으로 옮겼다. 결제 플로우 개선안 완성. 사용자가 덜 헷갈리는 걸 만들었다. 티켓은 완료됐고 작품도 나왔다.체계는 내가 쓰는 거다. 체계가 날 쓰는 게 아니라.

컴포넌트로 만들어둘게요, 를 반복하는 6년차의 미래

컴포넌트로 만들어둘게요, 를 반복하는 6년차의 미래

컴포넌트로 만들어둘게요 "이거 컴포넌트로 만들어둘게요." 입에 붙었다. 회의 때마다 나오는 말. 버튼 하나 디자인해도, 카드 레이아웃 잡아도, 입력 폼 만들어도. 컴포넌트. 6년 차가 되니까 모든 게 컴포넌트로 보인다. 신입 때는 몰랐다. 예쁘게만 만들면 되는 줄 알았다. 페이지마다 새로 그렸다. 버튼 색깔이 조금씩 달라도 신경 안 썼다. #3B82F6이랑 #3B83F6이 뭐가 다르냐고. 지금은 안다. 다르다. 엄청 다르다. 컴포넌트 없이 프로젝트 진행하면 어떻게 되는지. 3개월 뒤에 수정 요청 오면 어떻게 되는지. 30개 페이지에 흩어진 버튼을 하나하나 고치면 어떻게 되는지. 지옥이다. 그래서 만든다. 컴포넌트를.처음엔 재미있었다 시스템을 만드는 게 재미있었다. 디자인 시스템 구축 프로젝트. 3년 차 때였다. 팀장이 말했다. "최디자님, 이번에 디자인 시스템 제대로 만들어봅시다." 드디어. 버튼부터 시작했다. Primary, Secondary, Tertiary, Ghost. State는 Default, Hover, Active, Disabled. Size는 Small, Medium, Large. Icon 들어가는 버전, 안 들어가는 버전. 경우의 수를 다 만들었다. 48개 variant. 아름다웠다. Input field도 만들었다. Label, Placeholder, Helper text, Error message. 전부 프로퍼티로 조절 가능하게. 카드 컴포넌트도. 이미지 있는 버전, 없는 버전. CTA 버튼 1개, 2개. 태그 최대 3개까지. 완벽했다. 문서도 썼다. 사용 가이드. 언제 어떤 버튼을 쓰는지. 컬러 토큰 정리. Spacing 규칙. Typography scale. Notion에 20페이지. 뿌듯했다. "이제 모두가 이걸 쓰면 돼. 일관성도 생기고 작업도 빨라질 거야." 순진했다.그리고 현실이 왔다 기획자가 물었다. "이 버튼이요, 조금만 더 크게 할 수 없을까요? 사용자가 더 잘 보게." "Medium과 Large 사이 크기요?" "네, 딱 그 중간이요." 심호흡. "시스템에 정의된 사이즈를 쓰는 게..." "아, 그럼 이 페이지만 예외로 할게요." 예외. 이 단어가 시작이었다. 마케팅팀이 요청했다. "이벤트 페이지인데요, 좀 특별하게 만들고 싶어요. 시스템 컴포넌트 말고 새로 디자인해주세요." "컴포넌트 변형해서 쓰면..." "아니요, 완전히 새로운 느낌이 필요해요. 이건 특별한 프로젝트니까." 모든 프로젝트가 특별하다더라. 개발자가 말했다. "이 컴포넌트요, 구현하기 좀 복잡한데요. 이렇게까지 세분화해야 하나요?" "재사용성 때문에..." "근데 실제로 다 쓰이나요? 지금까지 3개 variant만 썼는데." 할 말이 없었다. 48개 중에 3개.효율성의 역설 컴포넌트는 효율을 위해 만든다. 한 번 만들어두면 계속 쓸 수 있으니까. 수정도 한 번에 반영되니까. 일관성도 유지되니까. 이론상으로는. 실제로는 다르다. 컴포넌트 만드는 데 시간이 든다. 모든 경우의 수를 고려해야 한다. 확장 가능하게 설계해야 한다. 문서도 써야 한다. 그냥 디자인하는 것보다 3배는 오래 걸린다. "지금은 시간이 좀 걸려도, 나중에 효율적이니까." 그렇게 믿었다. 근데 나중이 온다. 프로젝트 방향이 바뀐다. 요구사항이 달라진다. 예외 케이스가 생긴다. 컴포넌트를 수정한다. 기존 사용처에 영향이 간다. 또 수정한다. 또 영향이 간다. 컴포넌트가 컴포넌트를 부른다. 버튼 수정하면 카드 깨진다. 카드 수정하면 리스트 깨진다. 리스트 수정하면 페이지 깨진다. 연쇄작용. "detach instance"를 누르는 순간의 죄책감. 시스템을 배신하는 기분. 하지만 어쩔 수 없다. 일정은 내일까지고 이 페이지만 예외니까. 그렇게 예외가 쌓인다. 효율을 위해 만든 시스템이 비효율을 만든다. 유연성이라는 함정 그래서 배웠다. 유연하게 만들어야 한다고. 모든 케이스에 대응 가능하게. 프로퍼티 많이 열어두고. 옵션 다양하게. 버튼 하나에 프로퍼티 12개.Size (4종) Variant (5종) State (4종) Icon position (3종) Full width (Boolean) Loading (Boolean)완벽하다. 이제 어떤 요청이 와도 대응 가능하다. 근데. 너무 복잡해졌다. 신입 디자이너가 물었다. "이 버튼 어떻게 쓰는 거예요?" 설명하는 데 10분. "아... 그냥 새로 만들까요?" 아니. 그러면 안 되는데. 유연성을 높이면 복잡도가 올라간다. 복잡도가 올라가면 사용성이 떨어진다. 사용성이 떨어지면 아무도 안 쓴다. 안 쓰이는 컴포넌트. 공들여 만든 시스템. Figma 파일 구석에서 먼지 쌓인다. 그리고 모두가 새로 만든다. 각자의 방식으로. 일관성은 다시 무너진다. 원점이다. 80%의 법칙 5년 차쯤 깨달았다. 100% 완벽한 컴포넌트는 없다. 모든 케이스를 커버하는 시스템은 없다. 80%면 된다. 80%의 경우에 잘 작동하면. 나머지 20%는 예외로 두면. 그게 현실이다. Primary 버튼 하나. 잘 만들어둔다. 대부분의 경우에 쓸 수 있게. 특별한 이벤트 페이지? 그건 detach 해서 쓴다. 괜찮다. C레벨이 "이 페이지만 특별하게"라고 하면? 시스템 무시하고 만든다. 어차피 일회성이니까. 완벽주의를 내려놓았다. 시스템은 가이드라인이다. 법이 아니다. 컴포넌트는 도구다. 목적이 아니다. 일관성은 중요하다. 하지만 절대적이지 않다. 이걸 받아들이니까 편해졌다. "이거 컴포넌트 안 쓰고 해도 돼요?" "네, 괜찮아요. 특수한 케이스니까." 죄책감 없이 말할 수 있다. 핵심만 지킨다 지금은 핵심만 컴포넌트로 만든다. 정말 반복적으로 쓰이는 것. 정말 일관성이 필요한 것. 버튼. Input. 카드. 모달. 네비게이션. 이 정도. 나머지는 페이지별로 자유롭게. 컬러 토큰은 확실히 지킨다. Primary, Secondary, Background, Text. 8개 정도. Typography도. Heading 3개, Body 2개, Caption 1개. Spacing은 4px 기준. 8, 16, 24, 32, 48. 이 정도면 일관성은 유지된다. 세부적인 컴포넌트는? 필요할 때 만든다. "나중을 위해" 미리 만들지 않는다. 나중은 안 온다. 다른 나중이 온다. YAGNI. You Aren't Gonna Need It. 개발 원칙인데 디자인에도 적용된다. 지금 필요한 것만 만든다. 효율적이다. 문서는 짧게 디자인 시스템 문서. 3년 차 때는 20페이지 썼다. 아무도 안 읽었다. 지금은 3페이지. 컬러, 타이포, Spacing. 스크린샷 몇 개. 끝. "자세한 건 Figma 파일 보세요." 컴포넌트 자체가 문서다. 잘 만들어두면 설명 필요 없다. 프로퍼티 이름만 잘 지으면 된다. "showIcon" 말고 "hasIcon". "isLarge" 말고 "size=large". 직관적이면 문서 필요 없다. 업데이트도 쉽다. 20페이지 문서 유지보수? 불가능하다. 일주일 지나면 구버전 된다. 3페이지? 한 달에 한 번 10분이면 업데이트 끝. 지속 가능하다. 완벽한 문서보다 유지되는 문서가 낫다. 개발자와의 간극 디자인 컴포넌트랑 코드 컴포넌트는 다르다. 이걸 이해하는 데 2년 걸렸다. Figma에서는 쉽다. variant 추가하고 프로퍼티 바꾸고. 클릭 몇 번. 코드에서는? 복잡하다. "이 컴포넌트 prop 12개나 되는데요. 테스트 케이스만 50개예요." 개발자의 한숨. "Figma에서는 간단한데..." "구현은 다릅니다." 배웠다. 디자인 컴포넌트를 만들 때 개발 복잡도를 고려해야 한다. 이 프로퍼티가 정말 필요한가. 이 variant가 코드에서 어떻게 구현되는가. 개발자랑 같이 본다. Figma 파일 놓고 이야기한다. "이거 구현하려면 조건 분기가 10개 필요한데요." "그럼 이렇게 단순화하면 어때요?" 타협한다. 디자인적으로 완벽하지 않아도. 구현 가능한 선에서. 작동하는 시스템이 완벽한 시스템보다 낫다. 버전 관리의 악몽 컴포넌트 업데이트. 축복이자 저주. Master 컴포넌트 하나 수정하면 모든 instance에 반영된다. 편하다. 근데. 작업 중인 파일에도 반영된다. "어? 내 디자인이 왜 깨졌지?" 다른 디자이너의 비명. 내가 버튼 수정했는데 그 디자이너 작업물에 영향이 간 것. 미안하다. 그래서 조심스럽다. 컴포넌트 수정할 때. 누가 어디서 쓰고 있는지 확인한다. 슬랙에 공지한다. "버튼 업데이트합니다, 확인해주세요." 그래도 누군가는 놓친다. 그리고 다음 날. "어제 뭐 바꾸셨어요? 제 파일 다 깨졌는데요." 죄책감. 버전 관리가 필요하다. v1, v2, v3. 별도 페이지에. 근데 그러면 어떤 버전을 써야 하는지 헷갈린다. "최신 버전 쓰세요." "v3이요? 근데 v2가 더 안정적이라던데." "아니 v3이 최신이니까..." 혼란. 정답은 없다. 트레이드오프다. 항상. 6년 차의 깨달음 컴포넌트는 만능이 아니다. 시스템은 목적이 아니다. 도구다. 그냥. 좋은 제품 만드는 게 목적이다. 컴포넌트는 그걸 돕는 도구. 도구가 목적을 방해하면? 도구를 버린다. 시스템이 일을 느리게 만들면? 시스템을 무시한다. 일관성이 사용성을 해치면? 일관성을 포기한다. 원칙은 중요하다. 하지만 맹목적이면 안 된다. 깨야 할 때를 아는 게 경험이다. 신입 때는 몰랐다. 규칙을 배우느라 바빴다. 3년 차 때는 규칙을 만들었다. 완벽하게. 6년 차인 지금은 규칙을 깬다. 필요하면. 그게 시니어다. 미래는 어떨까 10년 차가 되면 어떨까. 아마 컴포넌트를 더 적게 만들 것 같다. 정말 필요한 것만. 핵심만. 경험이 쌓일수록 단순해진다. 복잡함이 답이 아니라는 걸 알게 되니까. AI 도구가 발전하면? "이런 느낌으로 버튼 10개 만들어줘." 클릭 한 번에 variant 생성? 그럼 컴포넌트 개념이 바뀔 것 같다. 수작업으로 만드는 게 아니라 규칙을 정의하는 것. "이런 조건일 때 이런 스타일." 코드처럼. 개발자랑 디자이너의 경계가 흐려질지도. "Design Engineer"라는 직무가 늘어나는 것처럼. Figma에서 직접 코드 생성하고. 컴포넌트가 그대로 프로덕션에 들어가고. 그럼 디자이너의 역할은? 시스템 설계자. 아니, 그것보다. 문제 해결자. 도구는 계속 바뀐다. Sketch에서 Figma로. Figma에서 다음 도구로. 컴포넌트 만드는 방식도 바뀐다. 하지만 본질은 안 바뀐다. 사용자 문제를 이해하고. 솔루션을 디자인하고. 팀과 협업하고. 컴포넌트는 그냥 과정일 뿐. 그래도 계속 말한다 "이거 컴포넌트로 만들어둘게요." 여전히. 완벽하지 않아도. 모든 경우를 커버 못 해도. 나중에 깨질 수도 있어도. 만든다. 왜냐면 그래도 낫다. 아예 없는 것보다. 80% 작동하는 시스템이 0% 시스템보다 낫다. 불완전한 일관성이 완전한 무질서보다 낫다. 깨지는 컴포넌트라도 다시 고칠 수 있다. 시스템은 진화한다. 처음부터 완벽할 순 없다. 써보면서 개선한다. 실패하면서 배운다. 6년 차의 컴포넌트는 1년 차와 다르다. 더 단순하고. 더 유연하고. 더 현실적이다. 10년 차는 또 다를 것이다. 그게 성장이다. 오늘도 출근했다. 슬랙 메시지. "최디자님, 이 버튼 좀 수정 가능할까요?" Figma 켠다. 컴포넌트 페이지 연다. 버튼을 본다. 3개월 전에 만든. 수정한다. 123개 instance에 반영된다. 누군가의 파일이 깨질지도 모른다. 미안하다. 하지만 어쩔 수 없다. 더 나은 시스템을 위해. 저장한다. "수정했습니다. 확인 부탁드려요." 슬랙에 보낸다. 커피 마신다. 네 번째. 다음 컴포넌트를 만들 준비한다. 오늘도.완벽한 시스템은 없다. 있는 건 계속 나아지는 시스템뿐이다. 6년 차가 되어서야 알았다. 컴포넌트는 목적지가 아니라 여정이라는 것을.

여백이 좀... 이 말 한마디로 시작된 3시간의 피그마 여정

여백이 좀... 이 말 한마디로 시작된 3시간의 피그마 여정

여백이 좀... 이 말 한마디로 시작된 3시간의 피그마 여전 오후 3시 27분, 그 한마디 "최디자님, 이거 여백이 좀..." 슬랙 메시지 하나가 떴다. 기획자 김과장이다. '좀' 이 단어가 문제다. 얼마나 좀인데. 4px인지 8px인지 말을 해야지. 피그마 켰다. 방금 올린 홈 화면 시안이다. 어제 밤 11시까지 잡은 레이아웃이다. "어느 부분이요?" "전체적으로요. 답답한 느낌?" 전체적으로. 답답한 느낌. 가장 추상적인 피드백 온다. 월요일 오후의 저주다.16px가 아니라 20px였던 거야 일단 측정부터 했다. 헤더 아래 여백: 24px 카드 사이 간격: 16px좌우 마진: 20px 디자인 시스템 기준이다. 8의 배수 원칙 지켰다. 뭐가 문제지. 개발자 이태리한테 물어봤다. "태리야, 이거 여백 이상해?" "저는 잘 모르겠는데요." 도움 안 된다. 태리는 1px 차이 못 본다. 그래도 착하니까 괜찮다. 대표님한테 올린 버전이랑 비교했다. 지난주 금요일 거다. 아. 찾았다. 카드 내부 패딩을 16px에서 12px로 줄였었다. 콘텐츠 많이 보이라고. 그게 문제였다. 12px는 너무 빡빡하다. 숨을 못 쉰다. 16px로 되돌렸다. 근데 이러면 카드 높이가 늘어난다. 그럼 한 화면에 3개밖에 안 보인다. 기획에서 4개 보이길 원했다. 망했다.타협의 기술, 아니 타협의 지옥 4시 15분. 48분 지났다. 카드 높이 줄이려면 내부 요소를 건드려야 한다. 제목 폰트: 18px → 16px 하면? 아니다. 제목은 위계상 타협 못 한다. 썸네일 이미지: 180px → 160px? 이것도 아니다. 썸네일 작아지면 임팩트 없다. 부제목을 한 줄로 제한? 말리는 문제 생긴다. 기획이 반대할 거다. 좌우 패딩만 줄일까. 16px → 12px. 아니다. 그럼 모바일에서 너무 답답하다. 다시 16px. 커피 마시러 갔다. 세 번째다. 정수기 앞에서 생각했다. 카드 상하 간격을 12px로 줄이면? 원래 16px인데. 4px 차이다. 별거 아닌 것 같은데 쌓이면 크다. 12px... 좀 빡빡한데. 근데 해볼 만하다. 돌아와서 적용했다. 오. 괜찮다. 4개 들어간다. 근데 뭔가 억지로 구겨 넣은 느낌이다. 5분 봤다. 익숙해진다. 10분 봤다. 아니다. 이거 아니다. 되돌렸다. 디자인 시스템이 날 가둔다 4시 53분. 문제를 다시 정의했다. 카드 하나의 높이: 240px 화면 높이(헤더 제외): 1080px - 60px = 1020px 여백 포함하면 카드 3.5개 보인다. 기획은 4개 원한다. 그럼 카드 높이를 줄여야 한다. 240px → 220px면? 20px 줄이면 된다. 어디서 줄이지. 내부 패딩: 16px (위아래 32px) 썸네일: 160px 텍스트 영역: 48px 32px 중에 8px 빼면? 위아래 각 4px씩. 12px 패딩. 또 12px다. 12px는 디자인 시스템에 없다. 8, 16, 24, 32 이렇게 간다. 규칙을 깨야 하나. 아니면 규칙을 바꿔야 하나. 슬랙에 디자인팀 채널 있다. 팀장 박실장한테 물어봤다. "실장님, 12px 패딩 써도 될까요?" "왜요?" "카드 높이 때문에요." "8의 배수 원칙 있잖아요." "네. 근데 이러면 4개 안 들어가서요." "4개가 꼭 필요해요?" 모르겠다. 기획이 원한다. 난 3개가 낫다고 본다. "일단 기획이랑 다시 얘기해보세요." 맞다. 기획이랑 얘기해야 한다.기획자는 신이 아니다 김과장한테 허들 잡았다. "과장님, 카드 4개 꼭 보여야 해요?" "네. 사용자가 선택지 많이 보는 게 좋잖아요." "근데 너무 빽빽하면 오히려 안 보지 않을까요?" "음... 그렇게 빽빽해요?" 피그마 공유했다. 4개 버전이랑 3개 버전. "이게 4개고, 이게 3개예요." 10초 침묵. "3개가 낫네요." 뭐야. "처음부터 3개 하면 안 됐어요?" "아니 4개 보여야 할 것 같았는데. 실제로 보니까 3개가 낫네요." 1시간 30분 날렸다. 근데 화는 안 난다. 이게 일이다. 보기 전엔 모른다. "그럼 3개로 할게요. 근데 답답한 느낌은 뭐였어요?" "아, 그거요. 모르겠어요. 그냥 뭔가 꽉 찬 느낌?" 꽉 찬 느낌. 카드가 4개 들어가서 그런 거였다. 억지로 넣으니까. 3개로 하면 해결된다. 근데 확인해봐야 한다. 완벽의 늪 5시 40분. 3개 버전 완성했다. 카드 간격 16px 유지. 카드 높이 240px 유지. 패딩 16px 유지. 디자인 시스템 안 깼다. 기분 좋다. 근데 또 보니까 뭔가 이상하다. 하단 여백이 너무 많다. 카드 3개 끝나고 밑에 공간이 남는다. 저기 CTA 버튼 넣을까? 아니다. 기획서에 없다. 그냥 둘까? 여백도 디자인이다. 꼭 채울 필요 없다. 근데 허전하다. 스크롤 인디케이터 넣을까? 점 3개로. 해봤다. 좀 낫다. 근데 과한가? 뺐다. 다시 넣었다. 또 뺐다. 태리한테 물어봤다. "태리야, 이거 점 있는 게 나아? 없는 게 나아?" "둘 다 괜찮은데요." 이럴 줄 알았다. 남친한테 카톡했다. 남친도 개발자다. "오빠 이거 봐봐. 점 있는 거 vs 없는 거." 3분 뒤. "없는 게 깔끔한데?" "나도 그렇게 생각해." 뺐다. 근데 5분 뒤 다시 보니까 있는 게 낫다. 다시 넣었다. 언제 멈춰야 하는가 6시 20분. 점 넣었다 뺐다를 7번 했다. 이제 진짜 모르겠다. 둘 다 괜찮다. 둘 다 이상하다. 이게 디자이너의 저주다. 디테일이 보인다. 1px 차이가 보인다. 그게 강점이다. 근데 그게 약점이다. 멈출 줄 모른다. 80%에서 멈추면 된다. 근데 난 95%를 원한다. 95%에서 100%까지 가는 게 전체 시간의 50%다. 비효율적이다. 알고 있다. 근데 못 멈춘다. 완벽하지 않으면 불안하다. 내일 아침에 보면 또 고치고 싶을 거다. 그럼 언제 끝나나. 대표님 말이 생각났다. 지난달 1on1 때. "디자이너는 작품을 만드는 게 아니라 제품을 만드는 거예요." 작품은 완벽을 추구한다. 제품은 타이밍을 지킨다. 맞는 말이다. 근데 제품도 완벽하면 안 되나. 애플 보라고. 1px까지 신경 쓴다. 우린 애플이 아니다. 스타트업이다. 빠르게 만들고, 빠르게 검증하고, 빠르게 바꾼다. 내 완벽주의는 사치다. 알고 있다. 결국 점은 뺐다 6시 35분. 점 뺐다. 최종 결정이다. 이유는 간단하다. 필요 없어서가 아니라 시간이 없어서다. 7시 퇴근이다. 25분 남았다. 개발자한테 핸드오프 해야 한다. 내일 아침 스프린트 시작이다. "태리야, 핸드오프 할게. 5분 줘." "네." 피그마 링크 공유했다. 컴포넌트 설명했다. "카드 간격 16px, 패딩 16px, 이거 토큰으로 이미 있어." "네." "하단 여백은 40px. 이것도 토큰 있어." "스크롤 인디케이터는요?" "없어. 뺐어." "아 네." "애니메이션은 ease-out, 0.3초." "알겠습니다." 끝났다. 3시간 27분 걸렸다. 실제 작업 시간은 30분이다. 나머지는 고민이다. 고민이 나쁜 건 아니다. 고민해야 좋은 디자인 나온다. 근데 과한 고민은 독이다. 디테일 강박증 환자의 자가 진단 퇴근길 지하철에서 생각했다. 나는 디테일에 예민하다. 그게 내 정체성이다. "여백 좀 이상한데요?" 이 말 듣는 게 제일 싫다. 그래서 미리 100번 본다. 혹시 이상한 거 없나. 이게 강점이다. 내 디자인은 완성도 높다. 근데 약점이기도 하다. 시간이 너무 오래 걸린다. 균형을 못 찾겠다. 완벽주의를 버리면 평범한 디자이너가 될까 봐 무섭다. 완벽주의를 유지하면 효율 없는 디자이너가 될까 봐 무섭다. 어디서 타협해야 하나. 선배 디자이너한테 물어본 적 있다. 작년에. "언제 멈춰야 해요?" "마감 1시간 전에." 농담 같았는데 진담이었다. "디자인은 끝이 없어. 시간이 끝낼 뿐이야." 맞다. 시간이 끝낸다. 내가 끝내는 게 아니라. 마감이 없으면 영원히 못 끝낸다. 내일의 나에게 집 도착했다. 8시 10분. 피그마 켰다. 습관이다. 오늘 한 작업 다시 봤다. 점 넣는 게 나았을 것 같다. 넣을까. 아니다. 그만하자. 이미 개발자한테 넘겼다. 끝난 거다. 다음 작업 들어가야 한다. 프로필 페이지 리뉴얼. 근데 오늘 한 거 한 번만 더 보자. 카드 모서리 라운드. 12px인데 16px가 나을까? 해봤다. 16px가 좀 더 부드럽다. 근데 너무 둥글다. 12px가 맞다. 되돌렸다. 아. 또 시작이다. 컴퓨터 껐다. 강제 종료다.디테일은 축복이자 저주다. 오늘도 그 사이 어딘가에서 길을 잃었다. 내일은 좀 빨리 나올 수 있을까.