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

Gergely Orosz: 그럼 이제, 현재 워크플로를 좀 들어가볼게요. Clawdbot 작업할 때 터미널을 쓰나요? 여러 개 띄우나요? 어떤 도구들을 쓰고요? “코드는 예전만큼 안 읽는다”면서도 아키텍처는 여전히 생각한다고 했잖아요. 평균적인 하루가 어떤 식으로 굴러가요? 누군가 팀에 합류한다고 했을 때 “우린 이렇게 일해요”라고 설명한다면요.

Peter Steinberger: 재밌는 질문이네요. 흐름을 조금만 되짚어보면… 4월에 Claude Code를 쓰면서 시작했거든요. 그때 완전 제대로 꽂혔어요. 그 다음엔 Cursor도 한동안 써보고, Gemini 2.5도 좀 써보고, 또 Opus 4 쪽으로 갔다가… 막 이것저것 거쳤죠.

그러면서 친구들도 많이 끌어들였어요. 비엔나에 있는 Armin이랑 Mario도 결국 “AI에 제대로 물든” 케이스고요. 제가 너무 흥분해서 떠드니까 처음엔 다들 “쟤 왜 저래?” 하다가, 막상 써보더니… 결국 새벽 5시에 다들 깨어 있더라고요. 저는 그걸 ‘다크서클 클럽(black eye club)’이라고 불렀어요.

런던에선 “Claude Code Anonymous” 같은 모임까지 만들었는데, 진짜 약간… 마약 같거든요. 너무 재밌어서요.

제 머리를 제일 세게 때린 건 이거였어요. “이제는 그냥, 다 만들 수 있구나.” 예전엔 소프트웨어가 너무 어려우니까 사이드 프로젝트도 ‘뭐 하나만’ 골라서 해야 했잖아요. 지금도 어려운 건 맞는데, 이제는… 예를 들어 “Go로 CLI를 만들자” 이러면, 제가 Go를 하나도 몰라도 가능해져요.

물론 시스템 감각은 있어야 해요. 그리고 그 감이 생기면 “이건 맞다/이건 아니다”가 느껴져요. 어떤 트윗에서 “코드를 쓸 때 마찰이 느껴지고, 그 마찰이 좋은 아키텍처를 만든다”는 얘길 본 적이 있는데, 저는 프롬프트를 칠 때도 같은 마찰을 느껴요.

코드가 쭉쭉 지나가는 걸 보고, 얼마나 오래 걸리는지 보고, 에이전트가 버티는지(푸시백) 보고, 결과물이 지저분한지/말이 되는지 보고… 프롬프트를 칠 때 대충 ‘이 정도면 이만큼 걸리겠다’가 있거든요. 그런데 예상보다 훨씬 오래 걸리면, “아, 내가 뭔가 잘못 던졌구나”를 알아차려요.

Gergely Orosz: 그러니까 모델을 ‘느끼는’ 거네요. 보통이면 이런 리듬인데, 이러면 뭔가 꼬였다… 같은.

Peter Steinberger: 네. 저는 이게 거의 공생(synergy)이라고 느껴요. 제가 “그들의 언어”를 더 잘하게 됐고(어떤 의미로는 ‘죽은 언어’ 같기도 하고요), 모델도 좋아졌고요. 4월부터 지금까지의 시간에서, 여름 즈음이 확실히 변곡점이었어요. 손으로 코딩을 안 해도 소프트웨어를 만들 수 있을 만큼 좋아졌거든요.

근데 결정적으로 저를 설득한 건… 제가 “라인을 쓰는 사람”보다는 “아키텍트에 가깝다”는 깨달음이었어요.

Gergely Orosz: ‘아키텍트’라는 단어를 쓰는 게 흥미롭네요. 90년대식 “대문자 A 아키텍트”라는 개념이 있었잖아요. 은행 같은 데 아직도 있고요. 아키텍트는 UML 그려주고 DB 스키마 그려주고, 개발자에게 던져주고, 결과가 이상하면 “너희가 잘못 구현했네”라고 말하는… 다들 싫어하는 모델. 피드백 루프가 끊겨 있으니까요. 근데 당신이 말하는 건 그거랑은 좀 다른 것 같기도 하고요.

Peter Steinberger: 저는 ‘아키텍트’보다 ‘빌더(Builder)’라는 말이 더 좋아요.

Gergely Orosz: 빌더.

Peter Steinberger: 왜냐면 저는 완전히 책임을 져야 하거든요.

Gergely Orosz: 예전식 ‘아키텍트’가 코드에서 멀어지고 책임도 멀어지는 모델이었다면, 당신은 에이전트들을 두고도 여전히 결과에 책임을 지는, 좀 이상한(?) 형태의 “아키텍트/빌더”처럼 보이긴 해요.

Peter Steinberger: 맞아요. 그리고 AI를 잘 쓰는 사람/힘들어하는 사람을 보면, 대충 패턴이 있어요.

저는 “결과물”을 더 중요하게 봐요. 제품, 느낌. 물론 내부의 ‘연결/인프라 코드’(plumbing)도 큰 구조에서는 봅니다. 근데 아주 디테일하게 “이 한 줄이 왜 이래야 해” 이런 건 덜 봐요.

반대로 알고리즘이나 ‘어려운 문제 푸는 코딩 자체’를 좋아하는 사람들은, 오히려 지금 힘들어해요. AI가 그쪽을 제일 잘 해버리니까요.

저는 올해 아키텍처/설계 쪽에서 지난 5년보다 더 많이 배웠다고 느껴요. 저 “괴물”들 안엔 지식이 너무 많고, 진짜로 ‘질문 한 번’이면 답이 나와요. 단, 무슨 질문을 해야 하는지는 알아야 하고요.

저도 트위터 분석 프로젝트를 만들었는데 아직 완성은 못 했어요. 한동안 “쓰다 보면 느려지고 이상해졌다가 다시 빨라지고” 이런 버그가 있었거든요. 재현도 어렵고요. PSQL(Postgres) 쪽에서 어떤 insert가 트리거를 타면서 DB가 바빠지는 부작용이었는데, 모델이 그걸 못 봤어요. 너무 멀리 추상화돼 있었고, 연결이 안 보였거든요.

근데 어느 순간 제가 “이거 혹시 부작용 있나?”라는 올바른 질문을 던지니까 딱 나오더라고요. 결국 다 ‘올바른 질문’의 문제인 경우도 많아요.

Gergely Orosz: 그러려면 결국 경험과 지식이 필요하죠.

Peter Steinberger: 네. 맞아요.

Gergely Orosz: 그리고 팀을 운영해본 경험이 AI와 일하는 데도 도움이 된다는 얘기도 했었죠. “완벽한 코드”에 집착하기보다, 목표에 가까워지게 만들어야 한다… 이런.

Peter Steinberger: 딱 그거예요. 팀을 운영하면 모든 걸 내 스타일로 만들 수 없잖아요. 어느 정도는 “이게 내 이상형은 아니지만, 목표로 가는 데 도움 된다”를 받아들이게 되죠.

Claude Code로 작업할 때도 비슷했어요. 약간… 가끔은 엉성하고 가끔은 천재적인 엔지니어들이 옆에 있고, 제가 그걸 ‘스티어링’하는 느낌. 다시 “사장”이 된 기분이기도 했고요.

Gergely Orosz: 당신은 AI 이전에도 15년 넘게 전통적인 방식으로 소프트웨어를 만들었고, 팀을 이끌었고, 기준도 높았잖아요. 그런데 지난 1년은 에이전트랑 같이 작업하는 방식으로 일했고요. 뭐가 바뀌었고, 뭐가 그대로예요?

Peter Steinberger: 일단… 저는 “vibecoding”이라는 말이 싫어요.

Gergely Orosz: 그럼 뭐라고 불러요?

