내가 본 신입 프로그래머와 현실

얼마전에 난 이직을 하였고 현 회사를 아직까지는 잘 다니고 있는 중이다. 

제조업을 떠나고 프로그래밍만 신경을 쓰니 한결 더 수월해진듯 하다. 전 회사에서와 같이 개발 단계에서 하드웨어 적인 이슈에 대해 전혀 신경을 쓰지 않는다. 시스템이 돌다가 하드웨어 문제로 인해 리부팅이 안되니 마니 하는 용어는 이제 들어보질 못했다. 전에는 잘 돌던 시스템도 갑자기 죽어버렸을때 그 당황함이란 이루 말할 수 없었지만 지금은 “Segmentation Fault” 만 발생하지 않으면 된다.

위 글에서도 언급했지만 임베디드 리눅스 기반의 시스템은 개발 단계에서 여러가지 신경써야 할 일이 많다. 소프트웨어 개발을 한다고 하지만 개발단계에서 하드웨어가 안정적이지 않기 때문에 하드웨어가 안정화 되기 전까지는 꽤나 많은 하드웨어적인 이슈가 발생한다. 이 단계에서 S/W 문제인지 H/W 문제인지 서로 티격태격 하거나 으르렁 대는 일이 비일비재 하다. 

임베디드 시스템을 개발하면 S/W 프로그래머들은 아마 이 단계에서 난관을 많이 겪을 것이다. 필자도 마찬가지였다. 개발 초기 단계에서 특정 패리패럴이 정상동작하지 않을 때 드라이버나 커널의 문제인지 패리패럴 부품 즉 하드웨어의 문제인지 불분명할 때가 많다. 하드웨어 엔지니어들은 충분히 검증을 했다고 자부하지만 S/W 프로그래머들이 검증을 해보면 하드웨어 문제인 경우가 꽤 있다. 그 반대로도 하드웨어에서 많은 검증을 해서 이상이 없다고 자부하지만 S/W 쪽에서 코드 오류로 인해 정상 동작을 안하는 문제가 발생한다. 

그래서 개발 초기 단계에서는 조심스럽지만 함부러 H/W 엔지니어들에게 H/W 문제라고 단정지으면 안된다. S/W 쪽에서 충분한 검증과 증거를 가지고 있지 않으면 H/W 문제인지 S/W 문제인지 불분명하기 때문이다. 검증 단계에서 무작정 서로 내 파트의 문제가 아니라고 단정지어 버리면 개발 단계에서 매우 피곤한 상황이 발생한다. 그래서 이때 커뮤니케이션이 잘 안되거나 오해를 하는 바람에 협업에도 빨간불이 켜지는 상황이 자주 발생한다. 

그래서 임베디드 시스템 개발은 이런 부분이 단점이다. 매우 안정적인 x86 기반의 PC나 서버에서 개발하는 프로그래머들은 이런 상황이 낯설게 느껴질지 모른다. 왜 프로그래머가 하드웨어 이상 여부를 검증해 줘야 하지? 라는 생각이 들 수 있다. 하지만 시스템, 특히 임베디드 시스템을 개발하는 프로그래머들은 이 과정이 거의 필수라고 볼 수 있다. 

제조업을 떠나기 전까지는 나도 이런 과정을 거의 필수로 겪었었다. 개발을 진행하는데 소프트웨어 알고리즘이나 코드를 잘 짜는 방법을 고민하는게 아닌 얼마나 시스템이 안정적으로 돌고 하드웨어 적인 이슈가 없게 하는 데에 리소스를 많이 투입했을 것이다. 누군가는 이런 패턴으로 프로그래머가 개발을 한다고 하면 결코 개발을 하지 않겠다고 할지 모른다. 

물론 우리나라 IT 업종에서 내가 그동안 몸담았던 임베디드쪽과 웹, 앱으로 대표되는 어플리케이션쪽 양쪽다 일정에 치여서 알고리즘을 고민할 여유가 있는 프로그래머들이 많지 않음을 알고 있다. 그럼에도 임베디드쪽 개발은 프로그래밍에 투입할 수 있는 시간이 상대적으로 부족한것은 사실이다. 

