좋은 아키텍쳐 엔지니어가 되는 방법 - 아키텍쳐 프로세스 순서

아키텍쳐의 정의

• 아키텍쳐란 비즈니스 문제를 기술로 풀어내는 것을 말한다
• 즉, 비즈니스 자체를 이해해야 아키텍쳐를 구성할 수 있다는 의미이다
• 이 시스템을 왜 만드는 건지, 이 시스템에서 목표로 하는 것은 무엇인지를 이해할 줄 알아야 좋은 아키텍쳐를 구성할 수 있다
• 팀을 이해하고 수익 구조를 이해하고 비즈니스의 목표를 이해하고 디자인해야 함
• 아키텍쳐 엔지니어가 가지고 있어야할 능력
  1. 소통능력 : 아무리 아키텍쳐를 잘 구성했더라고 할 지라도 개발자들이 말을 안들으면 소용이 없음
  2. 추상화 능력 : 개념을 요약(추상화)해서 글로 이해가 쉽도록 표현할 수 있는 능력
  3. 비즈니스에 대한 이해
  4. 문제 정의 능력
  5. 플래닝 능력
  6. 기술에 대한 깊은 이해
  7. 코딩 능력 : 기본적으로 코드 구조, 쓰레드 구조를 이해할 수 있는 정도는 되어야 함
• 기술은 도구일 뿐, 기술에 매몰되지 말자
• 아키텍쳐의 정의는 비즈니스 요구사항을 만족하는 시스템을 구축하는 것이다
• 아키텍쳐 문서란 비지니스 요구 사항을 만족하는 시스템을 구축하기 위해서 전체 시스템에 대한 구조를 정의한 문서로, 시스템을 구성하는 컴포넌트와, 그 컴포넌트간의 관계, 그리고, 컴포넌트가 다루는 정보(데이타)를 정의
• 아키텍쳐에 정답은 없다. 팀의 수준에 맞게, 이해할 수 있는 수준으로, 그러나 모든 내용을 담아야 함
• 아키텍쳐 문서는 의사 소통을 위한 매개체일 뿐, 멋있는 다이어그램을 만들고 보여주는 용도가 아니다. 문서로 남기는 것이 중요하다.

아키텍쳐 설계 프로세스

• 아키텍쳐 설계 프로세스 중에 토가프(TOGAF) 아키텍쳐 프레임워크란 것이 있다

TOGAF 축소 버전

• 아키텍쳐 문서에 비즈니스 요구사항은 반드시 들어가야 한다
• 이 비즈니스가 뭘하는지? → 어떻게 돈을 버는지를 적어라
• 만약에 비즈니스 요구사항에 해당 비즈니스가 돈을 버는 구조가 아닌 경우, 예를 들어 고객문의와 같은 서비스인 경우에는? 어떻게 해야할까? → Q&A 때 물어봐야할 듯
• 설계 원칙 (Architecture Design Principal) : mysql? nosql? cloud? onpremise? 멀 써야할까? 이런 판단의 근거가 되는 것이 설계 원칙이다. 예를 들어 금융시스템에서는 데이터의 data consistency 데이터 일관성이 굉장히 중요하다. 만약에 인스타그램 같은 경우에는 scale ability 확장성이 가장 중요하다. 쇼핑몰 같은 경우에는 절대로 시스템이 죽어도 안되고 데이터가 유실되어도 안됨. 하지만 모든 것이 완벽한 디자인을 만들 순 없다. 우선순위를 정해서 만들어야 한다. 이 우선순위가 바로 설계 원칙이다
• 그 후에 시스템 설계를 들어감
  • 애플리케이셔 설계 : 유저 서버, 이미지 서버, 댓글 서버 그런 식으로 컴포넌트를 구성하는 단계
  • 솔루션 설계 : 이런 애플리케이션을 개발할 때 필요한 솔루션들 redis, nosql 이런 것들 등등
  • 하드웨어 : L4 스위치는 어떻게 할건지 하드웨어 장비는 어떻게 할것인지 등등 온프렘이면 10G를 쓸것인지 머 이런거
  • 데이터 아키텍쳐 : db 설계, 스키마 구조
