기상청 화면과 같은 자리에, 더 선명하게, “언제 비 오는지” 바로 보이게

숫자 대신, 할 일로

색 4단계 = 기상청 공식 강도 구간. 같은 색이 누구에게는 우산, 누구에게는 감속이에요. 열을 누르면 왼쪽 폰이 그 비로 바뀌어요.

핀

핀 = 그 장소의 지금 하늘. 비가 셀수록 빗줄기가 많고 빨라지고, 50mm부터는 물이 차올라요. (mm/h)

이렇게 써요

⚾ 기준은 KBO 공식 수치가 없어서 추정(카드에도 표시). 우천 결정은 경기 약 3시간 전 경기운영위원, 경기 중엔 심판 · 중단 후 약 30분 대기 · 5회 넘기면 정식경기 · 고척돔은 영향 없음. 바람 입자는 시안용 공개 모델 자료이고, 앱에서는 기상청 초단기 바람으로 바꿔요.

한 화면에서 답이 나오게

이 화면을 여는 사람의 질문은 대부분 하나예요: “내가 갈 곳에 언제 비 와? 우산 필요해?” 지금은 지도를 재생하면서 눈으로 추측해야 해요. 바뀐 화면은 핀·문장·막대로 그 답을 먼저 보여주고, 지도는 확인용으로 둡니다. 각 카드의 버튼을 누르면 왼쪽 폰에서 바로 보여줘요.

내 장소 기능, 어떻게 해야 정말 편할까

새로 들어가는 세 가지(장소 저장 · 여러 곳 한눈에 · 핀 위 비 정보)는 “손이 덜 가는 것”이 전부예요. 이미 잘하는 서비스들이 푼 방식을 기준으로 정했어요.

왼쪽 폰에서 지도를 아무 데나 누르고 “☆ 내 장소에 추가”를 눌러보세요. Mobbin이 연결되면 이 세 화면을 실제 앱 화면들과 나란히 놓고 한 번 더 다듬을게요.

현재 디자인에서 바꾼 것과 이유

비 알림(D1·D2), 경로(C3)는 이번 범위에서 빠져 있어요.

기존 강수 위치 어긋남, 해결되나요?

숫자로 보면

폰의 비교 모드는 같은 기상청 원본을 두 방식으로 옮긴 결과예요. 왼쪽이 기존 서버, 오른쪽이 바뀐 서버이고, 해안선을 기준으로 보면 차이가 보여요. 기존 방식은 색을 섞어 늘린 것처럼 번지게 그려서 앱의 현재 모습도 함께 재현했어요.

2분마다 한 번, 새 자료가 있을 때만 일해요

기상청 관측은 5분마다(발표까지 2–9분), 예측은 10분마다(발표까지 16–25분) 나와요. 서버는 2분마다 “새 게 나왔나”만 확인하고, 새 자료가 있으면 그것만 받아서 처리합니다.

하루 호출량 (API허브 한도 2만 회)

한도의 약 35%. 재시도·장애 여유를 둬도 충분해요.

처리 시간

현재는 한 장씩 차례로 받음 → 병렬로 받으면 대부분이 기상청 응답 대기 시간이라 크게 줄어요. 이 목업을 만들 때 48장을 8개씩 병렬로 받은 실제 결과와 같은 방식이에요.

기상청이 늦거나 멈추면

새 자료가 없으면 manifest를 건드리지 않아요. 앱은 manifest의 시각을 보고 “기상청 11:50 · 6분 전 갱신”처럼 있는 그대로 보여주고, 30분 이상 멈추면 “기상청 자료가 늦어지고 있어요”로 바뀌어요.

핵심 코드 모양 (TypeScript, Lambda)

export const handler = async () => {
  const last = await readManifest();                      // S3
  const obsTm = await latestObsTime();                    // nph-rdr_cmp_inf
  const fcBase = await latestForecastBase();              // nph-qpf_ana_imgp → dateTime
  if (obsTm === last.obsTm && fcBase === last.fcBase) return; // 대부분 여기서 종료

  const jobs = [];
  if (obsTm !== last.obsTm) jobs.push({ kind: 'obs', tm: obsTm });
  if (fcBase !== last.fcBase)
    for (let ef = 10; ef <= 360; ef += 10) jobs.push({ kind: 'fc', tm: fcBase, ef });

  const frames = await pMap(jobs, async (j) => {
    const png  = await fetchKma(j);                        // 3회 재시도
    const idx  = colorToClass(png, { header: 20 });        // 24색 → 0..24
    const grid = remap980201To3857(idx);                   // 위치 보정
    await putS3(`v2/${key(j)}.png`, encodeGray(grid));     // 새 앱
    await putS3(`v1/${key(j)}.png`, paintKma(grid));       // 기존 앱
    return meta(j);
  }, { concurrency: 10 });

  await putS3('v2/manifest.json', merge(last, frames));   // 항상 마지막
  await writeLegacyDataExtended(frames);                   // 기존 앱 호환
};

교체 순서

웹에서 본 그대로 앱에 나오게

이 폰 화면은 스크린샷을 붙인 게 아니라, 앱에 들어갈 방식 그대로 돌아가요.

셰이더가 하는 일 (색칠 공부 비유)

서버는 “이 칸은 3번 색” 같은 번호만 보내요(색칠 공부 도안). 화면의 점 하나하나가 “나는 어느 칸 사이에 있지?”를 계산해서 주변 4칸의 번호로 경계를 부드럽게 그리고, 번호에 맞는 색을 칠해요. 확대하면 다시 계산하니까 계단이 생기지 않고, 색상표만 바꾸면 전체 색이 즉시 바뀌어요.

Flutter 3.38.5에는 텍스처 필터 옵션이 없어서 위 코드처럼 4칸을 직접 읽어 계산해요. 그래서 웹과 앱이 같은 결과를 냅니다.