Rust 검색 서버
Visual Summary 구현과 업무 관리

후속 슬랙 공유를 현재 상태의 기준으로 사용한다. 게이트웨이 dev 배포와 검색 서버의 실행 기반이 준비되었고 ECR 이미지도 받아지고 있다. 검색 API를 실제로 제공하려면 이석님이 표·차트를 포함한 Visual Summary 처리와 그에 맞는 데이터 로딩·검색을 구현해야 한다. 인프라 측의 “스냅샷만 로딩되면 뜬다”는 말은 실행 준비 상태에 관한 것이며 현재 기능 범위 전체가 완성됐다는 뜻은 아니다. 외부 요청 경로를 완성하는 CloudFront 연결과 PR #865 검토·머지는 별도로 남아 있다.

“인프라가 준비됨”은 “사용자 경로 전체가 이미 동작함”과 다르다. CloudFront 연결, API 경로 계약, 스냅샷 로딩·실제 검색 결과를 각각 확인한다. stg·prod 전체 검증 완료를 뜻하는 공유도 아니다.

새 방식은 “넣을 내용”과 “받아 줄 디자인”을 맞춘다

근거: Frame 문서 §2는 사용자 쪽 입력을 Visual Summary YAML의 structure, 디자인 쪽 입력을 IIS 경계 지도 또는 RLSC 규칙으로 설명한다. 같은 문서 §1·§8은 코어를 Rust의 frame-search API로 옮기는 계획을 기록한다. 현재 배포 완료를 뜻하는 설명은 아니다.

최신 진행 상황 · 제공된 Slack 스레드 ↗

아래는 관리 관점의 권장 작업 순서다. 이석님이 Visual Summary에 맞춘 제공 일정을 정하면, 이를 기준으로 정식 태스크를 등록한다. 기능의 적용 범위와 검증용 파일 준비는 함께 조율할 수 있다.

이 도식은 단계를 구분하기 위한 설명이다. 22일 완료 범위가 어디까지인지는 여기서 확정하지 않는다. S3에서 파일을 내려받는 “로딩”과 원본에서 정보를 만드는 “추출”도 서로 다른 작업이다.

9월 9일 작업 로그의 “22일 전에 체크 완료 목표”와 이번 “22일까지 추출 완료 희망”은 표현이 다르다. 동일한 완료 지점을 가리키는지 확인 전에는 하나의 확정 마감으로 합치지 않는다. 현재 주담당은 이석님이며 지우님이 이미 합류했거나 주담당을 대체한 것으로 표시하지 않는다.

협업 담당과 실제 남은 항목

도서관으로 비유하면 Rust는 도서 검색대, 기존 백엔드는 책과 상세 자료를 제공하는 시스템이다. 현재 Rust 작업은 Visual Summary를 기준으로 적합한 디자인 후보를 찾도록 구현하는 것이다. 실제 컴포넌트 자료 조회는 기존 백엔드에 남기는 인프라 합의가 있으며, 현재 Frame 방식의 반환 필드는 다시 확인해야 한다.

EKS는 여러 프로그램을 띄우고 관리하는 운영 공간이다. 그 안에서 실행되는 단위를 Pod라고 부른다. dev·stg·prd는 같은 구조를 사용하는 개발·검증·운영 환경이다.

