[Feature] 클라우드 최적화 참조 아키텍처 및 MSA 전환 가이드 추가 제안

[SEOUL-raphael]

해결하려는 문제 (Problem)

현재 표준프레임워크 실행환경 소개 문서는 화면처리, 업무처리, 데이터처리, 연계통합, 배치처리, 공통기반 중심의 전통적인 레이어드 아키텍처를 잘 설명하고 있습니다.

다만 최근 공공 정보시스템은 클라우드 전환, 컨테이너 배포, Kubernetes 운영, MSA, 이벤트 기반 연계, 관찰가능성 적용 등으로 운영 환경과 아키텍처 선택지가 넓어지고 있습니다. 이 관점에서 보면 현재 문서에는 다음과 같은 공백이 있습니다.

1. 기존 레이어드 아키텍처, Spring Boot API 구조, MSA 구조, 이벤트 기반 구조 중 어떤 방식을 선택해야 하는지 한눈에 안내하는 상위 문서가 부족합니다.
2. egovframe-msa-common-components, egovframe-operating-environment-msa, egovframe-ex-cloud-data-stream 등 관련 저장소와 예제가 존재하지만, 표준프레임워크 공식 아키텍처 선택지로 연결되는 설명이 약합니다.
3. 기존 시스템을 클라우드 환경으로 전환할 때 “현행 구조 유지”, “API 분리”, “모듈러 모놀리스”, “서비스 분리”, “이벤트 기반 연계”, “Kubernetes/Service Mesh 운영” 중 어떤 순서와 기준으로 접근할지에 대한 전환 경로 문서가 부족합니다.

따라서 문제는 클라우드/MSA 관련 기능이 전혀 없다는 점이 아니라, 이미 존재하는 실행환경·템플릿·샘플·운영환경 문서를 연결해 주는 “아키텍처 선택 기준과 전환 경로” 문서가 부족하다는 점입니다.

제안 내용 (Proposed Solution)

egovframe-runtime 또는 개발환경 문서 하위에 “클라우드 최적화 참조 아키텍처” 문서를 추가하는 것을 제안합니다. 이 문서는 기존 레이어드 아키텍처를 대체하는 것이 아니라, 표준프레임워크 기반 시스템이 클라우드 전환 환경에서 선택할 수 있는 아키텍처 옵션을 병행 제시하는 역할을 합니다.

문서에는 다음 네 가지 선택지를 함께 정리하면 좋겠습니다.

1. 기존 레이어드 아키텍처

   • 단일 업무 시스템, 내부망, 전통적 WAS/DB 중심 시스템에 적합
   • 표준프레임워크 실행환경의 화면처리, 업무처리, 데이터처리, 연계통합, 배치, 공통기반 구조를 그대로 활용

2. Spring Boot API 아키텍처

   • 프론트엔드 분리, REST API, 모바일/SPA/Flutter 연계, 컨테이너 배포에 적합
   • 기존 MVC/JSP 중심 구조에서 API 중심 구조로 단계적으로 전환하는 선택지

3. MSA 아키텍처

   • Gateway, Config Server, Service Discovery, 서비스별 독립 배포, 서비스별 권한/DB/스케일링이 필요한 경우에 적합
   • egovframe-msa-common-components와 MSA Template Wizard를 참조할 수 있음

4. 이벤트 기반/스트림 아키텍처

   • Kafka/RabbitMQ, Spring Cloud Stream, OpenSearch, MongoDB 등을 활용한 비동기 연계와 실시간 처리에 적합
   • egovframe-ex-cloud-data-stream 예제와 연결 가능

또한 기존 시스템의 전환 경로를 다음과 같은 단계 모델로 설명하면 실무자가 판단하기 쉬울 것 같습니다.

레이어드 구조 유지
→ Spring Boot/API 분리
→ 모듈러 모놀리스 정리
→ 서비스 단위 분리
→ 이벤트 기반 연계 도입
→ Kubernetes/Service Mesh 운영

문서에는 클라우드 네이티브 기본 원칙도 표준프레임워크 관점에서 함께 정리하면 좋겠습니다.

