반복 · 분석가와 엔지니어에게 인계

모델 변경의 파급 범위(파이프라인 Entity I/O · 그래프 인스턴스 · 인스펙터 라벨), 새 데이터셋이 들어왔을 때 매핑 추가 흐름, 그리고 분석가에게는 그래프 탐색기 진입 · 엔지니어에게는 새 데이터셋 매핑 패턴으로 양쪽 인계까지.

10분

지금까지 만든 그래프가 자기 컬렉션 안에 떠 있다고 합시다. 모델은 한 번 그려 끝나는 자산이 아닙니다 — 데이터 스키마가 바뀌고, 새 데이터셋이 추가되고, 분석가/엔지니어가 그 위에 작업을 쌓는 한 사이클이 계속됩니다. 본 레슨은 그 유지보수 사이클과 두 시점으로의 인계를 한 번에 다루며 코스를 마무리합니다.

모델 변경의 파급 범위 — 세 곳을 동시에 본다

엔티티 한 줄, 관계 한 줄을 바꿨을 때 어디까지 영향이 가는지 미리 알면 변경 결정이 빨라집니다.

변경 종류	영향 받는 곳	다음 행동
속성 이름 변경 (예: `health_score` → `latest_health_score`)	(a) 그래프 인스턴스 키, (b) 매핑된 데이터셋 컬럼, (c) 위젯 컬럼 참조	기반 데이터셋(backing dataset) 의 컬럼명을 함께 정렬하거나, 빌더에서만 alias 변경으로 우회
속성 타입 변경 (예: Text → Integer)	(a) 그래프 인스턴스 캐스팅 실패, (b) 파이프라인 Entity I/O 실행 실패	데이터셋 상류(엔지니어 코스 04 레슨) 에서 캐스팅 후 매핑
Identity Keys 변경	가장 큰 파급. 인스턴스 식별이 깨짐	새 컬렉션/엔티티로 분기하는 것이 안전합니다. 기존 엔티티는 deprecation 마커.
관계 type 변경 (`STOCKED_AT` → `STORED_IN`)	모든 Cypher 쿼리 · 그래프 탐색기 딥링크 · 위젯 쿼리	타입 변경은 사실상 새 관계 생성 + 옛 관계 삭제와 같습니다. 한 번에 정리.
카디널리티 변경 (1:N → N:N)	유효성 검사 신호 변경. 위젯의 집계 로직이 의미적으로 영향	그래프 탐색기에서 새 쿼리 결과를 한 번 검증 후 합의

원칙: 모델 변경은 기반 데이터셋 · 그래프 인스턴스 · 인스펙터 라벨 세 곳을 한 번에 봅니다. 한 곳만 보고 결정하면 다른 두 곳에서 silent 결과 변화가 일어납니다.

새 데이터셋이 들어왔을 때 — 매핑 추가 흐름

엔지니어가 새 마트 데이터셋(예: IOT_MaintenanceEvent 의 backing 인 maintenance_events)을 컬렉션에 떨어뜨렸다고 합시다. 모델러의 흐름은 짧습니다.

빌더에서 새 엔티티 IOT_MaintenanceEvent 를 02 레슨의 다섯 영역(이름 · 별칭 · 설명 · 스키마 · Identity)으로 정의 — event_id 가 Identity Key.
03 레슨의 매핑 흐름으로 maintenance_events 데이터셋을 backing 으로 잇기.
기존 IOT_Machine 과의 사이에 04 레슨의 캔버스 드래그로 관계 IOT_triggers 추가 — source 는 IOT_Machine, target 은 IOT_MaintenanceEvent. 관계 자체가 anomaly_id, severity, detected_at 속성을 가지므로 기반 데이터셋 매핑도 한 번 더(예: anomaly_events 데이터셋).
05 레슨의 그래프 탐색기에서 IOT_Machine 라벨 클릭 → 더블클릭 이웃 확장 → 새 IOT_MaintenanceEvent 노드가 함께 떠오르는지 확인.

이 사이클은 본 코스 전체의 축소판입니다. 한 번 흐름이 익숙해지면 새 엔티티 한 개 추가는 10 분 안에 닫힙니다.

분석가에게 인계 — 그래프 탐색기 진입 링크

분석가는 그래프 자체를 잘 모를 수도 있습니다. 어디서부터 시작해야 할지가 인계의 핵심입니다.

