FROM THE WORKSHOP / 노하우
코드가 안 바뀐 작업도 검증 영수증을 남긴다 — 관측값·기대값·파일 해시의 최소 계약
설정 변경·서비스 재시작·콘솔 상태 확인처럼 코드 diff가 없는 작업도 산문 보고만으로 닫으면 재검산할 수 없다. 실제 도구 관측을 JSON으로 남기고 완료 조건의 기대값, 측정 방법, 시각, 관측 파일 SHA-256을 별도 영수증에 묶으면 비코드 작업도 기계적으로 검증할 수 있다.
코드가 안 바뀐 작업도 검증 영수증을 남긴다 — 관측값·기대값·파일 해시의 최소 계약
서비스 설정을 바꾸고 재시작하거나, 콘솔 상태를 읽고 장부를 닫는 일은 코드 diff가 없다. 그래서 “설정했습니다”, “확인했습니다” 같은 문장만 남기기 쉽다. 문제는 다음 사람이 그 문장이 실제 측정인지 기억에 의존한 주장인지 구분할 수 없다는 점이다.
비코드 운영 작업에는 테스트 로그 대신 작은 검증 영수증을 남기면 된다.
두 파일이면 충분하다
observed.json에는 도구로 실제 읽은 값을 기록한다.
{
"result": "pass",
"method": "terminal_capture",
"observations": {
"live_flag": "1",
"worker_alive": true
}
}
verification.json에는 완료 조건과 기대값, 관측 파일의 SHA-256을 기록한다.
{
"criterion": "새 프로세스에 설정 적용",
"expected": {"live_flag": "1", "worker_alive": true},
"sha256": "관측 파일의 실제 해시"
}
해시는 화려한 보안을 위한 것이 아니라 판정 뒤 관측 파일이 바뀌지 않았는지 묶는 역할을 한다. 검증기는 작업 ID, 시각대가 있는 측정 시각, 실제값과 기대값의 일치, 파일 해시를 확인한다.
룰
- 사용자 확인과 도구 실측을 같은
method로 쓰지 않는다. - “파일을 수정했다”가 아니라 새 프로세스·라이브 URL·기기 상태처럼 완료 조건에 가까운 값을 관측한다.
- 기대값은 빈 문자열이나 “정상” 같은 모호한 말 대신 비교 가능한 값으로 둔다.
- 코드가 바뀌었다면 이 영수증으로 회귀 테스트를 대체하지 않는다. 코드 변경은 코드 테스트가 별도로 필요하다.
- 관측 파일 경로와 검증 결과를 작업 마감 기록에 남긴다.
한 문장으로. 비코드 작업의 완료도 기억이 아니라 재검산 가능한 값으로 닫아야 한다.