그럼에도 난 임베디드 쪽에 재미는 있다. 다만 군대식 문화와 말도 안되는 일정을 강요하는 제조업의 기업문화가 싫었을 뿐이다. 또한 충분히 나도 하드웨어 지식을 가지고 있고 하드웨어 엔지니어 들의 고충을 알고 있지만 막상 협업을 진행하면 대화의 어려움과 사람의 어려움 때문에 정작 내가 할일인 “프로그래밍”을 제대로 하지 못하는 상황이 발생한다. 이래서 잠시 제조업을 떠나 있는게 낫겠다는 생각을 했다. 

확실히 제조업을 떠나 순수 프로그래밍만 하는 업무를 맡다 보니 개발 환경이 좋아진 느낌이었다. 위에서도 언급했지만 x86 서버에다가 리눅스를 올리고 그 리눅스 안에서 내가 수정하고 짠 어플리케이션이 잘만 돌기만 하면 된다. x86  서버에서 이 서버가 하드웨어 문제로 동작이 이상해지거나 할일은 거의 없다. 난 단지 리눅스 프로그래밍만 잘 하면 되는 것이기 때문에 훨씬 마음은 편해졌다고 볼 수 있다.

그렇게 현 회사에서 잘 적응을 하던 도중…. 같은 팀원으로 신입 프로그래머가 한명 들어왔다. 그는 이제 각 대학을 졸업하고 경력이 일천한 생 신입 프로그래머이다. 

신입의 각오와 그가 마주한 현실

그는 대학을 졸업하고 나서 바로 내가 다니던 회사로 취업이 되었다고 한다. 그는 컴퓨터 공학을 전공하고 학교에서는 웹 프로그래밍을 했다고 했다. 그럼 웹은 어느정도 하겠구나 생각했다. 

그는 각오를 단단히 가지고 열심히 했다

그는 정말 각오가 대단했다. 그 이유는 이렇게 기회가 생겼으니 프로그래머로 성공을 해보고 싶다는 것이었다. 그는 학교다닐때 HTML, JS 같은 언어 위주로 썼으며 주로 웹 프로그래밍 관련하여 프로젝트를 진행해봤다고 했다. 대신에 C언어는 배우긴 했으나 자주 써보지는 않아서 잘하지 못한다고 했다. 

잉? C를 잘하지 못한다고? 지금 우리팀은 C언어를 다룰줄 아는 사람이 필요하다. 그런데 회사에서는 신입사원을 C가 익숙치 않은 사람을 채용한 것이다. 물론 회사에서도 이 신입 친구를 뽑은건 다 이유가 있을 것이다. 그럼에도 당장 일을 하려면 C가 익숙해야 하는데 C가 익숙하지 않다니…. 신입 프로그래머의 앞길이 험난할거 같다는 생각을 했다. 

사실 여기서 내가 알게 된 점은 최근에 컴퓨터 공학을 전공한 전공자들의 커리큘럼이다. 나때만 해도 C는 컴퓨터 공학을 비롯해, 정보통신, 전자 등등 C가 필수과목이었다. 하지만 요즘은 트렌드가 바뀌었는줄은 모르겠지만 자바나 파이썬, JS 등을 컴퓨터 공학 수업 시간에 가르친다고 했다. 오히려 C를 가르치는 수업은 많이 줄어들고 있다고 한다. 

최근에 IT 산업의 트렌드가 바뀐 것이 대학 수업에도 영향을 미친듯 보였다. 최근 “네카라쿠배” 같은 대형 IT 서비스 기업이 성공을 거두고 이들이 필요한 인력이 자바나 JS, 파이썬 같은 언어들로 개발을 하기 때문에 그런것으로 보인다. 사실 요즘 기업에서도 IT 기업들은 웹이나 앱같은 어플리케이션 개발 이슈가 많다. 웹은 워낙 수요가 많고 필요 인력도 많은 상황이 되버렸고 모바일 앱의 경우에도 그 수요는 여전히 많은 편이다. 그래서 관련 개발 인력도 많이 부족한 실정이다. 

반면에 나같이 C나 C++을 주 언어로 사용하는 프로그래머들은 주로 임베디드 시스템 개발이나 리눅스 어플리케이션 등 시스템 개발에 주로 사용된다. 혹은 IoT 장치나 장비등에도 아직까지는 C가 주로 사용이 되고 있다. 그런데 흥미로운 점은 대학에서 교수들이 이런 시스템 프로그래머는 사양추세이니 학과도 개설하지 않고 C 강의도 하지 않는 다고 한다. 

