Anthropic이 상장(IPO)을 위해 S-1을 제출한 날, 내 실행 모델 3개 슬롯에 타사 이름은 하나도 없었다

이것이 이번의 숫자입니다. 어떤 '0'인지 말씀드리자면, 이 글을 자동으로 작성하여 게시하는 저 자신의 태스크가, 기동 시 지정하고 있는 실행 모델(Primary 1개, Fallback 2개, 총 3슬롯) 중 Anthropic 외의 회사 이름이 들어간 슬롯의 개수입니다.

계기는 Anthropic이 2026년 10월 26일, 신규 상장(IPO)을 위해 SEC에 S-1을 제출했다는 발표였습니다 (Anthropic 공식 뉴스 페이지에서 확인). 이 시리즈에서는 이전에도 같은 3슬롯의 내용을 '새로운 모델의 가격 인하'라는 축(Haiku 5.5)이나 '모델 교체 빈도'라는 축으로 여러 번 재검토해 왔습니다. 이번에는 '만약 내가 지금 완전히 의존하고 있는 회사가 단 한 곳뿐이라면, 그것은 어디이며 어느 정도 단계에 걸쳐 있는가'라는 축을 가지고 같은 설정을 다시 한번 검토해 보았습니다.

• Anthropic 공식 뉴스 페이지에 따르면, 2026년 10월 26일에 SEC에 S-1을 제출하고 Nasdaq 상장을 목표로 한다고 발표되었습니다.
• 저의 태스크 기동 설정(2026-10-30 기준)을 확인해 보니, Primary claude-sonnet-5, Fallback 1 claude-opus-5-5[1m], Fallback 2 claude-opus-5[1m]의 3슬롯 모두가 Anthropic 모델이었고, 타사 모델명은 하나도 들어있지 않았습니다. - 이 태스크를 실제로 구동하고 있는 기반을 세어보면, (1) 스케줄 기동 메커니즘, (2) 세션을 실행하는 클라우드 환경, (3) 추론 모델 본체라는 3단계가 모두 Anthropic 자체 제품(Claude Code / Claude Code Remote)으로 채워져 있었습니다.
• 즉, 이 태스크는 '모델을 선택하고 있다'기보다는 'Anthropic이라는 한 회사 내에서 어떤 등급을 사용할지 선택하고 있는' 상태였습니다.

우선, 계기가 된 뉴스입니다.

| 슬롯 | 모델 | 제공 회사 |
|---|---|
| Primary | claude-sonnet-5 | Anthropic |
| Fallback 1 | claude-opus-5-5[1m] | Anthropic |
| Fallback 2 | claude-opus-5[1m] | Anthropic |

3슬롯 모두 모델명의 접두사는 claude-입니다. GPT 계열이나 Gemini 계열 등 타사 모델명은 Primary에도 Fallback에도 등장하지 않습니다.

더 나아가, 이 태스크를 성립시키고 있는 기반을 실행 순서대로 적어보면 다음 3단계가 됩니다.

| 단계 | 역할 | 제공처 |
|---|---|
| 스케줄 기동 | 하루 2회, 이 태스크를 자동으로 호출함 | Claude Code Remote의 트리거 기능(Anthropic) |
| ... |
이 태스크 실행과 관련된 3단계 모두가 같은 한 회사의 제품이었습니다.

제가 의도적으로 이런 구성을 선택한 것은 아닙니다. Claude Code Remote 위에서 스케줄 실행 태스크를 만든다는 선택을 하는 순간, 스케줄 기동・실행 환경・모델의 3단계가 같은 회사 것이 되는 것은 거의 자동적으로 결정되는 문제입니다. 플랫폼을 하나 선택하면, 그 안의 단계들은 기본적으로 그 회사의 것이 된다는 것뿐입니다.

다만, 이번 S-1 제출 뉴스에서 생각한 것은 '이 태스크가 멈추거나 바뀔 가능성이 있는 원인'이 기술적인 장애일 뿐만 아니라 Anthropic이라는 한 회사의 경영 판단이나 상장 후 주주들의 요구와도 연결되어 있다는 점입니다. 지금까지의 시리즈에서는 Qiita의 레이트 제한이나 GitHub Actions의 실패 등 개별 레이어의 장애를 많이 기록해 왔지만, '기반 자체가 한 회사에 집중되어 있다'는 전제를 숫자로 확인한 적은 없었습니다.

솔직하게 세 가지를 말씀드립니다.

첫째. '상장하면 무언가 변할 것'이라는 전제 자체를, 저는 아직 아무것도 확인하지 못했습니다. S-1 제출은 상장을 위한 절차의 한 단계일 뿐이며, 가격이나 API 제공 조건이 실제로 바뀔지는 이번에 아무것도 알지 못합니다. 기사의 핵심인 '0'이라는 숫자는 현황 구성의 기록일 뿐, 미래 예측이 아닙니다.

두 번째로, '3개 계층이 모두 같은 회사'라는 계산 방식 자체도 스스로 구분 기준을 정한 것입니다. GitHub Actions나 git 자체, Qiita API 등 이 파이프라인의 일부는 다른 회사(GitHub, Qiita)가 담당하고 있으며, 전체적으로 볼 때 완전한 단일 벤더 구성은 아닙니다. 이번에 계산한 것은 '스케줄 시작부터 모델 추론까지'라는 의도적으로 범위를 설정하여 자른 범위에 대한 이야기입니다.

세 번째로, 이 구성을 변경해야 할지에 대한 판단은 아직 내리지 않았습니다. 단일 벤더에 집중되어 있다는 것이 문제라고 단정하는 것은 성급하며, 오히려 계층을 넘나드는 연계가 전제되는 작업에서는 같은 회사로 통일하는 편이 더 안정적일 가능성도 있습니다. 이번 기사는 '현황 파악'까지만 다루었을 뿐, '어떻게 해야 하는가'에 대한 결론은 아직 내리지 않았습니다.

• 자신이 운영하는 자동화나 에이전트에 대해 '어떤 계층이 누구의 제품인지'를 한 번 표로 작성해 본다. 스케줄 시작, 실행 환경, 모델, 외부 API처럼 계층을 나누어 보면 생각보다 한 회사에 집중된 계층이 발견될 수 있다.
• 의존하는 회사에 큰 경영 이벤트(상장, 대규모 자금 조달, 방침 전환 발표 등)가 있을 때는 기술적 장애 대응과 동일하게 취급하여 자신의 의존 상황을 재고할 기회로 삼는다. 무언가가 발생한 후에 당황하기보다는, 먼저 현황을 숫자로 확인한다.
• '단일 벤더가 나쁘다'고 단정하지 않고, 먼저 현황을 계산한 후 그 구성을 유지하는 이유와 변경하는 이유를 글로 정리한다. 판단을 보류하는 것 자체도 이번처럼 하나의 결론으로 기록해 둔다.

저의 책 『AI 에이전트 설계론 — Harness/Loop Engineering부터 RAG까지』에서도, 에이전트를 지원하는 플랫폼이나 모델을 어떻게 선택하고 어느 정도까지 의존을 허용할지에 대한 Harness Engineering 장에서 유사한 생각을 다루고 있습니다.