하네스 스터디에서 배운 '리뷰어와 중간 산출물'을 업무 보고서 AI에 적용해 봤다

업무 보고서 AI에 리뷰어와 중간 산출물 적용하기

하네스 스터디에서 배운 '리뷰어와 중간 산출물'을 업무 보고서 AI에 적용해 봤다

📝 한줄 요약
업무 보고서를 다루는 AI에게 규칙을 많이 알려주는 것만으로는 부족했다. 지피터스 22기 스터디에서 배운 하네스, 역할 분리, 리뷰어, 중간 산출물 개념을 참고해 AI가 잘못된 최종본을 내보내거나 미검수 지식을 반영하지 못하도록 운영체계를 다시 만들었다.
바쁘시면 이것만 읽어도 됩니다.
프롬프트를 더 길게 쓰는 대신 규칙을 실행 코드로 옮겼다.
보고서 전달과 지식 환류를 서로 다른 상태로 분리했다.
실제 변경은 기본적으로 막아 두고, dry-run 검증 뒤 승인해야 실행되게 했다.
결과를 만드는 역할과 검증하는 역할을 나눴다.
25개 회귀 테스트와 전체 Wiki 검사로 규칙이 실제로 작동하는지 확인했다.
아직 기존 데이터의 중복 경고가 남아 있다. 이번 글은 완성 자랑보다 안전한 골격을 만든 기록에 가깝다.

🎯 이런 분들께 도움이 됩니다
업무 문서 작성에 AI를 쓰지만 최종본 관리가 불안한 분
프롬프트를 계속 고쳐도 같은 실수가 반복되는 분
개인 AI 에이전트를 실제 업무 프로세스에 연결하려는 비개발자
자동화 속도보다 승인, 근거, 책임 경계를 먼저 잡고 싶은 분
😫 폴더와 규칙은 있었는데, 실행은 다른 문제였다

업무 보고서 AI 시스템의 문제점

저는 텔레그램에서 사용하는 업무 참모형 AI '프라이드'와 보고서 시스템을 운영하고 있다. 승인된 보고서 원문, 템플릿, 의미 추출물, 재사용 지식, 작업 중인 문서, 평가 결과, 최종 산출물을 서로 다른 계층에서 관리한다.
처음에는 폴더와 스킬을 충분히 나누면 시스템이 안전해질 거라고 생각했다. 설계문서에도 규칙은 있었다. 최종본은 무엇인지, 어떤 문서만 Wiki로 올릴 수 있는지, 사용자 승인이 필요한 지점은 어디인지 적어 두었다.
그런데 실행 스크립트를 감사해 보니 문제가 달랐다.
문서에는 최종본 규칙이 있었지만 스크립트가 다른 파일을 고를 여지가 있었다.
보고서 전달 완료와 지식 환류 완료가 하나의 '완료'처럼 섞여 있었다.
미검수 Extract나 제목이 비슷한 지식카드가 들어올 때 사람이 다시 볼 수 있는 차단선이 약했다.
일부 단계에서 실패하면 페이지, 색인, 로그 중 일부만 바뀔 가능성이 있었다.
규칙을 적어 놓았지만, 어겼을 때 실행을 중단시키는 장치가 부족했다.
제가 던진 요청은 짧았다.
우리 시스템 더 보완할 사항은 없어?
보완해줘.
처음에는 스크립트 몇 줄을 고치면 될 줄 알았다. 실제로는 'AI에게 무엇을 시킬까'보다 'AI가 어떤 조건에서 멈춰야 하는가'를 다시 설계하는 일이었다.

하네스 스터디에서 얻은 네 가지 관점

