P7-3.2 CNN, 순차 모델, attention 계열 비교¶

Section ID: P7-3.2 Version: v2026.07.22

기본 이미지 분류기 하나를 학습했는데 test 정확도가 0.75로 끝났다고 해서, 그 사실만으로 다음 선택이 정해지지는 않습니다. 여기서 중요한 것은 어떤 실패가 어떤 구조 계열을 더 의심하게 만드는가를 프로젝트 문서에 남기는 일입니다.

이미지 프로젝트에서는 같은 정확도라도 어떤 샘플에서 틀렸는지에 따라 다음 개선 방향이 완전히 달라집니다. 약한 결함의 위치를 놓치는 실패라면 공간 구조를 더 읽는 계열을 먼저 떠올려야 하고, 긴 순서 관계가 핵심인 데이터라면 순차 모델을, 멀리 떨어진 요소 관계가 핵심이라면 attention 계열을 먼저 떠올리는 편이 더 맞습니다.

목적은 오류 사례를 틀렸다로 끝내지 않고, 왜 이 실패가 CNN, 순차 모델, attention 계열 가운데 어느 쪽 질문으로 이어지는가를 좁혀 가는 데 있습니다.

오류 사례에서 구조 질문으로¶

같은 실패를 왜 구조 계열 비교 질문으로 다시 읽어야 하는가?
CNN, 순차 모델, attention 계열은 어떤 실패 신호 앞에서 우선순위가 달라지는가?
오류 사례를 데이터 문제와 구조 선택 질문으로 어떻게 나누어 남길 수 있는가?

핵심은 한 오류 사례를 다음 반복의 구조 선택 질문으로 바꾸는 데 있습니다. 틀린 샘플을 데이터, 입력 표현, 구조 계열 질문으로 나눠 보면 왜 어떤 경우에는 CNN이 먼저 떠오르고, 어떤 경우에는 다른 계열을 더 의심해야 하는지 정리할 수 있습니다.

Part 7의 error analysis는 이 절처럼 샘플 단위로 흔들린 이유를 남기는 방식으로 읽으면 됩니다. 점수보다 어떤 샘플이 왜 흔들렸는가를 남기는 프로젝트 회고 기준을 여기서 고정합니다.

Part 7에서 회고(retrospective), 검토(review), 평가(evaluation)의 역할이 다시 섞이면 이 절과 개념사전을 함께 다시 보는 편이 좋습니다.

판단 기준¶

틀린 예측 하나를 가지고도 구조 선택 질문을 적을 수 있습니다.
점수와 사례를 함께 읽어야 하는 이유를 설명할 수 있습니다.
개선 방향을 데이터, 입력 표현, 구조 계열로 나누어 정리할 수 있습니다.

같은 실패를 세 구조 계열로 다시 읽기¶

이번 이미지 분류 실습에서 test 셋의 세 번째 샘플은 약한 스크래치가 있는 표면 패치였습니다. 반올림해 보면 다음과 같습니다.

0.57 0.59 0.59 0.61 0.50 0.51 0.63 0.63
0.60 0.60 0.60 0.62 0.52 0.54 0.64 0.64
0.61 0.61 0.63 0.65 0.46 0.46 0.65 0.67
0.64 0.64 0.66 0.65 0.46 0.47 0.68 0.70
0.65 0.67 0.67 0.67 0.48 0.49 0.71 0.71
0.66 0.68 0.70 0.70 0.51 0.52 0.72 0.74
0.69 0.70 0.70 0.73 0.63 0.63 0.73 0.75
0.72 0.71 0.73 0.74 0.65 0.66 0.76 0.76

이 샘플은 정상 표면에 가까운 밝기 분포를 유지하지만, 가운데 오른쪽 열에 약한 세로 스크래치가 섞여 있습니다. 즉, 명확한 결함은 아니지만 그대로 정상으로 넘기기에도 위험한 중간 상태입니다.

