약 4년간의 SI생활을 마친 후 이직을 준비하면서 느낀 좌절감, 굴욕감, 회의감, 자기혐오, 자아성찰등의 여러가지 감정과 느낀점을 담아보려 한다.
결론적으로 SI의 기술스택으로는 유사한 SI외에는 이직을 할수가 없었다.
-> 현 시점으로 나는 연구개발팀으로 입사가 확정된 상태이다><
이에 관해서는 추후에 남길 예정이다.
만 4년을 근무하면서 나는 꾀 성실히 일해왔다. 요구사항이 있다면 그것이 무리한 요구사항일지라고 개발자로서 당연히 해야한다고 생각하였고, 현재 나로서는 할수없다면 미래의 나는 반드시 의래 해내야 마땅한것이라고 생각했다.
할수없는 요구사항은 스케줄을 조정해서라도 반드시 해내왔고 그럴때마다 내 직업에 대한 소명을 다한다고 자부했다.
그리고 이런경험이 쌓이면서 나는 성장하고 내 실력이 늘어간다고 생각했다...
면접을 보기 전까지는 말이다.
SI 발자취
그동안 여러가지 프레임워크를 다루었다. 크고 작은 프로젝트에 참여했고 오래된 레거시 시스템을 유지보수 했다.
그안에서 나는 주인의식을 가지고 열정을 불태워 필요한것들을 채워나갔다.
라이브러리를 사용할때는 기술문서를 읽어보고, 지원하지 않은 기능들은 어떻게 하면 내 수준에서 문제를 해결할수있을지 고민하며 그것을 해결해나가고, 한정된 시간에서 데드라인을 지키기 위해 다른 방법론을 적용해보기도하고, 레거시 시스템을 개선하기위해 리팩터링과 클린코드를 익히기도 하고 프레임워크를 뜯어보고 기능들이 어떻게 동작하는지 분석하여 개선하기도 했다.
4년이란 시간의 발자취를 따라가보니 많은 일들을 한거같다.
이직을 결정하고 가장 고민했던부분이 바로 지방도시에서 서비스 회사로 이직이 가능할까? 였다. 그리고 몇일 확인해본 바로는 이곳에도 몇개의 근사해보이는 스타트업 회사가 있었다.
그 동안 빚진 기술부채를 이제는 갚을수 있겠다 싶었다.
더 이상은 구현이 목적이자 전부가 아닌 우아하고 코드와 진보한 기술스택을 다룰수있는 기회가 왔구나 싶었다.
더 이상은 코드품질을 인질로 일정을 맞추어야하는 짓을 그만둘수있겠다 싶었다.
풀스택 개발자
처음 개발을 배울때 Java를 배우고 html, css그리고 javascript를 배웠다.
Java는 굉장히 정교한 느낌이였다면 javascript는 무언가 엉성하게 다가왔다.
그리고 java는 서버에서 돌아가는 코드라는 생각에 더 가치있는 것이라고 생각했던거같다. 나중에 백엔드 개발자로 성장하면 아주 튼튼하고 편리한 기능을 제공하는 그런 프레임워크를 만들어보고 싶다라는 생각을 했다.
하지만 지방도시의 소프트웨어 회사들은 먹거리가 정해져있다. 그리고 인력인프라적으로 보나 다른 여러가지 상황으로 보나 비니지스모델은 si에서 크게 벗어나기 어려운거같다.
그리하여 나는 한 SI회사에 취업하게 되었고 무슨일을 할지 부푼 기대를 안고 프로젝트에 투입하게되었다.
같이 취업준비를 하던 개발자들을 보면 풀스택에 대한 환상같은것들이 있던거같다.
나는 그것에 대해 회의적이였다. 제너럴리스트보다는 스폐셜리스트이고 싶었고 무엇보다 한가지 분야를 다루는것도 꽤나 버거웠다. 어쩃든 나에게 선택권은 없었고 그저 대상을 가리지 않고 열정을 품었다.
"주어진 일에 최선을 다하면 무언가 되어있겠지" 라는 막연한 생각이었다.
SI는 프론트엔드/백엔드를 구분하지 않는다. 사업의 주체이자 발주처에서 그러한 구분을 하지 않는것이기도 하고 여러가지 어른들의 사정에 의해 그러한거 같다.
무튼 나는 풀스택 개발자가 되었다.
SI 발자취2
첫번째 프로젝트에서 나름대로의 역할을 잘 수행했다고 느꼇다. 열정적이었고 주체적으로 임하였다. 동시에 약간의 혼란스러운점도 있었다. "무언가 되겠지!"가 "무엇이 될까?"였다.
혼란은 걱정과 압박감을 가져왔다.
"이렇게 하는것이 잘하고 있는걸까?" 라는 걱정과 무언가 더 채워야된다는 압박감이었다.
책도 보고 여러가지 컬럼같은것들을 읽으며 내가하는일에 대해 이해하려 했다.
선배의 추천으로 봤던 "소프트웨어 장인정신"은 정말 감명깊게 읽은 책이였다.
이러한 고민과 걱정은 4년 내내 나를 압박했고 비슷한 양상으로 시간은 흘러갔다.
2년의 시간은 레거시 시스템을 유지보수하는 일로 채워졌다.
소프트웨어 장인정신과 애자일 방법론은 내가 어떻게 소프트웨어를 대해야하는지에 대한 태도를 가르쳐줬다.
"동작하는 소프트웨어만으로는 부족하다"
"소프트웨어는 집짓기가 아닌 정원돌보기다" 같은것들을 말이다
실제 눈으로 엉망이된 시스템을 보니 크게 와닿게 되었다.
아무도 돌보지 않은 시스템 내부 소스코드는 여기저기드 코드뭉치가 뒤엉켜있었고
무엇을 나타내는지 알수없는 네이밍, 코드변경 후 반영되지 않은 개발자를 혼동시키는 주석, 거대해져 다른 함수와 결합된 함수덩어리 등 무언가 손을 대고나면 몇일 뒤 쓰레기 데이터와 담당자의 오류 피드백으로 고생해야했다.
그러그런 개발자가 전체 비즈니스를 맡게되고 그저 머릿수로 채워진 인원들, 코드품질은 무시하고 배포 후 운영팀이 알아서 하겠지라는 마인드의 개발자, 결과중심의 관리자, 대량의 문서가 있으면 잘 운영되겠지라는 사업팀 이렇게 진행된 프로젝트의 당연한 결과물을 마주하였다.
그래도 나는 장인정신을 가진 개발자이고 나는 현재 이 업무를 맡은 개발자이다.
손놓고 보고있을수는 없다. 개선해야 했다. 후임자에게 이런코드를 남겨주는건 부끄러운 것이다.
유지보수는 선호하는 사람들을 봤다. 업무난이도도 적고 일도 별로 없는거같고 정시 퇴근도 보장된다고 한다.
나에게 유지보수는 소스코드를 개선하고 시스템을 더 나은 방향으로 개선하고 악취를 제거하고 잠재적인 위험을 제거하는것... 이런 소명의식을 가졌다.
적어도 퇴사일을 잡기 전까지는 말이다.
레거시 시스템
이 오래된 시스템을 문제를 어디서부터 손을 대야할지 무엇을 해내야할지에 대한 고민이 생겼다.
프로젝트에 연관된 사업담당자, 프로젝트 관리자와 그외 다른 동료 개발자들과는 논의할수 없었다.
보수적인 집단에서는 '기존의 해오던 일이 아니면 하면 안되는일'로 취급하는 경향이 있다.
그리고 지금 당장 해야할일들이 너무나 많았다. 담당자는 끊임없이 날라오는 오류 메일에 응대해야했고
관리자는 담당자의 피드백을 처리해야 했다. 나른 포함한 동료개발자들은 어떻게든 해당 오류들을 빠른시간안에 처리해야했고, 엉성한 기반시설위에 또 다른 기능을 추가하는 일들을 했다. 다들 각자 위치에서 엉망이된 시스템에 대한 기술부채 이자를 열심히 갚아나가고있는 걸로 보였다. 그러나 아무도 이에대한 원인과 문제의식에 대해 생각하지 않는거같았다.
.
.
.
다음편에 계속
