녹음 파일 하나로 회의록·노션까지 — n8n으로 만드는 회의 요약 파이프라인

회의를 녹음해 구글 드라이브 폴더에 올려두기만 하면, n8n이 음성을 텍스트로 바꾸고 맞춤법을 고치고 요약까지 순서대로 처리해 구글 문서와 노션 페이지에 동시에 남깁니다. 명함 OCR 편이 AI를 한 번 부르는 워크플로우였다면, 이번 편은 AI를 세 번 나눠 부르는 법을 보여줍니다. 전사·교정·요약을 한 프롬프트에 몰아넣지 않고 각자 한 가지 일만 하는 단계로 쪼갠 것이 이 워크플로우의 핵심입니다.

이 워크플로우 하나로 보여줄 수 있는 것

명함 OCR 편은 "사진 한 장 → AI 한 번 → 시트 한 행"이라는 짧은 체인이었습니다. 이번 워크플로우는 그 체인이 세 단계로 늘어나면서 무엇이 달라지는지를 보여줍니다.

• 오디오 트리거 — 음성 파일이 워크플로우를 시작시키는 경험
• 전사(STT) 전용 호출 — 음성을 텍스트로 바꾸는 일만 하는 모델을 따로 부르는 경험
• 역할이 분리된 LLM 체인 — 교정 모델은 교정만, 요약 모델은 요약만 하도록 프롬프트로 못박는 경험
• 한 결과를 두 타겟에 나눠 쓰기 — 같은 요약 결과를 구글 문서와 노션에 동시에 기록하는 경험

가장 중요한 건 세 번째입니다. "녹음 파일을 회의록으로 요약해줘"라는 프롬프트 하나로도 그럴듯한 결과는 나옵니다. 하지만 이 워크플로우는 일부러 전사·교정·요약을 서로 다른 AI 호출 세 개로 쪼갰고, 그 이유는 프롬프트 안에서 직접 확인할 수 있습니다.

배경 — 녹음은 쉬운데 정리가 오래 걸리는 일

회의를 녹음하는 건 버튼 한 번이면 끝나지만, 그 녹음을 다시 들으며 회의록으로 옮기는 일은 녹음 시간만큼, 때로는 그보다 더 오래 걸립니다. 이 워크플로우는 그 정리 과정을 자동화 대상으로 삼았습니다. 원본 캔버스의 트리거 폴더 이름에 "미팅록 유즈케이스"라는 표현이 남아 있는 걸 보면 강의 실습용 사례로 만들어진 워크플로우라는 걸 알 수 있고, "휴대폰 녹음 기능으로 녹음 후 드라이브에 수동 업로드"라는 스티키를 보면 트리거 앞단은 사람이 폰으로 녹음해 올리는 수작업이고 그다음부터가 자동화 구간이라는 것도 짐작할 수 있습니다.

n8n 설치와 기본 노드 사용법은 n8n으로 반복업무 자동화 포트폴리오 만들기에서 다뤘으니, 이 글에서는 워크플로우만 봅니다. OpenAI 전사·교정·요약 호출은 유료 API라 소액 결제가 필요하고, 뒤에서 다룰 Gemini 변형은 무료 티어로도 시도해볼 수 있습니다.

구조 — Trigger / Task / Target

• Trigger — 지정 폴더 매시간 폴링, 새 파일 생기면 시작
• Task — 다운로드 → 오디오 전사 → 문법 교정 → 3줄 요약·발언자별 정리·액션 아이템
• Target — 구글 문서 삽입 + 노션 DB 페이지 생성 (같은 요약 결과를 두 곳에)

캔버스에는 이 흐름 말고 웹훅으로 들어오는 또 다른 흐름이 하나 더 있는데, Gemini로 오디오를 직접 처리하는 변형입니다. 이건 아래 "원본 캔버스에 남아 있는 흔적"에서 따로 다룹니다.

만들기

1. Google Drive Trigger — 폴더 하나를 매시간 확인

