IT 책임자라면 언젠가는 기술 부채를 반드시 갚아야 한다는 사실을 잘 안다. 그러나 기업 경영진이 이를 진지하게 받아들이도록 설득하기는 쉽지 않다. 기술 부채 해소가 항상 직접적인 수익 증가 또는 새로운 역량으로 이어지지는 않기 때문이다.

기술 부채는 조직의 장기적 혁신 능력을 저해할 수 있다. 또한 초기 개발 과정에서 지름길을 선택할 경우 결과적으로 난해하고 느리고 개발자가 이해하기 어려운 코드베이스로 이어질 가능성이 높다. 여기에 구식 구성요소 또는 프레임워크까지 추가되면 코드 유지보수는 더욱 어려워진다.

생성형 AI 툴은 개발자가 코드를 작성하는 방식을 근본적으로 바꿔놓지만 그 외에 코드 리팩토링에도 사용되고 있다. 이는 IT 부서가 기술 부채에 접근하는 방식에 있어 중대한 의미를 지닌다.

이 기사를 위해 본지와 대화를 나눈 개발자들은 생성형 AI 툴이 다양한 방식으로 기술 부채에 대처하는 데 사용되고 있다고 전했다. 규모가 작고 즉각적인 기회를 활용하는 방식도 있고, 체계적이고 전체적인 관점에서 접근하는 방식도 있다. 기술 부채에 대처하는 생성형 AI의 능력에 대한 개발자들의 반응은 제각기 다르지만 가까운 시일 내에 이 분야에서 인간이 완전히 배제될 것이라고 생각하는 개발자는 거의 없었다. 다만 전체적으로 AI의 활용 가능성은 유망하다.

코드 정리 작업의 효율성 향상

기술 부채가 지속되는 이유 중 하나는 이를 정리하기 위한 작업이 귀찮고 지루하다는 데 있다. 그래서 미래지향적인 개발자들은 생성형 AI 툴의 도움을 받아 기술 부채에 대처하는 방법을 모색한다.

알아보기 어려운 코드에 명확성 부여. 오래되고 제대로 문서화되지도 않은 코드베이스는 특히 리팩토링하기가 까다롭다. 리팩터링하려면 먼저 코드베이스를 이해해야 하기 때문이다. 크레디블리(Credibly)의 최고 데이터 및 분석 책임자인 댄 옐은 “생성형 AI는 코드베이스를 검토하고 주석을 삽입해서 난해한 프로그램을 엔지니어가 더 쉽게 이해할 수 있도록 함으로써 투명성을 높여준다”라고 말했다.

‘코드 스멜(code smells)’ 감지. AI 툴은 기술적으로 작동은 하지만 잘못된 설계로 인해 향후 문제를 일으킬 가능성이 있는 코드, 즉 기술 부채를 해소하기 위해 제거해야 할 코드를 잘 찾아낼 수 있다.

UST의 수석 AI 설계자인 아드난 마수드는 “우리가 다룬 특히 어려운 사례 중 하나는 수백만 줄의 난해한 코드와 여러 중복된 모듈로 가득 찬 레거시 시스템이었다. 막대한 리소스 소모를 감안하면 수동으로 수정하는 방식은 현실적으로 불가능했다. AI 기반 코드 분석을 적용함으로써 코드 스멜, 중복 패턴, 과도한 종속성, 구조적 취약성을 보이는 불량 모듈을 체계적으로 식별해서 리팩토링 작업의 우선순위를 정확하게 정할 수 있었다”라고 말했다.

린팅 개선. 쿼티드(Qwoted)의 CTO 케빈 트로브리지는 “린팅 툴은 순전히 기계적인 프로세스로, 코드를 평가하고 예를 들어 if/then/else 분기가 너무 많거나 클래스 또는 메서드 본문이 지나치게 긴 경우 등을 감지해 표시한다. 이런 문제를 해결하기 위해서는 상당한 작업이 필요하기 때문에 ‘rubocop:disable’ 또는 ‘rubocop:todo’와 같이 린터에 이를 무시하도록 지시하는 코드 주석이 포함되는 경우가 많다.

이와 같은 주석은 전형적인 기술 부채에 해당한다. 즉, 개발자는 기능 개발 작업을 마친 후 방금 작성한 코드에 언젠가 대대적인 리팩토링이 필요하다는 사실을 깨닫게 된다. 트로브리지는 “여기서 LLM이 빛을 발한다. 많은 경우 위반 사항에 대해 rubocop:todo와 같은 주석 및 파악된 구체적인 문제를 포함해서 코드 내에 주석을 달도록 린터를 구성할 수 있다. ‘rubocop:todos를 해결하라’와 같은 간단한 지시와 함께 LLM에 이 파일을 직접 전달할 수 있다”라고 설명했다.

