AI가 만든 결과를 어떻게 다시 믿을 수 있게 만들까 — 연구 자동화에 ‘검증·승인·복구’의 이력을 붙인 날

📝 한줄 요약

AI가 연구 프로필과 계획서 초안을 만들 수 있어도, 그 결과가 언제 검증됐고 이후에 바뀌지 않았는지, 누가 어떤 범위까지 승인했는지, 문제가 나오면 어디로 되돌아가야 하는지가 남지 않으면 신뢰하기 어렵습니다. 이번에는 Research Navigator에 Proof, 범위가 있는 승인, 작은 복구 경로, Snapshot을 더해 결과를 단순히 “생성된 것”에서 다시 확인할 수 있는 작업물로 바꿨습니다.

바쁘시면 이것만 읽어도 돼요:

• 파일이 있다는 것과, 검증했던 그 파일이 지금도 같은 것은 다릅니다

• 승인도 “승인됨” 한마디가 아니라, 무엇을·어디까지·어떤 입력을 보고 승인했는지 남겨야 합니다

• 문제가 생기면 전부 다시 만들지 않고, 문제를 만든 가장 가까운 단계만 고쳐야 합니다

• rollback은 버튼 하나가 아니라 파일을 덮어쓰는 일이라, 마지막 정상 상태 확인과 사람 확인이 먼저입니다

• 대시보드는 판단에 필요한 상태만 보여 주고, fingerprint·승인 메모·원문은 숨겨야 합니다

🎯 이런 분들께 도움돼요

• AI가 만든 문서·계획서·보고서를 다음에도 다시 믿고 이어서 써야 하는 분

• “수정한 뒤에 뭐가 바뀌었지?”를 자주 되짚는 팀이나 1인 작업자

• 승인·검토가 필요한 자동화에서, 편리함과 통제를 같이 지키고 싶은 분

• AI 결과가 그럴듯해도 근거와 변경 이력을 분리해 보고 싶은 분

😫 문제 상황 (Before)

지난 편에서 Research Navigator는 자료 등록부터 프로필, 아이디어, 설계, 장비, 계획서, 심사, 감사까지를 단계별 스킬과 run.json으로 정리했습니다. AI가 만든 결과를 한 번에 보는 로컬 대시보드도 붙였고요.

그런데 계속 남는 질문이 있었습니다.

지금 워크 플로우에 루프를 통한 결과물 개선 기능도 있나?

계획서에는 내부 심사와 수정 이력이 있었습니다. 약점을 찾고, 지적된 문장만 고치고, 다시 심사하는 제한된 개선 루프입니다. 하지만 실제 작업에서는 그보다 더 기본적인 질문이 먼저였습니다.

• 검증이 끝난 뒤 파일이 바뀌면, 이전 검증은 아직 유효한가?

• “승인했다”는 말은 정확히 무엇을 승인한 것인가?

• 감사에서 문제가 발견되면, 계획서를 고치면 되는가, 아니면 장비·근거 단계로 돌아가야 하는가?

• 마지막으로 정상이라고 확인한 상태로 되돌리고 싶다면, 지금 파일을 덮어써도 되는가?

AI에게 더 많은 수정을 시키기 전에, 수정과 검증을 안전하게 반복할 수 있는 바닥이 필요했습니다.

🛠️ 사용한 도구

• Hermes Desktop — workflow 규칙, 스킬, 상태 파일, 안전 경계 설계

• Hermes Skills + Python 스크립트 — 검증, Proof, finding routing, Snapshot과 rollback 경계

• Node 테스트와 브라우저 — API 응답·민감값 비노출·대시보드 표시 확인

여기서 Proof는 “검증한 파일의 해시와 검증 시점을 남기는 증명서”이고, Snapshot은 “마지막으로 정상이라고 확인한 파일 상태의 목록”이라고 이해하면 됩니다.

🔧 작업 과정

1. Proof Artifact와 Code as Gate — “파일이 있다”와 “검증했던 파일이 그대로다”는 다르다

첫 번째로 만든 것은 단계별 Proof Artifact였습니다. Proof Artifact는 “이 단계가 언제, 어떤 규칙으로, 어떤 파일 상태에서 통과했는가”를 남기는 검증 증명서입니다.

예를 들어 계획서 검증이 통과한 뒤, 누군가 문장을 한 줄 고쳤다고 해봅시다. 파일은 여전히 있고, 화면도 잘 열릴 겁니다. 하지만 예전 검증이 새 문장까지 보증하는 것은 아닙니다.

그래서 검증이 통과할 때마다 해당 단계의 파일 해시와 검증 시점, 검증기 버전을 proof/<stage>.proof.json에 남기게 했습니다. 나중에 파일이 바뀌면 화면은 조용히 “통과”라고 말하지 않고 stale, 즉 “검증 뒤에 달라졌음”으로 표시합니다.

