[Bastion-RAG 0] Get help from AI (아키텍처 설계)

여기서 부터가 코딩 시작이라 보는게 맞을거 같습니다. 사실 그래서 제일 마지막에 “아키텍처 설계”로 추가된 포스트인데요. LLM을 이용해 팀원을 몇명 더 만들어 작업하는 느낌이네요. 다만 제가 아는 만큼, 제가 제안하는 만큼 개발을 해주고 계획을 세워주네요. 저는 사실 AI에게 모든 일자리를 빼앗기고, 나중에 개발자가 할일이 없을거야… 라는 생각이였는데 아닌거 같습니다. 잘하는 개발자가 많이 살아 남고 나머지는 필터링 되는 새상이 될거 같네요. 다른 분야도 똑같이 발전 할거 같습니다. 개발자가 코딩을 잘해야 되는게 아니고, 도메인 지식도 알고 있어야되고 소프트웨어 공학도 이해 하고 있고, 개발 경험도 있으면 살아남을 수 있을거 같습니다. (너무 당연한 말일까요?)

URL Site > https://github.com/zafrem/bastion-rag

시리즈명 : Bastion-RAG – Project 보안 RAG

• [Bastion-RAG] Project 보안 RAG
• [Bastion-RAG 0] Get help from AI (아키텍처 설계) – Here!
• [Bastion-RAG 1 – Sentinel]
  • 프롬프트 인젝션 방어
  • 메타데이터 필터링
• [Bastion-RAG 2 – Vault]
  • 멀티 테넌시
  • 결정적 비식별화
• [Bastion-RAG 3 – Navigator]
  • 하이브리드 리랭킹
  • 논리적 파티셔닝
• [Bastion-RAG 4 – Archor]
  • 임베딩 노이즈 주입
  • 임베딩 모델 편향성 검증
• [Bastion-RAG 5 – Tracker]
  • 데이터 리니지 추적
  • Honey-token 주입
• [Bastion Demo]

1. 프롤로그: 무모한 낙관에서 시작된 세 번의 아키텍처 재설계

이론으로만 떠뜰던 프롬프트 인젝션 방어, 결정적 비식별화, 차등 노이즈 주입 등의 복잡한 AI 보안 거버넌스 기술을 실제 가동 가능한 시스템으로 구현하겠다는 목표로 [Bastion-RAG] Project – 보안 RAG 개발에 착수했습니다. 최근 성능이 비약적으로 상승한 AI 코딩 어시스턴트가 있으니, 설계와 구현은 생각보다 수월할 것이라 낙관했습니다.

“AI의 지원을 받으면 복잡한 엔터프라이즈 거버넌스 레이어도 금방 빌드할 수 있겠지?” 라는 생각이 였고 실제로 구현자체는 상상 할 수 없는 속도로 만들어지고 있습니다. 하지만 설계부분에서는 아직 생각해야 될게 많네요.

실시간 데이터 파이프라인의 런타임 성능 저하를 최소화하면서도, 엄격한 컴플라이언스(개인정보보호법 PIPA, GDPR 등)를 만족하는 아키텍처를 세우는 과정은 마법처럼 자동으로 이루어지지 않았습니다. 보안 통제 레이어가 무분별하게 추가될 때마다 시스템 지연 시간(Latency)은 기하급수적으로 늘어났고, 이를 해결하기 위해 AI 어시스턴트와 수많은 끝장 토론을 주고받으며 코어 구조를 세 번이나 완전히 갈아엎는 전면 재설계(Restructuring) 과정을 거쳐야 했습니다.

이 포스트는 단순한 기술 스펙 나열이 아닙니다. AI와의 질의응답 논쟁 속에서 파이프라인의 구조가 어떻게 진화했고, 마침내 실행 추가 오버헤드를 측정하면서, 보안 RAG 거버넌스 프레임워크를 어떻게 만들게 되었는지에 대한 생생한 엔지니어링 스토리입니다. (진짜 생생하긴하네요… 작업하면서 써보고 있어서…)

