정보는 이미 충분했습니다. 없던 건 결정할 수 있는 구조였습니다.
제품 디자인 5년. 채용·HR 제품을 만들며, 정의에서 멈추지 않고 코드까지 직접 만듭니다.
A4 9장짜리 결과표를 한 화면으로 줄인 프로젝트입니다.
인사담당자가 실제로 읽는 순서를 찾아, 그 순서대로 다시 배치했습니다.
개편 후 해석 문의와 미팅에서 설명에 쓰던 시간이 줄었다는 피드백을 받았습니다.
AI 역량검사는 이력서만으로는 알기 어려운
업무 방식, 사고 패턴, 협업 태도를 보여주는 채용 검사입니다.
같은 스펙이라도 일하는 방식은 사람마다 다르기 때문에,
면접 전에 그 차이를 먼저 확인하려고 씁니다.
검사는 해마다 정교해졌지만, 결과를 읽는 일은
인사담당자에게 또 하나의 업무가 되었습니다.
결과표를 쓰려면 따로 배워야 했고, 설명 없이는
쓸 수 없는 결과표는 곧 제품의 진입 장벽이었습니다.
처음엔 설명을 더하면 해결될 거라 생각했습니다.
각 지표의 의미와 읽는 법을 정리한 해석 가이드를
만들어 배포했지만, 50페이지가 넘는 문서가 되었고
배포 뒤에도 해석 문의는 줄지 않았습니다.
설명을 더하는 대신 결과표 자체를 다시 봤습니다.
원래 인쇄용으로 만든 A4 9장짜리 문서를
화면에 그대로 옮겨 온 것이었고, 무엇보다
읽을 우선순위가 없었습니다.
인사담당자가 결과표에서 가장 먼저 찾는 건
전체 지원자 중 어디에 있는가였습니다.
영업팀 설문과 사업팀 피드백으로 이 순서를 확인하고,
위치 → 적합도 → 선호도 순으로 위에서부터 놓았습니다.
순서를 바꾸는 것만으로는 부족했습니다.
화면마다 제각각이던 색을 등급 분포 기준으로 묶어
S부터 C까지 한 가지 색 체계로 통일했습니다.
훑어보는 단계에서는 숫자를 읽지 않아도 됩니다.
채용 기준은 기업마다 다릅니다.
같은 데이터라도 보는 관점이 달라야 할 때가 있어,
결과표를 위젯 단위로 나누고 순서를 바꿔
기업별 템플릿으로 저장할 수 있게 했습니다.
요약 결과표는 기업 회원 대상 만족도 조사에서
8개 콘텐츠 중 1위를 기록했습니다.
사업팀은 미팅에서 해석 설명을 건너뛰게 됐고,
CS팀은 해석 문의가 줄었다고 전했습니다.
결과표 확인 시간, 해석 문의 건수를 추적했다면 개선 효과를 숫자로 보여줄 수 있었습니다. 개편 뒤에 남은 근거가 사업팀과 CS팀의 전언뿐이라, 무엇이 얼마나 나아졌는지 말하기 어려웠습니다. 지금도 이 부분이 제 약한 자리입니다.
요약 결과표는 새로 만들었지만 종합결과표 9장은 그대로 남았습니다. 요약에서 판단하고 더 깊이 보려는 담당자는 전혀 다른 구조의 문서로 넘어가야 합니다. 요약과 상세가 같은 설계 원칙 위에 있어야 경험이 이어진다는 것을, 요약만 바꿔 놓고서야 알았습니다.
50페이지가 넘는 가이드를 만들어 배포했지만 문의는 줄지 않았습니다. 읽는 사람이 몰라서가 아니라, 결과표가 무엇부터 보라고 말해주지 않았던 것입니다. 우선순위를 다시 짜고 핵심을 맨 위에 두자 설명할 일이 줄었습니다. 그 뒤로는 설명을 덧붙이기 전에 구조부터 의심합니다.
처음부터 맡은 과제는 아니었습니다. VOC를 정리하다 같은 불만이 반복되는 것을 보고, 그 패턴을 묶어 기획팀에 개선 방향을 먼저 제안했습니다. 요청을 기다렸다면 화면을 다듬는 데서 멈췄겠지만, 먼저 꺼낸 덕분에 무엇을 풀지 정하는 단계부터 함께할 수 있었습니다.
추천에 근거를 붙인 프로젝트입니다.
검색 도구에 가까웠던 매칭을, 왜 맞는지 근거를 주는 매칭으로 다시 설계했습니다.
H.X는 기업이 원하는 인재를 말로 설명하면
AI가 맞는 사람을 찾아 추천하는 B2B 서비스입니다.
지원자를 기다리는 채용이 아니라,
기업이 먼저 찾아 나서는 채용을 돕습니다.
수시채용만 실시하는 기업
한 칸 = 기업 1곳
출처: 한국경영자총협회, 2024
경력 채용 · 다이렉트 소싱 활용
출처: 고용노동부·한국고용정보원, 2024
직무 관련 경험을 보는 기업
출처: 한국경영자총협회, 2023–2025
여섯 곳을 하나씩 뜯어봤는데, 모두 조건에 맞는 사람을 찾아주는 데서 멈춰 있었습니다.
구직 활동 데이터로 인재를 추천
공고와 이력서를 비교해 적합 인재를 추천
명함을 바탕으로 경력직을 찾아 스카웃
매칭 데이터를 학습해 합격 확률이 높은 인재를 추천
경력과 연봉이 인증된 인재를 추천
역량검사 결과를 바탕으로 직무에 맞는 인재를 매칭
기존 채용 플랫폼들도 매칭을 내세웠지만,
실제로는 조건에 맞는 사람을 나열하는 데서 멈췄습니다.
왜 이 사람인지는 알려주지 않아서, 담당자가
프로필을 하나씩 열어 직접 판단해야 했습니다.
기존 서비스는 조건에 맞는 후보를 최대한 많이 보여줬고,
그중 맞는 사람을 찾는 건 담당자의 몫이었습니다.
더 적더라도 왜 맞는지 납득할 수 있다면,
그게 더 좋은 매칭이라고 봤습니다.
담당자는 원하는 인재를 이미 말로 설명합니다.
"마케팅 3년차, 데이터 분석 가능한 사람"처럼
말하듯 입력하면 AI가 검색 조건으로 바꾸고,
바꾼 조건은 화면에 그대로 보여 줍니다.
이력서에는 경력과 스펙만 적혀 있습니다.
하지만 채용을 가르는 건 협업 방식이나
근무 조건처럼 이력서 밖의 것일 때가 많아,
이 조건들까지 매칭의 기준으로 끌어왔습니다.
점수 하나로는 왜 이 사람인지 알 수 없었습니다.
그래서 판단에 필요한 근거를 세 관점으로 나눠 담았고,
순서는 담당자가 후보 앞에서 실제로 묻는
질문의 흐름을 그대로 따랐습니다.
역량검사 결과를 기업이 적어둔 인재상과 연결된 문장으로 바꾸고, 근거를 직접 확인한 뒤 정하게 했습니다.
기업이 적은 인재상 — “주도적으로 문제를 푸는 사람”
문제해결력이 상위 20%이고 자기주도성이 함께 높아, 스스로 과제를 정의하고 끌고 가는 유형입니다.
기업이 적은 인재상 — “팀으로 일하는 사람”
대인영향력은 평균 수준이지만 협업 상황에서의 조율 성향이 높아, 주도보다 조율로 기여하는 쪽에 가깝습니다.
출시 후 내부 인사담당자를 대상으로
사용 경험 인터뷰를 했습니다.
공통으로 나온 변화는 프로필을 열면
이력서보다 리포트부터 본다는 것이었습니다.
경험은 개선했지만 수익으로 이어지지는 못했습니다.
매칭은 알고리즘 · UX · 인재풀이 함께 맞아야
작동하는데, 둘은 풀었고 인재풀은
디자인으로 풀 수 있는 문제가 아니었습니다.
담당자의 탐색 방식은 바뀌었고, 근거를 확인하고 판단하는 구조도 만들었습니다. 하지만 인재풀이 신입 위주라 기업이 찾는 경력직이 부족했고, 경험을 개선하는 것만으로는 수익을 만들 수 없었습니다.
이 프로젝트 전까지는 화면 안의 문제를 잘 푸는 것이 디자이너의 역할이라고 생각했습니다. 하지만 매칭은 UX, 알고리즘, 인재풀, 비즈니스 모델이 함께 맞물려야 작동했습니다.
이제는 화면을 설계하기 전에 서비스 전체에서 디자인이 풀 수 있는 부분과 풀 수 없는 부분부터 가려 봅니다. 인재풀을 채우기 전에 수요부터 확인하는 다음 접근도 이 과정에서 나왔습니다.
시안을 넘기는 데서 멈추지 않습니다.
토큰과 컴포넌트를 직접 코드로 구현하고, AI가 읽는 시스템을 거쳐 지켜지게 만드는 장치까지 만들었습니다.
이렇게 하자고 제가 제안했습니다.
컬러와 타이포, 컴포넌트까지 시스템은 이미 있었습니다.
하지만 색과 간격을 값으로 정해 두어서,
만드는 사람이 늘수록 같은 역할에 다른 값이 쓰였고
무엇을 기준으로 골라야 하는지 설명할 수 없었습니다.
이 색은 무엇을 위한 색일까?
bluegray-900처럼 값으로 부르던 색을, 무엇을 위한 색인지로 4단계 역할 구조에 다시 담았습니다.
bluegray-900
역할 토큰을 Figma 이름 그대로 코드 변수로 옮겨, 설계부터 React·TypeScript 구현까지 직접 했습니다.
variant를 역할 토큰에 연결해 hover · pressed · disabled가 토큰에서 자동으로 따라옵니다.
컴포넌트가 언제 쓰이는지 스스로 설명하게 하고, 에이전트가 그 설명을 질의해 시스템대로 짜게 했습니다.
.metadata.ts — 용도·안티패턴·AI 힌트를 코드에 명시
전 컴포넌트 메타데이터 → 단일 JSON, 소스가 곧 스펙
CLI·스킬로 필요한 컴포넌트만 골라 조회
임의 스타일이 아니라 DS 토큰·컴포넌트를 우선 사용
AI가 없는 토큰 이름을 지어내도 오류도 안 나고 화면도 안 깨져서, 사람 눈으로는 안 잡혔습니다.
UI 파일을 처음 열 때, 쓸 수 있는 컴포넌트 목록을 통째로 알려준다
저장 직후, 하드코딩·유령 참조를 그 자리에서 지적
지난 250개를 되돌려 재보니 걸렸을 건 6개, 2.4%
못 지킨 자리를 모아 다음에 만들 컴포넌트의 근거로
화면을 짜는 주체가 사람에서 AI로 바뀌었지만,
무엇을 고를지와 그 기준은 같은 자리에 있습니다.
디자이너와 개발자, AI가 같은 이름으로 말하고
같은 시스템에서 부품을 찾습니다.
“이거 뭘 써야 하지?”
언제 쓰는지 · 기본값이 무엇인지
쓰면 안 될 때 한 영역에 primary 여럿 — 가장 중요한 하나만
“이름을 모르겠는데”
한글로 물어도 찾습니다. 이름을 알아야만 찾을 수 있으면, 있는 줄 모르는 부품은 영영 다시 만들어집니다
“이 색은 어떤 토큰이지?”
똑같은 게 없으면 제일 가까운 것을 줍니다
34종을 대보니 26종은 이미 있는 색이었습니다
아직 진행 중인 시스템입니다. 부품은 대체로 섰고, 화면을 짜는 층이 남아 있습니다.
구조가 잘 짜여 있어도 다른 사람이 이해하지 못하면 쓰이지 않았습니다. 프론트엔드 개발자와 구현 가능성을 검토하고 네이밍 규칙을 맞춘 것이, 시스템이 실제로 작동하는 데 가장 큰 영향을 줬습니다.
시안을 넘기고 기다리는 대신 제가 코드로 옮겼기 때문에, 디자인과 개발 사이에서 이름이 어긋나는 자리를 바로 잡을 수 있었습니다.
시스템은 제품과 함께 자라야 합니다. 그래서 안 지켜지는 자리를 세는 장치를 먼저 붙였고, 다음에 만들 부품은 감이 아니라 그 기록을 보고 고릅니다. 부품 다음은 화면을 짜는 패턴입니다.
읽어주셔서 감사합니다. 더 나은 결정을 돕는 디자인으로 이어가겠습니다.