개인 개발을 계속하다 보면 어느 시점에 깨닫게 된다. 매번 똑같은 판단을 반복하고 있다는 사실을.

"이것은 대장에 기입해야 할까?" "QA는 필요할까?" "경쟁사 조사를 먼저 하는 것이 좋을까?" —— 이러한 판단이 매 세션 발생한다. 지치게 되고, 누락도 발생한다.

이 문제를 해결하기 위해, Claude Code에 CEO·QA·사업 개발·기술 검증의 4개 부문을 둔 'AI 회사'를 1개월간 운영해 보았다. 본 기사는 그 실록이다.

역할 정의서는 모두 마크다운 (Markdown) 파일로 관리하며, Claude Code에 읽히는 운용 방식이다. 복수의 에이전트(Agent)나 복수의 LLM을 띄우는 것이 아니라, 동일 세션 내에서 인격을 전환하는 심플한 설계.

CEO 역할 정의서에서 가장 효과적이었던 것은, "CEO가 임의로 결정해도 되는 범위"와 "오너 확인이 필수인 범위"를 표로 만든 것이다.

이 표를 작성한 이후로, "이것을 확인해야 하는가?"라는 판단 비용이 사라졌다. 템포가 눈에 띄게 올라간다.

QA부의 역할 정의서에는 "당신의 업무는 개선점을 찾는 것이다. 좋은 점을 칭찬할 필요는 없다"라고 명시하고 있다.

실제로 운용해 보니, 재작업(差し戻し)은 상상 이상으로 빈번하게 발생했다. 1개월 동안 확인된 것만 6회 이상의 리뷰 사이클을 완주했다. 품질은 확실히 변한다.

1개월 동안 '실수'는 4번 있었다.

• CEO 대행 작업을 오너가 진행했다고 오귀속했다
• 브라우저 자동화 (Playwright MCP)를 도입했음에도 사용하지 않았다
• 양론 병기(両論併記) 습관 때문에 판단을 떠넘기지 못했다
• 신규 아이디어 상담 시 기존 PJ와의 중복을 간과했다

모두 발생 직후에 메모리 파일 (feedback_*.md)에 기록하고, 다음 세션부터 자동으로 적용하는 운용을 하고 있다. 같은 실수는 단 한 번도 반복하지 않았다.

특히 "PJ 대장 46회 갱신"은 스스로 하려고 했다면 절대로 게을리했을 영역이다. CEO에게 "구현 직후에 대장을 갱신하라"는 규칙을 부여하면, 정말로 수행해 준다.

Claude Code 통상 운용 프레임, Cloudflare Pages, Astro를 무료로 사용하여, 추가 비용은 도메인 비용뿐이다.

• 역할 정의서(마크다운)를 작성하는 것만으로 판단 비용이 사라진다
• QA부에 "칭찬하지 마라"고 쓰면 품질이 변한다
• 실패 → 즉시 메모리 기록 → 운용 규칙화로 같은 실수를 반복하지 않는다
• 월 비용 ¥170으로 개인 개발이 돌아간다

상세한 역할 정의서 내용·상담 처리 플로우·4가지 실패 패턴 전문은 원문에 작성했습니다: