소프트웨어 아키텍처 가이드

앞에 쓰는 말

소프트웨어 업계에서, 사람들이"아키텍처"에 대해 이야기할 때, 소프트웨어 시스템 내부 설계의 가장 중요한 측면을 모호하게 정의하는 개념을 가리킨다. 양호한 아키텍처는 중요하다. 그렇지 않으면 장래에 새 기능을 추가하는 것이 점점 느려지고, 비용도 높아지기 때문이다

하지만"아키텍처"라는 단어는 신중하게 다뤄야 한다. 일반적으로 프로그래밍과의 분리, 심지어 화려한 과장을 의미하기 때문이다. 우리가 진정으로 주목하는 것은 자체의 변천을 지원할 수 있고, 프로그래밍과 밀접하게 결합되어 있는 좋은 아키텍처이다. 그렇다면:

• 좋은 아키텍처는 어떤 것인가?

• 팀은 어떻게 좋은 아키텍처를 창조할 수 있는가?

• 어떻게 우리의 개발 조직 내에서 아키텍처 사고를 육성할 수 있는가?

一.아키텍처란 무엇인가?

아키텍처의 정의는, 소프트웨어 업계에서一直以来 논쟁이 끊이지 않는 화제이다.有人认为 아키텍처는 시스템의 기본 조직 방식이며,也有人认为是 최고층 컴포넌트를 함께 연결하는 방식. 그러나,"기초","고수준"의 객관적 정의란 무엇인가? 따라서, 더 나은看法는 전문가 개발자가 시스템 설계에 대해 형성하는 컨센서스이다

P.S.또 하나의 일반적인 정의가 있으며, 아키텍처는 프로젝트 초기에 수행해야 할 설계 결정이라고 생각하지만, 이 역시 충분히 정확하지 않다. 프로젝트 내에서 가능한 한 일찍 수행해야 할 결정을 희망하는 것처럼 보이기 때문이다

Ralph Johnson 은,아키텍처란 중요한 모든 것이다. 그것이 구체적으로 무엇이든 라고 생각한다:

Architecture is about the important stuff. Whatever that is.

조금 고풍听起来지만, 도리가 있다.아키텍처의 관점에서 고려하는 핵심은, 무엇이 중요한 것인가 (즉, 무엇이 아키텍처인가) 를 확정하고, 이후 이러한 아키텍처 요소가 양호한 상태를 유지하도록 정성을 투입하는 것이기 때문이다. 아키텍트가 되고 싶은 개발자에게 있어, 그것들의 중요한 요소, 및 제어하지 않으면 심각한 결과를 초래하는 요소를 식별할 수 있어야 한다

P.S.아키텍처 정의에 대한 상세 정보는, Who Needs an Architect? 참조

二.왜 아키텍처는 그렇게 중요한가?

소프트웨어 제품의 고객과 사용자에게 있어, 아키텍처는 성가신 문제이다. 그들이 즉시 감지할 수 있는 것이 아니기 때문이다. 그러나, 졸렬한 아키텍처는 잡란무장 (cruft) 을 촉진하는 주요인이며, 이러한 것들은 개발자가 소프트웨어를 이해하는 것을 방해한다. 대량의 잡란한 것을 포함하는 소프트웨어는 변경이 어렵고, 기능 이터레이션 속도 저하, 결함 증가로 이어진다:

더 심각한 것은, 이러한 잡란한 것들이 코드베이스 전체에 퍼져 있어,_기능 이터레이션의 때마다 지연시킨다_는 것이다

습관 경험은告诉我们, 일반적으로 고품질의 것은 비용도 높다고. 소프트웨어의 몇 가지 측면 (예를 들어 사용자 경험) 에 대해서는, 확실히 그렇지만, 아키텍처와 내부 품질의 다른 측면에 관여할 때, 이 관계는 정반대이다: 고내부 품질은 신기능의 딜리버리 속도를 가속한다. 잡란한 것으로부터의 저해가 감소하기 때문이다

확실히, 단기적으로는 보다 신속한 딜리버리를 위해 품질을 희생할 수 있지만, 잡란한 것이 축적되어 영향을 미치기 전에, 사람들은 그것이 전체 딜리버리를 지연시키는 신속함을 과소평가하고 있다. 객관적으로 측정하는 것은 불가능하지만, 경험이 풍부한 개발자는 알고 있다. 내부 품질에 대한 주목은 몇 주 이내에 보답을 받는다 (몇 달이 아니라)

고내부 품질의 소프트웨어는 전기 딜리버리가 느리지만, 후기 딜리버리 속도는 훨씬 빠르다

P.S.소프트웨어 내부 품질과 비용에 대한 상세 정보는, Is High Quality Software Worth the Cost? 참조

三.애플리케이션 아키텍처

소프트웨어 개발における 중요한 결정은, 우리가 고려하는 컨텍스트 범위에 따라 다르다. 일반적인 범위는 애플리케이션, 즉 애플리케이션 아키텍처이다

