BS 한양 AX TF · 브리핑

BS 한양 AX 하네스
사람이 안 봐도 스스로 도는 AI 자동화 감시 장치

AX(AI Transformation — AI로 일하는 방식으로 조직을 바꾸는 것)를 실제로 돌리는 하네스를 소개합니다. 우리는 이것을 AX 하네스라 부릅니다 — Claude Code(코드를 작성하고 검증하는 AI 도구) 위에 쌓은 규칙·게이트·자동화 층으로, AI가 "다 했다"고 거짓말하지 못하게 증거를 강제로 요구하는 감시 장치입니다.

발표 · 김정완 · Hugh Soft
2026-08-13 기준 실측
규칙107
스킬210
에이전트역할별 AI 일꾼89
훅자동 검사기52
오늘 볼 구조
세 부분만 보시면 됩니다.
1부 · 하네스 규칙·스킬·에이전트·훅 4층 토대 2부 · BS 파이프라인 그 위에서 이슈가 자동으로 도는 무인 순환 3부 · 언제 도나 정해진 시각 vs 필요할 때(온디맨드) 지금부터 이 순서대로 보여드립니다
용어부터
낯선 말 3개만 먼저 정리하겠습니다.
AX
AI로 일하는 방식으로 조직을 바꾸는 것
AX 하네스
거짓 완료를 막는 규칙·게이트·자동화 감시 장치
폐루프
실행→측정→개선이 사람 없이 스스로 도는 순환
1부

하네스는 무엇으로 이루어져 있나

규칙 · 스킬 · 에이전트 · 훅, 4개 층이 서로 맞물려 돕니다.

이어지는 3장에서 그 구조와, 왜 이렇게 만들었는지를 보여드립니다.

하네스 4층 구조
기준을 정하면, 절차가 되고, 사람 대신 실행되고, 검사받습니다.
규칙 · 107 판단 기준을 적어둔 문서 "이럴 땐 이렇게 하라"는 원칙을 글로 남깁니다 적용 스킬 · 210 그 기준으로 만든 실행 절차 QA·배포·이슈 처리 같은 반복 작업의 매뉴얼입니다 실행 에이전트 · 89 그 절차를 실제로 수행하는 AI 구현·리뷰·QA처럼 역할 하나만 맡는 일꾼입니다 검사 훅(hook) · 52 그 결과를 자동으로 검사 조건을 못 채우면 작업을 강제로 막습니다
2026-08-13 기준 실측치입니다.
왜 필요한가
훅은 AI가 일하는 모든 길목에 끼어듭니다.
에이전트가 작업 지시(도구 호출) PreToolUse 훅 검문 실행 전 — 위험한 명령·규칙 위반 확인 exit 2 → 차단 조건 미충족 시 통과 도구 실행 · 작업 진행 Stop 훅 검문 — 증거 확인 완료 선언 전 — 테스트 결과·로그가 있는가 exit 2 → 차단 증거 없을 시 통과 완료 (증거 동반)
exit 2(작업을 강제로 멈추는 차단 신호) — 이 신호가 뜨면 다음 단계로 넘어가지 못합니다.
그 다음
막기만 하지 않습니다. 스스로 고칩니다.
폐루프 ① 실행 에이전트가 이슈를 구현 ② 측정 훅·QA가 증거로 남김 ③ 개선 실패 패턴을 분석·수정 ④ 규칙화 다음부터 자동 적용
④에서 다시 ①로 이어집니다 — 이 순환에는 사람 개입이 없습니다.
2부

이 하네스가 BS 한양에서 어떻게 도나

BS 파이프라인(BS 한양 MAESTRO-BS 프로젝트의 GitHub 이슈를 자동 처리하는 무인 순환)의 실제 동작을 보여드립니다.

전체 구조부터, 4곳을 확대해서, 두 감시자까지 순서대로 다룹니다.

