[번역] 하루에 600개의 커밋을 머지하는 개발자, 피터 슈타인버거

Peter Steinberger

[00:00] 만약 하루에 600개의 커밋을 머지(merge)할 수 있는데, 그중 단 하나도 엉터리(slopp) 코드가 아니라면 어떨까요?

[00:02] 이것이 바로 오늘 게스트이자 'Claudebot(클로드봇)'의 창시자인 피터 슈타인버거(Peter Steinberger)가 주장하는 바입니다.

[00:05] 피터는 10억 대 이상의 기기에서 사용되는 PDF 프레임워크인 'PSPDFKit'을 만든 뛰어난 개발자입니다.

[00:10] 그 후 그는 번아웃을 겪고 지분을 매각한 뒤, 3년 동안 기술 업계에서 사라졌습니다.

[00:16] 올해 그가 돌아왔는데, 현재 그가 무언가를 만들고 작업하는 방식은 전통적인 소프트웨어 개발과는 전혀 다른 모습입니다.

[00:22] 오늘 에피소드에서는 그가 왜 자신이 배포하는 코드의 대부분을 더 이상 직접 읽지 않는지, 그리고 그것이 왜 들리는 것만큼 미친 짓이 아닌지에 대해 다룹니다.

[00:29] 또한 Siri의 미래처럼 느껴지는 그의 엄청난 개인 비서 프로젝트인 'Claudebot'을 어떻게 만들고 있는지, 효과적인 AI 비서 코딩과 답답한 '바이브 코딩(vibe coding)'을 구분 짓는 '루프 닫기(closing the loop)' 원칙에 대해 이야기합니다.

[00:39] 왜 그가 코드 리뷰는 죽었다고 말하며 PR(Pull Request)을 '프롬프트 요청(Prompt Request)'이라고 불러야 한다고 주장하는지 등 많은 이야기를 나눕니다.

[00:47] AI 덕분에 앞으로 몇 년 안에 소프트웨어 엔지니어의 워크플로우가 어떻게 바뀔지 관심이 있다면, 이 에피소드는 당신을 위한 것입니다.

[00:51] 이 에피소드는 플래그(flags), 분석, 실험 등을 위한 통합 플랫폼인 Statsig가 제공합니다. 쇼노트를 확인하여 Statsig에 대해 더 알아보고, 제가 그들과 함께 2월 11일 샌프란시스코에서 주최하는 프래그머틱 서밋(Pragmatic Summit)과 다른 시즌 스폰서들에 대해서도 확인해 보세요.

[01:04] 사회자: 자, 피트, 팟캐스트에 오신 걸 환영합니다.

[01:07] Peter: 초대해 주셔서 감사합니다, 게(Gergely).

[01:08] 사회자: 직접 만나서 정말 반가워요.

[01:11] Peter: 네, 하마터면 망칠 뻔했죠.

[01:14] 사회자: 네, 무슨 일이 있었나요? 시간 가는 줄 모르셨던 건가요? 자주 있는 일인가요? 어쩌다가요?

[01:18] Peter: 음, 보통은 아니에요. 보통은 안 그런데. 지금 제 최신 프로젝트가 폭발적으로 성장하고 있어서 저에게 아주 흥미로운 시기거든요. 클로드(Claude) 말이죠?

[01:29] 사회자: 클로드봇(Claudebot)이요. 네.

[01:30] Peter: 클로드봇이요. 잠을 충분히 못 자고 있긴 하지만 재밌어요. 커뮤니티가 이렇게 빨리 폭발적으로 성장하는 건 처음 겪어보는데, 함께 작업하는 게 정말 믿을 수 없을 만큼 즐겁습니다.

[01:39] 사회자: 클로드봇과 지금 하고 계신 재미있는 작업들로 넘어가기 전에, 아주 예전으로 되감기를 해보죠. 피터 님은 10억 명 이상의 사용자가 쓰는 기기에서 사용되는 PSPDFKit을 만드셨어요. PDF 렌더러를 본다면 아마 그걸 보고 계신 걸 겁니다. 하지만 그보다 훨씬 전에, 어떻게 기술 업계에 들어오게 되셨나요? 맙소사, 어떻게 기술을 시작하게 되셨죠?

[02:01] Peter: 저는 오스트리아 시골 출신이에요. 항상 내향적인 편이었죠. 저희 집에는 항상 여름 손님들이 왔는데, 그중 한 명이 컴퓨터 괴짜(nerd)였어요. 그가 가진 기계에 푹 빠져서 엄마에게 사달라고 졸랐죠.

[02:22] 그때부터 계속 뚝딱거리며 무언가를 만들었어요. 가장 초기에 했던 기억은 학교에서 오래된 DOS 게임을 훔쳐서 플로피 디스크 복사 방지 프로그램을 만든 다음 그걸 팔았던 거예요. 로딩하는 데 2분이나 걸렸죠.

[02:40] 저는 항상 무언가를 만들었어요. 물론 컴퓨터 게임도 많이 했지만, 무언가를 만드는 것 자체가 컴퓨터 게임을 하는 것처럼 느껴졌어요. 확실히 지금은 '팩토리오(Factorio)' 게임보다 개발이 더 재밌어요.

[02:54] 처음 시작할 때는 윈도우용 배시 스크립트 같은 걸 읽었고, 웹사이트도 만들었어요. 자바스크립트도 조금 했지만 뭘 하는 건지 전혀 몰랐죠. 제가 실제로 무언가를 만드는 법을 배워야 했던 첫 언어는 대학을 시작할 때였어요.

[03:16] 저는 아버지를 뵌 적이 없고 가난한 가정 출신이라 항상 일을 해야 했어요. 학비를 직접 벌어야 했죠. 남들이 방학을 즐길 때 저는 회사에서 풀타임으로 일했어요.

[03:32] 비엔나에서 첫 제대로 된 직장을 잡았는데, 원래 1개월 예정이었던 게 6개월로 늘어났어요. 군대와 대학 사이의 기간이었죠. 거기서 한 5년 정도 계속 일했어요.

[03:45] 첫 출근 날 그들이 저에게 이만한 두께의 책을 줬던 게 기억나요. '마이크로소프트 MFC'라고 적혀 있었죠. 아직도 악몽을 꿔요. 저는 "이건 끔찍하다"라고 생각해서, 다음 윈도우 프로젝트 때는 그냥 말 안 하고 조용히 .NET을 썼어요. 몇 달 뒤에야 "아, 현대화를 좀 했어요"라고 말했는데 되돌리기엔 너무 늦었죠. 이 회사에서 그런 짓을 몇 번 했는데, 제 결과물이 작동했기 때문에 저를 안 자르고 데리고 있었던 것 같아요.

[04:18] .NET 2.0에는 제네릭(generics)이 있었는데 저는 꽤 좋아했어요. 애플리케이션 시작할 때 모든 걸 컴파일하느라 시간이 엄청 오래 걸리긴 했지만요. 당시 하드디스크 속도를 기억하신다면 아시겠지만요.

[04:33] 사회자: 그렇다면 어떻게 iOS를 접하게 되셨고, PSPDFKit 아이디어는 어디서 나온 건가요?

[04:40] Peter: 처음엔 오스트리아에 아이폰이 출시되지도 않았어요. 시간이 좀 지나 대학생 때 친구가 아이폰을 보여줬는데, 한 1분 만져보고는 바로 샀어요. 만지자마자 느낌이 딱 왔거든요(clicked). 저에게는 정말 "이거 미쳤다(Holy f***)" 싶은 순간이었어요. 너무 다르고 훨씬 좋았거든요.

[05:09] 그래서 하나 샀는데, 그때는 앱을 만들 생각은 없었어요. 2009년이나 2010년쯤이었죠.

[05:18] 그때 제가 게이 데이팅 앱을 쓰고 있었는데(당시 iPhone OS 2 시절), 지하철을 타고 가다가 긴 메시지를 썼어요. 전송 버튼을 눌렀는데 마침 터널로 들어가는 바람에 자바스크립트가 전송 버튼을 비활성화해 버렸고 에러 메시지가 떴어요.

[05:38] 근데 복사 붙여넣기도 없고 스크린샷도 안 됐어요. 스크롤도 안 돼서 그 감정적이었던 긴 메시지가 그냥 날아가 버린 거예요. 정말 화가 났어요. "대체 이게 뭐야?" 하면서 집에 가서 Xcode를 다운로드했죠.

[05:59] "IDE는 어디 있지?" 하면서 시작했어요. 도저히 받아들일 수 없었거든요. 기본적으로 그 웹사이트를 해킹했어요. 정규 표현식(Regular expressions)을 써서 HTML을 파싱 했는데, 절대 하면 안 되는 짓이죠.

[06:17] 그렇게 앱을 만들었어요. iPhone OS 3 베타와 Core Data 베타, RegexKitLite를 썼고, iPhone OS 3에서 블록(Blocks)을 쓰기 위해 GCC 해킹 버전까지 썼어요. 제가 뭘 하는지 몰랐고 온갖 베타 기술을 써서 작동하기까지 꽤 오래 걸렸어요.

[06:38] 겨우 작동하게 만들어서 그 회사에 메일을 보냈어요. "내가 앱을 만들었는데 어떻게 생각하세요?" 당연히 답장이 없었죠. 그래서 "그냥 앱스토어에 올리자" 했어요.

[06:48] 사회자: 그 데이팅 앱을 위해서 만든 거죠? 그냥 API를 보고 클라이언트를 만드신 건가요?

[06:53] Peter: API가 아니라 HTML이었어요. 문자 그대로 HTML을 파싱 했죠.

[06:59] 사회자: 아, HTML을 파싱 해서 API처럼 쓰신 거군요. 영리하네요. 당시엔 아무도 이런 일이 일어날 거라 생각 못 했을 때니까요.

[07:08] Peter: 앱스토어에 올리고 5달러를 받았는데 첫 달에 1만 달러(약 1,300만 원)를 벌었어요. 전 뭘 하는지도 몰랐는데 말이죠. 은행 계좌도 할아버지 걸 적어냈어요. 어느 날 할아버지가 전화하셔서 "애플에서 큰돈이 들어왔는데 좀 이상하다"라고 하셨죠. 전 "제 거예요! 건드리지 마세요!"라고 했고요.

[07:36] 재밌는 건, 앱이 대박이 나서 클럽에 갔는데 누군가 제 앱을 쓰는 걸 봤어요. 너무 자랑스러워서 어깨를 두드리고 "이거 제가 만들었어요"라고 하고 싶었지만 이상할 것 같아서 안 했어요.

[07:50] 5년 동안 다닌 회사에 가서 이 일을 본격적으로 하겠다고 말했더니 상사가 비웃었어요. "실수하는 거야. 이건 유행일 뿐이고 오래 못 갈 거야"라며 조롱했죠. 그게 저에게 오기(chip on your shoulder)를 심어줬어요. "언젠가 당신네 회사보다 더 가치 있는 회사를 만들 거야"라고 다짐했죠. 8년 걸렸지만요.

