노션 Relation·Rollup 설정: 프로젝트별 업무 수·진행률 계산

Notion 웹·데스크톱 기준 · 공식 도움말 확인: 2026년 10월 10일

Relation·Rollup·Formula의 역할을 먼저 구분하세요

Notion에서 데이터베이스 간 숫자나 상태가 맞지 않을 때는 속성을 더 추가하기 전에 세 기능의 역할을 확인합니다. Relation은 한 데이터베이스의 페이지를 다른 데이터베이스 페이지와 연결합니다. 예를 들어 업무 페이지에서 프로젝트 페이지를 선택하면, 업무가 어떤 프로젝트에 속하는지 데이터 관계가 저장됩니다.

Rollup은 그 연결을 따라가서 관련 페이지의 특정 속성을 보여 주거나 계산합니다. 프로젝트와 연결된 업무 제목을 세거나, 업무의 예상 시간을 더하고, 가장 늦은 마감일을 표시할 수 있습니다. Formula는 연결된 업무의 상태가 ‘완료’인지 직접 검사해 완료 건수 또는 백분율 같은 조건 계산을 만듭니다. 따라서 업무를 먼저 Relation으로 묶지 않으면 프로젝트에서 해당 업무들을 집계할 수 없습니다.

프로젝트 DB와 업무 DB를 나눌 때와 합칠 때

프로젝트와 할 일이 같은 정보를 공유하고 항목 수도 적다면 한 데이터베이스에 프로젝트 행과 업무 행을 모두 넣을 수 있습니다. 다만 프로젝트 요약과 실제 할 일의 속성·상태·마감일이 섞이면 보기마다 불필요한 열이 늘고 잘못된 행을 편집하기 쉽습니다. 프로젝트에 여러 업무가 달리고 프로젝트별로 수나 시간을 집계하려면 두 데이터베이스를 나누는 편이 이해하기 쉽습니다.

다음 조건이면 분리 구성이 유용합니다. 프로젝트마다 업무가 여러 개이고, 업무에는 개별 담당자·상태·마감일이 있으며, 프로젝트 화면에서는 여러 업무를 한 번에 비교해야 하는 경우입니다. 반면 분기별 프로젝트 하나와 체크 항목 몇 개만 관리하고 집계도 필요하지 않다면 기존 표 하나로 시작해도 됩니다. Relation을 쓴다는 이유만으로 작은 목록을 복잡하게 설계하지 마세요.

Notion 실무 글의 업무 보드 기본 구성은 상태·담당자·마감일을 한 업무 데이터베이스로 운영하는 시작점입니다. 이 글은 그 보드에 프로젝트 데이터베이스를 하나 더 두고 연결·집계를 추가하는 확장 단계입니다. 데이터베이스에 어떤 항목이 있는지 먼저 점검하려면 Notion 항목이 보기에서 사라졌을 때의 필터·권한 진단도 참고하세요.

합성 데이터로 기대할 결과부터 정합니다

먼저 개인정보나 실제 업무 기록을 쓰지 말고 테스트용 프로젝트와 업무를 만듭니다. 프로젝트 DB에는 프로젝트명, 프로젝트 상태, 업무 Relation을 둡니다. 업무 DB에는 업무명, 프로젝트 Relation, 상태, 예상 시간, 마감일을 둡니다. 공식 데이터베이스 속성 도움말에 나오는 Title·Status·Number·Date·Relation 유형을 활용합니다.

완료 상태는 5개 중 2개입니다. 사이트 개편은 업무 3건, 예상 시간 6시간, 완료 1건이므로 1 ÷ 3을 계산한 약 33%입니다. 신규 매장 준비는 업무 2건, 3시간, 완료 1건이므로 50%입니다. 업무 DB의 각 프로젝트 연결이 정확하다는 조건에서 이 결과가 나와야 합니다. 이후 설정을 하나씩 마칠 때마다 예상 숫자와 대조하면 속성 메뉴에서 잘못된 대상을 고른 일을 찾기 쉽습니다.

업무 데이터베이스에 프로젝트 Relation을 만듭니다

