기술 부채, AI가 지울 수 있는가
'기술 부채를 줄이겠다'는 말은 대부분 선언으로 끝난다. 리팩터링 티켓은 백로그에 쌓이고, 실제로 손대는 팀은 드물다. 그런데 최근 두 가지 사례가 눈에 띈다. 하나는 Bun 런타임의 Zig 포크 프로젝트인 Buz가 LLM과 인간 감독을 병행해 11,000줄 이상의 데드코드를 제거한 것이고, 다른 하나는 개발자 한 명이 ChatGPT를 실질적인 페어 프로그래머로 삼아 Java CLI 도구를 처음부터 완성한 것이다. 두 사례는 규모도 맥락도 다르지만, AI를 쓰는 방식에서 공통된 구조가 보인다.
Buz 프로젝트: LLM은 '정리 도구'였다
Buz는 Bun이 Rust로 재작성되기 직전 커밋에서 출발한 Zig 기반 포크다. 목표 자체는 기술적으로 명확하다—최신 Zig로의 포팅, 1초 미만 증분 빌드, 그리고 60만 줄 규모의 Bun 코드베이스를 정돈된 상태로 만드는 것. 문제는 그 60만 줄 안에 아무도 손대지 않은 레거시가 켜켜이 쌓여 있다는 점이다.
프로젝트가 선택한 방법이 흥미롭다. LLM을 광범위하게 투입해 복잡한 기존 코드를 정리하되, 반드시 사람의 감독을 병행한다. 그리고 코드베이스가 충분히 정돈됐다고 판단할 때까지 외부의 사람이 직접 작성한 기여는 받지 않는다. AI가 생성한 코드가 새로운 기술 부채로 변질되는 것을 막겠다는 의도다. 장기 목표는 명확하다—LLM 없이도 유지보수하기 좋은 코드베이스. AI는 출발점이지 종착점이 아니다.
이미 11,000줄을 제거했고, 그 과정에서 숨어 있던 버그도 함께 수정됐다. Zig 표준 라이브러리 중심으로 코드를 현대화하면서 품질도 올라갔다. 수주에서 수개월 안에 Rust Bun 1.4.0의 호환 대체재를 내놓겠다는 목표를 내걸었다.
CLI 도구 제작: AI는 '모르는 영역의 길잡이'였다
velog에 공개된 Java CLI 도구 개발기는 결이 다르다. 개발자가 솔직하게 고백한다—"영상 관련 프로젝트를 해본 적이 없어서 거의 모든 코드를 ChatGPT에게 물었다." IntelliJ를 1년 가까이 안 쓴 탓에 프로젝트 구조 잡는 것부터 ChatGPT에게 물었다는 것도.
도구의 동작은 단순하다. YouTube 링크와 원하는 구간을 입력하면 yt-dlp로 해당 구간만 내려받고 FFmpeg로 MP4로 변환한다. 하지만 개발 과정은 단순하지 않았다. 한글 파일명 인코딩 오류, webm에서 mp4 변환 시 타임스탬프 계산 오류, FFmpeg 명령 인자 중복 적용 문제—이 세 가지 버그를 모두 ChatGPT와 함께 디버깅했다.
주목할 점은 AI가 틀린 답을 줬을 때의 대응이다. "알려준 문제는 전혀 관련이 없었다"고 짚고, 직접 다른 원인을 추적해 한글 인코딩 문제를 찾아냈다. AI의 답을 맹신하지 않고, 틀렸을 때 직접 판단을 개입시킨 것이다. 이 구조가 없었다면 도구는 완성되지 않았을 것이다.
두 사례의 공통 구조: AI는 실행, 판단은 사람
두 사례를 나란히 놓으면 패턴이 선명해진다.
첫째, AI를 특정 페이즈의 실행 도구로 한정한다. Buz는 '코드 정리' 페이즈에서만 LLM을 투입하고, 기여 구조와 방향 설정은 사람이 쥔다. CLI 도구 개발기에서도 구조 설계와 도메인 분리(domain/infrastructure/application)는 개발자가 결정했다.
둘째, AI가 생성한 결과물을 검증하는 루프를 명시적으로 설계한다. Buz는 '사람의 감독'을 전제로 명문화했다. CLI 개발기의 개발자는 테스트를 돌리고, 오류를 재현하고, AI의 진단이 틀렸을 때 직접 원인을 추적했다.
셋째, AI 의존에서 자립으로 나아가는 방향을 설정한다. Buz의 장기 목표가 'LLM 없이 유지보수 가능한 코드베이스'라는 것은 우연이 아니다. AI로 속도를 내되, 그 결과물이 새로운 의존을 낳지 않도록 설계하는 것이다.
AI-First 팀에게 실제로 의미하는 것
기술 부채 해소에 AI를 쓰는 팀이 늘고 있다. 하지만 AI를 투입했다가 오히려 '이해할 수 없는 리팩터링 결과물'을 받아든 팀도 많다. 두 사례가 공통으로 피한 함정이 바로 그것이다—AI에게 방향까지 맡기는 것.
내일 당장 팀에 적용한다면? 기술 부채 목록에서 '로직 변경 없이 정리 가능한 영역'을 먼저 분리하라. 데드코드 제거, 중복 함수 통합, 변수명 일관화—이 영역은 AI가 빠르게 처리할 수 있고, 검증 비용도 낮다. 이때 반드시 검증 기준을 선 정의하라. 테스트가 없다면 AI를 투입하기 전에 핵심 경로 테스트부터 작성하는 것이 순서다.
전망: 기술 부채 관리 자체가 AI-First로 재설계된다
Buz 프로젝트는 아직 프로덕션 수준이 아니다. CLI 도구는 개인 프로젝트다. 하지만 두 사례가 가리키는 방향은 명확하다—AI는 기술 부채를 '관리'하는 수준을 넘어, 코드베이스를 '리셋'하는 수단으로 쓰이기 시작했다.
팀 리빌딩 관점에서 이 변화는 중요하다. 기술 부채 해소는 그간 '시니어가 시간을 내야만 가능한 일'로 여겨졌다. AI가 그 진입 장벽을 낮추면, 주니어도 AI와 함께 레거시를 정리하는 역할을 맡을 수 있다. 단, 조건이 있다—검증 구조를 설계하고, AI의 판단을 교차 점검하는 능력. 이것이 AI-First 팀에서 개발자에게 요구되는 실질적인 역량이다.