분류 전체보기 276

[Pinit] 푸시 알림 발송하기

FCM 토큰으로 푸시알림을 발행하려고 하자, FCM 토큰이 UNREGISTERED되어 있다는 응답을 받았다.공식 문서를 참고한 결과, FCM 토큰이 만료되었다는 의미라는 것을 알게 되었다. 토큰이 예상하지 못한 방식으로 만료될 수 있다는 것을 알게된 나는 토큰의 만료 관리 정책을 고려해야 한다는 걸 알 수 있었다.하지만, 일단 지금의 목표는 알림 발송이니, 알림 안오는 버그부터 해결하자.그렇게 만료된 토큰을 삭제하고 다시 시도해본 결과, 에러 메시지가 달라졌다.이번에는 Invalid Argument 문제를 마주했다. GPT에게 자주 발생하는 Invalid Argument 에러에 대해 물어보니 다음과 같이 답변해주었다.진짜 FCM 등록 토큰을 넣었나? 엉뚱한거 잘못 넣은 거 아닌가?토큰 문자열이 손상된 ..

gRPC 튜토리얼 - 기본 기능과 원리, 직접 해보기

시작하기 전 - RPC란?외부 서비스의 메소드를 프록시 객체를 통해 로컬 함수(시스템 내부 함수)에서 호출하는 것처럼 만들어주는 도구이다.gRPC는 Google에서 개발한 오픈소스 원격 프로시저 호출(RPC) 프레임워크로, HTTP/2 기반의 고성능 통신을 제공한다.본 글은 gRPC 공식 튜토리얼 예제를 따라가며 작성한 내용입니다.좀 더 자세한 내용은 해당 링크를 통해 확인하실 수 있습니다.[Quick startThis guide gets you started with gRPC in Java with a simple working example.grpc.io](https://grpc.io/docs/languages/java/quickstart/)목차proto 파일 작성의존성 설정gRPC 서버 구현gRPC..

과거의 잘못과 반성

이 글은 아마도, 내 블로그를 주변 사람들이 모르기 때문에 쓸 수 있는 기록이다.동시에 “지난 2년이 더 이상 특별한 사건으로 남지 않았다”는 작은 선언에 가깝다.올해 6월 이전의 회고가 비어 있었던 이유도 여기에 있다. 100% 사실도 아니거니와, 100% 사실이라면 너무 부끄럽기 때문에, 소설처럼 읽어주길 바란다. 내가 스스로를 설명할 때 자주 쓰던 단어는 책임감과 감사였다.그런데 어느 시점부터 그 두 단어가 흐려졌고, 그 과정에서 후회와 반성을 겪었다.그리고 그걸 다시 찾아내게 된 과정을 담는다.시작친구가 어떤 프로젝트를 완수하면 받을 비용이 50만 원이었는데, “그 돈을 그대로 나에게 주겠다”는 제안을 받았다. 조금 알아보니, 내 입장에서는 난도가 과도하게 높지는 않았다. 바로 직전에 했던 학교 ..

2025년 12월 2주차 회고

감사가 무너지면 꾸준함이 무너진다.조급해지기 전에, 대안을 찾기전에, 충분히 감사했나?이번 주의 감사: 원 없이 MQ + 알림 시스템 개발 + gRPC 써봤다.항상 무언가를 수행하기.체계적인 상태를 유지하기.큰그림 그리고 핵심 짚기.처음부터 끝까지 차근차근 전개하기.현 시스템에 대한 감사를 유지하기.보상 체계를 깨끗히 유지하기.입장 중심이 아닌 이익 중심으로 사고하기.윈-윈 전략 생각하기.다음에 무엇을 해야 할 지 상상하기.이번주에 한 것RabbitMQ + AsyncAPI 설계 및 구현마이크로서비스 간 이벤트 기반 통신 시스템 구축 gRPC 사용법 습득푸쉬알림 기능 밑바탕 & 로직 작성이번주에 하지 못한 것DB Delete 작동 방식 깔끔하게 정리하기데이터 지역성 정리푸쉬알림 기능 버그 수정AI 모델 설..

[Pinit] 푸시 알림 Exactly-Once 구현하기

백엔드 서버 관점에서 일반적인 이벤트 발행의 Best Practice를 생각해보자.새로운 방법의 발견이 아닌, 일반적인 방법을 정리 후 적용하는 게시글이다. 트랜잭셔널 아웃박스 패턴 (Transactional Outbox Pattern)프로듀서 -> MQ 사이의 1회 이상 전송을 보장하는 매커니즘(패턴)이다.DB의 트랜잭션은 사용자의 요청과 DB 상태 변경을 원자적으로 묶어준다. 하지만, DB 상태 변경과 이벤트 기록, 그리고 이벤트 발행까지는 원자적으로 묶이지 않는다.트랜잭셔널 아웃박스 패턴은 DB 상태 변경과 이벤트 기록을 트랜잭션으로 묶는다.하지만, 트랜잭션 아웃박스 패턴은 1회 이상 발행 보장이지, 1회 발행 보장은 아니다.즉, 중복 발행 가능성이 있다.발행 후 해당 메시지를 발행함을 표기하지 못..

Java - classpath

우리가 특정 데이터를 JVM에 올리고 싶을 때, 이를 안정적으로 업로드할 "마법"이 필요해진다.이 예로는 공개 키 파일과 같은 것들이 있다.만약 키를 평범한 상대경로/절대경로로 가져오고 있다면, 이는 현재 환경에 종속적인 빌드 결과가 된다.(참고로 비밀 키와 같은 secret값들은 엄격한 운영 상황에서는 배포의 범위가 빌드 수준까지 넓어져 클래스패스에 올리지 않는다.)이때, 클래스패스라는 용어를 곧잘 접하게 된다. 클래스패스는 자바의 JVM 이 클래스를 로드할 때 사용하는 클래스로더와도 곧잘 얽히는데, 지금부터 이 클래스패스에 대해 빠르게 알아보자.1. 클래스패스란 무엇인가간단히 말하면JVM이나 컴파일러가 .class 파일과 리소스(예: .properties, .json, .xml)를 찾기 위해 검색하는..

유의미한 대화

나는 보통 내 이야기를 다른사람에게 하는 것보단, 다른 사람의 이야기를 듣는 것을 좋아한다. 사실 이런 글을 적는 것도 오만해지는 것 같아 그리 좋아하진 않는다. 단지 기록을 위해 남겨둔다. 브레인 스토밍이나 친목을 위한 대화 과정에서는 이것들이 유의미할 수 있지만, 내가 집중하고 있는 순간에는 그런 것들이 거슬리는 순간이 있다. 그럴 때 상대방에게 매몰차게 대하게 되고, "기분파"가 되는 듯한 감각, 상대방에 대한 미안함도 조금 생기게 된다. 항상 "직설적인 내용"에 "완곡한 톤"으로 말하려고 하는데, 쉽지 않은 것 같다. 이에 대한 정말 좋은 기준이 있다. "이 행동을 함을 통해, 듣는 상대방을 강제적으로 움직이게 해야 하나?" 우리는 보통 긴장감 있는 협업을 할 때, 상대방이 무언가를 이야기..

[Pinit] 푸쉬 알림 발송해보기 - 직접 Web Push 사용

웹 푸쉬 알림은 표준 Web Push 프로토콜을 따르며, VAPID 인증 방식을 사용하여 브라우저에 푸쉬 알림을 전송한다.이때 VAPID(Voluntary Application Server Identification)는 애플리케이션 서버가 푸쉬 서비스에 자신을 식별할 수 있도록 도와주는 메커니즘이다.VAPID는 그 자체로 푸쉬 서버에게 자신을 알리는 ID가 됨과 동시에, VAPID는 공개 키 암호화 방식을 사용하여 서버가 푸쉬 요청을 보낼 때 자신을 증명할 수 있게 한다.Web Push 구현 목표브라우저에서Notification 권한 요청pushManager.subscribe() 로 endpoint, keys.p256dh, keys.auth 획득서버에서VAPID 키 쌍 생성 및 관리payload 암호화,..

[Pinit] AsyncAPI - EDA를 향한 이벤트 교환 계약 문서 작성

추천 이전 글: Rabbit MQ의 이름 짓기 [RabbitMQ] Rabbit MQ의 이름 짓기개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다dev.go-gradually.me Rabbit MQ를 이용한 이벤트 송/수신 방식을 설계하려면, 이 또한 계약을 설계해야 한다.프로토콜, API, 메시지 포맷 등을 설계하는 것은 성능 최적화 이상 중요한 백엔드 개발자의 매우 중요한 역할 중 하나이다.MSA 에서 이벤트 기반 메시징을 설계할 때, 다음과 같은 사항들을 고려해야 한다.프로듀서 주체Exchange nameRouting key컨슈머 주체Queue nam..

[RabbitMQ] Rabbit MQ의 이름 짓기

개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다. 생산자 선언ExchangeRouting Key소비자 선언QueueBinding key (routing key에 의존적)나는 딱히 이름 짓기에 재능이 없어서 매번 AI에게 도움을 많이 받는데, 적어도 이름을 짓는데 어느정도 규칙이 있어야 나중에 읽을 때 무리가 없기 때문에, 각각의 수행하는 역할과 책임에 집중해서 이름을 짓는 규칙을 정해본다.과거 scheduleMemberNestedDtoMap 이라는 해괴한 이름을 짓고 팀원에게 쓴소리를 들은적도 있었다... 기본적으로 위 세 요소는 각각 다음과 같은 역할..