Rihpig

Posted on Apr 30 • Originally published at apidog.com

Ghostty 깃허브 떠난다: 개발자 도구 제작자에게 미치는 영향

2026년 4월 28일, 미첼 하시모토는 오픈소스 터미널 에뮬레이터 Ghostty가 GitHub를 떠날 것이라고 발표했습니다. 그는 GitHub 사용자 1299번이고, 2008년 2월부터 18년 넘게 거의 매일 GitHub를 사용해 왔습니다. 하지만 발표 당일에도 GitHub Actions 오류로 PR 검토가 약 두 시간 동안 막혔고, 그는 이미 “거의 매일 X가 있다”는 식으로 장애 기록을 남기고 있었습니다. 그의 결론은 명확했습니다. “매일 몇 시간씩 작업을 방해한다면 더 이상 진지한 작업을 위한 공간이 아니다.”

오늘 Apidog를 사용해 보세요

개발자 도구를 만드는 팀이라면 이 사례를 단순한 “GitHub 이탈” 뉴스로 보면 안 됩니다. 하시모토는 GitHub 위에서 HashiCorp를 공동 설립했고, Terraform, Vagrant, Vault, Consul, Boundary 같은 도구를 GitHub를 통해 출시한 사용자입니다. 그런 사용자가 기능이나 가격이 아니라 안정성 때문에 플랫폼을 떠난다는 것은, 개발자 워크플로우의 핵심 경로에 있는 도구가 어떤 기준을 충족해야 하는지 보여주는 신호입니다.

AI 시대의 GitHub 네이티브 워크플로우 변화는 AGENTS.md 파일 작성 방법과 팀을 위한 GitHub Copilot 사용 및 청구 API를 참고하세요. GitHub 안정성 격차를 자동화로 완화하는 사례는 Clawsweeper 분류 봇 작성기에서 볼 수 있습니다.

요약

미첼 하시모토는 2026년 4월 28일 Ghostty가 GitHub를 떠나 아직 정해지지 않은 다른 포지(forge)로 이동할 것이라고 발표했습니다.
이유는 GitHub Actions 및 플랫폼 전반의 반복적인 장애였습니다.
발표 당일에도 Actions 오류로 약 두 시간 동안 PR 검토가 막혔습니다.
Ghostty의 GitHub 저장소는 읽기 전용 미러로 남고, 활발한 개발은 점진적으로 새 포지로 이동합니다.
그의 다른 프로젝트들은 당분간 GitHub에 남아 있습니다.
핵심 교훈은 명확합니다. 개발자 도구가 사용자의 중요 경로에 들어가면 안정성이 기능보다 중요해집니다.
API 팀은 공급자 독립적인 클라이언트, 모의 서버, 다중 공급자 테스트, 대체 릴리스 경로를 미리 준비해야 합니다.
Apidog는 API 정의, 모의 서버, 환경 변수, 계약 테스트를 한 워크플로우에서 다룰 수 있게 해주는 도구입니다.

하시모토가 실제로 말한 내용

발표 게시물은 짧습니다. Microsoft 비판도, 특정 대안 포지 홍보도, 긴 선언문도 없습니다.

그는 다음 흐름으로 설명합니다.

GitHub 장애 기록을 개인적으로 남기기 시작했다.
예상보다 빠르게 “거의 매일 무언가 있다”는 패턴이 보였다.
발표 당일 GitHub Actions 장애로 PR 검토가 약 두 시간 동안 막혔다.
Ghostty 같은 프로젝트를 운영하기에는 GitHub가 충분히 안정적이지 않다고 판단했다.

중요한 점은 이것이 단일 장애에 대한 즉흥 반응이 아니라는 것입니다. 하시모토는 이미 몇 달 동안 패턴을 추적하고 있었고, 2026년 4월 27일 발생한 대규모 GitHub 장애는 결정을 만든 사건이라기보다 발표 시점을 앞당긴 사건에 가깝습니다.

현재 계획은 다음과 같습니다.

Ghostty GitHub 저장소는 읽기 전용 미러로 유지
이슈, 풀 리퀘스트, CI 등 활발한 개발은 새 포지로 이전
상업 및 FOSS 공급자 모두 검토 중
마이그레이션은 한 번에 끝내는 방식이 아니라 점진적으로 진행
다른 하시모토 프로젝트들은 당분간 GitHub에 유지

