답변 엔진 최적화

한동안 검색창에 무엇을 치든 돌아오는 것은 파란 링크 열 개였습니다. 그래서 마케터가 할 일도 분명했습니다. 우리 페이지를 그 열 개 안에, 되도록 위쪽에 올려놓는 것입니다. 검색 엔진 최적화가 그 일을 맡았습니다. 사람들이 실제로 치는 검색어를 제목과 본문에 넣고, 다른 사이트가 우리 페이지로 링크를 걸게 만들고, 페이지가 느리게 뜨지 않도록 손보는 식입니다. 잘하고 있는지 확인하기도 쉬웠습니다. 검색어를 쳤을 때 나오는 화면인 검색 결과 페이지에서 우리가 몇 번째에 있는지만 보면 됐습니다.

그러다 결과 화면 맨 위에 링크가 아닌 것이 올라오기 시작했습니다. 검색 엔진이 여러 페이지를 읽고 직접 쓴 답변 문단이 목록 위에 붙었고, 사람들은 아예 검색창을 거치지 않고 챗봇에 묻기 시작했습니다. 질문한 사람은 그 답변을 읽고 그대로 창을 닫습니다. 답변을 만드는 데 우리 글이 쓰였더라도 클릭은 일어나지 않습니다. 검색 순위를 올려 유입을 얻던 방식이 성립하지 않는 구간이 생긴 것입니다.

페이지덱에서 이 변화가 처음 눈에 띈 것은 현우가 분기 유입을 정리하던 자리였습니다. "회의록 정리하는 방법" 으로 검색했을 때 3위에 올라 있던 글이 반년 내내 3위를 지켰는데, 그 글로 들어오는 사람은 월 4,000명에서 1,600명으로 줄어 있었습니다. 순위가 떨어진 것도 아니고 검색량이 줄어든 것도 아니었습니다. 현우가 직접 검색해 보니 목록 위에 요약 답변이 붙어 있었고, 내용은 우리 글에서 읽어 온 것이 분명한데 아래에 달린 출처 세 개에 우리 이름은 없었습니다. 우리 글이 재료로는 쓰이고 출처로는 안 쓰인 상태입니다.

답변 엔진 최적화는 이 자리를 겨냥해 생긴 말입니다. 목표가 순위에서 인용으로 바뀝니다. 노리는 것은 열 개 목록 안의 한 칸이 아니라 답변 문단이 근거로 삼는 출처 목록이고, 그래서 손대는 곳도 달라집니다. 검색어를 몇 번 반복해 넣었는지보다, 우리 문서에서 한 문단만 떼어 냈을 때 그것이 질문에 대한 답으로 성립하는지가 중요해집니다.

답변 엔진 최적화는 하나의 기법이 아니라 네 갈래가 한 이름으로 묶인 것입니다. 같은 일을 다른 각도에서 부르는 인접 개념, 실제로 손을 대는 수단, 잘됐는지 판정하는 기준, 그리고 결과가 눈에 보이는 자리입니다.

인접 개념은 이 일의 경계를 정합니다. 생성 엔진 최적화는 답을 문장으로 지어내는 생성형 엔진을 상대로 콘텐츠를 맞추는 접근이고, 실무에서는 답변 엔진 최적화와 거의 같은 뜻으로 오갑니다. 굳이 나눈다면 답변 엔진 최적화는 "질문에 답이 달린다" 는 결과에, 생성 엔진 최적화는 "그 답을 모델이 지어낸다" 는 방식에 무게를 둡니다. 같은 회의에서 두 말이 번갈아 나와도 서로 다른 일을 가리키는 것은 아니니, 팀 안에서 한쪽을 골라 쓰고 넘어가는 편이 낫습니다. 어느 말을 쓰든 손대는 파일과 고치는 문장은 같습니다.

수단은 모델이 우리 사이트를 읽는 통로를 만드는 일입니다.

