지금의 기록이 미래의 자산이 된다.

• 시스템 장애를 처리하기 위해 재처리 및 DLQ 적용하기

  2026-01-06

  devFancy

  Kafka
  • Prologue

  모든 기술 선택에는 트레이드오프가 존재합니다.

  이 글에서 소개하는 방식이 유일한 정답은 아니며, 각자의 비즈니스 환경에 맞는 최선의 선택을 고민하는 데 작은 참고가 되길 바랍니다.

  Prologue

  대규모 트래픽을 처리하는 비즈니스 로직에서 가장 두려운 상황 중 하나는 비동기 처리 중 발생하는 데이터 유실입니다. 특히 쿠폰 발급과 같이 유저에게 민감한 보상이 주어지는 시스템에서, API 응답은 성공했지만 내부 장애로 실제 발급이 누락된다면 서비스 신뢰도에 치명적인 타격을 입게 됩니다.

  이번 글에서는 쿠폰 발급 시스템을 예시로, Consumer 서버에서 처리 도중 DB 장애 등의 시스템 예외가 발생했을 때 어떻게 메시지를 유실 없이 보호하고 재처리하는지, 그 설계와 구현 과정을 공유합니다.

  예상 독자

  • 시스템 장애(DB) 발생 시 재처리에 대한 로직에 대해 해결 과정이 궁금하신 분

  • SpringBoot 환경에서 재처리 방식 및 DLQ 처리 과정이 궁금하신 분

  (이 글은 재처리/DLQ에 대한 기본 개념과 경험이 있는 독자를 대상으로 작성했습니다.)

  Read All

  ---

• '삶을 재구성하는 관계의 법칙, 사람을 남기는 사람' 책 리뷰

  2026-01-04

  devFancy

  Book
  • 시작하며

  이 글은 ‘삶을 재구성하는 관계의 법칙, 사람을 남기는 사람‘이라는 책을 읽고, 책의 내용과 함께 필자의 개인적인 생각을 정리한 글입니다.

  아직 완독하지 않았기에, 현재까지 읽은 내용을 바탕으로 정리 중인 ‘진행형’의 글임을 미리 밝혀둡니다.

  시작하며

  

  나이가 들수록 인간관계의 중요성을 더 많이 체감한다. 스스로 바쁘게 살아가며 노력한 것에 비해 성과가 나지 않아 지친 부분도 있었고, 그 과정에서 가족이나 친구 등 주변 관계에 소홀했던 것은 아닌가 싶어 생각을 정리하고 싶었다.

  마침 생일날 합정동의 한 서점에 들렀다. 사장님께 현재의 고민을 말씀드리니 이 책을 추천해 주셨고, 시간 날 때마다 조금씩 읽으며 마음에 남는 문장들을 기록하기 시작했다.

  이 책의 저자는 프롤로그에서 ‘관계의 안정기’에 접어들며 이 글을 쓰게 되었다고 고백한다. 관계의 어려움을 어떻게 극복해 왔는지에 대한 그의 이야기가, 관계에 대해 고민하는 이들에게 한 줌의 도움이 되길 바라는 마음을 담았다고 한다.

  Read All

  ---

• 2026 Dev History

  2026-01-01

  devFancy

  DevHistory

  2026 Dev History

  • 2025 Dev History에 이어 2026년에도 내가 공부하면서 배운 내용을 꾸준히 기록해두자.
  Read All

  ---

