OpenClaw로 9개의 AI 에이전트 경영 OS를 구축한 이야기 | 설정 및 권한 설계 전격 공개
요약
본 글은 Claude Code의 서브 에이전트 메커니즘을 활용하여 경영 의사결정 보조, 재무 관리 등 9가지 역할을 수행하는 '경영 OS' 구축 과정을 다룹니다. 각 역할에 맞는 전용 에이전트를 정의하고, 최소 권한 원칙(minimum privilege)과 모델 할당 전략을 적용해 효율성을 극대화했습니다.
핵심 포인트
- Claude Code 서브 에이전트로 9개 역할의 '경영 OS' 구축 가능
- 역할별로 전용 에이전트를 정의하여 업무 위임 및 자동화 실현
- 최소 권한 원칙을 적용해 각 에이전트에게 필요한 도구만 제한적으로 부여
- 역할 중요도에 따라 모델 할당(Model assignment)으로 비용과 속도를 최적화
SES 엔지니어로 고객사에 상주하며 일하다 보면, '내가 없으면 이 업무 판단은 누가 할까?'라는 생각을 해본 사람이 많을 것이다. 나는 현재 경영 의사결정 보조, 재무 관리, 태스크 관리, 마케팅 분석까지를 Claude Code 위에 구축한 9개의 AI 에이전트에게 맡기고 있다. 오늘은 2026년 10월 13일 기준으로 실제로 운영하고 있는 '경영 OS'의 설정 파일과 커맨드를 그대로 공개하며 기술적인 측면과 경영적인 측면을 모두 다루겠다.
가상의 성공담을 쓸 생각은 없다. 오히려 '아직 검증하지 못한 부분'까지 포함하여, 실제로 내 손에서 돌아가고 있는 것들만 소개할 것이다.
혼자서 경영을 한다면 재무(CFO 관점), 기술(CTO 관점), 운영(COO 관점), 마케팅(CMO 관점), 전체 총괄(CEO 관점) 등 모든 역할을 동시에 수행하는 것이 어렵다. Notion이나 Excel로 관리하려고 해도, '오늘은 어떤 숫자를 봐야 할까'를 떠올리는 비용 자체가 병목 현상(bottleneck)이 된다. 혼자서 경영부터 구현까지 담당한다면, 연봉이나 SES 단가 이야기가 되기 이전에, 먼저 '봐야 할 곳을 내 대신 순회해 주는 시스템'이 필요하다고 느꼈다.
그래서 Claude Code의 서브 에이전트(sub-agent) 메커니즘을 사용하여 역할별로 전용 에이전트를 정의했다. Claude Code의 서브 에이전트는 .claude/agents/*.md에 YAML 프론트매터가 포함된 Markdown 파일을 놓기만 하면 정의할 수 있다. 예를 들어 CFO 역할을 하는 에이전트는 간략화하면 다음과 같은 형태가 된다.
name: cfo
description: CFO(최고재무책임자). freee 연동으로 재무 데이터 취득・PL 생성・적요 기장・미결제 관리・현금흐름 예측 실행
tools: Bash, Read, Edit
description에 역할과 담당 업무를 적어두면, 메인 Claude Code가 '이번에는 CFO의 일이다'라고 판단하여 자동으로 위임해 준다. 경영자가 매번 '이 태스크는 어느 에이전트에게 던져야 할까?'를 직접 판단할 필요가 없다는 것이 이 시스템의 가장 편리한 부분이다.
현재 운영하고 있는 9개의 역할 분담은 다음과 같다.
| 직책 | 주요 담당 |
|---|---|
| CEO | CFO/CTO/COO/CMO의 보고를 통합하여 경영 대시보드 및 의사결정 지원 |
| ... |
매일 확인해야 하는 항목들은 더욱 단축(shortcut)되었다. 입력하면 내부적으로 대응하는 커맨드가 호출되는 시스템으로, 대시보드 확인, 재무 미결제 확인, 태스크 확인, 제품 헬스 체크, inbox 목록 표시 등을 각각 짧은 한 단어의 커맨드로 불러낼 수 있게 했다. 사소하지만, 매일 아침 순회를 타이핑 몇 번만으로 끝낼 수 있다는 것은 쌓이면 큰 차이가 된다.
모델 할당(Model assignment)도 역할별로 나누고 있다. CEO처럼 여러 보고를 통합하여 의사결정 자료를 만드는 역할에는 추론의 깊이가 필요한 모델을 할당하고, cc-secretary의 inbox 분류 같은 정형 처리에는 가벼운(lightweight) 모델만으로 충분한 경우가 많다. 모든 에이전트에 무겁고 큰 모델을 사용할 필요는 없으며, 역할의 중요도에 따라 비용과 속도의 균형을 맞추고 있다.
Qiita에서는 최근 14일 동안 보안 태그 관련 글이 많이 쌓여서 'AI 에이전트에게 API 키를 전달해도 괜찮은가?'라는 게시물이 화제가 되고 있다. 멀티 에이전트 구성을 실제로 짜다 보면, 이 문제는 피할 수 없다.
Claude Code의 서브 에이전트는 앞서 언급한 tools: 프론트매터에서 도구를 개별적으로 제한할 수 있다. 경영 OS에서도 모든 에이전트에게 Bash나 Edit을 전달하는 것이 아니라, 역할별로 최소 권한(minimum privilege)을 부여하고 있다.
- 트렌드 조사 담당 에이전트에는
WebSearch, WebFetch, Read만 주고, 파일 쓰기나 셸 실행은 못하게 한다. - 배포 전 검증 담당에는Bash, Read, Grep만 주고,Edit(쓰기)는 못하게 한다. 만약 검증 담당이 코드를 직접 수정할 수 있게 된다면, 검증 자체가 무의미해진다. - 사이트 감사 담당에는Bash, Read, Grep, WebFetch를 주지만, 외부 발신 계열 도구는 주지 않는다.
이는 인간 조직에서 말하는 '경리 담당자가 시스템 관리자 권한을 갖지 못한다'는 것과 거의 같은 발상이다. AI 에이전트이기 때문에 예외로 할 이유는 없다. 오히려 자율적으로 움직이는 만큼, 권한 제한은 인간보다 더 엄격해야 한다고 느낀다. SNS 게시물 자동화 에이전트의 경우에도, 생성은 초안까지만 하고 공개는 반드시 사람이 승인하도록 하거나, 동일 계정에 연속으로 올리는 간격을 강제하는 등의 규칙을 명문화하고 있다. 편리하다고 해서 전부 자동화하기보다는, 사고가 난 후에 설계하는 것이 아니라 미리 가드레일을 설치한다는 생각이다.
9개 에이전트 중 cc-knowledge는 교훈/패턴/인시던트를 기록하고 검색하는 역할을 맡는다. 현재는 YAML/Markdown 기반의 구조화 데이터를 키워드로 검색하는 방식이지만, 기록이 늘어날수록 '표현은 다르지만 비슷한 과거의 실패'를 키워드 일치 외의 방법으로 끌어올릴 수 있도록 하고 싶다는 과제가 생긴다.
마침 Zenn의 일일 트렌드에서 'SQLite 본체에 벡터 검색 확장 vec1이 왔다'는 글이 화제였다. SQLite는 개인 개발이나 소규모 에이전트 기반에서 사용하기에 가볍고 다루기 쉬운데, 여기에 벡터 검색(임베딩 기반 유사 검색)이 표준적으로 사용할 수 있게 된다면, cc-knowledge와 같은 '구조화 로그 + 유사 검색' 용도에는 궁합이 좋아 보인다. 지금은 이 구성으로의 전환을 검토하는 단계라 아직 실제 운영에 사용하고 있지는 않다. 검토 중인 것을 '도입 완료'라고 쓰는 것은 성실하지 못하므로, 여기서는 솔직하게 적어두겠다.
경영 대시보드는 기본적으로 자신만 보는 것이지만, 보기 불편한 UI는 결국 사용되지 않는다. Zenn에서 '싫어지는 디자인의 역사'라는 글이 트렌드에 올랐었는데, 내부용 관리 화면에도 같은 이야기가 적용된다. 정보를 너무 많이 채워 넣은 표, 강조 색상을 남용한 알림, 클릭 수가 많은 동선은 인간이 결국 보지 않게 된다.
CEO 에이전트의 대시보드 출력은 '수치 → 판단 자료 → 다음 액션' 순서로 배열하는 단순한 구성으로 하고 있다. 외형적인 멋짐보다는 '매일 아침 1분 안에 읽을 수 있는가'를 우선했다. 도구를 늘릴수록 출력은 화려해지기 쉽지만, 결국 읽히지 않는 화면을 만들어도 의미가 없다.
9개 에이전트를 항상 병렬로 작동시키는 것은 아니다. 단발적인 조사나 확인은 하나의 서브 에이전트에게 맡기는 것만으로 충분하지만, 여러 관점을 가로질러 검토하는 작업은 결정론적 스크립트로 제어하고 싶은 경우가 있다. Claude Code에는 이 두 가지 계층이 있다.
단일 태스크는 Agent 툴로 서브 에이전트를 한 개 호출하는 것만으로 충분하다. 'CTO에게 여러 제품의 상태 점검을 시키기' 정도라면 이것으로 충분하다. 다단계/병렬이 필요한 태스크는 Workflow 툴로 스크립트를 작성하여, 병렬 실행이나 파이프라인 처리로 에이전트를 오케스트레이션한다. 예를 들어 여러 제품에 대한 감사를 병렬로 돌리고, 그 결과를 CTO 에이전트가 통합하는 구성이다.
경영의 최종 판단 자체는 AI에게 맡기지 않는다. 각 에이전트가 내놓는 것은 '보고'와 '선택지 제시'까지만이며, 최종 판단은 인간(나)이 한다. 이는 설계적으로 의도한 바다. 재무 회계 처리나 미결제 관리 같은 정형 처리는 CFO 에이전트에게 맡기고 있지만, '어떤 계약을 끊을지' 같은 판단은 스스로 결정한다.
이 구성을 이야기하면, '계약이나 인사 같은 무거운 판단까지 AI에 맡겨도 괜찮은가?'라는 질문을 받는 경우가 있다. 답은 '맡기지 않는다'이다. 에이전트가 자율적으로 실행하는 것은 freee로의 분개 등록과 같은 정형 작업이나, 여러 데이터 소스를 집계하여 리포트를 만드는 작업까지만이며, 금액이 큰 의사결정이나 계약 체결/해지는 반드시 인간의 승인을 거친다. 자율도를 높일수록 편해지는 것은 사실이지만, 편리함과 위험 감수도는 역할별로 따로 결정해야 한다고 생각한다. 경영 OS라는 단어를 쓰면 완전 자동화된 자율 주행을 상상하기 쉽지만, 실제는 '순찰과 1차 정리를 대신 맡기고, 최종 판단은 내가 하는' 인간 비서팀 같은 설계에 가깝다.
여기까지 기술적인 구성을 썼지만, 경영 지표 기여도를 정량적으로 보여줄 단계는 아니다. 도입 후 운영 기간이 아직 짧고, '구현이 완료되었다'는 것과 '효과가 나와 작동이 안정적이다'는 것은 동의어가 아니라고 스스로에게 경계하고 있다.
말할 수 있는 것은 매일 아침의 순찰 작업(재무 체크, 태스크 확인, 제품 헬스 체크)이 몇 번의 명령어 입력으로 끝날 수 있게 되었다는, 작업 프로세스의 변화다. 수익에 미친 영향(impact)을 주장하려면 운영 기간을 좀 더 거쳐야 진실하다고 생각한다. AI를 경영에 통합하는 이야기는 아무래도 큰 성과를 즉시 이야기하고 싶게 만들지만, 재현할 수 없는 숫자를 적는 것보다 프로세스의 변화만을 솔직하게 쓰는 것이 나중에 읽었을 때 도움이 된다고 생각한다.
지금까지의 이야기는 SES 엔지니어에게는 거리가 멀어 보일 수도 있다. 고객사 상주(常駐)로 특정 시스템의 개발 및 유지보수만 담당하는 경우, 이러한 '사내 툴을 역할 분담에 따라 설계'해 본 경험 자체를 접할 기회가 적은 것도 SES 엔지니어의 실태로서 흔히 있는 구조다. 요구사항 정의나 권한 설계 의사결정에는 관여하지 못하고, 주어진 사양(仕様) 구현에 전념하는 단계가 길어지기 쉽다.
이것은 개별 엔지니어 능력의 문제가 아니라, 다중 하청 구조 속에서 재량이 상위 단계로 치우치기 쉬운 업계 구조의 이야기다. 그렇기에 독립이나 프리랜서, 혹은 자사 개발 기업으로 이직을 고려할 때, 'AI 에이전트에게 무엇을 어디까지 맡길지', '권한을 어떻게 설계할지'를 스스로 결정해 본 경험이 있는지가 연봉이나 커리어 선택지의 폭에 은근히 영향을 미친다. 엔지니어의 커리어 가이드로 자주 언급되는 '코드를 작성할 수 있다'는 능력 외에도, '시스템 전체 설계 및 권한 분리(権限分離)를 자신의 재량으로 결정해 본' 경험을 담당 프로젝트 외부에서 쌓아둘 가치는 있다.
| 체크 항목 | 확인 내용 |
|---|---|
| 권한 분리 | 각 에이전트의 tools를 역할에 따라 최소 권한으로 설정했는지 |
| ... | |
| 이 체크리스트는 개인 개발로 AI 에이전트를 사용해 업무 자동화를 시도하는 사람에게나, SES에서 독립하여 자사 툴을 만들고 싶은 엔지니어 모두에게 그대로 쓸 수 있을 것이다. 저장해 두고 자신의 환경에서 하나씩 점검해 보는 것이 좋다. |
- 프리랜서 엔지니어 연봉 데이터 비교 2026 | 지방 리모트 단가와 SES 계약의 주의점
- 【2026년 최신】AI 코딩 툴 5가지 비교 | Claude Code, Copilot, Cursor 활용법
- SES 다중 하청 구조를 규모별로 해부: 독립 준비와 AI 활용 완전 로드맵
AI 구동塾 — AI를 사용한 스몰 비즈니스(SMB) 구축 방법을 배웁니다
Claude Code, OpenClaw, AI 경영 OS의 실전 노하우를 매주 공개 중입니다.
월액 ¥4,980으로 과거 기사 전체 무제한 열람.
작성자: 합동회사 Radineer (프리랜서 대상 프로젝트 사이트 FreelanceDB 운영)
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기