본문 바로가기
AI System/Agentic RAG: Agent 시스템을 위한 Vector RAG 설계

d01 - 4. RAG 파이프라인

by Toddler_AD 2026. 6. 15.

S3 · RAG 파이프라인 — 청킹 · 색인 · 검색

Agentic RAG 실전 (14시간) · Day 1

긴 문서를 어떻게 잘라(청킹) 넣느냐가 검색 품질을 좌우한다. 이 교시는 청킹·색인을 LangChain으로 자동화하고, 청크 크기 영향을 직접 비교한다.

목표

  • 긴 문서를 청크로 나눈다.
  • PineconeVectorStore 로 색인을 자동화한다.
  • 청크 크기에 따른 검색 품질 차이를 비교 실험한다.
 

1. 청킹 — 왜, 어떻게

문서를 통째로 넣지 않는 이유: 컨텍스트 길이 한계, 비용, 무관 내용으로 인한 잡음. 그래서 작은 조각(청크)으로 잘라 관련 조각만 검색해 넣는다.


chunk_size 장점 단점
작게(예: 200) 질문에 딱 맞는 조각, 정밀도↑ 앞뒤 문맥 손실 가능
크게(예: 1000) 문맥 보존↑ 여러 주제 혼입, 점수 희석
  • chunk_overlap: 인접 청크를 일정 글자 겹치게 해 경계에서의 문맥 손실을 완화.
  • RecursiveCharacterTextSplitter: 문단→줄→문장→공백 순으로 큰 단위부터 분할해 의미 단위를 최대한 보존.

정답은 도메인·질문 유형에 따라 다르므로 실험으로 정한다 — 그것이 이 교시의 핵심.

 

2. 실행 준비

S0 프로젝트의 .venv 커널로 실행한다. 추가 설치 없이 .env 의 키만 로드한다.

import os
from getpass import getpass

# S0 프로젝트 루트의 .env 에서 키 로드 (없으면 입력으로 폴백)
try:
    from dotenv import load_dotenv
    load_dotenv()
except ImportError:
    pass
for name in ["OPENAI_API_KEY", "PINECONE_API_KEY"]:
    if not os.environ.get(name):
        os.environ[name] = getpass(f"{name}: ")
print("키:", {k: bool(os.environ.get(k)) for k in ["OPENAI_API_KEY", "PINECONE_API_KEY"]})
키: {'OPENAI_API_KEY': True, 'PINECONE_API_KEY': True}
 

3. 코퍼스

가상의 회사 '누구나테크' 사내 핸드북 8개 문서. 청크 크기 비교가 드러나도록 문서 분량을 충분히 길게 구성했다. 실제 수업에서는 사내 문서로 교체한다.

# ── 한국어 코퍼스 (가상의 회사 "누구나테크" 사내 핸드북) ──────────────────
# 문서를 여러 단락(각 1,800자 이상)으로 충분히 길게 구성해, chunk_size를
# 200/500/1000/1500 으로 바꿀 때 청크 수와 검색 결과가 뚜렷이 달라지도록 했다.
# 실제 수업에서는 사내 문서로 교체한다.

