AI가 “다 했습니다”라고 말하기 전에, 영수증부터 받기로 했다-🧭 실행 완료 선언을 Trace·Proof·Verdict·Repair로 바꿔 본 TARDIS 운영 사례

📝 한줄 요약

AI에게 일을 맡길수록 “완료했습니다”라는 말만으로는 부족해진다. GPTERS의 한 사례글을 계기로, TARDIS의 결과물 작업에 시작 전 설계 계약과 실행 영수증을 붙이는 작은 운영 실험을 시작했다.

이번 글은 거대한 자동화 시스템을 완성했다는 이야기가 아니다. 무엇을 실제로 확인했는지, 무엇은 아직 하지 않았는지를 분리해 기록하는 방법을 시험한 사례다.

바쁘시면 이것만 읽어도 됩니다:

• AI의 완료 선언과 실제 완료는 서로 다른 사실이다.

• 단순 질의와 결과물 작업, 외부 효과가 있는 작업을 먼저 나눈다.

• 결과물 작업은 시작 전에 계약을 쓰고, 끝난 뒤 Trace·Proof·Verdict·Repair 영수증을 남긴다.

• 정상 기준본을 먼저 통과시킨 뒤 고장 샘플을 넣어야 검사기가 진짜 작동하는지 알 수 있다.

• 수리할 때 기준을 바꿔 PASS를 만드는 것이 아니라, 같은 기준으로 다시 검사한다.

• 이번 사례에서 전역 하네스를 완성한 것은 아니다. 현재 작업 기준에 반영하고, 실제 확인 기록을 남긴 단계다.

🎯 이런 분들께 도움됩니다

• AI에게 문서·코드·리포트를 맡기지만 결과를 어디까지 믿어야 할지 불안한 분

• 여러 AI 에이전트나 자동화 단계를 연결해 사용하는 분

• “파일을 만들었다”와 “사용할 수 있는 결과물이 검증됐다”를 구분하고 싶은 분

• 외부 발송·배포·삭제처럼 되돌리기 어려운 작업을 AI에게 맡기는 분

• AI 활용 사례를 성과 자랑이 아니라 재사용 가능한 작업 방식으로 공유하고 싶은 분

😫 문제 상황 — “다 됐습니다”만으로는 마지막 칸이 비어 있었다

AI에게 일을 맡기면 답변은 대체로 매끄럽게 돌아온다.

“완료했습니다.”

“파일을 생성했습니다.”

“검증까지 마쳤습니다.”

그런데 이 문장만으로는 다음 질문에 답할 수 없다.

• 실제로 어떤 입력을 사용했나?

• 어떤 파일이나 기능이 만들어졌나?

• 결과물이 현재 경로에 남아 있나?

• 검증은 무엇을 기준으로 했나?

• 정상 케이스도 통과했나?

• 실패한 항목은 무엇이며, 무엇을 고쳤나?

• 외부에 발송하거나 공개한 상태인가?

특히 작업이 여러 단계로 나뉘면 더 위험해진다. 앞 단계의 AI가 성공했다고 말해도, 다음 단계에서 다른 파일이 선택될 수 있다. 파일을 복사하는 과정에서 내용이 바뀔 수도 있다. 브라우저에서 화면이 열려도 버튼이 실제로 작동하지 않을 수 있다.

즉, 작업자의 성공 보고와 최종 결과물의 정확성은 같은 것이 아니다.

이번에 참조한 글의 제목은 이 문제를 아주 간단하게 표현하고 있었다.

AI에게 “다 했습니다” 대신 영수증을 받기로 했다

식당에서 “먹었습니다”라는 말만 듣는 대신 무엇을 얼마에 먹었는지 적힌 영수증을 받는 것처럼, AI에게도 완료 선언 대신 실행 흔적과 판정을 요구하자는 뜻이었다.

🌱 처음에는 무엇을 몰랐나

처음에는 검증을 “마지막에 한 번 확인하는 일”로 생각하기 쉽다.

