Vision Pro 의료 프로젝트에서 도메인을 먼저 정의한 이유

— HIPPO의 DDD 기반 멀티플랫폼 설계

시작은 기술 검증(PoC)이었다

HIPPO 프로젝트는 의료 수술 환경에서 사용할 수 있는 기술을 검증하는 것에서 출발했다.

처음에 우리가 궁금했던 것은 비교적 단순한 질문들이었다. Vision Pro에서 수술용 3D 모델을 안정적으로 렌더링할 수 있을지, 내시경 영상을 실시간으로 받아 화면에 자연스럽게 보여줄 수 있을지였다.

이런 질문들에 답하기 위해, 초반에는 자연스럽게 흐름이 나뉘었다.

• Vision Pro에서의 3D 모델링과 렌더링을 검증하는 흐름
• 내시경 영상 스트리밍을 검증하는 흐름

각각의 흐름은 빠르게 “되는지 안 되는지”를 확인하는 데 집중했고, 이 단계에서는 구조보다는 속도가 더 중요하게 느껴졌었다.

하나의 프로젝트로 합쳐야 하는 시점

기술 검증이 어느 정도 진행되면서, 각각의 결과물을 하나의 프로젝트로 묶어야 할 시점이 찾아왔다.

하나의 Vision Pro 앱, 하나의 macOS 앱, 그리고 하나의 GitHub 레포지토리로 관리해야 하는 상황이었다.

이 과정에서 단순히 코드를 합치는 것 이상의 고민들이 자연스럽게 생기기 시작했다.

예를 들어, 환자 정보는 더 이상 ‘주어진 데이터’가 아니라 누가 생성하고, 어디에서 수정하며, 어느 플랫폼이 책임져야 하는지 명확히 정리되어야 하는 도메인이었다.

또 Vision과 Mac은 역할은 다르지만, 동일한 환자와 수술 데이터를 함께 다루게 되면서 이 데이터를 어떤 방식으로 공유하고, 어디를 단일한 기준으로 삼을 것인지도 고민이 필요해졌다.

그리고 이런 질문들은 결국, 공통으로 가져갈 로직과 플랫폼에 남겨둘 로직의 경계를 어디까지로 잡을지에 대한 고민으로 이어졌다.

이 지점에서 상황을 간단한 그림으로 정리해보면 다음과 같다.

• PoC 단계에서는 각 플랫폼이 자기 역할만 잘 수행하면 되는 구조였다.
• 하지만 하나의 제품으로 묶이면서부터는 환자 정보와 수술 데이터가 플랫폼을 넘나드는 공통의 도메인이 되기 시작했다.

그리고 이런 질문들은 결국, 공통으로 가져갈 로직과 플랫폼에 남겨둘 로직의 경계를 어디까지로 잡을지에 대한 고민으로 이어졌다.

도메인을 먼저 정의하자고 판단한 이유

이 시점에서 내린 판단은, 기능을 더 추가하기 전에 도메인부터 정리해보자는 것이었다. 이 선택은 어떤 이상적인 설계 원칙 때문이라기보다는, 당시 프로젝트가 마주하고 있던 아주 현실적인 문제들에서 비롯되었다.

1. 팀이 나뉘어 있을수록, 공통 언어가 먼저 필요했다 기술 검증을 위한 흐름이 어느 정도 정리된 이후, 마침 디자인도 로우파이에서 하이파이로 넘어가던 단계에 들어서게 되었다.

화면 구조와 사용자 흐름이 구체화되면서, 팀 안에서는 UI 화면에 이름을 붙이고 같은 화면을 같은 이름으로 부르려는 시도를 하고 있었다.

다만 이 과정에서, 같은 대상을 두고 이야기하고 있음에도 서로 사용하는 용어가 조금씩 다르다는 점을 처음으로 인식하게 되었다.

같은 화면이나 같은 데이터를 가리키고 있었지만, 각자 익숙한 표현으로 설명하다 보니 처음 이 이야기를 들었을 때는 조금 헷갈리고 어렵게 느껴지는 순간들이 있었다.

지금 돌아보면, 이 과정에서 작은 소통의 어려움은 분명히 있었지만, 그 원인은 개인의 이해나 협업 방식이라기보다는 프로젝트 안에서 사용하는 개념들이 아직 하나의 기준으로 정리되지 않았기 때문이라고 생각했다.

그래서 화면이나 기능을 더 확장하기 전에, 먼저 이 프로젝트에서 사용할 용어와 개념을 공통으로 정의해두는 것이 필요하겠다고 생각했다.

도메인을 먼저 정리하자는 판단은, 이런 흐름 속에서 나오게 되었다.

