오픈라우터를 사용해 보고 싶으신가요?

1. 이게 뭔가요?

오픈라우터(OpenRouter)는 사용자의 인공지능 호출 요청을 여러 외부 호스팅 제공업체로 분산 연결해 주는 중개 서비스입니다. 이 글은 아이메시지 기반 인공지능 비서 '올리(Olly)'를 운영하며 처리한 1,800만 건 이상의 대화 중 약 3분의 1을 오픈 모델로 처리한 개발자가 직접 경험한 기술적 장애와 운영 함정을 정리한 보고서입니다. 글쓴이는 이름과 설계 가중치가 완전히 동일한 인공지능 모델이라 하더라도, 이를 실제 구동하는 호스팅 업체의 서버 설정과 보조 프로그램에 따라 성능 지표, 오류 형태, 시각 처리 성공 여부가 극단적으로 갈린다는 실증 시험 결과를 상세히 공개했습니다.

2. 왜 화제인가요?

같은 인공지능 프로그램을 지정하면 어느 호스팅 업체의 서버 컴퓨터를 거치든 거의 동일한 결과물이 나올 것이라고 전제하기 쉽지만, 실제 상용 운영 환경에서는 심각한 편차가 나타나기 때문입니다. 전문 지식 측정 시험이나 외부 명령을 수행하는 도구 호출 시험에서 업체 간 점수 격차가 20점 이상 벌어지고, 통신 성공 신호만 보낸 채 정작 알맹이 답변을 비워두거나 이미지를 아예 읽지 못하는 치명적인 결함이 빈번히 관찰되었습니다. 따라서 인공지능 연동 서비스를 개발할 때는 겉으로 드러난 모델 명칭이나 단순 정밀도 규격만 믿지 말고, 업체별 실측 성적과 비정상 응답 처리 규칙을 자체 소프트웨어에 철저히 구축해야 합니다.

3. 핵심 내용

인공지능 모델은 대규모 학습을 통해 완성된 계산 수치들의 모음인 가중치를 가리킵니다. 제공업체는 이 가중치를 자사 그래픽 연산 장치(GPU)에 올리고, 계산 단위를 축소하는 정밀도 압축 기법과 전용 명령어 해석기를 조합해 통신망 창구로 서비스하는 회사들입니다. 오픈라우터에서 특정 모델을 요청하면 이용자는 20여 개에 달하는 낯선 호스팅 업체 중 한 곳으로 임의 연결되는데, 서류상으로는 동일한 모델일지라도 실제 운영 현장에서는 각 업체가 자체적으로 지닌 고유한 결함 탓에 완전히 별개의 모델처럼 동작합니다.

첫째, 동일한 모델 가중치라도 호스팅 업체에 따라 벤치마크 점수가 크게 요동칩니다. 2026년 9월 7일 기준 딥시크 V4 플래시 0731 모델의 32일 이동 평균 지표에서, 원개발사인 딥시크의 자체 서버는 전문 지식 평가인 GPQA 다이아몬드에서 90.2%, 외부 도구 실행 성능을 측정하는 TAU-벤치 항공 시험에서 81.3%를 기록했습니다. 반면 완전히 동일한 가중치를 서비스하는 디지털오션은 지식 시험 75.3%, 도구 실행 시험 58.4%에 머물러 무려 20점 이상의 격차를 보였습니다. 대부분의 호스팅 업체는 도구 호출에서 원개발사 대비 5점에서 7점 낮은 수준에 몰려 있었으며, 지식 시험 점수가 급락한 업체도 4곳 있었습니다. 이전 7월 시험에서는 파이어웍스의 도구 호출 성적이 46%까지 떨어져 30점 이상의 격차를 기록하기도 했습니다. 다른 모델인 GLM 5.3으로 교체해 시험했을 때는 업체 간 성적 순위가 완전히 뒤바뀌었으므로, 도입하려는 실제 작업 유형과 가장 유사한 세부 성적표를 모델별로 대조해야 합니다.

