[개발서적] 아키텍트 첫걸음

1장 : 아키텍트가 하는일

아키텍트 정의

• 복잡한 구조물인 소프트웨어에서는 아키텍처의 적절한 설계가 무엇보다 중요하다. 이를 제대로 수행하기 위해서는 소프트웨어 개발 전반에 걸친 폭넓은 지식과 경험이 필요하며, 이런 역할을 전담하기 위한 전문 직종으로 아키텍트가 존재한다.

아키텍트의 주요 직무

• 기업의 비즈니스 목표와 IT전략을 효과적으로 연결하기 위한 최적의 기술 아키텍처를 설계하고 구현하는 일

아키텍트의 자질

1. 설계 능력과 코딩 능력
2. 추상화 능력
3. 비즈니스에 대한 이해
4. 호기심
5. 완벽주의보다는 합리주의

2장 : 소프트웨어 설계

소프트웨어 개발 프로세스의 전체구조

• 요구사항 분석 -> 설계 -> 구현, 테스트

설계 원칙(SOLID)

1. 단일 책임 원칙(Single Responsesibility Principle)
   클래스가 오직 하나의 명확한 역할을 가져야한다.
2. 개방-폐쇄 원칙(Open-Closed Principle)
   확장성과 관련이 깊으며, 기존 코드를 수정하지 않고도(폐쇄), 새로운 동작을 추가하여 확장할 수 있도록(개방) 설계하는데 활용되는 원칙이다.
3. 리스코프 치환 원칙(Liskov Substitution Principle)
   기본형(부모 클래스)을 사용하여 작성된 모든 프로그램이 프로그램의 동작을 변경하지 않고도 기본형을 파생형(자식 클래스)으로 치환 가능해야한다는 원칙이다.
4. 인터페이스 분리 원칙(Interface Segregation Principle)
   하나의 큰 인터페이스를 각 클라이언트가 실제로 필요로 하는 기능만 담아 더 작고 명확한 인터페이스들로 분리하자이다.
5. 의존성 역전 원칙(Dependency Inversion Principle)
   상위 모듈은 하위 모듈에 의존해서는 안된다. 두 모듈 모두 추상에 의존해야한다.
   추상은 구현의 세부 사항에 의존해서는 안된다. 구현의 세부 사항이 추상에 의존해야한다.

설계 실천 방법(clean code)

1. Cohesive(응집성) : 컴포넌트나 모듈에 포함된 구성 요소들이 기능적으로 서로 연관되고, 하나의 목적을 중심으로 정돈된 상태
2. Loosely Coupled(느슨한 결합) : 객체 지향 설계에서는 추상클래스와 인터페이스를 통해 구현
3. Encapsulated(캡슐화) : 클라이언트가 관심을 가질 필요가 없는 세부 사항을 숨기는 것을 의미
4. Assertive(단정적) : 필요한 데이터와 동작을 한 곳에 보유하고 있어, 객체가 다른 객체에 과도하게 의존하지 않고 자신의 책임을 다할 수 있는 상태
5. Nonredundate(비중복) : 동일한 코드가 여러 곳에서 중복되지 않도록 하는 것

설계 패턴

• 디자인 패턴 : GoF의 디자인 패턴으로 생성패턴, 구조패턴, 행동 패턴의 세가지로 분류되며, 총 23개의 패턴이 존재
• 아키텍처 스타일 : 소프트웨어 소스 코드의 구성 방식과 상호작용에 대한 포괄적인 구조
• 아키텍처 패턴 : 특정 문제를 해결하기 위한 구조적인 설계 방식

3장 : 아키텍처 설계

아키텍처 정의

시스템이 처한 환경 속에서 시스템의 요소, 관계, 그리고 설계와 발전의 원칙에 따라 구체화된 시스템의 기본 개념과 특성

아키텍처 드라이버
정의 : 시스템의 구조를 검토할 때 중요한 고려 사항이 되는 요구 사항
분류 : 제약, 품질 속성, 영향력 있는 기능 요구사항, 기타 영향

아키텍처 선정시 고려사항

1. 아키텍처 선정은 트레이드 오프 과정임을 인식
2. 아키텍처 패턴을 활용

애플리케이션 아키텍처 스타일

• 레이어드 아키텍처 파이프라인 아키테거, 마이크로커널 아키텍처

시스템 아키텍처 종류

• 모놀리식 아키텍처 vs 분산형 아키텍처
• 모놀리식 아키텍처 장단점

장점

• 소스코드의 관리, 빌드, 배포가 간편
• 시스템 전체를 대상으로 테스트하기 쉽다.
• 트랜잭션이 단일 애플리케이션 내에서 완료되므로, 정합성유지에 용이
• 기술 스택을 통일할 수 있어 IT거버너스적용, 즉 시스템 전반의 통합 관리 용이

