[심층분석] 말은 못 하지만 결정은 빠르다: 시스템 원 모델 'Jev'가 LLM 자동화에 던진 질문

채팅은 이미 사람보다 잘하는데, 자동화는 어디 갔을까?

TypeSafe AI라는 회사가 2년간의 스텔스 모드를 끝내고 첫 모델을 공개했어요. 이름은 Jev고, 회사는 이걸 "시스템 원 모델(System One Model)"이라는 새로운 종류의 모델이라고 부르는데요. 창업자 디오고 알메이다(Diogo Almeida)는 OpenAI에서 언어 모델이 사람 말을 잘 따르도록 만드는 방법, 그러니까 ChatGPT의 기반이 된 연구를 했던 사람이에요.

이 사람이 발표문 첫 줄에서 던진 질문이 꽤 뼈아파요. "모델은 몇 년 전부터 채팅에서 사람을 넘어섰는데, 그 많던 자동화는 다 어디 갔냐"는 거예요. 생각해보면 진짜 그래요. ChatGPT한테 물어보면 뭐든 대답은 잘하는데, 막상 우리 회사 시스템에 LLM을 붙여서 "알아서 돌아가게" 만들려고 하면 온갖 문제가 터지거든요. JSON 형식 안 지키고, 없는 값을 지어내고, 가끔은 "죄송하지만 그 요청은 도와드릴 수 없습니다" 하고 거부하고요.

TypeSafe AI의 진단은 이래요. 지금까지의 LLM은 "사람이 읽기 좋은 글"을 만들도록 훈련됐지, "소프트웨어가 바로 쓸 수 있는 결정"을 내리도록 훈련된 게 아니라는 거죠. 그래서 아예 다른 종류의 모델을 만들었다는 게 이번 발표의 핵심이에요.

"시스템 원"이 뭐냐면

이름부터 짚고 갈게요. 시스템 원이라는 말은 심리학자 대니얼 카너먼의 책 『생각에 관한 생각』에서 나온 개념이에요. 사람의 사고를 두 가지로 나누는데요.

• 시스템 1: 빠르고 직관적인 판단. 상대방 표정 보고 화났는지 아는 것, 스팸 메일 제목 보고 바로 삭제하는 것.
• 시스템 2: 느리고 논리적인 사고. 수학 문제 풀기, 장문의 보고서 쓰기.

기존 LLM은 굳이 따지면 시스템 2 쪽에 가까워요. 토큰을 하나씩 만들면서 긴 글을 쓰고, 최근에는 "생각하는 과정"까지 길게 출력하잖아요. 그런데 실제 소프트웨어 자동화에서 필요한 판단의 상당수는 시스템 1이에요. "이 티켓은 결제 문제인가, 배송 문제인가?", "이 로그는 장애 징후인가?", "이 리뷰는 부정적인가?" 같은 것들이요. 이런 판단에 굳이 500단어짜리 에세이가 필요하진 않거든요.

TypeSafe AI는 바로 이 영역, 그러니까 빠르고 구조화된 판단을 전담하는 모델을 만들겠다고 한 거예요.

Jev의 핵심: 세 가지 설계 결정

발표문을 뜯어보면 Jev는 크게 세 가지 지점에서 기존 LLM과 갈라져요.

1. 문자열 생성을 포기했다

이게 제일 과감한 결정이에요. Jev는 텍스트를 생성하지 않아요. 대신 미리 정의된 타입의 구조화된 값만 출력해요.

쉽게 말하면 이런 거예요. 기존 LLM한테 "이 고객 문의를 분류해줘"라고 하면 모델은 자유롭게 문자열을 뱉어요. 잘 되면 {"category": "refund"}가 나오지만, 가끔은 물론이죠! 이 문의는 환불 관련으로 보입니다. 같은 게 나와서 파서가 깨지죠. 반면 Jev는 처음부터 "출력은 refund | shipping | account | other 중 하나"라고 정해두면, 그 네 개 밖의 값은 아예 나올 수가 없어요.

이걸 회사는 "타입 에러를 절대 내지 않는다"고 표현하는데요. 프로그래밍 언어로 비유하면 아무 값이나 넣을 수 있는 동적 언어에서, TypeScript나 Rust처럼 컴파일 시점에 타입을 강제하는 언어로 바뀐 셈이에요. 회사 이름이 TypeSafe인 이유죠.

발표문에서는 이걸 "프론티어급 지능을 가진 함수 호출"이라고 부르는데, 저는 이 표현이 꽤 정확하다고 봐요. 입력은 비정형 데이터(텍스트, 프로그램 상태), 출력은 타입이 정해진 확률적 결정. 함수 시그니처가 있는 AI인 거예요.

2. 토큰 하나씩이 아니라, 한 번에 병렬로

기존 LLM이 느린 근본적인 이유는 순차 생성이에요. 다음 단어를 만들려면 이전 단어가 필요하니까, 100토큰짜리 답을 내려면 모델을 100번 돌려야 해요. 마치 한 글자씩 받아쓰기하는 것과 같죠.

