평생 공부를 해야하는 프로그래밍 환경에 대하여

오래동안 프로그래머라는 일을 하다보니 경력이 작은 사람들에게 옛날 이야기를 들려줄 때가 종종 있습니다. 아마, 10년 넘게 일한 사람들은 이런 경험이 많으리라 생각됩니다. 게다가 아직도 설계나 구현에 직접 참여할 기회를 가지고 있는 현역에서 뛰고 있는 "IT 중년"들이라면 더더욱 할 얘기가 많을 것입니다.

저도 그런 부류에 들어 있는 사람으로서, 게다가 80년대 초반(제가 초등학교시절)부터 어떻게든 프로그래밍을 계속 해온 사람으로서 그 역사속에서 다양한 설계 기법들이 명망을 거듭한 것을 종합하다보면, 한 때의 유행으로 취급한다거나 말만 그럴듯하게 포장되었다고 쉽게 간과하는 경향이 생기는 것 같습니다.

몇가지 예를 들어서 80,90,00년대를 변해온 환경을 되돌아 보겠습니다.

메모리가 없던 시절에는 메모리를 소중하게 생각하는 기법들이 많았습니다. 그러다가 메모리가 풍부해지니 넉넉히 설계해서 메모리 처리에 대한 신경을 그 전보다는 많이 안쓰게 되었습니다. 그러다가 임베디드 환경이 널리 보급되다보니 메모리에 대한 신경을 다시 쓰게 되었습니다. 언젠가는 또 반복되지 않을까요? 그것은 일반 프로그래머의 영역이 PC환경에서부터 초소형 환경까지 넓어졌기 때문입니다.

당시에 상용메모리, Extended memory, Expanded memory, High Memory 이름만 들어도 현기증 납니다. 메모리 관련된 개념들은 프로그래머가 아니라 게임하는 사람들이 더 잘 알았을 정도였습니다.

CPU의 성능이 올라가면서 메모리와의 성능 격차가 심해지는것과 중간에 캐시를 두는 것, 그리고 CPU의 코어 개수가 늘어나면서 캐시의 단계도 달라지다가, 심지어 메모리를 CPU 별로 물리적으로 직접 할당하는 NUMA환경이 되기까지 많은 아키텍쳐의 변화가 있어 왔습니다. 그러나 NUMA라는 기술또한 처음 나온 것이 최근일이 아니라, 과거 CPU와 메모리 및 시스템 버스에 대한 설계들이 빅뱅상태의 초기상태일때부터 있던 일입니다. 당시에는 CPU 카드들이 따로 있었고, 메모리도 그에 따라 다르게 설정이 가능하던 시절이었습니다. 한 20년 거의 하나의 아키텍쳐로 평준화되고 나니 그다지 이슈가 되지 않던 것이 그 한계에 도달하게 되고나면 이전 아키텍쳐들의 중요 개념들이 다시 들어오는 것입니다.

Remote Procedure Call 에 대한 것도 그렇습니다. 서비스를 구현하기 위해 실제 실행은 원격지에서 돌리고 이쪽에서는 호출하는 껍데기만을 가진다는 개념인데, 개체 지향적인 요소들이 추가되어 확장을 하였습니다. RPC가 보안상 문제가 있어 왔던적이 있어서 한동안은 RPC 용 서비스가 없던 시절에는 RPC용 데몬을 꺼둘것을 권고하는 시절도 있었습니다. RPC는 각종 언어에 포팅되어 호출될 수 있는 잠재력있는 기능이었습니다. XML이 입출력을 데이터를 표현하는 방법으로 바뀌기도 하였고, Javascript Object Notation을 사용한다든지, 도메인이 다른 스크립트간의 데이터 교환이라든지하는 기법들이 사용되는 것을 보고 나면, RPC라는 개념이 사라져 없어지는 것이 아님을 알 수 있습니다.

