!원문 캡처 · amplifying.ai

Amplifying은 같은 공개 AI 서비스 상태 대시보드 요청을 OpenAI Dots와 Meta Muse에 각각 8회 입력해 결과를 비교했다. Dots는 8개 앱을 모두 공개했고, Muse에서는 공개 배포를 확인한 앱이 없었다. 다만 공개 URL이 있다고 해서 예약 수집이나 데이터 정확성까지 완성된 것은 아니었다.

  • Dots는 ChatGPT Sites를 통해 Cloudflare Workers에 앱을 배포했고, 플랫폼에서 제공하는 D1 데이터베이스와 ChatGPT 로그인을 사용했다.
  • Muse는 6개 앱을 로컬 서버에서 실행했고, 1개는 비공개 플랫폼 아티팩트, 1개는 정적 HTML 파일로 제공했다.
  • 두 제품 모두 상태 페이지를 가져와 파싱하는 코드를 작성했지만, 예약 수집은 일부 결과물에서 작동하지 않거나 실행 중인 서버에 의존했다.

같은 요청에서 요구한 기능

요청한 앱은 12개 AI 서비스의 공식 상태 정보를 모아 보여주는 공개 대시보드였다. 서비스별 상태와 영향을 받은 구성요소, 최근 사고 및 업데이트 타임라인을 표시하고, 모델 API·클라우드 AI 서비스·추론 및 라우팅 플랫폼·개발자 도구를 구분해야 했다. 정보는 제공업체가 보고한 내용으로 표시하고, 출처 링크와 시각, 서비스 및 지역 범위를 보존해야 했다. 근거 없이 모델 수준의 세부사항을 만들거나 한 지역의 사고를 회사 전체 문제로 확대하거나, 한 제공업체의 사고가 다른 제공업체의 사고를 일으켰다고 추론하지 말라는 조건도 포함됐다.

대시보드에 포함할 공식 상태 출처는 다음과 같았다.

  • OpenAI: 상태 페이지 — 모델 및 API 구성요소를 다루고 ChatGPT 소비자 서비스 사고와 분리한다.
  • Anthropic/Claude: 상태 페이지 — Claude API 구성요소를 다루고 소비자용 채팅 사고와 분리한다.
  • Google Gemini: AI Studio 상태 페이지 — Gemini API를 다루고 AI Studio 인터페이스 문제와 구분한다.
  • xAI/Grok: 상태 페이지 — Grok API를 다루고 소비자용 Grok 사고와 구분한다.
  • Mistral: 상태 페이지 — 모델 및 API 구성요소를 다루고 소비자용 채팅과 구분한다.
  • DeepSeek: 상태 페이지 — 모델 및 API 구성요소를 다루고 채팅, 검색, 파일 업로드를 구분한다.
  • Cohere: 상태 페이지 — 모델 및 API 엔드포인트 상태를 다루고, 보고된 경우에만 모델 세부사항을 유지한다.
  • Microsoft Azure AI: Azure 상태 페이지 — Azure OpenAI와 Foundry의 모델·에이전트 서비스를 다루고, 보고된 서비스와 지역을 유지한다.
  • Amazon Bedrock: AWS Health 상태 페이지 — Amazon Bedrock 관련 이벤트와 보고된 지역을 다루며, AWS 전체 상태로 확대하지 않는다.
  • OpenRouter: 상태 페이지 — 라우팅 및 API 상태를 다루고, 라우터 상태로 상위 제공업체의 상태를 추정하지 않는다.
  • Groq: 상태 페이지 — GroqCloud API 추론을 다루며 xAI/Grok과 구분한다.
  • Cursor: 상태 페이지 — 보고된 IDE, CLI 및 에이전트 서비스 구성요소를 다루며 모델 API와 동일시하지 않는다.

사용자는 계정을 만들고 로그인해 서비스별 비공개 관심 목록을 저장할 수 있어야 했다. 관심 목록은 로그아웃, 브라우저 재시작, 기기 변경 후에도 유지되고 다른 사용자가 읽거나 수정할 수 없어야 했다. 수집 작업은 앱을 열어 둔 사용자가 없어도 15분마다 실행되고, 사고 이력을 보존하면서 기존 사고를 중복 생성하지 않고 업데이트해야 했다. 출처별 마지막 수집 성공 시각도 표시해야 했다. 수집에 실패하면 이전 데이터를 유지하고 오래된 정보 또는 알 수 없는 상태라고 밝혀야 하며, 제공업체가 정상이라고 암시해서는 안 됐다. 요청한 정보를 출처가 제공하지 않거나 수집할 수 없는 경우에도 서비스는 목록에 남기고 범위의 공백을 설명해야 했다. 보호된 관리자 새로고침 기능도 요구됐다.

