시스템 설계: 실제 앱을 떠받치는 도시 설계도

코드를 잘 짜는 것과 시스템을 잘 설계하는 것은 연결되어 있지만 같은 능력은 아닙니다.

코드는 방 하나를 잘 짓는 일에 가깝습니다. 시스템 설계는 도시를 계획하는 일입니다. 도로, 수도, 전기, 교통, 비상 경로, 성장 규칙까지 봐야 합니다.

첫날부터 Netflix 같은 시스템을 설계할 필요는 없습니다. 하지만 도시를 설명하는 단어는 알아야 합니다.

클라이언트와 서버: 손님과 주방

웹의 기본 그림은 단순합니다.

**클라이언트(Client)**는 손님입니다. 브라우저, 모바일 앱, 데스크톱 앱이 여기에 해당합니다.

**서버(Server)**는 주방입니다. 요청을 받고, 비공개 로직을 실행하고, 데이터베이스와 대화하고, 응답을 돌려줍니다.

**API(Application Programming Interface)**는 메뉴판입니다. 앱이나 서비스끼리 요청과 응답을 주고받는 약속입니다. 클라이언트가 무엇을 요청할 수 있고, 어떤 모양의 응답을 받을 수 있는지 정합니다.

서버는 자신의 데이터베이스만 쓰는 게 아닙니다. 외부 AI 모델이나 결제·메일 같은 외부 서비스도 API로 호출합니다. 이때는 내 서버가 다른 회사 주방의 '손님'이 되는 셈입니다.

DNS(Domain Name System)는 example.com 같은 도메인을 실제 서버 주소로 바꿔주는 주소록입니다. CDN(Content Delivery Network)은 이미지, CSS, JavaScript 같은 정적 파일을 사용자에게 가까운 서버에서 보내는 캐시망입니다. 페이지가 빨리 열리게 만드는 데 자주 쓰입니다.

데이터베이스: 도시의 도서관

데이터베이스는 앱의 중요한 기록을 보관하는 도서관입니다.

크게 세 가지 사고방식이 있습니다.

SQL(Structured Query Language) / 관계형 데이터베이스는 구조가 정해진 표와 같습니다. 행과 열이 분명하고 관계가 중요합니다. 사용자, 주문, 결제, 프로젝트, 리포트, 비즈니스 데이터에 강합니다.

NoSQL(Not Only SQL) 데이터베이스는 더 유연한 문서 묶음에 가깝습니다. 게시물, 채팅 메시지, 활동 피드처럼 모양이 자주 바뀌는 데이터에 잘 맞을 수 있습니다.

**벡터 데이터베이스(Vector DB)**는 '의미'로 찾는 도서관입니다. DB는 데이터베이스(database)의 줄임말입니다. 글·이미지·문서를 임베딩(embedding)이라는 숫자 묶음으로 바꿔 저장하고, 정확히 일치하는 단어가 아니라 의미가 가까운 것을 찾아줍니다. 그래서 AI 시맨틱 검색, 추천, RAG(Retrieval-Augmented Generation, 관련 문서를 찾아 답변 근거로 쓰는 방식)의 핵심입니다. Pinecone, Weaviate, pgvector가 대표적입니다.

캐싱: 자주 보는 책을 책상 위에

캐싱(Caching)은 결과를 다시 계산하거나 다시 가져오는 대신 재사용하는 것입니다.

매시간 보는 책이라면 매번 도서관에 가지 않습니다. 책상 위에 둡니다.

캐시는 시스템을 훨씬 빠르게 만들 수 있습니다. 동시에 질문 하나를 만듭니다. 책상 위 복사본과 도서관 원본이 달라지면 어떻게 할 것인가?

이것을 캐시 무효화(cache invalidation)라고 합니다.

캐시에 잘 맞는 것:

• 자주 바뀌지 않는 공개 콘텐츠.
• 재사용 가능한 비싼 AI 응답.
• 상품 카탈로그.
• 짧은 시간 동안의 사용자 권한 정보.
• 짧은 만료 시간을 둔 검색 결과.

로드 밸런서: 계산대 줄을 나누는 직원

서버 하나가 모든 트래픽을 감당할 수 없으면 서버를 여러 개 둡니다.

