시스템 설계라고 하면 딱딱하고 기술적인 느낌부터 떠오르죠? 근데 사실, 이건 결국 '선택의 연속'이에요. 어느 방향으로 가야 더 나을지, 지금 이 서비스에 어떤 방식이 어울릴지 고민하는 거예요. 저도 처음엔 ‘이게 왜 이렇게 복잡하지?’ 싶었는데, 하나씩 정리해보니까 생각보다 감이 오더라고요.
오늘은 제가 실제로 겪었던 고민들, 그리고 많은 개발자들이 흔히 마주치는 선택지들에 대해 편하게 풀어볼게요. 뭐가 더 좋다기보다는, 언제 어떤 선택이 맞을지를 같이 얘기해보자는 마음으로요. 😊
1. 앱이 커질 때: 서버를 키울까? 여러 개로 나눌까?
처음 만든 앱이 생각보다 반응이 좋고, 점점 유저가 많아지면 제일 먼저 하는 고민이 이거예요. '이걸 어떻게 더 버티게 하지?'
Vertical scaling은 말 그대로 기존 서버를 업그레이드하는 거예요. CPU 더 빵빵하게, 메모리도 업! 처음엔 이게 제일 쉬워요. 근데 언젠가는 이 방법도 한계에 부딪혀요. 저도 한 번은 서버를 업그레이드했는데, 비용 보고 깜짝 놀랐거든요.
그래서 나오는 게 Horizontal scaling이에요. 서버를 여러 대로 쪼개서 트래픽을 나눠서 처리하는 거죠. 확장성도 좋고 장애에도 강해요. 하지만 진짜, 설정할 게 많아서 복잡도는 확 올라갑니다.
👉 한줄 정리: 간편하게 시작할 땐 Vertical, 규모 커지면 Horizontal을 생각해보자!
2. REST vs GraphQL: 프론트가 원하는 걸 줄 수 있는 API는?
처음 API 짤 땐 다들 REST부터 시작하죠. 딱 봐도 익숙하고 배우기 쉽고요. 근데 UI가 복잡해지고, 프론트에서 '이 데이터만 딱 주세요' 할 때 REST가 조금 버겁더라고요.
그럴 때 등장하는 게 GraphQL이에요. 필요한 데이터만 정확히 뽑아올 수 있어서 프론트 입장에선 정말 편하죠. 저도 한번 GraphQL 도입하고 나서 프론트 개발자랑 커뮤니케이션이 훨씬 수월해졌어요.
물론 단점도 있어요. 쿼리가 복잡해지면 서버가 버벅일 수 있고, 보안 쪽도 신경 써야 할 게 많거든요.
👉 한줄 정리: REST는 익숙하고 단순, GraphQL은 유연하고 강력. 상황에 따라 고르자!
3. 서버가 뭘 기억해야 할까? 아니면 매번 새로 시작할까?
Stateless 구조는 요청이 들어올 때마다 ‘처음 보는 사람’처럼 대응하는 방식이에요. 이게 관리도 쉽고 확장하기도 편하죠.
근데 게임처럼 누가 어디에 있는지 기억해야 하거나, 채팅처럼 실시간 연결을 유지해야 하는 서비스에선 Stateful이 필수에요. 저도 예전에 실시간 알림 서비스 만들면서 이거 뼈저리게 느꼈습니다.
요즘엔 이 둘을 섞어서 쓰는 경우가 많아요. 일반 기능은 Stateless로, 중요한 상태를 다루는 기능은 Stateful로요.
👉 한줄 정리: ‘기억’이 필요한 기능은 Stateful, 나머진 Stateless로 깔끔하게!
4. 캐시, 빠르지만 때론 틀릴 수도 있어요
캐시는 진짜 속도에 날개 달아주는 기술이에요. 자주 요청되는 건 미리 저장해두고, 필요할 때 꺼내 쓰는 거죠.
Read-through caching은 없으면 DB에서 가져오고, 그걸 캐시에 저장하는 방식이에요. 단순하고 빠르지만, 가끔 업데이트된 데이터를 반영 못할 때가 있어요. 예전에 친구가 프로필 사진 바꿨는데 한동안 예전 사진이 계속 보여서 엄청 당황했었죠.
그래서 중요한 데이터에는 write-through caching이 필요해요. DB랑 캐시를 동시에 업데이트해서 항상 최신 상태를 유지하죠. 대신 처리 속도는 조금 느려져요.
👉 한줄 정리: 속도를 원하면 read-through, 신뢰성이 더 중요하면 write-through!
5. 요청 받자마자 처리할까? 아니면 좀 이따 할까?
작업이 금방 끝날 거면 synchronous processing이 제일 좋아요. 바로 응답 오니까 사용자도 만족하죠.
근데 영상 변환, 리포트 생성처럼 오래 걸리는 작업은? 사용자 계속 기다리게 하는 건 좀 그렇잖아요. 이럴 땐 asynchronous processing이 딱이에요. 요청 받고 ‘처리 중이에요~’ 하고 나중에 결과 주는 거죠.
물론 구현은 좀 복잡해요. 큐도 만들고, 상태 추적도 해야 하고, 실패했을 때 재시도도 필요하니까요. 저도 처음엔 비동기 처리하려다 진땀 뺐어요 😅
👉 한줄 정리: 간단한 건 동기로, 무거운 건 비동기로 처리하자!
마무리하며: 정답은 없고, '우리에게 맞는 답'만 있어요
시스템 설계엔 딱 떨어지는 정답이 없어요. 그때그때 상황, 서비스 규모, 개발팀 역량, 사용자 요구—all 그것들을 조합해서 가장 적절한 걸 골라야 하죠.
저도 처음엔 ‘이게 정석인가?’ 생각했지만, 결국 중요한 건 ‘이게 우리에게 잘 맞느냐’더라고요. 그러니까 너무 정답에 집착하지 말고, 우리 상황에 어울리는 설계를 찾아가는 과정 자체를 즐겨보세요. 😊
'SW > 클라우드 서비스 아키텍처' 카테고리의 다른 글
| 블랙프라이데이 폭주에도 끄떡없는 distributed system reliability 비결 7가지 (0) | 2025.06.27 |
|---|---|
| 클라우드 엔지니어가 되려면? 비전공자도 가능한 12단계 실전 가이드 (0) | 2025.06.16 |
| Apache Kafka를 워크플로우 및 오케스트레이션 엔진으로 활용하기 (0) | 2024.11.11 |
| 카파 아키텍처(Kappa Architecture): 데이터 엔지니어링을 위한 혁신적인 접근 방식 (0) | 2024.10.30 |
| gRPC vs. REST: 차이점, 유사점 및 사용 이유 (0) | 2024.09.28 |