비즈니스·서비스·애플리케이션·데이터·플랫폼·인프라

한 화면 뒤에는 여러 종류의 책임이 있다

고객이 주문 버튼을 누르면 화면 하나만 움직이는 것처럼 보인다. 그러나 회사는 무엇을 팔지 정하고, 서비스는 고객이 얻을 결과를 약속하며, 애플리케이션은 주문 규칙을 실행한다. 데이터는 주문 사실을 남기고, 플랫폼은 프로그램이 공통 기능을 쓰게 하며, 인프라는 계산·통신·저장 자원을 제공한다. 이 책임들을 한 덩어리로 부르면 장애 원인과 변경 책임을 찾기 어렵다.

층을 나누는 목적은 조직도를 외우는 것이 아니다. 사용자 가치가 아래쪽 기술 자원까지 어떻게 이어지고, 아래쪽 실패가 위쪽 결과를 어떻게 깨뜨리는지 추적하는 것이다.

먼저 되짚기: 각 층도 시스템이다

앞 절에서 시스템은 목적을 위해 상호작용하는 요소의 결합이라고 했다. 이제 각 층을 더 큰 디지털 서비스 안의 하위시스템으로 보고, 각자의 목적·입력·출력·상태와 층 사이 경계의 약속을 확인한다. 이 절은 그 시스템 관점을 층별 책임에 적용한다.

이 교재에서 사용하는 여섯 책임 관점

이 교재의 디지털 서비스 계층은 가치에서 자원까지의 책임을 비즈니스·서비스·애플리케이션·데이터·플랫폼·인프라로 나눈 관점이다. 모든 표준이나 제품이 반드시 이 여섯 층으로 구성된다는 뜻은 아니다. 여기서 층은 물리적으로 포개진 상자가 아니라 서로 다른 질문과 책임을 분리한 관점이다.

• 비즈니스 층은 왜 이 일을 하며 어떤 가치·정책·성과를 원하는지 정한다.
• 서비스 층은 사용자가 어떤 결과를 어떤 품질로 받는지 정한다.
• 애플리케이션 층은 그 결과를 만드는 업무 규칙과 처리 흐름을 실행한다.
• 데이터 층은 처리에 필요한 사실의 의미·구조·품질·수명을 관리한다.
• 플랫폼 층은 여러 애플리케이션이 공통으로 쓰는 실행·배포·관찰 기능을 제공한다.
• 인프라 층은 계산장치·기억장치·저장장치·네트워크 같은 자원을 제공한다.

한 제품이 여러 층의 책임을 함께 구현할 수도 있다. 따라서 층은 제품 목록이 아니라 책임을 묻는 언어다. 예를 들어 애플리케이션이 플랫폼의 인증 기능을 직접 사용할 수 있으므로, 모든 호출이 데이터 층을 먼저 거쳐야 한다는 실행 규칙으로 읽지 않는다.

주문 약속과 결과를 책임별로 내려가고 올라가며 추적한다

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

여섯 책임 관점 사이에서 요구와 결과를 추적한다. 아래 방향은 목표에서 필요한 자원 조건으로, 위 방향은 관찰 결과에서 사용자 가치로의 추적이며 실제 요청의 필수 실행 순서가 아니다. 목적·정책, 품질·사용 흐름, 읽기·쓰기와 자원 요구를 내려보내고 매출·완료시간·오류·조회 결과·자원 상태를 올려 확인한다.

요청은 위에서 아래로만 흐르지 않는다. 인프라의 저장장치 지연은 플랫폼의 대기, 애플리케이션의 시간초과, 서비스의 주문 실패, 비즈니스의 매출 손실로 위로 전파된다. 반대로 “주문 확정은 2초 안에”라는 서비스 목표는 애플리케이션 처리시간, 데이터 조회시간, 플랫폼 용량, 인프라 자원 기준으로 내려가야 한다. 좋은 설계는 이 양방향 추적을 끊지 않는다.

층을 판별하는 질문

같은 대상도 질문에 따라 다른 층에서 본다. 데이터베이스 제품은 인프라 자원을 쓰는 플랫폼일 수 있고, 데이터 모델과 품질을 논할 때는 데이터 층의 구성요소다. 이름만으로 분류하지 말고 그 문장에서 맡은 책임으로 판별한다.

