▲

나의 AI 도입 여정

 (mitchellh.com)
7P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 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 사용 여부는 개인의 선택이며, 본 글은 도구 탐색과 활용 방식의 개인적 사례 공유 목적임
▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 세션을 명확하고 실행 가능한 작업 단위로 나누는 게 핵심임
    너무 세세한 지시를 주면 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”과
    그에 대한 HN 토론을 참고할 만함

답변달기