미워 죽어도, 없으면 살 수 없는 7가지 프로그래밍 언어

InfoWorld

원한을 갖지 말라는 선의의 조언은 분명 생계를 위해 컴퓨터와 씨름하던 사람의 입에서 나온 말은 아니었을 것이다. 프로그래밍 언어의 지옥같은 로직과 싸우다 보면 최악의 버그들이 떠다니는 칠흑같은 공허함의 공포를 알게 된다.

물론 누구나 처음에 컴퓨터 언어를 처음 접할 때는 좋아한다. 그리고 3줄의 코드로 언어가 얼마나 강력한지 보여주는 모든 "헬로우 월드(Hello World)"의 예를 보더라도 그렇다.

프로그래밍 언어는 암암리에 논리적으로 정의되지만 어디든 로직을 확산시킨다는 의미는 아니다. 유쾌한 바텐더는 자신의 술집을 방문하는 모든 사람의 인생을 행복하게 만들 수 있다. 용감한 소방관은 용기를 내뿜는다. 하지만 논리적인 프로그래밍 언어 메커니즘은 종종 비논리, 혼란, 의심을 낳는다.

언어가 비논리적이라고 말하는 것은 논리적이지 않지만 어쨌든 논리에는 한계가 있기 때문에 이런 말을 하곤 한다. G&T(Gödel and Turing)에서 우리는 논리적인 메커니즘에도 무서운 일이 발생하는 한계가 있다는 사실을 배웠다.

물론, 개발자도 인간이기 때문에 잘못 사용하거나 잘못 프로그래밍하는 등 사람의 잘못일 수 있다. 하지만 프로그래밍 언어로 인해 자신의 두뇌가 이상한 요가 자세를 취할 수 밖에 없게 된다면 프로그래밍 언어를 탓하지 않을 수 없다.

그리고 할 수 있는 일이 아무 것도 없는 경우가 많이 발생한다. 설치된 기초가 너무 커서 짜증이 나더라도 언어를 포기할 수 없을 수 있다. 직장 상사가 한 스택(Stack)을 너무 좋아해 큐비클 팜(Cubicle Farm)에서 울부짖는 소리는 듣지 못할 수 있다.

더 나은 옵션이 없을 수 있다는 점이 잔인한 현실이다. 우리는 이미 인간이 만들 수 있는 최고의 도구를 사용하고 있다. 여기에서는 개발자들이 싫어하지만 없으면 살 수 없는 7가지 프로그래밍 언어에 관해 살펴보도록 하자.



우리가 싫어하는 언어: C
완전한 컴퓨터 언어라기보다는 "휴대용 어셈블러(Assembler)"라고 부르는 것이 더 나을 수도 있는 언어와 관련된 문제는 많다.

개별적인 헤더(Header) 파일을 작성하기 좋아하는 사람이 있을까? 정교한 일을 위해 전처리 장치를 사용하면서 전혀 화를 내지 않는 사람이 있을까? 이론적으로 놀라운 실력을 위해 소수점 연산의 힘을 활용할 수 있어야 하지만 데이터 구조를 할당하는 것 이상의 위험을 감수하는 사람이 있을까? 지시자(Pointer)를 잘 활용하는 것이 정말로 좋은 것일까?

여기서부터 코드가 깨지기 시작한다. 똑똑할 수 있다면 이를 문서화하기 위해 매우 긴 주석을 작성해야 하며 이로 인해 현명하게 절약해놓은 모든 시간을 소진하게 된다. 버퍼 오버런(Buffer Overrun)과 같은 모든 발생 가능한 보안 구멍의 추가를 막기 위해 C 코드를 작성하는 모든 규칙을 기억하는 사람이 있을까?

하지만 선택의 여지가 없다. 유닉스(Unix)는 C로 작성되어 있으며 대부분의 휴대폰과 클라우드를 구동한다. 이런 플랫폼을 위한 코드를 작성하는 모든 사람이 C를 사용할 필요는 없지만 누군가는 별표와 중괄호를 준수하지 않으면 모든 것을 망치게 된다. 그리고 장치 드라이버와 다른 내장형 프로그램이 있다. 누군가는 책임지고 리눅스(Linux)/유닉스 코드 기반을 발전시켜야 한다.



우리가 싫어하는 언어: 자바스크립트(JavaScript)
자바스크립트의 창시자들은 현대적이기 위해 노력했다. 그들이 너무 똑똑한 나머지 우리는 중괄호, 대괄호, 괄호를 세면서 적절히 망쳐져 있는지 확인하느라 인생을 보내게 되었다. 익명의 함수, 폐쇄성, JSON 데이터 구조 사이에서 새끼손가락은 이런 키를 누르느라 바쁘다.

