서론우리 팀은 여러 서비스를 하나의 백엔드 서버와 하나의 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 ..
현재 WegglePlus의 모든 서비스는 제가 혼자 개발하고 있습니다.혼자 개발을 하다 보면 놓치는 부분이 정말 많습니다.특히 코드의 일관성을 유지하는 일은 생각보다 쉽지 않습니다.내가 작성한 코드에 대해 누군가 코드 리뷰를 해주는 것도 아니고, 내가 수십 번 검토하더라도 어느 순간 익숙해져서 무엇이 잘못된 부분인지 눈에 잘 들어오지 않게 됩니다.그러다 며칠이 지나 다시 보면, 그제서야 놓쳤던 컨벤션이 보이곤 하죠.그래서 아주 기본적인 컨벤션이라도 자동으로 지킬 수 있도록, 프론트엔드 프로젝트에 Prettier를 설정하기로 했습니다.🪄 Prettier란?Prettier는 코드를 자동으로 일관된 형식으로 정리해주는 코드 포매터(Code Formatter) 입니다.즉, 코드의 동작에는 영향을 주지 않지만,..
첫번째 데이터 수집기인 GA 다음에 다른 데이터 수집기인 Clarity를 설정합니다.GA는 방문자에 대한 정보(방문지역, DAU 등)이라면 Clarity는 방문자가 우리 서비스에 들어와서 어떤 행동을 하는지를 알수 있습니다. 어떤 버튼을 주로 클릭하는지, 스크롤을 얼마나 내리는지. 를 알수 있습니다.UI/UX에 대한 지식이 미흡한 관계로 MVP 이후에 계속해서 사용자 반응을 보고 개선해나가기 위해서는 이러한 데이터가 필요하다고 판단하였습니다. 따라서 일단 설정하고 데이터를 수집하는것을 목표로 하였습니다.아울러 모두 무료이기 때문에 최대한 빠르게 적용하여 데이터를 수집하는것이 중요하다고 생각했습니다.MS Clarity란?Microsoft Clarity는 웹사이트 방문자의 행동을 시각적으로 분석할 수 있는 ..
첫 서비스로 반려동물 MBTI를 만든 뒤, 여러 SNS와 블로그 글을 통해 간단한 홍보를 진행했습니다.하지만 홍보보다 더 중요한 건 결국 얼마나 많은 사용자가 실제로 서비스에 들어오는가입니다.제가 생각하는 가장 기본적이면서 중요한 데이터는 활성 사용자 수(Active Users)입니다. 서비스에 특별한 기능이 많지 않더라도, 사용자가 블로그 글을 통해 얼마나 유입되는지를 아는 것이 핵심이었죠.이를 가장 쉽게 확인할 수 있는 도구가 바로 Google Analytics(GA)였습니다.설정일단 Google Analytics 사이트에 접속 후 측정 시작 버튼을 클릭합니다.2. 계정 이름을 입력합니다. (저는 weggle-plus로 설정)계정은 하나의 조직 단위라고 생각하면 됩니다. 회사, 팀, 개인 단위로 생성..
첫 개인 사이드 프로젝트로, 바이브코딩을 통해 반려동물 MBTI 서비스를 만들기로 했습니다.이 아이디어를 생각하게 된 계기는, 누군가와 대화를 하다가. 새로운 사이드 프로젝트인 MBTI와 관련된 프로젝트를 만든다고 했다. 그리고 같은 날에 강아지를 엄청 좋아한다는 이야기를 들었다.아이디어의 시작은 우연한 대화였습니다. 누군가의 사이드 프로젝트 아이디어를 들었고, MBTI 관련이였으며, 같은날 다른 사람이 강아지를 정말 좋아한다는 얘기를 했습니다.“그렇다면 MBTI를 사람뿐 아니라 반려동물에게도 적용할 수 있지 않을까?“라는 생각이 들었습니다.예를 들어, 손님을 반기는 강아지가 있는가 하면, 그렇지 않은 강아지도 있죠.이런 차이를 통해 재미있게 E/I 성향을 가늠할 수 있을 것 같았습니다.아이디어 구체화..
올해 제 목표는 기획부터 실제 서비스 결과물까지 혼자 완주해보는 것, 즉 솔로 프리너(Solo-preneur)가 되는 것이었습니다. 당연히 수익도 목표로 삼고 있었죠.하지만 시작은 쉽지 않았습니다.왜 시작이 어려웠나나의 무한한 상상력은 이미 카카x, 당근xx, 배달의xx, 네이x를 꿈꾸고 있었다. 이러다보니 초기 기능을 만들때 작업의 볼륨이 거대해지고 그걸 혼자서 꾸준히 작업하는것도 어려웠다.또한 개발자로서 저는 프로젝트 세팅에 과하게 진심인 타입입니다. 덕분에 사이드 프로젝트를 시작할 때마다 **“완벽한 초기 세팅”**에 집착했고, 정작 핵심인 서비스는 한 발짝도 못 나아가곤 했습니다.또한 비즈니스 모델도 어렵게만 생각했습니다. “결제가 있어야 수익이 생긴다”라는 틀에 묶여, 광고나 후원 같은 간단한 ..
