Optic은 사라졌다. OpenAPI 호환성을 깨는 변경을 위한 2026년 마이그레이션 가이드
출처: Dev.to
이 글은 원래 SpecShield 블로그에 게재되었습니다. 저는 아래에서 다루는 마이그레이션 대상 중 하나인 SpecShield의 공동 창업자입니다—전면 공개합니다. 이 글은 SpecShield가 어디에 맞는지, 그리고 다른 도구가 더 잘 맞는 경우를 솔직하게 설명하려고 합니다.
TL;DR
- Optic의 GitHub 저장소는 2026년 1월 12일에 아카이브되었습니다. 마지막 릴리스: 2025년 8월 v1.0.9.
useoptic.com도메인은 더 이상 해석되지 않습니다. - Optic은 2024년 4월 Atlassian에 인수되었지만 Atlassian Compass에 통합되지 않았습니다.
- MIT 라이선스 소스는 아직 GitHub에 존재하지만 방치된 상태—보안 패치도 없고, 새로운 규칙도 없으며, 지원도 없고, 전이 의존성이 EOL(수명 종료)될 때 CI가 결국 깨질 것입니다.
- Spec-diff와 CI에서의 파괴적 변경 검사에 Optic을 주로 사용했다면 가장 직접적인 마이그레이션 경로는 SpecShield(웹 UI + CLI + GitHub App + 무료 GitHub Action) 혹은 oasdiff(오픈소스 CLI, UI 없음)입니다.
- 테스트 트래픽으로부터 OpenAPI를 생성하기 위해 Optic을 사용했다면 직접적인 대체 도구가 없습니다. 워크플로를 바꿔야 합니다.
아래에는 기능별 비교 표, 단계별 마이그레이션 가이드, 그리고 대체하기 어려운 부분에 대한 솔직한 목록이 있습니다.
지난 6년 동안 Optic은 OpenAPI 파괴적 변경 감지를 위한 오픈소스 기본 도구였습니다. 대부분의 개발자 툴 스타트업이 갖추지 못한 깨끗한 CLI, 합리적인 규칙 시스템, MIT 라이선스, 깊은 CI 통합, 그리고 작지만 헌신적인 커뮤니티를 가지고 있었죠.
Optic이 사라진 흐름
| 날짜 | 사건 |
|---|---|
| 2024년 4월 | Atlassian이 Optic Labs를 인수. Optic 팀이 Atlassian에 합류. |
| 2024년 4월 – 2025년 8월 | 릴리스 주기가 느려짐. 대부분의 커밋이 의존성 업데이트에 불과. 이슈가 답변 없이 쌓임. |
| 2025년 8월 10일 | 최종 릴리스: v1.0.9. 마지막이라는 힌트를 주는 릴리스 노트는 없음. |
| 2025년 8월 – 2026년 1월 | 침묵. 릴리스도 없고, 유지보수자 응답도 없음. 커뮤니티는 “Optic이 아직 유지보수되고 있나요?”라고 질문하지만 공식 답변은 없음. |
| 2026년 1월 12일 | opticdev/optic GitHub 저장소가 아카이브(읽기 전용)됨. useoptic.com 도메인도 곧 해석되지 않음. |
공식적인 종료 발표도, Optic 팀이 제공한 마이그레이션 가이드도, “아카이브됐지만 포크는 여기 있어요” 같은 축복도 없었습니다. 그냥 멈춘 겁니다.
Atlassian 인수 이후 커뮤니티의 기대는 Optic이 Atlassian Compass—Atlassian의 개발자 경험 제품—에 포함될 것이라는 것이었습니다. 그러나 그 통합은 결코 출시되지 않았습니다. 2026년 5월 현재, Compass는 서비스 카탈로그와 DORA 메트릭에 집중하고 있으며 API 드리프트 감지 기능은 없습니다.
1.5k 스타를 받은 저장소는 92개의 포크가 있지만, 커뮤니티가 이어받은 후속 프로젝트는 아직 없습니다. npm에서 @useoptic/optic에 계속 의존한다면, 유지보수되지 않는 코드를 사용하고 있는 것이며, 해당 코드의 TypeScript / Node / npm 피어 의존성이 EOL에 도달하면 결국 깨질 것입니다.
이제 마이그레이션이 필요합니다. 좋은 소식은 대부분의 팀에게 4시간 안에 끝낼 수 있는 작업이라는 점입니다(4주 프로젝트가 아니라).
Optic은 다섯 가지 뚜렷한 기능을 제공했습니다. 팀마다 사용한 부분이 달랐으니, 교체 도구를 고르기 전에 자신에게 적용되는 기능을 먼저 파악하세요—잘못 선택하는 것이 가장 큰 마이그레이션 실수입니다.
가장 흔한 사용 사례
레포에
openapi.yaml이 있고, PR마다 CI에서optic diff를 실행해 파괴적 변경 경고를 PR에 코멘트한다.
- 대체 난이도: 쉬움. 여러 대체 옵션이 바로 사용 가능.
Optic 고유 규칙 파일 (.optic.dev.yml)
예: “모든 경로는 kebab-case여야 함”, “각 엔드포인트는 설명이 필요함”
- 대체 난이도: 중간. Spectral로 전환해야 합니다. Spectral은 OpenAPI 린팅의 사실상 표준이며, 훨씬 큰 규칙 생태계를 가지고 있습니다. 기존 커스텀 규칙은 Spectral 형식으로 다시 작성해야 합니다.
optic capture (테스트 트래픽 기반 스펙 자동 생성)
가장 혁신적인 기능이었습니다. 테스트 스위트를 Optic 프록시 앞에서 실행하면, 관찰된 트래픽으로부터 OpenAPI 스펙을 자동으로 생성(또는 업데이트)했습니다.
- 대체 난이도: 어려움. 동일한 성숙도를 가진 직접적인 오픈소스 대체 도구가 없습니다. 가능한 대안:
- Pollyjs – HTTP 기록/재생, 범용적
- Speakeasy – 워크플로가 다름—스펙이 SDK를 구동하고, 트래픽이 스펙을 구동하지 않음
- 수동 유지보수 – 대부분의 팀이 결국 선택하는 방법
optic capture에 크게 의존했다면, 스펙‑diff 사용자보다 마이그레이션이 더 고통스러울 수 있습니다. 계획을 잘 세우세요.
useoptic/optic-action GitHub Action
PR에 diff 결과를 코멘트했습니다.
- 대체 난이도: 쉬움. 비슷하거나 더 나은 PR 코멘트 디자인을 제공하는 여러 대체 옵션이 있습니다.
Optic Cloud (SaaS 레이어)
릴리즈 간 diff를 웹 UI에서 탐색하고, 비개발자 이해관계자와 공유할 수 있었습니다.
- 대체 난이도: 중간. 현재 사용 가능한 호스팅 UI 도구는 비용이 더 많이 들거나(Bump.sh, Stoplight) 다소 투박합니다. SpecShield의 웹 UI는 범위가 동일하고 활발히 개발 중입니다.
2026년 5월 현재 현실적인 대안 비교
| 도구 | 교체 대상 | 가격 | 호스팅 UI | OSS 엔진 | PR 코멘트 | 활발한 개발 |
|---|---|---|---|---|---|---|
| SpecShield | Optic의 spec‑diff, 파괴적 변경 감지, 호스팅 UI, CI 통합, BDCT(보너스) | 무료 티어; 월 $29부터 | ✅ | 코어는 폐쇄형, 무료 GitHub Action은 2026년 말에 공개 예정 | ✅ (GitHub App + Action) | ✅ |
| oasdiff | spec‑diff 및 파괴적 변경 감지 (CLI 전용) | 무료 / OSS (Apache 2.0) | ❌ | ✅ (Go) | ✅ 공식 GitHub Action 통해 | ✅ |
| Spectral | Optic의 린팅 (diff는 아님) | 무료 / OSS (Apache 2.0) | ❌ | ✅ (TS) | 커스텀 통합 필요 | ✅ (SmartBear 인수 후 다소 느려짐) |
| Bump.sh | 호스팅 문서 + changelog (Optic CI 흐름과는 다름) | 월 $50부터 | ✅ | ❌ | ❌ 네이티브 PR 코멘트 없음 | ✅ |
| Redocly CLI | 린팅 + 기본 diff | 무료 CLI; 유료 플랫폼 | ✅ (유료) | 부분 OSS | 커스텀 통합 필요 | ✅ |
마이그레이션 패턴 3가지 (전체 사용자의 약 95% 커버)
- CI에서 spec‑diff 사용 + UI 필요 → SpecShield (가장 직접적인 교체, 인지적 전환 최소)
- CI에서 spec‑diff 사용 + UI 불필요 → oasdiff (CLI‑only, Apache 2.0, SaaS 기업보다 오래 살아남음)
- Linting 사용 → Spectral (어떤 diff 도구를 쓰든 관계없이)
이 글의 나머지는 패턴 #1에 초점을 맞춥니다—가장 흔하고 문서화가 부족한 경우이기 때문입니다. 패턴 #2 혹은 #3이라면 oasdiff와 Spectral의 공식 문서가 충분히 훌륭하니 별도 마이그레이션 가이드는 필요 없습니다.
SpecShield가 Optic을 대체하는 이유
SpecShield는 Optic이 강조한 spec‑first, CI‑driven 워크플로를 위해 설계되었습니다. 사고 모델은 동일합니다:
- OpenAPI 스펙을 Git에 커밋한다.
- 모든 PR마다 새 스펙을 베이스 브랜치와 비교한다.
- 파괴적 변경을 머지 전에 표시한다.
- UI, CLI, PR 코멘트 모두에서 아름다운 diff 리포트를 제공한다.
Optic과 동일한 점
- OpenAPI 3.0 및 3.1 지원
$ref를 이용한 다중 파일 스펙 지원- 파괴적 변경 분류(삭제된 경로, 타입 변경, 새로운 필수 필드 등)
- GitHub App 및 (