이 세미나가 어떻게 무료예요?! 개발자들을 위한 '일할맛' 세미나 다시보기

패스트캠퍼스의 '일할 맛' 프로젝트에 대해 들어보신 적 있나요? '일할 맛' 프로젝트란, 실무에서 개발에 대한 열정은 넘치지만 회사 차원에서의 시간이나 비용이 부족해 개발 노하우, 업무 환경 개선 등 다양한 영역에서 도움이 필요한 개발자들을 지원하는 패스트캠퍼스의 프로젝트입니다. 참여자로 선발되면 1억 상당의 개발 교육 혜택에서부터 개발팀 간식 지원, 그리고 시니어 개발자들의 노하우를 전수하는 세미나와 네트워킹 행사까지 참여할 수 있는데요!

오늘은 성황리에 진행되었던 지난 1기 세미나 & 네트워킹 현장의 세미나 내용을 일부 소개해 드리려 합니다. 1기 프로젝트의 멘토는 쿠팡 테크 리더 출신의 이광운 님과 현 29cm 시니어 개발자인 김진실 님이 맡아주셨는데요. 두 분 모두 프로젝트 참여자 선발에서부터 세미나 발표, 네트워킹 시간에 1:1 컨설팅까지 전 과정을 함께해 주시며 지금까지 쌓아오신 경험과 인사이트를 최대한 많이 전달해 드리기 위해 노력해 주셨답니다. 그럼, 이광운님께서 '골목 기업에서 빅테크 기업으로 : 시스템 확장편' 이란 주제로 진행해 주신 발표 내용부터 함께 알아볼까요?

스타트업에서 3~4조 밸류 기업까지

여러분들이 스타트업을 시작한다고 가정해 봅시다. 서비스를 시작하려면, 외주 개발자나 개발자를 고용해 직접 서비스를 만드는 방법 또는 개발 능력이 없다면 네이버 카페, 인스타그램 등의 온라인 서비스를 사용할 수 있겠죠. 직접 만드는 방법은 이미 잘 알고 계시겠지만, 간단한 웹 서버 하나, 데이터베이스 하나, 관리 사이트 하나 만들어 서비스 운영을 시작하겠죠. 이 과정에서 카페24나 클라우드를 활용할 수 있겠고요.

지금 보시는 이미지는 여러분이 잘 아시는 쿠팡의 첫 사이트 화면입니다. 게시판을 약간 커스터마이징해서 사이트를 시작했고, 첫 소셜 상품 딜 하나를 만들어서 사업을 시작했었어요. 이런 식으로 사업이 시작될 수도 있겠고요.

다음으로는 직접 만들지 않고 인스타그램, 네이버 카페, 카페24 등을 활용해 외부 서비스를 이용할 수도 있는데요. 이런 경우에는 개발자가 필요 없이 바로 사업을 시작할 수 있다는 장점이 있죠. 이렇게 사업을 위한 서비스를 시작할 수 있는 두 가지 사례가 있는데요. 그러면 여기서, 사장님들은 서비스를 직접 만들 거냐 또는 온라인 서비스를 이용할 거냐는 고민을 할 수 있습니다. 이번 발표는 스타트업에서 빅테크 기업까지의 성장을 다뤄보는 만큼 직접 서비스를 만드는 케이스를 집중으로 얘기해 보도록 하겠습니다. 그렇다면, 직접 서비스를 만들 때 필요한 것들은 무엇이 있을까요?

일단 기획부터 해야 하니, 서비스 기획 PO 또는 기획자를 채용해야 할 거고 이 사람들이 기획을 완성하면 구현해 낼 디자이너도 필요합니다. 디자이너까지 채용이 되었으면 개발은 외주 업체에 맡길지 채용할지 고민하겠지만 자사 서비스를 만드는 거니 채용하겠죠. 그리고 채용된 개발자들은 개발 환경, 플랫폼, 인프라, 문화 등 다양한 영역과 관련된 고민을 할 거예요.

