빠른 결론

R&D 필드테스트 데이터 수집은 "현장에서 한번 돌려봤다"는 확인이 아니라, 프로토타입을 왜 고쳐야 하는지 설명할 수 있는 원본 기록을 남기는 일입니다. 개선 회의에서 필요한 최소 묶음은 테스트 목적, 현장·환경 조건, 센서와 수기 로그 형식, 동의·개인정보 범위, 이상치 메모, 반복성 기준, 표본 제외 규칙, 사진·영상 증거, 사후 결정 기록입니다. 이 묶음이 끊기면 같은 실패가 설계 문제인지, 현장 조건 문제인지, 측정 장비 문제인지 구분하기 어렵습니다[S1][S2][S4].

프로토타입 개선 직전의 필드테스트는 샌드박스 실증이나 정부 과제 최종보고서가 아닙니다. 실제 장소에서 데이터를 모은다는 점 때문에 "파일을 많이 모으면 증거가 되겠지"라고 생각하기 쉽지만, 내부 개선 회의가 묻는 질문은 다릅니다. 이 조건에서 기능이 어떻게 작동했는가, 같은 조건을 다시 만들 수 있는가, 제외한 표본은 왜 제외했는가, 사진과 영상은 어떤 로그 행을 설명하는가, 그리고 그 기록을 보고 어떤 개선 결정을 내렸는가가 핵심입니다.

이 글은 외부 제도 승인, 규제 샌드박스, 사용자 테스트 사용성 평가, TRL 검증, 데이터 관리계획, AI 데이터 프로젝트, 정부 R&D 최종보고서 증빙을 대신하지 않습니다. 그 주제는 각각 R&D 정부 샌드박스·파일럿 체크리스트, R&D 사용자 테스트 사용성 증거 체크리스트, R&D 프로토타입 TRL 검증 체크리스트, R&D 데이터 관리계획 체크리스트, R&D AI·데이터 프로젝트 체크리스트, 정부 R&D 최종보고서 증빙 패키지 체크리스트에서 다루는 편이 안전합니다. 여기서는 개선 전 현장 데이터 수집 양식만 좁게 봅니다.

R&D 필드테스트 데이터 수집은 테스트 목적을 한 문장으로 잠그는 데서 시작합니다

필드테스트의 첫 번째 기록은 장소가 아니라 목적입니다. "현장 반응 확인"처럼 넓은 문장은 개선 판단에 약합니다. 더 나은 문장은 "외부 온도 5~10도, 습도 70% 이상, 배터리 잔량 40% 이하 조건에서 센서 모듈이 30분 동안 허용 오차 안에 머무는지 확인한다"처럼 조건, 대상 기능, 측정 시간, 허용 기준이 보이는 문장입니다. EPA QAPP guidance는 환경정보 작업에서 계획, 실행, 문서화, 평가가 성능·수용 기준을 만족하도록 QA/QC 요구사항을 명시해야 한다고 설명합니다[S1]. R&D 현장에도 같은 논리가 적용됩니다. 목적이 흐리면 기록은 많아도 개선 결론이 흔들립니다.

테스트 목적은 개선 회의의 질문 형태로 쓰는 것이 좋습니다. 예를 들어 "A형 케이스를 계속 쓸 것인가", "센서 샘플링 주기를 1초에서 5초로 바꿀 것인가", "방수 패킹 위치를 바꿀 것인가"처럼 설계 변경 후보와 연결합니다. 목적이 결정과 연결되면 수집할 데이터도 줄어듭니다. 모든 로그를 저장하기보다 결정에 필요한 필드, 반복 횟수, 환경 조건, 실패 기준만 먼저 고를 수 있습니다.

목적 문장에는 제외할 판단도 같이 적습니다. 이번 필드테스트가 구매 의향을 보려는 것인지, 사용성 과업을 보려는 것인지, TRL 성숙도를 평가하려는 것인지, 장기 데이터셋을 구축하려는 것인지 섞이면 수집표가 금방 커집니다. 이 글의 범위에서는 "프로토타입 개선을 위한 현장 측정과 관찰"만 남깁니다. 시장성, 인증, 규제, 과제 종료 보고는 별도 문서로 넘겨야 합니다.

목적 문장에 반드시 들어갈 5개 필드

  • decision_question: 이번 테스트가 바꿀 설계 결정
  • test_objective: 측정하려는 기능, 성능, 안정성 항목
  • acceptance_rule: 통과, 보류, 재시험, 개선 필요를 나누는 기준
  • field_scope: 장소, 시간, 환경 조건, 사용 장비 범위
  • out_of_scope: 이번 테스트에서 결론 내리지 않을 항목

