호기심 많은 솔이의 개발 노트

OUTBOX 패턴이란?OUTBOX 패턴은 외부 시스템으로 처리해야 할 작업을 바로 실행하지 않고, 먼저 DB 테이블에 "해야 할 작업"으로 저장해두고, 별도 워커가 그 테이블 또는 큐를 기준으로 처리하는 방식이다. 특히, 이벤트 기반 아키텍처에서 메시지 유실을 방지하고, 데이터 정합성을 보장하는 데 활용한다. 예를 들면, 특정 이벤트에 대한 알림톡을 보내야 하는 경우, 바로 알림톡 API를 호출하는 게 아니라, 먼저 DB에 데이터를 남기고, 프로듀서가 SQS에 메시지를 넣고, 워커가 SQS 메시지를 받아서 해당 outboxId를 기준으로 OUTBOX를 선점한 뒤 알림톡을 발송할 수 있다. 사용하는 이유?[중복 처리 방지, 장애 복구, 처리 상태 추적]알림톡 같은 외부 API 호출은 언제든 실패할 수 있..

- 문제 상황 : 특정 비즈니스 이벤트가 발생했을 때, 담당자에게 정해진 시간 안에 알림 전달 필요. - 해결 방향 : 이벤트와 관련된 사용자에게 외부 알림톡 API를 통해 안내 메시지를 발송하도록 설계 및 구현 [흐름 정리]1. 비즈니스 이벤트 발생 2. Producer가 알림 발송 작업을 Outbox에 저장 3. Producer가 메시지 큐에 작업 ID 전송 4. Worker가 큐 메시지 수신 5. Worker가 Outbox 작업을 선점 6. Worker가 알림 템플릿 조회 7. Worker가 발송에 필요한 데이터를 조회하는 SP 실행- 테이블들을 상황에 맞게 조회, 조인하여, 필요한 데이터들을 가져옴8. Worker가 템플릿 파라미터 구성 - 위에서 가져온 필드들을 Java에서 파싱하여 템플릿에 ..

오늘 공통 모듈 분리에 대한 설명을 들었다. 내용을 요약하면, 어떤 프로젝트에서는 쓰이고, 또 어떤 프로젝트에서는 쓰이지 않는 것들이 아니라, 대부분의 프로젝트에서 쓰이는 것들, 예를 들면 db 설정, 해싱, jwt 관련 로직, 전역 예외처리, 공통 응답/에러 포맷, 검증(Validation), 로깅과 같은 것들은 따로 분리해서 뽑아 놓으면 새로운 프로젝트에서도 그대로 쓸 수 있고, 이를 잘 활용하면 개발 효율이 많이 올라간다는 것이었다. 위에 나오는 것들 외에도 알림톡 모듈을 개발한 후에 메일 전송 모듈을 만든다고 하면 공통되는 로직이 많을 것이다. 알림톡 모듈을 개발할 때, 그런 공통 로직들을 잘 뽑아서 정리해 놓으면 메일 전송 모듈을 개발할 때에는 개발 시간이 많이 단축될 것이다. 위의 내용들을..

프로시저란?프로시저(Procedure)는 특정 작업을 수행하기 위해 미리 정의된 일련의 명령어 집합으로, 데이터베이스에서 데이터의 추가, 수정, 삭제, 조회 등 복잡한 작업을 자동화하고 효율적으로 처리하기 위해 사용된다. 프로시저는 함수와 달리 값을 반환하지 않고 여러 동작을 묶어 하나의 논리적 단위로 실행한다는 특징을 가지고 있다. 프로시저를 사용하면 반복적인 업무를 줄이고 데이터베이스 성능을 향상시킬 수 있다.미리 만들어서 DB에 저장해두고, 필요할 때 이름으로 호출하면, 프로시저 내에 들어있는 여러 SQL(조회/수정/삽입/삭제, 계산, 조건문 등)이 한 번에 실행된다. 프로시저를 사용하는 이유 1. 같은 로직을 여러 시스템에서 재사용 할 수 있다. ㅡ> 추후 비슷한 시스템 개발 시 시간 단축 가능..

기본 흐름 구성우리 서비스에서는 특정 이벤트 발생 -> Producer가 SQS에 메시지를 Enqueue -> Consumer가 Polling으로 Dequeue 후 알림톡 발송 -> 성공 시 메시지 삭제 흐름으로 알림톡 모듈을 구성하였다. 과금 방식그리고 과금(잔액 차감)은 "큐에 들어간 순간 바로 차감"이 아니라, Enqueue 시점에는 예약 차감 & 임시 과금 상태를 저장하고 Dequeue 후 발송 성공 시점에 확정 차감 & 실제 잔액을 차감하는 식으로 구성하였다. Enqueue 단계에서 잔액을 바로 차감하지 않는 이유를 설명하자면, SQS는 기본적으로 적어도 한 번 전달될 수 있고, 네트워크/타임아웃/컨슈머 장애로 인해 같은 메시지가 중복 처리될 가능성이 있다. 또한, 외부 알림톡 벤더 API는 ..

