2026.09.03

이미지 콘텐츠 심사 데이터를 보며 판단 기준을 다시 세운 과정

Summary

Summary

AI 이미지 심사 데이터를 살펴보며 표본의 구성, 평가 단위, 정답 데이터, 재현 방법에 대한 판단을 바꾼 과정을 정리했습니다.

표본에서 전체 분포와 묶음 분석을 거쳐 판단이 정리되는 과정을 표현한 커버 이미지
표본에서 전체 분포와 묶음 분석을 거쳐 판단이 정리되는 과정을 표현한 커버 이미지

이 글은 실제 업무에서 로컬 분석과 재현 테스트를 진행하며 판단 기준을 바꾼 과정을 정리했습니다. 심사 과정은 이해에 필요한 범위로 단순화했으며, 회사 내부의 측정 수치와 정책·시스템 구성의 세부 내용, 내부 의사결정은 제외했습니다. 실제로 확인한 문제와 그에 따라 바꾼 분석 방법을 중심으로 서술했습니다. 실제 사례를 단순화한 그림과 개념 설명을 위해 가정한 예시는 각각 구분해 표시했습니다.

저희가 분석한 대상은 사용자가 등록한 이미지를 AI와 운영자가 심사하는 과정이었습니다. 이미지 심사는 콘텐츠가 정해진 기준에 맞는지 확인해 통과시키거나 반려하는 작업입니다. 여기서 반려는 해당 이미지를 사용 대상에서 제외한다는 뜻입니다.

더 간단히 말하자면 AI가 먼저 이미지를 심사하고 통과하거나 판단하지 못한 이미지는 운영자가 다시 확인하는 flow입니다. AI가 반려한 이미지는 운영자를 거치지 않고 제외됩니다. 따라서 자동화를 늘리는 일과 정상 이미지를 보호하는 일을 함께 살펴야 합니다.

작업은 운영자로부터 AI 심사의 품질을 높여달라는 요청을 받으며 시작했습니다. 정상 이미지를 보호하면서 운영자의 반복적인 판단을 줄이는 것이 목표였습니다. 처음에는 모델의 판단을 더 정확하게 만들면 된다고 생각했습니다. 모델에 전달하는 지시문인 프롬프트를 구체적으로 쓰고, 검사 점수를 어디서 나눠 판정할지 정하는 기준값인 임계값을 조정하는 데 집중했습니다.

그러나 실제 데이터를 확인하자 모델보다 측정 방법을 먼저 고쳐야 한다고 판단했습니다. 표본을 넓히자 우선순위가 달라졌고, 같은 판정도 이미지 한 장씩 세는지 묶음으로 보는지에 따라 해석이 달라졌습니다. 이 글에서는 무엇을 발견했고, 그 발견이 다음 분석을 어떻게 바꿨는지 정리하겠습니다.

표본의 크기와 표본이 만들어진 방식

처음에는 짧은 기간의 반려 사례를 모아 문제 유형을 나눴습니다. 전체 데이터 중 분석을 위해 골라 본 일부를 표본이라고 합니다. 처음 열어 본 반려 이미지에는 글자가 깨진 그림이 많았고, 글자 문제를 먼저 자동화해야 한다고 판단했습니다.

하지만 기간을 넓혀 전체 반려 사유를 집계하고 사용자별로 나눠 보자 판단이 달라졌습니다. 특정 사용자가 글자가 깨진 이미지를 한꺼번에 등록한 것이 표본에서 큰 비중을 차지하고 있었습니다. 한 사용자가 한 번에 등록한 이미지들을 여기서는 등록 묶음이라고 부르겠습니다. 전체 집계에서는 글자 오류보다 중복 이미지가 더 자주 나타났습니다.

실제 분석에서 글자 문제가 두드러졌던 짧은 표본과 중복 이미지의 비중이 더 컸던 한 달 전체 집계를 수치 없이 비교한 그림
실제 분석에서 글자 문제가 두드러졌던 짧은 표본과 중복 이미지의 비중이 더 컸던 한 달 전체 집계를 수치 없이 비교한 그림

이 결과를 바탕으로 중복 이미지 검사를 우선 검토했습니다. 새로 등록한 이미지와 기존 이미지를 비교해, 서로 대체할 수 있을 만큼 비슷한 콘텐츠인지 판단하는 검사입니다. 운영자가 반복해서 하던 중복 판단을 얼마나 대신할 수 있는지 평가하려고 했습니다.

