연결의 설계 — Claude를 사내 시스템·데이터와 잇는 아키텍처 판단

3.1 통합 메커니즘 선택 — MCP · 직접 API/CLI · 에이전트 간 연결

같은 기능이라도 어떻게 잇느냐에 따라 재사용성과 운영 부담이 갈립니다. MCP(Model Context Protocol, 모델에 도구·데이터를 표준 규격으로 노출하는 개방 프로토콜)는 여러 팀·여러 에이전트가 같은 연결부를 공유할 때 값어치가 큽니다. 반대로 정해진 한 곳과만 붙는 고정 연동이라면 직접 API나 CLI 호출이 군더더기가 적습니다. 하위 작업을 전문 에이전트에게 넘기는 에이전트 간 위임은 조율 유연성을 주지만 지연과 실패 지점이 늘어납니다. 판단 축은 결합도·재사용·통제(governance)입니다.

3.2 RAG 파이프라인 설계 — 청킹과 인덱싱 전략

RAG(Retrieval-Augmented Generation, 검색으로 찾은 근거를 답변 생성에 함께 넣는 방식)의 품질은 검색 전 단계에서 이미 절반이 정해집니다. 청킹(chunking, 문서를 검색 단위로 쪼개는 일)이 너무 잘면 맥락이 끊기고, 너무 크면 관련 없는 내용이 섞여 컨텍스트 윈도우(context window, 모델이 한 번에 참고하는 정보의 범위)를 낭비합니다. 문서의 결에 맞춰 조항·문단·대화 턴 등 의미 경계로 나누고, 필터링에 쓸 속성 정보를 함께 붙여 벡터 저장소(vector store)에 인덱싱(indexing, 검색을 빠르게 하려고 미리 정리해 두는 일)해 둡니다.

3.3 데이터 형태와 질의 패턴에 맞춘 검색 전략

검색 방식은 데이터의 생김새와 사용자가 묻는 방식에 맞춰 골라야 합니다. 의미 기반 검색(dense retrieval, 문장의 뜻을 벡터로 비교하는 방법)은 개념을 풀어 묻는 탐색형 질의(query)에 강하고, 키워드 검색(BM25 같은 sparse 방식, 단어 일치를 세는 방법)은 코드·품번·법조문처럼 정확한 일치가 중요한 조회에 강합니다. 둘을 섞은 하이브리드에 재순위(reranking, 1차 결과를 다시 정렬해 상위 정확도를 높이는 단계)를 얹는 구성이 많습니다. 정형 데이터라면 속성 필터나 질의 변환(text-to-SQL)이 더 맞습니다.

3.4 기능 과적재와 점진적 발견 — 도구·에이전트 구성 평가

도구를 많이 붙일수록 똑똑해질 것 같지만 실제로는 반대입니다. 도구가 늘면 모델이 어느 것을 쓸지 고르는 정확도가 떨어지고, 정의를 모두 실어 나르느라 컨텍스트와 비용·지연이 함께 불어납니다(기능 과적재, capability bloat). 각 도구가 제 값을 하는지 따져 덜어내는 것이 설계입니다. 모든 능력을 처음부터 다 여는 단일 컨텍스트 대신, 상황에 맞는 묶음만 그때그때 드러내는 점진적 발견(progressive discovery)이 선택 정확도를 지키고 컨텍스트를 아낍니다.

3.5 인증·인가 공백 분석 — 통합 지점이 곧 공격면

시스템을 이을 때마다 공격받을 수 있는 면이 함께 넓어집니다. 인증(authentication, 누구인지 확인)과 인가(authorization, 무엇을 해도 되는지 허가)는 다른 문제이며, 공백은 대개 인가 쪽에서 생깁니다. 에이전트에 조회용을 넘어 이체까지 되는 넓은 권한을 쥐여 주거나, 사용자별 권한을 좁히지 않아 A의 요청이 B의 데이터에 닿는 대리인 혼동(confused deputy)이 대표적입니다. 최소 권한, 사용자 권한을 그대로 넘기는 위임 토큰, 고위험 행위의 담당자 확인 단계로 막습니다.

3.6 정확도-지연 트레이드오프와 대규모 관측성

더 큰 모델, 더 많은 검색, 재순위, 여러 단계 추론은 정확도를 올리지만 응답 시간과 비용을 함께 끌어올립니다. 어느 쪽에 무게를 둘지는 그 업무의 응답 기준(SLA)이 정합니다. 쉬운 요청은 작은 모델로 처리하고 어려운 것만 큰 모델로 넘기는 라우팅, 반복되는 앞부분을 재사용하는 프롬프트 캐싱이 흔한 절충입니다. 규모가 커지면 요청 하나가 거친 도구 호출들을 이어 보는 추적(distributed tracing), 요청별 토큰·비용, 검색 품질을 실제 사용 흐름 위에서 살펴 이상 징후를 잡는 관측성(observability)이 필수가 됩니다.

! 흔한 함정

• MCP가 항상 정답은 아닙니다 — 재사용·공유가 없는 일회성 연동에 MCP 서버를 세우면 오히려 운영 부담만 늘어납니다. 연결 방식은 결합도와 재사용으로 고릅니다.
• 청킹 크기를 하나의 정답으로 고정하려는 시도 — 문서 종류마다 의미 경계가 다르므로, 자료 전체에 같은 크기를 밀어붙이면 검색 품질이 무너집니다.
• 인증만 챙기고 인가를 놓치는 것 — 로그인은 막았으니 안전하다고 여기지만, 실제 사고는 권한 범위를 좁히지 않은 인가 공백에서 납니다.
• 정확도를 위해 무조건 큰 모델·많은 검색을 쌓는 것 — 응답 기준을 넘긴 지연은 그 자체로 실패입니다. 트레이드오프는 업무 SLA에 비춰 정당화해야 합니다.