magpie 딥다이브
— 에이전트와 AI 모델 사이에 놓는 나만의 교환국

1프로젝트 한줄 요약

magpie는 여러 코딩 에이전트가 여러 AI 제공자의 모델을 한 주소로 이용하도록 묶는 데스크톱 앱 겸 로컬 게이트웨이입니다. 사용자는 화면에서 모델을 고르고, 에이전트는 자기에게 익숙한 API로 요청합니다. 그 사이에서 magpie가 설정 변경과 요청 중계를 맡습니다.

이 레포의 핵심은 에이전트가 말하는 API와 모델 제공자가 받는 API를 분리하는 데 있습니다. 예를 들어 Claude Code가 Anthropic Messages 형식으로 보낸 요청을, 다른 제공자가 받는 OpenAI Chat 형식으로 바꾸는 경로가 실제 소스에 있습니다.

사용자가 보는 일과 내부에서 하는 일

기본 게이트웨이 주소는 127.0.0.1:3425입니다. internal/gateway/gateway.go의 DefaultAddr에서 확인할 수 있습니다. 127.0.0.1은 자기 컴퓨터를 가리키며, 기본 주소를 쓰면 다른 기기의 공개 서버로 열리는 구조는 아닙니다.

모델 계산 자체는 연결한 제공자나 별도 로컬 모델 서버가 담당합니다. 따라서 “로컬 게이트웨이”라는 말만으로 모든 프롬프트가 컴퓨터 안에 머문다고 이해하면 안 됩니다. 데이터가 전달되는 범위는 연결한 제공자와 플러그인의 처리 경로에 따라 달라집니다.

2왜 주목받는가

선정 근거는 TrendShift Monthly #10입니다. 2026-10-23 GitHub 기준으로 생성일은 2026-09-23이며, 스타 19,797개, 포크 1,502개입니다. 약 한 달 만의 규모라는 점은 확인할 수 있지만, 특정 기능이 별 증가를 일으켰다는 인과관계까지 증명하지는 못합니다.

아래 세 가지가 관심을 끌었을 이유라는 것은 README와 구현을 바탕으로 한 해석입니다. 각 요인의 기여도를 판단하려면 이용자 조사나 유입 통계가 필요합니다.

• 설정의 분산을 줄입니다. 에이전트마다 다른 JSON·TOML·YAML 설정을 하나의 선택 화면으로 다룹니다.
• 모델과 도구의 조합을 넓힙니다. 에이전트가 쓰는 API와 제공자가 받는 API가 달라도 변환 계층을 거칩니다.
• 사용 중 끊기는 문제를 다룹니다. 계정·키별 후보, 실패 후 휴식, 대체 모델, 대화 고정을 함께 구현합니다.

경쟁 제품과 비교할 때 무엇이 강점인가

CC Switch·LiteLLM과 비교할 때는 설정 연결, API 변환, 라우팅을 어느 계층에서 다루는지 살펴보세요. 아래 표는 개인 개발 환경 통합과 소스 학습의 관점에서 살펴볼 항목을 보여 줍니다.

CC Switch에서 설정을 가져오는 기능은 magpie README에도 명시되어 있습니다. 서로 겹치는 영역이 있으므로 도구 이름만 보고 구분하기보다, Server.translate(), Server.plan(), Field.Set처럼 실제 책임이 어느 계층에 있는지 비교해 보세요. 제품별 지원 범위는 각 공식 문서를 기준으로 살펴보면 됩니다.

초보자에게 이 레포가 흥미로운 이유는 화면의 클릭 하나를 파일 변경과 네트워크 동작까지 따라갈 수 있기 때문입니다.

README의 큰 약속은 현재 구현과 대조하자

README는 여러 구독을 한곳에서 사용한다고 설명하며 Grok도 예시에 넣습니다. 하지만 internal/provider/migrate.go의 retiredBuiltins에는 grok, cursor, kiro, zed 등이 있습니다. 이 구독들의 내장 처리 코드는 폐기되었고, 해당 구독은 외부 플러그인이 담당합니다.

