팀원이 Slack에 글을 올린다. 주문 하나가 대기 상태에 멈춰 있고, 고객이 답을 기다린다. 나는 다른 일에 빠져 있어서 그 글을 보지 못한다.
1분 30초쯤 뒤 스레드에 답이 달린다. 에이전트가 코드 경로를 따라가고, 읽기 전용으로 열어 둔 데이터에서 그 주문의 지금 상태를 확인한 뒤, 왜 멈췄는지와 고객에게 무엇을 안내하면 되는지를 쉬운 말로 설명한다. 버그로 보이면 테스트 환경에서 재현하고, 원인과 수정 방향을 적은 Jira 이슈를 만든다. 내가 그 글을 볼 때쯤에는 조사가 끝나 있고, 남은 건 결정뿐이다.
1년 전이라면 그 질문은 나를 기다렸을 것이다.
이 글은 내 일에 AI 에이전트를 들이면서 배운 것을 정리하는 시리즈의 첫 편이다. 도구 비교나 프롬프트 모음이 아니다. 무엇이 바뀌었고, 무엇을 치렀고, 내일 시작하는 사람에게 무엇을 말해 주고 싶은지를 쓴다.
출발점: 더 좋은 검색창
웹 채팅을 업무에 쓰기 시작한 건 2025년 10월쯤이다. 주로 세 가지였다. 글 초안, 운영 정책과 계약서를 내보내기 전에 검토하기, 그리고 검색하는 대신 묻기.
도움이 됐다. 특히 계약서 검토가 그랬다. 조항을 읽어 주는 데서 그치지 않고 그 뒤에 있는 법적인 문제도 일부 같이 풀어 줘서, 늘 늘어지던 검토가 훨씬 빨리 끝났다. 하지만 일의 모양은 그대로였다. 그때 내 일은 무엇을 만들지 정하고, 팀에 구현을 요청하고, 돌아온 결과를 검토하는 것이었다. 채팅창은 그 단계 하나하나를 조금 빠르게 해 줬을 뿐이다. 답은 늘 채팅창 안에서 멈췄고, 실제 일은 다른 곳에서 다른 사람이 했다.
선택: 다시 코드로
2026년 9월, 두 가지 결론에 이르렀다. 하나는 AI를 옆에 두고 가끔 쓰는 도구가 아니라 일하는 방식 자체로 제대로 들여야 한다는 것. 다른 하나는 그렇게 믿는다면 남에게 요청하기 전에 내가 먼저 해야 한다는 것. 그래서 다시 직접 코드로 일하기로 했다. 누가 시킨 게 아니라 내가 고른 길이었고, 에이전트가 타이핑의 상당 부분을 맡아 줄 수 있게 됐기에 가능한 선택이었다.
그 길을 가려고 로컬 코딩 에이전트로 일하는 환경을 만들었다. 저장소의 파일을 읽고 고치고, 내 승인을 받아 명령을 실행하고, 무엇을 바꿨는지 보여 주는 에이전트다. 기능 요청서를 쓰던 자리에 이제는 에이전트에게 줄 목표와 제약, 완료 기준을 쓴다. 그리고 예전에 팀원의 작업을 검토하던 방식으로 에이전트의 작업을 검토한다.
어떤 도구보다 이 결정이 내 일의 결과물을 바꿨다.
숫자로 본 변화
전환하기 전 1년 동안 내 커밋은 한 달에 몇 개, 아예 없는 달도 많았다. 주로 요청하고 검토하는 사람이었으니 당연한 숫자다. 9월에는 41개, 10월에는 저장소 17개에 걸쳐 429개였다. 9월부터 11월 15일까지 커밋 734개 중 723개를 에이전트와 함께 썼다. 그래프는 업무 저장소 전체를 병합 커밋을 빼고 센 것이다.
커밋 수가 곧 성과는 아니다. 그래서 그 커밋이 무엇이었는지 적어 둔다. 이 석 달 동안, 거의 혼자서:
- 문서 허브를 하루에. 그 전에는 저장소 중 제대로 된 문서가 있는 곳이 하나뿐이었고, 그마저 버전 관리 밖에 있었다. 에이전트가 코드를 읽게 하면서 하루에 문서 63편을 썼고, 에이전트가 일을 시작하기 전에 어디부터 봐야 하는지 알려 주는 첫 규칙 파일들도 만들었다.
- 서로 협력하는 에이전트 셋을 사흘에. 팀 질문에 답하는 Slack 에이전트, 버그로 보이는 문제를 재현하는 조사 담당, 기능 아이디어를 검토하는 기획 담당이다. 사흘째에 여섯 명이 쓰고 있었다.
- 감시 체계를 하나에 하루이틀씩 다시 만들었다. 그중 하나는 첫 실행에서 아무도 몰랐던 문제를 찾아냈다. 어떻게 설계했는지는 2편에서 다룬다.
그래도 내가 가장 중요하게 보는 변화는 첫 대응 방식이다.
사라진 병목
내 일 중 하나는 운영 중인 서비스에서 문제가 생겼을 때의 첫 대응이다. 누군가 Slack으로 알리면 그게 무엇인지 알아낸다. 재현해 보고, 코드를 확인한다. 수정이 필요하면 이슈를 만들고 고친다. 그 사이사이 진행 상황과 임시 대책을 공유한다.
문제는 이 일이 어렵다는 게 아니었다. 나를 기다린다는 것이었다. 내가 다른 일에 몰두해 있으면 요청을 못 보거나 대응하지 못했고, 물어본 사람은 내가 볼 때까지 일이 막혔다.
이제는 에이전트가 첫 대응을 한다. 이름은 kenny, 내 영어 이름 Ken에서 따왔다. 사람들이 나를 기다리던 바로 그 부분의 일을 하라고 만든 에이전트라서다. 질문을 받으면 문서와 코드를 확인하고, 지금의 데이터를 찾아보고, 쉬운 말로 답하고, 얼마나 확실한지도 밝힌다. 진짜 버그라면 조사 담당 에이전트에게 넘기고, 조사 담당은 문제를 재현한 뒤 원인과 수정 방향을 정리한다. 고칠지 말지, 그리고 실제로 고치는 일은 여전히 내 몫이다.
11월 초 2주 동안 kenny는 나를 포함한 다섯 명이 물은 질문 약 100건에 답했다. 절반은 1분 30초 안에 첫 답이 나왔고, 거의 전부가 10분 안이었다. 첫 한 달 동안 Slack 요청에서 이슈 24건을 만들었다. 일주일에 여섯 건꼴이고, 각각 조사한 결과를 정리해 두었다.
표본이 작고, 질문 중 상당수는 내가 한 것이다. 이 숫자는 답이 얼마나 빨리 오는지를 보여 줄 뿐, 답이 얼마나 좋은지나 시간을 얼마나 아꼈는지를 보여 주지는 않는다. 하지만 문제가 바로 속도였다. 이제 질문은 나를 기다리지 않는다.
찾고, 옮기고, 쫓아다니던 시간이 결정하고 검토하는 시간으로 옮겨 갔다. 일이 줄어든 게 아니다. 다른 일이 됐고, 그게 내가 실제로 쓸모 있는 부분이다.
kenny를 어떻게 만들었는지, 왜 일부러 좁게 만들었는지는 6편에서 쓴다.
내가 걸어온 길
돌아보면 다섯 단계였고, 각 단계는 앞 단계가 한계에 닿았을 때 시작됐다.
- 웹 채팅 (2025년 10월). 초안과 질문에는 좋았지만, 답이 채팅창 안에서 멈췄다.
- 로컬 에이전트 (2026년 9월). 에이전트가 채팅창이 아니라 파일 안에서 일한다. 새 문제는 세션마다 0에서 시작해서 같은 것을 매번 다시 알아낸다는 것이었다.
- 글로 남긴 맥락 (2026년 9월). 저장소마다 문서와 규칙 파일을 둬서, 에이전트가 우리가 이미 아는 것에서 출발하게 했다. 4편과 5편에서 다룬다.
- Slack 에이전트 (2026년 10월). 맥락이 쌓이자 에이전트가 내 질문뿐 아니라 다른 사람의 질문에도 답할 수 있게 됐다. 병목이던 내가 빠졌다.
- 반복 확인 위임 (2026년 10~11월). 매주 하던 확인은 결과를 보고하는 감시 체계가 됐고, “이거 나중에 확인해야지” 메모는 확인할 내용을 그대로 담아 개인 비서 Hermes가 보내는 리마인더가 됐다(7편).
무엇을 치렀나
숫자에서 멈추면 정직하지 않다.
- 검토가 곧 일이 된다. 에이전트는 내가 꼼꼼히 읽을 수 있는 것보다 많이 만든다. 이제 중요한 능력은 잘 검토하는 것이다. 근거를 확인하고, 결과를 표본으로 뽑아 보고, 무엇이 왜 틀렸는지 정확히 말하는 것.
- 에이전트는 모든 걸 잊는다. 글로 남긴 맥락이 없으면 세션마다 어제의 실수를 반복한다. 문서 허브는 곁가지 작업이 아니었다. 그 뒤의 모든 것이 그 위에서 돌아간다.
- 에이전트는 새로운 방식으로 실패한다. 어느 날 밤 에이전트가 하위 작업을 줄줄이 만들어 평소의 여덟 배쯤 호출을 하고 API 크레딧을 바닥냈다. 그러지 말라는 규칙은 이미 있었는데 모델이 무시했다. 결국 그 도구를 없애는 것으로 해결했다. 이렇게 프롬프트 밖에서 강제하는 규칙들을 3편에서 쓴다.
- 안전은 내 책임이다. 코드를 읽을 수 있는 에이전트는 그 코드를 어딘가에 붙여 넣을 수도 있다. 이 문제는 Slack 에이전트가 소스 코드를 내보내지 못하게 한 글에 썼다.
왜 글로 정리했나
몇 달이 지나 이 모든 것을 가이드로 정리했다. 다른 사람들이 내가 겪은 걸 처음부터 다시 겪지 않고 같은 길을 따라올 수 있게 하려고. 이 시리즈는 그 가이드를 누구나 읽을 수 있게 다시 쓴 것이다. 실제로 일어난 일, 그러니까 숫자와 실수와 버텨 낸 설계를 바탕으로.
시리즈 목차
- 직접 하던 사람에서 맡기는 사람으로 (이 글)
- 판정은 코드가, 설명은 LLM이
- 내가 절대 어기지 않는 규칙
- 맥락이 실력이다
- 에이전트는 잊는다, 그래서 적는다
- kenny: 내 일을 대신하는 에이전트
- Hermes: 확인할 일을 챙겨 주는 리마인더
- 2주 만에 시작하는 법
내일 당장 일의 반복되는 한 부분을 에이전트에게 맡길 수 있다면, 무엇을 맡기겠는가? 그리고 그 전에 무엇을 글로 남겨 둬야 할까?