• 외부화 설정: Spring Profile, Config Server, 환경변수 기반 설정
• Stateless 서비스: 세션/파일/캐시를 외부 저장소로 분리
• Health/Readiness/Liveness: Actuator 기반 상태 확인
• Graceful Shutdown: 배포/스케일링 시 안전한 종료
• Structured Logging: JSON 로그, traceId/spanId, 서비스명 포함
• Secrets/Config 분리: DB 비밀번호, 토큰 키, 인증서 등 비밀정보 관리
• Observability: OpenTelemetry, Prometheus, Loki, Jaeger, Grafana, Kiali 연계
• Autoscaling 고려: 서비스별 부하 특성과 수평 확장 기준 정리

대안 (Alternatives)

1. 기존 MSA 관련 저장소의 README만 보강하는 방법

   • 장점: 변경 범위가 작습니다.
   • 한계: 실행환경/개발환경 문서를 보는 사용자가 클라우드 아키텍처 선택지를 발견하기 어렵습니다.

2. 운영환경 MSA 문서에만 내용을 추가하는 방법

   • 장점: Kubernetes, Istio, OpenTelemetry 내용과 가깝습니다.
   • 한계: 개발자가 애플리케이션 구조를 어떻게 설계해야 하는지에 대한 상위 가이드로는 부족할 수 있습니다.

3. 바로 샘플 코드를 추가하는 방법

   • 장점: 실행 가능한 예제를 빠르게 보여줄 수 있습니다.
   • 한계: 어떤 아키텍처를 언제 선택해야 하는지에 대한 합의 없이 코드부터 추가하면 유지보수 범위가 커질 수 있습니다.

따라서 우선은 문서 이슈로 방향을 논의하고, 합의 후 문서 PR 또는 샘플 개선 PR로 나누어 진행하는 방식을 제안합니다.

관련 영역 (Affected Area)

• 개발환경 (egovframe-development/)
• 실행환경 (egovframe-runtime/)
• 공통컴포넌트 (common-component/)
• 기타 (README, 설정 파일 등)

참고 자료 (References)

• 실행환경 기본 구조: https://github.com/eGovFramework/egovframe-runtime
• 실행환경 소개 문서: https://github.com/eGovFramework/egovframe-docs/blob/main/egovframe-runtime/intro/overview.md
• MSA Template Wizard: https://github.com/eGovFramework/egovframe-docs/blob/main/egovframe-development/implementation-tool/ide-msa-template-wizard.md
• MSA 공통컴포넌트: https://github.com/eGovFramework/egovframe-msa-common-components
• MSA 운영환경: https://github.com/eGovFramework/egovframe-operating-environment-msa
• Cloud Data Stream 예제: https://github.com/eGovFramework/egovframe-ex-cloud-data-stream

관련 논의:

• REST API 표준화 제안: [발전 방안 제안(Improvement Plan)]: 전자정부프레임워크 표준 REST API 규격 수립 #592
• Observability 표준화 제안: [제안] 애플리케이션 로그-트레이스 상관관계(traceId/spanId) 표준화 및 단일 앱 레퍼런스 egovframe-operating-environment-msa#7
• Boot Starter 방향 제안: [제안] 실행환경 in-app Boot 스타터 도입 방향 (관측/AI 횡단관심사·RTE 코어 자동구성) egovframe-runtime#248

기대효과

1. 표준프레임워크 사용자가 기존 레이어드 구조와 클라우드 최적화 구조를 상황에 맞게 선택할 수 있습니다.
2. 기존 시스템을 MSA로 무리하게 전환하지 않고, 단계적 전환 전략을 세울 수 있습니다.
3. 이미 존재하는 MSA 공통컴포넌트, Cloud Data Stream, 운영환경 MSA 문서가 공식 아키텍처 흐름 안에서 연결됩니다.
4. 공공기관 클라우드 전환 사업에서 표준프레임워크의 적용 범위와 현대적 활용 가능성을 더 명확히 설명할 수 있습니다.
5. 향후 REST API 표준화, Observability 표준화, Boot Starter 논의와도 자연스럽게 연결될 수 있습니다.

