찰리초이 스토리 블로그

한 줄 요약: Claude Opus 5.5는 장황한 사고 지시보다 effort , 완료 조건, 진행 보고, 도구 운영 규칙을 분명히 설계할 때 더 효율적으로 일한다. [1] 왜 중요한가 Claude Opus 5.5는 Opus 5보다 출력 토큰을 30% 이상 빠르게 생성하고, 같은 일을 더 적은 토큰으로 마치는 경향이 있다. 기존 Opus 5용 프롬프트도 대체로 작동하지만, 생각 기능이 항상 켜져 있고 장시간 에이전트 작업 방식이 달라졌기 때문에 모델에 넣는 문장뿐 아니라 이를 둘러싼 실행 장치, 즉 하네스까지 함께 조정해야 한다. [1] 여기서 핵심은 “더 깊게 생각해”라고 반복하는 것이 아니다. 비용·속도·품질을 좌우하는 설정, 작업이 끝났는지를 판정하는 조건, 중간 진행 상황을 사용자에게 전달하는 방식, 위험한 행동 앞에서 멈추는 규칙을 분리해 설계하는 것이다. 먼저 알아둘 변화 코딩과 코드 리뷰: 실제 저장소에서 여러 단계를 끝까지 수행하고 테스트까지 통과시키는 장기 작업이 강화됐다. [1] 지식 업무: 큰 문서와 스프레드시트에서 숫자·날짜·차트의 불일치를 찾는 능력이 개선됐다. [1] 시각 자료와 컴퓨터 사용: 복잡한 차트, 흐름도, 화면 캡처의 위치 관계를 더 정확하게 읽고 여러 단계의 화면 조작을 더 안정적으로 수행한다. [1] 진행 보고: 작업 중간과 마지막에 무엇을 했고, 무엇을 찾았으며, 사용자에게 무엇이 필요한지 비교적 명확하게 설명한다. [1] 실전 원칙 10가지 1. 기본은 medium effort에서 시작한다 Opus 5.5의 기본 effort는 medium이다. 이전 모델의 설정을 그대로 옮기지 말고, medium을 명시한 뒤 실제 업무 평가 데이터로 low·high 등을 비교하는 것이 좋다. 비용이나 응답 시간이 문제라면 프롬프트로 “짧게 생각하라”고 압박하기 전에 effort를 낮추는 편이 더 직접적이다. [1] effort: medium max_tokens: 작업 유형에 맞게 충분히 확보...

한 줄 요약: 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 비용을 막연한 “...