고객이 요청할 때마다 만들면 좋은 프로그램이 될까

요청받은 기능과 필요한 기능은 다를 때가 있다

"여기에 버튼 하나만 추가해 주세요." "엑셀로 다운로드할 수 있게 해 주세요." "정산 금액을 담당자가 직접 수정할 수 있으면 좋겠어요." 맞춤형 업무 시스템을 만들다 보면 이런 요청을 자주 받는다.

처음엔 요청을 빨리, 정확하게 만들어 주는 것이 좋은 개발이라고 생각하기 쉽다. 요청에는 현장의 불편이 그대로 담겨 있으니 틀린 말도 아니다. 하지만 들여다보면 고객이 요청한 기능과 실제로 문제를 없애는 기능이 다를 때가 많다. 한 기업만을 위해 만드는 시스템에서도 마찬가지다.

요청은 대개 증상이고, 원인은 그 뒤의 업무 흐름에 있다. 아래 다섯 가지 사례는 업무 시스템을 만들어 본 사람이라면 한 번쯤 들어 봤을 요청들이다.

사례 1, 엑셀 업로드 버튼을 하나 더 만들어 달라는 요청

사례 1은 주문서 업로드다. 한 회사가 여러 거래처에서 주문서를 받는다. 담당자는 엑셀 업로드 버튼이 필요하다고 요청한다. 버튼을 만들자 이번엔 다른 양식도 받게 해 달라고 하고, 그다음엔 거래처별 상품 코드를 자동으로 바꿔 달라는 요청이 이어진다.

업무를 살펴보니 담당자는 매일 거래처마다 다른 엑셀 컬럼을 정리하고, 상품 코드를 바꾼 뒤에야 업로드를 하고 있었다. 진짜 문제는 버튼이 없다는 게 아니었다. 서로 다른 주문 데이터를 사람이 매번 손으로 표준화해야 한다는 점이었다.

그래서 해결 방향도 달라진다. 거래처별 파일 형식을 등록해 두고, 컬럼 매핑과 상품 코드 변환을 시스템이 하게 하고, 오류 검증과 예외 확인을 붙인다. 요청받은 버튼 하나를 더 다는 것보다 주문 수집 흐름 전체를 바꾸는 편이 반복 작업을 훨씬 크게 줄인다.

사례 2, 정산 금액을 직접 고치게 해 달라는 요청

사례 2는 월말 정산이다. 월말마다 시스템이 계산한 정산액과 담당자가 따로 계산한 금액이 다르다. 담당자는 금액을 손으로 고칠 수 있는 기능을 요청한다.

그런데 원인을 따라가 보면 거래처별 계약 단가, 배송비, 수수료, 적용 기간이 시스템에 제대로 들어가 있지 않은 경우가 있다. 이때 수정 버튼만 만들어 주면 이번 달은 맞출 수 있어도 다음 달에 같은 일이 또 생긴다. 고치는 사람도, 고친 이유도 남지 않는다.

이런 경우엔 거래처별 계산 기준을 등록해 자동으로 적용하게 하고, 그래도 필요한 예외 조정에는 사유와 승인자, 변경 전후 금액을 남기는 편이 좋다. 핵심은 '수정할 수 있는 기능'보다 '수정할 필요가 줄어드는 구조'를 먼저 고민하는 것이다.

사례 3, 재고 수량을 직접 바꾸게 해 달라는 요청

사례 3은 재고다. 실물은 100개인데 전산에는 95개로 보인다. 재고 수량을 직접 고칠 수 있게 해 달라는 요청이 들어온다.

하지만 차이가 생긴 이유는 여러 가지일 수 있다. 입고 누락, 출고 중복 차감, 반품 미반영, 동시 처리 오류 같은 것들이다. 숫자만 고치면 당장은 맞지만 원인은 그대로 남아서, 다음 재고 실사 때 또 어긋난다.

그래서 입고·출고·반품·이동·재고 조정을 각각 다른 이벤트로 구분하고, 언제 누가 무엇을 바꿨는지 추적할 수 있어야 한다. 재고 조정 기능 자체는 필요하다. 다만 조정 사유와 승인 절차를 함께 설계해 두는 편이 안전하다.

사례 4, 담당자가 바뀌면 일이 멈춘다는 요청

