백엔드 비용 0원으로 AI Chrome extension을 구축했습니다 — 정확한 아키텍처를 공개합니다

당신은 자신의 Chrome extension에 AI를 추가하고 싶어 합니다.

뻔한 경로: Node.js 서버를 구동하고, 마스터 API key를 보유하며, 사용자에게 월간 요금을 부과하고, AI 비용을 직접 부담하는 것입니다. 모두가 그렇게 합니다.

저는 그렇게 하지 않았습니다. 저는 PR 요약, 리스크 점수 산정, 초안 검토 생성 등 AI 기능을 갖춘 세 가지 Chrome extension을 구축했지만, 저의 월간 인프라 비용은 0달러입니다. 서버도 없습니다. 백엔드도 없습니다. 보호해야 할 API key도 없습니다.

여기 정확한 아키텍처와 실제 트레이드오프(trade-offs), 그리고 여러분이 직접 고생하며 깨닫지 않도록 이 방식이 한계에 부딪히는 구체적인 지점들을 소개합니다.

"표준" 접근 방식의 문제점

대부분의 AI 기반 extension은 다음과 같이 작동합니다:

사용자 → Extension → 귀하의 서버 → AI provider → 귀하의 서버 → Extension → 사용자

귀하의 서버가 마스터 API key를 보유합니다. 사용자는 귀하에게 비용을 지불합니다. 귀하는 그 마진에서 AI provider에게 비용을 지불합니다.

문제점:

1. 당신은 이제 프록시(proxy) 비즈니스가 됩니다. 당신은 OpenAI에 $X를 지불하고 사용자에게 $Y를 청구하며, 그 차액이 당신의 마진이 됩니다. 하지만 당신은 또한 귀하의 서버를 거치는 모든 요청에 대해 속도 제한(rate limiting), 가동 시간(uptime), 남용 방지, 그리고 GDPR 준수에 대한 책임을 집니다.

2. 개인 코드가 귀하의 인프라를 통과합니다. GitHub diff를 읽는 개발자 도구의 경우, 사용자들이 가장 먼저 던지는 질문은 이것입니다: "내 코드가 당신의 서버로 전송되나요?" 호스팅된 백엔드를 사용하는 경우, 정직한 답변은 "예"입니다.

3. 당신은 VC 자금을 보유한 기업들과 가격으로 경쟁해야 합니다. CodeRabbit, GitHub Copilot, Linear 및 수십 개의 다른 기업들은 개인 개발자가 따라갈 수 없는 규모의 경제를 갖춘 호스팅 AI를 운영하고 있습니다.

다른 아키텍처가 있습니다. 새로운 것은 아닙니다 — 이를 BYOK (Bring Your Own Key)라고 부르며, AI provider와의 관계를 귀하가 아닌 사용자로 전환합니다.

사용자 → Extension → AI provider (사용자 본인의 key)

중간에 서버가 없습니다. 마진 계산도 없습니다. _"내 코드가 안전한가"_라는 질문도 필요 없습니다.

Chrome extension에서 BYOK가 작동하는 방식

핵심 메커니즘은 간단합니다. 확장이 서버를 호출하는 대신, 사용자의 API 키를 사용하여 브라우저에서 AI 제공업체(AI provider)로 직접 호출합니다.

