본 글은 Mitchell Hashimoto의 글을 읽고 정리한 글이다.
AI를 둘러싼 이야기는 대체로 두 갈래로 흐른다. 하나는 모든 것이 곧 AI로 대체될 것이라는 과장된 낙관론이고, 다른 하나는 아직은 실무에서 믿고 쓰기 어렵다는 냉소다.
그런데 실제로 생산성을 만들어내는 사람들의 이야기는 중간 어딘가에 있다. Mitchell Hashimoto가 2026년 2월에 쓴 "My AI Adoption Journey" 도 그런 글이다.
이 글은 특정 모델을 찬양하는 글도 아니고, 반대로 AI를 무의미한 유행으로 치부하는 글도 아니다. 그는 자신이 AI를 어떤 순서로 받아들였고, 어디에서 실망했고, 어느 시점부터 실질적인 가치를 느꼈는지를 여섯 단계로 정리한다.
Hashimoto는 새로운 도구를 도입할 때 대체로 세 시기를 거친다고 말한다.
처음에는 비효율의 시기가 있고, 그다음에는 그럭저럭 쓸 만한 단계가 오고, 마지막에는 워크플로우 자체를 바꾸는 수준의 발견에 도달한다는 것이다.
AI도 예외가 아니었다. 이미 손에 익은 방식이 있는데 새로운 도구를 배우는 일은 그 자체로 비용이 들고, 그래서 대개 사람은 초반의 불편함을 견디지 못한 채 포기한다. 그럼에도 그는 그 비효율의 시기를 통과해야만 진짜 판단이 가능하다고 얘기한다. 이것이 중요한 이유는, AI 도입을 단순히 “좋으냐 나쁘냐”로 나누지 않고, 도구 채택의 자연스러운 학습 곡선으로 보기 때문이다.
그의 첫 번째 결론은 의외로 단호하다. 의미 있는 코딩 작업을 웹 챗봇 인터페이스에서 하려는 시도를 그만두라는 것이다. ChatGPT나 Gemini 같은 챗 인터페이스는 여전히 가치가 있지만, 복잡한 코드 작업에서는 한계가 분명하다고 얘기한다.
특히 기존 코드베이스처럼 맥락이 많은 환경에서는 결과가 자주 어긋나고, 사람이 코드와 로그를 복사해 붙여넣으며 계속 오류를 바로잡아야 하므로 오히려 비효율적이라는 판단이다. 그가 본격적으로 가치를 느낀 지점은 챗봇이 아니라 에이전트였다. 그가 말하는 에이전트는 단순히 대화하는 모델이 아니라, 파일을 읽고, 프로그램을 실행하고, HTTP 요청을 보내며, 이런 행동을 반복 루프 안에서 수행할 수 있는 형태의 도구다. 즉, “답해주는 AI”보다 “일할 수 있는 AI”가 필요하다는 이야기다.
두 번째 단계에서 그는 AI에게 자신의 일을 맡기기 전에 먼저 아주 불편한 실험을 한다. 사람이 직접 한 작업을, 에이전트만으로 다시 재현해보는 것이다. 같은 일을 두 번 하는 셈이니 당연히 비효율적이다. 실제로 그는 이 과정을 고통스럽다고 표현한다. 하지만 이 반복 속에서 중요한 감각이 생겼다고 말한다.
하나의 거대한 세션으로 모든 것을 해결하려고 하면 실패 확률이 높고, 작업은 명확하고 실행 가능한 작은 단위로 나눠야 한다는 점이다. 또 요청이 모호하다면 계획 단계와 실행 단계를 분리해야 하며, 에이전트가 자기 결과를 검증할 수 있는 방법을 주면 스스로 실수를 고치고 회귀를 줄일 가능성이 높아진다는 점도 확인한다.
결국 여기서 얻은 가장 큰 성과는 “AI가 무엇을 잘하는가”보다 “AI에게 무엇을 맡기면 안 되는가”를 배운 데 있었다. 이 경계를 아는 것만으로도 시간 낭비를 크게 줄일 수 있기 때문이다.
대부분 많은 사람들이 지금도 AI 생산성을 모델의 지능에서만 찾으려 하고 있다. Hashimoto의 경험은 조금 다르다. 생산성은 더 똑똑한 모델에서만 오지 않는다. 오히려 실패할 일을 애초에 던지지 않는 판단, 모호한 일을 계획과 실행으로 분리하는 습관, 검증 수단을 함께 주는 방식 같은 운영 감각에서 더 많이 나온다. 즉, AI를 잘 쓰는 능력은 “좋은 질문을 던지는 능력”만이 아니라 “실패할 조건을 미리 제거하는 능력”에 가깝다.
그는 이 단계에서 이미 에이전트를 워크플로우 안에 넣을 수 있을 정도의 가치를 느꼈지만, 아직 자신보다 확실히 빠르다고 생각하지는 않았다고 얘기한다.
세 번째 단계는 하루의 끝을 활용하는 방식이다. 그는 근무 마지막 30분 정도를 따로 확보해 하나 이상의 에이전트를 실행한다. 사람의 집중력은 하루 후반부로 갈수록 떨어지고, 이때 억지로 깊이 있는 작업을 계속하기보다 에이전트를 돌려 다음 날의 준비물을 만들어두는 편이 낫다고 본 것이다.
여기에는 몇 가지 유형이 있다. 특정 언어나 라이선스 조건에 맞는 라이브러리를 조사해 장단점과 개발 현황, 커뮤니티 반응까지 정리하게 하는 딥 리서치, 아직 모양이 잡히지 않은 아이디어를 병렬적으로 탐색하는 시도, 그리고 GitHub 이슈나 PR을 분류하고 검토 보고서를 만드는 일이 대표적이다.
그는 에이전트를 밤새 무한 루프로 돌리는 극단적인 방식까지 간 것은 아니라고 분명히 얘기한다. 대부분의 작업은 30분 이내에 끝났다. 그러나 그 정도만으로도 다음 날 아침 더 빨리 일에 들어갈 수 있는 “웜 스타트”가 만들어졌다고 평가한다.
우리는 흔히 AI가 사람보다 즉시 빠르고 정확해야만 유용하다고 생각한다. 하지만 실제 업무에서는 사람이 일하지 못하는 시간에 다음 작업의 맥락과 재료를 준비해두는 것만으로도 충분히 큰 가치가 생긴다.
AI는 사람과 경쟁하는 속도 도구가 아니라, 사람의 비가동 시간을 생산적인 준비 시간으로 바꾸는 장치가 될 수 있다는 뜻이다. 여기서 중요한 것은 완전 자동화가 아니라, 사람의 리듬에 맞춘 보조다. Hashimoto의 경험은 AI 활용이 반드시 실시간 협업만을 의미하지 않으며, 비동기적으로도 충분히 강력할 수 있음을 보여준다.
네 번째 단계에서 그는 조금 더 과감해진다. 이제는 에이전트가 거의 틀리지 않을 것 같은 일을 골라, 백그라운드에서 실제로 맡기기 시작한다. 전날 밤 에이전트가 분류해둔 이슈나 작업 목록을 보고, 그중 성공 확률이 높은 것만 골라 하나씩 돌려두고, 자신은 그동안 다른 깊은 작업을 한다.
여기서 그가 강조하는 원칙 하나는 에이전트의 데스크톱 알림을 꺼야 한다는 것이다. 이유는 단순하다. 컨텍스트 스위칭 비용이 크기 때문이다. 인간이 언제 에이전트를 통제해야지, 에이전트가 사람의 집중을 끊어서는 안 된다.
자연스러운 휴식 구간이나 전환 지점에서만 에이전트를 확인하고 다시 자기 일로 돌아가야 한다는 것이다. 이 원칙은 AI 도입의 문제를 기술 문제가 아니라 주의력 관리 문제로도 바라보게 만든다.
그는 이 단계가 AI가 기술 형성을 해칠 수 있다는 우려와도 일정한 균형을 만든다고 본다. 덜 중요하거나 비교적 확실한 작업은 에이전트에게 맡기되, 자신이 계속 성장하고 싶은 영역의 작업은 여전히 수작업으로 유지하는 방식이다.
이 우려는 과장된 것이 아니다. Anthropic이 2026년 1월 공개한 연구는, 새로운 Python 라이브러리를 익히는 과제에서 AI 도움을 받은 참가자들이 도움을 받지 않은 집단보다 개념 이해, 코드 읽기, 디버깅 능력에서 더 낮은 점수를 기록했다고 보고했다.
논문 초록은 평균적으로 유의미한 효율 향상도 크지 않았으며, 특히 과제를 AI에 많이 위임할수록 학습 손실이 커졌다고 설명한다. 반면 AI를 단순 대행자가 아니라 설명과 분석 보조 도구로 쓴 참가자들은 상대적으로 더 나은 학습을 보였다는 해석도 함께 나온다. 결국 문제는 AI 사용 여부 자체가 아니라, 무엇을 위임하고 무엇을 직접 이해할 것인가에 대한 것이다.
다섯 번째 단계에서 이 글의 핵심이 나온다. 바로 “Engineer the Harness” 하네스를 설계하라는 말이다. Hashimoto는 에이전트가 처음부터 맞는 결과를 내거나, 최소한 아주 적은 수정만 필요하도록 만들수록 효율이 급격히 높아진다고 봤다. 그리고 이를 위한 가장 확실한 방법은, 에이전트가 틀렸을 때 빠르고 정확하게 틀렸음을 알려주는 좋은 도구를 주는 것이라고 말한다.
그는 이 접근을 “하네스 엔지니어링”이라 부른다. 뜻은 명확하다. 에이전트가 어떤 실수를 했다면, 그 실수를 다시는 반복하지 못하도록 환경과 도구를 설계하는 것이다. 이 발상이 중요한 이유는 AI 활용의 중심을 프롬프트에서 시스템 설계로 이동시키기 때문이다. 반복되는 실수를 사람의 인내로 감당하는 대신, 작업 환경의 규칙과 검증 장치로 흡수하는 것이다.
그는 하네스 엔지니어링을 두 가지 형태로 설명한다.
첫째는 더 나은 암묵적 프롬프팅이다. 예를 들어 AGENTS.md 같은 파일에, 에이전트가 자주 잘못 사용하는 명령어, 자주 엉뚱하게 찾는 API, 특정 서브시스템에서 먼저 확인해야 하는 파일, 플랫폼별 검증 방법 같은 맥락 정보를 짧고 구체적으로 적어두는 방식이다.
Hashimoto는 Ghostty 저장소의 AGENTS.md를 사례로 제시하며, 그 파일의 각 줄이 실제로 나쁜 에이전트 행동 하나를 겨냥해 추가된 것이고 결과적으로 문제를 거의 해결했다고 말한다.
둘째는 실제 도구다. 스크린샷을 찍는 스크립트, 일부 테스트만 빠르게 실행하는 스크립트, 결과를 필터링해 이상 여부를 바로 확인하는 도구 등이 여기에 속한다.
핵심은 에이전트가 결과를 스스로 검증할 수 있어야 한다는 점이다. 사람의 눈으로만 확인해야 하는 작업은 결국 병목이 된다. 반대로 검증이 자동화되면, AI는 “시도하는 도구”에서 “자기 오류를 교정하는 시스템의 일부”가 된다.
이 부분이 특히 중요한 이유는, 소프트웨어 엔지니어링의 좋은 원칙과 정확히 닿아 있기 때문이다.
좋은 팀은 버그를 하나 고치고 끝내지 않는다. 왜 그 버그가 다시 생기지 않게 할 것인지까지 고민한다. 테스트를 추가하고, 린트 규칙을 넣고, 배포 전 체크를 강화하고, 문서와 실행 규칙을 손본다.
Hashimoto가 말하는 하네스 엔지니어링은 사실 AI 시대에 새로 생긴 마법이 아니라, 익숙한 프로그래밍 원칙을 AI 작업에 그대로 확장한 것이다.
에이전트가 잘못했다면 그것은 한 번의 실패가 아니라, 다음부터 시스템으로 줄일 수 있는 결함 패턴이다. 따라서 AI를 잘 쓰는 사람은 답변을 더 정교하게 유도하는 사람이라기보다, 실패를 재발 방지 가능한 구조로 바꾸는 사람에 가깝다.
여섯 번째 단계는 “항상 에이전트 하나는 돌아가고 있는 상태”를 목표로 삼는 것이다. 그는 아직 여러 에이전트를 동시에 대규모로 운영하고 싶지는 않다고 말한다. 다만 최소한 하나의 에이전트는 가능한 자주 백그라운드에서 일하고 있기를 바란다.
에이전트가 돌아가고 있지 않을 때면, 지금 당장 에이전트가 대신 할 수 있는 일이 없는지 스스로 묻는다는 것이다. 다만 여기서도 그는 중요한 선을 긋는다. 에이전트를 돌리기 위해 억지로 일을 만드는 것이 목적은 아니다. 실제로 도움이 되는 일이 있을 때만 돌려야 한다. 그래서 이 목표를 실현하려면, 자신의 워크플로우 자체를 개선해 위임 가능한 고품질 작업이 꾸준히 나오도록 만들어야 한다고 본다.
그는 현재 자신이 근무 시간의 대략 10~20% 정도만 이런 방식으로 효과적으로 운영하고 있다고 밝힌다. 이 수치는 AI 도입이 완성형이 아니라 계속 다듬어가는 과정임을 보여준다.
마지막으로 그는 자신이 AI 기업에서 일하지도, 투자하지도, 자문하지도 않는다고 밝힌다. 또 AI가 영원히 남을지 여부보다, 지금 자신이 무언가를 만드는 데 실제로 도움이 되는지가 더 중요하다고 말한다.
AI 시대의 생산성 차이는 누가 더 화려한 프롬프트를 쓰느냐에서 갈리지 않는다. 진짜 차이는 누가 더 좋은 작업 환경을 설계하느냐에서 발생한다.
챗봇에 멋진 질문을 던지는 능력은 출발점일 수 있지만, 지속적인 생산성의 원천은 아니다. 더 큰 차이는 에이전트가 일할 수 있는 문맥을 만들고, 잘못된 행동을 빠르게 잡아내고, 반복되는 실수를 규칙과 도구로 제거하며, 사람은 더 중요한 문제에 집중할 수 있도록 일의 배치를 다시 짜는 데서 생긴다.
그런 의미에서 Hashimoto의 여정은 AI 사용 팁이라기보다, 새로운 도구를 실무에 흡수하는 엔지니어링 방법론에 가깝다. AI를 잘 쓰는 사람은 프롬프트를 다듬는 데서 멈추지 않는다. 결국 하네스를 만든다.
