AI 답이 길면 돈이 새요 | 시스템 연동 요구사항 5가지

핵심 요약

• 전 OpenAI 연구원 디오고 알메이다(Diogo Almeida)가 세운 TypeSafe AI가 사람 말 대신 정해진 결정값과 그 확률만 돌려주는 모델 Jev를 공개했어요.
• 회사 발표 기준 응답은 0.07～0.5초, 요금은 입력 100만 토큰당 0.042달러이고 출력 토큰은 따로 받지 않아요.
• 소식의 요지는 “기계끼리 주고받는 답은 짧아야 한다”예요. 새 모델을 쓰지 않더라도 AI를 시스템에 붙일 때 요구사항에 적을 것은 똑같아요.
• 직접 만들고 운영해본 개발사 기준으로, 발주 전에 정해 둘 5가지를 정리했어요.

📰 2026년 9월 20일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

“이 문의가 환불 요청인가요, 배송 문의인가요?”

사람이라면 한 단어로 답할 질문이에요. 그런데 LLM(대형 언어 모델)에 물으면 “이 문의는 고객이 상품 수령 후…”로 시작하는 문단이 돌아오기 일쑤예요. 사람이 읽는 화면이라면 친절한 답이지만, 그 답을 받아 다음 작업을 돌려야 하는 프로그램에게는 비용이고 골칫거리예요.

---

1. 무슨 소식인가요

CIO가 9월 17일 전한 InfoWorld 기사와 TypeSafe AI 공식 블로그(9월 15일)를 기준으로 정리했어요.

항목	확인한 내용
회사	TypeSafe AI, 창업자는 RLHF(사람 피드백으로 모델을 다듬는 학습법) 공동 개발자로 알려진 전 OpenAI 연구원
모델	Jev — 회사는 “System One 모델”이라는 새 분류로 소개해요
입력	작업·업무 흐름의 상태(텍스트와 구조화된 프로그램 데이터)
출력	미리 정한 결정값 하나와 그 확률
속도	70～500ms, 회사가 시험한 LLM은 수 초(공식 블로그 기준 3～329초)
요금	입력 100만 토큰당 0.042달러, 출력은 “재기에도 너무 싸다”며 무료
제공 방식	한 지역에서만 호스팅 서비스로 운영, 대기 명단을 받아 순차 개방

회사가 든 쓰임새는 요청 분류, 기록 점수 매기기, 다른 AI가 낸 답 검사 같은 짧은 판단이에요. 공식 블로그엔 실제 업무 흐름에서 “193.6배 빠르고 444.6배 싸다”는 수치도 있는데, 회사 스스로 상한에 가까운 사례라고 적어 뒀어요. 우리 업무에서도 그만큼 나온다고 읽으면 안 돼요.

공식 외부 기준 — CIO/InfoWorld “TypeSafe AI’s new models work with machines, not humans”(Anirban Ghoshal, 2026년 9월 17일), TypeSafe AI 블로그 “Introducing System One Models & Jev”(2026년 9월 15일). 수치는 모두 회사 발표이고, 저희가 직접 측정한 값은 아니에요.

2. 짧게 답해도 될 일에 LLM은 왜 길게 답할까요

LLM은 사람과 대화하도록 다듬어졌기 때문이에요. 설명을 붙이고 근거를 들고 예의를 차리는 게 사람에게는 좋은 답이에요.

문제는 기업이 AI를 쓰는 자리가 점점 대화창 밖으로 옮겨 간다는 점이에요. 문의를 분류해 담당 부서로 보내고, 주문 건에 위험 점수를 매기고, 다른 AI가 쓴 글을 검사하는 일은 결과를 사람이 아니라 다음 프로그램이 받아요. 기사 속 컨설턴트 데이비드 린티컴(David Linthicum)은 이런 예/아니오 판단에 범용 LLM을 쓰는 걸 “예/아니오 라우팅 질문 하나에 기업용 통합 버스 전체를 돌리는 것”에 빗댔어요.

사내 AI 에이전트처럼 한 작업 안에서 모델을 여러 번 부르는 구조라면 손해가 겹쳐요. 호출마다 길어진 답이 비용과 대기 시간으로 쌓이거든요.

3. 사람이 읽을 답과 프로그램이 받을 답은 무엇이 다른가요

