콘텐츠 열심히 만들어도 왜 AI는 우리 회사를 모를까?

프론트엔드 개발자 출신 PO가 GEO 서비스를 만들며 마주한 네 가지 고민

제가 다니는 회사는 UX를 중심으로 일하는 곳입니다. 저는 처음에 외부 파트너사로 이 회사와 협업했고, 2019년에 사내에 프론트엔드 개발 그룹이 새로 꾸려지면서 초기 멤버로 합류했습니다. 그 뒤로 여러 프로젝트를 진행했습니다. 함께 일한 클라이언트와 파트너사로부터 다음 프로젝트나 운영 업무를 이어서 맡아 달라는 요청도 종종 받았습니다. 기술 블로그도 꾸준히 운영하고 있었기 때문에, 저희 팀이 어떤 일을 하는지는 어느 정도 알려져 있다고 생각했습니다.

그런데 어느 날 AI에게 “프론트엔드 개발을 잘하는 회사가 어디야?”라고 물었더니, 답변에 저희 회사가 나오지 않았습니다. 실제로 진행한 프로젝트가 있고 공개된 글도 있는데, AI는 왜 그 정보를 답변에 반영하지 않았을까요? 원인을 따져 보니 정보가 부족한 것은 아니었습니다. 정보는 있었지만, AI가 그 정보를 찾지 못하거나 근거로 활용하지 못하고 있었습니다. 이 경험을 계기로 저희는 GEO(생성형 엔진 최적화, Generative Engine Optimization)를 살펴보기 시작했고, 결국 서비스를 직접 만들게 되었습니다.

이 글은 AI 검색 환경에서 제품이나 서비스를 만드는 분들을 위해 썼습니다. 새 기능에 AI를 도입할지 고민하는 기획자, 작은 팀으로 규모가 큰 제품을 운영해야 하는 개발자나 팀장이라면 비슷한 고민을 해 보셨을 것입니다. 기술 자랑이 아니라, 만들면서 실제로 무엇을 정했고, 그게 사업적으로 무엇을 바꿨는지에 대한 이야기입니다.

계기는 이렇게 사소했지만, 정작 어려운 건 그 다음이었습니다. 만들기로 하고 나니 힘든 건 코드가 아니라 매번 무언가를 정하는 일이었습니다. 무엇을 만들지, 무엇을 안 만들지, AI를 어디까지 믿을지, 제가 겪은 경험을 하나씩 풀어보겠습니다.

미리 요점만 짚어보면?

• 검색은 GEO로 넘어가고 있지만, GEO의 토대는 여전히 기본 SEO입니다. 그래서 저희는 GEO를 중심에 두되 기본 SEO까지 함께 봤습니다.
• AI는 콘텐츠가 많다고 인용하지 않습니다. ‘확인되는 사실’을 인용합니다. 그걸 규칙으로 바꾸는 게 일이었습니다.
• AI를 제품에 넣는 건, 어디에 쓸지보다 어디엔 안 쓸지를 정하는 일에 가깝습니다.

고민 1. 이건 ‘SEO 도구’일까, 그 너머일까

처음엔 단순했습니다. “웹 최적화 진단을 자동화하자.” 그런데 2025년 7월 무렵, 시장을 볼수록 애매해졌습니다. 사람들이 이제 검색 결과를 잘 누르지 않습니다. AI가 요약해준 답만 읽고 끝내죠. 그러면 ‘검색 상단 노출’(SEO)과 ‘AI가 인용해주는 것’(GEO)은 완전히 다른 목표가 됩니다.

그래서 정해야 했습니다. SEO? GEO? 저희는 둘 다 아니라고 봤습니다. 기업 사이트는 아직 구글에도 잘 떠야 하고, 동시에 AI에게도 읽혀야 하니까요. 저희는 GEO를 중심에 두기로 했습니다. 대신 AI에 잘 읽히려면 크롤링이 되는지, 문서 구조가 잡혀 있는지 같은 기본 SEO가 먼저 돼 있어야 해서, 그 기본까지 함께 진단하기로 했습니다. 키워드 순위 대시보드 같은 전형적인 SEO 도구를 만든 게 아니라, GEO를 기준으로 삼되 그 토대가 되는 SEO를 같이 챙기는 방식입니다.

사실 이 한 줄을 정하는 데도 팀에서 꽤 얘기했습니다. “그래서 우리 SEO 플랫폼을 만들거야, GEO 플랫폼을 만들거야?”라고 누가 묻길래 “둘 다요”라고 답했는데, 그 말을 하면서 오히려 방향이 또렷해졌습니다.

고객 입장에서도 GEO를 하려면 어차피 기본 SEO부터 봐야 하니, 둘을 한자리에서 점검할 수 있는 게 이득이었습니다. 지금도 결과 화면에서 GEO를 중심에 두고 기본 SEO를 함께 보여주는데, 따지고 보면 이때 정한 방향에서 그대로 나온 겁니다.

고민 2. 정답이 없는 시장에서, 진짜 인용되는 건 뭘까?

