나리와 JT가 부딪혔습니다.
정확히는, 디자인 프로세스를 두고 의견이 갈렸어요. 프로젝트를 시작한 이래 가장 긴 논쟁이었습니다.
나리는 디자이너입니다. 화면을 설계할 때 와이어프레임을 그리고, 하이파이 목업을 만들고, 컴포넌트를 정리해서 개발자에게 넘기는 것이 정석이라고 생각했어요.
그래서 피그마로 디자인 시스템을 만들기 시작했습니다. 컬러 팔레트 4종을 비교하고, 폰트를 정하고, 온보딩 5단계의 와이어프레임을 그렸습니다.
결과물은 훌륭했습니다. 온보딩 화면, MVP 플로우 다이어그램, UI 컴포넌트 보드까지. 지금도 남아 있는 이미지 파일들이 그때의 산출물이에요.
문제는, 그 다음이었습니다.
피그마에서 만든 디자인을 Flutter 코드로 옮기는 작업. 이 과정에서 시간이 너무 많이 걸렸습니다.
1인 개발입니다. 피그마에서 디자인하고, 그걸 보면서 코드를 짜고, 디자인과 코드가 안 맞으면 다시 피그마로 돌아가고.
이 왕복이 매번 반복되니까, 실질적인 진행이 너무 느렸어요.
JT가 말했습니다.
“영진님이 피그마도 하고 코딩도 하잖아요. 그러면 피그마를 거치지 말고, 바로 코드로 가는 게 빠르지 않을까요?”
나리는 반대했습니다.
“디자인 없이 코딩부터 하면, 나중에 전체 흐름이 뒤죽박죽 돼요. 사용자 입장에서 ‘어떻게 느끼는가’를 먼저 설계해야 합니다.”
둘 다 맞는 말이었습니다.
이 논쟁은 사실, 디자인 도구의 문제가 아니었습니다.
“이상적인 프로세스를 따를 것인가, 현실적인 속도를 택할 것인가”의 문제였어요.
스타트업이라면 당연히 속도를 택해야 할 것 같지만, 디자인 없이 만든 앱은 사용자가 쓰기 싫어할 수도 있습니다.
결국 타협점을 찾았습니다.
피그마는 버린다. 하지만 디자인 원칙은 지킨다.
구체적으로는 이랬습니다:
-
디자인 시스템은 코드로 관리한다. 컬러, 폰트, 간격 등의 규칙을 CSS/코드 변수로 정의합니다. 피그마 파일 대신, 코드 자체가 디자인 시스템이 됩니다.
-
화면 설계는 대화로 한다. 나리와 JT가 화면 단위로 “이 화면에서 사용자가 할 일”을 먼저 정의하고, 바로 코드로 구현합니다. 프롬프트 기반 개발이에요.
-
와이어프레임은 이미 만든 것으로 충분하다. 나리가 이미 그려둔 온보딩 플로우, MVP 플로우는 레퍼런스로 계속 사용합니다. 새로운 화면을 피그마로 그리지 않을 뿐입니다.
나리가 마지막에 이렇게 말했습니다.
“좋아요. 대신 하나만 약속해요. 디자인을 ‘안 하는 게’ 아니라, ‘다른 방식으로 하는 거’라고 생각할게요.”
이 결정은 프로젝트 전체의 속도를 바꿨습니다. 피그마 왕복이 사라지니까, 하루에 화면 하나씩 만들 수 있게 되었어요.
물론 완벽한 디자인은 아니었습니다. 하지만 “완벽한 디자인인데 아무도 안 쓰는 앱”보다는, “디자인은 투박하지만 돌아가는 앱”이 먼저 필요했습니다.
이 결정에서 배운 것이 있습니다.
1인 프로젝트에서는, 프로세스가 아니라 결과물이 중요합니다. 이상적인 절차를 포기할 용기가 필요한 순간이 옵니다.
피그마를 버린 밤. 아쉬웠지만, 후회하지 않습니다.
다음 편에서는 AI 모델 선택 이야기를 합니다. GPT와 Gemini, 어떤 AI에게 무엇을 맡길 것인가를 두고 실험한 이야기입니다.