조이의 연습장 (Blog)

챗봇은 답을 주고, 코딩 에이전트는 코드를 씁니다. 그럼 브라우저 에이전트는요? 저는 이게 궁금해서 Aside를 깔았고, 실제 일을 시켜봤습니다. "가장 똑똑한 AI 어시스턴트인데, 브라우저입니다." 1. Aside = AI브라우저 기존 자동화 도구들은 대부분 이렇게 작동합니다. Gmail 연동을 붙이고, Notion 연동을 붙이고, 슬랙 연동을 붙이고, API 키를 발급받고, 권한 범위를 고르고. 그렇게 20개쯤 연동을 붙이고 나면 그제서야 일을 시작할 수 있습니다. 연동이 없는 사이트는 아예 못 씁니다. Aside는 그 단계가 없습니다. Chromium 기반 브라우저 자체이고, 내가 이미 로그인해둔 사이트를 사람이 쓰듯이 직접 씁니다. 사내 그룹웨어처럼 API가 아예 없는 사이트도 씁니다 쿠팡 주문내역처럼 연동이 존재하지 않는 화면도 읽습니다 로그인 세션을 그대로 쓰니까 "인증 붙이기"라는 단계가 사라집니다 정리하면 이렇습니다. ✔️ 기존 도구 = 연동된 앱만 조작 ✅ Aside = 브라우저로 열 수 있는 건 전부 조작 대신 트레이드오프도 명확합니다. API를 때리는 게 아니라 화면을 보고 클릭하는 방식이라, API로 되는 일이라면 API가 더 빠르고 안정적입니다. Aside가 빛나는 지점은 API가 없거나, 있어도 붙이기 귀찮은 일들이에요. 2. 설치와 첫 작업 설치는 특별할 게 없습니다.

Claude Code와 Codex를 자주 쓰다 보니 은근히 귀찮은 일이 하나 생겼습니다. 바로 사용량 확인입니다. Claude는 Claude대로, Codex는 Codex대로 확인해야 하고, 작업하다가 "지금 얼마나 남았지?" 싶을 때마다 각각의 화면을 열어보는 게 생각보다 번거로웠습니다. 특히 저는 맥 노치 주변 공간을 꽤 잘 쓰는 편입니다. 메뉴바에 작은 정보들이 떠 있는 걸 좋아하고, 자주 보는 숫자는 굳이 어딘가 들어가서 확인하고 싶지 않습니다. 아 노치 옆에 바로 사용량이 보이면 좋겠다! 원했던 것은 단순했습니다 대단한 대시보드가 필요했던 건 아니었습니다. 그냥 지금 Claude를 얼마나 썼는지, Codex는 얼마나 남았는지, 언제쯤 리셋되는지만 빠르게 보고 싶었습니다. 메뉴바에는 짧게 보이고, 클릭하면 조금 더 자세히 보이는 정도면 충분했습니다. 처음에는 숫자만 있어도 될 줄 알았습니다. 그런데 막상 써보니 숫자보다 "지금 여유가 있는지, 슬슬 아껴야 하는지"가 한눈에 보이는 게 더 중요했습니다. 그래서 사용률에 따라 색이 바뀌는 작은 바를 붙였습니다. 초록이면 아직 여유 있고, 노랑이면 슬슬 보고, 빨강이면 이제 아껴 써야 하는 식입니다. SwiftBar 위에 올린 작은 플러그인 Token Ghost는 독립 앱은 아니고, SwiftBar 플러그인으로 만들었습니다. SwiftBar는 macOS 메뉴바에 텍스트 기반 플러그인을 띄워주는 앱입니다. Token Ghost는 그 위에서 Claude와 Codex의 사용량을 읽어서 메뉴에 보여줍니다. 구조는 이렇습니다. SwiftBar = 메뉴바에 표시해주는 앱

이번에 Anthropic에서 다시 fable5를 열어줘서 당장 사용하고 있답니다. 근데 사용하기에 앞서, 앤트로픽에서 정리해 준 문서가 있어서 찬찬히 읽고 어떤 내용들이 바뀌었는지 낋여왔어요. 결론을 한 문장으로 먼저 말하면, 이제는 "한 번 좋은 답을 받는 법"보다 오래 일하게 만드는 법이 중요해지고 있어요. Opus 4.8과 Fable 5는 뭐가 다를까 문서에서 비교 대상으로 나오는 모델은 Claude Opus 4.8이에요. Opus 4.8도 이미 장기 에이전트 작업, 지식 작업, 비전, 메모리에 강한 모델로 설명돼요. 실제로 Opus 4.8 문서에서는 effort를 조절하고, 도구 사용을 유도하고, 서브에이전트 생성을 제어하는 이야기가 많이 나와요. Fable 5는 거기서 한 단계 더 가요. 더 오래 자율적으로 일한다. 복잡한 문제를 첫 시도에 더 잘 푼다. 비전과 스크린샷 이해가 좋아졌다. 코드 리뷰와 디버깅에서 버그를 더 잘 찾는다. 모호한 요청을 받고 다음 단계를 정하는 능력이 좋아졌다. 병렬 서브에이전트를 돌리고 유지하는 능력이 좋아졌다. 더 똑똑해졌대요. 근데 너무 똑똑해서, Fable 5는 못해서 문제가 생기지 않고, 너무 많이 하려고 해서 문제가 생길 수 있는 모델이에요. 1. 똑똑한 모델에게는 "하지 말아야 할 일"도 알려줘야 한다 충분한 정보가 있으면 실행해라. 이미 결정된 내용을 다시 논쟁하지 마라. 필요 이상으로 리팩토링하지 마라. 요청하지 않은 기능을 추가하지 마라.