이런 고민과 함께 서비스를 만들었다면, 또 다른 이슈들이 발생할 수 있습니다. 서비스가 런칭 되었으니 고객 관리를 해야 하고, 쏟아지는 불평불만을 처리함과 동시에 쌓이는 서비스 데이터 관리, 서비스 유지 보수, UX 관리 등 해야 할 게 너무나 많습니다. 즉, 한번 서비스를 만들면 확장하기도 전에 이런 많은 고민이 발생하고 어느 순간 한계가 찾아오게 됩니다.

보통은 서버 한 개로 시작할 테니, 증가하는 고객 트래픽을 감당하지 못해 서비스가 중지되기 시작하고 데이터 적재, 분석, 보안 등 여러 문제로 서비스를 관리하기가 어려워지겠죠. 급한 마음에 로컬, 자신의 PC에서 데이터베이스에 직접 붙어서 뭔가 막 수정하려 하고, 그러다 날려 먹고 '아...이러면 안 되는구나'ㅎㅎㅎ깨닫게 되시기도 할 거고요(이러면 물론 안 됩니다). 이렇게 '더 이상 힘들어 못 살겠어!' 할 때쯤, 서비스 개편을 고민하게 되실 거예요.

그럼 시스템 구조를 고민하시게 될 텐데, 모노로틱, 세미-마이크로, 마이크로 서비스 등을 보통 떠올리시겠죠. 웹 메시지가 요즘 트렌드라며 막 쪼개는 걸 생각하실 수 있는데, 주니어로 대부분 구성되어 있고 사람이 많지 않은 상황에서 이렇게 되면 더 힘들어집니다. 쪼개면 데이터베이스도, 서버도 늘어나고 비용도 계속 증가하는데 쪼개던 시니어가 퇴사하면? 정말 힘들어질 수 있어요. 그러니, 시스템 구조는 요즘 트렌드라고 따라가면 위험합니다. 정답이 없으니 우리의 성숙도, 개발 상황, 환경, 규모에 맞게 선택해야 합니다. 우리의 서비스가 아직 작다면 모노로틱도 괜찮고, 나중에 규모가 커진다면 그때 MSA를 고려하되 이것도 한꺼번이 아니라 하나하나씩 정산을 뗀다든지, 주문을 뗀다든지 라는 식으로 점진적으로 진행되어야 합니다. 그래서 이런 시스템들을 좀 바꾸고 싶을 때는 아래와 같은 기준들을 참고해 보는 게 좋아요.

적정 아키텍처 선정 기준

✅왜 이런 아키텍처가 필요한가?
✅왜 이런 시스템이 필요한가?
✅왜 이런 플랫폼이 필요한가?
✅왜 이 개발언어가 필요한가?
✅왜 개발자가 많이 필요한가?

이런 부분들을 고민하고 팀원들에게 각 기준에 대한 이유를 설명해야 합니다. 그래서 '3 Whys'라고, 3번 물어봐라 이런 게 기획자들 사이에서 유행하기도 했어요. 저도 아직 이렇게 스스로한테 묻습니다. '내 돈으로 사업한다 해도 이렇게 할래?' 이걸 항상 마지막에 되짚어 보시면 좋은 설계, 그리고 좋은 아키텍처를 선택하는 데 도움이 되지 않을까 싶습니다. 그렇다면, 기본적으로 우리가 시스템 구조 및 확장과 관련해서 해야 할 것은 뭘까요?

서버가 많아지니 분산하기 위해 로드밸런스를 적용하겠고, 데이터베이스도 하나 가지고 안 되니 다중화할 거고, 부하가 너무 많이 가지 않도록 캐시 적용하고 CDN 도입해 정적 콘텐츠 서빙하게 하고. 또 주기적 업무를 위한 배치 시스템 활용, 도메인 단위 시스템 분리, 메세징 플랫폼 적용, 데이터 센터 다중화까지 갈 텐데 사실 여기까지는 완전히 규모가 성장한 최종의 단계이고요.

