다음을 통해 공유

스타트업을 위한 아키텍처

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

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

혁신 단계

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

제품 개발의 탐색, 확장 및 추출 단계를 보여 주는 그래프입니다.

  • 탐색 스테이지는 낮은 경사로 시작하여 어떤 것이 작동하는지 찾으려고 합니다. 확실성은 낮고, 소액만 투자하며, 변경으로 인한 위험도 낮습니다.

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

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

탐험하다

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

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

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

첫 번째 스택 빌드

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

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

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

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

확장하다

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

아키텍처 확장

제품을 수정하거나 개선할 때 아키텍처 개편이 필요한 부분을 필연적으로 찾게 될 것입니다. 백그라운드에서 장기 실행 작업을 완료하거나 IoT(사물 인터넷) 디바이스에서 자주 업데이트해야 할 수 있습니다. 제품에 전체 텍스트 검색 또는 인공 지능을 추가해야 할 수 있습니다.

로드맵의 항목을 수용하려면 아키텍처를 변경해야 할 수 있습니다. 그러한 변화를 너무 미리 만들려는 유혹에 저항하십시오. 확장은 아키텍처에 복잡성을 추가하고 인프라 비용을 대차대조표에 추가할 위험이 있습니다.

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

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

추출

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

성장 관리 및 스택 성숙시키기

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

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

조기에 최적화하려는 유혹에 저항하십시오. 제품을 계속 반복하고 개선하는 데 도움이 되는 성장 및 성숙 단계를 수행해야 합니다.

다음 단계