한 줄 요약

영상 인터뷰 편집의 기쁨과 고통

하이라이트

• 초기 독자들에게 챕터 목록에 대해 유용한 피드백을 받았습니다.
• 인터뷰 영상 편집은 답답했지만 텍스트 전사본을 만드는 과정은 즐거웠습니다.
• 프리랜서 블로그 편집 서비스를 홍보하려던 계획이 예상보다 훨씬 잘 풀렸습니다.

목표 달성 평가

매달 초에 이루고 싶은 목표를 정합니다. 이번 달 목표 달성 결과는 다음과 같습니다.

한 번도 대화한 적 없는 독자 20명에게 개인화된 이메일 보내기

• 결과: 대신 챕터 설문조사를 진행하기로 했습니다
• 평가: 해당 없음

몇몇 독자와 대화해보니 현시점에서는 모든 독자를 대상으로 한 폭넓은 설문조사를 하는 편이 더 나은 전략이라는 생각이 들었습니다.

Refactoring English 새 챕터 출간하기

• 결과: “Get to the Point” 챕터를 출간했습니다
• 평가: A

마침내 서론에 관한 챕터를 완성했습니다. 서론은 제가 글쓰기에서 가장 어려워하는 부분이라 이 챕터를 쓰는 것이 가장 힘들었습니다. 그래서 이 챕터는 서론에 대한 글이자, 제가 서론을 어떻게 쓰는지를 역으로 분석하려는 시도이기도 했습니다.

이 챕터에는 예산도 훨씬 초과했습니다. 처음에는 6시간이면 완성할 수 있을 거라고 예상했지만, 결국 19시간을 들였습니다.

남은 마케팅 작업 마무리하기

• 결과: 인터뷰 편집은 마쳤지만 행동 유도 문구는 마치지 못했습니다
• 평가: B+

미뤄두었던 가장 큰 작업인 인터뷰 편집은 끝냈습니다. 아직 책 웹사이트 디자인을 무료 메일링 리스트 구독이 아닌 얼리 액세스 구매 중심으로 바꾸는 작업은 손대지 못했습니다.

Refactoring English 지표

지난달에는 책 관련 지표가 양호하다고 생각했습니다. 인기 있는 새 글을 올리지 않았는데도 웹사이트 방문자 수와 수익이 모두 증가했기 때문입니다.

그 후 지표에 그래프를 추가하고 나니 다른 패턴이 보였습니다. 책 수익이 책 웹사이트 방문자 수와 밀접하게 연동되는 것으로 보입니다. 7월에는 인기 글이 없었다고 생각했지만, 8월에 책 웹사이트에 아무 것도 게시하지 않자 지표가 급락했습니다.

제가 얻은 교훈은 결국 웹사이트에 꾸준히 새로운 콘텐츠를 올려야 새로운 독자, 특히 책에 돈을 지불할 의향이 있는 독자를 계속 유입시킬 수 있다는 점입니다.

챕터 목록에 대한 독자 피드백 해석하기

개별적으로 독자들과 대화해보니 어떤 챕터가 유용하다고 느끼는지가 사람마다 매우 달랐습니다. 독자들이 가장 관심을 갖는 챕터가 무엇인지 더 잘 파악하려면 설문조사를 하는 편이 낫겠다는 생각이 들었습니다.

이전에 메일링 리스트를 통해 피드백을 요청했을 때 응답이 몇 건에 그쳤기 때문에 이번에도 응답률이 낮을 거라 예상했습니다. 그런데 독자들은 이번 설문에 훨씬 적극적으로 참여해주었고, 2주 만에 133건의 응답이 모여 놀랐습니다.

책 웹사이트에 응답에 대한 상세 분석을 올렸습니다.

• 챕터 목록에 대한 독자 피드백

요약하자면 유용한 피드백을 받았고, 그 덕분에 챕터 순서를 바꾸고 독자들이 별로 좋아하지 않았던 한 챕터를 새롭게 구성하게 되었습니다.