raw_docs = [
  {"id": "hr-leave", "title": "휴가 및 연차 정책",
   "text": """누구나테크의 연차 휴가는 입사 1년 차에 15일이 부여되며, 근속 2년마다 1일씩 가산되어 최대 25일까지 늘어난다. 입사 첫해에 1년을 채우지 못한 직원은 매월 만근 시 1일씩 비례하여 부여받는다. 연차는 회계연도(1월~12월) 기준으로 산정하며, 회계연도 중 입사한 직원은 입사일을 기준으로 비례 계산한 뒤 다음 해부터 정규 일수를 적용한다. 부여된 연차의 산정 내역은 매년 초 그룹웨어 근태 화면에서 직원이 직접 확인할 수 있다.

미사용 연차는 회계연도 종료 후 다음 해로 최대 5일까지 이월되며, 이월된 연차는 다음 해 상반기(6월 말) 안에 모두 소진해야 한다. 상반기 내 미소진 이월 연차는 자동 소멸하되, 회사 사정으로 사용하지 못한 경우 인사팀 승인 하에 연차수당으로 정산할 수 있다. 회사는 연차 촉진 제도를 운영하여, 사용 기한 2개월 전과 1개월 전 두 차례에 걸쳐 미사용 연차 현황을 직원에게 통지하고 사용 계획을 받는다.

반차는 오전(09:00~13:00)과 오후(14:00~18:00)로 나누어 사용할 수 있고, 반반차(2시간) 단위도 허용된다. 연차 사용은 사용 예정일 3영업일 전까지 그룹웨어에서 신청하고 팀장의 승인을 받아야 한다. 연속 5일 이상의 장기 휴가는 2주 전까지 신청하며 업무 인수인계 계획을 함께 제출한다. 팀 내 동시 휴가 인원이 과반을 넘지 않도록 일정을 조정하며, 연말·명절 등 성수기에는 사전에 팀 단위로 휴가 계획을 공유해 업무 공백을 줄인다.

경조사 휴가는 연차와 별도로 부여된다. 본인 결혼은 5일, 자녀 결혼은 1일, 자녀 출산(배우자)은 10일, 직계가족 사망은 5일, 형제자매 사망은 3일이 주어진다. 경조사 휴가는 사유 발생일로부터 한 달 이내에 사용하는 것을 원칙으로 하되, 장례·돌봄 등 부득이한 경우 분할 사용이 가능하며 증빙 서류를 제출한다. 출산·육아와 관련해서는 법정 출산전후휴가와 육아휴직을 보장하고, 육아기 근로시간 단축 제도를 함께 운영한다.

병가는 연 60일 한도로 사용 가능하며, 연속 3일을 초과하는 병가는 의사 진단서를 제출해야 한다. 업무상 질병·부상은 별도의 산재 절차를 따르며, 회복 기간 동안 직무 조정을 지원한다. 장기근속자(5년, 10년)에게는 각각 5일, 10일의 리프레시 휴가와 휴가비가 추가로 지급되며, 리프레시 휴가는 일반 연차와 붙여 사용할 수 있다. 모든 휴가 기록은 근태 시스템에 자동 반영되어 급여·평가와 연동된다."""},

  {"id": "hr-remote", "title": "재택근무 및 유연근무 제도",
   "text": """재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주 근무 형태를 그룹웨어에 등록하고 팀장 승인을 받아야 한다. 신규 입사자는 온보딩 기간(첫 4주) 동안에는 주 1회로 제한되며, 수습 종료 후 일반 기준이 적용된다. 직무 특성상 상시 대면이 필요한 일부 직군은 팀 단위로 별도 기준을 둘 수 있다.

핵심 근무시간(코어타임)은 오전 10시부터 오후 4시까지이며, 이 시간 동안에는 사내 메신저에서 즉시 응답이 가능해야 한다. 코어타임을 제외한 출퇴근 시각은 오전 7시~10시 사이에서 자유롭게 선택하는 유연근무제로 운영된다. 월 표준 근로시간을 채우는 선택근로제를 적용하므로, 특정일에 더 일하고 다른 날 일찍 퇴근하는 정산이 가능하다. 근태는 그룹웨어 기록을 기준으로 하며, 월말에 표준 시간 대비 부족·초과분을 확인하고 다음 달에 반영한다.

재택 시에는 회사가 지급한 노트북과 VPN을 사용해야 하며, 개인 기기에서 사내 시스템에 접속하는 것은 금지된다. 카페 등 공용 공간에서 근무할 경우 화면 보안 필름을 사용하고 민감 정보 화면 공유를 피해야 한다. 화상회의에서 고객 정보나 내부 자료를 공유할 때는 참석자 범위를 확인하고 녹화 여부를 사전에 고지한다. 재택근무 중 발생한 산업재해도 근무시간·업무 연관성이 인정되면 보상 대상이 되므로, 사고 발생 시 즉시 보고한다.

협업 방식으로는 비동기 커뮤니케이션을 기본으로 한다. 결정 사항과 논의 맥락은 문서와 이슈 트래커에 남겨, 다른 시간대나 재택 중인 동료가 따라올 수 있게 한다. 회의는 목적과 안건을 미리 공유하고, 회의록과 결정 사항을 사후에 정리해 공유한다. 즉시 응답이 필요한 사안과 그렇지 않은 사안을 구분해, 불필요한 실시간 대기를 줄인다.

월 1회 이상은 팀 동기화를 위해 사무실 출근이 권장되며, 분기마다 전사 오프사이트가 열린다. 팀별로 정기 대면 협업일을 지정해 운영할 수 있고, 신규 입사자 합류 주간에는 대면 비중을 높인다. 재택근무 비용 지원으로 매월 통신비 2만 원과 연 1회 홈오피스 용품비 20만 원이 지급되며, 의자·모니터 등 장비는 사내 대여 제도를 통해 빌릴 수 있다. 장기 출장이나 워케이션은 별도 승인 절차를 따른다."""},

  {"id": "eng-deploy", "title": "배포 및 릴리스 프로세스",
   "text": """모든 코드는 기능 브랜치에서 작업한 뒤 Pull Request를 통해 main 브랜치로 병합한다. PR은 최소 1인 이상의 코드 리뷰 승인과 CI 파이프라인(빌드, 단위 테스트, 린트, 보안 스캔) 통과를 필수로 한다. main 브랜치는 보호 규칙이 적용되어 직접 푸시가 금지되며, 강제 푸시와 히스토리 변경도 차단된다. 커밋 메시지는 변경 의도를 알 수 있도록 규칙에 맞춰 작성한다.

main 브랜치에 병합되면 자동으로 스테이징 환경에 배포되어 QA가 통합 테스트를 수행한다. 스테이징에서 스모크 테스트와 회귀 테스트가 통과해야 다음 단계로 넘어간다. 데이터베이스 스키마 변경은 무중단 마이그레이션 원칙을 따르며, 하위 호환을 유지한 채 추가→이중쓰기→정리의 단계로 점진 적용한다. 모든 마이그레이션은 롤백 스크립트를 함께 준비하고, 대용량 변경은 사전에 영향도를 검토한다.

프로덕션 배포는 QA 승인 이후 릴리스 담당자가 배포 태그를 생성하고, 마지막으로 엔지니어링 리드가 수동으로 승인하는 2단계 게이트를 거친다. 승인 기록과 변경 내역은 릴리스 노트로 자동 정리되어 추적성을 확보한다. 기능 플래그(feature flag)를 활용해 코드 배포와 기능 노출을 분리하며, 위험한 기능은 내부 사용자와 일부 고객에게 먼저 공개하는 점진적 출시를 적용한다.

배포는 카나리 방식으로 진행되어 전체 트래픽의 5%에 먼저 적용하고, 오류율과 지연(p95) 지표를 10분간 관찰한 뒤 25%, 50%, 100% 순으로 단계적으로 확대한다. 각 단계에서 오류율이 기준치(0.5%)를 초과하면 자동으로 확대를 중단하고 담당자에게 알림을 보낸다. 주요 지표는 대시보드로 실시간 모니터링하며, 배포 창에는 담당자가 대기한다.

문제가 감지되면 직전 배포 태그로 롤백하며, 롤백은 평균 1분 이내에 완료되도록 자동화되어 있다. 긴급 핫픽스는 별도 승인 절차를 통해 스테이징을 건너뛸 수 있으나, 배포 후 24시간 내 사후 리뷰를 반드시 작성해야 한다. 정기 배포는 화·목요일 오전에만 진행하며, 금요일과 공휴일 전날 오후에는 배포를 금지해 대응 인력이 부족한 시간대의 위험을 줄인다."""},

  {"id": "eng-incident", "title": "장애 대응 및 온콜 운영",
   "text": """서비스 장애는 영향 범위에 따라 Sev1(전면 장애), Sev2(주요 기능 장애), Sev3(부분/경미)로 분류한다. Sev1은 전체 사용자가 핵심 기능을 쓸 수 없는 상태, Sev2는 일부 기능이나 일부 사용자에 영향을 주는 상태, Sev3은 우회 가능한 경미한 문제를 의미한다. 분류는 초기 정보로 잠정 지정하고, 상황이 바뀌면 상향·하향 조정하며 그 근거를 기록한다.

온콜 담당자는 알림 수신 후 Sev1은 5분, Sev2는 15분, Sev3은 1시간 이내에 1차 대응을 시작해야 하며, 주간·야간 교대로 운영된다. 온콜은 1주 단위 순환이며, 야간·주말 온콜에는 별도 수당이 지급된다. 1차 대응자가 정해진 시간 내 확인하지 못하면 자동으로 2차 담당자와 팀장에게 에스컬레이션되도록 알림 정책이 설정되어 있다. 온콜 인수인계 시에는 진행 중 이슈와 위험 요소를 문서로 전달한다.

Sev1 장애는 즉시 전용 인시던트 채널을 개설하고, 인시던트 지휘자(IC)를 지정하여 30분 단위로 상태를 공유한다. 고객 영향이 있는 장애는 상태 페이지에 공지하고, 복구 예상 시각(ETA)을 함께 안내한다. 커뮤니케이션 담당자는 IC와 분리하여 지정하는 것을 권장하며, IC는 기술적 작업을 직접 수행하기보다 조율과 의사결정에 집중한다. 외부 공지 문구는 사실 위주로 간결하게 작성한다.

복구가 최우선이며, 근본 원인 분석은 서비스 정상화 이후에 진행한다. 임시 완화 조치(트래픽 차단, 기능 비활성화, 롤백, 스케일 아웃)를 적극 활용해 영향을 먼저 줄인다. 모든 조치와 관찰 결과는 인시던트 채널에 시간순으로 기록하여, 이후 타임라인 재구성과 분석에 활용한다. 추측과 확인된 사실을 구분해 공유한다.

장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템은 비난 없는(blameless) 문화를 원칙으로 하며, 사람보다 시스템과 프로세스의 개선에 초점을 둔다. 재발 방지 과제는 추적 가능한 티켓으로 등록하고 담당자와 기한을 부여한다. 반복되는 장애 패턴은 분기별 신뢰성 리뷰에서 다루고, 위험도가 높은 항목은 우선순위를 높여 처리한다."""},

  {"id": "sec-account", "title": "보안 및 계정 관리 규정",
   "text": """모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로는 인증 앱(TOTP)과 하드웨어 보안 키를 권장하며, SMS 인증은 보조 수단으로만 허용된다. 분실·기기 교체 시에는 헬프데스크를 통해 본인 확인 후 MFA를 재등록하며, 임시 우회 코드는 1회용으로 발급된다.

비밀번호는 최소 12자 이상이어야 하고 90일마다 변경하며, 최근 5회 사용한 비밀번호는 재사용할 수 없다. 사내 포털 비밀번호를 잊은 경우 로그인 화면의 '비밀번호 찾기'에서 사번과 사내 이메일로 재설정 링크를 받을 수 있고, 링크는 30분간 유효하다. 5회 연속 로그인 실패 시 계정은 15분간 잠긴다. 공용 계정 사용은 원칙적으로 금지하며, 불가피한 경우 비밀 관리 도구로 접근을 통제하고 사용 이력을 남긴다.

권한은 최소 권한 원칙(least privilege)에 따라 부여하며, 직무 변경 시 기존 권한을 회수하고 재부여한다. 프로덕션 데이터베이스 접근은 승인된 인원에 한해 임시 권한으로만 부여되며, 모든 접근은 감사 로그로 기록된다. 권한 부여는 요청-승인 절차를 거치고, 분기마다 전체 권한을 재검토(access review)하여 불필요한 권한을 제거한다. 민감 시스템 접근에는 추가 승인과 사유 기록이 요구된다.

기기 보안으로 노트북은 디스크 암호화와 화면 자동 잠금이 강제되며, 분실·도난 시 즉시 원격 잠금·초기화한다. 사내 소프트웨어는 승인된 목록에서 설치하고, 미승인 외부 도구로 회사 데이터를 처리하지 않는다. 고객 개인정보가 포함된 데이터는 저장 시 암호화하고 전송 시 TLS를 사용하며, 외부로 반출할 때는 별도 승인을 받는다.

보안 사고가 의심되면 즉시 보안팀(security@)에 신고하고 해당 계정의 세션을 강제 종료한다. 신고는 처벌 대상이 아니며, 늦은 은폐보다 빠른 신고를 권장한다. 퇴사자 계정은 마지막 근무일 18시에 일괄 비활성화되고 자산이 회수된다. 분기마다 전 직원 보안 교육과 피싱(phishing) 모의 훈련을 실시하고, 미이수자에게는 재교육과 별도 안내를 보낸다."""},

  {"id": "fin-expense", "title": "경비 처리 및 법인카드 규정",
   "text": """업무 관련 경비는 법인카드 사용을 원칙으로 하며, 개인 결제 후 환급은 예외적인 경우에만 허용된다. 법인카드는 사적 용도로 사용할 수 없으며, 위반 시 사용이 정지되고 회수될 수 있다. 카드 분실 시 즉시 카드사와 재무팀에 신고해 정지하고 재발급을 요청한다. 한도 상향이 필요하면 사유와 함께 사전에 신청한다.

경비 증빙은 결제일로부터 7영업일 이내에 전자 영수증과 함께 경비 시스템에 등록해야 한다. 영수증에는 사용 일자, 금액, 항목, 사용 목적이 명시되어야 하며, 5만 원 이상 지출은 사전 또는 사후에 팀장 승인이 필요하다. 적격 증빙(세금계산서·현금영수증·카드전표)이 없는 경우 원칙적으로 비용 처리가 어렵고, 부득이한 경우 지출결의로 대체하되 사유를 기재한다.

식대는 1인 1식 2만 원 한도이며, 팀 회식은 1인 5만 원 한도로 사전 승인 시 인정된다. 야근 식대는 1만 5천 원 한도로 별도 지원되고, 주말 근무 시에도 동일 기준이 적용된다. 출장 시 교통비는 실비로 정산하고, 숙박비는 도시 등급에 따라 1박 12만~18만 원 한도로 지급된다. 출장 일당(식대·잡비)은 국내 3만 원, 해외 5만 원이 별도 지급되며, 일당이 지급되는 경우 식대는 일당에 포함한다.

도서 및 교육비는 직무 관련성이 인정되면 연 100만 원 한도로 지원되며, 팀장 승인이 필요하다. 소프트웨어 구독과 장비 구매는 IT·재무 검토를 거쳐 중복 구매를 방지한다. 접대비는 사용 목적과 참석자를 명확히 기재해야 하고, 한도 초과분은 본인 부담이다. 외화 결제는 결제일 환율로 환산해 정산한다.

월말 정산은 익월 5일까지 마감하며, 미정산 건은 급여에서 차감될 수 있다. 정산 내역은 팀장 1차 검토 후 재무팀이 최종 확인하며, 부적정 지출은 소명을 요청한다. 반복적·고액 지출 항목은 예산 계획에 반영하고, 분기마다 부서별 집행 현황을 공유한다."""},

  {"id": "onboard", "title": "신규 입사자 온보딩 가이드",
   "text": """입사 첫날에는 노트북 수령, 계정 발급, 보안 교육을 완료하고 사내 위키 접근 권한을 받는다. 인사팀이 복리후생·근태 시스템 사용법을 안내하고, IT팀이 개발 도구 설치를 지원한다. 첫날 오후에는 팀에 합류해 좌석·협업 도구·캘린더를 설정하고, 자기소개와 함께 팀의 업무 범위를 공유받는다. 필수 교육 이수 목록은 온보딩 체크리스트로 제공된다.

첫 주에는 온보딩 버디가 배정되어 개발 환경 설정, 코드베이스 구조, 배포 절차를 함께 익힌다. 버디는 같은 팀의 선임 개발자가 맡으며, 매일 15분 체크인을 갖고 막힌 부분을 빠르게 해소한다. 첫 주 금요일에는 팀 소개 세션과 제품 데모에 참석하고, 아키텍처 개요 문서를 읽으며 궁금한 점을 정리해 질문한다. 사내 용어집과 자주 쓰는 문서 링크를 모은 시작 페이지가 제공된다.

2주 차에는 작은 규모의 첫 과제(스타터 티켓)를 맡아 PR 작성부터 배포까지 전 과정을 경험한다. 개발 환경은 사내 표준에 따라 Python 3.12와 uv 기반 가상환경을 사용하며, 윈도우 사용자는 PowerShell에서 동일하게 설정한다. 로컬 실행, 테스트, 코드 리뷰 반영, 스테이징 확인, 배포 절차를 한 번씩 직접 수행하며 흐름을 익힌다. 첫 PR은 버디가 함께 리뷰하며 관행을 설명한다.

이후 몇 주에 걸쳐 도메인 지식과 운영 절차를 단계적으로 학습한다. 온콜 관찰자(shadow)로 참여해 장애 대응 흐름을 지켜보고, 점차 실제 업무 비중을 늘려 간다. 정기 1:1을 통해 기대 역할을 맞추고, 학습 목표를 조정한다.

30일, 60일, 90일 시점에 매니저와 정기 면담을 통해 적응 상태와 목표를 점검한다. 90일 차에는 수습 평가가 이루어지며, 기대 역할과 성장 방향을 함께 정리한다. 온보딩 중 받은 질문과 답변, 막혔던 지점은 위키에 정리해 다음 입사자의 온보딩 시간을 줄이는 데 활용한다. 모르는 것은 언제든 질문하는 문화를 권장하고, 좋은 질문은 문서 개선의 신호로 본다."""},

  {"id": "arch", "title": "제품 아키텍처 개요",
   "text": """누구나테크의 서비스는 프론트엔드, API 게이트웨이, 다수의 백엔드 마이크로서비스, 데이터 계층으로 구성된다. 전체 시스템은 쿠버네티스 클러스터 위에서 운영되며, 인프라는 코드(IaC)로 관리되어 환경 간 일관성을 유지한다. 배포·확장·복구는 선언적 구성으로 자동화되어 있고, 변경은 코드 리뷰와 동일한 절차를 거친다.

프론트엔드는 단일 페이지 애플리케이션으로 CDN을 통해 정적 자산을 배포하고, 인증은 게이트웨이에서 토큰 검증으로 처리한다. API 게이트웨이는 라우팅, 인증, 속도 제한, 요청 로깅을 담당하며 모든 외부 트래픽의 단일 진입점 역할을 한다. 게이트웨이는 비정상 트래픽을 차단하고, 클라이언트별 호출량을 제어하여 과부하를 방지한다. 공통 관심사를 게이트웨이로 모아 각 서비스의 책임을 줄인다.

백엔드 서비스는 각자 독립된 데이터베이스를 소유하며(Database per Service), 서비스 간 통신은 동기 REST와 비동기 메시지 큐를 함께 사용한다. 강한 결합을 피하기 위해 도메인 이벤트를 메시지 큐로 발행하고 구독하는 이벤트 기반 패턴을 활용한다. 분산 트랜잭션은 사가(Saga) 패턴으로 보상 처리하며, 메시지 처리에 멱등성을 보장해 중복·재시도 상황에서도 안전하게 동작한다.

검색 기능은 벡터 데이터베이스를 활용한 의미 기반 검색과 기존 키워드 검색을 결합한 하이브리드 방식으로 동작한다. 검색 색인은 비동기 파이프라인을 통해 갱신되며, 원본 데이터 변경이 일정 시간 내 색인에 반영된다. 대규모 조회는 캐시 계층을 우선 활용한다. 관측성을 위해 모든 서비스는 구조화된 로그, 지표, 분산 추적을 수집하며 대시보드와 알림으로 모니터링한다.

데이터 계층은 주 데이터베이스의 읽기 부하를 줄이기 위해 캐시와 읽기 전용 복제본을 둔다. 장애 격리를 위해 서킷 브레이커와 타임아웃, 재시도 정책을 적용하며, 한 서비스의 장애가 전체로 번지지 않도록 격벽(bulkhead)을 둔다. 용량은 자동 확장으로 트래픽에 맞춰 조절하고, 정기적으로 장애 주입 훈련을 통해 복원력을 검증한다. 보안 경계는 네트워크 정책과 비밀 관리로 통제한다."""},

  {"id": "perf", "title": "성과 평가 및 승진 제도",
   "text": """성과 평가는 반기마다(상·하반기) 이루어지며, 목표 설정(OKR), 중간 점검, 최종 평가의 3단계로 진행된다. 목표는 도전적이되 측정 가능하게 설정하고, 회사·팀 목표와 정렬한다. 분기 중 환경 변화가 있으면 목표를 조정하고 그 사유를 기록한다. 평가는 본인 자기평가, 동료 평가(피어 리뷰), 매니저 평가를 종합하여 산정한다.

평가 등급은 5단계(탁월/우수/충족/개선 필요/미흡)로 구분되며, 등급에 따라 성과급과 연봉 인상률이 결정된다. 절대평가를 원칙으로 하되, 등급 분포는 조직 차원에서 보정(calibration) 회의를 거쳐 평가자 간 기준 편차를 줄인다. 평가는 결과뿐 아니라 협업·영향력·성장 같은 행동 요소도 함께 보며, 구체적 사례를 근거로 작성한다.

피드백은 평가 시점에만 몰아주지 않고 상시로 제공하는 것을 지향한다. 정기 1:1에서 진행 상황과 기대치를 맞추고, 잘한 점과 개선점을 균형 있게 전달한다. 성장에 도움이 되도록 구체적이고 실행 가능한 형태로 피드백을 준다.

승진은 직무 레벨(주니어, 미들, 시니어, 스태프, 프린시펄)에 따른 역량 기준을 충족할 때 이루어지며, 연 1회 승진 심사가 열린다. 승진 후보는 매니저 추천과 함께 성과 근거 자료(승진 패킷)를 제출하고, 승진 위원회의 심의를 거친다. 기술 트랙과 매니지먼트 트랙은 동등하게 인정되며, 본인이 경로를 선택할 수 있고 중간에 전환도 가능하다.

저성과자에게는 개선 계획(PIP)이 제공되며, 정해진 기간 동안 구체적 목표와 지원이 함께 제공된다. 개선이 확인되면 정상 복귀하고, 그렇지 않은 경우 별도 절차를 따른다. 평가 결과에 대한 이의 제기 절차가 마련되어 있으며, 인사팀이 중재한다. 모든 평가 기록은 일정 기간 보관되어 성장 추세를 추적하고 다음 목표 설정에 활용된다."""},

  {"id": "privacy", "title": "데이터 거버넌스 및 개인정보 보호",
   "text": """모든 데이터는 민감도에 따라 공개·내부·기밀·개인정보의 4단계로 분류되며, 분류에 따라 접근 권한과 보관 정책이 달라진다. 데이터 소유자는 각 데이터셋의 분류와 접근 권한을 책임지고, 분류 라벨을 메타데이터로 관리한다. 새로운 데이터셋을 만들 때는 분류를 먼저 지정하고 그에 맞는 보호 조치를 적용한다.

고객 개인정보 수집은 목적에 필요한 최소한으로 제한하며, 수집 시 이용 목적과 보관 기간을 고지하고 동의를 받는다. 수집 항목과 처리 목적은 처리방침에 명시하고 변경 시 갱신한다. 보관 기간이 지난 개인정보는 안전하게 파기하고 파기 기록을 남긴다. 동의 철회나 열람·정정·삭제 요청이 들어오면 정해진 기한 내에 처리하고 결과를 통지한다.

개인정보가 포함된 데이터를 분석에 활용할 때는 가명처리 또는 익명처리를 우선 적용한다. 운영 데이터를 개발·테스트 환경으로 복제할 때는 반드시 마스킹하며, 원본 접근은 최소한의 인원으로 제한하고 접근 기록을 남긴다. 제3자 제공 및 국외 이전은 법적 요건을 충족하고 별도 승인을 거치며, 처리 위탁 시 계약과 수탁사 점검을 수행한다.

내부 직원의 개인정보 접근도 업무 목적으로 한정하며, 대량 조회나 내려받기는 별도 통제와 로깅을 적용한다. 데이터 공유 채널과 외부 전송 도구는 승인된 것만 사용한다. 정기적으로 접근 권한과 보관 현황을 점검해 과도한 보관이나 권한을 정리한다.

개인정보 유출이 의심되면 즉시 보안팀과 개인정보 보호책임자(DPO)에게 보고하고, 관련 법령이 정한 기한 내 통지 절차를 따른다. 사고 대응은 사실 확인, 피해 최소화, 통지, 재발 방지의 순서로 진행한다. 연 1회 개인정보 영향평가와 접근 권한 점검을 수행하고, 처리 활동 기록을 최신 상태로 유지하여 감사에 대비한다."""},

  {"id": "support", "title": "고객 지원 및 SLA",
   "text": """고객 문의는 인앱 채팅, 이메일, 헬프센터를 통해 접수되며, 1차 응답 목표 시간(SLA)은 일반 문의 24시간, 유료 고객 4시간, 긴급 장애 1시간이다. 접수된 문의는 우선순위와 카테고리에 따라 분류되어 처리되고, 진행 상황은 티켓 시스템에 기록되어 담당자 간 인계가 가능하다. 응답 지연이 예상되면 중간 안내를 보낸다.

지원팀이 해결하기 어려운 기술 문제는 엔지니어링팀으로 에스컬레이션되며, 에스컬레이션 기준과 담당자는 온콜 일정과 연동된다. 에스컬레이션 시에는 재현 절차, 로그, 영향 범위를 함께 전달해 분석 시간을 줄인다. 반복되는 문의는 헬프센터 문서로 정리하여 셀프서비스를 강화하고, 제품 개선 요청으로 연결한다.

서비스 가용성 목표는 월 99.9%이며, 이를 초과하는 다운타임이 발생하면 SLA 정책에 따라 유료 고객에게 크레딧을 제공한다. 계획된 점검은 최소 72시간 전에 공지하고 트래픽이 낮은 시간대에 수행한다. 대규모 장애 시에는 상태 페이지와 함께 별도 사후 안내문을 발송하고, 영향과 조치를 투명하게 공유한다.

지원 품질을 유지하기 위해 응답 시간·해결 시간·재문의율 등의 지표를 관리한다. 어려운 사례는 팀 내 공유 세션에서 다루어 노하우를 확산한다. 자주 묻는 질문과 해결 절차는 표준 답변으로 정리해 일관성을 높인다.

고객 만족도는 문의 종료 후 CSAT 설문으로 측정하며, 분기별로 추세를 검토해 프로세스를 개선한다. 주요 고객에게는 전담 매니저(CSM)가 배정되어 정기 점검과 활용 지원을 제공하고, 갱신·확장 기회를 함께 관리한다. 고객 피드백은 제품팀과 공유되어 우선순위와 로드맵에 반영된다."""},

  {"id": "review", "title": "코드 리뷰 가이드",
   "text": """코드 리뷰의 목적은 결함을 조기에 발견하고 지식을 공유하며 코드 품질의 일관성을 유지하는 것이다. 리뷰는 비난이 아니라 협업이며, 코드를 대상으로 하되 사람을 대상으로 하지 않는다. 좋은 리뷰 문화는 심리적 안전감을 바탕으로 하며, 질문과 제안을 환영한다.

PR은 가능한 한 작게(권장 400줄 이하) 유지하고, 변경의 목적과 맥락을 설명하는 설명문을 포함한다. 큰 변경은 여러 PR로 나누거나, 리뷰어가 따라가기 쉽도록 커밋을 논리 단위로 정리한다. 관련 이슈와 테스트 결과, 스크린샷 등 검토에 도움이 되는 정보를 함께 첨부한다. 리뷰어는 영업일 기준 1일 이내에 1차 리뷰를 제공하는 것을 목표로 하며, 긴급 PR은 라벨로 표시해 우선 처리한다.

리뷰어는 정확성, 가독성, 테스트 커버리지, 보안, 성능 관점에서 확인한다. 사소한 스타일 문제는 자동 포매터·린터에 맡기고, 리뷰는 설계와 로직, 경계 조건에 집중한다. 의견은 '제안(nit)'과 '필수 수정(blocking)'을 구분해 표기해 작성자가 우선순위를 알 수 있게 한다. 좋은 점은 명시적으로 칭찬해 모범 사례를 강화한다.

작성자는 모든 코멘트에 응답하고, 반영하거나 반영하지 않는 이유를 남긴다. 의견이 갈릴 때는 댓글을 길게 주고받기보다 동기 대화로 빠르게 합의하고, 합의가 어려우면 테크 리드가 결정한다. 합의된 결정은 PR에 요약해 남겨 맥락을 보존한다.

승인 후 작성자가 머지하며, CI 통과는 머지의 전제 조건이다. 머지 방식과 브랜치 정리는 팀 규칙을 따른다. 리뷰에서 반복적으로 지적되는 패턴은 가이드라인이나 자동화 규칙(린트·템플릿)으로 흡수해 같은 논의를 줄이고, 신규 입사자가 빠르게 관행을 익히도록 문서화한다."""},

]

