본문 바로가기

Programming

Programming/Technical Writing 2026. 3. 27. kafka를 통한 이벤트 기반 아키텍처 TL;DR"이벤트로 분리할 것인가 말 것인가"라는 판단이 설계의 핵심이다. 기술 도입보다, 어디에 경계를 그을지를 결정하는 것이 더 중요하다. 커머스 프로젝트에서 주문을 처리하는 서비스 코드가 점점 비대해지고 있었다. 주문을 생성하고 결제를 처리하는 핵심 로직 사이에 알림 발송, 유저 행동 로깅, 좋아요 집계 같은 부가 로직들이 동기적으로 끼어들어 있었다. 알림 서버가 느려지면 주문 응답도 느려지고, 로깅 DB에 문제가 생기면 좋아요가 실패하는 상황이 발생할 수 있었다.이번 과제에서는 이 문제를 세 단계로 풀었다. 먼저 Spring ApplicationEvent로 프로세스 내에서 주요 로직과 부가 로직의 경계를 나누고, Kafka로 프로세스 간 이벤트 파이프라인을 구축한 뒤, 그 파이프라인 위에서 선..
Programming/Technical Writing 2026. 3. 20. 외부 결제 시스템(PG) 연동에서 Circuit Breaker가 필요한 이유 TL;DR: 외부 결제 시스템 연동에서 장애를 막는 네 가지 방법 결제 기능을 구현할 때, 우리 서비스는 외부 PG(Payment Gateway) 시스템과 통신해야 한다. 문제는 이 외부 시스템이 항상 정상이라는 보장이 없다는 점이다. 응답이 느려질 수 있고, 아예 응답이 오지 않을 수도 있다. PG가 죽었는데 우리 서비스까지 같이 죽는 상황, 이른바 장애 전파(Failure Propagation) 를 어떻게 막을 것인가가 이 글의 주제다.이 글에서는 PG Simulator를 연동하면서 Resilience4j의 Circuit Breaker, Timeout, Fallback, Retry를 단계적으로 적용한 과정을 정리한다. 각 패턴이 어떤 문제를 해결하는지, 그리고 왜 그 순서로 적용해야 하는지에 초점을..
Programming/Technical Writing 2026. 3. 13. 조회 병목 해소 과정: 쿼리, 인덱스, 비정규화, Redis TL;DR: 정렬 기준이 되는 값을 저장하는 위치와 방법이 성능을 결정한다. 쇼핑몰 서비스에서 상품 목록 페이지는 가장 많은 트래픽이 몰리는 지점 중 하나다. 브랜드 필터링과 좋아요 순 정렬이라는 요구사항은 기능 명세서 위에서는 단순해 보이지만, 데이터 규모가 10만 건을 넘어서는 순간 그 단순함은 빠르게 무너진다. 초기엔 수십 ms 수준이던 응답 시간이 수백 ms로 늘어나고, 동시 요청이 쌓이기 시작하면 초 단위로 치솟는다. 기능은 동작하지만, 서비스는 버티지 못하는 상태다.이 글은 해당 병목을 단계적으로 해소한 과정을 담는다. 쿼리 실행 계획 분석을 시작으로, 인덱스 설계, like_count 비정규화를 통한 구조 개선, 그리고 Redis 캐시 도입까지. 각 선택이 어떤 문제를 풀기 위한 것이었는지..
Programming/Technical Writing 2026. 3. 6. 동시성 제어: 트랜잭션 락은 언제 쓰는가 TL;DR 동시성 제어 — 락을 쓰기 전에 락이 필요한지부터 판단하자 이커머스 시스템에서 쿠폰 차감, 재고 감소, 좋아요 카운트 같은 기능을 만들다 보면 동시성 문제를 만나게 된다. 여러 요청이 같은 데이터를 동시에 수정하면 데이터 정합성이 깨질 수 있기 때문이다. 이 글에서는 동시성 문제를 해결하는 세 가지 접근 방식을 "언제 쓰는가" 중심으로 정리한다. 1. 아토믹 업데이트 vs Read-Modify-Write.2. 낙관적 락 vs 비관적 락3. 비관적 락: FOR UPDATE4. 마무리: 동시성 제어 판단 흐름 1. 아토믹 업데이트 vs Read-Modify-Write아토믹 업데이트SQL 한 문장으로 조건 판단과 갱신을 동시에 처리하는 방식이다. DB가 이 쿼리를 원자적으로 실행하므로 락이 필요 ..
Programming/Technical Writing 2026. 2. 27. 협업/분리/확장 관점에서 DIP 쓰는 법 TL;DR: DIP는 코드를 위한 원칙이 아니라 팀의 속도를 위한 전략이다. 레거시 코드베이스에서 가장 흔하게 마주하는 문제는 "동작하지 않는 코드"가 아니다. 코드는 정상적으로 동작한다. 진짜 문제는 그 이후에 드러난다. 기능 하나를 수정하면 예측하지 못한 지점에서 사이드이펙트가 발생하고, 새로운 요구사항이 들어올 때마다 확장이 아닌 리팩터링부터 논의해야 하며, 같은 Service 파일을 여러 명이 동시에 건드리면서 Git 충돌과 코드 리뷰 비용이 선형적으로 증가한다. 결국 팀의 배포 속도는 코드가 늘어날수록 느려진다. 이 현상의 근본 원인은 대부분 동일하다. 비즈니스 규칙(정책)과 기술적 구현(DB, 외부 API, 프레임워크)이 하나의 클래스 안에서 강하게 결합되어 있기 때문이다. 결제 로직을 수정하..
Programming/Technical Writing 2026. 2. 13. 주니어는 모르는 ERD 설계의 함정들 TL;DR: ERD는 ERD는 ‘데이터 구조’가 아니라 ‘변경 이력의 지도’다. ERD란 무엇일까? 주니어 개발자로서 프로젝트를 하면서 ERD를 설계하는 일은 사실 상사들의 몫이었다. 내가 설계를 하게 되니 ERD란 단순히 DB를 논리적으로 옮겨 둔 것뿐만이 아니라 개발의 토대라고 말할 수 있었다. 프로젝트의 성능이 달려 있고 비즈니스 모델의 중심을 정하는, 정렬을 우선으로 할지 정합성을 우선으로 할지 등을 판단해야 하는 일이었다. 주니어 단계에서는 ERD를 이렇게 본다. 엔티티가 맞는가? 관계가 자연스러운가? 정규화가 되어 있는가?시니어는 달라야 한다. 이 데이터는 언제 바뀌는가? 누가 바꾸는가? 왜 바뀌는가? 현재 요구사항을 만족하는 구조가 아니라, 미래 변경과 운영을 견디는 구조로 생각해야 한다...
Programming/Technical Writing 2026. 2. 5. AI로 테스트 코드를 짜기 전에, 내가 먼저 정리한 것들 TL;DR: 테스트 코드 프롬프트를 작성하기 위해서는 설계에 기반한 요구사항을 명확하게 정의해야 한다. 테스트 코드는 항상 뒤로 밀린다. 기능은 돌아가고, 일정은 촉박하고, 테스트는 나중에가 된다.Claude Code를 쓰기 시작했을 때, 처음엔 테스트 코드를 대신 써주는 도구로 기대했다. 그런데 몇 번 실패하고 나서 방향을 바꿨다. AI에게 코드를 맡기기 전에, 내가 먼저 생각을 정리하기로 했다. 0. 프롬프트를 잘 쓰는 게 아니라, 쪼개는 게 중요하다한 번에 다 물어보면 결과는 항상 비슷했다. 무엇보다 AI의 판단이 내 생각과 다르기도 했고, 구체적인 방향 제시가 어려웠다. 그래서 전략을 바꿨다.요구사항 재정의 > 테스트 코드 설계 및 검증 > 구현 요청위와 같이 프롬프트를 여러 단계로 쪼갰다. ..
Programming/회고 2025. 10. 27. AI Agent를 이용한 테스트 코드 경험 TN;DR: 테스트 코드와 Facade 패턴에 대한 초심자의 이해 1. 처음 접하는 테스트 코드(부끄럽게도!)나는 테스트 코드를 짜본 적이 없다. 테스트 코드의 필요성은 알고 있었지만 회사에서는 권장하지 않았기 때문이다. 그래서 과제를 받았을 때 이론부터 감을 잡아야 했다. 멘토님이 설명해 주신 다섯 가지의 테스트 객체(Dummy, Stub, Spy, Mock, Fake)는 나에게 너무 추상적이었다. 다 비슷비슷하게 보였다. 실제 사용해야 할 때 가장 적당한 것을 선택하기 힘들어 보였다. 그래서 일단 이들을 검색해서 닥치는 대로 예시를 읽었다. 아래는 내가 이해한 테스트 객체이다. Dummy는 가장 정적인 객체로 보았다. 빈 껍데기만 필요할 때 사용하기 좋은 것 같았다.Fake는 그보다는 조금 더 구체적..

티스토리툴바