주차 앱에서 한강 방문 앱으로

주차장은 한강자리의 시작점이었다. 한강에 갈지 말지를 정할 때 나부터 주차장과 행사, 공지와 혼잡도를 함께 봤다.

처음에는 주차 문제만 풀어도 충분하다고 생각했다. 막상 앱을 켜고 한강에 갈 준비를 해보니 잔여 대수만으로는 답할 수 없는 질문들이 따라왔다.

차를 가져갈 수 있더라도 오늘 행사가 너무 크면 목적지를 바꿀 수 있다. 공지가 있으면 아예 다른 공원을 고르는 편이 낫다. 대중교통으로 가는 날에는 주차 정보보다 혼잡도와 도착해서 찾을 시설 위치가 먼저였다.

오늘 행사가 있는지.
사람이 많은지.
화장실이나 편의점은 어디 있는지.
공지된 통제나 시설 중단은 없는지.
차 없이 가면 어느 역이나 정류장에서 내리는 게 좋은지.

나도 이런 정보를 여러 앱과 웹사이트에서 따로 찾아봤다. 처음 가는 공원에서는 어느 출처부터 봐야 할지 더 알기 어려웠다.

“한강공원”이라고 검색하면 하나의 장소처럼 보인다. 실제로는 여의도, 반포, 뚝섬, 망원, 잠실마다 가는 길과 분위기와 붐비는 정도가 다르다.

무엇보다 한강을 이용하는 방식이 사람마다 다르다.

화면을 나눌 때는 차를 가져가는 사람에게 주차장 잔여 대수와 내비게이션이 먼저 필요하다고 가정했다. 대중교통으로 오는 사람에게는 공원 혼잡도, 행사, 시설과 도보 길찾기가 먼저 필요하다고 봤다. 아이와 피크닉을 가는 사람, 자전거를 타는 사람, 밤에 산책하러 가는 사람도 한강에 가기 전과 도착한 뒤에 궁금한 것이 조금씩 다를 것이라고 가정했다.

한강자리는 주차 앱에서 한강공원을 고르고, 도착해서 필요한 것을 찾는 앱으로 방향을 바꿨다. 사용자가 실제로 묻는 말을 기준으로 화면 앞쪽의 정보를 다시 골랐다.

앱 안에서는 사용자가 들고 있는 질문에 맞춰 화면을 둘로 나눴다.

• 차량 화면: 주차장 현황, 시간대별 주차 변화, 내비게이션, 알림
• 일반 화면: 공원 혼잡도, 행사, 시설, 공지, 대중교통과 도보 길찾기, 근처 시설 탐색

두 화면은 같은 공원을 다루지만 출발점이 다르다.

화면	먼저 답할 질문	앞에 놓은 정보
차량 화면	지금 차를 가져가도 될까?	주차장 상태, 추천 후보, 내비게이션, 알림
일반 화면	오늘 이 공원이 괜찮을까, 근처에서 무엇을 찾을까?	혼잡도, 행사, 시설, 공지, 대중교통

두 화면을 나누지 않으면 주차장, 행사, 시설과 공지가 한곳에서 같은 비중으로 보였다. 차량 화면과 일반 화면을 나눈 뒤에는 내가 써보니 각 화면에서 목적지와 필요한 시설을 더 빨리 골랐다.

보여주는 것은 늘었지만 방향은 여전히 좁았다. 방문 전후에 바로 필요한 것만 앞에 두고 나머지는 뒤로 미뤘다.

한때는 전국 공원 나들이 앱 같은 더 넓은 방향도 검토했다. 출시 범위는 내가 자주 가고 데이터 출처를 직접 검증할 수 있는 한강으로 정했다.

기능보다 먼저 확인한 방문 목적

주차 앱에서 나들이 앱으로 넓히는 동안 새 정보를 넣기 전에 “이게 한강에 가기 전이나 한강 안에서 정말 도움이 되나”를 먼저 물었다.

행사는 방문 목적이 되고, 공지와 통제 정보는 헛걸음을 줄인다. 시설 정보는 현장에서 헤매는 시간을 줄이고, 혼잡도와 날씨는 오늘 어느 공원이 나은지 고르는 데 도움이 된다.

예쁜 소개 문구와 일반 관광 정보는 첫 공개에서 뒤로 미뤘다. 방문할 공원과 현장에서 필요한 시설을 빨리 고르는 정보부터 배치했다.

이 질문은 차량 화면과 일반 화면을 나누는 데도 도움이 됐다. 차량 화면에서는 주차장이 중심이다. 일반 화면에서는 공원 상황과 현장에서 찾을 시설이 중심이다. 모든 정보를 같은 화면에 넣었을 때는 두 질문 모두 뒤섞였다.

보여줄 것이 늘어날수록 “무엇을 빨리 정하고 찾게 도울까”를 먼저 물었다.

