Diagram

Diagram은 노드, 연결과 그룹을 이용해 관계와 구조를 자유롭게 시각화하는 범용 문서 유형입니다. 업무 흐름, 정보 구조, 아키텍처, 개념·상태·호출 관계와 조직 구조 등 시각적으로 설명할 수 있는 다양한 결과를 만들 수 있습니다.

Diagram으로 만들 수 있는 것

예를 들면 다음과 같습니다.

• 플로차트와 업무 프로세스
• 사용자 흐름과 서비스 흐름
• 정보 구조(IA), 사이트맵과 내비게이션 구조
• 시스템·서비스·모듈 구성도
• 소프트웨어 아키텍처
• 클라우드·인프라·네트워크 아키텍처
• 데이터 아키텍처와 데이터 흐름
• 보안 아키텍처와 신뢰 경계
• 조직도와 역할 관계
• 개념도와 마인드맵
• 의사결정 구조
• 상태 변화
• 클래스 구조와 객체 관계
• 호출 순서와 시퀀스
• 사용자와 기능의 유스케이스
• 활동과 처리 흐름
• 상태와 전이
• 컴포넌트와 배포 구조
• 프로젝트에 필요한 그 밖의 관계·구조 시각화

이 목록은 Diagram의 용도를 제한하지 않습니다. IA, 아키텍처, 클래스 구조, 시퀀스 또는 이름이 정해지지 않은 자유 형식의 그림까지 노드·연결·그룹으로 표현할 수 있는 내용이라면 프로젝트 목적에 맞게 구성할 수 있습니다. 특정 분야나 다이어그램 종류를 선택해야만 사용할 수 있는 기능이 아닙니다.

데이터베이스의 테이블, 컬럼과 외래 키를 데이터 모델로 관리해야 한다면 Diagram보다 ERD가 적합합니다.

만들기 전에

먼저 무엇을 설명하거나 검토하기 위한 Diagram인지 정합니다.

• 다이어그램의 목적
• 주요 독자
• 표현할 대상과 범위
• 필요한 표현 방식
• 반드시 드러나야 하는 관계와 흐름
• 상세 수준

정해진 표기 규칙이 필요한 경우에는 사용할 표현과 규칙을 요청에 명시합니다.

Agent로 만들기

[프로젝트 이름]의 기준 문서와 관련 자료를 읽고, [목적]을 설명하는 Diagram을 만들어줘.

형식이 중요한 경우에는 원하는 표현 방식을 함께 지정합니다.

주요 도메인 개체의 속성과 관계가 보이도록 클래스 구조를 그려줘.

사용자 요청부터 결과 반환까지 참여 대상과 호출 순서가 보이도록 그려줘.

원하는 배치, 그룹, 색상이나 강조 방식이 있다면 함께 설명할 수 있습니다.

구성 요소

• 노드 — 개체, 단계, 상태, 역할, 시스템 또는 개념
• 연결 — 방향, 관계, 호출, 이동 또는 의존성
• 그룹 — 관련 요소를 묶는 영역이나 계층
• 모양 — 사각형, 원, 다이아몬드, 실린더 등 의미를 구분하는 표현
• 레이블과 색상 — 관계와 중요도를 설명하는 표현

Agent는 노드, 연결과 그룹을 함께 생성·수정·삭제할 수 있습니다. 관련 변경은 가능한 한 하나의 일관된 작업으로 적용하고, 변경 후 구조를 다시 확인합니다.

큰 Diagram 구성하기

내용이 많아지면 그룹으로 영역을 나누고 필요한 경우 관련 Diagram을 연결합니다. 한 화면에 모든 세부 사항을 넣기보다 목적과 독자에 맞는 수준으로 분리합니다.

배치는 이해를 돕기 위한 표현입니다. 위치와 색상만으로 중요한 의미를 전달하지 말고 이름과 연결 관계도 명확히 합니다.

검토하기

다이어그램의 목적과 종류에 따라 다음을 확인합니다.

• 표현하려는 대상과 범위가 맞는가
• 노드와 연결의 의미가 분명한가
• 방향, 관계와 레이블이 올바른가
• 프로젝트 용어와 일치하는가
• 빠진 요소나 잘못 연결된 요소가 없는가
• 사용한 표기법이 일관되는가
• 복잡도가 목적에 적합한가
• 관련 Markdown과 전문 산출물의 결정에 맞는가

정해진 표기 규칙을 사용했다면 그 의미가 일관되게 유지되는지 확인하고, 자유 형식이라면 범례나 설명이 필요한지 검토합니다.

프로젝트 기준과 연결하기

Diagram은 정보를 이해하고 검토하는 시각적 산출물입니다. Diagram에서 새로운 결정이나 질문이 생기면 Markdown 기준 문서에 반영하고, 실행이 필요한 내용은 Kanban으로 연결합니다.

다음 단계

API 계약을 구조화해야 한다면 OpenAPI 명세를 확인하세요.