Blog Dice

Notes from Simon Willison's Interview on Software Misadventures

Michael Lynch

Software Misadventures에 출연한 Simon Willison 인터뷰 노트

Software Misadventures 팟캐스트에 출연한 Simon Willison 인터뷰를 방금 다 들었습니다. 인터뷰에서 많은 것을 배워 노트로 정리해 보았습니다.

이 글은 인터뷰 전체를 요약한 것이 아니라, 저에게 새로웠거나 기억해 두고 싶은 부분만 추려 정리한 것입니다.

Software Misadventures 팟캐스트에 출연한 Simon Willison

Simon Willison은 누구인가?

  • Python에서 가장 인기 있는 웹 프레임워크인 Django의 공동 개발자 중 한 명입니다.
  • Hacker News에서 가장 인기 있는 독립 블로거 중 한 명입니다.
  • 지난 몇 년간 블로그를 주로 AI, 특히 일상적인 소프트웨어 개발에서 AI 기술을 활용하는 방법에 집중해 운영하고 있습니다.
  • 현재 Datasette라는 오픈소스 데이터 분석 툴을 개발하고 있습니다.

오픈소스 기여 방식으로서의 플러그인

원문 논의

  • 애플리케이션이 기능을 확장하는 플러그인을 받을 수 있도록 설계하는 것은 오픈소스 기여를 받는 것보다도 마찰이 더 적은 협업 방식입니다.
    • 외부 기여자가 여러분의 검토나 승인 없이도 기능을 추가할 수 있으며, 여러분이 그 코드를 유지보수할 책임도 지지 않아도 됩니다.

플러그인의 가장 큰 장점은 다른 사람의 코드를 검토하지 않고도 기능이 추가되는 방식으로 오픈소스 프로젝트를 만들 수 있다는 점입니다. 어느 날 아침에 일어나 보니 누군가 플러그인을 새로 출시해서 내 소프트웨어가 새로운 기능을 하게 된 거죠.

[편집자 주: 흥미로운 관점이라고 생각했습니다. 저는 플러그인을 받는 소프트웨어를 설계해 본 적이 없지만, Simon은 이런 아키텍처에 대해 매우 설득력 있게 이야기합니다.]

LLM

LLM 활용 감각 기르기

원문 논의

  • LLM은 한계가 명확히 드러나지 않기 때문에 실제보다 다루기 어려워 보이지 않습니다.
    • 단순한 챗봇처럼 보여 쉬워 보이지만, 할 수 있는 일과 할 수 없는 일에 대한 감을 잡으려면 다양한 작업에 몇 시간씩 직접 써 봐야 합니다.
    • 예: LLM은 숫자 세기를 잘 못하는데, 컴퓨터가 원래 숫자 세기를 잘한다는 점을 생각하면 의외입니다.
  • Simon은 LLM 활용 능력을 키우는 효과적인 방법으로 Anthropic의 프롬프트 엔지니어링 문서를 추천합니다.
  • Simon은 직접 호스팅할 수 있는 모델(예: Phi-3, LLama 3.1)로 학습해 볼 것을 권합니다. 이런 모델들은 환각을 일으키고 실수를 더 자주 해서 LLM이 무엇에 약한지 더 잘 감을 잡을 수 있기 때문입니다.

Simon은 LLM을 어떻게 활용하는가

