[글 공유] 최근 블라인드에서 논쟁 중인 주제 대용량 트래픽, MSA, k8s 관련 글 입니다

[TaeHyoungKwon]

책 모임 주제와는 별로 관계가 없지만, 최근에 블라인드에서 논쟁 중인 글인데 꽤나 읽을만한 내용들이 많아서

위 주제에 관심 있으시다면, 블라인드에 글 검색하셔서 꼭 한번 읽어보시면 좋을 것 같습니다!

[wooyaggo86]

흠.. 가서 보고 싶은데.. 가입이 어려워 어떤 내용이 있을지 궁금하네요ㅎㅎ

글만 보고 드는 생각은

MAU 500이하 라는 조건에서

• "모놀리틱에 캐시 잘 바르고 스케일 아웃만 잘해도 전혀 문제 없다" 는 참일 가능성이 있지만, 비지니스 특성에 따라 틀릴 수도 있다. 라는 생각이 듭니다.

개발지원이 10명 이하의 조건에서

• MSA는 일반적으로 과할 수 있겠다 라는 생각이 들고.
• 쿠버네티스는 Infra과 Operation쪽인데, 필요할 수 있지 않나? 라는 생각이 드네요.

글의 의도는 Over-engineering을 피하자라는 의도로 이해했습니다. 종종 일어나는 일이고, 글에서처럼 너무 필요없이 일을 많이 해야하는 경우도 있습니다.

그렇다고 무작정까는건 노노. 무작정 옹오하는 것도 노노.
아만보라기 보다는 캐바캐가 아닐까 라는 생각이 듭니다.

[jongfeel]

저의 의견도 적어 보자면

기술 리더라고 부를만한 사람들이 결정하는 것들이
자기가 선호하는 기술 혹은 여태 까지 해 왔던 기술에 치우친 경향이 있고
거기에 기술 트렌드를 따라가다 보니 그런 것 같습니다.

이는
기술만 알고 쓸 줄 아는 사람이 결정해서 그런 것이라고 보는데
기술을 알고 쓸 줄 아는 걸 넘어서 기술을 이해하는 사람들이 민주적으로 아키텍처 결정에 대해 논의-협의-결정의 프로세스를 가진다면
당장은 모놀리식으로 시스템을 만든다고 해도, 이후 대응 방향에 대해서 대처가 가능하다고 봅니다.

작년 2024 Academic Conference 책이었던 < 소프트웨어 아키텍처 101 > 에서 언급한
시스템 아키텍처를 결정하고 평가하는 내용을 다시 리뷰해 보고 이해한다면 좋은 가이드라인이 될 거라 생각합니다.

또 제가 현재 고전이라고 불리는 < 소프트웨어 아키텍트가 알아야 할 97 가지 > 를 읽고 있는데
여기서도 비슷한 맥락의 얘기들이 몇 가지 언급되고
핵심적으로 관통하고 있는 주제는
아키텍트는 개발팀과 협의해서 설계를 이해할 수 있게 도와주는 역할이 필요하다 라고 얘기하고 있습니다.

• 제가 생각하는 고전의 기준: 출판된지 15년 이상 해당 주제에 대해 언급한지 20년이 넘은 것
• < 소프트웨어 아키텍트가 알아야 할 97 가지 > 는 원서 출판이 2009년(16년), 번역본 출판이 2011년 (14년) 입니다.

---

조직에서 합리적인 시스템 아키텍처와 설계 결정을 따랐다면
그것이 잘못됐다 아니다는 운영하면서 판단해야 할 부분이지 않을까 생각해 봅니다.

[TaeHyoungKwon]

구글포토에 캡쳐해서 업로드 해두었습니다~ 블라인드 가입 안되신 분들은 제가 캡쳐해둔 것 보셔도 될것 같아요~

https://photos.app.goo.gl/W4XkKzx89twjPYhK8

[wooyaggo86]

태형님 너무 감사합니다 :)

저희 독서모임끝나고 시간 남으면 간단히 이야기 나누는 것도 좋을 것 같아요! cc : @jongfeel