- 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 사용 여부는 개인의 선택이며, 본 글은 도구 탐색과 활용 방식의 개인적 사례 공유 목적임