자, 이렇게 고객 트래픽이 늘었을 때 고민하게 되는 게 두 가지가 있는데요. 하나는 수직적으로 CPU나 메모리를 늘릴 것이냐 아니면 수평적으로 장비, 자원들을 늘릴 것이냐입니다. 아마 대부분 수직적인 확장만 먼저 해보실 거예요. 이게 안 되면 수평적 확장으로 가실 건데 여기서 핵심은 바로 이겁니다.

시스템 확장에서 중요한 포인트 : SPoF(Siggle Point of Failure)

단일 장애점(SPoF)을 없애는 것이죠. 이게 대부분 빅 테크의 아키텍처 리뷰를 보면 꼭 지적받는 부분인데, 가령 디자인 리뷰 문서를 보고 '어? 저희 단일 장애 지점인데 저거 괜찮겠습니까?' 이런 의견 나오면 물론 안 괜찮겠죠. 아키텍처 디자인을 바꿔야겠죠. 그러니 항상 이 'SPoF'를 고민하셔야 합니다.

자, 그러면 이제 시스템을 확장해 봅시다.

DB 서버랑 웹서버랑 한 대씩 있었는데, 왼쪽 이미지를 보시면 싱글 포인트 페이웨이를 없애기 위해서 웹서버를 A랑 B로 늘렸고, DB는 아직 한 대네요. 트래픽 분산을 위해 이 앞에 로드밸런스를 둘 거고요. 이러면 지금 트래픽은 웹서버가 늘어나 분산이 되었는데, DB에 부하가 걸리죠. 그래서 결국은 오른쪽 이미지처럼 데이터베이스를 마스터하고 슬레이브를 둘 거고 마스터는 쓰기만, 슬레이브는 읽기만 담당시켜 분리해 두겠죠. 대부분의 트래픽은 리드가 많기 때문에 나중엔 리드를 여러 개로 늘려서 '읽기'의 부하를 분산시켜 줄 겁니다.

그런데 데이터베이스가 처리하기에는 무거운 작업이 있을 수 있어요. 그래서 보통 제가 있던 회사에서는 로직 짜는 등 DB의 프러시저 같은 걸 안 만들었고, 대부분의 로직은 대부분 웹 서버 단에 둬서 DB를 스케일 아웃할 수 있게 해뒀어요. 근데 이렇게 해둬도 무거운 작업이 있으니 이런 작업을 DB까지 가지 않고 서빙해 주기 위해서 저렴한 비용으로 도입할 수 있는 캐시를 들입니다. 여기까지만 해도 트래픽을 많이 감당할 수 있어요.

하지만 더 나아가면, 웹 서버에 있는 이미지라든지 CSS 파일이라든지 자바스크립트 파일은 굳이 서버에 있을 필요가 없죠. 그래서 이런 것들은 클라이언트에게 가까이 있는 CDN에 가져다주고 서빙하도록 CDN을 도입해 웹서버로 가던 부하들이 다 이쪽으로 가 엄청난 트래픽을 견딜 수 있게 해줍니다. 여기까지가 작은 기업에서 큰 규모의 기업으로 성장할 때 정말 기본적으로 해야 하는 단계들이라고 할 수 있고요.

이제부터는 빅 테크에 가까운 규모의 기업들이 해야 하는 단계를 설명해 보겠습니다. 회사에 다니다 보면, 매일/매주/매월 등 주기적으로 모아서 처리해야 하는 업무들이 있죠. 이런 것들은 웹서버와 따로 분리해서 배치에 넣어주시는 게 좋아요. 웹서버는 고객들의 요청에 빨리 응대하는 역할이고, 배치는 모아서 응대하는 역할로 둘이 다르기 때문에 이 왼쪽의 이미지가 트래픽을 분산하고 큰 트래픽을 견디고, 고객을 대량으로 처리할 수 있을 하나의 아키텍처라고 보시면 될 거 같아요.

