류기현

기존 디자인 시스템은 컴포넌트마다 API와 스타일링 방식이 달랐습니다. 제품에서 필요한 스타일을 적용하려고 내부 DOM을 직접 선택해 덮어쓰는 경우도 있었고, 작은 요구사항에도 디자인 시스템을 수정하고 다시 배포해야 했습니다.

제품별 요구사항을 디자인 시스템에 계속 추가하는 방식보다, 공통 컴포넌트는 책임을 명확히 하고 제품에서 필요한 부분은 안전하게 조합할 수 있게 만드는 것이 낫다고 판단했습니다. 컴포넌트 API와 스타일링 컨벤션을 다시 정의하고, 기존의 간편한 사용 방식과 조합 가능한 형태를 함께 제공했습니다.

제품 코드가 디자인 시스템의 내부 구현에 직접 의존하는 경우를 줄이고, 컴포넌트를 수정하지 않고도 제품에서 필요한 UI를 조합할 수 있는 방향으로 구조를 바꿨습니다.

아이콘과 디자인 토큰의 변경 사항을 사람이 확인하고 코드로 옮기고 있었습니다. 기존 아이콘 변경 이력을 분석해보니 갱신 간격은 평균 90일이었고, 임의 시점의 예상 대기 기간은 64일이었습니다. 개편 당시에는 Figma의 아이콘 376개 중 245개만 코드에 반영돼 약 35%가 누락된 상태였습니다.

누락분을 한 번 정리하는 것보다 같은 문제가 다시 쌓이지 않게 만드는 것이 중요하다고 생각했습니다. 디자인 자산을 코드와 전체 동기화하고, 이후 변경 감지부터 코드 생성, 변경 내역 작성, PR 생성까지 이어지는 파이프라인을 구축했습니다.

아이콘 반영률을 65%에서 100%로 높였고, 분기 단위로 발생하던 반영 대기를 수일 수준으로 줄였습니다. 구축에는 12작업일이 들었고, 반복 작업 절감까지 포함하면 1년 이내에 구축 비용을 회수할 수 있습니다.

공통 모달 개편을 앞두고, 리뷰와 QA의 완성도를 높이고자 제품에서 영향을 받는 화면을 조사했습니다. 단순 사용처는 코드 검색으로 찾을 수 있었지만, 실제 진입 경로와 노출 조건, 제품별 수정 정도, 변경 위험도는 코드를 직접 읽어야 판단할 수 있었습니다.

사람이 리뷰할 때 확인하던 내용을 15개 항목으로 나누고, AI가 저장소의 코드 맥락을 읽어 같은 형식으로 결과를 작성하도록 했습니다. 사용 위치, 진입 경로, 노출 조건처럼 코드 맥락이 필요한 부분은 AI가 맡고, 결과 형식과 중복 여부처럼 규칙으로 판단할 수 있는 부분은 코드로 다시 검증했습니다.

3일 동안 4개 제품에서 132건의 모달 사용 사례를 확보했고, 이 중 36건인 약 27%는 서버 오류, 시간 초과, 유효성 검사 실패처럼 정상적인 화면 흐름만 따라가서는 놓치기 쉬운 사용처였습니다.

사용처를 찾아도 코드 위치만 나열하면 리뷰어가 다시 제품을 열어 진입 경로와 위험도를 확인해야 했습니다.

저장소별 결과를 자동으로 모으고 유형, 위험도, 확인 여부에 따라 탐색할 수 있는 대시보드를 만들었습니다. AI가 판단한 내용에는 근거와 확신도를 함께 남겼습니다.

코드 리뷰에서 변경 코드와 함께 제품별 사용 맥락을 확인할 수 있게 했고, 같은 자료를 디자인 QA에서도 사용해 개발과 디자인이 동일한 범위를 검토하도록 도왔습니다.

PC에서는 마우스 버튼과 키보드로 확대, 이동, 측정을 구분할 수 있었지만 태블릿에서는 모두 손가락 터치로 시작했습니다. 실제로 핀치 확대 중 측정점이 생기거나 그래프를 이동하려다 측정이 시작되는 문제가 있었습니다.

터치가 시작된 순간 바로 기능을 정하지 않고, 유지 시간과 이동 거리, 손가락 수를 보고 사용자의 의도를 판단하도록 했습니다. 한 동작이 시작된 뒤에는 다른 기능이 같은 입력을 동시에 처리하지 않도록 공통 제어 상태를 두었습니다.

확대, 이동, 측정, 정밀측정, 도구 드래그가 같은 화면 위에서 동작하더라도 서로 입력을 빼앗거나 동시에 실행되는 문제를 줄였습니다.

심전도 그래프에서는 화면 좌표가 실제 시간과 전압 값으로 변환되기 때문에, UI가 자연스럽게 움직이는 것뿐 아니라 측정 좌표가 정확해야 했습니다. 핀치와 스크롤 간섭처럼 실제 브라우저 런타임에서만 확인 가능한 문제도 있었습니다.

좌표 변환과 상태 로직은 단위 테스트로 분리하고, 입력에 따른 상태 전이와 측정점 생성·제거, UI 변화는 브라우저 통합 테스트로 검증했습니다. 모바일 디바이스 에뮬레이션에서는 핀치 줌과 측정 충돌, 스크롤 간섭도 함께 확인했습니다.

실제 터치 입력부터 화면 변화까지 이어지는 동작을 테스트하여 태블릿 환경의 오작동 가능성을 줄였습니다.

서버가 파일 전체를 압축한 뒤 응답하고 브라우저가 다시 후처리하는 구조에서 파일이 커질수록 요청이 실패했습니다. 1GB 파일을 처리할 때는 브라우저 메모리 사용량이 약 1.9GB까지 증가했습니다.

처음에는 네트워크 문제를 의심했지만 백엔드와 처리 과정을 확인하면서, 전체 파일이 준비될 때까지 기다리고 다시 메모리에 쌓는 구조 자체가 병목이라고 판단했습니다. 서버는 데이터를 생성되는 대로 보내고, 클라이언트도 받은 데이터를 메모리에 계속 쌓지 않고 가능한 환경에서는 바로 파일로 기록하도록 변경했습니다.

100MB부터 1GB까지 파일 크기와 동시 요청 수를 달리해 검증했으며, 기존 방식에서 실패하던 대용량 다운로드를 모두 완료할 수 있었습니다. 1GB 처리 시 브라우저 메모리 사용량도 수십 MB 수준으로 낮췄습니다.

다운로드 파일을 암호화해야 했지만, 비밀번호를 서버에 전달하지 않는 기존 보안 원칙을 유지해야 했습니다.

암호화에 필요한 후처리는 클라이언트에 남기되, 이 과정에서도 파일 전체를 한 번에 메모리에 올리지 않도록 스트림 단위로 처리했습니다.

비밀번호를 서버로 전달하지 않으면서도 대용량 파일 다운로드를 안정적으로 처리할 수 있는 구조를 만들었습니다.