우리는 왜 디자인 엔지니어를 찾게 됐을까

당근 디자인 시스템 팀에 디자인 엔지니어(Design Engineer)라는 새로운 직군이 생겼어요.

새로운 역할을 정의한다는 건 생각보다 큰 일이에요. 어떤 사람이 필요한지부터, 어떤 역량을 기대하는지, 그리고 그 역할을 조직 안에서 어떻게 설명할지까지 모두 새롭게 고민해야 하니까요. 기존의 '프로덕트 디자이너'나 '프론트엔드 엔지니어'라는 이름만으로는 우리가 기대하는 역할을 충분히 설명하기 어려웠어요.

현실적으로는 쉽지 않은 채용이 될 거라는 점도 알고 있었어요. 시장에도 아직 익숙한 역할이 아니고, 우리가 기대하는 역량을 모두 갖춘 사람을 바로 찾기 어려울 거라고 생각했고요. 하지만 앞으로 당근이 지향하는 방향과 제품을 만드는 방식을 생각해 보면, 단순히 기능 중심의 역할을 채용하는 것만으로는 부족하다고 판단했습니다.

우리가 기대한 것은 운영 인력을 늘리는 일이 아니었습니다. 디자인 시스템의 구조를 이해하고, 제품 개발 흐름까지 함께 고민하며, 디자이너와 엔지니어를 연결해 전사의 생산성과 시스템 품질을 함께 높일 수 있는 역할이 필요했습니다.

그래서 처음부터 완성된 전문가를 찾기보다, 이런 방향성에 공감하는 사람을 꾸준히 발굴하고 함께 역할을 만들어가고 싶었습니다. 그 고민 끝에 기존 직군의 이름 대신 새로운 이름을 붙이기로 했고, 그 과정을 조금 나눠보려고 합니다.

직군은 나뉘어 있었지만 일은 나뉘지 않았어요

제품 팀에는 보통 순서가 있어요. 디자이너가 화면을 정의하고, 엔지니어가 그걸 구현해요. 그런데 디자인 시스템에서는 이 순서가 잘 성립하지 않아요.

컴포넌트 하나를 정의하려면 "어떻게 보이는가"와 "어떻게 동작하는가"를 같은 자리에서 정해야 해요. 이 컴포넌트에 로딩 상태가 필요한가, 상태를 몇 개로 쪼갤 것인가, 어떤 속성을 밖으로 열고 무엇을 안에 감출 것인가. 전부 디자인 질문이면서 동시에 구현 질문이에요. 어느 쪽이 먼저랄 게 없어요.

게다가 결정 하나가 iOS·Android·Web 세 곳에 각각 다른 모습으로 착지해요. 플랫폼의 관습을 모르면 애초에 옳은 디자인 결정을 내릴 수 없고, 디자인 의도를 모르면 세 구현체를 같은 방향으로 맞출 수 없어요.

이슈도 한쪽으로만 흐르지 않아요. 엔지니어가 컴포넌트의 동작을 확인하다가 "이 인터랙션이 어딘가 어색하다", "이 상태에서 시각적으로 어긋난다"고 이슈를 올리기도 하고, 반대로 디자이너가 컴포넌트의 설계 구조 자체를 두고 이슈를 내기도 해요.

즉, 저희 팀은 디자이너는 디자인만, 엔지니어는 구현만 고민하는 팀이 아니었어요. 그리고 우리는 디자인 시스템 팀이야말로 그 경계가 없어야 하는 팀이라고 생각했어요. 시스템은 디자인의 결과물도, 코드의 결과물도 아니고 그 둘이 맞물려 돌아가는 하나의 구조니까요.

그래서 새 자리를 고민할 때 가장 먼저 나온 이야기는 이거였어요. 우리가 이미 하고 있는 일을, 있는 그대로 이름 붙이면 뭐라고 불러야 할까?

핸드오프를 줄이는 게 아니라, 없애고 싶었어요

디자인 시스템에서 가장 많은 비용이 새는 곳은 사실 만드는 순간이 아니라 옮기는 순간이에요.

피그마에서는 성립하는 구조가 코드에서는 성립하지 않아요. 코드에서 이미 해결한 문제가 피그마에는 반영되지 않아요. 그 간극을 메우려면 누군가 양쪽 언어를 모두 이해한 채로 앉아 있어야 하는데, 그 역할이 지금까지는 사람과 사람 사이의 대화로만 존재했어요.

한 사람이 문제를 인식하고, 개선 방향을 정하고, 직접 구현해서, 배포까지 끌고 갈 수 있다면 그 간극은 애초에 생기지 않아요.

AI가 이 결정을 앞당겼어요

몇 년 전이었다면 이런 자리는 "있으면 좋은" 정도였을지도 몰라요. 지금은 조금 다르다고 생각해요.

디자인 시스템 문서는 이제 사람만 읽지 않아요. AI가 읽고, 그걸 근거로 코드를 만들어요. 토큰과 컴포넌트 문서는 읽을거리가 아니라 기계가 참조하는 소스가 됐어요. 그러면 문서를 쓰는 방식도, 시스템을 설계하는 방식도 달라져야 해요.