예를 들어 당일 배송을 시작하면서 “주문에는 배송희망일을 남긴다”는 정책을 추가한다고 하자. 비즈니스가 판매 약속과 추가 비용을 결정하고, 서비스가 고객에게 선택 가능한 날짜를 알려 주며, 애플리케이션이 날짜의 유효성을 검사한다. 데이터 담당은 날짜의 의미와 미입력 시 처리 방식을 정하고, 플랫폼 담당은 새 프로그램을 배포하며, 인프라 담당은 늘어난 요청을 처리할 자원이 있는지 확인한다. 변경 뒤에는 실제 주문 기록과 고객 완료시간을 다시 위로 올려 당일 배송 약속이 지켜졌는지 확인한다. 데이터 필드 하나를 추가한 결과라도 이 흐름을 따라가야 입력과 사용자 결과가 끊기지 않는다.

이제 저장장치 교체만 했는데 고객 주문 확정이 늦어진 상황을 생각해 보자. “인프라만 확인하면 된다”는 판단은 저장 지연이 플랫폼 대기와 애플리케이션 시간초과를 거쳐 서비스 결과에 전파되는 경로를 놓친다. 아래에서 위로 실제 지연 경로를 확인하고, 위에서 아래로 2초 확정 약속에 필요한 자원 기준을 다시 내려야 한다. 책임을 잘못 분류했다면 위 표의 제품명이 아니라 핵심 질문 열로 돌아가 어느 결과를 보려는지부터 고친다.

어디서 판단이 틀리는가

기술에서 바로 시작하는 실패는 “새 서버를 사자”처럼 어떤 서비스 결과를 개선할지 연결하지 않은 채 기술 대안을 먼저 제안하는 것이다. 먼저 사용자 결과와 비즈니스 목표를 적고 하위 계층에 필요한 능력을 구체화한다.

층 사이 책임 공백은 애플리케이션 팀이 데이터 품질을, 플랫폼 팀이 서비스 지연을 서로의 일이라고 여길 때 생긴다. 층 사이 입력·출력, 품질 기준, 실패 시 조치를 명시한다.

국소 최적화는 인프라 사용률을 높이느라 서비스 지연을 악화시키거나, 화면 응답만 빠르게 하고 실제 주문 확정을 늦춘다. 위쪽 결과와 아래쪽 자원 지표를 함께 본다.

제품과 층의 동일시는 제품 하나가 모든 책임을 해결한다고 믿게 한다. 제품이 제공하는 기능과 조직이 여전히 소유해야 할 데이터 의미·운영·성과 책임을 분리한다.

문제: 디지털 서비스 계층을 설명하고 변경 영향 분석에 적용하시오.

계층별 영향과 책임을 추적한 모범답안 보기

모범답안 축약본: 계층별 영향과 책임을 추적하라

디지털 서비스 계층은 가치와 실행자원을 비즈니스–서비스–애플리케이션–데이터–플랫폼–인프라의 책임 관점으로 나눈 것이다. 주문 당일 배송을 예로 들면 비즈니스층은 매출·고객 약속, 서비스층은 주문·배송 경험, 애플리케이션층은 주문처리 기능, 데이터층은 주문·재고의 의미와 품질, 플랫폼층은 배포·관측·메시징 공통능력, 인프라층은 계산·저장·통신 자원을 맡는다. 분석은 목표와 요구를 위에서 아래로 내리고, 처리상태·자원지표·서비스성과를 아래에서 위로 올려 추적한다. 어느 층을 제품명이나 조직명과 동일시하지 말고 입력·출력·품질기준·실패책임을 명시해야 한다. 데이터 모델 변경이라면 소비 애플리케이션, 플랫폼 배포, 인프라 용량뿐 아니라 서비스 약속과 비즈니스 성과까지 확인한다. 이 양방향 추적이 층 사이 책임 공백과 국소 최적화를 막는다.

30초 정리

1. 디지털 서비스 계층은 가치에서 자원까지의 책임을 비즈니스–서비스–애플리케이션–데이터–플랫폼–인프라로 나눈 관점이다.
2. 목표와 요구는 아래로, 상태와 성과는 위로 추적해야 한 층의 변경이 전체 결과에 미치는 영향을 알 수 있다.
3. 층은 제품명이나 조직도가 아니다. 어떤 질문과 책임을 맡는지로 구분한다.