어떤 언어를 공부할까요?

해답에 대한 설명은  꽤 길고 난해할 수도 있습니다. 철학을 알아야 뭘 할지 선택할 수 있기 때문입니다. 저도 100% 모릅니다. 다만, 제 생각을 솔직하게 말하고 상대방의 이야기를 들을 자세는 되어 있습니다.

일반적으로 IT 분야에서 자격증을 배우던, 프로그래밍을 배우던 관계없이 어느 수강생이 한 가지 언어의 기초 문법을 떼고 프로젝트를 하고 나면 항상 물어오는 질문입니다.

알고리즘 온라인 judge 사이트에서 어느 정도 문제 패턴을 공부하고, 디자인 패턴 책을 사서 코드에 적용해 보기도 하고 상용 프로젝트(네이버나 다음의 서비스), 혹은 최신 기술(AR)을 공부하고 나면 궁금해하는 질문입니다. 모든 것을 다 알아서가 아닙니다. 문제를 풀다보면 자신이 부족한 부분에 대한 카테고리(DP 等)는 확실히 알게 됩니다. 부족한 부분을 계속 하다보면 지루함도 몰려오고 자신의 한계를 알게 되기도 합니다.

처음에는 기술만 공부하면 될 줄 알았는데, 수학과가 알고리즘을 공부하다 보니 온라인 judge 문제들의 패턴은 일정하게 보입니다. 실제로 해야할 프로젝트는 규모가 큽니다. 이에 반해 자신이 했던 미니 프로젝트, 직접 만들었던 부분은 설계나 제작 방식을 그대로 쓸 수 없는 경우가 대부분 입니다. 또한, 최신 기술의 경우 해당 기술을 선도하는 기업에 들어가서 수개월 동안 관련 공부를 하기 前 원천 기술을 혼자서 맨땅에 돌파 하기에는 어렵습니다. 실마리도 잡을 수 없습니다. 라이브러리를 끌어다 쓰는 것은 항상 일정한 패턴이며, 중소규모 대회에 참가하면서 입상을 하다 보면 지겨워집니다. 그 길을 걷는 후임들도 같은 말들을 합니다.

학생들의 생각을 피드백으로 받았습니다. 스스로 생각할 능력이 생기고 이게 아닌 것 같다는 생각이 드나 봅니다. 멘사에 알고리즘 잘하는 친구도 단순 프로그래밍에 지쳤다고 하네요. 구조적 프로그래밍을 하고 싶다고 합니다. 

보통 진로 상담을 받았을 때 먼저 말해주는 것은 튜링상을 노려 보라고 합니다. 바다의 게가 옆으로 걷는다고 자식에게 똑바로 걸으라고 말할 자격이 없지는 않은 것처럼. 제가 잘난 것은 없지만 꿈은 크게 가져 보라고 합니다. 아니면 구글 코드잼 일등도 노려보라고 합니다. 해외 유수 명문대도 거치고, 한국에서는 일등만 해온, 그런 명문대 학생들도 IT 분야로 넘어옵니다. 

좀 더 현실적인 이야기를 해 달라고 요구를 합니다. 그럴 때는 한 가지 언어를 하라고 합니다.

https://www.youtube.com/watch?v=LJvEIjRBSDA

재미있는 GO 언어 영상을 보여주고 또 google이 한다는 점을 말하고 나면, 해당 언어를 배워 보겠다고 합니다. 그리고 저에게 묻습니다. 선생님 혹은 강사님, 혹은 (직급)님은 뭘 하시냐고.

전 SWIFT를 공부한다고 합니다. 그냥 재미있어서... 입니다. IT 분야에서 가장 중요한 것. 그리고 짧은 인생에 남는 것은 "재미"밖에 없으니까요. 행복을 가져오는 가장 강력한 요소 이기도합니다.

만약 모든 것을 개발하고 싶다면, C를 하라고 합니다.

언젠가는 구글이 운영체제도 GO 언어로 만들겠지만 그러려면 자체 CPU를 만들고 CPU의 명령어 Set(Instruction Set)을 GO 언어 스타트업 코드로 짤 수 있도록 추상화해야 합니다. 그리고 추상화했을 때 생겨나는 문제점을 모두 google이 책임져야 하죠.