그리고 이상한 현상도 존재한다. 만약 x가 1을 위한 문자를 유지하는 문자열이라면 x+1은 문자열 11을 생성하고 x-1은 숫자 0을 생성한다. 혹시 false, null, NaN, undefined의 차이점을 기억하는 사람이 있는가? 비슷해 보이지만 자바스크립트에 이 4가지가 모두 있는 이유는 무엇일까? 그리고 왜 동작이 일관되지 않을까?

사실 우리가 얼마나 불평하는 지는 중요하지 않다. 인터넷(World Wide Web)과 방대한 수의 브라우저는 사라지지 않을 것이다. 그리고 똑똑한 Node.js팀 때문에 개발자들은 서버에서 자바스크립트를 작성해야 한다.

비밀은 우리가 이메일을 확인하거나 무엇인가를 구매해야 할 때까지 수초 정도만 지켜진다. 그리고 자바스크립트를 운용될 것이다, 아주 오랫동안.



우리가 싫어하는 언어: PHP
PHP는 사실 컴퓨터 언어가 아니다. 정적인 HTML에 약간의 스마트함을 더하기 위한 도구에 더 가깝다. 데이터베이스에 정보를 저장하고 정적 태그(Tag)로 사슬같이 연결할 수 있다. 몇 가지 기능이 더 있을 수 있지만 우리가 PHP로 하는 일이라고는 우리가 데이터베이스에서 얻은 문자열을 통합하는 수준인 것 같다.

유치한 코드나 신택스(Syntax)에 관한 논쟁으로 인해 문제가 발생해서는 안 된다. 대부분의 웹은 PHP로 구축되고 있다. 워드프레스(WordPress), 줌라(Joomla), 드루팔(Drupal) 사이에서 대부분의 웹 콘텐츠는 PHP 코드를 통해 제공된다.

그리고 PHP로 작성된 페이스북(Facebook)이라는 것이 있으며 "웹에서" 사람들의 시간을 빼앗아 가고 있다. 페이스북이 HHVM(HipHop Virtual Machine)을 개발한 덕분에 젠드(Zend)가 PHP 7.0을 개발할 수 있었다는 사실에 기뻐해야 한다.

이런 새로운 PHP 엔진 덕분에 두 배나 빠르며 저항할 수 없는 과속 방지턱으로 인해 수백만 달러의 전기세를 절약하고 앞으로도 오랫동안 PHP를 사용하게 될 것이다.




우리가 싫어하는 언어: 코볼(Cobol)
코볼은 개발자 대부분이 태어나기 전인 1959년에 시작됐다. 수백 개의 제한된 단어로 구성된 복잡한 신택스로 인해 쓸모가 없다. 하지만 코볼 애호가들은 새로운 버전을 개발하며 다른 언어에서 아이디어를 차용해 거의 60년이나 된 프레임에 적용하고 있다.

코볼 2014라는 이름을 들어 보았는가? 여기에는 사람들이 2002년 이후로 해당 언어에 적용하려 시도했던 동적 테이블이 포함되어 있다. 새로운 것은 그것만이 아니다. 1970년 대에 사장되었다고 알고 있는가? 틀렸다.

데이터베이스 조작을 위해 비즈니스 로직을 작성하는 더 나은 툴이 있었을 수 있지만 더 큰 컴퓨터를 구매해 코볼 코드를 실행하는 것이 더 쉽기 때문에 그 누구도 고생을 자처하고 있지는 않는 것 같다.

이 기사를 작성하는 현 시점에서 다이스(Dice.com))에 게시된 543개의 일자리에 관한 설명에서 '코볼'이라는 단어가 포함되어 있다. 보험사와 국방 계약업체에는 코볼 관련 일자리가 있다.

메인프레임(Mainframe) 얼리 어댑터들은 여전히 코볼을 사용해 처리하고 있다. 컴퓨터 공학자들은 공포심에 뒷걸음질치겠지만 고객들이 줄을 서는 한 이렇게 말할 것이다. "망가지지 않는 한 따로 고치지 마라. 그냥 다른 메인프레임을 사라."



우리가 싫어하는 언어: XSLT
누구나 처음에는 XML을 변환하는 기능적 언어인 XSLT를 좋아한다. 대용량 XML 문서에서 데이터를 추출해야 하는 경우 매우 잘 동작하는 똑똑한 솔루션이다.

