AI 프로토타입이 헐거워 보인다면, 범인은 디자인 시스템의 기본값이다

“개발자가 한 디자인 같아요.”

채널톡이 데이터 분석 툴 '노트북'을 만들던 중, 디자이너가 Claude Code로 조합한 편집 뷰 프로토타입을 보고 대표가 던진 말입니다. 저는 이 회고 전체에서 이 장면이 가장 쓸모 있다고 봐요. 그 프로토타입은 채널톡 디자인 시스템 베지어(Bezier)의 컴포넌트만 가져다 쓴 결과물이었거든요. 시스템 밖의 요소가 하나도 없는데 엉성해 보였다면, 문제는 AI의 솜씨가 아니라 AI가 성실하게 따른 기본값 쪽에 있습니다.

디자이너에게 AI 코딩 도구를 쥐여주고 프로토타입 속도를 올리려는 팀이 요즘 많죠. 이 사례는 그게 된다는 증거이면서, 무엇이 갖춰져 있어야 되는지도 꽤 정직하게 보여줍니다. 효과보다 조건을 먼저 읽을 만한 글입니다.

기본값에는 기존 제품의 밀도가 새겨져 있다

채널톡의 기존 UI는 태스크 단위로 설계돼 있습니다. 한 번에 한 가지 일을 처리하는 화면에 맞춰진 셈이죠. 노트북은 코드 에디터와 실행 결과 테이블, 스키마 탐색, 차트 편집 패널이 한 화면에 동시에 떠 있어야 하는 제품이고요. 리더십이 처음부터 짚은 것도 이 간극이었습니다. "노트북은 밀도 높은 제품인데, 채널톡은 그 정도 정보 밀도를 감당할 UI 체계를 갖고 있지 않다."

'개발자가 한 디자인'이라는 평을 들은 게 이 화면입니다. 데이터가 많아서 뭔가 있어 보이긴 하는데 화면이 비어 보였다는 디자이너의 표현이 정확해요. 컴포넌트는 하나하나 맞게 쓰였지만, 그것들이 한 화면에 얼마나 촘촘하게 놓여야 하는지는 시스템이 정의하지 않았습니다. 디자인 시스템의 기본 간격과 크기에는 그 시스템이 처음 만들어질 때의 제품 밀도가 담겨 있고, AI는 그걸 의심하지 않고 조합할 뿐이죠.

그래서 실무자가 가져갈 판단은 이겁니다. AI 프로토타입이 헐거워 보일 때 프롬프트를 다듬는 건 대개 헛수고예요. 밀도가 한 단계뿐인 시스템 위에서는 누가 조합해도 비슷한 결과가 나옵니다. 채널톡이 한 일도 프롬프트 수정이 아니었습니다. 피그마로 넘어가 베지어 컴포넌트의 값을 하나씩 다시 잡았고, 그 결과 노트북은 채널톡 기본값보다 한 단위 아래의 스케일을 쓰게 됐습니다.

2px 합의는 누가 해주나

성공담이 생략하기 쉬운 비용이 이 대목에 있습니다. 새로 잡은 값은 대부분 디자인 시스템에 없는 값이라 그대로 쓸 수 없었습니다. 디자이너가 값을 제안하면 시스템 오너들이 이 값이 시스템 전체를 흔들지 않을지 하나씩 검토했고, 2px 단위의 조정까지 팀원들과 합의해서 결과값을 만들었죠.

노트북에 맞춘 값 목록을 두고 시스템 쪽 사람들과 오간 대화입니다. 값 하나가 다른 제품에서 무엇을 깨뜨릴지 확인하는 과정이기도 하고요. 파생 요구도 따라왔습니다. 셀 위에 겹쳐 뜨는 셀렉트와 텍스트필드에는 그림자 없는 variant가 따로 필요했고, 차트 컬러는 노트북·커스텀 리포트·통계 세 제품이 함께 쓰는 값이라 한 제품의 판단으로 정할 수 없었어요.

이게 가능했던 조건을 복원해보면 단순합니다. 시스템 오너가 사내에 있었고, 그들이 새 제품 하나를 위해 값을 검토할 시간을 냈다는 것. 디자인 시스템을 외부 라이브러리에 기대거나 오너가 따로 없는 팀이라면 이 단계에서 선택지가 둘로 줄어듭니다. 시스템을 우회해 노트북 전용 값을 하드코딩하거나, 기본값 그대로 헐거운 화면을 내보내거나. 앞쪽은 시스템 부채를, 뒤쪽은 사용성 부채를 남기죠.

3개월이라는 숫자 아래 깔린 것

속도만 보면 인상적입니다. 3월 3주차에 투입된 디자이너가 5월 CBT, 그 직후 OBT까지 약 3개월을 함께했으니까요. 그런데 이 일정표를 다른 팀이 그대로 기대하기엔 깔려 있는 조건이 꽤 많습니다.

가장 큰 건 디자이너가 들어오기 전에 이미 동작하는 제품이 있었다는 점이에요. 백엔드 2명과 프론트엔드 1명이 2주 만에 쿼리가 실행되고 차트가 그려지는 수준까지 만들어 둔 상태였습니다. 디자이너가 풀 문제는 "무엇을 만들까"가 아니라 "이미 있는 기능을 어떤 순서와 밀도로 보여줄까"로 좁혀져 있었던 거고요. 빈 캔버스에서 출발하는 팀이라면 이 3개월을 기준으로 삼으면 안 됩니다.

