GitHub Copilot 현대화를 사용하여 프로젝트 다시 설계

이 문서에서는 GitHub Copilot 현대화에서 다시 아키텍처 기능을 사용하여 레거시 프레임워크에서 최신 아키텍처(예: Struts에서 Spring MVC로)로 프로젝트를 다시 작성하는 방법을 설명합니다.

개요

다시 아키텍처 기능을 사용하면 AI 기반 다중 에이전트 워크플로를 사용하여 전체 프로젝트를 레거시 프레임워크에서 최신 아키텍처로 변환할 수 있습니다. 파일로 수동으로 마이그레이션하는 대신 자연어로 원하는 변환을 설명하고 현대화 에이전트는 분석, 계획 및 코드 생성을 처리합니다.

일반적인 다시 아키텍처 시나리오는 다음과 같습니다.

  • 스트럿에서 Spring MVC로
  • Struts에서 Spring Boot로
  • JSP에서 Thymeleaf로
  • EJB에서 Spring Boot로
  • Spring Boot에 대한 WebSphere 애플리케이션
  • 최신 Spring 기반 아키텍처에 대한 레거시 서블릿 기반 애플리케이션
  • Angular 웹 애플리케이션에 대한 Windows Forms(WinForms) 데스크톱 애플리케이션
  • ASP.NET MVC 프런트엔드 애플리케이션을 Angular 웹 애플리케이션으로

사전 요구 사항

  • GitHub Copilot 모던화 확장이 설치된 Visual Studio Code.
  • GitHub Copilot 구독입니다. 자세한 내용은 Copilot 계획 참조하세요.
  • (선택 사항) 지식 그래프를 빌드하기 위한 Python 3.7 이상이며, 이를 통해 에이전트는 재작성 프로세스 중에 프로젝트 구조를 보다 명확하게 이해할 수 있습니다. Python을 사용할 수 없는 경우 지식 그래프 단계가 건너뛰어집니다.
  • (선택 사항) 런타임 유효성 검사의 일환으로 Playwright 테스트를 실행하기 위해 Node.js 18 이상이 필요합니다. Node.js 사용할 수 없으면 Playwright 테스트 단계를 건너뜁습니다.
  • (선택 사항) 런타임 유효성 검사를 위한 Docker Desktop 입니다. Docker를 사용할 수 없는 경우 런타임 유효성 검사 단계를 건너뜁니다.

재구성 에이전트 사용

GitHub Copilot Chat 패널에서 현대화 에이전트를 사용합니다.

다음 단계를 사용하여 프로젝트를 다시 설계합니다.

  1. Visual Studio Code 프로젝트를 엽니다.

  2. GitHub Copilot Chat 패널을 엽니다.

  3. 에이전트 목록에서 에이전트 현대화 를 선택합니다.

  4. 수행하려는 변환에 대해 설명합니다. 다음은 그 예입니다.

    Rewrite the entire project from Struts to Spring MVC using rearchitecture agent

에이전트는 다음 단계를 수행하는 다중 에이전트 팀을 조정합니다.

  1. 분석 - 프레임워크 패턴, 종속성 및 모듈 경계를 식별하여 기존 코드베이스를 검사합니다.
  2. 계획 - 정렬된 작업 및 요구 사항 추적 기능을 사용하여 구조화된 구현 계획을 생성합니다.
  3. 실행 - 각 단계에서 유효성 검사를 사용하여 계획 다음에 코드 변환을 적용합니다.

중요합니다

분석 및 계획 단계가 완료되면 에이전트는 코드 생성을 시작하기 전에 일시 중지하고 확인을 요청합니다. 이 시점에서 계획을 신중하게 검토합니다. 에이전트가 구현을 진행하기 전에 계획 변경 내용을 요청하거나, 우선 순위를 조정하거나, 제약 조건을 추가할 수 있습니다.

더 많은 컨텍스트 제공

프롬프트에 추가 컨텍스트를 제공하여 변환 결과를 향상시킬 수 있습니다.

  • 대상 프레임워크 버전(예: "Spring Boot 3.2 및 Java 21 사용")을 지정합니다.
  • 참조 설명서 링크 또는 마이그레이션 가이드입니다.
  • 조직별 패턴 또는 규칙을 설명합니다.
  • 우선 순위를 지정할 모듈 또는 패키지를 나타냅니다.

다음은 그 예입니다.

Rewrite the entire project from Struts to Spring MVC using Spring Boot 3.2.
Refer to the Spring MVC migration guide at https://docs.spring.io/spring-framework/reference/web/webmvc.html.
Keep the existing backend business logic unchanged.

일반 문제 해결

재구성 과정에서 에이전트는 프로젝트의 .github/modernize/ 디렉터리에 아티팩트를 생성합니다. 이러한 아티팩트를 사용하여 문제가 발생할 때 이를 진단합니다.

