파이썬과 러스트 모두 경험은 없지만, 글만 놓고 봤을 때.. 러스트 도입에 대한 큰 장점을 느끼지 못하겠어요.
러스트가 안좋다는게 아니라, 러스트 도입을 위해 진행했던 실험도 빈약하고
(고작 메시지 50건 처리결과만 놓고보면 몇배가 더 빠르니 몇배가 더 좋다고 주장하는건 너무 빈약한 전개인 듯 합니다..)
그리고 동일한 처리 로직(동기vs비동기)으로 비교한 것도 아니고요..
[비동기 메시지 처리를 지원하지만 레퍼런스가 많이 없는 파이썬 라이브러리] vs [학습비용이 높고 소수인원에 의한 유지보수risk 가 있는 러스트 언어]
위 두 상황을 놓고 봤을 때, 향후 지속가능성에 대한 부분도 진지하게 고민이 이루어진 것인지도 의문이고요 (적어도 글에서 느끼기엔 그랬습니다)
ETL 특성상 짧게 자주 테스트해야 하는 경우가 많을 것 같은데, 빌드타임 100초 vs 300초는 개발에 있어 큰 병목현상일 것 같은데 말이죠..
증분 빌드가 뛰어나다고 글에서 언급하고 있는데, 이에 대한 내용은 하이퍼링크로 대체하고...
실제로는 열심히 조사하고 검토했을텐데요, 적어도 글에서 느껴지는 바로는.. 진짜 러스트 도입으로 어떤 점이 좋아진건지 기대효과는 무엇이고 무엇을 해결해주었는지 알수도 없고 공감하기도 힘드네요..
개인적으로, '최근 핫한 기술' 내지는 커리어 한줄을 위해 기술을 선택하는 경우를 봐왔는데, 결과적으로 팀내 유지보수하지도 못하고 기술부채로 남았던 경우가 대부분이였습니다.
가령, 워크로드가 작고 순차처리 해도 전혀전혀 문제가 없음에도 kafka니 비동기 처리를 해야한다고 주장하는 경우
(팀내 상황을 고려하지 않고) 비동기 처리에 무엇이 좋다고 하여 적용한 결과, 트러블슈팅도 매우 어렵고 결과적으로 또다른 레거시가 되는 경우....
최근 핫하다는 ooo을 도입하면 무엇이 좋다는 둥.. 하였지만 결국 또 다른 핫한 ooo이 나오니 또 그것이 좋다고 주장함..
물론 위 러스트 글이 그렇다는 건 아니고 그러지 않기를 바라겠지만..
진지하게 고민하지 않고 도입한 기술로 인한 피해는 팀원이 받는다는 사실을 여러 번 겪고나니 저러한 기술 프로모션 글을 읽을 때 더 신중해지는 것 같습니다.
파이썬과 러스트 모두 경험은 없지만, 글만 놓고 봤을 때.. 러스트 도입에 대한 큰 장점을 느끼지 못하겠어요.
러스트가 안좋다는게 아니라, 러스트 도입을 위해 진행했던 실험도 빈약하고
(고작 메시지 50건 처리결과만 놓고보면 몇배가 더 빠르니 몇배가 더 좋다고 주장하는건 너무 빈약한 전개인 듯 합니다..)
그리고 동일한 처리 로직(동기vs비동기)으로 비교한 것도 아니고요..
[비동기 메시지 처리를 지원하지만 레퍼런스가 많이 없는 파이썬 라이브러리] vs [학습비용이 높고 소수인원에 의한 유지보수risk 가 있는 러스트 언어]
위 두 상황을 놓고 봤을 때, 향후 지속가능성에 대한 부분도 진지하게 고민이 이루어진 것인지도 의문이고요 (적어도 글에서 느끼기엔 그랬습니다)
ETL 특성상 짧게 자주 테스트해야 하는 경우가 많을 것 같은데, 빌드타임 100초 vs 300초는 개발에 있어 큰 병목현상일 것 같은데 말이죠..
증분 빌드가 뛰어나다고 글에서 언급하고 있는데, 이에 대한 내용은 하이퍼링크로 대체하고...
실제로는 열심히 조사하고 검토했을텐데요, 적어도 글에서 느껴지는 바로는.. 진짜 러스트 도입으로 어떤 점이 좋아진건지 기대효과는 무엇이고 무엇을 해결해주었는지 알수도 없고 공감하기도 힘드네요..
개인적으로, '최근 핫한 기술' 내지는 커리어 한줄을 위해 기술을 선택하는 경우를 봐왔는데, 결과적으로 팀내 유지보수하지도 못하고 기술부채로 남았던 경우가 대부분이였습니다.
물론 위 러스트 글이 그렇다는 건 아니고 그러지 않기를 바라겠지만..
진지하게 고민하지 않고 도입한 기술로 인한 피해는 팀원이 받는다는 사실을 여러 번 겪고나니 저러한 기술 프로모션 글을 읽을 때 더 신중해지는 것 같습니다.