미리보기 238초를 0.9초로 줄이기까지
2026.08 · 문답 6항 · 수치는 실측값 · 읽는 시간 약 3분
카페24 쇼핑몰 판매가 자동 갱신 앱을 만들며, 상품 336건의 가격 미리보기가 238초가 걸려 화면이 죽는 문제를 만났습니다. 추측으로 세 번 고쳐 전부 실패한 뒤, 카페24 공식 문서의 「초당 2건」 한 줄에서 답을 찾아 0.9초로 줄였습니다. 그 과정을 다섯 문답으로 적었습니다.
문 1.무엇이 문제였나요?
카페24 쇼핑몰의 판매가를 자동 갱신하는 앱을 만들며, 반영 전에 바뀔 가격을 미리 보여주는 화면을 두었습니다. 상품 40건에서는 멀쩡했는데, 실제 규모인 상품 336건짜리 몰을 만들어 재보니 미리보기 한 번에 238초가 걸렸습니다. 웹서버 제한 시간 60초를 훌쩍 넘겨, 화면에는 결과 대신 오류가 떴습니다.
238초 → 0.9초상품 336건 미리보기 — 같은 화면, 같은 서버문 2.왜 그렇게 느렸나요?
상품마다 카페24에 옵션 정보를 물어보고 있었기 때문입니다. 카페24가 외부 프로그램에 허용하는 요청은 통 하나에 40칸이고, 빈칸이 초당 2칸씩만 회복됩니다. 한도를 넘기면 30초를 기다리라는 응답이 옵니다 — 238초의 대부분은 계산이 아니라 이 30초짜리 대기가 쌓인 시간이었습니다.
문 3.어떻게 풀었나요?
속도를 올린 게 아니라 부르는 횟수를 줄였습니다. 초당 2건이면 336건은 어떻게 해도 168초 — 빠르게 부르는 길 자체가 없습니다. 대신 옵션 가격 규칙이 없는 상품은 옵션 정보를 쓸 일이 없다는 사실에 주목해, 규칙이 있는 상품만 물어보게 바꿨습니다. 호출이 336건에서 4건이 됐고, 238초가 0.9초가 됐습니다.
문 4.헛짚은 건 없었나요?
세 번 헛짚었습니다. 병렬로 부르기, 연결 재사용, 대기 시간 단축 — 전부 추측이었고 전부 효과가 없었습니다. 동시에 부르기는 오히려 1회용 출입증을 여러 요청이 한꺼번에 바꾸려다 사고까지 만들었습니다. 답은 코드가 아니라 카페24 공식 문서에 처음부터 적혀 있었습니다 — 「초당 2건」.
문 5.무엇을 배웠나요?
남의 시스템이 느리면 내 프로그램을 고치기 전에 그쪽의 규칙 문서부터 읽어야 한다는 것. 그리고 상품 40건에서 통과한 검증은 300건에서의 검증이 아니라는 것입니다. 지금은 규모 실측(실제 300건 생성)을 검증 절차에 넣어 두었습니다.
문 6.이게 손님께는 무슨 의미인가요?
자동화는 만드는 것보다 「상품이 늘어나도 안 죽게」 만드는 게 어렵습니다. 상품 40개일 때 멀쩡하던 것이 300개가 되면 멈추는 일이 실제로 일어납니다. 저희는 저희 몰에서 그 벽에 먼저 부딪히고 먼저 넘었습니다 — 그래서 상품이 몇백 개인 몰에서도 화면이 바로 뜨고, 규모가 커져도 멈추지 않는 자동화를 만들어 드릴 수 있습니다.