여기서 핵심은 “기능 부족”이 아니라 “기반이 자주 멈춘다”는 점입니다.

왜 이 사건은 마이그레이션보다 안정성 문제인가

이 사건에서 가장 흥미로운 질문은 “Ghostty가 어디로 가는가?”가 아닙니다.

더 중요한 질문은 다음입니다.

GitHub처럼 성숙한 개발자 플랫폼에서도 왜 핵심 사용자가 안정성 문제로 떠나게 되었는가?

개발자 도구를 운영한다면 다음 세 가지를 봐야 합니다.

1. 사용자의 무게

하시모토는 단순한 파워 유저가 아닙니다. 그는 대규모 인프라 도구를 만든 사람이고, GitHub 생태계의 초기 사용자입니다.

그가 “GitHub는 더 이상 안정적이지 않다”고 말하면, 그 메시지는 개인 불만이 아니라 엔지니어링 리더들이 검토해야 하는 리스크 신호가 됩니다.

2. 이탈 이유

그는 Copilot, AI 학습, 가격, Microsoft, 정책 문제 때문에 떠난 것이 아닙니다.

이유는 단순합니다.

필요할 때 도구가 작동하지 않았다.

개발자 도구에서 이보다 더 치명적인 이유는 많지 않습니다.

3. 감정이 없는 어조

게시물은 분노한 글이 아니라 사후 분석처럼 읽힙니다. 오랫동안 참다가 더 이상 비용을 감당할 수 없다고 판단한 사용자의 기록입니다.

개발자 도구 팀 입장에서 이것이 가장 위험합니다. 화난 트윗은 대응할 수 있지만, 조용히 쌓인 장애 일지는 되돌리기 어렵습니다.

개발자 도구 팀이 바로 점검해야 할 질문

여러분의 제품이 개발자의 배포, 리뷰, 테스트, 문서화, 모니터링 경로에 있다면 다음 질문을 적용해 보세요.

질문 1: 사용자가 우리 서비스에 대해 장애 일지를 쓸 수 있는가?

지난 90일을 기준으로 확인합니다.

상태 페이지에 공개한 인시던트
공개하지 않았지만 내부적으로 알고 있는 성능 저하
특정 리전 또는 특정 기능 장애
백그라운드 작업 지연
API 응답 시간 증가
CI/CD 큐 지연

그리고 이를 상위 고객의 근무 시간과 매핑합니다.

예를 들어 다음처럼 계산할 수 있습니다.

고객 A
- 4월 10일: CI 큐 지연 45분
- 4월 17일: API 응답 지연 30분
- 4월 22일: 인증 오류 20분

월간 누적 차단 시간: 95분

한 고객이 매주 반복적으로 30분~1시간씩 막힌다면, 전체 가동률 수치가 좋아도 신뢰는 무너질 수 있습니다.

질문 2: 안정성은 개선 중인가, 악화 중인가?

단일 장애보다 중요한 것은 추세입니다.

다음 지표를 월별로 봐야 합니다.

월별 인시던트 수
월별 부분 장애 수
평균 복구 시간(MTTR)
사용자 영향 시간
특정 기능별 오류율

예시:

GitHub Actions 같은 핵심 기능이 있다고 가정

1월: 장애 1건, 총 20분
2월: 장애 2건, 총 50분
3월: 장애 4건, 총 120분
4월: 장애 5건, 총 180분

SLA를 아직 지키고 있어도 추세는 명확히 나빠지고 있습니다. 사용자는 이 추세를 체감합니다.

질문 3: 상태 페이지가 실제 상황을 말하고 있는가?

사용자가 직접 장애 일지를 쓰는 이유는 공식 신호를 믿지 못하기 때문입니다.

상태 페이지에는 최소한 다음을 명확히 표시해야 합니다.

어떤 기능이 영향을 받는지
어느 리전 또는 고객군이 영향을 받는지
지연인지, 실패인지, 데이터 손실 가능성인지
우회 방법이 있는지
다음 업데이트 시점은 언제인지

나쁜 예:

