0. 시작하기 전에..
프로그래밍 언어는 왜 이렇게 많을까요? 나라, 지역에 따라 나뉘는 것도 아닌데, 굳이 이렇게 여러가지로 나뉘어 있을 이유가 있을까요? 특정한 기능 때문에 나뉘어 있다면, 통합해서 사용하면 안될까요? 그리고 왜 이런 것들을 궁금해 해야 할까요?
프로그래밍을 처음 접하고, 프로그래밍 언어와 기술 스택을 정하고, Javascript 기초를 공부하는 지금 “왜 프로그래밍 언어들이 이렇게 많을까?” 를 고민해 보셨나요? c/c++ 와 같은 오랜 시간 지배적인 위치를 차지하고, 최근에 와서야 아주 약간 입지를 약간 위협받는 좋은 언어가 있는데 왜 다른 프로그래밍 언어들은 저렇게 많이 생겨났을까요? 물론 자세한 이야기를 하기에는 알아야 할 지식들이 너무 많고, 새로운 프로그래밍 언어가 생겨나는건 지식적인 측면 이외에 다양한 요인도 있어 완벽하게 설명하기 불가능하겠지만, 그건 나중에 공부하는걸로 두고 그래도 그나마 가장 대표적인 이유를 말씀드리면 "컴파일 여부", “성능/안정성과 편의성의 Trade-off 관계”, “패러다임” 때문입니다.
컴파일이란 지금은 우리가 프로그래밍 언어로 작성한 "소스코드"를 컴퓨터가 알아 들을 수 있도록 번역해주는 일 이라고 생각하시면 좋습니다. 컴퓨터와 스마트폰은 다른 기계들에 비해 엄청나게 대단하고, 똑똑하게 느껴지지만 그들도 결국 별 수 없는 기계입니다. 반도체를 통해서, 0과 1의 구분을 할 수 있을 뿐이죠. 그래서 컴퓨터에 뭔가를 시키거나 저장하거나 하려면 가장 마지막에는 0과 1로 표현된 데이터로 저장을 해야 하고, 0과 1로 표현된 기계어로 번역을 해줘야 합니다. 여기서 우리가 알고있던 "프로그래밍 언어로 작성된 코드"를 "0과 1로 표현된 기계어"로 변환하는 과정을 컴파일이라고 합니다. 그리고 이 컴파일을 하는 시점과 방법을 기준으로 컴파일 언어(C언어, Java, 등)와 인터프리터 언어(Python, Javascript)로 나뉘게 됩니다. 컴파일 언어는 소스코드로 이루어진 프로그램이 실행되기 전에 기계 언어로 여러분이 작성해둔 코드들을 전부 기계어로 바꿔두기 때문에 처음 실행시 컴파일 하는 시간이 필요합니다. 또 번역하는 과정에서 문법을 검사하는 등의 별도의 처리를 거치기에 에러를 미리 마주해야하지만, 런타임에 (프로그램 실행 중간중간에) 번역하는 과정이 없고 실제 프로그램이 실행되는 동안에 문법오류 등 예상치 못한 에러를 마주할 확률이 적어집니다. 반면 인터프리터 언어는 실행과 동시에 한 줄 한 줄 해석하고 실행합니다. 중간언어로 해석하고 실행하기 때문에 별도의 컴파일이 필요없지만, 위에 언급된 컴파일언어의 장점에 해당하는 항목은 일반적으로 반대로 단점으로 작용합니다.
성능/안정성과 편의성의 Trade-off 관계와 같은 것들 역시 지금 모두 설명 할 수 없습니다. 다만 간단히 이해 할 수 있을정도로 언급하자면, 일반적으로 성능과 개발 편의성은 Trade-off의 관계가 성립합니다. 프로그래밍 언어가 실행되는 환경에서 언어 자체적으로 더 많은 것들을 지원 해줄 수록 (메모리 관리, 타입 추론 등) 해당 언어로 작성된 프로그램들의 성능과 때로는 안정성이 "일반적"으로 떨어지게 됩니다. 프로그램이 동작하기 위해서는 크게 두 가지 자원이 필요합니다. "메모리"라는 저장 공간과, "연산 능력"이죠. 메모리에 관해서 여러분이 직접 프로그램에 필요한 메모리의 시작 주소와 그 크기를 할당하고 관리하다가, 해당 저장공간이 필요없어지면 풀어주는 코드까지 작성을 해야한다면, 개발 난이도와 시간이 매우 높아지겠죠? 반대로 적당히 프로그래밍 언어가 최적화 해서 메모리를 할당해주고, 다 썼는지 여부를 추론해서 해당 메모리를 풀어준다면 개발 난이도와 시간은 줄어들겠죠? 물론 그러한 편의성을 가져간 만큼 일반적으로 후자에서는 별도의 처리를 더 하는 것이기 때문에 프로그램 전체적으로 성능에서 손해를 보게 됩니다. 자세한 내용은 "Garbage Collection"으로 구글링 해보시면 조금 더 공부해보실 수 있습니다.
(🤔 저만 모를 것 같지만, Trade-off 관계는 하나를 얻으면 하나를 잃는 관계를 말합니다!)
Q. "그렇다면 고오오오급 개발자가 되기 위해서는, 무조건 어려운 언어를 잘 다루면 될까요?"
A. "그렇지 않습니다!"
이러한 트레이드 오프 관계는 개발자 스스로에게도 일어납니다. 어려운 언어, 쉬운 언어 두개를 똑같이 능숙하게 다루는 고오오오급 개발자가 있다면, 해당 개발자는 상대적으로 어려운 언어로 개발하면 성능이 높은 프로그램을 개발 할 수 있겠지만 반대로 쉬운 언어로 개발 할 때 같은 시간동안 더 많은 프로그램을 작성 할 수 있겠죠!, 물론 이외에도 환경 등 다양한 요인이 있어, 애초에 언어의 선정이 선택이 아닌 경우도 많습니다. 그래서 지금 시작하는 개발자의 입장에서는 본인 상황과 환경, 목적에 가장 적합한 언어로 시작하는 게 맞다고 생각합니다.
❓ 그렇다면 프로그래밍 패러다임은 뭘까요?
프로그래밍 패러다임은 프로그래머에게 프로그래밍의 관점을 갖게 해 주고, 결정하는 역할을 한다. 예를 들어 객체지향 프로그래밍은 프로그래머들이 프로그램을 상호작용하는 객체들의 집합으로 볼 수 있게 하는 반면에, 함수형 프로그래밍은 상태값을 지니지 않는 함수값들의 연속으로 생각할 수 있게 해준다.
출처 : 위키백과
아직 "패러다임"에 대하여 느낌이 잘 오지 않지만 그래도 프로그래머에게 프로그래밍의 관점을 갖게 해주고, 결정하는 역할을 한다는 말이 그나마 이해가 잘 됩니다. 다른 언어와 패러다임을 실제로 겪어보기 전까지는 충분히 와 닿지 않겠지만, 일단 “특정 프로그램을 작성 할 때 설계단계와 개발, 문제 해결을 수행하는데 있어 주요하게 작용하는 특정한 방법론과 사고의 흐름을 공유하고 있으면 패러다임이라고 볼 수 있을 것 같습니다.”
❓ 프로그래밍 언어에서 패러다임은 왜 중요하고, 어떠한 것들이 있을까요?
(물론 특정 패러다임을 메인 패러다임으로 두고 설계된 언어들이 있기도 하고 그러한 설계 철학적인 관점을 고민해야 하겠지만) … 설명하기 쉽게 일반적인 관점에서 이야기하면, 프로그래밍 언어들은 특정 패러다임과 관련한 문법을 지원하거나 지원하지 않기 때문입니다. 예를들어 객체 지향 프로그래밍을 지원하기 위한 클래스 문법과 같이 특정 패러다임을 지원하는 문법이 있느냐 아니냐에 따라서 특정 프로그래밍 언어의 패러다임을 따지는 편 입니다. 그렇다면 이러한 것들(특정 패러다임과 관련한 문법을 제공할 것인지 아닌지)은 누가 정할까요? 프로그래밍 언어를 만든 사람 또는 기관일까요? 아니면 그러한 것들을 관리하는 특정한 사람 또는 기관일까요? 이 부분이 궁금하시면 "프로그래밍 언어 표준"과 "ECMA"에 대하여 검색해보시면 좋을 것 같습니다. 최근에 와서 일반적으로 가장 대표적인 패러다임은 "절차형", "객체지향형", "함수형" 패러다임이 있으며. 지금 당장 공부하시기 보다는 시간을 두고 알아보시면 좋을 것 같습니다.
왜 우리는 이런것들을 궁금해야 할까요?
크게 두가지 이유가 있습니다.
첫 번째로, 이런것들을 찾아다니다 보면 자연스럽게 지금부터 우리가 자바스크립트를 공부하고, 마주하게 될 용어들과 친숙해 질 수 있습니다. 항상 화두가 던져지면 찾아볼 것들은 그만큼 많아집니다. 두 번째로 여러분들이 공부하면서 가지시면 가장 좋을 태도와 관련있습니다. 아직 갈 길이 아주 아주 아주 아주 아주 멀은 개발자이자, 항상 공부하고 있는 중이지만, 그래도 감히 짧은 개발 경험중에 배운 모든 내용을 요약하자면 "컴퓨터는 생각보다 멍청하고, 어떠한 마법같은 신기한 일은 일어나지 않으며, 반대로 당연한 것도 하나도 없어서, 항상 궁금해야 한다" 입니다. 우리가 알아야 할 것들은 너무 방대해서 배워야 할 것들을 모두 가이드 해줄 수 없으며 당연히 직접 다 알려줄 수 없습니다, 하나라도 더 직접 능동적으로 궁금해 해야 하나라도 더 배울 수 있고, 누군가 다 알려주기에는 너무 방대해서 하나라도 더 직접 찾아봐야 조금이나마 더 배울 수 있습니다.
예시 && 키워드 && 참고자료
예시 : "자바스크립트가 객체 지향, 함수형 프로그래밍 스타일에 적합한 고수준의 동적인 인터프리터 언어라는 사실을 아는 것이 도움이 될 것 입니다. 특정 문법은 java와 같은 c계열 언어에서 차용했지만, 일급 함수라는 개념은 스킴에서 가져왔고, 프로토타입에 기반한 상속은 셀프라는 유명하지 않은 언어에서 가져왔습니다."
Last updated
