AI 어시스턴트에게 무엇을 알 수 있고, 주장할 수 있으며, 할 수 있도록 허용할지 가르치기

🧠 AI 어시스턴트에게 무엇을 알 수 있고, 주장할 수 있으며, 할 수 있도록 허용할지 가르치기

저는 Zorgax와 관련된 새로운 MyZubster 마일스톤 작업을 진행하고 있습니다.

흥미로운 문제는 단순히 다음과 같지 않습니다:

“우리가 AI 어시스턴트에게 더 많은 지식을 어떻게 제공할 수 있을까?”

더 어려운 문제는 다음과 같습니다:

그 지식으로 실제로 무엇을 할 수 있도록 허용할지 정의하는 방법 — 그리고 그 역량을 어떻게 증명할 것인가?

이것이 PR #1573의 핵심입니다.

기여자 역량과 AI 역량 분리하기

제가 명확히 하고 싶었던 설계 결정 중 하나는 이 둘이 서로 다른 것이라는 점입니다.

기여자(contributor) 기록은 다음과 같은 질문에 답합니다:

• 누가 이 작업을 수행했는가?
• 어떤 저장소(repository) 또는 풀 리퀘스트(pull request)가 이를 지원하는가?
• 무엇이 문서화, 기록되거나 테스트되었는가?
• 증거 상태(evidence state)는 무엇인가?
• 제한 사항은 무엇인가?

반면, Zorgax 역량(capability)은 다른 것을 답변합니다:

• Zorgax가 어떤 증거를 소비할 수 있는가?
• 어떤 행동을 수행할 수 있는가?
• 무엇을 주장해서는 안 되는가?
• 어떤 출처 상태(source state)가 필요한가?
• TESTED로 불리기 전에 역량이 제한된 테스트를 필요로 하는가?

이 구분이 중요합니다.

만약 기여자가 특정 영역에 전문 지식이나 증거를 가지고 있더라도, Zorgax가 그 전문 지식을 무제한의 주장으로 자동으로 상속해서는 안 됩니다.

기계 판독 가능한 역량 모델

새로운 스키마는 다음과 같습니다:

myzubster.zorgax-capability.v1

역량(capability)은 다음을 정의합니다:

inputs
→ allowed actions
→ prohibited claims
...

초기 상태는 의도적으로 보수적입니다:

Contributor Profile Assistant
→ DOCUMENTED

...

오직 그중 하나만이 TESTED로 시작합니다.

이것은 고의적인 것입니다.

예시: 기여자 프로필

Contributor Profile Assistant는 승인된 공개 증거를 사용하여 다음을 수행할 수 있습니다:

• 선언된 전문 관심사 요약하기;
• 프로필 초안 준비하기;
• 출처(provenance) 식별하기;
• 제한된 온보딩 단계 제안하기.

하지만 다음과 같은 것은 할 수 없습니다:

• 자격증 발명 (invent qualifications);
• 고용 상태 추론 (infer employment);
• 자격 증명서 추론 (infer certification);
• 여권 / LIFE / DAO 참여 여부 추론 (infer Passport / LIFE / DAO participation);
• 필요한 승인 없이 프로필 정보 게시 (publish profile information without the required approval).

따라서 누군가 다음과 같이 말한다면:

“저는 MyZubster 사용성 테스트에 관심이 있습니다.”

Zorgax는 그 정보를 보존하고 구조화할 수 있습니다.

하지만 다음처럼 조용히 변환할 수는 없습니다:

“자격증을 갖춘 소프트웨어 테스터.”

예시: 연구 증거 (research evidence)

Research Evidence Navigator는 또 다른 규칙을 기반으로 설계되었습니다:

증거 상태는 검색 후에도 유지되어야 합니다 (evidence state must survive retrieval).

만약 연구 지식 카드(Knowledge Card)가 SUPPORTED라면,
Zorgax가 그것을 검색하거나 요약하더라도 여전히 SUPPORTED입니다:

SUPPORTED

아니라:

TESTED

아니라:

과학적으로 검증됨 (scientifically validated)

아니라:

임상적으로 인증됨 (clinically certified)

이 기능은 이미 경계가 지정된 기여자 범위(bounded contributor-scoped) 체크포인트를 가지고 있으며, 이것이 현재 상태가 TESTED일 수 있는 이유입니다.

역량 테스트 (Capability testing)

제가 나아가고 있는 모델은 다음과 같습니다:

Capability definition
        ↓
Allowed evidence
...

문서만으로는 충분하지 않습니다.

역량(capability)이 TESTED가 되려면, 재현 가능한 경계 지정 체크포인트(reproducible bounded checkpoint)가 이를 뒷받침해야 합니다.

CI 강제 (CI enforcement)

저는 또한 Zorgax 역량 레지스트리(Zorgax capability registry)를 위한 검증기(validator)를 추가하고 기존의 지속적 증거 게이트(Continuous Evidence Gate)에 연결했습니다.

이 검증기는 다음과 같은 사항들을 확인합니다:

• 스키마 유효성 (schema validity);
• 중복 역량 ID (duplicate capability IDs);
• 레지스트리 ↔ 파일 일관성 (registry ↔ file consistency);
• 상태 일관성 (status consistency);
• TESTED 역량이 실제로 경계 지정된 TESTED 체크포인트 증거와 연결되는지 여부.

따라서 역량 상태는 더 이상 단순한 문장이 아닙니다.

CI가 거부할 수 있는 무언가가 되어가고 있습니다.

이것이 중요한 이유 (Why this matters)

많은 AI 시스템들이 모호한 용어로 설명됩니다:

“어시스턴트는 X를 알고 있다.”

저는 이러한 틀(framing)이 기여자 주도 시스템(contributor-driven systems)에게는 너무 느슨하다고 생각합니다.

저는 다음을 선호합니다:

source
→ provenance
→ evidence state
...

그것은 다음과 같은 질문에 답하기 쉽게 만듭니다:

⚠️ [IMG:N]

• Zorgax가 이것을 말하는 것이 허용되는 이유는 무엇인가요?
• 어떤 출처가 이를 뒷받침하나요?
• 이 정보는 스스로 선언한 것인지, 뒷받침된 것인지, 기록된 것인지, 아니면 테스트된 것인가요?
• Zorgax가 추론하는 것이 명시적으로 금지된 것은 무엇인가요?
• 이 특정 기능은 실제로 테스트되었나요?

현재 로드맵

더 광범위한 MyZubster 경로는 다음과 같이 발전하고 있습니다:

Contributor evidence
→ machine-validatable checkpoint
→ competence / provenance registry
...

이 모든 상태를 하나의 일반적인 “검증됨(verified)” 레이블로 붕괴시키지 않으면서 말입니다.

PR #1573은 해당 기능 계층의 첫 번째 구현체입니다.

점검 사항들이 녹색불이고 PR이 병합되면, 제가 표준 병합 커밋과 최종 기능 상태들을 공개하겠습니다.

전체의 원칙은 간단합니다:

AI 기능은 신뢰도(confidence)가 아닌 증거(evidence)에 의해 경계 지어져야 한다.

#SoftwareEngineering #AIEngineering #AIGovernance #DevOps #JSONSchema #CI #OpenSource #SystemDesign #EvidenceFirst #DeveloperTools #MyZubster