하지만 실제로는 검증 기준도 작업의 일부다. 기준이 없으면 작업이 끝난 뒤에 무엇을 확인해야 할지 사람마다 달라진다. 결과물이 마음에 들면 PASS, 마음에 들지 않으면 FAIL이라고 말하는 식이 되기 쉽다.

또 하나 놓치기 쉬운 점은 실행 성공, 품질 통과, 승격 가능, 외부 공개 승인이 서로 다른 상태라는 것이다.

예를 들어 다음은 모두 다른 말이다.

• 프로그램이 오류 없이 실행됐다.

• 결과물이 구조 검사를 통과했다.

• 내용 품질 검토를 통과했다.

• 공개할 수 있는 후보가 됐다.

• 실제 공개 또는 발송을 승인받았다.

이것을 하나의 완료로 뭉치면, 실행은 성공했지만 품질은 실패한 결과가 최종적으로 성공처럼 보일 수 있다.

이번 참조를 통해 배운 핵심은 단순했다.

완료 여부를 말하기 전에, 무엇을 완료라고 부를지 먼저 고정해야 한다.

🛠️ 사용한 도구

• GPTERS 원문 글: 실행 영수증 방식의 사례와 문제의식 확인

• Hermes Agent / TARDIS: 원문 확인, 기존 운영 기준 대조, 적용 범위 정리

• 브라우저 직접 확인: 링크 페이지 제목과 본문 read-back

• 기존 artifact integrity 기준: 파일 존재·구조·해시·승격·외부 효과를 분리하는 검증 원칙

• 공동 업무일지·기전체 작업일지: 참조 경위와 적용 범위 기록

📚 도움받은 글

이 사례는 이생강님의 사례글을 직접 읽고 핵심 구조를 확인한 뒤 TARDIS 운영 기준에 대조해 정리했다.

• AI에게 “다 했습니다” 대신 영수증을 받기로 했다

🔧 작업 과정

1. “영수증”이라는 단어를 실제 문제로 연결하기

처음 대화는 아주 짧았다.

영수증

처음에는 일반 영수증 이미지나 가계부 입력을 뜻하는 것인지 알 수 없었다. 링크를 확인한 뒤에야 여기서 말하는 영수증이 물건을 산 뒤 받는 종이가 아니라, AI 작업이 실제로 끝났다는 것을 입증하는 실행 기록이라는 점을 알게 됐다.

그 다음 요청은 다음과 같았다.

이걸 참조해

이때 바로 글을 요약하는 대신, 링크 원문을 직접 열어 제목과 본문을 확인했다. 원문에서 말하는 개념을 기억에 의존해 재구성하지 않고, 실제 페이지의 내용을 read-back한 뒤 현재 TARDIS의 운영 기준과 대조했다.

이 과정에서 배운 점

• 링크를 받았다는 사실과 원문을 읽었다는 사실은 다르다.

• 원문을 읽었다는 사실과 그 원칙을 실제 운영에 적용했다는 사실도 다르다.

• 따라서 참조 작업 자체도 Trace와 Proof를 남길 수 있다.

2. 모든 요청에 같은 절차를 씌우지 않기

참조한 글에서는 요청을 세 등급으로 나눈다.

이 구분이 중요한 이유는 과잉 절차도 실패이기 때문이다.

“이 파일은 어디에 있지?”라는 질문에 매번 설계 계약서를 쓰면 불편하다. 반대로 파일을 삭제하거나 메일을 발송하면서 “완료했습니다” 한 줄로 끝내면 위험하다.

그래서 이번에는 다음처럼 적용 범위를 정했다.

• 짧은 정보 질의는 L로 처리한다.

• 문서 작성·파일 수정·검증 리포트처럼 결과물이 남는 일은 F로 처리한다.

• 발송·삭제·규칙 변경·공개 배포는 M으로 처리한다.

이 과정에서 배운 점

절차를 많이 붙이는 것이 안전한 것이 아니다. 작업의 위험과 결과물 여부에 맞는 절차를 붙이는 것이 안전하다.

3. 시작 전에 설계 계약을 쓰기

F 이상 작업을 시작하기 전에 다음 일곱 칸을 먼저 고정한다.

