메일함은 너무 복잡했다: 뉴스레터 앱 Presso의 시작

안녕하세요, Presso 개발자입니다.하나의 서비스를 시작하게 되는 계기는 다양합니다. 거창한 목표일 수도 있고, 시장의 기회를 발견한 것일 수도 있습니다.저에게는 아주 사소하지만, 모두가 공감하는 '불편함'이 그 시작이었습니다.이번 글부터 몇 편에 걸쳐, 사이드 프로젝트로 시작한 뉴스레터 앱 'Presso'의 개발기를 공유하려 합니다.오늘은 그 첫 번째 이야기로, 기술적인 내용에 앞서 "왜" 이 서비스를 만들게 되었는지에 대한 배경을 이야기해 보려 합니다.1. 문제 인식: "좋은 정보가 받은 편지함에서 사라지고 있었다"저를 포함한 초기 팀원들은 모두 유용한 뉴스레터를 구독하는 것을 좋아했습니다. 하지만 어느 순간부터, 정작 중요한 정보들이 업무 메일, 광고, 각종 알림과 뒤섞여 길을 잃는 현상을 공통적..
회고/개발 2025. 8. 7. 23:02

현장 결제 이탈률을 낮춘 카카오페이 도입기

안녕하세요, 백엔드 개발자입니다.온라인 서비스의 편리함이 오프라인 현장의 복잡함과 만났을 때, 우리는 종종 예상치 못한 '병목 현상'을 마주하게 됩니다. 저희 팀에게는 그것이 바로 '결제'였습니다.이번 글에서는 페스티벌 물품보관 서비스에서 겪었던 현장 결제의 어려움을 카카오페이라는 익숙한 기술을 통해 어떻게 해결했는지, 그 과정과 결과를 공유하고자 합니다.1. 문제점: 현장의 벽에 부딪힌 결제 시스템모든 서비스는 초기에 가설을 세웁니다. 저희의 가설은 '사용자들이 앱에서 간편하게 미리 결제하고 현장을 방문할 것'이었습니다. 그래서 서비스의 유일한 결제 방식으로 사용자가 앱에서 직접 카드 번호와 유효기간을 입력하는 기능을 구현했습니다.하지만 페스티벌 현장은 저희의 가설과 정반대로 움직였습니다. 사전 예약자..
회고/개발 2025. 8. 7. 00:16

하드코딩에서 관리자 페이지까지: 유연한 페스티벌 정책 시스템 구축기

