n8n으로 PDF 인보이스 파싱해 에어테이블에 저장하기 — 헤더·라인아이템 2테이블 설계

n8n.io 템플릿을 가져오면, 구글드라이브 인보이스 폴더에 PDF 한 장을 올리는 것만으로 LlamaParse가 문서를 구조화된 데이터로 바꾸고, n8n이 그 결과를 에어테이블의 인보이스 테이블과 라인아이템 테이블 두 곳에 나눠 저장하는 자동화를 만들 수 있습니다.

이 템플릿 하나로 보여줄 수 있는 것

면접에서 "문서 처리 자동화 해보셨어요?"라는 질문을 받으면, 이 템플릿은 구체적인 사례로 답할 재료가 됩니다. "구글드라이브에 인보이스 PDF를 올리면 LlamaParse가 파싱하고, 그 결과를 에어테이블의 인보이스 테이블과 라인아이템 테이블에 나눠 저장하는 자동화를 만들어봤습니다"라고 말할 수 있습니다.

문장 하나지만 안에 들어간 역량은 세 가지입니다.

• 비동기 API 연동 — 파일을 외부 파싱 서비스에 보내고, 처리가 끝난 뒤 그 서비스가 다시 콜백으로 결과를 알려주는 구조를 다뤄본 경험
• 관계형 데이터 모델링 — 인보이스 전체에 걸리는 값과 품목별로 반복되는 값을 테이블 두 개로 분리해 설계한 경험
• 이벤트 기반 트리거 — 사람이 버튼을 누르지 않아도 폴더 감시만으로 파이프라인이 시작되게 만든 경험

이 세 가지는 인보이스뿐 아니라 계약서, 견적서, 주문서처럼 "문서 하나 안에 헤더 정보와 반복되는 품목 정보가 함께 들어 있는" 문서 처리 자동화 전부에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Parse PDF with LlamaParse and save to Airtable라는 이름으로 공개된 템플릿이고, 제작자는 Mark Shcherbakov입니다. 카테고리는 Invoice Processing과 AI Summarization으로 등록돼 있습니다.

공식 설명에 따르면 이 템플릿이 겨냥하는 독자는 재무팀, 회계 담당자, 비즈니스 운영 담당자처럼 인보이스 처리를 반복하는 사람들입니다. 인보이스를 손으로 옮겨 적는 작업은 느리고 실수가 잦은데, 이 워크플로우는 업로드된 문서에서 인보이스 정보를 직접 추출해 구조화된 데이터로 저장함으로써 그 반복을 없앤다고 설명합니다. 제작자는 이 템플릿에 대한 유튜브 가이드 영상도 별도로 공개해두었습니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿의 구조 자체에 집중합니다.

구조 — Trigger / Task / Target

공식 문서의 "What the workflow does"를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다.

• Trigger — 이 워크플로우는 트리거가 두 개입니다. Google Drive Trigger가 인보이스 전용 폴더의 신규 파일을 감지하며 앞부분을 시작하고, Webhook 노드가 LlamaParse의 파싱 완료 콜백을 받으며 뒷부분을 시작합니다. 하나의 캔버스 안에 "요청을 보내는 흐름"과 "응답을 받는 흐름"이 나뉘어 있는 셈입니다.
• Task — 인보이스 파일을 헤더 설정과 웹훅 URL을 담아 LlamaParse로 업로드 → (LlamaParse가 문서를 파싱하는 동안 대기) → 파싱 결과를 웹훅으로 수신 → 인보이스 필드를 추출해 레코드 생성 → 품목을 나타내는 문자열 데이터를 구조화된 배열로 변환 → 품목별 레코드 생성.
• Target — 결과물은 에어테이블 베이스 안의 테이블 두 개입니다. 인보이스 테이블에는 인보이스 한 장당 레코드 하나가, 라인아이템 테이블에는 품목 하나당 레코드 하나가 쌓이고, 두 테이블은 서로 연결돼 있습니다.