스펙도 먼저 있었습니다. Amplitude와 Tableau 정도만 써본 디자이너는 첫 주를 통째로 도메인 학습에 썼고, PM이 없는 팀이라 유즈케이스와 스코프를 직접 정리해 DA팀 자문을 받아 MVP Phase를 확정했어요. Claude Code로 처음 만든 것도 화면이 아니라 셀 타입 갤러리였습니다.

SQL, Python, Markdown, Chart, Table, Single value, Input, Filter, Pivot까지 10개 셀 타입을 늘어놓고 각각이 상태별로 어떤 아웃풋을 내는지 펼친 이 갤러리는 사실상 실행되는 스펙 문서입니다. 상태를 열거하는 판단은 디자이너가 했고, 그걸 렌더링되는 화면으로 펼치는 일은 AI가 했죠. 저는 AI 프로토타이핑의 속도를 정하는 게 모델 성능보다 이 열거의 선명도라고 봐요. 유즈케이스와 PRD를 먼저 정의하자 구조 검증이 예상보다 멀리, 빠르게 나갔다는 회고와도 맞습니다. 차트를 대량으로 그려야 했을 때 Claude Code로 피그마 플러그인을 만들고, 컬러 토큰과 차트 유형을 정의하는 일만 사람이 쥔 것도 같은 원리예요. 정의가 선명한 곳에서만 반복을 넘길 수 있습니다.

짚어둘 건 이 스펙 작업을 디자이너 한 사람이 떠안았다는 사실입니다. 도메인 학습, 스코프 확정, 프로토타입, 디자인을 한 사람이 모두 쥐는 구조는 빠르지만 그 사람이 빠지면 판단의 근거도 같이 빠져요. 사람 쪽 조건도 있습니다. 사내 DA팀이 자문을 했고, 각 팀에서 데이터를 다루는 팀원들이 첫 사용자로 피드백을 줬고, 대표가 프로토타입을 직접 볼 만큼 가까이 있었습니다. 데이터 분석 툴을 만드는 회사 안에 데이터 분석을 업으로 하는 사람이 있다는 건 흔한 조건이 아니죠.

"어려워요"를 화면 밖에서 푼 선택

밀도를 잡은 뒤 돌아온 피드백은 "어려워요."였습니다. 여기서 채널톡이 한 선택이 이 회고에서 두 번째로 배울 만한 결정입니다. 어려운 화면을 쉽게 고치는 대신 AI CoS라는 진입 경로를 하나 더 붙였거든요. 분석하고 싶은 지표를 물으면 미리 연결해둔 데이터 웨어하우스나 채널톡 상담 데이터를 바탕으로 노트북을 만들어 주는 기능입니다.

이 선택이 영리한 건 밀도와 학습 난이도를 한 화면에서 동시에 풀려고 하지 않았다는 데 있습니다. 숙련자는 촘촘한 노트북을 직접 쓰고, 익숙하지 않은 사람은 질문으로 들어와 AI가 만든 노트북을 받습니다. 온보딩을 위해 애써 잡은 밀도를 다시 풀어버리는 흔한 실수를 피한 셈이죠. 배포 뒤에는 피처팀마다 따로 보던 제품 지표가 모두 노트북으로 모였고, 데이터 엔지니어가 아닌 사람도 분석하게 됐습니다.

대신 비용 하나가 자리를 옮깁니다. 질문으로 들어온 사용자는 AI가 쓴 쿼리가 맞는지 스스로 판단하기 어렵거든요. 촘촘한 화면이 사용자를 가르쳐야 하는 부담을 던 만큼, AI가 만든 결과를 검증 가능하게 보여줘야 하는 부담이 커집니다. OBT 이후 자발적으로 쓰는 고객사가 생기고 있다면, 다음 설계 과제는 이쪽이라고 봐요.

회고는 어떤 도구로 만들었는지는 '고객이 쓸 수 있는 제품인가'라는 질문 앞에서 아무 의미가 없다는 말로 끝납니다. 이 대목엔 동의하기 어렵습니다. 이 글이 보여준 가장 구체적인 발견이 바로 도구가 기본값을 증폭한다는 사실이었으니까요. 도구는 판단을 대신하지 못하지만, 어떤 판단이 비어 있는지는 가장 빨리 드러냅니다. 그 드러남을 미리 계산에 넣는 팀과 그렇지 않은 팀의 일정은 꽤 다르게 흘러가요.

디자이너가 AI로 프로토타입을 만드는 방식을 들이려는 팀이라면, 저는 도구 교육보다 디자인 시스템 점검을 먼저 하겠습니다. 시스템에 기존 제품과 다른 밀도를 받아줄 스케일이 있는지, 없다면 그걸 합의해 줄 오너가 사내에 있는지. 둘 다 없는 팀에서는 AI가 매번 '개발자가 한 디자인'을 성실하게 다시 만들어낼 뿐입니다. 둘 다 있는 팀이라면 구조는 AI로, 밀도는 손으로, 반복은 다시 AI로 넘기는 이 회고의 분업을 거의 그대로 가져가도 됩니다.