찰리초이 스토리 블로그

 

▲ 썸네일을 누르면 YouTube 영상으로 이동합니다. 답변을 넘어 접수 확인까지: 피클로 살펴본 AI 에이전트의 완수 조건 AI에게 맡기는 단위가 달라진다 일을 맡겼는데 다시 챙겨야 한다면 위임의 효과는 작다. 신청 방법을 알아낸 뒤 로그인하고, 서류를 채우고, 회신을 기다리는 과정이 그대로 남기 때문이다. 개인 AI 에이전트 피클의 사례에서 눈여겨볼 대목은 답변의 유창함보다 실행의 범위다. 브라우저와 이메일, 문서와 일정을 오가며 하나의 목표를 실제 결과까지 이어 간다. 여기서 위임의 단위는 질문 한 개가 아니라 완료 상태다. “신청 절차를 알려 달라”는 요청은 안내문으로 끝날 수 있다. “접수를 마치고 결과를 확인해 달라”는 요청에는 인증, 필수 항목 점검, 제출 증거 확보와 후속 확인까지 들어간다. 같은 신청 업무라도 무엇을 끝으로 정의하느냐에 따라 에이전트가 수행해야 할 일이 크게 달라진다. 완료의 기준을 행동에서 결과로 옮겨야 한다. 발송했다는 기록, 접수됐다는 회신, 실제 입금 확인은 서로 다른 단계의 증거다. 접수 버튼 이후에도 남아 있는 업무 참가 신청 과정에서 피클은 브라우저로 접수 페이지에 들어가 이메일 로그인을 진행한다. 연결된 수신함의 일회용 인증 번호는 직접 찾아 입력하고, 문자로 전달되는 인증 번호는 사용자에게 받아 입력한다. 필요한 정보를 채우고 약관 동의를 거쳐 신청한 뒤에는 완료 화면을 보관한다. 이후 문제 공개와 참가 혜택을 확인할 일정도 등록한다. 이 흐름은 자율 실행에도 사용자와의 연결 지점이 있다는 사실을 보여준다. 모든 단계를 혼자 처리해야만 위임이 성립하는 것은 아니다. 사용자 입력이 필요한 구간을 구분하고, 입력을 받은 뒤 진행하던 작업을 이어 가는 능력이 중요하다. 완료 화면을 남기는 행동도 의미가 있다. 사용자가 같은 페이지를 다시 열지 않아도 신청 상태를 판단할 근거가 생기기 때문이다. 업무별로 달라지는 완료의 증거 업무 실행 단계 결과 확인 참가 신청 정보 입력과 신청 제출 완료 화면 보...

▲ 썸네일을 누르면 1분 쇼츠로 이동합니다. 회사 자금 관리에서 AI 에이전트에게 어디까지 맡길 수 있을까요? 스트라이프가 공개한 Treasury for agents의 기능과 승인 방식을 확인된 사실 중심으로 정리했습니다. 사실 정리 스트라이프는 2026년 10월 21일 Treasury for agents를 공개했습니다. 챗GPT·클로드 같은 AI 에이전트가 MCP 서버를 통해 연결해 잔액 확인, 송장 결제, 계좌 간 이체, 환전을 할 수 있습니다. 1인 스타트업 쿠브리오는 그록 에이전트를 통해 매일 아침 잔액·구독·실패 결제·환불을 보고받고 있습니다. 회사는 에이전트가 볼 계좌와 데이터를 선택하고, 읽기만 허용할지 실행까지 허용할지, 어느 시점에 사람 승인을 받을지 정할 수 있습니다. 실제 돈이 움직이는 작업에는 기본적으로 사람의 검토와 승인이 필요합니다. 공식 발표에서 에이전트 지출 한도 설정은 몇 주 안에, 카드 발급 기능은 곧 추가할 예정이라고 밝혔습니다. 두 기능은 추가 예정으로 안내됐습니다. 서비스는 공개 미리보기 단계로 안내됐습니다. [해석] 어디까지 맡길까 이 부분은 위 사실을 바탕으로 한 해석입니다. 기능의 범위만큼 중요한 것은 회사가 정하는 권한과 승인 기준이라고 봅니다. 조회 업무부터 맡겨 보고, 송금처럼 돈이 움직이는 업무는 사람이 확인하는 방식으로 시작할 수 있겠습니다. 또한 지출 한도 기능이 추가 예정이라는 점과 별개로, 조직 내부에서 허용할 업무 범위와 금액 기준을 먼저 정해 두자는 제안입니다. 현재 해당 한도 기능을 사용할 수 있다는 뜻은 아닙니다. 출처 Stripe 뉴스룸: Treasury for agents 발표 — 2026-10-21 Stripe 문서: Treasury for agents FinTech Global 관련 보도 — 2026-10-28 숏츠 보기 로 핵심 내용을 확인해 보세요. 이런 정리가 도움이 된다면 구독해 주세요. 여러분은 어떤 업...

