Blog·인사이트

디자인 없이 개발부터 하면 안 되는 이유

··4분 읽기

"일단 기능부터 만들어주세요. 디자인은 나중에 입혀도 되잖아요."

자주 듣는 말입니다. 예산을 아끼기 위해, 혹은 빨리 시작하고 싶어서 디자인 단계를 건너뛰려는 것입니다. 이해는 되지만, 대부분의 경우 이 순서가 총비용을 더 키웁니다.

"나중에 디자인 입히면 되지"의 문제

디자인은 "예쁘게 만드는 것"이 아닙니다. 디자인은 화면의 구조를 결정하는 것입니다.

화면 구조가 코드 구조를 결정한다

  • 메인 페이지에 탭이 3개인지 5개인지에 따라 네비게이션 컴포넌트 구조가 달라집니다
  • 목록을 카드형으로 보여줄지 테이블형으로 보여줄지에 따라 데이터 로딩 방식이 달라집니다
  • 모바일에서 메뉴를 어떻게 접을지에 따라 레이아웃 코드가 달라집니다

디자인 없이 개발하면, 개발자가 "아마 이렇게 되겠지"하고 가정해서 코드를 짭니다. 나중에 디자인이 나오면 — "아, 이 구조가 아니었네" — 코드를 뜯어고쳐야 합니다.

재작업 비용

디자인이 나중에 나와서 수정하는 비용은, 처음부터 디자인을 확정하고 개발하는 비용보다 큽니다. 이미 만들어진 코드를 수정하는 것은, 백지에서 새로 만드는 것보다 어렵습니다.

  • 레이아웃 변경 → HTML 구조부터 다시
  • 인터랙션 추가 → 상태 관리 로직 수정
  • 화면 흐름 변경 → 라우팅, API 호출 순서 변경

"디자인 비용 아꼈다"가 아니라, "재작업 비용을 추가했다"가 됩니다.

기획 → 디자인 → 개발, 이 순서가 중요한 이유

기획 단계

무엇을 만들 것인가. 어떤 기능이 필요하고, 사용자가 어떤 순서로 사용하는가. 화면 목록과 각 화면의 역할을 정리합니다.

디자인 단계

기획을 화면으로 옮깁니다. 와이어프레임으로 구조를 잡고, UI 디자인으로 최종 형태를 확정합니다. 이 단계에서 "이 버튼을 누르면 어디로 가는지", "이 데이터를 어떤 형태로 보여주는지"가 결정됩니다.

개발 단계

확정된 디자인을 보고 코드를 작성합니다. 구조가 명확하니 재작업이 최소화되고, 개발자가 추측할 필요가 없습니다.

이 순서를 지키면 한 번에 제대로 만들 확률이 높아집니다. 순서를 뒤집으면 반복 수정의 루프에 빠집니다.

디자인이 개발 구조에 영향을 주는 경우

"디자인이랑 개발은 별개 아니에요?" — 아닙니다.

무한 스크롤 vs 페이지네이션

디자인에서 무한 스크롤을 결정하면, 백엔드 API도 커서 기반 페이지네이션으로 설계해야 합니다. 일반 페이지네이션으로 만들어놓고 나중에 무한 스크롤로 바꾸면, API 구조부터 바꿔야 합니다.

실시간 업데이트

채팅이나 알림이 실시간으로 화면에 반영되어야 하는 디자인이면, 웹소켓이나 Server-Sent Events 같은 기술이 필요합니다. "나중에 실시간으로 바꿔주세요"는 아키텍처 수준의 변경입니다.

반응형 디자인

모바일, 태블릿, 데스크톱에서 화면이 어떻게 변하는지가 디자인 단계에서 결정되어야 합니다. 데스크톱만 보고 만들어놓고 "모바일도 되게 해주세요"는, 레이아웃을 거의 새로 만드는 작업입니다.

다만, MVP에서는 예외가 있다

모든 프로젝트에서 완벽한 디자인이 필요한 것은 아닙니다.

MVP(최소 기능 제품) 단계에서는 최소한의 디자인으로 시작하는 것이 합리적입니다.

  • 와이어프레임 수준: 구조만 잡고, 비주얼 디자인은 나중에
  • UI 키트 활용: Material UI, Tailwind CSS 같은 기존 디자인 시스템 활용
  • 핵심 화면만 디자인: 메인 페이지, 핵심 기능 화면만 디자인하고, 나머지는 템플릿