모델 출력도 그 애매함을 그대로 드러냈습니다.

test_probs =
[[0.994 0.006]
 [0.003 0.997]
 [0.730 0.270]
 [0.973 0.027]]

세 번째 샘플에서 모델은 실제 라벨이 스크래치 경고인데도 정상 표면 쪽으로 기울었습니다. 즉, 이 사례의 핵심은 완전히 모르는 샘플이 아니라 약한 결함을 정상 조명 변화와 구분하지 못하는 샘플이라는 점입니다.

이 오류 샘플을 따로 기록해야 하는 이유를 판단 기준으로 고정하면 다음과 같습니다.

질문	짧은 답
왜 이 샘플을 따로 보아야 하는가?	점수보다 더 많은 검토 단서를 주기 때문
무엇을 다시 확인해야 하는가?	결함 강도, 학습 데이터 범위, 공간 구조 정보
그래서 문서에 무엇을 남기는가?	확인된 사실, 구조 계열 가설, 다음 개선 계획

같은 실패를 구조 계열 질문으로 바꾸면 비교는 다음처럼 읽힙니다.

구조 계열	먼저 떠올릴 장점	이번 실패에서 의심할 포인트
CNN	가까운 위치 패턴과 공간 구조를 잘 읽는다	약한 스크래치 위치를 지금보다 더 분명히 잡을 수 있는가
순차 모델	순서에 따라 누적되는 변화에 강하다	이 사례는 2차원 위치 문제라 우선순위가 높지 않다
attention 계열	멀리 떨어진 요소 관계를 함께 본다	현재 패치보다 더 큰 문맥이나 여러 위치 관계가 중요할 때 검토할 만한가

예를 들어 이 샘플을 보고 빠르게는 정확도가 낮으니 더 큰 모델을 붙이자고 적고 싶어질 수 있습니다. 하지만 더 안전한 다음 판단은 그렇게 곧바로 모델 크기로 뛰지 않는 것입니다. 먼저 약한 스크래치 위치를 놓친 문제인가, 학습 데이터에 비슷한 강도가 있었는가, 현재 표현이 공간 구조를 너무 잃었는가를 순서대로 적어야 합니다. 그렇게 적고 나면 이 사례에서는 순차 모델보다 CNN이 먼저 열리고, attention 계열은 더 큰 문맥이 실제로 필요한지 확인한 뒤에야 뒤따른다는 점이 분명해집니다.

왜 이 실패가 구조 선택 질문으로 이어지는가¶

여기서 바로 한 가지를 구분해야 합니다. 현재 예제는 제한된 synthetic 점검 패치로 만든 한 번의 실행 기록이므로, 아래 내용은 확정된 원인이 아니라 다음 검토를 위한 가설 정리입니다.

원인을 세 층위(level)로 나눠 기록하는 것이 좋습니다. 그다음에야 어떤 구조 계열을 먼저 검토할지 말할 수 있습니다.

층위(level)	이 사례에서의 질문	구조 계열 질문
데이터(data)	학습 데이터에 약한 스크래치 예시가 충분했는가?	데이터를 더 넣고도 같은 실패가 남는가
입력 표현(representation)	8x8 grayscale 배열을 펼친 입력만으로도 미약한 결함 위치를 충분히 살릴 수 있는가?	공간 구조를 유지하는 표현으로 바꿔야 하는가
구조(model family)	현재 분류기가 약한 결함과 그림자 변화를 구분하기에 너무 단순하지 않은가?	CNN을 먼저 볼지, 더 넓은 문맥 모델을 볼지

이렇게 나누면 모델이 멍청하다 같은 막연한 결론 대신, 다음 수정 지점을 더 정확히 적을 수 있습니다. 특히 표본이 제한된 실습에서는 한 샘플의 오분류를 곧바로 원인 확정으로 읽지 말고, 검토 우선순위를 올리는 변화 신호로 남겨 두는 편이 안전합니다.