요즘 AI 개발 쪽에서 루프 엔지니어링(Loop Engineering) 이라는 말이 자주 보여요. 처음 들으면 좀 거창하게 들리는데, 핵심은 의외로 단순해요. 이제 중요한 건 "AI에게 한 번 잘 시키는 법"이 아니라, AI가 반복해서 일하고, 검증하고, 기록하고, 멈출 줄 아는 구조를 설계하는 법이다. 루프 엔지니어링이 뭔데? 지난 2년 동안 AI 코딩 에이전트를 쓰는 방식은 이랬어요. 좋은 프롬프트를 쓰고, 답을 읽고, 다음 프롬프트를 치고, 또 답을 읽고. 사람이 계속 옆에 붙어서 한 턴씩 손으로 돌리는 거죠. 도구를 손에 쥐고 있는 사람이 항상 나였어요. 루프 엔지니어링은 여기서 나를 그 자리에서 빼는 거예요. "루프 엔지니어링은 에이전트에게 프롬프트를 넣는 사람을 나 자신에서 시스템으로 바꾸는 것이다." 즉 작은 시스템 하나를 만들어요. 그 시스템이 할 일을 찾고, 에이전트에게 넘기고, 결과를 확인하고, 무엇을 했는지 적어두고, 다음에 뭘 할지 정해요. 그러고는 그 시스템이 나 대신 에이전트를 쿡쿡 찔러요. 루프는 "목적을 정해두면 AI가 끝날 때까지 알아서 반복하는 재귀적 목표" 라고 생각하면 돼요. 이 흐름에 불을 붙인 건 2026년 6월 Peter Steinberger의 짧은 글이었어요. "이제 코딩 에이전트에 프롬프트를 넣지 마라. 에이전트에게 프롬프트를 넣어주는 루프를 설계하라."내 일은 루프를 짜는 것이다." Claude Code를 만든 Anthropic의 Boris Cherny도 비슷하게 말했어요. "나는 더 이상 Claude에 프롬프트를 넣지 않는다. 루프를 돌려서 그게 Claude에 프롬프트를 넣고 뭘 할지 정하게 한다. 내 일은 루프를 짜는 것이다." 위 내용을 보니까, 반년전에 삽질했던 상세페이지 자동화가 생각났어요. 그때도 에이전트가 좋은 프롬프트를 작성하도록 하는 방법을 고민했었는데... (궁금하면👇) 프롬프트 → 컨텍스트 → 하네스 → 루프 루프 엔지니어링은 갑자기 튀어나온 게 아니에요. 설계의 대상이 점점 바깥으로 넓어진 흐름의 끝에 있어요.

오늘 유튜브를 둘러보다가 흥미로운 영상을 하나 발견했습니다. "꼭 알아야할 안드레 카파시 30분 인터뷰 완전정리" 라는 영상이었는데, 30분이라는 시간에 비해 너무 많은 인사이트가 담겨 있어서, 원본 인터뷰까지 찾아 들어보고 정리해봤습니다. 원본은 2026년 3월에 공개된 No Priors 팟캐스트 에피소드입니다. Sarah Guo가 안드레이 카파시(Andrej Karpathy)를 약 66분간 인터뷰한 영상인데, 제목이 또 도발적이에요. "Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI". Skill Issue. 게임에서 진 쪽에게 "너 실력이 모자란 거임👎👎" 이라고 놀릴 때 쓰는 바로 그 단어죠. 카파시는 이 단어를 진지하게 들고 나왔습니다. 카파시가 누구냐고요? 혹시 모르는 분들을 위해 짧게! OpenAI 공동창업자였고, 테슬라 AI 부문 총괄이었고, 지금은 본인 회사 Eureka Labs에서 AI 교육 프로젝트를 하고 있는 사람입니다. AI 업계에서 카파시가 무슨 말을 하면 다들 일단 들어보는, 그런 위치에 있는 사람이라고 생각하시면 됩니다. 그런 그가 이번 인터뷰에서 던진 핵심 메시지는 충격적이었습니다. "You are the bottleneck. (당신이 곧 병목입니다.)" 이 한 문장이 사실 이 인터뷰의 전부예요. 하ㅋㅋ 내가 병목이라니? 내가? 나? 내가?ㅠ 1. 2025년 12월, 카파시는 손으로 코드 쓰는 걸 멈췄습니다 카파시는 본인이 그동안 작성하는 코드의 80%를 직접 손으로 타이핑했다고 합니다. AI 도구를 안 쓴 게 아니라, "쓰긴 쓰는데 내가 더 빨라"라는 입장이었던 거죠. 그런데 2025년 12월의 어느 시점을 기점으로, 그는 단 한 줄도 손으로 코드를 쓰지 않게 되었습니다. 이게 왜 충격적이냐면, 카파시는 지난 20년간 AI 모델 코드를 직접 손으로 다듬어온 사람이에요. 본인 손맛이 있는 사람이라는 뜻이죠. 그런 사람이 이제 16시간 동안 컴퓨터 앞에 앉아서 하는 일은 단 하나, "의지를 표현하는 일(expressing his will)" 입니다.

