토픽 6 · Phase 2

자기소개·지원 동기

질문 5개

Q6-1
자기소개 부탁드립니다 (1분 버전)
핵심 포인트
5년 차 / 회사명 / 한 줄 자기 정의 (단순 UI 구현이 아니라 시스템·DX를 고민하는 엔지니어)

가장 큰 임팩트 1~2개만 (디자인 시스템 신규 구축, VAC 아키텍처 등)

마지막 1줄에 "토스에서 하고 싶은 것"으로 자연스럽게 연결
모범 답안먼저 답해보고 펼치기
안녕하세요, 5년 차 프론트엔드 엔지니어 김찬호입니다. 현재 CLO Virtual Fashion에서 3D 의상 제작 SaaS의 웹 프론트엔드를 담당하고 있고, 단순히 화면을 만드는 일을 넘어서 제품의 확장성과 팀의 생산성을 함께 고민하는 방향으로 일해 왔습니다. 가장 임팩트가 컸던 일은 제로베이스에서 모노레포 디자인 시스템을 구축해 멀티 프로덕트로 확장한 것과, 명령형 3D 엔진과 선언형 React를 VAC 패턴으로 분리해 70개가 넘는 에디터 컴포넌트를 안정적으로 운영한 일입니다. 토스증권에서도 동료들이 더 빠르고 자신 있게 좋은 UX를 만들 수 있는 환경을 함께 만들고 싶어서 지원했습니다.
이 답변, 어땠나요?
꼬리 질문
Q-a. "동료들이 빠르고 자신 있게 만든다"는 게 구체적으로 뭔가요?

두 축이 있습니다. 하나는 디자인 시스템·자동화로 반복 작업을 시스템화하는 것 — 아이콘 추가가 한 번의 스크립트로 끝나도록, 토큰 변경이 코드 갱신으로 이어지도록 만들어 놓는 일이요. 다른 하나는 컴포넌트 API의 학습 비용을 거의 0으로 만드는 것입니다. Compound Component, Controlled/Uncontrolled 동시 지원이 그 사례예요.

Q-b. UI 구현을 넘어선다는 표현이 추상적인데, 구체화해 줄 수 있나요?

한 화면을 잘 만드는 것과, 한 팀이 100개 화면을 일관되게 잘 만들 수 있는 환경을 만드는 건 다른 일이에요. 후자에 더 시간을 쓴다는 의미입니다.
Q6-2
자기소개 부탁드립니다 (3분 확장 버전)
핵심 포인트
1분 버전을 골격으로 하되, 이전 경력(포그리트 → CLO) 흐름·전환 동기 추가

두세 가지 임팩트를 짧게 나열 (디자인 시스템·VAC·캐싱·Compound 중 2~3개)

마지막에 "어떤 사람인지"의 한 문장 — 본인을 정의하는 키워드
모범 답안먼저 답해보고 펼치기
안녕하세요, 5년 차 프론트엔드 엔지니어 김찬호입니다. 첫 회사는 UX 빅데이터 분석 SaaS를 만드는 포그리트였고, 거기서 약 2년 동안 다국어 반응형 랜딩, AngularJS에서 Vue로의 전면 마이그레이션, 삼성 글로벌 사이트의 WCAG 접근성 검수를 경험했습니다. 그 시기에 "공용 컴포넌트로 잘게 자른 코드가 팀 전체의 속도를 어떻게 바꾸는지"를 처음으로 체감했어요.

이후 CLO Virtual Fashion으로 옮겨 현재까지 약 5년 가까이 3D 의상 제작 플랫폼의 웹 프론트엔드를 담당해 왔습니다. 임팩트가 컸던 일이 셋 있습니다.

