최근에 WMS 사용자 가이드 문서를 작성했습니다. 작성하면서 한 가지 생각이 들었는데, 이 가이드 문서와 실제 코드베이스를 함께 참조할 수 있는 챗봇이 있으면 꽤 쓸모있겠다는 것이었습니다.간단한 질문이나 기능 관련 요구사항은 챗봇이 문서와 코드를 기반으로 1차 정제를

MongoDB에는 SELECT FOR UPDATE가 없다. WriteConflict로 실패하는 구조 속에서 정합성과 throughput을 모두 확보하기 위해 정리한 4가지 동시성 제어 패턴 - 조건부 원자 연산, Bulk Operations, 분산 락, Outbox

이전 글에서 WebFlux 환경에서 분산 락을 Reactive 체인의 라이프사이클에 맞춰 안전하게 관리하는 방법을 다뤘습니다.락 획득과 해제 시점이 트랜잭션 커밋과 정확히 맞물리게 만들었고, 기능적으로는 문제가 없었습니다.하지만 부하 테스트를 통해 성능 측면에서 3가지

벨만-포드(Bellman-Ford)는 음수 가중치가 포함된 그래프에서 최단 경로를 찾는 알고리즘이다.최단 경로는 최대 V-1개의 간선을 포함한다.(사이클이 없는 한, 더 이상 추가 간선을 거치지 않아도 모든 노드에 도달 가능)V번째 반복에서도 거리가 갱신된다면, 음수

시뮬레이션 문제는 주어진 규칙에 따라 상태를 직접 변화시키며 최종 결과를 도출하는 문제 유형이다.정해진 공식이나 점화식으로 답을 구하는 DP, 탐색, 수학적 문제와 달리“규칙을 그대로 구현해야 하는 문제”가 대부분이다.즉, 해답의 핵심은 알고리즘보다는 과정의 재현이다.

REST와 GraphQL은 모두 널리 쓰이는 API 접근 방식이지만, 데이터를 어떻게 요청·조합·전달할 것인지에 대한 철학이 다르다. 본 글은 두 방식을 데이터 통합 관점에서 비교하고, 어떤 상황에서 어떤 방식을 선택할지 실무 기준을 제시한다.두 서비스가 있다고 가정한

MSA(Microservice Architecture)에서는 하나의 거대한 애플리케이션 대신, 역할별로 쪼개진 여러 서비스가 독립적으로 배포/확장됩니다. 이때 모든 외부 트래픽은 API Gateway를 통해 유입되며, Gateway는 인증/인가, 라우팅, 로깅/모니터링

백트래킹(Backtracking)은 모든 가능한 경우의 수를 탐색하면서, 불필요한 경로를 조기에 차단하는 탐색 알고리즘이다.쉽게 말해 “조건에 맞지 않으면 바로 돌아가는(Backtrack)” 방식의 완전탐색이다.완전탐색(Brute-force)은 가능한 모든 경우를 시도

DP는 큰 문제를 작은 문제로 나누고, 그 결과를 저장하여 재활용하는 방식으로 문제를 해결하는 기법이다. 핵심 요약같은 계산을 반복하지 않음이전 단계의 최적 결과를 이용중복 계산을 줄여 효율적으로 계산문제를 쪼갤 수 있는지 확인큰 문제를 작은 하위 문제로 분리 가능해

Spring WebFlux 환경에서 Redisson을 이용해 분산 락을 구현할 때,락을 해제하는 방법으로 보통 아래 두 가지가 있습니다forceUnlock()unlock(threadId)두 메서드는 겉보기엔 비슷하지만, 내부적으로 동작 방식과 안전성 측면에서 꽤 큰 차

Spring MVC 같은 동기 트랜잭션 환경에서는 @Transactional 바깥에서 분산 락을 잡고, finally 블록에서 분산 락을 해제하면 큰 문제가 없습니다.하지만 WebFlux 환경에서는 이야기가 달라집니다.요청은 논블로킹(Non-blocking) 으로 처리