# Baron SSO 하위조직 Subtree API 보강 요청 초안

작성일: 2026-07-07
상태: draft

목적: Baron SSO 개발자에게 `tdc114plus` 신규 앱 기준 하위조직 subtree API 보강 필요사항을 Gitea 이슈 형식으로 전달하기 위한 등록용 초안이다. 현재 Swagger의 `GET /api/v1/public/orgchart?token=...` 형태를 참고해, 실제 수신 가능한 응답 구조 기준으로 요청 내용을 맞춘다.

## 1. 이슈 제목 초안

`[Feature Request] tdc114plus 직원검색/조직도용 public orgchart subtree 응답 보강 필요`

## 2. 이슈 본문 초안

```md
## 배경
신규 앱 `tdc114plus`는 Baron SSO에 추가되는 별도 RP(Relying Party)로 개발 중이며,
직원검색/조직도 화면은 정의된 API 인터페이스를 통해 데이터를 조회하는 구조로 진행하고 있습니다.

현재 Swagger상 공개 조직 조회 API는 아래 형태로 확인됩니다.

- `GET /api/v1/public/orgchart?token=...`
- 응답 구조: `tenants[]`, `users[]`, `sharedWith`

신규 앱에서는 이 응답을 기반으로 `전체 -> 회사 -> 부서 -> 팀 -> 개인` 단계 탐색이 가능해야 합니다.

## 문제점
현재 제공 중인 조직 관련 API 응답은 최상위 회사/법인 수준 정보 위주로 내려오고 있어,
특정 회사 하위의 부서/팀 subtree 구조를 충분히 구성할 수 없습니다.

실제 확인 결과:
- `GET /api/v1/tdc114plus/organization/tenants` 응답은 최상위 tenant 위주
- `GET /api/v1/tdc114plus/organization/orgchart`도 동일하게 하위 부서/팀 subtree 확인이 어려움
- `tenantId`를 지정해도 회사 하위 조직 subtree가 아니라 동일한 최상위 목록 중심 응답으로 확인됨
- 직원 상세의 joined tenant 정보도 회사급까지만 확인되어 세부 부서/팀 탐색 기준으로 사용하기 어렵습니다.
- `public/orgchart` 예시도 현재는 `tenants[]`, `users[]` 기본 구조만 보여서, 하위조직 경로 복원용 정보가 부족해 보입니다.

## 재현 절차
1. 신규 앱에서 직원검색/조직도 화면 진입
2. 상단 회사 뱃지 선택
3. 선택한 회사의 하위조직 탐색 시도
4. 하위 부서/팀 단위 트리 확장에 필요한 subtree 데이터가 부족하여 화면 구성이 제한됨

## 현재 동작
- 최상위 조직(회사/법인) 중심 데이터만 확인 가능
- 회사 하위 부서/팀 subtree를 안정적으로 구성하기 어려움
- leaf 조직 선택 후 해당 조직 기준 후속 조회 구현이 제한됨

## 기대 동작
- `public/orgchart` 계열 응답만으로도 특정 회사 또는 조직 기준 하위 subtree 전체를 복원할 수 있어야 합니다.
- 각 tenant 항목에서 상위 조직 관계와 leaf 여부를 확인할 수 있어야 합니다.
- 각 user 항목은 어떤 tenant/조직에 속하는지 연결 가능해야 합니다.
- 프론트는 이 응답만으로 `전체 -> 회사 -> 부서 -> 팀 -> 개인` 탐색과 해당 조직 사용자 표시를 구현할 수 있어야 합니다.

## 요청 사항
현재 Swagger에 노출된 `GET /api/v1/public/orgchart?token=...`를 기준으로,
조직 subtree 복원이 가능하도록 응답 보강이 필요합니다.

가능한 방향 예시:
- 기존 `public/orgchart` 응답에 조직 계층 복원용 필드 추가
- 또는
- `public/orgchart`와 유사한 응답 구조를 유지하면서 subtree 전용 API 추가

예를 들어 `tenants[]`에 아래 정보가 필요합니다.
- `id`
- `parentId`
- `slug`
- `name`
- `type` (`COMPANY`, `DEPARTMENT`, `TEAM` 등)
- `hasChildren` 또는 `isLeaf`
- `depth` 또는 경로 복원 가능 정보

예를 들어 `users[]`에는 아래 정보가 필요합니다.
- `id`
- `name`
- `position`
- `jobTitle`
- `companyCode`
- `tenantId` 또는 `tenantSlug`
- 필요 시 `department`

즉, 프론트가 `tenants[]`와 `users[]`만으로 조직 계층 구성, leaf 조직 판별, 해당 조직 사용자 표시를 수행할 수 있어야 합니다.

## 검토 포인트
- `public/orgchart` 응답 확장으로 처리할지, subtree 전용 API를 분리할지
- `tenants[]`, `users[]` 기준으로 조직-사용자 연결 식별자 통일 가능 여부
- leaf 조직 판단 기준 제공 여부
- 공유 token 기반 조회에서 subtree 범위 제한을 어떻게 둘지
- 신규 앱 포함 타 RP에서 공통 활용 가능 여부
```

## 3. 작성 메모

- 현재 Flutter 앱은 subtree API 부재 구간에서 `본인팀 synthetic chip + 회사 단위 직원 목록` fallback으로 동작하도록 정리했다.
- 즉, 앱 개발은 병행 가능하지만, 완전한 조직 drilldown UX는 해당 응답 보강이 필요하다.
- 현재 초안은 `신규 endpoint 생성 요구`보다 `기존 public orgchart 스타일 응답 보강 요청`에 더 가깝다.
- 등록 시에는 이 문서의 `## 2. 이슈 본문 초안` 블록만 그대로 사용하면 된다.
