Moltbot(Clawdbot) 제작자 인터뷰 1편: PSPDFKit에서 번아웃까지

source https://www.youtube.com/watch?v=8lF7HmQ_RgY

Gergely Orosz: 하루에 커밋 600개를 머지해도 “대충 만든 슬롭”이 하나도 없다면 어떨까요? 오늘의 게스트, clawdbot의 창시자 Peter Steinberger가 실제로 그걸 하고 있다고 합니다. Peter는 PSPDFKit을 만든 눈에 띄는 개발자예요. PSPDFKit은 10억 대가 넘는 디바이스에서 쓰이는 PDF 프레임워크죠. 그러다 번아웃이 왔고, 지분을 정리한 뒤 3년 동안 기술 업계에서 사라졌습니다. 그리고 올해 돌아왔는데요. 지금 그가 개발하는 방식은, 우리가 알던 전통적인 소프트웨어 개발과는 완전히 달라 보입니다.

오늘은 이런 얘기를 합니다. 왜 이제는 자기가 배포하는 코드 대부분을 직접 읽지 않는지(그게 왜 생각만큼 미친 얘기가 아닌지), 그리고 그럼에도 어떻게 clawdbot을 만들고 있는지.

“vibe coding”이랑 진짜로 효율적인 AI 보조 개발을 갈라놓는 원칙, 바로 “closing the loop(검증 루프 닫기)”.

또 “코드 리뷰는 죽었다, PR은 ‘프롬프트 요청(prompt request)’이라고 불러야 한다”는 그의 도발적인 주장까지요.

AI 때문에 소프트웨어 엔지니어링의 워크플로가 앞으로 어떻게 바뀔지 궁금하다면, 오늘 에피소드는 꽤 재미있을 겁니다.

Gergely Orosz: Peter, 팟캐스트에 오신 걸 환영합니다.

Peter Steinberger: 초대해줘서 고마워요, Gergely.

Gergely Orosz: 직접 만나서 더 좋네요.

Peter Steinberger: 그러게요. 근데 하마터면 약속을 날릴 뻔했어요.

Gergely Orosz: 무슨 일이 있었어요? 시간 감각을 잃었나? 종종 그래요?

Peter Steinberger: 음… 보통은 그렇진 않은데요. 요즘은 좀 특이한 시기예요. 제 최근 프로젝트가 갑자기 크게 터졌거든요.

Gergely Orosz: Claude… 맞죠?

Peter Steinberger: clawdbot이요. 네. 잠을 충분히 못 자는 게 좀 힘들긴 한데, 재밌어요. 이렇게 빠르게 커뮤니티가 커진 건 처음이라, 그냥 너무 신나게 작업하고 있어요.

Gergely Orosz: clawdbot 얘기 들어가기 전에, 시간을 거슬러 올라가볼게요. 당신이 만든 PSPDFKit은… 제 기억엔 10억 대 이상의 디바이스에서 쓰이고 있죠? 우리가 PDF를 렌더링해서 보는 순간, 어딘가에 당신 기술이 있을지도 몰라요. 그런데 그보다 더 이전, 어떻게 ‘기술’로 들어오게 됐어요?

Peter Steinberger: 와… 제가 어떻게 기술로 들어왔지? 저는 오스트리아 시골 출신이고요. 성격은 늘 내향적인 편이었어요. 여름이면 집에 손님이 오곤 했는데, 그중 한 명이 컴퓨터 덕후였거든요. 그 사람이 가져온 기계를 보고 완전히 꽂혀서, 엄마를 졸라서 컴퓨터를 샀어요. 그 뒤로는…

Gergely Orosz: 그게 고등학교쯤?

Peter Steinberger: 한 14살이었을 거예요.

Gergely Orosz: 네.

Peter Steinberger: 그때부터 그냥 계속 뭔가를 만들어왔죠. 제일 처음 기억나는 건… 학교에서 DOS 게임 하나를 ‘훔쳐서’, 플로피 디스크에 복사 방지 같은 걸 만들어서 팔았어요. 로딩하는 데 2분 걸렸는데요. 그냥 늘 뭔가를 만지작거렸어요. 게임도 많이 했고요. 그런데 뭔가를 ‘만드는 것’도, 저한텐 게임하는 느낌이었어요. 솔직히 요즘은 Factorio보다 더 재밌어요.

처음엔 윈도우에서 배시 스크립트 비슷한 걸 만들고, 그다음엔 웹사이트도 했고요. 자바스크립트도 좀… 하긴 했는데, 솔직히 뭘 하는지도 잘 몰랐어요. 그러다 대학에 들어가면서 처음으로 “언어를 제대로 배우고 뭔가를 구축하는” 경험을 했죠.

저는 아버지를 한 번도 뵌 적이 없고, 집도 넉넉하지 않아서 늘 일을 해야 했어요. 학비도 제가 벌어서 내야 했고요. 남들 휴가 갈 때 저는 회사에서 풀타임으로 일했습니다. 첫 ‘진짜 직장’은 비엔나였어요. 원래 한 달짜리였는데, 6개월로 늘어나고… 군 복무랑 대학 사이를 잇는 다리 같은 일이었는데, 결국 5년쯤 다녔네요.

입사 첫날, 책 한 권을 줬는데 표지에 “Microsoft MFC”라고 적혀 있었어요. 아직도 악몽 꿔요. 진짜로요. “이건 너무 끔찍한데?” 싶어서… 다음 프로젝트부터는 그냥 조용히 .NET을 썼어요. 말도 안 하고요. 몇 달 지나서야 “기술 스택을 좀 현대화했어요”라고 했죠. 근데 그땐 이미 늦었어요. 저는 그 회사에서 이런 짓을 몇 번 했어요.

