AI 기반 코드 현대화 프로젝트를 준비하는 방법

Anthropic의 현장 노트(Notes from the Field) 시리즈에서는 고객의 실제 도입 사례에서 얻은 모범 사례를 현장 배치 엔지니어들이 공유합니다. 이 글에서는 대규모 코드 현대화 프로젝트를 관리하면서 얻은 경험을 소개합니다.

과거에는 조직 전체가 수년에 걸쳐 수행해야 할 것으로 여겨졌던 코드 현대화 작업을 이제는 몇 달, 또는 몇 주 만에 완료할 수 있습니다. 그러나 이러한 현대화 작업 전후에 필요한 조직 차원의 업무는 대체로 달라지지 않았습니다.

예를 들어, 핵심 은행 시스템을 변경하려면 변경 관리, 검토, 승인 절차를 거쳐야 합니다. 규제 기관과 감사원, 기업의 요구 사항을 충족해야 하므로 이러한 절차는 엄격하게 운영됩니다.

이러한 프로세스는 핵심 시스템의 신뢰성을 보장하는 기반이며, 각각의 변경 사항을 사람이 작성하고 변경된 코드의 차이점(diff)을 사람이 검토한다는 전제하에 구축되었습니다. 에이전트가 변경 사항의 작성 속도를 높이면서 병목 현상은 변경 사항을 생성하는 작업에서 이를 처리하기 위해 조직 전체를 움직이는 작업으로 옮겨갑니다.

이 글에서는 현대화 작업을 시작하기 전에 기업이 수행해야 할 업무를 다룹니다. 완료의 의미를 정의하고, 변경 사항마다 어떤 증거 자료를 갖춰야 하는지, 인증을 거친 변경 사항을 프로덕션 환경에 어떻게 반영할지, 현대화 작업을 시작하기 전에 무엇을 미리 준비해야 하는지 살펴봅니다.

이 프로세스는 다음 6단계로 진행됩니다.

1. 목표 정의: 현대화된 코드가 갖춰야 할 기술 스택과 동작을 정의합니다.
2. 인증 기준 마련: 변경된 코드가 목표 상태에서 올바르게 작동한다고 인정받기 위해 충족해야 할 조건을 설정합니다.
3. 프로덕션 반영 정책 수립: 인증된 코드 변경 사항을 생성되는 속도에 맞춰 실제 운영 환경으로 배포할 수 있는 절차를 정의합니다.
4. 사전 준비 사항 마련: 환경, CI/CD, 검토 역량, 승인 절차를 마련합니다.
5. 에이전틱 워크플로우 구축 및 개선: 코드 현대화 작업을 여러 개의 소규모 병렬 서브에이전트 작업 흐름으로 분산하여 변경 사항을 생성하는 맞춤형 Claude Code 동적 워크플로우를 구축하고 개선합니다. 이 워크플로우는 목표 설정, 인증 및 프로덕션 반영 정책을 중심으로 이루어집니다.
6. 현대화 실행: 코드베이스의 일부 작은 영역에서 워크플로우의 전체 실행 과정을 검증한 뒤, 작업 규모를 확장합니다.

1단계: 목표 정의

목표는 현대화 작업을 통해 도달하고자 하는 최종 상태입니다. 원하는 최종 상태에 따라 어떤 유형의 현대화 작업을 수행할지가 결정되며, 현대화는 아래 표에 설명된 세 가지 유형으로 구분됩니다.

현대화 유형 결정

어떤 방식으로 현대화를 추진할지를 두고 조직 내부에서 의견이 엇갈리는 경우가 많습니다. 경험상, 프로덕션 환경과 가장 밀접하게 일하는 사람들은 위험을 최소화하기 위해 기존 시스템의 동작은 유지하면서 기술 스택만 교체하는 방식을 선호합니다(변환형 현대화). 반면, 기존 코드베이스를 오랫동안 다뤄 온 엔지니어들은 현대화로 기술 부채를 줄이길 원하며, 다른 비즈니스 이해관계자들은 이 기회를 활용해 새로운 요구 사항까지 정의하기를 원합니다(재구상형 현대화).

