핵심 인사이트 (3줄 요약)
- 본질: LISS (Linearly Independent, Spatially Spanning)는 복잡한 업무나 시스템을 구성할 때 각 모듈의 책임은 겹치지 않고, 전체 요구 공간은 빠짐없이 덮어야 한다는 구조화 원리다.
- 가치: 이 원리를 적용하면 서비스 경계, 데이터 모델, 책임 분담을 더 명확히 설계할 수 있어 결합도는 낮추고 누락된 기능이나 예외 처리는 줄일 수 있다.
- 판단 포인트: 핵심은 요소를 많이 쪼개는 것이 아니라, 분해 기준을 잘 선택해 독립성은 유지하면서도 전체 비즈니스 시나리오를 커버하는 최소 충분 집합을 찾는 데 있다.
Ⅰ. 개요 및 필요성
LISS는 선형 독립 (Linearly Independent)과 공간 포괄 (Spatially Spanning)이라는 두 개념을 결합해, 구조 설계의 품질을 설명하는 원리다. 쉽게 말해 각 구성요소가 서로 대체되지 않는 고유 책임을 가지면서도, 모두 합치면 전체 업무나 시스템을 빠짐없이 설명할 수 있어야 한다는 뜻이다. 비즈니스 분석에서는 MECE와 닮았고, 소프트웨어 설계에서는 모듈 경계와 책임 분리를 설명하는 데 자주 연결된다.
이 원리가 필요한 이유는 엔터프라이즈 시스템이 커질수록 두 가지 문제가 동시에 발생하기 때문이다. 첫째, 주문 모듈과 결제 모듈이 같은 검증 로직을 각각 가지면 변경 시 두 군데를 함께 수정해야 한다. 둘째, 모든 모듈이 자기 책임만 강조하다 보면 예외 승인, 환불, 정산처럼 애매한 기능이 어디에도 속하지 않아 운영 공백이 생긴다.
따라서 LISS는 "겹침을 줄여라"와 "빈틈을 메워라"를 동시에 요구한다. 이는 마이크로서비스, 도메인 주도 설계, 데이터 정규화, 조직 책임 분장까지 모두에 적용되는 공통 설계 감각이라고 볼 수 있다.
- 📢 섹션 요약 비유: LISS는 오케스트라에서 바이올린, 첼로, 플루트가 같은 멜로디를 중복 연주하지 않으면서도, 모두 합쳐야 곡이 비지 않고 완성되게 만드는 편성과 같다.
Ⅱ. 아키텍처 및 핵심 원리
LISS를 시스템 설계에 적용할 때는 보통 전체 업무 공간 정의, 분해 기준 설정, 독립성 검증, 포괄성 검증의 순서로 접근한다. 예를 들어 커머스 시스템을 주문, 결제, 재고, 배송으로 나눌 수 있는데, 이때 각 서비스가 무엇을 소유하고 어떤 이벤트를 발행하는지 명확해야 한다. 독립성은 책임 중복을 줄이는 기준이고, 포괄성은 전체 고객 여정이 끊기지 않게 하는 기준이다.
| 요소 | 질문 | 설계 의미 |
|---|---|---|
| Domain space | 우리가 덮어야 할 전체 업무 범위는 무엇인가 | 요구사항 경계 정의 |
| Independent unit | 각 모듈은 어떤 고유 책임을 가지는가 | 결합도 감소, 응집도 향상 |
| Spanning set | 모든 주요 시나리오가 커버되는가 | 기능 누락 방지 |
| Interface | 모듈 간 접점은 무엇인가 | 계약 기반 협업, 변경 영향 통제 |
| Validation | 중복·공백을 어떻게 검증하는가 | 리뷰, 테스트, 이벤트 흐름 점검 |
아래 그림은 LISS를 서비스 경계 설계 관점에서 해석한 것이다.
┌──────────────────────────────────────────────────────────────────────┐
│ LISS design view │
├──────────────────────────────────────────────────────────────────────┤
│ Total business space │
│ ┌──────────┬──────────┬──────────┬──────────┐ │
│ │ Order │ Payment │ Inventory│ Delivery │ │
│ └──────────┴──────────┴──────────┴──────────┘ │
│ │ │ │ │ │
│ └──── independent ownership and clear interfaces ─────┘ │
│ │
│ Check A: overlap between services = minimal │
│ Check B: end-to-end scenario coverage = complete │
└──────────────────────────────────────────────────────────────────────┘
선형 독립성 관점에서는 한 기능의 핵심 규칙이 한 곳에만 존재해야 한다. 예를 들어 할인 정책 계산이 주문과 결제 양쪽에 동시에 들어가 있으면 규칙 변경 시 충돌이 발생한다. 공간 포괄성 관점에서는 주문 생성, 결제 실패, 환불, 재고 복원, 배송 취소 같은 전체 시나리오가 서비스 조합으로 빠짐없이 설명되어야 한다.
- 📢 섹션 요약 비유: LISS는 집을 지을 때 방마다 역할이 겹치지 않게 배치하면서도, 부엌·화장실·침실이 빠지지 않게 전체 생활 공간을 완성하는 설계도와 같다.
Ⅲ. 비교 및 연결
LISS는 비즈니스 사고의 MECE, 코드 수준의 SRP (Single Responsibility Principle), 데이터 모델의 정규화와 비교하면 이해가 쉽다. MECE가 문제 분해의 논리 원칙이라면, LISS는 그 원칙을 시스템 구조 설계로 가져온 해석에 가깝다. SRP는 클래스 수준의 책임 분리를 강조하고, 정규화는 데이터 중복을 제거하는 데 초점이 있지만, LISS는 모듈 구조 전체의 독립성과 커버리지를 함께 본다.
| 관점 | 핵심 질문 | 초점 |
|---|---|---|
| MECE | 분류가 겹치거나 비지 않는가 | 문제 분해와 분석 구조 |
| SRP | 클래스가 한 가지 책임만 가지는가 | 코드 수준 책임 분리 |
| 정규화 | 데이터 중복과 이상 현상이 없는가 | 데이터 구조 품질 |
| LISS | 모듈이 독립적이면서 전체 요구를 덮는가 | 시스템 경계와 아키텍처 품질 |
이 원리는 DDD (Domain-Driven Design)의 Bounded Context, 마이크로서비스 경계 설정, 이벤트 기반 아키텍처의 이벤트 소유권과도 이어진다. 예를 들어 주문 이벤트를 주문 서비스가 발행하고 결제 서비스가 이를 소비하는 구조는 독립성을 높이지만, 환불 승인 책임이 어디에도 없다면 포괄성이 깨진다. 즉 LISS는 "잘 분리된 구조"와 "빠지지 않은 구조"를 동시에 보게 하는 렌즈다.
- 📢 섹션 요약 비유: MECE가 문제를 나누는 자라면, LISS는 그 자를 들고 실제 건물을 설계하는 건축가의 관점과 같다. 눈금만 맞아도 건물이 자동으로 서는 것은 아니기 때문이다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서 LISS는 마이크로서비스 분리 기준을 검토할 때 특히 유용하다. 예를 들어 레거시 쇼핑몰을 서비스로 분리하면서 팀이 테이블 단위로 서비스를 나누면, 주문 상태와 결제 상태가 여러 서비스에 걸쳐 중복 관리되어 독립성이 무너진다. 반대로 "주문, 결제, 재고, 배송"처럼 도메인 능력 기준으로 나누면 책임 경계가 더 명확해진다.
기술사 관점의 판단 포인트는 세 가지다. 첫째, 각 서비스의 데이터와 규칙 소유권이 명확한가를 본다. 둘째, 전체 고객 여정과 장애 시나리오가 모든 서비스 조합으로 설명되는가를 점검한다. 셋째, 독립성만 강조해 서비스를 과도하게 잘게 나누면 운영 복잡도와 분산 트랜잭션 비용이 커질 수 있으므로, 최소 충분 분할인지 함께 판단해야 한다.
실무 체크리스트는 ① 중복 소유하는 비즈니스 규칙이 있는가, ② 공유 데이터베이스에 과도하게 의존하는가, ③ 예외 시나리오를 담당하는 모듈이 존재하는가, ④ 인터페이스 계약이 문서화되어 있는가다. 대표 안티패턴은 "공통 테이블이 있으니 공통 서비스 하나에 다 넣자"는 식의 갓 서비스(God Service) 설계와, 반대로 너무 미세하게 쪼개어 오히려 책임 추적이 불가능해지는 구조다.
- 📢 섹션 요약 비유: LISS를 잘 쓰는 팀은 축구 포지션을 명확히 나누되 공격과 수비 전체 흐름은 끊기지 않게 운영하는 팀과 같고, 못 쓰는 팀은 모두가 같은 공을 쫓다가 빈 공간을 내주는 팀과 같다.
Ⅴ. 기대효과 및 결론
LISS를 잘 적용하면 변경 영향 범위가 줄고, 장애 원인 추적이 쉬워지며, 서비스 간 책임 충돌도 감소한다. 또한 신규 요구사항이 들어왔을 때 어느 모듈에 기능을 추가해야 하는지 판단하기 쉬워져 설계 의사결정 속도도 빨라진다. 이 점에서 LISS는 확장성과 유지보수성을 동시에 높이는 설계 기준으로 의미가 크다.
다만 LISS는 수학적 비유처럼 완전한 직교 구조를 현실 시스템에 그대로 강제하는 공식은 아니다. 실제 조직 구조, 배포 단위, 데이터 정합성 요구, 운영 인력 수준을 고려해야 하며, 독립성과 포괄성의 균형점은 상황마다 달라진다. 따라서 LISS는 "무조건 잘게 나누는 원칙"이 아니라 "겹침과 공백을 줄이는 설계 판단 프레임"으로 기억하는 것이 적절하다.
- 📢 섹션 요약 비유: LISS는 모든 공구를 제자리에 두되, 수리할 때 필요한 공구가 하나도 빠지지 않게 정리된 공구함과 같다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| MECE (Mutually Exclusive, Collectively Exhaustive) | LISS의 비즈니스 분석적 뿌리로 중복·누락 통제 원칙 제공 |
| SRP (Single Responsibility Principle) | 코드 수준에서 책임 중복을 줄이는 독립성 개념 |
| 정규화 (Normalization) | 데이터 중복 제거와 구조적 안정성 확보 측면에서 유사 |
| DDD (Domain-Driven Design) | 경계 맥락을 통해 독립적인 도메인 경계를 정의 |
| MSA (Microservices Architecture) | LISS 원리를 서비스 분할과 인터페이스 설계에 적용 |
📈 관련 키워드 및 발전 흐름도
Problem decomposition
│
▼
MECE thinking
│
▼
LISS architecture lens
│
▼
Bounded context and service ownership
│
▼
Evolvable enterprise architecture
이 흐름은 "문제 분해 원칙 → 구조 설계 원리 → 서비스 경계 정의 → 진화 가능한 아키텍처"로 이어지는 사고 확장을 보여준다.
👶 어린이를 위한 3줄 비유 설명
- LISS는 친구들과 역할놀이를 할 때 모두가 다른 역할을 맡고, 빠진 역할이 없게 만드는 규칙이에요.
- 누군가는 주문을 받고, 누군가는 계산하고, 누군가는 물건을 챙겨야 일이 잘 돌아가요.
- 서로 같은 일을 두 번 하지 않고 필요한 일이 모두 있으면 팀이 훨씬 잘 움직여요.