하네스는 GEO에 어떻게 영향을 줄까?

GEO를 이해하려면, 먼저 AI 답변이 만들어지는 방식을 봐야 합니다

GEO는 사람들이 AI에게 비교와 추천을 물을 때, 브랜드의 공개 정보가 발견되고 이해되기 쉬운 조건을 만드는 작업입니다. 이 글에서는 그 조건을 바꾸는 중요한 요소인 하네스를 살펴봅니다.

이 글에서 말하는 AI 모델, 즉 LLM은 사람의 언어를 이해하고 다음 말을 이어 쓰도록 학습한 모델입니다. LLM은 완성된 정답을 꺼내 오는 대신, 지금까지 주어진 문장과 자료를 바탕으로 다음에 이어질 말의 가능성을 계산합니다. 이 글에서 말하는 문맥은 질문 한 줄, 앞선 대화, 검색 결과처럼 모델이 답을 만들 때 함께 보는 정보입니다.

사람도 비슷한 경험을 합니다. 평소에는 AI가 만든 영상이나 대본을 별 의심 없이 보다가도 누군가 먼저 “이 영상, AI로 만든 것 아닐까?”라고 말하면 갑자기 어색한 손동작, 일정한 문장 리듬, 과하게 매끄러운 장면 전환이 눈에 들어옵니다. 영상이 바뀐 것이 아니라 영상을 해석하는 문맥이 바뀐 것입니다.

AI에게 “이 계약에서 법적 분쟁 가능성도 검토해 줘”라는 문장이 한 번 들어가면 이후 답변에서 책임, 의무, 위험, 예외가 더 앞에 놓일 수 있습니다. 모델이 사람처럼 법률 생각에 사로잡혔다고 말할 수는 없지만, 답변을 보면 그 관점으로 매몰된 것처럼 보입니다. 법률이라는 단어가 뒤에 올 표현이 선택될 가능성을 바꾸었기 때문입니다.

AI에게 들어간 문장 하나하나는 단순한 정보가 아닙니다. 다음 답변이 어느 방향으로 전개될지 기울이는 조건입니다.

우리의 질문보다 먼저, 하네스가 답변에 영향을 줍니다

AI 제품을 만드는 개발자들 사이에서는 하네스라는 말이 자주 쓰입니다. 하네스가 뭘까요? 이 글에서 하네스는 AI 모델을 실제 제품 안에서 일하게 만드는 실행 환경을 뜻합니다. 모델을 호출하는 것만으로는 서비스가 되지 않습니다. 모델이 따를 규칙, 참고할 자료, 사용할 도구와 결과를 보여 줄 화면을 갖춰야 합니다.

모델이 답을 만드는 두뇌라면, 하네스는 그 두뇌가 어떤 자료를 보고 어떤 도구를 쓰며 어떤 방식으로 결과를 내보낼지 정하는 운영 장치입니다. 어떤 지침을 먼저 넣을지, 이전 대화와 사용자가 남긴 기억 정보를 얼마나 가져올지, 검색·지도·상품·파일 같은 도구를 언제 열지, 도구가 찾은 자료 중 무엇을 다시 모델에 전달할지, 결과를 텍스트·카드·지도 중 어떤 형태로 보여 줄지를 관리합니다.

그래서 사용자가 입력한 문장만 모델이 함께 보는 정보가 되는 것은 아닙니다. 하네스가 더한 지침, 도구와 자료도 모델이 다음 답변을 고르는 조건이 됩니다.

OpenAI의 AI 에이전트 개발 안내는 모델이 보는 정보가 지침, 입력, 도구, 검색과 검색 결과로 구성된다고 설명합니다. Anthropic의 안내도 서비스가 답을 만들 때 시스템 안내, 도구, 외부 자료와 대화 이력을 골라 함께 전달해야 한다고 설명합니다.

그래서 같은 모델 이름이 표시돼도 답변이 같다고 볼 수 없습니다. 어떤 도구가 열렸는지, 어떤 검색 결과가 돌아왔는지, 사용자의 앞선 대화가 얼마나 남았는지에 따라 모델 앞의 무대가 달라집니다. 모델이 배우라면 하네스는 대본, 무대 장치, 참고 자료와 진행 규칙을 매번 조립하는 제작 시스템에 가깝습니다.

개발용 API와 실제 사용자의 웹은 같은 환경이 아닙니다

개발자가 자신의 서비스에 AI 기능을 붙일 때 쓰는 방식을 API(Application Programming Interface)라고 합니다. API를 쓰면 개발자는 어떤 모델에 어떤 질문과 안내를 보낼지, 검색·파일 같은 도구를 붙일지, 결과를 글이나 다른 프로그램이 읽을 수 있는 정리된 데이터 중 어떤 형태로 받을지를 직접 정합니다. API는 완성된 AI 서비스 화면이라기보다 여러 제품을 만들 때 사용하는 개발 도구에 가깝습니다.

