Develop/ETC

ETC #4. 주니어 SE의 커리어 고민

ZunoXI 2024. 4. 20.

들어가며

(허심탄회하게 작성한 글인만큼 전체적인 글의 내용이 반말, 음슴체인점 양해부탁드립니다.)

 

이제 막 만으로 4년차가 넘은 주니어 SE로써 얼마 안 된 경력이지만 지금까지 일해왔던 것을 배경으로 향후 커리어를 어떻게 가져가야 할지 고민이 많은 요즘이다.

 

부족한 것 천지인 나를 신입으로 품어준 감사했던 전 직장, 여전히 부족한 실력이었지만 IT 붐일 때 막차를 타고 올 수 있었던 내 꿈의 직장 현직장. 두 곳에서 각각 SA 업무와 SE 업무를 경험해 보고 앞으로 어떻게 커리어를 쌓아가야 할지에 대한 고민이 많다. 이 글도 지난 나의 취업 관련된 글들처럼 언젠가 이불킥(?)하며 비공개 처리될 글일지도 모르지만, 일기처럼 그리고 나와 같은 고민을 하는 IT 인프라 업계 주니어들에게 공감과 위로가 될까 싶어 이 글을 작성해 본다.

 

 

왜 인프라로 발을 들였나

 

 

 

우선 나는 컴공 전공자이며 군생활 중 통신 인프라를 간접적으로 접했었다. 간부로 복무하며 사단급 규모의 통신 체계를 다뤘기 때문에 통신체계에 대한 기초, 그리고 전산실이 어떻게 돌아가는지 등 지금 현업의 시선에서 봤을 때는 IT 인프라 분야를 찍먹 해봤던 시절이 아닐까 싶다. 무튼 그 경험이 나에게는 나름의 경험이었기 때문에, 훗날 취업할 때도 선호했던 분야로 작용했던 것 같다. (그러지 말았어야 했는데..)

 

학교를 졸업 후 군복무를 했기 때문에 졸업기준으로는 첫 직장에 입사하기 전까지 공백기가 꽤 길었었다. 어떻게든 살아남고자 전역 후 삼성과 포스코에서 각각 웹개발, AI에 대한 교육을 받았는데 당시 나름 핫한 교육과정이었어서 입과 시 경쟁률이 꽤 치열했던 것 같다. 그래서 그랬을지 교육내용의 완성도도 높은 편이었고 덕분에 취업 전 속성과외(?) 비슷하게 받은 상태로 취업시장에 뛰어들게 되었다. 그 모든 경험이 짬뽕이 돼서 '개발을 잘하는'은 절대 아니고 '개발을 좋아하는' 정도의 인프라 엔지니어 포지션으로 구직을 시도했고 마침 그런 니즈가 있는 포지션에 취업을 하게 되었다.

 

SA로써의 커리어

 

누구나 그러하듯 신입시절이기도 했고 아직 내가 하고 있는 게 업계 표준인지, 최신 기술이 맞는지 조차 모르고 업무를 했던 것 같다. 그때 당시 내 주 업무는 그룹사의 가상화 서버 관리 및 미들웨어, 메인모듈 애플리케이션 관리였는데 지금 생각해도 너무 넓은 업무범위다.

 

서버관리에 대해 먼저 말해보자면 보통 벤더를 끼고 일하다 보니 OS영역만 다루고 H/W의 fault는 거의 벤더를 통해 해결해서 가상화 대비 물리서버에 대한 전문성을 쌓기는 상대적으로 어려웠던 기억이 있다. 근데 솔직히 말하면 그 부분은 가상화 쪽도 마찬가지다. 가상화는 주로 vmware의 esxi를 운영했는데 이 역시 설치부터 크리티컬한 장애처리는 벤더를 통해 처리했다. 그때는 벤더 엔지니어분들이 참 대단하다고 생각했는데 지금은 내가 그런 일이 내 업무 중 하나인걸.. 그리고 애초에 서버대수가 현직장과 비교하면 압도적으로 적었던 것 같아서  전문성을 키울 노력도 별로 하지 않았던 것 같다.

 

미들웨어 관리, 이게 제일 힘들었는데 장애가 여기서 정말 많이 났었기 때문이다. 내가 다뤘던 미들웨어는 weblogic과 tomcat 그리고 apache 웹서버이다. 이 외에도 jeus, iis 등 다른 was들도 다루긴 했는데 그건 메인이 아니었고 실질적으로 weblogic을 가장 많이 썼던 것 같다. 덩치가 있던 고객사였다보니 비싼 weblogic 라이센스와 벤더 계약도 되어있어서 이 역시도 크리티컬한 장애나 최초 설치 처리는 벤더의 도움을 많이 받았다. 대부분의 코어 기술력은 벤더를 의지했지만 그래도 기본적인 설정변경이나 스케일 아웃과정의 설정들은 가이드를 기반 직접 작업했기 때문에 미들웨어 관리 쪽에 손이 제일 많이 가고 장애 대응도 많이 했던 기억이 있다. 근데 제일 많이 다뤘지만 현재는 하지 않는 일이기도 하다..

 

