Notes from Simon Willison's Interview on Software Misadventures

Michael Lynch

Software Misadventures 팟캐스트 사이먼 윌리슨 인터뷰 노트

원문은 Michael Lynch님이 에 게재했습니다. 이 블로그 구독하기

방금 Software Misadventures 팟캐스트에 출연한 사이먼 윌리슨의 인터뷰를 듣고 왔다. 인터뷰에서 배운 것이 많아 노트로 정리해 두었다.

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

Software Misadventures 팟캐스트에 출연한 사이먼 윌리슨

사이먼 윌리슨은 누구인가?

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

오픈소스 기여의 한 형태로서의 플러그인

원본 논의

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

플러그인의 가장 큰 장점은 내 코드를 리뷰하지 않고도 오픈소스 프로젝트에 기능을 추가할 수 있는 방법을 만든다는 겁니다. 아침에 일어나 보니 누군가 플러그인을 배포한 덕분에 내 소프트웨어가 새로운 기능을 하게 된 거죠.

[편집자 주: 흥미로운 관찰이라고 생각했다. 플러그인을 지원하도록 소프트웨어를 설계해 본 적은 없지만, 사이먼이 이런 아키텍처에 대해 아주 설득력 있는 주장을 펼친다.]

LLM

LLM을 활용하는 감각 익히기

원본 논의

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

사이먼이 LLM을 쓰는 방법

원본 논의

  • 정보 요약
    • 긴 컨텍스트 윈도우를 활용해 리서치를 가속한다. 예를 들어 한 인물을 조사할 때 그의 위키백과 문서, 관련 기사, 그가 쓴 글 등을 채팅에 몽땅 붙여 넣고 LLM에 핵심 주제를 예시와 함께 요약해 달라고 한다.
    • 직접 인용을 요청하고, 원본 소스를 확인해 LLM이 인용문을 환각한 것이 아닌지 검증한다.

      친구가 위키백과 페이지를 읽고 제 질문에 답할 수 있다면, LLM도 그 질문에 답할 수 있다는 걸 알 수 있죠. 하지만 위키백과 페이지에 있을 것 같지 않은 내용이라면, LLM이 답할 가능성도 낮아집니다.

  • 자신이 전문성이 있는 분야에 대해 질문하기

    이용 약관을 붙여 넣고 “여기 좀 수상한 부분 없어?”라고 물어보기도 해요.

    그게 형편없는 생각이라는 걸 저는 분명히 알아요. 법률 지식이 전혀 없으니까요. 그래서 그냥 흉내만 내면서 고개를 끄덕이는 거죠. 하지만 LLM이 준 법률 조언을 믿고 인생을 좌우할 결정을 내리지는 않을 거예요. 저는 변호사가 아니니까요.

    만약 제가 변호사였다면 LLM을 수시로 썼을 거예요. 책임감 있게 쓰고 있는지 제 전문 지식에 기대어 확인할 수 있을 테니까요.

  • SQL 쿼리 작성
    • 사이먼은 LLM에 전체 테이블 스키마와 샘플 행 몇 개를 보여주라고 조언한다.
  • 데이터 입력
    • 예: 손글씨 노트에서 정보를 옮겨 적거나 비정형 문서에서 구조화된 데이터를 추출하는 작업
    • 최상위 LLM은 약 95%의 정확도를 달성하는데, 이는 같은 작업을 사람 인턴 여러 명을 고용했을 때 얻을 수 있는 수준과 대략 비슷하다.
  • 소프트웨어 아키텍처 결정
    • 사이먼은 LLM에 같은 작업을 달성하는 여러 가지 옵션을 제시해 달라고 하고, 각각의 장단점에 대해 논의한다.
  • 학술 논문 읽기
    • 사이먼은 생소한 용어를 설명해 주는 Dejargonizer라는 도구를 만들었다.
    • [편집자 주: 재미있는 아이디어이긴 했지만 실용적인 도구라기보다는 장난에 가깝다고 느꼈다. 텍스트를 붙여 넣어야 하는데, 5쪽짜리 논문을 넣자마자 컨텍스트 한도에 걸렸다. 차라리 전문 용어 정의가 인라인으로 포함된 형태로 본문을 다시 써 주는 편이 더 낫겠다.]

사이먼의 “괴짜 인턴”이라는 LLM 멘탈 모델

