업무 데이터 파이프라인

02이 차시를 마치면

• 1.시트와 데이터베이스 사이의 동기화 스크립트를 설계할 수 있다.
• 2.대량 데이터를 배치로 나눠 처리하는 방식을 구현할 수 있다.
• 3.API 호출이 실패했을 때 레이트 리밋을 지키며 재시도하는 로직을 만들 수 있다.
• 4.시트나 DB의 스키마가 바뀌었을 때 파이프라인이 조용히 깨지지 않게 대응할 수 있다.
• 5.파이프라인이 실패했을 때 알림을 받도록 설정할 수 있다.

03왜 필요한가

기본과정 04차시에서 만든 Apps Script 자동화는 시트 안에서는 잘 돌아갔다. 그런데 데이터가 몇천 행을 넘어가고 외부 API까지 함께 쓰기 시작하면서 문제가 생긴다. 한 번에 다 처리하려다 실행 시간 한도를 넘겨 중간에 멈추고, 외부 API가 순간적으로 느려지면 스크립트가 그대로 죽어버린다. 그리고 아무도 실패를 알지 못한 채 다음 날 아침에야 리포트가 비어 있는 걸 발견한다.

• ·데이터가 늘어나면 한 번에 처리하던 방식이 실행 시간 한도에 걸려 중간에 멈춘다.
• ·외부 API가 일시적으로 응답하지 않으면 스크립트가 재시도 없이 그대로 실패한다.
• ·시트에 열이 하나 추가되거나 이름이 바뀌면 파이프라인이 예고 없이 조용히 깨진다.
• ·실패해도 알림이 없어, 사람이 우연히 발견하기 전까지 데이터가 계속 비어 있는 상태로 방치된다.

04개념 설명

05실습 가이드

1. 1. 동기화 방향과 원본 정하기

   • -동기화할 구글 시트와 Supabase(또는 사용 중인 DB) 테이블의 열/컬럼 구조를 정리한다.
   • -P4-1 프롬프트로 어느 쪽을 원본으로 볼지, 풀 동기화와 증분 동기화 중 무엇을 쓸지 AI와 함께 결정한다.

   예상 결과 — 원본(source of truth), 동기화 방식, 충돌 처리 원칙이 문서로 정리된다.

   안 될 때 — 시트나 DB 구조를 정확히 모르면 먼저 시트 헤더와 DB 테이블 스키마를 각각 내보내(export) 확인한 뒤 다시 요청한다.

2. 2. 소량 데이터로 동기화 스크립트 첫 실행

   • -실습 시트에서 20행 내외의 소량 데이터만 골라 동기화 스크립트를 실행한다.
   • -Supabase 테이블에 해당 데이터가 정상적으로 반영됐는지 확인한다.

   예상 결과 — 소량 데이터가 오류 없이 DB에 반영되고, 값이 시트 내용과 일치한다.

   안 될 때 — 연결 자체가 안 되면 API 키나 DB 연결 문자열(connection string)이 올바른지, 환경변수로 제대로 분리됐는지 먼저 확인한다.

3. 3. 대량 데이터를 배치로 나눠 처리하기

   • -P4-2 프롬프트로 전체 데이터를 정해진 크기로 나눠 처리하는 배치 로직을 추가 요청한다.
   • -처리 위치(커서)를 어딘가(시트의 별도 셀 또는 DB의 별도 테이블)에 저장하도록 함께 요청한다.
   • -전체 데이터로 실행해 여러 배치가 순차적으로 처리되는지 확인한다.

   예상 결과 — 전체 데이터가 여러 배치로 나뉘어 순차 처리되고, 마지막에 처리 완료 로그가 남는다.

   안 될 때 — 중간에 멈추면 저장된 커서 값을 확인하고, 그 값부터 이어서 실행되는지 별도로 테스트한다.

