스타트업을 위한 아키텍처

스타트업을 구축하는 것은 독특한 과제입니다. 핵심 과제는 시장에서 제품 또는 서비스로서의 혁신을 위한 장소를 찾는 것입니다. 이 프로세스를 수행하려면 혁신에 기본 제공되는 여러 가정을 테스트해야 합니다. 성공적인 스타트업은 이러한 가정을 반복하고 제품이 제품 및 시장에 적합해짐에 따라 성장하고 확장해야 합니다. 이 적합을 찾은 후 스타트업은 시장 수요를 포착하기 위해 규모를 조정해야 합니다.

다양한 스타트업 수명 단계에서 개발자, 설계자 및 CTO(최고 기술 책임자)는 고유한 개발 단계를 처리합니다. 이러한 단계에는 근본적으로 다른 접근 방식과 다양한 기술 선택이 필요합니다. 작업의 일부는 시작하는 단계를 설정하는 것입니다. 해당 단계와 일치하는 기술, 접근 방식 및 아키텍처를 선택합니다.

혁신 단계

Kent Beck은 소프트웨어 제품 혁신의 3단계 프로세스를 설명합니다. 이러한 단계는 탐색, 확장 및 추출입니다. 이 프로세스의 여러 부분을 그래프로 생각할 수 있습니다.

• 탐색 단계는 낮은 경사면에서 시작하여 어떤 것이 작동하는지 찾으려고 합니다. 확실성이 낮고, 소량만 투자하며, 변경에 따른 위험도 낮습니다.

• 제품 시장 적합성이 발견되면 그래프가 더 빠르게 상승합니다. 이러한 급속한 성장은 확장 단계입니다. 확실성이 크게 증가하고, 훨씬 더 많이 투자하고, 위험을 훨씬 더 잘 알고 있습니다.

• 마지막으로 그래프가 평면화되고 시작이 완성도에 도달하면 추출 단계에 도달합니다. 확실성, 투자 및 변화에 따른 위험은 모두 높지만 성장률은 정체기에 접어들었습니다.

탐색

스타트업이 탐색 단계에 있는 경우 다양한 제품 아이디어에 적은 시간과 노력을 투자해야 합니다. 대부분의 아이디어가 옳지 않을 것이라는 사실은 탐색을 유도합니다. 반복 및 학습을 통해서만 제품 및 시장에 적합한 제품을 찾을 수 있습니다. 많은 작은 베팅을 함으로써, 성과가 있는 제품 아이디어를 찾는 것을 목표로 합니다.

이 단계에는 원칙이 필요합니다. 더 적은 시간과 에너지로 테스트할 수 있다는 아이디어에 과도하게 투자하기 쉽습니다. 기술자는 특히 이 함정에 빠지기 쉽습니다. 탐색을 용이하게 하는 아키텍처를 선택하려면 탐색 중이라는 점을 기억하세요. 현재 제품 아이디어가 확장될 제품인지는 아직 알 수 없습니다.

아키텍처 관점에서 속도, 비용 및 옵션에 최적화된 서비스를 선택합니다. 복잡한 인프라에 대한 걱정 없이 Azure App Service와 같은 관리형 서비스 및 PaaS(Platform as a Service)를 사용하여 신속하게 시작할 수 있습니다. 탐색하는 동안 무료 계층 및 더 작은 인스턴스 크기를 선택하여 비용을 관리합니다. 컨테이너는 사용자에게 적합한 도구를 사용하여 개발을 지원하고 향후에 유연한 배포 옵션을 제공합니다.

첫 번째 스택 빌드

첫 번째 제품 버전과 마찬가지로 첫 번째 기술 스택은 탐색에 확고하게 뿌리를 두어야 합니다. 즉, 기술 스택은 노력을 낭비하지 않고 신속한 제품 반복을 용이하게 해야 합니다. 현재 질문에 대답하는 데 필요하지 않은 인프라 또는 아키텍처에 시간과 노력을 들이고 싶지 않습니다.

탐색 단계에서 속도, 비용 및 선택 사항을 최적화해야 합니다. 속도는 아이디어를 빌드하고 앞으로 나아가거나 다음 아이디어로 이동할 수 있는 속도에 관한 것입니다. 비용은 인프라를 실행하는 데 지출하는 비용입니다. 선택 사항은 현재 아키텍처를 고려할 때 방향을 얼마나 빨리 변경할 수 있는지 설명합니다.

