지난번(기사 5) 말미에 다음과 같이 적으며 마무리했습니다.

나는 Excel VBA를 좋아하는 게 아니다. Lotus 1-2-3도 정말 좋아했고, 줄곧 스프레드시트(Spreadsheet)를 좋아해 왔다. 그래서 Google의 스프레드시트도 꽤 좋아한다. 다음에는 Google 스프레드시트 관련 이야기도 해나가고 싶다.

이 구절을 이번에 조금 정정하겠습니다.

정확히 말하면, 제가 하고 있는 것은 「Google 스프레드시트를 사용하는 쪽」의 이야기가 아니라, 오히려 「Sheets를 사용하지 않는 쪽」의 이야기였습니다. 글을 쓰면서 저 자신도 깨닫지 못하고 있었지만, 최근 어렴풋이 그렇게 생각하게 되었고, 조금 전에 "아, 이거 그런 뜻이었구나" 하고 납득했습니다.

연재 제2부의 입구로서, 이번에는 그 이야기를 쓰겠습니다. 소재는 제가 올해 2월 중순의 「Gemini 3 앱 대회」(마감 직전)에 응모했던 GAS Web 앱 「Q-Quick」입니다. YouTube의 구독 채널을 순회하며 최신 정보를 취득하기 위한 도구입니다.

단, Q-Quick은 갑자기 튀어나온 것이 아니었습니다. 15년 전쯤 Excel + IE의 복사 붙여넣기로 만들었던 YouTube 「썸네일 목록」이, IE의 멸망, Python 좌절, 스프레드시트 버전에서의 타협, Excel 버전에서의 속도 비교, Gemini Antigravity를 통한 재구축, Claude Code를 통한 다듬기를 거쳐, 마침내 「하고 싶었던 형태」로 돌아왔다는 15년의 아크(Arc) 이야기입니다.

내용이 조금 길어집니다.

※ 이 기사의 해설 영상도 만들었습니다

• 15년 전쯤, Excel + IE의 복사 붙여넣기로 만들었던 YouTube 「썸네일 목록」. 이것이 GAS Web 앱 「Q-Quick」의 원형입니다.
• 스프레드시트 버전은 클라우드의 지연(Latency) 때문에 무거웠습니다. **Sheets를 사용하지 않고 GAS 단독(JavaScript만 사용)**으로 데이터를 보유하게 했더니, 검색이 폭속(爆速)해졌습니다. - 썸네일이 포함된 목록이 15년 만에 부활.
  시트를 버리고, 시트적인 구조를 스프레드시트 소프트웨어 외부에서 구동한다 —— AI와 함께라면, 사무원이라도 이것을 하루 만에 할 수 있습니다.

15년 전, 저는 Excel과 Internet Explorer의 조합으로 YouTube 채널 목록을 Excel에 붙여넣어 관리하는 매크로를 만들고 있었습니다. 「썸네일 목록」이라고 불렀습니다. 썸네일이 포함된 상태로 목록을 표시하는 것이 핵심이었습니다.

메커니즘은 지극히 단순한, **복사 붙여넣기 (Copy-Paste)**입니다. API가 아닙니다.

당시의 IE에는 웹 페이지에서 이미지를 포함한 HTML을 복사하면, 이미지 본체(JPEG)까지 함께 클립보드(Clipboard)로 운반해 주는 동작이 있었습니다. 클립보드에 「HTML Format」뿐만 아니라 「이미지 오브젝트 (Image Object)」도 동시에 실어 보냈다는 뜻입니다. 그것을 Excel에 붙여넣으면 이미지가 오브젝트로서 셀에 삽입되었습니다. 제목이나 조회수 같은 텍스트 데이터는 HTML 유래 텍스트로서 별도의 셀에 들어갔습니다.

지금의 Chrome에서는 이 동작을 재현할 수 없습니다. 정확히 말하면, 복사 붙여넣기를 해도 무언가는 붙여넣어지지만, 보이지 않거나 지나치게 거대해서 매우 정돈하여 목록으로 사용할 수 있는 상태가 되지 않습니다. 당시의 IE는 클립보드에 썸네일 이미지의 본체(JPEG)를 Excel이 순순히 받아들일 수 있는 형태로 실어 주었습니다. 지금의 YouTube 썸네일은 WebP 형식이고, Chrome의 클립보드 전달 방식도 당시와는 다릅니다. **IE와 Excel, 그리고 썸네일을 JPEG로 시트에 붙여넣을 수 있다는 것, 이 세 가지가 갖춰져야 비로소 성립되는 힘의 논리(力技)**였습니다.

