무료 도구로 시작하는, SEO·GEO를 지속 개선하는 웹사이트

채팅 메시지가 제품 웹사이트, 행동 분석, 검색 데이터와 연결되고 보고서와 달력이 정기적인 검토 과정을 나타내는 모습

개념 일러스트: 채팅 요청에서 웹사이트 배포와 정기 검토로 이어지는 흐름입니다. 실제 제품 화면이나 성장 성과를 나타내지 않습니다.

제품 웹사이트를 공개한 뒤에도 팀에는 할 일이 남습니다. 페이지가 열리는지, 클릭이 기록되는지, 방문자가 어디에서 오는지, 다음에는 무엇을 개선할지 확인해야 합니다.

이 정보는 호스팅 플랫폼, 분석 도구, 검색 관리 화면에 흩어져 있습니다. 다음 웹사이트 업데이트를 결정하려면 누군가 이 정보를 모아야 합니다.

Leina를 사용하면 팀이 Slack에서 작업을 요청하고, 필요한 앱을 연결한 뒤, 같은 대화에서 결과를 받을 수 있습니다. 사이트 제작 요청은 성과 검토, 합의한 범위 내의 수정, 결과 보고로 이어지는 정기 작업으로 확장할 수 있습니다.

Vercel은 배포를 담당하고, PostHog는 사이트 내 행동을 기록하며, Google Search Console은 검색 실적 데이터를 제공합니다. Leina는 이 도구들을 하나의 작업 흐름으로 연결합니다.

이 글은 녹화된 Leina 사례를 Slack 사용 환경에 맞게 각색했습니다. 원래 시연에서는 Feishu를 사용했으며, 아래 구현 결과는 해당 시연을 근거로 합니다.

무료 도구로 줄일 수 있는 비용

PostHog는 무료 사용량을 제공하고 Google Search Console은 무료입니다. Vercel Hobby는 개인의 비상업적 용도로 제한되므로 상업용 사이트에는 해당 용도를 허용하는 요금제가 필요합니다. 무료 도구로 시작한다는 것은 조건에 맞는 서비스와 무료 사용량을 활용한다는 뜻입니다. Leina, 도메인, 초과 사용 비용은 별도로 확인하세요.

웹사이트와 데이터 요구 사항을 함께 정하기

먼저 Leina에서 Vercel, PostHog, Google Search Console을 연결합니다. 그런 다음 Slack에서 필요한 페이지와 측정할 항목을 함께 요청합니다.

Leina 제품 소개 사이트를 만들어 주세요. 홈페이지, 가격 페이지, 기능 페이지, 블로그가 필요합니다. 연결된 Vercel 계정으로 배포하고, PostHog로 주요 행동을 추적하는 보고서를 만들어 주세요. 지속적인 SEO 분석을 위해 Google Search Console도 연결해 주세요.

이 요청에는 페이지 범위, 사용할 앱, 공개 후 필요한 데이터가 담겨 있습니다. 팀은 사이트에 접속할 수 있는지, 중요한 행동이 기록되는지, 이후 분석의 데이터 출처가 명확한지 확인할 수 있습니다.

녹화된 사례에서는 Vercel 도메인에 제품 데모 사이트가 만들어졌습니다. 기능과 가격은 공식 제품 정보를 기준으로 한다는 점도 사이트에 명시했습니다.

세 가지 앱으로 살펴보는 웹사이트

각 앱은 웹사이트의 서로 다른 측면을 보여 줍니다.

앱	작업 흐름에서의 역할	확인할 수 있는 사항
Vercel	웹사이트 배포와 배포 상태 확인	페이지가 공개되었는지, 변경 사항이 반영되었는지
PostHog	페이지 조회, 버튼 클릭, 읽기 행동 기록	어떤 페이지를 방문하고 어디에서 다음 행동으로 넘어가는지
Google Search Console	사이트 확인과 검색·색인 정보 조회	분석할 검색 데이터가 있는지, 어떤 페이지에 주목해야 하는지

