Posts

클라우드플레어(Cloudflare)의 13세대 서버 설계는 단순히 더 빠른 부품을 조립하는 단계를 넘어, 소프트웨어 스택의 변화가 하드웨어 결정에 어떤 영향을 미치는지 보여주는 전형적인 사례입니다. 특히 러스트(Rust) 기반의 FL2 스택 전환이 하드웨어의 물리적 한계를 어떻게 극복했는지에 초점을 맞춰 정리했습니다. 하드웨어의 캐시 용량을 줄이는 대신 코어 밀도를 극대화하고, 이를 소프트웨어 최적화로 보완하여 서버당 처리량을 2배로 끌어올린 하드웨어-소프트웨어 공동 설계의 결과물입니다. 성능 확장을 가로막던 하드웨어 제약과 소프트웨어의 해답 기존 12세대 서버에서 사용하던 AMD Genoa-X 프로세서는 대용량의 L3 캐시(3D V-Cache)를 탑재하여 요청 처리 속도를 높였습니다. 하지만 차세대 하드웨어를 검토하는 과정에서 코어 밀도를 높이면 코어당 할당되는 L3 캐시 용량이 급격히 줄어드는 문제에 직면했습니다. 기존의 FL1 소프트웨어 스택은 캐시 의존도가 높았기 때문에 하드웨어의 코어 수가 늘어나도 성능이 선형적으로 증가하지 않는 병목 현상이 예상되었습니다. ...

한 줄 요약 — LlamaParse의 에이전트 기반 파싱과 Gemini 3.1의 멀티모달 추론을 결합하여 복잡한 금융 PDF 문서에서 정확한 데이터를 추출하고 자동화된 분석 파이프라인을 구축하는 방법입니다. 금융 PDF 데이터 추출이 유독 까다로운 이유 비정형 문서에서 텍스트를 뽑아내는 작업은 개발자에게 오래된 숙제와 같습니다. 특히 금융 명세서(Brokerage Statements)는 다단 레이아웃, 복잡하게 중첩된 표, 전문 용어가 뒤섞여 있어 일반적인 OCR(Optical Character Recognition) 엔진으로는 처리가 거의 불가능합니다. 표의 경계선이 명확하지 않거나 페이지를 넘어가는 긴 테이블을 만나면 기존 시스템은 텍스트 순서를 엉망으로 섞어버리기 일쑤입니다. ...

한 줄 요약 — 왓츠앱은 화려한 프로세스나 대규모 인원 대신 얼랑(Erlang) 기반의 단순한 아키텍처와 엔지니어 간의 강력한 신뢰를 통해 30명의 엔지니어로 4억 5천만 명의 사용자를 수용했습니다. 이 주제를 꺼낸 이유 수많은 기업이 마이크로서비스 아키텍처(MSA)를 도입하고 애자일(Agile) 프로세스를 정교하게 다듬는 데 엄청난 에너지를 쏟습니다. 하지만 정작 서비스의 본질인 속도와 안정성은 뒷전이 되는 경우를 자주 목격합니다. 왓츠앱(WhatsApp)의 초기 멤버인 진 리(Jean Lee)의 인터뷰는 우리가 당연하게 여겼던 코드 리뷰, 스크럼, 테스트 주도 개발(TDD) 같은 절차들이 과연 필수적인 것인지 의문을 던집니다. ...

한 줄 요약 — 무거운 FFmpeg 작업을 처리하기 위해 도입했던 복잡한 컨테이너 관리 로직을 버리고, 일회성 실행 후 자동 소멸하는 Cloudflare Sandboxes로 아키텍처를 단순화한 여정을 소개합니다. 왜 컨테이너 관리가 복잡해질까? 메인 서버에서 FFmpeg 같은 CPU 집약적인 작업을 수행하면 서비스 전체의 응답성이 떨어집니다. 이를 해결하기 위해 작업을 별도의 인프라로 격리하는 것은 올바른 선택이지만, 그 과정에서 예상치 못한 관리 포인트가 생깁니다. 가장 골치 아픈 지점은 컨테이너의 생명주기(Lifecycle) 관리입니다. 작업이 끝났을 때 컨테이너가 스스로를 종료할 수 없다면, 외부에서 상태를 확인하고 꺼주는 별도의 컨트롤 플레인(Control Plane)이 필요합니다. ...

한 줄 요약 — 단순한 텍스트 생성을 넘어 호스팅 컨테이너 환경과 셸(Shell) 도구를 결합하여 실질적인 작업을 수행하는 에이전트 환경 구축 전략을 다룹니다. LLM이 직접 코드를 실행해야 하는 이유 모델이 질문에 답하는 수준을 넘어 스스로 도구를 사용하고 환경을 조작하는 에이전트(Agent)로 진화하고 있습니다. 기존의 방식은 모델이 생성한 코드를 개발자가 복사해서 실행하거나, 로컬 환경에서 위험을 감수하며 실행 스크립트를 돌리는 형태가 많았습니다. 하지만 실무에서 복잡한 데이터 분석이나 파일 편집 작업을 자동화하려면 모델이 자유롭게 접근할 수 있는 격리된 실행 환경(Sandboxed Environment)이 필수적입니다. OpenAI가 공개한 Responses API와 컴퓨터 환경(Computer Environment) 결합 방식은 이러한 인프라 고민을 덜어주는 흐름을 보여줍니다. ...

