AI 잘 쓰는 사람은 처음에 느립니다

HashiCorp 만든 사람 아시죠? Mitchell Hashimoto. Terraform, Vagrant, Vault — 인프라 쪽에서 모르면 간첩인 도구들 만든 사람이에요. 지금은 Ghostty라는 터미널 에뮬레이터를 만들고 있고요. 이 사람이 며칠 전에 "My AI Adoption Journey"라는 글을 올렸습니다.

저는 이 글을 읽고 좀 놀랐어요. 왜냐하면 제가 겪은 과정이랑 거의 똑같았거든요. 처음엔 AI가 별로였고, 억지로 써봤고, 어느 순간 "아, 이거 없으면 안 되겠다"가 됐다는 거요. 근데 Mitchell은 이 과정을 6단계로 깔끔하게 정리했어요. 읽으면서 "아, 이걸 나도 이렇게 설명할 수 있었으면 좋았겠다" 싶었습니다.

근데 원문을 그대로 전달하면 재미가 없잖아요. 그리고 6단계를 하나씩 나열하면 외우기도 어렵고, "그래서 나한테 뭐가 달라지는데?"가 안 와닿거든요. 그래서 오늘은 Mitchell의 여정을 제 현업 경험으로 재해석해보겠습니다. 같은 길을 걸었지만 다른 관점으로 봤어요.

AI와 함께 일하는 방식의 변화

"처음에 안 되는 게 정상이에요"

AI 코딩에 관심 있는 분들 중에 이런 경험 한 번쯤은 있을 거예요.

ChatGPT한테 "로그인 기능 만들어줘" 하니까 그럴듯한 코드가 나왔어요. 복붙했는데 안 돌아가요. 고쳐달라고 하니까 또 다른 코드를 뱉어요. 그것도 안 돼요. 결국 "에이, 이거 차라리 내가 짜는 게 낫다" 하고 끄죠.

Mitchell도 똑같았어요. AI 회의론자였는데, 어느 날 Zed 에디터의 커맨드 팔레트 스크린샷을 Gemini한테 보여주면서 "이거 SwiftUI로 만들어줘"라고 했더니 거의 완벽하게 나온 거예요. 지금 Ghostty에 탑재된 커맨드 팔레트가 그때 AI가 만든 거라고 해요. 몇 초 만에요.

"오, 이거 대박인데?"

근데 다른 작업에서 같은 걸 시도하니까 실망뿐이었대요. 기존 프로젝트(brownfield)에서는 결과물이 엉망이었고, 코드랑 에러 메시지를 복붙하면서 왔다 갔다 하는 게 차라리 직접 짜는 것보다 느렸다고요.

여기서 Mitchell이 내린 결론이 중요해요. "챗봇을 버려라. 에이전트를 써라."

챗봇은 대화 인터페이스잖아요. 여러분이 코드를 복사해서 붙여넣고, AI가 답을 주고, 또 복사해서 붙여넣고. 이 과정 자체가 비효율적이에요. 에이전트는 다릅니다. 파일을 직접 읽고, 프로그램을 실행하고, 필요하면 HTTP 요청도 보내요. 복붙이 아니라 AI가 직접 행동하는 거예요.

저도 똑같은 길을 걸었거든요. 처음에 ChatGPT 웹에서 이것저것 시도하다가 "이거 시간 낭비다" 싶었어요. 근데 Claude Code를 쓰면서 완전히 달라졌습니다. 터미널에서 바로 파일을 읽고, 수정하고, 테스트를 돌리니까 대화가 아니라 협업이 되더라고요.

근데 여기서 중요한 게 있어요. 에이전트를 써도 처음에는 안 됩니다. Mitchell도 Claude Code를 처음 썼을 때 별로였대요. 결과물을 일일이 고쳐야 했고, 직접 짜는 것보다 느렸다고요. 블로그 읽고 영상 봐도 감이 안 왔다고 해요.

이게 모든 새로운 도구의 보편적인 진실이에요. Mitchell은 이걸 3단계로 설명해요:

