C 프로그래밍 언어가 여전히 최고인 이유 : 개발언어 일대일 비교

Serdar Yegulalp | InfoWorld

어느 기술이든 다른 기술보다 어떤 일을 특별히 잘 하지 않는 50년 이상 살아남을 수는 없다. 더구나 컴퓨터 기술이라면 두 말할 필요도 없다. 그런데 C 프로그래밍 언어는 1972년부터 사용되기 시작해 소프트웨어로 움직이는 지금 시대에도 핵심적인 구성요소 중 하나로 확고히 자리를 잡고 있다.

그러나 사람들이 굳이 대체할 필요성을 느끼지 못하는 이유로 장기간 생존하는 기술도 있다. 지난 수십년 동안 다른 많은 언어가 나타났고, 그 중에서는 노골적으로 C의 아성에 도전한 언어도 있다. 일부는 인기를 끌면서 C의 자리를 가장자리부터 조금씩 갉아먹기도 했다.
 

ⓒ GettyIamgesBank

C를 대체해야 할 필요성을 주장하기는 어렵지 않다. 프로그래밍 언어에 대한 연구, 소프트웨어 개발 관행, 모두 C보다 훨씬 더 나은 방법이 있다. 그러나 수십년에 걸친 연구개발이 뒷받침하는 C의 위상에는 변함이 없다. C는 성능, 기계적 호환성, 보편성 면에서 다른 언어에 비해 월등히 뛰어나다. 다른 주요 언어와 C를 비교해 보는 것도 나름 의미 있는 일일 것이다.
 

C vs. C++ 

C의 가장 흔한 비교 상대는 당연히 C++다. 이름에서 알 수 있듯이 C++는 C의 확장판으로 개발됐다. C++가 C와 다른 점을 요약하자면 광범위함, 또는 받아들이는 사람에 따라서는 과잉이라고 할 수 있다.

구문과 접근 방식은 C와 비슷하지만 C++에는 네임스페이스, 템플릿, 예외, 자동 메모리 관리 등 C에서 기본적으로 제공하지 않는 정말로 유용한 기능도 많다. 데이터베이스나 머신 러닝 시스템과 같이 최상급 성능을 요구하는 프로젝트는 시스템의 모든 성능을 남김없이 활용하기 위해 C++의 이러한 기능을 사용해서 작성되는 경우가 많다.

또한 C++는 C에 비해 훨씬 더 적극적으로 확장을 지속하고 있다. 곧 나올 C++ 20은 모듈, 코루틴, 동기화 라이브러리, 템플릿을 더 쉽게 사용할 수 있게 해주는 개념을 비롯해서 더욱 많은 기능을 새롭게 제공한다. 반면 C 표준의 최신 리비전을 보면 추가 기능은 거의 없고 하위 호환성을 유지하는 데 중점을 두고 있다.

C++의 모든 장점은 동시에 단점이 되기도 하는데, 이 단점이 크다. C++ 기능을 많이 사용할수록 복잡성은 더 높아지고 결과를 통제하기가 더 어려워진다. 개발자는 C++의 특정 부분만 한정적으로 사용함으로써 C++의 가장 큰 함정과 과잉을 대부분 피해갈 수 있다. 일부 기업은 C++의 복잡성을 원천적으로 차단하기도 한다. C를 고수하면 개발자는 C 하위 집합 내에서만 작업하게 된다. 예를 들어 리눅스 커널 개발 팀은 C++를 기피한다.

C++의 과잉을 피하는 방법은 C를 선택해서 강제적인 미니멀리즘을 수용하는 것이다. 코드를 작성하는 본인뿐만 아니라 이후 이 코드를 유지보수해야 하는 개발자를 위해서도 그게 낫다. 물론 C++에는 그 나름의 용도가 분명한 고수준 기능이 풍부하게 있다. 그러나 현재와 미래의 프로젝트, 그리고 프로젝트 팀에 미니멀리즘이 더 적합하다면 C가 더 타당한 선택이다.
 

C vs. 자바

자바는 탄생 후 수십 년이 지난 지금까지 여전히 기업 소프트웨어 개발의 주축이며, 전반적인 개발의 대표 주자이기도 하다. 아파치 소프트웨어 재단 프로젝트의 대다수를 포함해서 가장 중요한 기업 소프트웨어 프로젝트의 상당수가 자바로 작성됐으며, 엔터프라이즈급 요구 사항이 있는 새로운 프로젝트를 개발할 때 여전히 유력한 언어다.

