205. 계층형 아키텍처 (Layered Architecture) - 관심사 분리 Presentation Business Data OSI 7계층 수직적 설계 의존성 제어 단방향 통신

핵심 인사이트: (204번 패턴의 제왕) 신입 개발자가 게시판 코드를 짰다. Button_Click() 함수 1개 안에 버튼 색깔 바꾸는 코드, SQL DB 비밀번호 뚫는 코드, 게시물 조회수 더하는 비즈니스 수학 코드가 1만 줄로 떡져서 짬뽕되어 있다. 1달 뒤 DB를 오라클에서 MySQL로 바꿨더니 버튼 색깔이 갑자기 빨간색으로 터져버렸다(미친 스파게티 의존성). "야! 화면 그리는 놈, 수학 계산하는 놈, DB 조작하는 놈을 한 방에 섞지 마! 3층짜리 빌딩을 세워! 3층엔 화면 그리는 놈(UI)만 살고, 2층엔 수학 계산하는 놈(비즈니스), 1층엔 지하 창고에서 DB 파오는 놈(데이터)만 가둬버려! 그리고 3층은 무조건 2층한테만 심부름시키고, 절대 1층으로 직접 뛰어 내려가지 못하게 층간 이동 철칙을 세워라!" 관심사 분리의 교과서이자 전 세계 웹 개발의 99%를 지배하는 뼈대, 계층형 아키텍처다.

Ⅰ. 단일 통짜 코드(Spaghetti)의 파멸

  • 기능이 섞여 있으면, 버튼 UI 하나 수정하려다 DB 접속 코드를 건드려 시스템이 마비됩니다.
  • 테스트를 하려 해도, 화면이 없으면 DB 코드만 따로 똑 떼어서 테스트할 수가 없어 개발 속도가 바닥을 칩니다.

Ⅱ. 계층형 아키텍처 (Layered Architecture)의 뼈대 🌟

  • 개념: 전체 시스템을 비슷한 역할을 하는 '관심사(Concern)' 단위로 찢어 여러 개의 층(Layer, 계층)으로 층층이 수직으로 쌓아 올린 아키텍처입니다.
  • OSI 7계층(942번)이 통신망을 7개 층으로 찢은 것처럼, 소프트웨어 코드도 보통 3~4개의 층으로 찢어 놓습니다.

Ⅲ. 고전적인 3계층 (3-Tier) 완벽 해부 🌟 핵심 기출 🌟

웹 프로그래밍(Spring, Django)을 켤 때 가장 먼저 만드는 3개의 폴더입니다.

1층 (최상단): 프레젠테이션 계층 (Presentation Layer) - "얼굴마담과 안내데스크"

  • 역할: 오직 사용자의 눈에 보이는 화면(UI)을 그리고, 마우스 클릭이나 키보드 입력(요청)을 받아내는 역할만 합니다. 브라우저, 모바일 앱 화면, HTML 껍데기가 여기 속합니다.
  • 금기: 여기서 절대로 "게시물 조회수 + 1" 같은 수학 계산이나 DB 비밀번호를 까보는 로직을 섞어 짜면 안 됩니다! 무조건 주문을 받아서 2층으로 토스만 합니다.

2층 (중간): 비즈니스 로직 계층 (Business Logic / Application Layer) - "핵심 두뇌"

  • 역할: 이 시스템이 존재하는 진짜 이유, 돈이 되는 핵심 알고리즘(수학 계산, 규칙, 검증)을 미친 듯이 처리하는 뇌입니다.
  • 예시: "고객이 입력한 아이디가 블랙리스트인지 검사해라", "장바구니 총액에서 쿠폰 10%를 깎아서 계산해라." 화면(1층)이 예쁘든 못생겼든 2층은 알 바 아닙니다. 오직 순수한 데이터 연산만 책임집니다.

3층 (최하단): 데이터 계층 (Data Access / Persistence Layer) - "지하 창고지기"

  • 역할: 2층(비즈니스 뇌)이 "야, 홍길동 계좌 잔액 내놔!"라고 시키면, 묻지도 따지지도 않고 지하 데이터베이스(DB) 창고의 자물쇠를 따고 쿼리(SQL)를 날려서 엑셀 데이터를 퍼 올려 2층으로 배달해 주는 순수 노가다 층입니다.
  • 효과: 나중에 DB가 오라클에서 MySQL로 바뀌어도? 1층과 2층 코드는 단 1줄도 안 고치고, 오직 이 3층 지하 창고지기 코드만 살짝 갈아 끼우면 완벽히 구동됩니다(완벽한 격리와 은닉).

Ⅳ. 계층형 아키텍처의 절대 제약(Constraints)과 장단점

이 룰을 깨는 순간 계층형을 쓰는 의미가 사라집니다.

  • 단방향 수직 하강 룰 (Strict Layering): 무조건 N층은 바로 밑의 N-1층한테만 부탁(호출)할 수 있습니다.

  • 3층(화면)이 2층(비즈니스)을 건너뛰고 바로 1층(DB)을 다이렉트로 호출하는 짓(Skip)은 보안과 유지보수를 개박살 내므로 절대 엄격히 금지됩니다. 역방향(1층이 2층 호출)도 절대 금지입니다.

  • 장점: **관심사 분리(Separation of Concerns)**로 인해 1층 UI 디자이너와 2층 백엔드 개발자가 완전히 병렬로 독립적으로 일할 수 있고, 층별로 따로따로 모의 테스트(Mocking)가 가능합니다.

  • 단점: 그냥 단순하게 1번 방에서 2번 방으로 데이터 하나 옮기면 끝날 일을, 굳이 3층 ➜ 2층 ➜ 1층을 멍청하게 다 징검다리로 거쳐야 하므로 덩치가 커질수록 퍼포먼스 딜레이(오버헤드)가 발생하고(싱크홀 현상), 코드가 무거워집니다.

📢 섹션 요약 비유: **계층형 아키텍처(Layered)**는 코드를 짬뽕으로 섞어놓은 난장판 포장마차를 **'철저한 계급이 나눠진 3층짜리 최고급 레스토랑'**으로 뜯어고친 것입니다. **1층(프레젠테이션 계층)**은 손님에게 미소를 지으며 메뉴판을 보여주고 주문만 딱 받아내는 '홀 서빙 웨이터'입니다. 웨이터는 절대 자기가 요리를 하지 않고 주문서만 2층으로 넘깁니다. **2층(비즈니스 로직 계층)**은 주문서를 보고 소스를 배합하고 고기를 완벽하게 굽는 '메인 셰프'입니다. 셰프는 홀에 손님이 100명이 왔든 예쁜 테이블이 깔렸든 밖은 안 보고 오직 요리(핵심 계산)만 미친 듯이 합니다. **3층(데이터 계층)**은 지하 냉동 창고에서 고기와 야채를 꺼내서 2층 셰프에게 가져다 바치는 '막내 보조(창고지기)'입니다. 웨이터(1층)가 셰프(2층)를 무시하고 다이렉트로 지하 창고(3층)에 가서 직접 고기를 꺼내오는 미친 짓(룰 위반)은 절대 금지됩니다. 손님이 테이블을 둥근 걸로 바꾸든(UI 변경), 창고 냉장고를 삼성에서 LG로 바꾸든(DB 변경), 중간의 셰프(비즈니스 뇌)는 1도 흔들림 없이 평화롭게 요리만 계속할 수 있게 지켜주는 궁극의 격리 뼈대 시스템입니다.