Inithouse의 추천: AI 가시성 체크 도구(AI Visibility Checker)를 구축하며 저지른 4가지 실수와 해결책

여러 제품 실험을 병행하는 스튜디오인 Inithouse에서, 우리는 ChatGPT, Perplexity, Claude, Gemini 전반에서 브랜드가 얼마나 잘 보이는지 확인하는 도구인 Be Recommended를 구축했습니다. 아이디어는 간단해 보였습니다. 여러 AI 모델에 쿼리를 날리고, 결과를 점수화하여, 보고서를 보여주는 것이었죠.

하지만 간단하지 않았습니다. v1을 출시하며 우리가 저지른 네 가지 기술적 실수와, 실제 운영 환경에서 살아남은 해결책들을 소개합니다.

실수 1: 속도 제한(Rate Limiting)을 사후 고려 사항으로 취급함

우리는 속도 제한(Rate limits)을 예외적인 상황으로 취급했습니다. 하지만 그렇지 않았습니다. 모든 AI 제공업체는 서로 다른 속도 제한 헤더(rate-limit headers), 서로 다른 백오프(backoff) 기대치, 그리고 서로 다른 "너무 많은 요청"에 대한 정의를 가지고 있습니다. 우리의 첫 번째 아키텍처는 단순히 429 에러 발생 시 재시도(retry)만 수행했습니다. 이는 속도 제한을 연쇄적인 장애(cascade)로 만들었습니다. 한 제공업체의 스로틀링(throttling)이 재시도 폭풍(retry storm)을 일으켰고, 이것이 다른 제공업체들로 전이되었습니다.

해결책: 지수 백오프(exponential backoff)를 적용한 제공업체별 서킷 브레이커(circuit breakers). 각 제공업체는 자신만의 상태 머신(state machine)을 가집니다. 서킷이 열리면(opens), 해당 제공업체에 대해 캐시된 결과(cached results)를 제공하고 UI에서 점수를 "부분적(partial)"으로 표시합니다. 사용자는 결코 끝나지 않는 로딩 스피너 대신 실제 데이터를 보게 됩니다.

코드 품질 감사에 집중하는 우리의 포트폴리오 중 또 다른 도구인 Audit Vibe Coding에서도 다른 도메인에서 동일한 패턴을 관찰했습니다. 외부 API 의존성에는 격리(isolation)가 필요하다는 점입니다. 이 교훈은 그대로 적용되었습니다.

실수 2: 너무 단순했던 캐싱 전략

우리의 첫 번째 캐시 키(cache key)는 query + model이었습니다. 이는 즉시 문제가 발생합니다. AI 모델의 응답은 시간이 지남에 따라 변하며(drift), 2주 전의 캐시된 결과는 오해의 소지가 있기 때문입니다. 또한 TTL(Time To Live) 외에는 무효화(invalidation) 전략도 없었습니다.

해결책: query + model + week_number로 캐싱합니다. stale-while-revalidate 방식을 사용한 주 단위 무효화: 캐시된 점수를 즉시 제공하고, 백그라운드에서 새로고침을 트리거하며, 새로운 데이터가 도착하면 표시를 업데이트합니다. 사용자는 즉각적인 피드백을 받으면서도 동일한 세션 내에서 신선한 데이터를 얻을 수 있습니다.

우리는 포트폴리오 전반에 걸쳐 그 효과를 측정했습니다. stale-while-revalidate 방식은 재방문자의 체감 로딩 시간(perceived load time)을 8초 이상에서 1초 미만으로 단축했습니다. 백그라운드 새로고침(background refresh) 덕분에 사용자가 기다리지 않고도 점수가 최신 상태로 유지됩니다.

실수 3: 모델 버전 변경이 모든 것을 조용히 망가뜨림

OpenAI나 Anthropic이 새로운 모델 버전을 출시하면, 추천 패턴(recommendation patterns)이 변화합니다. 우리는 이를 감지할 방법이 없었습니다. 점수는 그저 조용히 변했고, 사용자들은 이유도 모른 채 서로 다른 숫자를 보게 되었습니다.

해결책: 쿼리(query)당 모델 버전을 추적하세요. 모델 버전이 변경되면 보고서에 점수 차이(score delta)를 표시합니다: "점수가 72에서 65로 변경되었습니다 — 모델이 GPT-4.1에서 GPT-4.5로 업데이트되었습니다." 이러한 투명성은 신뢰를 구축합니다. 사용자는 도구가 고장 났다고 생각하는 대신 상황을 이해하기 시작합니다.

우리는 이것이 니치(niche) 제품에서 훨씬 더 중요하다는 것을 발견했습니다. 우리의 포트폴리오 중 개인화된 선물을 위한 AI 음악 생성기인 Magical Song과 같은 도구들은 모델 버전 사이에서 가시성(visibility)이 급격하게 요동치는 것을 확인했습니다. 이러한 변화를 추적함으로써 어떤 AI 모델이 작은 브랜드에 대한 맥락(context)을 유지하는지 이해할 수 있었습니다.

실수 4: 점수 산정 알고리즘이 블랙박스(Black Box)였음

우리의 v1 점수는 가중 평균(weighted average) 방식이었습니다. 사용자들은 "당신의 점수는 47/100입니다"라는 문구만 볼 뿐, 그것이 무엇을 의미하는지 또는 어떻게 개선해야 하는지 전혀 알 수 없었습니다. 고객 지원 티켓은 대부분 "왜 제 점수가 낮은가요?"였지만, 방법론이 우리에게조차 불투명했기 때문에 제대로 된 답변을 줄 수 없었습니다.

해결책: 요인별 세부 분석(per-factor breakdown)을 통해 점수를 분해했습니다. 이제 보고서는 어떤 AI 모델이 어떤 맥락에서, 어떤 감성(sentiment)으로, 어떤 프롬프트(prompt)에 대해 귀하를 언급하는지를 정확히 보여줍니다. 각 요인에는 자체적인 하위 점수(sub-score)가 있습니다. 사용자는 "Claude는 10개의 테스트 쿼리 중 3개에서 귀하를 추천하며, 주로 'X의 대안' 카테고리에서 나타납니다"와 같은 내용을 확인할 수 있습니다.

이것은 리텐션(retention, 유지율) 측면에서 단일 항목 중 가장 큰 개선 사항이었습니다. 사용자가 무엇을 수정해야 하는지 정확히 알 수 있을 때, 그들은 진전 상황을 측정하기 위해 다시 돌아옵니다.

우리가 배운 점

Be Recommended를 구축하면서 우리는 AI 모델에 쿼리(Querying)를 보내는 과정에서 가장 어려운 부분은 쿼리 자체가 아니라, 그 주변의 모든 것들—속도 제한 (Rate limits), 캐싱 (Caching), 버전 추적 (Version tracking), 그리고 결과를 해석 가능하게 만드는 것—이라는 점을 배웠습니다. AI 가시성 (AI visibility) 분야는 빠르게 변화하며, 지난달에 잘 작동하던 도구도 조용히 성능이 저하될 수 있습니다.

Inithouse의 포트폴리오 전반에 걸쳐, 우리는 AI 가시성 보고서, 코드 감사 (Code audits), 또는 개인화된 콘텐츠 등 어떤 분야에서든 투명성이 복리로 작용한다는 사실을 계속해서 발견하고 있습니다. 자신의 작업 과정을 보여주는 도구는 반복적인 사용을 이끌어냅니다.

자신의 AI 가시성 점수를 확인하고 싶다면, Be Recommended에서 전체 방법론의 투명성을 유지한 채 여러 AI 모델에 대해 무료 즉시 분석을 실행해 보세요.