상황
알툴즈 홈페이지의 여행자보험 이벤트를 보며, 이벤트에서 공항 서비스로 들어온 사람이 여행에 필요한 정보도 확인할 수 있으면 좋겠다고 생각했습니다. 주차와 항공편처럼 당장 필요한 정보를 제공하면, 이벤트에 대한 관심이 참여로 이어질 가능성도 높아질 것이라고 봤습니다.

이 생각을 바탕으로 인천국제공항공사 공공데이터를 연결해 ‘공항 지금’을 만들었습니다. 웹에 직접 배포해 개인 접근 환경에서 PoC를 진행하고 있습니다.
문제
공항 서비스가 기존 홈페이지만큼 많은 방문자를 모을 수 있을지는 알 수 없었습니다. 하지만 유입이 많아도 이벤트 참여로 이어지지 않는다면 방문자 수만으로 가치를 판단하기는 어려웠습니다.
그래서 두 경우를 비교해 봤습니다.
| 구분 | 유입 | 전환에 대한 판단 |
|---|---|---|
| 기존 홈페이지 | 많지만 방문 목적이 다양함 | 여행자보험에 관심이 적으면 전환율이 낮을 수 있음 |
| 공항 서비스 | 적지만 공항 이용 목적이 분명함 | 필요한 여행 정보를 함께 제공해 전환율을 기대할 수 있음 |
이는 측정 결과가 아닌 기획 단계의 비교입니다. 부족한 유입은 제가 직접 발품을 팔아 서비스를 알리며 늘려보려고 했습니다.
필요한 여행 정보를 제공해 전환율을 높이고, 직접 유입을 늘리는 방향이라면 현재의 한계를 어느 정도 보완할 수 있다고 생각했습니다. 두 가지를 함께 시도할 수 있다는 점에서 경쟁력이 있다고 판단했습니다.
원인
전환율의 차이를 만들 수 있는 것은 방문 목적과 이벤트의 관련성이라고 봤습니다. 홈페이지에 들어온 이유는 다양하지만, 공항 주차와 항공편을 확인하는 사람은 출국이나 마중처럼 구체적인 일정이 있습니다.
여행자보험 이벤트에서 들어온 사람에게 이런 정보를 제공하면 여행 준비에 필요한 내용을 함께 확인할 수 있습니다. 반대로 주차나 항공편을 찾으러 온 여행자에게도 보험 이벤트가 관련 정보가 될 수 있다고 생각했습니다.
그래서 유입 규모와 함께 들어온 사람이 무엇을 찾고, 그 정보가 이벤트 참여와 어떻게 이어지는지를 보려고 했습니다. 첫 구현에서는 주차·항공편 서비스를 먼저 만들고, 보험 이벤트 연결은 이후에 검토하기로 했습니다. PoC에서는 정보를 확인할 이유와 다시 찾을 이유를 갖추는 데 집중했습니다.
해결
링크 한 번으로 주차 현황에 접근하게 했습니다
두 서비스의 접근 과정과 화면을 비교했습니다.
| 네이버 검색 | 카카오 T |
|---|---|
![]() | ![]() |
| 접근: ‘인천공항 2터미널 주차’ 검색 표시: 터미널·층별 주차 가능 대수 안내: 장기주차장 현황과 예약주차장 운영 상태 | 접근: 앱 설치 → 인천공항 미리보기 → 주차정보 표시: 터미널·구역별 주차 가능 대수와 만차 상태 안내: 주차 요금과 주변 주차장 찾기 |
공항 지금은 정보를 확인하기까지 거치는 단계를 줄이는 데 차별점을 뒀습니다.
- 바로 확인: 검색이나 앱 설치 없이 링크를 열어 주차 현황을 봅니다.
- 다시 확인: 저장한 링크로 접속해 검색을 반복하지 않습니다.
- 항공편 공유: 항공편별 링크로 같은 날짜의 항공편과 터미널 주차 정보를 확인합니다.
사용자가 서비스를 여는 상황을 나눴습니다
사용자가 언제 들어오고 무엇을 확인할지 다음과 같이 가정했습니다.
- 출국 전: 자가용을 가져갈지 고민하는 사람이 항공편의 터미널과 주차 상태를 보고, 필요하면 대중교통 안내를 확인합니다.
- 이동 중: 동승자가 저장한 주차장을 다시 열어 이전보다 자리가 줄었는지 확인합니다.
- 만차 확인: 이용하려던 주차장이 만차라면 같은 터미널의 다른 일반 주차장을 비교하고 위치를 확인합니다.
- 가족 마중: 도착편의 변경 시각과 터미널을 확인하고, 해당 터미널의 단기주차장을 살펴봅니다.
- 일행 공유: 항공편 링크를 받은 사람이 날짜와 편명을 다시 검색하지 않고 같은 항공편과 주차 정보를 확인합니다.
세 상황에 필요한 기능부터 만들었습니다
출국 전 이동수단 선택, 만차 후 주차장 선택, 가족 마중을 중심으로 기능을 골랐습니다. 같은 주차·항공편 데이터로 지원하면서 이동 중 재확인과 일행 공유까지 연결할 수 있었습니다.
| 기능 | 넣은 이유 |
|---|---|
| 주차 현황 | 현재 상태와 잔여 면수를 바로 확인 |
| 항공편과 터미널 연결 | 자신의 일정에 맞는 주차장 확인 |
| 관심 저장과 이전 대비 변화 | 다시 검색하는 단계를 줄이고 달라진 값 확인 |
| 최근 3시간 그래프 | 한 시점의 숫자와 함께 최근 변화 확인 |
| 주차장 대안과 비교 | 만차 후 다른 주차장 선택 |
| 항공편 공유 | 일행이 같은 항공편으로 바로 접속 |
날씨로 개별 항공편의 지연 원인을 설명하거나 도착 시점의 만차를 예측하는 기능은 보류했습니다. 데이터가 있어도 그 질문에 답할 근거가 충분한지는 따로 봐야 했습니다. 공항 이용과 연결이 약한 여행 콘텐츠도 제외했습니다.
첫 화면에서 확인하고, 필요하면 더 살펴보게 했습니다
첫 화면에는 ‘출국해요’와 ‘마중가요’를 두고, 주차 목록에서 상태와 잔여 면수, 자료 시각을 보여 줬습니다. 항공편은 날짜와 편명, 항공사, 도시로 찾고 해당 터미널의 주차 정보에 연결했습니다.

