← 노하우 목록

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·기기 상태처럼 완료 조건에 가까운 값을 관측한다.
  • 기대값은 빈 문자열이나 “정상” 같은 모호한 말 대신 비교 가능한 값으로 둔다.
  • 코드가 바뀌었다면 이 영수증으로 회귀 테스트를 대체하지 않는다. 코드 변경은 코드 테스트가 별도로 필요하다.
  • 관측 파일 경로와 검증 결과를 작업 마감 기록에 남긴다.

한 문장으로. 비코드 작업의 완료도 기억이 아니라 재검산 가능한 값으로 닫아야 한다.

기록은 다음 시작이 됩니다.노하우 더 읽기 ↗이 작업장의 제품 ↗
작업장 전체 페이지 목적에 맞는 페이지 찾기