C/C++의 종말? 임베디드 프로그래머도 시대의 흐름에 대비해야 할까?

C/C++은 점점 사라질 것인가?

최근에 우연히 본 글은 제 생각을 더 유연하고 바꾸게 된 계기가 되버린거 같았습니다.

위 글은 C/C++ 과 관련하여 미국 백악관에서 C와 C++을 사용 중단을 촉구한다는 글입니다. 2024년 초에 왠 뚱딴지 같은 글인가 싶어서 내용을 봤더니… 이내 충분히 수긍이 가는 내용이었습니다.

C와 C++은 저도 사용하고 있고 현재에도 여전히 인기리에 사용되는 프로그래밍 언어입니다. 특히 제가 여전히 몸담고 있는 임베디드 관련 업계에도 많이 쓰이는 언어지요. 아직까지는 작은 장치와 임베디드 OS 에서 C나 C++을 대체할 만한 언어는 나오지 않고 있습니다.

그럼에도 이 글에 대한 내용이 수긍이 가는 이유는 무엇일까요? 그리고 미국 백악관에서 굳이 C/C++의 사용을 중단하길 요청하는 이유는 무엇일까요?

C/C++은 치명적인 약점을 지니고 있다

C/C++은 IT나 컴퓨터 업계에서 등장한지 꽤나 오래된 언어입니다. C는 1970년대 나온 언어이고 C++의 경우에는 그보다 조금 늦은 1980년대 중반에 등장하였지요.

위 사진속 “터보 C” 책은 제가 90년대 중반에 산 책입니다. 그 외에 자바나 파이썬 책은 2010년대 들어서 산 책들입니다. 터보 C 책은 중학생 때 산책인데 그때 당시에는 아무리 봐도 이해가 되질 않다가 대학생때 비로소 이해가 되더군요 ㅋ

자바, 파이썬, C 는 현재 프로그래밍 언어 중에서 가장 인기있는 언어들입니다. 그런데 이 언어들 중에서 가장 파워풀하고 메모리 제어를 할 수 있는 C/C++ 은 가장 치명적인 단점 또한 가지고 있습니다. 그것은…

C/C++은 메모리 누수나 버퍼 오버 플로우의 위험에 노출이 되기 쉽다는 점입니다.

C/C++은 컴퓨터 시스템을 프로그래머가 자유 자재로 컨트롤 하는게 가능한 언어입니다. 그래서 OS 를 개발할때도 C/C++을 사용하여 개발하는 경우가 많습니다. 또한 성능을 요하는 “게임”의 경우에도 C/C++로 개발하는 경우가 많습니다.

현재까지 “리눅스 커널”의 경우에도 C 소스로 되어 있습니다. 따라서 리눅스 진영에서는 아직도 커널 및 드라이버 개발을 위해 C를 사용하고 있지요.

이런 시스템 소프트웨어 외에도 성능이 중요시 되는 시스템 소프트웨어는 “C나 C++” 로 아직까지 개발이 되고 있습니다. 임베디드 관련 업계들도 어플리케이션을 C/C++로 개발합니다.

C/C++은 자동차로 비유하자면 성능좋은 “수동 기어” 자동차라고 볼 수 있겠네요.

C나 C++은 자동차로 비유하면 “수동 기어” 자동차와 비슷하다 – 픽사베이

수동 기어 자동차도 연비가 좋고 차 성능이 좋기 때문에 자동차 매니아들은 “수동 기어”를 선호합니다. 또한 자동차 경주 대회에서 사용되는 차들도 대다수가 “수동 기어”가 탑재된 자동차들 일겁니다.

C/C++의 가장 파워풀한 기능은 아무래도 “포인터” 일 겁니다. 프로그래머가 이동하고 싶은 메모리 번지수에 데이터를 복사하거나 값을 넣는게 가능하지요. 그래서 C/C++로 짜여진 코드는 빠르고 성능이 뛰어납니다.

그런데.. 이 C/C++의 파워풀한 특징 때문에 치명적인 약점이 발생합니다. 위에서 언급했던 “메모리 누수” 와 “버퍼 오버 플로우” 지요. C/C++은 특정 영역의 메모리에 접근이 가능하지만 해당 번지 메모리에서 사용된 변수(버퍼)는 잘 처리를 해줘야 합니다.

