← 목록 · 2026-08-19 · Sophia 엑셀·업무 자동화

구글시트 입고 예약 시스템 전체 구조: 왜 만들었고 어떤 순서로 이어지는가

이 시리즈는 예제 프로젝트가 아닙니다

이 블로그의 입고 예약 시리즈는 포트폴리오용으로 만든 가상 프로젝트가 아닙니다. 제가 총괄해 관리하는 약 1,700,000 sq ft 규모의 창고에서 실제로 쓰고 있는 시스템을, 기능 단위로 쪼개 기록한 것입니다.

이 정도 규모가 되면 하루 입고 계획이 조금만 어긋나도 게이트, 도크, 현장 인력의 일정이 연쇄로 밀립니다. 오전에 밀린 두 대가 오후 작업 배치를 통째로 바꿔 놓는 일이 드물지 않습니다. 그런데 그 계획이 전화와 이메일과 개인의 기억에 흩어져 있으면, 어디서부터 밀렸는지조차 그날 저녁에야 알게 됩니다.

예약 단계부터 관리해야 한다는 것을 늦게 알았습니다

처음에는 도착한 화물을 어떻게 빨리 처리할지만 생각했습니다. 관점이 바뀐 것은 업무 중에 상용 도크 예약 솔루션이 돌아가는 방식을 볼 기회가 있었을 때입니다. 거기서 얻은 것은 기능 목록이 아니라 순서에 대한 생각이었습니다.

대형 창고의 도크 운영은 트럭이 게이트에 도착한 순간부터 시작되는 일이 아닙니다. 언제 도착할지를 예약하는 단계에서 이미 정보가 구조화되어 있어야, 도크와 인력을 미리 준비할 수 있습니다. 도착한 뒤에 대응하는 방식은 아무리 빨라도 따라잡는 일이고, 예약 단계에서 준비하는 방식은 앞서 가는 일입니다.

이 생각이 담당 창고에 맞는 별도의 예약 시스템을 기획한 출발점이었습니다.

회사 WMS는 그대로 씁니다

오해를 먼저 정리하겠습니다. 회사에는 이미 전사 WMS가 있고, 이 프로그램은 그것을 대체하지 않습니다. 재고 원장, 회계 연동, 규정 관련 기록은 전사 시스템의 몫입니다.

다만 회사가 여러 지역에서 서로 다른 방식으로 화물을 입·출고하다 보니, 전사 시스템이 제가 담당하는 창고의 예약과 도크 운영 세부까지 모두 해결해 주지는 않았습니다. 필요한 데이터는 있는데 원하는 각도로 자르는 데 시간이 걸리고, 도크 단위의 준비는 여전히 사람 손에 남아 있었습니다.

그래서 이 시스템의 자리는 분명합니다. 전사 시스템과 현장 사이의 빈틈입니다. 예약을 받고, 도착을 확인하고, 도크를 붙이고, 지금 무슨 일이 벌어지는지 한 화면에 보이게 하는 것까지입니다.

전체 흐름 — 하나의 데이터가 끝까지 이어져야 합니다

이 시스템에서 가장 중요한 설계 원칙은 하나입니다. 예약 한 건이 도착·도크 배정·완료까지 같은 레코드로 이어져야 한다는 것입니다.

각 단계를 따로 기록하면 각각은 잘 돌아가는 것처럼 보입니다. 문제는 이어 붙일 때 생깁니다. 예약은 09:00인데 실제로 10:30에 도착했다는 사실이 다른 표에 있으면, 어느 시간대가 늘 밀리는지 알 수 없습니다. 자동화가 끊기는 지점은 대부분 사람이 다시 옮겨 적는 자리입니다.

전체 흐름은 이렇게 이어집니다.

예약 등록 — 어느 날 몇 시에 어떤 장비가 오는지 받습니다. 운영시간과 예약 가능 기간, 시간대별 정원이 여기서 걸러집니다.
일정 변경과 지연 — 예약 시간은 확정된 미래가 아닙니다. 선박 지연, 트럭 지연, 교통으로 계속 달라집니다. 변경과 사유를 남깁니다.
도착 체크인 — 기사가 컨테이너 번호로 오늘 예약을 찾고, 도착 사실이 기록됩니다.
도크 배정 — 그 시간대에 비어 있는 도어를 붙입니다. 남은 도어가 없으면 보류로 두고 사람이 정리합니다.
기사 안내 — 배정 결과를 기사에게 바로 전달합니다. 전달이 늦으면 배정을 자동화한 의미가 크게 줄어듭니다.
현황 대시보드 — 오늘 몇 대가 오는지, 어디가 밀렸는지, 지금 어느 화물이 도크에 붙어 있는지 한 화면에서 봅니다.
KPI와 리포트 — 지연을 세는 것이 목적이 아니라, 통제 가능한 지연과 그렇지 않은 지연을 구분하는 것이 목적입니다. 선박 지연처럼 운송사가 어쩔 수 없는 상황과 반복되는 운영상 지연을 같이 세면 평가가 왜곡됩니다.