4. 4. API 실패에 대비한 재시도 로직 넣기

   • -P4-3 프롬프트로 지수 백오프 방식의 재시도 로직을 추가 요청한다.
   • -일시적으로 잘못된 API 주소를 사용하는 등 의도적으로 실패 상황을 만들어 재시도 동작을 테스트한다.

   예상 결과 — 실패 시 간격을 늘려가며 자동 재시도한 로그가 남고, 정해진 횟수 이후에는 포기하고 실패로 기록된다.

   안 될 때 — 재시도가 멈추지 않고 계속된다면 최대 재시도 횟수 설정이 빠진 것이다. AI에게 최대 횟수를 명시해 다시 요청한다.

5. 5. 스키마 변경 시나리오 테스트하기

   • -테스트용 사본 시트에서 열 하나를 추가하거나 이름을 바꿔본다.
   • -P4-4 프롬프트로 실행 전 스키마 검증 단계와 열 이름 기준 매핑을 추가 요청한다.
   • -구조를 바꾼 상태에서 파이프라인을 다시 실행해 반응을 확인한다.

   예상 결과 — 구조가 예상과 다르면 데이터를 처리하지 않고 멈추며, 어떤 열이 문제인지 명확한 메시지가 나온다.

   안 될 때 — 구조가 바뀌었는데도 조용히 통과해 잘못된 값이 들어간다면 열 이름 기준 매핑이 제대로 안 된 것이다. 해당 부분을 짚어 다시 수정 요청한다.

6. 6. 실패 알림 연결하기

   • -P4-5 프롬프트로 실패 시에만 이메일(또는 슬랙)로 알림을 보내는 코드를 추가 요청한다.
   • -정상 실행 한 번, 의도적 실패 한 번을 각각 만들어 알림이 원하는 경우에만 오는지 확인한다.

   예상 결과 — 실패했을 때만 실패 시각·단계·에러 요약이 담긴 알림이 도착하고, 성공 시에는 알림이 오지 않는다.

   안 될 때 — 알림이 안 오면 성공/실패 판단 조건이 잘못 걸려 있을 수 있다. 실행 로그를 먼저 확인하고 조건문을 AI와 함께 점검한다.

7. 7. 자동 실행 트리거 등록하기

   • -기본과정 04차시와 같은 방식으로 시간 기반 트리거(또는 사용 환경에 맞는 스케줄러)를 등록한다.
   • -등록된 트리거 목록에 방금 만든 항목이 있는지 확인한다.

   예상 결과 — 트리거가 등록되고, 정해진 시간에 파이프라인이 자동으로 실행된 로그가 남는다.

   안 될 때 — 트리거 저장이 안 되면 스크립트 실행 권한 승인이 아직 끝나지 않은 것이다. 권한 승인부터 다시 진행한다.

8. 8. 전체 파이프라인 통합 점검

   • -동기화 → 배치 처리 → 재시도 → 스키마 검증 → 실패 알림까지 전체 흐름을 처음부터 한 번에 실행한다.
   • -특정 단계에서 막히면 P4-6(복구) 프롬프트로 그 단계만 따로 진단받는다.

   예상 결과 — 전체 흐름이 에러 없이 끝까지 완료되고, 각 단계가 로그에 순서대로 기록된다.

   안 될 때 — 특정 단계에서 반복적으로 막힌다면 그 단계만 별도 스크립트로 떼어내 재현한 뒤, P4-6으로 원인을 좁혀 복구한다.

06실전 프롬프트

구글 시트 [시트 이름]과 Supabase의 [테이블 이름]을 동기화하려고 해.
시트 구조: [열 목록]
DB 테이블 구조: [컬럼 목록]

다음을 정하는 걸 도와줘.
1. 어느 쪽을 원본(source of truth)으로 볼지
2. 매번 전체를 다시 옮길지, 바뀐 것만 옮길지
3. 같은 데이터가 양쪽에서 동시에 바뀌면 어느 쪽을 우선할지

각각 선택지를 두 개씩 주고,
내 상황(팀원 [인원수]명이 시트를 직접 수정함)에
뭐가 더 맞는지 추천해줘.

지금 스크립트는 시트 데이터를 한 번에 다 처리하는데,
행이 [대략적인 행 수]개가 넘어가면 실행 시간 한도에 걸릴 것 같아.

