관리형 에이전트 실행

관리형 에이전트 실행을 사용하면 Archyl에서 직접 자율 AI 에이전트를 배포할 수 있습니다. 작업을 지정하고, 에이전트의 동작 방식을 정하는 프로필을 고르고, MCP 커넥터를 통해 외부 서비스에 연결하고, 반복 스케줄을 설정하면 에이전트가 전체 아키텍처 컨텍스트를 활용하여 코드베이스에서 작업합니다.

사이드바에서 에이전트 허브 → 실행 목록으로 이동해 실행을 관리하고, 에이전트 허브 → 프로필에서 에이전트의 동작 방식을 정의하거나, 에이전트 허브 → 스케줄에서 반복 자동화를 설정할 수 있습니다.

개요

관리형 실행은 단일 에이전트 실행 단위입니다. 에이전트는 다음과 같이 동작합니다:

1. 클론 — 프로젝트의 리포지토리를 에이전트 워커의 새 작업 공간에 복제합니다
2. 수신 — 아키텍처 컨텍스트(C4 모델, ADR, 적합성 규칙, API 계약, 기술 스택)와 함께 작업 세션 브리핑을 전달받습니다. 브리핑에는 작업이 관련된 요소, 이전 세션이 그 요소에 대해 알아낸 내용, 사전 점검(preflight) 판정이 담겨 있습니다
3. 실행 — 정의된 작업을 수행하며, 프로필이 허용하는 범위 안에서 도구를 호출하고 의사 결정을 내립니다
4. 게시 — 코드 변경 사항을 풀 리퀘스트로 게시하고, 수행한 모든 작업에 대한 완전한 추적 기록을 반환합니다

실행은 수동으로(일회성) 또는 스케줄을 통해 자동으로 트리거할 수 있습니다.

실행 시작하기

1. 에이전트 허브 → 실행 목록으로 이동합니다
2. 드롭다운에서 프로젝트를 선택합니다
3. 새 실행을 클릭합니다
4. 프로필을 선택합니다
5. 작업 설명을 작성합니다 (예: "오래된 의존성을 확인하고 요약을 작성하세요")
6. 필요에 따라 커넥터를 연결합니다 (아래 참조)
7. 실행 시작을 클릭합니다

에이전트가 즉시 작업을 시작합니다. 실행 상세 페이지에서 실시간으로 진행 상황을 모니터링할 수 있습니다.

에이전트 프로필

프로필은 에이전트의 동작 방식을 재사용할 수 있게 정의한 것입니다. 모든 실행과 모든 스케줄은 프로필을 하나씩 사용합니다. 처음 방문하면 Archyl이 조직에 backend-fixer 프로필을 만들어 두며, 추가 프로필은 에이전트 허브 → 프로필에서 만들 수 있습니다.

프로필을 삭제해도 그 프로필로 수행된 실행 기록은 유지됩니다. 해당 프로필을 사용하던 스케줄은 일시 중지되고 프로필 삭제됨으로 표시됩니다. 스케줄을 재개하려면 스케줄에서 다른 프로필을 선택하세요.

스킬

스킬은 Archyl이 관리하는 플레이북으로, 에이전트가 실제로 사용할 수 있는 도구에 맞춰 계속 갱신됩니다. 지시 사항을 프롬프트에 복사하는 대신 프로필별로 활성화하세요.

알 수 없는 스킬이나 잘못된 허용 도구 패턴이 포함된 프로필은 저장 시 거부됩니다.

기본 backend-fixer 프로필에는 Architecture memory, Conformance first, Decision records가 활성화되어 있습니다.

실행 상세 페이지

각 실행에는 다음 정보를 표시하는 상세 페이지가 있습니다:

이벤트 피드는 각 작업에 대해 확장 가능한 카드를 표시합니다:

• 도구 호출 — 도구 이름, 입력 매개변수, 출력을 표시합니다. 각 카드에는 해당 도구가 어떤 커넥터에서 왔는지 나타내는 소스 레이블이 표시됩니다 (예: github, archyl, linear).
• 메시지 — 에이전트의 추론 과정과 의사 결정 내용입니다.
• 결과 — 실행 결과, 토큰 사용량, 풀 리퀘스트, 에이전트가 변경한 파일입니다.
• 오류 — 빠른 식별을 위해 강조 표시됩니다.

실행 중인 에이전트에게 지시하기