구체적인 조작 순서는 다음과 같습니다. 브라우저에서 YouTube 채널 페이지를 엽니다. 동영상 제목이 나열된 영역을 수작업으로 모두 표시하여 Ctrl+A로 선택하고, Ctrl+C. Excel로 전환하여 첫 번째 셀에서 Ctrl+V. 그러면 썸네일 이미지와 제목이 제각각 붙여넣어집니다. 잘 한 줄로 나열되므로, 이미지가 셀의 경계에 들어맞도록 미리 셀의 높이를 조정해 두어 다음 VBA 정형 작업이 하기 쉬운 형태로 가져옵니다.

그다음부터가 VBA의 일이었습니다. Worksheet.Pictures에서 이미지 오브젝트를 차례대로 가져와서, Picture.TopLeftCell

에서 앵커 셀 (Anchor Cell)을 다시 설정하고, 썸네일이 깔끔하게 나열되도록 한 줄씩 정렬한다. 텍스트는 정규 표현식 (Regular Expression)을 사용하여 동영상 제목과 조회수를 분리한다. 최종적으로 「채널명 · 썸네일 · 제목 · 조회수」가 한 줄로 나열되는 표가 되는 것이 정렬 매크로의 역할이었습니다.

정렬 매크로는 꽤 힘들었습니다. 채널마다 레이아웃이 미묘하게 달라서 예외 처리 (Exception Handling)가 쌓여갔습니다. 처리 시간도 어느 정도 걸렸습니다. 그럼에도 당시의 저에게는 "썸네일과 함께 채널을 순회할 수 있는, 나만의 전용 도구"가 손에 있다는 만족감이 컸습니다.

이것이 Q-Quick의 원형입니다.

IE (Internet Explorer)가 지원 종료되었습니다 (2022년 6월). 같은 방식으로는 물리적으로 불가능해졌습니다.

여기서 Python으로 넘어가려 했던 것은 기억납니다. 스크레이핑 (Scraping)을 작성해보고 싶었습니다. requests로 페이지를 가져오고, BeautifulSoup로 동영상 정보를 뽑아내며, 이미지는 URL에서 개별적으로 다운로드하는 것이 정석입니다. 시도해 보았습니다. 사실은 조금 어려워서 하지 못했습니다. "YouTube의 약관에 걸리기 때문에 하지 않았다"라고 멋지게 써도 되지만, 솔직한 사실은 제 능력 밖이라 작성할 수 없었다는 것입니다. Python은 지금도 그렇게 실력이 늘지 않았습니다.

대신 Google 스프레드시트 + GAS (Google Apps Script)로 비슷한 것을 만들었습니다. 스프레드시트에는 YouTube 서비스가 표준으로 연결되어 있어 데이터 취득 자체는 식은 죽 먹기입니다. 동영상 제목, 조회수, 게시 일시, 썸네일 URL은 가져올 수 있습니다.

다만, 썸네일 이미지를 Excel 때처럼 나란히 표시할 수는 없었습니다. Sheets의 셀에 이미지를 삽입하려면 =IMAGE(url) 함수가 있지만, 당시의 사용 편의성으로는 표시가 느리거나 렌더링이 깨지는 등 안정적이지 않았습니다. 어쩔 수 없이 시트 위에 동영상 링크 URL만 나열하고, 마우스를 올리면 썸네일이 미리보기로 표시되는 Sheets의 hover 기능으로 버텼습니다. 당시의 저는 그것으로 "뭐, 괜찮겠지"라고 생각했습니다. 썸네일이 포함된 목록이라는 15년 전의 원형은 여기서 일단 포기하게 되었습니다.