2. 진화 과정 분석: v1에서 v3까지, 구조의 극적인 변화

AI 어시스턴트와 주고받은 아키텍처 설계 프롬프트 기록을 바탕으로 파이프라인의 구조적 변화와 진화 단계를 복기해 보면, 기술적 충돌과 대안 도출, 리서치 부족(나의 이해 부족)의 연속이었습니다.

2.1 [Version 1.0] 기능별 파편화와 비대칭의 늪 (실패기)

• 구조적 특징: 입력 파이프라인 위주의 단방향 방어 아키텍처. 각 기능(Sentinel-IN, Vault-IN 등)이 개별 마이크로서비스 또는 독립 컨테이너 형태로 분리되어 존재했습니다. 허니토큰(Honey-Token) 기능 역시 Tracker 모듈 내부의 단일 기능으로 고립되어 기획되었습니다.
• AI와의 치열한 논쟁:
  • 나: “보안 모듈들의 결합도를 낮추고 싶어. Go 언어로 입력 게이트웨이를 짜고, 리랭킹이나 임베딩은 기존 Python 모델 서버를 마이크로서비스로 분리해서 HTTP로 호출하게 아키텍처를 가이드해줘.”
  • AI: “가장 정석적인 Microservice Architecture입니다. 완벽한 독립 배포 이점을 얻을 수 있습니다.”
• 무참한 현실과 붕괴
  • 실제 구현 후 테스트를 돌리자마자 절망했습니다. 하나의 검색 요청(Request)마다 외부 마이크로서비스를 지속적으로 호출하며 HTTP 네트워크 홉(Network Hop), JSON 직렬화/역직렬화 오버헤드가 누적되었습니다. p95 레이턴시가 300ms 이상 치솟으며 실시간 서비스가 불가능해졌습니다. 더 큰 문제는 비대칭성이었습니다. 입력 경로만 보호하다 보니, LLM이 응답(Output)을 생성할 때 원본 개인정보를 다시 노출하거나 환각 현상으로 비밀 데이터를 뱉어내는 ‘출력 보안 공백’을 생각하지 못했더라고요.

2.2 [Version 2.0] 대칭형 통합과 크로스컷팅(Cross-Cutting)의 발견 (과도기)

• 구조적 특징: 아키텍처의 전면 개편이 일어났습니다. 분리되어 있던 입력(Phase 1)과 출력(Phase 2) 모듈을 양방향 대칭 구조(Symmetric Bidirectional)로 묶어 단일 Go 언어 서비스 내부로 병합(Tight Coupling)했습니다. 또한, 허니토큰, 멀티 테넌시, 데이터 리니지를 단일 모듈의 짐이 아닌 ‘시스템 전반을 관통하는 크로스컷팅(Tier 3) 기능’으로 격상시켰습니다.
• AI와의 치열한 논쟁:
  • 나: “네트워크 홉 오버헤드를 잡으려고 단일 Go 프로세스로 합쳤는데, 이번엔 머신러닝 연산이 문제야. Go 생태계에 WEAT 분석이나 라플라시안 노이즈 분포 라이브러리가 없어서 매뉴얼로 수백 줄씩 코딩하느라 바퀴를 새로 발명하고 있어. 코드가 너무 복잡해!”
  • AI: “언어 독립성을 완전히 포기하는 것은 한계가 있습니다. 성능 격리를 유지하면서도 AI 라이브러리 생태계를 수용할 수 있는 하이브리드 인터페이스 계약을 다시 설계해야 합니다.”
• 과도기의 한계
  • 단일 언어(Go) 통합은 네트워크 지연은 줄였지만, 머신러닝 서빙 오버헤드와 CGO 바인딩의 복잡성으로 인해 유지보수 불가능 상태라는 또 다른 벽에 부딪혔습니다.

2.3 [Version 3.0] 고성능 폴리글랏(Polyglot) 와이어 계약의 완성 (현재)