단점

• 빌드와 배포에 시간이 많이 걸림
• 모듈과 컴포넌트 간 의존성이 복잡해져 거대한 진흙 덩어리 패턴에 빠지기 쉬우며, 이로 인해 유지보수성이 저하될 수 있음
• 작은 변경에도 전체 애플리케이션의 빌드와 배포가 필요
• 일부 기능 부하나 충돌로 인해 시스템 전체에 위험이 발생할 수 있음
• 스케일링이 어렵고, 특히 단일 데이터베이스에서 병목이 발생하기 쉬움
• 각 모듈 및 컴포넌트 구현에 필요한 라이브러리 사용으로 DLL 지옥이 발생하거나 종속성 오류가 생기기 쉬움
• 단일 기술 스택은 구현과 기술 도입 모두에 제약이 될 수 있음

분산형 아키텍처 장단점
장점

• 빌드 및 배포 시간이 짧음
• 서비스 단위로 돍립적인 배포가 가능하여 시스템의 어질리티가 높아짐
• 각 서비스의 소스 코드가 적어 유지보수하기 쉬움
• 부하가 큰 서비스만 선별적으로 확장할 수 있음
• 서비스별로 적합한 기술 스택과 데이터베이스를 사용할 수 있음
• 서비스별로 최적의 애플리케이션 아키텍처를 채택할 수 있음
• 서비스 단위로 재사용하기 쉬움
  단점
• 소스코드와 버전 관리가 복잡해짐
• 여러 서비스를 넘나드는 경우, 데이터 정합성을 보장하기 어려움
• 서비스 간 통신이 오버헤드 되어 응답 속도를 떨어뜨릴 수 있음
• 여러 서비스가 마스터 데이터를 공유하는 과정에서 동기화 등 관리 이슈가 생기기 쉬움
• 적절한 서비스 분할이 어렵고, 아키텍처 설계에 고도의 판단이 요구됨

분산형 아키텍처의 설계 패턴

• 서비스 기반 아키텍처 : 시스템을 구성하는 여러 서비스가 단일 데이터베이스를 공유하는것
• 마이크로서비스 아키텍처 : 독립적인 전용 데이터베이스를 가지며, 서비스 간 데이터는 완전히 분리

4장 : 아키텍처 구현

구현 단계에서 아키텍트의 역할

• 애플리케이션 기반 구축
• 애플리케이션 개발 플로 구축

개발 프로세스 표준화

• 문서 표준화 : 아키텍처 구현과 병행하여 문서 표준화를 진행하거나 아키텍처를 먼저 구현한 뒤 표준화된 문서가 개발에 적합한지 검증
• 기능 명세서 표준화
  - 유스케이스 다이어그램
  • 유스케이스 기술서
  • 유스케이스 기술서 작성시 핵심 고려사항
    1. 적절한 추상화 레벨에서 기술하는 것
    2. 사전 조건과 사후 조건은 시스템 외부에 있는 사용자가 인식할 수 있는 상태만 기술하고, 시스템 내부 상태는 포함하지 않는다.
    3. 사용자 인터페이스에 의존하는 표현을 피한다.
    4. 화면이나 장부의 개별 항목을 나열하지 않고, 정보의 청크 형태로 기술한다.
    5. 비즈니스 규칙이나 비즈니스 로직의 세부 사항은 기술하지 않는다.
    6. 사용자가 직접 처리할 수 없는 시스템적 예외는 기술하지 않지만, 사용자가 개입할 수 있는 예외 상황이라면 포함한다.

기능 명세서
1. 화면 전환도
2. 화면 레이아웃 정의( 각종 문서 서식의 레이아웃 포함)
3. 항목 정의
4. 화면 이벤트 정의
5. 로직 정의
- 설계서 표준화

유스케이스 중심의 아키텍처 구현

• 유스케이스 선정
• 유스케이스 구현

애플리케이션 기반 구현

• 애플리케이션 기반 공통 기능
• 인증
• 승인
• 세션 관리
• 오류 처리
• 로깅
• 보안
• 트랜잭션 제어
• 데이터베이스 접근

애플리케이션 개발 준비

• 개발자용 문서 정비
• 개발 규약
• 절차서 : 구현 과정에서 반복적으로 발생하는 작업 절차를 문서로 정리하여 공유함으로써 개발자와 팀의 업무 효율을 높이는 것을 목적으로 함
• 구현 참고 자료

구성 관리 및 CI/CD

• 구성 관리 : 소프트웨어 개발 프로젝트에서 생성되는 다양한 산출물을 관리 대상으로 실벽하고, 해당 산출물에 대한 변경 사항을 추적하는 일련의 프로세스를 의미
• CI/CD

5장 : 품질 보증과 테스트

아키텍트와 품질 보증을 위한 작업

