[SW Engineering] 06. 아키텍쳐 설계(Architectural Design)

건물을 지을 때 설계도가 가장 중요하듯, 소프트웨어 개발에서도 아키텍처 설계는 시스템의 성패를 좌우하는 핵심 단계입니다. 이번 포스팅에서는 아키텍처 설계의 정의와 중요성, 그리고 실무에서 자주 쓰이는 주요 아키텍처 패턴들을 정리해 봅니다.

1. 아키텍처 설계란? (Architectural Design)

아키텍처 설계는 소프트웨어 시스템을 어떻게 조직할지 이해하고, 그 전체적인 구조(Overall structure)를 설계하는 과정입니다.

• 역할: 디자인과 요구사항 공학 사이의 결정적인 연결 고리(Critical link) 역할을 합니다
• 핵심 활동: 시스템의 주요 구조적 컴포넌트와 그들 간의 관계를 식별합니다
• 애자일(Agile)에서의 위치: 일반적으로 애자일 프로세스에서도 초기 단계에 전체적인 시스템 아키텍처를 설계하는 것을 인정합니다.
  • 이유: 나중에 아키텍처를 리팩토링(Refactoring)하려면 시스템의 너무 많은 컴포넌트에 영향을 주기 때문에 비용이 매우 비싸기 때문입니다.

1) 아키텍처의 추상화 레벨

• Architecture in the small: 개별 프로그램(Program) 수준. 하나의 프로그램을 어떻게 컴포넌트로 분해할지 고민합니다 .
• Architecture in the large: 복잡한 엔터프라이즈 시스템 수준. 여러 다른 시스템, 프로그램 등을 포함하며, 서로 다른 회사가 관리하는 분산 환경일 수도 있습니다 .

2) 명시적 아키텍처의 장점 (Advantages of explicit architecture)

1. 이해관계자 의사소통 (Stakeholder communication): 시스템을 논의할 때 중심 초점이 됩니다.
2. 시스템 분석 (System analysis): 비기능적 요구사항(성능, 보안 등)을 만족시킬 수 있는지 초기에 분석 가능합니다.
3. 대규모 재사용 (Large-scale reuse): 아키텍처 자체를 여러 시스템에 재사용하거나 제품 라인(Product-line) 아키텍처를 개발할 수 있습니다.

 

2. 아키텍처 설계 결정과 시스템 특성

아키텍처 설계는 창의적인 프로세스이지만, 모든 설계 과정에서 공통적으로 결정해야 할 사항들이 있습니다.

• 예시: 어떤 일반적인 애플리케이션 아키텍처를 템플릿으로 쓸 것인가? 어떤 아키텍처 패턴을 적용할 것인가?

1) 아키텍처와 비기능적 요구사항 (System Characteristics)

특정 비기능적 요구사항(Non-functional Requirement)을 만족시키기 위해 아키텍처를 전략적으로 선택해야 합니다. 이는 곧 유저의 기대인 Validation과도 직접적으로 영향을 미쳐 프로젝트 성공여부를 결정하기도 합니다.

특성	아키텍처 전략
성능 (Performance)	중요한 오퍼레이션을 국소화(Localise)하고 통신을 최소화합니다. 작은 컴포넌트보다는 큰(Large-grain) 컴포넌트를 사용합니다.
보안 (Security)	레이어드(Layered) 아키텍처를 사용하여 중요한 자산을 가장 안쪽 레이어에 둡니다.
안전 (Safety)	안전에 중요한 기능을 소수의 서브시스템에 집중시킵니다.
가용성 (Availability)	중복(Redundant) 컴포넌트를 포함하여 장애 허용(Fault tolerance) 메커니즘을 만듭니다.
유지보수성 (Maintainable)	변경하기 쉽도록 작고(Fine-grain) 교체 가능한 컴포넌트를 사용합니다.

 

 

3. 아키텍처 패턴 (Architectural Patterns)

아키텍처 패턴은 좋은 설계 관행(Good design practice)을 추상화하여 공유하고 재사용할 수 있게 만든 것입니다. 구체적인 설계도가 아니라, 다양한 방식으로 구현될 수 있는 템플릿입니다.

1) MVC 패턴 (Model-View-Controller)

사용자 인터페이스(View)와 데이터 처리(Model)를 분리하는 가장 유명한 패턴입니다.