현장·환경 조건은 결과값보다 먼저 적어야 재시험이 가능합니다

필드테스트 데이터에서 가장 많이 빠지는 항목은 현장 조건입니다. 같은 프로토타입도 실내와 실외, 평지와 진동이 있는 작업대, 안정적인 전원과 임시 배터리, 맑은 날과 강풍 조건에서 전혀 다른 값을 냅니다. USGS National Field Manual은 수질 현장 자료의 신뢰성과 표준화를 위해 문서화된 절차와 프로토콜을 사용한다고 설명합니다[S2]. 이 원칙을 일반 R&D 필드테스트에 옮기면, 결과값만 저장하지 말고 "그 결과값이 발생한 조건"을 먼저 고정해야 합니다.

현장 조건은 사람이 쓴 메모와 장비가 남긴 로그가 서로 맞아야 합니다. 예를 들어 환경 센서가 09:31부터 온도 상승을 기록했는데 현장 메모에는 그 시각에 직사광선 노출이 없었다고 되어 있으면, 둘 중 하나는 검토 대상입니다. 그래서 현장 메모에는 장소명, 좌표 또는 구역 ID, 설치 높이, 방향, 표면 상태, 전원 방식, 네트워크 상태, 주변 간섭원, 날씨, 운반 직후 안정화 시간, 테스트 시작 전 캘리브레이션 여부를 남깁니다.

<table>

<thead>

<tr><th>현장 조건</th><th>권장 기록 필드</th><th>빠지면 생기는 문제</th></tr>

</thead>

<tbody>

<tr><td>장소와 설치</td><td>site_id, zone_id, 좌표, 설치 높이, 방향, 고정 방식</td><td>다음 테스트에서 같은 조건을 재현하기 어렵습니다.</td></tr>

<tr><td>환경</td><td>온도, 습도, 조도, 진동, 소음, 먼지, 바람, 강수, 표면 상태</td><td>프로토타입 문제와 외부 조건 문제를 섞어 해석합니다.</td></tr>

<tr><td>장비 상태</td><td>prototype_version, firmware_version, sensor_id, calibration_id, battery_level</td><td>어느 버전의 결함인지 추적할 수 없습니다.</td></tr>

<tr><td>운영 조건</td><td>operator_id, run_id, start_time, end_time, network_status, power_source</td><td>사람·시간·전원·통신 조건이 결과에 준 영향을 놓칩니다.</td></tr>

<tr><td>통제 조건</td><td>pre_check_result, stabilization_time, excluded_conditions</td><td>반복성 실패가 준비 부족인지 설계 문제인지 모호해집니다.</td></tr>

</tbody>

</table>

이 표는 모든 프로젝트에 그대로 붙이는 양식이 아닙니다. 냉장 물류 장비라면 온도와 문 열림 횟수가 중요하고, 실외 로봇이라면 지면 상태와 장애물 배치가 중요합니다. 중요한 것은 테스트 목적과 직접 연결되는 환경 변수를 "나중에 기억나면 적는 항목"이 아니라 "로그 시작 전 채워야 하는 항목"으로 승격하는 것입니다.

센서·로그 형식은 값, 시간, 단위, 장비 ID, 품질 플래그를 같은 행에 둡니다

현장 데이터가 개선에 쓰이려면 파일 형식이 먼저 합의되어야 합니다. 센서가 CSV를 내보내고, 앱은 JSON을 남기고, 현장 담당자는 메신저 사진을 보내는 식이면 회의 때마다 손으로 맞춰야 합니다. OGC Observations, Measurements, and Samples 표준은 관측 행위와 결과, 샘플링 관련 정보를 여러 과학·기술 커뮤니티에서 교환할 수 있도록 개념 스키마를 정의합니다[S4]. OGC SensorThings API도 Datastream을 같은 관측 속성을 같은 센서가 생산한 Observation 묶음으로 설명하고, 단위·관측 시간·결과 같은 필드를 다룹니다[S5]. 프로토타입 팀이 전체 표준을 구현하지 않더라도, 이 구조는 로그 필드 설계에 유용합니다.