중요한 것은 디자인의 수준을 낮추는 것이지, 디자인 단계를 건너뛰는 것이 아닙니다. 와이어프레임 수준이라도 화면 구조가 확정되어야 개발자가 올바른 방향으로 코드를 작성할 수 있습니다.

프로덕트 메이커의 방식은 좀 다릅니다

위에서 기획 → 디자인 → 개발 순서가 중요하다고 했지만, 저희는 실제로 조금 다르게 진행합니다.

저희는 요구사항을 정리하고 프로세스를 소통한 뒤, 바로 디자인하고 개발을 붙인 동작하는 결과물을 보여드립니다. 정적인 기획 문서나 디자인 이미지를 넘기는 게 아니라, 실제로 클릭하고 움직이는 화면을 먼저 공유합니다.

왜 이렇게 하느냐면, 기획서나 정적 디자인 이미지로 보는 것보다 동작하는 결과물, 인터랙션, 실제 UI/UX를 직접 만져보는 것이 소통에 훨씬 효과적이기 때문입니다. 클라이언트가 "아 이런 느낌이구나"를 즉시 체감하고, 거기서 피드백을 주시면 저희가 개선합니다.

물론 이 방식에서 일부 비효율이 발생할 수 있습니다. 피드백을 반영하면서 코드를 수정해야 하니까요. 하지만 그 비효율은 전적으로 저희가 감당합니다. 다 바꿔드릴 수 있다는 전제로 진행하는 프로세스입니다. 클라이언트가 완성품에 가까운 결과물을 보고 판단할 수 있으니, "이게 아닌데" 하고 완전히 엎는 상황이 오히려 줄어듭니다.

정리

  • 디자인은 "예쁘게"가 아니라 "구조를 결정하는 것"
  • 디자인 없이 개발하면 재작업 비용이 발생
  • 기획 → 디자인 → 개발 순서를 지켜야 총비용이 줄어듦
  • MVP에서는 디자인의 수준을 낮출 수 있지만, 단계를 건너뛰면 안 됨

"디자인은 나중에"가 아니라, "디자인의 범위를 조절한다"가 올바른 접근입니다.

*기획부터 디자인, 개발까지 한 번에 진행하고 싶으시다면, 프로젝트 상담을 통해 문의해 주세요.*


디자인,기획,UX,개발프로세스
다른 포스팅
Blog·인사이트

디자인 없이 개발부터 하면 안 되는 이유

··4분 읽기

"일단 기능부터 만들어주세요. 디자인은 나중에 입혀도 되잖아요."

자주 듣는 말입니다. 예산을 아끼기 위해, 혹은 빨리 시작하고 싶어서 디자인 단계를 건너뛰려는 것입니다. 이해는 되지만, 대부분의 경우 이 순서가 총비용을 더 키웁니다.

"나중에 디자인 입히면 되지"의 문제

디자인은 "예쁘게 만드는 것"이 아닙니다. 디자인은 화면의 구조를 결정하는 것입니다.

화면 구조가 코드 구조를 결정한다

  • 메인 페이지에 탭이 3개인지 5개인지에 따라 네비게이션 컴포넌트 구조가 달라집니다
  • 목록을 카드형으로 보여줄지 테이블형으로 보여줄지에 따라 데이터 로딩 방식이 달라집니다
  • 모바일에서 메뉴를 어떻게 접을지에 따라 레이아웃 코드가 달라집니다

디자인 없이 개발하면, 개발자가 "아마 이렇게 되겠지"하고 가정해서 코드를 짭니다. 나중에 디자인이 나오면 — "아, 이 구조가 아니었네" — 코드를 뜯어고쳐야 합니다.

재작업 비용

디자인이 나중에 나와서 수정하는 비용은, 처음부터 디자인을 확정하고 개발하는 비용보다 큽니다. 이미 만들어진 코드를 수정하는 것은, 백지에서 새로 만드는 것보다 어렵습니다.

  • 레이아웃 변경 → HTML 구조부터 다시
  • 인터랙션 추가 → 상태 관리 로직 수정
  • 화면 흐름 변경 → 라우팅, API 호출 순서 변경

"디자인 비용 아꼈다"가 아니라, "재작업 비용을 추가했다"가 됩니다.

기획 → 디자인 → 개발, 이 순서가 중요한 이유

기획 단계

무엇을 만들 것인가. 어떤 기능이 필요하고, 사용자가 어떤 순서로 사용하는가. 화면 목록과 각 화면의 역할을 정리합니다.

디자인 단계