• 시스템 설계에서 복잡한 시스템이 아닌 경우에는 애플리케이션 설계 정도만 해도 충분하다
• 간단한 시스템인 경우에는 아키텍쳐가 애플리케이션 설계 정도만 하고 나머지는 개발자에게 권한을 줘서 처리하거나 이런식으로 가능하지만, 전체 컴포넌트가 뭐가 있고 어떤 흐름이 있는지는 아키텍쳐 엔지니어가 잡아주는게 좋음
• 요즘 트렌드는 비즈니스 속도가 매우 빠르기 때문에 팀을 작게 역할별로 세분화하면서 기동성을 높이는 것이 트렌드이다.

레퍼런스 아키텍쳐

• 한마디로 베스트 프랙티스
• 아키텍쳐를 설계함에 있어서 참고해야할 아키텍쳐

• 엔터프라이스 : 그 회사만이 가지고 있는 아키텍쳐
• 인더스트리 : 그 업계 고유 아키텍쳐
  ex) 금융, 게임, 제조사
• 커먼 : 업종에 상관없이 어디에나 적용할 수 있는 아키텍쳐
  ex) MSA, MlOps, Data Lake of Big Data
• 인더스트리 = 엔터프라이스 + 커먼

비즈니스 아키텍쳐 설계 방법

• 서비스가 뭔지 그 서비스의 전체적인 구조
• 시장 현황과 차별화 전략이 가장 중요 → GTM 전략, 시장에서 어떻게 살아남을 것인지
• 비즈니스 로드맵에 따라 아키텍쳐 구성이 바뀔 수 있다. 어느 단계에서 어떻게 기능을 출시할 것이냐 → 로드맵이 짧다? 속도 지향적으로 설계
• 비즈니스 계획서에는 다음 4가지 항목이 반드시 들어가야 함

1. 비지니스 정의
2. 수익화 모델 정의
3. 시장 진입 전략
4. 시장 규모 및 차별화 전략

1. 비즈니스 서비스 모델의 정의

• Actor(누가)를 정해야 함
  예를 들어 인스타그램의 경우에는 1. 유저 2. 컨텐츠 제공자, 끝일까? 과연?
  좀 더 비즈니스 관점에서 생각을 해보아야한다. 인스타에 일상 공유만 하는 사람이 있을까? 아니다. 돈 벌려고 광고하는 사람들도 있다. 그러니 Actor에는 광고 플랫폼, 광고 영업 같은 것도 들어갈 수 있다는 것이다
• 항상 돈을 어떻게 벌 것인지를 생각해야 함 (다 돈 벌려고 하는 거니까!)

웹을 통해서 컨텐츠 미디어 서비스를 하는 서비스에 대한 모델 정의 예시

2. 시장 현황 분석

• 서비스를 기획을 했는데 이미 경쟁자들이 많다? 차별화 전략이 필요

1. Gartner Magic Quadrant와 Crunchbase, VC Info, 로켓펀치 또는 링크드인를 활용해서 선두주자 기업 확인
2. 해당 기업의 기능들이 무엇이 있는지, 수익 구조 모델은 어떻게 되어있는지 확인 → 그리고 그것들을 피해야 함
3. 상장사인 경우 : IR Report 확인 → 투자해준 회사들에게 실적을 보고 하는 리포트 를 확인하면서 해당 회사의 방향을 파악
   비상장사인 경우 : 로켓펀치, Crunchbase
4. 이런 방식으로 시장 규모를 파악할 수 있다
5. 잠재 고객 만나서 인터뷰하는 식으로 전략을 강화할 수도 있다
   (인터뷰 답변 내용들을 수치화할 수 있도록 구성하는 것이 중요, 예를 들어 20분이면 쓸래? 10분이면 쓸래? 5분이면 쓸래?)

• GTM 전략을 바꾸는 방법도 있다. 예를 들어 Webex와 같이 선두주자로 달리고 있는 서비스와 차별화를 두기 위해 b2b 서비스를 진행하고 있던 Webex와 달리 Zoom은 무료로 풀어서 b2c 선점하고 b2b로 넘어가게 만드는 전략을 사용했다
• 이런 식을 시장 조사를 통해 선두주자의 기능을 파악해서 기능의 차별화 또는 GTM 전략의 차별화를 두는 식으로 차별화를 만들 수 있다

2-1. 시장 현황 분석 기법 - Gartner Magic Quadrant

• Gartner Magic Quadrant : IT업체의 현 위치를 말해주는 지표

