01 · 필요한 이유

‘정확도 82%’를 고칠 수 있는 오류 묶음으로 바꾼다

공지 요약 서비스가 평가 문항 100개 중 82개를 통과했다고 합시다. 18개 실패가 날짜 누락 9개, 신청 조건 누락 5개, 출처 불일치 3개, 문체 1개라면 가장 큰 묶음부터 원인을 찾을 수 있습니다. 전체 점수만 보면 날짜 추출 규칙을 고쳐야 할지, 검색 범위를 바꿔야 할지, 프롬프트 예시를 보강해야 할지 알기 어렵습니다. 순환도는 점수와 실패 사례를 오류 유형으로 묶고 각 유형을 구체적인 수정 후보에 연결합니다.[1]

오류 수만으로 우선순위를 정하면 드물지만 피해가 큰 실패를 뒤로 미룰 수 있습니다. 각 묶음에는 발생 횟수, 영향도, 발견 가능성, 영향을 받는 이용자를 함께 기록합니다. 날짜 한 글자 누락과 잘못된 신청 자격 안내는 모두 한 건이지만 결과는 다릅니다. 평가·수정 순환도는 무엇을 고칠지뿐 아니라 왜 그 작업이 먼저인지도 남겨야 다음 회차의 결정 근거가 됩니다.

생각그림 1 · 18개 실패를 수정 단위로 나누기
날짜 누락
9
조건 누락
5
출처 불일치
3
문체
1
실패 수와 영향도를 함께 보고 날짜 누락 묶음을 첫 수정 대상으로 고릅니다.
02 · 기호 읽기

단계, 산출물, 판정 문턱, 되돌아갈 위치를 구별한다

순환도의 사각형은 수행 단계, 화살표는 다음 단계로 전달되는 산출물, 마름모나 문턱 상자는 계속·종료 판단을 뜻합니다. ‘평가→수정’처럼 행동만 연결하면 어떤 근거가 움직이는지 보이지 않습니다. ‘실패 사례+오류 라벨→수정안’처럼 화살표에 산출물을 적습니다. 기준 통과 화살표는 배포 후보로, 기준 미달 화살표는 오류 분류로 돌아갑니다. 최대 반복 횟수나 사람 검토 조건도 종료 문턱에 함께 씁니다.

한 바퀴를 읽을 때는 입력과 산출물이 맞물리는지 확인합니다. 평가 단계는 문항별 판정표를 내고, 오류 분류는 그 표를 원인 후보별 묶음으로 바꾸며, 수정 단계는 변경 내역과 예상 효과를 남깁니다. 다시 실행할 때는 같은 평가판과 설정을 사용해야 전후 차이를 비교할 수 있습니다. 화살표마다 전달물을 적으면 빈 상자만 순환하는 그림을 실제 운영 기록으로 바꿀 수 있습니다.

생각그림 2 · 다섯 단계와 두 종료 길
평가
점수+실패 사례
오류 분류
유형+영향
수정
변경 기록
재평가
새 결과
종료 판단
통과 / 보류
통과하면 배포 후보, 기준 미달이면 오류 분류로 돌아가며 최대 반복 뒤에는 사람 검토로 이동합니다.
03 · 평가 자료

수정에 쓴 사례와 최종 확인 사례를 분리한다

실패 사례를 보며 프롬프트와 규칙을 계속 고치면 그 사례에는 잘 맞지만 새 입력에서는 약해질 수 있습니다. 수정용 집합은 오류를 관찰하고 개선하는 데 쓰고, 보류 집합은 수정 과정에서 열어보지 않은 채 마지막 확인에 사용합니다. 운영에서 새로 발견한 사례도 바로 통과 점수에 섞기보다 출처와 수집 시점을 남기고 다음 평가판에 편입합니다. 평가 기준, 사례 집합, 실행 설정을 버전으로 묶어야 전후 비교가 가능합니다.

예를 들어 수정용 60개, 보류 20개, 운영 감시 20개처럼 역할을 나눌 수 있습니다. 숫자 비율은 자료 규모와 위험에 따라 달라지지만 역할은 섞지 않습니다. 보류 사례를 보고 수정했다면 더 이상 보류 집합이 아니므로 새 사례를 마련하거나 판정을 보수적으로 해석합니다. 평가판 버전에는 문항 원문, 기대 답, 채점 규칙, 수집 날짜와 중복 제거 기준을 함께 넣습니다.

생각그림 3 · 수정용·보류용·운영 사례의 역할
자료쓰는 시점목적
수정용 70개매 반복오류 발견·수정 방향
보류용 30개종료 후보에서새 사례 일반화 확인
운영 신고수집·검토 뒤다음 평가판 확장
같은 사례를 끝없이 보며 맞추는 일을 막고, 새 입력에서의 성능을 따로 확인합니다.
04 · 세 수정 사례

오류 유형마다 바꿀 층위와 재검사 범위가 다르다