print(f"문서 {len(raw_docs)}건, 총 글자수 {sum(len(d['text']) for d in raw_docs):,}자")
문서 12건, 총 글자수 11,797자
 

4. 청킹

split_corpus(chunk_size) 는 코퍼스를 지정 크기로 잘라 Document 목록을 반환한다. 메타데이터에 출처·제목·청크 번호를 넣어 근거 추적을 가능하게 한다. 셀 끝에서 크기 200/500/1000/1500 의 청크 수를 비교한다.

from langchain_text_splitters import RecursiveCharacterTextSplitter  # 재귀적 문자 분할기
from langchain_core.documents import Document                        # LangChain 표준 문서 객체

def split_corpus(chunk_size: int, chunk_overlap: int = 40):
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,            # 한 청크의 최대 글자 수
        chunk_overlap=chunk_overlap,      # 인접 청크 간 겹치는 글자 수
        separators=["\n\n", "\n", ". ", " ", ""],  # 큰 단위→작은 단위 순으로 분할 시도
    )
    chunks = []                            # 결과 청크들을 담을 리스트
    for d in raw_docs:                     # 모든 원본 문서를 순회
        for i, piece in enumerate(splitter.split_text(d["text"])):  # 본문을 청크로 분할
            chunks.append(Document(
                page_content=piece,                                  # 청크 본문
                metadata={"source": d["id"], "title": d["title"], "chunk": i},  # 출처 추적용 메타데이터
            ))
    return chunks