그래프 탐색기에서 분석가에게 보여 주고 싶은 시작 상태를 만든 뒤(예: RI_Region 라벨 클릭 → 수도권 더블클릭) URL 을 복사합니다. URL 쿼리 파라미터에 시작 노드와 쿼리가 prefill 됩니다.
본인 컬렉션의 README 또는 분석가용 대시보드 한 페이지에 그 링크를 세 줄 설명과 함께 둡니다 — "수도권 지점들과 거기에 보관된 상품들" 처럼.
분석가에게 위 링크 한 개와 함께 분석가 코스 04 레슨 — 첫 대시보드와 위젯 의 진입을 제안합니다. 그래프의 엔티티 한 개를 위젯의 입력으로 올리는 흐름이 거기 있습니다.

이 한 단락이 채워지면 그래프 탐색기에 들어가지 못한 분석가도 본인이 만든 모델의 첫 결과 화면을 만들 수 있습니다.

엔지니어에게 인계 — 새 데이터셋 매핑 패턴

엔지니어는 외부 시스템에서 데이터를 가져오는 단계에서 자기 흐름이 끝납니다. 그다음 그 데이터가 어느 엔티티의 backing 으로 들어가는지가 인계의 핵심입니다.

본인 컬렉션의 README 한 페이지에 다음 표를 한 번 작성해 둡니다.

엔지니어가 만들 데이터셋	어느 엔티티/관계의 backing	Identity Keys (컬럼)
`machines`	`IOT_Machine`	`machine_id`
`sensors`	`IOT_Sensor`	`sensor_id`
`maintenance_events`	`IOT_MaintenanceEvent`	`event_id`
`sensor_readings`	`IOT_reads_from` (관계)	(interval_seconds, latest_recorded_at)

새 데이터셋이 들어왔을 때 엔지니어가 바로 매핑 가능하도록 권한을 분리합니다. 원본 데이터셋은 엔지니어 컬렉션, 모델은 모델러 컬렉션으로 두고, 매핑 권한(Editor)을 두 컬렉션 모두 가진 공유 그룹 한 개를 만듭니다.
엔지니어에게 본인 도메인의 엔티티 한 개를 example 로 시연합니다 — 02–03 레슨의 매핑 5 단계가 그대로 가이드입니다.

이 한 단락이 채워지면 엔지니어가 본인 흐름을 모델에 맞는 형태로 닫는 자동 신호가 생깁니다.

권한 정리 — 모델 자원의 거버넌스

모델 자체도 조직 공통 자산입니다. 권한은 보통 다음 패턴으로 둡니다.

모델러 그룹 — 빌더 Editor + 그래프 탐색기 Editor.
엔지니어 그룹 — 기반 데이터셋 Editor + 빌더 Viewer (매핑은 모델러가 합의 후 적용).
분석가 그룹 — 그래프 탐색기 Viewer + 위젯 Editor.
거버넌스 / 감사 그룹 — 그래프 탐색기 Viewer + 컬렉션 Activity Log Viewer.

세 역할이 각자의 표면에서만 Editor 권한을 갖도록 두면, 모델 변경이 누구의 결정으로 일어났는지 추적이 자연스러워집니다.

코스 완료 — 다음에 무엇을 할까

여기까지 마쳤다면 의미 레이어 한 사이클을 직접 만들었습니다. 다음 학습 후보는 다음과 같습니다.

분석가 코스 04 레슨 — 첫 대시보드와 위젯 — 자기 그래프의 엔티티 한 개를 위젯 입력으로 올려, 모델이 곧 분석가의 입력이 되는 동선을 한 포털 안에서 확인.
엔지니어 코스 03 레슨 — 첫 파이프라인 — 기반 데이터셋을 외부 시스템에서 정기적으로 채우는 흐름. 모델은 정의했지만 데이터를 누가 채울지 본인이 같이 책임지는 상황에 어울립니다.
워크숍: 리테일 재고 인텔리전스 — 본 코스의 4 + 3 그래프가 실제 시나리오 한 건 안에서 분석가 · 엔지니어 · 모델러 세 시점이 만나는 흐름. 약 90 분.

이 코스의 모든 레슨 옆 체크박스를 채웠다면 코스가 완료된 것으로 기록됩니다. 다음 학습은 홈의 "이어서 학습하기" 패널에서 추천 흐름으로 보입니다.

수고하셨습니다.