[배치 크기, 예: 100행]씩 나눠서 처리하고,
어디까지 처리했는지 기록해뒀다가
다음 실행에서 그 다음부터 이어서 처리하도록 고쳐줘.

중간에 실패해도 처음부터 다시 시작하지 않게 만드는 게 목표야.

이 스크립트가 외부 API를 호출하는 부분에서
가끔 응답이 느리거나 요청이 너무 많다는(레이트 리밋) 에러가 나.

실패하면 곧바로 재시도하지 말고
간격을 점점 늘려가면서(예: 1초, 2초, 4초) 최대 [3~5]번까지 재시도하고,
그래도 안 되면 포기하고 어떤 요청이 실패했는지 기록만 남기도록 고쳐줘.

시트나 DB 테이블 구조가 나중에 바뀔 수도 있어.
스크립트를 실행하기 전에

1. 기대하는 열 이름들(예: [날짜, 담당자, 금액])이 실제로 다 있는지 확인하고
2. 하나라도 없거나 이름이 다르면 데이터를 처리하지 말고
   바로 멈추면서 어떤 열이 문제인지 알려주는

점검 단계를 맨 앞에 추가해줘. 지금은 열 위치(A열, B열)로 찾고 있다면
열 이름으로 찾도록 같이 바꿔줘.

이 파이프라인이 실패하면
[내 이메일 주소 또는 슬랙 채널]로 바로 알림이 오게 하고 싶어.

알림에는 다음이 들어가야 해.
· 언제 실패했는지
· 어느 단계(동기화/배치/재시도/검증 중 어디)에서 실패했는지
· 에러 메시지 요약

성공했을 때는 알림을 보내지 말고, 실패했을 때만 보내줘.

파이프라인을 처음부터 실행했는데 이 단계에서 멈췄어.

[멈춘 단계: 동기화/배치/재시도/스키마검증/알림 중 하나]
에러 또는 로그: [에러 메시지나 마지막 로그 그대로 붙여넣기]
직전까지 처리된 데이터 상태: [어디까지 처리됐는지]

무엇이 문제인지 먼저 설명하고,
처음부터 다시 돌리지 않고 멈춘 지점부터 이어서 실행할 수 있는 방법을 알려줘.

07이것만은 주의

08자가 점검

09과제

자신의 실제 업무 시트(또는 03차시에서 다룬 프로젝트의 데이터)와 데이터베이스 테이블 하나를 골라, 이번 실습과 같은 흐름(동기화 설계 → 배치 처리 → 재시도 → 스키마 검증 → 실패 알림)을 갖춘 파이프라인을 만든다. 실제로 붙일 DB가 없다면 Supabase에 테스트용 테이블을 새로 만들어 실습해도 된다.

제출 형식 — ① 파이프라인 코드가 담긴 저장소 링크 ② 대량 데이터 처리(배치) 실행 로그 캡처 ③ 강제로 실패시켜 알림이 도착한 스크린샷 ④ 스키마 변경 시나리오 테스트 결과를 하나의 문서로 정리해 제출한다.

10더 알아보기

• Supabase 배치/벌크 삽입 문서 — 대량 행을 한 번에 삽입·업서트하는 방법 확인용
• 사용 중인 외부 API의 레이트 리밋 정책 문서 — 재시도 간격과 최대 호출 수를 정할 때 기준으로 확인

증분 동기화(Incremental Sync)

— 전체 데이터를 매번 다시 옮기지 않고, 마지막 동기화 이후 바뀐 데이터만 옮기는 방식.

지수 백오프(Exponential Backoff)

— 재시도할 때마다 대기 시간을 점점 늘려가며 다시 시도하는 재시도 전략.

스키마 검증(Schema Validation)

— 데이터를 처리하기 전에 기대한 구조(열 이름, 컬럼 등)와 실제 구조가 일치하는지 확인하는 단계.

다음 차시 예고 — 다음 차시에서는 오늘처럼 반복해서 쓰는 작업 흐름을 커스텀 슬래시 커맨드와 스킬로 패키징해, 다음에는 매번 프롬프트를 새로 쓰지 않고도 같은 품질로 재사용하는 법을 다룹니다.