서론

대학교 대면 수업을 녹음하고, 그 음성으로부터 정형화된 노트를 자동으로 생성하는 운용을 하고 있습니다.

제가 하는 일은 수업 후에 스마트폰의 녹음 파일을 Google Drive에 업로드하는 것뿐입니다.

그 후에는 집에 있는 Windows PC가 정해진 시간에 알아서 기동하여, 받아쓰기(Transcription)부터 노트 생성, GitHub로의 PR(Pull Request) 생성까지 마칩니다.

귀가할 때쯤이면 스마트폰에 PR이 도착해 있고, 내용을 확인한 뒤 merge(병합)할지 여부를 판단하면 그 주의 노트가 완성됩니다 (제 입으로 말하기 좀 그렇지만, 상당히 쾌적합니다).

이 기사에서는 이 「정기 가동되는 AI 워커」의 구성을 작성하겠습니다.

왜 Mac이 아니라 별도의 Windows 기기인가

제가 평소 사용하는 것은 휴대하고 다니는 MacBook입니다.

하지만 수업이 끝나고 귀가하는 동안 Mac은 닫혀 있어 통신할 수 없습니다.

백그라운드에서 처리를 실행할 방법이 없는 것입니다.

반면, 집에는 Windows 데스크톱 PC가 있습니다.

상주하고 있으며, GPU (VRAM 12GB)를 탑재하여 CUDA를 사용할 수 있는 기계입니다.

받아쓰기는 Mac에서도 할 수 있지만, 굳이 휴대하는 단말기에 무거운 처리를 싣고 다닐 필요가 있는가? 라고 생각하면 답은 No였습니다.

무거운 처리는 집에서 기다리고 있는 쪽의 기계에게 시킨다. 역할 분담은 이것뿐입니다.

파이프라인 전체상

전체는 다음과 같습니다. 주목해 주셨으면 하는 점은 인간의 작업이 첫 번째 한 줄에서 끝난다는 점입니다.

[수업 후] 스마트폰으로 녹음 → Google Drive에 업로드 (인간의 작업은 여기까지)
│
▼ 매주 정해진 요일·시각
...

그림으로 그리면 단계가 많아 보이지만, 하고 있는 일은 「깨어난다 → 가져온다 → 깨운다 → 정돈한다 → 내보낸다」의 일직선 경로입니다.

각 단계의 구성

왜 상시 가동이 아니라 작업 스케줄러(Task Scheduler)인가

상시 가동이 아니라, 평소에는 슬립(Sleep) 상태로 대기시킵니다.

서버처럼 상시 가동해 두는 방법도 있지만, 처리가 실행되는 것은 수업이 있는 요일뿐입니다.

아무것도 하지 않는 시간에 전원을 소비할 이유가 없습니다.

그래서 수업이 있는 요일에 맞춰, 작업 스케줄러(Task Scheduler)를 통해 매주 정해진 요일·시각에 슬립 상태에서 깨어나도록 설정해 두었습니다.

가장 소박한 형태일 것입니다.

다운로드: Google Drive의 녹음 폴더

스마트폰의 녹음을 Google Drive의 지정된 폴더에 두는 운용을 하고 있으므로, 기동 후에는 우선 그곳에서 신규 음성을 다운로드합니다.

이곳이 후속 모든 작업의 기점입니다. 음성이 없으면 아무 일도 일어나지 않습니다 (후술하겠습니다).

받아쓰기: Whisper ＋ Pyannote

받아쓰기는 Whisper, 화자 분리(Speaker Diarization)는 Pyannote입니다. GPU (CUDA)로 돌립니다.

솔직히 이 부분은 비교 검토를 하지 않았습니다. Mac 측의 운용에서 Whisper의 정밀도에 불만이 없었기에 그대로 가져왔습니다.

「수업 녹음에 화자 분리? 거의 교수님 한 명 아닌가?」라고 생각하실지도 모릅니다.

맞습니다, 기본적으로는 1명의 화자로 취급합니다.

그럼에도 Pyannote를 넣은 이유는 수업 중에 영상을 재생하는 장면이 있기 때문입니다.

