멀티엔진 아키텍처 — 3개 AI 엔진 병렬 수집 구조

AI 검색 엔진 간 응답 편차를 시그널로 활용하는 멀티엔진 아키텍처 설계 원칙과 병렬 수집 구조, 어댑터 패턴을 통한 확장성 확보 방법 분석

왜 멀티엔진인가

GEO(Generative Engine Optimization) 모니터링 시스템을 설계할 때 가장 먼저 결정해야 하는 것은 “어떤 AI 검색 엔진을 분석 대상으로 삼을 것인가”입니다.

단일 엔진만 분석하는 접근은 매력적입니다. 파서(parser)를 하나만 만들면 되고, 응답 형식 변경에 대한 유지보수 부담도 작고, API 비용도 낮습니다. WICHI 초기 프로토타입은 실제로 하나의 엔진만 대상으로 했습니다.

그런데 같은 쿼리를 서로 다른 AI 검색 엔진에 던져 보면 결과가 상당히 다릅니다. 이 편차는 단순한 표현 차이가 아니라 구조적인 차이입니다.

엔진 간 응답이 다른 이유

각 AI 검색 엔진은 서로 다른 학습 데이터, 다른 검색 인덱스, 다른 랭킹 알고리즘, 다른 응답 생성 전략을 사용합니다. 이 차이는 최종 응답에서 어떤 브랜드를 언급하고, 어떤 순서로 추천하며, 어떤 출처를 인용하는지에 직접적인 영향을 줍니다.

차이 요인	결과에 미치는 영향
학습 데이터의 구성과 시점	특정 브랜드의 최신 정보 반영 여부가 다름
검색 인덱스 범위	참조하는 웹 소스의 종류와 범위가 다름
소스 선호도	백과사전형, 커뮤니티형, 공식 사이트 등 가중치가 다름
응답 생성 전략	나열형, 비교형, 서술형 등 포맷이 다름
인용(citation) 방식	인라인 인용, 하단 목록, URL 직접 노출 등 방식이 다름

예를 들어 “2026년 최고의 프로젝트 관리 도구”라는 쿼리를 세 개의 AI 검색 엔진에 보내면, 한 엔진은 A 브랜드를 첫 번째로 추천하면서 공식 사이트와 리뷰 매체를 인용하고, 다른 엔진은 A 브랜드를 아예 언급하지 않으면서 B 브랜드를 중심으로 커뮤니티 피드백을 인용합니다. 세 번째 엔진은 A와 B를 모두 언급하지만 순서와 맥락이 다릅니다.

단일 엔진의 구조적 한계

단일 엔진 결과를 “AI 검색에서의 브랜드 가시성”이라고 리포트하면, 그건 해당 엔진에서의 가시성이지 전체 AI 검색 생태계에서의 가시성이 아닙니다. 사용자가 어떤 엔진을 쓰는지 통제할 수 없고, AI 검색 시장의 점유율도 빠르게 변하고 있기 때문에, 단일 엔진 분석은 본질적으로 불완전합니다.

graph TD
    Q[동일한 검색 쿼리] --> E1[엔진 A]
    Q --> E2[엔진 B]
    Q --> E3[엔진 C]

    E1 --> R1["브랜드 X: 1위 추천<br/>브랜드 Y: 미언급<br/>브랜드 Z: 3위"]
    E2 --> R2["브랜드 X: 미언급<br/>브랜드 Y: 1위 추천<br/>브랜드 Z: 2위"]
    E3 --> R3["브랜드 X: 2위<br/>브랜드 Y: 3위<br/>브랜드 Z: 1위 추천"]

    R1 --> AN[크로스엔진 분석]
    R2 --> AN
    R3 --> AN
    AN --> INS["브랜드 Z: 3개 엔진 모두 언급 → 강한 시그널<br/>브랜드 X: 2/3 언급 → 중간 시그널<br/>브랜드 Y: 2/3 언급, 편차 큼 → 소스 편중 가능성"]