BuiltinRetired()와 PluginServes()를 보면, 내장 코드가 계속 처리하는 것이 아니라 플러그인 경로를 사용하도록 구분합니다. 따라서 “지원”이라는 README 문구는 모든 기능이 본체에 내장되어 있다는 뜻이 아닙니다. 플러그인의 설치·인증 상태와 변경에도 영향을 받습니다.

3기술 스택 전체 지도

3-1. 백엔드와 데이터 처리

버전의 기준 파일은 루트 go.mod입니다. 언어 선언은 Go 1.26.8이며, 아래 버전은 최신 권장값이 아니라 분석 커밋에 적힌 값입니다.

SQLite 의존성이 있다고 해서 모든 상태가 SQLite에 저장되지는 않습니다. 제공자·설정·마이그레이션·대화 고정에는 JSON 파일도 등장합니다. migrations.json과 affinity.json은 각각 다른 책임의 상태입니다.

3-2. 프론트엔드와 플러그인 실행 환경

루트에는 앱용 package.json이 없습니다. 하위 테스트 fixture의 package.json을 앱의 전체 의존성으로 착각하지 않는 것이 중요합니다. 또한 내장 Go 플러그인의 수명 관리 계층 pluginrt와 외부 JS 실행 계층 plugin은 별개입니다.

3-3. 인프라·빌드·CI

4아키텍처 심화 분석

4-1. 전체 시스템 구조

그림은 핵심 흐름을 압축한 것입니다. 구독에 따라 로컬 CLI를 사용하는 별도 브리지도 있고, 본문에 없는 검색·도구·미들웨어 경로도 있습니다. 모든 요청이 무조건 같은 변환 단계를 거친다고 해석하면 안 됩니다.

시작점은 루트 main.go의 main()입니다. 본체는 cli.Main(version)에 위임하고, plugins/all의 빈 식별자 import로 내장 플러그인 등록을 일으킵니다. 처음부터 거대한 게이트웨이 파일의 첫 줄부터 읽기보다 이 입구를 확인하는 편이 좋습니다.

4-2. 패턴 ① 어댑터 + 중간 표현: 번역 규칙을 모으기

internal/gateway/gateway.go의 Server.Handler()는 실제 URL과 처리 함수를 연결합니다. 다음은 소스에서 일부 경로만 발췌한 것입니다.

mux.HandleFunc("POST /v1/chat/completions", s.handle(provider.Chat))
mux.HandleFunc("POST /v1/responses", s.handle(provider.Responses))
mux.HandleFunc("POST /v1/messages", keepsSignIn(s.handle(provider.Anthropic)))

parse()는 parseChat(), parseResponses(), parseGemini(), parseAnthropic()로 분기합니다. 그 결과는 internal/gateway/ir.go의 공통 Request입니다. 반대쪽 build()와 buildFor()는 제공자가 받는 형식으로 다시 만듭니다.

아래는 Request의 핵심 필드만 남긴 학습용 발췌입니다. 원본에는 캐시·형식·제공자별 옵션 등 더 많은 필드가 있습니다.

// internal/gateway/ir.go의 필드 일부
type Request struct {
    Model      string
    System     string
    Messages   []Message
    Tools      []Tool
    ToolChoice string
    MaxTokens  int
    Stream     bool
}

Part는 텍스트·이미지·파일·도구 호출·도구 결과·추론 블록을 나누어 담습니다. 도구 호출에는 ID, Name, Args가 있고, 결과에는 CallID가 있습니다. 따라서 단순히 content 문자열만 복사하는 번역으로는 에이전트의 도구 왕복을 보존할 수 없습니다.

응답 쪽도 Event를 공통 언어로 씁니다. KText는 본문 조각, KToolStart는 도구 시작, KToolArgs는 아직 완성되지 않은 인자 조각입니다. decoder()가 제공자별 이벤트를 읽고 encoder()가 호출자의 형식으로 내보냅니다.