여기에 한 가지를 더 붙이면 오류 사례 분석 절이 Part 7 전체의 공통 검토 구조와 더 직접 연결됩니다. 오류 사례는 단순히 틀린 이미지 1장이 아니라, 확인된 사실, 추가 검토가 필요한 사례, 다음에 보강할 데이터 또는 모델 질문을 한 묶음으로 남겨야 합니다.

같이 남길 기록	왜 필요한가
오류 샘플 ID	다음 반복에서 같은 사례를 다시 찾기 위해서입니다.
검토 이유	확률이 애매했는지, 데이터 범위가 부족했는지 분리하기 위해서입니다.
다음 보강 항목	데이터 추가, 표현 변경, 모델 확장 중 어디를 먼저 볼지 정하기 위해서입니다.
공통 회고 문장	다른 프로젝트와 같은 형식으로 결과를 남기기 위해서입니다.

flowchart TD
  A["약한 스크래치 오분류 발견"]
  B["빠른 판단: 더 큰 모델부터 붙인다"]
  C["데이터 강도 범위와 유사 사례 존재 여부 확인"]
  D["공간 구조 손실 여부 확인"]
  E["CNN 질문이 먼저 열림"]
  F["더 큰 문맥이 필요한지 본 뒤 attention 검토"]

  A --> B
  A --> C
  C --> D
  D --> E
  E --> F

구조 계열 비교 흐름¶

flowchart TD
  A["오류 또는 애매한 샘플"]
  B["실패가 위치 패턴 문제인지 확인"]
  C["학습 데이터 범위 확인"]
  D["공간 구조 보존 필요 여부 확인"]
  E["CNN / 순차 / attention 우선순위 기록"]

  A --> B --> C --> D --> E

이 도식은 오류 사례 분석이 단순히 틀린 샘플 표시로 끝나지 않는다는 점을 보여 줍니다. 잘못된 예측을 본 뒤 원본 패턴, 학습 데이터 범위, 공간 구조 필요성을 차례로 점검해야 다음 구조 계열 질문이 프로젝트 문서 안에서 구체적으로 남습니다.

프로젝트 기록으로 남기면 순서는 다음과 같습니다.

단계	문서에 남길 것
오류 샘플	원본 형태
패턴 확인	왜 애매한가
데이터 범위	학습에 비슷한 사례가 있었는가
구조 계열 질문	CNN / 순차 / attention 중 무엇이 더 직접적인가
다음 계획	데이터/표현/구조 중 어디를 바꿀지

이 사례를 해석해 보면¶

1. 데이터 관점¶

학습 데이터에는 명확한 정상 표면과 명확한 스크래치 경고가 중심이었습니다. 하지만 약한 강도의 스크래치나 그림자와 겹친 결함 사례는 충분하지 않았습니다. 따라서 평가 셋의 세 번째 샘플은 모델 입장에서 낯선 입력입니다.

2. 입력 표현 관점¶

이미지를 64개 숫자로 평평하게(flatten) 펼치면 위치 구조가 많이 단순화됩니다. 사람이 보기에는 가운데 오른쪽 열의 밝기 저하 같은 공간 정보가 중요하지만, 단순 선형 분류기는 이를 충분히 섬세하게 다루지 못할 수 있습니다.

3. 구조 계열 관점¶

이번 모델은 매우 기본적인 softmax 분류기입니다. 깊은 층(deep layer)이나 합성곱(convolution)을 전혀 쓰지 않았기 때문에, 약한 결함과 조명 그림자를 더 세밀하게 구분하기 어렵습니다. 이 사례에서는 순서 누적보다 위치 패턴이 먼저 중요하므로 순차 모델보다 CNN 쪽 질문이 더 직접적이고, 현재 8x8 패치에서는 attention 계열을 바로 붙이기보다 공간 구조 보존이 먼저 읽힙니다.

Python 예제¶