같은 AI라도 결과를 누가 받느냐에 따라 좋은 답의 기준이 정반대예요.

구분	사람이 읽는 답	프로그램이 받는 답
좋은 답	맥락과 이유가 담긴 설명	정해진 칸에 정해진 값
길이	길어도 괜찮아요	짧을수록 싸고 빨라요
어긋나면	사람이 알아서 걸러 읽어요	파싱(데이터 해석)이 깨져 다음 단계가 멈춰요
확신이 없을 때	”아마도”라고 쓰면 돼요	기준에 못 미치면 사람에게 넘겨야 해요

기사에서도 이 차이를 짚어요. 지금은 개발자가 범용 LLM의 답을 프로그램이 믿고 쓸 수 있도록 프롬프트·형식 정의·검사·재시도·예외 처리를 여러 겹 둘러싸고 있다는 거예요. Jev 같은 모델은 그 겹을 줄이자는 시도고요.

4. 요구사항에 적어야 할 5가지

어떤 모델을 쓰든 AI를 시스템에 붙이는 프로젝트라면 요구사항 정의서에 아래 다섯 줄은 있어야 해요.

#	항목	요구사항에 적는 예
1	출력 형식(스키마)	{ "category": 문자열, "confidence": 0～1 숫자 } 외의 글자는 받지 않아요
2	허용값	category는 환불·배송·계정·기타·판단보류 다섯 개만
3	확신도 기준과 넘기는 곳	confidence 0.8 미만이거나 판단보류면 상담팀 대기열로
4	실패 처리	형식이 어긋나면 1회 재요청, 또 어긋나면 판단보류로 기록하고 알림
5	토큰 예산	한 번 답은 출력 20토큰 이하, 하루 호출 상한과 월 예산 상한

2번에서 판단보류를 빼먹는 경우가 많아요. 선택지를 네 개만 주면 AI는 애매한 건도 넷 중 하나에 억지로 끼워 넣어요. 3번에서 누가 어떻게 넘겨받을지는 AI가 틀린 답을 내놓았을 때 정해둘 3가지에서 자세히 다뤘어요.

기사 속 HyperFrame Research의 스테파니 월터(Stephanie Walter)도 같은 점을 짚었어요. 정해진 결정값을 돌려받으려면 질문, 가능한 답, 기준값, 넘기는 경로를 개발자가 미리 정해야 하고, 그게 적지 않은 일이라는 거예요. 모델이 알아서 해 주는 부분이 아니라 발주 단계에서 정할 일이라는 뜻이에요.

5. 답 길이가 청구서에 붙는 방식

숫자로 보면 차이가 더 잘 보여요. 아래는 계산을 위해 세운 가정이에요.

• 하루 1만 건의 문의를 분류하고, 한 달을 30일로 봐요.
• 문장형으로 답하면 한 번에 300토큰, 정해진 값만 받으면 10토큰이라고 해요.

방식	월 출력 토큰
문장형 답	300 × 10,000 × 30 = 9,000만
정해진 값만	10 × 10,000 × 30 = 300만

같은 판단인데 출력 토큰이 30배 차이 나요. TypeSafe AI 블로그는 기존 LLM의 출력 토큰이 입력보다 약 5배 비싸다고 적었어요. 모델마다 단가는 다르지만, 비싼 쪽 토큰을 줄이는 셈이라 절감 폭이 커요.

모델을 고를 때의 단가 비교는 벤치마크 1등 모델이 청구서도 1등일까요에서, 오픈 뒤 늘어나는 운영비 항목은 AI 기능 붙인 뒤 운영비에서 따로 정리했어요. 이 글에서 짚는 건 그보다 앞 단계, 답의 모양을 정하는 일이에요.

6. 새 모델을 바로 써도 될까요

아직은 지켜볼 단계예요. 기사에 나온 전문가들의 지적을 모으면 이래요.

