예산 집행 관리 시스템 개발 시 상태값을 정리하는 기준을 정리했습니다. 편성·배정·집행·정산 프로세스 도표화, 코드 네이밍 표준화, 상태 전이 규칙과 이력 관리까지 실무에서 바로 적용할 수 있는 설계 방법과 주의사항을 안내합니다.
- 결론 먼저: 상태값은 '프로세스 단계'와 '문서화'에서 출발한다
- 1단계 - 예산 프로세스 단계별 상태값 정의: 편성→배정→집행→정산
결론 먼저: 상태값은 '프로세스 단계'와 '문서화'에서 출발한다
결론부터 말씀드리면, 예산 집행 관리 시스템에서 가장 자주 터지는 문제는 기능 부족이 아니라 상태 정의의 불일치입니다. 개발팀은 '집행'이라고 부르는 상태를 회계팀은 '지급 완료'로 이해하고, 실무 부서는 그냥 "결재 올렸으니 끝난 거 아니냐"고 생각하는 순간, 시스템은 이미 어긋나기 시작합니다.
그래서 정리 순서가 중요합니다. 화면 설계나 DB 스키마보다 먼저 해야 할 일이 두 가지인데요.
1단계: 프로세스 단계부터 도표로 그린다
코드를 한 줄 짜기 전에 편성 → 배정 → 집행 → 정산 흐름을 한 장짜리 도표로 그려보세요. 여기서 핵심은 단계가 아니라 단계 사이의 경계입니다.
| 구분 | 흔한 실수 | 권장 기준 |
|---|---|---|
| 상태 정의 | 부서별 쓰는 말을 그대로 코드화 | 프로세스 단계별로 먼저 도표화 후 코드 부여 |
| 네이밍 | 담당자마다 '진행중/처리중/완료' 혼용 | 코드·한글명 규칙을 문서로 고정 |
| 분기 처리 | 승인·반려만 있고 보류는 운영 중 급조 | 전이 규칙(어느 상태에서 어느 상태로 갈 수 있는지)을 사전 정의 |
| 이력 관리 | 최종 상태만 저장 | 상태 변경 시점·변경자 로그 함께 설계 |
1단계 - 예산 프로세스 단계별 상태값 정의: 편성→배정→집행→정산
"이 건 지금 어디까지 진행된 거예요?" 결의서를 열어보니 진행여부 칸에 '진행중'이라고만 적혀 있다. 승인 전인지, 집행 직후인지, 정산만 남은 건지 아무도 못 읽는다. 상태값 설계는 바로 이 지점에서 시작한다.
흐름도를 먼저, 상태값은 나중
시스템 화면부터 그리지 말고, 지금 수기·엑셀로 돌아가는 절차를 편성→배정→집행→정산 순서로 쭉 펼쳐 그려보자. 상태값은 이 흐름 위에서 잘라낸다.
잘라내는 기준은 두 가지뿐이다.
- 누가 승인하는가 — 승인자가 바뀌는 지점이 곧 상태의 경계
- 어떤 증빙이 붙는가 — 증빙 서류 종류가 바뀌는 지점도 상태의 경계
이 기준으로 대표적인 상태 구조를 잡으면 이렇다.
| 단계 | 상태값 예시 | 반드시 답해야 할 질문 |
|---|---|---|
| 편성 | REQ → 확정 | 편성 확정 권한은 누구에게 있는가 |
| 배정 | 부서 배정 → 배정 확정 | 확정 전 부서 금액 수정이 가능한가 |
| 집행 | 신청 → 승인 → 집행 중 | 반려는 별도 상태로 둘 것인가 |
| 정산 | 정산 신청 → 완료 | 증빙 누락 시 어느 상태로 되돌리는가 |
질문에 답이 안 나오는 행이 있다면, 그 단계는 아직 설계가 덜 된 것이다.
2단계 - 코드 네이밍·공통 코드 표준화와 상태 전이 규칙
현장에서 자주 마주치는 장면이 하나 있다. 승인 요청 화면에 뜬 '반려'를 예산 담당자는 "보완해서 다시 내면 되는 것"으로 읽고, 실무 부서는 "취소당한 것"으로 읽는다. 코드 네이밍과 한글명이 부서마다 다르게 해석되는 순간, 화면·보고서·알림 문구가 제각각 어긋나기 시작한다.
코드 네이밍, 규칙부터 못 박기
- 접두사로 도메인 식별:
BDGT_EXEC_(예산 집행)처럼 코드만 봐도 어떤 업무인지 알리기 - 자리수 고정: 숫자는
01,02두 자리로 통일, 나중에 끼워 넣을 일 없게 - 대문자 + 언더스코어 통일: 대소문자 혼용은 검색도 어렵고 오타의 온상
- 한글명은 부서 공통 언어로: 코드표에 '반려'로 정했으면 어디서도 '기각'이라 쓰지 않기
| 항목 | 흔한 실수 | 권장 기준 |
|---|---|---|
| 코드 길이 | 그때그때 2~4자 제멋대로 | 접두사 + 고정 자리수 |
| 대소문자 | budget_exec, BUDGET_EXEC 혼용 | 대문자·언더스코어 하나로 통일 |
| prefix | 팀마다 다르거나 생략 | 도메인 접두사 고정(BDGT_EXEC_) |
| 한글명 | 부서별 표현 혼재 | 코드표에 정의한 명칭만 사용 |
3단계 - 상태 변경 이력 로그와 감사 대응, 운영 중 유지보수
상태 설계를 아무리 잘해도, 운영이 시작되고 나면 반드시 마주치는 질문이 하나 있습니다. "이 집행 건은 왜 집행 전 단계로 되돌아갔나요?" 감사 자료 요청이 들어왔을 때 답을 못 하면, 시스템이 아무리 잘 돌아가도 신뢰는 무너집니다. 그래서 이력 로그는 선택이 아니라 설계 단계부터 박아두어야 하는 부분입니다.
이력 로그에 무엇을 남길 것인가
상태가 바뀔 때마다 다음 네 가지는 반드시 기록되어야 합니다.
- 변경 전 상태 코드 / 변경 후 상태 코드
- 변경자 (로그인 계정 기준)
- 변경일시
- 변경 사유 (반려·보류 등 사유 입력을 필수로)
여기서 자주 놓치는 지점이 하나 더 있습니다. 상태 자체뿐 아니라 승인권자 변경 이력까지 별도 테이블로 남겨야 한다는 점입니다. 결재선이 중간에 바뀌면 "누가 승인했는가"와 "그 사람이 그 시점에 승인권자였는가"가 달라지기 때문입니다. 상태 이력과 권한 이력을 분리해 두면 감사 질문에 데이터로 답할 수 있습니다.
운영 중 상태를 추가·변경할 때 점검할 영향 범위
1년쯤 운영하면 "반려 후 재검토 상태를 하나 더 추가해야 할 것 같은데요"라는 요구가 반드시 나옵니다. 이때 코드만 추가하면 끝이 아닙니다.
상태값 정의서 템플릿·체크리스트로 마무리하기
상태값 정의서 템플릿·체크리스트로 마무리하기
설계가 끝났다면 이제 문서로 남기는 단계예요. 상태값은 만들어 놓고 방치하면 어느 순간 "이 상태가 뭐였지?"부터 다시 시작하게 됩니다. 그럴 때 바로 꺼내 쓸 수 있는 정의서 템플릿과 점검용 체크리스트로 마무리해 보세요.
바로 복사해서 쓰는 상태값 정의서 템플릿
| 코드 | 한글명 | 정의 | 진입 조건 | 퇴출 조건 | 승인권자 | 화면 노출 | 알림 발생 |
|---|---|---|---|---|---|---|---|
| BUD_DFT | 편성임시 | 예산 편성 중, 미확정 | 편성 등록 | 편성 확정/삭제 | 부서장 | 담당자만 | 없음 |
| BUD_APR | 편성승인 | 편성 확정, 집행 가능 | 부서장 승인 | 집행 시작/반려 | 재무팀 | 전체 | 팀 알림 |
| BUD_RUN | 집행중 | 실제 집행 진행 | 집의 집행 등록 | 집행 완료 | - | 전체 | 없음 |
| BUD_CLS | 정산완료 | 집행·정산 마감 | 정산 확정 | 없음(종단) | 재무팀 | 전체 | 완료 알림 |
여기서 핵심은 진입·퇴출 조건 컬럼이에요. "집행중" 상태가 언제 시작되고 언제 끝나는지 문장으로 쓰지 못하면, 개발 단계에서 반드시 해석이 갈립니다.