안녕하세요, 백엔드 개발자입니다.새로운 페스티벌이나 이벤트가 열릴 때마다, 백엔드 개발자가 직접 코드를 열어 가격, 수량, 이미지 경로 같은 정책들을 수정하고 있다면 어떨까요? 배포 없이는 사소한 문구 하나 바꾸기 어렵고, 그 과정에서 실수가 발생할 위험도 항상 존재합니다.이번 글에서는 제가 경험했던 '페스티벌 정책 관리 시스템'의 발전 과정에 대해 이야기하고자 합니다. 매번 반복되던 하드코딩 작업을 어떻게 데이터베이스화하고, 최종적으로는 개발자의 손을 떠나 현업 담당자가 직접 관리할 수 있는 관리자 페이지로 만들었는지, 그 두 단계의 여정을 공유합니다.1. 하드코딩의 시대초기 저희 시스템은 새로운 페스티벌이 추가될 때마다 백엔드 개발자의 수작업을 필요로 했습니다.요금 정책: 물품 보관함 사이즈(S/M/..
회고/개발 2025. 8. 6. 10:58

현장 QR코드 장애를 서버와 웹으로 해결한 이야기: 페스티벌 물품보관 서비스 개발기

안녕하세요, 백엔드 개발자입니다. 서버 개발자는 대부분 논리적으로 예측 가능한 환경 안에서 코드를 작성합니다. 하지만 그 코드가 온라인을 넘어 오프라인 '현장'과 맞닿는 순간, 우리는 전혀 예상치 못한 변수들과 마주하게 됩니다.이번 글에서는 제가 경험했던 한 페스티벌의 '물품 보관 서비스' 개발 과정에서, 서비스 오픈 직전에 터진 아찔한 돌발 상황과 그것을 해결했던 경험을 공유해 보려 합니다. 앱 업데이트 없이, 오직 서버와 웹의 기지로 위기를 넘겼던 이야기입니다.1. 최초의 계획: QR코드 기반의 간편한 체크인저희가 설계했던 물품보관 서비스의 사용자 시나리오는 간단하고 명확했습니다.사용자는 앱에서 물품보관 이용권을 미리 구매합니다.페스티벌 현장의 물품보관소에 도착하면, 보관소에 비치된 고유 QR코드를 ..
회고/개발 2025. 8. 5. 00:37

API 로그, 비즈니스 데이터로 만들기 3편: Fluentd 설정부터 BigQuery 연동까지 (Ubuntu 기준)

안녕하세요, 백엔드 개발자입니다.지난 글 "">실전 편: NestJS 미들웨어로 API 로그 완벽하게 수집하기“에서는 NestJS 애플리케이션에서 발생하는 모든 API 로그를 표준화된 JSON 형태로 생성하는 방법을 다뤘습니다.이번 글에서는 그 후속편으로, 생성된 로그를 Fluentd를 이용해 최종 목적지인 Google BigQuery까지 안정적으로 전송하는 과정을 상세히 다루겠습니다. Ubuntu 서버 환경을 기준으로, 실제 운영에서 사용하는 설정 파일을 공유합니다. 1. 우리가 만들 파이프라인본격적인 설정에 앞서, 이번 글에서 구축할 파이프라인의 흐름을 다시 한번 확인해 보겠습니다.NestJS App → Fluentd (on Ubuntu) → Google BigQuery지난 글에서 NestJS App..
회고/개발 2025. 8. 4. 00:07

API 로그, 비즈니스 데이터로 만들기 2편: NestJS 미들웨어로 API 로그 완벽하게 수집하기

안녕하세요, 백엔드 개발자입니다.지난 글 "API 로그, 비즈니스 데이터로 활용하기"에서는 '왜' 로그를 비즈니스 데이터의 관점에서 바라봐야 하는지에 대해 이야기 나눴습니다. NestJS 애플리케이션에서 미들웨어(Middleware)를 활용하여 모든 API의 요청과 응답 로그를 수집하는 실전 코드를 상세히 공유하고자 합니다.다음 편에 다룰 Fluentd나 BigQuery 설정 없이도, 당장 여러분의 NestJS 프로젝트에 적용하여 콘솔에 JSON 로그를 출력하는 것만으로도 충분히 유용할 것입니다.1. 전체 아키텍처 다시 보기코드를 보기 전에 우리가 만들 시스템의 전체 그림부터 그려보겠습니다. 구조는 아주 간단합니다.Node.js App → Fluentd (on Ubuntu) → Google BigQue..
회고/개발 2025. 7. 30. 22:30

API 로그, 비즈니스 데이터로 활용하기 1편: Fluentd 기반 로깅 파이프라인 구축기

안녕하세요, 백엔드 개발자입니다.수많은 서버가 각자의 로그를 뱉어내는 상황, 다들 공감하시나요? 에러가 터졌을 때 어떤 서버가 문제인지, 원인이 무엇인지 파악하기 위해 여러 서버를 오가며 로그를 뒤지는 경험은 개발자에게 익숙한 일상입니다.하지만 어느 날 문득 이런 생각이 들었습니다."우리가 쌓는 로그, 단순히 에러 디버깅에만 쓰고 있는 건 아닐까? 이 데이터로 비즈니스에 더 큰 가치를 만들 수는 없을까?"로그는 사용자가 우리 서비스와 소통하며 남기는 소중한 발자취입니다. 단순히 서버의 상태를 기록하는 것을 넘어, 사용자를 이해하고, 프로덕트를 개선하며, 비즈니스의 성장을 견인하는 핵심 데이터가 될 수 있습니다.이러한 관점에서 저희 팀이 구축한 Fluentd 기반의 API 로깅 시스템과 그 과정에서 얻은 ..
회고/개발 2025. 7. 29. 22:10