2026/04 27

Inbox / Outbox 패턴 정리

Inbox / Outbox 패턴 정리Inbox와 Outbox는 MSA나 이벤트 기반 구조에서 메시지를 안전하게 주고받기 위해 사용하는 패턴이다.서비스 간 통신에서 이벤트를 사용할 때는 다음과 같은 문제가 발생할 수 있다.DB 저장은 성공했는데 이벤트 발행은 실패하는 경우같은 이벤트가 여러 번 전달되는 경우이벤트 처리 중 장애가 발생하는 경우이런 문제를 줄이기 위해 사용하는 것이 Outbox 패턴과 Inbox 패턴이다. Outbox란?Outbox는 내 서비스에서 발행해야 할 이벤트를 저장하는 공간이다.예를 들어 주문이 생성 되면 주문 서비스는 다른 서비스에게 주문이 생성됐다는 이벤트를 보내야 한다.일반적인 흐름은 다음과 같다.주문 생성→ 주문 DB 저장→ 주문 생성 이벤트 발행하지만 이 방식은 문제가 생길..

Study 2026.04.30

모의 주식 대회 프로젝트에서 잘못된 상태 판단 로직을 수정한 과정

테이블 구조모의 주식 대회 서비스의 자산은 현재 아래 두 테이블을 기준으로 구성되어 있다.Account (계좌)- account_id- user_id- is_endedHoldings (보유 주식)- holding_id- account_id- stock_code- quantity- final_price하나의 Account 아래에 여러 Holdings가 존재하는 구조문제 상황초기 설계에서는 대회 종료 여부(is_ended)를 나타내는 컬럼이 존재하지 않았다.그래서 Holdings의 값을 기준으로 대회 종료 여부를 판단하려고 했다.holdings.final_price != 0 → 대회 종료문제 인식이 구조의 흐름은 다음과 같다대회 종료 → final_price 저장 → 조회 시 final_price로 종료 판..

Project 2026.04.29

주식 대회 정산 시 가격 조회 캐싱이 필요한가?

프로젝트 배경모의 투자 서비스에서 주식 대회 기능을 구현하고 있다.사용자는 가상의 돈으로 주식을 매수/매도대회 종료 시점에 보유 주식의 최종 가격 + 잔고 기준으로 수익률을 계산이를 기반으로 순위를 산정즉, 대회 종료 시점에는 모든 참가자의 보유 주식에 대해 종목별 최종 가격을 조회하는 과정이 필요하다.문제 상황여러 사용자가 동일한 종목을 보유할 수 있기 때문에 가격 조회 과정에서 중복 호출이 발생할 수 있다.사용자1: A, B, C 보유사용자2: B, C 보유→ B, C는 여러 번 조회될 수 있음같은 시점의 가격인데도 반복 조회가 발생하는 구조다.고민최종 가격은 DB에 저장해야한다.하지만 DB에 저장하기 전에 가격을 조회하는 과정에서 중복 API호출이 발생하는 문제가 있었다.그래서 캐싱을 고민하게 되었..

Project 2026.04.28

데이터 정합성

데이터 정합성데이터 정합성은 데이터가 서로 모순 없이 정확하고 일관된 상태를 유지하는 것을 의미한다.예시 :계좌 잔액 : 10000원거래 내역 합계 : 10000원이 둘이 같으면 정합성 유지, 다르면 정합성 깨짐 왜 중요한가잘못된 데이터 방지시스템 신뢰성 확보금융/주식 서비스 에서 필수특히 여러 데이터가 연결될 수록 정합성 유지의 중요도가 높아진다 정합성이 깨지는 원인1. 동시성 문제여러 요청이 동시에 데이터 수정예) 동시에 출금요청 → 잔액 꼬임2. 분산 시스템 문제서비스 간 처리 결과 불일치예) 계좌 차감 성공 → 물품 구매 실패 = 데이터 불일치 발생해결 방법1. 트랜잭션모두 성공 / 모두 실패2. 락 동시 접근 제어비관적 락: 충돌 방지낙관적 락: 충돌 감지 3. 분산 트랜잭션 2PC: 강한 정합..

Study 2026.04.27

멱등성

멱등성이란?멱등성은 같은 요청을 여러번 수행해도 결과가 한 번 수행한 것과 동일하게 유지되는 성질을 이야기한다.즉, 요청이 반복되더라도 결과가 변하지 않아야 한다. 금액 처리 예시로 보는 멱등성 멱등성이 없는 경우사용자는 한 번만 입금하려고 했지만, 동일한 요청이 여러 번 처리될 수 있다.예를 들어사용자가 입금 버튼을 한 번 클릭로딩이 오래걸림요청이 안 된건가? 라고 생각해서 입금 버튼을 여러번 클릭이 때 실제로는 첫번째 요청도 처리중이고 추가로 보낸 요청들도 모두 처리되면 사용자의 의도는 10000원 입금이었지만 20000원, 30000원이 입금 될 수도 있다. 이처럼 사용자의 의도와 다르게 동일한 요청이 여러 번 처리될 수 있기 때문에 멱등성 처리가 중요하다. 멱등성이 있는 경우같은 값을 여러 번 설..