두 입장 모두 합리적이지만, 이 문제를 해결하지 않고 넘어가면 나중에 특정 변경 사항이 '올바른' 것인지 여부에 대한 논쟁이 반복될 수 있습니다. 어떤 접근 방식을 선택할지 합의를 이루는 과정에서 초기에는 어려움이 따를 수 있지만, 프로젝트 전체를 더 원활하게 진행할 수 있습니다.

코드베이스 매핑 및 동작 명세서 작성

현대화 목표를 정의하려면 먼저 현재 시스템을 이해하는 것이 좋습니다. 기존 코드가 실제로 수행하는 작업을 파악하고 현재 동작을 목록으로 작성하면 어떤 구성 요소를 변경하거나 제거할지 쉽게 결정할 수 있습니다. 그리고 이를 통해 현대화 작업이 변환형인지, 재구상형인지 판단할 수도 있습니다. 또한 이 과정에서 그동안 알려지지 않았던 비즈니스 로직과 예외 상황이 드러나는 경우도 많습니다.

Claude는 의존성을 매핑하고, 아무도 구축 과정을 기억하지 못하는 워크플로우를 문서화함으로써 이러한 탐색 작업의 상당 부분을 수행할 수 있습니다. 코드 현대화 플러그인의 assess, map, extract-rules 명령어는 소스 코드 인용 정보를 포함한 비즈니스 규칙을 추출하며, 엔지니어가 이를 검토할 수 있습니다.

하지만 Claude의 탐색 작업만으로는 레거시 시스템의 동작 방식을 완전히 파악하지 못할 수 있습니다. 비즈니스 사용자 및 개발자와의 인터뷰, 내부 문서를 통해 부족한 정보를 보완할 수 있습니다. 초기에는 이러한 맥락 정보를 수집하는 데 시간이 걸릴 수 있지만, 수집한 맥락의 품질은 이후 워크플로우의 모든 의사 결정에 영향을 미칩니다.

재구상형 현대화에서는 목표를 정의하려면 추가 작업이 필요합니다. 상세한 동작 명세서를 작성하고 사용자 그룹과 합의해야 합니다.

프로젝트의 타당성과 목표 설정

조직은 목표를 정의하는 것과 함께, 왜 현대화 작업을 추진할 가치가 있는지도 고려해야 합니다. 레거시 시스템을 현대화하면 지속적으로 발생하는 유지보수 및 운영 비용을 줄일 수 있지만, 경험상 대부분의 현대화 프로젝트에서는 비용 절감이 주된 목표는 아니었습니다.

예를 들어, 패치되지 않은 취약점이 남아 있는 시스템은 사이버 침해 사고나 비즈니스 자체를 위협할 정도로 심각한 서비스 중단을 초래할 수 있습니다. 런타임에 대한 지원이 중단되거나 시스템을 이해하는 엔지니어가 점점 줄어들면 이러한 위험은 더욱 커집니다.

Claude Code와 같은 에이전틱 코딩 도구는 현대화에 걸리는 시간을 단축했지만, 여전히 예산을 산정하기 어려워 프로젝트 추진이 지연되는 경우가 많습니다. 저희는 일부 대규모 현대화 프로젝트의 비용을 공개했으며, 다른 기업들도 관련 비용을 공개했습니다. 이러한 수치는 대략적인 예산 기준으로 사용할 수 있습니다. 이 가이드의 마지막 부분에는 예산 추정에 필요한 추가 지침을 제공합니다.