자바 구문은 C와 C++에서 상당 부분을 차용했다. 그러나 C와 달리 자바는 기본적으로 네이티브 코드로 컴파일되지 않는다. 대신 자바 런타임 환경, JVM, JIT(Just-In-Time)가 대상 환경에서 실행되도록 자바 코드를 컴파일한다. 적절한 조건 하에서 JIT로 컴파일된 자바 코드는 C의 성능에 근접하거나 넘어서기도 한다.

또한 “한 번 작성해서 모든 곳에서 실행한다”는 자바의 기본 원칙 덕분에 자바 프로그램은 비교적 적은 조정을 거쳐 다양한 대상 아키텍처에서 실행할 수 있다. C는 상당히 많은 아키텍처로 이식되긴 했지만 C 프로그램을 예를 들어 리눅스에서 윈도우로 가져와서 적절히 실행하려면 이런저런 맞춤 작업이 필요한 경우가 많다.

이러한 이식성과 강력한 성능의 조합, 그리고 방대한 소프트웨어 라이브러리 및 프레임워크 생태계 덕분에 자바는 기업 애플리케이션 빌드에서 가장 선호되는 언어이자 런타임이다.

자바가 C에 비해 떨어지는 부분은 기계와 근접한 위치에서 실행되거나 하드웨어를 직접 다루는 경우인데, 이는 애초에 의도된 자바의 주력 분야가 아니다. C 코드는 기계 코드로 컴파일되어 프로세스에 의해 직접 실행된다. 자바는 중간 코드인 바이트코드로 컴파일되며 JVM 인터프리터가 이 바이트코드를 기계 코드로 변환한다. 또한 자바의 자동 메모리 관리는 대부분의 환경에서 유용하지만 제한된 메모리 리소스를 최적으로 사용해야 하는 프로그램에는 C가 더 낫다.

그래도 자바가 속도 측면에서 C에 근접하는 영역이 몇 가지 있다. JVM의 JIT 엔진은 프로그램 동작을 기반으로 런타임에 루틴을 최적화해서 사전 컴파일되는 C에서는 불가능한 다양한 종류의 최적화를 실현한다. 또한 자바 런타임은 메모리 관리를 자동화하는데, 일부 새로운 애플리케이션은 이를 우회하여 작동한다. 예를 들어 아파치 스파크는 JVM을 피해가는 맞춤형 메모리 관리 코드를 사용해서 메모리 내 프로세싱을 최적화한다.
 

C vs. C#과 닷넷

C#과 닷넷 프레임워크는 출시되고 20년 가까이 기업 소프트웨어 분야에서 주요한 언어로 사용되고 있다. 보통 C#과 닷넷을 두고 자바에 대한 마이크로소프트의 대응이라고 말한다(관리형 코드 컴파일러 시스템과 범용 런타임). 또한 C와 자바의 비교만큼 C와 C#/닷넷과의 비교도 많다.

자바(및 파이썬 일부분)와 마찬가지로 닷넷은 다양한 플랫폼 간 이식성과 방대한 통합 소프트웨어 생태계를 제공한다. 닷넷 분야에서 기업용 개발이 얼마나 많이 이뤄지는지를 감안하면 결코 작은 이점이 아니다. C# 또는 다른 닷넷 언어로 프로그램을 개발하는 경우 닷넷 런타임용으로 작성된 무수한 툴과 라이브러리를 활용할 수 있다.

자바와 비슷한 또 다른 닷넷의 장점은 JIT 최적화다. C#과 닷넷 프로그램은 C와 마찬가지로 사전 컴파일이 가능하지만, 주로 닷넷 런타임에 의해 JIT로 컴파일되며 런타임 정보를 사용해 최적화된다. JIT 컴파일은 닷넷 프로그램 실행을 위한, C에서는 수행할 수 없는 다양한 종류의 즉각적인 최적화를 가능하게 해준다.

C#과 닷넷은 C와 마찬가지로 메모리 직접 액세스를 위한 다양한 메커니즘을 제공한다. 힙, 스택, 비관리형 시스템 메모리, 모두 닷넷 API와 객체를 통해 액세스할 수 있다. 또한 개발자는 닷넷의 unsafe 모드를 사용해서 성능을 더 높일 수도 있다.

