가상 면접 사례로 배우는 대규모 시스템 설계 스터디 회고

최근 회사에서 가상 면접 사례를 통해 배우는 대규모 시스템 설계 스터디를 진행하게 되었습니다. 스터디는 사다리타기로 진행되었고, 그 결과 1장에 대한 정리를 제가 맡게 되었습니다.

이 책은 이미 워낙 유명해서 1장의 내용은 노션 링크로 간단히 공유하고, 이번에는 책에 나와 있는 내용뿐만 아니라, 스터디 중에 나온 질문들과 추가로 얻은 인사이트를 정리해보려고 합니다.

실무에서 배우는 시스템 설계

사실, 현재 현업에서 일하고 있는 상태다 보니, 팀원들 모두 기본적인 시스템 지식은 갖추고 있습니다. 그래서 단순히 책 내용을 정리하는 데 그치지 않고, 실제 현업에서 어떻게 적용하고 있는지에 대한 이야기를 나누게 되었습니다.

1장에서 다룬 핵심 내용은 웹 애플리케이션 서버(Web Application Server, WAS)를 작은 시스템에서 대규모 시스템으로 확장하는 과정에서 겪게 되는 시스템 설계 기본 지식입니다. 이 부분이 어떻게 적용될 수 있는지, 그리고 현업에서는 어떤 도구들이 활용되는지에 대해 이야기했습니다.

어떤 프레임워크를 선택할까?

스터디 중에 WAS (혹은 간단한 서비스)를 만들 때 어떤 프레임워크를 사용하고 있는지에 대한 질문이 있었습니다. 그때 나온 답변은 대체로 다음과 같았습니다:

1. FastAPI + React
2. Client-side 렌더링으로 no server, 가끔 FastAPI
3. Next.js + FastAPI
4. NestJS + Next.js

저는 1번 답변을 제시했습니다. 사실 저는 React를 다루는 편인데, 다른 프레임워크는 많이 사용해본 경험이 없었습니다. 하지만 Next.js에 대해 물어보니 SSR(Server-Side Rendering)과 라우팅 설정이 편리하고, React의 문법과 큰 차이가 없다는 답변을 들었습니다. React에서 라우팅을 구현할 때 어려웠던 기억이 있어서, Next.js를 더 깊게 공부해봐야겠다는 생각이 들었습니다.

RDB vs NoSQL: 데이터베이스 선택의 기준

다음으로 데이터베이스 선택에 대한 이야기가 나왔습니다. 항상 등장하는 주제인 RDB vs NoSQL에서, NoSQL이 Scale-out이 용이하고, Write TPS(초당 처리량)가 높은 상황에서 적합하다는 점이 강조되었습니다.

그러다 "왜 RDB는 안 되는 거지?"라는 질문이 나왔고, 저는 RDB는 트랜잭션을 잘 지원하기 때문에 그렇다고 설명했습니다. 하지만 요즘 나오는 NoSQL들은 트랜잭션을 지원하는 기능도 많아서, 혼동이 생길 수 있다는 점이 흥미로웠습니다.

논의 중에는 데이터를 관계형(ROW) 형태로 저장하는 것이 문제일 수 있다는 의견도 나왔습니다. 당시에는 RDB가 트랜잭션을 잘 지원한다는 점만 강조했지만, 사실 NoSQL이 더 나은 점은 Write 부하를 줄이는 구조를 취하고 있기 때문이라는 점도 알게 되었습니다. (이 부분은 유튜브 영상에서 더 확인해보실 수 있습니다.)

추가적인 기술적 질문과 인사이트

책에 명시된 내용 외에도 Redis의 데이터 제거 정책이나 Facebook의 캐시 계층 관리 방식과 같은 궁금한 점들을 덧붙여가며 얘기를 나누었습니다. 이런 기술적 질문들을 나누다 보니, 스터디 참여자들도 더 흥미롭고 신나는 시간을 보냈을 것 같다는 생각이 듭니다.

회고: 배운 점 & 느낀 점

마지막으로 스터디를 마친 후, 회고를 남기자면:

1. 책에서 궁금한 부분을 추가적으로 정리해 공유하니 더 많은 내용을 전달할 수 있어서 좋았습니다.
2. 서로의 경험을 공유하는 시간이 매우 유익했습니다. 다양한 관점에서의 의견을 들을 수 있어 배울 점이 많았습니다.
3. 모호하게 알고 있던 부분을 인지하면서, 제대로 답변하지 못했던 부분에 대해 좀 더 공부할 필요성을 느꼈습니다.

이번 스터디를 통해 많은 인사이트를 얻을 수 있었고, 다음에도 더 깊이 있는 기술적 대화를 나눠서 많이 성장할 수 있기를 기대하고 있습니다!