의미 있는 도구를 받아들이는 과정에서 겪은 단계들, 그리고 AI 에이전트를 실제 작업 흐름에 통합하며 얻은 교훈을 정리한 글.
2026년 2월 5일
목차
내가 의미 있는 도구를 받아들일 때의 경험은 늘 세 단계를 거친다는 것이다. (1) 비효율의 시기, (2) 그럭저럭 충분한 시기, 그리고 마지막으로 (3) 작업 방식과 삶을 바꾸는 발견의 시기다.
대부분의 경우 나는 이미 만족스럽고 편안하게 쓰고 있는 작업 흐름이 있기 때문에, 1단계와 2단계를 억지로라도 통과해야 한다. 새로운 도구를 도입하는 일은 일처럼 느껴지고, 나는 정말로 그 노력을 들이고 싶지 않다. 하지만 대개는 내 분야에서 균형 잡힌 사람이 되기 위해 결국 그렇게 한다.
이 글은 내가 AI 도구에서 어떻게 가치를 찾게 되었는지, 그리고 다음으로 무엇을 시도하고 있는지에 대한 여정이다. 지나치게 극적이고 과장된 의견이 넘쳐나는 바다 속에서, 이 글이 AI에 대한 내 시각과 그것이 시간에 따라 어떻게 바뀌었는지를 좀 더 미묘하고 신중하게 보여주는 접근이 되기를 바란다.
이 블로그 글은 전부 손으로, 내 말로 직접 썼다. 이런 말을 굳이 해야 한다는 게 싫지만, 특히 주제가 주제인 만큼 이 점은 분명히 밝히고 싶다.
의미 있는 작업을 챗봇(예: ChatGPT, 웹의 Gemini 등)으로 처리하려는 시도를 즉시 멈춰라. 챗봇은 분명한 가치가 있고 내 AI 작업 흐름의 일상적인 일부이기도 하지만, 코딩에서의 효용은 매우 제한적이다. 대부분은 그들이 사전 학습에 기반해 우연히 올바른 결과를 내놓기를 바라는 셈이고, 틀렸을 때 바로잡는 과정에는 반복해서 "그건 틀렸어"라고 말해 줄 인간, 즉 당신이 필요하다. 비효율적이다.
나는 모두가 AI를 처음 접하는 경험은 채팅 인터페이스라고 생각한다. 그리고 AI로 코딩을 처음 시도하는 경험도 채팅 인터페이스에게 코드를 써 달라고 하는 것이라고 생각한다.
내가 아직 강한 AI 회의론자였을 때, 처음으로 "와" 했던 순간은 Zed의 명령 팔레트 스크린샷을 Gemini에 붙여 넣고, 그것을 SwiftUI로 재현해 달라고 요청했을 때였다. 그리고 그것이 정말 잘 해내는 것을 보고 진심으로 어안이 벙벙했다. 오늘날 Ghostty의 macOS용 명령 팔레트는 Gemini가 몇 초 만에 만들어 준 결과물에서 아주 가볍게만 수정된 것이다.
하지만 다른 작업에서도 그 행동을 재현하려고 했을 때는 실망만 남았다. 이미 진행 중인 프로젝트의 맥락에서는 채팅 인터페이스가 매우 자주 형편없는 결과를 냈고, 코드와 명령 출력 결과를 인터페이스로 복사하고 다시 붙여 넣는 과정도 매우 답답했다. 내가 직접 작업하는 것보다 훨씬 비효율적이라는 것이 너무도 분명했다.
가치를 찾으려면 반드시 에이전트를 써야 한다. 에이전트는 업계에서 통용되는 용어로, 대화하면서 외부 동작을 반복적으로 호출할 수 있는 LLM을 뜻한다1. 최소한 에이전트는 파일 읽기, 프로그램 실행, HTTP 요청 수행 능력을 갖추어야 한다.
여정의 다음 단계에서 나는 Claude Code를 시도해 봤다. 결론부터 말하자면, 처음에는 인상적이지 않았다. 세션에서 좋은 결과를 잘 얻지 못했다. 생성된 결과물을 거의 전부 손봐야 한다고 느꼈고, 그 과정은 내가 그냥 직접 했을 때보다 더 오래 걸렸다. 블로그 글도 읽고, 영상도 봤지만, 그다지 감명받지 못했다.
포기하는 대신, 나는 내가 수동으로 만든 모든 커밋을 에이전트 방식으로 다시 재현하도록 나 자신을 강제했다. 말 그대로 일을 두 번 한 것이다. 먼저 수동으로 작업한 뒤, 에이전트가 품질과 기능 면에서 동일한 결과를 내놓도록 씨름했다(물론 내가 수동으로 만든 해법은 보지 못하게 한 채로).
이 과정은 끔찍할 정도로 고통스러웠다. 단순히 일을 해치우는 데 방해가 되었기 때문이다. 하지만 나는 AI가 아닌 도구들과도 오랫동안 씨름해 본 경험이 있어서, 마찰은 자연스러운 것이며 내 노력을 끝까지 다해 보기 전에는 확고하고 방어 가능한 결론에 도달할 수 없다는 걸 알고 있었다.
그러나 숙련은 형성되었다. 다른 사람들이 이미 말하고 있던 내용을 나는 곧바로 스스로 처음 원리에서부터 발견하게 되었고, 그것을 직접 발견한 덕분에 훨씬 더 강한 기초적 이해를 갖게 되었다.
좀 더 일반적으로는, 에이전트가 -- 그 시점에서는 -- 무엇을 잘하는지, 무엇을 잘하지 못하는지, 그리고 잘하는 작업에서는 내가 원하는 결과를 어떻게 끌어낼 수 있는지에 대한 경계도 파악하게 되었다.
이 모든 것은 상당한 효율 향상으로 이어졌고, 결국에는 내가 직접 하는 것보다 느리지 않다고 느껴질 정도로 에이전트를 자연스럽게 활용하게 되었다(다만 여전히 내가 주로 에이전트를 지켜보고 있었기 때문에 더 빠르다고까지는 느끼지 못했다).
여기서 강조할 만한 부정 공간은 이것이다. 효율 향상의 일부는 언제 에이전트를 쓰지 말아야 하는지를 이해하는 데서 왔다. 실패할 가능성이 높은 작업에 에이전트를 쓰는 것은 명백한 시간 낭비이며, 그것을 피할 지식을 갖추는 것만으로도 시간 절약으로 이어진다2.
이 단계에서 나는 에이전트에서 충분한 가치를 발견했고, 기꺼이 작업 흐름에 포함시킬 정도가 되었다. 그래도 순효율이 늘었다고까지는 느끼지 못했다. 하지만 상관없었다. 이 시점에서 나는 AI를 하나의 도구로 받아들이는 데 만족하고 있었다.
효율을 좀 더 찾아보기 위해, 다음으로 나는 새로운 패턴을 시작했다. 매일 마지막 30분을 비워 두고 하나 이상의 에이전트를 돌리는 것이다. 내 가설은 이랬다. 어차피 내가 일할 수 없는 시간에 에이전트가 긍정적인 진전 이라도 만들어 낼 수 있다면, 아마도 효율을 얻을 수 있지 않을까? 기본적으로는 이렇다. 내가 가진 시간 안에서 더 하려 하기보다, 내가 가지지 않은 시간 안에서 더 해 보자는 것이다.
앞선 단계와 비슷하게, 처음에는 이것도 성공적이지 않고 짜증나는 방식이라고 느꼈다. 하지만 이번에도 나는 금세 정말 도움이 되는 여러 작업 범주를 찾게 되었다.
gh(GitHub CLI)를 잘 다루기 때문에, 나는 여러 개를 병렬로 띄워 이슈를 분류할 수 있도록 간단한 스크립트를 수동으로 만들었다. 나는 에이전트가 직접 응답하도록 두지는 않았다. 다음 날 보고서만 받아서, 가치가 크거나 적은 노력으로 처리할 수 있는 작업 쪽으로 나를 안내해 주기만을 원했다.분명히 해 두자면, 나는 다른 사람들처럼 에이전트를 밤새 반복 실행시키는 데까지 나아가지는 않았다. 대부분의 경우 에이전트는 30분도 안 되어 작업을 끝냈다. 하지만 업무 시간 후반부에는 보통 피곤하고 몰입 상태에서도 벗어나서, 개인적으로도 효율이 떨어진다. 그래서 그 시간의 노력을 이런 에이전트를 띄우는 데 전환하니, 다음 날 아침 내가 원래보다 더 빨리 일을 시작할 수 있는 "웜 스타트"를 얻게 되었다.
나는 만족스러웠고, 비록 아주 조금일지라도 AI 이전보다 더 많은 일을 하고 있다는 느낌이 들기 시작했다.
이 시점이 되자, 내 AI가 어떤 작업을 잘하고 어떤 작업을 잘하지 못하는지에 대해 상당한 확신이 생겼다. 특정 작업들에 대해서는 AI가 대부분 올바른 해법을 내놓을 것이라는 신뢰가 매우 높아졌다. 그래서 내 여정의 다음 단계는 이것이었다. 그런 작업은 전부 에이전트에게 맡기고, 나는 다른 작업을 하는 것이다.
좀 더 구체적으로 말하면, 나는 매일 아침 전날 밤 돌려 둔 분류 에이전트의 결과를 보고, 에이전트가 거의 확실하게 잘 해결할 수 있는 이슈만 수동으로 골라낸 다음, 그것들을 백그라운드에서 계속 돌려 두었다(병렬이 아니라 한 번에 하나씩).
그동안 나는 다른 일을 했다. 소셜 미디어를 보러 가는 것도 아니고(AI가 없을 때보다 더 자주 그러는 것도 아니고), 영상을 보는 것도 아니었다. 나는 내가 원래 하던, AI 이전의 깊은 사고 모드 그대로, 내가 하고 싶거나 해야 하는 일을 하고 있었다.
이 단계에서 매우 중요하다. 에이전트 데스크톱 알림을 꺼라. 문맥 전환 비용은 매우 크다. 효율을 유지하려면, 언제 에이전트를 끊고 개입할지를 통제하는 주체는 인간인 나여야지 그 반대여서는 안 된다는 것을 나는 알게 되었다. 에이전트가 당신에게 알리게 두지 마라. 작업 사이에 자연스러운 휴식이 생길 때 탭을 전환해 상태를 확인하고, 다시 계속하면 된다.
중요한 점은, 나는 "다른 일을 한다"는 부분이 널리 알려진 Anthropic skill formation paper를 어느 정도 상쇄해 준다고 생각한다는 것이다. 일종의 절충이다. 에이전트에 위임한 작업에 대해서는 기술 형성을 하지 않게 되지만, 계속 수동으로 작업하는 영역에서는 자연스럽게 기술을 계속 쌓게 된다.
이 시점에 이르자 나는 확실히 "이제는 절대 이전으로 돌아갈 수 없다"는 영역에 들어섰다. 더 효율적이라고 느꼈고, 설령 그렇지 않았다 해도 가장 좋았던 점은 내가 정말 좋아하는 작업에 코딩과 사고를 집중하면서도, 좋아하지 않는 작업은 여전히 충분히 잘 끝낼 수 있게 되었다는 점이었다.
너무 당연한 말을 하는 위험을 감수하자면, 에이전트는 처음부터 올바른 결과를 내놓거나, 최악의 경우에도 아주 조금만 손보면 되는 결과를 내놓을 때 훨씬 더 효율적이다. 이를 달성하는 가장 확실한 방법은, 에이전트가 틀렸을 때 그것을 자동으로 알려 줄 빠르고 품질 좋은 도구를 제공하는 것이다.
이것에 대해 업계 전반에서 널리 받아들여진 용어가 이미 있는지는 모르겠지만, 나는 점점 이것을 "하네스 엔지니어링"이라고 부르게 되었다. 핵심 아이디어는 이렇다. 에이전트가 실수하는 것을 발견할 때마다, 그 실수를 다시는 하지 않도록 해결책을 엔지니어링하는 데 시간을 쓰는 것이다. 굳이 새로운 용어를 발명할 필요는 없다. 이미 다른 용어가 있다면 나도 그 흐름에 올라탈 것이다.
이것은 두 가지 형태로 나타난다.
더 나은 암묵적 프롬프팅(AGENTS.md): 에이전트가 계속 잘못된 명령을 실행하거나 잘못된 API를 찾는 것 같은 단순한 문제라면, AGENTS.md(또는 그에 준하는 파일)를 업데이트하라. 여기 Ghostty의 예시가 있다. 그 파일의 각 줄은 모두 나쁜 에이전트 행동에 대응해 생겨난 것이며, 거의 모든 문제를 사실상 해결했다.
실제로 프로그래밍된 도구: 예를 들면 스크린샷을 찍는 스크립트, 필터링된 테스트를 실행하는 스크립트 등이다. 보통은 에이전트가 이 도구의 존재를 알 수 있도록 AGENTS.md 변경과 함께 사용된다.
이것이 내가 오늘 서 있는 지점이다. 에이전트가 나쁜 짓을 하는 것을 볼 때마다, 그것을 다시는 하지 못하게 막기 위해 진지하게 노력하고 있다. 혹은 반대로, 에이전트가 좋은 일을 하고 있는지 스스로 검증할 수 있도록 진지하게 노력하고 있다.
5단계와 동시에, 나는 항상 에이전트 하나를 돌려 두는 것을 목표로 삼고 있다. 에이전트가 돌아가고 있지 않다면, 나는 스스로에게 묻는다. "지금 이 순간 에이전트가 나 대신 할 수 있는 일이 있을까?"
나는 이것을 Amp의 deep mode 같은 더 느리고 더 숙고하는 모델과 결합하는 것을 특히 좋아한다(기본적으로는 GPT-5.2-Codex일 뿐이다). 이런 모델은 작은 변경에도 30분 이상이 걸릴 수 있다. 하지만 반대급부로 상당히 좋은 결과를 내놓는 편이다.
나는 [아직은?] 여러 에이전트를 동시에 돌리고 있지 않고, 현재로서는 사실 별로 그러고 싶지도 않다. 지금의 내게는 에이전트 하나만 돌리는 것이, 내가 즐기는 깊고 수동적인 작업을 할 수 있는 것과, 다소 멍청하지만 왠지 모르게 생산적인 내 로봇 친구를 돌보는 것 사이에서 좋은 균형점이다.
"항상 에이전트를 돌려 두기" 목표는 여전히 말 그대로 목표일 뿐이다. 지금은 보통 업무일 기준으로 백그라운드 에이전트를 돌리는 데 10%에서 20% 정도만 효과를 내고 있다고 말할 수 있겠다. 하지만 나는 이를 개선하려고 적극적으로 노력하고 있다.
나는 에이전트를 돌리기 위해서 에이전트를 돌리고 싶지는 않다. 그것이 내게 진짜로 도움이 될 것 같은 작업이 있을 때만 돌리고 싶다. 이 목표의 과제 중 하나는, 내가 위임할 수 있을 만큼 품질 높은 작업이 끊임없이 나오도록 내 작업 흐름과 도구를 개선하는 것이다. 사실 이것은 AI가 없어도 중요한 일이다.
이것이 현재 내가 와 있는 지점이다.
이 여정을 거치며, 나는 개인적으로 현대의 AI 도구를 활용해 성과를 내고 있는 단계에 도달했고, 현실에 기반한 적절하고 신중한 관점으로 이것에 접근하고 있다고 믿는다. AI가 정말로 계속 남을지 여부에는 나는 어느 쪽으로도 크게 관심이 없다3. 나는 그저 만드는 일 자체를 사랑해서 무언가를 만들고 싶은 소프트웨어 장인일 뿐이다.
전체 지형이 너무 빠르게 움직이고 있어서, 나는 분명 얼마 지나지 않아 이 글을 돌아보며 내 순진함을 비웃게 될 것이다. 하지만 흔히 말하듯, 과거의 자신을 부끄러워할 수 없다면 아마 성장하고 있지 않은 것이다. 나는 그저 올바른 방향으로 성장하길 바랄 뿐이다!
나는 이 문제에 개인적 이해관계가 없다4. 물론 효용과는 별개로 AI 사용을 피해야 할 다른 이유들도 있다. 그에 관한 각자의 선택을 나는 온전히 존중한다. 나는 당신을 설득하러 여기 있는 것이 아니다! 관심 있는 사람들을 위해, 나는 단지 이 새로운 도구들을 내가 개인적으로 어떻게 헤쳐 나가고 있는지, 그리고 AI와 무관하게 일반적으로 새로운 도구에 어떻게 접근하는지에 대한 한 단면을 공유하고 싶었을 뿐이다.
Opus와 Codex 같은 현대의 코딩 모델은 대화형 모델에 비해 도구 사용 쪽으로 편향되도록 특별히 훈련된다. ↩
모델 혁신의 속도가 너무 빠르기 때문에, 나는 이 부분에 대한 내 기존 판단을 계속 다시 점검해야 한다. ↩
다만 기본기에 대한 탄탄한 이해가 없는 주니어들에게서 특히 기술 형성 문제가 나타나는 점은 깊이 우려된다. ↩
나는 어떤 AI 회사에서도 일하지 않고, 투자하지도 않으며, 자문도 하지 않는다. ↩
2026년 2월 5일
© 2026 Mitchell Hashimoto.