제가 개발하고 있는 OSS인 "Shortcut Expert"에서는 AI 구동 개발(AI-driven development)을 채택하고 있습니다. 저는 구현하고 싶은 동작을 지정할 뿐, 내부 설계나 구현은 기본적으로 AI 에이전트에게 맡겨왔습니다.
처음에는 순조로웠지만, 기능을 추가할수록 기대하는 동작을 실현하기까지의 재작업(手戻り)이 늘어났습니다. 이전에는 12회의 수정으로 충분했던 것이 최근에는 56회 정도 수정을 반복해야 할 때도 있어, 토큰 소비 증가와 개발 속도 저하가 신경 쓰이기 시작했습니다.
원인을 조사하기 위해 코드를 확인한 결과, 설계상의 문제가 발견되었습니다.
Shortcut Expert에서는 키 조작이나 마우스 조작을 감지하는 로직이 복잡해지고, C#과 TypeScript의 책임 영역(責務)도 모호해졌습니다. 하나의 기능을 추가하기 위해서 많은 부분을 변경해야 하는 상태입니다.
이러한 설계상의 문제 역시 재작업 증가와 관련이 있을 것이라고 생각하여 현재 리팩토링을 진행하고 있습니다.
이 경험을 통해 아키텍처 설계나 코드 리뷰는 어느 정도 스스로 수행할 필요가 있다고 느꼈습니다.
동시에, 코드의 유지보수성이 악화되는 것을 더 이른 단계에서 감지할 수 없을까라는 생각을 하게 되었습니다.
그래서 이번에는 소프트웨어 메트릭스(Software Metrics)에 초점을 맞추어, 유지보수의 정의와 AI 개발 관련 연구를 조사한 후 어떤 지표를 측정해야 할지 고민해 보았습니다.
- AI 에이전트에게 구현을 맡기고 있는 분
- 코드의 유지보수성을 객관적으로 평가하고 싶은 분
- 소프트웨어 메트릭스에 흥미가 있는 분
소프트웨어 품질의 국제 표준인 ISO/IEC 25010:2023에서는 유지보수성(Maintainability)을 소프트웨어를 효과적이고 효율적으로 변경할 수 있는 능력으로 정의하고 있습니다.
유지보수성은 다음 5가지 관점으로 구성됩니다.
| 관점 | 의미 |
|---|
| 모듈성 | 일부의 변경이 다른 부분에 영향을 주기 어렵다 |
| ... | |
| 쉽게 말해, 미래 기능 추가나 수정 시 기존 기능을 망가뜨리지 않고 적은 노력으로 지속할 수 있는지를 의미합니다. | |
2025년~2026년에 발표된 연구들을 중심으로 AI 개발에서의 유지보수성 문제를 조사했습니다.
Speed at the Cost of Quality (MSR 2026)에서는 Cursor를 도입한 OSS 프로젝트와 유사한 비도입 프로젝트를 비교하고 있습니다.
그 결과, 개발 속도는 일시적으로 향상되었지만, 코드의 복잡도나 정적 분석 경고 수는 지속적으로 증가했습니다. 또한, 이러한 품질 지표의 악화가 이후 개발 속도 저하와 관련된다는 분석 결과였습니다.
단기적으로는 개발이 빨라져도 장기적으로는 유지보수 부담이 늘어날 가능성이 있다는 것입니다.
이는 제가 개인 개발에서 느꼈던 문제점과 상당히 유사한 결과였습니다.
Understanding the Code and Architectural Smells Generated by LLMs and Autonomous Agents (ASE 2026)에서는 AI가 생성한 코드에서도 코드의 비대화(肥大化)나 강한 결합(strong coupling) 같은 설계 문제가 발견되었습니다.
또한, CodeTaste (ICML 2026)에서는 구체적인 리팩토링 방법을 지시하면 비교적 잘 구현할 수 있는 반면, 적절한 개선 방침을 AI 스스로 판단하게 하는 것은 어렵다는 보고가 있습니다.
물론, 인간과 다른 설계를 선택했다고 해서 반드시 틀린 것은 아닙니다.
다만, AI가 올바르게 구현하는 것과 적절한 설계를 자율적으로 선택하는 것은 별개라고 생각합니다.
Is Agent Code Less Maintainable Than Human Code? (EMNLP 2026)에서는 인간이 작성한 코드와 AI가 작성한 코드를 각각 AI에게 추가 변경하게 하는 실험을 진행했습니다.
그 결과, AI가 작성한 코드를 수정할 경우 태스크 성공률(task success rate)이 최대 13.1%까지 하락하는 사례가 있었습니다.
더 흥미로운 점은 기존의 유지보수성 메트릭스만으로는 이 차이를 충분히 설명하기 어려웠다는 것입니다.
기존 지표만으로는 AI에게 있어 변경 용이성을 충분히 평가하지 못할 가능성이 있습니다.
Test Coverage Analysis of Agentic Pull Requests (ICSME 2026)에서는 AI 에이전트가 생성한 4,882건의 PR(Pull Request)을 분석했습니다.
테스트 대상 코드를 변경한 PR 중 테스트도 함께 변경한 것은 49.6%였습니다. 또한, 기존 테스트가 변경된 부분을 충분히 실행하지 못하는 경우도 보고되었습니다.
테스트를 추가하지 않았다는 것이 반드시 테스트 부족을 의미하는 것은 아닙니다. 다만, 테스트의 유무뿐만 아니라 변경된 부분을 충분히 검증하고 있는지도 중요해질 것 같습니다.
Echoes of AI(Empirical Software Engineering, 2026) 연구에 따르면, AI의 지원을 받아 작성된 코드와 사람이 직접 작성한 코드를 나중에 다른 사람이 수정했을 때, 수정 시간이나 코드 품질 면에서 통계적으로 유의미한 차이는 확인되지 않았습니다.
이 연구는 AI 지원 개발을 대상으로 하고 있으며, 이는 AI 에이전트에 의한 자율적인 개발과는 조건이 다릅니다. 현재로서는 AI가 작성한 코드가 반드시 유지보성이 낮다고 단정하기는 어려운 것 같습니다.
이번 연구를 정리해 보면, AI 개발에서는 다음과 같은 문제에 주의할 필요가 있는 것으로 보입니다.
| 문제 | 관련된 유지보성 |
|---|
| 코드의 복잡화 | 분석성・변경 용이성 |
| ... | |
이는 AI에게만 발생하는 문제는 아니지만, AI 주도의 개발에서도 주의해야 합니다. 특히 저의 개인 개발에서는 설계의 복잡화가 기능 추가의 부담과 관련되어 있다고 생각하기 때문에, 모듈성과 변경 용이성을 중시하고 싶습니다.
소프트웨어 메트릭스(Software Metrics)란 코드의 규모나 복잡도, 의존 관계 등을 수치화하는 지표입니다. 대표적인 것들로는 순환 복잡도(Cyclomatic Complexity)나 인지적 복잡도(Cognitive Complexity) 등이 있습니다.
다만, 메트릭스의 수치가 좋다고 해서 반드시 유지보성이 높다고 할 수는 없습니다. 반대로, 수치가 나쁘다고 해서 반드시 리팩토링이 필요하다고 단정할 수도 없습니다.
메트릭스는 유지보성에 문제가 있을지 모르는 코드를 발견하고, 리팩토링을 검토하기 위한 판단 자료라고 생각합니다.
ISO의 5가지 분류에 대응시키면 다음과 같은 지표들이 후보가 될 수 있습니다.
| 유지보성 | 메트릭스 | 발견하고자 하는 문제 |
|---|---|
| 모듈성 | 결합도・순환 의존(Cyclic Dependency)・의존 관계 전파 비용 | 변경 영향이 확산되기 쉬운 구조 |
| ... |
다만, 이 지표들이 각 관점을 직접 측정할 수 있는 것은 아닙니다. 예를 들어, 코드 중복률은 재사용성 자체를 나타내는 것이 아니며, 커버리지(Coverage)나 Mutation Score 역시 테스트의 용이성을 직접적으로 측정하는 지표는 아닙니다.
이는 어디까지나 유지보성과 관련된 문제를 발견하기 위한 지표입니다.
이번에 조사한 연구와 저의 개발 경험을 바탕으로, 다음 지표들을 우선순위로 수집하려고 합니다.
| 우선순위 | 메트릭스 | 목적 |
|---|---|
| 1 | 의존 관계・결합도 | 설계의 복잡화 발견 |
| 2 | 변경 빈도 × 복잡도 | 빈번하게 변경되는 복잡한 코드 발견 |
| 3 | 변경 지점 커버리지・Mutation Score | 변경 사항을 충분히 검증했는지 확인 |
| 4 | 인지적 복잡도・LOC(Lines of Code) | 극단적으로 복잡한 코드 발견 |
특히 주목하고 있는 것은 의존 관계와 결합도입니다. Shortcut Expert의 경우, 개별 처리뿐만 아니라 C#과 TypeScript의 책임이 모호해지고 변경 지점이 늘어나는 것이 문제였습니다. 따라서 함수 단위의 복잡도뿐만 아니라 모듈 간의 의존 관계도 확인하고 싶습니다.
또한, 변경 빈도와 복잡도의 조합은 리팩토링 후보를 찾는 '핫스팟 분석(Hotspot Analysis)'에 활용될 수 있습니다. 예를 들어, 빈번하게 변경되면서 동시에 복잡도 또한 높은 파일을 특정함으로써, 우선적으로 조사해야 할 코드를 좁힐 수 있습니다.
이번에는 AI가 구현한 코드의 유지보성을 평가하기 위해 어떤 메트릭스를 측정해야 하는지 알아보았습니다. AI 개발에서는 코드의 복잡화나 설계상의 문제, 후속 변경의 어려움 등에 주의할 필요가 있는 것 같습니다. 특히 저의 개인 개발에서는 모듈성과 변경 용이성을 중시하여 의존 관계나 변경 이력 등을 감시해 나가려고 합니다.
다음 시간에는 SonarQube 등 도구를 사용하여 이번에 선정한 메트릭스들을 실제로 도입해 보겠습니다.
