구조화된 판단 입문: 모델에게 글 대신 정해진 판단 결과를 돌려받는 설계

한 문장으로 이해하기

구조화된 판단(Typed Decisions)은 모델에게 자유로운 문장을 받는 대신, 사람이 미리 정해 둔 형식의 판단 결과를 돌려받는 설계 방식입니다. 출처에서 소개한 형식은 세 가지입니다. 닫힌 선택지 중 하나를 고르기, 정해진 척도로 점수를 매기기, 어떤 진술이 참일 확률을 제시하기입니다.

말 두 개만 먼저 풀어 두겠습니다. 대규모언어모델(LLM, Large Language Model)은 단어를 이어 붙여 문장을 만들어 내는 AI입니다. JSON은 소프트웨어끼리 값을 주고받을 때 쓰는 정해진 표기 형식입니다. 이 글의 개념을 이해하는 데에는 이 정도면 충분하고, 프로그래밍 경험은 필요하지 않습니다.

이 글에서 다루는 구체적인 사례는 출처가 소개한 ‘제브’라는 모델입니다. 제브의 특성과 구조화된 판단이라는 설계 개념은 구분해서 읽어야 합니다. 다 읽고 나면 개념을 한 문장으로 말할 수 있고, 작동 순서를 단계로 설명할 수 있고, 어떤 일에 쓰기 어려운지 가릴 수 있습니다.

왜 필요한가

회사가 AI를 부르는 일은 결과의 성격에 따라 갈립니다. 보고서 작성이나 요약처럼 결과가 열려 있어 무엇이 나올지 미리 적을 수 없는 일이 한쪽입니다. 문의 분류나 경로 선택처럼 나올 수 있는 답을 처음부터 목록으로 적을 수 있는 일이 다른 한쪽입니다. 출처는 이 두 종류가 요구하는 출력 방식이 서로 다르다고 설명합니다.

그런데 뒤쪽 일에서도 모델이 문장이나 JSON을 쓰고, 소프트웨어가 그 글에서 값을 다시 꺼내는 절차를 거치는 경우가 많습니다. 목록 안의 한 항목이면 충분한데 글을 거쳐 가는 셈입니다.

출처에 따르면 제브는 이 구간을 줄입니다. 답의 후보가 닫힌 작업에서 생성된 글을 다시 해석하는 절차를 덜고, 돌아온 판단 결과를 코드가 바로 받아 처리할 수 있게 합니다. 다만 이것은 제브에 대한 설명이며, 구조화된 판단을 표방하는 모든 구현이 같은 속도와 비용 결과를 낸다는 뜻은 아닙니다.

어떻게 이루어지는가

1. 판단 대상이 되는 텍스트를 준비합니다. 아직 정리되지 않은 원재료입니다.
2. 질문의 형식을 앞에서 소개한 세 가지 가운데 하나로 미리 고정합니다.
3. 텍스트와 질문을 함께 모델에 넣습니다.
4. 제브는 자유 문장을 반환하지 않고, 선택 결과와 선택지별 확률 분포를 반환합니다. 내부에서 어떻게 계산하는지는 공개돼 있지 않으므로 여기서는 단정하지 않습니다.
5. 받은 쪽에서 확신도에 따라 길을 나눕니다. 확신도는 판단 결과에 함께 붙어 오는 확률 수준을 뜻합니다. 확신도가 높으면 자동 처리, 중간이면 추가 확인이나 검토 표시, 낮으면 실행을 미루고 사람이나 다른 시스템으로 넘기는 분기를 설계할 수 있습니다.

5단계가 이 설계의 쓸모를 결정합니다. 확신이 약하다는 신호가 버려지지 않고, 다음 행동을 가르는 기준으로 쓰이기 때문입니다.

하나의 예시로 따라가기

가상 예시를 하나 들겠습니다. 어떤 접수 창구에 글이 들어오면 A팀, B팀, C팀 가운데 한 곳으로 보내야 한다고 해 봅시다.

입력으로 쓸 텍스트는 접수된 글 자체입니다. 질문은 “이 글은 A·B·C 중 어디로 가야 하는가"로 고정하고 선택지를 그 셋으로 닫습니다. 여기서 모델에게 문장을 받으면, 소프트웨어는 그 문장을 다시 읽어 팀 이름을 꺼내야 합니다. 목록 밖의 표현이나 형식 오류가 생기면 소프트웨어가 값을 해석하지 못할 수 있습니다.

이 예시에서 제브와 같은 반환 방식을 적용하면, 돌아오는 것은 세 항목에 붙은 확률입니다. 설명을 위해 임의로 지어낸 값으로, 실제 성능 수치가 아닙니다. 예컨대 B가 0.92, A가 0.05, C가 0.03으로 돌아왔다고 하겠습니다.

이 값으로 분기를 만듭니다. 여기서 쓰는 임계값은 자동 처리와 사람 확인을 가르는 기준값을 말합니다. 역시 임의로 잡은 설명용 기준인데, 0.9를 넘으면 B팀으로 바로 보내고, 0.5에서 0.9 사이면 보내되 검토 표시를 남기고, 0.5보다 낮으면 사람에게 넘깁니다. 실제로 쓸 임계값은 짐작으로 정하는 것이 아니라 자기 업무 데이터로 검증한 뒤에 정해야 합니다.