[SEOUL-raphael]

추가 참고 사례: 공공부문 클라우드 네이티브·플랫폼 접근

본 제안은 표준프레임워크 기존 레이어드 아키텍처를 대체하자는 취지가 아니라, 공공부문에서 이미 확산되고 있는 “공통 플랫폼 + 클라우드 네이티브 + DevSecOps/관찰가능성” 흐름을 표준프레임워크 문서에도 선택지로 연결하자는 제안입니다. 아래 사례들을 참고하면 문서화 방향을 더 구체화할 수 있을 것 같습니다.

1. 미국 cloud.gov: 정부용 PaaS와 12-Factor 앱 기준

미국 GSA의 cloud.gov는 정부 기관이 인프라를 직접 관리하지 않고도 보안·컴플라이언스 요건을 갖춘 애플리케이션을 배포할 수 있도록 제공되는 정부용 PaaS입니다. 문서에서는 Cloud Foundry 기반 조직/공간 모델을 통한 격리와 리소스 관리를 설명하고, 애플리케이션은 12-Factor App 원칙을 따르는 것이 적합하다고 안내합니다. 또한 애플리케이션 로그와 메트릭을 중앙 로그/메트릭 서비스로 자동 수집하는 구조도 제시합니다.

표준프레임워크 관점의 시사점:

• Spring Boot API 아키텍처 문서에 12-Factor, 환경변수 기반 설정, stateless 설계, 표준 로그 출력 원칙을 포함할 수 있습니다.
• 운영환경 문서에는 중앙 로그/메트릭, 서비스별 공간/권한 분리, 관리형 서비스 연계 방식을 참고 사례로 연결할 수 있습니다.

참고:

• https://cloud.gov/
• https://docs.cloud.gov/platform/deployment/
• https://docs.cloud.gov/platform/logs/

2. 싱가포르 GovTech/GCC: Government Commercial Cloud와 GitOps/Kubernetes 운영

싱가포르 GovTech는 Government Commercial Cloud(GCC), Singapore Government Tech Stack(SGTS), Container Stack 등을 통해 정부 프로젝트에서 Docker, Kubernetes, GitOps, CI/CD, Infrastructure-as-Code, cloud native 솔루션 적용을 추진해 왔습니다. 개발자 포털 자료에서는 GitOps를 정부 프로젝트 배포 방식으로 소개하고, GCC 2.0과 CloudSCAPE를 통해 클라우드 보안·컴플라이언스 자동화도 함께 다룹니다.

표준프레임워크 관점의 시사점:

• MSA/Kubernetes 문서는 단순 배포 YAML 예제를 넘어 GitOps, CI/CD, IaC, 보안 기준 점검을 함께 다룰 필요가 있습니다.
• 공공기관 클라우드 전환 문서에는 “개발 플랫폼”, “보안·컴플라이언스 자동화”, “기관 공통 운영 기준”을 별도 축으로 정리할 수 있습니다.

참고:

• https://www.developer.tech.gov.sg/communities/events/stack-meetups/automate-deployments-in-government-the-gitops-way/overview.html
• https://www.developer.tech.gov.sg/products/categories/cybersecurity/cloudscape/overview
• https://www.developer.tech.gov.sg/communities/events/conferences/stack-2022-developer-conference/agenda/lightning-talks.html

3. 영국 DWP Digital: 공통 클라우드 네이티브 플랫폼과 Platform as a Product

영국 DWP Digital은 공통 클라우드 네이티브 플랫폼을 통해 서비스 팀이 각자 플랫폼을 반복 구축하지 않고, 표준화된 호스팅·도구·자동화를 재사용하도록 하는 접근을 소개했습니다. 특히 “플랫폼을 한 번 만들고 여러 기능 팀이 재사용한다”는 방식과 “Platform as a Product” 관점을 강조합니다.

표준프레임워크 관점의 시사점:

