AI가 15년의 역사를 가진 코드베이스를 이해할 수 있을까?

10년에서 15년 된 엔터프라이즈 시스템은 단순한 "오래된 코드"가 아닙니다. 그것은 수백만 줄의 코드, 수백 개의 테이블, 수십 개의 통합(integrations), 그리고 Confluence에 기록되지 않은 지식들이 모인 살아있는 유기체입니다. 새로운 개발자를 온보딩(Onboarding)하는 데는 몇 달이 걸리기도 합니다. 2026년의 질문은 이것입니다: 현대의 AI가 인간보다 더 빠르게 이러한 시스템을 파악할 수 있을까 — 그리고 그 한계는 어디까지인가?

요약하자면: AI는 검색, 의존성 맵(dependency maps), 초안 문서화(draft documentation)를 가속화하지만, 아키텍처적 판단(architectural judgment), 비즈니스 맥락(business context), 그리고 리스크 평가(risk assessment)는 여전히 전문가의 영역입니다.

핵심 요약 (Key takeaways)

레거시(Legacy)는 프레임워크의 연령이 아니라 축적된 복잡성입니다. 15년 된 프로젝트에는 여러 세대의 기술, 오래된 문서, 그리고 SQL 및 cron job에 내장된 비즈니스 로직이 쌓여 있습니다. 고통의 원인은 "Java 8"이 아니라, 필드 하나를 변경하는 것이 다섯 개의 통합(integrations)에 영향을 줄 수 있다는 점에 있습니다.

적절한 데이터 준비가 뒷받침된다면, AI는 인간이 몇 주 걸릴 일을 몇 시간 만에 해냅니다. 리포지토리 인덱싱(repo indexing), DB 스키마(DB schemas), git 히스토리(git history)가 없다면, 모델은 파편화된 정보만을 보게 되고 일반적인 패턴으로 빈틈을 채우려 할 것입니다. RAG, 시맨틱 검색(semantic search), 그리고 에이전트 도구(Cursor, Claude Code, Windsurf Deep Wiki)를 활용하면 훨씬 더 빠른 속도로 전체 그림을 그려낼 수 있습니다.

AI는 검색, 영향 분석(impact analysis), 그리고 문서화에 탁월합니다. 가격이 어떻게 계산되는지, 문서 승인이 어디서 일어나는지, 어떤 모듈이 orders_legacy를 읽는지와 같은 질문들은 리포지토리에 접근할 수 있다면 몇 분 안에 답을 얻을 수 있습니다.

AI는 "왜 이렇게 결정했는가"와 맹목적인 신뢰 문제에서 어려움을 겪습니다. AI는 2014년 회의에 참석하지 않았으며, 은행 계약 내용을 알지 못하고, 존재하지 않는 API를 자신 있게 설명할 수도 있습니다. 환각(Hallucinations)은 매우 그럴듯하게 들리기 때문에 위험합니다.

최적의 모델은 전문가 + AI입니다. 개발자나 아키텍트가 경계를 설정하고, 출력을 검증하며, 결정을 내립니다. 모델은 300만 줄의 코드를 읽어도 지치지 않는 분석가 역할을 수행합니다.

서론: 왜 레거시가 여전히 주요 고통인가

대부분의 기업은 5년마다 시스템을 재작성하지 않습니다. 대신 진화시킵니다: 새로운 모듈, 통합, 규제 변경 등이 추가됩니다. 리테일 ERP, B2B CRM, 코어 뱅킹, 정부 시스템 등은 수십 년 동안 운영됩니다. 다운타임 비용은 유지보수 비용의 1년보다 더 많이 발생합니다.

전형적인 성숙한 기업 프로젝트는 다음과 같습니다: 150만~400만 줄의 코드, 8천~1만 5천 개의 파일, 주 데이터베이스 및 보고 저장소에 있는 200~600개의 테이블, 그리고 20~40개의 외부 통합 (은행, 전자 송장 발행(e-invoicing), 마켓플레이스, ERP 브릿지, 메시지 버스). 팀은 5~10번 교체되었고, 일부 작성자는 연락이 불가능합니다.