1. 업무 데이터베이스를 열고 새 속성을 추가한 뒤 유형에서 Relation을 선택합니다. 속성 이름은 프로젝트처럼 연결 방향이 명확하게 정합니다.
2. 대상 데이터베이스로 프로젝트를 검색해 선택합니다. 동명 페이지나 링크드 데이터베이스가 여러 개라면 이름만 보지 말고 원본 데이터베이스를 확인합니다.
3. 미리보기에서 연결 대상이 올바른지 확인하고 Add relation을 눌러 저장합니다. 이제 업무 행의 프로젝트 칸에서 테스트 프로젝트를 고를 수 있습니다.
4. 프로젝트 DB에도 반대 방향을 표시하려면 Show on [프로젝트 데이터베이스] 또는 유사한 양방향 표시 옵션을 켭니다. 반대편 속성명은 업무로 지정합니다.
5. 업무 DB의 테스트 행 세 개에서 각각 사이트 개편을 연결합니다. 프로젝트 DB의 업무 Relation 속성에도 그 세 행이 나타나는지 확인합니다. 나머지 두 행은 신규 매장 준비에 연결되어야 합니다.

두 데이터베이스 사이의 Relation은 처음 만들 때 한 방향으로 구성될 수 있습니다. 프로젝트에서 관련 업무를 보려면 대상 데이터베이스에도 대응 속성을 표시하도록 설정해야 합니다. 두 방향 속성은 같은 관계를 다른 화면에서 편집할 수 있게 해 줍니다. 프로젝트의 Relation을 고칠 때 업무 DB의 대응 속성도 바뀌는지 합성 데이터로 확인하고, 이름이 비슷한 별도 속성을 실수로 추가하지 않도록 합니다.

업무 하나가 한 프로젝트에만 속하면 연결 수를 제한합니다

프로젝트 칸에서 항목을 골랐는데 실수로 프로젝트 두 개가 연결되면 프로젝트별 업무 수와 시간 합계가 각각 중복되어 보일 수 있습니다. 업무 한 건이 반드시 프로젝트 하나에만 속하는 운영이라면 업무 DB의 프로젝트 Relation 속성 설정에서 연결 가능한 페이지를 1 page로 제한합니다. 이후 각 업무 행은 한 프로젝트만 고를 수 있습니다.

이 제한은 프로젝트마다 업무 수를 제한하는 설정이 아닙니다. 한 프로젝트에는 여러 업무를 연결할 수 있고, 각 업무의 프로젝트 Relation에서 선택 가능한 대상 수를 하나로 제한하는 것입니다. 하나의 공통 업무가 두 프로젝트에 동시에 포함되거나 여러 고객을 위해 동일한 작업을 연결해야 한다면 No limit이 맞을 수 있습니다. 이때 Rollup은 프로젝트별 연결 페이지를 각각 집계하므로 같은 업무가 여러 프로젝트 합계에 포함된다는 점을 팀에 알려 주세요.

연결 개수 제한을 바꿀 때 이미 저장된 Relation이 어떻게 보이는지 현재 UI에서 확인하세요. 관계 구조를 바꾸기 전에 테스트용 데이터베이스에서 먼저 재현하고, 한 건을 바꾸어 다른 쪽 데이터베이스에서도 일관되게 표시되는지 확인합니다.

프로젝트별 업무 건수 Rollup을 설정합니다

1. 프로젝트 DB의 업무 Relation 옆에서 새 속성을 추가하고 유형을 Rollup으로 정합니다.
2. 집계할 Relation 속성으로 업무를 선택합니다.
3. 관련 업무 페이지에서 읽어 올 속성은 업무명인 Title 속성을 고릅니다. 프로젝트마다 이름을 알 수 없는 항목을 집계하지 않으려면 업무명 값이 있는지 확인합니다.
4. 계산은 Count all로 지정하고 속성명을 업무 수로 바꿉니다.

Title 속성은 각 업무 페이지를 구분하는 이름이므로 이 예시에서 Count all 결과는 사이트 개편 3, 신규 매장 준비 2가 됩니다. Status처럼 비어 있을 수 있는 속성을 선택해 Count values를 쓰면 상태가 빠진 업무는 건수에서 누락될 수 있습니다. 한편 Count values는 선택한 속성이 비어 있지 않은 값의 수를 셉니다. “전체 업무 수”를 세려는 것인지 “상태가 입력된 업무 수”를 세려는 것인지 먼저 결정한 뒤 속성과 집계 방식을 고릅니다.

