작성일 : 2026. 07. 06
지난번 포스트에서는 중국 모델들을 데리고 코딩 테스트를 해봤습니다. 그 사이에 Anthropic에서 차단되어 있던 Claude 5 패밀리의 첫 모델, Fable 5가 재공개되었습니다. 이번에는 벤치마크식 테스트보다 실제 프로젝트를 하나 통째로 맡겨보고 싶었습니다.
마침 좋은 핑곗거리가 있었습니다. 이번 인천 펜타포트 락 페스티벌 2026에 같이 가게 된 지인이 락 페스티벌이 처음입니다. 저는 수십년간 들어왔으니 확정 라인업 대부분이 아는 밴드였지만, 처음 가는 사람에게 크루앙빈이 어떤 밴드인지, 픽시즈가 왜 대단한지 하나하나 설명해줄 수는 없는 노릇이었죠.
그래서 자동화된 방법을 만들기로 했습니다. 페스티벌까지 남은 한 달 동안 하루에 한 밴드씩 예습시키는 "하루 한 밴드" 뉴스레터입니다. 만드는 김에 지인 한 명에게만 보내기는 아까워서 누구나 구독할 수 있는 공개 뉴스레터로 방향을 잡았습니다. 원고 생성부터 홈페이지 구축, 인프라 세팅과 검수까지 전부 Fable 5와 함께 하루 동안 진행했고, 이 포스트는 그 과정의 기록입니다.
참고로 펜타포트 공식과는 아무 관련이 없는 비공식 팬 프로젝트입니다.
결과물은 크게 세 가지입니다.
완성된 사이트는 pentaport-2026-newsletter.naram.kim 에서 보실 수 있습니다.
코드보다 먼저 만든 건 에이전트용 지침 문서였습니다. AGENTS.md 를 인덱스로 두고, 프로젝트 개요부터 뉴스레터 형식, 자료 수집 방법, 배포 인프라까지 docs 문서 9개로 쪼개서 정리했습니다. 문서 하나당 200줄 제한을 걸어서, 에이전트가 필요한 문서만 골라 읽을 수 있게 했습니다.
그중에서도 "절대 규칙" 몇 가지가 이 프로젝트 품질의 핵심이었다고 생각합니다.
특히 두 번째 규칙이 중요합니다. 이런 제약이 없으면 AI는 아주 그럴듯한 형식의 가짜 유튜브 링크를 만들어냅니다. 실제로 최종 결과물에서도 요일이 확인되지 않은 4팀은 본문에 "출연일 확인 중"으로 남아 있습니다. 모르는 걸 모른다고 쓰게 만드는 게 생각보다 큰 일입니다.
원고 생성에는 Claude Code의 Workflow(멀티에이전트 오케스트레이션) 기능을 사용했습니다. 구조만 간추리면 이렇습니다.
// 1단계: 라인업 조사 에이전트가 발행 순서를 정리
const lineup = await agent("펜타포트 2026 라인업 조사", { schema: LINEUP_SCHEMA });
// 2단계: 밴드당 서브에이전트 하나가 조사부터 파일 작성까지
const results = await parallel(
lineup.bands.map((band) => () =>
agent(band.name + " 조사 후 뉴스레터 작성", {
model: "sonnet",
schema: REPORT_SCHEMA,
})
)
);
// 3단계: QC 에이전트가 전체 파일을 검사하고 직접 수정
await agent("뉴스레터 전체 파일 형식 검사 및 위반 사항 수정");
메인 세션은 Fable 5가 지휘하고, 밴드별 조사와 작성은 Sonnet 서브에이전트에 맡겼습니다. 조사-작성은 병렬로 돌릴 수 있는 단순 반복 작업이라, 비싼 모델을 쓸 이유가 없으니까요.
각 서브에이전트는 한국어와 영어로 웹 검색을 병행하고, setlist.fm 에서 최근 셋리스트(페스티벌 셋 우선)를 확인하고, 유튜브 링크를 검증한 뒤 파일을 작성합니다. 셋리스트를 못 구한 팀은 인기곡 TOP 10으로 대체하고 그 사유를 본문에 명시하게 했습니다.
물론 한 번에 매끄럽게 끝나지는 않았습니다.
이런 함정들은 전부 지침 문서에 기록해뒀습니다. 다음에 비슷한 작업을 시킬 때 같은 곳에서 넘어지지 않도록요.
두 차례에 걸쳐 서브에이전트 67개가 돌았고, 토큰은 다 합쳐 약 460만이 들었습니다. 밴드 한 팀당 6만 토큰 정도인 셈입니다. 사람이 밴드 하나를 검색하고 셋리스트를 뒤져서 원고를 쓰는 시간을 생각하면, 개인적으로는 꽤 만족스러운 가성비였습니다.
홈페이지 디자인은 "하루 한 밴드"를 "1일 1정"으로 치환하는 데서 출발했습니다. 미국 식품 포장의 영양성분표(Nutrition Facts)를 모티프로 한 의약외품 라벨 컨셉입니다. 구독 신청은 "처방받기", 지난 회차 아카이브는 "복용 기록"이 되는 식이죠.
색은 종이색 배경에 잉크 검정, 액센트는 약국 간판의 레드 딱 하나만 썼습니다. 기술적으로는 Next.js 15에 React 19, CSS 프레임워크 없이 전역 CSS 파일 하나(1,100줄 남짓)로 만들었습니다. 사실 더 최신의 Next.js 를 쓸 수도 있었겠지만, 특별히 스펙상 더 필요한 것이 있지 않았기 때문에 Fable 의 선택을 수용했습니다.
기능적으로 신경 쓴 부분은 두 가지입니다.
첫째, 대표곡 미리듣기 플레이어입니다. 유튜브 IFrame API로 공개된 회차의 곡들을 이어 들을 수 있게 했습니다. 데스크탑 전용으로 제한했는데, 모바일 브라우저의 자동재생 정책과 싸우는 건 이 프로젝트의 범위가 아니라고 판단했습니다.
둘째, 미공개 회차 유출 방지입니다. 아직 발송되지 않은 회차는 페이지가 404를 반환하고, 메타데이터에도 밴드명이 노출되지 않으며, 회차별 오픈그래프 이미지는 파일명을 무작위 토큰으로 만들어 URL 추측으로 다음 밴드를 미리 알 수 없게 했습니다. 어차피 라인업 전체가 공개가 되어 있긴 하지만, 뉴스레터로 하나씩 받아보는 재미가 있지 않겠어요.
이 블로그는 Vercel로 이전했지만, 이 프로젝트는 SST로 AWS에 배포했습니다. 예전에 Open Next SST 3 포스트를 쓴 적이 있는데, 그때의 조합을 다시 꺼내온 셈입니다.
인프라 선정 기준은 하나였습니다. "AWS에서 가장 저렴하게". 구독자 정보, 회차 공개 상태, 발송 이력을 전부 DynamoDB 테이블 하나에 복합 키로 밀어 넣었고, 온디맨드 요금제라 트래픽이 없으면 과금도 없습니다. 지금 규모라면 전체 비용은 사실상 0에 수렴합니다.
SES는 도메인 DKIM 검증부터 프로덕션 액세스 승인 신청까지 하루 안에 끝났습니다. 샌드박스 해제 승인 대기가 이 프로젝트에서 가장 오래 걸린 작업이었을지도 모르겠네요.
무엇보다 인프라를 구성하는 모든 과정을 Fable 에게 일임하고 저는 그것에 대한 승인, 관리, 감독만 수행했습니다. SES 샌드박스 해제마저도 저는 지시와 승인만 진행했습니다. 인프라 세팅만 시켜놓고 잠시 식사를 하고 있었는데 SES 체크 과정에서 샌드박스 테스트용으로 등록한 메일을 찾아 메일 전송 테스트를 알아서 진행해서, 핸드폰에 메일 알림이 오는 걸 보고 굉장히 크게 감탄을 했습니다.
발송 백엔드는 EventBridge Scheduler의 cron으로 매일 아침 Lambda를 깨우는 구조입니다. 발송되지 않은 다음 회차를 계산해서 두 편씩 묶어 구독자에게 보내고, 보낸 회차는 홈페이지에 자동 공개합니다. 구독자가 없는 날에도 공개는 매일 진행됩니다.
소소하지만 신경 쓴 지점들이 있습니다.
발송 시각은 원래 08시였는데, 출근길에 읽기 좋도록 07시로 당겼습니다. 이게 이 프로젝트의 (현재까지) 마지막 커밋입니다.
솔직하게 말하면 유닛 테스트는 한 줄도 없습니다. 하루짜리 프로젝트에서 코드 테스트를 쌓는 것보다, 결과물과 운영 플로우를 직접 검증하는 쪽이 낫다고 판단했습니다. 대신 검수는 세 겹으로 했습니다.
첫째, 콘텐츠 검수입니다. QC 에이전트가 64편 전체를 grep으로 훑으며 금지 패턴(마크다운 헤딩, 볼드, 링크 문법, 표 등)을 검사하고 위반 사항은 직접 수정했습니다. 파일 개수와 회차 번호의 연속성, "오늘의 밴드:" 같은 필수 요소도 체크리스트로 확인했습니다.
둘째, 배포 후 검증입니다. 메인 페이지와 공개 회차가 200을 반환하는지, 미공개 회차와 존재하지 않는 회차가 제대로 404를 반환하는지, Lambda 로그에 권한 오류가 없는지 순서대로 확인했습니다.
셋째, 발송 리허설입니다. 실제 구독 플로우(신청, 확인 메일 수신, 링크 클릭, 확정)를 제 메일로 직접 통과해보고, 발송 Lambda는 dryRun 모드로 먼저 돌려본 뒤에 실제 발송을 열었습니다.
콘텐츠 64편, 홈페이지, 배포 인프라, 발송 자동화까지 하루에 끝났습니다. 돌아보면 제가 한 일은 방향을 정하고, 규칙을 문서로 박아두고, 결과물을 검수하는 것이었습니다. 원고와 코드는 대부분 AI의 손을 거쳤습니다.
Fable 5에 대한 감상을 한 줄로 줄이면, 코딩 능력보다 "일을 시키는 능력"이 좋아졌다는 것입니다. 서브에이전트 수십 개를 병렬로 굴리면서도 규칙 위반을 잡아내고, 실패한 작업을 복원해서 이어가는 오케스트레이션이 인상적이었습니다. 다만 이런 결과는 지침 문서를 먼저 만들어둔 덕이 컸다고 생각합니다. 결국 모델이 좋아질수록 중요해지는 건 무엇을 어떤 규칙으로 시킬지 정하는 쪽이 아닐까 하는, 지난 포스트와 같은 결론에 도달하게 되네요.
페스티벌까지 한 달, 하루 한 밴드면 예습은 충분합니다. 펜타포트에 가시는 분이라면 구독해보셔도 좋겠습니다.
이 블로그는 댓글 기능이 없습니다.
이 게시물에 대한 의견이 있으시면 i.am@naram.kim 으로 메일을 남겨주세요.