결제 플랫폼 신규 화면을 피그마 디자인과 1:1로 재현한 과정
목차
이커머스 PG 플랫폼에 새로운 기능 화면이 필요했고, 디자이너가 피그마에 정리한 디자인을 1:1로 재현하는 작업을 마쳤다. 단순히 "기능을 구현했다"라기보다, 디자인 가이드와 실제 웹 화면 사이의 갭을 최소화하는 데 신경 쓴 시간이었다.
디자인 정확도, 왜 이렇게 중요한가
피그마 디자인을 개발자가 "대충" 해석해서 구현하면 어떻게 될까. 버튼 크기가 2-3px 달라지고, 여백이 생각과 다르고, 폰트 색상이 약간 오프되고… 사용자 입장에서는 "어라, 뭔가 어색한데?" 같은 위화감이 생긴다. 특히 결제 플랫폼처럼 신뢰도가 중요한 도메인에서는 이런 세심한 부분이 신뢰성 인상에도 영향을 미친다.
이번에는 처음부터 "피그마 디자인을 엄격하게 따르자"는 기준을 잡았다. 버튼의 패딩, 아이콘 크기, 글자 줄 높이, 색상값까지 직접 피그마에서 수치를 확인하고 CSS/JSP에 반영했다. 몇몇 항목에서는 디자인과 현실의 렌더링 차이가 있어서 (예: 텍스트 안티앨리어싱, 수치 미세 조정) 디자이너와 여러 번 확인하고 조정하는 과정이 있었다.
구조 설계: 레이아웃과 컴포넌트의 조화
| 계층 | 역할 | 파일 |
|---|---|---|
| 컨트롤러 | 비즈니스 로직, 데이터 조회 | 내부 클래스 |
| 메인 레이아웃 | 전체 페이지 프레임 | mainLayout.jsp |
| 서브 레이아웃 | 섹션별 영역 | subLayout.jsp |
| 신규 화면 | 기능별 본체 | tickettaka.jsp |
| 헤더 컴포넌트 | 화면별 헤더 | tickettaka/_head.jsp |
| 공통 UI | 전역 네비게이션 | quickMenu.jsp |
JSP 구조를 계층적으로 나눈 이유는 재사용성과 유지보수성이다. 예를 들어, quickMenu 같은 공통 컴포넌트는 여러 페이지에서 쓰이므로 변경이 생기면 한 곳만 수정하면 된다. 반대로 신규 화면 특화 로직(tickettaka.jsp)은 별도로 두어서 다른 기능에 영향을 주지 않게 했다.
// 컨트롤러에서 데이터 조회 후 모델에 담아서 JSP로 전달
// 예: 디자인에 필요한 메뉴 항목, 상태값 등
model.addAttribute("menuList", fetchMenuItems());
model.addAttribute("initialState", getDefaultState());
팀 협업과 실제 배운 점
디자이너와 개발자 사이에 항상 작은 오해가 생기곤 한다.
- 디자이너는 이상적인 렌더링을 상정하고,
- 개발자는 브라우저의 현실적 제약(폰트 렌더링, 스크롤바 등)을 고려한다.
이번 작업에서는 초반에 "이 정도면 비슷하지 않나?"라는 생각으로 진행했다가, 중간에 디자이너가 "여기 3px 차이 나는데요"라고 지적하면서 보정의 반복이 생겼다. 이걸 번거로움이 아니라 "정확도 높이기"로 재프레임했을 때, 팀 간 소통이 훨씬 부드러워졌다.
결국 배운 점:
- 초기 요구사항 시점부터 "1:1 재현"을 명시하기 — 애매한 "비슷하게"보다 명확한 기준이 있으면 리뷰가 빠르다.
- 피그마 수치를 코드 주석으로 남기기 — 나중에 수정할 때 왜 이 값인지 빠르게 파악할 수 있다.
- 초반 프로토타입 리뷰를 충분히 하기 — 마무리 단계에 큰 수정이 생기는 것보다 훨씬 효율적이다.
다음에 비슷한 작업이 오면
신규 화면을 만들 때는 이런 체크리스트를 먼저 확인한다:
- 컨트롤러에서 필요한 데이터 구조 설계 (피그마와 함께 검토)
- 레이아웃 계층 구분 (공통/신규/섹션별)
- CSS 변수 또는 주석으로 디자인 근거 기록
- 초기 완성도 80% 단계에서 디자인 팀과 함께 스크린샷 비교
이번 작업이 단순한 "기능 추가"가 아니라 디자인-개발 협업 프로세스를 다시 정렬하는 기회가 됐다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.