날짜 누락이 문서 표 안에서 반복되면 표 추출과 문맥 구성 단계를 살핍니다. 출처 불일치는 검색 결과와 답변 주장 연결 규칙을 고칩니다. 존댓말 흔들림은 출력 형식과 문체 예시를 조정할 수 있습니다. 한 오류를 고친 뒤 관련 사례만 다시 돌리면 빠르지만, 다른 능력이 나빠졌는지 알 수 없습니다. 관련 묶음의 집중 검사와 전체 회귀 검사를 차례로 실행합니다. 변경한 층위, 기대 효과, 위험, 되돌리기 기준을 수정 카드에 적습니다.

검색 단계의 오류를 프롬프트 문장 하나로 가리는 수정은 비슷한 질문에서 다시 실패할 수 있습니다. 먼저 실패가 자료 없음, 검색 실패, 문맥 잘림, 지시 해석, 출력 형식 가운데 어디에서 생겼는지 좁힙니다. 같은 사례라도 원인 후보가 여러 개면 한 번에 여러 층위를 바꾸지 않습니다. 변경 하나와 결과 하나를 연결해야 효과를 설명하고 필요할 때 이전 버전으로 되돌릴 수 있습니다.

생각그림 4 · 오류에서 수정 카드로
오류수정 위치집중 검사회귀 검사
표 속 날짜 누락문서 추출표 20개전체 100개
출처 불일치주장–근거 연결인용 15개전체 100개
문체 흔들림출력 지침대화 12개안전·정확성 묶음
수정 대상과 재검사 범위를 한 줄로 연결해 효과와 부작용을 함께 봅니다.
05 · 종료 조건

통과 점수와 치명 오류, 반복 한도를 함께 정한다

평균 점수 90점만 종료 조건으로 두면 개인정보 노출 한 건이 평균에 묻힐 수 있습니다. 종료 문턱은 전체 통과율, 치명 오류 0건, 주요 하위 집단의 최소 점수, 기존 버전 대비 퇴행 한도처럼 여러 조건을 함께 둡니다. 또한 같은 수정이 세 번 이어져도 개선 폭이 작다면 사람 검토로 넘깁니다. 통과는 ‘더 손볼 곳이 전혀 없음’이 아니라 이 버전을 제한된 범위에 배포해도 되는 근거가 갖춰졌다는 운영 판단입니다.

문턱은 배포 범위와 짝을 이룹니다. 내부 시범은 사람 검토를 전제로 낮은 자동화 범위를 허용할 수 있고, 대외 공지는 치명 오류 기준과 출처 확인을 더 엄격히 둘 수 있습니다. 같은 94%도 어떤 문항이 실패했는지에 따라 판정이 달라집니다. 기준을 결과를 본 뒤 바꾸면 비교가 흔들리므로 평가 전에 정하고, 바꾼다면 이유와 적용 시작 버전을 기록합니다.

생각그림 5 · 네 가지 종료 문턱
1보류 집합 통과율 92% 이상
2개인정보·위험 안내 치명 오류 0건
3각 문서 유형 통과율 85% 이상
4기존 핵심 기능 퇴행 2%p 이내
평균 한 개 대신 배포 위험을 반영한 여러 문턱을 동시에 확인합니다.
06 · LLM에 요청하기

평가표를 수정 제안으로 바꿀 때 근거와 우선순위를 요구한다

LLM은 실패 사례를 묶고 수정 후보를 정리하는 보조 역할을 할 수 있습니다. 평가 기준, 입력, 기대 결과, 실제 결과, 판정, 오류 심각도를 제공합니다. 유사 오류를 묶되 원인이 같다고 확정하지 말고, 각 수정안이 어떤 사례를 개선하려는지 연결하도록 지시합니다. 수정 뒤 집중 검사와 전체 회귀 검사를 제안하게 하고, 원문에 없는 성공 기준이나 임의의 점수를 만들지 못하게 합니다.

생각그림 6 · 복사 가능한 평가·수정 요청문
다음 평가표를 수정 순환도로 정리해 주세요.
열: 사례 ID / 입력 유형 / 기준 / 기대 결과 / 실제 결과 / 판정 / 심각도.
분류: 비슷한 실패를 묶고 각 묶음의 공통 현상과 다른 점을 적는다.
수정: 각 제안이 겨냥하는 사례 ID, 변경 위치, 기대 효과, 부작용 위험을 연결한다.
재검사: 집중 검사와 전체 회귀 검사를 나누어 제안한다.
종료: 제공된 통과율·치명 오류·퇴행 한도·최대 반복 조건만 사용한다.
금지: 관찰된 현상을 하나의 원인으로 단정하거나 새 점수를 만들어 내지 않는다.
출력: ①오류 묶음 ②우선순위 ③수정 카드 ④재평가 경로 ⑤추가 확인.
준비된 예시 점수와 사례는 순환도 검토를 위한 교육 자료이며 실제 모델 평가 결과가 아닙니다.
오류 사례와 수정안을 ID로 연결하면 그럴듯한 일반론을 실제 검토 항목으로 바꿀 수 있습니다.
07 · 오류와 수정

점수가 오를 때마다 배포로 향하는 순환은 위험하다

