안녕하세요 주간SaaS 입니다. 고객과 시장의 빠른 변화에 따라가다 보면 제품을 빠르게 릴리스 하는데 집중하게 됩니다. 그 과정에서 때로는 실제로 고객의 가치 제안이 검증되지 않은 기능에 대한 품질 기준이 생기고 아키텍처 형태는 그 기준에 의해 변화되고 정작 고객은 기능을 사용하지 않는 일들도 생깁니다. 이런 일은, SaaS를 만드는 과정 뿐 아니라 일반적으로 소프트웨어를 만드는 과정에서 발생할 수 있는 일들 같습니다. 오늘은 시간이 지나도 지속 가능한 소프트웨어 아키텍처를 만들기 위해 지켜야 하는 원칙을 정리한 글을 소개 합니다.
시간이 되신다면 이 원칙의 배경에 대해 조금더 자세한 내용이 담겨 있는 이 글도 읽어보시면 좋을것 같습니다.
그럼 좋은 하루 보내세요!
원칙 1:
제품을 설계하세요. 프로젝트에서 제품으로 진화하세요. 제품을 설계하는 것은 프로젝트에 대한 포인트 솔루션을 설계하는 것보다 더 효율적이며 팀원들이 고객에 집중할 수 있도록 합니다.
원칙 2:
기능적 요구 사항이 아닌 품질 속성에 집중하세요. 품질 속성 요구 사항이 아키텍처를 주도합니다.
원칙 3:
꼭 필요할 때까지 설계 결정을 연기하세요. 추측이 아닌 사실에 기반하여 아키텍처를 설계하세요. 사용되지 않을지도 모르는 기능을 설계하고 구현하는 것은 시간과 리소스를 낭비하는 일입니다.
원칙 4:
변화를 위한 아키텍처를 설계하세요. "작은 것의 힘"을 활용하세요. 크고 모놀리식이며 긴밀하게 결합된 구성 요소는 변경하기 어렵습니다. 대신 작고 느슨하게 결합된 소프트웨어 요소를 활용하세요.
원칙 5:
빌드, 테스트, 배포 및 운영을 위한 아키텍처를 설계하세요. 대부분의 아키텍처 방법론은 소프트웨어 구축 활동에만 초점을 맞추지만, 지속적인 배포를 지원하기 위해서는 아키텍트가 테스트, 배포 및 운영에도 관심을 가져야 한다고 생각합니다.
원칙 6:
작업 중인 시스템을 설계한 후 팀 조직을 모델링하세요. 팀이 조직되는 방식에 따라 작업 중인 시스템의 아키텍처와 디자인이 결정됩니다. 이 6가지 원칙은 아키텍트가 최신 애플리케이션을 위한 소프트웨어 아키텍처의 가장 중요한 측면에 집중하는 동시에 애자일 및 DevOps 작업 방식을 지원하는 점진적이고 발전적인 방식으로 작업할 수 있도록 도와줍니다.
댓글
의견을 남겨주세요