원본 논의

  • 사이먼은 아내에게 LLM을 “괴짜 인턴”이라고 설명한다.

    모든 프로그래밍 언어의 문서를 통째로 외우고, 음모론을 마구 믿고, 가끔은 터무니없는 아이디어를 내며, 엄청나게 자신감이 넘치는 인턴을 옆에 두는 것과 같아요.

  • LLM이 사람 동료보다 나은 큰 장점 중 하나는 계속해서 솔루션을 개선해 달라고 요구할 수 있다는 점이다.
    • 사람 동료에게는 풀 리퀘스트를 개선할 새로운 아이디어를 계속 던지면 상대가 지치기 때문에 어느 순간 멈춰야 하지만, LLM에게는 상대의 시간을 존중하지 않는다는 걱정 없이 대대적인 재작성을 요청할 수 있다.
  • 사이먼은 LLM에 그저 “더 잘해 봐”라고 하면 답변이 개선된다는 것을 발견했다:

    제가 가장 좋아하는 프롬프트 중 하나는 그냥 “더 잘해 봐”라고 하는 건데, 그게 통한다는 겁니다. 정말 미친 일이죠!

    코드를 짜게 한 뒤에 “더 잘해 봐”라고 하면 “아 죄송합니다”라고 하더니 더 나은 코드를 내놓아요. 이 기술이 그런 식으로 작동한다는 게 너무 어이없지만, 또 그래서 재미있기도 해요.

LLM이 이전에는 effort 대비 가치가 없던 프로젝트를 가능하게 하다

원본 논의

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

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

LLM 동향 따라잡기

원본 논의

  • 가장 시그널이 높은 정보는 15명 남짓한 규모의 비공개 WhatsApp 및 Discord 그룹에서 나온다.
  • 트위터에는 괜찮은 AI 논의가 있다.
    • 반면 Mastodon에는 AI 회의론자들이 많아서 그렇지 않다.
  • 사이먼의 블로그 덕분에 사람들이 흥미로운 새로운 LLM 동향에 대한 제보를 자주 보내온다.

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

원본 논의

  • LLM의 단점은 작성자조차 이해하지 못하는 코드가 프로덕션에 투입된다는 것이다.
    • 이는 세계 전체로 보면 위험 요소이며, LLM이 전반적인 소프트웨어 품질을 떨어뜨릴 것임을 시사한다.
  • 사이먼은 세상이 이미 LLM이 생성하는 이른바 “죽 같은(goop)” 코드보다 더 엉망인 코드 위에서 돌아가고 있다고 지적한다:

    우리는 지금 세상의 절반이 단위 테스트도, 백업도, 버전 관리도 없는 엑셀 스프레드시트 위에서 돌아가는 세상에 살고 있어요. 누구나 수식을 하나 잘못 건드리면 회사 가치가 하룻밤 사이에 절반으로 떨어질 수 있는 그런 세상이죠…

    지금 우리가 사는 세상이 바로 그런 거예요. 엑셀 스프레드시트는 이미 일종의 죽 같은 존재이고, 그럼에도 사회는 굴러가요.

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

블로깅

매일 새로운 블로그 글 쓰기

원본 논의

  • 사이먼은 매일 새로운 블로그 글을 쓰려고 노력한다.

시간 투자

원본 논의

  • 사이먼은 하루에 10~15분 정도 블로깅을 한다.
  • 22년 동안 해 온 덕분에 더 빠르게 쓸 수 있게 됐다.

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

원본 논의

  • 사이먼은 지난 뉴스레터 이후 블로그에 새로 올라온 모든 내용을 diff 형태로 담은 뉴스레터를 운영한다:

    이메일 클라이언트에서 사는 사람들에게 소식을 전하는 정말 좋은 방법이에요.

  • 사이먼은 블로그 콘텐츠를 가져와 Substack 호환 리치 텍스트로 변환하는 Observable 노트북을 직접 만들었다. 그 노트북에서 복사해 Substack에 붙여 넣고 뉴스레터를 발송한다.
  • 구독자는 6,000명이다.
  • 뉴스레터 한 번 보내는 데 2분이 걸린다.

[편집자 주: 사이먼은 언급하지 않았지만, 이런 식으로 Substack에 신디케이트하는 것은 SEO에 부정적이라고 생각한다. 같은 콘텐츠가 서로 다른 URL에 두 벌로 존재하게 되어 Google이 어느 쪽이 원본인지 알 수 없기 때문이다.]

[편집자 주: 사이먼이 simonwillison.net의 서브도메인이 아니라 Substack 도메인을 쓰는 것도 의외였다. Substack은 자신의 도메인을 연결할 수 있게 해 주기 때문이다.]

블로그 인프라