C/C++은 이같은 특징 때문에 초보 개발자나 경험이 많지 않은 개발자는 C나 C++로 짠 프로그램이 시스템상에 구동되면서 시간이 지날수록 메모리 누수(leak)가 발생하거나 너무 많은 버퍼 사용으로 인해 “버퍼 오버플로우(Buffer Overflow)”가 많이 발생하게 되지요. 즉 이같은 현상은 시스템에 심각한 “버그(Bug)”를 일으키기도 합니다.

인터넷이 발달하기 전에는 이 부분에 대해서 심각성을 느끼지 못하다가 최근에 인터넷이 발달하고 데이터 처리량이 늘어나면서 “무시하지 못할 문제” 가 되버렸나 봅니다. 더군다나 이런 버그를 찾아서 공격하는 “사이버 공격”이 늘어나는 추세인거 같습니다.

보안 그리고 C/C++의 미래?

중학생때 부터 C를 접했고 대학교때 부터 본격적으로 사용했으니 제가 C를 접한지 어느덧 20여년의 세월이 흘렀습니다. 여전히 C에 익숙하고 최근에는 필요에 따라 C++을 사용하여 개발을 하기도 했네요.

그럼에도 “미국 백악관”에서 언급한 문제제기에 대해선 어느정도 공감하는 편입니다. 이제는 C/C++을 대체할 만한 언어가 서서히 등장하고 있기 때문이지요.

C나 C++의 “메모리 관련 버그”는 여전히 존재하는 이슈입니다. 아무리 프로그래머가 꼼꼼하다고 한들 “쓰레기값(Garbage Memory)”를 잘 처리하는게 쉽지 않은거 같습니다. C/C++은 파워풀하지만 그만큼 치명적인 버그의 위험도 지니고 있습니다.

임베디드 시스템 개발에서도 “원인모를 시스템 버그” 는 끊임없이 발생하는 이슈입니다. 제가 몇년전 스타트업회사에서 네트워크 단말을 개발했을 때 “갑자기 시스템이 먹통” 되는 현상을 디버깅 하면서 도저히 그 원인을 찾을 수 없더군요. 단말을 동작하는 어플리케이션은 C/C++로 개발되어 있었습니다.

하드웨어 문제인지 아니면 해당 어플의 오동작인지도 결국 밝혀내지 못했습니다. 여전히 오리무중인 상태로 그 회사를 떠나게 되었는데 만약 해당 어플이 “메모리 안전” 처리만 제대로 했어도 해당 이슈는 발생하지 않았을지도 모릅니다.

C/C++은 시스템 오류에 대해 더 높은 위험성을 지니고 있다 – 픽사베이

C/C++은 분명 성능좋고 파워풀한 언어입니다. 하지만 개발 후 나타날 “메모리 안전” 문제에 대해서는 꽤나 취약한 것도 사실이지요. 최근에 다트나 파이썬을 사용해 보면서 느낀점은 “메모리 안전”이 어느정도 보장되는 언어들은 성능이 다소 떨어지더라도 “시스템 오류” 에 관해서 보다 관대해질 수 있습니다.

소프트웨어 산업이 시간이 지날수록 중요해 지지만 최근 C/C++을 많이 사용하는 임베디드 제조 업계가 다소 쇠퇴하는 느낌과 맞물려 이번 백악관의 가이드 글은 많은 것을 생각하게 합니다.

최근에 임베디드 제조업을 떠나고 FAE로 일을 하면서 C/C++로 개발을 거의 하지 않습니다. 기술적 이슈가 있을 때에 가끔 C/C++ 코드를 보는 정도 입니다.

사실 현재 IT 업계에서 “어플리케이션”을 개발할 때는 C/C++의 사용 빈도는 많이 줄어든거 같습니다. 윈도우즈 어플의 경우에도 C#, 자바스크립트, 파이썬 같은 언어들로 개발이 가능하기 때문입니다. 리눅스 진영에서는 여전히 쓰이고 있지만 과거에 비해 “파이썬” 같은 언어로도 리눅스 어플리케이션도 개발이 가능합니다.

