의미 있는 도구를 도입할 때 내가 겪은 경험은 늘 세 단계를 거쳐야 한다는 것이다: (1) 비효율의 시기 (2) 그런대로 쓸 만한 시기, 그리고 마지막으로 (3) 워크플로와 삶 자체를 바꾸는 발견의 시기.

대부분의 경우 1단계와 2단계를 억지로 밀고 나가야 한다. 이미 만족스럽고 익숙한 워크플로가 있기 때문이다. 새로운 도구를 도입하는 건 일처럼 느껴지고, 나는 정말로 그 수고를 들이고 싶지 않지만, 내 분야에서 두루 갖춘 사람이 되기 위해 보통은 감수한다.

이 글은 내가 AI 도구에서 어떻게 가치를 찾았고 앞으로 무엇을 시도하려 하는지에 대한 여정이다. 과장되고 과열된 의견이 넘쳐나는 바다 속에서, 이 글이 AI에 대한 내 시각과 그 시각이 시간에 따라 어떻게 변해왔는지를 보여주는 좀 더 섬세하고 균형 잡힌 접근이 되기를 바란다.

1단계: 챗봇 버리기

챗봇(예: 웹의 ChatGPT, Gemini 등)으로 의미 있는 작업을 하려는 시도를 즉시 멈춰라. 챗봇은 분명 가치가 있고 내 AI 워크플로에서도 매일 쓰이지만, 코딩에서의 효용은 매우 제한적이다. 대부분 사전 학습에 기반해 올바른 결과를 내놓기를 바라는 데 그치고, 바로잡으려면 사람(당신)이 반복적으로 틀렸다고 알려줘야 하기 때문이다. 비효율적이다.

모든 사람의 AI 첫 경험은 채팅 인터페이스라고 생각한다. 그리고 AI로 코딩을 처음 시도한 경험 역시 채팅 인터페이스에 코드를 짜 달라고 요청한 것이었을 것이다.

내가 여전히 AI에 대해 회의적이었을 때 첫 “와” 했던 순간은 Zed의 커맨드 팔레트 스크린샷을 Gemini에 붙여 넣고 SwiftUI로 재현해 달라고 했을 때였다. 결과가 아주 훌륭해서 정말 놀랐다. 오늘날 Ghostty의 macOS용 커맨드 팔레트는 Gemini가 몇 초 만에 만들어 준 결과물에서 거의 손대지 않고 나온 것이다.

하지만 다른 작업에서 같은 방식을 재현하려 하자 실망만 남았다. 브라운필드 프로젝트, 즉 기존 코드베이스가 있는 프로젝트에서는 채팅 인터페이스가 아주 자주 형편없는 결과를 냈고, 코드와 명령어 출력을 인터페이스 안팎으로 복사해 붙여 넣는 과정에 크게 좌절했다. 내가 직접 하는 것보다 훨씬 비효율적이라는 게 너무나 명백했다.

가치를 찾으려면 반드시 에이전트를 써야 한다. 에이전트는 대화하면서 외부 동작을 루프 형태로 호출할 수 있는 LLM을 가리키는 업계 표준 용어다¹ 최소한 에이전트는 파일을 읽고, 프로그램을 실행하고, HTTP 요청을 보낼 수 있어야 한다.

2단계: 자신의 작업을 재현하기

여정의 다음 단계에서 나는 Claude Code를 시도했다. 결론부터 말하자면 처음엔 별 감흥이 없었다. 세션에서 좋은 결과를 얻지 못했다. 에이전트가 만든 것은 뭐든 손을 봐야 했고, 이 과정이 내가 직접 하는 것보다 더 오래 걸렸다. 블로그 글도 읽고 영상도 봤지만 여전히 인상적이지 않았다.

포기하는 대신, 나는 모든 수동 커밋을 에이전트로 다시 재현하도록 스스로를 강제했다. 말 그대로 일을 두 번 한 셈이다. 먼저 수동으로 작업한 뒤, 에이전트와 씨름해 품질과 기능 면에서 동일한 결과를 뽑아내도록 했다(물론 에이전트가 내 수동 솔루션을 보지 못하게 한 채로).