왜 저를 계속 뒀는지는 모르겠는데… 제 결과물이 잘 돌아가긴 했거든요. 그래서 .NET을 썼고, 사실 마음에 들었어요. .NET 2.0에 제네릭이 들어오던 시절이었죠. 다만 처음 실행할 때 JIT 때문에 앱이 미친 듯이 느렸어요. 하드디스크가 [드르륵…] 이런 소리 내면서요.

Gergely Orosz: 그럼 iOS는 어떻게 하게 됐고, PSPDFKit 아이디어는 어디서 나온 거예요?

Peter Steinberger: 사실 처음 아이폰은 오스트리아에 출시도 안 됐을 때였어요. 대학에서 친구가 아이폰을 보여줬고… 제가 한 1분 만져보더니 바로 샀어요. 딱 이렇게요. 손에 닿는 순간 ‘클릭’했어요. 저한텐 “와, 씨…” 싶은 순간이었죠. 너무 다르고, 너무 좋아서요.

근데 그때는 “이걸로 개발해야지”까지는 생각하지 않았어요.

Gergely Orosz: 2009년? 2010년쯤?

Peter Steinberger: 네, 그쯤이요. 아이폰 브라우저를 쓰다가… 지하철 안에서였어요. 그때 제가 데이팅 앱을 쓰고 있었는데, 그게 iPhone OS 2 시절이었죠.

긴 메시지를 막 썼어요. 감정도 좀 들어간 메시지였고요. 전송 버튼을 눌렀는데, 터널에 들어가면서… 자바스크립트가 전송 버튼을 비활성화시키고 에러가 뜨는 거예요. 근데 그땐 복사/붙여넣기가 없었어요. 스크린샷도 없었고요. 게다가 스크롤도 막혀버렸어요. 그 긴 메시지가 그냥… 사라졌죠.

저는 너무 열받았어요. “뭐야 이거?” 싶어서 집에 가자마자 Xcode를 받았죠. 그리고 Xcode 창을 열었는데… “IDE는 어디 있어?” 같은 느낌이었어요. 어쨌든, 이건 말이 안 된다 싶어서 웹을 ‘해킹’했어요. 정규식으로 HTML을 파싱했죠. 지금 생각하면 절대 하면 안 되는 방식인데요.

iPhone OS 3 베타를 쓰고, Core Data도 베타, RegexKitLite도 쓰고… Blocks를 쓰고 싶어서 GCC도 해킹 버전(Blocks 백포트)으로 깔았어요. 뭐가 돌아가기까지 꽤 오래 걸렸죠. 제가 뭘 하는지도 잘 모르고, 베타 기술을 이것저것 막 섞었으니까요. 그래도 결국 돌아가게는 만들었습니다.

그 회사에 메일도 보냈어요. “제가 앱을 만들고 있는데요, 어떠세요?” 답은 없었죠. 당연히. 그래서 그냥 앱스토어에 올렸어요.

Gergely Orosz: 그 데이팅 앱을 위한 앱이었죠?

Peter Steinberger: 네.

Gergely Orosz: API를 보고 클라이언트를 만든 거예요?

Peter Steinberger: API요? HTML이었는데요.

Gergely Orosz: 아.

Peter Steinberger: 그냥 HTML을 파싱한 거예요.

Gergely Orosz: 그럼 HTML을 위한 앱이었네요?

Peter Steinberger: 맞아요. 웹사이트를 스킨 씌운 거죠.

Gergely Orosz: 그게 꽤 성공했나 봐요.

Peter Steinberger: 네. 앱스토어에 올리고 5달러를 받았는데, 첫 달에 1만 달러 정도 벌었어요. 그땐 제가 뭘 하는지도 잘 몰랐고요. 세금/정산 같은 게 너무 복잡했어요. 초창기라 애플 쪽 폼도 이상한 게 많았고요. 그래서 그냥… 할아버지 통장으로 넣어버렸죠. 그러다 어느 날 할아버지가 전화해서 “애플에서 큰돈이 들어왔는데 이게 뭐냐?”라고 하시는 거예요. 저는 “그거 제 거예요! 손대지 마요!” 이랬고요.

그리고 이게 웃긴 게, 어느 날 클럽에 갔는데 누가 제 앱을 쓰고 있는 걸 본 거예요. 너무 자랑스러웠죠. 어깨를 툭 치고 “제가 만들었어요!” 하고 싶었는데… 너무 이상할 것 같아서 참았습니다.

그래서 5년 다니던 회사에 가서 “저 이거 계속 해볼게요. 너무 재밌어요”라고 했더니, 상사가 저를 막 비웃더라고요.

Gergely Orosz: 진짜요?

Peter Steinberger: “너 실수하는 거야. 이건 유행이야. 곧 끝나.” 뭐 이런 식이었죠. 미국식 표현으로는 ‘어깨 위에 칩을 올려놓은(chip on your shoulder)’ 상태가 됐달까요. “언젠가 당신 회사보다 더 큰 회사를 만들 거야.” 이런 오기가 생겼어요.

실제로 8년 걸렸죠. 저는 원래 좀 중독 성향이 있어서(지금도 그렇고요) 그 앱에 완전히 꽂혀서 엄청 달렸고, 엄청 빠르게 배웠어요. 그때 트위터도 시작했는데, 그게 제 커리어에 정말 큰 영향을 줬고요.

앱도 꽤 괜찮게 만들어놨는데… 어느 날 새벽 3시에, 술이 좀 오른 상태로 파티에 있다가 미국 번호로 전화가 온 거예요. “안녕하세요, 애플의 John인데요. 앱에 문제가 있습니다. 어떤 사진들이 신고됐어요.” 딱 그걸로 끝. 제 앱은 그렇게 끝났습니다.

Gergely Orosz: 좋을 때 끝났네요.

