객실을 세는 일에서
12년 1개월을 보냈습니다.

숙박이 경력의 뼈대입니다

객실을 파는 쪽이 아니라 돌아가게 만드는 쪽이었습니다. 예약·요금·재고·자산·정산이 서로 어긋나지 않게 붙이는 일입니다.

기능을 더한 게 아니라 구조를 다시 짰습니다

리조트 요금 체계를 새로 설계한 적이 있습니다. 기존 BAR 요금 체계의 한계를 극복하는 것이 목표였고, 재고 수량을 실시간으로 보면서 예약량에 따라 요금이 자동으로 움직이는 구조로 바꿨습니다.

두 수치가 같은 이야기입니다. 예약률이 오른 건 기능을 더해서가 아니라, 인벤토리를 블록으로 다시 나누고 요금 결정을 그 위에 얹었기 때문입니다. 그 과정에서 오라클 프로시저 8만 줄이 2만 줄로 줄었습니다 — 구조가 맞으면 코드는 줄어듭니다.

이 두 값은 증거 페이지에 산출 방법·출처와 함께 실려 있습니다. 여기 없는 수치는 제 주장이 아닙니다.

복도가 없으면 규칙이 달라집니다

전통적인 숙박 시설은 복도가 전제입니다. 한 사람이 카트를 밀며 수십 객실을 돌고, 점검자가 다시 복도를 돕니다. 동선이 곧 프로세스입니다.

독채가 흩어지면 그 전제가 사라집니다. 동선이 데이터가 되어야 누가 어디를 언제 가는지 정해집니다 — 그건 사람의 성실함으로는 수십 채까지만 버팁니다. 수백 채에서는 배정·검증·보충이 각각 시스템이 되어야 합니다.

매일 도는 일은 배분과 스케줄 문제입니다

세탁물처럼 매일 돌아야 하는 일은 겉보기엔 물류지만, 실제로 깨지는 자리는 대개 경로가 아니라 배분과 스케줄입니다 — 누가 얼마나 맡는가, 실패하면 어떻게 되는가, 늦어진 건이 다음 회차를 밀어내지 않는가.

그건 제가 오래 다뤄온 문제입니다.

수거를 이렇게 봅니다 — 회차가 트랜잭션이고, 별장 하나가 작업 단위입니다. 그러면 “오늘 몇 대가 어디를 도나”보다 “어느 건이 밀렸고 왜 밀렸나”가 먼저 보입니다. 밀린 이유가 보이면 경로는 그 다음 문제입니다.

다만 이건 안 해봤습니다

차량 경로 최적화(VRP) 자체는 경험이 없습니다. 시간창·적재량·다중 차량이 동시에 얽히는 최적화는 별개 분야이고, 배분·스케줄을 다뤄봤다고 그걸 해봤다는 뜻은 아닙니다.

이 구분을 적는 이유는 하나입니다 — 안 해본 것을 안 적으면 나머지도 못 믿습니다. 이 사이트의 수치에는 전부 출처가 붙어 있고, 근거를 댈 수 없는 것은 싣지 않습니다.

AI 에이전트로 직접 짓습니다

요즘은 기획서를 넘기고 기다리지 않습니다. 클로드 코드로 직접 설계하고 만들고 검증합니다. 이 사이트가 그 결과물이고, 방식은 이렇습니다:

중요한 건 속도가 아니라 되돌아오지 않는 것입니다. 검사가 없으면 빨리 만든 만큼 빨리 무너집니다. 그래서 저는 만드는 것과 같은 비중으로 “이게 진짜 그런가”를 확인하는 장치를 만듭니다.

기계가 읽는 표면도 함께 냅니다 — /api/catalog.json · /llms.txt · 기계가 읽는 것.

10%와 10배는 다른 일입니다

10%는 지금 하는 일을 빠르게 하는 것이고, 10배는 지금 하는 일을 안 하게 만드는 것입니다. 전자는 사람을 갈아 넣으면 되고, 후자는 무엇을 생략해도 되는지를 알아야 합니다.

제가 계속 묻는 질문이 그겁니다 — 이 단계는 왜 있는가. 8만 줄이 2만 줄이 된 것도, 관행으로 남아 있던 것들이 실제로는 필요 없었기 때문입니다.

그리고 제 일의 목표는 제가 계속 필요하지 않게 되는 것입니다. 인프라와 환경을 잡아두면 그 위에서 각자가 자기 디테일을 심습니다. 제가 계속 있어야 돌아가는 구조라면, 제가 잘못 만든 겁니다.