들어가며

프로젝트 초반, 기획서는 정제되어 있었고 디자인도 군더더기 없이 잘 다듬어져 있었습니다.
정리된 시안을 보면 누구든 이렇게 생각할 수 있습니다.
"이 정도면 그냥 그대로 구현만 하면 되겠네."
하지만 실제 개발을 시작해 보면, 오히려 이런 ‘완벽한 시안’이 더 복잡한 구현 문제를 유발하는 경우도 있습니다.
기획과 디자인에서 정리되지 않은 여백은 결국 프론트엔드 개발자의 판단과 설계로 채워지게 되며,
그 과정에서 예상치 못한 간극들이 드러납니다.

 

 

1. 기획과 디자인은 ‘정적인 스냅샷’, 구현은 ‘동적인 흐름’

• 정상 데이터가 있을 때
• 특정 화면 크기에서의 UI
• 정상적인 사용 흐름을 전제로 한 UX

하지만 실제 구현은 그보다 훨씬 더 다양한 상태와 흐름을 감안해야 합니다. 
예를 들면,

• 로딩 중 상태, 에러 상태, 빈 상태 등 비정상 상황 처리
• 텍스트 길이가 길거나 짧을 때의 레이아웃 변화
• 모바일과 데스크탑, 다양한 뷰포트 대응
• 빠른 사용자 조작(예: 더블 클릭, 연속 탭)에 대한 대응

이런 부분은 대개 기획서에 명시되지 않으며, 프론트엔드 개발자가 직접 해석하고 구현 방식까지 결정해야 합니다.

 

2. 디자인 시스템이 있어도, 엣지 케이스는 항상 존재한다.

디자인 시스템이 있는 프로젝트라고 해서 항상 깔끔하게 흘러가진 않습니다.
실제로는 시스템 외의 요청들이 적지 않게 발생합니다.
예를 들면,

• “전체적으로 radius는 4px인데, 이 경우만 8px로 해주세요.”
• “이건 기존 alert랑 거의 똑같은데 animation만 살짝 다르게요.”
• “이 패턴은 처음이긴 한데, 이번 캠페인 한정으로만 쓸 거예요.”

이렇게 시작된 일회성 예외가 반복되면,
기존 컴포넌트를 수정할지, 새로운 컴포넌트를 만들어야 할지 판단이 필요해지고,
결정에 따른 부작용이나 유지보수 리스크도 함께 따라옵니다.
디자인 시스템은 일관성을 지키기 위한 도구지만, 현실에서는 각 팀의 요구나 프로젝트 상황에 따라 예외가 만들어지고, 쌓이기 시작합니다.

 

3. UI는 ‘상태의 집합’이라는 점이 종종 간과된다.

기획과 디자인은 주로 ‘정상 상태’에 집중되어 있습니다.
하지만 UI를 구현할 때는 그 외에도 다양한 상태를 고려해야 합니다.

• 네트워크 지연으로 인한 로딩 상태
• API 응답 실패로 인한 에러 상태
• 콘텐츠가 없거나 권한이 없을 때의 예외 화면
• 다국어 대응 시 텍스트 길이 차이
• 반응형 디자인에서 발생하는 레이아웃 깨짐

이런 상태들은 설계에 명시되지 않거나, 디자인 없이 구현을 요구받는 경우가 많습니다.
결국 개발자가 적절한 UX를 판단해 구현하게 되며, 그만큼 추가 커뮤니케이션과 반복적인 수정이 발생할 수밖에 없습니다.

 

4. 기획/디자인과 기술 사이에는 항상 간극이 있다

실제 실무에서는 다음과 같은 요청이 나오는 경우가 자주 있습니다:

• “이건 그냥 Figma처럼 나오면 돼요.”
• “이 정도 애니메이션은 CSS로 금방 넣을 수 있지 않아요?”
• “고정된 위치에 띄워만 주면 되는데 왜 어렵죠?”

이 말들 하나하나가 기술적으로는 브라우저의 제약, 플랫폼 간 차이, 성능 이슈, 접근성 문제 등 다양한 고려사항을 필요로 합니다.
하지만 전달 과정에서는 이런 제약이 드러나지 않기 때문에, 기획과 실제 구현 가능성 사이에서 괴리가 발생합니다.
프론트엔드 개발자는 이 간극을 기술적으로만이 아니라 커뮤니케이션으로도 메워야 하는 역할을 맡게 됩니다.

 

5. 눈에 보이는 결과만으로는 작업의 복잡도를 설명하기 어렵다

한 줄짜리 스타일 수정이라도, 그 한 줄을 어떻게 구현할지 고민하고, 기존 UI 흐름과 충돌하지 않게 조정하며, 디자인 시스템에 맞게 적용하는 과정은 단순하지 않습니다.
하지만 결과물만 보면,

• “요소 하나 추가한 거 아닌가요?”
• “그냥 여백만 좀 맞춘 것 같은데요?”
• “글자 크기만 수정된 거네요.”

같이 보일 수 있습니다.
프론트엔드 개발자 입장에서 이럴 때 가장 어려운 점은, “왜 이렇게 오래 걸렸는지”를 설명하기 위한 에너지까지 필요하다는 것입니다.

 

마치며

기획과 디자인이 아무리 정교하더라도, 그것이 바로 구현 가능한 형태는 아닙니다.
특히 프론트엔드에서는 화면의 상태, 사용자 흐름, 디바이스/브라우저 간 차이, 기술 제약 등 수많은 현실적인 조건을 조율해야 합니다.
결국 프론트엔드 개발은 단순한 ‘기획 이행’이 아니라, 기획과 실제 사용자 경험 사이의 간극을 조율하는 고유한 역할입니다.
그 간극을 줄이기 위해서는 단지 코드를 잘 짜는 것뿐만 아니라,
기획자·디자이너와의 커뮤니케이션, 맥락 이해, 예외 대응 능력 등이 함께 필요함을 다시 한번 곱씹게 되었습니다.
이 글을 통해, 그 조율의 복잡함과 가치에 대해 한 번쯤 생각해볼 계기가 되었으면 하는 바램으로 마칩니다.

감사합니다.