# 세 가지 크기로 각각 몇 개의 청크가 나오는지 비교
for size in [200, 500, 1000, 1500]:
    n = len(split_corpus(size))            # 해당 크기로 분할했을 때 청크 수
    print(f"chunk_size={size:<5} → 청크 {n}개")
chunk_size=200   → 청크 89개
chunk_size=500   → 청크 34개
chunk_size=1000  → 청크 18개
chunk_size=1500  → 청크 12개
 

🔍 관찰 포인트

  • 작을수록 청크 수가 많아진다(더 잘게 분할). 저장·검색 비용과 정밀도 사이의 트레이드오프가 여기서 시작된다.
 

5. 임베딩 & 인덱스 연결

S2에서 만든 agentic-rag-lab 인덱스를 재사용한다(없으면 생성). 임베딩은 PineconeEmbeddings("multilingual-e5-large")(1024차원).

import os
from pinecone import Pinecone, ServerlessSpec
from langchain_pinecone import PineconeVectorStore, PineconeEmbeddings

embeddings = PineconeEmbeddings(model="multilingual-e5-large")   # 한국어 임베딩(1024차원)
EMBED_DIM = 1024

INDEX_NAME = "agentic-rag-lab"
pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])
if INDEX_NAME not in [ix["name"] for ix in pc.list_indexes()]:  # 없으면 생성
    pc.create_index(name=INDEX_NAME, dimension=EMBED_DIM, metric="cosine",
                    spec=ServerlessSpec(cloud="aws", region="us-east-1"))
index = pc.Index(INDEX_NAME)
print("인덱스 준비 완료")
인덱스 준비 완료
 

6. 청크 크기별 색인 — 네임스페이스 분리

공정한 비교를 위해 크기별로 다른 네임스페이스(chunk_200/500/1000/1500)에 색인한다. PineconeVectorStore.add_documents 가 임베딩→업서트를 한 번에 처리한다.

SIZES = [200, 500, 1000, 1500]                 # 비교할 청크 크기들

for size in SIZES:
    ns = f"chunk_{size}"                  # 이 크기 전용 네임스페이스 이름
    chunks = split_corpus(size)          # 해당 크기로 코퍼스 분할
    store = PineconeVectorStore(         # 네임스페이스를 지정한 벡터스토어
        index=index,
        embedding=embeddings,
        namespace=ns,                    # 색인 대상 네임스페이스
    )
    store.add_documents(chunks)          # 임베딩 후 해당 네임스페이스에 색인
    print(f"[{ns}] 청크 {len(chunks)}개 색인 완료")
[chunk_200] 청크 89개 색인 완료
[chunk_500] 청크 34개 색인 완료
[chunk_1000] 청크 18개 색인 완료
[chunk_1500] 청크 12개 색인 완료
 

7. 청크 크기 비교 실험

동일 질문 세트를 네 네임스페이스에 던져 비교한다. 질문 두 개는 성격을 달리했다 — 하나는 한 문서 내 여러 정보를 묶어야 하고(큰 청크 유리 가능), 하나는 특정 절차 한 군데다(작은 청크 정밀 가능).

def search_in(ns: str, query: str, k: int = 3):
    store = PineconeVectorStore(index=index, embedding=embeddings, namespace=ns)  # 해당 네임스페이스 연결
    return store.similarity_search_with_score(query, k=k)   # (문서, 점수) 리스트 반환

questions = [
    "연차 이월 규정과 경조사 휴가는 어떻게 되나요?",   # 한 문서 안 여러 단락 결합 → 큰 청크 유리 가능
    "프로덕션 배포는 누가 최종 승인하나요?",          # 한 문장 핀포인트 → 작은 청크 유리 가능
    "장애 등급별 1차 대응 시간과 포스트모템 절차는?",  # 여러 단락에 흩어진 정보 → 큰 청크 유리 가능
    "재택근무 시 지켜야 할 보안 요건은?",            # 주제 경계(재택+보안) → 검색 변별력 확인
]

for q in questions:
    print("=" * 72)
    print("Q:", q)
    for size in SIZES:                                   # 네 가지 청크 크기에 대해
        ns = f"chunk_{size}"
        hits = search_in(ns, q, k=3)                      # 동일 질의로 검색
        print(f"\n  [chunk_size={size}]")
        for doc, score in hits:                           # 상위 결과 출력
            preview = doc.page_content[:70].replace("\n", " ")  # 한 줄 미리보기
            print(f"    {round(score,3)} | {doc.metadata['title']} | {preview}...")
    print()