수많은 임직원이 있는 구글을 하나의 인격체로 평가하는건 웃긴 일이지만, 제가 아는 google은 그렇지 않습니다. 많은 것들을 창조 해나가고 있지만, 순수 코어 한 그룹은 아니고 인수/합병으로 커가는 공룡 기업의 하나지요. 애플처럼 더 좋은 게 있다면 자사 CPU도 버릴 결단을 할 수 있는 회사로 보이지는 않습니다. 그리고 각 회사마다 잘하는 분야가 있습니다. 애플이 인텔보다 CPU를 잘 만들지는 못하고 구글이 애플만큼 여러 기기에 운영체제를 만들고 다양하게 통합하지는 못합니다. 또 인텔은 구글보다 웹 서비스가 강력하지는 못하지요. 인공지능 역시 구글보다는 IBM이 더 앞서 있다고 생각합니다.

여러 상황을 고려해 보면 결국, 공룡 기업만 볼 것이 아니라 강력한 코어를 가진 중소기업을 봐야 합니다. 재미를 잃은 강력하고 작은 기업들은 결국 인수/합병을 통하여 대기업이 되어 버리지만 현재의 젊은 기업들을 보아야하지요.

그런 기업들이 쓰는 언어는 다양하긴 합니다만 코어는 C/C++입니다.

C라고 하고 싶지만 마소가 볼랜드를 없애버리면서 C/C++ 통합해 버렸지요. 그 장본인이 C#을 창시하고. net으로 무지하게 밀고 있지만, 3D 분야가 대세라(모바일로 주춤했지만 다시 미래 먹거리) 세부 컨트롤링을 생각하면 결국 개발자에게 메모리를 넘겨줄 수밖에 없었습니다.

그래서 마소도 모던 C++을 밀고 있는 것이죠. 

그러나 C++을 그리 추천하지는 않습니다. 한 때는 Writing 언어로 C++을 추천했지만 지금은 Reading 언어로 추천합니다. 예전에는 B, C를 개발한 개발자(캔 톰슨)도 GO 언어라는 새로운 언어를 개발하고, 제임스 고슬링도 자바에서 클래스를 없애고 싶다고 한 것처럼. 창시자들도 새로운 것을 하고 싶어 합니다. 그러나 C++ 만든 사람도 C로 만들었고, GO도 처음엔 그랬고(C로 만들었고) JAVA나 스위프트도 C++로 개발이 됩니다. 내부는 GO 언어로 다 대체되었다 하지만 이야기하기 싫어하는 core 개발자는 알고 있을 것입니다. 결국 돌아가는 CPU에 맞춰서 하부 코드가 되어 있기 때문에 C가 섞여 있다고 확신 합니다. 어불성설이겠지만 특정 keyword 를 쓸 때는 바로 기계어 코드(어셈블리어)로 바꾸어 주는 컴파일 기능을 넣어도 되긴 하겠죠.

C를 정확히 말하면 어셈블리를 읽기 좋게 해 놓은 것 입니다. C++은 C로 짤 디자인 패턴의 코딩 라인 수를 줄이게 한 것이고요. 그 외 언어들은 개발자가 메모리 관리를 못하니 못 믿겠다고 한 것입니다. static 한 컴파일/링크 과정을 dynamic 하게 하게 해 주려는 시도는 좋으나 그 메커니즘은 결국 CPU위에서 도는 메커니즘이지요. 

