kimong 님의 블로그

https://www.loopers.im/ Loop:PAK - 새로운 코딩 교육의 시작, 루퍼스에서 곧 만나요!루퍼스 부트캠프는 크루원들의 한단계 높은 성장을 이끄는 선순환을 목표로 현업 개발자와 협업하여 새롭게 탄생한 실전 개발 강의입니다. 열정있는 여러분에게, 진심을 다하는 루퍼스가, 진짜www.loopers.im 나의 루퍼스 부트캠프 백엔드 신청 계기현재 재직 중인 회사는 팀 규모가 작고 서비스 트래픽이 안정적인 편이다. 개발자로서 평온한 일상도 좋지만, 마음 한편에는 늘 ‘이대로 괜찮을까?’ 하는 막연한 불안감이 있었다. 실무에서 다룰 수 있는 기술적 범위가 제한적이다 보니, 대규모 트래픽 설계나 복잡한 장애 대응 같은 ‘진짜 백엔드’의 고민을 해볼 기회가 적었기 때문이다.이런 기술적 갈증을 ..

1주차 — 테스트 코드 & TDDTDD를 배우기 위해 돈까지 냈던 적이 있다. 그러면서도 막상 TDD를 즐겨 쓴 적은 없었다. 회사에서 테스트 문화를 만들어보려고 시도도 해봤지만 흐지부지됐다. 인식의 벽은 생각보다 두꺼웠고, 내가 그 벽을 깰 능력조차 당시에는 없었다. 그런데 AI가 등장하면서 분위기가 조금 바뀐 것 같다. 반복적이고 귀찮은 테스트 코드 작성을 AI가 상당 부분 대신해주니, 진입 장벽이 낮아졌다. 덕분에 이번 주차는 예전보다 훨씬 편하게 테스트를 먼저 써볼 수 있었다. 그리고 막상 과제를 하면서 테스트를 먼저 쓰는 게 단순히 순서 문제가 아니라는 걸 다시 한번 느꼈다. 구현보다 먼저 어떻게 동작해야 하는가를 정의하다 보면, 설계가 얼마나 테스트하기 어렵게 짜여졌는지가 바로 드러난다. 의존..

이번 과제 요구사항에 인기 상품 랭킹 만들기 라는 요구사항이 있었다 처음에는 공식부터 고르면 되는 줄 알았다. 그래서 주문된 상품 갯수를 기준으로 사용할지, 매출을 사용할지 , 합쳐서 사용할지 정하기만 하면 끝이라고 생각했다.그런데 같은 데이터를 넣어보니 공식마다 1위가 달랐다. 볼펜이 1위가 되기도 했고, 명품백이 1위가 되기도 했다. 멘토링 시간에도 인기라는 정의를 우선하고 코드를 구현하는 것이다 라는 멘토님의 조언처럼랭킹 공식은 먼저 고르는 것이 아니었다. 우리 서비스에서 인기를 무엇으로 볼지 정해야 공식도 정할 수 있었다. 1. 세 가지 인기의 정의 공식을 고르기 전에 먼저 정의부터 나누고, 실험을 했다.실제 내 프로젝트에서는 세 가지 이벤트가 랭킹 점수에 기여하는데, 주문 이벤트의 weight는..

트래픽이 몰리는 순간 모든 사용자의 요청을 한 번에 처리하려고 하면, 애플리케이션과 DB가 순간 부하를 감당하지 못할 수 있다.이럴 때는 모든 요청을 즉시 처리하기보다, 일정 수만 먼저 통과시키고 나머지는 대기시키는 방식이 더 안전하다. 대기열은 이런 상황에서 사용자에게 순번을 부여하고, 자신의 차례가 되었을 때만 다음 단계로 진입시키는 구조다.문제는 여기서 끝나지 않는다. 대기열에 들어온 사용자는 이제 궁금해진다. **“내가 지금 몇 번째인지”**를 어떻게 보여줄 것인가. 후보는 크게 세 가지다. Polling, Long Polling, SSE.지연만 보면 Long Polling과 SSE가 더 좋아 보인다. 하지만 이 프로젝트에서는 Polling이 더 적절했다. 이 글에서는 세 가지 방식을 비교한 뒤,..

1. 개요외부 시스템이 들어오면 성공의 기준부터 흔들린다.루퍼스에서 PG 연동 과제를 진행하면서 가장 먼저 부딪힌 것도 그 문제였다. 요청을 보냈다는 사실과 상태가 실제로 확정되었다는 사실은 다를 수 있기 때문이다. 재밌게도 이 질문은, 실제로 이번 주 회사에서 회원 탈퇴 설계를 논의하면서 다시 돌아왔다. (아쉽게도 결론이 나진 않았다...)도메인은 다르지만 질문은 같았다. 우리 시스템 안의 작업이 끝났다는 사실만으로 정말 성공이라고 말할 수 있는가.더보기 ▎(루퍼스 부트캠프 과제와 관련된 내용입니다, 읽지 않아도 무방)pg-simulator 연동에서 이 질문은 구체적인 형태로 나타났다. requestPayment()가 정상 응답을 받았다고 해서 결제가 완료된 것이 아니다. pg-simulator가 콜백..

0. 개요부트캠프에서 최근 상품 목록 API의 성능을 DB 인덱스로 최적화하는 과제가 있었다. 처음에는 인덱스를 그저 “조회 성능을 높이는 옵션” 정도로 생각했다. 조건절에 맞는 컬럼에 인덱스를 걸면 쿼리가 빨라진다고 이해했다. 그러다 인덱스를 공부하던 중 지인분이 작성한 캐시는 아이디어의 반복이라는 글을 읽게 됐다. CPU 캐시부터 Redis까지, 결국 느린 원본에 매번 직접 접근하지 않기 위해 더 가볍고 다루기 쉬운 구조를 따로 둔다는 내용이었다. 이 글을 읽고 나니 내가 테스트하던 인덱스도 비슷한 관점에서 볼 수 있겠다는 생각이 들었다. 물론 인덱스는 캐시가 아니다. 캐시처럼 임시 저장소에 가깝지도 않고, 결과값 자체를 재사용하는 구조도 아니다. 다만 원본 전체를 반복해서 읽지 않기 위해 별도의 구..

0. 개요그동안 동시성 이슈를 마주하면 단순히 낙관적락이나 비관적락을 활용해서 해결하면 되겠지?라고 막연하게 생각했다. 하지만 프로젝트를 진행할수록 문제의 성격을 파악하지 못한 해결책은 근거가 빈약하다는 것을 알게 되었다. 이 글에서는 '좋아요' 기능을 구현하며 마주친 동시성 문제를 어떤 근거로 해결했는지 기록하고자 한다. 1. 동시성, 다 똑같은 게 아니다동시성 문제는 성격에 따라 해결 방법이 달라진다. 현재 프로젝트에서 발생할 수 있는 케이스는 크게 3가지 정도가 있었다구분좋아요 (카운터)쿠폰 (Exactly-once)재고 (리소스 일관성)문제 성격수치의 정확성단 한 번만 실행리소스 일관성비즈니스 규칙여러번 증가해도 OK, 정확해야함한번만 사용되어야함재고가 음수가 되면 안됨데이터 특성누적 가능상태 변..