여기서 흔한 오해가 생깁니다. API는 순수한 모델이고 실제 웹 화면에만 하네스가 붙는다고 생각하기 쉽습니다. 실제로는 API에도 서비스의 기본 처리 과정이 있고, 호출자가 안내·도구·결과 형식을 추가할 수 있습니다. 차이는 하네스의 유무보다 누가 실행 환경을 구성하고, 관측자가 그 조건을 얼마나 통제하고 기록할 수 있느냐에 있습니다.

OpenAI API 문서와 Gemini API 도구 문서처럼 API에서도 웹 검색, 파일 검색, 지도, 코드 실행이나 개발자가 만든 기능을 붙일 수 있습니다. 다만 API 실험에서는 보통 호출자가 모델, 질문, 안내, 도구와 결과 형식을 정합니다. 반면 사람들이 실제로 쓰는 웹·앱 화면은 제품이 검색, 대화 기억, 위치, 쇼핑, 파일, 후속 질문과 화면 구성까지 더 넓은 하네스를 운영합니다. 이 글에서는 이런 실제 웹·앱 화면을 클라이언트라고 부르겠습니다.

API 실험의 최종 응답 자체는 실제 사용자의 웹·앱 화면을 대신할 수 없습니다. 실제 고객이 ChatGPT, Gemini 같은 화면에서 브랜드를 어떻게 만나는지 알고 싶은데 API 응답만 측정한다면, 서로 다른 하네스를 같은 환경으로 취급하는 셈입니다. 다만 답변 중간에 인용된 공개 웹 페이지와 출처는 실제 웹·앱 화면이 참조한 자료와 거의 비슷하게 나타나는 경우가 있어, 어떤 정보가 선택되어 답변에 쓰였는지 살피는 데 유용한 단서가 됩니다. API는 답변을 대신 측정하는 도구가 아니라, 공개된 인용과 정보 선택을 읽어 내는 보조 기준으로 다뤄야 합니다.

카드와 지도 결과는 텍스트만 가져와서는 재현되지 않습니다

이 차이는 답변이 긴 문장일 때보다 지도와 상품을 보여 줄 때 더 선명해집니다. Google은 AI Mode 기능 소개에서 장소의 평점·리뷰·영업시간과 상품의 가격·이미지·배송·재고를 시각 카드로 보여 준다고 설명합니다. ChatGPT 쇼핑 안내도 질문과 대화 맥락에 맞춰 이미지, 상품 정보와 구매 링크가 포함된 선택지를 표시할 수 있다고 밝힙니다.

지도도 지도 자체로 끝나지 않습니다. 지도 안에는 여러 장소 카드가 있고, 사용자가 항목을 누르면 세부 정보, 다른 선택지, 출처와 다음 행동이 그때 화면에 더 나타날 수 있습니다. 처음 보이는 텍스트만으로는 사용자가 실제로 무엇을 비교하고 어디로 이동할 수 있었는지 알기 어렵습니다. 하네스는 질문에 맞는 도구와 자료를 고르고, 클라이언트는 그 결과를 카드·지도·비교 화면으로 보여 줍니다. 모델이 화면 코드를 즉석에서 작성한다는 뜻은 아니지만, 무엇을 어떤 구성으로 보여 줄지는 답변 생성 과정과 분리할 수 없습니다.

웹 화면의 텍스트를 자동으로 가져오는 방식을 스크래핑이라고 합니다. 스크래핑은 보조 수집 방식이 될 수 있지만, 처음 화면의 문장만 가져오면 지도 안의 카드, 카드를 누른 뒤 나타나는 공개 정보, 출처와 다음 행동을 놓칠 수 있습니다. 동적인 선택 구조를 평평한 글자로 바꾸면 실제 사용자 경험이 사라집니다.

GEO 업체를 고를 때는 “웹 화면을 자동 수집한다”⁠는 설명에서 한 단계 더 확인할 필요가 있습니다.

• 지도와 카드를 함께 다루는지: 지도에 함께 표시된 항목, 출처와 클릭 뒤 공개되는 정보까지 분석 대상에 포함하는지 봅니다.
• 질문·서비스·시점을 함께 기록하는지: 같은 결과가 어떤 조건에서 나타났는지 비교할 수 있어야 합니다.
• 텍스트 수집과 화면 분석을 구분하는지: 단순 언급 수집을 실제 선택·비교 경험 분석처럼 포장하지 않아야 합니다.

모든 내부 방법을 공개하라는 뜻은 아닙니다. 고객은 공개된 결과를 바탕으로 카드·지도·출처·확장 정보까지 분석 대상에 포함하는지만 확인하면 됩니다.

여러 답변을 모아 결과를 측정해야 합니다

확률적으로 답을 만드는 모델을 분석할 때 한 번의 실행만 보는 것은, 동전을 한 번 던지고 앞면이 잘 나온다고 결론 내리는 것과 비슷합니다. 같은 질문을 해도 표현, 브랜드를 언급하는 순서, 선택한 출처가 달라질 수 있습니다. 모델 버전, 하네스, 검색 결과와 사용자 맥락까지 바뀌면 달라지는 이유는 더 많아집니다.