실행이 진행되는 동안 지시 입력란에 메시지를 입력하면 실행을 취소하지 않고 에이전트의 방향을 바꿀 수 있습니다 ("마이그레이션은 건너뛰고 핸들러에 집중해"). 메시지는 즉시 대기열에 추가되어 에이전트의 다음 단계에서 대화에 삽입되며, 에이전트가 메시지를 받으면 피드에 조정 메시지가 에이전트에 전달되었습니다라는 문구가 표시됩니다.

실행이 도중에 멈춘 경우

실행이 실패하거나, 비용 또는 시간 한도에 도달하거나, 반복 횟수를 모두 소진하더라도 이미 한 작업은 버려지지 않습니다. Archyl은 그 작업을 실행이 멈춘 이유를 설명하는 초안 풀 리퀘스트로 게시합니다. 자세한 내용은 아래 풀 리퀘스트를 참고하세요. 사용자가 취소한 실행은 아무것도 게시하지 않습니다.

안정성 보장

• 응답 없는 워커를 감지합니다. 에이전트 워커는 10초마다 응답을 보냅니다. 워커가 3분 동안 응답하지 않거나 시간 한도를 10분 넘겨서도 계속 실행 중인 실행은 자동으로 failed 처리되고, 차지하던 자리가 해제됩니다.
• 멈춘 실행이 자리를 차지하지 않습니다. 10분 안에 어떤 에이전트 워커도 가져가지 않은 실행은 실패하며, 사람의 답변을 1시간 10분 넘게 기다린 실행도 마찬가지입니다.
• 자격 증명은 실행보다 오래 남지 않습니다. 각 실행은 수명이 짧은 전용 Archyl API 키를 발급받으며, 이 키는 실행이 끝나는 즉시 폐기됩니다.
• 취소 요청은 반드시 에이전트에 닿습니다. 직접 보낸 중지 요청이 워커에 닿지 않았더라도, 취소된 실행은 다음 응답 시점에 멈춥니다.

작업 세션과 협업

모든 실행은 Archyl 작업 세션 안에서 진행됩니다. Archyl Harness가 로컬 코딩 에이전트에 제공하는 것과 같은 프로토콜입니다. 세션을 열고 닫는 것은 플랫폼이며, 에이전트가 세션을 관리하는 일은 없습니다.

실행의 작업 세션

실행이 시작되면 Archyl은 작업이 다루는 아키텍처 요소를 대상으로 세션을 엽니다. 해당 요소에 리스를 잡고, 프리플라이트 게이트 판정(allow, warn, deny)을 계산하며, 관련된 결정, 가드레일, 메모리를 에이전트의 브리핑에 넣습니다. 판정은 이벤트 피드에 게이트 이벤트로 표시됩니다.

다른 에이전트의 작업 존중

다른 에이전트의 작업 존중은 프로필의 협업 항목에 있는 설정이며 기본값은 꺼짐입니다. 켜면 세션이 배타적으로 열립니다.

• 다른 에이전트가 요소를 점유한 경우. Claude Code 같은 코딩 에이전트나 다른 관리형 실행이 같은 요소에 리스를 잡고 있으면 실행이 거부됩니다. 거부 사유에는 누가 그 요소에서 작업 중인지 표시됩니다.
• 게이트가 경고만 하는 경우. 예를 들어 error 수준 가드레일이 적용되면 실행은 승인 대기 중 상태로 기다리며, 이때 동시 실행 슬롯은 차지하지 않습니다. 실행 페이지에는 사유와 함께 승인하고 시작, 실행 취소 버튼이 표시됩니다.

승인하면 게이트를 다시 확인하므로, 그사이에 생긴 충돌이 있으면 실행은 여전히 거부됩니다. 24시간 안에 아무도 승인하지 않은 실행은 취소됩니다.

설정이 꺼져 있으면 게이트 판정과 관계없이 실행이 시작되고, 에이전트는 브리핑에서 사유를 확인합니다.

파일 쓰기 Guard

에이전트가 저장소에서 작업할 때는 프로젝트에 연결된 저장소든 GitHub 커넥터로 연 저장소든, 모든 write_file, edit_file 호출은 변경이 반영되기 전에 프로젝트의 적합성 규칙과 대조됩니다.

검사 자체가 실패하면 쓰기는 반영됩니다. Guard는 자신의 오류 때문에 에이전트를 막지 않습니다. 이 동작은 로컬 코딩 에이전트용 Guard 훅과 같으며, Harness 가이드에 설명되어 있습니다.

