코드

이 페이지는 AIMO 코드 시스템 형식, 명명 규칙 및 생명주기 관리를 정의합니다.

코드 형식

모든 AIMO 코드는 다음 형식을 따릅니다: <PREFIX>-<TOKEN>

구성 요소	설명	형식	예시
`<PREFIX>`	차원 식별자	2개 대문자	FS, UC, DT
`-`	구분자	하이픈	-
`<TOKEN>`	차원 내 고유 토큰	3자리 숫자 (0 패딩)	001, 002, 003

예시

FS-001 - 기능 범위: 최종 사용자 생산성
UC-005 - 사용 사례 분류: 코드 생성
DT-004 - 데이터 유형: 개인 데이터
CH-003 - 채널: IDE 플러그인
IM-002 - 통합 모드: SaaS 통합
RS-001 - 리스크 표면: 데이터 유출
OB-001 - 결과/혜택: 효율성
LG-001 - 로그/기록 유형: 요청 레코드

네임스페이스

AIMO 분류체계는 8개 차원 네임스페이스를 사용합니다:

ID	이름	접두사	코드 수
FS	기능 범위	`FS-`	6
UC	사용 사례 분류	`UC-`	30
DT	데이터 유형	`DT-`	10
CH	채널	`CH-`	8
IM	통합 모드	`IM-`	7
RS	리스크 표면	`RS-`	8
OB	결과 / 혜택	`OB-`	7
LG	로그/이벤트 유형	`LG-`	15

총계: 8개 차원에 걸쳐 91개 코드

네임스페이스 규칙

접두사는 고정: 2자리 차원 접두사(FS, UC 등)는 영구적이며 절대 변경되지 않습니다.
0 패딩: 토큰은 항상 3자리이며, 0으로 패딩됩니다(예: 1이 아닌 001).
순차 할당: 새 코드는 차원 내에서 다음 사용 가능한 번호가 할당됩니다.
재사용 없음: 제거된 코드는 다른 의미에 재할당되지 않습니다.

안정성 규칙

코드 안정성은 감사 추적성을 위한 중요한 원칙입니다.

ID 불변성

코드 ID는 불변 — 할당되면 코드 ID는 의미를 변경하지 않습니다
UC-001과 같은 코드는 전체 생명주기 동안 항상 "일반 Q&A"를 의미합니다
의미를 변경해야 하는 경우 대신 새 코드가 생성됩니다

재사용 금지 정책

폐기되거나 제거된 코드는 다른 의미에 재할당되지 않습니다
이것은 이력 증거가 유효하고 추적 가능한 상태로 유지되도록 보장합니다
예: UC-010이 폐기되면 새 사용 사례는 UC-031을 받습니다(UC-010이 아님)

제거 전 폐기

코드는 제거 전 최소 하나의 MINOR 버전 동안 deprecated로 표시되어야 합니다
제거는 MAJOR 버전 증분에서만 발생합니다
자세한 내용은 생명주기 섹션을 참조하세요

사용

필수 차원

각 AI 시스템 또는 사용 사례에 대해 각 필수 차원에서 최소 하나의 코드를 지정해야 합니다(MUST):

차원	선택	참고사항
FS	정확히 1개	기본 비즈니스 기능
UC	1개 이상	수행되는 작업 유형
DT	1개 이상	데이터 분류
CH	1개 이상	접근 채널
IM	정확히 1개	통합 모드
RS	1개 이상	리스크 범주
LG	1개 이상	로그/이벤트 유형

선택적 차원

차원	선택	참고사항
OB	0개 이상	기대되는 혜택 (선택적)

코드 조합

AI 시스템을 문서화할 때 여러 차원의 코드가 조합됩니다. 조합 우선순위는 코드를 나열할 때의 순서를 결정합니다:

FS (기능 범위)
UC (사용 사례 분류)
DT (데이터 유형)
CH (채널)
IM (통합 모드)
RS (리스크 표면)
OB (결과 / 혜택)
LG (로그/기록 유형)

조합 예시:

FS: FS-001
UC: UC-001, UC-002
DT: DT-002, DT-004
CH: CH-001
IM: IM-002
RS: RS-001, RS-003
OB: OB-001
LG: LG-001, LG-002

생명주기

상태 값

상태	설명	검증기 동작
`active`	현재 유효하고 사용 중	수락됨
`deprecated`	여전히 유효하지만 제거 예정	경고와 함께 수락됨
`removed`	더 이상 유효하지 않음; 사용하지 마세요	거부됨

생명주기 메타데이터 필드

딕셔너리는 다음 필드로 생명주기를 추적합니다:

필드	필수	설명	예시
`status`	예	현재 상태	`active`
`introduced_in`	예	코드가 추가된 버전	`0.1.0`
`deprecated_in`	아니요	폐기로 표시된 버전	`1.2.0`
`removed_in`	아니요	제거된 버전	`2.0.0`
`replaced_by`	아니요	대체 코드	`UC-015`
`backward_compatible`	예	변경이 기존 사용을 깨는지 여부	`true`

폐기 규칙

코드는 제거 전 최소 하나의 MINOR 버전 동안 deprecated로 표시되어야 합니다(MUST)
폐기된 코드에는 deprecated_in 버전 및 해당하는 경우 replaced_by가 포함됩니다
제거는 MAJOR 버전 증분에서만 발생합니다
폐기된 코드는 폐기 기간 동안 이전 호환성을 위해 유효한 상태로 유지됩니다

예시 타임라인:

버전	상태	조치
0.1.0	`active`	코드 `UC-010` 도입
1.2.0	`deprecated`	폐기로 표시됨, `replaced_by: UC-031`
2.0.0	`removed`	더 이상 검증기에서 수락되지 않음

버전 관리

코드 변경은 시맨틱 버전 관리를 따릅니다:

MAJOR: 코드 제거 또는 호환성 깨는 변경
MINOR: 새 코드 추가, 코드 폐기
PATCH: 정의 명확화만 (구조적 변경 없음)

이전 호환성

backward_compatible 필드는 변경이 기존 사용을 깨는지 여부를 나타냅니다:

값	의미
`true`	이 코드를 사용하는 기존 증거가 유효한 상태로 유지됨
`false`	기존 증거에 업데이트가 필요할 수 있음 (MAJOR 버전 변경)

검증

검증기가 확인하는 것:

모든 필수 차원에 최소 하나의 코드가 있음
단일 선택 차원에 정확히 하나의 코드가 있음
모든 코드가 현재 분류체계 딕셔너리에 존재함
코드 형식이 <PREFIX>-<TOKEN> 패턴과 일치함 (예: UC-001)
폐기된 코드에 경고 플래그 지정

구현 세부사항은 검증기를 참조하세요.

SSOT 참조

!!! info "진실 공급원" 권위 있는 정의는 source_pack/03_taxonomy/taxonomy_dictionary_v0.1.csv입니다. 이 페이지는 설명 목적입니다. 업데이트 워크플로우는 현지화 가이드를 참조하세요.

코드