회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
> 이 글은 'Five Languages That Won’t Ever Die'을 각색하여 작성되었습니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
프로그래밍과 소프트웨어 개발 및 엔지니어링, 그리고 그 모든 폐쇄된 영역과 관련해서 이야기를 하자면, 그 중에서 현실의 일상적인 업무에서 사용되는 언어는 극히 일부에 불과하며, 그런 언어들이 그런 견고한 진입장벽을 뚫고 진입한다는 것은 극도로 어렵다는 것을 알 수 있습니다.
프로그래밍 언어의 인기 추세가 좀처럼 변하지 않는 데에는 몇 가지의 이유들이 있지만, 제가 보기에 가장 큰 이유는 기존 코드베이스와의 하위호환성(backwards compatibility) 때문입니다. 새로운 언어를 소프트웨어 생태계 안으로 도입할 때 발생할 수 있는 가장 커다란 문제점은, 개발자들이 기존에 가지고 있는 언어를 함께 사용할 수 있는 방법을 찾거나, 새로운 언어로 다시 시작해야 한다는 것인데, 이건 그다지 즐거운 선택은 아닙니다.
그리고 이번 글에서는 저의 의견이 이처럼 곳곳에서 나타나고 있습니다. 왜냐하면 뭔가 관련된 일화나 개인적인 의견을 모두 빼고 이런 글을 쓴다는 건 좀처럼 재미가 없기 때문입니다.
이런 사실을 염두에 두고, 절대로, 결코, 절대로 사라지지 않을 다섯 가지의 프로그래밍 언어에 대해서 살펴보도록 하겠습니다.
이들은 논쟁의 여지가 없는 세계의 제왕입니다. 앞서 말한 하위호환성이 필요한 이유도, 프로그래밍 언어의 세계라는 매우 가파른 피라미드의 정점에 앉아 있는 이들 거물 언어 때문입니다. C와 C++은 거의 40년 동안 존재해 왔는데(C의 경우는 50년), 아직도 그 기세가 수그러들 기미가 좀처럼 보이지 않습니다.
이들이 이렇게 인기가 있는 이유는, 위에서도 말했다시피, 예전의 코드베이스에 대한 하위호환성 때문입니다. 그리고 이 두 가지를 함께 묶어 놓은 이유는, 두 언어가 서로 상호운용성(interoperability)를 갖고 있기 때문입니다. 그리고 C++은 원래부터 그러한 점을 염두에 두고 만들어졌습니다. 하위호환성이 왕입니다.
그리고 C나 C++과 마찬가지로, 파이썬이 여전히 그 인기를 지키고 있는 이유도 하위호환성의 필요성 때문이기는 하지만, 파이썬은 그런 점 외에도 사용하기 단순하고 편리하기 때문이기도 합니다. 그리고 이런 점은 앞의 두 언어는 갖고 있지 못한 특성입니다.
파이썬은 진입장벽이 낮아서 초보자들도 얼마든지 배워서 재미있게 사용할 수 있습니다. 제 생각에 아마도 바로 이 점이 파이썬이 가진 생명력의 핵심인 것 같습니다. 사용하기 편하다는 점 말입니다.
하지만 이런 의구심에도 불구하고, 자바는 TIOBE 지수에서 언제나 5위 내의 상위권을 유지하고 있습니다. 즉, 수많은 사람들이 이런 저런 이유로 이 언어를 좋아하고 있다는 것입니다. 그런데 사실 자바가 지향하는 목표를 훨씬 더 멋진 방식으로 달성할 수 있는 더욱 새로운 대안이 있는데도 불구하고 이러한 언어를 좋아하는 사람이 있다는 것이 쉽게 이해가 되지는 않습니다.
개인적으로는 위에서도 말했다시피, 자바는 코드가 부풀려져 있는 경우가 많고 읽는 것도 귀찮습니다. 자바로 된 코드를 읽거나 작성하는 것도 저에게는 전부 쉽지 않은 일입니다.
스위프트는 주식회사 애플이 오브젝티브 C(Objective-C)를 대체하겠다는 목표만으로 도입한 언어입니다. 그리고 오브젝티브 C는 이번 글에서 소개하려고 고려했던 언어이며, 그러지 못해서 결국 아래의 “명예 언어” 목록에 이름을 올려 두었습니다. 애플이 만들고 지원하는 스위프트는 절대로 (아니면 적어도 당분간은) 사라지지 않을 것입니다. 다름 아닌 애플의 일원이라는 이유 때문입니다.
그리고 스위프트는 C, C++, 오브젝티브 C가 장악하고 있었던 공간을 차지하기 위해 싸우는 주요한 경쟁자들 중 하나입니다. 참고로 어떤 사람들은 이러한 경쟁자들의 하나로 러스트(Rust)를 넣기도 합니다. (편파적이었다면 죄송합니다.) 스위프트가 이렇게 경쟁에 참여할 수 있는 이유는, 앞에서 언급했던 언어들처럼 자바나 C#보다 더 낮은 계층에서 작동하도록 만들어졌기 때문입니다. 즉, 스위프트는 단순히 프론트엔드 어플리케이션을 개발하는 것 이상으로 유용하기 때문에 나름의 추종자들이 있는 것입니다.
러스트가 이 목록에 오르지 못한 유일한 이유는 비교적 젊은 언어이며, 애플 같은 후원자가 없다는 사실 때문이었습니다. 물론 마이크로소프트가 최근에 윈도우 런타임(WinRT) 언어 프로젝션(language projection)의 형태로 명백한 지지를 표현하기는 했습니다. 뭐, 그런 게 있습니다.
좋아요
댓글
공유
공유
넷마블 QA실에서는 ‘크래시리포트’라는 시스템을 운영하고 있습니다. 크래시리포트는 게임 실행 과정에서 예상치 못한 종료 현상이 발생할 때, 그 상황을 저장한 데이터를 크래시라 합니다. 이러한 크래시리포트 운영용으로 마련한 엣지 서버 클러스터 환경에서는 신규 파드 추가마다 최소 1분 이상 필요했습니다. 게임 사용자가 언제 급증할지 예측할 수 없기에, 스케줄에 맞춘 확장도 적합하지 않았습니다. 또한 서버에 접속하는 클라이언트의 통신 연결 대기 시간은 대략 10~20초로 설정돼 있어서, 신규 파드를 준비하기 위해 소모하는 1분 동안 누락되는 데이터도 늘어날 수밖에 없었습니다.
여기어때에서는 WorkerNode의 AutoScaling 도구로 Karpenter를 사용하고 있습니다. 일반적으로 POD의 수량이 부족한 상황이 되면 HPA에 의해 POD가 Scale out 되며 신규 배포가 수행됩니다. 이때 WorkerNode에 충분한 공간이 있다면 정상적인 배포가 이루어지겠지만 공간이 부족한 상황이라면 POD는 모두 Pending 상태에 빠집니다. 이러한 상황을 해결하기 위해서는 WorkerNode를 Scale out 해주는 과정이 필요한데 이러한 과정을 담당하는 도구가 Karpenter입니다.
지금 회원가입하고,
요즘IT가 PICK한 뉴스레터를 받아보세요!