BYOK(Bring-your-own-model)은 컨트롤 플레인(control plane)의 문제다

GitHub은 이번 주 Copilot 앱에 BYOK 지원을 추가했습니다. 제가 생각하기에 지루한 부분은 이제 개발자들이 코딩 에이전트(coding agent)를 더 많은 모델로 연결할 수 있게 되었다는 점입니다.

흥미로운 부분은 그 다음에 일어날 일입니다.

BYOK는 'Bring your own key(자신의 키를 가져오기)'를 의미합니다. GitHub의 경우, 이제 Copilot 앱이 기본 Copilot 경험 외부의 모델 제공업체 및 엔드포인트(endpoints)를 사용할 수 있습니다. 여기에는 OpenAI, Azure OpenAI, Microsoft Foundry, Anthropic, LM Studio, Ollama 및 OpenAI 호환 API가 포함됩니다.

이것은 자유처럼 들립니다.

자유가 맞습니다.

하지만 이는 동시에 "어떤 모델을 사용해야 하는가?"라는 질문이 "누가, 어떤 작업을 위해, 누구의 예산으로, 어떤 로그를 남기며, 어떤 지원 계약 하에 어떤 모델을 사용할 수 있는가?"라는 질문보다 훨씬 덜 중요해지는 순간이기도 합니다.

모델 선택은 운영(operations)의 문제가 되고 있습니다.

모델은 더 이상 경계가 아니다

한동안 코딩 어시스턴트(coding assistant)에 대한 논쟁은 대부분 모델에 관한 논쟁이었습니다.

어떤 모델이 Python을 더 잘 작성하는가? 어떤 모델이 대규모 리포지토리(repos)를 더 잘 처리하는가? 어떤 모델이 테스트에 더 뛰어난가? 어떤 모델이 지시사항을 더 잘 따르는가? 어떤 모델이 더 저렴한가? 어떤 모델이 에디터에서 덜 짜증 나게 느껴지는가?

이러한 질문들은 여전히 중요합니다. 개발자들은 계속해서 의견을 가질 것이고, 그 의견 중 일부는 옳을 것입니다.

하지만 에이전트가 여러 제공업체, 클라우드 엔드포인트, 로컬 서버 및 OpenAI 호환 게이트웨이(gateways)를 가리킬 수 있게 되면, 모델은 더 이상 제품의 깔끔한 경계가 아닙니다.

경계가 위로 이동합니다.

이제 코딩 에이전트는 모델 컨트롤 플레인(model control plane)의 클라이언트입니다. 에이전트에는 라우팅(routing)이 필요합니다. 정책(policy)이 필요합니다. 자격 증명(credentials)이 필요합니다. 비용 청구 귀속(billing attribution)이 필요합니다. 로그(logs)가 필요합니다. 데이터 이동에 관한 규칙이 필요합니다. 어떤 작업에는 로컬 Ollama 모델이 허용되고, 다른 작업에는 호스팅된 엔터프라이즈 엔드포인트가 필요한지를 결정할 누군가가 필요합니다.

이것은 "이 리팩터링(refactor)에는 Claude가 더 나은 느낌이었어"라는 대화와는 다른 차원의 이야기입니다.

이는 API 관리(API management)에 더 가깝지만, API 호출자가 당신의 코드를 편집하고, 명령을 실행하며, 개인적인 컨텍스트(context)를 요약하고, 때로는 풀 리퀘스트(pull requests)를 생성할 수 있다는 점이 다릅니다.

자신의 키를 가져온다는 것은 자신의 혼란을 가져온다는 의미다

저는 BYOK를 좋아합니다.

특히 이미 모델 인프라를 갖춘 팀들에게는 더욱 그렇습니다. 적절한 데이터 제어(data controls) 기능을 갖춘 Azure OpenAI 배포 환경을 가진 기업이라면, 이를 활용할 수 있어야 합니다. 개발자가 리스크가 낮은 작업을 위해 로컬 모델(local model)을 대상으로 실험하고 싶다면, 이는 유용할 수 있습니다. 플랫폼 팀이 비용 제한, 로깅(logging), 레드액션(redaction), 프로바이더 라우팅(provider routing) 기능을 갖춘 게이트웨이(gateway)를 운영하고 있다면, 코딩 에이전트(coding agent)가 주변의 모든 환경을 강제해서는 안 됩니다.

유연성은 좋습니다.

하지만 운영상의 혼란이 뒤따릅니다.

