개념
평가반이 가장 먼저 확인하는 것
현장평가에서 평가반이 성적서 한 건을 집어 들고 하는 요구는 거의 정해져 있다.
"이 성적서의 이 값이 어디서 나왔는지 보여주십시오."
이 요구에 답하지 못하는 상태가 KOLAS 부적합 등급에서 '중대한 사항' 으로 분류된다 — 필수적인 원시데이터 등 기술기록의 일부를 확인할 수 없고, 미확보 사유조차 제시할 수 없는 경우다. 시험을 잘못한 것이 아니라 잘했다는 것을 증명할 수 없는 상태 가 제재 대상이라는 점이 핵심이다.
모듈 31 레슨 2에서 "성적서가 주장하는 것은 결과가 아니라 재현 가능성"이라고 했다. 이 레슨은 그 재현 가능성을 4년 뒤에도 유지하는 방법이다.
원자료와 가공데이터의 경계
KOLAS-G-011(공인기관의 기술기록 관리에 관한 기본지침)은 이 둘을 명시적으로 정의한다.
| 원시데이터(raw data) | 가공데이터 | |
|---|---|---|
| 정의 | 최초 관찰사항에 대한 기록 | 원시데이터를 입력해 얻은 계산 결과 |
| 형태 | 수기 측정기록지, 측정 시 직접 입력한 전산자료, 자동화된 장비가 수집한 데이터 | 결과값 계산시트, 성적서 |
| 재생성 | 불가능 | 원시데이터가 있으면 다시 만들 수 있다 |
여기에 단서가 하나 붙어 있고, 그 단서가 실무에서 가장 날카롭다.
직접 입력한 전산자료 중, 측정 당시 정황상 컴퓨터에 원활하게 입력할 수 있는 환경이 아니었거나 데이터 파일의 저장 일시가 측정 당시와 다르면 원시데이터로 인정되지 않는다.
즉 측정하고 나서 나중에 엑셀에 옮겨 적은 파일은 원자료가 아니다. 그 파일은 가공데이터이고, 그것만 남아 있으면 원자료가 없는 상태다. 7.5.1이 "최초 관찰·데이터·계산은 그것이 발생한 시점에 기록되고 특정 업무와 식별 가능해야 한다"고 요구하는 것과 같은 이야기다.
소프트웨어 시험에서 원자료는 무엇인가
물리 시험에서는 원자료가 눈에 보인다. 계측기 출력, 기록지, 장비 로그. 소프트웨어 시험에서는 이 구분이 흐려지기 쉬워서 의식적으로 정해 두어야 한다.
| 시험 유형 | 원자료 | 가공데이터 |
|---|---|---|
| 성능·부하 | 부하 도구가 남긴 요청 단위 원본 결과(raw sample), 서버·APM 원본 로그 | 백분위 표, 그래프, 요약 리포트 |
| 기능 | 실행 로그, 응답 본문 캡처, 스크린샷·화면 녹화, 실패 시 스택 트레이스 | 케이스별 합부 표 |
| 보안 | 스캐너 원본 출력, 요청·응답 원본, 패킷 캡처 | 취약점 목록, 심각도 표 |
| 호환성 | 디바이스·브라우저별 실행 산출물과 로그 | 매트릭스 표 |
두 번째 열에서 자주 벌어지는 실수가 하나 있다. 부하 도구의 요약 출력만 저장하는 것 이다. p95 값 하나만 남기면 나중에 "p99는 얼마였습니까", "그 구간에 오류가 섞여 있지 않았습니까"라는 질문에 답할 수 없다. 요약은 가공데이터이고, 원자료는 요청 단위 결과다. 모듈 31 레슨 4에서 다룬 백분위 합산의 함정도 원자료가 남아 있을 때만 사후 검증이 가능하다.
환경 정보도 같은 원칙을 따른다. 모듈 31 레슨 2의 환경 스냅샷 스크립트는 측정 시점에 자동으로 생성되기 때문에 원자료의 자격을 갖는다. 시험이 끝난 뒤 기억으로 채운 환경표는 가공데이터도 못 된다.
기록을 고치는 유일하게 허용되는 방법
7.5.2의 요구는 두 문장이다.
- 기술 기록의 수정은 이전 판 또는 최초 관찰로 추적 가능 해야 한다
- 원본과 수정된 데이터·파일을 모두 보존 하고, 변경 일자·변경된 부분· 변경 담당자를 남긴다
종이 기록이면 방법이 정해져 있다.
허용 잘못된 값에 한 줄을 긋고(읽을 수 있게), 옆에 옳은 값을 쓰고,
날짜와 서명을 남긴다. 필요하면 사유도.
금지 지우개 · 수정테이프 · 덧쓰기 · 찢고 다시 쓰기 · 재출력한 줄을 긋되 읽을 수 있게 남기는 것이 핵심이다. 원래 값이 무엇이었는지 보이지 않으면 추적 가능성이 사라진다.
전자 기록에서 이 요구는 감사 추적(audit trail) 으로 구현된다. 누가· 언제·무엇을 어떻게 바꿨는지가 값과 함께 남아야 한다. 승인된 성적서 파일을 덮어쓰는 방식으로는 이 요구를 충족할 수 없다 — KOLAS-G-011도 승인된 성적서·원시데이터·불확도 추정 보고서 등 기술기록에 수정 방지 절차(암호 설정 등) 를 갖추라고 요구한다.
전산으로 관리할 때 요구되는 통제
7.11(데이터 관리·정보시스템)과 KOLAS-G-011을 합치면 요구가 구체적으로 드러난다. 자체 개발 시스템이든 엑셀 기반이든 적용 대상이다.
| 영역 | 요구 |
|---|---|
| 사용자 식별 | 사용자 ID로 모든 기술직원을 유일하게 식별. ID와 같은 비밀번호 금지, 알려진 개인정보 사용 금지, 6자 이상·2종 이상 조합, 암호화 저장 |
| 번호 부여 | 접수번호는 1년 단위 누락 없는 유일한 일련번호. 접수번호·성적서번호·접수일자·승인일자·발급일자는 시스템이 자동 부여 |
| 승인 통제 | 승인된 성적서는 승인권자의 승인 없이 수정 금지 |
| 파일 관리 | 성적서 발급번호 1개당 파일 1개(여러 형식이면 압축해 1개로). 파일 안에 원시데이터·불확도 보고서를 함께 담을 수 있다 |
| 백업 | 기술기록 파일은 1개월 이내 주기로 백업. 장애 시 백업으로 복구 가능해야 한다 |
| 보안 | 승인권자의 승인 없이 유출되지 않도록 보안 조치. 백업 자료도 같다 |
| 대장 | 접수대장과 성적서발급대장 유지. 접수대장에는 접수번호·접수일자·신청사·시료명·수량·발급일자가 필수. 공인·비공인 성적서를 함께 접수하면 구분 표시 |
| 위변조 방지 | 발송 시 홀로그램·QR코드·공인전자문서·타임스탬프·2D 바코드 등으로 조치 |
| 진위확인 | 고객이 성적서 진위를 확인할 수 있는 체계를 갖추고, 요청 시 지체 없이 제공 |
이 지침은 개정되어 왔다(과거 KOLAS-G-018 번호로 운영된 시기가 있다). 항목 번호와 세부 수치는 최신 고시본으로 반드시 대조할 것.
이 목록을 처음 보면 과하다고 느끼기 쉽지만, 하나하나가 실제 사고에서 나온 조항이다. 접수번호에 누락이 있으면 "발행했다가 없앤 성적서"를 의심하게 되고, 발급일자를 사람이 입력하면 소급 발행이 가능해진다. 자동 부여는 편의 기능이 아니라 통제 장치 다.
보존 기간 — 표준은 숫자를 말하지 않는다
8.4.2는 "계약상 의무와 일관된 기간 동안 기록을 보존한다"고만 정한다. 숫자는 제도가 정한다.
| 근거 | 요구 |
|---|---|
| ISO/IEC 17025 8.4.2 | 계약상 의무와 일관된 기간 |
| KOLAS-R-002 제22조 | 인정받은 분야·범위 내에서 발행한 모든 성적서와 관련 기록을 4년 이상 |
| 현장평가 실무 | 인정 유효기간 내의 접수·발급 대장을 평가반에 제시할 수 있어야 한다 |
4년이라는 숫자가 인정 유효기간 4년과 같은 것은 우연이 아니다. 갱신평가 시점에 지난 인정 주기 전체를 되짚을 수 있게 설계된 기간이다.
실무에서 기간은 이렇게 결정한다.
보존 기간 = max(KOLAS 4년,
계약·의뢰서가 요구하는 기간,
다른 제도가 요구하는 기간, ← 조달·R&D·의료기기 등
분쟁 대응에 필요한 기간)마지막 줄이 종종 가장 길다. 모듈 31 레슨 5에서 본 것처럼 성적서가 조달과 계약 검수에 쓰이면 하자보수 기간까지 증거가 필요할 수 있다. 짧은 쪽을 택할 이유는 없고, 긴 쪽을 택하지 않을 이유는 비용뿐이다.
소프트웨어 시험소에서 실제로 설계하는 방법
요구를 모아 놓으면 설계는 비교적 단순해진다. 실행 한 건을 단위로 묶고, 불변으로 만들고, 자동으로 채우는 것이다.
records/2026/R-2026-0412/ ← 접수번호 = 디렉터리 이름
├── 00-intake/ 의뢰서 · 범위 합의 기록 · 계약 검토 기록 (7.1)
├── 01-item/ 대상 식별: 빌드 해시 · 버전 · 수령 일시 (7.4)
├── 02-env/ 환경 스냅샷 (스크립트 자동 생성) (6.3·7.5)
├── 03-raw/ 원자료: 요청 단위 결과 · 로그 · 캡처 (7.5.1)
├── 04-derived/ 계산시트 · 집계 스크립트와 그 버전 (7.11.6)
├── 05-uncertainty/ 불확도 예산표와 근거 (7.6)
├── 06-report/ 성적서 발행본 (승인 후 불변) (7.8)
├── 07-amendments/ 개정본과 사유 (7.8.8)
└── MANIFEST.sha256 전 파일 해시 목록 + 생성 일시이 구조가 요구를 어떻게 충족하는지가 중요하다.
- 해시 매니페스트 — 사후 변경 여부를 증명한다. 수정 방지 요구의 가장 값싼 구현이다
- 집계 스크립트를 원자료와 함께 보존 — 7.11.6은 계산과 데이터 전송을 적절하고 체계적으로 점검하라고 요구한다. 스크립트가 남아 있으면 원자료에서 성적서 표를 다시 만들어 대조 할 수 있다. 이것이 모듈 31 레슨 6에서 말한 "전사 오류를 구조적으로 없애는" 장치와 같은 것이다
- 객체 스토리지의 버전 관리·객체 잠금 — 승인 후 덮어쓰기를 기술적으로 막는다. 권한으로만 막으면 관리자 한 사람에게 의존한다
- 자동 생성 — 환경·타임스탬프·해시를 사람이 채우지 않으면 "저장 일시가 측정 당시와 다르다"는 문제가 구조적으로 생기지 않는다
현실적인 난관은 두 가지다.
용량. 성능 시험의 요청 단위 원자료는 수 GB가 되기 쉽고, 4년 보존이면 누적이 만만치 않다. 타협 지점은 원자료를 압축해 원본 그대로 보관하고, 분석용 사본만 따로 두는 것 이다. 원자료를 다운샘플링해 저장하는 선택은 피해야 한다 — 요약값만 남기는 것과 같은 문제가 된다.
개인정보. 실사용 데이터를 시험에 쓴 경우, 원자료 안에 개인정보가 그대로 남는다. 4년 보존 의무와 개인정보 최소 보관 원칙이 정면으로 부딪친다. 해법은 보존 기간을 줄이는 것이 아니라 원자료 생성 단계에서 마스킹· 가명처리 를 거치고 그 처리 자체를 기록에 남기는 것이다. 처리 후에도 재현이 가능해야 하므로 시험 설계 단계에서 결정해야 한다.
실무에서 왜 필요한가
기록 관리는 티가 나지 않는 일이라 후순위로 밀린다. 그런데 이 영역이 무너질 때의 파급은 다른 어떤 부적합보다 크다. 성적서 한 건의 계산 오류는 개정본으로 수습되지만(모듈 31 레슨 6), 원자료가 없다는 것은 그 기간에 발행한 성적서 전체에 대해 "증명할 수 없다"는 뜻 이 된다.
제품사에서 시험을 의뢰하는 쪽에도 쓸모가 있다. 결과가 의심스러울 때 요구할 수 있는 것이 원자료이고, 의뢰 계약에 원자료 제공 범위 를 미리 적어 두면 분쟁 시 선택지가 늘어난다. 반대로 시험기관 입장에서는 어디까지 제공할지를 미리 정해 둬야 한다.
사내 QA 맥락으로 옮기면 이것은 테스트 증거 관리 그 자체다. 릴리스 판정 회의에서 "이 지표 어디서 나온 숫자입니까"라는 질문에 답하지 못하는 조직은 놀랄 만큼 많다. CI 아티팩트 보존 기간이 30일이라 한 달 전 릴리스의 근거가 이미 사라진 경우도 흔하다. 규제 산업(의료기기 CSV, 금융 감사)에서는 이 공백이 그대로 감사 지적이 된다.
채용시장에서의 위치
이 영역은 품질책임자·데이터 무결성 담당 직무의 핵심이다. 시험인증기관 공고의 "기술기록 관리", "성적서 발급 시스템 운영" 항목이 여기다. 의료기기· 제약 쪽으로 가면 같은 능력이 CSV(컴퓨터 시스템 밸리데이션) 와 FDA 21 CFR Part 11 대응으로 이름을 바꿔 나타난다 — 감사 추적, 전자서명, 접근 통제는 사실상 동일한 요구다.
소프트웨어 엔지니어링 배경이 있으면 이 자리에서 강점이 크다. 해시 매니페스트, 객체 잠금, 자동 스냅샷 같은 구현은 품질 담당자가 혼자 설계하기 어려운 반면, 개발 경험이 있으면 며칠 안에 만든다. 제도를 아는 개발자 가 희소한 자리다.
면접에서 힘 있는 답변의 형태는 이렇다. "성능 시험 원자료가 요약값만 남아 있어서, 6개월 전 성적서의 p99를 재산출할 수 없었습니다. 실행 단위 디렉터리와 해시 매니페스트를 도입하고 집계를 스크립트로 옮겨, 원자료에서 성적서 표를 다시 생성해 대조하는 절차를 만들었습니다. 다음 사후관리에서 원자료 추적 항목 지적이 없었습니다."