이번 개선은 지피터스 22기 스터디 세 편을 다시 보며 방향을 잡았다. 자동자막은 오인식 가능성이 있어 문장을 직접 인용하기보다, 스터디에서 확인되는 논지를 제 방식으로 정리했다.
1. 에이전트는 답변하는 AI가 아니라 실행하고 검증하는 작업자다
1주차 스터디에서는 에이전트를 파일과 도구를 사용해 계획, 실행, 검증, 보고까지 수행하는 존재로 설명했다. 또 개인 에이전트의 지능은 모델 이름보다 업무 기록, 판단 기준, 절차, 예외 처리가 얼마나 남아 있는지에 좌우된다고 정리했다.
이 대목을 보고 현재 시스템의 약점이 선명해졌다. 설계문서에 규칙을 기록한 것만으로는 에이전트 시스템이라고 하기 어려웠다. 실행 코드가 그 규칙을 읽고, 위반하면 멈추고, 검증 결과를 남겨야 했다.
2. 프롬프트보다 작업별 컨텍스트와 환경이 중요하다
2주차 하네스 스터디에서는 관련 없는 정보가 한 채팅과 전역 지침에 뒤섞이는 '컨텍스트 오염'을 경고했다. 작업 폴더마다 필요한 지침과 자료를 구분하고, AI가 정보를 적재적소에서 사용하도록 환경을 설계하는 것이 하네스라는 설명이었다.
이를 보고 보고서 시스템의 정본을 하나로 고정했다. 인제스트 실행 코드는 작업 데이터와 함께 있는 한 곳만 정본으로 두고, 스킬에 들어 있는 스크립트는 정본을 호출하는 얇은 래퍼로 바꿨다. 같은 이름의 코드가 두 군데에서 다르게 진화하는 일을 막기 위해서다.
3. 큰 작업일수록 역할, 리뷰어, 중간 산출물이 필요하다
2주차 스터디 후반에서 특히 기억에 남은 부분은 세 가지였다.
업무 목적에 따라 에이전트 역할을 나눌 것
리뷰어나 검증 페르소나를 반드시 둘 것
다음 단계에 필요한 중간 산출물을 명확히 정의할 것
이 원칙은 보고서 업무와 잘 맞았다. 보고서를 쓰는 역할이 자신이 쓴 문서를 스스로 '통과'시키게 하면 검증이 느슨해진다. 그래서 작성, 최종본 승격, 보고서 상태 검사, Wiki 검사, 지식 인제스트를 서로 다른 책임으로 분리했다.
4. 에이전트를 만들기 전에 규칙과 워크플로우부터 정한다
5월 28일 스타트업실험실 사례 발표에서는 에이전트 페르소나부터 만드는 것보다, 에이전트가 지켜야 할 규칙과 작업 흐름, 참고할 지식 기반을 먼저 정리해야 한다는 경험담이 나왔다. 큰 구조를 먼저 잡고 한 부분을 실제로 돌려 본 뒤 확장하자는 조언도 반복됐다.
이 관점 덕분에 기존 Wiki 954개를 한꺼번에 새 스키마로 바꾸지 않기로 했다. 신규 카드, 다시 사용하는 카드, 의미가 바뀌는 카드부터 새 규칙을 적용하는 점진적 전환을 택했다.

스터디 원칙을 실제 시스템으로 옮긴 방법

규칙을 문장에서 차단 조건으로 바꿨다
최종 보고서는 정해진 파일명만 자동 선택할 수 있게 했다. 지식 환류 제안서, 초안, 검토 메모, 사실검증 파일은 이름이 최신이어도 최종 산출물로 선택하지 않는다. 최종 확정 뒤 수정한 리비전은 정확한 파일명과 승인 상태가 등록되어야만 승격할 수 있다.
여기서 가장 중요한 변화는 '권장'이 '실행 조건'으로 바뀐 점이다. 규칙에 맞지 않으면 AI가 알아서 넘어가지 않고 오류를 내고 멈춘다.
하나였던 완료 상태를 세 갈래로 나눴다
기존의 모호한 완료 상태를 다음처럼 분리했다.
1. 전체 작성 작업의 진행 상태
2. 최종 보고서 전달 상태
3. 지식 환류 상태
최종 보고서가 확정되어도 지식 환류는 별도 승인 대기일 수 있다. 반대로 지식 환류가 보류됐다고 이미 승인된 보고서 전달까지 막히면 안 된다. 이 둘을 나누니 누가 무엇을 승인했는지 설명하기 쉬워졌다.
리뷰어를 사람 이름이 아니라 검사기로 구현했다
스터디에서 말한 리뷰어를 페르소나 프롬프트로만 두지 않았다.
보고서 검사기는 단계, 승인, 최종본, 출력 파일, 상태가 서로 맞는지 본다.
Wiki 검사기는 출처, 필수 메타데이터, 깨진 링크, 동명 페이지, 제목 충돌을 본다.
독립 코드리뷰는 구현자가 놓친 위험을 별도 관점에서 찾는다.
회귀 테스트는 한 번 해결한 문제가 다시 생기지 않는지 확인한다.
리뷰어가 의견만 내고 실행을 막지 못하면 품질 게이트가 아니다. 검사 결과에 오류가 하나라도 있으면 승격이 중단되게 했다.
자동화의 기본값을 '실행'이 아니라 '미리보기'로 바꿨다
새 도구는 기본적으로 dry-run만 한다. 어떤 파일을 고르고, 무엇을 만들고, 어떤 충돌이 있는지 먼저 보여 준다. 실제 변경에는 별도의 --apply 승인이 필요하다.
파일을 바꿀 때도 실패를 전제로 했다. 임시 파일을 만들고, SHA-256을 비교한 뒤 원자적으로 교체한다. Wiki 인제스트 도중 오류가 발생하면 새 카드뿐 아니라 index와 log까지 이전 상태로 돌린다.
지식 환류에는 의도적으로 긴 경로를 뒀다
보고서 최종본 뒤에는 재사용할 사실, 분석, 판단 후보를 정리한 Knowledge Return 문서를 만든다. 하지만 이 문서는 Wiki의 직접 출처가 아니다.
공식 경로는 다음과 같다.
최종 보고서 확정
→ 지식 환류 후보 작성
→ 사용자 승인
→ 승인된 보고서 원문
→ 검토된 의미 Extract
→ 충돌 검사와 lint
→ Wiki 반영
자동화를 하는 입장에서는 답답할 정도로 길다. 업무 문서의 판단과 사실이 장기 지식으로 남는 과정이라면 이 정도 마찰은 필요하다고 판단했다.

