AI 코드 리팩터링의 ‘좋은 점, 나쁜 점, 이상한 점’

Besjunior / Shutterstock

생성형 AI는 소프트웨어 개발 세계에서 더 이상 새로운 존재가 아니다. 비서로, 때로는 프리 에이전트로 실제 프로덕션에서 실행되는 코드를 작성하는 용도로 사용이 확대되고 있다. 그러나 개발자라면 누구나 알듯이 새로운 코드 작성은 업무의 극히 일부에 불과하다. 개발자는 기존 코드베이스를 유지보수하고 다른 사람들이 쓴 코드를 리팩터링하는 데 대부분의 시간을 소비한다.

그런데 다른 사람이 아니라 AI 코파일럿에 의해 작성 또는 생성된 코드를 유지보수한다는 것은 어떤 일일까? 깃허브 코파일럿, 버셀(Vercel) v0, 커서(Cursor) IDE와 같은 AI 도구를 사용해서 짐을 덜 수 있을까? AI 혁명의 다음 단계가 어떻게 전개되고 있는지 알아보기 위해 여러 실무자와 대화를 나눴다.

AI가 작성한 코드 : 사용 가능하지만 때로는 이상한 코드

필자가 대화한 모든 개발자는 개발 프로세스의 일부로서 생성형 AI가 가진 유용성에 대해 정도는 다르지만 긍정적인 생각을 갖고 있었다. 또한 이들은 AI가 생성한 코드에는 특색이 있으며, 그로 인해 유지보수하고 리랙터링하기가 까다로울 수 있음을 인정했다.

데브 내그는 지난 몇 년 동안 AI 코딩 도구를 폭넓게 사용해왔으며 현재 AI 중심 티켓 생성에 초점을 둔 소프트웨어 기업 쿼리팔(QueryPal)의 CEO다. 내그는 AI 생성 코드를 리팩터링하고 유지보수하는 프로세스는 생각 이상으로 까다롭다면서 “코드의 스타일과 명명 규칙에 일관성이 부족한 경우가 많고, 이로 인해 코드베이스가 혼란스럽게 느껴진다. 지금까지 프로젝트 규약에 맞게 AI 생성 코드를 정리하고 표준화하는 데 많은 시간을 소비했다”라고 말했다.

IT 서비스 기업 프란쉬테크 솔루션(Pranshtech Solutions)의 CEO이며 SaaS 개발 기업 텍스트드립(Textdrip)의 CTO이자 소프트웨어 개발자인 다발 가자르 역시 “보통 AI 기반 코드는 구문상으로는 올바르지만 모범 사례에 대한 인간 개발자의 이해를 바탕으로 하는 명확성이나 정교함은 부족한 경우가 많다. 많은 경우 개발자가 변수 이름을 정리하고 논리를 간소화하거나 가독성을 높이기 위해 코드를 재구성해야 한다”라고 말했다.

클라우드에서 차세대 시스템을 마이그레이션, 현대화, 구축하는 이노베이티브 솔루션(Innovative Solutions)의 CTO 트래비스 렐은 리팩터링 또는 유지보수를 위해 AI가 작성 코드를 다룰 때 난해함이 커진다면서 “AI가 익숙하지 않은 패턴이나 라이브러리를 사용하면 그러한 선택에 대한 깊은 이해가 없는 경우 리팩터링하기가 어려울 수 있다. 또한 AI가 생성했을 수 있는 복잡한 종속성을 깨트릴 위험도 있다. 기존 경험과는 확실히 다르다. 익숙함과 동시에 낯설게 느껴지는 코드로 작업하게 되는 경우가 많다. AI는 인간 개발자에게 익숙하지 않은 접근 방법을 사용하기도 해서 이로 인해 개발자가 혼란에 빠질 수 있다”라고 말했다.

내그와 가자르는 모두 AI가 생성한 코드가 사람이 작성한, 같은 결과를 달성하는 코드에 비해 더 복잡할 수 있다고 지적했다. 또한 “AI 도구는 솔루션을 오버엔지니어링하는 경향이 있고, 결과적으로 단순한 작업을 위해 생성되는 코드도 필요 이상으로 복잡해질 수 있다. 관련성이 없는 단계를 개발자가 잘라내야 하거나 효율성과 유지보수의 용이함을 위해 구조를 간소화해야 하는 경우가 많다”라고 말했다. 내그는 AI가 “불필요한 오류 처리와 가장자리 사례를 발생시킬 수 있다. 더 간단한 솔루션으로 충분한 상황에서도 마치 자신이 알고 있는 모든 것을 과시하려는 듯한 경향을 보인다”라고 말했다.