그리고 0.92라는 숫자가 “열 번 중 아홉 번쯤 맞는다"는 뜻인지는 이 단계에서 아직 알 수 없습니다. 왜 그런지는 다음 단원에서 이어 봅니다.

언제 쓰고 언제 쓰지 않는가

쓸 수 있는 조건은 하나로 모입니다. 나올 수 있는 답을 미리 목록이나 척도로 적을 수 있어야 합니다. 분류, 경로 선택, 승인과 보류, 사람에게 넘길지 여부가 여기에 들어맞습니다. 반대로 보고서나 코드처럼 결과가 열린 작업에는 맞지 않습니다. 출처에서 소개한 제브는 자유 형식의 결과물을 작성하거나 자기 판단 과정을 설명하는 용도의 모델이 아닙니다.

가장 쉽게 생기는 오해는 형식과 내용을 섞어 보는 것입니다. 출력이 정해진 형식을 지킨다는 사실과 그 판단이 맞다는 사실은 서로 다른 문제이고, 허용된 형식 안에서도 틀린 선택은 나옵니다. 앞의 가상 예시로 말하면, B가 아닌 글을 B로 0.92와 함께 돌려줄 여지는 그대로 남아 있습니다.

덧붙여 짚을 것이 두 가지입니다. 첫째, 성능은 업무마다 다릅니다. 제브의 공개 비교에서도 업무별로 차이가 달랐고, 제시된 송장 처리 결과에서는 비교 모델과 17.3%포인트 차이가 났습니다. 이 수치는 그 업무의 결과일 뿐 다른 업무로 옮겨 적용할 수 없습니다. 둘째, 돌려받은 확률의 품질이 아직 공개 검증을 거치지 않았습니다. 보정(calibration) 곡선, 즉 모델이 말한 확률이 실제 적중률과 얼마나 들어맞는지 보여주는 자료와 사람이 만든 정답 데이터에 기반한 제3자 검증 결과는 출처 작성 시점에 공개되지 않았습니다.

그래서 도입 순서는 이렇게 잡는 편이 안전합니다. 먼저 자사의 모델 호출 가운데 선택지가 닫히는 작업이 어느 정도인지 파악해 적용 가능 범위를 추정합니다. 이는 절감액을 확정하는 계산이 아니라 적용 범위를 가늠하는 단계입니다. 다음으로 해당 업무에서 사람이 표시한 정답 데이터를 모아 판단 정확도와 확률의 보정 상태를 확인합니다. 자동 처리 여부와 임계값은 그 검증을 마친 뒤에 정해야 합니다.

핵심 정리와 확인문제

구조화된 판단은 답의 후보가 닫힌 일에서 글을 거치지 않고 미리 정한 형식의 판단 결과와 확률을 받아 코드가 분기하게 하는 설계입니다. 정해진 형식을 지킨다는 것과 판단이 옳다는 것은 다른 문제이며, 효과도 업무와 구현에 따라 다릅니다. 확률을 믿고 쓰려면 자사 데이터 검증이 앞서야 합니다.

확인문제

1. 구조화된 판단을 적용할 수 있는 업무의 조건은 무엇인가요?
2. 구조화된 판단이 이루어지는 순서를 입력 준비부터 후속 분기까지 설명해 보세요.
3. 자동 처리 임계값을 정하기 전에 해야 할 일은 무엇인가요?

정답과 해설

1. 정답: 나올 수 있는 답을 미리 목록이나 척도로 적을 수 있는 업무여야 합니다. 해설: 분류나 승인 여부처럼 후보가 닫히는 일에는 맞지만, 보고서 작성처럼 결과가 열린 일에는 맞지 않습니다. 출처에서 소개한 제브는 자유 형식의 글을 작성하는 용도가 아닙니다.
2. 정답: 판단 대상 텍스트를 준비하고, 질문 형식을 세 가지 중 하나로 고정하고, 둘을 함께 모델에 넣고, 정해진 형식의 선택 결과와 확률 분포를 돌려받고, 확신도에 따라 자동 처리·추가 확인·사람 이관으로 분기합니다. 해설: 출처에서 소개한 제브는 정해진 출력 형식과 범위 안에서 결과를 반환하지만, 그 결과의 정확성까지 보장하는 것은 아닙니다. 그래서 마지막 분기 단계가 중요합니다.
3. 정답: 해당 업무에서 사람이 표시한 정답 데이터로 판단 정확도와 확률의 보정 상태를 확인해야 합니다. 해설: 보정 곡선과 제3자 검증 결과가 공개되지 않았기 때문에, 확인 없이 확률만 보고 임계값을 정하면 잘못된 자동 처리를 걸러내지 못할 수 있습니다.

참고자료

• 구조화된 판단 입문 참고자료
• 구조화된 판단 입문 참고자료
• 구조화된 판단 입문 참고자료