-
성능 좋다는 그 모델, 우리한테도 좋을까
성능 좋다는 그 모델, 우리한테도 좋을까"이번엔 진짜 다르다던데요?"새 모델이 나올 때의 흐름은 다음과 같다. 벤치마크 표가 돌고, "이번엔 진짜 다르다"는 후기가 올라오고, 며칠 안에 다들 그 모델로 옮겨 간다. 나도 따라 옮긴다. 안 옮기면 뒤처지는 기분이 들어서다. 흔히 말하는 AI 포모(FOMO)다. 그런데 옮기고 나면 매번 같은 생각이 들었다."진짜 성능이 좋은 건가? 우리한테도 좋은 건가?" Fable이 나왔을 때 처음 의심이 생겼다. 개인적으로는 Opus와 큰 차이를 못 느꼈다. 하지만 확실히 느낀 건 토큰이 훨씬 빨리 닳는다는 것이었다. 내 도메인이 푸는 문제가 쉬워서 차이가 안 났을 수도 있다. 어려운 문제에서는 다를지도 모른다. 그런데 그걸 모른다는 게 문제였다. 차이가 없는 건지, 내..
-
운송장에 옵션이 안 보이는데요? - hard delete의 대가
"옵션 두 개 시켰는데 한 종류만 두 개 왔어요"과일 매장의 택배 시스템 운영 흐름은 다음과 같다.고객이 온라인으로 상품과 옵션(예: 사과 1kg / 사과 2kg)을 골라 결제하면,매장은 운송장을 출력해 박스를 포장하고 택배사에 넘긴다. 언제부턴가 CS 채널에 비슷한 클레임이 줄줄이 올라오기 시작했다."한 상품에서 1kg, 2kg 두 옵션을 시켰는데 1kg 두 개로 왔어요." 처음엔 매장에서 상품을 잘못 담은 단순 실수로 가볍게 봤다.그런데 같은 패턴의 클레임이 며칠 사이 적지 않게 쌓였다.여러 주문이 비슷한 모양으로 어긋나 있다는 게 분명해졌고, 그제야 시스템 쪽을 의심하기 시작했다. 결론부터 말하자면 이 문제는 옵션 삭제 정책을 hard delete에서 soft delete로 바꾸는 것으로 마무리됐다..
-
한번 더 고민하기 - 주니어의 확장성 회고
TL;DR주니어가 확장성 있는 설계에 다가서는 가장 단순한 방법은, 구현 직전에 한번 더 스스로에게 되묻는 습관이다.랭킹에서는 "이 데이터가 정말 일회성인가" 를, 매출 집계에서는 "같은 데이터를 읽는 경로를 몇 개로 둘 것인가" 를 묻지 않아 흔들렸다.AI 가 구현 비용을 덜어준 지금 그 시간을 구현 전의 고민에 옮겨 쓸 수 있는 시대다.두 경험에서 얻은 구현 전 사전질문 세 가지이 데이터는 정말 일회성인가, 아니면 재활용 가능한가?누군가 이 기능을 확장한다면, 지금의 구조가 그 방향을 막지는 않는가?이 코드를 처음 읽는 동료가 몇 번이나 멈추게 될까?주니어로 개발을 하다 보면 가장 많이 고민하는 건 아래와 같다."이 코드 동작하나?" 일정이 붙고, 요구사항이 쏟아지고, 구현해야 할 기능이 쌓이는 와중..
-
실시간 랭킹은 없다
우리가 보는 순위는 이미 과거다 "30분 전"무신사를 열었다. 실시간 랭킹 탭에 "30분 전", "16분 전" 같은 표기가 붙어 있었다.오늘의집도 마찬가지였다. "2026.04.10 04:56 기준"이라고 적혀 있다. "실시간"이라는 단어를 쓰면서 왜 갱신 시점을 명시할까. 지금 이 순간의 데이터가 아니라는 뜻 아닌가."실시간"이라고 적혀 있는 랭킹이 정말 지금 이 순간의 데이터일까? 아니다. 그리고 이건 버그가 아니라 설계다. 커머스 프로젝트를 공부하고 Redis Sorted Set 기반 랭킹 시스템을 구현하면서 이 사실을 체감했다.DB로 충분할 거라고 생각했던 초기 판단이 부하 테스트에서 어떻게 깨졌는지,그리고 왜 빅테크가 준실시간이라는 선택지를 가져가는지를 정리해보겠다.DB로 충분하지 않을까처음엔 ..
인기글 + 내용
-
인덱스를 걸었는데 왜 느릴까기타 2026.03.13 17:45
MySQL(InnoDB)에서 점검할 것들이전까지는 상품 조회 성능을 높이기 위해 어떤 캐시를 둘지, 어떤 인덱스가 필요한지 하나씩 살펴봤다. 이번 글에서는 그중에서도 가장 기본이 되는 세 가지, index, optimizer, query plan을 정리해보려 한다. 조회 성능 이야기를 할 때 보통 가장 먼저 나오는 해법은 인덱스다.다만 실무에서는 인덱스를 추가했다고 해서 바로 해결되지 않는 경우도 자주 만난다. 인덱스는 있는데 full scan이 나오기도 하고,인덱스를 타는데도 Using filesort 때문에 느리기도 하고,실행 계획은 괜찮아 보이는데 실제 부하에서는 응답 시간이 기대만큼 줄지 않기도 한다. 처음 조회 성능 문제가 있을때는 인덱스가 있는지만 확인했다.하지만 인덱스가 있어도 느린 경우가 ..
-
성능 좋다는 그 모델, 우리한테도 좋을까개발 2026.10.14 01:00
성능 좋다는 그 모델, 우리한테도 좋을까"이번엔 진짜 다르다던데요?"새 모델이 나올 때의 흐름은 다음과 같다. 벤치마크 표가 돌고, "이번엔 진짜 다르다"는 후기가 올라오고, 며칠 안에 다들 그 모델로 옮겨 간다. 나도 따라 옮긴다. 안 옮기면 뒤처지는 기분이 들어서다. 흔히 말하는 AI 포모(FOMO)다. 그런데 옮기고 나면 매번 같은 생각이 들었다."진짜 성능이 좋은 건가? 우리한테도 좋은 건가?" Fable이 나왔을 때 처음 의심이 생겼다. 개인적으로는 Opus와 큰 차이를 못 느꼈다. 하지만 확실히 느낀 건 토큰이 훨씬 빨리 닳는다는 것이었다. 내 도메인이 푸는 문제가 쉬워서 차이가 안 났을 수도 있다. 어려운 문제에서는 다를지도 모른다. 그런데 그걸 모른다는 게 문제였다. 차이가 없는 건지, 내..
-
운송장에 옵션이 안 보이는데요? - hard delete의 대가프로젝트 - 과일맛집 2026.05.03 17:47
"옵션 두 개 시켰는데 한 종류만 두 개 왔어요"과일 매장의 택배 시스템 운영 흐름은 다음과 같다.고객이 온라인으로 상품과 옵션(예: 사과 1kg / 사과 2kg)을 골라 결제하면,매장은 운송장을 출력해 박스를 포장하고 택배사에 넘긴다. 언제부턴가 CS 채널에 비슷한 클레임이 줄줄이 올라오기 시작했다."한 상품에서 1kg, 2kg 두 옵션을 시켰는데 1kg 두 개로 왔어요." 처음엔 매장에서 상품을 잘못 담은 단순 실수로 가볍게 봤다.그런데 같은 패턴의 클레임이 며칠 사이 적지 않게 쌓였다.여러 주문이 비슷한 모양으로 어긋나 있다는 게 분명해졌고, 그제야 시스템 쪽을 의심하기 시작했다. 결론부터 말하자면 이 문제는 옵션 삭제 정책을 hard delete에서 soft delete로 바꾸는 것으로 마무리됐다..