Written with AI assistance from the source video. The video is the authority.
30:37Vercel
Log in to leave a comment
No posts yet
노션은 인터페이스가 편하다. 1인 개발자가 서버와 데이터베이스를 따로 구축할 시간이 없을 때 노션을 백엔드로 쓰는 이유다. 하지만 프로덕션 레벨에서 이 구조를 유지하면 금방 벽에 부딪힌다. 노션 api는 모든 통합 토큰에 대해 초당 3회의 요청 제한을 건다. 이 제한을 넘으면 429 에러나 529 에러가 떨어진다.
데이터가 조금만 쌓여도 문제가 커진다. 한 번에 가져올 수 있는 데이터는 최대 100개다. 페이징 처리를 직접 구현해야 하고, 중첩된 프로퍼티 구조를 파싱하느라 서버 로직이 복잡해진다. 페이지 하나에 들어가는 속성 데이터 크기는 2.5메가바이트로 제한된다. 이 한계를 무시하고 서비스를 배포하면 사용자 요청이 몰릴 때 화면이 멈추거나 데이터가 누락된다.
외부 api 호출을 매번 기다릴 수는 없다. 캐싱 레이어를 앞에 두어야 한다. 레디스나 클라우드플레어 kv에 정적 데이터를 캐싱하고, 백그라운드 워커로 주기적으로 갱신해야 전체 api 호출의 80퍼센트를 로컬에서 처리할 수 있다. 응답 속도는 200밀리초 아래로 떨어진다.
파이썬 백엔드에서 노션의 복잡한 프로퍼티를 평탄화하는 파서도 필요하다. 노션 응답은 타입별로 깊게 중첩되어 있다. 딕셔너리를 순회하면서 타입 필드를 확인하고, 텍스트는 문자열로 합치고, 관계형 데이터는 id 배열만 뽑아내는 파서를 만든다. 이 전처리 과정을 거쳐야 프론트엔드 개발자가 파싱 로직 없이 데이터를 바로 갖다 쓴다.
노션에서 행이 바뀌어도 웹훅이 수신되자마자 api를 찌르면 예전 데이터가 돌아온다. 인덱싱이 밀리기 때문이다. 패킷이 유실되거나 데이터가 꼬이는 원인이다.
이 문제를 잡으려면 주기적인 백그라운드 복구 루틴이 필요하다. 노션 api의 수정 시각 필터를 활용해 로컬 캐시와 타임스탬프를 비교한다. 에러가 나면 지수 백오프 알고리즘으로 대기했다가 재시도한다. 마지막 동기화 시점 이후에 바뀐 레코드만 골라서 강제로 업데이트하는 루틴을 심어두어야 데이터 정합성이 깨지지 않는다.
클라이언트 브라우저에서 노션 시크릿 키를 직접 들고 요청을 보내는 코드는 위험하다. 토큰이 그대로 노출되고 cors 문제도 터진다. 서버리스 미들웨어 프록시를 중간에 둬야 하는 이유다.
클라이언트는 서버리스 미들웨어로 요청을 보내고, 미들웨어가 서버 환경 변수에 숨겨둔 토큰을 붙여서 노션 api와 통신한다. 멀티테넌트 환경이라면 앱 사용자 id와 노션 페이지 소유자를 매핑하는 역권한 테이블을 미들웨어에 두어야 한다. 이 구조를 만들어야 토큰 유출 사고를 막고 안전하게 데이터를 격리할 수 있다.