시스템 디자인 인터뷰를 잘 보지 못해서 공부하려고 Martin Klepmann의 Designing Data-Intensive Applications (2017) 책을 봤다. 지금이 2020년이니까 나온지 3년 된 책인데, 그 3년 사이에 새로운 기술이 꽤 많이 나왔겠지만, 적어도 내가 정보처리 기술사를 공부하던 2011년보다는 최신이니까 그것보다는 나았다.
시스템 디자인 인터뷰에서 중요한 건, 코딩 인터뷰와 마찬가지로 빨리 설계하는 것이고, 중간에 인터뷰어가 치고 들어올 때 말귀를 잘 알아듣고 빠릿빠릿하게 받아치는 것이다. 일단은 이것도 시험이라서 80-90%는 정답이 있는데, 한 10-20% 정도는 이래도 되고 저래도 되는 부분이 있다. 그 빈칸을 어떻게 채울지는 나에게 달렸다. 내 경험상 인터뷰에서 질문이 나오는 경우도 마찬가지로 두가지인데, 첫째는 80-90%에 해당하는 정답 부분을 틀렸을 때고, 둘째는 10-20%에 해당하는 여백 부분을 물어볼 때다. 첫째는 질문이 아니라 힌트다. “야, 너 이거 틀렸으니까 다시 한번 잘 생각해서 고쳐봐”하는 거니까 감사하게 생각해서 고치면 된다. (정답을 맞춘 부분은 거의 물어보지 않는다. 그냥 넘어간다) 둘째는 “이래도 되고 저래도 될텐데 얘는 왜 이렇게 했을까?” 궁금해서 물어보는 거니까 내가 선택한 이유를 설명하면 된다.
그리고 질문이 흐릿하게 주어지는데, 나는 처음에는 이 흐릿한 부분을 명확하게 하기 위해 계속 질문을 했더니, 물어보니까 답변은 해주는데 그러다보니 시간을 너무 낭비해서 설계를 할 시간이 부족했다. 내가 적당히를 몰라서 너무 부족하거나 너무 지나친 면이 있으니까, 이것도 큼직한 것만 물어보고 나머지는 내가 알아서 가정해서 푼다. 사실 아무리 질문이 흐릿해도, 우리가 시스템을 설계해보면 다들 비슷한 상황에 처해있기 때문에 적당히 가정해도 된다. 구글이건 페이스북이건 아마존이건 마이크로소프트건, 우리가 쓰는 시스템들이 얼마나 차이가 있겠나. 대부분을 일반적인 시스템 설계로 쓰고, 일부분만 특별하게 설계해서 붙여 쓰면 된다.
자, 그래서 일반적인 경우를 열심히 훈련해서 80-90% 정답을 잘 맞추면, 이제 그 다음 단계로 넘어간다. 두번째 스테이지는 나의 가정을 바꿔서 물어보는 것이다. 난 지금까지 Oracle, MSSQL, MySQL만 써왔기 때문에 익숙한대로 일반적인 Relational DB(RDB)로 푸는데, 이게 조그만 INSERT만 엄청나게 많이 생겨서 자원을 많이 소모하면 이를 아끼기 위해 다른 걸 선택해야 한다. NoSQL로 MongoDB나 Cassandra에 쌓을수도 있고, 아니면 일단 Kafka로 받아서 Redis에 써놓고, 그걸 주기적으로 말아서 다시 RDB에 쌓을수도 있다. 그래서 Kafka에서 받은 Raw data는 파일로 써놔서 나중에 필요할때만 열어보면 되고, 일반적으로 필요한 건 요약 데이터라서 그냥 그건 RDB나 DW에서 읽어와서 쓰도록 하면 자원을 많이 절약해서 클라우드 서비스 청구서에 돈이 덜 찍히니까 회사가 좋아할 것이고 나도 고과 평가에 한 줄 쓸 거리가 늘어날 것이다.
근데 이게 공부를 해보면, 80-90% 까지는 책을 읽거나 온라인 강의를 들으면 훈련할 수 있는데, 나머지 10-20%의 여백을 어떻게 채워야 할지가 고민이 된다. 이건 솔직히 답이 없다. 그런데 나같이 경력 10년차가 넘어가는 시니어 레벨의 경우에는 이 여백까지 무조건 물어본다. 그러면 나는 답이 없는 문제에 답을 해야 한다. 그냥 답을 하는게 아니라 뭔가 인터뷰이가 내심 놀라면서, “야 이 사람 대단한데?” 싶은 와우 모먼트를 만들어야 한다. 그걸 어떻게 만들거냐? 별 수 있나, 내가 만들어야지. 대학원에서도 박사 과정이 되면, 구글 검색해도 정보가 안 나온다. 그럼 내가 정보를 생산해서 논문을 쓰면, 그 정보가 구글 검색에 나온다. 정보가 없으면 생산해야 한다.
내가 그정도까지는 안되서 내가 생각한 방법은 남의 회사의 시스템 설계를 보는 것이다. 우버도 그렇고 많은 회사들이 테크 블로그나 테크 유튜브를 운영하고, 거기에 1년에 한두번씩 이벤트를 열어서 자기가 한 걸 자랑한다. 그걸 보면 자세하지는 않아도 대략적인 건 힌트를 얻을 수 있다. 특히 요즘은 아마존이나 구글이나 마이크로소프트나 오라클이나 다들 클라우스 서비스를 하기 때문에, 그런 기술을 공개하는 것 자체가 판촉이라 더욱 자세하게 올라온다. 내부 시스템에서 잘 되는 거면 클라우드로 만들어서 외부에 팔기 때문에, 기술적인 부분만 보면 실무에 즉시 쓸 수 있을만큼 자세하다.
아니면 트위터에서 엔지니어들을 많이 팔로우하면 요즘 유행하는 것들을 많이 접할 수 있다. 그 중에서 쓸만한 것들을 추려서 잘 생각해보면 뭔가 답이 나온다. 그래서 아까 위에서 훈련한 80-90%의 정답의 빈 칸에 붙여보면 된다. 그러면 새로운 설계도가 나온다. 이런 식으로 10-20%의 여백을 채운다.
아까 2017년 책에서 부족했던 2020년까지의 3년 공백을 채워야 한다. 이게 IT 기술은 발전이 하도 빨라서 자꾸 뭐가 바뀐다. 예를 들어 Spring boot는 비동기 처리에 약하지만, 요즘은 Spring webflux가 나와서 이걸로 하면 꽤 빨라진다. Redis도 그룹 연산이나 secondary index 기능이 꽤 발달해서 간단한 DW 정도는 되고, RabbitMQ도 Kafka에 비해서 느리지만 persistence로 써도 성능이 꽤 나온다. 그러니까 이런 것들이 10-20% 여백에서 답을 할 여지가 생긴다.
