vLLM이란 무엇인가
vLLM은 대규모 언어 모델(LLM)을 GPU에서 빠르고 효율적으로 돌리기 위한 오픈소스 추론·서빙 엔진입니다. 모델을 새로 만드는 도구도, 학습 프레임워크도 아닙니다.
vLLM은 대규모 언어 모델(LLM)을 GPU에서 빠르고 효율적으로 돌리기 위한 오픈소스 추론·서빙 엔진입니다. 모델을 새로 만드는 도구도, 학습 프레임워크도 아닙니다.
오픈소스 LLM을 프로덕션에서 운용하려 할 때, 단순히 transformers 라이브러리로 모델을 불러오는 방식은 GPU 메모리 낭비가 심각하고 처리량이 지나치게 낮습니다.
AI Agent가 단순한 질답 시스템을 넘어 복잡한 업무를 수행하려면 "기억"이 필요합니다. 사용자가 어제 요청한 내용을 오늘 이어서 처리하거나, 긴 작업 흐름 속에서 중간 결과를 보존하거나, 조직 전체의 지식을 빠르게 참조하는 능력…
OpenAI가 9월 3일 공개한 GPT-6 Astra를 개발자 입장에서 정리합니다. 컴퓨터 사용, Codex의 노트 기능, 100만 토큰 컨텍스트, API 가격, 요금제별 접근 범위, 그리고 발표문이 크게 말하지 않은 부분까지.
소프트웨어가 성장할수록 기능을 추가하는 비용이 기하급수적으로 증가하는 현상은 많은 팀이 공통적으로 겪는 문제입니다. 초기에는 단순하게 시작했던 코드베이스가 어느 순간 누군가 한 곳을 수정하면 엉뚱한 곳이 터지는, 소위 "스파게티 아키…
네트워크 정책으로 Flux 컨트롤러의 이그레스 트래픽을 Git 저장소와 컨테이너 레지스트리 주소로만 제한하면 추가적인 방어 계층이 생깁니다. 컨트롤러가 의도하지 않은 외부 주소로 데이터를 전송하는 시나리오를 방지하는 데 효과적입니다.
PostgreSQL의 쿼리 플래너는 실행 계획을 선택할 때 테이블과 컬럼에 저장된 통계 정보를 핵심 근거로 삼습니다. 이 통계가 실제 데이터 분포를 정확히 반영하고 있을 때 플래너는 최적의 실행 경로를 선택하지만, 통계가 오래되거나…
마이크로서비스 아키텍처가 일반화되면서 서비스 간 HTTP 통신은 현대 Spring 애플리케이션의 핵심 과제가 되었습니다. Spring HTTP Interface는 Spring 6.0(Spring Boot 3.
Java 애플리케이션을 개발하다 보면 클래스 구조를 런타임에 동적으로 탐색하거나 메서드를 호출해야 하는 상황이 자주 생깁니다. ORM 프레임워크, 직렬화 라이브러리, DI 컨테이너 같은 도구들이 대표적인 사례입니다.
권한이 아직 없어서 파일로는 저장하지 않겠습니다. 아래에 완성된 블로그 포스트를 바로 출력합니다.
Kubernetes 클러스터에서 HTTPS 서비스를 운영하다 보면 TLS 인증서 관리가 생각보다 복잡한 문제로 떠오릅니다.
Apache Cassandra는 분산 환경에서 초당 수십만 건의 쓰기를 처리할 수 있는 NoSQL 데이터베이스로, 시계열 데이터·이벤트 로그·IoT 스트림 같은 쓰기 집약적 워크로드에 자주 채택됩니다.
현대 웹 서비스는 단일 서버에서 운영되던 시대를 벗어나, 여러 인스턴스가 동시에 요청을 처리하는 분산 아키텍처로 전환하고 있습니다.
멀티스레드 프로그래밍에서 가장 까다로운 문제 중 하나는 스레드 간 상태 공유입니다. 공유 객체에 여러 스레드가 동시에 접근할 때 발생하는 경쟁 조건(race condition)과 데이터 불일치를 막기 위해 개발자들은 synchroni…
브라우저 에이전트의 위협 모델은 하나입니다. 웹페이지 내용이 곧 지시문이 될 수 있다는 것. 비밀번호를 아무리 잘 숨겨도 로그인된 세션은 그대로 남습니다.
손익분기는 월 51회입니다. 그보다 자주 돌리면 스크립트가, 그보다 드물면 에이전트가 쌉니다. CI를 통째로 에이전트로 바꾸면 비용이 25배가 됩니다.
코딩 에이전트가 못 하는 건 코드가 아니라 로그인입니다. aside mcp 한 줄로 그 구멍을 메우는 방법과, 메우고 나서 반드시 막아야 할 것들.
연동을 안 만드는 게 요점입니다. 사내 어드민처럼 API가 없는 곳을 사람처럼 클릭해서 처리합니다. CLI와 MCP 서버까지 있어서 Claude Code에 브라우저 손을 붙일 수 있습니다.
100GB/일을 90일 보관하면 월 858만 원입니다. 그런데 그중 스토리지는 3분의 1도 안 됩니다. 진짜 돈은 RAM에서 나가고, 티어를 나누면 84%가 줄어듭니다.
서버비만 세면 절반도 못 셉니다. NAT Gateway, 데이터 전송, 로그, 부가세까지 넣어 취미용 7천 원짜리와 이중화 프로덕션 62만 원짜리를 끝까지 계산했습니다.
웹 서비스의 파일 업로드는 multipart/form-data로 구현하는 것이 관례지만, 대용량 파일에서는 스트리밍 방식이 메모리와 응답 시간을 근본적으로 바꿉니다. 두 방식의 동작 원리와 선택 기준을 정리합니다.
"공유된 개념화의 명시적 명세"라는 정의는 아무것도 설명해주지 않습니다. DB 스키마와 뭐가 다른지, 그리고 LLM 시대에 왜 이 말이 다시 나오는지 씁니다.
분산 시스템에서 네트워크 장애나 타임아웃으로 인해 동일한 요청이 중복 처리되는 문제를 멱등성(Idempotency) API 설계로 안전하게 해결할 수 있습니다.
Kubernetes 클러스터에서 컨테이너 이미지를 빌드해야 하는 상황은 현대 CI/CD 파이프라인에서 매우 흔하게 맞닥뜨리는 과제입니다.
MySQL 5.7.8에서 공식 JSON 타입이 도입된 이후, 관계형 데이터베이스에서 유연한 스키마를 다루려는 수요가 크게 늘었습니다.
수평 확장(horizontal scaling)이 보편화된 현재 서비스 환경에서 @Scheduled 애노테이션은 의외로 위험한 존재가 될 수 있습니다.
Java 8의 Stream API가 등장했을 때, parallel() 메서드는 개발자들에게 병렬 처리의 민주화를 약속했습니다. .stream() 대신 .parallelStream()을 입력하거나, 스트림 중간에 .
숙련 개발자 16명을 무작위 배정한 실험에서 AI를 쓴 쪽이 19% 더 느렸습니다. 더 흥미로운 건 그들이 끝나고도 20% 빨라졌다고 믿었다는 점입니다.
이 질문에 자신 있게 답하는 글은 대개 데이터가 없습니다. 확실히 아는 것과 모르는 것을 나누고, 그 사이에서 무엇을 할 수 있는지 씁니다.
이 질문에 숫자로 답하는 글이 많지만, 그 숫자 대부분은 당신의 코드베이스에 대해 아무것도 말해주지 않습니다. 직접 재는 방법을 씁니다.
한국에는 원화 정가가 없습니다. 부가세와 카드 수수료까지 넣은 실제 월 부담액을 먼저 계산하고, 플랜을 가르는 진짜 기준을 봅니다.
"Pro는 하루 몇 개"라는 답을 기대하셨다면 실망하실 겁니다. 그 숫자가 존재할 수 없는 이유와, 대신 무엇을 조절해야 하는지 씁니다.
둘 다 실부담 월 3만 원 남짓입니다. 그래서 가격은 기준이 못 됩니다. 진짜 차이는 '코드를 누가 읽느냐'에 있습니다.
임베딩 비용부터 계산하는 글이 많은데, 대개 거기가 가장 안 중요한 항목입니다. 실제 손익분기가 어디서 갈리는지 계산해 봅니다.
리더보드 점수로 고르면 대체로 후회합니다. 한국어, 차원 수, 그리고 실제로 재야 하는 지표를 기준으로 정리했습니다.
표시가 20달러가 통장에서는 3만 원입니다. 부가세와 카드 수수료까지 넣은 실제 금액을, 넷플릭스가 아니라 자기 시급과 비교해 봅니다.
"학습에 쓰이나"는 이 질문의 일부일 뿐입니다. 공식 정책이 실제로 무엇을 보장하는지, 그리고 진짜 위험이 어디 있는지 나눠서 봅니다.