LLM 서버에서 prefix caching을 켰습니다. 같은 시스템 프롬프트를 반복해서 보내면 이미 계산한 부분을 재사용할 수 있습니다. 그런데 서버를 여러 대로 늘린 뒤에는 캐시를 켜기 전과 응답 속도가 크게 다르지 않습니다. 이런 상황을 가정해 보겠습니다. 첫 요청은 서버 A로 들어갔고, 같은 프롬프트로 시작하는 다음 요청은 서버 B로 들어갔습니다. A에 계산 결과가 남아 있어도 B가 그 결과를 사용할 수 없다면, B는 같은 부분을 다시 계산해야 합니다. 캐시 기능과 요청을 보내는 방식이 서로 맞지 않는 상황입니다. ...
에이전트가 실행을 마치면 터미널 창은 닫힙니다. 그 안에서 어떤 파일이 왜 바뀌었는지 알고 싶을 때 관찰 대시보드는 비용, 토큰 수, 지연 시간을 보여 줍니다. “왜 그 파일을 삭제했나"라는 질문에는 침묵합니다. 2026년 9월 2일, OrcaRouter(Continuum AI Corp)가 이 문제를 겨냥한 오픈소스 도구를 발표했습니다. OrcaReplay는 AI 에이전트 실행을 전체 이벤트 스트림으로 기록하고, 기록된 그대로 네트워크를 차단한 채 재현하며, 특정 지점부터 다른 모델로 분기(fork)하는 CLI 도구입니다. 라이선스는 Apache-2.0(코드), CC BY 4.0(트레이스 포맷)입니다. 이 글에서는 OrcaReplay의 캡처 아키텍처, 주요 명령어와 출력 형식, LangChain/LangGraph 에코시스템과의 연결성, 그리고 현재 상태와 한계를 정리합니다. 설치와 명령어 예시는 공식 README(2026-09-04 기준)에서 직접 확인한 내용을 바탕으로 합니다. ...
에이전트에 기능을 붙이는 두 조각은 이미 표준이 있습니다. 모델에게 절차적 지식을 주는 Agent Skills와 외부 도구·데이터에 연결하는 MCP입니다. 두 규약 모두 여러 클라이언트가 이미 지원합니다. 그런데 이 조각들을 실제로 배포하려고 하면 예상치 못한 곳에서 마찰이 생깁니다. 컴포넌트 자체는 멀쩡한데 그것을 담는 상자가 클라이언트마다 다르기 때문입니다. 2026년 8월 6일에 발표된 Agent Plugins 1.0.0이 이 상자를 표준화합니다. 오픈이고 벤더에 중립적인 패키징 표준이며, 기술 운영 위원회의 코어 메인테이너는 Amazon, Cursor, Microsoft, OpenAI, Vercel입니다. 발표 이후 Google이 코어 메인테이너로 합류했고, DeepMind의 Kevin Hou가 대표를 맡았습니다. 이 글에서는 표준이 무엇을 정의하고 무엇을 일부러 정의하지 않았는지를 코드 예시와 함께 살펴봅니다. ...
MCP 서버를 로컬에서 하나 띄워 쓸 때는 아무 문제가 없습니다. Claude Desktop이 stdio로 프로세스를 하나 붙이고, 그 프로세스가 살아 있는 동안 세션이 유지됩니다. 프로토콜이 처음 설계될 때 상정한 그림이 정확히 이것이었습니다. 단일 앱, 단일 로컬 서버, 하나의 연결. 같은 서버를 사내 100명이 쓰도록 원격 배포하는 순간 이야기가 달라집니다. 로드밸런서 뒤에 인스턴스를 세 개 띄우면 클라이언트가 처음 handshake한 인스턴스에만 세션이 존재합니다. 두 번째 요청이 다른 인스턴스로 가면 그 인스턴스는 세션을 모릅니다. 그래서 sticky routing을 켜거나, 인스턴스들이 공유하는 세션 스토어를 앞에 두거나, 둘 다 하게 됩니다. ...
코딩 에이전트가 코드를 쓰는 일은 이제 일상이 됐습니다. 문제는 그다음입니다. 그 코드를 누가 검토하는가. 가장 흔한 답은 “같은 에이전트에게 다시 시킨다"입니다. 방금 코드를 작성한 모델에게 “이거 리뷰해줘"라고 한 번 더 부탁하는 식입니다. 편하지만, 여기에는 구조적인 함정이 있습니다. 자기 리뷰의 맹점 같은 세션의 같은 모델이 자기가 쓴 코드를 검토하면, 작성할 때 놓친 가정을 리뷰할 때도 똑같이 놓칩니다. 모델이 어떤 엣지 케이스를 “이건 일어날 리 없지"라고 판단해서 코드에 반영하지 않았다면, 같은 모델은 리뷰 단계에서도 같은 판단을 반복할 가능성이 높습니다. 작성과 리뷰가 동일한 학습 분포에서 나오기 때문입니다. 같은 분포는 같은 사각지대를 만듭니다. ...
1. 여러 모델을 운영하는 비용 프로덕션 환경에서 LLM을 운영하는 팀이라면, 한 가지 모델로 모든 작업을 처리하기 어렵다는 점을 잘 알고 있을 것입니다. 빠른 채팅 응답에는 경량 Instruct 모델을, 복잡한 수학 문제에는 추론 특화 모델을, 이미지 분석에는 멀티모달 모델을, 코드 생성에는 코딩 특화 모델을 각각 배포해야 합니다. 모델마다 별도의 엔드포인트, 라우팅 로직, GPU 할당이 필요하고, 운영 복잡도는 모델 수에 비례해 증가합니다. 2026년 3월 16일, Mistral AI가 공개한 Mistral Small 4는 이 문제에 정면으로 답합니다. 기존에 별도로 존재하던 Instruct(Small 3.2), 추론(Magistral), 비전(Pixtral), 코딩(Devstral) 네 가지 모델 계열을 하나의 MoE 모델로 통합했습니다. 119B 파라미터 규모이지만, 토큰당 실제 연산에 참여하는 파라미터는 6.5B에 불과합니다. Apache 2.0 라이선스로 상업적 사용과 파인튜닝에 제한이 없습니다. ...
왜 지금 ‘통합 데이터·AI 플랫폼’ 전쟁인가 2024년 하반기, 엔터프라이즈 데이터 팀의 주요 고민 중 하나은 “도구가 너무 많다"는 것이었습니다. 데이터 엔지니어링(Data Engineering)은 Spark 클러스터에서, 분석(Analytics)은 SQL 웨어하우스에서, ML 학습은 또 다른 노트북 환경에서 돌아갑니다. 이렇게 파편화된 워크플로를 하나로 엮으려는 수요가 폭발적으로 늘고 있습니다. 개인적으로 여러 엔터프라이즈 프로젝트를 지켜보면, ETL에서 분석, ML 모델링, GenAI 서빙까지 이어지는 파이프라인에서 컨텍스트 스위칭(context switching) 비용이 전체 생산성의 상당 부분 이상을 잡아먹는 경우가 흔합니다. 바로 이 지점을 두 거인이 동시에 노리고 있습니다. ...