찰리초이 스토리 블로그

한 줄 요약: 웹 업무는 Ego Lite가 맡고, Excel 화면 조작은 Hermes Computer Use가 처리하며, Hermes Agent가 전체 순서와 검증 조건을 통제하는 자동화 사례를 구현했다. 웹과 엑셀을 함께 다뤄야 하는 업무 기업의 반복 업무는 한 시스템 안에서 끝나지 않는다. ERP에서 자료를 내려받고, Excel 양식에서 계산한 뒤, 다시 다른 ERP 화면에 입력하는 식이다. 이번 실증에서는 다음과 같은 가상의 업무 흐름을 만들었다. ERP-i에서 주문 CSV를 내려받는다. Excel 업무양식에 주문자료를 반영한다. 기존 수식으로 생산수량과 BOM을 계산한다. 오류가 없는지 확인한다. 검증을 통과한 결과만 ECOUNT 입력 화면에 붙여넣는다. 실제 등록 전 미리보기에서 최종 결과를 다시 검사한다. 단순히 브라우저만 자동화해서는 부족하고, Excel 매크로만으로도 전체 흐름을 끝낼 수 없다. 브라우저, 데스크톱 애플리케이션, 판단 로직을 하나의 에이전트가 연결해야 한다. 구성 1: Ego Lite 브라우저 자동화 Ego Lite는 사용자가 로그인한 웹 환경을 AI 에이전트와 함께 사용할 수 있는 브라우저다. 이번 예시에서는 모의 ERP-i와 모의 ECOUNT 화면을 조작했다. Ego Lite가 담당한 작업은 다음과 같다. ERP-i 주문 화면 열기 정상·예외 데이터 선택 CSV 다운로드 이벤트 확인 다운로드 파일 저장 ECOUNT 입력 화면 이동 Excel에서 복사한 TSV 데이터 붙여넣기 검증 버튼 실행 화면에 표시된 품목 수와 생산수량 확인 실제 등록 버튼 비활성화 여부 확인 버튼의 화면 좌표를 고정하지 않고 역할, 이름, DOM 요소를 기준으로 조작했다. 화면 배율이 달라져도 같은 버튼을 찾을 가능성이 높아진다. 구성 2: Hermes Computer Use로 Excel 수정 브라우저에서 받은 CSV는 실제 Microsoft Excel로 열었다. Hermes의 Computer Use는 화면을 보고 Excel 워...

한 줄 요약: 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 로 정...

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

  바이브코딩 실험기 Hermes AI 에이전트로 해본 바이브코딩 실시간 기상정보 API로 만든 사회적기업 운영 코치 아이디어를 말로 설명하면, AI 에이전트가 기획·개발·테스트·운영을 오가며 실제 작동하는 웹앱으로 완성해가는 과정을 기록했습니다. 🤖 Hermes AI Agent 🌦️ 기상청 · AirKorea API 🏢 사회적기업 POC 1 바이브코딩은 “코드를 대신 치는 것”이 아니다 요즘 AI를 활용한 개발 방식으로 바이브코딩(Vibe Coding) 이라는 말을 자주 듣습니다. 많은 분들이 “AI에게 말로 시키면 코드를 만들어주는 것”으로 이해하시는데, 틀린 말은 아니지만 실제로 끝까지 진행해보면 그보다 훨씬 넓은 개념이라는 것을 알게 됩니다. “아이디어를 말로 설명하면, AI 에이전트가 기획자·개발자·테스터·운영자의 역할을 오가며 실제 작동하는 결과물로 완성해가는 과정” 이번 프로젝트에서는 사회적기업을 위한 AI 날씨 운영 코치 라는 웹앱을 만들었습니다. 핵심 아이디어는 간단했습니다. “날씨 때문에 생길 수 있는 손해를 사회적기업이 미리 막을 수 있도록, 실시간 기상정보 API를 운영 의사결정 언어로 바꿔보자.” 2 아이디어: 날씨 데이터를 ‘운영 판단’으로 번역하기 일반적인 날씨 앱은 온도, 비, 바람, 미세먼지 같은 정보를 보여줍니다. 하지만 돌봄·복지·외근·배송·야외 행사·농업·시설관리 같은 일을 하는 사회적기업의 질문은 조금 다릅니다. 오늘 야외 활동을 계속해도 될까? 어르신 방문 일정을 조정해야 할까? 보호자에게 미리 연락해야 할까? 강풍이면 간판이나 천막을 철거해야 할까? 미세먼지가 나쁘면 실내 프로그램으로 바꿔야 할까? 몇 시까지 운영 결정을 내려야 할까? 즉, 단순한 날씨 정보보다 중요한 것은 행동 지침 입니다. 그래서 앱의 방향을 “업종과 지역만 고르면, AI가 날씨 데이터를 읽고 오늘의 운영 리스크와 권장 액션을 알려주는 도구”로 잡았습니다. 최종 헤드라인 날씨 때문에 생기는 손해, 오늘 미리 막으세요 사회적기업을 위한 ...

  초보자를 위한 AI 에이전트 서버 운영 가이드 리눅스를 몰라도 VPS에 Hermes를 설치하고 Codex로 운영하는 방법 이 글의 목표는 “리눅스 명령어를 잘 모르는 사람도” Hostinger VPS에 Hermes 에이전트를 설치하고, Codex를 이용해 SSH로 접속해 운영, 모니터링, 오류 해결까지 할 수 있게 만드는 것입니다. 목차 이 글은 누구를 위한 글인가 왜 Codex가 필요한가 준비물은 딱 세 가지 VPS에 SSH로 접속하는 방법 Codex에게 Hermes 설치를 맡기는 방법 Telegram 설정을 맡기는 방법 LLM 모델 설정 변경하기 상태 확인과 모니터링 오류가 났을 때 Codex로 해결하기 파일 공유 폴더 운영 보안과 운영 원칙 1. 이 글은 누구를 위한 글인가 VPS, SSH, Docker, Linux라는 단어가 낯선 분들도 많습니다. 하지만 AI 에이전트를 제대로 운영하려면 결국 “내 컴퓨터가 꺼져 있어도 계속 일하는 원격 작업자”가 필요합니다. 그 원격 작업자가 Hermes이고, 그 Hermes가 사는 집이 VPS입니다. 이 글은 서버 전문가를 위한 글이 아닙니다. 오히려 서버를 잘 모르는 분들이 Codex를 조력자로 삼아 원격 서버에 Hermes를 설치하고 운영하는 흐름을 이해하도록 돕는 글입니다. 핵심 메시지: 리눅스 명령어를 모두 외우지 않아도 됩니다. 중요한 것은 SSH 접속 정보와 Codex에게 정확히 요청하는 방법입니다. 2. 왜 Codex가 필요한가 VPS를 구매하면 보통 이런 정보를 받습니다. 서버 IP 주소 SSH 사용자 이름, 보통 root root 비밀번호 또는 SSH key 운영체제, 예를 들어 Ubuntu 24.04 문제는 그 다음입니다. 접속은 했는데 무엇을 입력해야 할지 모릅니다. Docker 설치, Hermes 설치, 환경변수 설정, Telegram bot token 등록, 로그 확인, 재시작 같은 작업이 모두 리눅스 명령어로 보이기 때문입니다. Codex가 필요한 이유는 여기에 있습니다. Code...