설계 검증에 쓰이는 다이어그램 종류

how-to-verify-implementation-matches-design|설계 검증에서 "AI에게 구조도를 그려달라"고 할 때, 확인하고 싶은 대상에 따라 적절한 다이어그램이 달라진다. 크게 정적 구조, 동적 행동, 배포 구조 세 관점이 있다.

정적 구조 — "코드가 어떻게 조직되어 있나"

코드를 실행하지 않고 볼 수 있는 것들.

Class Diagram

객체 간의 관계를 보여준다. 도메인 모델이 설계와 일치하는가를 검증한다.

Package/Module Diagram

폴더/모듈 단위의 의존 관계. 아키텍처(Layered 등)가 지켜졌는가를 검증한다. 화살표가 항상 위→아래인지, 층을 건너뛰는 의존이 없는지 확인.

ER Diagram (Entity-Relationship)

DB 테이블 간 관계. DB 스키마가 도메인 모델과 일치하는가를 검증한다. Course-Lecture 분리가 테이블에서도 반영됐는지.

동적 행동 — "실행하면 어떻게 흐르나"

코드가 돌아갈 때 일어나는 것들.

Sequence Diagram

하나의 기능이 실행될 때 모듈 간 호출 순서. 기능 흐름이 설계 의도와 같은가를 검증한다.

"충돌 검사가 저장 전에 일어나는가?" 같은 순서 문제를 잡을 수 있다.

Flowchart

하나의 로직 안에서의 분기와 판단.

비즈니스 로직의 분기가 맞는가를 검증한다. "충돌 시 어떻게 되나?", "중복 등록은?" 같은 엣지 케이스 처리 확인.

배포 구조 — "어디서 뭐가 돌아가나"

designing-local-app-with-server-dependency|로컬+서버 혼합 구조처럼 물리적 배치가 중요한 경우.

검증 대상: 물리적 배치가 맞는가. "SQLite가 정말 앱 안에 내장돼 있는가?", "LLM 통신이 HTTP로 격리돼 있는가?"

어떤 상황에 어떤 다이어그램을 쓰나

매번 다 그릴 필요 없어. 검증 루틴에 맞춰서:

Step 1 (폴더 구조)   → Package Diagram 요청
Step 2 (모델 확인)   → Class Diagram 요청  
Step 3 (import 방향) → Package Diagram으로 이미 확인됨
Step 4 (동작 확인)   → 핵심 기능 하나만 Sequence Diagram 요청

"SQLite가 앱 안에 내장돼 있는가?", "LLM 통신이 HTTP로 격리돼 있는가?" 등을 확인한다.

상황별 선택 가이드

매번 다 그릴 필요 없다. Package + Class 두 개면 80% 검증 가능하고, 나머지는 필요할 때 추가하면 된다.

다이어그램 종류를 외울 필요는 없다. **"나는 지금 뭘 확인하고 싶은가?"**를 먼저 정하고 그에 맞는 도구를 고르면 된다. 구조가 궁금하면 정적, 흐름이 궁금하면 동적.