아키텍처 결정 이력

2026-08-20 · UI Center의 역할 분리

결정: 공통 UI 배포 작업대는 DirectoryService 관리자 화면에서 분리해 UI Center 독립 웹서비스로 운영한다.

이유: 공통 UI 패키지 버전, 릴리스 메타데이터, 포털별 적용·검증 상태는 중앙 운영 도구로서 별도 화면과 릴리스 수명주기가 필요하다.

영향: DirectoryService는 사용자·조직·권한 원장과 UI Center 연동 설정을 유지한다. UI Center는 공통 UI 패키지·테마·배포 상태를 표시하고 관리한다.

후속 조치: UI Center 전용 읽기·쓰기 권한과 중앙 로그인 기반의 쓰기 작업 보호를 구현한다.

결정: 공통 UI 릴리스 승인·포털 구독·적용 요청의 활성 운영 화면은 UI Center가 담당하고, DirectoryService는 포털 URL·배포 플랫폼 전달 대상·관리형 Key 및 배포 원장 API를 담당한다.

이유: 공통 UI의 릴리스 수명주기와 포털 인증·전달 설정은 서로 다른 운영 관심사다. UI Center에서는 중앙 로그인 관리자만 ui:read·ui:write 권한을 사용하는 배포 작업을 실행한다.

영향: DirectoryService의 일반 좌측 메뉴에서는 공통 UI 배포 탭을 제거하고, 로그인 사용자 정보 바로 위의 독립 UI Center 바로가기로 전환한다. 포털 URL 등록과 자격증명 전달은 현황 우선의 단일 포털 연동 설정 화면에서 관리한다.

결정: 일반게시판·첨부파일 같은 공통 기능은 중앙 런타임 서비스와 중앙 DB로 통합하지 않는다. 기본 소스·예제·테스트·적용 문서를 제공하는 버전 관리 Asset으로 운영한다.

이유: 포털마다 게시판 필드, 승인 절차, 화면, 보존 정책과 운영 요구가 다르다. 하나의 통합 게시판은 각 포털 요구를 제약하거나 지나치게 복잡해질 수 있다.

영향: 각 포털은 게시판 DB·소스·운영을 독립적으로 소유한다. 공통 Asset 저장소는 출발점과 개선된 기준 버전을 제공할 뿐, 포털의 런타임과 직접 결합하지 않는다.

후속 조치: 게시판·첨부파일 기본 Asset 구조와 포털별 인계·선택적 업그레이드 기준을 정의한다.

결정: 공통 게시판 DB를 별도 인스턴스나 별도 사용자로 만들지 않는다. 게시판 데이터는 적용 포털의 DB에 저장한다.

이유: 공통 기능의 최종 모델이 중앙 운영 서비스가 아니라 소스 Asset 제공으로 정리됐기 때문이다.

영향: DB 인스턴스 통합 여부는 각 포털의 기존 운영 환경 판단으로 남는다. DirectoryService의 사용자·조직 원장은 계속 중앙 API를 통해 참조한다.

후속 조치: 공통 Asset의 사용자·조직 연동 예시를 DirectoryService API 기반으로 제공한다.

결정: 공통 UI의 표준 템플릿은 로그인 화면, 로그인 후 좌측 메뉴, 우측 프레임 상단바, 히어로 영역까지로 한정한다. 히어로 아래는 공통 좌우 여백을 제외하고 포털과 하위 페이지가 자유롭게 소유하는 업무 레이아웃으로 운영한다.

이유: 모든 포털에서 일관된 진입 경험과 탐색 규칙을 유지하면서도, 업무 화면의 정보 구조·데이터 밀도·승인 절차·도메인 기능이 고정 템플릿에 제약받지 않도록 하기 위함이다.

영향: 공통 UI 패키지는 로그인, 좌측 메뉴, 상단바, 히어로 및 버튼·타이포그래피·첨부파일·게시판·폼 같은 재사용 컴포넌트를 제공한다. 각 포털은 히어로 아래의 그리드·섹션·업무 흐름·도메인 데이터 표현을 자체 소스로 구현한다.

후속 조치: 신규 포털과 화면 개편 시 공통 UI 템플릿 및 포털 자유 레이아웃 가이드를 적용 검토 기준으로 사용한다.