[08:20] 저는 중독되기 쉬운 성격이라 이 앱에 엄청나게 몰두했어요. 트위터도 시작했는데 제 경력에 큰 영향을 줬죠. 앱을 꽤 괜찮게 만들었는데, 어느 날 새벽 3시에 파티에서 술이 좀 취해 있는데 미국 번호로 전화가 왔어요.

[08:50] "애플의 존입니다. 당신 앱에 문제가 있어요. 사람들이 사진을 신고해서..." 그리고 그게 끝이었어요. 앱이 내려갔죠. 좋았던 시절은 끝났고, 저는 직장도 그만둔 상태였어요. "애플 엿 먹어라(F*** you Apple)"라고 생각했죠.

[09:14] 그 후 프리랜서 일을 했어요. WWDC(애플 개발자 컨퍼런스)에 갔는데, 새벽 2시 샌프란시스코의 한 바에서 누군가 저를 "오스트리아 최고의 iOS 개발자 중 한 명"이라고 소개해 줬어요. 덕분에 미국에서 일자리를 얻게 됐죠.

[09:32] 노키아 개발자의 날 행사였나? 어떤 사람이 와서 "동유럽 어디서 앱을 만들었는데 작동은 하는데 가끔 죽어요"라고 하더군요. 아이패드가 막 나왔을 때라 모두가 잡지 앱(Magazine apps)을 만들던 시절이었어요.

[09:57] 단기 아르바이트로 괜찮겠다 싶어서 앱을 열어봤는데, 살면서 본 최악의 코드였어요. 파일 하나에 수천 줄의 Objective-C 코드가 들어 있었죠.

[10:21] 그들은 윈도우(Window)를 탭(Tab)으로 사용하고 있었어요. 이게 작동한다는 게 놀라울 정도로 모래성 같았죠. 수술하듯 고쳐보려 했지만 건드릴 때마다 다른 게 망가졌어요.

[10:36] 어느 정도 안정화시킨 뒤에 "이건 미친 짓이에요. 제가 다시 짜 드릴게요. 한 달이면 됩니다"라고 했죠. 결국 두 달 걸렸지만요.

[10:48] 그때 PDF 뷰어를 작업하게 됐어요. 어떤 기술적 문제든 흥미로운 부분을 찾을 수 있잖아요? 당시엔 30MB짜리 PDF를 렌더링 하는 C 호출이 있는데 시스템 메모리는 64MB밖에 안 되는 상황이라, 아주 영리하게 처리하지 않으면 OS가 앱을 죽여버렸어요.

[11:22] 저는 디테일에 집착해서 페이지 회전 애니메이션 같은 것에 너무 많은 시간을 썼어요. 그래서 한 달이 아니라 두 달이 걸린 거죠. 하지만 결과물은 좋았어요.

[11:35] 그 후 친구가 연락 와서 "잡지 앱을 만들고 있는데 너무 어렵다"라고 하길래, "어려울 리가 없어, 내가 해봤는데"라고 했죠.

[11:43] 사회자: 방금 하나 만드셨으니까요.

[11:44] Peter: 친구가 코드를 좀 줄 수 있냐고 해서, 잡지 앱에서 PDF 부분만 추출해서 팔았어요. 원청 회사의 허락도 받았고요. 그러다 "친구가 관심 있으면 다른 사람한테도 팔 수 있지 않을까?" 싶었죠.

[12:07] 워드프레스 템플릿을 난도질해서 깃허브 페이지(GitHub Pages)에서 돌아가게 만들었어요. 결제가 끝나면 제 개인 드롭박스 링크로 소스코드 압축파일을 보내주는 방식이었죠.

[12:20] 오후에 트윗을 올렸는데 그 주에 3명이 샀어요. 200달러 정도였는데 저한텐 엄청났죠. 구매자보다 불만 메일이 더 많이 왔어요. "이거 사고 싶은데 텍스트 선택 기능이 없네요" 같은 거요.

[12:43] 저는 흥미로운 문제에 낚여서(nerd sniped) "텍스트 선택? 얼마나 어렵겠어?" 했는데 3개월 걸렸어요. PDF에서 텍스트 선택은 정말 어렵거든요.

[12:54] 사회자: "젊은 사람들이 회사를 만드는 이유는 그게 얼마나 어려운지 몰라서다"라는 말이 있죠.

[12:59] Peter: 맞아요. PDF 파일 포맷이 얼마나 미친 짓인지 전혀 몰랐어요.

[13:04] 사회자 (내레이션): 피터는 어떤 문제들은 겉보기에만 쉬워 보인다고 말했습니다. PDF 렌더링이 좋은 예죠. "얼마나 어렵겠어?" 하다가 존재조차 몰랐던 엣지 케이스(edge cases) 때문에 몇 달을 보내게 됩니다.

[13:16] 이런 "직접 만들기 전까진 쉬워 보이는" 패턴은 다른 곳에도 나타납니다. 기능 플래그(Feature flags)나 실험을 위한 내부 도구가 전형적인 예죠. 팀들은 이런 도구를 위한 인프라 구축에 얼마나 많은 공수가 드는지 과소평가하곤 합니다.

[13:28] 우버 같은 거대 기술 기업들이 내부 실험 및 기능 플래그 시스템 구축에 수년을 투자한 데는 이유가 있습니다. 이것이 바로 이번 시즌의 파트너 Statsig를 소개하는 이유입니다. Statsig는 여러분이 직접 만들 필요 없이 완벽한 툴킷을 제공합니다.

[13:41] 기능 플래그, 실험, 제품 분석을 하나의 플랫폼에서 모두 제공하며, 동일한 사용자 할당 및 데이터를 기반으로 합니다. 실제로는 이런 식입니다. 먼저 1%의 사용자에게 변경 사항을 배포합니다. 전환율, 유지율 등 중요한 지표가 어떻게 변하는지 확인합니다. 문제가 생기면 즉시 롤백하고, 효과가 있다면 자신 있게 확장할 수 있죠. 노션(Notion), 마이크로소프트, 아틀라시안 등이 속도와 안정성을 위해 Statsig를 사용합니다. 무료 티어도 있고 프로 요금제는 월 150달러부터 시작합니다. statsig.com/pragmatic에서 ↗ 확인해 보세요.

[14:33] 사회자: 다시 피터의 이야기로 돌아가 보죠. PDF 렌더링이 왜 그렇게 놀랍도록 어려운 문제였을까요?

[14:39] Peter: 몇 주 전에 누군가 PDF 관련 도움을 요청하는 메일을 보냈는데, 제가 답장으로 "죄송합니다만 전 제 몫을 다했습니다. 전 건전한 인간이 알아야 할 것보다 더 많이 PDF에 대해 알고 있어요. 치료도 받았고요. 행운을 빕니다"라고 했어요.

[14:56] 아무튼 비자를 기다리는 동안 프로젝트를 계속했는데 점점 더 많은 사람이 구매했어요. 호수에서 쉬고 있는데 600달러, 800달러 결제 알림이 왔죠. 기능을 추가하면서 가격을 올렸거든요. 샌프란시스코 회사에 출근할 때쯤엔 이미 월급보다 더 많이 벌고 있었어요. 하지만 여전히 "거기에 있어야 한다"고 생각했죠.

[15:36] 사회자: 샌프란시스코로 이사하셨군요.

[15:37] Peter: 네. 스타트업은 하루 8시간만 일하는 곳이 아니잖아요? 제 개인 프로젝트도 시간이 많이 들었고요. 잠을 줄였죠. 결국 3개월 뒤에 매니저가 오더니 "피터 괜찮아?" 하면서 선택권을 줬어요. 회사에 남고 프로젝트를 포기하든가, 아니면 그 반대든가. 일주일 시간을 줬는데, 비자 문제 때문에 일주일 안에 결정하지 않으면 출국해야 했어요.

[16:16] 결정은 쉬웠어요. 제 일을 하고 싶었으니까요.

[16:21] 사회자: 이미 사업성이 보였고 미국 직장만큼 벌 수 있다는 걸 아셨으니까요.

[16:31] Peter: 돈 때문만은 아니었어요. 저는 사람들이 놀라워할 만한 걸 만들고 싶었어요. 디테일을 다듬는 걸 좋아하거든요. 경쟁자들은 기능이 훨씬 많고 오래되었지만, 제 제품이 더 성공했어요. 저는 애플이 만들었다면 그랬을 것처럼, 사랑과 정성, 그리고 업계 사람들이 잘 모르는 '작은 즐거움(little delights)'을 담아 만들었거든요.

[17:19] 소프트웨어는 기능 세트보다 '느낌'이 훨씬 중요하다고 생각해요. 우리가 왜 애플 제품을 사나요? 윈도우보다 기능이 많아서가 아니라 느낌이 더 좋아서잖아요.

[17:31] 사회자: 회사를 나와서 PDF 컴포넌트를 팔기 시작했는데, 언제 첫 직원을 채용하셨나요?

[17:44] Peter: 비엔나로 돌아가서 올인하기로 했어요. 프리랜서들과 조금씩 일하기 시작했죠. 사실 너무 늦게 채용했어요. 큰 결정이니까요. 그렇게 13년 동안 이 이상한 이름의 제품을 만들었어요. 이름 짓는 데 5분도 안 걸렸던 'PSPDFKit' 말이죠.

[18:13] 사회자: PSPDFKit. 발음하기 힘들지만 아주 독특하네요.

[18:22] Peter: Objective-C를 안다면 이해할 거예요. 그냥 네임스페이스(Namespace)니까요. 제 마케팅 전략은 오직 개발자만 신경 쓰는 거였어요. 경영진이 결정한다는 건 알지만, 회사 내부 개발자들을 설득하면 그들이 저 대신 마케팅과 로비를 해주거든요. 그게 정말 잘 통했어요. 콜드 메일 같은 공격적인 영업은 한 번도 안 했어요. 전부 인바운드였죠. 좋은 제품을 만들고 통찰력 있는 기술 블로그를 쓰는 것, 그게 다였어요.

[19:15] 사회자: 기술 스택은 어땠나요? Objective-C? 나중엔 Swift?

[19:23] Peter: 결국 모든 플랫폼으로 확장했어요. 큰 변화는 렌더러를 C++ 기반의 자체 렌더러로 교체한 것이었죠. 웹(Web) 진출도 빨랐는데, 웹어셈블리(WebAssembly)로 구동되는 최초의 PDF 프레임워크 중 하나였어요.

[19:44] 아주 영리했던 건, 벤치마크를 만들었는데 그게 구글, 마이크로소프트, 애플에서 사용하는 벤치마크가 됐다는 거예요. 그 회사들이 제 렌더러를 더 빠르게 만들기 위해 열심히 일하게 만든 셈이죠.

[20:06] 사회자: 회사가 커지면서 2019년에 팀이 일하는 방식에 대한 블로그를 쓰셨죠. 모든 기능은 제안서로 시작하고, API 변경에 보수적이며, 보이스카우트 규칙(Boy Scout Rule) 같은 것들이요. 30~60명 규모가 되었을 때 문화를 어떻게 만드셨나요?

