찰리초이 스토리 블로그

한 줄 요약: Mac에서 실행되는 Hermes Agent를 Slack에 연결하고, 별도의 딥 리서치 전문 에이전트 ‘리서’까지 추가해 사람과 AI 동료가 같은 채널에서 협업하는 구조를 만들었다. 이번에는 단순히 Slack에 챗봇 하나를 붙인 것이 아니다. ‘맥헬미’는 내 MacBook Air에서 실행되는 Hermes Agent에게 붙인 친근한 별명이다. ‘맥에서 일하는 헬미’라는 뜻으로, 지금 이 글을 함께 만들고 실제 작업을 수행하는 AI 에이전트이기도 하다. 이 맥헬미를 Slack의 정식 팀원처럼 연결하고, 이어서 딥 리서치 전담 동료 ‘리서’를 별도의 에이전트로 구성했다. 마지막에는 나와 맥헬미, 리서가 함께 일할 수 있는 협업 채널까지 만들었다. 먼저 사실관계부터 정확히 말하면 Slack 데스크톱 앱은 내가 Mac에 설치했다. 그다음 Slack 채널 생성, Hermes용 Slack App 구성, Gateway 연결, 사용자 허용 정책, 실제 메시지 왕복 검증은 맥헬미와 함께 자동화해 진행했다. 9월 10일 맥헬미 연결을 시작했고, 9월 11일에는 리서까지 독립 에이전트로 확장했다. 왜 터미널이 아니라 Slack이었나 Hermes는 터미널에서 강력하게 일하지만, 매번 터미널을 열어야 한다면 일상적인 협업 도구가 되기 어렵다. 내가 원한 것은 평소 사용하는 Slack에서 사람에게 말을 걸듯 AI 에이전트에게 요청하는 방식이었다. DM에서는 맥헬미 (나의 헤르메스 닉네임)와 일대일로 대화한다. 프로젝트 채널에서는 맥헬미를 멘션해 업무를 맡긴다. 조사가 필요하면 리서를 멘션해 근거 수집과 교차 검증을 맡긴다. 한 스레드 안에서 사람과 에이전트가 결과를 이어서 검토한다. 목표는 “Slack에서 답변하는 봇”이 아니라, 역할과 기억과 도구를 가진 AI 동료가 실제 업무 공간에 들어오는 것이었다. 1단계: 맥헬미용 Slack 공간 만들기 처음에는 맥헬미와 대화할 전용 공개 채널을 만들었다. 이름은 #mac-helmi 로 정...

한 줄 요약: AI 비용을 줄이는 가장 좋은 방법은 무조건 싼 모델을 고르는 것이 아니다. 반복되는 입력은 캐시하고, 낡은 프롬프트 규칙은 걷어내고, 일의 난이도에 맞춰 AI가 생각하는 강도를 조절해야 한다. Anthropic이 2026년 9월 8일 공개한 글은 흔히 갖는 오해부터 뒤집는다. 보통 비용을 아끼려면 성능을 포기해야 한다고 생각한다. 하지만 Claude Platform을 실제로 운영해 보니, 설정과 프롬프트를 제대로 다듬는 것만으로 비용을 낮추면서 정확도까지 높일 수 있었다는 설명이다. 핵심은 세 가지다. 프롬프트 캐시 적중률을 높이고, 최신 모델에 맞지 않는 낡은 지시문을 없애고, 업무 난이도에 맞춰 effort(생각하는 강도)를 조절하는 것 이다. 기술 용어가 많아 보이지만, 사무실 업무에 빗대면 어렵지 않다. 1. 프롬프트 캐시: 매번 서류철을 처음부터 읽히지 말자 Claude가 답을 만들기 전에는 사용자가 보낸 지시문, 참고자료, 도구 설명, 지금까지의 대화를 먼저 읽고 내부 작업 상태를 만든다. 이 입력 처리 과정을 프리필(prefill)이라고 한다. 긴 문서를 매번 처음부터 읽히면 시간과 비용이 든다. 프롬프트 캐시는 한 번 읽은 공통 내용을 잠시 보관했다가, 다음 요청이 같은 내용으로 시작하면 다시 계산하지 않고 불러오는 기능이다. 캐시 읽기 비용은 전체 입력을 새로 처리하는 비용보다 훨씬 싸다. 예시: 100쪽짜리 사내 규정집을 참고하는 인사 상담 AI 직원이 휴가 질문을 할 때마다 규정집 100쪽을 새로 읽힌다고 해보자. 질문은 한 줄인데 비용 대부분은 같은 규정집을 반복해서 읽는 데 쓰인다. 규정집과 공통 지시문을 앞부분에 고정해 캐시하면, 다음 질문부터는 이미 읽어 둔 규정집을 꺼내 쓰는 것처럼 처리할 수 있다. 캐시가 자꾸 깨지는 이유 앞부분에 현재 시각이나 매번 바뀌는 ID를 넣는다. 캐시는 바이트 단위로 정확히 같아야 하므로 한 글자만 달라도 다른 입력으로 본다. 도구 목록의 순서...

Uber의 Software Factory에서 배울 점: AI 에이전트는 ‘비용’이 아니라 ‘운영 설계’의 문제다 Uber Engineering이 공개한 “Running a Software Factory Efficiently at Uber Scale” 글은 단순한 AI 코딩 도구 소개가 아닙니다. 핵심은 AI 에이전트를 개발 현장에 많이 쓰면서도 비용을 통제하기 위한 운영 구조 입니다. 저는 이 글을 보면서 개인용 AI 오케스트레이션, 특히 제가 정리하고 있는 CPAO(Cost-aware Personal Agentic Orchestration) 와 매우 가까운 문제의식을 느꼈습니다. 규모는 Uber처럼 크지 않더라도, 개인·소규모 조직도 이제 AI를 “가끔 쓰는 도구”가 아니라 “반복 업무를 맡기는 업무팀”으로 운영해야 하는 단계에 들어섰기 때문입니다. 1. Uber가 말하는 AI Software Factory Uber는 AI 도구가 소프트웨어 개발 전 과정에 들어와 있다고 설명합니다. 코드 작성, 코드 리뷰, CI 실패 복구, 버그 분석, 온콜 알림 처리, 유지보수 PR 생성 등 여러 업무가 에이전트 기반으로 움직이고 있습니다. 인상적인 것은 사용량 증가입니다. Uber에 따르면 2026년 2월부터 8월까지 주간 활성 사용자는 7배, 주간 에이전트 요청은 9.4배 증가했습니다. 그런데 총 AI 비용은 4월 이후 비교적 안정화됐다고 합니다. 동일 모델 기준으로 보면 1,000개 요청당 비용은 피크 대비 약 34%, 세션당 비용은 6월 피크 대비 52% 낮아졌다고 합니다. 즉, Uber의 방향은 “AI를 덜 쓰자”가 아닙니다. 오히려 더 많이 쓰되, 낭비되는 턴·요청·토큰을 줄이는 방식 입니다. 2. 핵심은 비용 방정식이다 Uber는 AI 에이전트 비용을 다음과 같은 식으로 분해합니다. 총비용 = 사용자 수 × 세션/사용자 × 턴/세션 × 요청/턴 × 토큰/요청 × 토큰당 가격 이 식이 중요한 이유는 AI 비용을 막연한 “...