이 과정은 고문 같았다. 그냥 일을 끝내는 데 방해가 됐기 때문이다. 하지만 AI가 아닌 도구들을 충분히 다뤄본 경험상 마찰은 자연스러운 것이고, 노력을 다 쏟지 않고서는 확고하고 방어 가능한 결론에 도달할 수 없다는 걸 알고 있었다.

하지만 전문성이 생겼다. 다른 사람들이 이미 말하고 있던 것들을 나는 제1원칙부터 스스로 빠르게 발견했고, 직접 발견했기에 더 단단한 근본적 이해로 이어졌다.

1. 세션을 명확하고 실행 가능한 별개의 작업으로 나눠라. 한 번의 메가 세션에서 “올빼미 그리기”를 시도하지 마라.
2. 모호한 요청은 기획 세션과 실행 세션으로 나눠라.
3. 에이전트에게 자신의 작업을 검증할 방법을 주면, 십중팔구 스스로 실수를 고치고 회귀를 방지한다.

더 일반적으로는, 당시 에이전트가 잘하는 일과 못하는 일의 경계, 그리고 잘하는 일에 대해 내가 원하는 결과를 어떻게 얻는지도 알게 됐다.

이 모든 것이 상당한 효율 향상으로 이어졌고, 마침내 에이전트를 쓰는 것이 내가 직접 하는 것보다 느리지 않다고 느껴질 정도로 자연스럽게 사용하게 됐다(다만 여전히 더 빠르다고는 느끼지 못했다. 대부분 에이전트를 돌보는 데 시간을 쓰고 있었으니).

여기서 여백, 즉 하지 않은 부분을 다시 강조할 가치가 있다: 효율 향상의 일부는 언제 에이전트를 쓰지 말아야 하는지를 이해한 데서 왔다. 실패할 가능성이 높은 일에 에이전트를 쓰는 건 명백히 큰 시간 낭비이며, 그것을 피할 줄 아는 것 자체가 시간을 아끼는 길이 된다².

이 단계에서 나는 에이전트에서 충분히 쓸 만한 가치를 찾아 워크플로에 기꺼이 활용했지만, 여전히 순수한 효율 향상이 있다고는 느끼지 못했다. 그래도 상관없었다. 이 시점에서 AI라는 도구 자체에 만족하고 있었다.

3단계: 하루 끝에 에이전트 돌리기

효율을 좀 더 찾아보고자 다음으로는 새로운 패턴을 시작했다: 매일 마지막 30분을 확보해 하나 이상의 에이전트를 실행하는 것. 내 가설은, 어차피 내가 일할 수 없는 시간에 에이전트가 긍정적인 진전을 만들어낼 수 있다면 어쩌면 효율을 얻을 수 있지 않을까 하는 것이었다. 요컨대, 내가 가진 시간에 더 많이 하려 하기보다, 내가 갖지 못한 시간에 더 많이 해보려는 시도였다.

이전 과제와 마찬가지로 처음에는 실패했고 짜증도 났다. 하지만 또다시 금방 정말 도움이 되는 여러 유형의 작업을 찾았다:

• 심층 리서치 세션 — 에이전트에게 특정 분야를 조사시키는 것으로, 예를 들어 특정 언어에서 특정 라이선스 유형을 가진 모든 라이브러리를 찾아 각각의 장단점, 개발 현황, 커뮤니티 반응 등을 담은 수십 페이지 분량의 요약을 만들게 하는 작업.
• 막연한 아이디어를 병렬 에이전트로 시도하기 — 당장 시작할 시간은 없었던 다양한 막연한 아이디어들을 여러 에이전트에 병렬로 시도시키는 것. 여기서 당장 제품에 반영할 결과물을 기대하진 않았지만, 다음 날 작업에 착수했을 때 미처 몰랐던 것들을 밝혀주는 데 도움이 될 수 있었다.
• 이슈 및 PR 분류/리뷰. 에이전트는 gh(GitHub CLI)를 잘 다루므로, 여러 개를 병렬로 띄워 이슈를 분류하도록 간단한 스크립트를 직접 짰다. 에이전트가 직접 답변하도록 하지는 않았다. 다음 날 나를 고가치 또는 저노력 작업으로 이끌어줄 보고서만 원했다.

