AI 코딩 도구의 진짜 가치는 코드 작성 속도가 아니라 장기적인 유지보수 비용을 얼마나 줄이느냐에 달려 있다.
곧바로 본론으로 들어가겠다. 코드를 작성할 때 사용하는 당신의 AI 코딩 에이전트는 유지보수 비용을 줄여줘야 한다. 그것도 조금이 아니라, 크게. 이제 코드를 두 배 빠르게 작성한다고? 그렇다면 유지보수 비용은 절반이 되기를 바라는 게 좋다. 생산성이 세 배가 되었다고? 유지보수 비용은 3분의 1이어야 한다. 그렇지 않으면 끝장이다. 당신은 일시적인 속도 향상과 영구적인 예속을 맞바꾸고 있는 셈이다.
아, 왜 그런지 알고 싶다고? 좋다. 한 번 드라이브를 떠나보자. 어두운 사막의 고속도로 위에서...
당신이 작성하는 모든 코드 줄은 유지보수되어야 한다. 버그 수정, 정리, 의존성 업그레이드 등등. 나는 새로운 기능이나 개선 사항을 말하는 게 아니다. 오직 유지보수만 말하는 것이다. 코드를 작성하는 데 한 달을 쓸 때마다, 그 다음 해에는 그 코드를 유지보수하는 데 어느 정도 시간을 쓰게 되고, 그 이후 매년에도 마찬가지로, 그 코드가 존재하는 한 영원히 계속된다.
가령 개발자 50명 정도에게 유지보수 비용이 어느 정도인지 물어본다고 해보자. Wisdom of the Crowd라는 기법을 사용하면, 꽤 정확한 답을 얻을 수 있다.1
1 직접 군중의 지혜 설문조사를 해봐도 좋다! 하지만 여기서 내가 말하려는 전체 요지에는 구체적인 숫자가 사실 중요하지 않다는 점이 드러난다.
당신의 군중은, 코드를 작성하는 데 한 달을 쓸 때마다, 다음과 같은 시간이 든다고 말할지도 모른다...
첫해에는 유지보수에 10일, 그리고
그 이후에는 매년 유지보수에 5일.
당신이 유난히 집요한 사람이라면, 그런 추정치가 시간이 지나며 생산성에 어떤 영향을 주는지 모델링한 스프레드시트를 만드는 데 몇 시간을 쓸 수도 있다. 이런 스프레드시트처럼.
새 프로젝트의 첫 달은 영광스럽다. 모든 시간을 멋진 새 기능을 만드는 데 쓴다.
다음 달은 약간 덜 영광스럽다. 시간의 일부가—많지는 않지만, 조금은—첫 달에 생긴 버그를 고치고 설계 실수를 정리하는 데 들어간다. 세 번째 달에는 조금 더. 네 번째 달, 다섯 번째 달, 여섯 번째 달에도...
결국에는 전혀 영광스럽지 않게 된다. 우리 군중의 유지보수 추정치에 따르면, 2년 반이 지나면 시간의 절반 이상을 유지보수에 쓰게 된다. 10년이 지나면 다른 일은 거의 할 수 없게 된다.
군중의 유지보수 추정치를 절반으로 줄이면 50% 지점에 도달하기까지 3년을 더 벌 수 있다. 반대로 두 배로 늘리면 1년도 되기 전에 50% 아래로 떨어진다.
교훈은 분명하다. 생산적인 팀을 원한다면, 그들의 유지보수 비용에 집중해야 한다.
이 숫자들이 당신에게도 그럴듯하게 들리는가? 내게는 그렇다. 나는 컨설턴트로 일하던 시절 후기 단계 스타트업을 전문으로 했는데, 그들은 모두 위 그래프에 나온 것과 정확히 같은 문제를 안고 있었다. 대략 5~9년쯤 지나면 팀이 더는 제대로 일을 해내지 못하고 있다는 걸 알아차렸고, 그러고 나서 나를 불렀다.
그들의 팀은 그래프가 보여주는 만큼 완전히 나쁘지는 않았다. 어쩌면 유지보수 비용이 더 낮았을 수도 있다. 아니면... 그리고 내게는 이쪽이 더 그럴듯하게 느껴지는데... 유지보수 비용이 정확히 그만큼 나빴고, 대신 그 문제를 겉으로만 덮어두었을 수도 있다. 아마 그들은 다음과 같은 일을 했을 것이다:
모든 버그를 고치거나 모든 의존성을 업그레이드하지 않기로 했다
팀이 느려지면 사람을 더 투입했다... 그리고 그것으로도 충분하지 않아서 계속 더 늘렸다
전부 버리고 재작성으로 처음부터 다시 시작했다
정확한 유지보수 수치에 대해서는 논쟁의 여지가 있다. 하지만 전체적으로 보면, 이 모델은 맞는 느낌이다. 현업을 오래 겪어봤다면, 이 그래프가 사실이라는 것을 안다. 시간이 지나며 생산성이 어떻게 녹아내리는지 직접 봤을 것이다. 그 상처가 당신에게도 있다.
전부 다 관련 있다.
가령 당신의 팀이 방금 Rock Lobster, 최신이자 최고의 에이전트형 코딩 프레임워크를 쓰기 시작했고, 그 덕분에 코드 산출량이 두 배가 되었다고 해보자!! 와우! 그런데 코드는 조금 더 이해하기 어려워졌고, 팀은 풀 리퀘스트에 파묻혀 있으며, 어쩌면 아마도 아주 조금은 승인 버튼을 마구 누르기 전에 코드를 실제로 읽지도 않는다고 치자. 정말로 말이다. 지루한 회의 중에 가끔 훑어보기는 했고, 그 정도면 충분한 거 아닌가? LGTM, 얼른 끝내자!
이제 당신은 한 달에 두 달치 작업을 만들어내고 있다. 그리고 그 “한 달치” 산출물을 유지보수하는 비용도 두 배가 되었다고 해보자. 그러면 다음 달의 유지보수 비용은 _네 배_가 된다.
이런.
Rock Lobster를 사용하기 시작한 지 약 5개월이 지나면 생산성은 다시 원래 수준으로 떨어진다. 그리고 몇 달만 더 지나면, 애초에 Rock Lobster를 건드리지 않았을 때보다 더 나빠진다.
내가 AI가 유지보수 비용을 두 배로 만든다고 말하는 것은 아니다. 생산성도 마찬가지다. 이것은 극단적인 예시다. 하지만 당신의 AI가 사람이 작성한 코드와 똑같이 유지보수하기 쉬운 코드를 만든다고 해도, 생산성 향상은 오래가지 않는다.
2 하지만 결코 떠날 수는 없다.
에이전트는 비싸고, 앞으로도 더 비싸질 뿐이다. 어느 순간 에이전트의 효용이 비용만큼 가치 있지 않게 되면, 돈을 아끼기 위해 예전 방식으로 돌아가고 싶을 수도 있다. 마치 원시인처럼. 손가락 으로.
하! 농담은 당신 쪽이다! 에이전트 사용을 멈추면 생산성 이점은 모두 사라지지만... 추가된 유지보수 비용은 사라지지 않는다! 그 코드가 여전히 남아 있는 한, 애초에 에이전트를 전혀 쓰지 않았을 때보다 더 낮은 생산성에 묶이게 된다.
이 수학은 LLM이 유지보수 비용을 감소시킬 때만 성립하며, 그것도 코드 추가 속도의 정확한 역수만큼 감소시켜야 한다. 산출량을 두 배로 늘리고 그 산출물을 유지보수하는 비용도 두 배로 늘리면, 2 곱하기 2이므로 유지보수 비용은 네 배가 된다. 산출량을 두 배로 늘리고 유지보수 비용을 그대로 유지해도, 2 곱하기 1이므로 유지보수 비용은 여전히 두 배다.
대신 생산성을 뒤집어야 한다. 두 배 많은 코드를 만들고 있다면, 유지보수 비용은 절반인 코드가 필요하다. 세 배 많은 코드라면, 유지보수는 3분의 1이어야 한다.
이것 이 성공의 비밀이다. 모든 이점은 얻고, 종속은 전혀 없다.
글쎄. 내가 최고의 뉴스 소스를 읽어본 바로는, 코딩 에이전트는 유지보수 비용을 증가시킨다. 어떤 사람들은 그것이 대규모 시스템을 더 잘 이해하는 데 도움이 된다고 말하기도 한다. 하지만 우리가 필요로 하는 수준의 큰 비용 감소? 아니다. 오히려 정반대다.
그건 문제다. 이 모델은 현실을 완벽하게 재현한 것은 아니지만, 전체 메시지는 옳다. 당신에게 필요한 것은 유지보수 비용을 줄여주는 AI이고, 그것도 새 코드로 얻는 속도 향상에 비례해서 줄여줘야 한다. 그렇지 않으면 끝장이다. 당신은 일시적인 속도 향상과 영구적인 예속을 맞바꾸고 있는 셈이다.
그러니 그래, 코딩 속도 향상을 좇아도 좋다. 하지만 유지보수 비용 개선도 그만큼의 시간과 노력으로 좇아야 한다. 그렇지 않으면 당신 역시 Hotel California에 갇히게 될 것이다.
정말 아름다운 곳.
정말 아름다운 얼굴.
겉보기에는 그럴 수 있어도, 이것은 AI 반대 폭언으로 쓰인 글이 아니다. 당겨볼 수 있는 다른 레버들도 있다. 예를 들어 유지보수 자체를 더 생산적으로 만들어주는 AI는, 코드 자체를 더 유지보수하기 쉽게 만들지 못하더라도 도움이 될 수 있다. 스프레드시트를 복사해서 모델의 모든 레버를 직접 움직여보길 권한다. 당신의 현실 상황에 맞게 가정을 바꾸면 어떤 일이 일어나는지 확인해보라.