기획을 화면으로 옮깁니다. 와이어프레임으로 구조를 잡고, UI 디자인으로 최종 형태를 확정합니다. 이 단계에서 "이 버튼을 누르면 어디로 가는지", "이 데이터를 어떤 형태로 보여주는지"가 결정됩니다.

개발 단계

확정된 디자인을 보고 코드를 작성합니다. 구조가 명확하니 재작업이 최소화되고, 개발자가 추측할 필요가 없습니다.

이 순서를 지키면 한 번에 제대로 만들 확률이 높아집니다. 순서를 뒤집으면 반복 수정의 루프에 빠집니다.

디자인이 개발 구조에 영향을 주는 경우

"디자인이랑 개발은 별개 아니에요?" — 아닙니다.

무한 스크롤 vs 페이지네이션

디자인에서 무한 스크롤을 결정하면, 백엔드 API도 커서 기반 페이지네이션으로 설계해야 합니다. 일반 페이지네이션으로 만들어놓고 나중에 무한 스크롤로 바꾸면, API 구조부터 바꿔야 합니다.

실시간 업데이트

채팅이나 알림이 실시간으로 화면에 반영되어야 하는 디자인이면, 웹소켓이나 Server-Sent Events 같은 기술이 필요합니다. "나중에 실시간으로 바꿔주세요"는 아키텍처 수준의 변경입니다.

반응형 디자인

모바일, 태블릿, 데스크톱에서 화면이 어떻게 변하는지가 디자인 단계에서 결정되어야 합니다. 데스크톱만 보고 만들어놓고 "모바일도 되게 해주세요"는, 레이아웃을 거의 새로 만드는 작업입니다.

다만, MVP에서는 예외가 있다

모든 프로젝트에서 완벽한 디자인이 필요한 것은 아닙니다.

MVP(최소 기능 제품) 단계에서는 최소한의 디자인으로 시작하는 것이 합리적입니다.

  • 와이어프레임 수준: 구조만 잡고, 비주얼 디자인은 나중에
  • UI 키트 활용: Material UI, Tailwind CSS 같은 기존 디자인 시스템 활용
  • 핵심 화면만 디자인: 메인 페이지, 핵심 기능 화면만 디자인하고, 나머지는 템플릿

중요한 것은 디자인의 수준을 낮추는 것이지, 디자인 단계를 건너뛰는 것이 아닙니다. 와이어프레임 수준이라도 화면 구조가 확정되어야 개발자가 올바른 방향으로 코드를 작성할 수 있습니다.

프로덕트 메이커의 방식은 좀 다릅니다

위에서 기획 → 디자인 → 개발 순서가 중요하다고 했지만, 저희는 실제로 조금 다르게 진행합니다.

저희는 요구사항을 정리하고 프로세스를 소통한 뒤, 바로 디자인하고 개발을 붙인 동작하는 결과물을 보여드립니다. 정적인 기획 문서나 디자인 이미지를 넘기는 게 아니라, 실제로 클릭하고 움직이는 화면을 먼저 공유합니다.

왜 이렇게 하느냐면, 기획서나 정적 디자인 이미지로 보는 것보다 동작하는 결과물, 인터랙션, 실제 UI/UX를 직접 만져보는 것이 소통에 훨씬 효과적이기 때문입니다. 클라이언트가 "아 이런 느낌이구나"를 즉시 체감하고, 거기서 피드백을 주시면 저희가 개선합니다.

물론 이 방식에서 일부 비효율이 발생할 수 있습니다. 피드백을 반영하면서 코드를 수정해야 하니까요. 하지만 그 비효율은 전적으로 저희가 감당합니다. 다 바꿔드릴 수 있다는 전제로 진행하는 프로세스입니다. 클라이언트가 완성품에 가까운 결과물을 보고 판단할 수 있으니, "이게 아닌데" 하고 완전히 엎는 상황이 오히려 줄어듭니다.

정리

  • 디자인은 "예쁘게"가 아니라 "구조를 결정하는 것"
  • 디자인 없이 개발하면 재작업 비용이 발생
  • 기획 → 디자인 → 개발 순서를 지켜야 총비용이 줄어듦
  • MVP에서는 디자인의 수준을 낮출 수 있지만, 단계를 건너뛰면 안 됨

"디자인은 나중에"가 아니라, "디자인의 범위를 조절한다"가 올바른 접근입니다.

*기획부터 디자인, 개발까지 한 번에 진행하고 싶으시다면, 프로젝트 상담을 통해 문의해 주세요.*


디자인,기획,UX,개발프로세스
다른 포스팅
WebGL프로젝트 상담