여행사 백오피스 업무 자동화 시스템을 어떻게 구축하는가

업무 자동화 시스템을 구축할 때 가장 어려운 부분은 기술 선택이 아니다. 어디서부터 자동화할지, 어떤 순서로 연결할지, 그리고 실제로 사람이 쓰는 시스템을 어떻게 만드는지다. 나무숲이 여행사 백오피스 프로젝트에서 마주한 문제도 정확히 그 지점이었다.

---

여행사 백오피스가 안고 있는 실제 문제

여행사 백오피스는 겉으로 보면 단순해 보인다. 예약 받고, 항공권·호텔 조율하고, 정산하면 끝처럼 보인다. 실제로 열어보면 전혀 다르다.

예약 확인만 해도 이메일, 카카오, 전화, 자체 홈페이지, OTA(온라인 여행 플랫폼)까지 채널이 5개 이상 흩어져 있다. 담당자는 아침마다 각 채널을 순회하며 예약 내역을 수작업으로 엑셀에 옮긴다. 이 과정에서 누락이 생긴다. 누락이 생기면 정산이 틀린다. 정산이 틀리면 고객 불만이 된다.

문제를 구조적으로 정리하면 세 가지다.

• 채널 분산: 예약 유입 경로가 다양한데 중앙에서 모이는 곳이 없다.
• 수동 처리 비중 과다: 예약 확인, 공급사 연락, 정산 확인까지 반복 행동이 대부분 사람 손을 거친다.
• 정산 지연: 공급사마다 정산 주기와 형식이 달라 월말 정산에 집중적으로 공수가 몰린다.

이 구조는 직원 수가 적은 중소 여행사일수록 더 심각하게 작동한다. 소수 인원이 여러 역할을 겸하기 때문에, 반복 업무 비중이 높을수록 고부가가치 업무(패키지 기획, 고객 상담)에 쓸 시간이 줄어든다.

---

나무숲이 설계한 자동화 구조: 에이전트 간 협업

단일 자동화 스크립트로 이 문제를 해결하려 하면 곧 막힌다. 채널이 여럿이고, 데이터 형식도 제각각이며, 예외 케이스가 많기 때문이다. 나무숲이 선택한 방향은 단일 자동화가 아니라, 역할이 분리된 여러 에이전트가 협업하는 구조였다.

에이전트 역할 분리의 원칙

각 에이전트는 하나의 책임만 가진다. 이 원칙은 소프트웨어 설계에서 오래된 개념인 단일 책임 원칙(Single Responsibility Principle)과 같다. 에이전트도 예외가 아니다. 하나의 에이전트가 데이터 수집, 판단, 실행까지 모두 맡으면 예외 상황에서 어디가 문제인지 추적하기 어려워진다.

여행사 백오피스 프로젝트에서 역할은 대략 이렇게 나뉘었다.

이 구조의 핵심은 에이전트 간 인터페이스를 단순하게 유지하는 것이다. 각 에이전트는 표준화된 형식으로 데이터를 주고받는다. 한 에이전트가 교체되거나 수정될 때 다른 에이전트를 건드리지 않아도 된다.

오케스트레이터의 역할

에이전트들을 연결하는 오케스트레이터는 별도로 두었다. 오케스트레이터는 흐름을 제어한다. 어떤 에이전트를 언제 호출할지, 에이전트가 예외를 반환했을 때 어떻게 처리할지, 담당자 개입이 필요한 시점을 어떻게 판단할지가 여기에 정의된다.

특히 중요한 설계 결정이 하나 있다. 예외 케이스는 자동화하지 않는다. 정상 흐름만 자동화하고, 예외는 사람에게 넘긴다. "예외도 자동화하겠다"는 욕심이 시스템을 복잡하게 만들고, 결국 유지보수 비용을 키운다. 예외 처리를 사람에게 명확히 넘기는 것이 장기적으로 더 안정적이다.

---