Jev는 출력할 항목이 미리 정해져 있으니까 이 순서 의존성이 없어요. 분류 결과, 신뢰도, 여러 필드 값을 한 번의 쿼리로 동시에 계산해요. 회사는 이걸 "병렬 샘플러"라고 부르고, 하드웨어 특성에 맞게 설계했다고 해요. GPU는 원래 병렬 연산에 강한데, 순차 생성은 그 강점을 제대로 못 쓰거든요.

그 결과로 주장하는 게 "비슷한 지능에 두 자릿수 배 빠르고 효율적"이에요. 두 자릿수 배라는 건 100배 수준이라는 뜻이고요. 물론 이건 시스템 1 과제에 한정된 이야기고, 회사 스스로도 "특별한 주장에는 특별한 증거가 필요하다"며 벤치마크를 공개했다고 하니, 실제 워크로드에서 검증이 필요한 부분이에요.

3. RLCD: 정직한 확률을 배우는 훈련법

여기가 기술적으로 제일 흥미로운 부분이에요. 기존 모델의 학습 방법은 크게 두 가지였어요.

• RLHF (인간 피드백 강화학습): 사람이 더 좋아하는 답변을 만들도록 훈련. ChatGPT 방식.
• RLVR (검증 가능한 보상 강화학습): 수학 문제처럼 정답을 프로그램으로 확인할 수 있는 과제로 훈련. 최근 추론 모델들 방식.

TypeSafe AI는 세 번째 길을 제안해요. RLCD (Reinforcement Learning for Calibrated Decisions), 그러니까 "보정된 결정을 위한 강화학습"이에요.

보정(calibration)이 뭐냐면, 모델이 "70% 확신해요"라고 했을 때 실제로 열 번 중 일곱 번 맞는 상태를 말해요. 지금 LLM들은 이게 잘 안 돼요. 틀린 답도 엄청 자신 있게 말하잖아요. RLHF로 훈련하면 "자신감 있게 말하는 답변"을 사람들이 더 좋아하니까 오히려 과신하는 방향으로 밀리기도 하고요.

RLCD는 정답을 맞히는 것뿐 아니라 자기 확신의 정도를 정직하게 표현하는 것 자체에 보상을 줘요. 그래서 Jev의 모든 출력에는 확률과 신뢰도 점수가 따라와요. "환불 문의일 확률 0.91, 배송 문의일 확률 0.07" 이런 식으로요.

이게 실무에서 왜 중요하냐면, 확률이 있어야 자동화의 문턱을 정할 수 있거든요. 신뢰도 0.95 이상은 자동 처리하고, 그 이하는 사람한테 넘기는 식으로요. 지금 LLM으로는 이걸 하려면 "확신도를 1~10으로 말해줘"라고 프롬프트에 써야 하는데, 그 숫자가 실제 정확도랑 거의 무관해서 별 의미가 없었어요.

"환각이 없다"는 말, 어디까지 믿어야 할까

발표문에서 "Jev는 환각을 일으킬 수 없다"고 하는데, 이건 정확히 읽을 필요가 있어요.

여기서 환각이 없다는 건 스키마 밖의 값을 지어낼 수 없다는 뜻이에요. 없는 카테고리를 만들거나, 형식을 깨거나, 요청을 거부하는 문장을 출력하는 일이 구조적으로 불가능하다는 거죠. 하지만 정해진 선택지 중에서 틀린 걸 고를 수는 있어요. 환불 문의를 배송 문의로 분류할 수 있다는 말이에요.

차이는, 틀릴 때 "얼마나 확신이 없었는지"를 함께 알려준다는 점이에요. 그러니까 정확히 말하면 "환각이 없다"기보다 "틀림이 예측 가능하고 측정 가능하다"에 가까워요. 이건 그것대로 큰 진전이지만, 마케팅 문구 그대로 받아들이면 안 되는 부분이에요.

기존 방식들과 뭐가 다른지

"구조화된 출력이면 이미 있는 거 아니야?" 하실 수 있어요. 맞아요. 비슷해 보이는 것들이 있는데, 비유로 정리해볼게요.

OpenAI의 Structured Outputs, JSON 모드: 소설가한테 "반드시 이 양식에 맞춰 써"라고 강제하는 거예요. 토큰 생성 단계에서 문법에 안 맞는 토큰을 막아요. 형식은 지켜지지만 여전히 한 글자씩 쓰고, 확률 보정은 없어요. 소설가는 여전히 소설가예요.

전통적인 분류기(BERT 파인튜닝 등): 특정 업무만 훈련받은 전문가예요. 빠르고 확률도 나오지만, 새 카테고리가 생기면 다시 학습시켜야 하고, 복잡한 문맥 이해는 약해요.