이 연결을 통해 Leina가 작업에 필요한 도구에 접근할 수 있습니다. 실제 가능한 작업은 승인된 계정, 프로젝트, 접근 권한에 따라 달라집니다. 자세한 내용은 안전한 업무 앱 연결(영문)을 참고하세요.

Slack 요청에서 웹사이트와 데이터까지

flowchart TB
  accTitle: Slack 요청에서 웹사이트와 데이터까지
  accDescr: 팀이 Slack에서 작업을 요청하면 Leina가 승인된 연결로 Vercel, PostHog, Google Search Console을 사용하고 결과를 Slack으로 반환합니다.
  C("Slack
요청과 결과"):::channel <--> L("Leina"):::agent
  L --> A("승인된 앱 연결"):::gateway
  A --> V("Vercel
사이트 배포"):::resource
  A --> P("PostHog
사이트 내 행동"):::resource
  A --> G("Google Search Console
검색 실적"):::resource

Slack에서 요청과 결과를 주고받고, Leina는 승인된 연결로 배포, 사이트 행동 분석, 검색 데이터를 처리합니다.

확인 가능한 결과와 함께 사이트 전달하기

녹화된 완료 보고에서 Leina는 8개 페이지를 배포하고 모든 페이지가 HTTP 200을 반환하는지 확인했다고 보고했습니다. 이후 화면에는 실제로 접속 가능한 제품 페이지와 Ready 상태의 Vercel 배포가 나타났습니다.

보고에는 페이지 제목과 설명, 대표 URL, 소셜 공유 메타데이터, 구조화된 데이터, robots.txt, 사이트맵, 글 사이의 내부 링크 등 검색을 위한 기본 설정도 포함되었습니다.

이 목록은 다음 업데이트에서도 활용할 수 있습니다. 팀은 페이지 주소, 배포 기록, 설정 내용을 확인하고 변경 후 같은 항목을 다시 검증할 수 있습니다.

페이지와 함께 데이터 수집도 검증하기

시연에는 PostHog 대시보드도 등장합니다. Leina는 방문, 인기 페이지, 행동 유도 버튼(CTA), 내부 링크, 글 읽기 깊이, FAQ 상호작용, 유입 경로, 기기 등을 다루는 보고서 11개를 만들었다고 설명했습니다. 브라우저에서 조회와 클릭을 수행해 이벤트가 들어오는지도 확인했습니다.

페이지가 작동하는지와 사용자 행동을 측정할 수 있는지를 함께 확인합니다.

방문자가 ‘가격 보기’를 클릭하면 해당 이벤트가 나타날까요? 어떤 글을 읽고 얼마나 읽었는지 식별할 수 있을까요? 이런 확인을 마쳐야 이후 분석에 데이터를 사용할 준비가 됩니다.

시연의 초기 수치는 인수 테스트에서 나온 데이터입니다. 이벤트 수집이 작동한다는 사실은 보여 주지만, 실제 고객 행동을 평가하려면 이후 운영 데이터가 필요합니다.

사이트 소유자가 참여할 단계도 흐름에 포함하기

Google Search Console 설정에는 사이트 소유자의 참여가 필요한 단계가 있었습니다. 시연 당시 소유권 확인이 완료되지 않았고, 주어진 권한만으로 직접 마칠 수 없었기 때문입니다.

Leina는 남은 작업을 설명했습니다. Search Console에서 HTML 확인 태그를 받아 사이트에 삽입하도록 전달하고, 다시 배포한 뒤, Google 관리 화면에서 확인을 완료하는 순서입니다.

대화에서 인계 지점이 명확해졌습니다. 이후 Search Console 화면에는 데이터 처리 중이라는 안내와 일부 보고서의 사용 데이터가 부족하다는 상태가 표시되었습니다.

이 단계의 성과는 데이터를 수집하고 점검할 기반을 갖추는 것입니다. 검색 데이터가 쌓이려면 시간과 활동이 필요합니다. 초기 보고서에는 확보된 데이터와 부족한 부분을 함께 설명해야 합니다.

정기 검토를 구체적인 작업으로 만들기

사이트가 운영되기 시작하면 Slack에서 다음 요청을 추가할 수 있습니다.

한 달에 두 번 SEO와 클릭 분석 보고서를 작성해 주세요. 합의한 범위 안에서 결과를 바탕으로 사이트를 개선해 주세요. 목표는 더 많은 방문자가 유료 고객으로 전환되게 하는 것입니다.

다음으로 어떤 데이터를 검토할지, 어디로 보고서를 보낼지, Leina가 어떤 수정을 할 수 있는지 정합니다.

녹화된 사례의 마지막에는 활성화된 SEO 및 전환 보고 작업이 표시되었습니다. 실제 일정은 매월 1일과 15일 오전 10시였습니다. 이는 월 2회 일정입니다. 정확히 14일마다 실행해야 한다면 간격과 기준 시간대를 명시해야 합니다.

설정된 작업에는 다음 단계가 포함되어 있었습니다.

Search Console과 PostHog에서 관련 데이터를 가져옵니다.
해당 기간의 실적과 분석 결과를 PDF 보고서로 만듭니다.
미리 정한 조건을 확인하고 승인된 범위에서 제한적으로 수정합니다.
배포 후 관련 페이지와 이벤트 수집을 검증하고 변경 내용을 기록합니다.
요약과 보고서를 원래 대화로 보냅니다. 이 각색에서는 Slack이 전달 대상입니다.

작업 화면은 정기 실행이 설정되었다는 사실을 보여 줍니다. 여러 주기에 걸쳐 성공적으로 실행되었거나 성과가 개선되었다는 측정 결과까지 입증하지는 않습니다.

정기 분석에서 다음 개선까지

flowchart TB
  accTitle: 정기 분석에서 다음 개선까지
  accDescr: 예약 작업이 검색과 행동 데이터를 수집하고, 부족하면 원인을 보고합니다. 충분하면 분석과 수정 조건을 확인하고 변경을 검증한 뒤 Slack에 보고하고 다음 주기를 기다립니다.
  T("예약 실행"):::channel --> D("검색·행동
데이터 수집"):::resource
  D --> Q{"데이터가 충분한가?"}:::gateway
  Q -->|아니요| N("부족한 데이터와
원인 설명"):::restricted
  Q -->|예| R("성과 분석
보고서 준비"):::agent
  R --> J{"수정 조건 충족?"}:::gateway
  J -->|예| E("범위 내 수정
회차당 최대 두 곳"):::agent
  E --> V("배포 및 검증
변경·복구 방법 기록"):::resource
  J -->|아니요| H("요약과 보고서를
Slack으로 전달"):::channel
  V --> H
  N --> H
  H --> W("다음 주기 대기"):::channel
  W -.-> T

데이터가 부족하면 이유를 보고하고, 합의한 조건을 충족할 때만 수정합니다.

매번 수정할 수 있는 범위를 명확히 정하기

사례에서는 회차마다 수정할 수 있는 곳을 최대 두 곳으로 제한했습니다. 제목, 설명, CTA 문구, 내부 링크, 소셜 공유 메타데이터 등이 허용된 범위였습니다. 각 변경에는 이유, 기대 효과, 검증 방법을 남겨야 했습니다.

가격, 기능, 지원 플랫폼과 같은 제품 사실은 공식 정보를 따라야 합니다. 소유권 확인 태그와 유입 경로 추적 매개변수도 보존해야 합니다. 배포 확인과 원래 상태로 복구하는 방법 역시 작업에 포함되었습니다.

이렇게 정하면 어떤 제목을 바꿨는지, 왜 버튼을 수정했는지, 다음에는 어떤 지표를 볼지 검토하기 쉬워집니다.

시연의 임계값은 해당 작업에 맞춘 설정입니다. 다른 사이트라면 트래픽, 페이지 목적, 데이터 양에 맞게 조건을 정하고 테스트 활동과 고객 방문을 구분해야 합니다.

유료 전환 추적을 웹사이트 밖까지 연결하기

사업 목표는 유료 전환이지만, 제품 사이트에서 직접 관측한 것은 주로 조회, 클릭, 외부 이동이었습니다. 가입과 결제는 별도 시스템에서 이루어졌습니다.

Leina는 완료 보고에서 CTA 링크에 UTM 매개변수를 추가해 유입 경로와 버튼 위치를 구분했다고 설명했습니다. 홈페이지, 기능 페이지, 가격 페이지, 블로그 중 어디에서 들어왔는지 추적할 단서를 남기는 작업입니다.

어떤 진입점이 유료 고객으로 이어졌는지 알려면, 이동한 시스템이 매개변수를 보존하고 가입 및 결제 이벤트와 연결해야 합니다. 녹화에서는 이 준비를 보여 주었지만, 결제까지의 추적이 완성되었거나 전환율이 높아졌다는 결과는 보여 주지 않았습니다.

팀은 단계별로 확인할 수 있습니다. 먼저 조회와 클릭, 다음으로 업무 시스템에 전달되는 유입 정보, 마지막으로 해당 유입 정보와 연결된 가입 및 결제 결과를 검증합니다.

정기 SEO 개선을 GEO로 확장하기

SEO는 검색 노출을 다룹니다. GEO(생성형 엔진 최적화)는 AI 답변이 콘텐츠를 정확히 이해하고 언급하며 인용하는지에 주목합니다. 둘은 일부 콘텐츠·기술 기반을 공유합니다. Google 안내에서도 기본 SEO 원칙이 자사의 AI 검색 기능에 적용된다고 설명합니다.

확장 방안으로 고객 질문에 맞게 페이지를 개선하고 검증 가능한 제품 정보와 출처를 보강할 수 있습니다. 고정된 질문 목록으로 브랜드 언급, 인용 페이지, 답변 정확성을 정기 기록하고 사이트 행동 데이터와 함께 검토해 다음 콘텐츠 수정을 결정합니다.

이는 설계와 검증이 필요한 확장안입니다. 원본 영상에는 SEO, 클릭 분석, 예약 작업 설정이 나오지만 GEO 모니터링이나 AI 인용 증가 결과는 없습니다. GEO 평가에는 추가 데이터 출처와 점검 단계가 필요합니다.

검토할 수 있는 첫 결과부터 시작하기

이 흐름은 웹사이트 제작, 배포 점검, 분석, 정기 검토를 팀이 익숙한 대화로 가져옵니다. Slack에서 목표를 설명하고, 권한 승인이나 사이트 소유권 확인에 필요한 작업을 도우며, 같은 곳에서 결과를 받을 수 있습니다.

첫 요청은 다음처럼 작성할 수 있습니다.

제품 사이트의 배포 상태, 주요 페이지, 이벤트 추적을 점검해 주세요. 승인된 검색 및 행동 데이터로 초기 보고서를 작성하고, 출처와 부족한 데이터, 우선 해결할 두 가지 문제를 포함해 주세요. 보고서를 검토한 후에는 수정 범위와 검증 단계를 명확히 정해 합의한 주기로 실행해 주세요.

첫 결과를 검증할 수 있게 만든 뒤, 잘 작동한 단계를 정기 작업으로 설정합니다. 매번 같은 페이지, 측정 기준, 사업 목표를 바탕으로 다음 개선을 진행할 수 있습니다.

팀 활용에 관한 자세한 내용은 Leina 팀 AI 에이전트 개요(영문)와 팀 에이전트 권한 관리(영문)를 참고하세요.