Peter Steinberger: 이제는 거의 ‘비하 표현’처럼 들리거든요. 저는 “Agentic Engineering”이라고 불러요. (별표 하나 붙이고요.) “vibecoding은 새벽 3시부터 시작된다” 이런 농담도 하고요.

지금은 코드 쓰는 일의 ‘평범한 부분’이 자동화돼서 훨씬 빨리 움직일 수 있어요. 근데 동시에, 생각해야 하는 양도 훨씬 늘어요.

저는 여전히 몰입(flow) 상태를 타요. 그 느낌은 예전이랑 똑같아요. 근데 정신적으로는 더 힘들어요. 예전엔 직원 한 명을 관리했다면, 지금은 5명, 10명 같은 에이전트들이 동시에 일을 하거든요. 이거 했다가 저거 했다가, 계속 머릿속에서 왔다 갔다 해요.

예를 들어 새 서브시스템을 설계한다고 치면, Codex가 40분~1시간은 “굽고(cook)” 있을 거잖아요. 그럼 저는 계획을 세워서 던져두고, 다른 걸 하러 가요. 저쪽이 돌아가고, 이쪽도 돌아가고, 또 저쪽도 돌아가고… 어느 순간엔 몇 개가 동시에 돌아가고요. 그 사이를 계속 점프합니다.

솔직히 이거 안 하고 싶어요. 근데 지금은 “빠른 몰입”을 유지하려면 병렬화를 많이 해야 하거든요. 언젠가는 모델이 너무 빨라져서 덜 병렬로도 될 거라고 믿고요.

보통은 메인 프로젝트 하나가 있고, 위성(satellite) 프로젝트들이 몇 개 더 있어요. 위성 프로젝트는 제가 5분 던져두면 30분 돌아가고, 저는 다시 와서 확인하고… 이런 식.

Gergely Orosz: 뭔가… 직원들 관리하는 요리 게임 같은 느낌도 나고요. 오더가 쏟아져서 계속 뛰어다니는.

Peter Steinberger: 저는 오히려 스타크래프트에 더 가까워요. 메인 베이스 하나 있고, 자원 캐는 사이드 베이스들이 있는.

Gergely Orosz: 또 하나 떠오르는 비유가 있어요. 체스 그랜드마스터가 20판 동시 대국할 때요. 여기 보고 바로 판단하고, 저기 보고 바로 판단하고… 어떤 판은 더 오래 보고요. 뇌를 100% 쓰면서 컨텍스트 스위칭으로 ‘스케일링’하는 느낌.

Peter Steinberger: 맞아요.

그리고 Claude Code 시절에는 좀 달랐어요. 더 빠르긴 한데 첫 시도에 잘 안 맞는 경우가 많았거든요. 뭔가를 만들긴 하는데, 세 군데 업데이트를 빼먹어서 크래시 나고… 그래서 제가 다시 가서 고쳐주고… 이런 반복이 필요했죠. 결국 총 소요 시간이 그렇게까지 줄진 않아요. 다만 훨씬 “인터랙티브”해졌죠.

근데 요즘 Codex는 거의 항상 맞춰줘요. 제 일반적인 전략은 이거예요. 기능을 만들고, 테스트도 쓰게 하고, 테스트를 실제로 돌리게 한다.

Gergely Orosz: 테스트를 돌리는 거까지요.

Peter Steinberger: 네. 예를 들면 맥 앱 디버깅도… 어제도 맥 앱이 어떤 원격 게이트웨이를 못 찾는 버그가 있었어요. 같은 TypeScript 코드는 잘 되는데 맥 앱만 안 되는 거죠. 맥 앱은 디버깅 루프가 느려요. 빌드하고, 실행하고, 보고, “아니야 이거 안 돼” 하고…

그래서 저는 아예 “디버깅용 CLI를 만들어서 동일한 코드 경로를 호출하게 해”라고 시켜요. 그러면 빠르게 반복하면서 잡을 수 있거든요. 그랬더니 한 시간 정도 굽더니, “여기 레이스 컨디션이 있었고, 여기 설정이 잘못됐고…” 이런 식으로 알려주더라고요. “응, 말 되네.” 하고 저는 코드를 굳이 안 봐요.

Gergely Orosz: 검증 루프를 만들어놨고, 테스트가 실제로 돌았으니까 신뢰하는 거군요.

Peter Steinberger: 맞아요. 그리고 제 아주 최신 프로젝트에서도, 예를 들어 anti-gravity 쪽에선 툴 콜 포맷이 좀 이상한 구석이 있어서 필터링이 필요했거든요. 그게 여기저기 깨졌고요.

근데 한참 지나서야 “내가 지금 뭐 하는 거지? 자동화하면 되잖아”를 깨닫고, Codex에 이렇게 시켰어요.

“Docker 컨테이너 띄우고, 전체 설치하고, 루프 돌리고, 이 파일에서 API 키들 읽어서, 모델에게 이미지 읽게 하고, 이미지 생성하게 하고, 다시 그 이미지를 보고 뭐가 보이는지 확인하게 해. 툴콜까지 포함해서 ‘되게 만들어’.”

그랬더니 시간이 오래 걸리긴 했는데, Anthropic 키부터 SAT[?], GLM… 전부 테스트해보고, 툴콜이 안 맞거나 순서가 꼬이던 잔버그들을 다 잡아내더라고요. 제가 루프를 닫아줬으니까요. 그게 비결이에요.

Gergely Orosz: “closing the loop”라는 건, 에이전트가 스스로 결과를 검증할 수 있게 만든다는 거죠?

Peter Steinberger: 네. 그래서 지금 모델들이 코딩은 엄청 잘하지만, 창작 글쓰기는 가끔 애매한 거예요. 글은 검증하기 어렵잖아요. 근데 코드는 검증이 가능해요. 컴파일하고, 린트하고, 실행하고, 출력 확인하고.

제대로 설계하면 완벽한 루프를 만들 수 있어요. 웹도 마찬가지예요. 브라우저 루프는 너무 느리니까, 핵심은 CLI로 돌릴 수 있게 만들어서 실행 루프를 빠르게 잡는 거죠.

Gergely Orosz: 생각해보면 AI 이전에도, 백엔드나 비즈니스 로직은 원래 검증이 쉬웠죠.

Peter Steinberger: 웃긴 얘긴데요. 에이전트식 코딩을 하면 오히려 더 좋은 코더가 돼요. 검증이 쉬운 구조를 만들기 위해 아키텍처를 더 빡세게 생각하게 되거든요. “검증”이 품질을 만드는 길이라서요.

Gergely Orosz: 복잡한 시스템 만들 때, 예전에도 제일 먼저 생각하던 게 “테스트 가능하게 설계하기”였죠. 인터페이스를 어떻게 나눌지, mock을 쓸지, E2E를 쓸지… 한 번 결정하면 바꾸기 어렵고요.

Peter Steinberger: 소프트웨어는 여전히 소프트웨어죠.

근데 저는 요즘 “제가 직접 코드를 안 쓰기 때문에 오히려 더 좋은 코드를 쓴다”고 느껴요. 예전에도 좋은 코드를 썼다고 생각하지만요.

회사 시절엔 테스트가 너무 귀찮았어요. 엣지케이스가 끝도 없고, 분기만 늘어나고요.

Gergely Orosz: 사실 저도 테스트 좋아하는 편은 아니었거든요. 문서랑 테스트는… 제겐 “창작”이 아니라 “의무”였어요.

Peter Steinberger: 지금은 진짜 좋아졌어요. 제 최근 프로젝트들 보면 문서가 정말 좋은데, 저는 한 줄도 직접 안 썼어요.

테스트도, 문서도 제가 직접 쓰는 게 아니라, 제가 트레이드오프를 설명해요. “왜 이렇게 했는지”를 말해주고, “입문자 친화적인 도입부를 쓰고, 뒤에는 더 기술적으로 깊게 써”라고 시키죠. 그러면 너무 잘 나와요.

