Typescript6 [Troubleshooting] "데이터 없음"을 0으로 처리했다가, 위험한 날을 안전하다고 한 버그 이 글은 바람 데이터가 없을 때 그 빈 값을 0으로 처리한 것 때문에, 서핑하기 위험한 날이 "완벽한 컨디션"으로 둔갑한 버그를 추적한 기록입니다. 세 단계의 코드가 각자 멀쩡해 보였는데 겹치면서 안전 판정을 뒤집었고, 그 과정에서 "데이터가 정합적인 것"과 "비즈니스적으로 옳은 것"이 다르다는 걸 배웠습니다. 외부 API 데이터를 다루거나, null 처리를 무심코 ?? 0으로 하는 코드를 가진 분이라면 한 번쯤 점검해볼 만한 이야기입니다.안전을 다루는 앱에서 가장 무서운 버그제가 만드는 앱은 서핑 적합도를 점수로 보여줍니다. 파고, 풍속, 수온 같은 예보 데이터를 모아 "오늘 이 스팟은 8점, 좋음"처럼 알려주는 식입니다. 그런데 이런 앱에는 평범한 버그와는 차원이 다른 위험이 하나 있습니다. 위험한 .. 2026. 6. 26. [Backend] 보정 필터를 만들며 밟은 함정들 (거짓양성 해결 · 수치 검증) 📌 이 글의 핵심 요약 (SEO Summary)핵심 내용: 거짓양성 보정 레이어를 구현하며 마주친 함정 5가지와, 수치로 해결을 확인한 검증 과정주요 포인트: 과잉 보정, 이중 페널티, 범위 오류, 단순합→가중합, 레벨별 차등, 회귀 테스트기대 효과: "고치려다 새 버그를 만드는" 함정을 피하고, 보정 로직을 안전하게 검증하는 법 익히기적용 시점: 점수·판정 로직에 보정/예외 규칙을 추가하고, 그게 정말 맞는지 확인해야 할 때※ 아래 점수·임계값·가중치는 실제 운영 값이 아니라 구조 설명용 예시·상수입니다. 실제 공식은 공개하지 않고 검증 관점 위주로 설명합니다.📚 시리즈 구성이 글은 서핑 예보 점수 엔진의 거짓양성/거짓음성 해결 시리즈의 3편(거짓양성 완결)입니다.[1편: 거짓양성 — 앱이 "안전하.. 2026. 6. 19. [Backend] 서핑 점수 거짓양성, 엔진 수정 없이 고치기 (보정 레이어 설계 전략) 📌 이 글의 핵심 요약 (SEO Summary)핵심 내용: 검증된 점수 엔진을 수정하지 않고, "보정 레이어"를 끼워 거짓양성 2건을 해결한 설계 과정주요 포인트: 고친 방법 3가지 비교, 계단식 vs 연속값, 곱하기 vs 게이트, 엔진 무수정 아키텍처기대 효과: 기존 동작을 깨지 않으면서 판정 로직을 안전하게 보강하는 설계 패턴 습득적용 시점: 이미 테스트로 검증돼 돌아가는 점수·등급 로직에 새 규칙을 추가해야 할 때※ 아래 코드의 임계값·가중치·감점 계수는 실제 운영 값이 아니라 구조 설명용 예시·상수입니다. 실제 공식은 공개하지 않고 설계 관점 위주로 설명합니다.📚 시리즈 구성이 글은 서핑 예보 점수 엔진의 거짓양성/거짓음성 해결 시리즈의 2편입니다.[1편: 거짓양성 — 앱이 "안전하다"고 잘못.. 2026. 6. 18. [Troubleshooting] 앱이 "안전하다"고 잘못 판단한 순간 — 서핑 점수 거짓양성 2건 📌 이 글의 핵심 요약핵심 내용: 서핑 점수 엔진이 "안전(통과)"이라고 안내했지만 실제로는 위험했던 거짓양성 2건과 그 원인 주요 포인트: 항목별 안전 필터의 맹점(복합 위험), 가중 평균의 함정(한 항목이 나머지를 가림) 기대 효과: "빌드도 테스트도 통과하는데 판단만 틀린" 버그를 어떻게 발견하는지 감 잡기 적용 시점: 점수·등급·추천처럼 여러 입력으로 판정을 내리는 로직을 만들거나 검증할 때※ 아래 코드의 임계값(WAVE_LIMIT 등)·가중치·감점 계수는 실제 운영 값이 아니라 구조 설명용 예시입니다. 실제 점수 공식은 공개하지 않고 문제의 구조와 설계 관점 위주로 설명합니다.📚 시리즈 구성이 시리즈는 서핑 예보 점수 엔진에서 발견한 "거짓양성 / 거짓음성" 오류를 정리한 글입니다.1편: 거.. 2026. 6. 18. [Backend] NestJS와 PostgreSQL로 구축하는 고성능 예보 수집 엔진 (병렬 처리와 Upsert) 모바일 서비스를 기획할 때 기획자나 개발자가 가장 먼저 마주하는 질문은 “어떤 기능을 우선순위에 둘 것인가”입니다. 제가 진행 중인 서핑 앱 Whale-Log 프로젝트에서 내린 결론은 ‘예보 시스템의 완결성’이었습니다.이는 새로운 기능을 많이 만드는 것보다, 이미 다른 앱에도 공통으로 존재하는 가장 기본적이면서도 핵심적인 기능을 먼저 제대로 구현하는 것이 서비스의 신뢰도를 좌우모바일 서비스를 기획할 때 기획자나 개발자가 가장 먼저 마주하는 질문은 "어떤 기능을 우선순위에 둘 것인가"입니다. 제가 진행 중인 서핑 앱 Whale-Log 프로젝트에서 내린 결론은 ‘예보 시스템의 완결성’이었습니다.이는 새로운 기능을 많이 만드는 것보다, 이미 다른 서핑 앱에도 공통으로 존재하는 가장 기본적이면서도 핵심적인 기능.. 2026. 2. 8. [Project] Whale-Log: 기술 스택 선정과 생존 전략 안녕하세요, whale-tail입니다. 설계도를 그리고 스켈레톤 코드를 짜다 보니, 어느덧 개발자로서 가장 설레면서도 두려운 '기술 스택 확정'의 순간이 왔습니다. 오늘은 제가 왜 이 도구들을 선택했는지, 그리고 1인 개발자로서 마주한 '현실적인 선택과 집중'에 대해 솔직하게 적어보려 합니다. .🛠 1. Whale-Log를 지탱할 기술들: 왜 이 조합인가?Frontend: React Native + TypeScript이유: 저는 웹 개발자입니다. React의 컴포넌트 기반 사고방식은 저에게 가장 강력한 무기입니다. Flutter라는 매력적인 대안도 있었지만, 러닝 커브를 최소화하고 비즈니스 로직에 집중하기 위해 RN을 선택했습니다.기술적 고찰: 특히 웹에서 사용하던 Business Logic이나 API.. 2026. 2. 6. 이전 1 다음