• 구성 요소:
  • Model: 애플리케이션의 상태(데이터)와 비즈니스 로직을 캡슐화합니다 .
  • View: 모델을 화면에 렌더링하고 사용자 이벤트를 컨트롤러에 보냅니다 .
  • Controller: 사용자 행동(키보드, 마우스 등)을 모델 업데이트로 매핑하고 뷰를 선택합니다.
• 웹 애플리케이션 예시: 브라우저(View)가 HTTP 요청을 보내면 컨트롤러가 처리하고, 모델(DB)을 업데이트한 뒤, 동적으로 페이지(View)를 생성해 응답합니다.

조금 더 구체적인 예시를 볼까요?

시나리오: 맛집 웨이팅 앱 (캐치테이블/테이블링)

 

캐치 테이블에서는 다음과 같이 "사용자의 입력을 받아(Controller), 데이터를 처리하고(Model), 화면을 그립니다.(View)."

• Controller (주문 접수원): 사용자가 앱에서 '웨이팅 등록하기' 버튼을 클릭합니다. 컨트롤러는 이 요청을 받아 모델에게 "대기열에 사람 한 명 추가해줘"라고 명령하고, 등록 성공 후 보여줄 화면(View)을 선택합니다 .
• Model (주방장/장부): 현재 대기 팀 수(5팀), 예상 대기 시간(30분) 같은 핵심 데이터와 '대기 번호 발급 로직'을 가지고 있습니다. 컨트롤러의 명령을 받아 대기 명단에 데이터를 추가하고 상태를 갱신합니다 .
• View (메뉴판/전광판): 모델의 데이터가 변경되면, 화면에 "현재 대기 6팀, 예상 대기 시간 40분"이라는 텍스트와 UI를 그려서 사용자에게 보여줍니다.

 

 

2) 계층형 아키텍처 (Layered Architecture)

시스템을 여러 계층(Layer)으로 나누어 구성합니다. 각 계층은 관련된 서비스 집합을 제공합니다.

• 특징: 서브시스템의 점진적 개발을 지원합니다. 어떤 레이어의 인터페이스가 바뀌어도 인접한 레이어에만 영향을 줍니다.
• 일반적인 구조 예시:
  1. 사용자 인터페이스 (User Interface)
  2. UI 관리 / 인증 및 인가 (Authentication)
  3. 핵심 비즈니스 로직 (Core business logic)
  4. 시스템 지원 (OS, Database 등).

계층형 아키텍쳐에서는 "각 층은 자기 할 일만 하고, 바로 아래층이나 위층 하고만 대화"하여 계층간 독립성을 유지합니다.

시나리오: 모바일 뱅킹 앱(토스/카카오뱅크)

뱅킹 앱처럼 각 계층 역할이 명확히 구분되어야 하는 서비스에서는 다음처럼 계층간 독립성을 유지합니다.

• 1계층 (User Interface): 사용자가 '송금하기' 화면에서 금액을 입력하고 버튼을 누르는 UI 부분입니다.
• 2계층 (Authentication/UI Management): 사용자가 로그인한 상태인지, 비밀번호가 맞는지 인증합니다. UI에서 넘어온 입력값이 숫자가 맞는지 검사합니다.
• 3계층 (Core Business Logic): 실제 송금 로직이 돌아갑니다. "잔액이 송금액보다 많은지 확인"하고, "A계좌에서 빼서 B계좌로 더하는" 핵심 업무를 수행합니다.
• 4계층 (System Support/Database): 실제 은행 데이터베이스(DB)에 접속해서 잔액 데이터를 수정하고 저장합니다.
• 특징: DB 구조(4계층)가 바뀌어도 송금 버튼 디자인(1계층)은 바꿀 필요가 없습니다.

 

3) 리포지토리 아키텍처 (Repository Architecture)

서브시스템 간에 데이터를 교환할 때 사용합니다.

• 방식: 중앙 데이터베이스(Repository)에 공유 데이터를 두고 모든 서브시스템이 접근하게 합니다. (반대 방식: 각자가 데이터를 가지고 명시적으로 주고받기)
• 장점: 대량의 데이터를 공유해야 할 때 가장 효율적입니다.
• 예시: IDE(통합 개발 환경)에서 프로젝트 리포지토리를 중심으로 에디터, 컴파일러, UML 툴들이 데이터를 공유하는 구조.

레포지토리 아키텍쳐는 중앙 저장소에 자료를 두고 여러 사람이 필요할 때 각자 꺼내 쓰는 상황에서 유리합니다.