이러한 과시에는 이노베이티브 솔루션의 렐이 좋게 평가하는 측면도 있다. 렐은 “AI는 함수가 수행하는 동작에 대해 매우 상세한 주석을 추가한다. 사람이 읽기에 유용하지만 코드베이스를 무겁게 하는 요소가 된다는 면에서 양날의 검과 같다. 하지만 다음에 AI를 사용할 때를 생각해 보자. 함수의 목적에 대한 설명이 있으면 나중에 AI가 이를 다시 읽고 함수의 비즈니스적 맥락을 이해할 수 있을 것”이라고 말했다.

AI의 자체 테스트

여러 유별난 특성에도 불구하고 필자와 대화를 나눈 개발자는 모두 소프트웨어 개발 수명 주기 내에 AI가 생성한 코드에 맞는 자리가 있다고 생각했다. 실제로 이들은 AI 도구가 코드 유지보수와 리팩터링 프로세스에서 유용할 수 있다고 말했다. 다소 모순적이지만 AI 코드에서 발견되는 결함을 극복하는 데도 AI 도구를 사용할 수 있다.

예를 들어 이노베이티브 솔루션의 렐은 코드 분석과 자동 리팩터링, 두 가지 용도로 모두 AI 도구를 배포한다. 렐은 “AI는 대규모 코드베이스를 신속하게 분석하고 리팩터링이 필요한 부분, 잠재적인 버그 또는 최적화 기회를 찾을 수 있다. 변수 이름 변경이나 메서드 추출과 같은 비교적 간단한 리팩터링 작업의 경우 AI 도구가 코드베이스 전체를 대상으로 꽤 정확히 수행할 수 있다”라고 말했다. 쿼리팔의 내그는 “사용 중단된 API 호출을 업데이트하는 것과 같은 코드베이스 전반의 변경 작업에서 AI를 매우 효과적으로 사용한 적이 있다”라고 말했다.

상용 AI 도구는 방대한 코드베이스에서 습득한 모범 사례와 패턴을 학습하기 때문에 사람의 눈에 잘 띄지 않을 수 있는 개선을 제안하는 데 사용할 수도 있다. 내그는 “AI 도구는 패턴을 식별하고 개선을 제안하는 데 있어 탁월하며 이를 통해 리팩터링 프로세스의 속도를 크게 높일 수 있다”라고 말했다.

프란쉬테크의 가자르는 “깃허브 코파일럿과 같은 도구는 코드 간소화, 비효율성 교정, 그리고 일부 패턴에서 식별된 논리의 재구성까지도 제안한다. 자동 반복 작업, 상용구 코드, 리팩터링이 필요한 부분에 대한 힌트를 얻는 데도 도움이 될 수 있다”라고 덧붙였다.

렐은 AI 보조를 받은 코드를 AI 도구를 사용해 리팩터링했던 실제 상황을 설명하며 “AI는 정교한 리액트 구성요소 구조를 만들었지만 이 구조는 백엔드에 설정된 데이터 모델과 잘 맞지 않았다”라고 말했다.

이를 리팩터링하기 위해서는 AI의 효율적인 구성요소 설계를 보존하면서 특정 데이터 흐름에 맞춰 조정하는 신중한 균형 잡기가 필요했다. 특히 유용했던 부분은 리팩터링 프로세스 자체에서 AI(이 사례에서는 커서 IDE)를 사용해 도움을 받은 점이었다. 필요한 변경 사항을 자연어로 설명하면 AI가 코드 수정을 제안했다. 이렇게 해서 사람이 감독하면서 프로세스를 이끌어 AI가 생성한 코드를 AI의 도움으로 리팩터링하는 흥미로운 루프가 만들어졌다.

여전히 사람의 개입은 필요

필자가 이야기한 개발자 중에서 코드베이스를 AI의 재량에 맡겨도 된다고 생각하는 개발자는 없었다. 적어도 아직은 그렇다. 브랜드 개발 기업 에머럴드 오션(Emerald Ocean Ltd.)의 CEO이자 개발자인 제이슨 윈게이트는 AI 도구를 통해 리팩터링 속도를 높일 수 있었지만 여전히 핵심은 사람의 감독이라면서 “AI가 생성한 코드 변경을 항상 검토하고 다듬어야 한다”라고 말했다.