요청은 공유되고 지속적으로 저장되는 데이터가 있는 공개 앱을 요구했다. 소유자만 볼 수 있는 미리보기는 허용되지 않았다. 호스팅, 인증, 데이터 저장, 수집 및 예약 실행 방식은 제품이 선택하도록 했으며, 파일 업로드와 이메일·SMS 알림은 필요하지 않았다. 사용할 수 있는 접근 권한 때문에 기능을 완성할 수 없다면 부족한 점을 정확히 밝히고, 작동하는 기능과 구현하지 못한 기능을 구분하라는 조건도 있었다.

호스팅과 저장 방식

Dots는 ChatGPT Sites를 통해 앱을 Cloudflare Workers에 배포했다. 별도의 호스팅 계정이나 Cloudflare 자격 증명을 제공하지 않아도 Sites가 Cloudflare D1 저장소와 ChatGPT 로그인을 제공했다. Muse는 자체 컴퓨터에서 패키지를 설치하고 서버를 실행했다. 외부 방문자가 서버에 접속하도록 Cloudflare Tunnel, localtunnel.me, localhost.run을 시도했지만 네트워크 제한과 권한 요청이 발생했다. 터널은 Muse 안에서 실행되는 서버를 외부에 노출할 뿐, 앱을 호스팅 플랫폼으로 옮기지는 않는다.

Dots는 8개 빌드 모두 공개 앱을 배포했고, Muse는 공개 앱 0개를 검증받았다. Dots의 앱 가운데 3개는 전달 시점에 활성화된 스크래핑 예약 작업이 없었다. Muse 결과물은 로컬 앱 6개, 비공개 아티팩트 1개, 정적 HTML 다운로드 1개였다. 두 제품 모두 외부 호스팅·데이터베이스·인증 계정을 연결하지 않고 같은 프롬프트를 받았다. 공개 URL만으로 앱의 전체 기능이 작동한다고 볼 수는 없다. Muse의 통상적인 배포 경로는 로컬 서버였으며, 한 번은 로그인해야 볼 수 있는 플랫폼 아티팩트를 만들었다.

실행 환경 선택도 달랐다. Dots는 8개 빌드에서 React, Vinext, Vite를 함께 사용했다. Muse는 빌드에 따라 Node.js와 Express 4개, Python HTTP 서버 2개, Flask 1개, React와 Muse SDK 1개 등 네 가지 스택을 사용했다. Dots 앱은 ChatGPT 로그인을 사용했고, Muse 앱 7개는 자체 계정 기능을 구현했으며 1개는 @hatch/space-sdk를 통한 Muse 로그인을 사용했다.

Dots는 Cloudflare D1이라는 관리형 SQLite 기반 데이터베이스를 사용했다. Muse 앱 7개는 로컬 SQLite 파일을 사용했다. 나머지 한 빌드는 Muse 플랫폼에서 실행되는 앱을 위한 라이브러리인 @hatch/space-sdk를 썼다. 이 앱은 ctx.db를 통해 Muse가 제공하는 데이터베이스 연결에 접근했고, Drizzle로 SQLite 스키마를 정의했다. 같은 라이브러리가 ctx.viewer를 통해 로그인한 사용자 신원을 제공했다. 어느 제품도 별도의 Neon 또는 Supabase 서비스를 설정하지 않았다.

D1은 배포된 앱에 이미 연결된 데이터베이스였고 저장소는 Cloudflare가 운영했다. Muse는 로컬 데이터베이스 파일을 직접 사용할 수 있었지만, 설정 안내에서는 호스트의 지속적 저장소가 여전히 필요했다. 다만 로컬 SQLite도 공개 웹 앱에 사용할 수 있다. Supabase는 Turso 인수 발표에서 에이전트가 파일을 만들듯 쉽게 데이터베이스를 만들 수 있어야 한다는 취지의 주장을 내놓았다. Amplifying은 공급업체가 파일을 지속적인 저장소를 갖춘 배포 데이터베이스로 전환하는 데 도움을 줄 수 있다고 봤으며, Dots는 ChatGPT Sites를 통해 이미 그런 환경을 제공받았다고 평가했다.

