14주차에 대하여
회고 공략에 대하여
지난주 저는 스스로에게회고를 작성하지 않으면 동기들에게 커피를 대접한는 공약을 걸었습니다. 이 단순한 약속이 생각보다 큰 심리적 동인이 되었고 일요일 늦은 저녁이 되어도 회고를 반드시 마쳐야 한다는 강한 의지를 부여했습니다.
비록 커피를 대접하는 일 자체는 즐거운 경험이지만 자발적으로 스스로에게 제약을 부여하는 것이 실제 실행력을 높인다는 사실을 체감할 수 있었습니다.
앞으로 꾸준한 기록 습관을 만들고 싶은 분들께 자발적 공약 설정을 강력히 추천드리고 싶습니다.
피그마 UI 설계
이번 주는 특히 피그마를 통한 UI 설계에 많은 시간을 할애했습니다.
현재 저희 팀은 약 154개의 API를 관리하고 있으며 이 중 45개의 API와 그에 따른 페이지 설계를 담당하고 있습니다.
전공 시절 2주간 20개를 넘는 페이지를 만들어본 경험이 있었지만 이번에는 그 두 배를 넘어서는 분량을 혼자 소화해야 하는 상황이었습니다.
기존 방식으론 설계를 완수하는 것이 사실상 불가능하다고 판단하였고 여러 방법을 찾던중 html.to.design 플러그인을 발견했습니다. 해당 플러그인은 HTML+CSS로 구축한 페이지를 피그마로 변환해주는 기능을 제공하고 더 놀라운 것은 Flexbox 구조까지 인식하여 초벌 설계를 빠르게 완성할 수 있게 도와준다는 것이었습니다.
하지만 자동화로 생성된 결과물은 역시나 유지보수성이 떨어진다는 문제가 있었고 이를 보완하기 위해 우선 피그마를 다시 공부하게 되었고 과거 기억들을 스멀스멀 다시 가져와서 Auto Layout과 컴포넌트화 기능을 사용하여 플러그인이 만들어주는 산출물에서 유사한 구조를 컴포넌트로 추출하고 디자인 토큰을 정리하여 재사용성과 통일성을 높일 수 있었습니다.
결과적으로 저는 일주일 만에 45개 이상의 페이지를 도출할 수 있었고 많은 페이지를 만들다 보니 자주 쓰는 색상이나 글꼴, 여백과 같은 것들을 정리해야 겠단 생각을 하게 되었고 이를 기반으로 디자인 시스템을 도출하여 자연스럽게 하나의 통일된 톤 앤 매너를 갖춘 어플리케이션을 만들 수 있게 되었습니다.
저는 서비스 전체의 레이아웃이 일관되어야 사용자 경험이 좋아진다라고 생각하는편입니다. 그래서 레이아웃의 경우에도 개발 관점에서의 효율성 뿐만 아니라 디자인 일관성과 통의성을 통한 사용자 경험을 높이기 위해 레이아웃을 크게 세가지 유형으로 나눠보았습니다.
레이아웃 유형 세가지
- 사이드바 + 메인형(마이페이지, 사업자 마이페이지)
- 독립형 메인형(포인트 충전, 환불 등)
- 풀스크린 중앙정렬형(로그인, 회원가입, 복구신청 등)
계속해서 반복한 페이지들의 공통적인 레이아웃을 쪼개봤을 때 위의 세개의 레이아웃에 포함된다는 것을 알게 되었고 각각의 유형에 대해 넓이, 높이, 패딩, 마진 등을 설정하고 그 안에 main만 변경하다보니 매우 효율적으로 페이지를 추가할 수 있게 되었고 이 뿐만이 아니라 통일된 어플리케이션을 구성하게 되어 개발 효율성과 유지보수성을 크게 끌어올리면서 사용자 경험도 높일 수 있는 설계를 할수 있게 된 것 같아 매우 큰 기쁨을 느끼게 되었습니다.
그리고 저는 프론트엔드에선 사용자 중심 UI 설계가 매우 중요하다고 생각하고 이탈률 최소화와 직관성 강화를 위해 모임 개설처럼 입력해야 할 정보가 많은 플로우에서 한 화면에 모든 정보를 입력받게 하면 이탈률이 증가한다는 것을 UX 원칙에서 학습한 바 있어 다음과 같은 방식으로 해결하게 되었습니다.
문제해결 방법
- 정보를 세 단계로 나누어 받는 구조로 설계하기
- 각 단계별로 명확한 피드백을을 주기
- 선택한 버튼에 색상 변화를 주어 직관성을 강화하기
- 모바일 사용성을 고려하여 모든 버튼/입력 요소의 터치 영역을 최소 44px 이상 확보하기
이를 통해 결과적으로 사용자의 피로도도 낮추고 이탈률을 낮추는 UI 흐름을 구축할 수 있게 되었습니다.
리액트와 Vue의 차이
이번 주는 Vue.js를 처음 접하게 되었습니다. 처음에는 JSX의 부재, 번거로운 속성 설정 등으로 인해 Vue에 부정적인 인상을 받았습니다. 하지만 양방향 바인딩을 경험하면서 생각이 바뀌었습니다. React에서는 상당한 수작업이 필요한 바인딩 작업을 Vue는 자연스럽게 처리해주었고 학습 진입 장벽이 낮은 프레임워크라는 Vue의 특성을 직접 체감할 수 있었습니다.
그리고 익숙한 기술을 넘어서 다른 프레임워크의 사고방식을 접하는 것은 성장에 크게 도움이 된다는 것을 다시한번 깨닫게 되는 경험이었던 것 같습니다.
토스 api를 보면서
어쩌다가 토스 api 설계에 대한 설명을 해주는 토스에서 제공하는 공식 유튜브 영상을 보게 되었는데 정말 많은 깨달음을 얻게 되었습니다.
제가 해당 영상에서 확인하기론 온라인 결제가 필요한 가맹점의 경우에 PG 시스템을 통해 카드사 인증 호출부터 승인, 매입 처리 등을 진행하게 되는데 기존 PG 연동의 경우에 가맹점 서버에 의존이 생기는 모듈을 설치해야만 했고 이해하기 힘든 요청 / 파라미터들을 넘기도록 해서 고객 중심으로 보면 조금 아쉬운점이 있는 서비스를 제공했고 토스페이먼츠는 결제 자체와 연관된 경험뿐만 아니라 가맹점의 기술적인 개발 경험도 중요하다고 판단하여 이러한 불편을 개선하기 위한 전략이 필요하다고 판단하였고 모든 시스템을 변경하는 것은 기존 레거시 코드나 배포 환경, 관련 데이터 센터 등에 갑자기 큰 변경을 가하는 것이므로 기존 가맹점이 아닌 신규 연동 개발 가맹점을 대상으로만 개편된 연동 SDK를 점차 제공하는 방식을 채택하고 기존에 복잡했던 모든 일련의 과정들은 삭제하고 토스페이먼츠의 SDK와 서비스 서버레이어에서 최대한 대신 수행하고 외부로 드러나는 인터페이는 잘 포장해서 새로운 가맹점이 쉽게 접근할 수 있도록 하는 방법을 제공하는 것으로 알고 있고 Payments API의 경우에 목표가 고객 편의를 우선시 하고 쉽고 간결한 디자인을 사용하기 위해 디자인 원칙을 설정했다고 하는데 저는 해당 부분이 너무 기억에 많이 남습니다.
저는 RESTful API는 CRUD와 Method Http Status가 일치해야 한다고 그냥 무조건 지켜야 하는 원칙처럼 생각한것에 반면에 토스페이먼츠는 오히려 RESTful Design을 고집하기 보단 HTTP 클라이언트 모듈이 DELETE, PUT 미지원하거나 가맹점 인프라, 방화벽 문제로 DELETE, PUT 불가한 상황들을 고려하여 NOT Pure RESTful API로 오로지 자원에 접근하는 경우에는 무조건 GET이고 자원을 변경하는 경우엔 POST로 처리하도록 설계한 부분이 매우 의아하면서도 의미있는 설계라는 생각이 들었고 일관성을 부여하기 위해 일부러 api에 대한 Request와 Response를 일치시켜 클라이언트가 인터페이스를 쉽게 사용하도록 설계했다는 부분도 매우 영감을 받는 부분이었습니다.
마무리
이번 주는 UI/UX 설계, 디자인 시스템 정비, 프론트 기술 스택 확장, API 철학에 대한 고민 등 다양한 관점에서 깊은 통찰과 실질적인 성장 경험을 얻은 주였습니다.
백엔드 공부를 하면서 아키텍처에 대한 고민을 많이 하게되고 즐거움을 느끼게 되었는데 어쩌다보니 프론트엔드에서도 디자인 시스템을 구축한다던가 컴포넌트 설계를 하는 식의 유지보수성을 높이는 방법에 대해 계속 고민하게 되고 지금은 안정적이지 않거나 효율적이지 않은 코드를 보면 넘어가질 못하는 정도가 되었습니다.
하고 싶은 것이 너무나도 많은 주였지만 아쉽게도 시간이라는 제한 속에서 늘 부족함을 느끼며 한주가 지나가버렸지만 다음주엔 휴일도 많으니 꼭 다음 단계들을 수행해보고자 합니다.
15주차 목표
- 디자인 시스템 최종 정리 및 문서화
- API 설계 가이드 작성
- Figma 컴포넌트 체계화 및 재정비
- Vue와 React를 비교하는 깊이 있는 기술 블로그 작성
- 테스트 코드 모두 작성
- MSA Configure 서버 구성