같은 등록 묶음의 이미지가 여러 장이라고 해서 서로 다른 상황을 그만큼 확인한 것은 아닙니다. 이처럼 특정 사용자나 유형이 표본에 과도하게 포함되어 전체의 특성을 제대로 반영하지 못하는 것은 표본 편향의 한 형태입니다. 같은 사용자에게서 비슷한 사례를 더 모으는 것만으로는 이런 편향을 해소하기 어렵습니다.

이후에는 기간별 건수, 사유별 비중, 특정 사용자나 등록 묶음에 집중되는 정도를 먼저 집계하고 각 구간에서 이미지를 골라 봤습니다. 사유별 비중도 전체 등록 이미지 중의 비율인지, 반려된 이미지 안에서의 비율인지 구분했습니다. 전체 집계는 문제의 범위를 파악하는 데, 개별 이미지는 그 문제가 어떤 모습으로 나타나는지 이해하는 데 필요했습니다.

전체 일치율에서 세 가지 질문으로

처음에는 모델과 운영자의 전체 일치율로 심사 품질을 평가하려고 했습니다. 판정이 일치한 이미지 수를 전체 비교 이미지 수로 나누면 일치율이 나옵니다. 계산은 간단했지만, 이 값으로 정상 이미지를 보호하는 일과 운영자의 반복 작업을 줄이는 일을 함께 설명하기는 어려웠습니다. 그래서 평가할 내용을 다음 세 가지로 나눴습니다.

  1. 정상 이미지 보호: 정상 이미지를 잘못 반려하는 오반려를 얼마나 줄일 수 있는지 확인합니다.
  2. 운영자 작업량: 검사를 도입했을 때 사람이 확인하거나 처리해야 할 작업이 얼마나 남는지 추정합니다.
  3. 실패 시 처리: AI가 판단하지 못하거나 호출에 실패했을 때도 사람이 확인할 수 있는지 테스트합니다.

확실한 중복만 찾아내는 검사라도 정상 이미지를 잘못 제외하지 않으면서 반복 작업을 줄인다면 도움이 될 수 있습니다. 이후에는 같은 모델과 기준값도 이 세 목적에 따라 나눠 평가했습니다.

평가 단위: 이미지 한 장과 중복 묶음

중복 검사 결과를 이미지별로 대조했을 때는 AI와 운영자의 판정이 다른 사례가 있었습니다. 해당 이미지들을 함께 열어 보니, 같은 묶음에서 서로 다른 이미지를 남긴 경우가 있었습니다. 한 장씩 비교한 결과만으로는 어떤 작업이 처리됐는지 충분히 설명할 수 없었습니다.

중복 판단에서는 구도나 색이 조금 달라도 두 이미지가 서로 같은 용도로 쓰일 수 있는지가 중요했습니다. 이 글에서는 중복으로 의심되어 함께 비교하는 이미지들을 중복 묶음이라고 부르겠습니다.

실제로 확인한 판정 불일치를 이미지 A, B, C로 단순화해 설명하겠습니다. 이 예시에서는 세 이미지 중 대표 이미지 하나를 남기는 것이 목적입니다. 어느 이미지를 남겨도 필요한 품질과 사용 목적을 충족한다고 가정합니다. 운영자는 B를 남기고 A와 C를 반려했습니다. AI는 A를 남기고 B와 C를 반려했습니다.

이미지별로 비교하면 A와 B에서 판정 불일치가 발생합니다. 하지만 필요한 이미지를 하나 남기고 나머지를 제외한다는 목적은 양쪽 모두 충족합니다. 평가할 때는 어떤 이미지를 남겼는지와 함께, 남은 이미지로 필요한 목적을 충족하는지도 확인해야 합니다.

실제 판정 불일치를 A·B·C로 단순화하고, 어느 이미지를 남겨도 같은 목적을 충족한다고 가정해 평가 단위를 비교한 그림
실제 판정 불일치를 A·B·C로 단순화하고, 어느 이미지를 남겨도 같은 목적을 충족한다고 가정해 평가 단위를 비교한 그림