프로젝트 DB 표의 아래쪽에서 전체 합계를 볼 필요가 있으면 해당 Rollup 열의 계산 메뉴에서 Sum을 선택할 수 있습니다. 이 표 전체 합계는 각 프로젝트의 업무 수를 더한 값입니다. 하나의 업무를 여러 프로젝트에 연결했다면 프로젝트별 합계에서 같은 업무가 두 번 포함되는 것은 의도된 결과일 수 있습니다.

예상 시간 합계와 가장 늦은 마감일을 집계합니다

프로젝트마다 예정된 작업량을 비교하려면 두 번째 Rollup을 만듭니다. 프로젝트 DB에서 속성 추가 → Rollup → Relation 업무 → 업무 DB의 예상 시간 속성 → 계산 Sum 순으로 고릅니다. 샘플 데이터에서는 사이트 개편이 3+2+1로 6시간, 신규 매장 준비가 2+1로 3시간이어야 합니다. 값이 비어 있는 업무는 합계에서 빠질 수 있으므로 입력 누락은 별도의 확인 열이나 보기로 찾습니다.

예상 시간 대신 실제 지출액을 관리한다면 Number 속성의 합계·평균·최솟값·최댓값 등 공식 Rollup 계산을 사용할 수 있습니다. 다만 금액은 통화 단위를 통일한 뒤 합산하세요. 원화와 달러가 한 열에 함께 들어가면 단순 합계가 의미를 잃습니다. 숫자를 텍스트로 붙여 넣거나 셀 안에 3시간이라고 저장하면 수치 계산이 어렵기 때문에 Number 속성에 3을 입력하고 단위는 이름 또는 표시 형식으로 구분합니다.

업무 DB의 Date 속성도 집계할 수 있습니다. 마감일이 가장 빠른 업무를 보고 싶으면 Earliest date, 일정상 가장 나중인 날짜를 보고 싶으면 Latest date를 선택합니다. 아무 업무에도 날짜를 넣지 않은 프로젝트는 결과가 비어 있을 수 있습니다. 이를 ‘지연 없음’으로 해석하지 말고 마감일 미입력과 날짜가 집계된 상태를 구분하세요.

완료 건수와 프로젝트 진행률은 Formula 2.0으로 계산합니다

업무 상태가 완료·진행 중·할 일로 나뉘면 Status 속성을 그냥 Count values로 세는 것만으로는 완료 업무 수를 알 수 없습니다. Relation을 따라가서 각 업무의 상태가 정확히 완료인지 검사해야 합니다. Notion Formula 2.0은 Relation에서 연결 페이지 목록을 읽고 map()과 filter(), length()를 사용해 완료된 항목 수를 구할 수 있습니다.

프로젝트 DB에서 Formula 속성을 추가하고 이름을 완료 업무 수로 정한 뒤 다음 공식을 입력합니다. 공식에서 참조하는 속성 이름은 사용자가 실제 데이터베이스에 지정한 이름과 정확히 같아야 합니다.

prop("업무").map(current.prop("상태")).filter(current == "완료").length()

프로젝트별 완료 비율을 표시하는 Formula 속성에는 아래 계산을 사용할 수 있습니다. 업무가 아직 하나도 연결되지 않은 프로젝트는 0으로 반환해 0으로 나누는 오류를 피합니다.

lets(
  total, prop("업무").length(),
  done, prop("업무").map(current.prop("상태")).filter(current == "완료").length(),
  if(total == 0, 0, round(done / total * 100))
)

사이트 개편은 1/3이라 33, 신규 매장 준비는 1/2라 50이 나옵니다. 속성 이름에 진행률 (%)이라고 표시하거나 Formula 결과가 백분율임을 도움말에 적어 숫자 50을 0.5%로 오해하지 않게 합니다. Notion Formula 편집기의 미리보기와 Show types 표시를 확인하세요. 완료 상태 이름을 완료됨처럼 다르게 만들었다면 공식 문자열도 같은 값으로 고쳐야 합니다.

위 공식은 완료 건수로 진행률을 계산합니다. 우선순위나 예상 시간 가중치가 다르면 완료율과 업무량 진척이 같은 뜻이 아닙니다. 예를 들어 전체 10시간 중 8시간짜리 업무 하나가 완료되고 1시간짜리 두 개가 남으면 건수 완료율은 33%지만 예상 시간 기준 완료율은 80%입니다. 어떤 지표를 의사결정에 쓸지 정한 뒤 공식의 분자·분모를 설계하세요. 이 공식은 실제 결과를 대신 측정하는 회계 값이나 계획 준수율을 자동 인증하지 않습니다.

