본문으로 건너뛰기
모니터를 함께 보며 작업 중인 디자이너와 개발자

디자인과 개발 사이에 문서를 두지 않습니다

큰 조직은 디자인과 개발 사이에 문서와 회의를 쌓습니다. 작은 팀에는 그럴 여유가 없는 대신, 더 빠르고 정확하게 움직일 수 있습니다. 우리 서비스를 직접 만들면서 자리 잡은 작업 방식을 공유합니다.

모니터를 함께 보며 작업 중인 디자이너와 개발자

디자이너가 시안을 완성해 개발자에게 넘기고, 개발자가 질문하고, 다시 수정하는 과정. 이 왕복에서 일정의 상당 부분이 사라집니다. 문제는 사람의 성실함이 아니라 구조에 있습니다. 넘기는 순간이 있으면, 넘기기 전까지는 아무도 실제 화면을 보지 못합니다.

우리 팀에서는 디자이너가 그리는 컴포넌트와 개발자가 만드는 컴포넌트가 처음부터 같은 이름, 같은 규칙을 씁니다. 색과 간격, 타이포그래피는 토큰 한 벌로 관리하기 때문에 값 하나를 바꾸면 디자인 파일과 코드가 함께 바뀝니다. 시안이 예뻐 보이는데 구현이 이상해지는 일은, 대개 두 쪽이 서로 다른 단위를 쓰고 있어서 생깁니다.

  • 디자인 토큰을 코드와 같은 저장소에서 관리한다
  • 컴포넌트 이름을 디자인과 코드에서 통일한다
  • 매주 스테이징에 배포하고 실제 화면으로 리뷰한다
  • 문구와 간격 같은 작은 수정은 디자이너가 직접 코드에 반영한다

가장 좋은 명세서는 지금 열어 볼 수 있는 화면입니다.

— 신아린, 프로덕트 디자이너

미요사주의 풀이 화면은 이 방식이 가장 많이 쓰인 자리입니다. 긴 글을 읽는 화면은 줄 간격 하나, 문단 사이 여백 하나로 체감이 크게 달라집니다. 시안 위에서 아무리 오래 들여다봐도 답이 안 나오던 문제가, 실제 문장을 넣고 손에 쥐어 보면 30분 만에 정리되는 경우가 많았습니다.

우리 서비스라서 마음껏 고쳐 볼 수 있었고, 그 과정에서 정리된 규칙이 지금은 우리가 맡는 다른 제품의 출발점이 됩니다. 남의 제품에서 실험하지 않아도 되는 것, 작은 팀이 자기 서비스를 갖는 가장 실질적인 이점입니다.

외부 프로젝트에서도 순서는 같습니다. 문서 대신 매주 금요일 스테이징 링크를 보냅니다. 고객사는 PDF가 아니라 자기 손으로 눌러 본 화면에 피드백을 남기고, 우리는 다음 주 월요일에 그걸 반영합니다.

작은 팀의 강점은 결정이 빠르다는 데 있습니다. 모두가 같은 화면을 보며 같은 이름으로 이야기할 때, 좋은 결과물은 생각보다 훨씬 빨리 나옵니다.

대기열 없이 공연장 입구로 들어서는 관객들

기획서부터 만들고
오실 필요 없습니다.

무엇을 만들고 싶은지만 알려주세요. 아이디어 단계인지, 이미 운영 중인 서비스인지, 개발사를 바꾸려는 상황인지부터 확인하고 지금 무엇을 결정해야 하는지 정리해드립니다.