Cover image

신뢰성 있는 AI를 위한 에이전트 아키텍처: 스플릿-브레인 설계의 실무 적용

왜 지금 이게 문제인가 LLM을 프로덕션에 투입하는 팀이 늘어나면서 두 가지 근본적인 문제가 동시에 터지고 있다. 첫째, 지연 시간(Latency). 거대 모델에 모든 요청을 던지면 응답이 느려서 실시간 시스템에 쓸 수 없다. 둘째, 신뢰성(Reliability). 빠른 경량 모델만 쓰면 복잡한 추론에서 환각(Hallucination)이 터진다. “빠르면 부정확하고, 정확하면 느리다"는 딜레마 속에서 대부분의 팀은 하나를 포기한다. 구글이 고속 레이싱 환경에서 실험한 스플릿-브레인(Split-Brain) 아키텍처는 이 딜레마를 정면으로 공략한다. 시속 160km로 달리는 차량에서 AI가 실시간 코칭을 하는 극단적인 시나리오에서 검증된 설계다. ...

February 5, 2026 · 5 min · 938 words · gnosyslambda

OpenAI는 어떻게 PostgreSQL 하나로 8억 사용자를 감당하는가

왜 지금 이게 문제인가 “PostgreSQL은 스타트업 DB 아닌가?” 많은 한국 개발자들이 대규모 트래픽을 언급할 때 당연하게 NoSQL이나 NewSQL을 먼저 떠올린다. 그런데 세계에서 가장 폭발적으로 성장한 서비스인 ChatGPT가 단일 PostgreSQL 프라이머리 인스턴스를 핵심 데이터 저장소로 사용하고 있다는 사실은 업계의 통념을 정면으로 뒤집는다. OpenAI는 1년 만에 트래픽이 10배 증가하는 상황에서도 PostgreSQL을 포기하지 않았다. 대신 약 50대의 읽기 복제본(Read Replica)을 배치하고, 쓰기 부하가 큰 워크로드만 선별적으로 CosmosDB로 분리하는 전략을 택했다. 결과는 p99 레이턴시 두 자릿수 밀리초, 가용성 99.999%. ...

January 28, 2026 · 4 min · 770 words · gnosyslambda

Claude Code Plugins 해부: 앱스토어 없는 AI 코딩 도구의 확장성 전쟁

왜 지금 이게 문제인가 AI 코딩 도구 시장이 “누가 더 똑똑한 모델을 쓰느냐"에서 **“누가 더 유연하게 확장되느냐”**로 전선이 이동하고 있다. GitHub Copilot은 VS Code 익스텐션 생태계 위에 올라탔고, Cursor는 자체 에디터에 MCP를 통합했다. 그런데 Anthropic은 2025년 10월 9일, 전혀 다른 방향을 선택했다. 앱스토어 없이, Git 저장소 기반의 분산형 플러그인 시스템을 퍼블릭 베타로 공개한 것이다. 핵심 질문은 이것이다: 중앙 마켓플레이스 없이 플러그인 생태계가 성립할 수 있는가? 락인의 문제: VS Code Marketplace에 올린 익스텐션은 VS Code 밖에서 못 쓴다. Cursor의 MCP 설정은 Cursor 밖에서 재활용이 어렵다. 도구에 종속된 확장성은 결국 개발자의 자유도를 갉아먹는다. 토큰 경제학: AI 코딩 도구에서 컨텍스트 윈도우는 곧 비용이다. 무거운 플러그인 하나가 50k 토큰을 먹으면, 정작 코드 분석에 쓸 토큰이 줄어든다. 확장성과 효율성 사이의 트레이드오프를 어떻게 설계하느냐가 기술적 분기점이다. 신뢰 경계: CLI 도구에 서드파티 코드를 실행시키는 것은 본질적으로 위험하다. 샌드박싱 없이 npm install을 돌리는 플러그인이 나오면 그건 보안 사고다. 어떻게 동작하는가 확장성 아키텍처: Skills vs MCP vs Plugins Claude Code의 확장성 레이어는 세 가지로 나뉜다. 각각의 무게와 역할이 명확히 다르다. ...

October 18, 2025 · 5 min · 855 words · gnosyslambda

Cloudflare가 인터넷의 20%를 Rust로 다시 쓴 이유

왜 지금 이게 문제인가 전 세계 인터넷 트래픽의 약 20%가 Cloudflare를 경유한다. 이 거대한 트래픽을 처리하는 핵심 프록시가 NGINX + LuaJIT 조합(내부 코드명 FL1)으로 10년 이상 운영되어 왔다. 그리고 Cloudflare는 이것을 **Rust로 완전히 재작성(FL2)**하는 데 성공했다. “동작하는 코드를 왜 다시 짜는가?“라는 질문에 대한 답은 명확하다. 메모리 안전성의 한계: C/C++ 기반의 NGINX는 버퍼 오버플로우, Use-after-free 같은 메모리 취약점의 온상이다. 보안 회사가 자체 프록시에서 메모리 버그를 내는 것은 존재론적 위협이다. 확장성의 벽: NGINX의 모놀리식 구조 위에 LuaJIT으로 비즈니스 로직을 붙이는 방식은 기능이 늘어날수록 유지보수가 기하급수적으로 어려워졌다. 새 기능 하나를 추가하려면 Lua, C, 설정 파일 세 곳을 동시에 건드려야 했다. 성능 천장: LuaJIT의 GC(가비지 컬렉션)가 예측 불가능한 레이턴시 스파이크를 일으켰고, NGINX의 스레딩 모델은 현대적인 비동기 I/O 패턴과 맞지 않았다. Cloudflare의 재작성은 “Rust가 좋으니까"가 아니라, 기존 시스템의 기술적 부채가 사업적 리스크가 되는 시점에서 내린 결정이다. 100명 이상의 엔지니어가 130개 이상의 모듈을 작성하여 점진적으로 트래픽을 이관한, 대규모 시스템 마이그레이션의 교과서적 사례다. ...

October 8, 2025 · 4 min · 729 words · gnosyslambda