1. llms.txt — 사이트 뿌리에 두는 텍스트 파일로, 우리 사이트가 무엇을 다루는지와 읽을 가치가 있는 핵심 문서가 어디인지를 목록으로 적어 둡니다. 모델이 수백 개 페이지를 헤매지 않고 정리된 문서부터 읽게 만드는 안내판입니다. 도움말 문서가 300개인 사이트에서 이 파일이 없으면 모델은 아무 페이지나 몇 개 집어 읽고, 있으면 우리가 앞에 적어 둔 열 개를 먼저 읽습니다.
2. 구조화 데이터 — 페이지 안의 어떤 덩어리가 질문이고 어떤 덩어리가 답인지, 어느 줄이 가격이고 어느 줄이 작성일인지를 기계가 알아보는 표기로 붙여 둔 것입니다. 사람 눈에는 똑같은 문단이지만 기계에게는 이름표가 달린 셈이라 발췌해 가기 쉬워집니다.

기준은 잘된 문서와 그렇지 않은 문서를 가릅니다.

1. 답변 추출성 — 한 문단만 떼어 놓아도 그 자체로 답이 되게 쓰였는지를 봅니다. "앞서 말한 세 가지 중 두 번째가 여기에 해당합니다" 로 시작하는 문단은 앞 문단을 읽어야 뜻이 통하니 떼어 낼 수 없고, "회의록은 회의가 끝난 당일에 정리합니다" 로 시작하는 문단은 그대로 답이 됩니다.
2. 인용 가능성 — 출처로 삼기 좋게 정리됐는지를 봅니다. 숫자에 기준 시점이 붙어 있는지, 주장에 근거가 달려 있는지, 글쓴이가 누구인지가 드러나는지 같은 것입니다. 같은 사실을 담은 두 문서가 있으면 모델은 확인 가능한 쪽을 출처로 답니다. "협업 도구 시장은 계속 커지고 있습니다" 보다 "2025년 기준 국내 협업 도구 도입률은 38퍼센트입니다" 쪽이 인용됩니다. 뒤 문장은 인용한 답변이 틀렸을 때 어디를 짚어야 하는지가 분명하기 때문입니다.

결과는 이 일이 실제로 나타나는 자리입니다. AI 개요는 검색 결과 맨 위에 붙는 요약 답변 영역이고, 그 아래에 근거로 쓰인 사이트가 몇 개 달립니다. 여기에 이름이 오르는 것이 답변 엔진 최적화의 가장 직접적인 성과입니다. 생김새가 비슷한 피처드 스니펫과는 다릅니다. 피처드 스니펫은 한 페이지의 문단을 그대로 오려 붙인 것이라 출처가 하나지만, AI 개요는 여러 페이지를 읽고 새로 쓴 문장이라 출처가 여럿이고 매번 조합이 달라집니다.

네 갈래는 순서대로 이어집니다. 수단으로 모델이 읽을 길을 트고, 기준에 맞춰 문서를 고쳐 쓰고, 결과 영역에서 인용됐는지를 확인하고, 그 확인을 다시 다음 문서에 반영합니다. 수단만 갖추고 문서는 예전 그대로 둔 팀은 모델이 읽어 가기는 하되 인용은 되지 않습니다. 반대로 문서만 고치고 확인을 건너뛴 팀은 어느 손질이 효과가 있었는지 모르는 채 다음 글도 감으로 씁니다.

"이 글 3위인데 유입이 반으로 줄었어요. AI 개요에 우리가 안 걸린 것 같은데 답변 엔진 최적화 관점에서 다시 볼까요?"

순위는 그대로인데 클릭이 줄었으니 원인이 순위 밖에 있다는 말이고, 검색어를 더 넣는 대신 문서를 인용되기 좋은 형태로 고쳐 쓰자는 제안입니다.

"결론을 맨 아래 두지 말고 첫 문단에 한 줄로 박아 주세요. 지금은 통째로 읽어야 답이 나와요."

