프로그래머로 전향

냉정하게 말씀 드리자면.. 현재 상태에서 php 개발자로 전직을 하셔도 크게 달라질 것은 없다고 보입니다. (물론 예외도 있습니다. 정말 S.E가 체질에 맞지 않으시다면..)

다만, S.E의 역할을 너무 스스로 축소를 시키고 있다는 생각은 듭니다. S.E가 하는 일은 님이 생각하시는 범위 이상의 일을 하게 됩니다. design + troble shooting은 기본이고.. 개발에도 참여를 하는 경우도 허다하고, 실제로 개발을 직접해야 하는 경우도 있습니다.

그리고 S.E는 시스템 전반을 아우러야 합니다. 어쩌다 보면 모르는 것이 없어야 할 수도 있습니다. 개발자가 와서 개발에 대해서 물어볼 정도로 말이죠. 예들 들면 가장 최근에 제가 개발자에게 받은 질문은.. "어떻게 해야 메일 제목이 깨지지 않고 받는 사람이 볼 수 있을까?" 였습니다. 답은..

=?CHARSET?B|Q?encoded-string?=

포맷으로 제목을 만들면 된다는 것입니다. 사소해 보이지만.. 이런 것 알고 있는 분들 얼마되지 않습니다. 물론 잘하시는 분들은.. 몰라도 해야할 경우가 생기면 알아서들 RFC 문서들 보시고 척척 잘 구현해 냅니다. 즉, 일반 사람들이나 개발자들이 상상하지도 못할 정도의 경험이 필요하거나, 또는 그 경험을 넘나들 수 있는 정도의 실력이 필요한 직업일 수도 있다고 생각합니다. 그만큼 S.E는 쉬운 직업은 아닙니다만.. 그만큼 진입 장벽이 높기 때문에 진입 장벽만 넘을 수 있다면 다른 분야보다 길은 훨씬 수월하지 않을까 싶습니다.

P.S.
S.E의 평가가 낮은 이유에 대해서 고민을 해 본적이 있습니다. 물론 우리나라 정서상의 특성이 가장 크기는 합니다만, 저를 비롯해서 스스로들 낮추는 경우도 적지 않다고 보입니다. 외국의 경우 operator / administrator / enginner 의 구분이 명확합니다. 그런데 우리나라의 경우 "S.E"는 거의 administrator의 업무를 칭하는 경우가 대부분 인 듯 싶습니다. 저 역시 administrator의 업무를 하면서 제 자신을 system engineer라고 칭하며 다녔고요. 그리고 가장 결정적인 것은 우리나라에서는 system engineering에 대해서 학문으로 체계화가 전혀 되어 있지 않다는 점입니다. 외국의 경우 system engineering에 대한 논문(학교에서 작성하는 논문이 아닌, 회사에서 작성된 논문들..)이 참 많다는 것이 제게는 개인적으로 큰 충격이기도 했습니다.

더 냉정하게 이야기드리면.

일단 7년차면 이미 두세개정도의 스크립트 언어는 마스터해야했을 시점입니다.

php , perl , python , ruby 중에 2개정도는 익혀두셔야하고.. ( 전 python 은 적당히 하고 나머지 3개는 보고 수정가능한 수준까지는 했습니다. )
c/c++/asm 으로 언어 확장정도는 코딩가능할정도가 되어야합니다.
디비는 mysql/pgsql/oracle 정도는 해야하고..
network 장비는 L3/L4/L7 VPN VLAN 정도 대략 만져야하구요.
스토리지도 san 장비 정도는 매뉴얼 보고 다룬 경험이 있어야합니다.

김정균님 말대로 프로그래머보다 잘해야 SE 라고 부를수 있습니다.

저는 현재 대략 10년차 SE 고.. 현재 여러가지 하지만 잠깐 하고 있는 일이

