최근 AI 코딩 도구는 코드 생성 수준을 넘어 코드 이해, 분석, 리팩토링, 디버깅까지 지원하는 방향으로 빠르게 발전하고 있습니다. 하지만 실제 개발 현장에서 중요한 것은 AI가 얼마나 많은 코드를 생성하느냐가 아니라, 개발자가 문제를 이해하고 해결하는 과정을 얼마나 효과적으로 지원할 수 있느냐입니다.
SLEXN이 공개한 AI 기반 개발 지원 플랫폼 CodeCenter 역시 이러한 관점에서 출발했습니다. 제품 출시 이후 가장 먼저 진행한 검증 대상은 내부 개발 조직이었습니다. 새로운 기능이 실제 개발 업무에서 어떤 가치를 제공하는지, 그리고 개발자의 생산성과 코드 품질 향상에 얼마나 기여할 수 있는지를 직접 확인할 필요가 있었기 때문입니다.
이번 글은 그 과정에서 시작되었습니다. 개발팀과의 논의를 통해 CodeCenter가 제공하는 코드 분석, 컨텍스트 이해, 성능 진단 기능을 살펴보던 중, 실제 프로젝트를 대상으로 검증해보자는 의견이 나왔습니다. 단순 기능 소개가 아니라 개발자가 실제로 마주하는 문제를 AI가 얼마나 효과적으로 해결할 수 있는지 확인해보고 싶었습니다.
이를 위해 오픈소스 Java 프로젝트를 대상으로 성능 분석 및 최적화 실험을 진행했습니다. AI가 코드 구조를 얼마나 정확하게 이해하는지, 병목 지점을 어떻게 찾아내는지, 그리고 개선 방안을 어느 수준까지 제안할 수 있는지를 검증했습니다.
레거시 시스템에서 반복적으로 발생하는 과제
개발자라면 누구나 한 번쯤은 이런 요청을 받아본 적이 있을 것입니다.
“애플리케이션 성능을 개선해 주세요.” or “가끔 원인을 알 수 없는 오류가 발생합니다.”
이런 요청은 고객 지원 채널을 통해 들어오기도 하고, 운영팀이나 인프라팀의 모니터링 결과로 전달되기도 하며, 때로는 경영진의 요구사항으로 내려오기도 합니다.
프로젝트 규모가 비교적 작고 특정 개발자 몇 명만 이해하는 복잡한 레거시 코드가 많지 않다면 문제 해결은 그리 어렵지 않습니다. 물론 시간과 노력이 필요하지만, 대부분은 합리적인 범위 안에서 원인을 파악하고 개선할 수 있습니다.
하지만 프로젝트가 5년, 10년 이상 운영되면서 상황은 달라집니다. 오랜 기간 유지보수를 거치며 코드가 누적되고 담당자가 여러 번 바뀐 시스템에서는 문제의 원인을 찾는 것 자체가 하나의 프로젝트가 되기도 합니다. 어떤 기능이 영향을 받는지 파악하는 데만 며칠이 걸리고, 버그를 찾는 과정은 마치 모래사장 속에서 바늘을 찾는 일처럼 느껴집니다.
특히 대규모 모놀리식 애플리케이션이라면 하나의 성능 이슈를 해결하기 위해 여러 전문가가 투입되고 수일에서 수주가 소요되는 경우도 적지 않습니다. 적어도 몇 년 전까지는 이것이 일반적인 풍경이었습니다.
AI 활용 환경의 변화
그렇다면 지금은 어떨까요?
이제는 AI 없는 개발 환경을 상상하기 어려운 시대가 되었습니다. 2022년 11월 이전만 해도 AI는 머신러닝, 데이터 분석, 이미지 처리와 같은 전문 분야의 기술로 인식되었습니다. 하지만 ChatGPT의 등장 이후 AI는 대규모 언어 모델(LLM)의 형태로 누구나 사용할 수 있는 도구가 되었고, 개발 업무에도 빠르게 적용되기 시작했습니다.
이번 글은 AI 자체를 소개하기 위한 글은 아닙니다.
대신 AI, 그리고 SLEXN의 AI 기반 개발 지원 플랫폼 CodeCenter가 코드 이해와 분석, 디버깅, 성능 최적화 과정에서 실제로 어떤 도움을 줄 수 있는지 살펴보려고 합니다. 이를 위해 오픈소스 Java 프로젝트와 실제 업무 환경에 가까운 프로젝트를 대상으로 성능 분석 및 최적화 실험을 진행했습니다.
Java 프로젝트를 선택한 이유
SLEXN의 주요 고객사는 엔터프라이즈 소프트웨어를 개발하는 기업들입니다. 제 경험상 엔터프라이즈 환경에서는 웹 애플리케이션, 모바일 애플리케이션, 임베디드 시스템을 막론하고 Java가 여전히 중요한 위치를 차지하고 있습니다.
또한 Java 프로젝트는 시간이 지날수록 규모가 커지고 복잡도가 높아지는 경우가 많습니다. 수년 전 작성된 코드가 여전히 서비스의 핵심 기능을 담당하고 있지만, 누구도 선뜻 수정하려 하지 않는 경우도 흔합니다. 문제는 성능 저하나 장애의 원인이 바로 그 오래된 코드에 숨어 있을 때입니다.
수백 개의 클래스와 DAO, DTO, Mapper가 얽혀 있는 환경에서 특정 문제의 원인을 추적하는 일은 개발자에게 상당한 시간과 노력을 요구합니다.
그렇다면 이 과정을 더 빠르게 만들 수는 없을까? 이번 실험은 바로 그 질문에서 시작되었습니다.
코드 분석 관점에서의 AI 활용 가치
AI가 개발자보다 뛰어난 점이 있다면 압도적인 속도로 코드를 읽을 수 있다는 것입니다. 단순히 읽는 것에 그치지 않고 코드 간의 관계를 파악하고 의존성을 분석하며 전체 구조를 이해할 수 있습니다.
개발자가 수백 개의 클래스를 하나씩 검토하며 흐름을 파악하는 데 수 시간 또는 수 일이 걸릴 수 있는 작업을 AI는 수 초 안에 수행할 수 있습니다.
물론 AI가 완벽한 것은 아닙니다. 잘못된 결론을 내리거나 사실과 다른 내용을 생성하는 경우도 있습니다. 따라서 최종적인 판단과 검증은 반드시 개발자의 몫이어야 합니다.
테스트 환경
이제 실제 실험을 시작해보겠습니다.
저는 개발자로서 애플리케이션의 구조와 동작 원리를 이해하고 있지만 Java 전문가라고 보기는 어렵습니다. 이번 실험에서는 대표적인 오픈소스 프로젝트인 PetClinic을 대상으로 테스트를 진행했습니다.
PetClinic은 Spring Boot MVC 기반으로 개발되었으며 오랜 기간 유지보수되어 온 프로젝트입니다. 실제 엔터프라이즈 시스템에 비하면 규모는 작지만, 프로젝트 구조와 기술 스택 측면에서는 충분히 현실적인 예제라고 판단했습니다.
현재도 활발하게 유지보수되고 있는 프로젝트인 만큼 치명적인 문제나 극적인 최적화 포인트가 존재할 가능성은 높지 않습니다. 그럼에도 불구하고 CodeCenter가 어떤 방식으로 프로젝트를 분석하고 개선점을 찾아낼 수 있는지 확인하기에는 적절한 대상이라고 생각했습니다.
다행히 프로젝트에는 JMeter 테스트 시나리오가 포함되어 있어 현재 성능을 비교적 쉽게 측정할 수 있었습니다. (모든 테스트는 로컬 환경에서 진행했습니다.)
테스트 플랜은 애플리케이션의 주요 기능을 검증하도록 구성되어 있으며, 다음과 같은 조건을 사용했습니다.
- 동시 사용자(Threads): 700개
- 각 스레드당 요청 수: 10회
- 리소스별 총 요청 수: 7,000회
- 전체 요청 수: 98,000회
프로젝트를 로컬 환경에 구성한 뒤 Codecenter를 활용해 성능 병목 구간을 분석했습니다.
분석 결과, Codecenter는 하나의 주요 문제와 여러 개선 가능 항목을 제시했습니다.
① Hibernate N+1 문제
가장 먼저 식별된 문제는 대표적인 Hibernate N+1 패턴이었습니다.
N+1 문제는 하나의 조회 쿼리 실행 이후 반환된 각 데이터에 대해 추가 쿼리가 반복적으로 발생하는 현상입니다. 개별 쿼리는 빠르게 수행될 수 있지만 데이터 규모가 커질수록 불필요한 데이터베이스 접근이 누적되며 성능 저하를 유발할 수 있습니다.
② O(n) 선형 탐색
두 번째로 CodeCenter를 통해 식별된 문제는 O(n) 복잡도를 갖는 리스트 기반 선형 탐색 (Linear Search)이었습니다.
현재 구현은 데이터를 찾기 위해 리스트 전체를 순회하는 구조였으며, 시간 복잡도는 O(n)이었습니다. 일반적으로 이러한 경우에는 Map 기반 구조를 사용해 O(1)에 가까운 조회 성능을 확보할 수 있습니다.
Codecenter가 제안한 수정 사항을 적용하기 전에 JMeter 부하 테스트를 수행했습니다.
이번 테스트에서 가장 주목한 항목은 Get Owners API 결과였습니다.
성능 측정에서 중요한 지표 중 하나는 평균 응답 시간(Average Latency)입니다. 이는 사용자가 데이터를 받기까지 걸리는 평균 시간을 의미합니다. 다만 개인적으로는 평균값보다 95th Percentile(P95) 과 99th Percentile(P99) 을 더 중요하게 봅니다.
P95와 P99는 각각 전체 요청의 95%, 99%가 해당 시간 이내에 처리되었음을 의미하는 지표로, 실제 사용자가 경험하는 성능을 보다 현실적으로 보여줍니다.
이번 테스트에서는 전체 요청의 99%가 259ms 이하, 95%가 163ms 이하에서 처리된 것으로 나타났습니다.
③ 개선 사항 적용
이후 CodeCenter에게 발견된 문제를 직접 수정해 달라고 요청했습니다. 몇 분 뒤 CodeCenter는 개선 결과를 제안했습니다. 주요 변경 사항은 다음과 같습니다.
- Fetch Type을 Eager에서 Lazy로 변경
- @EntityGraph 추가
- LEFT JOIN FETCH 기반 커스텀 쿼리 구현
또한 단순히 특정 파일만 수정하는 것이 아니라, 관련된 코드와 의존성을 함께 분석한 뒤 필요한 변경 사항을 연관 파일에도 자동으로 반영했습니다.
변경 사항 적용 이후 프로젝트를 다시 빌드하고 동일한 JMeter 테스트를 수행했습니다.
측정 결과는 다음과 같았습니다.
테스트 결과를 보면 P95 응답 시간은 163ms에서 143ms로 감소했으며, P99 응답 시간은 259ms에서 209ms로 감소했습니다.
이는 각각 약 12%, 19%의 성능 개선에 해당합니다.
다만 이번 결과를 해석할 때 고려해야 할 점이 있습니다. 실험에 사용한 PetClinic은 100명 이상의 개발자가 참여해 지속적으로 유지보수되고 있는 대표적인 오픈소스 프로젝트입니다. 따라서 이미 많은 최적화 작업이 이루어졌을 가능성이 높으며, 코드 규모와 데이터베이스 크기 역시 비교적 작은 편입니다.
반면 실제 엔터프라이즈 환경은 다릅니다. 프로젝트 규모가 커지고 데이터가 증가할수록 성능 병목이 발생할 가능성도 높아집니다. 특히 수년간 운영되며 수십만 라인의 코드가 누적된 시스템에서는 최적화 여지가 훨씬 크기 때문에, AI를 활용한 분석과 개선 효과 역시 더욱 크게 나타날 수 있습니다.
AI 활용 시 고려사항
물론 AI에도 한계는 있습니다. AI는 놀라운 수준의 코드 분석 능력을 보여주지만, 여전히 프로젝트의 비즈니스 맥락이나 의사결정 배경까지 완벽하게 이해하지는 못합니다. 따라서 AI가 제안하거나 수행한 모든 변경 사항은 반드시 경험 있는 개발자의 검토와 승인을 거쳐야 합니다.
실제로 이번 실험에서도 CodeCenter는 여러 개선 사항을 제안했습니다. 하지만 그중 일부는 성능 향상 효과가 미미해 본문에서는 제외했습니다. 만약 사용자가 AI가 수행하는 작업을 이해하지 못한 채 결과만 그대로 적용한다면, 최선의 경우에는 불필요한 토큰과 컴퓨팅 자원만 낭비하게 됩니다. 최악의 경우에는 새로운 버그가 발생하거나 서비스 장애로 이어질 수도 있습니다.
또한 AI가 기술적으로 올바른 개선 사항을 찾아냈다고 해서 그것이 항상 적용해야 할 변경 사항이라는 의미는 아닙니다. 예를 들어 N+1 문제가 존재하더라도 특정 비즈니스 로직이나 데이터 처리 방식 때문에 의도적으로 유지되고 있을 수 있습니다. 마찬가지로 선형 탐색(O(n)) 역시 데이터 규모가 작다면 실제 성능에 미치는 영향이 거의 없을 수 있습니다.
결국 AI는 개발자를 대체하는 존재가 아니라, 더 빠르게 문제를 발견하고 해결할 수 있도록 돕는 강력한 도구에 가깝습니다. 중요한 것은 AI의 결과를 그대로 받아들이는 것이 아니라, 그 결과를 이해하고 검증할 수 있는 개발자의 판단입니다.
AI 활용 시 고려사항
물론 AI에도 한계는 있습니다. AI는 놀라운 수준의 코드 분석 능력을 보여주지만, 여전히 프로젝트의 비즈니스 맥락이나 의사결정 배경까지 완벽하게 이해하지는 못합니다. 따라서 AI가 제안하거나 수행한 모든 변경 사항은 반드시 경험 있는 개발자의 검토와 승인을 거쳐야 합니다.
실제로 이번 실험에서도 CodeCenter는 여러 개선 사항을 제안했습니다. 하지만 그중 일부는 성능 향상 효과가 미미해 본문에서는 제외했습니다. 만약 사용자가 AI가 수행하는 작업을 이해하지 못한 채 결과만 그대로 적용한다면, 최선의 경우에는 불필요한 토큰과 컴퓨팅 자원만 낭비하게 됩니다. 최악의 경우에는 새로운 버그가 발생하거나 서비스 장애로 이어질 수도 있습니다.
또한 AI가 기술적으로 올바른 개선 사항을 찾아냈다고 해서 그것이 항상 적용해야 할 변경 사항이라는 의미는 아닙니다. 예를 들어 N+1 문제가 존재하더라도 특정 비즈니스 로직이나 데이터 처리 방식 때문에 의도적으로 유지되고 있을 수 있습니다. 마찬가지로 선형 탐색(O(n)) 역시 데이터 규모가 작다면 실제 성능에 미치는 영향이 거의 없을 수 있습니다.
결국 AI는 개발자를 대체하는 존재가 아니라, 더 빠르게 문제를 발견하고 해결할 수 있도록 돕는 강력한 도구에 가깝습니다. 중요한 것은 AI의 결과를 그대로 받아들이는 것이 아니라, 그 결과를 이해하고 검증할 수 있는 개발자의 판단입니다.
마무리
이번 글에서는 CodeCenter와 같은 AI 기반 개발 도구가 애플리케이션 성능 분석과 최적화 과정에서 어떤 도움을 줄 수 있는지 살펴보았습니다. 비록 이번 실험은 데모 성격이 강한 오픈소스 프로젝트를 대상으로 진행되었지만, AI를 활용하는 방식 자체는 프로젝트 규모와 관계없이 크게 다르지 않습니다.
AI는 코드 이해, 디버깅, 성능 분석, 최적화 과정의 속도를 크게 높일 수 있습니다. 수천 개의 파일과 수십만 줄의 코드를 빠르게 분석하고 연관성을 파악하는 작업은 AI가 특히 강점을 보이는 영역입니다. 실제로 이번 실험에서도 이미 잘 관리되고 있는 프로젝트를 대상으로 약 12~19%의 성능 개선을 확인할 수 있었습니다.
만약 수년간 운영되며 수십만 라인의 코드와 대규모 데이터를 보유한 엔터프라이즈 시스템이라면 어떨까요? 코드 규모가 커질수록 분석해야 할 범위도 넓어지기 때문에 AI가 제공할 수 있는 생산성 향상과 최적화 효과는 더욱 커질 수 있습니다.
다만 AI는 어디까지나 도구라는 점을 잊어서는 안 됩니다. 최근의 에이전트 기반 개발 환경은 비교적 적은 경험을 가진 개발자도 다양한 작업을 수행할 수 있도록 지원하지만, 충분한 검증 없이 결과를 그대로 적용하는 것은 또 다른 문제를 만들 수 있습니다. 결국 AI의 가치는 자동화 자체가 아니라, 개발자의 판단과 결합될 때 가장 크게 발휘됩니다.
이번 글을 통해 AI 기반 개발 환경과 CodeCenter에 관심이 생기셨다면, 실제 개발 조직에서는 어떤 방식으로 활용할 수 있는지 직접 확인해 보시기 바랍니다. AI를 단순한 코드 생성 도구가 아니라 개발 프로세스 전반을 지원하는 파트너로 활용하는 방법은 생각보다 훨씬 다양합니다.
CodeCenter에 대해 더 자세한 정보가 필요하시거나 데모를 통해 직접 확인해보고 싶으시다면 언제든지 SLEXN에 문의해 주시기 바랍니다.