Server.translate()는 호출자가 완성 응답을 원해도 제공자에게는 스트리밍을 요청합니다. 호출자가 스트리밍을 원하면 streamTranslated()로 가고, 아니면 이벤트를 수집해 완성 응답을 만듭니다. 제공자가 stream:true를 무시한 경우를 감지하는 오류 경로도 있습니다.

설계의 대가: 공통 자료형을 만든다고 API 차이가 사라지지는 않습니다. Part.Sealed와 SealedBy는 특정 API가 봉인한 추론 데이터를 구분합니다. 현재 사용자 메시지의 이미지가 변환할 수 없는 형태라면 translate()에서 400으로 거절하는 경우도 있습니다. “형식 호환”과 “기능을 모두 동일하게 재현”은 구별해야 합니다.

4-3. 패턴 ② 전략 + 상태: 고르는 일과 실패 처리를 분리하기

internal/routes/routes.go의 Strategy는 후보 순서를 반환합니다. Seat는 사용률·갱신 시각·가중치·휴식 여부 등 순서를 정할 자료를 담습니다. 반면 후보를 만드는 일과 실제 재시도는 게이트웨이에 남겨 둡니다.

// internal/routes/routes.go의 인터페이스 핵심
Order func(pool string, seats []Seat) []int

// 예: 세 후보의 우선순위가 두 번째, 첫 번째, 세 번째라면
[]int{1, 0, 2}

Register()는 전략을 등록하고 해제 함수를 돌려줍니다. plugins/rotation/rotation.go는 등록 결과를 c.OnDispose()에 연결합니다. 기능이 꺼질 때 등록도 해제되도록 생명주기를 묶는 방식입니다.

Apply()는 반환값이 모든 인덱스를 한 번씩 포함하는 순열인지 검사합니다. 중복·누락·범위 초과 또는 panic이 있으면 원래 순서로 복구합니다. 이것은 인증을 생략한다는 뜻이 아니라, 정렬 기능의 실패 때문에 후보 자체를 잃지 않도록 한다는 뜻입니다.

internal/routes/strategies.go의 Smart는 단순한 무작위 분배가 아닙니다. 사용률 구간을 나누고, 여유 있는 계정 중 큰 한도 창의 갱신 시각을 우선합니다. 갱신 시각 비교는 시간 단위로 묶으며, LowShare는 90입니다. 잔량을 아직 모르지만 응답에서 배울 수 있는 계정을 먼저 탐색하는 규칙도 있습니다.

여기서 요청 한 번과 모델 제공자 호출 시도 한 번은 다릅니다. 후보가 실패하면 하나의 요청 안에서도 여러 시도가 기록될 수 있습니다. internal/gateway/fallback.go는 이미 사용자에게 보낸 응답을 두 모델의 반쪽 답변으로 섞지 않도록 경계를 둡니다. 1분 휴식은 일반 실패의 기본값이며, 모든 한도·오류를 무조건 1분으로 처리한다는 뜻은 아닙니다.

재시도의 핵심은 몇 번 더 부르느냐보다 어느 시점까지 답변을 바꿔도 되는지 정하는 것입니다.

4-4. 패턴 ③ 형식 보존 편집 + 안전한 저장

internal/gui/api.go의 POST /api/set 처리기는 agent.Find() → a.Field() → a.Pick() 순서로 선택을 넘깁니다. internal/agent/agent.go의 Field에는 Get, Set, Options 함수가 있습니다. 화면은 각 에이전트의 파일 문법을 직접 알 필요가 없습니다.

internal/agent/codex.go는 Codex의 TOML 키를 연결하고, internal/edit/json.go의 SetJSON()은 필요한 키를 수정한 뒤 저장합니다. 객체 전체를 다시 직렬화해 파일을 통째로 정렬하는 것보다 주석·들여쓰기·키 순서를 보존하는 데 초점을 둡니다.