로그인과 데이터 수집

Dots는 ChatGPT 로그인을 사용했다. Muse 빌드 7개는 자체 계정, 비밀번호 해시 처리, 세션을 구현했고 나머지 하나는 @hatch/space-sdk로 Muse 로그인을 사용했다. 어느 제품도 Clerk나 WorkOS 같은 별도의 서비스를 설정하지 않았다. Amplifying은 Muse 독립 앱의 비밀번호 및 세션 코드를 개발자가 검토해야 한다고 지적했다. 플랫폼 로그인은 Dots의 구현 부담을 줄였지만, 각 앱은 여전히 사용자의 관심 목록을 비공개로 유지해야 했다. Amplifying은 두 제품의 앱을 프로덕션 보안 관점에서 감사하지 않았다고 밝혔다.

두 제품 모두 상태 페이지를 직접 요청하고 출처별 파서를 적용하는 맞춤 코드를 작성했다. Dots는 ChatGPT 작업을 이용해 수집기를 호출했지만, 일부 빌드는 활성 예약 작업 없이 끝났다. Muse는 일부 빌드에서 플랫폼 작업을 사용했고, 다른 빌드에서는 서버 내부 타이머를 사용했다. 서버 타이머는 해당 프로세스가 계속 실행 중이어야 작동한다. Dots 앱 하나에서는 브라우저를 닫아 둔 동안 새로운 스크래핑 시각이 기록되는 것을 확인했다. Muse의 백그라운드 스크래핑은 검증하지 않았다.

비교 결과와 한계

Amplifying이 확인한 가장 뚜렷한 차이는 공개 배포였다. Muse는 코드를 작성했지만 외부에서 접근할 수 있는 공개 배포 앱은 확인되지 않았다. Dots는 8개 빌드를 모두 ChatGPT Sites로 공개했다. 다만 일부 대시보드는 예약 작업을 고치고 출처 범위를 점검해야 했다. Muse의 독립 앱은 연결 가능한 호스트, 지속적 저장소, 계속 실행되는 프로세스가 필요했다. 기존 서버나 연결된 호스팅 계정에 배포하는 경우는 시험하지 않았다.

Run 6에서는 공개된 Dots 사이트와 독립 실행형 Muse 앱을 비교했다. Muse가 제공한 스크린샷은 로컬 서버에서 실행된 앱을 Chromium으로 캡처한 이미지였으며, 공개 배포에 접속한 결과는 아니었다.

  • OpenAI Dots, Run 6 공개 웹사이트: 공개 AI Signal 사이트를 브라우저에서 캡처했다. 앱 URL은 가렸다. Dots 전체 스크린샷
  • Meta Muse, Run 6 로컬 앱: Muse가 로컬 앱의 Chromium 캡처로 제공했다. 공개 배포에는 접속하지 않았다. Muse 전체 스크린샷

Run 1에서 Muse는 플랫폼의 저장소와 신원 기능을 이용한 아티팩트를 만들었다. 이 아티팩트는 Muse 로그인이 필요했다. Dots의 첫 번째 빌드도 함께 비교했다.

  • OpenAI Dots, Run 1 공개 웹사이트: 로그인하지 않고 공개된 사이트를 열어 브라우저에서 캡처했다. 앱 URL은 가렸다. Dots 전체 스크린샷
  • Meta Muse, Run 1 비공개 아티팩트: Muse 안에서 앱을 캡처했다. 로그아웃한 상태에서 열면 Muse 로그인 페이지로 이동했다. Muse 전체 스크린샷

캡처는 서로 다른 시점과 화면 크기에서 이뤄졌다. 화면에 표시된 상태 건수는 출처 정보의 정확성을 비교한 결과가 아니다.

Amplifying은 이 실행에서 Dots가 ChatGPT Sites를 통해 호스팅, 저장소, 로그인을 연결해 둔 표준 환경의 이점을 얻었다고 평가했다. Muse는 추가 설정이 더 필요했고 결과도 덜 일관적이었다. 또한 Muse가 앞으로 앱 제작과 배포를 개선할 것으로 예상한다고 밝혔다. 전체 연구는 What Dots Actually Choose와 What Muse Actually Chooses에서 확인할 수 있다.

전달 결과 차트 다운로드(PNG)