← 전체 글
Analysis

DXC가 규제 산업의 레거시 코드 현대화에 Claude를 쓰는 방식

2026년 6월 11일, Anthropic은 DXC Technology와 다년간의 제휴를 발표했다. Claude를 “빠르게 움직인다”가 대개 “먼저 롤백 계획부터 써라”를 뜻하는 시스템 한복판에 넣겠다는 이야기다. DXC에 따르면 Claude는 이미 DXC OASIS 에이전트형 워크플로의 기본 파운데이션 모델이고, Claude 덕분에 OASIS 소프트웨어 딜리버리가 추정 10배 빨라졌으며, 엔지니어 검토 전에 OASIS 코드의 95% 이상이 Claude로 생성됐다 (Anthropic, PRNewswire).

흥미로운 지점은 바로 여기다. “AI가 코드를 쓴다”가 아니다. 그런 데모는 다들 봤다. 진짜 이야기는 DXC가 에이전트형 코드 생성을 은행, 항공사, 보험사, 제조사, 정부 기관으로 가져가고 있다는 점이다. 여기서 어려운 문제는 의존성 고고학, 릴리스 거버넌스, 감사 가능성, 보안, 그리고 새벽 2시에 실제 돈을 정산하는 30년 된 배치 프로세스를 망가뜨리지 않는 일이다.

DXC OASIS식 현대화 흐름의 아키텍처 스케치: 레거시 코드 저장소, 의존성 스캐너, Claude 기반 에이전트

신호: AI가 매니지드 서비스 계층으로 들어간다

DXC는 2026년 4월 28일, 매니지드 서비스를 위한 지능형 오케스트레이션 플랫폼으로 OASIS를 출시했다. OASIS의 역할은 조직의 기존 IT 자산 전반에 거버넌스와 보안을 갖춘 계층으로 자리 잡아, 운영을 사후 대응형 지원에서 실시간 실행으로 옮기는 것이다 (DXC).

이게 중요한 이유는 규제 산업의 현대화가 깨끗한 저장소와 그린필드 목표에서 시작되는 경우가 거의 없기 때문이다. 보통은 이런 것들에서 시작한다.

  • 누구도 완전히 소유하지 않는 배치 작업
  • 일반 지원 기간을 지난 애플리케이션 서버
  • COBOL, Java EE, PL/SQL, shell, 그리고 벤더 워크플로 접착 코드
  • 일부는 코드에, 일부는 런북에 들어 있는 컴플라이언스 통제
  • 결제, 청구, 예약, 재고, 신원, 사건 관리 시스템과의 깨지기 쉬운 연동

Claude를 OASIS에 넣는다는 것은 DXC가 모델을 업무 옆에 붙은 챗봇으로 취급하지 않는다는 뜻이다. 모델을 이미 인시던트, 변경 창, 티켓 맥락, 런북, 환경, 고객 제약을 알고 있는 오케스트레이션 워크플로 안에 배치하는 것이다. 이것이 “리팩터링을 생성한다”와 “CAB 검토를 통과할 수 있는 리팩터링을 생성한다”의 차이다.

Anthropic은 DXC가 Anthropic Academy를 통해 수만 명의 Claude 인증 현장 배치 엔지니어를 교육하고, DXC가 미션 크리티컬 시스템을 위한 자체 커리큘럼을 더할 것이라고 말한다 (Anthropic). 방향이 맞다. 규제 환경의 현대화에는 프롬프트 관광객이 아니라 시스템을 읽을 수 있는 사람이 필요하다.

개발자가 베껴야 할 것

DXC 규모에서 일하지 않더라도 DXC 패턴은 쓸모가 있다. 교훈은 “모델에게 저장소를 맡겨라”가 아니다. 교훈은 이것이다. 모델의 작업을 맥락, 제약, 검토, 증거가 일급 객체인 워크플로로 감싸라.

실용적인 레거시 현대화 에이전트는 “이 서비스를 Go로 다시 써줘”에서 시작하면 안 된다. 제약이 걸린 계획에서 시작해야 한다.

1. Inventory modules, entry points, data stores, and external contracts.
2. Identify dead code and risk hotspots.
3. Propose the smallest behavior-preserving refactor.
4. Generate tests around current behavior before changing code.
5. Open a reviewable patch with traceable rationale.
6. Attach evidence: tests, static analysis, dependency impact, rollback notes.

지루하게 들린다. 좋다. 지루함이 규제 시스템을 바꾸는 방식이다.

DXC가 공개한 숫자는 공격적이다. OASIS의 소프트웨어 딜리버리가 추정 10배 빨라졌고, 코드의 95% 이상이 Claude로 생성된 뒤 엔지니어가 검토했다는 것이다 (Anthropic). 이것을 보편적인 생산성 상수가 아니라 배포 환경에 특화된 주장으로 받아들여야 한다. 개발자에게 중요한 포인트는 운영 모델이다. 높은 모델 기여도, 필수적인 인간 검토, 그리고 작업을 기록하는 플랫폼.

