생성형 AI가 레거시 리팩토링에서 잘하는 것, 못하는 것

“AI가 다 해준다”는 말은 정확하지 않습니다. AI가 잘하는 영역과 사람이 검증해야 하는 영역이 명확히 갈립니다.

현재 LLM 기반 코딩 도구의 강점과 한계를 솔직하게 정리하면 다음과 같습니다.

요약하면, 생성형 AI는 “개발자 한 명을 대체하는 도구”가 아니라 “개발자 한 명의 처리량을 늘려주는 도구”입니다. 사람이 의사결정을 하고, AI가 기계적 반복을 처리하는 분업이 현재 가장 안정적인 패턴입니다.

전통 방식 vs 생성형 AI 방식 — 어디서 차이가 나는가

실제 차이가 가장 크게 나는 영역은 코드 분석과 테스트 생성 단계입니다.

위 효과는 코드 품질·언어·도메인에 따라 편차가 크며, 같은 도구라도 프로젝트 특성에 따라 결과가 달라집니다. 도입 전에 작은 모듈로 PoC를 진행해 자사 환경의 실제 효과를 측정하는 것이 권장됩니다.

실무 4단계 가이드 — 무엇을, 어떤 도구로

한 번에 전체를 바꾸지 않습니다. 작은 모듈부터 단계적으로 진행하는 것이 정석입니다.

1단계 — 분석·문서화

전체 코드베이스를 Claude Code, GitHub Copilot, Cursor 같은 도구에 올리고 “전체 구조, 데드코드, 순환 의존성”을 요약시킵니다. 사람이 단번에 파악하기 어려운 거대 코드베이스의 지도를 30분~수시간 안에 그릴 수 있습니다. 결과는 반드시 사람이 1차 검수해야 하며, AI가 추측한 부분과 코드에서 실제로 확인된 부분을 구분해 표기하는 것이 좋습니다.

2단계 — 점진적 리팩토링

모듈·함수 단위로 IDE에서 “이 함수를 SOLID 원칙으로 리팩토링”을 요청하고, diff를 사람이 검토·승인합니다. 한 번에 1,000줄을 통째로 바꾸기보다 100~200줄 단위로 끊어가는 것이 안전합니다. 비즈니스 로직 변경은 AI에 위임하지 않고 사람이 결정합니다.

3단계 — 검증·테스트

AI가 생성한 단위 테스트와 Playwright·Cypress 같은 E2E 테스트를 결합해 회귀 검증을 수행합니다. SonarQube로 코드 냄새를 자동 점검하고, 보안 측면은 OWASP ASVS 5.0과 OWASP AISVS(AI Security Verification Standard, 2025년 1.0 공개) 기준에 맞춰 별도 스캔을 거치는 것이 좋습니다. AI 생성 코드의 환각(존재하지 않는 라이브러리 호출 등)을 잡아내는 단계가 여기입니다.

4단계 — 배포·모니터링

GitHub Actions·GitLab CI에 AI 코드 리뷰 봇을 통합하고, 블루-그린 또는 카나리 배포로 점진 전환합니다. 운영 중 성능·에러를 New Relic·Datadog 같은 APM 도구로 모니터링하면서, 문제 발생 시 즉시 롤백할 수 있는 체계를 갖춥니다.

레거시 AI 리팩토링 자주 묻는 질문

실무에서 가장 자주 받는 질문 세 가지를 정리합니다.

기존 시스템에 AI를 적용할 때 어디서부터 시작해야 하는가

비즈니스 로직 수정보다 리버스 엔지니어링과 단위 테스트 자동 생성부터 시작하는 것이 안전합니다. 기존 코드의 동작 방식을 AI가 분석해 문서·테스트로 바꿔주면, 그 자체가 향후 리팩토링의 안전망이 됩니다. RAG 기반 코드 분석 에이전트로 기술 부채 점수를 먼저 측정한 뒤, 효과가 입증된 비핵심 모듈부터 단계적으로 진행하는 전략이 일반적입니다.

AI가 생성한 코드를 어떻게 검증해야 안전한가

EU AI Act는 2024년 8월 1일 발효되어 단계적으로 적용되며, 고위험 AI 시스템에 대한 의무는 2026년 8월 2일부터 본격 적용됩니다(고용·신용·교육·법 집행 등 부속서 III 영역). EU 시장에 진출하는 기업이라면 채용·평가 자동화 같은 영역에서 사람의 100% 검수와 AI 레드팀 교차 검증을 결합한 하이브리드 거버넌스가 필요합니다. 일반 코드 영역에서도 OWASP ASVS 5.0과 AISVS 기준으로 보안 취약점을 자동 스캔하고, AI 생성 코드의 환각을 정기적으로 점검하는 절차를 두는 것이 권장됩니다. “환각률 0%”는 현재 LLM에서 보장되지 않으므로, 0이 아니라 “충분히 낮게 유지”가 현실적인 목표입니다.