온보딩 과정은

Confluence 페이지인 “Architecture v3”는 Kafka 마이그레이션 이전인 2019년의 것입니다. Swagger는 새로운 API만 다룹니다. 레거시(Legacy) 시스템은 한 통합업체만 알고 있는 스키마(Schema)를 통해 XML을 교환합니다. **실제 동작 (Actual behavior)**은 문서와 다릅니다. 설정 플래그(Config flag), 새벽 2시의 크론(Cron) 작업, 수동 운영 단계 등이 존재합니다.

일부 규칙은 오직 사람들의 머릿속에만 존재합니다: “월말 결산 전에는 이 테이블을 건드리지 마세요”, “이 엔드포인트(Endpoint)는 폐기(Deprecated)되었지만 은행은 여전히 호출합니다”와 같은 것들입니다. 이러한 규칙들은 git에 기록되는 경우가 거의 없습니다.

AI에게 문서는 여러 소스 중 하나일 뿐이며, 코드 교차 검증(Cross-check) 없이는 결코 신뢰할 수 없습니다. 긍정적인 측면은, 모델이 코드로부터 문서를 **생성(Generate)**하여 그 격차를 줄일 수 있다는 점입니다.

복잡한 비즈니스 프로세스 (Complex business processes)

ERP, CRM, 뱅킹 및 공공 부문 시스템은 단순한 CRUD 앱이 아닙니다. 승인, 한도, 세금 규칙, 문서 상태, 다단계 주문 등 **비즈니스 로직 (Business logic)**이 축적되어 있습니다. 여기서 버그는 단순한 UI 오류가 아닙니다. 그것은 과태료, 계좌 동결, 또는 규제 기관의 거절을 의미합니다.

높은 **오류 비용 (Cost of errors)**은 게임의 규칙을 바꿉니다: “AI를 통한 빠른 패치(Quick patch)”만으로는 충분하지 않습니다. 결과 분석(Consequence analysis)이 필요합니다. AI는 합계가 계산되는 **위치(Where)**를 찾아내고, 인간은 배포 전에 해당 공식이 변경될 수 있는지 **여부(Whether)**를 결정합니다.

현대적 AI 모델이 코드를 분석하는 방법

최근 몇 년간 변화된 점

세 가지 변화가 레거시 분석을 현실적으로 만들었습니다.

**컨텍스트 윈도우 (Context windows)**가 수천 토큰에서 수십만, 수백만 토큰으로 확장되었습니다. 여전히 전체 리포지토리(Repo)를 한 번에 로드할 수는 없지만, 하나의 모듈, DB 스키마, 또는 호출 체인(Call chain)은 한 세션에 담을 수 있습니다.

특화된 모델(Claude, GPT-4o, Gemini, Codestral 등)의 코드 이해 (Code understanding) 능력은 의존성(Dependencies)을 추적하고, SQL을 설명하며, DTO를 테이블에 매핑할 수 있을 정도로 강력합니다. 완벽하지는 않지만, 첫 번째 검토를 수행하는 숙련된 미드 레벨 개발자와 비교할 만한 수준입니다.

**리포지토리 도구 (Repository tools)**는 채팅 수준을 넘어섰습니다: Cursor와 Claude Code는 프로젝트를 인덱싱(Index)하고, 파일을 탐색하며, grep을 수행하고, git blame을 읽습니다. Windsurf Deep Wiki는 라이브 위키를 구축하며, 엔터프라이즈 RAG는 GitLab, Jira, Confluence를 연결합니다.

요약하자면: 병목 현상은 “모델이 Java를 이해하지 못한다”에서 “전체 코퍼스(Corpus)를 어떻게 입력할 것인가”로 이동했습니다.

AI가 분석할 수 있는 데이터

소스 (Source)	모델에게 제공하는 정보
소스 코드 (Source code)	로직 (Logic), 의존성 (Dependencies), API
...