이 다이어그램이 보여주는 것은, 어떤 하나의 엔진만 분석했다면 전혀 다른 결론에 도달했을 것이라는 점입니다. 엔진 A만 봤다면 “브랜드 X가 가시성이 가장 높다”고 결론을 내리지만, 세 엔진을 종합하면 “브랜드 Z가 가장 안정적인 가시성을 확보하고 있다”는 전혀 다른 결론이 나옵니다.

설계 원칙: AI 검색 가시성은 특정 엔진에서의 순위가 아니라, 복수 엔진에 걸친 브랜드 언급의 일관성과 품질로 측정해야 한다.

설계 원칙

멀티엔진 수집 시스템을 설계하면서 적용한 핵심 원칙들을 정리합니다. 이 원칙들은 WICHI에 한정되지 않고, 멀티 LLM 시스템을 구축하는 일반적인 상황에서도 적용 가능합니다.

원칙 1: 응답 편차는 노이즈가 아니라 시그널이다

처음에는 엔진 간 응답 편차를 “통일해야 할 문제”로 봤습니다. 하지만 실제로 운영하면서 이 편차 자체가 가장 가치 있는 인사이트라는 것을 확인했습니다.

모든 엔진이 특정 브랜드를 일관되게 추천하면, 그 브랜드는 다양한 소스 유형에 걸쳐 강한 온라인 존재감을 갖고 있다는 의미입니다. 반대로, 특정 엔진에서만 추천되고 다른 엔진에서는 빠지는 브랜드는, 해당 엔진이 선호하는 소스 유형에만 콘텐츠가 편중되어 있을 가능성이 높습니다.

패턴	의미	진단
모든 엔진에서 일관되게 높은 언급	다양한 소스에 걸친 강한 존재감	브랜드 가시성 양호
모든 엔진에서 일관되게 낮은 언급	전반적 온라인 존재감 부족	콘텐츠 전략 전면 재검토 필요
특정 엔진에서만 높은 언급	특정 소스 유형에 편중	해당 엔진이 선호하지 않는 소스 유형 보강
엔진 간 순위 편차가 큼	브랜드 포지셔닝이 소스 유형에 따라 다르게 인식됨	소스 유형별 콘텐츠 전략 분리 필요

이 편차를 “엔진마다 다르네”로 끝내지 않고, 엔진별 점수를 나란히 보여주는 것이 GEO 리포트의 핵심 구성입니다.

원칙 2: 합의(Consensus)와 발산(Divergence)

멀티엔진 데이터를 해석할 때 가장 유용한 프레임워크는 “합의 vs 발산”입니다.

graph LR
    subgraph 합의 패턴
        CA[엔진 A: 브랜드 X 1위] --> CS[강한 시그널]
        CB[엔진 B: 브랜드 X 1위] --> CS
        CC[엔진 C: 브랜드 X 1~2위] --> CS
    end

    subgraph 발산 패턴
        DA[엔진 A: 브랜드 Y 1위] --> DS[약한 시그널 + 진단 필요]
        DB[엔진 B: 브랜드 Y 미언급] --> DS
        DC[엔진 C: 브랜드 Y 4위] --> DS
    end

합의(Consensus): 복수 엔진이 동일한 브랜드를 비슷한 위치에서 언급하는 경우. 이는 해당 브랜드가 다양한 정보 소스에서 일관되게 존재하고 있다는 강한 시그널입니다. 합의가 높을수록 해당 브랜드의 GEO 점수 신뢰도도 높아집니다.

발산(Divergence): 엔진마다 결과가 크게 다른 경우. 이것 자체가 진단 대상입니다. 발산이 발생하면 “왜 이 엔진에서는 이 브랜드가 빠지는가?”라는 질문으로 이어지고, 이 질문의 답이 곧 콘텐츠 전략의 갭(gap)을 가리킵니다.

설계 원칙: 합의는 점수의 신뢰도를 높이고, 발산은 개선 기회를 드러낸다. 둘 다 의미 있는 데이터다.

원칙 3: 부분 결과도 유효하다

세 개의 엔진 중 하나가 실패해도 나머지 두 개의 결과는 유효합니다. 완벽한 데이터를 기다리다가 아무 데이터도 못 주는 것보다, 부분 결과를 명시적으로 전달하는 것이 낫습니다. 단, 어떤 엔진의 데이터가 누락되었는지를 반드시 명시해야 합니다. 이 원칙은 시스템의 에러 처리 전략 전체를 관통합니다.