internal/edit/file.go의 WriteAtomic()은 대상 경로 확인, BOM 보존, 파일 권한 보존, 같은 디렉터리의 임시 파일 생성, steady.Sync(), steady.Rename() 순서로 일반 파일을 교체합니다. JSON 편집의 keepCRLF()는 원본이 일관된 CRLF일 때 그 줄바꿈을 유지합니다.

중요한 예외도 소스에 있습니다. 심볼릭 링크는 링크가 가리키는 파일을 수정합니다. 하드 링크는 다른 이름과의 연결을 유지하려고 writeInPlace()로 덮어쓰는 경로가 있으며, 이 경로는 원자적이지 않습니다. 대신 새 내용을 동기화한 임시 파일을 먼저 남깁니다.

4-5. 패턴 ④ 별도 프로세스 + 흐름 제어

internal/plugin/host.go의 startOn()은 Bun으로 호스트를 시작하고 StdinPipe(), StdoutPipe()를 연결합니다. Go와 JS는 요청 ID가 있는 줄 단위 JSON 메시지를 주고받습니다. 바이너리 응답 조각은 메시지의 Data와 디코딩된 바이트로 관리됩니다.

독립 프로세스라고 자동으로 신뢰할 수 있는 샌드박스가 되지는 않습니다. 여기서 주목할 것은 느린 소비자 때문에 전체 플러그인 통신이 막히지 않게 하는 설계입니다. 각 호출은 큐와 상태를 가지며, call.push()가 받은 조각을 관리합니다.

// internal/plugin/host.go의 기본값
streamWindow = 512 << 10  // 호출별 크레딧: 512 KiB
streamBudget = 64 << 20   // 스트림 윈도 전체 예산: 64 MiB
maxFrame     = 64 << 10   // 조각 크기 상한: 64 KiB
frameOverhead = 2048       // 조각 메타데이터도 비용에 포함

자식 프로세스는 받은 크레딧 범위에서 조각을 보내고, 소비자가 읽으면 여유를 돌려받습니다. 크레딧을 초과한 응답은 프로토콜 위반으로 처리합니다. maxWireLine은 끝없이 길어지는 메시지를 막고, 헤더 수·크기에도 별도 상한이 있습니다.

internal/plugin/host.js의 pump()는 출력 큐를 비우며, 표준 출력의 write()가 가득 찼다고 알리면 waitDrain()으로 기다립니다. false가 “그 줄을 못 썼다”는 뜻은 아니므로 같은 줄을 다시 보내지 않는다는 점도 주석에 드러납니다.

2026-10-28 재검토: 구독 계정 탐색을 끄는 경계

고정 소스 27bf14790f08b1fd12a354fbdebedf692420894b의 README와 internal/provider/discovery.go는 구독 계정 탐색을 별도 선택으로 둡니다. 기본 동작에서는 에이전트의 기존 로그인 정보를 찾지만, Settings → Privacy의 Subscription accounts를 끄거나 아래 설정을 쓰면 자격증명 파일·Keychain과 구독 계정을 읽는 경로를 차단합니다.

# 프로젝트 문서의 설정 예시. 이번 분석에서 실행하지 않았습니다.
magpie accounts discovery off
# 한 실행에서만 끄는 환경 변수
MAGPIE_NO_ACCOUNTS=1

settings.AccountDiscoveryOffIn은 저장된 NoAccountDiscovery와 환경 변수를 함께 확인하고, readAccountFile은 탐색이 꺼졌으면 파일을 읽기 전에 오류를 반환합니다. API 키 제공자는 계속 쓸 수 있고, 이미 저장된 magpie 자체 로그인 자료는 삭제하지 않고 읽기·쓰기를 중지합니다. 저장된 자료 삭제와 탐색 중지는 다른 동작입니다.

실습은 settings/accounts.go → provider/discovery.go를 읽고, 자격증명 파일을 읽기 전 검사와 UI 설정의 관계를 그려 보는 것으로 시작합니다. 에이전트 설정·구독 계정·외부 모델을 실제로 실행한 분석은 아닙니다.

