Unix Programmer가 되려면?

전 유닉스 프로그래머로 일한지 10여년이 지났습니다. 물론 가끔 윈도우 응용 프로그래밍을 개발한 적도 있고 웹프로그래밍을 한 적도 있습니다만, 여전히 가장 많이 했던 일은 유닉스 프로그래밍이었고 이제 조금 유닉스 프로그래머다라고 말할 수 있는 느낌이 듭니다.

어쨋든 어줍잖은 저의 경험이지만 도움이 될까해서 글을 씁니다.

우선, 많은 고민후에 결정하신일이라고 생각합니다만 다시 한 번 고민하시라고 말씀드리겠습니다. 대우가 별로 좋지 않기 떄문입니다. 수요가 너무 적기때문이지요.

C/C++계열로 먹고 살자면 현재 제일 수요가 많은 것은 윈도우 응용프로그래머인 것을 잘 알고 계실 것입니다. 유닉스용 응용프로그래머는 갈수록 입지가 좁아지고 있거든요. 현재 시장에서 필요로 하는 유닉스용 응용프로그램은 FTP나 통신데몬 정도로 줄어들고 있는 실정입니다. 한때 미들웨어 붐이 불어서 아직까지 그 쪽 계통의 프로그래머로 일하시는 분들이 있긴 하지만 그나마 미래는 불투명합니다. 유닉스 응용프로그래머의 수요가 그러한데 응용프로그래머들에게 인터페이스를 제공하는 시스템 프로그래머는 암울 그 자체지요. 저또한 가끔 딴길로 샛다고 말씀드린 것이 만족할 만한 대우를 받지 못한 관계로 그런 것입니다.

이런 상황떄문에 유닉스 프로그래밍을 꿈꾸다가 SE나 CE로 지향하시는 분들이 꽤됩니다. 물론 이것은 정통 유닉스 프로그래머가 되기를 생각하신다고 가정하고 말씀드리는 것입니다. 자신의 일이 유닉스 프로그래머인지, 웹플머인지 SE/CE인지도 모르는 비기너라면 곤란하겠지요. 사실 상당수의 SE/CE나 웹프로그래머들이 단지 유닉스상에서 일한다는 이유로 자신을 유닉스 프로그래머로 착각하고 있답니다. 이런 경우 경력과 상관없이 여전히 초보자인 것이죠. 허송세월만 산것입니다. 잘아시겠시만 이런 사람들에게 유닉스 응용프로그래머와 유닉스 시스템 프로그래머의 차이를 설명한다는 것 자체가 난센스 아니겠습니까? 쩝 이야기가 딴데로 샛네요.

산전수전 다 겪으셨다니 상황을 잘아실텐데도 굳이 유닉스 프로그래머가 되시겠다는데에는 나름의 각오를 하신거라 생각됩니다. 그렇다면 우선 공부의 방향은 제대로 잡스신 것 같습니다. "The C Programming Language", "Advanced Programming In the Unix Environment", "Unix Network Programming", "The Design of the Unix Operating System" 등등과 같은 책들은 유닉스 프로그래머들의 바이블과 같은 양서죠. 대다수의 유닉스 프로그래머들이 고객들을 상대로 아키텍쳐를 설명할때 책들의 내용이 자주 언급됩니다. 이를테면, "이 방식은 Unix Network Programming에서 소개된 내용인데, 다음 모듈은 어떻다... "식으로요. 그러나, 제대로 마스터하시는데 꽤 시간이 걸리는것은 각오하셔야 할 것입니다. 그리고 공부하시면서 틈틈히 운영체제에 대한 공부를 곁들이시면 금상첨화일겁니다. 미약한 지식이나마 한 권 권하는데, Operating system concepts( galvin 저 )를 권합니다.

원하시는 바 성취을 기원합니다.

유닉스 프로그래머라..
유닉스 할려면 공부 많이 해야됩니다.
OS 를 애인보다 옆에 끼고 살아야 된다고 생각하는데..ㅎㅎ
말씀하신 책들은 정석입니다. 그 책들 보시고.
그런데 이상하게 네크워크 책이 빠졌군요.

유닉스 프로그래머가 될려면
(순서)
1. OS 구조 / 운영 / 방법 / 설계
2. 시스템 프로그래밍 (특히 프로세스, 스레드)
3. 네트웍 프로그래밍 (버클리 소켓)
4. X Window 프로그래밍 (Xt 툴킷, 모티프)
를 반드시 공부해야 됩니다.