• 표준프레임워크 문서에서 MSA를 단순히 서비스를 쪼개는 방식으로 설명하기보다, 공통 플랫폼과 운영 표준을 함께 제공하는 방식으로 설명할 필요가 있습니다.
• 개발팀의 인지 부하를 줄이기 위해 Gateway, Config, Observability, CI/CD, 보안 정책을 공통 플랫폼 레이어로 묶어 설명할 수 있습니다.

참고:

• https://dwpdigital.blog.gov.uk/2022/04/01/podcast-accelerating-digital-services-using-a-cloud-native-common-platform/

4. 미국 DoD Platform One: DevSecOps, 서비스 메시, 지속적 보안 인가

미국 국방부의 Platform One은 보안이 중요한 공공·국방 영역에서 DevSecOps 플랫폼, hardened container, service mesh/API gateway, 관찰가능성, 지속적 인가(cATO) 같은 개념을 하나의 참조 구조로 다룹니다. Platform One의 Big Bang은 오픈소스 기반 DevSecOps 플랫폼으로 소개되며, DSOP 자료는 마이크로서비스 아키텍처와 Istio 기반 서비스 메시, 보안·가시성, CI/CD 자동화의 중요성을 설명합니다.

표준프레임워크 관점의 시사점:

• 공공 시스템의 MSA 문서는 “서비스 분리”보다 보안 내재화, 표준 컨테이너 이미지, 공급망 보안, 관찰가능성, 배포 자동화까지 포함해야 합니다.
• egovframe-operating-environment-msa의 Istio/OpenTelemetry 가이드는 이러한 공공 DevSecOps 참조 구조와 연결해 설명할 수 있습니다.

참고:

• https://p1.dso.mil/
• https://p1.dso.mil/big-bang
• https://software.af.mil/dsop/
• https://software.af.mil/dsop/architecture/

문서화 제안 보강 방향

위 사례들을 반영하면 “클라우드 최적화 참조 아키텍처” 문서는 다음과 같이 구성할 수 있을 것 같습니다.

1. 아키텍처 선택 표

   • 레이어드, Boot API, MSA, 이벤트 기반, Kubernetes/Service Mesh 운영을 선택 기준별로 비교

2. 전환 로드맵

   • 기존 시스템 유지 → API 분리 → 모듈러 모놀리스 → 서비스 분리 → 이벤트 기반 연계 → 공통 플랫폼 운영

3. 공통 플랫폼 레이어

   • Gateway, Config, Discovery, Observability, CI/CD, GitOps, Secrets, 표준 로그, 보안 정책을 플랫폼 기능으로 정리

4. 공공 운영 체크리스트

   • 보안·컴플라이언스, 감사 로그, traceId/spanId, 중앙 로그, 배포 이력, 장애 추적, 공급망 보안, 관리형 서비스 연계

5. 표준프레임워크 기존 자산과의 연결

   • egovframe-runtime: 레이어드 실행환경과 reactive/WebFlux/R2DBC 기능
   • egovframe-msa-common-components: Gateway/Config/Eureka 기반 MSA 공통컴포넌트
   • egovframe-operating-environment-msa: Kubernetes/Istio/OpenTelemetry 운영환경
   • egovframe-ex-cloud-data-stream: Spring Cloud Stream 기반 이벤트/스트림 예제

이 방향이면 특정 클라우드 사업자나 특정 제품을 표준으로 강제하지 않으면서도, 공공부문 클라우드 전환에서 이미 검증된 패턴을 표준프레임워크 문서 안으로 연결할 수 있을 것 같습니다.

[SEOUL-raphael]

#604의 큰 제안 중에서, 우선 egovframe-docs 안에서 관련 문서 발견성을 높이는 최소 범위의 draft PR을 열었습니다.

• PR: docs: add cloud native reference architecture guide #616
• 범위: 실행환경 소개 하위에 “클라우드 최적화 참조 아키텍처” 문서 추가, 기존 관련 문서 링크 연결
• 취지: 기존 레이어드 아키텍처를 대체하거나 MSA/Kubernetes를 강제하는 것이 아니라, 상황별 선택지를 쉽게 찾을 수 있도록 안내하는 문서 보강