LLM 없이도 정확한 정부 지원금 자동 판정
목차
정부 지원금 자격 판단을 LLM에서 규칙 기반 파서로 전환했다. 자동 매칭 도구의 신뢰도를 높이기 위한 결정이었다.
왜 LLM을 걷어냈는가
처음에는 LLM을 활용한 자격 판단이 좋아 보였다. 복잡한 정부 정책 문서를 자연어로 읽고 사용자 정보와 매칭하는 것이 유연해 보였으니까. 그런데 실제로 운영해 보니 몇 가지 문제가 드러났다.
첫째, 비용 구조가 맞지 않았다. 매번 API 호출이 들어가니 특정 시간대에 부하가 몰릴 때 비용이 급증했다. 사용자가 지원 프로그램을 찾는 것이 "한 번의 요청"이 아니라 종종 반복되는 과정이라는 걸 간과했다.
둘째, 응답 시간이 일관되지 않았다. LLM은 기본적으로 생성형 모델이라 출력 토큰이 많아질수록 레이턴시가 늘어난다. 정부 지원 대상자 조회는 빠르게 응답이 와야 하는 중요한 사용자 경험인데, 가끔 5초 이상 기다리게 되는 상황이 있었다.
셋째, 정책 변화에 대응이 어려웠다. 정부 정책은 자주 바뀐다. 프롬프트를 계속 수정해야 했는데, 프롬프트가 길어질수록 모델 동작이 예측 불가능해졌다. 특히 부정 조건(예: '21세 이상이면서 특정 소득 이하가 아닌 경우') 같은 복잡한 논리를 다룰 때 환각이 발생하곤 했다.
넷째, 감사 추적(audit trail)이 부족했다. "왜 이 사용자가 이 프로그램에 매칭되었나"를 설명하기가 어려웠다. LLM 응답은 "그럴듯한" 설명을 주지만, 정부 지원금 판정처럼 정당성이 중요한 영역에서는 "이 규칙 항목 1번, 항목 2번을 만족했으므로"라는 명확한 근거가 필요했다.
규칙 기반 파서로의 전환
그래서 결국 다시 기본으로 돌아갔다. 정부 정책 문서를 읽고 명시적인 판단 규칙으로 정리한 뒤, 파서를 만들었다.
extract_eligibility_parse.py 는 각 정부 프로그램의 자격 조건을 구조화된 규칙으로 선언한다. 예를 들어:
프로그램 A: [나이 >= 18, 나이 < 65] AND [월소득 <= 300만원] OR [기초생활수급자]
프로그램 B: [장애인 등록] AND [거주 기간 >= 2년]
이런 식으로 AND, OR, NOT 조합으로 나타낼 수 있는 조건이면 모두 표현 가능하다. 복잡하면 복잡할수록 규칙 엔진이 확실하게 동작한다. 애매함이 없다.
gov/db.py 에서는 이 규칙들을 데이터베이스에 저장하고, 사용자 정보 조회 시 규칙 엔진이 조건을 평가한다. 각 조건별로 매칭 여부를 기록하므로 나중에 "왜 이 프로그램에 해당하는가"를 투명하게 설명할 수 있다.
팀 관점에서의 선택
이 변경을 결정할 때 팀과 함께 고민한 부분은 이거였다: 정책의 복잡도 증가가 유지보수를 힘들게 하지 않을까?
초반에 규칙이 20개 정도면 괜찮겠지만, 정부 프로그램이 계속 추가되고 조건이 세분화되면 100개, 200개로 늘어날 수 있다는 우려가 있었다.
하지만 반대로 생각해 보니, LLM 기반이어도 복잡도는 같다는 걸 깨달았다. 다만 LLM은 그 복잡도를 프롬프트 속에 숨기고 있었을 뿐이다. 규칙 기반은 복잡도가 명시적으로 보이는 것일 뿐이다. 오히려 이렇게 명시적이어야 코드 리뷰도 쉽고, 정책 담당자와 개발자가 함께 변경점을 검증할 수 있다.
또한 규칙 엔진은 테스트 작성이 훨씬 간단하다. "사용자 X는 프로그램 A, C, E에 해당한다"는 테스트를 작성하면 된다. 매번 LLM 응답의 비결정성(non-determinism)으로 인한 플레이키 테스트를 고민할 필요가 없다.
성능과 신뢰성의 확보
LLM-free 파서로 전환하니 응답 시간이 밀리초 단위로 떨어졌다. 데이터베이스 쿼리 몇 개 + 메모리 내 규칙 평가인데, 이건 네트워크 호출 없이 로컬에서 처리되니까.
비용도 거의 0에 수렴했다. API 호출이 없으니까.
가장 중요한 것은 신뢰성이다. LLM은 확률 모델이므로 같은 입력이라도 다른 답을 줄 수 있다(샘플링 온도가 0이 아닌 한). 하지만 규칙 기반 파서는 결정론적(deterministic)이다. 같은 사용자 정보가 들어오면 항상 같은 매칭 결과가 나온다.
정부 지원금은 공정성이 중요하다. "어제는 해당했는데 오늘은 안 된다"는 상황은 절대로 일어나면 안 된다.
회고: 언제 LLM이 정답인가
이 작업을 하면서 깨달은 건, "자유도가 높은 의사결정이 필요한가, 아니면 명확한 규칙인가"의 차이다.
사용자가 작성한 자유로운 텍스트를 분류하거나, 복잡한 문맥을 이해해야 할 때는 LLM이 맞다. 하지만 "조건 A, B, C를 만족하면 매칭된다"처럼 논리가 명시적일 때는 규칙 엔진이 답이다.
초기 프로토타입 단계에서는 LLM으로 빨리 검증하는 것도 좋은 전략이다. "이게 정말 필요한 기능인가"를 확인한 뒤, 그 다음 단계에서 규칙 기반으로 최적화하는 식으로.
이번 자동 매칭 도구도 처음부터 규칙 파서로 설계했으면 초기 구현이 더 오래 걸렸을 텐데, LLM으로 빠르게 프로토타이핑하고 실제 필요성을 검증한 뒤에 규칙 기반으로 전환한 게 올바른 순서였다고 본다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.