지난 회고의 마지막 부분에 'UX/UI' 레이어가 문서화될 필요성에 대한 회고를 했다. 왜냐하면 길어진 작업에 따른 피로감의 원인이 코드 자체보다 사전에 공유된 UX/UI 기준의 부재에 있다는 생각이 들었기 때문이다.
1. 점심 시간에 전수 받은 꿀팁
오늘 점심 시간에 동료들에게 이 회고 내용을 짧게 언급했다. 그랬더니 한 동료 분께서 실천해보셨던, 그리고 나에게 제안하는 방법 2가지를 알려주셨다.
나중에 고칠 문제를 미리 찾는 법
① 메타 프롬프팅: "여러 사람들 앞에서 현재 만들어진 것을 가지고 시연을 한다고 했을 때, 막히거나 피드백을 들을만한 부분들을 발견해주세요"를 n회 반복해 많은 문제를 잡아내셨다고 말씀해주셨다.
② 내가 한 잡도리(?) 돌아보기: 실제 작업 중 내가 어떤 부분을 반복해서 지적했는지 모아보라고 말씀해주셨다. 기준 없이 반복노동으로 AI와 내가 모두 피곤해졌던 순간들을 다시 되짚어보면 그것 자체로 체크리스트이자 기준이 될 수 있을 것 같다는 느낌이 왔다.

