LINUX는 어렵다.

생각 2013. 8. 20. 12:35

오늘 우연히 어떤 개발자의 블로그를 재미있게 읽고 있었다.

필요한 내용도 있었고 개발자의 고단함을 느낄 수 있는 그리고 주변에서 일어나는 여러가지 단편적인 내용들이 주를 이루고 있었다. 글쓴이는 게임 개발자로 추정되며 나름 실력도 있고 개발자로서의 기간도 10여년이 넘는 것으로 표현되었다.

그런데 글을 읽다가 재미있는 글을 읽었다. 2000년도 초반에 비교적 안정적인 LINUX를 이용하여 게임 서버를 만드는 에피소드였다. LINUX에서 C언어를 컴파일 방법을 몰라 검색을 한다거나 네트워크 드라이브가 잡히지 않아 용산에서 구형 LAN카드를 구입하였다거나 하는 이야기였다. 가장 기억에 남는 것은 'LINUX는 어려워서 못쓰겠다.'였다. 뭐 비슷한 뉘양스 였을 것이다.

LINUX는 일반 사람들이 접근하기 쉽지 않다. 지금은 설치도 쉬워지고 UI도 Mac이나 MS-Windows와 비슷하여 그냥저냥 설치되어있는 것을 사용하기는 편리해진점도 있다. 문제는 UI가 아닌 낮선 용어들과 사용방법들이다. 사실 처음 LINUX를 접하게되면 무엇을 해야할지 몰라서 많이 당황하게 된다. 인터넷 검색을 한다거나 해서 어느정도 해결할 수 있기는 하지만 문제는 LINUX의 역사만큼이나 굳어진 인터페이스와 사용방법에 있다.

RedHat이나 Debian, Ubuntu, Suse, Gentoo같이 배포판이 여러개로 나뉘어있고 패키지의 관리방법도 각 패키지마다 고유의 방법을 가지고 있다. 요즘은 RedHat과 Debian의 패키지 관리방법으로 대부분 양분되어있지만 Gentoo의 패키지 방법(이것은 BSD의 패키지 방법을 응용하였다.)등도 있어서 처음접하는 사람은 헷가리게 되어있다. 사실 본인도 같은 LINUX계열이지만 배포판을 바꿀 때면 OS를 변경할 때 처럼 많은 고민끝에 선택을 하게된다. 그만큼 패키지 관리방법은 배포판에서 중요한 부분을 차지하고 있다.

위 블로그에서 LINUX가 어렵다고 하신 심정은 십분 이해가 된다. 내가 처음 MS-Windows 3.1을 만났을 때와 같은 심정이었을 것이다. 컴퓨터를 처음으로 시작할 때 만난것은 Apple II와 MS-DOS 3.x 그리고 UNIX를 기반으로한 터미널이었고 제대 이후에 PC환경의 급격한 변화로 인하여 MS-Windows를 만났을 때 무엇을 해야할지 컴파일은 어떻게 해야할지 난감한 상황도 있었다. 그러다가 어차피 우리나라에서는 MS-DOS나 MS-Windows를 기반으로 하지 않으면 프로그래머로서 살아가기 힘들다고 결정을 하고 MS의 OS를 위주로 이것 저것 배우고 있었다. MS-Windows를 만났을 때 우연히 PC통신을 통해서 LINUX SLS배포판도 접하게 되었고 주 OS는 MS-Windows(MS-DOS)였지만 LINUX로도 이것 저것 많은 것을 해볼 수 있어서 다른 사람보다는 LINUX를 쉽게 접근한 것인지도 모른다.

LINUX는 어렵다. 맞다. 하지만 MS-Windows도 어렵다. Mac도 어렵고 안드로이드도 어렵다. 쉬운 것은 없다. 사실 쉽다고 느끼겠지만 쉬운것이 아니라 습관이 된 것일 뿐이다. MS-Windows가 쉬운 것이 아니라 MS-Windows에 길들여져서 쉽게 느껴질 뿐이다. 혹시 어떤 프로그램이 설치되어있는데 이것을 삭제하려면 Uninstall은 제공되지도 않고 이 프로그램이 서비스로 실행되고 있어서 서비스를 내리고 직접 삭제를 해야하고 레지스터리를 찾아서 지워야한다는 상황이 발생한다면 어떨까? 사실 MS-Windows를 사용하는 사람중에 Uninstall이 지원되지 않으면 프로그램이 어디에 설치되어있는지도 모르는 사람들이 상당수 있다. 개발자라하더라도 서비스프로그램이 무엇이며 왜 필요한지 그리고 만드는 방법도 모르는 개발자가 상당수 있다. 서비스 프로그램이 무엇인지는 아는데 그것을 내리는 방법을 모르는 개발자도 상당수 있다. MS-Windows가 쉬운것이 아니라 사용자가 어려운 것을 모르도록 MS사에서 UI를 만들어 놓았고 그것에 익숙한 것 뿐이다.

