찰리초이 스토리 블로그

OpenAI 공식 가이드 정리 GPT-6 패밀리 실전 사용 가이드: 모델 고르기부터 운영까지 OpenAI가 2026년 10월 2일 공개한 "A model guide for the GPT-6 family"를 바탕으로, 어떤 모델을 쓰고 어떻게 지시하고 비용을 어떻게 관리할지 정리합니다. GPT-6은 하나가 아니라 세 가지 모델입니다 GPT-6은 작업 성격에 맞춰 고르는 "모델 세트"로 나왔습니다. 토큰(token) 은 모델이 글을 읽고 쓸 때 쪼개서 세는 단위이고, 가격은 보통 "입력 100만 토큰당 $얼마"로 표시됩니다. GPT-6 Astra 가장 어려운 추론 작업용. 입력 $10 / 출력 $50 / 캐시입력 $1 (100만 토큰당) GPT-6.1 Sol 복잡한 코딩·리서치·컴퓨터 사용(Computer Use)용. Astra에 근접한 지능을 1/5 가격에 제공. 입력 $2 / 출력 $10 / 캐시입력 $0.1 GPT-6 Luna 송장 항목 추출, 요청 분류, 구조화된 요약처럼 반복이 많은 대량 작업용. 입력 $0.1 / 출력 $0.5 / 캐시입력 $0.01 선택 기준 가장 어려운 문제엔 Astra, 코딩·에이전트 작업의 기본값은 Sol, 반복 대량 처리는 Luna로 내려서 비용을 절약합니다. 예시. 사내 고객센터 문의를 매일 5,000건씩 "환불/배송/기타"로 분류하는 작업이라면 Luna가 적합합니다. 반대로 신규 계약서의 법적 리스크를 분석해 조항을 다시 쓰는 작업은 Astra가 맞습니다. 중간 난이도의 코드 리팩터링이나 버그 수정-테스트 반복은 Sol이 가...

항공권 예약 그 이상 — Hermes Agent 326개 실사용 사례로 본 '에이전트 시대'의 실제 모습 2026-10-05 · Nous Research 공식 발표 분석 Nous Research가 자사 X 계정을 통해 "Hermes Agent는 항공권 예약 그 이상이다"라며 실제 사용자 326개 사례 모음을 공개했다 ( 원문 트윗 · 전체 목록 ). X, Reddit, GitHub, YouTube, 블로그, 팟캐스트, 링크드인 등 11개 채널에서 수집된 이 사례들은 "에이전트가 실험실을 벗어나 실제로 무엇을 하고 있는가"를 보여주는 꽤 정직한 스냅샷이다. 1. 숫자로 보는 구도 326개 사례는 15개 카테고리로 분류되어 있다. 압도적 1위는 역시 개발 워크플로우지만, 2위인 '개인 비서'가 전체의 15%를 차지한다는 점이 주목할 만하다 — 비개발자 사용자층이 결코 작지 않다는 뜻이다. Dev Workflow 77 Personal Assistant 49 Integrations 32 Creative 26 Business Ops 23 Meta & Ecosystem 23 Cost Optimization 20 Privacy & Self-Hosted 13 Content Creation 12 Research 12 Enterprise 12 Messaging 11 출처 채널: Discord 116 · X/Twitter 61 · Reddit 60 · GitHub 38 · Blog 20 · YouTube 17 · GitHub Gist 4 · Hacker News 4 · LinkedIn 3 · Podcast 2 · Product Hunt 1 2. 다섯 가지 패턴 ① "24시간 켜져 있는 직원" 서사가 압도적으로 많다 $175짜리 중고 Dell OptiPlex, 라즈베리파이5, 5년 된 고장난 GPU 노트북처럼 저사양 장비에서 Her...