"Grok @Bot got much faster." 일론 머스크(@elonmusk)가 이렇게 인용한 Grok Bot 업데이트가 2026년 10월 17일 오전 4시 55분(KST) @bot 공식 계정에 올라왔습니다. 리서처K 쇼츠로 정리한 주요 업데이트 5가지를, 회사 발표와 외신 보도를 구분해서 적어 봅니다. ▶ YouTube에서 쇼츠 보기 1. 속도: 컴퓨터 작업 평균 3배 (회사 수치) @bot 공식 게시물에 따르면 Grok Bot의 컴퓨터 작업은 평균 3배 빨리 끝나고, 그 밖의 답장은 절반도 안 되는 시간에 도착합니다. 다만 '3배'는 회사가 밝힌 자체 수치이고 측정 방법은 공개되지 않았습니다. 확인일 기준 Grok Bot 공식 changelog에는 10월 7일 "Bots work faster on their computer" 항목만 있고 배수는 적혀 있지 않습니다. 2. 채팅 카드 새 디자인 채팅 카드가 더 깔끔한 레이아웃으로 바뀌었습니다(@bot 공식). 새 글꼴과 테마도 함께 적용됐다는 내용은 외신 iPhone in Canada가 보도했습니다. 3. 음성 통화 개선 음성 통화가 더 빠르고 안정적이 됐고, 지난 대화를 더 잘 기억합니다(@bot 공식). 4. 이메일 플러스 별칭 이메일 주소에 플러스 별칭(이름+태그@…)을 붙일 수 있어서, 특정 주소로 온 메일에만 루틴이 실행되도록 나눌 수 있습니다(@bot 공식). 5. 알림은 지금 쓰는 기기로만 알림이 여러 기기로 흩어지지 않고, 지금 쓰고 있는 기기로만 갑니다(@bot 공식). 정리 이번 Grok Bot 업데이트의 핵심은 속도입니다. 다만 3배라는 숫자는 회사 발표이니, 내 작업에서 얼마나 빨라졌는지는 직접 써 보며 확인해 보시길 권합니다. 위 5가지는 @bot 스레드에서 리서처K가 고른 주요 항목이고, 스레드 전체에는 이 밖의 내용도 있습니다. AI 에이전트를 업무에 어떻게 쓸지 고민이시라면 찰리초...

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

AI 에이전트 트렌드 말 잘하는 AI에서, 일 잘하는 AI 팀으로 — Hermes Agent v0.18이 바꾼 것들 에이전트가 "완료했습니다"라고 말하는 것과, 실제로 완료된 것은 다르다. 찰리초이 스토리 AI 에이전트 · 실무 자동화 이 글의 순서 근본적으로 달라진 것 세 가지 기능별로 뜯어보기 Telegram, 24시간 AI 업무팀을 부르는 리모컨 Telegram 실전 활용 예시 찰리의 한마디 & 정리 지금까지 우리가 써온 AI 에이전트는 대부분 "말 잘하는 비서" 에 가까웠습니다. 요청을 하면 그럴듯한 답을 내놓지만, 그 결과가 실제로 완료된 것인지, 파일이 진짜 저장됐는지, 테스트를 통과했는지는 사용자가 일일이 확인해야 했습니다. 최근 업데이트된 Hermes Agent v0.18 은 이 지점을 정면으로 겨냥합니다. 한마디로 정리하면, AI 에이전트를 대화 도구에서 스스로 작업을 나누고, 검증하고, 학습하는 운영형 업무 파트너 로 끌어올린 업데이트입니다. 그리고 이번 업데이트는 Telegram 같은 메신저 채널에서 더 진가를 발휘하도록 설계됐습니다. 핵심 요약 여러 하위 에이전트가 조사·분석·작성을 동시에 병렬 처리 완료 조건을 기준으로 결과물을 실제로 검증 반복 업무는 /learn 으로 저장해 재사용 Telegram에서 Rich Markdown 보고서 로 결과를 받고, /status 등으로 운영 상태 확인 Gateway·Cron·보안까지 개선되어 24시간 운영 이 가능한 수준으로 안정화 근본적으로 달라진 것 세 가지 이번 업그레이드를 관통하는 키워드는 세 가지, 검증(Verification) , 병렬 작업(Parallelization) , 자기학습(Self-learning) 입니다. 예를 들어 "시장조사 자료를 정리해줘"라고 요청하면, 예전에는 하나의 에이전트가 처음부터 끝까지 순서대로 일을 처리했습니다. v0.18에서는 이 요청을 여러 하위 에이전트에게 나눌 수 있습니다. 01 나누는 능력...

