TL;DR — 제조 부품 신뢰성 시험 약 114종을 한정된 시험 장비에 배치하는 시험계획 자동 생성 케이스다. 핵심은 "LLM이 일정을 짜준다"가 아니라 "전용 제약 스케줄링 최적화 모듈이 일정을 계산하고 LLM은 그 결과를 계획서로 서술만 한다"는 책임 분리다. 장비=자원, 시험=작업, 가동시간·잔여면적·여유율·우선순위=제약인 자원제약 스케줄링(RCPSP) 문제이며 RAG가 아니다. 사양 → 시험항목 식별 → 마스터 조회 → [최적화 모듈] 최적 배치 → [LLM] 계획서 서술 → 검증·반영 목표는 일정 충돌 0 · 제약 위반 0 · 같은 입력에 같은 일정(재현성 100%). 이 한 케이스가 Planning·Tool Use·HITL·Evaluation을 핵심으로 여러 에이전틱 패턴을 동시에 요구한다.
1. 완전 자동 생성을 포기한 이유
"시험 의뢰서를 LLM에 넣으면 일정을 알아서 짜주지 않을까?" — 이 케이스를 검토할 때 가장 먼저 나온 기대였고 가장 먼저 접어야 했던 기대이기도 하다. 제조 부품의 신뢰성 시험은 내열·내광·진동·화학성능처럼 종류가 많고 각 시험은 정해진 장비(예: 항온항습기)를 일정 시간 점유한다. 결국 "어떤 시험을 언제, 어느 장비에서 돌릴 것인가"는 장비라는 한정 자원 위에 마감과 우선순위를 얹어 푸는 조합 최적화 문제다. 설계서의 핵심 비고가 못박은 결론도 같았다 — "LLM이 복잡한 수식 계산을 자체적으로 못할 경우 해당 알고리즘(최적화 모듈)을 개발한다." 즉 이 시스템의 정체성은 완전 자동 생성이 아니라, 전용 제약 스케줄링 최적화 모듈이 일정을 계산하고 LLM은 그 결과를 계획서로 서술만 한다는 책임 분리다.
자동화를 거절한 이유는 세 가지로 정리된다. 첫째, 일정은 책임 데이터다. 장비가 겹치거나 마감이 깨진 '거짓 일정'이 그대로 시험관리 플랫폼에 반영되면 시험 라인 자체가 멈춘다. 일정은 감상이 아니라 현장 자원을 움직이는 명령이므로 한 줄의 오류가 실물 손실로 직결된다. 둘째, 제약 검증이 불가능하다. LLM은 자신이 내놓은 일정이 가동시간·여유율·우선순위를 어겼는지를 스스로 증명하지 못한다. 셋째, 비결정성이다. 같은 입력에 매번 다른 일정을 내놓으면 인수검수나 분쟁 상황에서 "그때 왜 이렇게 짰는가"를 재현할 수 없다. 계산과 검증과 재현 — 이 셋이 동시에 깨지는 영역에 자유 서술형 LLM을 두는 것은 설계가 아니라 도박에 가깝다.
현실의 모습을 떠올리면 경계가 더 또렷해진다. 베테랑 생산관리 선배가 장비 점유 화이트보드를 펴 놓고 "이 항온항습기 이 날 비어? 이 시험 먼저 끝나야 저게 들어가지" 하며 충돌을 손으로 풀어내는 장면 — 그 손놀림이 곧 최적화 모듈이 하는 일이다. 최적화 모듈은 빈 슬롯을 찾고 선행 관계를 따지고 마감을 넘기지 않는 배치를 탐색한다. 반면 같은 일을 LLM에게 통째로 맡기면 문장은 매끄럽고 표는 그럴듯하지만 장비가 겹치고 마감을 넘긴 자신만만한 거짓 일정을 내놓기 쉽다. 읽기 좋은 거짓말이 가장 위험한 종류의 오류다.
물론 이 선택에 공짜는 없다. 최적화 모듈을 도입하고 제약을 모델링하는 추가 공수가 들고 어떤 최적화 모듈(예: CP-SAT, MILP, 또는 메타휴리스틱)를 쓸지 기술검토(PoC)가 선행돼야 한다. 그럼에도 이 케이스를 골라 소개하는 이유는 분명하다. 결정성이 사실상 인수검수 수준으로 요구되는 도메인에서는 "LLM이 다 해준다"는 발상이 가장 위험하기 때문이다. 계산은 검증 가능한 최적화 모듈에 맡기고 서술은 언어에 강한 LLM에 맡기는 — 이 단순하지만 단단한 책임 분리가, 다음 섹션부터 풀어낼 전체 설계의 출발점이다.
2. 시험 114종과 네 가지 제약
발주사(현업)는 제조 부품을 양산 승인 전에 신뢰성 시험을 통과시켜야 한다. 내열·내광·진동·화학성능처럼 성격이 전혀 다른 시험이 약 114종(원천 설계 문서에 "시험항목 약 114개, 확정 협의 중"으로 기재된 미확정 수치)에 이르며 각 시험은 전용 시험 장비를 일정 시간 점유한다. 시험계획을 짠다는 것은 결국 이 114종을 한정된 장비에 시간 축으로 배치하는 일이다. 시험 한 건을 옮기면 그 장비를 쓰는 다른 시험이 밀리고 장비 가동 한도와 마감일이 함께 흔들리기 때문에 "한 건씩 손으로" 풀기에는 결합도가 너무 높다.
시작점은 사양구성도다. 사양구성도는 공정기획 시스템에서 생성되어 시험관리 플랫폼으로 연계 수신되며 프로젝트 → 완성 부품 → 설계변경의 계층 구조를 가진다. "이 부품에 도대체 어떤 시험이 필요한가"를 식별하는 최초 입력이 바로 이 사양구성도이고 여기서 부품별 시험 목록이 펼쳐진다. 이 입력이 부정확하면 뒤의 어떤 최적화도 의미가 없기 때문에, 설계상 사양 수신과 시험리스트 추출을 가장 앞 단계에 둔 것이다.
문제가 까다로운 진짜 이유는 제약이 하나가 아니라 네 가지가 동시에 작용한다는 데 있다. ①시간 — 장비 가동시간, 주말·공휴일 제외, 단계별 소요일을 모두 지켜야 한다. ②공간 — 장비의 잔여면적과 포화율이 한정되어 있어 무한정 밀어 넣을 수 없다. ③가동 — 정기 점검·돌발 대응을 위한 여유율 30%를 남겨, 장비 포화율을 70% 이하로 유지해야 한다. ④우선순위 — 마감월을 먼저 맞출지, 제출일을 먼저 맞출지를 사용자가 선택한다. 이 네 제약은 서로 맞물려서, 시간을 양보하면 가동률이 깨지고 가동률을 지키면 마감이 밀리는 식으로 충돌한다. 그래서 "규칙 몇 개로 정렬"이 아니라 제약을 동시에 만족시키는 탐색이 필요하다.
전체 처리는 10단계로 이어진다. 화면에서 시험의뢰를 등록하고 배치기준을 입력해 월별로 배치한 뒤 [계획 생성]을 클릭하면, 백엔드에서 AI 에이전트가 시험리스트를 추출·정규화하고 시험항목·장비 마스터를 조회한 다음 스케줄링 최적화(최적화 모듈)로 일정을 계산한다. 이어 계획서 생성(LLM)이 그 결과를 문서로 서술하고 결과를 시험관리 플랫폼으로 전송하면 플랫폼이 DB 검증·갱신·충돌 재검증을 거쳐 자동 배치 결과를 캘린더에 반영한다. 사용자가 직접 보는 화면은 의뢰 등록·계획 요청·자동 배치 캘린더 단 3개뿐이고 나머지는 전부 백엔드에서 돌아간다. 화면을 최소화한 것은, 사람이 끼어들 지점을 "입력"과 "확인"으로 좁혀 자동화의 신뢰 경계를 분명히 하기 위해서다.
여기서 가장 흔한 오해가 등장한다. "시험 목록과 장비 목록을 통째로 LLM에 넣고 일정 짜달라고 하면 되지 않나?"라는 생각이다. 결론부터 말하면 안 된다. 첫째, 조합 폭발이다. 114종 × 장비 × 기간의 배치 경우의 수는 NP-hard 탐색공간이라, 한 번의 프롬프트로 최적해를 찾는 것은 원리적으로 불가능하다. 둘째, 제약 위반을 검증할 수 없다. LLM은 가동시간이나 여유율 70% 같은 수치 제약을 토큰 예측으로 "지켰다고 말할" 뿐, 실제로 지켰는지 보장하지 못한다. 셋째, 재현성이 없다. 같은 입력을 넣어도 매번 다른 일정이 나오면, 현업이 검수할 때 같은 결과를 재현할 수 없어 신뢰 자체가 성립하지 않는다.
3. 두 개의 엔진 — 최적화 모듈과 LLM
전체 흐름은 시험의뢰 등록부터 캘린더 반영까지 이어지는 10단계의 단일 직선 파이프라인처럼 보인다. 그러나 그 안에는 성격이 근본적으로 다른 두 개의 엔진이 들어 있다. 하나는 스케줄링 최적화 단계로, 장비라는 자원에 시험이라는 작업을 배치하는 결정론적 수치 최적화(조합최적화·제약충족)다. 다른 하나는 계획서 생성 단계로, 그 배치 결과를 사람이 읽을 문서로 옮기는 비결정론적 자연어 생성(LLM)이다. 같은 파이프라인에 놓여 있다는 이유로 둘을 한 덩어리로 보면 설계가 무너진다.
이 케이스 아키텍처의 1차 근거는 바로 이 지점이다. 원천 설계가 두 엔진을 별도 단계·별도 책임으로 명확히 끊어 두었다는 사실 자체가 설계 의도다. 최적화 모듈은 "같은 입력이면 같은 일정"을 보장해야 하고 제약 위반은 0이어야 하는 반면, LLM은 표현이 매번 조금씩 달라도 무방하다. 한쪽은 정답이 수학적으로 정의되고 다른 쪽은 정답이 가독성과 정확한 인용으로만 평가된다. 검증 기준도, 실패 모드도, 기술 스택도 다른 두 작업을 같은 책임으로 묶으면 어느 한쪽의 품질 기준이 반드시 희생된다.
이 분리를 행위자 관점으로 펼치면 다섯 개의 레인(lane)이 된다. ①사용자(시험담당)가 시험을 의뢰하고 옵션을 지정한다. ②시험관리 플랫폼이 의뢰를 받아 AI 에이전트에 계획 생성을 요청하고 결과를 화면·DB·캘린더에 반영한다. ③AI 에이전트는 시험리스트 추출·정규화, 마스터 조회, 오케스트레이션, 그리고 마지막 LLM 서술을 담당한다. ④스케줄링 최적화 모듈·최적화 엔진이 ★별도 레인으로 일정을 계산한다. ⑤마스터 DB가 시험항목과 장비 스케줄을 제공한다. 여기서 의도적 결정은 최적화 모듈을 AI 에이전트와 같은 레인에 두지 않고 다섯 번째 레인으로 떼어 낸 것이다.
왜 떼어 내는가. 최적화 모듈을 AI 에이전트 레인에 묶어 버리면 결정성·재현성·기술 스택의 근본 차이가 도식에서 은폐되기 때문이다. LLM 기반 에이전트와 OR 최적화 모듈은 검증 방법도, 장애 복구 전략도, 필요한 인력의 전문성도 전혀 다르다. 원천 설계가 최적화 모듈에 대해 "에이전트 개발과 별개로 기술검토가 필요하다"고 명시한 것은 이 두 기술을 같은 트랙으로 다루면 안 된다는 신호다. 레인을 분리해 두어야 최적화 모듈 선정(CP-SAT·MILP·휴리스틱 중 무엇을 쓸지)을 에이전트 구현과 독립적인 의사결정으로 보존할 수 있다.
한편 통합 테스트의 무게중심은 다른 곳에 있다. AI 에이전트 ↔ 시험관리 플랫폼이라는 두 컴포넌트가 맞닿는 경계가 회귀 검증의 단일 핵심 지점이다. 이 경계는 두 군데에서 교차한다. (1) 요청 계약은 시험의뢰ID·사양구성도ID·사용자 옵션(여유율·주말계획·우선순위·시험일정)·장비정보를 에이전트로 보내는 약속이고 (2) 응답 계약은 산출된 시험계획 데이터와 기존일정 변경내역을 2채널로 분리해 플랫폼이 돌려받는 약속이다. 특히 "기존일정 변경내역을 신규/변경 2채널로 분리 처리"하는 부분이 통합 리스크가 집중되는 지점이다 — 새로 잡힌 일정과 밀려난 기존 일정을 한 페이로드에 섞으면 플랫폼 쪽 반영 로직이 어느 것이 변경분인지 구분하지 못한다.
의뢰ID·사양ID·옵션·장비정보
시험계획 / 변경내역 2채널
4. 스케줄링을 OR 문제로 정형화
앞 절에서 "최적화 모듈이 일정을 계산한다"고 했지만 최적화 모듈은 자연어를 이해하지 못한다. 최적화 모듈에 일을 시키려면 먼저 시험 일정 배치를 운영연구(Operations Research)의 정형 문제로 번역해야 한다. 번역의 핵심은 세 가지를 수학적 객체로 환원하는 일이다. 첫째 자원(Resource)은 시험 장비로, 각 장비는 일별 가동시간·잔여 면적·보유 가능한 시험 차원(Dimension)이라는 용량 속성을 갖는다. 둘째 작업(Job)은 각 시험항목으로, 소요일수·선후 순서·필요 장비를 속성으로 갖는다. 셋째 제약(Constraint)은 이 둘을 묶는 규칙이다. 이렇게 정형화해 두어야 "잘 짜줘"라는 모호한 요청이 아니라, 풀 수 있는(혹은 풀 수 없음을 증명할 수 있는) 명확한 문제가 된다.
제약은 네 축으로 갈라진다. 시간 제약은 장비별 가동시간과 주말·공휴일을 배제하는 시간 윈도우(Time Windows)다. 선후 제약은 시험 절차상 A가 끝나야 B를 시작할 수 있는 순서(precedence) 관계다. 용량 제약은 장비 잔여 면적과 포화율 상한 안에 월별 시험을 '담아야' 한다는 공간 한도로, 본질적으로 Bin capacity 문제다. 우선순위 제약은 마감월·제출일이 임박한 시험을 먼저 배치하라는 규칙이다. 목적함수도 동시에 세 개를 만족시켜야 한다 — ①마감 준수를 위한 지연(Tardiness) 최소화, ②설비 유휴를 줄이는 가동률(Utilization) 최대화, ③동일 장비 중복 배정을 막는 충돌 0. 충돌 0은 협상 대상이 아닌 하드 제약이라는 점이 중요하다.
| 구성요소 | 이론 개념 | 이 케이스 매핑 |
|---|---|---|
| 자원(Resource) | 처리 능력을 가진 설비 | 시험 장비 (가동시간·잔여면적·Dimension 보유) |
| 작업(Job) | 자원을 점유하는 단위 작업 | 각 시험항목 (약 114종 · 소요일·필요장비) |
| 제약 · 시간 | Time Windows | 가동시간 · 주말/공휴일 배제 |
| 제약 · 순서 | Precedence | 시험 절차상 선후 순서 |
| 제약 · 공간 | Capacity / Bin | 잔여 면적 · 포화율(여유율 30%/포화 70%) |
| 제약 · 우선순위 | Priority Rules | 마감월 · 제출일 임박 우선 |
| 목적 ① | Tardiness 최소화 | 마감 준수 |
| 목적 ② | Utilization 최대화 | 설비 가동률(유휴 최소) |
| 목적 ③ | Conflict 0 (하드 제약) | 동일 장비 중복 배정 금지 |
이 케이스는 단일 정형이 아니라 세 부류가 겹친 복합 구조다. 첫째이자 핵심은 RCPSP로, 복수 시험이 복수 장비를 공유하면서 자원 용량 상한과 선후 제약을 동시에 충족해야 한다. RCPSP는 NP-hard로 증명되어, 입력이 커지면 정확해 탐색 비용이 지수적으로 폭증한다. 둘째는 Job-Shop 유사 구조다. 각 시험이 특정 장비를 점유하며 순서를 갖는 연산 단계로 볼 수 있는데, 다만 동일 장비에 복수 시험이 병렬 가능해 엄밀히는 병렬 기계(parallel machine) 변형이다. 셋째는 Bin Packing 유사 구조로, 장비의 잔여 면적(포화율) 한도 안에 월별 시험을 담는 공간 용량 관점이다. 약 114종 × 장비 수 × 기간으로 펼쳐지는 탐색공간은 brute-force로 정확해를 구하는 것이 비현실적이며 바로 이 점이 LLM 단독 풀이를 배제하고 전용 제약충족(CP) 또는 메타휴리스틱 최적화 모듈을 필수로 만든다.
5. 왜 LLM 단독은 안 되는가
앞 장에서 시험 배치를 자원제약 스케줄링(RCPSP) 문제로 정형화했다면, 이제 그 문제를 무엇으로 풀 것인가를 정해야 한다. 후보는 다섯이다 — ①CP-SAT(OR-Tools 등 제약 프로그래밍 최적화 모듈), ②우선순위 규칙(EDF/SPT 같은 디스패치 규칙), ③유전알고리즘·담금질(GA/SA), ④MILP(정수계획), ⑤LLM 단독(프롬프트로 일정 계산까지 시키는 방식). 이 선택은 취향이 아니라 본 사업의 네 가지 평가 기준 — 폐쇄망(온프레미스) 배포 가능 여부, 재조정 시 변경량(delta) 최소화, 검수자가 납득할 설명가능성, 설비 규모 확장성 — 으로 강제된다. 결론부터 말하면 ⑤만 모든 축에서 탈락하고 나머지 넷 사이에서 1순위·폴백·예비를 가른다.
가장 먼저 떨어지는 건 LLM 단독이다. 이유는 단순하지만 치명적이다. 첫째, 비결정성이다. 같은 시험 목록·같은 장비 상태를 넣어도 호출마다 다른 일정이 나온다. 본 사업의 하드 목표는 "같은 입력에 같은 일정(재현성 100%)"인데, 확률적 디코딩에 의존하는 모델은 이 요건과 구조적으로 충돌한다. 둘째, 제약 충족 능력의 부재다. LLM은 "장비 가동시간을 넘기지 마라", "잔여 적재면적을 음수로 만들지 마라" 같은 수치 제약을 검증하는 게 아니라 모방한다. 그럴듯하게 일정을 적어내지만 실제로는 제약을 위반하거나 존재하지 않는 슬롯을 환각으로 만들어낸다. 셋째, 설명 불가다. 왜 이 시험을 화요일 그 장비에 넣었는지, 어떤 제약 때문에 다른 곳이 불가능했는지를 추적할 메커니즘이 없다.
남은 네 후보는 각자 장단이 갈린다. 우선순위 규칙(EDF/SPT)은 완전히 결정적이고 규칙이 명시적이라 설명이 쉽지만 그리디 특성상 전역 최적을 보장하지 못한다. GA/SA는 대규모에서 병렬화가 쉽고 근사해를 빠르게 찾지만 시드에 의존하는 확률적 탐색이라 수렴이 보장되지 않고 재현성 요건과 부딪힌다. MILP는 정수 최적해를 주고 쌍대값(dual)으로 제약 기여도까지 분석할 수 있지만 잔여면적 적재(Bin Packing) 항과 순서 제약(RCPSP) 항을 한 모델에 결합하면 정수변수가 폭증해 수렴 시간이 비현실적으로 커진다. 그에 비해 CP-SAT는 소규모에서 최적해(또는 허용오차 내 해)를 주고 시드를 고정하면 출력이 완전히 동일하며 제약 위반 이유와 여유(slack)를 함께 내보내 검수자가 납득할 근거를 제공한다. 결정적으로 재조정 delta 최소화를 제약으로 직접 표현할 수 있다 — 기존 일정을 고정 변수로 두고 변경에 페널티를 거는 방식이다. LLM 단독은 이전 상태를 추적할 구조 자체가 없어 이 요건이 원리적으로 불가능하다.
| 비교축 | CP-SAT | 우선순위 규칙 | GA·SA | MILP | LLM 단독 |
|---|---|---|---|---|---|
| 폐쇄망 배포 | ○ 오픈소스 | ○ 자체 구현 | ○ 오픈소스 | ○ 오픈소스 | ✕ 외부 API/온프레미스 LLM 필요 |
| 결정성·재현성 | ○ 시드 고정 시 완전 동일 | ○ 완전 결정적 | △ 시드 필요·확률적 | ○ 완전 결정적 | ✕ 비결정적(같은 입력 다른 일정) |
| 최적성 | ○ 소규모 최적/허용오차 내 | △ greedy·비보장 | △ 근사(수렴 비보장) | ○ 정수 최적(수렴 시간 큼) | ✕ 비보장·제약위반 가능 |
| 설명가능성 | ○ 제약 위반 이유·슬랙 출력 | ○ 규칙 명시적 | ✕ 불투명 | ○ dual로 기여도 분석 | ✕ 불투명·환각 |
| 재조정 delta 최소화 | ○ 고정변수+페널티로 직접 표현 | △ 규칙 추가 필요 | △ 적합도 페널티 | ○ 목적항 추가 | ✕ 구조적 불가(이전 상태 추적 없음) |
| 확장성 | ○ 시간제한 파라미터로 품질/속도 절충 | ○ 선형 | ○ 병렬화 용이 | ✕ 변수폭증 위험 | ✕ 컨텍스트 포화 |
| 종합 판정 | 1순위 (권고) | 폴백 | 대규모 예비 | 비권고 | 비권고 |
따라서 권고는 1순위 = CP-SAT(OR-Tools, Apache 2.0 라이선스로 폐쇄망 반입 가능, 시간제한 파라미터로 속도·품질 제어)이며 타임아웃이나 해 없음(infeasible) 상황에서는 EDF/SPT 우선순위 규칙으로 실용해를 즉시 산출하고 그 케이스를 HITL로 격리하는 폴백을 둔다. 약 114종 · 월 단위 규모라면 수초~수십초 내 해 산출이 현실적이라고 본다(가정값이며 파일럿 벤치마크로 반드시 검증해야 한다). MILP는 잔여면적 Bin 항과 순서 RCPSP 항을 결합할 때 정수변수가 폭증해 수렴 보장이 어렵고 GA/SA는 비결정성이 재현성 요건과 충돌하므로 본선에서 빼되 대규모 확장 시 예비 선택지로만 남긴다. 그리고 LLM 단독은 — 다시 강조하지만 — 제약충족 능력이 없고 비결정적이며 검증 불가하므로, 일정 계산의 자리에는 결코 두지 않는다.
6. 최적화 모듈과 LLM의 역할 분리 — 환각을 구조로 막다
앞 절에서 LLM 단독 스케줄링이 불가능하다는 점을 짚었다면, 이 절의 질문은 그다음이다. 그렇다면 LLM은 어디까지 손을 대도 되는가. 이 케이스 설계의 가장 단단한 원칙은 한 문장으로 요약된다 — 전용 제약 스케줄링 최적화 모듈이 산출한 일정이 유일한 진실(Ground Truth)이고 LLM은 그 결과를 '서술'만 한다. 왜 이렇게까지 못을 박아야 하는가. LLM이 날짜나 장비를 직접 계산·수정하도록 허용하는 모든 설계는, 그 순간 충돌 0·제약 위반 0 요건을 구조적으로 위협하기 때문이다. 최적화 모듈이 보장한 무충돌 배치를 LLM이 자연어 생성 과정에서 단 하루라도 옮겨 적으면, 그 일정은 더 이상 검증된 일정이 아니다.
그래서 10단계 파이프라인의 각 단계마다 LLM 개입 허용 범위를 사전에 못 박았다. 시험리스트 추출·정규화는 비정형 텍스트(사양 문서·요청서)를 파싱하는 일이라 LLM 보조가 유용하다 — 단, 추출 결과를 마스터 대조 규칙으로 반드시 재검증한다. 마스터 조회는 결정적 DB 조회이므로 개입이 없다. 핵심인 스케줄링 최적화는 LLM 개입을 절대 금지하고 전용 최적화 모듈에 일임한다. 계획서 생성만 LLM 전담이되, 근거는 오직 최적화 모듈 결과뿐이며 날짜·장비는 손댈 수 없다. 전송·DB 갱신·검증은 모두 결정적 트랜잭션이라 개입이 없다. 정리하면 LLM은 양쪽 끝의 '언어 작업'(비정형 입력 해석 / 결과 서술)에만 배치되고 한가운데의 '수치 계산'에서는 완전히 배제된다.
| 단계 | 담당 | LLM 개입 |
|---|---|---|
| 시험리스트 추출·정규화 | LLM 보조 + 규칙 검증 | 보조 가능 (마스터 대조 검증 필수) |
| 마스터 조회 | 결정적 DB 조회 | 개입 없음 |
| 스케줄링 최적화 | 전용 제약 스케줄링 최적화 모듈 | ★ 절대 금지 |
| 계획서 생성 | LLM 전담 | 전담 (최적화 모듈 산출값만 근거·날짜/장비 수정 불가) |
| 전송 · DB 갱신 · 검증 | 결정적 트랜잭션 | 개입 없음 |
역할 분리 원칙만으로는 부족하다. 계획서 생성 단계에서 LLM이 최적화 모듈 결과를 그대로 옮긴다는 보장을 실행 수준에서 강제해야 한다. 그래서 환각 통제를 네 겹으로 쌓았다. ①재계산 금지 지시 — 프롬프트에 "제공된 일정 데이터를 수정·재계산하지 말 것, 오직 서술만 할 것"을 명시한다. ②출력 스키마 고정 — 시험항목명·배치시작일·배치종료일·장비명 같은 필드는 최적화 모듈 입력값을 그대로 echo하게 하고 자연어 설명은 별도 narrative 필드에만 허용한다. 즉 LLM이 자유 문장을 쓸 공간과 수치를 담는 공간을 물리적으로 분리한다. ③사후 검증(Post-validation) — 생성된 계획서의 날짜·장비가 최적화 모듈 산출값과 일치하는지 자동 비교하고 불일치하면 LLM 출력을 거부하고 최적화 모듈 원본으로 대체한다. ④예외 서술 격리 — infeasible·재조정 항목 설명은 LLM이 맡되, 예외 항목 목록 자체는 최적화 모듈이 플래그로 제공하고 LLM은 그 목록 밖 항목에 임의로 예외 표기를 달 수 없다.
이 네 겹 구조가 만들어내는 효과는 명료하다. LLM의 환각 노출면이 '수치'에서 '서술 문장'으로 축소된다. 날짜를 하루 밀거나 장비를 바꿔 적는 식의 일정 수치 환각은 스키마 echo와 사후 검증으로 구조적으로 차단되고 사람이 따로 검증해야 할 대상은 오직 서술의 누락·왜곡뿐이다. 그리고 서술 오류는 일정 오류와 위험 등급이 다르다 — 잘못된 날짜는 시험 충돌을 일으키지만 어색한 설명 한 줄은 가독성 문제에 그친다. 결국 이 절의 메시지는 "LLM을 믿지 말라"가 아니라, LLM이 틀려도 안전한 자리에만 LLM을 두라는 것이다. 환각은 프롬프트로 줄이는 게 아니라 설계로 가두는 것이며 이 케이스는 그 경계를 최적화 모듈과 LLM 사이에 명확히 그었다.
7. 같은 입력에 같은 일정 — 결정성·재현성
RAG형 과제를 다뤄 본 사람이라면 1순위 비기능 요건(NFR)으로 검색 정확도·근거충실도·환각률을 떠올린다. 그런데 이 과제는 성격이 다르다. 시험 일정을 짜는 일에서 가장 먼저 못박아야 할 NFR은 결정성·재현성·일정 정합성이다. 왜 그런가. 일정은 자원을 움직이는 명령이고 인수검수와 분쟁 방어의 대상이기 때문이다. "이 일정이 그럴듯한가"가 아니라 "같은 입력에서 이 일정이 또 나오는가"가 핵심 질문이 된다. RAG의 평가지표를 그대로 가져와 이 과제를 재단하면 정작 가장 중요한 속성을 놓치게 된다 — 같은 과제라도 1순위로 지켜야 할 품질의 종류가 다르다는 점을 분명히 하고 시작해야 한다.
문제는 최적화 모듈 자체가 본질적으로 결정적이지 않다는 데 있다. 제약 최적화 모듈은 시드(seed)·타이브레이크(동률 해소)·병렬 탐색의 비결정성 때문에, 같은 입력에도 비용이 똑같은 여러 최적해(동률해) 중 매번 다른 것을 내놓을 수 있다. 마감을 모두 지키고 충돌이 0인 일정이 여럿일 때, 최적화 모듈은 그중 무엇을 골라도 "최적"이지만 사람 눈에는 서로 다른 일정이다. 원천 설계는 "최적 스케줄 산출"과 "규칙 오류 검증"은 명시했지만 정작 재현성 보장은 비어 있었다. 인수검수 자리에서 "그때 그 일정을 다시 한 번 뽑아 보라"는 요구에 다른 결과가 나오는 순간, 시스템의 신뢰는 무너진다. 그래서 결정성은 부가 기능이 아니라 설계의 골격으로 끌어올려야 했다.
설계는 다섯 겹의 장치로 "같은 입력 → 같은 일정"을 강제한다. 첫째 고정 시드로 탐색의 출발점을 못박고 둘째 결정적 타이브레이크 규칙으로 동률해를 항상 같은 방식으로 깬다 — 우선순위 → 마감월 → 제출일 → 시험항목 ID 순으로 비교하면 비용이 같은 후보들 사이에서도 단 하나의 정답이 정해진다. 셋째 단일스레드 결정 모드(또는 결정적 병렬)로 스레드 경합에서 오는 흔들림을 없애고 넷째 입력 정규화로 의뢰 목록을 항상 같은 키로 정렬해 입력 순서 의존성을 제거한다. 다섯째 계획 스냅샷 — 입력 옵션·최적화 모듈 버전·시드·파라미터를 산출 일정과 함께 보존해, 몇 달 뒤에도 그 일정을 똑같이 재현하고 입증할 수 있게 한다. 이 다섯이 모이면 일정은 우연이 아니라 함수의 출력이 된다.
이 결정성은 통합테스트와 곧장 연결된다. 회귀 검증이 성립하려면 같은 입력으로 반복 실행했을 때 응답 페이로드 — 즉 산출된 시험계획 — 가 동일해야 한다. 일정이 매번 바뀌면 "이번 변경이 회귀를 일으켰는가"라는 질문 자체가 성립하지 않는다. 결정성은 그래서 단순한 품질 속성이 아니라 통합·검수의 토대다. 같은 입력에 같은 출력이 보장되어야 비로소 비교의 기준선이 서고 그 위에서 변경의 영향을 가려낼 수 있다.
8. 충돌·재조정과 이중 검증
일정은 한 번 짜고 끝나지 않는다. 신규 의뢰가 들어오고 잡혔던 시험이 취소되고 우선순위가 바뀐다. 그래서 이 케이스의 진짜 난이도는 최초 배치가 아니라 이미 확정된 일정 위에 변경을 얹는 일에 있다. 변경을 얹는 순간 충돌이 발생할 수 있고 충돌은 세 유형으로 갈린다. ①자원 중복은 동일 장비·동일 시간대에 두 시험이 배정되는 경우, ②용량 초과는 장비 잔여 면적을 넘기거나 포화율 상한(70%)을 깨는 경우, ③순서 위반은 선행 시험이 끝나지 않았는데 후속 시험이 먼저 배치되는 경우다. 중요한 점은 이 세 충돌을 사람이나 LLM이 눈으로 찾는 게 아니라 최적화 모듈 내부의 제약 위반 판정으로 기계적으로 감지한다는 것이다. 제약을 수학적으로 선언해 두었기 때문에(4절) 충돌은 곧 "제약식이 거짓이 되는 상태"로 환원되고 최적화 모듈은 그것을 놓치지 않는다.
| 충돌 유형 | 정의 | 감지 기준(최적화 모듈 제약) |
|---|---|---|
| ① 자원 중복 | 동일 장비·동일 시간대에 두 시험이 배정 | 자원 점유 구간 비중첩 제약 위반 |
| ② 용량 초과 | 장비 잔여 면적 초과 · 포화율 70% 상한 돌파 | Bin capacity 제약(여유율 30%) 위반 |
| ③ 순서 위반 | 선행 시험 미완료 상태에서 후속 시험 배치 | 선후(precedence) 제약 위반 |
충돌을 감지했다면 어떻게 푸는가. 재조정의 제1원칙은 기존 일정을 최대한 보존하고 변경된 배치 수(delta)를 최소화하는 것이다. 신규 의뢰 하나가 들어왔다고 전체 일정을 갈아엎으면, 이미 현업에 공지된 수십 건의 시험 일정이 흔들려 운영 혼란이 발생한다. 그래서 정책은 네 단계로 작동한다. (1) 기존 일정 고정 우선 — 확정된 배치를 최적화 모듈의 고정 변수(fixed variable)로 묶고 신규 항목만 자유 변수로 둔다. (2) delta 최소화 — 이동이 불가피한 작업만 옮기되, 옮긴 횟수를 목적함수의 페널티 항으로 넣어 최적화 모듈이 스스로 최소 이동 해를 찾게 한다. (3) 우선순위 보호 — 마감월이 빠른 시험을 보존하고 후순위부터 밀어낸다. (4) 최소 이동 범위 — 영향 받는 장비·기간으로 재계산을 국소화한다. 이 정책이 두 가지 운영 모드로 나타난다 — 변경 규모가 크면 '전체 재최적화', 작으면 'delta 최소 재계산'이다.
이 보존이 코드에서 어떻게 강제되는지 한 조각만 보이고 싶다. 핵심은 사람의 주의가 아니라 최적화 모듈의 제약과 목적함수에 보존을 '선언'한다는 점이다. 제약 프로그래밍 최적화 모듈(CP-SAT)라면 대략 이런 모양이 된다.
from ortools.sat.python import cp_model
model = cp_model.CpModel()
# (1) 기존 확정 일정은 '고정 변수'로 묶어 최적화 모듈이 함부로 옮기지 못하게
for j in fixed_jobs:
model.Add(start[j] == fixed_start[j])
# (2) 옮겨야 한다면 '이동 여부'를 변수로 두고
moved = {j: model.NewBoolVar(f"moved_{j}") for j in movable_jobs}
for j in movable_jobs:
model.Add(start[j] != original_start[j]).OnlyEnforceIf(moved[j])
# (3) 이동 횟수 자체를 최소화 = delta 최소(기존 일정 최대 보존)
model.Minimize(sum(moved.values()))위 조각에서 두 가지가 보존을 보장한다. 첫째, 이미 확정된 작업의 시작일을 고정 변수로 묶어 최적화 모듈이 임의로 옮기지 못하게 한다. 둘째, 그래도 옮겨야 한다면 이동 여부 자체를 목적함수의 페널티로 넣어, 최적화 모듈이 최적화 과정에서 자연스럽게 '가장 적게 흔드는 해'를 고르게 한다. 보존이 운영 매뉴얼의 당부가 아니라 모델의 구조가 되는 순간, 사람이 깜빡해서 새는 틈이 사라진다. 전체 모델(자원 제약·선후 제약·용량 빈)은 상세 설계의 몫이고 여기서는 "보존을 제약으로 선언한다"는 감각만 전하면 충분하다.
재배치가 끝났다고 바로 반영하지 않는다. 원천 설계는 "작업 이후 규칙 오류 발생 여부를 검증한다"고 명시하는데, 검증해야 할 규칙은 여섯 가지다 — 주말·공휴일 배치 금지, 가동시간 외 배치 금지, 여유율 30% 초과 금지(포화율 70% 이하), 선후 순서 위반 없음, 우선순위 정책 준수, 그리고 의뢰서 기준 필수 시험항목 누락 없음이다. 마지막 항목이 특히 중요하다. 충돌이 없는 깔끔한 일정이라도 의뢰자가 요구한 시험이 빠져 있으면 그것은 잘못된 계획이다. 이 6규칙 중 하나라도 위반이 잡히면 두 갈래로 처리한다. 기계적으로 풀 수 있는 위반(예: 단순 시간대 충돌)이면 최적화 모듈을 소규모로 재호출해 보정하고 비즈니스 판단이 필요한 위반(예: 어느 우선순위를 양보할지)이면 HITL로 격리해 사람에게 넘긴다.
검증은 한 번이 아니라 두 번 작동한다. 이 이중 검증(정합 가드)이 데이터 무결성의 마지막 방어선이다. 첫 번째는 최적화 모듈 사전 검증으로, 산출 직후 최적화 모듈이 자신이 만든 해가 모든 제약을 만족하는지 스스로 확인한다. 두 번째는 DB 사후 재검증으로, 계획을 시험관리 플랫폼에 반영하기 직전에 한 번 더 본다. 사전 검증을 통과했는데 왜 또 보는가? 최적화 모듈이 옳은 해를 냈더라도 전송·파싱 과정에서 데이터가 손상되거나, 그 사이 기존 DB 상태가 바뀌어 불일치가 생길 수 있기 때문이다. 사후 검증은 바로 이 틈을 막는다. 그리고 신규·변경을 단일 트랜잭션으로 처리해 부분 반영을 0으로 만들고 충돌·오류 시 롤백 또는 보정한 뒤 변경이력을 남긴다. 변경내역은 신규/변경 2채널로 분리해 전송·파싱하므로(3절의 응답 계약과 동일 원칙) 어느 것이 새 일정이고 어느 것이 밀려난 일정인지 끝까지 구분된다.
infeasible 처리는 이 케이스에서 가장 위험한 실수를 차단하는 지점이라 따로 강조할 가치가 있다. 제약이 너무 빡빡해 어떤 일정으로도 모든 조건을 만족시킬 수 없는 상황은 실제로 발생한다. 이때 가장 그럴듯하지만 가장 나쁜 선택이 "최적화 모듈이 못 풀었으니 LLM에게 대충 일정을 추정시키자"는 폴백이다. 그렇게 만든 일정은 충돌 0도, 제약 위반 0도, 재현성 100%도 모두 깨진 채 그럴듯한 표만 갖춘 가짜 계획이 된다. 올바른 처리는 최적화 모듈의 능력 안에 머무는 것이다. 제약을 완화 가능한 것(soft)과 절대 불가한 것(hard)으로 나눠 soft 제약부터 단계적으로 풀거나, 풀리는 만큼만 배치하고 미배치 항목을 솔직히 드러내 사람에게 결정을 넘긴다. 해가 없다는 사실을 숨기지 않는 것, 그것이 LLM 단독 풀이를 배제한 이 아키텍처의 일관된 태도다.
9. 사람은 어디서 끼어드는가 — 세 화면과 확정 게이트
여기까지 저는 최적화 모듈과 LLM이라는 두 엔진, 그리고 그 둘이 맞물리는 아키텍처를 이야기했습니다. 그런데 이 시스템을 실제로 움직이는 것은 엔진이 아니라 사람입니다. 설계를 하면서 제가 가장 늦게까지 붙들고 있던 질문도 그것이었습니다 — 자동화를 어디까지 밀어붙이고 사람의 손은 어디에 남겨 둘 것인가. 결론부터 말하면, 사용자가 직접 만지는 화면은 단 셋뿐이고 저는 그 셋을 사람이 통제권을 쥐는 세 개의 게이트로 설계했습니다. 화면이 적은 것은 기능이 빈약해서가 아니라, 사람이 개입할 지점을 '입력'과 '확인'으로 좁혀 자동화의 신뢰 경계를 분명히 하려는 의도였습니다.
첫 번째 화면은 시험의뢰 등록입니다. 사용자는 사양구성도를 연계해 어떤 부품을 시험할지 지정하고 우선순위(마감월을 먼저 맞출지 제출일을 먼저 맞출지)와 마감월·제출일을 입력합니다. 그리고 'AI 시험계획 자동생성 연계' 토글을 켜면 자동화 경로가 열립니다. 저는 이 화면을 게이트 G0, 즉 "무엇을 어떤 기준으로 시험할지 사람이 정의하는 자리"로 봤습니다. 자동화가 아무리 똑똑해도 목표와 우선순위는 사람이 먼저 못 박아야 하기 때문입니다.
두 번째는 계획 생성 요청 화면입니다. 여기서 사용자는 배치 기준을 세팅합니다 — 단계별 소요일(시험의뢰·샘플접수·시험진행·시험판정·재시험대비·시험완료), 설비 가동시간 제약, 주말·공휴일 제외, 정기 여유율 30%, 그리고 마감월/제출일 우선순위입니다. 월별 배치 그리드에서 프로젝트와 완성 부품을 어느 달에 돌릴지 펼쳐 놓은 다음, [계획 생성] 버튼을 누르는 순간 백엔드 파이프라인이 깨어납니다. 저는 이 버튼을 게이트 G1, "언제 자동화를 시작할지 사람이 트리거하는 자리"로 설계했습니다. 무인 자동이 아니라 사람의 명시적 클릭에서 출발한다는 점이 중요합니다.
진행상태 표시는 사소해 보이지만 제가 공들인 부분입니다. 스케줄링 최적화 모듈은 결정성을 위해 속도를 다소 양보하므로(7절), 사용자가 [계획 생성]을 누르고 결과를 받기까지 빈 화면으로 기다리게 둘 수 없었습니다. 그래서 요청 접수부터 완료까지 여섯 단계를 진행률로 노출해, "지금 스케줄링 최적화 중"임을 보여줍니다. 느린 계산을 숨기는 대신 정직하게 드러내는 편이, 결정성을 위해 속도를 내준 트레이드오프와도 일관된다고 봤습니다.
마지막 세 번째 화면, 자동 배치 결과 캘린더입니다. 최적화 모듈이 계산하고 LLM이 서술한 결과가 여기에 펼쳐집니다. 상단에는 계획 요약 카드(계획 여유율·전체 샘플수·접수 완료/예정/미접수)가 한눈에 들어오고 가운데에는 설비별 캘린더가 1주·1·3·6·12개월 단위로 시험 블록을 보여줍니다. 그리고 재조정으로 밀려난 일정은 다른 색으로 강조됩니다 — 무엇이 새로 잡혔고 무엇이 바뀌었는지 사용자가 즉시 분간하도록 한 장치입니다. 사용자는 여기서 [재계산]이나 [최적화 배치]를 눌러 결과를 다시 받아 볼 수 있습니다. 이 화면이 게이트 G2, "결과가 맞는지 사람이 검토하는 자리"입니다.
그런데 이 여정에는 제가 설계하면서 발견한 빠진 단추가 하나 있습니다. 결과를 조회하고 재계산하는 자리는 있는데, "이 계획으로 확정한다"는 명시적 승인 버튼과 확정 이력이 원천 요구에는 없었습니다. 이 시스템은 AI가 기존에 확정된 일정까지 자동으로 밀어내며 재조정합니다. 그런데 그 변경을 사람이 승인하는 단계 없이 곧장 시험 진행 기준으로 쓰이면, 잘못된 계획이 검토 없이 현장에 흘러가고 책임 소재도 흐려집니다. 그래서 저는 [계획 확정] 버튼과 확정 이력(확정자 역할·일시)을 보완 제안으로 올렸습니다. 확정 전에는 조회·재계산·최적화만 가능하고 확정을 눌러야 비로소 일정이 시험 진행 기준으로 넘어가도록 말입니다. 자동화의 마지막 한 칸은 사람의 확정으로 닫아야 한다는 것이, 이 화면 설계에서 제가 얻은 교훈이었습니다.
10. 최적화 모듈을 굶기지 않으려면 — 6개 데이터 엔티티
지금까지 최적화 모듈이 어떻게 일정을 계산하는지를 이야기했다면, 이 절의 질문은 더 앞쪽에 있다. 최적화 모듈이 도대체 무엇을 먹고 도는가. 제약 스케줄링 최적화 모듈은 똑똑한 알고리즘이기 이전에 입력 데이터에 절대적으로 의존하는 함수다. 시험 한 건을 며칠짜리 작업으로 환산하려면 그 시험의 소요일을, 어느 장비에 꽂을지 정하려면 장비의 잔여 용량을, 주말을 건너뛰려면 가동 캘린더를 알아야 한다. 이 입력들이 모두 갖춰져야 비로소 최적화 모듈은 변수와 제약을 세울 수 있다. 그래서 이 케이스에서 가장 먼저 막히는 곳은 알고리즘이 아니라 데이터였고 우리는 그 입력을 6개 데이터 엔티티로 못 박아 정의했다.
6개 엔티티는 역할이 또렷이 갈린다. ①시험항목 마스터는 약 114종의 시험 각각에 대해 시험절차·선후 순서·필요장비·소요일/소요시간을 정의한다 — 최적화 모듈에게는 "작업의 정체"를 알려주는 사전이다. ②장비 마스터는 장비명·규격(Dimension)·표준 가동시간·잔여면적·위치를 담아 "자원의 용량"을 규정한다. ③장비 운용 스케줄은 날짜별 점유시간·잔여용량·기배치된 시험을 실시간으로 비추는 "현재 부하 지도"다. ④가동 캘린더는 주말·공휴일과 가동 시작/종료시간으로 "달력의 모양"을 정한다. ⑤시험 의뢰서는 마감월·제출일·우선순위·여유율·주말제외 여부를 담은 "트리거 입력"이고 ⑥사용자 옵션은 여유율 30%·주말/공휴일 제외·우선순위·가동시간 제약·단계별 소요일 같은 배치 기준 파라미터로 "배치의 룰셋"을 조정한다. 앞의 네 개는 미리 구축해 둘 마스터·운용 데이터, 뒤의 두 개는 실행 시점에 들어오는 입력이라는 점에서도 결이 다르다.
| 데이터 엔티티 | 최적화 모듈에서의 역할 | 결측 시 영향 |
|---|---|---|
| ① 시험항목 마스터 약 114종·절차·순서·장비·소요일 |
작업 정의 — 무엇을 며칠간, 어떤 순서로 | ★ 미완성 시 전체 차단(최적화 모듈 기동 불가) |
| ② 장비 마스터 규격·표준 가동시간·잔여면적·위치 |
자원 용량 — 어디에 꽂을 수 있나 | 갱신 누락 시 잘못된 용량 → 배치 오산 |
| ③ 장비 운용 스케줄 날짜별 점유·잔여용량·기배치(실시간) |
현재 부하 — 남은 슬롯 계산의 기준 | ★ 실시간 연동 미흡 시 포화율 오산 → 충돌 |
| ④ 가동 캘린더 주말/공휴일·가동 시작/종료시간 |
달력 형상 — 배치 가능한 날·시간 | 공휴일 관리 주체 미결 시 휴일 배치 발생 |
| ⑤ 시험 의뢰서 마감월·제출일·우선순위·여유율(트리거) |
목표·마감 — 무엇을 언제까지 | 필수 입력 결측 시 계획 생성 요청 자체 불가 |
| ⑥ 사용자 옵션 여유율 30%·휴일 제외·우선순위·소요일 |
룰셋 — 배치 기준 파라미터 조정 | 결측 시 기본값 적용(보수적 여유율로 대체) |
결측은 다 같은 무게가 아니다. 위험을 등급으로 갈라 보면 설계의 우선순위가 분명해진다. 최상위 위험은 시험항목 마스터 미완성이다 — 작업의 정체를 모르면 최적화 모듈은 변수조차 만들 수 없어 전체가 차단된다. 그 안에서도 소요시간 결측은 배치 슬롯 길이를 못 정하게 하고 선후 순서(precedence) 미정의는 더 교묘하다. 순서 제약 없이 배치되면 최적화 모듈은 "충돌 0"인 일정을 내놓지만 현실에서는 선행 시험이 끝나기 전에 후행 시험이 시작되는 시험 오류가 발생한다. 그다음 위험은 운용 스케줄 실시간 연동 미흡으로, 부하 지도가 낡으면 포화율을 잘못 계산해 이미 찬 슬롯에 또 배치하는 충돌이 난다. 끝으로 공휴일 캘린더 관리 주체 미결과 설비 기준정보 관리 화면 부재는 운영상의 결측이다 — 장비 마스터를 갱신할 창구가 없으면 잔여 용량이 현실과 어긋난 채 굳어 오산을 부른다.
그래서 일정 계획의 진짜 크리티컬 패스는 최적화 모듈 모델링이 아니라 데이터 정의다. 그리고 이 데이터 정의는 개발사가 아니라 발주사(현업)가 리딩해야 한다 — 약 114종의 시험이 각각 며칠 걸리고 어떤 순서로 묶이는지는 현업의 시험기획·품질 지식에서만 나오기 때문이다. 그래서 일정의 첫 단추는 114종 확정과 데이터 정의 워크숍이다. 이 워크숍으로 마스터 스키마를 동결한 뒤에야 조회 로직과 최적화 모듈 모델링에 착수할 수 있다. 순서를 거꾸로 잡으면 비싼 대가를 치른다 — 마스터가 미완성인 상태에서는 시험리스트 추출도, 스케줄링도, 계획서 생성도 전부 블로킹되기 때문이다.
한 가지 더 짚어야 할 실수가 있다. 데이터 정의가 크리티컬 패스라고 하면, '데이터 정의'와 'DB 구축'과 '데이터 조회'를 같은 주체의 일이라고 묶어 버리기 쉽다. 저는 이 셋을 일부러 갈라 놓았다. 데이터 정의(약 114종의 시험 항목을 절차·순서·소요일로 무엇으로 채울지)는 도메인 지식이 있는 발주사 현업이 리딩한다. 물리 구축·적재(스키마를 만들고 마스터에 데이터를 넣는 일)는 개발사가 맡는다. 그리고 조회·연산(구축된 마스터를 읽어 최적화 모듈에 먹이는 일)은 AI 에이전트 컴포넌트의 몫이다. 같은 '마스터 데이터'라도 이 세 책임은 필요한 전문성도, 일정도 전혀 다르다.
이 분할이 중요한 이유는, 실제로 두 개의 상위 정의 문서가 마스터 구축 주체를 서로 다르게 적어 두는 일이 있었기 때문이다. 한쪽은 정의 주체를, 다른 쪽은 구축 주체를 가리키며 같은 항목을 다르게 귀속했다. 정의=현업·구축=개발사·조회=AI로 세 층을 명시적으로 갈라 놓지 않으면, 착수 시점에 "그건 우리 일이 아닌 줄 알았다"가 반드시 튀어나온다. 거버넌스에서 가장 비싼 실수는 기술이 아니라 책임의 경계를 비워 두는 것이다.
11. 흔한 실수 6가지
이런 종류의 과제를 시작할 때 거의 모든 팀이 비슷한 실수에 빠진다. 공통점은 하나다 — 계산해야 할 일을 LLM에게 시키려는 유혹이다. 생성형 모델이 워낙 매끄러운 문장을 뽑아 주다 보니, 일정 배치처럼 명백히 계산해야 하는 작업까지도 "프롬프트만 잘 쓰면 알아서 짜 주겠지"라고 기대하게 된다. 하지만 신뢰성 시험 일정은 장비 점유·시험 기간·선후행 제약·여유율이 맞물린 제약 충족 문제(CSP)이지, 자연어 추론 문제가 아니다. 아래 여섯 가지는 이 과제에서 반드시 피해야 할 설계 안티패턴이며 각각의 처방은 우리가 최적화 모듈 중심 아키텍처를 택한 이유와 정확히 맞닿아 있다.
실수① LLM에게 일정 계산을 맡긴다. 가장 흔한 출발점이다. LLM은 같은 입력에도 매번 다른 답을 내놓을 수 있어 결정성과 재현성이 무너진다. 더 치명적인 것은, 모델이 "장비가 겹치지 않는다"고 서술해도 그것이 실제로 제약을 만족하는지 기계적으로 검증할 길이 없다는 점이다. 결과적으로 환각 일정 — 존재하지 않는 슬롯에 시험을 배치하거나 점유 중인 장비를 중복 할당한 계획 — 이 그럴듯한 문장에 실려 정답처럼 흘러간다. 처방은 명확하다. 계산은 최적화 모듈(CP-SAT)이 하고 LLM은 최적화 모듈이 확정한 날짜·장비를 그대로 옮겨 적는(echo) 서술자 역할만 맡는다. 서술 직후에는 최적화 모듈 산출값과 계획서 텍스트가 일치하는지 사후검증(post-check)으로 한 번 더 대조한다.
실수② infeasible일 때 LLM에게 폴백 추정을 시킨다. 최적화 모듈이 해를 찾지 못하면(infeasible) "그럼 LLM이 대충이라도 짜 줘"라는 임시방편이 자연스럽게 떠오른다. 이것이 실수①보다 더 위험한 이유는, 근거 없는 거짓 일정이 정상적으로 풀린 결과처럼 시스템에 반영되어 버리기 때문이다. infeasible은 버그가 아니라 "현재 자원·제약으로는 불가능"이라는 정당한 신호다. 올바른 처방은 최적화 모듈이 무엇이 충돌했는지(제약 완화 후보·부분해·미배치 시험 목록)를 명시적으로 내놓고 그 판단을 사람에게 넘겨(HITL) 재조정하게 하는 것이다. LLM을 일정 폴백 생성기로 쓰는 일은 어떤 경우에도 금지한다.
실수③ 재현성을 설계하지 않는다. 초기에는 "일단 잘 도니까" 시드와 입력 스냅샷을 남기지 않는 경우가 많다. 그러나 검수나 분쟁 상황에서 "그때 그 일정을 다시 그대로 보여 달라"는 요구가 들어오면 시스템은 그 자리에서 무너진다. 최적화 모듈에 고정 시드를 박고 동점 후보를 가를 때도 결정적 타이브레이크 규칙(예: 시험 ID 오름차순)을 쓰며 매 계획마다 입력·최적화 모듈 버전·시드를 묶은 스냅샷을 보관해야 한다. 그래야 같은 입력은 언제 돌려도 같은 결과를 재현한다.
실수④(짧게) 이 과제를 RAG·임베딩 과제로 오인한다. 다른 검색 과제에서 쓰던 색인·임베딩 스택을 습관적으로 가져오는 실수다. 벡터 검색이 본질이 아닌데도 임베딩 파이프라인을 부채처럼 떠안게 된다. 이 과제는 본질이 OR(운영 연구) 최적화형이다. 벡터 검색·근거 충실도 같은 RAG형 NFR은 비핵심이고 결정성·충돌 0·제약 준수가 핵심 품질 축이다.
실수⑤ 사양이 바뀌어도 계획은 모른다. 이 시스템은 사용자가 명시적으로 요청할 때만 계획을 생성한다. 그래서 한 번 계획을 짠 뒤 사양구성도가 설계변경으로 개정되면, 기존 계획은 구버전 사양을 기준으로 그대로 남는다. 신차 개발처럼 사양이 자주 바뀌는 국면에서는 계획과 현행 사양의 불일치가 소리 없이 쌓인다. 처방은 두 갈래다. 가볍게 가려면 사양이 개정될 때 관련 의뢰에 '사양 변경됨' 알림 플래그만 띄우고 무겁게 가려면 개정을 감지해 계획을 자동으로 재생성하는 트리거를 둔다. 어느 쪽이든 "계획은 한 번 짜면 끝"이라는 가정만은 버려야 한다.
실수⑥ 자동 재조정에 사람의 승인이 없다. 앞의 9절(세 화면과 게이트)에서 짚은 빠진 단추가 그대로 실수가 된다. AI가 기존 확정 일정을 말없이 밀어내고 그 결과가 검토 없이 반영되면, 현장은 "누가 언제 왜 내 시험을 옮겼는가"를 추적할 수 없다. 처방은 명시적 확정 게이트다 — 변경 내역을 하이라이트로 보여 주고 [계획 확정] 승인과 확정 이력을 남긴 뒤에야 일정이 시험 진행 기준으로 넘어가게 한다. 자동화가 똑똑할수록 사람이 마지막에 도장을 찍는 자리는 더 분명해야 한다.
12. 설계 교훈 5선
이 케이스를 관통하는 한 문장은 "전용 최적화 모듈이 일정을 계산하고 LLM은 계획서로 서술만 한다"였다. 제조 부품 신뢰성 시험계획처럼 장비·운용 캘린더·시험항목 마스터가 서로 얽힌 조합 최적화(OR) 과제에서는, 모델을 더 똑똑하게 만드는 일보다 계산할 일과 서술할 일을 분리하는 일이 결과 품질을 가른다. 아래 다섯 가지는 이 과제에서 도출했지만 특정 업종에 묶이지 않는, 비슷한 제약 스케줄링·자원 배분 과제에 그대로 옮겨 쓸 수 있는 일반 원칙으로 정리했다.
첫째, 계산과 서술을 분리하라. 조합 최적화와 수치 계산은 CP-SAT 같은 전용 최적화 모듈이 산출한 결과를 Ground Truth로 삼고 자연어 계획서는 그 결과를 받아 LLM이 풀어 쓰는 역할만 맡긴다. 둘을 한 단계에 섞으면 같은 입력에도 출력이 흔들려 결정성이 무너진다 — 이 분리는 어느 OR형 과제든 성립하는 책임 경계라서 일반화된다. 둘째, 결정성·재현성을 1순위 NFR로 두라. 시험계획·교대편성·물류 배차 같은 과제의 핵심 품질은 검색 정확도가 아니라 '같은 입력이면 같은 결과'다. 시드 고정·타이브레이크 규칙·계획 스냅샷을 초기 설계에 박아 두지 않으면 나중에 끼워 넣기 어렵다.
셋째, 충돌·정합은 이중으로 검증하라. 최적화 모듈이 배치 단계에서 사전 검증을 마쳐도, 반영 시점에는 마스터 DB 기준으로 사후 재검증을 한 번 더 건다. 단일 트랜잭션으로 묶어 부분 반영을 0으로 만들고 변경이력을 남기면, 동시성·중복 반영 같은 정합 사고의 틈이 메워진다. 넷째, 데이터가 진짜 크리티컬 패스다. 아무리 좋은 최적화 모듈도 입력이 부실하면 굶는다. 시험항목·장비·운용스케줄·캘린더·의뢰서·옵션이라는 6개 엔티티와 그 데이터 정의(현업 리딩)가 모델 선택보다 먼저 확정돼야, 최적화 모듈이 의미 있는 해를 낸다.
다섯째, 사람의 자리를 게이트로 명시하라. 이 시스템은 무인 자동이 아니라 사용자 트리거 + 검토 게이트 구조다. 배치기준 설정, [계획 생성] 트리거, 결과 검토라는 3개 게이트(HITL)가 책임 경계를 분명히 한다(9절). 여기에 명시적 [계획 확정] 승인을 더하면 그 경계는 더 또렷해진다 — 자동화의 효율과 사람의 최종 판단이 충돌하지 않게 자리만 정해 주면, 같은 패턴을 다른 자동 의사결정 과제에도 안전하게 적용할 수 있다.
| 교훈 | 핵심 | 일반화 적용 영역 |
|---|---|---|
| ① 계산과 서술 분리 | 조합 최적화·수치는 전용 최적화 모듈(Ground Truth), 자연어 설명은 LLM. 한 단계에 섞으면 결정성 붕괴 | 최적화 모듈 결과를 사람이 읽을 보고서로 바꾸는 모든 OR형 과제 |
| ② 결정성·재현성 우선 | '같은 입력 같은 결과'가 1순위 NFR. 시드·타이브레이크·계획 스냅샷을 초기 설계에 내장 | 교대편성·배차·생산 일정 등 OR형 자동 배치 과제 전반 |
| ③ 충돌·정합 이중 검증 | 최적화 모듈 사전 검증 + DB 사후 재검증. 단일 트랜잭션·부분 반영 0·변경이력으로 정합 가드 | 계산 결과를 운영 DB·외부 시스템에 반영하는 통합 구간 |
| ④ 데이터가 크리티컬 패스 | 6개 엔티티와 데이터 정의(현업 리딩)가 모델보다 먼저 확정돼야 최적화 모듈이 굶지 않음 | 입력 마스터·제약 데이터가 품질을 좌우하는 모든 최적화 모듈 과제 |
| ⑤ 사람의 자리는 게이트로 | 배치기준 설정·[계획 생성] 트리거·결과 검토 확정의 3게이트(HITL)로 책임 경계 명시 | 최종 판단에 사람 승인이 필요한 자동 의사결정 시스템 전반 |
13. 기대효과는 목표치로, 합격선은 측정 프레임으로
도입 효과를 이야기할 때 가장 흔한 실수는 "작성 시간 80% 단축" 같은 숫자를 결과처럼 단정하는 것이다. 이 케이스의 KPI는 두 부류로 갈린다. 하나는 최적화 모듈이 구조적으로 보장하는 하드 목표이고 다른 하나는 비즈니스 협의가 필요한 효율성 지표다. 이 구분이 중요한 이유는, 전자는 설계만 제대로 하면 협상 없이 달성되지만 후자는 현업의 운영 정책·설비 사정에 따라 달라지기 때문이다. 둘을 한 표에 뒤섞어 모두 "확정 수치"로 제시하면, 달성 가능한 약속과 협의가 필요한 추정을 구분하지 못해 인수검수 단계에서 신뢰가 무너진다.
하드 목표는 셋이다. 일정 충돌 0건, 제약 위반 0건(주말·공휴일·가동시간·여유율·선후·우선순위·필수항목 누락), 재현성 100%(동일 입력이면 동일 해, 5회 반복 검증). 이 셋은 협의 대상이 아니다. 전용 제약 스케줄링 최적화 모듈이 제약을 모델에 직접 인코딩하고 결정적으로 푸는 구조이기 때문에, 충돌과 위반은 애초에 해가 될 수 없는 영역으로 배제되고 동일 입력은 동일 해로 수렴한다. 반대로 설비 가동률·마감 준수율·재조정 delta 비율 같은 지표는 최적화 모듈이 최적화는 하지만 그 절대 수치는 입력 조건(설비 보유량·시험 물량·납기 분포)에 종속된다. 그래서 가동률 ≥70%, 마감 준수율 ≥95% 같은 값은 예시일 뿐, 합격선은 현업과 협의해 확정해야 한다.
여기서 이 설계의 핵심 주장이 나온다 — 근거 있는 목표치 + 명시된 측정 방법이, 근거 없는 확정 수치보다 엔터프라이즈의 신뢰를 얻는다. "가동률 73.4%"라고 못 박는 대신 "가동률은 ≥70%를 목표로 하되 설비 마스터 확정 후 협의, 측정은 배치 점유시간/가용시간으로 산정"이라고 적는 편이, 검수자 입장에서 검증 가능하고 책임 소재가 분명하다. 그래서 다수 지표가 "목표치 협의필요" 상태로 남는 것은 미완성이 아니라, 인수검수 합격선을 측정 프레임으로 합의한다는 설계 의사결정이다. LLM 단독 방식과 비교하면 차이는 더 분명하다. 최적화 모듈을 쓰면 충돌 0·위반 0·재현성 100% 같은 하드 목표를 구조적으로 달성하지만 LLM이 직접 일정을 계산하는 방식에서는 이 셋 모두 통계적 확률 문제로 전락한다.
| 지표 | 정의 | 목표치 | 측정·전제 |
|---|---|---|---|
| 일정 충돌 건수 | 동일 설비·동일 시점 중복 배치 | 0건 (하드) | 최적화 모듈이 보장 · 자동 검증 |
| 제약 위반 | 주말·공휴일·가동시간·여유율·선후·우선순위·필수누락 | 0건 (하드) | 제약 모델 인코딩 · 최적화 모듈 보장 |
| 재현성 | 동일 입력 → 동일 해 | 100% (하드) | 5회 반복 동일 출력 확인 |
| LLM 계획서 누락·날짜 불일치 | 서술값 vs 최적화 모듈 산출값 차이 | 0건 (하드) | 최적화 모듈 원본 대조 · 불일치 시 거부 |
| HITL 격리 정확도 | 예외 항목만 사람 검토로 분리 | 100% (하드) | 최적화 모듈 플래그 기준 · 오격리 0 |
| 설비 가동률 | 배치 점유시간 / 가용시간 | 협의 (예: ≥70%) | 설비 마스터 확정 후 합의 |
| 마감 준수율 | 납기 내 완료 항목 비율 | 협의 (예: ≥95%) | 납기 분포·물량 전제 합의 |
| 재조정 delta 비율 | 재계획 시 변경되는 배치 비중 | 협의 (예: ≤20%) | 안정성 정책 합의 후 측정 |
| 파이프라인 처리시간 p95 | 계획 생성 요청→완료 95분위 | 협의 | 물량 규모·인프라 전제 합의 |
| 시험리스트 추출 정규화 정확도 | 비정형 추출→마스터 정합 비율 | 협의 | 층화표본 검수로 산정 |
KPI를 목표치로 적었다면, 그 목표를 무엇으로 확인할지도 함께 적어야 한다. 그래서 저는 합격선을 재는 검증셋을 여섯 유형으로 구성하기를 권한다. 정상 케이스로 충돌 0·재현성을 보고 충돌·포화·재조정 케이스로 제약과 안정성을, infeasible 케이스로 HITL 격리를, 그리고 LLM 일관성 케이스로 서술값이 최적화 모듈 산출값과 어긋나지 않는지를 본다. 이 여섯 유형이 곧 인수검수의 골든셋이 된다.
| 검증셋 유형 | 구성 | 확인 KPI |
|---|---|---|
| 정상 | 제약을 모두 만족하는 표준 의뢰 | 충돌 0 · 제약 위반 0 · 재현성 |
| 충돌 | 동일 장비·시간대 중복을 심은 의뢰 | 충돌 감지 · 재조정 delta |
| 포화 | 잔여 면적이 거의 찬 상황의 신규 의뢰 | 용량 제약(포화율 70%) |
| 재조정 | 기존 일정 위에 고우선 의뢰 삽입 | delta 최소화 · 기존 일정 보존율 |
| infeasible | 물리적으로 풀 수 없는 제약 | HITL 격리 동작(LLM 폴백 금지) |
| LLM 일관성 | 정상 케이스 최적화 모듈 결과의 계획서 서술 | 누락 0 · 날짜 불일치 0 |
효과를 약속하기 전에 먼저 점검해야 할 것들이 있다. 도입 전 미결 항목을 우선순위 두 단계로 정리했다. P0(착수 전 필수)는 세 가지다. ①스케줄링 최적화 모듈 방식 확정 — LLM 단독으로 갈지 전용 최적화 모듈+LLM 서술 구조로 갈지를 PoC로 먼저 검증해야 한다. 이 결정이 전체 아키텍처를 가른다. ②시험항목 약 114종 확정과 데이터 정의 범위·일정 — 마스터 데이터가 곧 최적화 모듈의 입력이므로, 항목 정의가 흔들리면 일정 전체가 흔들린다. 현업이 리딩해야 하는 크리티컬 패스다. ③AI 에이전트 ↔ 시험관리 플랫폼 합동 인터페이스 정의서 — 요청/응답 스키마, 변경내역 2채널, 재시도·멱등성을 양측이 함께 합의해야 한다. P1(병행 정비)은 둘이다. ④결정성·재현성 정책과 검수 KPI(동일 입력 동일 해, infeasible은 LLM 폴백 금지하고 명시적 예외 처리), ⑤설비 기준정보 관리 화면 신설(장비 마스터 갱신 경로 확보).
| 우선순위 | 점검 항목 | 미결 시 리스크 · 합의 주체 |
|---|---|---|
| P0 | 스케줄링 최적화 모듈 방식 확정 (LLM 단독 vs 전용 최적화 모듈+LLM 서술, PoC 선행) | 잘못 택하면 충돌 0·재현성 100% 달성 불가 → 전면 재설계 · 아키텍트 + 기술리드 |
| P0 | 시험항목 약 114종 확정 · 데이터 정의 범위·일정 | 마스터 미확정 시 입력 부재로 최적화 모듈 가동 불가(크리티컬 패스) · 현업(시험기획/품질) 리딩 |
| P0 | AI 에이전트 ↔ 시험관리 플랫폼 합동 인터페이스 정의서 (스키마·변경내역 2채널·재시도·멱등성) | 경계 미합의 시 통합 단계 충돌·중복 전송 · 개발사 ↔ 플랫폼 컴포넌트 경계 합동 |
| P1 | 결정성·재현성 정책 및 검수 KPI (동일입력 동일해 · infeasible = LLM 폴백 금지) | 정책 부재 시 환각 일정이 통과될 여지 · 아키텍트 + 현업 검수 |
| P1 | 설비 기준정보 관리 화면 신설 (장비 마스터 갱신 경로) | 갱신 경로 부재 시 설비 변경이 일정에 반영 안 됨 · 플랫폼 + 현업 |
14. 언제 최적화 모듈+LLM을 쓰고 언제 피하나
지금까지 이 케이스를 한 문장으로 압축하면 이렇다 — 조합 최적화는 전용 최적화 모듈이 결정적으로 풀고 그 결과를 LLM이 사람이 읽을 계획서로 서술하며 사람이 게이트에서 확정한다. 이 구조가 우아한 이유는 각 구성요소가 자신이 가장 잘하는 일만 맡기 때문이다. 최적화 모듈은 충돌 0·제약 위반 0을 수학적으로 보장하고 LLM은 비정형 입력 해석과 자연어 서술이라는 언어 작업을 담당하며 사람은 책임이 따르는 최종 확정을 진다. 그러나 우아함은 만능과 다르다. 이 아키텍처는 적용 조건을 잘못 잡으면 곧바로 과설계가 된다. 제약이 두세 개뿐인 문제에 최적화 모듈을 얹고 자유서술이 본질인 일에 굳이 최적화를 끼워 넣는 순간, 운영 비용만 늘고 효용은 사라진다. 그래서 마지막 절은 "이 패턴을 어디에 쓰고 어디에 쓰지 말아야 하는가"를 정직하게 가른다.
먼저 적합한 자리다. 이 최적화 모듈+LLM 하이브리드는 다섯 조건이 함께 성립할 때 정석이 된다. ①자원·시간·공간 제약이 동시에 작용하는 조합 최적화(일정·배치·할당)여서 경우의 수가 폭발할 때. ②결정성·재현성이 검수·운영 요건일 때 — 같은 입력에 같은 결과를 내야 책임 소재가 명확해진다. ③결과를 사람이 읽을 문서로 서술해야 할 때 — 단순 숫자 덤프가 아니라 근거와 맥락이 담긴 계획서가 산출물일 때. ④제약 위반이 치명적일 때 — 안전·납기·책임이 걸려 한 건의 충돌도 용납되지 않을 때. ⑤재조정 시 기존 일정 보존, 즉 delta 최소화가 중요할 때 — 이미 통보된 일정을 함부로 흔들면 현장 신뢰가 무너지기 때문이다. 이 다섯이 겹치는 영역이 바로 최적화 모듈이 결정하고 LLM이 설명하는 구조가 가장 큰 값을 내는 지점이다.
반대로 피해야 할 자리도 분명하다. ①제약이 단순·소수여서 그리디 휴리스틱이나 몇 줄의 규칙으로 충분한 문제에 최적화 모듈을 얹으면 모델링 비용만 든다. ②자유서술 생성이 본질이고 최적화 요소가 없다면 그냥 LLM 또는 RAG가 맞다. ③일회성·소규모 작업은 수기나 엑셀로 끝나며 파이프라인을 세우는 것 자체가 낭비다. ④이미 정형 데이터가 갖춰져 BI 쿼리 한 방으로 답이 나오는 문제에 에이전트를 붙일 이유는 없다. ⑤사람 검토가 불필요한 실시간 자동 결정은 룰 엔진이나 분류 모델이 더 빠르고 싸다. 요컨대 조합 폭발과 결정성 요건이 둘 다 없으면, 이 아키텍처는 효용보다 무게가 크다.
미결 쟁점도 정직하게 남겨 둔다. 최적화 모듈 알고리즘 계열은 데이터 규모를 측정한 뒤 PoC로 확정한다. 제약 충족 우선이라면 CP-SAT가 1순위지만 규모가 커져 결정적 최적해 탐색이 시간 안에 끝나지 않으면 GA/SA 같은 휴리스틱이나 EDF/SPT 디스패칭 규칙으로 내려가는 선택이 합리적일 수 있다. 즉 "CP-SAT 1순위"는 출발점일 뿐 결론이 아니며 실제 분포(품종 수·시험 종류·장비 가용창)를 측정해야 답이 확정된다. 또 하나 강조할 점은 순서다. 합동 인터페이스 정의서와 데이터 정의를 먼저 읽고 6개 엔티티 모델을 확정하는 일이 최적화 모듈 알고리즘 선택보다 앞선다. 모델이 비어 있으면 어떤 최적화 모듈을 골라도 최적화할 대상이 없기 때문이다.
그래서 도입 여부를 가르는 결정 체크리스트를 여섯 항목으로 정리했다. 각 항목은 단순한 질문 하나와, 그 질문이 "예"일 때 끌어와야 할 핵심 에이전트 패턴에 대응한다. 여섯 질문이 모두 "예"라면 최적화 모듈+LLM 하이브리드가 정석이고 하나라도 "아니오"가 섞이면 그 항목이 비용 대비 효용을 떨어뜨리는 지점이므로 더 가벼운 설계를 다시 검토해야 한다. 아래 표는 그 여섯 질문을 각각 어떤 패턴으로 충족하는지까지 매핑한 것이다.
| 체크 항목 | 확인 질문 | 핵심 패턴 |
|---|---|---|
| 조합 폭발 | 자원·시간·공간 제약이 동시에 작용하는가? | Planning(제약 최적화 모듈) |
| 제약 위반 0 | 충돌·제약 위반 0을 검증해야 하는가? | Evaluation(사후 검증) |
| 재현성 | 같은 입력에 같은 결과(재현성)가 검수 요건인가? | Tool Use(결정적 최적화 모듈 호출) |
| 서술 산출 | 결과를 사람이 읽을 서술로 내야 하는가? | LLM 서술(echo+narrative) |
| 데이터 확보 | 6개 엔티티를 확보·정의할 수 있는가? | 데이터 준비(엔티티 모델링) |
| 검토 게이트 | 사람 검토 게이트가 필요한가? | HITL(게이트 확정) |
마지막으로 이 도메인에서 가장 위험한 선택을 분명히 해 둔다. 그것은 LLM이 알아서 일정을 짜게 만드는 것이다. LLM은 그럴듯한 일정을 술술 내놓지만 그 일정에 충돌이 없다는 보장은 어디에도 없다 — 보장이 없는 일정은 일정이 아니라 초안일 뿐이고 초안을 확정으로 통보하는 순간 책임은 설계자에게 돌아온다. 옳은 분업은 처음부터 명확하다. 최적화 모듈이 계산하고 LLM이 설명하고 게이트가 검토한다. 무엇을 LLM에 맡기고 무엇을 최적화 모듈에 맡길지를 구분하는 안목 — 결국 이 도메인의 정석은 화려한 모델이 아니라 그 경계를 정확히 긋는 판단력에 있다.
케이스 스터디 · 계산은 최적화 모듈, 서술은 LLM · Planning · Tool Use · HITL · Evaluation을 중심으로 본 제약 스케줄링 적용 분석
에이전틱 AI를 공부할 때 우리는 "LLM이 알아서 한다"는 그림을 먼저 떠올린다. 하지만 일정·배치·충돌 같은 조합 최적화는 LLM이 신뢰성 있게 풀 수 있는 문제가 아니다. 이 케이스의 설계가 내린 가장 중요한 결정은 단 한 줄로 압축된다 — AI가 일정을 짜주는 게 아니라, 최적화 모듈이 풀고 AI가 설명한다. 전용 제약 최적화 모듈이 충돌 0·제약 위반 0·같은 입력에 같은 일정을 책임지고 LLM은 그 결정값을 사람이 읽을 계획서로 서술만 한다. 계산과 서술을 갈라놓는 이 한 번의 분리가 결정성·재현성·검수 가능성을 동시에 지켜낸다. 무엇이든 LLM에 떠넘기고 싶은 유혹 앞에서, "이건 최적화 모듈의 일, 저건 LLM의 일"을 구분하는 안목 — 그것이 고책임 엔터프라이즈 도메인에서 자동화보다 먼저 와야 할 설계 원칙이다.
- Google OR-Tools — CP-SAT Solver(제약 프로그래밍 최적화 모듈)
- Google OR-Tools — Job-Shop·자원 제약 스케줄링 가이드
- LangGraph 공식 문서 — Plan-and-Execute · Human-in-the-loop
- Google ADK 공식 문서 — LlmAgent · FunctionTool(도구 호출)
'Agentic AI Case Studies' 카테고리의 다른 글
| AI에게 배합 비율을 묻지 마라 — 계산은 옵티마이저에, 설명만 LLM에 (0) | 2026.06.25 |
|---|---|
| 가장 비슷한 과거값이 정답은 아니다 — 사출 수축률을 추천하고 학습하는 HITL 에이전트 (0) | 2026.06.20 |
| AI는 품질 대책서를 써주지 않는다 — 비정형 문서를 다루는 HITL 에이전트 설계 (1) | 2026.06.19 |