하나의 인덱스(Index)와 RAG 파이프라인에 더 많은 소스가 연결될수록, 모델이 **지어내는 것 (invents)**이 줄어듭니다. DB 스키마(Schema) 없이 코드만 있는 것은 전형적인 실패 사례입니다. AI가 Order 엔티티(Entity)는 찾아내지만, PostgreSQL 트리거(Trigger)는 놓치게 됩니다.

AI가 프로젝트 맵을 구축하는 방법

전형적인 분석 파이프라인: 의존성 그래프 (Dependency graph) (import, 패키지 호출, HTTP 클라이언트); 모델, 테이블, REST 경로로부터 추출한 도메인 엔티티 (Domain entities) (주문, 거래 상대방, 배송); 클래스 및 큐(Queue) 체인으로서의 시나리오 (Scenarios) (“주문 생성 → 예약 → 결제 → 배송”); 통합 지점 (Integration points) (외부 URL, Kafka 토픽, SFTP 폴더).

에이전트(Agent)는 “리포지토리(Repo)를 암기”하는 것이 아니라, ripgrep과 IDE를 사용하는 시니어 개발자처럼 쿼리 (Queries) 합니다: “배송(shipments)에서 상태(status)가 업데이트되는 곳은 어디인가”, “LegacyBillingAdapter를 호출하는 곳은 누구인가”.

실험: AI에게 15년 된 프로젝트를 부여하기

아래는 실제 도매 ERP 패턴(모놀리스(Monolith) + 위성 서비스(Satellite services))을 기반으로 한 전형적인 시나리오 재구성입니다. 수치는 대표적인 예시이며, 귀하의 프로젝트와는 다를 수 있지만 규모(Orders of magnitude) 면에서는 익숙하게 느껴질 것입니다.

시작 조건

약 280만 라인의 Java, Kotlin, SQL, JavaScript, XML 설정 파일
메인 모노리포(Monorepo) 내 약 11,400개 파일 + 4개의 위성 리포지토리
Oracle (코어) 내 약 380개 테이블 + PostgreSQL (리포팅) 내 90개 테이블
34개 통합 지점: 은행, 전자 세금 계산서, 마켓플레이스, 회계 브릿지, SMS, 세관
문서화 (Documentation): 모듈의 약 40%가 최신 설명을 갖추지 못함; 위키(Wiki) 내용이 코드와 부분적으로 상충함

AI 설정: 리포지토리 인덱싱, DDL 덤프 접근 권한 (개인정보(PII) 제외), 읽기 전용 Git, IDE 에이전트. 운영(Prod) 로그 없음, 팀으로부터 전달받은 구전 전설(Oral legends) 없음.

AI가 처음 몇 시간 동안 이해하는 것

(연속된 실행이 아닌) 타겟팅된 세션을 4~8시간 동안 진행하면, 도구가 갖춰진 모델은 보통 다음과 같은 결과물을 만들어냅니다:

최상위 아키텍처 (Top-level architecture): 모놀리스 core-app, 분리된 출력 및 알림 서비스, 01:00~04:00 사이의 야간 배치(Batch), 주문 이벤트용 버스(Bus).

핵심 엔티티 (Core entities): counterparty, contract, order, shipment, invoice, payment — 패키지 및 테이블로 매핑됨.

주요 시나리오 (Key scenarios): 주문 생성 (order placement), 할인 승인 (discount approval), 창고 예약 (warehouse reservation), 인보이스 발행 (invoicing), 은행 계정 조정 (bank reconciliation) — REST, UI, 스케줄러 (scheduler) 진입점 포함.

통합 지점 (Integration points): 어댑터 목록 (adapter list), URL, 형식 (formats), 일반적인 장애 모드 (common failure modes) (은행 타임아웃, 큐 재시도).

이는 이러한 도구가 없는 새로운 시니어 개발자보다 더 빠릅니다. 인간은 어디를 살펴봐야 할지 탐색하고 추측하는 데 시간을 소비합니다.

인간이 여전히 몇 주 동안 공부해야 하는 것들

명확하지 않은 의존성 맵 (Non-obvious dependency maps): "discount_reason 필드가 Java에서 참조되지 않는 뷰 (view)를 통해 세금 라인에 영향을 미침."