Jev: 소설가 수준의 이해력을 가진 사람한테 펜 대신 객관식 답안지만 준 거예요. 문맥은 LLM 수준으로 이해하는데, 출력은 분류기처럼 빠르고 구조화되어 있고, 확률까지 보정돼 있다는 게 주장이에요.

물론 트레이드오프도 분명해요. Jev는 글을 못 써요. 요약도, 코드 생성도, 답변 작성도 안 돼요. 그래서 이건 LLM의 대체재가 아니라, 에이전트 파이프라인 안에서 판단을 담당하는 부품이라고 보는 게 맞아요. 예를 들어 에이전트가 "다음에 어떤 도구를 호출할까?"를 정하는 라우팅 단계는 Jev가, 최종 답변 작성은 기존 LLM이 하는 식이죠.

한국 개발자에게 주는 시사점

지금 당장 써볼 만한 시나리오

한국 서비스들 상황에 대입해보면 이런 곳에 딱 맞아요.

• 고객센터 티켓 라우팅: 카카오톡 채널이나 인앱 문의가 하루 수천 건 들어오는데, 지금 GPT로 분류하고 있다면 비용과 지연 시간이 문제였을 거예요. 처리 속도가 두 자릿수 배 차이 나면 실시간 분류가 가능해져요.
• 콘텐츠 모더레이션: 커뮤니티 게시글이나 리뷰 필터링. "삭제 / 보류 / 통과"에 확률이 붙으면, 애매한 것만 운영자가 보게 할 수 있어요.
• 에이전트 라우팅: 이미 LLM 에이전트를 만들고 있다면, 도구 선택이나 의도 분류 단계만 떼어내 보세요. 전체 지연 시간의 상당 부분이 여기서 줄어요.
• 이상 탐지: 로그, 결제 패턴, 사용자 행동에서 "이거 이상한가?"를 판단하는 단계.

도입할 때 생각할 것

1. 현재 얼리 액세스예요. 프로덕션에 바로 넣을 단계는 아니에요. 대기 명단에 올려두고 API 형태를 먼저 파악하세요.
2. 자기 데이터로 보정을 검증하세요. "확률 0.9가 진짜 90% 정확한가"는 여러분의 도메인에서 직접 재봐야 해요. 한국어 데이터에서 영어만큼 보정이 잘 되는지는 별개 문제예요.
3. 스키마 설계가 곧 프롬프트 엔지니어링이 돼요. 출력 타입을 어떻게 정의하느냐가 성능을 좌우해요. 카테고리를 너무 잘게 쪼개면 확률이 분산되고, 너무 크게 잡으면 쓸모가 없어요.
4. "글을 못 쓴다"는 걸 팀에 명확히 알리세요. 기존 LLM 대체를 기대하는 사람이 분명 있을 거예요.

학습 로드맵

• 카너먼의 시스템 1 / 시스템 2 개념은 한 번 읽어두면 이번 발표뿐 아니라 요즘 AI 논의 전반을 이해하는 데 도움이 돼요.
• 캘리브레이션이라는 개념을 공부해보세요. 신뢰도 다이어그램(reliability diagram), ECE(expected calibration error) 같은 용어를 알면 "이 모델이 정직한가"를 직접 측정할 수 있어요.
• OpenAI Structured Outputs나 Pydantic 기반 출력 검증을 써본 적이 없다면 먼저 그걸 해보세요. Jev가 뭘 해결하려는지가 몸으로 느껴져요.
• 여유가 있다면 RLHF와 RLVR의 차이를 정리해보세요. RLCD가 왜 세 번째 길인지 이해가 돼요.

마무리: "말하는 AI"에서 "결정하는 AI"로

이번 발표가 흥미로운 건, LLM을 더 크게 더 똑똑하게 만드는 경쟁에서 한 발 빠져나와 "우리가 진짜 필요한 건 뭔가"를 다시 물었다는 점이에요. 채팅 모델에 계속 프롬프트를 얹어서 억지로 분류기로 쓰는 게 아니라, 처음부터 결정을 위한 모델을 만들자는 거죠.

물론 검증은 남아 있어요. "두 자릿수 배 빠르다"는 주장은 실제 워크로드에서 재봐야 하고, 얼리 액세스 단계라 API 안정성이나 가격도 아직 모르고요. 한국어 성능은 특히 직접 확인해야 해요.

그래도 방향 자체는 설득력이 있어요. 앞으로 AI 시스템은 "생각하고 말하는 큰 모델" 하나가 아니라, "빠르게 판단하는 모델"과 "천천히 생성하는 모델"을 조합하는 형태로 갈 가능성이 높거든요. 마치 사람이 시스템 1과 시스템 2를 같이 쓰듯이요.

여러분은 어떠세요? 지금 LLM을 분류나 라우팅에 쓰고 계신다면, 비용이나 지연 시간 때문에 고생한 적 있으신가요? "확률이 붙은 결정"이 있었다면 자동화할 수 있었을 업무가 떠오르시나요? 댓글로 경험을 나눠주세요.