일부 사용자가 문제를 겪고 있습니다. 조사 중입니다.

좋은 예:

GitHub Actions 스타일의 CI 큐 처리 지연이 발생 중입니다.
영향 범위: us-east 리전의 Linux runner
증상: 작업 시작까지 20~40분 지연
우회 방법: self-hosted runner 사용 가능
다음 업데이트: 30분 후

개발자는 완벽한 무중단보다 정확한 정보를 더 신뢰합니다.

질문 4: 데모용 안정성이 아니라 실제 작업용 안정성인가?

99.95% 가동률이라도 장애가 항상 사용자의 PR 리뷰 시간, 릴리스 시간, 배포 시간에 발생하면 체감 안정성은 낮습니다.

개발자 도구는 다음 단위로 안정성을 측정해야 합니다.

PR 리뷰 세션
릴리스 윈도우
CI 파이프라인 실행
온콜 대응
고객 배포 시간
API 계약 테스트 실행 시간

전체 월간 가동률만 보면 실제 개발자 경험을 놓치기 쉽습니다.

“항상 GitHub”의 비용

하시모토가 말한 핵심 문장은 다음입니다.

내 프로젝트를 어디에 둘지는 나에게 전혀 문제가 되지 않았다. 항상 GitHub였다.

많은 개발팀이 같은 상태입니다.

GitHub는 단순한 Git 원격 저장소가 아닙니다. 보통 다음을 모두 포함합니다.

Git 저장소
이슈 트래커
Pull Request 리뷰
CI/CD
릴리스
패키지 배포
Discussions
프로젝트 보드
OAuth 로그인
권한 모델
CODEOWNERS
시크릿 관리

그래서 “저장소를 옮기면 되지”는 실제 마이그레이션 비용을 과소평가한 말입니다.

Git 기록은 쉽게 복제할 수 있습니다.

git clone --mirror git@github.com:org/repo.git
cd repo.git
git push --mirror git@codeberg.org:org/repo.git

하지만 다음은 단순하지 않습니다.

PR 리뷰 기록
이슈 코멘트
CI secrets
Actions workflow
릴리스 아티팩트
패키지 registry
팀 권한
봇 계정
웹훅
브랜치 보호 규칙

즉, 종속성은 git remote보다 훨씬 넓습니다.

GitHub 의존도를 줄이는 기본 패턴

완전한 이주는 어렵지만, 리스크를 줄이는 작업은 지금 시작할 수 있습니다.

1. 저장소를 두 번째 포지에 미러링

예시: GitHub Actions로 Forgejo 또는 Codeberg에 미러링

name: mirror-repository

on:
  schedule:
    - cron: "0 3 * * *"
  workflow_dispatch:

jobs:
  mirror:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout mirror
        run: |
          git clone --mirror https://github.com/YOUR_ORG/YOUR_REPO.git repo.git
          cd repo.git
          git remote add backup https://codeberg.org/YOUR_ORG/YOUR_REPO.git
          git push --mirror backup

운영 환경에서는 토큰을 GitHub Secrets에 넣고 HTTPS URL에 주입하거나 SSH deploy key를 사용하세요.

2. GitHub API 클라이언트를 어댑터로 감싸기

나쁜 구조:

import { Octokit } from "@octokit/rest";

const github = new Octokit({ auth: process.env.GITHUB_TOKEN });

export async function createIssue(title: string, body: string) {
  return github.issues.create({
    owner: "org",
    repo: "repo",
    title,
    body,
  });
}

이 구조는 GitHub에 직접 묶입니다.

더 나은 구조:

export interface IssueTracker {
  createIssue(input: {
    title: string;
    body: string;
    labels?: string[];
  }): Promise<{ id: string; url: string }>;
}

GitHub 구현:

import { Octokit } from "@octokit/rest";
import type { IssueTracker } from "./IssueTracker";

export class GitHubIssueTracker implements IssueTracker {
  private client: Octokit;

  constructor(token: string) {
    this.client = new Octokit({ auth: token });
  }

  async createIssue(input: {
    title: string;
    body: string;
    labels?: string[];
  }) {
    const res = await this.client.issues.create({
      owner: "org",
      repo: "repo",
      title: input.title,
      body: input.body,
      labels: input.labels,
    });

    return {
      id: String(res.data.id),
      url: res.data.html_url,
    };
  }
}

