Backend5 [Backend] 무료 서핑 예보 API, 뭘 쓰고 뭘 버렸나 — 카드 없이 파도 데이터 소싱하기 서핑 예보 앱을 만들면서 가장 먼저 부딪힌 질문은 "파도 데이터를 어디서 가져오나"였습니다. 유료 상용 API는 개인 개발자에겐 부담이 크고, 무료 API는 종류가 많은데 품질이 천차만별입니다. 이 글에서는 무료 예보 API들을 실제로 비교해 무엇을 메인으로 쓰고 무엇을 버렸는지, 그리고 "무료인데 절대 쓰면 안 되는 API"까지 정리합니다. 신용카드 없이 파도·기상 데이터를 소싱하려는 분께 참고가 될 만합니다.무료 API가 많다고 다 쓸 수 있는 건 아니다파도 예보에 필요한 데이터는 파고, 파주기, 스웰(높이·주기·방향), 풍속, 풍향 정도입니다. 이걸 무료로 주는 API를 찾아보면 의외로 여러 개가 나옵니다. 그런데 하나씩 뜯어보면 "무료"의 조건이 제각각이라, 실제로 프로덕션에 쓸 수 있는 건 몇 .. 2026. 7. 2. [Backend] 깎기와 풀기를 한 곳에 — 양방향 보정의 균형 (통합편) 이 글은 서핑 점수 엔진을 양방향으로 보정한 결과를 종합하는 글입니다. 위험한 날의 점수를 깎는 보정(거짓양성)과 탈 만한 날을 풀어주는 보정(거짓음성), 이 반대 방향의 두 작업을 한 파이프라인에 함께 넣었을 때 어떤 균형이 생기는지, 그리고 둘이 충돌 없이 공존하는지를 정리합니다. 규칙 기반 시스템을 양방향으로 튜닝하면서 "한쪽을 고치면 반대쪽이 망가지는" 문제를 겪어본 분께 참고가 될 만합니다.이 글은 거짓양성 시리즈(3편)와 거짓음성 시리즈(3편)를 잇는 통합편입니다. 앞 글들을 안 읽었어도 이 글만으로 큰 그림은 잡히도록 정리했습니다.한쪽만 고치면 반대쪽이 망가진다서핑 점수 엔진을 다듬으면서 가장 오래 붙들고 있던 깨달음이 있습니다. 점수의 오류는 한 방향이 아니라는 것입니다.처음에는 "위험한 .. 2026. 6. 30. [Backend] 풀어주다 위험을 놓칠 뻔한 순간들 — 거짓음성 보정의 함정과 검증 (거짓음성 3편) 이 글은 과소평가를 푸는 보정을 만들면서 실제로 밟은 함정들과, "풀어주되 위험한 날은 막는다"가 정말 지켜지는지를 어떻게 검증했는지 다루는 거짓음성 시리즈의 3편(완결)입니다. 설계가 아무리 좋아도 그 의도가 코드에서 진짜 지켜지는지는 검증으로만 확인됩니다. 안전이 걸린 시스템에서 "완화"라는 위험한 작업을 어떻게 안전하게 가두는지가 궁금한 분께 도움이 될 만합니다.이 글은 거짓음성 시리즈의 3편(완결)입니다. 1편에서 과소평가의 세 모습을, 2편에서 보정 설계를 다뤘습니다. 이번 편은 그 보정이 위험을 놓치지 않는지 검증하는 이야기입니다.풀어주는 보정은 왜 위험한가거짓음성 보정은 본질적으로 "기존의 엄격함을 푸는" 작업입니다. 점수를 올려주고, 페널티를 빼주고, 차단을 완화합니다. 그런데 안전을 다루.. 2026. 6. 29. [Backend] 절벽을 비탈로 — 과소평가를 푸는 보정 설계 (거짓음성 2편) 이 글은 서핑 적합도 점수가 탈 만한 날을 과소평가하던 문제(거짓음성)를 어떻게 보정했는지, 그 설계 결정을 다루는 시리즈의 2편입니다. 1편에서 정의한 세 가지 과소평가를 풀되, "위험한 날까지 풀어버리지 않는" 안전을 동시에 지키는 게 핵심이었습니다. 규칙 기반 점수 시스템에서 경계를 부드럽게 다듬는 방법이 궁금한 분께 참고가 될 만합니다.이 글은 거짓음성 시리즈의 2편입니다. 1편에서 "어떤 날들이 과소평가됐나"를 다뤘고, 이번 편은 "그걸 어떻게 풀었나"입니다. 다음 편에서는 보정을 만들며 밟은 함정과 검증을 이야기합니다.설계의 큰 원칙 — 엔진은 건드리지 않는다거짓양성을 보정할 때 세운 원칙이 하나 있었습니다. 기존 점수 엔진의 핵심 계산은 건드리지 않고, 그 앞뒤에 보정 단계를 덧붙이는 것입니.. 2026. 6. 28. [Backend] NestJS와 PostgreSQL로 구축하는 고성능 예보 수집 엔진 (병렬 처리와 Upsert) 모바일 서비스를 기획할 때 기획자나 개발자가 가장 먼저 마주하는 질문은 “어떤 기능을 우선순위에 둘 것인가”입니다. 제가 진행 중인 서핑 앱 Whale-Log 프로젝트에서 내린 결론은 ‘예보 시스템의 완결성’이었습니다.이는 새로운 기능을 많이 만드는 것보다, 이미 다른 앱에도 공통으로 존재하는 가장 기본적이면서도 핵심적인 기능을 먼저 제대로 구현하는 것이 서비스의 신뢰도를 좌우모바일 서비스를 기획할 때 기획자나 개발자가 가장 먼저 마주하는 질문은 "어떤 기능을 우선순위에 둘 것인가"입니다. 제가 진행 중인 서핑 앱 Whale-Log 프로젝트에서 내린 결론은 ‘예보 시스템의 완결성’이었습니다.이는 새로운 기능을 많이 만드는 것보다, 이미 다른 서핑 앱에도 공통으로 존재하는 가장 기본적이면서도 핵심적인 기능.. 2026. 2. 8. 이전 1 다음
