기능이 아니라 실패 원인을 먼저 썼습니다

기능을 아무리 자세히 써도 왜 반응이 없었을까요

문서에서 표와 텍스트를 정확히 뽑아내 LLM에 넣어주는 제품을 만드는 스타트업입니다. 기술력은 분명히 있었는데요, 문제는 시장에서 이 제품군을 뭐라고 불러야 하는지조차 아직 정해지지 않았다는 점이었습니다. 어떤 곳은 Document AI라 부르고 어떤 곳은 문서 파싱이라고 부르던 시기였거든요.

그동안 만들어온 콘텐츠를 열어보니 대부분 기능 소개였습니다. 정확도가 몇 퍼센트인지, 어떤 문서 포맷을 지원하는지 같은 이야기가 반복되고 있었는데요, 정작 AI 답변에서는 거의 인용되지 않고 있었습니다.

잠재 고객은 제품이 아니라 자기가 겪는 증상을 검색하고 있었습니다

그래서 방향을 바꿔서 타깃 고객이 실제로 던지는 질문을 모아놓고 하나씩 읽어봤습니다. 제품명이나 카테고리명으로 검색하는 사람은 생각보다 드물었고, 대부분은 지금 자기가 겪고 있는 문제를 그대로 문장으로 쓰고 있더라고요.

문제를 검색하는 사람이 구매에 훨씬 가깝습니다

‘Document AI 추천’을 묻는 사람과 ‘PDF 표가 깨진다’를 묻는 사람은 급한 정도가 완전히 다릅니다. 뒤쪽은 이미 프로젝트가 돌아가고 있는데 어딘가에서 막혀 있는 상태거든요. 그래서 답이 되는 문서를 만나면 곧바로 검토 대상에 올립니다. 혹시 리드 수는 나오는데 상담이 잘 붙지 않는다면, 어떤 질문을 통해 들어온 리드인지 한번 갈라서 보시길 권합니다.

모든 문서를 문제에서 시작해 해결로 끝나도록 다시 짰습니다

문서 구조를 하나로 통일했습니다. 어떤 문제가 있는지 먼저 쓰고, 왜 그 문제가 생기는지 원인을 설명한 다음, 무엇을 기준으로 판단하면 되는지와 어떻게 푸는지를 순서대로 이어 붙이는 방식입니다. 자사 제품은 맨 마지막에 한 번만 등장합니다.

원인을 개발자가 납득할 만큼 기술적으로 설명했습니다

PDF 표가 깨지는 이유를 레이아웃 정보가 손실되는 문제와 병합된 셀을 처리하는 문제로 나눠서 설명했습니다. 이 시장에서는 읽는 사람이 개발자라, 마케팅 톤으로 두루뭉술하게 쓰면 그 문서는 인용되지 않습니다. 쉽게 말하면 검증할 수 없는 글은 답의 재료로 쓰이지 못하는 겁니다.

직접 재현해 볼 수 있는 예시를 함께 넣었습니다

어떤 형태의 표가 어떤 식으로 깨지는지를 실제 출력 결과와 함께 보여줬습니다. 코드와 결과가 나란히 있는 문서는 인용률이 눈에 띄게 높았는데요, 읽는 사람이 직접 돌려보고 확인할 수 있기 때문이라고 보고 있습니다.

자사 제품이 답이 아닌 경우도 그대로 적었습니다

문서 구조가 단순하고 양이 많지 않다면 오픈소스로도 충분하다고 썼습니다. 모든 문제의 답이 자사 제품으로 끝나면 그 글은 판매 자료로 읽히고, 그렇게 읽히는 순간 인용에서 밀리기 때문입니다. 내부에서 이 문장을 두고 논의가 좀 있었는데, 지나고 보니 이 부분이 신뢰를 만들어 줬습니다.

문서끼리 서로를 가리키도록 연결했습니다