Peter Steinberger: 저는 그냥… 회사를 그만두고 “그래, 애플… 엿 먹어라.” 이런 마음이었죠. 프리랜서도 했고, “Dub Dub”(WWDC)에도 다녔고요. 거기서 또 소개를 받다가—

Gergely Orosz: “Dub Dub”은 WWDC죠.

Peter Steinberger: 네, 내부자 표현이었네요. 샌프란시스코에서 새벽 2시에 바에서 누군가가 저를 “오스트리아에서 제일 잘하는 iOS 개발자 중 한 명”이라고 소개해줬어요. 그렇게 미국에서 일할 기회가 생겼고, 잠깐 미국으로 가서 살게 됐죠.

Peter Steinberger: 그다음에 Nokia 개발자 행사 같은 것도 갔었는데… 지금 생각하면 석기시대죠. 하여튼 그때 동유럽의 누군가가 와서 “이 앱이 있는데 가끔 크래시나요”라고 했어요. 매거진 뷰어 앱이었죠. iPad가 막 나온 시절이고, 스티브 잡스가 “이건 구원이다” 이런 분위기였으니까 다들 매거진 앱 만들 때예요.

저는 “단기 프로젝트로 재밌겠네” 싶어서 도와주겠다고 했어요. 앱을 열어봤는데… 와, 제가 평생 본 구식 iOS 코드 중 최악이었어요. 파일 하나에 수천 줄이 들어 있고…

Gergely Orosz: Objective‑C였나요?

Peter Steinberger: 네. 탭 대신 윈도우를 탭처럼 쓰는 식이었는데, 저는 그런 게 가능한지도 몰랐어요. 그게 돌아간다는 게 신기했죠. 근데 진짜 종이집이라서, 한 군데 고치면 다른 데가 무너졌어요. 일단 좀 안정화는 시켜놨는데, 결국 “이건 미쳤다. 내가 다시 쓸게.”라고 했죠. 상대는 “근데 그거 반년 걸렸는데?”라고 했고, 저는 “한 달이면 돼요.”라고 했습니다. 실제로는 두 달 걸렸지만요. 그래도 크게 빗나가진 않았죠.

그렇게 해서 제가 PDF 뷰어를 만들기 시작한 거예요. 기술 문제라는 게… 도메인이 완전히 중요하지 않은 건 아니지만, 사실 어떤 도메인에서도 흥미로운 문제는 나오잖아요. PDF는 그게 아주 많았어요. C 함수 하나로 PDF를 렌더링하면 30MB를 잡아먹는데, 시스템 전체 메모리가 64MB였으니까요. 백그라운드에서 뭘 언제 어떻게 하느냐를 정말 조심하지 않으면 OS가 그냥 죽여버렸죠.

저는 “느낌”에 집착하는 편이에요. 화면 회전할 때 페이지가 애니메이션으로 부드럽게 넘어가야 한다든지… 그런 디테일요. 거기다 시간을 너무 많이 써서 한 달이 아니라 두 달이 됐지만, 결과는 좋았어요.

Gergely Orosz: 그러다 PSPDFKit으로는 어떻게 이어졌어요?

Peter Steinberger: 그 매거진 앱을 어느 정도 하고 나니까, 친구가 메시지를 보냈어요. “나도 매거진 앱 만들고 있는데 너무 어렵다.” 그래서 제가 “무슨 소리야, 나 방금 만들었는데.”라고 했죠.

그 친구가 “그 코드 좀 받을 수 있어?”라고 하길래, 제가 “그래.” 했어요. 그래서 그 매거진 앱에서 PDF 부분만 뽑아서 팔았죠. 다른 팀도 괜찮게 정리해둔 다음에요. 그리고 생각했어요. “한 사람이 원하면… 다른 사람도 원하겠는데?”

워드프레스 템플릿 하나 가져다 깃허브 페이지에서 돌아가게 ‘난도질’했고요. Fastlane 플로우 끝에 개인 Dropbox로 연결되는 소스 zip 링크가 떨어지게 만들어서, 하루 오후에 뚝딱 만들고 트윗했어요. 그 주에 3명이 샀고, 가격은 아마 200달러였을 거예요. 그때의 저한텐 엄청난 일이었죠.

그리고 더 재밌는 건… 산 사람 3명보다, “사고 싶은데 이 기능이 없네요”라며 불평 메일을 보낸 사람이 10명이었다는 거예요. 제가 딱 “너드 스나이프” 당한 거죠. “텍스트 선택이 안 되네요.” “그게 뭐 얼마나 어렵다고?” 했다가… 세 달 뒤에 “아, 이거 진짜 어렵네.”를 깨닫습니다.

Gergely Orosz: PDF에서 텍스트 선택 기능 말이죠.

Peter Steinberger: 네. “회사는 젊은 사람이 만든다. 얼마나 어려운지 몰라서.” 이런 말 있잖아요. 제가 딱 그랬어요. PDF라는 파일 포맷이 이렇게 미친 세계인 줄 몰랐죠.

Peter Steinberger: 얼마 전에도 누가 PDF 관련해서 도움을 요청했는데, 제가 이렇게 답했어요. “미안한데… 난 할 만큼 했어. 사람으로서 알 필요가 없는 수준까지 PDF를 알아버렸고, 치료까지 받았어. 행운을 빈다.”

근데 어쨌든 그 PDF 컴포넌트는 계속 잘 팔렸어요. 비자를 기다리면서 계속 만들었는데, 사람들이 계속 샀죠. 여름에 호숫가에 누워 있는데 “누가 600달러에 샀다”는 메일이 오고, 또 “800달러에 샀다”는 메일이 오고… 기능이 늘면 가격을 계속 올렸어요.