비용, 속도 및 선택 사항의 균형을 맞추는 것이 중요합니다. 비용에 너무 집중하면 속도와 선택성이 제한됩니다. 속도에 너무 집중하면 비용이 증가하고 옵션이 줄어들 수 있습니다. 너무 많은 옵션을 디자인하면 복잡성이 증가하여 비용이 증가하고 속도가 감소합니다.

제안된 첫 번째 기술 스택을 사용하는 것이 좋습니다. 이 아키텍처는 구현의 용이성을 위해 PaaS 서비스를 사용하고, 최소한의 규모로 시작할 수 있으며, 완성도에 따라 다양한 기술 스택에 쉽게 배포할 수 있는 컨테이너 및 오픈 소스 기술을 사용합니다.

Expand

스타트업이 탐색을 통해 제품 시장 적합성과 후속 성장을 발견하면 기어를 확장으로 전환합니다. 제품 및 회사의 지속적인 성장을 방해하는 장애물을 제거하는 데 집중합니다. 기술적인 관점에서 인프라 규모 문제를 해결하고 개발 속도를 높입니다. 목표는 신규 고객의 요구를 충족하고 제품 로드맵을 발전시키는 것입니다.

아키텍처 확장

제품을 반복할 때 아키텍처를 확장해야 하는 영역을 필연적으로 찾을 수 있습니다. 백그라운드에서 장기 실행 작업을 완료하거나 IoT(사물 인터넷) 디바이스에서 자주 업데이트를 처리해야 할 수 있습니다. 제품에 전체 텍스트 검색 또는 AI를 추가해야 할 수도 있습니다.

로드맵의 항목을 수용하기 위해 아키텍처 변경이 필요할 수 있습니다. 너무 일찍 변경하려고 하면 안 됩니다. 확장은 아키텍처에 복잡성을 더하고 인프라 비용이 대차대조표에 추가될 위험이 있습니다.

초기 시작 단계에서 모든 아키텍처 확장은 Just-In-Time이어야 합니다. 확장은 다음 가설을 테스트하는 데 필요한 만큼의 시간과 에너지만 필요합니다. 복잡성을 줄이기 위해 확장을 제거할 준비를 합니다. 고객이 아키텍처를 단순화하고 인프라 지출을 줄이는 기회로 사용하지 않는 제품 기능을 찾습니다.

아키텍처는 다음과 같은 여러 가지 방법으로 확장될 수 있습니다.

• RAG(검색 증강 세대)를 통해 인공 지능 추가
• 영역 중복 배포를 통한 복원력 향상
• 고가용성 다중 지역 배포를 통한 복원력 향상
• 네트워크 강화 기술 스택을 통한 보안 강화

추출

추출 단계에서는 시장 기회의 한계에 도달함에 따라 성장 속도가 느려집니다. 이전 단계를 통해 확장했으므로 이제 잃을 것이 많으므로 더 신중한 접근 방식을 취합니다. 마진 확대, 비용 절감 및 효율성 향상은 추출 단계의 특징입니다. 추출 단계에서는 확장 단계에서 획득한 고객을 위해 제품이 손상되지 않도록 주의해야 합니다.

증가 처리 및 스택 성숙화

제품이 제품성과 시장에 적합하게 되면 많은 수요가 아키텍처를 주도하게 됩니다. 사용량이 증가하면 부하를 처리하기 위해 인프라 크기 조정이 필요할 수 있습니다. 새로운 엔터프라이즈 규정 준수 요구 사항에는 더 큰 격리가 필요할 수 있습니다. 이러한 변경은 성공적인 애플리케이션을 완성하는 일반적인 단계입니다.

성장을 처리하고 완성도를 더하기 위해 변경한 내용은 아키텍처를 확장하는 것과 다릅니다. 이러한 변경 내용은 기능 요구 사항이 아니라 규모 잠금 해제와 관련이 있습니다. 규모는 순 신규 고객, 기존 고객의 사용 증가, 규제 요구 사항이 높은 고객에서 비롯될 수 있습니다.

성급하게 최적화하려는 해서는 안 됩니다. 제품을 계속 반복하고 개선하는 데 도움이 되는 성장 및 성숙 단계를 수행해야 합니다.

다음 단계

• 예제 Core 시작 스택 아키텍처를 참조하고 배포합니다.

관련 참고 자료

• 클라우드 애플리케이션의 모범 사례
• Azure 애플리케이션을 위한 10가지 설계 원칙