프로젝트 화면과 업무 화면을 각각 정리합니다

프로젝트 DB에는 한 행에 프로젝트명·상태·업무 수·예상 시간 합계·진행률을 배치합니다. 업무 DB에는 업무명·프로젝트·담당자·상태·마감일·예상 시간을 표시합니다. 프로젝트 표는 상태별로 묶거나 진행률 기준으로 정렬하고, 업무 DB에는 ‘전체 업무’, ‘내 업무’, ‘마감 임박’처럼 별도 보기를 만들 수 있습니다.

Notion의 각 데이터베이스 보기는 개별 필터와 정렬을 가집니다. 필터를 변경할 때는 해당 보기에서만 바꿀지 팀 모두에게 저장할지 판단하세요. 업무 보드에서 진행 중인 업무만 보이게 숨겨도, Relation에 연결된 페이지 관계를 지운 것은 아닙니다. 따라서 프로젝트 Rollup 값이 현재 화면에 보이는 행 수와 다를 수 있습니다. 전체 연결 수를 세는 집계와 필터 화면의 개수를 혼동하지 않도록 검산용 표 보기를 둡니다.

한 프로젝트 페이지 안에서 연결된 업무를 확인할 때는 프로젝트 페이지에 Relation 속성을 표시하거나 업무 데이터베이스의 링크드 뷰를 둘 수 있습니다. 링크드 뷰는 같은 데이터 소스를 다른 필터·정렬로 보여 주므로 원본 데이터베이스 구조가 복제되는 것은 아닙니다. 처음에는 프로젝트 두 개를 각각 열어 잘못 연결된 업무가 보이지 않는지 확인합니다.

Relation을 만들기 전후로 공유 범위를 점검합니다

Relation은 데이터를 연결하는 속성이지, 공유 정책을 검토하지 않아도 된다는 뜻은 아닙니다. 프로젝트 페이지가 웹에 공개됐거나 넓은 팀스페이스에 속해 있다면 Relation으로 연결한 업무 페이지에 민감한 정보, 고객 이름, 계약 금액, 내부 메모가 포함되어 있지 않은지 확인하세요. Notion은 넓게 공유된 페이지와 양방향 Relation으로 연결된 페이지가 공개 링크 페이지의 접근 경로에 영향을 줄 수 있다고 안내합니다.

1. 시험 페이지와 합성 업무로 Relation을 먼저 만들고 연결 양쪽의 공유 메뉴를 확인합니다.
2. 공개 링크나 전체 팀 공유가 켜져 있다면 실제로 공개해야 하는 프로젝트와 업무만 연결합니다.
3. 업무명과 Rollup으로 집계하는 속성에도 고객명·비공개 금액·사내 전용 값이 표시되지 않는지 확인합니다.
4. 권한을 바꾼 뒤 기존 멤버·게스트·시크릿 브라우저 등 의도한 읽기 범위로 접근을 점검합니다.

화면에서 속성을 숨기거나 뷰 필터를 걸었다고 접근 권한이 제한되는 것은 아닙니다. 누가 어떤 페이지를 읽고 편집할 수 있는지는 Notion의 Share 설정과 상속된 권한을 확인하세요. 자세한 초대·게스트·웹 공개 점검은 Notion 페이지 공유 권한 가이드에 정리되어 있습니다.

단순 집계는 Rollup, 조건 계산은 Formula가 편합니다

현재 프로젝트에서 업무명이 몇 개인지, 예상 시간이 몇 시간인지, 연결 업무의 가장 늦은 마감일이 언제인지처럼 한 속성을 읽고 집계하는 작업은 Rollup이 직관적입니다. 설정에서 Relation·대상 속성·계산 방식을 선택하면 결과가 표에 나타나므로 복잡한 공식을 유지할 필요가 없습니다.

‘완료’ 상태의 업무만 세기, 빈 업무 목록을 0으로 바꾸기, 완료율을 문구나 색상으로 표시하기처럼 조건이 들어가면 Formula 2.0이 더 유연합니다. 공식은 현재 Relation이 연결한 페이지를 읽어 계산할 수 있으므로 간단한 조건부 집계만을 위해 Rollup 열을 여러 개 추가할 필요가 없습니다. 반대로 공식이 길어져 다음 담당자가 계산을 이해하기 어렵다면 Count·Sum 등 표준 Rollup으로 줄일 수 있는지 먼저 검토합니다.