프롬프트와 로컬 환경을 최적화하면 어떤 효과가 있는가

사내 프레임워크 규칙·아키텍처 가이드라인을 RAG로 주입하면 코드 일관성이 크게 올라갑니다. 보안이 중요한 핵심 자산은 Llama 4·DeepSeek-V3 같은 오픈소스 모델을 Ollama·vLLM 환경에서 로컬 구동해 코드 데이터가 외부로 나가지 않도록 차단할 수 있습니다. 다만 로컬 모델은 GPU·운영 비용이 발생하므로, 민감도에 따라 클라우드 API와 로컬 모델을 섞어 쓰는 하이브리드 전략이 일반적입니다.

도입 전에 한 번 더 점검할 것

마지막으로, 생성형 AI 리팩토링을 도입하기 전에 점검해야 할 세 가지가 있습니다. 첫째, 대상 시스템의 코드 품질이 AI가 다룰 수 있는 수준인가입니다. 주석이 거의 없고 함수가 수천 줄이며 도메인 용어가 한국어 약어로 박혀 있는 코드는 AI도 어려워합니다. 이 경우 사람이 1차로 정리한 뒤 AI에 넘기는 것이 효율적입니다.

둘째, 코드와 데이터가 외부 API로 나가도 되는가입니다. 금융·헬스케어·국방 등 규제 영역은 코드 자체가 자산이라 외부 LLM API 사용이 제한될 수 있습니다. 이 경우 처음부터 로컬 모델을 전제로 설계해야 합니다.

셋째, 리팩토링 후 운영·테스트 인프라가 받쳐주는가입니다. 코드를 빠르게 바꿔도 CI/CD·테스트 자동화가 부실하면 운영 사고로 이어집니다. AI 도입 효과를 보려면 자동화 인프라가 함께 성숙해야 합니다.

참고 자료

• EU AI Act 공식: AI Act — Shaping Europe’s digital future (2024.8 발효, 2026.8 고위험 적용)
• EU AI Act Implementation Timeline: 단계별 적용 일정
• OWASP AISVS: AI Security Verification Standard (2025년 1.0 공개)
• McKinsey QuantumBlack: Overcoming legacy tech through agentic AI — LegacyX 플랫폼 사례
• GitHub Copilot: GitHub Blog — 코드 자동화·리팩토링 가이드
• AImatters.co.kr: 코드 한 줄당 44만원 손실 — 생성형 AI가 레거시 앱 비용 잡는다

바이브 코딩이란 무엇인가 — ‘어떻게’에서 ‘무엇을’로

2025년 초 Andrej Karpathy가 던진 한 마디에서 시작된 흐름입니다.

‘바이브 코딩’은 개발자가 코드를 한 줄씩 직접 쓰는 대신, AI 에이전트에게 의도를 설명하고 결과물을 검토·수정하는 방식의 작업 패턴을 가리킵니다. 과거의 개발자가 “어떻게(How) 코드를 짤 것인가”에 집중했다면, 2026년의 엔지니어는 “어떤 가치(What)를 구현할 것인가”를 정의하는 데 더 많은 시간을 씁니다. Andrej Karpathy는 자신의 코드 약 80%가 이미 에이전트가 작성한 것이라고 언급했고, 이 발언이 ‘에이전틱 엔지니어링(agentic engineering)’이라는 프레임을 대중화시켰습니다.

다만 바이브 코딩이 만능은 아닙니다. 신경과학자 Russ Poldrack이 지적했듯, AI가 생성한 코드는 통계적으로 “더러운(dirty)” 경향이 있습니다. 불필요한 반복문, 타입 체크는 통과하지만 개념적으로 잘못된 로직 같은 오류가 섞여 있습니다. “구문 오류”의 시대는 지나갔지만, 대신 “의도 불일치”와 “개념적 오류”라는 새로운 버그 분류가 등장했습니다. SonarSource의 2026년 벤치마크에서 Claude Opus 4.5 Thinking이 실제 엔지니어링 과제의 83.6%를 해결했지만, 풀지 못한 16%는 정확히 “사람이 리뷰하면 잡지만 AI가 놓치는 종류”의 미묘한 버그였습니다. 사람이 의사결정과 검토를 맡는 분업 구조가 여전히 핵심입니다.

Claude Code가 만든 변화 — CLI를 넘어 에이전트 플랫폼으로

