# 나의 AI 도입 여정 > Clean Markdown view of GeekNews topic #26437. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26437](https://news.hada.io/topic?id=26437) - GeekNews Markdown: [https://news.hada.io/topic/26437.md](https://news.hada.io/topic/26437.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-02-06T09:23:49+09:00 - Updated: 2026-02-06T09:23:49+09:00 - Original source: [mitchellh.com](https://mitchellh.com/writing/my-ai-adoption-journey) - Points: 38 - Comments: 1 ## Summary HashiCorp를 엑싯하고 Ghostty를 만들고 있는 미첼 하시모토가 AI 도구를 실제 업무에 통합하기까지의 과정을 정리했습니다. AI 도입 과정을 **비효율에서 적응을 거쳐 생산성 향상으로 이르는 단계별**로 설명하는데요. 하루의 마지막 30분을 활용한 **야간 자동화 루틴**과 오류 방지를 위한 **하네스 엔지니어링**이 흥미롭습니다. ## Topic Body - HashiCorp를 엑싯하고 Ghostty를 만들고 있는 미첼 하시모토가 AI 도구를 실제 업무에 통합하기까지의 과정을 정리 - **비효율 → 적응 → 생산성 향상**의 세 단계로 구분하며, 각 단계에서의 시행착오와 학습 과정을 구체적으로 기록 - 챗봇 기반 코딩의 한계를 인식한 뒤, **에이전트 기반 도구**로 전환하면서 본격적으로 가치를 발견 - 기존에 수동으로 완료한 커밋을 에이전트로 재현하는 훈련을 통해 **작업 분해, 계획/실행 분리, 자동 검증**이 핵심임을 체득 - 하루 업무의 마지막 30분을 활용해 **야간 자동화 작업**을 수행하고, 반복 가능한 단순 업무를 **에이전트에 위임**하는 방식으로 **실질적 생산성 향상** - 현재는 **항상 하나의 에이전트를 실행**하며, 오류 방지를 위한 **‘하니스 엔지니어링’** 을 병행해 AI와 인간의 협업 효율을 극대화하는 단계 --- ### 도입 배경과 접근 방식 - 새로운 도구를 도입할 때마다 **비효율 → 적정 → 혁신**의 세 단계를 거쳐야 함 - 기존 워크플로에 익숙하기 때문에 초기 도입은 불편하지만, **장기적으로는 생산성 향상**으로 이어짐 - AI 도구에 대한 과도한 기대나 비판 대신, **실제 사용 경험에 기반한 균형 잡힌 시각**을 제시함 ### Step 1: 챗봇에서 벗어나기 - ChatGPT, Gemini 등 **챗봇 인터페이스**를 통한 코딩은 사전 학습에 의존하며, 오류 수정이 사람의 반복 피드백에 의존하므로 비효율적 - Zed의 커맨드 팔레트 스크린샷을 Gemini에 붙여넣어 SwiftUI로 재현한 것이 첫 "놀라운 순간"이었고, Ghostty macOS 커맨드 팔레트의 기초가 됨 - 그러나 **브라운필드 프로젝트**(기존 코드베이스) 맥락에서는 챗봇이 자주 나쁜 결과를 생성했고, 코드와 출력을 복사·붙여넣기하는 과정이 직접 작업보다 비효율적 - 가치를 얻으려면 반드시 **에이전트**를 사용해야 하며, 에이전트란 LLM이 외부 행동을 반복 호출할 수 있는 도구로 최소한 파일 읽기, 프로그램 실행, HTTP 요청 기능 필요 ### Step 2: 자신의 작업을 에이전트로 재현하기 - **Claude Code**를 처음 사용했을 때 결과물에 만족하지 못했고, 수정 작업이 직접 하는 것보다 오래 걸림 - 포기 대신, **수동 커밋을 에이전트로 동일하게 재현**하는 훈련을 반복 수행 - 같은 작업을 두 번(수동 + 에이전트) 하는 고통스러운 과정이었지만, 도구 도입 시 마찰은 자연스러운 것 - 이 과정에서 스스로 발견한 핵심 원칙 3가지: - 세션을 **명확하고 실행 가능한 단위 작업**으로 분해할 것 - 모호한 요청은 **계획 세션과 실행 세션**을 분리할 것 - 에이전트에 **작업 검증 수단**을 제공하면 스스로 실수를 수정하고 회귀를 방지 - 에이전트가 잘 못하는 영역을 파악해 **사용하지 않을 때를 아는 것**도 큰 효율 향상 요인 - 이 단계에서는 순 효율 향상은 느끼지 못했지만, 에이전트를 도구로서 만족스럽게 수용 ### Step 3: 하루 마무리 에이전트 활용 - **매일 마지막 30분**을 에이전트 작업 시작에 할당하는 패턴 도입 - 일하지 않는 시간에 에이전트가 진전을 이루면 효율을 얻을 수 있다는 가설 - 효과적이었던 작업 유형 3가지: - **딥 리서치 세션**: 특정 언어의 특정 라이선스 라이브러리 조사, 장단점·개발 활동·커뮤니티 반응 등 다중 페이지 요약 생성 - **병렬 에이전트로 모호한 아이디어 탐색**: 출시 목적이 아닌, 다음 날 작업 시 미지의 변수를 발견하기 위한 용도 - **이슈 및 PR 분류/리뷰**: `gh`(GitHub CLI)를 활용해 병렬 에이전트로 이슈 트리아지, 에이전트가 직접 응답하지는 않고 다음 날 참고할 보고서만 생성 - 에이전트를 밤새 반복 실행하지는 않았고, 대부분 30분 이내에 완료 - 하루 후반부 피로한 시간을 에이전트 작업에 전환함으로써 **다음 날 아침 "웜 스타트"** 효과 확보 ### Step 4: 확실한 작업 위임 - 에이전트가 거의 확실히 잘 해낼 작업을 파악한 후, 해당 작업을 **백그라운드 에이전트에 위임**하고 본인은 다른 작업에 집중 - 매일 아침 전날 밤 트리아지 결과를 수동 필터링해 에이전트에 적합한 이슈를 선별, 한 번에 하나씩 실행 - 이 시간에 SNS나 영상이 아닌 **기존 AI 이전 방식의 깊은 사고 작업**을 직접 수행 - **에이전트 데스크톱 알림 끄기**가 핵심: 컨텍스트 스위칭 비용이 크므로 에이전트가 사람을 인터럽트하는 것이 아니라, 자연스러운 휴식 시점에 확인하는 방식이 효율적 - Anthropic의 **스킬 형성 연구 논문**에 대한 대응: 에이전트에 위임한 작업의 스킬 형성은 포기하지만, 수동으로 계속하는 작업에서는 자연스럽게 스킬 형성 지속 - 이 단계에서 **"이전으로 돌아갈 수 없는" 수준**에 도달, 좋아하는 작업에 집중할 수 있게 된 것이 가장 큰 장점 ### Step 5: 하네스 엔지니어링 - 에이전트가 첫 번째 시도에 올바른 결과를 내거나 최소한의 수정만 필요할 때 가장 효율적 - 에이전트가 실수할 때마다 **같은 실수를 다시는 하지 않도록 해결책을 엔지니어링**하는 것이 "**하네스 엔지니어링**" 개념 - 두 가지 형태: - **암시적 프롬프팅 개선(AGENTS.md)**: 에이전트가 잘못된 명령을 실행하거나 잘못된 API를 찾는 경우, `AGENTS.md` 파일에 기록해 해결 — Ghostty 리포지토리에 실제 예시 존재 - **프로그래밍된 도구**: 스크린샷 캡처, 필터링된 테스트 실행 등의 스크립트를 작성하고 AGENTS.md에 해당 도구의 존재를 알림 - 현재 이 단계에 있으며, 에이전트의 나쁜 행동 방지와 좋은 행동 검증에 적극 투자 중 ### Step 6: 항상 에이전트 실행 상태 유지 - Step 5와 병행하여 **항상 하나의 에이전트가 백그라운드에서 실행 중인 상태**를 목표로 설정 - Amp의 **deep mode**(GPT-5.2-Codex 기반)처럼 30분 이상 소요되지만 높은 품질의 결과를 내는 느린 모델 선호 - 현재 **복수 에이전트 병렬 실행은 하지 않으며**, 에이전트 하나와 수동 작업 사이의 균형이 적절하다고 판단 - 실제로는 근무 시간의 **10~20% 정도**만 백그라운드 에이전트가 돌아가는 상태이며, 비율 개선을 위해 노력 중 - 에이전트 실행 자체가 목적이 아니라, **진정으로 도움이 되는 작업이 있을 때만** 실행해야 하며, 위임 가능한 고품질 작업 흐름을 만드는 것이 AI 유무와 무관하게 중요 ### 현재 상태와 관점 - AI 도구로 성과를 내고 있으며, 현실에 기반한 **균형 잡힌 시각**으로 접근 중 - AI 회사에 근무하거나 투자하거나 자문하는 관계가 없으며, AI의 존속 여부에 무관하게 **소프트웨어 장인으로서 만들기를 즐기는 것**이 핵심 동기 - 기초가 약한 주니어 개발자들의 **스킬 형성 문제**에 대해서는 깊이 우려하고 있음 - 모델 혁신 속도가 빠르기 때문에 에이전트가 못하는 영역에 대한 판단을 **지속적으로 재검토**해야 함 - AI 사용 여부는 개인의 선택이며, 본 글은 **도구 탐색과 활용 방식의 개인적 사례 공유** 목적임 ## Comments ### Comment 50695 - Author: neo - Created: 2026-02-06T09:23:49+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46903558) - 세션을 명확하고 실행 가능한 **작업 단위**로 나누는 게 핵심임 너무 세세한 지시를 주면 LLM을 쓸 이유가 없고, 반대로 “개를 위한 Facebook 앱 만들어줘”처럼 너무 광범위하면 쓸모없는 프로토타입만 나옴 결국 성공적인 코드용 LLM 활용은 이 **적정 범위**를 찾는 일임 - AI 도구를 쓸 때 가장 즐기는 부분이 바로 이 **직관 형성**임 어떤 작업을 맡기면 좋은 결과가 나오는지 감을 잡고, 그에 맞게 범위를 조정하는 과정이 프로그래밍의 모듈화와 비슷한 즐거움을 줌 - “Facebook for dogs” 예시처럼 너무 큰 요청을 줬다가 실패했음 Lovable에서는 온보딩부터 실패를 유도하는 느낌이었고, 대신 Claude Code로 **작게 쪼개서 진행**하니 훨씬 성공적이었음 - LLM을 단순히 `for` 문법 예시 찾는 용도로 쓰면 **컨텍스트 전환**을 줄일 수 있어서 편함 초기에는 이런 단순한 코드 작성 보조로 많이 활용했음 - 모델이 발전할수록 그 **적정 범위의 상한선**이 6~8주마다 올라가는 느낌임 - 가끔 “출력을 출력해줘”라고 말했더니 정말로 `print(output)`만 추가하는 식으로 반응함 자연어와 코드 사이를 오가며 작업하는 게 오히려 **심리적으로 편하게 느껴짐** - 2025년은 AI 코딩 도구가 진짜로 **실용 단계**에 들어선 해였음 예전엔 GPT-3 같은 초기 모델이 가능성만 보여줬고, 그로 인해 과도한 **하이프와 회의론**이 생겼음 하지만 지금은 많은 개발자들이 실제 워크플로우에 AI를 통합하고 있음 아직 회의적인 개발자라면 Mitchell의 글을 읽고 Claude Code를 직접 써보길 권함 - 나도 같은 생각임. 10년 뒤엔 어떤 시점을 **전환점**으로 기억할지 궁금함 한때는 “데이터 한계” 얘기가 많았는데, Claude Code, Sonnet 4.5, Opus 4.5가 나오면서 분위기가 완전히 바뀌었음 - Claude Code를 Codex나 Gemini 대신 써야 할 이유가 있는지 궁금함 두 모델은 비슷했는데, Claude는 **요금제 사용량 제한**이 빠르게 닳는다는 얘기 때문에 아직 안 써봤음 - 하지만 여전히 **하이프 중심의 산업 구조**가 걱정임 경영진이 속도와 양만 중시하다가 유지 불가능한 코드 더미를 양산할까 두려움 - “Don’t draw the owl” 접근법이 내 경험과도 일치함 LLM이 점점 **현실 제약에서 벗어나며 드리프트**하는 게 문제였음 그래서 채팅은 설계 논의용으로, 에이전트는 **좁고 검증 가능한 diff 작업**만 맡기도록 분리했음 이 루프가 안정되자 장난감이 아니라 **진짜 레버**가 되었고, 실제 프로젝트 기능을 여러 번 배포했음 - 글의 문체가 LLM을 닮았다는 지적을 받음 요즘 이런 **패턴화된 문장 구조**가 사람들 사이에서도 늘고 있어서 흥미로움 - 이런 접근이 사실 우리가 **원래 소프트웨어를 짜야 했던 방식**과 다르지 않다는 생각도 듦 - Opus 4.5 관련 논의가 많아져서 직접 써봤는데, **에이전트 패러다임**이 확실히 유용해졌음을 느낌 아직은 단순한 작업 위주지만 만족스러움 - LLM은 나에게 맞지 않음 인간의 **사고력과 창의성**이 우리를 구분 짓는 요소인데, 이를 기계에 넘기면 스스로를 약화시킨다고 느낌 Rails 개발자로서 Zed와 Claude Sonnet 4.x, Opus를 써봤지만, 점점 **RSpec 작성 능력**이 줄어드는 걸 체감했음 결국 neovim으로 돌아가 에이전트 없이 일함 편리함은 결국 **사고력의 퇴화**를 부를 수 있음 LLM은 인간이 만든 **최고의 편의 도구**지만, 나는 내 기술과 사고를 유지하는 쪽을 택함 - 이번 글은 다른 프론트페이지 글보다 훨씬 **실용적이고 덜 과장된** 느낌임 - 드디어 회의적인 사람도 따라 해볼 수 있는 **단계별 가이드**가 나왔음 “분위기 코딩으로 OS를 만들었다” 같은 과장 대신 현실적인 접근임 - 다들 비슷한 **AI 활용 여정**을 겪고 있는 게 흥미로움 여러 모델을 병행해 코드베이스의 다른 부분에 적용하고, 모델끼리 **상호 검증**하게 함 여전히 git reset을 자주 하지만, 점점 더 효율적으로 피할 방법을 배우는 중임 마치 **두뇌 자동완성** 시대에 살고 있는 기분임 - “에이전트는 파일 읽기, 프로그램 실행, HTTP 요청이 가능해야 한다”는 말이 있었는데, 이건 Simon Willison이 말한 **‘치명적 삼합체’** 와 거의 같은 수준임 - 그래서 난 절대 내 로컬 머신에서 그걸 돌리지 않을 생각임 - 에이전트에게 개선점을 계속 알려줘야 하는 게 **짜증**남 매번 agent.md를 수정하며 피드백을 줘야 하는데, 스스로 학습해서 개선되면 좋겠음 - 하지만 누군가의 개선이 다른 사람에겐 **코드 스멜**일 수 있음 AGENTS.md에 몇 줄 추가하는 건 그리 큰 일도 아님 `/fix` 명령을 만들어 자동으로 수정하고 문서화하게 하면 꽤 **시간 절약**됨 - 난 오히려 피드백 주는 걸 즐김 내가 **엔지니어링의 주도권**을 쥐고 있다는 느낌을 줌 특히 새로운 기능 리서치와 구현을 빠르게 반복할 수 있어서 좋음 - 실제로 이런 접근이 어떻게 보이는지 궁금하다면, OP의 과거 블로그 글 [“Non-trivial Vibing”](https://mitchellh.com/writing/non-trivial-vibing)과 그에 대한 [HN 토론](https://news.ycombinator.com/item?id=45549434)을 참고할 만함