나중에 Forgejo, GitLab 구현을 같은 인터페이스 뒤에 추가할 수 있습니다.

export class GitLabIssueTracker implements IssueTracker {
  async createIssue(input: {
    title: string;
    body: string;
    labels?: string[];
  }) {
    // GitLab API 호출
    return {
      id: "123",
      url: "https://gitlab.com/org/repo/-/issues/123",
    };
  }
}

핵심은 GitHub를 코드 전체에 흩뿌리지 않는 것입니다.

3. 릴리스 경로를 문서화

자동 릴리스가 멈췄을 때 수동 릴리스 경로가 있어야 합니다.

문서에는 최소한 다음이 있어야 합니다.

수동 릴리스 절차

1. main 브랜치 최신 커밋 확인
2. 로컬에서 테스트 실행
3. 버전 태그 생성
4. 빌드 아티팩트 생성
5. 체크섬 생성
6. 패키지 registry에 수동 업로드
7. 릴리스 노트 게시
8. 고객 상태 페이지 업데이트

예시 명령:

git checkout main
git pull origin main

pnpm install --frozen-lockfile
pnpm test
pnpm build

npm version patch
npm publish --access public

릴리스 경로가 GitHub Actions 하나뿐이면, GitHub Actions 장애는 곧 여러분의 릴리스 장애입니다.

포지 대안 간단 비교

Ghostty가 어디로 갈지는 아직 정해지지 않았지만, 현실적인 선택지는 다음과 같습니다.

Forgejo

Gitea의 하드 포크
완전 FOSS
Codeberg e.V. 비영리 단체가 유지 관리
ActivityPub 기반 연합(federation)이 로드맵에 있으며 일부 진행
FOSS 프로젝트에 적합

Codeberg

비영리로 운영되는 Forgejo 호스팅 인스턴스
오픈소스 프로젝트에 무료
GitHub Actions와 동일한 수준의 대규모 CI 생태계는 아직 부족

GitLab

강력한 CI/CD
GitHub와 기능적으로 가장 가까운 대안 중 하나
상업 지원 제공
최근 라이선스 변화로 FOSS 커뮤니티에서 논쟁적

Sourcehut

이메일 기반 워크플로우
미니멀하고 빠름
사용자층은 작지만 충성도 높음
워크플로우 취향이 크게 갈림

자체 호스팅 Forgejo 또는 Gitea

최대 제어권
최대 운영 책임
백업, 업그레이드, 보안 패치, 장애 대응을 직접 관리해야 함

Radicle

P2P 기반
중앙 호스트 없음
연합성과 탈중앙화 측면에서 강함
대중적인 프로젝트에는 아직 초기 단계

핵심은 GitHub가 제공하던 전체 스택을 1:1로 대체할 완벽한 선택지는 없다는 점입니다. 그래서 점진적 마이그레이션과 미러링이 현실적인 접근입니다.

API 팀에게 적용되는 교훈

API 또는 API 도구를 만든다면 이 사건은 그대로 적용됩니다.

다음처럼 바꿔 읽으면 됩니다.

GitHub Actions → 여러분의 제품이 의존하는 상위 API
이슈/PR → 고객이 문제를 보고하는 워크플로우
포지 마이그레이션 → 공급자 전환 또는 장애 우회

질문은 같습니다.

고객 작업의 얼마만큼이 우리가 통제하지 못하는 서비스에 의존하는가?

패턴 1: 의존하는 API를 모두 모의(Mock)하기

상위 API가 멈춰도 개발, 테스트, CI는 계속 돌아가야 합니다.

예를 들어 결제 API에 의존하는 서비스라면 로컬 개발에서 실제 결제 API를 계속 호출하면 안 됩니다.

// 실제 API 호출
const response = await fetch("https://api.payment.example/charges", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.PAYMENT_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    amount: 1000,
    currency: "USD",
  }),
});

장애에 강한 구조는 환경별 base URL을 분리합니다.

const baseUrl = process.env.PAYMENT_API_BASE_URL;