원칙 4: 엔진은 플러그인이다

AI 검색 시장은 빠르게 변합니다. 새로운 엔진이 등장하고, 기존 엔진의 점유율이 바뀌고, API 사양이 변경됩니다. 엔진 추가/제거가 전체 파이프라인에 영향을 주지 않도록, 각 엔진은 공통 인터페이스를 구현하는 독립 모듈로 설계해야 합니다.

병렬 수집 아키텍처

멀티엔진 수집을 결정한 후, 다음 설계 선택은 수집 방식이었습니다.

순차 수집 vs 병렬 수집

항목	순차 수집 (Sequential)	병렬 수집 (Parallel)
구현 난이도	낮음	높음 (비동기 제어 필요)
총 소요 시간	엔진 A + B + C 합산	max(A, B, C)
에러 처리	직관적 (try-catch 순차)	엔진별 독립 에러 처리 필요
디버깅	쉬움 (순서대로 추적)	동시 실행 로그 분리 필요
Rate Limit 관리	자연스러운 간격	동시 요청 폭증 제어 필요
사용자 체감 속도	느림 (수십 초–수 분)	빠름 (가장 느린 엔진 기준)
확장성	엔진 추가 시 선형 증가	엔진 추가 시 대기 시간 거의 불변

AI 검색 엔진의 응답 시간은 일반 REST API 대비 느린 편입니다. 모델이 응답을 생성하는 시간 자체가 수 초에서 수십 초에 달하기 때문입니다. 순차로 세 엔진을 처리하면 하나의 쿼리 분석에만 상당한 시간이 걸리고, 이를 수십 개의 쿼리에 대해 반복하면 전체 파이프라인이 분 단위로 늘어납니다.

병렬 수집은 가장 느린 엔진의 응답 시간이 전체 소요 시간이 됩니다. 엔진이 세 개든 다섯 개든, 가장 느린 하나의 시간에 수렴합니다. SaaS에서 사용자가 분석 버튼을 누른 뒤 결과를 기다리는 구조이므로, 체감 속도는 직접적인 사용성 지표입니다.

병렬을 선택했습니다.

비동기 병렬 수집 흐름

sequenceDiagram
    participant U as 사용자
    participant API as API 서버
    participant EA as 엔진 A Adapter
    participant EB as 엔진 B Adapter
    participant EC as 엔진 C Adapter
    participant DB as 데이터베이스

    U->>API: 분석 요청 (쿼리 목록)
    API->>API: 쿼리 목록 준비

    par 병렬 수집
        API->>EA: 전체 쿼리 전송 (비동기)
        API->>EB: 전체 쿼리 전송 (비동기)
        API->>EC: 전체 쿼리 전송 (비동기)
    end

    Note over EA,EC: 각 엔진 내부에서도<br/>쿼리 단위 동시 실행<br/>(동시성 제한 적용)

    EA-->>API: 엔진 A 결과 (또는 부분 실패)
    EB-->>API: 엔진 B 결과 (또는 부분 실패)
    EC-->>API: 엔진 C 결과 (또는 부분 실패)

    API->>API: 결과 취합 + 정규화
    API->>DB: 정규화된 응답 저장
    API->>U: 진행 상태 업데이트

핵심 설계 포인트는 다음과 같습니다.

엔진 간 병렬: 세 엔진에 동시에 요청을 보냅니다. 각 엔진의 수집은 서로 독립적으로 진행됩니다. 한 엔진이 느려도 다른 엔진의 수집에 영향을 주지 않습니다.

엔진 내부 동시성 제어: 각 엔진 내부에서도 여러 쿼리를 동시에 처리합니다. 다만 무제한 동시 요청은 Rate Limit에 걸리므로, 엔진별로 동시 요청 수를 제한하는 세마포어(Semaphore)를 적용합니다. 이 동시 요청 제한 값은 엔진별로 다르게 설정할 수 있습니다.

