201. 소프트웨어 아키텍처 (Software Architecture) 정의 - 시스템 뼈대 골격 구성 요소 상호작용 의사결정 비기능적 요구사항(품질 속성) 설계

핵심 인사이트: (149번 요구사항 심화) 집을 지을 때 대충 시멘트부터 바르는 바보는 없다. 건축가가 '설계도(청사진)'를 쫙 펴놓고 "여긴 기둥 4개를 철골로 세우고, 이쪽 벽은 뚫어서 유리창을 달아라"라고 '큰 그림'의 뼈대부터 잡는다. 이걸 안 하고 벽부터 올리면 지진 났을 때 집이 통째로 폭삭 주저앉는다. 소프트웨어도 똑같다! "야! 100만 줄짜리 코드 짜기 전에, '이 시스템은 웹 서버 2대를 앞에 두고, 뒤에 오라클 DB를 꽂은 다음, 둘 사이를 JSON 데이터로 통신하게 묶어라'라는 최상위 수준의 거대한 구조(뼈대)부터 무조건 확정 지어!! 한 번 뼈대가 콘크리트로 굳어지면 나중에 절대 못 고치니까 며칠 밤을 새워서라도 신중하게 결정해!" 코딩 이전에 시스템의 운명을 결정짓는 절대 골격, 소프트웨어 아키텍처다.

Ⅰ. 소프트웨어 아키텍처(Software Architecture)의 개념 🌟

  • 개념: 시스템을 구성하는 커다란 서브시스템 및 컴포넌트(Component)들이 무엇인지 정의하고, 그 컴포넌트들이 서로 어떻게 관계를 맺고 데이터를 주고받는지 상호작용(Connector)을 명시하며, 전체 시스템의 진화와 발전을 이끄는 **'최상위 수준의 구조적 설계도(뼈대)'**입니다.
  • 코드 한 줄 한 줄(For 문, if 문)을 어떻게 짤지 고민하는 상세 설계가 아닙니다! 숲 전체의 모양과 산맥의 배치를 그리는 작업입니다.

Ⅱ. 아키텍처가 시스템의 명운을 가르는 3대 이유 🌟 핵심 🌟

왜 이 뼈대를 잡는 데 수석 아키텍트(최고 연봉자)가 1달씩 고민을 할까요?

1. 비기능적 요구사항 (품질 속성)의 달성 🌟 기출 🌟

  • 고객이 "버튼 누르면 화면 띄워줘(기능)"라고 한 건 대학생도 짭니다.
  • 비기능적 요구사항: "블랙프라이데이 때 동시 접속 100만 명이 몰려도 1초도 안 멈추게(가용성) 해주고, 해커가 털어도 안 뚫리게(보안성) 해주며, 내년에 서버 100대 더 꽂으면 속도가 100배로 빨라지게(확장성) 해줘!"
  • 이런 끔찍한 성능/품질 목표는 코딩(함수)을 잘한다고 해결되는 게 아닙니다. 애초에 뼈대를 MSA(마이크로서비스)로 짜느냐, DB를 이중화하느냐 하는 아키텍처의 거시적 설계 구조가 100% 결정지어 버립니다.

2. 이해관계자(Stakeholder) 간의 의사소통 도구

  • 고객(돈 주는 사람), 기획자, 개발자, 네트워크 엔지니어가 모였습니다. 백날 말로 해봐야 서로 못 알아먹습니다.
  • 아키텍트가 화이트보드에 네모 박스(웹 서버, DB)와 화살표(통신망)를 쭉쭉 그려서 보여주면 모두가 고개를 끄덕입니다. 수백만 줄의 코드를 한 장의 그림으로 압축하여 합의를 이끌어내는 마법의 공용어입니다.

3. 가장 초기적이고 치명적인 의사결정 (Early Design Decision)

  • 처음에 단독 서버(모놀리식)로 아키텍처 뼈대를 잡고 개발을 1년 동안 진행했습니다.
  • 오픈 한 달 전에 "아 차라리 도커 컨테이너로 쪼개서 클라우드에 올릴 걸 그랬나?" 하고 후회해 봤자, 아키텍처(뼈대)를 뜯어고치려면 1년 동안 짠 코드를 전부 쓰레기통에 버리고 0부터 다시 짜야 합니다.
  • 뼈대는 한 번 굳으면 수정 비용이 기하급수적으로 폭발하기 때문에, 프로젝트 초기(요구사항 직후)에 가장 신중하게 설계되어야 합니다.

Ⅲ. 아키텍처 설계의 기본 원리 (4대 천왕)

이전 문서들에서 배운 좋은 코딩의 철학이 그대로 들어갑니다.

  1. 198번 추상화 (Abstraction): 복잡한 찌끄러기 다 빼고 거대한 박스(컴포넌트)로만 숲을 그려라.
  2. 199번 정보 은닉 (Information Hiding): 박스 안의 비밀(DB 종류)을 딴 박스(UI)가 모르게 숨겨라.
  3. 200번 분할과 정복 (Divide & Conquer): 100층짜리 거대 시스템을 웹 박스, WAS 박스, DB 박스로 찢어서 해결해라.
  4. 191번 느슨한 결합 (Loose Coupling): 박스끼리 화살표(통신)를 최소한으로 연결해 의존성을 끊어라.

📢 섹션 요약 비유: 소프트웨어 아키텍처는 거대한 초고층 빌딩을 올리기 전 설계사가 그리는 **'강철 H빔 골조 설계도(청사진)'**입니다. 각 방의 벽지 색깔을 무슨 색으로 바를지, 형광등 스위치를 어디 달지 고민하는 것(상세 코딩)이 아닙니다. 이 설계도의 가장 큰 목적은 "진도 8.0의 지진(트래픽 폭주)이 와도 건물이 무너지지 않게 하려면 1층에 강철 기둥을 몇 개 박아야 하는가?(비기능적 품질 보장)"를 결정하는 것입니다. 만약 이 뼈대 설계를 대충 하고 건물을 50층까지 다 지어버렸는데, 뒤늦게 "아, 기둥 1개 빼고 콘크리트로 바꿀까?"라고 해봤자 이미 굳어버린 시멘트 때문에 건물을 폭파하고 다시 짓는 수밖에 없습니다(초기 의사결정의 치명성). 코드 한 줄 한 줄의 늪에 빠지기 전에, 헬기를 타고 하늘 위에서 시스템 전체의 산맥과 강물의 흐름을 지휘하여 수백 명의 개발자가 길을 잃지 않게 만드는 프로젝트의 나침반이자 콘크리트 뼈대입니다.