이게 제일 막막했습니다. SEO는 그 동안 프론트엔드, 웹접근성 작업을 하면서 쌓인 노하우가 있는데, GEO는 “AI가 대체 무엇을 인용하는가”에 대한 정답이 없거든요. 저희가 한참 개발 중이던 2025년 7~9월엔 국내에 참고할 GEO 서비스라는 게 사실상 없었습니다. 물어볼 데가 없으니 그냥 저희가 직접 보는 수밖에 없었습니다.

그래서 국내외 사이트를 대여섯 곳 붙잡고, 똑같은 질문을 챗지피티(ChatGPT), 클로드(Claude), 제미나이(Gemini), 퍼플렉시티(Perplexity) 네 군데에 던져봤습니다. 이 서비스들이 한 사이트에서 어떤 문장을 끌어다 쓰는지 하나하나 비교한 겁니다. 처음엔 “이렇게 눈으로 대충 봐도 되나” 싶었는데, 네 곳의 답을 나란히 놓고 보니 겹치는 게 눈에 들어왔습니다. 어떤 사이트는 검색엔 멀쩡히 뜨는데 AI 답변에선 한 번도 불려 나오지 않고, 어떤 사이트는 특정 페이지 하나가 계속 인용됐습니다. 그 차이가 무엇인지 계속 들여다봤습니다.

콘텐츠가 많다고 인용되는 게 아니었습니다. 관건은 “인용하기 좋게 쓰였는가”였습니다. 예를 들어, “우리는 사용성 테스트로 개선안을 제시합니다” 같은 문장은 홍보 문구라 거의 끌려가지 않았습니다. 반면 “사용성 테스트 결과 사용자 60%가 결제 단계에서 이탈했고, 플로우를 고친 뒤 완료율이 40%에서 68%로 올랐다” 같은 문장은 자주 인용됐습니다. 내용은 같은데 서술만 다릅니다. AI는 ‘주장’보다 ‘확인되는 사실’을 골라 갔습니다.

여기서부터가 진짜 일이었습니다. 이 감을 그대로 두면 그냥 생각일 뿐이니까요. 그래서 “숫자 근거가 있는가”, “AI가 답하기 좋은 구조인가”, “톤이 광고 같지 않은가” 같은, 코드가 판별할 수 있는 항목으로 하나하나 옮겼습니다. 막상 옮기려니 애매한 것도 많았습니다. 예를 들어 ‘중립적인 톤’은 사람 눈엔 대충 보이는데, 그걸 코드에 어떻게 설명할까요? 이런 걸 더 작은 기준으로 쪼개는 데 시간이 은근히 걸렸습니다. 그래도 지나고 보니 이때 직접 모은 기준이 저희에겐 제일 큰 자산이었습니다.

고민 3. 백엔드 하는 사람이 없는데, 어떻게 다 만들지?

이 서비스는 크롤링, 브라우저 렌더링, 비동기 분석, DB, 인증까지 다 필요했습니다. 거의 다 백엔드죠. 그런데 저희 팀은 저를 포함해 전원 프론트엔드였습니다. 백엔드를 본업으로 해본 사람이 하나도 없었습니다.

원래대로면 백엔드를 뽑거나 외주를 줘야 했겠죠. 하지만 저희는 다른 선택을 했습니다. AI를 최대한 활용해서 직접 해보기로..! 얼마만큼의 퀄리티가 나와줄지 아무도 모르는 상황에 그 당시에는 바이브 코딩이 이제 겨우 사람들 입에 오르내리는 상태여서 엄청나게 파격적인 선택이었지만, 해보기로 했습니다.

그리고 바로 어려움에 부딪혔죠. 팀 전체가 AI 도움으로 짜다 보니 사람마다 결과물의 결이 다르고 동시 작업을 했을 때 머지가 힘들어, 그걸 리뷰하고 맞추는 데 시간이 훅훅 들어갔습니다. 똑같은 기능인데 누구는 이렇게, 누구는 저렇게 짜놓으니 나중에 합칠 때 서로 코드를 다시 읽어야 했으니까요. 그리고 다른 사람의 작업을 원복하거나 회귀하는 현상이 잦아졌습니다. 그러다보니 “혼자서 하는 게 더 빠르겠는데?”라는 생각과, 분명 팀 작업인데 순서를 정해놓고 작업하는 이상한 상황까지 가게 되었습니다.

그래서 일하는 방식 자체를 재정비했습니다. 코드부터 뽑지 말고 스펙을 먼저 확정하게 하고, 설계를 꼼꼼히 하고, 코드 작성 후 인수테스트 시나리오까지 모두 돌려봅니다. 그리고 짠 코드는 자동으로 리뷰와 QA를 거치게 했습니다. 저희만의 방식을 도구에 심어 다들 똑같이 일하도록 한 겁니다. AI가 짠 코드일지라도 사람이 짠 것과 최대한 비슷해질 수 있게 코드 품질을 유지하고, 버그에 대응할 수 있게 규칙을 설정해 코드의 퀄리티를 업 시킨 거죠.