샌프란시스코로 그 회사에 일하러 갈 때쯤엔, 이미 그 회사에서 받는 월급보다 제 프로젝트가 더 벌고 있었어요. 그래도 저는 “그래도 회사에는 가야지” 같은 생각이 있어서 갔고요.

Gergely Orosz: 잠깐만요. 그럼 SF로 옮긴 거네요?

Peter Steinberger: 네. 그리고 그 회사에서도 결국 제 프레임워크로 뭔가를 만들게 됐어요. 근데 스타트업이 하루 8시간짜리 일이 아니잖아요. 더 오래 일하고, 제 개인 프로젝트도 더 오래 하고… 잠이 더 줄었죠.

3개월쯤 지나니까 매니저인 Sabine이 와서 묻더라고요. “Peter, 괜찮아?” 그리고 선택지를 줬어요. “회사 일을 계속하려면 네 프로젝트를 접어라” 혹은 “프로젝트를 계속하려면 회사를 그만둬라.” 결정할 시간은 1주일. 비자도 복잡한 상태라서, 남아있을 수 있는 카운트다운도 1주일이었고요.

근데 결정은 쉽더라고요. “그래, 난 내 걸 하고 싶어.”

Gergely Orosz: 그 시점이면 이미 ‘이거 큰 사업 되겠다’는 감이 있었겠네요. 미국에서 받던 연봉만큼은 벌 수 있겠다, 이런.

Peter Steinberger: 음… 저는 돈 때문에 한 건 아니었어요.

Gergely Orosz: 그럼 뭘로 움직였어요?

Peter Steinberger: 사람들이 “와…” 하고 감탄하는 걸 만들고 싶었어요. 저는 디테일을 만지는 걸 좋아해요. 작은 ‘기쁨 포인트’ 같은 거요. 경쟁사도 있었어요. 기능은 경쟁사가 더 많고, 더 오래됐고요. 근데 제 각도는 이거였죠. “애플이 만들었다면 이런 느낌으로 만들었을 거다.” 사랑과 신경, 폴리시, 그런 작은 디테일까지.

그래서 경쟁사가 기능이 훨씬 많았는데도, 제 회사가 더 잘 됐고 제 제품이 더 잘 됐어요. 개발자들이 여러 제품을 써보고, 결국 “이게 제일 느낌이 좋다”를 선택했으니까요. 저는 소프트웨어는 기능표보다 ‘느낌’이 더 중요하다고 생각해요. 우리가 왜 애플 제품을 사죠? 윈도우보다 기능이 많아서가 아니잖아요. 그냥 더 ‘좋게’ 느껴져서죠.

Gergely Orosz: 그럼 회사에서 나와서, 판매되기 시작한 PDF 컴포넌트를 만들고 있었잖아요. “이거 뭔가 된다” 싶어서 첫 사람을 뽑은 건 언제예요?

Peter Steinberger: 비엔나로 돌아갔을 때였어요. “이제 올인해야겠다” 싶어서 프리랜서들과 조금씩 일하기 시작했고요. 솔직히 말하면… 너무 늦었죠. 더 일찍 뽑았어도 됐는데, 사람 뽑는 건 큰 결정이니까요. 어쨌든 그때부터 이게 ‘자기 생명’을 갖기 시작했습니다.

저는 커리어 13년을 거의 이 제품에 쏟았어요. 그리고 이름이 참 이상한데… 진짜 5분 정도 고민하고 지은 이름을 안 바꿨어요. 그렇게 굳어버린 거죠. PSPDFKit. 나중에 리브랜딩도 하긴 했지만, 저는 솔직히 안 바꿨을 거예요.

Gergely Orosz: 발음하기도 어렵긴 한데, 엄청 유니크하긴 하죠.

Peter Steinberger: Objective‑C 해보면 이해돼요. 네임스페이스 같은 느낌이라서요.

Gergely Orosz: 그렇죠.

Peter Steinberger: 그리고 시간이 지나니까 오히려 말이 됐어요.

마케팅 전략은 늘 이거였어요. “나는 개발자만 본다.” 최종 의사결정은 위에서 해도, 내부의 개발자들을 설득하면 그 사람들이 저 대신 로비도 하고, 마케팅도 해주거든요. 실제로 그게 잘 먹혔어요. 콜드 메일 같은 거 안 했고, 공격적인 영업도 안 했고… 다 인바운드였죠. 우리는 그냥 좋은 걸 만들고, 기술 블로그를 진짜 깊게 쓰고, 컨퍼런스 많이 다녔어요.

핵심은… 사람들이 “이 제품 만드는 사람들은 진짜 아는 사람들이고, 이 일을 좋아하는 사람들이구나”를 느끼게 하는 거예요. 그게 제품에 그대로 묻어나니까요. 그게 잘 됐습니다.

Gergely Orosz: PSPDFKit의 기술 스택은 어땠어요? 처음엔 Objective‑C였나요? 나중에 Swift도 쓰고? C 같은 것도 있고?

Peter Steinberger: 결국 모든 플랫폼으로 확장했죠. 큰 전환점은 애플의 렌더러(지금도 여전히 버그가 많죠)를 빼고, 큰 C++ 렌더러로 바꾼 거예요. 그걸 여러 프레임워크에서 공통으로 썼고요. 웹도 정말 빨리 들어갔어요. 웹어셈블리로 돌아가는 PDF 프레임워크 중에서도 초창기였죠.

그리고 그때 제가 가장 ‘영리한’ 짓을 하나 했어요. 웹어셈블리가 막 뜨던 시기였는데, 우리가 벤치마크를 만들었거든요. 그 벤치마크를 구글, 마이크로소프트, 애플이 실제로 쓰게 됐어요. 그 결과… 그 회사들이 우리 렌더러를 더 빠르게 만들기 위해 엄청 열심히 최적화하는 상황이 된 거죠. 왜냐면 그 벤치마크가 “우리 렌더러로 우리 PDF를 렌더링하는” 거였거든요.