const response = await fetch(`${baseUrl}/charges`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.PAYMENT_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    amount: 1000,
    currency: "USD",
  }),
});

환경별 설정:

# local
PAYMENT_API_BASE_URL=http://localhost:4010

# staging
PAYMENT_API_BASE_URL=https://sandbox.payment.example

# production
PAYMENT_API_BASE_URL=https://api.payment.example

Apidog에서는 라이브 API 테스트에 사용하는 동일한 요청/응답 정의로 모의 서버를 생성할 수 있습니다. 여러 공급자 API 형태를 비교하는 예시는 GPT-5.5 API 사용 방법을 참고하세요.

패턴 2: 여러 공급자를 대상으로 테스트하기

AI API, 결제 API, 이메일 API, 검색 API처럼 대체 공급자가 있는 영역에서는 기본 공급자 하나만 테스트하면 위험합니다.

예를 들어 AI API 래퍼를 만든다면 다음 공급자들을 같은 계약 테스트로 검증할 수 있어야 합니다.

OpenAI
Anthropic
Mistral
DeepSeek
Google
xAI

테스트 구조 예시:

const providers = ["openai", "anthropic", "mistral"] as const;

for (const provider of providers) {
  test(`${provider} returns a valid chat response`, async () => {
    const client = createClient(provider);

    const result = await client.chat({
      messages: [{ role: "user", content: "Hello" }],
    });

    expect(result.content).toBeDefined();
    expect(typeof result.content).toBe("string");
  });
}

장애 대응의 차이는 큽니다.

나쁜 상태:
OpenAI가 다운되어 우리 제품도 다운됨

좋은 상태:
OpenAI가 다운되어 Anthropic 또는 다른 공급자로 우회함

이를 가능하게 하려면 API 클라이언트를 공급자별 구현이 아니라 공통 인터페이스 뒤에 두어야 합니다.

패턴 3: 릴리스 파이프라인을 호스팅 플랫폼에서 분리하기

CI가 GitHub Actions 하나에만 묶여 있으면 Actions 장애 시 릴리스가 멈춥니다.

최소한 다음 중 하나를 준비하세요.

self-hosted runner
GitLab CI 미러
Buildkite, CircleCI 같은 보조 CI
로컬에서 실행 가능한 릴리스 스크립트
컨테이너화된 빌드 환경

예시:

./scripts/test.sh
./scripts/build.sh
./scripts/release.sh

CI 설정이 달라도 핵심 릴리스 로직은 스크립트로 분리하는 것이 좋습니다.

name: release

on:
  workflow_dispatch:

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/test.sh
      - run: ./scripts/build.sh
      - run: ./scripts/release.sh

이렇게 하면 다른 CI로 옮겨도 동일한 스크립트를 재사용할 수 있습니다.

Apidog 스타일의 탄력적인 API 워크플로우

API 팀이 상위 공급자 장애로부터 스스로를 격리하려면 다음 워크플로우가 실용적입니다.

Apidog를 다운로드합니다.
의존하는 각 상위 API마다 프로젝트를 만듭니다.
요청 및 응답 스키마를 정의합니다.
해당 스키마로 모의 서버를 생성합니다.
환경을 dev, staging, prod로 분리합니다.
자격 증명은 환경별 secret으로 관리합니다.
계약 테스트를 작성합니다.
릴리스마다 계약 테스트를 실행합니다.
상위 API 장애 시 환경을 mock으로 전환하고 개발을 계속합니다.

예시 환경 구성:

dev
- base_url: https://mock.apidog.local
- api_key: mock-key

staging
- base_url: https://sandbox.vendor.example
- api_key: staging-secret

prod
- base_url: https://api.vendor.example
- api_key: production-secret

이 패턴의 장점은 단순합니다.

로컬 개발이 외부 API 장애에 막히지 않음
CI가 외부 공급자 상태에 덜 민감함
공급자 변경 시 테스트 범위가 명확함
API 계약 변경을 조기에 발견 가능
장애 상황에서도 문서, 테스트, mock 기반 개발은 계속 가능

개발자들이 이 발표에서 읽는 것

초기 반응은 대략 네 가지입니다.

“그는 잘했다”