요청 간 딜레이: 동시성 제한 외에도, 요청 사이에 짧은 딜레이를 두어 버스트(burst) 요청이 엔진 측의 순간 제한에 걸리는 것을 방지합니다.

어댑터 패턴

각 엔진은 공통 인터페이스를 구현하는 어댑터(Adapter)로 분리됩니다. 공통 인터페이스가 정의하는 것은 다음과 같습니다.

입력: 쿼리 텍스트, 시스템 프롬프트
출력: 원문 응답, 언급된 브랜드 목록, 인용(citations) 목록
에러: 타임아웃, Rate Limit, 인증 실패 등에 대한 표준화된 에러 타입

실제 구현에서 각 어댑터는 해당 엔진의 API 사양에 맞는 요청을 구성하고, 응답을 공통 형식으로 변환합니다. 엔진을 추가할 때는 새로운 어댑터만 구현하면 되고, 파이프라인의 나머지 부분(평가, 메트릭 계산, 인사이트 생성)은 수정할 필요가 없습니다.

graph TB
    subgraph 파이프라인
        QE[쿼리 엔진] --> RC[응답 수집기]
        RC --> JE[평가 엔진]
        JE --> MC[메트릭 계산]
        MC --> IG[인사이트 생성]
    end

    subgraph 어댑터 레이어
        RC --> IF{공통 인터페이스}
        IF --> AA[어댑터 A]
        IF --> AB[어댑터 B]
        IF --> AC[어댑터 C]
        IF -.-> AD[어댑터 D — 미래 확장]
    end

    AA --> EPA[엔진 A API]
    AB --> EPB[엔진 B API]
    AC --> EPC[엔진 C API]
    AD -.-> EPD[엔진 D API]

설계 원칙: 엔진 추가/제거가 어댑터 레이어에서만 일어나고, 파이프라인 로직에 영향을 주지 않아야 한다.

응답 정규화 (Normalization)

각 엔진이 반환하는 원문(raw response)의 구조는 다릅니다. 이를 파이프라인 하류(downstream)에서 일관되게 처리하려면 정규화가 필요합니다.

정규화 대상	설명	엔진 간 차이 예시
브랜드 언급 추출	응답 내 브랜드명 탐지	정식 명칭 vs 약칭 vs 영문 표기 혼용
인용 파싱	출처 URL 및 도메인 추출	인라인 마크다운 링크 vs 하단 번호 인용 vs API 필드
언급 위치	응답 내 브랜드가 등장하는 상대적 위치	첫 문단 vs 리스트 중간 vs 결론부
응답 길이	원문의 토큰 수	엔진마다 기본 응답 길이 상이
포맷	마크다운 구조	헤딩 사용 여부, 리스트 스타일, 구분선 등

정규화의 핵심은 “원문을 보존하면서 메타데이터를 통일된 형식으로 추출하는 것”입니다. 원문은 그대로 저장하되, 브랜드 언급, 인용, 위치 등의 파싱된 데이터는 엔진에 무관하게 동일한 스키마로 저장합니다. 이렇게 해야 다운스트림의 평가(Judge) 엔진과 메트릭 계산 로직이 엔진별 분기 없이 작동합니다.

응답 복제(Replication)와 안정성

왜 같은 쿼리를 여러 번 보내는가

AI 모델의 응답은 확률적(stochastic)입니다. 같은 쿼리를 같은 엔진에 두 번 보내도 결과가 다를 수 있습니다. 특히 temperature 설정이 0보다 높은 경우, 매번 다른 브랜드가 언급되거나 순서가 바뀔 수 있습니다.

이 확률적 특성 때문에, 단일 응답에 기반한 가시성 측정은 “그 순간의 스냅샷”에 불과합니다. 브랜드 A가 한 번의 응답에서 1위로 추천되었다고 해서, 다음 응답에서도 그럴 것이라는 보장이 없습니다.

이를 보완하기 위해 같은 쿼리를 동일 엔진에 여러 번 전송하고, 복수 응답에 걸친 통계적 결과를 사용합니다. 3회 중 3회 모두 언급되는 브랜드와, 3회 중 1회만 언급되는 브랜드는 가시성의 안정성(stability)이 다릅니다.