팀원이 같이 사용할 수 있는 스킬들을 만들고 해당 스킬은 자가 성장할 수 있는 루프까지 심어서 활용했습니다. 작은 팀이 11월 베타부터 이듬해 4월 정식 오픈을 거쳐 지금까지 버틴 힘이 여기 있었다고 생각합니다.

고민 4. AI를 한가운데 두면서, 신뢰는 어떻게 지키지?

이 제품의 핵심은 AI가 개선 가이드를 주는 겁니다. 저희도 처음엔 “AI가 알아서 잘하겠지” 했습니다. 그런데 초반에 크게 한 번 막혔습니다. 같은 사이트를 세 번 돌렸는데 점수가 72, 85, 61로 나왔습니다. 없는 태그를 있다고 하고, 엉망인 사이트에 점수를 후하게 주기도 했습니다. 데모면 귀엽죠. 그런데 돈을 받는 제품에서 같은 사이트 점수가 매번 다르면, 고객은 그냥 믿지 않고 나갑니다. 그 세 개의 숫자를 보고 생각을 접었습니다.

그래서 AI에게 다 맡기지 않기로 했습니다. 사실 확인은 코드가 합니다. 예를 들어 robots.txt가 있는지 볼 때, 단순히 요청이 HTTP 200으로 돌아왔는지만 보면 안 됩니다. 에러 페이지가 200으로 리턴되는 경우도 있어서 그것만 믿으면 오작동하거든요. 그래서 응답이 200인지뿐 아니라, 그 페이지가 실제로 robots.txt 내용을 담고 있는지까지 확인해야 합니다. 이런 건 코드로 충분히 검증되니 AI의 해석이 필요한 영역이 아니었습니다.

대신 “이 콘텐츠가 전문가가 쓴 것 같은가”, “믿을 만한가” 같은 건 AI가 사람보다 일관되게 봐줍니다. 프롬프트도 한 번에 다 묻지 않고 영역별로 쪼갰고, AI가 준 답도 형식이 맞는지 한 번 더 걸러서 화면에 띄웠습니다. 이렇게 나누고 나서는 같은 사이트를 다시 돌려도 점수가 예전처럼 크게 튀지 않았습니다. 결국 AI를 ‘어디에 쓸까’가 아니라 ‘어디엔 안 쓸까’를 먼저 정한 셈입니다.

결론: 아직 못 푼 고민도 있습니다

이렇게 네 가지를 정했는데, 돌아보면 대부분 “무엇을 안 할지”를 정한 일이었습니다. 그런데 솔직히, 아직 답을 못 낸 게 하나 더 있습니다. 우리 제품은 대체 누굴 위한 걸까요. 베타부터 정식 오픈까지 오는 내내 이 질문을 자꾸 미뤘습니다. 저희가 전원 프론트엔드다 보니 개선 가이드도 어느새 개발자가 보기 편한 쪽으로 가 있었습니다. robots.txt가 어떻고 canonical이 어떻고 하는 얘기가 많았죠. 그런데 GEO를 진짜 필요로 하는 곳이 어디인지 들여다볼수록, 개인 사용자보다 브랜드와 기업 쪽에서 그 값어치가 훨씬 크다는 걸 알게 됐습니다. 자기 콘텐츠가 AI에 어떻게 노출되는지를 성과로 관리해야 하는 것에 가장 예민한 곳은 결국 기업이니까요.

인지의 문제도 컸습니다. 앞에서 “AI가 우릴 못 찾더라”라고 했던 그 고민이, 이번엔 저희 서비스 자체에 똑같이 돌아왔습니다. 좋은 제품을 만드는 일과 그걸 알리는 일은 완전히 다른데, 사람들에게 지오닉을 알리는 건 생각보다 훨씬 어려웠습니다. 그렇다고 다 풀린 건 아닙니다. 결과 화면이 여전히 개발자 눈높이라는 것도 아직 저희가 풀어야 할 숙제입니다. 마케터가 처음 들어와도 “이건 나도 해볼 만하다” 싶게 만드는 것, 그게 지금 저희의 다음 고민입니다.

마치며

돌아보면 이 글은 GEO 서비스를 만든 이야기이면서, 동시에 프론트엔드만 하던 팀이 낯선 영역까지 끌어안고 제품 하나를 끝까지 만들어낸 기록이기도 합니다. 저희에게 더 큰 숙제였던 건 사실 GEO보다 이쪽이었습니다. 그 과정에서 가장 오래 붙들었던 질문은, 네 번째 고민에서 잠깐 스쳤던 것이었습니다. AI에게 판단을 맡기면서도, 그 결과를 고객이 믿을 수 있게 만드는 일이죠.

그래서 다음 편에선 그 이야기를 정면으로 파보려고 합니다. 같은 페이지를 봤는데 점수가 매번 다르면 그건 진단이라 할 수 없으니까요. AI에게 무엇을 맡기고 무엇은 맡기지 않을지, 그 선을 어떻게 그어 진단을 믿을 수 있게 만들었는지 실제 사례로 풀어보겠습니다.

※ 이 글은 AI의 도움을 받아 작성했습니다. 초반 구조 설계와 자료 정리에 AI를 활용했으며, 데이터 해석과 판단, 최종 문장은 직접 작성했습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.