예제는 P7-3.1의 애매한 샘플 하나를 실제 프로젝트 회고 기록으로 바꾸는 것입니다. 예제에서는 오류 사례 요약과 다음 조치 목록을 코드 안에 직접 쓰지 않고 CSV 파일로 분리해, 본문 코드가 오류 기록 읽기 -> 학습 데이터와 대조 -> 회고 생성 흐름에만 집중하도록 맞춥니다.

문제 상황: 평가-결함-약함이 왜 틀렸는지 기록한다.
입력: 평가 샘플별 예측 결과, 학습 데이터 패턴 목록, 다음 조치 목록
기대 출력: 오류 사례 기록, 원인 가설, 다음 조치 목록
확인할 개념:
오류 사례는 샘플 ID 기준으로 다시 추적할 수 있어야 한다
원인을 데이터 / 표현 / 모델 층위로 나누어 적을 수 있어야 한다
다음 반복을 위한 조치가 함께 남아야 한다

입력 파일¶

p7-3-surface-patches.csv
역할: 학습 데이터에 어떤 패턴이 실제로 있었는지 다시 대조하기 위한 기준 파일
p7-3-error-review.csv
역할: 평가 샘플별 예측 결과와 오류 검토 필요 여부를 읽는 파일
p7-3-followup-actions.csv
역할: 회고 뒤에 바로 붙일 다음 조치 후보를 읽는 파일

한 파일만 읽고 끝나지 않습니다. 무슨 일이 있었는가는 평가 기록에서 읽고, 학습에 무엇이 있었는가는 패치 파일에서 대조하고, 다음에 무엇을 할 것인가는 조치 파일에서 읽어 회고 문장으로 다시 묶습니다.

실행 기록 기준¶

이 오류 사례 기록의 중심은 새 모델 구현이 아니라, 약한 결함 오분류 하나를 구조 계열 비교 질문으로 바꾸는 데 있습니다. 세 입력 파일은 각각 평가 기록, 학습 데이터 범위, 다음 조치 후보를 맡고, 결과 해석에서는 오류 사례 기록과 다음 조치 목록이 서로 맞물리는지 봅니다.

기록은 다음 기준으로 나눕니다.

p7-3-error-review.csv에서 검토 대상 샘플 ID와 확률 차이를 확인합니다.
p7-3-surface-patches.csv에서 같은 패턴이 학습 데이터에 있었는지 대조합니다.
p7-3-followup-actions.csv에서 다음 조치가 데이터, 입력 표현, 모델 구조 중 어느 축에 속하는지 나눕니다.
출력된 회고 기록을 보고, 이번 실패가 왜 순차 모델보다 CNN 질문을 먼저 여는지 한 문장으로 씁니다.

# 표면 패치 오류 검토 기록을 읽어 약한 스크래치 사례의 데이터, 표현, 모델 가설과 다음 조치를 정리하는 예제입니다.
import csv
from pathlib import Path

surface_path = Path("docs/assets/part-07/chapter-03/p7-3-surface-patches.csv")
review_path = Path("docs/assets/part-07/chapter-03/p7-3-error-review.csv")
action_path = Path("docs/assets/part-07/chapter-03/p7-3-followup-actions.csv")

surface_rows = list(csv.DictReader(surface_path.open(encoding="utf-8")))
review_rows = list(csv.DictReader(review_path.open(encoding="utf-8")))
action_rows = list(csv.DictReader(action_path.open(encoding="utf-8")))

test_records = [
    {
        "샘플": row["sample"],
        "패턴 이름": row["pattern_name"],
        "실제 라벨": int(row["true_label"]),
        "예측 라벨": int(row["pred_label"]),
        "클래스별 확률": [float(row["class_0_prob"]), float(row["class_1_prob"])],
        "확신 차이": float(row["confidence_margin"]),
        "오류 검토 필요": row["review_needed"],
    }
    for row in review_rows
]

target_sample = "평가-결함-약함"

학습_패턴_이름 = [
    row["pattern_name"] for row in surface_rows if row["split"] == "train"
]