AI PM + 실행팀 작은 AI 회사처럼 움직이는 헤르미 팀 헤르미는 단순히 질문에 답하는 챗봇이 아니라, 찰리님의 일을 실제로 함께 수행하는 역할 기반 AI 실행팀 입니다. 오더리가 정리하고, 플래니가 계획하고, 메이키가 만들고, 체키가 검증하고, 가디가 지키고, 브리피가 보고합니다. 헤르미는 VPS 에서 24시간 365일 일을 하는 AI 에이전트입니다.  헤르미 팀이 만들어진 배경 처음에는 “답변을 잘하는 AI”가 목표였지만, 실제 업무에서는 답변보다 더 중요한 것이 있었습니다. 요청을 정확히 이해하고, 일을 작게 나누고, 실제로 만들고, 결과를 확인하고, 위험한 부분을 점검한 뒤, 사람이 이해하기 쉽게 보고하는 과정입니다. 그래서 헤르미는 혼자서 모든 역할을 하는 대신, 내부에 여러 전문 팀원을 둔 것처럼 움직입니다. 각 팀원은 실제 사람이 아니라, 헤르미가 일을 처리할 때 사용하는 역할 기반 AI 팀원 입니다. 요구사항 정리 계획 수립 제작·실행 검증 리스크 점검 요약 보고 헤르미 팀원 소개 ☰ Orderly 오더리 질서를 잡고 요청을 정돈하는 팀원 찰리님의 요청을 목표, 요구사항, 빠뜨리면 안 되는 조건으로 정리합니다. 모든 작업의 출발점을 분명하게 만드는 역할입니다. △ Planny 플래니 계획을 세우는 작전 참모 정리된 목표를 실행 순서로 바꿉니다. 필요한 도구, 작업 단계, 우선순위를 판단하는 프로젝트 매니저 역할을 합니다. ✦ Makey 메이키 실제로 결과물을 만드는 제작자 글, 코드, 웹앱, 문서, 발표 자료, 자동화 스크립트처럼 눈에 보이는 산출물을 직접 만들어냅니다. ✓ Checky 체키 결과를 확인하는 품질검사 담당자 만든 결과물이 요청과 맞는지, 오류는 없는지, 실제로 작동하는지 점검합니다. “했다”보다 “확인했다”를 중요하게 봅니다. ♢ Guardy 가디 위험을 살피는 보호자 개인정보, 보안, 비용 발생, 배포, 삭제처럼 조심해야 할 부분을 확인합니다. AI 자동화의 안전벨트 역할입니다. ≡ Briefy 브리피 사람이 이해하기...

  AI 에이전트 · 바이브코딩 · Codex SDK Codex SDK 출시의 의미 바이브코딩은 어디로 진화하는가? 이제 Codex는 단순히 사람이 직접 사용하는 코딩 도구를 넘어, 앱과 AI 에이전트 안에 들어가는 “개발 자동화 엔진”으로 확장되고 있습니다. 1. Codex SDK 공식 사이트 OpenAI가 공개한 Codex SDK 공식 문서는 아래에서 확인할 수 있습니다. 공식 URL: https://developers.openai.com/codex/sdk 공식 문서에 따르면 Codex SDK는 Codex를 프로그래밍 방식으로 제어하기 위한 도구입니다. 쉽게 말하면, 사람이 직접 Codex 화면에 명령을 입력하는 방식에서 한 걸음 더 나아가 내가 만든 앱, 자동화 시스템, AI 에이전트가 Codex를 호출해서 개발 업무를 맡길 수 있게 해주는 SDK 입니다. 2. Codex SDK를 한마디로 설명하면? Codex SDK는 “앱 안에 넣을 수 있는 코딩 담당 AI 직원”에 가깝습니다. 기존에는 사용자가 Codex CLI, Codex 앱, IDE 확장 도구 등을 직접 열고 “이 코드 수정해줘”, “버그 고쳐줘”, “테스트 실행해줘”라고 지시했습니다. 그런데 Codex SDK가 등장하면 구조가 달라집니다. 이제는 사용자가 직접 Codex를 조작하지 않아도, 다른 웹앱이나 AI 에이전트가 Codex에게 개발 업무를 자동으로 맡길 수 있습니다. 기존 방식: 사람이 Codex에게 직접 지시한다. SDK 방식: 내가 만든 시스템이 Codex에게 개발 업무를 지시한다. 3. 기존 바이브코딩과 무엇이 다른가? 기존의 바이브코딩은 주로 사람이 AI에게 자연어로 개발을 지시하는 방식이었습니다. 예를 들면 이런 식입니다. “고객 상담 FAQ 검색 웹앱을 만들어줘.” “검색창 대신 카테고리 메뉴 방식으로 바꿔줘.” “모바일에서 보기 좋게 카드형 UI로 수정해줘.” 이 방식도 충분히 강력합니다. 하지만 Codex SDK가 더해지면 단순히 한 사람이 AI에게 개발을 시키는 ...