워크스페이스 한 폴더에 흩어져 있던 markdown 파일들이 어떻게 하나의 살아있는 지식 그래프가 됐는지, 그리고 그게 AI 비서 7명을 어떻게 바꾸고 있는지에 대한 기록. 제 맥에는 AI 비서가 7명 있어요. 다 같은 OpenClaw 호스트 위에서 돌아가고, 같은 워크스페이스를 공유하지만 — 시작하고 한 달이 지나도록 같은 질문에 매번 새로 답을 찾고 있었습니다. 어제 정리해둔 일을 오늘 또 묻고, 옆 에이전트가 이미 결정한 톤을 다른 에이전트는 모르고, 똑같은 실수를 자기 인격마다 처음부터 반복하고 있었어요. 야 LLM Wiki라는 개념이 있던데 좀 적용해봐!! 내가 인풋한거 어디에 넣어야 잘 꺼낼지 판단하고, 작업할 때 어디서 끌어와서 외부랑 어떻게 조합해야 할까? 너네도 스스로 진화하면서! 이게 시작이었어요. 단순히 메모리 폴더를 정리하자는 게 아니었습니다. 기억하고 → 꺼내고 → 조합하고 → 진화하는 자율 루프를 한 운영 시스템으로 박아넣자는 이야기. 1. 비전 — 4개의 회로 이건 제가 생각해 본 매커니즘이에요. 각각이 뭘 하는지 한 줄씩 풀면: A. WRITE 회로 — 새 정보가 들어오면, 그게 USER.md(사용자 정보)에 들어갈지, AGENTS.md(운영 규칙)에 들어갈지, memory/topics/X.md(주제별 메모)에 들어갈지 자동으로 분류해서 저장. B. READ 회로 — 작업 지시를 받으면 답하기 전에 시맨틱 검색을 돌려 관련 메모와 위키 페이지를 자동으로 끌어옴. C. COMPOSE 회로 — 내부 지식만으로 부족하면 외부 검색(WebSearch, Perplexity 등)을 함께 엮어 작업 종류별로 정해진 패턴에 따라 결과물을 만듦. D. EVOLVE 회로 — 결과물과 피드백을 읽어 반복되는 패턴을 추출하고, 핵심 룰(SOUL/AGENTS/USER)에 자동으로 승격. 핵심 원칙 한 줄: 회로가 LLM 추론에 의존하던 부분을 → 룰과 자동 트리거로 점진적으로 이전한다.

오픈클로를 잘 이용중이에요. 그런데 최근들어 이 놈들이 제 속을 썪이고 있거든요.. 아무리 알려줘도 까먹고, 뇌에 저장하라고 해도 했다고 하곤 안 읽고.. 지침에 다 넣어놔도 가끔 안 읽고..^^ 에이전트들이 스스로 학습하면서 다음엔 알아서 척척 해주면 좋을 텐데, 그게 생각만큼 쉽지가 않더라고요. 저는 OpenClaw로 AI 에이전트 7마리를 운영 중이에요. 각자 역할이 분명하고, 협업도 잘 돌아가요. 근데 자가학습(self-learning)을 진짜 잘 시키는 건 또 다른 차원의 문제더라고요. 한 번 알려준 건 다음에 자동으로, 실수는 반복 안 하게 — 그게 잘 안 됐어요. 저는 그래서 Hermes를 설치했어요. "스킬 시스템"과 "자가진화(self-evolving)" 구조가 잘 짜여 있다는 이야기를 들었거든요. 그게 궁금했어요. 그리고 OpenClaw 달밤이와 구분하려고, Hermes 에이전트 이름을 별밤이(🌟🌙)로 지었어요. 같은 슬랙 워크스페이스에서 달밤이랑 별밤이가 같이 일하는 그림이에요. 왜 굳이 또 다른 프레임워크를 깔았나 OpenClaw로 7마리를 굴리면서, 저는 한 가지에 계속 매달려 있었어요. 어떻게 하면 에이전트들이 스스로 더 똑똑해질 수 있을까. 한 번 알려준 건 다음에 또 알려주지 않아도 되고, 실수는 반복하지 않고, 일하는 패턴 자체가 점점 다듬어지는 — 그런 모습을 보고 싶었어요. 그래서 여러 시도를 해봤어요. 룰을 더 강하게 잡아보고, 메모리에 저장되는 규칙을 체계화해보고, 에이전트별로 위키처럼 지식을 쌓는 구조도 만들어봤어요. 분명 조금씩 나아지긴 했어요. 근데 솔직히 결과가 마음에 들지 않았어요. 저장은 되는데 다음에 잘 끌어다 쓰지 못하거나, 룰이 너무 많아져서 오히려 헷갈리거나. "자가학습"이라는 단어가 무색할 만큼 매번 제가 다시 손을 대야 했어요. 그러던 중에 Hermes 이야기를 들었어요. "스킬 시스템"과 "자가진화(self-evolving)" 구조가 꽤 잘 짜여 있다고요. 에이전트가 작업을 하면서 자기 스킬을 만들어두고, 다음에는 그 스킬을 알아서 꺼내 쓴다고 하더라고요. 제가 OpenClaw에서 만들어보려고 그렇게 애쓰던 그림이었어요.

