AI로 만들고, 디자인으로 완성한 3개월

채널톡은 올해 상반기 '노트북'이라는 데이터 분석 툴을 만들었습니다. 데이터를 직접 조회하고, 셀을 쌓아 분석하고, 대시보드까지 구성할 수 있는 제품입니다. 저는 3월 중순에 디자이너로 투입되어 5월에 CBT, 그 직후 OBT까지 약 3개월을 함께했습니다.

이 글은 그 안에서 제가 내린 판단들에 대한 기록입니다. AI로 무엇을 빠르게 검증했고, 어디서부터 AI가 대신해주지 못했는지. 그리고 '동작하는 제품'과 '쓸 수 있는 제품' 사이에 무엇이 있었는지에 대한 이야기입니다.

분석 툴이 필요했던 이유

채널톡에는 상담 지표를 볼 수 있는 통계 기능이 있었습니다. 어떤 문의가 얼마나 인입되는지, 어떤 문제가 반복되는지, 상담원들이 어떻게 응대하는지. 이 지표에서 서비스의 문제를 읽어냅니다. 다만 통계라는 기능에는 구조적 한계가 있습니다. 회사마다 보고 싶은 데이터가 다르고, 같은 이름의 지표라도 정의가 다릅니다. 정형화된 대시보드로는 커버할 수 없는 영역이 반드시 남습니다. 고객사는 지표를 자신들의 기준으로 쪼개 보길 원했고, 이 요구는 개별 기능을 추가해 대응할 수 있는 성격이 아니었습니다. 정해진 지표를 보여주는 대신, 고객이 직접 지표를 정의하게 하는 것. 그래서 데이터 분석 툴을 직접 만들기로 했습니다.

이미 동작하던 제품은 왜 배포되지 못했을까

제가 배정된 건 3월 3주차입니다. 백엔드 2명, 프론트엔드 1명이 2주 만에 이미 '기능으로서 동작하는' 수준까지 만들어놓은 상태였습니다.

즉, 제가 없어도 제품은 이미 있었습니다. 그런데 배포되지 않았습니다. 쿼리는 실행됐고 차트는 그려졌습니다. 부족한 건 기능이 아니라 그 기능들이 사용자에게 어떤 순서로, 어떤 밀도로, 어떤 상태를 거치며 전달되는지였습니다. 실행 모델은 있었지만 사용자의 멘탈 모델이 없었습니다.

리더십에서 받은 미션도 여기에 정확히 걸려 있었습니다.

"노트북은 밀도 높은 제품인데, 채널톡은 그 정도 정보 밀도를 감당할 UI 체계를 갖고 있지 않다."

기존 채널톡의 UI는 태스크 단위로 설계되어 있습니다. 반면 분석 툴은 코드 에디터, 실행 결과 테이블, 스키마 탐색, 차트 편집 패널이 한 화면에 동시에 존재해야 합니다. 두 제품의 정보 밀도 기준이 근본적으로 달랐습니다.

여기에 팀의 고민이 하나 더 있었습니다. "이 어려운 도구를 고객이 이해할 수 있게 만드는 것" 결국 이 두 과제는 서로 다른 해법을 요구했고, 이 글의 나머지는 그 두 개를 푸는 과정입니다.

화면보다 먼저 이해해야했던 실행 모델

Amplitude와 Tableau 정도만 써본 상태로 노트북을 설계하는 건 불가능했습니다. 첫 주는 온전히 도메인 학습에 썼습니다.

'노트북'이라는 단어의 유래부터, SQL 셀과 Python 셀이 나뉘는 이유, 셀 단위 실행 모델, 셀 간 변수 스코프가 공유되는 구조, 인풋 셀로 파라미터를 주입해 하위 결과를 다시 계산하는 흐름까지 파고들었습니다.

핵심은 노트북이 화면이 아니라 실행 컨텍스트를 가진 문서라는 점이었습니다. 셀은 위에서 아래로 나열되지만 실제로는 의존 관계를 갖습니다. 앞 셀이 만든 데이터프레임이 뒤 셀의 입력이 되고, 중간 셀을 다시 실행하면 하위 셀의 상태가 어긋납니다. 여기를 이해하지 못한 채 화면부터 그렸다면 예쁜 껍데기가 나왔을 겁니다.

시작은 Claude Code로

도메인을 이해한 뒤, PM이 없는 팀이었기 때문에 유즈케이스 정리와 스코프 확정까지 맡아 진행했습니다. 실제 워크플로우 기준으로 우선순위를 세우고, 사내 DA팀 자문을 받아 MVP Phase를 정리했습니다.

