이전 경력 — 포그리트(4grit) 시기

포그리트에서 AngularJS 기반 뷰저블 툴을 Vue로 전면 리팩토링했습니다. 원칙은 두 가지였어요. 첫째, 빅뱅 전환은 안 한다 — 라이브 서비스라 일정 단위로 멈출 수 없어서 페이지 단위로 자연스럽게 전환하는 점진 전략을 택했습니다. 로그인 → 대시보드 → 페이지 CRUD → 리포트 순으로 한 페이지씩 Vue로 옮겼고, 한 시점엔 두 프레임워크가 라우트 단위로 공존했어요.

둘째, 3회 이상 반복되는 UI는 공용 컴포넌트로 추출한다는 룰을 정해 두고 진행했습니다. Input, Button, Modal, Select, Loading 같은 컴포넌트가 그렇게 만들어졌어요. 처음엔 단순한 prop 인터페이스로 시작해 화면 요구가 들어올 때마다 점진적으로 확장하는 방향이었습니다.

회고하자면, 점진 전환이 안전하지만 공용 컴포넌트 초기 설계가 너무 단순하면 나중에 변형 요구가 누적되며 다시 깨질 수 있다는 걸 배웠어요. 이 학습이 이후 CLO에서 디자인 시스템 v1 → v2 (Compound Component) 전환의 사고로 이어졌습니다.

삼성의 글로벌 사이트가 SWCAG라는 자체 가이드라인(WCAG 2.1 기반)을 따르는데, 매 반기마다 외부 검수단이 들어가서 이슈를 점검하는 작업이 있었어요. 저는 그 검수단의 일원으로 상·하반기 2회씩 참여해서 페이지 전체를 SWCAG 기준으로 점검하고 수정·개선 방향을 제안하는 역할을 했습니다.

자주 발견됐던 이슈는 네 가지 패턴이었어요. (1) 키보드 네비게이션 깨짐 — 마우스로는 동작하지만 Tab으로는 도달 못 하는 카르셀 컨트롤, (2) ARIA 속성 오용 — role="button" 만 붙여 두고 tabindex를 안 주거나 키보드 핸들러가 없는 케이스, (3) 명도 대비 미달 — 4.5:1 기준에 미치지 못하는 회색 보조 텍스트, (4) 스크린 리더용 대체 텍스트 누락 — 장식용 이미지에 alt가 없거나 정보성 이미지에 빈 alt가 들어간 케이스.

이 작업이 제게 남긴 가장 큰 학습은 **"접근성은 별도 작업이 아니라 컴포넌트 기본 덕목"**이라는 사고였어요. 이후 CLO에서 디자인 시스템을 만들 때부터 컴포넌트 단위로 키보드 핸들러·ARIA 속성·focus 관리를 기본 인터페이스에 포함시켰고, 토스증권 같은 금융 서비스에선 이 사고가 더 중요하다고 봅니다.

뷰저블리 툴 페이지의 스타일이 모든 페이지를 단일 CSS 파일에서 관리하는 상태였어요. 코딩 컨벤션이 없어서 비슷한 UI인데 클래스명이 페이지마다 다르고, 새 화면을 만들 때 어떤 클래스를 재사용할 수 있는지 파악이 어려웠습니다. 가독성·유지보수성 둘 다 떨어지는 상태였어요.

리팩토링은 두 단계로 갔어요. 첫째, BEM 방법론 참고로 클래스 네이밍 통일 — block__element--modifier 형태로 같은 의미의 UI는 같은 이름이 되도록 정리. 팀 전체 컨벤션을 정립하기 전에 일단 네이밍부터 맞추니 코드 리딩이 즉시 좋아졌어요. 둘째, 단일 CSS → SCSS 모듈화 — 색상·간격·타이포 같은 공통 값을 변수로, 자주 쓰이는 패턴(미디어 쿼리, 그라디언트 등)을 믹스인으로 분리해서 재사용 가능하게 만들었습니다.

회고하자면 "작은 규약이라도 일관성이 큰 효과를 만든다"는 걸 체감한 작업이었어요. 컴포넌트 추상화나 빌드 시스템 같은 거대한 개선이 아니라 단순 네이밍 통일만으로도 팀의 코드 리딩 비용이 눈에 띄게 줄었습니다. 이 사고가 이후 CLO 디자인 시스템에서 토큰·시맨틱 네이밍을 강조하는 방향으로 이어졌습니다.

한국어·일본어·영어 세 언어를 한 페이지에서 지원하는 랜딩이라, 같은 박스 안에 들어가는 텍스트 길이가 언어마다 30~50% 차이가 났어요. 콘텐츠 박스 크기를 고정하면 어느 언어에선 잘리고 어느 언어에선 빈 공간이 남는 문제가 즉시 생겼습니다. 일본어는 특히 화면 크기별로 줄바꿈을 세밀하게 맞춰야 자연스러워요.

핵심 해법은 두 가지였습니다. 첫째, px 대신 % / rem 위주 레이아웃. 박스를 콘텐츠 길이에 따라 늘어나도록 만들고, 부모는 비율로 배치해서 언어별로 자연스럽게 적응되게 했어요. 둘째, 언어별 예외 분기를 코드 레벨에서 줄이기 위해 디자이너와 사전 협의. 처음부터 "이 카피의 일본어 길이가 한국어 대비 X% 길어지는데 이 박스에서 받을 수 있나"를 디자이너와 같이 검증해서, 카피 자체를 다듬거나 박스 자체를 유연하게 설계하는 식으로 풀었습니다.

회고하자면, 반응형·다국어는 코드로 푸는 일보다 콘텐츠와 디자인 의사결정에서 풀리는 비율이 훨씬 크다는 걸 배웠어요. 코드는 콘텐츠 변동에 견고하게 대응하면 되고, 변동의 폭 자체는 초기 설계에서 좁혀야 한다는 사고입니다.