당신은 구글이 아닙니다 (You Are Not Google)
(blog.bradfieldcs.com)많은 소프트웨어 엔지니어들은 기술 선택에 있어 이성적이지 못하다. 새로운 기술을 선택할 때 실질적인 필요나 문제 정의 없이, 단순히 구글이나 아마존 등 빅테크 기업들이 사용하는 기술이라는 이유로 따라가는 경우가 많다. 예를 들어, MapReduce나 Hadoop은 대규모 데이터 처리를 위해 탄생했지만, 실제로 그만한 데이터 규모가 없는 기업들이 이를 도입하면서 오히려 불필요한 I/O 비용과 기능 손실을 겪는다. 이는 단순한 "기술 숭배(cargo cult)" 현상이다.
글은 이런 무비판적인 모방을 피하기 위해 UNPHAT이라는 체크리스트를 제시한다:
Understand – 문제를 충분히 이해하라.
eNumerate – 다양한 후보를 나열하라.
Paper – 기술이 근거한 논문이나 백서를 읽어보라.
Historical context – 개발된 역사적 맥락을 살펴라.
Advantages – 장단점을 균형 있게 비교하라.
Think – 이 기술이 정말 문제에 적합한지 스스로 생각하라.
글에서는 Cassandra, Kafka, SOA(Service-Oriented Architecture) 같은 기술들이 실제 사용 사례와 맞지 않는 상황에서 무비판적으로 도입된 예시들을 제시한다. 가령 Kafka는 초당 수백만 메시지를 처리하는 링크드인을 위해 만들어졌지만, 하루 수십 건의 트랜잭션밖에 없는 작은 기업에서 사용되는 경우가 있다.
저자는 또한, 구글조차도 MapReduce가 더 이상 적합하지 않다고 판단했을 때 사용을 중단했음을 강조한다. 결국 중요한 건, 기술 자체가 아니라 당신이 풀고자 하는 문제가 무엇인지 정확히 이해하고, 그에 맞는 기술을 선택하는 것이다.
마지막으로 저자는 Pólya, Hamming, Rich Hickey 등도 같은 메시지를 반복해왔음을 언급하며, 핵심은 단순하다:
“생각하라. 그리고 진짜 문제를 이해하라.”
할일이 별로 없으면 쓸데없는 짓들을 하게 되어있죠 ㅎㅎ
쉬운문제도 어렵게 풀어야 뭔가 했다고 생색낼수도 있고. 쉽게하면 쉬운줄아는 사람들도 많고.. ㅎㅎㅎㅎ
저는 위의 내용에 많이 동의합니다!
다만 규모가 작은기업에서 오버엔지니어링을 하게되는 경우가 대기업을 목표로 하는 사람들이 작은 기업에서 그런 툴들의 경험을 쌓기 위해서 라고도 봅니다
물론 대표님은 별로 안좋아하시겠지만요 ㅎㅎ
대기업의 니즈에 맞춰진 툴을 소규모 기업에서도 그대로 쓰게 되는 이유의 8할은 이게 아닐까요. 그걸 제어해야 하는 게 CTO일 텐데, CTO부터가 대기업으로의 이직을 생각하고 있는 경우가 있으니.
결국 기술들이 풀려고 하는 문제와, 그 기술이 나오게 된 맥락을 이해해야 합니다. 글에 나온 예시로는 다음과 같은 것들이 있죠.
- Cassandra -> Facebook 서비스의 Database scale 이슈를 해결하기 위한 솔루션
- Kafka -> Linkedin에서 데이터 처리의 scale 이슈를 해결하기 위한 솔루션
그것들이 풀려는 문제와 내가 풀려고 하는 문제가 align되냐? 를 잘 살펴봐야 한다고 생각합니다.