그 다음 클로드 코드로 프로토타입을 시작했습니다. 여기서 제가 한 건 화면을 만들어달라고 요청한 게 아닙니다. 먼저 셀 타입별 갤러리를 만들었습니다. SQL, Python, Markdown, Chart, Table, Single value, Input, Filter, Pivot까지 10개 셀 타입을 나열하고, 각 타입을 상태별로 어떤 아웃풋이 나오는지 볼 수 있게 구성했습니다.

이 갤러리를 만든 이유는 명확했습니다. 셀마다 어떤 설정이 필요하고 어떤 상태를 가지는지를 먼저 확정해야, 그 뒤의 조합이 의미가 있기 때문입니다. 상태를 열거하는 판단은 제가 했고, 그걸 실제로 렌더링되는 화면으로 펼치는 작업을 AI가 했습니다.

클로드 코드가 없었다면 이 기간 안에 만들지 못 했을 겁니다. 셀 간 데이터 흐름, 변수 공유, 파라미터 주입 같은 동작은 정적인 목업으로는 검증이 안 됩니다. 실제로 실행되는 프로토타입이 있어야 판단할 수 있는 영역이었습니다. 유즈케이스와 PRD를 먼저 명확히 정의한 뒤 프로토타입을 만들자, 예상보다 훨씬 멀리 그리고 빠르게 구조 검증이 진행됐습니다.

"개발자가 한 디자인 같아요"

갤러리를 조합해 노트북 편집 뷰 프로토타입까지 만들었을 때, 대표님의 한마디에 바로 긁혀버렸습니다...

"개발자가 한 디자인 같아요."

바이브 코딩으로 만든 아웃풋이니 틀린 말은 아니었습니다. 그런데 이 프로토타입은 우리 디자인 시스템인 베지어(Bezier)를 그대로 가져다 쓴 것이었습니다. 컴포넌트는 전부 시스템 안에 있는 것들이었습니다.

그런데도 엉성했습니다. 데이터가 많아서 뭔가 있어 보이긴 하는데, 화면이 비어 보였습니다.

여기서 알게 된 게 있습니다. 디자인 시스템 컴포넌트를 조합하는 것과, 그 컴포넌트로 밀도를 설계하는 것은 다른 일입니다. 시스템은 각 컴포넌트가 어떻게 쓰여야 하는지를 정의하지만, 그것들이 한 화면에서 어떤 간격으로 얼마나 촘촘하게 놓여야 하는지는 정의하지 않습니다. AI는 시스템의 기본값을 성실하게 조합했고, 그 기본값은 현재 시스템 기준으로 만들어진 값이었습니다.

2px 단위에서 만들어진 밀도

일정이 타이트했기 때문에 바로 피그마로 넘어왔습니다. 프로토타입에서 구조가 이미 확정돼 있었기 때문에, 모듈 단위로 블럭을 만들어 조합하는 방식으로 속도를 낼 수 있었습니다.

다만 이번에는 컴포넌트를 그냥 얹지 않았습니다. 베지어를 직접 조합하며 제가 판단한 이상적인 값으로 하나씩 다시 잡았습니다. 그러자 밀도가 나오기 시작했습니다.

결과적으로 노트북은 채널톡의 기본값보다 한 단위 아래의 스케일을 쓰게 됐습니다.

여기서 중요한 건 이 값들이 대부분 디자인 시스템에 존재하지 않는 값이었다는 점입니다. 그래서 그냥 쓸 수 없었습니다. 노트북과 데이터 소스 화면에 필요한 값을 제안하고, 시스템 오너들과 이 값이 시스템 전체에 문제를 일으키지 않을지 하나씩 검토했습니다. 2px 단위의 조정까지 팀원들과 합의하며 결과값을 만들어갔습니다.

밀도는 이런 대화의 총합입니다. 한 번의 결정으로 만들어지지 않고, 컴포넌트 하나하나가 놓이는 맥락을 다시 물어야 나옵니다.

이후 파생 요구도 계속 나왔습니다. 셀렉트와 텍스트필드는 셀 위에 겹쳐 올라가거나 오버레이 안에서 쓰이는 경우가 많아 shadow 없는 variant가 별도로 필요했습니다. 차트 컬러는 노트북만의 문제가 아니라 커스텀 리포트와 통계에서 공통으로 쓰일 값이라, 제품 하나가 아니라 세 제품을 함께 놓고 정해야 했습니다.

'디테일'이라는 단어로 뭉뚱그려지는 작업의 실체가 이런 것들입니다.

판단은 직접, 구현은 다시 AI가

이 과정에서 차트를 대량으로 만들어야 했습니다. 차트는 컴포넌트화 자체가 비효율적인 영역입니다. 값이 바뀔 때마다 시각적으로 정상 출력되도록 구조를 잡는 비용이 큽니다.