근거: 탐색 설정 판정 · 파일 읽기 경계. 아래 초판의 세부 프로토콜 예시는 당시 커밋 65e8040 기준으로 남깁니다.

5디렉토리 구조 해부

이 트리는 학습에 필요한 항목만 추린 것입니다. Go는 internal/의 패키지를 그 부모 디렉터리 트리 안에서만 import하도록 제한합니다. 이 레포의 대부분은 외부 공개 라이브러리보다 앱 내부의 책임 단위로 나뉩니다.

코드 규모

저장소 루트(.) 아래 파일의 LF 바이트 수를 기준으로 한 규모입니다. .git/은 제외했고, 테스트·fixture·생성 코드·사이트는 포함했습니다. 따라서 주석·빈 줄을 뺀 순수 로직 줄 수나 GitHub 언어 비율과는 다릅니다.

Go에서 _test.go를 제외하면 317,845줄입니다. Go 테스트는 약 55.1%이며, 이 비율은 코드 커버리지나 품질 점수가 아닙니다. 파일 개수와 줄 수만으로 학습 부담이나 안정성을 판단하지 않는 것이 좋습니다.

# 저장소 루트에서 같은 기준으로 세는 읽기 전용 명령
python3 - <<'PY'
from pathlib import Path
files = [p for p in Path('.').rglob('*.go') if '.git' not in p.parts]
print(len(files), sum(p.read_bytes().count(b'\n') for p in files))
PY

internal/gateway/gateway.go 하나도 7,065줄입니다. 처음에는 internal/gateway/ir.go → Handler() → parse() → translate() 순서로 읽고, 그다음 internal/gateway/fallback.go로 이동하세요. 이름을 검색해 작은 범위씩 확인하는 습관이 큰 레포를 읽는 기술입니다.

6학습 포인트 (기술별)

Go와 HTTP: URL에서 처리 함수까지

Server.Handler()에서 http.NewServeMux()와 메서드가 포함된 패턴을 읽습니다. s.handle(provider.Chat)처럼 프로토콜을 전달해 처리 함수를 만드는 방식은 비슷한 엔드포인트의 공통 동작을 묶는 사례입니다.

작은 실습: POST /v1/responses를 찾아 handle() → serve() → attempt()로 이어지는 호출 지도를 적습니다. 그다음 translate()가 필요한 경우와 그대로 전달할 수 있는 경우를 구분합니다.

자료형 설계: 문자열 하나로 표현하지 않기

internal/gateway/ir.go의 Message, Part, Event를 보면서 사용자 본문, 추론, 도구 호출, 도구 결과가 왜 다른 종류인지 생각합니다. 특히 도구 호출 ID와 결과의 CallID가 맞아야 대화의 관계가 보존됩니다.

작은 실습: “파일 읽기 도구를 요청 → 도구가 내용을 반환 → 모델이 요약”을 텍스트 세 줄이 아닌 구조화된 표로 그려 보세요. 각 단계의 역할·호출 ID·내용 종류를 열로 두면 무엇을 잃으면 안 되는지 보입니다.

스트리밍과 동시성: 응답은 여러 조각으로 도착한다

internal/gateway/gateway.go의 decoder()·encoder()와 internal/plugin/host.go의 큐·잠금·취소 처리를 연결해 읽습니다. 하나의 도구 인자 JSON이 여러 이벤트에 나뉘어 올 수 있고, 소비자가 느리거나 연결을 끊는 경우도 따로 다뤄야 합니다.

작은 실습: 본문 이벤트, 오류 이벤트, 사용량 이벤트를 각각 하나씩 종이에 적고 “이미 화면에 표시한 내용”과 “아직 내부에만 있는 내용”을 다른 칸에 놓습니다. 어느 칸까지는 다른 모델로 재시도할 수 있는지 설명해 보세요.

설정 파일: 파싱 성공과 사용자 경험은 다르다