서로 다른 출처와 갱신 속도

공식 출처마다 품질과 의미가 달랐다. 어떤 데이터는 자주 갱신되지만 필드가 거칠다. 안정적이지만 방문 직전 판단에 쓰기에는 갱신이 느린 데이터도 있다. 공식 목록에는 있어도 화면에 바로 보여주기엔 설명이 부족한 정보도 있다.

주차, 행사, 공지, 시설, 실시간 혼잡도는 각각 다른 속도로 움직인다. 가져오는 주기와 보여주는 방식이 달라야 하고 실패했을 때 사용자에게 보여주는 안내도 달라야 했다.

예를 들어 주차 잔여 대수가 없을 때와 행사 정보가 없을 때는 의미가 다르다. 주차 잔여 대수가 없으면 차를 가져갈지 말지부터 흔들린다. 반면 행사 정보가 없다는 건 오늘 목적지가 될 만한 이벤트를 찾지 못했다는 뜻에 가깝다.

둘을 똑같이 “정보 없음”으로 표시하면 화면은 단순해지지만 사용자는 더 불확실한 상태로 출발하게 된다.

지킬 수 있는 앱 설명

이 과정에서 가장 조심한 건 표현이었다. “정확한 한강 정보”라고 말하면 쉬워 보이지만 공공데이터를 모아 보여주는 독립 앱이 감당하기에는 큰 약속이다.

앱 설명에는 “공식 공개 정보를 바탕으로 한강에 가기 전과 한강 안에서 필요한 판단을 돕는다”고 적었다.

앱을 설명하는 말은 개발할 때의 선이기도 했다. 어디까지 보여줄 수 있는지, 어떤 값은 참고용인지, 오래된 값은 어떻게 말할지 정하지 않으면 화면과 API가 계속 흔들린다.

한강자리는 공식 앱이 아니기 때문에 더 단정적으로 말하면 안 됐다. 그래서 오래된 값에는 갱신 시각을 함께 표시해 얼마나 지난 정보인지 알렸다.

이 설명에 맞춰 출처, 갱신 시각과 값의 한계를 화면과 API에 함께 넣었다.

숫자 옆의 갱신 시각과 출처

공공데이터 앱은 처음에는 데이터를 가져와서 화면에 보여주면 끝날 것처럼 보인다. 실제로는 그 다음이 더 어렵다.

각 정보를 어느 범위까지 믿고 보여줄 수 있는지 정해야 했다.

예를 들어 주차 잔여 대수는 숫자로 보인다. 숫자는 단정적으로 느껴진다. 하지만 사용자는 그 숫자를 보고 실제로 차를 몰고 간다. 앱에 20대가 남았다고 떠 있어도, 도착하는 동안 상황은 바뀔 수 있다. 특정 주차장의 정보가 늦게 갱신될 수도 있고, 행사나 통제로 평소와 다르게 운영될 수도 있다.

잔여 대수와 함께 상태, 갱신 시각, 출처와 시간대별 변화를 보여줬다. “여유”, “보통”, “혼잡”, “만차” 같은 라벨은 사용자가 숫자를 해석하도록 돕는 말로 사용했다.

행사와 시설 정보도 비슷했다. 미래한강본부의 행사/공연 정보, 한강소식, 새소식, 시설 데이터, 서울 실시간 도시데이터처럼 쓸 수 있는 공식 출처가 있었지만 출처마다 쓰임과 갱신 주기가 달랐다. 어떤 것은 행사 목록에 가깝고, 어떤 것은 운영 공지에 가깝고, 어떤 것은 현재 혼잡도나 날씨에 가깝다.

서버에서는 출처를 화면에서 필요한 쓰임대로 나눠 다뤘다.

• 주차: 지금 차를 가져갈지 볼 때 필요한 잔여 대수와 상태
• 실시간 상황: 공원 혼잡도, 날씨, 도로 상태
• 행사/프로그램: 방문 목적이 될 수 있는 공식 일정
• 공지: 운영 변경, 통제, 시설 중단처럼 헛걸음을 만들 수 있는 정보
• 시설: 화장실, 매점, 주차장, 접근 지점처럼 현장에서 찾는 정보

한강자리는 공개된 공공데이터와 공식 정보를 보기 쉽게 모아주는 독립 앱이다. 출처와 한계를 함께 표시하는 원칙은 이후 예측, 캐시, 다국어, 알림과 장애 대응에도 적용했다.

사용자가 한강에 가기 전과 도착한 뒤에 묻는 질문을 따라 화면을 나누고, 답할 수 있는 정보에는 출처와 갱신 시각을 붙였다. 그 결과 주차, 행사, 공지와 시설을 한 앱에서 다루면서도 각 값의 쓰임과 한계를 구분할 수 있었다.