지금까지 쓴 편

시리즈는 기능 단위로 나눠 올리고 있습니다. 순서대로 따라오시면 마지막에는 실제로 도는 시스템 하나가 남습니다.

기본 만들기 — 시트와 화면의 뼈대

예약 등록 — 받을 것과 받지 않을 것

도착 체크인 — 예약이 실적이 되는 자리

창고 재고관리 — 예약 시스템 이전에 만든 것들

입고 예약 시스템보다 먼저 만든 재고·출고 자동화입니다. 같은 창고에서 쓰는 도구들이라 시트 설계 방식이 이어집니다.

앞으로 쓸 편

아래는 실제 시스템에는 들어 있지만 아직 글로 정리하지 않은 부분입니다. 순서대로 이어서 올릴 예정입니다.

현황 대시보드 — 일일 현황, 상태별 현황, 야드 현황
KPI와 리포트 — 일별 지표, 운송사별 점수, 주간 리포트
일괄 등록과 관리자 화면 — 붙여넣기 검증, 날짜 일괄 이동
운송사 포털과 알림 — 기사 문자 안내를 포함한 외부 연동
변경과 노쇼 처리 — 일정 변경 이력과 사유 분류

지금 없는 편을 미리 링크해 두지 않은 이유는 단순합니다. 쓰지 않은 글을 목차에 올려 두면 목차가 거짓말이 됩니다. 올라가는 대로 이 페이지에 추가하겠습니다.

AI를 어떻게 썼는지

코드를 쓰는 과정에서는 AI를 보조 도구로 활용했습니다. 이 사실을 숨길 이유가 없다고 생각합니다. 동시에 정확히 말씀드리는 편이 낫겠습니다.

무엇을 만들지, 어떤 업무 흐름이 필요한지, 지연과 예외를 어떻게 다룰지는 현장 경험을 바탕으로 제가 정했습니다. 예약과 도착을 어떤 단위로 이을지, 도어가 없을 때 예약을 거절할지 보류할지, 취소를 어떻게 처리할지 같은 판단은 코드 이전의 문제이고 창고를 아는 사람만 정할 수 있습니다.

AI가 낸 코드는 그대로 쓰지 않았습니다. 실제 데이터와 운영 상황에서 돌려 보고 고친 뒤에 현장에 적용했습니다. 이 블로그에 실린 코드 중 상당수는 한 번 올린 뒤에 다시 고친 것들입니다. 시트 열 위치가 앞 편과 어긋났거나, 시간대가 잘못 박혀 있었거나, 빈 행 하나에 작업 전체가 멈추는 문제였습니다.

처음부터 이 구조였던 것은 아닙니다

시리즈를 순서대로 읽으면 잘 설계된 것처럼 보이지만, 실제로는 그렇지 않았습니다. 각 기능은 앞 단계를 쓰면서 드러난 다음 문제를 풀며 붙은 것입니다.

예약표를 만들고 나니 실제 도착과 맞지 않았고, 도착을 기록하기 시작하니 도크 배정과 이어야 했고, 도크를 배정하니 기사에게 전달할 방법이 필요했습니다. 중복 예약 방지는 같은 컨테이너가 두 건 들어와 있는 걸 보고 나서 추가했고, 날짜 형식만 다루는 편은 예약이 하루 전날로 저장된 걸 발견하고 나서 썼습니다.

그래서 이 시리즈는 완성된 설계도의 해설이 아니라 문제를 하나씩 만나며 늘려 온 기록에 가깝습니다.

그대로 쓰지 마시고, 고쳐 쓰세요

마지막으로 한 가지만 부탁드립니다. 이 시리즈의 코드는 범용 물류 소프트웨어가 아닙니다. 제가 관리하는 창고의 흐름에 맞춰 필요한 필드와 상태, 예외 처리 순서를 정한 것입니다.

여러분의 현장은 부지 크기도, 하루에 소화하는 대수도, 도크 구조도 다릅니다. 코드는 출발점으로 쓰시고 열 이름, 상태값, 시간대, 권한, 예외 처리는 반드시 자기 환경에 맞게 바꾸셔야 합니다. 특히 시간대 설정과 정원 값은 그대로 두면 거의 확실히 어긋납니다.

막히는 부분이 있으면 연락처로 알려 주세요. 확인해서 글을 고칩니다. 실제로 그렇게 고친 적이 여러 번 있습니다.