[🛠] 두 자동화를 합치려다 영업과 직원 행정을 다시 나눴다

✨ GPT-5.6 Sol의 요약 　

이미 돌아가던 영업·문자 업무를 보존하면서 인바운드와 직원 행정까지 확장할 수 있는 운영 자동화 구조를 고민한 기록.

이미 돌아가던 두 프로그램을 합치려 했다

회사 내부에는 이미 서로 다른 방향으로 발전한 두 자동화 프로그램이 있었다.

하나는 전임자가 먼저 구현해둔 문자 기반 연차 관리 프로그램이었다. 직원별 연차를 계산하고, 사용촉진 문자를 보내고, 문자로 들어온 신청을 해석해 승인과 반려까지 이어주는 서비스였다. Web과 backend, DB, Android 업무폰까지 이미 하나의 흐름으로 움직이고 있었다.

다른 하나는 내가 계속 다듬어온 공개 데이터 수집과 영업 자동화였다. 시설과 연락처를 모으고, Vox 아웃바운드에 연결해 실제 영업 활동으로 넘기는 구조였다.

처음에는 두 프로젝트를 한 저장소로 옮기면 통합이 될 것 같았다. 하지만 앞으로 붙이고 싶은 기능을 생각하니 단순한 폴더 합치기로는 부족했다.

• 기존 아웃바운드와 이어지는 인바운드 응대
• 직원 요청을 받아 행정 업무로 넘기는 흐름
• 재직증명서를 자동으로 만들고 전달하는 기능
• 직원·계약·현장 정보를 기준으로 권한을 나누는 기능
• 실패, 승인, 재처리와 감사 기록을 한곳에서 보는 운영 화면

그때부터 질문이 “두 코드를 어떻게 합칠까”에서 “앞으로 늘어날 업무를 어디에 놓아야 할까”로 바뀌었다.

기존 프로그램을 버리지 않기로 했다

문자 기반 연차 프로그램을 보면서 새로 만들고 싶은 마음이 컸다. 오래된 구조와 임시 설정도 보였고, 지금 기준으로 다시 설계하고 싶은 부분도 많았다. 요구사항만 가져와 새 코드로 옮기면 더 깔끔할 것 같았다.

그런데 자료를 하나씩 볼수록 그 프로그램에는 코드보다 더 중요한 것이 들어 있었다.

• 실제 직원에게 보여주던 연차 결과
• 입사일을 기준으로 연차를 계산하는 방식
• 사용촉진 대상과 발송 시점
• 문자 신청을 날짜와 반차로 해석하는 규칙
• 신청, 승인, 반려와 결과 문자의 순서
• Android 업무폰이 문자를 보내고 받는 방식
• 운영자가 이미 사용하던 화면과 예외 처리

이걸 문서 몇 장으로 요약한 뒤 처음부터 다시 만들면, 새 코드는 깨끗해도 기존 사용자가 받던 결과가 달라질 수 있었다. 전임자가 실제로 완성해둔 수직 흐름을 내가 설계 취향만으로 없애서는 안 됐다.

그래서 기존 서비스를 먼저 그대로 재현하고, 화면과 계산 결과를 회귀 기준으로 남긴 다음, 문제 있는 부분을 기능별로 교체하는 쪽으로 방향을 바꿨다. 새 시스템은 기존 프로그램을 지우고 시작하는 것이 아니라, 기존 프로그램이 하던 일을 잃지 않은 채 더 큰 구조 안으로 들어와야 했다.

영업과 직원 행정은 같은 앱이 아니었다

프로젝트를 하나로 묶는다고 DB와 Runtime까지 하나로 만들면 또 다른 문제가 생긴다.

영업 자동화는 공개 데이터, 연락처, 통화 대상과 영업 결과를 다룬다. 직원 행정은 직원 정보, 문서 발급, 연차, 승인과 메시지를 다룬다. 두 영역은 운영 화면에서 함께 보일 수는 있지만 데이터의 성격도, 권한도, 장애가 미치는 범위도 달랐다.

영업 DB migration이 직원 행정 배포를 막거나, 연차 서비스 장애 때문에 영업 수집까지 같이 멈추는 구조는 원하지 않았다. 계정과 credential, queue, backup과 rollback도 업무별로 나뉘어야 했다.

결국 저장소는 하나로 두되 영업과 직원 행정을 독립 앱으로 나누기로 했다. 운영 화면은 두 앱을 한곳에서 탐색하게 해주지만 DB를 직접 읽지 않고, 각 backend가 자기 데이터와 권한을 책임진다.

아웃바운드에서 인바운드와 행정 업무로

기존 영업 자동화는 바깥으로 전화를 거는 아웃바운드 흐름에 가까웠다. 15일에는 여기에 인바운드를 어떻게 붙일지도 오래 생각했다.

전화가 들어왔다는 이유만으로 모든 요청을 통화 시스템 안에서 처리할 필요는 없었다. 통화는 요청을 받아 적절한 업무로 넘기는 입구일 수 있다. 재직증명서 요청이 들어오면 본인확인과 발급 업무로 넘기고, 발급된 문서는 별도의 전달 절차를 거쳐야 한다. Web이나 모바일에서 같은 요청이 들어오더라도 결국 같은 행정 업무로 합쳐져야 했다.

재직증명서부터 시작하기로 한 이유도 여기에 있었다. 요청 접수, 직원 기준정보 확인, 문서 생성, 승인, 전달, 실패 처리와 감사까지 운영 자동화에 필요한 흐름을 한 번에 확인할 수 있는 첫 기능이었다.

한 기능만 잘 만드는 것이 아니라, 이후 다른 직원 행정 업무가 들어와도 같은 경계를 재사용할 수 있어야 했다.

기준정보를 다시 만들면 안 됐다

회사에서는 이미 다른 시스템으로 직원과 계약, 현장 배정을 관리하고 있었다. 자동화에는 그 정보가 필요하지만, 우리 쪽에 직원 관리 원장을 하나 더 만들면 곧 두 시스템의 값이 어긋난다.

외부 시스템은 계속 기준정보를 소유하고, 우리 쪽은 필요한 자료를 읽어 와 검증된 snapshot으로 남기는 쪽이 맞았다. 원장을 수정하는 기능과 그 정보를 이용해 행정 사건을 처리하는 기능을 분리해야 했다.

문제는 실제 내려받기 파일의 형식도, 안정적인 직원 식별자도 아직 확인하지 못했다는 점이었다. 화면에 보이는 번호를 사번이라고 부르거나, 내려받기 기능을 확인도 하지 않고 Excel이라고 적으면 그다음 설계가 전부 거짓 전제 위에 올라간다.

그래서 모르는 것은 미결정으로 남겼다.

그날 확정한 경계

• 저장소는 하나로 두되 영업과 직원 행정은 독립 앱으로 나눈다.
• DB, Runtime, credential, queue, backup과 rollback은 업무별로 분리한다.
• 통합 운영 화면은 각 backend API를 사용하고 DB를 직접 읽지 않는다.
• 문자 기반 연차 서비스는 현재 결과를 회귀 기준으로 남긴 뒤 기능별로 교체한다.
• 직원·계약·현장 기준정보는 기존 시스템이 소유하고, 자동화 쪽에는 검증된 snapshot만 남긴다.
• 첫 vertical slice는 재직증명서 요청부터 발급·승인·전달·실패 처리까지로 잡는다.

15일에는 코드를 거의 쓰지 않고 이 경계와 기존 서비스 이전 순서를 정리했다.