programi의 개발 노트

사내에서 Claude Code를 도입하는 일정을 분기별로 되짚어보면, 어느 시점부터는 "사람이 작업을 하나씩 지시하는" 루프 자체가 병목이 되는 순간이 온다. 핀테크 회사 Imprint의 엔지니어링 블로그 Irrational Exuberance에 올라온 글이 바로 이 지점을 다룬다. 2026년 1월에는 전 엔지니어가 매일 Claude Code를 쓰게 만들었고, 3월에는 엔지니어가 아닌 팀까지 Claude Code·Claude Cowork를 매일 쓰도록 확장했다. 4월에는 로컬 개발 환경이 저장소 단위의 체크아웃(checkout, 원격 저장소 코드를 로컬로 내려받는 작업) 구조 때문에 병목이 걸려서, 리포지토리가 아니라 워크스페이스 단위로 작업하는 구조로 바꿨다. 각 워크스페이스는 프론트엔드·백엔드·인프라..

PlanetScale에서 Postgres 클러스터를 새로 만들다가 아키텍처 선택 화면 앞에서 멈칫한 적이 있다. aarch64(ARM 계열 명령어 집합)와 x86-64 중 하나를 고르라는데, vCPU(가상 CPU 코어 1개에 해당하는 과금 단위) 개수와 RAM 용량이 똑같은 두 옵션이 왜 따로 나뉘어 있는지 바로 이해가 안 됐다. 더 찾아보니 이 선택은 나중에 쉽게 바꿀 수 없는 결정이었다. 클러스터를 만든 뒤에 아키텍처만 갈아타는 기능은 제공되지 않는다. 그래서 이 차이가 실제로 데이터베이스 성능에 어떤 영향을 주는지 정리해본다.기술 개요 & 등장 배경x86과 ARM은 애초에 풀려는 문제가 달랐다. x86은 1978년 인텔에서 시작해 데스크톱 환경에서 자랐다. IBM이 초기 개인용 컴퓨터(PC)에 x8..

최근 팀 내에서 "이거 에이전트 맞나요?", "그럼 하네스는 누가 만들죠?" 같은 질문이 오갈 때마다 서로 다른 그림을 그리고 있다는 걸 느꼈다. 누군가는 "Context에 넣어두면 된다"고 하고, 누군가는 "그건 Memory 아니냐"고 되묻는다. MCP와 A2A도 마찬가지다. 기존 REST API랑 뭐가 다르냐는 질문에 바로 답하기 어려웠다. 네이버 D2 블로그에 올라온 "에이전트, 개념부터 같이 정리해봐요" 세션(원문 링크)도 같은 문제의식에서 출발한다. Anthropic·OpenAI·MCP·A2A 스펙 원문을 다시 읽고 실물을 확인해본 결과를 공유하는 발표다. 이 글에서는 그 문제의식을 따라가면서, 용어들을 실무 관점에서 다시 정리해본다.기술 개요 & 등장 배경용어 혼란이 생기는 근본 원인은 "에이..

OpenAI가 GPT-6 시리즈의 새로운 미드티어 모델인 GPT-6.1 Sol을 전격 공개했습니다. 이번 업데이트의 핵심은 단순한 지능 향상이 아닌, "최상위 플래그십 모델(GPT-6 Astra)급의 성능을 1/5 수준의 비용으로 제공한다"는 점입니다. 특히 개발자들의 에이전틱 코딩(Agentic Coding)과 비동기 AI 파이프라인 구축 비용을 획기적으로 줄여줄 수 있는 모델로 주목받고 있습니다.기술 개요 & 등장 배경기존 GPT-6 라인업에서 최고 성능을 내는 GPT-6 Astra는 뛰어난 추론 능력을 보여주었지만, 토큰당 단가와 Task당 실행 비용이 높아 24시간 계속해서 돌아가는 에이전트(Agent) 워크플로우에 적용하기에는 비용 부담이 컸습니다. 반면 기존 Sol 모델은 가성비는 좋았으나 복..

