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
시작하기 전에
낯선 말 3개만 먼저 정리하겠습니다.
TERM 01

AX

  • AI로 일하는 방식으로 조직을 바꾸는 것입니다.
TERM 02

AX 하네스

  • AI가 "다 했다"고 거짓말 못 하게 증거를 강제하는 규칙·게이트·자동화 감시 장치입니다.
TERM 03

폐루프

  • 실행 → 측정 → 개선이 사람 개입 없이 스스로 도는 구조입니다.
이 세 단어만 있으면 오늘 이야기를 따라오실 수 있습니다 — 나머지 낯선 말은 처음 나올 때마다 그 자리에서 풀어드립니다.
PART 1 · 어느 날 밤

퇴근 전, 이슈 보드에
할 일을 쌓아둡니다.

BS 한양 MAESTRO-BS 프로젝트에는 GitHub(코드와 작업 기록을 관리하는 서비스) 이슈 보드가 있습니다. 하루 동안 발견한 버그·기능 요청을 QA·기획팀이 카드로 등록해 Ready(할 일) 칸에 쌓아둡니다. 사람이 하는 일은 여기까지입니다.

PART 1 · 아침의 결과
다음 날 아침 보드를 보면 — 카드가 스스로 움직여 있습니다.
Ready
예시 — 로그인 세션 만료 처리
bug
In Review
예시 — 메뉴 노출 로직 개선
bs-qa-in-review (병합 관문)
통과해야 병합
In Dev
예시 — 결제 API 토큰 갱신
bs-qa-in-dev (완결성 점검)
병합 후 다시 확인
In Staging
예시 — 대시보드 차트 렌더 버그
bs-staging-qa-parallel (최종 검증)
배포 전 마지막 검사
Done
예시 — 알림 큐 재시도 정책
← 밤사이 스스로 여기까지 이동
카드 내용은 이해를 돕기 위한 예시입니다 — 열 구성(Ready → In Review → In Dev → In Staging → Done)은 실제 보드 그대로입니다. 사람이 카드를 끌지 않습니다 — 통과한 것만 옆 칸으로 넘어갑니다.
PART 1 · 이슈 하나의 여정
이슈 하나가 Done까지, 사람 손 없이 이동합니다.
→
→
→
→
이 길을 만드는 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(규칙 학습)
통과하지 못하면 Ready로 돌아갑니다 — 실패 경로는 3부에서 자세히 다룹니다.
PART 1 · 매일의 구조
낮과 밤 구분 없이, 이 네 단어로 돌아갑니다.
TERM
훅(hook)·게이트
커밋·푸시 직전 자동으로 도는 검사기입니다. 조건을 못 채우면 작업을 강제로 막습니다.
TERM
에이전트
특정 역할(구현·리뷰·QA)만 맡는 AI 일꾼입니다.
TERM
worktree
이슈마다 따로 만드는 격리된 작업 폴더입니다 — 서로 파일이 안 섞입니다.
TERM
tmux
그 작업을 실시간으로 지켜볼 수 있는 터미널 창입니다.
정확히 몇 시에 무엇이 도는지는 4부(리듬과 정직)에서 시각표로 보여드립니다.
2
PART 02 / 05 · 구조

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

The Structure

규칙 · 스킬 · 에이전트 · 훅, 네 개 층이 한 방향으로 맞물려 돕니다.

