85. 논리 뷰 (Logical View) - 최종 사용자 요구사항 개념 설계

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

본질: 기능적 요구사항은 "무엇을 해야 하는가"이고, 논리 뷰(Logical View)는 그 요구를 책임 중심 구조로 번역한 설계 관점이다. 가치: 클래스 다이어그램(Class Diagram)은 구현 기술이 바뀌어도 유지되는 정적 구조를 보여 주어, 개발·테스트·검토의 공통 언어가 된다. 판단 포인트: 유스케이스에서 클래스 책임으로 내려오는 추적성이 없으면, 논리 뷰는 예쁜 그림일 뿐 설계 검증 도구가 되지 못한다.

Ⅰ. 개요 및 필요성

논리 뷰(Logical View)는 4+1 뷰 모델(4+1 View Model)에서 기능과 도메인 구조를 설명하는 관점이다. 화면 배치나 서버 대수보다 먼저 "어떤 객체가 어떤 책임을 지는가"를 정리해, 기능적 요구사항을 설계 언어로 번역한다.

필요성은 복잡한 시스템에서 요구사항의 의미가 팀마다 달라지는 것을 막는 데 있다. 같은 주문 처리라도 프론트엔드는 버튼과 상태, 백엔드는 검증과 트랜잭션, 테스트는 시나리오와 예외를 보게 되는데, 논리 뷰가 없으면 이 셋이 서로 다른 그림을 그리게 된다.

UML (Unified Modeling Language) 관점에서 보면 논리 뷰는 기능을 객체 책임으로 쪼개는 첫 단계다. 이 단계가 선명해야 이후 컴포넌트 설계와 배포 구조가 흔들리지 않는다.

📢 섹션 요약 비유: 설계 번역기

Ⅱ. 아키텍처 및 핵심 원리

클래스 다이어그램은 경계(Boundary) - 제어(Control) - 엔티티(Entity)처럼 책임을 나누는 데 유용하다. Boundary는 외부와의 접점, Control은 유스케이스 흐름, Entity는 도메인 규칙을 품는다. 여기에 연관(Association), 집합(Aggregation), 합성(Composition), 일반화(Generalization), 의존(Dependency)을 붙여 협력 구조를 드러낸다.

요구사항 -> 유스케이스 -> Boundary/Control/Entity -> 클래스 다이어그램
    |             |                 |                     |
    └─────────────┴─────────────────┴─────────────────────┘
                 "무엇을 해야 하는가"를 책임으로 분해

요소	역할	체크 포인트
Boundary	외부 입력/출력	API, UI, 메시지 경계가 과도하게 비대해지지 않는가
Control	유스케이스 흐름	절차만 있고 규칙이 없는 빈 껍데기가 아닌가
Entity	도메인 규칙	핵심 규칙이 서비스 클래스가 아니라 엔티티에 남는가

이 구조의 핵심은 화면·DB·메시지 큐보다 먼저 규칙의 경계를 세우는 것이다. 클래스 다이어그램은 객체의 이름표가 아니라, 책임의 중복과 누락을 찾는 점검표다.

📢 섹션 요약 비유: 역할 분담표

Ⅲ. 비교 및 연결

논리 뷰는 컴포넌트 뷰(Component View)나 배포 뷰(Deployment View)와 다르다. 논리 뷰가 "무엇과 무엇이 협력하는가"를 보여 준다면, 컴포넌트 뷰는 "어떤 모듈로 묶이는가", 배포 뷰는 "어디에 올라가는가"를 보여 준다. 또한 클래스 다이어그램은 정적 구조이고, 시퀀스 다이어그램(Sequence Diagram)은 동적 메시지 흐름이다.

비교 대상	논리 뷰와의 차이
클래스 다이어그램 vs 시퀀스 다이어그램	구조 vs 실행 흐름
논리 뷰 vs 컴포넌트 뷰	책임 구조 vs 모듈 경계
기능적 요구사항 vs 비기능적 요구사항	기능 정의 vs 성능/가용성 제약

따라서 논리 뷰는 기능적 요구사항을 객체 책임으로 묶고, 다른 뷰가 그 책임을 어떻게 배치·실행할지 이어받게 만든다.

📢 섹션 요약 비유: 지도와 배치도의 차이

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

실무에서는 유스케이스 1개당 주요 책임 객체가 무엇인지 먼저 적고, 그 다음에 클래스 다이어그램을 그려야 한다. 요구사항 문장에 있는 동사와 명사를 그대로 옮기기보다, 규칙·상태·예외를 분리해 누가 검증하고 누가 저장하는지 결정한다. 그 과정에서 추적성 매트릭스(Traceability Matrix)를 두면 요구 변경이 어느 클래스에 영향을 주는지 바로 보인다.

체크리스트

유스케이스의 예외 처리와 정상 흐름이 모두 구조에 반영되었는가?
DB 테이블명을 클래스명으로 착각한 부분은 없는가?
제어 로직이 특정 화면이나 특정 프레임워크에 과도하게 묶이지 않았는가?

안티패턴

테이블 구조를 먼저 그리고 그 위에 클래스를 억지로 얹는 설계
모든 규칙을 서비스 클래스 한 곳에 몰아넣는 설계
다이어그램은 많지만 유스케이스와 연결되지 않는 설계
📢 섹션 요약 비유: 검사관 체크리스트

Ⅴ. 기대효과 및 결론

논리 뷰가 잘 서면 요구사항 변경이 와도 영향 범위를 빠르게 읽을 수 있고, 테스트 케이스도 책임 단위로 분해된다. 반대로 논리 뷰가 약하면 구현은 빨라 보여도 규칙 중복과 결합도가 쌓여, 유지보수 시점에 더 큰 비용으로 돌아온다. 이 관점에서 논리 뷰는 "예쁜 UML"이 아니라 기능 요구를 실행 가능한 설계로 바꾸는 번역기다.

앞으로는 DDD (Domain-Driven Design)와 결합해, 유스케이스-클래스-컴포넌트 사이의 연결을 더 명확히 추적하는 방향으로 쓰인다. 다만 배포 구조, 성능 임계치, 장애 복구 전략은 별도의 뷰에서 보완해야 한다.

📢 섹션 요약 비유: 레고 설명서

📌 관련 개념 맵

개념	연결 포인트
기능적 요구사항	시스템이 해야 할 일의 출발점
유스케이스	사용자 관점 시나리오
논리 뷰	책임 분해 관점
클래스 다이어그램	정적 협력 구조
컴포넌트/배포 뷰	구현·운영 단계로 확장

📈 관련 키워드 및 발전 흐름도

기능 요구사항
   ↓
유스케이스
   ↓
책임 분해
   ↓
논리 뷰
   ↓
클래스 다이어그램
   ↓
컴포넌트/배포 설계

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

논리 뷰는 큰 레고 상자를 열어 "이 블록은 뭐 하는 블록인지"를 적는 설명서예요.
클래스 다이어그램은 블록들이 서로 어떻게 붙는지 보여 주는 조립도예요.
설명서가 있으면 친구가 바뀌어도 같은 장난감을 다시 만들 수 있어요.