Gergely Orosz: 와, 좋네요.

Gergely Orosz: 회사가 커지면서 기억나는 게, PSPDFKit은 블로그를 정말 많이 썼잖아요. 2019년에 팀 운영 방식(기능은 항상 제안서로 시작한다, API가 크니 보수적으로 간다, Boy Scout rule로 리팩터한다 등)을 쓴 글도 있었고요. 30~60명 규모가 되면서 그런 문화를 어떻게 만들었어요?

Peter Steinberger: 저희가 지분을 정리할 때는 70명 정도였고, 지금은 거의 200명이라고 들었어요. 처음부터 “비엔나에서 내가 필요한 사람을 다 찾을 수는 없다”는 걸 알았죠. 그래서 기본은 remote‑first였고, 나중에 하이브리드 비슷한 걸로 가면서 조금 복잡해졌고요.

저는 솔직히 CEO가 되고 싶었던 사람은 아니에요. 늘 코딩하고 있었고요. 비즈니스 쪽은 저를 많이 도와준 사람이 둘 있었어요. 제가 못하는 건 아니고, 잘하긴 하는데… 즐기진 않아요. 예를 들면 엔터프라이즈 세일즈 콜 같은 거요. “마법의 숫자”를 정해야 하잖아요. 저 회사는 얼마까지 낼 것 같나, 이런 거. 하… 최악이죠.

Peter Steinberger: 근데 그게 그 모델에서는 또 유일하게 먹히는 방식이기도 해요.

Gergely Orosz: 엔터프라이즈 세일즈 얘기죠? 맞춤 가격. 개발자 입장에선 어떤 벤더 사이트 들어갔는데 가격이 없고 “전화하세요 / 미팅 잡으세요”만 있으면 짜증나잖아요. 왜 그런지 설명해줄 수 있어요?

Peter Steinberger: 그건… 회사 규모를 보고, 주사위를 굴려서 “이 정도면 낼 것 같은 숫자”를 정하기 때문이죠. 듣기엔 끔찍한데, 어떤 제품은 어쩔 수가 없어요. 프리랜서가 연락할 때랑 포춘 500이 연락할 때랑 가치도, 사용량도 다르잖아요. 같은 가격을 매기면 한쪽을 아예 배제하게 됩니다.

너무 싸면 “이거 뭐지?” 하고 조달 프로세스를 시작도 안 해요. 반대로 너무 비싸면 작은 고객은 다 떨어져 나가죠.

그래서 이 과정이 불공평하고 별로처럼 보여도, 어떤 타입의 제품에선 결국 가장 ‘공정한’ 방식이기도 해요.

그리고 소프트웨어에는… 저는 축이 네 개쯤 있다고 봐요. 쉽다/어렵다, 재밌다/안 재밌다. 우리는 딱 “안 재밌는데 어렵다” 영역이었어요. 모든 개발자가 ‘직접 만들고 싶어 하는 것’이면 팔기가 더 어렵고요. 개발자에게 뭘 판다는 것 자체가 어려운데, 너무 쉽거나 너무 재밌으면 더 힘들죠. 근데 “아, 나 이거 하기 싫다” + “근데 엄청 어렵다”면… 그건 좋은 자리예요.

저는 거기서 정말 좋은 니치를 찾았고, 복잡한 문제가 끝도 없이 나왔습니다.

Gergely Orosz: PDF 파싱이 그렇게 어렵다면서요. 스펙도 있고, 우리 엔지니어는 스펙 읽을 줄 아는데… 뭐가 그렇게 어려워요? 한두 가지 예를 들어줘요.

Peter Steinberger: 예를 들면 PDF에는 링크가 있잖아요. 목차에서 클릭하면 37페이지로 점프하는 그런 거요. 저는 “링크가 많아야 수십 개, 많아야 수백 개겠지”라고 가정하고 데이터 모델을 짰어요.

근데 어떤 고객이 돈도 꽤 많이 내고 들어왔는데, “PDF 로딩에 4분이나 걸린다, 뭐냐”라고 하는 거예요. 열어보니까 캐나다에서 온 5만 페이지짜리 텍스트 바이블이었어요.

Gergely Orosz: 5만 페이지요?

Peter Steinberger: 그리고 페이지당 링크가 100개가 넘었어요.

Gergely Orosz: 그럼 링크가 50만 개…

Peter Steinberger: 제 데이터 모델이 완전히 터졌죠. 제 가정이… 한 1,000배쯤 틀린 거니까요. 근데 이미 제품은 성숙해져 있고, 사람들이 쓰는 API도 있고요. 그럼 내부를 완전히 다시 설계하되, 바깥의 모든 걸 깨지 않고 어떻게 바꿔요? 예전엔 100개 파싱은 쉽게 eager로 했는데, 이제는 전부 lazy가 돼야 하죠.

이걸 “사용자들이 계속 쓸 수 있게” 유지하는 게 너무 어려웠어요. 그 일에만 두 달쯤 썼던 것 같아요. 내부를 완전히 갈아엎고, 동시에 사용자는 여전히 편하게 쓰게 만들고요. 사용자 입장에선 우리가 뭘 eager로 로드하고 뭘 lazy로 로드하는지 알 필요가 없잖아요. 복사 기능 같은 것도 여전히 연결이 유지돼야 했고요.

Gergely Orosz: 레퍼런스도 유지돼야 하고요.

Peter Steinberger: 맞아요. 저는 고객 지원도 정말 좋아했어요. 그리고 그게 회사가 잘 된 이유 중 하나였다고 생각해요. 티켓을 보냈는데 CEO가 답장해서 직접 도와주면… 그건 임팩트가 크죠.

