비개발자가 발주 정산 웹앱을 만들기까지
시연본을 보내기 직전에 전제가 무너졌습니다
화면 다섯 개를 만들고 모바일까지 맞춘 다음, 대표에게 보고하고 나서야 “이미 다른 관리 시스템을 쓰고 있다”는 말이 나왔습니다. 만들던 것을 그 자리에서 멈췄습니다. 한숨이 절로 나왔습니다. 다만 지운 것은 아니고, 방향을 전면 도입에서 보조 도구 쪽으로 돌렸습니다.
앞서 사는 쪽과 만드는 쪽 사이에서 범위를 좁히는 판단을 한 번 정리했었고, 이 글은 그 다음 이야기입니다. 실제로 화면을 만들어 붙여보고, 비용을 계산하고, 발주 이후 흐름을 설계하다가 전제가 흔들려 방향을 바꾼 구간까지의 기록입니다. 저는 개발자가 아니라 회사 재무를 보는 실무자이고, 이 작업도 본업 사이사이에 붙여서 했습니다.
화면부터 만들었습니다
문서로 요구사항을 정리하는 단계는 이미 지났다고 봤습니다. 대표에게 보여줄 것이 필요했고, 글보다 화면이 빨랐습니다. 본사 대시보드, 지점 화면, 재고 관리, 계정과 권한 그리고 매뉴얼. 이렇게 다섯 벌을 만들었습니다.
파일을 나눠 만든 것이 첫 실수였습니다
다섯 개를 각각 별도 파일로 만들고 서로 링크로 연결했습니다. 제 PC에서는 잘 넘어갔습니다. 같은 폴더에 다섯 파일이 다 있으니까요.
모바일로 보내니 첫 화면만 열리고 나머지 메뉴는 눌러도 아무 반응이 없었습니다. 메신저나 파일 미리보기는 보통 파일 하나만 임시 공간에 풀어서 열기 때문에, 옆에 있어야 할 나머지 파일을 찾지 못합니다. 링크가 깨진 게 아니라 링크가 가리키는 파일이 그 기기에 없었던 겁니다.
문제가 하나 더 있었습니다. 상단 메뉴를 가로 스크롤 방식으로 만들어둔 탓에, 좁은 화면에서는 뒤쪽 메뉴 세 개가 화면 밖으로 밀려 있었습니다. 스크롤된다는 표시도 없었습니다. 쓰는 사람 입장에서는 그 메뉴가 아예 없는 것과 같습니다. 게다가 하위 화면에는 본사로 돌아가는 링크만 있고 다른 화면으로 바로 가는 길이 없어서, 한 번 들어가면 매번 되돌아 나와야 했습니다.
하나로 합치니 전달 문제가 사라졌습니다
해결은 단순했습니다. 다섯 화면을 파일 하나 안에 다 넣고, 메뉴를 누르면 해당 화면만 보이게 했습니다. 주소 뒤에 붙는 표시로 화면을 구분하도록 해서, 특정 화면으로 바로 여는 것도 가능하게 뒀습니다.
압축해서 다섯 파일을 묶어 보내는 방법도 있었지만 택하지 않았습니다. 받는 사람이 압축을 풀어야 하는 순간 전달은 실패합니다. 보고 받는 사람에게 작업을 시키지 않는 것이 시연본의 조건이라고 봤습니다.
다만 이건 시연용 임시 해법입니다. 실제로 운영하는 단계에서는 파일 하나에 다 넣는 방식이 아니라 서버에 올려두고 화면마다 주소를 나누는 쪽이 맞습니다. 시연본과 개발본의 구조가 다르다는 점은 처음부터 구분해두는 편이 좋았습니다.
검증은 눈이 아니라 숫자로 했습니다
여기서 시간이 제일 많이 들었습니다. 만드는 것보다 만든 게 맞는지 확인하는 쪽이 오래 걸립니다.
- 화면 폭: 390픽셀로 강제한 상태에서 다섯 화면을 하나씩 열어 가로 폭이 정확히 390인지 확인했습니다. 하나라도 390을 넘으면 그 화면은 잘리거나 겹칩니다.
- 문법: 화면 안에 들어간 스크립트를 문법 검사기로 한 번씩 돌렸습니다. 눈으로 훑는 것과는 다릅니다.
- 사본 일치: 시연본을 원본 폴더와 전달용 폴더 두 곳에 두고 있었기 때문에, 두 파일의 크기와 해시값이 같은지 매번 비교했습니다. 한쪽만 고쳐두고 다른 쪽을 보내는 사고를 막으려는 장치였습니다.
“모바일에서도 됩니다”라는 문장은 숫자로 재보기 전까지는 검증하지 않은 상태입니다. 이건 앞 편에서도 같은 결론이 나왔고, 이번에도 그대로였습니다.
비용은 계산이 쉬웠고, 계산되지 않는 항목이 하나 있었습니다
대표가 물은 것은 결국 월 얼마냐였습니다. 현금으로 나가는 돈만 뽑으면 이렇게 정리됩니다.
| 항목 | 월 예상 |
|---|---|
| 서버 한 대 | 10,000~20,000원 |
| 도메인 월 환산 | 1,000~2,000원 |
| 외부 백업 저장공간 | 0~5,000원 |
| 보안 인증서 | 0원 |
| 데이터베이스와 서버 프레임워크 | 0원 |
| 알림 메신저 봇 | 0원 |
| 합계 | 11,000~27,000원 |
여유 있게 잡아도 월 3만 원, 연 36만 원 수준입니다. 다만 이 표에서 빠진 항목이 훨씬 큽니다.
- 개발과 유지보수에 들어가는 사람의 시간
- 은행 거래 데이터를 받아오는 쪽에서 별도 이용료를 요구하는 경우
- 문자나 알림톡 발송 비용
- 지점이 늘어 서버 사양을 올리는 경우
- POS 업체가 연동비를 요구하는 경우
특히 첫 줄이 문제입니다. 제가 하는 일이라 0원으로 계산되지만 실제로는 0원이 아닙니다. 월 1만 원짜리 시스템이라는 표현은 사실 절반만 맞는 말입니다.
발주 버튼을 누른 다음이 비어 있었습니다
시연본에서 재고 화면의 품목을 담고 발주 작성으로 이동을 누르면, 안내창 하나가 뜨고 끝납니다. 화면은 있는데 뒤가 없습니다. 정리해보니 안 되어 있는 것이 이만큼이었습니다.
- 재고 화면에서 담은 품목을 발주 화면으로 넘기기
- 거래처별로 장바구니 나누기
- 부족 수량 기준으로 발주 수량 제안하기
- 발주 내역을 데이터베이스에 저장하기
- 발주번호 만들고 입고 대기 상태로 등록하기
- 수정, 취소, 승인 처리하기
- 거래처로 실제 전송하기
여기서 판단이 하나 필요했습니다. 전송을 자동으로 할 것인가입니다. 결론은 초기에는 자동 작성까지만 하고 전송 버튼은 사람이 누르는 방식입니다. 수량이나 납품일이 틀리면 그대로 돈이 나가기 때문입니다. 반복 발주가 안정된 뒤에 조건을 걸어 자동으로 넘기는 것이 순서라고 봤습니다.
거래처와 연결하는 방법은 다섯 가지였습니다
상대 회사의 시스템과 연결할 수 있느냐는 질문이 나왔습니다. 가능하지만 조건이 있습니다. 상대가 연결 수단을 열어줘야 합니다. 우리가 마음대로 붙일 수 있는 게 아닙니다.
| 방식 | 특징 |
|---|---|
| 공식 API 연동 | 가장 안정적. 상대의 제공과 승인이 필요 |
| 정해진 파일 규격 송수신 | 유통업에서 흔한 형태. 파일을 서버에 올려두면 상대가 가져감 |
| 거래처 사이트에 파일 업로드 | 상대 양식에 맞는 파일을 자동 생성. 사람이 올림 |
| 이메일 발주서 | 구축이 가장 쉬움. 상대가 받아서 처리 |
| 상대 사이트 화면 자동 입력 | 기술적으로는 되지만 화면 변경, 인증, 약관 문제로 최후 수단 |
현실적인 순서는 이메일 발주서부터입니다. 그다음이 거래처 양식에 맞춘 파일 자동 생성이고, 상대 시스템과의 직접 연결은 그 뒤입니다. 중요한 건 우리 쪽 발주와 승인, 기록 구조는 어느 경우에도 그대로 쓸 수 있다는 점입니다. 나중에 보내는 방식만 갈아끼우면 됩니다. 그래서 설계할 때 거래처마다 발송 방식을 다르게 설정할 수 있게 잡아뒀습니다.
대형 공급사와의 API 연동도 제공 조건을 따져야 했습니다
큰 식자재 회사라면 당연히 연결 창구가 있을 거라고 생각했는데, 찾아보니 그렇지 않았습니다. 발주 포털과 모바일 주문 서비스, 협력사 포털처럼 사람이 쓰는 화면은 잘 갖춰져 있었지만, 외부 시스템이 바로 붙는 연결 창구는 따로 안내돼 있지 않았습니다. 주문 내역을 엑셀로 내려받아 다른 시스템에 넣는 운영 사례가 오히려 눈에 띄었습니다.
대체로 거래 규모에 따라 열어주는 수단이 달라집니다. 매장 한 곳이면 발주 포털을 안내받고, 지점이 여럿이면 엑셀 일괄 발주나 전용 화면, 거래액이 큰 곳이면 그때 파일 연동이나 전용 연결을 협의하는 식입니다. 그래서 확정할 수 있는 건 검색이 아니라 담당자에게 묻는 것뿐이었습니다. 물어볼 항목을 이렇게 정리했습니다.
- 자체 시스템에서 만든 발주 데이터를 자동으로 등록할 수단이 있는지
- 있다면 어떤 형태인지, 신청 절차와 이용료는 어떻게 되는지
- 품목코드 대응표를 받을 수 있는지
- 주문 마감 시간, 납품일 규칙, 최소 주문 수량, 수정과 취소 가능 시간
- 테스트 계정과 인증 방식
이 중에서 제일 중요한 건 품목코드입니다. 우리 쪽 품목명과 상대 쪽 코드가 짝지어지지 않으면 나머지는 다 무의미합니다. 자동 발주는 코드 매핑 위에서만 성립합니다.
보고 직전에 방향이 바뀌었습니다
여기까지 정리하고 1차 보고를 준비하는 자리에서, 그 매장이 이미 다른 관리 시스템을 쓰고 있다는 이야기가 나왔습니다. 앞서 세운 전제가 통째로 흔들리는 정보였습니다.
그래서 개발을 계속하는 대신 먼저 확인할 것을 다섯 개로 정리했습니다.
- 어떤 제품인지, 어느 업체인지
- 실제 사용 화면이나 계정을 볼 수 있는지
- 지금 실제로 쓰고 있는 기능이 무엇인지, 발주만인지 재고와 정산까지인지
- 직원들이 그 시스템 밖에서 엑셀이나 메신저로 따로 처리하는 업무가 무엇인지
- 데이터를 내보낼 수 있는지
기존 시스템이 발주만 처리하고 품목별 원가나 정산 대사가 비어 있다면, 갈아엎을 이유가 없습니다. 그 시스템의 데이터를 받아서 붙여 보는 보조 도구 쪽으로 방향만 바꾸면 됩니다. 반대로 필요한 기능이 이미 다 있다면 자체 개발은 그냥 접는 게 맞습니다.
만들어둔 화면은 버리지 않았습니다. 요구사항을 확인하려고 만든 시안이라, 지금은 기존 시스템에 무엇이 있고 무엇이 없는지 따져보는 비교표 역할을 합니다. 손해라고 보기는 어렵습니다. 다만 순서가 틀렸던 건 맞습니다.
순서 감각으로 남은 여섯 가지
- 무엇을 만들지 정하기 전에, 지금 그 자리에 이미 무엇이 돌아가고 있는지부터 확인합니다. 이번에 제가 건너뛴 게 정확히 이 단계입니다.
- 시연본은 받는 사람이 아무 작업도 하지 않고 열 수 있어야 합니다. 압축을 풀게 하거나 파일을 여러 개 보내는 순간 전달은 실패합니다.
- 시연본 구조와 실제 운영 구조를 같은 것으로 취급하지 않습니다. 파일 하나에 다 넣는 방식은 보여주기 위한 임시 형태입니다.
- 확인은 숫자로 합니다. 화면 폭, 파일 해시, 문법 검사처럼 참과 거짓이 나오는 것으로 봅니다. 눈으로 보고 괜찮다는 판단은 여러 번 틀렸습니다.
- 자동 전송은 마지막에 붙입니다. 사람이 확인하고 누르는 단계를 남겨두는 편이, 초기에는 훨씬 싸게 먹힙니다.
- 월 고정비를 계산할 때 제 시간을 0원으로 넣지 않습니다. 현금 지출은 월 3만 원이지만 실제 비용은 그게 아닙니다. 고정비나 배치 같은 표현은 따로 모아 정리해두었습니다
정리하면 이번에 얻은 건 완성된 시스템이 아니라 순서 감각입니다. 화면을 만드는 일은 생각보다 빨랐고, 그 화면이 필요한 자리인지 확인하는 일은 끝까지 안 하고 있었습니다.
이어서 읽을 기록