실제 응답은 Rust → 게이트웨이 → FE로 돌아온다. 마지막 단계는 FE가 기존 백엔드에 보내는 별도의 자료 조회 요청이다. 외부에서 이 흐름으로 들어오는 CloudFront 경로는 아직 반영 대기다. 게이트웨이는 /component-search/api/**를 앞부분 제거 없이 전달하므로, Rust의 프리픽스 서빙(PR #865)과 같은 규칙을 써야 한다.

제안 · 논의중 컴포넌트 검색을 검증 → 검색 → 기록 세 번의 호출로 나누자는 제안이다. 가르는 줄이 하나 있다 — 사용자에게 보여 줄 것은 두 번째에서 끝나고, 세 번째는 그 뒤에 남는 뒷정리다. 아직 합의된 규약이 아니며 아래 「정해야 하는 것」이 남아 있다.

아래는 이 제안이 아직 답하지 않은 것들이다. 구현 전에 정해야 한다.

1. 1단계가 무엇을 검증하나. 권한인지, 사용량 한도인지, 입력 텍스트의 적격성인지. 상태값의 종류와 각 값에 대한 FE의 동작(재시도·안내·차단)이 함께 정해져야 한다.
2. 3단계가 실패하면 어떻게 하나. 사용자 응답은 이미 끝난 뒤다. 재시도할지, 유실을 허용할지, 큐에 넣을지에 따라 DA 데이터의 완전성이 달라진다.
3. VisualSummary를 통째로 보내나. 크기와 보관 기간, BE가 실제로 쓰는 필드 범위에 따라 3단계 payload가 정해진다.
4. 검색 UUID의 수명과 범위. 언제까지 유효한지, 재사용이 가능한지, 2단계 요청에도 실어 보내는지. IUI가 UUID를 알아야 한다면 결합이 한 겹 생기므로 이 결정이 설계의 기둥과 직접 맞닿는다.
5. 기존 흐름과의 접점. 03 · B 검색의 게이트웨이 경로와 FE의 활성 버전 전달이 어느 단계에 들어가는지, 검색 결과로 실제 자료를 조회하는 「FE → 기존 백엔드」 호출이 2단계와 3단계 중 어디에 붙는지.

출처: 사용자가 공유한 컴포넌트 검색 호출 순서(2026-09-16). 코드에서 확인하지 않았다 — 엔드포인트·필드명·상태값은 이 문서에 적힌 것이 전부이고, 구현된 것을 옮긴 것이 아니다. 단계 이름과 주고받는 값은 공유된 표기를 그대로 썼다.

S3는 AWS가 제공하는 파일 보관 서비스다. 사람에게 구글 드라이브가 있다면, 서버에게는 이런 파일 보관소가 있다고 생각하면 된다. 버킷(bucket)은 파일을 담는 보관함이다. 이번 작업은 환경별 S3 버킷 3개를 만들어 두었다.

“DB 없이 S3를 DB처럼 쓴다”는 의미

기존 인프라 방향은 검색용 데이터를 S3 파일로 관리하고 Rust가 메모리에 올려 검색하는 것이다. 현재 데이터는 Visual Summary/Frame 규격에 맞아야 한다. 초기 메모의 comp-sign 시그니처 17만 건과 메모리 예상치를 I.I.S Semantic Component 의 규모·사용량으로 적용하지 않는다 — 단위가 컴포넌트가 아니라 경계 노드라 건수부터 다시 세야 한다. 별도 DB를 두지 않는 결정은 Rust 검색 서버의 데이터 관리 방식에 관한 것이며, 기존 백엔드의 DB까지 없앤다는 뜻은 아니다. ADMIN 기능은 보류되었다.

도서관의 옛 목록에 적힌 책 위치와 현재 책장 위치가 다르면 책을 못 찾는다. 여기서도 Rust가 예전 데이터로 찾은 컴포넌트 키를 백엔드가 새 데이터 기준으로 조회하면 실패할 수 있다. 특히 서버를 한 대씩 교체하는 롤링 배포 중에는 구·신 서버가 함께 떠 있으므로 버전 관리가 중요하다.

증분 처리는 전체 파일 중 바뀐 부분만 반영하는 것

전체 데이터를 매번 다시 읽는 대신 추가·변경분을 S3에서 주기적으로 확인해 반영하는 계획이다. 이 자료에서는 갱신 중 요청 대기열 처리를 잠시 멈추는 방향을 논의했다. Mordor에서 변경분 파일과 목록을 만드는 파이프라인이 먼저 필요하다. 석님 로더 구현만으로 완료되는 작업은 아니다.

아래는 관리용으로 제안하는 완료 기준이다. “빌드 성공”과 “S3 파일 업로드”만으로 기능 배포 완료를 표시하지 않고, 실제 사용 경로가 어느 단계까지 동작하는지 확인한다.

운영 준비에서 확인할 세 가지

Rust

이번 독립 검색 서버를 만든 프로그래밍 언어. 여기서는 별도 서버의 구현 기술 이름으로 이해하면 된다.

I.I.S Semantic Component

Rust 서버에 올라가는 데이터. I.I.S.(증분 정보 구조화기)가 디자인 컴포넌트 안의 경계 노드마다 「이 묶음이 어떤 의미 단위인가」를 뽑아 둔 것이다. 컴포넌트 자체는 BE 로 가고 이 정보만 Rust 로 간다. 이 문서가 종전에 “시그니처”라고 부르던 자리다.

Visual Summary · Frame · 과거 comp-sign 시그니처

Visual Summary는 내용의 구조화 규격, Frame은 그 내용을 디자인과 비교하는 형식이다. comp-sign 시그니처는 이전 방식의 용어이며, 이번 구현과도 위 I.I.S Semantic Component 와도 같은 말이 아니다.

컴포넌트 키

디자인 컴포넌트를 식별하는 번호다. 과거 시그니처 검색을 쓰지 않아도 컴포넌트 식별자는 필요할 수 있다. 현재 응답 필드는 API 계약에서 정한다.

FE · 백엔드

FE는 사용자가 보는 브라우저 화면과 요청을 다루는 쪽. 백엔드는 서버에서 데이터와 기능을 제공하는 쪽이다.

API · 벌크 조회

API는 프로그램끼리 요청·응답하는 약속. 벌크 조회는 여러 컴포넌트 자료를 묶어서 한 번에 요청하는 것이다.

S3 · 버킷

AWS의 파일 보관 서비스와 그 안의 보관함. 이번에는 검색 데이터 파일과 버전 안내 JSON을 저장한다.

추출 · 파일 내보내기 · 로딩

현재 추출은 Visual Summary 관련 입력에서 필요한 구조·대응 정보를 준비하는 작업으로 범위를 확인해야 한다. 파일 내보내기는 데이터를 저장하는 단계, 로딩은 그 데이터를 프로그램으로 읽는 단계다. 서로를 동일한 완료 기준으로 쓰지 않는다.

JSON · 스냅샷

JSON은 프로그램이 읽기 쉽게 데이터를 적는 형식. 스냅샷은 특정 시점·버전의 전체 데이터 사본이다.

인메모리 · 로더

인메모리는 데이터를 RAM에 올려 사용하는 방식. 로더는 파일을 가져와 읽고 쓸 수 있는 상태로 준비하는 기능이다.

GitHub Actions · 빌드

Actions는 검사와 배포 준비를 자동 실행하는 도구. 빌드는 코드를 실행 가능한 결과물로 만드는 과정이다.

컨테이너 이미지 · ECR

이미지는 프로그램과 실행 환경을 묶은 꾸러미. ECR은 그 꾸러미를 보관하는 저장소다. 여기서 이미지는 사진을 뜻하지 않는다.

EKS · Pod

EKS는 Kubernetes 기반의 운영 공간. Pod는 그 안에서 프로그램이 실행되는 단위다. 물리 서버 한 대와 반드시 같지는 않다.

ArgoCD · Helm · sync

ArgoCD와 Helm은 배포와 설정 반영에 사용하는 도구. sync는 정해 둔 배포 상태를 실제 환경에 맞춰 반영하는 작업이다.

CloudFront · ALB · Service · SG

이번 흐름에서 CloudFront는 외부 요청이 들어오는 경로, ALB는 요청을 받을 대상으로 전달하는 로드 밸런서, Service는 Pod에 접근하는 고정된 입구, SG는 허용할 네트워크 통신을 정하는 규칙이다.

프리픽스 · StripPrefix · SEARCH_TOKEN

프리픽스는 URL 앞부분이다. StripPrefix는 그 앞부분을 떼는 처리인데, 이번 게이트웨이는 떼지 않고 보낸다. PR #865는 Rust가 그 경로를 받도록 맞추고 서버 전용 SEARCH_TOKEN 검사를 제거하는 내용이며, 게이트웨이 인증은 별도로 유지된다.

환경 변수

프로그램 시작 시 밖에서 주는 설정값. 파일 경로·접속 주소·포트 등을 코드 수정 없이 알려 주는 데 쓴다.

게이트웨이

사용자 요청을 받아 인증·요청량 제한을 확인하고 내부 서비스로 보내는 입구. 이번 Rust 서버의 앞에 놓인다.

IRSA · IAM

AWS 접근 권한과 관련된 용어. 이 그림에서는 Pod가 자신의 역할로 S3 파일을 읽도록 권한을 연결한다는 의미다.

활성 버전 · 가용 버전

활성은 현재 사용하도록 선택된 버전. 가용은 사용할 수 있는 버전 목록이다. 두 개념을 구분해야 한다.

lazy 로딩 · LRU · polling

필요해졌을 때 읽기, 오래 사용하지 않은 것부터 내보내기, 일정 간격으로 새 상태를 확인하기를 뜻한다.

롤링 배포 · 롤백

서버를 한 번에 모두 바꾸지 않고 차례로 교체하는 것, 문제가 생겼을 때 이전 상태로 되돌리는 것이다.

dev · stg · prod/prd

개발 환경, 운영 전 검증 환경, 실제 사용자가 이용하는 운영 환경이다.

queue · RPS · scale out

처리 전 요청의 대기줄, 초당 요청 수, 부하를 나눠 처리하도록 서버 실행 개수를 늘리는 것이다.

Datadog · OpenSearch · k6

이 업무에서 각각 운영 지표 관측, 로그 적재·검색, 요청 부하 테스트를 위해 준비하는 도구다.