제 전략은 항상 “역순 처리”였어요. 티켓 보내고 5분 안에 답장이 오면 그건 마법이에요. 하루 이틀 기다리면… 사실 크게 다르지 않거든요.

그리고 방금 그 문제는… 두 달을 달려서 거의 딱! 하고 맞춰냈을 때(손가락 ‘딱’ 하는 느낌으로요) 진짜 만족스러웠어요.

Gergely Orosz: 그 시절엔 본인이 코드를 엄청 많이 썼나요? 팀도 컸을 텐데요. 디테일을 리뷰하고, 전체를 보고.

Peter Steinberger: 좋은 팀이 있었고, 어떤 부분엔 제가 더 깊게 들어갔죠. 저는 늘 모바일 쪽에 더 마음이 갔고요. 하지만 기술 깊이로는 계속 들어가 있었어요. 마케팅/비즈니스 쪽은 Jonathan, Martin 같은 사람들이 도와줬고, 좋은 사람들을 찾았어요.

그리고… 흥미로운 어려운 문제를 어떻게 풀었는지 블로그로 쓰는 걸 좋아한다면, 그건 결국 같은 걸 좋아하는 사람들을 채용하는 데도 도움이 됩니다.

Gergely Orosz: 저도 기억나요. PSPDFKit 블로그가 가끔 Hacker News에도 올라오고, 읽을 때마다 재밌었어요. 저는 PDF에 엄청 관심 있는 사람은 아니지만, “PDF 하면 뭐 떠오르냐” 물으면 PSPDFKit이라고 했을 것 같아요. 최적화나 배포 같은 엔지니어링 글을 그쪽에서만 봤거든요.

그 글을 쓸 때 “이게 채용이나 홍보에 도움 되겠지” 같은 생각을 한 거예요? 아니면 그냥, 어려운 문제를 풀고 나서 기록하고 공유하는 게 좋아서?

Peter Steinberger: 저는 공유하고 사람들에게 영감을 주는 걸 좋아해요. 가끔 “이거 우리 비밀 소스 아니야?” 같은 논쟁도 있었죠. 근데 저는 그런 목소리를 크게 신경 쓰지 않았어요.

또 글을 쓰면, “내가 안다고 생각하던 걸” 진짜로 이해하게 되거든요. 누군가에게 가르치려면 더 깊이 이해해야 하니까요. 저한텐 “어려운 문제를 풀었으니, 보존하고 다른 사람에게도 도움이 되게 하자” 같은 느낌이었어요.

물론 관심 받는 건 좋죠. 근데 진짜로는… 1년 뒤에 제가 제 글을 다시 찾아보기도 했어요. “아 맞다, 이거 내가 이렇게 해결했지.” 회사 문서이기도 하고, 제 개인 로그북이기도 한 거예요. 여러모로 도움이 됐습니다.

큰 회사들은 규제가 너무 많아요. 그리고 개발자 중에는 글 쓰는 걸 별로 안 좋아하는 사람도 많죠. 그래서 저는 팀원들에게 “한 달에 한 번, 하루 통째로 블로그 글 쓰는 날”을 강제로 줬어요.

Gergely Orosz: 근데 시간을 준 거잖아요. “그날은 일하지 말고 글만 써라.”

Peter Steinberger: 맞아요. 하루면 글 하나 쓸 수 있잖아요. 사실 하루면 꽤 길어요. 요즘 제가 글을 쓰려 해도 몇 시간은 걸리니까요.

그리고… 회사 얘기를 너무 길게 하고 싶진 않은데, 저는 초창기가 제일 재밌었어요. 성장 단계로 들어가면 규칙도 늘고, 사람도 늘고, ‘와일드한 해킹’보다는 제품을 가꾸는 일이 훨씬 많아지죠. 반복적이고요. 시간이 지날수록 조금 덜 재밌어졌어요. 사람 드라마도 늘고요. 사람이 많아질수록 문제도 많아지니까요.

…그리고 저는 그걸 그렇게 즐기지 못했고, 정말 심하게 번아웃이 왔어요.

Gergely Orosz: 뭐가 번아웃을 만들었다고 생각해요?

Peter Steinberger: 그냥… 너무 태우면서 살았죠. 주말 대부분을 일했고요. 매니저로서 해야 할 것들을 어떻게든 다 처리하려고 버텼어요. 근데 CEO라는 역할이 있잖아요. basically “쓰레기통”이에요. 다른 사람들이 못 챙기거나, 못 하거나, 망친 건 결국 다 내 앞으로 와요. 그걸 다 제가 수습해야 하고요.

그리고 꽤 외로워요. 많은 걸 솔직하게 말할 수가 없거든요. 회사 문화를 최대한 오픈하게 만들려고 노력했지만, 그래도… 계속 부정적이면 안 되죠. 정말 안 좋은 일이 터져도요.

한 번은 공동창업자가 새벽 5시에 전화해서 이러는 거예요. “큰 항공사 고객이 있는데, 우리 소프트웨어가 크래시 나서 비행기들이 멈춰 섰다.” 그 주말이 정말… ‘흥미로운’ 주말이었습니다. 결국 그 고객이 우리 소스코드를 임의로 손대다가 라이선스 키 폴백을 건드려서 문제가 났다는 걸, 제가 그쪽 앱을 뜯어보며 증명해냈어요. 근데 그때는 진짜로 “이거 소송 당하면 회사 끝장” 같은 순간이었죠.

그런 일이 한두 번이 아니었고요. 어느 정도는 버틸 수 있어요. 근데 저는 번아웃이 꼭 “일을 많이 해서”만 오는 건 아니라고 생각해요. 적어도 저는… 내가 하는 일을 더는 믿지 못한다거나, 갈등이 너무 많을 때 더 빨리 타더라고요.

