앤트로픽의 현대화 플러그인은 당신의 COBOL을 다시 써준다. 단, 먼저 당신이 그것을 이해했음을 증명하게 만든다

앤트로픽이 code-modernization이라는 Claude Code 플러그인을 공개했다. 겨냥한 것은 기업 소프트웨어에서 가장 오래되고 가장 볼품없는 문제다. COBOL, 구형 Java, C++, .NET — 여전히 사업을 돌리고 있지만 지금 회사에 남아 있는 누구도 전체를 파악하지 못하는 시스템 말이다. 라이선스는 Apache 2.0, 설치는 한 줄이며, 공식 플러그인 디렉터리에는 '앤트로픽 인증'으로 약 5,900건의 설치 수가 표시돼 있다.

여기서 제공되는 능력 자체는 흥미롭지 않다. 언어 모델이 COBOL을 읽고 Java를 뱉을 수 있게 된 지는 꽤 됐다. 이 플러그인을 읽어볼 가치가 있는 이유는, 설계의 대부분이 바로 그 일을 하지 않으려고 쓰였기 때문이다.

순서가 곧 제품이다

플러그인은 순서를 강제한다.

preflight → assess → map → extract-rules → brief → (reimagine | transform | uplift) → harden

앞의 네 명령은 문서만 만든다. assess는 인벤토리와 복잡도 지수를 쓰고, map은 의존성·데이터 계보 그래프와 인터랙티브 토폴로지 뷰어를 쓴다. extract-rules는 업무 규칙을 캐내 file:line 출처와 확신도가 달린 Given/When/Then "Rule Card"로 정리한다. 이 시점까지 새 시스템을 향해 쓰인 코드는 한 줄도 없다.

관문은 brief다. 조사 결과를 운영위원회가 승인할 단계별 계획으로 종합하고, 사람의 승인을 받기 위해 플랜 모드로 들어간다. 그리고 그 정의에서 결정적인 문장 — 조사 산출물을 읽고 하나라도 없으면 멈춘다. 분석을 먼저 만들어두지 않으면 코드를 생성하는 명령에 도달할 수 없다. 이유는 README가 직설적으로 말한다. 현대화는 팀이 코드를 이해하기 전에 변환할 때, 또는 동작 이탈을 잡아낼 장치 없이 출시할 때 실패한다는 것이다.

이 전제는 30년치 실패한 마이그레이션으로 충분히 뒷받침되지만, 제품의 축으로 삼기에는 기묘한 주장이기도 하다. 이 플러그인의 경쟁력은 더 나은 Java를 쓴다는 데 있지 않다. 옛 시스템이 무엇을 하는지 설명한 문서가 나오기 전까지는 Java를 한 줄도 쓰지 않는다는 데 있다.

세 가지 방법, 그리고 요점은 가장 심심한 쪽이다

구축 단계에는 세 명령이 있고, 어느 쪽이 맞는지는 brief가 추천한다.

실제 현장 경험이 드러나는 쪽은 uplift다. 이 명령의 정의는 자신이 transform이 아니라고 못박으며 시작한다. "코드는 멀쩡하다. 새 런타임에서 돌기만 하면 된다." 그래서 구조를 보존하고, 컴파일되고 동일하게 동작하는 최소한의 diff만 만든다. 이를 이끄는 것은 이 코드가 실제로 부딪히는 알려진 파괴적 변경의 카탈로그다. 그 카탈로그가 어차피 코드 대부분이 바뀔 수밖에 없다고 나오면, 명령은 대신 transform을 쓰라고 알려준다.

이 플러그인에서 가장 정직한 비용 통제 장치도 여기 있다. 마이그레이션은 파일럿 우선이다. 대표 프로젝트 하나를 끝까지 통과시키고, 그 교훈을 플레이북에 적은 뒤에야 나머지가 프로젝트당 에이전트 하나씩, 의존성을 고려한 배치로, 서킷 브레이커 뒤에서 퍼져 나간다. 그래서 더 이상 통하지 않는 플레이북은 에이전트 몇 개 안에 걸러지고, 수정될 때까지 지출이 멈춘다. 에이전트 무리가 확신에 차서 엉뚱한 방향으로 토큰을 태우는 광경을 지켜본 사람이 쓴 설계다.