글의 구성을 바꾸라는 요청입니다. 문단 하나만 떼어도 답이 되도록 만들어 달라는 뜻입니다.

"llms.txt 부터 올리고 두 주 뒤에 인용되는지 보죠."

모델이 읽어 갈 통로부터 열어 두고, 효과는 바로 재지 말고 시간을 두고 확인하자는 말입니다. 손이 가장 적게 드는 일부터 하고 문서 고쳐 쓰기는 그다음으로 미루자는 순서 제안이기도 합니다.

페이지덱에서는 이 일이 현우와 지현 사이에서 오갑니다. 현우가 유입이 빠진 글 열 개를 뽑아 오면 지현이 그중 제품 설명에 해당하는 글을 골라 냅니다. 둘이 같이 하는 첫 작업은 글을 늘리는 것이 아니라 자르는 것입니다. 도입부에서 배경을 세 문단 늘어놓던 글은 첫 줄에 답을 놓고 배경을 뒤로 미룹니다. 한 글에 질문 다섯 개가 섞여 있던 글은 질문마다 소제목을 달아 나눕니다. "이 부분은 앞에서 설명한 대로" 같은 연결 표현은 그 자리에서 내용을 다시 적어 주는 문장으로 바꿉니다. 문단 하나가 앞뒤 없이도 성립해야 발췌될 수 있기 때문입니다.

확인은 느립니다. 고친 글이 답변에 반영되기까지 보통 몇 주가 걸리고, 같은 질문을 두 번 물어도 답변이 조금씩 달라집니다. 그래서 현우는 하루 뒤에 검색해 보고 판단하지 않습니다. 주요 질문 스무 개를 정해 두고 2주에 한 번씩 물어본 뒤, 답변 아래 출처에 페이지덱이 몇 번 걸렸는지를 세어 기록합니다. 스무 번 가운데 세 번이던 것이 여섯 번이 되면 방향이 맞다고 보고, 두 달을 고쳐도 숫자가 그대로면 고친 내용이 아니라 고른 질문이 잘못됐는지부터 다시 봅니다.

검색 엔진 최적화를 접고 답변 엔진 최적화로 갈아타야 한다는 오해가 가장 흔합니다. 새 이름이 붙은 일이 나타나면 옛 일이 끝났다고 읽기 쉽고, 실제로 유입이 줄어드는 것을 눈으로 보고 나면 더 그렇습니다. 하지만 모델이 답을 만들 때 읽는 문서는 검색 엔진이 먼저 찾아 둔 문서입니다. 검색에서 아예 잡히지 않는 페이지는 답변에도 인용되지 않습니다. 둘을 맞바꾸려고 한 팀은 다른 사이트에서 걸어 준 링크를 늘리고 사이트 구조를 정리하던 일을 멈춘 채 문장만 고치다가, 반년 뒤 순위와 인용을 함께 잃습니다. 순위가 밀리면서 모델이 읽어 가는 후보 목록에서도 빠지기 때문입니다.

글을 짧게 쓰는 일이라는 오해도 자주 봅니다. 모델이 요약해 가니 짧은 글이 유리하다는 생각이 자연스럽게 따라옵니다. 실제로 걸리는 것은 길이가 아니라 구조입니다. 긴 글이라도 질문마다 소제목이 달리고 각 문단이 독립해서 읽히면 발췌하기 좋고, 짧은 글이라도 앞 문단을 읽어야 뜻이 통하면 떼어 낼 자리가 없습니다. 길이만 줄인 팀은 근거와 수치를 먼저 덜어 내는데, 그러면 콘텐츠 마케팅으로 쌓아 둔 신뢰까지 같이 얇아집니다. 남는 것은 인용도 안 되고 읽을 것도 없는 글입니다. 고쳐야 할 것은 분량이 아니라 순서입니다. 답을 먼저 놓고 근거를 뒤에 붙이면 글은 그대로 길어도 첫 문단만으로 답이 성립합니다.