이번 응답률과 이전 피드백 요청 때의 응답률을 비교해보는 것도 흥미로웠습니다. 예전에는 샘플 챕터를 보내고 피드백을 요청했는데, 차이는 독자에게 요구하는 작업량 때문인 것 같습니다. 이번 설문은 몇 분이면 끝낼 수 있지만, 챕터 피드백을 하려면 챕터를 읽고 고민하는 데 30분은 들여야 하고, 설문을 받았을 때 당장 그럴 준비가 되어 있지 않을 수도 있습니다.

30분짜리 영상 인터뷰 편집의 뜻밖의 어려움

2024년 7월, 블로깅 강좌인 Hit the Front Page of Hacker News를 다시 시작하는 과정에서 Adam Gordon Bell과 인터뷰를 녹화했습니다. 육아휴직에 들어가기 전까지 강좌를 완성하지 못했고, 결국 재단장 계획은 무기한 보류했습니다.

그 때문에 인터뷰 처리가 난처해졌습니다. Adam이 시간을 내어 흔쾌히 응해주었는데, 인터뷰를 전혀 공개하지 않자니 죄송한 마음이 들었습니다.

Refactoring English 얼리 액세스를 시작하면서 인터뷰를 공개하기에 좋은 시기라고 생각했습니다. 사람들이 인터뷰를 마음에 들어 하면 책에도 관심을 가질 수 있을 테니까요.

미루고 미루던 일을 두고 “이렇게 오래 미루다니 바보 같다. 그냥 앉아서 하면 한 시간 만에 끝나고 머리에서 지워버릴 수 있을 텐데”라고 생각해본 적 있을 겁니다. 저는 이 인터뷰도 분명 그런 일일 거라고 확신했습니다.

하지만 그렇지 않았습니다.

오디오 싱크 어긋남이라는 고질병의 재발

인터뷰는 Riverside라는 서비스로 녹화했습니다. 통화가 끝나면 Riverside가 통화 양쪽의 영상 파일을 각각 생성하고, 대화가 합쳐진 싱크가 맞춰진 버전도 만들어줍니다. 당시에는 영상이 제대로 작동하는지 대충 확인만 하고 꼼꼼히 보지는 않았습니다.

합쳐진 버전을 그대로 YouTube에 올리면 끝나는 작업이라고 생각했습니다. 혹시 끊김이나 긴 곁길 이야기가 있으면 잘라낼 수는 있겠지만, 영상은 거의 완성된 상태라고 여겼습니다.

녹화한 지 1년이 지나서야 영상을 꼼꼼히 보게 되었는데, 오디오와 비디오가 서로 어긋나 있다는 것을 알게 되었습니다. 영상에서는 입이 움직이기 전에 목소리가 먼저 들렸습니다.

괜찮습니다. FFmpeg로 영상을 재처리해서 오디오를 조금 옮기면 되니까요.

하지만 아니었습니다. 대화의 양쪽에서 오디오 어긋남 정도가 달랐습니다. Adam 쪽은 약 425ms, 제 쪽은 약 150ms 밀려 있었습니다. 그래서 합쳐지기 전의 원본 영상들로 돌아가 각각 싱크를 바로잡은 뒤 직접 다시 합쳐야 했습니다.

쓸 만한 오픈소스 비디오 편집기 찾기

원래 영상 편집에는 Adobe Premiere를 사용했지만, 작년에 리눅스로 옮기면서 Premiere를 쓸 수 없게 되었습니다. 게다가 이제는 Adobe라는 회사 자체가 지긋지긋합니다.

지난여름부터 배워두었던 비디오 편집기인 Shotcut으로 편집을 시작했습니다. Shotcut에서 영상을 나란히 배치하는 방법조차 알아내는 데 시간이 걸렸지만, 결국 확대·자르기 필터를 조합해 어떻게든 구현했습니다.