첫째, 제로베이스에서 모노레포 디자인 시스템을 구축했습니다. core/theme 패키지로 분리하고, Rollup으로 ESM/CJS 이중 빌드를 잡고, Storybook MDX로 문서화 환경을 마련했어요. 이후 멀티 프로덕트로 확장하면서 core-{product}/theme-{product}로 재편했고, 디자이너분과의 협업 병목인 SVG·Figma 토큰 자동 동기화까지 파이프라인으로 묶었습니다.

둘째, 명령형 3D 엔진과 선언형 React 사이의 패러다임 충돌을 VAC라는 3계층 어댑터 아키텍처로 풀었습니다. 엔진 API 스펙이 바뀌어도 70개가 넘는 에디터 UI는 안 흔들리는 구조를 만들었고, AtomFamily 패턴으로 소재별 독립 리렌더 최적화까지 잡았어요.

셋째, 상태 관리를 Recoil에서 Jotai로 무중단 점진 마이그레이션 했습니다. 라이브 서비스라 한 번에 못 갈아엎는 제약 안에서, 두 라이브러리를 일시 공존시키며 안전하게 옮겼습니다.

저를 한 문장으로 정의하면 "UI를 잘 만드는 사람보다, 동료가 UI를 잘 만들 수 있는 환경을 만드는 사람"에 가깝습니다. 토스증권에서도 같은 결의 일을 더 큰 사용자·더 큰 신뢰성 위에서 해 보고 싶어서 지원했습니다.
이 답변, 어땠나요?
꼬리 질문
Q-a. 3분 자기소개는 길게 느껴질 수 있는데, 길이는 어떻게 조절하나요?

면접관이 "간단히"라고 하면 1분 버전, 시간 여유가 있으면 3분 버전을 씁니다. 핵심은 첫 30초 안에 "5년 차 / 디자인 시스템·아키텍처 / 토스에서 하고 싶은 일" 세 가지를 던져서 후속 질문이 자연스럽게 따라오게 만드는 거예요.

Q-b. 한 문장 정의가 거창해 보이는데 진짜 그렇게 사고하시나요?

솔직히 매일 그렇게 하진 못해요. 다만 의사결정 순간에 "혼자 잘 만들 길과, 팀이 다 같이 잘 만들 길이 다르면 후자 쪽으로 한 걸음 가자"는 기준을 두려고 합니다. 디자인 시스템·자동화·DX 개선이 그 결정의 결과물이에요.
Q6-3
토스증권 / UX Engineer 직무에 지원하신 이유는요?
핵심 포인트
회사 단위가 아닌 직무 단위로 동기 설계 — UX Engineer라는 포지션이 본인 강점과 정확히 겹친다는 점

토스의 두 가지 매력: (1) 디자인-개발의 경계가 얇은 문화 (2) 금융 도메인의 신뢰성·접근성 압박이 시스템적 사고를 강하게 요구

"여기 와서 무엇을 하고 싶다"가 마지막에 명시 — 받기만 하는 사람이 아니라 기여할 수 있는 사람으로
모범 답안먼저 답해보고 펼치기
세 가지 이유가 있습니다.

첫째, UX Engineer라는 직무가 제 강점과 가장 정확히 겹칩니다. 5년 동안 일관되게 해 온 일이 디자이너분과 코드 사이의 마찰을 시스템으로 푸는 것이었어요. Figma 토큰을 코드로 자동 동기화하고, SVG를 React 컴포넌트로 자동 변환하고, Compound Component로 마크업 자유도를 주는 것 — 이게 다 같은 결의 일이에요. UX Engineer는 그 결을 직무로 명시하는 포지션이라 자연스럽게 끌렸습니다.

둘째, 토스의 디자인 컬쳐입니다. 디자이너와 엔지니어의 경계가 얇고, 인터랙션·접근성·미시 디테일까지 함께 고민한다는 인상을 외부에서 봐도 강하게 받았어요. 제가 회사에서 혼자 진행해야 했던 자동화·DX 개선이 토스에선 표준 작업으로 들어가 있을 거라는 기대가 있고, 그 환경에서 한 단계 더 깊이 들어가고 싶습니다.

