e-wikidversitye-wikidversity

구독하기

Tag: 사례연구

  • 벡터검색 정확도가 낮을 때 점검해야 할 7가지 원인

    벡터검색 정확도가 낮을 때 점검해야 할 7가지 원인

    RAG를 만들었는데 “분명 문서에 있는데 검색이 못 찾는다”는 문제는 거의 모든 팀이 겪습니다. 생성 모델이 아무리 좋아도 검색이 관련 문맥을 못 가져오면 답은 무너집니다. 이 글에서는 벡터검색 정확도가 낮을 때 점검할 원인을 우선순위대로 정리합니다.

    원인 1~2: 청킹과 정제 문제

    가장 흔한 원인은 검색이 아니라 그 앞 단계에 있습니다. 청크가 너무 커서 하나의 벡터에 여러 주제가 섞이면 임베딩이 흐려져 어떤 질문에도 어중간하게 매칭됩니다. 반대로 너무 작으면 핵심 문장이 문맥 없이 떠다닙니다. 또한 정제가 부실해 머리말·각주가 본문에 섞이면 노이즈가 임베딩을 오염시킵니다.

    원인 3: 부적합한 임베딩 모델

    영어 위주로 학습된 임베딩 모델을 한국어 문서에 쓰면 의미가 비슷한 문장끼리도 벡터 거리가 멀어집니다. 도메인 용어가 많은 경우(의료·법률·금융)에는 일반 모델보다 해당 언어와 도메인을 잘 반영하는 모델을 선택해야 합니다.

    원인 4: 거리 측정과 정규화

    코사인 유사도를 가정한 모델인데 벡터를 정규화하지 않고 유클리드 거리로 검색하면 결과가 망가집니다. 임베딩 모델 문서가 권장하는 거리 측정 방식과 정규화 여부를 반드시 확인하세요. 이 작은 설정 하나가 정확도를 좌우합니다.

    • 코사인 유사도: 정규화된 벡터, 의미 유사도에 일반적
    • 내적(dot product): 정규화 안 된 벡터에서 사용, 크기 반영
    • 유클리드 거리: 절대적 거리, 일부 모델에서만 적합

    원인 5~6: 질문과 문서의 표현 격차

    사용자는 “환불 어떻게 해요”라고 묻지만 문서에는 “청약 철회 절차”라고 적혀 있으면 순수 의미 검색만으로는 잘 안 잡힙니다. 이런 어휘 격차에는 키워드 검색(BM25)과 벡터 검색을 함께 쓰는 하이브리드 검색이 효과적입니다. 또한 질문을 LLM으로 확장·재작성하는 쿼리 변환도 도움이 됩니다.

    원인 7: 리랭킹 부재

    벡터 검색의 상위 결과가 정확히 1등은 아닐 때가 많습니다. 상위 후보를 넉넉히 뽑은 뒤 리랭커로 다시 정렬하면, 같은 검색 결과에서도 실제로 답에 쓰이는 청크의 적중률이 올라갑니다.

    진단 순서를 기억하세요: 정제 → 청킹 → 임베딩 모델 → 거리 설정 → 하이브리드/쿼리 변환 → 리랭킹. 위에서부터 막혀 있으면 아래를 아무리 손봐도 효과가 없습니다.

    정리

    벡터검색 문제는 대부분 검색 알고리즘이 아니라 그 앞뒤 단계에서 발생합니다. 작은 평가셋(질문-정답 청크 쌍)을 만들어 두고, 한 번에 한 가지 변수만 바꾸며 적중률을 측정하면 원인을 빠르게 좁힐 수 있습니다.

  • 중견 제조기업의 생성형 AI 도입기: 6개월간 무엇을 배웠나

    중견 제조기업의 생성형 AI 도입기: 6개월간 무엇을 배웠나

    생성형 AI 도입은 기술보다 조직과 데이터 문제에서 더 많이 막힙니다. 이 글은 한 중견 제조기업이 사내 문서 검색 챗봇을 도입하며 겪은 6개월의 여정을 정리한 사례 연구입니다. 특정 제품 이야기가 아니라, 같은 길을 갈 팀이 참고할 만한 의사결정과 교훈에 초점을 둡니다.

    출발점: 무엇이 문제였나

    이 기업은 수천 건의 작업 표준서와 설비 매뉴얼이 여러 시스템에 흩어져 있었습니다. 현장 직원이 필요한 절차를 찾는 데 평균 15분 이상 걸렸고, 베테랑의 암묵지가 문서화되지 않아 퇴직과 함께 사라지는 문제가 컸습니다. 목표는 “질문하면 출처와 함께 답하는 사내 챗봇”이었습니다.

    1~2개월차: 데이터의 벽

    가장 큰 난관은 모델이 아니라 데이터였습니다. 스캔된 PDF, 손글씨 메모, 버전이 뒤섞인 문서가 많아 그대로 인덱싱하면 검색 품질이 형편없었습니다. 결국 전체 일정의 절반 이상을 문서 정제와 메타데이터 정리에 썼습니다.

    교훈 1: 생성형 AI 프로젝트의 성패는 모델 선택이 아니라 데이터 준비에서 갈린다. 데이터 정제 공수를 일정의 절반으로 잡아라.

    3~4개월차: RAG 구축과 평가

    RAG 파이프라인을 구축한 뒤, 현장 질문 80개로 골든셋을 만들어 검색 적중률과 답변 충실성을 측정했습니다. 초기 적중률은 60% 수준이었는데, 청킹을 섹션 기반으로 바꾸고 하이브리드 검색을 도입하자 85%까지 올랐습니다. 측정이 없었다면 무엇이 효과적인지 알 수 없었을 것입니다.

    • 초기: 고정 청킹 + 벡터 검색, 적중률 60%
    • 개선: 섹션 청킹 + 하이브리드 검색, 적중률 85%
    • 마무리: 리랭킹 추가로 답변 충실성 추가 향상

    5~6개월차: 현장 도입과 저항

    기술이 완성돼도 현장이 쓰지 않으면 의미가 없습니다. 초기에는 “답이 틀릴까 봐 못 믿겠다”는 불신이 컸습니다. 모든 답변에 출처 문서와 페이지를 함께 보여주고, 베테랑 직원이 직접 답변을 검수해 신뢰를 쌓자 사용률이 빠르게 올랐습니다.

    교훈 2: 신뢰는 정확도만으로 생기지 않는다. 출처 제시와 “모르면 모른다고 답하는” 정직함이 현장 채택을 좌우한다.

    성과와 남은 과제

    도입 후 절차 검색 시간은 평균 15분에서 2분 이내로 줄었고, 반복 문의가 감소했습니다. 다만 문서가 갱신될 때 인덱스를 최신으로 유지하는 운영 체계, 그리고 답변 품질을 지속 모니터링하는 책임자 지정이 남은 과제로 확인됐습니다.

    정리: 도입을 앞둔 팀에게

    작게 시작해 평가셋으로 검증하고, 출처와 정직함으로 신뢰를 쌓으세요. 데이터 준비를 과소평가하지 말고, 출시는 끝이 아니라 운영의 시작임을 기억하세요. 기술보다 데이터와 사람의 신뢰가 생성형 AI 도입의 진짜 변수입니다.

  • 데이터 품질 모니터링 자동화: 사람이 발견하기 전에 시스템이 먼저 잡게 하기

    데이터 품질 모니터링 자동화: 사람이 발견하기 전에 시스템이 먼저 잡게 하기

    한 이커머스 데이터팀은 매주 월요일 같은 사고를 반복했다. 주말 배치가 일부 실패해 매출 지표가 누락된 채 임원 보고가 나가고, 오후가 되어서야 현업이 “숫자가 이상하다”며 제보하는 식이었다. 사람이 사후에 발견하는 한 이 패턴은 끝나지 않는다. 이 팀은 품질 모니터링 자동화로 문제를 “소비자보다 먼저” 잡기로 했다.

    수동 검증의 한계

    초기에 팀은 핵심 테이블마다 수동 점검 쿼리를 돌렸다. 그러나 테이블이 수백 개로 늘자 모든 데이터를 매번 검사할 수 없었고, 점검 쿼리 자체가 낡아 거짓 경보를 쏟아냈다. 가장 큰 문제는 “무엇이 정상인지”를 사람이 일일이 정의해야 한다는 점이었다. 데이터가 진화하면 기준도 끊임없이 손봐야 했다.

    규칙 기반과 머신러닝 기반의 결합

    팀은 두 가지 접근을 결합했다. 명확한 비즈니스 규칙(예: 매출은 음수일 수 없음, 고객 ID는 유일해야 함)은 규칙 기반 검증으로 강제했다. 반면 “오늘 행 수가 평소보다 비정상적으로 적은가” 같은 패턴은 과거 데이터를 학습한 이상 탐지 모델에 맡겼다. 규칙 기반은 명확하고 설명 가능하며, 머신러닝 기반은 미리 정의하지 못한 이상까지 포착한다.

    방식탐지 대상장점한계
    규칙 기반알려진 위반명확·설명 가능예상 못한 이상 누락
    ML 기반통계적 이상미지의 이상 포착거짓 경보·해석 난해

    구축 과정

    1. 핵심 데이터 자산 선정 및 품질 차원 정의
    2. 신선도·행 수·NULL 비율 등 핵심 지표를 자동 수집
    3. 규칙 기반 검증과 이상 탐지 모델을 파이프라인에 삽입
    4. 이상 발생 시 담당자에게 즉시 알림, 영향 자산 자동 표시
    5. 경보 정확도를 측정해 임계값과 모델을 지속 조정

    좋은 모니터링의 척도는 경보의 수가 아니라 “실제 사고를 소비자보다 먼저 잡은 비율”과 “거짓 경보 비율”이다.

    운영 정착과 성과

    자동화의 진짜 난관은 도입이 아니라 정착이었다. 초기에는 거짓 경보가 너무 많아 팀이 알림을 무시하기 시작했다. 이를 해결하기 위해 경보를 심각도별로 분류하고, 반복되는 거짓 경보는 규칙을 정교화했으며, 모든 경보에 “왜 발생했는지”와 “무엇이 영향받는지”를 함께 표시했다. 리니지와 연동해 근본 원인 후보를 자동 제시하자 평균 해결 시간이 크게 줄었다. 6개월 후 이 팀은 사고의 80% 이상을 현업 제보 전에 탐지하게 되었다.

    정리

    데이터 품질 모니터링 자동화는 사후 발견을 사전 탐지로 바꾼다. 규칙 기반과 머신러닝 기반을 결합하고, 핵심 지표를 자동 수집하며, 경보 정확도를 끈질기게 다듬는 것이 성공의 열쇠다. 핵심은 도구가 아니라 신뢰할 수 있는 경보로 팀이 실제로 반응하게 만드는 운영 정착에 있다.

  • 갚지 못한 기술 부채가 조직을 어떻게 무너뜨렸는가

    갚지 못한 기술 부채가 조직을 어떻게 무너뜨렸는가

    모든 팀은 기술 부채를 진다. 빠르게 출시하기 위해 임시방편을 쓰고, “나중에 정리하자”고 약속한다. 문제는 그 나중이 거의 오지 않는다는 것이다. 이 글은 우리 팀이 2년간 미뤄둔 데이터 파이프라인 부채가 결국 한 분기 전체를 삼킨 과정을 솔직하게 복기한 회고다.

    이 이야기를 공유하는 이유는 변명을 하기 위해서가 아니다. 부채가 쌓이는 메커니즘은 놀랄 만큼 보편적이어서, 우리의 실패가 다른 팀에게는 조기 경보가 될 수 있다고 믿기 때문이다.

    처음엔 합리적인 타협이었다

    시작은 정당했다. 제품 출시 마감이 코앞이었고, 우리는 검증 로직 없이 데이터 파이프라인을 빠르게 띄웠다. 당시 데이터는 하루 수천 건이었고, 문제가 생기면 손으로 고칠 수 있었다. 그때의 결정은 옳았다. 부채 자체가 죄는 아니다.

    이자는 복리로 붙는다

    죄는 부채를 관리하지 않은 데 있었다. 데이터가 하루 수백만 건으로 불어나는 동안 검증 로직은 여전히 없었다. 새 기능들이 그 위태로운 파이프라인 위에 하나씩 쌓였다. 임시방편 위에 또 임시방편이 올라가며, 부채의 이자는 단리가 아니라 복리로 불어났다.

    기술 부채의 가장 잔인한 점은, 갚지 않은 동안에도 이자가 매일 조용히 청구되고 있다는 것이다.

    붕괴의 날

    붕괴는 예고 없이 왔다. 한 상류 시스템이 데이터 형식을 미묘하게 바꿨고, 검증이 없던 우리 파이프라인은 잘못된 데이터를 조용히 흘려보냈다. 3주 뒤 경영진이 본 매출 지표가 실제와 크게 어긋났다는 사실이 드러났다. 그 사이 그 잘못된 숫자로 내려진 결정들을 되돌려야 했다.

    복구가 아니라 재건이었다

    우리는 한 분기 전체를 갈아 넣었다. 새 기능 개발을 전면 중단하고 파이프라인을 재설계했다. 만약 부채가 작았을 때, 즉 데이터가 적었을 때 검증을 넣었다면 며칠이면 끝났을 일이었다. 부채를 키운 대가는 그 일을 80배쯤 비싸게 만들었다.

    • 부채를 진 즉시 “상환 기한”을 백로그에 명시적으로 기록한다
    • 데이터 규모가 N배 커질 때 부채 비용도 N배 커진다고 가정한다
    • 검증과 모니터링은 기능이 아니라 보험이다, 작을 때 든다

    균형 잡힌 교훈

    그렇다고 모든 부채를 즉시 갚아야 한다는 결론은 위험하다. 그것은 또 다른 과잉이다. 폐기될지도 모르는 실험적 기능을 완벽하게 만드는 것은 낭비다. 핵심은 부채를 지지 않는 것이 아니라, 어떤 부채인지 의식하고 의도적으로 관리하는 것이다.

    지금 우리 팀은 분기마다 “부채 가시화” 시간을 갖는다. 미뤄둔 타협들을 목록으로 펼치고, 각각의 이자율을 추정하고, 상환할지 의도적으로 더 끌고 갈지 결정한다. 부채는 적이 아니다. 보이지 않는 부채가 적이다. 이 회고가 누군가의 파이프라인이 조용히 무너지기 전에 닿기를 바란다.

  • 분석을 제품처럼: 데이터 제품 사고가 바꾼 일하는 방식

    분석을 제품처럼: 데이터 제품 사고가 바꾼 일하는 방식

    한때 우리 데이터팀은 분석 공장이었다. 요청이 들어오면 쿼리를 짜고, 차트를 만들고, 슬라이드에 붙여 넘겼다. 그리고 그 결과물은 대부분 한 번 쓰이고 잊혔다. 같은 질문이 두 달 뒤 다른 부서에서 다시 들어오면, 우리는 처음부터 똑같은 일을 반복했다.

    전환점은 한 시니어가 던진 질문이었다. “우리는 왜 분석을 일회용으로 만들까? 제품처럼 만들 수는 없을까?” 이 한마디가 데이터 제품 사고로 가는 문을 열었고, 우리 팀의 일하는 방식을 근본적으로 바꿨다.

    일회성 분석과 데이터 제품의 차이

    일회성 분석은 특정 질문에 한 번 답하고 끝난다. 데이터 제품은 반복되는 질문에 지속적으로 답하도록 설계된 자산이다. 후자는 사용자가 있고, 신뢰성에 대한 약속이 있으며, 유지보수되고 개선된다. 마치 소프트웨어 제품처럼 라이프사이클을 가진다.

    분석은 질문에 답한다. 데이터 제품은 질문이 다시 올 것을 안다.

    사용자를 정의하는 순간 모든 게 바뀐다

    제품 사고의 핵심은 “사용자가 누구인가”를 묻는 것이다. 우리는 대시보드를 만들 때 더 이상 “무슨 데이터가 있지?”에서 출발하지 않았다. “이걸 누가, 어떤 결정을 내리려고 보는가?”에서 출발했다. 이 질문 하나가 불필요한 지표를 쳐내고, 정작 필요한 맥락을 더하게 만들었다.

    제품처럼 운영한다는 것

    • 사용량을 측정한다: 아무도 안 보는 대시보드는 폐기한다
    • SLA를 약속한다: 데이터 신선도와 정확도에 책임을 진다
    • 피드백을 받는다: 사용자 인터뷰로 데이터 제품을 개선한다
    • 로드맵을 가진다: 다음 분기에 무엇을 개선할지 계획한다

    측정이 가져온 충격

    가장 충격적인 변화는 사용량을 측정하기 시작했을 때 왔다. 우리가 자랑하던 대시보드의 70%를 아무도 보지 않는다는 사실이 드러났다. 우리는 그것들을 과감히 없앴고, 살아남은 30%에 자원을 집중했다. 데이터 제품도 제품인 이상, 안 쓰이는 기능은 부채일 뿐이다.

    한계: 모든 것을 제품으로 만들 필요는 없다

    물론 과유불급이다. 정말로 한 번만 필요한 탐색적 질문까지 제품으로 만들려 하면 과잉 설계가 된다. 빠르게 답하고 버려야 할 분석도 분명히 있다. 데이터 제품 사고는 “반복될 것이 거의 확실한” 질문에 적용할 때 가장 큰 레버리지를 낸다. 모든 망치질을 제품 공정으로 바꾸면 속도를 잃는다.

    그럼에도 이 사고방식은 데이터팀의 정체성을 바꿨다. 우리는 더 이상 요청을 처리하는 서비스 데스크가 아니라, 조직이 의존하는 자산을 만드는 제품팀으로 스스로를 본다. 같은 일을 하더라도 “제품을 만든다”는 자기 인식은 품질과 책임감, 그리고 자부심을 완전히 다른 차원으로 끌어올린다.

  • 6개월을 갈아 넣고 폐기한 프로젝트가 남긴 것

    6개월을 갈아 넣고 폐기한 프로젝트가 남긴 것

    우리는 6개월을 갈아 넣은 프로젝트를 출시 직전에 폐기했다. 야심찬 추천 시스템이었다. 팀의 자존심이 걸려 있었고, 경영진의 기대도 컸다. 그런데도 우리는 스스로 그것을 묻기로 결정했다. 이 글은 그 실패를 정직하게 복기한 회고다. 미화도, 과도한 자기비하도 없이.

    실패를 글로 쓰는 것은 불편하다. 그러나 성공담보다 실패담에서 배울 것이 훨씬 많다는 것을, 나는 이 프로젝트를 통해 뼈저리게 알게 됐다.

    모든 것이 순조로워 보였다

    시작은 완벽했다. 명확한 목표, 충분한 데이터, 유능한 팀. 우리는 정교한 추천 모델을 만들었고, 오프라인 평가 지표는 훌륭했다. 정확도가 기존 대비 크게 올랐다. 모두가 출시만 하면 성공이라 믿었다. 바로 그 자신감이 첫 번째 위험 신호였다.

    잘못된 질문에 완벽하게 답했다

    문제는 출시 직전 작은 사용자 테스트에서 드러났다. 우리의 추천은 통계적으로 정확했지만, 사용자에게는 “이미 알거나 이미 산 것”을 추천하고 있었다. 우리는 “클릭 확률이 높은 항목”을 정확히 예측했지만, 정작 비즈니스가 원한 것은 “새로운 발견”이었다. 우리는 잘못된 질문에 완벽하게 답한 것이다.

    틀린 문제를 정확히 푸는 것보다, 옳은 문제를 대충 푸는 것이 거의 항상 낫다.

    왜 6개월 동안 몰랐을까

    가장 아픈 질문은 이것이었다. 이걸 왜 6개월이 지나서야 알았을까? 답은 명확했다. 우리는 모델 정확도라는 대리 지표에 빠져, 실제 사용자와 비즈니스 목표에서 너무 일찍 멀어졌다. 6개월간 우리는 한 번도 진짜 사용자에게 결과를 보여주지 않았다. 측정하기 쉬운 지표가 측정해야 할 지표를 가렸다.

    • 대리 지표가 좋아도 진짜 목표와의 연결을 의심하라
    • 아무리 초기라도 실제 사용자 피드백을 미루지 마라
    • 비싸지기 전에 가장 큰 가정을 가장 먼저 검증하라

    폐기 결정이 가장 좋은 결정이었다

    역설적이게도 이 프로젝트에서 가장 잘한 일은 폐기 결정이었다. 매몰비용에 끌려 출시했다면, 사용자 경험을 해치고 더 큰 비용을 치렀을 것이다. 6개월을 버린 것은 아팠지만, 잘못된 방향으로 12개월을 더 가는 것보다는 훨씬 쌌다. 손실을 인정하고 멈추는 것도 실력이다.

    실패가 조직에 남긴 자산

    물론 이 회고가 “실패는 무조건 좋다”는 식의 낭만으로 읽히면 곤란하다. 피할 수 있었던 실패였고, 더 일찍 사용자를 만났다면 비용을 줄일 수 있었다. 실패 예찬은 위험하다. 중요한 것은 실패 자체가 아니라 실패에서 무엇을 추출하느냐다.

    이 프로젝트 이후 우리 팀은 모든 프로젝트 시작 시 “우리가 틀렸다면 어디서 가장 먼저 알 수 있을까”를 먼저 설계한다. 가장 비싼 가정을 가장 싸게 검증하는 습관, 그것이 6개월의 학비로 산 가장 값진 자산이다. 묻어버린 프로젝트는 사라졌지만, 그 교훈은 이후 모든 프로젝트를 더 단단하게 만들었다.