한 줄 요약 — 보안을 개발 마지막 단계의 검문소가 아니라 파이프라인 전체에 녹여내는 데브섹옵스(DevSecOps) 실천법을 통해 예기치 못한 침해 사고를 방지해야 합니다. 왜 보안을 개발 프로세스 전반으로 옮겨야 할까? 새벽 3시, 슬랙(Slack) 채널에 크리티컬 보안 사고 알림이 뜹니다. 운영 중인 쿠버네티스 클러스터에서 암호화폐 채굴(Cryptomining) 활동이 감지되었다는 메시지입니다. 이런 상황은 단순히 이론적인 가설이 아니라 실제 현업에서 빈번하게 발생하는 일입니다. 데브섹옵스(DevSecOps)는 이러한 공격자가 시스템에 침투하기 전에 미리 방어막을 구축하는 일련의 과정입니다. 전통적인 방식에서는 개발이 모두 끝난 뒤 보안 팀이 코드를 검수합니다. 이 시점에서는 이미 수십 개의 취약점이 발견되고, 개발자는 3주 전에 쓴 코드의 맥락을 기억하지 못해 수정이 늦어집니다. 보안이 병목 현상을 일으키는 주범이 되는 셈입니다. 보안을 왼쪽으로 옮기는 쉬프트 레프트(Shift-Left) 전략이 필요한 이유가 여기에 있습니다. ...

한 줄 요약 — 검색 의도를 파악하는 시맨틱 검색과 정확한 키워드를 찾는 렉시컬 검색을 결합하여, 검색 품질과 서버 성능을 동시에 잡는 하이브리드 검색 아키텍처 구현 가이드입니다. 이 주제를 꺼낸 이유 최근 많은 서비스가 벡터(Vector) 기반 시맨틱 검색(Semantic Search)을 도입하고 있습니다. 자연어 질문에 대해 찰떡같은 답변을 내놓는 모습은 분명 매력적이지만, 실무에서 이를 운영하다 보면 의외의 복병을 만납니다. 바로 고유 명사나 API 이름처럼 정확한 텍스트 매칭이 필요한 영역에서 시맨틱 검색이 힘을 쓰지 못한다는 점입니다. ...

AWS 로컬 에뮬레이터인 LocalStack이 점진적으로 유료 기능을 확대하고 커뮤니티 에디션의 제약을 늘려가는 상황에서, 이를 완전히 대체할 수 있는 가볍고 빠른 오픈소스 대안인 Floci가 등장했습니다. 한 줄 요약 — Floci는 LocalStack의 유료화 행보에 대응하여 등장한 MIT 라이선스 기반의 초경량 AWS 로컬 에뮬레이터로, 24ms 수준의 빠른 시작 속도와 낮은 메모리 점유율이 특징입니다. 이 주제를 꺼낸 이유 로컬 개발 환경에서 AWS 인프라를 테스트할 때 LocalStack은 사실상 표준처럼 자리 잡았습니다. 하지만 시간이 흐를수록 LocalStack의 도커(Docker) 이미지는 비대해졌고, 실행하는 데만 수십 초가 소요되는 등 개발 피드백 루프를 저해하는 요소가 되었습니다. 특히 2026년 3월부터 LocalStack 커뮤니티 에디션에서 인증 토큰을 요구하고 CI 지원을 중단한다는 소식은 오픈소스 생태계에 큰 충격을 주었습니다. ...

한 줄 요약 — 쿠버네티스 환경에서 코드 수정 없이 OpenLIT 오퍼레이터를 활용해 LLM과 AI 에이전트의 비용, 지연 시간, 토큰 사용량을 실시간으로 모니터링하는 자동화 전략을 소개합니다. 쿠버네티스 기반 AI 서비스에서 관측성이 왜 해결하기 어려운 과제가 되었을까? 쿠버네티스(Kubernetes) 환경에서 대규모 언어 모델(LLM) 기반 서비스를 운영하다 보면 일반적인 마이크로서비스보다 훨씬 복잡한 문제에 직면합니다. 단순히 서버가 살아있는지 확인하는 수준을 넘어, 특정 에이전트가 왜 반복적인 루프에 빠졌는지, 어떤 사용자가 토큰을 과다하게 소비하여 비용을 발생시키는지 파악해야 하기 때문입니다. ...

한 줄 요약 — Rust와 WebAssembly가 모든 상황에서 JavaScript보다 빠른 것은 아니며, 특히 런타임 간 데이터 교환 비용이 큰 경우에는 오히려 성능이 저하될 수 있습니다. 이 주제를 꺼낸 이유 성능 최적화가 필요한 시점에 많은 개발자가 가장 먼저 떠올리는 선택지 중 하나가 Rust와 WebAssembly(WASM) 조합입니다. JavaScript(JS)의 한계를 넘어서는 네이티브에 가까운 속도를 브라우저에서 구현할 수 있다는 기대 때문입니다. 하지만 실제 프로젝트에 이를 적용해 보면 예상치 못한 병목 구간을 마주하게 됩니다. 최근 OpenUI 팀에서 공유한 사례는 이러한 기술적 맹점을 정확히 짚어줍니다. 그들은 LLM이 생성한 DSL(Domain Specific Language)을 파싱하기 위해 Rust 기반의 WASM 파서를 구축했지만, 오히려 이를 순수 TypeScript(TS)로 재작성했을 때 성능이 2배에서 4배까지 향상되는 결과를 얻었습니다. 이는 단순히 언어의 실행 속도보다 시스템 전체의 데이터 흐름과 경계 비용(Boundary Cost)을 이해하는 것이 얼마나 중요한지를 보여줍니다. ...