콘텐츠로 이동

P3-9.4 검토 메모는 어떻게 목표 라벨 후보로 바뀌는가

Section ID: P3-9.4 Version: v2026.09.20

검토 메모를 열로 옮길 때는 먼저 무엇을 옮기는지 정해야 합니다. “후반 하강 반복, 재확인 필요, 센서 문제 의심”에는 관측에 대한 보고, 검토 요청, 원인 추정이 섞여 있습니다. 이를 모두 고장=1로 줄이면 원문이 말하지 않은 결론을 만듭니다. 목표 라벨 후보는 메모에서 구조화할 수 있지만, 구조화가 곧 사실 검증이나 학습 준비 완료는 아닙니다.

원문을 보존하고 문장의 역할 나누기

아래는 자체 구성한 가상 메모입니다. A~D는 이 절의 비교 구간 ID이며 다른 절의 같은 문자와 별개입니다. 메모는 해당 구간에 관한 기록이고, 개별 동작의 라벨로 자동 복사하지 않습니다. R1·R2는 가상 원문 작성자 ID입니다.

note_id window_id reviewer_id 원문 메모
N1 A R1 후반 하강 반복 확인. 재확인 필요. 센서 문제 의심.
N2 B R1 기록만 남김.
N3 C R2 후반이 내려가는 양상이 여러 동작에서 관찰됨. 추가 확인 권장.
N4 D R2 서식 예시: “재확인 필요”. 현재 추가 검토 요청 없음.

N1의 첫 문장은 작성자가 관측했다고 보고한 내용입니다. 센서 원기록을 여기서 독립적으로 검증했다는 뜻은 아닙니다. “센서 문제 의심”은 원인 후보이며 확정 원인이 아닙니다. N4의 인용문은 현재 D에 대한 요청이 아니라 서식 예시입니다.

짧은 주석 기준 note-v1

이 연습은 실제 고장 여부가 아니라 현재 메모가 무엇을 명시하는지 표로 옮깁니다. ?는 미언급·불명확·모순 등으로 값을 정할 수 없음을 뜻합니다. 상충하는 문장이 있으면 하나를 임의 선택하지 않고 원문 확인 대상으로 남깁니다.

후보 열 1 또는 값 부여 기준 0 또는 미확인 처리
reported_repeated_drop 현재 구간에서 여러 동작의 후반 하강을 관측했다고 명시 해당 반복을 관측하지 않았다고 명시하면 0, 언급이 없으면 ?
note_requests_review 현재 대상에 “재확인 필요”, “추가 확인 권장” 등 요청이 있음 현재 추가 요청이 없다고 명시하거나 이 기준의 “기록만 남김”이면 0; 대상·의도가 불명확하면 ?
suspected_cause 현재 대상에 대해 추정한 원인 문구를 보존 언급이 없으면 ?; 확정 원인으로 변환하지 않음

note_requests_review=0은 이 메모에 추가 요청이 없다는 뜻입니다. 실제로 검토할 필요가 없거나 다른 경로의 요청도 없다는 뜻은 아닙니다. 여기서 “기록만 남김”을 0으로 옮기는 것은 명시한 note-v1의 문서 해석 규칙입니다. 원문 자체가 없으면 세 열 모두 미확인으로 둡니다.

같은 의미의 다른 표현, 같은 문구의 다른 맥락

N1의 “후반 하강 반복 확인”과 N3의 “후반이 내려가는 양상이 여러 동작에서 관찰됨”은 이 기준에서 같은 종류의 관측 보고입니다. 또한 N1의 “재확인 필요”와 N3의 “추가 확인 권장”은 모두 현재 대상의 추가 검토 요청입니다. 표현이 달라도 역할과 대상을 확인하면 같은 값으로 옮길 수 있습니다.

반대로 N1과 N4에 똑같이 등장하는 “재확인 필요”는 역할이 다릅니다. N1에서는 실제 요청이고 N4에서는 서식 문구의 인용입니다. 단어가 포함되어 있다는 이유만으로 N4의 요청 값을 1로 만들면 맥락을 잃습니다.

