환불 조건을 모두 갖춘 고객이 신청 버튼을 누릅니다. 곧바로 거절 안내가 도착합니다. 회사에 남은 기록은 다음과 같습니다. 자동화된 판단에 따라 고객의 환불 여부가 결정되는 가상의 장면입니다.
거절 안내는 발송됐고, 업무는 완료됐습니다. 운영 대시보드에서도 이상을 찾을 수 없습니다. 그러나 이 고객에게 회사의 환불 규정은 제대로 적용되지 않았습니다.
TypeSafe의 Jev는 이런 판단을 소프트웨어 곳곳에 넣기 쉬워지는 방향을 보여줍니다. 비정형 정보를 받아 코드가 바로 사용할 수 있는 선택값과 확률 정보를 반환하는 모델입니다.
판단을 더 빠르고 저렴하게 호출할 수 있다면 고객 요청을 자동으로 처리할 기회도 늘어납니다. 함께 늘어나는 것은 그 판단이 실제로 적절했는지 확인해야 할 자리입니다.
1. AI 판단 하나를 들이는 데는 비용이 들었습니다
기업은 이미 채용과 신용평가, 사기 탐지와 고객지원에 머신러닝을 사용해 왔습니다. 그 결과는 누가 면접을 보고, 어떤 거래가 통과하고, 누구의 요청이 보류되는지를 좌우합니다. 모델이 반환한 값이 업무에서 사용되는 순간, 기업은 그 기준과 결과를 관리해야 합니다.
그동안 적용 범위를 제한한 요인 중 하나는 구축과 운영의 비용이었습니다. 여기서 말하는 비용은 예측 한 번에 쓰는 연산 비용이 아닙니다. 업무에 맞는 판단 기능 하나를 만들고 계속 유지하는 데 드는 비용입니다.
목적별 모델을 개발하려면 무엇을 정답으로 볼지 정하고, 데이터를 준비하고, 학습과 검증을 거쳐 업무 시스템에 연결해야 했습니다. 운영 중 기준이나 입력조건이 달라지면 다시 평가하고 수정해야 합니다. 판단 하나가 개발 프로젝트와 지속적인 운영 업무를 함께 만드는 셈입니다.
기업은 이 투자를 정당화할 수 있는 업무부터 자동화하게 됩니다. 처리량이 크거나 절감 효과가 분명한 판단에는 투자할 수 있지만, 중간 절차의 작은 확인마다 별도 모델을 만들기는 어렵습니다. 이 비용이 공정함이나 안전을 보장한 것은 아닙니다. 다만 기계의 판단을 어디까지 도입할지 선택하게 하는 경제적 제약으로 작용했습니다.
2. Jev가 흥미로운 이유는 경제성입니다
기존 LLM에서도 분류 결과나 구조화된 출력을 받아 코드의 분기에 사용할 수 있었습니다. Jev에서 주목할 부분은 이런 판단을 빠르고 저렴하게 반복 사용하도록 설계한 방향입니다.
Jev는 승인·거절·추가 검토 같은 선택값과 확률 정보를 반환합니다. 정해진 선택값은 코드의 다음 경로를 정하는 데, 확률 정보는 자동 처리와 검토 조건을 설계하는 데 사용할 수 있습니다. 이렇게 판단을 소프트웨어의 여러 단계에 추가하고 조합하는 기본 기능, 즉 소프트웨어 프리미티브처럼 활용할 수 있습니다.
기업은 목적별 모델을 새로 개발하는 대신, 기존 애플리케이션에 Jev 호출을 추가하는 방식으로 판단 자동화를 시도할 수 있습니다. 새로운 업무를 검토하는 출발점도 다음처럼 구체적인 질문이 됩니다.
- 이 환불을 승인해도 되는가?
- 이 거래는 추가 검토가 필요한가?
- 이 지원자를 면접 대상으로 넘겨도 되는가?
이런 접근의 경제성이 확보되면, 별도 개발 투자를 정당화하기 어려웠던 작은 판단도 자동화 후보가 될 수 있습니다. 판단 기능 하나를 추가하는 부담이 낮아질수록, 기업이 활용을 검토할 수 있는 업무의 범위도 넓어지는 것입니다.
다만 질문 하나를 추가하는 것만으로 업무 설계가 끝나지는 않습니다. 무엇을 질문하고 어떤 선택지를 둘지, 여러 판단을 어떻게 조합하고 어떤 조건에서 실행할지 정해야 합니다. TypeSafe 역시 실제 업무에서는 질문을 나누고 일관되게 조합하는 도메인 설계가 필요하다고 설명합니다.
더 많은 판단을 자동화할수록, 그 판단에 실제 업무를 맡겨도 되는지 확인해야 할 자리도 늘어납니다.
3. 정상 처리 속에서 실패가 쌓일 수 있습니다
판단을 추가하기 쉬워지면, 하나의 업무 안에서도 AI가 맡는 결정이 늘어날 수 있습니다. 환불 요청 하나에도 요청 분류, 사유 해석, 정보 충족 여부, 지급 조건과 예외 적용 같은 판단이 들어갑니다. 각 단계는 서로 다른 기준을 사용하고, 다른 후속 조치로 이어집니다.
좋은 판단을 싸게 반복할 수 있다는 것은 분명한 진전입니다. 하지만 판단을 반복하는 비용이 낮아지면, 잘못된 판단도 더 큰 규모로 반복될 수 있습니다. 다음은 지원자의 평가 점수와 처리 결과를 남긴 가상의 채용 기록입니다.
모델의 선택 결과와 해당 선택지의 확률은 보이지만, 이 기록만으로는 어떤 근거로 판단했는지, 확률은 어떻게 산출됐는지 알기 어렵습니다. 지원자의 자격을 올바르게 해석했는지, 채용 기준을 제대로 적용했는지도 확인하기 어렵습니다.
이 시스템이 석 달 동안 20만 건을 처리한 뒤, 특정 집단의 탈락률이 계속 높았다는 사실을 발견했다고 가정해 보겠습니다. 그 차이만으로 오류나 차별을 확정할 수는 없습니다. 하지만 어떤 조건이 결과에 영향을 줬는지 조사할 이유는 생깁니다. 성별이나 인종을 직접 입력하지 않았더라도 경력 공백, 학교, 주소 같은 정보가 대리 변수로 작용했는지 살펴볼 수 있습니다.
문제가 항상 집단 간 차이로 나타나는 것도 아닙니다. 같은 내용을 다르게 표현했을 때 오탐이 늘거나, 판단과 무관한 맥락 때문에 임계값 근처의 결정이 뒤집히거나, 업무 정책이 바뀌었는데 이전 기준의 판단이 계속될 수도 있습니다. 그동안 시스템 운영 지표는 다음처럼 정상일 수 있습니다.
요청을 받고 정해진 형식의 응답을 반환하는 과정은 성공했기 때문입니다. 이 지표들은 판단에 업무 기준이 올바르게 적용됐는지까지 알려주지 않습니다. REJECT라는 짧은 결정값만 남아 있다면, 무엇이 잘못됐는지 조사할 단서도 제한됩니다.
요청 하나하나는 정상적으로 끝나더라도, 그 판단이 만든 결과는 조직 안에 쌓입니다. 개별 판단은 업무 기준과 대조하고, 누적 결과에서는 같은 문제가 반복되는 조건과 범위를 살펴봐야 합니다. 문제를 발견하더라도 판단 기준과 실행 방식이 그대로라면 같은 오류가 반복될 수 있습니다. 이를 막으려면 관찰 결과에 따라 판단 기준과 자동 실행 범위를 조정하는 통제가 필요합니다.
4. 모델 목록만으로는 부족할 수 있습니다
기업이 AI를 관리하는 출발점 중 하나는 어떤 모델을 쓰는지 목록을 만드는 것입니다. 어떤 공급사의 어떤 버전인지, 누가 승인했는지, 어떤 벤치마크를 통과했는지를 기록합니다.
하지만 Jev처럼 판단을 소프트웨어 곳곳에 추가하기 쉬워지면, 모델 목록만으로는 부족할 수 있습니다. 같은 모델을 요청 분류와 환불 조건 확인, 최종 거절에 사용하더라도 각 지점에서 적용해야 할 기준과 허용할 조치는 다릅니다. 모델 목록에서는 하나로 보이지만, 기업이 확인해야 할 판단은 여러 곳으로 늘어나는 것입니다. 모델의 공급사와 버전, 승인 여부만으로는 어느 지점에서 업무 기준이 잘못 적용되고 있는지 알기 어렵습니다.
회사가 쓰는 모델 열 개를 아는 것과, 그 모델들이 어디에서 어떤 기준으로 중요한 결정을 내리는지 아는 것은 다른 일입니다. 거버넌스가 모델 목록에서 실제 판단과 실행까지 이어져야 하는 이유입니다. 결정마다 적어도 다음은 알 수 있어야 합니다.
- 어떤 입력을 보고 어떤 판단을 내렸는지
- 어떤 정책과 임계값이 적용됐는지
- 그런 종류의 판단을 자동으로 실행해도 됐는지, 사람의 검토가 필요했는지
- 실제로 어떤 조치가 이어졌는지
- 개별 결과만 볼 때는 보이지 않던 이상이 전체 결과에서 나타나고 있지는 않은지
모델이 어떤 판단을 할 수 있다는 것과, 그 판단에 따라 실제로 조치하도록 허용해도 된다는 것은 다른 문제입니다.
Jev가 보여 주는 방향이 맞다면, 해법이 기계의 판단을 다시 비싸게 만드는 것일 수는 없습니다. 좋은 판단이 더 싸고 빠르게 퍼지는 것은 분명한 기술적 진전입니다. 문제는 판단을 만드는 비용만 내려가고, 그 판단을 검증하고 통제하는 일은 여전히 사람의 수작업에 묶여 있을 때 생깁니다. AI가 내린 판단을 사람이 일일이 다시 읽는 방식만으로는 이 확산을 따라가기 어렵습니다.
필요한 것은 판단이 늘어나는 만큼 함께 커지는 통제 계층(control layer)입니다. 어떤 판단이 실제 조치로 이어져도 되는지 실행 시점에 확인하고, 나중에 어떤 근거와 정책으로 허용됐는지 되짚어 볼 수 있어야 합니다. 하나하나는 멀쩡해 보이는 결정들이 전체적으로 이상한 방향으로 쌓이고 있지 않은지도 볼 수 있어야 합니다. 이상이 확인되면 그 판단의 자동 실행 범위를 좁히거나 적용 기준을 고치거나 사람의 검토로 돌린 뒤, 같은 조건에서 결과가 개선됐는지 다시 평가할 수 있어야 합니다.
AI 판단의 비용이 낮아질수록, 통제와 관찰도 함께 확장돼야 합니다.
우리는 이 문제를 풀기 위해 필요한 계층을 Decision Trust Infrastructure라고 부릅니다.
