TL;DR — 수년간 쌓인 사출 수축률 적용 이력에서 유사 부품을 검색하되, 단순 유사도가 아니라 품질 이슈·최신성 가중으로 순위를 보정하고, 여러 추천을 사람이 확정하며, 확정값을 다시 학습 데이터로 되먹이는 RAG+HITL+학습 환류 에이전트 케이스다. 핵심은 "AI가 자동으로 값을 정한다"가 아니라 "AI가 후보·근거를 제시하고 사람이 확정한다"는 설계 선택이다.
유사 검색 → 가중 랭킹 → 다중 추천 → 사람 확정 → 재색인
이 한 케이스가 RAG·가중 랭킹·HITL·학습 루프를 핵심으로, 여러 에이전틱 디자인 패턴을 동시에 요구한다.
1. 가장 비슷한 값을 그대로 쓰지 않은 이유
사출 성형으로 플라스틱 부품을 만들 때, 설계자는 금형 치수를 정하기 전에 수축률을 먼저 정해야 한다. 용융된 수지가 금형을 채우고 식으면서 부품이 줄어드는 비율인데, 이 값을 잘못 잡으면 부품이 인접 부품에 맞지 않거나 틈이 벌어진다. 한 번 깎은 금형을 다시 수정하는 비용은 적지 않으니, 수축률 결정은 제조 품질 관리 도메인에서 비용이 큰 의사결정이다. 발주사(현업)에는 수년간 쌓인 수축률 적용 이력이 있었고, 이 자산을 본 사람이라면 자연스럽게 이런 기대를 품는다. "비슷한 부품의 과거 수축률을 찾아 그대로 추천하면 되지 않을까?"
이 글은 그 기대가 절반만 맞다는 데서 출발한다. 결론부터 적으면, 이 에이전트의 정체성은 자동 결정이 아니라 추천과 확정의 분리다. AI는 과거 이력에서 후보 수축률을 찾아 제시하고, 실제로 어떤 값을 쓸지 확정하는 것은 사람이다. 그리고 사람이 확정한 값은 버려지지 않고 다시 학습 데이터로 쌓여, 다음 추천의 근거가 된다. 검색·추천·확정·학습이 한 줄로 맞물린 구조다.
가장 비슷한 과거값을 자동으로 채우지 않은 이유는 두 가지다. 첫째, 단순 유사도만으로는 좋은 추천이 되지 않는다. 가장 비슷해 보이는 사례가 사실은 오래전 값이거나, 당시 품질 이슈가 있었던 사례일 수 있다. 원천 자료도 유사 검색 결과를 그대로 쓰지 말고 품질 이슈 평가 결과와 최신성으로 가중치를 줘서 순위를 보정하라고 못박는다. 둘째, 수축률은 책임이 따르는 값이다. 신규 수지나 처음 거래하는 원소재 업체처럼 과거 데이터가 빈약한 경우, AI가 억지로 값을 채우면 그것은 근거 없는 추정이 된다. 그래서 설계는 AI 출력을 항상 '추천'으로 라벨링하고, 확정은 사람이 하도록 분리했다.
현실에 빗대면 이렇다. 신입이 혼자 수축률을 정해 버리는 구조가 아니다. 옆자리 베테랑이 "예전 비슷한 품종이 이 정도였는데, 그때 품질 문제가 있었으니 그대로 쓰지 말고 최근 안정된 값을 참고하자"라고 후보와 근거를 같이 짚어 주고, 최종 판단은 담당자가 한다. 이 케이스에서 AI는 그 베테랑 역할이다. 후보를 찾아 주고 왜 그 순위인지 근거를 붙이지만, 확정 버튼은 사람이 누른다.
이 선택에는 정직하게 드러낼 트레이드오프가 있다. 추천과 확정을 나누면 완전 자동화보다 처리량이 낮고, 사람의 손이 매번 들어간다. 또한 확정값을 학습 데이터로 되먹이는 환류 루프는 언제, 어떤 검증을 거쳐, 어떻게 쌓을지를 사전에 합의해야 동작한다. 원천 자료가 "이후 사용되는 수축률 데이터의 증분 방법은 협의가 필요하다"라고 미결로 남긴 부분이다. 그럼에도 이 케이스를 고른 이유는 분명하다. 데이터가 알려주되 사람이 책임지고, 그 책임의 결과가 다시 데이터가 되는 — 추천형 AI가 현장에서 자리 잡는 한 가지 방식을 보여 주기 때문이다.
2. 흩어진 수축률 이력과 세 갈래의 일
출발점은 단순하다. 발주사(현업)에는 부품마다 적용한 수축률 이력이 쌓여 있었지만, 그 자체로는 추천에 바로 쓸 수 없는 상태였다. 이력은 부품의 메타 정보(타입·스펙·원소재 업체·공정·권역·기본 수축률)와 따로 놀았고, 무엇보다 과거 품질 이슈 평가 결과나 개선 대책 자료에 적힌 수축률 정보와 연결되어 있지 않았다. 원천 자료는 이 둘을 "매칭하여 데이터를 구축할 필요가 있다"라고 명시한다. 즉 추천을 시작하기 전에, 흩어진 수축률 값과 품질 이력을 한 부품 단위로 엮는 일이 먼저다.
시스템이 떠맡는 일은 세 갈래로 갈라진다. 이 분리는 메뉴 구분이 아니라, 각 일이 서로 다른 시점·서로 다른 책임자·서로 다른 패턴을 요구하기 때문에 떼어내야 하는 경계다. 첫째는 검색 자산화다. 부품 메타와 품질 이슈, 과거 대책 자료의 수축률을 결합해 검색 가능한 형태로 만들고, 임베딩과 메타 인덱스를 구축한다. 둘째는 추천 생성이다. 사용자가 화면에서 검토 대상 부품을 골라 요청하면, 유사 부품을 검색해 가중치로 순위를 매기고 추천 수축률을 만들어 화면에 띄운다. 셋째는 학습 환류다. 사용자가 확정한 값과 수정 이력을 검증 완료 데이터로 저장하고 다시 색인해, 다음 추천의 근거로 되먹인다.
세 일의 관계를 흐름으로 보면, 검색 자산화가 흩어진 이력을 검색 가능한 지식으로 갈아 넣고(오프라인), 그 위에서 추천 생성이 사용자 요청마다 동작한다(온라인). 그리고 추천이 끝나는 지점이 곧 학습이 시작되는 지점이다. 사람이 확정한 수축률이 환류되어 자산을 키우는 이 마지막 고리가, 이 케이스를 한 번 쓰고 마는 검색기와 구분 짓는다.
"그냥 가장 가까운 과거 사례를 찾아서 그 수축률을 쓰면 되는 것 아닌가? 가중이니 확정이니 왜 복잡하게 만들지?"
② 오래된 값일수록 현재 공정과 멀어진다 — 재료나 설비가 바뀌면 같은 부품이라도 적정 수축률이 달라진다. 최신성을 순위에 반영해야 한다.
③ 신규 부품에는 비슷한 과거가 거의 없다 — 이 콜드스타트에서 단순 검색은 빈손이거나 엉뚱한 값을 끌어온다. 그래서 사람 확정과 학습이 단순 유사도 위에 얹힌다.
3. 세 레이어로 나눈 아키텍처
이 시스템은 하나의 큰 파이프라인이 아니라, 검색 자산화 / 추천 생성 / 학습 환류라는 세 레이어로 나뉜다. 나눈 이유는 단순하다. 세 레이어는 가동 시점과 책임이 근본적으로 다르다. 검색 자산화는 원천 데이터가 바뀔 때 도는 배치 작업이다. 추천 생성은 사용자가 화면에서 요청하는 실시간 처리다. 학습 환류는 사용자가 값을 확정한 뒤에 일어나는 후처리다. 성격이 다른 이 작업들을 같은 실행 경로에 묶으면, 대량 색인 작업이 도는 동안 사용자의 추천 요청이 막히는 자원 경합이 생긴다. 레이어 경계가 곧 실패 격리 경계이자 확장 단위다.
데이터는 한 방향으로만 흐르지 않는다. 검색 자산화에서 추천 생성으로 이어지는 직선 흐름 위에, 추천 생성에서 다시 검색 자산화로 돌아가는 피드백 루프가 얹힌다. 사람이 확정한 수축률과 수정 이력은 검증 완료 데이터로 저장되고, 검색 인덱스에 증분 색인되어 다음 추천의 후보가 된다. 오늘 한 담당자가 확정한 값이 내일 다른 담당자의 추천 근거가 되는 구조다. 처음에는 정적이던 이력이 운영하면서 스스로 자라는 자산으로 바뀌는 지점이며, 원천 자료도 이 환류를 "향후 추천 품질 개선 데이터로 활용한다"라고 적고 있다.
레이어를 인터페이스로 끊어 둔 또 다른 실익은 교체 가능성이다. 검색 레이어의 내부 구현을 바꾸더라도, 추천 레이어는 "검색하면 근거가 붙은 유사 후보가 돌아온다"는 계약만 지켜지면 영향받지 않는다. 다만 이 깔끔한 분리에도 정직하게 드러낼 난제가 있다. 첫째, 피드백 루프가 검색 품질을 떨어뜨릴 위험이다 — 잘못 확정된 값이나 중복된 값이 그대로 재색인되면 검색 공간이 오염되므로, 등록 전 검증 단계가 환류의 전제 조건이 된다. 둘째, 추천에 쓰는 검색 자산을 과거 품질 자료의 검색 자산과 공용할지 따로 둘지가 아직 정해지지 않았다. 레이어로 나눈 덕에 각 레이어는 단순해졌지만, 환류 품질과 자산 귀속이라는 두 난제는 오히려 또렷해졌다.
4. 핵심 패턴 ① RAG — 유사 검색을 넘어 가중 랭킹으로
이 시스템에서 검색 증강(RAG)을 핵심으로 분류한 이유는 분명합니다. 추천의 출발이 곧 과거 수축률 이력에서 유사 부품을 찾는 검색이기 때문입니다. 그런데 여기서 멈추지 않는 것이 이 케이스의 특징입니다. 검색은 두 단계로 나뉩니다. 먼저 정규화된 부품 메타로 검색 조건을 만들고, 부품 타입·스펙·원소재 업체·공정·권역 같은 정형 키로 거르면서 의미가 비슷한 사례를 찾아 후보 목록(TopK)을 확보합니다. 정형 필터와 의미 검색을 함께 쓰는 하이브리드 방식입니다.
진짜 설계 결정은 그 다음에 있습니다. 원천 자료는 검색 결과를 그대로 쓰지 말라고 합니다. 유사도에 더해 품질 이슈 평가 결과와 최신성으로 가중치를 줘서 순위를 다시 매기라는 것입니다. 가장 비슷한 사례가 1순위가 아닐 수 있다는 뜻입니다. 당시 품질 이슈가 있었던 사례는 점수를 깎고, 최근에 안정적으로 적용된 사례는 점수를 올립니다. 여기에 더해, 이미 충분히 검증되어 최종 튜닝된 수축률(골든값)이 있는 부품이라면 그 값을 우선 반영합니다.
이 가중 공식에서 정직하게 밝혀야 할 부분이 있습니다. 가중치 계수를 얼마로 줄지, 어떻게 정규화할지는 아직 정해지지 않았습니다. 원천 자료는 "가중치를 적용한다"라고만 적었을 뿐 구체적인 공식이나 값을 주지 않습니다. 그래서 위 의사코드의 계수는 형태를 보여 주기 위한 예시이며, 실제 값은 현장 데이터로 맞춰 가야 하는 협의 대상입니다. 데이터 관점에서 한 가지 덧붙이면, 후보 수축률을 합칠 때 단순 평균보다 중앙값에 가까운 방식이 이상치에 강합니다. 오입력이나 특수 조건의 값 하나가 추천 전체를 흔들지 않도록, 분포에서 크게 벗어난 값은 걸러내는 편이 안전합니다.
타입·스펙·업체·공정·권역
여기서 한 번 멈추고 자주 나오는 질문에 답하겠습니다. "유사도 검색으로 수축률을 추천하는 게 맞나? XGBoost 같은 머신러닝 회귀 모델을 써야 하지 않나?" 타당한 지적입니다. 수축률 예측은 입력 인자(타입·스펙·원소재 업체·공정·권역·벽 두께·보압 등)로 연속 수치를 맞히는 본질적으로 회귀 문제이고, 정형 데이터 회귀에서 XGBoost·LightGBM 같은 부스팅 모델이 강력한 건 사실입니다.
다만 한 가지를 짚어야 합니다. 지금의 "유사 검색 + 가중 랭킹"도 머신러닝으로 보면 이미 가중 k-최근접이웃(k-NN) 회귀입니다. 가장 비슷한 K개를 찾아 가중 집계로 값을 추정하는 비모수 회귀죠. 그러니 질문의 진짜 구도는 "검색이냐 머신러닝이냐"가 아니라 "k-NN 회귀냐, 더 강한 회귀냐"이고, 둘은 택일이 아니라 데이터 성숙도에 따른 단계 관계입니다.
검색(k-NN)은 설명가능성·콜드스타트·증분 학습·다중 추천에서 강하고, 부스팅 회귀는 데이터가 충분할 때의 정확도와 새 조합 예측에서 강합니다. 책임이 따르고(금형 비용) 데이터의 양·품질이 아직 불확실하며 사람 확정·학습 환류와 맞물리는 이 도메인에서는, 검색이 합리적인 출발점입니다. 하지만 종착점은 아닙니다. 권장하는 길은 단계적 전환입니다. Phase 1에서는 검색으로 시작해 사람 확정으로 라벨(정답 수축률)을 모으고, Phase 2에서는 라벨이 충분해지면 회귀 모델을 병행해 오차(RMSE·MAE)와 채택률로 비교하며, 하이브리드에서는 검색이 근거와 다중 후보를 보여 주고 회귀가 점추정을 맡도록 합칩니다. 그리고 학습 환류로 라벨이 쌓이는 구조 자체가 자연스럽게 Phase 2로 가는 발판이 됩니다.
위 의사코드는 프로덕션 코드가 아니라 개념을 드러내는 골격입니다. 실제 구현에서는 점수 융합 방식(가중합인지 재정렬인지), 정규화 범위, 골든값과 일반 후보의 충돌 처리 같은 결정이 더 필요합니다. 그럼에도 이 골격을 먼저 보여 주는 이유는, 이 케이스의 핵심이 "검색을 잘하느냐"가 아니라 "검색 결과를 어떻게 다시 줄 세우느냐"에 있기 때문입니다. 다음 절에서는 이렇게 줄 세운 후보들을 사람이 어떻게 고르고 확정하는지를 다룹니다 — 추천은 여기서 끝이 아니라 시작입니다.
5. 핵심 패턴 ② HITL — 다중 추천과 사람의 확정
검색과 가중 랭킹을 거쳐 만들어진 후보들은 LLM을 통해 추천 내용으로 정리됩니다. 이때 화면에 올라가는 것은 하나의 정답이 아니라 여러 개의 추천 수축률입니다. 원천 자료가 "여러 추천 수축률 값을 표시하고, 사용자가 선택·확정하는 화면"을 명시하기 때문입니다. 각 추천에는 근거가 붙습니다. 어떤 과거 부품을 참조했는지, 그 사례의 연도와 품질 상태는 어땠는지, 신뢰도는 얼마인지를 함께 보여 줍니다. 사용자는 이 근거를 보고 값을 고르거나, 직접 수정하거나, 적절한 후보가 없으면 거부합니다.
이 지점이 추천형 AI를 단순 검색기와 가르는 분기입니다. 시스템은 답을 정해 주지 않습니다. 방향과 근거를 제시하고, 결정은 사람에게 넘깁니다. 잘못된 수축률이 금형 비용과 품질 문제로 직결되는 도메인에서, 확정 게이트는 선택이 아니라 필수입니다. 그리고 이 확정 행위에는 또 다른 의미가 있습니다. 사용자가 "이 값을 쓰겠다"라고 누르는 순간, 그 선택은 곧 학습 라벨이 됩니다. 사람의 판단이 다음 추천을 가르치는 데이터로 바뀌는 것입니다.
여기서도 트레이드오프를 숨기지 않겠습니다. 추천이 신뢰할 만한 근거를 충분히 찾지 못했을 때, 시스템은 억지로 값을 만들기보다 "참조할 만한 과거 수축률이 없으니 직접 입력하라"고 물러서는 편이 안전합니다. 이렇게 하면 신규 부품 같은 콜드스타트 상황에서 자동 채택을 막을 수 있지만, 대신 사람의 부담이 늘어납니다. 추천이 빈손으로 돌아오는 비율을 어디까지 허용할지, 신뢰도가 얼마 아래일 때 사람에게 넘길지 같은 임계값은 아직 정해지지 않았고(미정), 인수 검수 기준을 정할 때 함께 합의해야 할 부분입니다.
6. 핵심 패턴 ③ Memory·학습 — 확정값이 자산을 키운다
이 케이스에서 가장 특징적인 부분은 추천이 끝난 뒤에 일어납니다. 사용자가 확정한 수축률과 수정 이력은 그대로 사라지지 않고, 검증 완료 데이터로 저장되어 다시 색인됩니다. 원천 자료는 이를 두 단계로 적습니다. 먼저 확정값과 수정 이력을 학습 데이터로 보내고(증분), 그 다음 검증 완료 데이터를 신규 데이터로 등록합니다. 등록된 값은 검색 인덱스에 더해져, 다음 사용자가 비슷한 부품을 요청할 때 후보로 떠오릅니다.
이 환류가 만드는 변화는 큽니다. 처음에는 과거 이력만 있던 정적 자산이, 운영하면서 사람의 확정이 누적되는 살아 있는 자산으로 바뀝니다. 같은 부품에 대해 확정이 한 건에서 열 건으로 쌓이면 추천의 신뢰도가 올라가고, 신규 부품도 한 번 확정되고 나면 다음부터는 검색 후보가 생깁니다. 콜드스타트가 시간이 지나면서 완화되는 구조입니다.
그리고 이 학습 환류에는 숨은 가치가 하나 더 있습니다. 사람이 누른 확정값은 곧 머신러닝이 학습할 정답 라벨입니다. 그래서 이 루프는 추천 품질을 높이는 장치이면서, 동시에 앞 절에서 말한 Phase 2(회귀)로 가는 데이터 적재 장치이기도 합니다. 운영할수록 회귀 모델이 학습할 입력과 정답의 쌍이 저절로 쌓이는 셈이죠. 다만 나중에 회귀로 매끄럽게 갈아타려면 지금부터 두 가지를 설계에 박아둬야 합니다. 추천 엔진을 내부 구현을 갈아끼울 수 있는 형태로 추상화해 두는 것(검색이든 회귀든 같은 방식으로 호출되도록), 그리고 확정 데이터를 검색용만이 아니라 회귀가 바로 쓸 수 있는 형태로도 함께 저장해 두는 것입니다. 이 둘을 빠뜨리면, 토대는 있었는데 막상 전환할 때 다 뜯어고쳐야 하는 상황이 됩니다.
위 의사코드에서 가장 중요한 줄은 2단계의 검증·등록 게이트입니다. 학습 루프의 매력은 자산이 스스로 자란다는 데 있지만, 그 자람이 통제되지 않으면 오히려 검색 공간을 망가뜨립니다. 잘못 확정된 값, 같은 부품에 대한 서로 다른 확정, 중복 등록을 거르지 않고 쌓으면 다음 추천의 근거가 오염됩니다. 그래서 원천 자료가 직접 "증분 방법은 협의가 필요하다"라고 미결로 남긴 것이며, 위 코드의 validate / is_duplicate / version은 그 협의가 채워 넣어야 할 빈칸입니다. 학습 루프는 이 케이스의 가장 큰 장점이자, 가장 신중하게 다뤄야 할 부분입니다.
7. 핵심 패턴 ④ 평가·가드레일 — 근거 없는 추천을 막는 장치
추천형 에이전트에서 가장 위험한 실패는 근거 없이 그럴듯한 값을 내놓는 것입니다. 그래서 LLM 추천 단계에는 몇 가지 가드레일이 들어갑니다. 첫째, 검색으로 확보한 근거 안에서만 추천을 만들고, 근거 밖의 수치를 지어내지 못하게 막습니다. 둘째, 추천한 수축률에는 출처를 붙입니다. 어떤 과거 부품과 자료를 참조했는지 명시해, 사용자가 근거를 직접 확인할 수 있게 합니다. 셋째, 신뢰도가 낮은 추천은 자동으로 채택되지 못하게 하고 사람의 검토를 거치도록 합니다. 넷째, 검증된 골든값이 있으면 생성보다 그 값을 우선합니다.
여기서 한 가지 더 짚을 설계 의문이 있습니다. 추천 수축률 값 자체를 LLM이 직접 만들게 하는 것은 재고할 부분입니다. LLM은 자연어 설명에는 강하지만 수치 예측에는 약하고 환각 위험이 있습니다. 더 안전한 분리는 역할을 나누는 것입니다. 수축률 값(점추정)은 통계·머신러닝이 계산하고(앞 절의 가중 집계나 회귀 모델), LLM은 그 값의 근거를 요약하고 설명을 생성하는 데만 쓰는 것이죠. 이렇게 하면 환각이 수치를 오염시키지 않습니다. 여러 추천값을 보여 주는 요건도 LLM이 아니라 통계 모델의 후보·분위수로 충족할 수 있습니다.
품질을 어떻게 측정할지도 설계에 들어갑니다. 검색이 적절한 후보를 잘 끌어왔는지, 추천값이 실제 확정값과 얼마나 가까웠는지, 사용자가 추천을 그대로 채택했는지 아니면 수정했는지, 학습 환류가 추천 정확도를 실제로 개선했는지를 지표로 봅니다. 그런데 여기서도 정직해야 합니다. 이 지표들의 합격선은 아직 정해지지 않았습니다. 원천 자료에는 정량 목표치가 없습니다. 그래서 합격선이 확정되기 전까지는 절대 기준으로 판정하기보다, 설계를 바꾸기 전과 후를 비교하는 방식으로 관리하는 편이 현실적입니다.
| 가드레일 | 막으려는 실패 | 처리 |
|---|---|---|
| 근거 강제 | 근거 밖 수치 창작(환각) | 검색으로 확보한 근거 안에서만 추천 생성 |
| 출처 표기 | 근거 확인 불가 | 참조한 과거 부품·자료를 추천마다 명시 |
| 신뢰도 게이트 | 약한 추천의 자동 채택 | 임계 미만은 사람 검토로 회부 (임계값 미정) |
| 골든값 우선 | 검증값 두고 생성에 의존 | 최종 튜닝된 값이 있으면 그 값을 앞세움 |
본문에 등장하는 가중치 계수·신뢰도 임계·합격선 등은 원천 설계 자료에 확정값이 없는 협의 대상(목표치)입니다. 특정 기업의 실측 결과가 아니며, 형태와 방향을 보여 주기 위한 설계 예시일 뿐입니다. 실제 값은 현장 데이터로 맞춰 가야 하며, 인수 검수 기준을 정할 때 함께 합의되어야 합니다.
8. 나머지 패턴 — 보조와 약함
핵심 네 축(RAG · HITL · 학습/메모리 · 평가/가드레일)을 떠받치는 나머지 패턴들은 보조 역할로 들어간다. 검색 조건을 만드는 단계에는 부품 메타에서 검색 키를 뽑아 구성하는 도구 사용·계획 성격의 처리가 있고, 추천 후보가 빈손이거나 신뢰도가 낮을 때 사람에게 넘기는 분기는 가벼운 라우팅이다. 학습 환류에서 확정 데이터를 저장하고 다시 불러오는 부분은 장기 메모리 패턴에 해당한다. 반면 자율적으로 목표를 세우고 여러 에이전트가 협업하는 식의 무거운 패턴은 이 케이스에서 약하게만 쓰인다. 단일 도메인의 추천 흐름을 굳이 여러 에이전트로 쪼개면 토폴로지가 본질을 잡아먹는다.
이 등급을 가른 기준은 "작동하느냐"가 아니라 "빼면 케이스가 무너지느냐"다. 라우팅·도구 사용·메모리는 분명히 작동하지만, 그 위에서 검색·가중·확정·학습이라는 정체성을 떠받칠 뿐 스스로 정체성을 만들지는 않는다. 약함으로 분류한 자율 목표 설정·멀티에이전트는 더 정직하게 선을 그었다 — 단일 조직 내부의 한 도메인 추천 흐름이라, 다중 에이전트의 본래 가치(원격 협업·역할 분담)가 약하게만 닿는다. 아래 매트릭스는 그 차등을 한 장으로 정리한 것이다.
| 등급 | 패턴 | 케이스 적용 한 줄 |
|---|---|---|
| 핵심 | RAG | 하이브리드 검색 + 가중 랭킹(유사도+품질이슈+최신성)으로 후보 수축률 회수 |
| 핵심 | HITL | 다중 추천 표시 → 사람의 선택·수정·거부 → 확정(추천과 확정의 분리) |
| 핵심 | 학습 · 메모리 | 확정값·수정 이력을 검증 완료 데이터로 재색인해 다음 추천 근거로 환류 |
| 핵심 | 평가 · 가드레일 | 근거 밖 수치 생성 차단·출처 부착·골든값 우선·낮은 신뢰도 사람 회귀 |
| 🟦 보조 | 도구 사용 · 계획 | 부품 메타에서 검색 키를 뽑아 검색 조건을 구성하는 전처리 |
| 🟦 보조 | 라우팅 | 추천이 빈손·저신뢰일 때 사람 직접 입력으로 넘기는 가벼운 분기 |
| 🟦 보조 | 장기 메모리 | 확정 데이터를 저장·재호출하는 검색 코퍼스(모델 파라미터 변경 아님) |
| ⬜ 약함 | 자율 목표 설정 | 결정 주체가 사람(HITL)이라 자율 목표 수립의 명분이 약함 |
| ⬜ 약함 | 멀티에이전트 | 단일 도메인 추천 흐름을 쪼개면 토폴로지가 본질을 잡아먹음 |
매트릭스가 던지는 교훈은 하나다. 실무 요건 하나는 결코 한 패턴으로 끝나지 않지만, 모든 패턴이 동등하지도 않다. 진짜 어려운 일은 쓸 패턴을 찾는 것이 아니라, 작동하는 것과 정체성인 것을 갈라 과대·과소평가를 둘 다 피하는 것이다. 가중 랭킹을 단순 검색과 같은 등급으로 두면 추천 품질이 무너지고, 멀티에이전트를 정체성으로 격상하면 단순한 흐름이 과설계로 부푼다.
9. 통합 아키텍처 — 한 장으로 본 흐름
지금까지 본 레이어와 패턴을 한 장으로 겹쳐 보면, 흐름은 이렇게 정리된다. 사용자가 화면에서 부품을 골라 요청하면, 메타가 정규화되어 검색 조건이 만들어지고, 하이브리드 검색이 유사 부품을 찾아 후보 목록(TopK)을 확보한다. 여기에 품질 이슈와 최신성 가중치가 붙어 순위가 보정되고, 골든값이 있으면 우선된다. LLM이 근거를 붙여 여러 추천을 만들면, 사람이 화면에서 고르고 확정한다. 확정값은 검증을 거쳐 인덱스에 재색인되어, 다음 추천의 근거로 돌아온다. 검색 · 가중 · 추천 · 확정 · 학습이 한 바퀴를 도는 구조다.
이 흐름에서 책임 경계는 세 군데에 인터페이스로 그어진다. 추천을 요청해 보내는 지점, 추천 결과를 받아 오는 지점, 그리고 확정값을 학습 데이터로 보내는 지점이다. 앞의 두 경계는 추천형 시스템에서 흔하지만, 세 번째 학습 송신 경계가 이 케이스에 고유하다. 학습 루프가 단계로 명문화되어 있기 때문에, 두 컴포넌트가 맞물리는 약속(인터페이스 정의서)도 두 군데가 아니라 세 군데를 함께 합의해야 한다. 이 세 번째 경계를 빠뜨리면 추천까지는 동작하지만 자산이 자라는 선순환이 끊긴다.
10. 설계가 어긋나는 세 지점
이 아키텍처를 그대로 가져다 쓸 때 자주 어긋나는 지점이 셋 있다. 미리 알아 두면 피할 수 있다. 세 지점 모두 코드 버그가 아니라 설계 단계의 전제 누락이라는 공통점을 가진다.
첫째, 단순 유사도에 기대는 것이다. 가장 비슷한 사례를 그대로 추천하면 구현은 쉽지만, 오래된 값이나 품질 이슈가 있던 값을 끌어온다. 원천 자료가 가중 랭킹을 명시한 이유가 여기 있다. 유사도는 출발일 뿐, 품질과 최신성으로 보정해야 추천이 쓸모 있어진다.
둘째, 콜드스타트를 무시하는 것이다. 신규 부품이나 처음 거래하는 원소재 업체에는 비슷한 과거가 거의 없다. 이때 억지로 값을 채우면 근거 없는 추천이 된다. 추천을 보류하고 사람에게 직접 입력을 넘기는 후퇴 경로를 처음부터 설계에 넣어야 한다.
셋째, 학습 환류를 검증 없이 여는 것이다. 확정값을 무조건 쌓으면 잘못된 값과 중복이 검색 공간을 오염시킨다. 등록 전 검증·승인·버전 관리라는 거버넌스 없이 루프만 연결하면, 자산이 자라는 게 아니라 망가진다.
세 경우 모두 공통 교훈은 하나다. "확정되지 않은 것을 확정처럼 설계하지 않는다." 가중치 계수도, 신뢰도 임계도, 증분 방법도 원천 자료에서는 미결로 남아 있다. 이를 임의의 수치로 메우는 순간 설계는 분석이 아니라 가정의 누적이 된다.
11. 재사용 가능한 설계 교훈 5선
이 케이스에서 다른 추천형 과제로 옮겨 쓸 만한 교훈을 다섯 가지로 정리한다. 각 교훈은 "왜 이 설계여야 하는가"의 논증과 함께 묶이는 패턴을 명시한다. 공통된 메타 교훈을 먼저 말하면 — 경계를 명확히 긋고, 권한을 사람에게 남기며, 모든 것을 표준 지표로 계측하라.
책임이 따르는 값일수록 AI는 후보를 제시하고 사람이 결정해야 한다. 잘못된 수축률이 금형 비용·품질 문제로 직결되는 도메인에서 확정 게이트는 선택이 아니라 필수다. AI 출력을 항상 '추천'으로 두고 확정 버튼을 사람에게 남기면, AI 실패가 곧 작업 중단이 아니라 '사람 주도로 전환'되는 안전한 저하 경로가 된다.
비슷함만으로는 부족하다. 품질 이슈 평가 결과와 최신성이 순위를 바꿔야 한다. 가장 비슷한 사례가 1순위가 아닐 수 있고, 당시 품질 이슈가 있던 사례는 점수를 깎고 최근 안정적으로 적용된 사례는 점수를 올려야 한다. 검증된 골든값이 있으면 생성보다 그 값을 우선한다. 후보를 합칠 때는 단순 평균보다 이상치에 강한 방식이 안전하다.
사람의 선택은 가장 좋은 학습 라벨이다. 확정값과 수정 이력을 검증 완료 데이터로 재색인하면, 처음에는 정적이던 과거 이력이 운영하면서 스스로 자라는 자산으로 바뀐다. 이 환류가 신규 부품의 콜드스타트를 시간이 풀어 주게 한다 — 한 번 확정되고 나면 다음부터는 검색 후보가 생긴다.
검증 없는 학습은 자산을 키우는 게 아니라 오염시킨다. 잘못 확정된 값, 같은 부품에 대한 서로 다른 확정, 중복 등록을 어떻게 처리할지 정하지 않으면 검색 공간이 망가진다. 그래서 등록 전 검증·승인을 두고, 버전을 관리하며, 충돌을 정리하는 거버넌스가 환류의 전제가 된다. 학습 루프는 이 케이스의 가장 큰 장점이자 가장 신중하게 다뤄야 할 부분이다.
가중치 계수, 신뢰도 임계, 합격선, 증분 방법이 미정이라면 그것을 정직하게 협의 대상으로 남기고, 임의의 수치로 메우지 마라. 근거 있는 목표치와 측정 프레임이 근거 없는 확정 수치보다 신뢰를 얻는다. 추천형 AI에서 가장 위험한 실패는 근거 없이 그럴듯한 값을 내놓는 것이고, 그 위험은 코드가 아니라 정직함으로 막는다.
다섯 교훈이 가리키는 방향은 일관된다. 데이터가 알려주되 사람이 책임지고, 그 책임의 결과가 다시 데이터가 된다. 이 다섯 축은 수축률 추천을 넘어, 비정형 이력과 전문가 판단이 섞인 어떤 추천형 도메인에도 그대로 이식된다.
12. 도입 기대효과 (목표치)
도입으로 기대하는 효과는 세 가지다. 수축률 결정에 드는 시간을 줄이고, 담당자별로 들쭉날쭉하던 값의 편차를 좁히며, 한 번 확정한 값이 다음에 재사용되도록 만드는 것이다. 다만 결론부터 못박으면, 이 효과 수치는 전부 도입 기대효과(목표치)이며 특정 기업의 실측이 아니다. 앞서 여러 번 짚었듯 원천 자료에는 정량 목표가 거의 없다.
왜 이 점을 강조하는가. 이 케이스의 As-Is가 "흩어진 과거 이력을 숙련자가 기억으로 수기 탐색"이라, 검색 적중률의 베이스라인이 사실상 없고 결정 시간도 작성자별 편차가 커 단일 기준값이 없기 때문이다. 베이스라인이 없는데 효과를 단정하면 그것은 분석이 아니라 마케팅이다. 그래서 이 케이스에서 더 정직한 표현은 "얼마를 개선한다"가 아니라, "무엇을 개선하려 하며, 그 합격선은 현장 데이터로 함께 정한다"이다.
| 기대효과 | 의미 | 목표 방향(가정) | 측정·전제 |
|---|---|---|---|
| 수축률 결정 시간 단축 | 후보를 직접 찾던 시간을 추천이 대신 | 단축(방향) | 파일럿 전·후 측정. Before 기준값 미확보 → 선측정 필요 |
| 담당자 간 값 편차 감소 | 같은 부품에 같은 근거로 수렴 | 감소(방향) | 동일 부품군 확정값 분산 비교. As-Is 편차 미확보 |
| 확정값 재사용률 | 추천 기반 확정값이 다음 추천 근거로 재사용 | 증가(방향) | 재색인 로그. 피드백 루프 운영 전제 |
| 유사 사례 검색 적중률 | TopK 안에 쓸 만한 후보가 포함되는 비율 | 기준값 협의 | Precision@K·Recall@K·MRR 병행. 합격선 미정 |
| 신규 부품 콜드스타트 완화 | 확정 누적으로 추천 가능 범위 확대 | 완화(방향) | 신규 부품의 추천 빈손율 추이. 장기 관찰 필요 |
이 표에서 설계적으로 가장 흥미로운 칸은 검색 적중률이다. 다른 지표가 "사람이 더 빨라졌나"를 보는 데 반해, 이 지표는 "시스템이 스스로 자라고 있나"를 본다. 확정값을 재색인하는 피드백 루프가 실제로 코퍼스를 키우면, 적중률은 운영을 지속할수록 우상향해야 한다. 다만 맹점이 있다 — 검증 통과 완성본만 색인하는 게이트가 없으면 저품질 값이 다음 추천의 근거를 오염시켜 적중률이 오히려 점진 회귀한다. 그래서 "재색인 전후 적중률·분포 드리프트 비교"가 단순 지표가 아니라 데이터 선순환이 진짜 품질을 올렸는지를 가르는 핵심 검수 항목이 된다.
13. 베스트 프랙티스 — 언제 쓰고, 언제 피하나
지금까지 본 아키텍처를 한 문장으로 압축하면 "과거 이력을 가중 랭킹으로 검색해 후보를 비추고, 그 위에서 사람이 확정하며, 확정값을 다시 코퍼스로 되먹이는 구조"다. 이 설계는 우아하지만 만능이 아니다. 적용 조건을 잘못 잡으면 과설계의 전형이 된다. 도입을 결정하려면 "내 문제가 이 네 축 — 가중 검색 · 사람 확정 · 학습 환류 · 품질 평가 — 을 실제로 요구하는가"를 먼저 따져야 한다.
핵심 논증은 이렇다. 이 아키텍처의 비용 대부분은 검색 자산화·가중 랭킹·HITL 확정 루프·평가 백본이라는 네 축에서 발생한다. 문제가 이 중 일부만 요구한다면 더 단순한 패턴(단일 호출 검색, 룰 기반 분류, 정형 쿼리)으로 충분하며 이 풀스택은 부채가 된다. 반대로 네 축을 모두 요구한다면 — 즉 과거 이력이 충분히 쌓여 있고, 그 값에 책임이 따라 사람의 확정이 불가피하며, 확정 결과가 다시 자산으로 자라야 가치가 생기고, 추천 품질을 지표로 관리해야 한다면 — 이보다 정직한 정석 아키텍처는 없다.
기능을 만들기 전에 합의해야 할 것들이 있다. 아래는 그 미결 안건을 착수 전 점검 체크리스트로 정리한 것이다. 특히 위의 둘은 미결 시 추천·환류 자체가 무너지는 최우선 항목이다.
| 착수 전 체크리스트 | 확인 질문 | 연결 패턴 |
|---|---|---|
| □ 가중 공식 | 유사도·품질이슈·최신성의 가중치 계수와 정규화를 현장 데이터로 정할 계획이 있는가? (착수 전 1순위) | RAG 리랭킹 |
| □ 증분(학습 환류) 방법 | 확정값을 어떤 검증·버전·충돌 정리를 거쳐 재색인할지 거버넌스를 합의했는가? (착수 전 1순위) | Learning · Memory |
| □ 세 인터페이스 경계 | 요청 송신·결과 수신·학습 송신 세 경계를 인터페이스 정의서로 못박았는가? | 통합 아키텍처 |
| □ 환각 게이트 | 근거 밖 수치 생성 차단·출처 부착·골든값 우선을 추천 단계에 넣었는가? | Evaluation · Guardrails |
| □ 콜드스타트 후퇴 경로 | 신뢰도 미달 시 추천을 멈추고 사람 직접 입력으로 회귀하는 경로를 처음부터 설계했는가? | HITL · Routing |
결국 이 모든 설계가 수렴하는 지점은 하나다. 데이터가 가장 비슷한 과거를 알려줄 수는 있어도, 그 값을 쓸지 결정하는 것은 사람이고, 그 결정이 다시 데이터가 되어야 한다. 검색이 후보를 비추고, 가중이 순위를 바로잡고, 사람이 확정하고, 학습이 그 확정을 자산으로 키운다. 가장 비슷한 값을 그대로 쓰지 않기로 한 첫 결정이, 이 네 장치를 모두 불러온 셈이다. 이 한 문장을 설계의 헌법으로 삼을 수 있는 문제라면 이 아키텍처는 정답이고, 그렇지 않다면 더 단순한 길을 택하라.
케이스 스터디 · 한 실무 요건 = 검색·가중·확정·학습의 한 바퀴 · 핵심 4종(RAG · HITL · Memory/Learning · Evaluation)을 중심으로 본 적용 분석
에이전틱 AI를 공부할 때 우리는 패턴을 한 개씩 배운다 — 검색 증강, 라우팅, 휴먼 인 더 루프, 메모리, 평가. 하지만 현장의 실무 요건 하나는 그 패턴들을 한꺼번에 요구한다. 이 케이스는 "과거 이력에서 후보를 찾아 가중 랭킹으로 비추고(RAG), 사람이 확정하며(HITL), 그 확정을 다시 자산으로 키우고(Memory·Learning), 근거 없는 추천을 게이트로 막는다(Evaluation·Guardrails)"는 네 축을 정체성으로 삼고, 나머지 패턴이 이를 떠받친다. 가장 중요한 한 줄은 변하지 않는다 — 가장 비슷한 과거값이 정답은 아니다. 데이터가 알려주되 사람이 책임지고, 그 책임이 다시 데이터가 되는 도메인에서, 이것이 자동화보다 먼저 와야 할 설계 원칙이다.
- LangGraph 공식 문서 — Human-in-the-loop · interrupt · 조건부 엣지
- LangChain 공식 문서 — RAG 튜토리얼(검색 증강 생성)
- Google ADK 공식 문서 — LlmAgent · Multi-agent · FunctionTool
- RAGAS 공식 문서 — RAG 평가 지표(faithfulness · answer relevancy)
'Agentic AI Case Studies' 카테고리의 다른 글
| AI에게 배합 비율을 묻지 마라 — 계산은 옵티마이저에, 설명만 LLM에 (0) | 2026.06.25 |
|---|---|
| AI는 시험 일정을 계산하지 못한다 — 제약 스케줄링 최적화 모듈과 LLM을 분리한 자동 배치 설계 (0) | 2026.06.23 |
| AI는 품질 대책서를 써주지 않는다 — 비정형 문서를 다루는 HITL 에이전트 설계 (1) | 2026.06.19 |