핵심 인사이트 (3줄 요약)
- 본질: 마스 (MaaS, Mobility as a Service)는 버스, 철도, 택시, 카셰어링, 공유 자전거 같은 이기종 교통수단을 하나의 여정 서비스로 묶어, 검색·예약·결제·환승 안내를 통합 제공하는 개념이다.
- 가치: 이동수단의 소유보다 이용 경험을 최적화해 환승 마찰을 줄이고, 퍼스트 마일 (First Mile)·라스트 마일 (Last Mile) 문제와 도심 혼잡 완화에 기여한다.
- 판단 포인트: MaaS의 성공은 앱 화면보다 공공교통 데이터 개방, 표준화된 응용 프로그래밍 인터페이스 (API, Application Programming Interface), 계정 기반 발권 (ABT, Account-Based Ticketing), 정산 체계, 거버넌스에 달려 있다.
Ⅰ. 개요 및 필요성
마스 (MaaS)는 버스, 지하철, 철도, 택시, 카셰어링, 공유 자전거, 개인형 이동수단 (PM, Personal Mobility) 을 하나의 디지털 접점으로 묶어, 출발지부터 목적지까지의 여정을 서비스로 제공하는 개념이다. 핵심은 특정 운송수단 하나를 파는 것이 아니라, 이동 전체를 조합하고 책임지는 것이다.
이 개념이 필요해진 이유는 도시 이동이 지나치게 파편화되어 있기 때문이다. 사용자는 길찾기 앱, 철도 앱, 택시 앱, 공유 킥보드 앱을 각각 열어야 하고, 환승할 때마다 예약과 결제를 다시 해야 한다. 이 마찰 비용이 커질수록 사람들은 결국 자가용 소유를 더 편한 해답으로 받아들이게 된다.
또한 MaaS는 단순 편의 기능을 넘어 도시 운영 문제와도 연결된다. 대중교통 뼈대 위에 PM이나 택시를 붙이면 라스트 마일 공백을 줄일 수 있고, 혼잡 구간에 요금 인센티브를 얹으면 수요 분산 정책도 가능해진다. 즉 MaaS는 "좋은 앱"이 아니라 교통 이용 방식을 소유 중심에서 서비스 중심으로 바꾸는 운영 패러다임이다.
이 그림은 파편화된 이동과 통합된 이동의 차이를 한눈에 보여 준다.
┌──────────────────────────────────────────────────────────────────────┐
│ Door-to-door mobility: fragmented vs integrated │
├──────────────────────────────────────────────────────────────────────┤
│ Legacy : map app -> rail app -> taxi app -> separate tickets/pay │
│ MaaS : one app -> plan -> reserve -> pay once -> transfer guide │
│ │
│ value : the journey becomes the service, not each vehicle alone │
└──────────────────────────────────────────────────────────────────────┘
결국 MaaS의 출발점은 "교통수단이 많다"가 아니라 "여정이 끊긴다"는 문제 인식이다. 그래서 성공 여부는 교통수단 개수보다도, 끊어진 여정을 얼마나 매끄럽게 잇는지로 평가해야 한다.
- 📢 섹션 요약 비유: 식당을 여러 군데 돌아다니며 메뉴를 따로 주문하고 계산하는 대신, 한 번 주문으로 코스 요리가 이어서 나오는 레스토랑이 MaaS와 비슷하다. 중요한 것은 접시 수가 아니라 식사가 끊기지 않는 경험이다.
Ⅱ. 아키텍처 및 핵심 원리
MaaS의 기술 구조는 보통 교통 공급 계층 → 데이터 표준화 계층 → 여정 오케스트레이션 계층 → 결제·정산 계층 → 사용자·정책 계층으로 나뉜다. 여기서 가장 중요한 것은 중간 계층이 단순한 데이터 모음집이 아니라, 서로 다른 운송 서비스를 하나의 여정으로 조합하는 오케스트레이터라는 점이다.
| 계층 | 주요 구성 | 역할 | 설계 포인트 |
|---|---|---|---|
| 교통 공급 계층 | 버스, 지하철, 철도, 택시, PM, 카셰어링 | 운행 정보와 좌석·기기 상태 제공 | 운송 서비스 제공자 (TSP, Transport Service Provider) 참여 |
| 데이터 표준화 계층 | GTFS (General Transit Feed Specification), 실시간 위치 API, 운임 규칙 | 이기종 포맷을 공통 모델로 변환 | ID 체계, 위치·시간 기준 통합 |
| 여정 오케스트레이션 | 경로 탐색, 예상 도착 시간 (ETA, Estimated Time of Arrival), 환승 추천, 장애 대응 | 도어 투 도어 경로 생성 | 실시간 재탐색, 선호도 반영 |
| 결제·정산 계층 | 통합 결제, 쿠폰, 구독, 청산소 (Clearing House) | 한 번 결제 후 사업자별 수익 배분 | 분할 정산, 취소·환불, 수수료 정책 |
| 사용자·정책 계층 | 모바일 앱, 운영자 콘솔, 도시 정책 연계 | 시민 경험과 수요 관리 | 접근성, 개인정보 보호, 공공 인센티브 |
MaaS는 보통 정보 통합에서 시작해 거래 통합으로, 그다음에는 구독과 정책 통합으로 발전한다. 처음에는 여러 교통수단의 경로만 한 화면에 보여 주다가, 이후 예약과 결제를 통합하고, 더 나아가 월정액이나 혼잡 완화 인센티브처럼 도시 정책과 맞물리는 구조로 진화한다.
아래 구조는 MaaS가 실제로 어떤 데이터를 받아 어떤 서비스로 바꾸는지 보여 준다.
┌──────────────────────────────────────────────────────────────────────┐
│ Core MaaS stack: from transport supply to journey │
├──────────────────────────────────────────────────────────────────────┤
│ Bus / Metro / Rail / Taxi / PM / Car share │
│ │ real-time location, seats, fares │
│ ▼ │
│ data standardization (GTFS, APIs, IDs, fare rules) │
│ ▼ │
│ routing + booking + disruption handling │
│ ▼ │
│ one payment -> clearing house -> settlement to each operator │
│ ▼ │
│ traveler app / operator console / city policy dashboard │
└──────────────────────────────────────────────────────────────────────┘
여기서 난도가 가장 높은 구간은 정산이다. 사용자는 한 번만 결제하지만, 백엔드는 철도·버스·택시·PM 사업자에게 요금과 수수료를 각각 나눠야 한다. 그래서 MaaS는 길찾기 알고리즘만 잘 만든다고 완성되는 서비스가 아니라, 정산과 책임 분배까지 설계된 거래 플랫폼이어야 한다.
- 📢 섹션 요약 비유: 여러 악기가 모인 오케스트라에서 악보를 맞추고 출연료를 공정하게 나눠 주는 지휘자와 사무국이 함께 있어야 공연이 성립한다. MaaS도 경로 추천만이 아니라 배역 배분과 정산까지 있어야 진짜 플랫폼이 된다.
Ⅲ. 비교 및 연결
MaaS는 비슷한 용어와 자주 섞여 쓰이지만, 초점이 다르다. 길찾기 서비스는 정보를 보여 주는 데 머물고, 운송 서비스형 (TaaS, Transport as a Service) 은 특정 이동수단을 서비스화하는 데 집중한다. 반면 MaaS는 이동수단을 넘어서 여정 전체를 통합한다.
| 구분 | 길찾기 서비스 | TaaS | MaaS | 스마트 시티 플랫폼 |
|---|---|---|---|---|
| 핵심 대상 | 경로 정보 | 특정 운송수단 이용 | 도어 투 도어 여정 | 도시 운영 전체 |
| 제공 범위 | 검색·안내 | 호출·대여 | 검색·예약·결제·환승 | 교통·안전·환경 통합 관제 |
| 통합 수준 | 정보 중심 | 단일 모드 중심 | 멀티모달 오케스트레이션 | 정책·운영 중심 |
| 주요 가치 | 길 찾기 편의 | 차량 접근성 | 환승 마찰 제거 | 도시 효율과 제어 |
| 대표 판단 | 정확한 경로 안내 | 차량 가용성 | 정산·거버넌스·표준화 | 공공 데이터 거버넌스 |
또한 MaaS는 협력 지능형 교통체계 (C-ITS, Cooperative-Intelligent Transport Systems) 나 스마트 시티 플랫폼과도 연결된다. C-ITS가 도로와 차량의 실시간 상태를 알려 준다면, MaaS는 그 정보를 시민 여정 설계에 반영한다. 스마트 시티 플랫폼은 MaaS에서 수집된 이동 패턴을 정책에 반영해, 혼잡 요금이나 친환경 인센티브 같은 제어 전략을 설계할 수 있다.
즉 MaaS는 도시의 모든 교통 기술을 대체하는 개념이 아니라, 사용자 관점에서 이들을 조합하는 접점 계층이다. 그래서 대중교통 데이터가 빠지면 단순한 호출 앱으로 축소되고, 반대로 정책 계층과 연결되면 도시 운영의 중요한 도구가 된다.
- 📢 섹션 요약 비유: 길찾기 앱이 지도책이라면, TaaS는 택시 한 대를 빌리는 서비스이고, MaaS는 지도책과 표 판매소와 환승 안내원을 한꺼번에 가진 여행 매니저에 가깝다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서 MaaS를 검토할 때 가장 먼저 봐야 할 것은 "앱을 만들 수 있는가"가 아니라 "생태계를 묶을 수 있는가"다. 예를 들어 공항에서 도심까지 이동하는 시나리오를 생각해 보면, 철도 시간표와 좌석 정보, 공항버스 운행 현황, 택시 호출 가능 대수, PM 주차 위치까지 모두 연결되어야 사용자가 끊김 없는 경로를 받을 수 있다.
이때 공공교통 데이터가 폐쇄적이거나, 사업자 간 정산 기준이 정리되지 않았거나, 취소·환불 책임이 모호하면 MaaS는 금세 멈춘다. 반대로 데이터 표준과 수익 배분 룰이 잘 잡혀 있으면, 혼잡 시간 할인이나 월정액 패키지 같은 고급 서비스도 얹기 쉬워진다.
아래 결정 흐름은 MaaS를 "진짜 통합"으로 볼 수 있는 최소 조건을 보여 준다.
┌──────────────────────────────────────────────────────────────────────┐
│ Can a mobility service become MaaS? │
├──────────────────────────────────────────────────────────────────────┤
│ public transit data open and reliable? │
│ ├─ no -> super-app or TaaS only │
│ └─ yes │
│ unified booking/payment possible? │
│ ├─ no -> information integration level │
│ └─ yes │
│ settlement/governance agreed? │
│ ├─ no -> pilot remains fragile │
│ └─ yes -> MaaS scaling candidate │
└──────────────────────────────────────────────────────────────────────┘
기술사 판단 체크리스트
- 버스·철도·택시·PM 데이터를 실시간으로 받을 수 있는가?
- 운임 규칙과 취소·환불 기준을 단일 결제 흐름으로 묶을 수 있는가?
- 정산 청구와 수익 배분을 사업자들이 수용할 수 있는가?
- 고령자·장애인 접근성과 개인정보 보호 기준이 설계에 반영되었는가?
- 장애나 지연 발생 시 재탐색과 대체 안내가 가능한가?
자주 나오는 안티패턴
- 택시 호출과 PM 대여를 모아 놓고 대중교통 통합 없이 MaaS라고 부르는 경우
- 경로 안내만 통합하고 결제·정산은 각 사업자에게 다시 넘기는 경우
- 데이터와 수익을 한 플랫폼이 독점하려 해 사업자 협력을 잃는 경우
- 접근성, 환불 책임, 장애 대응을 나중 문제로 미루는 경우
좋은 MaaS는 기술적으로는 API와 정산 플랫폼이고, 정책적으로는 공공과 민간의 협업 구조다. 둘 중 하나라도 빠지면 서비스는 화려해 보여도 지속성이 약하다.
- 📢 섹션 요약 비유: 여러 버스를 이어 타는 여행을 한 명의 안내원이 끝까지 책임져 주려면, 시간표만 아는 것으로는 부족하고 표값 정산과 문제 생겼을 때의 대처까지 알아야 한다. MaaS도 바로 그런 종합 여행 운영자다.
Ⅴ. 기대효과 및 결론
MaaS를 제대로 구현하면 사용자는 앱 전환과 중복 결제 없이 더 예측 가능한 이동 경험을 얻고, 도시 입장에서는 승용차 의존도를 낮추며 대중교통과 공유 모빌리티의 활용률을 높일 수 있다. 운영자에게도 수요 패턴 데이터가 쌓여 공급 최적화, 동적 요금, 구독 상품 설계 같은 고도화가 가능해진다.
하지만 한계도 명확하다. 사업자 간 이해관계 충돌, 공공 데이터 개방 수준, 정산 복잡도, 장애 시 책임 분담, 개인정보 이슈는 기술만으로 해결되지 않는다. 특히 대중교통이 빠진 MaaS는 실질적으로 도시 이동의 뼈대를 놓친 것이므로, 서비스 범위가 제한될 수밖에 없다.
앞으로 MaaS는 자율주행 셔틀, 수요응답형 교통 (DRT, Demand Responsive Transit), 도심항공교통 (UAM, Urban Air Mobility) 같은 새로운 이동수단과도 연결될 수 있다. 다만 확장의 전제는 언제나 같다. 공통 데이터 모델, 단일 거래 흐름, 신뢰 가능한 거버넌스가 먼저다.
- 📢 섹션 요약 비유: 좋은 MaaS는 탈것을 많이 모아 놓은 전시장보다, 집에서 목적지까지 한 번에 이어 주는 믿을 만한 여행 코디네이터에 가깝다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 운송 서비스 제공자 (TSP, Transport Service Provider) | MaaS가 연계해야 하는 실제 교통 공급 주체 |
| GTFS (General Transit Feed Specification) | 대중교통 정보 표준화의 핵심 기반 |
| 계정 기반 발권 (ABT, Account-Based Ticketing) | 단일 사용자 계정으로 다중 운임을 통합 처리 |
| 청산소 (Clearing House) | 한 번의 결제를 사업자별로 분할 정산 |
| 개인형 이동수단 (PM, Personal Mobility) | 퍼스트 마일·라스트 마일 연결 수단 |
| 협력 지능형 교통체계 (C-ITS, Cooperative-Intelligent Transport Systems) | 실시간 교통 정보를 MaaS 경로 최적화에 제공 |
| 스마트 시티 플랫폼 | MaaS 데이터를 도시 정책과 운영으로 확장 |
📈 관련 키워드 및 발전 흐름도
Fragmented transport services
│
▼
Open data + standardized APIs
│
▼
Integrated routing / booking / payment
│
▼
Subscription, incentives, demand management
│
▼
City-scale MaaS linked with C-ITS and Smart City
이 흐름은 개별 교통수단의 파편화가 데이터 표준화와 거래 통합을 거쳐, 도시 차원의 수요 관리 도구로 발전하는 방향을 보여 준다.
👶 어린이를 위한 3줄 비유 설명
- 버스표, 기차표, 택시비를 따로 내지 않고 한 장의 마법 표로 이어 타는 게 MaaS예요.
- 앱이 어디서 갈아타야 가장 빠른지도 같이 알려줘요.
- 그래서 자동차를 꼭 사지 않아도 필요한 탈것들을 이어서 편하게 갈 수 있어요.