SQS란? SQS(Simple Queue Service)는 AWS에서 제공하는 완전 관리형 메시지 큐 서비스로, 분산 시스템과 애플리케이션 간의 메시지(작업)를 안정적으로 주고받도록 하여 서비스들을 분리(Decoupling)하고 확장성을 높여주는 역할을 한다. SQS는 생산자(Producer)가 보낸 메시지를 Enqueue를 통해 큐에 저장하고, 소비자(Consumer)가 필요할 때 큐에서 그 메시지를 가져가(Dequeue) 처리하는 비동기 방식으로 작업이 이루어진다. SQS의 작동 방식위 그림은 AWS SQS의 작동 방식이다. 맨 왼쪽의 Producer는 메시지를 제공하는 쪽이다. 즉, 메시지를 큐에 넣는 쪽을 producer라고 한다. 이렇게 큐에 들어간 메시지는 설정에 따라 서버사이드 암호화(S..

이번 주에는 JWT 기반 로그인/회원가입을 구현하기 위해 관련 개념을 학습하고 실제 적용을 준비하였다. JWT는 토큰 기반 인증 방식으로, 세션을 서버에서 관리하지 않아도 되기 때문에 확장성과 유지보수 측면에서 장점이 많았다. 학습 과정에서 Access Token과 Refresh Token의 역할을 명확히 구분하는 것이 중요하다는 점을 알게 되었고, 특히 보안성을 높이기 위해 Refresh Token을 Redis에 저장하고 관리하는 방식을 적용하려고 했다. 이를 통해 토큰 만료 시점과 블랙리스트 처리, 강제 로그아웃 같은 시나리오를 더 유연하게 처리할 수 있다는 점을 이해할 수 있었다. 또한 Redis를 단순 캐시로만 생각했었는데, 이번 학습을 통해 분산 환경에서의 세션 관리 대체재로 활용할 수 ..

이번 주에는 파이널 프로젝트에서 공통 기능인 로깅과 예외 처리를 직접 구현해 보았다. 실제 서비스에 필수적인 기능이지만 처음으로 구조를 잡고 적용하다 보니 생각보다 신경 써야 할 부분이 많았다. 로깅에서는 에러 상황뿐만 아니라 정상적인 흐름도 잘 기록될 수 있도록 로그 레벨을 분리하고, 운영 환경에서의 모니터링을 고려한 구조를 학습할 수 있었다. 예외 처리에서는 전역 예외 처리기를 통해 서비스 전반에서 일관된 응답을 제공하는 방법을 적용하면서, 에러 코드 관리와 응답 DTO 설계의 중요성을 느꼈다. 이번 작업을 통해 단순히 코드를 작성하는 것 이상의, 서비스의 안정성과 유지보수성에 직결되는 공통 기능이 얼마나 중요한지 체감할 수 있었다. 커스텀 예외 같은 것들은 처음 해보는 내용이라 생소해서 어렵..

이번 주에는 팀 프로젝트에서 처음으로 CI/CD 환경을 직접 구성해보았다. 처음 해보는 작업이라 생소한 개념도 많았고, 설정 과정에서 예상치 못한 오류도 자주 발생했지만, 그만큼 배우는 것도 많았다. CI/CD를 구성하는 과정에서 GitHub Actions, Docker, AWS ECR, EC2, Nginx 등 다양한 기술 스택을 다뤄보았고, 코드를 작성하는 건 별로 없지만 과정을 이해해 보면서 알게 된 게 많은 것 같다. 특히, React, Spring Boot, FastAPI를 모두 포함한 멀티 모듈 환경을 배포하면서 서비스 간 연동 구조를 이해하는 데 많은 도움이 됐다. 처음에는 Nginx 설정 문제와 ECR 푸시 과정에서 어려움을 겪었지만, 로그를 보면서 원인을 분석하고 해결책을 찾는 과정..

처음 참가한 해커톤에서 대상이라는 예상치 못한 결과를 받았다. 사실 해커톤을 준비하면서도 부족한 점을 많이 느꼈고, 대회 도중에도 문제 해결 과정에서 어려움을 겪을 때가 많았다. 그래서 상을 받겠다는 생각은 못했었는데, 막상 대상을 받게 되니 놀랍고 감사하다는 생각을 했던 것 같다. 이번 해커톤에서 배운 점이 많은데,우선, 해커톤을 준비하고 진행하는 과정에서 단순한 개발 실력뿐만 아니라 팀워크와 문제 해결 능력의 중요성을 크게 체감했다. 짧은 시간 안에 아이디어를 구체화하고, 팀원들과 역할을 분담하며 빠르게 개발을 진행하는 과정에서 애자일 프로세스의 중요성에 대해서도 배울 수 있었다. 우리팀에 PM이 없어서 얼떨결에 PM 역할 까지 맡게 됐는데, 이 과정에서 우선순위를 설정하고, 논의 사항에 대해 결정하..