Go vs Bun, Go 언어는 정말 JS 런타임보다 빠를까?
(tsboard.dev)핵심 결론
- Go 언어는 항상 빠르지 않습니다. 오히려 JS 런타임이 더 빠를 수도 있습니다.
- Go는 단순성과 효율성을 자랑하지만, 실제 환경에서는 예상보다 성능이 저조할 때가 있습니다.
- 특히 데이터베이스 I/O가 많은 상황에서 Bun과 같은 JavaScript 런타임에 비해 성능이 떨어질 수 있습니다.
벤치마크 결과
- Go는 더 높은 요청 처리량과 낮은 메모리 사용량을 보였지만, CPU 사용량은 2~3배 높았습니다.
- 하지만 DB I/O가 많은 리얼 월드 환경에서는 Bun(Elysia 프레임워크와 MySQL2 라이브러리 조합)이 더 안정적이고 효율적인 성능을 보였습니다.
- 표준 HTTP 라우터는 성능이 낮아 Fiber 프레임워크로 전환 후, Bun에 비슷한 응답 속도를 얻었습니다. (Go 표준 HTTP Router는 쓰지마세요!)
이 벤치마크를 진행하며 생각해본 Go의 장점
- 다양한 원시 타입과 타입 안정성을 제공 해주는 것.
- 단일 바이너리 배포: 간단한 실행 파일로 배포 가능, 런타임 종속성 제거.
- 고루틴: 병렬 처리를 효율적으로 지원, 적절히 사용하면 하드웨어 성능을 극대화.
이번 벤치마크를 통해 느낀 한계와 개선 여지
- 의심되는 MySQL 드라이버 성능 문제: Go의 go-mysql-driver는 안정적이지만 느리며, JavaScript의 mysql2보다 성능이 부족해 보입니다. (물론 제가 잘못 생각하는 걸 수도 있지만요)
- DB 연결이 없는 작업에서는 Go가 더 좋은 성능을 보입니다. 어쩌면 이건 당연할수도 있겠네요.
- HTTP 라우터의 낮은 성능: 정신 건강을 위해 Fiber나 다른 프레임워크를 사용하세요!
성능 불만족이지만 Go를 계속 사용하려는 이유
- Go의 타입 안정성, 단일 바이너리 배포, 고루틴의 병렬 처리 성능 등이 개발자로서 매력적입니다. 타입스크립트로는 채울 수 없는 타입들과 npm install 이 필요없는 싱글 바이너리 파일 배포, 이 점이 정말 큰 메리트였습니다.
- 추가적인 성능 최적화 가능성을 보고 Go를 더 학습하며 사용해보기로 결정하게 되었습니다.
개발자들에게 전하는 말
- 모든 언어와 기술에는 장단점이 있습니다. Go 언어 역시 마찬가지라 생각합니다.
- Go의 성능에 실망하기보다는 장점을 잘 활용하고, 성능의 한계를 돌파할 수 있는 수단을 계속 찾아가보면 좋겠습니다.
- Go를 사용하는 개발자들에게 이런 분석 결과도 있구나 하는 정보를 공유하고자 글을 작성하였습니다.
저도 저 폰트가 정말 마음에 들어서 사용했는데, 딱 하나 아쉬운 점이 해상도가 낮은 모니터로 보면 또 유난히 이쁘지 않습니다. ㅎㅎ 5K 모니터로 보면 진짜 이쁘더라구요!
저도 궁금합니다 이 결과가 mysql에 국한된 문제인지, 아니면 DB를 사용하는 모든 시나리오에 해당되는지. 언젠가 다른 분들이 결과를 공유해 주실거라 생각합니다 ㅎㅎ
무언가를 비판하는것은 정말 조심스러워야 한다고 생각합니다.
언어차원의 이슈인지 특정 라이브러리 이슈인지 코드상의 이슈인지도 모호하고, 다른사람이 재현하기에 충분한 정보도 제공하지 않은 상태에서 무언가가 안좋다 라고 공개적으로 주장하는것은
그러한 의도가 없으셨다 하더라도 해당 생태계에 살아가는 사람들에게 있어 기분이 좋은 내용은 아닌 것 같습니다.
안녕하세요! 먼저 소중한 의견 남겨주셔서 감사합니다. 말씀하신 내용에 대해서 어떤 마음으로 의견을 남겨주신 건지 이해가 되며, 행여 Go 언어의 미래나 사용자 등을 비난한 것처럼 느껴지셨다면 그게 아니었다는 점 다시 한 번 말씀드리면서 사과를 드리겠습니다. 그리고 혹시 괜찮으시다면, 글 제목을 클릭해보시면 여러 데이터와 추가적으로 다른 분의 블로그 글도 있사오니 (조금 길긴 하지만) 읽어주시면 보다 확실히 제 의도를 파악하실 수 있으리라 생각합니다.
저는 언어가 일종의 자동차 같다는 생각이 듭니다. 차마다 여러 장단점이 있고, 구매하는 데 저마다 다른 비용이 들며, 같은 역할을 하는 거 같지만 서로 다른 가치를 추구하는 점 등이 닮았다고 생각하고 있습니다. 물론 해당 차량을 특별히 아끼고 사랑하는 마음을 가지는 것도 당연하다고 생각합니다. 저도 제 차를 사랑하고 차량 제조사를 신뢰하니까요.
그럼에도, 저 역시 제 차에 대해 가지는 아쉬운 점이나 불만사항들이 있고, 차량 모델들을 주기적으로 리뷰하는 리뷰어들은 늘 경쟁 모델들과 함께 여러 방면에서 비교하면서 내용들을 공유해주고 있습니다. 누군가가 제 차에 대해 변속기 성능이 별로라고 하거나, 연비가 나쁘다고 말하면 저도 사실 기분은 좋지 않습니다만, 그럼에도 운전자인 저와 차는 분리해서 생각하려고 노력하는 편입니다. 또한 제가 운행하는 차에 대해 장점이든 단점이든 더 많이 알아보려고 노력하는 편입니다. 어쩌면 또 다른 차를 탈 수도 있겠지만, 지금의 운전 경험이 그 때도 여전히 도움이 될테니까요.
요약 버전에서는 언급을 많이 못했지만, 블로그 본문에서는 Go의 아쉬운 점에도 불구하고 여전히 장점이 더 많기 때문에 계속 사용(=운전)해 보려고 한다는 내용으로 마무리를 하였습니다. 저는 언어마다 추구하는 가치나 장점이 서로 다르기 때문에, 최대한 다양한 언어(=차량)를 사용해 보려고 노력하는 편입니다. 잘 쓰던 JS 런타임을 두고 굳이 Go언어로 넘어가려는 이유도 그렇구요.
최대한 불필요한 언어 논쟁이 벌어지지 않도록 제 나름대로 세심히 글을 썼다고 생각했습니다만, 그럼에도 이 글을 보시고 기분이 언짢으신 Gopher 분들이 계시다면 다시 한 번 마음을 풀어주시기를 바라며, 저는 그렇게 욕먹었던 PHP 언어도 사랑하는 낭만 코더라는 점을 밝히면서 댓글을 마무리 하겠습니다!
TMI 이긴 하지만 Go 의 std 라이브러리는 시간이 지날수록 성능이 떨어지고 있습니다. 주된 이유는 RFC 표준 준수를 위해 다양한 기능들이 추가되면서 보고되는 수많은 보안 취약점에 대한 trade off 입니다.
최근에는 FIPS 인증을 통과하기 위해서 아마 성능적인 손해는 좀 더 커질것으로 예상되는 상황입니다.
이러한 배경들을 전부 처내고, 가장 간단한 특정 시나리오에 대해서 성능이 안좋다 한마디만 써두는것은 많은 사람들로 하여금 오해를 불러일으키기에 충분할것으로 생각되네요 ㅠ
원문에는 느린 부분에 대한 필자 나름대로의 분석과 그럼에도 불구하고 고를 사용하겠다는 이유가 적혀있는데 무슨 이유로 이 글을 가치판단으로 받아들이신 건지 잘 이해가 안 됩니다
이번 벤치마크를 통해서 저도 새롭게 발견(?)한 것인데, 안정성도 크게 문제 없는 수준이라 감히 말씀드릴 수 있을 것 같습니다. 멀티스레드는 확실히 오케스트레이션(이렇게 쓰는 게 맞나 모르겠네요)이 필요하니까 조금 번거로운 건 사실입니다.
안녕하세요! 댓글로 알려주셔서 감사드립니다 ㅎㅎ 아직 호스팅으로 사이트를 옮기질 못해서 간혹 접속에 장애가 있습니다! 가급적 빠른 시일 내로 조치해 놓겠습니다. (지금은 집에서 미니PC가 열일중입니다 😂)