교수님 이외의 음성이 나왔을 때 「이것은 영상의 나레이터다」라고 구별할 수 있도록 해두었습니다.

정형화: 받아쓰기 × 수업 중 메모

받아쓰기된 텍스트와 제가 수업 중에 적은 메모를 조합하여, Claude Code가 정형화된 노트를 만듭니다.

슬라이드에는 적혀 있지 않지만 교수님이 구두로 말씀하신 내용을 포착하여 노트에 추가할 수 있습니다.

녹음으로부터 굳이 파이프라인을 구축한 이유는 여기 있습니다.

출구: push → PR → 스마트폰에서 merge

생성된 노트는 브랜치(Branch)에 push되며, PR이 생성됩니다.

main에 직접 들어가지 않습니다.

「그 정도로 자동이라면 merge도 자동으로 하면 되지 않나?」라고 생각하실까요.

저는 스마트폰에서 GitHub를 열어 PR의 내용을 보고 merge할지 여부를 판단합니다.

기계가 만든 것을 무조건 메인 흐름(Mainline)에 넣지 않는다, 라는 마지막 단계만은 인간에게 남겨두었습니다.

어디까지 해야 「완전 자동화」라고 부를 수 있는가

이전에는 받아쓰기 서비스에 돌린 결과를 복사해서 붙여넣는 운용도 병행했습니다.

「붙여넣기만 하면 충분히 편하지 않나?」라고 생각하실지도 모릅니다. 실제로 상당히 편했습니다.

그럼에도 저는 이것을 완전 자동화라고 부르지 않습니다.

경계선은, 녹음 파일을 업로드한 시점부터 정리된 노트가 나올 때까지 인간의 작업이 남아있는지 여부라고 생각합니다.

복사 & 붙여넣기(Copy & Paste)는 한 단계의 수고가 들지만, 그 수고는 「매주 반드시 발생하는 수고」입니다.

이 구성에서는 저의 작업이 업로드뿐이 되었습니다.

대면 수업에 대해서는, 이것으로 완전 자동화라고 부를 수 있는 상태일 것입니다.

헛스윙과 실패의 동작

휴강 등으로 음성이 없는 주는 다운로드할 것이 없기 때문에 후속 처리도 기동되지 않고, 헛스윙(空振り) 상태로 종료됩니다.

헛스윙을 위한 특별한 분기(Branch)는 작성하지 않았습니다.

「없으면 아무것도 하지 않는다」가 그대로 헛스윙 처리가 되는 형태입니다.

그렇다면 실패했을 경우에는 어떻게 될까요?

이 구성에서는, 성공했을 때만 PR(Pull Request)이 도착합니다. 즉, PR이 오지 않는다면 무언가 실패했다는 것을 알 수 있습니다.

어디서 멈췄는지는 로그(Log)가 남아 있으므로, 다음에 PC를 만질 때 추적하면 끝나는 문제입니다.

알림 메커니즘을 추가하는 것도 고려했지만, 현재로서는 넣지 않았습니다. 실패해도 다시 하면 그만이기 때문입니다 (이 「실패해도 아무것도 망가지지 않는다」 측면의 설계 이야기는 별도의 기사로 나누어 쓸 예정입니다).

요약

• 휴대하는 Mac은 귀가 중에 닫혀 있어 사용할 수 없으므로, 무거운 작업은 상주 중인 Windows GPU 기기 (CUDA)로 넘겼다
• 작업 스케줄러(Task Scheduler)의 정기 기동 → Google Drive에서 음성 다운로드 → Whisper ＋ Pyannote → Claude Code로 정리 → push → PR 과정을 무인으로 통과시킨다
• 인간에게 남은 작업은 「녹음 파일의 업로드」와 「PR의 merge 판단」 두 가지뿐

음성이 없는 주는 헛스윙, 실패한 주는 PR이 오지 않는 것으로 알 수 있다.

운용 동작에 대한 설명은 이것으로 끝납니다.

집에서 잠자고 있는 PC가 있는 분은, 정기 기동 워커(Worker)로 만들어 보세요.

무거운 작업은 상주 기기로 넘기고, 정기 기동으로 돌린다면 수업 후의 노트 생성은 완전 자동화할 수 있습니다.

Discussion