Shotcut에서 편집할 때 재생이 엄청나게 끊겼습니다. 비교적 새 고사양 데스크톱에서도 1080p 영상 두 개를 합치는 데 버거워했기 때문입니다. 그래서 영상이 실제로 어떻게 들리는지 확인하려면 영상을 내보내야 했습니다. 그런데 Shotcut은 영상의 일부만 내보내는 기능을 지원하지 않아서, 매번 30분짜리 전체를 내보내야 했고 그때마다 몇 시간이 걸렸습니다. 참고로 나중에서야 Shotcut에서 편집 중 재생 해상도를 낮춰 성능을 높일 수 있다는 것을 알게 되었습니다.

내보낸 뒤에야 클립을 분할할 때마다 Shotcut이 큰 팝 노이즈를 삽입한다는 것을 알게 되었습니다. 실제로 분할 지점에서 뭔가를 잘라내지 않아도 발생했습니다. 하나의 연속된 클립을 단순히 두 개로 나누는 행위만으로 팝 노이즈가 생긴 것입니다.

이 팝 노이즈가 Shotcut의 알려진 문제라는 것을 알게 되었는데, 믿기 어려웠습니다. 분할할 때마다 거슬리는 오디오 결함이 생기는데 어떻게 영상을 편집하라는 건지요? 그런데 많은 댓글 작성자들은 모든 영상·오디오 편집 툴에 같은 문제가 있다고 말했습니다.

이게 무슨 말인가요?!

저는 다른 툴로 수백 개의 미디어 파일을 편집해왔지만, 클립을 분할한다고 팝 노이즈가 끼는 경우는 한 번도 본 적이 없습니다.

리눅스용 다른 오픈소스 비디오 편집 툴도 시도해보았습니다. Kdenlive는 편집을 시작한 지 몇 분 만에 충돌했고, Flowblade는 아예 실행되지 않았지만 결국 우회 방법을 찾았습니다. 그리고 Flowblade는 Shotcut을 더 단순하게 만든 것 같아서, 다시 Flowblade에서 편집을 시작해 나란히 배치하는 방법을 다시 알아내야 했습니다.

Flowblade에서 한 시간 정도 편집한 뒤 영상을 내보내보니 팝 노이즈가 다시 나타났습니다. 그쪽에도 같은 버그가 있었고, 그들이 파악한 원인은 다름 아닌 Shotcut의 개발자인 Dan Dennedy의 설명에 근거한 것이었습니다. 그리고 Flowblade도 Shotcut을 구동하는 것과 같은 미디어 프레임워크인 MLT 위에 만들어진 것으로 보였습니다. 결국 같은 버그로 다시 돌아간 셈이었습니다.

어쨌든 이 편집 모험담은 이미 너무 길고 지루하니 결론만 말하자면, 결국 영상의 오디오 샘플링 레이트를 44.1kHz에서 48kHz로 변환해서 팝 노이즈를 우회했습니다. 그렇게 하니 팝 현상이 사라졌지만, 왜 그런지는 모르겠습니다.

영상을 편집하는 동안 다른 버그도 많이 겪었지만, 여기에서 일일이 설명하기에는 너무 지루합니다.

영상 편집에서 얻은 교훈

• 가능한 한 많은 사전 처리를 FFmpeg 스크립트로 하세요.
• 나중에 사전 처리를 조정해야 할 경우를 대비해 FFmpeg 스크립트를 저장해두세요.
  • 다시는 사전 처리를 할 일이 없을 거라고 확신하더라도 스크립트를 저장하세요. 가능하면 버전 관리에 넣어두는 것이 좋습니다.
• FFmpeg 스크립트가 의도한 대로 동작하는지 극단적인 값으로 테스트해보세요.
  • 오디오 싱크 어긋남을 바로잡기 위해 오디오를 200ms 옮겨보았지만 여전히 어긋나 있었습니다. 300ms로도, 400ms로도 마찬가지였습니다. 결국 2000ms로 확 옮겨보고 나서야 스크립트에 버그가 있다는 것을 깨달았습니다. 200ms 보정과 2000ms 보정이 똑같이 들렸기 때문입니다.
• 적정한 설정값을 확신할 수 없을 때는 FFmpeg로 여러 버전을 만들어 옵션을 비교하세요.
  • 저는 대화 중 제 쪽 배경 소음을 제거하는 여러 전략을 테스트할 때 이렇게 했습니다.
