KDS 운영

문제

2021년 제가 케이뱅크에 입사할 당시 KDS(Kbank Design System)는 시스템이라고 부르기 어려운 상태였습니다. Framer로 구성된 디자인 컴포넌트는 개발 컴포넌트와 전혀 연동되어 있지 않았고, 이 컴포넌트를 사용하는 이해관계자가 어느 부서의 어느 사람까지인지 작성된 것이 없었습니다. 한 마디로, 모든 것이 모호했습니다. 당시의 저는 문제를 3개로 압축하였습니다.

재사용 가능한 컴포넌트 부재. Framer는 컴포넌트 배포의 시점을 중앙에서 관리하는 것이 불가능합니다. 게다가 3년 전 케이뱅크 대부분의 제품은 이를 가져다 Detach 해서 썼고, UI는 제품마다 조금씩 다르게 그려져 있었습니다.

Foundation 부재. 색·타이포그래피·그림자 같은 기초 값이 규칙 없이 정해지다 보니, 컴포넌트를 아무리 정리해도 다시 파편화가 일어났습니다. 이 글에서는 그중 재사용 요구가 가장 컸던 컬러를 중심으로 설명합니다.

컴포넌트 단위 설계 인프라 부재. 디자인에서 "쓸 수 있다"고 정의한 컴포넌트라도, 개발에서는 모두 다른 형상으로 설계할 수밖에 없는 상황이었습니다.

접근

Framework 전환

2025년, 케이뱅크는 기존 프레임워크인 IB20에서 React로 넘어가는 대규모 프론트엔드 전환 프로젝트를 시작했습니다. IB20은 한국 이니텍이 개발한 상용 웹 프레임워크 솔루션으로, 주로 국내 금융 회사가 사용합니다. 이 시점 전환 구축사는 모든 화면에서 사용 가능한 공통 컴포넌트 설계 기준이 필요한 상태였습니다. 마침 케이뱅크는 Figma를 도입하던 시기였기에, Framer의 컴포넌트 전체를 Figma 용도로 전환하면서 아래의 기준을 적용했습니다.

• SASS 클래스 재사용 우선순위 설정. 어떤 클래스가 어떤 스타일을 사용하고, 해당 스타일이 얼만큼 자주 사용되는지를 파악해 컴포넌트와 이름을 구성하였습니다.
• Figma를 기준으로 컴포넌트 단위 스타일 수정 가능 범위를 제한. 가이드를 통해 Override 대상 가능 Props를 설정하여 불필요한 파편화 코드라는 의사결정을 디자인 시스템에서 결정했습니다.

이 과정에서 예상하지 못한 소득이 있었습니다. 문서로는 남아 있지 않던 과거의 디자인 합의사항이 레거시 코드의 연관 클래스 주석에 남아 있었어요. 클래스를 훑으며 그 규칙들을 다시 꺼내 정리했습니다. 내부 자료는 대외비라, 가상의 예시를 들어 설명하고자 합니다.

예시 - RectangleButton 컴포넌트 구축

아래 버튼을 주로 페이지 하단에 고정되어 사용된 버튼이라고 가정해보았습니다. Eclipse로 코드를 추출해보면 아래와 같은 코드가 표시될 것입니다.

<!-- 화면 최하단 CTA의 font-size는 16px을 사용한다 -->
<div class="btn btn-primary font-size-16">
	행운상자 100개 받기
</div>

이를 토대로 figma에는 유사한 컴포넌트인 btn-primary라는 컴포넌트가 구성됩니다. 이와 같은 여러 패턴을 찾아 컴포넌트를 구성해놓으면, 구축사는 이를 추상화해 RectangleButton이라는 추상적인 버튼 개념을 새롭게 구상합니다.

이를 전체 전환 대상 화면의 스타일 코드에 반복 적용하는 방법으로 React 프레임워크를 사용하는 컴포넌트 세트를 아래와 같이 구성해낼 수 있습니다. 아래 코드는 구축사가 만들어낼 산출물의 형태를 보여주기 위한 예시입니다.

type Tone = 'primary' | 'secondary';
type Size = 'lg' | 'md' | 'sm';
 
// tones, sizes는 각각 컬러·스페이싱 토큰을 참조하는 스타일 맵입니다.
const RectangleButton = styled.button<{
  $tone?: Tone;          // 토큰으로 고정
  $size?: Size;          // 토큰으로 고정
  $background?: string;  // 유일하게 Override를 허용한 지점
}>`
  ${({ $size = 'lg' }) => sizes[$size]}
  ${({ $tone = 'primary' }) => tones[$tone]}
  ${({ $background }) => $background && css`background: ${$background};`}
`;

이 가상의 RectangleButton 컴포넌트는 $tone, $size props로 구성되었으며, $background의 경우 제품 디자이너에게 배경 컬러를 수정 가능하도록 선택지를 제공하고 있습니다. 이를 통해 배경 컬러를 일부 수정해야 하는 경우가 발생하는 경우 공통 컴포넌트 담당자와 논의 후 접근성 이슈가 발생하지 않는 선에서 배경 컬러를 변경 지정할 수 있도록 가이드를 제공합니다.

Color Foundation 설계

