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

대부분의 경우 저는 1단계와 2단계를 억지로 밀고 나가야 합니다. 이미 만족하고 익숙한 워크플로가 있기 때문입니다. 새로운 도구를 들이는 일은 그 자체로 일이 되는 느낌이고, 솔직히 전혀 노력을 들이고 싶지 않습니다. 하지만 제 분야에서 균형 잡힌 장인이 되고 싶어 보통은 그 노력을 감수합니다.

이 글은 제가 AI 도구에서 어떻게 가치를 찾았고 앞으로 무엇을 시도하려 하는지에 대한 여정입니다. 과장되고 과열된 의견이 넘치는 바다에서, 이 글이 AI에 대한 제 관점과 그 관점이 시간에 따라 어떻게 변해왔는지를 보여주는 조금 더 섬세하고 차분한 기록이 되기를 바랍니다.

1단계: 챗봇부터 버리기

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

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

제가 아직 AI에 대해 강한 회의론자였을 때, 첫 번째 “와” 하는 순간은 Zed의 커맨드 팔레트 스크린샷을 Gemini에 붙여 넣고 SwiftUI로 재현해 달라고 했을 때였습니다. 결과가 아주 훌륭하게 나와 정말 깜짝 놀랐습니다. 오늘날 Ghostty의 macOS 버전에 들어간 커맨드 팔레트는 Gemini가 몇 초 만에 만들어 준 것에서 아주 조금만 손본 것입니다.

하지만 다른 작업에서 같은 방식을 재현하려 하자 실망만 남았습니다. 기존 코드베이스가 있는 brownfield 프로젝트에서는 채팅 인터페이스가 매우 자주 형편없는 결과를 냈고, 코드와 명령어 실행 결과를 인터페이스에 복사해 넣고 다시 가져오는 과정에 극심한 좌절을 느꼈습니다. 제가 직접 하는 것보다 훨씬 비효율적이라는 점이 너무나 명백했습니다.

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

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

여정의 다음 단계에서는 Claude Code를 시도했습니다. 결론부터 말씀드리면, 처음에는 별로 인상적이지 않았습니다. 세션에서 좋은 결과를 얻지 못했습니다. 에이전트가 만든 것은 무엇이든 제가 손봐야 한다고 느꼈고, 이 과정은 제가 직접 하는 것보다 더 많은 시간이 들었습니다. 블로그 글도 읽고 영상도 봤지만, 여전히 크게 와닿지 않았습니다.

포기하는 대신, 저는 수작업으로 만든 모든 커밋을 에이전트로 똑같이 재현하도록 스스로를 몰아붙였습니다. 말 그대로 일을 두 번 한 셈입니다. 먼저 직접 작업한 뒤, 에이전트와 씨름해 품질과 기능 면에서 동일한 결과를 만들어 내도록 했습니다(물론 에이전트가 제 수작업 결과를 볼 수 없게 한 채로).

이 과정은 고문에 가까웠습니다. 그저 일을 끝내야 하는데 방해가 되었기 때문입니다. 하지만 AI가 아닌 다른 도구들을 충분히 오래 다뤄본 경험으로, 이런 마찰은 자연스러운 일임을 알고 있었습니다. 노력을 끝까지 다 쏟지 않고서는 확고하고 방어 가능한 결론에 도달할 수 없습니다.

하지만 전문성이 생겼습니다. 다른 사람들이 이미 말하고 있던 것들을 저는 스스로, 원리부터 빠르게 깨닫게 되었고, 직접 발견했기에 더욱 단단한 근본적 이해로 이어졌습니다.

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 변경과 함께 이루어집니다.

제가 오늘 서 있는 지점이 바로 여기입니다. 에이전트가 나쁜 행동(Bad Thing)을 하는 것을 볼 때마다 다시는 그런 행동을 하지 않도록 막기 위해 진지하게 노력하고 있습니다. 반대로, 에이전트가 좋은 행동(Good Thing)을 하고 있음을 스스로 검증할 수 있도록 하는 데에도 진지하게 힘쓰고 있습니다.

6단계: 항상 에이전트 하나는 돌려두기

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

특히 Amp의 deep mode(기본적으로 GPT-5.2-Codex와 같습니다)처럼 더 느리지만 더 신중한 모델과 함께 쓰는 것을 좋아합니다. 작은 변경에도 30분 이상이 걸릴 수 있지만, 대신 결과물의 품질이 매우 좋은 편입니다.

저는 (아직?) 여러 에이전트를 동시에 돌리고 있지 않으며, 지금은 딱히 그러고 싶지도 않습니다. 에이전트 하나를 돌리는 것이 제가 즐기는 깊이 있는 수작업을 하면서도, 어딘가 어수룩하지만 신기하게 생산적인 로봇 친구를 돌보는 일 사이에서 지금 제게는 좋은 균형이라고 생각합니다.

“항상 에이전트를 실행해 둔다”는 목표는 아직 목표일 뿐입니다. 지금으로서는 일반적인 업무 시간 중 10~20% 정도만 백그라운드 에이전트를 유지하는 데 성공하고 있다고 할 수 있습니다. 하지만 이를 개선하기 위해 적극적으로 노력하고 있습니다.

오늘

그리고 그게 제가 오늘 서 있는 자리입니다.

이 여정을 통해 저는 개인적으로 현대 AI 툴링으로 성공을 거두고 있다고 느끼는 지점에 도달했고, 현실에 기반한 적절하고 균형 잡힌 시각으로 접근하고 있다고 믿습니다. AI가 계속 남을지 말지³는 솔직히 크게 신경 쓰지 않습니다. 저는 그저 만드는 것을 사랑해서 만들고 싶은 소프트웨어 장인일 뿐입니다.

전체 지형이 너무 빠르게 움직이고 있어, 이 글을 곧 다시 읽고 제 순진함에 웃게 될 것이라고 확신합니다. 하지만 말하듯, 과거의 자신이 부끄럽지 않다면 아마 성장하지 않은 것일 겁니다. 그저 올바른 방향으로 성장하길 바랄 뿐입니다!

저는 여기에서 아무런 이해관계도 없습니다⁴. 그리고 효용성 외에도 AI 사용을 피해야 할 다른 이유들도 물론 있습니다. 이와 관련된 각자의 결정을 전적으로 존중합니다. 여러분을 설득하려는 것이 아닙니다! 관심 있는 분들을 위해, 이 새로운 도구들을 어떻게 헤쳐 나가고 있는지에 대한 저만의 접근법, 그리고 AI와는 별개로 일반적으로 새로운 도구에 어떻게 접근하는지를 살짝 보여드리고 싶었을 뿐입니다.