2. 나의 프롬프트/작업 내역 돌아보기
그래서 Codex에서 작업했던 여러 채팅방을 다시 뒤져보며, 당시의 지적과 수정 흐름을 시간순으로 최대한 모아봤다.
| 시점 | 겉으로 보인 문제 | 수정한 내용 | 실제로 부족했던 기준 |
| 초반 | 패널 추가 버튼 2개가 시각적으로 덜 다듬어져 보임 | 텍스트 기호를 아이콘 버튼으로 바꾸고, hover/focus 스타일과 내부 툴팁을 정리함 | 🟠 패널 액션 버튼의 공통 디자인 기준 부재 |
| 초반 | hover/focus의 파란색 강조가 과하게 느껴짐 | 보조 액션 버튼의 강조 색상을 중립 회색 계열로 낮춤 | 🟠 액션 위계별 색상 사용 기준 부재 |
| 초반 | 우측/하단 패널 추가 버튼이 모두 필요한지 애매함 | 하단 추가 버튼을 제거하고 우측 패널 추가 버튼만 남김 | 🟢 패널 추가/이동 가능 범위에 대한 제품 원칙 부재 |
| 초반 | 아이콘만으로 버튼 의미가 충분히 전달되지 않음 | PanelRight + 패널 추가처럼 아이콘+텍스트 버튼으로 변경 | 🟠 버튼 라벨링과 아이콘 사용 기준 부재 |
| 초반 | 액션 영역의 X와 탭 영역의 X가 겹쳐 보여 헷갈림 | 액션 영역의 X를 제거하고, 닫기는 탭 쪽 책임으로 정리 | 🟢 닫기/추가/이동의 책임 영역 기준 부재 |
| 초중반 | 빈 패널에도 닫기 동작이 필요하지만 의미가 애매함 | 유일한 빈 패널의 X는 패널 삭제가 아니라 사이드바 닫기로 처리 | 🟢 빈 패널과 사이드바 종료의 동작 원칙 부재 |
| 초중반 | 패널 추가 버튼에 툴팁까지 붙어 중복되어 보임 | 시각적 툴팁은 제거하고, 스크린리더용 aria-label만 정확히 수정 | 🔵 시각적 툴팁과 접근성 라벨의 역할 기준 부재 |
| 초중반 | 토론 메시지 영역이 좌우로 붙어 보여 답답함 | 토론 메시지 리스트 좌우 여백을 16px로 조정 | 🟠 패널 내부 여백 기준 부재 |
| 초중반 | 탭 앞 아이콘 배경이 무겁고 빈 패널에서는 불필요해 보임 | 아이콘 배경을 제거하고, 빈 패널 탭에서는 아이콘도 제거 | 🟠 탭 시각 요소의 밀도/강조 기준 부재 |
| 중반 | 빈 패널이 단순 버튼 목록처럼 보여 의도가 약함 | 설명 영역 + 버튼 영역의 2칼럼 구조로 변경 | 🟠 빈 상태 디자인 기준 부재 |
| 중반 | 빈 패널 문구와 정보량이 과하거나 어색함 | 큰 제목, New, 본문 등을 줄이고 사이드바 커스텀 모드 pill 중심으로 정리 | 🟠 빈 상태의 문구 위계 기준 부재 |
| 중반 | 빈 패널 추천 영역과 기능 버튼 폭이 서로 맞지 않음 | 추천 영역과 기능 리스트 폭을 맞추고 중앙 정렬을 조정 | 🟠 카드/리스트 폭과 정렬 기준 부재 |
| 중반 | 빈 패널이 위쪽이나 왼쪽으로 치우쳐 보임 | 중앙 rail 폭, 정렬 방식, safe center 등을 조정 | 🟠 패널 크기별 레이아웃 기준 부재 |
| 중반 | 기능 목록의 순서와 그룹이 제품 의도와 덜 맞음 | 요약, 토론, 키워드, 퀴즈, 노트, 하이라이트 등 순서를 재정리 | 🟢 기능 우선순위와 정보구조 기준 부재 |
| 중반 | 기본/커스텀 모드 전환 UI 위치가 화면에서 다소 뜬금없음 | 사이드바 헤더 쪽 드롭다운으로 옮김 | 🟢 모드 전환의 사용 빈도와 위치 원칙 부재 |
| 중후반 | 기본 모드에서 드롭다운이 X 왼쪽에 정확히 붙지 않음 | 실제 rightSidebarCloseButton 바로 앞에 마운트되도록 수정 | ⚪ 실제 화면 기준 위치 검증 부족 |
| 중후반 | 모든 패널에 모드 드롭다운/패널 추가가 반복되어 복잡함 | 가장 우측, 가장 상단 패널에만 표시되도록 제한 | 🟢 패널 액션의 표시 범위 기준 부재 |
| 중후반 | 모드 전환이 자주 쓰는 기능처럼 노출됨 | 화면 설정 모달로 이동하고 segmented toggle 형태로 변경 | 🟢 설정성 기능과 작업 중 기능의 배치 기준 부재 |
| 중후반 | 스플릿 뷰, 패널 모드, pane 등 용어가 섞임 | 커스텀 모드, 사이드바 모드, 패널 등으로 정리 | 🟢 사용자-facing 용어 체계 부재 |
| 중후반 | 드래그 시 같은 레벨 이동 피드백이 실제 결과보다 크게 보임 | 반투명 영역 대신 경계 삽입선/슬롯 블럭으로 변경 | 🟠 드래그 피드백 디자인 기준 부재 |
| 중후반 | lower-level 탭 이동 피드백이 병합처럼 보임 | pane-edge, tab-position, tab-strip 의도를 분리 | 🟢 패널 이동과 위계에 대한 제품 원칙 부재 |
| 중후반 | lower-level 탭의 순서 변경이 되지 않음 | 탭 좌/우 위치에 따라 before/after reorder 가능하게 구현 | 🟢 하위 패널/탭 reorder 동작 기준 부재 |
| 후반 | tabbar의 빈 오른쪽 영역이 의도와 다르게 drop target이 됨 | 탭이 있는 tabbar에서는 빈 영역도 after-last tab-position으로 처리 | 🟢 드롭 영역별 동작 정의 부족 |
| 후반 | 사용자 행동 이벤트가 너무 세분화됨 | 6개 이벤트를 하나의 right_sidebar_custom_mode_snapshot으로 단순화 | 🟣 이벤트 설계 원칙 부재 |
| 후반 | 패널 닫기 이벤트가 실제 분석 가치보다 과하게 느껴짐 | 개별 close tracking보다 최종 구성 snapshot 중심으로 변경 | 🟣 분석 질문 중심의 이벤트 기준 부재 |
| 후반 | i18n 적용 전 한국어 하드코딩이 남아 있음 | 8개 locale의 viewer.ftl로 사용자-facing 문자열 이동 | 🔵 다국어/접근성 포함 문구 관리 기준 부재 |
| 후반 | 언어 번들 로딩 전 i18n key가 화면에 깜빡 보임 | 언어 준비 전 children을 렌더하지 않도록 수정 | 🔵 로딩 중 접근성/문구 노출 기준 부재 |
| 후반 | 기본/커스텀 모드의 관계가 계속 재확인됨 | docs/right-sidebar-custom-mode.md에 목적, 용어, 규칙, 체크리스트 작성 | 🟢 기본 기획서/제품 계약 문서 부재 |
| 리뷰 단계 | 저장된 layout 값이 깨질 가능성 있음 | invalid/missing panel id, number validation, layout 테스트 보강 | ⚪ 상태 저장/복원 검증 기준 부족 |
| 리뷰 단계 | ARIA, locale, 용어, refetch 같은 주변 품질 이슈가 뒤늦게 발견됨 | ARIA 연결, i18n 용어, 불필요한 refetch 제거, 테스트 추가 | ⚪ 리뷰 전 QA 체크리스트 부족 |
타임라인으로 펼쳐보니, 반복 수정의 대부분은 개별 구현 실수라기보다 디자인 시스템, 접근성, 이벤트 설계, 제품 동작 원칙이 비어 있던 지점에서 발생하고 있었다.
통계를 내보면...
| 부족했던 기준 | 횟수 | 해석 |
| 🟢 제품 기획/동작 원칙 부재 | 12 | 패널 추가, 이동, 위계, 모드 전환처럼 기능의 "규칙"이 작업 중에 만들어진 비중이 가장 큼 |
| 🟠 디자인 시스템 부재 | 10 | 버튼, 색상, 여백, 빈 상태, 드래그 피드백 등 시각 기준이 매번 개별 판단됨 |
| 🔵 접근성 기준 부재 | 3 | 툴팁, aria-label, i18n key 노출처럼 명시 기준이 없어 뒤늦게 정리됨 |
| 🟣 이벤트 설계 원칙 부재 | 2 | 무엇을 이벤트로 남길지보다 어떤 분석 질문에 답할지가 늦게 정리됨 |
| ⚪ QA/검증 기준 부재 | 4 | 실제 위치, 저장값, ARIA, locale, refetch 등 구현 후반/리뷰 단계에서 발견됨 |
작업을 되돌아보니 ‘UX/UI 문서화가 필요하다’는 지난번 회고를 조금 더 구체화할 수 있었다. 막연히 UX/UI라고 부르던 영역 안에도 디자인 시스템, 접근성 기준, 이벤트 설계 원칙(DX에 가까움), 기본 기획서처럼 서로 다른 종류의 기준들이 섞여 있었다
3. 시스템의 중요성과 개인적 반성
2등 '🟠 디자인 시스템 부재'를 보며 생각이 많아졌다. 제품 메인 UX/UI 담당자로서 부끄러운 말이지만.. 이제 진짜 디자인 시스템의 범위를 넓혀 보완해야하는 타이밍이라는 걸 알고 있었지만, 당장 그로스 관점에서 더 직접적으로 도움이 되는 일을 우선하다 보니 디자인 시스템 작업을 계속 뒤로 밀어두고 있었다. 그런데 이번 작업을 정리해보니, 디자인 시스템만 있었다면 긴 수정의 시간을 아낄 수 있었을텐데 하는 현타가 왔다.
그리고 우리 팀은 엔지니어부터 데이터&그로스를 주로 보는 동료, 마케터까지 모두가 UI를 직접 건들이고 있다. 그때마다 많은 경우에 내가 검수를 도와드리며 매번 기준을 새로 고민하고 정리하는 일이 많아지고 있다. 생각해보면 이건 개인의 피로뿐 아니라 팀의 속도 차원에서도 병목이 되는 일, 혹은 병목이 되기 싫어 디자인 품질을 떨어뜨리는 일이라는 생각이 들어, 디자인 시스템 작업의 우선순위를 더 높여야겠다는 다짐을 하게 된다.