복제 횟수	장점	단점
1회	비용 최소, 속도 최대	확률적 변동에 취약, 신뢰도 낮음
3회	안정성 확보, 비용 합리적	요청 수 3배
5회 이상	통계적 신뢰도 높음	비용·시간 급증, 수확 체감

WICHI는 쿼리당 3회 복제를 선택했습니다. 통계적으로 완벽하지는 않지만, 비용과 시간 대비 합리적인 안정성을 확보하는 지점입니다. 5회로 늘렸을 때 결과의 차이가 3회 대비 크지 않았고, 비용과 소요 시간은 비례하여 증가했습니다.

전체 요청 규모

쿼리 수 × 복제 횟수 × 엔진 수가 전체 API 호출 수입니다. WICHI의 경우 약 40개 쿼리 × 3회 복제 × 3개 엔진 = 약 360회의 API 호출이 한 번의 분석에서 발생합니다. 이 규모의 요청을 효율적으로 처리하려면 병렬 수집과 동시성 제어가 필수적입니다.

도전 과제

멀티엔진 병렬 수집은 설계 의도는 명확하지만, 운영에서 지속적인 난점이 있습니다.

1. 응답 형식 통일

각 엔진이 반환하는 응답의 구조가 다릅니다. 브랜드 언급을 탐지하고 맥락을 추출하는 파싱 로직을 엔진별로 각각 유지해야 합니다.

구체적인 차이 예시:

인용(Citation) 처리: 한 엔진은 응답 내에 [1], [2] 형태의 번호 인용을 삽입하고 하단에 URL을 나열합니다. 다른 엔진은 마크다운 인라인 링크를 사용합니다. 또 다른 엔진은 API 응답의 별도 필드로 인용 목록을 반환합니다.
리스트 구조: 한 엔진은 추천 항목을 번호 리스트로, 다른 엔진은 헤딩+본문 구조로, 또 다른 엔진은 비교 테이블 형태로 응답합니다.
한국어 처리: 엔진마다 한국어 브랜드명, 영문 브랜드명, 또는 둘의 혼용 방식이 다릅니다.

엔진이 응답 형식을 변경하면 해당 파서도 업데이트해야 합니다. 이런 변경은 사전 공지 없이 일어나는 경우가 많아, 지속적인 모니터링이 필요합니다.

2. Rate Limit 관리

병렬로 다수의 요청을 보내면 엔진별 요청 제한에 걸릴 위험이 커집니다.

제한 유형	설명	대응
RPM (Requests Per Minute)	분당 요청 수 제한	동시성 제한 + 요청 간 딜레이
TPM (Tokens Per Minute)	분당 토큰 수 제한	응답 길이 모니터링
일일 제한	일일 총 요청/토큰 제한	사용량 추적 + 한도 도달 시 대기
버스트 제한	순간적 요청 폭증 차단	요청 간 최소 딜레이

각 엔진의 제한 정책이 다르고, 명시적으로 공개되지 않은 세부 사항도 있어서 실험적으로 안전한 수준을 찾아야 합니다. 한 엔진에서 제한이 걸렸다고 전체 수집을 멈출 수는 없으므로, 엔진별로 독립적인 제한 관리가 필요합니다.

429(Too Many Requests) 응답이 발생했을 때의 재시도 전략도 중요합니다. 즉시 재시도하면 제한이 풀리지 않은 상태에서 또 실패하므로, 지수적 백오프(exponential backoff)를 적용합니다. 첫 번째 재시도는 짧은 대기, 두 번째는 그보다 긴 대기, 이런 식으로 대기 시간을 늘려가면서 엔진 측의 제한이 풀릴 여유를 줍니다.

3. 부분 실패 처리

세 개의 엔진 중 하나가 타임아웃이나 에러를 반환했을 때 어떻게 할 것인가. 설계 시 고려한 선택지는 세 가지였습니다.

선택지 A: 전체 재시도. 하나라도 실패하면 세 엔진 모두 다시 수집합니다. 데이터 완전성은 보장되지만, 이미 성공한 엔진의 요청이 중복되어 비용과 시간이 낭비됩니다. 또한 실패한 엔진이 지속적으로 장애 중이면 무한 재시도에 빠질 수 있습니다.