예전에 비해 시스템 프로그래머의 수요가 줄긴 했지만 사양 추세라니… 물론 대학들도 다 시장을 알아보고 현재 IT 트렌드를 파악한 결과 그런 결론을 내렸을 것이다. 그럼에도 시스템 개발의 기본인 C나 C++ 관련 강의가 사라진다는 것은 약간 잘못되지 않았나 싶다. 

여전히 C나 C++은 프로그래밍 언어 사용율에서도 높은 순위를 차지하는 편이다. 

위 순위는 “티오베 지수” 에서 2022년 5월 현재 전세계 인기 언어 사용 순위를 표시한 것이다.  티오베 지수라는 것은 검색 엔진에서 프로그래머들(숙련 엔지니어, 서드 파티 업체)의 검색량을 조사해서 발표한다고 한다. 여기서 재밌는 점은 우리의 예상과는 다르게 C가 2위를 차지한 것이다. 

그것도 2021년까지는 C가 1위를 차지하였다가 2022년 들어서 파이썬이 1위를 차지하고 C가 2위를 차지한 것이다. 그만큼 파이썬의 인기를 보여준 셈인데 C도 만만치 않은 인기를 보여주고 있다. 

인기도를 조사한 것인데 실제 사용율은 어떨지는 모르겠지만 아마 사용율도 비슷할 것이라고 생각하고 있다. 여기서 또 재밌는 점은 의외로 자바가 3위이고 자바 스크립트가 7위인 점이다. 파이썬, C, 자바, C++ 순으로 인기 순위를 1위~4위까지 기록하고 있다. 

우리나라에서는 자바의 사용율이 높다고 알려져 있지만 생각외로 “티오베 지수”의 인기도는 그에 미치지 못한다. 아마 국내 상황이랑 전세계로 봤을때 언어 사용율이 다른 것일까? 어쨌거나 여기서 분명한 점은 “C언어”는 여전히 그 위상을 자랑하고 있다는 점이다. 

서두가 길었는데 현재 C언어를 대학에서 가르치지 않는 다는 것은 꽤나 잘못되지 않았나 싶다. 학생들에게 선택의 기회를 박탈시키지 않았나 하는 것이다. C를 배우고 싶은 학생은 C를 배우게 하고 자바나 파이썬을 배우고 싶은 학생은 배우게 하면 된다. C가 사양추세라서 안배우거나 안가르치는 것은 학교에서 조금 잘못된 방향으로 가지 않나 싶은 것이다. 

그렇게 학교에서 “C 언어” 배우는 것에 미흡한 신입 프로그래머는 당장 나와 같은 팀이 되었고 이제 C언어로 리눅스 프로그래밍을 해야 하는 임무를 가졌다. 그는 각오를 다졌고 나와 같이 있는 두달 동안은 정말 열심히 하는 것 같았다. 하지만 그는 생각보다 많이 어려워 했고 C 문법조차 잘 이해하지 못하는 모습을 보인다. 

물론 회사에서도 신입 A씨(이하 A씨)가 C언어 기초가 부족하다는 사실은 알고 있다. 그럼에도 회사는 A씨의 상황이나 수준과는 별도로 빨리 프로젝트에 합류해서 실무를 해주길 바라고 있는 눈치다. 당분간은 계속 교육을 한다고는 하지만 내가 봤을 때 A씨는 실무에 투입하기 여전히 어려운 상태이다. 

이런 상황에서 A씨가 내게 개인 상담을 요청해왔다. 

이상과 현실 사이

난 경력이 얼마 되지 않은 프로그머들의 도움 요청에 종종 응해주곤 한다. 그 이유중에 하나는 내가 그 시절에 겪었던 많은 어려움과 난관이 떠올라서다. 물론 지금 내가 어디 명함 내밀 실력은 못되지만 어딜 가서 밥벌이는 할 수 있는 프로그래머라고는 말할 수 있다. 그래서 누군가에게 도움은 줄 수 있다. 

위에서 언급한 A씨는 내 생각과는 다르게 엄청난게 많은 부담감을 가지고 있었다. 원래 웹 프로그래머를 생각했었지만 취업을 하다보니 C언어 기반의 시스템 어플리케이션을 개발하는 회사에 오게 된것이다. 입사 처음에는 열심히 하면 된다고 생각했다는데 막상 회사에서 자료를 참고하고 주변 분위기를 보니 생각보다 많은 어려움이 생기더라는 것이다. 

