
업무 시스템을 개발하다 보면 가장 많이 듣는 말 중 하나가 있습니다.
"상태값 하나 추가해주세요."
처음에는 간단해 보입니다.
하지만 프로젝트가 진행될수록 상태값은 점점 늘어나고, 어느 순간 시스템 전체를 복잡하게 만드는 원인이 됩니다.
특히 연구행정 시스템은 과제, 예산, 연구비 집행, 전자결재 등 수많은 업무가 연결되어 있기 때문에 상태값 설계가 매우 중요합니다.
이번 글에서는 연구과제 상태를 어떻게 설계하면 좋은지 실무 경험 관점에서 정리해보겠습니다.
왜 상태값 설계가 중요할까?
상태값은 단순히 화면에 보여주는 데이터가 아닙니다.
시스템의 업무 흐름 자체를 정의합니다.
예를 들어 다음과 같은 질문이 모두 상태값과 관련됩니다.
- 현재 과제가 진행 중인가?
- 연구비 집행이 가능한가?
- 정산이 가능한가?
- 수정이 가능한가?
- 결재를 올릴 수 있는가?
결국 상태값은 시스템의 권한과 기능을 제어하는 핵심 요소입니다.
연구과제의 일반적인 상태 흐름
대부분의 연구행정 시스템은 다음과 같은 상태를 가집니다.
작성중
↓
신청
↓
승인대기
↓
진행중
↓
종료
↓
정산완료
간단해 보이지만 실제 업무에서는 예외 상황이 많이 발생합니다.
실제 시스템에서는 더 복잡해진다
예를 들어 다음 상태가 추가될 수 있습니다.
작성중
신청
반려
재신청
승인대기
승인완료
일시중지
진행중
조기종료
종료
정산중
정산완료
상태가 많아질수록 관리가 어려워집니다.
개발자가 자주 하는 실수
상태값을 문자열로 저장한다.
STATUS = '진행중'
처음에는 편합니다.
하지만 나중에 명칭이 변경되면 모든 데이터를 수정해야 합니다.
추천 방법
STATUS_CD = 'PRG'
코드값과 코드명을 분리해서 관리하는 것이 좋습니다.
코드 테이블을 사용하는 이유
추천하는 구조는 다음과 같습니다.
CODE_MASTER
CODE_DETAIL
CODE_MASTER
CODE_GROUPCODE_NAME
| PROJECT_STATUS | 과제상태 |
CODE_DETAIL
CODE_GROUPCODECODE_NAME
| PROJECT_STATUS | WRT | 작성중 |
| PROJECT_STATUS | REQ | 신청 |
| PROJECT_STATUS | PRG | 진행중 |
| PROJECT_STATUS | END | 종료 |
왜 코드 테이블을 써야 할까?
1. 유지보수가 쉽다.
상태명을 바꾸더라도 데이터 수정이 필요 없습니다.
2. 다국어 지원이 쉽다.
PRG
한국어 : 진행중
영어 : In Progress
3. 공통 코드 재사용 가능
- 과제상태
- 결재상태
- 지급상태
- 사용자권한
모두 동일한 구조로 관리할 수 있습니다.
상태 전이(State Transition) 관리도 중요하다
예를 들어
작성중 → 신청
신청 → 승인대기
승인대기 → 승인완료
승인완료 → 진행중
하지만
종료 → 작성중
이런 전이는 허용하면 안 됩니다.
추천 테이블
STATUS_TRANSITION
FROMTO
| WRT | REQ |
| REQ | APV |
| APV | PRG |
| PRG | END |
이렇게 관리하면 시스템 변경에 유연하게 대응할 수 있습니다.
화면에서 많이 발생하는 문제
상태값에 따라 버튼 활성화
예시
상태수정삭제집행
| 작성중 | O | O | X |
| 진행중 | O | X | O |
| 종료 | X | X | X |
상태값이 권한까지 결정하는 경우가 많습니다.
개발자가 반드시 고려해야 하는 것
감사 로그
누가 언제 상태를 변경했는지 기록해야 합니다.
추천 테이블
STATUS_HISTORY
| 과제번호 | 이전상태 | 변경상태 | 변경자 | 변경일시 |
감사 대응 시 매우 중요한 데이터가 됩니다.
연구행정 시스템에서 자주 사용하는 상태 코드
WRT : 작성중
REQ : 신청
APV : 승인
REJ : 반려
PRG : 진행중
SUS : 중지
END : 종료
CLS : 정산완료
제가 설계한다면 이렇게 합니다
PROJECT
PROJECT_STATUS
STATUS_HISTORY
CODE_MASTER
CODE_DETAIL
STATUS_TRANSITION
상태 관리 로직은 서비스 레이어에서 처리하고, 화면에서는 코드값을 조회해서 사용하는 구조를 선호합니다.
마무리
연구행정 시스템은 상태값이 많고 업무 규칙도 복잡합니다.
처음부터 상태 코드를 체계적으로 설계하지 않으면 프로젝트 후반부에 유지보수가 매우 어려워집니다.
특히 산학협력단 시스템은 과제, 연구비, 결재가 모두 연결되어 있기 때문에 상태 관리와 코드 테이블 설계가 시스템 품질을 좌우한다고 해도 과언이 아닙니다.
다음 글에서는 실제 개발에서 많이 사용하는 주제인 **「연구비 관리 시스템 권한 설계 방법과 사용자 역할 관리」**에 대해 알아보겠습니다.
'개발기초' 카테고리의 다른 글
| 개발기초 연구비 관리 시스템 주요 기능과 화면 설계 방법 (개발자 실무 가이드) (0) | 2026.07.04 |
|---|---|
| 개발기초 국가연구개발사업 연구비 집행 절차 총정리 (산학협력단 실무 가이드) (0) | 2026.06.29 |
| 개발기초 연구비 관리 시스템이란? 대학과 연구기관은 왜 이런 시스템이 필요할까 (0) | 2026.06.28 |
| 개발기초 KOSA 10편 개발자가 KOSA 경력관리를 반드시 해야 하는 이유 (실제 경험 기반) (0) | 2026.06.27 |
| 개발기초 KOSA 9편 경력증명서 발급 방법 총정리 (이직·프리랜서·공공사업 활용법) (0) | 2026.06.23 |