라벨_이름 = {0: "정상 표면", 1: "스크래치 경고"}

오류_사례_기록 = None
for row in test_records:
    if row["샘플"] == target_sample:
        약한_결함_여부 = "예" if row["패턴 이름"] == "약한 스크래치" else "아니오"
        학습_데이터_포함_여부 = (
            "예" if row["패턴 이름"] in 학습_패턴_이름 else "아니오"
        )
        오류_사례_기록 = {
            "오류 샘플": row["샘플"],
            "실제 라벨": 라벨_이름[row["실제 라벨"]],
            "예측 라벨": 라벨_이름[row["예측 라벨"]],
            "클래스별 확률": row["클래스별 확률"],
            "확신 차이": row["확신 차이"],
            "약한 결함 여부": 약한_결함_여부,
            "학습 데이터 포함 여부": 학습_데이터_포함_여부,
            "데이터 가설": "학습 데이터에는 약한 스크래치 강도의 사례가 부족하다",
            "표현 가설": "8x8 입력을 평평하게 펼치면서 미약한 결함 위치 강조가 약해졌다",
            "모델 가설": "선형 경계만으로는 약한 스크래치와 그림자 변화를 충분히 구분하기 어렵다",
        }
        break

대표_다음_조치_목록 = [
    {"다음 조치": row["action"], "이유": row["reason"]} for row in action_rows
][:3]

검토_요약 = {
    "전체 오류 사례 수": sum(row["오류 검토 필요"] == "예" for row in test_records),
    "전체 검토 대상 샘플": [
        row["샘플"] for row in test_records if row["오류 검토 필요"] == "예"
    ],
    "대표 오류 샘플": target_sample,
    "전체 다음 조치 수": len(action_rows),
    "대표 다음 조치 수": len(대표_다음_조치_목록),
}

print("읽은 평가 기록 파일 =", str(review_path))
print("읽은 학습 패치 파일 =", str(surface_path))
print("읽은 다음 조치 파일 =", str(action_path))
print("검토 요약 =", 검토_요약)
print("오류 사례 기록 =", 오류_사례_기록)
print("대표 다음 조치 목록 =")
for row in 대표_다음_조치_목록:
    print(row)

실행 결과 예시는 다음과 같습니다.

읽은 평가 기록 파일 = docs/assets/part-07/chapter-03/p7-3-error-review.csv
읽은 학습 패치 파일 = docs/assets/part-07/chapter-03/p7-3-surface-patches.csv
읽은 다음 조치 파일 = docs/assets/part-07/chapter-03/p7-3-followup-actions.csv
검토 요약 = {'전체 오류 사례 수': 22, '전체 검토 대상 샘플': ['평가-결함-약함', '평가-후보-01', '평가-후보-02', '평가-후보-05', '평가-후보-06', '평가-후보-08', '평가-후보-09', '평가-후보-10', '평가-후보-11', '평가-후보-15', '평가-후보-16', '평가-후보-17', '평가-후보-18', '평가-후보-20', '평가-후보-21', '평가-후보-24', '평가-후보-25', '평가-후보-26', '평가-후보-28', '평가-후보-30', '평가-후보-31', '평가-후보-33'], '대표 오류 샘플': '평가-결함-약함', '전체 다음 조치 수': 36, '대표 다음 조치 수': 3}
오류 사례 기록 = {'오류 샘플': '평가-결함-약함', '실제 라벨': '스크래치 경고', '예측 라벨': '정상 표면', '클래스별 확률': [0.73, 0.27], '확신 차이': 0.459, '약한 결함 여부': '예', '학습 데이터 포함 여부': '아니오', '데이터 가설': '학습 데이터에는 약한 스크래치 강도의 사례가 부족하다', '표현 가설': '8x8 입력을 평평하게 펼치면서 미약한 결함 위치 강조가 약해졌다', '모델 가설': '선형 경계만으로는 약한 스크래치와 그림자 변화를 충분히 구분하기 어렵다'}
대표 다음 조치 목록 =
{'다음 조치': '학습 데이터에 약한 스크래치 강도 사례 추가', '이유': '현재 학습 데이터가 비교적 명확한 결함 중심이기 때문'}
{'다음 조치': '조명 그림자와 결함이 겹친 변형 추가', '이유': '정상 그림자와 결함을 더 분리해 봐야 하기 때문'}
{'다음 조치': '공간 구조를 더 읽는 후속 모델 검토', '이유': '평평하게 펼친 입력보다 공간 구조가 더 중요할 수 있기 때문'}

