이 글에서 다루는 예시 코드는 해당 Github이며, 시간에 따라 코드가 변경될 수 있습니다.
저번 글에서는 왜 서킷 브레이커를 사용하는지, 개념과 사용 방식에 대해 알아봤습니다.
이번 글에서는 외부 시스템으로부터 장애가 전파되는 것을 막기 위해 서킷 브레이커를 적용한 과정을 공유하고자 합니다.
이전 회사에서 프로젝트를 진행하던 중, 외부 시스템 연동 과정에서 장애를 겪은 경험이 있습니다. 기능의 요구사항에 따라 동기 혹은 비동기 방식을 통해 연동이 되는데, 그 당시에는 서비스의 기능과 요구사항을 봤을 때 동기 방식으로 진행해야 했습니다.
그래서 동기 방식으로 진행하고 테스트를 진행했을 때, 성공 케이스에 대해서는 성공적으로 잘 이뤄졌습니다. 하지만, 서비스를 운영하다보면 해피 케이스 보다는 예외 케이스에 대해 많이 고려해야 한다는 점을 알 수 있었습니다.
해피 케이스는 비즈니스 요구사항에 맞춰 로직이 정상적으로 수행된 경우를 말합니다.
예외 케이스는 크게 비즈니스 로직에 의한 예외와 시스템 장애 두 가지로 구분하여 접근해야 합니다.
첫 번째는 비즈니스 로직상 발생하는 예외입니다. 이는 서비스의 흐름상 충분히 예상 가능한 상황입니다. 예를 들어, 사용자의 잔액이 부족하거나, 유효하지 않은 카드 번호를 입력하여 PG사로부터 거절 응답(4xx)을 받는 경우가 이에 해당합니다.
두 번째는 예상치 못한 시스템 장애입니다. 네트워크 지연으로 인한 타임아웃(Timeout)이나, 외부 PG 서버의 내부 오류(5xx) 등으로 인해 정상적인 통신이 불가능한 경우를 말합니다.
이번 글에서 저는 “외부 시스템 장애 발생 시 어떻게 시스템을 격리할 것인가?“에 대해 초점을 맞췄습니다.
이를 구체적으로 설명하기 위해 외부 의존성이 높은 ‘결제’ 도메인과 외부 시스템인 PG사 연동을 예시로 활용했습니다. (단, 결제 도메인에 대한 실무 경험을 기반으로 작성한 내용은 아니므로, 실제 서비스의 비즈니스 로직과는 차이가 있을 수 있는 점 참고 부탁드립니다.)
예상 독자
외부 시스템과의 장애 격리를 위해 Spring Boot, Kotlin 기반 환경에서 서킷 브레이커를 적용한 과정이 궁금한 분
서킷 브레이커에서 정확한 집계 처리를 위해 비즈니스 로직상 발생하는 예외와 예상치 못한 시스템 장애를 구분하는 방법이 궁금한 분
Beeceptor 를 이용한 Mock 테스트하는 방법이 궁금한 분
이 글에서 다루는 모든 코드는 해당 Github을 참고해 주시면 감사하겠습니다.
외부 API 연동 시 주의해야할 점 중 하나는 외부 시스템에 장애가 발생하는 경우입니다.
외부 시스템의 응답 지연이나 에러가 우리 시스템의 스레드 고갈로 이어지는 것을 방지하고, 장애 상황에 유연하게 대처하기 위해 서킷 브레이커(Circuit Breaker) 패턴을 사용합니다.
이번 글에서는 서킷 브레이커의 핵심 개념과 상태 변화, 그리고 Resilience4j를 활용한 구체적인 설정 방법을 정리해 봅니다.
그리고 이후에 SpringBoot, Kotlin 기반으로 서킷 브레이커를 적용한 경험을 공유하고자 합니다.
이 글에서 다루는 모든 코드는 개인 프로젝트를 기반으로 작성되었으며, 아래 Github 를 참고해 주시면 감사하겠습니다.
테스트 코드를 처음 작성하기 시작한 지 어느덧 2년이 되었습니다. 초기에는 단순히 “테스트 코드가 있어야 한다”는 의무감이나 문법적인 사용법(How)을 익히는 데 급급했습니다. 하지만 프로젝트의 규모가 커지고 비즈니스 로직이 복잡해질수록, “어떻게 짜는 것이 지속 가능한 테스트인가?”에 대한 고민이 깊어졌습니다.
단순히 커버리지를 높이는 것을 넘어, 유지보수 비용을 낮추고 비즈니스 가치를 지키는 테스트 전략이 필요함을 느꼈습니다.
이 글은 여러 기술 서적과 현업의 기술 블로그를 참고하며, 실제 프로젝트에 적용해 본 가치 있는 테스트를 위한 전략과 고민을 정리한 글입니다.
저와 비슷한 고민을 하고 계신 분들께 작은 이정표가 되기를 바랍니다.
예상 독자
이 글은 Java, Spring Boot 환경에서 기본적인 테스트 코드 작성 경험이 있으며, 더 효율적이고 체계적인 테스트 전략을 고민하는 분들을 대상으로 작성했습니다.
이 글은 요즘 당근 AI 개발 책을 읽고 느낀 필자의 주관적인 생각입니다.
해당 책에서 인상깊게 봤던 부분은 Github에 자세히 정리했습니다.
AI 기술이 빠르게 발전하면서 IT 서비스 회사 중 하나인 당근팀에서는 AI 기술을 어떻게 활용하는지 궁금해서 해당 책을 읽게 되었다.
해당 책에 대한 저자분들이 아래 유튜브 영상에서 소개해주는 내용이 있는데, 참고하면 좋을 것 같다.
[Youtube] 개발자 없이 AI로 프로덕트 a-z 완성하기 (2025.10.13)
[Youtube] CS 도메인에서 AI로 압도적인 사용자 경험 제공하기 (2025.10.27)
두 개의 영상을 보면서 느낀점은 “개발자 없이 AI로 프로덕트 a-z 완성하기” 영상의 경우 비개발자에 맞춰서 해당 책을 리뷰한 내용이 크고,
“CS 도메인에서 AI로 압도적인 사용자 경험 제공하기” 의 경우 소프트웨어 엔지니어에 맞춰서 책을 리뷰한 부분이 있다. (개인적으로 이 부분이 더 도움을 받았던 영상이었다)
이 글은 제미니의 개발실무 - 커머스 백엔드 기본편 강의를 듣고 느낀 필자의 주관적인 생각입니다.
해당 강의를 들으면서 중요하거나 기억하고 싶은 부분들을 Github에 정리했습니다.
해당 강의를 듣게된 배경
필자는 이전부터 커머스 도메인에 대해서 관심을 가져왔고, 성장을 위해 가고자하는 부분이 커리어 방향성과 맞는지 확인하고 싶어서 이 강의를 듣게 되었다.
또한, 해당 강의를 만드신 분이 개인적으로 운영하고 있는 유튜브 영상도 즐겨봐왔기 때문에 강의는 어떤 식으로 만들었는지도 궁금해서 더 관심을 가진 부분도 있다.