객실 가격이 스스로 움직이기까지

제가 일했던 호스피탈리티 회사에서 객실 가격 결정은 이런 풍경이었습니다. 매일 아침 여러 명이 각자 오전의 상당 시간을 들여 캘린더를 날짜별로 훑습니다. 오늘 밤은 얼마나 찼나, 6주 뒤 그 주말은 어떤가, 옆집은 얼마를 받나. 그렇게 모든 날짜, 모든 객실 타입에 가격을 매깁니다. 그다음 모여서 서로의 숫자를 비교하고, 다투고, 하나로 맞추죠. 다음 날 또 처음부터 합니다. 밤사이 수요가 움직였으니까요. 부업이 아니었습니다. 그 일을 하라고 고용된 사람들의 풀타임 업무였고, 호텔업에서는 이게 정상입니다. 방 관리보다 가격 관리가 더 중요하다는 게 이 업계의 통설이니까요.

낭비는 사람이 아니었습니다. 가격을 매기는 판단은 진짜 전문성입니다. 낭비는 그 전문성이 매일 아침 백지에서 다시 만들어지고, 그 몇 사람의 머릿속 말고는 어디에도 남지 않는다는 데 있었습니다.

머릿속의 판단을 인터뷰로 꺼내기

첫 단계는 소프트웨어와 아무 상관이 없었습니다. 가격 담당자들을 한 명씩 인터뷰했습니다. 언제 올리는지, 언제 내리는지, 어떤 날짜가 무서운지, 어떤 신호를 믿고 어떤 신호를 무시하는지. 답변은 생각보다 덜 겹쳤습니다. 매일 조율 회의가 필요했던 이유가 바로 그것이었죠. 그래서 인터뷰를 하나의 문서로 합쳤습니다. 우리 집 가격 원칙, 그러니까 팀이 실제로 동의할 수 있는 규칙들로요.

그다음에 기계가 들어왔습니다. AI가 그 문서를 따라, 사람이 매긴 것과 같은 캘린더에 가격을 매기고 일치율을 쟀습니다. 기계가 사람들의 합의 지점에 안착한 날짜가 며칠이나 되는가. 처음에는 거의 없었습니다. 그런데 여기서부터의 학습 루프가 민망할 만큼 쌌습니다. 매일 새로 들어가는 입력은 그날 가격 회의의 메모뿐이었으니까요. 사람이 기계와 어디서, 왜 다르게 봤는지. 시스템은 그 논리를 원칙 문서에 접어 넣고, 최신 논리로 첫날부터 전체 기간을 다시 돌려서 일치율을 전 구간에 걸쳐 다시 쟀습니다. 오늘 하루만이 아니라요.

일주일쯤 지나자 기계는 대다수 날짜에서 사람들의 합의와 같은 답을 냈습니다. 전부는 아니었죠. 그리고 어긋난 날짜들이 가장 흥미로웠습니다. 다시 들여다보니 사람 쪽이 틀렸던 날짜가 그 안에 섞여 있었거든요.

이 루프를 가능하게 한 건 지능이 아닙니다. 사람들도 문서화된 원칙을 캘린더에 적용할 수 있습니다. 하루 아침, 길어야 일주일은요. 어떤 팀도 절대 못 하는 일은 따로 있습니다. 규칙이 한 문장 바뀔 때마다, 첫날부터 모든 날짜를 매일 다시 계산하는 것. 기계의 강점은 더 나은 가격 감각이 아니었습니다. 400번째 날짜에서도 지치지 않는다는 것이었습니다.

부티크 호텔 버전

몇 년 뒤, 같은 패턴을 반대편에서 다시 지을 기회가 왔습니다. AI 코칭을 하던 부티크 호텔 오너였습니다. 그의 호텔은 리뷰가 좋고 주말은 꽉 찹니다. 문제는 전형적이었습니다. 성수기 평일 점유율이 무른데, 경쟁 숙소들은 공격적으로 가격을 내리는 상황. 그리고 가격 결정 프로세스는 사람 한 명이 채널들을 확인하며 감으로 조정하는 것이었죠.

같은 순서로 갔습니다. 배관만 더 좋게요.