우리도 경영진 레벨에서 갈등이 많았고요. 제가 “회사는 좀 더 민주적으로 운영해야 한다” 같은 판단을 했던 게 오히려 어려움을 키운 면도 있었어요. 그래도… 그 시간을 세상 그 무엇과도 바꾸고 싶진 않아요.

Gergely Orosz: 바깥에서 보면요. 지분을 정리했고, 원하면 더는 일하지 않아도 될 정도의 돈도 벌었고… 많은 사람들에겐 꿈같은 이야기죠. 벽을 오르다 종을 치면 “끝”인 것처럼요. 근데 제가 봤을 때, 당신 블로그 글이 몇 년 동안 완전히 멈췄잖아요. 그 시간 동안 뭘 했어요? 그리고 그 시간에서 뭘 배웠어요? 지금으로 돌아오기 전에요.

Peter Steinberger: 회복하는 시간이 정말 필요했어요. 놓쳤다고 생각했던 것들을 많이 따라잡았고, 파티도 많이 했고요. 몇 달은 컴퓨터를 아예 켜지도 않았어요.

한동안은… “이제 뭘 하지?”라는 감각이 사라졌어요. “왜 굳이?” 같은 생각이 들었죠. 너무 이르게 은퇴한 느낌이랄까, 너무 좋은 엑싯을 해버려서 다시는 일 안 해도 되는 상황… 그게 제 머리를 꽤 흔들어놨어요. 힘든 몇 년이었습니다.

그러다 어느 4월, 예전에 몇 년 전부터 갖고 있던 아이디어가 떠올랐어요. 예전에 시작해둔 사이드 프로젝트도 있었고요. “아, 이거 다시 해볼까?” 하고요. 3년 넘게 지나서 다시 컴퓨터 앞에 앉아 해킹을 시작했습니다.

근데 그 프로젝트가 트위터 분석 같은 거였는데, Swift/SwiftUI로 되어 있었거든요. 그리고 저는 이미 알고 있었어요. “이건 웹으로 만드는 게 훨씬 나았을 텐데…”

Gergely Orosz: 원래 마음속에 있던 아이디어였군요? 트위터 분석 같은?

Peter Steinberger: 네. 그냥 제가 쓰고 싶어서 만들고 싶었던 건데… 없었거든요. 3년이 지나도 없었어요. 아직도 없고요. 비슷한 건 있긴 한데, 저는 좀 다른 데로 샜죠.

그래서 웹으로 만들고 싶었는데, 웹은 제가 회사에서도 제일 덜 본 영역이었어요. 회사에 그쪽을 정말 잘 맡아주던 사람이 있었거든요(제가 데려온 Martin). 그래서 저는 크게 걱정할 일이 없었죠.

Gergely Orosz: 그럼 React 같은 건 손에 안 익었겠네요?

Peter Steinberger: 네. 저는 돌아와서 “prop이 뭐지?” 이 수준이었어요.

그리고 이건 많은 개발자들에게 있는 함정인데요. 한 기술을 깊게 잘할수록, 다른 쪽으로 옮기기가 더 어려워져요. 못 옮긴다는 게 아니라… 너무 아파요. 애플 스택에서는 눈 감고도 코딩할 수 있는데, 다른 스택으로 가면 가장 사소한 것까지 구글링해야 하고, 그게 진짜… 아프죠. 다시 바보가 된 느낌이 들어요.

Gergely Orosz: 경험이 많을수록 그게 더 싫죠. “내가 더 빠르게 할 수 있는데”라는 감각이 있으니까.

Peter Steinberger: 맞아요. 그래서 돌아와서 생각했어요. “대체 이 AI라는 게 뭐지? 사람들이 다 무시하던데… 한 번 봐야겠다.”

Gergely Orosz: 그 4월 무렵, 많은 사람들이 실제로 무시하긴 했죠.

Peter Steinberger: 그리고 솔직히… 그 3년 동안 제가 컴퓨터를 거의 안 켠 덕을 봤다고도 생각해요. 그 기간 동안 여러분이 AI를 써보고 “이거 별로다”를 이미 겪었잖아요.

Gergely Orosz: 그러니까 당신은 GitHub Copilot 베타(일종의 자동완성) 같은 것도 건너뛰었고, GPT‑3/3.5/4로 점진적으로 좋아지는 과정도 그냥 통째로 스킵한 거네요. 그래서 돌아왔을 때 처음 잡은 도구가 뭐였어요?

Peter Steinberger: Claude Code요.

Gergely Orosz: Claude Code로 시작했군요.

Peter Steinberger: 그게 아마…

Gergely Orosz: 5월에 정식으로 나왔고, 그 전에 베타가 있었죠?

Peter Steinberger: 2월쯤 이미 뭔가 있었던 것 같은데…

Gergely Orosz: 맞아요. 2월부터 베타가 있었어요.

Peter Steinberger: 네. 그래서… 제가 공백기를 끝내고 돌아오자마자, 바로 Claude Code를 켰고 그 전 단계는 다 건너뛴 셈이죠.

제가 했던 게 이런 거예요. 예전에 만든 지저분한 사이드 프로젝트가 있었고, GitHub 레포를 “하나의 큰 마크다운”으로 바꿔주는 브라우저 확장이 있었거든요. 그게 1.3MB짜리 마크다운 파일이었어요. 그걸 Google AI Studio에(당시 Gemini 1.5 혹은 2.x) 드래그해서 넣고 “스펙을 써줘”라고 했어요. 그러니까 400줄짜리 스펙이 나왔죠.

그 스펙을 다시 Claude Code에 넣고 “빌드해”라고 했습니다. 계속 계속… 그러다 어느 순간 “100% production ready”라고 말하더라고요. 실행했더니… 바로 크래시 났죠.

