[MVP] Ian Tweedie와 함께하는 복잡한 엔터프라이즈 솔루션을 위한 Power Platform 아키텍처 설계

Microsoft Power Platform은 종종 로우코드(low-code) 플랫폼으로 설명됩니다. 하지만 여러분이 만든 애플리케이션이 비즈니스에 필수적이고, 고도로 통합되며, 단순한 메이커 중심 접근 방식으로는 감당하기 어려울 만큼 복잡해지면 어떻게 될까요?

이번 M365 FM 에피소드에서 Mirko Peters는 Power Platform 솔루션 아키텍트 Ian Tweedie와 함께, Power Platform이 단순한 로우코드 애플리케이션을 넘어 본격적인 엔터프라이즈 아키텍처의 일부가 될 때 어떤 일이 일어나는지 이야기합니다.

로우코드가 로우 아키텍처를 의미하지는 않습니다
Power Platform은 많은 비즈니스 가치를 빠르게 제공할 수 있지만, 엔터프라이즈 솔루션에는 거의 언제나 표준 로우코드 기능을 넘어서는 요구사항이 포함됩니다.
Ian은 로우코드를 노코드(no-code)와 혼동해서는 안 되는 이유, 그리고 Power Apps, Power Automate, Dataverse, 커스텀 커넥터, API, Azure 서비스로 개발할 때 전통적인 소프트웨어 아키텍처 원칙이 여전히 중요한 이유를 설명합니다.

Power Platform이 엔터프라이즈 소프트웨어가 될 때
로우코드와 엔터프라이즈 사이에 명확한 경계가 있는 것은 아닙니다.
애플리케이션이 여러 사용자 여정, 개발 팀, 통합, 보안 요구사항, 비즈니스 필수 프로세스, 상호 연결된 서비스를 포함하기 시작하면 복잡성이 증가합니다.
그 시점에서 아키텍처는 필수가 됩니다.
Ian은 하나의 거대하고 상호 연결된 애플리케이션이 되지 않도록, 솔루션을 명확히 정의된 기능과 모듈로 나누고 깔끔한 인터페이스를 갖추어야 하는 이유를 설명합니다.

두더지 잡기(Whack-a-Mole) 개발 문제에서 벗어나기
하나의 버그를 고치면 다른 곳에서 또 다른 버그가 나타납니다.
이 익숙한 개발 문제는 종종 긴밀하게 결합된(tightly coupled) 아키텍처의 증상입니다.
Ian은 모듈식 설계가 기능을 격리하고 의도치 않은 의존성을 줄일 수 있는 방법을 논의합니다. 이메일 발송을 예로 들어, 비즈니스 프로세스와 전달 메커니즘을 분리하면 애플리케이션을 테스트, 유지보수, 교체, 확장하기가 더 쉬워질 수 있다고 설명합니다.

로우코드 + 프로코드 = 하이브리드 아키텍처
Power Platform이 전통적인 소프트웨어 개발과 경쟁할 필요는 없습니다.
Power Apps 프론트엔드는 Azure, AWS, GCP, API, 또는 커스텀 서비스를 사용하는 훨씬 더 큰 애플리케이션의 일부에 불과할 수 있습니다.
중요한 아키텍처 질문은 무언가가 "로우코드"인지 "프로코드"인지가 아니라, 각 기능에 어떤 기술이 가장 적합한지입니다.

시민 개발자, 메이커, 그리고 아키텍처
시민 개발자(citizen developer)는 매우 가치 있는 것을 가져옵니다. 바로 매일 함께 일하는 비즈니스 프로세스에 대한 깊은 지식입니다.
하지만 비즈니스 전문성이 자동으로 좋은 애플리케이션 아키텍처로 이어지지는 않습니다.
Ian은 메이커에게 힘을 실어주는 것과, 솔루션이 유지보수하기 어려워지는 것을 막기 위해 충분한 아키텍처, 거버넌스, 정규화, 기술 검토를 도입하는 것 사이의 균형에 대해 이야기합니다.

혁신을 죽이지 않는 거버넌스
거버넌스가 너무 부족하면 혼란이 생깁니다.
거버넌스가 너무 많으면 마찰이 생기고, 직원들을 지원되지 않는 우회 방법, 스프레드시트, VBA, 그리고 섀도우 IT로 몰아갈 수 있습니다.
과제는 조직의 위험, 애플리케이션의 중요도, 사용자, 비즈니스 영향에 따라 적절한 수준의 거버넌스를 찾는 것입니다.

Power Platform, API 그리고 Azure
비즈니스 로직은 어디에 있어야 할까요?
시크릿(secret)을 Power Platform 내부에 저장해야 할까요? Azure Key Vault, Azure Functions, 또는 API Management는 언제 아키텍처의 일부가 되어야 할까요?
Ian은 단지 사용 가능하다는 이유로 Azure 서비스를 추가하기보다, 아키텍처는 항상 해결하려는 문제에서 시작해야 한다고 설명합니다.

Git, 소스 제어, 그리고 CI/CD
Power Platform 개발이 점점 협업 중심이 되면서, 전통적인 개발 관행이 점점 더 중요해지고 있습니다.
대화는 Git, 리포지토리, 개발 환경, 파이프라인, 소스 제어, 기능 격리, 상호 의존성, 그리고 CI/CD를 다룹니다.
Power Platform에서 소스 제어에 대한 완벽한 접근법이 항상 존재하지는 않으며, 때로는 프로젝트를 위한 "최선보다 덜 나쁜 선택(least worst option)"을 고르는 것이 목표가 되기도 합니다.

Ian의 Power Platform 아키텍처 플레이북

Ian의 핵심 원칙은 간단합니다.
솔루션을 기능과 모듈로 나누세요.
각 기능은 존재하는 명확한 이유가 있어야 하며, 이상적으로는 하나의 특정 책임만 수행해야 합니다.
그런 다음 이 기능들이 어떻게 소통하는지, 로직이 어디에서 실행되어야 하는지, 어떻게 테스트해야 하는지, 그리고 어떤 기술이 구현에 가장 적합한지를 결정하세요.

빠른 질문 라운드
Mirko는 Ian에게 몇 가지 빠른 질문을 던집니다.
모든 엔터프라이즈 애플리케이션이 Dataverse를 사용해야 할까요?
Power Platform으로 미션 크리티컬 애플리케이션을 만들 수 있을까요?
Power Automate가 Logic Apps를 대체할 수 있을까요?
로우코드는 자동으로 기술 부채를 줄여줄까요?
Power Platform이 전통적인 애플리케이션 개발을 대체할 수 있을까요?
그리고 아마 가장 중요한 질문: 뉴캐슬을 방문하면 무엇을 주문해야 할까요?

핵심 요약
로우코드가 로우 아키텍처를 의미하지는 않습니다.
Power Platform 솔루션이 더 커지고, 더 많이 연결되고, 비즈니스에 더 중요해질수록 소프트웨어 엔지니어링의 기본 원칙은 여전히 유효합니다.
아키텍처가 중요합니다.
데이터 모델링이 중요합니다.
거버넌스가 중요합니다.
보안이 중요합니다.
API 설계가 중요합니다.
DevOps가 중요합니다.
그리고 성공적인 엔터프라이즈 Power Platform 개발은 점점 로우코드, 프로코드, Azure, API, 자동화, 그리고 전통적인 소프트웨어 엔지니어링 관행이 어떻게 함께 작동하는지를 이해하는 데 달려 있습니다.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.