🟢 38. 엣지 케이스에 대한 달라진 마음가짐

개발하는 프로덕트 디자이너의 체커블 작업 과정 이야기

Jun 26, 2025

안녕하세요, fi-workers 프로덕트 디자이너 나나산이에요. 저는 밖에 나가지 않고 넷플릭스를 보고, 듀오링고 자수정 리그 1등을 하며 주말을 보냈어요. 이번주엔 강원도로 가족 여행을 떠납니다! 🚗

TMI는 그만 얘기하고, 그럼 오늘 뉴스레터도 재밌게 읽어주시길 바라요. 저희에게는 댓글이 가장 큰 힘이 된답니다 😉
38번째 뉴스레터 시작해볼게요! 📩

사이드킥 사전 신청 ⚽

지속 가능한 사이드 프로젝트를 위한 프로그램 사이드킥! 사이드킥 사전 신청을 해주시면 2기 신청이 시작되면 제일 먼저 알려드릴게요. 궁금하신 점이 있다면 뉴스레터의 댓글이나 저희가 운영하는 인디 메이커를 위한 커뮤니티 인디라운드에 와서 남겨주세요. 😉

fi-workers 업무 일지 ✍️

체커블 작업 과정 🔄

외주 업무와 더불어 요즘은 계속 체커블을 개발하고 있습니다 ✅

예전에 공유 드렸듯이 체커블은 Figma 디자인 파일이 따로 없습니다. 어떤 기능을 새로 추가해야 할 때는 레퍼런스를 모으고, 와이어프레임을 대충 머릿속으로 혹은 손으로 그린 후, Shadcn 라이브러리의 컴포넌트를 활용해서 필요한 UI를 구성하고 있습니다.

Shadcn 라이브러리에서 가져올 수 없이 새로 구성해야 하는 컴포넌트 같은 경우, AI를 통해 컴포넌트를 만들어 UI를 그리고, 이후에 추가로 보기 좋게 컴포넌트를 다듬는 식으로 작업을 해나가고 있어요.

사전 디자인 단계가 생략되다 보니 작업 속도는 굉장히 빨라졌어요. 풀스택 개발자인 w0nder님 혼자서 UI도 그리고 기능도 개발할 때도 있고요, 제가 UI를 구성하고 백엔드를 w0nder님이 작업하실 때도 있고, 프론트에서 처리 가능하다면 제가 UI와 더불어 기능까지 만들기도 합니다.

주별 성공/실패 표시 추가

최근 제가 작업한 것은 챌린지 상세 페이지에서 주별 성공/실패를 표시하는 건데요, 처음엔 간단한 기능으로 생각했어요. 설정된 인증 횟수와 비교했을 때 그 횟수 미만이면 실패를 표시하고, 이상이면 성공을 표시하면 되겠구나 싶었습니다.

한 주의 정의

근데 코드를 보니 한 주를 무지성으로 7일로 끊고 이를 한 주로 표시하고 있었어요. 그래서 수요일에 시작하는 챌린지는 수목금토일월화를 한 주로 보고 있었죠. (~~아니 누가 개발했나요? 제가 개발했습니다…~~) 한 주의 의미를 다시 살펴 볼 필요가 있었어요.

체커블에서 한 주는 월화수목금토일이라는 결론을 짓고, 수요일에 시작했다면 일요일이 마지막 요일이 되게끔 했어요. 그리고 챌린지 기간 밖 상태로 월요일과 화요일을 표시했습니다.

성공과 실패 상태, 그리고 아직 성공도 실패도 하지 않은 상태

이후 QA를 하다 보니 커서가 한 주가 다 지나야 성공을 표시하도록 개발한 걸 알게 되었고, 한 주가 지나지 않았을 때 조건을 만족하면 성공으로 보도록 수정했습니다. 또 한 주가 다 지난 후 조건이 만족되지 않을 때에만 실패를 표시하고, 그 전까진 아직 성공의 가능성이 있기 때문에 성공과 실패가 아닌 상태로 “-”로 표시했습니다.

엣지 케이스에 대한 달라진 마음가짐

실제로 기능을 만들며 생기는 엣지 케이스들을 하나씩 잡고, 이를 직접 해결할 때 희열을 느낍니다. 사실 그 전이었다면 함께 일하는 개발자가 저에게 와서 이 케이스 대응이 빠져 있다, 이때는 어떻게 표시할지를 물어봤을 거예요.

‘나는 왜 미리 설계할 때 이런 엣지 케이스를 발견을 못했지?’, ‘이런 일이 없게 하려면 어떻게 해야 하지?’ 사실 전 그때마다 좌절감을 느끼곤 했어요. 제 실력이 부족하다는 생각에 디자인 스펙을 좀 더 치밀하게 쓰려고 노력하고, CRUD도 공부하고, 개발 공부도 하는 식으로 만전의 만전을 기하려곤 노력했죠.