원문 논의

  • 정보 요약
    • 긴 컨텍스트 윈도우를 활용해 리서치를 가속합니다. 예를 들어 한 인물에 대해 조사할 때 위키백과 페이지, 관련 기사, 그 사람의 글 등을 채팅창에 모두 넣고 LLM에 예시와 함께 핵심 주제를 요약해 달라고 요청합니다.
    • 직접 인용을 요청하고, 원본 소스를 확인해 LLM이 인용을 지어내지 않았는지 검증합니다.

      제 친구가 위키백과 페이지 하나를 읽고 제 질문에 답할 수 있다면, LLM도 그 질문에 답할 수 있다는 걸 압니다. 하지만 위키백과 페이지에 나오지 않을 법한 내용이라면 LLM도 답할 가능성이 낮죠.

  • 자신이 전문성을 갖춘 분야에 대해 질문하기

    법률 관련 질문도 합니다. 예를 들어 이용 약관을 붙여 넣고 “여기 좀 수상해 보이는 부분 있어?”라고 묻죠.

    이게 정말 나쁜 생각이라는 걸 저는 잘 압니다. 법률 지식이 전혀 없으니까요. 그래서 그냥 따라 하는 흉내를 내며 고개를 끄덕이는 셈이지만, LLM에게 받은 법률 조언을 바탕으로 인생을 좌우할 결정을 내리지는 않을 겁니다. 저는 변호사가 아니니까요.

    제가 변호사라면 LLM을 항상 쓸 겁니다. 제 전문 지식에 기대어 책임감 있게 활용하고 있는지 확인할 수 있을 테니까요.

  • SQL 쿼리 작성
    • Simon은 전체 테이블 스키마와 몇 개의 샘플 행을 LLM에 보여줄 것을 조언합니다.
  • 데이터 입력
    • 예: 손글씨 노트에서 정보를 옮겨 적거나 비정형 문서에서 정형 데이터를 추출하는 작업
    • 최고 성능의 LLM도 정확도가 약 95% 수준으로, 사람 인턴 여러 명을 고용해 같은 작업을 맡겼을 때와 대략 비슷한 수준입니다.
  • 소프트웨어 아키텍처 결정
    • Simon은 같은 작업을 달성하기 위한 다양한 옵션을 LLM에 요청하고, 각각의 장단점을 함께 따져봅니다.
  • 학술 논문 읽기
    • Simon은 낯선 용어를 설명해 주는 Dejargonizer라는 툴을 만들었습니다.
    • [편집자 주: 이 툴은 실용적인 도구라기보다는 재미있는 아이디어에 가깝다고 느꼈습니다. 텍스트를 붙여 넣어야 하는데, 5쪽짜리 논문을 넣으니 컨텍스트 한도를 금방 초과했습니다. 전문 용어를 인라인으로 정의해 텍스트를 다시 쓰는 방식이 더 합리적일 것 같습니다.]

Simon의 “이상한 인턴” LLM 멘탈 모델

원문 논의

  • Simon은 아내에게 LLM을 “자신의 이상한 인턴”이라고 설명합니다.

    모든 프로그래밍 언어의 문서를 외우고 있는 데다 황당한 음모론자여서 가끔 터무니없는 아이디어를 내놓고… 엄청나게 자신감이 넘치는 인턴을 옆에 둔 것과 같아요.

  • 사람 팀원보다 LLM이 갖는 큰 장점 중 하나는 계속해서 해결책을 개선해 달라고 요구할 수 있다는 점입니다.
    • 사람 팀원에게는 계속 새로운 아이디어를 내며 풀 리퀘스트 개선을 요구하면 상대가 지치기 때문에 어느 순간 멈춰야 하지만, LLM에게는 시간을 뺏는다는 부담 없이 대대적인 재작성을 요청할 수 있습니다.
  • Simon은 그냥 “더 잘해 봐”라고 말하는 것만으로도 LLM이 답변을 개선하게 할 수 있다는 것을 발견했습니다.

    제가 가장 좋아하는 프롬프트 중 하나는 그냥 “더 잘해 봐”라고 말하는 건데, 실제로 효과가 있어요. 정말 황당하죠!

    코드를 하나 작성하고 “더 잘해 봐”라고 하면 “아, 죄송합니다”라고 하더니 더 나은 코드를 뚝딱 내놓습니다. 이런 식으로 기술이 동작한다는 게 어이없을 정도로 멍청하지만, 한편으로는 재미있기도 해요.

LLM이 실현 가능하게 만든 프로젝트들

원문 논의

  • LLM이 Simon에게 미친 가장 큰 영향 중 하나는 개발자로서 더 야심차게 도전하게 만들었다는 점입니다.
    • 이전에는 프로젝트 아이디어가 떠올라도 구현에 적합한 언어가 AppleScript나 Go라는 걸 알면, 그 언어를 모르니 아이디어를 접어 두곤 했습니다.
    • 이제 LLM을 이용해 코드를 생성하고 원하는 대로 동작하는지 검증할 수 있습니다.
  • 예전에도 그 기술들을 배울 수는 있었지만, LLM이 진입 장벽을 충분히 낮춰 이제는 실제로 만들어 보는 것이 더 현실적이 됐습니다.

    이 작은 프로젝트들은 LLM 없이는 존재하지 않았을 겁니다. 만들 능력이 없어서가 아니라, 들인 노력을 정당화할 만큼 충분히 빠르게 만들 수 없었기 때문이죠.