• 오디오 샘플링 레이트가 44.1kHz이면 편집 시 문제가 생기는 것 같습니다.
  • 사전 처리 과정에서 레이트를 48kHz로 변환하니 팝 현상이 해결되었습니다.
  • 왜 그런지는 전혀 모르겠습니다.
• 편집 초기에 영상을 내보내 최종 결과물을 확인해보세요.
• 비디오·오디오 편집 필터는 클립 단위가 아니라 트랙 단위로 적용하세요.
  • 거대한 클립 하나만 있더라도 편집을 시작하면 독립적인 필터 설정을 가진 수십 개의 클립이 생깁니다.
  • 필터 설정을 잘못했다는 것을 깨달으면 모든 클립에서 다시 작업해야 합니다.

인터뷰 전사본 작업에 푹 빠지다

Adam Gordon Bell과의 영상 편집을 마쳤으니 이제 끝이어야 할 것 같지 않나요? 영상 편집에 너무 많은 시간을 쏟았으니 분명 빨리 공개하고 마무리하고 싶었을 텐데요.

아니었습니다!

영상 편집이 끝나자 이번에는 전사본에 집착할 차례였습니다. 그런데 이 작업은 오히려 재미있었습니다.

온라인에서 보는 인터뷰 전사본들은 디자이너가 “60년 전 타자기로 친 법정 속기록의 재미와 상호작용성을 그대로 웹으로 가져와 보자”라고 말한 것 같습니다.

제발! 타자기에서는 할 수 없는 일을 웹에서 해봅시다.

그래서 whisper-ctranslate2로 초안을 생성한 뒤, 정확하고 상호작용적이며 읽기 재미있는 전사본을 만들기 위해 많은 시간을 들였습니다.

• 대화의 각 화자가 서로 다른 색상의 말풍선으로 표시되어 누가 말하는지 한눈에 알 수 있습니다.
• 각 말풍선에는 작은 재생 버튼 아이콘이 있습니다. 아이콘을 클릭하면 페이지가 영상으로 스크롤되면서 전사본의 해당 시점부터 재생됩니다.
• 제가 가장 좋아하는 인용구를 따로 뽑아 강조 상자로 만들었습니다.
• 대화의 구조를 잡아주는 소제목을 추가했습니다.
• 전사 오류가 있는지 텍스트를 검토했습니다.

아직 영상은 공개하지 않았습니다. 금요일에 메일링 리스트 구독자들에게 새 챕터를 막 발송했기 때문입니다. 이번 주 말(2025-09-12)까지는 책 블로그에 올라갈 예정입니다.

Tyler Cipriani의 해커 뉴스 1위 달성 돕기

때로는 계획이 기대했던 것보다 훨씬 더 잘 풀리기도 합니다.

실제 작가들에게 피드백을 주는 것이 책을 쓰는 데 도움이 되기에, 다른 인디 개발자 블로거들을 위해 프리랜서 편집 일을 해왔습니다. 편집 서비스를 소개하는 페이지에 제 편집 작업 샘플을 넣고 싶었지만, 이미 비용을 지불한 유료 고객에게 그 결과물을 제 마케팅에 사용하게 해달라고 부탁하고 싶지는 않았습니다.

그래서 제 계획은 제 편집 노트를 공개하고 저를 편집자로 명시해주는 조건으로, 제가 무료로 글을 편집하도록 허락해줄 사람을 찾는 것이었습니다.

추가 목표는 그 글이 제 책의 잠재 독자들이 모이는 Hacker News, Lobsters, reddit 같은 곳에서 주목받는 것이었습니다. 독자가 글 끝에 도달해서 “Edited by Refactoring English”라는 문구를 보면 “오, 이게 뭐지?”라고 생각하게 만들고 싶었습니다.

잠재 고객에게 “보세요, 이 분이 저를 고용했고 그분의 글이 여러분이 성공하고 싶은 곳에서 성공했습니다”라고 보여줄 수 있다면 신뢰도 측면에서도 좋습니다.