최강의 언어가 나오려면 가장 많이 쓰는 디자인 패턴을 아예 CPU 명령어 set으로 칩 안에 넣어버린 컴파일러를 가져야 합니다.(빠를 수밖에 없죠) 그 CPU는 서버뿐 아니라 데스크톱 시장, 모바일 시장도 모두 선점해야 합니다. 게다가 메모리 관리를 못해도 개발할 수 있는 수많은 개발자를 양성하기 위하여 C#, GO, SWIFT, JAVA 언어의 공통점을 넣어야 합니다. 컴파일도 최대한 빠르게 해줘야겠지만, 어차피 하드웨어 성능 아래 묶여 버리니 자동으로 분산 컴파일이 가능하도록 해 줘야 합니다. 서버로 할 거면, 클라우드로 컴파일하게 해 주면 좋겠네요. 그게 아니라면 토렌트처럼 분산 컴파일하게 해 주면 되겠네요. 작은 시스템은 dynamic 하게 바로 반영이 되도록 스위쳐블하게... 그러나 모든 상황을 고려하다 보면 개발팀이 힘들지고 연봉도 계속 올라가서 다수의 사회 현상을 해결해 주는 시스템을 생산하기보다 자체적인 비용만 올라갑니다. 해당 비용은 AI(인공지능) 쇼를 이용해서 비즈니스와 무관하게 꿈과 희망으로 땜질해도 되긴 하겠습니다. 그렇게 버티다간 결국 망합니다. 그래서 타이트하고 치열하게 사는 헝그리 정신에서 창조물이 더 잘 만들어질 가능성이 커집니다.

꿈과 희망으로 도배되어 개발되는 언어가 결국 수천만이 지어야 할 농사를 기계가 대신하게 해 주는 것처럼 발전하지 못하면 결국 우리 사회에 도움을 주지 못합니다. C는 충분히 그 역할을 해 주었고 앞으로도 해 줄 것입니다. 적어도 임베디드 분야에서는 많은 역할들을 했으니까요. 우리 삶에 충분히 좋은 일을 했습니다.

수많은 언어 전쟁이 모던 C++ 이 더 많이 생각하게 해 주고 발전적인 방향으로 바꾸어 준다는 것에 감사합니다. 그러나 그렇게 들어가는 heavy 한 fucntion(모듈, 라이브러리, 프레임웍... 믓튼 API)은 결국 언어를 무겁게 하고 무거워진 언어는 임베디드에 적합하지 않습니다. 윈도만 봤을 때 그럴 거면 C#을 쓰는 게 맞지요. 무거워진 애들을 쉽게 쓸 수 있도록 프로그래머에게 계속해서 추상화를 해 줄 테니 말입니다. 세부적인 컨트롤이 필요하지 않다면 F#을 써도 되겠네요. 윈도 API를 순서대로 잘 호출하는 것이 전부라면 말입니다.

순서대로 호출하는 것이 전부가 아닌 3D를 살펴봅니다. Direct X 잘 모르지만 API일 뿐이기에 API를 보는 관점을 그대로 적용해서 적어 보겠습니다. 서든어택 2 문 닫아서 아쉽지만(웨어 하우스 들어가 보니 똑같더라고요. 캐릭터만 섹시해지고) 다이렉트 9.0c로 만들었다고 해서 아... 그래픽 엔진을 정말 잘 만드는 엔지니어가 있나 보다 했습니다. 사실 dx9 이상부터 너무 달라졌고, 9와 11, 12 비교해 보면 엄청나게 차이 나지는 않기 때문입니다. OpenGL과 DirectX 비교 영상을 봐도 사실 취향 차이로 보입니다. 어차피 비용상 모든 색상의 주사선을 꽂지 못하는 이상 RGB로 표현하는 모니터상의 화면은 현실 세계의 색감을 나타낼 수가 없기 때문입니다. 현실적이지 않으면 취향으로 넘어갈 수밖에 없지요. dxd9던 11이던 shape 그리는 저수준 함수는 같고 저수준 함수는 그래픽 카드로 이어져 있으니 별 다를 바 없습니다. ray tracing 다 해서 일일이 그려주는 방식이면 괜찮겠지만 아직 3D는 사용자 클라이언트의 성능과 보여주고자 하는 다이내믹의 수준을 고려해야 하죠. 12 버전은 꽤 큰 기대를 하고 있습니다. youtube에서 보여준 병렬 처리가 꽤 괜찮아 보였거든요. 그래도 아마 9c 잘하시는 분은 directX 14, 15, 16 나와도 관심이 없을 것입니다. 자주 쓰는 directX의 엔진 패턴이 칩 내부 명령어로 들어가서 엄청난 속도 향상이 있었다는 것이 아니라면요.