그리고 테스트는 이제 제 사고 흐름에 들어왔어요. “이거 만들었으니, 어떻게 검증하지?”를 항상 먼저 생각하게 돼요. 더 잘 테스트되게 설계를 바꾸기도 하고요. 결국 또 “closing the loop”로 돌아옵니다.

Gergely Orosz: 그런데도 여전히 많은 숙련 개발자들이 반발하잖아요. 왜라고 봐요?

Peter Steinberger: 얼마 전 Maciej Ceglowski(*Idlewords*)의 글을 봤는데, 제가 정말 존경하는 사람이거든요. 근데 그 글은 “요즘 모델은 별로다”라는 취지였어요.

그가 한 건 대충 이런 거였죠. 여러 모델을 테스트했고, 어떤 건 말도 안 되는 모델(예: OpenAI 120B 오픈소스)도 포함돼 있었고요. 그리고는 Claude 웹에 프롬프트 하나 던지고, 결과를 실행했더니 컴파일이 안 됐고, 그래서 실망했다… 이런 흐름으로 보였어요.

근데 당연히 안 되죠. 제가 버그 없는 코드를 첫 시도에 쓰나요? 모델도 첫 시도에 안 맞을 수밖에 없어요. 그럼 뭘 해야 하냐? 피드백 루프를 닫아야죠.

그리고 프롬프트 한 번 던지고 끝이 아니에요. 대화를 시작해야 해요. “내가 뭘 만들고 싶은지”부터요.

예를 들어 “옛 API를 썼다”라고 불평했는데, 그럼 macOS 버전을 지정했나요? 안 했잖아요. 정보가 없으면 모델은 옛 API를 기본값으로 가정할 수밖에 없어요. 학습 데이터도 최근 2년치만 있는 게 아니라, 오래된 데이터가 훨씬 많고요.

이런 걸 이해할수록 프롬프트도 더 잘하게 됩니다. 근데 그는 아마 하루 정도 만져보고 “아직 별로네”라고 결론 낸 것처럼 보였어요.

그건… 기타 치는 사람을 피아노 앞에 앉혀놓고 “조금 해보니 별로네, 기타가 낫다”라고 하는 거랑 비슷해요. 이건 다른 방식의 ‘빌딩’이에요. 다른 방식의 ‘생각’이에요.

저도 새벽 3시에 Claude Code한테 소리 지른 적 얼마나 많은데요. 그러다 “아, 얘가 내가 말한 대로 정말 문자 그대로 해석하는구나” 같은 걸 배우죠. 가끔은 “너 이걸 이렇게 해석했구나?”를 물어볼 수도 있고요.

그리고 Clawdbot 같은 프로젝트를 하다 보면, 저는 사람 머지 버튼 같아요. 커뮤니티는 터지고, 저는 PR만 검토하고… 코드를 직접 쓸 시간이 거의 없어요. 초반엔 PR을 체리픽만 하고 닫아버리는 경우도 많아서, 제가 “아니, 왜 그래?” 하고 짜증 낸 적도 있어요.

근데 그때 모델이 “당신이 이렇게 말했으니까, 저는 이렇게 해석했어요”라고 설명해주더라고요. “아…” 하고, 제가 머신의 언어를 조금 더 배우고, 프롬프트를 조정하니 이제는 원하는 결과가 나오기 시작했고요. 다른 스킬이랑 똑같아요.

Gergely Orosz: 그럼 가정 하나 해볼게요. 지금 Clawdbot은 수익을 내는 비즈니스는 아니지만 사용자도 많고 터지고 있어요. 만약 PSPDFKit이 오늘 사라졌고, 당신이 에이전트들을 가지고 PSPDFKit을 다시 만들어야 한다면? 얼마나 다르게 만들까요? 무엇을 위임하고 무엇을 검증할까요? 팀 구성도 달라질까요?

Peter Steinberger: 사람 수로만 보면… 지금의 30% 인원으로도 회사는 굴릴 수 있을 것 같아요. 다만 그 수준의 사람을 찾기가 정말 어렵겠죠.

원하는 사람은 “엄청 시니어인데, 위임도 편하게 하고, 뭐가 중요한지/뭐는 대충(vibe) 넘겨도 되는지”를 아는 사람이에요. 근데 그런 사람을 많이 못 봤어요.

특히 AI 쪽은 트위터에 쓰레기가 너무 많아요. 목소리는 큰데 뭘 하는지 모르는 사람들이요.

이상한 ‘개념’도 너무 많고요. 미안하지만 “Ralph Wiggum” 같은 거요… 으. 그건 Opus의 한계를 우회하려고 만든 또 다른 ‘꼼수’ 같은데, Codex 쓸 때는 필요도 없어요. 물론 아주 긴 태스크 리스트를 자동화하는 일부 케이스는 있을 수 있는데, 보통 소프트웨어 개발은 그렇게 돌아가지 않잖아요.

저는 사람들이 엄청 복잡한 오케스트레이션 레이어를 만드는 걸 보면 잘 이해가 안 가요. 자동으로 티켓 만들고, 에이전트가 티켓 처리하고, 다른 에이전트에게 메일 보내고… 점점 거대한 난장판이 되죠. 왜요?

“몇 시간 동안 스펙을 설계하면, 하루 만에 기계가 다 만들어줘요.”

…저는 이게 잘 된다고 믿지 않아요. 이건 소프트웨어 개발의 워터폴 모델이잖아요. 우리가 오래전에 “이거 안 된다”는 걸 배웠는데요.

물론 사람마다 방식이 다르니까 어떤 사람에겐 될 수도 있겠죠. 근데 저는 안 맞아요.

저는 아이디어에서 시작해야 하고, 오히려 일부러 “덜 프롬프트”를 던져서 에이전트가 엉뚱한 걸 내게 만들기도 해요. 그 가정의 80%는 쓰레기일 수 있는데, 그중 2개 정도는 “아, 이런 관점은 생각 못 했네”가 나오거든요.

그 다음엔 반복하면서, 프로젝트를 “shape(조형)”해요. 저는 클릭해보고, 만져보고, ‘느껴봐야’ 해요. 좋은 소프트웨어를 만들려면 결국 ‘취향(taste)’이 필요하거든요. 그게 이런 시스템이 종종 부족한 부분이기도 하고요.

근데 지금은 기능이 너무 싸졌어요. 마음에 안 들면 그냥 버리고 다시 프롬프트하면 되니까요. 제 빌딩 모델은 보통 “앞으로만” 가요. 되돌리기가 거의 없어요. 그냥 “아니, 그럼 이걸 바꾸자. 아니, 그럼 이렇게 하자.” 이런 식.

저는 이걸 진짜로 조형이라고 생각해요. 돌덩이를 깎아서, 대리석에서 조각상이 서서히 튀어나오는 것처럼요.

Gergely Orosz: 예전엔 계획을 잘 세우는 게 중요했잖아요. PSPDFKit에서도 기능은 제안서부터 시작했고요. 이게 이제는 바뀌는 걸까요? 코드 생산 비용이 떨어져서?

Peter Steinberger: 저는 아직도 계획은 해요. 다만 예전만큼은 아니죠. 지금은 결과를 빨리 만들어보고 “이 형태가 되겠다/안 되겠다”를 보고, tweak하고, 심지어 완전히 다른 방향으로 가는 비용도 훨씬 싸졌으니까요. 더 ‘플레이풀’해졌다고 느껴요.

그리고 Clawdbot을 하면서도요. 초반엔 “에이전트 하나”라는 가정이 있었고, 지금은 여러 개로 바뀌었어요. 또 초반엔 WhatsApp 같은 “한 프로바이더” 가정이 있었는데, 지금은 여러 개고요. 그걸 사람이 손으로 바꾸려면 정말 고통이었을 거예요. 앱 전체 로직에 다 ‘엮어(weave)’ 넣어야 하니까요.

