전체 글

들어가며WegglePlus 팀은 블로그 콘텐츠를 통한 검색 유입 확대와 서비스 성장을 목표로 새로운 마케팅 프로젝트를 시작했습니다. 이 프로젝트의 핵심은 **SEO(검색엔진 최적화)**를 통해 안정적인 트래픽을 확보하고, 이를 WegglePlus 서비스 유입으로 연결하는 것입니다.오늘은 SEO의 기본 중 기본, Sitemap과 Robots.txt 구현 과정을 공유합니다.Sitemap과 Robots.txt가 왜 중요할까?Sitemap.xmlSitemap은 웹사이트의 페이지 목록을 검색엔진에 알려주는 XML 파일입니다. 검색엔진 크롤러가 사이트 구조를 빠르게 파악하고, 새로운 콘텐츠를 효율적으로 색인할 수 있도록 도와줍니다. 2026-01-10 weekly 0.8Robots.txtRobots.txt..

문제 상황프로덕션 환경에서 특정 API의 메모리 사용량이 비정상적으로 높다는 알림을 받았습니다. 요청이 들어올 때마다 메모리가 계속 증가하고, GC(Garbage Collection)가 제대로 동작하지 않는 것처럼 보였습니다.1단계: 메모리 프로파일링 미들웨어 구현먼저 문제를 정량적으로 측정하기 위해 메모리 프로파일링 미들웨어를 구현했습니다.# app/core/memory_profiler.pyimport gcimport tracemallocfrom collections.abc import Callableimport psutilfrom starlette.middleware.base import BaseHTTPMiddlewarefrom starlette.requests import Requestfrom st..

들어가며블로그를 운영하다 보면 RSS 피드는 필수 기능 중 하나입니다. Feedly, Inoreader 같은 RSS 리더를 통해 구독자들이 새 글을 쉽게 받아볼 수 있기 때문이죠. 이번 글에서는 Spring Boot와 Kotlin 환경에서 다국어(한국어/영어)를 지원하는 RSS 2.0 피드를 구현한 경험을 공유합니다.기술 스택Spring Boot 3.5.6Kotlin 1.9.25Rome 2.1.0 (RSS/Atom 피드 라이브러리)Rome 라이브러리 선택 이유RSS 피드를 구현하는 방법은 여러 가지가 있습니다:방법 장점 단점직접 XML 생성의존성 없음유지보수 어려움, 버그 가능성Rome 라이브러리검증된 라이브러리, Spring 통합 용이추가 의존성JAXBJava 표준설정 복잡Rome은 RSS/Atom 피..

웹과 앱을 모두 고려한 현실적인 인증 전략 (fetch 기반 구현)로그인 이후 토큰을 어디에 저장할 것인가는 단순한 구현 문제가 아닙니다.이 선택은 보안 모델, 사용자 경험(UX), 그리고 웹과 앱을 함께 운영할 수 있는지 여부까지 결정합니다.이번 글에서는 우리가 최종적으로 선택한 인증 구조인 Refresh Token은 HttpOnly 쿠키, Access Token은 메모리 라는 전략을, 프론트엔드(fetch 기반) 구현과 앱(WebView) 대응 관점까지 포함해 정리합니다.1. 왜 다시 토큰 저장 전략을 고민했을까?전통적으로 많이 사용되던 방식은 다음과 같습니다.Access Token → 쿠키Refresh Token → 쿠키구현은 간단하지만, 실무에서는 다음과 같은 문제가 반복해서 드러났습니다.Acce..

운영 중인 서비스에서 특정 조회 API가 간헐적으로 실패하며 다음과 같은 MySQL 에러가 발생했습니다.Out of sort memory, consider increasing server sort buffer size처음에는 단순한 쿼리 성능 이슈로 보였지만, 실제 원인은 MySQL의 정렬(filesort) 과정에서 발생한 메모리 부족(OOSM) 이었습니다.이번 글에서는 OOSM이 무엇인지, 왜 발생하는지, 그리고 우리가 실제로 어떻게 해결했는지를 공유합니다.OOSM이란 무엇인가?OOSM(Out Of Sort Memory) 은 MySQL이 ORDER BY, GROUP BY 등을 처리하는 과정에서 정렬을 위한 메모리(sort buffer)가 부족할 때 발생하는 에러입니다.MySQL은 다음 두 가지 방식으로..

