모델 전문가 없이 학습 결과를 읽는 법

대부분의 공장에는 모델 전문가가 없습니다

검사 모델을 도입한 공장에는 설비 담당자와 품질 담당자가 있습니다. 두 사람 모두 제품을 압니다. 어떤 흠집이 불량이고 어떤 자국은 넘어가도 되는지, 어느 라인에서 유난히 문제가 잦은지 알고 있습니다. 다만 학습 결과 화면을 열었을 때 거기 적힌 숫자가 무엇을 뜻하는지는 아무도 모릅니다. 학습 설정을 정하고 그 결과를 읽어낼 줄 아는 모델 전문가가 없기 때문입니다. 제품을 아는 사람과 모델을 아는 사람이 같은 공장에 있지 않습니다.

특정 공장만의 사정이 아닙니다. 중소기업중앙회가 2025년 9월 상생형 스마트공장 사업 참여 기업 502개사를 조사했을 때(중소기업중앙회, 「스마트공장 구축 中企 AI도입 의견조사」, 2025년 10월 17일 발표) , AI 도입을 망설이는 이유로 전문인력 부족을 꼽은 곳은 20.5%였습니다. 그런데 이미 운영 중인 기업에서는 이 비율이 43.8%로 올라가고, 제조 데이터를 다루는 단계에서는 50.4%로 가장 높아집니다. 사람이 없다는 사실은 도입할 때보다 쓰기 시작한 뒤에 더 뚜렷해집니다.

MLOps 플랫폼을 도입해도 마찬가지입니다. 결과를 읽을 사람이 없으면 필요한 모델을 계속 만들어 쓰는 단계까지 가지 못합니다. 그렇다고 결과를 읽어줄 사람을 새로 뽑기도 어렵습니다.

AIVEX는 검사 모델과 MLOps 플랫폼을 공급하는 회사이고, "이 모델이 잘된 건가요?"라는 질문을 가장 많이 받아온 당사자입니다. 그래서 읽는 일 자체를 플랫폼 안으로 옮기기로 했습니다. 다행히 학습에 사용된 데이터와 중간 결과, 최종 결과는 이미 정해진 형식으로 남아 있습니다. 그 숫자를 해석해 사람의 말로 풀어내는 단계만 떼어내면, 그 일은 LLM이 지금 가장 잘하는 일과 정확히 겹칩니다.

[그림 1] AI를 활용하는 기업은 전문 인력이 더욱 부족하다고 생각합니다 (중소기업중앙회, 2025)

LLM에게 맡기자 다른 문제가 시작됐습니다

그 첫 단계로, 학습이 끝나면 남는 결과 JSON을 읽는 기능을 만들었습니다. 모델의 품질 상태를 초록·노랑·빨강 세 단계로 판정하고, 판정 근거와 함께 다음 학습에서 무엇을 바꾸면 좋을지까지 사람의 말로 내놓습니다. 문서 검색도 대화 기억도 필요 없고, 입력은 이미 가지고 있는 모델 결과 하나로 끝납니다. 시스템 프롬프트만 잘 적어두면 될 일로 보였습니다. 실제 학습 결과를 넣어보기 전까지는 그랬습니다.

먼저 문제가 된 것은 데이터의 양이었습니다. 분석에 넘기는 수치는 소수점 열여섯 자리까지 들어 있어서, 0.9994897842407227 같은 값 하나가 토큰을 예닐곱 개 차지합니다. 이런 값이 수백 개 모이면 그 자체로 비용이 됩니다. 클래스가 쉰 개를 넘어 혼동행렬이 50×50이 되면 프롬프트는 길이 제한을 넘고, LLM은 중간 내용을 잊거나 없는 이야기를 지어냅니다. 데이터를 다 주면 모델이 오히려 읽지 못합니다. 그래서 설계의 핵심은 무엇을 넣을지가 아니라, 무엇을 빼도 판정이 바뀌지 않는지였습니다.

다음 문제는 출력 형식이었습니다. 해설을 화면에 그리려면 정해진 JSON 구조로 받아야 하는데, LLM은 대체로 지키다가 가끔 어깁니다. 앞에 "다음은 요청하신 JSON입니다" 같은 문장을 덧붙이거나, 마크다운 코드 블록으로 감싸거나, 괄호를 하나 더 붙입니다. 한 글자 차이라도 파싱이 실패하면 화면에는 아무것도 남지 않습니다. 그래서 실패한 응답을 그대로 버리지 않고 고쳐 읽는 가드레일을 만들었습니다. 그런데 코드로는 해결되지 않는 것이 하나 남아 있었습니다.