QOS, L7, DDOS 방어 장비,Flow 장비등 50대 장비를 관리하는 시스템을 만들고 있습니다. ( SI 성이긴합니다. )
개발은 python 으로 하고 웹단은 django 디비는 pgsql
백엔드는 syslogd , snmp , ssh client , ftp client 를 비동기로 엮어서 필요한 데이터를 수집해서 가공하고 웹단에서 조회가능하게 pgsql 에 밀어넣는겁니다.
대부분 라이브러리를 불러다가 쓰지만 많이 짰고 각종의 프로토콜이 어떻게 돌아가는지를 다 이해하고 있습니다.
웹은 html 을 대략 이해하고 css / javascript 를 적당히 쓰고 ( 요즘은 jquery 를 쓰지만 ) comet 을 쓰기위한 cometd 도 직접구현했습니다. ( twisted 기반 )
동접 1000/2000 정도의 tcp 써버는 파이썬으로 구현할수 있고 뭐 그거 넘어가면 그 때 c 로 짜면 된다는 생각으로 뭔가 만듭니다.
물론 코드는 훌륭한건 아니고 그냥 적당히 동작하는 정도입니다.

SE 가 딱히 어떻게 해야한다기보다.. 문제해결에 포커스를 맞춘게 SE 라고 생각합니다.
문제 상황이 주어지면 주어진 자원으로 해결이 가능해야하고.. 그게 코딩이든 솔루션의 조합이든 말이죠.
전 아직까지 사업이나 돈의 개념 그리고 소모자원의 개념이 많이 부족한데 그게 부족한건 저도 알고 있고 나머지는 SE 로 살고 있다고 생각합니다.
아직은 뭔가 사람을 다루는 직급이 아니지만 사람도 시스템의 개념으로 다루기 위해서 많이 공부는 하고 있습니다. ( 일종의 절차를 만드는 거죠 )

다시금 이야기드리지만..
SE 는 프로그래머의 슈퍼셋입니다. ( 코딩은 않하거나 못해도 되지만 어떻게 도는지는 세세히 알아야하니까 결국 해봤어야하는거죠 )
( 알고리즘도 당연히 프로그래머 이상으로 해야한다고 생각합니다. 실천은 못하지만 ㅠㅠ )
사랑하지 않으면 떠나라 라는 책을 추천해드립니다.
http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8991268358

SE = 프로그래머 + system admin + network admin + 경험

이라고 생각합니다.

------------------------------------------------------------------------------------------------
Life is in 다즐링

그러니까 말이죠.

VMWare 아키텍트가 와서 시스템 사이징을 어떻게 하면 되는지에 대해서 물어보고 (그것도 Unix to Linux Migration + VM -_-)

HP-UX 엔지니어가 스크립트 어떻게 짜고 시스템 정보 수집은 어떻게 하나 물어보러 오고

개발자가 와서 소스 이상하다고 봐달라고 그러거나 잘 도는지 검증 어떻게 하냐고 해달라고 그러고

Oracle DBA가 와서 DB 느리다고 뭐가 문제인지 봐달라고 오거나 새로 DB서버 살건데 어떻게 해야되나 물어보러 오고

JSP/J2EE 개발자가 와서 connection pooling 안된다고 이상하다고 고쳐달라고 오고

네트워크 담당자가 자기는 문제없다고 뻥카치다가 딱 걸리니까 "어떻게 알았어요?" 하고

L4/L7 엔지니어가 튜닝하다가 안되니까 와서 "아 이거 좀 서비스가 이상한 듯" 하길래 가서 "이렇게 이렇게 하는거예요" 하고 알려주고

방화벽 업체 엔지니어가 "이거 이렇게 이렇게 하면 되는거예요" 하길래 "거짓말하지 마세요" 라고 해야하거나 "그런 구식 방식으로 구성하시면 이러이러한 문제가 발생하세요. 지금 이 문제도 그래서 발생한거잖아요. 그럼 이러쿵저러쿵 해야지..서비스 특성을 감안해야지 그냥 되는데로 똑같이 컨설팅하면 그게 컨설팅이예요? 초등학교 선생도 아니고 왜 이러세요.." 라고 말해주거나..

AIX 혹은 Linux 시스템 작동구조가 어떻길래 대충 퉁퉁 짠 프로그램에서 이런 증상이 발생하냐고 물어보러 오거나

등등의 일들이 매우 자주 발생하니까 이걸 다 알아야됩니다. (...)