LLM 동향 따라잡기

원문 논의

  • 가장 밀도 높은 정보는 15명 안팎의 비공개 WhatsApp 및 Discord 그룹에서 나옵니다.
  • 트위터에는 AI에 대한 좋은 논의가 많습니다.
    • Mastodon은 AI 회의론자들이 많이 모여 있어 그렇지 않습니다.
  • Simon의 블로그 덕분에 사람들은 흥미로운 새로운 LLM 동향에 대한 제보를 자주 보내옵니다.

LLM이 세상을 형편없는 코드로 오염시키지 않을지도 모르는 이유

원문 논의

  • LLM의 단점은 작성자조차 이해하지 못하는 코드가 프로덕션에 투입되고 있다는 점입니다.
    • 이는 LLM이 전반적인 소프트웨어 품질을 떨어뜨릴 수 있다는 점에서 전 세계적인 리스크입니다.
  • Simon은 세상의 많은 부분이 LLM이 생성하는 “죽 같은(goop)” 코드보다도 더 엉망인 코드로 돌아가고 있다는 점을 지적합니다.

    우리는 지금 세상의 절반이 단위 테스트도 없고 백업도, 버전 관리도 없는 엑셀 스프레드시트로 돌아가는 세상에 살고 있습니다. 누구든 수식 하나를 잘못 건드리면 하룻밤 사이에 기업 가치가 반 토막 날 수 있죠…

    그게 우리가 오늘날 사는 세상이잖아요? 엑셀 스프레드시트 자체가 이미 일종의 죽 같은 상태인데도 어떻게든 사회는 돌아갑니다.

    그러니 “아니, 모든 코드 한 줄이 완벽해야 해”라고 말하는 우리 같은 사람들이 어쩌면 틀렸을지도 모릅니다. 어쩌면 죽 같은 상태가 앞으로 나아갈 길일지도 모르죠. 하지만 생각하면 조금 무섭습니다.

블로깅

매일 새로운 블로그 글 쓰기

원문 논의

  • Simon은 매일 새로운 블로그 글을 쓰려고 노력합니다.
    • 10년간 매주 영상을 올린 Tom Scott에게서 영감을 받았습니다.
    • 덕분에 매일 흥미로운 무언가를 찾으려는 동기가 생깁니다.

시간 투자

원문 논의

  • Simon은 하루에 10~15분 정도 블로그에 투자합니다.
  • 22년 동안 해 온 덕분에 더 빠르게 쓸 수 있게 됐습니다.

블로그에서 뉴스레터로 이어지는 파이프라인

원문 논의

  • Simon은 지난 뉴스레터 이후 블로그에 새로 올라온 모든 내용의 차이(diff) 그 자체인 뉴스레터를 운영합니다.

    이메일 클라이언트에서 생활하는 사람들에게 콘텐츠를 전달하는 정말 좋은 방법입니다.

  • Simon은 블로그에서 콘텐츠를 가져와 Substack 호환 리치 텍스트로 변환하는 Observable 노트북을 만들었습니다. 그런 다음 노트북에서 Substack으로 복사해 뉴스레터를 발송합니다.
  • Substack 구독자는 6,000명입니다.
  • 뉴스레터 한 번 보내는 데 2분이 걸립니다.

[편집자 주: Simon이 Substack으로 신디케이션하는 방식은 SEO에 부정적이라고 생각합니다. 동일한 콘텐츠가 서로 다른 URL에 두 개 생기면 구글이 어느 쪽이 원본인지 알 수 없기 때문입니다.]

[편집자 주: Substack에서 자체 도메인을 사용할 수 있는데도 Simon이 simonwillison.net의 서브도메인이 아닌 Substack 도메인을 그대로 쓰는 점도 의외였습니다.]

블로그 인프라

원문 논의

  • Simon의 메인 블로그는 CDN인 Cloudflare 뒤에 있는 Heroku 인스턴스에서 운영됩니다.

Cloudflare의 가장 큰 장점은 트래픽이 급증해도 — 예를 들어 Hacker News 홈페이지에 링크될 때 — Cloudflare가 모든 트래픽을 흡수해 주기 때문에 저렴하고 작은 Heroku 인스턴스는 영향을 전혀 받지 않는다는 점입니다.

Bing 챗 사건

원문 논의

모든 것을 GitHub 이슈로 만들기