작업 세션 결과

에이전트는 끝내기 전에 결과를 보고합니다. 요약, 결정, 후속 작업, 그리고 참고한 메모리가 포함됩니다. 실행이 끝나면 Archyl은 다음을 수행합니다.

1. 변경된 파일을 세션에 연결해, 실제 작업이 어떤 리스 대상 요소에 이루어졌는지 파악합니다
2. 세션을 닫고 요약을 해당 요소의 메모리로 저장합니다
3. 결정을 프로젝트 메모리로 기록하고, 검토용 아키텍처 변경 요청 초안을 엽니다. 결정은 성공한 실행만 기록합니다

실행 페이지에는 작업 세션 결과 카드가 표시되며, 요약, 결정, 후속 작업, 관련 요소, 변경 요청 링크가 담깁니다. 다른 세션이 점유한 요소에는 다른 작업 세션이 점유 중 표시가 붙습니다.

실행을 실시간으로 따라가기

실행 페이지에는 두 가지 보기가 있습니다. 이벤트 피드인 활동과, 에이전트가 쓴 파일을 보여 주는 변경 사항입니다. 에이전트에게 사용자가 필요할 때는 그 위에 배너가 나타나 무엇을 기다리는지(계획 검토를 기다리는 중 또는 에이전트에게 질문이 있습니다) 알려 주고 해당 위치로 안내합니다.

계획

에이전트는 무엇이든 변경하기 전에 계획을 공유합니다. 계획은 한 문장 요약과 최대 12개의 구체적인 단계로 이루어집니다. 실행 페이지 상단의 계획 패널은 이를 체크리스트로 보여 줍니다. 에이전트는 각 단계를 진행 중, 완료 또는 건너뜀으로 표시하고 때로는 짧은 메모를 덧붙이며, 패널에는 현재 단계와 진행률(3/7)이 표시됩니다.

계획 먼저 검토는 프로필의 협업 항목에 있는 설정이며 기본값은 꺼짐입니다. 켜면 에이전트는 무엇이든 변경하기 전에 검토를 기다립니다.

1. 패널이 계획 검토로 바뀝니다. 단계 이름을 바꾸고 세부 내용을 추가할 수 있으며, 단계를 추가, 삭제하거나 순서를 바꿀 수 있습니다.
2. 계획 승인(계획을 수정했다면 수정한 계획 승인)을 누르면 에이전트가 작업을 진행합니다. 수정한 버전이 에이전트가 따르고 체크리스트가 추적하는 계획이 됩니다.
3. 변경 요청을 누르면 피드백이 전달됩니다. 에이전트는 계획을 수정해 검토할 새 리비전을 제안합니다. 이전 리비전은 피드에 남습니다.

계획이 승인되기 전까지 에이전트는 읽을 수는 있지만 아무것도 변경할 수 없습니다. 파일 쓰기와 함께 생성·수정·삭제·연결·가져오기·푸시·병합을 수행하는 모든 도구(Archyl과 모든 커넥터에 해당, 예: linear__create_issue)가 거부되며, remember도 거부됩니다. 에이전트에게는 검토를 기다리라는 안내가 전달됩니다.

질문

요구 사항이 모호하거나, 뚜렷한 정답이 없는 트레이드오프가 있거나, 파괴적인 작업이 필요한 경우처럼 사람의 결정이 필요하면 에이전트가 질문합니다. 질문은 피드 위에 표시되며, 에이전트가 제안한 답이 있으면 추천 답변이 함께 나오고, 자유롭게 답할 수 있는 입력란도 제공됩니다(Cmd/Ctrl + Enter로 전송). 프로젝트를 편집할 수 있는 사람이라면 누구나 답할 수 있으며, 누가 답했는지는 피드에 기록됩니다.

에이전트는 실행 한 번에 최대 5개의 질문을 할 수 있으며, 직접 찾아볼 수 있는 내용은 절대 묻지 않도록 지시받습니다.

사용자를 기다리는 동안

에이전트가 계획 검토나 답변을 기다리는 동안 실행에는 응답 대기 중이 표시되고, 실행 목록에서는 승인 대기 중 상태로 보류된 실행과 함께 조치 필요 아래에 나열됩니다.

