아키텍처

프록시 서버와 백엔드 간의 해석 차이를 이용해 보안 통제권을 무력화하는 리퀘스트 스머글링(Request Smuggling) 취약점이 최근 Rust 기반 프레임워크인 핑고라(Pingora) OSS에서 발견되었습니다. 프록시 보안 취약점을 왜 지금 살펴봐야 할까 클라우드플레어(Cloudflare)가 Nginx를 대체하기 위해 만든 핑고라는 최근 백엔드 인프라 업계에서 가장 뜨거운 오픈소스 프로젝트 중 하나입니다. 자바나 코틀린 기반의 마이크로서비스 아키텍처를 운영하는 시니어 개발자 입장에서, 프록시 계층의 보안은 서비스 전체의 생존과 직결되는 문제입니다. 우리가 구축한 API 게이트웨이나 인그레스 프록시(Ingress Proxy)가 외부의 악의적인 요청을 잘못 해석한다면, 그 뒤에 있는 스프링 부트(Spring Boot) 서버가 아무리 견고해도 소용이 없기 때문입니다. 이번에 공개된 CVE-2026-2833, CVE-2026-2835, CVE-2026-2836 취약점은 단순한 버그를 넘어 HTTP 프로토콜을 처리하는 프록시 설계의 근본적인 어려움을 보여줍니다. ...

왜 지금 이게 문제인가 LLM을 단순한 챗봇이 아니라 ‘에이전트’로 활용하려는 시도가 늘어나면서 백엔드 엔지니어들은 새로운 형태의 통합 지옥(Integration Hell)에 빠졌다. 기존에는 서비스마다 제각각인 REST API 명세에 맞춰 툴(Tool)을 정의하고, 프롬프트에 수십 개의 함수 명세를 때려 넣는 노가다를 반복해 왔다. 툴 관리의 비대해짐: 에이전트가 처리할 도메인이 넓어질수록 tools[] 리스트는 관리 불가능한 수준으로 길어지고, 이는 곧 컨텍스트 윈도우 낭비와 모델의 추론 성능 저하로 이어진다. 표준의 부재: 서로 다른 팀이나 회사가 만든 에이전트끼리 협업하려면, 결국 또 사람이 개입해서 API 스펙을 맞추고 인증 로직을 새로 짜야 한다. 신뢰와 보안의 트레이드오프: 에이전트에게 실행 권한을 줄수록 보안 리스크는 커지며, 특히 금융권이나 대규모 커머스처럼 ‘무결성’이 중요한 한국 실무 환경에서 ‘Auto-Approve’ 같은 기능은 기술적 부채보다 무서운 운영 리스크가 된다. 구글이 제시한 MCP(Model Context Protocol)와 A2A(Agent-to-Agent) 등의 프로토콜은 이 파편화된 연결 고리를 표준화하겠다는 선언이다. 이제 에이전트는 직접 API를 호출하는 대신, 표준화된 프로토콜을 통해 데이터에 접근하고 다른 에이전트에게 업무를 위임한다. ...

구글이 제공하는 공식 문서를 AI 에이전트가 실시간으로 검색하고 읽을 수 있게 해주는 Developer Knowledge API와 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 서버가 공개되었습니다. 이 도구들을 활용하면 AI가 생성하는 코드의 정확도를 높이고, 최신 SDK나 API 변경 사항을 반영하지 못해 발생하는 할루시네이션(Hallucination) 문제를 근본적으로 해결할 수 있습니다. 왜 공식 문서 API가 필요한가? 자바와 코틀린 기반의 백엔드 시스템을 10년 넘게 운영하다 보면 가장 골치 아픈 지점이 바로 라이브러리 버전 업데이트와 그에 따른 문서 파편화입니다. 특히 구글 클라우드(Google Cloud)나 파이어베이스(Firebase)처럼 변화 속도가 빠른 플랫폼을 다룰 때, 구글링으로 찾은 예제 코드가 이미 디프리케이트(Deprecated)된 경우를 수없이 겪었습니다. ...