대부분의 사람들이 1단계에서 포기해요. "AI 써봤는데 별로더라." 네, 처음엔 다 별로예요. Mitchell Hashimoto도 별로였어요. 저도 별로였어요. 근데 그걸 뚫고 나가야 2단계, 3단계가 옵니다.

삽질이 전문성을 만든다

Mitchell이 한 행동이 미쳤어요. 같은 작업을 두 번 했습니다. 한 번은 직접, 한 번은 AI로. 일부러요.

직접 커밋한 걸 AI한테 똑같이 시켜본 거예요. 물론 AI한테는 자기가 만든 답을 안 보여줬고요. 품질과 기능이 동일한 결과물을 에이전트로 만들어내는 연습을 한 거예요.

솔직히 이거 미친 짓이거든요. 업무 시간의 2배를 쓰는 거잖아요. 근데 Mitchell은 이렇게 말해요. "고통스러웠지만, 이 마찰이 자연스러운 것이고, 노력을 다하지 않으면 확실한 결론을 내릴 수 없다는 걸 알았다."

저도 비슷한 경험을 했어요. 회사에서 업무 코드를 AI로 짜기 시작했을 때, 처음 한 달은 사실 직접 짜는 것보다 느렸습니다. 근데 "이건 내가 도구를 못 쓰는 거지, 도구가 나쁜 게 아니다"라는 확신이 있었거든요. 그래서 계속 했어요.

그 과정에서 Mitchell이 발견한 원칙 3가지가 있는데, 이게 제 강의에서 가르치는 것과 정확히 일치해요.

원칙 1: 세션을 쪼개라

하나의 메가 세션에서 "전체 앱 만들어줘"는 안 됩니다. 명확하고 실행 가능한 작은 작업으로 나눠야 해요.

제 강의 Ch3에서 이걸 "탐색 → 설계 → 구현 → 커밋" 워크플로우로 가르치는데, Mitchell도 같은 결론에 도달한 거예요. "부엉이를 그려라(Draw the Owl)"처럼 한 번에 완성하려고 하면 안 된다고요. 단계별로 쪼개고, 각 단계에서 확인하고, 그다음 넘어가야 해요.

원칙 2: 설계와 실행을 분리하라

막연한 요청은 "계획 세션"과 "실행 세션"을 분리하라고 해요.

이건 제가 Claude Code에서 Plan Mode를 쓰는 이유와 정확히 같아요. "이 기능 만들어줘"라고 바로 시키는 게 아니라, Plan Mode에서 먼저 "어떻게 만들 건지 설계해봐"를 시키고, 그 설계를 내가 검토한 다음에 실행으로 넘기는 거예요. Mitchell은 용어가 다르지만 같은 패턴을 독립적으로 발견한 거예요.

원칙 3: AI한테 검증 수단을 줘라

이게 제일 중요해요. Mitchell 원문 표현을 빌리면: "에이전트에게 자기 작업을 검증할 수단을 주면, 대부분의 경우 스스로 실수를 고치고 회귀를 방지한다."

이건 제 첫 번째 뉴스레터에서 깊이 다뤘던 내용이에요. 테스트를 분리하고, 린팅을 걸고, AI가 스스로 "내가 맞게 했나?"를 확인할 수 있게 해주면 결과물이 완전히 달라집니다. Anthropic의 공식 가이드에서도 "검증 수단을 줘라"를 가장 레버리지 높은 행동이라고 했고요.

여기서 Mitchell이 한 가지 더 중요한 걸 짚어요. "언제 AI를 안 쓸지를 아는 것도 효율이다." AI가 잘 못하는 작업에 AI를 쓰면 시간 낭비잖아요. 그 판단력을 기르는 것 자체가 1~2단계에서 삽질하면서 얻는 전문성이에요.

이 시점에서 Mitchell은 AI를 쓰는 게 직접 하는 것과 비슷한 속도가 됐대요. 아직 더 빠르진 않았고요. 에이전트를 베이비시팅하느라 시간이 들었으니까요. 근데 이게 2단계예요. 충분한 가치를 느끼지만, 아직 획기적인 효율 향상은 아닌 단계.