셋째, 금융 도메인의 신뢰성·접근성 요구입니다. 사용자에게 돈이 걸려 있는 화면은 1px의 어긋남, 0.1초의 지연, 한 번의 잘못된 인터랙션이 신뢰를 깨뜨려요. 이런 압박이 시스템적 사고를 강하게 요구하고, 제가 지금까지 다져온 아키텍처·디자인 시스템 역량이 가장 잘 발휘될 수 있는 환경이라고 봅니다.

토스증권에 와서는 (1) 디자인 시스템과 자동화 파이프라인을 더 정교하게 운영하는 데 기여하고, (2) 복잡한 금융 화면의 인터랙션을 컴포넌트 레벨에서 견고하게 만드는 일에 시간을 쓰고 싶습니다.
이 답변, 어땠나요?
꼬리 질문
Q-a. 토스 본사가 아닌 토스증권을 고른 이유가 따로 있나요?

금융 도메인 중에서도 증권은 데이터 시각화·실시간성·복잡한 사용자 결정이 모두 들어가 있어서 프론트엔드의 도전이 가장 큽니다. 차트·호가·체결 같은 화면이 한 픽셀 단위로 어긋나면 사용자 신뢰가 흔들리는 도메인이라, 시스템적 사고와 디테일이 동시에 요구되는 점이 매력적이었습니다.

Q-b. 다른 회사도 지원하셨나요? 어떻게 비교하셨어요?

(현재 상황에 맞게 솔직하게 답변) — 다만 토스증권의 직무 정의가 제 강점과 가장 정확히 겹친다는 점에서 우선순위가 가장 높습니다.

Q-c. UX Engineer가 본인이 정의하는 직무라면 어떤 모습인가요?

"디자이너의 의도를 잃지 않고 코드로 옮기는 사람" 이상으로, "디자이너와 엔지니어의 협업 자체를 시스템으로 풀어내는 사람"이라고 봅니다. 토큰 자동화, 컴포넌트 API의 직관성, 인터랙션의 마이크로 디테일까지 한 사람이 책임지는 포지션이 UX Engineer의 진짜 정의라고 생각합니다.
CS · 이론
UX Engineer / Design Engineer 직무 정의: 미국 빅테크(Linear, Vercel, Stripe)·국내 토스 등에서 정착된 비교적 새로운 포지션. "frontend + design"의 교집합

Toss의 디자인 시스템 (TDS, Toss Design System): 외부 공개된 컴포넌트 일부 — 면접 전에 한 번 훑어보면 좋음

금융 프론트엔드의 도전: 실시간 데이터, 정밀한 차트 렌더링, 접근성·다국어, 신뢰성 SLA
Q6-4
본인의 강점과 약점은 무엇인가요?
핵심 포인트
강점: 시스템적 사고 + 자동화 + 동료 DX 우선

약점: 일반론 회피, 본인의 진짜 약점을 솔직하게 + 그걸 어떻게 보완하고 있는지

"약점인데 사실은 강점인 척"하는 답은 면접관이 가장 싫어함
모범 답안먼저 답해보고 펼치기
강점은 "한 화면을 잘 만드는 일"보다 "한 팀이 모든 화면을 일관되게 잘 만드는 환경을 만드는 일"에 시간을 더 쓴다는 점입니다. 모노레포 디자인 시스템 구축, VAC 아키텍처, 토큰·SVG 자동화 파이프라인이 모두 같은 결이고요. 의사결정 순간에 단기 작업 속도와 장기 시스템 건강성 중에서 시스템 쪽에 한 걸음 더 가는 편입니다.

약점은 두 가지가 있습니다.

첫째, 추상화·시스템화에 시간을 쓰는 만큼 단기 결과물 출력이 느릴 때가 있습니다. 컴포넌트 하나를 빨리 찍어내야 할 자리에서 디자인 시스템에 추가할지를 먼저 따져보는 습관이 있어요. 이걸 자각하고 나서는 "이건 일회성인가, 재사용성인가"를 PR 시작 전에 정해 두고 들어가는 식으로 절제하고 있습니다.