이를 가능하게 하는 원칙이 Code as Gate입니다. “문서가 있어 보인다”거나 “대시보드가 초록색이다”가 통과 판정이 아닙니다. 코드 검증기가 Artifact Contract와 Proof Artifact의 해시를 확인해야 다음 단계로 갈 수 있습니다. 이건 성적표보다 봉인에 가깝습니다. 봉인이 그대로면 그때 확인한 물건일 가능성이 높고, 봉인이 깨졌다면 다시 확인해야 합니다.

2. “승인됨” 한 줄 대신, 승인 범위를 남기다

자동화에서 승인이라는 말은 쉽게 너무 넓어집니다. “이 자료 써도 돼요”라고 했을 때, 어디에 쓰는지·어떤 행동은 하면 안 되는지·입력이 바뀌면 다시 물어봐야 하는지가 빠지기 쉽습니다.

그래서 승인 기록을 다음처럼 묶었습니다.

• 하려는 action과 destination

• 허용한 범위와 명시적으로 금지한 범위

• 검토한 입력 파일 목록

• 그 입력 조합이 바뀌었는지 알아보는 fingerprint

입력 파일이 달라지면 이전 승인은 더 이상 현재 작업의 승인이 아닙니다. 화면은 이를 stale로 보여 주고, 새 범위로 다시 확인받아야 합니다.

여기서 실제로 작은 보안 결함도 발견했습니다. 대시보드의 요약에는 fingerprint를 숨겼지만 API가 원본 approval 객체까지 반환하고 있었습니다. 즉, “화면에 안 보이니 괜찮다”가 아니었습니다. 응답 전체를 검사해 원본 객체를 제거하고, 필요한 개수만 남겼습니다.

보안은 보이는 화면만 점검해서 끝나지 않습니다. 데이터가 나가는 모든 경로를 봐야 합니다.

3. 문제가 나오면, 전체를 다시 만들지 않는다

감사 결과를 읽는 글로만 두면, 다음 행동은 다시 사람이 해석해야 합니다. 그래서 finding을 “문제 설명”이 아니라 “복구 계약”으로 만들었습니다.

예를 들어 장비 접근성이 확인되지 않았다는 문제가 있다면, 계획서 문장을 더 자신 있게 고치는 것은 답이 아닙니다. 장비 또는 ZEUS 근거 단계에서 다시 확인해야 합니다. 반대로 문서 구조나 표현의 문제라면 계획서 단계에서만 고치면 됩니다.

이 차이를 기록하는 것이 audit/findings.json입니다. 각 문제는 severity뿐 아니라 누가 고쳐야 하는지, 어디서부터 아래 단계를 무효화할지, 사람 확인이 필요한지를 갖습니다.

비유하면 병원에서 증상만 가리는 진통제를 쓰는 대신, 문제가 난 부품을 찾아 그 부품과 그 아래 조립분만 다시 점검하는 방식입니다. 전체 시스템을 매번 처음부터 만들지 않습니다.

4. 되돌리기도 작업이다 — Snapshot과 readback

“이전 상태로 되돌리자”는 말은 편하게 들립니다. 하지만 파일 기반 workflow에서는 현재 산출물을 덮어쓰는 행동입니다.

그래서 마지막으로 검증된 상태가 생길 때 Snapshot manifest를 남기고, rollback 전에 현재 파일과 비교하는 readback을 먼저 하게 했습니다. 결과는 단순합니다.

• unchanged: 마지막 정상 상태 뒤로 바뀌지 않음

• changed: 이후에 달라짐

• missing: 현재 파일이 없음

실제 rollback은 자동 실행하지 않습니다. 어떤 run의 어떤 snapshot에서 어떤 stage를 되돌릴지, 사유가 무엇인지 명시하고 --confirm을 줘야 합니다. 덮어쓰기 전 현재 파일은 별도 preimage로 보관합니다.

되돌리기는 “실수했으니 원상복구”가 아니라, 무엇을 바꾸는지 알고 실행하는 복구 절차가 됐습니다.

5. 한 화면에서는 상태만, 민감한 원문은 숨긴다

마지막으로 로컬 대시보드에 검증·승인·복구 상태 패널을 추가했습니다.

• Proof가 현재도 유효한지

• 승인이 현재 입력에도 맞는지

• 발견된 문제가 누구의 책임인지

• 마지막 정상 상태와 지금 파일이 같은지

이 네 가지를 한 화면에서 봅니다. 하지만 fingerprint 원문, 승인 메모, 원문 연구자료는 표시하지 않습니다. 대시보드는 작업을 실행하거나 되돌리는 곳도 아닙니다. 판단을 돕는 read-only 창입니다.