묶음의 기준도 먼저 정해야 합니다. 같은 사용자가 함께 등록했다는 이유만으로 모두 중복인 것은 아닙니다. 서로 다른 쓰임이 있는 이미지를 제외했다면, 한 장이 남았더라도 필요한 콘텐츠를 잃은 것입니다. 모델이 두 이미지를 중복 후보로 지목했을 때도 그 관계가 타당한지 별도로 확인해야 합니다.

저희는 실제 검사 결과를 이미지별로 대조한 뒤 묶음 단위에서도 다시 살펴봤습니다. 모델이 운영자와 같은 이미지를 반려한 경우와, 같은 묶음의 다른 이미지를 반려하고 필요한 콘텐츠를 남긴 경우를 구분했습니다.

평가 단위확인할 내용
이미지 한 장같은 이미지에 같은 판정을 내렸는지 확인합니다.
중복 묶음서로 대체 가능한 이미지가 남았는지, 필요한 콘텐츠가 잘못 제외되지는 않았는지 확인합니다.
운영자 작업검사 이후에도 사람이 확인하거나 처리해야 하는 작업을 셉니다.

작업 감소는 따로 확인해야 했습니다. 같은 묶음에서 여러 장을 반려해도 운영자가 묶음을 다시 열어 봐야 한다면 확인 작업은 남습니다. 따라서 이미지별 일치율이나 검출 건수를 작업 건수와 심사 시간의 감소로 그대로 해석하지 않았습니다.

다시 심사하자 달라진 운영자 판정

AI의 답이 맞는지 비교할 기준인 정답 데이터로 운영자의 기존 판정을 먼저 검토했습니다. 각 이미지에 붙은 통과·반려 같은 판정을 레이블이라고 부릅니다. 기록을 그대로 비교 기준으로 써도 되는지 확인하려고 운영자에게 일부 이미지를 다시 판정받았습니다. 같은 사람이 같은 이미지를 두고 이전과 다른 판정을 내리는 사례가 있었습니다.

판정 기준이 평가에 미치는 영향을 설명하기 위해, 색감만 조금 다른 사진 두 장을 가정해 보겠습니다. 운영자가 한 번은 색감 차이를 인정해 둘 다 통과시키고, 다시 볼 때는 같은 용도로 쓸 수 있다고 판단해 한 장을 반려할 수 있습니다. 색감 차이를 어느 정도까지 별개 콘텐츠로 인정할지 정하지 않았다면, 어느 판정을 정답으로 삼는지에 따라 같은 AI의 점수가 달라집니다.

설명용 가정: 같은 운영자가 색감만 다른 사진 쌍을 처음에는 모두 통과시키고 다시 볼 때는 한 장을 반려하는 비교
설명용 가정: 같은 운영자가 색감만 다른 사진 쌍을 처음에는 모두 통과시키고 다시 볼 때는 한 장을 반려하는 비교

저희가 실제로 받은 재판정 결과에서도 판정이 달라진 사례가 있었으므로, 저장된 통과·반려 값만으로 모델의 오류를 가릴 수 없다고 판단했습니다. 어떤 이미지와 비교했고 어떤 차이를 별개의 쓰임으로 인정했는지까지 확인해야 했습니다. 개발자가 다시 판정한 결과도 같은 기준으로 검토해야 했습니다.

그래서 평가 결과를 해석할 때는 사례를 다음처럼 구분했습니다.

  • 명확한 중복: 어느 한 장을 제외해도 필요한 사용 목적을 충족합니다.
  • 별개 콘텐츠: 소재가 비슷해도 쓰임이 분명히 구분됩니다.
  • 경계 사례: 현재 기준만으로 통과와 반려를 일관되게 나누기 어렵습니다.

경계 사례를 따로 살펴보자 확실하게 평가할 수 있는 범위와 기준을 더 검토해야 하는 범위를 구분할 수 있었습니다. 직접 확인한 사례도 어떤 구간에서 골랐는지 함께 기록해야 했습니다. 일부 사례에서 문제가 발견되지 않았다는 결과를 전체의 안전성으로 확대해서 해석하지 않도록 평가 범위를 명시했습니다.

오반려만으로 판단할 수 없었던 검사 품질

초기 실험에서는 운영자가 통과시킨 이미지에 새 검사를 실행해 오반려가 있는지 확인했습니다. 해당 표본에서 오반려가 나오지 않아 처음에는 안전한 검사라고 판단했습니다. 그러나 운영자가 반려한 이미지를 따로 모아 실행하자, 문제를 전혀 찾지 못하는 검사도 있었습니다.