원문 논의

  • Simon은 개인 할 일 목록을 GitHub 이슈로 관리합니다.
  • 그는 250개의 프로젝트를 유지합니다.
    • 모든 세부사항을 잊어버릴 것이라고 가정하고 문서화합니다.

      1년 동안 손대지 않은 프로젝트에 다시 들어가도, 그 프로젝트가 무엇인지 모르는 사람처럼 문서를 읽고 바로 작업을 시작할 수 있습니다.

  • 설계 문서도 이슈로 작성합니다.

    댓글이 100개가 넘는 이슈 스레드도 있는데, 전부 저 혼자 쓴 겁니다. 그냥 혼자 이야기하고 있는 거죠.

[편집자 주: 이슈를 이해하려면 수백 개의 댓글을 읽어야 하므로 읽기보다 쓰기에 최적화된, 놀라운 워크플로입니다. 현재 상태를 요약한 단일 댓글 하나를 읽는 대신 말이죠.]

“시간적” 문서 vs. 현재 문서

원문 논의

  • Simon은 소프트웨어 문서를 두 가지 유형으로 나눕니다.
    1. 소프트웨어가 현재 무엇을 하는지 설명하는 문서.
    2. 문서가 작성된 시점에 소프트웨어가 무엇을 했는지를 설명하지만 오늘날에는 정확하지 않을 수도 있는 문서(“시간적 문서”)
  • GitHub 이슈는 시간적 문서를 남기기에 좋습니다.
    • Simon은 이슈를 보고 작성일을 확인해 해당 문서가 언제 정확했는지 파악할 수 있습니다.
  • 코드와 반드시 일치해야 하는 문서는 코드와 같은 레포지토리에 마크다운 파일로 보관하고, 코드가 업데이트될 때마다 문서도 함께 업데이트되도록 합니다.

인디 개발자로서의 삶

원문 논의

  • Simon은 스탠퍼드에서 데이터 저널리즘 분야로 1년간 유급 펠로십을 받으면서 독립적인 일을 처음 맛보았습니다.

    정말 놀라운 경험이었고, 완전히 제 인생을 망쳐 놓았습니다. 가장 흥미롭다고 생각하는 일에 1년을 쓰라고 돈을 줬으니까요.

    한 번 그런 경험을 하고 나면 다시 누군가가… 내가 무엇을 할지 정해 주는 상황으로 돌아가기가 정말 어렵습니다. 그러니까 문제는 제가 1년간 자유를 경험했고, “이걸 포기하고 싶지 않다. 이런 일들을 하며 너무 즐겁다”고 생각하게 됐다는 거죠.

시간 관리

원문 논의

  • Simon은 고용주를 위해 일할 때에 비해 외부의 압박이나 책임이 거의 없기 때문에 무엇을 할지 결정하는 것이 극도로 어렵다고 느낍니다.
    • AI에는 탐구할 흥미로운 분야가 너무 많고, 그것을 영원히 파고드는 것을 막을 것이 아무것도 없습니다.
  • 그래서 가끔은 VC 투자자가 있었으면 해서 누군가 자신을 목표에 집중하도록 잡아 주길 바라기도 합니다.
  • 컨퍼런스 주도 개발
    • Simon은 컨퍼런스 일정에 맞춰 기능을 약속해 두고, 이를 통해 마감 시한까지 구현을 우선순위화하도록 강제합니다.
  • 위크노트

경제적 자립을 향해

원문 논의

  • Simon은 경제적 자립을 꿈꿉니다.
    • 그의 스타트업이 한창 성장하던 중 Eventbrite에 인수되었고, 이후 그는 그곳에서 6년간 엔지니어링 디렉터로 일했습니다.
    • 그는 “상당한 런웨이”를 확보하고 있지만, 수입을 걱정하지 않아도 될 정도는 아닙니다.
    • Datasette가 주 수입원이 될 만큼 충분한 수익을 낼 때까지 컨설팅 기회를 통해 수입을 확보하려 하고 있습니다.

[편집자 주: 인터뷰 전체에서 가장 놀라웠던 점은 Simon이 이미 경제적 자립을 달성했을 거라고 생각했는데 그렇지 않았다는 사실입니다.]

Datasette의 목표

