Milestone 2 - SaaS 전환의 첫 걸음

Milestone 2 - SaaS 전환의 첫 걸음

General Immersion Day가 끝난 다음날 개발팀장 이성호는 모든 개발자들을 회의실에 모았다. 젊은 개발자들은 대체로 클라우드 기술 사용에 대해 기대감을 나타냈지만 우려의 목소리도 많았다.

"이미 안정화된 제품을 굳이 바꿀 필요가 있을까요?"

"변화에 맞춰 우리의 역량을 빠르게 업그레이드할 수 있을까요?"

"이 코드베이스는 15년 동안 쌓아온 우리의 자산입니다." 개발팀 수석 아키텍트 한지훈이 단호하게 말했다. "이걸 클라우드용으로 다시 작성한다고요? 불가능합니다."

이성호는 참을성 있게 대답했다. "불가능하지 않아요. 단계적으로 접근하면 됩니다."

"단계적이라고요?" 지훈이 비웃듯 말했다. "우리 시스템은 수백만 라인의 코드와 복잡한 종속성을 가지고 있어요. 이건 레고 블록처럼 쉽게 옮길 수 있는 게 아닙니다."

백엔드 개발 리더 박서진이 끼어들었다. "게다가 우리 코드는 특정 데이터베이스 기능과 OS 레벨 최적화에 의존하고 있어요. 클라우드로 옮기면 성능이 크게 저하될 겁니다."

특히 BizpulseCRM의 설계 단계부터 주도해온 박진석 수석 개발자의 의견이 무거웠다.

"이런 혁신적인 시도는 스타트업이나 하는 겁니다. 우리는 이미 시장에서 검증된 제품을 가지고 있어요. 위험을 감수할 이유가 없습니다. 게다가 우리 코드베이스를 SaaS 환경에 맞게 변환하는 건 엄청난 작업이 될 거예요."

이성호는 깊게 숨을 들이쉬었다. "여러분, 저도 이 코드베이스를 직접 만들어온 사람 중 하나입니다. 하지만 시장은 변하고 있어요. 우리가 적응하지 않으면..."

"그렇다고 10년간 검증된 아키텍처를 버리자는 건가요?" 한지훈이 말을 자르며 물었다. "우리 고객들은 안정성과 성능 때문에 우리 제품을 선택했어요."

"우리는 그것들을 버리는 게 아니라, 새로운 환경에 맞게 진화시키는 겁니다." 이성호가 화이트보드 앞으로 걸어갔다. "전 단계적으로 접근하고 싶습니다."

이성호도 한숨을 내쉬었다. 자신도 내심 불안했다. 온프레미스 환경에서만 개발해온 제품을 클라우드로 옮기는 것은 엄청난 도전이었다. 하지만 이대로 불안해 하기만 할 순 없었다.

회의가 끝난 후, 몇몇 개발자들이 조용히 이성호에게 다가왔다. "팀장님, 저희가 도울 수 있을 것 같아요. 새로운 시도에 관심이 있습니다." 젊은 개발자 김민재가 말했다.

이성호는 희망의 빛을 발견한 듯 미소를 지었다. 클라우드 기반 개발에 관심을 보이는 개발자 5명으로 TF를 꾸리고 SaaS 전환과 기존 개발을 병행하기로 결정했다.

일주일 뒤 AWS 어카운트팀과 새로운 미팅이 잡혔다. 이 자리에서 김범준 Solutions Architect는 BizpulseCRM 개발팀에게 다음과 같은 제안을 했다.

"여러분, SaaS 전환 여정에 첫 번째 Milestone으로 BizpulseCRM을 EC2에서 동작할 수 있게 마이그레이션 하는것을 제안드립니다. AWS에 대한 이해도를 높이면서 앞으로의 SaaS 전환 과정에 초석이 될 것입니다."

개발팀장 이성호의 눈이 반짝였다. "그거 좋은 생각이네요. 우리의 첫 클라우드 발걸음이 될 수 있겠어요."

이성호는 곧바로 행동에 나섰다. SaaS 전환 TF는 2주동안 스프린트를 진행하며 BizpulseCRM을 EC2로 옮기는 작업을 시작했다. 때로는 난관에 부딪히기도 했지만 김범준 Solutions Architect에게 조언을 구하며 스프린트를 이어나갔다.

