SaaS 도입 회고

Munki Shin·2022년 11월 13일

새로운 기능을 추가하는 요구사항을 반영하기위해 SaaS를 도입하였습니다.

프로젝트를 진행하면서 이미 알고 있거나 미리 알고 있었다면 좋았을 토픽들을 SaaS 도입 검토 ~ 구현의 시간 순서대로 회고해보았습니다.

SaaS를 도입하는것을 고려하고 있거나 설계, 개발을 진행하시는 모든 분들께 이글이 도움이 될 수 있다면 좋을 것 같습니다!

도입 검토

SaaS는 범용적인 요구사항을 반영하기에는 좋지만 특정 비즈니스의 요구사항을 반영하기에는 적합하지 않을 수 있습니다.

특히나 SaaS를 도입하면서 비즈니스 요구사항을 반영하기 위해 기존 기능 설계에 많은 변화가 생겨야하는 경우라면 기민하게 결과를 만드는것이 어렵게되고 결국 고객의 반응을 빠르게 확인할 수 없어 프로젝트의 불확실성이 높아지게 됩니다.

만약 특정 기능을 구현하기 위해 SaaS 도입을 검토하는 것이라면 SaaS도입이 최소한의 노력을 해당 기능을 구현하는 유일한 옵션인지 고민이 필요합니다.

이전부터 설계의 중요성을 알고있어서 나름 설계를 진행한뒤에 코드를 작성하기 시작했지만 설계에서 고려하지 못하였던 예외사항들이 많이 발생하였습니다.

이러한 예외사항을 그때그때마다 처리하다보니 결국 초기 설계와는 다른 방향의 결과가 나오게 되었고 일정 또한 예상했던것 보다는 늦춰졌습니다.

만약 초기 설계에 좀더 시간을 할애하여 이러한 예외사항을 잘 검토했다면 로직을 개발하는 시간을 많이 줄여 전체적인 개발 일정을 앞당길 수 있었을것이라고 생각합니다.

검색을 통해 cherry-pick을 하게된다면 그때그때 필요한 지식에 대해서는 가장 빠르게 얻을 수 있어서 디버깅을 하거나 특정 지식을 원하는 경우에는 답이 될 수 있다고 생각합니다.

하지만 SaaS 도입을 위한 검토 혹은 설계등 거시적인 관점에서 파악이 필요한 경우에는 공식 문서를 정독하는것이 전체적인 흐름도 파악할 수 있고 특정 예외사항에 대한 인지도 가능하기 때문에 선행되어야한다고 생각합니다.

SaaS를 도입하기로 결정하였다면 SaaS를 제공하는 사람들에게 본인들의 기존 비즈니스를 이해시키고 best practice를 구해야합니다.

SaaS 서비스에 대한 이해도는 만든 사람들이 가장 잘알고 있고 이미 다른 고객사들과의 협업에서 유사한 케이스를 통해 얻은 노하우가 있을 가능성이 높기 때문입니다.

반대로 본인이 SaaS 서비스에 대한 모든 이해를 하는 방법도 있지만... 이 방법이 더 어렵지 않을까요?

SaaS 도입뿐만 아니라 다른 프로젝트에서도 허용되는 트래픽, 트랜잭션 관리등 비기능적 요구사항이 함께 확인되어야합니다

SaaS의 경우에는 해당 솔루션이 어느정도의 트래픽을 받을 수 있고 특정 트래픽을 넘어갈때 문제가 발생하는지 인지하고 이러한 장애가 우리의 비즈니스에 영향이 없도록 해야합니다.

가장 좋은 방법은 스테이징환경에서 트래픽을 재현해보는것이지만 만약 불가하다면 SaaS 제공사로부터 시나리오별 트래픽 임계치를 전달받고 그 이상의 트래픽이 발생할 수 있는 경우라면 이에 대한 예외처리가 필요합니다.

이번 회고에 나온 토픽들이 SaaS 도입 프로젝트뿐만 아니라 일반적인 프로젝트에서도 통용되는 토픽인것 같습니다.

기존에 알고 있던 실수들을 경험한 만큼 처음에는 부끄러운 감정이 컷지만 회고를 통해 다음 프로젝트에서는 같은 실수를 반복하지 않는 모습을 기대해봅니다!