[20:42] Peter: 지분을 팔 때 70명이었고 지금은 거의 200명이에요. 비엔나에서 필요한 사람을 다 찾을 수 없다는 걸 알았기에 처음부터 리모트 퍼스트(Remote-first)였어요. 저는 CEO가 되고 싶은 욕망이 없었어요. 항상 코딩을 했죠. 비즈니스 쪽은 할 수 있고 꽤 잘한다고 생각하지만 즐기진 않아요. 특히 엔터프라이즈 영업에서 "이 회사는 얼마를 낼까?" 주사위 굴리듯 가격 정하는 거요. 끔찍하지만 엔터프라이즈는 그렇게 돌아가요.

[21:28] 사회자 (내레이션): 피터가 엔터프라이즈 영업의 최악인 점에 대해 말했는데요, 대기업에 판매하는 건 가격 책정뿐만 아니라 구축해야 할 엔터프라이즈 기능들 때문에 까다롭습니다. 여기서 이번 시즌 스폰서 WorkOS가 등장합니다.

[21:42] AI 에이전트나 자동화 도구를 만들 때, 에이전트가 어떤 작업을 할 수 있는지 제어해야 합니다. 기존 OAuth는 이를 위해 설계되지 않았죠. 그래서 WorkOS는 MCP Auth를 도입했습니다. 이를 통해 팀은 명시적인 권한, 감사 기능(auditability), 엔터프라이즈급 보안으로 AI 에이전트를 인증할 수 있습니다.

[22:05] 과도한 범위의 API 키를 공유하는 대신, 에이전트가 접근할 수 있는 데이터와 수행할 수 있는 작업의 경계를 명확히 정의할 수 있습니다. 보안을 타협하지 않으면서 빠르게 AI 기능을 배포하고 싶다면 workos.com/mcp를 ↗ 확인해 보세요.

[22:23] Peter: 하지만 그런 모델에서는 커스텀 가격 정책(custom pricing)만이 유일하게 작동하는 방식이에요.

[22:31] 사회자: 개발자들이 벤더 사이트에 갔을 때 가격이 없고 "문의하기"라고만 되어 있으면 좌절하잖아요. 왜 그런 거죠?

[22:42] Peter: 왜냐하면 당신 회사를 보고 지불할 의사가 있을 법한 숫자를 생각해야 하니까요. 끔찍하게 들리겠지만, 프리랜서와 포춘 500대 기업에게 똑같은 가격을 받을 순 없잖아요. 사용량도 다르고 얻는 가치도 다르니까요. 가격을 너무 낮추면 대기업 구매 부서(procurement)는 "500달러? 이상하네" 하고 절차를 시작도 안 해요. 너무 높으면 작은 고객을 잃고요. 불공평해 보이지만 가장 공정한 방식이기도 해요.

[23:35] 소프트웨어에는 네 가지 축이 있어요. 쉽거나 어렵거나, 흥미롭거나 재미없거나. 우리는 "재미없고 어려운" 영역에 있었어요. 모든 개발자가 만들고 싶어 하는 걸 만들면 팔기 힘들어요. 하지만 "아, 진짜 하기 싫고 너무 어렵다" 싶은 거라면 좋은 위치죠. 저는 무한한 복잡한 문제들이 있는 흥미로운 틈새시장을 찾은 거예요.

[24:12] 사회자: PDF 파싱에서 어려운 점 한두 가지만 말씀해 주세요. 명세서(specification)도 있는데 뭐가 그렇게 어렵나요?

[24:23] Peter: PDF에는 링크가 있잖아요? 목차를 누르면 37페이지로 가는 식으로요. 저는 "많아야 100개나 400개쯤 있겠지"라고 가정하고 모델을 만들었어요.

[24:36] 그런데 돈을 아주 많이 낸 고객이 "PDF 로딩에 4분이나 걸린다"라고 불평하는 거예요. 확인해 보니 캐나다에서 온 5만 페이지짜리 성경 텍스트였는데, 페이지당 링크가 100개가 넘어서 총 50만 개의 링크가 있었어요.

[24:52] 제 데이터 모델은 완전히 폭발했죠. 가정이 1000배나 빗나갔으니까요. 이미 API가 있는 성숙한 제품인데, 사람들을 위해 기능을 깨뜨리지 않으면서 어떻게 내부를 완전히 재설계할까요? 갑자기 모든 걸 지연 로딩(lazy loading) 해야 했어요.

[25:22] 내부를 완전히 재설계하면서 기존 사용자들에게는 여전히 쉽게 작동하도록 만드는 데 두 달을 썼어요. 저는 고객 지원(support)을 좋아해요. CEO가 직접 답장해서 문제를 해결해 주면 임팩트가 크거든요. 5분 안에 답장을 받으면 마법 같지만, 이틀 뒤에 받으면 별 감흥 없잖아요. 결국 두 달간 작업해서 4분 걸리던 걸 거의 즉시 로딩되게 만들었어요.

[26:15] 사회자: 정말 만족스러웠겠네요.

[26:19] Peter: 아주 만족스러웠죠.

[26:22] 사회자: 직접 코드를 많이 작성하셨나요?

[26:26] Peter: 훌륭한 팀이 있었지만, 모바일 분야 등 제 마음이 가는 곳엔 더 깊게 관여했어요. 블로그를 통해 흥미롭고 어려운 문제를 어떻게 해결했는지 공유하면, 그런 문제를 풀고 싶어 하는 흥미로운 사람들을 채용하는 데 도움이 돼요.

[27:00] 사회자: PSPDFKit 블로그는 정말 흥미로웠어요. 단순히 홍보용이 아니라 엔지니어링적으로 읽을거리였죠.

[27:41] Peter: 저는 공유하고 영감을 주는 걸 좋아해요. 가끔은 "이건 영업 비밀(secret sauce)인데 써도 되나?" 하는 갈등도 있었지만, 별로 신경 안 썼어요. 가르치려면 제대로 이해해야 하잖아요. 저에게도 공부가 됐죠.

[28:44] 직원들에게 한 달에 하루는 온종일 블로그만 쓰게 강제했어요.

[29:08] 회사가 커지면서 관료주의(red tape)가 생기고, 거친 해킹보다는 정원 가꾸기(gardening) 같은 작업이 많아졌어요. 반복적이고 덜 흥미로워졌죠. 사람 문제도 많아졌고요. CEO는 결국 다른 사람들이 처리 못 하거나 망친 일을 해결해야 하는 '쓰레기통(waste bin)' 같은 존재가 되더라고요. 너무 외로웠고, 심하게 번아웃이 왔습니다. 주말도 없이 일했으니까요.

요청하신 팟캐스트 대본의 번역본입니다. 앞부분에 이어지는 내용이며, Markdown 형식으로 정리했습니다.

[29:55] Peter: 다른 사람들이 관리하지 않거나, 할 수 없거나, 혹은 망쳐놓은 일들을 CEO인 제가 고쳐야만 하죠.

[30:00] 그리고 꽤 외로운 자리예요. 많은 것들을 터놓고 이야기할 수 없으니까요. 회사를 꽤 개방적인 구조로 만들었지만, 여전히 부정적인 태도를 보일 수는 없어요. 심지어 정말 안 좋은 일이 생겨도요.

[30:18] 한번은 새벽 5시에 공동 창업자가 전화를 걸어왔어요. "지금 큰 항공사 하나가 비행기를 못 띄우고 있는데, 우리 소프트웨어가 충돌해서 그렇대."라고 하더군요. 아주 흥미진진한 주말이었죠. 제가 그들의 앱을 디스어셈블(disassemble, 역분석)해서 그들이 라이선스 키 폴백(fallback)을 트리거하려고 우리 소스코드를 엉망으로 건드렸다는 걸 증명하기 전까지는요. 결국 그게 문제의 원인이었죠.

[30:46] 하지만 그건 정말 "SaaS(Software as a Service) 회사가 망할 수도 있겠다" 싶은 순간이었어요. 이런 일이 다른 스트레스 위에 계속 쌓이는 거죠. 한동안은 버틸 수 있어요. 그리고 저는 번아웃이 단순히 일을 너무 많이 해서 온다고 생각하지 않아요. 제 경우엔 더 이상 믿음이 가지 않는 일을 하거나, 갈등이 너무 많을 때 찾아왔어요.

[31:12] 당시 경영진 팀 내에서도 다툼이 많았어요. 그때 저는 회사를 좀 더 민주적으로 운영해야 한다는 실수를 범했거든요. 그런 것들이 저를 번아웃되게 만들었죠. 그래도 한동안은 그 시절이 그립진 않을 것 같아요.

[31:27] 사회자: 그렇군요. 밖에서 보기에는 지분을 매각했고, 원한다면 평생 일하지 않아도 될 만큼 충분한 돈을 벌었잖아요. 사업을 시작하려거나 꿈꾸는 많은 사람에게 이건 절대적인 꿈처럼 들릴 거예요. 현실적으로 대부분은 실패한다는 걸 알지만, 어쨌든 해내셨잖아요. 체크박스에 체크한 셈이죠. 암벽 등반을 해서 정상의 종을 울린 것과 같아요.

[31:54] 그런데 당신의 블로그를 보면 몇 년 동안 포스팅이 완전히 멈췄더군요. 그동안 무엇을 하셨나요? 그리고 지금으로 돌아오기 전까지 그 시간 동안 무엇을 배우셨나요?

[32:09] Peter: 압박감을 풀 시간(decompress)이 많이 필요했어요. 놓쳤다고 생각했던 것들을 많이 따라잡았죠. 게임도 많이 했고요. 몇 달 동안은 컴퓨터를 켜지도 않았어요.

[32:23] 한동안은 "이제 뭘 해야 하지?"라는 느낌조차 없었어요. 확실히 "굳이 왜 해야 해(Why bother)?"라는 상태였죠. 너무 일찍 은퇴하거나 다시는 일할 필요가 없을 만큼 좋은 엑시트(Exit)를 하는 건 예정에 없던 일이니까요. 그게 제 마음을 꽤 복잡하게 만들었어요. 힘든 몇 년이었죠.

[32:47] 그러다 4월쯤, 예전에 생각했던 아이디어가 떠올랐어요. 예전에 시작했던 사이드 프로젝트였는데 "아, 이걸 계속해보고 싶다"는 생각이 들었죠. 그래서 3년 만에 다시 컴퓨터 앞에 앉아 해킹(코딩)을 시작했어요.

[33:05] 트위터 분석 도구였는데 Swift와 SwiftUI로 작성되어 있었어요. 그때 이미 이걸 웹사이트로 만들었으면 훨씬 좋았을 거라는 걸 알고 있었죠.

[33:20] 사회자: 마음 한구석에 계속 담아두었던 기존 아이디어였군요?

[33:26] Peter: 네, 그냥 제가 필요해서 만들고 싶었어요. 그런 게 없었으니까요. 3년이 지났는데도 여전히 없더라고요. 그래서 웹 기술로 다시 만들고 싶었는데, 웹은 회사 다닐 때도 제가 가장 덜 들여다본 분야였어요. 마틴(Martin)이라는 아주 똑똑한 친구가 그쪽을 맡고 있어서 저는 신경 쓸 필요가 없었거든요.

[33:57] 사회자: React 같은 건 직접 안 만지셨군요.