몇 달 전 Tyler Cipriani가 블로그에 대한 전반적인 리뷰를 의뢰했습니다. 결과에 만족하는 것 같아서 무료 편집 아이디어를 제안했고, 그는 흔쾌히 수락했습니다.

Tyler와 함께 그의 글 “The future of large files in Git is Git.”에 대해 몇 차례 피드백을 주고받았습니다. 함께 작업하는 과정이 즐거웠고, 책에 활용할 좋은 아이디어도 얻었습니다.

추가 목표는 그저 Hacker News 프론트 페이지에 오르는 것이었는데, 기대를 뛰어넘어 Hacker News는 물론 Lobsters, reddit 모두에서 1위를 차지했습니다.

저희 둘에게 가장 큰 교훈 중 하나는 글의 대상 독자에 맞춰 조정하는 것이 중요하다는 점이었습니다. Tyler 글의 초기 초안은 독자가 대용량 파일을 관리하는 Git 확장인 Git LFS를 잘 알고 있다고 가정하고 있었습니다.

저는 일반적인 Git 사용자라면 글의 모든 내용을 이해할 만큼 Git LFS를 잘 알지 못할 수도 있다고 제안했습니다. Tyler는 대용량 파일을 다뤄본 일반적인 Git 사용자라면 당연히 Git LFS를 알 것이라고 생각하며 반박했습니다.

독자가 글에서 가정한 것보다 Git LFS에 대해 훨씬 덜 알고 있다는 것을 Tyler에게 설득하기 위해, 제 Git LFS 지식과 경험을 나열했습니다.

• 내 git 저장소에 대용량 파일이 있거나 바이너리 데이터를 자주 업데이트한다면 git LFS를 써야 한다
• 나는 git LFS를 써본 적이 없다
  • Git LFS를 사용하는 오픈소스 프로젝트를 1~2개 정도 작업해본 적은 있지만, LFS 부분은 전혀 건드린 적이 없다.
• 다양한 포지(forge)의 용량 제한이 얼마인지 모르지만, 제한에 걸리면 포지에서 경고를 줄 것이고 그때 가서 처리하면 된다고 생각했다
  • git 저장소에 5MB가 넘는 파일을 저장하고 싶을 때는 피할 방법을 먼저 찾는다
• Git LFS는 어디서나 쓸 수 있는 포지에 구애받지 않는 기능이라고 생각했다.
• Git LFS는 10년 이상 된 기술로 성숙하고 안정적이라고 생각했다
• 한 번 Git LFS를 사용하기 시작하면 저장소가 거기에 묶인다는 것을 몰랐다
• git에 대용량 파일을 저장하는 방법에는 관심이 있고 HN/Lobsters에서 관련 글을 보면 클릭하겠지만, 정말로 대용량 파일을 git 저장소에 저장해야 하는 상황에 부딪히지 않는 한 미리 고민해서 해결하려는 문제는 아니다.

Tyler는 이 목록이 자신에게 ‘아하’ 하는 순간이었다고 말했습니다. 이전에는 독자들이 Git LFS를 알 것이라고 확신했기 때문에 피드백을 받아들이지 않았다고 합니다. 제 목록을 보고 나서야 독자들이 Git LFS가 무엇인지 피상적으로는 알아도, 그것이 어떻게 작동하는지는 모를 수도 있다는 것을 깨달았다고 합니다.

Tyler의 깨달음에서 멋진 점은 그가 제 목록을 스스로도 쓸 수 있었다는 것입니다. 그는 대상 독자가 무엇을 알지에 대해 저와 같은 예측을 하고 있었지만, 독자가 어떤 기술을 ‘안다’는 것이 무엇을 의미하는지 한 단계 더 깊이 생각해야 했던 것입니다.

사이드 프로젝트

Hacker News Observer를 시계열 데이터베이스로 전환해 500배 빨라지다

지난 몇 년간 “시계열 데이터베이스”라는 말을 들어왔지만, 그것이 정확히 무엇을 하는지, 일반 관계형 데이터베이스와 어떻게 다른지 이해하지 못했습니다. 작년에는 Grafana와 호환되는 것이 필요해서 사이드 프로젝트에 InfluxDB를 사용하기까지 했지만, 여전히 무엇이 그것을 “시계열” 데이터베이스로 만드는지, 왜 그냥 SQLite를 쓰면 안 되는지 알지 못했습니다.