Study 2026.04.26

라우터 / 스위치 / 허브 차이

네트워크 장비네트워크 장비는 여러 장치들이 데이터를 주고 받을 수 있도록 연결해주는 장치이다대표적으로 허브(Hub), 스위치(Switch), 라우터(Router)가 있다.허브(Hub)허브는 가장 단순한 네트워크 장비로 들어온 네트워크를 모든 포트로 그대로 전송한다특징데이터 목적지 구분 없음모든 장치에 동일하게 전송충돌 발생 가능성 높음스위치스위치는 허브의 단점을 개선한 장비로 MAC 주소를 기반으로 필요한 장치에만 데이터를 전송한다특징목적지 장치만 선택적으로 전송MAC 주소 테이블 관리충돌 감소LAN(내부 네트워크)에서 주로 사용라우터라우터는 서로 다른 네트워크를 연결하는 장비로 IP주소를 기반으로 데이터를 목적지까지 전달한다.특징네트워크 ↔ 네트워크 연결최적 경로 탐색공인 IP/사설 IP로 변환(NAT..

Study 2026.04.25

IP 주소 / 서브넷 마스크 / 공인 IP & 사설 IP

IP주소란IP주소(Internet Protocol Address)는 네트워크에서 각 장치를 식별하기 위한 고유한 주소이다.예시 : 192.168.0.1특징네트워크에서 컴퓨터를 구분하는 역할인터넷 통신 시 반드시 필요IPv4 / IPv6 두가지 방식 존재서브넷 마스크란서브넷마스크는 IP주소를 네트워크 영역과 호스트 영역으로 나누는 기준이다예시 : IP 주소: 192.168.0.10서브넷 마스크: 255.255.255.0의미 : 192.168.0 = 네트워크 10 = 호스트(개별장치)역할같은 네트워크인지 판단통신 가능 범위 결정공인 IP vs 사설 IP공인IP인터넷에서 직접 접근 가능한 IP특징전 세계에서 유일외부에서 접근 가능ISP(통신사)가 할당사설 IP내부 네트워크에서 사용하는 IP특징외부에서 접근 ..

Study 2026.04.24

OSI 7계층 / TCP-IP 4계층

OSI 7계층이란?OSI(Open Systems Interconnection)는 네트워크 통신 과정을 7단계로 나눈 이론적 모델이다.계층구조계층이름역할7Application사용자와 직접 통신(HTTP, FTP)6Presentation데이터 변환5Session연결 생성 및 유지4Transport데이터 전송(TCP/UDP)3NetworkIP 기반 경로 설정2Data LinkMAC 주소 기반 통신1Physical전기 신호 전송특징계층별 역할이 명확하게 분리됨문제 발생 시 특정 계층에서 원인 파악 가능실제 구현보다 개념 이해 중심TCP/TP 4계층이란?TCP/OP는 실제 인터넷에서 사용하는 표준 네트워크 모델이다.계층 구조계층역할OSI 대응Application응용 서비스 제공5~7Transport데이터 전송(T..

Study 2026.04.23

Redis Pub/Sub

Pub/Sub이란Pub/Sub은 Publish/Subscribe의 줄임말이다Publisher : 메시지를 보내는 쪽Subscriber : 메시지를 받는 쪽Channel : 메시지가 지나가는 통로동작 방식Redis Pub/Sub의 흐름은 다음과 같다.1. Subscriber가 특정 채널을 구독한다2. Publisher가 해당 채널에 메시지를 발행한다3. Redis가 그 채널을 구독중인 Subscriber들에게 메시지를 전달한다이 구조의 핵심은 중간에 Redis가 메시지 전달 역할을 해준다는 점이다.덕분에 Publisher는 누가 이 메시지를 받는지 몰라도 되고, Subscriber도 누가 보냈는지 몰라도 된다.왜 사용하는가?Redis Pub/Sub은 실시간 메시지 전달이 필요할 때 유용하다채팅 메시지 전달..

Study 2026.04.22

헥사고날 아키텍처 vs 레이어드 아키텍처

주식 관리 프로젝트를 진행하면서, 현재 내가 하고 있는 프로젝트에 어떤 아키텍처가 더 적합할지 고민하게 되었다.레이어드 아키텍처개념애플리케이션을 역할별 계층으로 나누는 구조구조Controller→Service →Repository →DB특징위에서 아래로 흐르는 구조역할이 명확하고 이해하기 쉬움빠른 개발에 적합한계Service가 DB, 외부 API에 직접 의존변경 시 영향 범위가 큼테스트가 어려워질 수 있음헥사고날 아키텍처개념비즈니스 로직을 중심에 두고 외부 요소를 분리하는 구조구조Controller →InPort →Service →OutPort →Adapter →DB핵심 개념Core비즈니스 로직이 위치하는 중심영역DB, 외부 API등 기술 요소를 알고 있지 않음PortInPort외부 요청이 Core로 들..

Study 2026.04.21