마지막으로 메인모듈 애플리케이션 관리이다. 일단 나는 취업전 할 줄 아는 언어는 java밖에 없었고 그 수준도 java로 알고리즘 문제를 풀 수 있고 간단한 웹사이트를 만들 수 있는 수준밖에 되지 않았다. 다행히도 입사 후 유지보수 해야 할 시스템은 ejb로 구축된 서비스였고 덕분에 java 개발을 조금이나마 현업의 입장에서 체험할 수 있었다. 그 유지보수의 수준은 시스템의 로그인 페이지나 필터클래스와 같이 세분화된 각 파트의 개발자들은 담당하지 않을 만한 공통 업무를 개발하는 업무였는데, 덕분에 다른 사람이 짠 코드(15년도 더 지난)를 보면서 공부도 많이 되었고 취미로 혼자 개발도 해보는 약간의 개발자스러운 시간을 보냈던 신입 시절이었다. 

 

어느 날 문득..

 

나는 위 업무들을 하며 그래서 내 직무가 뭘까?라는 생각을 했다. 명함에 박힌 나의 직무는 '인프라 엔지니어'인데 그런 직무는 너무 러프한(?) 직무라는 생각이 들었다. 당장 그 당시 같은 팀 인원이 각각 네트워크, DB, 서버 파트로 업무를 나눠 일하고 있었고 공통되게 인프라 엔지니어라는 타이틀을 달고 있었기 때문이다. 그러던 중 모종의 이유로 이직을 결심하며 이직시장에서 내 경력을 대조해 보니 '나는 System Engineer였구나' 라는 생각을 하게됐었다. 내가 했던 일들과 매우 유사했다고 느꼈기 때문인데 실제로 그때 그 경력을 갖고 지원했던 SE 직군에 대부분 붙었었다. 그때 내 경력이 진짜 SE 경력이라 된건지 전직장 회사 덩치빨로 된건지는 모르겠지만 무튼 그 경력을 갖고 지금 회사에 오게되었다.

 

전직장, 나의 신입시절은 좋은 기억들이 가득하다. 과거는 미화된다지만 무엇보다 같이 근무했던 분들이 정말 좋았고, 내 사수분은 인생의 멘토라고 생각할 정도로 존경받아 마땅한 어른이었다. 회사의 처우나 복지는 만족할 수준이었고 이직할 시점쯤에는 업무적인 분야에서도 내가 내 분야에서 목소리를 낼 수 있는 위치에 있었다고 생각한다. 다만 나는 내 업무 분야가 너무 광범위해서 전문성이 떨어진다는 생각이 항상 들었다. 소수의 인원이 인프라를 관리하고 개발도 하며 심지어 ups/전기 쪽 이슈를 대응하거나 잦은 문서작업, 누군가는 해야하는 업무외적인 잡일(?)들이 꽤 많았던 것 같다.

 

또한, 나는 여러 교육과정 참여와 지속적인 자기개발 중에 취업을 했었던터라 그게 몸에 배여서 였을까 신입으로 입사 후 2년간은 거의 주말에도 공부를했고, 속한 팀에서 신기술을 활용한 프로젝트를 진행함에 있어 개인시간을 활용하여서라도 프로젝트를 나름 성공적으로 완료했던 경험이 있다. 이 얘기를 한 이유는 회사생활을 하면서 결코 업무시간에만 일했던 것이 아닌 끝없이 개인개발을 위해 노력했다는 것이며 이 블로그도 그 증거 중 하나라고 할 수 있는데, 그럼에도 불구하고 나는 내가 전문성을 갖춰나가고 있다는 느낌이 들지 않았다. 그 이유 여러가지가 있겠지만 가장 큰 이유는 내가 해야할 업무 범위가 너무나 넓다는 것이었다. 대부분의 IT 계열사가 그러겠지만 소수의 인원이 만명이 넘게 사용하는 서비스의 서버, was, 형상관리, 공통 어플리케이션 유지보수 등을 모두 전문가 수준으로 딥하게 하기 쉽지않겠다는 생각이 들었다. 그저 일이 많은게 아니라 범위가 너무나 넓게 느껴졌고, 물론 그게 이직할만큼의 불만요소는 아니었지만 진짜 서버 인프라적인 업무만 전문적으로 하고 싶다는 생각을 했다.

 

 

 

"그렇게 나는 현재 서버 인프라적인 업무만 전문적으로 하게 되었다."

 

 

SE로써의 커리어 전환

 

