우리가 클라우드 IDE를 오픈 소스로 공개한 이유 (AGPL)

아무도 말하지 않는 AI 코딩 도구의 문제점

몇 달 전, 저는 디버깅 세션에 깊이 몰입해 있었습니다.

버그 자체는 특별히 어렵지 않았습니다. 어려운 부분은 AI 어시스턴트였습니다.

저는 이미 할당량(quota)을 모두 사용한 상태였습니다.

또다시 말이죠.

만약 여러분이 현대적인 AI 코딩 도구를 진지하게 사용해 본 적이 있다면, 아마 똑같은 경험을 해보셨을 것입니다. 생산적인 몰입 상태(flow state)에서 모델에게 아키텍처 결정 사항을 검토하거나, 에러 트레이스(error trace)를 설명하거나, 테스트를 생성하거나, 서비스를 리팩터링(refactor)하도록 요청하고 있는데, 갑자기 다음과 같은 메시지가 뜹니다:

"사용 한도에 도달했습니다."

세션이 중단됩니다.

컨텍스트(context)가 유실됩니다.

생산성이 떨어집니다.

아이러니한 점은 AI 코딩 도구는 집중적으로 작업할 때 가장 가치가 높지만, 바로 그때 많은 플랫폼이 사용을 제한하기 시작한다는 것입니다.

여러 도구에서 이러한 한계에 반복적으로 부딪힌 후, 우리는 단순한 질문을 던지기 시작했습니다:

만약 AI에 사용량 제한이 전혀 없다면 어떨까?

"더 높은 한도"가 아닙니다.

"더 많은 크레딧"도 아닙니다.

또 다른 프리미엄 티어(premium tier)도 아닙니다.

정말로 무제한인 것입니다.

그 질문은 결국 Neural Inverse Cloud의 탄생으로 이어졌습니다. 이곳은 AI 어시스턴스가 별도로 과금되는 대신 컴퓨팅 리소스(compute resources)에 포함된 클라우드 IDE(Cloud IDE)입니다.

하지만 곧 다른 질문이 뒤따랐습니다:

무제한 AI가 가능하다면, 왜 모두가 그렇게 하지 않을까?

답은 기술적인 것이 아닙니다.

경제적인 것입니다.

그리고 그 깨달음이 결국 우리가 전체 플랫폼을 AGPL 라이선스 하에 오픈 소스로 공개하도록 설득했습니다.

이 글에서 저는 아키텍처(architecture), 무제한 AI 뒤에 숨겨진 경제학, 그리고 왜 우리가 전체 스택(stack)을 공개적으로 사용할 수 있게 만들기로 결정했는지에 대해 설명하겠습니다.

왜 오픈 소스인가?

아키텍처를 논하기 전에, 오픈 소스로 공개하기로 한 결정을 설명할 가치가 있습니다.

개발자들은 블랙박스(black-box) 인프라에 대해 점점 더 회의적입니다.

만약 누군가 다음과 같이 주장한다면:

무제한 AI
멀티 리전 배포 (Multi-region deployment)
셀프 호스팅 가능한 아키텍처 (Self-hostable architecture)
지속 가능한 경제성

대부분의 엔지니어는 즉시 이렇게 묻습니다:

"코드를 보여주세요."

그것이 바로 우리가 원했던 것입니다.

우리는 사람들이 마케팅을 믿기를 원하지 않았습니다.

우리는 사용자들이 직접 구현 내용을 검토하기를 원했습니다.

AGPL 라이선스는 개선 사항이 오픈 소스로 유지되도록 보장하는 동시에, 팀들이 시스템이 어떻게 작동하는지에 대해 완전한 가시성 (Visibility)을 가질 수 있도록 합니다.

인프라 제품의 경우, 투명성 (Transparency)은 종종 문서화 (Documentation)보다 더 설득력이 있습니다.

아키텍처 개요 (Architecture Overview)

높은 수준 (High level)에서 볼 때, 플랫폼은 네 가지 주요 시스템으로 구성됩니다:

