Software Architecture · Draft v0.1

Bring-Up Bridge

RTOS 공용 센서허브 프레임워크 챗봇 시스템의 데이터 입수부터 질의 서빙까지의 소프트웨어 아키텍처입니다. 사내 정보와 칩사 공개 정보를 물리적으로 분리해 저장하고, 응답을 생성하는 LLM은 호출 주체에 따라 교체할 수 있도록 설계했습니다.

대상: 센서허브 프레임워크 챗봇 범위: 입수 파이프라인 · 서빙 아키텍처 작성일: 2026-08-31
← 테스트 하네스로 돌아가기

핵심 설계 결정

지금까지 논의를 통해 확정된 일곱 가지 결정입니다. 아래 파이프라인은 이 결정들을 그대로 구현한 것입니다.

범위

Internal DB(전체) / External DB(칩사 공통) 2단 구조. 칩사별 추가 분리는 두지 않는다.

저장

파일 기반 임베디드 벡터 저장소를 쓴다. 서버 프로세스 없이, 내부/외부 데이터를 물리적으로 다른 위치에 둔다.

모델

임베딩 모델은 고정하고, 답변을 생성하는 LLM만 게이트웨이를 통해 자유롭게 교체한다.

분류

분류는 저장 이전에 끝낸다. 조회 시점에 태그로 걸러내는 방식은 쓰지 않는다.

규칙

메신저·이메일은 규칙 기반으로 즉시 내부 전용 처리한다. 그 외 소스만 사람 검수를 거쳐 승격한다.

입수

자동 크롤링과 수동 업로드는 분류·검수 파이프라인을 동일하게 공유한다.

생성

데이터시트 등록은 여느 문서와 동일하게 처리한다. 드라이버 코드 생성은 배포된 챗봇의 실시간 기능으로, 요청 시 인터페이스 검사·시뮬레이터로 검증한 뒤 답변에 포함한다.

01

입수 및 저장 파이프라인

문서가 들어와서 분류되고, 벡터화되어 저장소에 안착하기까지의 쓰기(write) 경로입니다.

데이터 입수 (자동 크롤링 + 수동 업로드) Wiki · 메신저 · 게시판 · 데이터시트 · 이메일 · 수동입력 텍스트 추출 소스 판별 메신저 · 이메일 (규칙) 그 외 소스 (AI 1차 분류) internal_only 확정 검수 없이 즉시 저장 검수 큐 (사람 승인) 애매한 문서 최종 판단 승인 반려 → 내부로 external_approved 확정 칩사 공개 후보 벡터화 (임베딩 모델, 고정) 분류 완료된 문서 전체 전체 문서 external_approved만 Internal 파일 저장소 전체 문서 (메신저 포함) External 파일 저장소 칩사 공통 공개, 검수 승인분만
그림 1. 메신저·이메일은 규칙으로 즉시 내부 전용 처리되고, 나머지 소스만 사람 검수를 통과해야 External 저장소로 승격됩니다. 승격되지 않은 모든 문서는 Internal 저장소에만 남습니다.
02

질의 처리 및 서빙 아키텍처

사용자의 질문이 들어와서 답변으로 나가기까지의 읽기(read) 경로입니다. 호출 주체에 따라 조회 가능한 저장소와 최종 응답 LLM이 갈립니다.

사내 사용자 (엔지니어) 칩사 파트너 내부 게이트웨이 사내 API 키 검증 External 게이트웨이 칩사 전용 키 검증 접근 불가 · 경로 없음 질의 임베딩 + 검색 질의 임베딩 + 검색 Internal 파일 저장소 전체 문서 (메신저 포함) External 파일 저장소 칩사 공통 공개분 검색된 청크 → 프롬프트 구성 LLM 게이트웨이 공통 인터페이스 · 백엔드 교체 가능 사내 요청 칩사 요청 사내 LLM (고정) 삼성 사내 모델 칩사 지정 LLM 교체 가능 (플러그인) 코드 검증 도구 (선택적 호출) 인터페이스 검사 + 시뮬레이터 · 코드 생성 요청일 때만 사용자에게 답변 반환
그림 2. 칩사 쪽 요청은 게이트웨이 단계에서부터 External 저장소로만 라우팅되며, Internal 저장소로 가는 경로 자체가 존재하지 않습니다. 드라이버 코드 생성 요청일 때는 응답 직전에 "코드 검증 도구"를 거치지만, 일반 질의는 이 단계를 건너뜁니다.

접근 권한 요약

구분 조회 가능 저장소 응답 생성 LLM 포함 데이터 소스
내부 정보봇 / 브링업봇 Internal 전체 사내 LLM (고정) Wiki · 메신저 · 게시판 · 데이터시트 · 이메일 전체
칩사 브링업봇 External(공통)만 칩사 지정 LLM (교체 가능) 검수 승인된 문서만 (메신저 제외)