위젯은 앱의 축소판이 아니었다

한강자리는 처음부터 위젯을 중요하게 생각했다. 그래도 만들기 전에는 위젯을 앱 옆에 붙는 부가 기능 정도로 봤다.

앱을 열면 자세히 보고, 위젯에서는 간단히 보는 정도. 좋아하는 공원을 하나 골라두면 홈 화면에서 빠르게 확인하는 정도로 생각했다.

직접 쓰기 시작하자 생각이 바뀌었다.

앱을 열기 전에도 이미 사용은 시작되고 있었다. 홈 화면을 지나가다 숫자를 보고, 잠금화면에서 상태를 보고, 차 키를 들기 전에 다시 한 번 확인한다. 그 순간에 위젯이 애매하면 사용자는 앱을 열기보다 다른 방법을 찾는다.

한강에 갈지 말지는 앱을 연 뒤에 정해지지 않았다. 집에서 나가기 전, 차 키를 들기 전, 엘리베이터를 기다릴 때, 잠금화면이나 홈 화면을 스치듯 보는 순간에 이미 한쪽으로 기울기 시작했다.

그때 필요한 정보는 많지 않았다.

오늘 이 공원이 괜찮은지. 차를 가져가도 될지. 지금 주차장이 버틸 만한지. 행사나 혼잡 신호가 있는지. 정보가 오래된 건 아닌지.

앱 안에서는 많은 정보를 보여줄 수 있다. 하지만 출발 전에 보는 순간에는 한눈에 결정을 도와야 한다. 그래서 위젯은 작은 앱 화면이 아니라, 앱 밖에서 먼저 확인하는 화면이어야 했다.

위젯은 늘 최신 화면이 아니다

위젯을 진지하게 보면서 가장 먼저 인정해야 했던 것은, 위젯이 언제나 실시간 화면은 아니라는 점이었다. iOS 위젯은 시스템 정책 안에서 갱신된다. 앱이 원하는 순간마다 마음대로 새로 그릴 수 있는 화면이 아니다.

그래서 위젯을 “지금 서버 값을 그대로 보여주는 실시간 현황판”처럼 생각하면 설계가 흔들린다. 위젯은 마지막으로 확인된 snapshot을 바탕으로 빠르게 판단하게 돕고, 오래된 값이면 오래됐다고 말하고, 더 확인하고 싶을 때 앱으로 자연스럽게 이어져야 했다.

이 전제를 받아들이니 화면 안내도 달라졌다. “실시간”이라는 말을 쉽게 쓰지 않게 됐고, 갱신 시각을 더 중요하게 봤다. 위젯이 신뢰를 얻으려면 항상 최신인 척하기보다, 지금 보여주는 값이 언제 확인된 것인지 숨기지 않아야 했다.

위젯에는 한눈에 볼 값만 남겼다

위젯을 만들면서 가장 많이 한 일은 정보를 추가하는 게 아니라 빼는 일이었다.

일반 모드 위젯에는 혼잡도, 날씨, 미세먼지, 행사 신호처럼 “오늘 이 공원에 가도 될까”에 답하는 정보만 남겼다. 주차 위젯에는 추천 주차장, 잔여 대수, 상태, 갱신 시각처럼 “차를 가져가도 될까”에 가까운 정보만 남겼다.

앱 화면이라면 시설 목록, 공지, 상세 주소, 길찾기, 예측 변화까지 더 보여줄 수 있다. 위젯에서는 그렇게 하면 오히려 결정을 늦춘다.

그래서 위젯의 질문을 먼저 정했다.

• 일반 모드 위젯: 오늘 이 한강공원은 갈 만한가?
• 차량 모드 위젯: 지금 차를 가져가도 되는가?

이 질문이 정해지니 화면도 달라졌다. 큰 숫자, 짧은 상태, 갱신 시각, 최소한의 보조 신호만 남겼다. 근처 시설이나 상세 길찾기처럼 더 알아볼 것은 위젯에 넣지 않고, 사용자가 더 알고 싶을 때 해당 공원과 모드로 바로 들어가게 했다.

위젯을 잘 만들었는지 보는 기준도 앱 화면과 달랐다.

기준	앱 화면	위젯
정보량	비교와 상세 확인을 위해 넓게 보여준다.	한 번 보는 순간 필요한 값만 남긴다.
갱신 표현	섹션별 출처와 상태를 자세히 보여줄 수 있다.	갱신 시각과 오래된 상태를 짧게 보여준다.
행동	상세 탐색, 길찾기, 설정 변경으로 이어진다.	보고 나서 앱으로 들어가거나 그대로 닫힌다.
좋은 결과	필요한 정보를 찾는다.	앱을 열지 않고도 결정이 빨라진다.

그래서 위젯이 앱 사용 시간을 늘리지 않아도 괜찮다고 봤다. 오히려 출발 전 확인 시간이 줄었다면 위젯은 자기 역할을 한 셈이다.

이렇게 보니 위젯을 평가하는 방법도 바뀌었다. “앱으로 얼마나 많이 들어오게 했나”보다 “앱을 열지 않아도 결정할 수 있었나”가 더 중요해졌다. 출발 전에 한 번 보고 바로 움직였다면, 앱을 열지 않았더라도 괜찮았다.

작은 화면에서 덜어낸 정보

위젯을 만들 때 넣고 싶었지만 뺀 것들이 많았다. 공원 설명, 긴 공지, 시설 목록, 여러 개의 행사, 자세한 예측 그래프 같은 것들이다. 앱 화면에서는 의미가 있지만 위젯에서는 결정을 늦춘다.