**로드 밸런서(Load Balancer)**는 앞에서 요청을 나눠줍니다.

마트 직원이 "이쪽 계산대 비었습니다"라고 안내하는 것과 비슷합니다. 한 서버에만 압력이 몰리지 않게 합니다.

Vercel, Cloudflare, Firebase, Render 같은 관리형 클라우드에서는 로드 밸런서를 직접 만지지 않을 수 있습니다. 하지만 개념은 중요합니다. 플랫폼 버튼 뒤에 숨어 있는 많은 기능이 결국 부하 분산입니다.

메시지 큐: 우체국의 분류함

사용자 요청 안에서 바로 처리하지 않는 편이 좋은 일이 있습니다.

이메일 발송, 이미지 리사이즈, 리포트 생성, 업로드 처리, 긴 AI 작업, 데이터 동기화 같은 일입니다.

**메시지 큐(Message Queue)**는 작업자가 준비될 때까지 작업을 보관합니다.

이 구조는 앱을 더 빠르고 안정적으로 만듭니다.

• 사용자 요청이 빨리 끝납니다.
• 실패하면 재시도할 수 있습니다.
• 작업자를 별도로 확장할 수 있습니다.
• 긴 작업이 웹페이지 타임아웃을 만들지 않습니다.

모놀리식 vs 마이크로서비스

초기 제품 대부분은 모놀리식에 가깝게 시작하는 편이 낫습니다. 마이크로서비스는 팀과 확장 문제를 풀어주지만, 네트워크, 배포, 모니터링, 디버깅 문제를 새로 만듭니다.

트레이드오프: 시스템 설계의 진짜 핵심

시스템 설계에는 정답이 하나만 있는 경우가 드뭅니다.

우리는 계속 교환합니다.

• 속도와 비용.
• 안전성과 복잡도.
• 유연성과 운영 부담.
• 단순함과 미래 마이그레이션 비용.
• 성능과 데이터 신선도.

AI에게 이렇게 물어보세요

이 앱의 시스템 설계를 요청 흐름으로 설명해줘.
클라이언트, 서버, API, 데이터베이스, 캐시, 큐, 외부 서비스가 각각 어디에 있어?
다음 1,000명의 사용자를 안전하게 지원하는 가장 단순한 아키텍처는 뭐야?
아직 마이크로서비스로 나누지 말아야 할 것은 뭐야?

자주 묻는 질문

시스템 설계란 무엇인가요?

시스템 설계는 애플리케이션의 여러 부분이 어떻게 연결되어야 실제 사용자를 안정적으로 지원하면서, 필요할 때 확장하고 나중에도 변경할 수 있는지 결정하는 일입니다.

클라이언트와 서버의 차이는 무엇인가요?

클라이언트는 사용자가 상호작용하는 브라우저나 앱입니다. 서버는 요청을 받아 처리하고 데이터베이스나 다른 서비스와 통신한 뒤 응답을 보내주는 프로그램입니다.

캐시는 언제 써야 하나요?

같은 데이터를 반복해서 읽는 비용이 크거나 느리고, 짧은 시간 동안 약간 오래된 데이터를 제공해도 괜찮을 때 캐시를 사용합니다.

메시지 큐는 무엇에 쓰나요?

메시지 큐는 이메일 발송, 이미지 리사이즈, AI 작업 실행, 데이터 동기화 같이 사용자 요청 안에서 끝낼 필요가 없는 작업을 보관합니다. 앱이 빨리 응답하고 실패한 작업을 재시도할 수 있게 합니다.

모놀리식과 마이크로서비스 중 처음에는 무엇을 선택해야 하나요?

팀이나 확장 문제가 명확하게 분리가 필요하지 않다면 모놀리식으로 시작하세요. 초기에는 만들고, 테스트하고, 배포하고, 변경하기가 더 단순합니다.

핵심 정리

시스템 설계는 방 하나가 아니라 도시 전체를 보는 능력입니다.

초기 빌더에게 가장 좋은 아키텍처는 보통 실제 사용자를 안전하게 받을 수 있으면서 나중에 바꿀 수 있는 가장 단순한 구조입니다.