기존 실행은 새 계약이 생기기 전에 만들어졌기 때문에 Proof가 없고 scoped approval도 없습니다. 이 경우 억지로 “정상”처럼 꾸미지 않고 legacy, missing으로 보여 줍니다. 예쁜 상태 표시보다 정직한 상태 표시가 먼저입니다.

✅ 결과 (After)

실제 확인

• API focused test 7/7 통과

• Proof·승인·Snapshot이 변경되면 stale 또는 changed로 바뀌는지 임시 fixture로 확인

• raw fingerprint가 API 전체 응답에 포함되지 않는지 확인

• 실제 legacy run에서 Assurance 패널이 표시되고, 콘솔 오류·텍스트 겹침·잘림이 없는지 브라우저에서 확인

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. AI의 개선 루프보다 먼저, 검증 루프를 설계하기

   • AI가 더 고치게 하기 전에 “언제 다시 검증할지”를 정해야 합니다.

2. 문제를 문장으로 끝내지 말고 다음 행동으로 연결하기

   • “장비 근거 부족”이라는 말만 남기지 말고, 장비 단계로 돌아가야 한다는 owner와 route를 남기면 복구가 빨라집니다.

3. 승인에도 입력 버전을 묶기

   • 같은 목적이라도 입력 자료가 달라졌다면 같은 승인이 아닐 수 있습니다.

4. 되돌리기를 가볍게 자동화하지 않기

   • rollback은 현재 파일을 덮어쓰므로, 마지막 정상 상태 확인과 명시적인 사람 확인이 필요합니다.

이렇게 하면 안 돼요

1. “대시보드에 안 보이니 안전하다”라고 생각하지 않기

   • API 응답 전체와 로그·원본 객체까지 확인해야 합니다.

2. 경고를 없애려고 문장만 세게 쓰지 않기

   • 근거 공백은 계획서 표현이 아니라, 실제 근거를 소유한 단계에서 해결해야 합니다.

3. 기존 run을 보기 좋게 만들려고 소급 수정하지 않기

   • 새 계약이 없던 실행은 legacy로 정직하게 남기는 편이 낫습니다.

🌍 다른 업무에 적용한다면?

• 지원서·제안서 자동화: 검토 후 수정된 파일은 재검토가 필요하다는 표시를 남길 수 있습니다.

• 사내 보고 자동화: 문제를 발견한 부서·원천 데이터·재검토 지점을 구조화해 전체 재작업을 줄일 수 있습니다.

• 민감 문서 workflow: 승인 범위와 입력 변경을 묶어, 같은 승인으로 다른 자료를 처리하는 일을 막을 수 있습니다.

• AI 협업 문서: 초안의 품질 점수뿐 아니라 검증 시점·근거 공백·수정 이력을 함께 남길 수 있습니다.

🚀 앞으로의 계획

이번 작업은 AI가 스스로 계속 고쳐 나가는 완전 자동 개선 엔진을 만든 것은 아닙니다. 그 엔진이 안전하게 돌아갈 수 있는 검증·승인·복구의 바닥을 만든 단계입니다.

다음 작업은 bounded auto-improvement controller입니다. 내부 심사 → 지적된 문장만 수정 → 재심사를 실제로 실행하되, 점수가 오르지 않으면 일찍 멈추고, 근거·실행 가능성 문제가 나오면 문장을 억지로 고치지 않고 가장 가까운 upstream 단계나 Human Gate로 돌려보내는 구조를 만들 예정입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: AI 산출물에 검증 이력 붙이기

이 workflow의 각 단계가 검증된 뒤, 산출물 파일이 바뀌면 이전 검증이 무효가 되도록 만들고 싶어.
단계별 산출물 목록, 검증 시점, 파일 해시, 검증기 버전을 남기는 Proof Artifact 구조를 설계해줘.
기존 실행은 바꾸지 말고 legacy로 읽을 수 있게 해줘.

프롬프트 2: 사람 승인을 범위와 입력에 묶기

단순한 approved: true 대신, 사람이 무엇을 승인했는지 추적 가능한 gate를 설계해줘.
action, destination, 허용·금지 범위, 검토한 입력 파일, 입력이 바뀌었을 때 승인 무효화를 포함해줘.
화면과 API에서 fingerprint 원문이나 승인 메모가 노출되지 않게 해줘.

프롬프트 3: 문제를 가장 작은 책임 단계로 되돌리기

감사에서 나온 문제를 사람이 읽는 문장으로만 남기지 말고, severity·책임 owner·invalidate 시작 단계·사람 확인 필요 여부를 가진 JSON finding으로 만들고 싶어.
문제가 사실·근거 문제인지, 문장·표현 문제인지에 따라 가장 가까운 owner로 보내도록 설계해줘.