행복한 시지프 - 서버

들어가며팀 내에 분업을 하다보면, 데이터가 잘 공유되는 것이 중요합니다. 유저는 몇명인지, 하루에 몇명이 사용하는지, 우리가 세운 가설이 동작하고 있는지 등이요. 하지만, DB 는 보통 개발자의 몫이고, 실제로 확인하고 설계하는 것은 PM/PD 의 역할입니다. 매번 주요 데이터를 조회해서 전달을 해주기가 어렵고, 좋은 협업이 아닙니다. 팀 내 누구나 데이터에 접근 가능하게 하는 구조가 필요합니다. 그것이 바로 대시보드가 필요한 이유입니다. 오늘은 DB 를Grafana 대시보드로 표현하는 과정을 써봅니다.0. 원리 시각화먼저 전체 원리를 그려봅니다. 일반적인 애플리케이션의 흐름과 Grafana 시각화 흐름이 동일하다는 것에 주목했습니다.DB 가 있고, DB 를 직접 요청하는 WAS 가 있고, WAS 에 A..

들어가며디톡스메이트 서비스는 서버 에러를 Grafana에서 확인하고, Grafana Alert를 통해 Discord로 알림을 받고 있습니다. 그런데 며칠 동안 에러 알림이 오지 않았습니다. 이상해서 Grafana를 확인해보니, prod 백엔드 로그가 더 이상 쌓이지 않고 있었습니다. 처음에는 "백엔드 로그가 안 찍히나?"라고 생각했지만, 실제 원인은 백엔드 코드가 아니라 로그 수집 파이프라인과 디스크 용량 문제였습니다.이 글은 Grafana에 로그가 보이지 않는 상황에서 어디부터 확인했고, 어떤 단서로 원인을 좁혀갔는지 정리한 디버깅 기록입니다.로그가 Discord까지 도달하는 흐름먼저 현재 서비스에서 로그가 어떻게 생성되고, Grafana와 Discord까지 도달하는지 큰 그림을 봅니다. Grafan..

들어가며백엔드 서비스 개발을 하다보면, 테이블 스키마를 변경해야 하는 일이 발생합니다. Column 을 추가하거나, PK 를 바꾸거나, 인덱스를 추가하는 등이요. 그냥 ALTER TABLE … ADD COLUMN 으로 추가하면 될까요? 데이터베이스 수업 시간에 스키마 변경은 비싼 비용, O(n) 연산이라고 공부했습니다. 이제 과연 맞을지, 어떻게 Column 을 추가해야 할지 학습하고 적용해봅니다.DDL 알고리즘 (Native DDL)테이블이 짠 하고 변경된다고 생각하기 쉽지만, 다양한 방법이 있습니다.Metadata-Only Operation (MySQL 기준, ALGORITHM=INSTANT)Full Table Rewrite (MySQL 기준, ALGORITHM=COPY)In-Place Rewrite..

들어가며블로그 성향 분석 서비스를 만들고 싶습니다. 하나의 항목이, “아침형 vs 밤형” 입니다. 글을 주로 언제 쓰느냐에 따라서 결정합니다. RSS 의 pubDate 를 파싱해서 계산합니다. 이때 버그가 있었습니다. test CI 를 등록하고나서, 이 테스트가 통과하지 않았습니다. 분명 Local 에서는 모든 테스트가 동작했는데, 왜 CI 에서는 통과하지 않을 걸까요? 에러 로그를 보니, 테스트 코드 결과에서 hour 가 예상과 달랐던 것입니다. 원인을 분석해보니 Time Zone 문제라는 것을 깨달았고, Node.js 환경에서 어떻게 Time Zone 을 다루어야 하는지 학습하고 적용해보았습니다. [ {- "hour": 21,+ "hour": 12, "minute": 4..

들어가며사이드 프로젝트로 블로그 분석 서비스를 만들고 있습니다. 서비스를 운영한지 일주일 정도 되었습니다. 서비스를 운영하다보니, 기능을 새로 추가하고, 수정해야 할 일이 많이 생깁니다. 이때 어떻게 안정적으로 기능을 추가하고, 리팩터링 할 수 있을까요? 프론트엔드에서는 리팩터링 후 UI 와 기능이 정상 동작하는지 확인하기가 간편했고 명확했습니다. 백엔드는 더 다양한 케이스를 다룰 뿐더러, 하나씩 API 를 호출해보는 과정은 좀 더 까다로웠습니다. 또는 API 에는 다른 많은 로직이 섞여있으므로, API 를 통해 하나의 기능을 테스트하기가 번거롭습니다. 어떻게 리팩터링을 잘 할 수 있을까 고민하다가, 회귀 방지(Regression Protection)가 핵심이라는 생각이 들었습니다. 회귀 방지를 할 수 ..

들어가며서버 개발을 하면서, Layered Architecture 가 자주 쓰입니다. Spring, NestJS 가 기본적으로 강제하고 있는 방식입니다. 이 아키텍쳐를 그대로 따르는 것이 팀 개발에서 중요하겠지만, 그 전에 이것이 왜 태동했는지 이해해야 합니다. 그것을 이해하지 않으면, 형태만 똑같을 뿐, 본질적인 가치를 훼손할 수 있습니다. 그래서 이번에 Layered Architecture 가 왜 생겼는지, 본질적인 철학은 무엇인지 이해해보려고 합니다. 그리고 그것을 기반으로 NestJS 를 이해해 볼 것입니다. Layered Architecture 이전Layered Architecture 가 없는 시절, 또는 지금 express 로 개발을 한다면 무슨 일이 벌어졌을까요? 1. 관심사의 분리가 되지 ..

들어가며블로그 분석 서비스를 배포했습니다. 베타 테스트로 커뮤니티에 홍보했습니다. 반응이 괜찮았습니다. 광고를 추가하고, 정식 배포를 하려고 하는데요. 한가지 크리티컬한 문제가 있었습니다. Gemini API 를 호출하는데, 평균 응답이 25초 가량 걸린다는 것입니다. 이대로면 이탈률이 매우 높을 것으로 예상되었습니다. 커뮤니티 내에서는 친절한 사용자분들이기 때문에, 시간을 기다려줬겠지만, 시장의 반응은 혹독할 것 같았습니다. 그래서 정식 배포 전에, 성능 문제를 해소하고자 했습니다. 성능 분석부터, 병목 지점 확인, 해결책 도출, 테스트, 개선 과정을 이번 글에서 다룹니다. 성능 측정먼저 성능을 측정합니다.서버의 API 성능을 먼저 살펴볼게요. Cloudflare Workers 에서 성능 모니터링 도..

들어가며저는 AI 블로그 분석기 서비스를 만들고 있습니다. Cloudflare Workers 로 API 를 서빙하고 있습니다. LLM API 는 gemini-2.5-flash-light 로 저렴하지만, 강력한 모델을 쓰고 있습니다. 오늘 서비스를 배포하고 바로 에러가 잡히기 시작하여, 분석해보았습니다. 에러 분석 : User location is not supported for the API use배포 후, 얼마 지나지 않아 Sentry 에 이런 로그가 잡혔습니다. 상세 로그를 보시죠{ "code": 400, "message": "User location is not supported for the API use.", "status": "FAILED_PRECONDITION"} google..