최소 로그 행은 run_id, record_id, phenomenon_time, result_time, prototype_version, sensor_id, observed_property, value, unit, quality_flag, operator_note, evidence_uri를 포함하는 편이 좋습니다. 여기서 phenomenon_time은 현상이 발생한 시각이고, result_time은 시스템이 결과를 기록하거나 계산한 시각입니다. 두 시간이 다르면 지연, 버퍼링, 통신 장애를 볼 수 있습니다. quality_flag는 정상, 결측, 캘리브레이션 의심, 현장 메모 확인 필요, 제외 후보처럼 단순한 코드부터 시작해도 됩니다.

<table>

<thead>

<tr><th>필드</th><th>예시</th><th>개선 회의에서 쓰는 질문</th></tr>

</thead>

<tbody>

<tr><td>run_id</td><td>FT-20260703-A03</td><td>같은 실행 묶음 안의 로그와 사진을 연결할 수 있는가?</td></tr>

<tr><td>observed_property</td><td>surface_temperature</td><td>무엇을 측정했는지 사람이 읽어도 알 수 있는가?</td></tr>

<tr><td>unit</td><td>degC</td><td>단위 변환이나 반올림으로 값이 바뀌지 않았는가?</td></tr>

<tr><td>quality_flag</td><td>suspect_calibration</td><td>값을 그대로 쓸지, 보류할지, 제외할지 판단할 수 있는가?</td></tr>

<tr><td>evidence_uri</td><td>photo://FT-A03-0912.jpg</td><td>해당 값이 나온 순간의 사진·영상·수기 메모가 연결되는가?</td></tr>

</tbody>

</table>

USGS는 전자 현장 노트와 장비 로그를 사용할 때 변경과 수정이 날짜, 담당자와 함께 추적되어야 하고, 센서 같은 교체 가능한 구성요소는 나중에 접근할 수 있도록 추적해야 한다고 안내합니다[S3]. 따라서 필드테스트 로그는 "최종 정리본"만 있으면 부족합니다. 원본 파일, 정제 파일, 제외 파일, 의사결정 표가 각각 어떤 버전에서 만들어졌는지 남겨야 합니다.

동의·개인정보와 사진·영상 증거는 수집 전에 경계를 정합니다

필드테스트가 사람, 차량, 작업장, 고객 장비, 사내 보안 구역을 촬영할 수 있다면 개인정보와 기밀 정보 문제가 생길 수 있습니다. NIST Privacy Framework는 혁신적 제품과 서비스를 만들면서도 개인정보 위험을 식별하고 관리하도록 돕는 도구입니다[S6]. NIST SP 800-122는 PII의 수집·이용·보관을 목적 수행에 필요한 최소 범위로 줄이는 원칙을 설명합니다[S7]. 이 글은 법률 자문이 아니지만, 필드테스트 수집표에는 최소 수집, 접근 권한, 보관 기간, 마스킹 기준이 들어가야 합니다.

사람이 참여하거나 식별될 수 있는 경우에는 동의 절차를 더 좁게 봐야 합니다. HHS OHRP의 informed consent FAQ는 동의가 충분한 고려 기회를 제공하고 강압이나 부당한 영향 가능성을 줄이는 상황에서 이루어져야 한다고 설명합니다[S8]. 일반 기업 R&D의 모든 현장 확인이 인간대상연구 규정 대상이라는 뜻은 아닙니다. 다만 얼굴, 음성, 위치, 작업 습관, 건강·안전 상태처럼 개인과 연결될 수 있는 정보가 포함되면 "나중에 모자이크하면 된다"가 아니라 수집 전에 목적, 범위, 열람자, 보관 기간, 철회·삭제 문의 경로를 안내해야 합니다.

사진과 영상은 강력한 증거지만, 가장 빨리 위험해지는 증거이기도 합니다. 파일명은 run_id, 촬영 시각, 촬영자, 관련 로그 행, 촬영 목적을 포함해야 합니다. 사진 안에 사람이 보이면 식별 가능성, 얼굴·명찰·차량 번호·화면 정보 노출 여부를 체크합니다. 영상은 전체 공유보다 필요한 구간 클립과 마스킹 사본을 분리하는 편이 안전합니다. 원본은 접근 권한을 제한하고, 개선 회의에는 필요한 프레임과 설명만 가져갑니다.

주의할 표현

"동의를 받았으니 모든 자료를 자유롭게 쓸 수 있다"는 문장은 위험합니다. 동의는 목적, 수집 항목, 이용 범위, 보관 기간, 공유 대상에 묶입니다. 개선 회의에서 필요한 것은 개인정보를 많이 보유하는 능력이 아니라, 최소한의 증거로 같은 결론을 설명하는 능력입니다[S7][S8].