PART 2 · 하네스 4층 구조
기준을 정하면, 절차가 되고, 사람 대신 실행되고, 검사받습니다.
규칙 107개가 스킬 210개로, 스킬이 에이전트 89개로, 에이전트가 훅 52개로 이어지는 4층 구조 적용 실행 검사 01 · RULES 규칙 판단 기준을 적어둔 문서 107개 02 · SKILLS 스킬 그 기준으로 만든 실행 절차 210개 03 · AGENTS 에이전트 절차를 실제로 수행하는 AI 89개 04 · HOOKS 훅 결과를 자동으로 검사 52개
2026-08-13 기준 실측치입니다 — 훅은 조건을 못 채우면 작업을 강제로 막습니다(다음 장).
PART 2 · 왜 필요한가
훅은 AI가 일하는 모든 길목에 끼어듭니다.
코드 작성부터 완료 선언까지의 경로에 세 개의 검문소가 서 있는 그림, 조건 미충족 시 exit 2로 차단 코드 작성 커밋 푸시 완료 선언 비밀키 · 규칙 위반 있으면 커밋 불가 QA 증거 없음 없으면 푸시 불가 실행된 검증 없음 없으면 완료 선언 불가
exit 2(작업을 강제로 멈추는 차단 신호)가 뜨면 다음 단계로 넘어가지 못합니다 — 사람이 깜빡해도, 급해도 통과되지 않습니다.
PART 2 · 그 다음
막기만 하지 않습니다. 스스로 고칩니다.
실행에서 측정, 개선, 규칙화를 거쳐 다시 실행으로 돌아가는 순환 고리 ④에서 다시 ①로 — 사람 개입 없이 ① 실행 에이전트가 이슈를 구현 ② 측정 훅·QA가 증거로 남김 ③ 개선 실패 패턴을 분석·수정 ④ 규칙화 다음부터 자동 적용
④에서 다시 ①로 이어집니다 — 이 순환에는 사람 개입이 없습니다.
3
PART 03 / 05 · BS 파이프라인

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

The BS Pipeline

BS 파이프라인(BS 한양 MAESTRO-BS 프로젝트의 GitHub 이슈를 자동 처리하는 무인 순환)의 실제 동작을 전체 구조부터, 4곳을 확대해서, 두 감시자까지 순서대로 보여드립니다.

PART 3 · 전체 구조 한 장
이슈(할 일) 하나가 Done까지 스스로 이동합니다.
Ready에서 디스패치, 워커, 자가QA, push를 거쳐 In Review, In Dev, In Staging 세 관문을 통과해 Done에 이르는 전체 흐름, 실패 시 Ready로 반송, 상단에 두 감시자 오버레이 가동 중 감시: 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(스테이징 검증)이 순서대로 걸립니다.
PART 3 · 확대 1 — 디스패치
이슈를 골라 격리된 작업 공간을 만듭니다.
보드에서 이슈 선정, 선점, worktree와 tmux 창 생성, 워커 기동으로 이어지는 흐름, bs-auto-issue-loop이 순환을 켜고 끔 보드에서 이슈 선정 Ready 목록 확인 선점(lock) 중복 배정 방지 worktree 생성 이슈 전용 격리 폴더 tmux 창 생성 실시간으로 지켜볼 수 있음 워커(claude -p) 기동 구현을 시작합니다 bs-auto-issue-loop 이 순환을 켜고 끄는 관리자 몇 분마다 반복 실행 여부를 결정합니다 bs-auto-issue: 이 전체 과정을 1회 수행하는 디스패처
PART 3 · 확대 2 — 워커 내부
워커 하나가 스스로 계획하고, 만들고, 검증합니다.
생애주기 — 요청 하나가 push까지
계획, 구현, 팀 소집, 자가QA, push로 이어지는 워커 생애주기 ① 계획 할 일 목록 도출 ② 구현 코드 작성 ③ 팀 소집 리뷰어 AI 동원 ④ 자가QA 스스로 먼저 검증 ⑤ push In Review로 인계
최대 3개 이슈가 동시에, 서로 격리되어 진행됩니다
WORKER A

worktree-A · tmux-A

  • 진행 중 — 다른 워커와 파일이 안 섞입니다
WORKER B

worktree-B · tmux-B

  • 진행 중 — 다른 워커와 파일이 안 섞입니다
WORKER C

worktree-C · tmux-C

  • 진행 중 — 다른 워커와 파일이 안 섞입니다