이러한 프로젝트를 시작할 때 가장 큰 과제는 일반적으로 시스템을 소유한 팀과 해당 시스템에 의존하는 팀으로부터 내부적인 합의와 적극적인 참여 의지를 이끌어 내는 것입니다. 경영진을 중심으로 프로젝트의 사업적 타당성을 확립하고 목표를 명확히 설정하면 이러한 과정을 더 원활하게 진행할 수 있습니다. 이는 후속 단계에서 인증 기준과 프로덕션 반영 정책에 관한 상충하는 요구 사항을 조율할 때도 판단의 기준이 됩니다. 이해관계자들이 변경 사항에 허용할 수 있는 위험 수준을 두고 의견이 엇갈릴 때는 현대화를 추진하지 않을 경우 발생할 수 있는 위험도 함께 고려해야 합니다.

2단계: 인증 기준 정의

인증 기준은 모든 현대화 변경 사항이 충족해야 하는 일련의 조건이나 테스트 집합입니다. 변경 사항이 목표 상태에 부합하며 올바르게 구현되었다는 사실을 가장 강력하게 입증할 수 있도록, 종합적인 증거를 제공하는 조건을 선택해야 합니다.

모든 조건은 사람의 개입 없이 확인할 수 있어야 합니다. 그래야 에이전틱 워크플로우가 인증 기준을 충족할 때까지 변경 사항을 반복적으로 개선하고, 충족할 수 없는 경우에는 사람의 검토 대상으로 지정할 수 있습니다.

인증 기준에 포함되는 항목은 현대화 목표에 따라 다르지만, 일반적으로 다음과 같은 조건을 적용합니다.

• 기존 테스트 스위트가 통과해야 합니다.
• 현대화 과정에서 Claude가 작성한 모든 테스트가 통과해야 합니다.
• 테스트 범위가 합의된 임계값을 충족해야 합니다.
• 성능 벤치마크는 합의된 범위 내에 유지되어야 합니다.
• Claude가 매번 새로운 컨텍스트 창에서 독립적으로 수행한 적대적 검토에서 작업을 차단할 만한 문제가 발견되지 않아야 합니다.
• UI의 경우, Claude의 컴퓨터 사용 기능을 통한 검증에서 회귀 문제가 발견되지 않아야 합니다.
• 현재 버전과 목표 버전에 동일한 입력을 제공했을 때 동일한 출력이 생성되어야 합니다. 입력은 실시간 데이터, 기록된 데이터 또는 Claude가 생성한 데이터일 수 있습니다.
• 영구 저장된 상태와 통신 데이터 형식이 현재 버전과 목표 버전 간에 왕복 변환해도 정상적으로 유지되어야 합니다.
• 변경 사항을 스테이징 환경에서 합의된 기간 동안 실행해도 오류율, 지연 시간, 알림에 회귀 문제가 없어야 합니다.
• 정적 분석 및 보안 검사에서 새로운 문제가 발견되지 않아야 합니다.
• 컴파일 대상의 경우, 빌드가 오류 없이 완료되고 타입 검사도 통과해야 합니다.

이들의 전문 지식은 인증 기준에서 무엇을 검증할지 결정하는 데 영향을 미치며, 초기 단계부터 이들을 참여시키는 것은 변경 사항이 검토 단계에 도달했을 때 이들의 동의와 지지를 얻는 데 중요한 역할을 합니다. 완성된 인증 기준이 적절한지 판단하려면 담당자들이 인증 기준에서 제공하는 증거만으로 안심하고 변경 사항을 병합할 수 있는지 살펴보는 것이 좋습니다. 인증 기준에 자신들이 요구하는 수준이 반영되어 있다고 판단하면 3단계의 프로덕션 반영 정책을 간소화할 수 있습니다.

인증 기준에서 무엇을 대상으로 어떤 방식으로 검증하는지는 현대화 유형에 따라 달라집니다.