수요부터 보이게 만들기. 어느 방이 예약됐는지 아는 소프트웨어, 그러니까 숙소 관리 시스템에 API가 있었습니다. 이걸 연결해 간단한 라이브 페이지를 만들었죠. 앞으로의 모든 날짜별 점유율이 계속 갱신되고, 전일 대비 변화폭이 붙어서 어느 날짜가 얼마나 빨리 차오르는지 눈으로 좇을 수 있습니다. 전에는 "이번 달 마지막 주 페이스 어때요?"가 누군가 가서 알아봐야 하는 질문이었습니다. 이제는 한 번 쳐다보면 끝입니다.

원칙 쓰기. 시즌별 목표 점유율. 자동화가 절대 뚫고 내려갈 수 없는 객실 타입별 하한가. 그리고 오너 본인이 고집한 포지셔닝 규칙 하나. 저는 이게 시스템 전체에서 가장 날카로운 대목이라고 생각합니다. 진짜 같은 급하고만 비교할 것. "이 동네 숙박업소 전체"가 아니라, 객실 수가 비슷하고 뷰가 비슷하고 손님이 비슷한 곳들만. 경쟁자도 아닌 곳을 벤치마크하는 데서 패닉 할인이 시작되니까요.

채널까지 루프 닫기. 남은 배관은 채널 매니저입니다. 모든 예약 플랫폼에 요금을 밀어 넣어 주는 시스템이죠. 이 API까지 연결하면 흐름이 완성됩니다. 수요 데이터가 들어오고, 원칙이 날짜별 제안 가격을 만들고, 사람은 승인이냐 보류냐만 누릅니다. 승인 한 번이면 새 요금이 모든 채널로 퍼지고요. 제안은 상시 자동, 결정은 버튼 하나.

이 마지막 문장이 "스스로 움직이는 가격"의 정직한 정의입니다. 가격은 수요를 따라 매일 움직입니다. 그 움직임의 주인은 여전히 사람입니다.

데이터가 못 보는 것

오너가 남긴 단서 하나를 저는 계속 간직하고 있습니다. 운영자만 아는 종류의 이야기라서요. 그의 시장에서는 의미 있는 비중의 장사가 어떤 예약 시스템에도 잡히지 않습니다. 워크인, 현금, 조용한 평일 밤의 직거래. 데이터 피드만 보고 가격을 매기면 수요의 일부만 보고 매기는 셈이죠. 그의 결론은 "그러니 자동화하지 말자"가 아니었습니다. "그러니 내 동네는 내가 계속 알아야 한다"였습니다. 예전 회사에서는 같은 구멍을 기계적으로 메웠습니다. 대시보드와 은행 계좌를 대조하고, 안 맞는 것을 끝까지 쫓는 방식으로요.

프로젝트 전체를 보는 올바른 프레임이 이것입니다. 자동화는 가격 판단을 없애지 않았습니다. 한 층 위로 올렸을 뿐입니다. 오늘의 가격을 정하는 일에서, 오늘의 가격을 정하는 규칙을 정하는 일로. 그리고 규칙이 못 보는 것을 알아채는 일로. 아침 풍경이 가장 잘 말해 줍니다. 예전 아침은 여러 명이 모든 날짜를 백지에서 매기고, 회의로 그걸 두들겨 맞추는 시간이었습니다. 지금 아침은 자리에 앉으면 제안이 이미 화면에 떠 있고, 사람의 일은 예외 몇 건을 짧게 살피는 것뿐입니다.

그리고 바로 여기서 자동화가 조용히 매출로 바뀝니다. 호텔의 하룻밤은 상하는 재고입니다. 날짜가 지나면 그 판매 기회는 영영 사라지죠. 누가 시간 날 때만 움직이는 가격은 팔 수 있는 동안의 수요를 놓치고, 매일 스스로 움직이는 가격은 그 수요를 받아냅니다. 방은 하나도 달라지지 않았습니다. 달라지는 건 같은 방이 수요를 얼마나 받아내느냐입니다. 그리고 매일 밤 증발하던 가격 지식은 이제 문서에 삽니다. 사람이 기계의 제안을 뒤집고 그 이유를 말할 때마다, 그 문서는 조금씩 더 날카로워지고요.