개발.. 한놈만 팬다

`@Transactional`로 묶었다고 동시성이 해결되는 건 아니다. 그건 원자성(A) 얘기지 격리성(I) 얘기가 아니다. 재고 5개짜리 상품에 10명이 동시에 주문을 넣는 상황을 따라가며 비관적 락, 낙관적 락, 그리고 "사실 읽을 필요도 없는" 원자적 UPDATE까지 저울질한 기록. 시작은 단순한 착각이었다주문 로직을 짜면서 처음엔 이렇게 생각했다."재고 차감이랑 주문 생성을 @Transacional 로 묶었으니, 동시에 주문이 들어와도 알아서 잘 처리하겠지 트랜잭션이 ACID 를 보장하니깐 동시성도 트랜잭션이 잘 막아줄 것이라고 막연히 믿었다.혼자 주문할 땐 이 믿음이 안깨진다.읽고 -> 확인하고 -> 줄이고 -> 커밋 읽기와 쓰기가 딱 붙어 있어서 문제가 생길 틈이 안보인다. 검증할 상황 자체..

강의 목록 API 하나를 "추측 대신 측정"으로 파고들어캐싱 → 구조 개선 → 메모리까지 잡은 기록.Stack: Node.js · TypeScript · TypeORM(MySQL) · Redis · Vitest 한눈에 보기지표BeforeAfter변화응답 시간(대형 케이스)9.5 s0.27 s🟢 −97%외부 인기도 API7,000 ms20 ms (캐시 히트)🟢 −99.7%요청당 객체 메모리3,560 KB53 KB🟢 −98.5%조립 객체 수1,652개20개🟢 −98.8%응답 20건을 주는 API가 매번 1,652건을 다 만들고 있었다. → 20건만 만들도록 바꾼 이야기. 개선 여정 (요약) 1. 측정부터 — 구간별 타이밍const mark = (label) => { marks[label] = now..

멈춘 코드브랜드 도메인을 만들고 있었다. 요구사항은 단순했다"어드민이 브랜드를 등록할 때, 동일한 이름의 soft-deleted 행이 있으면 새 INSERT 대신 그 행을 복구(restore)하라."설계 문서는 이 로직을 BrandAdminFacade.create 에 두라고 했다. 그대로 옮기다가 손이 멈췄다. // BrandAdminFacade.create()fun create(name: String): BrandInfo { val existing = brandRepository.findByName(name) // ← 왜 Facade 가 이걸 알지? return when { existing == null -> save(BrandModel(name)) ex..

언젠가 만들고 싶다고 생각만 하던 도구가 있었다.회사에서 반복적으로 마주치는 불편함을 해결할 화면이 있으면 좋겠다고 자주 생각했지만, 막상 시작하려고 하면 데이터, 기준, 화면 구성이 한꺼번에 떠올라 쉽게 손이 가지 않았다. 이번에는 달랐다.AI가 있어서 시작할 수 있었다. 문제의식과 업무 맥락을 설명하면 AI가 기능을 나누고 구현 순서를 잡는 데 도움을 줬다.그렇게 머릿속에만 있던 내부 도구를 움직이는 웹앱으로 만들 수 있었다.그 결과물이 Observatory다. 아래 앱 화면 캡처는 외부 공개를 위해 실제 수치, 개인 식별 정보, 랭킹/테이블 데이터 영역을 블러 처리했다.왜 만들었나우리 회사는 교육 콘텐츠를 다루고 있고, 수강생의 시청 기록은 여러 시스템에 쌓인다.운영성 데이터는 RDB에, 날짜별..

좋아요 등록·취소는 단순한 INSERT/DELETE 같지만, 멱등성을 제대로 보장하려면 다섯 개의 결정을 거친다. DB unique 제약과 hard delete 같은 결정들이 한 트랜잭션 안에서 도메인 정합성을 어떻게 만드는지 정리한다. 1. POST /products/{id}/likes 한 줄에서 시작좋아요는 처음 봤을 때 단순한 기능이었다. 명세상 엔드포인트는 세 개뿐이다. (user_id, product_id) 한 행을 INSERT 하거나 DELETE 하는 일이다.그런데도 설계 문서를 쓰는 동안 결정해야 했던 것이 다섯이었다.멱등성, 좋아요 수의 위치, soft delete 와 unique 의 충돌, BaseEntity 상속 여부, 그리고 그 모두를 묶는 hard delete 결단.이 글은 그 다..

루프팩 첫 주, 회원 도메인 세 가지를 TDD로 구현했다. 잘한 것보다 어색했던 게 더 많아서, 일단 기록부터 남긴다. TDD를 막 시작한 사람, 도메인 검증을 어디 둘지 고민하는 사람에게 참고가 될지도.(Red 실패하는 테스트 Green 최소 구현 Refactor 코드 정리 다음 사이클)이번 주에 한 일3개의 유스케이스를 TDD 사이클 한 바퀴씩 돌렸다.회원가입 POST /api/v1/users내 정보 조회 GET /api/v1/users/me (이름 마지막 글자 * 마스킹)비밀번호 수정 PATCH /api/v1/users/me/password각 기능은 test → feat → refactor 세 커밋으로 끊어서, 한 사이클이 어디서 끝나는지 git 그래프만 봐도 보이도록 했다. 가장 곱씹었던 결정 ..

Mock API를 우선 제공해야 하는 필요성에 대한 이해Mock API는 데이터베이스 연결이나 백엔드 처리 없이 정적 응답만 제공합니다. 테스트 및 개발용: 실제 API가 준비되지 않았거나 불완전하거나 불안정한 경우 사용 https://velog.io/@khy226/msw로-모의-서버-만들기 MSW(Mock Service Worker)로 더욱 생산적인 FE 개발하기MSW(Mock Service Worker)는 Service Worker를 이용해 서버를 향한 실제 네트워크 요청을 가로채서(intercept) 모의 응답 (Mocked response)를 보내주는 API Mocking 라이브러리이다.velog.iohttps://techblog.woowahan.com/20154/ API 모킹으로 테스트를 더 편..

10주간 항해를 마치고 부족한 부분을 다시 공부하고자 항해 그 후 스터디에 참여를 하여 스터디를 진행을 하였습니다.스터디를 진행을 하면서 개인적으로 공부를 했던것을 기록하려고 합니다. 해당 내용은 항해에서 배웠던 10주간 챕터들 중에서 항해하면서 부족하고 추가로 공부할 필요가 있는 것을 키워드 별로 공부를 진행 했습니다. 런던파와 고전파에 대한 이해와 본인의 견해 수립런턴파와 고전파의 가장 큰 차이는 테스트에서의 격리(isolation)를 어떻게 정의하고 구현하느냐이다.런던파런던파는 테스트 대상 코드가 다른 객체/클래스에 의존할 경우, 이 의존성을 모두 테스트 대역(test double) 으로 대체해야 한다고 본다.테스트 대역은 실제 객체 대신 사용하는 ‘단순화된 대체’ 객체로, 복잡성을 줄이고 테스트를..

pub/sub 로직 개선했던 서비스에서 간단하게 배경 설명을 한다면,, 수강신청이라는 서비스가 있다. b2e 화면에서 수강생들이 수강신청을 진행을 하면 backoffice 에서 관리자가 해당 상품에 대해서 수강신청 확정 버튼을 클릭해 수강생들이 신청한 강의들을 확정처리하여 강의를 들을 수 있게 하는 서비스가 있다. 이 서비스는 처음에 batch 로 작업이 진행이 되었다.batch 로 1시간에 한번씩 작업이 진행이 되었다. 하지만 이 서비스의 확정 처리 기능은 빈번하게 발생하는 작업이 아니였고 비정기적으로 진행이 되는 작업이였다.비정기적으로 작업이 되는 서비스에 batch 는 과한 스펙이 되었다. 그래서 이 확정처리 기능은 batch 에서 pub/sub 으로 변경이 되었다.pub/sub 은 이렇게 구현을 ..

사내 서비스를 이용하던 중 전체 강의 화면에서 화면 로딩이 2~3초가 걸려서 원인이 궁금했다.화면 로딩이 2~3 초면 사용자가 이용하기에 화면 로딩이 너무 느리다고 체감이 되고, 서비스 사용하기에 불편함을 느낄것 같았다.그래서 이것을 개선해보기로 했다!  전체 강의 보기 화면에서 호출되는 api 를 파악하고 제일 응답 속도가 느린 api 를 확인해보았다.제일 응답 속도가 느린 api 는 filters 였고 이 api 응답값을 통해서 프론트에서 화면을 뿌려주고 있었다. filters API 구조를 확인을 해보자!server to server 통신을 하고 있고, 내부에서 많은 연산이 진행이 되고 있었다.  여기서 연산이 가장 오래 걸리는 것을 파악하기 위해서 console.time(), console.tim..