모호한 요청을 실행 가능한 범위로 바꾸는 일

“수기로 관리하던 업무를 사내 웹 서비스로 옮겨 달라”는 요청을 받았다. 방향은 분명했지만 무엇을 어디까지 옮겨야 하는지는 정해지지 않은 상태였다. 기존 문서는 30개 탭으로 구성돼 있었고, 다른 내부 서비스와 연결해야 한다는 요구도 섞여 있었다. 이 문장만으로 개발을 시작하면 화면은 빠르게 만들 수 있어도 전환 대상과 완료 기준이 계속 흔들릴 가능성이 컸다.

처음 한 일은 요청을 기능 단위로 다시 쓰는 것이었다. 데이터베이스 연동, 수기 입력 유지, 고객 관리 시스템 연동, 출근 데이터 연동, 통합 인증, 역할별 권한으로 요구사항을 나눴다. 하나의 포털을 만든다는 말 안에는 데이터를 어디서 가져올지, 기존 작업 방식을 얼마나 남길지, 누가 어떤 정보에 접근할지 같은 서로 다른 문제가 들어 있었다. 요구사항을 분리하고 나니 당장 구현할 부분과 관계 부서의 협의가 필요한 부분도 구별할 수 있었다.

개발 주체도 초기에 정해야 했다. 지원 조직과 직접 개발 조직 가운데 어디에서 맡을지 판단이 필요했다. 인프라와 실행 환경은 지원 조직이 맡고, 서비스 개발은 직접 진행하는 것으로 역할을 나눴다. 담당을 정하는 일은 단순한 업무 배분이 아니었다. 이후 변경 요청을 누가 판단하고 운영 책임을 어디까지 질 것인지 정하는 과정에 가까웠다.

범위를 줄이는 데에는 원본을 직접 확인하는 일이 가장 효과적이었다. 30개 탭을 모두 살펴보니 빈 탭과 사본, 옛 버전이 섞여 있었다. 이름만 보고 전부 이전 대상으로 잡았다면 불필요한 기능까지 새 시스템에 재현할 뻔했다. 실제 업무에 쓰이는 항목을 추려 전환 대상을 7개로 확정했다. 기존 서비스 세 곳의 저장소와 개발 데이터베이스 연결 구조도 확인해, 새 화면만 설계하고 연동 조건은 뒤늦게 발견하는 일을 피하려 했다.

모든 기능을 한 번에 통합하는 대신 1차 오픈과 후속 통합을 나눴다. 첫 버전에서는 기존 시스템을 링크로 연결해 접근 경로부터 한곳에 모으고, 실제 데이터 통합은 단계적으로 진행하기로 했다. 완성된 통합만을 목표로 삼으면 인증과 권한, 여러 데이터 연결이 모두 준비될 때까지 공개가 늦어진다. 반대로 링크 연결을 최종 상태로 받아들이면 수기 업무를 줄이려던 목적을 달성하기 어렵다. 그래서 빠른 공개는 중간 단계로 두고, 통합해야 할 범위는 별도로 남겼다.

이번 일을 돌아보면 모호한 요청을 구체화한다는 것은 요구사항 문서를 길게 만드는 작업이 아니었다. 실제 사용 대상을 확인해 범위를 줄이고, 개발과 인프라의 책임을 나누며, 지금 제공할 가치와 나중에 해결할 통합 문제를 구분하는 일이었다. 특히 기존 자료의 제목이나 개수보다 실제 사용 여부를 확인해야 한다는 점이 중요했다. 빠른 1차 오픈도 범위를 흐리는 타협이 아니라, 후속 전환 범위를 분명히 합의했을 때에만 유효한 선택이었다.