원인을 설명하는 문서에서 해결 방법 문서로, 해결 방법 문서에서 구현 가이드로 크롤링 가능한 링크를 걸어서 묶었습니다. AI가 한 주제에 답할 때 여러 문서를 함께 참조하게 만들려는 의도였는데요, 이렇게 묶고 나니 하나가 인용될 때 옆 문서까지 같이 불려 나오는 경우가 생겼습니다.

영업 첫 미팅에서 제품을 설명하는 시간이 줄었습니다

기술 질문 커버리지가 6%에서 59%로 올라갔고, 월 데모 신청은 8건에서 27건이 됐습니다. AI를 거쳐 들어오는 인바운드 비중도 4%에서 31%로 늘었고요.

그런데 회사 안에서 가장 크게 체감했던 건 다른 부분이었습니다. 영업팀이 첫 미팅에서 제품 기본을 설명하는 데 쓰던 시간이 22분에서 9분으로 줄었거든요. 고객이 원인과 판단 기준을 이미 읽고 들어오니까 처음부터 설명할 것이 그만큼 없어진 겁니다. 유효 리드 비율도 29%에서 63%로 올랐습니다.

기술 스타트업 담당자분들께 드리고 싶은 이야기

증상을 검색하는 사람이 훨씬 급합니다

제품 카테고리를 묻는 사람보다 자기 문제를 묻는 사람이 구매에 가깝습니다. 이미 프로젝트가 돌아가는 중에 막혀 있기 때문인데요, 그래서 답이 되는 문서를 만나면 반응이 빠릅니다.

개발자를 상대하는 콘텐츠는 깊이가 조건입니다

기술 시장에서는 얕은 설명이 인용되지 않습니다. 재현할 수 있는 예시와 실제 출력 결과가 있어야 근거로 쓰이는데요, 이건 글 솜씨의 문제가 아니라 검증 가능성의 문제입니다.

우리 제품이 답이 아닌 경우도 한번 써보세요

모든 문제의 결론이 자사 제품이면 판매 자료로 읽힙니다. 예외를 한 줄 적어두면 나머지 문장이 믿어지는데요, 손해 보는 것 같아도 인용 측면에서는 이쪽이 이득입니다.

자주 묻는 질문

기능 소개 콘텐츠는 왜 인용되지 않을까요?

잠재 고객이 기능 이름으로 검색하지 않기 때문입니다. 특히 신생 제품군은 카테고리 이름조차 통일되어 있지 않아서, 사람들은 자기가 겪고 있는 증상을 그대로 문장으로 씁니다. 그 문장에 대응하는 문서가 없으면 아무리 잘 쓴 기능 소개라도 인용될 근거가 없습니다.

개발자 대상 콘텐츠는 어느 정도 깊이로 써야 할까요?

읽는 사람이 직접 확인해 보고 납득할 수 있는 수준이어야 합니다. 이 사례에서는 재현 가능한 예시와 실제 출력 결과가 들어간 문서의 인용률이 뚜렷하게 높았는데요, 마케팅 톤으로 쓴 개념 설명은 기술 질문의 답으로는 거의 쓰이지 못했습니다.

GEO가 영업 미팅에도 영향을 주나요?

이 사례에서는 제품 기본을 설명하는 시간이 22분에서 9분으로 줄었습니다. 고객이 원인과 판단 기준을 이미 읽고 들어오기 때문인데요, 데모 건수보다 이 변화가 영업 생산성 측면에서는 훨씬 크게 작용했습니다.

리드젠랩과 시작하려면 어떻게 하나요?

무료 진단 신청으로 시작합니다. 실제 고객 질문 20개를 주요 AI에 넣어 답변 80개를 분석하고, 현재 노출 상태와 경쟁 구도를 리포트로 드립니다. 이후 필요에 따라 GEO·AEO 대행 또는 컨설팅·내재화 방식을 정하고, 채널별 시작가는 요금 안내에서 확인하실 수 있습니다.

고객사와 체결한 비밀유지계약에 따라 기업명은 가명으로 표기했습니다. 수치와 실행 내용은 실제 프로젝트 측정 데이터입니다.