구축 과정에서 마주한 장애물과 해결 방법

계획대로 흘러간 부분만큼 막힌 부분도 있었다.

첫 번째 장애물: 데이터 형식 불일치

채널마다 예약 데이터 형식이 달랐다. OTA는 JSON API를 제공했지만, 공급사 일부는 여전히 이메일로 PDF를 보냈다. PDF에서 구조화된 데이터를 추출하는 과정은 단순하지 않다. 비정형 텍스트에서 날짜, 금액, 공급사 코드를 안정적으로 파싱하려면 LLM 기반 추출 레이어가 필요했다.

해결 방식은 채널별 어댑터를 두는 것이었다. 각 입력 채널에 맞는 파서를 별도로 만들고, 그 출력이 공통 스키마를 따르도록 강제했다. 어댑터 내부 구현이 바뀌어도 공통 스키마는 변하지 않기 때문에 하위 에이전트에 영향을 주지 않는다.

두 번째 장애물: "이 케이스는 예외예요"가 너무 많았다

자동화 시스템을 처음 보여주면 담당자들이 반드시 하는 말이 있다. "이 경우는 달리 처리해야 해요." 이 말이 반복될수록 예외 케이스 목록이 길어지고, 시스템이 복잡해진다.

이때 도움이 된 접근은 예외 케이스를 두 종류로 분리하는 것이다. 반복되는 예외와 일회성 예외다. 반복되는 예외는 시스템에 흡수할 가치가 있다. 일회성 예외는 사람이 처리하는 게 맞다. 이 분류 없이 모든 예외를 시스템에 넣으려 하면 ROI가 나오지 않는다.

세 번째 장애물: 담당자 신뢰 확보

기술적으로 작동하는 것과 실제로 쓰이는 것은 다르다. 담당자가 "혹시 잘못 처리되지 않을까"라는 불안을 갖고 있으면 자동화 시스템을 믿고 맡기지 않는다. 이중으로 수작업 확인을 하면 자동화 효과가 사라진다.

해결은 투명성에 있었다. 모니터링 대시보드를 담당자가 직접 볼 수 있게 만들고, 각 처리 단계에서 무슨 일이 일어났는지 로그로 남겼다. 처음엔 담당자가 로그를 꼼꼼히 확인했다. 시간이 지나면서 직접 확인하는 빈도가 줄어들었다. 신뢰는 시간과 투명한 기록으로 쌓인다.

---

자동화 도입 후 달라진 운영 지점

나무숲은 수치를 임의로 만들지 않는다. 여기서는 구조적으로 어떤 부분이 달라지는지를 설명한다.

자동화 이전 백오피스 운영의 병목은 정보 수집과 통합에 있었다. 담당자가 가장 많은 시간을 쓰는 구간이 여기였다. 예약을 처리하는 것보다 예약이 맞게 들어왔는지 확인하는 데 더 많은 시간이 들었다.

시스템이 이 구간을 맡으면, 담당자의 역할이 바뀐다. 전체 흐름을 직접 처리하는 것에서 예외와 이상을 검토하는 것으로. 이는 같은 인원으로 더 많은 예약을 처리할 수 있다는 의미가 아니라, 같은 예약량을 처리하면서 패키지 기획이나 고객 관계 관리 같은 판단이 필요한 업무에 더 집중할 수 있다는 의미다.

정산 구간도 달라진다. 공급사별 조건이 시스템에 정의되어 있으면, 월말에 집중되던 정산 공수가 일상적인 흐름으로 분산된다. 실수도 줄어든다. 수작업으로 공급사 조건을 매번 찾아 적용하는 과정에서 생기는 오류가, 규칙이 코드로 고정되면 발생하지 않는다.

---

이 구조에서 배울 수 있는 점

여행사 백오피스 사례가 B2B 현업에 주는 시사점은 업종 특수성보다 구조의 일반성에 있다.