여러 번 답변을 확인하는 일은 좋은 화면을 많이 모으기 위한 것이 아닙니다. 같은 질문에서 브랜드가 얼마나 자주 언급되는지, 어떤 설명과 출처가 반복되는지, 어느 조건에서 답변이 달라지는지를 보기 위해서입니다. 답변을 충분히 모아 보면 우연히 나온 한 번의 답변에 덜 흔들리고, 대체로 어떤 결과가 나오는지와 얼마나 달라지는지를 더 분명하게 알 수 있습니다.

답변 횟수만 늘린다고 저절로 정확한 판단이 되는 것은 아닙니다. 서로 다른 조건에서 나온 답변을 한데 섞어 평균을 내면 오히려 변화가 가려집니다. 개발용 API로 확인한 기준과 실제 웹·앱 화면에서 본 결과를 나누고, 같은 서비스와 같은 시점의 답변끼리 비교해야 여러 번 확인하는 일이 의미를 가집니다.

하네스와 모델은 계속 바뀝니다

AI 제품의 하네스는 고정된 배관이 아닙니다. 모델 버전, 서비스가 먼저 넣는 안내, 검색 대상, 도구 선택, 대화 기억과 대화 내용을 요약해 가져오는 방식, 출처 표시 방식, 카드 화면이 계속 업데이트됩니다. 같은 질문을 입력해도 지난달과 이번 달, 한 서비스와 다른 서비스에서 모델이 함께 보는 정보가 달라질 수 있습니다.

Anthropic의 하네스 설명도 모델 능력이 변하면 하네스가 가진 가정이 낡을 수 있고, 이전 대화 중 무엇을 골라 모델에게 전달할지 정하는 방식 역시 조정된다고 설명합니다. 모델 자체의 성능 개선만 추적해서는 실제 제품 답변의 변화를 전부 설명할 수 없는 이유입니다.

모델마다 기본 경향도 다릅니다. 같은 자료를 보고도 비교 기준을 먼저 정리하는 모델, 출처를 더 적극적으로 찾는 모델, 안전 조건과 예외를 길게 설명하는 모델이 있을 수 있습니다. 여기에 서로 다른 하네스가 더해지므로 GEO는 한 모델의 한 시점에서 끝낼 수 없습니다.

GEO는 매번 달라지는 전광판을 운영하는 일입니다

예전의 검색 결과가 비교적 고정된 간판의 목록이었다면, AI 답변은 질문과 사용자 맥락에 따라 내용과 배치가 달라지는 동적인 전광판에 가깝습니다. 어떤 날에는 설명 문장 속에 브랜드가 등장하고, 다른 날에는 출처 링크나 상품 카드로 보이며, 조건이 맞지 않으면 나오지 않을 수도 있습니다.

GEO는 이 전광판을 직접 조종하는 기술이 아닙니다. 사용자가 실제로 묻는 질문에 답하는 공식 정보를 공개하고, 검증 가능한 외부 근거를 함께 제시하고, AI 제품의 실제 웹·앱 화면에서 그 정보가 어떻게 발견되고 설명되는지 반복해서 확인하는 운영입니다. 브랜드가 바꿀 수 있는 것은 비공개 서비스 안내나 모델 내부의 값이 아니라, 하네스가 찾고 이해할 공개 정보의 정확성, 설명 방식과 갱신 상태입니다.

1. 실제 질문을 정합니다. 브랜드명 검색이 아니라 고객이 발견·비교·선택할 때 묻는 질문을 고릅니다.
2. 기준을 나누어 봅니다. 개발용 API에서는 조건을 맞춘 결과를 보고, 실제 웹·앱 화면에서는 제품 하네스가 만든 사용자 경험을 봅니다.
3. 여러 번 관측합니다. 같은 조건의 답변을 모아 대체로 어떤 결과가 나오는지와 얼마나 달라지는지를 함께 기록합니다.
4. 공개 근거를 보강합니다. 고객이 확인한 공식 사실, 적용 조건, 예외와 독립 출처를 질문 가까이에 둡니다.
5. 다시 확인합니다. 모델과 하네스 업데이트 뒤에도 설명·출처·카드 노출이 어떻게 달라지는지 이어서 봅니다.

GEO의 핵심은 AI 답변을 한 번 얻어내는 데 있지 않습니다. 계속 달라지는 답변 환경에서 우리 브랜드가 발견될 정보 조건을 만들고, 실제 사용자 화면의 변화를 꾸준히 측정하는 데 있습니다.

사람들이 검색창 대신 AI에게 비교와 추천을 묻기 시작했기 때문에 이 운영이 필요합니다. 한 번의 좋은 답변을 성과로 포장하기보다, 어떤 질문과 하네스에서 어떤 자료가 사용됐는지 확인하고 평균적인 경향이 좋아지는지 봐야 합니다.