장점만 있는 것은 아니다. 관리형 객체와 unsafe 객체를 임의로 교환할 수 없고, 둘 사이의 마샬링은 성능에 영향을 미친다. 따라서 닷넷 애플리케이션의 성능을 극대화한다는 것은 관리형 객체와 비관리형 객체 간의 이동을 최소화한다는 의미다.

관리형과 비관리형 메모리 간의 불이익을 용인할 수 없는 경우, 또는 닷넷 런타임이 대상 환경에 적합하지 않거나(예를 들어 커널 공간) 아예 제공되지 않는 경우에는 C가 필요하다. C# 및 닷넷과 달리 C에서는 기본적으로 직접 메모리 액세스가 해제되어 있다.
 

C vs. 구글 고

고 구문을 보면 구분자 역할을 하는 중괄호, 문을 종결하는 세미콜론 등 C에서 가져온 요소가 많다. 네임스페이스, 패키지 관리와 같은 새로운 고 기능을 감안하더라도 C에 능숙한 개발자라면 보통 큰 어려움 없이 고를 사용할 수 있다.

고의 주요 설계 기준 중 하나는 읽기 편한 코드다. 즉, 고 프로젝트에 새로 참여한 개발자라도 손쉽게 진행 상황을 파악하고 즉시 코드베이스를 능숙하게 다룰 수 있도록 하는 데 초점을 두고 만들어진 언어다. C 코드베이스의 경우 프로젝트 및 팀에서 사용하는 온갖 매크로와 #ifdef로 뒤범벅이 되기 쉬운 만큼 알아보기가 어렵다. 고의 구문과 기본 코드 서식과 프로젝트 관리 툴은 이와 같은 C의 제도적 문제점들을 방지해준다.

또한 고에는 고루틴, 채널, 구성 요소 간 메시지 전달과 동시성을 처리하기 위한 언어 수준 툴 등의 부가적인 기능도 있다. C에서 이와 같은 작업을 하려면 수동으로 하거나 외부 라이브러리의 도움을 받아야 하지만, 고는 기본적으로 제공하므로 이러한 요소가 필요한 소프트웨어를 더욱 쉽게 구축할 수 있다.

고가 내부적으로 C와 다른 점은 메모리 관리다. 고 객체는 기본적으로 자동으로 관리되고 가비지로 수집된다. 대부분의 프로그래밍 작업에서는 매우 편리하지만, 결정적(deterministic) 메모리 취급이 필요한 프로그램은 작성하기가 더 어렵다는 이면도 있다.

고에는 Pointer 형식으로 임의 메모리를 읽고 쓰는 것과 같은 형식 취급 안전성을 피하기 위한 unsafe 패키지가 포함되어 있다. 그러나 unsafe에는 “unsafe로 작성된 프로그램은 이식이 불가능할 수 있고 고 1 호환성 가이드라인으로 보호되지 않는다”는 경고가 따른다.

고는 세분화된 조작이 거의 필요 없는 명령줄 유틸리티, 네트워크 서비스와 같은 프로그램을 만드는 데 적합하다. 그러나 저수준 디바이스 드라이버, 커널 공간 운영체제 구성 요소, 기타 메모리 레이아웃 및 관리에 대한 정확한 제어가 필요한 작업은 C로 만드는 것이 최선이다.

C vs. 러스트

어떤 면에서 러스트는 메모리 관리의 어려움을 비롯해 C와 C++ 언어의 다른 여러 단점에 대한 해결 방안으로 볼 수 있다. 러스트는 네이티브 기계 코드로 컴파일되므로 성능에 있어서는 C와 동급으로 간주된다. 그러나 러스트의 가장 큰 매력 포인트는 기본적으로 확보되는 메모리 안전성이다.

러스트의 구문과 컴파일 규칙은 개발자가 일반적인 메모리 관리 실수를 피하는 데 도움이 된다. 프로그램에 러스트 구문에 맞지 않는 메모리 관리 문제가 있으면 컴파일 자체가 되지 않는다. 러스트를 처음 접하는 경우, 특히 C와 같이 이러한 버그의 여지가 큰 언어에서 건너온 사람들은 컴파일러를 조심스럽게 다루는 방법을 익히는 데 많은 시간을 소비하게 된다. 그러나 러스트 지지자들은 이와 같은 잠깐의 어려움이 장기적인 보상, 즉 속도를 희생하지 않는 더 안전한 코드를 제공한다고 주장한다. 