채널이 여럿이고, 데이터 형식이 제각각이며, 예외가 많고, 월말에 공수가 몰리는 구조는 여행사만의 문제가 아니다. 물류, 부동산 중개, 공공 서비스 창구 운영 등 많은 B2B 업무가 같은 패턴을 갖는다.

자동화 시스템을 도입할 때 공통적으로 유효한 원칙은 이렇다.

• 정상 흐름을 먼저 자동화하고, 예외는 사람에게 명확히 넘긴다.
• 에이전트 간 인터페이스를 단순하게 유지해 교체 비용을 낮춘다.
• 담당자가 시스템을 볼 수 있게 만든다. 블랙박스는 신뢰를 얻지 못한다.
• 반복되는 예외와 일회성 예외를 구분해 시스템 복잡도를 제어한다.

이 원칙은 특정 기술 스택에 종속되지 않는다. LangChain이든, 자체 오케스트레이터든, RPA 도구든 어디에나 적용된다.

나무숲은 여행사 백오피스 외에도 항공우주 견적 AI, 도면 부품 추출 AI 등 여러 B2B 자동화 프로젝트를 직접 구축했다. 공통점은 같다. 전 팀원이 AI를 기본 도구로 쓰며 일하기 때문에 착수가 빠르고, 연구에서 운영까지 한 팀이 끊기지 않고 가져간다. 업무 자동화 시스템 구축에 관심 있다면 나무숲의 에이전틱 AI 서비스 페이지에서 구체적인 적용 범위를 확인할 수 있다.

---

자주 묻는 질문

자동화 시스템 구축에 앞서 내부 데이터 정리가 먼저 되어야 하나?

완벽히 정리된 데이터를 기다리면 착수 시점이 없어진다. 데이터 형식이 불일치하는 것은 구축 과정에서 어댑터로 해결하는 것이 현실적이다. 다만 어떤 데이터가 어느 채널에 어떤 형식으로 존재하는지 목록화하는 작업은 착수 전에 해두는 게 좋다.

에이전트 구조가 기존 RPA 도구와 다른 점은 무엇인가?

RPA는 화면 UI를 직접 조작하는 방식으로 특정 화면 구조에 의존한다. 화면이 바뀌면 스크립트가 깨진다. 에이전트 기반 자동화는 API나 데이터 레이어에서 작동하며, 판단이 필요한 구간에 LLM을 활용할 수 있다. 구조 변경에 더 강하고, 텍스트 기반 예외 처리에 유리하다.

자동화 시스템을 도입하면 담당자 업무가 줄어드나, 없어지나?

줄어든다. 반복적인 수집·확인·입력 업무는 줄고, 예외 검토와 판단 업무는 남는다. 시스템이 예외를 사람에게 명확히 넘기도록 설계되기 때문에, 담당자는 더 판단이 필요한 케이스에 집중하게 된다.

착수부터 실제 운영까지 얼마나 걸리나?

프로젝트 규모와 기존 시스템 연동 복잡도에 따라 다르다. 나무숲의 경우 전 팀원이 같은 AI 개발 환경을 표준으로 쓰기 때문에 일반적인 외주 방식보다 착수가 빠르다. 범위를 명확히 정한 뒤 2주 내 착수하는 것을 목표로 한다.

중소 여행사도 이 구조를 적용할 수 있나?

가능하다. 오히려 직원 수가 적고 반복 업무 비중이 높은 조직일수록 자동화 효과가 명확하게 나타난다. 시스템 범위를 넓게 잡기보다, 가장 공수가 많이 드는 구간 하나를 먼저 자동화하는 방식으로 시작하는 것이 현실적이다.

---

비슷한 구조의 문제를 겪고 있다면, 현재 어느 구간에서 공수가 가장 많이 드는지, 예외 케이스가 어떤 패턴으로 발생하는지를 구체적으로 들고 오면 논의가 빨라진다. 무료 상담에서 나무숲 팀과 직접 이야기할 수 있다.