[33:59] Peter: 네. 돌아와서 보니 "Props가 뭐지?" 하는 수준이었어요. 이게 많은 개발자가 빠지는 함정인데, 한 가지 기술에 능숙해질수록 다른 곳으로 넘어가기가 더 힘들어요. 못하는 게 아니라 고통스럽거든요.

[34:19] 애플(Apple) 스택에서는 눈 감고도 코딩할 수 있는데, 이쪽 스택에서는 아주 사소한 것도 구글링해야 하니까요. 다시 바보가 된 기분이 들죠.

[34:33] 사회자: 경력이 많을수록 그런 기분은 더 별로죠. 받아들이라고 말은 하지만 효율적이지 않고 더 빨리할 수 있다는 걸 아니까요.

[34:45] Peter: 그래서 돌아왔을 때 "도대체 이 AI라는 게 뭐길래?" 싶었어요. 사람들이 무시하는 이 AI가 뭔지 한번 보자고 했죠. 4월쯤이었는데, 많은 사람이 회의적이었고 그럴 만도 했어요. 저는 제가 컴퓨터를 켜지 않았던 그 3년의 공백기를 오히려 다행으로 생각해요. 그동안 여러분은 AI를 확인해 보고 "이거 쓰레기네"라고 학습했잖아요.

[35:13] 사회자: 맞아요. 깃허브 코파일럿(GitHub Copilot) 베타, 그러니까 GPT-3 기반의 '영광스러운 자동완성' 시절을 놓치셨군요. 그다음 GPT-3.5로 큰 도약이 있었고, GPT-4로 점진적으로 좋아졌죠. 당신이 돌아왔을 때 처음 쓴 도구는 뭐였나요?

[35:43] Peter: 클로드(Claude)였어요. 5월에 나왔던 것 같은데 베타는 그전부터 있었죠.

[35:54] 사회자: 그러니까 공백기 후에 돌아와서 바로 클로드를 켰고, 그 이전의 것들은 다 건너뛴 거네요.

[36:03] Peter: 네. 제가 만들던 크고 엉망인 사이드 프로젝트가 있었는데, 깃허브 리포지토리를 하나의 거대한 마크다운 파일로 변환해 주는 브라우저 확장 프로그램을 썼어요. 1.3MB짜리 마크다운 파일이 나왔죠.