========================================================================
Q: 연차 이월 규정과 경조사 휴가는 어떻게 되나요?

  [chunk_size=200]
    0.861 | 휴가 및 연차 정책 | 경조사 휴가는 연차와 별도로 부여된다. 본인 결혼은 5일, 자녀 결혼은 1일, 자녀 출산(배우자)은 10일, 직계가족 사망은 ...
    0.836 | 휴가 및 연차 정책 | 미사용 연차는 회계연도 종료 후 다음 해로 최대 5일까지 이월되며, 이월된 연차는 다음 해 상반기(6월 말) 안에 모두 소진해...
    0.833 | 휴가 및 연차 정책 | 반차는 오전(09:00~13:00)과 오후(14:00~18:00)로 나누어 사용할 수 있고, 반반차(2시간) 단위도 허용된다....

  [chunk_size=500]
    0.864 | 휴가 및 연차 정책 | 반차는 오전(09:00~13:00)과 오후(14:00~18:00)로 나누어 사용할 수 있고, 반반차(2시간) 단위도 허용된다....
    0.825 | 휴가 및 연차 정책 | 누구나테크의 연차 휴가는 입사 1년 차에 15일이 부여되며, 근속 2년마다 1일씩 가산되어 최대 25일까지 늘어난다. 입사 첫...
    0.82 | 휴가 및 연차 정책 | 병가는 연 60일 한도로 사용 가능하며, 연속 3일을 초과하는 병가는 의사 진단서를 제출해야 한다. 업무상 질병·부상은 별도의...

  [chunk_size=1000]
    0.855 | 휴가 및 연차 정책 | 누구나테크의 연차 휴가는 입사 1년 차에 15일이 부여되며, 근속 2년마다 1일씩 가산되어 최대 25일까지 늘어난다. 입사 첫...
    0.82 | 휴가 및 연차 정책 | 병가는 연 60일 한도로 사용 가능하며, 연속 3일을 초과하는 병가는 의사 진단서를 제출해야 한다. 업무상 질병·부상은 별도의...
    0.808 | 경비 처리 및 법인카드 규정 | 업무 관련 경비는 법인카드 사용을 원칙으로 하며, 개인 결제 후 환급은 예외적인 경우에만 허용된다. 법인카드는 사적 용도로 사...

  [chunk_size=1500]
    0.855 | 휴가 및 연차 정책 | 누구나테크의 연차 휴가는 입사 1년 차에 15일이 부여되며, 근속 2년마다 1일씩 가산되어 최대 25일까지 늘어난다. 입사 첫...
    0.808 | 경비 처리 및 법인카드 규정 | 업무 관련 경비는 법인카드 사용을 원칙으로 하며, 개인 결제 후 환급은 예외적인 경우에만 허용된다. 법인카드는 사적 용도로 사...
    0.798 | 재택근무 및 유연근무 제도 | 재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주...

========================================================================
Q: 프로덕션 배포는 누가 최종 승인하나요?

  [chunk_size=200]
    0.881 | 배포 및 릴리스 프로세스 | 프로덕션 배포는 QA 승인 이후 릴리스 담당자가 배포 태그를 생성하고, 마지막으로 엔지니어링 리드가 수동으로 승인하는 2단계 ...
    0.818 | 배포 및 릴리스 프로세스 | 문제가 감지되면 직전 배포 태그로 롤백하며, 롤백은 평균 1분 이내에 완료되도록 자동화되어 있다. 긴급 핫픽스는 별도 승인 절...
    0.818 | 보안 및 계정 관리 규정 | 권한은 최소 권한 원칙(least privilege)에 따라 부여하며, 직무 변경 시 기존 권한을 회수하고 재부여한다. 프로덕...

  [chunk_size=500]
    0.859 | 배포 및 릴리스 프로세스 | 프로덕션 배포는 QA 승인 이후 릴리스 담당자가 배포 태그를 생성하고, 마지막으로 엔지니어링 리드가 수동으로 승인하는 2단계 ...
    0.813 | 배포 및 릴리스 프로세스 | 모든 코드는 기능 브랜치에서 작업한 뒤 Pull Request를 통해 main 브랜치로 병합한다. PR은 최소 1인 이상의 코...
    0.818 | 배포 및 릴리스 프로세스 | 문제가 감지되면 직전 배포 태그로 롤백하며, 롤백은 평균 1분 이내에 완료되도록 자동화되어 있다. 긴급 핫픽스는 별도 승인 절...

  [chunk_size=1000]
    0.822 | 배포 및 릴리스 프로세스 | 모든 코드는 기능 브랜치에서 작업한 뒤 Pull Request를 통해 main 브랜치로 병합한다. PR은 최소 1인 이상의 코...
    0.818 | 배포 및 릴리스 프로세스 | 문제가 감지되면 직전 배포 태그로 롤백하며, 롤백은 평균 1분 이내에 완료되도록 자동화되어 있다. 긴급 핫픽스는 별도 승인 절...
    0.788 | 보안 및 계정 관리 규정 | 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로...

  [chunk_size=1500]
    0.822 | 배포 및 릴리스 프로세스 | 모든 코드는 기능 브랜치에서 작업한 뒤 Pull Request를 통해 main 브랜치로 병합한다. PR은 최소 1인 이상의 코...
    0.786 | 보안 및 계정 관리 규정 | 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로...
    0.775 | 데이터 거버넌스 및 개인정보 보호 | 모든 데이터는 민감도에 따라 공개·내부·기밀·개인정보의 4단계로 분류되며, 분류에 따라 접근 권한과 보관 정책이 달라진다. 데...

========================================================================
Q: 장애 등급별 1차 대응 시간과 포스트모템 절차는?

  [chunk_size=200]
    0.85 | 장애 대응 및 온콜 운영 | 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템...
    0.838 | 장애 대응 및 온콜 운영 | 온콜 담당자는 알림 수신 후 Sev1은 5분, Sev2는 15분, Sev3은 1시간 이내에 1차 대응을 시작해야 하며, 주간·...
    0.82 | 신규 입사자 온보딩 가이드 | 이후 몇 주에 걸쳐 도메인 지식과 운영 절차를 단계적으로 학습한다. 온콜 관찰자(shadow)로 참여해 장애 대응 흐름을 지켜...

  [chunk_size=500]
    0.845 | 장애 대응 및 온콜 운영 | 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템...
    0.831 | 장애 대응 및 온콜 운영 | 서비스 장애는 영향 범위에 따라 Sev1(전면 장애), Sev2(주요 기능 장애), Sev3(부분/경미)로 분류한다. Sev1...
    0.825 | 신규 입사자 온보딩 가이드 | 2주 차에는 작은 규모의 첫 과제(스타터 티켓)를 맡아 PR 작성부터 배포까지 전 과정을 경험한다. 개발 환경은 사내 표준에 ...

  [chunk_size=1000]
    0.844 | 장애 대응 및 온콜 운영 | 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템...
    0.821 | 장애 대응 및 온콜 운영 | 서비스 장애는 영향 범위에 따라 Sev1(전면 장애), Sev2(주요 기능 장애), Sev3(부분/경미)로 분류한다. Sev1...
    0.815 | 배포 및 릴리스 프로세스 | 문제가 감지되면 직전 배포 태그로 롤백하며, 롤백은 평균 1분 이내에 완료되도록 자동화되어 있다. 긴급 핫픽스는 별도 승인 절...

  [chunk_size=1500]
    0.84 | 장애 대응 및 온콜 운영 | 서비스 장애는 영향 범위에 따라 Sev1(전면 장애), Sev2(주요 기능 장애), Sev3(부분/경미)로 분류한다. Sev1...
    0.81 | 고객 지원 및 SLA | 고객 문의는 인앱 채팅, 이메일, 헬프센터를 통해 접수되며, 1차 응답 목표 시간(SLA)은 일반 문의 24시간, 유료 고객 ...
    0.809 | 신규 입사자 온보딩 가이드 | 입사 첫날에는 노트북 수령, 계정 발급, 보안 교육을 완료하고 사내 위키 접근 권한을 받는다. 인사팀이 복리후생·근태 시스템 ...

========================================================================
Q: 재택근무 시 지켜야 할 보안 요건은?

  [chunk_size=200]
    0.884 | 재택근무 및 유연근무 제도 | 재택 시에는 회사가 지급한 노트북과 VPN을 사용해야 하며, 개인 기기에서 사내 시스템에 접속하는 것은 금지된다. 카페 등 공...
    0.845 | 재택근무 및 유연근무 제도 | . 재택근무 중 발생한 산업재해도 근무시간·업무 연관성이 인정되면 보상 대상이 되므로, 사고 발생 시 즉시 보고한다....
    0.845 | 재택근무 및 유연근무 제도 | 월 1회 이상은 팀 동기화를 위해 사무실 출근이 권장되며, 분기마다 전사 오프사이트가 열린다. 팀별로 정기 대면 협업일을 지정...

  [chunk_size=500]
    0.887 | 재택근무 및 유연근무 제도 | 재택 시에는 회사가 지급한 노트북과 VPN을 사용해야 하며, 개인 기기에서 사내 시스템에 접속하는 것은 금지된다. 카페 등 공...
    0.849 | 재택근무 및 유연근무 제도 | 재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주...
    0.847 | 재택근무 및 유연근무 제도 | 월 1회 이상은 팀 동기화를 위해 사무실 출근이 권장되며, 분기마다 전사 오프사이트가 열린다. 팀별로 정기 대면 협업일을 지정...

  [chunk_size=1000]
    0.867 | 재택근무 및 유연근무 제도 | 재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주...
    0.847 | 재택근무 및 유연근무 제도 | 월 1회 이상은 팀 동기화를 위해 사무실 출근이 권장되며, 분기마다 전사 오프사이트가 열린다. 팀별로 정기 대면 협업일을 지정...
    0.84 | 보안 및 계정 관리 규정 | 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로...

  [chunk_size=1500]
    0.865 | 재택근무 및 유연근무 제도 | 재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주...
    0.808 | 경비 처리 및 법인카드 규정 | 업무 관련 경비는 법인카드 사용을 원칙으로 하며, 개인 결제 후 환급은 예외적인 경우에만 허용된다. 법인카드는 사적 용도로 사...
    0.844 | 보안 및 계정 관리 규정 | 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로...
 