컬러는 가장 짧은 시간 안에 사용자에게 인지 부하를 줄 수 있는 재료입니다. 모두가 더 밝고 강한 대비를 지닌 컬러를 사용하고 싶어하지만, 용도에 맞는 컬러를 구성하기 위해 저는 아래와 같은 요소를 생성했습니다.

• OKLCH 도입. 차세대 웹 표준 컬러규약인 OKLCH에서는 명도, 채도, 색조를 일정한 간격으로 움직였을 때 사람이 느끼는 차이도 일정하게 유지합니다. 케이뱅크의 브랜드 Seed 컬러 하나에서 예측 가능한 color-ramp를 설계했습니다.
• 시맨틱 토큰을 생성. 각 색상에 역할을 부여하고, 역할이 부여되어 있지 않은 컬러는 사용을 지양하도록 안내. 색상 단위의 위계를 확정, 각 위계별 사용 용도를 background, text, icon, border로 구분하여 접근성 명도대비 지침을 준수하면서도 시스템의 심미성을 훼손하지 않도록 규정을 마련하였습니다.

이 정책 도입 과정 속에서 많은 디자이너들과 갈등이 있었습니다. 왜 잘 쓰던 값을 사용하지 못하게 제한하는지 문의가 가장 많았어요. 설득의 기반은 값을 제한하는 것이 아니라 유연한 규칙을 제정하는 것이었습니다. 그래서 최대한 많은 디자이너들의 참여를 유도하기 위해, 컬러, 이펙트 등에 사용하는 컬러 램프의 색조 구성 프로토타입을 구성했습니다.

이 프로토타입에서는 Brand 팀에서 결정한 컬러와, 의미론적으로 이미 통용되고 있는 warning, error, success 컬러의 지정 컬러를 추출해 각 컬러의 색조와 명도, 그리고 채도를 추출하여 신규 컬러를 제정할 수 있습니다. 실제로는 11(Hue) x 12(Lightness)로 사용 가능 색상 테이블을 구현하였습니다. 이 테이블을 이용해 Light-Dark 모드가 지정된 Semantic 컬러를 구성했습니다.

KDS 사용 지표 생성

위와 같은 사용 컴포넌트, 파운데이션을 도입했을 때, Figma의 Asset list에서 제품의 용도에 맞는 컴포넌트를 골라 쓰는 것 만으로는 KDS의 잠재력을 충분히 활용하지 못합니다. KDS를 활용하는 정량 지표는 컴포넌트의 수명을 늘리는데 필수적인 요소입니다.

• 모두가 약속한 방식으로 제품 개발에 사용하는 확정 Frame을 색인해서, 그 안에서 여러 종류의 공통 컴포넌트를 참조하는 비율을 추적했습니다.
• Instance Override의 허용 범위를 Figma Plugin으로 확인했습니다. 디자인에서 덮어쓴 속성 중 실제 개발에서 지원 가능한 Props가 무엇인지를 서비스 개발자에게 전달하기 전에 확정합니다. 디자인과 개발이 서로 다른 목록을 보던 문제를 커뮤니케이션 전에 찾아냅니다.

개발자와 디자이너가 공유하는 프레임을 팀, 폴더, 파일, 페이지, 프레임 단위로 고정하였습니다. 이 약속은 Figma REST API를 통해 Workspace 내 모든 파일의 최신 지표를 실시간으로 업데이트할 수 있는 기반이 되었습니다.

각 인스턴스의 이슈를 파악할때는 Component Checker를 사용합니다. 다시 RectangleButton으로 돌아와서, 이 버튼의 background 컬러 외 지정 불가 속성을 수정했는지 프로덕트 디자이너가 실시간으로 파악하게끔 안내합니다. NodeChangeProperty는 117개의 type을 실시간으로 추적하기에, 이 중 수정 가능 Property의 항목과 허용 범위를 설정하면 모든 컴포넌트 각각의 정책을 세부적으로 구성할 수 있습니다.

결과

SASS 클래스의 사용 빈도로 재사용 우선순위를 매기고, 그 순서대로 Figma 컴포넌트에 대응시킨 뒤 구축사가 추상화하는 절차를 만들었습니다. 이 방법론을 전환 대상 화면 전체에 반복 적용해, 컴포넌트 세트로 전환할 수 있는 30개 이상의 컴포넌트를 식별했습니다.

OKLCH 기반의 color-ramp와 시맨틱 토큰을 통해 값을 단순히 제한하는 것이 아닌, 색상 선택 전반에 있어 제품 디자이너들을 참여시켰습니다.

Figma REST API와 Figma Plugin을 사용, 디자인과 개발의 괴리를 사람간의 커뮤니케이션 이전에 걸러냈습니다.

제품 운영은 항상 어려운 의사결정을 동반합니다. 특히 디자인 시스템은 한정된 자원을 누구에게 어떤 방식으로 분배하냐의 기로 속에서 항상 갈등하기 마련인데요. 매 의사결정 순간, 전체 케이뱅크 제품의 목적인, 기분 좋은 금융 생활이라는 슬로건을 사용자에게 떠올리기 위해서는 무엇을 해야하는지 고민하고 있습니다.