이전에는 “좋은 결과물을 만들어 달라”는 요청 안에 이 내용이 섞여 있었다. 이제는 시작 전에 분리한다.

예를 들어 이 사례의 계약을 간단히 적으면 다음과 같다.

• Goal: AI의 완료 선언을 실행 증거와 판정이 있는 영수증으로 바꾼다.

• Trigger: 결과물이 남는 작업부터 적용한다.

• Context: GPTERS 원문과 기존 TARDIS artifact integrity 기준을 대조한다.

• Route: 원문 확인 → 등급 분류 → 계약·영수증 구조 정리 → 현재 적용 범위 기록.

• Criteria: 원문 핵심 구조가 실제로 확인되고, 완료·미확인·미적용 범위가 구분된다.

• Approval: 전역 skill이나 다른 프로필 파일을 바꾸는 일은 별도 승인 없이는 하지 않는다.

• Repair: 사실과 다른 표현이 발견되면 문장을 고치되, 확인하지 않은 성과를 추가하지 않는다.

계약의 장점은 일을 시작하기 전에 “무엇을 하지 않을지”까지 적는다는 것이다.

4. 끝난 뒤에는 네 칸 영수증으로 닫기

실행이 끝나면 다음 네 칸을 채운다.

이번 참조 작업의 영수증은 다음과 같이 정리할 수 있다.

Trace

• 사용자가 제공한 GPTERS 링크를 브라우저로 직접 열었다.

• 페이지 제목과 article 본문을 read-back했다.

• 원문의 L/F/M, 7칸 계약, 4칸 영수증 구조를 추출했다.

• TARDIS의 기존 artifact integrity 기준과 대조했다.

• 현재 대화의 후속 결과물 작업에 적용할 범위를 기록했다.

Proof

• 페이지 제목: AI에게 “다 했습니다” 대신 영수증을 받기로 했다

• 본문에서 확인한 핵심 구조: L/F/M, Goal·Trigger·Context·Route·Criteria·Approval·Repair, Trace·Proof·Verdict·Repair

• 정상 기준본 선행 검사, 고장 샘플, 최소 수리, 동일 기준 재평가 원칙 확인

• 현재 적용 범위와 미적용 범위를 공동 기록에 남김

Verdict

• 참조 확인: 완료

• 현재 대화의 결과물 작업 기준 반영: 완료

• 전역 하네스·skill 구현: 아직 하지 않음

• 정량적인 시간 절감 효과: 측정하지 않음

Repair

이번 참조 작업에서는 결함을 고치는 수리가 발생하지 않았다. 따라서 수리했다고 쓰지 않고 없음으로 남긴다.

이렇게 적어두면 “참조했다”와 “시스템에 구현했다”를 혼동하지 않게 된다.

전환점 — 정상 파일부터 넣어야 검사기가 진짜인지 알 수 있다

참조한 글에서 가장 인상 깊었던 부분은 고장 샘플보다 정상 기준본을 먼저 검사했다는 점이었다.

검사기를 만들고 곧바로 고장난 파일을 넣으면, 파일이 탈락하는 것을 보고 “검사가 잘 작동한다”고 생각하기 쉽다. 하지만 정상 파일도 탈락한다면 그 검사는 고장을 찾는 장치가 아니라 모든 것을 시끄럽게 만드는 장치일 뿐이다.

이 원칙을 일반화하면 다음 순서가 된다.

1. 정상 기준본은 통과해야 한다.

2. 의도적으로 부러뜨린 샘플은 잡아야 한다.

3. 잡힌 결함의 가장 작은 원인만 고친다.

4. 같은 기준과 같은 샘플로 다시 검사한다.

5. 검사를 통과시키기 위해 기준이나 샘플을 바꾸지 않는다.

그리고 검사기가 못 막은 자리도 기록한다. 당장 고칠 수 없는 사각이라도 이름을 붙여 남겨야 다음에 같은 구멍을 다시 찾지 않는다.

이 과정에서 배운 점

테스트가 실패했다는 사실만큼, 테스트가 어디에서 침묵했는지도 중요한 증거다.

5. 현재 적용과 전역 구현을 구분하기