Anthropic 개발자 가이드 정리 Claude Sonnet 5.5로 넘어가기: Anthropic 공식 빌딩 가이드 요약 Anthropic은 2026년 9월 28일, 자사 개발자 블로그(claude.dev)에 “Building with Claude Sonnet 5.5”라는 가이드를 올렸습니다. Addy Osmani가 작성한 이 글은 Sonnet 5에서 Sonnet 5.5로 모델 이름만 바꾼다고 마이그레이션이 끝나는 게 아니라고 말합니다. 이 글은 그 원문 내용을 그대로 정리한 것입니다. 언제 Sonnet 5.5, 언제 Opus 5.5를 쓸까 Claude 5.5 패밀리에서 Opus 5.5는 신중한 판단이 필요한 복잡한 작업용이고, Sonnet 5.5는 범위가 명확한 일상적인 작업용입니다. 가까운 시일 안에 대용량·저지연 작업을 위한 Claude Haiku 5.5도 합류할 예정입니다. 작업 유형 추천 모델 버그 수정, 빠른 기능 반복, 요구사항 검증 등 범위가 명확한 일상 코딩 Sonnet 5.5 대용량 일상 개발 Sonnet 5.5 한 페이지 문서, 다이어그램, 슬라이드 요약, 문서 편집, 스프레드시트 정리 등 디자인 감각이 필요한 작업 Sonnet 5.5 조사·리뷰·초안 작성처럼 반복 실행하는 정형화된 에이전트 작업 Sonnet 5.5 장시간에 걸친 에이전트형 코딩, 신중한 판단이 필요한 지식노동 Opus 5.5 가장 높은 수준의 지능이 필요한 난제 Opus 5.5 "Epic의 초기 테스트에서 Sonnet 5.5는 상위 티어 모델에 준하는 품질 기준을 통과했고, 시스템 설계 감사와 데이터 흐름 리뷰에서도 제 몫을 했습니다. 게임플레이 시스템 아키텍처를 위한 수만 줄의 코드를 관리하면서도 응답이 빨랐고, 여러 시간에 걸친 작업도 처리했으며, 덜 구체적인 프롬프트로...

AI 모델 소식 · 2026.09.28 Claude Sonnet 5.5 발표, Opus 5.5와 무엇이 같고 무엇이 다른가 Anthropic이 9월 28일 Claude Sonnet 5.5를 공개했습니다. 일주일 전에 나온 최상위 모델 Opus 5.5와 가격, 성능, 사용 상황을 나란히 비교해 봅니다. 한 줄 요약 Sonnet 5.5는 Opus 5.5의 절반 가격 입니다. 여러 벤치마크에서 Opus 5.5에 근접하거나 앞서지만, 어렵고 결과가 열려 있는 작업은 여전히 Opus 5.5가 더 강하다고 Anthropic이 밝혔습니다. Sonnet 5.5는 어떤 모델인가 Sonnet은 Claude 모델군의 중간 등급으로, 일상 업무를 맡는 실무형 모델입니다. 5.5는 이전 Sonnet 5보다 출력 속도가 30% 이상 빠르고, 같은 일을 더 적은 토큰으로 끝내 작업당 비용이 최대 30% 줄었다고 합니다. 여기서 토큰 은 AI가 글을 읽고 쓸 때 세는 단위로, 사용료 계산의 기준입니다. Anthropic은 범위가 정해진 일상 작업, 버그 수정, 문서·슬라이드·스프레드시트 작성에 강하다고 소개합니다. 디자인 감각도 좋아졌다고 합니다. 하위 모델 Haiku 5.5는 몇 주 안에 나올 예정입니다. 가격 비교 (100만 토큰당) Sonnet 5.5 입력: $2 출력: $10 캐시 쓰기: $2.50 캐시 읽기: $0.20 컨텍스트: 100만 토큰 Opus 5.5 입력: $4 출력: $20 캐시 쓰기: $5 캐시 읽기: $0.20 컨텍스트: 100만 토큰 입력은 AI에게 보내는 내용, 출력은 AI가 써 주는 내용입니다. 컨텍스트 윈도우 는 AI가 한 번에 기억하며 다룰 수 있는 분량입니다. 캐시는 같은 내용을 반복해 보낼 때 저렴하게 처리하는 방식입니다. Sonnet 5.5의 가격은 Sonnet 5와 같습니...