한동안 스프레드시트 버전을 사용해 왔는데, AI (Gemini)를 사용하기 시작할 무렵, AI의 도움을 받아 똑같은 도구를 Excel로도 만들어 보았습니다. 사실 Excel에서 YouTube Data API를 호출하는 구성에는 이전부터 관심이 있었지만, API 키 취득이나 인증 절차를 조사하는 것이 번거로워 계속 손을 대지 못하고 있었습니다. 그런데 AI에게 물어보니 친절하게 가르쳐 주었습니다. AI를 사용하기 시작하면서 이런 "지금까지 포기했던 영역"이 점점 가능해지고 있다는 체감이 듭니다.

그렇게 완성된 것이 「유튜브 최신 정보.xlsm」이라는 파일입니다. 목적은 속도 비교였습니다. 클라우드 측 (스프레드시트 + GAS)과 로컬 측 (Excel + VBA + YouTube Data API) 중 어느 쪽이 정말 빠른지를 명확히 하고 싶었습니다. 이 검증은 제 YouTube 채널 「슈」에서도 영상으로 만들었습니다.

재료로는 인기 채널을 사용했습니다. 동영상 1,300개 이상인 채널을 대상으로 양쪽에서 동일한 「전체 동영상 리스트업」을 수행하게 하고, 시간을 측정합니다.

결과는 다음과 같았습니다:

Excel의 압승이었습니다.

원인은 단순합니다, 바로 **클라우드의 지연 (Latency)**입니다. 스프레드시트 + GAS 구성에서는 데이터를 가져올 때마다, 검색을 한 번 할 때마다 PC와 서버를 몇 번이고 왕복합니다. 클라이언트 (브라우저) → GAS → Sheets API → 스프레드시트 → 브라우저라는 라운드 트립 (Round Trip)을 매번 거칩니다. 통신 대기 시간 자체가 본체 처리 시간보다 길어집니다. 이것은 데이터가 무거워질수록 더 크게 작용합니다.

Excel에 같은 도구를 두었더니 이 문제가 전부 사라졌습니다. 시트 위에 나열된 데이터를 Find로 찾기만 하거나, VBA로 배열을 훑기만 하면 됩니다. 서버를 거치지 않고 메모리 상에서 완결됩니다.

여기서 한 가지, 확실히 체감한 것이 있습니다. 클라우드가 편리한 것은 틀림없다. 다만, 데이터가 무거워지는 작업에서는 클라우드의 지연 (Latency) 자체가 발목을 잡는다. 저의 경우, YouTube 채널 순회는 목록 취득과 검색을 몇 번이고 반복하는 작업입니다. 검색이 "버벅거리면" 도구로서 손이 멈추게 됩니다.

이때는 아직, "그렇다면 클라우드 자체를 빼버리면 된다"라는 발상까지는 이르지 못했습니다. 그저 "Excel이 더 빠르다"라는 체감을 얻었을 뿐입니다. 하지만, 이 체감이 나중에 결정적인 역할을 합니다.

제3장의 비교를 통해 "Excel이 더 빠르다"는 것을 알게 되었습니다. 다만, Excel 파일은 배포하기 어렵고 스마트폰에서는 열 수 없습니다. 타인이 부담 없이 사용할 수 있는 형태로 만들고 싶다고 하면, 결국 Web 앱으로 만들지 않으면 전달할 수 없다는 이야기입니다.

마침 그 타이밍에, 유튜버 코스케(こーすけ) 선생님께서 "Gemini 3 앱 대회"를 개최하고 계셨습니다. 응모 조건은 대략 두 가지였습니다:

Gemini 3를 사용할 것
누구나 사용할 수 있는 Web 앱일 것

응모해 보기로 했습니다. Gemini 3를 사용하는 것은 정해져 있으므로, 당시 사용하기 시작했던 Antigravity (Gemini를 내장한 IDE)로 작성하게 됩니다.

문제는 ②번인 "Web 앱" 쪽이었습니다. Excel이나 스프레드시트(Spreadsheet)로 해왔던 것들을 어떻게 Web 앱화할 것인가. 처음에는 스프레드시트로 Web 앱화를 시도했습니다. 스프레드시트에서도 GAS Web 앱은 만들 수 있으니까요. 하지만 제3장에서 보았던 클라우드 지연이 그대로 따라와서, 결국 이것도 느렸습니다.