• 구조적 특징: v2.0에서 정립된 대칭형 파이프라인과 완벽한 모듈 독립성(Standalone) 기조를 유지하면서, 핵심 언어를 이원화한 하이브리드 폴리글랏(Polyglot) 구조로 진화했습니다. 고속 패턴 매칭과 암호화는 Go가 담당하고, 임베딩 및 수치 연산은 Python이 처리합니다.
• AI와의 치열한 논쟁으로 찾아낸 돌파구:
  • 결정적 질문 (나): “Python의 풍부한 머신러닝 생태계를 쓰면서도, v1 때 겪었던 마이크로서비스 간 HTTP 네트워크 통신 지연을 물리적으로 없애는 방법은 진짜 없는 거야?”
  • AI의 솔루션 (v3의 핵심): “그렇다면 모델 서버를 외부에 두고 호출하는 고정관념을 깨십시오. Navigator(검색)와 Anchor(보안)를 Python 자립형 모듈로 재설계하고, 그 프로세스 내부 메모리에 sentence-transformers와 CrossEncoder 모델을 인프로세스(In-process) 방식으로 직접 서빙하십시오. 네트워크 오버헤드는 사라집니다. 그리고 두 언어 간 통신은 gRPC 인프라를 쓰되 와이어 레벨(Wire-level)에서는 가시성이 높은 JSON Codec 계약을 체결하여 유연성을 결합하십시오.”

3. [Bastion-RAG 0] 설계 무결성을 위한 가상 에뮬레이션 시뮬레이션

세 번의 아키텍처 설계를 거치며 뼈저리게 깨달은 교훈은 “코드를 단 한 줄이라도 치기 전에 설계의 컴플라이언스 무결성과 예외 처리 경로를 먼저 완벽하게 검증해야 한다”는 점이었습니다. 이 사상을 시스템화하여 프레임워크 전면에 배치한 것이 바로 [Bastion-RAG 0] 아키텍처 감사 레이어입니다.

[Bastion-RAG 0]은 엔터프라이즈 비즈니스 도메인의 보안 정책 사양이 입력되면, 실제 무거운 ML 모델을 로드하거나 코드를 구동하지 않고도 고성능 메시징 시스템인 NATS 이벤트 버스 토폴로지를 기반으로 가상의 클라이언트 요청을 진입시켜 보안 이벤트의 흐름을 미리 에뮬레이션합니다.

개발자가 기획한 파이프라인 설계 구조가 유입되면 [Bastion-RAG 0] 감사 엔진은 아래와 같은 가상 추적 로그(Virtual Ingestion Trace Log)를 실시간으로 빌드하여 완벽한 데이터 계보와 흐름 상의 병목을 진단합니다.

[Bastion-RAG 0: Virtual Emulator Ingestion Trace Log]

 - [emulator/Sentinel-IN]  INFO: Prompt input validated. Status: PASSED. Injection score: 0.05
 - [emulator/Vault-Phase1] INFO: Multi-strategy anonymization executed.
                                       - Input matching: "Hong Gildong" -> KR_NAME_8f3d2a (PERSON)
                                       - Input matching: "hong@naver.com" -> EMAIL_c3a91f (EMAIL)
 - [emulator/Navigator]    INFO: Executing structural pre-filtering isolation.
                                       - Injected filters: tenant_id=acme, collections=[customer_docs]
 - [emulator/Anchor-IN]    INFO: Differential noise injection executed. Sigma applied: 0.01
 - [emulator/Vault-Phase2] INFO: Evaluating selective detokenization via OPA policy rules.
 - [emulator/Sentinel-OUT] INFO: Grounding and hallucination checks completed. Status: PASSED.

4. 완벽한 격리를 위한 아키텍처 설계 기조와 제약 조건

AI 어시스턴트와의 끝장 토론을 통해 정립되어 01_architecture-principles.md 파운데이션 문서에 각인된 Bastion-RAG 프레임워크의 절대적인 설계 제약 조건은 다음과 같습니다.