한동안 C-style의 언어 pascal, java, c++ 등 형선언이 비교적 강력하고, 절차형 언어에서 10년 정도 개체 지향적인 접근이 주류를 이루게 되었습니다. 이런 상황에 반해서 나온듯한 함수형 언어의 도약은 오히려 개체 지향적인 접근에 대해 무색하게 만드는 흐름처럼 보입니다. 함수형 언어(haskel, lisp, erlang) 혹은 함수형 언어적 성격(iterator, map, fold, generator, closure) 의 수용은 최근 몇년사이에 일어나는 경향입니다. 아마도 세대가 바뀌어서 개체 지향적인 접근이 우위를 점했듯이 함수형 언어적 특성들을 적극이용하는 것이 주류가 되려면 세대가 바뀌어야 가능할 것 같습니다. 아뭏든간에 이런 언어의 근간을 이루는 것도 이미 70,80년대에 모두 완성되었으며, 특수한 도메인에서만 사용되는듯하다가 이제 주류로 조금씩 나오는 상황입니다.

네트워크의 속도와 보조기억장치의 속도에 대한 것도 억지로 맞추자면 그러합니다. 네트워크로 OS를 부팅하는 이유도 경제적인 이유나 관리상의 이유에 의해 존재했습니다. 보조기억장치가 비싸던 시절에는 한 곳에 OS를 설치하고 네트워크로 부팅해주면 좋았던 시절이 있었습니다. 또한 동시에 수천대를 관리해야하는 서버실이라면, OS의 업그레이드를 굳이 일일이 하는 것보다 한 곳에 두어 하는 것이 편리하다는 장점이 있을 수 있습니다.

어쩌면, CPU, 메모리, 노드간 접속, 하드디스크, 버스를 머리속에 그려놓고, 이들의 속도에 대한 생각, 연결 방식에 대한 생각들이 고착화될 시점에 항상 그것을 부수는 방향이 그 다음 세대에 주효한 흐름으로 자리잡고 있습니다.

프로그래머는 공부를 많이 해야한다고 알려져 있습니다. 한가지 기술을 배워서는 몇년 못써먹는다고 하지요. 공부할 양이 많긴하지만, 너무 가장 보편적인 기술만을 공부해놓고서 몇년 못써먹는 기술이라 생각하는 것은 아닐까요?

알고리즘은 변한게 없고, 어떤 물리적인 구조의 성능을 극대화하기 위한 설계는 늘 변한게 없었습니다. 다만 물리적인 구조라는 것이, 수요가 많이 발생하여 변해왔다거나 대량생산에 의해 관심사가 달라졌다거나 기술적인 한계에 도달하여 도입한 패치가 이루어졌거나 하는 것일 뿐입니다.

배울때, 보편적인 기술의 인터페이스만 배우는 것은 좋은 기회를 놓치는 것입니다. 주위에 있는 사람들에게 종종하는 말은, 따로 공부하지 말고 주어진 일에 대한 공부가 필요할 때, 매우 깊이 파라고 합니다. 하나의 주요한 라이브러리나 언어적인 특성, 알고리즘을 공부해야할때, 그것과 연관된 근원까지 공부해두면, 언젠가는 한바퀴돌아서 다시 만나게 됩니다.

한가지 더, 그렇게 반복되는 듯한 모습이라면, 진보는 없다는 것으로 오해될 것 같습니다. 매우 중요한 개념의 확장이 있어왔습니다. GUI 환경이 그랬고, 인터넷이 그래왔고, 웹관련 기술이 그래왔으며, 이제 가상화나 분산처리기술들이 그러할 것입니다. 이런 기술들은 몇년을 두고 천천히 해도 늦지 않습니다. 이런 기술들이 주류로 편입되기에는 바뀌어야할 환경들이 많기 때문입니다. 하지만, 그것이 주류가 되기전에 그 기술적 배경들 속에 과거부터 있어온 것과 정말 그 기술이 새로이 도입한 것들을 가려낼 수 있다면 그다지 어렵지 않게 따라 잡을 수 있으리라 생각됩니다. 오히려 그런 기술들을 공부하는 것은 그 기술과 연관된 환경을 관찰하는 관광요소들이 많아서 지적으로 도움이 됩니다.

궤도에 올랐다는 느낌이 드는 순간까지 화이팅!