은행 코어 마이그레이션이라면 에이전트가 거래 흐름을 매핑하고 특성화 테스트를 생성하는 식일 수 있다. 항공사라면 외부 메시지 형식을 보존하면서 예약이나 정비 워크플로를 풀어낼 수 있다. 보험사라면 계약 관리 규칙과 청구 동작을 비교할 수 있다. 제조사라면 코드를 건드리기 전에 ERP, MES, 공급망 의존성을 추적할 수 있다.

현대화 전후 비교: 왼쪽은 얽힌 레거시 모듈, 배치 작업, 문서화되지 않은 연동을 보여준다

모델 선택은 아키텍처 결정이 되고 있다

DXC 발표 이틀 전인 2026년 6월 9일, Anthropic은 Claude Fable 5와 Claude Mythos 5를 출시했다. Fable 5는 Anthropic의 일반 제공 Mythos급 모델이고, Mythos 5는 Project Glasswing 및 신뢰 기반 접근 프로그램을 통해 제한적으로 제공된다. Anthropic은 현재 API 문서에서 Fable 5 가격을 입력 토큰 100만 개당 10달러, 출력 토큰 100만 개당 50달러로 제시하며, 1M 토큰 컨텍스트 창과 128k 최대 출력을 제공한다고 설명한다 (Anthropic, Claude Docs).

Anthropic 모델 개요의 간단한 가격 스냅샷은 이렇다.

모델입력출력컨텍스트최대 출력
Claude Fable 5$10 / MTok$50 / MTok1M tokens128k
Claude Opus 4.8$5 / MTok$25 / MTok1M tokens128k
Claude Sonnet 4.6$3 / MTok$15 / MTok1M tokens64k
Claude Haiku 4.5$1 / MTok$5 / MTok200k tokens64k

잘못된 결론은 “항상 가장 강한 모델을 써라”다. 더 나은 아키텍처는 모델 라우팅이다.

시스템 수준 추론에는 가장 강한 모델을 써라. 의존성 발견, 마이그레이션 계획, 낯선 프레임워크, 여러 저장소에 걸친 리팩터링, 실패 분석 같은 작업이다. 요약, 단순 테스트 생성, 문서 정리, 기계적인 편집에는 더 저렴한 모델을 써라. 두 경우 모두 주변에 결정론적 도구를 붙여야 한다. 컴파일러, 테스트 러너, 스키마 diff 도구, SAST, SBOM 생성, 정책 검사 같은 것들이다.

Anthropic은 또한 Fable 5가 특정 사이버보안, 생물학, 화학, 또는 증류 관련 요청에서 Claude Opus 4.8로 폴백하는 안전장치를 갖췄고, 초기 데이터상 Fable 세션의 95% 이상은 폴백이 없었다고 말한다 (Anthropic). 규제 산업 개발자에게 이것은 각주가 아니다. 워크플로가 보안 수정, 취약점 분석, 민감한 연구를 다룬다면 에이전트 런타임은 모델 폴백을 감지하고, 기록하고, 그 결과물이 여전히 보증 기준을 충족하는지 판단해야 한다.

Claude Fable 5, Opus 4.8, Sonnet 4.6, Haiku 4.5를 보여주는 성능 및 가격 비교 차트와 입력 가격 막대

인간 검토는 세금이 아니라 제품이다

“95% 이상 Claude 생성 코드”라는 문구가 헤드라인을 차지할 것이다. 하지만 “그다음 소프트웨어 엔지니어가 검토했다”는 문구가 배포 가능성을 만든다.

규제 환경의 현대화에서 검토는 의례적인 pull request 승인일 수 없다. 검토는 구체적인 질문에 답해야 한다.

  • 동작이 바뀌었는가, 테스트 증거는 어디에 있는가?
  • 어떤 데이터 계약, 스키마, APIs, 배치 파일이 건드려졌는가?
  • 패치가 인가, 보존, 로깅, 감사 추적을 바꾸는가?
  • 롤백 경로가 있는가?
  • 작성자가 아닌 사람이 6개월 뒤에 이 변경이 왜 존재하는지 이해할 수 있는가?

여기서 에이전트 워크플로가 느슨한 채팅을 이긴다. 좋은 워크플로는 생성된 모든 패치가 자체 설명, 테스트 계획, 위험 분류, 영향받는 시스템 맵을 갖도록 강제할 수 있다. 모델이 의존 서비스 하나를 확인하지 않았거나 생성된 테스트가 해피 패스만 증명할 때 병합을 막을 수도 있다.

개발자의 역량은 모든 줄을 직접 타이핑하는 것에서 검토 가능한 작업 패킷을 설계하는 것으로 이동한다. 그것도 여전히 엔지니어링이다. 많은 레거시 자산에서는 바로 그 엔지니어링이 빠져 있었다.