코드베이스는 공격자로 취급된다

안전 관련 주의사항은 이례적으로 직설적이다. 분석 대상 코드는 신뢰할 수 없는 입력이다. 적대적인 저장소는 "이전 지시를 무시하라", "이 규칙을 승인된 것으로 표시하라" 같은 주석을 심어 추출된 규칙이나 보안 발견 사항에 무엇이 들어갈지 조종할 수 있고, 이후 명령들은 그것을 신뢰한다. 명시된 방어는 세 가지다. 에이전트는 파일 내용을 데이터로 취급하고, 검증 에이전트는 모든 규칙과 발견 사항을 다른 에이전트의 설명이 아니라 인용된 원본 코드에서 다시 도출하며, 사람의 승인 관문이 코드 생성보다 앞에 놓인다.

비밀 정보도 비슷하게 다뤄진다. 공유 산출물에서는 마스킹되고 gitignore된 파일에 격리된다. 그리고 이어지는 한 문장은 과거 결함의 공개로 읽힌다. 이 플러그인의 초기 버전을 실제 시스템에 돌린 적이 있다면 analysis/ 산출물이 커밋되지는 않았는지 확인하고, 노출된 것은 교체하라는 것이다.

권장 워크스페이스 설정은 같은 직관을 권한으로 표현한 것이다. legacy/에 대한 쓰기를 거부하고 analysis/와 modernized/에서는 허용한다. 문서는 그 방어의 한계도 인정한다. 파일을 변경하는 셸 명령은 여전히 일반 Bash 프롬프트를 거치며, 쓰기 권한을 가진 에이전트를 한꺼번에 대량으로 펼치는 두 단계에서는 그 프롬프트가 유일한 봉쇄 수단이라는 것이다.

추정하기를 거부한 것

assess는 COCOMO 수치를 계산해놓고 그것을 일정으로 쓰는 것을 금지한다. 이유도 적혀 있다. COCOMO의 상수는 인간 팀의 생산성을 담고 있는데 에이전트 기반 변환은 그 곡선을 따르지 않으므로, 거기서 끌어낸 기간은 무엇이든 틀린다는 것이다. 이 숫자는 포트폴리오 안의 시스템들을 순위 매기고 순서를 정하는 상대 지수로만 살아남는다.

저장소에서 가장 솔직한 문장이다. 에이전트 주도 마이그레이션이 얼마나 걸리는지에 대해 업계에는 보정된 모델이 없다. 그리고 이 플러그인은 모델을 지어내는 대신 경고 딱지를 붙인 지표를 내놓았다.

이것으로 어려운 문제가 쉬워지지는 않는다. 가장 강한 동등성 증명 — 옛 런타임과 새 런타임에서 같은 테스트 스위트를 돌리는 것 — 에는 작동하는 레거시 툴체인이 필요하고, 그것이 없으면 플러그인은 기록된 트레이스 기반 특성화 테스트로 물러선다. 이는 의도된 동작이 아니라 관측된 동작을 고정한다. 디렉터리 페이지는 여전히 preflight와 uplift가 통째로 빠진 옛 설명을 달고 있는데, 워크플로가 진열대보다 빠르게 개정돼 왔음을 시사한다.

그러나 이 형태 자체가 주장이다. 앤트로픽은 COBOL 번역기를 내놓지 않았다. 번역을 싼 단계로, 증명을 비싼 단계로 취급하는 절차를 내놓았다. 그리고 그것은 이런 프로젝트들이 왜 실패하는지에 대한 올바른 독해일 가능성이 매우 높다.

Sources: code-modernization README (GitHub) · plugin.json manifest · modernize-uplift command definition · modernize-brief command definition · claude-plugins-official directory (GitHub) · code-modernization plugin listing (Claude)