유성

지난 글에서는 '테스트하기 좋은 구조'를 위해 비즈니스 로직을 도메인 모델로 옮기고, 비결정적인 값(시간 등)을 외부에서 주입받는 방법을 살펴봤다. 덕분에 우리는 빠르고 독립적인 단위 테스트(Unit Test)를 가질 수 있게 되었다. 하지만 실제 서비스는 혼자 돌아가지 않는다. 수많은 사용자가 동시에 요청을 보내고(동시성), 실제 데이터베이스에 값이 정확히 들어가는지 확인해야 하는 순간이 온다. 오늘은 단위 테스트만으로는 검증하기 까다로운 '동시성 문제'와 '실제 인프라 의존성'을 제어하며 테스트하는 법을 알아보자. 1. 동시성 테스트: "동시에 100명이 주문하면 어떻게 될까?"단일 스레드에서 돌아가는 단위 테스트는 동시성 버그를 절대 잡아낼 수 없다. 예를 들어, 재고를 1 감소시키는 로직을 테스트..

개발자라면 항상 고민하는 문제가 있다."빠르게 변하는 비즈니스 요구사항 속에서도, 어떻게 시스템의 안정성을 지킬 것인가?" 이다. 테스트 코드는 그 질문에 대한 가장 확실한 대답이였다.그러나 현실적으로 '커버리지 100%'를 채우는 것이 능사는 아니다. 개발자에게 시간은 한정적이다. 오늘은 실무에서 느낀 테스트 코드의 진짜 목적과, 복잡한 분산 환경에서 테스트를 작성하며 마주한 난관들에 대해 이야기해보려 한다. 1. 왜 테스트 코드를 작성해야 하는가?테스트 코드의 장점으로 '버그 예방'을 생각할 수 있으나, 내가 경험한 가장 큰 가치는 '과감한 리팩터링을 가능하게 하는 안전장치' 이다.지금 막 시작한 프로젝트라고 한다면 테스트 코드를 쓴다는 것이 어려울 수 있다. 기능이 몇번 사용되고 버려진다거나 구조가..

신규 서비스에서의 검색 서비스신규 서비스를 만들 때 가장 난감한 기능 중 하나가 검색(search)이다.서비스는 보통 데이터를 기반으로 움직이는데, 신규 서비스는 애초에 데이터가 없다. 국가데이터포털이나 외부 API를 사용해도 데이터가 부족하거나, 정확하지 않거나, "껍데기 데이터"가 많다.이런 상황에서 내가 선택한 해법은 AI + API + DB를 체이닝하는 방식이다.데이터가 없어도 마치 모든 데이터를 알고 있는 서비스처럼 동작하게 만드는 구조다. 많은 신규 서비스의 경우 이러한 방식을 활용하는 것이 큰 도움이 될것이다. 데이터가 없다면?보통 데이터가 없는 경우 유/무료 API 및 국가데이터처를 활용하게 된다.그러나, 막상 사용해보면 형식은 제각각, 누락된 값은 많고 내 서비스에 최적화 하기까지 꽤 노..

이 글에서는 Kafka 기반의 대규모 채팅 서비스를 직접 설계하고 구현하며 마주친 문제와, 이를 어떻게 해결했는지를 기록합니다.인프라 아키텍처부터 코드 레벨의 구조 개선, 서비스의 생명주기 까지 순차적으로 회고합니다. 1. 서비스 구성을 위해 정해야 할 것각 노드간 통신을 어떻게 해야할지?단일 노드 사용 시 성능 한계와 노드 다운에 대한 안정성 문제가 있어, 멀티 노드로 구성하겠습니다. 그럼 멀티 노드간에 사용자에 대한 통신 문제를 아래 '짱구' 와 '철수' 예제로 보겠습니다.(Node는 서버 또는 Pod를 의미하며, client는 현재 연결된 connection을 의미합니다.) 위와 같이 Node를 구성 할 경우 '짱구'와 '철수'는 각기 다른 Node를 통신하기에 메시지 송수신이 불가능합니다. 짱구와..

프로젝트에서 repository.save() 메서드를 사용했음에도 불구하고 데이터가 커밋되지 않는 문제를 겪은 적이 있습니다. 이 글에서는 문제의 원인과 해결 방법을 공유합니다. 트랜잭션 처리 방식문제의 원인을 파악하기 위해 하나의 쓰레드에서 두 개의 메서드를 사용하며, 각각의 트랜잭션이 어떻게 작동하는지 세 가지 케이스로 살펴보겠습니다. 1. 첫 번째 케이스: 동일 트랜잭션두 메서드(A 트랜잭션, B 트랜잭션)가 동일한 트랜잭션에 포함되어 있습니다. 즉, A와 B가 모두 성공해야 트랜잭션이 커밋됩니다. 만약 B에서 예외가 발생하면, A에서의 작업까지 모두 롤백됩니다. |-----------(A 트랜잭션)-----------| |-----------(..