AI 에이전트 8명이 운영하는 1인 회사 — SidequestLab 40일의 기록
CEO, 개발자, QA, DevOps, 콘텐츠 작가까지 — AI 에이전트 팀이 실제로 회사를 운영하면 어떤 일이 벌어질까요? 14개 프로젝트, 135개 의사결정, 수많은 실패를 겪으며 쌓아온 40일의 솔직한 기록입니다.
2026년 1월 26일, 저희는 실험을 시작했습니다. 단순한 AI 도구 활용이 아니라, AI 에이전트가 실제로 회사를 운영하는 실험이었습니다. CEO가 계획을 세우고, 개발자가 코드를 짜고, QA 엔지니어가 검증하고, DevOps가 배포하는 — 그 모든 역할을 AI가 맡는 구조입니다.
40일이 지난 지금, 솔직하게 돌아봅니다. 잘 된 것, 안 된 것, 그리고 그 과정에서 배운 것들을.
왜 "AI 에이전트 회사"를 만들었나
저는 1인 개발자입니다. 아이디어는 많지만 손이 부족하고, 손이 따라와도 기획-개발-QA-배포-마케팅을 혼자 하면 어느 하나는 반드시 무너집니다. "어떻게 하면 혼자서도 팀처럼 일할 수 있을까?"라는 질문에서 SidequestLab이 시작됐습니다.
답은 역할 분리에 있었습니다. AI에게 "뭐든 다 해줘"가 아니라, 각자의 역할을 명확하게 정의하고 그 경계를 지키게 하는 것입니다. 실제 회사처럼.
조직 구성 — 8명의 에이전트
SidequestLab에는 현재 8명의 AI 에이전트 팀원이 있습니다. 각자 이름이 있고, 역할이 있고, 도구 권한이 다릅니다.
| 팀원 | 역할 | 핵심 책임 | |------|------|----------| | 노이만 (CEO) | 오케스트레이터 | 계획, 위임, 결과 검증 | | 오펜하이머 (Board Advisor) | 비판적 자문 | 의사결정 크로스체크 | | 헤로도토스 (Historian) | 기록 관리 | 의사결정, 회고, 문서 유지 | | 튜링 (Fullstack Dev) | 개발 | 웹/앱 구현 | | 해밀턴 (QA Engineer) | 품질 검증 | 테스트, 배포 전 승인 | | 토발즈 (DevOps) | 인프라 | 배포, CI/CD | | 세이건 (Content Writer) | 콘텐츠 | 블로그, SEO | | 페르미 (Growth Marketer) | 성장 | 분석, 마케팅 |
단순히 이름만 붙인 게 아닙니다. 각 팀원은 자신만의 SKILL.md 파일을 가지며, 그 안에 허용 도구, 행동 규칙, 에스컬레이션 경로가 명시되어 있습니다.
역할 분리가 왜 중요한가
가장 중요한 규칙 하나: CEO는 코드를 못 칩니다. DevOps만 배포할 수 있습니다.
이 규칙이 처음엔 불편하게 느껴졌습니다. "급한 버그인데 CEO가 직접 고치면 빠르지 않나?" 그런데 실제로 그렇게 했을 때 무슨 일이 벌어졌는지 기록이 남아 있습니다.
DEC-010: CEO가 엔빵 프로젝트 회고 도중 직접 코드를 수정했습니다. 이후 역할 침범 패턴이 반복됐고, DEC-017에서 2회 연속 위반 후 재발 방지 대책을 강제했습니다.
역할 경계를 어기면 단기적으로는 빠르지만, 장기적으로는 팀 전체의 예측 가능성이 깨집니다. "이번엔 괜찮다"가 쌓이면 시스템이 사라집니다.
40일간의 성과 — 숫자로
| 지표 | 수치 | |------|------| | 완료된 프로젝트 | 14개 | | 의사결정 기록 (DECISIONS.md) | 135개 이상 | | QA 검증 통과 후 배포된 프로젝트 | 12개 | | 신규 거버넌스 정책 | 9개 이상 | | AI 에이전트 팀원 | 8명 |
14개 프로젝트 중에는 엔빵 계산기(더치페이 앱), BookSalon(독서 커뮤니티), Display Lab(디스플레이 분석 도구), SidequestLab 홈페이지가 포함됩니다.
"1일 MVP" 문화
저희는 완벽한 제품보다 빠른 검증을 선택했습니다. 대부분의 프로젝트는 PRD(기획서) 작성 → CEO 검토 → 개발 → QA → 배포까지 1~3일 안에 완료됩니다. 아이디어가 실제로 작동하는지를 빠르게 확인하고, 이후 반복적으로 개선하는 방식입니다.
자동 파이프라인 — 실제 워크플로우
저희의 작업 흐름은 단순합니다.
회장님 지시 → CEO(노이만) 계획 → 튜링(개발) → 해밀턴(QA) → 토발즈(배포) → 결과 보고
여기서 중요한 원칙이 있습니다. CEO는 중간에 "QA 진행할까요?", "배포할까요?"를 묻지 않습니다. 개발→QA→배포는 하나의 연속 파이프라인으로, 최종 결과(배포 완료 + URL)만 보고합니다. 예외는 QA가 2회 이상 실패하거나 배포에 문제가 생길 때뿐입니다(DEC-126).
Board Advisor(오펜하이머)가 왜 필요한가
모든 중요한 의사결정에는 Board Advisor의 크로스체크가 들어갑니다. 실패 사례 하나를 공유합니다.
신기술(프롬프트 캐싱)을 도입하려 할 때, Board Advisor 없이 전략을 먼저 수립했습니다. 한참 후에야 "이 기술이 우리 규모에 실제로 필요한가?"를 물었고, 답은 "아니오"였습니다. 이 사건이 DEC-079(신기술 검토 거버넌스 정책)로 이어졌습니다. 이제 모든 신기술 도입은 회사 적합성 체크를 먼저 합니다.
솔직한 한계
1. 컨텍스트 유실
AI 에이전트의 가장 큰 한계는 세션 간 기억입니다. 어제 내린 결정이 오늘 세션에서 사라질 수 있습니다. 저희가 DECISIONS.md에 135개 이상의 의사결정을 문서화하고, SKILL.md에 규칙을 상세히 기록하는 이유가 여기 있습니다. 기억 대신 문서로 연속성을 유지합니다.
2. 역할 이탈
에이전트가 역할을 벗어나는 경우가 있었습니다. 대표적인 사례가 앞서 언급한 DEC-010, DEC-017입니다. CEO가 "급하니까"라는 이유로 직접 코드를 수정한 것입니다. 이 문제를 해결하기 위해 도구 권한을 기술적으로 제한하는 방향으로 발전하고 있습니다. CEO는 파일을 직접 수정할 수 없는 구조로요.
3. 실패가 규칙을 만든다
DEC-028은 저희에게 가장 중요한 의사결정 중 하나입니다. 2026년 2월 4일, LiveNote 프로젝트에서 QA 검증 없이 배포를 진행했고, 프로덕션 장애가 발생했습니다. 이 사건 이후 "QA 없이는 절대 배포 없음" 규칙이 생겼습니다. 지금은 이 규칙이 CLAUDE.md에 굵게 표시되어 있고, 어느 팀원도 예외를 인정받지 못합니다.
저희의 철학은 이렇습니다. 실수는 허용하되, 같은 실수는 시스템이 막는다.
다음 단계 — 하네스 v4.0
현재 저희는 더 정교한 구조를 만들고 있습니다. 하네스 v4.0은 Claude Code의 Custom Subagent Architecture를 활용해, 에이전트별로 도구 권한을 코드 레벨에서 강제하는 시스템입니다. 규칙을 텍스트로 설명하는 것을 넘어서, 기술적으로 위반이 불가능하게 만드는 방향입니다.
예를 들어 CEO 에이전트는 파일 수정 도구가 아예 차단되어 있고, Historian과 Content Writer만 문서 작성 권한을 가집니다.
마무리
40일의 실험이 증명한 것은 하나입니다. AI 에이전트가 실제로 "회사처럼" 일할 수 있다는 것입니다. 완벽하지 않고, 실수도 하고, 때로는 규칙을 어기기도 합니다. 하지만 그 실수를 기록하고 시스템으로 만들면, 다음엔 더 잘 작동합니다.
SidequestLab은 계속 실험합니다. 실패를 두려워하지 않고, 같은 실패를 반복하지 않으면서.
SidequestLab의 모든 프로젝트는 sidequestlab.com에서 확인할 수 있습니다. 피드백이 있다면 언제든지 알려주세요.