안녕하세요, Aero-Csharp입니다.
최근 몇 년간 IT 업계의 가장 큰 화두는 단연 ‘클라우드 네이티브(Cloud Native)’와 ‘마이그레이션(Migration)’일 것입니다. 많은 기업들이 온프레미스(On-Premise) 시스템을 걷어내고 AWS나 Azure로 인프라를 이전하고 있죠.
하지만 수백 개의 비즈니스 애플리케이션이 복잡하게 얽혀 있는 엔터프라이즈 환경, 특히 단 1초의 다운타임도 허용되지 않는 유럽 대형 항공사의 시스템에서도 과연 "내일부터 전부 클라우드로 올인(All-in)합니다!"가 가능할까요?
결론부터 말씀드리면 "원천적으로 불가능"합니다.
저는 최근 수년간 유럽 최대 항공사 중 하나인 항공그룹사에서 파일럿과 승무원을 위한 코어 시스템 개발 및 아키텍처 전환을 담당해 왔습니다. 수많은 시행착오 끝에 우리가 선택한 생존 전략은 다름 아닌 ‘하이브리드 클라우드(Hybrid Cloud)’ 과도기 모델이었습니다.
단순히 "기술이 부족해서"가 아닙니다. 철저히 보안, 비용, 그리고 레거시 인프라의 안정성을 고려한 고도의 의사결정이었습니다.
오늘 첫 포스팅에서는 수백 개의 앱을 운영하던 우리가 왜 과도기적 하이브리드 토폴로지를 선택할 수밖에 없었는지, 그리고 그 중심에서 보안과 무중단을 책임진 Gateway Web Service 설계 이야기를 풀어보려 합니다.
- 족쇄가 된 데이터베이스, 그리고 Azure의 무시무시한 비용 현실
마이그레이션 프로젝트 초기, Frontend(Angular, TypeScript)와 Backend Web Service(C#, .NET)는 상대적으로 가볍기 때문에 클라우드화(Cloud-to-Azure)를 빠르게 추진할 수 있었습니다.
진짜 문제는 데이터베이스(SQL Server, Oracle)였습니다.
마이그레이션의 시차: 데이터 규모가 수십 테라바이트에 달하고 가용성 제약이 촘촘한 항공사 DB를 웹 애플리케이션과 동시에 클라우드로 옮기는 것은 리스크가 너무 컸습니다. 웹을 먼저 옮기든 DB를 먼저 옮기든 '시차'가 발생할 수밖에 없었죠.
Azure DB 비용 폭탄: 인프라 매니저나 CTO라면 격하게 공감하시겠지만, Azure 상에서 대규모 엔터프라이즈급 DB 가용성(High Availability)을 보장받기 위한 비용은 상상을 초월합니다. 경제적이고 안정적인 클라우드 DB 아키텍처를 최종 확정하기 전까지, 데이터를 담은 코어 DB 서버는 온프레미스에 둔 채 단계적으로 이주하는 전략이 필수적이었습니다.
결국 "Frontend와 Backend는 Azure Cloud에, DB 서버는 여전히 On-Premise에" 존재하는 물리적 분리 상태, 즉 하이브리드 과도기가 시작되었습니다.
- 보안 부서가 기절할 소리: "클라우드에서 내망 DB로 직접 연결하겠다고?"
웹은 클라우드에 있고, DB는 사내 온프레미스 전산실에 있습니다. 그렇다면 클라우드의 Backend에서 온프레미스 DB 서버로 직접 Connection String을 맺으면 되지 않을까요?
항공사 보안 팀(Security Team)이 들으면 기절할 소리입니다.
엔터프라이즈 보안 컴플라이언스상, 외부 클라우드 환경의 서비스가 사내망 깊숙이 숨겨진 SQL Server(1433 포트)나 Oracle(1521 포트)로 직접 방화벽을 뚫고 들어오는 것은 절대로 허용되지 않습니다.
이 심각한 보안 교착상태를 해결하기 위해 제가 설계한 구원투수가 바로 'Gateway Web Service' 아키텍처였습니다.
[ Azure Cloud 환경 ] Frontend (Angular) ---> Backend (.NET) ──(보안 HTTPS 터널)
──> Gateway Web Service ──> 코어 DB Server (SQL/Oracle)
(기존 데이터 파이프라인 유지) 기존 On-Prem 레거시 백엔드 (무중단 가동)
클라우드 Backend가 DB에 직접 붙는 구조를 과감히 버리고, 온프레미스 내부망 안에 일종의 '대리인'인 Gateway 웹 애플리케이션을 하나 더 만든 것입니다.
클라우드 백엔드는 오직 이 Gateway API만 호출할 수 있고, 실제 DB 쿼리는 내부망의 Gateway가 대신 수행하여 데이터만 안전하게 전달(Fetch)해 주는 방식입니다.
- 현장 아키텍트가 체감한 Gateway 구조의 4가지 실전 이점
이 Gateway App 도입은 단순히 보안 부서의 승인을 받기 위한 임시방편이 아니었습니다. 운영을 거듭할수록 다음과 같은 강력한 비즈니스적 장점들이 증명되었습니다.
① 공격 표면(Attack Surface)의 최소화와 보안 통제
온프레미스 방화벽은 외부를 향해 무겁고 취약한 DB 포트를 열 필요가 없습니다. 오직 사내망에 위치한 Gateway App의 표준 HTTPS 포트(443) 통신만 허용하면 됩니다. DB 서버의 실제 IP와 포트가 클라우드 환경에 전혀 노출되지 않으므로 보안 리스크가 획기적으로 줄어듭니다.
② 기존 온프레미스 시스템의 'Zero 무중단' 보장 (가장 중요)
클라우드 이주 프로젝트 중에도 수백 개의 기존 온프레미스 레거시 백엔드 시스템은 여전히 촘촘하게 엮여서 비즈니스를 수행하고 있습니다. Gateway App은 기존 인프라에 어떤 영향도 주지 않고, 오직 클라우드로 먼저 이주한 신규 시스템이 요청하는 데이터만 독립적으로 서빙합니다. 덕분에 기존 시스템은 단 1초의 가동 중단이나 소스 수정 없이 100% 정상 가동을 유지할 수 있었습니다.
③ 촘촘한 방화벽 해제(Firewall Unlock)의 최소화
클라우드의 Backend 시스템들은 트래픽에 따라 오토스케일링(Scale-out)되며 IP가 유동적으로 변하는 컨테이너(Container App) 환경이었습니다. 인프라 팀에 이 수많은 유동 IP를 일일이 DB 방화벽에 등록해 달라고 요구하는 것은 불가능에 가깝습니다. 하지만 Gateway를 두면서 "클라우드 특정 컨테이너 구간 ── 온프레미스 Gateway" 사이의 단일 통신 채널만 정밀하게 방화벽을 Unlock하면 끝났습니다. 인프라 부서와의 소통 비용이 극적으로 절감된 순간이었습니다.
④ 미래 마이그레이션을 위한 '추상화 레이어' 확보
상위 클라우드 애플리케이션들은 DB가 현재 온프레미스에 있는지, 향후 Azure Cosmos DB나 Azure SQL로 가는지 알 필요가 없습니다. 오직 Gateway API만 바라봅니다. 훗날 데이터베이스를 클라우드로 최종 이주할 때, 상위 웹 애플리케이션 소스코드는 단 한 줄도 고치지 않고 오직 Gateway 내부 로직만 스위칭하면 되므로 완벽한 마이그레이션 유연성을 얻게 되었습니다.
💡 20년 차 아키텍트의 인사이트: "Lift & Shift의 환상을 깨라"
많은 매니저와 결정권자들이 클라우드 이주를 단순한 '서버 이사(Lift & Shift)'로 가볍게 생각하곤 합니다. 하지만 엔터프라이즈 환경에서의 이주는 훨씬 더 입체적이고 정치적(?)이며, 인프라의 한계와 타협해야 하는 예술에 가깝습니다.
우리가 구형 Windows Service 하나를 클라우드 네이티브 환경에 맞춰 3개의 Container App Job으로 쪼개고 Microservice 원칙에 따라 아키텍처를 재설계하는 과정에서도 이 Gateway는 든든한 버팀목이 되어 주었습니다.
하이브리드는 부끄러운 기술적 타협이 아니라, 거대한 레거시가 안전하게 살아남기 위한 가장 정교한 아키텍트의 생존 기술입니다.
다음 포스팅에서는 이 하이브리드 구조 위에서 "클라우드의 컨테이너 백엔드 앱과 온프레미스의 Gateway 웹 서비스 간의 통신 보안을 OAuth 2.0(M2M standard)으로 어떻게 구현했는지" 구체적인 C# .NET 실전 팁과 함께 다뤄보겠습니다.
혹시 현재 대규모 마이그레이션 과정에서 인프라 및 보안 부서와의 조율이나 비용 문제로 밤잠을 설치고 계신 아키텍트나 매니저분이 계시다면 언제든 댓글이나 비즈니스 문의로 의견을 공유해 주세요. 함께 고민해 드리겠습니다.
- 유럽 하늘 아래에서, Aero-Csharp 드림.![]