이걸 다 모르잖아요? 그럼 어영부영하다가 "쟤가 잘못했음" 이라고 저한테, 혹은 퉁쳐서 "OS가 잘못했음" 이라고 OS 엔지니어한테 뒤집어 씌웁니다. -_-; 보통 좀 대기업가면 이게 습관이 된 자식들이 좀 많아서 뒷통수쳐맞고 쿨럭쿨럭하면서 버럭버럭 대들어봐야 윗선에 다 얘기가 올라갔으므로 꾹 참고 있다가 다시 동일한 문제 발생하면 "음음 이건 이래요. 그러니까 저번에 이거 보라니까 안보더니 결국 이렇게 됐잖아요. 다음부터 그렇게 막 뒤집어씌우지 마세요~" 하면서 또 한방 먹이는 재미가 있다던지..(후우~ 십라대왕~)

7년차면 이제 Senior 가 될 준비 하셔야 겠군요.
Senior 라면 이것 저것 일을 벌리기 보다는 자신의 특정한 분야를 하나 준비하셔야 겠습니다.
그리고 그 경험을 바탕으로 한 깊이 있는 지식도 필요하겠지요.
또한,
Senior 라면 자신의 경험을 바탕으로 문제가 생기면 처리하기 보다 문제가 생기기 전에 먼저 움직이는 사람입니다. 적극적으로 말이죠.
위에 분들이 말씀하신 내용이 틀린것은 아닙니다만, 저는 문제 해결과 조언이 시니어 엔지니어의 주요 능력이라고 보진 않습니다.
전체적인 구조를 볼 수 있는 통찰력을 가진 엔지니어는 어느 조직에서나 가장 필요한 존재 입니다.
(저는 이게 SE의 매력이라고 생각 하는데요.)

이것도 할줄 알고 저것도 할 줄 알고, 이 장비도 다룰줄 알고 저 장비도 다뤄봤고..
대단한 엔지니어라고 생각 했는데 막상 조금만 깊이 있게 들어가면 금방 그 깊이가 들어나는 엔지니어들 많이 봐왔습니다.
네트워크 엔지니어가, 10년차 다된 시스템 엔지니어라는 사람이 TCP 3way handshake 에 대해 설명도 못하고, 저널링 파일시스템에 대해 이해도 못하는 건 정상이 아니지요.
설치나 셋업 그리고 문제 해결은 순식간에 하는데 운영 방안에 대한 고민은 없는 SE 들도 많이 봐왔구요.
머리로 일하는게 아니고 손으로 일하는 엔지니어들.. 잔재주는 한두달이면 바닥이 드러 납니다.

하드웨어 엔지니어들은 x86 서버들 때문에 별로 재미 없을 겁니다. 말씀하신데로 2,3년차들 수준이어도 문제없이 설치/운영이 되니까요.
앞으로도 더욱 쉬워질겁니다. Unix 장비들의 시장점유률은 앞으로도 계속 내려갈 전망이고요.

그리고,
다소 한국적인 상황을 감안 한다 하더라도 이것 저것 할 줄 아는게 자신의 몸값을 올리고 자리를 잡는데 도움이 되지 않는다고 봅니다.
PHP 개발자로의 전향도 자신이 목표하는 바가 있고 그 과정 중 하나가 아니라면 현재와 별로 달라질 것은 없을 겁니다.
개발자들도, DBA 들도 똑같은 고민 하고 있습니다. 이쪽에서 보면 안 그런 것 처럼 보이는 것뿐이죠.

아는 만큼 보인다는 말이 있습니다. 없는게 아니고, 보이지 않는 다면 자신의 시야에 대해 고민해 보시는게 먼저 인것 같습니다.
별로 도움이 되는 글을 못남겨 죄송합니다만, 말로 표현 하기가 쉽진 않네요.
그리고 영어 공부는 하시는지 모르겠군요. 시니어라면 영어로 협업 하는데 지장은 없어야 겠죠?

댓글들이 영양가가 있어서 훈훈 하군요.....

