코딩 에이전트가 코드를 빨리 써도, 제품은 저절로 좋아지지 않는다
코딩 에이전트가 코드 작성 비용을 낮추는 시대에도, 좋은 제품을 만들기 위해 여전히 사람의 판단과 맥락 관리가 필요한 이유를 정리합니다.
이 글은 아래 두 글을 읽고, 개인적인 해석과 생각을 덧붙여 정리했습니다.
요즘 Claude Code, Codex, Cursor 같은 코딩 에이전트를 쓰다 보면 확실히 느껴진다. 코드는 예전보다 훨씬 빠르게 만들어진다.
반나절은 걸릴 것 같던 구현 초안이 몇십 분 만에 나온다. 테스트 코드도 만들어준다. 리팩터링 방향도 제안한다. 문서 초안까지 정리해준다.
개발자 입장에서는 생산성이 오른 것처럼 느껴지는 순간이 분명히 있다. 실제로 특정 범주의 작업에서는 생산성이 오르는 것도 맞다. CRUD성 기능, 반복적인 코드 수정, 테스트 초안 작성, 간단한 내부 도구 제작 같은 일들은 코딩 에이전트와 꽤 잘 맞는다.
하지만 최근 읽은 두 글은 조금 다른 질문을 던진다.
코딩 에이전트가 코드를 빨리 쓰게 해준다면, 제품도 그만큼 빨리 좋아지고 있을까?
두 글의 표현 방식은 다르지만, 공통된 문제의식은 비슷하다.
코딩 에이전트는 코드 작성 비용을 낮춘다. 하지만 좋은 제품을 만드는 데 필요한 판단, 맥락, 취향, 협업의 문제까지 자동으로 해결해주지는 않는다.
오히려 코드 작성이 쉬워질수록 진짜 병목은 더 선명해진다.
무엇을 만들 것인가.
왜 만들어야 하는가.
무엇을 만들지 않을 것인가.
어떤 복잡도는 감수하고, 어떤 복잡도는 막을 것인가.
이 질문에 답하지 못하면, 코딩 에이전트는 제품을 좋게 만드는 도구가 아니라 복잡도를 더 빠르게 쌓는 도구가 될 수 있다.
병목은 코드가 아니었다
첫 번째 글인 The bottleneck was never the code에서 가장 인상 깊었던 주장은 제목 그대로다.
병목은 원래 코드가 아니었다.
이 글은 소프트웨어 개발을 단순히 코드를 작성하는 일이 아니라, 여러 사람이 “무엇을 만들지”에 대해 합의하는 과정으로 본다. 코드 자체는 중요하지만, 그보다 더 어려운 일은 팀이 같은 그림을 보는 것이다.
무엇이 문제인지 합의해야 한다. 어떤 기능을 만들지 정해야 한다. 어떤 요구사항을 버릴지 결정해야 한다. 어떤 예외 상황을 감수할지 정해야 한다. 사용자에게 어떤 경험을 제공할지 맞춰야 한다.
그 합의가 끝난 뒤에 남는 결과물이 코드다.
예전에는 코드 작성 비용이 충분히 컸기 때문에 우리는 코드 자체에 많은 관심을 두었다. 어떤 언어를 쓸 것인가, 어떤 프레임워크를 쓸 것인가, 어떻게 더 빠르게 구현할 것인가, 어떻게 더 효율적으로 리뷰할 것인가 같은 문제들이 중요했다.
그런데 코딩 에이전트가 등장하면서 코드 작성 비용이 크게 낮아졌다. 그러자 오히려 그 아래에 있던 문제가 드러났다.
코드를 쓰는 사람보다, 어떤 코드가 존재해야 하는지 결정하는 사람이 병목이 된다.
이 관점은 지금 개발 조직에서 꽤 현실적으로 느껴진다. 에이전트가 구현을 빠르게 도와줄수록, 엔지니어는 더 이상 “다음 코드를 어떻게 짤까”만 고민하지 않는다. 오히려 다음과 같은 질문이 더 중요해진다.
- 이 기능은 정말 필요한가?
- 사용자의 어떤 흐름에서 쓰이는가?
- 지금 만들어야 하는가, 아니면 나중으로 미뤄야 하는가?
- 기존 시스템의 어떤 제약을 건드리는가?
- 완료되었다고 판단할 기준은 무엇인가?
- 어떤 테스트가 있어야 안전하다고 말할 수 있는가?
결국 코딩 에이전트 시대의 생산성은 “프롬프트를 얼마나 잘 쓰느냐”만의 문제가 아니다. 더 정확히는 일을 에이전트가 실행 가능한 형태로 정의하는 능력의 문제가 된다.
코드 작성 속도와 제품 개선 속도는 다르다
두 번째 글인 claude code is not making your product better는 조금 더 도발적인 질문을 던진다.
Claude Code가 코드를 빠르게 작성해준다면, Claude Code라는 제품 자체도 압도적으로 빠르게 좋아지고 있어야 하는 것 아닌가?
이 질문은 꽤 흥미롭다. 만약 코딩 에이전트가 제품 개발 속도를 정말로 복리처럼 끌어올린다면, 가장 좋은 코딩 에이전트를 가장 먼저 쓰는 팀은 경쟁자들과 압도적인 격차를 벌려야 한다.
하지만 현실은 그렇게 단순하지 않다. 코딩 에이전트 시장에서는 여전히 Claude Code, Codex, Cursor, 여러 에이전트 도구들이 서로 비교되고 있다. 어느 하나가 완전히 따라잡을 수 없는 격차를 만든 것처럼 보이지는 않는다.
이 글은 그 이유를 이렇게 본다.
코딩 속도는 빨라졌을 수 있다. 하지만 제품 개선 속도는 다른 문제다.
제품이 좋아진다는 것은 단순히 PR이 많아지는 것이 아니다. 기능이 많아지는 것도 아니다. 코드 라인이 늘어나는 것도 아니다.
좋은 제품은 사용자가 더 명확하게 문제를 해결하게 해준다. 불필요한 선택지를 줄인다. 흐름을 단순하게 만든다. 복잡한 문제를 사용자가 덜 느끼게 만든다. 기능을 추가하기보다, 오히려 기능을 덜어내면서 더 좋은 경험을 만든다.
이 지점에서 코딩 에이전트의 한계가 드러난다.
코딩 에이전트는 “만들어줘”에는 강하다. 하지만 “이걸 만들지 말아야 하는 이유를 판단해줘”에는 아직 조심해야 한다.
물론 에이전트도 반론을 제시할 수 있고, 설계 리뷰를 도와줄 수 있다. 하지만 최종적으로 어떤 제품 경험이 더 나은지, 지금 이 기능이 사용자의 문제를 정말 해결하는지, 장기적으로 유지보수 가능한지 판단하는 책임은 여전히 사람에게 남아 있다.
코드는 자산이면서 동시에 비용이다
개발자는 종종 생산성을 코드의 양으로 착각하기 쉽다.
PR을 많이 만들었다. 커밋이 늘었다. 기능을 많이 추가했다. 백로그를 빠르게 처리했다.
겉으로 보면 생산성이 좋아진 것처럼 보인다.
하지만 제품 관점에서 코드는 자산이면서 동시에 비용이다.
새로운 코드 한 줄은 새로운 버그 가능성이다. 새로운 함수 하나는 다음 변경의 의존성이 된다. 새로운 기능 하나는 테스트해야 할 시나리오를 늘린다. 새로운 옵션 하나는 사용자가 이해해야 할 표면적을 넓힌다.
코드는 많을수록 좋은 것이 아니다. 좋은 코드는 필요한 문제를 해결하는 만큼만 존재해야 한다.
코딩 에이전트가 위험해지는 지점은 바로 여기다.
예전에는 구현 비용이 높았기 때문에 자연스럽게 걸러지던 기능들이 있었다.
“이거 있으면 좋긴 한데, 지금 만들 정도는 아니야.”
“내부 도구로 만들 수는 있지만, 유지보수까지 생각하면 과해.”
“일단 수동으로 처리하면서 진짜 반복되는 문제인지 보자.”
그런데 코드 작성 비용이 낮아지면 이런 것들이 전부 만들어질 수 있다. 그리고 만들어진 코드는 사라지지 않는다. 테스트해야 하고, 고쳐야 하고, 문서화해야 하고, 다음 개발자의 머릿속에 들어가야 한다.
즉, 에이전트는 코드 생산 비용을 낮추지만, 잘못 만든 코드의 유지 비용까지 없애주지는 않는다.
오히려 “너무 쉽게 만들 수 있기 때문에” 더 많은 복잡도를 만들 위험이 있다.
시니어에게는 증폭기, 주니어에게는 함정일 수 있다
두 번째 글에서는 코딩 에이전트의 생산성 향상이 모두에게 균등하게 일어나지 않을 수 있다고 말한다. 특히 시니어 엔지니어는 더 생산적이 되지만, 주니어 엔지니어는 오히려 정체되거나 나빠질 수 있다는 문제를 제기한다.
이 주장은 조심해서 받아들일 필요가 있다. 실제 생산성을 어떻게 측정할 것인지, 어떤 조직과 어떤 작업을 기준으로 볼 것인지에 따라 결론은 달라질 수 있기 때문이다.
다만 방향성 자체는 충분히 설득력이 있다.
시니어는 에이전트가 만든 결과를 평가할 수 있다. 이 코드가 현재 시스템과 맞는지 볼 수 있다. 어떤 추상화가 과한지 판단할 수 있다. 테스트가 정말 의미 있는지 구분할 수 있다. 운영 리스크가 어디에서 생길지 예측할 수 있다. 도메인 맥락상 건드리면 안 되는 부분을 알아볼 수 있다.
반면 경험이 부족한 개발자는 에이전트가 만든 코드를 그럴듯한 정답으로 받아들이기 쉽다.
작동은 하지만 왜 작동하는지 모르는 코드가 쌓인다. 테스트는 있지만 무엇을 보장하는지 모른다. 리팩터링은 했지만 복잡도는 오히려 증가한다. 에러는 사라졌지만 문제의 원인은 이해하지 못한다.
이런 상황에서는 코딩 에이전트가 학습을 돕기보다 학습을 건너뛰게 만들 수 있다.
그래서 코딩 에이전트는 주니어를 곧바로 시니어처럼 만들어주는 도구라기보다는, 이미 판단 기준을 가진 사람의 실행력을 증폭시키는 도구에 가깝다.
도구가 강력해질수록 중요한 것은 도구 사용법이 아니라, 결과를 판단하는 기준이다.
진짜 경쟁력은 맥락을 관리하는 능력이다
첫 번째 글에서 가장 중요하게 느껴진 단어는 “맥락”이었다.
조직에서 중요한 맥락은 대부분 코드에만 있지 않다. 문서에도 완전히 남아 있지 않다. 사람들 사이에 흩어져 있다.
왜 이 모듈이 이상한 구조를 갖게 되었는지. 어떤 고객사 요구 때문에 특정 예외 처리가 남아 있는지. 예전에 어떤 선택지를 검토했고 왜 버렸는지. 마이그레이션 중 절대 깨면 안 되는 동작은 무엇인지. 어떤 코드는 낡아 보이지만 실제로는 중요한 호환성을 지키고 있는지.
사람은 이런 맥락을 회의, 코드 리뷰, 장애 대응, 잡담, 과거의 시행착오 속에서 조금씩 흡수한다. 하지만 에이전트는 그렇게 배우지 못한다.
에이전트는 방 안에 같이 앉아 있지 않는다. 회의 분위기를 느끼지 못한다. 지난 장애의 긴장감을 기억하지 못한다. 고객사가 왜 그 기능에 민감한지 체감하지 못한다.
에이전트가 읽을 수 있는 것은 결국 명시적으로 주어진 것들이다.
프롬프트. 코드베이스. 문서. 이슈. PR. 커밋 메시지. 테스트. 운영 로그. 설계 결정 기록.
그래서 앞으로 중요한 조직은 단순히 AI 도구를 많이 쓰는 조직이 아닐 가능성이 높다.
오히려 다음과 같은 조직이 더 강해질 것이다.
- 의사결정의 이유를 남기는 조직
- 스펙과 수용 기준을 명확히 쓰는 조직
- 코드의 히스토리와 도메인 맥락을 관리하는 조직
- 만들지 않을 것을 정할 수 있는 조직
- 빠른 구현보다 제품의 일관성을 중시하는 조직
- 문서화를 귀찮은 부가 작업이 아니라 생산성의 기반으로 보는 조직
코딩 에이전트는 이런 조직에서는 강력한 배율 장치가 된다. 하지만 맥락이 없는 조직에서는 혼란도 같은 비율로 증폭시킨다.
좋은 조직은 더 빨리 좋아지고, 나쁜 조직은 더 빨리 복잡해질 수 있다.
에이전트 시대에 문서화는 더 중요해진다
예전에는 문서화가 종종 “하면 좋지만 바쁘면 밀리는 일”로 취급됐다.
사람은 암묵지를 어느 정도 흡수할 수 있었기 때문이다. 옆자리에서 물어볼 수 있고, 회의에서 들을 수 있고, 오래 일하면서 감을 잡을 수 있었다.
하지만 에이전트와 함께 일하려면 암묵지만으로는 부족하다. 에이전트는 말하지 않은 맥락을 안정적으로 추론하지 못한다.
이제 문서화는 단순히 사람을 위한 기록이 아니다. 에이전트가 제대로 일하기 위한 입력값이기도 하다.
다만 여기서 말하는 문서화는 거창한 산출물을 의미하지 않는다. 현실적으로는 다음 정도만으로도 충분히 가치가 있다.
- 이 기능을 왜 만드는지
- 어떤 사용자 흐름에서 쓰이는지
- 반드시 유지해야 하는 기존 동작은 무엇인지
- 이번 작업에서 하지 않을 것은 무엇인지
- 완료 기준은 무엇인지
- 테스트해야 할 핵심 시나리오는 무엇인지
- 과거에 검토했지만 버린 선택지는 무엇인지
이런 정보가 쌓이면 에이전트는 더 나은 결과를 낼 수 있다. 사람도 더 빠르게 맥락을 이해할 수 있다. 팀은 같은 실수를 반복할 가능성이 줄어든다.
결국 코딩 에이전트 시대의 문서화는 “보고용 문서”가 아니라 실행 가능한 맥락을 만드는 일에 가까워진다.
그래서 개발자는 무엇을 해야 할까
이 두 글을 읽고 내가 정리한 결론은 이렇다.
코딩 에이전트를 쓰지 말자는 이야기가 아니다. 오히려 써야 한다.
이 도구는 분명히 강력하다. 이미 많은 개발 작업에서 실질적인 도움을 준다. 특히 명확하게 정의된 작업, 반복적인 수정, 작은 단위의 구현, 테스트 초안, 코드 탐색, 문서 정리에는 충분히 유용하다.
하지만 코딩 에이전트를 “나 대신 코딩해주는 도구”로만 보면 한계가 빨리 온다.
앞으로 더 중요한 것은 에이전트를 이용해 무엇을 더 빨리 만들 것인가가 아니다.
무엇을 더 정확히 정의할 것인가.
무엇을 검증할 것인가.
무엇을 만들지 않을 것인가.
어떤 복잡도를 막을 것인가.
개발자의 역할은 코드 작성자에서 점점 다음 역할로 이동하고 있다.
요구사항을 구조화하는 사람. 도메인 맥락을 코드와 문서로 연결하는 사람. 에이전트의 결과를 검증하는 사람. 제품의 복잡도를 통제하는 사람. 팀이 같은 그림을 보도록 만드는 사람.
즉, 코딩 능력이 덜 중요해지는 것이 아니다. 코딩만으로 충분하지 않다는 사실이 더 선명해지고 있다.
에이전트가 코드를 더 빨리 쓰는 시대에는 오히려 좋은 개발자의 기준이 더 높아질 수 있다. 코드를 쓰는 능력뿐 아니라, 무엇이 좋은 코드인지 판단하는 능력이 중요해진다. 무엇이 좋은 제품인지 판단하는 감각이 중요해진다. 무엇을 하지 않을지 결정하는 용기가 중요해진다.
내가 앞으로 신경 쓰고 싶은 것들
이 글을 읽고 나서 개인적으로는 코딩 에이전트를 사용할 때 몇 가지 기준을 더 의식해야겠다고 생각했다.
첫째, 작업을 맡기기 전에 문제를 먼저 정리해야 한다. 에이전트에게 바로 “구현해줘”라고 하기 전에, 이 작업이 어떤 사용자 문제를 해결하는지, 성공 기준이 무엇인지, 건드리면 안 되는 제약은 무엇인지 적어야 한다.
둘째, 결과물을 코드가 아니라 판단 대상으로 봐야 한다. 에이전트가 만든 코드는 정답이 아니라 초안이다. 읽고, 의심하고, 줄이고, 테스트해야 한다.
셋째, 더 많이 만드는 것보다 덜 만드는 능력을 유지해야 한다. 코드 작성 비용이 낮아질수록 불필요한 기능을 만들 유혹은 커진다. 하지만 좋은 제품은 대개 더 많은 기능이 아니라 더 적절한 기능에서 나온다.
넷째, 문서화를 더 진지하게 봐야 한다. 문서는 더 이상 나중에 시간이 남으면 하는 일이 아니다. 에이전트와 협업하기 위한 기반이자, 팀의 맥락을 보존하는 장치다.
다섯째, 주니어일수록 에이전트 사용을 학습의 대체재로 쓰면 안 된다. 모르는 코드를 만들어내는 것보다, 작은 코드라도 왜 그렇게 동작하는지 이해하는 것이 더 중요하다.
마무리
코딩 에이전트는 코드 작성 비용을 낮춘다. 하지만 제품을 좋게 만드는 비용까지 자동으로 낮추지는 않는다.
좋은 제품에는 여전히 좋은 판단이 필요하다. 사용자에 대한 이해가 필요하다. 덜어낼 수 있는 용기가 필요하다. 시스템의 맥락을 읽는 능력이 필요하다. 그리고 팀이 같은 방향을 바라보게 만드는 문서화와 커뮤니케이션이 필요하다.
결국 코딩 에이전트 시대에 더 중요해지는 질문은 이것일지 모른다.
“얼마나 빨리 만들 수 있는가?”가 아니라, “무엇을 만들 가치가 있는지 알고 있는가?”
그 질문에 답할 수 있는 개발자와 조직만이, AI가 코드를 더 싸게 만드는 시대에도 오래 살아남을 것이다.
참고한 글
The bottleneck was never the code
https://www.thetypicalset.com/blog/thoughts-on-coding-agents코딩 에이전트로 인해 코드 작성 비용이 낮아질수록, 진짜 병목은 구현이 아니라 스펙, 로드맵, 조직의 합의, 공유 맥락으로 이동한다는 관점을 제시한다.
claude code is not making your product better
https://ethanding.substack.com/p/claude-code-is-not-making-your-product코딩 에이전트가 PR 생성 속도나 코드 생산량을 높일 수는 있지만, 그것이 곧 제품 개선 속도의 증가를 의미하지는 않는다고 주장한다. 좋은 제품은 더 많은 코드가 아니라, 무엇을 만들고 무엇을 만들지 않을지 판단하는 감각에서 나온다는 문제의식을 담고 있다.