무엇인가
README 팀 표 기준으로 에이전트 14명을 4개 팀에 나눠 앉히고,
일이 들어오면 팀장이 팀원에게 내려보내게 했다.
이 블로그의 프로젝트 목록은 시작을 2026-02-02, 끝을 2026-06-05로 적고,
2026-10-19 확인 기준으로 이 체계는 접혀 있다.
BK-HQ는 새 기능, 버그 수정, 마케팅 실험, 정책 변경을
오케스트레이터 아래 팀장과 팀원 에이전트에게
기업 조직도처럼 나눠 맡기도록 설계한 개인 에이전트 운영 체계다.
오케스트레이터는 일을 받아 팀에 나눠 주고
보고를 모으는 맨 위 에이전트다.
README는 BK-HQ를 "1인 AI 회사"로 소개하고
"CEO(BK)와 AI 에이전트 15명이 4개 팀으로 나뉘어" 일한다고 적었다.
그런데 같은 README의 팀 표에 이름이 오른 에이전트는 14명이다.
인원수부터 README 안에서 서로 맞지 않았다.
왜 만들었나
프로젝트 폴더에서 처음 한 일은 개인 GitHub 계정의 리포지토리를
새 조직의 리포 하나로 옮기려는 요청이었다(2026-02-02).
솔로프리너로 방향을 튼 경위는
커리어 전환기 1편에 적었다.
2026-10-08에 나는 2월의 출발을 이렇게 말했다.
"솔로프린으로서 사스나 기타 앱을 만들어서 출시를 해서 그걸로 돈을 벌어보자"
같은 날 에이전트 메모리를 직접 만든 동기는 이렇게 말했다.
"매 세션이 초기화되면 … 와 이거 엄청 불합리하다"
같은 발화에서 이렇게 이어 갔다.
"그렇다고 핸드오프 문서를 만들어서 넣자니 완벽하지 않고"
이 말에도 BK-HQ라는 이름은 나오지 않는다.
2월 6일에는 에이전트에게 이런 역할을 줬다.
"너는 이제 1인 개발 기업을 운영하는 CEO의 비서겸 총괄 실장이야."
2월 9일에는 폴더 구조를 이렇게 설명했다.
"기업 조직도를 모방해서 디렉토리를 구성한거야."
법무·기획·마케팅 에이전트가 문서를 만드는 운영 리포,
프로젝트마다 하나씩 두고 개발팀 에이전트가 일하는 개발 리포,
두 쪽이 같이 쓰는 템플릿과 규칙과 회사 지침을 담은 최상위 폴더로 나뉜다는 설명이었다.
2월 12일에는 이렇게 입력했다.
"나는 bkan-hq를 정말 실존하는 기업이라고 가정하고 실제로 그렇게 운영하려고해."
어떻게 동작하나
사장은 사장대행에게만, 사장대행은 팀장에게만, 팀원은 팀장에게만 말하는 구조를 원했다.
2월 13일에 나는 이 구조를 이렇게 적었다.
"사장대행인 너는 팀장이랑만 소통하고 팀원은 팀장이랑만 소통한다는거지."
일의 종류마다 팀을 거치는 순서도 정해 두었다.
README는 오케스트레이터가 맡는 일을 "라우팅 · 보고 · 품질 게이트"로 적고
작업 유형에 따라 팀 사이의 인계가 자동으로 이어진다고 설명한다.
| 작업 유형 | 거치는 순서 |
|---|---|
| 새 기능 | 기획, 법무, 개발, 평가, 기획(검수), 법무(최종) |
| 버그 수정 | 개발, 기획(확인) |
| 마케팅 실험 | 마케팅, 개발(지원), 마케팅(분석) |
| 정책 변경 | 법무, 기획, 개발, 기획(검수), 법무(최종) |
README의 훅 표는 훅이 맡은 일을 이렇게 적는다.
훅은 세션 시작이나 도구 실행 같은 시점마다 자동으로 실행되는 스크립트다.
세션 시작 때 맥락을 주입하고, 키워드로 팀을 고르고,
위험한 명령을 막고, 시크릿 출력을 거른다.
사용자가 직접 부르는 슬래시 커맨드 스킬도 따로 있다.
본체 리포 셋(규칙과 훅의 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건이 남아 있다.
5건은 UTC 2026-08-01에 만들어졌고 이름이 test-로 시작하며 모두 실패(failed) 상태다.
실패와 고친 것
실패와 고친 것을 사건별로 적는다.
2월 중순, SNS 자료를 마케팅 팀장에게 맡기고
팀장이 콘텐츠 담당 팀원에게 내려보내게 했는데 작업이 끝나지 않았다.
"15분째 작업하고 있어서 의심스러워가지고 esc로 인터럽트 넣었는데"
나는 팀원은 이미 일을 끝냈는데 팀장이 알아채지 못하는 것 같다고 봤다.
같은 날 쓴 문서는 원인을 이렇게 적었다.
Task 서브에이전트로 띄운 팀장에게
하위 작업의 완료 결과를 받아 오는 TaskOutput 도구가 없다.
해법은 팀장을 claude -p --agent로 띄운
CLI(명령줄) 프로세스로 바꾸고
작업이 끝나면 남는 완료·오류 표지 파일로 완료 여부를 감지하는 것으로 확정했다.
main 트리의 실행 스크립트에는
claude -p --agent 호출과 완료·오류 표지 파일을 만드는 코드가 있고,
주석은 이 파일이 관측용이며 폴링 대상이 아니라고 적는다.
4월 1일에는 Claude Code를 따라가는 커밋이 하루에 몰렸다.
오후에 Claude Code 2.1.89에 맞춰 MCP(모델 컨텍스트 프로토콜)
시작 방식과 훅, 권한 처리까지 다섯 가지를 바꿨고
저녁에는 외부 프롬프트 캐시 패치 도구를 설치 스크립트로 감싸 넣었다.
이어진 커밋 하나는 그 도구가 2.1.89에서 실패한다며 패치 로직을 바꿨고,
다음 커밋이 패치 버그를 고쳤다.
그날 밤 패치 도구 커밋 셋을 모두 되돌렸고
되돌리는 커밋 셋은 1초 안에 연달아 기록됐다.
일주일 뒤에 에이전트가 연 이슈는 깨진 참조(가리키는
파일이 없는 참조) 90건을 정리 대상으로 삼았다.
본문은 그중 73건이 스킬 문서에 설계만 하고 만들지 않은 파일이라 적는다
(본문의 분류별 건수를 더하면 89건이다).
다른 이슈는 등록된 학습 186건 가운데
기술 참고 문서로 옮겨진 것이 0건이라 적었고
처리 댓글은 원인을 "구현 레이어 자체 부재"로 짚었다.
6월 초에는 토큰 사용량이 문제로 올라왔다.
Opus 4.8로 넘어간 뒤 나는 이렇게 입력했다.
"과감하게 삭제해야할 내 하네스를 엄격하게 선별해봐 토큰소모가 너무 엄청나."
하네스는 에이전트를 감싼 규칙·훅·스킬 묶음이다.
그날 새벽 커밋 네 개가
규칙과 SSR 머신러리를 걷어 냈고
커밋 메시지에는 태스크당 서브에이전트 fan-out 제거와 "quality-gate -75%",
"12파일 삭제"가 적혀 있다.
나머지는 표로 정리한다.
| 시기 | 실패 | 고친 것 |
|---|---|---|
| 2~3월 | 에이전트 지침 파일에 기억을 밀어 넣어 파일이 불어났다 | 깎았다. 경위는 지침 파일과 메모리를 다룬 글에 있다 |
| 4월 | 이슈 본문은 세션 시작 훅이 경로를 앵커 없이 찾아 엉뚱한 팀 학습을 주입할 수 있고 실패를 삼켜 0건 주입도 드러나지 않는다고 적었다 | 앵커 패턴과 경고 출력. 처리 댓글 기준 테스트 14건·29건 통과 |
| 4월 | 커밋 메시지는 git add -A 금지가 문서 규칙으로만 있어 재발했다고 적는다 | 훅에서 차단했다. 승격 기준은 위 글에 있다 |
| 5월 | 규칙 문서의 강제어가 Opus 4.7의 지시를 글자 그대로 따르는 성향과 부딪힌다는 분석이 나왔다 | 문서 5개의 "항상/반드시/무조건/금지"를 목표 서술로 바꿨다 |
지금 상태
BK-HQ는 접혀 있다.
이 블로그의 프로젝트 목록은 한 줄 요약을 "Hindsight로 갈아타며 접음"으로 적었다.
본체 리포 셋 모두 6월 초 커밋 이후 7월에는 커밋이 없고 8월에 9건이 더 기록됐다.
2026-10-08에 나는 2월부터 6월까지 자작한 메모리 시스템을 두고 이렇게 말했다.
이 말에 BK-HQ라는 이름은 나오지 않는다.
"동작은 하지만 왜 동작하는지도 사실 잘 모르기도 했었고"
같은 발화에서 Claude Code가 업데이트될 때마다 몇 개는 동작하지 않았다고 했다.
"수정 작업 개선 작업에 들어가는 시간과 비용이 너무너무 컸었던 거지"
결론은 이랬다.
"아 이건 내가 만드는 게 아니고 좋은 오픈소스를 가져다 써야 되겠다"
이 블로그의 프로젝트 목록이 적은 Hindsight로 갈아탄 뒤의 일은
지침 파일과 메모리를 다룬 글에 있다.
2026-07-17에 나는 "스킬들은?"과 "smart 시리즈는 어때?"를 묻고
이렇게 입력했다.
"일단 smartthink만 가져오자. 나머진 레거시다."
이 입력에도 BK-HQ라는 이름은 나오지 않는다.
8월 초에는 SNS 파이프라인을 별도 비공개 리포로 떼어 냈다.
8월 말 세 리포의 마지막 커밋 메시지에는 모두 "포맷 전"이 들어 있다.
infra의 마지막 커밋은 외부 에이전트가 읽는 지침 파일을 "백지 선언"으로 바꿨다.
새 에이전트라고 선언하고, BK-HQ의 규칙·페르소나·워크플로우도 무시하라고 적었다.
리포 셋은 아카이브하지 않은 채 비공개로 남아 있고 그 뒤로 커밋은 없다.
열린 이슈 3건(Node.js 24 전환 잔여 점검, 지식 누적 루프 잔여 작업,
참조 힌트 관측 인프라)도 그대로다.