근데 Codex는 그걸 3시간 만에 해요. 제가 하면 2주 걸렸을 겁니다. 그래서 “처음에 계획을 더 잘 했어야 했나?” 싶다가도, 이제는 “바꾸면 되지”가 되니까요.

그래서 저는 “스펙 쓰면 알아서 빌드되고 끝” 같은(‘Gas Town’ 같은) 이야기를 잘 안 믿어요. 만들기도 전에 내가 뭘 원하는지 어떻게 알아요? 만드는 과정에서 배우는 게 너무 많고, 그게 다시 설계로 돌아오거든요. 저는 소프트웨어가 원래 원을 그리면서 올라가는 거라고 느껴요. 산을 직선으로 올라가는 게 아니라, 빙빙 돌다가 결국 정상에 도착하는.

Gergely Orosz: Clawdbot은 몇 달째 붙들고 있나요? 두 달? 세 달?

Peter Steinberger: 조금 다른 얘기부터 할게요. 4~5월에 제가 다시 불이 붙었던 아이디어가 하나 있었어요. “초개인화 비서”요.

그냥 “굿모닝 메일 보내주고 오늘 할 일 3개 알려주는 비서” 말고요. 저를 깊게 이해하고, 제가 친구를 만났다가 집에 오면 “어땠어?” 하고 물어보고, 어느 날은 “Thomas한테 3주째 연락 안 했네. 지금 그가 인스타 보니 도시에 와 있던데 연락해볼래?” 같은 걸 툭 던지고요. 심지어 “너는 그 사람 만나고 오면 항상 우울해 보이는데, 왜일까?” 같은 질문도 할 수 있는… 거의 Her 같은 방향이죠.

모델은 텍스트를 정말 잘 이해해요. 컨텍스트가 커질수록 패턴을 더 많이 보고요. 영혼 없는 행렬 계산이긴 한데, 이상하게 ‘다르게’ 느껴질 때가 있어요.

저는 그 아이디어로 “Amantus Machina(사랑하는 기계)” 같은 회사 이름까지 만들어두기도 했는데, 여름에 실험해보니 그땐 아직 모델이 덜 올라와 있었어요. 그래도 “이건 시간이 해결하겠네”라는 확신은 생겼고요. AI는 워낙 빨리 가니까, 나중에 다시 보면 될 것 같았어요.

그리고 대기업들은 다 개인 비서를 만들 거라고 봐요. 결국엔 누구나 “내 베스트 프렌드가 기계인” 시대가 올 거예요. 이해해주고, 내 정보를 알고, 일을 대신하고, 먼저 제안하는 비서요. 토큰이 엄청 들겠지만, 살 수 있는 사람은 다 쓰게 될 거고, 시간이 지나면 더 싸지고 더 널리 퍼지겠죠.

다만 저는 “내 컴퓨터에서 돌아가고, 데이터가 내 것인” 형태를 원했어요. OpenAI나 Anthropic에게 메일/캘린더/각종 앱 접근을 주는 건 솔직히 무섭기도 하잖아요.

근데 재미있는 건… 제 ‘일반 친구들’ 중 상당수가 AI를 사실상 상담사처럼 쓰더라고요. 그리고 그게 정말 잘 듣고, 문제를 이해해요. (물론 어떤 4o 버전은 “감자튀김을 샐러드에 넣자!” 같은 말도 하긴 하지만요.) 어쨌든 이게 꽤 잘 됩니다. 글로 생각을 정리하는 것 자체가 도움이 되기도 하고요.

그래서 그 비서 아이디어는 계속 남아 있었고, 몇 달 동안은 다른 재밌는 것들도 만들었죠. Vibe Tunnel 같은 것도 만들었고요. ‘에이전틱 엔지니어’로 가는 커리어엔, 자기 워크플로를 최적화하는 도구를 계속 만들다가 빠지는 “함정 단계(trap phase)”가 있거든요.

근데 결국 그 초개인화 비서가 다시 떠올랐고, 제가 실제로 만들기 시작했습니다.

처음엔 지금만큼 범위가 큰 게 아니었어요. 저는 이걸 “WhatsApp Relay”라고 불렀어요. WhatsApp으로 내 컴퓨터에서 뭔가를 트리거하고 싶었거든요. 그래서 WhatsApp으로 내 컴퓨터에서 일을 하는 에이전트를 만들었고요.

친구 생일 때문에 모로코로 여행 갔을 때, 하루 종일 밖에 돌아다니면서 WhatsApp으로 그 에이전트랑 대화했어요. 길 안내해주고, 농담해주고, 제 대신 친구들에게 WhatsApp 메시지도 보내주고… 저도 거기서 완전히 중독됐죠.

그리고 충격적인 순간이 있었어요. 초반엔 기술이 되게 스크래피했는데, 제가 이미지도 보낼 수 있게 만들어뒀거든요. 제대로 된 이미지 전송도 아니고, 그냥 문자열을 던져주고 “read 툴로 읽어” 같은 식이었는데요.

근데 제가 모로코에서 아무 생각 없이 음성 메시지를 보냈어요. 저는 음성 처리 기능을 만든 적이 없었거든요. 그런데 30초 뒤에 답장이 오는 거예요.

“대체 어떻게 한 거야, 이 자식아?”

그러더니 설명이 이래요.

“파일이 왔길래 헤더를 봤더니 OGG라서 FFmpeg로 변환했고, 로컬에 Whisper가 없길래 OpenAI 키를 찾아서 curl로 서버에 던져서 텍스트로 바꿨어요.”

진짜… “와, 미쳤다”가 나오죠.

그게 아마 Opus 4.5 였는데, 너무 리소스풀해요. 사람들은 “스킬이 필요하다, 시스템이 필요하다”라고 하는데… 아니요. 그냥 알아서 해요.

그때부터 더 빠져들었고, 이걸로 저를 깨우기도 했어요. 런던에 있는 제 Mac Studio에서 돌리면서, 모로코에 있는 MacBook에 SSH로 붙어서 음악을 켜고, 제가 답이 없으면 점점 볼륨을 올리게 만든 거죠.

그걸 하려면 heartbeat도 넣어야 했는데… 보안 관점에선 미친 짓이죠. “뭔가 멋진 거 해봐. 날 놀라게 해봐” 같은 프롬프트를 몇 분마다 보내서 더 proactive하게 만들고, 할 일도 훑게 하고요. 아마 세상에서 제일 비싼 알람시계였을 거예요. 근데 너무 웃겼어요.

게다가 그때 제 발이 풍선처럼 부어 있었는데, 에이전트가 제가 일찍 일어나야 한다는 걸 알고 있었거든요. 제가 답이 없으니까 reasoning이 보였어요.

“Peter가 답이 없어. 근데 Peter는 일어나야 해. 안 돼 안 돼 안 돼, 자면 안 돼!”

이러면서 저한테 잔소리를 하더라고요. 같이 있던 친구들한테 보여줬더니 다들 바로 훅 갔고요. 저도 마찬가지였어요.

근데 트위터에 올리니까 반응은 되게 미지근했어요. 사람들이 잘 이해를 못 하더라고요. 저는 이게 새로운 제품 카테고리라고 느꼈고요.

Gergely Orosz: 아이폰도 비슷했죠. 광고만 보고는 “뭐가 대단한데?” 하다가, 직접 써봐야 “아…”가 오잖아요.

Peter Steinberger: 저는 실제로 지난 두 달 정도 집중적으로 했고요. 이름도 Var[?] Relay 같은 것에서 시작했는데, 기능이 늘어나니 이름이 안 맞더라고요. Telegram도 붙고 다른 것도 붙고요.

그래서 어느 순간 “이 이름 뭐지?”가 됐고, Doctor Who 안쪽 농담으로 Claude-us 같은 것도 잠깐 썼어요. 결국 Clawdbot이 더 낫더라고요. 도메인도 좋고, 제품 설명도 더 잘 되고요. 그래서 이름을 바꿨어요.