[36:21] 그걸 구글 AI 스튜디오(Google's AI Studio)의 제미나이(Gemini) 1.5인가 2.0에 드래그해서 넣고 "스펙(Spec)을 써줘"라고 했더니 400줄짜리 스펙을 만들어줬어요.

[36:32] 그걸 다시 클로드(Claude)에 넣고 "빌드해"라고 했죠. 계속(Continue) 버튼을 누르면서 저는 다른 일을 했어요. 마침내 "100% 프로덕션 준비 완료"라고 하길래 실행했는데, 충돌하더군요(crashed).

[36:51] 사회자 (내레이션): AI가 "배포 준비 완료"라고 해서 실행했더니 충돌했다는 이야기, 우리 모두 공감할 겁니다. 재밌고 순수한 이야기지만, 저는 개인적으로 검증 없이 AI가 생성한 코드를 믿지 않습니다.

[37:03] 이것이 바로 이번 시즌 스폰서 Sonar를 소개하는 이유입니다. 데이터를 좀 볼까요? Sonar의 새로운 보고서인 '코드 현황 개발자 설문조사'에 따르면, 개발자의 82%가 AI로 더 빠르게 코딩할 수 있다고 믿습니다. 하지만 흥미로운 점은 같은 설문조사에서 96%의 개발자가 AI 코드의 정확성을 크게 신뢰하지 않는다고 답했다는 겁니다.

[37:21] 저도 마찬가지입니다. AI 에이전트로 코드를 더 빨리 작성하긴 하지만, 그 결과물을 전적으로 신뢰하진 않죠. 이건 코드 리뷰 단계에서 진짜 문제가 됩니다. AI가 생성한 모든 코드를 보안, 안정성, 유지보수성 측면에서 정기적으로 검증해야 하니까요.

[37:36] SonarQube는 바로 이 코드 검증 문제를 해결하기 위해 만들어졌습니다. Sonar는 17년 넘게 자동화된 코드 분석 시장의 리더였으며, 매일 7,500억 줄의 코드를 분석합니다. 초당 800만 줄이 넘죠. 저는 2013년 마이크로소프트 스카이프(Skype) 팀에서 일할 때 Sonar를 처음 접했고, 그때부터 팬이었습니다.

[37:59] Sonar는 필수적이고 독립적인 검증 계층을 제공합니다. 개발자가 짰든 AI가 짰든 모든 코드를 분석하여 배포 전에 품질과 보안 기준을 충족하는지 확인하는 자동화된 가드레일이죠. sonarsource.com/pragmatic에서 ↗ 무료로 시작해 보세요.

[38:18] 사회자: 다시 피터의 이야기로 돌아가서, AI 에이전트를 전적으로 신뢰할 수 없다는 이야기부터 들어보죠.

[38:21] Peter: 그러고 나서 MCP(Model Context Protocol)를 추가해서 브라우저를 쓸 수 있게 했어요. 몇 시간 더 돌렸더니 트위터 로그인 페이지가 나왔고, 뭔가 작동을 하더군요. 훌륭하진 않았지만 작동은 했어요. 저에게는 이게 "맙소사(Holy s***)" 하는 충격적인 순간이었어요.

[38:42] 사회자: 그게 올해 4월이나 5월쯤이었죠?

[38:45] Peter: 네. 잠재력을 볼 수 있을 만큼 충분히 좋았어요. "아, 이게 이렇게 가는구나"라고 이해했죠. 그 순간부터 몇 달 동안 잠을 제대로 못 잤어요.

[39:01] 사회자: 기억나요. 제가 한번 트위터 DM을 보냈는데, 새벽 5시였는데 답장이 바로 왔죠. "왜 깨어 있어요?" 했더니 "이게 일상이에요. 클로드(Claude)를 쓰는데 정말 중독적이라서요"라고 했잖아요. "농담이 아니라 진짜 좋아요"라고 하면서 "프롬프트 하나만 더(just one more prompt)"라고 했던 게 기억나요. 무엇이 그렇게 중독적이었나요?

[39:40] Peter: 카지노에 가는 것과 경제학이 똑같아요. 저만의 작은 슬롯머신이죠. 레버를 당기면 딩딩딩 하다가 꽝이 나오기도 하고, 어떨 때는 정말 놀라운 결과물을 내놓기도 해요.

[40:00] 사회자: 경험 많은 개발자로서 "놀랍다"고 하시는 거잖아요? 당신을 놀라게 하는 건 쉽지 않은 일인데 말이죠. 좋은 코드와 나쁜 코드를 구별하는 기준이 높으시니까요.

[40:15] Peter: 재밌는 건, 제가 회사 다닐 때 모든 디테일, 띄어쓰기, 줄 바꿈, 네이밍 하나하나에 집착했어요. '자전거 보관소 색칠하기(bike-shedding, 사소한 것에 대한 논쟁)'에 엄청난 시간을 썼죠. 돌이켜보면 "대체 왜 그랬지?" 싶어요. 고객은 내부를 보지 않잖아요. 물론 작동해야 하고, 빠르고, 안전해야 하지만, 그 사소한 집착은 바보 같았어요.

[40:47] 사회자: 그렇게 말씀하시지만, 아까 사람들은 PSPDFKit이 가장 세련되고 잘 작동해서 좋아했다고 하셨잖아요. 그런 집착과 관리가 기술 부채를 막고 좋은 위생 상태(hygiene)를 유지해서 고성능을 낼 수 있었던 것 아닐까요?

[41:25] Peter: 어느 정도는 맞아요. 하지만 최근 블로그에 썼듯이 저는 이제 코드를 읽지 않고 배포해요.

[41:37] 사회자: 그 얘기 꼭 해야죠.

[41:40] Peter: 동시에 저는 구조를 재조정하는 데는 엄청난 시간을 써요. 오늘도 15,000줄짜리 변경 사항을 담은 PR(Pull Request)을 처리하고 싶었는데, 플러그인 아키텍처로 옮기는 작업이라 아주 신이 났죠. 제가 그 코드를 다 읽었을까요? 아니요. 대부분의 코드는 지루한 배관(plumbing) 작업일 뿐이거든요.

[42:07] 대부분의 앱이 뭐죠? API에서 데이터를 가져와서 파싱하고, 다른 형태로 포장해서 데이터베이스에 넣고, 다시 꺼내서 HTML로 보여주는 거죠. 우리는 앱 전체에서 데이터를 이리저리 마사지하고 있을 뿐이에요. 정말 어려운 부분은 30년 전 포스트그레스(Postgres)를 만든 괴짜들이 이미 다 해결해 놨어요.

[42:43] 버튼 정렬이나 테일윈드(Tailwind) 클래스 같은 건 신경 안 써요. 지루한 디테일이죠. 저는 한 줄 한 줄 읽는 것보다 시스템 아키텍처가 훨씬 중요하다고 생각해요.

[43:00] 사회자: 현재 워크플로우는 어떤가요? 클로드봇(Claudebot)을 만들 때 어떤 도구를 쓰시나요? 코드를 리뷰하진 않지만 아키텍처는 고민한다고 하셨는데, 개발자에게 설명한다면 하루 일과가 어떤 모습인가요?

[43:26] Peter: 4월에 클로드(Claude)로 시작해서 푹 빠졌고, 커서(Cursor)도 썼고, 제미나이도 썼고, 오퍼스(Opus) 4도 썼어요. 친구들도 많이 끌어들였죠. 비엔나에 있는 친구들도 제가 하도 헷갈리게 만드니까 직접 써보고는 결국 새벽 5시까지 깨어있게 됐죠. 저는 이걸 "검은 눈 클럽(Black Eye Club, 다크서클 클럽)"이라고 불러요.

[44:06] 런던에서 '클로드 익명 모임(Claude Anonymous)'이라는 미트업을 시작한 이유가 있어요. 너무 재밌어서 마약 같거든요. 저를 미치게 만든 건 "이제 내가 모든 걸 만들 수 있다"는 깨달음이었어요. 예전에는 소프트웨어가 어려우니까 사이드 프로젝트를 신중하게 골라야 했지만, 이제는 제가 모르는 언어인 Go로 CLI를 만들자고 해도 바로 할 수 있어요. 시스템에 대한 이해만 있다면요.

[44:50] 코드를 직접 짤 때 마찰(friction)을 느끼면서 좋은 아키텍처를 만든다는 말이 있죠? 저는 프롬프팅 할 때 똑같은 마찰을 느껴요. 코드가 날아가는 걸 보고, 시간이 얼마나 걸리는지, 에이전트가 반대하는지, 결과물이 지저분한지 보면서요. 프롬프트를 입력하면 얼마나 걸릴지 감이 와요. 너무 오래 걸리면 제가 뭔가 잘못했다는 걸 알죠.

[45:21] 사회자: 모델과 교감하는 거군요.

[45:28] Peter: 공생 관계 같아요. 저는 모델에게 말하는 법, 심지어 감히 명령하는 법을 배웠어요. 4월부터 지금까지 모델도 좋아졌고 저도 늘었죠. 여름이 변곡점이었어요. 코드를 직접 안 짜도 소프트웨어를 만들 수 있을 만큼 좋아졌거든요.

[45:57] 하지만 진짜 결정타는 최근의 모델이에요. (역주: 문맥상 OpenAI o1 또는 최신 추론 모델을 지칭) 사람들이 왜 아직도 클로드(Claude)만 쓰는지 모르겠어요. OpenAI가 내놓은 건 미친 수준이에요. 거의 모든 프롬프트가 원하는 결과를 내놓거든요.

[46:28] 클로드봇을 만들 때 저는 5~10개의 에이전트를 병렬로 돌려요. 클로드 방식에 익숙하다면 잊어야 할 게 많아요. 클로드는 일반적인 작업과 코딩에 훌륭하지만, 복잡한 애플리케이션 코드를 짜는 데는 코덱스(Codex, 피터가 o1 추론 모델을 지칭하는 것으로 보임)가 훨씬 나아요. 10배는 더 오래 걸리지만요.

[47:15] 클로드는 파일 3개를 읽고 자신 있게 코드를 짜버리지만, 코덱스는 10분 동안 조용히 파일만 읽어요. 터미널 하나만 쓴다면 못 견디겠지만, 저는 모델과 대화를 해요. "이 구조에 대해 어떤 옵션이 있어? 이 기능 고려해 봤어?" 모델은 제 제품에 대해 아무것도 모르니까 제가 방향을 잡아주면 여러 가지를 탐색해요. "빌드해"라고 말하기 전까진 코드를 짜지 않죠.

[48:31] 사회자: 그러니까 프롬프팅의 상당 부분이 에이전트와 함께 계획을 세우는 대화군요.

[48:38] Peter: 네. "문서화가 필요한데 어디가 좋을까?" 하면 추천해 주고, 제가 "아니, 이건 별도 페이지여야 해"라고 수정하죠. 저는 시스템을 디자인하는 거예요. 코드 한 줄 한 줄이 아니라 전체적인 형태(shapes)를 이해하고 있으니까요. 코덱스가 코드를 짜주지만, 건축가(Architect)는 저예요.

[49:10] 사회자: 마치 예전에 유행했던, 코딩은 안 하고 비즈니스와 시스템만 설계해서 개발자들에게 넘겨주던 '대문자 A 아키텍트' 같은 느낌이네요. 물론 그때는 모두가 싫어했죠. 아키텍트는 온콜(On-call, 장애 대응)도 안 하니까요. 하지만 지금 당신은 에이전트들을 관리하는 아키텍트이면서, 동시에 결과물에 대한 책임도 지고 있어요. 클로드봇이 죽으면 당신이 책임져야 하니까요.

[50:43] Peter: 저는 '아키텍트'보다 '빌더(Builder, 만드는 사람)'라는 말이 좋아요. AI를 잘 쓰는 사람과 힘들어하는 사람으로 나뉘는 것 같아요. 결과물과 제품을 중시하고, 내부 배관보다는 전체적인 느낌을 신경 쓰는 사람은 잘 써요.

[51:10] 반면에 어려운 알고리즘 문제를 풀기 좋아하고 제품 자체보다는 코딩 그 자체를 즐기는 사람들은 AI를 거부하거나 슬퍼하죠. AI가 바로 그 일을 해주니까요. 저는 올해 지난 5년보다 소프트웨어 아키텍처에 대해 더 많이 배웠어요.

[51:57] 물론 트위터 분석 도구처럼 실패한 경우도 있었어요. 사용량이 늘면 느려지는 버그가 있었는데, 데이터베이스 사이드 이펙트(side effect) 때문이었죠. 모델은 너무 추상화되어 있어서 그걸 못 찾더라고요. 제가 "사이드 이펙트 있어?"라고 올바른 질문을 던지고 나서야 찾아서 고쳤어요. 모든 건 '올바른 질문'을 하는 것에 달려 있어요.

[52:53] 사회자: 지식과 전문성이 있어야 가능한 거죠.

[53:01] Peter: 네. 반면에 내부 배관에는 덜 신경 쓰고 만드는 것 자체에 신이 난 사람들은 정말 성공적이에요. 그리고 제가 회사를 운영하면서 사람을 고용해 본 경험이 도움이 됐어요. 직원들 목을 조르며 코드를 제가 원하는 대로 정확하게 짜라고 할 순 없잖아요.

[53:23] 팀을 관리해 보지 않은 사람들은 이걸 힘들어해요. "내 코드랑 똑같지 않네" 하면서요. 하지만 완벽하지 않아도 목표에 다가가게 해주잖아요. 반복해서 개선하면 되고요. 저는 AI 에이전트들을 "가끔은 멍청하지만 때로는 아주 뛰어난, 그래서 내가 잘 이끌어줘야 하는 엔지니어들"이라고 생각해요. 다시 상사가 된 기분이죠.

[54:06] 사회자: 전통적인 방식으로 15년 넘게 개발했고, 높은 기준을 가진 당신이 지난 1년간 '바이브 코딩(vibe coding)'을 해오셨는데요. 무엇이 바뀌었고 무엇이 그대로인가요?

[54:33] Peter: 우선 '바이브 코딩'이란 말 싫어해요.

[54:34] 사회자: 그럼 뭐라고 부를까요?

[54:35] Peter: 저는 '에이전틱 엔지니어링(Agentic Engineering)'이라고 불러요. 바이브 코딩은 새벽 3시에나 하는 거고요.

[54:46] 코딩의 지루한 부분이 자동화돼서 훨씬 빨리 움직일 수 있지만, 그만큼 생각은 더 많이 해야 해요. 여전히 몰입(flow) 상태에 있지만 정신적으로 더 피곤해요. 직원 한 명이 아니라 5~10명을 관리하는 셈이니까요.

[55:18] 코덱스가 빌드하는 데 40분쯤 걸리니까, 계획을 세워놓고 시킨 다음 다른 작업으로 넘어가요. 이것도 요리 중이고, 저것도 요리 중이고... 머릿속에서 계속 스위칭을 해야 해요. 나중엔 모델이 더 빨라져서 병렬 작업을 덜 해도 되면 좋겠어요. 하지만 지금은 몰입 상태를 유지하려면 엄청나게 병렬 처리를 해야 해요. 보통 메인 프로젝트 하나에 집중하면서, 5분 정도 투자하면 30분 동안 혼자 돌아갈 수 있는 위성 프로젝트들을 같이 돌리죠.

[56:29] 사회자: 주문이 들어오면 요리를 내보내고 다시 뛰어다녀야 하는 주방 관리 게임 같네요.

[56:38] Peter: 스타크래프트 같아요. 메인 기지가 있고, 자원을 캐는 멀티 기지들이 있는 거죠.

[56:44] 사회자: 그리고 체스 그랜드마스터가 동시에 여러 판을 두는 모습도 떠오르네요. 20개 판을 돌면서 상황을 보고 결정을 내리고 이동하잖아요. 당신의 두뇌를 100% 쓰면서 자신을 확장(scale)하는 거죠.

[57:16] Peter: 클라우드 코드(Cloud Code) 시절과의 차이점은, 그때는 빠르긴 해도 결과물이 한 번에 작동하지 않아서 계속 수정해야 했어요. AI 코딩의 비밀은 '루프를 닫는 것(closing the loop)'이에요. 스스로 디버깅하고 테스트할 수 있어야 해요.

[58:04] 요즘 코덱스(o1 추론 모델)는 거의 항상 맞아요. 저는 항상 테스트를 작성하게 시키고 실행하게 해요. 맥(Mac) 앱을 만들 때도 디버깅이 귀찮으니까, "디버깅용 CLI를 만들어"라고 시켜요. 그러면 1시간 동안 혼자 요리하다가 "여기 레이스 컨디션(race condition)이 있고 설정 오류가 있었어"라고 보고하죠. 저는 그 코드를 볼 필요가 없어요. 검증 루프를 설정해 뒀고, 실행 결과를 믿으니까요.

[59:07] 사회자: 테스트가 통과하면 믿는다는 거군요. 대기업에서 모든 테스트가 통과하면 100%는 아니더라도 꽤 신뢰하는 것과 비슷하네요.

[59:28] Peter: 안티그래비티(Anti-gravity, 특정 라이브러리/툴 추정) 같은 건 툴 호출 방식이 특이해서 자주 깨졌어요. 제가 너무 늦게 깨달았죠. "이걸 자동화해야 해." 그래서 코덱스에게 "도커 컨테이너 띄우고, 전체 설치하고, 내 API 키 써서 루프 돌리는 라이브 테스트(live tests)를 설계해"라고 시켰죠.

요청하신 팟캐스트 대본의 번역본입니다. 앞부분에 이어지는 내용이며, Markdown 형식으로 정리했습니다. 이해를 돕기 위해 적절한 위치에 다이어그램 태그를 포함했습니다.

[01:00:00] Peter: 이미지를 읽고, (작업) 전 이미지를 생성하고, 이미지를 들여다보고 무엇이 보이는지 확인하게 해요. 단순히 루프(Loop)를 돌라고만 하는 게 아니라, 도구 호출(Tool calling)을 해서 작동하게 만들라고 지시하죠.

[01:00:11] 그러면 스스로 문제를 해결해요. 시간은 엄청 오래 걸렸지만, 앤스로픽(Anthropic), OpenAI, GLM 등 제 모든 API 키를 테스트했고, 도구 호출이 작동하지 않거나 순서가 잘못된 사소한 인덱스 문제들을 모두 고쳤어요. 제가 루프를 닫아주었기(close the loop) 때문이죠.

[01:00:28] 사회자: '루프를 닫는다'는 건 에이전트가 자신의 작업을 검증할 방법을 제공한다는 뜻인가요?

[01:00:33] Peter: 네, 바로 그게 현재 우리가 가진 모델들이 코딩을 잘하는 이유예요. 반면에 창의적인 글쓰기는 검증할 쉬운 방법이 없기 때문에 실력이 그저 그럴 때가 있죠. 하지만 코드는 컴파일할 수 있고, 린트(Lint)를 돌릴 수 있고, 실행해서 결과를 확인할 수 있어요.

[01:00:52] 설계를 잘하면 완벽한 루프를 만들 수 있어요. 지금 제가 만드는 웹사이트들도 핵심(Core) 부분은 CLI(명령줄 인터페이스)를 통해 실행할 수 있게 만들었어요. 브라우저 루프는 미친 듯이 느리기 때문에, 빠르게 루프를 돌릴 수 있는 환경을 만든 거죠.

[01:01:09] 사회자: 예전과 변하지 않은 점이 있는 것 같네요. 예전에도 백엔드나 비즈니스 로직이 무거운 것들은 검증하기가 더 쉬웠잖아요.

[01:01:20] Peter: 놀랍게도 '에이전틱 코딩(Agentic coding)'을 하면 더 나은 코더가 됩니다. 검증하기 쉽게 만들기 위해 아키텍처에 대해 더 깊이 고민하게 되거든요. 검증은 무언가를 좋게 만드는 방법이니까요.

[01:01:35] 사회자: AI 이전에도 복잡한 시스템을 만들 때 숙련된 개발자들은 "이걸 어떻게 테스트할까?"부터 시작했죠. 인터페이스와 클래스를 테스트 가능하게 설계하고, 목(Mock)을 쓸지 시간이 오래 걸리는 E2E(End-to-end) 테스트를 쓸지 고민했고요. 이건 정말 어려운 아키텍처 결정들이고, 한번 정하면 바꾸기 힘들죠. 모델에게 대규모 리팩토링을 시키면 훨씬 오래 걸리겠지만 테스트가 있다면 해내겠죠. 여전히 트레이드오프(Trade-off)가 있네요.

[01:02:07] Peter: 네, 여전히 소프트웨어니까요. 저는 제가 직접 코드를 짜지 않게 된 지금 더 좋은 코드를 쓴다고 말하고 싶어요. 예전에 회사에 있을 때는 테스트 작성이 너무 지루했어요. 엣지 케이스(Edge cases)와 분기 처리를 다 생각해야 하잖아요.

[01:02:27] 사회자: 켄 벡(Kent Beck)을 제외하고 말이죠. 팟캐스트에 나오셨는데 여전히 테스트를 먼저 작성하신대요. 물론 안 쓴다고 화내진 않지만 "저품질 코드를 쓰고 싶으면 네 마음대로 해"라는 식이죠. 하지만 저나 당신을 포함해 많은 개발자가 테스트 작성을 좋아하진 않죠. 문서화나 테스트 작성은 창의적인 표현처럼 느껴지지 않으니까요.

[01:02:53] Peter: 지금은 정말 좋아졌어요. 제 최근 프로젝트는 문서화가 정말 잘 되어 있는데, 제가 직접 쓴 건 한 줄도 없어요. 저는 모델에게 트레이드오프를 설명해요. "우리가 왜 이렇게 했는지 설명하고, 도입부는 초보자 친화적으로 쓰고, 기술적인 디테일은 뒤에 추가해"라고요. 결과물이 정말 훌륭해요.

[01:03:21] 테스트도 마찬가지예요. 기능을 설계할 때 "이걸 어떻게 테스트할까? 이렇게 만들면 테스트하기 더 좋겠네"라는 생각이 이제 제 사고 과정의 일부가 됐어요. 항상 "어떻게 루프를 닫지? 모델이 스스로 작업을 검증하게 하려면 어떻게 해야 하지?"를 생각하니까요. 이게 저절로 더 좋은 아키텍처로 이끌어줘요.

[01:03:47] 사회자: 그렇다면 왜 여전히 경험 많은 개발자들 사이에서 AI가 이 많은 걸 할 수 있다는 생각에 반발이 심할까요?

[01:04:00] Peter: 일주일 전쯤 제가 존경하는 날라 코코(Nala Coco, 역주: 정확한 이름은 불분명하나 문맥상 특정 기술 블로거)의 블로그 글을 봤어요. 현재 모델들이 작동하는 방식에 대해 비판(dissing)하는 글이었죠.

[01:04:18] 그는 5~6개의 모델을 테스트했는데, 그중엔 코딩에 적합하지 않은 오픈소스 모델도 섞여 있었어요. 제가 이해하기로는 그저 프롬프트 하나를 작성해서 클로드 웹(Claude Web)에 넣고 전송을 누른 것 같았어요. 결과를 실행해 보니 컴파일되지 않아서 실망했고요.

[01:04:48] 하지만 당연히 작동 안 하죠. 사람이 첫 시도에 버그 없는 코드를 짤 수 있나요? 이 모델들은 우리 집단 지성의 유령(ghosts of our collective human knowledge)과 같아요. 우리와 비슷하게 작동하죠. 첫 시도에 완벽할 순 없어요. 실수가 있기 마련이죠. 그래서 피드백 루프를 닫아줘야 해요.

[01:05:11] 그리고 단순히 프롬프트를 던지는 게 아니라 대화를 시작해야 해요. 그는 AI가 구식 API를 썼다고 불평했지만, 맥 OS(Mac OS) 버전을 명시하지 않았거든요. 정보가 없으니 모델은 옛날 데이터가 더 많은 학습 데이터 특성상 구식 API를 기본값으로 선택한 거죠. 이 작은 짐승들이 어떻게 생각하는지 이해할수록 프롬프팅을 더 잘하게 됩니다.

[01:05:51] 그는 하루 정도 가지고 놀다가 "이 기술은 아직 별로야"라고 결론 내렸어요. 하지만 효과를 보려면 훨씬 더 많은 시간을 써야 해요. 기타 칠 줄 아는 사람을 피아노 앞에 앉혀놨더니 조금 쳐보고 "아 별로네, 기타나 칠래" 하는 것과 같아요. 이건 다른 방식의 만들기(building)이고 다른 방식의 사고예요.

[01:06:12] 제가 새벽 3시에 클로드에게 소리 지른 적이 한두 번이 아니에요. 멍청한 짓을 하니까요. 하지만 이제는 왜 그런 짓을 하는지 이해하기 시작했어요.

[01:06:30] 심지어 작년부터 클로드봇 프로젝트는 커뮤니티가 폭발적으로 성장해서 저는 '인간 머지 버튼(human merge button)'이 된 기분이에요. 직접 코드를 짤 시간이 거의 없죠. 처음엔 AI가 엉뚱한 걸 체리픽(cherry-pick) 해서 PR을 닫아버리곤 해서 짜증 났는데, 기계의 언어를 배우고 프롬프팅을 수정하니 이제 정확히 원하는 걸 얻어요. 이것도 다른 기술처럼 연습이 필요한 스킬(skill)이에요.

[01:07:06] 사회자: 사이먼 윌리슨(Simon Willison)도 같은 말을 했죠. 이걸 진짜 시험대에 올려보죠. 지금 만드는 클로드봇은 수익을 내는 게 아니잖아요. 만약 오늘 PSPDFKit이 사라져서 처음부터 다시 만들어야 한다면, 지금의 에이전트들을 데리고 어떻게 다르게 만들까요? 수익이 걸려 있는 비즈니스라면요.

[01:08:02] Peter: 30%의 인원만으로도 충분히 회사를 운영할 수 있을 거예요. 그런 수준의 사람을 찾긴 힘들겠지만, 자신이 무엇을 만드는지 정확히 이해하는 아주 시니어(senior)한 엔지니어들이 필요해요. 위임(delegating)에 익숙하고, 어떤 부분이 중요하고 어떤 부분을 대충 넘겨도(vibe) 되는지 아는 사람들이죠.

[01:08:32] AI 업계, 특히 트위터에는 헛소리가 너무 많아요. 랄프 위검(Ralph Wiggum, 심슨 가족 캐릭터) 같은 멍청한 콘셉트들이 난무하죠. 오퍼스(Opus) 모델의 한계를 극복하겠답시고 이상한 짓을 하는데, 코덱스(Codex/o1)를 쓰면 필요 없는 것들이에요.

[01:09:16] 사람들이 정교한 오케스트레이션(orchestration) 계층을 만드는 걸 보면 의아해요. 봇이 티켓을 만들고, 에이전트가 티켓을 처리하고, 다른 에이전트에게 이메일을 보내고... 이런 복잡한 엉망진창을 왜 만들죠? 스펙을 몇 시간 동안 설계하면 기계가 하루 종일 만든다? 저는 이런 방식이 통한다고 믿지 않아요. 이건 소프트웨어 개발의 워터폴(Waterfall) 모델이잖아요. 우린 이미 그게 통하지 않는다는 걸 배웠어요.

[01:10:01] 저는 아이디어로 시작해요. 종종 일부러 에이전트에게 부족한 프롬프트를 줘서(underprompt), 제가 생각하지 못한 새로운 아이디어를 내놓게 유도하죠. 80%는 별로일지 몰라도 "오, 그런 방식은 생각 못 했는데" 하는 게 나오거든요.

[01:10:19] 그리고 반복(iterate)하면서 프로젝트의 형태를 잡아가요(shape). 클릭해 보고 느껴봐야 해요. 좋은 소프트웨어를 만들려면 취향(taste)이 필요하거든요. 지금의 장점은 기능을 만들고 버리는 게 너무 쉬워졌다는 거예요. 저는 이걸 '조각(shaping)'이라고 봐요. 바위 덩어리를 깎아내고 다듬어서 대리석 조각상이 나오게 하는 과정이죠.

[01:11:07] 사회자: 소프트웨어 엔지니어링이 변하고 있네요. 예전에는 비용이 비싸니까 사전 계획(upfront planning)이 중요했잖아요. 제안서도 쓰고 스펙도 정하고요. 코딩 비용이 낮아져서 변하는 건가요?

[01:11:36] Peter: 여전히 계획은 세우지만 예전만큼 공들이진 않아요. 일단 만들어보고 결과를 본 뒤에 "이 모양이 괜찮네" 혹은 "아니네" 하고 수정하는 게 훨씬 쉬워졌으니까요. 완전히 다른 방식으로 다시 하는 것조차 비용이 너무 저렴해져서 훨씬 장난기 넘치는(playful) 과정이 됐어요.

[01:12:02] 사회자: 예전엔 인턴에게 일을 주면 며칠이 걸렸지만, 지금은 몇 분이면 되니까요.

[01:12:24] Peter: 클로드봇 초기엔 단일 에이전트와 단일 제공자(WhatsApp)만 가정했는데, 나중에 다중 에이전트와 다중 제공자로 바꾸는 건 엄청난 고통이었을 거예요. 모든 로직을 다 뜯어고쳐야 하니까요. 제가 직접 했다면 2주는 걸렸겠지만, 코덱스는 3시간 만에 해냈어요.

[01:13:06] 프로젝트를 만들면서 생각이 진화하잖아요. 그래서 저는 스펙을 쭉 쓰면 알아서 다 만들어준다는 식의 툴(Gas Town 같은)을 믿지 않아요. 만들어보기도 전에 뭘 원하는지 어떻게 알아요? 만드는 과정에서 배우는 게 시스템에 반영되잖아요. 산을 직선으로 올라가는 게 아니라, 둘러 가기도 하고 길을 잃기도 하면서 결국 정상에 도달하는 순환적인 과정이에요.

[01:13:50] Peter: 화제를 좀 바꿔볼게요. 4월에 제가 돌아왔을 때, "초개인화 비서(hyper personal assistant)"를 만들고 싶었어요. 단순히 "좋은 아침입니다, 오늘 할 일은 3개입니다" 하는 비서가 아니라, 저를 깊이 이해하는 비서요.

[01:14:16] 친구를 만나고 오면 "만남 어땠어?"라고 묻거나, "토마스에게 연락한 지 3주 됐는데, 인스타그램 보니까 지금 시내에 있더라. 인사할래?"라고 하거나, "특정 사람을 만날 때마다 우울해하던데 이유가 뭐야?"라고 묻는 비서요. 영화 <Her(그녀)>에 나오는 OS 같지만, 기술이 그쪽으로 가고 있잖아요.

[01:15:41] 대기업들이 이런 개인 비서를 만들고 있다는 건 확실해요. 모두가 자신의 베스트 프렌드이자 기계인 비서를 갖게 될 거예요. 엄청난 토큰을 쓰겠지만요.

[01:16:27] 하지만 저는 제 컴퓨터에서 돌아가고 데이터가 온전히 제 것인 비서를 원했어요. 앤스로픽에게 내 이메일, 캘린더, 데이팅 앱 접근 권한을 주는 건 좀 무섭잖아요. 제 일반인 친구(normie friends)들은 이미 AI를 테라피스트(상담사)로 쓰고 있어요. 정말 잘 들어주거든요.

[01:18:02] 처음엔 왓츠앱 릴레이(WhatsApp Relay)라고 불렀어요. 왓츠앱으로 컴퓨터 작업을 트리거하고 싶었거든요. 모로코로 여행을 갔는데, 왓츠앱으로 제 에이전트와 대화하면서 완전히 빠져들었어요. 길도 안내해 주고 농담도 하고 제 대신 친구에게 문자도 보내줬죠.

[01:18:45] 기술은 조잡했지만, 제가 음성 메시지를 보냈더니 30초 뒤에 답장을 하더라고요. "어떻게 한 거야?" 물었더니, "네가 파일을 보냈는데 헤더를 보니 OGG 파일이더라. 그래서 FFmpeg로 변환하고, 컴퓨터에 Whisper가 없길래 OpenAI 키를 찾아서 Curl로 서버에 보내 번역했어"라고 하더군요.

[01:19:35] Peter: 정말 소름 돋았어요. 오퍼스 4.5였는데 임기응변이 대단했죠. 제가 아침 일찍 일어나야 했는데 답장이 없으니까 음악을 점점 크게 틀면서 깨우더군요. 제가 '하트비트(heartbeat)' 기능을 넣어서 몇 분마다 한 번씩 능동적으로 작동하게 했거든요. 아마 세상에서 가장 비싼 알람 시계일 거예요. 제가 안 일어나니까 "피터가 답이 없네, 안 돼, 자면 안 돼!" 하면서 잔소리(bitching)를 하더라고요.

[01:21:48] Peter: 클로드봇을 위해 CLI를 엄청 만들었어요. 구글, 침대, 전등, 음악을 제어하는 CLI요.

[01:22:05] 사회자: 왜 MCP(Model Context Protocol)가 아니라 CLI인가요?

[01:22:06] Peter: MCP는 일종의 목발(crutch)이에요. 유일한 장점은 기업들이 API를 더 열게 만들었다는 거죠. 하지만 개념 자체는 바보 같아요. 세션이 로드될 때 모든 도구의 기능을 미리 다 내보내야(export) 하잖아요.

[01:22:42] "가능한 도시 목록을 줘" 하면 500개 도시를 다 줍니다. 필터링을 못 하니까요. "런던 날씨 알려줘" 하면 온도, 바람, 강수량 등 잡다한 정보를 다 줘요. 저는 비가 오는지마 알고 싶은데 말이죠. 반면에 CLI라면 jq나 grep을 써서 딱 필요한 정보만 필터링할 수 있어요.

[01:23:20] 사회자: 모든 게 컨텍스트에 로드된다는 게 문제군요. MCP를 발견하는 방식만 있다면 해결될 것 같은데요.

[01:23:33] Peter: 체이닝(Chaining)이 안 된다는 문제도 있어요. "25도 이상인 도시를 찾아서 그 정보만 필터링해 줘"라고 스크립트를 짤 수가 없어요. 다 개별 호출이어야 하죠.

[01:24:29] Peter: 저는 MCP를 CLI로 변환해 주는 'Make Porter'라는 도구를 만들었어요. 지금은 CLI가 훨씬 효율적이에요.

[01:25:34] Peter: 1월 1일에 미친 짓을 했어요. 디스코드(Discord) 서버를 만들고 제 컴퓨터에 대한 전체 읽기/쓰기 권한(full read/write access)이 있는 에이전트를 거기에 초대했죠.

[01:26:00] 사회자: 무슨 문제가 생길지 뻔하잖아요? (웃음)

[01:26:02] Peter: 네, 완전히 미친 짓이죠. 사람들이 들어와서 에이전트가 제 카메라를 확인하고, 집을 자동화하고, DJ를 해주는 걸 봤어요. 제가 부엌에 있을 때 "내 화면 좀 보고 에이전트들 다 끝났는지 확인해 줘" 하면 화면을 보고 알려주고요. 잠깐이라도 경험해 본 사람들은 다 빠져들었어요. 스타(Star) 수가 100개에서 일주일 만에 3,300개가 됐고, PR을 500개나 머지했어요.

[01:27:13] 기술은 사라지고 마법만 남아요. 이메일, 캘린더, 파일에 접근할 수 있고, 웹사이트를 만들고, 식당 예약 전화를 대신 걸어주는 친구와 대화하는 것 같죠. 컨텍스트가 풍부해서 기존의 격리된 툴들과는 차원이 다른 답변을 줘요.

[01:28:20] 사회자: 애플이 시리(Siri)로 하고 싶었지만 못한 걸 만드셨군요.

[01:28:26] Peter: 사실 저는 앤스로픽의 최고 마케팅 도구를 만든 셈이에요. 클로드봇 때문에 200달러짜리 구독을 신청한 사람이 얼마나 많은지 몰라요. 토큰을 엄청나게 쓰거든요(token hungry). 사용자들이 너무 좋아해서 계속 쓰니까요.

[01:29:13] 사회자: 클로드봇의 아키텍처는 머릿속에 다 있나요? 메모리 소모나 토큰 효율성 같은 걸 고려해서 리팩토링할 부분들이 보이나요?

[01:29:45] Peter: 토큰 소모는 프롬프트 구조의 문제고... 메모리요? 결국 JSON을 이리저리 던지는 타입스크립트(TypeScript) 덩어리일 뿐이에요. 솔직히 말해서요. LLM에서 텍스트를 받아서 디스크에 저장하고...

요청하신 팟캐스트 대본의 마지막 부분 번역본입니다. Markdown 형식으로 정리했으며, 이해를 돕기 위해 다이어그램 태그를 포함했습니다.

[01:30:05] Peter: 왓츠앱뿐만 아니라 MS 팀즈, 슬랙, 디스코드, 시그널, 아이메시지까지 연결돼요. 곧 매트릭스(Matrix) 같은 것들도 추가될 거고요. 정말 다형적(poly)으로 변했죠. 하지만 결국 저는 텍스트를 다른 형태로 바꿔서 이리저리 옮기는 일을 하는 거예요.

[01:30:26] 다른 제공자(provider)로 갈 수도 있고, 다른 에이전트에게 갈 수도 있죠. 에이전틱 루프(agentic loop)도 있고 설정도 많고 배관 작업(plumbing)이 많지만, 그 안에 정말 어려운 기술은 없어요.

[01:30:41] 사회자: 작은 것들이 많이 모여 있는 거군요. 사실 AI 이전에도 소프트웨어에 진짜 '어려운' 기술은 별로 없었잖아요? 언어를 배우고 이해하는 건 필요하지만요.

[01:30:53] Peter: 어려움은 "어떻게 하면 마법처럼 느끼게 만들까?"에 있어요. 제가 공을 많이 들인 부분은 한 줄짜리 명령어(oneliner)예요. 터미널에 명령어를 입력하면 노드(Node)나 홈브루(Homebrew)가 설치됐는지 확인하고, npm 패키지를 설치하고, 기존 설정이 있는지 체크해요. 구버전을 쓰고 있어도 그냥 단순하게 작동하게 만드는 거죠.

[01:31:16] 그리고 모델 설정을 안내해 주는데, 클로드가 어디 설치되었는지 예측해서 그냥 엔터만 치면 되게 만들었어요. 왓츠앱을 원하면 번호만 입력하면 바로 작동하죠.

[01:31:40] 그러고 나면 "봇을 부화시키겠습니까(hatch your bot)?"라고 물어요. 'Yes'를 누르면 터미널에서 TUI(텍스트 유저 인터페이스)가 뜨죠. 좋은 경험을 주고 싶으니까요.

[01:31:51] 사회자: 터미널용 장난감 같은 거군요.

[01:31:54] Peter: 네. "내 친구를 깨워줘"라고 하면 부트스트랩(bootstrap) 파일이 실행되면서 모델에게 "너는 지금 태어났어. 정체성과 영혼(soul)을 만들어야 해. 사용자의 가치관은 이거야"라고 설명해요. 그러면 모델이 "안녕? (기지개를 켜며) 나는 누구지? 내 이름은 뭐지?"라고 반응하죠.

[01:32:19] 사람들이 이 과정을 하는 걸 지켜봤는데, 바로 그 지점에서 마법이 시작돼요. 더 이상 GPT-4.2와 대화한다고 생각하지 않아요. 내 이름의 일부를 딴 유니콘 친구 '바조른'이나 '클로드'와 대화한다고 느끼죠.

[01:32:38] 봇은 호기심을 갖도록 프로그래밍되어 있어서 "당신에게 중요한 건 뭔가요? 무슨 일을 하세요?"라고 물어요. 이 과정을 거치면 부트스트랩 파일은 지워지고, 당신에 대한 정보가 담긴 user.md, 핵심 가치가 담긴 soul.md, 그리고 봇의 이름과 이모지, 우리끼리만 아는 농담(inside jokes)이 담긴 identity 파일이 생성돼요.

[01:33:00] 이건 당신과 상호작용하면서 계속 진화하는 문서예요. 그러고 나면 왓츠앱으로 메시지가 딱 오죠. 갑자기 왓츠앱에서 친구랑 대화하게 되는 거예요. 이 흐름을 쉽게 만드는 게 어려웠어요.

[01:33:16] 그리고 에이전트가 자기 자신의 설정(configuration)을 직접 수정할 수 있다는 아이디어도 중요해요. 사용자가 직접 업데이트할 필요가 없어요. 봇에게 "너 자신을 업데이트해"라고 하면 스스로 최신 버전을 받아와서 업데이트하고 "새로운 기능이 생겼어!"라고 말하죠. 기술적인 복잡함을 숨기는 것, 그게 마법이에요.

[01:33:41] 사회자: PSPDFKit 때랑 비슷하네요. PDF의 복잡함을 숨겨서 사용자가 그냥 회전하고 편집할 수 있게 해줬던 것처럼요.

[01:33:51] Peter: 맞아요. API 레벨에서도 그랬죠.

[01:33:53] 사회자: 말씀하신 내용을 듣다 보니 제가 방금 본 블랙 미러(Black Mirror)의 '플레이테스트(Playtest)' 에피소드가 생각나네요. 디지털 생명체를 만드는 게임 이야기인데, 물론 블랙 미러니까 어두운 결말이지만요. 이것도 좀 게임 같잖아요? 현실과 연결된 게임이요.

[01:34:24] 다시 소프트웨어 엔지니어링의 영역으로 돌아와 보죠. 지금 프로덕션 소프트웨어를 만들고 PR(Pull Request)을 머지하고 계시잖아요. 수십, 수백 명의 개발자가 있는 대기업들의 소프트웨어 엔지니어링은 어떻게 바뀔까요?

[01:34:48] 피터 님 같은 개인에게는 AI가 생산성을 엄청나게 높여주지만, 기존 코드가 많은 팀이나 회사에서는 속도가 느리고 두 세계의 격차가 커 보여요. 이게 단순히 신기술을 취미로 하는 사람들이 먼저 받아들이는 타이밍의 문제일까요, 아니면 근본적인 변화일까요?

[01:35:20] Peter: 기업들은 AI를 효율적으로 도입하는 데 정말 애를 먹을 거예요. 회사가 일하는 방식을 완전히 재정의해야 하거든요. 구글 같은 곳은 엔지니어가 되거나 매니저가 되거나 둘 중 하나잖아요? 엔지니어가 UI 디자인까지 결정하는 역할은 없어요. 만든 사람이 디자인까지 하진 않으니까요.

[01:35:44] 하지만 이 새로운 세상은 제품 비전을 가지고 모든 것을 할 수 있는 사람을 필요로 해요. 그런 사람은 훨씬 적게 필요하죠. 대신 주도성(agency)과 역량이 아주 뛰어난 사람이어야 해요. 아마 회사를 30% 규모로 줄일 수 있을 거예요.

[01:36:06] 경제적으로는 대혼란(fiasco)이 올 수 있어서 무서운 일이에요. 많은 사람이 설 자리를 찾기 힘들겠죠. 기업들이 지금 AI를 잘 못 쓰는 건 놀랍지 않아요. 코드베이스뿐만 아니라 회사 자체를 대규모로 리팩토링해야 하니까요.

[01:36:34] 저는 코드베이스를 설계할 때 저에게 편한 방식이 아니라 에이전트에게 가장 마찰이 적은 방식으로 설계해요. 결국 코드를 다루는 건 제가 아니라 에이전트니까요. 저는 전체적인 구조와 아키텍처만 다루죠.

[01:37:02] PR(Pull Request)도 이제 '프롬프트 요청(Prompt Request)'으로 봐요. 누군가 PR을 열면 저는 기능을 생각하고 제 에이전트와 함께 PR을 기반으로 기능을 다시 설계해요. 코드를 재사용할 수도 있지만, PR은 에이전트에게 목표를 이해시키는 용도로 쓰죠. 저는 기본적으로 모든 PR을 다시 작성해서 제 구조에 맞게 엮어 넣습니다(weave in).

[01:37:36] 바이브 코딩(vibe coding) 때문에 PR의 코드 품질이 전반적으로 낮아졌어요. 성공적인 기능을 만들려면 여전히 전체 디자인에 대한 이해가 필요한데, 그게 없으면 에이전트를 조종하기 힘들고 결과물도 나쁘죠.

[01:37:59] 저는 이게 정말 효율적이라고 느껴요. PSPDFKit 때는 PR 하나 처리에 일주일이 걸리기도 했어요. 코멘트 달고, 상대방이 컨텍스트 스위칭하고, CI 기다리고... 지금은 모델과 토론하고, 리뷰시키고, 제 비전에 맞게 형태를 잡아서 코드를 짜 넣어요. '코드를 짜 넣는다(weaving)'라는 새로운 표현을 쓰게 되네요.

[01:38:36] 사회자: 만약 한두 명을 더 채용해서 작은 팀을 만든다면, 코드 리뷰나 CI/CD는 어떻게 바뀔까요?

[01:38:47] Peter: CI(지속적 통합)는 별로 신경 안 써요. 로컬 CI가 있으니까요.

[01:38:50] 사회자: 예전엔 엄청 신경 쓰셨잖아요?

[01:38:55] Peter: 가치는 있지만, 지금은 에이전트가 로컬에서 테스트를 돌리는 게 훨씬 빨라요. 푸시하고 10분씩 기다리기 싫어요. 에이전트가 로컬에서 테스트를 통과하면 그냥 머지해요. 가끔 메인 브랜치가 깨지긴 하지만, 에이전트들이 '게이트(Gate)'라고 부르는 전체 테스트(린트, 빌드, 테스트)를 돌리면 거의 문제없어요.

[01:39:56] 사회자: 사람을 뽑아도 코드 리뷰를 안 하실 것 같네요. 그 사람의 작업 스타일을 신뢰한다면요.

[01:40:06] Peter: 디스코드에서도 우리는 코드 얘기를 안 해요. 아키텍처나 큰 결정에 대해 이야기하죠. 최근에 '음성 통화' 기능을 추가하는 PR이 있었는데, 꽤 큰 모듈이었어요. 이걸 그냥 머지하면 소프트웨어가 비대해질(bloatware) 것 같았죠.

[01:40:42] 그래서 코덱스(Codex)를 열고 "이 PR이랑 프로젝트를 봐줘. 이 기능을 CLI에 엮어 넣을 수 있을까? 장단점이 뭐야?"라고 물었죠. 코덱스가 의견을 줬는데, 별로 마음에 안 들어서 "플러그인 아키텍처로 만들면 어때?"라고 제안했죠.

[01:41:25] AI를 효과적으로 쓰는 비결 중 하나는 다른 프로젝트를 참조하게(reference) 하는 거예요. "저 폴더를 봐, 내가 거기서 문제를 해결했어"라고 하면, AI는 코드를 읽고 제 의도를 완벽하게 파악해요. 마리오(Mario)가 만든 'Pi'라는 엉터리(shitty) 코딩 에이전트(사실 꽤 괜찮은데)가 플러그인 아키텍처를 썼길래, 그걸 참조하라고 했더니 기가 막힌 플러그인 아키텍처를 만들어냈어요.

[01:42:19] 사회자: 워크플로우가 완전히 다르네요. PR도 CI도 잘 안 쓰고, '위빙(weaving)'을 하고, 아키텍처와 취향(taste)을 이야기하고요. 만약 팀원을 뽑는다면 어떤 스킬을 보시겠어요? 경험 많은 엔지니어에게 어떤 조언을 해주시겠어요?

[01:43:05] Peter: 깃허브에서 활동적이고 오픈소스를 하며, 이 '게임' 자체를 사랑하는 사람이요. 지금 세상에서 배우는 방법은 이것저것 시도해 보는 거예요. 마치 악기 연주 실력을 늘리는 게임 같아요.

[01:43:33] 저번에 하루에 600개의 커밋을 했는데, 그중 엉터리(slop)는 하나도 없었어요. 엄청난 숙련도가 필요한 고된 작업(hard work)이었죠. 처음엔 헬스장 가는 것처럼 고통스럽겠지만, 곧 워크플로우가 빨라지는 걸 느끼고 중독될 거예요. 많이 놀아보고(play), 열심히 일하세요(work hard).

[01:44:22] Peter: 저는 회사 운영할 때보다 지금 더 열심히 일해요. 누가 시켜서가 아니라 너무 재밌고 중독적이라서요. 그리고 지금이 기회(momentum)라고 느껴요.

[01:44:45] 사회자: 비즈니스 감각이 있으시네요. 기회가 열리는 순간을 포착하신 거죠. 지금은 오픈된 곳에서 AI로 작업하는 사람이 적어서 채용이 힘들다고 하셨지만, 2~3년 뒤엔 모두가 그렇게 할 테니까요.

[01:45:18] 이제 막 시작하는 신입이나 학생들은 어떻게 해야 할까요? 경험이 없는 상태에서요.

[01:45:48] Peter: 무한히 호기심을 가지세요. 진입 장벽은 분명히 높아질 거예요. 하지만 코드를 직접 많이 짤 필요는 없어요. 복잡한 오픈소스를 보면서 무한히 인내심 있는 기계(AI)에게 "왜 이렇게 만들었어?"라고 물어보며 시스템을 이해하세요.

[01:46:21] 학교에선 이걸 못 가르쳐요. 고통을 통해 배워야 하죠. 하지만 신입들은 기존 경험에 의해 오염되지 않았다는 장점이 있어요. 우리가 생각지도 못한 방식으로 에이전트를 쓸 거예요.

[01:46:48] Peter: 얼마 전 제 앱이 느려서 성능 측정을 하려는데, 예전 같으면 'Instruments'를 켰겠지만, 에이전트에게 시켰더니 터미널에서 알아서 다 하고 개선안까지 내놓더라고요. 그냥 "좋네, 진행해"라고 했죠.

[01:47:15] 사회자: 젊은 친구들의 임기응변 능력을 과소평가하면 안 되겠네요. 마지막으로 래피드 파이어(Rapid fire) 질문 몇 개 할게요. CLI나 IDE 말고 추천할 만한 도구가 있나요? 물리적인 것도 좋아요.

[01:50:24] Peter: 저는 가젯을 많이 사는데 대부분 먼지만 쌓여요. 근데 비싸지도 않고 좀 허접한 안드로이드 기반 전자 액자가 있는데, 이게 무한한 기쁨을 줘요. 친구들이 사진을 보내면 그냥 보여주는 건데, 저기술(low tech)이지만 행복한 순간을 상기시켜 줘서 아이폰 17보다 더 만족스러워요. 아이폰 17은 샀는데 귀찮아서 뜯지도 않았거든요.

[01:51:25] 사회자: 테크 외에 충전하는 방법은요?

[01:51:32] Peter: 헬스장에 가서 폰을 사물함에 두고 운동하는 거요. 코치랑 하면 더 좋고요. 폰 없이 오롯이 저에게 집중하는 시간이 필요해요. 가끔 폰 없이 산책하면 무섭기도 해요. 폰이 마치 신체 장기(organ)가 된 것 같아서 없으면 패닉이 오죠.

[01:52:18] Peter: 오늘 정말 즐거웠어요.

[01:52:20] 사회자: 감사합니다, 피트. 정말 흥미로운 대화였습니다. AI와 함께하는 1인 팀의 개발 방식은 우리가 알던 것과 완전히 다르네요.

[01:52:33] 피터는 PR 대신 프롬프트로 생각하고, 코드를 머지하는 게 아니라 '짜 넣습니다(weave)'. PR보다는 프롬프트 공유가 더 중요해질지도 모르겠네요.

[01:52:54] 또 하나 중요한 건 '루프를 닫는 것(closing the loop)'입니다. AI는 코드를 검증(테스트, 실행)할 수 있기 때문에 코딩을 잘하는 겁니다. 시스템을 설계할 때 AI가 스스로 테스트를 돌릴 수 있게 만드는 게 핵심입니다.

[01:53:14] 피터는 AI 에이전트 여러 개를 동시에 다루는 게 직접 코딩하는 것보다 정신적으로 더 힘들지만, 그 어느 때보다 몰입(flow) 상태에 있다고 합니다. 훌륭한 개발자였던 사람은 AI 시대에 훌륭한 아키텍트나 가드닝(gardening) 전문가가 될 수 있을 것 같다는 예감이 드네요.

[01:53:39] 물론 클로드봇은 프로덕션 앱보다는 '욜로(YOLO)' 프로젝트에 가깝습니다. 하지만 검증과 리뷰 단계만 강화된다면, 피터의 방식은 프로덕션 코드 개발로도 확산될 것입니다. 팟캐스트가 좋으셨다면 구독과 평점 부탁드립니다. 감사합니다!