어떤 OS를 잘 사용해 보겠다는 의지도 없고 남들이 안정적이라니 한번 해볼까하고 접근했다가는 평생을 가도 해당 OS는 배우지도 못한다. 위 블로그에서는 svn을 LINUX에서 돌리고 있는데 정전으로 이상이 생겼다는 에피소드도 있었다. 담당자가 퇴직을해서 어떡할까 생각하다 개발자들 svn이 최신으로 되어있으니 그냥 포맷을 했다는 에피소드도 있었다. 만일 사용할 생각이 있었다면 Google에서 'linux용 scandisk'로 검색을 하고 몇몇 글들중에 fsck를 찾았을 지도 모른다. 하지만 그냥 지인들에게 연락을 해보고 모른다는 답변에 포맷을 결정했다는 것은 안타까운 일이다.

사실 MS-Windows를 사용하든 LINUX를 사용하든 Mac을 사용하든 네가 뭔 상관이냐는 사람들도 있다. 맞는 이야기다. 상관할 필요없다. 그사람이 알든 모르든 내 알바 아니다. 하지만 사람이 평생 밥만으로 식사를 하지 않아도 된다는 것을 안다는건 중요한 일이다. 빵을 먹어도 살수 있으며 스테이크를 먹어도 살 수 있다. 때로는 한끼를 안먹어도 죽지 않는다. 내가하고 싶은 이야기는 다양한 경험을 해보라고 충고하는 것이다. 깊이는 들어가지 않아도 이것 저것 경험을 해보면 현재 자신이 처한 어려운점을 오히려 쉽게 해결할 방법을 배울 수 있기 때문이다. 한 예로 한 플랫폼 프로젝트에서 해결되지 않는 부분이 있었다. 네트워크 연결을 12까지만 할 수 있고 그이상 연결을 하려면 더 이상의 연결이 되지 않는다는 메시지만 출력할 뿐이었다. 아무도 왜 이런 현상이 생기는지 알 수 없는 상황이었고 네트워크 라이브러리 개발자도 난감할 뿐이었다. 커널개발자도 모르고 있었다고 생각한다. 그때 생각 났던것은 MS-DOS시절 파일을 Open할때 기본으로 12개의 파일만을 다룰 수 있었지만 config.sys라는 리소스 정의 파일에서 FILES=30 이라는 정의를 통해서 Open할 수 있는 파일개수를 늘릴 수 있었다는 생각이 났다. 그래서 커널개발자에게 사용하는 커널이 무엇인지를 물어보고 Qos를 개조했다고 소리를 들었고 당시 Qos가 MS-DOS와 유사하다는 것을 어렴풋이 알고 있었기에 FILES라는 정의가 혹시 있는지 만일 있다면 그것을 늘려줄 것을 요청해서 문제를 해결했던 기억이 있다. 어려우니까 또는 내가 사용할 OS가 아니니까, 내일이 아니니까 넘어갔었다면 나는 12개의 연결 포인트로 되지도 않는 프로그램을 작성했어야만 했을 것이다.

그리고 여기서 또 한가지 프로그래머들이 알아야하는 것이 있다. 알고 있는 프로그래머들도 있겠지만 이 개념은 UNIX에서 나왔고 현재 동작되고 있는 대부분의 OS에서 알게 모르게 통용되는 부분인데 OS는 장치들도 하나의 파일로 취급을 한다는 것이다. 위 예에서 네트워크 연결과 File Open에 필요한 정의인 FILES를 연계해서 생각했던 이유는 바로 네트워크의 연결 또한 OS는 File처리의 한부분으로 생각하기 때문이다. 이 부분에 대한 자세한 설명은 UNIX관련 기초서적에 자세하게 언급되어있다. 랜덤파일, 순차파일, 블럭파일, 문자파일 등등에서도 다루고 있으니 궁금한 사람을 해당 서적을 찾아보는 것을 추천한다. 다만, 인터넷을 통해서 검색을 하는 것 보다는 직접 책을 사서 볼 것을 권장한다.(이부분은 나중에 글로 써볼까 생각한다. 아직 정리가 안되어서...)

이젠 결론을 지을 때가 된 것 같다. 결론은 'LINUX는 어렵다.'이다. 그리고 '새로운 경험을 주저하는 자는 배우지 말라.'라고 말하고 싶다. 그냥 편하게 현재 상황에 안주하면 된다. 어차피 LINUX나 다른 OS를 배우고 잘해도 누가 알아주지 않는게 프로그래머이다. 그러니 현재 상황에서 최선을 다하는 것이 중요하다고 말하고 싶다. 하지만 빵도 먹어보고 싶고 스테이크도 먹어보고 싶은 사람에게는 강력하게 추천한다. 도전을 하면서 실패도 할 수 있지만 그 과정에서 배우는 것들도 있을 것이고 그것이 현재 안주하고 있는 곳에서 더 큰힘을 발휘할 수 있다고 본인은 믿기 때문이다.

'생각' 카테고리의 다른 글

해외 주문 영문 뜻 정리  (0) 2018.01.08
인기있는 노래, 좋은 노래  (0) 2015.06.16
최민수를 아시나요?  (0) 2009.01.28
나 강훈인디...  (0) 2009.01.02
무슨 맛일까?  (0) 2007.11.10
Posted by codebank
,