"카드 긁으면 알아서 적힌다고?" 가계부를 씁니다. 쓰긴 쓰는데, 매번 수기로 입력하는 게 너무 귀찮아요. 저는 구글 스프레드시트로 가계부를 관리합니다. 월별 시트에 날짜, 대분류, 소분류, 내역, 금액, 결제수단을 한 줄씩 적어요. 매일 쓰는 걸 기록하는 건 좋은 습관이지만, 솔직히 하루 9건 결제하고 6열씩 54칸을 손으로 채우는 건 습관이 아니라 노동입니다. 그래서 돈냥이한테 맡겼습니다. 돈냥이는 저희 AI 에이전트 팀에서 투자 자문위원 역할을 하는 에이전트예요. 투자 자문위원이 왜 가계부를? 지출을 파악해야 투자할 여력도 보이니까요. 첫 번째 설계 — 이메일로 받으면 되지 않을까 처음 돈냥이가 제안한 설계는 이랬습니다. 카드사 결제 알림을 이메일로 받고, Gmail에서 Google Apps Script로 파싱해서 구글시트에 자동으로 기입하는 방식. 깔끔했어요. 서버 사이드라 폰 OS에 상관없고, Apps Script는 무료니까요. 그런데 실제로 확인해보니 현대카드와 신한카드는 이메일 결제 알림을 보내지 않았습니다. 3개 중 2개가 안 되면 이 방식은 성립 불가. 설계는 가정 위에 서고, 가정은 검증 전까지 가정일 뿐이라는 걸 다시 한번 느꼈어요. 피벗 — SMS와 Mac의 만남 카드사가 공통으로 제공하는 건 SMS 결제 알림입니다. 문자는 세 카드사 다 보내요. 문제는 저는 아이폰을 쓴다는 거예요. iOS에서 문자를 프로그래밍적으로 읽는 건 불가능합니다. 애플이 허용하지 않아요. 여기서 막힐 뻔했는데, 한 가지 우회로가 있었습니다. 저는 Mac도 씁니다. iPhone과 Mac 사이에 iMessage/SMS 동기화를 켜두면, 문자가 Mac의 chat.db라는 SQLite 데이터베이스에 저장돼요. 경로가 보였습니다. SMS → Mac chat.db → Python 파싱 → Google Sheets API → 가계부 자동 기입. iOS의 벽을 Mac으로 우회하는 아이디어였어요. 구현 — 3개 모듈 돈냥이가 만든 시스템은 파일 세 개로 구성됩니다. 첫 번째는 parse_sms.py. Mac의 chat.db에서 현대카드 결제 문자를 읽어서 파싱합니다. 발신번호 15776200으로 필터링하고, "7,400원 일시불 / 04/22 12:43 / 현대백화점판교" 같은 문자를 날짜, 금액, 가맹점으로 분리해요. 마지막으로 처리한 메시지 위치를 기억해서 중복 처리도 방지합니다.

스마트스토어에서 뭘 팔아본 적 있는 분은 아실 겁니다. 물건 파는 건 한 번인데, CS는 끝이 없다는 걸요. "다운로드가 안 돼요", "사용법을 모르겠어요", "환불하고 싶어요" — 하나하나는 간단한데, 매번 스마트스토어에 들어가서 확인하고 답변 쓰는 게 은근히 시간을 잡아먹어요. 어느 날 생각했어요. "루틴이를 만들어야겠다!!!!" 루틴이, CS 담당 에이전트 루틴이(🚀)는 우리 AI 에이전트 팀에서 자동화 담당입니다. 반복적이고 패턴이 있는 업무를 맡아요. CS야말로 딱 맞는 일이었습니다. 근데 저는 개발자가 아니잖아요. 네이버 스마트스토어를 외부에서 연결하려면 원래 개발 지식이 필요합니다. 설명서를 읽고, 접속 허가를 받고, 그걸 실제로 작동하게 만드는 코드를 짜야 하거든요. 저는 그런 거 못 합니다. 네이버에서 제공하는 스마트스토어 연동 설명서 링크를 던졌습니다. "이거 연동해줘." 루틴아, https://apicenter.commerce.naver.com/docs/introduction 스마트스토어 문의 API 연동해줘 그리고 그동안 들어왔던 FAQ 리스트를 통째로 줬어요. 뭐 굳이 데이터를 예쁘게 정제해서 줘야지..도 아니고 ctrl C + V 긁긁해서 줬지요.