결과를 어떻게 읽는가¶

이 예제에서 중요한 점은 세 가지입니다.

검토 요약
회고 대상 샘플이 몇 개인지, 어떤 샘플 ID를 다시 볼지 바로 정리합니다. 즉, 긴 오류 분석 문서를 다시 열기 전에 이번 반복에서 무엇부터 다시 봐야 하는가를 한 줄로 잡아 주는 표지 역할을 합니다.
오류 사례 기록
단순히 틀렸다가 아니라, 정답/예측 클래스 이름, 확률, 학습 데이터 포함 여부, 해석 가설까지 한 묶음으로 남깁니다.
다음 조치 목록
개선 계획을 막연한 문장으로 끝내지 않고, 바로 다음 반복에서 실행할 작업 목록으로 바꿉니다.

즉, 오류 분석 문서는 감상문이 아니라 다음 실험을 여는 기록이어야 합니다.

프로젝트 메모 형식으로 줄이면 다음처럼 적을 수 있습니다.

기록 항목	예
사실	`평가-결함-약함`은 오분류되었다
검토 대상 사례	`약한 결함`을 정상으로 넘겼다
다음 조치	`약한 스크래치 사례를 학습 데이터에 추가해 다시 확인한다`
다음 질문	`공간 구조를 더 읽는 합성곱 신경망(CNN)이 먼저 필요한가`

이 표가 있으면 오류 사례 분석 절이 사실 -> 검토 사례 -> 다음 보강 질문 구조로 먼저 읽힙니다.

결과 해석 기준¶

출력을 볼 때는 오류 사례 수보다 오류가 어떤 질문을 여는지 봅니다. 같은 오답이라도 학습 데이터에 비슷한 패턴이 없어서 틀린 경우와, 입력 표현이 공간 구조를 충분히 살리지 못해서 틀린 경우의 다음 조치는 다릅니다.

다음 세 가지를 분리해 관찰합니다.

관찰할 것	기록할 질문
데이터 범위	학습 데이터에 약한 스크래치와 비슷한 패턴이 있었는가?
입력 표현	8x8 배열을 펼치면서 중요한 위치 단서가 약해졌는가?
구조 계열	이번 실패는 CNN, 순차 모델, attention 계열 중 어느 질문을 먼저 여는가?

프로젝트 기록 예시¶

기록은 다음 형식으로 오류 사례를 압축할 수 있습니다.

항목	기록
사실	`평가-결함-약함`은 실제 스크래치 경고였지만 정상 표면으로 예측되었다.
검토 이유	약한 세로 스크래치가 정상 조명 변화와 섞여 보였다.
데이터 가설	학습 데이터에 약한 결함 강도의 예시가 부족했을 수 있다.
표현 가설	펼친 입력이 미약한 위치 변화를 충분히 강조하지 못했을 수 있다.
구조 질문	공간 구조를 더 직접 읽는 CNN 계열을 먼저 검토한다.

회고 문장 예시¶

이 프로젝트의 오류 사례 회고는 다음처럼 정리할 수 있습니다.

