AACWorkflow Docs

기술(Skill) 서명 및 검토

버전 관리, 체크섬 및 승인 워크플로우를 통해 기술 거버넌스를 구현하여 검토된 코드만 실행되도록 보장합니다.

기술 서명 및 검토는 사용자 정의 기술에 승인 게이트를 적용하는 보안 기능입니다. 에이전트가 기술을 사용하기 전에 작업 공간 관리자 또는 검토자의 검토와 승인을 받아야 합니다. 각 기술은 암호화적으로 서명되며 변조 감지를 위한 체크섬을 포함합니다.

기술이 검토가 필요한 이유

사용자 정의 기술은 강력합니다. 에이전트에 새로운 기능을 제공하고 종종 외부 시스템에 접근할 수 있습니다. 검토 없이:

  • 악성 코드 — 불정당한 기술이 데이터를 유출하거나 손상을 입힐 수 있음
  • 의도하지 않은 동작 — 개발자가 실수로 버그를 도입하거나 안티패턴을 만들 수 있음
  • 규정 준수 결함 — 규제 대상 팀이 프로덕션에서 실행되는 코드를 감사해야 함
  • 공급망 위험 — 기술을 레지스트리에서 가져오면 내용을 확인해야 함

기술 검토 방식

  1. 작성자가 기술을 생성하거나 편집draft 상태로 시작
  2. 작성자가 검토를 위해 제출 — 상태가 pending_review로 변경
  3. 검토자가 검사 — 코드, 파일 첨부 및 업데이트인 경우 diff 확인
  4. 검토자가 결정승인(에이전트가 사용 가능) 또는 거부(피드백 포함)
  5. 승인된 경우 — 기술이 활성화되고 에이전트가 작업에 로드 가능
  6. 나중에 편집된 경우 — 승인이 취소되고 재검토 필요

기술 생명주기

draft

새 기술 또는 승인되지 않은 편집. 에이전트는 사용할 수 없습니다. 작성자와 작업 공간 관리자만 전체 내용을 볼 수 있습니다.

pending_review

기술이 검토자의 결정을 기다리는 중. 기술 → 대기 중인 검토 대기열에 표시됩니다. 에이전트는 여전히 사용할 수 없습니다.

approved

검토자가 동의했습니다. 기술이 활성화되고 에이전트가 작업에 로드할 수 있습니다. 승인은 체크섬을 통해 정확한 콘텐츠와 암호화로 연결되어 있습니다.

rejected

검토자가 피드백과 함께 기술을 거부했습니다. 작성자가 편집해서 재제출하거나 포기할 수 있습니다. 에이전트는 사용할 수 없습니다.

revoked

기술의 내용이 승인 후 변조되었습니다(체크섬 불일치). 기술이 즉시 비활성화되고 에이전트가 로드할 수 없습니다. 이는 조사가 필요한 보안 신호입니다.

버전 관리 및 체크섬

기술을 생성하거나 편집할 때마다 AACWorkflow는:

  1. 기술 콘텐츠 및 첨부된 모든 파일의 체크섬(SHA256) 계산
  2. 체크섬을 승인과 함께 저장하여 승인이 정확한 콘텐츠에 바인딩되도록 함
  3. 검토자가 변경 사항을 볼 수 있도록 버전 히스토리 유지

에이전트가 작업 시간에 기술을 사용하려고 할 때:

  • AACWorkflow가 저장된 체크섬과 현재 콘텐츠가 일치하는지 확인
  • 체크섬이 일치하지 않으면(콘텐츠가 편집되거나 변조됨) 기술이 revoked로 표시됨
  • 에이전트가 로드할 수 없으며 보안 문제 알림을 받음

변조가 감지되었지만 방지되었습니다. 기술의 체크섬이 일치하지 않으면 에이전트가 자동으로 건너뜁니다. 이런 경우 감사 로그를 확인하세요. 데이터베이스 불일치 또는 변조 시도를 나타낼 수 있습니다.

기술 생성 및 검토를 위한 제출

기술 생성

  1. 기술 → 기술 생성으로 이동
  2. 이름, 설명 및 콘텐츠 입력
  3. 필요한 경우 파일 첨부(Python 스크립트, 데이터 파일 등)
  4. 생성 클릭

기술이 draft 상태로 시작됩니다. 당신과 작업 공간 관리자만 볼 수 있습니다.

검토를 위해 제출

  1. 기술 열기
  2. 콘텐츠 재검토
  3. 검토를 위해 제출 클릭
  4. 선택적으로 검토자에게 메시지 추가