Kubernetes 워크스페이스 (Kubernetes Workspaces)
AI 추론 게이트웨이 (AI Inference Gateway)
Git 기반 지속성 (Git-Based Persistence)
멀티 리전 인프라 (Multi-Region Infrastructure)

개발자 브라우저 (Developer Browser)
│
▼
┌────────────────────┐
│ 글로벌 로드 밸런서 (Global Load Balancer)│
└──────────┬─────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼

US 리전 (US Region) Europe 리전 (Europe Region) APAC 리전 (APAC Region)

  │               │               │
  ▼               ▼               ▼

┌──────────────────────────────────────┐
│ Kubernetes 워크스페이스 포드 (Kubernetes Workspace Pods) │
└──────────────┬───────────────────────┘
│
┌─────────┴─────────┐
▼ ▼

Gitea AI 게이트웨이 (Gitea AI Gateway)

  │                   │

  ▼                   ▼

지속성 Azure AI Foundry (Persistent Azure AI Foundry)
스토리지 서버리스 모델 (Storage Serverless Models)

목표는 명확했습니다:

운영 복잡성 (Operational complexity)을 관리 가능한 수준으로 유지하면서, 통합된 AI 지원을 제공하는 격리된 개발 환경을 구축하는 것이었습니다.

워크스페이스 아키텍처 (Workspace Architecture)

모든 개발자 워크스페이스는 Kubernetes 포드 (Pod)로 실행됩니다.

현재 워크스페이스 티어 (Tier)는 다음과 같습니다:

티어 (Tier) CPU 메모리 (Memory)
Starter 2 vCPU 2 GB
Standard 4 vCPU 8 GB
Pro 8 vCPU 32 GB

우리가 초기에 얻은 교훈 중 하나는 노이지 네이버 (Noisy-neighbor) 문제였습니다.

초기에는 대규모 워크스페이스가 더 작은 워크로드 (Workload)와 노드 (Node)를 공유했습니다.

그 결과:

빌드 지연 시간 (Build latency) 급증
터미널 응답성 저하
일관되지 않은 개발자 경험

우리는 결국 티어를 전용 노드 풀 (Node pools)로 격리했습니다.

apiVersion: v1

spec:
nodeSelector:
workspace-tier: high-performance

tolerations:

• key: workspace-tier
  operator: Equal
  value: high-performance

이는 일관성을 극적으로 향상시켰습니다.

콜드 스타트 (Cold Starts) 해결하기

개발 환경을 위해 3분 동안 기다리고 싶은 사람은 아무도 없습니다.

원래는 모든 워크스페이스 실행 시 다음과 같은 과정이 트리거되었습니다:

Kubernetes 스케줄링 (scheduling)
스토리지 연결 (Storage attachment)
컨테이너 시작 (Container startup)
IDE 초기화 (IDE initialization)

이러한 시작 경험은 느리게 느껴졌습니다.

해결책은 놀라울 정도로 간단했습니다:

사전 예열된 워크스페이스 풀 (Pre-warmed workspace pools).

환경을 처음부터 프로비저닝 (provisioning) 하는 대신, 각 리전에 즉시 사용 가능한 포드 (pod)를 유지합니다.

def create_workspace(user):

pod = get_available_pod()

attach_volume(user.volume)
...

이제 대부분의 워크스페이스 실행은 1분 이내에 완료됩니다.

Unlimited AI가 실제로 작동하는 방식

이것은 보통 개발자들이 가장 먼저 던지는 질문입니다.

그 답은 AI와는 거의 관련이 없습니다.

그것은 가격 책정 (pricing)과 모든 관련이 있습니다.

대부분의 AI 제품은 모델 사용량에 대해 직접 비용을 청구합니다.

그것은 다음을 의미합니다:

더 많은 토큰 (tokens) = 더 많은 비용.

결국 제공업체는 사용량을 예측할 수 없게 되기 때문에 제한을 도입합니다.

우리는 이 문제에 다르게 접근했습니다.