Kafka 컨슈머(카프카 토픽에서 메시지를 읽어 처리하는 애플리케이션) 로그를 들여다보다가 이상한 패턴을 본 적이 있다. 컨슈머가 멀쩡히 떠 있는데 브로커(Kafka 클러스터의 메시지 저장·중계 서버)가 갑자기 해당 컨슈머를 죽은 것으로 판단하고 파티션을 다른 인스턴스로 재분배하는 현상이다. 이걸 리밸런스(rebalance)라고 부르는데, 원인을 추적해보면 대부분 컨슈머 내부에서 외부 API나 DB 호출이 오래 걸려 하트비트(heartbeat, 컨슈머가 "나 살아있다"고 브로커에 보내는 주기적 신호)를 제때 못 보낸 경우다. 이 문제를 정면으로 다룬 오픈소스 라이브러리가 WKafka이고, 이번 글에서 다루는 내용은 해당 프로젝트의 엔지니어링 시리즈 10일차 글을 정리한 것이다.기술 개요 & 등장 배경일반..

툴을 호출할 수 있는 AI 에이전트를 붙이고 나서 세 시간쯤 지나면, 누구나 한 번은 이 질문 앞에 서게 된다. "사용자가 일부러 악의적인 입력을 넣으면 이 에이전트는 어떻게 반응하는가." 에이전트가 실수로 틀린 답을 내놓는 상황이 아니라, 누군가 작정하고 깨려고 달려드는 상황이다. DEV Community에 올라온 "I attacked my own AI agent before someone else did"는 바로 이 지점을 실제로 공격해보고 기록한 글이다.기술 개요 & 등장 배경여기서 다루는 공격 기법은 프롬프트 인젝션(prompt injection)이다. 공격자가 일반 텍스트 입력 안에, AI 모델이 개발자의 지시라고 착각할 만한 문장을 몰래 끼워 넣어 원래 설계된 동작을 우회시키는 방식이다. 원문..

에이전트 파이프라인에 붙인 과학 도구 호출 로그를 들여다보다가 이상한 패턴을 발견한 적이 있다. API 응답 코드는 200이고 에이전트는 "성공"이라고 보고하는데, 실제로 돌아온 데이터는 필드 몇 개가 비어 있거나 검색 결과 개수가 기대보다 훨씬 적었다. 에러도, 경고도 없이 그냥 조용히 일부만 돌아온 것이다. 이번에 소개할 논문 "Silent Failures in Agent-Tool Interaction: An Audit of ToolUniverse"(arXiv:2609.26836)는 바로 이 현상을 정면으로 다룬다.기술 개요 & 등장 배경최근 에이전트형(agentic) AI 시스템은 여러 개의 외부 도구를 자동으로 연결해 파이프라인을 구성하는 방식으로 진화하고 있다. 에이전트가 스스로 검색 API를 ..

TypeSafe AI 'Jev' 뜯어보기생성 기능 다 빼고 '결정(Decision)'에만 미친 AI 모델이 나온 이유▲ 상태(State)를 입력받아 타입화된 결정(Typed Decisions)만 초고속으로 출력하는 Jev 아키텍처 개념도 요즘 AI 에이전트나 백엔드 파이프라인 만들 때 제일 골치 아픈 게 하나 있다.유저 요청이 들어왔을 때 "이 요청이 환불 문의인가, 그냥 잡담인가?" 혹은 "다음 스텝으로 넘겨도 되는 상태인가?" 같은 단순 분류나 라우팅을 해야 하는 순간인데, 이걸 처리하자고 GPT-4o나 Claude 같은 거대한 LLM을 붙이자니 비용도 무겁고 Latency(응답 시간)도 터무니없이 느리다.그렇다고 JSON output mode로 꾸역꾸역 타입 파싱하자니 가끔 스키마 깨져서 에러 나는..