이 템플릿에서 취준생이 눈여겨봐야 할 건 노드 구성보다 마지막에 데이터를 담는 방식입니다. 인보이스 자동화에서 자주 나오는 실수는 파싱 결과를 테이블 하나에 통째로 우겨넣는 것입니다. 인보이스 한 장에는 거래처명·인보이스 번호·합계금액처럼 문서 전체에 딱 한 번만 나오는 값과, 품목명·수량·단가처럼 줄마다 반복되는 값이 섞여 있습니다. 이 둘을 한 테이블에 넣으면 품목이 다섯 개인 인보이스는 다섯 개 행에 거래처명과 합계금액이 그대로 복제되고, 나중에 거래처명 하나를 고치려면 행 다섯 개를 전부 찾아 고쳐야 합니다.

이 템플릿은 그래서 테이블을 둘로 나눕니다. 인보이스 테이블에는 인보이스당 레코드 하나만 있고, 라인아이템 테이블에는 품목당 레코드 하나가 있으면서 각 레코드가 자신이 속한 인보이스 레코드를 링크 필드로 가리킵니다. 이렇게 나누면 거래처명은 인보이스 테이블에 딱 한 번만 저장되고, 품목이 몇 개든 라인아이템 테이블에서 인보이스 링크를 따라가 조회하면 됩니다. 관계형 데이터베이스에서 정규화(normalization)라고 부르는 개념을 에어테이블의 링크 필드로 구현한 것이고, 주문서·견적서·거래명세서처럼 "헤더 하나에 품목 여러 개"가 반복되는 데이터라면 어디에나 그대로 옮겨 쓸 수 있는 설계입니다.

만들기

공식 Setup 단계는 총 5개입니다. 순서는 그대로 두고 각 단계에서 무엇을 준비해야 하는지 풀어씁니다.

1. 구글드라이브 인보이스 폴더 준비

구글드라이브에 인보이스 PDF만 모아둘 전용 폴더를 하나 만듭니다. 이 폴더가 Google Drive Trigger의 감시 대상이 되고, 여기에 새 파일이 올라올 때마다 파이프라인 전체가 시작됩니다.

2. LlamaParse 계정과 API 키 발급

LlamaParse는 LlamaIndex가 만든 문서 파싱 API 서비스로, PDF 같은 비정형 문서를 구조화된 데이터로 바꿔줍니다. 사용하려면 LlamaCloud 계정을 만들고 API 키를 발급받아야 합니다. 무료로 쓸 수 있는 크레딧이 있지만, 페이지 수 한도나 요금제별 조건은 자주 바뀌니 실습 전에 LlamaParse 공식 가격 페이지에서 최신 조건을 직접 확인하는 걸 권합니다.

3. n8n Webhook 노드로 콜백 주소 만들기

이 템플릿의 핵심은 LlamaParse가 파싱을 끝내자마자 결과를 바로 돌려주지 않는다는 점입니다. HTTP Request 노드가 파일을 업로드할 때 헤더 설정과 함께 "파싱이 끝나면 여기로 결과를 보내달라"는 웹훅 URL을 같이 전달하고, n8n 쪽에서는 Webhook 노드가 그 콜백을 받을 준비를 해두고 대기합니다. 그래서 워크플로우를 만드는 중에는 테스트 URL로 확인하다가, 실제로 폴더 감시가 돌기 시작하면 캔버스 상단을 Active로 켜서 프로덕션 웹훅 URL이 살아 있게 해둬야 합니다. Active 상태가 아니면 LlamaParse가 콜백을 보내도 n8n이 받지 못합니다.

4. 에어테이블 인보이스 테이블 만들기

에어테이블에 베이스를 하나 만들고, 인보이스 전체에 해당하는 값(거래처명·인보이스 번호·발행일·합계금액 같은 항목)을 담을 테이블을 준비합니다. n8n에는 Airtable API 크리덴셜을 등록해두고, Edit Fields(Set) 노드가 LlamaParse 파싱 결과에서 이 값들을 추출해 레코드 하나로 만드는 흐름을 연결합니다.

5. 라인아이템 테이블 만들고 인보이스 테이블과 링크

같은 베이스 안에 품목 단위 정보(품목명·수량·단가 같은 항목)를 담을 두 번째 테이블을 만들고, 4번에서 만든 인보이스 테이블을 가리키는 "Link to another record" 필드를 하나 추가합니다. 파싱 결과에서 품목 정보는 보통 문자열 형태로 들어오기 때문에, 이걸 품목 하나당 배열 원소 하나가 되도록 변환하는 과정이 필요합니다. 변환이 끝나면 배열의 각 원소마다 라인아이템 테이블에 레코드를 만들면서, 방금 생성한 인보이스 레코드를 링크 필드 값으로 함께 넣어줍니다.

