Agentic Engineering in Action with Mitchell Hashimoto

트랜스크립트: https://www.assemblyai.com/playground/transcript/7fa128a8-efee-4f08-b38d-aa1e0003a60a

번역 (비공개): https://gemini.google.com/app/617a94c5d8ced304

https://github.com/ghostty-org/ghostty/commit/3de3f48faf830fe1326f44b08fb9f27fa65cefcd

🎙️ 에이전틱 엔지니어링의 대가, 미첼 하시모토를 만나다

🤔: 여러분, 환영합니다. 저희의 첫 번째 에이전틱 엔지니어링 세션입니다. 저는 Zen의 엔지니어 리처드입니다. 저희는 AI에 탁월한 코드 에디터를 만들고 있죠. 이분은 널리 사용되는 수많은 기술을 개발하신 미첼 하시모토입니다. 여러분도 아마 그중 일부를 사용해 보셨을 겁니다. 가장 최근에는 제가 주력으로 사용하는 터미널 에뮬레이터인 뛰어난 Ghostty를 만드셨죠. 이 자리를 빌려 만들어주셔서 감사하다는 말씀을 전합니다. 정말 팬이에요. 오늘 저희가 이 자리에 모인 이유는 사람들이 어떻게 AI 에이전트를 사용해 단순히 기존의 것을 더 빠르게 만드는 것이 아니라, 높은 품질의 소프트웨어를 만들어내는지 배우기 위함입니다. Ghostty는 제가 생각하기에 바로 그 '품질의 기준을 높이는' 고품질 소프트웨어의 범주에 속합니다. 미첼, 당신은 그동안 대규모 언어 모델(LLM)을 사용해 Ghostty를 개선하는 몇 가지 방법들에 대해 포스팅해 오셨습니다. Ghostty는 고품질 프로젝트일 뿐만 아니라, 수많은 로우레벨 시스템 프로그래밍 유형의 작업을 포함하고 있죠. 단순히 웹 UI 같은 것을 만드는 게 아닙니다. 게다가 Zig라는 비주류 언어로 작성되었죠. 모델의 학습 데이터에서 큰 비중을 차지하지 않기 때문에 이와 관련된 몇 가지 특별한 어려움이 있을 거라 생각합니다. 우선 당신이 사용했던 프롬프트 등을 공유한 특정 커밋(commit)에 대해 이야기하며 시작해 보면 어떨까요? 그걸 보면서 당신이 무엇을 했고, 과정은 어땠으며, 무엇을 배웠는지, 그리고 비슷한 종류의 작업을 하려는 사람들에게 어떤 실질적인 조언을 해줄 수 있는지 이야기해 보시죠. 괜찮으신가요?

👨‍💻: 네, 좋습니다.

🤔: 좋습니다. 그럼 제 화면을 공유하겠습니다. 바로 이 커밋인데요. 이걸 어떻게 수정했는지에 대해 이야기했었죠. 네, 이 수정 작업이 정확히 어떤 내용이었는지 간단한 배경 설명을 좀 해주시겠어요?

👨‍💻: 네. 아주 높은 수준에서 설명드리자면, Ghostty에 최근 새로운 기능이 추가되었습니다. 정식 릴리즈는 아니지만 베타 사용자들이 쓸 수 있는 기능인데요, 터미널을 닫을 때, 그게 분할 창(split)이든, 탭이든, 창(window)이든 상관없이 터미널을 닫은 후에 Control-Z나 Command-Z를 눌러서 되돌릴 수 있는 기능입니다. 닫은 후 약 5초 동안(설정 가능) Command-Z를 누르면 창이 다시 나타나는 거죠. 터미널을 완전히 종료시킨 게 아니기 때문에 모든 히스토리와 모든 것이 그대로 남아있습니다. 이 커밋은 그 기능을 도입하면서 발생한 버그와 관련된 것이었습니다. 그리고 그 기능은 AI 도구와 상당 부분 협력하여 작성되었습니다.

🐛 AI와 함께 버그 수정하기: '실행 취소' 기능의 여정

🤔: 그렇군요. 그게 배경이군요. 그러니까 이건 탭을 다시 열고 싶을 때 실행 취소를 하는, 꽤 이해하기 쉬운 버그네요. 구현을 위해 무엇을 해야 하는지 설명했고, 그 아래에는 실제로 구현에 도달하기까지 거쳤던 프롬프트들이 있습니다. 첫 번째 질문은 이겁니다.

👨‍💻: 이 커밋 메시지, 정말 마음에 들어요. 이것도 대부분 사람이 쓴 겁니다. 배경을 위해 덧붙이자면요.