윈게이트는 AI 도움을 받는 반복적인 코딩 프로세스에 대해 설명하며 “가장 기본적인 방법은 리팩터링 제안을 요청하면서 일정량의 코드를 제공하는 것이다. 여기에 언어, 코딩 표준, 규칙에 대한 기본적인 정보를 포함한다. 달성하고자 하는 목표에 따라 더 많은 세부적인 질문으로 들어갈 수 있다. 성능, 가독성 등 목표에 따라 제안을 직접 구현하거나 AI에 맡길 수 있다. 그런 다음 검토하고, (대부분의 경우) 다시 반복한다”라고 말했다.

또한 윈게이트는 AI의 환각 현상에 주의하고 테스트를 수행해 도구가 프롬프트를 올바르게 따랐는지 확인해야 한다면서 “예를 들어 전혀 의미가 없는 문구인 ‘사라의 코딩 표준을 사용’한다는 문구를 집어넣더라도 AI는 ‘물론입니다. 사라의 코딩 표준을 사용하겠습니다!’라고 답할 수 있다”라고 말했다.

쿼리팔의 내그 역시 AI가 생성한 코드를 신중하게 검토할 필요가 있다고 강조하며 “내 경험상 초기 개발과 리팩터링에서 AI를 성공적으로 사용하기 위한 핵심은 풍부한 지식을 갖추었지만 가끔 신뢰하기가 어려운 신입 팀원처럼 대하는 것이다. 신입 팀원에게 코드를 맡기고 검토 없이 프로덕션으로 밀어 넣지는 않을 것이다. AI가 생성한 코드도 마찬가지다. 나는 항상 팀의 숙련된 개발자가 AI의 출력을 검토하고 조정하도록 한다”라고 말했다.

렐은 이와 같은 종류의 인간 감독이 일시적일 것이라고 생각하지 않는다면서 “리팩터링 프로세스에는 사람이 개입하는 환경이 필요하다고 본다. 시스템이 그렇게 설계된 이유에 대한 비즈니스 컨텍스트가 AI 모델에서는 없을 수 있으므로 결과적으로 사람의 조율이 필요하다. QA 엔지니어가 미래의 ‘리팩터링 엔지니어’가 되어 요구사항을 검증하고 출력을 비교하고 그 내용을 다시 AI에 공급하는 역할을 할 수 있을 것”이라고 말했다.

아직 오지 않은 미래

필자가 대화를 나눈 모든 개발자와 IT 리더는 아직은 생성형 AI의 초기임을 강조했다. 대부분의 기업 코드베이스에서 AI 보조(또는 완전한 AI 작성) 코드가 차지하는 양은 적은 편이다. 그러나 AI 보조 리팩터링의 규모가 커지면서 그 양도 필연적으로 늘어나게 될 것이다.

렐은 질식 덩굴(strangler vine) 패턴을 들어 프로세스를 이렇게 설명했다.

예전 기술을 좋아하면서 새 기술을 만들고 싶다면 예전 시스템 옆에 완전히 새로운 시스템을 구축해서 잘라내 붙이거나, 예전 시스템을 중심으로 새로운 시스템의 구성요소를 구축하는 것이다. 이렇게 구성요소 나무와 질식 덩굴을 바꾸기 시작한다. 하지만 이 덩굴은 나무를 질식시킨다.

시간이 지나면 AI로 인해 이 같은 현상이 발생할 것이라고 생각한다. AI는 코파일럿으로 기존 시스템에 노출되면 나무 주변에 있는 것들을 자동으로 문서화하기 시작한다. 그렇게 1년이 지나면 충분한 주석을 확보해서 달성하고자 했던 비즈니스 컨텍스트를 이해하게 되고 나무를 차지하게 된다.

그러나 대부분의 기업은 아직 그 지점까지 이르지 않았다. 쿼리팔의 내그는 “전체적으로 AI 코딩 도구는 많은 영역에서 생산성을 높여줬지만 코드 일관성과 유지보수에서 새로운 과제를 안겨주기도 했다. 일부에서 기대한 만능 해결사만큼은 아니지만, 신중하게 사용하면 개발자의 역량을 대폭 강화할 수 있는 강력한 도구다. 핵심은 적절한 균형을 찾고 코드베이스에서 항상 사람의 개입을 유지하는 것”이라고 말했다.
dl-itworldkorea@foundryco.com

Josh Fruhlinger editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지