전체 MuleSoft‑to‑.NET 마이그레이션을 계획하기 위해 22개의 프롬프트를 사용했습니다. 여기 플레이북이 있습니다.

I’m happy to translate the article for you, but I need the actual text of the post. Could you please paste the content you’d like translated (or a specific excerpt)? Once I have the text, I’ll keep the source link at the top and provide the Korean translation while preserving all formatting, markdown, and code blocks.

지난 주에 나는 MuleSoft 통합 프로젝트를 .NET 10 Minimal APIs 로 마이그레이션하기 위해 자리를 잡았다.

마이그레이션 사양, 아키텍처 문서, 에이전트‑팀 정의를 며칠 동안 수작업으로 작성하는 대신, 나는 Claude와 한 번의 대화로 모두 해결했다.

22개의 프롬프트. 이것만으로 “어디서 시작해야 하지?”에서 완전하게 구조화되고, 감사받으며, 실행 준비가 된 마이그레이션 툴킷(스캐너 에이전트, 단계별 프롬프트, 통합 패턴, 프로젝트 스캐폴딩 포함)까지 도달했다.

아래는 어느 개발 팀이든 따라 할 수 있는 반복 가능한 플레이북이다.

Phase 1 – 탐색 및 AI를 코드베이스에 맞추기

대부분의 개발자는 AI 대화를 시작할 때 모든 정보를 한 번에 텍스트로 제공한다. 그럴 필요 없다.

1. 넓게 시작한다. 먼저 AI에게 접근 방식을 제안하게 하고, 그 뒤에 방향을 잡는다.

   What is the best approach to convert MuleSoft to C# Minimal API?

2. Claude는 탄탄한 일반 전략(Strangler Fig 패턴, 커넥터‑매핑 테이블, 단계적 접근)을 반환했다. 좋은 기반이었지만 너무 일반적이었다 – 내 스택을 몰랐기 때문이다.

3. 실제 코드를 가리킨다:

   Check my project on GitHub for the target architecture

   잘못된 레포(오류)를 지적받고 바로 잡았다:

   That's not the right repo – try this URL instead

핵심 인사이트: AI는 가상의 프로젝트가 아니라 실제 프로젝트에 기반을 두었을 때 훨씬 더 좋은 결과를 만든다. 솔루션 구조, EF Core 설정, Polly 구성, Azure AD 인증을 읽은 뒤에 생성된 모든 내용이 상황에 맞았다.

요점: 아키텍처를 서술형으로 설명하지 말고, AI에게 코드를 직접 읽게 하라.

Phase 2 – 도구에 맞는 산출물 요청하기

AI가 코드베이스를 이해했으니, 정확히 사용할 포맷으로 결과물을 달라고 요청한다.

Can you create detailed agent‑team definitions I can use with Claude Code CLI?

Claude는 Claude Code의 agent teams 기능에 맞춘 에이전트‑팀 역할, 프롬프트, 조정 규칙 전체를 생성했다. 검토 중에 나는 한 부분이 빠졌음을 발견했다:

We're missing a step – we need to scan and inventory the source project before migrating anything

Phase 0 스캐너를 언급하지 않았기 때문에 AI는 이를 생각하지 못했다. 내가 그 빈틈을 지적하자, AI는 다음과 같은 5‑agent 스캐너 팀을 만들었다:

• MuleSoft XML 플로우 파싱
• DataWeave 변환 카탈로그화
• 커넥터를 NuGet 패키지에 매핑
• 단계별 마이그레이션 계획 생성

그 뒤 나는 AI가 스스로 찾아낼 수 없는 도메인 지식을 제공했다:

I already know the integrations we use – Azure AD auth, Key Vault for secrets, Graph API for user management, Box for documents, and SQL Server stored procedures

스캐너는 각 통합에 대한 즉시 사용 가능한 C# 구현 패턴(타입드 클라이언트, DI 등록, 설정 예시 포함)으로 사전 시드되었다. 허위 API도 없고, 오래된 SDK 호출도 없었다.

요점: AI는 실제 운영 시스템을 읽을 수 없다. 알고 있는 정보를 제공하면 AI는 추측 대신 그 지식을 기반으로 구축한다.

Phase 3 – 아키텍처 결정에 도전하기

대부분의 사람들은 AI의 첫 번째 답변을 그대로 받아들인다. 그렇지 않다. 토론하라.

나는 처음에 이렇게 제안했다:

I think we should copy the source code into a docs folder inside the project

그 직후 스스로 아이디어에 이의를 제기했다:

Actually no – the source should stay external and never be modified. Ask the user for the path at runtime instead

30초 동안의 왕복 대화는 근본적으로 더 나은 설계를 이끌어냈다:

• MuleSoft 프로젝트는 원본 위치에 읽기 전용으로 남는다.
• 스캐너는 경로(MULE_SOURCE_PATH)를 요청한다.
• 파일 복제도, 우발적인 수정도 없으며, 깔끔하게 분리된다.

AI는 즉시 적응했다: Phase 0 초기 프롬프트를 다시 작성하고, 모든 에이전트‑팀 정의를 MULE_SOURCE_PATH를 참조하도록 업데이트했으며, 디렉터리 구조 검증도 추가했다.