서론우리 팀은 여러 서비스를 하나의 백엔드 서버와 하나의 DB에서 모두 관리하고 있습니다.그러다보니 Category 모델의 개념의 분류화, 유형화 등을 쓸일이 많습니다.이제 그부분을 두가지 방법으로 관리할수 있을것입니다.단순 String 컬럼을 추가한다.각각의 모델에 따라 Cateogry 모델을 만들어서 관리한다.이러다보니, 현재 팀의 모토인 빠르게 서비스를 개발하고 사용자에게 가치를 주는 일을 주기 위해서 개발의 시간이 많이 드는것을 느꼈습니다.따라서 이번에 시간이 조금 들여도 공통 모델을 만들어서 관리할수 있도록 하는것을 목표로 하였습니다.해결하고자 하는 방안Category의 개념이 필요할때마다 Cateogry를 의미하는 모델을 새롭게 추가할 필요가 없어야 한다.서비스와 타입에 따라 카테고리가 관리되..

a.b.c 조전까지만 해도 무심코 쓰던 코드입니다. A모델에 B가 있으니, 체인으로 c를 꺼내 쓰는 게 자연스럽게 느껴졌죠. 하지만 이 패턴은 Law of Demeter—최소 지식 원칙—을 정면으로 위배합니다. “내 옆집 문을 열어달라고 내 친구에게 부탁하지 말라”는 말처럼, 객체는 자신과 직접 관련된 이웃에게만 말을 걸어야 합니다. 그렇지 않으면 내부 구조가 외부에 노출돼 결합도가 치솟고, 작은 구조 변경이 연쇄 폭발로 이어집니다.이번 글에서는 운영 중인 rails 프로젝트를 예시로, Law of Demeter를 Rails에서 어떻게 지키고 있는지, delegate를 활용하면 어떤 장단점까지 정리해 봅니다.1. 문제는 어디서 시작됐나?A는 B과 1:1 관계를 맺고 있습니다. 외부에서 B의 c를 알고 싶..

Locale 공통화는 다국어 서비스를 운영할 때 필수적인 인프라로, 모든 API가 동일한 언어 판별 규칙을 따르도록 일원화한 작업입니다. 이를 통해 코드 중복을 줄이고 서비스 전반의 언어 일관성을 확보했습니다.왜 Locale이 필요한가?저희 서비스는 다국어(한국어, 영어) 를 지원합니다.동적 데이터는 하나의 DB 컬럼을 JSON 형태로 관리하고 있습니다.예를 들어 블로그 글이 있다고 해봅시다.글의 제목은 한국어와 영어를 모두 지원해야 하므로 모델은 이렇게 정의됩니다.class Post { title: {ko: "Spring Locale 공통화 여정", en: "The Journey to Unify Locale Management in Spring" }}이제 이 데이터를 가지고 DTO에서 lang을 받아..

들어가며최근 JupyterHub와 내부 시스템 간의 API 호출 과정에서 Timeout 설정값을 어떻게 잡는 게 적절할지 논의가 있었습니다. 단순히 “적당히 5초쯤?”으로 정하기보단, 실제 데이터 기반으로 최적값을 찾아보자는 접근을 해보았습니다.이 글에서는Timeout 값을 결정할 때 어떤 기준이 필요한지AWS Athena를 활용해 API 응답 시간을 분석하는 과정최종적으로 도출된 Timeout 설정값을 공유합니다.1️⃣ 문제 인식: “Timeout을 몇 초로 해야 할까?”해당 API는 주로 두 가지 요청을 처리합니다.토큰 발급유저 생성요청 자체는 많지 않지만, 호출 시점마다 응답이 지연될 때 전체 시스템에 영향을 줄 수 있습니다.특히 너무 긴 Timeout은 스레드 점유 시간 증가 → 전체 처리량 감소..

저희는 Figma Makers를 활용해 신규 서비스의 MVP, 그리고 신규 기능의 MVP를 제작하고 있습니다.최근 Figma Makers에 Library Import 기능이 추가되면서, 여러 개의 서비스를 빠르게 만들어 나가거나 기존 서비스를 고도화할 때 AI를 활용하더라도 결국 디자인 컨벤션이 정립되어 있어야 효율적으로 개발할 수 있다는 점을 다시금 깨닫게 되었습니다.결국 서비스는 계속 만들어질 것이고, 그 서비스들이 각기 다른 프로젝트가 아니라 하나의 WegglePlus라는 큰 서비스로 연결되기를 기대하기 때문에, 작은 단위라도 하나씩 제대로 만들어가야겠다는 생각이 들었습니다.저희는 Figma Makers를 활용해 신규 서비스의 MVP, 그리고 신규 기능의 MVP를 제작하고 있습니다.최근 Figma ..