AI에 직접 가격을 매기는 대신, 컴퓨팅 (compute)에 가격을 매깁니다.

개발자는 할당된 리소스 (resources)에 대해 비용을 지불합니다.

AI는 해당 환경 내에서 실행되는 또 다른 워크로드 (workload)가 됩니다.

이 방식이 효과적인 이유는 다음과 같습니다:

컴퓨팅 사용량은 예측 가능합니다.
AI 사용량은 가변적입니다.
수익은 워크스페이스 할당에 따라 확장됩니다.
AI는 총 비용의 아주 작은 부분으로 남습니다.

경제 모델을 관리하기가 훨씬 쉬워집니다.

AI 인프라 (AI Infrastructure)

우리는 의도적으로 자체 GPU 플릿 (fleet)을 운영하는 것을 피했습니다.

GPU를 관리하면 다음과 같은 문제가 발생합니다:

용량 계획 (Capacity planning)
하드웨어 비용
유휴 활용 (Idle utilization) 문제
운영 복잡성 (Operational complexity)

대신, 추론 (inference)은 Azure AI Foundry 서버리스 엔드포인트 (serverless endpoints)를 통해 라우팅됩니다.

현재 모델 구성:

DeepSeek R1
Llama 4
Mistral Large 3

요청은 동적으로 라우팅됩니다.

def select_model(task):

if task == "reasoning":
    return "deepseek-r1"

...

장점은 유연성입니다.

모델을 변경하는 것은 인프라 마이그레이션 (migration)이 아닌 구성 업데이트 (configuration update)가 됩니다.

비용 경제학 (Cost Economics)

흔한 가정은 무제한 AI는 반드시 비쌀 것이라는 점입니다.

수치는 다른 이야기를 해줍니다.

전형적인 4-vCPU 워크스페이스의 경우:

구성 요소 비용
AI 추론 (Inference) $0.10/hr
스토리지 (Storage) $0.02/hr
네트워크 (Network) $0.02/hr
총 비용 $0.14/hr

수익 (Revenue):

구성 요소별 수익 (Component Revenue)
컴퓨팅 (Compute) $0.96/hr

이는 헤비 AI 사용자들에게도 상당한 여유 공간 (headroom)을 남겨줍니다.

흥미로운 점은 AI 비용이 계속해서 하락하고 있다는 것입니다.

추론 (Inference) 가격의 모든 감소는 고객 가격을 변경하지 않고도 마진 (margins)을 개선합니다.

이는 전통적인 AI 크레딧 시스템에서 발생하는 현상과는 정반대입니다.

멀티 리전 배포 (Multi-Region Deployment)

플랫폼은 현재 다음 지역에서 운영됩니다:

미국 (United States)
유럽 (Europe)
싱가포르 (Singapore)
일본 (Japan)

각 리전은 다음을 포함합니다:

Kubernetes 클러스터 (Kubernetes cluster)
워크스페이스 노드 (Workspace nodes)
Gitea 배포 (Gitea deployment)
스토리지 계층 (Storage layer)

워크스페이스는 리전 제한 (region-bound) 상태로 유지됩니다.

우리는 의도적으로 실시간 교차 리전 마이그레이션 (live cross-region migration)을 피했습니다.

기술적으로는 가능하지만, 스토리지 일관성 (storage consistency) 및 복구 (recovery)와 관련된 추가적인 복잡성을 초래하기 때문입니다.

때로는 더 단순한 시스템이 더 신뢰할 수 있는 시스템입니다.

플랫폼 셀프 호스팅 (Self-Hosting the Platform)

오픈 소스의 장점 중 하나는 누구나 플랫폼을 직접 실행할 수 있다는 것입니다.

이는 특히 다음의 경우에 유용합니다:

기업 (Enterprises)
정부 기관 (Government agencies)
의료 기관 (Healthcare organizations)
금융 기관 (Financial institutions)

배포는 의도적으로 간단하게 설계되었습니다.

저장소 (repository)를 클론합니다:

git clone https://github.com/neuralinverse/neuralinverse