• 대기 시간은 실행의 시간 한도에 포함되지 않습니다. 기다린 시간만큼 마감 시각이 뒤로 밀립니다. 실행은 동시 실행 자리를 계속 차지합니다.
• 1시간 안에 아무도 답하지 않은 질문: 에이전트는 자체 판단으로 작업을 계속하고, 자신이 세운 가정을 결과에 밝힙니다.
• 1시간 안에 아무도 검토하지 않은 계획: 실행은 아무것도 변경하지 않은 채 실패합니다.

에이전트가 작업하는 곳

에이전트는 리포지토리의 클론인 작업 공간에서 코드를 읽고 변경합니다.

• 프로젝트에 연결된 리포지토리: 실행이 시작될 때 Archyl이 클론합니다.
• 연결된 리포지토리 없음, GitHub 커넥터 연결됨: 에이전트가 파일을 건드리기 전에 작업 대상 리포지토리를 커넥터의 자격 증명으로 직접 클론합니다. GitHub에서 호스팅하는 MCP 서버(api.githubcopilot.com)만 지원됩니다. 커넥터는 Authorization: Bearer 헤더로 인증해야 하며, 해당 토큰에는 리포지토리 접근 권한이 있어야 합니다.

작업 공간이 열린 뒤에는 에이전트가 그곳에서만 파일을 변경합니다. 커넥터 도구로 파일을 푸시하거나 풀 리퀘스트를 여는 것은 거부됩니다. 그래서 모든 변경이 Guard를 거치고, 변경 사항 보기에 표시되며, 하나의 풀 리퀘스트로 모입니다.

변경 사항

변경 사항에는 에이전트가 쓰는 모든 파일이 쓰는 즉시 추가됨, 수정됨 또는 차단됨으로 표시되며, 파일별 및 실행 전체의 추가·삭제된 줄 수도 함께 나옵니다. 파일을 선택하면 각 쓰기가 무엇을 바꿨는지 볼 수 있습니다.

• Guard가 거부한 쓰기는 차단됨으로 표시됩니다. diff에는 에이전트가 쓰려고 한 내용과 위반한 규칙이 나타납니다. Guard가 경고만 한 쓰기는 그대로 반영되며, 파일에 경고가 표시됩니다.
• 긴 diff는 600줄에서 잘리고, 128 KB를 넘는 파일은 diff 없이 표시됩니다.

줄에 코멘트 달기

에이전트가 작업하는 동안 diff를 리뷰할 수 있습니다. 변경 사항에서 줄 번호를 클릭해 그 줄에 코멘트를 작성한 다음 에이전트에게 보내기를 클릭합니다(Cmd/Ctrl + Enter). 에이전트는 파일, 줄, 그 내용을 받아 코멘트를 반영한 뒤 계획을 이어 갑니다.

• 코멘트는 해당 줄 아래에 표시되며, 에이전트가 읽기 전에는 대기 중, 읽은 후에는 전달됨으로 나타납니다. 활동에도 표시되고, 파일마다 코멘트 수가 표시됩니다.
• 추가된 줄, 변경되지 않은 줄, 삭제된 줄 모두에 코멘트할 수 있습니다. Guard가 차단한 쓰기에는 코멘트할 수 없습니다.
• 코멘트는 에이전트가 작업 중이거나 사용자를 기다리는 동안 받습니다. 실행이 끝날 때까지 대기 중인 코멘트는 전달되지 않음으로 표시됩니다.

끝난 실행에서는 코멘트가 다음 실행을 위한 메모가 됩니다. 후속 실행에 추가를 누르면 브라우저에 보관되고, 파일 목록 위의 막대(후속 실행용 코멘트 3개)에서 그 코멘트로 실행을 이어 갈 수 있습니다(이 코멘트로 이어서 실행).

풀 리퀘스트

실행이 끝나면 Archyl은 작업 공간의 변경 사항을 archyl/agent- 뒤에 실행 ID의 처음 8자를 붙인 이름의 브랜치에 커밋하고, 클론이 시작된 브랜치를 대상으로 풀 리퀘스트를 엽니다. 그 링크는 변경 사항 상단(풀 리퀘스트 열기)과 결과에 표시됩니다.

GitLab에서는 초안이 Draft: 머지 리퀘스트입니다. Bitbucket에서는 풀 리퀘스트 없이 브랜치만 푸시합니다. 파일을 하나도 변경하지 않은 실행은 아무것도 게시하지 않습니다.