대부분의 사람들이 여기서 멈춰요. "AI 쓰는 거랑 직접 하는 거랑 비슷한데 뭐하러 AI를 써?" 근데 Mitchell은 여기서 멈추지 않았어요.

집중해서 코드를 작성하는 모습

내가 안 쓰는 시간을 AI한테 줘라

여기서부터가 진짜예요. Mitchell이 3단계로 넘어간 방법이 독특해요.

핵심 발상은 이거예요: "내가 일하는 시간을 더 효율적으로 쓰려고 하지 말고, 내가 일 안 하는 시간에 AI가 일하게 하자."

Mitchell은 매일 퇴근 전 30분을 비워두고, 에이전트를 띄워놓고 퇴근했어요. 밤새 돌린 건 아니고, 대부분 30분 이내에 끝나는 작업들이었는데, 종류가 세 가지였어요.

이건 발상의 전환이에요. 보통 "AI로 생산성 올리기"라고 하면 "내가 일하는 시간에 AI를 같이 써서 더 빨리 하자"잖아요. Mitchell은 그 대신 "내가 일 못하는 시간에 AI가 일하게 하자"고 한 거예요.

저도 이거 느꼈거든요. 하루 중 가장 비효율적인 시간이 언제인지 아세요? 오후 4시 이후예요. 집중력이 떨어지고, 플로우에서 빠져나와 있고, 뭔가를 새로 시작하기엔 애매한 시간이에요. Mitchell도 같은 말을 해요. "하루 후반부에는 보통 피곤하고 플로우에서 벗어나 있어서, 개인적으로 비효율적이다."

이 시간을 에이전트 세팅에 쓰면 어떻게 되냐면요. 다음 날 아침에 출근했을 때 "웜 스타트(warm start)" 상태가 되는 거예요. 리서치가 정리돼 있고, 이슈가 분류돼 있고, 어제 던져놓은 아이디어의 탐색 결과가 있으니까. 뭘 해야 할지 고민하는 시간이 줄어들어요.

이 시점에서 Mitchell은 "AI 없이는 못 돌아가겠다"까지는 아니었지만, "AI 전보다 확실히 더 많이 하고 있다"고 느꼈대요.

그다음은 "확실한 일"을 맡기기

퇴근 전 에이전트 패턴으로 효과를 본 Mitchell은 다음 단계로 넘어갑니다. 밤사이 정리된 이슈들 중에서 "AI가 거의 확실히 잘 해낼 작업"을 골라서 백그라운드로 돌려놓고, 본인은 다른 일을 한 거예요.

여기서 핵심이 뭐냐면요. Mitchell은 그 시간에 SNS를 보거나 유튜브를 본 게 아니에요. 본인이 하고 싶은 코딩, 또는 해야 하는 코딩을 했어요. AI 전과 동일한 딥씽킹 모드로 작업하면서, 백그라운드에서 에이전트가 다른 작업을 처리하게 한 거예요.

그리고 여기서 Mitchell이 아주 중요한 팁을 줘요:

컨텍스트 스위칭이 비싸다는 거예요. 에이전트가 "끝났어요!"라고 알림을 보내면 하던 일을 멈추고 확인하잖아요. 그럼 흐름이 끊겨요. Mitchell은 이렇게 해요. "에이전트가 나한테 알려주는 게 아니라, 내가 자연스러운 쉬는 시간에 확인하는 거다." 인간이 에이전트의 인터럽트를 통제해야 한다는 거예요. 반대가 되면 안 됩니다.

이건 제 강의 Ch5의 병렬 개발과 연결되는 이야기예요. 터미널 여러 개를 열어두고 각각 에이전트를 돌리면, 혼자인데 팀처럼 일할 수 있어요. 근데 그때도 핵심은 "내가 흐름을 유지하면서 에이전트를 관리하는 것"이지, 에이전트한테 끌려다니는 게 아니에요.