생성된 아티팩트 검토

.github/modernize/rearchitecture 디렉터리에는 다음과 같은 주요 리소스가 포함됩니다.

  • board.md - 모든 단계와 상태를 추적하는 작업 보드입니다. 이 파일을 확인하여 통과, 실패 또는 필요한 반복 작업을 확인합니다.
  • artifacts/ - 각 작업의 자세한 보고서입니다. 파일은 t21-tester-report.md과 같은 초기 테스트 보고서 또는 t21.2-tester-report.md과 같은 재시도 반복 명명 규칙을 따릅니다.
  • learn.md - 작업 실행 중에 각 역할에 의해 기록된 검색, 버그 발견 및 기술에 대한 누적 기술 자료입니다. 이 파일을 확인하여 에이전트가 직면했던 문제와 해결 방법에 대한 통찰을 얻으십시오.
  • team/ - 각 에이전트의 책임을 정의하는 역할별 헌장입니다.

품질 게이트가 실패하면 에이전트는 수정 시도를 문서화하기 위해 반복 아티팩트 예를 들어, t21.1, t21.2를 생성합니다. 이러한 번호가 매겨진 반복을 찾아서 문제가 검색되고 해결된 방법을 이해합니다.

분석 및 계획 검토

에이전트가 코드 작성을 시작하기 전에 검토해야 하는 분석 및 계획 아티팩트가 생성됩니다. 이러한 아티팩트에서는 에이전트가 프로젝트에 대해 이해한 내용과 빌드할 대상을 파악할 수 있습니다.

분석 아티팩트에서는 다음을 포함합니다.

  • 아키텍처 요약: 기존 기술 스택, 프로젝트 구조, 데이터 모델 및 통합 지점에 대한 개요입니다. 이 요약을 확인하여 에이전트가 프로젝트의 주요 구성 요소를 올바르게 식별했는지 확인합니다. 다음과 같은 파일을 찾으십시오: artifacts/t2-architect-architecture-summary.md, artifacts/t2-architect-tech-stack.md, artifacts/t2-architect-data-model.md.
  • 기능 인벤토리: 원래 애플리케이션의 모든 기능 카탈로그로, 각각 요구 사항 ID(예: REQ-001)가 할당되었습니다. 이 목록이 완전하고 정확한지 확인합니다. 를 찾습니다 artifacts/t3-pm-spec.md.
  • 대상 아키텍처 디자인: 새 애플리케이션에 대해 제안된 API 계약, 모듈 구조 및 기술 선택 사항입니다. 예를 들어 artifacts/t5-architect-api-contracts.md 및 artifacts/t5-architect-integration.md과 같은 파일을 찾습니다.

계획 아티팩트에는 다음이 포함됩니다:

  • 구현 계획: 종속성이 있는 순서가 지정된 작업 목록으로, 단계로 그룹화됩니다. 각 작업은 기능 인벤토리에서 하나 이상의 요구 사항에 다시 매핑됩니다. 를 찾습니다 artifacts/t7-teamlead-plan.md.
  • 테스트 전략: 단위 테스트, 통합 테스트 및 엔드투엔드 테스트에 대한 계획된 접근 방식입니다. 를 찾습니다 artifacts/t7-teamlead-testing-strategy.md.

에이전트는 이러한 아티팩트 생성 후 일시 중지되고 확인을 기다립니다. 이 기회를 사용하여 다음을 수행합니다.

  • 인벤토리에서 누락된 기능이 없는지 확인합니다.
  • 대상 아키텍처가 예상과 일치하는지 확인합니다.
  • 구현이 시작되기 전에 작업 우선 순위를 조정하거나 제약 조건을 추가합니다.

이 단계에서 신중하게 검토하면 구현 및 유효성 검사 단계에서 비용이 많이 드는 재작업을 방지할 수 있습니다.

빌드 및 시작 실패

변환된 애플리케이션이 컴파일 또는 시작에 실패하는 경우 다음 방법을 사용합니다.

  1. 빌드 출력 및 스택 추적에 대한 테스터 보고서 아티팩트(예 t21-tester-report.md: )를 확인합니다.
  2. 아티팩트에서 예외 유형 또는 오류 메시지를 검색하여 근본 원인을 식별합니다.
  3. 에이전트가 수정 반복을 만든 경우(예: t21.1, t21.3), 해당 아티팩트를 검토하여 어떤 변경이 시도되었는지 확인합니다.

일반적인 근본 원인으로는 레거시 클래스와 새로 생성된 클래스 간의 이름 지정 충돌, 잘못된 Spring 프로필 구성, 누락되거나 충돌하는 종속성 등이 있습니다 pom.xml. 예를 들어 레거시 컨트롤러와 최신 컨트롤러가 동일한 클래스 이름을 공유하는 경우 Spring은 시작 시 throw ConflictingBeanDefinitionException 합니다.