풀 리퀘스트는 github.com, gitlab.com, bitbucket.org에서 열립니다. Archyl은 Git 자격 증명을 이 호스트에만 보냅니다. 자체 호스팅 Git 서버(GitHub Enterprise, 비공개 GitLab, Azure DevOps, Gitea)에 있는 리포지토리는 자격 증명 없이 클론되므로 비공개 리포지토리는 클론할 수 없고, 풀 리퀘스트도 열리지 않습니다.

실행 이어 가기

끝난 실행에는 결과와 관계없이 두 개의 버튼이 있습니다.

• 이어서 실행은 이 실행의 작업을 이어받는 새 실행을 시작합니다. 에이전트가 다음에 할 일을 작성하세요. 후속 실행용 코멘트가 한 줄에 하나씩 지시 사항에 미리 채워집니다(경로:줄 — 코멘트). 프로필은 기본적으로 원래 실행과 같으며, 커넥터를 선택할 수 있습니다.
• 다시 실행은 같은 작업과 프로필로 시작 대화 상자를 열어 처음부터 새로 실행합니다.

이어 가는 실행은 이전 실행이 무엇을 요청받았고 무엇을 했는지 알고 있습니다. 이전 실행이 게시한 브랜치에서 시작해 그 브랜치에 커밋하고, 새 풀 리퀘스트를 여는 대신 같은 풀 리퀘스트에 변경 사항을 추가합니다. 이전 실행이 풀 리퀘스트를 열지 않고 브랜치만 푸시했다면, 새 실행이 대상으로 삼을 브랜치를 대상으로 풀 리퀘스트를 엽니다. 이전 실행이 GitHub 커넥터로 저장소를 열었다면 그 브랜치로 저장소를 다시 엽니다.

• 브랜치가 더 이상 없으면(예: 병합 후 삭제된 경우) 새 실행이 시작할 브랜치, 즉 프로젝트에 연결된 브랜치나 리포지토리의 기본 브랜치에서 시작해 새 풀 리퀘스트를 엽니다. 피드에 그 사실이 표시됩니다.
• 초안 풀 리퀘스트는 초안으로 남습니다. 작업이 끝나면 리뷰 준비 완료로 표시하세요.
• Archyl 에이전트가 만든 브랜치에서만 이어 가며, 사용자의 브랜치에는 커밋하지 않습니다.

새 실행 페이지에는 원래 실행으로 가는 링크(원래 실행)가, 이전 실행에는 후속 실행으로 가는 링크(후속 실행)가 표시됩니다. 진행 중인 실행은 이어 갈 수 없습니다. 대신 그 줄에 코멘트를 다세요.

MCP 커넥터

커넥터를 사용하면 에이전트 실행에 외부 서비스를 연결할 수 있습니다. MCP (Model Context Protocol) 서버를 노출하는 모든 서비스를 연결할 수 있습니다.

지원 서비스

커넥터 생성

1. 에이전트 허브 → 커넥터로 이동합니다
2. 새 커넥터를 클릭합니다
3. 이름을 입력합니다 (예: "github")
4. MCP 서버 URL을 붙여넣습니다
5. 필요한 경우 인증 헤더를 추가합니다
6. 커넥터 생성을 클릭합니다 — Archyl이 서버를 탐색하고 사용 가능한 도구를 표시합니다

도구 네임스페이싱

커넥터가 실행에 연결되면, 해당 도구에 커넥터 이름이 접두사로 추가됩니다:

Archyl 내장 MCP 서버의 도구에는 접두사가 붙지 않습니다 (예: get_agent_context, list_conformance_rules).

이 네임스페이싱 덕분에 도구 이름 충돌이 생기지 않고, 이벤트 피드를 한눈에 훑어볼 수 있으며, 프로필의 허용 도구에서 github__* 같은 패턴 하나로 커넥터 전체를 지정할 수 있습니다.

스케줄

스케줄을 사용하면 표준 cron 표현식을 활용하여 반복 에이전트 실행을 정의할 수 있습니다.

스케줄 생성

1. 에이전트 허브 → 스케줄로 이동합니다
2. 새 스케줄을 클릭합니다
3. 프로필을 선택하고 작업 설명을 작성합니다
4. cron 표현식을 선택합니다 (프리셋 사용 가능 또는 사용자 정의 입력)
5. 필요한 경우 커넥터를 연결합니다
6. 스케줄 생성을 클릭합니다