실제 검증에서 나온 결과

구현이 끝난 뒤 임시 샘플과 실제 데이터를 나눠 검사했다.
검증 항목
결과
회귀 테스트
25개 통과, 실패 0개
전체 Wiki 검사
954페이지, 오류 0개
기존 Wiki 경고
동명·표기 충돌 10건
미인제스트 Extract dry-run
5건 검사
생성 가능 후보
85건
충돌 오류
15건
실제 Wiki 적용
0건
원격 readback
로컬과 SHA-256 일치
가장 의미 있었던 결과는 85개 후보를 만든 일이 아니었다. 충돌 15건을 발견하고 아무것도 반영하지 않은 것이 이번 개선의 목적에 더 가깝다.
기존 Wiki의 경고 10건도 자동으로 합치지 않았다. 제목이 같다고 의미까지 같은 것은 아니기 때문이다. 경고는 남기되 병합과 삭제는 사람이 판단하도록 했다.

이번에 배운 것

프롬프트를 고치는 것과 시스템을 고치는 것은 다르다
AI가 실수할 때마다 지시문을 한 줄씩 추가하면 규칙은 길어지지만, 실제 실행 경계는 그대로일 수 있다. 반복되는 실수는 프롬프트보다 상태, 권한, 입력과 출력 계약을 먼저 봐야 했다.
리뷰어는 '검토해 줘'라는 역할명이 아니었다
리뷰어가 무엇을 검사하고, 어떤 상태에서 실패시키며, 어떤 근거를 남기는지 정의해야 했다. 사람처럼 말하는 페르소나보다 오류 코드를 내고 승격을 중단시키는 검사기가 더 유용한 순간이 많았다.
좋은 자동화는 거절할 수 있어야 한다
이번 파일럿에서 인제스트가 아무것도 적용하지 않은 것은 실패가 아니다. 출처, 승인, 제목 충돌이 해결되지 않은 상태에서 멈춘 것은 시스템이 처음으로 규칙대로 행동한 결과였다.
기존 데이터를 한꺼번에 고치는 것이 항상 정답은 아니다
954개 카드를 일괄 변경하면 빠르게 통일된 모양을 만들 수 있다. 대신 과거 의미와 링크를 망가뜨릴 위험도 커진다. 이번에는 신규·재사용·변경 카드부터 적용하는 방식이 더 안전했다.

다른 업무에 적용한다면

보고서가 아니어도 다음 질문으로 업무 자동화를 점검할 수 있다.
1. AI가 읽어야 할 정본은 어디인가?
2. 입력과 최종 산출물은 파일 단위로 구분되어 있는가?
3. 사람이 승인해야 하는 지점은 어디인가?
4. 작성자와 리뷰어의 책임이 분리되어 있는가?
5. 실제 변경 전에 dry-run으로 영향을 볼 수 있는가?
6. 중간에 실패하면 어디까지 되돌릴 수 있는가?
7. 완료를 파일 존재가 아니라 검증 결과로 증명할 수 있는가?
이 질문에 답하지 못하면 자동화 범위를 넓히기보다 작업 구조부터 정리하는 편이 낫다.

다음 단계

이번 작업으로 안전한 골격은 마련했지만 끝난 것은 아니다.
신규 보고서 한 건을 상태 v2로 처음부터 끝까지 실행해 본다.
기존 Wiki 경고 10건은 문맥을 읽고 병합·유지·별도 명칭 중 하나로 판단한다.
기존 카드의 과거 고정 태그와 근거 표현을 읽기 전용으로 감사한다.
실제 운영에서 새 실패가 나오면 테스트와 스킬 규칙에 다시 반영한다.
스터디에서 배운 하네스는 거대한 멀티 에이전트 화면을 만드는 기술이 아니었다. 제 업무에 적용해 보니, AI가 참고할 맥락과 지켜야 할 규칙, 검증받을 산출물, 멈춰야 할 조건을 미리 설계하는 일이었다.
이번에는 AI가 보고서를 더 빨리 쓰게 만든 것이 아니다. 잘못된 보고서와 지식이 조용히 통과하지 못하게 만들었다. 실제 업무에서는 이 차이가 더 중요했다.

재사용 가능한 점검 프롬프트

내가 운영 중인 AI 업무 자동화를 감사해 줘.

현재 정본과 실행 코드가 분리되어 있는지 확인한다.

입력, 중간 산출물, 최종 산출물, 승인 문서를 구분한다.

자동화가 사람의 승인이나 의미 판단을 우회하는 경로를 찾는다.

작성과 검증 책임이 같은 주체에 몰려 있는지 확인한다.

dry-run, lint, checksum, rollback, 회귀 테스트가 필요한 지점을 제안한다.

기존 데이터는 자동 병합·삭제하지 말고 위험과 점진적 전환안을 먼저 제시한다.

문서에만 적힌 규칙과 실행 코드가 실제로 강제하는 규칙의 차이를 표로 정리한다.

결과는 '문제 → 위험 → 최소 안전장치 → 검증 방법' 순서로 작성해 줘.