이 부분은 클로드 코드로 피그마 플러그인을 만들어 해결했습니다. 컬러 토큰과 차트 유형을 정의해두고, 키노트에서 차트를 다루듯 원하는 값을 입력하면 아웃풋이 생성되는 방식이었습니다. 컬러와 유형을 정의하는 판단은 제가 했고, 반복 생성은 AI가 했습니다.

MVP 룩이 잡힌 뒤에는 DA팀, 제품팀과 무엇이 부족한지 함께 써보며 확인했습니다. 대표적인 것이 SQL 셀의 자동완성이었습니다. 자동완성은 UI로 보이지만 실제로는 규칙의 문제입니다. 커서가 어느 절에 있는지에 따라 테이블을 제안할지 컬럼을 제안할지가 달라지고, 연결된 웨어하우스의 스키마를 어떤 우선순위로 노출할지도 정의해야 합니다. 이 로직을 혼자 설계하기는 어려웠고, 여기서 다시 클로드 코드로 규칙을 정리했습니다.

구조 검증은 AI로, 밀도와 완성도는 피그마로, 반복 생성과 로직 정리는 다시 AI로. 이 분업이 이 프로젝트의 리듬이었습니다. 도구를 바꾼 기준은 늘 같았습니다. 판단이 필요한 구간인가, 실행이 필요한 구간인가.

완성도와 별개였던 두번째 과제

각 팀에서 데이터를 다루는 팀원들에게 제품을 보여주고 피드백을 받았습니다.

"어려워요."

밀도라는 첫 과제는 해결했습니다. 하지만 '어려운 도구를 고객이 이해할 수 있게 만드는 것'이 아직 해결되지 않았습니다.

그래서 두 번째 과제로 넘어갔습니다. AI CoS입니다.

AI CoS는 분석하고 싶은 지표를 물어보면, 미리 연결해둔 데이터 웨어하우스나 채널톡이 제공하는 상담 데이터를 기반으로 노트북을 만들어줍니다. 여기서 와우가 나왔습니다.

디자인 관점에서 이건 AI 기능을 붙이는 일이 아니라 진입 경로를 하나 더 설계하는 일이었습니다. 어떤 시나리오에서 사용자가 AI에게 질문하게 되는지, AI가 어떤 순서로 데이터를 조회하고 분석하고 대시보드를 구성하는지를 설계하며 성능을 함께 검토했습니다. 이후 2주간 AI CoS를 붙여 OBT로 노트북을 배포했습니다.

고객이 알려준 답

배포 이후 가장 먼저 바뀐 건 내부 팀이였습니다. 각 피처팀이 따로 보고 있던 제품 지표를 이제 모두 노트북에서 볼 수 있게 됐습니다. AI CoS가 데이터 엔지니어가 아닌 사람도 분석할 수 있게 만들어준 덕분입니다. "AI가 붙으면 노트북의 허들이 낮아질 것"이라는 가설이 여기서 해소됐습니다.

OBT 이후에는 AI CoS로 노트북을 자발적으로 쓰는 고객사가 점차 생겨나고 있습니다. 노트북에 관심을 보이는 고객사를 직접 만나 어떤 분석을 하고 싶은지 듣고, 그걸 다시 제품으로 옮기며 전파하는 과정에 있습니다.

여기서 확인한 게 있습니다. 밀도를 잡은 것도, AI CoS를 붙인 것도 결국 같은 질문에 답하기 위한 수단이었습니다. 고객이 쓸 수 있는 제품인가. 어떤 도구로 만들었는지는 이 질문 앞에서 아무 의미가 없습니다.

3개월, 그리고 남은 것

돌아보면 저는 이 제품을 AI만으로 만들지 않았습니다. 리서치, 기획, 인터뷰, 디자인이라는 과정 자체는 그대로였고, 도구만 구간에 맞게 바뀌었습니다. 다만 그 도구 덕분에 예전의 저라면 혼자 감당할 수 없었을 범위의 기획을 해낼 수 있었습니다.

AI가 나왔다고 디자이너가 반드시 코드를 쓰고 PM이 디자인을 해야 하는 세상은 아니라고 생각합니다. 진입 장벽이 낮아져 누구나 만들 수 있게 됐을 뿐, 각자의 관점에서 풀 수 있는 문제는 여전히 다릅니다.

3월의 노트북과 5월의 노트북 사이에 있던 건 새로운 기능이 아니었습니다. 셀이 놓이는 간격, 상태가 전환되는 방식, 처음 진입한 사람이 무엇을 먼저 보게 되는지, 실패했을 때 어디로 갈 수 있는지. 제품의 완결성은 이런 것들의 총합이고, 이건 도구가 대신 결정해주지 않습니다.

결국 그 판단의 근거는 제품과 고객, 가치에 대한 이해였습니다. 이건 어떤 도구를 쓰든 줄어들지 않는 몫이라고 생각합니다.