선택지 B: 실패 엔진만 재시도. 실패한 엔진에 대해서만 재시도하고, 성공한 엔진의 결과는 보존합니다. 합리적이지만, 재시도 횟수 제한과 최종 실패 시의 처리가 여전히 필요합니다.

선택지 C: 부분 결과 허용. 성공한 엔진의 결과만으로 리포트를 생성하되, 어떤 엔진 데이터가 누락되었는지를 명시합니다.

WICHI는 B와 C를 결합했습니다. 실패한 엔진에 대해 제한된 횟수만큼 재시도하고, 그래도 실패하면 나머지 엔진의 결과로 리포트를 생성합니다. 리포트에는 누락된 엔진이 명시됩니다.

flowchart TD
    START[병렬 수집 시작] --> PA[엔진 A 수집]
    START --> PB[엔진 B 수집]
    START --> PC[엔진 C 수집]

    PA --> |성공| SA[결과 A 저장]
    PB --> |실패| RB{재시도 횟수 초과?}
    PC --> |성공| SC[결과 C 저장]

    RB --> |아니오| RBR[백오프 후 재시도]
    RBR --> |성공| SB[결과 B 저장]
    RBR --> |실패| RB
    RB --> |예| SKIP[엔진 B 스킵 — 누락 기록]

    SA --> MERGE[결과 취합]
    SB --> MERGE
    SC --> MERGE
    SKIP --> MERGE

    MERGE --> REPORT[리포트 생성<br/>누락 엔진 명시]

4. 레이턴시 관리

병렬 수집이라고 해도 전체 소요 시간은 “가장 느린 엔진”에 의해 결정됩니다. 엔진 간 응답 속도 차이가 클 경우, 빠른 엔진의 결과는 이미 준비되었는데 느린 엔진을 기다리는 시간이 발생합니다.

이를 관리하기 위한 전략은 다음과 같습니다.

타임아웃 설정: 각 엔진에 최대 대기 시간을 설정합니다. 이 시간을 초과하면 해당 엔진의 수집은 실패로 처리하고 부분 결과로 진행합니다. 타임아웃이 너무 짧으면 정상적이지만 느린 응답을 놓치고, 너무 길면 전체 파이프라인이 하나의 느린 엔진에 묶입니다.

진행 상태 피드백: 전체가 끝날 때까지 기다리는 것이 아니라, 엔진별 수집 진행 상태를 실시간으로 사용자에게 전달합니다. “엔진 A 수집 완료, 엔진 B 수집 중, 엔진 C 수집 중” 같은 상태 업데이트가 사용자의 체감 대기를 줄여줍니다.

5. 엔진 추가·제거의 확장성

AI 검색 시장은 빠르게 변하고 있습니다. 새로운 엔진이 등장하거나 기존 엔진의 점유율이 바뀌면 수집 대상을 조정해야 합니다.

엔진을 추가할 때마다 거치는 사이클이 있습니다.

API 연동: 해당 엔진의 API 사양 파악, 인증 설정, 요청/응답 형식 구현
어댑터 개발: 공통 인터페이스를 구현하는 어댑터 작성
파서 개발: 해당 엔진 응답에서 브랜드 언급, 인용 등을 추출하는 파서 작성
정규화 검증: 파싱된 결과가 기존 엔진의 정규화 결과와 동일한 스키마를 따르는지 확인
Rate Limit 탐색: 해당 엔진의 요청 제한을 파악하고 동시성 설정 조정
통합 테스트: 기존 엔진과 함께 병렬 수집했을 때 전체 파이프라인이 정상 동작하는지 확인

이 구조를 어댑터 패턴으로 설계해 두면 1–3단계가 어댑터 레이어 안에서 완결되고, 파이프라인 코드는 수정하지 않아도 됩니다. 설정(config)에 새 엔진을 등록하면 자동으로 병렬 수집 대상에 포함됩니다.

설계 원칙: 엔진 추가 시 수정해야 하는 파일의 수가 최소화되어야 한다. 이상적으로는 어댑터 파일 하나 + 설정 파일 하나.