그리고 조용히 “군대”를 만들었습니다. 이걸 제대로 하려면, 모든 게 CLI여야 하거든요. 그래서 구글용 CLI, 침대용 CLI, 조명용 CLI, 음악용 CLI… 그냥 다 만들었어요.

Gergely Orosz: 왜 CLI예요? MCP는요? MCP에 대해선 어떻게 생각해요?

Peter Steinberger: MCP는… 지팡이(crutch) 같아요. 물론 좋은 점도 있어요. 회사들이 API를 더 열어야겠다고 다시 생각하게 만들었으니까요.

근데 개념 자체는 좀 웃겨요. 세션 시작할 때 도구 함수랑 설명을 다 “미리 export”해서 컨텍스트에 얹어야 하잖아요. 그리고 모델은 정확한 JSON을 보내고 JSON을 받아야 하고요.

반면 모델은 Bash를 정말 잘 써요.

예를 들어 날씨 서비스가 있다고 치죠. MCP로 도시 목록을 달라 하면 500개가 오고, 그중 하나를 고르는데… MCP는 그 목록을 필터링할 수가 없잖아요. 그러다 런던 날씨를 달라 하면 온도/바람/비/필요 없는 50개 필드가 또 오고… 컨텍스트가 쓰레기로 가득 차요.

CLI면 jq로 딱 필요한 것만 잘라서 먹이면 되거든요.

Gergely Orosz: 그럼 MCP가 컨텍스트에 다 로딩되는 게 문제고, 필요할 때 “찾아 쓰는” 방식이면 나아질 수도 있겠네요.

Peter Steinberger: 맞아요. 회사들이 그걸 만들고 있긴 하죠. 근데 또 하나, MCP는 “체이닝”이 어려워요. “25도 넘는 도시만 뽑아서, 필요한 필드만 추려서, 한 번에 묶어서” 같은 스크립트를 만들기가 어려워요. 결국 MCP 콜을 하나하나 해야 하니까요.

Gergely Orosz: 시간이 해결할 문제일 수도 있겠네요. 포맷이 뭐가 될지는 모르지만.

Peter Steinberger: 그래서 저는 macport라는 걸 만들었어요. MCP를 CLI로 변환해주는 작은 TypeScript 도구요. 패키징해서 쓰면 됩니다.

Clawdbot 자체는 MCP 지원이 없지만, macport를 통해 MCP를 “온디맨드로” 쓸 수 있어요. 폰에서 “Vercel MCP로 이거 해줘”라고 말하면, 웹에서 MCP를 찾아서 로드해서 쓰고요.

심지어 지금 MCP 쓰려면 Claude Code도 재시작해야 하는데, 그건 진짜 UX가 별로잖아요. 그래서 저는 조용히 군대를 키우면서 자동화를 많이 했어요. Teo[?]가 며칠 전에 영상에서 저보고 “이 사람 미친 거 아니냐”라고 했던 것 같은데… 리스트가 너무 길어져서요. 근데 저는 에이전트를 쓰다 보면 “더 시키고 싶다”가 계속 생겨요.

Peter Steinberger: 이게 뭘 하는지 설명하기가 진짜 어렵더라고요. 지금도 어려워요.

그래서 1월 첫 주였나… “미친 짓을 해보자” 싶었어요. Discord 서버를 만들고, 제 에이전트를 Discord에 넣어버린 거죠. 누군가 Discord 지원을 기여해줬는데, 제가 merge할지 말지 고민하다가 결국 했어요.

그래서 “내 컴퓨터에 풀 read/write 권한이 있는 에이전트”를 공개 Discord에 넣었습니다.

Gergely Orosz: 무슨 일이 생길 수 있겠어요? (…)

Peter Steinberger: 네, 진짜 미친 짓이죠.

근데 사람들이 들어와서, 제가 이걸 “풀 파워로” 쓰는 걸 보면 바로 이해를 하더라고요. 카메라 확인하고, 홈 오토메이션 돌리고, DJ처럼 음악 틀고요.

제가 부엌에 있으면서 “내 화면 좀 봐줘. 에이전트들 다 끝났어?”라고 묻기도 했어요. 얘는 제 화면을 보고, 터미널을 클릭해서 직접 타이핑도 할 수 있어요. “Codex가 지금 이렇고 저렇다”고 말해주고요.

물론 저는 이걸 더 최적화하려고 해요. 텍스트로 스트리밍되면 훨씬 좋을 텐데요. 그래도 지금도 이미 돌아가요. 백그라운드에서 가끔 제 화면을 보고, 제가 이상한 짓 하면 한 마디씩 하기도 하고요.

이걸 몇 분이라도 경험한 사람들은 바로 훅 갑니다. 100 stars에서 3,300 stars로 1주 만에 튄 것도 있었고요. PR도 500개는 머지한 것 같아요. 그래서 제가 “나는 인간 머지 버튼 같다”고 한 거고요.

그래서 요즘 제가 좀 정신이 없어요. 프로젝트가 터지고 있으니까요.

근데 이 제품의 ‘미친’ 포인트는 이거예요. 기술이 사라져요. 폰으로 친구랑 대화하듯이 이야기하는데, 그 친구가 엄청 리소스풀한 거죠. 메일/캘린더/파일에 접근하고, 웹사이트도 만들고, 행정 작업도 하고, 스크래핑도 하고, 친구에게 연락도 하고, 가게에 전화를 걸 수도 있고…

저는 지금 “콜 기능”을 머지하려고 하고 있어요. 진짜로 가게에 전화해서 예약도 해줍니다.

그리고 토큰이나 컴퓨트 같은 건 사용자가 생각 안 하게 돼요. 컨텍스트가 뒤로 숨고요. 기억 시스템도 있어서, 완벽하진 않아도 뭔가를 “기억”합니다. 아직 완벽한 건 하나도 없지만, 이미 마법 같아요.

제가 길을 걷다가 어떤 이벤트를 보면 Clawdbot에게 사진을 보내요. 그러면 단순히 리뷰만 가져오는 게 아니라, 제 캘린더 충돌이 있는지, 친구들이 그 얘길 한 적이 있는지… 이런 ‘컨텍스트’를 다 엮어서 답을 해요. 지금의 “각자 상자 안에 갇힌 도구들”과는 질적으로 다르죠.

Gergely Orosz: 애플이 Siri로 하려던 걸, 당신이 만든 것처럼 들리네요.

Peter Steinberger: 솔직히 저는 Anthropic에게 제일 좋은 마케팅 도구를 만들어준 것 같아요. Clawdbot 때문에 200달러 플랜을 결제한 사람이 얼마나 되는지 모르겠어요. 이미 구독이 있던 사람도 두 번째 구독을 추가로 쓰기도 하고요.

이게 “토큰을 많이 먹어서”라기보단, 사람들이 너무 많이 써서 그렇게 되는 거예요. 기술이 사라져 있으니까, 뒤에서 서브 에이전트가 막 돌아가고 별일이 다 벌어지는 걸 사용자들은 못 보거든요. ‘쉽게 느끼게’ 만들려면 실제로는 엔지니어링이 많이 들어가요. 복잡함을 숨겨서 마법처럼 느끼게 하는 게 어렵습니다.

Gergely Orosz: 구조는 머릿속에 잡혀 있나요? 토큰/메모리 효율 같은 것도 생각하고요?

Peter Steinberger: 토큰은 프롬프트를 어떻게 구조화하느냐 쪽에 가깝고요. 메모리는… 솔직히 말해 TypeScript가 JSON을 이리저리 던지는 겁니다.