• 업리프트형 현대화(Uplift modernization): 기존 코드베이스와의 동작 일치 여부를 검증하며, 기존 테스트 스위트를 인증 기준의 핵심으로 사용할 수 있습니다.
• 변환형 현대화(Transform modernization): 이 유형 역시 기존 코드베이스와의 동작 일치 여부를 검증하지만, 기존 테스트 스위트는 새로운 기술 스택에서 실행되지 않는 경우가 많습니다. 대신 프로덕션 트래픽 재생, 기존 시스템과 신규 시스템 간의 차등 테스트 수행, 프로덕션 환경에서 병렬 배포가 검증 작업의 대부분을 담당합니다.
• 재구상형 현대화(Reimagine modernization): 인증 기준은 동작 명세서를 기반으로 수립하며, 세 가지 유형 중 가장 까다로운 경우입니다. 명세서는 비교 대상이 되는 기존 시스템보다 객관성이 떨어지므로 모델의 판단이 더 많이 개입하게 되고, 그에 따라 결과에도 더 많은 변동이 발생할 수 있습니다. 따라서 인증 기준은 명세서를 바탕으로 작성한 테스트, 각 변경 사항을 명세서와 대조하는 Claude의 독립적인 적대적 검토, 신규 시스템이 기존 시스템의 동작을 유지하는 부분에 대한 차등 검증에 주로 의존합니다. 명세서가 명확해짐에 따라 인증 기준도 수정해야 할 것으로 예상해야 합니다. 명세서에서 누락된 부분이 이 단계에서 가장 먼저 드러나기 때문입니다.

구형 시스템은 테스트 커버리지가 좁고, 테스트가 불안정하며, 텔레메트리 데이터가 부족한 경우가 많습니다. 인증 기준을 정의할 때는 이렇게 부족한 부분을 파악하는 작업도 포함됩니다. 신뢰도 높은 인증 기준을 마련하기 어렵다면, 이 단계에서 가장 유용한 방법 중 하나는 Claude를 활용해 부족한 검증 근거를 확보하는 것입니다. 프로덕션 병렬 환경을 구축하고, 트래픽 재생 하네스를 만들거나, 테스트를 추가로 작성하는 등의 방법이 있습니다.

3단계: 프로덕션 반영 정책 수립

에이전트는 인간으로 구성된 어떤 팀보다도 훨씬 빠른 속도로 변경 사항을 생성하므로, 모든 변경 내역을 일일이 검토하기는 어렵습니다. 프로덕션 반영 정책은 변경 사항에 필요한 사람의 검토 수준을 정하는 단계별 검토 절차로, 사전에 문서화하고 합의해야 합니다. 이를 통해 현대화 작업을 허용 가능한 일정 내에 완료할 수 있습니다.

인증 기준과 마찬가지로 이 단계도 검토자들과 함께 진행하고, 가능한 경우 조직의 기존 변경 관리 프로세스에 통합해야 합니다. 구체적인 방식은 조직과 해당 조직이 직면한 위험 사이의 절충점에 따라 달라지지만, 어디에서나 적용되는 몇 가지 원칙이 있습니다.

• 영향 범위와 에이전트 확신 수준에 따라 검토 수준을 구분하세요. 조직에 자체적인 변경 사항이나 위험 분류 체계가 있다면, 이를 사용하세요. 핵심 경로에 대한 변경 사항은 사람이 모든 사항을 전면적으로 검토하는 절차를 유지해야 합니다.
• 반복적으로 표시되는 문제는 근본 원인을 해결하세요. 시간이 지남에 따라 검토 대상으로 표시된 변경 사항을 그룹화하고 분석하세요. 동일한 유형의 문제가 반복되는 경우, 개별적으로 검토하기보다는 에이전틱 워크플로우나 인증 기준에서 근본 원인을 해결해야 합니다.
• 검토자와 함께 결과물 형식을 설계하세요. 검토를 가장 빠르게 진행하려면 필요한 정보와 표시 형식, 다른 지표보다 더 높은 확신을 줄 수 있는 검증 신호에 대해 합의하세요. 5단계에서 초기 샘플 결과물을 검토 담당자들이 확인하도록 하세요.
• SME의 시간을 효율적으로 배분하세요. SME가 모든 최종 코드 변경 내역(diff)을 검토하지는 않지만, 이들의 전문적인 판단은 여전히 확보하기 어려운 핵심 자원입니다. 방대한 코드 변경 내역을 일일이 살펴보지 않고도 위험 등급이 가장 높은 변경 사항과 그 안에서 검토 대상으로 표시된 에이전트의 결정 사항을 바로 확인할 수 있도록 하세요. 이렇게 하면 전문가들이 적은 시간만 투입해도 위험이 가장 큰 변경 사항을 집중적으로 검토할 수 있습니다.