원본 논의

  • 사이먼의 메인 블로그는 Cloudflare를 CDN으로 앞단에 둔 Heroku 인스턴스에서 돌아간다.

Cloudflare의 가장 큰 장점은 트래픽이 폭증해도, 예를 들어 Hacker News 메인에 링크가 걸려도, 저렴한 Heroku 인스턴스는 타격을 전혀 받지 않는다는 겁니다. Cloudflare가 모든 트래픽을 흡수하니까요.

Bing Chat 사건

원본 논의

모든 것을 GitHub 이슈로 만들기

원본 논의

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

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

  • 디자인 문서도 이슈로 작성한다.

    댓글 100개가 넘는 이슈 스레드가 있는데, 전부 저 혼자 쓴 거예요. 그냥 저 혼자 떠들고 있는 거죠.

[편집자 주: 쓰기에는 최적화됐지만 읽기에는 그렇지 않은 놀라운 워크플로다. 이슈를 이해하려면 현재 상태를 요약한 하나의 댓글을 읽는 대신 수백 개의 댓글을 읽어야 하기 때문이다.]

“시간적(Temporal)” 문서 vs. 현재 문서

원본 논의

  • 사이먼은 소프트웨어 문서를 두 가지 유형으로 본다.
    1. 소프트웨어가 현재 무엇을 하는지 설명하는 문서.
    2. 문서가 작성된 시점에 소프트웨어가 무엇을 했는지 설명하지만 오늘날에는 더 이상 정확하지 않을 수도 있는 문서(“시간적 문서”)
  • GitHub 이슈는 시간적 문서에 적합하다.
    • 이슈를 작성한 날짜를 보고 그 문서가 언제 정확했는지 파악할 수 있다.
  • 코드와 일치해야 하는 문서의 경우, 코드와 같은 저장소에 마크다운 파일로 보관하고 코드 업데이트 시 문서도 항상 함께 업데이트되도록 한다.

인디 개발자로서의 삶

원본 논의

  • 사이먼은 스탠퍼드에서 데이터 저널리즘 분야로 1년간 유급 펠로우십을 받았을 때 독립적인 일에 처음 맛을 들였다.

    정말 놀라운 경험이었고, 완전히 망쳐 놨어요. 가장 흥미롭다고 생각하는 일에 1년을 쓸 수 있도록 돈을 준 거니까요.

    그런 경험을 한 번 하고 나면, 다른 사람이 내가 무엇을 할지 정해 주는 일로 돌아가기가 아주 어렵습니다. 그래서 기본적으로 문제는 제가 1년간 자유를 경험했고, “이걸 포기하고 싶지 않아. 이런 것들을 작업하는 게 너무 재미있어”라고 생각하게 된 거죠.

시간 관리

원본 논의

  • 사이먼은 무엇을 할지 결정하는 것이 극도로 어렵다고 느낀다. 고용주를 위해 일할 때에 비해 외부의 압박이나 책임이 거의 없기 때문이다.
    • 탐구할 만한 AI 분야는 너무나 많고, 그것을 탐색하는 것을 막을 것이 아무것도 없다.
  • 그래서 때로는 VC 투자자가 있어서 목표에 집중하도록 잡아주면 좋겠다고 생각하기도 한다.
  • 컨퍼런스 주도 개발
    • 사이먼은 컨퍼런스 일정에 맞춰 기능을 약속하고, 이를 마감 시한으로 삼아 구현에 우선순위를 둔다.
  • Weeknotes

경제적 자립을 향해

원본 논의

  • 사이먼은 경제적 자립을 꿈꾼다.
    • 사이먼이 창업한 스타트업은 아직 성장 중일 때 Eventbrite에 인수됐고, 이후 6년간 엔지니어링 디렉터로 근무했다.
    • 상당한 기간 버틸 자금(runway)은 있지만, 수입을 걱정하지 않아도 될 정도는 아니다.
    • Datasette가 주 수입원이 될 만큼 충분한 수익을 낼 때까지 버틸 수 있도록 컨설팅 기회를 모색하고 있다.

[편집자 주: 인터뷰 전체에서 가장 놀라웠던 점은 사이먼이 아직 경제적으로 자립하지 못했다는 사실이었다. 나는 그가 이미 자립했을 거라고 생각했기 때문이다.]

Datasette의 목표

원본 논의

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

데이터 저널리즘에서 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가 사이먼의 말을 완전히 바꿔 놓았지만, 대부분은 인용문을 정확하게 옮겼다.

링크

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

댓글