이상치 메모와 반복성 점검은 실패를 버리는 절차가 아니라 설명하는 절차입니다

필드테스트에서 이상치는 자주 나옵니다. 갑자기 값이 튀거나, 센서가 멈추거나, 현장 담당자가 장비를 옮기거나, 네트워크가 끊기거나, 예상하지 못한 사용 조건이 생깁니다. 이때 바로 삭제하면 개선 기회를 잃고, 모두 포함하면 평균값이 왜곡됩니다. EPA QA/G-5 guidance는 샘플 위치, 날짜, SOP 이탈, 프로토콜을 위반한 샘플을 대체하는 시정 절차 같은 기록과 데이터 검증·검토 기록을 다룹니다[S1]. 프로토타입 필드테스트에서도 이상치는 "제외할 값"이 아니라 먼저 "설명할 사건"입니다.

이상치 메모에는 anomaly_id, run_id, time_range, affected_records, observed_symptom, suspected_cause, evidence_link, initial_action, include_exclude_candidate, review_owner를 남깁니다. 예를 들어 "09:42~09:47 온도값 급등"만 적으면 부족합니다. "직사광선 노출, 패널 위치 변경 사진 있음, 동일 조건 재현 필요, 1차 분석에서는 제외 후보"처럼 원인 후보와 다음 행동까지 적어야 합니다.

반복성은 같은 값을 완벽히 재현하는 뜻이 아닙니다. 같은 조건을 충분히 비슷하게 만들었을 때 같은 결론에 도달할 수 있는지를 보는 것입니다. 반복성 점검에는 같은 목적, 같은 장비 버전, 같은 설치 조건, 같은 캘리브레이션 절차, 같은 수집 주기, 같은 제외 규칙이 필요합니다. 한 번의 성공으로 개선을 확정하지 말고, 한 번의 실패로 설계를 폐기하지도 말아야 합니다. 반복 실행이 어렵다면 왜 어려운지 기록합니다. 현장 접근 제한, 날씨, 안전 문제, 장비 수급 같은 이유가 남아야 다음 테스트 설계를 바꿀 수 있습니다.

표본 제외 규칙은 테스트가 끝난 뒤 만들지 않습니다

표본 제외는 가장 민감한 결정입니다. 개선하고 싶은 결론에 맞춰 나중에 제외 규칙을 만들면 내부 리뷰에서 신뢰를 잃습니다. 제외 규칙은 테스트 전 초안으로 만들고, 테스트 후에는 그 규칙을 적용했는지와 예외 승인 여부를 남깁니다. 제외 후보는 장비 오류, 캘리브레이션 실패, 설치 조건 불일치, 안전 중단, 로그 결측, 동의 범위 초과, 현장 개입, 사진·영상 증거 누락처럼 구체적이어야 합니다.

좋은 제외 규칙은 값의 좋고 나쁨보다 데이터의 해석 가능성을 기준으로 합니다. 결과가 나쁘다는 이유만으로 제외하면 안 됩니다. 반대로 명백히 잘못된 설치나 미동의 촬영이 포함된 표본을 "현실 데이터"라는 이유로 그대로 쓰는 것도 위험합니다. exclusion_reason_code, affected_record_count, decision_owner, decision_time, retained_for_safety_review, deleted_or_masked_evidence를 남기면 나중에 왜 제외했는지 설명할 수 있습니다.

현장 담당자가 즉석에서 판단해야 하는 경우도 있습니다. 이때는 삭제 대신 표시가 우선입니다. quality_flag=exclude_candidate로 표시하고, 원본 파일은 보존하되 분석본에서는 분리합니다. 개인정보나 기밀 노출처럼 보존 자체가 위험한 자료는 보관 담당자와 삭제·마스킹 결정을 별도로 남깁니다. "제외했다"와 "폐기했다"는 다른 결정입니다.

개선 결정 기록은 로그 행과 설계 변경 후보를 이어야 합니다

필드테스트의 마지막 산출물은 그래프가 아니라 결정 기록입니다. 그래프는 회의에서 보기 쉽지만, 어떤 로그 행과 어떤 현장 증거가 어떤 설계 변경으로 이어졌는지 보여주지 못하면 다음 스프린트에서 같은 논쟁이 반복됩니다. 국가연구개발사업 연구노트 지침은 전자 연구노트에 전자서명 인증, 기록 날짜와 시각 자동기록, 위·변조 확인 기능 같은 요건을 둡니다[S9]. 모든 기업 R&D 노트가 곧바로 이 지침의 적용 대상이라는 뜻은 아니지만, 연구 기록의 추적성과 변경 통제 관점은 필드테스트 결정 기록에도 유용합니다.

