용어집

작업 가이드나 API 계약을 읽다가 필요한 용어를 찾는 문서입니다. Scope, population, 소유권, 멤버십은 서로 다른 사실이므로 아래 권한 예시로 구분하세요. 여기의 정의를 별도 환경 설정 단계로 취급할 필요는 없습니다.

읽는 방법

알파벳순이 아니라 혼동을 일으키는 짝별로 묶었습니다. 각 항목은 그 용어가 무엇인지, 그리고 더 중요한 경우 무엇이 아닌지를 밝힙니다.

지속 어휘의 소유자는 docs/doctrine/02-TERMS.md입니다. 아직 구현되지 않은 용어는 그렇다고 적었습니다.

정의와 코드가 어긋나면 enum이 정본입니다. 아래 용어들의 실제 값 집합은 이 네 곳에 있습니다.

Nexia\Permission\AssignmentScope;   // tenant, legal_entity, operating_unit
Nexia\Permission\SubjectPopulation; // all, self, direct_reports, legal_entity, operating_unit
Nexia\Permission\GrantControl;      // standard, protected
Nexia\AppDescriptors\DescriptorStatus; // active, deprecated, removed1234

최소 예시

authorization 문장을 서로 다른 네 용어로 읽으세요.

Permission: workshop.note.update
Role: Workshop editor
Data scope: one Legal Entity
Subject population: all1234

Permission은 action을 명명하고 Role은 이를 묶으며 Access Grant가 scope와 population을 더합니다. 어느 것도 authentication이나 organization membership가 아닙니다.

플랫폼과 소유권

용어	정체	아닌 것
Tenant	한 고객사의 데이터와 실행을 다른 고객사의 것과 분리하는 격리 경계	쿼리에 붙이는 필터
Platform	App이 붙는 테넌트향 제품 표면. Core와 그것을 조립하는 호스트	서비스를 굴리는 운영 계층
Core	같은 표면을 가리키는 내부 소유 용어. 그래서 `core.*` 식별자가 이 이름을 씀	산문에서 쓸 대외 명칭
Service operations	가입 관리, 도메인, 프로비저닝, 공개 사이트, 개발자 포털	테넌트 업무 진실의 소유자
App	도메인 진실을 소유하고 명시적 계약으로 통합하는 업무 기능	플랫폼 안의 폴더, 별도 서비스
App Package	한 App의 독립 버전 Composer 배포 단위	플랫폼 소유 소스
App Manifest	플랫폼이 여러분의 contribution을 어디서 찾을지 선언하는 클래스	기능 등록부
App Definition	`extra.nexia.app` 메타데이터 블록	PHP 설정
SDK	유일한 공개 경계 — `Nexia\*`와 `@nexia/sdk`	유틸리티 라이브러리
Resource	소유권과 권한 경계가 명시된 지속 업무 개념	아무 Eloquent 모델

App과 App Package의 차이. App은 기능이고 Package는 배포 방식입니다. app_key가 둘 다 식별하며 절대 바뀌지 않습니다.

Platform과 Core의 차이. 같은 것을 두 독자에게 다르게 부릅니다. 산문에서는 플랫폼, 코드에서는 Core입니다. app/Platform/ 디렉터리는 용어보다 먼저 생긴 이름이라 여기서 말하는 Platform이 아니라 서비스 운영 계층입니다.

작업 공간과 패키지 해석

아래 용어는 소스 코드가 실행 중인 테넌트에 도달하기까지의 서로 다른 단계를 가리킵니다. 같은 뜻으로 바꿔 쓸 수 없으며, 지속되는 doctrine 어휘가 아니라 현재 개발 도구의 동작을 설명합니다.

