AI 코딩 에이전트를 결정론적 Java Spring 전문가로 전환하세요

출처: The New Stack

AI 코딩 에이전트가 등장하면서 개발자들은 복잡하고 다단계인 업그레이드 요청을 실험하기 시작했습니다. Spring은 가장 많이 사용되는 Java 프레임워크이기 때문에, 개발자가 “Please upgrade this application to Spring Boot 4”와 같은 자연어 명령만으로 애플리케이션을 업그레이드할 수 있다는 아이디어는 매우 흥미로운 전망입니다.

현실에서는, 특히 대상 애플리케이션이 매우 크고 레거시 프로젝트일 경우, 이런 방식의 업그레이드는 기대에 못 미칠 수 있습니다. 개발자는 초기 결과를 받기 위해 20분 이상, 심지어 그보다 더 오래 기다려야 합니다. 그 후에는 코딩 및 컴파일 오류를 수정하고 테스트 케이스를 검증하기 위해 여러 차례 반복 작업을 해야 합니다.

전체 애플리케이션에 걸쳐 사용되는 주요 프레임워크를 업그레이드하려면 많은 테스트와 검증이 필요합니다. 코드가 컴파일되고 기술적으로는 올바르게 보이더라도, 프레임워크의 동작 방식이 미세하게 바뀌었거나, 업그레이드에 포함된 새로운 기능이 런타임에만 드러나는 경우가 있기 때문입니다.

이러한 앞뒤 반복은 두 가지 측면에서 비용을 증가시킵니다:

• 코드베이스에 내부 공유 라이브러리나 프레임워크에 대한 의존성이 없다고 가정할 때, 이 과정은 1~2일이 소요됩니다. 그리고 변경 사항이 성공적으로 병합될 것이라는 보장은 없습니다(예: CI 체크 실패, PR 거절 등). 코딩 에이전트가 없었다면 며칠이 더 걸릴 수 있지만, 결과는 더 결정적일 가능성이 높습니다. 인간 프로그래머가 작업한 코드는 대체로 정상적으로 동작하고 병합될 수 있기 때문입니다.

• 코드 생성에는 토큰 비용도 고려해야 합니다. 초기 실행과 모든 반복마다 토큰이 소모됩니다.

프레임워크 업그레이드의 목적이 CVE(보안 취약점) 해결이라면 시간은 더욱 중요한 요소가 됩니다. 특히 대규모 업그레이드가 필요할 경우, 가능한 한 빨리 패치를 배포해 잠재적인 보안 위험을 차단하고 싶을 것입니다.

예시: Spring Petclinic 업그레이드

예시로 Spring Petclinic을 Spring Boot 3.5.x에서 Spring Boot 4로 업그레이드하는 과정을 살펴보겠습니다. Spring Petclinic 애플리케이션은 엔티티가 몇 개(수의사, 소유자, 예약)뿐이고 구조가 비교적 단순하고 잘 설계되어 있습니다. AI를 이용해 Spring Boot 3.5.x에서 Spring Boot 4로 마이그레이션하는 데 계획 단계에서 478,380 토큰, 코드 변경 단계에서 908,900 토큰이 소모됐지만 최종적으로는 실패했습니다.

무엇이 문제였을까요? 코딩 어시스턴트가 요청하지 않은 여러 변경을 시도했습니다. 예를 들어 Spring 스타터와 import 문을 업데이트하거나 이름을 바꾸는 작업이 있었습니다. 또한 사용 중단된 메서드에 대한 컴파일러 경고와 실제 컴파일 오류도 발생했습니다. 이 때문에 추가적인 반복 작업이 필요했고, 그만큼 토큰과 시간이 더 많이 소모되었습니다.

Spring 업그레이드에 AI 코딩 에이전트를 사용할 때의 어려움: 오류와 사용 중단된 메서드가 자주 발생해 많은 반복 작업이 필요합니다(위 Spring Petclinic 예시 참조).

그리고 이는 비교적 최신 버전에서 업그레이드한 경우였습니다. 만약 2.7.x와 같은 오래된 버전에서 Spring Boot 4로 업그레이드하려 했다면, 중간 단계가 더 많아져 문제가 발생할 가능성이 훨씬 더 높았을 것입니다.

제 경험에 비추어 보면, 실제로 잘못될 가능성이 높았습니다. 이는 2025년 Broadcom이 Spring Boot 앱의 약 50%가 아직 Spring Boot 2.7 이하 버전을 사용하고 있다고 추정한 점과도 연결됩니다.

업그레이드가 선택 사항이 아닐 때

엔지니어링 팀이 Spring Boot 새 버전으로 업그레이드하는 주요 이유 중 하나는 보안 문제 해결입니다. 현재 Broadcom이 **보안 취약점 발견 급증**을 목격하고 있는 상황에서, 많은 조직이 업그레이드를 보안 대비 전략의 일환으로 인식하고 있습니다.

