왜 대부분의 AI-LC-MS 프로젝트는 PoC에서 멈추는가

 모델은 맞았지만, 아무도 책임질 수 없었다

왜 대부분의 AI-LC-MS 프로젝트는 PoC에서 멈추는가

1️⃣ PoC의 목표 자체가 잘못 설정된다

대부분의 AI-LC-MS PoC는 이렇게 시작한다.

“AI로 이거 할 수 있나요?”

그래서 PoC의 성공 기준이:

• accuracy 몇 %
• anomaly detect 성공
• 사람보다 잘 맞춤

같은 기술 데모 수준에 머문다.

하지만 운영 단계의 질문은 완전히 다르다.

• 이 결과로 무엇을 결정할 것인가?
• 이 판단의 책임자는 누구인가?
• 이 결과가 틀렸을 때 어디까지 허용되는가?

👉 PoC는 “가능한가?”에 답하지만,
👉 운영은 “써도 되는가?”에 답해야 한다.

이 간극을 처음부터 설계하지 않으면
PoC는 성공해도 프로젝트는 멈춘다.

2️⃣ AI가 ‘판단’을 대신하도록 설계된다

PoC 단계에서 가장 흔한 설계 오류는 이거다.

“AI가 batch 이상 여부를 판단하게 하자.”

이건 PoC에선 멋있다.
운영에선 바로 막힌다.

왜냐하면:

• AI 판단의 근거를 QA가 요구하고
• 모델은 그 근거를 문장으로 설명하지 못하며
• 책임 주체가 모호해진다.

그래서 QA의 질문은 항상 같다.

“이 결과에 대해 누가 사인하나요?”

그 질문에 답이 없으면
👉 프로젝트는 PoC에서 종료된다.

3️⃣ ‘설명 가능성’을 나중에 붙이려 한다

많은 팀이 이렇게 생각한다.

“일단 모델부터 만들고,
나중에 explainability를 붙이자.”

하지만 LC-MS 환경에서는 이게 거의 불가능하다.

왜냐하면:

• 데이터 자체가 고차원이고
• 전처리 단계가 복잡하며
• 결정 기준이 명시적이지 않기 때문이다.

결국:

• SHAP plot 몇 장
• feature importance 그래프
• “이상치로 분류됨”이라는 문장

정도로는 audit을 못 버틴다.

👉 설명 가능성은 기능이 아니라, 설계 조건이다.

4️⃣ Golden batch, reference 구조 없이 AI를 얹는다

PoC에서 AI는 보통 이렇게 학습된다.

• 과거 데이터
• “정상/이상”으로 라벨링
• 분류 또는 이상 탐지

하지만 실제 운영에선 QA가 묻는다.

“그럼 ‘정상’의 기준은 뭔가요?”

이 질문에:

• Golden batch 정의가 없고
• reference distribution이 없고
• 변동성의 범위가 합의되지 않았다면

AI 결과는 근거 없는 점수가 된다.

👉 AI는 기준을 만들지 못한다.
👉 기준 위에서만 작동한다.

5️⃣ 데이터 무결성 구조가 PoC에 포함되지 않는다

PoC에서는 종종 이런 전제가 깔린다.

• 파일은 깨끗하다
• export는 정확하다
• 누가 언제 돌렸는지는 중요하지 않다

하지만 운영에서는:

• Part 11
• audit trail
• version control
• access control

이 없으면 아무 의미가 없다.

그래서 QA는 말한다.

“이건 연구용으론 흥미롭지만,
GMP 환경에선 쓸 수 없어요.”

그리고 프로젝트는 멈춘다.

6️⃣ AI 결과가 SOP 언어로 번역되지 않는다

PoC 결과는 보통 이렇게 나온다.

• anomaly score = 0.92
• similarity index = 0.87

하지만 SOP는 이렇게 묻는다.

• 이 점수는 어디에 쓰이나?
• 어느 threshold에서 무엇을 해야 하나?
• deviation은 언제 열리는가?

이 연결이 없으면:

• AI 결과는 참고 자료
• 참고 자료는 비공식
• 비공식은 운영 불가

👉 PoC를 넘지 못하는 이유는 SOP 문장이 없기 때문이다.

7️⃣ PoC 이후의 ‘유지 관리’가 설계되지 않는다

PoC에서는 모델이 “한 번 잘 돌아가면 끝”처럼 보인다.

하지만 실제 운영에선:

• 장비 상태가 바뀌고
• column이 바뀌고
• matrix가 달라지고
• 사람도 바뀐다

이때 QA는 묻는다.

“모델은 언제 재학습하나요?”
“그 판단 기준은 누가 정하죠?”

여기에 답이 없으면
AI는 불안정한 블랙박스가 된다.

8️⃣ PoC를 넘어간 소수의 프로젝트들이 공통으로 한 것

실제로 PoC를 넘긴 AI-LC-MS 프로젝트들은
공통적으로 이 순서를 밟았다.

1. AI가 하지 않을 것부터 정의
2. Golden batch / reference 구조 확립
3. AI 결과를 판단 보조 신호로 제한
4. 결과를 SOP 문장으로 번역
5. QA 문서와 함께 설계

👉 모델은 그 다음 문제였다.

9️⃣ 이 질문에 대한 가장 정직한 결론

대부분의 AI-LC-MS 프로젝트는
실패한 게 아니라,
‘운영될 준비가 안 된 상태에서 멈춘 것’이다.

AI는 기술적으로는 이미 가능하다.
문제는:

• 책임 구조
• 설명 언어
• 규제 적합성
• 유지 관리 체계

이 네 가지다.

마무리 문장

PoC는 기술의 증명이고,
운영은 신뢰의 증명이다.

AI-LC-MS 프로젝트가 PoC를 넘으려면
모델보다 먼저
👉 조직이 책임질 수 있는 구조를 만들어야 한다.