부가적으로 gtk 같은 것도 공부하면 좋겠지만,
제가 보기엔 아직 표준은 모티프 같던데..
엑스 윈도 프로그램은 상당히 쉽습니다.
참고로 MS 윈도 프로그래밍은 한번도 한적이 없어서 모릅니다. MS 쪽은 완전 까막눈입니다. 그 흔한 비주얼C++/베이직 쓸줄도 모르거든요.

공부해보시면 아시겠지만... MS윈도우는 유닉스를 흉내낸 것이라는 인상이 강하게 남을 겁니다. 유닉스를 학문처럼 역사가 있고 체계적이라서 공부해보면 재미있습니다.

커널을 건드려야 제대로된 유닉스 프로그래머다?

건드려서 뭐하게? 쓰잘데기 없는 장난이다?

이 두가지 의견이 팽팽하군요.
제 생각은 커널 건드려 보면 당근히 OS 에 대한 이해를 깊이있게 할수 있으니 좋다고 봅니다. 그것이 당장은 불필요한것이라고 하더라도..

OS 에 대해 빠삭히 알아야 하는 분야도 있을테니 전혀 불필요한 헛짓 같지는 않습니다.
그런데 만약에 파워빌더나 JSP 같은 것만 죽어라고 쓰는 응용레벨 프로그래머가 리눅스 커널 알아서 뭐하는데 쓰겠습니까?

결국 시스템 프로그래머로 쭉 커리어를 가지고 가겠다고 하는분은 커널 건드리는게 도움될듯 합니다.

황당하네요. 프래그래밍 언어 보다 도구가 더 중요하다?

이렇게 생각하는 분들도 계시군요. 도구는 도구일뿐... 중요한 핵심은 문제해결능력 이죠. 결국 적절한 알고리즘, 자료구조 그리고 프로그래밍 언어.. 이런것들이 젤로 중요하죠.

유닉스 프로그래머 수요가 있긴한데.. 다른 프로그래머에 비해 더 잘쳐주는거 같진 않아요.
엠베디드나 대용량 디비 프로그래머를 더 쳐주는 경향이 있어요.. 대기업 금융업체나 SI 업체도 물론 유닉스 많이 쓰죠. 그런데 대부분 유닉스 프로그램은 하청을 주죠. 하청업체는 보통 가난하게 사니까.. 결론은 유닉스 프로그래머는 배고픈 프로그래머???

저는 인터넷 업체에서 유닉스 프로그래밍을 주로하는데 업체 성격상 웹프로그래머를 더 쳐줘요. 너무 자주 옮기는게 경력상 않좋기 때문에 참고 버티고 있죠.

하드웨어 업체에선 유닉스 프로그래머가 제대로 대우 받을라나...? 그건 잘 몰르겠네요. 돈잘버는 유닉스 프로그래머 있으면 리플 좀 달아주세요. 희망을 좀 갖게.. ^^

제 생각에는 플밍 테크닉이나 운영체제에 대한 이해도도 중요하지만 플밍도구도 상당히 중요하다고 생각합니다. automake, srpm, autoconf, make, gcc 등도 자세히 알고 있어야 한다고 생각합니다. 그거 모르고 다른 사람이 작성한 코드를 분석한다는건 어불 성설이거든요.
GNU 문서에 가면 아주 자세히 나와있더군요.
아 그리고 우리나라는 영어권이 아니니까 locate나 gettext같은 지역 선택 관련 내용도 필수라는 생각도 듭니다.

책은 일단 기초를 다지기 위해 사용하세요.
그리고 관심있는 소스를 많이 받아서 컴파일 해보고 고쳐보고 코드를 일고 이해하세요.
코드를 보고 막히는 부분이 있으면 관련 문서를 찾아서 읽고 이해하도록 노력하세요
책만 봐서는 프로그래밍을 잘할 수 없습니다.
코드를 보세요!

프로그래머는 특정 프랫폼이나 특정 언어에 국한되어서는 안된다고 봅니다.
우리나라에서 유닉스로 프로그래밍을 해서 제품은 만들고 있는 회사가 과연 몇 개나 있는 지 궁금합니다.
보안 쪽 Firewall, VPN 쪽이 좀 사용하는 나머지는 글쎄요.
자신을 어디에 구속하지 말구 두루두루 잘하는 사람만이 살아남을 수 있는 세상입니다.