하지만 상사가 단순한 찾아 바꾸기 이상의 복잡한 것을 요구하는 경우 개발이 교착 상태에 빠지게 된다. 언어는 분명 기능적이며, 문서에 "변수"라고 써 있는 경우 프로그래머가 아니라 대수학 선생님 같은 언어를 구사한다는 사실을 알게 된다.

이런 젠(Zen) 같은 문장에 대해 XSLT의 전문가 밥 듀캄은 이렇게 말했다. "XSLT 변수는 실제로 여러 프로그래밍 언어의 상수와 공통점이 훨씬 많으며 유사한 용도로 사용되고 있다." 다른 컴퓨터 언어의 변수처럼 동작하는 변수를 사용하고 싶은 경우(즉, 변화가 가능한 경우) 매우 현명하게 대처해야 한다.

XML은 제이슨(JSON)처럼 더욱 효과적인 데이터 형식에 자리를 내어주고 있을 수도 있지만 많은 빅데이터(Big Data) 프로세서에는 여전히 강력한 기초가 되고 있다. XSLT를 사용할 필요가 없다. 항상 텍스트 자체를 분석하는 기본적인 코드를 작성할 수 있다.

하지만 XML을 분석하기 위해 모든 코드를 작성하다 보면 XSLT 구조를 총체적으로 이해하는 것 이상의 일이 될 수 있다.



우리가 싫어하는 언어: 자바(Java)
가상머신(Virtual Machine)과 라이브러리는 1990년대부터 시작되었을 수 있지만 신택스는 여전히 C가 개발된 1970년대 수준이다. 자동 메모리 관리가 대단한 발전처럼 보이지만 가비지 콜렉션(Garbage Collection)이 통제하는 동안 코드가 넋 놓고 있는 모습을 보면 그런 생각이 싹 사라진다.

안드로이드 개발자들은 가비지 콜렉터(Garbage Collector)가 911에 전화를 거는 등의 중요한 상황 중에 시작되지 않도록 하기 위해 사전에 가비지 콜렉션을 정중히 요청하는 시점에 대한 요령을 교환한다.

자바 프로그래머는 많은 문제점에 대해 오랫동안 불평했지만 그 가운데 일부는 해결되었거나 최소한 오라클(Oracle)이 처리하고 있다. 하지만 이로 인해 새로운 문제가 발생하고 있다. 새로운 코드와 라이브러리 일부는 오래된 VM과 호환되지 않는다.

필자는 하루 동안 java.lang.UnsupportedClassVersionError와 씨름했지만 영구적인 해결책을 찾을 수 없었다. 1.4 이후의 각 자바 버전이 다른 언어인 것과 같다.

이런 문제가 중요하지는 않다. 자바는 웹과 휴대폰의 기초다. 개발자들이 처음으로 접하는 언어다. 라이브러리 콜렉션은 다른 거의 모든 언어보다 심오하고 더욱 가치있다. 굳이 다른 것을 사용할 이유가 있을까?



우리가 싫어하는 언어: 파이썬(Python)
젊은 개발자들이 공부하는 현대적인 언어다. 구두점이 드물고 코드가 더 깔끔해 보인다. 싫어할 이유가 있을까? 파이썬 2.7과 3.0 사이에는 공백이 존재한다. 언어를 발전시키기 위해서는 어쩔 수 없는 선택이었지만 이로 인해 자신이 사용하고 있는 신택스를 지속적으로 추적해야 한다. 어떤 버전의 파이썬이 설치되어 있는지 항상 확인해야 한다.

그리고 들여쓰기 한 코드 블록의 모든 공백을 세고 싶은 개발자가 누가 있을까? 중괄호를 세는 것도 힘들지만 공백을 세기 위해서는 고정폭 편집기가 필요하다.

소프트 공학자들은 어려운 과학의 짐을 덜어주는 따뜻하고 부드러운 느낌의 파이썬을 사랑하기 때문에 아무런 문제가 되지 않는다. 생물학자와 경제학자는 파이썬이 유일하다고 생각한다. 심지어 일각에서는 주식과 채권에 관한 새 투자 설명서에 파이썬 코드를 요구하도록 제안하고 있기 때문에 투자 은행들이 엉터리 변호사의 말 대신에 파이썬을 이용해 우리를 혼란에 빠뜨릴 수 있다.

변호사들의 손 끝에서 나오는 소위 말하는 영어보다는 파이썬이 읽기 쉽다는 점이 다행이다. 모든 공백을 세어야 하지만 어쨌든 한 단계 발전한 것이다. 이미 소프트 공학자들로 꽉 찬 버스가 정류장을 출발했다. editor@itworld.co.kr