무엇인가
에이전트 14명을 4개 팀에 나눠 앉히고
일이 들어오면 팀장이 팀원에게 내려보내게 했다.
조직도대로 일을 받은 역할은 그중 일부에 그쳤고
계층을 지키는 데 드는 토큰(AI 사용량)과 수리 시간은 갈수록 불어났다.
6월 초를 끝으로 거의 손을 놓았고 지금은 접어 두었다.
BK-HQ는 새 기능, 버그 수정, 마케팅 실험, 정책 변경을
오케스트레이터 아래 팀장과 팀원 에이전트에게
기업 조직도처럼 나눠 맡기도록 설계한 개인 에이전트 운영 체계다.
오케스트레이터는 일을 받아 팀에 나눠 주고
보고를 모으는 맨 위 에이전트다.
README는 BK-HQ를 "1인 AI 회사"로 소개하고
"CEO(BK)와 AI 에이전트 15명이 4개 팀으로 나뉘어" 일한다고 적었다.
그런데 같은 README의 팀 표에 이름이 오른 에이전트는 14명이다.
인원수부터 README 안에서 서로 맞지 않았다.
왜 만들었나
혼자 SaaS(구독형 소프트웨어)와 앱을 만들어 팔려면,
개발 말고도 기획과 법무와 마케팅을 맡을 일손이 필요했다.
솔로프리너로 방향을 바꾼 경위는
커리어 전환기 1편에 적었다.
2월 초에 에이전트에게 처음 부여한 역할은 이랬다.
"너는 이제 1인 개발 기업을 운영하는 CEO의 비서겸 총괄 실장이야."
며칠 뒤에는 폴더 구조를 회사 조직도에 맞췄다.
법무·기획·마케팅 에이전트가 문서를 만드는 운영 리포,
프로젝트마다 하나씩 두고 개발팀 에이전트가 일하는 개발 리포,
두 쪽이 함께 쓰는 템플릿과 규칙과 회사 지침을 담은 최상위 폴더로 나눴다.
2월 중순에는 이렇게 못 박았다.
"나는 bkan-hq를 정말 실존하는 기업이라고 가정하고 실제로 그렇게 운영하려고해."
어떻게 동작하나
명령은 위에서 아래로만, 보고는 아래에서 위로만 오가게 했다.
나는 사장대행 역할을 맡은 오케스트레이터에게서만 보고를 받는다.
그 아래 단계의 규칙은 2월 중순에 내가 직접 이렇게 적었다.
"사장대행인 너는 팀장이랑만 소통하고 팀원은 팀장이랑만 소통한다는거지."
일의 종류마다 팀을 거치는 순서도 정해 두었다.
README는 오케스트레이터가 맡는 일을 "라우팅 · 보고 · 품질 게이트"로 적고
작업 유형에 따라 팀 사이의 인계가 자동으로 이어진다고 설명한다.
| 작업 유형 | 거치는 순서 |
|---|---|
| 새 기능 | 기획, 법무, 개발, 평가, 기획(검수), 법무(최종) |
| 버그 수정 | 개발, 기획(확인) |
| 마케팅 실험 | 마케팅, 개발(지원), 마케팅(분석) |
| 정책 변경 | 법무, 기획, 개발, 기획(검수), 법무(최종) |
이 흐름은 Claude Code의 훅으로 뒷받침했다.
훅은 세션 시작이나 도구 실행 같은 시점마다 자동으로 실행되는 스크립트다.
세션을 열면 맥락을 주입하고, 프롬프트에 담긴 키워드로 팀을 고르고,
위험한 명령을 막고, 시크릿이 출력되면 걸러 내게 했다.
작업 유형마다 호출하는 슬래시 커맨드도 따로 두었다.
작성은 에이전트가 맡고, 나는 설계와 지시를 맡았다.
본체 리포 셋(규칙과 훅의 infra, 학습을 쌓는 vault, 운영 리포 ops)의
main 브랜치 커밋 1,482건은 작성자가 모두 내 계정이고
그중 1,326건에 Claude 공동 작성자 표기가 붙어 있다
(Co-Authored-By 표기를 대소문자 구분 없이 센 값).
이 블로그의 프로젝트 목록에도 내 역할은 "설계와 지시"로 적었다.
써 보니
일은 3월과 4월에 몰렸고 일이 몰린 곳도 조직도의 몇몇 칸뿐이었다.
아래 표의 입력 행은 이전 PC의 Claude Code 입력 기록에서
BK-HQ 프로젝트로 기록된 행을 한국 시간 기준 달별로 센 값이다.
슬래시 커맨드와 짧은 답까지 들어 있으므로 작업 건수와는 다르다.
커밋은 본체 리포 셋의 main 브랜치를 UTC 기준 달별로 센 값이다.
| 달 | 입력 행 | 커밋 |
|---|---|---|
| 2월 | 1,294 | 149 |
| 3월 | 3,749 | 509 |
| 4월 | 3,641 | 696 |
| 5월 | 359 | 98 |
| 6월 | 68 | 21 |
| 7월 | 46 | 0 |
| 8월 | 34 | 9 |
첫 개발 프로젝트로는 기존에 진행하던 ASHD를 2월에 들여왔고
3월에는 OurFolio 리포가 생겼다.
ops의 콘텐츠 초안 폴더에는 파일이 876개 쌓였다
(main 기준, md 545·log 226·json 105).
비어 있는 칸도 일찍부터 눈에 띄었다.
3월에는 실험 분석과 규정 점검을 맡긴 두 에이전트를 두고
"아직 미활용 에이전트인가?"라고 물었다.
1분 뒤에는 A/B 테스트를 언제 할 수 있는지 묻고 이렇게 덧붙였다.
"내가 경험이 전무해서 만들어는 뒀는데 어떻게 활용해야할지 고민이야"
ops의 마지막 커밋에서도 법무팀의 정책·체크리스트 폴더,
마케팅팀의 실험 폴더, 기획팀의 PRD(제품 요구사항 문서)
폴더와 UX(사용자 경험) 분석 폴더에는
빈 폴더를 유지하기 위한 표지 파일 하나만 있다.
PRD 3개는 그 폴더 밖에 놓여 있다.
부서를 만들어 둔다고 해서 그 부서가 일을 받게 되지는 않았다.
실시간 에이전트 모니터링용으로 만든 대시보드의 운영 DB 사본에는 실행 5건이 남아 있다.
2026-08-02의 테스트 실행이고 5건 모두 실패(failed) 상태다.
실패와 고친 것
실패는 대부분 계층을 지키는 비용과 바뀌는 도구를 따라가는 비용에서 비롯됐다.
2월 중순, SNS 자료를 마케팅 팀장에게 맡기고
팀장이 콘텐츠 담당 팀원에게 내려보내게 했는데 작업이 끝나지 않았다.
"15분째 작업하고 있어서 의심스러워가지고 esc로 인터럽트 넣었는데"
알고 보니 팀원은 이미 일을 끝냈고 팀장이 그 사실을 알아채지 못하고 있었다.
원인은 Task 서브에이전트로 띄운 팀장에게
하위 작업의 완료 결과를 받아 오는 TaskOutput 도구가 없다는 데 있었다.
그때 정한 해법은 팀장을 claude -p --agent로 띄운
CLI(명령줄) 프로세스로 바꾸고
작업이 끝나면 남는 완료·오류 표지 파일로 완료 여부를 감지하는 것이었다.
4월 1일에는 Claude Code를 따라가는 비용이 한꺼번에 드러났다.
오후에 Claude Code 2.1.89에 맞춰 MCP(모델 컨텍스트 프로토콜)
시작 방식과 훅, 권한 처리까지 다섯 가지를 바꿨고
저녁에는 외부 프롬프트 캐시 패치 도구를 설치 스크립트로 감싸 넣었다.
그 도구가 2.1.89에서 실패하는 바람에 패치 로직을 고치고 버그를 한 번 더 잡았다.
그날 밤 패치 도구 커밋 셋을 모두 되돌렸고
되돌리는 커밋 셋은 1초 안에 연달아 기록됐다.
일주일 뒤에는 설계만 있고 실물이 없는 부분이 드러났다.
에이전트가 이슈 본문에 남긴 집계에 따르면
깨진 참조(가리키는 파일이 없는 참조) 90건 가운데
73건이 스킬 문서에 설계만 해 두고 만들지 않은 파일이었다
(본문의 분류별 건수를 더하면 89건이다).
다른 이슈에는 등록된 학습 186건 가운데
기술 참고 문서로 옮겨진 것이 0건이라고 적혀 있었고
그 원인을 "구현 레이어 자체 부재"로 짚었다.
이 학습을 쌓던 메모리 시스템을 두고 나중에 나는 이렇게 말했다.
"동작은 하지만 왜 동작하는지도 사실 잘 모르기도 했었고"
계층의 비용은 6월 초에 토큰 사용량으로 드러났다.
Opus 4.8로 넘어간 뒤 나는 이렇게 입력했다.
"과감하게 삭제해야할 내 하네스를 엄격하게 선별해봐 토큰소모가 너무 엄청나."
하네스는 에이전트를 감싼 규칙·훅·스킬 묶음이다.
그날 새벽 커밋 네 개가
태스크마다 서브에이전트를 여럿 띄우던 구조를 걷어 냈고
커밋 메시지에는 "quality-gate -75%"와 "12파일 삭제"가 적혀 있다.
나머지는 표로 정리한다.
| 시기 | 실패 | 고친 것 |
|---|---|---|
| 2~3월 | 에이전트 지침 파일에 기억을 밀어 넣어 파일이 불어났다 | 깎았다. 경위는 지침 파일과 메모리를 다룬 글에 있다 |
| 4월 | 세션 시작 훅이 경로를 앵커 없이 찾아 엉뚱한 팀 학습을 주입할 수 있었고 실패를 삼켜 0건 주입도 드러나지 않았다 | 앵커 패턴과 경고 출력. 처리 댓글 기준 테스트 14건·29건 통과 |
| 4월 | git add -A 금지를 스킬 문서 규칙으로만 두어 같은 계열 실수가 다섯 번째 재발했다 | 훅에서 git add -A·--all·git add . 차단, 테스트 10개 추가 |
| 5월 | 규칙 문서의 강제어가 Opus 4.7의 지시를 글자 그대로 따르는 성향과 부딪힌다는 분석이 나왔다 | 문서 5개의 "항상/반드시/무조건/금지"를 목표 서술로 바꿨다 |
지금 상태
BK-HQ는 접혀 있다.
이 블로그의 프로젝트 목록에는 기간을 2026-02-02부터 2026-06-05까지로,
한 줄 요약을 "Hindsight로 갈아타며 접음"으로 적었다.
본체 리포 셋 모두 6월 초 커밋 이후 7월에는 커밋이 없고 8월에 9건이 더 기록됐다.
접은 뒤에 나는 이 시기에 만든 메모리 시스템을 두고
Claude Code가 업데이트될 때마다 몇 개는 동작하지 않았다며 이렇게 말했다.
"수정 작업 개선 작업에 들어가는 시간과 비용이 너무너무 컸었던 거지"
결론은 이랬다.
"아 이건 내가 만드는 게 아니고 좋은 오픈소스를 가져다 써야 되겠다"
Hindsight로 옮긴 뒤의 일은 지침 파일과 메모리를 다룬 글에 있다.
8월 초에는 SNS 파이프라인을 별도의 비공개 리포로 분리했다.
8월 말 세 리포의 마지막 커밋 메시지에는 모두 "포맷 전"이 들어 있고
infra의 마지막 커밋은 외부 에이전트가 읽는 지침 파일을 "백지 선언"으로 바꿨다.
BK-HQ의 규칙과 페르소나와 워크플로우를 전부 무시하라는 내용이다.
리포 셋은 아카이브하지 않은 채 비공개로 남아 있고 그 뒤로 커밋은 없다.
열린 이슈 3건(Node.js 24 전환 잔여 점검, 지식 누적 루프 잔여 작업,
참조 힌트 관측 인프라)도 그대로다.
7월에 새 환경으로 스킬을 옮길 때는 이렇게 정했다.
"일단 smartthink만 가져오자. 나머진 레거시다."
조직도는 리포에 남았고, 새 환경으로 옮겨 간 것은 스킬 하나였다.