숫자만으로는 공공데이터를 믿기 어려웠다

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

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

그래서 화면에 올라가는 값은 단순한 데이터가 아니었다. 숫자 하나, 라벨 하나, 갱신 시각 하나가 모여 “가도 되겠다” 혹은 “오늘은 피하자”라는 생각으로 이어진다.

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

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

이 차이를 모두 “정보 없음”으로 뭉개면 앱은 무심해진다. 반대로 오래된 값을 최신처럼 보여주면 더 위험하다.

그래서 한강자리에서는 숫자만 보여주지 않으려 했다. 숫자와 함께 세 가지를 보여줘야 했다.

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

숫자에는 확인 시각을 함께 적었다

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

그래서 숫자에는 확인 시각이 필요했다. 언제 관측된 값인지, 마지막으로 언제 성공적으로 가져온 값인지, 오래된 값이면 오래됐다고 말해야 했다.

상태 라벨도 마찬가지다. “여유”, “보통”, “혼잡”, “만차”는 숫자를 예쁘게 바꾼 이름이 아니다. 사용자가 숫자를 해석하게 돕는 보조 신호다. 잔여 대수와 상태가 함께 있을 때, 사용자는 조금 더 현실적으로 받아들일 수 있다.

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

정보가 없는 이유를 구분해야 했다

데이터가 없을 때 어떤 안내를 보여줄지도 생각보다 중요했다. 개발자 입장에서는 null, empty array, timeout, 404가 모두 다른데, 사용자에게는 전부 빈 화면처럼 보일 수 있다. 그런데 사용자가 해야 할 일은 각각 다르다.

주차장이 없는 공원이라면 사용자는 대중교통이나 주변 주차장을 봐야 한다. 주차장은 있지만 실시간 잔여 대수가 없다면 총면수와 위치 정도는 참고할 수 있다.

출처가 일시적으로 실패했다면 잠시 뒤 다시 확인할 수 있다. 마지막 성공 값이 오래됐다면 현장 차이를 감안하고 움직여야 한다.

그래서 “정보 없음”이라는 안내 하나로 끝내지 않으려 했다. 화면에 쓰는 말은 짧아야 하지만, 그 짧은 말 안에 다음에 뭘 하면 되는지가 들어 있어야 한다. “현재 수집이 지연되고 있어요”와 “이 공원은 실시간 주차 정보를 제공하지 않아요”는 비슷해 보여도 완전히 다른 안내다.

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

이렇게 쓰고 보니 데이터 상태는 개발자용 예외 처리가 아니었다. 사용자가 다음에 무엇을 볼지 바꾸는 말이었다.

모를 때는 모른다고 말해야 했다

가장 어려운 건 모른다는 말을 어떻게 보여줄지였다.

데이터가 비어 있는 경우에도 이유는 다르다.

해당 공원에 주차장이 없을 수 있다. 주차장은 있지만 실시간 잔여 대수가 없을 수 있다. 출처가 일시적으로 실패했을 수 있다. 마지막 성공 값이 오래되어 참고만 해야 할 수 있다. 아직 제품에서 연결하지 않은 출처일 수도 있다.

사용자에게는 이 차이가 중요하다. “주차 정보 미제공”과 “현재 수집 실패”와 “오래된 정보”는 모두 다른 행동을 만든다. 하나는 주변 후보를 보게 하고, 하나는 잠시 뒤 다시 확인하게 하고, 하나는 현장 차이를 감안하게 한다.

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

앱은 아는 값을 보여주는 동시에, 어디까지 모르는지도 보여줘야 한다.

내부 상태명을 그대로 사용자에게 보여주지는 않는다. stale은 개발자가 보기 좋은 이름이지, 사용자가 읽기 좋은 표현은 아니다. 화면에서는 “마지막 확인 기준”이나 “업데이트가 지연되고 있어요”처럼 바꿔야 한다. 반대로 내부에는 이 상태명이 있어야 한다. 그래야 앱, 위젯, 알림이 같은 값을 같은 뜻으로 다룬다.

사용자는 데이터 출처의 모든 사정을 알 필요는 없지만, 앱이 지금 값을 얼마나 믿고 말하는지는 느낄 수 있어야 한다.

한강자리는 기관이 직접 운영하는 서비스가 아니라, 공개된 정보와 직접 정리한 데이터를 바탕으로 방문 전후의 판단을 돕는 독립 앱이다. 그래서 더더욱 단정적으로 말하면 안 됐다. “맞다”는 말보다 “언제, 어디서 온 값이고, 지금 어느 정도 믿어도 되는가”가 더 중요했다.

갱신 시각과 출처가 불안을 줄였다

처음에는 갱신 시각이나 출처 표시가 화면을 지저분하게 만들까 봐 걱정했다. 하지만 막상 직접 써보면 그 작은 안내가 오히려 마음을 편하게 했다.

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

이걸 알면 사용자는 앱을 맹신하지 않고 스스로 판단할 수 있다. 앱은 사용자를 대신해 결론을 과하게 내리는 것이 아니라, 움직이기 전후에 확인할 것들을 정직하게 정리해야 한다.

한강자리에서 데이터 신뢰도는 백엔드나 파서만의 문제가 아니었다. 화면 안내, 상태 라벨, 위젯 표시, 알림 기준까지 모두 같은 태도를 가져야 했다.

신뢰는 한 번에 생기지 않는다. 숫자가 맞는 날에도 생기고, 모른다고 말해야 하는 날에도 생긴다. 앱이 모르는 범위를 숨기지 않을 때, 사용자는 값을 과하게 믿지 않고 현실적으로 받아들인다.

알림은 더 보수적으로 보내야 했다

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

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

결국 데이터 신뢰도는 화면의 작은 보조 문구가 아니라 앱 전체의 안전장치였다. 정확하다고 말하는 것보다, 믿을 수 있는 만큼만 말하는 것이 더 중요했다.

공공데이터 앱을 만들면서 가장 크게 배운 것도 이것이었다. 좋은 데이터 앱은 데이터를 많이 보여주는 앱이 아니라, 지금 보여주는 값의 무게를 알고 있는 앱이어야 한다.

한강자리에서 정확함은 숫자 하나를 맞히는 일이 아니었다. 숫자와 갱신 시각, 출처를 함께 보여주고, 사용자가 믿어도 되는 범위를 분명히 하는 일이었다.