전체 구조 한 장
이슈(할 일) 하나가 Done까지 스스로 이동합니다.
가동 중 감시: bs-pipeline-improve(일 1회) · bs-self-improve — 파이프라인 자체를 지켜봅니다 Ready 할 일 등록 bs-auto-issue 이슈 집어 워커 기동 워커(worktree+tmux) 구현→팀 소집→자가QA feature push 브랜치 올림 In Review bs-qa-in-review In Dev bs-qa-in-dev In Staging bs-staging-qa-parallel Done 실패하면 Ready로 반송됩니다 (다음 4장에서 자세히)
bs-qa-in-review(dev 병합 관문) · bs-qa-in-dev(병합 후 완결성 점검) · bs-staging-qa-parallel(스테이징 검증) · worktree(이슈마다 따로 만드는 격리된 작업 폴더) · tmux(그 작업을 지켜볼 수 있는 터미널 창)
확대 1 · 디스패치
이슈를 골라 격리된 작업 공간을 만듭니다.
보드에서 이슈 선정 Ready 목록 확인 선점(lock) 중복 배정 방지 worktree 생성 이슈 전용 격리 폴더 tmux 창 생성 실시간으로 지켜볼 수 있음 워커(claude -p) 기동 구현을 시작합니다 bs-auto-issue-loop 이 순환을 켜고 끄는 관리자 몇 분마다 반복 실행 여부를 결정합니다 bs-auto-issue: 이 전체 과정을 1회 수행하는 디스패처
확대 2 · 워커 내부
워커 하나가 스스로 계획하고, 만들고, 검증합니다.
① 계획 할 일 목록 도출 ② 구현 코드 작성 ③ 팀 소집 리뷰어 AI 동원 ④ 자가QA 스스로 먼저 검증 ⑤ push In Review로 인계 최대 3개 이슈가 동시에, 서로 격리되어 진행됩니다 워커 A worktree-A · tmux-A 진행 중 워커 B worktree-B · tmux-B 진행 중 워커 C worktree-C · tmux-C 진행 중
worktree(이슈마다 따로 만드는 격리된 작업 폴더) · tmux(그 작업을 지켜볼 수 있는 터미널 창) — 서로 파일이 안 섞입니다.
확대 3 · QA 3단 관문
세 번 걸러야 Done에 닿습니다.
In Review In Dev In Staging Done bs-qa-in-review 통과 시 dev 병합 bs-qa-in-dev 완결성 재점검 bs-staging-qa-parallel 배포 전 최종 검증
각 관문은 구현한 것과 다른 AI가 diff 를 다시 채점합니다 — 자기 채점 금지.
확대 4 · 실패 경로
성공 경로만 보여드리지 않습니다.
QA 실패 · 반려 Ready로 반송 가장 흔한 경로 문제를 고쳐 다시 시도 사람이 옮기지 않습니다 [QA후속] 이슈 분리 완결성 점검 실패 시 남은 결함만 새 이슈로 Ready 큐로 재투입 사람 에스컬레이션 같은 사유 24시간 내 3회 반복 시 자동화가 멈춤 사람 결정 요청 막는 것과 못 막는 것을 구분하는 것처럼, 실패했을 때 무슨 일이 일어나는지도 정직하게 보여드립니다.
두 감시자
일하는 동안, 파이프라인 자체를 지켜보는 스킬도 있습니다.
두 스킬 모두 파이프라인 가동 기간에 주기적으로 함께 돕니다 일 1회 bs-pipeline-improve 일일 결함 감지 · 치유 매일 파이프라인 운영 지표를 훑어 결함 패턴을 찾고 스스로 고칩니다. 가동 중 bs-self-improve 실패에서 규칙 학습 반복되는 실패 사례를 분석해 다음 워커가 참고할 규칙을 갱신합니다.
이것으로 스킬 7종을 모두 소개했습니다 — bs-auto-issue · bs-auto-issue-loop · bs-qa-in-review · bs-qa-in-dev · bs-staging-qa-parallel · bs-pipeline-improve · bs-self-improve.
3부

그럼 지금도 돌고 있나

정직하게 답합니다 — 정해진 시각에 도는 것과, 필요할 때만 켜는 것을 구분해서 보여드립니다.

정해진 시각에 도는 것들
cron(정해진 시각마다 자동 실행되는 예약 작업)과 launchd(macOS가 상시 띄워두는 백그라운드 서비스)입니다.
00:43 하네스 진화 루프 harness-evolution-loop 04:00 설정 백업·동기화 cc-sync 04:23 기억 동기화 mbc-catchup 04:37 로그 정리 rotate-hook-triggers 5·10·30분·매시마다 폭주 감시 · 부하 감시 자가개선 신호 수집 매시 정각 클론 매시 17·47분 청소 launchd 상시 브릿지·기억동기화 트렌드수집·주간평가
BS 한양 관련 작업은 이 목록에 없습니다 — 다음 장에서 이유를 설명합니다.
🚨 정직하게 말씀드리면
BS 한양 파이프라인은 지금 상시로 돌고 있지 않습니다.
상시 (launchd) — 항상 켜져 있음 텔레그램 브릿지 기억 실시간 동기화 외부 트렌드 수집 주간 평가 온디맨드 (BS) — 현재 전부 꺼짐 bs-auto-issue-loop bs-qa-in-review bs-qa-in-dev bs-pipeline-improve bs-self-improve 필요할 때 tmux(터미널 창)를 열어 켭니다 — 가장 최근 워커 가동: 2026-08-09
"구조는 갖췄고, 필요할 때 켠다" — 이것이 현재 상태입니다.
마지막

정직한 한계와, 한 문장 요약

막는 것과 못 막는 것을 구분한 뒤, 세 가지로 마무리합니다.

정직한 한계
이 하네스가 막는 것과 못 막는 것을 구분합니다.
막는다 비가역 실수 삭제·배포 같은 되돌릴 수 없는 작업은 사람 승인 전엔 실행되지 않습니다. 증거 없는 완료 주장 훅이 exit 2로 작업을 강제로 멈춥니다. 못 막는다 설계 품질 코드가 동작해도 구조가 나쁠 수 있습니다. 유지보수성 하네스는 최소한을 지키는 바닥이지, 최선을 보장하는 천장은 아닙니다.

AX 하네스는 세 가지로 요약됩니다.

① 폐루프실행 → 측정 → 개선이 사람 없이 돕니다.
② 증거 강제AI가 다 했다고 말해도, 증거 없인 끝나지 않습니다.
③ 온디맨드상시 가동이 아니라, 필요할 때 켭니다.
발표 · 김정완 · Hugh Soft
1 / ·
← → 또는 Space · F 전체화면