• x은 ‘비전의 완성도’를 나타내는데, 제품이 얼마나 많은 기능을 가지고 있고 다른 IT업체들에게 흐름을 따라잡도록 강요하는 혁신적 향상을 반영한다.
• y은 ‘실행 능력’을 나타내는데, 매출, 유통업자와 공급업자의 숫자와 품질, 직원 수와 엔지니어링, 판매, 지원, 기타 사업 부분등의 직원 비율등에 의해 결정된다.
• 오른쪽 상단의 사분면에 리더군(Leaders)이 위치하고, 오른쪽 하단에는 비전가군(Visionaries), 왼쪽 하단에는 틈새시장군(Niche), 왼쪽 상단에는 도전자군(Challengers)으로 분류할 수 있다

2-2. 시장 현황 분석 기법 - Venture Capital Information (벤처 캐피탈 정보)

• "Venture Capital"은 새로운 기업이나 기업의 성장을 지원하기 위해 자본을 제공하는 투자 기관입니다.
• 벤처 캐피탈의 정보는 다음과 같은 요소를 포함할 수 있습니다
  
  1. 투자 금액: 벤처 캐피탈이 기업에 투자한 금액
  2. 투자 라운드: 기업이 받은 투자가 시리즈 A, 시리즈 B 등과 같은 투자 라운드 중 어느 것에 해당하는지를 나타냄
  3. 투자한 기업들의 목록: 해당 벤처 캐피탈이 투자한 기업들의 목록과 각 기업에 대한 정보
  4. 성과 및 수익률: 벤처 캐피탈의 성과 및 투자한 기업의 성과와 함께, 투자자들에게 제공되는 수익률 등의 정보
• VC Info는 보통 투자자, 기업, 기업가, 그리고 산업 전문가들이 벤처 캐피탈의 활동을 이해하고 투자 결정을 내리는 데 도움을 주는 지표이지만 기업의 정보를 확인할 때 사용할 수 있다

2-3. 시장 현황 분석 기법 - 로켓펀치 (https://www.rocketpunch.com/) , Crunchbase (https://www.crunchbase.com/)

로켓펀치 - 비즈니스 네트워크

• 기업 정보 확인 사이트

• 이런식으로 투자 단계를 보면 어느정도 회사의 규모를 알 수 있다
• 시장 규모를 파악하자
• 이런 방식으로 잘하는 회사를 찾을 수 있다

3. 비즈니스 전략

• 돈은 어떻게 벌 것인지
• 차별화가 무엇인지
• 비즈니스 전략이 설계 원칙과 이어질 수도 있다

4. 주요 기능 정의

• 시스템에 대한 핵심 기능을 7개 또는 10~20개 정도로 간략하게 정의
• 누구나 이해할 수 있을 정도로 쉽게

• 주요 기능을 정의할 때는 사용자의 흐름에 따라 정리하는 것이 중요다

4-1. 사용자 스토리

잘 안보여서...ㅎ

• Feature Lv2는 나중에 아키텍쳐 하나 하나에 맵핑될 수 있다. 각각이 API 하나로 맵핑되는 경우도 있다. 그래서 어떻게 분류하느냐가 중요함
• Feature Lv1은 마이크로서비스 또는 카테고리 하나 하나에 맵핑될 수 있다.

5. 전체 시스템 아키텍쳐 정의

• 앞에서 사용자 스토리를 정의하면서 대략적으로 Feature들을 뽑아두었기 때문에 이제는 전체적인 아키텍쳐를 대략적으로 그린다
• 나중에 바뀌어도 됨
• 연동해야 할 대외 서비스들(금융 인증 또는 결제 서비스, 개인 인증 등등)을 어떻게 통합할 것인지 들어가면 좋음

6. 비즈니스 도메인 모델 (Business Domain Model)

• 도메인(업무) 중심적으로 표현
• 업무가 어떻게 돌아가는지 표현
• 예를 들어 콜센터 같은 경우에 콜센터 직원 → 해결 못함 → 정규직 엔지니어 → 해결 못함 → ... 와 같이 업무가 어떻게 돌아가는지를 표현

시스템 아키텍쳐의 설계

• 앞서 정의했던 비즈니스 요구 사항을 아키텍쳐 설계 원칙에 따라 설계하는데 이때 레퍼런스 아키텍쳐를 참고한다

0. 아키텍쳐 설계 원칙

• 비기능적인 설계 원칙이 주를 이룸
  ex) 비용, 시스템 안정성, 성능, 응답시간, 데이터 유실 등