비공식 규칙 (Informal rules): 계절적 절차, 주요 고객 예외 사항, 특정 지역의 임시 방편 (workaround).

품질 및 리스크 (Quality and risk): 테스트되지 않은 모듈, 최근 P1 장애 발생 영역, 야간 배치 (nightly batch) 실패 시 연락해야 할 사람.

변경 정책 (Change policy): 금요일 배포 규칙, DBA 작업 시간 (windows).

AI는 매핑의 초기 60~70%를 가속화하지만, 팀 간의 대화와 장애 대응 경험 (incident memory)을 대체하지는 못합니다. 좋은 AI 루프 (loop)를 활용하여 온보딩 기간을 "3개월"에서 "6주"로 단축하는 것은 현실적이지만, "1주일 만에 완전한 이해"를 달성하는 것은 불가능합니다.

요약하자면: 구조는 빠르게 파악되지만, 컨텍스트 (context)와 리스크 (risk)는 느리게 파악됩니다.

AI가 가장 뛰어난 성능을 발휘하는 영역

비즈니스 로직 찾기

"할인과 부가세(VAT)가 적용된 총액(line total)이 어디서 계산되는가?"와 같은 질문은 AI의 강점입니다. 에이전트는 PriceCalculator, 리포팅 SQL, 그리고 아무도 삭제하지 않은 중복된 레거시 메서드 (legacy method)를 찾아냅니다.

"문서 승인은 어디서 이루어지는가?" — 워크플로 엔진 (workflow engine) + approval_steps + 알림 (notifications).

"상태(status)가 어디서 변경되는가?" — enum 검색 (grep), 매퍼 (mapper) 업데이트, 이벤트 리스너 (event listener).

인간도 할 수 있지만, 인간은 며칠이 걸리는 반면 AI는 최신 인덱스 (index)를 통해 몇 분 만에 해냅니다.

변경 영향 분석 (Change impact analysis)

client_id를 리팩터링하거나 테이블을 삭제하기 전에 **영향 분석 (impact analysis)**이 필요합니다. AI는 JPA 엔티티 (entities), 리포트, 통합 DTO, 저장 프로시저 (stored procedures), 테스트를 나열합니다. 100% 보장되지는 않지만 (동적 SQL, 리플렉션 (reflection) 때문), 약 80%의 번거로운 작업을 제거해 줍니다.

특히 **DB 마이그레이션 (DB migrations)**이나 컬럼 타입 변경 전에 매우 가치가 높습니다.

문서 생성 (Documentation generation)

코드로부터 모듈 설명 (module descriptions), 누락된 OpenAPI, 컴포넌트 다이어그램 (component diagrams) (Mermaid, PlantUML), 엔티티 용어 사전 (entity glossaries) 등을 생성합니다. Windsurf Deep Wiki와 유사한 도구들은 이를 반자동으로 수행하며, 팀들은 실시간 레포지토리 문서를 AI의 초기 ROI (투자 대비 효과) 사례로 꼽습니다.

출력물을 **생성됨 (generated)**으로 표시하고 검토하십시오. 그렇지 않으면 위키는 단지 더 예뻐진 상태로 다시 괴리(drift)가 발생할 뿐입니다.

더 빠른 개발자 온보딩 (Faster developer onboarding)

신규 입사자는 RAG 채팅에 다음과 같이 질문합니다: "주문 취소는 어떻게 구현되어 있나요?", "왜 PaymentService가 두 개인가요?", "X 은행 연동 로그는 어디에 있나요?". 파일 링크와 함께 제공되는 답변은 **첫 커밋까지 걸리는 시간 (time-to-first-commit)**을 단축시킵니다.

이는 멘토를 대체하는 것이 아니라, 레포지토리를 헤매는 첫 몇 주간의 시간을 **압축 (compression)**해 주는 것입니다.

AI의 한계 (Limitations of AI)

컨텍스트 제한 (Context limits)