Peter Steinberger: 그래서 저는 MCP를 하나 붙여서 브라우저를 쓸 수 있게 했어요. Playwright MCP였던 것 같고요. 몇 시간 더 루프를 돌렸죠. 그러더니 트위터 로그인 페이지가 하나 나오더라고요. 엄청 훌륭하진 않았지만, 어쨌든 뭔가가 ‘나왔어요’.

그 순간이 제겐 진짜… “와, 씨…” 하는 순간이었어요. ‘되긴 되네?’가 아니라, ‘아, 이게 앞으로 갈 방향이 이거구나’가 보였거든요.

Gergely Orosz: 그게 올해 4~5월쯤이죠?

Peter Steinberger: 네. 그땐 딱 “가능성이 보일 정도”였어요. 그리고 그때부터 몇 달 동안 잠을 정말 못 잤어요.

Gergely Orosz: 그 얘기 기억나요. 한 번은 트위터에서 DM을 보냈는데요. 저는 애 때문에 어쩔 수 없이 일찍 일어난 거였는데, 새벽 5시에 메시지를 보냈더니 당신이 바로 답장을 했어요. 그래서 “왜 안 자요?”라고 했더니, “보통 이 시간엔 아직 깨어 있다”고 했죠. 왜냐고 물었더니 “Claude 쓰느라 너무 중독적이다”라고 했고요.

“진짜로 그렇게 중독적이야?” 했더니 “농담 아니야. 너무 좋아”라고 했던 것 같아요. 그리고 “프롬프트를 딱 한 번만 더 쳐보고 싶다(‘한 번만 더’)” 같은 말도 했고요. 뭐가 그렇게 중독적이에요? 아직도 그래요?

Peter Steinberger: 카지노랑 똑같은 경제학이에요. 제 작은 슬롯머신이죠. 레버를 당기면 딩딩딩딩… 하다가 “꽝”. 프롬프트를 치면 (타닥타닥…) 하고, 결과가 쓰레기일 때도 있어요.

근데 가끔은… 진짜로 머리를 날려버리는 결과가 나와요. 그게…

Gergely Orosz: 당신은 엄청 경험 많은 개발자잖아요. 쉽게 “와, 미쳤다”가 나오기 어렵죠. 나쁜 코드/괜찮은 코드/좋은 코드, 그런 기준이 확실할 텐데요.

Peter Steinberger: 재밌는 게… 저는 회사 운영할 때 디테일에 집착했어요. 간격, 줄바꿈, 네이밍… 말도 안 되게 ‘자전거 타기(바이크셰딩)’를 했죠.

지금 생각하면 “내가 왜 그랬지?” 싶어요. 고객은 내부를 보지도 않잖아요. 물론 일정 수준의 기준은 필요하죠. 제대로 동작해야 하고, 빨라야 하고, 보안도 되어야 하고요. 근데 제가 했던 바이크셰딩은… 솔직히 좀 어이없을 정도였어요.

Gergely Orosz: 근데 또 방금은 “PSPDFKit이 제일 폴리시가 좋고 잘 돌아가서 사랑받았다”고도 했잖아요. 그 ‘집착’이 단순히 공백/줄바꿈이 아니라, 테스트나 위생 같은 것까지 포함해서 제품의 품질과 성능을 만든 거 아닌가요?

Peter Steinberger: 어느 정도는 맞아요. 그리고 지금도 저는 구조를 엄청 중요하게 생각해요.

제 마지막 블로그 글이 사실 “읽지 않은 코드를 배포한다”는 고백이었거든요.

Gergely Orosz: 그 얘기 꼭 해야죠.

Peter Steinberger: 동시에 저는 구조를 바꾸는 데도 엄청 시간을 써요. 이를테면… 최근에 어떤 프로젝트에서 1만 5천 줄짜리 PR을 정말 넣고 싶었어요. 전체를 플러그인 아키텍처로 옮기는 변화였고, 저는 그게 너무 신났죠. 구조는 정말 중요하거든요.

근데 제가 코드를 전부 읽었냐? 아니요. 왜냐면 코드의 상당 부분은 결국 눈에 잘 안 보이는 ‘연결 작업’(plumbing)이라 지루하거든요.

대부분의 앱이 뭐죠? API에서 어떤 형태로 데이터가 들어와요. 파싱하고, 다른 형태로 포장하고, DB에 또 다른 형태로 저장하죠. 다시 꺼내면 또 다른 형태. 프런트로 나가면 HTML이든 뭐든 또 다른 형태. 사용자가 타이핑하면 또 다른 형태. 결국 우리는 앱 전체에서 “데이터 형태를 마사지”하는 일을 계속해요. 대부분의 앱은 사실상 JSON 프린터죠.

그리고 진짜 어려운 부분은… 사실 Postgres가 30년 전에 이미(‘목 긴 수염 아저씨들’이) 해결해둔 것도 많고요. 물론 항상 흥미로운 부분은 있지만, 버튼 정렬이 어떻고 Tailwind 클래스가 뭐고… 그런 디테일은 지루한 게 많아요. 흥미로운 디테일도 있고요.

근데 결국 중요한 건 “모든 라인을 다 읽느냐”가 아니라, 시스템 아키텍처에 더 가깝다고 생각해요.

Gergely Orosz: 좋아요. 그럼 이제, Clawdbot을 만들 때 워크플로는 어떻게 돼요? 터미널을 쓰나요, 터미널을 여러 개 띄우나요? 어떤 도구를 쓰고, “코드를 다 안 읽는다”면서도 아키텍처는 어떻게 생각하나요? 누군가 팀에 합류한다고 했을 때, “우리는 이렇게 일해요”를 설명한다면요?

다음 편(2편)에서는 방금 이 질문부터 그대로 이어서, Peter가 말하는 “에이전트식 개발”을 실제 워크플로 관점에서 차근차근 풀어볼게요.