일단 가장 어려운 점은 회사에서 개발했던 소스 코드를 분석하는 일이었다. 전부 C로 되어있으며 간혹 C++로 된 코드도 이다. 또한 리눅스 어플리케이션이다보니 전에 리눅스를 경험해보지 못했다면 완전히 낯설게 느껴질 가능성이 있다. A씨는 학교다닐때 리눅스를 만져본적도 없고 C코드를 배우기만 했지 본적이 많지 않다. 

가장 간단하고 쉬운 소스인 대략 1000라인짜리 소스를 A씨에게 분석을 맡겼는데 A씨는 소스 분석 부터 C 문법까지 모든것을 어려워 했다. 사실 C 프로그래머라면 1000라인 소스는 그리 많은 양의 소스는 아니다. 며칠 분석해 보면 어느정도 파악이 되는 수준인데 A씨는 분석한 경험이 없다보니 모든게 어렵게 낯설었던 것이다. 

게다가 C 문법도 익숙하지 않았기에 더욱더 분석은 어려움을 겪는다. 주변에 도움이 없다면 A씨는 몇개월이 지나도 큰 진전이 없을 수 도 있다. 안타까운 마음에 분석하는 요령을 짚어주고 C 문법적인 부분을 내 나름대로 강의도 해주었다. 하지만 A씨는 그럼에도 이해하는데 어려움을 겪었다. 

난 그래서 A씨에게 내가 초창기에 개발을 하면서 터특했던 요령들을 조금씩 알려주었다. 그랬더니 그도 조금씩 요령이 생기는 것 같았다. 그럼에도 그는 내가 종종 지나갈때 보면 머리를 싸매고 있거나 얼굴이 상기되는 등의 “스트레스”를 받아 하는 거 같았다. 

사실 리눅스 기반의 어플리케이션 개발은 리눅스를 경험하지 않거나 C를 다뤄보지 않은 사람이 개발을 하려고 하면 무척이나 어려움을 느낄 수 있다. 특히 C나 C++은 “포인터” 라는 메모리를 다루는 기능이 있기 때문에 이부분 때문에 많은 예비 프로그래머들이 중간에 배우다가 포기하거나 다른 언어로 전향하는 경우를 본 적이 있다. 

A씨도 마찬가지다. 포인터 관련해서 질문을 해보고 얼마나 아는지 체크를 해봤는데 그는 아직 초보자 수준이다. 실제로 실무에 들어가면 포인터를 제대로 활용하지 못할 가능성이 높다. 하지만 현재 프로젝트에 투입이 되려면 포인터는 능숙하게는 아니더라도 그 개념을 어느정도 알고 활용하는 수준에는 도달해야 한다. 

여기서 A씨는 많은 고민을 하는 듯 하다. 내게 개인 상담을 하면서 그는 진지하게 현재 고민을 한다고 했다. 

그는 신입임에도 불구하고 나름 최선을 다하는 중이다. 현재 회사에서는 실무를 하지 않고 교육 위주로 분석을 하고 있지만 생각보다 높은 벽에 감당하기 어렵다고 했다. 그는 회사에서 뿐만 아니라 집에서도 공부를 지속하고 있는데 전혀 진전이 없다는 것이다. 그런 와중에 회사에서는 빨리 실무에 투입되길 바라는 눈치니 부담이 엄청나다고 했다. 

난 그래서 그에게 몇마디를 건냈다. “A씨가 프로그래머로 성장하고 싶으면 끈기와 인내를 가지고 버텨내야 해요. 프로그래머는 우아하게 책상에 앉아서 커피 마시면서 할수 있는 일이 아닙니다.” 라고…

그렇다. 프로그래머는 처음부터 잘하긴 쉽지 않다. 아무리 뛰어나고 난놈이라고 해도 실제 실무에 투입되면 경력자에 비해 아무래도 부족하다. 물론 어렸을때부터 프로그래밍에 관심을 가지고 했던 천재들은 다르긴 하지만. 

당신이 천재가 아니라면 생각보다 처음에는 높은 벽이 존재한다. 특히 C는 1970년대에 처음 나온 언어인데 이때 나온 C는 어셈블리어의 불편함을 대체하기 위해 창시된 고급 언어 였다. 

어셈블리어가 일일이 명령어 기반으로 라인 by 라인으로 프로그래밍을 하기 때문에 그 난이도는 C에 비할 바 못된다. 그런 와중에 C의 등장은 프로그래밍의 대중화에 기대를 할 정도로 훨씬 편해지고 짜기 쉬워진 고급 언어에 속했다. 하지만 고급 언어임에도 컴퓨터의 메모리를 직접 제어할 수 있는 “포인터(Pointer)” 가 존재하기 때문에 그만큼 강력하다고 볼 수 있다. 