용어	정체	아닌 것
Repository(저장소)	버전 관리되는 소스와 Git 이력. Core, App SDK, 각 App Package가 서로 다른 저장소를 가짐	Composer 설치나 테넌트에서 켜진 App
소스 폴더	개발자가 코드를 읽고 수정하는 폴더. Core는 `nexia-cloud-os/`, SDK는 `packages/app-sdk`, App은 `packages/{app}`에 있음	Composer 설치 뷰. 소스 폴더가 있어도 Composer가 반드시 사용하지는 않음
로컬 소스 목록 (`local package selection`)	`PACKAGES=...`로 정하고 로컬에 저장하는 패키지 key 목록. 생성된 `composer.local.json`이 어느 SDK·App 소스 폴더를 사용할지 결정	Git branch 선택, 일반 UI 선택, 테넌트 설치
로컬 소스 패키지	저장된 로컬 소스 목록에 든 패키지. Core가 해당 checkout으로 Composer·frontend 로컬 overlay를 준비함	App이 어느 테넌트에 설치됐다는 증거
Lock으로 해석된 패키지	로컬 소스 목록 밖에 있어 커밋된 `composer.lock`에서 버전과 소스를 가져오는 패키지	편집할 소스 루트
Composer 설치 뷰	런타임 도구가 `Composer\InstalledVersions::getInstallPath()`로 찾는 해석 완료 패키지 경로	개발자가 편집하는 소스 위치
테넌트 설치	App 하나를 특정 테넌트에서 사용할 수 있게 만드는 런타임 설치 기록과 initializer 결과	`packages/`의 소스 폴더, Composer 해석, 사용자 권한

저장소 동작은 clone, branch switch, file restore처럼 실제 행위를 밝힙니다. selection도 그 자체로는 일반적인 선택일 뿐입니다. 코드의 local package selection을 국문판에서는 그 역할이 드러나는 로컬 소스 목록이라고 씁니다.

업무 실행과 조율

용어	정체	아닌 것
Workbench	사람이 지금 할 일과 업무 도구를 여는 Shell 컨텍스트	업무 상태 소유자, 실행 엔진
Business Process	사람이 작성한 BPMN 프로세스와 DMN 결정을 실행하는 Core 런타임	Workflow, 내장 Camunda 런타임
전자 결재 (`Approval`)	결재선과 결정 증거, 문서 snapshot을 소유하는 Core 런타임	업무 양식 하나, Process User Task
Workflow	Temporal 같은 durable workflow 런타임 계열을 위해 남겨 둔 용어	Business Process와 전자 결재의 상위 이름

Nexia Business Process는 OMG BPMN·DMN 표준 용어를 사용하고 Camunda 8의 작성·오케스트레이션 모델을 참고하지만, 실행 상태와 nexia:* 확장을 직접 소유합니다. 현재 개발자 문서에서 Workflow는 구현된 제품 영역을 가리키지 않습니다. 앞으로 durable workflow 런타임을 설명할 때 Business Process와 구별해 쓰기 위한 이름입니다.

조직 구조

이 묶음은 모두 실제 조직 구조를 모델링합니다. 그러나 어느 것도 권한을 부여하지 않습니다.

용어	정체	아닌 것
Party	실세계 사람 또는 조직 하나의 공유 식별	권한 범위, 업무 프로필
Legal Entity	내부 법적·계약·세무·회계·고용 실체	운영 계층, PartyRole
Legal Entity Membership	User가 한 Legal Entity에 유효기간을 갖고 참여하는 사실	행위 권한 — 참여와 Shell 가용성만 통제
Operating Unit	운영 책임의 지속 단위	Legal Entity, 암묵적 권한 부여
Operating Unit Membership	User가 한 Operating Unit에 참여하는 사실	Worker Assignment, 권한 부여
Site	실세계 장소 — 사무실, 공장, 지점, 물류 거점	Operating Unit, App 실행 설비
Worker	People이 소유하는 사람 Party의 인력 프로필	PartyRole, 그 자체로 권한
Worker Assignment	Worker를 업무 컨텍스트에 배치한 유효기간 기록	User 멤버십, Access Grant
PartyRole	한 Party의 가벼운 비권한 분류	Legal Entity, 업무 프로필, 관계
PartyRelationship	두 Party 사이의 지속적 유형 관계	권한 부여
Business profile	Party가 특정 App 도메인에 참여하는 방식을 정의한 App 소유 레코드	Party, PartyRole
Workspace / view context	사용자 경험 컨텍스트	권한 뿌리, 지속 진실의 소유자

이 묶음 전체의 규칙: 참여는 권한이 아닙니다. 멤버십은 무언가를 선택 가능하게 만듭니다. 그 레코드에 행위하려면 Access Grant가 필요합니다.

권한

한 결정을 이루는 네 부분입니다.