남은 것은 LLM이 무엇을 어떤 말로 설명하느냐였습니다. 파싱은 성공했고 숫자도 맞는데 설명이 현장에서 읽히지 않는 경우가 있습니다. 코드는 틀렸을 때 고치지만, 프롬프트는 틀리지 않았는데도 고쳐야 할 때가 더 많았습니다.

가장 잦은 이유는 용어였습니다. LLM에게 넘기는 입력에는 코드에서 쓰려고 지은 이름이 그대로 섞여 있고, LLM은 아는 단어가 그것뿐이니 문장에도 그대로 옮겨 씁니다. 현장 담당자는 그 단어를 본 적이 없습니다. 그래서 어떤 항목을 어떤 말로 바꿔 부를지를 프롬프트에서 하나씩 정해 두어야 합니다.

판정 기준도 마찬가지입니다. 검증 데이터까지 학습에 써버린 모델이 대표적입니다. 채점에만 써야 할 데이터를 학습에 넣으면 문제를 미리 보고 치른 시험이 되어, 점수는 높아도 그 점수가 실력을 뜻하지 않습니다. 그래서 성능 수치가 아무리 좋아도 배포에 주의해야 하는 쪽으로 분류하기로 했습니다. 결함을 고친 것이 아니라 품질 정책을 정한 것이고, 정책이 바뀌면 문장도 바뀝니다.

더 곤란한 것은, 이런 용어와 판정 기준이 한 번 정해두면 끝나는 것이 아니라는 점입니다. 검출·분할·분류처럼 모델의 종류마다 설정 항목이 다르고, 학습 엔진의 버전이 올라가면 같은 항목이라도 이름과 값의 범위가 달라집니다. 모델과 버전이 늘어나는 만큼 프롬프트도 함께 움직여야 합니다.

[그림 2] 세 겹을 지나고 나서야 학습 결과가 읽을 수 있는 설명이 됩니다

시스템 프롬프트는 코드가 아니라 운영자산입니다

시스템 프롬프트는 틀려서 고치는 것이 아니라 상황이 바뀌어서 고칩니다. 부르는 말이 현장과 어긋날 때, 무엇을 주의해서 보라고 할지 정책이 달라질 때, 새로운 종류의 모델이 들어오거나 학습 엔진의 버전이 올라갈 때마다 손을 봐야 합니다. 한 번 잘 써두고 잊는 파일이 아니라, 다루는 모델이 늘어나는 동안 계속 따라 움직이는 자산입니다.

바뀔 일이 이렇게 잦은데 고칠 때마다 개발자를 찾고 배포를 기다려야 한다면 아무도 고치지 않습니다. 그래서 프롬프트를 코드 밖으로 꺼내 화면으로 옮겼습니다. 화면에서 직접 작성하고, 저장만 해둔 상태와 배포된 상태를 나누고, 지금 어느 것이 적용 중이며 마지막으로 배포한 사람이 누구인지를 목록에서 바로 보이게 했습니다. 무엇을 LLM에게 넘길지도 여기서 고르는데, 항목마다 어떤 데이터가 들어 있는지 설명을 붙였습니다. 이름만 늘어놓아서는 개발자가 아닌 사람이 무엇을 골라야 할지 알 수 없기 때문입니다.

고칠 수 있게 만들자마자 다음 문제가 따라왔습니다. 고친 결과를 확인하겠다고 배포하면 그 순간 모든 사용자에게 나갑니다. 그래서 같은 화면에 플레이그라운드를 붙였습니다. 실제 모델과 데이터셋을 지정하면, 프롬프트를 실행해 나온 JSON과 그 JSON이 화면에 그려진 모습까지 배포 전에 확인할 수 있습니다. 입력 토큰과 출력 토큰도 함께 표시되어, 문장을 한 줄 늘렸을 때 비용이 얼마나 늘어나는지가 그 자리에서 보입니다.

여기까지가 해설 한 번을 제대로 만들기 위한 이야기입니다. 다만 현장에서 필요한 것은 잘 만든 해설 한 번이 아니었습니다.

[그림 3] 프롬프트를 화면에서 고치고, 배포 전에 결과와 비용을 확인합니다

분석에서 끝나면 의미가 없습니다

판정과 함께 나오는 것이 하나 더 있습니다. 다음 학습에서 모델 성능을 올리려면 무엇을 어떻게 바꿔야 하는지 알려주는 추천 설정입니다. 그런데 이 설정에는 쓰임새가 하나 더 있습니다. 사람이 읽고 참고하는 데서 그치지 않고, 그 값이 그대로 다음 학습의 설정으로 들어갑니다. 어떤 항목을 어떤 값으로 왜 바꾸는지가 정해진 형식으로 나오기 때문에 가능한 일입니다.