극단적인 경우로, 모든 이미지를 통과시키는 검사를 가정하면 오반려가 없지만 문제도 전혀 찾지 못합니다. 정상 이미지를 잘못 제외하는지와 문제 이미지를 찾아내는지는 따로 확인해야 합니다.

설명용 가정: 정상 안내 이미지와 글자가 깨진 안내 이미지를 모두 통과시키면, 오반려는 없지만 문제 검출에는 실패하는 사례
설명용 가정: 정상 안내 이미지와 글자가 깨진 안내 이미지를 모두 통과시키면, 오반려는 없지만 문제 검출에는 실패하는 사례

문제를 찾지 못한 실제 검사 결과를 확인한 뒤부터는 통과 이미지와 문제가 있는 이미지를 함께 사용했습니다. 평가 대상을 나누고 각각 다른 질문에 답하도록 확인 항목을 정리했습니다.

정상 이미지와 문제 이미지는 사전에 정한 평가 기준으로 구분합니다. 문제가 있는 이미지를 찾아 반려하는 일을 검출로 정의하면, 정상 이미지를 잘못 제외한 비율은 오반려율로, 문제 이미지 중 실제로 찾아낸 비율은 문제 검출률(재현율)로 나타낼 수 있습니다. 두 지표는 분모가 다르므로 전체 이미지 수로 한꺼번에 나누지 않습니다.

평가 대상확인할 내용
기준상 문제가 명확한 이미지문제 검출률 = 해당 문제를 찾아 반려한 이미지 수 ÷ 평가 기준상 문제가 있는 이미지 수입니다.
정상 이미지오반려율 = 잘못 반려한 정상 이미지 수 ÷ 평가 기준상 정상인 이미지 수입니다.
판단이 엇갈릴 수 있는 이미지사람의 확인이 필요한 경계를 살펴봅니다.
호출이나 저장 실패를 재현한 상황실패 이후에도 검토할 수 있는 결과가 남는지 확인합니다.

재현 대상: 이미지와 판단 시점의 상태

중복 검사는 심사 대상과 비교할 이미지가 함께 있어야 판단할 수 있습니다. 여기서 비교 후보는 심사 대상과 대조하도록 검사에 전달하는 이미지 목록입니다. 후보를 구성하는 단계와 그 안에서 중복을 판정하는 단계를 구분해서 확인할 수 있습니다.

같은 이미지를 고정해 모델과 기준값을 비교할 때는 검출 결과가 잘 나왔습니다. 그러나 처리 순서를 반영해 다시 실행하자 놓치는 사례가 나왔습니다. 처음에는 모델이나 기준값의 한계라고 생각했습니다.

놓친 이미지가 받았던 비교 후보를 다시 구성해 보니, 중복 여부를 판단하는 데 필요한 이미지가 목록에 없었습니다. 후보를 고르는 조건과 당시 이미지의 심사 상태를 확인했습니다.

비교 후보는 심사가 끝난 이미지에서만 골랐습니다. 테스트에서는 이미지를 심사 완료 상태로 넣었지만, 실제 순서를 재현했을 때는 아직 심사 대기 중인 이미지가 후보에서 빠졌습니다. 여기서 상태는 심사가 끝났는지, 아직 대기 중인지처럼 후보에 넣을 수 있는지를 결정하는 당시의 정보를 뜻합니다.

실제로 확인한 후보 누락을 이미지 A와 B가 차례로 등록되는 상황으로 단순화해 설명하겠습니다. B를 검사할 때 A가 아직 심사 대기 중이라면, A는 B의 비교 후보에 들어가지 않습니다. 파일이 저장되어 있어도 심사가 끝나지 않았기 때문입니다.

반면 고정 표본 테스트에서 A를 미리 심사 완료 상태로 넣었다면 B의 중복을 찾을 수 있습니다. 프롬프트나 임계값을 바꿔도 비교 목록에 들어오지 않은 A와의 중복은 찾을 수 없습니다.

판단 시점의 심사 상태에 따라 B의 비교 후보에 A가 포함되거나 빠지는 상황을 재구성한 그림
판단 시점의 심사 상태에 따라 B의 비교 후보에 A가 포함되거나 빠지는 상황을 재구성한 그림

