여기어때 소개서 빌더의 진짜 자산은 AI가 아니라 문법이다
Gamma로는 원하는 수준이 안 나왔고, Genspark로는 소개서마다 같은 기준을 적용하기 어려웠습니다. Google Canvas로 직접 빌더를 만들어 봤더니 공유하고 운영하는 과정에서 렌더링과 레이아웃이 계속 어긋났고요. 여기어때 플랫폼 디자인팀의 한동현 디자이너가 AI 소개서 빌더를 만들기까지 거친 실패들입니다. 저는 이 실패 목록이 결과물보다 더 많은 걸 알려준다고 봐요.
세 도구가 공통으로 못 한 건 '여기어때가 소개서를 만드는 방식'을 지키는 일이었습니다. 팀도 시행착오 끝에 필요한 게 소개서를 만들어주는 AI 서비스가 아니라, 자기들 방식을 이해하고 그 기준 안에서 일관된 결과를 내는 제작 시스템이라는 걸 깨달았다고 적었어요. 이 문장에 이 프로젝트의 무게중심이 있습니다.
AI보다 먼저 한 일
빌더를 만들기 전에 팀은 Figma에 쌓여 있던 기존 소개서를 하나씩 열어 반복해서 쓰이는 내용을 찾았습니다. 그렇게 모은 페이지를 Main Cover, Index, Intro 같은 카테고리로 나누고, 카테고리 안의 레이아웃 차이는 Type으로 구분했어요. 이때 그래픽과 컬러는 일부러 빼고 레이아웃과 타이포그래피 체계부터 정리하는 걸 1차 목표로 잡았습니다.
제가 보기에 이 빌더의 진짜 자산은 이 카테고리×Type 표입니다. 디자이너가 매번 머릿속으로 내리던 판단, 그러니까 어떤 정보를 어떤 순서로 어떤 레이아웃에 담을지를 밖으로 꺼내 문법으로 만든 거죠. 디자인 시스템을 컴포넌트로 쪼개본 팀이라면 익숙한 작업입니다. 그래픽과 컬러를 뒤로 미룬 판단도 좋았다고 봐요. 장식부터 템플릿에 넣으면 문법이 아니라 스킨이 먼저 굳어버리니까요.
여기에 UX Writer가 미리 정리해둔 소개서 제작 SOP가 있었다는 점도 결정적입니다. 서비스 개요, 타겟, 핵심 가치, FAQ처럼 무엇을 써야 하는지가 이미 정해져 있었기에 AI가 할 일은 그 내용을 정해진 카테고리와 Type에 배치하는 쪽으로 좁혀졌습니다. 내용의 문법은 SOP가, 형태의 문법은 Type 표가 쥐고 있고, AI는 둘을 잇는 역할이에요.
그래서 이건 사서 쓸 도구가 아니라 만들어야 하는 도구였습니다. 기성 툴이 실패한 이유가 모델 성능이 아니라 '우리 기준'을 담을 자리가 없어서였으니까요. 대신 비용이 따라옵니다. 기존 소개서를 해부해 문법을 뽑는 데 디자이너의 시간이 들고, 레이아웃을 코드로 옮긴 순간부터는 그 코드를 유지할 사람이 필요합니다. 소개서를 1년에 몇 장 만들지 않는 회사라면 이 투자는 회수되지 않아요. 여러 사업부가 자주 새 덱을 찍어내는 회사일수록 계산이 맞습니다.
사용자에게 열어둔 세 개의 문
정리한 레이아웃은 Google Antigravity의 Pencil Extension으로 코드에 옮겼고, Claude로 웹 빌더를 만들었습니다. 사용자는 질문지에 답하는 입력 모드, 기존 회사 소개서를 올리는 원클릭 모드, 직접 쓰는 수동 모드 중에서 고릅니다.
팀이 처음 쓰는 사람에게 입력 모드를 권하는 이유도 문법으로 설명됩니다. 질문지는 SOP를 화면으로 옮긴 것이라, 답을 채우는 순간 내용이 이미 문법에 맞춰 들어옵니다. 원클릭 모드는 반대로 형식이 제각각인 기존 문서를 문법에 끼워 맞춰야 하니 결과가 흔들리기 쉽고요. 필요한 부분만 다시 생성하는 부분 수정과, 사내 아이콘 생성기를 연동해 그래픽을 바로 만드는 기능도 붙었습니다.
문법 밖에서 흔들린 이유
PO들과 1~2주 사용성 테스트를 해보니, SOP와 템플릿 안에서는 슬라이드가 꽤 일관되게 나왔습니다. 문제는 SOP에 없는 텍스트를 추가할 때였어요. 기존 슬라이드와 다른 디자인 방향의 결과물이 나왔다는 피드백이 돌아왔습니다.
팀은 다음 과제를, 디자이너가 새 템플릿을 계속 추가하는 대신 AI가 기존 패턴을 이해해 새 내용에도 비슷하게 적용하는 시스템으로 잡았습니다. 저는 이 방향에 절반만 동의합니다. 문법에 없는 내용을 AI가 알아서 브랜드답게 처리해주길 기대하는 건, 이 프로젝트가 처음에 Gamma와 Genspark에서 겪은 문제를 다시 AI에게 맡기는 일에 가깝거든요. 기준 밖에서의 일관성은 모델이 똑똑해진다고 저절로 생기지 않습니다.
더 빠른 길은 문법 안에 예외를 받는 자리를 만드는 쪽이라고 봐요. 어떤 카테고리에도 맞지 않는 내용이 들어오면 무리하게 새 레이아웃을 만들지 않고 범용 Type 하나로 받아내고, 그런 내용이 쌓이면 디자이너가 그걸 보고 새 Type을 추가하는 경로를 처음부터 두는 겁니다. 디자인 시스템이 컴포넌트에 없는 요구를 다룰 때와 같은 방식이죠.
테스트 대상이 사내 PO였다는 점도 기억해둘 만합니다. PO는 소개서 SOP에 익숙하고 이상한 결과가 나오면 다시 생성할 줄 아는 사용자예요. 이 빌더가 겨냥하는 영업팀이 실제 고객사에 보낼 덱을 급하게 만들 때는 문법 밖의 내용이 훨씬 자주 들어오고, 흔들린 결과물이 그대로 밖으로 나갈 수 있습니다. 확장성 과제를 풀기 전에 문법 밖 입력이 얼마나 자주 들어오는지부터 세어보면, 범용 Type 하나로 충분한지 AI가 필요한지가 숫자로 갈릴 거예요.
이 빌더가 맞는 회사, 안 맞는 회사
이 방식이 통하는 조건은 분명합니다. 구조가 반복되는 소개서가 많고, 무엇을 써야 하는지 정한 SOP가 있고, 문법을 관리할 디자이너가 계속 붙어 있을 것. 여기어때는 셋 다 갖췄기에 영업팀과 구성원이 직접 소개서를 만드는 단계까지 갈 수 있었습니다. 반대로 매번 서사가 달라야 하는 투자 유치 덱이나 큰 캠페인 제안서라면, 문법이 오히려 이야기를 납작하게 만들 수 있습니다.
디자이너의 역할도 바뀝니다. 출발점은 소개서를 만들 때마다 같은 판단을 반복하며 쌓이던 피로였는데, 빌더가 자리를 잡으면 디자이너는 장표를 그리는 사람에서 문법을 관리하는 사람으로 옮겨갑니다. 반복은 줄지만 결과물이 덜 눈에 띄는 일이라, 조직이 그 일을 성과로 인정해주지 않으면 문법 관리는 금방 뒷전이 되기 쉽습니다.
브랜드 쪽에서 짚을 점도 하나 있습니다. 빌더가 퍼질수록 브랜드 일관성은 디자이너의 손이 아니라 템플릿 문법이 지킵니다. 그 문법을 누가 갱신하고 언제 Type을 늘릴지 정해두지 않으면, 1년 뒤에는 문법은 그대로인데 브랜드만 바뀐 상태가 올 수 있어요. 저는 이 빌더를 만들려는 팀에게 AI 모델 고르기보다 문법의 관리자 정하기를 먼저 권하고 싶습니다.