• 3개 또는 7~15개 정도 작성
• 디자인 의사 결정에 있어서 판단을 내려야할 때 판단의 근거가 됨
• 현재 무엇을 필요로 하는지를 알아야 함
  • 비용이 중요해?
  • 확장성이 중요해?

0. 아키텍쳐 설계 시 주의 사항

• 아키텍쳐 문서를 만들기 위해서 설계를 하는게 아니라 소통 하기 위해서 하는 것이 아키텍쳐 설계
• 최종 아키텍쳐라는 것은 없다. 계속해서 진화 한다
  (Evolutionary architecture : 진화적 아키텍쳐)
• 오버 디자인 주의 (나중에 비지니스가 잘되면 그때 바꾸자) → 이게 왜 필요하고 합당한 이유를 설명할 수 있으면 OK
• 팀 전체가 아키텍쳐를 이해하고 있도록 만드는게 아키텍트의 역할
  ex) "전체 그림중에서 개발자 A씨의 역할은?"

1. 애플리케이션 아키텍쳐

• 컴포넌트 간의 추상적인 관계를 표현한 아키텍쳐이다
• 구성 요소 : 컴포넌트, 컴포넌트 간의 관계, 호출 순서, 통신 인터페이스
  • 정적 아키텍쳐 (Static Architecture)
    • 계층 모델
    • 컴포넌트 간의 관계
  • 동적 아키텍쳐 (Dynamic Architecture)
  • 인터페이스 정의서 (Interface Definition Spec)
  • 상세 아키텍쳐 (Detail Architecture)
• 큰 시스템일 경우에는 다 필요할 수도 있겠지만 보통은 다 하지는 않는다
• 하지만 꼭 해야하는 두가지는 동적 아키텍쳐와 상세 아키텍쳐는 꼭 해야한다

1-1. 정적 아키텍쳐 (Static Architecture)

• 컴포넌트들을 나열하는 것
• 계층 모델을 사용하여 표현 후에 각각을 컴포넌트로 표현하면 좀 더 수월하다
• 다음 예시를 보자

계층 모델로 표현

계층모델을 Break Down하여 정리

• 컴포넌트를 몇개로 나누어야 하는지의 기준은 업무를 진행할 팀원들을 봐야 한다
• 업무와 팀의 구조를 보고 디자인해야 한다
• 보통 Level 0 아니면 Level 1에서 끝난다. Level 2까지 넘어가면 너무 많아져서 핸들링이 힘들어짐 (큰 시스템에서는 어쩔 수 없음)

1-2. 동적 아키텍쳐 (Dynamic Architecture)

• 동적 아키텍쳐는 이런 식으로 앞에서 정의한 사용자 스토리에서 각 기능별로 하나씩 나와야 한다
• 7개의 기능이 있으면 7개가 나와야 한다
• 예를 들어 포스팅하는 기능이 있다고 한다면 그 하나의 기능에 대해서 다음과 같은 아키텍쳐가 나와야 한다

• 즉, 하나의 시나리오에서 각 컴포넌트들이 어떻게 상호작용을 하는지 나타내는 것이 동적 아키텍쳐이다
• 일종의 시퀀스 다이어그램이라고 볼 수 있다. 하지만 상호작용 부분을 더욱 시각화하기 위해 컴포넌트 다이어그램을 이용할 수 있다
• 필요시 스테레오 타입을 넣던가, 아니면 경우에 따라 예를 들어 구조가 너무 간단한 경우에는 솔루션 아키텍쳐에 들어갈 부분들을 넣을 수도 있다 → 항상 flexible하게!

1-3. 상세 아키텍쳐 (Detail Architecture)

• 특정 기술을 사용해야 하는 경우에 사용
• 예를 들어 REST API를 JWT 토큰 방식으로 인증을 하는데 JWT 토큰은 어떤 방식으로 구현할 것인지에 대한 디테일한 가이드

1-4. 인터페이스 정의서 (Interface Definition Spec)

• 컴포넌트 간의 어떻게 통신을 하는지 정의
• REST API 같은 경우에는 그냥 REST API Spec 정도로 끝나는 경우가 많다
• 그럼 어느 경우에 쓰는가?
  1. 메세지 큐와 같은 비동기 방식 때 사용, 왜냐하면 비동기 방식 때 메세지를 처리하는 방식이 여러가지가 있기 때문
  2. 대외 시스템 연동이 있는 경우 : 전문 포맷을 맞춰야 하기 때문에 필요
     ex) 카카오페이 연동, NICE 신용 시스템 연동

