노션 Database 대용량 릴레이션이 느려지는 이유｜병목 현상과 최적화 방법

노션 데이터베이스를 처음 만들 때는 Relation을 여러 개 연결해도 크게 불편하지 않습니다. 프로젝트와 업무를 연결하고, 담당자를 연결하고, 필요한 값은 Rollup으로 가져오면 꽤 편리합니다.

그런데 데이터가 계속 쌓이면 상황이 달라집니다.

처음에는 프로젝트 10개와 업무 100개 정도였던 데이터베이스가 몇 년 동안 사용되면서 수천 건으로 늘어나고, Relation과 Rollup까지 계속 추가되면 구조를 파악하는 것부터 어려워질 수 있습니다.

이럴 때 무조건 Relation을 삭제하기보다는 어디에서 불필요한 연결이 만들어지고 있는지부터 확인하는 것이 좋습니다.

먼저 데이터 구조를 그려봤습니다

예를 들어 노션으로 프로젝트 업무를 관리한다고 가정해보겠습니다.

구조는 다음과 같습니다.

고객사 DB
   ↓
프로젝트 DB
   ↓
업무 DB
   ↓
작업기록 DB

프로젝트 DB에는 고객사를 연결하고, 업무 DB에서는 프로젝트를 연결합니다. 작업기록 DB에서는 다시 업무를 Relation으로 연결합니다.

여기까지만 보면 크게 복잡하지 않습니다.

그런데 실제 사용하다 보면 요구사항이 하나씩 추가됩니다.

업무 DB에서 고객사도 바로 보고 싶고, 프로젝트 담당자도 표시하고 싶고, 작업기록 개수와 마지막 작업일까지 확인하고 싶어집니다.

그러면서 Relation과 Rollup 속성이 계속 늘어납니다.

제가 먼저 확인하는 것은 중복 Relation입니다

다음과 같은 구조를 생각해보겠습니다.

프로젝트 DB

프로젝트명 / 고객사 / 담당자

업무 DB

업무명 / 프로젝트 / 고객사 / 프로젝트 담당자 / 상태

여기에서 업무 DB의 프로젝트를 통해 이미 고객사와 담당자를 확인할 수 있는데 고객사와 담당자를 다시 직접 입력하고 있다면 문제가 생길 수 있습니다.

예를 들어 프로젝트 담당자가 김대리에서 이대리로 변경됐는데 업무 DB에 입력해놓은 담당자는 김대리로 그대로 남을 수 있습니다.

결국 같은 정보를 두 군데에서 관리하게 됩니다.

그래서 Relation을 만들기 전에 저는 다음을 먼저 확인합니다.

“이 데이터의 기준이 되는 데이터베이스는 어디인가?”

프로젝트 담당자라면 프로젝트 DB를 기준으로 관리하고 다른 데이터베이스에서는 필요한 방식으로 참조하는 편이 관리하기 쉽습니다.

데이터가 많다고 무조건 느려지는 것은 아닙니다

여기서 주의해야 할 부분도 있습니다.

1,000건 이상이면 느려진다 또는 Relation이 10개 이상이면 느려진다처럼 특정 숫자를 기준으로 성능을 단정하기는 어렵습니다.

같은 5,000개의 페이지가 있어도 데이터베이스 구조와 사용하는 뷰, Formula, Rollup, 필터 등의 구성에 따라 사용 경험은 달라질 수 있습니다.

따라서 단순히 페이지 개수만 보고 문제를 판단하기보다 데이터가 늘어나면서 어떤 계산과 연결이 함께 늘어났는지 확인해야 합니다.

Relation보다 Rollup이 복잡해지는 경우도 확인합니다

예를 들어 프로젝트 하나에 업무가 100개 연결되어 있다고 가정해보겠습니다.

프로젝트 DB에서 다음 정보를 전부 Rollup으로 가져오도록 만들어놓았다고 해보겠습니다.

전체 업무 수 / 완료 업무 수 / 담당자 / 최근 작업일 / 마감일 / 작업시간 / 검토 상태

실제로 모두 필요한 값이라면 사용할 이유가 있습니다.

하지만 단순히 나중에 사용할 것 같다는 이유로 만들어놓고 실제 화면에서는 전혀 확인하지 않는 Rollup도 생길 수 있습니다.

이런 속성은 데이터베이스를 복잡하게 만들 뿐 아니라 나중에 구조를 수정할 때 무엇과 연결되어 있는지 파악하기 어렵게 만듭니다.

그래서 저는 사용하지 않는 Rollup부터 확인합니다.

문제가 생긴 구조와 정리한 구조 비교

예를 들어 처음 구조가 다음과 같았다고 해보겠습니다.

업무 DB
 ├─ 프로젝트 Relation
 ├─ 고객사 Relation
 ├─ 담당자 Relation
 ├─ 작업기록 Relation
 ├─ 고객사 Rollup
 ├─ 프로젝트 담당자 Rollup
 ├─ 작업횟수 Rollup
 ├─ 최근 작업일 Rollup
 └─ 진행률 Formula

업무 화면에서 실제로 필요한 것은 프로젝트, 담당자, 상태, 마감일뿐이었다고 가정하겠습니다.

그러면 구조를 다시 검토해볼 수 있습니다.

업무 DB
 ├─ 프로젝트 Relation
 ├─ 담당자
 ├─ 상태
 ├─ 마감일
 └─ 필요한 계산 속성