이번 작업에서 실제로 한 일은 다음과 같다.

• 외부 참조 글의 원문을 확인했다.

• 핵심 구조를 TARDIS의 기존 품질 기준과 대조했다.

• 현재 대화의 결과물 작업에 계약→실행→영수증 기준을 적용하기로 했다.

• 참조 경위와 적용 범위를 공동 업무일지와 기전체 사건 기록에 남겼다.

반대로 아직 하지 않은 일도 분명하다.

• 모든 대화에 자동으로 L/F/M을 분류하는 전역 하네스 구현

• 모든 결과물에 자동으로 영수증을 생성하는 검사기 구현

• 모든 프로필과 모든 skill에 규칙을 이식하는 작업

• 영수증의 해시와 파일 상태를 자동으로 대조하는 일괄 검증기

• 이 방식을 적용한 뒤의 시간 절감·오류 감소 수치 측정

사례글에서 이 경계를 숨기지 않는 것이 중요했다. 운영 원칙을 이해하고 현재 대화에 적용한 것과, 실제로 시스템 전체에 기능을 구현한 것은 서로 다른 단계이기 때문이다.

✅ 결과 — “완료”를 한 문장이 아니라 검증 가능한 묶음으로 바꾸기

Before vs After

이번 사례에서 실제로 남은 것

• 원문 링크와 핵심 원칙의 확인 기록

• 현재 대화에 적용할 작업 등급 기준

• 설계 계약과 실행 영수증의 재사용 가능한 구조

• 전역 구현과 현재 세션 적용을 구분한 범위 기록

• 다음 결과물 작업에서 사용할 검증 기준

이번 결과는 완성된 제품보다 운영 기준을 측정 가능한 형태로 바꾼 첫 번째 작은 실험에 가깝다.

아직 하지 않은 것

• 자동 영수증 생성기

• 영수증 누락을 자동 차단하는 전역 검사

• 모든 전문 에이전트와 프로필에 대한 적용

• 외부 발송·배포 후 상태를 자동으로 재확인하는 통합 어댑터

• 시간·오류·재작업 감소에 대한 통계

완료하지 않은 일을 완료했다고 쓰지 않는 것 역시 이번 사례의 결과다.

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

효과적이었던 것

1. 작업을 시작하기 전에 등급부터 나누기

   모든 일에 무거운 절차를 붙이지 않고, 결과물과 위험도에 따라 L/F/M을 고른다.

2. 성공 기준에 실패와 애매함까지 넣기

   “무엇을 만족하면 통과인가”만 쓰면 회색지대가 사라진다. 실패·보류·확인 불가를 미리 정의해야 한다.

3. 정상 기준본을 먼저 검사하기

   고장 샘플을 잡는 능력과 정상 샘플을 통과시키는 능력은 별개다.

4. 수리의 크기를 줄이기

   문제가 생겼을 때 전체 규칙을 다시 쓰지 말고, 실패를 소유한 가장 작은 단위를 찾는다.

5. 상태를 한 단어로 합치지 않기

   실행 성공, 품질 통과, 승격 가능, 사람 승인, 외부 상태는 각각 기록한다.

이렇게 하면 안 돼요

1. 외부 글을 읽지 않고 제목이나 요약만으로 원칙을 적용하지 않기

2. 파일이 생성됐다는 말만으로 파일이 현재도 정확하다고 가정하지 않기

3. 고장 샘플만 통과하면 검사기가 잘 작동한다고 판단하지 않기

4. 기준을 완화하거나 테스트 샘플을 바꿔서 PASS를 만들지 않기

5. 아직 구현하지 않은 전역 자동화를 구현 완료처럼 쓰지 않기

6. “확인하지 못함”을 빈칸으로 지워서 독자가 PASS로 오해하게 만들지 않기

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

문서 변환

PDF를 Markdown으로 바꿀 때는 원본 경로, 파일 해시, 변환 도구, 결과 경로, 표·목록·문단 검증 결과를 영수증에 남길 수 있다.

단순히 “변환했습니다”가 아니라 다음을 확인한다.

