# 인터넷 없이도 Evidence와 승인 을 지키는 AI-PMO-OS 운영체계를 만들었다
## 📝 한줄 요약
AI가 프로젝트 문서를 읽고 요약하는 수준을 넘어, **원본·버전·Evidence·결함·사람 승인·변경 이력을 연결하는 오프라인 AI-PMO-OS**를 만들었다. 신규 산출물 수령부터 품질검토, 조치, 재시험, Baseline 승격까지 하나의 통제 흐름으로 설계하고 로컬 대시보드와 재사용 가능한 Skill로 운영화했다.
**바쁘시면 이것만 읽어도 돼요:**
- AI의 제안과 사람이 승인한 공식 상태를 분리했다.
- 파일 존재 여부와 실제 사용 가능 여부를 다르게 판정했다.
- 원본 문서의 위치·버전·해시와 AI 판단을 Evidence로 연결했다.
- 점수보다 먼저 확인하는 8개 하드 게이트를 만들었다.
- 품질검토를 9개 영역과 57개 기계판독 체크로 표준화했다.
- 부족한 자료는 요청으로 끝내지 않고 담당·완료조건·재시험이 있는 Action으로 전환했다.
- 새 산출물을 받는 순간부터 적용하는 Intake Gate를 만들었다.
- 인터넷·외부 API·외부 폰트 없이 실행 가능한 로컬 Control Center를 구성했다.
- 사람 승인 전에는 Candidate를 공식 Baseline으로 자동 승격하지 않게 했다.
## 🎯 이런 분들께 도움돼요
- AI를 PMO·품질관리·산출물 검토에 적용하려는 사람
- 프로젝트 문서가 많아 버전과 승인 상태를 추적하기 어려운 조직
- AI의 요약과 공식 프로젝트 상태를 분리해야 하는 PM·PMO
- 폐쇄망·내부망·보안 환경에서 로컬 AI 활용을 검토하는 팀
- 반복되는 산출물 검토를 Skill과 Workflow로 표준화하려는 실무자
## 😫 문제 상황 (Before)
처음에는 여러 AI 에이전트가 요구사항, 일정, 위험, 품질, 보고 업무를 나눠 수행하는 시스템을 구상했다. 기능 목록은 빠르게 늘어났지만, 실제 PMO 업무에 적용하려면 먼저 해결해야 할 문제가 있었다.
AI가 어떤 문제를 발견했다고 말했을 때 다음 질문에 답할 수 있어야 했다.
```text
어떤 원본을 읽었는가?
어느 위치를 근거로 판단했는가?
문서의 버전과 승인 상태는 무엇인가?
AI가 제안한 것인가, 사람이 승인한 공식 상태인가?
문제가 수정됐다면 어떤 범위를 다시 시험했는가?
```
기존 방식에서는 파일이 폴더에 있다는 이유로 검토 준비가 끝난 것처럼 보이기 쉬웠다. 하지만 파일명과 내부 버전이 다르거나, 비어 있는 양식이 실제 운영대장처럼 보이거나, 초안이 승인본과 함께 섞일 수 있었다.
대시보드도 마찬가지였다. 화면이 완성됐다는 사실과 프로젝트가 인수 가능한 상태라는 사실은 전혀 다르다. AI가 만든 설명·요약·그래프가 공식 Evidence를 대신해서는 안 됐다.
그래서 목표를 바꿨다.
```text
AI가 많은 업무를 자동화하는 시스템
```
보다 먼저,
```text
AI가 어떤 근거로 판단했고,
사람이 무엇을 승인했으며,
현재 어떤 결함이 열려 있는지 설명할 수 있는 시스템
```
을 만들기로 했다.
## 🛠️ 사용한 도구
- **Hermes Agent:** 로컬 파일 검토, Workflow 실행, Skill 운영
- **로컬 문서 분석:** PDF·문서·표·이미지형 자료의 구조 확인
- **CSV·JSON:** 체크리스트·정책·상태·Action Register 관리
- **SHA-256:** 파일 무결성과 변경 여부 확인
- **Hermes Skill:** 검토 절차를 반복 실행 가능한 형태로 패키징
- **로컬 HTML·JavaScript:** 인터넷 없이 실행되는 Control Center
- **브라우저 검증:** 화면·필터·상호작용·콘솔 오류 확인
원본 산출물은 수정하지 않았다. 내부 파일을 외부 AI 서비스에 업로드하지 않고, 검토 결과는 별도의 로컬 결과 폴더에 저장했다.
---
## 🔧 작업 과정
### 1. 에이전트보다 먼저 네 개의 Ledger를 설계했다
AI-PMO-OS의 중심을 에이전트 수가 아니라 네 개의 원장으로 정했다.
#### Document Ledger
- 문서 ID
- 파일명과 내부 제목
- 버전·작성일·승인일
- 해시
- 보안등급
- 공식 상태
#### Evidence Ledger
- AI 판단과 연결된 원본 위치
- 페이지·문단·표·셀
- 짧은 근거 대목
- 근거의 권위와 사용 제한
#### Project Knowledge Ledger
- 요구사항
- 일정
- 위험·이슈
- 결정·Action
- 시험·산출물
- 항목 간 연결 관계
#### Change/Audit Ledger
- AI 제안
- 사람 검토·승인·반려
- 변경 전후 상태
- 실행 주체와 시각
- 재시험 결과
AI가 추출한 정보는 기본적으로 `Candidate` 상태에서 시작한다. 사람이 검토하고 승인한 항목만 `Approved` 상태로 바뀌며, 승인 전에는 공식 프로젝트 상태에 반영되지 않는다.
---
### 2. 파일의 ‘존재’와 ‘사용 가능’을 분리했다
산출물 폴더를 확인할 때 파일 수만 세지 않았다. 각 파일에 다음 질문을 적용했다.
```text
파일명과 내부 제목이 일치하는가?
버전과 개정이력이 있는가?
작성자·검토자·승인자가 구분되는가?
승인일과 공식상태를 확인할 수 있는가?
매니페스트의 크기와 해시가 실제 파일과 일치하는가?
초안·양식·참고자료·승인본이 구분되는가?
```
해시가 일치하면 파일이 바뀌지 않았다는 것은 확인할 수 있다. 그러나 내용이 정확하고 공식 승인됐다는 의미는 아니다.
그래서 상태를 다음처럼 분리했다.
- `OFFICIAL`
- `APPROVED`
- `CANDIDATE`
- `DRAFT`
- `TEMPLATE`
- `SUPPORTING_ONLY`
- `PENDING_APPROVAL`
- `UNVERIFIED`
이 구분으로 “자료가 있다”와 “결정에 사용할 수 있다”를 혼동하지 않게 됐다.
---
### 3. 점수보다 먼저 확인하는 8개 하드 게이트를 만들었다
AI 산출물의 평균점수가 높아도 보안·권리·승인·운영안전 문제가 있으면 사용할 수 없다. 그래서 품질점수보다 먼저 통과해야 하는 하드 게이트를 만들었다.
1. **기준선·권위** — 공식 범위와 승인 권위를 확인할 수 있는가?
2. **법적 권리** — 개인정보·저작권·라이선스가 해결됐는가?
3. **보안** — 인젝션·권한상승·유출 위험을 통제하는가?
4. **인간통제** — 승인·거부·롤백이 가능한가?
5. **재현성** — 버전·입력·환경·로그가 남는가?
6. **합격기준** — 지표·표본·평가셋·승인 기준이 정해졌는가?
7. **Critical 결함** — 운영을 막아야 할 결함이 없는가?
8. **운영안전** — 모니터링·Incident·중지·복구 절차가 있는가?
게이트가 실패하면 평균점수가 높아도 인수·Baseline·배포를 진행하지 않는다. 핵심 Evidence가 부족하면 억지로 점수를 계산하지 않고 `U(미검증)` 상태로 남긴다.
---
### 4. 품질검토를 9개 영역·57개 Check로 표준화했다
하드 게이트를 통과한 산출물만 세부 품질평가를 진행하도록 설계했다.
- 기준선·목적 적합성
- 문서 완전성
- Evidence·추적성·재현성
- 데이터 품질·거버넌스
- 기능·업무 성능
- 안전·보안·개인정보·공정성
- 인간통제·사용자 경험
- 신뢰성·운영·모니터링
- 변경·릴리즈·공급망
각 체크에는 다음 정보를 갖게 했다.
```text
Check ID
→ 적용 여부
→ 평가기준
→ 확인한 Evidence
→ 원점수
→ 결함 등급
→ 필요한 조치
→ 완료조건
→ 재시험 범위
```
외부 가이드와 연구자료는 참고 근거로 사용하되, 그 안의 예시 수치를 프로젝트 합격선으로 그대로 복제하지 않았다. 프로젝트의 합격선은 권한 있는 사람이 사전에 승인해야 한다.
---
### 5. 부족한 자료를 실행 가능한 Action으로 전환했다
검토보고서가 “자료 부족”이라는 문장으로 끝나면 다음 행동이 불명확하다. 그래서 열린 항목마다 Action Register를 만들었다.
각 Action에는 다음을 기록했다.
- 우선순위
- 필요한 공식 Evidence
- 담당 역할
- 선행조건
- 제안기한
- 완료조건
- 영향범위
- 재시험 범위
- 종료 승인자
예를 들어 “변경관리 자료가 필요하다”는 요청만 남기는 것이 아니라 다음처럼 구조화한다.
```text
승인된 변경 원장과 승인 기록 확보
→ 문서 ID·버전·승인자 확인
→ 관련 요구사항과 일정 영향 연결
→ 영향받는 산출물 재검토
→ 사람 승인
→ 결함 종료
```
이 구조 덕분에 AI의 발견이 실제 PMO 조치와 재시험으로 이어질 수 있게 됐다.
---
### 6. 신규 제출물의 입구에 Intake Gate를 만들었다
문제가 쌓인 뒤에 검토하는 것보다, 새 파일을 받는 순간부터 통제하는 편이 효율적이다. 그래서 모든 신규 산출물에 동일한 Intake 절차를 적용했다.
```text
제출물 수령
→ 파일 인벤토리
→ 문서 ID·제목·버전 확인
→ 작성·검토·승인 상태 확인
→ 보안·개인정보·권리 확인
→ 파일 크기·SHA-256·매니페스트 대조
→ 공식·후보·초안·참고자료 분리
→ 기존 결함·Action과 자동 매칭
→ 추적성 영향 분석
→ 필요한 범위 재시험
→ 사람 승인 후 상태 변경
```
검사에 실패한 파일은 자동으로 공식 상태에 반영하지 않는다. 문제 유형에 따라 격리·보완 요청·반려·제한적 검토로 분기한다.
---
### 7. 검토 절차를 Hermes Skill로 운영화했다
기준서가 있어도 매번 긴 프롬프트를 다시 만들면 검토자의 기억에 의존하게 된다. 그래서 검토 절차를 `ai-pmo-os-artifact-quality-review` Skill로 만들었다.
Skill의 실행 흐름은 다음과 같다.
```text
프로젝트 기준 확인
→ 실제 파일 인벤토리·해시
→ 산출물 유형·위험등급
→ 8개 하드 게이트
→ 적용 가능한 57개 Check
→ 결함 등급 분류
→ Action·완료조건·재시험
→ 인수·Baseline·배포 권고
```
결과 형식도 고정했다.
1. 한줄 판정
2. 하드 게이트 상태
3. 확인한 원본·버전·해시·공식상태
4. 검증된 주장과 미검증 주장
5. Critical·Major·Minor·Observation
6. 추가 필요한 Evidence
7. 담당·기한·완료조건·재시험
8. Baseline·인수·배포 권고
Skill은 판정을 대신 승인하지 않는다. 동일한 검토 순서와 결과 형식을 반복해주는 역할을 맡는다.
---
### 8. 인터넷 없이 실행되는 Control Center를 만들었다
검토 결과가 여러 문서와 CSV에 흩어져 있으면 현재 상태를 파악하기 어렵다. 이를 하나의 로컬 Control Center로 연결했다.
대시보드에는 다음 내용을 배치했다.
- 현재 검토 상태
- 열린 Action과 우선순위
- 8개 하드 게이트
- 품질영역과 체크 현황
- 결함·재시험 상태
- 기능 카탈로그
- 검토 산출물
- Baseline 승격 조건
기능 카탈로그에는 각 기능의 작동 방식을 다음 형식으로 표시했다.
```text
기능 목적
→ 입력
→ 처리
→ 출력
→ 구현 상태
```
Control Center는 외부 CDN·폰트·API 없이 로컬 HTML·CSS·JavaScript로 구성했다. 인터넷이 끊겨도 화면과 필터를 사용할 수 있고, 내부 문서 내용이 외부로 전송되지 않는다.
공개용 사례글에는 실제 운영 화면을 삽입하지 않았다. 화면 이미지가 필요할 때는 내부 자료가 전혀 없는 별도 Mock 데이터로 다시 제작해야 한다.
---
### 9. 오프라인을 ‘네트워크 차단’이 아닌 운영통제로 정의했다
오프라인 구동은 단순히 인터넷 연결을 끊는 것으로 끝나지 않는다. 외부 연결이 없어도 판단과 승인 과정을 재현할 수 있어야 한다.
그래서 오프라인 AI-PMO-OS의 최소조건을 다음처럼 정리했다.
- 포터블 또는 단일 설치본
- 로컬 DB와 문서 인덱스
- 파일 해시와 변경 이력
- 사용자·역할별 접근통제
- 승인·반려·롤백 로그
- 자동 잠금과 감사로그
- 암호화 백업과 복구시험
- 모델·프롬프트·데이터셋 버전 관리
- 승인된 매체를 통한 반입·반출
- 악성파일 검사와 파기 기록
- 외부 연계가 없을 때 사용할 Mock·Queue·재처리 절차
- 외부 API·CDN·텔레메트리 차단
이 구조에서 AI는 공식 상태를 임의로 바꾸지 않는다. AI는 후보와 문제를 제안하고, 사람은 승인·반려·재시험을 통해 상태를 변경한다.
## ✅ 결과 (After)
### Before vs After
| 항목 | Before | After |
|---|---|---|
| AI 역할 | 문서 요약과 답변 생성 | Evidence 연결·결함 탐지·조치안 생성 |
| 공식 상태 | AI 결과와 승인 상태가 섞일 위험 | Candidate와 Approved 상태 분리 |
| 문서 관리 | 파일명과 폴더 중심 | ID·버전·해시·승인·보안등급 관리 |
| 품질판정 | 검토자별 질문과 평균점수 | 8 Gate·9개 영역·57개 Check |
| 자료 부족 | 보고서에 누락사항만 기록 | 담당·완료조건·재시험이 있는 Action Register |
| 신규 제출물 | 사후 검토 | 수령 즉시 Intake Gate 적용 |
| 결함 종료 | 수정됐다는 설명에 의존 | 종료 Evidence와 영향범위 재시험 필요 |
| Baseline | 자동 반영 가능성 | 사람 승인 전 자동 승격 차단 |
| 대시보드 | 진행상황 위주 | Gate·Action·Evidence·기능·승격조건 통합 |
| 실행환경 | 외부 서비스 의존 가능 | 로컬·오프라인 우선 구조 |
### 현재 구현된 핵심 기능
1. 제출물 인벤토리와 무결성 검증
2. 문서 권위와 공식상태 분류
3. 항목 간 종단 추적성 검사
4. 하드 게이트 기반 차단 판정
5. 품질 체크리스트 평가
6. 결함·Action·재시험 관리
7. Candidate→Baseline 승격 통제
8. 합격기준·평가셋 승인 Gate
9. 필요한 Evidence 요청과 일정화
10. 신규 제출물 Intake Gate
11. 재사용 가능한 Hermes 품질검토 Skill
12. 로컬 AI-PMO Control Center
## 💬 이 과정에서 배운 AI 활용 팁
### 효과적이었던 것
1. **기능보다 상태 모델을 먼저 만들기**
AI가 무엇을 할지보다 Candidate·Approved·Rejected·Blocked가 어떻게 바뀌는지 먼저 정의했다.
2. **파일 무결성과 내용 품질을 분리하기**
해시가 일치해도 내용·버전·승인이 올바르다는 뜻은 아니다.
3. **점수보다 차단조건을 먼저 정하기**
Critical한 문제를 높은 평균점수로 상쇄하지 않게 했다.
4. **자료 요청에 종료조건을 붙이기**
어떤 Evidence가 들어와야 결함이 닫히는지 미리 정했다.
5. **재시험 범위를 기록하기**
수정된 파일 하나만 보지 않고 영향을 받는 연결 항목까지 다시 확인했다.
6. **대시보드를 승인 시스템처럼 보이게 만들지 않기**
화면의 완료 표시는 검토 Workflow 완료이지 공식 인수 승인이 아니다.
### 이렇게 하면 안 돼요
1. 파일이 있다는 이유로 공식 자료라고 판단하지 않는다.
2. 초안·양식·참고자료를 승인본과 섞지 않는다.
3. AI가 만든 후보를 사람 승인 없이 Baseline으로 올리지 않는다.
4. 외부 가이드의 예시 수치를 프로젝트 합격선으로 복제하지 않는다.
5. 높은 평균점수로 보안·권리·인간통제 결함을 감추지 않는다.
6. 수정됐다는 설명만으로 결함을 종료하지 않는다.
7. 내부 문서를 외부 AI·분석 서비스에 승인 없이 전송하지 않는다.
8. 대시보드의 시각적 완성도를 프로젝트 인수 가능성과 혼동하지 않는다.
## 🌍 다른 업무에 적용한다면?
이 운영체계는 PMO 외에도 다음과 같은 업무에 적용할 수 있다.
- 계약·규정 준수 검토
- 내부감사와 시정조치 관리
- 데이터셋·평가셋 품질관리
- RAG 지식원천 검증
- AI 모델·프롬프트 변경관리
- 보안·개인정보 점검
- 시험 결과와 결함 추적
- 공급사 산출물 인수검사
공통 구조는 같다.
```text
원본과 기준 확보
→ 인벤토리·버전·해시 확인
→ Evidence 연결
→ 하드 게이트
→ 품질검토
→ 결함·Action
→ 수정·영향범위 재시험
→ 사람 승인
→ 공식 상태 변경
```
## 🚀 앞으로의 계획
1. 정적 대시보드를 실제 검토 결과와 연결
2. 로컬 문서 인덱스와 Evidence 검색기 구현
3. 승인·반려·롤백 UI 추가
4. Action과 재시험 결과 자동 연결
5. 문서 버전·해시 변경 감지
6. 모델·프롬프트·데이터셋 Registry 구축
7. 포터블 오프라인 실행 패키지 제작
8. 권한·감사로그·백업·복구시험 강화
9. 대표적인 가상 산출물로 회귀시험 세트 구성
10. 검토시간·수정률·Evidence 누락률·재시험 통과율 측정
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: Evidence 중심 AI-PMO Workflow 설계
> AI-PMO 시스템을 설계해줘. 에이전트 수와 기능 목록보다 원본·버전·해시·Evidence·AI 제안·사람 승인·변경 이력이 연결되는 가장 작은 수직 Workflow를 먼저 정의해. Candidate와 Approved 상태를 분리하고 단계별 완료조건과 금지행동을 작성해줘.
### 프롬프트 2: 산출물 Intake Gate 만들기
> 신규 산출물을 받는 즉시 적용할 Intake Gate를 만들어줘. 문서 ID, 내부 제목, 버전, 작성·검토·승인 상태, 보안등급, 권리, 파일 크기, SHA-256, 매니페스트, 공식상태, 추적성을 검사해. 실패 시 격리·보완·반려·제한적 검토 조건을 정의해줘.
### 프롬프트 3: 품질기준을 하드 게이트와 체크리스트로 변환
> 이 품질기준을 반복 가능한 검토 Workflow로 바꿔줘. 점수보다 먼저 확인할 기준선·권리·보안·인간통제·재현성·합격기준·Critical·운영안전 Gate를 정의하고, 세부 체크에는 Evidence·결함등급·조치·완료조건·재시험 범위를 포함해줘.
### 프롬프트 4: 오프라인 AI 업무환경 설계
> 외부 인터넷과 생성형 AI API를 사용할 수 없는 환경을 위한 로컬 AI 업무체계를 설계해줘. 로컬 문서 인덱스, 해시, 버전, 승인로그, RBAC, 반입·반출, 감사로그, 백업·복구, 모델·프롬프트·데이터 Registry, Mock·Queue·재처리, 외부 통신 차단을 포함해줘.