누구의 키(key)가 사용되는가? 개인 개발자 키인가? 팀 키인가? 서비스 계정(service account)인가? 중앙에서 관리되는 토큰(token)인가? 키가 로테이션(rotate)되는가? 에이전트가 키를 저장하는가? 로그에 유출될 수 있는가? 모든 리포지토리(repository)에서 사용될 수 있는가? 프로바이더(provider)가 프롬프트(prompt)를 보는가? 프롬프트에 고객 데이터, 미발표 제품 계획, 비공개 코드, 비밀(secrets), 또는 장애(incident) 상세 정보가 포함되어 있는가?

이것들은 이론적인 플랫폼 팀의 질문이 아닙니다. 실제 기업에서 이를 운영할 때 마주하게 될 첫 한 시간 동안의 질문들입니다.

동일한 워크플로우(workflow)라도 엔드포인트(endpoint)에 따라 리스크가 매우 다를 수 있습니다.

테스트 헬퍼(test helpers)의 이름을 바꾸기 위해 로컬 모델을 사용하는 것과, 프로덕션 장애(production incident) 기록, 비공개 리포지토리 컨텍스트(context), 그리고 데이터베이스 스키마(database schema)를 무작위의 OpenAI 호환 엔드포인트로 보내는 것은 전혀 다른 문제입니다. 기업에서 승인한 모델에게 마이그레이션(migration) 검토를 요청하는 것은 또 다른 문제입니다.

BYOK는 이러한 차이점들을 없애지 않습니다.

오히려 그것들을 가시화할 뿐입니다.

프로바이더 선택에는 느낌(vibes)이 아닌 정책이 필요하다

BYOK의 나쁜 버전은 모든 팀이 '느낌(vibes)'에 따라 프로바이더를 선택하는 것입니다.

어떤 팀은 비용이 저렴하다는 이유로 로컬 모델을 사용합니다. 다른 팀은 편리하다는 이유로 가장 큰 호스팅 모델(hosted model)을 사용합니다. 세 번째 팀은 아무도 존재를 모르는 게이트웨이를 통해 라우팅합니다. 네 번째 팀은 공식적인 경로가 너무 느리다는 이유로 업무가 몰리는 시기에 개인 계정을 사용합니다.

그러고 나서 6개월 뒤, 엔지니어링 리더십은 비용을 파악하고 싶어 하고, 보안 팀은 데이터 흐름을 파악하고 싶어 하며, 법무 팀은 벤더 노출(vendor exposure)을 파악하고 싶어 하고, 플랫폼 팀은 왜 버그 리포트 재현이 불가능한지 알고 싶어 하게 됩니다.

행운을 빕니다.

유용한 버전은 지루하고 명시적입니다.

몇 가지 예시는 다음과 같습니다:

문서화 전용 (documentation-only) 작업은 더 저렴하거나 로컬 모델을 사용할 수 있습니다.
민감한 리포지토리 (repositories)에서의 코드 생성은 승인된 엔터프라이즈 엔드포인트 (enterprise endpoints)를 사용해야 합니다.
운영 장애 (production incident) 대응 작업은 회사가 승인한 경계를 벗어날 수 없습니다.
오픈 소스 (open-source) 유지보수는 프라이빗 제품 작업과는 다른 예산 및 제공업체 정책을 사용할 수 있습니다.
고가의 모델은 개인의 선호도가 아닌 작업 카테고리 (task category)를 필요로 합니다.
모델 선택은 에이전트 세션 (agent session), 브랜치 (branch), 또는 풀 리퀘스트 (pull request)에 기록됩니다.

이 중 그 어떤 것도 거대한 거버넌스 (governance) 의식을 요구하지 않습니다.

다만 조직이 모델 선택이 이제 엔지니어링 정책 (engineering policy)의 일부임을 인정해야 할 뿐입니다.

개발자가 추측해야 하는 상황이 발생해서는 안 됩니다.

로컬 모델이 자동으로 프라이빗한 것은 아니다

이 과정에서 Ollama와 LM Studio 부분은 특히 흥미로운데, 로컬 모델이 프라이버시 친화적인 해답처럼 느껴지기 때문입니다.

때로는 실제로 그렇기도 합니다.

로컬 모델을 실행하면 프롬프트 (prompts)를 외부 제공업체로부터 격리할 수 있습니다. 비용을 절감할 수 있습니다. 실험 속도를 높일 수 있습니다. 간단한 코드 검색, 명명 (naming), 요약 (summarization), 또는 저위험 스캐폴딩 (scaffolding) 작업에 적합할 수 있습니다.

하지만 "로컬"이 "안전"과 동일한 의미는 아닙니다.

로컬 모델도 여전히 컨텍스트 (context)가 필요합니다. 에이전트는 여전히 파일을 읽습니다. 여전히 명령어를 실행할 수 있습니다. 여전히 사람이 병합할 코드를 생성할 수 있습니다. 여전히 도구 (tools)에 연결될 수 있습니다. 여전히 구식일 수 있고, 특정 언어에 취약하거나, 리포지토리 지침을 따르는 능력이 떨어질 수 있습니다.