2. 멀티플랫폼에서는 기준이 하나 필요했다 Vision Pro와 macOS는 역할과 구현은 달랐지만, 같은 환자와 수술 데이터를 함께 다루고 있었다.

이 데이터를 어떻게 이해할지에 대한 기준은 플랫폼보다 먼저 정리되어야 한다고 느꼈다.

3. PoC를 넘어서며 판단 기준이 필요해졌다 PoC 단계에서는 속도가 중요했지만, 결과물을 하나의 레포지토리로 합치면서부터는 구조를 유지할 기준이 필요해졌다. 도메인은 그 기준이 되어주었다.

4. 기술은 바뀔 수 있어도, 도메인은 남는다 저장 방식이나 동기화 기술은 바뀔 수 있지만, 환자와 수술이라는 개념은 남는다. 그래서 도메인은 기술 선택과 분리해두는 편이 낫다고 판단했다.

우리가 정의한 도메인

도메인을 정리하는 첫 단계는 복잡한 구조를 그리는 것이 아니라, 이 프로젝트에서 다루는 개념을 단순하게 나열해보는 것이었다.

우리는 노션에서 아주 기본적인 도메인부터 적어 내려가기 시작했다.

• Patient
• Operation

처음부터 완벽한 모델을 만들겠다는 생각은 없었다. 다만 같은 대상을 같은 이름으로 부르기 위한 최소한의 기준이 필요했다.

이 정의를 바탕으로, 코드에서는 다음과 같은 방향으로 구조가 정리되었다.

• Patient를 Aggregate Root로 두고
• Operation은 항상 Patient의 맥락 안에서만 존재하도록 구성했다
• 수술에 사용되는 3D 모델이나 파일은 단순한 URL이 아니라, OperationAsset이라는 도메인 엔티티로 취급했다

특히 OperationAsset은 처음에는 “조사 필요”로 남겨두었던 영역이었다. 하지만 CloudKit 동기화와 파일 관리까지 고려하게 되면서, 단순한 부가 데이터가 아니라 수술이라는 맥락을 가진 도메인 객체로 다루는 편이 더 적절하다고 판단했다.

Patient–Operation–Asset 관계 다이어그램

멀티플랫폼과 Shared Architecture

도메인을 정의하고 나니, 다음으로 고민해야 할 것은 이 도메인을 어디에 둘 것인가였다.

HIPPO는 Vision Pro와 macOS를 함께 사용하는 멀티플랫폼 구조였다. 두 플랫폼은 역할과 구현 방식은 달랐지만, 환자와 수술이라는 도메인은 동일하게 사용하고 있었다.

이 상황에서 선택지는 단순했다.

• 각 플랫폼마다 도메인을 복제해서 관리할 것인가
• 아니면 공통으로 사용하는 영역을 분리할 것인가

두 번째를 선택했다.

도메인을 플랫폼에 종속시키기보다, 플랫폼이 도메인을 사용하도록 구조를 나누는 편이 지금 상황에 더 맞다고 판단했다.

그래서 HIPPO는 Shared 영역을 중심으로 한 구조를 선택하게 되었다.

Shared Domain을 중심으로 한 멀티플랫폼 구조

Shared 영역을 선택하면서, 무엇을 공통으로 가져갈지보다 무엇을 의도적으로 가져가지 않을지가 더 중요해졌다.

HIPPO에서 Shared에 포함된 것은 다음과 같다.

• 환자와 수술을 표현하는 도메인 엔티티
• 도메인을 다루는 UseCase
• 플랫폼 간 상태와 흐름을 조율하는 ViewModel

반대로, 다음 것들은 Shared에서 제외했다.

• visionOS 전용 UI와 공간 렌더링 로직
• 내시경 스트리밍 송수신 파이프라인
• 각 플랫폼에 종속된 입력 장치와 인터랙션 처리

Shared는 “재사용을 위한 공간”이 아니라, 공통으로 책임져야 할 것만 남기기 위한 경계였다.

아직은 테스트 중이다

이 구조는 아직도 계속 조정 중이고, 앞으로 바뀔 가능성도 충분히 있다.

하지만 하나 확실해진 점은, 도메인을 중심으로 구조를 잡아둔 선택 자체는 쉽게 흔들리지 않을 것 같다는 점이다.

다음 글에서는: 내시경 스트리밍 파이프라인을 어떻게 분리했는지를 다뤄볼까 한다.

아직도 계속 바뀌고 있는 구조이지만, 그때그때 어떤 고민을 했고 왜 그런 선택을 했는지를 남겨두는 것이 의미가 있을 것 같아 글로 정리해보았다.

이 글은 HIPPO 팀이 기술 검증으로 시작한 프로젝트를 진행하며, 구조를 정리해온 과정을 기록한 글이다.