특히 연차에 따른 스킬레벨 정리는 명함에 적혀있는 직함이랑 직책을 부끄럽게 하네요.....(글쓰신 분 만큼의 연차는 아닙니다만..... 몇년남았네요 ^^)

짜증만 늘어가는 꽉채운 3년차에 많은 생각들을 하게 하네요.(추천이라도 있으면 눌러 드리고 싶음^^, 아님 소주라도 한잔~)

안녕 하세요

현재 개발회사에서 SE로일하고있습니다.
SE 도 여러가지 파가있는거 같네요 ㅎㅎ
저는 서버업체에서4년간 필드뛰다가 4년전 이직했는데요
예전에 잦은출장과 정말 슈퍼SE 를 요구하는회사인지라 솔직히힘들어서 이직했습니다.
이제 출장은 없는데 야근이 빡쎄네요 ㅜ

위에 말씀하신분들모두 존경스럽습니다.우선 자부심이 있어야 나도살고 모두가사는것같습니다.
unix3종(aix,solaris,hp-ux)linux,NT,방화벽,라우터,IPS,각종솔루션,무선,WAS3종(weblogic,oas,jeus)외 DB3종 기타 apache,tomcat등등등게다가 회사제품등 안해본게 없을정도인데요
이걸다 머리에 넣코다닐수가 없지요.. 이제는 감으로 일합니다. 경험인것 같기도하고요..
게다가 제안서 구성도 성능측정 슬슬문서쪽으로 빠지고있는 SE 1인입니다.

요즘 부사수에게 우리SE말고 다른이름을 달자고 했습니다. 진정 우리가 하는일이 SE인가요?
새로운 포지션을 만들어야하지 않을까요.. SE를 포함하여 뭔가 새로운 길을 만드는게 본질인것 같습니다.
내가 하지않으면 일거리도 없어지는것 같습니다.
구라로 일을 만들때도있고 살아남기위해 속도조절을 할떄도있고..그런데 제일 힘든것은
SE는 1~2명밖에 없다는거지요.. 얘기할 사람도없고 도와줄 상사도 없습니다.

아직 고민하고있는중인데 이번프로잭트끝나고 나름평가서를 만들려고 합니다.
PM이나팀장이아닌 SE가 평가하는프로잭트를 하는게 작은 기대입니다 ㅎ

그럼 다들 수고하세요..

저는 리눅스 잠깐 만지다가, 전산실에서 4년(Sun장비, 솔라리스 8), 전역하고 통합관제 잠깐,
Redhat 리눅스 기반에서 1년 서버운영, 다시 옮겨서 Debian 리눅스 서버로 서버운영중입니다.

명함에 SE라고 되어있지만, 제 생각에는 똑똑한 Operater이거나 초보 딱지는 뗀 SA라고 생각합니다.
일하다 보면, 여러 OS나 제품등을 다루었던 경험도 중요하지만,
그 전에 그 기반 프로코톨이나 OS를 잘 이해하는게 더 중요하지 않았나 생각이 듭니다.
서버 견적낼때 어떤 스펙이 제일 좋을까? 고민할때, 스펙에 대한 이해도 부족해서...HW공부도 해야겠구나~ 생각이 들때고 있고요.

PHP나, Perl이나 Python을 처음부터 공부했었더라면, SA하는데 있어서 더 높은 수준이 되었을텐데, 후회도 되네요.
운이 좋아서, 거의 갑의 위치에서 일했었기 때문에, (대부분 상용 제품을 썼기 때문에) 문제가 생기면 유지보수 엔지니어를 call만 하면 되었기 때문에,
직접 먼가 수정할 필요성이 없어서 그랬을지도 모르겠습니다.

이 정도 경력이 되니, 관심이 있는건,
재해복구라던지, 고가용성을 확보하는 문제라던지, 시설안전(소방/전기/항온항습)의 문제라던지
그런쪽도 해당 분야 전문가정도는 아니지만, 나중에 회의할때 아는척 할수 있을 정도로 공부해보고 싶지만, 워낙에 공부와 거리가 있어서....

또 지금은 시스템 모니터링하는데 오픈소스 가져다가만 쓰고 있지만, 가끔 개선하고 싶은 것도 있고 해서, 또는 간단한건 만들어
보고 싶기도 해서, 위에서 언급한 언어를 공부해볼까? 생각도 듭니다.