따라서 C는 리눅스의 창시자인 “리눅스 토발즈”도 주로 사용하는 언어이다. 토발즈의 경우에는 리눅스 커널은 C 언어로 개발했고 이는 현재 가장 대중적으로 많이 쓰이는 OS인 리눅스 기본 언어라고 볼 수 있다. 재밌는 것은 토발즈가 C++의 경우에는 나쁜언어라고 평가하고 C++은 리눅스 커널의 문제점을 해결하지 못한다고 주장했다는 것. 

어쨌거나 C는 현재에도 가장 많이 쓰이는 언어이다. 대신에 1970년대에 처음 출시되었고 포인터로 메모리를 직접 제어하기 때문에 예비 프로그래머들의 진입 장벽이 어느정도 있는 편이다. 

그래서 최근들어서는 C/C++의 불편함을 개선한 언어들인 자바/자바 스크립트/파이썬 등의 언어들이 실무에서도 많이 쓰이게 되었다. 이들 언어들의 특징은 C++의 객체지향성과 C의 포인터 개념이 없어진 것이다. 따라서 프로그래머는 포인터를 신경쓰지 않기 때문에 그만큼 좀더 효율적인 프로그래밍이 가능하다. 그리고 최근에도 이들 언어들은 많은 프로그램 개발에 사용되고 개발 트렌드를 바꾸게 했다. 

사실 C나 C++은 포인터라는 강력한 기능이 있지만 대형 프로젝트에 적합하지 못하다는 평가가 있다. 그 이유가 포인터를 잘못 사용하면 프로그램이 죽거나 치명적인 오류가 생길 가능성이 높기 때문이다. 

이런 점 때문에 최근 들어서 C/C++ 보다 많은 프로그래머들이 자바, 자바 스크립트, 파이썬 등의 선호도가 더 높을 가능성이 있다. C나 C++같이 굳이 컴퓨터 구조, 메모리, 포인터 등을 이해하지 않더라도 프로그래밍이 가능하기 때문이다. 

A씨도 현 시점이 갈림길일 것이다. 그는 C를 다루므로써 좀더 강력한 도구를 쓸 수 있으니 열심히 해보겠다고 각오를 다졌지만 불과 두달만에 포기를 할 생각을 가지고 있었던 것이다. 그만큼 그에게는 큰 벽이 존재하는 것 같았다. 

하지만 그는 명심해야 한다. 만약 여기서 C 정복을 포기하면 과연 다른 언어도 정복이 가능할까? 물론 가능할 수 있다.  C나 C++ 외에 다른 언어를 배우면 된다. 하지만 그는 우리 팀 프로젝트에서 참여할 수가 없고 설사 다른 언어를 배운다고 해도 앞으로 추가적으로 배워야 할 리눅스에 관련된 내용과 네트워크, 서버의 개념 및 동작 , 프로토콜 등등 개발을 하기 위한 지식들을 끊임없이 습득해야 하고 배워야 한다. 

언어는 개발에 있어서 도구일 뿐이다. 그리고 누구나 처음에는 어렵고 쉽지 않다. 하지만 프로그래머로 살기 위해서는 단지 두달동안 머리가 아프고 어렵다는 이유로 포기해선 프로그래머로 살기가 어려울 것이다. 프로그래머로는 언어를 잘 다루게 되면 그때부터 수많은 지식들과 경험을 필요로 하는 직업이기 때문이다. 

처음에 어렵더라도 그 한계점을 넘으면 서서히 고지가 보이기 시작한다. 우리가 높은 산을 오를때 특히 경사가 매우 가파르다면 정상까지 가기가 엄청나게 힘들것이다. 하지만 그 정상을 어떻게든 정복을 하고 발을 디뎠다면 그 이후에는 내리막길로 내려오기 때문에 훨씬 수월하다. 프로그래밍도 이와 마찬가지라고 볼 수 있다. 

“프로그래밍은 결코 TV나 영화에서 본 거와 같이 아침에 모닝 커피를 마시면서 우아하게 하는 일은 아니다. 단지 프로그래밍에 관심이 있고 끊임없이 지식을 쌓고 공부를 할 수 있다면 그것만으로도 프로그래머로서 사는 게 가능할 것이다.”

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