업무 수가 0이거나 예상 합계가 다를 때

• 프로젝트의 업무 Relation이 비어 있음: 업무 DB에서 각 행의 프로젝트를 지정했는지 확인합니다. 반대 방향 속성이 숨겨졌는지, 다른 원본 데이터베이스를 선택했는지도 봅니다.
• 업무 건수가 예상보다 적음: Rollup의 Relation이 올바른지, 대상 속성이 업무명인지, Count all인지 확인합니다. 값이 비어 있을 수 있는 Status를 세고 있지 않은지 검토합니다.
• 예상 시간 합계가 낮음: 예상 시간 속성이 Number인지 확인하고 빈 값과 숫자처럼 보이는 텍스트를 구분합니다. 날짜·금액·시간이 섞이지 않았는지도 확인합니다.
• 완료율이 0%: Formula가 읽는 Relation 이름·상태 속성 이름·완료 상태 텍스트가 실제 명칭과 정확히 맞는지 확인합니다. 상태 값에 앞뒤 공백이나 ‘Done’/‘완료’ 혼용이 있는지도 점검합니다.
• 완료율 분모가 다름: Relation 제한을 1개로 둔 상태에서 일부 업무에 프로젝트가 지정되지 않았는지 확인합니다. 반대로 No limit이라면 한 업무가 여러 프로젝트의 집계에 포함되는 것이 의도인지 살펴봅니다.
• 화면에 안 보이지만 집계에는 들어 있음: 업무 보기에 필터가 적용되어 있는지, 프로젝트의 원본 Relation은 그대로 연결되어 있는지 구분합니다. 필터는 뷰 표시 방식이며 원본 관계 자체를 자동 삭제하지 않습니다.

한 번에 여러 설정을 바꾸지 마세요. 먼저 업무 DB에서 샘플 프로젝트 Relation을 열고 5개 합성 업무 중 어떤 행이 연결되어 있는지 확인합니다. 그다음 Rollup의 대상 속성과 계산을 보고, 마지막으로 Formula 편집기의 오류와 미리보기 결과를 확인합니다. 이렇게 순서를 나누면 잘못된 연결, 빈 숫자, 공식의 상태 문자열을 따로 찾을 수 있습니다.

데이터베이스 복제·CSV 반입·내보내기에서 관계를 보존합니다

Relation이 설정된 데이터베이스를 통째로 복제하거나 다른 워크스페이스로 옮기기 전에는 프로젝트와 업무가 어떻게 연결되는지 별도 샘플로 확인하세요. Notion 도움말은 연결된 데이터베이스를 복제할 때 기존 양방향 관계가 한 방향으로 바뀔 수 있다고 설명합니다. 복제본의 Relation을 열고 반대 방향 속성이 존재하는지, 기존 프로젝트와 새 프로젝트 중 어디를 가리키는지 확인해야 합니다.

관계형 데이터베이스를 CSV로 내보내면 Relation 속성은 일반 텍스트 URL로 내보내지고, 그 CSV를 다시 가져와도 Notion이 기존 관계를 자동으로 복원하지 않습니다. 따라서 CSV만으로 프로젝트 연결을 백업했다고 생각하지 마세요. Notion에서 원본 업무·프로젝트 DB를 각각 내보내고, 합성 복사본으로 연결 복원 절차를 시험한 뒤, 업무 ID와 프로젝트 ID를 함께 보존해 수동 매핑할 계획을 세웁니다. Notion CSV 가져오기·중복 방지 안내는 새 데이터베이스 시험과 고유 ID 검산 절차를 다룹니다.

운영 DB에 적용하기 전 이 체크리스트로 검수합니다

1. 합성 프로젝트 2개와 업무 5개를 만들고, 업무 상태·예상 시간·마감일을 입력합니다.
2. 각 업무에서 프로젝트를 하나씩 선택하고 프로젝트 DB의 반대 방향 업무 목록을 확인합니다.
3. 한 업무에 프로젝트 2개를 붙일 수 있는지 시험하고, 운영 규칙에 맞게 1개 제한 또는 No limit을 정합니다.
4. Count all의 업무 수가 3와 2, Number Sum이 6시간과 3시간으로 나오는지 검산합니다.
5. Formula 완료 건수가 1과 1, 완료율이 33%와 50%로 계산되는지 확인합니다.
6. 미입력 마감일·상태·예상 시간 한 건을 일부러 만들고 빈 값이 건수·합계·Formula에 미치는 영향을 기록합니다.
7. 프로젝트와 업무 페이지의 Share 설정, 링크 공개, 상위 페이지 접근을 검수합니다.
8. 업무 보기에 필터를 적용해도 프로젝트의 원본 Relation과 집계가 유지되는지 확인합니다.
9. 복제 또는 CSV 이동이 필요하면 관계가 유지되지 않는 경우를 먼저 시험합니다.

