플러스프로젝트 배경
1) 문제점 - 사내 운영 기능은 전자계약, 회의실, 헬프데스크, 위키, 구매 승인, 연차, 조직도처럼 성격이 제각각이라 도구가 흩어지기 쉽고, 흩어진 만큼 접근 권한도 제각기 관리된다. - 구독 팩 차단을 프런트 메뉴 숨김에 의존하면, 메뉴는 잠겨 있어도 주소를 직접 입력하면 열리는 상태가 만들어진다. 실제로 이 프로젝트의 두 모듈이 그 상태였다. - 팩이 어떤 메뉴를 여는지 알려주는 표
프로젝트 성과
연동되지 않은 기능을 성공으로 위장하지 않는 표기 체계
회의실 컨트롤러가 오프라인이면 원격 명령 버튼 옆에 하드웨어에 반영되지 않을 수
있다는 문구를 바로 붙였다. 외부 캘린더 연동은 실제 API가 없어 시도 시 성공을 지어내지
않고 실패로 기록한다.
있다는 문구를 바로 붙였다. 외부 캘린더 연동은 실제 API가 없어 시도 시 성공을 지어내지
않고 실패로 기록한다.
되돌리기를 되돌릴 수 있는 복원 구조
사내 위키 문서를 이전 버전으로 복원할 때, 복원하기 전의 현재 상태를 먼저 버전으로
저장한 뒤 되돌린다. 잘못 복원했더라도 되돌아올 길이 항상 남는다.
저장한 뒤 되돌린다. 잘못 복원했더라도 되돌아올 길이 항상 남는다.
핵심 기능
전자계약 서명
서명 이미지와 서명 시각, 접속 정보를 남기고 본문을 해시로 봉인한다.
진행 단계
데이터 모델과 상태 규칙 설계
2026.08.
데이터 모델 38개를 잡고, 구매 승인처럼 상태가 이동하는 흐름은 상태전이표를 먼저
만들었다. 어떤 상태에서 어떤 상태로 갈 수 있는지 표에 없는 이동은 거부.
만들었다. 어떤 상태에서 어떤 상태로 갈 수 있는지 표에 없는 이동은 거부.
프로젝트 상세
사내 운영에 필요한 기능들은 서로 닮은 구석이 거의 없다. 전자계약 서명과 회의실 예약과 사내 위키를 나란히 놓으면 공통점을 찾기 어렵다. 그럼에도 서른두 개 화면을 하나의 구독 팩으로 묶은 것은 "회사를 굴리는 데 다 필요하다"는 기준 하나 때문이었고, 그 느슨한 묶음을 지탱하려면 잠금과 상태 관리가 코드의 한 곳에 모여 있어야 했다. 그래서 팩 차단을 프런트 메뉴 숨김이 아니라 백엔드 함수 하나로