저희는 재현 테스트에서 확인한 후보 누락을 계기로, 모델에 전달된 입력부터 점검하도록 테스트를 바꿨습니다. 이미지 파일과 함께 등록 순서, 판단 시점의 상태, 앞선 판정이 다음 비교 후보에 미치는 영향을 살폈습니다. 테스트도 목적에 따라 나눴습니다.

  • 고정 표본 테스트: 같은 이미지와 비교 후보를 고정해 모델과 규칙의 상대적인 차이를 빠르게 확인합니다.
  • 처리 재생 테스트: 입력이 들어온 순서와 판단 시점의 상태를 반영해 비교 후보가 만들어지는 과정과 실패 이후의 처리를 확인합니다.

오류 비용에 따른 자동화 범위

AI가 정상 이미지를 잘못 반려하면 운영자에게 도달하지 않습니다. AI가 놓친 문제 이미지는 운영자가 다시 확인할 수 있습니다. 두 오류의 영향이 다르므로, 전체 일치율이 가장 높은 임계값을 그대로 자동 반려 기준으로 삼기는 어렵습니다.

저희는 중복 여부를 판단할 근거로 이미지의 유사도도 비교했습니다. 유사도는 두 이미지가 얼마나 비슷한지를 나타내는 값입니다. 실제 이미지를 열어 보니, 이 점수만으로 사람이 보는 쓰임의 차이를 설명하기 어려운 사례가 있었습니다. 그래서 점수와 이미지를 함께 보며 어떤 유형에서 판단이 어려운지 확인하고 적용 범위를 검토했습니다.

점수와 쓰임의 차이를 설명하기 위해, 안내 문구가 서로 다른 표지판 두 장을 가정해 보겠습니다. 배경과 구도가 비슷해도 전달하는 정보가 다르므로, 외형이 비슷하다는 이유만으로 서로 대체할 수 있다고 판단하기는 어렵습니다.

설명용으로 그린 입구·출구 표지판: 외형은 비슷하지만 안내하는 정보가 달라 서로 대체할 수 없는 사례
설명용으로 그린 입구·출구 표지판: 외형은 비슷하지만 안내하는 정보가 달라 서로 대체할 수 없는 사례

반면 AI가 중복 가능성을 표시하고 최종 판단은 운영자가 한다면, 잘못된 제안도 이미지가 제외되기 전에 검토할 수 있습니다. 같은 점수라도 자동 반려에 쓰는지 참고 정보로 보여주는지에 따라 허용할 수 있는 범위가 달라집니다.

이 경험에서 얻은 원칙은 확실한 결과를 자동 처리할 범위와 사람이 확인할 범위를 나누는 것입니다. 판단할 수 없거나 호출에 실패한 결과도 사람이 확인할 수 있어야 합니다. 이후 기준을 다시 검토할 수 있도록 판정과 근거를 남기는 방식까지 함께 설계해야 합니다.

마치며

작업 전에는 데이터를 많이 본다는 말을 주로 표본 수의 문제로 이해했습니다. 이후에는 같은 데이터를 어떤 단위로 세는지, 정답으로 사용한 기록이 어떤 과정을 거쳐 만들어졌는지, 실제 입력을 재현했는지가 결론에 영향을 준다는 것을 알게 되었습니다. 데이터를 보는 관점을 넓히는 것이 다음 분석에서 무엇을 먼저 확인할지 정하는 데 도움이 되었습니다.

아쉽게도 검토한 중복 검사는 상용 배포로 이어지지 않았습니다. 그래도 이 과정에서 AI 심사를 평가하는 기준은 더 분명해졌습니다. 문제를 얼마나 잘 찾는지뿐 아니라 정상 이미지를 잘못 제외하지 않는지, 운영자의 반복 작업을 실제로 줄일 수 있는지도 함께 살펴보게 되었습니다.

이번 경험에서 얻은 가장 큰 교훈은 해결하려는 문제에 맞춰 평가할 데이터와 단위를 정해야 한다는 점입니다. 다음에 비슷한 요청을 받으면 모델을 고르기 전에 어떤 작업을 줄이려는지, 그 과정에서 어떤 오류를 주의해야 하는지부터 확인하려고 합니다.