단, 여기서 가장 중요한 것은 절대 웹 서버에 배치를 두지 않는 것입니다. 배치는 오래 돌기 때문에 커넥션도 오래 보고, 리소스도 오래 갖고 있어 웹서버가 원래 해야 했던 일을 못 하게 합니다. 이 때문에 배치는 항상 이렇게 분리해 두는 걸 추천해 드립니다.

자, 이제 시스템이 점점 더 커지고 있는데요! 이렇게 되다 보니 한 시스템에 코드를 저장해서 웹 서버에 올리는 모듈들이나, 백엔드 정보까지 다 갖고 있게 됩니다. 너무 복잡해지는 거죠. 그러면 코드 저장도 분리하면서 시스템도 역할을 분리하고자 하실 거예요. 이때 나오는 게 바로 '도메인'입니다. 도메인이란 결국 저희가 해결하고 싶은 문제의 영역을 말하는 건데요. 오른쪽의 이미지처럼 주문은 주문대로 정산은 정산대로 나누는 건데, 결국 기본은 똑같습니다. 웹서버 이중화, DB 이중화, 캐시, 배치 다 각자 가져가는 거죠. 물론 이 과정에서 비용은 훨씬 증가합니다. 대신 엄청난 트래픽과 고객들은 다 감당하고 처리할 수 있겠죠. 그런데 여기서 이런 생각을 하실 수 있어요. '캐시랑 배치는 같이 있어도 되지 않나?'

하지만 배치와 캐시를 같이 쓰면, 얘도 앞서 말한 SPoF가 될 수 있습니다. 배치가 죽으면 주문 배치, 정산 배치가 다 안 될 수 있어서 주문 배치가 죽어도 정산은 되고 이럴 수 있도록 SPoF를 제거해 주며 스케일을 계속 늘려가야 합니다. 큰 기업에서는 이렇게 쪼개둔 시스템 구조가 수십 가지는 되겠죠.

이렇게 시스템을 나누면 이제 시스템끼리 통신을 해야 하는데요. 보통 API 통신을 생각하는데 API 통신은 동기기 때문에 요청하고 기다렸다가 받고 해야 해서 트래픽과 성능 관점에서 이슈가 있을 수 있어요. 따라서 이벤트가 발생했을 때 서로 이벤트를 주고받을 수 있는 도입료로 큐를 집어넣는 것입니다. 하지만 큐도 마찬가지로 한 곳에 같이 쓰면 다 같이 장애를 겪을 수 있어서, 어느 순간 이후부터는 분리하게 되실 수 있습니다. 그리고 최종적으로는 데이터 센터도 하나만 두면 또다시 SPoF가 될 수 있기 때문에 데이터 센터도 이중으로 다중화하게 되겠죠.

시스템 필수 기반

하지만 이렇게 막 분리한다고 해서 운영이 되는 게 아니고, 다중화하려면 제대로 서비스가 될 수 있도록 기반이 있어야 하겠죠. 즉 시스템 확장을 위한 필수 요소를 꼽아보면,

✅로깅 ✅모니터링✅지표 수집✅자동화(빌드/배포/테스트/확장)

이런 게 다 잘 갖춰져야 앞서 계속 말한 시스템 분리를 통한 확장을 잘할 수 있는 겁니다. 스타트업은 아직 배포 시스템 레일이 없을 수도 있는데, 배포를 손으로 하게 되면 개발자가 배포를 무서워하게 됩니다. 버전 관리 앱을 깃허브나 깃랩이나 사용하고 계실 텐데, 여기서 배포를 지원하고 있으니 최소한으로 깃허브 액션이나 이런 걸로 배포를 자동화하시길 바라요. 이렇게 되면 롤백도 자동화가 되니 이렇게 해야 여러분들이 빠르게 성장하고 싶을 때 성장할 수 있습니다.

대규모 시스템을 위한 구조 정리 한 장 요약!