그리고 Mitchell이 여기서 Anthropic의 스킬 형성 논문을 언급해요. AI한테 다 맡기면 내 실력이 안 느는 거 아니냐는 우려요. Mitchell의 답은 명쾌해요. "에이전트한테 맡기는 일에서는 스킬이 안 늘겠지만, 그 시간에 직접 하는 일에서는 계속 스킬이 는다." 트레이드오프를 인정하되, 본인이 성장하고 싶은 영역은 직접 하고, 나머지는 에이전트한테 맡기는 거예요.

이 시점에서 Mitchell은 "절대 돌아갈 수 없는 영역"에 진입했대요. 효율적인 것도 좋았지만, 가장 좋았던 건 "내가 좋아하는 작업에 집중할 수 있게 된 것"이었다고요. 싫어하는 일은 에이전트한테 맡기고, 좋아하는 일에 코딩과 사고를 집중하는 거예요.

AI가 실수하면 시스템으로 막아라

Mitchell이 지금 집중하고 있는 단계가 이거예요. 그가 "하네스 엔지니어링(Harness Engineering)"이라고 부르는 개념이에요.

핵심은 심플해요: "에이전트가 실수하면, 그 실수가 다시는 일어나지 않도록 시스템을 만들어라."

에이전트가 처음에 올바른 결과를 내면 가장 효율적이잖아요. 두 번째로 좋은 건 최소한의 수정만 필요한 거고요. 이걸 달성하는 가장 확실한 방법은 에이전트한테 "네가 틀렸다"를 자동으로 알려주는 도구를 주는 것이에요.

Mitchell은 이걸 두 가지 형태로 나눠요:

형태 1: 암묵적 프롬프팅 (AGENTS.md)

에이전트가 반복적으로 잘못된 명령어를 실행하거나, 잘못된 API를 찾거나 할 때, AGENTS.md(또는 CLAUDE.md)에 규칙을 추가하는 거예요.

Mitchell은 Ghostty의 AGENTS.md를 공개했는데요. 그 파일의 모든 줄이 에이전트의 나쁜 행동에서 비롯된 것이래요. 에이전트가 잘못된 빌드 명령어를 실행했으면 "이 명령어를 써라"를 추가하고, 잘못된 디렉토리를 찾았으면 "이 경로를 봐라"를 추가하고. 하나씩 축적한 거예요.

이건 제가 이전 뉴스레터에서 CLAUDE.md 이야기를 하면서 강조한 것과 같아요. 근데 Mitchell이 한 단계 더 나간 포인트가 있어요. 수동적으로 규칙을 미리 쓰는 게 아니라, 에이전트가 실수할 때마다 반응적으로 추가한다는 거예요. 실수가 발생해야 규칙이 생기는 거죠. 머리로 예측해서 미리 쓰는 게 아니라, 실전에서 터진 것만 기록하는 거예요.

이 접근이 왜 좋냐면요:

이건 제 강의 Ch2에서 CLAUDE.md 작성법을 가르치면서 반드시 추가해야 할 관점이에요. "좋은 CLAUDE.md는 한 번에 쓰는 게 아니라, 에이전트와 일하면서 쌓아가는 것이다."

형태 2: 실제 프로그래밍된 도구

AGENTS.md만으로 해결이 안 되는 문제도 있어요. 그때는 스크립트나 도구를 직접 만드는 거예요.

예를 들어:

그리고 이 도구를 만들면 AGENTS.md에 "이 스크립트가 있다"고 알려주는 거예요. 에이전트가 도구를 쓸 수 있게요.

이걸 Mitchell은 이렇게 표현해요: "에이전트가 나쁜 짓을 할 때마다, 그 나쁜 짓이 다시는 일어나지 않도록 엔지니어링한다." 반대로, "에이전트가 좋은 짓을 하고 있다는 걸 스스로 확인할 수 있게 엔지니어링한다."

이게 왜 중요한지 제 경험을 하나 말씀드릴게요.