원문 논의

  • Datasette에 대한 Simon의 목표는 한 기자가 Datasette를 활용해 퓰리처상을 받는 기사를 쓰는 것입니다.
  • 혼자 일하는 것이 외롭기 때문에 함께 일할 팀을 꾸리고 싶어 합니다.
  • 코드를 오픈소스로 공개하고 이를 매니지드 서비스로 제공해 수익을 내는 워드프레스 모델을 따르고 싶어 합니다.

데이터 저널리즘에서 LLM 활용의 어려움

원문 논의

  • 모든 주요 LLM이 정보를 검열하기 때문에 데이터 저널리즘이 더 어려워집니다.

기자라면 다루는 원천 자료 중에는 끔찍한 것들도 있잖아요? 폭력 사건에 대한 경찰 보고서라든가, 파시스트 메시지 보드 같은 것들이요… 지금 LLM에게 이런 것들을 처리하도록 도와달라고 하고, 이 파시스트 게시판의 주제를 요약해 달라고 하면 “안 된다”고 하잖아요?

많은 LLM이 아예 처리를 거부해 버립니다. 그래서… 활용도가 크게 제한되죠…

메타: 이 노트를 만든 방법

yt-dlp로 인터뷰를 다운로드했습니다:

yt-dlp https://www.youtube.com/watch?v=6U_Zk_PZ6Kg

그리고 Whisper로 트랜스크립트를 생성했습니다:

VIDEO_FILE="~/LLMs\ are\ weird,\ over-confident\ intern\ ｜\ Simon\ Willison\ (Datasette)\ \[6U_Zk_PZ6Kg].webm"
whisper $VIDEO_FILE

제 NixOS 시스템의 CUDA 설정이 알 수 없이 작동을 멈춰서 Whisper가 CPU를 사용했는데, 속도가 느리고 오류가 많았습니다. 이를 정리하기 위해 Google Gemini 2.5 Pro Preview를 사용했습니다:

Split this transcript into sections by topic.

Under each topic, write the timestamp that the section covers in the transcript.

Break groups of sentences into logical paragraphs under each heading.

Fix words that appear to be transcription errors, but don't editorialize or
change language.

```
1
00:00:00,000 --> 00:00:06,000
call it my weird intern. I'll say to my wife Natalie sometimes, hey so I got my weird intern

2
00:00:06,000 --> 00:00:10,800
to do this. And that works, right? It's a good mental model for these things as well because

[elided...]

```

Gemini는 한 번에 약 30분 분량의 트랜스크립트까지만 처리하고 출력 토큰이 바닥나기 때문에, 지시문 끝에 Start at 00:26:26,240이라는 문구를 덧붙여 계속 반복해야 했습니다.

그런 다음 서식이 정리된 트랜스크립트를 모두 합쳤습니다.

그러면 이렇게 잘 정리된 트랜스크립트가 만들어집니다:

### The Efficiency and Benefits of Consistent Blogging
(00:08:44,480 --> 00:11:24,800)

Well, that's the secret of blogging, is that it takes a lot of work at first,
but I've been blogging for 22 years...

그 다음 Gemini 2.5 Pro에 제 노트를 아래 프롬프트와 함께 입력했습니다:

Here is a transcript of an interview that's available on YouTube
at https://www.youtube.com/watch?v=6U_Zk_PZ6Kg:

```
SRT TRANSCRIPT GOES HERE
```

Here are  my notes about the interview:

```
MARKDOWN VERSION OF THIS BLOG POST GOES HERE
```

Reproduce the headers in my notes, but under each, include a link to the
original YouTube video that the transcript came from with a timestamped link
that points to that part of the conversation.

직접 인용한 부분들이 모두 정확한지 검증하고 싶었지만, 좋은 방법을 찾지 못했습니다. 처음에는 Gemini Pro와 Flash에 ffmpeg 명령어를 생성해 인용된 부분만 남기도록 영상을 편집해 달라고 했지만 계속 잘못 생성했습니다. 조금 더 간단하게 모든 인용에 타임스탬프가 있는 YouTube 링크를 덧붙여 달라고 해 보았지만, 항상 몇 분씩 어긋났습니다. 결국 SRT 파일을 검색한 뒤 영상의 해당 지점을 찾아 직접 수작업으로 했습니다. 한 사례에서는 Gemini가 Simon의 표현을 완전히 바꿔 버렸지만, 대체로 인용은 정확했습니다.

링크

원문은 Michael Lynch님이 에 게재했습니다.

이 글은 muse-spark-1.2-contributor 모델을 사용해 번역했습니다.