하지만 이런 엣지 케이스는 실제로 직접 개발하며 테스트하지 않는 이상, 만전의 만전을 기해도 튀어나올 수밖에 없다는 걸 깨달았어요. 물론 만전을 기하기 위해 공부를 하는 건 좋지만 디자인 스펙에 완벽은 없다는 걸 깨달았습니다.

혹시나 프로덕트 디자이너분들 중에 저와 비슷한 생각을 하셨던 분이 계시다면 너무 괴로워하지 않으셨으면 좋겠습니다 🍀

인디라운드에서 나눈 이야기

인디 메이커를 위한 커뮤니티, 인디라운드 디스코드 채널에서 공유된 제품, 아티클을 공유합니다 😊

이외에도 지속가능한 사이드 프로젝트를 도와주는 사이드킥, 매월 열리는 오프라인 북클럽, 독서 챌린지 등에 참여할 수 있어요 😊 인디라운드 디스코드 채널로 놀러 오세요!

fi-workers가 본 제품, 아티클

Tremor

🔗 https://tremor.so/ | by w0nder

Tremor는 React 기반의 대시보드 및 차트 라이브러리인데, 기존 라이브러리들과 차별화되는 몇 가지 특징이 인상적이었어요.

첫 번째로 눈에 띈 건 문서화 품질이에요. 예제 코드들이 정말 깔끔하게 정리되어 있어서 학습 곡선이 완만하더라고요. 다른 차트 라이브러리들 쓸 때마다 문서 읽는 게 고역이었는데, Tremor는 코드 예제만 봐도 바로 어떻게 쓰는지 감이 와요. 특히 실제 사용 시나리오에 맞춘 예제들이 많아서 복사-붙여넣기로도 금방 프로토타입을 만들 수 있었어요.

두 번째는 디자인 일관성이에요. 기본 스타일링이 현대적이고 깔끔해서 별도 커스터마이징 없이도 괜찮은 결과물이 나와요. Recharts나 Chart.js 쓸 때는 항상 스타일링에 시간을 많이 투자해야 했는데, Tremor는 기본값만으로도 충분히 프로페셜해 보이더라고요.

그리고 최근 Vercel에 조인했다는 소식을 봤는데, 개인적으로 Vercel은 별로 선호하지 않는 회사지만 이 경우엔 긍정적으로 보고 있어요. 지속적인 지원과 React 생태계 내에서의 안정성은 확실히 보장될 것 같거든요. 오픈소스 프로젝트 선택할 때 가장 중요한 게 장기적 지속 가능성인데, 이 부분에서는 안심이 되네요.

대시보드나 데이터 시각화가 필요한 프로젝트를 계획 중이라면 Tremor 한번 써보시길 추천드려요. 빠른 프로토타이핑부터 프로덕션까지 무리 없이 커버할 수 있을 것 같아요.

Approaching AI as a design leader: starting with a culture of experimentation

🔗 https://www.mynameisjehad.com/approaching-ai-as-a-design-leader-starting-with-a-culture-of-experimentation/ | by 나나산

디자인 리더인 저자가 AI를 어떻게 디자인 팀에 적용하는지를 다루는 시리즈로 첫 번째 글입니다. 제일 먼저 프로토타이핑, 다양한 제품을 써보며 새로운 접근법을 실험할 수 있는 문화를 주도해야 한다고 말합니다.

실험하는 문화에서 3가지 중요한 요소를 제시하는데, 두 번째 “새로운 도구를 쉽게 시도할 수 있게 만들기” 내용에 공감이 가더라고요. 가끔 회사 내에 있는 프로덕트 디자이너들과 이야기를 나눌 때면 AI에 대한 지식이나 경험의 차이가 굉장히 크다는 생각이 들때가 많았어요.

아무래도 조직 내에선 쉽게 쉽게 새로운 툴을 빠르게 구매해서 사용해볼 수 없고, 대부분 회사에서는 어느정도 안정화된 제품을 도입해서 오래 쓸 걸 생각하다 보니 더 그 격차가 생기는 게 아닐까 싶어요.

디지털 제품 분야 자체가 워낙 트렌디한 곳이기도 하지만 특히나 AI 분야의 제품들은 특히 더 트렌드가 바뀌는 속도가 훨씬 빠르기 때문에 더 쉽게 도구를 탐색해 보고 시도해볼 수 있는 문화를 만들어야 한다고 저자는 말합니다.

다음 시리즈들도 계속해서 다뤄보도록 하겠습니다 😊