Google Drive Trigger 노드에서 Trigger On을 Changes Involving a Specific Folder, Watch For를 File Created로 두고, Poll Times는 Every Hour로 설정합니다. 명함 OCR 편의 트리거는 1분마다 폴링했지만, 이 워크플로우는 1시간 간격입니다.

2. Google Drive → HTTP Request — 파일을 내려받아 OpenAI로 전사

Google Drive 노드(Operation: Download)로 파일을 내려받은 뒤, HTTP Request 노드로 OpenAI의 오디오 전사 엔드포인트를 직접 호출합니다.

• Method: POST
• URL: https://api.openai.com/v1/audio/transcriptions
• Authentication: Generic Credential Type → Bearer Auth (OpenAI API 키를 credential에 저장)
• Body(multipart/form-data): file(앞 노드가 내려받은 바이너리) + model: gpt-4o-transcribe

스티키에는 "Whisper"라고 적혀 있지만 실제로 지정된 모델은 gpt-4o-transcribe입니다. OpenAI가 오디오 전사 라인업을 Whisper 이후 이 모델로 넘겼기 때문에, 지금 새로 만든다면 이 이름으로 부르는 게 맞습니다. 명함 OCR 편의 Mistral OCR 호출과 마찬가지로 API 키는 Body가 아니라 credential로 분리했습니다.

3. OpenAI 문법 교정 — 딱 한 가지 일만

전사된 텍스트를 그대로 요약에 넘기지 않고, OpenAI 노드(모델: gpt-5-nano)를 하나 더 거칩니다. 시스템 프롬프트는 이렇습니다.

당신은 전문적인 교정 및 편집 에디터입니다.
아래 제공되는 [음성 인식 텍스트]를 바탕으로 다음의 [작업 지침]을 엄격히 준수하여 텍스트를 다듬어 주세요.

[작업 지침]
1. 교정 및 윤문: 맞춤법, 띄어쓰기, 문법 오류를 수정하고 문장의 흐름이 자연스럽게 이어지도록 매끄럽게 다듬으세요.
2. 길이 유지 (요약 금지): 내용을 요약하거나 축약하지 마세요. 원문의 정보량과 길이를 그대로 유지해야 합니다.
3. 누락 방지: 텍스트의 시작부터 끝까지, 어떤 문장도 누락되지 않도록 꼼꼼하게 검토하여 변환하세요.
4. 문맥 수정: 음성 인식(STT) 과정에서 잘못 인식된 것으로 보이는 단어나 문맥상 어색한 표현은 상황에 가장 적합한 단어로 수정하세요.
5. 출력 형식: 교정이 완료된 텍스트만 출력하세요. (인사말이나 부가 설명 생략)

2번 지침이 이 단계의 존재 이유입니다. "요약 금지, 길이 유지"를 못박아 두지 않으면 모델이 교정하면서 슬쩍 문장을 줄여버릴 수 있고, 그러면 다음 요약 단계가 이미 손질된 텍스트를 다시 요약해 원문 세부 내용이 사라질 위험이 커집니다. 이 노드의 유일한 임무는 "글자를 고치는 것"입니다.

4. OpenAI 요약 — 3줄 요약·발언자별 정리·액션 아이템

교정된 텍스트를 다시 OpenAI 노드(같은 gpt-5-nano)에 넘겨 회의록 형태로 정리합니다. 시스템 프롬프트의 핵심만 옮기면 다음과 같습니다.

당신은 비즈니스 문서 정리에 특화된 '수석 서기'입니다.
제공된 회의 스크립트를 분석하여, 바쁜 팀원들이 1분 만에 파악할 수 있는
가독성 최상의 회의록을 작성하세요.

1. 3줄 요약(Executive Summary): 회의의 핵심 목적과 결론을 딱 3문장으로.
2. 발언자별 핵심 발언: 담당 업무는 제외하고, 각 참여자의 주요 의견만 간결하게.
   형식 - **이름**: 주요 발언 요약