오랫동안 GitHub 안정성에 불만을 느낀 사용자들은 이 글을 공개적으로 문제를 말할 수 있는 신호로 받아들였습니다. 이미 두 번째 포지에 미러링하던 팀은 미러를 더 진지하게 검토하게 되었습니다.

“한 번의 장애일 뿐이다”

GitHub의 전체 가동률은 여전히 업계 주요 플랫폼과 비교 가능한 수준이라는 반응입니다. 이 주장도 일부 맞습니다. 하지만 하시모토가 본 것은 단일 장애가 아니라 반복 패턴이었습니다.

“마이그레이션은 어렵다”

이슈, PR 기록, CI, secrets, 릴리스 아티팩트를 옮겨본 팀은 마이그레이션 비용이 크다는 것을 압니다. 그래서 읽기 전용 미러와 점진적 이전은 현실적인 전략입니다.

“내 저장소도 옮겨야 하나?”

소규모 프로젝트라면 즉시 GitHub를 떠날 필요는 없을 수 있습니다. 하지만 미러링은 거의 항상 비용 대비 가치가 있습니다.

자신의 스택을 위한 체크리스트

다음 항목을 기준으로 점검하세요.

저장소

[ ] 활성 저장소를 두 번째 포지에 미러링하고 있는가?
[ ] 미러가 실제로 복구 가능한 상태인지 테스트했는가?
[ ] 기본 브랜치, 태그, 릴리스 아티팩트를 백업하는가?

CI/CD

[ ] GitHub Actions가 멈췄을 때 대체 실행 경로가 있는가?
[ ] 릴리스 스크립트가 특정 CI 문법에 묶여 있지 않은가?
[ ] self-hosted runner 또는 보조 CI를 테스트해 봤는가?

API 의존성

[ ] 중요 경로의 외부 API 목록이 있는가?
[ ] 각 API가 4시간 다운되면 어떻게 할지 문서화했는가?
[ ] mock 서버로 로컬 개발과 CI를 계속할 수 있는가?
[ ] 여러 공급자를 같은 계약 테스트로 검증하는가?

운영

[ ] 상태 페이지가 실제 장애 범위를 표시하는가?
[ ] 부분 장애와 성능 저하를 공개하는가?
[ ] 월별 인시던트 추세를 보고 있는가?
[ ] 고객 근무 시간 기준의 영향도를 측정하는가?

API 도구 관점의 더 구체적인 예시는 공급자 장애에서 살아남는 견고한 워크플로우 구축을 참고하세요. DeepSeek과 OpenAI를 이중 공급자 예시로 사용해 같은 패턴을 설명합니다.

자주 묻는 질문

Ghostty는 어디로 옮겨가나요?

하시모토는 발표 게시물에서 최종 목적지를 밝히지 않았습니다. 상업 및 FOSS 공급자 모두와 논의 중이며, 마이그레이션은 점진적으로 진행될 것이라고 했습니다. 현재 GitHub 저장소는 기존 링크와 참조가 깨지지 않도록 읽기 전용 미러로 유지됩니다.

GitHub가 그렇게 불안정한가요?

GitHub의 전체 가동률 수치는 여전히 주요 플랫폼과 경쟁 가능한 수준입니다. 하지만 2025년과 2026년에 Actions, Packages, API 표면에서 장기 장애가 여러 차례 있었습니다. 하시모토의 문제 제기는 총 가동률보다 반복적인 부분 장애가 중요 경로 사용자에게 누적된다는 점입니다.

지금 내 저장소를 GitHub에서 옮겨야 하나요?

대부분의 팀에게 즉시 이전은 과할 수 있습니다. 하지만 두 번째 포지로 미러링하는 것은 가치가 큽니다. 비용은 작고, GitHub Actions나 GitHub API 장애 시 복구 옵션을 제공합니다.

GitHub Copilot 또는 GitHub Actions 사용에도 영향이 있나요?

하시모토의 글은 특정 제품을 장기적으로 비판한 것이 아니지만, 발표 당일 직접적인 계기는 GitHub Actions 장애였습니다. Copilot은 별도 제품 표면이므로 안정성과 비용을 별도로 추적해야 합니다. 관련 내용은 팀을 위한 GitHub Copilot 사용 및 청구 API를 참고하세요.