cd neuralinverse

환경을 설정합니다:

cp .env.example .env

서비스를 시작합니다:

docker compose up -d

배포를 확인합니다:

docker ps

배포 후에는 대시보드 (dashboard)를 통해 워크스페이스를 직접 생성할 수 있습니다.

전형적인 워크플로 (A Typical Workflow)

개발자가 워크스페이스를 생성합니다.

플랫폼은 미리 예열된 (pre-warmed) Kubernetes 포드 (pod)를 할당합니다.

AI 지원을 즉시 사용할 수 있습니다.

개발자는 다음을 수행할 수 있습니다:

코드 생성 (Generate code)
문제 디버깅 (Debug issues)
테스트 생성 (Create tests)
서비스 리팩터링 (Refactor services)
API 문서화 (Document APIs)

그동안:

변경 사항은 Git을 통해 지속적으로 저장 (persisted)됩니다
인프라 (Infrastructure)가 자동으로 확장 (scales)됩니다
AI 요청이 적절한 모델로 라우팅 (routed)됩니다

개발자의 관점에서는 모든 것이 일반적인 IDE처럼 느껴집니다.

복잡성은 플랫폼 뒤에 숨겨져 있습니다.

우리가 배운 점 (What We Learned)

클라우드 IDE를 구축하며 우리는 몇 가지 교훈을 얻었습니다.

첫째, 인프라 병목 현상 (infrastructure bottlenecks)은 예상치 못한 곳에서 발생하는 경우가 많습니다.

우리는 처음에 컴퓨팅 용량 (compute capacity)을 걱정했습니다.

하지만 더 큰 과제는 스토리지 수명 주기 관리 (storage lifecycle management)와 워크스페이스 오케스트레이션 (workspace orchestration)인 것으로 밝혀졌습니다.

둘째, 가격 모델 (pricing models)은 기술 아키텍처 (technical architecture)만큼이나 중요합니다.

많은 플랫폼이 오로지 기능에만 집중합니다.

우리의 경험상, 지속 가능한 경제성 (sustainable economics)은 기능적 동등성 (feature parity)보다 더 강력한 차별화를 만들어냅니다.

마지막으로, 오픈 소스 (open source)는 신뢰를 구축합니다.

가장 가치 있는 피드백 중 일부는 제품 자체를 사용하는 대신, 배포 매니페스트 (deployment manifests)와 인프라 코드를 읽는 엔지니어들로부터 왔습니다.

이것이 오픈 인프라 (open infrastructure)를 지지하는 가장 강력한 논거 중 하나입니다.

결론 (Conclusion)

Neural Inverse Cloud 뒤에 있는 기술들이 혁명적인 것은 아닙니다.

Kubernetes는 이미 존재합니다.

Git은 이미 존재합니다.

서버리스 AI (Serverless AI)는 이미 존재합니다.

멀티 리전 배포 (Multi-region deployments)도 이미 존재합니다.

이 플랫폼을 흥미롭게 만드는 것은 이러한 요소들이 어떻게 결합되었는가 하는 점입니다.

예측 불가능한 AI 사용량 대신 예측 가능한 컴퓨팅 리소스를 가격 책정함으로써, 우리는 경제성을 지속 가능하게 유지하면서도 무제한 AI 어시스턴트 (AI assistance)를 제공하는 클라우드 IDE를 구축할 수 있었습니다.

플랫폼을 오픈 소스로 공개하는 것은 자연스러운 다음 단계였습니다.

개발자들은 아키텍처를 검사하고, 주장을 검증하며, 원한다면 시스템을 직접 실행할 수 있어야 합니다.

구현 내용에 관심이 있다면:

GitHub: https://github.com/neuralinverse/neuralinverse

Cloud Platform: https://cloud.neuralinverse.com

다른 분들은 AI 경제성 (AI economics), 셀프 호스팅 (self-hosting), 그리고 개발자 인프라 (developer infrastructure)에 어떻게 접근하고 있는지 듣고 싶습니다.