1. 코어 기능의 철저한 독립성 (Standalone Value): 모든 모듈은 단독으로 LLM에 연결되어도 유의미한 보안 기능을 수행할 수 있는 자립형 구조를 가져야 합니다. 다른 모듈이 죽더라도 핵심 데이터 경로는 Graceful Degradation(우아한 성능 저하) 원칙에 따라 무너지지 않고 유지됩니다.
2. 직접적인 강한 의존성 금지 (Forbidden Coupling): 모듈 내부에서 타 모듈의 API를 직접 호출하거나 의존 관계를 생성하는 행위는 엄격히 금지됩니다. 예컨대 Navigator는 Vault 객체를 참조하지 않으며, 상위 오케스트레이터가 Vault에서 받아온 권한 데이터를 ‘요청 페이로드’에 포함하여 전달해 주는 데이터 플로우 계약만을 신뢰합니다.
3. 비침습적 옵저버 구조 (Non-Invasive Observer): 데이터 계보(Data Lineage)와 감사 로그를 추적하는 Tracker 모듈은 동기식 데이터 경로를 단 1밀리초도 블로킹하지 않습니다. 오직 NATS 비동기 이벤트 버스로 발행되는 화이어 앤 포겟(Fire-and-Forget) 형태의 JSON 스트림만을 관찰(CCTV 역할)하여 시스템 안정성을 보장합니다.

5. 결론: AI 어시스턴트는 맹신하는 도구가 아닌, 최고의 논쟁 파트너다

AI 코딩 어시스턴트는 처음에 엔터프라이즈 환경의 레이턴시 특수성을 고려하지 않은 채 정석적이지만 실무에는 맞지 않는 아키텍처(v1 마이크로서비스 아키텍처)를 제안하여 큰 시행착오를 겪게 만들었습니다. 하지만 런타임 지연 시간 임계치, 특정 언어 생태계의 한계 등 명확한 ‘기술적 제약 조건’을 던지며 AI를 끊임없이 압박하고 디버깅 논쟁을 이어가자, 결과적으로 혼자서는 도출하기 힘들었을 혁신적인 하이브리드 폴리글랏 토폴로지(v3)를 함께 구축해 낼 수 있었습니다.

결코 쉽게 구현되지는 않았습니다. 세 번의 뼈아픈 아키텍처 설계 과정이 있었지만, AI와의 밀도 높은 기술적 질의응답 덕분에 보안 거버넌스 추가 레이어로 인한 실행 오버헤드를 3ms 미만이라는 경이로운 수치로 격리하는 데 성공했습니다.

Bastion-RAG 프레임워크는 대규모 문서 자산의 보안과 LLM 데이터 제어를 동시에 확보하려는 최고정보보호책임자(CISO)와 AI 리드 아키텍트들에게 가장 현실적이고 완벽한 아키텍처 표준을 제시할 것입니다.

설계만 총 4주 정도 걸렸습니다. 한번은 와 이정도면 완성이지 싶어서 구현하다 롤백해서 2주를 보냈고요….

LLM의 토큰 한계나 너무 긴 문맥으로 인한 문제등… 나름 현재 LLM에 대한 문제 해결 노하우가 생기고 있는거 같네요.

예전에 잘동작하는 제품을 리팩토링한 적이 있습니다. 리팩토링하면서 코드 숫자를 1/5로 줄이고 테스트 케이스도 몇만개를 만들어 릴리즈를 올릴때 한달씩 걸리던 제품을 3시간만에 모든 테스트를 하도록 만들었었죠. 그 작업을 하고 나서 웬만한 어플리케이션에 대해서는 분석하고, 재설계하는 능력이 엄청 좋아졌습니다. 그때와 비슷하게 LLM 을 이용해 제품을 한번 만들어보면 요즘 세대의 개발자를 잘 이해하고, 저도 적응 할 수 있는 사람이 되겠죠?