들어가며
현재 SI업체로부터 탈출에 성공해서 프론트엔드 개발자로 일하고 있습니다. 지금부터 SI업체에서의 경험들과 어떤 계기로 탈출을 해야겠다는 결심이 생겼는지, 그리고 얼마나 노력을 해서 성공했는지에 관해 이야기를 해보려고 합니다.
하루는 24시간이고 일주일은 7일이죠
처음 개발을 공부할 때 가장 많이 들었던 조언은, SI 업체는 반드시 피하라는 말이었습니다. 하지만 교육 과정이 끝나고 본격적으로 구직활동을 시작하면서 현실을 깨닫게 되었습니다. 스타트업에 계속 이력서를 넣었지만, 면접을 볼 수 있는 기회조차 쉽게 주어지지 않았습니다. 결국 기약 없는 도전에 불안한 나머지 그렇게나 피하려던 SI업체에서 일을 시작하게 되었습니다.
1. 경력 뻥튀기
프로젝트 리더를 하라구요?
신입으로 파견을 나갔다고 생각했지만, 현실은 경력이 뻥튀기되어 중급개발자로 투입이 되었습니다. 심지어 한 프로젝트에서는 프로젝트 리더를 하라고 했었습니다. 나도 신입인데 다른 신입을 데리고 프로젝트 리더를 하라고? 게다가 한 달 반 동안 만들어야 하는 웹사이트는 5개 정도 였습니다. 일정에 맞춰서 서비스 오픈은 했지만, 그동안의 책임감과 부담감은 컸습니다.
2. 자비없는 일정산정
“워킹데이가 14일 이니까 2주 잡으면 되겠네요?”
엥? 뭐라고? 3주 아닌가요?
“토요일 일요일은 날이 아닌가요?”
경력이 뻥튀기 된 것도 억울한데 주말을 포함하는 일정 산정에 여긴 아니다라는 생각이 들기 시작했습니다. 개인 일정 때문에 일찍 퇴근했던 날은 “고생하셨습니다.” 보다는 “그럼 내일 밤새셔야겠네요?”라는 말을 더 많이 들었던 것 같습니다. 주말 출근과 잦은 밤샘으로 건강은 더 나빠졌고 개인 시간은 아예 없었습니다.
3. 돌아가기만 하는 코드
코드의 품질은 생각하지 말고 일단 돌아가게만 만들면 됩니다.
서비스 오픈 일정이 다가오면서 프로젝트팀은 초조해졌고 서로 예민한 상태가 되었습니다. 그때 저는 코드 한 줄 더 신경을 써서 개발을 하느라 시간이 좀 더 걸렸었습니다. 그걸 본 PM이 코드의 품질은 생각하지 말고 일단 돌아가게만 만드세요.라는 말씀을 하셨습니다. 그 말을 듣는 순간, 아 여긴 아니다. 무조건 탈출해야겠다라고 생각이 들었습니다.
처음에는 “왜 서비스가 돌아가기만 하면 되지? 코드 품질은 신경 안 써도 되나?”라는 의문이 생겼습니다. 하지만 곧 그 이유를 깨닫게 되었는데, 우리 팀은 서비스 오픈까지만 담당이었고 유지보수는 다른 팀이 투입될 예정이었기 때문입니다.
돌아보면, 2년 남짓한 기간에 설마? 하는 마음으로 SI 업체에서 일을했지만 대부분의 안 좋은 경험들 때문에 이곳을 탈출해야겠다고 생각했습니다.
피나는 노력으로 성공한 SI업체 탈출
1. 왜 Vue.js를 선택했나
SI업체에서 개발을 할 때 백엔드 개발보다는 화면을 만드는 프론트 개발이 더 재미있었습니다. 또 UI/UX에도 관심이 있어서 프론트엔드 개발을 선택했습니다.
공부하기 전에 프론트엔드 개발에서 사용하는 라이브러리 또는 프레임워크를 먼저 선택해야 합니다. 그 이유는 프론트엔드 개발자 공고를보면 Vue.js, React.js, Angular 셋 중의 하나가 주요 기술로 적혀있기 때문입니다.
그래서 저는 세 가지 기술 중에 Vue.js를 선택했는데, 그 이유는 다른 기술보다는 러닝커브가 낮다고 들었기 때문입니다. Angular는 typescript, rxjs를 알아야 할 시간이 더 필요했었습니다. 하지만 제게 주어진 시간은 얼마 없었고, 빠른 시간 안에 기술을 공부해서 SI업체를 탈출해야 했었습니다.
2. 어려웠던 개념들
공부하면서 제일 어려웠던 부분은 부모 자식 간의 데이터 통신 즉, 단방향 데이터 바인딩이었습니다. 부모는 자식한테 데이터를 전달할 수 있지만, 자식은 부모한테 데이터를 직접적으로 전달하면 안 된다. 저한텐 너무 어려운 개념이었습니다. 부모가 가지고 있는 데이터를 자식이 변경하거나 자식이 가지고 있는 데이터를 부모에게 보내고 싶은 경우 Vue.js에서는 사용자 지정 이벤트와 $emit을 사용합니다. React.js에서는 부모에서 직접 함수를 props로 받아서 직접 함수를 호출해야 합니다.
그다음 힘들었던 부분은 CSS이었습니다. SI업체에 있었을 때는 퍼블리셔가 퍼블리싱을 해서 준 파일들에는 이미 CSS가 작성되어 있었기 때문에 CSS를 직접 작성할 일이 없었습니다. 간단한 Todo앱을 만들었었는데 화면마다 CSS를 일일이 작성했습니다. 간단한 앱이었지만 중복되는 CSS 코드들이 너무 많았었습니다. 그때 옆에서 지켜보던 남편(프론트 개발자)이 의미있게 재사용 할 수 있는 단위로 쪼개라라고 알려줬습니다.
어떻게 컴포넌트를 의미있게 재사용 할 수 있는 단위로 쪼개지? 그럼 도대체 컴포넌트가 뭐야? 궁금증만 커졌습니다. 컴포넌트라는 개념을 알기 위해 남편과 같이 Todo앱 코드를 리팩토링했습니다. 한 화면에 동일한 input, button이 많았고 한 파일에서 다 작성을 했었습니다. 제일 먼저 리팩토링했던 코드는 중복된 button 코드들을 Button이라는 컴포넌트로 만들었습니다. button에서 사용되는 type, classname, button title, disable, click event 등을 props로 받았습니다. Button을 사용하는 부모 컴포넌트에서는 Button에 props로 내려주는 데이터, 이벤트를 관리했고, Button에서는 렌더링만 담당했습니다. 코드의 양은 많이 줄었으며, Button의 관심사가 분리되었습니다.
컴포넌트란 재사용 가능한 기능과 마크업을 가지고 화면을 그릴 수 있는 단위라고 설명할 수 있습니다.
예전에는 화면을 보면 하나의 페이지에 모든 내용이 다 담겨있다라고 생각하고 개발했다면, 지금은 각각의 컴포넌트들의 집합이라고 생각하고 개발합니다.
3. 처음 접해본 라이브러리들
처음 접해 본 라이브러리는 lodash였습니다. lodash란 자바스크립트 유틸리티 라이브러리로, 데이터를 쉽게 다룰 수 있도록 도와줍니다. 또, 자바스크립트에서 배열 안의 객체들의 값을 핸들링할 때 유용합니다.
지금은 여기저기서 유용하게 잘 사용하고 있지만, 기본적으로 많이 사용하던 map, reduce, filter를 이해하는데 어려웠습니다.
개념을 간단히 설명하자면, map이란 iteratee를 통해 컬렉션의 각 요소를 실행하여 새로운 배열을 리턴합니다. map의 기본 형태는 _.map(collection, [iteratee=_.identity])입니다.
reduce는 배열을 줄여나가는 방법이라고 할 수 있습니다. reduce 함수는 배열에 대하여 주어진 리듀서(reducer)함수를 실행하고 결과값을 반환합니다. reduce(콜백합수, 초기값)과 같은 형태를 가지고 있으며, 배열의 각 요소가 주어진 콜백 함수를 거치고 콜백 함수의 결과값이 다시 초기값으로 이어집니다. 이 콜백 함수를 리듀서(reducer)라고 합니다. reducer는 accumulator(누산기), currentValue(현재 값), currentIndex(현재 인덱스), array(원본 배열)의 네 개의 인자를 가집니다. 간단한 예제를 들어보겠습니다.
const arr = [1, 2]
arr.reduce((sum, number) => sum + number, 0) // 3
arr.reduce((sum, number) => sum + number, 3) // 6accmulator는 콜백 함수를 통한 결과값과, 그다음의 index에 있는 값을 받아서 배열의 순회가 끝날 때까지 실행합니다. 초기값이 0 일 때는 결과가 3이 나오고, 3일 때는 6이 나옵니다.
filter는 배열 내 각 요소에 대해 한 번 제공된 콜백 함수를 호출해 콜백함수가 true로 강제하는 값을 반환하는 모든 값이 있는 새로운 배열을 리턴합니다. 간단한 예제를 들어보겠습니다.
const arr = [1, 2, 3, 4, 5]
arr.filter = value => value < 3 // [1, 2]filter는 3 미만의 숫자만 골라내 새로운 배열로 리턴합니다.
처음에는 위 이미지만 보고 이해하기가 어려웠습니다. 이 개념들을 이해시키기 위해서 인프런에서 유인동님의 함수형 프로그래밍 강의를 들었습니다. 그리고 vue.js와 더 친해지기 위해서 vue.js2 Cookbook책을 보면 A to Z 까지 따라 해봤고, 장기효 강사님의 세미나도 열릴 때마다 가서 들었습니다.
4. 프론트엔드개발자로 지원
어느 정도 준비가 된 후에 이력서를 다시 작성했습니다. 기존 이력서는 자기소개서, 학력 정보, 자격증 정보, 경력정보로 작성했다면, 새로 작성한 이력서는 주로 내가 어떤 기술을 사용할 줄 아는지, 어떤 기술이 제일 관심 있는지에 대해서 더 어필했습니다.
몇 군데 프론트 개발자로 지원을 했고 면접을 봤지만 쉽지 않았습니다. 다행히 한 곳에서 면접에 합격하고 과제를 받았습니다. 그때 받았던 과제는 데이터 시각화하는 과제였습니다. 일주일 동안 과제를 열심히 했지만, 만족하지 못한 상태에서 제출했습니다. 다행히 과제 검토 후 입사제의 연락을 받았고 SI업체 탈출에 성공하게 되었습니다.
SI업계 탈출 후
1. 재미있는 우리 서비스
저는 주위에서 우리 서비스를 해야지 재미있다고 많이 들었습니다. 뭐가 재미있지? 개발하고 오픈하면 끝 아닌가? 라고만 생각했었습니다. SI업체는 주로 파견 나가서 일정 기간에 개발하고 철수합니다. 계약 기간에 개발이 마무리가 안 되면 오픈도 못 하고 철수하는 경우가 많습니다. 서비스에 새로운 기술을 적용하면서 유지보수하고, 사용자 분석도 하면서 재미를 느낀다는데 저는 그런 경험이 없어서 재미를 느껴보지 못했었던 것 같습니다.
하지만 그 재미는 SI업체를 탈출하고 나서부터 알게 되었습니다. SI업체를 탈출하고 우리 서비스를 개발하면서 바뀐 점은 서비스를 대하는 자세입니다. 우리 회사의 경우는 브레인스토밍을 다 같이 하면서 도메인 지식도 같이 스터디하고 공유합니다. 사용자가 우리 서비스를 관심을 갖고 사용하기 위해서 정말 사용자가 원하는 것이 무엇인지, 또 어떻게 매력 있는 서비스가 되어야 하는지를 고민합니다. 그리고 우리가 원하는 목표까지 사용자가 도달할 수 있도록 좋은 UX에 대해서 아이디어 회의를 자주 합니다.
그리고 우리 회사는 실험을 많이 합니다. 우리가 하고 싶은 서비스 중 기능을 작게 만들어서 빠르게 개발하고, 광고를 올려서 사용자 행동을 분석합니다. 데이터가 모이면 우리가 가고자 하는 방향이 잘 맞는지 또는 사용자 타게팅은 잘했는지 외에 대해서도 많은 분석을 할 수 있습니다. 모여진 데이터를 토대로 서비스를 개선하고 실험을 반복하면 더 많은 데이터가 모이게 되고, 그 데이터로 또 여러 가지 실험을 할 수 있습니다.
또, 저희 개발팀은 더 좋은 서비스를 만들기 위해 매일 1~2시간씩 스터디를 진행합니다. 프론트, 백엔드, 인프라 나뉘어 있지만 우리 서비스 기술에 대해서는 모두 다 알고 있어야 한다고 생각을 해서 서로 부족한 부분을 스터디합니다.
이제서야 서비스를 개발하면서 재미를 느끼고, 우리 서비스를 해야 재미있다라는 말을 실감하면서 개발을 하고 있습니다.
2. 코드를 잘 작성하기 위해
더이상 돌아가기만 하는 코드를 작성하지 않는다.
저는 이제 더이상 돌아가기만 하는 코드를 작성하지 않는다고 당당히 말 할 수 있습니다. SI업체에 잠깐 몸 담그던 시절에는 안 좋은 습관들이 많았습니다. Ctrl+C, Ctrl+V 만 주야장천 했었고 네이밍도 생각 안 하고 작성했었습니다. 중복되는 코드가 많아지는 건 말할 것도 없었고, 파일 하나에 코드가 몇천 줄이 되어도 신경도 안 썼습니다. 지금은 안 좋은 습관들은 버리고 좋은 습관을 만들기 위해 아래 내용처럼 열심히 노력하고 있습니다.
첫째, 네이밍에 대해서 고민을 많이 합니다. 다른 사람들이 코드를 봤을 때 네이밍만 봐도 어떤 역할을 하는 코드인지 바로 알아야 합니다.
둘째, 컴포넌트 설계에 대해서 고민을 많이 합니다. 데이터 구조와 흐름을 파악하는데도 명확하고 중복되는 코드를 줄일 수 있습니다.
셋째, 코드리뷰와 짝코딩을 합니다. 개발자들한테는 코드리뷰는 무조건 필요하다고 생각합니다. 놓치고 있던 부분과 잦은 실수를 바로 발견할 수 있습니다. 특히, 짝코딩이 제일 좋은점은 얘기를 하면서 개발하면 서로가 몰랐던 지식을 알게 되고, 코드가 더 나은 로직으로 작성될 수 있습니다.
넷째, 테스트코드를 작성합니다. 사람이 작성한 코드는 항상 버그가 발생할 수 있기 때문에 테스트코드를 작성해서 버그를 줄여야 합니다. 코드를 유지보수 할 때도 테스트코드를 먼저 보게 되면 코드가 하는 역할을 더 명확히 알 수 있습니다.
3. 좋은 문화, 좋은 동료
최고의 복지는 최고의 동료다. 아마 이 부분은 남편이 준 영향이 제일 클 것 같습니다. 저는 회사 분위기와 동료들에 의해서 어떤 영향을 받는지 잘 몰랐습니다. 하지만 남편과 그 주위 동료들을 보고 너무 다른 환경에서 일하고 있는걸 깨달았습니다. 서로의 성장을 위해 도와주고 새로운 기술과 더 나은 서비스를 만들기 위해서 끊임없이 고민과 토론을 하고 있었습니다.
SI업체 탈출하고 좋은 문화와 동료를 얻었다고 생각했지만 처음 이직한 회사에서는 회사 사정상 퇴직을 하게 되었고, 두 번째 회사로 이직했습니다. 우여곡절 끝에 이직을 했지만 제가 바라는 문화는 아니었습니다. 먼저 일을 할 때 같이 고민할 동료가 없었습니다. 처음에는 혼자서 어떻게든 하면 되겠지? 라는 생각으로 일을 했습니다. 서비스 몇 개 런칭한 후에 시니어 개발자가 뽑히면 같이 좀 더 나은 서비스를 만들고, 서로 성장하는 데 도움이 될 거라고 생각했었습니다.
하지만, 현실은 녹록하지 않았습니다. 시니어 개발자는 뽑히지 않았고 심지어 신입 개발자도 뽑히지 않는 상황이었습니다. 혼자서 많은 것을 담당하기엔 부담감이 너무 컸고, 뭔가 더 발전하고 있다는 느낌도 들지 않아서 다시 이직을 하게 되었습니다.
우연히 지인의 소개로 지금 회사에 입사했는데, 좋은 문화에서 좋은 동료들과 일한다는 기분이 이런 것이 아닐까 싶습니다. 지금 회사는 서로의 성장을 책임져 주기 위해서 많은 노력을 하고 있습니다. 그리고 제일 하고 싶었던 짝코딩, 코드리뷰, 스터디를 하고 있고 기술적 고민을 같이 얘기합니다. 우리 팀은 항상 서비스가 더 잘 되기 위해, 팀원들이 성장하기 위해 계속 노력하고 있습니다.
마치며
돌이켜보면 개발자 5년 차에 많은 일을 겪었던 것 같습니다. SI업체에서 개발자 시작 > SI업체 탈출 > 프론트엔드 개발자로 시작 > 무급휴직 > 다시 이직 활동 > 동료 없는 회사에서 고군분투 > 또다시 이직 활동 > 좋은 동료와 좋은 문화를 찾은 지금의 회사.
개발자로 일하면서 제일 잘했다고 생각하는 점은 SI업체탈출이고, 시간이 오래 걸렸지만 스스로 성장에 대한 욕심이 생기면서 이제야 하나씩 해나가는 것 같습니다. 제일 부족했던 부분이 꾸준한 학습이었는데, 이 부분은 아직도 고민 중이고 방법을 찾는 중이지만 지금은 강제성을 두고 여기저기 스터디에 참여하고 있습니다. 하다 보면 좋은 습관이 생기고 저한테 맞는 좋은 방법이 만들어질 거라 생각이 듭니다.
앞으로도 꾸준히 성장하고 주변 동료들한테도 좋은 영향을 줄 수 있는 개발자가 되기 위해 노력할 겁니다.