서비스를 운영하다 보면 꼭 마주치는 문제들이 있어요. "왜 요청이 막히지?", "왜 갑자기 느려지지?" 오늘은 이런 문제를 해결하는 핵심 개념들 — CORS, 스케일링, 캐시를 편하게 정리해볼게요.
CORS — 다른 주소끼리 대화하게 해주는 규칙
**CORS(Cross Origin Resource Sharing)**는 주소가 다른 요청자랑 제공자끼리 통신이 되게 해주는 규칙이에요.
예를 들어 a.com에서 실행되는 프론트엔드가 b.com에 있는 백엔드 API를 호출하려고 하면, 브라우저는 기본적으로 "어? 다른 주소인데?"라면서 막아버려요. 이때 CORS 설정을 해줘야 이 둘이 정상적으로 통신할 수 있게 돼요. 프론트엔드랑 백엔드를 따로 개발할 때 자주 마주치는 이슈라서 꼭 알아두면 좋아요.
브라우저 캐시 — 매번 새로 안 받아와도 되게
브라우저 캐시는 HTML, CSS 같은 정적 콘텐츠들을 브라우저가 일정 기간 동안 저장해뒀다가 재사용하는 걸 말해요. 매번 서버에서 새로 받아오지 않아도 되니까 훨씬 빨라지겠죠?
이런 캐시 처리에는 앞서 다뤘던 Redis나 Memcached 같은 Memory DB가 사용자 쪽(클라이언트 근처)에서 많이 활용돼요.
스케일링 — 왜 필요할까?
스케일링이 필요한 이유는 크게 두 가지예요.
- 비용 최적화: 트래픽이 적을 땐 서버를 줄이고, 많을 땐 늘려서 비용을 아껴요.
- Service Always (항상 서비스되게 하기): 부하가 몰려도 서비스가 끊기지 않게 하려고요.
결국 스케일링이란 서버의 리소스나 개수를 조절하는 것을 말해요.
수평 스케일링 (Horizontal Scaling)
서버의 수를 조절하는 방식이에요.
- Scale in: 서버 수를 줄이는 것
- Scale out: 서버 수를 늘리는 것
수직 스케일링 (Vertical Scaling)
서버의 리소스를 조절하는 방식이에요.
- Scale up: CPU나 Memory를 올리는 것
- Scale down: CPU나 Memory를 내리는 것
참고로 서버 리소스는 보통 이렇게 측정해요.
- CPU(Central Processing Unit): 중앙 처리 장치, 단위는 core
- Memory: 단위는 GB
서비스는 왜 느려질까?
느려지는 원인을 몇 가지로 나눠볼 수 있어요.
1. 프론트엔드와 백엔드 사이가 느려질 때
백엔드 애플리케이션이 보통 thread 방식으로 개발되어 있는데, 이 thread 수를 초과하는 요청이 들어오면 뒤에 들어온 요청들은 대기해야 해요. 이 문제를 극복하기 위해 reactive 개발 방식을 쓰기도 해요.
2. 백엔드와 DB 사이가 느려질 때
DB의 **connection(연결)**이 꽉 차버리면, 백엔드 서버는 새로운 연결이 뚫릴 때까지 기다려야 해서 느려져요.
3. Cache 아키텍처가 없을 때
같은 데이터를 매번 DB까지 가서 조회하면 당연히 느릴 수밖에 없어요. 캐시 아키텍처가 없으면 이런 비효율이 계속 쌓여요.
정리해볼게요
서비스 성능은 결국 이 세 가지를 얼마나 잘 챙기느냐에 달려 있어요.
- CORS로 프론트-백엔드가 다른 주소여도 안전하게 통신하게 하고
- 스케일링(수평/수직)으로 트래픽 변화에 유연하게 대응하고
- 캐시로 반복되는 요청을 DB까지 안 가고도 빠르게 처리하기
우리 앱은 "화면(프론트엔드) → 로직(백엔드) → 저장(DB)" 세 층으로 이루어져 있어요.
이 구조를 내 컴퓨터에서 통째로 돌리면서 테스트하다가, 준비가 되면 백엔드+DB만 Render.com이라는 온라인 서버에 "배포"해서 실제 사람들이 쓸 수 있게 하는 거예요.
즉, 같은 구조가 "연습용(내 컴퓨터)"과 "실전용(Render.com)" 두 군데에 각각 존재하는 거죠.
사용자가 뭔가 요청하면, 백엔드는 먼저 "캐시(Redis)에 이 데이터가 이미 있나?"부터 확인해요. 있으면(Cache Hit) DB까지 안 가고 캐시에서 바로 꺼내 쓰니까 훨씨 빨라요. 없으면(Cache Miss) 어쩔 수 없이 DB까지 가서 조회하고, 대신 다음번엔 빠르게 쓸 수 있도록 그 결과를 캐시에 저장해둬요
그럼 데이터가 바뀌면 캐시 키는 어떻게 될까요?
캐시(Redis)는 한번 저장해두면 계속 그 값을 들고 있어요. 근데 만약 그 사이에 원본 데이터(DB)가 바뀌어버리면 어떻게 될까요? 캐시는 옛날 정보를 그대로 들고 있으니까 낡은 데이터를 계속 보여주는 문제가 생겨요.
그래서 이렇게 처리해요.
- 데이터 변경 요청이 들어오면
- 먼저 DB를 업데이트해서 새 데이터를 정식으로 저장하고
- 그다음 캐시에 있던 그 키(key)를 지워버려요 — "이 정보는 낡은 정보야, 지워!" 라고 하는 거예요