수정 전 그림은 ‘평가→점수 상승→배포’만 보여 주기 쉽습니다. 이 구조에는 새 사례 검증, 치명 오류, 퇴행 검사와 중단 기준이 없습니다. 수정한 순환도는 오류를 심각도와 유형으로 나누고, 변경 범위를 기록하며, 집중 검사 뒤 보류 집합과 회귀 검사를 통과해야 종료 문턱으로 갑니다. 개선 폭이 작거나 같은 실패가 반복되면 자동 반복을 멈추고 평가 기준·자료·시스템 설계를 사람이 다시 봅니다.

퇴행은 전체 점수 하나보다 기능별 차이로 찾는 편이 빠릅니다. 날짜 추출 수정 뒤 표 안의 날짜는 좋아졌지만 일반 문장의 날짜가 나빠질 수 있습니다. 이전 버전과 새 버전을 같은 문항에 실행해 통과에서 실패로 바뀐 사례를 따로 모읍니다. 새로 좋아진 사례와 새로 나빠진 사례를 한 표에 놓으면 평균 상승 뒤에 숨은 교환 관계를 확인할 수 있습니다.

생각그림 7 · 점수 상승 순환에서 위험 통제 순환으로
수정 전점수 확인 → 프롬프트 수정
점수 상승 → 즉시 배포
종료·되돌리기 기준 없음
수정 후오류 유형·심각도 분류
보류+회귀 검사 통과
치명 오류 0건·반복 한도 확인
평가 순환의 목적은 숫자를 계속 올리는 데 있지 않고, 정해진 위험 범위 안에서 배포 근거를 만드는 데 있습니다.
08 · 검토 기준

측정·관리·운영 감시가 한 번의 원 안에서 이어져야 한다

평가는 개발 단계의 한 번짜리 시험으로 끝나지 않습니다. 배포 환경과 이용자가 바뀌면 새 실패가 생깁니다. NIST AI RMF는 측정 결과를 관리 행동에 연결하고, 배포 뒤 위험을 지속해서 추적하도록 구성합니다.[1] 순환도에는 누가 결과를 검토하고, 어떤 기준으로 배포·보류·되돌리기를 결정하며, 운영 신고가 다음 평가 자료로 어떻게 들어오는지 표시합니다. 자동 채점 결과와 사람 검토가 다를 때의 우선 규칙도 정합니다.

운영 신고는 그대로 평가 자료가 되는 것이 아니라 재현과 권리 확인을 거쳐 평가 후보가 됩니다. 신고 시각, 입력 유형, 사용한 문서와 모델 버전, 실제 영향, 임시 조치를 남깁니다. 재현되지 않은 사례도 관찰 목록에 두되 통과율 분모에는 섞지 않습니다. 담당자, 판단 시한, 되돌리기 권한을 순환도 밖의 운영표와 연결하면 그림이 책임 체계까지 안내합니다.

생각그림 8 · 개발 평가에서 운영 감시까지
개발 평가
고정 사례·보류 집합
→
배포 판단
통과·제한·보류
다음 평가판
검토된 새 사례
←
운영 감시
오류 신고·분포 변화
운영에서 발견한 사례는 검토와 라벨링을 거쳐 다음 평가판으로 돌아옵니다.
09 · 직접 해 보기

통과율과 치명 오류, 퇴행을 함께 판정하자

평가 결과가 94%여도 치명 오류가 한 건 있으면 보류해야 합니다. 새 버전이 93%이고 치명 오류가 없더라도 핵심 기능이 기존보다 4%p 낮아졌다면 되돌리기나 추가 수정이 필요합니다. 아래에서 통과율, 치명 오류, 퇴행 폭을 골라 배포 후보·수정 계속·즉시 보류의 판정을 확인해 보세요.

실습에서는 먼저 통과율만 바꾸고, 이어서 치명 오류와 퇴행 폭을 한 항목씩 바꿉니다. 어느 입력이 판정을 뒤집었는지 결과 문장과 대조하세요. 반복 횟수 상한에 닿았을 때는 같은 수정을 자동으로 계속하지 않고 사람 검토로 넘깁니다. 숫자는 교육용 기준이며 실제 서비스에서는 이용자 피해와 배포 범위에 맞춰 별도의 문턱을 정해야 합니다.

결과를 기록할 때는 선택한 네 입력과 판정 시각도 함께 남깁니다. 같은 기준을 다음 버전에 다시 적용해야 변화가 수정 효과인지 자료 차이인지 구분할 수 있습니다.

마지막으로 판정에 사용한 기준표의 버전을 결과와 함께 보관하세요. 같은 수치라도 기준표가 달라지면 같은 판정으로 비교할 수 없습니다.

생각그림 9 · 종료 조건 판정 실습
조건을 고른 뒤 판정하세요.
해설: 배포 후보는 통과율 92% 이상, 치명 오류 0건, 퇴행 2%p 이내를 모두 충족해야 합니다. 3회를 넘기면 자동 반복을 멈추고 사람 검토로 이동합니다.
평균 점수 하나보다 여러 문턱과 반복 한도가 안전한 종료를 만듭니다.