특히 주차 위젯에서는 “가장 중요한 후보를 보여주는 것”과 “모든 후보를 공평하게 보여주는 것” 사이에서 고민했다. 모든 주차장을 작게 나열하면 정보량은 많아진다.

하지만 사용자는 출발 직전에 어느 주차장으로 갈지 알고 싶다. 그래서 위젯에서는 추천 후보와 상태를 더 앞에 두고, 상세 비교는 앱으로 넘기는 편이 나았다.

일반 모드 위젯도 비슷했다. 날씨, 혼잡도, 행사, 미세먼지, 공지까지 모두 중요해 보인다. 하지만 한 화면에서 모두 같은 비중으로 보이면 아무것도 눈에 남지 않는다. 시설 목록처럼 현장에서 찾을 정보는 앱 화면으로 넘기고, 위젯에는 “오늘 이 공원이 괜찮은가”라는 질문에 답하는 값만 남겨야 했다.

위젯에서도 오래된 숫자는 오래됐다고 말했다

위젯은 편하지만 위험한 화면이기도 하다. 사용자는 위젯을 오래 읽지 않는다. 그래서 잘못된 값을 크게 보여주면 앱 화면보다 더 쉽게 오해가 생긴다.

한강자리 위젯에는 갱신 시각과 오래된 값 표시가 중요했다. 위젯은 항상 즉시 최신 값을 보장하는 화면이 아니다. 시스템이 정한 갱신 주기가 있고, 네트워크가 실패할 수도 있고, 마지막으로 저장된 snapshot을 먼저 보여줘야 할 때도 있다.

그래서 위젯을 “실시간 현황판”처럼 만들고 싶지 않았다.

대신 마지막으로 확인한 값을 빠르게 보여주고, 오래됐으면 오래됐다고 말하고, 필요하면 앱으로 이어져 다시 확인하게 하는 화면으로 설계했다.

이 결정은 구현에도 영향을 줬다. 앱과 위젯은 같은 데이터를 각자 다르게 읽는다. 앱은 스크롤하고 비교하고 상세로 들어가는 화면이고, 위젯은 마지막 snapshot을 바탕으로 한 번에 확인하는 화면이다.

그래서 App Group을 통해 위젯용 snapshot을 따로 저장하고, 위젯에서 들어올 때는 선택한 공원과 모드로 자연스럽게 연결되게 했다.

위젯은 앱의 축소판이 아니라, 사용자가 움직이기 전에 먼저 보는 화면이다.

이 기준을 붙잡고 나니 많은 결정이 쉬워졌다. 위젯은 앱보다 작아서 덜 중요한 것이 아니었다. 사용자의 더 빠른 순간을 맡기 때문에 더 조심스럽게 만들어야 했다.

위젯을 먼저 생각하니 앱도 단순해졌다

위젯을 중심에 두니 앱의 역할도 더 분명해졌다.

위젯은 빠른 확인. 앱은 비교와 상세. 알림은 사용자가 정한 조건의 변화. 길찾기는 실제 이동으로 넘어가는 마지막 단계.

이렇게 나누면 각 접점이 서로 경쟁하지 않는다. 위젯에서 모든 것을 끝내려 하지 않고, 앱에서도 첫 화면에 모든 것을 밀어 넣지 않게 된다.

위젯만 보고 끝나도 괜찮아야 했다

처음에는 앱을 더 많이 열게 만드는 것이 좋은 제품이라고 생각하기 쉽다. 하지만 한강자리에서는 반대에 가까웠다. 위젯만 보고 “오늘은 여의도 말고 반포로 가자”거나 “지금은 차를 두고 가자”라고 판단할 수 있다면, 앱을 열지 않아도 성공이다.

물론 상세 확인이 필요한 순간은 있다. 주차장 위치를 비교하거나, 행사 정보를 보거나, 길찾기를 열 때는 앱이 필요하다. 하지만 매번 앱을 열어야만 판단할 수 있다면 위젯을 만든 의미가 줄어든다.

한강자리가 위젯을 중요하게 본 이유도 여기에 있다. 위젯에서는 앱 사용 시간을 늘리는 것이 목표가 아니라, 한강에 가기 전의 불필요한 확인 시간을 줄이는 것이 목표였다. 사용자가 덜 헤매고 더 빨리 결정하면, 위젯은 그만큼 제 역할을 한 것이다.

한강자리를 만들며 배운 점은, 모바일 제품의 중심이 꼭 앱 아이콘 안에만 있지는 않다는 것이다. 사용자의 생활에서는 홈 화면, 잠금화면, 알림, 지도 앱 이동까지 모두 앱을 만나는 순간이다.

위젯을 보는 순간에는 더 그렇다. 사용자는 한강자리를 오래 탐색하고 싶은 게 아니라, 지금 나가도 되는지 빨리 판단하고 싶다.

그래서 한강자리의 위젯은 부가 기능이 아니라 제품의 중심에 가까웠다. 앱을 열기 전 확인이 좋아지면, 앱을 여는 순간도 더 자연스러워졌다.

돌아보면 위젯을 진지하게 본 덕분에 한강자리의 성격도 분명해졌다. 오래 머무르게 만드는 화면이 아니라, 나가기 전의 망설임을 줄이는 화면이었다. 위젯은 그 성격을 가장 먼저 드러내는 접점이었다.