그리고 로컬 모델 사용은 종종 관찰 가능성 (observability)이 더 낮습니다.

공식 호스팅 엔드포인트 (hosted endpoint)가 에이전트 세션, 모델 선택, 크레딧 사용량, 도구 호출 (tool calls)을 기록하는 반면, 로컬 경로는 중앙 집중적인 흔적을 거의 남기지 않는다면, 프라이버시의 이득은 감사 (audit)의 손실과 함께 올 수 있습니다.

이것이 로컬 모델이 나쁘다는 뜻은 아닙니다.

단지 팀이 로컬 추론 (local inference)이 어디에 적합한지 결정해야 한다는 의미입니다.

어떤 작업에서는 "외부 제공자가 이 프롬프트를 보지 않았다"는 점이 가장 중요한 속성입니다. 다른 작업에서는 "에이전트가 왜 이러한 변경을 수행했는지 재구성할 수 있다"는 점이 더 중요합니다. 때로는 두 가지 모두가 필요하며, 바로 그 지점에서 플랫폼 작업이 본격적으로 중요해집니다.

지원(support)이 기묘해진다

BYOK는 또한 사람들이 과소평가하는 방식으로 지원(support)의 양상을 변화시킵니다.

에이전트가 제대로 작동하지 않을 때, 그 버그의 책임은 누구에게 있을까요?

만약 Copilot 앱이 기본 제공자(default provider)로 라우팅된다면, 지원 경로가 적어도 어느 정도는 명확합니다. 하지만 동일한 앱이 기업용 Azure 배포 환경, Foundry 모델, Anthropic, LM Studio를 통한 로컬 모델, 또는 OpenAI 호환인 척하는 회사의 프록시(proxy)로 라우팅된다면, 문제는 훨씬 더 복잡해집니다.

실패의 원인이 에이전트 UI였을까요? 리포지토리(repository) 지침이었을까요? 모델이었을까요? 제공자 엔드포인트(provider endpoint)였을까요? 게이트웨이(gateway)였을까요? 속도 제한(rate limit)이었을까요? 정책 필터(policy filter)였을까요? 오래된 로컬 모델이었을까요? 도구 권한(tool permission)이었을까요? 프롬프트 변환(prompt transformation)이었을까요? 누락된 시스템 지침(system instruction)이었을까요?

이것이 바로 에이전트 세션 메타데이터(agent session metadata)가 중요한 이유입니다.

플랫폼은 개발자에게 Slack에 스크린샷을 붙여넣으라고 요청하지 않고도 다음과 같은 기본적인 질문에 답할 수 있어야 합니다:

어떤 모델이 작업을 처리했는가
어떤 엔드포인트(endpoint)가 사용되었는가
어떤 ID(identity)가 비용을 지불했는가
어떤 리포지토리(repository)와 브랜치(branch)가 관여되었는가
어떤 도구(tools)가 활성화되었는가
어떤 지침(instructions)이 로드되었는가
어떤 명령(commands)이 실행되었는가
어떤 사람이 최종 변경 사항을 승인했는가

이것은 화려한 AI 제품 개발 작업은 아닙니다.

이것은 지원 가능성(supportability)입니다.

그리고 코딩 에이전트가 일반적인 개발 인프라가 되려 한다면, 지원 가능성(supportability)은 선택 사항이 아닙니다.

모델 이식성(model portability)은 워크플로 이식성(workflow portability)이 아니다

OpenAI 호환 엔드포인트(OpenAI-compatible endpoints)는 유용하지만, 호환성이라는 점이 중요한 차이점들을 숨길 수 있습니다.

두 제공업체가 동일한 요청 형태(request shape)를 수락하더라도 도구 사용(tool use), 컨텍스트 제한(context limits), 구조화된 출력(structured output), 지연 시간(latency), 안전 거부(safety refusals), 비용(cost), 캐싱(caching), 그리고 지시 이행(instruction following) 측면에서 여전히 다르게 동작할 수 있습니다. 로컬 모델(local model)이 어떤 리포지토리(repo)에는 적합할 수 있지만, 다른 리포지토리에는 사용할 수 없을 수도 있습니다. 작은 모델(small model)이 단위 테스트 생성 워크플로우(unit-test generation workflow)는 통과할 수 있어도, 교차 서비스 마이그레이션(cross-service migration)에서는 처참하게 실패할 수도 있습니다.

따라서 플랫폼은 "엔드포인트가 작동한다"는 수준에서 멈춰서는 안 됩니다.

질문은 "워크플로우가 작동하는가"입니다.