• 원본과 변환 대상이 같은가?

• 결과 파일이 실제로 열리는가?

• 표와 목록이 보존됐는가?

• 변환되지 않은 페이지가 있는가?

• 사람이 추가 확인해야 할 항목은 무엇인가?

법률 문서 검토

법률 검토에서는 “검토 완료”와 “법적 결론 확정”을 분리해야 한다.

• 어떤 법령·판례를 확인했는가?

• 기준일은 언제인가?

• 확인한 원문과 아직 확인하지 못한 부분은 무엇인가?

• 법률 참모의 분석과 사람의 최종 판단은 어디서 갈리는가?

특히 인용 원문을 확인하지 못한 상태라면 확인 필요 또는 BLOCKED로 남겨야 한다.

미디어 전사·강의 정리

전사 작업은 음성 파일 해시, 전사 엔진, 모델, 구간, 교정 범위, 미전사 구간을 기록할 수 있다. 강의 recap은 슬라이드·발화·교재 보충이 실제로 모두 편입됐는지 별도 확인한다.

웹 배포

웹페이지가 배포됐다는 것과 사용자가 실제로 사용할 수 있다는 것도 다르다.

• 배포 URL이 HTTP 200인가?

• 데스크톱·모바일에서 레이아웃이 유지되는가?

• 버튼·탭·링크가 작동하는가?

• 콘솔 오류와 깨진 이미지가 없는가?

• 공개 승인과 배포 후 read-back이 완료됐는가?

가계부·외부 시스템 입력

거래를 등록했다면 등록 요청이 성공했다는 응답만 보지 않고 실제 거래 목록에서 다시 확인한다. 금액·날짜·차변·대변·적요가 의도와 같은지 비교한 뒤 영수증을 닫는다.

🤝 배워서 남 주기

이 사례를 다른 사람이 바로 가져다 쓸 수 있도록 다음 두 가지를 남긴다.

1. 작업 시작용 설계 계약

2. 작업 종료용 실행 영수증

설계 계약 템플릿

[작업명]

Goal:
무엇을 만들거나 바꾸는가?

Trigger:
언제 시작하는가? 언제는 시작하지 않는가?

Context:
어떤 원본·자료·기준을 사용하는가?

Route:
어떤 순서로 진행하는가?

Criteria:
통과·실패·애매·확인 불가를 어떻게 구분하는가?

Approval:
어디에서 사람의 승인이 필요한가?

Repair:
실패하면 무엇만, 몇 번까지 고칠 것인가?

실행 영수증 템플릿

[작업명] 실행 영수증

Trace:
무엇을 어떤 순서로 실행했는가?

Proof:
실제로 확인한 파일·화면·로그·해시·검사 결과는 무엇인가?

Verdict:
완료 / 질문 / 보류 / 차단 중 무엇인가?
통과·실패·애매·미확인 범위는 무엇인가?

Repair:
실패했다면 무엇을 고쳤는가?
같은 기준과 같은 샘플로 재평가했는가?

Not done:
아직 하지 않은 일은 무엇인가?

독자가 이 템플릿을 자기 업무에 복사해 쓰면 된다. 중요한 것은 형식의 이름보다 완료 선언을 근거와 함께 묶는 습관이다.

🕊️ 홍익인간 관점

이 방식이 줄이는 것은 AI 사용자의 불안만이 아니다.

• 비개발자가 파일 생성과 실제 검증을 구분할 수 있다.

• 여러 사람이 이어받는 작업에서 “어디까지 됐는지”를 다시 묻는 시간을 줄인다.

• 외부 발송·삭제·배포 같은 실수를 한 번 더 막을 수 있다.

• 결과물이 실패했을 때 기준을 바꿔 숨기지 않고, 다음 사람이 같은 실수를 반복하지 않게 한다.

• AI를 잘 쓰는 사람이 더 많은 일을 맡는 것에서 그치지 않고, 다른 사람도 재현할 수 있는 작업 절차를 남길 수 있다.

결국 영수증은 AI를 불신하기 위한 장치가 아니다. AI와 사람이 서로의 작업 상태를 정확히 이어받기 위한 공용 언어에 가깝다.

