단도직입적으로 말씀드리겠습니다. 코드를 작성하는 데 사용하는 여러분의 AI 코딩 에이전트는 유지보수 비용 (maintenance costs)을 줄여주어야 합니다. 그것도 아주 조금이 아니라 확실히 줄여주어야 합니다. 지금 코드를 두 배 더 빠르게 작성하시나요? 그렇다면 유지보수 비용도 절반으로 줄어들기를 바라십시오. 생산성이 세 배가 되었나요? 유지보수 비용은 3분의 1이 되어야 합니다. 그렇지 않다면, 여러분은 망한 것입니다. 일시적인 속도 향상을 위해 영구적인 속박을 맞바꾸고 있는 셈이니까요.

아, 왜 그런지 알고 싶으신가요? 물론이죠. 드라이브나 가시죠. 어두운 사막 고속도로 위에서...

생산성은 유지보수 비용에 의해 결정됩니다

여러분이 작성하는 모든 코드 라인은 유지보수 (maintenance)되어야 합니다. 버그 수정 (bug fixes), 정리 (cleanup), 의존성 업그레이드 (dependency upgrades) 등이 그것입니다. 새로운 기능이나 개선 사항에 대한 이야기가 아닙니다. 오직 유지보수만을 말하는 것입니다. 코드를 작성하는 데 한 달을 소비한다면, 그다음 해에 그 코드를 유지보수하는 데 일정 시간을 소비할 것이고, 그 코드가 존재하는 한 영원히 그다음 해들에도 매년 일정 시간을 소비하게 될 것입니다.

예를 들어, 50명의 개발자 집단에게 그 유지보수 비용이 어느 정도인지 물어본다고 가정해 봅시다. 대중의 지혜 (Wisdom of the Crowd)라고 불리는 기법을 사용하면 상당히 정확한 답변을 얻을 수 있습니다.

1여러분만의 대중의 지혜 설문조사를 실시해 보셔도 좋습니다! 하지만 제가 여기서 전달하려는 전체적인 요점에는 구체적인 숫자가 중요하지 않다는 것이 밝혀졌습니다.

여러분의 집단은 코드를 작성하는 데 한 달을 소비할 때마다 다음과 같이 소비할 것이라고 말할지도 모릅니다...

• 첫 해에는 유지보수에 10일을 사용하고;
• 그 이후 매년 5일을 유지보수에 사용한다.

만약 여러분이 유난히 집요한 사람이라면, 이러한 추정치들이 시간이 지남에 따라 생산성에 어떤 영향을 미치는지 모델링하는 스프레드시트 (spreadsheet)를 만드는 데 몇 시간을 보낼 수도 있을 것입니다. 다음과 같은 스프레드시트 말이죠.

새 프로젝트의 첫 달은 영광스럽습니다. 여러분은 모든 시간을 멋진 새로운 기능을 만드는 데 사용합니다.

다음 달은 영광스러움이 약간 줄어듭니다. 시간의 아주 일부가—많지는 않지만 약간의—첫 달의 버그를 수정하고 설계 실수를 정리하는 데 들어갑니다. 세 번째 달에는 그보다 조금 더 들어갑니다. 그리고 네 번째 달, 다섯 번째 달, 여섯 번째 달...

결국, 그것은 전혀 영광스럽지 않습니다. 저희 집단의 유지보수 추정치에 따르면, 2년 반이 지난 후에는 시간의 절반 이상을 유지보수에 쓰게 될 것입니다. 10년이 지나면, 다른 일은 거의 아무것도 할 수 없게 됩니다.

집단의 유지보수 추정치를 절반으로 줄이면 50% 지점에 도달하기 전까지 3년의 시간을 더 벌 수 있습니다. 반대로 두 배로 늘리면 1년도 채 되지 않아 50% 미만으로 떨어집니다.

교훈은 명확합니다. 생산적인 팀을 원한다면, 그들의 유지보수 비용에 집중해야 합니다.

모든 모델은 틀렸다

이 수치들이 실감 나시나요? 저에게는 그렇습니다. 컨설턴트로서의 경력 동안 저는 후기 단계의 스타트업을 전문으로 했고, 그들은 모두 위 그래프에 나타난 것과 정확히 똑같은 문제를 겪고 있었습니다. 약 5~9년 차가 되면, 그들은 팀이 더 이상 제대로 된 일을 해내지 못하고 있다는 사실을 깨닫고 저에게 전화를 걸었습니다.

그들의 팀이 그래프에 표시된 것만큼 정확히 나쁘지는 않았을 수도 있습니다. 아마 유지보수 비용이 더 낮았을 수도 있죠. 아니면... 제가 보기엔 이쪽이 더 가능성이 높아 보이는데... 유지보수 비용이 정확히 그 정도로 나빴고, 대신 문제를 겉으로만 가리고 있었을 수도 있습니다. 예를 들면 다음과 같습니다:

• 모든 버그를 수정하거나 모든 의존성 (dependency)을 업그레이드하지 않기로 결정함
• 팀의 속도가 느려지면 인원을 추가하고... 그러면 충분하지 않다는 이유로 계속해서 더 많은 인원을 추가함
• 모든 것을 폐기하고 재작성 (rewrite)으로 새로 시작함

정확한 유지보수 수치에 대해서는 논쟁의 여지가 있겠지만, 전반적으로 이 모델은 타당해 보입니다. 경험이 있는 분이라면, 이 그래프가 사실임을 알고 있을 것입니다. 시간이 흐름에 따라 생산성이 어떻게 녹아내리는지 보아왔을 것입니다. 당신은 그 상처(scars)를 가지고 있습니다.