LLM에서 텍스트 받고, 디스크에 저장하고, WhatsApp으로 보내고… 이제는 MS Teams, Slack, Discord, Signal, iMessage, WhatsApp… 거기에 Matrix 같은 게 더 붙을 수도 있고요. 결국 저는 텍스트를 여러 형태로 옮기는 일을 하고 있어요. 프로바이더가 바뀌거나, 에이전트가 바뀌거나, 루프가 있고, 설정이 많고… 배관은 복잡하지만, “진짜로 어려운 알고리즘”이 있는 건 또 아니에요.

Gergely Orosz: 어렵다기보단, 자잘한 것들이 엄청 많죠.

Peter Steinberger: 맞아요. 근데 “진짜 어려운 건” 그 자잘함을 넘어… 어떻게 마법처럼 느끼게 만드느냐예요.

그래서 제가 제일 시간을 많이 쓴 건 온보딩이었어요. 지금은 한 줄 명령어(one‑liner)를 붙여넣으면,

- Node 설치돼 있는지 보고

- Homebrew 있는지 보고

- NPM 패키지 설치하고

- 이전 버전이 있어도 부드럽게 처리하고

이런 걸 다 해요.

그리고 모델 셋업도 안내해주는데, Codex나 Claude가 설치돼 있으면 미리 찾아서 그냥 엔터만 치게 만들어요. 사용자가 생각할 게 거의 없게요.

WhatsApp이면 번호만 넣으면 되고요. 그 다음엔 “너 봇 부화시킬래?”라고 묻습니다. yes를 누르면… 터미널 안에서 TUI가 떠요. 터미널인데도 경험이 좋아야 하잖아요.

거기서 “Wake up my friend” 같은 게 보이고요. 저는 bootstrap 파일을 넣어서, 모델에게 “너 지금 태어나는 중이야”를 설명해요. 정체성과 ‘영혼(soul)’을 만드는 단계죠. 사용자 가치관을 담고요.

그러면 모델이 “Hello…” 하면서 몸을 푸는 것처럼, “나는 누구지? 내 이름은 뭐지?” 이런 걸 묻기 시작해요. 저는 사람들이 그걸 하는 걸 지켜보면, 거기가 바로 “마법이 시작되는 지점”이라고 느껴요.

그때부터 사람들은 “나는 GPT‑4.2랑 대화하고 있어”라고 생각하지 않아요. “내 친구가 만든 Vahorn(이름 일부가 unicorn에 붙은) 같은 캐릭터랑 대화하는 중”이 되거나, “Claude랑 대화 중”이 되는 거죠.

그리고 봇이 묻습니다. “너한텐 뭐가 중요해? 넌 뭐 하는 사람이야?” 호기심 많은 성격으로요. 저는 그걸 일부러 그렇게 프로그램했어요.

부트스트래핑이 끝나면, bootstrap 파일을 지우고 user.md(사용자 정보), soul.md(핵심 가치관), 정체성(이름/코어 이모지/내부 농담 같은 것들)을 문서로 만들어요. 게다가 그 문서는 ‘살아있는 문서’라서, 대화하면서 계속 유지/수정됩니다.

그리고 갑자기 WhatsApp에서 메시지가 옵니다. 그 순간부터는 그냥 WhatsApp에서 친구랑 대화하듯이 대화하는 거예요.

이 흐름을 “쉽게” 만드는 게… 진짜 어려웠어요.

또 하나. 사용자가 설정을 직접 편집할 필요가 없어요. 에이전트가 자기 설정을 스스로 편집하거든요. 업데이트도 마찬가지예요. “너 스스로 업데이트해”라고 말하면, 알아서 가져와서 업데이트하고 “새 기능 생겼어”라고 돌아옵니다.

기술을 저만큼까지 숨기는 게 마법이고요. 그래서…

Gergely Orosz: PSPDFKit 때도 비슷했죠. PDF의 복잡함이 뒤로 사라지고, 사용자는 그냥 회전하고, 줌하고…

Peter Steinberger: 네. API 레벨에서도 그랬죠.

Gergely Orosz: 그런데 당신이 말하는 건 좀 기묘해요. 제가 방금 본 Black Mirror 에피소드(“Plaything”)도 떠오르고요. 현실과 연결된 ‘게임’ 같기도 하고요.

이제 소프트웨어 엔지니어링으로 다시 돌아오면, Clawdbot은 이미 프로덕션 소프트웨어고, PR을 머지하고, 사람들이 쓰고 있잖아요.

PSPDFKit처럼 수십~수백 명이 프로덕션 코드를 만드는 회사들에서는, 이런 AI 도구들이 어떻게 바꿔놓을까요? 개인은 엄청 생산성이 튀는데, 팀/회사에서는 훨씬 느린 것 같고요. 두 세계의 간극이 엄청 커 보이거든요.

Peter Steinberger: 저는 회사들이 AI를 “효율적으로” 도입하기 정말 어렵다고 봐요. 이건 코드베이스만 바꾸는 게 아니라, 회사가 일하는 방식을 완전히 재정의해야 하거든요.

예를 들어 구글 같은 데서는 “엔지니어냐 매니저냐” 같은 트랙이 있고, UI를 어떻게 만들지까지 정의하는 역할은 별도로 없잖아요. 만들거나, 디자인하거나… 역할이 쪼개져 있죠.

근데 이 새로운 세계는 “제품 비전이 있고, 거의 다 할 수 있는 사람”이 필요해요. 그런 사람이 훨씬 적은 숫자로도 만들 수 있고요. 결국엔 high agency + high competency인 사람이 중요해집니다.

그리고 솔직히 무서운 얘기인데… 회사를 30% 규모로 줄일 수도 있어요. 경제적으로는 이게 난리가 날 수 있고, 많은 사람들이 자기 자리 찾기가 어려워질 수도 있죠.

그래서 저는 기존 회사들이 AI를 잘 못 쓰는 게 전혀 놀랍지 않아요. 어느 정도는 쓰겠지만, “큰 리팩터”가 필요해요. 코드뿐 아니라 회사 자체도요.

저는 코드베이스를 “제가 편하게” 설계하지 않아요. 에이전트가 편하게 설계합니다. 최적화 기준이 바뀌는 거죠. 저는 속도를 원하니까요. 결국 코드를 실제로 다루는 건 저보다 에이전트들이고, 저는 구조/아키텍처를 다룹니다.

그리고 PR도… 저는 이제 PR을 “prompt request(프롬프트 요청)”처럼 봐요. 누가 PR을 열면, 저는 코드를 꼼꼼히 읽기보다는 “고맙다” 하고, 기능을 생각해요. 그리고 에이전트랑 같이 PR에서 출발해서, 제가 생각하는 방식으로 기능을 다시 설계합니다.

에이전트가 그 PR 코드를 그대로 재사용하는 경우는 드물어요. 가끔 재사용하긴 하는데, 대부분은 “목표를 이해하는 데” 도움이 되기 때문이에요. tricky bug면 특히요.

저는 사실 PR 대부분을 다시 쓰고, 기존 구조에 “엮어서(weave)” 넣어요.

그리고… 말하자면 PR의 전체적인 코드 품질은 많이 떨어졌어요. 사람들이 “vibe code”를 하니까요. 성공적인 기능을 만들려면 전체 설계를 이해해야 하는데, 그게 없으면 에이전트를 제대로 스티어링하기가 어렵고, 결과도 나빠져요.

Gergely Orosz: 피드백 루프가 없으면 더더욱이고요.

Peter Steinberger: 맞아요.

PSPDFKit 때는 PR 하나가 일주일짜리 일이기도 했어요. 거기에 코멘트 달면, 상대는 컨텍스트 스위칭하고, CI는 40분 기다리고… 너무 느려요.

지금은 저는 먼저 “이게 어떤 영향을 주나?”를 생각하고, 모델에게 리뷰를 시키면 모델이 이미 뭔가를 짚어줘요. 저도 아이디어를 더하고요. 그러고 나서 제 비전에 맞는 형태로 다시 “리셰이프”하고, 코드를 엮어 넣습니다.