주차 탭은 단기주차, 장기주차, 예약주차, 관심 순서로 배치했습니다. 단기주차로 시작하고, 출국·마중 모드를 바꿔도 주차 종류는 사용자가 선택하게 했습니다.
관심 항목은 계정 가입 없이 익명 쿠키에 연결해 저장했습니다. 같은 브라우저에서 다시 열면 복원됩니다.
만차를 확인한 뒤 다른 선택을 할 수 있게 했습니다
만차라는 사실만 알려 주면 사용자는 다른 주차장이나 이동수단을 다시 찾아야 합니다. 그래서 ‘만차라면, 다른 선택지’를 두고 다음 판단에 필요한 안내를 모았습니다.

- 다른 주차장: 같은 터미널에서 잔여 면수가 있는 일반 주차장을 찾아볼 수 있게 했습니다.
- 위치·셔틀·요금: 빈자리뿐 아니라 이동 방법과 비용도 확인해 주차장을 고를 수 있게 했습니다.
- 대중교통: 출발 전 주차가 어렵다고 판단하면 차를 가져갈지 다시 결정할 수 있게 했습니다.
주차장은 최대 두 곳을 비교하도록 했습니다. 예약주차장은 일반 대안에서 제외하고, 예약 없이 이용할 수 있다고 오해하지 않도록 이용 조건을 표시했습니다.
항공편을 URL 경로에 담아 차별점을 찾았습니다
항공편은 선택부터 주차 확인과 공유까지 이어지도록 했습니다.
- 찾기: ‘내 항공편 연결하기’나 이미 선택된 편명을 누르면 검색창이 열립니다.
- 선택: 여행 날짜를 정하고 편명·항공사·도시로 검색한 뒤 항공편을 누릅니다.
- 연결: 검색창이 닫히고 카드에 예정·변경 시각, 터미널, 탑승구 등이 표시됩니다. 주차 목록도 해당 터미널로 바뀝니다.
- 공유: ‘이 항공편 링크 공유’로 전달한 링크를 열면 같은 항공편과 터미널의 주차 현황이 표시됩니다.
터미널을 따로 검색하거나 주차 탭을 다시 맞추는 절차를 줄이려는 흐름입니다. 선택한 날짜, 출도착, 편명은 URL 경로에 반영됩니다.
/flights/2026-09-10/departure/OM308?terminal=T1
| 공유할 항공편 | 링크를 열면 보이는 화면 |
|---|---|
![]() | ![]() |
항공편 링크를 열면 같은 항공편과 T1 주차 현황이 함께 표시됩니다.
편명만 전달하면 받는 사람이 날짜와 출도착을 맞춰 다시 검색해야 합니다. 공유 경로에는 이 조건이 담겨 있으며, 브라우저에 남은 이전 선택보다 우선합니다.
제가 찾은 차별점은 주차 확인과 항공편 공유를 하나의 접근 경로로 연결한 것입니다. 링크가 서비스 주소를 알리는 데서 끝나지 않고, 일행이 확인할 항공편까지 가리키도록 했습니다.
사용자 조회와 데이터 수집을 나눴습니다
주차와 당일·전일 출발·도착편은 5분 간격의 배치로 수집하고, 사용자 조회에는 저장된 데이터를 사용했습니다. 방문자가 없어도 이력을 남기고, 조회마다 외부 API를 호출하지 않기 위한 구조입니다.
하지만 배치가 실패하면 사용자는 계속 과거 데이터를 보게 됩니다. 그래서 최근 5분 이내에 저장된 데이터가 없으면 조회 요청에서 API를 직접 호출하고, 성공한 데이터를 저장해 다음 조회에도 사용하도록 했습니다. 배치 실패를 조회 시 수집으로 보완하는 방식입니다.
이때 API까지 느리거나 실패하면 조회도 함께 지연될 수 있습니다. 응답 대기는 3초로 제한하고, 5xx 오류가 나면 마지막 저장 데이터를 보여 주도록 처리했습니다.
| 상황 | 처리 | 표시할 데이터 |
|---|---|---|
| 최근 5분 이내 저장 데이터가 있음 | 저장소에서 조회 | 저장된 데이터 |
| 최근 5분 이내 저장 데이터가 없고, API가 3초 미만에 정상 응답 | API 응답을 저장하고 조회에 사용 | 새로 받은 데이터 |
| API 응답이 3초 이상 지연 | 응답 대기를 끝내고 저장소에서 조회 | 마지막 저장 데이터 |
| API가 5xx 오류를 반환 | 저장소에서 조회 | 마지막 저장 데이터 |
| API 지연·실패 시 저장 데이터도 없음 | 정보 없음으로 안내 | 숫자를 표시하지 않음 |
기준은 최신 데이터 확보에 실패해도 조회는 이어가는 것이었습니다. 과거 데이터에는 자료 시각과 수집 지연을 함께 표시했습니다.