PART 3 · 확대 3 — QA 3단 관문
세 번 걸러야 Done에 닿습니다.
In Review에서 bs-qa-in-review, In Dev에서 bs-qa-in-dev, In Staging에서 bs-staging-qa-parallel을 거쳐 Done에 도달하는 QA 3단 관문 In Review In Dev In Staging Done bs-qa-in-review 통과 시 dev 병합 bs-qa-in-dev 완결성 재점검 bs-staging-qa-parallel 배포 전 최종 검증
각 관문은 구현한 것과 다른 AI가 diff를 다시 채점합니다 — 자기 채점 금지.
PART 3 · 확대 4 — 실패 경로
성공 경로만 보여드리지 않습니다.
QA 관문 실패가 세 갈래로 나뉘는 흐름 — 가장 흔한 경로는 Ready로 반송, 완결성 점검 실패 시 QA후속 이슈로 분리, 같은 사유가 24시간 내 3회 반복되면 사람 에스컬레이션 QA 관문 실패 In Review · In Dev · In Staging 중 하나 다른 AI가 다시 채점해 걸러냅니다 가장 흔한 경로 Ready로 반송 문제를 고쳐 다시 시도합니다 — 사람이 옮기지 않습니다 완결성 점검 실패 시 [QA후속] 이슈 분리 남은 결함만 새 이슈로 분리해 Ready 큐로 재투입합니다 같은 사유 24시간 내 3회 사람 에스컬레이션 반복되면 자동화가 멈추고 사람의 결정을 요청합니다
막는 것과 못 막는 것을 구분하는 것처럼, 실패했을 때 무슨 일이 일어나는지도 정직하게 보여드립니다.
PART 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.
4
PART 04 / 05 · 리듬과 정직

그럼 지금도
돌고 있나

Rhythm & Honesty

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

PART 4 · 정해진 시각에 도는 것들
cron(정해진 시각마다 자동 실행되는 예약 작업)과 launchd(macOS가 상시 띄워두는 백그라운드 서비스)입니다.
새벽 시간대 예약 작업 4건과 짧은 주기·매시 반복 작업, launchd 상시 서비스로 구성된 타임라인 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로 상시 가동되는 4개 서비스 레인과, 전부 비활성화된 BS 온디맨드 레인, 최근 워커 가동 2026-08-09 상시 (launchd) — 항상 켜져 있음 텔레그램 브릿지 기억 실시간 동기화 외부 트렌드 수집 주간 평가 온디맨드 (BS) — 현재 전부 꺼짐 bs-auto-issue-loop bs-qa-in-review bs-qa-in-dev bs-pipeline-improve bs-self-improve 필요할 때 tmux(터미널 창)를 열어 켭니다 — 가장 최근 워커 가동: 2026-08-09
"구조는 갖췄고, 필요할 때 켠다" — 이것이 현재 상태입니다.
PART 4 · 정직한 한계
이 하네스가 막는 것과 못 막는 것을 구분합니다.
막는다

물리적으로 차단

  • 비가역 실수 — 삭제·배포 같은 되돌릴 수 없는 작업은 사람 승인 전엔 실행되지 않습니다.
  • 증거 없는 완료 주장 — 훅이 exit 2로 작업을 강제로 멈춥니다.
못 막는다

사람의 몫으로 남음

  • 설계 품질 — 코드가 동작해도 구조가 나쁠 수 있습니다.
  • 유지보수성 — 하네스는 최소한을 지키는 바닥이지, 최선을 보장하는 천장은 아닙니다.
5
PART 05 / 05 · 적용 구조

이 구조를
어떻게 들이나

How To Adopt

표준을 한 번에 내려보내지 않습니다 — 단계 · 범위 · 책임을 먼저 정합니다.

PART 5 · 순서
한 번에 전면 도입하지 않습니다 — 검증된 것부터 넓힙니다.
STEP 1

진단

현재 이슈 처리 방식·병목을 구조화된 인터뷰로 파악

→
STEP 2

설계

진단 위에 BS 한양에 맞는 하네스·게이트 기준 설계

→
STEP 3

시범

한두 이슈 유형에서 실제 적용 후 효과 측정

→
STEP 4

확장 결정

책임자 · 보안 · 되돌리기를 갖춘 범위에서만 확장

잘 돌아가던 현장을 흔들지 않는 순서입니다 — 검증된 것부터 단계적으로 넓힙니다.
PART 5 · 적용 범위
AI 산출물을 "완료"로 인정하기 전에, 무엇을 확인할지 정합니다.
절대 기준
개인정보·보안 유출, 비가역 작업(삭제·배포), 사실 오류
위반 시 차단
회사 공통
코드 품질 기준, 커밋·PR 규칙, 훅·게이트 통과 여부
강제 / 점검
이슈·팀별
이슈 유형별 QA 시나리오, 프로젝트별 규칙
점검
개인(워커)
구현 방식 · 프롬프트 스타일
권장
산출물 → 자동 검증 → 사람 승인의 게이트를 통과한 것만 "완료"입니다. 범위는 진단 결과로 확정합니다.
PART 5 · 책임