• 한 지역에서만 운영돼요. 데이터를 어느 나라에 두는지 따져야 하는 회사라면 먼저 걸리는 조건이에요.
• 대기 명단을 받는 초기 서비스예요. Broadcom의 어드베이트 파텔(Advait Patel)은 보안, 데이터 보관 위치, 서비스 수준 약속, 특정 업체에 묶이는 문제를 짚었어요.
• 확률은 이유를 말해 주지 않아요. Doozer AI의 폴 차다(Paul Chada)는 규제 업종이라면 “왜 그렇게 판단했는지” 설명하기 어려울 수 있다고 했어요.
• 확률의 뜻은 우리 데이터로 다시 재야 해요. 0.8이 우리 업무에서 실제로 몇 번 중 몇 번 맞는지는 직접 시험해 봐야 알아요.

파텔은 기업이 핵심 업무가 아닌 사내 자동화부터 시작해 효과를 재 볼 거라고 내다봤어요. 저희 생각도 같아요. AI 에이전트 도입을 검토 중이라면 지금 쓰는 모델에서 출력 형식부터 좁혀 보고, 짧은 판단이 호출의 대부분을 차지한다는 게 숫자로 확인되면 그때 전용 모델을 시험해 보는 순서가 무리가 없어요.

7. 운영해 보면 달라지는 것

AI를 붙인 기능이 오픈 뒤 멈추는 이유는 모델이 틀려서보다 답의 모양이 한 번 어긋나서인 경우가 많아요. 쉼표 하나, 따옴표 하나가 빠진 답이 들어오면 받는 쪽 코드가 멈추고, 그 뒤로 쌓인 작업이 같이 밀려요.

자체 SaaS 4종을 직접 운영하면서 저희가 지키는 원칙도 여기서 크게 다르지 않아요. 다른 곳에서 넘어오는 데이터는 형식부터 고정하고, 어긋난 값은 조용히 넘기지 않고 기록하고, 모르는 건 모른다고 적을 칸을 둬요. AI가 보내는 답도 결국 넘어오는 데이터라서, 모델이 바뀌어도 이 세 가지는 그대로 남아요.

우리 업무에 AI를 붙이면 어떤 답을 받아야 하는지 정리해 보고 싶다면 출력 형식부터 같이 정해 볼게요 →

저희는 10년 넘게 50개 이상의 프로젝트를 만들어 왔고, 롯데·캐논 같은 곳의 시스템을 개발한 경험과 자체 서비스를 매일 운영하는 경험을 함께 가진 개발사예요.

8. 자주 묻는 질문

지금 쓰는 LLM으로도 짧은 구조화 답을 받을 수 있나요?

받을 수 있어요. 요즘 주요 모델은 정해진 JSON 형식으로 답하게 하는 기능을 대부분 갖고 있어요. 다만 형식이 어긋나는 경우가 드물게라도 생기니, 검사하고 다시 요청하는 처리를 요구사항에 함께 적어 두는 편이 안전해요.

허용값을 정해 두면 AI가 애매한 건을 억지로 끼워 맞추지 않을까요?

그래서 ‘판단 보류’ 같은 값을 허용값에 꼭 넣어요. 확신도가 기준보다 낮거나 보류가 나오면 사람에게 넘기도록 정해 두면, 억지로 고른 답이 그대로 다음 단계로 흘러가는 일을 막을 수 있어요.

AI 자체 도입과 외주 개발 중 어떤 선택이 맞나요?

AI 호출 자체보다 그 결과를 받아 쓰는 기존 시스템을 누가 잘 아느냐로 갈려요. 사내에 연동 대상 시스템을 다루는 개발자가 있으면 자체 도입이 빠르고, 없다면 출력 형식과 실패 처리까지 설계할 수 있는 외주사를 찾는 편이 오픈 뒤 비용을 줄여요.

9. 마무리

이번 소식에서 기억할 숫자는 0.07～0.5초와 0.042달러예요. 둘 다 “기계에게는 짧은 답이면 충분하다”는 전제에서 나온 숫자예요.

새 모델을 당장 쓰지 않아도 가져갈 건 있어요. 우리 시스템에서 AI를 부르는 곳을 적어 보고, 그 답을 사람이 읽는지 프로그램이 받는지부터 나눠 보세요. 프로그램이 받는 곳이라면 위 다섯 줄이 요구사항에 들어가 있는지 확인하면 돼요.

함께 보면 좋은 글

• 요구사항 정의서·RFP 작성 가이드
• AI 프로젝트, 외주와 자체 개발 중 무엇이 맞을까요
• AI가 틀린 답을 내놓았을 때 — 서비스에 넣기 전 정해둘 3가지