한 줄 요약: 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 에이전트 비교 · 2026년 9월 25일 Muse와 OpenClaw: 같은 에이전트인가, 새로운 개인비서인가 Muse가 OpenClaw 코드를 그대로 실행하는 클론이라는 증거는 없습니다. 다만 에이전트의 기본 구조와 제품 철학은 크게 닮았고, Muse의 새로움은 개념보다 배포 방식·보안 모델·대중화에 있습니다. 에이전트 개념은 OpenClaw ≈ Muse입니다. 구현은 다릅니다. OpenClaw가 사용자가 직접 운영하는 개방형 하니스라면, Muse는 Meta가 호스팅하는 소비자용 서비스입니다. 1. 왜 ‘일반인용 OpenClaw’라는 말이 나왔나 Muse 출시 뒤 초기 사용자들은 두 제품의 내부 파일 체계를 비교했습니다. SOUL.md , IDENTITY.md , USER.md , MEMORY.md , AGENTS.md , TOOLS.md 같은 이름뿐 아니라, 에이전트의 성격과 행동 경계를 정하는 문장까지 비슷하다는 지적이 나왔습니다. The Verge도 두 제품이 핵심 파일 이름과 “Be genuinely helpful, not performatively helpful” 같은 문구를 공유한다고 보도했습니다. [2] 파일 규약 OpenClaw: 성격·사용자·기억·도구를 텍스트 파일로 관리합니다. Muse: 이름과 역할이 유사한 파일 체계가 관찰됐습니다. 제품 형태 공통점: 질문에 답하는 챗봇을 넘어 브라우저와 도구를 사용해 실제 일을 수행하는 개인 에이전트를 지향합니다. 논란의 핵심은 화면이 비슷하다는 정도가 아닙니다. 에이전트 하니스, 즉 모델이 기억·도구·규칙을 활용하도록 둘러싼 실행 구조와 성격 문서까지 닮았다는 점입니다. 2. Meta의 공식 설명 Meta Superintelligence Labs 제품 책임자 Nat Friedman은 Muse를 “처음부터 새로 만들었지만, 제품으로서는...

한 줄 요약: Jev는 글을 생성하는 챗봇이 아니라, 소프트웨어가 직접 사용할 판단값과 확률을 100ms 내외로 빠르게 반환하는 System One 의사결정 전용 모델 이다. 최근 AI 개발자 커뮤니티에서 Jev 가 빠르게 주목받고 있다. 항공권을 약 7초 만에 찾고, 광고 수백 개를 수십 초 안에 분석하고, 논문 1,018편을 0.08달러에 분류했다는 사례들이 등장했다. 숫자만 보면 새로운 초고속 생성형 AI처럼 보인다. 하지만 Jev를 ChatGPT나 Claude의 더 빠르고 저렴한 대체품으로 이해하면 핵심을 놓친다. Jev는 글을 생성하는 AI가 아니라, 소프트웨어가 사용할 판단값을 빠르게 반환하는 의사결정 전용 모델이다. TypeSafe AI는 이를 새로운 모델 계열인 System One Model 이라고 부른다.[1] 이 글에서는 TypeSafe의 공식 발표와 개발 문서, 초기 활용 사례를 바탕으로 다음 질문에 답한다. Jev는 정확히 무엇인가? 기존 LLM과 무엇이 다른가? 어떤 업무에 유용한가? Hermes 같은 AI 에이전트와 어떻게 연결할 수 있는가? 기업 데이터와 개인정보를 외부 API로 보내는 보안 문제는 어떻게 봐야 하는가? 1. 기존 LLM이 자동화에서 부딪히는 문제 ChatGPT, Claude, Gemini와 같은 LLM은 기본적으로 사람이 읽는 문자열을 생성하는 모델 이다. 보고서 작성, 설명, 대화, 코드 생성에는 매우 강력하다. 그러나 기업의 업무 시스템이 필요한 것은 종종 긴 설명문이 아니다. 예를 들어 고객 문의가 들어왔을 때 프로그램이 알고 싶은 것은 다음과 같다. 어느 부서가 처리해야 하는가? 긴급도는 얼마인가? 환불 요청인가? 사람이 확인해야 하는가? 자동 처리해도 되는가? 일반 LLM에 이런 질문을 하면 자연스러운 문장이나 JSON을 생성하도록 프롬프트를 작성한 뒤, 결과를 다시 파싱하고 검증해야 한다...