합성 데이터에서 값이 맞은 뒤에만 운영 DB에 연결을 추가합니다. 배포 후에도 프로젝트 한 건을 정해서 업무 관계·롤업·완료율을 같은 순서로 다시 확인하고, 팀원에게 어떤 속성이 입력 기준인지 알려 주세요. 설정과 계산이 달라지면 Relation 이름이나 상태 값이 변경되었는지 먼저 기록하면 다음 유지보수에 도움이 됩니다.

자주 묻는 질문

Rollup에서 완료된 업무만 바로 셀 수 있나요?

기본 Rollup 집계에서 Status 값만 세면 완료·진행 중·할 일이 모두 대상이 됩니다. 완료 여부만 세려면 Formula 2.0으로 Relation의 각 업무 상태를 검사하거나, 업무 DB에 완료 여부를 계산하는 보조 속성을 만든 뒤 Rollup을 구성할 수 있습니다. 이번 예시는 Formula로 한 곳에서 계산합니다.

Rollup 결과를 다시 Rollup할 수 있나요?

Notion 도움말은 Rollup을 다시 Rollup하는 기능을 지원하지 않는다고 설명합니다. 단계별 집계가 필요하면 연결 구조를 단순화하거나 Formula 2.0으로 Relation의 원래 속성을 직접 읽는 설계를 검토하세요.

한 업무를 여러 프로젝트에 연결해도 되나요?

업무 하나가 공동 프로젝트에 걸쳐 쓰인다면 Relation을 No limit로 둘 수 있습니다. 이 경우 같은 업무가 각 연결 프로젝트의 수·시간 집계에 각각 반영될 수 있으므로 합계를 팀 전체의 고유 업무 수로 해석하지 않습니다.

Relation을 숨기면 프로젝트 연결도 없어지나요?

보기를 바꿔 속성을 숨기거나 필터를 건 것과 Relation 값을 삭제하는 것은 다릅니다. 원본 데이터베이스나 다른 보기를 열어 연결을 확인하고, 더 이상 필요하지 않으면 Relation 셀의 연결 페이지를 직접 제거합니다.

Formula를 쓰지 않고 완료율을 만들 수 있나요?

완료 수와 전체 수를 Rollup으로 각각 계산하고 다른 Formula에서 나눌 수 있습니다. 다만 Notion은 Rollup의 중첩 집계를 지원하지 않으므로 여러 단계가 필요해질 수 있습니다. Formula 2.0은 Relation에서 완료 항목을 직접 세는 방법을 제공하므로 이 예시처럼 간단한 진행률에는 직접 계산이 더 짧습니다.

Notion 공식 도움말과 함께 확인하세요

Notion의 웹·데스크톱 화면은 업데이트와 언어 설정에 따라 메뉴 이름이 달라질 수 있습니다. 속성 유형과 계산 결과는 실제 워크스페이스의 합성 데이터로 먼저 시험하세요. 확인일은 2026년 10월 10일입니다.

• Notion: Relations & rollups — Relation 생성, 양방향 표시, 연결 수 제한, Rollup 계산, CSV 관계 제한과 Rollup 중첩 불가.
• Notion: Database properties — Relation·Rollup·Formula 등 데이터베이스 속성.
• Notion: Formula syntax & functions — Relation을 포함한 Formula 값과 `map`, `filter`, `length`, `sum` 함수.
• Notion: Formulas 2.0 — Relation을 통해 연결 DB 속성을 직접 참조하는 진행률 계산 예.
• Notion: Database views, filters, sorts & groups — 보기별 필터와 정렬, 팀 공유 범위 설정.
• Notion: Sharing & permissions settings — 페이지 공유 범위와 양방향 Relation이 공개 링크 경로에 미칠 수 있는 접근 범위 영향.

Notion 글 전체를 보려면 Notion 실무 가이드 허브에서 공유·반입·업무 보드·반복 작업을 선택할 수 있습니다.