• 품질 보증과 테스트
• 스프트 레프트 : 품질 보증 활동을 보다 이른 시점, 즉 소프트웨어 개발 초기 단계부터 숭행하면 결함을 조기에 발견하고 수정할 수 있어 이러한 비용 증가를 막는 것
• 테스트 유형
• 테스트 전략 : 소프트웨어를 고객과 사용자의 요구에 부합하는 품질 수준으로 완성하기 위해 어떤 테스트를 언제, 어떻게 수행할 것인지 그리고 프로젝트 자원을 어떻게 배분할지 등을 정하는 전반적인 정책 수립

기능 테스트 자동화

• 기능 테스트 자동화에서의 테스트 전략 : 테스트 피라미드가 대표적인 예
• 단위 테스트
  1. 테스트 입력값과 의존 객체 준비가 용이함
  2. 다양한 테스트 케이스를 간편하게 구성 가능
  3. 테스트 실행 시간이 짧음
  4. 테스트 실패 시 원인 파악이 빠름
• 통합 테스트
• E2E 테스트 : 사용자 기준으로 시스템 전체를 종합적으로 검증하는 과정
  1. 시스템 전체를 검증할 수 있음
  2. 테스트 준비에 시간이 많이 소요됨
  3. 사용자 이용을 위한 사전 준비에 많은 리소스 필요
  4. 세밀한 테스트 케이스 검증에는 적합하지 않음
  5. 테스트 실행 시간이 매우 김
  6. 테스트 실패 시 원인 파악이 어려움
• 테스트 전략 검토 시 고려사항

성능 테스트

• 성능 테스트 개요
• 단일 기능 성능 테스트
• 부하 테스트 : 업무 피크 시점에 시스템 전체가 정해진 성능 목표를 달성할 수 있는지 검증
• 장기 실행 테스트 : 시스템이 장시간 연속으로 ㅏ동되는 상황에서도 성능을 안정적으로 유지할 수 있는지 검증하는 테스트
• 확장성 테스트 : 시스템에 부하가 증가했을 때, 시스템을 확장함으로써 이에 잘 적을할 수 있는지를 검증하는 테스트

6장 : 아키텍트의 학습과 성장

아키텍트로 성장하려면

• 아키텍트의 인재상
  1. T형 인재 : 특정 분야의 깊은 전문성과 여러 분야에 대한 폭넓은 지식을 함께 갖춘 인재
  2. 파이형 인재 : 두 가지 핵심 전문 분야를 보유한 인재
• 성장의 길
  1. 기본 기술 습득

  기술 분야	목표 수준
  프로그래밍 언어	최소 한 가지 언어에 능통하여 타인을 지도할 수 있는 정도의 이해 필요 여러 언어를 실무에서 활용 가능한 수준
  웹 애플리케이션 설계 및 개발	웹 기술의 기본 원리와 웹 애플리케이션 서버 구조 이해 특정 웹 프레임워크의 특징을 파악하고, 표준 기능을 활용하거나 확장하여 공통 기능 개발 기능
  보안	웹 애플리케이션 개발에 필요한 기본적인 보안 지식 보유 관련 보안 대책을 적용 가능
  데이터베이스	RDBMS의 구조 이해를 바탕으로 효율적인 SQL문 작성 및 튜닝 가능 NoSQL등 비관계형 데이터베이스에 대한 기초 지식 보유
  객체지향 설계	객체지향 설계의 핵심 원칙과 실무 적용 방법에 대한 이해 상황에 따라 적절한 디자인 패턴 적용 가능
  프런트엔드	JavaScript,Dart 등의 언어로 프런트엔드 개발 가능 모던 프레임웤ㅡ 활용 역량 보유 SPA 개발 경험
  개발 프로세스	워터폴과 애자일 개발 프로세스의 개요 및 차이점에 대한 이해 스크럼등 애자일 방법론 실무 경험
  인프라	네트워크 및 운영체제에 대한 기본 지식 보유 PowerShell, bash 등을 이용한 쉘 스크립트 작성 가능
  클라우드	3대 클라우드 서비스 중 하나 이상의 환경에서 개발 경험 보유 주요 서비스에 대한 구조 및 활용 이해

  2. 아키텍팅 습득
  3. 업무 지식과 소프트 스킬 습득
• 일을 대하는 방식

효과적인 학습 방법

• 인풋
  1. 도서
  2. 교육 및 세미나
  3. 자격증 취득
  4. 기술 컨퍼런스와 개발자 행사
  5. SNS
• 아웃풋
  1. 독서 맵
  2. 샘플 코드 작성
  3. 기술 글 작성 및 공유
  4. 발표

좋은 책에서 배운다

• 추천 도서
• 애플리케이션 설계
• 아키텍처 설계
• 품질 보증과 테스트
• 독서법