여기서 AI에게 상담했습니다. 돌아온 답은, GAS 단독 (JavaScript만)으로 만든다는 것이었습니다. 스프레드시트를 거치지 않고, Web 앱의 토대만 GAS에 두고 데이터는 앱 측에서 보유하는 방식입니다.

처음 시도한 것은 본래 목적인 G-Quick (Google Drive의 파일 목록을 폴더 관계없이 하위 폴더를 포함하여 전부 가져와 업데이트 날짜순으로 정렬하는 앱. 다음 기사에서 다루겠습니다) 쪽이었습니다. G-Quick으로 시트를 제외한 구성을 짜보았더니, 검색이 폭속(爆速)이 되었습니다. 이것은 효과가 있구나, 라고 깨달았습니다.

그 방침을 이번 이야기인 Q-Quick에도 적용해 보기로 했습니다. Q-Quick 쪽은 Web 앱화가 비교적 쉽게 진행되었습니다. '유튜브 최신정보.xlsm'이라는 Excel 기반이 있고, 다루는 구조도 단순하기 때문입니다 (채널별로 동영상 목록을 묶기만 하면 됩니다).

대회 결과는 결과 발표 영상에서 발표되었습니다. 저의 Q-Quick에 대한 직접적인 언급은 특별히 없었습니다. 그것은 그것대로, 응모자로서 완결된 것입니다.

응모하고 얼마 지나지 않아, 저는 Claude Pro를 구독했습니다. 평판이 좋다는 이야기를 들었기에 시험해 보고 싶었습니다. 그때까지의 작업장이 Antigravity + Gemini였으므로, 딱히 Gemini가 나빠서 갈아탄 것은 아닙니다. 구독 타이밍과 평판 때문에 작업장이 바뀌었을 뿐입니다.

사실 전전회(번외편)에서 썼듯이, 저는 Claude에게 「秀.xlsm」의 배포판을 수정해 달라고 요청했으나 실패하고, Antigravity의 Gemini에게 도움을 받았던 경험이 있습니다. 그 기사에서 "Claude 완패"라고 썼지만, 아무래도 Gemini가 버전 업그레이드된 것이 진상이라고 생각합니다. Gemini도 Claude도, 둘 다 사용한다는 것이 지금 저의 운용 방식입니다.

Q-Quick NEXT의 개량을 Claude Pro로 계속했습니다. 서버 측을 git diff 관점에서 보면, 응모 버전 (Gemini 버전)에서 개량 버전 (Claude 버전)으로의 차분은 다음과 같습니다:

Claude가 다듬어 준 주요 포인트는 다음과 같습니다:

: 2024년 이후 YouTube가 밀고 있는 @handle 대응
@handle 형식을 해결하기 위한 resolveChannelHandles

함수 신규 추가 -
서버 측 병렬화 (Parallelization): UrlFetchApp.fetchAll()을 사용하여 여러 채널을 병렬로 가져오도록 -
클라이언트 측 키보드 조작: ↑↓ Enter Space Home End / Escape로 모든 조작이 가능하도록 -
견고화 (Robustness): 폴백 처리 (UC→UU 변환 실패 시 재시도), 에러 핸들링 (Error Handling) 엄격화, 캐시 (Cache) 주변의 견고화

응용 버전 (Gemini 버전)의 핵심은, 데이터를 UserProperties로 보유하는 것과,

UC→UU

변환을 통해 API 호출을 1회 생략하는 것입니다. Gemini로 세운 골격을 그대로 남겨둔 채, Claude가 그 주변을 다듬었다는 분담 방식입니다. 골격이 좋으면 세부적인 다듬기를 통해 완성도가 올라갑니다. 골격에 문제가 있다면 아무리 다듬어도 소용이 없습니다. Gemini로 골격이 세워져 있었다는 점이 컸습니다.

코드는 GitHub의 Qquick-NEXT 리포지토리를 확인해 주세요.

PC에서 사용할 때는 마우스를 쓰지 않고 ↑↓ Enter Space Home End / Escape로 모든 조작을 할 수 있습니다. 이는 秀.xlsm의 '메뉴에서 호출하기', '키보드 구동'의 계보입니다. Lotus 1-2-3의 메뉴 구조를 매크로로 자동화하던 1988년부터, 저는 줄곧 키보드만으로 완결되는 도구를 만들고 싶었던 것 같습니다.

