Milestone 3 - 클라우드 네이티브로의 진화

Milestone 3 - 클라우드 네이티브로의 진화

개발팀장 이성호의 사무실에는 화이트보드가 가득 찼다. 새롭게 설계된 아키텍처 다이어그램이 그려져 있었고, 그 옆에는 할 일 목록이 빼곡히 적혀 있었다.

"자, 이제 시작이야." 이성호가 TF 팀원들을 바라보며 말했다. "우리의 목표는 CloudFormation을 이용한 IaC 구현을 통해 새로운 고객을 위해 온보딩 과정에서 필요한 자원 배포를 자동화하고 이걸 관리할 Control Plane을 개발하는거야."

팀원 중 한 명이 손을 들었다. "팀장님, CloudFormation으로 EC2 하나를 만드는건 어렵지 않았지만 다양한 AWS 서비스를 다루는 건 너무 어려워요"

이성호는 미소 지었다. "걱정 마. 우리 모두 함께 배울 거야." 김범준 Solutions Architect는 TF팀을 위한 CloudFormation 세션을 열고 CloudFormation 학습을 도왔다.

세CloudFormation 학습 세션이 끝난 후 사무실로 돌아온 이성호는 피로한 표정으로 의자에 앉았습니다. TF팀 안에서도 새로운 기술에 대한 의견 충돌이 일어나고 있었다.

"팀장님, CloudFormation이 정말 필요한가요? 그냥 AWS 콘솔로 수동 배포하는 게 더 빠르지 않을까요? 지금 우리에게 당장 필요한 건 고객들에게 서비스를 제공하는 거잖아요."

다른 개발자가 반박했습니다. "그런 식으로 하면 나중에 고객이 늘어났을 때 관리가 불가능해질 거야. 지금 제대로 자동화 시스템을 구축해 놓는 게 중요해."

"하지만 CloudFormation 학습 곡선이 생각보다 가파르잖아. 우리가 이걸 언제 다 익히고 구현한다는 거야? 영업팀은 이미 새 고객들에게 약속을 하고 있다고."

한숨을 내쉰 이성호가 말했습니다. "나도 이해해. 하지만 우리가 진정한 SaaS 기업으로 거듭나려면 이런 과정은 필수야."

이때 박진석 수석 개발자가 문을 열고 들어왔습니다.

"여전히 생각이 바뀌지 않았어요." 그가 단호하게 말했습니다. "이렇게 새로운 기술을 자꾸 도입할수록 우리 코드베이스는 복잡해지고, 안정성은 떨어질 겁니다. TF팀에서 이걸 감당할 수 있을지도 의문이고요."

이성호는 침착하게 대답했습니다. "진석 씨, 당신의 우려는 이해합니다. 하지만 우리가 살아남기 위해서는 변화해야 해요. TF팀만이 아니라 당신의 경험과 지식도 필요합니다. 함께 해주시면 어떨까요?"

박진석은 잠시 생각하더니 대답했습니다. "제가 보기에는 지금의 계획만으로는 부족합니다. 특히 보안 측면에서요. 제대로 하려면 IAM 역할 설정, 보안 그룹 구성, 네트워크 아키텍처를 더 신중하게 설계해야 합니다."

이성호의 눈이 반짝였습니다. "정확히 우리가 필요로 하는 전문성입니다. TF팀에 합류해서 이 부분을 맡아주시겠어요?"

박진석은 한참을 망설이다 마지못해 고개를 끄덕였습니다. "단 한 가지 조건이 있습니다. 제가 인프라 보안 아키텍처를 설계하고 검토할 권한을 갖고 싶습니다."

"물론입니다." 이성호가 미소 지었습니다.

이후 며칠 동안, TF팀 내에서는 지속적인 토론과 때로는 격렬한 논쟁이 이어졌습니다. CloudFormation 템플릿의 복잡성, 리소스 간 의존성 관리의 어려움, 그리고 배포 실패 시 디버깅 방법 등이 주요 쟁점이었습니다.

"이건 생각보다 훨씬 복잡해요." 한 개발자가 밤 늦게까지 코드를 들여다보며 한숨을 쉬었습니다. "그냥 EC2 인스턴스 하나 생성하는 것도 이렇게 복잡한데, 전체 환경을 자동화하는 건 정말 가능할까요?"

박진석이 옆에 앉아 도움을 주었습니다. "처음에는 모두 그렇게 느끼는 법이야. 하나씩 해결해나가자."

점차 팀이 CloudFormation에 익숙해지면서, 작은 성공들이 쌓이기 시작했고, 처음으로 자동화된 VPC 생성에 성공했을 때, 팀 전체가 환호성을 질렀다.

그러나 기뻐하는것도 잠시, 다른 쟁점이 수면 위로 올라왔다. Control Plane 개발과 관련된 내용이었다.

"이런 관리 시스템은 지금 당장 필요한 게 아니에요." 한 개발자가 주장했습니다. "고객들에게 서비스부터 제공하고, 나중에 만들어도 되지 않을까요?"

이성호는 단호하게 대답했습니다. "그건 마치 기초 없이 집을 짓는 것과 같아. Control Plane은 우리가 진정한 SaaS가 되기 위한 핵심이야. 지금 제대로 만들어 놓지 않으면, 나중에 더 큰 비용을 치르게 될 거야."

며칠 후, 팀은 새로운 시스템의 첫 테스트를 진행했다.

"자, 시작해볼까?" 이성호가 키보드 앞에 앉았다.

Enter 키를 누르자, CloudFormation Stack이 생성되기 시작했다. 팀원들은 숨을 죽이고 화면을 지켜보았다. 몇 분 후, Stack 생성이 완료되었다는 메시지가 떴다.

"성공이야!" 팀원들이 환호성을 질렀다.

이성호는 새로 생성된 URL로 접속해보았다. BizpulseCRM의 로그인 화면이 나타났다.

"우리가 해냈어." 그의 목소리에는 감동이 묻어났다.

새로운 시스템의 장점은 명확했다. 새 고객이 BizpulseCRM을 사용할 수 있기까지의 리드 타임이 대폭 감소했고, 고객의 IDC가 아닌 BizpulseCRM의 AWS 계정에서 서비스가 구동되니 유지보수도 훨씬 수월 해졌다.

개방팀장 이성호는 영업팀과의 미팅을 잡고 새로운 시스템에 대해 설명했다. 박지원은 이 변화를 놓치지 않았다. "이건 정말 대단한 발전이에요! 우리 제품이 한층 더 매력적으로 변했어요."

그녀는 팀을 소집해 새로운 마케팅 전략을 수립했다. "우리는 이제 '클라우드 네이티브 CRM'을 판매하는 거예요. 빠른 구축, 쉬운 유지보수, 언제 어디서나 접근 가능한 CRM!"

새로운 고객들이 하나 둘 늘어나기 시작했다. 하지만 아직 완벽하지는 않았다. 고객이 BizpulseCRM을 사용하려면 여전히 홈페이지나 영업팀을 통해 사용 요청을 해야 했고, 그때마다 TF에서Control Plane을 통해 인스턴스를 생성하는 단계를 거쳐야 했다.

이성호는 이 과정을 지켜보며 생각에 잠겼다. "우리는 한 걸음 더 나아가야 해. 고객이 필요로 할 때 간편하게 바로 사용할 수 있는 진정한 SaaS... 그게 우리의 다음 목표가 되어야 해."

그는 다음 미팅에서 이 아이디어를 팀과 공유하기로 마음먹었다. BizpulseCRM의 SaaS 여정은 아직 끝나지 않았다. 오히려 이제 막 시작된 것일지도 모른다.