C/C++의 종말? 임베디드 프로그래머도 시대의 흐름에 대비해야 할까?
목차
C/C++은 점점 사라질 것인가?
최근에 우연히 본 글은 제 생각을 더 유연하고 바꾸게 된 계기가 되버린거 같았습니다.
![](https://files.ciokorea.com/2024/02/GettyImages-802124242.640x480.jpg)
위 글은 C/C++ 과 관련하여 미국 백악관에서 C와 C++을 사용 중단을 촉구한다는 글입니다. 2024년 초에 왠 뚱딴지 같은 글인가 싶어서 내용을 봤더니… 이내 충분히 수긍이 가는 내용이었습니다.
C와 C++은 저도 사용하고 있고 현재에도 여전히 인기리에 사용되는 프로그래밍 언어입니다. 특히 제가 여전히 몸담고 있는 임베디드 관련 업계에도 많이 쓰이는 언어지요. 아직까지는 작은 장치와 임베디드 OS 에서 C나 C++을 대체할 만한 언어는 나오지 않고 있습니다.
그럼에도 이 글에 대한 내용이 수긍이 가는 이유는 무엇일까요? 그리고 미국 백악관에서 굳이 C/C++의 사용을 중단하길 요청하는 이유는 무엇일까요?
C/C++은 치명적인 약점을 지니고 있다
C/C++은 IT나 컴퓨터 업계에서 등장한지 꽤나 오래된 언어입니다. C는 1970년대 나온 언어이고 C++의 경우에는 그보다 조금 늦은 1980년대 중반에 등장하였지요.
![](http://codedosa.com/wp-content/uploads/2018/11/Coding_20190630_120737-1024x768.jpg)
위 사진속 “터보 C” 책은 제가 90년대 중반에 산 책입니다. 그 외에 자바나 파이썬 책은 2010년대 들어서 산 책들입니다. 터보 C 책은 중학생 때 산책인데 그때 당시에는 아무리 봐도 이해가 되질 않다가 대학생때 비로소 이해가 되더군요 ㅋ
자바, 파이썬, C 는 현재 프로그래밍 언어 중에서 가장 인기있는 언어들입니다. 그런데 이 언어들 중에서 가장 파워풀하고 메모리 제어를 할 수 있는 C/C++ 은 가장 치명적인 단점 또한 가지고 있습니다. 그것은…
C/C++은 메모리 누수나 버퍼 오버 플로우의 위험에 노출이 되기 쉽다는 점입니다.
C/C++은 컴퓨터 시스템을 프로그래머가 자유 자재로 컨트롤 하는게 가능한 언어입니다. 그래서 OS 를 개발할때도 C/C++을 사용하여 개발하는 경우가 많습니다. 또한 성능을 요하는 “게임”의 경우에도 C/C++로 개발하는 경우가 많습니다.
현재까지 “리눅스 커널”의 경우에도 C 소스로 되어 있습니다. 따라서 리눅스 진영에서는 아직도 커널 및 드라이버 개발을 위해 C를 사용하고 있지요.
이런 시스템 소프트웨어 외에도 성능이 중요시 되는 시스템 소프트웨어는 “C나 C++” 로 아직까지 개발이 되고 있습니다. 임베디드 관련 업계들도 어플리케이션을 C/C++로 개발합니다.
C/C++은 자동차로 비유하자면 성능좋은 “수동 기어” 자동차라고 볼 수 있겠네요.
![](https://codedosa.com/wp-content/uploads/2024/03/audi-1214054_1280-1024x682.webp)
수동 기어 자동차도 연비가 좋고 차 성능이 좋기 때문에 자동차 매니아들은 “수동 기어”를 선호합니다. 또한 자동차 경주 대회에서 사용되는 차들도 대다수가 “수동 기어”가 탑재된 자동차들 일겁니다.
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++로 개발되어 있었습니다.
하드웨어 문제인지 아니면 해당 어플의 오동작인지도 결국 밝혀내지 못했습니다. 여전히 오리무중인 상태로 그 회사를 떠나게 되었는데 만약 해당 어플이 “메모리 안전” 처리만 제대로 했어도 해당 이슈는 발생하지 않았을지도 모릅니다.
![](https://codedosa.com/wp-content/uploads/2024/03/laptop-5906264_1280-1024x634.webp)
C/C++은 분명 성능좋고 파워풀한 언어입니다. 하지만 개발 후 나타날 “메모리 안전” 문제에 대해서는 꽤나 취약한 것도 사실이지요. 최근에 다트나 파이썬을 사용해 보면서 느낀점은 “메모리 안전”이 어느정도 보장되는 언어들은 성능이 다소 떨어지더라도 “시스템 오류” 에 관해서 보다 관대해질 수 있습니다.
소프트웨어 산업이 시간이 지날수록 중요해 지지만 최근 C/C++을 많이 사용하는 임베디드 제조 업계가 다소 쇠퇴하는 느낌과 맞물려 이번 백악관의 가이드 글은 많은 것을 생각하게 합니다.
![](https://codedosa.com/wp-content/uploads/2022/09/beautiful-girl-1516635_1280.jpg)
최근에 임베디드 제조업을 떠나고 FAE로 일을 하면서 C/C++로 개발을 거의 하지 않습니다. 기술적 이슈가 있을 때에 가끔 C/C++ 코드를 보는 정도 입니다.
사실 현재 IT 업계에서 “어플리케이션”을 개발할 때는 C/C++의 사용 빈도는 많이 줄어든거 같습니다. 윈도우즈 어플의 경우에도 C#, 자바스크립트, 파이썬 같은 언어들로 개발이 가능하기 때문입니다. 리눅스 진영에서는 여전히 쓰이고 있지만 과거에 비해 “파이썬” 같은 언어로도 리눅스 어플리케이션도 개발이 가능합니다.
C/C++의 한계 때문에 제가 어플리케이션을 개발해보고 싶다면 굳이 C/C++을 쓸 필요가 없습니다. 최근에 언어들은 객체지향이나 메모리 안전에서 해방된 언어들을 주로 사용하고 있기 때문이지요. 따라서 자바스크립트 기반의 언어나 파이썬들은 어플리케이션을 짤때 꽤나 괜찮은 언어로 손꼽힙니다.
![](http://codedosa.com/wp-content/uploads/2022/10/파이썬_로고-e1664776186934.jpg)
이제 시장의 시선은 “C/C++”의 종말까진 아니더라도 C/C++ 의 사용 비중을 점차 줄이는 추세로 가는거 같아 보이는군요. 성능좋은 CPU와 도구들이 계속 출시가 되고 있고 굳이 C/C++을 사용하지 않아도 괜찮은 어플리케이션 소프트웨어를 개발하는게 가능합니다.
저같아도 “메모리 안전에 위협”이 되는 C/C++을 사용하는거 보다 대체 언어가 있다면 성능이 다소 떨어지더라도 그 언어를 사용하는게 낫겠다는 생각이 드는군요.
그렇다면 C/C++은 뭘로 대체될 것인가?
시장은 C/C++의 사용을 점차 줄여가는 걸로 보이지만 아직까지는 C/C++을 대체하기는 쉽지 않습니다.
![](https://codedosa.com/wp-content/uploads/2024/03/2024-03-13-14-01-52-1024x517.webp)
이 글을 쓰는 현재 TIOBE 에서 발표한 프로그래밍 언어 사용 순위입니다. 여전히 C/C++은 2024년 현재에도 2,3위에 들정도로 막강한 위치를 차지하고 있습니다.
따라서 당장은 대체하기는 어려울 겁니다. 특히 시스템 프로그래밍을 주로 하는 “리눅스 진영” 에서는 더더욱 C/C++을 대체하기 쉽지는 않습니다. 당장 리눅스 커널이 C로 되어 있기 때문입니다.
하지만 시장은 이미 C/C++을 대체할 만한 언어를 준비해놓고 있습니다. 바로 “러스트(Rust)” 입니다.
![](https://image.zdnet.co.kr/2021/03/30/bace62995fbd497c42e982eee84b980c.png)
C/C++ 대체용으로 모질라재단에서 개발하고 배포하는 언어인 “러스트”는 이미 리눅스 진영에서 서서히 받아들이고 있는 걸로 보입니다. 리눅스 커널의 일부를 러스트로 개발한다는 이야기가 있더군요.
![](https://www.zdnet.com/a/img/resize/b4ce3e7a3916ec1c67705b049c0bbe07de57c8ab/2020/12/14/94a849a0-9f3b-4bd3-abd9-62b67c5559df/linustorvaldstedyoutubeb.jpg?auto=webp&fit=crop&height=675&width=1200)
리눅스의 창시자 토발즈도 러스트를 인정하며 커널 6.1 버전에 일부 반영하겠다는 계획을 발표했습니다.
![](http://codedosa.com/wp-content/uploads/2024/03/2024-03-13-14-14-31.jpg)
현재 커널은 6.8 버전이 마지막 버전이니 이미 러스트가 커널에 적용이 된거 같군요 ㅋ 위 토발즈의 글이 2022년에 쓰여졌으니 이미 러스트는 커널에 일부 탑재가 된걸로 보입니다.
물론 커널 전체는 아니지만 일부 탑재가 되었다는 것은 그만큼 토발즈도 “러스트”를 어느정도 인정한게 됩니다. 불과 몇년전만 해도 “리눅스 커널 = C” 의 공식이 깨지고 있군요.
이처럼 시장과 프로그래밍 언어는 시대의 흐름에 따라 바뀌는거 같습니다. C는 출시된지 벌써 50년이 지났지만 여전히 사용되는 언어인 만큼 오히려 C나 C++이 장수를 하는거 같아 보이는군요.
이 글을 읽는 임베디드 리눅스 프로그래머 및 리눅스 프로그래머 혹은 C/C++ 프로그래머들께서는 어떤 생각이신가요? 분명한 점은 C/C++는 서서히 다른 언어로 대체가 되어가고 있다는 점입니다.
이제 저도 주변이들에게 “러스트” 를 사용해 보라고 권유를 하고 있습니다. 사람의 언어가 시대에 따라 달라지듯이 컴퓨터 프로그래밍 언어도 시대의 흐름에 따라 달라지는거 같습니다. 저도 대비를 해야 겠군요.
프로그래밍 언어는 수단이 아닌 단지 “도구”일 뿐이다.