이러한 원칙 중 상당수는 프로젝트 초기부터 SME를 참여시켜, 이들의 시간을 초반에 집중적으로 투입하도록 합니다. 이들의 피드백을 바탕으로, 전체 현대화 작업이 시작되기 전에 인증 기준과 에이전틱 워크플로우를 개선할 수 있습니다.

전문가가 초기 샘플 결과물을 검토하고 승인한 것은 변경 사항에 대한 신뢰도가 높은 경우 검토 절차를 간소화할 수 있는 추가적인 근거가 됩니다. 이는 검토가 마지막 단계에서 진행되는 기존의 비에이전틱 방식과 정반대입니다.

프로덕션 반영 정책에는 현대화 작업이 속도와 검토 수준 사이에서 어디에 더 주안점을 둘지 반영해야 합니다. 런타임 지원 종료와 같이 반드시 지켜야 하는 마감 기한에 맞춰 서둘러 진행해야 하는 현대화 작업에는 사람의 검토를 간소화한 신속한 프로덕션 반영 정책과 변경 사항별로 더 높은 위험을 감수하겠다는 명시적인 합의가 필요합니다.

현대화 일정에 여유가 있다면, 사람이 더 면밀하게 검토하고 신규 시스템으로의 전환을 더 천천히 진행할 수도 있습니다. 이해관계자들은 위험 감수 성향과 제약 조건에 따라 속도와 검토 수준 사이에서 서로 다른 지점을 선택하게 되므로, 작업이 시작되기 전에 이를 확정해 두는 것이 좋습니다.

규제가 적용되는 환경에서 어떤 변경 사항이든 사람의 검토를 간소화하는 데 상당한 부담을 느낄 수 있습니다. 개별 승인 담당자는 잘못된 변경 사항에 대한 책임을 져야 하므로 승인을 주저하지만, 경영진은 시스템 노후화에 따른 더 큰 위험을 감수해야 합니다.

경험상 프로덕션 반영 정책에 대한 지침은 최고위 경영진이 제시하는 것이 가장 효과적입니다. 또한 프로덕션 환경에 반영된 버그에 대한 책임이 변경 사항을 승인한 특정 담당자에게 집중되지 않고 공동으로 분담되도록, 사전에 정책에 합의하는 것이 바람직합니다.

4단계: 사전 준비 사항 마련

이 단계의 작업 상당수는 현대화 프로젝트에 참여하지 않는 여러 팀과 협력해 진행해야 합니다. 호스팅 환경은 플랫폼 또는 인프라팀, 테스트 역량 확보는 QA 또는 릴리스 엔지니어링팀, 승인은 보안 및 규정 준수팀이 담당합니다. 각 팀에는 각자 처리해야 할 작업 목록이나 승인 절차가 있는 경우가 많으므로, 요구 사항을 파악하는 즉시 관련 팀과 협의를 시작하세요. 이는 대개 1~3단계가 아직 진행 중인 시점입니다.

환경

• Claude가 코드베이스와 기타 관련 소스에 접근할 수 있도록 구성된 워크플로우 실행용 전용 원격 호스트
• 인증 기준에 따라 필요한 테스트 수행 역량
• 인증 기준을 강화하는 데 필요한 요소: 프로덕션 텔레메트리 데이터, 프로덕션 병렬 환경, 재생에 사용할 프로덕션 데이터

코드베이스 및 CI/CD