런타임 오류

애플리케이션이 시작되지만 API 호출에서 오류(예: 500개 또는 400개 응답)를 반환하는 경우 다음 방법을 사용합니다.

  1. 엔드포인트가 실패한 경우와 연결된 오류 메시지를 확인하기 위해 테스터 보고서의 아티팩트를 점검하십시오.
  2. 구성 문제에 대한 보안 결과 아티팩트(예: t20-security-findings.md)를 검토합니다.
  3. 생성된 엔터티 클래스 및 컨트롤러 코드에서 데이터베이스 스키마와 ORM 매핑 간의 불일치를 검사합니다.

일반적인 근본 원인으로는 주석의 @Column 데이터베이스 예약 키워드 충돌, DTO 필드 형식과 엔터티 필드 형식 간의 불일치, 요청 개체에 대한 유효성 검사 주석 누락 등이 있습니다.

품질 게이트 오류 및 반복

에이전트는 다시 아키텍처 프로세스 중에 여러 품질 게이트를 적용합니다. 게이트가 실패하면 에이전트는 자동으로 수정 작업을 만들고 유효성 검사를 다시 시도합니다. 일반적인 게이트 오류는 다음과 같습니다.

  • 아키텍처 검토: 에이전트는 구현이 디자인된 API 계약, DTO 구조 및 엔드포인트 매핑과 일치하는지 확인합니다. 오류에는 일반적으로 누락된 엔드포인트, 이름이 바뀐 필드 또는 누락된 유효성 검사 주석이 포함됩니다. 특정 결과에 대한 설계자 보고서 아티팩트(예: t19-architect-review.md)를 검토합니다.
  • 규칙 검토: 에이전트는 구현이 초기 헌법에 정의된 모든 원칙을 충족하는지 확인합니다. 일반적인 오류는 규정에서 요구할 때 브라우저 수준의 엔드 투 엔드 테스트가 누락되는 것입니다. 팀 리더 검토 아티팩트(예: t22-teamlead-review.md)를 검토하여 충족되지 않은 원칙을 식별합니다.
  • 기능 패리티 확인: 에이전트는 카탈로그된 모든 요구 사항이 구현되는지 확인합니다. 부분 승인은 특정 기능이 미완성 상태임을 의미합니다. 예를 들어, fromDate이 toDate 앞에 있는지 확인하는 교차 필드 유효성 검사가 누락되었습니다. 요구 사항별 분석을 위해 PM 승인 아티팩트(예: t23-pm-signoff.md)를 검토합니다.

에이전트가 모든 문제를 해결하지 않고 반복 제한에 도달하면 최신 아티팩트 파일을 검토하여 나머지 간격을 이해하고 수동 수정을 적용합니다.

런타임 검증 필수 조건

에이전트는 외부 도구에 종속된 선택적 런타임 유효성 검사 단계를 수행합니다. 도구를 사용할 수 없는 경우 해당 단계를 건너뜁습니다.

  • Python 설치되지 않음: 지식 그래프 단계를 건너뜁 있습니다. 에이전트는 여전히 다시 아키텍처를 수행할 수 있지만 프로젝트 구조에 대한 컨텍스트가 적을 수 있습니다. Python 3.7 이상을 설치하고 PATH에서 python3 사용할 수 있는지 확인합니다.
  • Node.js가 설치되지 않음: Playwright의 브라우저 수준 엔드 투 엔드 테스트가 생략됩니다. 에이전트는 Maven을 통해 통합 테스트를 계속 실행합니다. Node.js 18 이상을 설치하여 브라우저 테스트를 사용하도록 설정합니다.
  • Docker를 사용할 수 없음: 런타임 유효성 검사(컨테이너에서 애플리케이션을 시작하고 요청을 제공하는지 확인)를 건너뜁니다. 에이전트는 대신 단위 및 통합 테스트에 의존합니다. Docker Desktop을 설치하고 시작하여 이 단계를 사용하도록 설정합니다.

제한점

다음 제한 사항에 유의하세요.

  • 깊이 결합된 레거시 프레임워크가 있는 복잡한 프로젝트에는 여러 반복이 필요할 수 있습니다.
  • 변경 내용을 커밋하기 전에 생성된 코드를 신중하게 검토해야 합니다.

피드백 제공하기

다시 아키텍처 기능에 대한 피드백이 있는 경우 github-copilot-appmod 리포지토리에서 문제를 생성하거나 GitHub Copilot 현대화 피드백 양식 사용합니다.

참고하십시오

Java용 GitHub Copilot 현대화 개요

  • Last updated on