C/C++의 한계 때문에 제가 어플리케이션을 개발해보고 싶다면 굳이 C/C++을 쓸 필요가 없습니다. 최근에 언어들은 객체지향이나 메모리 안전에서 해방된 언어들을 주로 사용하고 있기 때문이지요. 따라서 자바스크립트 기반의 언어나 파이썬들은 어플리케이션을 짤때 꽤나 괜찮은 언어로 손꼽힙니다.

이제 시장의 시선은 “C/C++”의 종말까진 아니더라도 C/C++ 의 사용 비중을 점차 줄이는 추세로 가는거 같아 보이는군요. 성능좋은 CPU와 도구들이 계속 출시가 되고 있고 굳이 C/C++을 사용하지 않아도 괜찮은 어플리케이션 소프트웨어를 개발하는게 가능합니다.

저같아도 “메모리 안전에 위협”이 되는 C/C++을 사용하는거 보다 대체 언어가 있다면 성능이 다소 떨어지더라도 그 언어를 사용하는게 낫겠다는 생각이 드는군요.

그렇다면 C/C++은 뭘로 대체될 것인가?

시장은 C/C++의 사용을 점차 줄여가는 걸로 보이지만 아직까지는 C/C++을 대체하기는 쉽지 않습니다.

이 글을 쓰는 현재 TIOBE 에서 발표한 프로그래밍 언어 사용 순위입니다. 여전히 C/C++은 2024년 현재에도 2,3위에 들정도로 막강한 위치를 차지하고 있습니다.

따라서 당장은 대체하기는 어려울 겁니다. 특히 시스템 프로그래밍을 주로 하는 “리눅스 진영” 에서는 더더욱 C/C++을 대체하기 쉽지는 않습니다. 당장 리눅스 커널이 C로 되어 있기 때문입니다.

하지만 시장은 이미 C/C++을 대체할 만한 언어를 준비해놓고 있습니다. 바로 “러스트(Rust)” 입니다.

C/C++ 대체용으로 모질라재단에서 개발하고 배포하는 언어인 “러스트”는 이미 리눅스 진영에서 서서히 받아들이고 있는 걸로 보입니다. 리눅스 커널의 일부를 러스트로 개발한다는 이야기가 있더군요.

리눅스의 창시자 토발즈도 러스트를 인정하며 커널 6.1 버전에 일부 반영하겠다는 계획을 발표했습니다.

현재 커널은 6.8 버전이 마지막 버전이니 이미 러스트가 커널에 적용이 된거 같군요 ㅋ 위 토발즈의 글이 2022년에 쓰여졌으니 이미 러스트는 커널에 일부 탑재가 된걸로 보입니다.

물론 커널 전체는 아니지만 일부 탑재가 되었다는 것은 그만큼 토발즈도 “러스트”를 어느정도 인정한게 됩니다. 불과 몇년전만 해도 “리눅스 커널 = C” 의 공식이 깨지고 있군요.

이처럼 시장과 프로그래밍 언어는 시대의 흐름에 따라 바뀌는거 같습니다. C는 출시된지 벌써 50년이 지났지만 여전히 사용되는 언어인 만큼 오히려 C나 C++이 장수를 하는거 같아 보이는군요.

이 글을 읽는 임베디드 리눅스 프로그래머 및 리눅스 프로그래머 혹은 C/C++ 프로그래머들께서는 어떤 생각이신가요? 분명한 점은 C/C++는 서서히 다른 언어로 대체가 되어가고 있다는 점입니다.

이제 저도 주변이들에게 “러스트” 를 사용해 보라고 권유를 하고 있습니다. 사람의 언어가 시대에 따라 달라지듯이 컴퓨터 프로그래밍 언어도 시대의 흐름에 따라 달라지는거 같습니다. 저도 대비를 해야 겠군요.

프로그래밍 언어는 수단이 아닌 단지 “도구”일 뿐이다.

'코드도사(codedosa.com)'에는 쿠팡파트너스 등의 제휴링크가 포함되어 있으며 수수료를 제공받을 수 있습니다.