오래된 종속성 추적. 자신이 작성한 코드가 불량해서가 아니라 그 코드가 의존하는 코드가 변경되거나 유효 기간이 지난 이유로 기술 부채가 발생하기도 한다. 웹 및 모바일 개발 업체 나르 컴퍼니(Gnar Company)의 창업자인 피트 화이팅은 “AI 코딩 어시스턴트는 코드베이스의 모든 라이브러리와 종속성이 얼마나 오래되었는지 파악할 수 있다”라고 말했다. 화이팅은 AI가 기술 부채를 추적하라는 구체적인 지시를 받지 않은 경우에도 이런 링크를 문제로 인식할 수 있다면서 “AI 코딩 어시스턴트는 성능 개선, 일관적인 패턴 적용 또는 모범 사례 따르기와 같은 코드 개선 요청을 받으면 이러한 코드 영역을 파악해 알려준다”라고 말했다.

‘스마트한’ 테스트로 부채 발생 전에 제거

더 넓은 과점에서 기술 부채 작업에 AI 툴을 적용하는 개발자도 있다. 예를 들어 단위 테스트를 보자. 단위 테스트는 기술 부채를 가중시키지 않는 고품질 코드를 생성하기 위해 중요한 툴임에도 최소 실행 가능 제품을 제공하기 위한 속도전에서 무시되는 경우가 많다. 이 경우 나중에 정리 작업에서 프로덕션 코드에 대한 테스트를 작성해야 한다. 부담스러운 작업이지만 생성형 AI 툴을 사용하면 속도를 높일 수 있다.

나르의 화이팅은 “AI 코딩 어시스턴트는 이전에는 테스트가 없었던 기존 기능에 대해 테스트 커버리지를 추가하는 데 유용하다”라고 말했다.

물론 기술 부채를 예방하는 최선의 방법은 처음부터 피하는 것이다. 컴파이(Compai)의 CEO 저스틴 라모스는 “AI 툴은 단위 테스트를 쉽게 생성하는 데 큰 도움이 되고, 이는 기술 부채의 누적을 방지한다. 과거에는 가치 있지만 힘든 작업이었다. 그러나 클로드와 같은 툴을 사용하면 이제 쉽게 할 수 있다”라고 조언했다.

실제로 AI 툴은 이전에는 테스트가 매우 어려웠던 특수한 상황에서 테스트 커버리지를 개선하는 데 도움이 될 수 있다. 도미노 데이터 랩(Domino Data Lab)의 최고 데이터 과학자인 재러드 보드리는 “비결정론적 결과를 갖는 ML/AI 모델에 테스트는 전통적으로 어려운 과제였고, 그로 인해 팀은 복잡한 시스템을 충분히 테스트하지 못하는 경우가 많았다. AI는 모델의 확률적 행동을 반영하고 폭넓은 시나리오에 걸쳐 출력을 검증할 수 있는 포괄적인 테스트 모음을 자동으로 생성함으로써 이와 같은 과제를 해결하고 있다”라고 언급했다.

부채를 전략으로 전환

많은 기업이 기술 부채의 정량화와 수정을 지원하는 인프라 생태계로 AI 툴을 활용하기 시작했다. 쿼리팔(QueryPal)의 CEO이자 창업자인 데브 내그는 AI가 단순히 코드 스멜을 드러내는 데 그치지 않고 “핫스팟, 이탈률, 엔트로피 지표, 심지어 모듈별 변경 비용 예측까지 포함된 완전한 대시보드를 생성할 수 있다”라고 설명했다. 이 경우 기업은 기술 부채를 명확하게 볼 수 있게 된다.

AI 툴은 버그 밀도, 빈번한 변경, 종속성의 무분별한 확산과 같은 패턴을 기반으로 위험한 상태의 구성요소를 식별할 수 있다. 팀은 이런 인사이트를 통해 부채에 대한 공략 방안을 계획할 수 있다. 코더(Coder) CEO 롭 화이트리는 “어디에 문제가 있는지를 알고 빠르게 해결할 수 있다면 부채는 무서운 것이 아닌 전략적인 요소가 된다”라고 말했다.

크레디블리의 옐은 “프레임워크 기반 접근 방식”을 통해 이런 문제를 해결해야 한다면서 이를 위해 코드 복잡성과 성능에 대한 정량적 정의를 통합해야 한다고 말했다. 옐은 “생성형 AI를 사용하면 복잡성을 정의하는 방법을 제안할 수 있지만 어떤 지표가 가장 관련성이 높은지 판단하기 위한 맥락을 가장 많이 갖고 있는 사람은 조직 리더”라고 말했다. 팀은 제안을 통해 직감에 의존한 분류에서 체계적인 문제 해결로 전환할 수 있다.