• 빌드 및 컴파일 로그, 임포트 분석 또는 런타임 추적 데이터를 근거로 작성한 코드베이스의 의존성 맵. 참고: 플러그인의 map 명령을 활용하면 초기 작업을 시작하는 데 도움이 되지만, 코드베이스의 규모와 사용 연한에 따라 더 광범위한 사전 작업이 필요할 수 있습니다.
• 목표 상태 정의의 일부로서, 모든 의존성 또는 패키지 처리 방법에 대한 계획
• 필요한 경우 CI/CD에 추가할 수 있도록 준비된 호환성 검사
• 기존 환경에서 직접 현대화하는 경우, 사전에 합의된 코드 동결 정책
• 현업 개발자에게 코드 동결 및 새로운 호환성 요구 사항을 알리기 위한 커뮤니케이션 계획

팀 및 검토

• 코드베이스에 의존하는 다른 팀들과 인증 기준 승인, 프로덕션 반영 정책에 따른 검토 등 참여 방식에 대해 합의하고 검토 담당자의 업무 시간도 사전에 배정해야 합니다.

보안 및 규정 준수

• 소스 코드에 사용하도록 승인된 Claude Code 모델 접근 경로
• 에이전트 워크플로우에 대한 최소 권한 접근: 현대화 작업용 브랜치에만 쓰기를 허용하고, 프로덕션 환경의 인증 정보에는 접근할 수 없도록 제한
• 현대화 작업용 브랜치에서 비밀 정보 및 PII 제거 또는 마스킹
• 모든 변경 사항은 추적할 수 있으며, PR은 에이전트 작업 기록 및 인증 기준에 따른 검증 근거에 연결
• 새로운 의존성에 대한 라이선스 및 보안 취약성 검사

5단계: 에이전틱 워크플로우 구축 및 개선

Claude Code를 활용해 코드베이스 현대화를 위한 맞춤형 동적 워크플로우를 개발하세요.

코드 현대화 플러그인부터 시작해, 워크플로우에 필요한 모든 요소를 Claude가 접근할 수 있는 파일 시스템이나 MCP를 통해 제공하는 것이 좋습니다. 여기에는 목표, 인증 기준, 프로덕션 반영 정책, 코드베이스, 문서, 그리고 인증 기준에 필요한 모든 데이터 소스나 도구가 포함됩니다. 이 문서를 Claude에 컨텍스트로도 제공할 수 있습니다. 이러한 요소들이 프로젝트의 중앙 지식 베이스를 형성합니다.

이러한 요소를 모두 갖추었다면 현대화 워크플로우를 구축하는 것은 어렵지 않습니다. 필요에 따라, SME가 Claude의 작업을 검토하도록 하세요. 특히 코드베이스 전용 스킬이나 추출된 규칙은 후속 작업에서 활용하기 전에 검토해야 합니다.

구축한 워크플로우를 코드베이스의 작은 부분에 적용하면서 개선해 나가세요. SME가 생성된 코드 변경 사항, 에이전트의 작업 과정, 인증 기준을 충족했다는 검증 근거까지 검토하도록 해야 합니다.

6단계: 현대화 실행

먼저, 코드베이스의 작은 부분을 대상으로 현대화 작업의 전체 과정을 완료하세요. 여기에는 프로덕션 반영 정책에 따라 변경 사항을 검토하고 실제로 적용하는 과정까지 포함해야 합니다. 수정 비용이 적게 드는 단계에서 제대로 작동하지 않는 부분을 수정하고, 확신이 생길 때까지 이 과정을 반복한 뒤, 전체 코드베이스로 확대하세요.

변환형 및 재구상형 현대화는 기존 시스템과 병행하여 목표 시스템을 구축하고, 작업이 완료되면 전환하는 방식입니다. 반면, 업리프트형 현대화에는 또 다른 선택지가 있습니다. 기존 개발 작업을 계속 진행하면서 운영 중인 코드베이스를 직접 현대화하는 방식입니다.

