공공데이터의 갱신 시각과 출처를 함께 보여준 이유

공공데이터를 쓰는 앱에서는 “정확한 정보”라는 말만으로 부족하다. 특히 한강자리처럼 이동과 체류 판단을 돕는 앱에서는 숫자 하나가 바로 행동으로 이어진다.

주차 잔여 대수가 20대라고 보이면 사용자는 차를 가져갈 수 있다고 느낀다. 혼잡도가 낮다고 보이면 지금 가도 괜찮겠다고 생각한다. 오늘 행사가 있다고 보이면 목적지를 바꿀 수도 있다.

화면의 숫자, 상태 라벨과 갱신 시각은 “가도 되겠다” 혹은 “오늘은 피하자”라는 판단에 함께 쓰인다.

문제는 공공데이터가 항상 같은 속도와 같은 의미로 오지 않는다는 점이다.

어떤 값은 방금 갱신된 값이다. 어떤 값은 마지막 성공 수집 이후 시간이 조금 지났다. 어떤 값은 출처는 살아 있지만 해당 공원에는 항목이 없다. 어떤 값은 출처 자체가 실패해서 지금은 믿고 보기 어렵다.

이 차이를 모두 “정보 없음”으로 표시하면 사용자는 기다려야 하는지 다른 정보를 봐야 하는지 알 수 없다. 오래된 값을 최신처럼 표시하면 현장 상황을 오해할 수 있다.

한강자리에서는 숫자와 함께 세 가지를 보여줬다.

갱신 시각.
출처.
모른다는 말.

숫자와 함께 적은 확인 시각

숫자는 화면에서 힘이 세다. “20대 가능” 같은 표현은 설명 없이도 결론처럼 읽힌다. 하지만 주차장은 사용자가 확인하는 순간에도 계속 바뀐다. 행사나 통제, 날씨, 시간대에 따라 평소와 다르게 움직일 수도 있다.

숫자에는 관측 시각과 마지막 성공 수집 시각을 붙이고, 오래된 값은 별도 상태로 표시했다.

“여유”, “보통”, “혼잡”, “만차” 상태 라벨은 사용자가 잔여 대수를 해석하도록 돕는다. 화면에는 라벨과 잔여 대수를 함께 표시했다.

출처도 숨기지 않기로 했다. 한강자리에는 주차, 실시간 문맥, 행사, 시설, 공지처럼 성격이 다른 데이터가 들어온다. 각각 역할도 다르고 새로 들어오는 속도도 다르다. 행사 목록과 실시간 혼잡도와 시설 상태를 같은 종류의 정보처럼 섞으면 화면은 단순해질 수 있지만 사용자는 무엇을 얼마나 믿어야 할지 알기 어렵다.

정보가 없는 서로 다른 이유

데이터가 없을 때 null, empty array, timeout과 404를 같은 빈 화면으로 표시하면 원인을 구분할 수 없다. 원인에 따라 사용자가 할 수 있는 일도 달랐다.

주차장이 없는 공원이라면 사용자는 대중교통이나 주변 주차장을 봐야 한다. 주차장은 있지만 실시간 값이 없다면 총면수와 위치만 참고할 수 있다. 출처가 일시적으로 실패했다면 잠시 뒤 다시 확인하고 마지막 성공 값이 오래됐다면 현장 차이를 감안해야 한다.

화면에는 “현재 수집이 지연되고 있어요”와 “이 공원은 실시간 주차 정보를 제공하지 않아요”를 구분해 표시했다. 안내 문구마다 다시 확인할지 다른 정보를 볼지가 드러나게 했다.

화면이 말해야 하는 것	사용자가 할 수 있는 일
값이 방금 갱신됨	현재값을 중심으로 본다.
마지막 값이 조금 오래됨	현장 변화 가능성을 감안한다.
출처가 일시적으로 실패함	잠시 뒤 다시 확인하거나 다른 정보를 본다.
해당 공원에 정보가 없음	주차장 대신 대중교통, 시설, 공지 같은 다른 정보를 본다.
아직 연결하지 않은 출처	앱이 모른다는 사실을 숨기지 않는다.

화면 문구로 옮긴 내부 상태

이 구분은 API 응답과 화면 안내에도 들어갔다. 내부 응답 구조에는 fresh, partial, stale, unavailable 같은 상태가 있고, 각 섹션마다 갱신 시각과 마지막 성공 시각, 출처 상태를 나눠 둔다.

내부 상태명을 그대로 사용자에게 보여주지는 않았다. stale은 화면에서 “마지막 확인 기준”이나 “업데이트가 지연되고 있어요”로 바꿨다. 내부 상태명은 앱, 위젯과 알림이 같은 값을 같은 뜻으로 처리할 때 사용했다.

화면에는 값이 언제 어느 출처에서 왔는지와 현재 수집 상태를 함께 표시했다. 한강자리는 서울시나 한강사업본부가 운영하는 앱이 아니라 공개된 정보와 직접 정리한 데이터로 만든 앱이다.

직접 써 보고 남긴 갱신 시각과 출처

처음에는 갱신 시각이나 출처 표시가 화면을 복잡하게 만들까 봐 걱정했다. 직접 써보니 값이 없는 원인과 다시 확인할 시점을 구분할 수 있었다.

몇 분 전 기준인지. 어느 출처 기준인지. 오래된 값인지. 값이 없는 건지, 가져오지 못한 건지.

백엔드와 파서가 나눈 상태는 화면 안내, 상태 라벨, 위젯 표시와 알림 기준에도 같은 의미로 이어졌다.

더 보수적인 알림 기준

알림은 화면보다 더 조심스러운 기능이다. 앱 안에서 오래된 값을 보여주는 것도 문제지만 오래된 값으로 알림을 보내면 더 큰 문제다. 나는 알림을 행동의 신호로 다뤘다.

그래서 알림 후보를 만들 때도 값의 신선도와 출처 상태를 봐야 했다. 단순히 “잔여 대수가 기준보다 낮다”만으로는 부족하다. 그 값이 언제 확인된 것인지, 최근 수집이 정상인지, 이미 비슷한 알림을 보냈는지까지 같이 봐야 한다.

앱은 값마다 출처와 갱신 시각을 함께 내려 보냈다. 알림 후보도 값의 신선도, 최근 수집 상태와 중복 발송 여부를 통과한 경우에만 만들었다. 화면과 알림은 같은 상태 정보를 사용해 사용자가 참고할 수 있는 범위를 표시했다.