사후 결정 표는 단순해야 오래 갑니다. decision_id, decision_question, supporting_run_id, supporting_records, evidence_summary, decision, design_change, owner, due_date, retest_required, remaining_uncertainty만 있어도 충분합니다. 예를 들어 "패킹 위치 변경"이라는 결정에는 어떤 현장 조건에서 누수가 발생했는지, 사진 몇 번이 그 상황을 보여주는지, 제외된 표본은 없는지, 재시험은 어떤 조건에서 할 것인지가 붙어야 합니다.

<table>

<thead>

<tr><th>결정 항목</th><th>기록 예시</th><th>검토 포인트</th></tr>

</thead>

<tbody>

<tr><td>evidence_summary</td><td>FT-A03 18개 기록 중 5개에서 습도 80% 이상 조건 오류</td><td>숫자와 조건이 원본 로그로 돌아가는가?</td></tr>

<tr><td>decision</td><td>케이스 하단 패킹 위치 수정 후 재시험</td><td>관찰을 설계 행동으로 바꿨는가?</td></tr>

<tr><td>retest_required</td><td>예, 동일 장소·동일 습도 범위·v0.8 펌웨어</td><td>반복성 기준이 남아 있는가?</td></tr>

<tr><td>remaining_uncertainty</td><td>저온 조건은 미검증, 장기 진동은 다음 테스트 범위</td><td>결론을 과장하지 않았는가?</td></tr>

</tbody>

</table>

이 결정 기록은 최종보고서 문장이 아닙니다. 내부 개선을 움직이는 작업 문서입니다. 그래서 실패를 숨기면 안 됩니다. 실패가 반복되면 설계 변경 후보가 강해지고, 실패가 특정 환경에서만 나오면 적용 범위를 줄일 수 있습니다. 중요한 것은 회의가 끝난 뒤에도 "왜 이 개선을 하기로 했는지"를 같은 데이터로 다시 읽을 수 있는 상태를 만드는 것입니다.

프로토타입 개선 전 60분 필드테스트 데이터 수집 점검

최종 체크리스트

  • 테스트 목적이 설계 결정 질문과 연결되어 있는가?
  • 현장·환경 조건이 결과값보다 먼저 기록되는가?
  • 센서 로그에 시간, 단위, 장비 ID, 버전, 품질 플래그가 있는가?
  • 수기 메모, 사진, 영상이 같은 run_id와 record_id로 연결되는가?
  • 동의·개인정보·기밀 노출 범위가 수집 전에 정리되었는가?
  • 이상치 메모가 삭제 사유가 아니라 사건 설명으로 남는가?
  • 반복성 기준과 재시험 조건이 테스트 전에 정해졌는가?
  • 표본 제외 규칙이 사후 결론에 맞춰 바뀌지 않는가?
  • 원본, 정제본, 제외본, 결정표의 버전 관계가 남는가?
  • 개선 결정 기록에 남은 불확실성과 다음 테스트 조건이 들어가는가?

이 10개가 채워지면 프로토타입 개선 회의의 문장이 달라집니다. 약한 문장은 "현장 테스트 결과 몇 가지 문제가 있었다"입니다. 강한 문장은 "v0.7 프로토타입을 3개 현장 조건에서 6회 실행했고, 습도 80% 이상 조건에서 센서 지연이 5건 반복되었으며, 2건은 캘리브레이션 오류로 제외 후보 처리, 3건은 사진·로그가 일치해 패킹 위치 변경과 재시험 대상으로 결정했다"입니다. 후자는 성공을 과장하지 않고, 실패를 버리지 않고, 다음 개선을 실행할 수 있게 만듭니다.

마지막으로 한 가지를 분명히 해야 합니다. 필드테스트 데이터 수집 체크리스트는 데이터를 많이 모으는 도구가 아닙니다. 적게 모아도 판단 가능한 데이터를 남기기 위한 도구입니다. 프로토타입 개선 전에는 "더 측정할 것인가"보다 "이 기록으로 같은 결정을 다시 설명할 수 있는가"를 먼저 물어야 합니다.

R&D 필드테스트 데이터 수집 체크리스트 참고 출처