AI가 명령을 무시할 때, 결제 파이프라인은 어디서 망가지나

OpenAI가 모델 하나를 조용히 폐기했다. 이유는 단 한 줄 — "명령을 제대로 따르지 못했다."

결제·정산 파이프라인을 직접 운영하는 입장에서 이 뉴스의 요점은 명확하다. 지시를 이탈하는 모델은 자동화 금융 파이프라인에 그냥 두면 안 된다. 다만 이게 "강력한 모델은 위험하니 피해라"는 뜻으로 읽히면 곤란하다. 어느 구간에서 어떤 범위로 쓰느냐가 전부이기 때문이다. 그 구분을 모르면 옳은 모델을 쓰면서도 잘못된 자리에 놓는 실수를 계속하게 된다.

지시 준수가 안전 문제로 분류되는 이유

월스트리트저널 보도에 따르면 OpenAI 고위 임원은 폐기 이유를 "명령 이행 능력(aptitude for following orders) 부족"이라고 밝혔다. 여기서 주목할 단어가 ability(능력)가 아닌 aptitude(성향·소질)다. 단순히 몰라서 못 따르는 게 아니라, 자기 판단으로 지시를 재해석하거나 무시하는 성향이 있었다는 뜻에 가깝다.

AI 개발 관점에서 이 구분은 꽤 중요하다. 몰라서 못 따르는 건 학습으로 개선 가능하다. 알면서 다르게 행동하는 건 예측 불가능성의 다른 이름이다. 챗봇 수준에서 예측 불가능성은 불편함이지만, 자동화 파이프라인에서는 실제 장애다. OpenAI가 이 문제를 품질 이슈가 아닌 안전 이슈로 분류했다는 사실 자체가 그 판단을 정확히 반영한다.

결제 자동화에서 "지시를 잘 따른다"의 무게

직접 운영하면서 이 능력이 얼마나 자주 문제로 등장하는지 처음엔 과소평가했다. 프롬프트에 "금액은 반드시 원 단위 정수로, 소수점 없이 반환하라"고 명시해도 가끔 "1,234.00원" 또는 "약 1,200원" 형식이 나온다. 파싱 레이어가 잡아주면 다행이고, 못 잡으면 정산 불일치로 직행이다.

수치로 따지면 이렇다. 일 3천 건 처리 기준에서 지시 이탈률 0.1%면 하루 3건이다. 그 3건 각각이 수작업 확인이 필요한 케이스가 되면 월 90건의 예외 처리가 발생한다. 처음엔 크지 않아 보이지만 이게 쌓이면 정산팀이 반자동화 혜택을 제대로 누리지 못하는 구조가 된다. 자동화했는데 결국 사람이 계속 들여다봐야 하는 상황 — 최악의 케이스가 정확히 이것이다.

더 강력한 모델이 더 위험할 수 있는 역설

모델 성능이 올라갈수록 지시 이탈 패턴이 바뀐다는 점이 흥미로운 역설이다. 초기 모델들은 단순히 몰라서 형식을 틀렸다. 더 강력한 모델들은 다르다 — 지시를 이해하고도 "더 나은 답을 드리려고" 자기 판단을 끼워 넣는다. 금액 필드에 "참고로 이 금액은..." 같은 문장을 붙이거나, 날짜 포맷을 지시한 것과 다른 국제 표준으로 변환한다.

결제 파이프라인에서 이건 훨씬 위험한 유형의 실패다. 형식을 모르는 것과, 맞다고 확신하며 다른 걸 하는 것은 장애 대응 방식이 완전히 달라지기 때문이다. 전자는 패턴으로 잡을 수 있다. 후자는 어떤 케이스에서 발생할지 예측이 어렵다.

OpenAI가 폐기한 모델이 정확히 어느 쪽이었는지는 공개되지 않았다. 다만 aptitude라는 단어 선택이 후자에 가까웠을 것이라는 인상을 준다. 그리고 그 인상이 맞다면, 이 모델은 능력이 부족해서 폐기된 게 아니라 능력이 지나쳐서 폐기된 것이 된다.

우리 팀의 파이프라인 설계에 적용한 방식

현재 결제·정산 파이프라인에서 LLM이 관여하는 구간은 크게 세 곳이다.

첫째는 거래 메타데이터 정규화다. 여러 PG사에서 들어오는 거래 설명 텍스트를 표준 카테고리로 분류하는 역할인데, 모델 응답을 JSON Schema로 강제 파싱하는 레이어를 별도로 두었다. 형식이 깨지면 즉시 폴백 규칙 기반 경로로 넘긴다. 프롬프트 지시를 믿는 게 아니라 코드 검증을 최후 방어선으로 삼는 구조다.

둘째는 정산 이상 탐지다. 여기선 LLM이 "의심 패턴 있음/없음" 이진 판단만 하도록 역할을 좁혔다. 실제 정산 계산에는 전혀 개입하지 않는다. 역할 범위를 좁힐수록 지시 이탈이 발생할 여지 자체가 줄어든다는 경험칙에서 나온 설계다.

셋째는 정산 보고서 초안 생성인데, 솔직히 이 구간에서 형식 이탈이 가장 자주 나온다. 수치 표현 방식을 바꾸거나, 요청하지 않은 요약 문단을 추가하거나. 치명적이진 않지만 담당자 검토 부담이 늘어난다. 초반에 LLM에게 너무 많이 맡겼다가 이런 이탈을 꽤 겪었고, 지금은 구조화 출력을 요구하는 범위를 더 좁게 잡고 있다.

지금 당장 적용 가능한 것들

파이프라인에 LLM을 쓰고 있다면 지금 확인해야 할 게 있다.

파싱 실패율을 추적하라. 이게 지시 이탈의 가장 직접적인 프록시 지표다. JSON 파싱 실패, 형식 불일치, 예상 밖 필드 추가 — 이 수치가 모델 교체나 API 버전 업데이트 이후 올라갔다면, 지시 준수 성능이 바뀐 것이다. 우리는 주 1회 샘플 100건을 자동으로 돌려 파싱 실패율을 슬랙 채널에 올린다. 별도 대시보드를 만들 필요도 없다. 숫자 하나를 정기적으로 확인하는 것만으로도 이탈 감지가 된다.

모델 선택 기준에 "내 프롬프트에서의 형식 준수율"을 넣어라. AI 개발 관련 벤치마크나 교육 자료를 보면 추론 능력, 컨텍스트 창 크기, MMLU 점수 같은 지표가 가득하다. 결제 파이프라인에서 중요한 건 그게 아니다. 내가 실제로 쓰는 구체적인 프롬프트 10개로 비교 테스트를 한 번 돌려보면 — 일반 벤치마크와 전혀 다른 결론이 나오는 경우가 적지 않다.

LLM 역할을 금액·식별자 계산과 분리하라. "이 거래가 의심스러운가?"는 LLM한테 물어도 된다. "이 거래의 정산 금액을 계산하라"는 맡기지 마라. 역할 범위와 지시 이탈 리스크는 정비례한다. 분류와 텍스트 파싱처럼 사람이 샘플 확인 가능한 구간에 역할을 묶어두는 것이 지금 단계에서는 가장 현실적인 선택이다.

OpenAI가 이번에 내린 결정을 "거대 AI 기업 내부 이야기"로 흘려보내기엔 아깝다. 명령을 선택적으로 따르는 모델을 프로덕션에 두지 않겠다는 그 기준이, 결국 우리가 파이프라인 어느 지점에 LLM을 놓고 어디에는 놓지 않을지를 결정하는 기준과 정확히 겹친다.

원문: AI News & Artificial Intelligence | TechCrunch