클라우드 이전에 온프레미스가 있었다

우리는 애플리케이션의 배포에 클라우드, IDC를 사용했다. 클라우드는 익숙한 편이었다. 구체적인 비용 표는 몰라도, 어떤 때에 어떤 기준으로 비용이 청구된다는 얘기들은 알고 있다. 취업 준비할 때도 포트폴리오로 낼 프로젝트 띄운다고 여러 서비스를 썼었다. EC2, RDS, ELB 비용 신경쓰기 싫다며 썼던 Lightsail, 정적 배포를 해야하니 S3, CloudFront, 도메인 사려고 썼던 Route53, 친구랑 같이한다고 뒀던 IAM까지. 특히 프론트엔드 애플리케이션은, SPA를 정적 배포하면서 CDN 캐시 무력화의 필요성과 다중 리전 대응 개념도 자연스레 획득했었다.

올 해 나는 사내 생산성 개선 서비스의 리드를 맡았고, 가설 수립과 개념 검증부터 설계, 구현까지 팀원들과 맞춰내었다. 미래는 모르지만, 적어도 올해는 사내망에서만 존재할 서비스였고, 자연스럽게 비용으로 생각이 이어지면서 ‘프론트엔드 애플리케이션에서 SSR이 굳이 필요한가’라는 의문에 닿았다. 클라이언트-서버 면을 넘나들며 인증이니 하이드레이션이니 불필요한 레이어를 하나 더 만드는 것은 아닌가? IP 화이트리스팅 처리를 하고, SPA로 만드는 게 더 낫지 않을까? 굳이 불필요한 서버를 두는 건 공격 면적을 하나 더 만드는 게 아닌가?

팀 내 고연차 인프라 엔지니어 분과, 백엔드, 프론트엔드 엔지니어분들께 의견을 구했다. 프론트엔드, 백엔드 엔지니어 분들은 어느 정도 이해를 하신 모양이었지만, 인프라 엔지니어는 왜 SPA를 생각했냐고 되물으셨다. 생각해보니 그렇다. 사내망 전용 백오피스 제품이니, 서버 애플리케이션은 IDC로 갔을 것이다. 이 상태에서 SPA를 S3 + CF에 올리게 되면 서버 애플리케이션의 외부로의 로드 밸런싱 설정은 물론이고, 결국 IDC 망에 외부로의 접근을 허용하게 되지 않나?

그렇다면 공격 면적은 넓어진다. 서비스가 아니라 자원 단위까지. egress도 필요하다. IDC에 SSR로 구성하는 Node 서버를 둔다면? 내부망 통신으로 해결되며 불필요한 내외부 네트워크 통신 오버헤드도 적다. 열릴 뻔한 공격 면적도 봉쇄된다. 게다가 IDC 장비는 이미 사용하고 있고, 대여료도 내고 있지 않은가? AWS 정적 배포 구성이 저렴하다지만, 이쪽은 이미 매몰되고 있는 비용이고, 감가상각 비용을 회수하는 데도 훨씬 탁월하다. 처음에는 이걸 염두하고 SSR을 구상해 개발한 건 아니었다. 다만 서버 측 엔드포인트를 지우고, BFF로도 활용할 여지가 크며, 공개적으로 밝힐 순 없으나 긴 로드맵에서 관여하는 바가 있기에 의도한 SSR이었는데.

일부 공고에 기술되어 있는 ‘온프레미스 환경에서의 경험’은 이런 걸 의미하는 거였을까. 몇 년간의 경험은 꽤나 밀도있다고 느껴왔었다. 그런데 소프트웨어니 하드웨어니 하는 기술만 논하고 있고, 자원 관리를 넓게 생각 못했다는 게 스스로 좀 부끄럽기도 하고, IT 서비스를 빌딩하고 운영하는 데에 있어 새로이 눈이 떠졌다는 느낌을 받는다.

번외지만 CI/CD 마이그레이션도 진행했었다. 기존의 Jenkins + Docker Hub + AWS 구성에서, GitHub Actions + Nexus + ArgoCD + Helm으로. 배포는 무사히 했지만 이 부분도 조금 더 배워볼 필요가 있겠다.