// 사용자가 온보딩(onboarding) 중에 자신의 API 키를 붙여넣습니다
// 이를 로컬에 저장합니다 — 절대 다른 곳으로 전송하지 마세요
await chrome.storage.local.set({ 
...

API 키는 chrome.storage.local에 저장됩니다. AI 제공업체로 직접 전송되는 경우를 제외하고는 브라우저를 절대 벗어나지 않습니다. 사용자가 키를 붙여넣은 후에는 확장이 이를 다시 볼 일이 없습니다.

실제로 필요한 manifest.json 권한

Chrome extension에서 직접 API 호출을 수행하려면, 지원하는 각 제공업체에 대한 호스트 권한(host permissions)을 선언해야 합니다:

{
  "manifest_version": 3,
  "permissions": [
...

localhost 항목은 Ollama를 지원합니다. API 비용이 전혀 없는 완전한 로컬 모델을 원하는 사용자들을 위한 것입니다.

중요: MV3에서는 호스트 권한이 검토 과정에서 면밀히 조사됩니다. 구체적으로 작성하세요. 정확한 도메인을 지정할 수 있다면 <all_urls>를 사용하지 마세요. 저는 이 manifest로 CWS(Chrome Web Store) 검토를 두 번 거쳤는데, 명시적으로 작성하는 것이 도움이 됩니다.

혼란 없이 여러 제공업체 지원하기

4개의 주요 제공업체 모두 OpenAI 호환 /v1/chat/completions 형식을 사용합니다. 하나의 구현으로 4개의 제공업체를 지원할 수 있습니다:

const AI_PROVIDERS = {
  groq: {
    endpoint: 'https://api.groq.com/openai/v1/chat/completions',
...

모델 이름을 fetch 호출 시 하드코딩하지 말고 여기에 저장하세요. Groq가 이전 Llama 버전을 지원 중단했을 때, 저는 설정 업데이트 하나만 배포했고 모든 사용자가 자동으로 새 모델을 사용할 수 있었습니다. 사용자의 별도 조치는 필요하지 않았습니다.

온보딩 마찰 문제 — 그리고 이를 줄이는 방법

BYOK의 실제 비용은 다음과 같습니다: 사용자가 AI 기능을 사용하기 전에 반드시 API 키를 직접 발급받아야 한다는 점입니다. 일부 사용자는 이 단계에서 이탈합니다.

실제로 마찰을 줄여주는 요소는 다음과 같습니다:

1. Groq을 앞세우세요. Groq의 무료 티어(free tier)는 소형 모델에 대해 하루 약 14,400개의 요청을 지원합니다. 대부분의 개인 개발자에게는 진정으로 무료입니다. 이는 대화의 흐름을 _"API 키를 사러 가세요"_에서 _"2분 만에 무료 API 키를 받으러 가세요"_로 바꿔줍니다.

2. 모호한 지침이 아닌 정확한 단계를 제공하세요:

1단계: console.groq.com/keys로 이동
2단계: "Create API key" 클릭
3단계: 여기에 키를 붙여넣으세요 → [input]

단 세 줄입니다. 모호함이 없습니다. 저는 온보딩(onboarding) 과정에서 사용자가 어디서 이탈하는지 추적합니다. 가장 이탈률이 높은 단계는 항상 제가 정확히 어디인지 말하지 않고 단순히 "API 키를 받으세요"라고만 말했을 때였습니다.

3. AI 없이도 핵심 기능이 작동하게 만드세요. 만약 모든 기능이 BYOK(Bring Your Own Key) 설정 뒤에 가로막혀 있다면, 첫 세션은 설정 세션이 되어버립니다. 그리고 많은 사용자가 두 번째 세션으로 돌아오지 않습니다. PR Focus에서는 멀티 계정 GitHub, PR 정렬, CSV 내보내기, 그리고 오래된(stale) 알림 기능이 API 키 없이도 모두 작동합니다. AI 기능은 부가적인 요소입니다.

스트리밍(streaming) 시 발생하는 MV3 서비스 워커(service worker) 문제

AI 응답을 토큰(token) 단위로 스트리밍하고 싶다면 MV3의 제약 사항에 부딪히게 됩니다. 서비스 워커가 API 호출을 처리하지만, 스트리밍은 장기 유지 연결(long-lived connection)을 필요로 하며, 서비스 워커는 스트리밍 도중에 종료될 수 있기 때문입니다.

작동하는 패턴은 다음과 같습니다. 서비스 워커가 fetch를 처리하고, 메시지를 통해 팝업(popup)으로 토큰을 전송합니다:

// 서비스 워커 — 스트리밍 fetch를 처리함
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === 'STREAM_AI') {
...

fetch는 스트리밍이 지속되는 동안 서비스 워커를 활성 상태로 유지합니다. 토큰은 메시지를 통해 팝업으로 전달됩니다. 팝업은 이를 축적하여 점진적으로 렌더링합니다.

구체적인 에러 핸들링(error handling) — 이는 고객 지원 티켓을 줄여줍니다

BYOK 모델에서 가장 흔한 고객 지원 카테고리는 잘못되었거나 잘못 설정된 키를 사용하는 사용자입니다. 일반적인 "AI 에러" 메시지는 후속 문의 티켓을 생성하지만, 상태 코드(status-code)별로 특화된 메시지는 그렇지 않습니다:

async function validateApiKey(apiKey, provider) {
  try {
    const config = AI_PROVIDERS[provider];
...

실제 토큰 비용 — 실제 수치

PR Focus에서의 일반적인 PR 요약(PR summary)은 다음과 같습니다: 입력(input) 약 800 토큰 (diff 컨텍스트 + 시스템 프롬프트), 출력(output) 약 150 토큰. PR당 약 950 토큰이 소모됩니다.

제공자 (Provider)	티어 (Tier)	PR당 비용	일일 100개 PR 기준
Groq (Llama 3.3 70B)	무료 (Free)	$0	$0
...

BYOK(Bring Your Own Key)를 선택하는 비용 논거는 단순히 개인정보 보호 때문만이 아닙니다. 바로 수학적인 문제입니다. 월 10달러를 청구하는 호스팅 모델(hosted model)은 AI 비용과 인프라 비용을 제외하면 몇 푼 남지 않습니다. 자신만의 Groq 키를 가진 사용자는 개인적인 용도로 사용할 때 비용을 전혀 지불하지 않습니다. 이는 호스팅된 백엔드(hosted backend)로는 맞출 수 없는 가치 제안(value proposition)입니다.

무엇이 문제인가 — 솔직하게 말하기

엄격한 프록시(proxy) 뒤에 있는 기업 사용자. 일부 엔터프라이즈 환경은 브라우저에서 외부 API로의 직접적인 호출을 차단합니다. 이는 해결할 수 없는 문제입니다. 이 부분을 솔직하게 밝히고, 로컬 해결책으로 Ollama를 안내하세요.

Ollama는 별도의 설치가 필요함. 이것은 단순히 "키를 붙여넣기"만 하면 되는 것이 아닙니다. "Ollama를 설치하고, 모델을 풀(pull)하고, 로컬에서 실행한 다음, 확장 프로그램을 설정"해야 합니다. 개인정보 보호를 우선시하는 사용자들을 위해 지원할 가치는 있지만, 이를 간단한 경로라고 홍보해서는 안 됩니다.

응답을 캐싱(cache)할 수 없음. 각 사용자의 키를 사용한다는 것은 각 사용자가 자신의 호출에 대해 비용을 지불한다는 의미입니다. 사용자 간의 교차 캐싱(cross-user caching)이 불가능합니다. 대부분의 사용 사례에서는 문제가 되지 않지만, 1,000명의 사용자가 동일한 질문을 할 가능성이 높은 무언가를 구축하고 있다면, 캐싱 기능이 있는 호스팅 방식이 그들에게 더 저렴할 것입니다.

당신의 확장 프로그램에 BYOK가 적합할까요?

네, 다음과 같은 경우라면:

• 사용자가 개발자이거나 "API 키"가 생소한 개념이 아닐 정도로 기술적 지식이 있는 경우
• 개인정보 보호가 진정한 셀링 포인트(selling point)인 경우 (코드 리뷰, 글쓰기 보조, 개인 데이터를 포함하는 모든 작업)
• 1인 개발자이며 인프라를 운영하고 싶지 않은 경우
• AI 비용을 부담하지 않으면서 무료 티어(free tier)를 제공하고 싶은 경우

아니요, 다음과 같은 경우라면:

• 사용자가 기술적이지 않으며, 가치를 전달하기도 전에 _"API key"_라는 단어에서 이탈할 가능성이 있는 경우
• 일관성이나 품질을 위해 어떤 모델을 사용할지 제어해야 하는 경우
• 플랫폼 수준의 캐싱 (caching), 속도 제한 (rate limiting), 또는 남용 방지 (abuse prevention) 기능이 필요한 경우
• 구독 모델을 수용할 수 있으며 관리형 서비스 (managed service)의 단순함을 원하는 경우

아키텍처 다이어그램

chrome.storage.local
  ├── aiApiKey      ← 사용자 본인의 키, 제공업체로 전송되는 것 외에는 브라우저를 떠나지 않음
  └── aiProvider    ← 'groq' | 'openai' | 'mistral' | 'ollama'
...

실제 프로덕션 환경에서의 구동 모습

이 글의 모든 내용은 **PR Focus Pro**에서 실행되고 있습니다. 이 서비스는 AI 요약, 하이브리드 위험 점수 (0–100), 그리고 원클릭 초안 리뷰 기능을 통해 GitHub Pull Request (PR)를 분류하는 Chrome extension입니다. 설치는 무료이며, AI 기능은 사용자의 API key를 통해 활성화됩니다.

제가 거부한 옵션들, 사용자 마찰 (user friction) 측면에서 발생한 비용, 그리고 다시 선택한다면 어떻게 할 것인지에 대한 내용을 포함하여, 이 아키텍처 뒤에 숨겨진 전체 엔지니어링 결정 로그는 제 공개 Build Logs 리포지토리의 Build Log #007에서 확인할 수 있습니다.

비슷한 것을 구축 중이며 구현 방식에 대해 피드백을 받고 싶다면, Summer Review Swap이 열려 있습니다. 지금 바로 참여하고 싶다면 리뷰어를 기다리고 있는 PR이 있습니다.

브라우저 extension에서 AI를 다루는 여러분의 방식은 무엇인가요? 자체 백엔드를 운영하시나요, BYOK (Bring Your Own Key) 방식을 사용하시나요, 아니면 완전히 다른 방식인가요? 특히 스트리밍 (streaming)과 서비스 워커 종료 (service worker termination) 문제를 해결할 더 깔끔한 솔루션을 찾은 분이 계신지 궁금합니다. 댓글로 알려주세요.

이 글의 링크들:

이 글의 링크들:

• PR Focus Pro on Chrome Web Store
• Interactive demo
• Build Log #007 — full engineering decision log
• Build Log #002 — why BYOK vs hosted backend
• Summer Review Swap — open through July
• Groq free tier limits