러스트의 툴도 C보다 낫다. 프로젝트 및 구성요소 관리는 고와 마찬가지로 러스트에서도 기본적으로 툴체인에 포함된다. 패키지 관리, 프로젝트 폴더 정리를 비롯해 다른 많은 부분을 처리하는 기본 방법이 제공된다. C에서는 각 프로젝트 및 팀마다 처리하는 방법도 다르고, 기껏해야 임시 방편으로 다룰 수밖에 없다.

그러나 러스트에서 장점으로 강조하는 기능이 C 개발자에게는 장점으로 보이지 않는 경우도 있다. 러스트의 컴파일 타임 안전 기능은 비활성화할 수 없으므로 아주 사소한 러스트 프로그램이라도 러스트의 메모리 안전 제약을 따라야 한다. C는 기본적으로 덜 안전할 수 있지만, 훨씬 더 유연하며 필요한 부분에서 관대하다.

또 다른 잠재적 단점은 러스트 언어의 크기다. C는 표준 라이브러리를 감안하더라도 상대적으로 기능의 수가 적다. 러스트의 기능은 대단히 많고 지금도 계속 확장 중이다. C++와 마찬가지로 러스트 역시 기능이 많은 만큼 더 강력하지만 더 복잡하기도 하다. C는 기능 면에서 더 작은 언어지만 정신적으로 모델링하기가 훨씬 더 쉬우므로 러스트가 부담스러운 프로젝트에는 C가 더 적합하다.
 

C vs. 파이썬

요즘 소프트웨어 개발에 대한 대화에서 빠지지 않는 주제가 바로 파이썬이다. 파이썬은 “모든 용도에서 두 번째로 좋은 언어”이며, 수천 개의 서드파티 라이브러리에 힘입어 가장 다방면에 유용한 언어 중 하나다.

파이썬이 강조하는 부분이자 C와 구분되는 점은 실행 속도보다 개발 속도를 우선한다는 점이다. C 등의 다른 언어로 짜는 데 한 시간 정도가 걸리는 프로그램을 파이썬에서는 몇 분만에 만들 수 있다. 반면 이 프로그램을 실행하는 시간은 C에서 몇 초라면 파이썬에서는 몇 분이 걸릴 수 있다(일반적으로 파이썬 프로그램은 같은 프로그램의 C 버전에 비해 한 자릿수만큼의 시간이 더 걸린다고 보면 거의 정확하다). 그러나 현대 하드웨어에서 실행되는 많은 작업에서 파이썬도 충분히 빠르며, 바로 이 점이 파이썬의 핵심 인기 요인으로 작용하고 있다.

또 한가지 큰 차이점은 메모리 관리다. 파이썬 프로그램은 파이썬 런타임에 의해 전적으로 메모리가 관리되므로 개발자는 메모리 할당과 해제에 일일이 신경을 쓸 필요가 없다. 그러나 이 장점 역시 공짜는 아니다. 개발자가 편한 만큼 런타임 성능은 떨어지게 된다. C 프로그램을 작성할 때는 메모리 관리에 세심하게 신경을 써야 하지만, 대신 그렇게 만든 프로그램의 속도는 순수한 기계의 속도 그대로다.

그러나 내부적으로 파이썬과 C는 깊게 연관된다. 레퍼런스 파이썬 런타임은 C로 작성됐으며, 덕분에 파이썬 프로그램은 C 및 C++로 작성된 라이브러리를 래핑할 수 있다. 머신러닝을 비롯한 파이썬 서드파티 라이브러리 생태계의 상당 부분은 근간에 C 코드를 두고 있다.

개발 속도가 실행 속도보다 중요하고 프로그램의 영구적인 부분을 거의 다 독립적인 구성요소로 격리할 수 있다면(코드 전반에 분산시키는 것이 아닌) 순수 파이썬 또는 파이썬과 C 라이브러리의 혼합이 C 단독보다 더 나은 선택이고, 그렇지 않은 경우에는 여전히 C가 최선이다.  editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/news/124767?page=0,1#csidx3f941ced1135eacbfb0da4fd1a3f0bd