****# 개요

회사에서 SaaS 비즈니스를 운영함에 따라, SaaS를 어떻게 개발해야 하는지, 프론트엔드(FE) 개발자의 관점에서 어떤 기술을 활용할 수 있는지, 그리고 실제로 어떤 방식으로 접근해야 할지에 대한 고민을 정리해보았다..

SaaS 개발은 그냥 개발과 무엇이 다를까

1. 기능의 확장성과 선택성

   SaaS는 사용자가 필요에 따라 기능을 선택하고 확장할 수 있어야 한다. 예를 들어, 'A+' 플랜을 구매한 고객은 'A' 플랜 사용자에게는 제공되지 않는 추가 기능에 접근할 수 있어야 한다. 이를 위해 FE 개발자는 사용자 권한에 따라 동적으로 UI를 조정할 수 있는 유연한 설계 방식을 도입해야 한다. 이러한 접근은 실수로 특정 기능이 잘못된 사용자에게 노출되는 것을 방지하는 데에도 중요하다.

2. 컴포넌트의 재사용성과 일관된 디자인

   SaaS는 컴포넌트 기반 개발의 장점을 최대한 활용해야 한다. 이는 개발의 효율성을 높이고, 유지보수를 용이하게 한다. 또한, 플랜에 관계없이 일관된 사용자 경험을 제공하기 위해 디자인 시스템과 가이드라인을 정립하는 것이 중요하다. 따라서, 컴포넌트는 재사용 가능하며, 전체 서비스에 걸쳐 일관된 디자인 언어를 사용해야 한다.

3. 테스트(QA)의 중요성

   SaaS 제품의 성공은 고품질의 서비스 제공에 달려 있다. 제품이 출시된 후에도 지속적인 업데이트와 개선이 필요하며, 이 과정에서 발생할 수 있는 오류를 최소화하기 위해 철저한 테스트 과정이 필수적이다. 고객이 유료로 서비스를 이용하는 만큼, 서비스의 모든 측면에서 높은 품질을 유지하는 것이 매우 중요하다.

도입하거나 검토해볼 수 있는 기술

1. 서버 드리븐(Server Driven UI)

   서버 드리븐 UI는 서버에서 UI 구성 요소와 레이아웃을 동적으로 결정하고 클라이언트로 전송하는 방식이다. 이 접근 방식은 FE개발자가 사용자의 행동이나 권한 변경에 따라 UI를 신속하게 조정할 수 있게 해주며, 클라이언트 사이드의 로직을 최소화한다. 다양한 사용자 권한과 맞춤형 기능을 제공하는 SaaS 서비스에 유용하다.

   • 레퍼런스 : 네이버 D2, 토스, 친구네 회사
     • 솔직히 얘네는 뭘 써도 되는 애들이라 참고하기 어려움
     • 친구네 회사도 도입하려고 한다는데 한 1년뒤에 물어보면 어떻게 되었을지 알 수 있을 것 같음.

2. 아토믹 디자인패턴

   아토믹 디자인은 UI를 작은 단위(아토믹)부터 복잡한 구조(페이지)까지 여러 단계로 나누어 개발하는 방식이다. 재사용 가능한 컴포넌트를 만드는 데 초점을 맞추고, 일관된 디자인 시스템 구축에 도움을 준다.

   • 스토리북

     스토리북은 컴포넌트 기반 UI 개발을 위한 오픈 소스 도구로, 개발자가 컴포넌트를 독립적으로 개발하고 테스트할 수 있게 해준다. 아토믹 디자인 패턴과 함께 사용하면 컴포넌트의 재사용성과 일관성을 크게 향상시킬 수 있다.

   • 레퍼런스 : 아토믹은 요새 여기저기 다써서 뭐

     • 아토믹이 문제가 아니라 스토리북이 문제인데, 우리회사는 chatGPT의 힘을 빌리고 있다.

3. 품질 보증(QA) 전략

   e2e(end-to-end) 테스트

   e2e 테스트는 사용자의 관점에서 애플리케이션의 흐름을 테스트하는 방법이다. Cypress, Selenium과 같은 도구를 사용하여 자동화된 테스트를 구현함으로써, 개발 과정에서 발생할 수 있는 오류를 조기에 발견하고 고품질의 사용자 경험을 보장할 수 있다.

   • 레퍼런스 : 어느 회사든 멀쩡하게 e2e를 돌리는 회사는 흔하지 않은 것 같다.
     • QA엔지니어가 필요하지 않을까

4. 그 외

• i18n (국제화): 글로벌 서비스를 위한 다국어 지원은 사용자 기반을 확장하는 데 중요하다.
• PWA (프로그레시브 웹 앱): 푸시 알림, 오프라인 지원 등 웹 API를 활용해 앱과 유사한 사용자 경험을 제공한다.

SaaS 개발 과정에서 이러한 기술과 전략을 적극적으로 검토하고 적용함으로써, 효율적이고 확장 가능하며 고객 만족도가 높은 서비스를 제공할 수 있다.

제약사항

사실 나는 회사에서, 스토리북 및 아토믹 디자인 패턴, 그리고 e2e 테스트, i18n의 도입을 시도해보았다.(서버 드리븐 UI는 아직 경험해보지 못했다.) 이 과정에서 깨달은 점은, 아무리 유용한 기술이라도 가장 중요한 제약사항은 바로 '시간'이라는 것이다.

스토리북 작성과 e2e 테스트는 상당한 시간과 노력을 요구한다. 특히, 처음부터 재사용성과 확장성을 고려한 개발 표준과 디자인 시스템이 명확하게 정립되어 있지 않은 상태에서 이러한 기술을 도입하려고 하면, 비효율적이며 개발 공수의 낭비로 이어질 위험이 크다.

스타트업과 같이 매일매일 바쁘고 새로운 기능이 수시로 추가되는 환경에서, 이러한 작업들은 어떻게 효과적으로 이루어져야 할까? 이는 큰 고민이다.

이러한 상황에서의 내린 내 나름의 결론은 다음과 같이 고려될 수 있다:

1. 점진적 도입: 모든 것을 한 번에 도입하려 하지 말고, 가장 큰 가치를 제공할 수 있는 부분부터 점진적으로 도입한다.
2. 필수 요소에 집중: 초기 단계에서는 가장 중요한 기능의 테스트와 컴포넌트화에 집중하고, 점차 범위를 확장해 나간다.
3. 자동화와 툴의 활용: 가능한 많은 부분을 자동화하고, 개발 과정을 지원하는 도구를 활용하여 시간을 절약한다.
4. 팀 내 합의와 기준 마련: 전체 팀이 동의하는 개발 표준과 디자인 시스템을 초기에 마련하고, 이를 지속적으로 개선해 나간다.

이러한 접근 방식을 통해, 제한된 시간과 리소스 내에서도 효율적으로 작업을 진행하고, 점차적으로 시스템을 개선해 나갈 수 있을 것이다.
SaaS 비즈니스 모델과 스타트업/SI와의 차이에 대한 개요는 [[KnowledgeBase/Blog/SaaS란 무엇인가, SaaS, 스타트업, 그리고 SI]]를 먼저 읽으면 도움이 된다.