응용구조의 설계

⭐ 아엔 Aen (개발자지망생)·2026년 1월 14일

데브코스

목록 보기

121/131

응용 소프트웨어 아키텍처 설계, 한 번에 이해하기

기능은 다 되는데 코드가 스파게티처럼 엉켜서 고치기 무서운 경험, 한 번쯤 있을 거다. 처음부터 구조를 잘 잡아두면 나중에 기능 추가도 쉽고, 버그 찾기도 쉽고, 팀원이 봐도 이해가 빠르다. 그게 바로 아키텍처 설계다. 핵심부터 한 줄로 정리하면 이렇다.

응용 소프트웨어 아키텍처 = 소프트웨어를 구성하는 컴포넌트들을 어떻게 나누고, 어떻게 연결할지에 대한 큰 그림

쉽게 비유하면

도시 설계라고 생각하면 됨! 주거지·상업지·공업지를 구역별로 나누고, 도로로 연결하는 게 도시 설계다. 이 구역 나누기 없이 집·공장·마트를 막 지으면 나중에 교통 지옥이 되고 확장도 못 한다.

아키텍처도 똑같다. 기능들을 역할별로 구역(레이어·모듈)으로 나누고, 그 사이에 규칙(인터페이스)을 만들어서 연결한다. 처음엔 귀찮아 보여도, 서비스가 커질수록 이 구조가 있고 없고의 차이가 엄청나게 벌어지는 것 같음!

자세히

왜 아키텍처가 중요하냐

변경이 쉬워짐 — 한 모듈 바꿔도 다른 곳에 영향이 최소화됨
테스트가 쉬워짐 — 역할이 분리돼 있으면 단위 테스트 짜기 쉬움
협업이 쉬워짐 — 팀원마다 담당 영역이 명확해짐
확장이 쉬워짐 — 기능 추가할 때 어디에 뭘 넣어야 할지 바로 보임

대표 아키텍처 패턴들

1. 레이어드 아키텍처 (Layered Architecture)

가장 기본적이고 많이 쓰이는 구조. 역할별로 층을 나눈다.

[ Presentation Layer ]  ← 화면, API 엔드포인트
        ↓
[ Business Layer    ]  ← 핵심 비즈니스 로직
        ↓
[ Data Layer        ]  ← DB 접근, 데이터 처리

위 → 아래 방향으로만 의존함. 아래 층이 위 층을 모르게 하는 게 핵심
비유: 햄버거. 빵·패티·야채가 층층이 쌓여 있고, 각 층이 자기 역할만 함
백엔드에서 Controller → Service → Repository 구조가 딱 이거다!

2. MVC (Model - View - Controller)

웹 프레임워크에서 제일 많이 보이는 패턴.

Model      ← 데이터, 비즈니스 로직
View       ← 화면 (UI)
Controller ← 요청 받아서 Model에 시키고 View에 전달

비유: 식당. Controller는 웨이터(주문 받아서 전달), Model은 주방(요리), View는 음식이 담긴 접시(화면)
Express, Spring, Django 등 대부분 백엔드 프레임워크가 MVC 기반

3. 클린 아키텍처 (Clean Architecture)

Robert C. Martin(Uncle Bob)이 제안한 구조. 핵심 비즈니스 로직을 외부(DB·프레임워크·UI)로부터 완전히 독립시키는 게 목표다.

         [외부 세계]
    DB / 프레임워크 / UI
           ↓
      [인터페이스 어댑터]
           ↓
      [유스케이스(비즈니스 로직)]
           ↓
        [엔티티(핵심 도메인)]

안쪽 원은 바깥쪽 원을 모름. 의존성이 항상 안쪽으로만 향함
이렇게 하면 DB를 PostgreSQL → MongoDB로 바꿔도 핵심 로직은 건드릴 필요 없음
처음엔 복잡해 보이지만, 대규모 프로젝트에서 진가를 발휘 같음!

4. 마이크로서비스 아키텍처 (MSA)

하나의 큰 앱 대신, 기능별로 독립된 작은 서비스들로 쪼개는 구조.

[모놀리식]               [마이크로서비스]
하나의 큰 서버    →     유저 서비스
                        결제 서비스
                        알림 서비스
                        (각각 독립 배포)

장점: 서비스별로 독립 배포·확장 가능. 하나 터져도 전체 다운 안 됨
단점: 서비스 간 통신 복잡, 관리 부담 큼. 작은 팀엔 오히려 독이 될 수 있음
비유: 편의점 하나(모놀리식) vs 전문점들이 모인 쇼핑몰(MSA)

5. 이벤트 드리븐 아키텍처 (Event-Driven)

컴포넌트들이 직접 호출하지 않고, 이벤트를 발행/구독하는 방식으로 소통.

결제 완료 이벤트 발행
  → 알림 서비스가 구독 → 문자 발송
  → 포인트 서비스가 구독 → 포인트 적립
  → 주문 서비스가 구독 → 주문 상태 업데이트

서비스끼리 직접 연결이 없어서 느슨하게 결합됨(Loose Coupling)
비유: 라디오 방송. 방송국이 송출하면 채널 맞춘 사람이 각자 받아 씀

프론트엔드 아키텍처도 있다

백엔드만의 이야기가 아님. 프론트엔드도 구조를 잡아야 한다.

아토믹 디자인 — 컴포넌트를 Atoms→Molecules→Organisms→Templates→Pages로 계층화
FSD (Feature-Sliced Design) — 기능(Feature) 단위로 폴더를 나누는 방식. 대규모 프론트엔드에서 많이 씀

실사용 예

백엔드를 Express + TypeScript로 짠다고 하면, 레이어드 아키텍처 기준으로 이런 구조가 된다.

src/
├── routes/         ← Presentation Layer (엔드포인트 정의)
├── controllers/    ← 요청 받아서 서비스에 넘김
├── services/       ← Business Layer (핵심 로직)
├── repositories/   ← Data Layer (DB 쿼리)
└── models/         ← 데이터 구조 정의

라우터가 요청을 받음 → 컨트롤러가 파싱 → 서비스에서 로직 처리 → 레포지토리로 DB 접근 → 결과 반환
나중에 DB를 바꾸고 싶으면 repositories/만 수정하면 됨. 서비스 로직은 그대로

프론트엔드에서 OpenPoll 같은 규모가 커지면 FSD가 빛을 발한다. 페이지가 20개 넘어가면 기능별로 폴더 안 나눠두면 어디에 뭐가 있는지 찾기 힘들어지기 시작함. "이 컴포넌트가 투표 기능 건지 유저 기능 건지"가 폴더 구조만 봐도 바로 보이게 되는 거다!

한 방 정리

아키텍처	핵심 아이디어	언제
레이어드	역할별 층으로 나누기	백엔드 기본 구조
MVC	Model·View·Controller 분리	대부분 웹 프레임워크
클린 아키텍처	핵심 로직을 외부로부터 독립	대규모·장기 프로젝트
MSA	기능별 독립 서비스로 쪼개기	대형 서비스·큰 팀
이벤트 드리븐	이벤트 발행/구독으로 느슨하게 연결	서비스 간 결합 줄일 때
아토믹 디자인 / FSD	컴포넌트·기능 단위 계층화	프론트엔드