요점: 최고의 아키텍처는 단일 프롬프트가 아니라 토론을 통해 나온다. 계속해서 의문을 제기하고 수정하라.

Source: …

ck on the AI – and on yourself. The AI is fast enough to restructure everything in seconds.

Phase 4 – 컨텍스트가 변함에 따라 디자인 진화

실제 프로젝트는 당신이 계획하는 동안 멈추지 않는다. 세션 중에 프로젝트 구조가 바뀌었다.

나는 깨달았다:

This is a reusable template, not the actual project – we need a scaffolding step that renames everything

Claude는 즉시 Bash와 PowerShell용 초기화 스크립트를 생성했다. 그 후 다른 세션에서는 dotnet new 템플릿 엔진과 sourceName을 사용해 다르게 처리했다:

Another session is handling the template config already, so we don't need the init script anymore – drop it

대부분의 개발자는 이를 AI에게 알리는 것을 잊어버려 중복 작업, 충돌하는 접근 방식, 삭제된 파일을 참조하는 문서가 남는다. 한 번의 프롬프트 “drop it”가 Claude에게 다음을 수행하게 했다:

• 스크립트 제거
• 모든 교차 참조 업데이트
• 워크플로 간소화

핵심: 다른 것이 해당 관점을 처리한다면, AI에게 추가가 아니라 제거하도록 알려라. 오래된 참조가 있는 AI‑생성 문서는 문서가 전혀 없는 것보다 더 나쁘다.

Phase 5 – 배포 전 품질 게이트

AI는 일관성 오류를 만들 수 있다. 서로 연결된 여섯 개 파일을 살펴보면 이름 누수, 깨진 교차 참조, 오래된 경로가 발견된다. 배포 전에 반드시 감사를 수행하라.

1. 첫 번째 이슈:

   The generated config still has hardcoded project name references – it needs to use generic placeholders

2. 레포 구조가 변경됨:

   These files belong in a separate toolkit repo – here's the folder structure, reorganize everything to fit

3. 마지막이자 가장 중요한 프롬프트:

   Do a deep review of every file – check cross‑references, path consistency, typos, and logical errors

Claude는 전체 프로젝트 리뷰를 수행하고, 자리표시자를 수정하고, 경로를 업데이트하며, 이름 불일치를 고치고, 커밋 준비가 된 깔끔한 툴킷을 만들어냈다.

핵심: 출력물을 “완료”라고 간주하기 전에 체계적인 AI‑지원 감사를 실행하라.

TL;DR 플레이북

이 단계들을 따라 하면, 여러 주에 걸친 마이그레이션을 단일 세션 AI‑주도 스프린트로 전환할 수 있습니다. 마이그레이션을 즐기세요!

모든 파일에 대한 2‑point audit

It found and fixed:

• 일관되지 않은 자리표시자 이름 ({Name} vs {ProjectName})
• 퀵‑레퍼런스 프롬프트에서 잘못된 MuleSoft 디렉터리 경로
• JSON 구성(EnterprisId)의 오타
• “copied to”라는 오래된 문구가 “accessible at”로 바뀌어야 함
• 교차‑참조에 있는 오래된 파일 이름

Without that final audit, I would have shipped docs that pointed to non‑existent files and used incorrect MuleSoft paths. The audit took 2 minutes. It would have cost hours of debugging later.

핵심: 최종 감사 없이 AI‑생성 출력물을 절대 배포하지 마세요. AI에게 스스로 작업을 검토하도록 요청하세요—명시적으로 요청하면 AI가 자신의 실수를 잡아내는 데 놀라울 정도로 능숙합니다.

플레이북

다음은 정리된 패턴입니다:

1. 폭넓게 시작 – AI에게 제안을 맡기고, 초기에 과도하게 구체화하지 마세요.
2. 실제 코드에 기반 – 가상의 저장소가 아니라 실제 레포지토리를 가리키세요.
3. 사용 가능한 산출물 요청 – 도구가 실제로 소비하는 형식으로 요청하세요.
4. 도메인 지식 제공 – 통합, 제약 조건, 시스템에 대해 알고 있는 내용을 알려 주세요.
5. 갭 식별 – 출력물을 검토하고 누락된 부분을 표시하세요.
6. 아키텍처 토론 – 가정(자신의 가정 포함)에 대해 반박하세요.
7. 계획 진화 – 상황이 변하면 AI를 업데이트하고 오래된 작업을 제거하세요.
8. 모두 감사 – 배포 전에 철저한 파일 간 검토를 요구하세요.

• 22개의 프롬프트. 하나의 대화.
• 스캐너 에이전트, 단계별 마이그레이션 프롬프트, 통합 패턴, 설정 가이드, 프로젝트 스캐폴딩을 포함한 완전한 마이그레이션 툴킷 – 모두 검증되고 교차 참조되어 바로 사용할 수 있습니다.

AI가 내 판단을 대체한 것은 아닙니다. 오히려 증폭시켰을 뿐입니다. 모든 아키텍처 결정은 내 것이었고, AI는 그 결정을 며칠이 아닌 몇 시간 안에 실행할 수 있게 해 주었습니다.