워크스페이스로 바닥을 깔고 나니 이제 진짜 만들 차례였다. 대표님이 처음부터 바란 건 흩어진 자료를 시스템으로 모으는 것. 문제는 어디서부터 손을 대느냐였다.
내 머릿속 1순위는 입력 자동화였다. 카드 내역을 자동으로 긁어오는 유료 방식을 붙이면, 사람이 파일을 만질 일 자체가 없어진다. 입력이 자동이면 뒤가 다 자동이니까 — 개발자 눈엔 당연한 출발점이다.
대표님 의견은 달랐다. "그거, 쓸만한 게 거의 없어요."
이유를 파보니 구조가 보였다. 자동으로 긁히는 데이터와, 사무소가 손으로 정리하느라 아픈 데이터가 서로 달랐다. 정작 정리가 필요한 건 고객 사장님들이 이메일과 메신저로 제각각 던져주는 개별 명세 파일들이었다. 카드사마다 양식이 다르고, 보내는 사람은 그게 어떻게 처리되는지 모른다.
자동화하기 좋은 데이터를 자동화하는 건 쉽다. 실무가 아픈 데이터를 다뤄야 하는데, 그 둘이 같지 않다는 걸 대표님은 경험으로 알고 있었고 나는 몰랐다. 그래서 입력 자동화는 시작도 하기 전에 접었다. 돈도 안 들었고 코드도 안 버렸다.
방향을 틀고 나니 더 근본적인 게 걸렸다. 실무자가 받은 명세 파일을 올리고, 업체별로 지출을 장부 항목으로 나누는 일 — 그 일을 담을 화면이 사무소 어디에도 없었다.
지금까지 이 일은 실무자 세 사람이 각자 자기 PC에서, 각자의 방식으로 하고 있었다. 같은 작업을 저마다 다른 기준으로 한다. 어제 어떻게 처리했는지는 각자의 기억에 있다. 이걸 하나의 화면, 하나의 기준으로 모으지 않으면 표준화도 축적도 안 된다.
그제서야 알았다. 자동화를 붙일 데가 아니라, 사람이 일할 데부터 있어야 한다는 걸. 그래서 첫 시스템은 자동수집이 아니라 관리자 화면 — 어드민이 됐다.
어드민의 첫 세 화면은 이렇게 잡았다.
화면 구조는 개발자 관행(데이터 종류별 메뉴)이 아니라 실무 관행(업체별 컨텍스트)에 맞췄다. 세무사들이 익숙한 방식이 그거였다.
도메인도 이 단계에서 하나 배웠다. 같은 지출이라도 업종에 따라 장부에 다르게 적힌다 — 카페가 산 커피와 IT 회사가 산 커피는 다른 항목이다. 화면과 데이터가 처음부터 "업체 단위"여야 하는 진짜 이유였다.
만들고 나서 정리된 생각이 있다. 나는 자동화부터 하려고 했는데, 자동화란 사람이 어떻게 일하는지가 화면으로 서 있어야 그 위에 붙일 수 있는 것이었다. 무엇을 자동화할지는 기술이 아니라 실무가 정한다.
이 관리자 화면 하나가 서자 뒤의 일들이 전부 여기에 얹혔다. 다음 편은 그 업로드 화면이 실전에서 겪은 일이다. 서버는 성공했는데 화면은 실패했던 날.