중요한 것은 두 번째 구조가 항상 정답이라는 뜻이 아닙니다.

업무 목적에 따라 고객사 Relation이나 작업기록 Relation이 반드시 필요할 수도 있습니다.

핵심은 만들 수 있으니까 연결한다가 아니라 실제 업무에서 사용하는 연결인지 확인하는 것입니다.

오래된 완료 데이터를 어떻게 할지도 생각해봅니다

몇 년 동안 사용한 업무 DB라면 완료된 업무가 상당히 많이 쌓일 수 있습니다.

현재 진행 중인 업무는 200건인데 과거 완료 업무가 수천 건 남아 있는 식입니다.

이때 바로 오래된 데이터를 삭제할 필요는 없습니다.

오히려 과거 기록이 필요한 업무라면 삭제하면 안 됩니다.

대신 현재 업무와 과거 기록을 동일한 방식으로 계속 보여줄 필요가 있는지 확인합니다.

예를 들어 진행 중, 이번 달 완료, 과거 완료처럼 뷰와 필터를 나눠 현재 작업에 필요한 데이터에 집중하도록 구성할 수 있습니다.

업무 성격에 따라서는 별도의 보관 구조를 검토할 수도 있습니다.

메인 화면에는 필요한 속성만 보여줍니다

데이터베이스 구조가 복잡할수록 화면까지 복잡하게 만들 필요는 없습니다.

제가 메인 업무 뷰를 만든다면 우선 다음 정도만 표시합니다.

업무명 | 상태 | 담당자 | 마감일 | 프로젝트

고객사 정보나 상세 작업기록, 계산 결과 등은 필요한 페이지나 별도의 뷰에서 확인합니다.

속성을 화면에서 숨기는 것 자체가 데이터 처리량을 줄인다고 단정할 수는 없지만, 적어도 실제 사용자가 필요한 정보를 빠르게 파악하는 데는 도움이 됩니다.

성능 최적화와 사용 화면 최적화를 구분해서 생각하는 것이 좋습니다.

Formula까지 연결되어 있다면 더 조심해야 합니다

Relation을 정리할 때 바로 삭제 버튼부터 누르면 안 되는 이유가 있습니다.

해당 Relation을 Rollup이 참조하고 있고, 그 Rollup을 다시 Formula가 사용하고 있을 수 있기 때문입니다.

예를 들어 다음과 같은 구조입니다.

프로젝트 Relation
       ↓
완료 업무 Rollup
       ↓
진행률 Formula

여기서 중간 속성을 무작정 제거하면 마지막 Formula까지 영향을 받을 수 있습니다.

그래서 실제 데이터베이스를 수정할 때는 다음 순서로 확인하는 편이 안전합니다.

Relation → Rollup → Formula → 자동화 → API

특히 Make, Zapier 또는 직접 만든 API 프로그램까지 연결되어 있다면 속성 이름 하나를 바꾸는 것도 기존 자동화에 영향을 줄 수 있습니다.

대용량 DB를 정리할 때 제가 사용하는 순서

한꺼번에 데이터베이스를 뜯어고치는 방법은 권하지 않습니다.

먼저 현재 Relation을 확인하고 각각 어디에서 사용하는지 적어봅니다.

그다음 사용하지 않는 Rollup과 Formula를 확인합니다.

삭제 후보가 생겼다면 실제 DB에서 바로 지우지 말고 복제하거나 테스트 환경에서 먼저 확인합니다.

문제가 없다면 하나씩 실제 구조에 적용합니다.

정리하면 다음 순서입니다.

1. Relation 목록 확인
        ↓
2. 연결된 Rollup 확인
        ↓
3. Formula 참조 확인
        ↓
4. 자동화/API 연결 확인
        ↓
5. 테스트
        ↓
6. 실제 DB 반영

이렇게 하면 문제가 발생했을 때 어느 단계에서 잘못됐는지 찾기도 쉽습니다.

Relation 개수만 줄이는 것이 최적화는 아닙니다

대용량 노션 데이터베이스를 최적화한다고 해서 Relation을 최대한 적게 만드는 것이 목표가 되어서는 안 됩니다.

필요한 Relation까지 제거하면 오히려 데이터를 중복 입력하게 되고 관리가 더 어려워질 수 있습니다.

제가 생각하는 기준은 간단합니다.

“이 Relation을 왜 만들었는지 설명할 수 있는가?”

사용 목적을 설명하기 어려운 Relation이라면 다시 확인할 필요가 있습니다.

반대로 데이터의 관계를 명확하게 만들어주는 Relation이라면 데이터가 많다는 이유만으로 제거할 필요는 없습니다.

마무리

노션에서 대용량 데이터베이스를 관리하다 보면 Relation, Rollup, Formula가 자연스럽게 늘어납니다.

처음에는 편리했던 구조가 데이터가 쌓이면서 관리하기 어려운 구조로 바뀌기도 합니다.

이럴 때는 단순히 Relation 숫자를 줄이는 것보다 기준 데이터가 어디에 있는지, 같은 정보를 여러 곳에서 관리하고 있지는 않은지, 사용하지 않는 Rollup과 Formula가 남아 있지는 않은지부터 확인해보는 것이 좋습니다.

결국 관리하기 좋은 데이터베이스는 기능이 가장 많은 데이터베이스가 아니라 데이터가 어디에서 만들어지고 어떤 경로로 연결되는지 쉽게 파악할 수 있는 데이터베이스입니다.