최근 다른 개발자와 이야기하다가 그가 초 단위와 일 단위처럼 서로 다른 세분도로 데이터를 보기 위해 시계열 데이터베이스를 사용한다고 말하는 것을 들었습니다. 그 이상 자세히 설명하지도 않았는데 제 머릿속에서 전구가 켜지며 “아! 시계열 데이터베이스가 바로 그런 용도구나!”라는 생각이 들었습니다.

Hacker News Observer는 매 분마다 Hacker News를 조회해 최근 몇 주간의 모든 스토리의 추천 수, 댓글 수, 순위를 기록하는 사이드 프로젝트입니다. 더 깊이 파고들어 흥미로운 패턴을 찾고 싶지만, 지금은 프론트 페이지의 총 추천 수와 댓글 수 같은 고수준 집계만 보고 있습니다.

처음에는 데이터베이스로 SQLite를 사용했는데, 위 그래프를 렌더링하는 데 2분이 걸렸습니다. 하루에도 수천 개의 스토리가 있고 각 스토리마다 수천 개의 스냅샷이 있으며, 각 스냅샷에서 상위 30개(프론트 페이지)를 찾은 뒤 이를 시간 단위 버킷으로 묶어야 하니 당연한 결과였습니다. SQLite에는 분 단위 데이터를 시간 단위 뷰로 집계하는 특별한 함수가 없어 비용이 많이 드는 쿼리를 수행해야 했습니다.

시계열 데이터베이스에 대한 아이디어를 얻은 뒤, SQLite와 비슷한 시계열 데이터베이스 옵션을 LLM에 물어보니 DuckDB를 추천해주었습니다. 그리고 LLM에 SQLite에서 DuckDB로 데이터베이스를 마이그레이션하도록 시켰습니다. 그 마이그레이션만으로 그래프 로드 시간이 2분에서 250ms로 줄어들어 약 500배 빨라졌습니다.

그래서, 시계열 데이터베이스가 바로 이런 용도인 것 같습니다.

Gleam Chat Log Parser로 오래된 로그 조금씩 처리하기

채팅 로그 파서 프로젝트는 조금씩만 진전을 보았습니다. 자리 비움 메시지가 포함된 로그와 Windows 스타일 줄 바꿈(\r\n)이 있는 로그를 처리했습니다. 이상하게도 Erlang(따라서 Gleam에서도)에서는 \r\n이 하나의 문자로 취급되는데, 이 때문에 한동안 헤맸습니다.

마무리

무엇을 해냈나요?

• Refactoring English의 “Get to the Point” 챕터를 출간했습니다.
• “Give Your Spouse the Gift of a Couple’s Email Domain”을 게시했습니다
• 커맨드 라인에서 AirGradient 공기질 모니터를 플래싱하는 튜토리얼을 게시했습니다.
• “Reader Feedback about my Chapter List”를 게시했습니다
• 낮 동안 집중력을 지키기 위해 다시 LeechBlock NG를 사용하기 시작했습니다.
  • 이번에는 잘 작동하고 있습니다! 메모리 누수도 겪지 않고 있고, 업무 시간에 소셜 미디어로 새는 것을 막아주고 있습니다.

얻은 교훈

• 영상 편집에 더 체계적으로 임하기
• 인터뷰 영상 편집은 지루하지만, 전사본을 편집하고 스타일링하는 일은 재미있습니다.
• 30분이 걸리는 작업보다 몇 분이면 끝나는 작업에 대해 피드백을 주려는 고객이 열 배 더 많습니다.

다음 달 목표

• Refactoring English 웹사이트에 새로운 독자를 끌어들일 수 있는 콘텐츠를 게시하기.
• Refactoring English 새 챕터 출간하기.
• 한 번도 대화한 적 없는 독자 20명에게 개인화된 이메일 보내기.