3. 담당자별 액션 아이템: 할 일을 담당자별로 그룹화. 담당자 불명확 시 '공통'.
   형식 - **담당자명** / - [ ] 할 일 내용 (마감: 문맥상 유추될 때만 기입)

서론/결론 없이 본문만 출력. Markdown 문법 사용(볼드체, 표, 체크박스 등).

교정과 요약은 같은 모델(gpt-5-nano)을 쓰지만 시스템 프롬프트가 완전히 다릅니다. 하나는 "글자를 고치기만" 하고, 다른 하나는 "구조로 재배열"합니다. 이 노드의 출력이 다음 두 Target 노드로 동시에 흘러갑니다.

5. Google Docs — 문서를 만들고, 그 안에 삽입

n8n의 Google Docs 노드는 문서 생성과 내용 삽입을 한 노드에서 끝낼 수 없습니다. Create a document 노드로 빈 문서를 먼저 만들고(제목은 회의록_{{ $now.format('yyyy-MM-dd') }} 형태), 받은 문서 ID를 다음 Update a document 노드의 Document URL에 넣은 뒤 Action을 Insert로 두고 요약 텍스트를 삽입합니다. 문서를 새로 만드는 워크플로우에서는 이 2단계 패턴을 기억해두면 됩니다.

6. Notion — 같은 요약을 DB 페이지로

Notion 노드(Resource: Database Page)에서 제목을 {{ 오늘 날짜 }} 회의록으로 두고, 속성으로 날짜·문서분류(회의록)를 채운 뒤 본문 블록에 같은 요약 텍스트를 넣습니다. 담당자 속성(다중 선택)에는 "회의 요약봇"이라는 고정값이 들어가 있는데, DB 안에서 사람이 쓴 회의록과 AI가 생성한 회의록을 구분하려는 설계로 보입니다.

원본 캔버스에 남아 있는 흔적 — Gemini 오디오 변형과 애로사항

원본 캔버스를 열어보면 지금까지 다룬 흐름 아래에 또 다른 파이프라인이 있습니다. 웹훅으로 시작해 Gemini로 오디오를 직접 처리하는 변형입니다. 가장 큰 차이는 전사 방식입니다. OpenAI 쪽은 전사 전용 모델(gpt-4o-transcribe)을 텍스트 처리 모델과 따로 불러야 했지만, Gemini 쪽은 오디오 입력을 받는 노드(Transcribe a recording(gemini), 모델: Gemini 2.5 Flash)가 바로 텍스트를 돌려줍니다. 이후 문법 교정과 요약도 같은 Gemini 2.5 Flash로 처리하는데, 교정 단계의 시스템 프롬프트는 OpenAI 쪽과 거의 동일한 문장을 그대로 재사용했습니다. 모델 제공사가 바뀌어도 "교정만 하는 단계"라는 역할 정의는 그대로 옮겨간 셈입니다.

요약 단계는 오히려 Gemini 쪽이 더 구조화돼 있습니다. OpenAI 쪽은 마크다운 텍스트를 그대로 출력하지만, Gemini 쪽은 jsonOutput을 켜고 meeting_date, meeting_title, meeting_oneline, meeting_attendee, meeting_summary 필드를 명시한 JSON 스키마로 답하게 해서, 노션 페이지에 회의 날짜·제목·한줄요약이 각각 별도 속성으로 들어갑니다.

다만 이 변형은 미완성입니다. 캔버스 아래쪽 멀리 떨어진 곳에 Google Docs 생성·삽입 노드 쌍이 하나 더 있고, "Target: 파일 업로드 — Google Docs 생성 및 회의록 업로드" 스티키까지 붙어 있어 OpenAI 쪽과 똑같이 Docs에도 남기려던 흔적이 보이지만, connections에는 이 노드 쌍으로 들어오는 연결이 없습니다. 노션 쪽만 완성되고 Docs 쪽은 만들다 만 상태입니다. 초반에는 웹훅·폼 제출·수동 테스트 세 갈래 입력을 하나로 합쳐 분기하려던 Switch 노드(스티키 이름 "Classify")도 있지만, 여기도 들어오는 연결이 없고 세 출력 모두 비어 있습니다. 실제로 Gemini 처리 체인까지 이어지는 건 웹훅뿐이고, 나머지 두 트리거는 라우터도 처리 체인도 거치지 않은 채 끊겨 있습니다. export를 읽을 때는 이런 미완성 노드를 실제 흐름과 구분하는 것도 기술입니다.

