전체 글30 나를 피곤하게도, 단단하게도 만드는 성격 이 글을 쓰는 이유면접을 준비하다 보면 나를 설명해야 하는 순간이 온다.기술은 모르면 공부하면 되고, 프로젝트는 다시 정리하면 된다. 그런데 “본인의 성격은 어떤가요?”라는 질문은 조금 더 어렵다. 나를 좋게만 포장하고 싶지는 않았다. 그렇다고 단점만 말하고 싶지도 않았다. 내 성격은 나를 피곤하게 만들기도 했지만, 동시에 지금의 나를 버티게 만든 힘이기도 했기 때문이다. 그래서 이 글은 내가 어떤 사람인지 조금 솔직하게 정리해보려는 글이다.나는 꽤 피곤한 사람이다. 나는 기준을 쉽게 넘기지 못하는 사람이다.정해진 규칙이 있으면 쉽게 깨지 못하고, 약속이 있으면 조금 일찍 도착해야 마음이 놓인다. 사람과 대화한 뒤에도 생각이 오래 남는다. 내 말이 이상하게 들리지는 않았을까, 내 의도와 다르게 받아들인.. 2026. 4. 28. [Point-live-young (9)] 복합 인덱스를 도입했지만 성능은 더 나빠졌다 https://github.com/f-lab-edu/point-live-young/blob/main/decisions/ADR-014%20%EC%83%81%ED%92%88%20%EA%B2%80%EC%83%89%20API%20%ED%95%84%ED%84%B0%EB%A7%81%20%EC%84%B1%EB%8A%A5%20%EA%B0%9C%EC%84%A0%EC%9D%84%20%EC%9C%84%ED%95%9C%20%EB%B3%B5%ED%95%A9%20%EC%9D%B8%EB%8D%B1%EC%8A%A4%20%EB%8F%84%EC%9E%85%20%EA%B2%80%ED%86%A0.md point-live-young/decisions/ADR-014 상품 검색 API 필터링 성능 개선을 위한 복합 인덱스 도입 검토.md at .. 2026. 3. 30. [Point-live-young (8)] 상품 검색 성능 개선 – LIKE에서 Full-Text Index로 https://github.com/f-lab-edu/point-live-young/blob/main/decisions/ADR-013%20%EC%83%81%ED%92%88%20%EA%B2%80%EC%83%89%20API%20%EC%B5%9C%EC%A0%81%ED%99%94%EB%A5%BC%20%EC%9C%84%ED%95%9C%20Full-Text%20Index%20%EB%8F%84%EC%9E%85.md point-live-young/decisions/ADR-013 상품 검색 API 최적화를 위한 Full-Text Index 도입.md at main · f-lab-edu/point-li대규모 사용자와 대용량 트래픽을 안정적으로 처리하는 포인트 기반 이커머스. Contribute to f-lab-edu/poi.. 2026. 3. 29. [Point-live-young (7)] 생일 포인트 지급 재시도 전략 2 - 실패해도 안전하게 https://github.com/f-lab-edu/point-live-young/blob/main/decisions/ADR-011%20%EC%8A%A4%EC%BC%80%EC%A4%84%EB%A7%81%20%EC%83%9D%EC%9D%BC%20%ED%8F%AC%EC%9D%B8%ED%8A%B8%20%EC%A7%80%EA%B8%89%20%EC%9E%AC%EC%8B%9C%EB%8F%84(Retry)%20%EC%A0%84%EB%9E%B5.md?plain=1 point-live-young/decisions/ADR-011 스케줄링 생일 포인트 지급 재시도(Retry) 전략.md at main · f-lab-edu/point-li대규모 사용자와 대용량 트래픽을 안정적으로 처리하는 포인트 기반 이커머스. Contrib.. 2026. 2. 21. [Point-live-young (6)] 생일 포인트 지급 재시도 전략 1 – 멱등성으로 중복을 막다 이 전 글의 주문은 사용자가 트리거하는 동기 요청이다.하지만 생일 포인트 지급은 다르다. 사용자가 요청하지 않는다.정해진 시점에 자동으로 실행된다.실패해도 눈에 잘 띄지 않는다.하지만 누락되거나 중복 지급되면 신뢰 문제가 된다.이 글의 질문은 이것이다.생일 포인트는 실패해도 반드시 지급되엉야 한다.하지만 절대로 두 번 지급되면 안 된다.어떻게 보장할 것인가? 재시도는 필수다스케줄러는 언제든 실패할 수 있다. DB 연결 오류특정 사용자 처리 중 예외서버 재시작배포 중 트랜잭션 롤백 예를 들어, 오늘 생일인 사용자가 100명이고40번째 사용자 처리 중 예외가 발생했다면: 앞의 39명은 지급 완료나머지는 미지급 이 상태에서 다시 실행하지 않으면일부 사용자는 영원히 생일 포인트를 받지 못한다. 그래서 재시도는 .. 2026. 2. 21. [Point-live-young (5)] 주문 흐름 전체 아키텍처 – 포인트, 재고, 트랜잭션을 어떻게 분리했는가 (1)~(4)편에서는 포인트 도메인, 차감 정책, 재고 동시성, 만료 전략을 각각 다뤘다.이번 글에서는 그 모든 선택이 하나의 주문 요청 안에서 어떻게 연결되는지,즉 주문 흐름 전체 아키텍처를 정리해보려고 한다. 이 글의 질문은 이것이다.포인트 차감과 재고 차감은 어디까지 하나의 책임인가?그리고 트랜잭션은 어디에서 끊어야 하는가? 주문 흐름을 단순화하면 안되는 이유주문 기능을 단순하게 표현하면 아래와 같다.포인트 충분한지 확인재고 확인포인트 차감재고 차감주문 생성하지만 실제 구현에서는 이 순서가 그대로 코드가 되면 위험하다.중간 단계에서 실패하면?동시 요청이 들어오면?포인트는 차감됐는데 재고가 실패하면?재고는 줄었는데 주문 생성이 실패하면?다시 말해서 주문은 "성공" 아니면 "아무 일도 없었던 상태"여야.. 2026. 2. 21. 이전 1 2 3 4 5 다음
