이직 후 영혼을 갈아넣으며 새로운 서비스 런칭 준비를 하는 나의 모습(지피티 이미지 잘만드네.. ㅋㅅㅋ 근데 한글 깨지는게 넘많음..) 버그 리포트는 한 줄이었다. "부품 지우고 새로고침했는데 다시 생겨요."웹 앱 안에 Unity WebGL로 만든 3D 조립 시뮬레이터를 띄워놓고 쓰는 서비스를 만들고 있다. 사용자가 화면에서 부품을 놓고, 붙이고, 옮긴다. 그 결과는 프로젝트에 저장되고 다시 열면 복원된다.그런데 어떤 오브젝트는 지워도 안 지워졌다. 정확히는, 지운 직후에는 사라지는데 새로고침하면 그 자리에 다시 있었다. 원인을 따라가다 보니 결국 "웹과 게임 엔진 사이에서 상태를 어디에 두느냐"라는 꽤 근본적인 문제였다. 고치는 데 파일 60개쯤을 건드렸다..🥲웹과 씬은 어떻게 대화할까..?우리 앱에..
선착순 신청 시스템은 트래픽이 평탄하지 않다. 평소엔 한산하다가 접수 시작 시각에 수백 명이 동시에 로그인하고 신청한다.k6로 500 VU 부하를 걸었더니 에러율은 0.00%인데 로그인 p50이 2초를 넘었다.범인은 bcrypt였다. SALT_ROUNDS를 10에서 8로 낮추자 로그인 p50이 1,460ms에서 26ms로 떨어졌다. 산술상 4배인데 체감은 56배였다.신청 API는 별개 문제였다. 상품 35개를 한 번에 신청하면 쿼리가 112개 나가서 p95가 12.8초였다. 배치 쿼리와 트랜잭션 래핑으로 쿼리를 11개까지 줄였다.배경 | 왜 부하테스트가 필요했나이 시스템의 트래픽은 일정하지 않다. 신청은 정해진 접수 시작 시각이 있고, 자리가 한정돼 있다. 그래서 접수가 열리는 순간에 사용자가 몰린다. ..
전국 17개 시도의 공공데이터를 데이터베이스에 적재해야 했다. 공시지가와 실거래가만 수억 건이었다. 처음 짠 코드는 한 건씩 INSERT하면서 한 건씩 중복을 확인했다. DB 왕복이 데이터 건수만큼 일어났고, 추정 소요 시간은 마감을 한참 넘겼다....🫠원인을 먼저 봤다. 느린 건 INSERT 자체가 아니라 그 주변의 SELECT였다. 두 가지로 나눠 풀었다.- 공시지가 : 건별 INSERT를 JDBC 배치 INSERT로 바꾸고, 중복 확인 SELECT는 ON CONFLICT DO NOTHING으로 없앴다. 외래키 조회도 건별에서 배치 단위 벌크 조회로 변경했다.- 실거래가 : 원본 CSV를 임시 테이블에 COPY로 싹 적재하고, SQL 한 번으로 가공·중복 제거해서 본 테이블에 넣었다.- 멀티 서버..
이번 ERP는 물건을 직접 움직이지 않는다. 재고는 외부 창고에 있고, 창고의 WMS가 입출고를 처리한다. ERP는 그 숫자를 가져다 보여줄 뿐이다.문제를 더 꼬는 건 판매 경로다. B2C 주문 상당수가 채널 → OMS → WMS로 흘러 ERP를 거치지 않고 출고된다. ERP는 그 출고를 사후에 매출 엑셀로 기록할 뿐, 실시간으로 알지 못한다.그래서 출발점이 분명했다. ERP가 자력으로 재고를 정확히 유지하는 건 구조적으로 불가능하다. WMS에서 가져와야만 맞는 숫자가 된다.그런데 클라이언트 요구가 정반대 방향을 가리켰다. - 출고를 ERP에서 처리하면 재고 현황이 즉시 줄어야 한다. "출고했는데 화면이 안 바뀌면 ERP를 쓸 이유가 없다."- 동시에 재고 리스트와 수량은 WMS 값으로 정확히 유지돼야 ..
프론트엔드 프로젝트를 진행하기에 앞서 규모가 크고, 정말 중요한 프로젝트라초기 세팅 및 보안, 협업 관련해 고민해 보고, 도움이 될 것 같은 항목들 셋업 내용 정리...🧑💻 1. 코드 품질은 사람의 의지보다는 도구로 강제2. 공급망 공격 같은 외부 위협 고려기술 스택은 아래와 같다.Vite 7 + React 19 + TypeScript 5 + TanStack Router/Query + Tailwind v4 + shadcn/ui + Zod + React Hook Form + Recharts 1. pnpm 공급망 격리 : 'minimum-release-age'2024년부터 npm 패키지를 통한 공급망 공격이 눈에 띄게 늘었다. nx 빌드 산출물에 악성 코드가 박힌 사건, polyfill.io 도메인 인..
사내 시스템 설계에 들어가면서 캐시·작업 큐 인프라로 자연스럽게 Redis 를 후보에 올렸다. 그런데 막상 라이센스 검토 단계로 가니 "Redis 라고 쓰면 안 되는 거 아니냐" 는 이야기가 나왔다.Redis 가 BSD 가 아니게 된 시점2024년 3월, Redis Inc. 는 Redis 7.4 부터 BSD 3-Clause 라이센스를 폐기한다고 발표했다. 새 라이센스는 두 가지 중 하나를 고르는 듀얼 라이센스다. - RSALv2 (Redis Source Available License v2): 소스는 공개되어 있고 내부 사용·수정도 가능하다. 다만 Redis 자체를 "as a service" 로 제공하는 행위를 금지한다. AWS ElastiCache 같은 호스팅형 서비스가 직접 타깃이었다. - S..