고고학자와 그의 조수: Malykhin이 Java 1.5로 LLM을 훈련시키다

Nik Malykhin은 현대 하드웨어에서 Java 1.5 기반을 실행해야 했습니다. 그의 LLM의 첫 번째 답변은 그럴듯했지만 저장소에 맞지 않았습니다. 해결책: 그의 말을 무조건 믿지 말고, 증거에 기반하도록 강제하는 것입니다.

간단히 말해

레거시 코드에LLM을 적용하면 듣기에는 옳아 보이는 답변이 나오지만 실제 프로젝트와 맞지 않을 수 있습니다. 효과적인 방법은 LLM이 기억이 아닌 코드, 테스트, 산출물 등 증거를 기반으로 작업하도록 강제하는 것입니다.

작업 중인 고고학자

Nik Malykhin은 2026년 7월 16일 martinfowler.com에서 Java 1.5에서 최신 환경으로 레거시 시스템을 현대화한 경험을 공유했습니다. 문제는 현대 도구들이 Java 1.5를 지원하지 않거나 거부한다는 점입니다. 그가 처음 시도한 방법은 LLM에게 직접 수정 사항을 요청하는 것이었는데, 그 결과는 Malykhin이 "plausible"하지만 "did not hold up in the codebase"하다고 묘사한 답변이었습니다. 즉, Java 1.5 코드로서는 그럴듯해 보였지만 실제 저장소와는 맞지 않았던 것입니다.

핵심은 방법론의 전환이었습니다. Malykhin은 LLM을 작성자로 사용하기보다 분석가와 검증자로 활용했습니다. 각 단계는 저장소에 기반을 두고 진행되었습니다: 기존 코드 읽기, 테스트와 실행 traces를 통한 가설 검증, 코드 자체로 증명할 수 있는 것보다 더 빠르게 진행하지 않기 등입니다. 이 글의 메시지는 단순합니다. 레거시 현대화에 LLM을 사용한다고 작업이 빨라지는 것은 아닙니다. 고고학자처럼 천천히 진행되지만, 증명 과정에서의 구멍은 줄어듭니다.

내부 메커니즘

이 패턴은 현대 에이전트 도구에서 evidence-first prompting, grounded reasoning, retrieval-first 등으로 불립니다. 핵심 규칙은 동일합니다: LLM의 모든 주장은 저장소의 산출물(파일, 줄, 테스트 등)에 근거해야 한다는 것입니다. 이 제약이 없다면 레거시 코드에서 LLM이 내놓는 가장 비용이 큰 "거짓 양성"이 발생합니다: 대상 버전보다 późniejszy APIs, 존재하지 않는 메서드, 잘못된 import 등이 그 예입니다.

결론

레거시 코드를 다루는 팀에게 "코파일럿"은 작성자가 아니라 발견자로 활용되어야 합니다. 진정한 생산성은 LLM이 읽게 하는 데서 오며, 추측하게 두지 않는 것입니다. CTO를 위한 교훈: AI가 지원하는 현대화 프로젝트의 올바른 측정 지표는 "생성된 줄 수"가 아니라 "코드 자체에 의해 반증된 가설"이어야 합니다. 두 지표의 차이는 성공하는 레거시 프로젝트와 다시 부채로 돌아가는 프로젝트의 차이입니다.