🤔: 네, 어느 정도 티가 나요. Claude는 특유의 말투가 있는데, 제가 별로 선호하는 글투는 아니거든요. 자, 여기 구현 부분이 있는데, 첫 질문은 이겁니다. 처음부터 이런 식으로 문제를 분해해서 시작했나요? 즉, 이 글머리 기호 목록을 미리 작성했나요, 아니면 그냥 실제 프롬프트로 시작했다가 전체 작업을 마친 후에야 요약하게 된 건가요?

👨‍💻: 네, 현재 AI 도구를 사용하는 제 접근 방식은 이렇습니다. 물론 AI 도구가 훨씬 더 발전한다면 이런 방식에서 벗어날 수도 있겠지만요. 제가 가장 큰 성공을 거두는 방식은, 제가 소프트웨어 프로젝트의 '설계자(architect)' 역할을 하는 것입니다. 요즘은 사람들이 이런 직책명을 좋아하지 않지만요. 저는 여전히 코드 구조, 애플리케이션의 예상 데이터 흐름, 상태(state)가 어디에 위치하는지 등을 구상하는 것을 선호합니다. 제 머릿속으로 그것을 상상하고 파악하는 거죠. 그리고 AI 도구에게 그런 지침을 줍니다. "이 최종 목표를 달성해 주되, 이런 형태(shape)를 사용해서 해줘"라고요. 저는 이런 방식이 가장 성공률이 높다는 것을 발견했습니다. 만약 제가 그냥 "여러 탭이 포함된 창을 닫을 때 실행 취소 작업이 작동하지 않으니 고쳐줘"라고 첫 문단처럼 말했다면, 아마 AI가 해결은 했을 겁니다. 하지만 그건 장기적으로 유지보수하기 어려운, 아주 끔찍하고 조악한 방식으로 해결했을 겁니다. 그래서 제가 이런 구체적인 글머리 기호 목록을 직접 만들지는 않았지만, 제 프롬프트를 보시면 제가 무엇을 말했는지 알 수 있을 겁니다. 문제 해결의 '틀'을 제가 구상하고 AI에게 맡긴 거죠.

🧭 '설계자'로서의 개발자: 성공적인 AI 활용 철학

🤔: 알겠습니다. 개별 프롬프트를 살펴보기 전에, 방금 암시하신 부분에 대해 조금 더 질문하고 싶습니다. "이런 동작을 원하니, 그냥 네가 알아서 해줘"와 같이 훨씬 더 추상적인 버전을 시도해 본 적이 있으신 것 같습니다. 그리고 그 결과에 만족하지 못하셨던 것 같고요.

👨‍💻: 이 특정한 문제에 대해서는 그렇게 시도해보지 않았습니다. 경험상 이제는 그런 방식을 피하게 됐어요. 하지만 과거에는 그 접근 방식에 만족하지 못했습니다. 제가 원하는 결과물에 도달하기까지 훨씬 더 많은 '손질(massaging)'이 필요하다고 느꼈거든요. 왜냐하면 많은 경우 제 머릿속에는 제가 원하는 것에 대한 명확한 그림이 있었고, 그렇다면 그 그림을 그냥 말해주는 게 낫지 않을까요? 제가 정말 막연한 프롬프트를 사용하는 유일한 경우는, 제가 '헤일 메리(Hail Mary)' 프롬프트라고 부르는, 일종의 제로샷(zero-shot) 같은 건데요. 미리 저장해 둔 Claude의 슬래시 커맨드(/command)가 있습니다. 이슈 번호만 알려주면 GitHub에 연결해서 이슈를 가져오죠. 저는 이슈를 '고쳐달라'고 말하지는 않습니다. 아직 그 정도로 신뢰하지는 않거든요. 하지만 이슈를 분류하면서 그냥 '헤일 메리'처럼 "이 이슈가 왜 존재하는가? 해결책이 보이는가?"라고 묻습니다. 그냥 무언가를 설명하고 제가 나아갈 길을 보여주도록 유도하는 거죠. 이슈를 분류하고, 라벨을 붙이고, 정리하는 동안 동시에 5개 정도의 이슈에 대해 이런 작업을 할 수 있습니다. 저는 정답을 찾는 게 아닙니다. 때로는 "아, 버그가 아마 저 파일에 있겠구나" 하는 지점까지 저를 데려다주는 것만으로도 충분하고, 그러면 제가 직접 가서 마무리할 수 있습니다.

🤔: 제가 그런 방식으로 도구를 사용하는 것에 대한 멘탈 모델은, 일종의 '초안 생성기' 같은 겁니다. "이 코드를 보면 문제 설명만으로는 얻지 못했던 무언가를 배울 수 있겠지, 하지만 이 코드는 아마 전부 버리고 나중에 제대로 다시 짜게 될 거야" 하는 식이죠.