전체 글
-
에러가 없으면 에이전트는 멈추지 않는다: 전진 본능과 브레이크를 설계에 넣는 법AI 2026. 11. 4. 21:02
에이전트에게 데이터 1,000건을 변환하라고 시켰다고 하자. 프로세스는 exit code 0으로 끝나고, 요약에는 "99%를 성공적으로 변환했습니다. 다음 단계로 넘어가겠습니다"라고 적힌다. 이 문장에서 가장 중요한 정보는 빠졌다. 나머지 10건이 무엇이고 왜 실패했는지 아무도 모른다.에이전트가 스택 트레이스를 읽고 고치는 솜씨는 이제 놀랍지 않다. 어려운 문제는 그 반대편에 산다. 아무것도 터지지 않았는데 결과가 틀린 경우다. 이 글은 그 실패 모드를 다룬다. 이름은 한 연구자의 강의에서 빌리고, 사례는 공개 저장소의 PR에서 가져온다.요약에이전트는 에러 메시지를 신호 삼아 잘 고친다. 신호가 없는 오류 앞에서는 그대로 다음 단계로 간다. 안상진 교수는 이 경향을 "전진 본능"이라 불렀다.사람의 감각에..
-
에이전트를 늘릴수록 왜 실패할까: 앤트로픽이 멀티 에이전트를 단일 루프로 합치라고 권고한 이유AI 2026. 11. 3. 09:04
복잡한 비즈니스 문제를 해결하려는 AI 개발팀은 자연스럽게 멀티 에이전트 아키텍처를 떠올린다. 주문 처리 에이전트, 배송 조회 에이전트, 취소 환불 에이전트처럼 역할을 잘게 쪼개고 라우터가 이들을 조율하는 구조다. 인간 조직의 분업 모델을 닮았기에 직관적이며 모듈화도 깔끔해 보인다.프로덕션 환경에 배포하는 순간 기대는 무너진다. 에이전트 사이를 오가는 인수인계 과정에서 핵심 제약 조건이 유실된다. 팀마다 제각각 덧붙인 프롬프트 규칙이 충돌하며, 요청 하나를 처리하는 데 드는 지연 시간과 토큰 비용이 폭증한다. 각 하위 에이전트는 독립 테스트를 만점으로 통과해도 고객이 마주하는 최종 결과물은 실패로 끝난다.Claude 3.5 Sonnet과 Claude Code를 만드는 앤트로픽(Anthropic)의 응용 ..
-
디스크리스 카프카(Diskless Kafka): 브로커가 데이터를 소유하지 않을 때 일어나는 분산 아키텍처의 전환 — KIP-1150과 객체 스토리지 기반 스트리밍ARCHIVE 2026. 10. 31. 09:06
아파치 카프카(Apache Kafka)는 지난 15년간 대규모 분산 스트리밍의 표준으로 군림했다. 2011년 링크드인(LinkedIn)의 NetDB 논문에서 제시된 설계 철학은 명확했다. 디스크의 순차 I/O(Sequential I/O), OS 페이지 캐시(Page Cache), 커널 공간에서 네트워크 소켓으로 버퍼를 직접 전달하는 sendfile 제로 카피(Zero-copy)다. 이 구조에서 브로커는 파티션 로그 파일(partition-N.log)을 로컬 디스크에 직접 저장하고, 복제본 상태를 스스로 관리했다.온프레미스 베어메탈 서버를 위해 태어난 이 설계는 퍼블릭 클라우드 환경에서 막대한 인프라 비용과 운영 마찰을 일으킨다. 3개 가용 영역(AZ)에 걸쳐 복제본을 유지하는 클러스터는 기가바이트(GiB..
-
프롬프트 대신 코드베이스를 고쳐라: Cursor 1,000개 PR 자동 머지와 에이전트 신뢰 곡선AI 2026. 10. 29. 09:03
코딩 에이전트를 도입한 개발팀의 일상은 대개 불신으로 시작한다. 에이전트가 만든 코드가 그럴듯해 보여도 한 줄씩 뜯어보며 검토한다. 엉뚱한 라이브러리를 임포트하거나 미묘한 논리 버그를 심어두지 않았는지 감시하는 사이, 개발자는 지치고 만다. 에이전트를 10개, 100개 띄워 병렬로 실행하자는 제안은 공허하게 들린다. 에이전트 하나가 내놓는 코드조차 믿지 못하는데 100개를 돌리면 리뷰 대기열만 폭발하기 때문이다.Cursor와 SpaceXAI를 거친 로렌 탄(Lauren Tan)은 정반대의 운영 모델을 증명했다. 한 달 만에 에이전트가 작성한 PR 1,000개를 머지했고, 다음 달에는 12일 만에 800개 PR을 처리했다. 아침에 출근하면 에이전트가 밤새 작성하고 자동 머지까지 끝낸 PR 20여 개가 메인..
-
DB 커넥션 풀 사이징: 왜 커넥션을 늘려도 TPS가 오르지 않을까? — 코어×2 공식과 리틀의 법칙ARCHIVE 2026. 10. 24. 09:06
웹 서비스 트래픽이 급증하고 응답 지연이 발생할 때, 개발자가 가장 흔하게 저지르는 실수가 있다. WAS의 데이터베이스 커넥션 풀(Connection Pool) 크기를 10에서 50, 100, 200으로 무작정 늘리는 조치다. "일꾼이 많으면 밀린 일도 빨리 끝나겠지"라는 직관에 기댄다.결과는 정반대로 흐른다. 커넥션 풀을 늘리자마자 데이터베이스 서버 CPU 사용률이 100%를 찍고, 쿼리 응답 시간은 급증하며, 시스템 전체가 마비에 빠진다.커넥션 수가 늘어난다고 처리량(TPS)이 비례해 오르지 않는다. 오히려 특정 임계점을 넘는 순간 성능이 곤두박질친다. 이 역설을 이해하고 데이터베이스 하드웨어에 맞는 최적의 커넥션 풀을 산정하는 기준을 정리한다. 🔍 클릭하여 확대 flowchart LR s..
-
Playwright를 두고 왜 Ego Lite가 등장했을까: 드라이버에서 에이전틱 브라우저 런타임으로의 진화AI 2026. 10. 23. 05:07
Playwright를 두고 왜 Ego Lite가 등장했을까: 드라이버에서 에이전틱 브라우저 런타임으로의 진화핵심 요약: Playwright는 오늘날 대다수 AI 에이전트(Playwright MCP, Browser Use, Stagehand)의 핵심 실행 엔진으로 활약합니다. 그럼에도 최근 Ego Lite, Steel, Browserbase 같은 전용 도구가 쏟아져 나옵니다. 원인은 브라우저 조작 주체가 '정적 코드를 작성하는 인간 엔지니어'에서 '실시간 DOM을 추론하는 LLM'으로 바뀌었기 때문입니다. 에이전트가 전통적 자동화 드라이버를 직접 호출할 때 마주치는 4대 병목(프로필 락, 턴 바이 턴 왕복 지연, 포커스 탈취, 시각 토큰 낭비)을 해부하고, 브라우저 애플리케이션 자체가 에이전트 런타임으로 ..
-
마이크로서비스 게이트웨이를 넘어: 에이전트 게이트웨이와 MCP 호출 통제 아키텍처AI 2026. 10. 22. 09:03
대규모 언어 모델(LLM)이 단독 챗봇을 넘어 시스템 외부 세계와 상호작용하는 에이전트로 진화하면서, 도구 호출(Tool Calling) 표준으로 Model Context Protocol(MCP)이 급부상했다. 엔터프라이즈 환경에서 팀별로 수십, 수백 개의 MCP 서버를 배포하기 시작하자 마이크로서비스 초기와 유사한 인프라 혼란이 재현된다.각 에이전트 클라이언트는 개별 MCP 서버의 연결 주소를 직접 관리하고, 보안 정책과 권한 통제는 서버마다 제각각 흩어진다. 모델이 생성하는 도구 호출은 비결정론적이어서 기존 정적 방화벽이나 API 게이트웨이 규칙으로 방어하기 어렵다.이 문제를 해결하기 위해 에이전트와 도구 서버 사이의 단일 길목(Chokepoint)을 통제하는 에이전트 게이트웨이(Agent Gatew..
-
AI 클러스터에서 TCP의 종말: GPU 아이들링을 끝내는 차세대 전송 프로토콜 HomaAI 2026. 10. 20. 09:03
대규모 AI 분산 환경의 네트워크 병목이 대역폭(Throughput)에서 극단적인 마이크로 지연 시간(Tail Latency)으로 이동했다.과거 모델 학습(Training) 중심 워크로드는 수 기가바이트 단위의 가중치와 그래디언트를 전송하는 벌크 트래픽이 지배했다. 반면 최신 분산 추론과 복합 에이전트 시스템은 수십 바이트에서 수 킬로바이트 수준의 소형 메타데이터, 분산 KV 캐시 동기화, 라운드별 배리어 동기화(Barrier Synchronization)를 쉼 없이 교환한다.수백 개의 최신 GPU가 밀리초 단위로 연산을 마쳐도 단 하나의 네트워크 패킷 지연 때문에 전체 노드가 멈춘다. 스탠포드 대학교 존 오스터하우트(John Ousterhout) 교수가 이끄는 연구진은 반세기 동안 인터넷을 지탱한 TC..