이 모델이 이 리포지토리의 지침을 따를 수 있는가? 리뷰어가 수용할 수 있는 패치(patches)를 생성하는가? 도구를 너무 공격적으로 호출하는가? 실패하는 테스트를 무시하는가? 재시도(retries)에 시간을 허비하는가? 리뷰에 충분히 좋은 설명을 생성하는가? 팀이 실제로 사용하는 언어와 프레임워크를 처리할 수 있는가?

이것이 바로 진지한 팀들이 실제 엔지니어링 워크플로우를 중심으로 모델 평가(model evaluations)를 구축해야 하는 지점입니다.

일반적인 벤치마크(benchmark) 숭배가 아니라 말입니다.

실제 작업들:

이 의존성(dependency)을 안전하게 업그레이드하기
이 불안정한 테스트(flaky test) 수정하기
누락된 이 통합 테스트(integration test) 작성하기
동작을 변경하지 않고 이 핸들러(handler) 리팩터링하기
로그와 코드를 통해 이 장애(incident) 설명하기
우리의 로컬 표준을 사용하여 이 풀 리퀘스트(pull request) 리뷰하기

그렇게 된다면 모델 선택은 커뮤니티 포럼에 기반하는 대신 증거에 기반할 수 있게 됩니다.

내가 가장 먼저 할 일

만약 내가 회사 내부에서 이를 도입한다면, 작게 시작할 것입니다.

첫째, 리포지토리의 민감도와 작업 유형에 따라 승인된 모델 경로(model routes)를 정의하겠습니다. 수백 개의 규칙이 아니라, 명백한 사례들을 명확하게 구분할 수 있을 정도면 충분합니다.

둘째, 작업 기록에 모델 선택 사항이 보이도록 하겠습니다. 모든 에이전트 세션(agent session)에는 제공업체(provider), 엔드포인트 클래스(endpoint class), 모델(model), ID(identity), 비용 범주(cost bucket), 그리고 이를 허용한 정책(policy)이 표시되어야 합니다.

셋째, 중요한 업무에는 개인 키(personal keys) 사용을 피하겠습니다. 개인 키는 편리하지만, 감사(audit), 교체(rotation), 장애 대응(incident response), 그리고 비용 귀속(cost attribution)을 위한 기초로서는 최악입니다.

넷째, 개발자들에게 실험을 위한 잘 닦인 경로(paved path)를 제공하겠습니다. 만약 공식적인 답변이 너무 제한적이라면, 사람들은 이를 우회할 것입니다. 저위험 상황(low-risk contexts)에서는 로컬 모델이나 대안 모델을 시도할 수 있게 하되, 그 경계는 명확히 설정해야 합니다.

마지막으로, 모델에 대한 팬덤(fandom)이 아니라 워크플로우(workflow)를 기준으로 결과를 측정하겠습니다. 더 저렴한 모델이 종속성 업데이트(dependency bumps)를 잘 처리한다면 그것을 사용하십시오. 더 비싼 모델이 더 나은 디자인 리뷰(design reviews)를 생성한다면, 그만한 가치가 있을 것입니다. 로컬 모델이 비용은 절감하지만 리뷰 시간을 두 배로 늘린다면, 그 비용 또한 실질적인 비용입니다.

중요한 것은 트레이드오프(tradeoff)를 가시화하는 것입니다.

결론 (the punchline)

GitHub Copilot 앱의 BYOK 지원은 좋은 기능입니다. 개발자와 플랫폼 팀은 영원히 하나의 고정된 제공자 경로만을 수용하는 대신, 기존의 모델 투자 자산을 코딩 도구로 가져올 수 있어야 합니다.

하지만 코딩 에이전트(coding agents)가 다양한 모델 백엔드(model backends)를 사용할 수 있게 되면, 어려운 점은 더 이상 모델 접근성(model access) 문제가 아닙니다.

어려운 점은 컨트롤(control)입니다.

누가 어떤 모델을 사용할 수 있는가? 어떤 데이터가 머신을 벗어날 수 있는가? 민감한 작업을 위해 승인된 엔드포인트(endpoint)는 무엇인가? 비용 지출은 어떻게 귀속되는가? 세션은 어떻게 감사(audit)되는가? 지원 팀은 장애를 어떻게 디버깅(debug)하는가? 팀은 모델이 단순히 데모에서 인상적인 것을 넘어, 워크플로우에 적합한지 어떻게 알 수 있는가?

그것이 바로 해야 할 일입니다.

BYOK는 모델 선택을 개인적인 문제처럼 느끼게 만듭니다.

하지만 프로덕션(production) 환경에서는, 그것이 플랫폼 아키텍처(platform architecture)가 됩니다.

참고 문헌 (references)

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위해 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.

Insights