이것이 AI와 무슨 상관인가?

모든 것과 상관이 있습니다.

당신의 팀이 최신이자 최고의 에이전트 기반 코딩 프레임워크 (agentic coding framework)인 Rock Lobster를 막 사용하기 시작했다고 가정해 봅시다. 그리고 그것이 코드 출력량을 두 배로!! 늘려줍니다! 와우! 하지만 코드를 이해하기는 조금 더 어려워졌고, 팀은 풀 리퀘스트 (pull requests)에 파묻혀 있으며, 당신은 승인 (approve) 버튼을 누르기 전에 코드를 실제로 읽지 않는 상태일 수도 있습니다. 아주 조금도 말이죠. 그러니까, 지루한 회의 중에 가끔 훑어보긴 했지만, 그 정도면 충분히 괜찮은 거겠죠? LGTM (Looks Good To Me), 얼른 이 일을 끝내버립시다!

이제 당신은 한 달 만에 두 달 치의 작업량을 만들어내고 있고, 그 결과 매 '달'의 산출물을 유지보수하는 비용이 두 배로 늘어났다고 가정해 봅시다. 그러면 다음 달의 유지보수 비용은 네 배가 됩니다.

오.

Rock Lobster를 사용하기 시작한 지 약 5개월이 지나면, 당신의 생산성은 처음 시작했을 때 수준으로 돌아가고, 그로부터 몇 달 후에는 애초에 Rock Lobster를 전혀 사용하지 않았을 때보다 상황이 더 나빠집니다.

AI가 유지보수 비용을 두 배로 늘린다는 뜻은 아닙니다. 생산성도 마찬가지고요. 이것은 극단적인 예시입니다. 하지만 설령 당신의 AI가 인간이 작성한 코드만큼이나 유지보수하기 쉬운 코드를 생성한다 하더라도, 생산성 향상은 지속되지 않습니다.

언제든 원할 때 그만둘 수 있습니다2

에이전트 (Agent)는 비용이 많이 들며, 그 비용은 점점 더 높아지고 있습니다. 에이전트가 주는 이득이 투입되는 노력만큼의 가치가 더 이상 없다고 판단되면, 당신은 돈을 아끼기 위해 예전 방식으로 코딩하는 것을 선택할지도 모릅니다. 마치 원시인처럼 말이죠. 손가락을 사용해서 말입니다.

하! 농담입니다! 에이전트 사용을 중단하면 생산성 이점은 모두 사라지지만... 추가된 유지보수 비용은 사라지지 않습니다! 그 코드가 남아 있는 한, 당신은 에이전트를 전혀 사용하지 않았을 때보다 더 낮은 생산성에 갇히게 됩니다.

되돌아가는 길

수학적으로 이 계산이 성립하려면, LLM (Large Language Model)이 코드를 추가하는 속도의 정확히 역수만큼 유지보수 비용을 감소시켜야 합니다. 만약 산출량을 두 배로 늘렸는데 그 산출물을 유지보수하는 비용도 두 배로 늘어난다면, 2 곱하기 2는 유지보수 비용이 네 배가 되었음을 의미합니다. 산출량을 두 배로 늘리면서 유지보수 비용을 일정하게 유지하더라도, 2 곱하기 1은 유지보수 비용이 여전히 두 배가 되었음을 의미합니다.

대신, 생산성을 역전시켜야 합니다. 만약 두 배의 코드를 생산하고 있다면, 유지보수 비용은 절반이 드는 코드가 필요합니다. 세 배의 코드를 생산한다면, 유지보수 비용은 3분의 1이어야 합니다.

이것이 성공의 비결입니다. 모든 이점을 누리면서도, 종속 (Lock-in)은 피하는 것입니다.

이 괴물을 죽일 수 있을까요?

잘 모르겠습니다. 가장 뛰어난 뉴스 소스들을 읽어본 결과, 코딩 에이전트 (coding agents)는 유지보수 비용을 증가시킨다고 합니다. 어떤 이들은 에이전트가 대규모 시스템을 더 잘 이해하도록 도와준다고 말하기도 합니다. 하지만 우리가 목격해야 할 수준의 막대한 비용 절감은요? 아니요, 오히려 그 반대입니다.

그것이 문제입니다. 모델이 현실을 완벽하게 반영하는 것은 아니지만, 전반적인 메시지는 맞습니다. 당신에게는 유지보수 비용을 줄여주는 AI가 필요하며, 그 감소 폭은 새로운 코드로 얻는 속도 향상에 비례해야 합니다. 그렇지 않으면 당신은 망하게 됩니다. 일시적인 속도 향상을 위해 영구적인 속박을 맞바꾸는 꼴이 되기 때문입니다.

그러니, 네, 계속해서 코딩 속도 향상을 쫓으십시오. 하지만 유지보수 비용을 개선하는 데에도 똑같은 시간을 투자하십시오. 그렇지 않으면 당신 또한 '호텔 캘리포니아 (Hotel California)'에 갇히게 될 것입니다.

참으로 아름다운 곳이죠.

참으로 아름다운 얼굴이죠.

그렇게 보일 수도 있겠지만, 이것은 AI에 반대하는 비난을 하려는 의도가 아닙니다. 비록 코드 자체를 더 유지보수하기 쉽게 만들지는 못하더라도, 유지보수 작업 자체를 더 생산적으로 만드는 AI와 같이 활용할 수 있는 다른 레버 (levers)들이 있습니다. 저는 여러분이 스프레드시트를 복사하여 모델의 모든 레버를 직접 조작해 보기를 권장합니다. 가설을 실제 상황에 맞게 변경했을 때 어떤 일이 일어나는지 확인해 보십시오.