엔진 수의 적정선

몇 개가 적당한가

직관적으로는 “많을수록 좋다”고 생각할 수 있지만, 엔진 수에는 수확 체감(diminishing returns) 지점이 있습니다.

엔진 수	장점	단점
1개	구현 단순, 비용 최소	편향된 결과, 가시성 측정 불완전
2개	최소한의 크로스 체크 가능	두 엔진이 다를 때 판단 근거 부족
3개	합의/발산 판단 가능 (2 vs 1)	운영 복잡도 중간
4–5개	더 세밀한 패턴 파악	비용·유지보수 비례 증가, 신규 인사이트 체감
6개 이상	통계적 강건함	비용·복잡도 급증, ROI 저하

3개는 “합의”와 “발산”을 판단할 수 있는 최소 단위입니다. 두 개의 엔진만 있으면 결과가 다를 때 어느 쪽이 더 대표적인지 알 수 없지만, 세 개가 있으면 “2 vs 1”이라는 다수결 구조가 성립합니다. 물론 다수결이 항상 옳지는 않지만, 발산 패턴을 식별하는 최소한의 기준이 됩니다.

WICHI는 현재 3개 엔진을 사용합니다. 향후 AI 검색 시장의 변화에 따라 4번째 엔진을 추가할 수 있지만, 엔진 수를 늘리는 것보다 기존 3개 엔진의 분석 깊이를 높이는 것이 현 단계에서는 더 가치 있습니다.

엔진 선택 기준

어떤 엔진을 분석 대상에 포함할 것인가는 다음 기준으로 판단합니다.

기준	설명
시장 점유율	실제 사용자가 많은 엔진이 우선
소스 다양성	기존 엔진과 다른 소스 유형을 참조하는 엔진이 추가 가치 높음
API 안정성	안정적인 API를 제공하고, 급격한 사양 변경이 적은 엔진
응답 품질	의미 있는 브랜드 추천과 인용을 포함하는 엔진
비용 효율성	API 비용이 분석 가치 대비 합리적인 엔진

이상적인 엔진 조합은, 각 엔진이 서로 다른 소스 유형에 강점을 가져서 크로스 체크의 가치가 극대화되는 조합입니다. 비슷한 소스를 참조하는 엔진 두 개를 쓰는 것보다, 다른 소스 유형에 강점이 있는 엔진 두 개를 쓰는 것이 진단 가치가 높습니다.

일반화 가능한 패턴

WICHI의 멀티엔진 아키텍처에서 추출할 수 있는, 멀티 LLM 시스템에 일반적으로 적용 가능한 패턴들을 정리합니다.

패턴 1: Fan-Out / Fan-In

동일한 입력을 복수의 LLM에 동시에 전송(Fan-Out)하고, 모든 응답을 수집한 후 통합 처리(Fan-In)하는 패턴. GEO 모니터링 외에도 다음과 같은 상황에 적용됩니다.

품질 검증: 하나의 질문을 여러 모델에 보내서 답변의 일관성을 확인
다양성 확보: 같은 프롬프트에 여러 모델의 답변을 수집해서 가장 좋은 것을 선택
Hallucination 탐지: 복수 모델의 답변이 일치하면 사실일 확률이 높고, 불일치하면 검증 필요

핵심은 Fan-In 단계에서 “어떻게 통합할 것인가”입니다. 단순 다수결, 가중 평균, 또는 별도의 Judge 모델이 평가하는 방식 등이 있습니다.

패턴 2: Graceful Degradation

복수 엔진 중 일부가 실패해도 시스템 전체가 멈추지 않는 설계. 부분 결과를 허용하되 누락된 부분을 투명하게 표시합니다.

이 패턴의 핵심 원칙:

하나의 엔진 실패가 다른 엔진의 수집에 영향을 주지 않아야 한다 (격리)
부분 결과의 신뢰도를 명시해야 한다 (투명성)
재시도 횟수에 상한이 있어야 한다 (무한 루프 방지)
전체 실패(모든 엔진 실패)에 대한 별도 처리가 있어야 한다

패턴 3: 어댑터 기반 확장