둘째, 백엔드/인프라 깊이가 강한 편이 아닙니다. CLO에서는 BFF·서버 쪽을 직접 만질 일이 적었어서, 깊은 SQL 튜닝이나 인프라 설계 경험은 부족합니다. 이를 보완하기 위해 사내 백엔드 분들과 인터페이스 설계 회의에 적극 참여하고, 회사 외부에서는 시스템 디자인 관련 책·아티클을 꾸준히 보고 있어요. 이 약점이 UX Engineer 포지션에서 critical한 영역은 아니라고 보지만, 정직하게 말씀드리는 게 맞다고 생각합니다.
이 답변, 어땠나요?
꼬리 질문
Q-a. 강점이 약점으로 작용한 적은 있나요?

네, 있습니다. 예를 들어 디자인 시스템 v1을 처음 만들 때 너무 일반화에 욕심을 부려서 prop이 늘어나는 문제가 생겼어요. v2 Compound Component 전환은 그 학습의 결과였고, 지금은 "지금 당장 필요한 만큼만 추상화한다"는 원칙을 더 의식하고 있습니다.

Q-b. 두 번째 약점이 정말 약점이라면 다른 방향을 더 훈련하고 싶지는 않으세요?

우선순위 문제예요. UX Engineer로서 화면 레이어의 깊이를 더 키우는 게 우선이라고 봤기 때문에 백엔드 깊이는 한 단계 더 미뤘습니다. 다만 무관심한 게 아니라 협업에 필요한 만큼은 따라가고 있습니다.
Q6-5
(선택) 왜 이직하시려고 하나요?
핵심 포인트
부정적 이직 동기(불만, 갈등)는 절대 금지 — 면접관은 "다음 회사에서도 같은 이유로 떠난다"고 평가

긍정적 동기 위주: 새로운 도메인의 도전, 더 큰 사용자·더 큰 신뢰성, 본인이 다음 단계로 성장할 환경

현재 회사에 대한 평가는 중립~긍정으로
모범 답안먼저 답해보고 펼치기
지금 회사에서 5년 가까이 일하면서 디자인 시스템을 제로베이스에서 만들고 멀티 프로덕트로 확장하는 큰 사이클을 거의 한 바퀴 돌았습니다. 이 경험이 제 커리어의 단단한 베이스가 됐다고 생각하고, 지금 회사에 대한 불만 때문이 아니라 다음 사이클을 더 큰 사용자·더 큰 신뢰성 위에서 돌려보고 싶다는 욕구가 이직 동기입니다.

특히 토스증권은 (1) 사용자 규모가 비교할 수 없게 크고, (2) 금융 도메인의 신뢰성·접근성 요구가 시스템적 사고를 강하게 끌어내는 환경이며, (3) 디자이너-엔지니어 협업 컬쳐가 외부에서 봐도 매우 두텁다는 인상이라, 제가 지금까지 다져 온 강점이 더 잘 발휘되면서 동시에 다음 단계로 성장할 수 있는 자리라고 봅니다.
이 답변, 어땠나요?
꼬리 질문
Q-a. 지금 회사에서 부족했다고 느낀 부분이 있나요?

부족하다기보다 "한 사이클을 한 번 돌고 나니 다음 환경이 궁금해진" 단계예요. 굳이 말하자면, 사용자 규모와 도메인 압박이 시스템 설계의 깊이를 결정한다는 걸 경험하면서, 그 압박이 더 큰 환경에서 일해 보고 싶었습니다.

Q-b. 토스가 안 됐을 때 다른 옵션이 있나요?

(솔직하게, 다만 토스가 1순위라는 정도까지) — 우선순위는 토스증권이고, 그 이유는 위에 말씀드린 직무 fit입니다.