🚀 앞으로의 계획

1. 실제 문서·웹·데이터 작업에 L/F/M 등급을 적용한다.

2. F 작업의 시작 계약과 종료 영수증을 같은 형식으로 축적한다.

3. 정상 기준본·고장 샘플·최소 수리·동일 기준 재평가를 검증 절차에 넣는다.

4. 영수증의 경로·구조·해시·브라우저 상태를 자동으로 확인하는 검증기를 별도 설계한다.

5. 전역 skill이나 전문 프로필에 편입하기 전, 범위 승인·회귀·read-back을 거친다.

6. 충분한 실제 사례가 쌓인 뒤 시간 절감·재작업·누락 감소를 측정한다.

현재 단계는 “전부 자동화했다”가 아니라, 완료라고 말하기 전에 무엇을 보여줘야 하는지 합의한 단계다.

📋 재사용 가능한 프롬프트

프롬프트 1: 시작 전 설계 계약 만들기

다음 작업을 실행하기 전에 설계 계약을 작성해 주세요.

작업명: [작업명]

먼저 이 요청을 L/F/M 중 하나로 분류하세요.

• L: 답변만 남는 저위험 질의

• F: 결과물이 남는 작업

• M: 외부 발송·삭제·규칙 변경처럼 되돌리기 어렵거나 외부 효과가 있는 작업

F 이상이면 다음 칸을 채워 주세요.

• Goal: 무엇을 만들거나 바꾸는가

• Trigger: 언제 시작하고 언제는 시작하지 않는가

• Context: 어떤 원본·자료·기준을 사용하는가

• Route: 어떤 순서로 실행하는가

• Criteria: 통과·실패·애매·확인 불가의 기준은 무엇인가

• Approval: 어디에서 사람의 승인이 필요한가

• Repair: 실패 시 최소 수리 범위와 재시도 예산은 무엇인가

확인하지 않은 사실이나 측정하지 않은 효과는 성공 기준에 넣지 말고 확인 필요로 표시하세요.

[작업명], [원본 자료], [승인자 또는 승인 지점]을 실제 상황에 맞게 바꿔 사용하세요.

프롬프트 2: 실행 영수증 만들기

다음 실행 결과를 “다 했습니다”라는 문장 대신 영수증으로 정리해 주세요.

Trace

무엇을 어떤 순서로 실행했는지 기록하세요.

Proof

실제로 확인한 파일 경로, 화면 상태, 로그, 테스트 결과, 해시 또는 외부 응답을 기록하세요. 작업자의 자기보고와 독립적으로 확인한 사실을 구분하세요.

Verdict

기준에 따라 완료, 질문, 보류, 차단 중 하나를 고르세요. 통과·실패·애매·확인하지 못한 항목을 각각 표시하세요.

Repair

실패했다면 실패를 소유한 가장 작은 단위를 식별하고, 최소 수리만 기록하세요. 기준이나 테스트 샘플을 바꿔 PASS를 만들지 마세요.

Re-evaluation

수리 후 같은 기준과 같은 샘플로 다시 검사했는지 기록하세요.

Not done

아직 하지 않은 작업과 다음 확인 지점을 분리해 적으세요.

프롬프트 3: 외부 효과가 있는 작업 재확인하기

이 작업은 외부 발송·삭제·배포·규칙 변경을 포함합니다. 실행 전에 다음을 확인해 주세요.

1. 변경 대상과 되돌리기 경로

2. 사람의 사전 승인 지점

3. 실행 전 원본·대상 상태

4. 실행 후 독립 read-back 방법

5. 실패하거나 일부만 반영됐을 때의 중단 기준

6. 최종 영수증에 남길 외부 상태와 검증 근거

승인되지 않은 외부 효과는 실행하지 말고 보류 또는 차단으로 보고하세요.

이 글은 전역 자동화가 완성됐다는 발표가 아니다. AI의 완료 선언을 검증 가능한 작업 기록으로 바꾸기 시작한 운영 실험이며, 확인한 것과 아직 하지 않은 것을 함께 남기는 사례다.