실험 결과 해석 가이드

  • 이 셀의 출력은 같은 질문을 chunk_200, chunk_500, chunk_1000, chunk_1500 네 개의 검색 공간에 각각 던진 결과를 나란히 보여 준다.
  • 각 줄의 점수(score) 는 질의와 청크가 얼마나 가깝게 매칭되었는지를 나타내고, 뒤의 title 과 preview 는 "어느 문서의 어떤 부분이 잡혔는지"를 빠르게 확인하기 위한 정보다.
  • 점수가 조금 높다고 해서 항상 더 좋은 결과라고 단정할 수는 없다. 실제로는 질문이 요구한 정보가 청크 안에 충분히 들어 있는지, 불필요한 내용이 많이 섞이지 않았는지를 함께 봐야 한다.
  • 예를 들어 프로덕션 배포는 누가 최종 승인하나요? 같은 핀포인트 질문은 작은 청크가 정답 문장을 더 날카롭게 집을 가능성이 크다. 반대로 연차 이월 규정과 경조사 휴가는 어떻게 되나요?처럼 한 문서 안의 여러 항목을 함께 묻는 질문은 더 큰 청크가 문맥을 한 번에 담아 유리할 수 있다.
  • 재택근무 시 지켜야 할 보안 요건은? 같은 질문은 재택근무 문서와 보안 문서의 경계에서 어떤 청크가 더 적절한 근거를 주는지 보기 좋다. 이때는 점수만 보지 말고, 상위 결과가 정말 재택 시 보안 수칙을 설명하는 청크인지 확인해야 한다.
  • 결국 이 실험의 목적은 "가장 높은 점수 하나"를 찾는 것이 아니라, 우리 도메인 질문에서 어떤 청크 크기가 가장 일관되게 쓸 만한 근거를 반환하는지 감각을 얻는 데 있다.
 

질문별로 이렇게 해석하면 좋다

  • 연차 이월 규정과 경조사 휴가는 어떻게 되나요?는 같은 문서 안의 서로 다른 항목을 함께 묻는다. 이 경우 너무 작은 청크는 정보가 둘로 갈라질 수 있어, 상위 결과 여러 개를 함께 읽어야 할 가능성이 크다.
  • 프로덕션 배포는 누가 최종 승인하나요?는 특정 절차의 특정 역할을 찾는 질문이다. 이런 질문은 작은 청크가 불필요한 문맥 없이 정답 문장을 더 선명하게 잡는 경우가 많다.
  • 장애 등급별 1차 대응 시간과 포스트모템 절차는?는 한 문서 안에서도 떨어진 위치의 정보를 함께 요구한다. 따라서 큰 청크는 한 번에 더 많은 맥락을 담아 줄 수 있지만, 반대로 너무 많은 부가 설명이 섞여 핵심 문장이 흐려질 수도 있다.
  • 재택근무 시 지켜야 할 보안 요건은?는 재택근무 문서 안의 보안 단락이 잘 잡히는지 보는 질문이다. 이때 상위 결과가 단순히 재택근무 일반 설명인지, 아니면 실제로 VPN, 개인 기기 금지, 공용 공간 주의 같은 보안 규칙을 담고 있는지 확인하는 것이 중요하다.
  • 따라서 실험 결과를 읽을 때는 점수 순위, 문서 제목, 미리보기 내용을 함께 보고, "이 청크가 질문에 답할 준비가 된 근거인가?"를 기준으로 판단해야 한다.
 

🔍 관찰 포인트

  • 작은 청크(200): 딱 맞는 문장을 정확히 집지만 연결된 맥락이 잘릴 수 있다.
  • 큰 청크(1000): 맥락은 좋지만 무관 문장 혼입으로 점수가 희석될 수 있다.
  • 유리한 크기는 질문 유형에 따라 다르다 — 도메인 문서와 질문 유형에 맞춰 실험으로 정한다.
 

✏️ 미니 실습

  1. chunk_overlap 을 0·100으로 바꿔 같은 실험을 반복한다.
  2. 본인 도메인 질문 2개를 추가해 안정적인 크기를 결론짓는다.
  3. (도전) "정답 포함 여부" 를 라벨링해 간단한 적중률을 계산한다 → S10의 정량 평가로 연결.
# 미니 실습 모범 답안
# 이 셀은 세 가지를 한 번에 보여 줍니다.
# 1) chunk_overlap 을 0, 100으로 바꿔 다시 색인합니다.
# 2) 추가 질문 2개를 넣어 어떤 chunk_size 가 더 안정적인지 비교합니다.
# 3) (도전) top-1 결과에 정답 키워드가 들어 있는지 간단히 점검합니다.

# 이 실습에서만 사용할 청크 크기 목록입니다.
practice_sizes = [200, 500, 1000, 1500]

# overlap 비교를 위해 별도 네임스페이스를 씁니다.
# 이렇게 하면 앞의 본 실험 결과를 덮어쓰지 않고 따로 비교할 수 있습니다.
practice_overlaps = [0, 100]

# 본 실험의 기본 질문들입니다.
base_questions = [
    "연차 이월 규정과 경조사 휴가는 어떻게 되나요?",
    "프로덕션 배포는 누가 최종 승인하나요?",
    "장애 등급별 1차 대응 시간과 포스트모템 절차는?",
    "재택근무 시 지켜야 할 보안 요건은?",
]

# 사용자가 바로 바꿔 볼 수 있는 추가 질문 예시입니다.
# 필요하면 본인 도메인 질문으로 교체해 실험하면 됩니다.
extra_questions = [
    "비밀번호를 잊었을 때 재설정은 어떻게 하나요?",
    "신규 입사자의 첫 주 온보딩에서는 무엇을 하나요?",
]

# 간단한 정답 키워드입니다.
# top-1 문서에 이 단어들이 모두 들어 있으면 '정답을 포함했을 가능성'이 높다고 봅니다.
# 엄밀한 평가는 아니고, S10에서 할 정량 평가의 아주 간단한 맛보기입니다.
answer_keywords = {
    "비밀번호를 잊었을 때 재설정은 어떻게 하나요?": ["비밀번호 찾기", "재설정 링크"],
    "신규 입사자의 첫 주 온보딩에서는 무엇을 하나요?": ["온보딩 버디", "체크인"],
}

# 결과를 한 줄로 보기 쉽게 출력하는 함수입니다.
def print_top_hit(overlap, size, query, doc, score):
    # 미리보기는 너무 길면 읽기 어려우므로 앞부분만 사용합니다.
    preview = doc.page_content[:90].replace("\n", " ")
    print(f"overlap={overlap:<3} | chunk_size={size:<4} | score={round(score, 3)}")
    print(f"  title   : {doc.metadata['title']}")
    print(f"  preview : {preview}...")

# top-1 결과에 정답 키워드가 들어 있는지 아주 단순하게 확인합니다.
def contains_all_keywords(text, keywords):
    # 모든 키워드가 본문에 있으면 True 를 반환합니다.
    return all(keyword in text for keyword in keywords)

# 네임스페이스가 아직 없을 수 있으므로, 없는 경우는 무시하고 진행합니다.
def clear_namespace_if_exists(namespace):
    try:
        index.delete(delete_all=True, namespace=namespace)
    except Exception as error:
        # 첫 실행처럼 네임스페이스가 아직 없을 때는 그냥 넘어갑니다.
        if "Namespace not found" not in str(error):
            raise

# overlap 값마다 별도 네임스페이스에 다시 색인합니다.
for overlap in practice_overlaps:
    print("=" * 72)
    print(f"[재색인] chunk_overlap={overlap}")

    for size in practice_sizes:
        # overlap 과 size 를 함께 넣어 네임스페이스 이름을 만듭니다.
        namespace = f"practice_overlap_{overlap}_chunk_{size}"

        # 같은 셀을 여러 번 실행해도 이전 결과가 중복 저장되지 않게 먼저 비웁니다.
        clear_namespace_if_exists(namespace)

        # 현재 overlap 설정으로 코퍼스를 다시 분할합니다.
        chunks = split_corpus(size, chunk_overlap=overlap)

        # 이 설정 전용 벡터스토어를 만든 뒤 문서를 색인합니다.
        store = PineconeVectorStore(
            index=index,
            embedding=embeddings,
            namespace=namespace,
        )
        store.add_documents(chunks)

        # 몇 개의 청크가 생겼는지 함께 출력해 overlap 의 영향도 확인합니다.
        print(f"  [{namespace}] 청크 {len(chunks)}개 색인 완료")

# 비교 질문은 기본 질문 4개 + 추가 질문 2개를 합쳐서 사용합니다.
practice_questions = base_questions + extra_questions

print("\n" + "#" * 72)
print("[검색 비교 시작]")

# 각 질문에 대해 overlap 과 chunk_size 조합별 top-1 결과를 비교합니다.
for query in practice_questions:
    print("\n" + "=" * 72)
    print("Q:", query)

    for overlap in practice_overlaps:
        print(f"\n  <chunk_overlap={overlap}>")

        for size in practice_sizes:
            namespace = f"practice_overlap_{overlap}_chunk_{size}"
            store = PineconeVectorStore(
                index=index,
                embedding=embeddings,
                namespace=namespace,
            )

            # 비교를 단순하게 하기 위해 top-1 결과만 가져옵니다.
            top_hit = store.similarity_search_with_score(query, k=1)
            doc, score = top_hit[0]
            print_top_hit(overlap, size, query, doc, score)

            # 추가 질문에 대해서만 아주 간단한 키워드 기반 적중 여부를 출력합니다.
            if query in answer_keywords:
                hit = contains_all_keywords(doc.page_content, answer_keywords[query])
                print(f"  keyword_hit: {hit}")

# 필요하면 아래 코드를 참고해 실습용 네임스페이스를 정리할 수 있습니다.
# for overlap in practice_overlaps:
#     for size in practice_sizes:
#         index.delete(delete_all=True, namespace=f"practice_overlap_{overlap}_chunk_{size}")
========================================================================
[재색인] chunk_overlap=0
  [practice_overlap_0_chunk_200] 청크 89개 색인 완료
  [practice_overlap_0_chunk_500] 청크 34개 색인 완료
  [practice_overlap_0_chunk_1000] 청크 18개 색인 완료
  [practice_overlap_0_chunk_1500] 청크 12개 색인 완료
========================================================================
[재색인] chunk_overlap=100
  [practice_overlap_100_chunk_200] 청크 89개 색인 완료
  [practice_overlap_100_chunk_500] 청크 34개 색인 완료
  [practice_overlap_100_chunk_1000] 청크 18개 색인 완료
  [practice_overlap_100_chunk_1500] 청크 12개 색인 완료