데모 앱인 Petclinic을 업그레이드하는 번거로움과 비용은 별개로, 실제 운영 환경에서는 여러 Git 저장소가 서로 의존하면서 보안 문제를 해결하기 위해 업그레이드가 그 어느 때보다 필요합니다. 이런 경우 **지속적인 업그레이드 문화**를 실천하는 것이 매우 유용합니다. 모든 의존성 버전을 지원 범위 내에 유지하고 최신 패치 릴리스를 적용하면, CVE가 코드에 영향을 미치는 기간을 최소화하고 Java와 Spring의 최신 최적화를 활용해 인프라 비용을 절감할 수 있습니다.

또한 표준화를 통해 모든 애플리케이션이 동일한 Spring 버전을 사용하도록 하면, 내부 Spring 컴포넌트를 공유하기 쉬워집니다. 비록 언제나 가능한 것은 아니지만, 보다 균일하고 지원되는 Spring 환경을 유지하면 Day‑2 운영 및 지속적인 업그레이드 작업이 일관성을 갖게 되어 유지보수가 훨씬 수월해집니다. 표준화를 추진하려면 규모에 맞는 운영을 고민해야 합니다. 따라서 스스로에게 던져야 할 핵심 질문은 “어떻게 하면 대규모로 Spring을 더 효율적으로 업그레이드할 수 있을까?”가 됩니다.

Petclinic처럼 간단한 사례에서도 확인했듯이, 코딩 에이전트를 사용하면 업그레이드 변경을 빠르게 작성할 수 있지만 완벽하지도, 무료도 아닙니다. 결국 코딩 에이전트는 **본질적으로 비결정적(non‑deterministic)**이기 때문에 예측 가능하거나 일관된 결과를 보장하지 못합니다.

“코딩 에이전트를 사용하면 업그레이드 변경을 더 빠르게 작성할 수 있지만, 코딩 에이전트는 완벽하지도, 무료도 아닙니다. 결국 비결정적이기 때문에 예측 가능하거나 일관되지 않으며, 항상 정확한 결과를 제공하지는 않습니다.”

따라서 핵심 질문은 “AI를 활용한 대규모 업그레이드를 어떻게 가속화하고, 더 정확한 코드 변경을 적용할 수 있을까?” 입니다. 제 경험에 따르면, 규모 있게 좋은 결과를 얻으려면 타입‑안전하고 결정적인 리팩터링을 수행할 수 있는 추가 도구로 코딩 에이전트를 보강해야 합니다.

코딩 에이전트가 어떻게 동작하는지 이해하려면, Human‑in‑the‑Loop(HITL) 접근법이 업그레이드에 어떤 도움이 되는지 먼저 살펴볼 필요가 있습니다.

타입 인식의 필요성: 에이전트 한계 극복

Coding agents는 **대형 언어 모델(LLM)**과 설정된 도구·스킬 세트를 활용해 최적의 답변을 생성하도록 설계된 제품입니다. 코딩 에이전트는 LLM과 도구를 이용해 코드, 설정 파일, 문서 등을 생성하고, 컴파일·테스트 실행·배포와 같은 명령을 수행합니다. 일부 사람들은 “coding agent” 대신 **“harness”**라는 용어를 선호하기도 합니다.

여기서 “도구(tools)”는 Maven이나 Gradle 같은 명령줄 도구를 의미하고, “스킬(skills)”은 특정 상황에서 에이전트가 따라야 할 스크립트와 자연어 설명을 말합니다.

코딩 에이전트는 확장성을 염두에 두고 설계되었습니다. 예를 들어 이러한 도구는 원격 혹은 로컬 MCP 서버(MCP 서버 소개)와 연동해 확장할 수 있습니다. 스킬은 간단한 마크다운 파일 형태로 특정 디렉터리에 저장하면 바로 추가할 수 있도록 설계되었습니다.

많은 개발자들이 코딩 에이전트가 인간처럼 코드베이스를 의미론적으로 분석해 변경을 적용한다고 오해하는데, 이는 사실이 아닙니다. 기본적으로 Claude, Cursor, Copilot 등 대부분의 코딩 에이전트는 코드베이스에 등장하는 각 표현식의 타입이나 정확성을 이해하지 못합니다. 그래서 때때로 컴파일 오류를 유발하는 경우가 발생합니다.

오류를 줄이려면 MCP 서버를 통한 Language Server Protocol(LSP) 연결을 고려할 수 있습니다. 이는 일부 IDE나 개발 도구가 지원하는 기술이지만, 실제 코드 변경에 활용되는 경우는 아직 제한적입니다. Java 환경에서는 가장 유연한 오픈‑소스 LSP 구현을 활용해 타입 정보를 제공함으로써 에이전트가