에이전트형 현대화를 위한 작은 패턴

내가 규제 소프트웨어 팀 안에서 이것을 만든다면, 모든 현대화 작업이 코드 리뷰 전에 네 가지 산출물을 만들게 할 것이다.

  1. inventory.md: 진입점, 의존성, 설정, 데이터 저장소, 외부 계약.
  2. risk.md: 영향받는 비즈니스 프로세스, 건드린 컴플라이언스 통제, 롤백 메모.
  3. tests/: 현재 동작을 고정하는 특성화 테스트.
  4. patch.diff: 동작을 보존하는 가장 작은 변경.

모델은 네 가지를 모두 생성할 수 있다. 엔지니어는 네 가지를 모두 검토해야 한다. CI는 지루한 부분을 강제해야 한다.

로컬 실험용으로는 Claude Fable 5를 OneHop을 통해 Anthropic Messages 엔드포인트에 드롭인으로 사용할 수도 있다. OneHop의 Fable 5 페이지는 현재 엔드포인트를 https://api.onehop.ai/anthropic, 모델 이름을 anthropic/claude-fable-5로 표시하고, 카드 없이 새 계정에 10달러 크레딧을 제공한다고 안내한다. 표시된 프로모션 가격은 입력 100만 토큰당 5달러, 출력 100만 토큰당 25달러로, Anthropic의 10달러/50달러 정가보다 30% 이상 낮다 (OneHop).

from anthropic import Anthropic

client = Anthropic(
    base_url="https://api.onehop.ai/anthropic",
    api_key="<ONEHOP_KEY>",
)

message = client.messages.create(
    model="anthropic/claude-fable-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Map risks in this legacy migration plan."}],
)

그런 종류의 엔드포인트는 프로토타입과 평가 하네스에 써라. 규제 프로덕션 워크로드에서 어려운 부분은 여전히 당신의 통제다. 데이터 처리, 보존, 접근, 증거, 모델 라우팅, 인간 승인 말이다.

빠른 기계적 작업에는 Haiku 4.5, 균형 잡힌 코딩에는 Sonnet 4.6, 복잡한 추론에는 Opus 4.8을 보여주는 모델 패밀리 다이어그램

진짜 베팅: 현대화는 지속적인 일이 된다

대부분의 기업은 레거시 현대화를 10년에 한 번 하는 프로그램처럼 다룬다. 큰 예산. 큰 SI. 큰 위험. 그리고 새 플랫폼은 첫날부터 다시 낡기 시작한다.

DXC의 OASIS 이야기는 더 나은 모델을 가리킨다. 현대화를 지속적인 매니지드 서비스 워크플로로 보는 모델이다. 에이전트가 검사하고, 제안하고, 테스트하고, 리팩터링하고, 문서화하고, 작업을 엔지니어에게 라우팅한다. 엔지니어는 검토하고, 제약을 걸고, 승인한다. 플랫폼은 증거를 보관한다. 시스템은 더 작고 더 안전한 단위로 개선된다.

그래서 이 제휴는 지켜볼 가치가 있다. 유용한 질문은 Claude가 코드를 쓸 수 있느냐가 아니다. 쓸 수 있다. 유용한 질문은 조직이 다운되면 안 되는 시스템 전반에서 생성된 코드를 거버넌스가 있고, 검토 가능하며, 프로덕션에 안전한 변경으로 바꿀 수 있느냐다.

DXC는 이것이 진지한 규모에서 작동할 수 있다는 초기 증거를 주장하고 있다. 70개국 115,000명 직원, 50개 이상의 고객과 프로덕션에서 운영 중인 OASIS, 계획된 수만 명의 Claude 인증 현장 배치 엔지니어, 그리고 OASIS 에이전트형 워크플로의 기본 모델인 Claude (Anthropic, PRNewswire).

개발자에게 움직임은 분명하다. AI를 autocomplete로 생각하는 것을 멈춰라. 테스트, diffs, 설명, 감사 추적을 남기는 에이전트 워크플로를 설계하기 시작하라. 레거시 현대화에는 늘 그것이 필요했다. 모델 덕분에 마침내 서류 작업과 코드 이동이 충분히 싸져서 지속적으로 할 수 있게 됐다.

전체 엔터프라이즈 스택을 세팅하지 않고 모델 라우팅 쪽을 테스트하고 싶다면, 좁은 저장소 하나, 특성화 테스트 작업 하나, 그리고 Claude Fable 5 on OneHop 같은 Fable 5 엔드포인트로 시작하라. 인간 검토 게이트는 유지하라. 승인된 diffs, 실패한 테스트, 검토 시간, 롤백 품질, 병합된 변경당 비용을 측정하라. 그런 다음 그 워크플로가 더 큰 시스템을 맡을 자격이 있는지 결정하라.

무료 $10 받기 →