분명히 하자면, 나는 밤새 에이전트를 루프로 돌리는 다른 사람들만큼 극단적으로 하진 않았다. 대부분의 경우 에이전트는 30분 이내에 작업을 마쳤다. 하지만 하루 일과의 후반부에는 보통 지쳐 있고 몰입에서 벗어나 개인적으로 매우 비효율적이라, 에이전트를 띄우는 쪽으로 노력을 전환하니 다음 날 아침 더 빨리 일에 착수할 수 있는 “웜 스타트”가 됐다.

만족스러웠고, 비록 조금이라도 AI 이전보다 더 많은 일을 하고 있다는 느낌이 들기 시작했다.

4단계: 확실한 건 아웃소싱하기

이 시점에 이르자 내 AI가 잘하는 일과 못하는 일에 대해 매우 확신이 생겼다. 특정 작업에 대해서는 AI가 대부분 올바른 솔루션을 내놓을 거라는 강한 확신이 있었다. 그래서 여정의 다음 단계는 에이전트가 그런 작업을 모두 처리하게 하고 나는 다른 일을 하는 것이었다.

좀 더 구체적으로는, 매일 아침 전날 밤 분류 에이전트의 결과를 가져와 에이전트가 거의 확실히 잘 해결할 이슈들만 수동으로 걸러낸 뒤, 백그라운드에서 하나씩(병렬이 아닌 순차적으로) 계속 실행시켰다.

그동안 나는 다른 작업을 했다. 소셜 미디어를 하지도 않았고(AI 없이 평소 하던 것 이상으로), 영상을 보지도 않았다. AI 이전의 평소 깊이 몰입하는 사고 모드로, 내가 하고 싶거나 해야 하는 작업에 집중했다.

이 단계에서 매우 중요한 것: 에이전트의 데스크톱 알림을 꺼라. 컨텍스트 스위칭 비용은 매우 크다. 효율을 유지하려면 에이전트를 언제 방해할지는 인간인 내가 통제해야지, 그 반대가 되어서는 안 된다는 걸 깨달았다. 에이전트가 당신에게 알림을 보내게 두지 마라. 작업 중 자연스러운 쉬는 타이밍에 탭을 옮겨 확인하고 다시 하던 일을 이어가라.

중요한 점은, “다른 일을 한다”는 것이 널리 알려진 Anthropic의 스킬 형성 논문에 대한 대응책이 된다고 생각한다는 것이다. 물론 트레이드오프는 있다: 에이전트에 위임한 작업에 대한 스킬은 형성되지 않지만, 계속 직접 하는 작업에서는 자연스럽게 스킬을 계속 형성하게 된다.

이 시점에서 나는 확실히 “절대 이전으로 돌아갈 수 없는” 영역에 들어섰다. 더 효율적이라고 느꼈지만, 설령 그렇지 않더라도 가장 좋았던 점은 내가 정말 좋아하는 작업에 코딩과 사고를 집중하면서도, 좋아하지 않는 작업들 역시 충분히 잘 마무리할 수 있게 됐다는 것이다.

5단계: 하네스 엔지니어링하기

너무 당연한 말을 할 위험을 무릅쓰고 말하자면, 에이전트는 처음부터 올바른 결과를 내놓을 때, 혹은 최악의 경우에도 최소한의 손질만으로 끝나는 결과를 내놓을 때 훨씬 더 효율적이다. 이를 달성하는 가장 확실한 방법은 에이전트가 틀렸을 때 자동으로 알려주는 빠르고 품질 좋은 도구를 주는 것이다.

이 개념에 대해 업계 전반에서 통용되는 용어가 있는지는 모르겠지만, 나는 이를 “하네스 엔지니어링”이라고 부르게 됐다. 에이전트가 실수를 할 때마다 그 실수를 다시는 반복하지 않도록 해결책을 엔지니어링하는 데 시간을 들인다는 아이디어다. 여기서 굳이 새로운 용어를 만들 필요는 없다. 다른 용어가 있다면 언제든 그 흐름에 동참할 것이다.

