NextBlog가 하위 페이지를 처리하는 방법

노션 페이지 구조

노션은 계층적인 페이지 구조를 가집니다. 각 페이지는 고유한 ID를 가지며, 하위 페이지들을 포함할 수 있습니다.

만약 사용자가 보고서 모음 이라는 페이지를 NextBlog에 작성한다고 하면 NextBlog는 보고서 모음의 id인 123…을 DB에 저장합니다. 다른 사용자들은 해당 포스트를 확인할 수 있습니다. 그리고 해당 포스트를 클릭하여 들어가면 해당 노션페이지를 확인할 수 있습니다.

하지만 노션 블로그에서 페이지 간 이동 시 하위 페이지의 404 에러를 발견했습니다.

예를 들어 "보고서 모음" 페이지는 DB에 저장되어 있어 접근이 가능하지만, 그 하위의 "OS", "임베디드", "네트워크" 페이지들은 DB에 저장되어 있지 않아 접근이 불가능했습니다.

초기 해결 시도: 업로드 시 하위 페이지 전체 저장

이를 해결하기 위해 처음에는 재귀 방식으로 하위 페이지들을 모두 탐색하여 페이지 id를 모두 DB에 저장하였습니다. 페이지의 하위 페이지를 추출하고 하위페이지를 재귀로 이동하여 업로드 로직을 반복합니다.

해당 코드는 노션 페이지를 업로드 할 때 사용하는 코드입니다.


//하위 페이지 모두 업로드
async function uploadPageWithSubpages(
    pageId: string, 
    userId: string, 
    avatar: string,
    processedPages = new Set<string>()
  ): Promise<void> {
    //이미 처리한 페이지면 스킵
    if (processedPages.has(pageId)) {
      return;
    }
    
    //현재 페이지 처리 표시
    processedPages.add(pageId);
    
    //페이지 데이터 가져오기
    const recordMap = await getPage(pageId);
    const notionContent = await getNotionPageContent(pageId);
    
    //현재 페이지 저장
    await uploadPost({
      id: pageId,
      author: userId,
      date: new Date(),
      image: notionContent.image,
      title: notionContent.title,
      avatar: avatar,
    });
    
    //하위 페이지 ID들 가져오기
    const subpageIds = await getAllSubpages(recordMap);
    
    //재귀적으로 하위 페이지들 처리
    for (const subpageId of subpageIds) {
      await uploadPageWithSubpages(subpageId, userId, avatar, processedPages);
    }
  }


//하위 페이지 GET
async function getAllSubpages(recordMap: Types.ExtendedRecordMap): Promise<string[]> {
    const pageIds: string[] = [];
    
    //recordMap에서 block 정보 추출
    const blocks = recordMap.block;
    
    for (const [, block] of Object.entries(blocks)) {
      //type이 page인 블록 찾기
      if (block?.value?.type === 'page') {
        pageIds.push(block.value.id);
      }
    }
    console.log(pageIds)

    return pageIds;
  }

단일 페이지에서는 문제가 없었지만 하위 페이지가 많아질 경우 저장해야 하는 데이터가 증가하였고 모든 페이지를 순회하고 업로드 하는 과정에서 오랜 시간이 걸렸습니다.

개선: Bottom-Up 트리 순회

그래서 모든 페이지를 DB에 저장하지 않고 업로드한 한 페이지만 DB에 저장하게 변경하고, 사용자가 하위 포스트에 접근할 때 Bottom-Up 방식의 로직을 도입하여 부모 페이지가 DB에 존재하는지 확인하였습니다.

노션 페이지 업로드 시


        //작성 시간 설정
        const date = new Date();

        //노션 페이지 컨텐츠 획득
        const notionContent = await getNotionPageContent(id);

        //DB 저장
        await uploadPost({
            id:id,
            author:userId,
            date:date,
            image:notionContent.image,
            title:notionContent.title,
            avatar:avatar,
        });
        
        return NextResponse.json({message:"Post Uploaded",isSuccess:true},{status:200})

    }
    catch(err){
        return NextResponse.json({message:"Internal Server Error",isSuccess:false},{status:500})
    }
}

노션 페이지 검증 시


/**
 * 재귀적으로 위로 올라가며 페이지가 DB에 저장되어 있는지를 확인하는 함수
 * @param id 탐색할 페이지의 id
 * @returns 페이지가 DB에 저장되어 있는지 여부
 */
export async function isDescendantOfStoredPage(id: string): Promise<boolean> {
    try {
        // DB에서 포스트 존재 확인
        const page = await getPostById(id);

        // DB에 존재하면 true 반환
        if (Array.isArray(page) && page.length !== 0) {
            return true;
        }

        // 해당 페이지 정보 추출
        const recordMap = await getPage(id);
        const block = recordMap.block[Object.keys(recordMap.block)[0]].value;

        // 부모 페이지 추출
        const parentPage = await getBlockParentPage(block, recordMap);

        // 부모 페이지가 없으면 (루트 페이지) false 반환
        if (!parentPage) {
            return false;
        }

        // 부모 페이지가 있을 경우 재귀적으로 탐색
        return isDescendantOfStoredPage(parentPage.id);
    } catch (error) {
        console.error('Error in isDescendantOfStoredPage:', error);
        return false; // 에러 발생 시 false 반환
    }
}

페이지의 id만 저장하는 경우 업로드 시간은 모두 2초내로 하위 페이지 수와 관계없이 빠른 속도를 확인할 수 있었습니다.

두 데이터를 비교하면 단일 페이지만 DB에 저장하는 경우 빠른 속도로 업로드하는것을 확인할 수 있었습니다.

페이지 검증 시간(트리 깊이 기준)

그렇다면 두 로직의 페이지가 DB에 존재하는지 확인하는 검증 시간은 어떻게 될까요.

트리를 깊이 이동할수록 검증 시간이 얼마나 걸리는지 측정하였습니다.

그림과 같이 모든 페이지를 저장했을 때는 빠른 페이지 로딩을 보여주지만, 단일 페이지만 저장하였을 경우 트리를 깊이 이동할수록 검증 시간이 증가하는것을 확인할 수 있었습니다.

하지만 Bottom-Up 검증 방식은 트리 깊이에는 영향을 받지만, 형제 페이지의 수에는 영향을 받지 않습니다.

실제로 상위 페이지에서 모든 페이지를 DB에 저장하였을 때와 Bottom-Up 검증 방식은 비슷한 검증 시간을 보여주었습니다. 이는 페이지 접근 시 해당 페이지의 상위 페이지들만을 순회하면 되기 때문입니다.

결국 실제 블로그의 구조를 고려했을 때:

트리의 깊이는 보통 3-4단계를 넘지 않음

페이지 업로드 시간이 크게 개선 (20페이지 기준 19.86초 → 1.64초)

DB 저장 공간이 효율적으로 관리됨

페이지의 형제 노드 수에 영향을 받지 않음

이러한 이유들로 Bottom-Up 검증 방식이 더 효율적인 해결책이라고 판단하였습니다. 특히 사용자들은 대부분 3-4단계 이상의 깊은 계층 구조를 만들지 않는다는 점을 고려할 때, 검증 시간의 소폭 증가는 실제 사용성에 크게 영향을 미치지 않을 것으로 예상됩니다.