그리고 여기서 약 15년 전부터 되찾고 싶었던 것에 드디어 도달했습니다.

썸네일이 포함된 목록입니다.

Q-퀵을 만들고 있을 때, 저는 AI에게 "썸네일을 가져와서 화면에 표시하는 것이 간단히 가능한가요?"라고 물었습니다. "가능합니다"라는 즉답에 놀랐습니다.

약 15년 전에는 IE × Excel의 복사 붙여넣기로만 가능한 일이라고 믿고 있었습니다. 스프레드시트 시대에도, Excel 버전을 만든 후에도, **"썸네일 표시는 Excel이 아니면 무리다"**라고 멋대로 생각하고 있었습니다. 그런데 AI가 내놓은 설명은 이랬습니다.

"YouTube API의 응답(Response)에 thumbnails.medium.url이라는 필드가 있습니다. 이것을 <img 태그의 src에 넣기만 하면 됩니다."

const thumbnail = item.snippet.thumbnails.medium.url;
// later:
`<img src="${thumbnail}">`

이것뿐입니다. 15년 동안 "벽"이라고 생각했던 것은 벽이 아니었던 셈입니다.

실제로 해보니 정말 금방 되었습니다. 썸네일 포함, 검색 즉시 실행, 게다가 스마트폰에서도 접속 가능. 약 15년 전의 Excel + IE 버전에서 하고 싶었지만 당시에는 할 수 없었던 기능까지 합쳐져서 돌아왔습니다.

VIP 기능 (선두 채널 우선 표시), 다크/라이트 모드 전환, @handle 대응, 조회수 배지, 상대 시간 표시 ("NEW · 6시간 전" 같은 것). 이것들은 당시의 Excel 버전에는 없던 것들입니다.

여기까지 쓰고 나니 스스로도 정리가 되었습니다.

제가 해온 일은 Excel과 Google Sheets 중 어느 쪽이 더 우월한가의 문제가 아닙니다. 시트(Sheet)적인 데이터 구조를 스프레드시트 소프트웨어 외부에서 구동한다는, 유파(流派)의 문제입니다.

연재 제1부에서 쓴 秀.xlsm의 "Sheets를 작업의 장으로 사용하는" 설계와, 이번 Q-퀵의 "Sheets를 사용하지 않고 UserProperties로 보유하는" 설계는, 같은 사상을 가진 Excel 측과 Google 측의 구현이었습니다. 저는 40년 가까이 줄곧 같은 일을 하고 있었던 것입니다.

지금 직장에서는 Gmail을 대상으로 한 동일한 구조의 Web 앱도 만들고 있습니다. M-퀵이라는 이름으로, Gemini Flash 3.5와 함께 작성하고 있습니다. Drive, YouTube, Gmail 등 대상은 바뀌어도 설계의 골격은 같습니다. 시트적인 데이터 구조를 스프레드시트 소프트웨어 외부, 즉 JavaScript 측에서 구동하는 것입니다.

Q-Quick 같은 앱은 다른 누군가가 만들어주면 좋을 텐데, 라고 줄곧 생각해 왔습니다. "썸네일이 포함된 목록 형태의 Web 앱 정도는 누구나 만들 수 있을 텐데"라고 말이죠. 하지만 최근 깨닫고 있는 것은, 제가 15년 전부터 "썸네일 목록"을 계속 만들어온 밑바탕이 있기에 지금의 형태가 보이는 것이라는 점입니다.

밑바탕이 없는 사람에게는 만들기가 어렵습니다. 15년 전쯤의 IE × Excel을 이용한 복사/붙여넣기(Copy-Paste) 정형화 작업이 없었다면, "썸네일 포함 목록"이라는 최종 목표 이미지가 확고해지지 않았을 것입니다. 스프레드시트 버전의 임시방편(hover 凌ぎ)이 없었다면, "타협해서는 안 된다"라는 감각도 가질 수 없었을 것입니다. 5개월 전 Excel 버전과의 속도 비교가 없었다면, "클라우드의 지연(Latency)이야말로 본질이다"라는 체감도 없었을 것입니다.