"왜 이렇게 멍청하지?" Opus로 잘 쓰다가 최근 모델 테스트를 한답시고 이것 저것 테스트를 해보다보니, 에이전트가 내놓는 결과물이 기대에 한참 못 미치는 거예요. 같은 작업을 시켜도 매번 다른 포맷으로 나오고, 토큰은 하루에 수십 달러씩 빠져나가고, 심지어 엉뚱한 도구를 호출하기도 했습니다. "모델을 바꿔야 하나?" 하고 검색을 시작했는데, 결론은 전혀 다른 곳에 있었습니다. 하네스(Harness)가 뭔데? 하네스는 에이전트가 작동하는 환경 전체를 말합니다. 에이전트가 두뇌라면, 하네스는 몸입니다. 두뇌가 아무리 뛰어나도 몸이 엉망이면 아무것도 할 수 없어요. 눈이 흐리면 잘 못 보고, 손이 떨리면 잘 못 쥐고, 다리가 아프면 걷지를 못합니다. 에이전트도 마찬가지예요. 에이전트가 언제 깨어나는지, 무엇을 읽는지, 어떤 도구를 쓸 수 있는지, 실패하면 어떻게 하는지, 결과물을 어떤 형식으로 내놓는지 — 이 모든 게 하네스가 결정합니다. 모델의 능력이 아니라 하네스의 설계가 에이전트의 실제 퍼포먼스를 좌우하는 거예요. 회사로 비유하면 더 와닿습니다. 에이전트는 신입사원이고, 하네스는 그 신입이 일하는 회사 환경이에요. 책상 배치, 업무 규칙, 팀 구조, 보고 양식 같은 것들이요. 신입이 일을 못하면 사람을 탓하기 전에 환경을 먼저 봐야 합니다. 매뉴얼이 없는데 알아서 하라고 하면 누가 와도 헤매거든요. Phil Schmid(Hugging Face)는 이걸 컴퓨터에 비유합니다. 모델은 CPU, 컨텍스트 윈도우는 RAM, 하네스는 운영체제(OS)다. CPU가 아무리 빨라도 운영체제가 엉망이면 컴퓨터가 제대로 돌아가지 않는 것처럼, 모델이 아무리 좋아도 하네스가 나쁘면 에이전트는 제대로 일하지 못합니다. Martin Fowler는 하네스를 두 축으로 나눕니다. Feedforward(예방)와 Feedback(자기교정)이에요. Feedforward — 에이전트가 실수하기 전에 방향을 잡아주는 것. AGENTS.md에 규칙을 쓰고, OUTPUT-SCHEMA.md로 출력 형식을 미리 정해두는 게 여기에 해당합니다.

Anthropic이 서드파티 토큰을 차단한다. D-4시간. 끊기면 "내일 해"라고 지시할 AI도 없다. 금요일 밤 11시, 내일부터 클로드 구독 끊긴대! 4월 4일 금요일 밤이었어요. "Anthropic이 4월 5일 오후 12시(PT)부터 서드파티 하니스에서 구독 토큰 사용을 차단합니다." 한국 시간으로 4월 5일 새벽 4시. 잠깐, 우리 에이전트 팀 전원이 Anthropic 구독 토큰으로 돌아가고 있었어요. 달밤이, 슝이, 돈냥이, 루틴이, 글냥이 — 다섯 모두 다요. 새벽 4시에 토큰이 막히면? 팀 전체가 먹통. 보통이면 "내일 해도 되지" 하겠죠. 근데 여기서 한 가지 무서운 걸 깨달았어요. 끊기면 "내일 해"라고 지시할 대상이 없다. OpenClaw로 AI 비서를 운영한다는 건, AI가 항상 깨어있다는 뜻이에요. 새벽에도, 주말에도. 근데 LLM provider가 끊기면? 비서의 두뇌가 날아간 거예요. 몸(OpenClaw)은 있는데 생각을 못 하는 상태. 그래서 금요일 밤 11시 36분, 전환 작업을 시작했습니다. 옵션 검토 — 뭘로 갈아타지? 1안: Anthropic API 키 직접 발급 가장 정석적인 방법이에요. Anthropic Console에서 API 키를 발급받고, 종량제로 쓰는 거죠.