TL;DR — Cloudflare가 API의 로직 결함을 사전에 탐지하는 **웹 및 API 취약점 스캐너(Web and API Vulnerability Scanner)**를 출시했습니다. 이 도구는 API 호출 간의 의존성을 이해하는 상태 기반(Stateful) 테스트와 API 호출 그래프(Call Graph) 기술을 활용하여, 기존 WAF가 방어하기 어려웠던 BOLA(Broken Object Level Authorization)와 같은 복잡한 권한 취약점을 자동으로 식별합니다. 배경과 문제 정의 전통적인 보안은 성벽을 쌓고 문을 지키는 ‘방어’의 영역이었습니다. 웹 애플리케이션 방화벽(WAF, Web Application Firewall)은 데이터가 있어야 할 자리에 코드가 삽입되는 SQL 인젝션(SQL Injection)이나 크로스 사이트 스크립팅(XSS) 같은 구문 오류(Syntax Error) 형태의 공격을 차단하는 데 매우 효과적입니다. 이러한 공격은 명확한 서명(Signature)이 존재하기 때문입니다. ...

한 줄 요약 — 드롭박스(Dropbox)는 DSPy를 활용해 LLM 기반 검색 결과 평가 시스템을 자동 최적화함으로써, 인간과의 평가 일치도를 45% 높이고 운영 비용을 최대 100배 절감했습니다. 이 주제를 꺼낸 이유 검색 시스템이나 추천 엔진을 만들 때 가장 고통스러운 지점은 결과가 정말로 사용자에게 유용한지 판단하는 과정입니다. 흔히 렐러번스 저지(Relevance Judge)라고 부르는 이 평가 단계는 과거에는 사람이 일일이 검수하거나 복잡한 규칙 기반 시스템에 의존했습니다. 최근에는 LLM을 판별기로 사용하는 LLM-as-a-Judge 방식이 대세가 되었지만, 정작 이 판별기를 고도화하는 과정은 여전히 수동 프롬프트 수정이라는 노가다에 머물러 있는 경우가 많습니다. ...

왜 지금 이게 문제인가 2025년 11월, 오스트리아 개발자 Peter Steinberger가 “Clawdbot"이라는 이름으로 오픈소스 AI 에이전트를 공개했다. 터미널에서 코드를 읽고, 브라우저를 돌리고, 테스트를 실행하는 – 말 그대로 ‘행동하는’ AI 에이전트였다. 이름이 Anthropic의 Claude와 너무 유사하다는 법적 경고를 받아 “OpenClaw(오픈클로)“로 리브랜딩한 뒤, 2026년 1월 말 갑자기 바이럴을 탔다. 72시간 만에 GitHub 60,000 스타. 2026년 3월 3일 기준 250,829 스타로, React가 10년에 걸쳐 쌓은 기록을 3개월 만에 넘어섰다. 그런데 진짜 사건은 그 이후에 터졌다. 2026년 2월 14일, Sam Altman이 직접 트위터에서 Peter Steinberger의 OpenAI 합류를 발표했다. 오픈소스 AI 에이전트의 상징적 인물이 가장 공격적인 상용 AI 기업으로 이직한 것이다. 프로젝트는 독립 오픈소스 재단으로 이전됐지만, 커뮤니티에는 불안감이 퍼지고 있다. ...

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

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

왜 지금 이게 문제인가 결제 시스템에서 “정확히 한 번 처리(exactly-once processing)“는 분산 시스템 엔지니어링의 성배(Holy Grail)다. 네트워크 타임아웃이 발생했을 때 요청을 재시도하면 이중 결제가 되고, 재시도하지 않으면 결제가 누락된다. Uber는 하루 수천만 건의 결제를 수백 개의 마이크로서비스가 처리하면서 이 문제를 극한까지 경험했다. “결제가 두 번 되었습니다"라는 고객 컴플레인은 단순한 버그 리포트가 아니다. 토스나 카카오페이 같은 한국 핀테크도 동일한 문제에 직면한다. PG사 연동에서 타임아웃이 걸렸을 때, 그 결제가 성공한 건지 실패한 건지 확인하는 로직 하나가 수억 원의 차이를 만든다. ...

왜 지금 이게 문제인가 전 세계 인터넷 트래픽의 약 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개 이상의 모듈을 작성하여 점진적으로 트래픽을 이관한, 대규모 시스템 마이그레이션의 교과서적 사례다. ...