Rabbit MQ에서 정의된 MEP 양식  •메세지 전달 방식 정의 (aka. Message Exchange Pattern. MEP)

2. 테크니컬 아키텍쳐

2-1. 하드웨어 아키텍쳐 / 네트워크 아키텍쳐 / 클라우드 아키텍쳐

• 하드웨어 스펙 디자인
• 온프레미스를 사용한다면 필요

하드웨어 아키텍쳐

네트워크 아키텍쳐

클라우드 아키텍쳐

3. 솔루션 아키텍쳐

• 마스터 슬레이브 구조로 할 건지 클러스터링 구조를 할 것인지, 로드밸런서 붙여서 static 기능 써서 세션 관리한다던지와 같은 것이 솔루션 아키텍쳐이다
• 데이타 베이스, 미들웨어등의 구성과 배포 구조 정의
• ※ 특히 클러스터링,로드 밸런싱, HA 구조 등에 대한 정의

4. 데이터 아키텍쳐

• 시스템에 저장되는 데이타에 대한 아키텍쳐 정의
• 데이타 구조
• 저장 장소 및 솔루션
• 보안 처리 아키텍쳐 (암호화등)
• 데이타 생명 주기 관리 (생성, 백업, 폐기까지의 정책)

📢 아키텍쳐 디자인 프로세스 총정리

1. 사용자 스토리 작성 → User Stroy가 기능에 맵핑, 카테고리별로 묶이는 경우도 생김.
2. 컴포넌트 구분 → 업무와 팀을 보고 컴포넌트를 구분
3. 사용자 스토리에 따른 각 기능들마다 동적 아키텍쳐 작성 → 그런 기능들 하나하나가 REST API 구현에 맵핑될 수 있음
4. Optional) 외부 연동 또는 비동기 호출일 경우에 인터페이스 정의서 작성
5. Optional) Detailed Architecture

아키텍쳐 의사 결정 템플릿 Architecture Decision (aka. AD)

• 아키텍쳐 디자인한 것이 운영팀이나 개발팀과 협의가 안되는 경우가 생길 수 있다
• 그럴 경우에는 기본적으로 판단 근거를 아키텍쳐 설계 원칙을 근거로 판단을 내리며 된다
• 그래도 충돌이 발생할 경우에는 의사 결정 템플릿을 활용해보자

• 의사 결정 템플릿은 계속 기록을 하고 보관하고 있어야 한다
• 그래야 추후에 발뺌하는 문제를 막을 수 있다...

번외) 글로벌 아키텍쳐에서 고려해야할 것

• 서버 리전을 선택할 때 항상 규제를 생각해야 한다
• 예를 들어 중국은 내부에 서버를 따로 두어야 하고 미국은 유럽과 서버 둘 다 서버를 둘 수 있다
• 사실 서버를 하나만 두어도 전세계 서비스가 가능하다. 160ms 정도 걸린다. 실시간 세션 게임 같은 경우가 아니고서야 일반적인 경우에는 문제가 없는 속도이다. latency에 너무 목매이지 않아도 됨. 하지만 그럼에도 서버를 여러 리전에 나누는 이유? 규제 때문에 아니면 클라우드 같은 경우에는 리전마다 인스턴스 비용이 다르기 때문에 비용적인 문제 때문일 수도 있다
• 그럼 유럽, 미국, 중국에 서버를 두었는데 만약에 유럽 사용자가 미국을 출장을 간다면? 데이터를 미국 서버로 옮겨야 하나...? 아니다. 실시간 세션 게임이 아니고서는 큰문제가 없기 때문에 그냥 두어도 latency에 문제가 없다. 즉, DB replication 같은걸 할 필요가 없다.

Regional Hierarchy(하이라키) 구조

• US를 메인으로 두고 EU, CH, Singapore를 Regional Center로 두고 각각의 API 서버 로그를 US로 보내면 US에서는 Big Data 또는 ML 모델 트레이닝을 한다 → 이런 비대칭적인 구조를 Regional Hierarchy(하이라키) 구조라고 부름
• 여기서 국가마다 규제에 따라 한단계 더 나아가는 구조를 가질 수 있다
• 예를 들어 한국에서는 위치정보는 한국 내부에 두어야한다는 규제가 있기 때문에 edge 서버를 따로 만들어서 위치 정보만 한국에다가 저장하는 것이다