공룡책이 뭐죠????

저는 Brien W.Kernighan 과 Rob Pike이 쓴 The Unix Programming Environment를 권하고 십습니다. 오래된 책이지만 쉽고 재미있으며, 특히 Epilog는 Unix approach or philosophy에 대한 기술이 있어서 기억에 특히 남는 것 같습니다.
Unix 프로그래머가 되고 싶은 누구나 먼저 읽어 봐야되지 않을까 하는 생각이 듭니다.

......
우리는 서문에서 프로그래밍 작업에 접근하는 한 스타일인, Unix approach or philosophy가 있다고 말했다...
첫째, 머신이 일을 하게 해라. 다른 시스템에선 손으로 할 작업들을 머신이 대신 하도록(to mechanize) grep그리고 wc그리고 awk같은 프로그램을 사용하라.
둘째, 다른 사람들이 일을 하게 해라. 이미 있는 프로그램들을, 셸과 프로그램할 수있는 필터로 함께 붙여서, 당신 프로그램의 '빌딩 블록'으로서 사용해라 ... Unix환경은 수 만가지 방법으로 결합가능한 툴들로 풍성하다; 당신의 일은 때론 단지 적합한 결합(combination)을 생각해 내는 것이다.
셋째, 일을 단계적(in stages)으로 해라. 쓸만할 것 같은 가장 단순한(the simplest) 것을 만들어라, 그리고 당신의 사용 경험이(your experience with that) 다음으로 되어야할 가치가 있는 (만약 있으면) 것을 결정하게 해라. 사용 패턴들이 당신에게 어떤 것이 필요한 지를 말해 주기전엔 features와 옵션들을 추가 하지 말라.
넷째, 툴들을 만들어라. 단순히 환경에 더해지기 보단 그것을 향상 시키는, 기존 환경과 잘 맞는(to mesh with) 툴들을 만들어라(write).
......
...그리고 그 (유닉스의) 인기는, 편리하다고 여겨질만한 프로그래밍 환경의 디자인을 칠판에 스케치했던, 1969년의 몇몇 사람들의 명료한(clear) 생각에로 거슬러 올라 갈 수 있다...-에필로그 본문 중에서

유닉스에서 C 라는 건....
C + UNIX 가 융화된 형태라서
C 언어만 잘아서는 써먹을 데가 없습니다.

공부하려면 머.. 스티븐스 책 씨리즈 보면 되고여.. 아. 되도록이면 비싸더라도 원서를..
번역판 보다가 성격이 나빠지거나, 잘못된 이해를 할 수도 있습니다.

다음은 man, /usr/include/*.h

unix system 프로그래머가 잘 팔리냐구요?
글쎄요. 나만의 추측인지 모르지만, 프로그래머 인구 전체에서 5 ~ 10% 만 있어도 수요에 대한 공급은 될 거 같습니다.

아직 프로그래밍을 한건 아니지만, 제가 앞으로 할 일이 솔라리스의 CDE윈도우즈에서 돌리는 프로그램입니다. 장비제어를 GUI로 수행하는 프로그램인데, 미국회사와 제휴를 맺고 국내 모대기업에 납품하는 장비입니다. 그 장비 컨트롤 콘솔이 선 웍스테이션입니다.
이거 말고 일본장비도 비슷한 성격의 장비인데,선 웍스테이션을 장비 제어용으로 사용하는군요.
xNIX 프로그래밍의 실제 사용은 순수 소프트웨어계열보다 하드웨어 관련 업종에서 의외로 많이 쓰는것도 같네요.

임베디드 리눅스 가 그냥 기존의 필요 없는 부분 빼면 된다고 하시는 분이 있었던것 같습니다 윗글에...

하지만 제 생에는 기존에 있는 것 지우는 것이야 쉽지만.... 지워진 모듈이름 말고 모듈 내부 동작 이해는 어렵지요.... 대략이라는 범위 안에서는 이해 하시겠지만.. 대략으로 뭘 할 수 있지요?

perl을 만든사람도 게을러서 만들었다고 합니다.

unix system을 관리하다 보니.. 불편해서
더욱 게으름 피기 위하여 perl을 만들었다고
하는 군요.

그래서 나온말이 '게으른 프로그래머'입니다.

게으름 필려면 좀더 쉽게 살 방법을 만들어야
하지 않겠습니까?

열라 열심히한다 -_-;; 당연한 말...