▲

코드 작성에 쓰는 AI 코딩 에이전트는 유지보수 비용을 줄여야 함

 (jamesshore.com)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 새 코드 작성 속도보다 유지보수 비용이 장기 생산성을 좌우함
  • 예시 모델에서는 2년 반 뒤 유지보수가 전체 시간의 절반을 넘음
  • AI 에이전트가 산출량과 유지보수 비용을 함께 늘리면 효과가 빠르게 사라짐
  • 에이전트를 중단해도 이미 만든 코드의 추가 유지보수 비용은 계속 남음
  • 산출량이 두 배라면 코드당 유지보수 비용도 절반으로 낮춰야 함

유지보수 비용이 생산성을 결정함

  • 코드 작성에 쓰는 모든 시간은 이후 버그 수정, 정리, 의존성 업그레이드 같은 유지보수 시간을 계속 발생시킴
  • 새 기능이나 개선 작업이 아니라, 코드가 존재하는 한 매년 반복되는 유지보수만 대상으로 삼음
  • 예시 추정치는 코드 작성 1개월마다 첫해에 10일, 이후 매년 5일의 유지보수 시간이 든다는 가정임
  • Wisdom of the Crowd 방식으로 50명 정도의 개발자에게 유지보수 비용을 물으면 꽤 정확한 답을 얻을 수 있다고 봄
  • 이 가정으로 만든 스프레드시트 모델에 따르면, 새 프로젝트 초반에는 대부분의 시간을 기능 개발에 쓰지만 시간이 갈수록 과거 코드의 유지보수 비중이 커짐
  • 해당 추정치에서는 2년 반 뒤 유지보수에 쓰는 시간이 전체의 절반을 넘고, 10년 뒤에는 거의 다른 일을 하기 어려운 수준이 됨
  • 유지보수 추정치를 절반으로 낮추면 50% 지점까지 3년을 더 벌 수 있고, 두 배로 높이면 1년도 안 되어 생산성이 50% 아래로 떨어짐
  • 생산적인 팀을 원한다면 새 코드 작성 속도보다 유지보수 비용에 집중해야 함

모델은 틀릴 수 있지만 방향은 맞음

  • 후기 단계 스타트업에서는 5~9년 정도 지나 팀이 더 이상 일을 제대로 끝내지 못하는 문제가 나타났고, 이는 그래프가 보이는 패턴과 유사했음
  • 실제 팀이 그래프만큼 나빠 보이지 않는 이유는 유지보수 비용이 낮았기 때문일 수도 있고, 문제를 다른 방식으로 덮었기 때문일 수도 있음
  • 가능한 대응은 모든 버그를 고치지 않거나 모든 의존성을 업그레이드하지 않는 것, 팀이 느려질 때 인원을 추가하고 계속 더 추가하는 것, 전체를 버리고 재작성하는 것임
  • 정확한 숫자는 논쟁할 수 있지만, 시간이 지나며 생산성이 줄어드는 큰 흐름은 경험적으로 맞아 보임

AI 코딩 에이전트가 만드는 곱셈 효과

  • 예시로 최신 에이전트형 코딩 프레임워크 Rock Lobster 가 코드 산출량을 두 배로 늘린다고 가정함
  • 동시에 코드가 조금 더 이해하기 어려워지고, 팀이 풀 리퀘스트에 압도되며, 승인 전에 코드를 제대로 읽지 않는다고 가정함
  • 한 달에 두 달 치 코드를 만들고, 그 산출물의 유지보수 비용도 두 배가 되면 다음 달의 유지보수 비용은 4배가 됨
  • 이 극단적 예시에서는 Rock Lobster 사용 후 약 5개월 만에 생산성이 원래 수준으로 돌아가고, 몇 달 뒤에는 아예 사용하지 않았을 때보다 나빠짐
  • AI가 실제로 생산성이나 유지보수 비용을 두 배로 만든다는 뜻은 아니며, 유지보수성이 인간이 쓴 코드와 같더라도 생산성 이득은 오래가지 않음을 강조함

에이전트를 중단해도 유지보수 비용은 남음

  • 코딩 에이전트는 비용이 들며, 그 효용이 비용보다 작아지면 예전 방식으로 돌아가려 할 수 있음
  • 에이전트 사용을 중단하면 생산성 이득은 사라지지만, 에이전트로 만든 코드의 추가 유지보수 비용은 코드가 남아 있는 한 계속 남음
  • 이 경우 에이전트를 전혀 쓰지 않았을 때보다 낮은 생산성에 묶일 수 있음