용어	정체	아닌 것
Authentication	신원 검증	Authorization
Authorization	행위자가 보호된 동작을 해도 되는지 백엔드가 강제 평가하는 것	프런트엔드가 판단하는 무엇
Permission	그 기능을 소유한 코드가 선언하는 정확한 백엔드 강제 업무 동작 — Core 또는 App	대상 모집단이나 데이터 범위
Role	Permission의 재사용 가능한 묶음. 테넌트가 작성하거나 Core가 동기화한 시스템 기준 Role	이름이나 조직 배치로 생기는 데이터 접근
Access grant	Role을 데이터 범위 안에서 행위자에게 배정한 유효기간 기록	멤버십
Data scope	Grant가 적용되는 한정된 업무 컨텍스트	구조로부터 암묵 생성되는 무엇
Subject population	Grant가 겨냥할 수 있는 행위자 상대 모집단 — `self`, `direct_reports` 등	그 자체로 동작을 부여하는 것
Delegation	명시적·한정적·회수 가능·감사 가능한 대리 권한	상속되거나 스스로 확장되는 권한
Field policy	보이는 레코드의 어느 필드를 읽고 바꿀 수 있는지 정하는 백엔드 규칙	레코드 단위 가시성
Separation of duties	양립 불가 권한을 막는 서버 강제 정책	아직 동작하는 기능 — 이연 상태

Permission과 Role과 Grant의 차이. Permission은 무엇을, Role은 어느 묶음을, Grant는 어디서·누구의 것을 말합니다. 여러분의 App은 Permission만 선언합니다.

Permission은 능력을 지칭하고 범위를 지칭하지 않습니다. workshop.note.update는 어느 노트인지 말하지 않습니다.

확장 패턴

닮아 보이는 다섯 가지입니다. 판별식은 결과를 누가 소유하는가입니다.

용어	결과 소유자	내 원본과 갈라지는가
Catalog	여러분의 코드 — 실시간으로 읽힘	아니오
Descriptor	여러분의 코드 — 런타임에 해석됨	아니오
Preset	선택 후 테넌트	즉시
Template	복사 후 테넌트	즉시
Initializer	설치 시점의 테넌트	즉시

용어	정체	아닌 것
Contribution	선언된 위치에서 SDK 인터페이스를 구현한 클래스	등록 호출
Catalog	플랫폼이 발견·게이팅·해석하는 코드 소유 정의	테넌트가 관리하는 기준 정보
Registry (백엔드)	발견된 contribution 위의 플랫폼 런타임 조회 계층	여러분이 쓰기하는 대상
Registry (프런트엔드 SDK)	App이 시작 시 쓰고 Shell이 런타임에 읽는 레지스트리 — `resourceInspectorAdapterRegistry`, `approvalComposerBusinessFormRegistry`	백엔드 contribution 레지스트리
Descriptor	기능을 플랫폼 런타임에 연결하는 타입 있는 선언. Version과 lifecycle field는 descriptor 계열 계약을 따르며 하위 `ResourceLifecycleEventDescriptor`도 자체 payload `schemaVersion`을 가짐	테넌트 레코드, Template
Preset	관리자가 채택할 수 있는 권장 구성	권한 부여, 생성된 Role
Copyable template	행위자가 명시적으로 복사하는 코드 정의 원본	살아 있는 정의
Initializer	App이 동작하는 데 필요한 최소 행	데이터 적재 수단
Demo data	폐기 가능한 샘플 레코드	설치 전제 조건

Catalog와 기준 정보의 차이. quality.defect_code가 존재한다는 사실은 Catalog입니다. 공장이 실제로 쓰는 결함코드는 기준 정보입니다.

Template과 Catalog의 차이. Catalog에 수정을 배포하면 모든 테넌트가 받습니다. Template에 수정을 배포하면 기존 복사본은 그대로입니다.

Shell과 프런트엔드

용어	정체	아닌 것
Shell	호스트가 소유하는 애플리케이션 프레임	App이 배치하는 무엇
Activity Rail	최좌측 영역 — Workbench, App Launcher, 운영 항목	직접 기여하는 내비게이션
Side Navigation Surface	Settings, App Menu, Workbench 컨텍스트 중 하나를 그리는 슬롯	세 개의 별도 영역
App Menu	그 슬롯의 `app:{app_key}` 뷰	Settings Menu
Settings Menu	`shell.settings` 뷰 — 호스트 전용	App 설정이 사는 곳
Navigation context	항목이 어느 Side Navigation 뷰에 속하는지	권한
Destination	Route·아이콘·라벨·배치·권한 게이트	권한 부여
Route Surface	Route 또는 탭 단위 화면	Work Surface
Work Surface	Route Surface 안의 Primary Section + 선택적 Inspector Section	Route Surface
Slot	호스트 소유 화면의 이름 있는 버전 삽입 지점	여러분이 새로 만들 수 있는 것
Slot Widget	레지스트리 슬롯을 채우는 여러분의 컴포넌트	대시보드 위젯
Dashboard widget	배치 가능하고 Resource에 묶인 컴포넌트	Slot Widget