• AWS EC2 기반 부하 테스트를 진행하며 시스템 아키텍처 및 성능 개선하기

  2025-12-30

  devFancy

  Technology
  • Prologue

  Prologue

  이 글에서 다루는 내용은 해당 Github 기반으로 작성되었으며, 시간에 따라 아키텍처 및 코드는 변경될 수 있습니다.

  이번 글에는 개인 프로젝트인 쿠폰 발급 시스템을 개발하면서, 프로젝트 목표인 선착순 이벤트 시 대규모 트래픽 속에서도 안정성과 성능을 보장하고자 했습니다.

  AWS EC2 기반으로 구축하고 최소 사양부터 시작해서 부하 테스트를 진행하면서 점진적으로 개선하는 과정을 공유하고자 작성하게 되었습니다.

  예상 독자

  • 부하 테스트를 통해 성능과 안정성을 점진적으로 개선하고자 하는 사람

  • 대규모 트래픽 처리를 위해 어떤 요소를 고려하고 그에 맞게 개선해야 하는지 궁금한 사람

  (이 글은 Redis와 Kafka에 대한 지식과 경험이 있는 예상 독자를 기준으로 작성했습니다.)

  Read All

  ---

• 외부 시스템과의 연동 시 발생하는 장애를 격리하기 위해 서킷 브레이커 적용하기

  2025-12-12

  devFancy

  Technology
  • Prologue

  Prologue

  이 글에서 다루는 예시 코드는 해당 Github이며, 시간에 따라 코드가 변경될 수 있습니다.

  저번 글에서는 왜 서킷 브레이커를 사용하는지, 개념과 사용 방식에 대해 알아봤습니다.

  이번 글에서는 외부 시스템으로부터 장애가 전파되는 것을 막기 위해 서킷 브레이커를 적용한 과정을 공유하고자 합니다.

  이전 회사에서 프로젝트를 진행하던 중, 외부 시스템 연동 과정에서 장애를 겪은 경험이 있습니다. 기능의 요구사항에 따라 동기 혹은 비동기 방식을 통해 연동이 되는데, 그 당시에는 서비스의 기능과 요구사항을 봤을 때 동기 방식으로 진행해야 했습니다.

  그래서 동기 방식으로 진행하고 테스트를 진행했을 때, 성공 케이스에 대해서는 성공적으로 잘 이뤄졌습니다. 하지만, 서비스를 운영하다보면 해피 케이스 보다는 예외 케이스에 대해 많이 고려해야 한다는 점을 알 수 있었습니다.

  해피 케이스는 비즈니스 요구사항에 맞춰 로직이 정상적으로 수행된 경우를 말합니다.

  예외 케이스는 크게 비즈니스 로직에 의한 예외와 시스템 장애 두 가지로 구분하여 접근해야 합니다.

  첫 번째는 비즈니스 로직상 발생하는 예외입니다. 이는 서비스의 흐름상 충분히 예상 가능한 상황입니다. 예를 들어, 사용자의 잔액이 부족하거나, 유효하지 않은 카드 번호를 입력하여 PG사로부터 거절 응답(4xx)을 받는 경우가 이에 해당합니다.

  두 번째는 예상치 못한 시스템 장애입니다. 네트워크 지연으로 인한 타임아웃(Timeout)이나, 외부 PG 서버의 내부 오류(5xx) 등으로 인해 정상적인 통신이 불가능한 경우를 말합니다.

  이번 글에서 저는 “외부 시스템 장애 발생 시 어떻게 시스템을 격리할 것인가?“에 대해 초점을 맞췄습니다.

  이를 구체적으로 설명하기 위해 외부 의존성이 높은 ‘결제’ 도메인과 외부 시스템인 PG사 연동을 예시로 활용했습니다. (단, 결제 도메인에 대한 실무 경험을 기반으로 작성한 내용은 아니므로, 실제 서비스의 비즈니스 로직과는 차이가 있을 수 있는 점 참고 부탁드립니다.)

  예상 독자

  • 외부 시스템과의 장애 격리를 위해 Spring Boot, Kotlin 기반 환경에서 서킷 브레이커를 적용한 과정이 궁금한 분

  • 서킷 브레이커에서 정확한 집계 처리를 위해 비즈니스 로직상 발생하는 예외와 예상치 못한 시스템 장애를 구분하는 방법이 궁금한 분

  • Beeceptor 를 이용한 Mock 테스트하는 방법이 궁금한 분

  Read All

  ---