What happens to technical debt when AI makes code cheap?
Dear past Jenna, I know you're used to dealing with large, complex, legacy codebases riddled with...
개요 #
"충분히 큰 코드베이스에서 기술 부채는 그냥 안고 가야 하는 것이었다. 이제는 아니다." X에 올라온 이 한 문장이 개발자들 사이에서 논쟁을 불렀다. 달린 답글 중에는 정반대 이야기도 있었다. "이제 코드베이스 전체가 기술 부채다."
개발자 Jenna Pederson은 양쪽 다 맞는 말일 수 있다고 봤다. AI는 기술 부채를 고치기 쉽게 만든다. 에이전트는 반복 패턴을 리팩터링하고, 의존성을 마이그레이션하고, 레거시 동작을 감싸는 테스트를 붙이고, 백로그에 영원히 방치될 뻔한 정리 작업을 처리한다. 동시에 부채를 쌓는 일도 놀랍도록 쉬워졌다.
과거의 자신에게 보내는 편지 형식으로 쓴 이 글에서, Pederson은 절약한 시간을 어디에 쓸 것인가라는 질문을 던진다.
기술 부채는 나쁜 코드만을 뜻하지 않는다 #
기술 부채가 곧 형편없는 코드였던 적은 없다. 엔지니어링 실력의 문제도 아니다. 대개는 특정 시점에 의도적으로 내린 트레이드오프의 결과다(유닛 테스트를 끝까지 안 쓴 그 한 사람은 예외로 하고).
문제는 그 결정들이 당시엔 합리적이었다는 데 있다. 시스템이 실제로 어떻게 쓰이고 어떻게 진화해야 하는지 알아가면서, 멀쩡했던 판단이 틀린 판단으로 바뀐다.
코드베이스는 커졌다. 요구사항은 달라졌다. 고객은 버그였던 동작에 의존하기 시작했고(축하한다, 이제 그건 기능이다), 시스템은 팀 단위로 확장됐다. 동료는 들어오고 나갔고 의존성은 낡았다. 3년 전엔 완벽하게 맞아떨어지던 아키텍처가 오늘의 발목을 잡는다.
그때는 아는 만큼 최선의 결정을 내렸다. 그리고 소프트웨어를 프로덕션에 올린 뒤에 더 많은 걸 배웠다.
기술 부채의 상당 부분은 그때 내린 결정과 나중에 알게 된 진짜 필요 사이의 간극이다.
배우는 속도보다 만드는 속도가 빨라졌다 #
아이디어 하나를 큰 시스템으로 바꾸는 데는 시간이 걸렸다. 그리고 만드는 동안 배웠다.
Pederson은 이전 글에서 다룬 '마찰(friction)'을 다시 꺼낸다. 그 마찰의 일부는 멈춰 서서 "이걸 정말 만들어야 하나?"를 묻게 했다. 설계가 바뀌고 요구사항이 뒤집혔다. 구현과 학습이 어느 정도 나란히 일어났다.
지금은 다르다. 엔지니어링 팀은 자기가 뭘 만들고 있는지(혹은 뭘 만들어 버렸는지) 온전히 이해하기도 전에 시스템 하나를 통째로 쌓아 올릴 수 있다.
AI는 구현 시간을 압축한다. 시스템이 무엇이 되어야 하는지 알아내는 시간까지 압축하지는 못한다. 느린 개발이 좋았다는 얘기가 아니다. 다만 우리가 없애고 있는 시간 중 일부는 배우는 데 쓰던 시간이었다.
Photo by Mediahooch Pixels on Pexels
프로덕션 경험은 생성할 수 없다 #
Pederson이 가장 아프게 배운 것들은 테스트 환경에서 재현조차 힘든 프로덕션 이슈에서 왔다.
스레딩과 동시성 버그. 고객 데이터, 시스템 상태, 타이밍, 그리고 아마도 달의 위상까지 아주 특정한 방식으로 정렬돼야만 터지는 버그들(2009년의 그 VAT 세금 계산기를 말하는 거다).
설계는 실제 트래픽을 태우기 전까지 완벽하게 합리적으로 보인다. 진짜 트래픽은 예상하지 못한 타이밍 문제와 레이스 컨디션, 상호작용을 끌고 들어온다.
에이전트는 기대한 대로 정확히 동작하는 시스템을 만들 수도 있다. 사람이 놓칠 문제를 미리 짚어낼 수도 있다. 하지만 에이전트에게도, 우리에게도 수정 구슬은 없다. 에이전트가 구현을 빠르게 도와주는 것과 우리가 더 빨리 배우는 것은 같은 얘기가 아니다.
그 속도를 다르게 써 본다면 #
지금까지의 흐름은 이랬다.
만들고 → 만들고 → 만들고 → 만들고 → 만들고 → 배포 → 관찰 → 학습 → 변경
5주짜리 구현이 1주로 줄었다면, 그만큼 프로덕션에 빨리 도달해 더 일찍 배우기 시작할 수 있다는 뜻 아닐까.
만들고 → 배포 → 관찰 → 학습 → 변경 → 반복
구현 비용은 확실히 싸졌다. 하지만 리뷰, 테스트, 설계 결정 검증, 보안 점검, 운영, 프로덕션에서 배우기는 같은 속도로 싸지지 않았다.
Pederson은 지난주에 접한 브란돌리니의 법칙(Brandolini's law), 이른바 '헛소리 비대칭 원리'를 인용한다.
헛소리를 반박하는 데 드는 에너지는 그것을 만들어 내는 데 드는 에너지보다 자릿수 하나만큼 크다.
코드가 아무 문제 없어도, 리뷰하는 데는 생성하는 것보다 훨씬 오래 걸릴 수 있다.
Codex, 동작을 바꾸지 말고 이 모듈을 리팩터링해줘.
87개 파일 변경됨.
에이전트는 몇 분 만에 거대한 PR을 만든다. 그게 애초에 존재해야 하는 변경인지, 정확하고 안전한지, 시스템에 맞는지, 앞으로 유지보수가 가능한지 판단하는 데는 여전히 몇 시간이 걸린다.
문제는 속도를 어디에 쓰느냐다 #
이 모든 일이 "빨리, 더 빨리"를 요구하는 환경에서 벌어지고 있다.
"에이전트 덕에 빨라졌으니 이제 더 많은 일을, 항상 할 수 있다"는 기대는 실재한다. 리더십이 빨라진 구현 속도를 보고 모든 것을 더 많이 요구한다면, 결국 같은 속도 향상을 겪지 못한 엔지니어링 프로세스에 더 많은 소프트웨어를 밀어 넣는 셈이 된다.
문제는 그 속도를 전부 더 많은 구현에 쓸 때, 그것도 시간을 들일 가치가 있는지 충분히 배우기도 전에 쓸 때 시작된다.
속도를 학습에 쓰자 #
Pederson은 AI가 정말로 과거처럼 기술 부채를 안고 살지 않아도 되게 만들어 주기를 바란다고 적었다. 언젠가 에이전트가 우리가 신경 쓰지 않는 사이에 부채 대부분을 상시 관리할지도 모른다. 기술 부채를 만들고, 지고, 갚는 방식이 몇 년 안에 완전히 달라질 수도 있다. 그건 아직 모른다.
다만 확실한 게 하나 있다. AI가 벌어 준 시간을 전부 더 많은 코드에 쏟아부을 필요는 없다는 것.
일단 내보내고, 어디서 틀렸는지 확인하고, 고치고, 다시 처음부터. 지금으로선 빨라진 구현을 학습 루프 전체를 줄이는 데 쓰는 편이 나을지도 모른다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.