둘째, 시각 정보를 인식하는 모델임에도 특정 제공업체를 거치면 이미지를 전혀 인식하지 못하는 이른바 시각 차단 현상이 발생합니다. 2026년 7월 31일 세 장의 단순한 시험용 이미지(알파벳 한 글자, 단색 빨간색, 배경 위의 단어)를 전송해 시험했을 때, 딥인프라의 큐원 모델 창구는 글자 K를 R 또는 I로 오독하고 빨간색을 파란색이라고 답했으며 보라색 배경의 우산 단어를 이상한 밝은 파란색이라고 잘못 설명했습니다. 반면 알리바바, 아틀라스클라우드, 노비타, 실리콘플로우는 세 시험을 모두 완벽히 통과했습니다. 또한 미니맥스 모델 시험에서는 베니스와 투게더가 이미지가 제공되지 않았다는 오류 문구를 출력하며 사진 입력을 인식하지 못했습니다. 미니맥스의 색상 오인 문제는 원개발사를 포함한 모든 업체에서 공통으로 나타나 모델 자체의 한계로 확인되었으나, 베니스와 투게더는 공식 설명에 이미지 지원이 명시되어 있음에도 정상 완료 코드인 200 OK를 회신하면서 사진 입력을 무시했습니다.

셋째, 인공지능의 사고 깊이를 제어하는 추론 노력(reasoning.effort) 조절 기능이 일부 업체에서는 전혀 작동하지 않습니다. 딥시크 모델을 서비스하는 모든 업체를 대상으로 낮음, 높음, 최대로 설정을 바꾸어 동일한 질문을 3회씩 보낸 결과, 다수 업체는 설정 단계에 맞춰 생각하는 단어 조각인 추론 토큰 수를 늘렸으나 디지털오션, 지엠아이클라우드, 맨서, 베니스는 설정을 변경해도 생성되는 추론 토큰 수에 유의미한 차이가 없었습니다.

넷째, 계산 단위를 줄여 메모리를 절약하는 압축 규격인 양자화 정밀도 필터는 답변 품질을 보장하는 지표가 되지 못합니다. 비트 수가 적은 fp4보다 비트 수가 많은 fp8 방식이 더 뛰어날 것이라는 일반적인 짐작과 달리, 9월 7일 실측 성적표에서 fp4 업체들의 점수는 fp8 업체들의 평균 수준에 고르게 섞여 있었습니다. 딥시크 지식 시험 최하위 3개 업체는 fp4 1곳, fp8 1곳, 압축 규격을 밝히지 않은 곳 1곳으로 나뉘었고, GLM 모델 시험에서 두 평가 항목 모두 1위를 기록한 웨이퍼는 정밀도 방식을 공개하지 않았습니다. 하드웨어 표기 규격만으로 업체를 걸러내면 장애 시 우회할 수 있는 예비 서버 풀만 줄어들므로, 규격 문구가 아닌 실측 성적표를 근거로 선택해야 합니다.

다섯째, 인공지능이 외부 도구를 실행하기 위해 생성한 컴퓨터 명령어가 일반 문자열 본문에 그대로 섞여 출력되는 결함이 나타납니다. 모델이 특정 기호로 감싼 호출 명령을 생성했을 때 제공업체의 전용 해석기가 이를 구조화된 기능 호출로 변환하지 못하면, 특수 태그가 포함된 시스템 명령어 문자열이 사용자 답변 본문으로 여과 없이 노출됩니다. 이러한 현상의 발생 빈도는 업체마다 천차만별이므로, 개발자는 응답 본문에 섞인 도구 호출 문법과 파손된 태그를 자체 소프트웨어에서 직접 분리해 해석하도록 대비책을 세워야 합니다.

