533. 비즈니스 능력에 따른 분해 (Decompose by Business Capability)

핵심 인사이트 (3줄 요약)

1. 본질: 마이크로서비스를 쪼갤 때(Decomposition), 데이터베이스 테이블 구조(명사)나 기술적 층(Layer)을 보고 칼질하는 멍청한 짓을 버리고, 오직 회사가 돈을 버는 현실 세계의 '조직도(부서)'와 '비즈니스 목적(동사)'을 기준으로 시스템을 세로로 쫙쫙 썰어버리는 직관적인 1차원적 아키텍처 해부술이다.
2. 가치: 코드의 생김새(Architecture)와 회사 조직의 생김새(Organization)를 1:1 쌍둥이로 일치시킨다. 주문 부서 기획자가 "이거 바꿔주세요"라고 할 때, 오직 [주문 서비스] 코드 깡통 딱 하나만 1분 만에 뜯어고쳐 배포하면 끝나는, 부서 간의 눈치 보기(의존성)를 100% 멸망시키는 극한의 애자일(Agile) 속도전을 선사한다.
3. 융합: 기술보다 비즈니스를 상위에 두는 **DDD(도메인 주도 설계)**의 사상과 맞닿아 있으며, **콘웨이의 법칙(Conway's Law)**을 역이용하여 "조직을 쪼개는 대로 코드가 찢어진다"는 진리를 입증하는 크로스 펑셔널(Cross-functional) 스쿼드(Squad) 팀 빌딩의 뼈대로 완벽히 융합된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: 쿠팡이라는 1,000만 줄짜리 앱 덩어리(모놀리식)가 있다. 이 코드를 어떻게 50개의 마이크로서비스(MSA) 깡통으로 예쁘게 자를까? Decompose by Business Capability 방식은 회사 로비를 쓱 둘러보는 데서 시작한다. "아하, 우리 회사는 [상품 전시팀], [결제/재무팀], [배송팀], [CS팀]으로 부서가 4개네?" ➡ 그럼 코드 깡통도 똑같이 딱 4개(상품 서비스, 결제 서비스, 배송 서비스, CS 서비스)로 무식하고 투명하게 썰어버린다. 이것이 비즈니스 능력 기반 분해다.

• 필요성: 옛날 아키텍트들은 코드를 '기술'로 가로로 썰었다(Layered Architecture). [UI 껍데기 통짜 서버] + [백엔드 로직 통짜 서버] + [DB 통짜 서버]. 기획자가 "결제 버튼 색깔이랑 로직 좀 바꿔주세요" 했다. UI 개발자, 백엔드 개발자, DB 관리자 3명이 회의실에 모여 일정을 맞추고 3개의 서버를 동시에 껐다 켜면서 밤새 배포하다가 코드가 엉켜 터졌다(병목 지옥). **"야! 그냥 1개의 비즈니스(결제)를 위해 화면, 백엔드, DB를 하나의 캡슐 통짜로 묶어서 니들(결제팀)끼리 마음대로 북치고 장구치게 찢어주자!"**라는 피눈물 나는 협업의 한계가 이 수직 분해 사상을 태동시켰다.

• 💡 비유: 비즈니스 분해는 대형 식당의 **'코너별 뷔페 푸드코트 공사'**와 똑같습니다. 옛날 식당(기술 분해)은 재료 썰기(DB), 끓이기(백엔드), 접시에 담기(프론트)로 방을 나눴습니다. 짬뽕 하나 만들려면 세 방을 요리가 릴레이로 왔다 갔다 하며 10분이 걸립니다. 비즈니스 능력 분해는 아예 **[중식 코너], [일식 코너], [양식 코너]**로 식당을 수직으로 쫙 찢어버립니다. 중식 코너 안에 재료(DB), 불(백엔드), 그릇(프론트)이 다 들어있습니다. 짬뽕(비즈니스 요구)이 들어오면 오직 중식 코너 요리사 혼자 1분 만에 볶아서 탕! 하고 내놓습니다. 다른 코너 요리사는 쳐다볼 필요도 없는 미친 효율성입니다.

• 등장 배경 및 발전 과정:

  1. 수평적 계층화(Layered)의 저주: 코드를 MVC(Model, View, Controller) 계층으로만 나누던 시절, 기능 1개를 추가하려면 3개의 계층 폴더를 다 들쑤시며 커밋해야 했다.
  2. 콘웨이의 법칙(Conway's law)의 각성 (1960s~현재): "소프트웨어 구조는 그 회사의 소통(조직) 구조를 따라간다"는 멜빈 콘웨이의 명언이 50년 만에 재평가되었다. 코드를 찢으려면 조직부터 찢어야 한다는 깨달음이 번졌다.
  3. 스포티파이(Spotify) 스쿼드(Squad) 모델의 대박: 단순한 부서를 넘어, 기획자+프론트+백엔드+DBA 5명을 1조(스쿼드)로 묶고 "니들은 이제 '결제 비즈니스' 하나만 평생 먹여 살려!" 라며 권한을 100% 밀어주는 독립 부대 단위의 애자일(Agile) 혁명이 폭발하며 분해의 절대 표준이 되었다.

• 📢 섹션 요약 비유: 기술 분해(가로 썰기)가 **'케이크를 빵 층, 딸기 층, 크림 층으로 가로로 썰어 접시에 담아주는 미친 짓'**이라면, 비즈니스 능력 분해(세로 썰기)는 **'우리가 아는 평범한 케이크 조각(빵+딸기+크림이 1조각에 다 들어있음)으로 세로로 예쁘게 썰어 한 사람에게 완벽한 한 입(기능)을 주는 것'**입니다. 손님은 딸기(DB)만 먹고 싶은 게 아니라, 빵과 크림이 합쳐진 완벽한 '케이크 조각(비즈니스 기능)'을 원하기 때문입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 비즈니스 능력 분해 아키텍처 (어떻게 도면을 찢는가?)

아키텍트는 코드를 열기 전에, 회사 사장님의 **'경영 전략 문서'**부터 펴본다.

1. 최상위 비즈니스 능력 식별 (Level 1)
   • 쇼핑몰 회사의 돈 버는 핵심 능력을 덩어리 짓는다.
   • ➡ [고객 획득], [주문 처리], [물류 배송], [사후 CS]
2. 하위 세부 능력 분해 (Level 2~3)
   • 덩어리를 1번 더 깐깐하게 마이크로(Micro)하게 쪼갠다.
   • [주문 처리] ➡ [장바구니 관리], [결제 승인], [영수증 발급]
3. 아키텍처 1:1 매핑 (Code ➡ Capability)
   • 찢어놓은 저 하위 능력(기능) 1개당 ➡ 무조건 도커(Docker) 컨테이너 1개(Spring Boot 서버)와 전용 데이터베이스(DB) 1개를 세트로 묶어 쾅! 찍어낸다.
   • 결과: Payment Service (결제 서버), Cart Service (장바구니 서버) 탄생.

2. 완벽한 자율성 (Autonomy)과 십자군 조직 (Cross-functional Team)

이 분해법의 궁극적인 흑마법은 코드가 아니라 '인간(개발자)'의 뇌 구조를 개조하는 데 있다.

• 문제: 결제 서버(Payment)를 만들었는데, 프론트(화면) 개발팀은 10층에 있고 백엔드 개발팀은 11층에 있다. 둘이 API 맞추려면 슬랙(Slack)으로 싸우고 회의 날짜 잡아야 한다(블로킹 지연).

• 해결 (스쿼드 조직 융합): 비즈니스 분해를 완수하려면 반드시 조직을 부수어야 한다! 10층 프론트 1명, 11층 백엔드 2명, DBA 1명을 아예 짐 싸서 한 책상(결제 스쿼드 팀)에 모아 앉힌다.

• 파괴력: 사장님이 "결제 버튼 파란색으로 고치고 DB에 로깅 1줄 더 남겨!" 지시한다. 같은 책상에 앉은 프론트+백엔드+DBA 4명이 모니터 보며 5분 만에 코드를 쓱싹 맞춘 뒤 젠킨스(CI)로 배포 버튼을 쾅 누른다. 타 부서 결재? 눈치? 통신 딜레이? 0(Zero)다. 이것이 1일 100회 배포를 가능케 하는 십자군 부대(Cross-functional Team)의 위엄이다.

• 📢 섹션 요약 비유: 부서가 나뉜 낡은 회사는 **'육군, 해군, 공군이 따로 노는 오합지졸'**입니다. 적(버그)을 잡으려면 육군이 무전 쳐서 해군 부르고 결재받느라 적은 다 도망갑니다. 비즈니스 능력 분해(스쿼드)는 **'네이비씰(특수 부대)'**입니다. 보트 1대(1개 서비스) 안에 저격수, 폭파병, 통신병(프론트, 백엔드, DB)이 한 팀으로 다 타 있습니다. 적이 보이면 본부(타 부서)에 허락받을 필요 없이 그 보트 안에서 0.1초 만에 쏘고 빠지는 극한의 치고 빠지기(Agility) 살상력입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 비즈니스 분해 vs 도메인(DDD) 분해 (532장 심화 비교)

마이크로서비스를 찢는 두 가지 양대 산맥. 초보 아키텍트들이 100% 헷갈려 죽는 개념.

과목 융합 관점

• 소프트웨어 공학 (콘웨이의 법칙, Conway's Law 역이용): 콘웨이는 "시스템 구조는 그 회사의 소통 구조를 그대로 닮는다"고 했다. 아키텍트는 이를 역이용하는 **'역 콘웨이 법칙(Inverse Conway Maneuver)'**을 발동한다. 내가 코드를 결제, 배송 2개 서버로 예쁘게 찢고 싶다면? 코드를 만지기 전에, 사장님실로 쳐들어가서 "개발 1팀, 2팀을 다 해체하고 결제팀, 배송팀으로 책상 위치부터 옮겨주십시오!"라고 **조직 개편(Organization Restructure)**부터 멱살 잡고 때려 버린다. 사람을 찢어놓으면 신기하게도 소프트웨어 코드는 그들의 소통 단절에 맞춰 100% 완벽한 2개의 마이크로서비스로 자연스럽게 갈라져 찢어진다. (소프트웨어 아키텍처는 곧 조직 공학이다.)

• 클라우드 / 데브옵스 (파이프라인의 극한 분리): 코드를 비즈니스로 찢었다면 인프라도 찢어야 한다. 결제 서버와 배송 서버를 똑같은 젠킨스(CI) 빌드 봇 하나에 묶어두면 안티패턴이다. 아키텍트는 결제팀 전용 깃허브 저장소(Repo 1개), 결제팀 전용 AWS 계정(Account 1개), 결제팀 전용 CI/CD 봇을 100% 물리적으로 복제해서 따로 쥐여준다. 결제팀이 새벽 3시에 서버를 100대 배포하며 놀아도, 배송팀은 다음 날 아침까지 결제팀이 무슨 짓을 했는지 1도 모르는 철저한 인프라 사일로(Silo) 구축이 진정한 독립성의 완결이다.

• 📢 섹션 요약 비유: 비즈니스 능력 분해는 **'이혼 부부의 완벽한 재산 분할'**과 같습니다. 이혼(분해)했는데도 차 1대(공용 DB나 젠킨스)를 같이 쓰면서 "월수금은 네가 타, 화목토는 내가 탈게" 하면 매일 피 터지게 싸웁니다(의존성 폭발). 진정한 분해는 돈을 절반으로 찢어 각자 차를 따로 사고(DB 분리, 파이프라인 독립), 상대방이 그 차로 절벽을 박든(장애) 여행을 가든(배포) 평생 남남처럼 알 바 아니게 살아가는 완벽한 무관심(Loose Coupling)을 선물하는 것입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 기술 스택(Layer)으로 코드를 찢었다가 맞이한 커뮤니케이션 헬(Hell): 낡은 회사가 "우리도 MSA 한다!"라며 거대한 서버를 3개로 찢었다. [Front-end 서버 1대], [Back-end API 서버 1대], [DB Server 1대]. 기능 1개(예: 장바구니 추가)를 만들 때마다, 프론트엔드 팀장이 백엔드 팀장한테 "API 열어주세요" 슬랙(Slack)을 쏘고 3일을 기다린다. 백엔드 팀장은 DBA한테 "테이블 하나 파주세요" 결재를 올리고 3일을 기다린다. 코드 치는 건 1시간인데, 부서 간 승인받고 릴리즈 일정을 3팀이 모여서 맞추느라(Synchronized Release) 2주일이 낭비되어 예전 모놀리식 시절보다 배포 속도가 10배 느려졌다.

   • 아키텍트의 해결책: 수평적 계층(Horizontal Layer) 분해의 파멸적 부작용이다. 기술(UI, API, DB)을 기준으로 팀을 찢으면 그 어떤 기능 1개도 혼자서 완성할 수가 없는 지독한 족쇄(Coupling)에 걸린다. 아키텍트는 즉시 3개 층을 수직(Vertical)으로 썰어버리는 비즈니스 능력 분해를 때려야 한다. 장바구니 스쿼드 팀을 하나 만들고 그 팀 안에 UI 개발자 1명, API 개발자 1명, DB 1개를 통째로 몰아넣어 방을 닫아버린다. 이제 장바구니 팀은 타 부서 결재 0번으로 UI부터 DB까지 수직 관통(Full-stack)하는 기능을 1시간 만에 짜서 하루에 10번 대낮에 배포해 버리는 미친 레이싱카로 둔갑한다.

2. 시나리오 — '공통 도메인(God Class)' 쟁탈전, 찢어진 부대들의 피 튀기는 내전: 비즈니스로 [주문팀]과 [배송팀]을 예쁘게 찢어놨다. 문제는 **'사용자(User)'**라는 데이터였다. 주문팀도 결제할 때 '사용자 주소'가 필요하고, 배송팀도 택배 보낼 때 '사용자 주소'가 필요하다. 서로 "야, User 테이블은 내가 관리할 테니까 넌 내 API 찔러서 가져가!"라며 피 터지는 권력(DB 주도권) 싸움이 났다. 주문팀이 User 테이블 컬럼명을 address에서 home_addr로 슬쩍 바꿨더니, 배송팀 서버 전체가 Null 에러를 뿜으며 사망했다.

   • 아키텍트의 해결책: 비즈니스 능력 분해의 한계(공통 엔티티 파편화)와 DDD 문맥 경계(Bounded Context)의 투입이다. 비즈니스로만 썰면 '명사(Data)'가 꼬인다. 아키텍트는 솔로몬의 판결을 내린다. "User 테이블 1개를 같이 쓰지 마라! 무조건 2개로 찢어라!"
     • 주문팀 DB에는 User(이름, 신용카드 번호) 만 저장한다.
     • 배송팀 DB에는 User(이름, 집 주소) 만 저장한다. 데이터가 중복 저장(Redundancy)되어 낭비 같아 보이지만, 이것이 바로 **"데이터의 파편화(중복)를 감수하고서라도, 상대팀이 죽든 살든 내 코드는 절대 안 죽는 절대적 결합도 단절(Decoupling)"**을 이루어내는 마이크로서비스 아키텍처의 위대하고 잔인한 진리다. (532장 연계)

도입 체크리스트

• 조직적: "Two-Pizza Team (투 피자 팀)"의 룰을 지키고 있는가? 비즈니스 능력으로 팀을 찢었다. [결제팀]이 만들어졌다. 그런데 이 팀에 개발자가 50명이다? 망한 거다. 아마존(AWS)의 제프 베이조스가 세운 MSA 절대 헌법. "팀원은 피자 2판으로 배불리 먹을 수 있는 숫자(5~9명)를 절대 넘어서는 안 된다." 사람이 10명을 넘어가는 순간 아침 데일리 스크럼(회의)이 1시간이 넘어가고, 소통 비용(Communication Overhead)이 폭발하여 애자일 속도가 늪에 빠진다. 10명이 넘으면 그 결제팀을 [신용카드 결제팀], [포인트 결제팀]으로 더 마이크로(Micro)하게 또 한 번 썰어버려(분해) 인원수를 5명으로 무조건 압착시켜야 한다.
• 기술적: API 하위 호환성 (Backwards Compatibility) 정책이 깔려 있는가? 비즈니스 조직이 분리되어 내 마음대로 내 서버 API 파라미터를 막 바꾼다. 편하다. 그런데 날 부르던 옛날 버전을 쓰는 모바일 앱 고객 100만 명의 화면이 다 하얗게 뻗어버렸다. 찢어진 팀의 유일한 무기는 'API(약속)'다. 아키텍트는 "API v1을 v2로 바꿀 때, 기존 v1 파라미터를 무조건 6개월간 살려둔다(Deprecation Policy)"는 엄격한 API 게이트웨이 버전 관리(Versioning) 헌법을 세우지 않으면 분산된 자율성이 곧 분산된 재앙으로 돌아온다.

안티패턴

• "프론트엔드 모놀리스 (Frontend Monolith)의 방치": 백엔드 서버는 주문, 배송, 회원으로 기가 막히게 50개로 찢고(비즈니스 능력 분해) 각자 배포했다. 그런데 사용자가 보는 웹 브라우저(React 앱) 껍데기 소스 코드는 1,000만 줄짜리 1통짜리 덩어리(모놀리식)로 그냥 냅뒀다. 백엔드 개발자 50명이 제각기 튀어나가는데, 프론트엔드 개발자 10명은 1개의 Git 저장소에서 100만 줄 엉킨 코드를 풀며 머리끄덩이를 잡고 싸운다(Front-end 병목). "백엔드를 비즈니스로 찢었다면, 브라우저 화면(UI) 자체도 [결제 컴포넌트], [배송 컴포넌트]로 갈기갈기 찢어서 각 백엔드 팀원(스쿼드)이 자기 화면 쪼가리까지 같이 책임지고 배포하는 마이크로 프론트엔드(Micro-Frontends) 구조로 통째로 수직 정렬해야 한다."

• 📢 섹션 요약 비유: 프론트엔드 모놀리스 방치는, **'주방에선 한식, 양식, 일식 셰프가 각자 자기 주방(백엔드)에서 1초 만에 밥을 찍어내는데, 홀 서빙 알바생(프론트엔드)은 딱 1명만 고용해 놓은 것'**과 같습니다. 주방(백엔드)이 아무리 빨라도 서빙(화면 배포)이 밀려서 손님은 평생 밥을 못 먹습니다. 진정한 MSA 분해는 양식 셰프가 자기 요리의 전담 서빙 알바생(마이크로 프론트)까지 1조(스쿼드)로 데리고 다니며 처음부터 끝까지 혼자 다이렉트로 책임지는 구조입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• AI 기반 아키텍처 자동 찢기 (Auto-Decomposition by AI): 1,000만 줄짜리 오래된 스파게티 레거시 코드를 사람이 눈으로 보고 "여기가 결제부서네, 자르자!" 하려면 1년이 걸린다. 미래의 마이그레이션(Migration)은 챗GPT 같은 초거대 AI가 소스코드를 1초 만에 통째로 씹어 먹는다. 그리고 AI가 파일 10,000개의 호출 관계(Call Graph)를 분석하여, "이 파일 300개는 결제, 저 파일 200개는 배송 묶음이야!" 라며 기계적으로 완벽한 비즈니스 쪼개기 도면(Bounded Context)을 그려주고, 찢어진 도커 컨테이너 코드까지 분리해 토해내는 '자율형 MSA 마이그레이션' 시대가 도래하고 있다.
• 클라우드 서버리스(Serverless)와 비즈니스 분해의 극한 융합: 도커 컨테이너(K8s) 단위로 찢는 것도 이젠 뚱뚱하다. 아키텍트들은 "서버 깡통 띄울 필요도 없어! 그냥 [결제 승인] 비즈니스 로직 하나만 AWS 람다(Lambda) 함수 딱 1개(10줄)로 허공에 띄워!"라고 나아간다. 비즈니스 능력이 서버(Server) 단위를 넘어 함수(Function, FaaS) 단위로 원자(Atomic) 분해되며, 초당 1,000만 번의 트래픽에도 1원도 낭비되지 않고 무한대로 확장하는 극한의 마이크로 세상(Nano-services)이 클라우드를 지배하고 있다.

참고 표준

• Conway's Law (콘웨이의 법칙): "소프트웨어 구조는 결국 그 코드를 짜는 인간들의 소통(조직도) 구조를 카피하게 되어있다." 이 1960년대의 위대한 명언이 21세기 마이크로서비스 비즈니스 분해 패턴(스쿼드 조직론)을 탄생시킨 가장 위대한 철학적 뿌리이자 헌법.
• Spotify Squad Model (스포티파이 모델): 세계 1위 음악 앱 스포티파이가 "우리는 부장님 결재 안 받고, 8명짜리 '스쿼드(Squad)' 팀이 사장님처럼 권한을 다 쥐고 각자 서버를 맘대로 배포해!"라며 전 세계 IT 업계에 충격을 주고 애자일/MSA 조직의 '바이블(교복)'이 된 전설적인 팀 분해 아키텍처.

비즈니스 능력에 따른 분해(Decompose by Business Capability)는 소프트웨어 공학이 "위대한 코드는 위대한 컴퓨터(기술)에서 나오는 것이 아니라, 위대하게 조립된 인간의 뇌(조직)에서 나온다"는 가장 인문학적인 진리를 깨닫고 시스템의 뼈대에 메스를 댄 철학적 외과 수술이다. 우리는 그동안 화면(UI)을 잘 그리는 사람, DB 쿼리를 잘 짜는 사람을 기술의 색깔별로 칸막이에 가두고 소통의 지옥을 맛보았다. 기계가 터지기 전에 인간의 협업이 먼저 터져버렸다. 아키텍트는 과감하게 콘크리트 벽(부서 이기주의)을 부수어야 한다. 1개의 온전한 고객 가치(결제, 배송)를 창조하기 위해 프론트엔드, 백엔드, DB 관리자를 하나의 비좁은 구명보트(Microservice)에 구겨 넣고, "너희들끼리 치고받고 싸워서라도 이 기능 하나만큼은 1시간 안에 런칭하고 책임져라!"라며 멱살을 쥐여주는 독재자. 그것이 기술의 늪에서 허우적대는 코더들을 구출해 내어, 돈을 버는 비즈니스의 최전선(Time-to-Market)으로 강제 진군시키는 진정한 아키텍트의 위대한 용단이다.

• 📢 섹션 요약 비유: 이 분해 철학은 거대한 오케스트라 교향악단을 **'독립적인 길거리 버스킹 밴드 50개'**로 찢는 것과 같습니다. 오케스트라(모놀리식/수평 계층)는 바이올린 50명(프론트), 첼로 50명(백엔드)이 앉아서 한 명의 지휘자(사장님) 손짓에만 맞춰 1시간짜리 지루한 노래를 칩니다. 지휘자가 틀리면 전원이 멈춥니다. 비즈니스 능력 분해는 바이올린 1명, 첼로 1명, 드럼 1명을 뽑아 '4인조 록밴드(스쿼드)' 50개를 만들어 길거리에 던집니다. 이 밴드 50개는 지휘자 없이 자기 맘대로 팝송도 부르고 락도 부르며 관객(고객)의 반응에 맞춰 1초 만에 노래를 바꿔 부르는(Agility) 미친듯한 독립 생존력과 자율성을 폭발시킵니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 거대한 식당(낡은 컴퓨터 프로그램)이 있었어요. 요리를 만들려면 '재료 써는 사람(DB)', '불 피우는 사람(백엔드)', '그릇에 담는 사람(프론트)' 방을 3번 거쳐야 해서 짬뽕 한 그릇 나오는 데 1시간이나 걸렸죠 ㅠㅠ (층별로 나눈 멍청한 구조)
2. 화가 난 사장님(아키텍트)이 식당을 다 부수고 아예 '짜장면 코너', '치킨 코너', '아이스크림 코너' (비즈니스 능력) 로 방을 새로 다 쪼개버렸어요!
3. 이제 각 코너 안에 재료와 불과 그릇이 전부 다 들어있어서, 짜장면을 시키면 딴 방 눈치 볼 필요 없이 오직 그 코너 요리사 혼자서 1분 만에 짜장면을 탁! 만들어 내는 엄청나게 빠르고 눈치 안 보는 똑똑한 팀 나누기 방법을 **'비즈니스 능력 분해'**라고 부른답니다!