edit.SetJSON(), keepCRLF(), WriteAtomic()를 읽으면 데이터 값이 맞는 것만으로는 충분하지 않다는 사실이 보입니다. 사람은 주석·줄바꿈·권한·링크 관계도 설정의 일부로 사용합니다.

작은 실습: internal/edit/crlf_json_test.go, internal/edit/bom_test.go, internal/edit/hardlink_test.go에서 입력·기대한 결과·실패 조건을 하나씩 뽑습니다. 운영체제가 달라질 때 같은 “저장”에 어떤 추가 조건이 붙는지 정리합니다.

웹 UI: 프레임워크가 없어도 상태의 경계는 필요하다

internal/gui/assets/app.js에는 state, prefs, providers, pick처럼 목적이 다른 상태가 있습니다. 화면 상태가 서버의 영속 데이터와 같은 것은 아닙니다. 서버의 POST /api/set까지 함께 읽어야 실제 변경 경계가 보입니다.

작은 실습: 모델 선택 창이 열리는 순간부터 서버 응답을 받아 화면이 바뀌는 순간까지 “사용자 입력 → 임시 선택 → 저장 요청 → 서버 상태” 네 칸으로 나눕니다. 저장 실패 시 어떤 칸을 복원해야 할지도 적습니다.

이 프로젝트에서 배울 것은 특정 라이브러리의 문법보다 입력·상태·부작용의 경계를 나누는 방법입니다.

테스트 읽기: 성공 사례보다 불변 조건 찾기

internal/routes/routes_test.go의 TestApplyFailsOpen()은 panic, 짧은 배열, 중복, 범위 초과, 음수, nil을 다룹니다. 각 예외를 암기하기보다 “정렬 전략이 망가져도 유효한 후보를 잃지 않는다”는 공통 조건을 찾으세요.

CI도 플랫폼마다 같은 검사를 한다고 단정하면 안 됩니다. .github/workflows/test.yml은 Windows에서 전체 테스트를 컴파일하고 일부 네이티브 검사를 따로 실행합니다. 선언된 행렬과 실제 실행 단계를 구분해서 읽는 것 역시 학습 포인트입니다.

7하드웨어 / 시스템 요구사항

원격 API를 중계하는 magpie 자체와 로컬에서 모델을 계산하는 서버는 서로 다른 자원을 요구합니다. 소스의 설정값만으로 처리량, 실제 메모리 사용량, 권장 CPU 코어 수를 산정할 수는 없습니다.

숫자를 잘못 읽기 쉬운 세 지점

• streamBudget = 64 << 20은 플러그인 호스트의 스트림 윈도 예산입니다. 프로세스 전체가 RAM 64 MiB로 동작한다는 뜻이 아닙니다.
• EXPOSE 3425 3430은 이미지의 포트 선언입니다. 그 자체로 호스트에 포트를 공개하는 명령이 아닙니다.
• CGO_ENABLED=0은 CLI 빌드의 C 연결을 끕니다. Bun·외부 CLI·네트워크 같은 선택 기능의 요구까지 없애지는 않습니다.

자원 계획을 한다면 먼저 원격 API 중계만 쓰는지, 플러그인과 구독 CLI도 쓰는지, 로컬 추론 서버도 같은 컴퓨터에서 돌리는지를 나누어야 합니다. 이 글의 수치는 앱 전체의 최소 RAM·디스크 요구량을 뜻하지 않습니다.

8직접 해볼 수 있는 실습 과제

아래 과제는 읽기와 문서 작성만으로 수행할 수 있는 소스 독해 실습입니다. 설치나 실제 모델 호출 없이 코드와 테스트의 조건을 따라가 보세요. 설계 설명은 docs/subsystems/에서, 구현과 테스트는 internal/에서 찾아볼 수 있습니다.

[]int{2, 0, 1}
[]int{2, 2, 0}
[]int{0, 1}
[]int{-1, 0, 1}