그리고 Google 계열은 발표하는 문화가 없기 때문에, 밑바탕이 있는 사람이 있어도 작품이 세상에 나오지 않습니다. 발표하는 문화(Excel VBA 문화)에서 자라난 제가, 발표하는 문화가 없는 영역에 작품을 내놓고 있는 것일지도 모릅니다. 그저 그것을 하고 있을 뿐일지도 모릅니다.

저는 Excel과 Google을 모두 사용하는 쪽입니다. 두 가지를 모두 사용하는 '이도류(二刀流)'로 만들고 있기 때문에, 한쪽만 다루는 사람에게는 쓰기 어려운 코드가 되어 있을지도 모른다는 것은 저만의 자의적인 해석입니다. 하지만 최근 어렴풋이 그렇게 느끼기 시작했다는 것은 사실입니다.

저는 사무원입니다. 15년 전에는 썸네일 목록을 만들기 위해 수년의 시간을 들여 계속해서 개선해 왔습니다. 복사해서 붙여넣고, VBA로 이미지를 정렬하고, 에러 처리(Error Handling)를 추가하고, 다시 망가지면 고치고를 반복했습니다.

지금은 AI와 함께라면 같은 것을 하루 만에 만들 수 있습니다. Q-Quick도 기본적으로는 하루 만에 형태를 갖추었습니다. 5개월 전의 Excel 버전인 "유튜브최신정보.xlsm"도 AI 덕분에 금방 만들 수 있었습니다. Gemini가 골격을 만들고, Claude가 세부 사항을 다듬으며, 제가 판단하는 방식의 분업입니다.

시트(Sheet)는 필요 없습니다.

보통의 사무원은 시트를 사용합니다. 시트의 범주에서 벗어나지 못합니다. 하지만 시트를 버리고, 시트적인 구조를 JavaScript로 구동하면, 사무원이라도 폭속(爆速)의 앱을 만들 수 있습니다. 폭속으로 만들 수 있다면 업무에 도움이 됩니다.

이러한 방식은 아직 거의 알려져 있지 않습니다. "Web 앱은 프로그래머가 만드는 분야"라고 생각되어지곤 합니다. 하지만 틀렸습니다. AI가 가능해졌기 때문에, 사무원이라도 JavaScript만으로 소프트웨어를 만들 수 있게 된 것입니다.

15년 전에는 수년이 걸렸던 일을, 지금은 하루 만에 할 수 있습니다. 이것은 사무원에게 있어 혁명입니다.

이 사실을 알아주었으면 합니다. 그것이 Q-Quick NEXT를 공개하고 이 글을 쓴 가장 큰 이유입니다.

Q-Quick NEXT의 코드는 GitHub에 공개했습니다 (MIT 라이선스).

간편하게 사용하고 싶은 분은, Drive 공유 링크를 열어서 드라이브에서 **우클릭 → "사본 만들기"**를 하면 자신의 드라이브로 통째로 복제할 수 있습니다 (코드 복사/붙여넣기는 불필요). 만들어진 사본을 자신의 계정으로 배포(Deploy)하기만 하면 됩니다. 썸네일이 포함되어 있고, 검색이 즉각적이며, 스마트폰에서도 열 수 있습니다.

15년 전의 Excel + IE 복사/붙여넣기 정형화 매크로부터, 5개월 전 Excel 버전과의 속도 비교를 거쳐, Q-Quick NEXT의 현행 버전까지, 결국 제가 하고 싶었던 것은 "시트적인 구조를 자신의 도구에 편입시켜, 썸네일과 함께 구동하는 것"이었습니다.

도구는 시대에 따라 변하지만, 핵심은 계속 같았던 것 같습니다. Lotus 1-2-3 시절에도, Excel + IE 시절에도, 秀.xlsm 시절에도, Q-Quick 시절에도, 시트의 형태를 빌린 무언가를 자신의 손안에 두고 싶었을 뿐이었다는 사실이 Claude Code와 대화하는 과정에서 보이기 시작했습니다.

다음 회차부터는 G-Quick (Drive)에 관한 이야기를 할 예정입니다. 'Quick 계열'의 가족 소개가 될 것입니다.