시나리오: 협업 문서 도구 (깃허브/구글 닥스/노션)

 

• 중앙 리포지토리 (Central Repository): 우리가 작성 중인 문서 데이터 그 자체(주로 GitHub Repository)가 저장된 중앙 서버입니다. 모든 데이터는 여기에 모여 있습니다.
• 서브시스템 A (에디터): 내가 글자를 타이핑하면 중앙 저장소의 내용을 수정합니다.
• 서브시스템 B (댓글 알림 봇): 중앙 저장소에 새로운 댓글 데이터가 들어오면, 이를 감지해서 사용자에게 알림을 보냅니다.
• 서브시스템 C (PDF 변환기): 사용자가 다운로드를 요청하면, 중앙 저장소의 데이터를 가져와서 PDF 파일로 만들어줍니다.
• 특징: 알림 봇과 PDF 변환기는 서로 직접 대화하지 않고, 오직 중앙 저장소의 데이터만 바라보고 일합니다.

 

4) 클라이언트-서버 아키텍처 (Client-Server Architecture)

데이터와 처리를 여러 컴포넌트에 분산시키는 모델입니다.

• 구성:
  • 서버 (Servers): 프린팅, 데이터 관리 등 특정 서비스를 제공하는 독립적인 컴포넌트.
  • 클라이언트 (Clients): 서비스를 호출하는 사용자.
  • 네트워크: 클라이언트가 서버에 접속할 수 있게 함.
• 예시: 영화 라이브러리 시스템 (비디오 서버, 사진 서버, 웹 서버 등 분리).

시나리오: 넷플릭스/유튜브 (영상 스트리밍 서비스)

 

대용량 스트리밍 서비스처럼 대규모 데이터를 제공해야 하는 상황에서는 클라이언트-서버 아키텍쳐가 유리합니다.

• Client (손님): 내 스마트폰이나 TV 앱입니다. "영화 틀어줘", "검색해줘"라고 요청만 합니다 .
• Server 1 (비디오 서버): 실제 영화 영상 파일만 전문적으로 스트리밍해 줍니다.
• Server 2 (회원/추천 서버): 내 시청 기록을 분석해서 "좋아할 만한 영화" 목록 데이터를 보내줍니다.
• Server 3 (이미지 서버): 영화 포스터 썸네일 사진만 전송해 줍니다.
• 특징: 영상 서버가 터져도(장애), 로그인이나 영화 목록 검색은 잘 될 수 있습니다(분산 처리).

 

5) 파이프 앤 필터 아키텍처 (Pipe and Filter)

입력을 받아 처리(Transformation)하고 출력을 내보내는 과정을 연결한 구조입니다35.

• 특징: 유닉스(UNIX) 쉘 명령어가 대표적입니다. (예: cat log | grep error | wc).
• 활용: 데이터 처리 시스템(Batch processing)에 주로 쓰이며, 즉각적인 반응이 필요한 상호작용(Interactive) 시스템에는 적합하지 않습니다.
• 예시: 청구서 처리 시스템 (송장 읽기 -> 결제 식별 -> 영수증 발행).

시나리오: 인스타그램 사진 필터 / 영수증 처리

 

공장 컨베이어 벨트처럼, 입력이 주어지면 가공되어 완성품이 나오는 상황에서 파이프 앤 필터 아키텍쳐가 유리합니다.

• Input (입력): 사용자가 찍은 원본 사진 데이터가 들어옵니다.
• Filter 1 (보정): 사진의 밝기와 대비를 조절하는 필터를 거칩니다.
• Filter 2 (효과): 흑백 효과나 빈티지 효과를 입히는 필터를 거칩니다.
• Filter 3 (워터마크): 사진 구석에 날짜나 로고를 박는 필터를 거칩니다.
• Output (출력): 짠! 인스타 감성의 완성된 사진이 나옵니다.
• 특징: 중간에 '스티커 붙이기' 단계를 추가하고 싶으면, 파이프 중간에 그 필터만 쏙 끼워 넣으면 됩니다.

 

정리

아키텍처 설계는 시스템의 품질(성능, 보안, 유지보수성 등)을 결정짓는 초기 단계의 핵심 활동입니다. 요구사항에 맞춰 MVC, Layered, Repository 등 적절한 아키텍처 패턴을 선정하고 적용하는 것이 중요합니다. 다음 포스팅에서는 이를 바탕으로 한 상세 설계와 구현(Design and Implementation)에 대해 다루어 보겠습니다.