백만 개의 토큰이라 할지라도 **280만 줄의 코드 (2.8M lines)**를 대체할 수는 없습니다. 인덱싱 (indexing), 청킹 (chunking), 계층적 모듈 요약이 필요합니다. 이것이 없다면 모델은 코드의 일부 조각만을 보고 추론(extrapolate)하게 됩니다.

레거시 코드를 복사하여 붙여넣거나 **매직 스트링 (magic strings)**이 포함된 경우 노이즈가 추가되어, AI가 머릿속에서 유사한 두 클래스를 하나로 "병합"해 버릴 수도 있습니다.

비즈니스 컨텍스트 누락 (Missing business context)

코드는 **무엇(what)**을 하는지는 보여주지만, 왜(why) 그렇게 했는지는 거의 보여주지 않습니다. 2017년에 작성된 "임시" 은행 API 우회 코드는 아키텍트가 설명해주기 전까지는 무의미한 코드로 보일 뿐입니다.

역사적 제약 사항 (Historical constraints) (라이선스, 하드웨어, SLA 계약 등)은 git에 기록되어 있지 않습니다. ADR (Architecture Decision Records)이 존재한다면 도움이 되지만, 레거시 시스템에서는 없는 경우가 많습니다.

환각 및 오해 (Hallucinations and misinterpretation)

모델은 존재하지 않는 엔드포인트를 **자신 있게 인용 (confidently cite)**하거나, v1과 v2 API를 **혼동 (confuse)**하거나, 리플렉션 (reflection) 기반 호출을 놓치기도 (miss) 합니다. 답변이 구조적으로 잘 짜여 있기 때문에, 관리자 입장에서는 엔지니어보다 **맹목적 신뢰 (blind trust)**의 위험이 더 높습니다.

규칙: 운영 환경(prod) 결정을 위한 모든 AI 출력물은 파일/라인 참조나 테스트를 통해 **반드시 검증 (verify)**하십시오. 핵심 경로(critical paths)에 대해서는 대규모 AI 활용 팀들이 권장하는 대로, 다른 모델을 사용하거나 동료 검토 (peer review)를 거치십시오.

기업들이 레거시 시스템을 위해 AI를 배포하는 방법

레포지토리 인덱싱 (Repository indexing)

최소 코퍼스 (Minimum corpus): 코드 (SQL 및 인프라를 포함한 모든 운영 레포지토리), DB 스키마 (DB schema) (DDL, Flyway/Liquibase 마이그레이션), 문서 (docs) (Confluence 내보내기, ADR, README). 일 년에 한 번이 아니라, **main 브랜치로 머지 (merge to main)**될 때마다 다시 인덱싱하십시오.

Secrets: .env, 키(keys), 개인정보(PII)를 제외하고 인덱싱하십시오; 기업 정책(corporate policy)을 준수하십시오.

내부 지식 베이스 (Internal knowledge base)

의존성 그래프 (Dependency graph) (모듈, 서비스, 테이블) + 시맨틱 검색 (semantic search) (“신용 한도가 어디에 언급되어 있는가”). 도구: 엔터프라이즈 RAG (Azure AI Search, Elasticsearch + 임베딩 (embeddings), 온프레미스 스택 (on-prem stacks)), 프로젝트 인덱스를 갖춘 IDE 에이전트 (IDE agents).

위키(Wiki)는 **보조 계층 (secondary layer)**이 됩니다: 코드로부터 생성되고, 검토되며, 리포지토리(repo)와 함께 버전 관리됩니다.

RAG vs. 일반 채팅 (plain chat)

범용 ChatGPT는 사용자의 git을 볼 수 없습니다. RAG는 클래스, 마이그레이션(migration), 위키 페이지와 같은 **현재 청크 (current chunks)**를 검색합니다. RAG가 없다면 답변은 Stack Overflow 수준에 머물지만, RAG가 있다면 “당신의 InvoiceService.java 142번 라인에 있습니다”라고 답할 수 있습니다.

레거시(Legacy) 시스템에는 **정밀도와 인용 (precision and citations)**이 필요합니다. RAG + 에이전트 도구(agent tools)는 내부 시스템을 위한 2026년의 기본 사양(default)입니다.