소프트웨어 아키텍처를 정의하는 첫 번째 문제는, 애플리케이션이란 무엇인가를 명확히 정의하지 않은 것이다. 본질적으로, 애플리케이션은 일종의 사회 구조로 이해할 수 있다:

• 개발자로부터 보면 (애플리케이션은) 한 무리의 코드

• 비즈니스 고객으로부터 보면 한 세트의 기능

• 투자자로부터 보면 하나의 예산 계획

이 완만한 정의에 의해, 규모가 대소 다양한 애플리케이션이 존재하며, 개발 팀은 몇 명에서 수백 명까지 다르다 (규모를 관여하는 인원 수로 보는 것이 가장 유용한衡量 방식이다). 기업 아키텍처와의 주요 차이점은, 사회 구조를 둘러싸고很大 정도의 통일 목표가 존재한다는 것이다

애플리케이션의 경계

소프트웨어 개발에서 미해결 문제의 하나는, 소프트웨어의 경계가 무엇인가를 확정하는 것이다. 예를 들어, 브라우저는 오퍼레이팅 시스템의 일부인가?

본질적으로, 애플리케이션은 사회 구조이며, 우리는 수백 가지의 다른 방법으로 소프트웨어 경계를 묘사할 수 있다 (개발자, 비즈니스 고객, 투자자 등의 시각). 많은 면에서,이러한 경계는 인간 관계와 정치에 의해 획정되어 있으며, 기술과 기능상의 고려에 기반한 것은 아니다

P.S.상세 정보는, ApplicationBoundary 참조

마이크로서비스 패턴

마이크로서비스 아키텍처 패턴은, 단일 애플리케이션을 일련의 소형 서비스로 분해하여 개발하는 방법이다. 각 소형 서비스는 자체 프로세스에서 실행되며, 경량급 메커니즘 (일반적으로 HTTP 리소스 지향 API) 을 통해 통신한다. 이러한 서비스는 비즈니스 기능을 둘러싸고 구축되며, 완전히 자동화된 배포 메커니즘에 의해 독립적으로 배포되며, 다른 언어로 기술할 수 있고, 다른 데이터 저장 기술을 사용할 수 있으며, 최소한의 집중 관리만 필요하다

이러한 이점에 의해, 마이크로서비스 패턴은 과거 수년 동안 매우 인기가 되었지만, 분산 비용의 증가, 일관성의 약화, 및 조작 관리상의 성숙도 요구 등의 대가도随之而来한다

P.S.상세 정보는, 마이크로서비스 아키텍처 (Microservices) 참조

Serverless 아키텍처

Serverless 아키텍처는, 제 3 자 BaaS(Backend as a Service) 서비스를 포함하며, FaaS(Functions as a Service) 플랫폼에서 호스트되는 일시적인 컨테이너에서 실행되는 커스텀 코드를 포함하는 애플리케이션 설계이다. 이러한 사상과 싱글 페이지 애플리케이션 등의 관련 사상을 운용함으로써, 이 아키텍처는 전통적인 항상 실행되고 있는 서버 측 컴포넌트의 대부분의 수요를 소멸한다

Serverless 아키텍처는 운영 비용, 복잡함, 엔지니어링 딜리버리 사이클을 대폭으로 삭감하는 데 도움이 되지만, 대가는 서플라이어에 대한 의존의 증가와 상대적으로 미성숙한 서포트 서비스이다

P.S.상세 정보는, 버클리 연구자들眼中的 Serverless Computing, Serverless Architectures 참조

마이크로 프런트엔드 패턴

프런트엔드 개발을 잘 수행하는 것은 어렵고, 프런트엔드 개발을 확장하여 여러 팀이 동시에大而 복잡한 제품을 처리할 수 있도록 하는 것은 더욱 어렵다

마이크로 프런트엔드 패턴은 최근 출현한, 프런트엔드 전체를 많은 관리하기 쉬운 작은 조각으로 분해하여, 프런트엔드 팀의 효율을 향상시키는 유행 트렌드이다

P.S.상세 정보는, Micro Frontends 참조

GUI 아키텍처

최초의 폼加 컨트롤에서, 후년의 MVC, MVP 등의 패턴까지, UI 아키텍처도不断에 진화하고 있다

P.S.상세 정보는, GUI Architectures 참조

표현 - 영역 로직 - 데이터分层

정보가 풍부한 프로그램에 있어, 가장 일반적인 모듈화 방법은 3 층으로 나누는 것이다:

• 표현층 (UI)

• 영역 로직층 (또는 비즈니스 로직층이라고 부름)

• 데이터 액세스층

따라서, Web 애플리케이션은 HTTP 리クエスト를 처리하고 HTML 을 렌더링하는 Web 층, 검증과 계산을 포함하는 비즈니스 로직층, 및 데이터베이스 또는 원격 서비스로 영속화 데이터를 관리하는 데이터 액세스층으로 나누어지는 것이 자주 있다:

分层의 최대의 이점은관심 범위를 좁히는것으로, 이들 3 개의 부분을 개별적으로 고려할 수 있다. 모듈 경계를 확립했기 때문에, 다른 구현으로 전환하는 영향 범위가 비교적 작아지고, 독립적으로 테스트하기 쉬워진다

P.S.상세 정보는, Presentation Domain Data Layering 참조

四.기업 아키텍처

애플리케이션 아키텍처는 어떤 형식적인 개념적 애플리케이션 경계 내의 아키텍처에 초점을 맞추지만, 기업 아키텍처는 기업 전체를 조망하는 아키텍처이다. 기업 조직은 일반적으로 너무 커서, 모든 소프트웨어를 응집 방식으로 분할할 수 없기 때문에, 각각이 많은 코드베이스를 가진 팀을 조정할 필요가 있다. 이러한 팀들은 서로 독립적으로 개발하며, 자금과 사용자도 독립적으로 운용한다

기업 아키텍처의 많은 내용은어떤中心化 조정이 가치 있는가, 및 조정은 어떤 형식을 취해야 하는가에 관한 것이다. 하나의 극단적인 상황은中心化 아키텍처 분할로, 기업 하의 각 소프트웨어 시스템의 모든 아키텍처 결정을 승인할 필요가 있다. 이 분할은 결정 속도를 늦추고, 광범위한 시스템 조합 내의 다양한 문제를 진정으로 이해할 수 없으며, 결정 불력으로 이어진다. 또 하나의 ���단은 완전히 조정이 없어, 팀의 중복 작업, 다른 시스템 간의 상호 운용 불가, 팀 간의 스킬 육성과 교차 학습의 부재로 이어진다

이에 대해, 구속적인 제어를 수행하기보다는, 권한을 하방하고, 동시에 국소 결정을 가능한 한 강화하며, 관여하는 실제 비용을 최소한으로 억제해야 한다

기업 아키텍트를 개발 팀에 참가시키다

기업 아키텍처 그룹은 일반적으로 일상 개발과 분리되어 있어, 이에 의해 그들의 개발 작업에 대한 인식이 시대遅れ가 되고, 개발 팀도 전 회사의 광범위한 시각에서 보고 있지 않다. 따라서, 기업 아키텍트는 개발 팀에 참가함으로써 효율을 향상할 수 있을지도 모른다

P.S.상세 정보는, Enterprise Architects Join the Team 참조

린 기업における 기업 아키텍트의 역할 변화

기업이 애자일 사고를 채용할 때, 기업 아키텍처는 소실하지 않지만, 기업 아키텍트의 역할은 변화한다:

• 기업 아키텍트는 선택을 수행하지 않게 되고, 대신 타인이 올바른 결정을 수행하는 것을 지원하며, 이후 이러한 정보를 전파한다

• 기업 아키텍트는 여전히 비전을 형성할 필요가 있지만, 이후 팀 간에 다리를架设하고, 학습 커뮤니티를 구축한다

• 기업 아키텍트는 팀과 파트너십을 구축하고, 성장 속에서 새로운 방법을 탐색하며 상호 학습한다

P.S.상세 정보는, The Role of an Enterprise Architect in a Lean Enterprise 참조

제품 패턴은 프로젝트 패턴에 승하다

프로젝트 패턴은, 소프트웨어 프로젝트에 따라 자금 투입과 소프트웨어 개발을 조직화하는 유행 방식이다. 작업을 일시적인, 구현만 담당하는 팀으로 조직화하고, 비즈니스 시나리오에서 예상되는 특정 수익에 의해 자금 제공된다

제품 패턴은 대신 영속적인, 구상·구현·운행을 담당하는 팀으로 전환하고, 지속적으로 존재하는 비즈니스 문제를 해결한다. 제품 패턴은 팀이 신속하게 방향을 조정하고, 엔드 투 엔드의 사이클 시간을 삭감하며, 단 사이클 이터레이션을 통해 실제 수익을 검증하고, 동시에 소프트웨어 아키텍처의 완전성을 유지하여 그 장기 유효성을 보증하는 것을 가능하게 한다

P.S.상세 정보는, Products Over Projects 참조

아키텍트의 책무

많은 대규모 조직의 IT 부문과 결정권을 가진 고층 사이에는 많은 층이隔开되어 있어, 이 또한 비즈니스와 디지털 전략과 전략을 실시하는 중요한 작업을 분리하고 있다

따라서, 아키텍트의 주요한 책무는顶层에서 기실까지의 엘리베이터를 타고, 디지털 작업을 서포트할 필요가 있는 모든 곳에서 정지하는 것이다: 소프트웨어 생산을 자동화하고, 전기 결정을 최소한으로 억제하며, 기술 진화와 동시에 조직에 영향을 준다

P.S.상세 정보는, The Architect Elevator — Visiting the upper floors 참조

참고 자료

• Software Architecture Guide