########################################################################
[검색 비교 시작]

========================================================================
Q: 연차 이월 규정과 경조사 휴가는 어떻게 되나요?

  <chunk_overlap=0>
overlap=0   | chunk_size=200  | score=0.861
  title   : 휴가 및 연차 정책
  preview : 경조사 휴가는 연차와 별도로 부여된다. 본인 결혼은 5일, 자녀 결혼은 1일, 자녀 출산(배우자)은 10일, 직계가족 사망은 5일, 형제자매 사망은 3일이 주어진...
overlap=0   | chunk_size=500  | score=0.864
  title   : 휴가 및 연차 정책
  preview : 반차는 오전(09:00~13:00)과 오후(14:00~18:00)로 나누어 사용할 수 있고, 반반차(2시간) 단위도 허용된다. 연차 사용은 사용 예정일 3영업일 ...
overlap=0   | chunk_size=1000 | score=0.855
  title   : 휴가 및 연차 정책
  preview : 누구나테크의 연차 휴가는 입사 1년 차에 15일이 부여되며, 근속 2년마다 1일씩 가산되어 최대 25일까지 늘어난다. 입사 첫해에 1년을 채우지 못한 직원은 매월...
overlap=0   | chunk_size=1500 | score=0.855
  title   : 휴가 및 연차 정책
  preview : 누구나테크의 연차 휴가는 입사 1년 차에 15일이 부여되며, 근속 2년마다 1일씩 가산되어 최대 25일까지 늘어난다. 입사 첫해에 1년을 채우지 못한 직원은 매월...

  <chunk_overlap=100>
overlap=100 | chunk_size=200  | score=0.868
  title   : 휴가 및 연차 정책
  preview : . 경조사 휴가는 사유 발생일로부터 한 달 이내에 사용하는 것을 원칙으로 하되, 장례·돌봄 등 부득이한 경우 분할 사용이 가능하며 증빙 서류를 제출한다. 출산·육...
overlap=100 | chunk_size=500  | score=0.864
  title   : 휴가 및 연차 정책
  preview : 반차는 오전(09:00~13:00)과 오후(14:00~18:00)로 나누어 사용할 수 있고, 반반차(2시간) 단위도 허용된다. 연차 사용은 사용 예정일 3영업일 ...
overlap=100 | chunk_size=1000 | score=0.855
  title   : 휴가 및 연차 정책
  preview : 누구나테크의 연차 휴가는 입사 1년 차에 15일이 부여되며, 근속 2년마다 1일씩 가산되어 최대 25일까지 늘어난다. 입사 첫해에 1년을 채우지 못한 직원은 매월...
overlap=100 | chunk_size=1500 | score=0.855
  title   : 휴가 및 연차 정책
  preview : 누구나테크의 연차 휴가는 입사 1년 차에 15일이 부여되며, 근속 2년마다 1일씩 가산되어 최대 25일까지 늘어난다. 입사 첫해에 1년을 채우지 못한 직원은 매월...

========================================================================
Q: 프로덕션 배포는 누가 최종 승인하나요?

  <chunk_overlap=0>
overlap=0   | chunk_size=200  | score=0.881
  title   : 배포 및 릴리스 프로세스
  preview : 프로덕션 배포는 QA 승인 이후 릴리스 담당자가 배포 태그를 생성하고, 마지막으로 엔지니어링 리드가 수동으로 승인하는 2단계 게이트를 거친다. 승인 기록과 변경 ...
overlap=0   | chunk_size=500  | score=0.859
  title   : 배포 및 릴리스 프로세스
  preview : 프로덕션 배포는 QA 승인 이후 릴리스 담당자가 배포 태그를 생성하고, 마지막으로 엔지니어링 리드가 수동으로 승인하는 2단계 게이트를 거친다. 승인 기록과 변경 ...
