AI 에이전트와 함께 일한다는 것 — OpenClaw 후기
1시간이면 게임이 나온다고요?
요즘 타임라인을 열면 자극적인 숫자들이 넘쳐납니다.
“1시간 만에 게임 완성”, “일주일 만에 SaaS 출시”, “생산성 10배 향상”. 긱뉴스, 트위터, 유튜브 할 것 없이 AI 생산성 신화가 매일 쏟아집니다.
저도 AI 코딩 에이전트를 꽤 많이 씁니다. Claude Max5 계정의 주간 한도를 매주 꽉 채울 정도로요. 기획, 코드 개발, 리서치, 브레인스토밍 — 거의 모든 작업에 AI가 함께합니다.
그렇다고 제가 정답을 알고 있는 건 아닙니다. 그냥 좀 먼저 써본 사람일 뿐이에요. 먼저 가본 길에서 느낀 것들을 남겨봅니다.
찍어먹어 봐야 안다
Sonnet 3.5 시절에 AI로 스페인어 쇼츠를 만들어 올려본 적이 있습니다. 엑셀 포멧에 맞춰 프롬프트 표를 작성하고, A와 B를 비교시키는 주제로 Canva를 활용해서 짧은 영상을 찍어냈습니다.
검수 없이 완전 자동화된 파이프라인을 뚫어서, 리소스를 최소화하고 싶었거든요. 결과는? 접었습니다. 검수 없이는 품질이 안 나왔고, 지금은 AI만으로 만든 영상은 수익 창출 심사조차 통과하기 어려워졌습니다.
반면, 사이드 프로젝트에서는 3주 이상 지연될 것 같았던 기능이 1주일 이내로 끊어지는 경험도 했습니다. 덩어리가 큰 작업을 개발-검증-배포까지 2주 만에 끝낸 적도 있습니다.
실패도 있었고 성공도 있었습니다. 둘 다 직접 해봐야 알 수 있었습니다.
앱도 릴리즈해봤고, 새로운 기능이 나올 때마다 써봤습니다. 맥미니를 사서 AI 에이전트를 24시간 돌리고 있고, 코딩 에이전트의 트렌드를 따라가다 보면 어제까지 중요했던 것이 오늘 알 필요 없어지는 일도 생깁니다.
이 속도감 속에서 “나는 안 쓸 거야”라고 선을 긋는 건 위험하다고 느꼈습니다. 직접 써봐야 어디까지가 과장이고 어디부터가 진짜인지 감이 잡히더라고요.
뉴스 제목만 보고 판단하면, 과대평가하거나 과소평가하거나 둘 중 하나가 되기 쉽습니다.
원래 있던 것, 새로워진 것
코딩 에이전트가 해주는 일들 — 코드 리뷰, 스케줄링, 테스트 작성, 반복 작업 자동화. 사실 이것들은 기존에도 가능했던 기능입니다. 크론 잡, CI/CD 파이프라인, 린터. 새로운 개념이 아닙니다.
달라진 건 자연어로 지시할 수 있게 됐다는 겁니다.
“이 변경사항 리뷰해줘. 편향 없이 낙관/중도/비관 에이전트를 생성해서 토론 후 개별 점수를 매기고 합의 사항에 대해 보고해줘.”
이 한 줄이 실제로 동작한다는 건, 비관론이 뭐라 하든 놀라운 일이었습니다. 진입 장벽이 극적으로 낮아졌고, 그만큼 개발자가 신경 쓸 수 있는 영역이 넓어졌습니다.
저한테 가장 큰 충격을 준 건 ChatGPT가 아니었습니다. 에이전트가 자율적으로 돌아가는 경험이었습니다.
일어나서 에이전트에게 작업을 시키고,
출근하면서 명령하고,
점심시간에 명령하고,
화장실에서 명령하고,
퇴근하면서 명령하고,
자기 전에 명령합니다.
아침이면 정리된 리포트가 와 있습니다. 틈이 있는 모든 순간이 제품을 만드는 순간이 됐습니다.
유비쿼터스 코딩이라고 할까요 — 시간과 장소에 구애받지 않고 제품이 만들어지는 경험. 이건 써보기 전엔 상상하기 어려웠습니다.
물론 공짜는 아닙니다. 매달 $110, 한화로 16만 원이 넘습니다. 적은 돈은 아니지만, 이 비용으로 기획부터 개발, 리서치, 자동화까지 돌아간다고 생각하면 저한테는 충분히 가치가 있었습니다.
내가 일하는 방식, 그리고 현실
제 워크플로우를 공유해봅니다. 정답이라서가 아니라, 참고가 될 수 있을 것 같아서요.
- AI 에이전트가 PR을 생성합니다. 기능 개발, 버그 수정, 리팩토링 — 상당 부분을 에이전트가 초안을 잡습니다.
- Claude 리뷰 CI가 자동으로 리뷰합니다. 타입 에러, 테스트 커버리지 부족, 코드 스타일 등을 잡아냅니다.
- 리뷰 반영 → 재리뷰 사이클을 반복합니다. 에이전트가 지적사항을 수정하고, 다시 리뷰를 받습니다.
- 마지막에 제가 전수검사합니다. 코드를 한 줄씩 읽고, 아키텍처를 점검하고, 직접 실행해서 검증합니다.
실제 사례를 하나 보여드리면 — 최근 스토리지 아키텍처를 통합하는 리팩토링에서, 에이전트가 17개 파일을 변경하는 PR을 만들었고, 3분 후 Claude 리뷰 CI가 P0(Critical) 이슈 1개, P1(Important) 이슈 2개를 잡아냈습니다.
제가 아키텍처를 조치하고 리뷰를 요청하면, 1분 36초 후 재검수 완료.
사이클 자체는 빠릅니다. 문제는 이 사이클 바깥에 있었습니다.
도구가 좋아진다고 10배가 되진 않더라
PR 하나에 30개 파일 변경은 흔합니다. 신기능이면 100개가 넘는 파일이 한꺼번에 생성되기도 합니다.
Anthropic CPO 마이크 크리거(Mike Krieger)의 인터뷰에 따르면 내부 코드의 거의 100%를 Claude로 생성하고, PR당 2,000줄의 변경사항이 발생한다고 합니다. 규모의 문제는 어디서든 마찬가지인 것 같습니다.
10배 생산성이라는 말의 이면에는, 10배의 코드 부채와 리뷰 피로도가 숨어 있었습니다.
아무리 모델이 좋아지고 에이전트가 똑똑해져도, 대규모 변경에서는 아키텍처가 끔찍해지는 경우가 많았습니다. 파일 하나하나는 그럴듯한데, 전체를 조감하면 구조가 뒤엉켜 있는 거죠.
이 과정이 마치 채용과 비슷하다고 느꼈습니다.
에이전트가 PR을 올리면, 저는 면접관처럼 코드를 검토합니다. 잘 만든 건 머지하고, 방향이 틀린 건 그냥 닫아버립니다. 최근 한 달간 닫아버린 PR만 7개입니다.
아키텍처가 근본적으로 잘못된 경우, 이미 다른 방식으로 해결된 경우, 혹은 접근 자체가 맞지 않는 경우 — 수정하는 것보다 새로 시작하는 게 나을 때가 있더라고요.
코드 작성의 텀은 줄었지만, 판단의 빈도는 오히려 늘었습니다. 사람이 감당할 수 있는 역치가 있습니다. 코드가 10배 빨리 생성되어도, 그걸 검증하고 판단하는 속도는 10배가 되지 않았습니다.
예전에는 구글링부터 시작했습니다. 지금은 에이전트한테 먼저 물어봅니다. 코드를 쓰는 시간보다 코드를 읽는 시간이 압도적으로 많아졌습니다. 개발이라는 행위 자체가 바뀌고 있다고 느낍니다.
바뀐 것, 바뀌지 않은 것
비관적인 이야기만 한 것 같지만, 분명히 바뀐 것이 있습니다.
유닛 테스트는 더 이상 제가 직접 작성하지 않습니다.
오해하지 마세요 — 테스트 설계까지 위임한 건 아닙니다. “이 모듈은 어떤 케이스를 검증해야 하는가”를 판단하는 건 여전히 제 몫입니다. 하지만 그 판단을 코드로 옮기는 반복 작업은 에이전트가 합니다.
테스트 단계의 패러다임이 바뀐 것 같습니다. 코드를 작성하는 것에서, 코드를 검증하고 방향을 조율하는 것으로. 개발자의 역할이 “만드는 사람”에서 “판단하는 사람” 쪽으로 무게중심이 이동하고 있다고 느낍니다.
그리고 MVP의 실험적 생명 주기가 어마무시하게 단축됐습니다.
아이디어에서 검증 가능한 프로토타입까지의 거리가 짧아졌다는 건, 더 많이 시도하고 더 빨리 실패할 수 있다는 뜻입니다. 기술부채가 생기는 건 당연합니다. 중요한 건 그걸 얼마나 빨리 갚느냐이고, 갚다가 부채가 더 늘어나지 않게 조율하는 것이었습니다.
그릇을 키우는 중
솔직히 말하면, 제가 실제로 자동화하고 있는 것들은 꽤 소박합니다.
API가 없는 대시보드의 정보를 에이전트가 읽어오게 하거나,
CLI로 Firebase 데이터를 주기적으로 확인하거나,
아침마다 날씨를 알려주는 정도입니다.
실제로는 훨씬 다양한 자동화를 하고 있는 사람들이 많을 겁니다. 저는 아직 이 그릇을 키우는 중입니다.
지금 집중하고 있는 건 결승선에 서 있는 시간 — 그러니까 전수검사에 쓰는 시간 — 을 줄이는 것, 그리고 거기까지 도달하는 과정을 최적화하는 것입니다.
에이전트가 코드를 만들고, CI가 리뷰하고, 제가 아키텍처를 잡고, 자동화가 반복 작업을 덜어주고, 그 여유로 다음 판단을 내리는 — 이 흐름이 끊기지 않게 설계하는 연습을 하고 있습니다.
이건 도구를 잘 쓰는 능력이 아니라, 일의 흐름을 설계하는 능력인 것 같습니다.
이 정도의 자동화를 시작하는 허들이 예전과는 비교할 수 없을 만큼 낮아졌습니다. 관심이 있다면 주저하지 말고 도전해보시길 권합니다.
마치며
이 글은 정답이 아닙니다. 현업 저연차 개발자로서 느끼는 현장감과 프로젝트를 만들면서 탐구심이 있는 사람의 현장 메모 정도로 봐주세요.
1시간 만에 만든 게임은 1시간짜리 게임입니다.
일주일 만에 만든 SaaS는 일주일짜리 SaaS입니다.
빠르게 만드는 것과 좋은 것을 만드는 것은 여전히 다른 문제입니다.
AI 코딩 에이전트는 강력한 도구입니다. 저는 매일 쓰고 있고, 없으면 불편할 정도로 의존하고 있습니다.
하지만 도구가 아무리 좋아져도, 무엇을 만들지 결정하고, 어떤 구조로 만들지 판단하고, 언제 멈추고 고칠지 아는 것은 여전히 사람의 영역이었습니다.
적어도 지금은, 마지막 결승선에는 사람이 서 있어야 한다고 느끼고 있습니다. 이 과정 없이 완전 자동화로 가는 방식도 있겠지만, 그건 결함을 안고 달리는 것과 같았습니다. 롤백을 자주 하거나, 유저 피드백으로 뒤늦게 대응하거나.
안전한 서비스를 만들기 위해서는 에이전트와 사용자 사이에 사람의 완충이 필요했습니다.
벽을 쌓지는 마세요.
직접 써보세요.
하지만 숫자에 흔들리지도 마세요.
뒤에 오시는 분들에게 이 메모가 조금이라도 도움이 되면 좋겠습니다.