오늘의 구조가 내일의 자격이 된다

지난 세 편에 걸쳐 flex 백엔드 아키텍처의 인과 사슬을 따라왔습니다.

1화에서는 Gradle Convention Plugin이 Hexagonal Modular Monolith를 컴파일 타임에 강제하는 이야기를 했습니다. 아키텍처를 문서가 아니라 빌드가 지키는 구조.
2화에서는 이 일관성 덕분에 Transactional Outbox를 라이브러리 수준에서 제공할 수 있었고, 모든 도메인이 같은 방식으로 신뢰성 있는 이벤트를 발행하게 되었습니다.
3화에서는 이 이벤트 레일 위에 ReBAC 기반 통합 인가를 올려서, HR의 복잡한 권한 문제를 관계 모델로 풀었습니다.

각각은 그 시점의 문제를 풀기 위한 결정이었습니다. 하지만 돌아보면, 이 결정들이 서로 맞물리면서 우리가 예상하지 못했던 다음 문제를 풀 수 있는 기반이 되었습니다.

전체 인과 사슬 한눈에 보기

멀티클라우드 — 모듈 경계가 만든 유연성

flex는 지금 공공시장(B2G) 진출을 앞두고 있습니다. 공공 서비스를 제공하려면 CSAP(Cloud Security Assurance Program) 인증이 필요한데, AWS만으로는 중등급 이상을 통과할 수 없습니다. 국내 클라우드 환경에서도 서비스를 운영해야 한다는 뜻입니다.

"기존 서비스를 다른 클라우드에서도 돌려야 한다"는 요구사항은, 아키텍처에 따라 난이도가 완전히 달라집니다. 만약 애플리케이션 코드가 특정 클라우드의 SDK나 서비스에 직접 의존하고 있다면, 클라우드를 바꾸는 건 사실상 서비스를 다시 만드는 것에 가깝습니다.

flex의 Hexagonal Architecture에서는 이 상황이 다릅니다. 도메인 로직은 Port를 통해 외부와 통신하고, 실제 인프라와의 연결은 Adapter가 담당합니다. AWS의 특정 서비스에 의존하는 부분은 Adapter 안에 격리되어 있습니다. 다른 클라우드로 이전할 때, 도메인 로직을 건드리지 않고 해당 Adapter만 교체하면 됩니다.

물론 현실은 이론만큼 깔끔하지는 않습니다. 클라우드 간 서비스 스펙의 차이, 네트워크 구성, 데이터 마이그레이션 등 풀어야 할 문제가 많습니다. 하지만 최소한 "도메인 로직까지 다 뜯어고쳐야 하는 상황"은 아키텍처 수준에서 방지되어 있습니다. 1화에서 이야기한 모듈 경계와 의존성 방향의 강제가, 2년 뒤의 멀티클라우드 전환에서 구조적 안전망이 되어주는 셈입니다.

AI Backend — 인프라를 새로 만들 필요가 없다

flex의 AI 플랫폼은 멀티클라우드 LLM 통합, A2A(Agent-to-Agent) 프로토콜, MCP 서버, RAG 파이프라인 등 다양한 기술을 다루고 있습니다. AWS Bedrock, Azure OpenAI, GCP Vertex 등 여러 클라우드의 LLM을 통합하고, AI 에이전트가 Notion, Slack, GitHub 같은 외부 서비스와 상호 작용하며, 사내 HR 데이터를 기반으로 맥락을 이해하는 시스템입니다.

이 AI 플랫폼을 만들 때, 가장 중요한 전제 중 하나는 "AI도 권한을 지켜야 한다"는 것입니다. AI 에이전트가 구성원의 인사 데이터에 접근할 때, 그 접근이 요청자의 권한 범위 안에 있는 지를 확인해야 합니다. AI라고 해서 모든 데이터를 자유롭게 볼 수 있는 건 아닙니다.

여기서 3화의 ReBAC 인가 시스템이 그대로 활용됩니다. AI 에이전트의 요청도 결국 "이 사용자가 이 자원에 접근할 수 있는가?"라는 질문으로 귀결되고, 이 질문은 이미 구축된 OpenFGA 기반 인가 파이프라인이 답합니다.