처음에는 그저 좋았다. 이제 더이상 스트레스 받아가며 web/was 장애대응하거나 개발 유지보수 할 필요도 없고, 잡스러운 일들은 더더욱 없으며 잦은 문서작업도 없어졌다. 그저 서버관리 업무만 딥하게 하면 되게 되었다. 그리고 업무에 적응해 갈 때쯤, 그동안 했던 업무들은 SE 업무가 아니라 SA(System Administrator), 시스템 관리자 업무라는 것을 깨닳았다. 잘 생각해보면 나는 딥한 트러블 슈팅은 대부분 벤더사를 통해 처리했고, 벤더사에서는 실제 벤더 엔지니어가 그 조치를 취했으니 나는 엔지니어라기보다는 어느정도 운영업무를 하는 어드민에 가까웠던 것 같다. 해결할 능력이 없었던것도 맞지만 해결을 시도할만한 시간도 여유롭지 않고, 조직에서도 딥한 트러블 슈팅을 내가 직접하는 것을 선호하지 않았다. 신입으로써 문제를 파고들어 해결하려는 모습은 좋게 봐줬지만, 궁극적으로는 회사대 회사로 벤더 계약이 되어있기에 이를 활용하는 좀더 관리자적인 업무수행능력을 중요 역량으로 여기는 것 같았다. (나의 완전한 주관적 생각이다 ㅎ)

 

 

그렇게 이직하고 1년정도 SE업무를 하다보니 지금은 겉으로는 같아보일지 몰라도 내부는 결이 다른 직무를 하고 있다고 느껴진다. 현재는 전체적인 흐름에서 대규모 인프라를 바라보고 이슈 발생 시 네트워크부터  시스템 로그 단까지 벤더 지원없이 이슈를 해결해야하는 말그대로 시스템 엔지니어의 역할을 요구받는 것 같다. 전직장 대비 관리하는 서버의 규모 차이도 엄청난데 인당 관리하는 서버 수를 따지자면 100배가 넘는 수준이라 일일이 관리하기 힘들기 때문에 벌크로 관리하거나 전체를 관제할 수 있는 모니터링 툴도 직접 개발해서 사용해야한다. 전직장이었으면 벤더를 통해 모니터링 툴을 구축했을 것 같은데, 지금은 그마저도 시스템을 구축하기 위한 개발을 하고있다. 또한, 인프라의 범주에서 K8S 플랫폼도 관리하는 롤을 맡아 플랫폼과 밀접한 서버관리에 대해서도 전문성이 향상되는 것이 확실히 느껴진다. 즉, 기술적으로는 좀더 분야를 좁혀 확실한 스킬업 하고 있다고 생각한다.

 

그리고 딜레마

 

다만, 대외 서비스에 대한 개발이 없다는 것과 미들웨어를 다루지 않는다는점은 향후 커리어에 대해 불안함을 갖게 되는 딜레마인 것 같다. 그토록 하고 싶지 않은 것이라 내려놓고 싶었는데 지금 생각해보니 그것도 할줄 알아야 향후 커리어의 선택지가 넓어질 것 같다는 생각이 드는 것 같다. 특히나 요즘 업계에서 SE에게 요구하는 중요 요건 중 하나가 AWS를 이용하여 퍼블릭 혹은 하이브리드 클라우드를 구축하는 일이 많은 것 같은데, 현직장 특성상 AWS나 해외 퍼블릭 클라우드를 사용할일이 없다는건 생각하지 못한 새로운 이슈인 것 같다.

 

그래서 그런지 너무나 좋은 사람들과 꿈꾸던 회사에서 내가 원하던 일을 하는데도 어딘가 불안함이 존재하는것은 어쩔 수 없는 것 같다. 엔지니어이기 때문에 관리자만큼 폭 넓은 범위에 대한 시야를 가지기는 현실적으로 어렵다는 것을 알지만, 막상 엔지니어의 커리어를 시작해보니 향후 특정 분야의 스페셜리스트가 되는것과 넓은 범위를 아우르는 제네럴리스트가 되는 것 중 어떤 것이 롱런할지, 더 나에게 맞을지, 단순 SE/ SA의 업무 구분을 넘어 인프라 업계에서 어떻게 포지션을 잡고 일을 하는게 맞는지 고민이 되는 요즘이다. 사실 이런고민은 이직과 직무 전환이 잦은 IT업계의 종사자는 한 번쯤 고민 해볼만한 거리가 아닐까 싶기도하다.

 

한가지 확실한 것은 아직 SE로써의 경력이 SA로써의 경력보다 짧다는 점이다. 적어도 SA였던 시간만큼은 일을 해봐야 그때서야 조금더 객관적인 고민과 스스로에 대한 해답이 나오지 않을까 싶다. 그저 현실에 안주하지 않고 이렇게 계속 커리어에 대한 고민을 하는 스스로에게 감사할 뿐이며 언젠가 커리어 결정의 기로에 섰을 때 자의로 결정할 수 있게, 실력을 갈고 닦는 것을 게을러 하지 않는 내가 되었으면 좋겠다.

반응형

댓글