2024년 출시된 Claude Code는 2026년 들어 단순 코드 어시스턴트를 넘어 에이전트 오케스트레이션 플랫폼으로 진화했습니다.

현재 Claude Code의 핵심 기능은 다음 다섯 가지로 정리됩니다.

Anthropic이 2026년 자체 발표한 ‘Agentic Coding Trends Report’에 따르면, 구조화된 CLAUDE.md 설정과 서브에이전트 워크플로를 사용하는 팀이 일반 Claude Code 사용 대비 2~4배의 속도 향상을 보고했습니다. “10배 생산성”이 아니라 “2~4배”라는 점이 중요합니다 — 환각이 아닌 실제 측정값에 기반한 수치입니다.

실무 사례 — 어디까지 자동화되고 있는가

자율성의 정도는 작업 종류에 따라 다릅니다.

현재 Claude Code 등 AI 코딩 도구가 실무에서 처리하는 영역을 자율성 정도로 정리하면 다음과 같습니다.

위 효과는 코드 품질·도메인·팀 역량에 따라 큰 편차를 보입니다. 같은 도구라도 프로젝트 특성에 따라 결과가 달라지므로, 도입 전 작은 모듈로 PoC를 진행해 자사 환경의 실효성을 측정하는 것이 권장됩니다.

엔터프라이즈 도입 시 점검할 세 가지

기술의 화려함보다 비즈니스 결과가 중요합니다.

리더 입장에서 Claude Code·바이브 코딩 도입을 검토한다면 다음 세 가지를 먼저 점검하는 것이 좋습니다.

첫째, 자사 코드와 데이터의 외부 API 노출 가능 여부입니다. 클라우드 LLM API 사용이 규제·보안상 제한되는 영역(금융·헬스케어·국방)에서는 처음부터 로컬 모델 또는 사설 클라우드 배포를 전제로 설계해야 합니다. Anthropic은 AWS Bedrock·GCP Vertex AI를 통한 엔터프라이즈 배포를 지원합니다.

둘째, 코드 품질·보안 검증 체계입니다. AI가 생성한 코드는 통계적으로 더러운 경향이 있으므로, SonarQube 같은 정적 분석, OWASP ASVS·AISVS 기반 보안 스캔, 사람의 PR 리뷰가 결합된 다층 방어 체계가 필요합니다. “AI가 짠 코드니까 신뢰할 수 있다”는 가정은 위험합니다.

셋째, 온보딩과 지식 자산화입니다. CLAUDE.md·Skills·서브에이전트 정의는 그 자체로 팀의 개발 표준 문서가 됩니다. 신규 개발자가 합류했을 때 이 파일들이 곧 가이드 역할을 하므로, 잘 관리된 .claude 디렉터리는 기존의 위키·온보딩 문서보다 훨씬 실용적인 자산입니다.

AI 시대, 개발자의 새로운 역할

2026년은 코드 생성의 패러다임이 본격적으로 바뀌는 분기점입니다. AI가 단순 반복 작업을 넘어 일정 수준의 로직 구현까지 처리하면서, 개발자의 역할은 코드 작성자에서 AI 협업자·시스템 설계자로 진화하고 있습니다. 이제 중요한 역량은 프롬프트 설계, 생성된 코드의 품질 검증, 그리고 AI가 접근하기 어려운 도메인 지식·창의적 문제 해결 능력입니다.

도구는 변해도 본질은 남습니다. AI가 아무리 발전해도 비즈니스 맥락을 이해하고, 사용자 관점에서 문제를 정의하며, 팀과 소통하는 능력은 여전히 사람의 몫입니다. AI 시대의 개발자는 기술과 비즈니스를 잇는 통역자가 되어야 합니다.

지금 익숙해진 개발 방식은 2년 후 다시 한 번 크게 바뀌어 있을 가능성이 큽니다. 변화 속도에 압도되기보다는, 그 변화 안에서 자신만의 가치를 찾아가는 과정이 필요한 시점입니다. Claude Code는 도구일 뿐, 결국 무엇을 만들지는 사람이 정합니다.

참고 자료

• Claude Code 공식 문서: Claude Code Overview — Anthropic
• Claude Code Changelog: code.claude.com — 최신 업데이트 이력
• Model Context Protocol: MCP 공식 — AI 에이전트와 도구 간 표준 프로토콜
• Anthropic News: Anthropic News — Claude 모델 업데이트와 벤치마크
• Claude Code Best Practices: Claude Code 베스트 프랙티스 — 바이브 코딩에서 에이전틱 엔지니어링까지
• Spring Boot 4.0: Spring Boot 공식 — 4.0 릴리스 정보