개발 에이전트 기능 development-agentic-capabilities
Adobe Experience Manager(AEM) as a Cloud Service의 Development Agentic 기능은 공동 작업자 채팅과(와) 협력하여 기존 AEM Java 스택 개발자 및 관리자가 코드를 보다 효율적으로 만들고, 디버깅하고, 배포하고, 최적화할 수 있도록 지원합니다.
사용 사례 use-cases
다양한 사용 사례를 다룹니다.
Cloud Manager 파이프라인 관리 aem-cloud-manager-pipeline-management
AEM Cloud Manager 파이프라인 관리 스킬을 사용하면 Cloud Manager 화면 간에 전환하여 필요한 정보나 컨트롤을 찾지 않고도 자연어를 통해 직접 CI/CD 파이프라인을 관리할 수 있습니다. 파이프라인을 나열 및 생성하고, 실행을 시작 또는 취소하며, 상태 및 내역을 확인할 수 있습니다(모두 단일 대화에서).
문제가 발생하면 스킬은 상태 검사를 넘어 단계 지표, 로그, 아티팩트 및 실행 실패를 검색할 수 있으므로 원시 로그 파일을 직접 다운로드하고 검색하지 않고도 문제를 진단할 수 있습니다. 또한 파이프라인 변수 관리, 캐시된 아티팩트 무효화 및 파이프라인 설정 조정과 같은 일상적인 파이프라인 구성을 처리하므로 UI를 통해 여러 번 클릭해야 했던 일상적인 유지 관리 작업을 단일 요청으로 수행할 수 있습니다.
실행이 실패한 이유를 확인하려면 AEM Cloud Manager 파이프라인 문제 해결을 참조하세요.
AI는 실수를 할 수 있으므로 제안된 조치를 적용하기 전에 검토해야 하며, 특히 파괴적인 작업을 위해 그러해야 합니다.
"기본 프로그램에 어떤 파이프라인이 있습니까?"에 대한 파이프라인 나열
“에 대한 새 전체 스택 파이프라인을 만듭니다. 개발 환경에 대한 코드 품질 파이프라인을 설정합니다.”
“파이프라인 67890 실행 시작”
“실행 중인 코드 검사 단계를 중지하여 실행을 12345.”
“개발 파이프라인의 마지막 5개 실행을 표시합니다.”
“코드 검사 단계가 마지막 실행에서 얼마나 걸립니까?”
“실패한 코드 검색 단계에 대한 로그를 가져옵니다.”
“에서 생성된 아티팩트를 보여 줍니다. 마지막 실행에서 빌드 아티팩트는 어디에서 다운로드할 수 있습니까?”
“이번 주 12345 프로그램에 대해 실패한 모든 실행을 나열합니다.”
“파이프라인 67890에서 API_ENDPOINT 변수 업데이트”
“다음 실행 전에 빌드 캐시를 지우십시오.”
“릴리스하려면 파이프라인 67890 트리거 분기를 변경하십시오.”
AEM Cloud Manager 파이프라인 문제 해결 aem-cloud-manager-pipeline-troubleshooting
AEM Cloud Manager 파이프라인 문제 해결 스킬을 사용하면 원시 로그 파일을 직접 다운로드하여 검색하지 않고도 파이프라인 실행이 실패한 이유를 찾을 수 있습니다. 파이프라인 이름 또는 실행 ID로 실패한 실행을 참조하면 스킬은 Cloud Manager에서 실패를 확인하고 실패한 단계를 식별하며 무엇이 잘못되었는지, 그 이유와 다음 작업을 설명합니다. 요청이 둘 이상의 파이프라인과 일치하는 경우 스킬은 계속하기 전에 하나를 선택하라는 메시지를 표시합니다.
이 기능은 전문 에이전트로 구현되므로 Coworker 사용자 정의 인터페이스에 나열된 기술로 시각적으로 표시되지 않습니다.
이 기술은 다음 파이프라인 및 단계에서 오류를 조사합니다.
- 전체 스택 배포 및 코드 품질 파이프라인의 빌드 및 단위 테스트 단계 및 코드 스캔 단계입니다.
- Dispatcher 구성 유효성 검사 오류와 같은 웹 계층 구성 파이프라인에서 빌드 및 코드 품질 오류가 발생했습니다.
- 잘못된 CDN 구성과 같이 구성 파이프라인에서 배포 오류가 발생했습니다.
전체 스택 파이프라인의 배포 단계와 같은 다른 단계의 실패의 경우, 이 기술은 실패한 단계를 진단하지 않고 보고합니다. 이 경우 로그 액세스 및 다운로드에 설명된 대로 로그를 검사하거나 Adobe 지원에 문의하십시오.
프롬프트를 작성하지 않고 문제 해결을 시작할 수도 있습니다. Cloud Manager에서 실패한 파이프라인 실행에 대한 AI 문제 해결 또는 Experience Manager 홈 페이지의 실패한 파이프라인 위젯을 클릭하여 해당 실행이 이미 참조된 Coworker를 엽니다. Cloud Manager에서 실패한 파이프라인 문제 해결 및 실패한 파이프라인 위젯 문제 해결을 참조하십시오.
AI는 실수를 할 수 있으므로 행동하기 전에 진단을 검토하십시오.
“주 프로그램에서 실패한 마지막 파이프라인 문제를 해결하도록 도와주세요”
“프로그램 1234567의 개발 파이프라인 실행 문제 해결 12345”
“에서 내 웹 계층 빌드 오류를 디버깅하십시오. 프로그램 12345에서 구성 파이프라인 배포가 실패한 이유는 무엇입니까?”
권한 pipeline-troubleshooting-permissions
AEM Cloud Manager 파이프라인 문제 해결 기술을 사용하려면 Cloud Manager에서 개발자 또는 프로그램 관리자 역할이 있어야 합니다. 역할 기반 권한을 참조하세요.
Cloud Manager에서 실패한 파이프라인 문제 해결 troubleshoot-from-cloud-manager
실패한 파이프라인 실행에서 시작하는 것이 문제를 해결하는 가장 빠른 방법입니다. 동료가 실행을 컨텍스트로 수신하므로 프롬프트를 작성할 필요가 없습니다.
-
Adobe Experience Cloud에 로그인한 다음 Experience Manager을 엽니다.
note tip TIP Cloud Manager을 열지 않고 문제를 해결하려면 이 페이지의 동료에게 묻기 상자에 실패한 파이프라인 문제 해결과 같은 메시지를 입력하십시오. -
왼쪽 레일에서 Cloud Manager을 클릭한 다음 프로그램을 선택합니다.
-
프로그램 개요 페이지의 파이프라인 카드에서 실패한 파이프라인을 클릭합니다.
-
파이프라인 실행 페이지에서 파이프라인 이름 옆에 실패 상태와 실패한 단계를 확인합니다.
-
AI 문제 해결을 클릭합니다. 단추가 페이지의 오른쪽 상단 모서리와 실패한 단계의 단계 오류 상자에 나타납니다.
동료는 프롬프트에서 실패한 실행을 참조하여 페이지 오른쪽의 패널에서 열립니다. Coworker는 실패한 단계를 식별하고 근본 원인을 설명하며 수동으로 적용할 수 있는 수정 사항을 제안합니다.
-
진단을 검토하십시오. 추가 질문을 하거나 자세한 내용을 요청하려면 동료에게 질문하기 상자에 입력하세요.
실패한 파이프라인 위젯 문제 해결 troubleshoot-from-experience-home-widget
Experience Manager 홈 페이지에는 프로그램 전체의 파이프라인 오류를 나열하는 실패한 파이프라인 위젯이 포함되어 있으므로 먼저 Cloud Manager을 열지 않고도 문제 해결을 시작할 수 있습니다. 각 행에는 파이프라인 이름, 마지막 실행 날짜 및 시간, 기간, 실패한 단계가 AI 문제 해결 단추와 함께 표시됩니다.
-
Adobe Experience Cloud에 로그인하고 Experience Manager을 연 다음 실패한 파이프라인 위젯으로 스크롤합니다.
-
조사할 파이프라인 행에서 AI 문제 해결을 클릭합니다.
동료가 실행 실패를 참조한 상태로 열리고 분석을 시작하여 근본 원인을 파악하고 수정 사항을 제안합니다.
-
진단을 검토하십시오. 추가 질문을 하거나 자세한 내용을 요청하려면 동료에게 질문하기 상자에 입력하세요.
AEM Cloud Manager 환경 관리 aem-cloud-manager-environment-management
AEM Cloud Manager 환경 관리 스킬을 사용하면 Cloud Manager의 UI 화면을 탐색하여 적절한 프로그램, 환경 또는 구성 패널을 찾지 않고도 자연어를 통해 Cloud Manager 환경을 관리할 수 있습니다. 환경을 나열하고 특정 환경에 대한 세부 정보를 가져올 수 있으며 프로젝트가 변경될 때 환경을 생성, 복제 또는 삭제할 수 있습니다.
일상적인 환경 유지 관리도 다룹니다. 환경 변수 관리, 디버깅을 위한 로그 다운로드, 깨끗한 슬레이트가 필요할 때 신속한 개발 환경(RDE) 재설정, 지역 배포 구성(Cloud Manager을 통한 여러 번의 방문 대신 단일 대화로 모두). 롤백해야 할 사항이 있는 경우 스킬은 백업에서 환경을 복원할 수도 있습니다.
AI는 실수를 할 수 있으므로 제안된 조치를 적용하기 전에 검토해야 하며, 특히 파괴적인 작업을 위해 그러해야 합니다.
“기본 프로그램의 모든 환경 표시”
"내 프로덕션 환경의 상태가 어떻게 됩니까?“에서 스테이징 환경에 대한 세부 정보를 가져옵니다.”
“에 대한 새 개발 환경을 만듭니다. 테스트할 스테이지 환경을 설정합니다.”
“프로그램 12345에 대한 스테이징 환경을 복제합니다.”
"사용되지 않은 테스트 환경을 제거합니다.“에서 이전 개발 환경을 삭제합니다.”
“내 스테이징 환경에서 API_BASE_URL 변수 설정”
“스테이징 환경에 대한 디스패처 로그를 다운로드합니다.”
“프로그램 12345에 대한 신속한 개발 환경을 재설정합니다.”
"내 프로덕션 환경에 대한 지역 배포를 표시합니다.“에 대한 새 지역 배포를 추가합니다.”
“스테이지 환경에 사용할 수 있는 백업을 표시합니다.”
AEM Cloud Manager 프로그램 관리 aem-cloud-manager-program-management
AEM Cloud Manager 프로그램 관리 스킬을 사용하면 Cloud Manager의 프로그램 목록을 탐색하여 원하는 프로그램을 찾는 대신 자연어를 통해 Cloud Manager 프로그램을 검색하고 관리할 수 있습니다. 액세스 권한이 있는 모든 프로그램을 나열하고, 특정 프로그램에 대한 세부 정보를 가져와서, 더 이상 필요하지 않을 때 프로그램을 삭제할 수 있습니다.
프로그램은 파이프라인과 환경이 아래에 있는 상위 항목이므로 이 기술은 관련 리소스에 대한 빠른 진입점 역할도 합니다. 먼저 프로그램 ID를 직접 추적하지 않고 주어진 프로그램에 연결된 파이프라인 또는 환경을 표시하도록 요청할 수 있습니다.
AI는 실수를 할 수 있으므로 제안된 조치를 적용하기 전에 검토해야 하며, 특히 파괴적인 작업을 위해 그러해야 합니다.
“액세스 권한이 있는 프로그램은 무엇입니까?”
“기본 프로그램에 대한 정보 표시”
“이전 데모 프로그램 제거”
“기본 프로그램에 대한 파이프라인을 나열합니다.”
“기본 프로그램에 있는 환경 표시”
AEM Cloud Manager 릴리스 관리 aem-cloud-manager-release-management
AEM Cloud Manager 릴리스 관리 스킬을 사용하면 Cloud Manager 설정을 끝까지 탐색하여 올바른 화면을 찾지 않고도 Adobe이 자동 유지 관리 업데이트를 프로그램에 적용하는 시기를 제어할 수 있습니다. 현재 업데이트 일정을 확인하고, 매일 Adobe이 업데이트를 일시 중지하는 반복 시간인 매일 방해 받지 않는 시간 창을 설정하고, 환경에 변경 사항을 적용하지 않으려는 경우 제품 출시 또는 휴일 동결과 같은 이벤트에 대해 여러 날의 업데이트 금지 기간을 예약할 수 있습니다.
계획이 변경되면 일정이 잡힌 대로 쉽게 무업데이트 기간을 제거할 수 있습니다. 또한 이 기술은 Adobe의 글로벌 코드 동결 기간을 보여 줄 수도 있습니다. — windows Adobe은 이미 계획된 유지 관리 제외를 위해 차단되어 있습니다. — 따라서 일정을 잡기 전에 미리 어떤 날짜가 이미 사용 제한인지 알 수 있습니다.
이 기술은 예약 오류를 방지하는 데에도 도움이 됩니다. 요청을 안내하면 부동 365일 기간 내의 최대 3개의 업데이트 불가 기간, 기간 간의 필수 1주 간격, Adobe의 계획된 유지 관리 제외 창 등 적용되는 제한에 플래그가 지정됩니다. 구성 실패 후 제한을 검색하는 대신 동일한 대화에서 유효한 일정에 도달합니다. 이 접근 방식은 자동 유지 관리 업데이트로부터 중요한 비즈니스 창을 보호하고 앞뒤와 잘못된 구성을 줄입니다. 업무 중지 시간 및 무료 기간 업데이트를 참조하세요.
AI는 오류를 범할 수 있으므로 제안된 작업을 적용하기 전에 검토하십시오. 잘못 예약되거나 제거된 업데이트 불가 기간이 사용자가 보호하려는 기간 동안 업데이트가 랜딩될 수 있으므로 업데이트-예약 변경 사항에 특히 적합합니다.
“프로그램 12345 업데이트 일정 표시”
“자동 중지 시간 창을 업데이트하여 한 시간 앞당겨 시작하십시오.”
“실행 주간에 프로그램 12345 업데이트 차단, 3월 3~10일”
“다음 주로 예약한 일시 중단 기간 취소”
“Adobe의 계획된 유지 관리 제외 기간 표시”
AEM 워크플로 검사 aem-workflow-inspection
AEM 워크플로우 검사 스킬을 사용하면 일반 언어로 워크플로우 활동을 확인할 수 있습니다. 워크플로우 사용자 인터페이스를 열지 않고 실행 중인 워크플로우, 받은 편지함에서 대기 중인 워크플로우 또는 워크플로우가 실패한 이유를 동료에게 질문합니다.
특정 워크플로우를 조회하고 사용 가능한 워크플로우 모델을 탐색하며 문제를 해결할 때 후속 질문을 할 수 있습니다. 이 스킬은 읽기 전용입니다. 이 스킬은 발생한 상황을 파악하고 이해하는 데 도움이 되지만, 워크플로우를 시작, 변경 또는 중지하는 것은 아닙니다.
AI는 실수를 할 수 있으므로 결과를 검토하여 조치를 취하십시오.
“일시 중단된 워크플로가 있습니까?”
“상태별 워크플로를 빠르게 분류합니다.”
“검사한 워크플로우에서 발견된 오류를 요약합니다.”
“해당 목록의 두 번째 워크플로에 대한 오류를 설명합니다.”
“마지막으로 확인한 이후 상태 또는 현재 단계가 변경되었습니까?”
“누가 시작했으며 언제, 어떤 작업 항목 정보를 사용할 수 있습니까?”
“작업이 아닌 워크플로 단계만 표시합니다.”
“편집 검토(Editorial Review)라는 이름의 모델을 사용할 수 있습니까?”
AEM Dispatcher Insights aem-dispatcher-insights
AEM Dispatcher 인사이트 스킬은 Dispatcher 및 Apache 웹 계층이 AEM as a Cloud Service에서 요청을 처리하는 방법을 이해하는 데 도움이 됩니다. 동료에게 요청하여 캐시 성능을 분석하고, 트래픽 및 게재 문제를 조사하고, 로그 파일을 수동으로 검색하지 않고도 보안 구성을 검토할 수 있습니다. 사용 가능한 데이터가 지원하는 경우 Coworker는 결과를 차트 및 요청 시간 시각화로 제시할 수 있습니다.
환경별 분석을 위해 조사할 환경 및 기간(7일 로그 창 내)을 식별합니다. 현재 스킬은 소스 저장소에 액세스하지 않으므로 구성 및 코드 검토를 위해 관련 파일을 붙여넣거나 업로드합니다. 동료는 연결 가능한 URL을 검사하여 응답 상태, 헤더 및 리디렉션을 확인할 수도 있습니다.
이러한 주제에서 변경 사항을 제안하고, 잠재적인 영향을 설명하고, 유효성 검사 및 롤백 지침을 제공하도록 Coworker에 요청할 수 있습니다. 변경 사항을 적용하고 배포한 후 Coworker에 사용 가능한 로그 또는 라이브 URL 동작을 다시 평가하도록 요청하십시오.
현재 스킬은 저장소를 수정하거나, 변경 사항을 배포하거나, 콘텐츠를 게시 또는 게시 취소하거나, 캐시를 지우지 않습니다. CDN 캐시 삭제, 에지 트래픽 필터 규칙 작성 및 Adobe 관리 인프라 설정에 대한 변경 사항은 범위를 벗어납니다.
AI는 실수를 할 수 있으므로 결과를 검토하고 제안된 변경 사항을 적용한 후 조치를 취합니다.
캐싱 및 성능 dispatcher-caching-performance
캐시 효율성을 이해하고, 느리거나 오래된 응답을 조사하고, 게시 요청을 줄일 수 있는 기회를 식별합니다.
“최신 배포 후 캐시 성능이 저하되었습니다. 로그 증거를 최근 배포 및 내가 공유한 구성 차이와 비교합니다.”
“이러한 GraphQL 지속 쿼리 응답이 캐시되지 않는 이유를 검토하십시오.”
“검색 또는 페이지 매김을 중단하지 않고 무시할 수 있는 매개 변수는 무엇입니까?”
“공유한 구성을 사용하여 버전 관리된 클라이언트 라이브러리 및 DAM 자산에 캐싱 정책을 권장합니다.”
“statfileslevel 또는 gracePeriod를 변경하면 무효화에 어떤 영향을 미치며, 페이지 캐시를 언제 새로 고쳐야 합니까?”
“대표적인 페이지 요청의 경우 관찰된 Dispatcher 및 게시 처리 단계와 사용 시간이 어디에 있는지 확인하십시오.”
“이 페이지가 사이트 맵에 포함되어 있는지 확인하고 사이트 맵 범위가 준비에 어떻게 영향을 주는지 설명합니다.”
트래픽 및 요청 처리 dispatcher-traffic-request-handling
Dispatcher에 도달하는 트래픽을 이해하고 요청이 필터링, 라우팅 및 제공되는 방법을 조사합니다.
“캐시에서 자동화된 트래픽을 흡수합니까, 아니면 게시 요청이 증가합니까?”
“오늘의 403 및 404 응답을 설명하는 경로는 무엇이며, 어떤 증거가 이러한 응답을 설명하는 데 도움이 됩니까?”
“규칙 순서 지정이 GraphQL 엔드포인트에 대한 요청에 어떻게 영향을 주는지 설명합니다.”
“새 도메인에 대한 요청이 잘못된 사이트에 제공되고 있습니다. 공유한 호스트 별칭 및 팜 매핑을 확인합니다.”
“이 vanity URL은 게시에서 작동하지만 Dispatcher을 통해 404를 반환합니다. 무엇을 확인해야 합니까?”
“clientheaders.any에 속한 헤더와 vhost 또는 cache 구성에서 처리되는 헤더를 설명합니다.”
“프로덕션 로깅을 변경하지 않고 스테이지에서 Dispatcher을 활성화하거나 디버그 로깅을 다시 작성하려면 어떻게 해야 합니까?”
보안 dispatcher-security
Coworker에 전반적인 보안 검토를 요청하거나 고객 제어 Dispatcher 구성 및 관련 AEM 코드의 특정 문제에 집중하십시오.
“필요한 요청을 보존하는 동안 이 끝점의 허용 규칙을 좁힐 수 있습니까?”
“권장하는 콘텐츠 보안 정책 변경의 보안 이점 및 잠재적인 응용 프로그램 영향에 대해 설명합니다.”
“인증된 콘텐츠를 캐시할 때 무단 액세스를 방지하기 위해 확인해야 하는 사항은 무엇입니까?”
“공유한 Dispatcher 규칙과 함께 이 OSGi CSRF 및 CORS 구성을 검토하십시오.”
“심각도별로 검색 결과를 우선 순위를 지정하고 AEM as a Cloud Service에서 제어하는 내에서 개선 사항을 추천합니다.”