본문 바로가기

CS Study44

[소프트웨어 아키텍처 101] Ch. 7 아키텍처 특성 범위 소프트웨어 아키텍처 세계에서는 전통적으로 아키텍처 특성의 범위를 시스템 레벨에 두는 것을 당연시했다. 예를 들어, 아키텍트가 확장성을 논할 때에는 일반적으로 전체 시스템의 확장성을 가리키는 것이다. 10년 전까지만 해도 거의 모든 시스템은 모놀리식이었으니 이것은 안전한 전제였지만, 현대적인 공학 기술의 등장과 마이크로서비스 등의 아키텍처 스타일이 가능해지면서 아키텍처 특성의 범위는 상당히 좁혀졌다. 이렇듯 소프트웨어 개발 생태계가 무서운 속도로 진화를 거듭하면서 기존에 당연하게 여겼던 공식도 서서히 퇴물로 전락하고 있다. 우리가 앞에서 살펴보았던 다양한 메트릭들은 사실 모두 코드에 관한 저수준의 세부만 밝힐 뿐, (특히 운영과 관련된) 아키텍처 특성에 영향을 미치는, (데이터베이스 같은) 코드베이스 외부.. 2024. 1. 11.
[소프트웨어 아키텍처 101] Ch.6 아키텍처 특성의 측정 및 거버넌스 1. 아키텍처 특성 측정 아키텍처 특성을 정의할 때 흔히 발생하는 문제들 물리학이 아니다 : 아키텍처 특성의 대부분은 의미가 모호하다. 정의가 너무 다양하다 : 부서마다 정의를 통일하기 전까지는 원활한 소통이 어렵다. 너무 복합적이다 : 바람직한 아키텍처 특성은 대부분 더 작은 다른 여러 특성들로 구성된다. 이 세 가지 문제는 아키텍처 특성을 객관적으로 정의하면 모두 해결된다. 1.1 운영적 측정 아키텍처 특성은 성능, 확장성처럼 비교적 정확하게 측정할 수 있는 것도 많지만, 팀 목표에 따라 그에 다른 해석은 미묘하게 갈릴 때가 많다. 성능의 여러 가지 맛 대부분의 프로젝트는 (웹 애플리케이션의 요청/응답 시간을 재는 것처럼) 일반적인 성능을 살펴보지만, 아키텍트와 데브옵스 엔지니어는 성능 예산을 책정하.. 2024. 1. 11.
[소프트웨어 아키텍처 101] Ch.5 아키텍처 특성 식별 1. 도메인 관심사에서 아키텍처 특성 도출 도메인 이해관계자와 협력해서 주요 아키텍처 특성을 정의하는 한 가지 팁은, 최종 목록을 가능한 한 짧게 하는 것이다. 아키텍처에서 가장 흔한 안티패턴 중 하나가, 모든 아키텍처 특성을 지원하는 제네릭 아키텍처를 설계하려는 것이다. 아키텍처 특성의 개수에 연연하지 말고 가급적 설계를 단순화하는게 좋다. 대부분의 아키텍처 특성은 핵심 도메인 이해관계자들의 의견을 듣고 도메인 관점에서 무엇이 중요한지 의견을 교환하면서 정리된다. 여기서 문제는 아키텍트와 도메인 이해관계자들이 서로 다른 언어로 말을 한다는 것이다. 예를 들어, 아키텍트는 확장성, 상호운용성, 내고장성, 학습성, 가용성을 운운하는데, 도메인 이해관계자는 인수 병합, 고객 만족, 출시 시점, 경쟁 우위를 .. 2024. 1. 5.
[소프트웨어 아키텍처 101] Ch4. 아키텍처 특성 정의 p. 89 소프트웨어 솔루션은 도메인 요구사항과 아키텍처 특성으로 구성된다. 💬정처기에서 공부했던 것을 연결해보면 '도메인 요구사항 = 기능 요구사항 / 아키텍처 특성 = 비기능 요구사항'인걸까? 아키텍처 특성의 기준 비도메인 설계 고려 사항을 명시한다. 설계의 구조적 측면에 영향을 미친다. 애플리케이션 성공에 (절대적으로) 중요하다. 아키텍처 특성 (일부) 목록 운영 아키텍처 특성 가용성(availability) 시스템이 얼마나 오랫동안 사용 가능해야 하나? 연속성(continuity) 재해 복구 능력 성능(performance) 스트레스 테스트, 피크 분석, 기능의 사용 빈도 분석, 필요 용량, 응답 시간 복구성(recoverability) 비즈니스 연속성 요구사항(e.g. 장애 발생 시 얼마나 신속.. 2024. 1. 5.
[소프트웨어 아키텍처 101] Ch.3 모듈 소프트웨어 아키텍처 용어의 95%는 '모듈성'의 이로움을 찬양하는 데 사용되고 있지만, 정작 모듈성을 어떻게 달성할지에 대해서는 별다른 얘기가 없다. - 글렌포드 J. 마이어스, 1978년 플랫폼마다 제공하는 코드 재사용 메커니즘은 제각각이지만, 연관된 코드를 '모듈'로 묶는 방법은 모두 지원한다. 본인이 선택한 개발 플랫폼에서 모듈성과 그것을 구현한 수많은 코드를 이해하는 것은 아키텍트에게 대단히 중요한 일이다. 우리가 아키텍처를 분석해야 할 (메트릭, 피트니스 함수, 시각화 등) 많은 도구가 바로 이 모듈성에 기반하기 때문이다. 모듈성은 일종의 구성 원리이다. 아키텍트가 대충 아무렇게나 조각들을 이어 붙여 시스템을 설계하면 무수한 난관에 봉착해 옴짝달싹 못 하는 시스템이 될 것이다. 물리학에 비유하자.. 2024. 1. 5.
[스터디] 직교성이란? 소프트웨어 아키텍처 101을 읽다보면 직교성이라는 단어가 종종 나온다. 이게 뭔지 감이 잘 오지 않아 따로 알아보았다. 직교성이란? 직교성은 기하학에서 빌려온 용어다. 그래프의 축과 같이 두 직선이 직각으로 만나는 경우 직교한다고 말한다. 벡터의 입장에서 보면, 두 개의 선은 독립적이다. ex) 함수 그래프 y = 5 는 x가 무슨 값이어도 영향을 받지 않는다. 컴퓨팅에서 이 용어는 결합도 줄이기를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않는다면 직교한다고 할 수 있다. 직교성의 장점 비직교적인 시스템은 본질적으로 변화와 조정을 하기가 복잡하다. 시스템의 컴포넌트들이 고도로 상호의존적인 경우, 특정 부분만 수정하는 방법이란 없다. "관련 없는 것들 간에 서로 영향이 없도록 하라." 컴포넌트.. 2024. 1. 4.

티스토리툴바