좋은 독해 실습은 함수를 찾는 데서 끝나지 않고 정상 동작과 버그를 가르는 조건을 결과물로 남깁니다.

9관련 기술 심화 학습 로드맵

아래 시간은 공식 교육 과정이나 숙련도 보장이 아닌 학습 계획 예시입니다. 매주 읽을 범위를 좁히고, 설명 자료 한 장을 만드는 것을 목표로 합니다.

Go가 처음이라면 1주차 전에 struct, 슬라이스, 함수 값, 포인터, error, defer를 먼저 익히세요. goroutine과 채널을 모른 채 플러그인 호스트부터 읽으면 통신 규약보다 문법에 막히기 쉽습니다.

각 주의 마무리는 코드 요약 대신 “이 경계가 없다면 어떤 문제가 생길까?”를 쓰는 것입니다. 예를 들어 IR이 없으면 변환 규칙이 중복되고, 응답 공개 경계가 없으면 서로 다른 모델의 답이 섞일 수 있습니다.

한 번에 레포 전체를 이해하려 하지 말고 한 요청의 정상 경로를 그린 뒤 실패 경로를 하나씩 붙이세요.

10핵심 키워드 사전

11참고 링크

공식 저장소·문서

• yetone/magpie — 소스 저장소
• 분석 커밋의 파일 트리 — 이 글의 파일 경로 기준
• 분석 시점 README — 제품 설명과 사용 예시
• 공식 시작 문서 — 배포판을 사용할 때의 안내. 내용은 이후 바뀔 수 있음
• 커밋에 고정된 참조 문서 — 빌드·연결·운영 옵션
• 서브시스템 설계 목차 — 라우팅·플러그인·GUI·설정 연결의 책임
• v0.1.1330 릴리스 — 2026-10-23 GitHub 기준 최신 버전. 배포 저장소는 본체와 별도
• 커뮤니티 플러그인 저장소 — 본체에서 이전한 구독 기능 등
• TrendShift — 2026-10-23 Monthly #10 선정 정보의 출처

핵심 소스 바로 읽기

• go.mod — 언어·의존성 버전
• internal/gateway/ir.go — 요청·메시지·이벤트의 공통 모양
• internal/gateway/gateway.go — Handler·parse·build·translate
• internal/gateway/fallback.go — 후보 계획과 응답 공개 경계
• internal/gateway/affinity.go — 계정 고정과 캐시 유지
• internal/routes/routes.go — 전략 등록·해제와 결과 검증
• internal/edit/file.go — WriteAtomic과 하드 링크 예외
• internal/plugin/host.go — Go 쪽 플러그인 통신과 크레딧
• internal/provider/migrate.go — 폐기된 내장 구독과 플러그인 담당 구분
• internal/gateway/plugin_workdir_test.go — 최신 커밋의 재시도 검증 사례
• .github/workflows/test.yml — 플랫폼별 실제 검사 범위
• Dockerfile — 이미지·사용자·볼륨·포트 구성

관련 기술의 공식 학습 자료

아래 링크는 개념을 더 공부할 출발점입니다. 이 글의 버전·설정값은 커밋 65e8040을 기준으로 합니다.

• A Tour of Go — 구조체·슬라이스·함수·동시성 기초
• Go net/http — 요청·응답·ServeMux
• Go embed — 정적 파일 포함
• Go 데이터 경쟁 검사 안내 — CI의 race 검사를 이해할 배경
• Wails v3 문서 — Go와 운영체제 웹뷰를 연결하는 데스크톱 앱
• Bubble Tea — 터미널 UI의 상태·메시지·갱신 구조
• Bun 문서 — 외부 JS 플러그인의 실행 환경
• MDN SSE 안내 — 서버가 이벤트를 연속 전송하는 방식
• Playwright 문서 — 브라우저 UI 검증의 배경
• MCP 공식 문서 — 에이전트와 외부 도구 연결 규약

초판 관측표 (2026-10-23, 현재 수치 아님)