원본 캔버스에는 만든 사람이 직접 남긴 애로사항 스티키도 있어서 그대로 옮깁니다.

사적인 회의 파일은 사용하기가 좀... 괜찮은 회의 음성이 없다.

노션, 구글에 서식 적용 안 되니까 너무 아쉽다.

첫 문장은 테스트 데이터 문제입니다. 실제 회의 녹음은 사적인 내용이 섞여 있어 테스트로 쓰기 애매하고, 마땅한 공개 샘플 음성도 없었다는 뜻으로 읽힙니다. 테스트 트리거 쪽에 공개된 n8n 실습용 저장소의 샘플 음성을 가져오는 노드가 따로 있는 것도 이 정황과 맞아떨어집니다. 둘째 문장은 직접 만들어보면 바로 부딪히는 지점입니다. 요약 프롬프트는 볼드체·표·체크박스 같은 마크다운 문법으로 답하라고 요청하지만, Notion의 본문 블록도 Google Docs의 삽입 액션도 문자열을 그대로 밀어넣을 뿐 서식 있는 블록으로 변환해주지 않습니다. 그래서 최종 문서에는 **담당자**, - [ ] 할 일 같은 기호가 서식이 아니라 글자 그대로 남습니다.

한계

• 서식 손실 — 프롬프트가 요청한 마크다운 서식이 Notion·Docs에 살아나지 않습니다. 체크박스나 표가 꼭 필요하다면 요약 결과를 파싱해 Notion 블록 배열을 직접 만들어 넣어야 합니다.
• 1시간 폴링 — 회의가 끝나자마자 회의록을 받고 싶다면 최대 1시간을 기다려야 합니다. 즉시성이 필요하면 Drive Trigger 대신 폼이나 웹훅 업로드 구조가 낫습니다.
• 에러 처리 없음 — 전사 API가 실패하거나 파일 형식이 안 맞을 때 워크플로우를 멈추거나 알려주는 노드가 없습니다.
• Gemini 변형 미완성 — Docs 출력이 연결되지 않아, 지금 그대로 가져다 쓰면 노션 페이지만 생기고 문서는 생기지 않습니다.

포트폴리오·면접 포인트

이 워크플로우의 핵심은 "전사 → 교정 → 요약" 3단 체인이지, 회의록이라는 소재 자체가 아닙니다. 같은 뼈대로 인터뷰 녹음을 발언 정리로, 상담 통화를 상담 요약으로 바꿀 수 있습니다.

면접에서 "왜 교정이랑 요약을 한 프롬프트로 합치지 않았나요?"라는 질문이 나올 수 있습니다. 답은 프롬프트 안에 있습니다. 교정 단계에 "요약 금지, 길이 유지"라고 명시한 이유는, 한 번에 두 가지 일을 시키면 중간 산출물(교정된 원문)을 따로 검증할 수 없기 때문입니다. 단계를 쪼개면 요약이 이상하게 나왔을 때 원인이 전사·교정·요약 중 어디인지 구분할 수 있습니다. 같은 파이프라인을 OpenAI와 Gemini 두 공급자로 구현해본 경험까지 덧붙이면, 모델을 하나만 써본 사람과 구분됩니다.

다음 액션

이 편은 파일 하나가 문서 전체로 커지는 배치 처리 체인이었습니다. 다음 편은 방향이 바뀝니다. 슬랙에 음식 사진을 올리면 AI가 그 자리에서 평가 댓글을 다는 워크플로우로, 파일을 쌓아두고 나중에 처리하는 대신 실시간으로 응답하는 패턴을 다룹니다.