
"AI 코딩 에이전트 썼더니 6년치 백로그를 쳤어요"
소셜 미디어에서 이런 자랑이 쏟아지고 있습니다. 커서(Cursor)로 백엔드를 3일 만에 만들었다, 클로드 코드로 PR이 자동 생성된다, AI 덕분에 개발자 2명이 20명 몫을 한다.
그런데 재미있는 건, 누구보다 AI를 적극적으로 쓰는 사람들, 즉 프로젝트 관리 툴 Linear를 만든 CEO 카리 사리넨, 센트리(Sentry) 창업자 데이비드 크래머 같은 사람들이 입을 모아 이렇게 말한다는 거예요. "AI 코딩 에이전트를 쓴다고 해서 제품이 더 좋아지고 있다는 느낌이 없다"고요.
어떻게 된 일일까요? 코드가 더 빨리 나오는데 제품은 왜 더 좋아지지 않는 걸까요?
AI 코딩 에이전트가 뭔지 잠깐 짚어볼게요
AI 코딩 에이전트란, 개발자가 자연어로 요청하면 코드를 자동으로 작성하거나 수정해주는 AI 도구입니다. 클로드 코드(Claude Code), 커서(Cursor), 깃허브 코파일럿(GitHub Copilot) 등이 대표적이에요.
단순 자동완성을 넘어서, 전체 기능을 구현하거나 버그를 찾아 고치는 수준까지 발전했습니다. 마이크로소프트 CEO 사티아 나델라는 2024년 말에 "현재 마이크로소프트에서 작성되는 코드의 약 30%는 AI 도구로 생성되고 있다"고 밝히기도 했죠.
단순한 코딩 보조 도구가 아니라, 기능 전체를 만들어주는 자동화 도구입니다. 이게 포인트예요.
K자형 생산성 곡선, 들어보셨나요?
여기서 흥미로운 데이터가 하나 있습니다. AI 코딩 도구의 효과가 누구에게나 동등하게 나타나지 않는다는 거예요.
시니어 개발자는 AI 도입 후 생산성이 눈에 띄게 올라갔습니다. 반면 주니어 개발자는 잘해봐야 제자리걸음, 어떤 경우에는 오히려 퇴보하는 경향이 나타났어요. 이 모양이 알파벳 K와 닮아서 'K자형 생산성 곡선'이라고 부릅니다.
왜 이런 일이 생기는 걸까요?
시니어 개발자는 AI가 만들어낸 코드의 품질을 판단할 수 있습니다. 어디가 위험한지, 어디서 기술 부채가 쌓이는지를 직감적으로 압니다. 그러니 AI를 지렛대로 쓸 수 있어요.
반면 주니어 개발자는 AI가 만들어준 코드를 이유도 모른 채 그냥 복붙합니다. 아키텍처 결정, 보안 설계, 규정 준수 같은 판단은 여전히 경험 많은 엔지니어의 몫이거든요. AI는 그 맥락을 이해하지 못합니다.
AI 코딩 도구는 잘하는 사람을 더 잘하게 만듭니다. 그리고 못하는 사람은 그냥 놔두거나, 더 뒤처지게 만들기도 해요.
"6년치 백로그를 다 쳤다"는 말이 왜 인상적이지 않을까요?
앞서 말한 그 자랑스러운 문장으로 돌아가 봅시다. 이 말을 듣고 감탄하기 전에 딱 하나만 물어봐야 합니다. 그 백로그가 어떤 종류였냐고요.
백로그에는 두 종류가 있습니다.
하나는 반복적인 기능 추가, 내부 도구, CRUD 작업 같은 단순 작업들이에요. AI가 가장 잘하는 것들입니다. 다른 하나는 "어떤 기능을 어떻게 만들어야 사용자가 더 많이 쓸까"라는 근본적인 질문에 답하는 것입니다. AI가 가장 못하는 것이기도 해요.
센트리의 데이비드 크래머는 이렇게 정리했습니다. AI가 만들어낸 코드는 복잡한 소프트웨어를 만들어내지만, 그게 유지보수 가능한 소프트웨어냐는 별개 문제라고요. 장기적으로 오히려 개발 속도를 낮출 수 있다는 결론입니다.
AI가 빠르게 처리하는 백로그는, 사실 제품 품질을 결정하는 핵심 작업이 아닐 가능성이 높습니다.
코드 줄 수는 자산이 아니라 비용이다
이 논의에서 가장 핵심적인 관점 전환이 여기에 있습니다.
우리는 보통 코드를 많이 생산하는 것을 생산성이 높다고 생각합니다. 그런데 좋은 엔지니어링 문화는 정반대로 작동해요. 코드 줄 수는 쓰는 것이지, 생산하는 것이 아닙니다. 필요한 곳에만 씁니다. 불필요한 기능에는 쓰지 않습니다. 코드베이스는 회사의 자산이 아니라 부채입니다.
전기차 소프트웨어로 유명한 comma.ai는 코드베이스가 일정 규모를 넘어서면 알람이 울리는 시스템을 운영했습니다. 코드를 삭제하면 오히려 축하했어요. 코드 한 줄은 버그가 생길 수 있는 표면 하나를 추가하는 것이기 때문이에요.
Linear와 Jira를 비교하면 더 명확합니다. Linear는 직원 178명, 창업 6년 차에 연 반복 수익(ARR) 1억 달러를 달성했습니다. Jira는 누적 개발 인력이 Linear보다 56배 더 많아요. 그런데 사용자 만족도는 Linear가 더 높습니다. 코드 양이 많다고 제품이 좋아지는 게 아니라는 증거죠.
2025년 한 국내 개발자 커뮤니티 설문에서도 비슷한 결과가 나왔습니다. AI 코딩 도구 도입 후 "배포 속도는 빨라졌다"고 답한 비율은 70%가 넘었지만, "제품 완성도가 높아졌다"고 답한 비율은 30%대에 머물렀습니다.
복리 효과는 왜 나타나지 않을까요?
한 가지 재미있는 질문이 있습니다. 클로드 코드(Claude Code)는 클로드 코드로 만들어졌습니다. AI가 AI를 만드는 루프가 닫힌 셈이에요. 그렇다면 지금쯤 경쟁자들을 압도하는 복리 효과를 보여줘야 하지 않을까요?
클로드 코드가 7개월 먼저 출시됐다면, 그 7개월 동안 AI의 힘으로 경쟁자들이 따라올 수 없는 수준으로 발전했어야 합니다. 그런데 현실은 어떤가요? 오픈AI의 코덱스(Codex)는 수개월 뒤에 나왔음에도 기능적으로 충분히 경쟁력 있습니다. 커서(Cursor)도 여전히 강하죠.
복리 효과가 나타나지 않고 있다는 건, 코드를 생산하는 속도가 아니라 좋은 아이디어를 내는 속도가 진짜 제약 조건이라는 뜻입니다. 진짜 병목은 코드 생산량이 아니라 제품 아이디어의 질이었던 거예요.
AI 시대에 가장 희귀한 자원은 취향과 절제력이다
가장 중요한 대목입니다.
최전선에서 경쟁하는 제품의 품질은, 코드를 얼마나 빨리 쓰느냐로 결정되지 않습니다. 어떤 기능을 만들지 않을지를 결정하는 사람의 취향(taste)이 결정합니다.
Linear가 Jira보다 좋은 이유는 더 예쁜 박스를 그려서가 아닙니다. "프로젝트 관리 툴이 어떻게 느껴져야 하는가"에 대한 구체적인 비전을 가진 사람이 있었고, 수년에 걸쳐 그것을 절제 있게 실행했기 때문이에요.
미국의 스컹크 웍스(Skunk Works) 팀 이야기가 있습니다. 켈리 존슨이라는 엔지니어가 이끈 소규모 팀이 SR-71 블랙버드를 만들었는데요, 아직도 인간이 타고 날아간 공기 흡입식 항공기 중 가장 빠릅니다. 60년 전 기록이 깨지지 않았어요. 블랙버드가 빠른 이유는 설계도를 많이 그려서가 아닙니다. 무엇을 빼낼지 아는 취향 때문입니다.
AI 코딩 에이전트를 만들고 있는 개발자 닥스가 자기 팀에게 경고한 것도 같은 맥락입니다. "우리가 만족감을 미루는 능력을 잃어가고 있다"고요. 빠르게 결과물을 내는 것에 익숙해질수록, 느리고 불편한 생각을 기피하게 됩니다. 그 생각이 바로 좋은 제품이 나오는 자리인데도 말이에요.
캠리는 싸지고, 페라리는 여전히 페라리다
그렇다고 AI 코딩 에이전트가 무용하다는 말은 아닙니다. 포지션에 따라 효과가 완전히 달라요.
처음 제품을 만드는 단계, 즉 0에서 1로 가는 과정에서는 AI 코딩 에이전트가 엄청난 도움이 됩니다. 첫 작동 버전까지 걸리는 시간을 극적으로 줄여줍니다. MVP를 빠르게 만들어야 하는 스타트업이라면 반드시 활용해야 합니다.
다만 그 속도에는 대가가 있습니다. 코드베이스가 품질보다 빠르게 커집니다. 기술 부채가 쌓이고, 나중에 누군가 그걸 정리해야 합니다.
비유하자면 이렇습니다. AI 코딩 에이전트는 누구나 쓸 만한 캠리를 싸고 빠르게 만드는 데 탁월합니다. 하지만 페라리를 더 빠르게 만들어주지는 못해요. 페라리의 속도는 설계도를 빨리 그리는 것에서 나오지 않으니까요.
실제로 AWS 연구에서 AI 코딩 도구를 쓴 개발자가 그렇지 않은 개발자보다 작업을 평균 57% 더 빠르게 완료했다는 결과가 나왔습니다. 속도는 분명히 현실이에요. 그 속도를 어디에 쓰느냐가 관건입니다.
마무리
AI가 코드를 대신 쓰는 세상이 왔지만, 진짜 가치 있는 것은 코드를 쓰지 않을 이유를 아는 능력입니다. 더 많은 기능을 빠르게 추가하는 능력이 아니라, 어떤 기능을 빼낼지 아는 취향이에요. 빠른 실행이 아니라, 느리고 불편한 생각을 견디는 인내입니다.
코드를 만드는 속도가 아니라 무엇을 만들지 결정하는 판단력이 남습니다. 그리고 그건 AI 에이전트가 아직 갖지 못한 것이고, 경험 많은 사람이 갖고 있는 것입니다.
도구는 빨라졌습니다. 생각은 여전히 우리 몫입니다.
'IT > AI' 카테고리의 다른 글
| 🤖 AI 에이전트로 코딩하는 시대, 개발자는 무엇을 바꿔야 할까? (0) | 2026.06.05 |
|---|---|
| AI 코딩 에이전트에게 디자인 감각 주는 법, DESIGN.md가 뭔가요? (0) | 2026.06.04 |
| AI 모델만 좋으면 될까? 2026년 가장 뜨거운 개념 "모델-하네스 적합성" (0) | 2026.06.04 |
| AI가 결정하고, 사람이 서명한다? 그 버튼이 진짜 책임을 지는 게 아닌 이유 (0) | 2026.06.03 |
| 🎨 AI가 크리에이터의 도구가 됐다, 어도비와 앤트로픽의 대담한 실험 (0) | 2026.06.03 |