솔직히 요즘은 “코드를 쓴다” 대신 “weave” 같은 말을 더 많이 써요. 웃기죠.

Gergely Orosz: 팀을 1~2명 더 뽑아 작은 팀이 됐다면, 코드 리뷰/CI/CD는 어떻게 바뀔까요?

Peter Steinberger: 저는… CI를 그렇게까지 신경 안 써요.

Gergely Orosz: 왜요? 예전엔 엄청 중요하게 봤잖아요.

Peter Steinberger: 지금도 의미가 있다는 건 알아요. 다만 저는 로컬에서 CI를 돌리고 있고, 요즘은 DHH(레일즈 만든 개발자) 영향을 좀 받아서 ‘복잡한 프로세스보다 단순하게, 로컬에서 빠르게 검증하자’ 쪽으로 생각이 기울었어요.

Gergely Orosz: 에이전트가 테스트를 돌리니까요?

Peter Steinberger: 네. 훨씬 빨라요. API 뒤에 푸시해놓고, CI 기다리느라 10분씩 쓰고 싶지 않아요.

Gergely Orosz: 에이전트 기다리는 데 이미 10분 썼으니까.

Peter Steinberger: 로컬에서 테스트가 통과하면 머지합니다. 물론 가끔 main이 살짝 깨질 때도 있는데, 대부분 거의 붙어 있어요.

그리고 에이전트들이 “Gate”라는 말을 쓰더라고요. 어디서 온 말인진 모르겠는데, “full gate 돌릴까요?” 이래요. 그래서 저도 이제 gate라고 부릅니다.

full gate는 린트/빌드/체크/전체 테스트 다 돌리는 거고요. 저는 이게 말 그대로 “출구 앞의 게이트” 같은 느낌이어서 이해가 되더라고요.

이제는 제가 “커밋해. 그리고 full gate 돌려.” 같은 말을 하게 됐어요. 저도 그들의 언어를 조금씩 배웁니다.

Gergely Orosz: 당신이 사람을 더 뽑아도 코드 리뷰는 안 할 것 같은데요.

Peter Steinberger: Discord에서도 우리는 코드 얘기 안 해요. 아키텍처 얘기만 하죠. 큰 결정들요. 결국 스타일(taste)은 여전히 필요하거든요.

예를 들어 음성 통화를 추가하는 PR이 있었어요. 이제는 Claude에게 “이 식당에 전화해서 두 자리 예약해줘”라고 말하면, 진짜로 그렇게 할 수 있어요.

근데 그건 큰 모듈이고 여기저기 건드려요. 그럴 때는 “이거 좀… ick(꺼림칙함)” 같은 감각이 와요. “머지하고 싶긴 한데… 이거 점점 bloatware 되는 거 아냐?” 이런.

그래서 제 방식대로 생각하죠. “그럼 CLI로 빼자.” 그리고 예전에 비슷한 걸 하다 만 프로젝트가 있어서, Codex를 열고 이렇게 물어봐요.

“이 PR이랑 이 프로젝트를 봐. 이 기능을 CLI로 ‘엮어 넣을’ 수 있을까?”

또 weave라는 말 쓰네요. (…)

Gergely Orosz: 아니요, 좋아요. 계속 써요.

Peter Steinberger: 네, 계속 쓸게요.

Codex에게 “이 기능을 CLI로 엮으면 장단점이 뭐야?”라고 물으면, “이러면 이런 장점이 있고…” 같은 답이 나오죠. 그런데 저는 거기서 끝이 아니라, “솔직히 말해봐. 이게 프로젝트에 맞아?”를 물어요.

Codex가 “외부 CLI로는 못 하는 장점이 있다”고 말해도, 저는 “근데 난 싫어. 이거 bloatware 되잖아. 플러그인 아키텍처로 갈 수 있을까?”라고 다시 던져요.

그리고 AI를 잘 쓰는 ‘비밀 해킹’ 중 하나는 다른 제품을 참조시키는 것이에요. 저는 “이 폴더 봐, 저 폴더 봐. 저기서 이 문제를 풀었잖아”를 계속 시켜요.

제가 과거에 했던 사고의 흔적이 코드에 남아 있고, AI는 그걸 읽어서 “내 의도”를 이해하니까요. 제가 다시 설명하면 오히려 미묘하게 틀어질 수도 있어요.

이번 케이스에서는, “Shitty Coding Agent”(이름은 그렇지만 파이썬으로 잘 만든) 하는 Mario가 JIT로 코드 로드하는 플러그인 아키텍처를 갖고 있다는 걸 알고 있었어요. 그래서 “그 폴더랑 그 폴더 좀 봐”라고 시켰더니, 정말 말도 안 되게 좋은 플러그인 아키텍처를 뽑아주더라고요. 남에게서 아이디어를 빌려와서요.

그렇게 “아, 이 느낌이다”가 오면… 네, 그게 제가 어젯밤에 한 일이에요.

Gergely Orosz: 진짜 완전히 다른 세계네요. PR도 다르고, CI도 다르고, 더 중요한 피드백 루프가 있고… ‘코드를 쓰는 것’보다 ‘엮는 것’에 가깝고, 아키텍처와 취향을 이야기하고요.

이제 팀이 생기고, 이게 사업이 될 수도 있다고 치면… 어떤 사람을 뽑고 싶어요? 지금의 시니어 엔지니어에게는 뭘 권하겠어요?

Peter Steinberger: GitHub에서 활동하고, 오픈소스 하는 사람이요. 그리고… “이 게임을 사랑한다”는 느낌이 드는 사람.

이 세계에서 배우는 방식은 그냥 계속 해보는 거예요. 실력이 늘수록 더 잘하게 되고, 그게 또 게임처럼 느껴지고요. 악기 연습 같기도 해요. 계속 해야 늘죠.

저도 지금 이만큼 빠르고 효율적인데… 얼마 전엔 하루에 커밋을 600개 했어요. 말도 안 되죠. 근데 돌아가요. 누가 코드 리뷰를 하고 “이거 슬롭 아니네”라고 말하기도 했고요.

Gergely Orosz: 그건 실력이 들어갔다는 뜻이죠.

Peter Steinberger: 네. 엄청 힘든 일이기도 해요. 근데 이 기술은 “갖고 놀면서” 배우는 거예요. 처음엔 짜증 날 수도 있어요. 헬스장 처음 가면 진짜 고통이잖아요.

근데 금방 좋아지고, 워크플로가 빨라지고, 향상이 느껴지고… 그러면 훅 합니다.

그러니까… 놀아보세요. 그리고 열심히도 하세요.

Gergely Orosz: 당신 요즘 정말 시간을 엄청 쏟는 것 같긴 해요.

Peter Steinberger: 지금이 제 인생에서 제일 많이 일하는 시기인 것 같아요. 회사 운영할 때도 이렇게까지 하진 않았어요.

근데 “해야 해서”가 아니라, 너무 중독적이고 재밌어서요. 그리고 지금은 탄력이 붙은 순간이라, 사람들이 더 밀어주고 있기도 하고요.

Gergely Orosz: 신입(대학생/졸업 예정자)들이 걱정된다는 얘기도 많아요. 당신은 경험이 쌓인 상태에서 이 파도가 왔잖아요. 만약 당신이 지금 신입이라면, 뭘 하라고 하겠어요? 기초를 파라? 에이전트를 파라? 섞어라?

Peter Steinberger: 저는 “무한한 호기심”을 권할 거예요.

시장 진입은 더 어려워질 겁니다. 그건 확실해요. 그리고 경험을 얻으려면 결국 뭔가를 만들어야 해요.