사례 4는 사람에게 묶인 업무다. 오래 일한 담당자가 휴가를 가자, 대신 맡은 직원이 거래처별 예외 조건과 정산 관행을 알지 못해 일이 멈춘다. 고객은 매뉴얼 화면을 만들어 달라고 요청한다.

매뉴얼도 도움은 된다. 하지만 핵심은 업무 규칙이 특정 사람의 기억 속에만 있다는 점이다. 매뉴얼은 누군가 따로 써서 고쳐 나가야 하고, 쓰는 사람이 바쁘면 금방 낡는다.

거래처별 배송 조건, 예외 처리 기준, 승인 흐름을 시스템에 등록하고 처리 이력을 남기면 담당자가 바뀌어도 일을 이어 갈 수 있다. 모든 예외를 자동화할 필요는 없다. 그래도 판단 기준만큼은 개인의 기억이 아니라 회사의 자산으로 남아야 한다.

사례 5, 대표가 볼 보고서를 만들어 달라는 요청

사례 5는 보고서다. 대표는 매일 주문 수, 매출, 출고량을 묻고, 담당자는 통계 대시보드를 요청한다. 겉으로는 화면 하나 더 만드는 일처럼 보인다.

그런데 영업팀은 주문일 기준으로, 물류팀은 출고일 기준으로 숫자를 집계하고 있다. 취소와 반품을 어느 시점에 빼는지도 팀마다 다르다. 이 상태에서 그래프부터 만들면 보고서마다 숫자가 달라지고, 회의는 어느 숫자가 맞는지 따지는 자리가 된다.

먼저 매출·주문·출고·반품의 정의와 집계 시점을 하나로 맞추고, 그다음에 대시보드를 만드는 편이 좋다. 보기 좋은 그래프보다 믿을 수 있는 데이터가 먼저다.

기능 요청을 받았을 때 확인할 다섯 가지

다섯 사례를 겪고 나면 요청을 받았을 때 던질 질문이 정리된다. 첫째, 왜 필요한가. 지금 어떤 불편이나 오류가 생기고 있는지부터 묻는다. 둘째, 얼마나 자주 생기는가. 매일 반복되는 일인지, 가끔 있는 예외인지에 따라 답이 달라진다.

셋째, 누가 영향을 받는가. 한 사람의 불편인지, 여러 부서가 얽힌 문제인지 본다. 넷째, 기존 업무 흐름이나 규칙을 바꿔서 해결할 수는 없는가. 다섯째, 기능을 더했을 때 다른 업무나 데이터의 일관성이 흔들리지 않는가.

모든 요청을 이렇게 복잡하게 따질 필요는 없다. 단순한 오류 수정이나 분명한 화면 개선은 빨리 처리하는 편이 좋다. 다만 데이터를 처리하는 방식이나 업무 기준을 바꾸는 요청이라면 원인을 확인하는 과정을 건너뛰지 않는 편이 좋다.

중요한 것은 기능의 개수가 아니다

고객의 요청을 적극적으로 반영하는 것은 중요하다. 그렇지만 요청이 올 때마다 기능을 덧붙이기만 하면 버튼과 예외 로직이 계속 늘어난다. 결국 한 기능을 고칠 때마다 다른 업무가 영향을 받는 구조가 된다.

그래서 개발자는 "그 기능은 안 됩니다"라고 말하기보다 이렇게 설명할 수 있어야 한다. "말씀하신 기능도 만들 수 있습니다. 다만 문제가 생기는 원인을 먼저 살펴보면 더 간단하고 오래가는 방법을 찾을 수 있습니다." 거절이 아니라 질문으로 대화를 여는 것이다.

고객은 현장 업무를 알고, 개발자는 그것을 시스템으로 옮기는 방법을 안다. 어느 한쪽만으로는 답이 나오지 않는다. 좋은 맞춤형 개발은 두 사람이 함께 문제를 정의하는 데서 시작된다.

회고

빠르게 기능을 만드는 능력은 중요하다. 하지만 같은 실수가 반복되지 않도록 업무 흐름과 기준을 설계하는 능력도 그만큼 중요하다. 요청 하나를 받았을 때 그 뒤의 흐름까지 한 번 따라가 보는 습관이 둘을 잇는다.

좋은 업무 프로그램은 기능이 많은 프로그램이 아니다. 불필요한 작업이 사라진 프로그램이다.

용어 쉽게 보기

글에 나온 용어를 개발자가 아닌 분도 읽을 수 있게 풀었다.