기획 디자인 개발 간극

pxd UX Engineer hsunj는 "정제된 기획서와 잘 다듬어진 디자인 시안이면 그대로 구현만 하면 된다"는 통념을 반박하며, 오히려 완벽해 보이는 시안일수록 구현 단계에서 더 복잡한 문제를 유발하는 경우가 많다고 짚는다. 기획과 디자인이 정리하지 않고 남긴 여백은 결국 프론트엔드 개발자의 판단과 설계로 채워지며, 그 과정에서 예상치 못한 간극이 드러난다는 것이 이 글의 핵심 문제의식이다.

간극의 첫 번째 원인은 기획·디자인은 '정적인 스냅샷'이지만 구현은 '동적인 흐름'이라는 데 있다. 기획서와 디자인은 정상 데이터, 특정 화면 크기, 정상적인 사용 흐름을 전제로 만들어지지만, 실제 구현은 로딩 중·에러·빈 상태 같은 비정상 상황, 텍스트 길이 변화에 따른 레이아웃 변화, 모바일·데스크탑 등 다양한 뷰포트, 더블 클릭 같은 빠른 사용자 조작까지 감안해야 한다. 이런 부분은 기획서에 명시되지 않는 경우가 많아, 개발자가 직접 해석하고 구현 방식을 결정해야 한다.

두 번째 원인은 디자인 시스템이 있어도 엣지 케이스는 항상 존재한다는 점이다. "이 경우만 radius를 8px로", "기존 alert와 거의 같은데 애니메이션만 다르게", "이번 캠페인 한정 패턴" 같은 일회성 예외 요청이 반복되면, 기존 컴포넌트를 수정할지 새로 만들지 판단이 필요해지고 그에 따른 유지보수 리스크가 함께 따라온다. 디자인 시스템은 일관성을 위한 도구이지만, 현실에서는 팀별 요구와 프로젝트 상황에 따라 예외가 쌓여간다.

세 번째로, UI는 '상태의 집합'이라는 점이 종종 간과된다. 네트워크 지연에 따른 로딩 상태, API 실패에 따른 에러 상태, 콘텐츠·권한 부재에 따른 예외 화면, 다국어 대응 시 텍스트 길이 차이, 반응형 레이아웃 붕괴 등은 설계 단계에 명시되지 않거나 디자인 없이 구현을 요구받는 경우가 많다. 결국 개발자가 적절한 UX를 판단해 채워 넣게 되며, 이는 추가 커뮤니케이션과 반복 수정으로 이어진다.

기획·기술 사이의 간극은 소통 층위에서도 나타난다. "그냥 Figma처럼 나오면 된다", "CSS로 금방 되지 않냐", "고정 위치에 띄우기만 하면 되는데 왜 어렵냐"는 요청은 실제로는 브라우저 제약·플랫폼 차이·성능·접근성 등 복합적인 기술 고려사항을 감춘 채 전달된다. 프론트엔드 개발자는 이 간극을 기술적으로만이 아니라 커뮤니케이션으로도 메워야 하는 역할을 떠맡는다. 눈에 보이는 결과물만으로는 작업의 복잡도를 설명하기 어렵다는 점도 지적된다 — 한 줄짜리 스타일 수정이라도 기존 UI 흐름과의 충돌, 디자인 시스템 정합성까지 고려해야 하지만, 겉보기에는 "요소 하나 추가한 것"처럼 보여 왜 오래 걸렸는지를 설명하는 데 별도의 에너지가 든다.

결론적으로 프론트엔드 개발은 단순한 '기획 이행'이 아니라, 기획과 실제 사용자 경험 사이의 간극을 조율하는 고유한 역할이라는 것이 이 글의 메시지다. 이 간극을 줄이려면 코드 역량뿐 아니라 기획자·디자이너와의 커뮤니케이션, 맥락 이해, 예외 대응 능력이 함께 필요하다.

핵심 내용

  • 완벽해 보이는 기획·디자인 시안일수록 오히려 구현 단계에서 더 복잡한 문제를 유발할 수 있음
  • 기획·디자인은 정적인 스냅샷(정상 데이터·특정 화면 크기·정상 흐름), 구현은 동적인 흐름(로딩·에러·빈 상태, 뷰포트 대응, 빠른 조작)
  • 디자인 시스템이 있어도 일회성 예외 요청이 누적되며 컴포넌트 수정 여부 판단과 유지보수 리스크가 따라옴
  • UI는 상태의 집합: 로딩·에러·빈 상태·다국어·반응형 붕괴 등은 대개 설계에 명시되지 않아 개발자가 직접 판단해야 함
  • "Figma처럼", "CSS로 금방" 같은 요청은 브라우저 제약·성능·접근성 등 실제 기술 고려사항을 가림 — 개발자는 기술과 커뮤니케이션 양쪽으로 간극을 메워야 함
  • 결과물만으로는 작업 복잡도가 드러나지 않아, "왜 오래 걸렸는지"를 설명하는 것 자체가 추가 부담이 됨
  • 프론트엔드 개발은 '기획 이행'이 아니라 기획과 실제 사용자 경험 사이의 간극을 조율하는 고유한 역할

관련 개념

출처

최종 업데이트: 2026-09-07 | 출처 1개