architecture

2 posts
컨트롤 플레인과 데이터 플레인: 시스템을 두 층으로 나누는 이유

컨트롤 플레인과 데이터 플레인: 시스템을 두 층으로 나누는 이유

시스템 설계를 다루는 글을 읽다 보면 컨트롤 플레인(control plane)과 데이터 플레인(data plane)이라는 말이 늘 짝을 지어 나옵니다. 시스템을 둘로 나눈다는 이야기인 건 알겠는데, 정확히 무엇을 기준으로 나누는 건지 물으면 선뜻 답하기 어렵죠. 특히 웹 서비스를 만들며 시스템을 프론트엔드와 백엔드로만 나눠 보던 분이라면 더 낯설게 느껴질 겁니다. 그런데 이 구분은 그 익숙한 나누기와 전혀 다른 방향으로 시스템을 자르는 칼이에요. 한 번 익혀 두면 매일 만지는 백엔드 코드도 다르게 보이기 시작합니다. 이번 글에서는

헷갈리는 Upstream과 Downstream

헷갈리는 Upstream과 Downstream

소프트웨어 문서를 읽다 보면 "upstream 서버에 장애가 났다", "downstream consumer가 영향을 받는다" 같은 표현이 수시로 튀어나오는데요. 그때마다 "그래서 어느 쪽이 어느 쪽이지?" 하며 잠깐 멈칫한 경험, 저만 있는 건 아닐 거예요. nginx 설정의 upstream 블록, dbt의 downstream 모델, Debian/Ubuntu의 계보처럼 결이 완전히 다른 자리에서 같은 단어가 쏟아지니 한 번에 감을 잡기가 쉽지 않습니다. 이 글은 그 혼란의 뿌리를 짚어보고, 실무에서 두 용어가 쓰이는 대표 쓰임새를

Discord