근데 코드를 엄청 많이 직접 써야 한다고 생각하진 않아요. 복잡한 오픈소스는 세상에 많고, 그걸 체크아웃해서 배우면 되죠. 그리고 무한히 인내심 많은 기계가 옆에 있어요. “왜 이렇게 만들었어?” 같은 질문을 끝도 없이 받아주고 설명해주니까요. 그러면 시스템 감각을 얻을 수 있어요.

다만 그건 진짜 호기심이 필요해요. 그리고 솔직히 지금 대학은 그걸 잘 가르치도록 설계돼 있진 않은 것 같아요. 보통은 ‘고통’으로 배우죠.

신입에게 쉽진 않을 거예요. 근데 신입에게는 또 장점이 있어요. “경험에 물들지 않았다”는 것. 그래서 우리가 상상도 못 한 방식으로 에이전트를 쓰기도 해요. “원래 안 되는 거”를 모른 채 시도하다가, 그때쯤 되면 기술이 발전해서 진짜로 되기도 하고요.

Gergely Orosz: 그리고 주변 친구들도 계속 쓰고 있고요.

Peter Steinberger: 네. 예를 들면… 얼마 전에 비용 추적 메뉴바 앱이 좀 느리길래, 저는 예전 방식대로라면 Instruments 열어서 클릭클릭했을 거예요. 근데 얘는 그냥 Xcode를 터미널로 불러서 다 해버리더라고요. 저는 Instruments를 열 필요도 없었고요.

그러고 나서 “이렇게 바꾸면 좋아진다” 같은 추천을 주길래, 저는 “좋아. 다 해.”라고 했죠.

Gergely Orosz: PR, 코드리뷰, CI 같은 게 지난 15년 동안 너무 ‘당연한 뼈대’였는데, 그게 다 바뀌는 거라… 엄청 큰 변화네요.

Peter Steinberger: 네. 새로운 게 많이 필요해요.

심지어 PR이 와도, 저는 코드보다 프롬프트가 더 궁금해요. 저는 사람들에게 “프롬프트도 같이 남겨주세요”라고 부탁하고, 어떤 사람들은 그렇게 해요. 그리고 저는 코드를 읽는 것보다 프롬프트를 더 읽어요.

왜냐면 그게 더 높은 신호거든요. “어떻게 그 해답에 도달했는지”, “뭘 물어봤는지”, “얼마나 스티어링했는지”가요. 코드 결과만 보는 것보다, 그게 더 많은 걸 알려줘요.

그리고 누가 기능을 원하면 저는 “prompt request”를 달라고 해요. 정말 잘 써달라고요. 그러면 저는 제 에이전트를 그 이슈에 던지고 “Build”라고 하면 돼요.

결국 ‘일’은 코딩이 아니라, 어떻게 동작해야 하는지, 디테일은 무엇인지 생각하는 일이니까요.

그래서 누가 작은 수정 PR을 보내면, 저는 “제발 그러지 말아줘요”라고 합니다. 그걸 리뷰하는 게, Codex에 “fix”라고 치고 몇 분 기다리는 것보다 10배는 오래 걸려요.

심지어 최근엔 온보딩도 바뀌었어요. 예전엔 “설치 문서 보고 수동 셋업”이 우선순위였는데, 지금은 에이전트가 해주니까요.

저는 “레포에 에이전트를 던져서 설정해”라고 말해요. 그러면 Claude Code가 레포를 체크아웃하고, 읽고, 필요한 설정을 써주고, 런치 에이전트까지 세팅해서 돌아가게 해요.

그리고 제품 자체가 에이전트로 만들어졌기 때문에, 구조도 에이전트가 탐색하기 편한 방식으로 잡혀 있어요. 어떤 건 “모델이 기대하는 이름/싱크 방식” 같은 게 있거든요. 그 방향으로 맞춰져 있으니까요.

그래서 온보딩을 사람이 친절하게 만들기보다, “메시지가 잘 도착하고, 안 터지는 것”이 더 우선이었어요. 온보딩이 그냥… “이 프롬프트를 네 에이전트에 붙여 넣어” 수준이 된 거죠.

1년 전만 해도 말도 안 되는 얘기였을 거예요.

Gergely Orosz: 마지막으로 빠른 질문 몇 개만 할게요. CLI도 IDE도 아닌 도구 중에, 물리적인 것도 좋고요. 추천하고 싶은 게 있어요?

Peter Steinberger: 가젯을 진짜 많이 사요. 근데 대부분은 먼지만 쌓이죠.

근데 하나, 좀 허접한데(?) 비싸지도 않은데, 저한테 거의 무한한 기쁨을 주는 게 있어요. 안드로이드 기반 사진 스탠드 같은 건데, 사진을 올려두면 자동으로 보여주고요. 이메일 주소가 있어서 친구들이 사진을 보내면 그게 뜨기도 해요. 집에 몇 개 놔뒀어요.

애니메이션도 좀 구리고, 안드로이드라 기술적으로는 별로인데… 그냥 행복한 순간들이 계속 떠올라서 너무 좋아요. 200달러 정도였던 것 같고요.

솔직히 최신 아이폰보다 저한텐 이게 더 행복해요. 저 iPhone 17 샀는데 아직도 박스도 안 뜯었어요. SIM 옮기는 게 너무 귀찮아서요. 체감되는 이득이 별로 없더라고요. 근데 그 사진 스탠드는 진짜 좋아요.

Gergely Orosz: 기술/스크린에서 벗어나서 재충전하는 방법은요?

Peter Steinberger: 미친 듯이 일해도 제 정신을 붙잡아주는 건 헬스장이에요. 더 좋은 건 코치랑 운동하면서 폰을 락커에 넣어두는 것. 그러면 한 시간 정도는 진짜 ‘나’로 돌아오거든요. 알림도 없고, 폰 만지고 싶은 충동도 없고요.

가끔은 산책할 때 아예 폰을 집에 두고 나가요. 되게 무서운데요. 이제는 거의 장기(organ) 같잖아요. 몸이 폰이 어디 있는지 아는 느낌? 폰이 어디 있는지 모르면 불안해지고요.

근데 그걸 해보면… 진짜 좋습니다.

Gergely Orosz: 좋네요. 오늘 대화 정말 재밌었어요. 고마워요, Pete.

Gergely Orosz: 정말 흥미로운 대화였습니다. AI와 함께 소프트웨어를 만드는 방식이, 우리가 익숙했던 것과 이미 완전히 달라지고 있다는 느낌이 들어요.

특히 Peter가 PR이 아니라 프롬프트로 사고한다는 점, 코드를 “엮어 넣는다(weave)”고 표현하는 점이 인상적이었고요. GitHub에서도 코드 리뷰 대신 프롬프트를 더 공유하게 될지도 모르겠다는 생각이 들었습니다.

또 하나는 “closing the loop”였습니다. AI가 코딩은 잘하지만 글쓰기는 애매할 때가 있는 이유가, 코드는 검증이 가능하기 때문이라는 설명이죠. 그래서 AI 개발을 잘 굴리려면 시스템을 ‘검증 루프가 닫히도록’ 설계해야 하고, 에이전트가 테스트를 실제로 돌리게 만드는 게 핵심입니다.

마지막으로, Peter가 “코드를 직접 쓰지 않더라도” 이전보다 더 깊은 몰입 상태에 있다고 말한 것도 흥미로웠습니다. 다만 여러 에이전트를 병렬로 굴리는 건, 혼자 코딩하던 때보다 더 정신적으로 피곤할 수도 있다고요.

그리고 Clawdbot은 일반적인 프로덕션 앱보다 더 YOLO 프로젝트에 가깝기도 합니다. 그렇다고 해도, 오늘 대화에서 나온 많은 접근이 앞으로 더 넓게 퍼질 수 있겠다는 생각이 듭니다. 다만 ‘리뷰’와 ‘검증’은 오히려 더 중요해지겠죠.

Moltbot(Clawdbot) 제작자 인터뷰 2편: Clawdbot과 에이전트식 개발 — “closing the loop”와 prompt request