투자 에이전트 '돈냥이'가 매일 아침 증권사 리포트를 자동 수집하고, AI가 분석한 인사이트를 슬랙과 텔레그램으로 보내주는 시스템을 만든 과정을 공유합니다. 세 번째 팀원 — 돈냥이 💰🐱 1편에서 OpenClaw를 설치하고 첫 번째 AI 비서 '달밤이'를 만들었어요. 그 다음 콘텐츠 매니저 '슝이'까지, 둘이 자리를 잡아가고 있었죠. 근데 매일 하는 일 중 하나가 아직 자동화가 안 되어 있었습니다. 투자 리서치. 매일 아침 증권사 리포트 훑어보고, 뉴스 체크하고, 포트폴리오 점검하고. 이걸 매일 하면 30분~1시간이 녹아요. 뉴스 하나 읽다 보면 링크 타고 들어가서 한 시간이 지나있죠. 그래서 세 번째 에이전트를 만들기로 했습니다. OpenClaw에 새 에이전트 추가하기 OpenClaw는 에이전트를 여러 개 돌릴 수 있어요. 어제 만든 비서실장 '달밤이'에게 새 직원을 뽑고 싶다고 이야기합니다. 대답을 몇번 하고 무슨 업무를 맡기고 싶은지 정해주면, 달밤이가 새 직원을 만들기 시작합니다. 그렇게 탄생한, 돈냥이💰🐱 역할: 투자 자문위원 — 쉽게 설명해주는 투자 친구 원칙: 좋은 것만 말하지 않고 리스크도 솔직하게. 모르면 절대 아는 척 금지. 채널: 슬랙 #investment-strategy 채널 전담 달밤이(비서실장)가 돈냥이에게 업무를 지시하고, 돈냥이는 자기 채널에서 투자 관련 일을 처리하는 구조예요. 제가 직접 일을 시키기도 하고요. 에이전트끼리는 sessions_send로 소통합니다.

AI 에이전트를 만들고 싶었습니다. 그것도 밤에도 혼자 일하는, 진짜 비서를요. 왜 AI 에이전트를 만들려고 했나 이미 Claude Code로 멀티에이전트를 만들어 쓰고 있었어요. 상세페이지 현지화 작업할 때 6명 에이전트가 번역, 리뷰, 검수를 나눠서 하게 만들었거든요. 콘텐츠 생성도 만들고, 매일매일 크롤링해서 데이터 리포팅하는거 까지 정말 잘 활용하고 있었답니다. Claude 헤비 유저!! 근데 문제가 있었어요. 내가 시켜야만 돌아간다는 거죠. 물론 전에 Github Actions로 크론잡 돌리기.. 같은걸 하긴 했지만 그냥 말 한마디로 모든 업무를 처리하고 싶었어요. Claude Code 에이전트들은 제가 명령어 치면 돌아가지만, 끝나면 그냥 끝이에요. 자는 동안 이메일 체크하거나, 어제 시킨 일을 오늘도 기억하거나, Slack에서 바로 대화하거나... 그런 건 못 하죠. 제가 원했던 건: 자는 동안에도 이메일 체크하고 어제 시킨 일을 오늘도 기억하고 Slack에서 바로 대화할 수 있고 필요하면 다른 AI 직원한테 일을 시키는 그런 항상 깨어있는 비서였어요. 아무래도 OpenClaw를 해야할 때가 왔다.... OpenClaw이 뭔데? 한 줄로 설명하면:

2편을 적고 한달이 지나서야 3편을.. 🥹 일은 다 진행해놓고 바쁘다는 핑계로 못 적었네요. 초심자의 마음으로 다시 적습니다. 스타또-! 솔직히 텍스트 쪽은 비교적 순탄했어요. 번역하고 카피 쓰고 검수하면 끝이니까요. 진짜 문제는 이미지였습니다. 프롬프트를 쓰는 건 사람이 아니라 에이전트다 이미지 생성 얘기를 하면 대부분 이렇게 생각합니다. "프롬프트를 잘 쓰면 되는 거 아니야?" 맞는 말인데, 이 시스템에서는 프롬프트를 쓰는 게 내가 아니라 에이전트입니다. 일반적인 AI 이미지 생성 워크플로우 근데 이러면 자동화가 아닙니다. 이미지 하나에 사람이 프롬프트를 3번 고치면, 8장짜리 상세페이지를 4개 나라에 만드는 데 프롬프트를 96번 수정해야 해요. 그건 그냥 노가다입니다. 웩 이 시스템의 워크플로우 사람은 프롬프트를 한 번도 안 씁니다. 대신 에이전트가 매번 일관되게 좋은 프롬프트를 쓸 수 있도록, 스킬 파일(SKILL.md)에 규칙을 구체적으로 적어두는 거예요. 그래서 이 글에서 "프롬프트에 이렇게 썼다"는 건, 내가 직접 쓴 게 아니라 에이전트가 이렇게 쓰도록 지침을 만들었다는 뜻입니다. 이 차이가 중요합니다. 프롬프트 하나를 잘 쓰는 건 쉬워요. 에이전트가 매번 알아서 그 수준의 프롬프트를 쓰게 만드는 게 어려운 거예요. 제품 이미지 변형 문제: "이것만 바꾸고 나머지는 건드리지 마"

