데우스랠리 데이터 저장 구조 고민

처음에는 전에 잘 맞았던 구조를 재사용하는 게 합리적이라고 생각했어요. 데우스랠리도 타임라인과 모션을 다루는 에디터였고 flatTree를 쓰면 노드 단위 접근과 수정이 단순해질 거라 봤어요. MobX observable 관점에서도 중첩 객체의 중간값을 감시하기보다 납작한 객체 단위를 감시하는 편이 더 유리해 보였어요. 하지만 데우스랠리는 Rally Editor보다 데이터 흐름이 복잡했어요. Deus에서 내려오는 원본 데이터, 플러그인 내부 store, 프리뷰, 코드젠, 저장 동기화가 함께 움직여야 했기 때문에 데이터 구조 선택이 기능 개발과 협업 속도에 곧바로 영향을 줬어요.

데이터 구조는 id 접근 성능만이 아니라 원본 데이터 형태, 변환 비용, 팀의 이해 가능성을 함께 기준으로 비교했어요. Rally Editor에서 잘 맞았던 flatTree 구조가 데우스랠리의 입력 데이터와 협업 방식에도 맞는지 실제 설계에 적용해보며 확인했어요. 생성, 삭제, 복제 과정에서 parent-child 관계와 중첩된 자식 관계를 직접 관리해야 하는 비용이 드러났어요. Deus에서 내려오는 원본 데이터가 이미 트리 구조였기 때문에, 내부 store도 원본과 가까운 구조로 유지하는 방향을 선택했어요.

flatTree를 쓰면 Deus에서 내려온 트리 데이터를 굳이 flatten해서 다뤄야 했어요. 프리뷰나 코드젠처럼 계층 관계가 필요한 곳에서는 flatten된 데이터를 다시 관계 중심으로 복원하는 일이 계속 따라붙었어요. 자식 노드를 다룰 때마다 부모 참조를 일일이 갱신하는 손이 들어갔고요. 함께 작업하던 동료가 구조가 계속 헷갈린다는 의견을 줬고 기능 개발 과정에서도 flatTree가 병목이 되고 있다는 걸 체감했어요. 처음 flatTree를 제안한 건 저였지만 제 선택이 지금 제품 맥락에는 맞지 않는다고 인정하고 트리 구조로 되돌리는 방향을 제안했어요.

flatTree를 적용해본 뒤 트리 구조로 롤백했어요. id 기반 단일 노드 접근이라는 편의는 매력적이었지만, 그 이점만으로는 데우스랠리의 데이터 흐름을 감당하기 어려웠어요. 원본이 이미 트리였고 계층 관계가 필요한 지점마다 복원 비용이 따라붙는 상황에서는, 원본 구조와 가깝고 팀이 이해하기 쉬운 쪽이 더 나은 선택이었어요. 결국 id 접근의 편의보다 원본 구조와의 정합성, 그리고 팀의 이해 가능성을 우선에 둔 판단이었어요.

트리 구조로 돌아가면서 flatTree의 id 기반 단일 노드 접근 편의성은 일부 내려놓았어요. 대신 parent-child 관계가 코드 구조에 자연스럽게 드러나고 팀이 이해하고 리뷰하기 쉬운 구조를 얻었어요.

롤백 이후 가장 크게 회복된 건 동료와의 커뮤니케이션이었어요. 데이터 구조를 설명하기 쉬워졌고 기능을 어느 위치에 추가할지도 더 명확해졌어요. Deus에서 내려오는 원본 데이터 구조와 내부 store 구조가 가까워지면서 불필요한 변환 부담도 줄었어요. 단일 책임 같은 전통적인 좋은 코드 기준도 트리 구조에서 더 쉽게 설명하고 적용할 수 있었어요.

전에 잘 맞았던 구조라도 새 제품의 입력 데이터와 협업 맥락에 맞지 않으면 과감히 버릴 수 있어야 한다는 걸 배웠어요. 좋은 구조는 아이디어만 좋아서는 부족하고 팀원이 이해할 수 있고 기능 개발 속도를 계속 지탱할 수 있어야 해요. 내가 먼저 제안한 구조라도 실제 개발 과정에서 병목이 된다면, 그 선택이 잘못됐다는 걸 인정하고 되돌리는 판단이 필요했어요.

다음에 비슷한 선택을 한다면 먼저 원본 데이터의 형태, 변환 비용, 팀의 숙련도, 리뷰 가능성을 같이 보려고 해요. 특히 에디터처럼 데이터 구조가 기능 개발 전체에 영향을 주는 경우에는, 이론적으로 좋아 보이는 구조보다 팀이 계속 유지할 수 있는 구조인지 더 일찍 검증해보고 싶어요.