"여기 간격 좀 띄워주세요."

에이전시에서 일하다 보면 이 문장을 수도 없이 듣는다. 디자이너에게는 완결된 요청이다. 하지만 개발자에게는 질문이 서너 개 따라붙는 문장이다. 얼마나? 위아래 둘 다? 모바일에서도? 패딩으로, 마진으로?

반대 방향도 마찬가지다. 개발자가 "그건 컴포넌트 구조상 어렵다"고 말하면 디자이너는 어디가 왜 어려운지 알 길이 없다. 양쪽 다 자기 언어로는 정확하게 말하고 있다. 문제는 말이 아니라 번역이다.

공통 어휘가 회의를 줄인다

내가 겪어본 가장 효과적인 해결책은 거창한 프로세스가 아니라 어휘를 통일하는 것이었다.

간격은 4px 단위 스케일로 이름을 붙인다. 색은 헥스 코드가 아니라 토큰 이름으로 부른다. "회색 좀 더 진하게"가 아니라 "muted를 fg로"라고 말하면 해석의 여지가 사라진다. 컴포넌트도 마찬가지다. 디자인 파일의 프레임 이름과 코드의 컴포넌트 이름이 같으면, "그 카드 있잖아요, 그 둥근 거"라는 대화가 사라진다.

어휘가 통일되면 회의가 짧아진다. 과장이 아니라 실제로 그렇다. 서로의 말을 해석하는 데 쓰던 시간이 통째로 사라지기 때문이다. 디자인 시스템의 진짜 가치는 예쁜 문서가 아니라 여기에 있다고 생각한다.

오가본 사람이 다리를 놓는다

나는 디자인 전공으로 시작해서 퍼블리셔를 거쳐 프론트엔드까지 왔다. 그래서 양쪽의 말이 다 들린다. 디자이너가 "무게감이 없다"고 할 때 그게 폰트 웨이트인지 여백인지 대비인지 감이 오고, 개발자가 "상태 관리가 꼬인다"고 할 때 어떤 화면 요구가 그걸 유발했는지 짐작이 간다.

이 위치가 한동안은 애매하다고 느껴졌다. 어느 쪽 전문가도 아닌 것 같아서. 그런데 요즘은 생각이 다르다. 번역자가 있는 팀과 없는 팀은 속도가 다르다. 양쪽 언어를 쓸 줄 아는 사람이 토큰과 컴포넌트 이름을 정리해두면, 그다음부터는 번역자 없이도 대화가 굴러간다.

같은 언어를 쓰게 만드는 일은 도구 도입이 아니라 습관의 문제다. 다음 회의에서 "간격 좀"이라는 말이 나오면, 그 자리에서 이름을 붙여보는 것부터 시작하면 된다.