이는 두 가지 형태로 나타난다:

1. 더 나은 암시적 프롬프팅(AGENTS.md). 에이전트가 잘못된 명령을 반복 실행하거나 잘못된 API를 찾는 등 단순한 문제에 대해서는 AGENTS.md(또는 그에 상응하는 파일)를 업데이트하라. Ghostty의 예시를 보라. 그 파일의 각 줄은 잘못된 에이전트 행동 하나에 기반한 것이며, 그것만으로 거의 모든 문제가 해결됐다.

2. 실제로 프로그래밍된 도구. 예를 들어 스크린샷을 찍거나 필터링된 테스트를 실행하는 스크립트 등이다. 이는 보통 해당 도구의 존재를 알리기 위한 AGENTS.md 변경과 함께 사용된다.

지금 나는 여기 있다. 에이전트가 나쁜 행동을 하는 걸 볼 때마다 다시는 그런 행동을 하지 않도록 막기 위해 진지하게 노력하고 있다. 반대로 에이전트가 좋은 행동을 하고 있음을 스스로 검증할 수 있도록 하는 데도 진지하게 힘쓰고 있다.

6단계: 항상 에이전트 실행하기

5단계와 동시에, 나는 항상 에이전트를 실행해 둔다는 목표 아래 움직이고 있다. 에이전트가 실행 중이지 않다면 스스로에게 “지금 에이전트가 대신 해줄 수 있는 일이 있을까?”라고 묻는다.

특히 Amp의 딥 모드(기본적으로 GPT-5.2-Codex와 같다)처럼 더 느리지만 더 깊이 생각하는 모델과 결합하는 걸 좋아한다. 이 모델은 작은 변경을 만드는 데 30분 이상이 걸리기도 한다. 대신 결과물의 품질이 매우 좋은 편이라는 장점이 있다.

나는 [아직은?] 여러 에이전트를 동시에 돌리고 있지 않으며, 현재로서는 딱히 하고 싶지도 않다. 지금으로서는 에이전트 하나를 돌리는 것이 내가 즐기는 깊이 있는 수동 작업과, 다소 어리석지만 신기하게 생산적인 로봇 친구를 돌보는 일 사이에서 좋은 균형이라고 느낀다.

“항상 에이전트를 실행한다”는 목표는 아직 목표일 뿐이다. 지금으로선 일반적인 근무일 기준으로 10~20% 정도만 백그라운드 에이전트를 효과적으로 돌리고 있는 것 같다. 하지만 이를 개선하기 위해 적극적으로 노력 중이다.

지금

그리고 지금 나는 여기까지 왔다.

이 여정을 통해 나는 현대적인 AI 도구로 성공을 거두고 있다고 개인적으로 느끼는 지점에 도달했고, 현실에 기반한 적절히 절제된 시각으로 접근하고 있다고 믿는다. AI가 계속 남을지 아닐지는 솔직히 별로 신경 쓰지 않는다³. 나는 그저 만드는 것 자체를 사랑해서 만들고 싶은 소프트웨어 장인일 뿐이다.

전체 판도가 너무 빠르게 움직이고 있어서, 머지않아 이 글을 돌아보며 내 순진함에 웃게 될 거라 확신한다. 하지만 말하듯, 과거의 자신에 대해 부끄러움을 느끼지 못한다면 아마 성장하지 않고 있는 것이다. 그 성장이라도 올바른 방향이길 바랄 뿐이다!

나는 여기에 어떤 이해관계도 없다⁴. 그리고 효용을 넘어 AI 사용을 피할 다른 이유들도 당연히 존재한다. 그에 대한 각자의 결정을 전적으로 존중한다. 당신을 설득하려는 게 아니다! 관심 있는 분들을 위해, 이 새로운 도구들을 헤쳐 나가는 나만의 접근법과 AI 여부와 관계없이 새로운 도구에 일반적으로 어떻게 접근하는지를 공유하고 싶었을 뿐이다.