Claude Code로 작업하다 보면 에이전트가 가끔 엉뚱한 파일을 수정하거든요. "이 API 수정해줘"라고 했는데 관련 없는 유틸 파일까지 건드린다거나. 처음에는 그때마다 "야, 그 파일은 건드리지 마"라고 말했어요. 근데 매번 같은 말을 하는 건 제 시간 낭비잖아요.

그래서 CLAUDE.md에 이렇게 추가했어요:

- src/utils/ 디렉토리의 파일은 명시적으로 요청하지 않는 한 수정하지 마라.
  이 디렉토리의 유틸 함수들은 프로젝트 전체에서 사용하므로, 사이드 이펙트가 크다.

이 한 줄 추가한 이후로 그 문제가 사라졌어요. 내가 매번 말하던 걸 시스템이 대신 말해주는 거예요. 이게 하네스 엔지니어링의 본질이에요.

이전 뉴스레터에서 Anthropic이 "의도까지 설명하라"고 한 거 기억나시나요? 여기서도 같은 원리가 적용돼요. "수정하지 마라"만 쓰면 규칙이고, "왜 수정하면 안 되는지"까지 쓰면 에이전트가 의도를 이해해요. 비슷한 상황에서도 스스로 판단할 수 있게 되는 거죠.

항상 에이전트를 돌려라 — 근데 강제하지는 마라

Mitchell이 지금 실천하고 있는 목표가 하나 더 있어요. "항상 에이전트가 돌아가고 있어야 한다." 에이전트가 안 돌아가고 있으면 스스로 묻는대요. "지금 에이전트가 나를 위해 할 수 있는 일이 있나?"

근데 여기서 Mitchell이 아주 중요한 단서를 달아요:

이게 솔직한 현실이에요. Mitchell도 아직 하루 중 10~20%만 백그라운드 에이전트를 돌리고 있대요. 항상 돌리는 건 아직 목표일 뿐이고요. 에이전트한테 맡길 수 있는 양질의 작업 스트림을 만드는 것 자체가 도전이래요.

이 말이 와닿는 게, AI 도구가 만능이 아니라는 걸 인정하는 거잖아요. Mitchell은 AI 회사에 투자하지도, 일하지도, 자문하지도 않는다고 글 말미에 밝혀요. "이해관계가 없다(no skin in the game)"고요. 그래서 이 글이 신뢰가 가는 거예요. 과대광고가 아니라, 도구를 있는 그대로 평가하는 글이거든요.

그리고 여기서 Mitchell이 병렬 에이전트가 아니라 한 개만 돌린다고 말한 것도 주목할 부분이에요. "아직 여러 개는 안 돌리고, 솔직히 돌리고 싶지도 않다. 한 개가 지금은 적절한 균형이다. 딥한 수동 작업을 즐기면서, 좀 멍청하지만 신비롭게 생산적인 로봇 친구를 베이비시팅하는 것 사이의 균형."

이 표현이 좋아요. "좀 멍청하지만 신비롭게 생산적인 로봇 친구." AI에 대한 가장 현실적인 묘사인 것 같아요. 완벽하지 않아요. 가끔 멍청해요. 근데 뭔가 되긴 해요. 그래서 잘 쓰면 진짜 도움이 되는 거예요.

워크플로우와 생산성

Mitchell과 에피의 여정 비교

제가 이 글을 읽으면서 가장 인상 깊었던 건, 거의 같은 길을 걸었다는 거예요. 정리해보면 이래요:

근데 관점의 차이가 있어요.

Mitchell은 오픈소스 메인테이너예요. Ghostty라는 개인 프로젝트를 혼자 관리하면서, 이슈/PR이 쏟아지는 환경이에요. 그래서 "이슈 트리아지"나 "PR 리뷰"를 에이전트한테 맡기는 게 큰 가치인 거예요.

저는 현업 개발자였어요. 회사에서 팀의 코드베이스를 다루면서, 기존 코드의 패턴에 맞춰 작업해야 하는 환경이었죠. 그래서 제가 더 강조하는 건 "컨텍스트를 어떻게 전달하느냐"예요. 회사 코드베이스는 암묵적인 규칙이 엄청 많거든요. AI한테 그걸 알려줘야 해요.