스케줄 관리

각 스케줄에는 다음 정보가 표시됩니다:

• Cron 표현식 — 에이전트가 실행되는 시점
• 다음 실행 — 다음 실행 예정 시간
• 마지막 실행 — 마지막 실행 시간
• 상태 — 활성 또는 일시 중지, 프로필이 삭제된 경우 프로필 삭제됨

수행 가능한 작업:

• 일시 중지 — 스케줄을 삭제하지 않고 일시 중지합니다
• 재개 — 일시 중지된 스케줄을 재개합니다
• 지금 실행 — 정기 실행 주기와 관계없이 즉시 실행합니다
• 편집 — 작업 텍스트, cron 표현식 또는 연결된 커넥터를 수정합니다
• 삭제 — 스케줄을 삭제합니다

프로필이 삭제된 스케줄은 일시 중지 상태로 유지됩니다. 스케줄을 편집해 다른 프로필을 선택할 때까지 재개나 지금 실행은 거부됩니다.

스케줄 예시

아키텍처 컨텍스트

모든 관리형 실행은 자동으로 Archyl 프로젝트의 MCP 서버에 접근할 수 있습니다. 에이전트가 수행할 수 있는 작업:

• C4 모델 쿼리를 통한 시스템 경계 파악
• ADR 조회를 통한 과거 아키텍처 결정 사항 이해
• 적합성 규칙 확인을 통한 준수해야 할 패턴 파악
• API 계약 탐색을 통한 서비스 인터페이스 이해
• 기술 할당 조회를 통한 적절한 도구 선택
• 아키텍처 메모리를 통한 요소 관련 사실 조회 및 기록

이 컨텍스트는 에이전트가 작업을 시작하기 전에 주입됩니다 — 에이전트가 아키텍처를 처음부터 파악할 필요가 없습니다. 또한 각 실행은 하네스 작업 세션으로 감싸져 있어, 실행 결과가 관련 요소의 메모리로 남습니다.

AI 제공자

조직에서 자체 AI 제공자 사용을 활성화하지 않았다면 실행에는 Archyl이 관리하는 모델이 사용됩니다. BYO를 활성화하면 실행은 조직의 제공자에서 조직의 자격 증명으로 이루어집니다. 지원되는 제공자는 Anthropic, AWS Bedrock, OpenAI, 그리고 Responses API를 구현한 OpenAI 호환 엔드포인트입니다. Google Gemini로는 아직 관리형 에이전트를 실행할 수 없으며, 이 경우 Archyl 모델로 조용히 대체되는 대신 명확한 메시지와 함께 실행이 거부됩니다.

할당량 및 동시 실행

관리형 에이전트 실행은 Scale 및 Custom 플랜에서 사용할 수 있습니다. 사용량은 조직별 월간 할당량으로 추적되며, 실행 목록 및 스케줄 페이지 상단에 표시됩니다. 실행 이어 가기와 보류된 실행 승인도 실행으로 계산됩니다. BYO AI를 활성화한 조직은 수동 실행과 예약 실행 모두 할당량에서 차감되지 않습니다.

활성 실행(pending, running 또는 waiting_for_input)은 각각 조직의 동시 실행 자리를 하나씩 차지합니다. 실행이 끝나면 이유와 관계없이 그 즉시 자리가 해제됩니다.

모범 사례

• 작업 설명을 구체적으로 작성하세요 — "의존성을 확인하세요"보다 "알려진 CVE가 있는 Go 패키지를 확인하고 심각도와 함께 목록을 작성하세요"가 더 효과적입니다
• 작업마다 별도의 프로필을 두세요 — allowedTools를 list_*, get_*, read_file로 제한한 읽기 전용 리뷰어는 실수로 무언가를 수정할 수 없습니다.
• 필요한 커넥터만 연결하세요 — 각 커넥터는 에이전트 컨텍스트에 도구를 추가합니다. 도구가 적을수록 더 집중된 실행이 가능합니다.
• 수동 실행으로 먼저 테스트하세요 — 스케줄을 생성하기 전에 일회성 실행으로 작업 설명을 검증하세요.
• 적합성 규칙과 함께 활용하세요 — 먼저 가드레일을 정의한 후, Conformance first 스킬을 활성화해 실행이 이를 기준으로 자동 검증하도록 하세요.