성립하는 수학은 유지보수 비용 감소뿐임

  • LLM이 코드 산출량을 늘리는 비율의 정확한 역수만큼 유지보수 비용을 낮춰야 전체 생산성 계산이 맞음
  • 산출량이 두 배이고 그 산출물의 유지보수 비용도 두 배라면 전체 유지보수 비용은 4배가 됨
  • 산출량이 두 배인데 산출물당 유지보수 비용이 그대로여도 전체 유지보수 비용은 여전히 2배가 됨
  • 산출량이 두 배라면 유지보수 비용은 절반이어야 하고, 산출량이 세 배라면 유지보수 비용은 3분의 1이어야 함
  • 이 조건을 만족해야 속도 이득을 얻으면서도 장기적인 종속을 피할 수 있음

현재 코딩 에이전트에 대한 우려와 가능한 다른 지렛대

  • Hacker News 같은 소스에서는 코딩 에이전트가 유지보수 비용을 늘린다는 신호가 많아 보임
  • 일부는 대규모 시스템을 이해하는 데 도움이 된다고 하지만, 필요한 수준의 큰 유지보수 비용 감소는 보이지 않고 오히려 반대에 가깝다고 봄
  • 모델이 현실을 완벽하게 나타내지는 않지만, AI는 새 코드 작성 속도에 비례해 유지보수 비용을 줄여야 한다는 메시지는 유효함
  • 코딩 속도 개선을 추구하더라도 유지보수 비용 개선에도 같은 만큼 시간을 써야 함
  • 반AI 주장이 아니라, 코드 자체의 유지보수성을 높이지 않더라도 유지보수 작업 자체를 더 생산적으로 만드는 AI 같은 다른 지렛대도 있음
  • 실제 상황에 맞게 가정을 바꾸려면 스프레드시트를 복사해 모델의 여러 변수를 조정해볼 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • Dconf'24 발표 Software as investment에서 소프트웨어 조각마다 조합 가능한 가치 함수에 기반한 기본 프레임워크를 제안했음
    이 프레임워크 자체는 AI 때문에 딱히 바뀔 필요가 없고, 별개로 유지보수에서 AI가 얼마나 잘하느냐에 따라 비용 모델만 갱신하면 됨
    AI가 버그를 1.7배 더 만든다지만, 어쩌면 더 빨리 고칠 수도 있어서 잘 모르겠음
    소프트웨어를 투자로 보면 “기술 부채” 대신 “가치”를 말하게 되고, 부채는 가치가 0보다 작은 자산일 뿐임
    소프트웨어가 과거의 고마진 세계를 벗어나면, 경제적으로 존재할 가치가 있는 소프트웨어가 무엇인지 정밀하게 정의해야 함

    • 사람들은 이미 자신의 노력을 투자로 보지만, 그렇다고 시간이 지나며 부채가 쌓이는 걸 막지는 못함
      소프트웨어에는 언제나 더 잘 작성될 수 있었던 부분이 있고, 그게 부채임
    • 이 발표인가? https://youtu.be/YBZ6JFrfuiM?si=6ZdZph8GxOy-OLHZ 궁금해서 보고 싶음

  • 통찰력 있는 관점이고 동의함
    아쉽게도 유지보수성은 보통 “비기능 요구사항”이라는 바구니에 들어감
    하지만 유지보수성 같은 비기능 요구사항은 미래의 기능 요구사항 전달을 보존하고 가능하게 하는 것으로 봐야 함
    단순히 소프트웨어가 무엇을 해야 하는지와 대비되는 “어떻게 해야 하는지” 정도로 프레이밍하면 안 됨
    꾸준한 기능 추가와 개선이 중요한 프로젝트라면, 아주 짧은 기간을 제외하고는 유지보수성이 사실상 기능 요구사항에 가까움

    • 어떤 팀이나 조직이 비기능 요구사항, “기술 부채” 등으로 불리는 문제를 없애려면 첫 단계이자 가장 중요한 단계는 이름을 붙이지 않는 것이라고 봄
      별도 이름을 붙이는 순간, 잘 모르는 사람이 그것을 따로 울타리 치고 우선순위를 낮출 명분을 주게 됨
      품질은 중요하며, 유지하지 않으면 손익계산서에 아주 빠르고 강하게 타격을 줌
      그래서 다른 어떤 요소만큼이나 중요함
    • “비기능”이라는 용어는 잊는 게 좋음. 작동하지 않는 소프트웨어를 누가 원하겠나?
      Kevlin Henney의 표현인 운영 특성과 개발 특성을 쓰면 됨
      유지보수성은 근본적인 개발 특성임
    • 맞음. 문제는 많은 소프트웨어 회사가 실제로는 다음 분기 이상을 거의 생각하지 않는다는 데 있음
      1~2년짜리 제품 로드맵이 있을 수는 있지만, 솔직히 말해 그런 로드맵은 엔지니어링 계획보다 영업 목적에 가까운 경우가 많음
      매출이 꺾이면 제품과 엔지니어링은 방향을 바꾸고, 회사 초기일수록 이런 일이 자주 생김
      스타트업 모드를 벗어나면 안정화되어야 하지만, 많은 회사는 그러지 않고 단기 계획 패턴을 계속 반복함
      그 결과 제품 안정성은 낮은 우선순위로 남음
      결국 많은 회사가 좋은 소프트웨어를 만들 자원이 없거나, 실제로 신경 쓰지 않는 것 같음
    • 유지보수 비용 논리는 양쪽으로 작동함
      우리 프로젝트를 만들며 겪어보니 AI는 빠르지만, AI가 넣는 버그는 이상하게 발견하기 어려움
      뻔한 버그가 아니라, 3주 뒤 운영 환경에서 뭔가 깨지고 추적해보면 AI가 미묘한 부분을 잘못 이해했던 그런 논리임
      솔직히 AI는 유지보수 비용을 줄인다기보다 비용의 위치를 바꿈
      작성 시간은 줄고 검토 시간이 늘어남
      AI 코드는 틀렸을 때도 유창하고 확신에 차 있어서, 사람 코드보다 검토가 더 어려움
      순이익이 되는지는 팀이 코드를 쓰는 것보다 읽는 능력이 얼마나 좋은지에 전적으로 달려 있음

  • 내 경험상 AI는 유지보수 비용을 줄여줌
    다만 맥락이 중요할 수 있음. 나는 수십 년 된 여러 프로젝트를 다루고 있고, 신규 기능 개발도 많지만 오래된 코드와 오래된 프로젝트가 갑자기 훨씬 다루기 쉬워지고 현대화하기 쉬워졌으며, 여러 경우에는 제거도 가능해졌음
    오래된 라이브러리와 빌드 도구 의존성은 어떤 경우에는 업데이트됐고, 어떤 경우에는 그냥 제거됐으며, 빌드는 더 빠르고 개발자에게 쉬워짐
    종단 간 테스트 설정과 자동화도 훨씬 쉬워졌고, DevOps도 많이 개선됐으며, 운영 이슈 진단도 크게 좋아짐
    로그와 정보가 아주 많고, 중요한 것들을 잡기 위한 통합 대시보드와 모니터링도 있지만 이제 배포된 시스템 약 50개 프로젝트에 대해 훨씬 많은 분석을 할 수 있음

    • 나도 비슷하게 느끼지만, 단순히 AI를 유지보수 보조에 쓰는 것이라면 이 논점에 포함되는지는 모르겠음
      글의 기본 주장은 “가치 추가” 기능 개발 1시간당 유지보수를 몇 시간 해야 하느냐에 관한 것임
      그래서 첫째, 유지보수 비용만 측정하면 안 되고 비율을 봐야 하며, 둘째, 그 오래된 코드는 애초에 AI로 작성된 것이 아님
    • 동의함. AI는 레거시 코드를 다루기 쉽게 만들어줌
      다만 저자의 요지는 AI 도구 접근을 잃으면 모든 게 더 막막해진다는 것 같음
      중장비로 산을 편하게 옮기다가 다시 손도구로 돌아가는 셈임
    • AI 지원으로 이해하지 못한 코드베이스 여기저기에 코드를 마구 뿌리는 대기업에서는 완전히 반대의 경험을 하고 있음
      배포되는 코드 줄 수와 함께 장애가 늘었고, 장애도 점점 더 심각해지고 있음
      물론 오래된 코드를 많이 개선했고, 더 많이 삭제했으며, 코드 현대화를 자동화할 수 있고, 문제 진단도 더 잘하고, 완화 선택지도 많아졌음
      하지만 그 모든 것이 아무도 제대로 이해하지 못한 채 배포되는 코드의 압도적인 규모를 상쇄하지 못했음

  • 우리 팀은 AI로 코드를 추가하기도 하지만, 오래되어 폐기된 코드를 공격적으로 제거하는 데도 씀
    “아직 이걸 쓰는 사람이 있나?”, “이게 어떻게 호출되지?” 같은 질문은 프런트엔드, 백엔드, 전체 코드베이스를 에이전트에 던져서 소프트웨어 프로젝트 지도를 만들게 하면 답하기 쉬워짐
    IDE도 단일 언어와 보통 단일 프로젝트 안에서는 어느 정도 해주지만, RPC나 REST 같은 경계가 많은 IDE 도구를 깨뜨림

  • 이 질문이 정말 마음에 듦: 원할 수 있다면 어떤 코드베이스를 원하겠는가?
    잠깐만 생각해보면 아마 기능이 엄청 많은 코드베이스를 바라지는 않을 것임
    지금 가진 것과 꽤 비슷하지만 이해하기 쉽고, 앞으로의 사업 과제에 맞춰 유지보수와 확장이 쉬운 코드베이스를 원하게 됨

    • 코드는 진공 속에 존재하지 않음
      “일하는” 코드베이스, 즉 유지보수하는 코드베이스는 현실의 문제를 풀고 있고, 그런 문제를 푸는 일이 언제나 깔끔함보다 우선해야 함
      깔끔한 코드베이스는 보통 선반 위에 올려두고 감상하는 전시용 예제인 경우가 많음

  • 두 가지를 덧붙이고 싶음
    첫째, 소프트웨어에는 기술적 유지보수만 있는 게 아니라 사용자 지원도 있고, 소프트웨어가 커질수록 이것도 늘어남
    둘째, 유지보수 비용이 선형으로 증가한다고 확신하지 않음
    설령 선형으로 증가하더라도 결국 유지보수에 모든 시간을 쓰는 지점에 도달하게 됨

    • 선형보다 더 빠르게 증가한다고 보는 건가?
      각 부분뿐 아니라 부분들이 서로 상호작용하는 방식까지 유지보수해야 한다면 그럴 수도 있음

  • AI가 실제로 유지보수 비용을 줄이는지에 대해 내가 본 가장 강한 신호는 개발자가 AI 출력을 초안으로 대하는지, 아니면 최종 산출물로 대하는지임
    기존 코드베이스에서 AI 도구를 쓸 때, 예컨대 낯선 모듈 이해, 표적 리팩터링 생성, 마이그레이션 스크립트 작성에서는 유지보수 부담이 실제로 줄어듦
    내가 아키텍처적으로 이미 이해하는 코드 위에서 AI가 작업하므로 출력을 빠르게 평가할 수 있기 때문임
    문제는 AI가 아무도 깊이 이해하지 못하는 신규 코드를 생성할 때 나타남
    그 코드는 작성하지도 설계하지도 않은 사람이 유지보수해야 함
    다른 사람이 쓴 코드라면 적어도 이름, 구조, 커밋 이력에서 의도를 추론할 수 있음
    AI 생성 코드는 “작성자”가 파일 전반에 걸친 지속적인 의도를 갖고 있지 않기 때문에 그런 가독 가능한 의도가 부족한 경우가 많음
    글이 맞는 부분은 속도뿐 아니라 유지보수 비용을 측정해야 한다는 점임
    실제로는 며칠이 아니라 몇 달에 걸쳐 AI 보조 코드와 사람이 쓴 코드의 이해 소요 시간과 변경 실패율을 추적해야 함

  • 코드 리뷰도 마찬가지임
    AI가 코드 리뷰를 더 보기 좋게 만들 수 있을지 궁금함
    사람 코드 리뷰에서는 개발자들이 코드나 주석을 리플로우하거나, 도구가 숨기지 못하는 들여쓰기를 바꾸거나, 함수를 옮기거나, 줄을 지우는 식의 불필요한 시각적 변경을 피하는 법을 빨리 배움
    불필요한 리팩터링도 하지 않아야 함
    리뷰를 기능 변경과 외형 변경 두 개로 나눌 수도 있을 것 같음

    • 리팩터링은 별도 리뷰로 하고, 동작 변경이 없다는 규칙과 함께 “REFACTOR_ONLY:” 같은 표현을 붙이면 됨
      그러면 리뷰가 훨씬 쉬워짐
      리뷰는 “아무것도 바뀌면 안 된다”에서 시작하고, 리뷰어는 패턴 매칭을 할 수 있음
      그렇지 않으면 리뷰어가 모든 코드 줄을 다시 평가해서 아무것도 바뀌지 않았는지 확인해야 하는데, 제대로 하기가 정말 어려움
      내가 써본 버전 관리 시스템들은 각각 독립적으로 리뷰되는 변경 큐를 허용했음
      개발 중 리팩터링이 필요하면 커밋을 하나 올려 리팩터링하고 리뷰를 보낸 뒤, 진행 중인 작업을 리베이스하고 계속함
      “CLEANUP:”, “REFACTOR_ONLY:” 같은 변경을 계속 흘려보내면 최종 변경은 거대한 괴물 변경보다 훨씬 작아짐
      리뷰어들이 그 노력을 고마워할 것임
      그런 조직이라면 지표 게임도 사악하지 않게 할 수 있음
    • 이건 코드 변경 문제가 아니라 코드 리뷰 도구의 문제임
    • https://github.com/ReviewStage/stage-cli가 이 주제에 대한 흥미로운 출발점처럼 보임

  • 저자는 사람이 모든 AI 코드를 자세히 검토하고, AI 도움 없이 이해하고 유지보수할 수 있어야 한다는 가정에서 출발하는 것 같음
    내 경험상 사람들이 AI를 그렇게 쓰지는 않음
    처음에는 그렇게 시작함. 신뢰하기 전이고, 원하는 결과를 얻도록 프롬프트하는 법을 배우기 전에는 지루한 부분을 자동화하는 데 쓰지만, 초기 구현이나 패턴은 사람이 만들고 AI가 빈틈을 채움
    코드 작성 방식의 대전환이라기보다 강화된 자동완성에 가까움
    AI와 더 많이 일할수록 사람들은 AI가 실제로 생성하는 코드를 덜 걱정함
    이게 좋다는 뜻은 아님. 버그, 성능 문제, 보안 구멍을 만들 수 있음
    하지만 현실은 그럼. AI 코드가 버그를 만들었나? AI에게 고치라고 하면 됨
    AI 코드가 비대하고 읽기 어렵나? 신경 쓰이면 AI에게 고치라고 하면 됨. 많은 사람은 신경 쓰지 않음
    사람이 코드 유지보수에서 완전히 빠지면 유지보수 가능한 코드의 필요도 사라짐
    아직 100% 거기까지 간 건 아니지만, 그 방향으로 가고 있음
    많은 회사에는 이미 충분히 괜찮기 때문에 위험을 감수하고 YOLO로 가는 게 가치 있음
    개인적으로는 AI가 생성한 코드를 읽지 않을 만큼 신뢰하지는 않지만, 모든 줄을 읽지도 않음
    테스트 대상 코드보다 테스트를 더 주의 깊게 보고, 성능이 중요한 부분을 더 신경 쓰며, 전체 구조를 안내함
    그래도 기준에 못 미치면 내가 유지보수하는 게 아니라 AI에게 고치라고 함
    유지보수가 이렇게 싸다면 유지보수 비용은 내 관심사에 올라오지 않음

  • 이 글은 AI 에이전트나 보조 도구가 처음의 “새 위젯 만들어줘” 부분뿐 아니라 소프트웨어 개발의 여러 부분을 도와야 한다는 필요를 잘 부각함
    저자는 누군가 AI 에이전트나 보조 도구를 새 위젯을 만드는 단계에만 쓰면, AI로 더 많은 코드를 뽑아내기 때문에 유지보수해야 할 코드도 훨씬 많아진다고 봄
    코드 품질이 높더라도 시간이 지나면 유지보수 비용은 생김
    다만 저자가 말하는 문제는 모두가 겪게 될 문제라기보다 상당 부분 스스로 만든 문제에 가까움
    저자가 지적한 스타트업 상황, 즉 “시장 적합성을 확인하고 고객을 잡기 위해 일단 어떻게든 이걸 돌아가게 만들자”는 상황은 원래도 나중에 더 높은 유지보수 비용을 동반해왔음
    사업이 있는지 확인하고, 있다면 빠르게 키우기 위해 속도 명목으로 품질을 낮추는 건 어느 정도 타당하기 때문임
    또한 저자가 AI가 유지보수 부분을 실제로 어떻게 도울 수 있는지는 말하기를 꺼리는 것처럼 느껴졌음
    AI는 사람의 안내가 있을 때 오래된 의존성 수정이나 성가신 버그 해결에 아주 유용할 수 있음
    이런 작업은 소프트웨어 엔지니어에게 잡일처럼 느껴질 수 있고, AI의 도움을 받고 싶어지는 종류임

답변달기