근데 공통점이 있어요. 둘 다 "삽질을 통해 전문성을 쌓았다"는 거예요. 블로그 읽어서 안 되고, 영상 봐서 안 되고, 직접 부딪혀봐야 알게 되는 것들이 있어요. Mitchell은 이걸 "첫 번째 원리에서 직접 발견하면 더 강한 근본적 이해가 형성된다"고 표현해요.

이건 Anthropic이 우려한 "스킬 형성" 문제와도 연결돼요. AI를 쓰면 코딩 실력이 안 는다고? 그건 AI를 무지성으로 쓸 때 얘기예요. Mitchell처럼, 그리고 제가 하는 것처럼 "의도적으로 삽질하면서 AI와 일하는 법을 배우면" 오히려 새로운 종류의 전문성이 생겨요. 어떤 작업을 AI한테 맡기고 어떤 건 직접 해야 하는지 아는 것. 에이전트의 실수를 시스템으로 방지하는 법을 아는 것. 이게 2026년의 개발자 역량이에요.

그래서 지금 당장 뭘 하면 되냐면

Mitchell의 6단계를 그대로 따라 하라는 게 아니에요. 핵심은 자기 상황에 맞는 단계부터 시작하라는 거예요.

AI를 아직 안 써봤거나 별로였다면

챗봇 말고 에이전트를 쓰세요. ChatGPT 웹이나 Gemini 웹에서 코드를 복붙하는 건 AI 코딩이 아니에요. Claude Code 같은 에이전트를 설치하고, 터미널에서 직접 돌려보세요. 경험이 완전히 달라집니다.

# Claude Code 설치하고
npm install -g @anthropic-ai/claude-code

# 프로젝트 디렉토리에서 바로 실행
claude

그리고 처음 2주는 느려도 괜찮다는 걸 받아들이세요. Mitchell Hashimoto도 느렸어요. 저도 느렸어요. 그 삽질이 전문성이 됩니다.

이미 쓰고 있지만 효율이 안 느껴진다면

퇴근 전 30분 루틴을 만들어보세요. 하루 중 가장 비효율적인 시간에 에이전트를 세팅하고, 다음 날 아침에 결과를 확인하세요.

구체적으로:

이미 효과를 보고 있다면

하네스 엔지니어링을 시작하세요. 에이전트가 실수할 때마다, "이 실수가 다시는 안 일어나게 하려면?"을 생각하세요. CLAUDE.md에 한 줄 추가하든, 스크립트를 만들든. 이게 축적되면 에이전트의 성능이 프로젝트에 맞게 점점 좋아져요.

CLAUDE.md를 열어보세요. 지금 들어있는 규칙 중에 "에이전트가 실제로 잘못해서 추가한 것"과 "혹시 몰라서 미리 넣은 것"을 구분해보세요. 후자는 과감하게 지우세요. 전자만 남기면 CLAUDE.md가 더 정확하고 간결해집니다.

마무리

Mitchell이 글 마지막에 이렇게 말해요.

이게 핵심이에요. AI가 앞으로 어떻게 되든 상관없대요. 그냥 좋은 소프트웨어를 만들고 싶고, 그 과정에서 AI가 도움이 되니까 쓰는 거예요. 이게 건강한 AI 채택 자세인 것 같아요.

"AI가 세상을 바꿀 거다!" 이런 하이프도 아니고, "AI는 사기다!" 이런 부정도 아니고. "써봤더니 도움이 되니까 쓴다. 근데 삽질은 필요했다." 이게 Mitchell의 메시지이고, 제 경험이기도 해요.

한 문장으로 요약하면:

삽질을 피하면 전문성도 안 생깁니다. 처음에 느린 게 정상이에요. 그 시간이 아까우면 AI도 못 써요. 근데 그 시간을 투자하면, "절대 돌아갈 수 없는 영역"에 도달합니다. Mitchell처럼, 저처럼요.

다음 뉴스레터에서도 바이브 코딩과 AI 코딩 관련 실전 인사이트를 가져오겠습니다.

레퍼런스