동시에 UI를 만드는 속도 자체가 빨라졌어요. 화면을 그리고 붙이는 일이 쉬워질수록, 차이를 만드는 건 얼마나 빨리 만들었나가 아니라 얼마나 잘 만들었나가 돼요. 그래서 '잘'이 무엇인지 정의하고, 그 기준을 끝까지 밀어붙이는 사람의 가치가 오히려 올라간다고 봤어요. 컬러가 반 톤 어긋나고, 모션이 반 프레임 늦고, 터치 영역이 시각적 경계와 미묘하게 다른 것까지. 그 차이를 설명할 수 있는 언어를 가진 사람이요.

그래서 어떤 베이스를 가진 사람을 찾아야 할까

경계가 없어야 한다는 데까지는 쉽게 합의했어요. 어려운 건 그다음이었어요.

디자이너로 커리어를 쌓아온 분과 엔지니어로 커리어를 쌓아온 분은 같은 문제를 봐도 손을 대는 지점이 달라요. 경계 없이 일하는 건 합류한 뒤의 이야기지만, 어떤 기본기를 가지고 들어오느냐는 정해야 했어요.

엔지니어링 베이스를 이야기하는 쪽의 근거는 이랬어요. 당근의 디자인 시스템 SEED는 컴포넌트만으로 굴러가지 않아요. 토큰 파이프라인, 문서 인프라, 내부 도구들이 함께 움직여야 하고, 여기까지 손대려면 프론트엔드만이 아니라 백엔드와 인프라를 넘나들 수 있어야 해요. 그건 엔지니어를 본업으로 해온 사람이라야 가능하다는 관점이었어요.

디자인 베이스를 이야기하는 쪽의 근거는 이랬어요. 구현은 배울 수 있지만 기준은 배우기 어렵다는 거예요. "이 정도면 됐다"고 타협하지 않는 감각, 반 톤의 차이를 문제로 인식하는 눈은 디자이너로 오래 훈련된 사람에게서 나온다고 봤어요.

Vercel, Ramp, Anthropic, Raycast, Supabase 같은 회사들의 디자인 엔지니어 JD를 모아 비교해보기도 했어요. 회사마다 무게중심이 조금씩 달랐고, 어느 쪽이 정답이라고 말해주는 곳은 없었어요. 결국 우리가 도착한 결론은 이거였어요.

코드는 수단일 뿐이라는 것이에요.

스킬이든, 코드든, 시스템이든 무엇을 쓰든 상관없어요. 중요한 건 문제를 깊이 이해하고, 그걸 자율적으로 설계하고 구축해서, 실제로 출시까지 끌고 갈 수 있느냐예요.

그렇게 보면 어떤 베이스를 가졌든, 완성도의 기준을 가지고 있고, 그 기준을 구현까지 밀고 갈 수 있는 분이라면 된다고 정리했어요. 인프라처럼 깊은 엔지니어링이 필요한 영역은 팀의 기존 엔지니어들이 함께 받치면 된다고 봤고요.

우리가 이 역할의 필요성을 가장 먼저 발견한 곳은 SEED였어요. 디자인 시스템에서는 디테일한 시각·인터랙션 문제를 코드로 해결하고, 반복되는 판단을 기준과 컴포넌트로 만들며, 여러 플랫폼에서 같은 품질로 작동하도록 제품 개발 방식까지 함께 다뤄요.

이 일을 하다 보니 이런 역량이 디자인 시스템 안에서만 필요한 건 아니라는 것도 알게 됐어요. 어떤 문제는 제품 코드 안에서 해결할 수 있고, 어떤 문제는 여러 팀이 함께 쓰는 시스템으로 만들 수 있어요. 또 어떤 문제는 Kraft처럼 디자인 시스템의 맥락으로 아이디어를 빠르게 구현하거나, 디자인과 개발 사이의 비효율을 줄이는 플랫폼으로 풀 수도 있고요.

결과물의 형태는 달라도 핵심은 같아요. 디자인과 관련된 문제를 발견하고, 디테일을 놓치지 않으면서 기술로 실제 변화를 만드는 일이에요. 한 문장으로 정리하자면 다음과 같아요.

당근의 제품과 제품 개발 과정에서 생기는 디자인 문제를 기술로 해결해, 완성도 높은 사용자 경험을 남기는 사람

함께할 분을 찾고 있어요

그리고 그 위에 자리를 하나 열어두었어요. 당근에 처음 생긴 직군인 만큼, 합류하시는 분은 이미 짜인 자리에 들어오는 게 아니라 이 역할이 당근에서 무엇을 해낼 수 있는지를 처음으로 보여주게 될 거예요. 우리가 오래 고민해서 방향을 잡아둔 만큼, 그 위에서 더 멀리 가주실 분을 기다리고 있어요.

당근의 디자인 문제를 기술로 풀고 싶다면?

Design Engineer 채용 공고 보러 가기