이후 분석을 위해 원본과 집계를 남겼습니다
화면에는 최근 3시간의 변화를 보여 주지만, 저장 기간까지 3시간으로 제한하지는 않았습니다. 원본은 R2에 압축 파일로, 조회 데이터와 시간별 집계·수집 기록은 D1에 저장하도록 구현했습니다.
원본을 먼저 저장하고 조회 데이터와 집계를 반영했습니다. 이후 집계 기준을 바꾸더라도 원본을 다시 해석할 수 있게 하려는 선택입니다. 같은 자료와 시간 구간이 중복 집계되지 않도록 처리했습니다.
집계에서는 무엇을 한 건으로 세는지도 정해야 했습니다. 같은 항공편을 5분마다 수집했다고 운항편 수를 계속 더할 수는 없습니다. 항공편은 시간대의 마지막 전체 상태를 남기고, 공동운항은 대표편과 예정시각으로 묶었습니다.
주차 역시 만차로 관측된 비율과 실제 만차였던 시간은 다릅니다. 수집 사이에 일어난 변화는 알 수 없기 때문입니다. 데이터를 오래 모으는 것과 그 데이터로 답할 수 있는 질문은 따로 생각해야 했습니다.

저장된 T1 단기주차장 지하 1층의 관측 이력입니다.
| 시작 · 11:29 | 마지막 · 11:50 | 차이 |
|---|---|---|
| 22면 | 19면 | 3면 감소 |
21분 동안 잔여 면수가 3면 줄었습니다. 이처럼 이력을 남기면 변화를 비교할 수 있습니다. 다만 입출차 대수는 이 차이만으로 알 수 없습니다.
주차·항공편 정보를 오해하지 않도록 안내했습니다
주차 숫자나 항공편 상태만 보고 판단하지 않도록 다음 안내를 붙였습니다.
- 빈자리: 지금 자리가 있어도 도착할 때는 만차일 수 있습니다.
- 항공편 도착: 비행기가 도착해도 입국 절차가 남아 있어 바로 만날 수는 없습니다.
- 혼잡: 잔여 면수 비율이 10% 미만일 때 표시하는 자체 기준입니다.
- 정보 없음: 자료가 없어 상태를 알 수 없다는 뜻입니다. 만차와 구분해 표시했습니다.
결과
현재 상황에서 사용자의 니즈를 파악하고, 시나리오를 작성해 필요한 기능을 정리했습니다. 이 과정을 거치며 기능을 구성하는 기준이 필요하다고 느꼈습니다.
AI로 구현할 수 있는 기능이 많아진 만큼, 무엇을 추가하고 뺄지 더 고민하게 됐습니다. 만들 수 있는 기능 중 어디에 집중할지 판단하는 일도 중요해졌습니다.
일단 생각한 기능은 모두 PoC에 넣어 봤습니다. 이제 기획팀에 보여 주고 실제로 쓸 만한지 의견을 들어보려고 합니다. 그다음 정식 서비스로 내놓을 수 있을지도 함께 고민해 볼 생각입니다. 이후 이야기도 결과가 나오면 남겨 보겠습니다.



