예산 집행 관리 시스템 개발 검색 필터 설계, 먼저 정해야 하는 이유

결론 먼저: 검색·필터를 나중에 정하면 재개발·일정 지연·데이터 구조 변경이 시작됩니다

결산 자료 요청 메일 한 통이 일정을 무너뜨리는 장면이 반복됩니다. "본부별로, 사업비와 인건비를 나눠서, 집행 확정 건만 뽑아 달라"는 요청이 들어왔는데 예산 과목이 메모 성격의 자유 텍스트로 저장돼 있다면, 그때부터는 필터 추가가 아니라 컬럼 추가와 기존 데이터 이관 작업이 시작됩니다. 결국 화면 하나 추가하려다 구조를 다시 여는 상황이 되는 거죠.

검색·필터는 화면 기능이 아니라 구조 요구사항이다

• 조건값이 컬럼으로 코드화돼 있어야만 필터가 작동합니다
• 기간·부서·집행 상태처럼 자주 쓰는 조건은 인덱스 설계에 미리 반영해야 조회가 느려지지 않습니다
• 합계·부서별 비교 같은 집계 로직도 필터 조건에 맞춰 함께 설계됩니다

후반 확정과 초기 확정의 차이는 표 한 장으로 정리됩니다.

1단계: 예산 집행 내역 조회에 필요한 기본 필터 항목 도출하기

행사가 끝나고 정산 자료를 만들다 보면 "그때 인쇄비가 얼마였더라" 한 번 찾으려고 엑셀을 반나절 뒤지게 됩니다. 조회 화면 설계는 바로 이 순간을 기준으로 잡으면 됩니다. 개발자 언어가 아니라, 실제로 검색하는 사람의 손움직임부터 따라가는 거죠.

'조회하지 않을 것'부터 지우기

필터를 도출할 때 흔히 "뭘 넣을까"부터 묻는데, 순서를 바꾸는 편이 낫습니다. 먼저 절대 그렇게는 검색하지 않는 조건을 지우고, 남는 것만 기본 필터로 삼는 방식입니다.

판단 기준은 실제 예산 집행 승인 흐름입니다. 집행 요구 → 지출결의 → 승인 → 완료 또는 불용으로 이어지는 과정에서 결의서에 기록되는 항목만 필터가 될 수 있습니다. 승인 단계에서 입력되지 않는 값은 필터로 만들어도 데이터가 비어 있을 뿐이니까요.

이 기준으로 좁히면 기본 필터는 대체로 다섯 가지로 정리됩니다.

2단계: 검색·필터 요구사항을 데이터베이스 설계로 연결하기 (흔한 실수 vs 권장 기준)

2단계: 검색·필터 요구사항을 데이터베이스 설계로 연결하기 (흔한 실수 vs 권장 기준)

"부서별로 걸고, 집행 상태로 걸고, 이번 분기 금액 범위로 조회하고 싶어요."

이 한 문장을 개발 착수 전에 정리했느냐, 아니면 시스템을 다 만들고 나서 던졌느냐에 따라 개발비와 일정이 갈립니다. 검색·필터 조건은 화면 옵션이 아니라 테이블 구조 그 자체를 바꾸는 요구사항이거든요.

흔한 실수 vs 권장 기준

왜 텍스트 한 줄 저장이 문제인가

3단계: 관리자 권한별 조회 범위와 필터 노출 차등 설계

같은 예산 집행 화면을 열어도 총괄 관리자와 부서 담당자가 봐야 하는 데이터는 다릅니다. 총괄 관리자는 전사 집행 내역을 부서끼리 비교해야 하고, 부서 담당자는 소속 부서 예산만 추적하면 됩니다. 이 차이를 "관리자 권한 있음/없음" 두 급으로 넘기지 말고, 검색·필터 조건 단계에서부터 설계해 두는 게 핵심입니다.

필터는 '숨기는 게 아니라 거는 것'입니다

흔한 실수는 부서 선택 드롭다운을 화면에서 가리는 식으로 권한을 처리하는 경우예요. 버튼만 숨기면 다른 화면이나 직접 요청 경로로 데이터가 새어 나갈 수 있습니다. 판단 기준은 하나로 충분합니다.

필터가 UI 장식이 아니라 조회 조건에 실제로 붙어 있어야, 부서 담당자가 조건을 아무리 바꿔도 소속 부서 밖의 집행 내역은 애초에 조회되지 않습니다.

권한별 필터 노출 차등 설계 예시

4단계·요약 체크리스트: 사전 정의로 개발비 절감하는 실행 순서와 함께

오픈 후 어느 날 "집행 부서별로만 걸러서 보고 싶다"는 요청이 하나 들어옵니다. 화면상으로는 드롭다운 하나 추가하는 일처럼 보이지만, 개발 관점에서는 전혀 다른 이야기가 시작됩니다.

왜 후기 추가가 더 비쌀까

검색·필터를 나중에 붙이면 작업이 세 겹으로 쌓입니다.

| 테스트 | 전체 시나리오 테스트에 흡수 | 변경 재테스트 + 기존 기능 회귀 점