이런 생각들을 하는 엔진 만드는 엔지니어라면 C/C++ 일 테고.

유니티나 언리얼을 쓰는 엔지니어라면 잘 맞는 언어를 선택하면 됩니다. 블루프린트도 좋고 C#도 좋고, C++도 좋고...(UML도 언어입니다 ^^)

문제는 학원에서 1년을 배웠을 때 열심히 했으니 잘 일해라 이 길로만 가라는 것이 아니라. 정말 수료생들을 생각한다면 자신만의 unique 함을 가져야 한다는 것인데 그것을 추천하려면

writing 언어는 하나의 언어만 하라고 해야 한다는 것입니다. 4개국 언어 5개국 언어를 하는 것이 중요하겠지만 결국 연설을 하거나 시를 쓸 정도의 감수성을 가지려면 하나만 해야 하지 않을까요?

보통은 이런 철학으로 상담을 합니다.

그러나 정말 재미로 IT 분야를 하고 싶다는 사람이 나타났었습니다. 컴파일러도 만들어 보고 싶고, 운영체제로 만들어 보고 싶다고 합니다. 돈을 못 벌어도 괜찮다고 합니다.

저는 항상 생각했었습니다. 프로그래머 관점에서 제가 만약 그렇다면 이것을 꼭 공부할 것이다라고 한 것은

ARM Cortex-R Instruction Set

Intel C/C++ Compiler

Micro C/OS-III(Scheduler) & others(TCP&IP, FileSystem...)

Linux Kernel 

이기에 추천해주었습니다.

시스템 오류들이 사람을 죽이는 경우를 방지할 공용 운영체제는 존재할 수 없었습니다. 존재한다고 해도 커스텀 컴파일된 리눅스 커널이나 해당 기술로 만들어진 새로운 커널. 혹은 Vxworks 같은 회사가 담당을 했겠지요. gcc 옵션이 뭔지 내부 오류는 뭔지 모르지만 RUN&FIX 방식으로 의료 기기도 만들어지고 했었지요. 해당 CPU와의 궁합은 몰라도 워낙 다른 문제들이 많으니까요.

이렇게 공부를 해도 아마 수많은 문제가 내재되어 있겠으나, 그나마 많은 오류들을 줄여줄 수 있겠습니다. 그래서 모든 상황에서의 시스템의 내구성을 고려하는 하드웨어 엔지니어를 만났을 때 하나의 작품이 나올 수 있을 것 같습니다.

압니다.

혼자서 불가능합니다. 그래서 소프트웨어 공학이 중요하고 개발 방법론이 계속해서 나오는 것입니다.

궁극의 개발 방법론은 간단합니다.

개발 좋아하는 사람들 모아 놓으면 됩니다. 창조의 기쁨을 느끼는 사람들.

지금까지 시간이 문제였다고 하면, 그 시간이 주는 압력 때문에 삶의 부조화, 건강 악화 등의 이유로 좋아하는 사람 모아 놓아도 결국 모두를 웃게 만들 수 없었다고 하면 시간을 없애면 되겠지만 불가능합니다.

뭘 만들어야 사람들이 할 힘든 일을 줄이고, 행복하게 해 줄 수 있을까 고민해서 아이템을 무수히 생각하고.

해당 아이템들이 돌아갈 프레임워크를 생각하며, 그 프레임워크가 돌아갈 시스템 비용과 안정성을 고려하고,

향 후 비즈니스 방향도 고려해서 지속 가능한 하드웨어 공급이 된다고 판단하면.

현재 해당 하드웨어 시스템 버전으로 고정하고, 운영체제, 컴파일러도 버전 픽스하고 문제점 있는 것은 원천 차단. 즉, 해당 부분은 클린룸 만들고 네트워크 연결 부분은 지속 업데이트가 가능한 시스템을 두는 식으로...

그러나

