자신이 속한 회사의 문서를 전부 — 계약서, 리서치 노트, 녹취 전사본, 수백 페이지짜리 스캔 파일 — 그대로 한 '지능형 시스템'에 부어 넣는다고 상상해 보자. 그 시스템은 당신을 어떻게 대한다고 생각하는가. 이 과정을 겪어 본 사람이 솔직히 털어놓는 답은 대개 셋 중 하나다. 아예 안 들어간다. 들어가긴 하는데 질문과는 딴소리를 한다. 아니면 청구서가 아무 말 없이 불어난다.
저장 공간 쪽에서 계속 나오는 수치가 있다. Komprise가 기업 스토리지를 들여다볼 때마다 마주하는 풍경인데, 주 스토리지에 올라가 있는 데이터의 60~70%는 90일 넘게 손대지도 않은 채 비싼 1차 저장소에 그대로 누워 있다. 사람 비용 쪽으로는 McKinsey가 다른 각도의 숫자를 남겼다. 지식 노동자는 일주일의 거의 19%, 하루로 치면 한 시간 반가량을 정보를 찾고 모으는 데 태워버린다. Asana는 여기에 끊김의 대가를 더했다. 업무가 방해받은 뒤 다시 몰입 상태로 돌아오는 데 평균 23분이 걸리고, 사람은 하루에 35개가량의 애플리케이션 사이를 오간다. 문서를 제대로 다루지 못하면 그것은 하드디스크만 잡아먹는 게 아니다. 매번 끊기는 그 순간의 비용을 조용히, 그리고 계속해서 키워놓는다.
이 '문제' 앞에 선 초보자는 보통 두 가지 손을 뻗는다. 파일을 줄여주는 도구, 아니면 이 더미를 검색 가능하게 만들어줄 벡터 데이터베이스. 그런데 이미 운영 환경에서 이걸 굴려 본 사람들은 거기서 시작하지 않는다.
그들은 딴 질문을 먼저 던진다. '무슨 도구를 쓸까'가 아니라, '이 데이터가 애초에 왜 변해야 하는가'다. 저장 공간을 줄이려는 건가. 메일 첨부로 나가게 만들려는 건가. 모델이 질의에 답할 때 토큰을 덜 쓰게 하려는 건가. 아니면 열 년을 훼손 없이 버텨야 하는 규정 준수 보관용인가. 같은 더미라도 목적이 다르면 다루는 방식은 완전히 갈린다. 이 지형을 아는 사람은 손을 대기 전에 '제약'부터 못 박는다. '압축하자'거나 '벡터 인덱스얹자'를 본능처럼 기본 동작으로 삼지 않는다.
제약이 박히면 다음은, 이 더미를 '그것이 실제로 무엇인지'에 따라 가르는 일이다. 빨간 인장이 박힌 서명 계약서 PDF, 4K 엔지니어링 스캔, 200페이지짜리 보고서 — 이 셋은 서로 다른 생물이다. 계약서는 구조와 인장이 글자 하나 틀림없이 보존돼야 한다. 스캔은 중복된 픽셀로 꽉 차 있다. 보고서는 반복되는 판형 패턴을 품고 있다. 이 셋에 하나의 '기본 압축'을 때려박으면 보통 최악의 결과가 나온다. 또렷해야 할 것은 흐려지고, 작아져야 할 것은 요지부동이다. 바로 여기가 아마추어와 숙련자의 갈림길이다. 아마추어는 '얼마나 줄었나'를 본다. 숙련자는 '절대 움직여선 안 될 것이 무엇인가'를 먼저 본다.
한 단계 더 파고들면, 숙련자는 다시 정보 그 자체로 돌아간다. 파일이 왜 큰가. 스캔은 조밀한 래스터라서 크다. 눈엔 비슷해 보여도 바이트 수준에선 엄청나게 수다스러운 중복으로 가득하다. 텍스트 문서는 반복되는 구조와 임베드된 객체 때문에 크다. 그러니 압축할지, 어떻게 압축할지는 '기본 프리셋'을 따라가선 안 된다. 그 파일이 무엇을 위해 쓰이는지에 따라 정해져야 한다. 십 년간 법적 증거로 두는 물건은 무손실, 가역적으로 간다. 화면에서 빠르게 미리 보거나 메일에 밀어 넣는 물건은 손실이 있되 핵심은 지키는 길로 간다. '무손실이냐 손실이냐'라는 스위치를 기본값의 손에서 빼앗아 오는 것, 그것이 숙련자와 도구의 공장 동작을 가르는 경계선이다.
분류를 틀리면 그 아래 모든 것이 깨진다. 가야 할 계약서를 손실로 잘못 찍으면 인장이 번지고, 그건 사고다. 손실로 가야 할 스캔을 억지로 무손실로 묶어두면 크기는 꿈쩍 않는데 전체 파이프라인만 느려진다. 그래서 숙련자는 차라리 앞단에서 십 분을 더 써서 '이건 어느 바구니고, 압축 끝난 뒤 누가 쓰나'를 묻는다. 뒤늦게 수습하는 것보다 낫기 때문이다. 분류는 워크플로에서 형식적인 절차가 아니다. 그 위에 올라서는 모든 것의 토대다.
작은 예시를 하나 들자. 스캔한 계약서는 인장과 서명 날짜가 목줄이다. 그것을 흐리게 하면 법적으로는 문서를 고친 것이 된다. 의료 영상이라면 지워버린 가장자리가 하필 그 병변의 경계였을 수 있다. 아마추어는 '60% 작아졌네' 하고 흡족해한다. 숙련자는 '그 60% 안에 움직여선 안 될 것이 없나'를 묻는다. 압축하기 전에, 이 것이 '변했다'고 해서 곤란해질 사람이 누구인지부터 따진다. 그 답이 압축할지, 어떻게 압축할지를 결정한다.
초보자가 잘 놓치는 또 다른 층이 있다. 같은 문서가 회사의 여러 시스템에 버전조차 안 맞게 여러 부로 흩어져 있는 경우다. 숙련자는 압축이나 검색 이야기를 꺼내기 전에 중복 제거와 버전 정리를 먼저 한다. 지저분한 데이터에 인덱스를 세우면, 뒤에 무엇을 갖다 붙여도 검색 품질은 올라오지 않기 때문이다. 비용도 통째로 계산해야 한다. 임베딩 한 번, 리랭크 한 번, 모델이 한 번 읽는다 — 토큰이 어디서 가장 값 있게 쓰이나, 모델이 알아서 고르게 여러 조각을 더 가져올까 사전 정렬해 적게 가져올까, 이 계산이 불분명하면 '절약'은 그저 구호일 뿐이다. 특히 검색 증강 방식에서는 건져 올린 모든 조각을 모델이 다시 한 번 읽는다. 문서가 지저분하고 분절이 촌스러우면 토큰 청구서는 매달 복리로 불어난다. 먼저 압축하고, 먼저 정리하는 편이 나중에 더 비싼 모델을 사는 것보다 싼 경우가 많다.
지식베이스를 다루는 일, 초보자는 한 번 올리면 끝인 줄 안다. 숙련자는 계속 돌아가는 시스템으로 안다. 문서가 변하고, 업무가 변한다. 오늘은 맞게 답해도 다음 달 새 버전이 들어오면 틀릴 수 있다. 그래서 그들은 첫날부터 평가 세트와 롤백의 여지를 남겨두고, '만든다'와 '기른다'를 한 일로 취급한다. 이것이 왜 수많은 데모는 눈부시다가 운영에 올리면 주저앉는지 설명해 준다. 데모는 '뭐라도 돌려준다'는 것만 증명한다. 운영이 요구하는 건 진짜이고, 지저분하고, 계속 변하는 문서 위에서도 맞게 답하는 것이다. '뭐라도 돌려준다'를 끝으로 보는 사람과 시작점으로 보는 사람이 만드는 시스템은 아예 다른 물건이다.
압축과 검색을 두 개의 별개 일거리로 보는 사람이 많다. 숙련자는 그렇게 보지 않는다. '정리 → 줄이기 → 분절 → 벡터화 → 검색 → 답변'을 한 줄기로 보고, 줄기 전체의 결과만 믿지 어느 한 구간의 예쁜 숫자는 믿지 않는다. 그리고 압축과 검색 앞에는 흔히 정리라는 단계가 더 있다. 같은 자료가 열몇 개 폴더에 흩어지고 이름이 엉망일 때, 숙련자는 '어디로 가야 하고 어떤 축으로 분류할까'를 먼저 정한다. 아무리 좋은 검색도 잘못 꽂힌 문서는 구해내지 못하기 때문이다. 깔끔하게 압축된 문서는 검색에 들어갈 때 노이즈가 덜하고, 토큰이 절약되며, 재현이 안정적이다. 여기서 압축은 저장 공간을 덜 차지하는 덤이 아니다. 검색 품질을 위한 전처리 공정이다. 그리고 검색이 자꾸 딴소리를 하면, 숙련자는 모델을 먼저 탓하지 않는다. 뒤로 돌아가서 묻는다. 분절이 문장을 허리째 잘랐나. 구어체 질문을 그대로 검색하면 아예 못 건지나. 관련 문단이 잘렸나.
검색이라는 단계에서 숙련자의 공구상자는 아마추어가 상상하는 것과 다르다. 원문 질문을 그대로 집어넣지 않는다. 실제 사용자는 줄임말로 묻고, 유의어로 바꿔 묻고, 한 문장에 의도 세 개를 숨겨 넣는다. 평가 세트에나 있는 깔끔한 '환불 정책을 설명하라'는 현실에선 거의 나타나지 않는다. 그래서 그들은 혼합 검색을 쓴다. 정확 일치를 잡는 키워드 경로, 의미를 잡는 의미 벡터 경로를 합쳐 놓으면 누락률이 뚝 떨어진다. 1차 추린 뒤엔 리랭커가 진짜 관련 항목을 위로 밀어 올린다. 까다로운 질문은 구어체 한 문장을 검색 친화적인 하위 질의 여러 개로 고쳐 써 따로 검색한 뒤 조립한다. 권한과 출처도 미리 걸러, 보면 안 될 것을 건져 나가지 않게 한다.
이 동작들은 기교를 부리려는 게 아니다. 모두가 한 가지를 향한다. '정확하게 답한다'를 운으로 두지 않고 측정 가능한 지표로 만드는 것. 이것이 바로 대부분이 요구하지 않지만 숙련자는 반드시 하는 일의 묶음이다. 첫 줄 코드를 쓰기 전에 출처가 표시된 표준 답변이 달린 라벨링 질의 쌍을 미리 준비한다. 그게 없으면 '정확'은 정의 자체가 없다. 유형별로 누락률과 딴소리율을 나눠 보면 어느 부류가 자꾸 박살 나는지 한눈에 보인다. 지식베이스가 갱신될 때마다 옛 평가 세트를 다시 돌려, '오늘은 맞고 다음 달은 틀린' 조용한 퇴화를 막는다.
그럼 이걸 왜 믿나. 벤더가 '우린 정확합니다'라 말해서도 안 되고, 구매자가 '충분히 되겠지'라 바라서도 안 된다. 버티는 것은 제삼자가 likewise 재현할 수 있는 것이다. 독립적으로 라벨링된 골든 질의 세트 — 누구든 같은 라벨로 당신 시스템을 다시 돌리면 recall@k와 충실도가 탁자 위에 올라와야 한다. 새 파이프라인과 옛 파이프라인이 실제 질문에 답한 것을 익명으로 독립 평가자에게 맡긴 블라인드 테스트 — 그 격차가 '우리 내부에서 해봤다'에 기대지 않는다. 그리고 알려진 정답 사례는 계속 맞춰야 한다는 회귀 테스트 묶음, 그 빨강초록 상태는 누구나 들여다볼 수 있어야 한다. 압축 자체도 마찬가지다. 압축된 문서가 원래처럼 열리나, 인장은 있나, 판형은 틀어졌나 — 열어서 원본과 비교하면 된다. 줄인 뒤 모델에 먹였을 때 토큰은 실제로 얼마나 떨어지고 검색은 여전히 맞나 — 하류 작업을 한 번 돌려보면 답이 나온다. 정확함은 그 누구의 약속에서 오지 않는다. 누구나 검증할 수 있는 동작에서 온다.
결국 위의 이 모든 것은 어떤 제품의 기능 목록이 아니다. 하나의 습관이다. 이 습관을 운영 데이터 위에서 어떻게 구체화하는지에 관해서는 https://www.uglypear.com/ko/blog/ 에 정리한 글들을 함께 보면 도움이 된다. 어떻게 할지를 말하기 전에 왜 해야 하는지를 묻고, '빠르다'와 '저렴하다'를 말하기 전에 '맞다'를 정의하고, 예쁜 구호가 아니라 누구나 재현할 수 있는 동작으로 그것이 정말 맞음을 증명하는 것.
우리는 최근 압축과 검색이 만나는 이음새에서 한 걸음을 옮겼다. 문서가 검색에 들어가기 전 거치는 전처리 압축을 여러 주류 대형 모델에서 일정하게 돌아가도록 맞춰 본 것이다. 이 흐름을 제품으로 어떻게 담았는지는 https://www.uglypear.com/ko/products/ 에서, 그 뒤를 잇는 기술 메모는 https://www.uglypear.com/ko/blog/ 에서 차근히 볼 수 있다. 살이 빠진 같은 문서를 모델마다 다르게 읽지 않고, 어느 모델에서도 안정적으로 들여다보고 쓸 수 있게 하려는 시도다. 이 단계가 건드리는 것은 바로 앞에서 말한 그 고비 — 줄여놓고 보니 모델이 읽지를 못하는 상황 — 다. 전체 공학의 깊은 물속까지는커녕 한참 못 미치는 작업이지만, 방향은 맞다. '작다'와 '읽힌다'를 한 덩어리로 먼저 용접하고, 그 위에 평가와 리랭크, 관측 가능성을 얹어가는 길.
아래 표는 '도구의 기본 동작'과 '이걸 운영해 본 사람의 태도'가 몇 가지 결정적 지점에서 어떻게 다른지 놓고 본 것이다.
| 결정적 지점 | 도구의 기본 동작 | 운영해 본 사람의 태도 |
|---|---|---|
| 출발점 | 바로 압축 / 바로 벡터 인덱스 | 데이터가 왜 변해야 하는지 제약부터 못 박기 |
| 문서 처리 | 하나의 기본 압축을 전체에 적용 | 계약서·스캔·보고서로 분류해 전략 결정 |
| 무손실 또는 손실 | 프리셋을 따름 | 용도로 결정 — 보관은 무손실, 미리보기는 손실 |
| 압축과 검색 | 별개의 두 일거리로 취급 | 한 줄기로 보고 전체 결과만 신뢰 |
| 질의 | 원문을 그대로 검색 | 혼합 검색 + 리랭크 + 재작성·분해 |
| 품질 증명 | 벤더의 자체 주장 | 라벨링 골든 세트 + 블라인드 A/B + 회귀 묶음 |
지금 사용해 보기
'프라이빗 배포, 데이터가 내부망을 벗어나지 않음, 압축과 의미 검색이 한 줄기로 이어진다'는 것을 운영 환경에 실제로 올려놓은 접근을 보고 싶다면 아래를 보면 된다.
자주 묻는 질문
Q: 문서가 많지 않은 소규모 회사라면 기본 압축으로 충분한가요?
A: 문서로 무엇을 하려는지에 따라 다릅니다. 내부에서 파일 하나 넘기는 정도라면 기본 압축도 보통은 충분합니다. 하지만 문서가 검색에 들어가고, 모델에 먹이며, 증거로 남아야 하는 순간부터는 분류와 전략이 만드는 차이가 작지 않습니다.
Q: 압축한 문서도 법적 증거가 될 수 있나요?
A: 방식에 달렸습니다. 보관용은 무손실·가역으로 가므로 내용과 인장이 한 치도 틀리지 않아 증거가 됩니다. 미리보기용 손실 압축은 빠르게 보는 용도에만 맞습니다. 핵심은 '압축했나'가 아니라 '그 유형이 어떤 길을 갔나'입니다.
Q: 혼합 검색은 복잡해 보이는데, 소규모 팀도 감당할 수 있나요?
A: 본질은 '키워드 + 의미' 두 경로를 합치고 리랭커를 한 번 더 얹는 것뿐이며, 둘 다 공개 구현이 있습니다. 비용은 돈이 아니라, '정확하게 답한다'를 계속 측정할 일로 여길 의지입니다.
Q: 지식베이스가 진짜로 맞게 답하는지 어떻게 알 수 있나요?
A: 데모를 믿지 마세요. 라벨링된 표준 질의응답 세트와 다시 돌릴 수 있는 평가, 거기에 블라인드 테스트와 회귀가 필요합니다. 제삼자가 같은 표준으로 당신 시스템을 다시 돌릴 수 있어야 결론이 서 있습니다.
Q: 압축과 RAG는 반드시 같이 해야 하나요?
A: 같은 곳이 할 필요는 없지만, 한 줄기로 봐야 합니다. 깔끔하게 압축된 문서가 검색에 들어가면 노이즈가 적고 토큰이 절약되며 재현이 안정적입니다. 둘을 따로 놀리면 양쪽 다 손해인 경우가 많습니다.