프레임워크가 마련되면 생성형 AI 툴이 대량의 정리 프로세스를 자동화할 수 있다. CGI의 이사이자 컨설팅 전문가인 케빈 보그랜드는 AI를 사용해 레거시 애플리케이션을 마이그레이션하는 방법을 설명하면서 새 코드의 거의 70%가 생성 및 재사용된다고 말했다. 보그랜드는 “또한 애플리케이션의 전체적인 기술 부채가 대폭, 약 50% 감소한 것을 확인했다”라고 말했다.

중요한 것은 ‘AI에 없는’ 맥락

AI 툴이 기술 부채를 해소할 수 있을 것이라는 기대에도 불구하고 대부분의 실무자들은 루프에 사람을 유지해야 할 필요성을 강조했다.

쿼리팔의 내그는 “AI 툴은 난잡하거나 지나치게 복잡하거나 유지관리가 어려울 것으로 판단되는 코드를 매우 정확히 찾아낸다. 그러나 문제의 코드가 왜 그런 상태가 됐는지, 그것이 진짜 부채인지 아니면 단순히 비즈니스 맥락상의 특성에 불과한지 파악하는 부분에서는 어려움을 겪는다. 한 리포지토리에서 중복 요소로 보이는 루프가 다른 리포지토리에서는 불안정한 벤더 API에 대한 중요한 우회로가 될 수 있다”라고 덧붙였다.

내그는 “문제는 근본적으로 기술 부채는 구조보다는 문화와 맥락 측면의 요소라는 점”이라고 말했다.

내그는 “AI는 코드 재작성 지연의 원인이 된 내부 정치 요인, 마감에 맞추기 위해 어쩔 수 없이 택한 편법, 또는 추상화를 불가능하게 만든 파트너 시스템과의 취약한 계약을 볼 수 없다. 리포지토리에 존재하지 않는 이런 스토리에 접근할 수 없는 AI는 해당 코드의 삭제나 유지를 판단할 수 없다. 이와 같은 맥락 지식이 없으면 AI는 특정 코드를 삭제할지 유지할지 여부를 안정적으로 판단하지 못한다”라고 지적했다.

처음부터 코딩에 AI를 사용하면 기술 부채만 늘어난다는 지적도 있다. UST의 마수드는 이것이 AI 개발의 “역설적 과제”라며 “전례 없는 속도로 코드를 생성할 수 있는 역량은 적절한 거버넌스 프레임워크가 뒷받침되지 않을 경우 아키텍처상의 비일관성을 더 심화시킬 수 있다. 이 긴장 관계를 해결하려면 엄격한 개발 관행 내에서 AI 기능을 정교하게 조율해야 한다”라고 말했다.

퓨전 콜렉티브(Fusion Collective)의 공동 창업자이자 CEO인 이벳 슈미터의 표현은 훨씬 더 직설적이다. 슈미터는 AI 가드레일이 없는 기업에 대해 “AI 생성 코드가 작동한다는 이유만으로 무턱대고 사용할 경우 기술 부채를 제대로 경험하게 될 것이다. 무엇이 기업에 적합하고 그렇지 않을지를 결정하기 위한 판단력을 갖춘 엔지니어가 여전히 필요하다”라고 강조했다.

미래의 기술 부채를 ‘오늘’ 방지하는 방법

그러나 본지와 대화를 나눈 모든 전문가는 기술 부채에 대처하는 데 있어 AI가 일정한 역할을 할 수 있을 것으로 봤다. 제대로 사용된다면(말처럼 단순하지는 않지만) AI는 기술 부채가 발생하기 전에 미리 해소하기 위한 미래지향적 지침을 제공할 수 있다. UST의 마수드는 “AI 프레임워크는 이제 놀라울 만큼 정확하게 부채 누적 경로를 예측할 수 있다”라고 언급했다.

팀은 이런 예측 모델을 사용해 실시간 부채 평가를 코드 검토에 통합해서 문제가 확산되기 전에 포착할 수 있다. 코더의 화이트리는 “이런 예측은 기술 부채를 연례적인 긴급 대응에서 지속적이고 가시적인 백로그로 바꿔준다. 엔지니어링 리더는 이러한 백로그를 우선순위에 따라 관리할 수 있다”라고 설명했다.

기술 부채를 더 빠르고 효율적으로 줄이면 개발자는 원하는 일을 그만큼 더 많이 할 수 있게 된다. 화이트리는 “에이전트 AI가 개발자를 대체한다는 이야기가 많다. 그러나 실제로는 에이전트 AI 덕분에 개발자는 기술 부채를 갚는 일에 매달릴 필요 없이 가치 창출에 집중할 수 있게 된다”라고 강조했다.
dl-itworldkorea@foundryco.com