어떤 경우는 운영체제 필요 없이 생짜 펌웨어로 짜는 것이 효율적이며, 큰 시스템이라도 해당 시스템들을 연결하는 것이 더 나은 경우도 있습니다. 완벽한 보안은 없습니다. 사람을 해킹하는 방법도 있으니까요. 클린룸을 만드는 것은 표준을 따라가지 않는 것입니다. 일본이 그렇습니다. 세계 표준보다 자신만의 표준을 만듭니다. 무슨 일 있으면 감추고. 나쁜 것은 아예 알리지도 않지요. 그래도 구석진 음식점이 요란한 대형 레스토랑보다 더 나은 문화를 만들었죠. 

점점 옆으로 새기 시작합니다. 

이제부터가 사실 시작입니다.

언어를 결정하는 것은 논리적이어야 하는 것 일수도 있지만.

짧은 인생을 함께 걸어가야 할 TOOL을 선택하는 것일 수도 있습니다.

저 역시 두 번 크게 그만두었다가 다시 IT Field로 돌아온 case입니다.

처음 그만 둘 때는 쓰고 있던 언어나 개발 방식이 너무 지겨웠습니다. 다시 시작할 때 생각해보면 너무 편협하게 안 것 같아 CPU 도 공부를 하고 전기 학원 수강도 하는데 파면 팔 수록 너무 공부가 깊고, 또 시대는 너무 빨리 변해서 공부한 것보다 공부할 것이 더더욱 많아져서 그동안 쌓아온 개발자 자존심이나 명성만으로도 충분히 개발을 잘했다는 치장이 되었기 때문입니다.

다시 개발을 시작할 때는 개인/팀으로 이루었던 여러 타이틀이 있긴 하지만.

정작 개발한 것은 없었다는 것을 알고 난 후였습니다.

어머니께 우분투 노트북을 선물하고 가르쳐 드리려던 노력이 안드로이드 태블릿으로 해결이 되던 것과 그 안에 앨범 앱이 어려워 통합 앱을 만들어 드렸을 때의 기쁨. 내가 원해서 개발하고 원하는 상대에게 기쁨을 주는 것. 그러나 그것도 잠시 암 투병하실 때 필요한 장비들은 모두 다른 사람들이 개발해 준 것이었고 제가 기여한 부분은 없었다는 것. 나중에는 안드로이드 폰에 기여를 했지만 아이폰을 추천하는 것이 낫다는 것을 알았을 때. 그렇다고 해도 VR 개발하려면 안드로이드 폰을 다시 사야 했고 내 콘텐츠가 아닌 지인들에게 보여 주었을 때 새롭고 신기한 경험을 줄 수 있다는 또 행복을 느끼는 것을 보았는데 해당 파트에 기여한 부분은 없었다는 것.

비관론적인 입장에서 보면 이렇습니다. 사실 낙관론보다 비관론이 현실에 더 가깝고 객관적이지요.

이야기하는 사람들이 facebook 에 많이 엮어 있어서 그런지 몰라도 일전에 코볼 이야기를 했을 때 코볼 관련해서 쓰였던 뉴스 기사나 링크 그리고 새로운 생각들이 많이 공유되는 것을 경험했습니다. 그리고 안 사실은 이런 생각들은 사실 누구나가 다 하는 것이라는 것도 알게 되었습니다.

이미 있으나 혹시나 볼 사람들을 위해

여러 생각들을 적어 보았습니다.

그리고 최근 몇 년 사이 가르칠 기회가 생겼을 대 항상 하는 말이 있습니다.

전문가란 자신이 잘 해야 하는 것을 위해 하고 싶은 많은
것들을 포기하는 사람을 말합니다.
당신은 무엇을 포기했나요?

사실 이 말은 꼭, 개발의 상황에서 쓰고 싶은 말은 아닙니다.

사랑의 전문가, 즉 사랑을 위해 모든 것을 포기하는 것도 꽤 낭만적이라고 생각합니다.

적고 싶은 대로 써서 죄송합니다. 언젠가 찬찬히 읽고 퇴고해 보겠습니다.

그러나 기술이 세상을 변화시킨다고 할 때 한 번은 사색해 보아야 할 부분이 아닌가 해서...

사실 주변 개발자에게 이런 말하면 "뭘 쓰던 개발 하면 되지, 고민해?"가 대부분입니다. ㅎㅎ