이번 회고를 통해 디자인 시스템을 미뤄둔 비용이 생각보다 컸다는 걸 느꼈다. 그 비용이 더 커지기 전에 작업에 들어가야겠다! 그런데.. 사실 시도는 여러차례 했으나 추진력을 발휘 못한 데는 이유가 있었을텐데 이 부분에 대해서도 근본적인 이유를 한 번 들여다보고 시작하는 것이 좋을 것 같다. 며칠 뒤면 이에 대한 회고를 쓰고 있기를..!! 굿..!!
'Learn everyday' 카테고리의 다른 글
| [6월 TIL #3] 작업 회고: truncate와 minSize가 안 됐던 이유 (0) | 2026.06.08 |
|---|---|
| [6월 TIL #2] 다른 근육 쓰기: 2주년 이벤트 & 글로벌 유저 인터뷰 (0) | 2026.06.04 |
| [5월 TIL #17] 폰으로만 코딩③: 느슨해진 업무에도 긴장감이 필요하다 (0) | 2026.05.31 |
| [5월 TIL #16] EXL 26 공유회 후기: 인간과 AI가 시너지를 내는 실험이란 (0) | 2026.05.29 |
| [5월 TIL #15] 폰으로만 코딩②: FC 바르셀로나 소식 봇 (0) | 2026.05.28 |