이벤트 인프라도 마찬가지입니다. AI 에이전트의 작업 결과를 다른 시스템에 전파하거나, HR 데이터 변경을 AI 시스템에 반영할 때, 2화에서 구축한 Outbox + CDC + Kafka 파이프라인을 그대로 사용합니다. AI 백엔드를 위해 별도의 메시징 인프라를 새로 만들 필요가 없었습니다. 이미 신뢰성이 검증된 인프라 위에 새로운 컨슈머를 붙이면 됩니다.

Observability — 벤더를 3번 바꾸고 남은 것

1화에서 "아키텍처를 문서가 아니라 빌드가 지킨다"고 했습니다. 관측(Observability) 영역에서 flex가 얻은 교훈도 비슷한 구조를 가지고 있습니다 — "관측을 벤더가 아니라 표준이 지킨다."

flex의 Observability 스택은 지난 몇 년간 세 번의 큰 전환을 거쳤습니다. APM 트레이싱은 Splunk O11y에서 OpenTelemetry Collector + Grafana Tempo로, 메트릭은 Prometheus에서 VictoriaMetrics로, 로깅은 ELK(Filebeat + Logstash + Elasticsearch)에서 FluentBit + Kafka + Fluentd + OpenSearch로. 세 번 모두 벤더 혹은 구현체가 바뀌었지만, 그때마다 처음부터 다시 시작하지는 않았습니다.

이게 가능했던 이유는 전환 과정에서 일관되게 표준 인터페이스에 투자했기 때문입니다. 트레이싱은 OpenTelemetry 프로토콜(OTLP) 위에 올렸고, 메트릭은 PromQL 호환성을 유지했습니다. 애플리케이션 코드에 Splunk 전용 SDK나 Datadog 전용 에이전트를 심는 대신, 표준 계측(instrumentation)만 심어두면 수집 백엔드를 교체할 때 애플리케이션 코드를 건드릴 필요가 없습니다. 실제로 Splunk에서 Tempo로의 전환은 Dual-write 기간을 거쳐 애플리케이션 변경 없이 완료되었고, Prometheus에서 VictoriaMetrics로의 전환에서는 prod 메모리 사용량이 39GB에서 13GB로 줄었지만 Grafana 대시보드는 그대로 살아남았습니다.

이 설계 철학은 새로운 영역에서도 반복됩니다. AI 플랫폼의 LLM Observability에서는 Langfuse를 Self-hosted로 도입해 토큰 사용량, 프롬프트 품질, 비용을 추적하고 있습니다. SaaS 평가 도구(Braintrust)가 있었지만 고객 데이터의 국외 이전 리스크 때문에 프로덕션 환경에서는 활용이 어려웠습니다. Self-hosted Langfuse는 국내 클라우드에 배포하여 고객 데이터를 100% 국내에 보관하면서도 실시간 품질 모니터링과 비용 분석이 가능합니다. 멀티클라우드에서의 벤더 독립과 같은 동기가, 관측 영역에서도 작동하고 있는 셈입니다.

Observability 파이프라인 자체도 진화 중입니다. 현재 Trace/Log 에이전트를 OpenTelemetry Collector로 일원화하고, Kafka를 버퍼로 두어 다양한 백엔드(Tempo, OpenSearch, VictoriaMetrics, Langfuse)로 데이터를 라우팅하는 통합 파이프라인을 구축하고 있습니다. 새로운 관측 요구(LLM 사용량, 클러스터 이벤트 자동 분석 등)가 생겨도, 파이프라인에 컨슈머를 붙이는 것만으로 확장할 수 있는 구조입니다.

1화에서 만든 일관성이 빌드 규율로 작동하듯, 표준에 투자한 관측 인프라는 벤더가 바뀌어도 조직의 관측 능력 자체는 유지되게 해줍니다. "오늘 선택한 도구"가 아니라 "오늘 투자한 표준"이 내일의 자산이 됩니다.

오늘의 투자, 내일의 출발점

멀티클라우드에서는 Adapter 교체로 서비스를 재배치할 수 있었습니다. AI Backend에서는 이벤트 인프라와 인가 시스템을 새로 만들 필요가 없었습니다. Observability에서는 표준에 투자했기 때문에 벤더를 3번 바꿔도 처음부터 다시 시작하지 않았습니다.

이 모든 것의 출발점은 1화에서 이야기한 구조의 일관성입니다. 하지만 이 원칙이 애플리케이션 코드에서만 작동하는 건 아닙니다.

다음 화에서는,
1화에서 깎아낸 경계가 인프라 코드, 배포 파이프라인, 그리고 개발자의 디버깅 도구까지 관통하는 이야기를 해보겠습니다.