주의할 점 · 제약

공식 문서와 실제 서비스 조건을 종합하면 세 가지를 챙겨야 합니다.

• 외부 유료 API에 의존한다 — LlamaParse는 n8n 밖의 별도 서비스라 자체 계정과 API 키, 별도 요금제가 필요합니다. 무료 크레딧이 있긴 하지만 정확한 한도는 계속 바뀔 수 있어 숫자를 여기 못박지 않습니다. 실습 전에 공식 가격 페이지를 확인하세요.
• 에어테이블 무료 플랜에는 레코드 상한이 있다 — 에어테이블 공식 문서에 따르면 무료 플랜은 베이스당 레코드 1,000개가 상한입니다(2026년 8월 기준, Airtable 공식 플랜 문서). 인보이스 테이블과 라인아이템 테이블 둘 다 이 한도를 각각 적용받으므로, 인보이스 한 장에 품목이 여러 개씩 붙는다는 걸 감안하면 실습용 베이스라도 이 상한을 넘기지 않는지 가끔 확인해두는 게 좋습니다.
• 비동기 구조라 즉시 완료되지 않는다 — 업로드하자마자 에어테이블에 값이 채워지는 게 아니라, LlamaParse가 문서를 파싱하는 시간만큼 기다렸다가 웹훅 콜백이 돌아온 뒤에야 나머지 단계가 실행됩니다. 처음 테스트할 때 "왜 에어테이블에 아무것도 안 뜨지"라고 당황하기 쉬운데, 파싱이 끝나지 않아서인 경우가 대부분입니다.

한 가지 더, 공식 페이지의 노드 미리보기에는 Airtable·HTTP Request·Edit Fields(Set) 외에 다섯 개 노드가 더 있다고만 나와 있고 이름까지는 공개돼 있지 않습니다. 문자열을 라인아이템 배열로 바꾸는 정확한 노드 구성은 템플릿을 자신의 n8n 인스턴스로 가져와야 직접 확인할 수 있습니다.

포트폴리오·면접 포인트

포트폴리오에는 업로드한 인보이스 PDF 원본, 그리고 잠시 후 채워지는 에어테이블의 인보이스 레코드와 그 인보이스에 링크된 라인아이템 레코드들, 이렇게 화면 두세 장이면 충분합니다. 인보이스를 하나만 넣지 말고 품목 개수가 다른 인보이스 두세 장을 넣어보면, 라인아이템 테이블이 인보이스마다 다른 개수의 레코드를 만들어내는 걸 보여줄 수 있어 설계가 실제로 유연하다는 인상을 줍니다.

면접에서는 "파싱 결과를 왜 테이블 하나에 넣지 않았나요?"라는 질문이 나올 수 있습니다. 답은 이렇습니다. 인보이스 전체 값과 품목별 값을 한 테이블에 섞으면 품목 수만큼 헤더 값이 중복 저장되고, 나중에 헤더 값 하나를 고칠 때마다 관련 행을 전부 찾아 고쳐야 합니다. 테이블을 둘로 나누고 링크 필드로 연결하면 헤더 값은 한 곳에만 있고, 품목이 늘어나도 라인아이템 테이블에 레코드만 추가하면 됩니다. 이런 답을 할 수 있으면 노드를 조립할 줄 아는 사람이 아니라 데이터 구조를 이해하고 설계한 사람이라는 인상을 줍니다.

다음 액션

이 템플릿까지 보면, 지금까지 다룬 n8n.io 템플릿 열 편에서 트리거 분기, 벡터 검색, 음성 입력 처리, 에러 핸들링, 그리고 이번 편의 관계형 데이터 모델링까지 자동화에서 반복해서 만나는 기본 패턴을 대부분 훑은 셈입니다. 다음 단계는 여기서 멈추지 않고, 이 중 하나를 골라 자신이 실제로 갖고 있는 데이터(재고표, 신청서, 영수증 같은 것)로 바꿔서 직접 돌려보는 것입니다. 템플릿을 그대로 가져와 실행해본 것과, 자신의 데이터에 맞게 필드와 조건을 바꿔본 것은 포트폴리오에서 전혀 다른 무게로 읽힙니다.