시스템을 중단할 수 없거나, 코드베이스가 너무 빠르게 변경되어 별도로 현대화한 코드베이스를 최신 상태로 유지하기 어려운 경우, 일반적으로 이 방식을 선택합니다. 이 경우 저희 경험상 효과적인 것은 코드베이스를 말단 부분부터 내부 방향으로 논리적인 구획으로 나누고, 각 구획을 하나씩 동결하여 현대화한 다음, 새로운 커밋이 이미 현대화된 구획을 이전 상태로 되돌릴 수 없도록 CI/CD에 검증 절차를 설정하는 것입니다.

비용 관련 참고 사항

이러한 현대화 작업에 토큰이 얼마나 소요되는지 묻는 질문을 자주 받습니다. 현대화 프로젝트마다 차이가 있지만, 비용에 미치는 주요 요인은 다음과 같습니다.

• 코드베이스에서 읽어야 하는 코드와 실제로 수정해야 하는 코드의 양
• 인증 기준의 복잡성(규제 대상 환경에서는 변경 사항을 작성하는 것보다 검증하는 데 더 많은 비용이 드는 경우가 일반적)
• 인증 기준을 충족하기 위해 새로 작성하거나 보완해야 하는 테스트의 양
• 현대화 작업이 진행되는 동안 다른 팀이 코드 변경 사항을 병합하면서 발생하는 조정 작업의 규모

파일럿 단계에서 측정한 데이터는 비용 측면에서 에이전틱 워크플로우의 어느 부분을 최적화해야 하는지도 보여 줍니다. 워크플로우에서 토큰 사용량이 가장 많은 단계를 식별하고, 더 효율적으로 개선할 방법을 고려하세요. 컴퓨팅 자원이 많이 필요한 검증 항목은 비용이 적게 드는 검증 절차 이후로 배치하여, 간단한 검사를 통과한 경우에만 실행되도록 하세요.

인증 기준에 따라 모든 결과를 검증할 수 있는 정형화된 대량 작업에는 비용과 성능의 균형을 갖춘 Sonnet과 같은 모델을 사용하는 것을 고려해 보세요. 복잡한 변환 작업과 정확성을 검증하는 적대적 검토에는 더 지능적인 모델을 사용하세요.

비용이 낮은 모델이 인증 기준을 충족하지 못하면 더 고가의 모델로 전환할 수도 있습니다. 하지만 비용이 낮은 모델로 여러 번 시도하는 것이 비용이 높은 모델로 한 번 시도하는 것보다 더 많은 비용이 들 수 있으므로, 파일럿 단계에서 재시도 비율을 신중하게 분석해야 합니다. Claude에 워크플로우와 파일럿 데이터 모두에 대한 접근 권한을 부여하면, 이러한 분석의 상당 부분을 Claude와 함께 수행할 수 있습니다.

현대화 이후의 활용

현대화된 코드베이스는 결과물 중 하나일 뿐입니다. 그 밖에도 현대화된 코드베이스를 만들어 낸 워크플로우, 올바른 결과를 판단하는 기준을 명시한 인증 기준 문서, 조직의 변경 관리 프로세스에서 이미 승인한 프로덕션 반영 정책, 그리고 실제 반영된 모든 변경 사항에 대한 검증 근거 기록이 결과물로 남습니다. 이러한 작업 절차를 재사용 가능한 자산으로 정리해 두면, 다음 업그레이드나 코드 재작성 작업에서도 이미 마련된 방식을 활용할 수 있습니다.

Anthropic의 현장 배치 엔지니어들은 고객의 가장 중요한 시스템을 대상으로 이러한 단계를 수행합니다. 현대화 프로젝트를 준비하고 있다면, Anthropic 팀에 문의하세요.

추가 리소스

• Claude Code용 공개 codemod 플러그인
• AI 네이티브 SDLC 플레이북
• 코드 현대화 플레이북
• AI를 통한 COBOL 현대화: 비용 장벽 극복