그런데 한 번으로는 부족했습니다. 추천대로 학습을 실행해도 단번에 목표에 닿는 경우는 드물고, 결과를 확인하고 다시 조정하는 반복은 그대로 사람 몫으로 남습니다. 그래서 반복 자체를 넘기기로 했습니다. 학습을 실행하고, 결과를 평가하고, 다음 설정을 받아 다시 학습하는 과정을 시스템이 이어서 돌립니다.

대신 언제 멈출지를 먼저 정하게 했습니다. 학습 한 번은 GPU 자원을 오래 점유하는 일이라, 끝을 정해두지 않으면 반복이 길어지는 만큼 낭비가 됩니다. F1 점수, 과검률, 미검률 가운데 이번에 중요한 것만 목표로 지정하면 되고, 여러 개를 지정하면 전부 충족했을 때 멈춥니다. 최대 시도 횟수도 함께 정합니다.

첫 학습은 해설이 내놓은 추천 설정으로 시작합니다. 목표를 넘겼으면 거기서 멈추고, 못 넘겼으면 이번 회차의 설정과 결과를 앞선 회차들과 함께 넘겨 다음 설정을 받습니다. 정한 횟수를 다 쓰면 도달하지 못한 채로 종료하고, 새로 받은 설정이 지금까지 어느 회차와든 같으면 그 자리에서 멈춥니다. 더 제안할 것이 없다는 뜻이기 때문입니다.

설계에서 실제로 문제가 된 것은 다른 곳에 있었습니다. 기존 해설은 모델 하나만 놓고 만들어진 구조인데, 반복 학습에서 중요한 것은 지난번보다 나아졌느냐입니다. 비교 대상이 입력에 없으니 성능 수치만으로는 의미를 판단할 수 없었고, 프롬프트 문장이 아니라 입력 구조의 문제였습니다. 그래서 회차마다 넘기는 데이터를 두 종류로 나눴습니다. 이번 회차는 원본 그대로 싣고, 지난 회차들은 지표를 추리고 무엇이 달라졌는지만 남긴 요약으로 압축합니다.

그래도 회차가 쌓일수록 입력은 길어집니다. 실제로 측정해 보니 이전 회차를 함께 넣었을 때 토큰이 약 47% 늘었습니다. 비교를 하기로 정한 이상 피할 수 없는 비용이고, 지금 규모에서는 감당할 수 있는 수준으로 판단했습니다.

[그림 4] 목표를 걸어두면 닿을 때까지 학습과 평가를 이어서 돌립니다

이제 중요한 것은 모델이 아니라 데이터입니다

이제 담당자는 퇴근 전에 목표만 걸어두면 됩니다. 다음 날 아침이면 초록인지 노랑인지, 왜 그렇게 판정했는지, 다음에는 무엇을 바꾸면 되는지가 화면에 준비되어 있습니다. 학습이 끝나면 판정과 근거와 다음 설정이 한 번에 나오고, 목표에 닿을 때까지 반복하는 일도 사람 손을 거치지 않습니다. 모델 전문가가 결과를 읽고 내리던 판단을, 이제 AI 시스템이 대신 할 수 있습니다.

물론 전부가 자동으로 되지는 않습니다. 어떤 클래스의 검증 데이터가 두 장뿐이라면, 증강을 아무리 강화해도 그 클래스의 미검은 줄지 않습니다. 부족한 것은 파라미터가 아니라 데이터입니다. 반복이 목표에 닿지 못한 채 끝났을 때도 그 사실은 알려주지만, 왜 닿지 못했는지까지 설명해주지는 않습니다.

정리하면 병목이 옮겨갔습니다. 어떤 설정으로 학습시킬지는 이제 시스템이 정합니다. 대신 어떤 흠집을 불량으로 볼지 정하고, 부족한 클래스의 이미지를 모아 레이블을 붙이는 일이 앞으로 나왔습니다. 잘 레이블링된 데이터를 얼마나 갖추느냐가 모델의 성능을 가르게 됐습니다.

[그림 5] 밤사이 반복이 이어지고, 아침에 남는 일은 확인뿐입니다

모델 전문가를 두지 못하는 공장이 대부분입니다. 아이벡스의 AIVOps(아이브옵스)는 전문가가 없어도 모델을 만들고, 결과를 바탕으로 스스로 모델을 개선합니다. 남은 과제는 좋은 데이터를 확보하는 것뿐이며, 그 데이터의 원천은 이미 공장 안에 있습니다.