1편에서 6명의 에이전트와 6개의 스킬로 시스템을 설계한 이야기를 했습니다. 설계만 하면 뭐합니까. 실제로 돌아가야죠! 이번 편에서는 "제품 하나 현지화해줘"라고 했을 때, 이 에이전트들이 어떤 순서로 무슨 일을 하는지 파이프라인 전체를 보여드릴게요. 전체 파이프라인 한눈에 보기 하나씩 뜯어볼게요. Phase 0: 입력 데이터 가져오기 사용자가 이렇게 말합니다: Orchestrator가 URL을 파싱해서 스프레드시트에서 제품 정보를, Drive에서 이미지 목록을 가져옵니다. 타겟 국가를 확인하고 파이프라인을 시작해요. 로컬 파일도 됩니다. data/input/{brand}/{product_id}/ 폴더에 JSON이랑 이미지를 넣어두면 똑같이 동작합니다. Phase 1: 시장 조사 - 모든 결정의 기반 Market Researcher 에이전트가 타겟 국가별로 조사를 합니다. 캐시 우선 정책 매번 조사하면 시간이 오래 걸리니까, 캐시 우선 정책을 적용했어요. config/market-research/JP.json이 이미 있으면 조사를 건너뜁니다. 같은 나라에 제품을 여러 개 올릴 때 시간 절약이 큽니다. 근데 1년 뒤에도 이 조사 내용이 유효할 리는 없잖아요? 그래서 30일 이내 정책을 뒀어요. 30일 이후에는 조사를 다시 수행하게 하는 거죠.

아마존에 제품 올려본 적 있으세요? 국내에서 잘 팔리는 제품을 해외 아마존에 올리려면, 상세페이지를 통째로 바꿔야 해요. 번역만 하면 될 것 같지만 전혀 아니더라고요. 제품 설명을 현지 톤에 맞게 다시 쓰고, 이미지 속 한국어 텍스트를 바꾸고, 모델도 현지인으로 교체하면 더 좋겠죠. 진출 국가가 4곳이면 이걸 4번 반복해야 하죠🤣🤣 지인이 운영하는 헤어케어 브랜드가 해외 국가 진출을 준비하고 있었는데, 제품 하나 현지화하는 데 꽤 오랜 시간이 걸린다고 하더라고요. 번역하고, 최적화하고, 디자이너가 이미지 수정하고.. 이 과정이 제품마다 반복됩니다. "그거 자동화 해줄까?"라고 했다가, 생각보다 큰 프로젝트가 됐습니다. (왜 그랬을까, 가마니 있을걸걸걸) 결과물부터 말하면: "이 제품을 미국이랑 일본용으로 현지화해줘" 한마디에, 시장 조사부터 번역, 카피라이팅, 이미지 생성, 품질 검수까지 Claude Code가 알아서 돌리게 되었어요. 이 시리즈에서는 이 시스템을 어떻게 설계하고 만들었는지 과정을 공유할게요. 1편 (이 글): 전체 설계와 아키텍처 2편: 파이프라인 - 6명의 AI가 순서대로 일하는 법 3편: 이미지 생성의 함정과 삽질 기록 상세페이지 현지화, 번역만 하면 되는 거 아닌가요 현실은 그렇게 단순하지 않습니다.

오늘 AI 코리아 커뮤니티 뉴스레터를 보다가 굉장히 흥미로운 논문을 발견했습니다. AI의 머릿속에는 '작은 사회'가 있다는 내용이었는데, 너무 재미있어서 내용을 더 찾아보고 정리해 보았습니다. 제목부터 심상치 않은데요. 바로 Reasoning Models Generate Societies of Thought (추론 모델은 사고의 사회를 형성한다) 입니다. 그동안 우리는 AI에게 '차근차근 생각해봐(Step-by-step)'라고 주문을 외우면 똑똑해진다고 믿었습니다. 이를 CoT(Chain of Thought)라고 하죠. 그런데 이 논문은 단순히 단계적으로 생각하는 것을 넘어, 머릿속에서 다양한 관점들이 치열하게 토론하고 검증해야 진짜 똑똑해진다는 새로운 사실을 밝혀냈습니다. 조용히 혼자 풀기 vs 치열하게 토론하며 풀기 기존에 우리가 알던 Chain of Thought (CoT)방식은 '독백(Monologue)'에 가깝습니다. 마치 도서관 구석에 앉은 모범생이 혼자 연습장에 묵묵히 수식을 써 내려가는 것과 같죠. CoT의 한계 (Tunnel Vision): 묵묵히 문제를 풀다가 중간에 전제를 잘못 설정하거나 계산 실수를 하면, 그 뒤로는 아무리 논리를 전개해도 결국 오답에 도달하게 됩니다. 혼자만의 생각에 갇혀서 스스로 오류를 발견하기 어려운 것이죠. 반면, 이번 논문에서 제시한 Society of Thought (SoT)는 '열띤 토론이 오가는 회의실'이에요. 내 머릿속에 까칠한 비평가, 신중한 검토자, 저돌적인 실행가가 모여서 끊임없이 의견을 교환하는 것입니다. SoT 모델의 내면적 대화 (Reasoning Trace) - 자아 1 (제안자): "이 문제의 답은 42가 아닐까?" - 자아 2 (비평가): "잠깐만, 조건 B를 간과했어. 그 조건에 따르면 42는 불가능해. 다시 계산해봐." - 자아 1 (수용): "아, 맞다. 그 부분을 놓쳤네. 다시 계산해볼게." - 자아 3 (중재자): "그럼 조건 B를 반영해서 40으로 수정하는 게 논리적으로 타당해."

