Google Sheets Notion 연동: 단방향 페이지 생성
Google Sheets Notion 연동은 승인된 스프레드시트 행을 읽고 각 필드를 대상 데이터베이스의 속성 유형에 매핑한 다음, 처리 기준을 통과한 행마다 페이지를 생성하는 방식으로 진행합니다. 다음 전송 전에 반환된 Notion 페이지 ID를 원본 ID와 함께 기록합니다. 아래의 카탈로그 기반 설계는 단방향 페이지 생성이며, 매핑과 재실행에 명시적인 검토 단계를 둡니다.
스프레드시트 열과 Notion 데이터베이스 속성은 서로 다른 규약을 따릅니다. Status라는 열이 유효한 선택 속성이나 허용된 옵션 중 하나에 자동으로 대응하는 것은 아닙니다.
작성: Ai Flowi · 게시일
공식 출처: Google Sheets API 문서, Notion API 문서
원본 범위와 페이지 식별 기준 선택
읽기 권한이 있는 스프레드시트, 탭, 정확한 범위를 지정합니다. 모든 행에 안정적인 원본 ID를 포함하고 어떤 필드를 Notion 속성으로 만들지 합의합니다. 관련 없는 비공개 열이 포함되지 않도록 선택 범위를 좁게 유지합니다. 행을 정렬하거나 삽입하면 위치가 바뀌므로 여러 배치에서 같은 기록을 식별할 때는 원본 ID를 사용합니다.
Read Range는 values를 JSON으로 제공합니다. Loop의 data 입력에는 Table과 DataFrame이 명시되어 있으므로 둘 다 데이터 모음을 표현한다는 이유만으로 Read Range를 Loop에 바로 연결하지 않습니다. 속성 매핑과 검토를 마친 레코드를 Data → DataFrame으로 변환하고 먼저 Table을 점검합니다.
두 서비스에서 준비할 사항
Google 연결 설정에 따라 원본 시트에 사용할 Google 계정을 인증하고, notion_secret으로 본인 Notion 계정의 데이터베이스 인증 정보를 제공합니다. 서비스 요금은 별도이며 이 전송에는 모델 호출이 없습니다.
배치를 선택하기 전에 소규모 로컬 실습으로 Notion 인증 정보가 원하는 데이터베이스를 조회할 수 있는지 확인합니다.
List Database Properties와 Create Page 설정은 Notion 연동 안내를 따릅니다.
전송 매핑에는 각 대상 속성과 함께 사용할 데이터베이스를 명시해야 합니다. 두 데이터베이스에 모두 Status 속성이 있어도 허용 옵션은 다를 수 있습니다. 이름이 비슷한 대상의 매핑을 그대로 가져오지 말고 이 배치에서 선택한 데이터베이스에 맞는지 검토합니다.
검토를 거치는 생성 배치 설정
구성 예시이며, 기록된 테스트가 아닙니다
| 컴포넌트 | 설정할 입력 | 작업 처리 기준 확인 |
|---|---|---|
| Read Range | range_name으로 승인된 헤더와 데이터 셀을 선택하고, spreadsheet_id로 스프레드시트를 지정하며 google_account를 선택합니다. | 선택한 범위의 위치가 여전히 승인된 원본 헤더에 매핑되는지 확인합니다. |
| List Database Properties | notion_secret과 대상 database_id를 설정합니다. | 점검한 스키마가 이 배치의 대상 데이터베이스에 속하는지 확인합니다. |
| JSON Operations | "JQ Expression"을 operations에서 선택하여 제공된 data에 적용합니다. 실제 행 필드에 이름을 붙이고 ID가 없는 행을 제외하도록 query를 작성합니다. | 처리 기준을 통과한 모든 행에는 검토된 속성 매핑과 원본 ID가 있어야 합니다. |
| Data → DataFrame 및 Loop | 매핑된 JSON을 data_list에 연결한 다음 결과 dataframe을 Loop.data에 연결합니다. | 생성 결과는 단순한 행 위치가 아니라 원본 ID로 대조해야 합니다. |
| Create Page | 이 배치의 database_id를 선택하고, 점검한 속성 문자열을 properties_json에 전달하며, notion_secret으로 인증 정보를 제공합니다. 앞 단계에서 생성한 경우 검증된 Message 변환을 사용합니다. | 생성된 페이지를 열고 상태를 승인된 매핑 결정과 비교합니다. |
- 행을 읽고 필드에 이름을 붙입니다. 테스트 시트에서 Read Range를 실행합니다. 안정적인 원본 ID를 보존하면서 실제 각 위치를 합의된 헤더에 매핑합니다. 짧게 반환된 행을 열 누락으로 처리하기 전에 끝부분의 빈 셀을 확인합니다.
- Notion 스키마를 점검합니다. List Database Properties를 별도로 실행합니다. 각 원본 필드에 대해 대상 속성 이름, 예상 유형, 빈 값 처리 방식, 필요한 경우 허용 옵션을 포함한 매핑을 작성합니다.
- 처리 기준을 통과한 레코드를 준비합니다. JSON Operations로 허용된 필드만 구성합니다. 중복 ID, 알 수 없는 상태 값, 필수 내용 누락이 나타나면 수동 실습을 중단합니다. 불완전한 매핑으로 별도 확인 없이 페이지를 생성하지 않습니다.
- 각 항목과 생성 결과를 대조합니다. 반복 설정은 Loop의 연결 및 순서 제한을 따릅니다. 반환된 각 페이지 ID가 해당 생성 요청에 포함된 원본 ID와 연결되는지 확인합니다. 원본 행과 생성 결과를 위치로 짝짓지 말고 ID를 비교합니다.
- 페이지 1개를 생성하고 결과를 보관합니다. 확인한 대상 스키마에 맞게 속성 객체를 준비합니다. 필요하면 Type Convert에서
output_type="Message"로 변환하고 결과 텍스트가 유효한 JSON인지 점검합니다. 이를 Create Page의properties_json에 전달합니다. - 원본과 페이지의 매핑을 기록합니다. 이 실습에서는 다음 행을 선택하기 전에 원본 ID, 반환된 페이지 ID, 처리 결과를 검토 로그에 수동으로 보관합니다. 이 그래프에는 원본에 자동으로 다시 기록하는 노드가 설정되어 있지 않습니다.
속성 유형을 고려한 명시적인 매핑
가상의 전송에서 스프레드시트 행은 작업을 T-07로 식별하고 상태를 Waiting으로 지정합니다. 대상 데이터베이스에 대응하는 상태 옵션이 없다면 매핑 결정이 내려질 때까지 해당 행을 보류합니다. 첫 번째 옵션으로 대체하거나 겉보기에는 유효한 상태지만 오해를 일으키는 페이지를 생성하지 않습니다. 검토자는 특정 대상 옵션을 승인하거나 원본을 수정하거나 사유를 기록하고 해당 행을 제외할 수 있습니다. 다음 배치에서 같은 모호함이 반복되지 않도록 결정을 T-07과 함께 보관합니다.
매핑 시트에서 텍스트, 수량, 날짜, 옵션 값을 구분합니다. 빈 셀은 “속성을 비워 둠”, “이 기록 제외”, “승인된 기본값 사용”을 뜻할 수 있으므로 명시적으로 결정합니다. 대상 필드를 채우기 위해 모호한 스프레드시트 텍스트에서 날짜를 만들어 내지 않습니다.
옵션 속성은 원본 값을 대상의 허용 값과 비교합니다. 텍스트 속성은 의미 있는 줄바꿈과 구두점을 유지합니다. 컴포넌트 항목에는 관계형 속성의 연결 대상 자동 확인, 첨부 파일 복사, 서식 있는 텍스트 변환이 확인되어 있지 않습니다. 데이터 구조와 동작을 검증할 때까지 이러한 필드는 첫 전송에서 제외합니다.
재실행 시 의도치 않은 페이지 생성 방지
Create Page는 생성 작업이며 문서화된 업서트 작업이 아닙니다. 같은 행을 다시 선택해도 제목이 일치한다는 이유로 이전 페이지가 업데이트된다고 가정하지 않습니다. 원본과 페이지를 연결한 생성 결과 로그를 사용하여 생성이 완료되지 않았다고 확인된 행만 선택합니다.
신뢰할 수 있는 생성 결과가 반환되지 않으면 행을 다시 제출하기 전에 대상 데이터베이스에서 해당 원본 ID를 확인합니다. 카탈로그에는 Create Page의 멱등성 매개변수나 생성과 결과 로그 사이의 트랜잭션 연결이 없습니다. 호출 측에서 ID를 보관하지 못해도 페이지는 존재할 수 있으므로 자동 재시도 대신 중단하고 결과를 대조합니다.
전송 규모를 늘리기 전에 확인
선택 입력 항목이 비어 있는 행, 유효하지 않은 옵션, 앞자리 0이 있는 원본 ID, 중복 원본 ID를 포함한 가상 행을 준비합니다. 제안된 검증이 생성 전에 유효하지 않은 기록을 제외하는지 확인합니다. 처리 기준을 통과한 행 1개의 대상 속성 값을 점검하고 페이지 ID를 기록한 다음, 두 번째 생성 배치에서 선택 과정이 해당 행을 제외하는지 확인합니다.
스프레드시트 열을 삽입하거나 이름을 바꾼 후에는 범위 헤더를 확인합니다. 위치를 기준으로 값을 매핑한다면 헤더가 이동했을 때 잘못된 속성에 값을 넣는 대신 과정을 중단해야 합니다. 이후 변경을 설명할 수 있도록 각 배치에 사용한 원본 스키마를 보관합니다.
Google Sheets에서 Notion으로 전송할 때 어떤 한계가 있으며, 다른 전송 방향은 무엇인가요?
이 전송은 카탈로그에 문서화되어 있지만 Ai Flowi가 운영 환경에서 테스트하지는 않았습니다. 양방향 동기화, 수정 사항 자동 대조, 완전한 페이지네이션, 반복 경로로 되돌아가는 연결 동작, 안전한 재시도 장치는 확인되어 있지 않습니다. 한 번 옮기는 작업을 기존의 수동 가져오기로 해결할 수 있다면 그것을 사용하고, 매핑과 실패 복구를 확인하기 전에는 무인 배치를 실행하지 않습니다.
선택한 데이터베이스 속성을 반대 방향으로 옮기려면 Notion에서 Google Sheets로 전송을 읽으세요. 페이지 본문 텍스트를 문서 스냅샷으로 만들려면 Notion에서 Google Docs로 내보내기를 사용합니다. 이들은 별도의 결과물이며 식별 규칙도 다릅니다.
행별 생성의 사용량
요금제: Go 연간 결제 시 월 USD8부터(월간 USD10), Plus 월 USD16부터(월간 USD20), Pro 100 월 USD80부터(월간 USD100), Pro 200 월 USD160부터(월간 USD200), Pro 500 월 USD400부터(월간 USD500). 매월 5,000~250,000 Flowi Tokens가 제공되며 충전도 가능합니다. 노드 실행 1회당 1토큰, 타사 API 및 모델 사용 요금은 포함되지 않습니다.
원본 읽기와 Table 변환뿐 아니라 반복 내부의 실행 내역도 점검합니다. 행별 생성 노드는 한 배치에서 여러 번 실행될 수 있습니다. 그래프에 노드가 하나 보인다고 해서 전체 전송에 노드 실행 1회만 과금되는 것은 아닙니다.
스프레드시트 전송 참고 자료
Notion 안내에서 속성 인터페이스를 점검합니다. 앞 단계의 행이 HTTP 입력으로 들어온다면 전송 배치를 선택하기 전에 웹훅 입력 수신 튜토리얼을 확인합니다. 구성 예제 목록에는 다른 워크플로우의 범위가 기록되어 있습니다. 데이터베이스 속성을 반대 방향으로 내보내는 작업은 Notion에서 Google Sheets로 전송을 참고합니다. 필요한 필드가 아직 업로드된 문서 안에만 있다면 먼저 문서 AI 추출을 사용합니다.