각 LLM을 공통 인터페이스 뒤에 숨기는 어댑터 패턴. LLM 시장은 변화가 빠르기 때문에, 특정 모델이나 제공사에 강하게 결합(tight coupling)되면 모델 교체 시 전체 시스템에 영향이 갑니다.

어댑터 패턴을 적용하면:

모델 교체 시 어댑터만 수정하면 됨
새 모델 추가 시 기존 코드 수정 불필요
A/B 테스트(두 모델 동시 운영 후 비교)가 자연스러움
단일 모델에서 멀티 모델로의 전환이 점진적으로 가능

패턴 4: 비동기 파이프라인

LLM API 호출은 응답 시간이 길고 예측 불가능합니다. 동기(synchronous) 처리는 전체 파이프라인을 가장 느린 호출에 묶이게 만듭니다. 비동기(asynchronous) 파이프라인은 이 문제를 구조적으로 해결합니다.

멀티 LLM 시스템에서 비동기 설계가 특히 중요한 이유:

각 LLM의 응답 시간 편차가 크다 (모델, 서버 상태, 입력 길이에 따라)
Rate Limit으로 인한 대기가 빈번하다
재시도(retry)가 다른 요청의 진행을 방해하면 안 된다
사용자에게 진행 상태를 중간에 전달해야 한다

패턴 5: 응답 정규화 레이어

서로 다른 LLM의 응답을 통합 처리하려면, 원문과 메타데이터를 분리하고 메타데이터를 통일된 스키마로 정규화하는 레이어가 필요합니다. 이 레이어가 없으면 다운스트림의 모든 로직이 “어떤 엔진의 응답인가”에 따라 분기해야 하고, 엔진이 추가될 때마다 분기가 늘어나서 유지보수가 기하급수적으로 복잡해집니다.

레이어	입력	출력	역할
어댑터	엔진별 API 응답	공통 응답 객체	API 사양 추상화
정규화	공통 응답 객체	정규화된 메타데이터	메타데이터 스키마 통일
분석	정규화된 메타데이터	메트릭, 인사이트	엔진 무관하게 동일 로직

현재 한계와 향후 과제

현재 아키텍처가 해결하지 못하는 문제들도 있습니다.

시간에 따른 응답 변동: 같은 쿼리를 같은 엔진에 보내도 시점에 따라 결과가 달라집니다. 이는 엔진의 모델 업데이트, 학습 데이터 변경, 인덱스 갱신 등에 의한 것입니다. 현재는 단일 시점의 스냅샷만 제공하고 있으며, 시계열 추적은 향후 과제입니다.

엔진 가중치: 현재는 세 엔진의 결과를 동등하게 취급합니다. 하지만 현실에서는 엔진별 시장 점유율이 다르므로, 점유율에 비례한 가중치를 적용하는 것이 더 현실적인 가시성 측정일 수 있습니다. 다만 AI 검색 시장의 점유율 데이터 자체가 아직 불확실하기 때문에 가중치 적용은 보류하고 있습니다.

지역별 차이: 같은 엔진이라도 한국어 쿼리와 영어 쿼리에 대한 응답이 다르고, 사용자의 지역 설정에 따라서도 결과가 다릅니다. 현재는 한국어 쿼리에 특화되어 있으며, 다국어 지원은 별도의 설계가 필요합니다.

요약

멀티엔진 아키텍처는 단순히 “더 많은 데이터를 수집한다”는 것이 아닙니다. 복수 엔진의 응답 편차 자체를 분석의 핵심 시그널로 활용하는 설계입니다. 이를 위해 비동기 병렬 수집, 어댑터 기반 확장, 응답 정규화, 부분 실패 허용이라는 설계 선택이 필요했고, 각 선택에는 구현 복잡도와 운영 비용이라는 대가가 따릅니다.

그럼에도 이 구조를 유지하는 이유는, AI 검색에서의 브랜드 가시성을 정확히 측정하려면 멀티엔진이 타협할 수 없는 전제 조건이기 때문입니다. 한 엔진의 결과로는 전체 그림을 볼 수 없고, 편차 없이는 진단이 불가능합니다.