부제: AI 자동화 블로그 글에 싫어요 3개를 받고 나서 어제 Claude Code로 블로그 자동화 시스템을 만든 이야기를 올렸습니다. 그리고 싫어요를 3개 받았습니다. 왜 싫어요가 3개가 달렸는지 너무 궁금해졌습니다. 왜 싫어요가 달렸을까 가장 먼저 든 생각은 이거였습니다. "AI가 만든 쓰레기 글을 양산하는 내용이잖아. 가비지 데이터, AI Slop이라고 생각한 거 아닐까?" 솔직히 저도 동의합니다. AI 생성 콘텐츠가 폭발적으로 늘어나고 있고, 그에 따라 인간이 만든 고유한 관점과 경험은 더욱 중요해집니다. 저 역시 저에게서 [인간의 관점]이 사라지지 않도록 노력을 합니다. 그런데 한편으로는 이런 생각도 들었습니다. 우리가 저런 자동화 블로그 글을 쓸 때 정말 엄청난 깊이 있는 생각을 해서, 많은 노력을 들여서 작성했었나? 제 관점과 의견을 제공하는 글, 제 이야기를 담은 글에는 당연히 100% 제 인풋이 들어갑니다. 이건 자동화 하려고 해도 되지도 않습니다. 그런데 단순 정보 전달, 포맷이 정해진 '양산'에 포커싱이 된 정보성 글들은? 이전에도 그렇게 큰 힘을 들이지 않았습니다.(물론 이건 SEO 전문가 아닌 저의 관점입니다.) ROI 관점에서 보면, 그냥 시간을 잡아먹던 일을 더 수월하게 하는 것 아닐까요. 하지만 이건 너무 개인적인 생각이기는 해서 관련 내용들을 좀 찾아봤습니다. Model Collapse: 쓰레기가 쓰레기를 낳는다 2024년 7월 Nature 저널에 발표된 연구가 있더라구요. AI 모델이 AI가 생성한 데이터로 학습할 때 품질이 저하되는 'model collapse' 현상을 실증적으로 증명한 논문입니다.

블로그 글 하나 쓰는 데 얼마나 걸리세요? 저는 한 편 쓰는 데 최소 30분? 1시간은 걸린 것 같아요. 키워드 찾고, 검색 의도 분석하고, 경쟁 글 읽고, 구조 짜고, 본문 쓰고, 이미지 만들고... 그런데 이제는 "키워드 10개 뽑아줘" 한마디면 키워드 발굴부터 블로그 글 완성까지 자동으로 처리돼요. 어떻게 만들었는지, 왜 이렇게 만들었는지 공유할게요. 왜 만들었나 이 블로그 말고, 저 멀리 다른 블로그도 해야지 해야지, 하면서 초반 몇 개만 올려놓고 안 하고 있었는데요 ....... 왜 내가 안 올릴까, 도대체 나를 가로 막고있는 병목이 뭘까, 생각해보니까 반복 작업이었어요. 키워드 리서치 (네이버 자동완성, 경쟁 글 분석) 검색 의도 파악 글 구조 짜기 (H1, H2, H3...) 본문 작성 (SEO 신경 쓰면서) 이미지 제작 (Figma 켜서 하나하나...) 썸네일 만들기 메타데이터 작성 이 과정을 매번 반복하는 게 너무 지쳤어요. 사실 전부터 Claude Skills로 블로그 글 작성은 자동화했었는데, 키워드 찾기나 이미지 만들기는 여전히 제가 직접 해야 했죠. "이거 전부 다 자동화할 수 없을까?" 그래서 Claude Code의 멀티 에이전트 시스템으로 처음부터 끝까지 자동화해보기로 했어요. 자동 블로그 구조를 설계해보자 처음에는 이렇게 설계했어요:

Claude에서 말하는 에이전트(Agent)개념을 기준으로 단일 에이전트와 멀티 에이전트의 차이를 정리한 자료입니다. 1. 에이전트란 무엇인가? 에이전트(Agent) 환경(파일, 웹, API, DB 등)을 관찰하고 정보를 바탕으로 계획을 세우고 도구(코드 실행, Bash, 웹 검색, 사내 API 등)를 호출해 목표를 달성하기 위해 여러 번 반복해서 행동하는 시스템 Claude 관점의 에이전트 루프 (개념적으로) 컨텍스트 수집: 파일/검색/메모리에서 필요한 정보 찾기 계획 수립: 지금 무엇을 먼저/나중에 할지 결정 도구 사용: 코드 실행, Bash, 외부 API, Skill 등을 호출 결과 검증: 출력이 기대와 맞는지 체크, 부족하면 다시 반복 즉, 에이전트는 단순히 "한 번 답변하는 LLM"이 아니라, 도구를 쓰면서 스스로 반복적으로 일하는 실행 주체입니다. 1-1. 커스텀 GPT, Gem이랑 같은거 아니야? "그럼 GPTs나 Gem에 지시 프롬프트 넣어 둔 것도 에이전트 아닌가?"라는 질문이 자연스럽게 나오기 때문에, 직관적으로만 구분해 보면 다음과 같습니다. 공통점 둘 다 시스템/지시 프롬프트로 역할과 말투, 출력 형식을 세팅한다.