예산 집행 관리 시스템 개발에서 담당자가 바뀌어도 시스템이 멈추지 않게 하는 인수인계 설계법을 소개합니다. 모듈화, 문서 자동화, 코딩 컨벤션부터 필수 산출물 목록까지 실무 중심으로 정리했습니다.
- 핵심 요약: 인수인계가 어려운 시스템의 공통점과 해결 원칙
- 인수인계가 쉬운 시스템 구조 설계법: 모듈화·코딩 컨벤션·문서 자동화
핵심 요약: 인수인계가 어려운 시스템의 공통점과 해결 원칙
인수인계가 무너지는 순간을 떠올려 보면, 시스템이 멈춰서가 아니라 아무도 규칙을 몰라서입니다. "이 코드표는 작년에 누가 왜 바꿨지?", "이 품의는 왜 관리자 승인 없이 통과하지?" — 이런 질문에 답할 사람이 퇴사하면, 잘 돌아가던 예산 집행 시스템도 하루아침에 오브제가 됩니다.
사람 머릿속에만 있는 것들이 문제다
인수인계가 어려운 시스템에는 공통점이 있습니다.
- 관리자 권한 체계: 누가 어떤 메뉴를 열 수 있는지가 구두로만 전달됨
- 전결 규칙: 금액 구간별 승인 라인이 문서가 아니라 담당자의 감으로 존재
- 코드표 변경 이력: 예산과목 코드를 언제, 왜 바꿨는지 기록이 없음
즉, 시스템은 있는데 운영 지식이 시스템 밖에 있는 겁니다.
해결 원칙 세 가지
| 항목 | 흔한 방식 | 권장 원칙 |
|---|---|---|
| 시스템 구조 | 통짜로 구축, 담당자만 이해 가능 | 모듈화해 새 담당자가 구조를 빠르게 파악 |
| 문서화 | 인수인계 직전 별도 작업 | 개발 과정에서 자동 생성 |
| 인계 시점 | 마지막 1~2주 급조 | 퇴사 3개월 전부터 절차적 인계 기간 확보 |
인수인계가 쉬운 시스템 구조 설계법: 모듈화·코딩 컨벤션·문서 자동화
인수인계가 쉬운 시스템 구조 설계법: 모듈화·코딩 컨벤션·문서 자동화
예산 시스템 인수인계에서 가장 흔한 사고는 "사람이 문서를 넘기는 구조"입니다. 퇴사 두 달 전에 매뉴얼 쓰라고 하고, 넘겨받은 담당자는 문서와 실제 코드가 다를 때마다 전임자에게 연락하다가 결국 시스템을 다시 만들자고 제안하죠. 이 악순환을 끊는 방향은 하나입니다. 사람이 아니라 구조가 인수인계를 하게 만드는 것.
① 모듈화: 전체가 아니라 한 조각만 이해해도 운영되게
예산 업무는 신청 → 심사 → 집행 → 정산으로 흐름이 선형합니다. 이 흐름을 하나의 거대한 로직으로 묶어두면 담당자는 시스템 전체를 다 이해해야 손댈 수 있습니다. 대신 각 단계를 독립 모듈로 쪼개고, 모듈 간에는 입출력 데이터 정의만 남겨두세요.
예를 들어 심사 모듈은 "어떤 신청 건이 들어왔고, 승인·반려·보완 중 무엇을 판단했는지"만 주고받으면 됩니다. 심사 담당자가 집행 모듈의 결제 로직까지 알 필요가 없어지는 거죠. 인수인계도 모듈 단위로 쪼개지면, 새 담당자는 자기가 맡은 모듈 하나만 파고 들어도 운영이 가능해집니다.
판단 기준은 단순합니다. "이 모듈의 담당자가 다른 모듈 코드를 열어봐야 하는가?" — 예라면 모듈 경계가 아니라 데이터 연결 지점에서 설계를 다시 보세요.
② 코딩 컨벤션: 해석 시간이 인수인계 기간입니다
반드시 넘겨야 할 산출물 vs 놓치기 쉬운 것: 문서 목록 총정리
인수인계가 무너지는 지점은 대개 정해져 있다. 요구사항 정의서나 ERD는 폴더에 고스란히 남는데, 사람 머릿속과 채팅창에만 존재하던 것들이 담당자와 함께 사라진다. 개발 단계에서 만들어진 산출물은 파일로 남지만, 운영을 하면서 생겨난 규칙은 어디에도 기록되지 않기 때문이다.
기본 vs 놓치기 쉬운 산출물
| 기본 산출물 (보통 넘어옴) | 놓치기 쉬운 산출물 (사람과 함께 사라짐) |
|---|
| 요구사항 정의서 | 관리자 계정·권한 목록과 승인 �
담당자 퇴사 전 인수인계 절차: 기간 설정과 실제 실패 사례
"결제 오류가 났는데 고칠 수 있는 사람이 없습니다." 인수인계를 2일만 받고 담당자가 떠난 뒤 가장 자주 듣는 문장입니다. 사전등록 결제는 신용카드·카카오페이·가상계좌에 회원 등급별 요금 자동 계산까지 얽혀 있어서, 아는 사람 한 명이 사라지면 오류 하나가 등록 업무 전체를 멈춥니다.
4주에 걸쳐 나눠 끝내는 절차
핵심은 기간을 '노력'이 아니라 일정에 못 박힌 절차로 확보하는 것입니다.
- 퇴사 4주 전 — 산출물 목록 확정: 예산 신청부터 정산 마감까지 필요한 문서·데이터 목록
- 퇴사 3주 전 — 문서 갱신 및 누락 분석: 오래된 화면 설명을 걷어내고 빠진 항목 표시
- 퇴사 2주 전 — 병행 운영: 신규 담당자가 실제로 처리하고, 기존 담당자가 옆에서 지켜보는 섀도잉
- 퇴사 1주 전 — 권한 이관 및 최종 질의응답
성패를 가르는 기준은 문서 분량이 아닙니다. "혼자만 할 수 있는 업무가 0개가 되었는가"로 판단하세요.
실패 장면에서 뽑은 대응 기준
| 항목 | 실패 장면 | 대응 기준 |
|---|---|---|
| 인수인계 기간 | 2일 압축 후 결제 오류를 아무도 수정 못함 | 4주 절차를 일정에 확정 |
| 관리자 권한 | 비밀번호를 아는 사람이 퇴사 | 개인이 아닌 역할 단위 권한 관리 |
인수인계 이후의 지식관리(KM) 체계와 최종 체크리스트
인수인계 이후의 지식관리(KM) 체계와 최종 체크리스트
인수인계를 한 번 했다고 끝이 아닙니다. 진짜 리스크는 인수인계 문서를 만든 뒤 6개월쯤 지나서 찾아옵니다. 전결 한도가 바뀌었는데 문서엔 옛 규칙이 남아 있고, 코드표는 시스템에만 추가됐는데 매뉴얼엔 없는 상태가 되는 거죠. 담당자가 또 바뀌는 순간, 그 문서는 오히려 오해를 만듭니다.
위키 없이는 시스템 변경도 못 하게 만드는 규칙
해결책은 의외로 단순한 규칙 하나입니다. "위키 수정 없이는 시스템에 반영하지 않는다."
- 코드표에 새 예비비 항목을 추가하려면, 먼저 위키의 코드표 문서를 수정하고 그 링크를 변경 요청에 첨부한다
- 전결 규칙·승인 라인이 바뀌면 위키의 권한 문서 갱신이 선행된다
- 시스템 설정 화면을 열기 전에 "위키에 있는 게 최신본인가"를 확인하는 게 습관이 된다
이 규칙이 작동하려면 위키에 버전 히스토리가 꼭 필요합니다. 누가 언제 어떤 항목을 고쳤는지 남아야 "이 규칙이 언제부터 적용된 건지"를 따라갈 수 있으니까요. 트리 구조로 문서를 계층화하고 검색이 되며, PIN 인증·UID 화이트리스트 같은 접근 제어까지 걸 수 있는 사내 위키 시스템이 이 용도에 맞습니다. 비오케이솔루션은 시스템 개발과 함께 이런 사내 위키·운영 문서 체계를 통합 구축해 줍니다.