overlap=0   | chunk_size=1000 | score=0.822
  title   : 배포 및 릴리스 프로세스
  preview : 모든 코드는 기능 브랜치에서 작업한 뒤 Pull Request를 통해 main 브랜치로 병합한다. PR은 최소 1인 이상의 코드 리뷰 승인과 CI 파이프라인(빌드...
overlap=0   | chunk_size=1500 | score=0.822
  title   : 배포 및 릴리스 프로세스
  preview : 모든 코드는 기능 브랜치에서 작업한 뒤 Pull Request를 통해 main 브랜치로 병합한다. PR은 최소 1인 이상의 코드 리뷰 승인과 CI 파이프라인(빌드...

  <chunk_overlap=100>
overlap=100 | chunk_size=200  | score=0.881
  title   : 배포 및 릴리스 프로세스
  preview : 프로덕션 배포는 QA 승인 이후 릴리스 담당자가 배포 태그를 생성하고, 마지막으로 엔지니어링 리드가 수동으로 승인하는 2단계 게이트를 거친다. 승인 기록과 변경 ...
overlap=100 | chunk_size=500  | score=0.859
  title   : 배포 및 릴리스 프로세스
  preview : 프로덕션 배포는 QA 승인 이후 릴리스 담당자가 배포 태그를 생성하고, 마지막으로 엔지니어링 리드가 수동으로 승인하는 2단계 게이트를 거친다. 승인 기록과 변경 ...
overlap=100 | chunk_size=1000 | score=0.822
  title   : 배포 및 릴리스 프로세스
  preview : 모든 코드는 기능 브랜치에서 작업한 뒤 Pull Request를 통해 main 브랜치로 병합한다. PR은 최소 1인 이상의 코드 리뷰 승인과 CI 파이프라인(빌드...
overlap=100 | chunk_size=1500 | score=0.822
  title   : 배포 및 릴리스 프로세스
  preview : 모든 코드는 기능 브랜치에서 작업한 뒤 Pull Request를 통해 main 브랜치로 병합한다. PR은 최소 1인 이상의 코드 리뷰 승인과 CI 파이프라인(빌드...

========================================================================
Q: 장애 등급별 1차 대응 시간과 포스트모템 절차는?

  <chunk_overlap=0>
overlap=0   | chunk_size=200  | score=0.85
  title   : 장애 대응 및 온콜 운영
  preview : 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템은 비난 없는(blameless) 문...
overlap=0   | chunk_size=500  | score=0.845
  title   : 장애 대응 및 온콜 운영
  preview : 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템은 비난 없는(blameless) 문...
overlap=0   | chunk_size=1000 | score=0.844
  title   : 장애 대응 및 온콜 운영
  preview : 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템은 비난 없는(blameless) 문...
overlap=0   | chunk_size=1500 | score=0.84
  title   : 장애 대응 및 온콜 운영
  preview : 서비스 장애는 영향 범위에 따라 Sev1(전면 장애), Sev2(주요 기능 장애), Sev3(부분/경미)로 분류한다. Sev1은 전체 사용자가 핵심 기능을 쓸 수...

  <chunk_overlap=100>
overlap=100 | chunk_size=200  | score=0.85
  title   : 장애 대응 및 온콜 운영
  preview : 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템은 비난 없는(blameless) 문...
overlap=100 | chunk_size=500  | score=0.845
  title   : 장애 대응 및 온콜 운영
  preview : 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템은 비난 없는(blameless) 문...
overlap=100 | chunk_size=1000 | score=0.844
  title   : 장애 대응 및 온콜 운영
  preview : 장애가 종료되면 24시간 이내에 타임라인, 근본 원인, 영향 범위, 재발 방지책을 담은 포스트모템 문서를 작성한다. 포스트모템은 비난 없는(blameless) 문...
overlap=100 | chunk_size=1500 | score=0.84
  title   : 장애 대응 및 온콜 운영
  preview : 서비스 장애는 영향 범위에 따라 Sev1(전면 장애), Sev2(주요 기능 장애), Sev3(부분/경미)로 분류한다. Sev1은 전체 사용자가 핵심 기능을 쓸 수...

========================================================================
Q: 재택근무 시 지켜야 할 보안 요건은?

  <chunk_overlap=0>
overlap=0   | chunk_size=200  | score=0.884
  title   : 재택근무 및 유연근무 제도
  preview : 재택 시에는 회사가 지급한 노트북과 VPN을 사용해야 하며, 개인 기기에서 사내 시스템에 접속하는 것은 금지된다. 카페 등 공용 공간에서 근무할 경우 화면 보안 ...
overlap=0   | chunk_size=500  | score=0.887
  title   : 재택근무 및 유연근무 제도
  preview : 재택 시에는 회사가 지급한 노트북과 VPN을 사용해야 하며, 개인 기기에서 사내 시스템에 접속하는 것은 금지된다. 카페 등 공용 공간에서 근무할 경우 화면 보안 ...
overlap=0   | chunk_size=1000 | score=0.867
  title   : 재택근무 및 유연근무 제도
  preview : 재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주 근무 형태를 그룹웨어에 등록하고 팀...
overlap=0   | chunk_size=1500 | score=0.865
  title   : 재택근무 및 유연근무 제도
  preview : 재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주 근무 형태를 그룹웨어에 등록하고 팀...

  <chunk_overlap=100>
overlap=100 | chunk_size=200  | score=0.884
  title   : 재택근무 및 유연근무 제도
  preview : 재택 시에는 회사가 지급한 노트북과 VPN을 사용해야 하며, 개인 기기에서 사내 시스템에 접속하는 것은 금지된다. 카페 등 공용 공간에서 근무할 경우 화면 보안 ...
overlap=100 | chunk_size=500  | score=0.887
  title   : 재택근무 및 유연근무 제도
  preview : 재택 시에는 회사가 지급한 노트북과 VPN을 사용해야 하며, 개인 기기에서 사내 시스템에 접속하는 것은 금지된다. 카페 등 공용 공간에서 근무할 경우 화면 보안 ...
overlap=100 | chunk_size=1000 | score=0.867
  title   : 재택근무 및 유연근무 제도
  preview : 재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주 근무 형태를 그룹웨어에 등록하고 팀...
overlap=100 | chunk_size=1500 | score=0.865
  title   : 재택근무 및 유연근무 제도
  preview : 재택근무는 주 최대 3일까지 가능하며, 매주 금요일은 전사 권장 재택일로 운영된다. 재택근무를 하려면 전주 목요일까지 다음 주 근무 형태를 그룹웨어에 등록하고 팀...

========================================================================
Q: 비밀번호를 잊었을 때 재설정은 어떻게 하나요?

  <chunk_overlap=0>
overlap=0   | chunk_size=200  | score=0.872
  title   : 보안 및 계정 관리 규정
  preview : 비밀번호는 최소 12자 이상이어야 하고 90일마다 변경하며, 최근 5회 사용한 비밀번호는 재사용할 수 없다. 사내 포털 비밀번호를 잊은 경우 로그인 화면의 '비밀...
  keyword_hit: True
overlap=0   | chunk_size=500  | score=0.859
  title   : 보안 및 계정 관리 규정
  preview : 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로는 인증 앱(TOTP)과 하드웨어 보...
  keyword_hit: True
overlap=0   | chunk_size=1000 | score=0.841
  title   : 보안 및 계정 관리 규정
  preview : 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로는 인증 앱(TOTP)과 하드웨어 보...
  keyword_hit: True
overlap=0   | chunk_size=1500 | score=0.831
  title   : 보안 및 계정 관리 규정
  preview : 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로는 인증 앱(TOTP)과 하드웨어 보...
  keyword_hit: True

  <chunk_overlap=100>
overlap=100 | chunk_size=200  | score=0.872
  title   : 보안 및 계정 관리 규정
  preview : 비밀번호는 최소 12자 이상이어야 하고 90일마다 변경하며, 최근 5회 사용한 비밀번호는 재사용할 수 없다. 사내 포털 비밀번호를 잊은 경우 로그인 화면의 '비밀...
  keyword_hit: True
overlap=100 | chunk_size=500  | score=0.859
  title   : 보안 및 계정 관리 규정
  preview : 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로는 인증 앱(TOTP)과 하드웨어 보...
  keyword_hit: True
overlap=100 | chunk_size=1000 | score=0.841
  title   : 보안 및 계정 관리 규정
  preview : 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로는 인증 앱(TOTP)과 하드웨어 보...
  keyword_hit: True
overlap=100 | chunk_size=1500 | score=0.831
  title   : 보안 및 계정 관리 규정
  preview : 모든 사내 시스템 접근에는 SSO와 2단계 인증(MFA)이 적용되며, MFA 미설정 계정은 로그인이 차단된다. MFA 수단으로는 인증 앱(TOTP)과 하드웨어 보...
  keyword_hit: True

========================================================================
Q: 신규 입사자의 첫 주 온보딩에서는 무엇을 하나요?

  <chunk_overlap=0>
overlap=0   | chunk_size=200  | score=0.892
  title   : 신규 입사자 온보딩 가이드
  preview : 첫 주에는 온보딩 버디가 배정되어 개발 환경 설정, 코드베이스 구조, 배포 절차를 함께 익힌다. 버디는 같은 팀의 선임 개발자가 맡으며, 매일 15분 체크인을 갖...
  keyword_hit: True
overlap=0   | chunk_size=500  | score=0.89
  title   : 신규 입사자 온보딩 가이드
  preview : 입사 첫날에는 노트북 수령, 계정 발급, 보안 교육을 완료하고 사내 위키 접근 권한을 받는다. 인사팀이 복리후생·근태 시스템 사용법을 안내하고, IT팀이 개발 도...
  keyword_hit: True
overlap=0   | chunk_size=1000 | score=0.887
  title   : 신규 입사자 온보딩 가이드
  preview : 입사 첫날에는 노트북 수령, 계정 발급, 보안 교육을 완료하고 사내 위키 접근 권한을 받는다. 인사팀이 복리후생·근태 시스템 사용법을 안내하고, IT팀이 개발 도...
  keyword_hit: True
overlap=0   | chunk_size=1500 | score=0.887
  title   : 신규 입사자 온보딩 가이드
  preview : 입사 첫날에는 노트북 수령, 계정 발급, 보안 교육을 완료하고 사내 위키 접근 권한을 받는다. 인사팀이 복리후생·근태 시스템 사용법을 안내하고, IT팀이 개발 도...
  keyword_hit: True

  <chunk_overlap=100>
overlap=100 | chunk_size=200  | score=0.892
  title   : 신규 입사자 온보딩 가이드
  preview : 첫 주에는 온보딩 버디가 배정되어 개발 환경 설정, 코드베이스 구조, 배포 절차를 함께 익힌다. 버디는 같은 팀의 선임 개발자가 맡으며, 매일 15분 체크인을 갖...
  keyword_hit: True
overlap=100 | chunk_size=500  | score=0.89
  title   : 신규 입사자 온보딩 가이드
  preview : 입사 첫날에는 노트북 수령, 계정 발급, 보안 교육을 완료하고 사내 위키 접근 권한을 받는다. 인사팀이 복리후생·근태 시스템 사용법을 안내하고, IT팀이 개발 도...
  keyword_hit: True
overlap=100 | chunk_size=1000 | score=0.887
  title   : 신규 입사자 온보딩 가이드
  preview : 입사 첫날에는 노트북 수령, 계정 발급, 보안 교육을 완료하고 사내 위키 접근 권한을 받는다. 인사팀이 복리후생·근태 시스템 사용법을 안내하고, IT팀이 개발 도...
  keyword_hit: True
overlap=100 | chunk_size=1500 | score=0.887
  title   : 신규 입사자 온보딩 가이드
  preview : 입사 첫날에는 노트북 수령, 계정 발급, 보안 교육을 완료하고 사내 위키 접근 권한을 받는다. 인사팀이 복리후생·근태 시스템 사용법을 안내하고, IT팀이 개발 도...
  keyword_hit: True
 

미니 실습 결과 해설

  • 이번 실행에서는 chunk_overlap=0 과 chunk_overlap=100 사이에 상위 결과의 큰 차이는 거의 보이지 않았다. 이는 현재 코퍼스가 문단 구조가 비교적 분명하고, 질문이 청크 경계에 강하게 걸리지 않았기 때문이다.
  • 프로덕션 배포는 누가 최종 승인하나요? 같은 핀포인트 질문은 chunk_size=200 에서 가장 높은 점수와 가장 직접적인 문장을 보여 주었다. 즉, 특정 역할이나 규정 한 줄을 찾을 때는 작은 청크가 유리하다는 가설과 잘 맞는다.
  • 재택근무 시 지켜야 할 보안 요건은? 질문은 chunk_size=500 이 가장 자연스러운 균형을 보여 주었다. 너무 작은 청크보다 맥락이 조금 더 남고, 너무 큰 청크보다 불필요한 주변 설명이 적어 해석이 쉬웠다.
  • 연차 이월 규정과 경조사 휴가는 어떻게 되나요? 와 장애 등급별 1차 대응 시간과 포스트모템 절차는? 처럼 여러 정보를 함께 묻는 질문은 큰 청크가 문맥을 더 많이 담을 수 있지만, 실제 top-1 결과만 보면 질문의 일부만 먼저 잡히는 경우도 있었다. 이런 질문은 top-1 하나만 보지 말고 top-k 결과를 함께 읽는 것이 더 안전하다.
  • 추가 질문 2개에서는 모든 크기에서 keyword_hit=True 가 나왔다. 다만 점수와 미리보기를 함께 보면, 비밀번호 재설정 과 온보딩 첫 주처럼 답이 비교적 한 단락에 모여 있는 질문은 작은 청크가 더 선명한 근거를 주는 경향이 보였다.
  • 따라서 이 코퍼스 기준의 실무적 결론은 "항상 가장 큰 청크가 좋다"가 아니라, 200~500 범위가 핀포인트 질문에 강하고, 여러 정보를 묶는 질문은 500~1000 범위도 함께 검토할 가치가 있다는 것이다.
# 실습 정리용 셀: practice_overlap 네임스페이스 삭제
# 미니 실습에서 만든 비교용 네임스페이스만 정리합니다.
# 본 실험에서 사용한 chunk_200/500/1000/1500 네임스페이스는 그대로 유지합니다.

for overlap in [0, 100]:
    for size in [200, 500, 1000, 1500]:
        namespace = f"practice_overlap_{overlap}_chunk_{size}"

        try:
            index.delete(delete_all=True, namespace=namespace)
            print(f"삭제 완료: {namespace}")
        except Exception as error:
            if "Namespace not found" in str(error):
                print(f"건너뜀: {namespace} (이미 없거나 아직 생성되지 않음)")
            else:
                raise
 
삭제 완료: practice_overlap_0_chunk_200
삭제 완료: practice_overlap_0_chunk_500
삭제 완료: practice_overlap_0_chunk_1000
삭제 완료: practice_overlap_0_chunk_1500
삭제 완료: practice_overlap_100_chunk_200
삭제 완료: practice_overlap_100_chunk_500
삭제 완료: practice_overlap_100_chunk_1000
삭제 완료: practice_overlap_100_chunk_1500
 

정리

  • 청킹 → PineconeVectorStore 색인·검색의 표준 파이프라인을 완성했다.
  • 청크 크기/겹침이 품질을 좌우하며 정답은 도메인마다 다름을 실험으로 확인했다.
  • 다음(S4): 검색기를 에이전트의 도구로 쓰기 위한 LangGraph 핵심을 익힌다.

네임스페이스 삭제: 각 index.delete(delete_all=True, namespace=f"chunk_{size}")

저작자표시 비영리 변경금지 (새창열림)

'AI System > Agentic RAG: Agent 시스템을 위한 Vector RAG 설계' 카테고리의 다른 글

d01 - 6. AgenticRAG 실습  (0) 2026.06.15
d01 - 5. LangGraph  (0) 2026.06.15
d01 - 3. Pinecone  (0) 2026.06.15
d01 - 2. AgenticRAG  (0) 2026.06.15
d01 - 1. 개발환경 구축  (0) 2026.06.15

관련글

티스토리툴바