Slot Widget과 Dashboard widget의 차이. Slot Widget은 호스트 화면이 공개한 고정 지점을 채웁니다. Dashboard widget은 테넌트가 대시보드에 배치합니다.

selected/active와 focused의 차이. 앞은 지속되는 현재 상태, 뒤는 키보드·포인터가 잠시 겨냥한 후보입니다.

라이프사이클

용어	정체	접근 권한을 주는가
호스트 활성화	패키지를 호스트에 설치하고 정의를 동기화	아니오
테넌트 설치	한 테넌트에 설치 행을 쓰고 initializer를 실행	아니오
초기화	설치의 initializer 단계 — `pending` → `initialized` \| `failed`	아니오
Operational	설치가 활성이고 초기화 완료, 모든 전제 App도 operational	아니오
Access Grant	행위자와 Role, Data scope, Subject population, 유효기간을 묶는 레코드 — 지속 권한의 유일한 출처	예
Role 배정	Access Grant를 만들거나 편집하는 UI 축약어. Role 멤버십만으로는 아무것도 부여되지 않음	그 자체로는 아니오

현재 연산에 적용되는 Access Grant가 상시 권한의 근거입니다. 탐색과 설치는 기능을 사용할 준비를 할 뿐 사용자 권한을 부여하지 않습니다.

문서와 설계

용어	정체
Current design	Reference에 기록된 변경 가능한 구현 선택
Protected invariant	구현이 바뀌어도 살아남아야 하는 제품·보안·정합성·복구 결과
Transition exception	아직 제거할 수 없어 기록한 기존 경계 위반 — 재사용할 선례가 아님

doctrine에 있으나 구현되지 않은 것

이 항목들을 전제로 설계하지 마세요. 이연이지 포기는 아닙니다.

용어	상태
Separation of duties	SoD 규칙 테이블이 아직 없음
Access delegation 레코드	이연
Data scope로서의 `core.site`	이연 — scope는 tenant, legal_entity, operating_unit
Legal Entity relationship descendants	이연 — descendants는 `core.operating_unit`만 지원
`reporting_tree`, `assigned_records` 모집단	`SubjectPopulation`에 없음

doctrine이 enum에 없는 값을 지칭하면 실제로 동작하는 것은 enum입니다.

오류

혼동한 쌍	잘못된 추론	올바른 확인
Authentication / authorization	로그인한 사용자는 행위할 수 있음	backend Permission 결정을 확인
Membership / Access Grant	조직 참여가 권한을 부여함	membership는 참여에 영향, Grant가 권한을 운반
Catalog / master data	코드 소유 Resource 정의가 tenant 편집 데이터임	Catalog는 type을 선언, master data는 tenant의 행
App / App Package	folder가 업무 capability임	App은 capability, Package는 delivery unit
`packages/`의 소스 폴더 / 로컬 소스 목록	디스크에 패키지 소스 폴더가 있으면 Composer가 자동으로 그 코드를 사용함	저장된 로컬 소스 목록에 package key가 있는지 확인
Composer 설치 / 테넌트 설치	`vendor/`에 패키지가 보이면 모든 테넌트에서 App을 쓸 수 있음	해당 테넌트의 App 설치 상태를 별도로 확인

실제 사용

packages/assets/src/Contribution/Resources/AssetModule.php는 capability와 scope를 서로 다른 선언으로 유지합니다.

코드 예시

PHP

public static function permissionAssignmentScope(): AssignmentScope
{
    return AssignmentScope::LegalEntity;
}

public static function permissionResources(): array
{
    return ['assets.asset' => ['read', 'register', 'update_identity', 'validate', 'import', 'retire', 'export', 'audit']];
}123456789

이 소스는 glossary의 구분을 보여 줍니다. Permission은 action을 명명하고 AssignmentScope는 grant가 적용될 수 있는 곳을 명명합니다.

용어집

용어집