기술이 pending_review로 이동하고 검토자 대기열에 나타납니다.

검토 전 편집

draft 또는 rejected 상태인 경우 자유롭게 편집할 수 있습니다. 편집을 클릭하고 변경 사항을 만들고 저장합니다.

기술이 승인되었고 변경이 필요한 경우:

  1. 편집 클릭
  2. 변경 사항을 만들고 저장
  3. 기술이 자동으로 pending_review로 다시 이동
  4. 새 버전이 생성되고 검토자가 변경 사항의 diff를 볼 수 있습니다

기술 검토

대기 중인 기술 보기

  1. 기술 → 대기 중인 검토로 이동
  2. 승인 대기 중인 기술 목록 보기

기술 검토

  1. 대기 중인 기술 열기
  2. 설명을 읽고 코드 검사
  3. 업데이트인 경우(버전 > 1) 차이 보기를 클릭하여 변경 사항 확인
  4. 결정:
    • 승인 — 코드가 안전하고 표준을 충족; 에이전트가 사용 가능
    • 거부 — 코드에 문제 있음; 작성자에게 피드백 제공

차이 보기

업데이트를 검토할 때 차이 보기는 다음을 표시합니다:

  • 제거된 행(빨강) — 작성자가 제거한 코드
  • 추가된 행(초록) — 새 코드
  • 컨텍스트 — 각 변경 전후 몇 줄

이를 사용하여 감지:

  • 중요 섹션의 예상치 못한 변경
  • 새로운 외부 호출 또는 의존성
  • 범위 확장 또는 기능 편향

기술 승인

  1. pending_review에서 기술 열기
  2. 승인 클릭
  3. 선택적으로 검토자 메모 추가(작성자에게 표시되고 감사 로그에 나타남)
  4. 확인 클릭

기술이 approved로 이동하고 에이전트가 즉시 사용 시작 가능합니다.

기술 거부

  1. pending_review에서 기술 열기
  2. 거부 클릭
  3. 필수 피드백 추가 — 변경 필요 사항 설명
  4. 확인 클릭

기술이 rejected로 이동합니다. 작성자가 피드백을 보고 편집해서 재제출할 수 있습니다.

도구 제한

검토할 때 검토자는 선택적으로 allowed_tools 설정 가능 — 기술이 사용할 수 있는 외부 도구 목록. 예를 들어:

  • github-pr-reviewer 기술이 github_api만으로 제한될 수 있음
  • aws-cost-checker 기술이 aws_api만으로 제한될 수 있음

기술이 이 화이트리스트 밖의 도구를 사용하려고 하면:

  • 제한이 작업 실행 시 강제됨
  • 에이전트가 오류를 받으며 계속할 수 없음
  • 시도가 감사 추적에 기록됨

이를 통해 검토자는 기술이 나중에 문제가 발견되더라도 손상 반경을 제한할 수 있습니다.

감사 및 규정 준수

모든 기술 조치가 기록됩니다:

  • 기술 생성, 편집 및 삭제
  • 검토 제출
  • 승인, 거부 및 취소
  • 에이전트가 기술을 로드하고 사용할 때
  • 체크섬 불일치 및 변조 시도

설정 → 감사 로그에서 감사 로그에 접근하고 "기술"로 필터링하여:

  • 누가 어떤 코드를 승인했는지 추적
  • 기술이 언제 편집되었는지 확인
  • 보안 사건 조사(취소된 기술, 체크섬 실패)

모범 사례

  • 철저한 검토 — 기술이 에이전트 대신 실행됨; 코드 검토처럼 대우
  • 질문 예상 — 작성자에게 중요 섹션 설명 요청
  • 도구 제한 사용 — 각 기술을 필요한 최소 도구로 제한
  • 검토자 교체 — 한 명이 모든 것을 승인하도록 하지 않음
  • 업데이트 확인 — 기술 편집 시 차이 신중히 검토
  • 의심스러우면 취소 — 기술이 비정상적으로 작동하면 취소하고 조사

대량 작업

엔터프라이즈 관리자는 다음을 할 수 있습니다:

  • 기술 취소 — 즉시 작업 공간 전체 비활성화(변조 의심 시)
  • 재승인 요구 — 모든 승인된 기술을 pending_review로 강제(정책 변경 후 등)
  • 모든 버전 감사 — 완전한 버전 히스토리 및 차이 보기

설정 → 기술 → 거버넌스를 사용하여 이러한 대량 작업을 수행합니다.

다음 단계