"EC2 인스턴스에 우리 애플리케이션을 옮겨오는 건 쉽지 않네요. 네트워크 구성부터 데이터베이스 마이그레이션까지 신경써야 할 일이 한 두 가지가 아니에요." 한 개발자가 한숨을 쉬었다.

"그래도 포기하지 마. 우리가 해낼 수 있어!" 다른 개발자가 격려했다.

마침내, 2주 후 그들의 노력이 결실을 맺었다. BizpulseCRM이 EC2 인스턴스에서 성공적으로 동작하기 시작한 것이다. 이성호는 EC2 인스턴스에 접속해 BizpulseCRM이 정상적으로 작동하는 것을 확인했다. 애플리케이션과 MySQL이 EC2에 직접 설치되어 있었고, EIP(Elastic IP)를 연결해 외부에서 접속할 수 있게 했다.

"우리가 해냈어요, 팀장님!" TF 팀원 중 한 명이 기쁨에 찬 목소리로 말했다.

이성호는 미소를 지었다. "그래, 정말 잘했어. 하지만 이건 시작에 불과해."

다음 AWS와의 미팅에서, 김범준 SA는 BizpulseCRM 팀의 성과를 축하해 주었다.

"훌륭합니다. 이제 SaaS로 전환하기 위한 기본적인 토대가 마련되었습니다. 다음 Milestone으로 진행하시죠."

모두가 귀를 기울였다.

"다음 Milestone에서는 빠르게 SaaS로 전환하기 위한 전략으로 Full stack silo의 아키텍처를 제안 드립니다. SaaS에서 Full stack silo 아키텍처는 공유하는 자원이 없이 각 테넌트마다 별도의 자원을 사용해 서비스를 제공하는 방식입니다. 새로운 테넌트 생성이 필요하면 앞 단계에서 BizpulseCRM을 EC2 환경으로 옮기면서 만든 AMI를 이용해 테넌트가 사용할 개별 인스턴스를 만들 겁니다. 이 과정은 CloudFormation을 이용해 자동화 시키고 이것을 관리할 Control Plane을 만들어야 해요. Control Plane이 조금 생소 하실 수 있지만 SaaS에서 꼭 필요한 부분입니다."

이때 TF 개발자가 김범준 SA에게 질문을 했다.

"SaaS는 Multi Tenant가 되어야 하고 Multi Tenant는 인스턴스를 공유해야 한다고 공부했는데 지금 말씀하신 Full stack silo 방식은 SaaS가 아니라고 생각되는데요?"

"아주 좋은 질문입니다." 김범준 SA가 설명을 이어 나갔다. 고전적인Multi Tenant에 대한 정의와 SaaS를 만들면서 빠지기 쉬운 함정에 대해 자세히 설명해 나갔다. 거기에 더해 SaaS에서 Control Plane의 역할과 필요성도 빼놓지 않고 전달했다.

설명을 들은 이성호와 TF팀은 그동안 알고 있었던 Multi Tenant의 정의를 다시 생각해보는 계기가 되었다.

김범준 SA가 계속이어나갔다. "보안은 언제나 최우선 고려사항입니다. EIP를 직접 연결하는 대신 Application Load Balancer를 통해 Private Subnet에 있는인스턴스에 접근 하도록방식으로 아키텍처를 개선하면 좋겠습니다."

이성호는 고개를 끄덕였다. "이해했습니다. 새로운 도전이 될 것 같네요."

회의실을 나서면서, 이성호는 깊은 숨을 내쉬었다. 첫 번째 Milestone을 달성한 기쁨도 잠시, 이제 더 큰 도전이 그들을 기다리고 있었다. 하지만 그의 눈에는 확신이 서려 있었다. 그들은 이제 클라우드로 가는 길에 첫 발을 내디뎠고, 멈출 수 없다는 것을 알고 있었다.

"자, 이제 다음 단계로 나아갈 시간이군." 이성호는 중얼거렸다. 그의 머릿속에는 이미 다음 Milestone을 위한 계획이 그려지고 있었다.