요새는 또 위키나, 이슈트래커를 이용해 서버관리하는 업무에 효율적으로 적용해보자~ 생각도 하고 있지만, 메모장 벗어나기가 힘드네요. ^^

결론은, 프로그래밍 언어 할줄아는게 없는 사람의 끄적임입니다. ^^.. 그런데 서버쪽도 알면알수록 어렵니다. ㅠㅠ
언어공부하자니, 서버쪽도 잘모르는데..? 이런 생각이 떠올라서...

그런데 이런글 올라오는것도 주기가 있나봐요

비슷한글 많이 읽은듯해요

많은 분들이 비슷한 고민을 했었다는거죠

ㅎㅎㅎ

http://kkanari.egloos.com/

SE 경력은 얼마 되지 않지만..
선배님들 글을 읽고서 도대체 어디까지 할 줄 알아야 하며..
어디까지 공부 해야 되나.. 막막해지네요 ㅜㅜ

커리어 패스 얘기가 있어서 적습니다.

크게 봐서 선택은 두 가지에요. 특정 분야/솔루션의 전문가가 되는 것이나, 여러 분야를 두루 경험한 후 전체를 볼 수 있는 엔지니어(아키텍트)로 발전해 나가는 것으로 생각합니다.

여러 기술 얘기가 나왔는데, 그 중에 특히 프로그래밍을 할 줄 아는 것은 스스로 해결책 (자동화 스크립트, 툴 등)을 만들 수 있다는 점과 어플리케이션과 개발과정을 이해할 수 있다는 점에서 아주 중요합니다. 하드웨어/OS 레벨에서 성장하지 못하는 분들을 많이 봤습니다. 그 이상을 보고 이해할 수 있어야 급여/대우도 좋아지고 더 어려운 일을 할 수 있습니다 (재미도 더 있겠지요).

현재 일하고 있는 환경에서 다양한 도전을 주지 못하더라도 절망하지 마세요. 몇몇분 말씀대로 프로그래머로 (뒤늦게) 옮겨서 나아질 것이 없습니다. 원래부터 프로그래밍을 아주 잘하셨다면 예외겠지요. 결국 큰 그림을 볼 수 없으면 뭘 해도 성장에 한계가 옵니다. 더구나 PHP는 진입 장벽도 낮잖아요?

커리어 패스를 생각하고 꾸준히 공부를 하셔야 합니다. 기본이 없으면 우연히 상위 레벨을 경험해도 자기 것이 되지 않습니다. 인터넷에서 글도 읽고, 부족한 영역은 정식으로 시간들여서 배우셔야 합니다. 그러면서 현재 자신이 어떤 위치인지, 어떤 분야가 관심이 가는지, 어떻게 나아가야 할 것인지 생각해 볼 수 있습니다.

이 글타래에서 많은 경력을 쌓은 분들은 그만한 노력의 시간이 있던 것입니다. 지금 조급하고 답답한 분들, 저런 경력이 부러운 분들은 아직 경력의 초반인 거니까 더딜수도 있고 돌아갈 수 있고 당연한 거에요. 실망하지 마세요.

최근에 읽은 글에서 저자가 operation을 정의해 보려 하고 있네요.

- 글의 링크입니다. http://www.netmeister.org/blog/defining-operations.html

- 글에서 나온 다이어그램입니다.

미국에서 사용되고 있는 이름/개념들입니다. 부연 설명을 하자면:

operations = IT 운영 전체를 일컫는 말. 운영조직, 운영팀이나 운영자를 가리키는 말로 많이 사용합니다.
ops = operations의 약어. 예) Network Ops (네트웍 운영팀)

다이어그램처럼 operations란 울타리 안에 여러 분야가 있습니다:
system administration
storage operations
network operations
web service operations
security
IT helpdesk
site operations = 데이터센터 운영
등등

+ 클라우드 컴퓨팅의 영향으로 전통적인 "ops"의 개념이 깨지면서 글에서 설명된 것처럼 "devops"라는 개념도 나오고 있습니다.