note_id window_id reported_repeated_drop note_requests_review suspected_cause
N1 A 1 1 센서 문제
N2 B ? 0 ?
N3 C 1 1 ?
N4 D ? 0 ?

B의 “기록만 남김”은 반복 하강이 없다는 진술이 아니므로 반복 보고는 ?입니다. N1·N3의 1도 원시 측정값으로 검증된 반복 여부와는 구별해야 합니다. 정량적 하강 규칙을 목표 정의로 삼으려면 메모 문구만이 아니라 해당 구간의 원측정과 동일한 계산 기준을 확인해야 합니다.

열로 옮긴 뒤에도 라벨 근거를 확인하기

구조화 결과의 각 행에는 원문을 찾을 note_id, 대상 window_id, 원문 작성자 reviewer_id, 실제 주석 담당자 annotator_id, 적용 기준 annotation_version을 연결합니다. 예를 들어 N1은 reviewer_id=R1, annotator_id=AN1, annotation_version=note-v1로 남깁니다. 원문 작성자와 열로 옮긴 사람은 같을 필요가 없습니다. 원문·작성 시점·근거 위치를 보존하고 수정본은 원문을 덮어쓰지 않도록 구분합니다.

같은 문구가 열 번 나타나도 같은 서식을 복사한 것일 수 있습니다. 빈도만으로 의미가 일관되거나 실제 사실이 맞다고 볼 수 없습니다. 같은 대상의 메모를 여러 주석 담당자가 독립적으로 읽어 다른 값을 붙였다면 대상 범위·부정 표현·인용 여부와 근거를 대조해 기준을 보완합니다. 판단이 일치해도 고장 사실 자체를 검증한 것은 아닙니다.

목표가 “추가 검토 요청을 분류한다”라면 note_requests_review는 그 판단의 후보가 될 수 있습니다. 목표가 “실제 고장이 있었는가”라면 별도 결과 확인이 필요합니다. 요청 여부·관측 보고·원인 추정 중 어느 것을 배우려는지 먼저 정하고, 라벨 출처와 입력 시점, 평가 범위를 확인해야 합니다.

검토 메모를 공통 라벨 기준으로 정리하기

flowchart TD
    A["원문·대상·작성자 보존"]
    A --> B["관측 보고·요청·추정 분리"]
    B --> C["note-v1 적용, 미확인 유지"]
    C --> D["후보 열 + 원문·주석 담당자"]
    D --> E["목표 의미와 사실 근거 별도 확인"]

이 과정은 메모에서 후보 열을 얻는 한 경로입니다. 모든 라벨이 검토 메모의 반복에서 생겨야 하는 것은 아닙니다. 이미 독립적인 검사 결과가 있다면 그 정의와 근거를 연결해 사용할 수 있습니다.

짧은 메모를 직접 옮기기

새 메모가 “이번 구간의 여러 동작을 확인했으나 후반 하강 반복은 관측하지 못함. 재확인 필요”라고 적혀 있습니다. note-v1의 세 열을 채우고, 이 메모로 실제 고장 여부도 정할 수 있는지 설명해 보세요.

해설: reported_repeated_drop=0, note_requests_review=1, suspected_cause=?입니다. 반복을 관측하지 못했다는 명시적 보고와 추가 요청을 따로 옮깁니다. B처럼 반복 자체를 언급하지 않은 메모의 ?와 구분합니다. 실제 고장 여부는 이 메모만으로 확정하지 않으며, 새 note_id와 원문·작성자·주석 담당자·기준 버전을 남깁니다.

체크리스트

  • 관측 보고·검토 요청·원인 추정을 다른 열로 나누고 미언급을 0으로 채우지 않는가?
  • 같은 뜻의 다른 표현과 같은 문구의 다른 맥락을 구분할 수 있는가?
  • 후보 값에서 원문·작성자·주석 담당자·기준 버전으로 돌아가며, 반복 빈도와 사실 검증을 구분하는가?

출처와 참고 자료

  • W3C, PROV-Overview — 파생 결과의 출처·활동·담당 주체를 연결하는 관점을 참고했습니다. note-v1, 메모와 주석 결과는 본서의 자체 가상 사례이며 검증된 고장 정답 자료가 아닙니다. 확인일: 2026-09-20.