2019.06.21

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에 능숙한 개발자라면 보통 큰 어려움 없이 고를 사용할 수 있다.



2019.06.21

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에 능숙한 개발자라면 보통 큰 어려움 없이 고를 사용할 수 있다.



X