최종 승인은 항상 사람이 합니다.
AI는 그 판단을 돕습니다.

AI는 반복되는 구현·검증을 분담하고, 사람은 판단이 필요한 곳에 집중합니다. 합격 기준은 적용 전에 문서로 정하고, 데이터 사용 범위와 실패 시 책임자를 명시합니다.

PART 5 · 역량과 위치
이 하네스를 들이려면 무엇이 필요한가
역량

판단력 + 유지보수 감각

  • 프롬프트를 잘 쓰는 것이 아니라 검증 기준을 설계하는 능력입니다.
  • 게이트·자동화를 계속 손보는 유지보수 감각이 필요합니다.
위치

표준을 만들고 적용을 돕는 자리

  • 현업과 개발팀 사이에서 하네스 기준을 수립합니다.
  • 적용은 각 팀, 표준과 검증은 TF가 담당합니다.
이번 발표에서 소개한 규칙·훅·자가개선 폐루프가 바로 그 표준의 실물입니다.

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

① 폐루프실행 → 측정 → 개선이 사람 없이 돕니다.
② 증거 강제AI가 다 했다고 말해도, 증거 없인 끝나지 않습니다.
③ 온디맨드상시 가동이 아니라, 필요할 때 켭니다.
발표 · 김정완 · Hugh Soft
A
APPENDIX · 스킬 참조

스킬 7종을
표로 정리하면

For Reference

본편은 앞에서 끝났습니다 — 여기부터는 참조용 표입니다.

APPENDIX · 스킬 7종 참조
오늘 나온 스킬을 한 표로 정리하면
스킬 역할 실행 방식
bs-auto-issue이슈 선정 → 워커 구현+자가QA → push온디맨드
bs-auto-issue-loop위 과정을 반복하는 순환을 켜고 끄는 관리자온디맨드
bs-qa-in-reviewdev 병합 관문 — 통과해야 병합온디맨드
bs-qa-in-dev병합 후 완결성 재점검온디맨드
bs-staging-qa-parallel배포 전 최종 검증온디맨드
bs-pipeline-improve일일 결함 감지 · 치유일 1회
bs-self-improve실패에서 규칙 학습가동 중
직접 URL로만 접근 가능한 참조 자료입니다 — 발표는 앞장에서 끝났습니다. 🚨 BS 계열은 현재 전부 온디맨드로 켜야 도는 상태입니다(4부 참조).
APPENDIX · 세 루프 한눈에
지금까지 본 조각들은 세 개의 루프로 맞물려 있습니다.
자가개선 루프, HARD 게이트, 워커 자가QA 루프가 위아래로 맞물린 구조 — 자가QA 실패는 재작업을 거쳐 다시 검사받고, 그 경험은 자가개선 루프의 다음 세션 규칙에 반영된다 ① 자가개선 루프 세션 중 실수 예: 되돌린 커밋(fix:) 신호 감지·적재 실수 패턴을 큐에 기록 규칙으로 정리 다음 세션 시작 전 반영 다음 세션 시작 강화된 판단 기준 적용 ② HARD 게이트 커밋 · 푸시 · 완료 선언마다 자동으로 검사합니다 — 조건을 못 채우면 그 자리에서 멈춥니다. 비밀키 · 규칙 위반 QA 증거 없음 실행된 검증 없음 ③ 자가QA 루프 구현 완료 계획→구현→팀 소집 이후 자동 QA (L0~L5) 빌드·타입 + 화면 검증 + 다른 AI 교차 리뷰 PASS? 양쪽 다 통과해야 PASS push · 알림 commit → push → 텔레그램 통보 FAIL bug-fixer 재작업 최대 4회, 고쳐서 다시 검사받습니다 재시도
① 실행→측정→개선→규칙화(10p) ② 커밋·푸시·완료 선언마다 자동 검사(9p) ③ 워커가 스스로 검증 후 push(14p) — 세 루프가 맞물려 사람 없이 돕니다.
1 / ·
← → 또는 Space · F 전체화면