평가 셋의 세 번째 이미지에서는 약한 세로 스크래치가 있었지만, 모델은 이를 정상 표면으로 분류했다. 현재 학습 데이터에는 이런 약한 결함 강도의 사례가 충분하지 않았고, 입력을 평평하게 펼친 현재 구조도 미약한 위치 변화를 강조하지 못했을 수 있다. 따라서 이번 결과는 데이터 범위 부족과 공간 구조 보존 부족을 먼저 의심하게 만드는 신호로 읽을 수 있다. 다음 반복에서는 약한 스크래치와 그림자 변형을 더 추가하거나, 순차 모델보다 공간 구조를 더 직접 읽는 합성곱 신경망(CNN) 계열 모델을 먼저 검토한 뒤 같은 샘플을 다시 확인하는 방향이 더 자연스럽다.

이 문단에서 독자가 익혀야 할 형식은 다음 네 가지입니다.

어떤 샘플이 문제였는가
왜 애매했는가
원인을 어느 층위에서 해석하는가
다음에 무엇을 바꿀 것인가

실무에서 왜 중요한가¶

실제 이미지 프로젝트에서도 이 원리는 그대로 남습니다.

의료 영상에서는 경계가 애매한 사례가 중요합니다.
공장 검사에서는 약한 긁힘과 그림자가 겹친 이미지가 중요합니다.
자율주행에서는 가려진 표지판처럼 미약한 신호가 들어온 사례가 중요합니다.

즉, 잘 맞춘 이미지보다 애매하게 틀린 이미지가 프로젝트를 더 많이 가르쳐 줍니다.

이 점 때문에 이미지 프로젝트 문서에서는 성공 사례 모음보다 대표 오류 사례 1~2개를 남기는 편이 더 유익합니다.

다음 개선 계획 예시¶

프로젝트라면 다음 정도의 개선 계획을 적는 것이 적절합니다.

약한 스크래치 이미지를 학습 데이터에 추가한다.
조명 그림자와 결함이 함께 들어간 변형 데이터를 만든다.
단순 선형 분류기 대신 CNN 구조 예시를 후속 실습으로 연결한다.
정확도만이 아니라 약한 결함 오분류 샘플 수를 함께 기록한다.

직접 바꿔 보며 확인할 것¶

오류 사례 하나가 다음 실험을 여는지 보려면 오류 검토 필요와 다음 조치를 직접 바꿔 보는 편이 좋습니다.

p7-3-error-review.csv에서 평가-결함-약함의 확률 차이를 더 작게 바꿔 봅니다. 관찰할 점: 같은 오답이어도 회고 문장이 명확한 오분류보다 애매한 경계 사례 쪽으로 이동하는가?
p7-3-followup-actions.csv에 조명 정규화 전처리 추가 같은 조치를 한 줄 더 넣어 봅니다. 관찰할 점: 다음 조치 목록이 데이터, 표현, 모델 중 어느 축에 더 무게를 두는지 달라지는가?

핵심 확인 기준은 오류 사례를 적었다보다 오류 해석과 다음 조치의 무게중심이 어떻게 바뀌는가입니다.

체크리스트¶

확인할 것	스스로 답할 질문
오류 샘플	틀린 샘플을 ID와 원문 형태로 다시 찾을 수 있는가?
검토 이유	확률이 애매했는지, 라벨이 틀렸는지, 데이터 범위가 부족했는지 구분했는가?
가설 층위	원인을 데이터 / 입력 표현 / 모델 구조로 나누어 적었는가?
구조 질문	CNN, 순차 모델, attention 계열 중 어떤 질문이 먼저 열리는지 설명했는가?
다음 조치	다음 반복에서 추가할 데이터, 바꿀 표현, 검토할 구조를 구체적으로 적었는가?

점수만 남으면 다음 사람이 같은 실패를 다시 찾기 어렵습니다. 오류 샘플, 검토 이유, 가설 층위, 구조 질문, 다음 조치가 함께 있어야 오류 사례가 다음 실험을 여는 기록이 됩니다.

출처와 참고 자료¶

이 절의 오류 사례는 P7-3.1의 자체 표면 점검 패치 데이터를 바탕으로 정리한 프로젝트 회고입니다.