여섯째와 일곱째, 서버 통신 성공 신호인 200 OK를 반환하면서 정작 알맹이 본문을 누락하는 빈 껍데기 응답 오류입니다. 추론형 모델이 생각 과정 칸에만 계산 내용을 채우고 정작 사용자에게 보여줄 최종 본문 칸을 비운 채 종료 상태를 반환하거나, 본문 내용과 생각 과정은 물론 자원 사용량 지표까지 완전히 비어 있는 200 OK 신호를 돌려주는 사례가 관찰되었습니다. 지난 7월 딥시크 모델 운영 당시 전체 통신량의 약 20%를 보냈던 스트림레이크에서 발생한 빈 응답의 92%가 집중되었고, 한 달 뒤에는 투게더의 딥시크 창구에서도 동일한 현상이 발생했습니다. 따라서 통신 코드가 정상 200이라 하더라도 본문과 도구 호출이 모두 비어 있다면 즉시 오류로 판정하고 재시도하도록 처리해야 합니다.

여덟째, 대화 기록을 넘겨받는 규칙이 업체마다 달라 충돌이 일어납니다. 딥시크 모델이 생각 모드에서 도구를 호출할 때 종종 생각 내용이 비어 있는 상태로 명령만 내리는데, 이 빈 생각 기록을 그대로 담아 다음 요청을 보낼 경우 실리콘플로우는 생각 내용이 반드시 포함되어야 한다는 전용 오류 코드와 함께 400 거부 응답을 냅니다. 반면 바이두, 알리바바, 클라우드플레어는 동일한 기록을 아무 문제 없이 받아들입니다. 도구 호출 기록을 누락하면 모델이 이전 작업을 기억하지 못해 동일 작업을 끝없이 재시도하는 무한 루프에 빠지므로, 제공업체별로 상이한 기록 규약에 맞춰 예외 처리를 만들어야 합니다.

아홉째, 개발용 개인 컴퓨터에서는 원활하게 동작하던 제공업체가 실제 운영 서버 환경에서는 접속 주소(IP) 단위 요청 횟수 제한 정책에 걸려 429 요청 초과 오류를 연쇄적으로 일으킬 수 있습니다. 베니스와 노비타는 개인용 맥 컴퓨터에서 정상 작동했으나 상용 서버 망에서는 거의 모든 요청에 429 오류를 냈으므로, 반드시 실제 배포 서버 환경에서 충분한 양의 표본을 두고 점검해야 합니다.

열째, 검증된 대형 제공업체 몇 곳만 우선순위로 고정해 두고 자동 우회 기능을 꺼두는 운영 방식은 전체 서비스를 한순간에 멈추게 만들 수 있습니다. 글쓴이가 클라우드플레어, 바이두, 알리바바 3곳만 고정하고 예외 우회를 차단했을 때, 불과 2주 만에 바이두는 429 요청 한도 초과를 냈고 클라우드플레어는 사전 예고 없이 해당 모델 서비스를 중단했습니다. 그 결과 100%의 트래픽이 남은 알리바바로 집중되었고, 알리바바마저 용량 초과로 429 오류를 쏟아내며 최상위 인기 모델을 기반으로 하던 비서 서비스 전체가 완전히 마비되는 장애가 일어났습니다.

4. 나에게 어떤 영향이 있나요?

인공지능 비서 앱이나 대화형 웹 서비스를 이용하는 일반 사용자는 동일한 모델을 사용하는 서비스라 하더라도 내부에서 연결된 호스팅 업체에 따라 잘못된 오답을 받거나 이미지를 인식하지 못하고 응답이 백지로 돌아오는 기술적 결함을 겪을 수 있습니다. 중개 플랫폼을 활용해 인공지능 응용 프로그램을 개발하고 운영하는 기업과 개발자는 제공업체가 일방적으로 홍보하는 정밀도 압축 사양만 신뢰해서는 안 되며, 실제 벤치마크 데이터를 주기적으로 감시해야 합니다. 아울러 내용물이 비어 있는 통신 성공 신호(200 OK), 업체별 대화 기록 규칙 불일치(400 오류), 운영 서버 접속 주소 기반 요청 제한(429 오류)에 대비한 자체적인 예외 파싱 규칙과 다중 대체 경로를 빈틈없이 구축해야만 서비스 불통 사태를 예방할 수 있습니다.