에이전트 시대, 내가 하는 일의 정의가 바뀌었다
면허를 딴 뒤 수동 기어 차량은 한 번도 몰지 않았다.
코드를 작성하는 일도 비슷한 방향으로 움직이고 있다.
에이전트에게 일을 맡기고, 매일 삐걱대는 기억 시스템과 씨름하면서 깨달은 것들을 정리했다.
변하는 것과 변하지 않는 것에 대해.
에이전트가 1시간 30분을 돌았다. 내가 설계해둔 개발 로드맵에 따라 쪼개진 마일스톤들이 전부 수행된 상태였다. 커밋 로그가 찍혀 있고, PR이 올라와 있었다.
자리에 앉자마자 핵심 기능이 동작하는지부터 확인한다.
코드를 열어보고, 테스트를 돌리고, 의도한 흐름대로 움직이는지 검증한다. 완벽하진 않다. 엣지 케이스를 놓친 부분이 있고, 내가 생각한 것과 다른 방식으로 구현한 곳도 있다. 하지만 마일스톤의 뼈대는 서 있다.
6개월 전의 나는 이 모든 걸 직접 했다. 코드를 한 줄씩 짜고, 테스트를 작성하고, PR을 올리고. 그게 엔지니어의 일이라고 생각했다.
그런데 지금, 나는 코드를 짜는 대신 코드를 검증하고 있다. 그리고 오히려 더 많은 일이 진행되고 있다.
뭔가가 바뀌었다. 내가 하는 “일”의 정의 자체가.
처음에는 하나씩 시켰다
Claude Code를 처음 만진 건 작년이었다. 터미널에 앉아서 명령을 내렸다. “이 페이지 크롤링해줘.” “이 데이터 정리해줘.” “이 API 연동 코드 짜줘.”
빠르긴 했다. 직접 짜는 것보다 코드가 나오는 속도 자체는 확실히 빨랐다. 그런데 이상한 간극이 생겼다. 코드를 짜는 시간은 줄었는데, 코드를 읽는 시간이 길어진 거다. 내가 짠 게 아니니까 한 줄 한 줄 확인해야 했고, 의도와 다른 부분을 설명하는 시간이 더 걸릴 때도 있었다. 그래도 신기하니까 계속 썼다. 크롤링 자동화를 만들고, 뉴스레터를 정리하고. 그 정도 수준이었다. AI를 “쓰는” 단계. 도구를 손에 쥐고 이리저리 돌려보는 시기.
이때의 나는 명확했다. 나는 명령하는 사람이고, AI는 실행하는 도구다. 관계가 단순했다. 내가 무엇을 할지 결정하고, 어떻게 할지도 결정하고, AI는 그 “어떻게”의 일부를 대신해줄 뿐이었다.
그런데 이 관계가 서서히 바뀌기 시작했다.
두려우면서 재밌어졌다
전환점은 “시키는 방식”이 바뀐 게 아니었다. 관심사 자체가 바뀌었다.
에이전트 오케스트레이션이라는 개념이 나왔을 때까지만 해도 “그렇구나” 수준이었다. 그런데 OpenClaw가 나오고, 에이전트의 메모리 구조를 들여다보기 시작하면서 분위기가 달라졌다.
GSD가 돌아가는 방식을 관찰하면서, 이게 어떻게 작동하는지 이해하고 싶어졌다. 기억을 계층화하고, 컨텍스트를 관리하고, 우선순위를 주입하는 구조. 두려웠다. 이걸 제대로 이해하지 못하면 뒤처질 것 같았다. 그런데 동시에 미치도록 재밌었다.
사람의 뇌과학이 마구 떠올랐다. 단기기억에서 장기기억으로 넘어가는 과정, 수면 중 기억 응고화, 망각의 역할. 에이전트의 메모리 아키텍처가 인간의 기억 구조와 닮아 있다는 걸 깨달은 순간, 이건 단순한 도구가 아니라 설계의 대상이 됐다.
그러면서 일하는 방식이 바뀌기 시작했다. 정의가 바뀌기 시작했다.
계획의 비중이 커졌다. 에이전트는 한 번에 모든 맥락을 완전히 흡수하지 못한다. 그래서 설계가 바뀔 때마다 플로우차트를 그리게 시킨다. 전체 흐름을 시각화하고, 이걸 내가 검토하고, 수정하고, 다시 그리게 하고. 이 과정을 몇 번이고 반복한 뒤에야 비로소 구현을 지시한다. 그제서야 코드가 나온다.
이전에는 머릿속의 설계를 바로 코드로 옮겼다. 지금은 머릿속의 설계를 플로우차트로 시각화하고, 시각화를 검증하고, 검증된 설계를 에이전트에게 넘긴다. 단계가 하나 늘어난 것 같지만, 실제로는 설계의 정밀도가 올라간 거다. 이전에는 코드를 짜면서 설계를 수정했다. 지금은 코드를 짜기 전에 설계가 끝나 있다.
내가 쓰는 시간의 질이 달라졌다. 코드를 짜는 시간이 설계하는 시간으로 바뀐 게 아니라, 처음부터 설계에 집중할 수밖에 없는 구조가 된 거다.
빈 시간이 생겼고, 그 빈 시간이 모든 걸 바꿨다
계획을 세우고 위임하는 방식으로 전환하니까, 생각보다 시간이 많이 뜨기 시작했다. 에이전트가 GSD를 수행하는 동안, 나는 기다려야 했다. 처음에는 그 시간에 긱뉴스를 읽거나, 오픈소스 PR을 구경하거나, 코드리뷰 노하우를 뒤적거렸다. 리서치 시간.
그런데 어느 순간 그 빈 시간의 용도가 바뀌었다.
GSD 하나가 돌아가는 동안, 다른 업무를 설계하기 시작했다. 그리고 그 설계를 또 다른 GSD로 넘겼다. 동시에 두 개가 돌아간다. 익숙해지면 세 개, 네 개. 최대 네 개가 적정선이었다. 그 이상은 내 머릿속에서 맥락 전환 비용이 너무 커진다.
네 개의 작업이 병렬로 돌아가는 동안 나는 다섯 번째 일을 하고 있다. 하지만 그 다섯 번째 일은 코드를 짜는 게 아니다. 다음에 무엇을 할지를 결정하는 일이다.
여기서 핵심적인 발견이 있었다.
에이전트에게 일을 시키는 것 자체가 생산성의 핵심이 아니었다. 에이전트가 일하는 동안 내가 “다음에 무엇을 할지”를 설계하는 시간을 확보하게 된 것 — 이것이 진짜 전환이었다.
코딩을 위임하면 코딩 시간이 비는 게 아니다. 사고하는 시간이 생긴다.
한 발 더 나가면 이런 그림이 된다. 일의 정의가 모호하거나, 결정이 필요해서 홀딩된 업무가 있다. 예전에는 그런 업무가 “나중에 해야지” 리스트에 쌓였다. 지금은 그 빈 시간에 실험을 돌린다. 회사에 도입할 워크플로우를 로컬에서 먼저 시험해본다. 작은 장난감을 만들듯이.
다만 현실의 벽도 있다. 개인 수준에서 장난감을 만드는 건 쉽지만, 그걸 회사 차원의 추상화로 올리는 건 전혀 다른 난이도다. 이건 매번 체감한다. 개인 프로젝트에서 잘 돌아가는 자동화가 팀 단위로 가면 완전히 다른 문제가 된다.
설화에서 벌어지고 있는 일
“설화”라는 모바일 게임 서비스를 만들고 있다. tailbound라는 프로젝트명으로, 여기에 OpenClaw를 붙인 에이전트가 매일 크론잡으로 돌아간다. 하는 일이 꽤 넓다. 열린 PR을 리뷰하고 레이블을 달아준다. 마케팅 전략을 고민해준다. 사업적 방향성을 제안한다.
글로 쓰면 대단해 보이지만, 현실은 삐걱거린다.
어제는 잘 돌았는데 오늘은 답변이 없다. 원인을 추적하면 별거 아닌 경우가 많다. 세션이 꼬였거나, 컨텍스트가 넘쳤거나, API가 타임아웃을 낸 거다. 하지만 그 “별거 아닌” 것을 매번 잡아줘야 한다는 게 피로하다.
더 답답한 건 기억의 문제다. 에이전트에게 커밋해놓은 메모리를 읽으라고 한다. 최우선순위 메모리를 반드시 참조하라고 지시한다. 그런데 안 읽는다. 정확히는, 읽는 척하다가 자기 멋대로 답변한다.
사람을 가르치듯 같은 지시를 반복해야 하고, 그래도 원하는 대로 안 되는 날이 있다. 한번 꼬이면 반복적인 답변만 뱉으면서 루프에 빠진다. 그러면 세션을 끊고 처음부터 다시 시작해야 한다.
자동화는 버튼 하나를 누르면 끝나는 게 아니었다.
이걸 깨닫는 데 시간이 좀 걸렸다. 에이전트를 운영한다는 건, 에이전트가 잘 작동할 수 있는 환경을 만드는 일이다.
기억을 어떤 형태로 저장할지, 어떤 지시를 어떤 우선순위로 주입할지, 실패했을 때 어떻게 복구할지, 어디까지를 자동으로 맡기고 어디서부터 사람이 개입할지.
로봇 청소기를 산다고 바닥이 알아서 깨끗해지지 않는 것과 같다. 장애물을 치워야 하고, 빠지지 않게 영역을 만들어야 하고, 다 돈 다음에 구석을 확인해야 한다. 에이전트도 마찬가지다. 데이터를 정리하고, 가드레일을 세우고, 결과를 모니터링해야 한다.
그래도 되돌아가고 싶지는 않다. 삐걱대는 날이 있어도, 에이전트가 밤새 리뷰를 달아놓은 아침의 그 느낌. “내가 안 시켰는데 일이 되어 있다”는 경험. 이게 한 번 생기면 이전으로 돌아가기 어렵다.
에이전트에게 “하루”를 준다는 것
지금 시도하고 있는 건 한 단계 더 나아간 실험이다. 에이전트에게 하루라는 개념을 부여하는 것.
지금까지의 에이전트는 크론잡이 깨울 때만 존재했다. 12시에 깨어나서 PR을 리뷰하고, 다시 사라진다. 18시에 깨어나서 레이블을 정리하고, 다시 사라진다. 호출 사이에는 아무것도 없다. 시간의 흐름이 없다.
하루를 부여한다는 건, 에이전트가 아침에 어제의 기억을 읽고, 오늘 할 일의 우선순위를 스스로 판단하고, 저녁에 하루를 정리해서 내일의 자기에게 넘기는 구조를 만든다는 뜻이다. 단순히 시킨 일을 하는 실행자가 아니라, 무엇을 먼저 할지 판단하는 주체로 전환하는 것이다.
아직 완성되지 않았다. 솔직히 말하면 절반도 안 됐다. 기억 시스템이 안정적이지 않고, 우선순위 판단이 사람의 기대와 어긋나는 경우가 많고, 하루의 흐름이 끊기는 지점이 곳곳에 있다.
하지만 방향은 보인다.
에이전트 하나가 하루를 갖게 되면, 에이전트 여러 개가 각자의 하루를 갖게 된다. 그러면 에이전트들 사이에 대화가 필요해진다. A가 발견한 이슈를 B에게 넘기고, B의 결과를 C가 검증하는 파이프라인. 에이전트 팀이 생긴다.
팀이 생기면 팀의 기억이 필요하고, 팀의 교훈이 필요하고, 팀의 우선순위가 필요하다.
이 방향의 끝에 무엇이 있을지는 아직 모른다. 확실한 건, 나의 역할이 계속 바뀌고 있다는 것이다. 코드를 짜는 사람에서, 계획을 세우는 사람으로. 계획을 세우는 사람에서, 시스템을 설계하는 사람으로. 시스템을 설계하는 사람에서, 시스템이 잘 돌아가는 환경을 관리하는 사람으로.
“1종 면허는 따야지”
면허를 딸 때 주변에서 그랬다. “1종은 따야지.” 수동 기어를 다룰 줄 알아야 진짜 운전을 아는 거라고. 그래서 1종을 땄다. 클러치 타이밍을 익히고, 반클러치를 연습하고, 언덕에서 밀리지 않는 법을 배웠다.
면허를 딴 이후, 수동 기어 차량을 단 한 번도 운전한 적이 없다. 그리고 FSD가 나오는 걸 보면, 내 삶에서 수동 기어를 잡을 일은 두 번 다시 없을 것 같다. 기어를 다루는 능력은커녕, 핸들을 잡는 일 자체가 사라질 수 있다. 그러면 뭐가 남는가? 어디로 갈지 결정하는 사람만 남는다.
“1종은 따야지”라는 말이 틀린 건 아니었다. 수동 기어를 다룰 줄 아는 사람이 자동차의 원리를 더 깊이 이해하는 건 사실이다. 하지만 그것이 운전의 핵심 역량이었던 시대는 끝났다. 코드도 마찬가지다. 코드를 짤 줄 아는 사람이 에이전트의 결과물을 더 정확하게 판단할 수 있다. 하지만 코딩 능력이 엔지니어링의 핵심인 시대는 바뀌고 있다. 추상화 레벨이 올라가고 있다. 더 이상 알 필요 없는 것이 생겨나가고 있다.
이건 개발자만의 이야기가 아니다.
의사가 진단에 AI를 쓰기 시작하면, 핵심은 “증상을 외우는 능력”이 아니라 “환자의 맥락을 읽는 능력”이 된다.
변호사가 판례 검색을 AI에 맡기면, 핵심은 “판례를 많이 아는 것”이 아니라 “이 사건에 어떤 논리를 적용할지 결정하는 것”이 된다.
농업에서 센서와 자동화가 들어오면, 핵심은 “밭을 갈 줄 아는 것”이 아니라 “무엇을, 언제, 어디에 심을지 결정하는 것”이 된다.
모든 분야에서 같은 패턴이 반복된다. 도구를 다루는 능력은 항상 다음 추상화에 의해 대체된다. 대체되지 않는 건 “어떤 문제를 풀 것인가”를 정의하는 능력이다.
내가 겪은 네 단계
돌이켜보면 내 여정은 네 단계로 나뉜다.
1단계 — 명령자. “이거 해줘.” AI에게 하나씩 지시한다. 도구를 쓰는 단계. 뉴스레터 정리, 간단한 크롤링. 빠르긴 한데 코드를 읽는 시간이 늘어나는 간극이 생긴다.
2단계 — 설계자. 관심사가 바뀐다. 메모리 구조, GSD, 오케스트레이션의 작동 방식이 궁금해진다. 플로우차트를 반복해서 그리고, 설계가 끝난 다음에야 코드를 지시한다. 여기서 빈 시간이 생기고, 멀티플렉싱이 가능해진다.
3단계 — 운영자. 시스템이 알아서 돌아가기 시작한다. 크론잡이 매일 정해진 시간에 작업을 실행한다. 내가 매번 시키지 않아도 PR 리뷰가 달리고 레이블이 정리된다. 하지만 “알아서”라는 말 뒤에는 환경을 설계하고 유지하는 일이 숨어 있다.
4단계 — 설계하는 존재를 만드는 사람. 에이전트에게 하루를 주고, 사고를 주고, 자율성을 부여한다. 에이전트가 단순 실행자에서 판단하는 주체로 넘어간다. 내 역할은 코드를 짜는 것도, 계획을 세우는 것도 아닌, 판단하는 시스템 자체를 설계하는 것이 된다.
지금 나는 3단계와 4단계 사이에 있다. 3단계는 돌아가고 있고, 4단계는 삐걱대고 있다.
사라지는 것과 남는 것
이 여정을 거치면서 확신하게 된 것이 하나 있다.
엔지니어링은 더 이상 코드를 짜는 일이 아니다.
정확히 말하면, 코드를 짜는 것이 엔지니어링의 본질이었던 적은 한 번도 없을지 모른다. 니즈를 파악하고, 이를 문제로 규명하고, 해결하는 방식을 설계하는 것. 그게 항상 본질이었다. 다만 그 “설계”를 실현하는 과정에서 코드를 직접 짜야 했기 때문에, 코딩 능력이 곧 엔지니어링 능력처럼 보였을 뿐이다.
이제 실현의 도구가 바뀌고 있다. 직접 짜지 않아도 되는 영역이 넓어지고 있다. 코딩 능력이 무의미해지는 건 아니다. 하지만 그것이 핵심 역량의 자리에서 내려오고 있다는 건 인정해야 한다.
분야를 불문하고, 다음 시대에 남는 역량은 세 가지라고 생각한다.
도메인 이해. 무엇이 문제인지 아는 것. AI가 아무리 똑똑해져도, “이 시장에서 지금 가장 아픈 지점이 뭔지”는 그 분야에 발을 담그고 있는 사람만 안다. 설화를 만들면서 에이전트에게 마케팅 전략을 시키지만, “우리 사용자가 진짜 원하는 게 뭔지”는 내가 정의해야 한다.
문제 규명. 풀어야 할 것을 정의하는 것. “이 버그를 고쳐라”가 아니라 “이 사용자 경험이 왜 불편한지 찾아내고, 해결 방향을 세 가지 제시하라”고 말할 수 있는 능력이다. 문제를 잘 정의하면 에이전트가 해결할 수 있다. 문제를 잘못 정의하면 아무리 좋은 에이전트도 쓸모없다.
자동화 경계 설계. 무엇을 자동화하고 무엇을 사람이 할 것인가. 이것이 어쩌면 가장 새로운 역량이다.
모든 걸 자동화하면 통제를 잃는다. 아무것도 자동화하지 않으면 경쟁에서 밀린다. 그 경계를 그리는 감각. 설화에서 PR 리뷰는 에이전트에게 맡기지만, 아키텍처 결정은 내가 한다. 이 선을 어디에 긋는가가 시스템의 품질을 결정한다.
아직 가는 중이다
솔직하게 말하면, 이 글에 쓴 것들의 절반은 아직 완성되지 않았다. 에이전트의 기억은 불안정하고, 하루의 구조는 자주 깨지고, 멀티플렉싱은 가끔 네 개 전부 엉키면서 오히려 생산성이 떨어지는 날도 있다.
하지만 방향은 틀리지 않았다고 확신한다. 6개월 전의 나와 지금의 나는 같은 직업을 가지고 있지만, 하는 일이 다르다. 코드를 짜는 시간은 줄었고, 설계하는 시간은 늘었고, “다음에 무엇을 할까”를 생각하는 시간이 가장 많아졌다.
도구는 계속 바뀐다. 추상화 레벨은 계속 올라간다. 하지만 무엇이 문제인지 파악하고, 그 문제를 정의하고, 해결의 구조를 설계하는 일은 사라지지 않는다. 개발의 행위가 바뀌고 있을 뿐, 엔지니어링의 본질은 처음부터 거기에 있었다.
나는 아직 그 길 위에 있다. 매일 아침, 자리에 앉자마자 검증부터 하면서.
built with Claude Code CLI + OpenClaw + cron + 삐걱거리는 기억 시스템