7 posts tagged with "직업"

회사에서 동료들과 이야기하던 중 우리 회사도 redux를 도입해야 하는 거 아니냐는 말을 들었습니다. 그렇습니다. 사실 redux를 도입하던 global state 관리할 만한 뭔가를 진작 도입했어야 했습니다. 우리는 왜 여태 컴포넌트 간의 props 를 넘겨가며 코드를 계속 복잡하게 만들고 있어야 했나...

배경​

사실 시작은 이렇다. 처음 개발한 개발자 분이 react 기본 router, state 관리 방식까지 모두 자기만의 스타일로 만들어 그 패턴으로 개발했습니다. 황당했지만 굴러드러온 돌이고 바빴기 때문에 이를 고칠 시간적 여유도 없었습니다.

그렇게 시간이 흘러 여러 차례 마이그레이션, 신규 런칭 과정을 거쳤지만 이번에도 같은 실수를 반복하며 제대로 개선되지 못하고 본인만의 패턴들을 꽉 체워 두었습니다. 결국 모두가 새로 나가고 한번 더 새로운 사람들로 체워지면서 현재의 새로운 프론트엔드, 앱 개발자들은 이 상황을 맞닥뜨려야 했습니다.

바쁜 일상​

프론트엔드, 앱, 서비스 백엔드 개발자 분들은 계속된 요구사항과 유지보수 개발에 지쳐있었습니다. 문제를 이야기한지 시간이 많이 지났지만 그 누구도 기술적 검토나 토론을 이어가지 않았습니다.

그래서 자의로 스터디도 할 겸, 사내 문서도 만들 겸, 테스트해 react의 global state 관리 방식에 대해 조사해보기로 했습니다.

위의 링크에 있는 비교 분석을 참고해 실제 적용하며 테스트했고 recoil 로 적용하자고 결론에 다다랐습니다.

이번 회사에서는 면접 자리에서 연봉협상을 통해 헨드헌터와 이야기 했던 연봉 보다 낮춰진 체로 입사하게 되어 떨떠름 했지만 그래도 기존 연봉보다는 20% 넘게 올렸기 때문에 그걸 위안 삼기로 했습니다.

2019년 10월부터 2022년 9월까지 거의 3년을 근무한 회사의 경험입니다.

입사일​

처음 출근 하기 전 영어 이름을 정해야 했습니다. 이번에도 이전에 정한 익숙한 이름 알렉스로 정했습니다.

출근해 보니 정해져 있는 자리가 있었습니다. 그리고 OT가 시작됐다. OT는 다른 스타트업과 비교해 독특하게 개발과 상관없는 모든 부서의 장들이 직접 부서 업무에 대해 소개해줬습니다. (알고 보니 개발과 굉장히 밀접한 부서들이었습니다.)

OT를 거치면서 부서장 분들이 직급과 상관없이 서로 편하게 말할 수 있는 분위기인 것을 강조해 좋은 인상을 받았습니다.

내가 속해 있던 개발팀은 CTO인 브라이언과 내 또래의 프론트엔드 개발자 휴버트가 있었고 샘이라는 개발자는 신사업팀으로 따로 팀이 있는 상황이었습니다. 개발자가 3명인데다가 말도 잘 통해 보이고 나이대도 비슷해 든든했습니다.

자기 일만 제대로 한다면 쉬는 시간도 자유롭고 영어이름을 쓰며 높은 직급에도 격의없이 서비스에 대해 논의하고 개발자에 대해 존중해주는 수평적인 분위기가 보였고 회사에 대한 기대가 생기는 첫 날이었습니다.

회사의 과거 이야기​

OT가 끝나고 휴버트는 프론트엔드 소스를 공유했습니다. 본인이 맡고 있는 프론트엔드부터 같이 해보자고 해서 본격적인 업무를 시작하게 됩니다. 소스를 보니 typescript, react로 구성된 웹이었고 회사의 앱은 react-native에 웹뷰를 띄워 거의 모든 동작은 웹뷰에서 이뤄지게 만들어져 있었습니다.

react-native 소스도 받았지만 수정을 안 한지가 거의 6개월이 지난 상태였습니다. 그리고 react-native로 앱 스토어에 배포한 경험이 있는 사람도 회사에 없었습니다. 알고 보니 내가 들어오기 1달 전 제이드라는 개발자가 앱을 맡고 있다가 인수인계 없이 퇴사를 했다고 합니다.

점심 식사를 하면서 회사의 과거 이야기를 듣게 됐습니다. 사실 회사에는 개발자 숫자가 거의 15명이 될 정도로 개발인원이 많았었는데 투자 유치 및 개발 산출물의 반응이 좋지 않아 적자에 허덕였고 그 때 퇴사 권유를 받아 대부분 퇴사하게 되고 개발자 샘과 보험 데이터 기획자 에릭이 남게 되었다고 합니다.

그렇게 남게 된 샘은 조금씩 작은 개발 관련 일처리를 하다가 회사에 투자 유치가 되서 에릭과 함께 보닥이라는 서비스를 만들기로 했고 그 서비스를 만들기 위해 개발자들을 채용하게 됐습니다. 그 때 뽑은 인원이 휴버트와 제이드였고 휴버트는 프론트엔드, 제이드는 앱 및 서버 구성, 샘은 백엔드를 담당해 훌륭한 합을 보여줬다고 합니다.

에릭과 개발팀들은 열심히 목적을 향해 나갔고 앱을 출시하고 유지보수하며 잘 운영해 회사의 캐시카우가 되었습니다. 그런데 앱이 성공적으로 출시되고 회사가 안정된 돈이 들어오게 되면서 다른 투자들을 더 받기 위해 새로운 시도들이 계속 요구됐는데 이 과정에서 샘과 경영진 간 마찰이 많았다고 합니다.

샘은 개발자 입장, 경영진은 투자를 받기 위한 입장이기 때문에 마찰이 있을 수 있었지만 경영진이 샘을 컨트롤하기 힘들어졌다 생각해 추후 더 큰 개발팀이 되면 뽑으려 했던 CTO를 급하게 고용했다고 합니다. CTO는 나를 면접 봤던 브라이언이었고 브라이언은 경영진이 원하는 바를 빠르게 도입할 수 있는 체계를 만들기 위해 현재 개발된 내용들을 모두 단순화하기 위해 다 갈아치울 거라고 말했습니다.

브라이언은 처음에 앱의 규모만 보고 혼자 모두 새로 만들어도 2~3개월이면 될 듯이 말했고 경영진은 이것을 믿어주고 힘을 실어줬습니다. 하지만 샘은 이런 브라이언의 태도를 가만 볼 수 없었고 브라이언의 원하는 바를 해주지 않았고 여전히 강경한 입장을 고수하고 있었습니다. 그렇게 샘과 틀어진 브라이언은 남은 2명과 샘을 이간질하고 샘을 팀에서 추방해 샘과의 대화를 통제하기 시작했습니다.

하지만 3명은 이미 개발 합을 맞추며 깊은 관계였고 이 모든 것은 3명 모두의 반감을 사게 됩니다. 브라이언은 애초에 CTO로 입사할 때부터 실무를 하려 한 게 아니었기 때문에 개발자들의 도움이 필요했는데 그나마 말을 좀 들어주던 제이드와 휴버트에게 일을 시켰지만 브라이언이 급하게 설계한 데이터베이스와 백엔드는 아주 많이 수정이 필요했고 이에 2명 또한 지쳐갔습니다.

브라이언은 3명 모두의 신임을 잃었기 때문에 경영진에게는 3명이 돕지 않아 문제가 된다며 그들 탓을 계속 반복 했지만 일정 압박을 받았고, 이 때부터 회사에서 자유롭게 사용하던 개발자들의 연차까지 반려시키기 시작했습니다. 이로 인해 제이드는 사적으로 안 좋은 상황에 처하게 됐고 그로 인해 바로 퇴사하게 됐다고 들었습니다.

그래서 회사에서 사용중인 서비스들의 계정 관련 정보들, 배포 프로세스, 앱 배포 등을 아는 사람이 없는 상황이었습니다. 생각보다 심각한 상황이었습니다. 배포체계에 갑자기 문제가 생긴 상태에서 급하게 서비스에 이슈가 생긴다면 그걸 고치기 위해 전체 프로세스를 새로 만들어야 할 수도 있었습니다.

브라이언은 저와 샘과의 대화를 지속적으로 막았습니다. 브라이언 때문에 신사업팀으로 배정돼 업무에서 배제된 샘이 사실은 회사의 모든 백엔드 내용을 알고 있는데 대화를 할 수도 없고 불편하고 난감한 상황이었습니다.

퇴사 레이스​

입사했을 때부터 샘은 퇴사 일정이 잡혀 있었습니다. 업무를 배제시키고 경영진 또한 CTO에게 힘을 실어주고 있으니 샘도 회사에 있을 이유가 없어 보였습니다. 하지만 샘에게 배우고 싶어 회사에 남아있었던 휴버트는 샘이 나가면 나가겠다고 했습니다. (샘은 개발 능력이 아주 뛰어난 개발자였습니다.)

CTO는 해내겠다고 한 일정보다 6개월이 더 걸려서도 일을 해내지 못했고 게다가 모든 팀원들이 퇴사 의지를 밝혀 찰스에 의해 결국 강제 퇴사를 당하게 됐습니다. CTO가 퇴사 당했지만 회사에 질려버린 샘도 거의 비슷한 시일에 일정대로 퇴사했고 휴버트는 간단하게 웹뷰에 대한 배포 방법을 알려준 뒤 샘의 소개로 다른 회사에 추천되어 이직을 성공하게 됩니다.

퇴사하기 전 샘과 휴버트는 경영진에게도 많은 상황 어필들을 했으나 모든 것들이 소용이 없었다고 생각해 회사에 실망을 한 상태였기 때문에 마음을 돌리 수도 없었습니다. 그렇게 결국 다시 개발팀에 혼자 남게 됐는데 그래도 에릭이 이전 개발에 대한 히스토리를 알고 있어 옆에서 많은 도움을 줬고 유지보수에 많은 도움이 됐습니다.

유지보수​

프론트엔드​

react, typescript로 구성된 서비스는 대부분 웹뷰를 통해 독특하게 구성되어 있었습니다. 프론트엔드에서 api를 사용하기 위해서는 백엔드 개발 시 같이 배포하는 api용 타입 라이브러리를 npm에 배포하고 이것을 프론트엔드에서 업그레이드해 사용하는 패턴을 취하고 있어 양 쪽의 오류를 덜 수도 있었지만 혼자 있는 상황에서 많은 일을 빠르게 개발할 때 불편한 족쇄 중 하나였습니다.

게다가 소스를 보면 react-router, redux, react 기본 기능인 state 관리, UI컴포넌트 등을 모두 JS로 직접 만들어 사용했는데 설정 방식도, 기능도, 성능도 모두 좋지 않았습니다. 하지만 혼자 남은 상황에서 패턴을 모두 변경하고 새로 개발하기엔 버거웠기 때문에 패턴에 맞춰 개발했습니다. 독립적으로 변경할 수 있는 부분들만 다른 개발자들도 좀 더 익숙한 형태로 변경해 나갔습니다.

앱​

react-native, typescript로 구성된 앱은 앱에서 구동되는 광고용, 비지니스용 트랙킹 라이브러리들, 딥링크들을 사용하기 위해 구성되어 있고 앱의 가장 주요 기능 중 하나인 신정원 회원가입, 로그인, 스크랩핑을 위해 필요했습니다.

나머지는 웹뷰에서 구현되어 있기 때문에 사실 앱 UI는 아무것도 없는 빈 껍떼기에 불과한 상황이었습니다. 하지만 이 시점부터 react-native는 빠르게 업그레이드 되고 앱스토어, 플레이스토어의 정책 변경과 웹뷰가 많은 앱에 대한 심사가 까다로워지는 등 이슈들은 계속 생겨났습니다.

앱에 익숙하지 않고 스토어에 배포까지 해 본 적은 없어서 좀 더 앱에 익숙해지기 위해 열공하고 이슈도 해결해 나갔습니다. 직접 토이 프로젝트 앱도 스토어에 배포해 보고 테스트도 하면서 조금씩 앱에 대해 익숙해져 갔습니다.

메인 Api​

메인 Api는 모두가 퇴사하고 나서 유지보수를 하면서 처음 보게 됐습니다. 회사의 모든 언어 스택이 typescript로 알고 있었는데 사실은 아니었습니다. 깃허브를 열심히 뒤져보며 찾게 된 실 구동중인 소스는 php laravel로 구성된 백엔드였습니다.

php는 아예 처음 들어본 상황인데, 유지보수는 급했고 소스를 열심히 읽어가며 무작정 Larabel의 패턴을 익혀 패턴에 맞춰 개발했습니다. 배포 방법은 에릭에게 질문하고 readme에 적힌 내용을 토대로 테스트하며 결국 배포할 수 있게 됐습니다.

php로 로컬 환경을 구성하는 법도 모르던 상황에서 빠르게 유지보수를 해야 했기 때문에 당시에는 빨리 고치고 테스트 환경에 배포해 테스트 앱에서 확인한 후 실 서비스에 바로 반영 했습니다. 지금 생각해 보면 얼마나 불편하고 무서운 행동이었는지, 당시에 고객이 많지 않아 실수했을 때 얼마나 다행이었는지 모릅니다.

엔진​

메인 Api는 개발 문서에 적힌 ERD상에 있는 데이터베이스에 있는 내용들을 가져와 보여주거나 상담신청에 대한 플래너 배정 정도를 담당하고 있었습니다.

사실 이 앱의 핵심은 엔진에 있었는데 엔진은 typescript, expressjs로 구성됐습니다. 앱, 웹, 엔진에 공통적으로 보이는 데이터 구조를 만들거나 다루는데 사용하는 라이브러리가 보였습니다. 알고 보니 퇴사한 샘의 개인 npm repository에 있는 라이브러리였습니다.

샘의 개발 구성 방식은 MS사에서 개발하는 방식을 따랐다고 하고 C++ 개발자 출신이라 전형적인 Typscript 개발과 다르게 굉장히 체계적이고 작은 기능에도 규모가 컸습니다. 사용 방법이나 코멘트들도 적혀 있지 않아 아주 많은 것을 상속 받으며 정의되어 있는 기능들이 어떤 기능인지를 찾는데 많은 고생이 필요했습니다.

샘의 개인 라이브러리드들은 모든 소스에서 속속들이 사용하고 있어서 걷어내려면 마치 앱을 새로 만드는 듯한 정성이 필요했습니다.

엔진은 보험 데이터를 통해 도출된 머신러닝 데이터와 고객의 보험 데이터 간의 수식을 통해 점수를 산출하는 진단과 수 많은 보험 데이터들 간 조합 알고리즘을 통해 도출되는 최적의 보험 상품 조합을 도출하는 추천 기능을 가지고 있었습니다.

앱의 가장 중요한 기능 2가지를 담고 있는 회사의 코어 자산이었습니다. 엔진 소스는 백엔드랑은 비교도 안되게 복잡하게 구성되어 있었고 엔진 기능 관련 api를 제공하는 서버와 코어 기능이 담긴 라이브러리, 그리고 보험 데이터를 조작하고 관리하는 펙토리 기능 이렇게 3가지 소스가 나눠져 있었는데 제대로 이해하기까지 3개월 정도 시간을 쏟았던 기억이 납니다.

클라우드​

클라우드 구성은 AWS에 2계정으로 관리되고 있었습니다. 첫 번째 계정은 메인 api와 웹뷰, 데이터베이스 서버 등이 구성되어 있었고 두 번째 계정은 엔진이 구성되어 있었습니다. 구성된 상태는 ELB에 ACM을 연결해 ssl을 연결했고 EC2들이 ELB에 연결되어 있었습니다.

EC2에서 서버는 http로 동작해도 ELB에 연결되기 때문에 따로 https 설정을 할 필요는 없었습니다. 도메인은 이미 구매되어 있어서 route53 서비스를 통해 연결되어 있었습니다.

AWS의 서버구성 방식은 간단히 구성되어 있었고 걱정했던 것보다 조작하거나 구성하기 쉬웠습니다. 엔진의 경우 Api를 통해 업데이트하도록 설계되어 특정 패스로 api 요청하면 워커들을 하나씩 업데이트 해가며 코드 레벨에서 blue-green(무중단 배포)이 실행됐습니다. 덕분에 배포 시 편하게 api 요청만 하면 끝이었습니다.

하지만 메인 api와 웹뷰의 배포 방법은 굉장히 불편했습니다. 프론트엔드 소스의 개발을 마무리 한 후 라이브러리로 빌드해 npm에 배포한 뒤 이를 Laravel 백엔드에서 설치해 폴더별로 path를 지정하여 웹에 포팅했습니다.

그렇게 백엔드 소스와 한 몸으로 만든 뒤 사설 깃랩 서버에 올리고 깃랩 내에 설정해둔 대로 로컬에서 명령을 날리면 vagrant와 virtualbox가 실행되면서 이미지를 만들고 이 이미지를 운영중인 서버로 설치해 배포되게 됩니다. 과정을 알아내는 것도 힘든 과정이었지만 오류도 잦았고 해결을 위해 많은 시간을 소비했던 기억이 납니다.

지금 생각해 보면 Docker와 ECR을 활용했다면 보다 빠르고 효율적으로 관리하면서 고생을 덜 수 있었을텐데 그 때의 나에게 돌아가 알려주고 싶습니다.

문서 작성​

회사에 개발자로서 혼자 남아 있는 상태에서 경영진은 개발 산출물들에 대한 정보를 지속적으로 나에게 요구하고 있었습니다. 이미 퇴사한 개발자들이 정상적으로 뒀는지 염려가 많이 됐던 모양입니다.

개발 소스들과 많은 서비스 계정들, erd, 클라우드 구성 등이 대부분 문서로 되어 있지 않았고 제대로 되어 있지 않은 것들이 많았습니다. 이전에 남겨놓은 문서들은 대부분 경영진에게 그럴싸하게 보이기 위해 브라이언이 만들었던 as is, to be 문서 였고 심지어 틀린 내용도 수두룩했습니다.

유지보수를 하기에도 어차피 한번 정리가 필요했기 때문에 이왕 정리하는 김에 제대로 해서 다음 개발자들도 적응하기 좋도록 체계적으로 정리하고 싶어졌습니다. erd 구성부터 백엔드로직, api 문서 등 개발에 대한 정리를 시작했고 문서화해 나갔습니다. 소스와 구성들을 보면서 사용 중인 계정들을 더 알게 되고 사용 중인 계정과 패스워드들을 문서에 작성해 경영진들과 에릭에게 공유했습니다.

그리고 찰스가 이해하기 좋도록 클라우드 구성, 서비스 플로우, 배포 프로세스 등을 도식화 해 설명했고 이를 활용해 경영진들에게 현재의 산출물들의 체계를 제대로 알릴 수 있었습니다.

이후로도 정리하는 습관이 생겨 이슈 사항에 대한 리포트하는 법부터 설계 시작 단계부터 마무리까지의 과정들까지 정리했습니다. 이 정리들은 추후에 많은 공통 이슈들을 해결할 때 자주 찾아보며 사용하게 됐습니다.

신규 프로젝트​

1년 치 요구사항​

기존에 있던 개발자들과 CTO 간의 다툼으로 경영진들과 마켓팅 부서에서는 하고 싶은 일들이 넘쳐났지만 진행하지 못했던 수 많은 일들을 진행하고 싶어했습니다. 작은 일들은 유지보수를 하며 조금씩 요구사항들에 맞게 수정했지만 추가 기능들에 대해 요구가 계속 많아졌고 결국 프로젝트가 되어 돌아왔습니다.

그렇게 버겁게 유지보수를 하면서 프로젝트들을 시작하게 됐습니다. 회사는 기본적으로 인슈어테크 회사이고 결국 목적은 상담을 많이 유도해서 고객 계약을 따내는 것인데, 설계사분들은 모두 자영업이고 회사가 아닌 개인적으로 아는 고객들이 많았는데 이들의 상담과 계약 건도 앱과 연동해 진행하길 원했습니다.

그렇게 플래너분들의 개인 고객들을 연결해 플래너 개인 고객들에 대한 기능을 넣어주기 위한 앱 내, 관리자 앱의 기능을 추가해 주는 것이 필요했습니다.

또 필요한 기능으로 청구 기능이 있었는데, 당시에 청구는 실손 관련 간편 청구만 구현 가능했고 대부분의 인슈어 테크앱에서 이미 구현해 놓은 기능이었습니다. 우리도 기본적인 청구 기능을 구현하겠지만 늦게 출시하는 만큼 다른 앱들과는 다른 포인트가 필요했습니다.

연구 끝에 청구하려는 내용에 해당하는 청구 관련 분쟁조정사례를 보여 주고 청구 시 참조할 수 있도록 해주는 간편한 청구에 심화적인 내용을 정보로 주어 조금 어려운 청구 기능의 경우 플래너들이 직접 청구를 돕거나 이것을 기회로 보험 상담을 진행할 수 있게 하는 기능이었습니다.

에릭과 함께 기획이 끝났고 앱과 웹, 백엔드에 적용해야 할 아이템들을 검토해 기간을 산출했고 이를 통해 계획을 세워 프로젝트의 가닥이 잡혔습니다.

이 외에도 앱 내 게시판, 공지 기능 추가와 에디터 적용 등 많은 기능 추가들이 있었지만 회사의 개발자는 혼자였기 때문에 업무 배정, 협의에 대한 시간 소요 없이 빠르게 처리할 수 있어 모든 일들이 빠르게 테스트까지 마무리 되고 앱 심사까지 성공적으로 런칭할 수 있었습니다.

신규 엔진 개발​

회사에서 가장 중요한 코어 기능을 엔진 서버에 구현해 뒀는데 핵심 기능으로 보험 진단과 추천이 있었습니다. 하지만 기존에 만들어 놓은 엔진은 백엔드와 너무 의존적인 관계여서 독립적으로 서비스할 수 없었습니다.

불필요한 동작, 재동작들이 너무 많아 성능이 좋지 않았고 이로 인해 보험 진단 한번에 1분이 넘는 시간이 걸릴 때도 있었습니다. 심지어 ERD를 공유하면 복잡한 DB 구조로 인해 신규 인력들이 적응하는데 이것이 허들이 될 정도였습니다. 게다가 구조 상 모두 엮여 동작해 엔진을 조금 수정하면 서비스 전체에 영향을 끼칠 정도였습니다.

여러 불만들이 취합되어 결국 새로운 엔진을 만들게 결정이 됩니다. 보험에 대해 잘 알지 못했던 당시에 나는 보험을 진단하는 과정에 대해 온전히 이해하지 않고 코드상으로만 이해하고 있었습니다. 다행히 동료 중 에릭이라는 보험 설계사 출신 데이터 기획자 분이 있어 같이 엔진을 설계해 나갈 수 있었습니다.

우선 서비스에서 쌓여 있던 수 많은 진단 정보와 신용정보원 데이터 등을 취합했고 그 데이터들을 가공해 데이터 포맷과 피쳐들을 일원화했습니다. 데이터를 분석하면서 플래너들, 에릭과 상의해 보험의 여러 특성들을 도출했고 이를 통해 5가지 특성을 이용해 점수화하자는 기획이 섰습니다. 수동과 자동을 섞어가며 플래너 분들과 함께 데이터를 라벨링하기 시작했습니다.

라벨링 된 데이터를 통해 머신러닝 모델을 만들고 계속된 검증과 성능을 높이기 위한 작업을 진행했습니다. 결국 정확도 높고 원하는 결과를 도출하는 모델을 만들어 낼 수 있었습니다. 그렇게 엔진 코어 기능 중 하나인 진단 기능을 완성했고 그 외 추가적인 요구사항들인 관련 집계 기능, 차트 데이터 등을 완성해 가며 보험 진단을 마무리 했습니다.

보험 추천은 보험의 여러 특성들을 토대로 최적의 보험 패캐지를 찾아내는데 집중했습니다. 현재 판매중인 보험사들의 상품 정보를 모아서 그 데이터를 통해 고객인 원하는 보장 및 보장금액을 가진 최저가의 보험 패키지를 만들기 위해 bin packing 등의 알고리즘을 도입해 일반적인 방식으로는 감당할 수 없는 경우의 수를 쪼개 프로그램으로 감당할 수 있게 만들었습니다.

그렇게 보험 상품의 조합으로 고객의 요구 사항에 맞는 보험 패키지를 최저가로 찾아주는 보험 추천 기능을 완성했고 그 외에 원하는 보험사로 추천을 받는 기능, 신뢰도 있는 보험사로 추천받는 기능 등의 커스텀 동작들을 붙여 또 하나의 코어 기능을 완성했습니다.

보험 진단과 추천은 기존 성능 대비 40배 가량 성능이 빨라졌고 백엔드와의 의존성이 제거되어 독립 동작할 수 있어 나중에 BtoB 서비스로 보험 솔루션 SaaS의 개발 기반이 됩니다.

Bussiness To Bussiness​

앱이 성장하고 회사가 더 조금씩 알려지면서 보험 진단, 보험 추천 등의 기능을 인슈어 테크 회사들이 도입하고 싶어했습니다. 보험사들과 도입을 위한 회의를 진행하고 보험사에 맞는 내부망 서버 구성과 엔진의 커스터마이징 등 많은 부분을 협의해 나갔습니다.

처음 도입한 보험사는 보안을 이유로 내부망에 설치해 운영하고 싶어했습니다. 나중에 실제 이유는 서비스가 내부에 설치되어 있으면 이를 분석해 보험사 내에 자산화하고 싶은 이유였던 것을 알게 됐습니다. 그래서 그런지 유지보수 계약도 하지 않았습니다.

하지만 설치형 엔진은 기술 유출을 막기 위해 난독화, 암호화를 이중으로 하고 이것을 바이너리 파일로 제공했기 때문에 보험사에서 코드를 하나도 확인할 수 없어 결국 자산화는 실패하고 보인들의 입맛으로 커스터마이징하는 것도 할 수 없어 결국 유지보수 계약도 하게 됩니다.

시간이 많이 흐른 뒤에는 신용정보원 개편이나 여러 보험적 이슈들에 대해 직접 가서 설치해야 하기 때문에 빠른 대응을 할 수 없었기에 SaaS 형태의 엔진으로 계약을 변경해 건당 사용 요금을 받는 방식으로 변경해 사용하게 됩니다.

첫 도입한 회사에서 정상적으로 엔진이 운영되면서 타 회사들에도 신뢰가 생겼는지 여러 보험사들과 협의를 거쳐 진행했고 한번에 3개의 보험사와 계약을 하는 등 빠르게 발전해 갔습니다. 각 보험사들마다 요구사항에 맞는 새로운 서비스들(약관 조회서비스, 약관 분석 서비스 등...)을 요청해 요청한 내용들도 바로 개발해 제공했고 그렇게 BtoB 아이템들을 늘려나갈 수 있었습니다.

마이데이터​

어느 날 국가에서 데이터를 개방한다는 발표가 있었고 마이데이터를 통해 기존의 신용정보원 크롤링 데이터를 좀 더 체계화 된 데이터로 받을 수 있는 기대감이 생겼습니다. 얼마 안 지나서 경영진은 마이데이터를 해야 인슈어 테크 회사로서 살아남을 수 있다고 이건 숙명적 과정이라는 결론을 내렸습니다.

마이데이터에 통과되기 위해 공기업 격인 코스콤 클라우드로의 클라우드 구성 이전과 여러 보안 사항들, 그리고 옮기는 김에 하자고 하는 것들이 많아졌습니다.

당시에는 개발자가 3명이었는데 1명은 입사한지 1개월이 됐고 프론트엔드 개발자였는데 html, css만 다둘 줄 아는 분이어서 react를 공부하고 있었고 진행 인원에서 제외되게 됩니다. 1명 더 있던 CTO와 일을 진행하게 됩니다.

CTO는 프론트엔드 개발자였고 node 외에 언어를 다뤄 본적이 없었습니다. 그래서 당시 백엔드 소스만 php로 되어 있는 것을 눈에 가시로 여겼기 때문에 이것을 typescript로 변경하자고 제안했습니다. (CTO는 입사 후 3개월 동안 ERD도 개발 문서도 그 어떤 것도 제대로 보지 않고 원 페이지 웹싸이트를 새로 개발하며 자랑을 하던 분이었습니다.)

달갑지는 않았습니다. CTO는 현재의 구성을 전혀 고려하지도 않고 단순히 기술 스택만 이야기하며 이걸로 바꾸자가 전부였기 때문입니다. 심지어 백엔드만 변경하기로 했는데 추가 기능, 성능 향상이 있는 것도 아니고 언어만 바꿀 이유가 있나 싶었습니다.

하지만 CTO가 경영진과의 소통 참구를 본인을 통해서만 하도록 막았기 때문에 경영진을 설득해 본인이 원하는 스택으로 내가 개발해 줘야 하는 마이그레이션이 시작됐습니다.

서버의 코드들을 꼼꼼히 읽어 나가면서 기능들 간의 연결 관계와 의미들을 파악하고 필요한 기능을 구현하기 위한 서비스들과 앱과 웹에서 사용할 api 로직들을 설계할 수 있었습니다.

새로 구현된 api들과 프론트엔드, 앱 간에 연결을 한번 더 검토하고 효율적인 방향을 모색해 프론트엔드/앱과 백엔드를 양방향으로 수정해 나갔습니다. 그렇게 개발 소스를 수정하는 동안 CTO는 클라우드 구성을 했었는데 마이그레이션 개발과 DB 마이그레이션이 2개월만에 완료 됐지만 4개월 동안 클라우드 구성만 했고 2개월 간은 클라우드 구성 마저 지원해야 했습니다.

마이데이터 보안 구성을 위한 회의에서 CTO는 자신이 보안이 아주 높은 중국계 코인 회사에서 일 했었다며 자신의 의견을 계속 관철하고 구성을 주도 했는데 CTO의 말대로 구성을 완료하고 마이데이터 심사에서 여러 번 떨어지면서 실제 마이데이터 사업자를 취득하는데 기간만으로만 1년 정도 걸렸습니다.

마이그레이션​

마이데이터를 위해 코스콤으로 망을 이동이 끝나자 앱의 UI를 개선을 진행하자는 의견이 점점 커져 갔습니다. 이에 CTO는 앱 소스만 변경하지 말고 이참에 기존 레거시들을 모두 버리고 새로 만들기를 원했습니다.

이미 코스콤을 위해 마이그레이션 비슷한 경험을 해 봤기 때문에 마이그레이션 하기 위해서 해야 할 것들을 리스팅했습니다. 우선 기존의 ERD구성과 각 api 별 로직들과 영향관계들을 파악하고 프론트엔드에서의 데이터 흐름을 우선적으로 파악한 뒤 신규 ERD 구성과 api 로직들을 설계하고 웹, 앱에서 어떻게 보여줄지에 따라 backend를 수정 개발하는 것이 필요하다고 제안했습니다.

하지만 CTO는 기존 레거시를 6개월 동안 보지 않았기 때문에 레거시와 상관없이 db 마이그레이션 계획도 없이 기획자분과 함께 새로운 앱을 구성하기로 마음 먹고 그렇게 그냥 시작이 됐습니다.

더 많은 설득을 하고 싶었지만 당시 신규 엔진을 연구하며 개발하고 있었기 때문에 여유도 없고 계속 말해도 듣지를 않으니 관여하기가 참 난감한 상황이었습니다. 3개월 뒤 서비스 개발의 진도는 프론트엔드, 앱만 완료되어 가고 있었고 데이터베이스와 백엔드는 기획도 설계도 되어 있지 않았다.

그렇게 무계획으로 시작된 프로젝트는 3개월이라는 CTO의 근자감 일정 안에 끝나지 않았고, CTO의 주도 하에 개발자 3명이 같이 붙어 강행된 개발이 언제 끝날지 모르는 상황이었습니다. 그런 가운데 투자자들에게 신규 앱 런칭을 3개월 뒤로 공표한 비지니스 담당자들은 난감함에 점점 개발쪽에 압박이 높아져 갔습니다.

엔진 개발을 맡고 있던 저는 일정을 맞췄지만 플랫폼 개발 쪽은 점점 시간이 지체되어 갔습니다. 도와주며 빠르게 진행하고 싶었지만 CTO가 코드를 볼 수 있는 권한을 각 부서별로 막았기 때문에 엔진 개발하는 사람은 엔진만 볼 수 있는 상황이었습니다.

그렇게 1년이 지나 앱 런칭 테스트를 진행했고 테스트 이후 2개월 뒤인 1년 2개월 만에 앱이 런칭되면서 고비를 한번 넘게 됩니다. 이 기간 동안 많은 이슈들이 발생하고 경영진과 마찰이 빚어지면서 CTO와 CTO 인맥으로 들어온 개발자들이 프로젝트 후 일을 아예 안 하면서 이상한 행동들을 하다가 얼마 지나지 않아 인수인계 없이 CTO와 함께 다 같이 퇴사했습니다.

그 후...​

CTO와 CTO 인맥들이 모두 퇴사하는 동안 가장 먼저 나간 CTO 이후 새로운 CTO도 여러번 입사하고 퇴사했습니다. 비지니스 요구사항과 CTO의 억지로 막 만들어져 있고 많은 것이 소실된 현재의 상태를 제대로 고쳐나갈 사람이 등장하지 않았습니다. 하지만 시간이 지나고 현 상황을 받아들이고 같이 헤쳐나갈 새로운 개발자들이 체워졌고 점점 체계가 잡혀가면서 업무를 서로 덜어가며 발전해 나갔습니다.

초기 스타트업이었던 이 회사가 다니는 동안 220억 이상 규모의 투자를 유치해 Series C 스타트업이 됐고 이제는 상장을 준비하고 있습니다.

피플팀도 생겨서 직원들의 복지를 고민하며 늘려 가고 카페테리아까지 있어 공짜 음료도 맛 보고 재택 근무도 주 2일을 할 수 있게 분위기가 조성되기 시작했습니다. 기획팀의 숫자도 늘어나고 마켓팅, 브랜딩 등 회사가 더 성장해 나가기 시작했습니다.

나도 회사의 가치를 성장시키기 많은 문제들을 해결하고 신규 BtoB 사업들을 성공적으로 완수해 43개 보험사에서 모두 사용할 수 있는 솔루션을 SaaS로 제공하고 핵심 업무들을 도맡아 수행하며 보험에 대해 끊임없이 스터디했습니다. 신규 인력들이 들어오면서 그 동안 사내에 문서화 해 놓은 자료들을 통해 교육 자료로 사용하고 직접 교육을 하기도 하는 뿌듯한 일도 했습니다.

SaaS를 통한 서비스를 모두 총괄하고 있고 주력 앱인 보닥의 핵심인 보험 엔진 개발 또한 총괄 했습니다. 또한 신규 서비스 개발을 위해 데이터 가공, 분석, 기획 등의 작업을 진행하며 팀원들과 함께 새로운 가치를 발굴하며 새로운 서비스도 찾아나갔습니다.

이직 결심​

회사의 여러 요청으로 여러 차례 CTO 포지션을 제안 받았지만 관리 보다는 엔진 개발에 좀 더 몰두하고 싶어 이를 거절했는데, 다른 오랜 연차의 CTO가 입사했습니다. 이 분은 이미 개발자가 많아 직접 개발하진 않았고 개발 상황을 경영진에게 설명하는 중간자 역활을 했는데 회사에서 가장 오래된 개발자이고 유일한 초기 맴버인 내가 눈에 가시였던 것 같습니다.

아기가 태어나면서 육아를 좀 더 도와줄 수 있도록 풀재택 근무가 필요해졌습니다. 회사에서는 최대 가능일을 저를 위해 2일로 늘려주었지만 이미 엔진과 SaaS 쪽은 풀재택으로도 일을 처리할 수 있는 상황을 어필하자 경영진 쪽에서 이를 허락해 줬습니다.

그러나 개발자들이 차별을 느낀다며 다시 거절됐고 결국 풀재택이 가능한 곳을 찾아보게 됩니다. 나중에 알게된 사실이지만 개발팀원들과 서로 편히 이야기하며 모두 아기 때문에 재택하는 것을 지지해주던 상황이었는데 CTO로부터 그런 이야기가 나오며 거절된 것을 알았습니다.

그렇게 최선을 다해 오던 회사를 나오게 됩니다.

데이터 분석 직무로 이직했던 극 초기 스타트업에서의 이야기입니다.

지원​

IT 구인난이었는지 사람인에 이력서 업데이트만 했는데도 아주 많이 연락이 왔습니다. 얼마 되지 않는 경력인데도 실무를 해 본 신입이라는 것이 좋은 타이틀이 된 것 같습니다.

하지만 직무는 거의 프론트엔드였습니다. 이전 회사에 지원했던 것처럼 일단 회사에 들어가고 직무를 변경해 보자라는 생각은 이전 회사의 밀당 경험 덕분에 일찍이 포기했습니다. 그래서 이번에는 확실히 데이터 분석 직무에 지원했습니다.

검색하다 보니 데이터 분석 직무는 여전히 석사 이상, 캐글 대회 수상자 등 진입장벽이 높았습니다. 오랜 검색 끝에 경력이 적어도 데이터분석 직무를 시켜주는 스타트업을 찾았습니다. 워낙 희귀했기 때문에 당장 그곳에 지원했습니다.

헬스케어 분야의 빅데이터를 통해 서비스를 하고자 하는 초기 스타트업이었습니다. 휴가를 내고 면접을 보러 갔는데 대표님이 생각보다 젋어 보이시는 여자 대표님이셨습니다.

대표님은 데이터 분석 직무로 입사하지만 스타트업 특성상 다른 개발 업무들도 같이 수행할 수 있다는 이야기를 했습니다. 스타트업의 구조상 인력이 부족하면 자금이 부족할 때 인력으로 막아야 하는 것은 이전 회사에서 경험해 봤으니 그 정도는 각오가 되어 있었습니다.

그렇게 순조롭게 면접을 마무리 짓고 연락을 기다렸습니다. 며칠 뒤 입사해달라는 연락이 왔고 다니는 회사에 바로 알린 뒤 2주 간의 인수인계를 거치고 입사하게 됐습니다.

입사일​

입사 당일, 동탄에서 판교 직행 버스로 출근하다가 미금으로 출근하려니 버스를 갈아타고 시간도 오래 걸려서 첫 날이기도 하고 아주 일찍 출근했습니다. 사무실에는 아무도 없었고 당연히 문도 열리지 않았습니다.

사무실 앞에서 노래 들으면서 1시간 가까이 대기했던 기억이 납니다. 대기하다 보니 9시 10분 쯤 되서 어떤 남자분이 걸어왔는데 문 앞에 서 있으시길래 물었더니 그 분도 오늘이 입사일이었습니다.(앞으로 영님이라고 합니다)

그러고 조금 시간이 더 지나 9시 30분 쯤 되자 대표님과 함께 남자 2명이 같이 나타났습니다. 남자 한 분은 나이가 좀 있어 보였고 한 분은 어려 보였는데 남자 분의 부하 직원처럼 나이 있으신 분이 지시를 했습니다.

사무실 문을 얼른 열어주더니 먼저 비밀번호를 알려줄 걸 그랬다며 미안해 하셨고 컴퓨터 부품들을 들고 와서 먼저 왔던 영님과 짐 옮기는 걸 도와 셋팅을 시작 했습니다. 알고 보니 3명 모두 3명이 팀으로 구성해서 이제 시작하는 동기들이기 때문에 입사일을 맞췄다고 합니다.

나이 있으셨던 남자 분은 대표님의 남편분(앞으로 교수님이라고 함)이셨고 그 어린 남자 분은 교수님의 제자(앞으로 석사생님이라고 함)였습니다. 영님과 석사생님과 나, 교수님, 대표님은 회의를 시작했고 회사의 연혁을 상세히 말해주셨습니다.

대표님은 원래 브랜딩 분야에서 경력이 많고 그 분야의 강의로도 꽤 높은 수입을 얻고 계시다가 교수님이 하고 싶은 사업이 있다며 대표님 이름을 빌려서 시작한 사업이 현재의 사업라는 것. 그 동안 투자 유치를 하고 인력을 뽑아 개발 중 수 차례 실패했고 이번에 다시 투자 유치에 성공해 이번엔 제대로 진행하려고 하고 기획은 거의 완성단계에 있다고 했습니다.

완성 단계에 있는데 초기 인원이 지금 입사한다는 것이 뭔가 이상했습니다. 역시나 불안한 느낌은 틀리지 않았고 실제로는 기획서, 요구사항, 그 어떤 것도 없는 그냥 대화하면서 이런 앱을 만들자 정도의 기획이 되어 있었습니다.

데이터 분석 직무를 하려고 들어왔으니 참아보자 생각했지만, 면접 당시 곧 출시할 듯한 늬앙스로 말씀하셔서 기대했는데 실망스러웠습니다. 역시 쉽게 하고 싶은 일을 할 수는 없는건가 생각하며 앱을 런칭해 데이터를 모으면 데이터를 다루는 업무를 해볼 수 있어! 라며 마음을 다 잡았습니다.

그렇게 가져온 노트북을 셋팅하며 하루가 지나갔고 첫 날이기 때문에 저녁 때 고기를 같이 먹자며 회식을 했습니다. 고기를 조금 먹고 내일부터 다 같이 열심히 해보자고 기약하며 하루가 끝났습니다.

프로토타입​

다음날 아침 교수님이 또 나타났습니다. 아침 회의가 시작됐고 원하는 앱에 대해 이야기하고 얼마나 걸릴 것 같냐고 묻더니 우물쭈물 생각하던 사이 1.5주만에 프로토타입을 만들어 달라고 했습니다. 기능만 간단하게 돌아가는 UI를 고려하지 않아도 되는 앱과, 웹 페이지를 만들어 달라고 하며 상황이 밀어부쳐졌습니다.

간단하게 개발 기획을 같이 하고 영님과 석사생님, 그리고 나는 역할 분담을 해야 했습니다. 영님과 석사생님은 네이티브로 안드로이드 앱 개발을 하기로 했고 나는 백엔드, 프론트엔드로 웹 개발과 앱에서 사용할 서버도 백엔드에 같이 만들기로 했습니다.

데모앱에서 시작해 나중에 실제 서비스로 발전할 계획이어서 인력이 적은 지금 ios, aos 모두 가능한 react native로 하는 것을 제안했지만 두 분은 전혀 경험이 없다며 거절하고 안드로이드 스튜디오를 활용해 UI를 조금씩 만들어 나갔습니다.

우선적으로 앱에서 사용할 백엔드 개발 시 참고할 api 규격서를 작성해 앱 개발 시 더미데이터로 참고해 만들도록 문서를 전달했습니다. 그런 뒤 expressjs 를 활용해 api 규격서 대로 백엔드를 개발하기 시작했습니다.

프론트엔드는 UI 컴포넌트를 직접 css로 다 만들지 않고 이전에 서비스에 사용했던 mui를 활용해 개발했습니다. 개발에 속도가 붙어 갔고 개발 기한은 출근일수로 8일 안에 만들어야 했기 때문에 매일 9 to 9으로 일하며 열심히 만들었습니다.

그러다 보니 화, 수, 목, 금, 월 5일 만에 개발을 완료할 수 있었습니다. 개발이 완료되고 수요일에 있을 개발 산출물 점검 때 발표할 내용을 만들면서 외부에서 시연할 때 프론트엔드와, 백엔드, 데이터베이스 서버를 클라우드에 구성하는 방법들을 검색해 봤습니다. 어느덧 수요일이 왔고 발표의 시간이 됐습니다.

회의가 시작되고 웹 개발 산출물에 대해 먼저 발표가 진행됐습니다. 간단하게 ERD 구성을 설명했고 구축된 데이터베이스를 보여준 뒤 시연이 시작됐습니다. 회원가입, 로그인은 bycript, crpyto(AES-256-CBC), jwt를 활용해 암호화 및 토큰 관리를 구현해 웹에서 회원가입, 로그인 시의 동작을 데이터베이스 상의 변화와 함께 시연했습니다.

건강검진 pdf 파일을 웹에서 업로드하면 자동으로 데이터를 파싱한다는 모델이었는데 파싱 모델은 아직 개발되지 않았기 때문에 예시로 만들어 놓은 더미 데이터를 데이터베이스에 넣어 두었습니다. 더미데이터와 교수님이 가져온 10만명의 건강검진 데이터를 결합해 통계 시각화를 만들었고 이를 대시보드 형태로 보여주고, 업로드한 pdf파일 내용을 웹상에서 볼 수 있도록 했습니다.

이제 앱을 시연할 차례였습니다. 앱에서는 시연 시 잘 보이지 않으니 건강검진 사진을 찍어 업로드하는 부분이 구현되어 있으면 됐습니다.

하지만 버튼들이 한 줄로 나열되어 있는데 버튼 글자도 아직 test1, test2, test3, ... 식으로 되어 있었는데 test1을 눌러도 다른 버튼을 눌러도 화면 전환만 되고 기대하는 동작이 일어나지 않았습니다. 회의실의 분위기는 급격히 얼어붙었고 교수님과 대표님은 그 동안 뭘 한 거냐며 급 화를 냈고 실제 투자 시연일은 다음주라며 이번주 안에 어떻게든 마무리 지으라고 했습니다.

그렇게 회의가 끝나고 영님과 석사생님은 멍한 상태가 되었고 이미 웹 개발과 데이터베이스 서버를 클라우드에 구성했기 때문에 앱 개발에도 참여하게 됐습니다. 사실 우리 셋 중 누구도 앱을 개발해 본 사람은 없었고 그나마 react랑 비슷하다는 react native로 개발해 보자는 의견이 잘 먹혀서 금요일까지 혼자 앱 개발을 한 뒤 개발한 내용에 대해 두 분에게 설명했습니다.

react native로 갤러리 사진이나 카메라 사진을 업로드하는 예제를 인터넷에서 찾아 ui를 간단히 구성한 뒤 api를 통해 건강검진 데이터를 데이터베이스화 했다는 요청을 만들어 적당히 완성할 수 있었습니다.

그렇게 투자 유치를 위해 사용할 프로토타입 앱을 완성했고 대표님이 스피치를 잘 하셨는지 투자를 받으셨고 디자이너, 카피라이터, 의료데이터 전문가 등 많은 분들이 채용되기 시작했습니다.

퇴사 레이스​

석사생​

프로토타입을 완성하고 시연이 끝난 후 대표님은 앱 개발했던 두 분에게 탐탁치 않았는지 강한 어조로 변하셨습니다. 그 중에서도 석사생님에게 그 압박이 좀 더 강했는데 야근하지 않고 집에 가려 하면 30분 정도 일 제대로 했는지 체크하기도 하고, 일에 대한 컨펌을 할 때는 할 줄 아는 것이 없다며 월급을 줘야 하는지 고민이라는 말도 해가며 폭언을 이어갔습니다.

내가 들리던 몇몇 말들 외에도 점심 식사 때 석사생님에게 들은 많은 폭언들은 심각했고, 석사생이면서 알바로 업무를 하던 중이었는데, 결국 석사생님은 얼마 지나지 않아 다시 대학원으로 돌아갔습니다.

디자이너​

대표님이 가르치던 브랜딩/디자인 강의의 수강생 중 현재 부산에서 디자이너로 일하고 있던 분을 스카웃하셨습니다. 디자이너는 대표님 강의를 들을 때 감명 깊었는지 대표님을 존경하고 있었습니다. 그래서 부산에서 분당으로 자취방까지 얻어 다니던 직장도 퇴사하며 이직을 한 것입니다.

하지만 기획자가 없이 디자이너만 있다 보니 기획, 디자인을 모두 담당해야 했는데 교수님, 대표님을 직접적으로 컨택하며 일을 해야 했습니다. 문제는 교수님이나 대표님 모두 개발에 필요한 기획에 대해 무지한데 대표님이 디자인에 감각이 있다 보니 꼼꼼히 디자인에 대해 지적들을 하다가 결국 화를 내기 시작했습니다.

얼마 지나지 않아 대표님은 다시 월급 루팡이라는 식의 발언을 조금씩 하며 디자이너에게 연봉을 낮춰 계약하려 했고 결국 디자이너는 자취방 계약 기간을 체우지 못하고 1달 만에 다시 부산으로 내려갔습니다.

카피라이터, 의료데이터 전문가​

디자이너가 나갈 때 쯤 의료데이터 전문가와 카피라이터가 들어왔는데, 의료데이터 전문가는 간호사 출신으로 의료 코드를 넣는 등의 행정일을 도맡아 오다가 의료데이터를 다루는데 익숙하고 현재는 사업을 하나 런칭 준비중인 어리고 열정 넘치는 분이었습니다.

카피라이터는 다른 직종에 있다가 블로그를 쓰면서 카피라이터를 하게 됐는데, 신입이어서 이 회사에서 많은 일을 하고 싶어했습니다.

의료데이터 전문가는 의료코드 정리 업무부터 맡았고 그 코드들에 대한 소비자를 위한 설명을 달아주는 일을 했는데 생각한 것보다 빠르게 적응하며 일을 잘 해 나갔습니다. 하지만 카피라이터는 정량적인 일이 아닌 느낌있는 글을 써야 했기에 대표와 큰 마찰을 빚었습니다.

대표와 본인의 스타일이 전혀 안 맞는다며 입사 후 1주일도 되지 않아 퇴사를 결정했고 퇴사 이유를 대표한테 분명히 말하고 퇴사했습니다. 의료데이터 전문가도 대표의 업무 중 눈치주는 것과 디자이너, 카피라이터 등 여러 사람들이 퇴사하는 것을 지켜보더니 사업에 전념하고 싶다며 퇴사했습니다.

나도 언제까지나 무리한 일정과 주변에서 듣는 폭언을 듣고 보다 보니 나에게도 일어날 수 있다는 불안감이 들기 시작했고 마음 속으로 퇴사에 대한 생각이 들기 시작했습니다.

건강검진 데이터 구축 서비스​

입사했다가 금방 사람들이 나가는 뒤숭숭한 분위기 속에서 남아 있는 영님과 나는 회의실에서 교수님과 진지하게 회의를 했습니다.

건강검진을 하면 병원에서 공단으로 결과를 전달하는데 그 때 만들어지는 공단 전송 파일을 pdf로 프린트 할 수 있고 병원과 제휴해 pdf 파일을 제공받으면 이 데이터를 토대로 건강검진 데이터를 얻고 그 데이터로 여러 서비스를 할 수 있으니 일단 병원 별로 다른 pdf 데이터를 자동으로 추출하는 모듈을 만들어 보자고 했습니다.

이미 교수님이 100만 개의 건강검진 pdf 파일을 가지고 있었고 이것을 통해 작업을 시작할 수 있었습니다. pdf 파일에서 text를 추출하는 작업은 처음하는 일이었는데 pdfminer, tesseract, pypdf 등 사용할 수 있는 것이 많았지만, 정확도가 떨어졌습니다. 그래서 결국 다른 빠르고 정확한 방법을 찾아내 대부분의 pdf 파일을 만족하며 txt를 정상적인 순서로 불러오는 것에 성공했습니다.

그 후에는 여러 순서로 되어 있는 txt에서 원하는 txt를 불러오기 위한 수작업들이 오래 지속됐지만 결국은 100만 개 중 80%를 만족시키는 자동화 모듈이 완성했습니다. 나머지 20%도 완전히 정확히 가져오는 것이 아닐 뿐 대부분의 필요한 txt를 추출했습니다.

하지만 다음 pdf 파일에서 어떤 형식이 올 지는 모르는 상황이기 때문에 자동화로 가져오는 txt에 대해 가져올 가능성이 없거나 있는 txt들을 모아 Validation 모듈을 만들었습니다.
이 후에는 자동 추출 후 Validation 에서 실패한 케이스를 모아 웹에서 쉽게 이미지를 조정하며 확인해 수동으로 수정할 수 있는 관리자 싸이트도 만들었습니다.

그렇게 빠르게 2주가 지나갔습니다.

아래는 자세한 과정입니다.

텍스트 추출​

우선 100명 분의 건강검진 데이터를 대상으로 pdf 파일에서 텍스트를 추출해 보고 여러가지 라이브러리, 심지어 유료 라이브러리의 체험판도 이용해 보며 추출을 시도해 봤지만 모두 추출된 텍스트를 사용하기에 적절하지 않아 보였습니다.

여러 시도를 하던 중 크롬에서 pdf 를 열어 전체 선택 후 복사해 txt 파일로 저장해 봤는데 각 필드 결합을 하기에 그나마 가장 적합하게 텍스트가 추출됐습니다. 하지만 방대한 pdf 파일을 모두 열어 수동으로 텍스트를 복사해 파일로 저장하는 것은 불가능하니 이를 자동화 할 방법을 찾았고 pyautogui 를 활용해 자동화하여 텍스트를 추출할 수 있었습니다.

텍스트 분류​

초기 100명 분의 텍스트 추출과 필드 추출을 위한 규칙들은 1000개의 작업부터는 다시 예외들로 가득 찼습니다. 예외들에 대한 대응 코드들과 케이스들을 포괄하기 위한 포괄 코드들을 잘 조합해 가며 개수를 점점 늘려가며 테스트했습니다.

1000개에서 2000개로 2000개에서 3000개로 조금씩 늘려갈수록 점점 예외 케이스가 보이지 않았고 7000개에서 10000개 사이에는 예외가 없어졌습니다. 모든 케이스를 검증해보면 좋겠지만 그렇다면 이 자동화 모델을 만들 이유가 없기에 만 개 까지만 고려해 만들어 보고 가지고 있던 나머지를 함께 테스트 해봤습니다.

10만개 데이터에서 예외없이 정상 동작해 분류됐고 이제 활용할 수준이 됐다는 생각이 들었습니다. 그렇게 100만 개 데이터까지 테스트를 완료할 수 있었습니다.

하지만 역시 pdf 텍스트 추출과 분류 과정은 덕지덕지 붙여서 겨우 완성시킨 모델에 불과했기 때문에 분류 실패 케이스를 확실히 인지하고 이를 수동 수정하여 삽입할 수 있게 하는 것이 더 중요하다 생각했습니다. 그래서 각 필드 값들에 대한 범위를 구해내고 그 범위와 다른 잘못된 값들이 있을 시 인지해 수동 수정할 수 있도록 하는 체계를 만들었습니다.

어드민​

텍스트 분류 모델이 완성 됐으니 이를 활용할 수 있도록 어드민 페이지가 필요했습니다. 로그인, 회원가입 기본 구성에 모델에서 실패 케이스를 pdf 를 보며 수동 분류하는 페이지, 나중에 앱에서 사진 파일 업로드한 걸 보며 수동 입력해 분류하는 페이지를 만들고 자동으로 분류된 데이터를 고객 또는 필드들에 따라 검색하는 페이지 등 많은 기능을 구현했습니다.

병원용 웹​

교수님과 많은 병원들에 제휴하기 위해 병원들의 상황을 확인해 본 적이 있는데 작은 병원들의 대부분은 종이로 환자들의 검진 데이터를 쌓아두고 있었습니다. 환자 관리 또한 서류로 이뤄지고 있었습니다.

큰 병원들은 자체적으로 앱도 만들고 많은 부분이 디지털화 되어 있지만 제휴를 맺기는 힘들고 중소 병원들을 최대한 많이 제휴해 데이터를 모야야 했습니다. 병원 측에 지도 정보, 환자 정보를 디지털화 해서 환자 관리 및 분류 시스템을 만들어 주고 대시보드도 구성해 주는 것을 건강검진 데이터를 정보 제공 동의한 환자에 한 해서 구축해 주는 것을 제안했습니다.

하지만 병원에서는 실질적으로 사용해 보지 않은 서비스에 관심이 없어서 그 의미에 대해 별 생각이 없었습니다. 그것보다 건강검진 결과를 병원에서 제공해 주면 그 결과를 우편으로 발송해 주는 업무를 대행해 줬으면 했습니다.

이건 속도전이라며 교수님은 빠른 개발을 계속 요구했고 영님과 나는 병원용 웹 + 발송 대행 업무를 할 수 있도록 협약을 하나 둘 맺어 가며 개발 기획에 맞춰 더미데이터를 만들고 환자 관리 시스템을 구축하고 있었습니다. 구축하던 중 추가적으로 의사분들이 원하는 다른 요구사항들이 생겨나면서 프로젝트는 점점 방대해져 갔습니다.

개발 협약​

병원용 웹을 개발하면서 의사분들의 요구사항은 점점 더 커져갔고 병원마다 환자들이 정보 제공 동의받는 것부터 데이터를 입력받는 태블릿 앱까지 만들어 납품해 달라는 요구가 있어 이 또한 만들어야 했습니다.

그 와중에 대표님이 런칭하고 싶어서 카피라이터까지 구해서 진행하던 헬스케어 앱 개발을 빨리 진행했으면 좋겠다며 압박이 들어오기 시작했습니다. 영님은 웹, 앱 구성에 대한 경험이 없는 상태로 옆에서 도움이 되지 못했고 더 이상 혼자서 많은 플랫폼을 만드는데는 한계가 있었습니다.

교수님과 대표님의 상상력은 눈덩이처럼 계속 불어났고 이에 대해 계속 호소하는 영님과 나에게 문제를 인식했는지 개발 인원이 부족한 것을 안다며 대표님이 아는 멘토님의 회사에서 개발자, 디자이너, 기획자, PM 등을 지원받는 협약을 하겠다고 했습니다.

멘토 분은 대표님이 투자받기 위해 다니다가 투자 관련 검토를 해주던 분 중 하나인데, 우리와 개발 협약을 하기로 한 회사의 이사였습니다. 그래서 그 회사 근처에서 미팅을 했습니다.

미팅 자리에서 이사분은 협약을 한다면 개발 주도권을 완전히 그쪽에서 가져가고 기존 개발진들도 우리가 시키는 바를 했으면 한다고 말했습니다.

나로서는 이미 친해졌던 분들이 퇴사 압박을 받다가 퇴사하게 되고 업무는 개발에 대한 고려없이 밀려오는 상황에서 이미 퇴사할 마음을 가지고 있었지만 개발 가능 인원이 없는 체로 발 동동거리는 대표님과 교수님을 두고 퇴사하기가 인간적으로 힘들어 버티고 있었던 터였기 때문에 희소식이었습니다. 이 타이밍이 기회라는 생각이 들었습니다.

이직​

퇴사 생각이 있었기 때문에 미리 이력서를 업데이트 했었습니다. 그래서 헤드헌터들로부터 제안을 받는대로 최소 10인은 되는 회사들을 찾으며 좋은 연봉 조건인 회사들로 면접을 다니기 시작했습니다.

그러던 어느 날 의료 빅데이터 포럼을 모두 같이 참관하러 간 날, 적당히 포럼을 듣고 중간에 나와 면접을 보러 갔습니다. 면접을 보러 간 회사에 도착했고 환경이 좋아 보이는 사무실에 들어섰고 회의실로 안내받아 면접이 시작됐습니다.

CTO님과 부대표님이 면접을 봤는데 부대표님이 동년배 같아 보여 말이 잘 통할 것 같았고 CTO님도 굉장히 호의적인 자세로 질문을 하셔서 이야기도 술술 풀렸습니다. 면접은 잘 마무리 된 느낌으로 채용을 진행할 듯 보였는데 전체 경영진과 함께 2차 면접이 있다고 하여 결과를 기다려야 했습니다.

얼마 지나지 않아 면접 일정이 잡혔고 회사에 도착하니 같은 회의장으로 안내 받았습니다. 면접을 보는 경영진분들은 5명 정도 있었고 그 중에 대표님 찰스도 있었습니다.

실무적으로 뭘 해봤는지에 대해 간략히 설명했고 이후로는 일을 진행하는 방식, 문제를 숨기지 않는 성격인지 등의 인성적인 질문들이었는데 나름대로 잘 대답한 듯 했습니다.

좋은 분위기 속에서 찰스가 그래도 경력이 너무 적어 신임하기 힘들다며 갑자기 경력을 이용해 연봉을 낮추려 하셨고 모두가 있는 자리에서 연봉 협상을 시작하셨습니다. 이미 헤드헌터와 이야기한 연봉보다 500만원이나 낮춘 금액으로 협상이 됐고 그렇게 하루 이틀 뒤 전화로 입사일 조정을 하며 입사가 결정됐습니다.

국비지원 교육이 끝나고 새로운 직종으로의 첫 취업을 하고 직장생활을 다시 시작한 이야기입니다.

지원​

국비지원 과정을 수강하던 시절 SI회사 PM으로 이사로 지내시던 분이 본인이 사업을 준비하기 전 개발을 배워 개발자로 전향해 보고 싶어하던 동기분이 있었는데, 수업이 마무리 될 쯤, 그 분이 본인이 점 찍어 둔 학우들에게 이전에 다니던 SI회사로 취업을 권유하셨습니다. 권유를 듣고 지원한 학우들도 꽤 있었는데 수업이 끝나기 전 취업에 대해 알아봤기 때문에 SI회사에 대한 소문을 많이 들어 고민이 됐습니다.

업무 강도가 강하고 시키는대로만 하고 철수해서 시간이 지나도 서비스에 대한 경험이 안 생긴다는 등 많은 글들을 봤습니다. 그래도 무경력에 나이도 있어서 지원을 할까 망설였지만 거절했습니다.

지나고 보니 어느 분야에 있어 첫 회사는 생각보다 의미가 큰 것 같습니다. 직종이라는 대분류를 변경하려고 정말 많은 노력이 필요했던 것처럼 첫 회사는 대분류까지는 아니지만 중분류를 결정하는 일이었습니다.

이 중분류는 앞으로의 커리어를 정할 때 내 경험의 분류를 정하기 때문에 노선을 정하는 역활을 합니다. 그리고 이 중분류 또한 많은 노력을 해야 변경할 수 있다고 생각합니다.

IT회사에 지원하기 위해 전략을 세워 봤습니다. 자기 객관화가 먼저 시작했습니다. 나이도 많고 교육과정 수료한 것이 전부인 나와 나이도 어리고 컴공을 졸업한 학생들과 비교했을 때 실력이 비슷하더라도 나 같으면 어린 친구들을 뽑을 것 같았습니다. 그래서 대기업은 우선 포기했습니다.

대기업을 제외하니 남는 건 중소기업이었는데 IT계열에서는 신생 중소기업들을 스타트업이라고 멋있게 표현하고 있었습니다. 스타트업이라는 단어는 회사 규모가 작지만 자유롭고 빠른 성장을 위해 도전하는 느낌이었습니다. 수평적인 분위기에 스스로 공부하고 도전하는 나의 가치관과도 맞았습니다.

IT회사들은 구로디지털단지, 가산디지털단지, 강남, 판교 등의 지역으로 나뉘어져 있었습니다. 강남이 이미 좀 커진 회사들이 옮겨간 회사들이 많은 것 같았고, 판교가 대기업도 있지만 스타트업들도 많고 전체적인 분위기가 가장 좋아보였습니다. (구로, 가산은 좀 옜날 느낌...)

직무는 데이터분석 직무를 택하고 싶었지만 고학력자와 경력이 많은 사람들만 지원 가능했습니다. 그래서 데이터분석 직무가 있는 회사로 신입이 잘 뽑히는 프론트엔드 직무로 지원하기로 했습니다.

결론은 판교 쪽에 위치한 스타트업 중 분위기가 좋아보이면서 데이터분석 직무를 채용하고 있으면 그 회사의 프론트엔드 직무로 지원을 시작했습니다. 많은 곳에 지원 했지만 연락오는 기업은 없었습니다. 불안감에 SI회사 지원, 이전 직종으로의 복귀 등 많은 가능성들을 염두하며 12월까지 채용이 되지 않으면 안타깝지만 포기하고 이전 직종으로 돌아가기로 결정했습니다.

12월 중순쯤, 하나의 회사에서 면접 연락이 왔고 면접 준비를 열심히 임했습니다.

면접​

건물에 들어가자 공간이 아주 크고 넓었습니다. 휴게실도 크고 티비보며 누워있는 사람들도 있고 독특한 조형물들도 있고 이전에 일하던 장소와는 전혀 다른 자유로운 분위기였습니다. 이게 판교의 IT 회사인가 싶어 신나 있는 상태에서 걷다 보니 여러 회사들이 같은 층에서 여러 시설을 공유하면서 사용하고 있는 것처럼 보였고 마침내 면접 보기로 한 회사를 찾았습니다.

2분의 실무진과 유리로 오픈되어 보이는 회의실 같은 곳에 데려가 면접을 진행했습니다. 우선 간단하게 이 분야의 짧은 이력을 가지고 자기소개를 시작했습니다.

그런 뒤 이전의 경력들을 통해 내가 다른 신입들 보다 좀 더 회사 생활에 익숙하고 잘 할 수 있음을 어필했습니다. 또한 지금까지 뭘 공부해 왔고 무엇을 할 수 있는지, 개발해 본 경험은 무엇이 있는지 아주 상세히 설명했습니다.

내 이야기가 끝나고 면접을 보는 선임분들은 입사하고 개발 시 사용하게 될 개발 스택에 대한 설명을 미리 해줬습니다. 그리고 바로 입사에 동의하는 듯 말하며 대표님 면접만 잘 마무리되면 입사를 결정하겠다고 말했습니다.

서로 영어이름으로 대화하던 선임들이 많이 이질적으로 보였지만 대표님이 많이 꼰대라며 대표님 때문에 지원의사를 취소하지 말하달라며 농담을 하는 것을 보고 여느 회사와 다르지 않다 생각했습니다. 그리고 굉장히 수평적인 회사인 것 같아 인상이 참 좋았습니다.

대표님과의 대화는 참 길었습니다. 처음보는 나에게 본인이 해 보고 싶은 개발 과제에 대해 말했고 개발자로서 어떤 삶을 살아야 하는가에 대해 도덕책에 적혀있을 것처럼 도덕적으로 나를 코칭 했습니다. 좋은 어른이라 그런건가 싶어 열심히 경청했고 그 자세가 맘에 들었는지 대표님은 바로 출근 일정을 물었습니다.

그리고 나서도 계속 대화를 이어갔는데 이번엔 기독교에 대한 이야기를 이어가셨습니다. 종교를 강요하는 듯한 조금 불편한 대화였지만 대표님과의 대화이니 참아냈습니다.

전체 면접만 3시에서 8시가 다 되도록 진행됐고 면접 날이 금요일이었는데 바로 다음주부터 월요일 출근하기로 결정됐습니다.

이 때는 모든 게 좋아 보이던 때라 많은 단서를 놓쳤던 것 같습니다.

첫 날​

환경이 참 좋은 판교에 매일 일하러 간다니! 포기하고 이전 직종으로 돌아가려 했었는데, 결국 IT 쪽으로 취업할 수 있어 기뻤습니다. 일찍 출근해서 대표님과 인사하고 개발에 사용할 아이맥을 받았습니다.

나중에 들은 바로는 면접을 보던 2명의 개발자를 제외하고 병특으로 사람을 뽑아 쓰는 식으로 정규직 채용을 안하고 사람을 돌려서 쓰던 포지션을 이번에 나부터 정규직으로 채용한 케이스였습니다.

당시에는 맥OS를 처음 사용해 봤고 개발 셋팅하는 법도 모르고 트랙패드를 주셔서 트랙패드를 사용하고 하니 참 불편했습니다. 인터넷으로 검색해 가며 iterm2 부터 하나 하나 셋팅해 이쁘게 만들어 가며 뿌듯해 하던 기억이 납니다.

iterm2 셋팅을 하고 면접 당시 들었던 javascript 개발을 위해 첫 출근 전 주말에 공부했던 react 프레임워크에 대한 개발 셋팅을 했습니다. 그렇게 개발 셋팅을 완료하고 꾸준히 개발에 사용하다 보니 이후로는 윈도우로 개발하는게 너무 불편해 맥만 사용하게 됩니다.

일찍 출근해 한참 뒤 다른 선임들이 왔는데 30분 정도 유동적으로 출퇴근 하는 것 같았습니다. 개발 인원은 실무진 면접 때 들어왔던 선임 개발자 2분이 전부였고 영어 이름을 지어오라고 해서 영어 이름을 알렉스로 정해 말씀드리고 기분 좋게 첫 출근을 마쳤습니다.

업무 시작​

javascript 언어는 jquery를 사용할 때 처음 접했고 그마저도 UI 조작용으로만 간단히 배워서 개발할 수 있는 수준이 되지 못했습니다. 면접 때 react로 프론트엔드를 마이그레이션 할 예정임을 들었는데 입사 당시에는 MarionetteJS를 사용하고 있었습니다. 전부 새로운 프레임워크와 언어 환경에 적응해 가며 3일 정도 소스파악을 하고 간단한 유지보수를 했습니다.

그리고 작은 회사이었기 때문에 선임들은 CS업무를 어쩔 수 없이 맡아야 하는데 지금까지는 선임 개발자가 막내였어서 전화를 거의 받았다며 이제 전화를 내가 받아야 한다며 입사한지 얼마 되지 않았는데 고객을 상담하는 전화를 받아야 했습니다. 개발자가 고객의 소리를 듣고 잘못된 부분을 빠르게 수정해 적용할 수 있다는 말을 했는데 옳은 말 같았고 막내기도 했으니까 다음 막내가 오기까지 일을 맡게 됐습니다.

마이그레이션​

열심히 유지보수를 진행하다 보니 어느덧 면접 때 말한 마이그레이션 시기가 다가왔습니다. ReactJS로의 마이그레이션이었습니다. 입사 전부터 유지보수하는 동안에도 꾸준히 공부해 왔기 때문에 class component 방식으로 React 프론트엔드를 구성하는 것이 어렵지 않을 것 같았습니다.

자신했던 것과 달리 실제 개발하면서 부족함을 실감하게 됩니다. react를 사용하는데 보다 효율적으로 코딩을 하기 위한 redux, router 등 여러 다른 라이브러리들이 있었고 처음 보는 것이 react, redux, router, mui 등 라이브러리 지옥에 진입하게 됩니다.

동시에 기본기가 없었던 나에게 javascript, react 개발에 필요한 최적화 패턴들과 원리들을 경험하며 그 동안 공부한 건 아무것도 아니구나 재차 느끼게 됩니다. UI 구성을 위한 라이브러리들과 기본기 공부를 하며 고된 시간이었지만 그래도 결국 기한 내에 마이그레이션을 마무리 할 수 있었습니다.

개발을 진행하고 완료해 가면서 프론트엔드에서 요청한 api가 어떻게 만들어지는지 궁금해 백엔드 코드를 보고 싶었지만 선임 개발자는 코드를 보여주기를 꺼려했습니다.

정부 과제​

입사 전 계획처럼 프론트엔드 개발을 잘 해내고 나면 데이터분석 직무에 관심이 있으니 그 직무도 할 수 있다고 면접에서 대표님이 말씀하셨었기에 호시탐탐 업무를 노리고 있었습니다. 그러던 중 정부 과제로 사업을 따 냈고 그 사업에 데이터 분석 업무가 필요했습니다.

선임 개발자들은 데이터 분석, AI에 관심이 없었기 때문에 이건 내가 맡을 수 있는 업무다 라고 확신하고 있었습니다. 과제는 청각 장애인을 위한 AI를 활용한 SRT 수화 방송 서비스 개발이었습니다.

데이터 수집​

대표님에게 개발에 적극 참여하고 싶은 의사를 밝혔고 대표님도 이 분야가 원래 나의 관심사인 것을 알고 있었고 마이그레이션도 성공적으로 마무리되서 이를 수락했습니다.

처음에 전달 받은 업무는 데이터 분석을 위한 데이터 수집을 하기 위해 음성 수집 기계를 직접 가지고 SRT에 방문해 배선 공사 대표님들과 함께 이동하며 수집 장치를 설치했습니다. 통신 테스트를 통해 수집이 정상적으로 이뤄지는지도 확인하며 데이터가 쌓이는 것을 보며 얼른 쌓여라 생각하며 기대 했습니다.

수 차례 기계 설치를 완료하고 애니메이션 업체와 컨택해 수화 방송에 대한 컨셉을 같이 잡았고 회사에서 음성 분석을 위한 AI 엔진인 에트리 엔진과 슈퍼 컴퓨터도 구매했습니다.

머신러닝과 에트리 엔진 소프트웨어를 사용할 수 있도록 python, tensorflow-gpu 등을 1대의 컴퓨터에 셋팅을 완료 했습니다. 기쁜 마음으로 셋팅을 완료했을 때 갑자기 데이터 분석 직무의 개발자가 신입으로 입사했습니다.

신규 앱 런칭​

신입 데이터 분석가로 입사한 개발자는 아직 대학 졸업도 안한 개발자였고 실제로 개발 자체에 대한 경험도 없는 사람이었습니다. 심지어 국문학과에 부전공으로 데이터 분석을 했기 때문에 데이터 분석 자체에 대한 기술적 역량이 없었지만 그래도 언어적인 이해가 높다 하여 결국 정부 과제에서 물러나게 됩니다.

정부 과제에서 물러나고 나에게 다른 업무가 배정됐는데, 또 새로 들어온 인턴분과 함께 진행하게 됐습니다. 업무는 회사의 코어 기술을 활용할 신규 서비스에 대해 생각해 보고 생각해 본 서비스에 대해 시장조사부터 시작해서 UI설계까지 해 신규 앱을 런칭하는 것이었습니다.

간만에 학원에서 하던 팀 과제를 진행하는 기분이었습니다. 인턴분과 브레인스토밍을 같이 하며 여러 후보군이 나왔고, 그 중 대표님이 선택한 몇 개의 아이디어들에 대해 시장조사를 시작했습니다.

후보군은 아래와 같았습니다.

1. 중고차 시장에서의 고객 관리 서비스
2. 부동산 시장에서의 고객 관리 서비스
3. 동네 마트의 고객 관리 서비스

시장조사​

3개의 주제로 중고차 시장부터 부동산, 마트 등 여러 곳에서 하고자 하는 서비스를 직접 영업점에 가서 설명드리고 그 서비스가 있다면 사용하겠는지와 더 필요한 기능들에 대해 인터뷰를 했습니다. 처음에는 잘 안 받아줬지만 대학생인 척하고 과제 수행중이라고 하자 생각보다 흔쾌히 인터뷰에 임해줬습니다.

여러가지 의견들이 있었습니다. 본인들의 업무가 굉장히 복잡하기 때문에 조금도 고객 관리를 자동화할 수 없을 거라고 업무를 설명해주지 않는 분들도 많았고 앱의 필요성을 이야기하며 주도적으로 쓰고 싶어하는 분들, 자식같다며 좋아하시는 분들 등등 시장조사에 대한 결론으로 당시 회사에서 운영중인 앱을 사용하던 고객 중 슈퍼마켓에서 사용하는 고객이 있었는데 그 분의 요구사항을 들어주는 걸로 결론이 났습니다.

이럴거면 시장조사는 왜 한 건가 싶었지만 그래도 좋은 경험했다 생각하기로 했습니다.

UI 설계​

주제가 정해지고 와이어프레임 작업을 시작했습니다. 당시 회사에 나오던 디자이너분이 있긴 했지만 그 분은 출근을 했다 안 했다 하는 대표님의 지인이어서 업무를 도와주지는 않아 스스로 해야 했습니다.

와이어프레임은 요구사항과 같이 간단하게 고객 목록에 메시지를 보낼 수 있으면 되는 것이라 어렵지 않았습니다. 많은 기능이 있지 않았으면 했고 간단한 일만 하게 될 컴퓨터에서 돌아갈 앱이니 UI 구성이 중요하지 않다고 했습니다.

그래서 필요한 기능만 있고 필요한 기능만 버튼도 큼직하게 사용하기 좋은 UI를 구성했습니다. 그 후 카카오 오븐에서 프로토타입을 만들어 완성했고 날을 잡아 전직원이 사용성 테스트를 진행해 처음 보는 사람도 사용에 설명조차 필요 없는 형태라고 칭찬받으며 UI 설계가 마무리 됐습니다.

개발 및 런칭​

개발에 익숙했던 react로 앱을 구성했습니다. 신규 프로젝트에 router, redux 등 기본 구성들로 레이아웃을 만들고 로그인, 회원가입 등 기본 페이지를 완성했습니다. 선임분은 백엔드 소스를 이 때까지도 보여주지 않고 있었어서 모두 더미데이터로 UI 설계된 대로 화면을 구현했습니다.

Api 문서도, 백엔드 소스도 보여주지 않고 있던 선임개발자는 시간이 촉박해지자 백엔드 소스를 보여줬고 그제서야 expressjs 공부해 백엔드를 이어 나갈 수 있었습니다. 그리고 얼추 개발이 완료될 쯤 커밋 사항들을 보고 있었는지 선임개발자가 그렇게 개발하면 사용할 수 없다며 나누어 개발하던 내 브랜치를 로컬과 리모트에서 맘대로 제거한 뒤 본인이 만든 내용으로 바꾸라고 통보했습니다.

설명도 없이 소스도 지우고 프론트엔드 구성도 고려하지 않고 만들어진 백엔드로 다시 고쳐야 하는 상황에 화가 났지만 웹 개발팀 직속 선임이고 IT 첫 회사에서 무경력 상태로 혹시나 짤리지 않을까 걱정되서 참아야 했습니다.

그렇게 이를 악물고 수정해서 웹에서 정상 동작하는 것을 테스트 완료해 배포하려 하는데, 고객사에서 웹 싸이트가 아닌 데스크톱 앱으로 배포해 달라는 요청이 왔습니다. 데스크톱 앱은 뭐지? 처음 배운 것도 웹이고 지금까지 한 것도 웹이라 데스크톱 앱을 만들라니 깜깜했습니다.

그렇게 검색을 하다 보니 데스크톱 앱으로 개발을 다시 해야 하는지부터 언어를 c 계열로 바꿔야 한다는 둥 여러 의견들이 있었는데, 이미 개발 완료한 react 소스를 버리기 싫어 검색하던 중 ElectronJS를 찾아 냅니다.

electron을 이용하면 javascript와 react로 구성된 웹 페이지를 데스크톱 앱으로 감싸서 배포할 수 있었습니다. 그렇게 재개발의 위기에서 이것을 통해 기한을 맞춰 서비스를 런칭할 수 있었습니다.

이직 결심​

IT 분야의 첫 회사였고 첫 인상도 좋았는데 이직을 하게 된 데는 여러가지 이유가 있었습니다.

선임 개발자​

가장 큰 원인은 직속 선임이었던 선임 개발자였습니다. 선임 개발자는 음식에 진심인 사람이었고 다 같이 먹는 점심 식사에 본인이 먹고 싶은 메뉴로 꼭 먹어야 하는 사람이었습니다. 그리고 식사 시간에는 본인의 정치 성향을 강조하며 이에 반하는 사람에게 폭언을 하거나 그런 사람들에 대해 뒷담화하는 시간을 가졌습니다.

시간이 지나면서 본인의 정치성향을 넘어 가치관들까지 강요하기 시작했습니다. 예를 들면 신입 때는 야근을 해서 살아남으려고 노력해야 한다는 등의 말도 안되는 소리들이었습니다.

그리고 예전에 판교에서 복싱을 배웠는데 아주 잘했다며 작은 키로 센 척을 많이 해댔는데 사람이 참 작아 보였습니다. 어린 나이가 아닌 40대인데도 불구하고 눈 앞에서 진심을 담아 쉐도우 복싱하며 위협하던 건 잊혀지지 않는 기억입니다.

본인과 담배를 피러 같이 가주지 않으면 삐지기도 하고 혼잣말로 욕설이나 폭언도 가끔 하는 정신적으로 불안한 선임이었습니다. 위의 상황들은 군대도 갔다 왔으니 적당히 맞춰 줄 수 있는 문제들이었다.

하지만 업무에 있어 내가 만든 소스를 아무런 설명도 없이 삭제하거나 기한이 있는 업무에 협조하지 않고 개발 소스를 공유하지 않는 행동들은 같이 일하는 성인의 태도가 아니었습니다.

나중에 선임 개발자와 퇴사를 결정하기 전 같이 허심탄회하게 이야기를 했었는데 어차피 이 회사에 2명만 있으면 일이 돌아가고 어린 여직원을 채용하고 싶다고 했습니다. 그래서 일부러 일을 가르쳐주지도 않았고 소스도 안 보여줬다고 말했습니다. 의문은 풀렸지만 노총각의 행동에 기분은 좋지 않았고 나가야 할 회사라는 생각이 더 확실해졌습니다.

대표님​

대표님은 기독교에 신실하고 진심인 분이었습니다. 그래서 나에게 종교생활을 강요했습니다. 매주 주말에 교회를 갔다 왔는지 물었고 수요일 점심시간엔 직장인 예배에 데려갔고 멘토까지 이어주며 관심이 없음을 여러차례 돌려서 말했지만 종교에 나를 빠뜨렸습니다.

회사가 어려워져 입사 전 약속됐던 점심 복지도 직원들을 위해 지불하는 4대 보험도 밀리는 상황에서도 직장인 예배에 교인들에게는 본인이 굳이 점심을 구매해 제공했습니다. (회사 인원은 5명, 교인들은 100명 가까이 됐습니다.)

대표님도 퇴사의 이유긴 했지만 그래도 결정하기 전 회사의 대표인 대표님과 이야기하고 싶었습니다. 종교 강요는 그래도 참을 수 있으니까, 선임 개발자와 있었던 여러 일들과 부당한 행동들에 대해 이야기를 했는데 종교의 힘으로 이겨낼 수 있음을 이야기 했고 본인도 사람 다루는데 있어 정말 힘들지만 해야 하는 일이라며 이상한 논리를 펼치기 시작했고 마치 내가 이 회사를 위한 순교자처럼 희생해야 할 것 같은 답변을 내놓았습니다. 더 이상 말이 통하지 않을 것 같다는 느낌이 들었고 이후로는 말을 섞지 않았습니다.

결말​

결심이 굳어졌습니다. 이제 이직을 준비해야 합니다. 이번에는 데이터분석 직무를 줄 듯 말 듯 밀당하는 회사에 들어가지 않고 정확히 그 직무로 지원하려고 마음먹었습니다.

빠른 이직을 하기 위해 스타트업을 알아봤습니다. 그 중 하나를 찾았는데 이전부터 관심있는 도메인인 헬스케어 관련 스타트업이었습니다. 그래도 면접에서 첫 회사를 다니며 해 온 실무들 덕에 자신있게 말할 수 있었습니다.

면접 결과가 나왔고 인수인계 때문에 2주 뒤 출근하기로 했습니다. 바로 대표님에게 이야기했는데 대표님은 무경력에 취업시켜줬는데 배은망덕하다며 화를 냈고 온갖 충고를 보태 한참 이야기 했습니다.

사실 공장자동화 plc 엔지니어였기에 IT 분야에서는 무경력이었고 나이도 있는 나를 취업시켜줬던 것은 정말 감사했던 일이긴 합니다. 하지만 그 외에 다른 행동은 나한테 미안해 하셨으면 했지만 전혀 그럴 분이 아니었습니다.

마지막이다 생각하고 충고들과 저주 섞인 말들을 들어주자 갑자기 나중에 힘들 때 연락하라며 급 따뜻한 마무리를 하셨습니다. 그렇게 인수인계 기간 2주를 가진 뒤 다음 스타트업으로 이직을 하게 됐습니다.

30살이 되던 해 회사를 나와 국비지원 교육과정을 들으면서 겪었던 일들입니다.

지원​

프로그래밍 관련 교육 과정은 아주 많았습니다. 돈을 내고 다니는 학원 과정도 있었고 국비지원과정, 아니면 석사 과정을 밟을 수도 있었습니다. 하지만 직업을 잃은 상황에 돈 드는 걸 하는 건 리스크라고 생각했고, 그래서 결국 국비지원과정을 듣기로 결정했습니다.

IT 관련 국비지원과정은 웹개발과정과 머신러닝교육과정, IOT 교육과정 이렇게 3가지가 트렌드였습니다. 당시 뉴스에서도 이슈가 많이 되고 있었고 가장 멋있어 보였던 직업인 데이터사이언티스트가 되려면 머신러닝교육과정을 듣고 싶었는데 메이저 교육 기관들은 경쟁률이 거의 취업 경쟁률 같이 높아서 그 경쟁에서 면접에 가면 나이도 있고 이전 직장 일과 다른 분야를 도전하는 걸 그리 좋아하지 않았기 때문에 계속 지원은 했지만 떨어졌었습니다.

메이저 교육 기관에서 많이 떨어지고 나니 상반기, 하반기 마다 열리는 교육과정 지원 가능 시간이 얼마 남지 않았고, 그래서 어딜 가든 내가 열심히 하는 만큼만 얻는거니 아직 밑바닥 실력의 나로서는 어딜 가도 이득이다라는 생각으로 최대한 사람이 안 몰려 보이는 곳으로 지원 했습니다. 그렇게 지원한 과정은 머신러닝 기반의 웹 프로그래밍 개발자 양성과정이었습니다.

국비로 지원하기 위해 내일배움카드를 등록하고 취업준비에 대한 자문을 형식적으로 받았습니다. 그 후 교육 기관에 면접을 봤고 면접 후 교육생 결정이 확인되고 자문해주는 곳에 등록해 국비를 지원 받을 수 있었습니다. 6개월 간 교육 과정에 참여했기 때문에 취업 공부를 할 수 있는 공식적인 기간이 생겨 마음이 조금은 편해졌습니다.

학창 시절에는 공부하는 것이 그렇게 싫었는데 사회 나오니 공식적으로 공부를 하는 시기가 얼마나 반가웠는지 모릅니다.

OT​

첫 날은 강사님의 이력에 대한 설명과 책 배분, 교육 과정에 대한 전반적인 설명으로 끝이 났습니다. 교육 기간 동안 웹 개발부터 머신러닝까지 모두 배울 수 있는 과정이었기 때문에 설레는 마음을 품고 있었습니다.

Java​

본격적으로 수업이 시작됐습니다. 처음 섹션은 java 언어에 대한 이해 였습니다. java를 사용하기 위해 eclipse editor를 이용했고 본격적으로 프로그래밍 공부를 시작하는 느낌에 좋았습니다.

java를 이용해 여러가지 미션들이 주어졌고 해당 미션들을 하나씩 수행해 갔습니다. 공부를 하다 보니 이전에 python를 공부하던 때 했던 것들을 java로 바꿔서 하는 느낌이었는데 java가 python 보다 코딩 시 많이 불편하구나 생각했습니다.

언어 공부를 하며 미션들을 수행하다 보니 적응이 늦거나 이해가 되지 않아 뒤쳐지는 분들이 생기기 시작했습니다. 그러면서 교육 일정대로 수업이 나가지 않게 되고 점점 늘어지기 시작했습니다.

이전에 공부했던 내용이 있어 쉽게 따라갈 수 있었기 때문에 꽤 오랜 시간 동안 언어의 기본 기능들을 가르쳐주시면서 연기되는 일정 동안 취업에 도움이 될까 싶어 정보처리기사 필기를 준비해 취득할 수 있었습니다.

Html, Css, Javascript​

언어의 기본 기능들을 공부하고 웹 개발을 위한 html, css에 대해 교육이 시작됐습니다. html 태그들의 종류와 css 사용 방법들에 대해 듣다 보니 암기과목처럼 알아야 할 게 너무 많았습니다.

언제 다 이해해서 언제 다 제대로 사용하나 걱정했지만 각각의 사용법과 내용은 생각하던 것보다 아주 간단했습니다. 단순히 외우는 것이 문제였는데 사실 외우면 좋지만 외우지 않아도 필요한 것을 검색해 사용하다 보면 사용할 수 있었고 이것이 코딩의 원리임을 나중에 알게 됐습니다. 검색하기도 매우 간단했고 설명도 자세히 찾을 수 있었습니다.

javascript는 언어에 대한 교육을 따로 하기 보다는 html, css 상에서 동적 구성이 필요한 부분을 어떻게 불러오고 어떻게 다루는지에 대한 내용만 간략히 배웠습니다. 그 당시에는 jQuery를 사용해 간단하게 컨트롤할 수 있었습니다.

1차 팀 프로젝트​

java, html, css, javascript를 배우고 자유주제에 웹싸이트 개발 팀 프로젝트가 진행됐습니다. 팀 구성은 잘하는 사람을 한 명 씩 배정하고 못하는 사람을 팀에 한 명 씩 배정한 뒤 나머지는 랜덤으로 배정돼 정해졌습니다.

잘하는 사람들에게 배우고 싶었지만 생각과 달리 잘하는 사람들이 찢어져 같은 팀에서는 내가 교육해줘야 하는 상황에 처했습니다. 자연스럽게 팀장이 됐고 어떤 주제로 개발을 할지 같이 브레인스토밍을 거쳐 팀원들이 모두 관심이 많은 건강관리에 대한 웹을 개발하기로 했습니다. 이름도 느낌있게 퀄리티 있는 헬스케어라고 해서 퀄스케어라고 지었습니다.

우리팀에 나이가 있는 분들이 좀 있었기도 했고 당시 헬스케어 앱으로 많이 쓰던 나이키앱, 삼성헬스 등의 기능이 만족스럽지 못한 상황이었습니다. 그래서 우리 앱은 목표로 하는 근육량과, 체지방률, 목표체중 그리고 D-Day를 설정해 하루 먹어야 할 적정한 칼로리와 운동량을 계산해 식단, 운동을 직접 등록해 목표가 지켜질 수 있게 돕는 헬스케어 앱이었습니다.

우선 네이버에서 음식별 칼로리와 영양소 데이터를 가져왔고 운동별 시간에 따른 칼로리 소모 데이터를 가져왔습니다. 목표 체중과 디데이를 설정한 뒤 매일 매일 오늘 먹을 식단과 운동을 등록하면 목표로 해야 하는 칼로리와 운동량을 보여주고 목표에 맞게 각각을 체우거나 비워내서 목표를 이룰 수 있게 돕는 방식입니다. 그렇게 건강관리 웹(퀄스케어)가 완성됐습니다.

물론 본인의 신체나이, 체지방률, 키, 몸무게 등을 직접 입력해야 하고 근육량에 의해 체중이 늘어나는 것에 대한 고려를 하지 못하는 등 많은 한계가 있었습니다. 하지만 팀장으로서 팀 간의 의견 조율을 해내고 기획에 반영해 가며 개발 과정과 일정을 산출하며 업무를 조율하면서 웹앱을 완성할 수 있었고, 매우 보람찬 시간이었습니다.

데이터 시각화​

팀 프로젝트가 마무리되고 되돌아 보니 팀 내에서 개발에 제대로 동참하지 못한 인원들이 많았습니다. 그 인원들은 그 동안 배운 내용을 복습하는 시간을 가졌고 선생님도 복습을 도왔습니다.

어수선한 분위기에서 머신러닝 교육이 시작됐습니다. 처음에는 R을 활용해 라이브러리를 블러와 학원에서 준비한 csv 데이터를 이용해 시각화하는 작업을 배웠습니다. 그리고 python으로 R로 진행했던 시각화 내용을 똑같이 다시 재현했습니다.

그렇게 시각화 수업이 끝난 뒤 선생님은 못 따라온 학생들이 너무 많고 어차피 제대로 가르치려면 과정 내 시간이 부족하다며 남은 과정들은 진행하지 않는다고 했고 그렇게 머신러닝 교육은 마무리 됐습니다.

하지만 수업을 따라가는 내내 수업이 지연될 때마다 독학해 오던 버릇이 있어서 남는 시간이 생길 때마다 웹 서비스에 머신러닝 서비스를 도입해 볼 수 있도록 틈틈히 독학해 나갔습니다.

Spring​

간단하게 jsp를 활용해 웹 개발을 해왔는데 웹 프레임워크인 spring을 활용하는 마지막 과정이 남았습니다. spring을 활용해 게시판을 만들어 보는 수업이었고 선생님이 만들어 주신 스크립트를 복습해 가며 eclips부터 spring sts 를 적용하고 서블릿, XML에 등록해서 게시판을 겨우 만들었던 기억이 있습니다.

당시 python으로 독학을 따로 하던 중이었어서 java를 배우던 기억은 좋지 않았습니다. 같은 개발을 하더라도 코딩을 훨씬 많이 해줘야 했고 셋팅까지 참 불편한 언어였습니다.

2차 팀 프로젝트​

2차로 시작된 팀 프로젝트는 교육 수강을 포기하고 나간 인원들이 많았기 때문에 인원이 얼마 남지 않아 2팀으로 나누어 개발을 했는데 갑자기 젋은 인원으로 팀이 구성됐습니다. 팀원들은 모두 동생이었는데 모두 롤이라는 게임에 빠져 있었고 결국 롤 관련 서비스로 가닥이 잡혔습니다.

당시 단순하게 전적을 조회할 수 있는 서비스는 많이 있었지만 롤을 매일 즐기고 있는 사람들에게는 부족했습니다. 그래서 추가 기능을 생각하게 됐습니다.

• 전적 검색
• 대회 기능
• 승패 예측 기능(+ 통계 기능)
• 커뮤니티 기능
• 챗봇 기능

기본적으로 로그인과 회원가입을 구성했고 어느 싸이트에나 있는 전적 조회 기능을 구현해야 했습니다. riot game 에서 제공하는 검색해 보니 developer 싸이트의 데이터 api가 있었기에 전적 데이터, 챔피언, 아이템 등 많은 데이터들을 수집해 올 수 있었습니다. 수집된 데이터들을 특성에 따라 분류하여 저장했습니다. 그런 뒤 전적 조회 시마다 최신 업데이트를 위한 로직 등을 설계하고 프론트엔드를 개발해 구현했습니다.

대회 기능은 로그인된 사용자만 가능한 프로세스였는데 대회를 만들고 위치와 상금, 팀인원을 정했고 대회에 참가하기 위해서는 만들어진 상금에 따라 아임포트 모듈을 이용해 결제하는 방식이었습니다. 결제가 완료되면 약속된 시간과 위치에 모여 피씨방 대회등을 할 수 있게 구글맵의 길찾기가 지원됐습니다. 그렇게 대회 참가 팀인원이 다 모이면 대회의 경과를 볼 수 있는 페이지가 있어 참가자들이 경과를 알 수 있게 구현했습니다.

하지만 누가 이겼는지에 대해 알 수 있는 방법에 대해서 연구되지 않아 수동으로 설정해서 경과를 표시해야 했고 결제된 금액도 누구한테 어떻게 보내줘야 할지도 수동으로 보내야 하는 등 많은 한계가 존재하는 기능이었습니다. 아쉬운 기능이긴 했지만 그래도 있으면 좋겠다는 기능이 화면에 표현은 됐어서 다들 뿌듯했던 기억이 있습니다.

승패 예측 기능은 화면에서 챔피언과 사용 장비를 입력 받으면 그걸 이용해 최신 전적 데이터를 불러왔고 불러온 데이터를 전처리해 tensorflow 를 활용한 승패예측을 해주는 기능입니다. 더해서 승패 예측에서 사용된 모델의 정확도와 오차에 대해 트레이닝 당시의 데이터를 그래프로 보여주고 부가적으로 아이템과 챔피언, 능력치들 간의 상관관계에 대한 통계 데이터, 챔피언과 아이템 간의 관계, 챔피언과 데미지 입히는 것과의 관계 등 많은 부가 통계 데이터들을 제공했습니다.

다른 많은 작업들이 있어 급하게 만들었기 때문에 모델에 대해 심도있게 고민해서 만들지는 못했지만 그래도 머신러닝을 적용했다는 생각해 뿌듯했습니다. 나중에 선생님께서도 가르쳐주지 않은 flask, tensorflow, pandas 등 많은 라이브러리를 활용해 해당 부분이 적용된 것을 보고 팀 프로젝트에 대한 좋은 평가를 주셨습니다.

그리고 java spring 수업 시간에 배웠던 게시판, 댓글, 대댓글 기능을 구현해 단순한 커뮤니티 기능을 추가했습니다. 마지막 프로젝트였던 만큼 욕심이 생겼습니다. 그래서 당시 유행이던 챗봇을 구현해 보고 싶어 chatterbot 라이브러리를 활용해 영문 챗봇을 구현해 봤고 구글에서 제공하는 dialogflow를 활용해 시나리오 기반의 한글 챗봇도 구현해 봤습니다.

학원을 다니면서 팀 프로젝트 때 열심히 하는 사람과 안 하는 사람, 모르는 사람, 나갈 사람 등 많은 팀원들과 소통하며 그래도 끝내 잘 마무리 해가는 it 회사의 간접 경험을 해보는 것 같아 보람있는 시간들이었고 많은 경험들과 함께 무사히 League of legend 웹 을 잘 완성할 수 있었습니다.

마무리하며​

학원을 다니며 기획하고 ui도 설계하고 erd툴을 활용해 데이터베이스도 설계해 보고 팀원들과 프로젝트도 진행해 보는 등 꽤 많은 경험들을 하다보니 순식간에 6개월이 지나갔습니다. 6개월 간 6시에 일어나 2시간을 대중교통을 갈아타며 저녁 6시까지 수업을 듣고 집에 2시간 걸려 돌아와 저녁 먹고 12시까지 공부하는 온 종일 개발만 하던 생활이었습니다. 여러 프로젝트를 진행하고 쉴 새 없이 개발에 몰두할 수 있어 좋았고 덕분에 취업에 대한 자신감이 생겼습니다.

지금은 폰에 번호가 다 날아가서 선생님, 학우들과 연락할 수 없지만 가끔씩 그 시절이 생각날 때가 있습니다. 이제 재밌는 시간은 지났고 다시 직장생활 생존기가 시작됩니다.

2015년에 입사해 3년 동안 다닌 외국계 회사에 대한 이야기입니다.

면접​

여러 준비를 하며 it 분야로의 직종 변경을 생각하며 지내던 중 갑자기 업데이트 해 놓은 이력서를 보고 헤드헌터로부터 연락이 왔습니다.

외국계 회사에 탄탄한 재무 상태면서 현재 집에서도 가까운 위치의 회사였습니다. 당시 선배들한테 들었던 다닐만한 회사의 조건이 있었습니다. 인당 10억을 넘기는 매출액을 가진 회사를 가야 연봉을 많이 받는다고 들었었는데, 이것을 충족하는 회사였습니다.

직종 변경을 하고 싶은 마음이 아직 있었지만 주변(가족, 친구 등)의 깊은 걱정과 취업 압박이 있었고, 외국계 회사라면 이전에 정했던 목표 중 하나로 경험해 보고 싶은 회사였기 때문에 지원해 보기로 했습니다. 떨리는 마음으로 영어 자기소개를 준비하고 그 간 해 온 일들을 정리해 가며 부족한 부분들을 공부해 나갔고, 마지막으로 업데이트 된 이력서까지 숙지하여 준비를 마쳤습니다.

드디어 면접 당일 ☀️, 떨리는 마음으로 회사에 도착했습니다. 회사의 첫 인상은 조립식 판넬 같은 가 건물로 지어져 있었고, 넓은 주차 공간에 주차를 한 뒤 건물로 들어갔습니다.

면접을 보러 왔다고 말하자 덩치 있는 두 분이 나타나 구석에 있는 테이블로 날 데려갔습니다. 두 분은 입사 후 알게 되지만 소속되게 될 팀의 팀장과 선임대리였습니다.

공장 자동화에 대한 경험은 있는지? PLC 를 얼마나 다뤄 봤는지? 등등 실무경험에 대한 질문이 쏟아졌습니다. 다행히 Simens 계열의 공장자동화 소프트웨어는 모두 내가 해 온 일이고 잘 아는 부분이기 때문에 자신있게 실무를 할 수 있음을 말할 수 있었습니다.

하지만 이전 회사 경력이 너무 짧아 바로 업무를 잘 할 수 있는 상태인데도 경력은 인정되지 않았습니다. 그리고 짧은 회사 생활 때문에 뽑기를 망설이는 모습도 보여서 말하지 말 걸 그랬나 생각했습니다. 그래도 이직 이유를 낮은 연봉 때문이라는 이유를 분명히 밝혔고 군 시절 경험과 여러 역경을 이겨낸 일들을 제시하며 원래 잘 버티고 인내심 있는 사람임을 어필했습니다.

면접이 마무리될 쯤 언제부터 출근할 수 있는지 물었고 괜히 잘 보이고 싶었던 나는 당장이라도 가능하다고 말했는데 금요일에 면접을 보고 월요일이 입사일이 됐습니다.

입사일​

입사 후 자리를 배정받았는데 자리에 착석하자마자 면접 때의 존대하는 분위기와 달리 팀장과 선임들이 말 편하게 해도 되지? 라고 말하며 바로 말을 편히 하기 시작했습니다. 친근한 분위기 속에서 팀장은 빠르게 업무 소개를 했고 다음주부터 현장에서 실무 투입 될 예정이니 잘 숙지하고 있으라며 책 두께의 프린트를 여러 개 전달했습니다.

그리고 멀리 선임들과 대화하는 소리가 들려 왔는데, 너무 바로 보내는 거 아니냐? 그러다 나간다, 실무에 투입되고 나서 힘들게 일해 봐야 회사에 남아 있을 사람인지 아닌지를 알 수 있다고 일종의 테스트인 것처럼 말하고 있었습니다. 면접 때 말한 것처럼 당시의 나는 열정이 가득했고 아무리 힘든 일이 있어도 내 능력을 키우는 계기로 삼고 포기하지 않겠다 생각했습니다.

식사 시간이 됐고 같은 팀원들끼리 식사를 같이 했는데, 식사를 같이 하러 간 팀원은 팀장과 면접 때 봤던 선임대리 둘 뿐이었습니다. 같은 회사의 다른 팀들도 물론 같은 시간대에 식사하기 때문에 식사하는 장면들을 봤었는데 선임이 먼저 자리에 앉으면 후임이 자리에 앉고 선임이 자리에 못 앉을 경우 후임이 다른 자리에 가서 앉아 먹는 등 군대생활을 연상케 하는 모습이 보였습니다.

수평적인 관계일 거라 예상했던 외국계 회사였는데 수직적인 관계라는 것에 좀 실망스러웠습니다.

첫 일주일​

당시 회사의 업무 방식은 프로젝트가 많지 않아서 그랬는지 선임대리급이 한 명 프로젝트 고문으로 가 있고 거기에 신입 또는 후임이 배정되서 프로젝트 실무를 담당해 마무리 짓는 방식이었습니다.

SK인천석유화학 공장에서 나오는 VOC(Volatile Organic Compounds)를 처리하는 RTO(Regenerative Thermal Oxidizer)장비를 설치하고 기대한 만큼 VOC를 잘 처리하며 좋은 효율로 운전되도록 하는 것이 관건이었습니다.

츨발하기 전 1주일 동안 다른 선임들과도 같이 식사를 하며 회사 전반에 대한 이야기들을 듣게 됐는데, 선임과 후임이 같이 배정되서 프로젝트가 진행되는데 그 곳에 내가 배정된 이유는 이전 후임이 퇴사했기 때문이라는 것과 그 선임분이 악명이 높다는 것, 꽤 여러차례 후임을 나가게 만든 분(이후 악덕선임이라고 지칭함)이라는 것이었습니다.

하지만 군대 생활 때도 이상한 사람 많았고 악덕한 사람 있었지만 잘 지냈었기 때문에 자신감이 있었습니다. 같은 일에 있어서 느끼는 바도 서로 다 다를 수 있고 사람간의 관계도 같은 사람이어도 사람마다 다른 관계가 형성된다고 생각했기 때문에 대수롭지 생각하려 노력했고 열심히 일 할 마음으로 업무를 숙지해 나갔습니다.

금요일, 악덕선임이 등장했고 갑자기 업무용 트럭에 실어야 할 부품과 공구 리스트를 말하더니 실어 놓으라고 명령했고 월요일부터 인천으로 가야 하니 새벽 6시까지 회사로 출근하면 회사 차로 같이 이동한다고 말을 남기고 퇴근해 버렸습니다.

처음 듣는 부품, 공구들을 말로 대충 말하고 가서 찾는 일이 힘든 상태였고 다른 팀 선임들한테 질문해 가며 부품과 공구를 차에 실은 뒤 퇴근했습니다.

첫 실무​

다음 날 새벽 6시 출근하니 아무도 없었습니다. 출발하기 전 물품들을 한번 더 점검하고 기다리다 보니 30분이 지나 악덕선임이 왔고 어제 말한 걸 잘 챙겼냐고 못 챙겼기만 해보라며 화를 내고 인천으로 출발했습니다.

인천까지 가는 길은 아침이라 막히지는 않았지만 그래도 1시간이 걸렸고 선임은 온풍기를 틀고 옆에서 잠들었는데 본인이 춥다며 창문을 못 열게 해 졸음을 겨우 참아가며 가까스로 인천에 도착했습니다.

도착하자마자 SK인천석유화학의 출입 과정을 바로 실행하며 진행했고 짐 수레에 짐을 끌어가며 공장 내 사무실까지 옴겼습니다. 사무실에 도착해 짐을 정 위치에 둔 뒤 악덕선임은 잠을 못 잤다며 누구 오면 부르라더니 갑자기 잠을 자기 시작했습니다.

30분 정도 지나자 아침 체조를 해야 한다며 나오라고 사람이 왔고 선임과 함께 나가 보니 공장에서 일하는 사람들이 줄 서 있었고, 선임과 나는 사람들과 함께 아침 운동을 했습니다. 군대 이후로 간만에 하는 단체 아침 운동이라 신기했습니다. 아침 운동이 끝나고 본격 공장에서의 업무가 시작됐습니다.

악덕선임은 우리 장비가 설치된 곳과 담당자분을 소개해 주고는 거의 다 했으니 시공을 잘 마무리 해 보라며 다시 사무실에 들어가 잠을 잤습니다. 전기선을 끌어다 판넬에 연결하고 PLC 접점에 배선하는 배선공 아저씨들이 하는 일을 해야 했는데 PLC 프로그래밍만 하다가 처음 보는 설계 도면을 보며 배선공의 일을 배우고, 배선공 아저씨들에게 도면을 보며 배선을 똑바로 했는지 질문해 가며, 관리 감독을 시작하게 됐습니다.

시간이 지나 계장품들의 메뉴얼 문서와 설계 도면들을 보며 업무를 완전히 파악했고, 아저씨들에게 배선 방법을 가이드하고 일하는 아저씨들이 힘들다고 투정 부리면 완급조절을 하며 일을 진행했습니다.

매일 일일 업무 일지, 시공 계획, 설계 자료 등 많은 서류들을 작성해서 대기업 담당자에게 확인받는 절차를 거치고 회의실에 가서 시공 현황에 대해 회의도 하며 지내게 됐습니다.

어느 날은 악덕선임이 서류를 대충 제출해서 담당자의 심기를 건드려 담당자가 이 공장에서 나가라며 하이바 던져 가며 성질내며 실제 공사가 연기되는 날도 생겼고, 안전팀, 감사팀 등이 감시하다 맘에 들지 않는 행동을 하면 그 날의 프로젝트 일정이 연기되기도 했습니다.

그 밖에도 배선공, 기계공 등 외주 아저씨들을 인솔하며 업무 지시를 하는데 술을 많이 먹어 일을 못하는 등의 문제로 인력이 줄어들기도 하며 업무 지시를 잘못 이행하거나 가이드를 안 듣고 하고 싶은대로 이행하며 다시 일을 해야 하는 등의 일들이 반복됐습니다. 그 와중에 나는 신입이었기 때문에 더욱 무시 당하고 잘 알지도 못하고 악덕선임은 화만 내고 잠만 자는 상황이 반복됐습니다.

이전 후임들이 왜 못 버티고 나갔는지를 체감했고, 결국은 선임에게 기대감을 1도 갖지 말고 오직 내 스스로 모든 문제를 해결해야 겠구나라고 마음 먹으니 차라이 마음이 편해졌습니다.

시공​

장비가 공장에 설치되기 위해서는 아주 많은 절차와 인력이 필요 했습니다. 하지만 적은 인력으로 큰 프로젝트를 진행하던 회사였어서 실무진 중 기계팀 1명, 전기팀 1명 만을 배치하고 일을 마무리 하게 했습니다. (물론 선임 1명과 같이 배치되지만 그 선임은 회의만 가끔 나가고 실무, 서류 작업을 전혀 하지 않아 회의 때 발언없이 내용만 듣고와 전달하는 업무 정도였습니다.)

우선 공장 관리 담당자들과 모여 장비에 대한 소개와 간단한 시공 계획을 말하고 실제 설치되어야 할 위치에 대해 논의하고 장비 설치를 위한 시공, 운반 계획을 해야 합니다. 또한 논의된 설치 위치와 공장 내 프로세스를 눈으로 파악하고 배관의 사이즈, 환경 상황들의 스펙들을 파악해 장비 설치를 위한 환경을 검토했습니다.

검토가 끝나면 실제 장비를 설치하기 위해 들어올 중장비들의 위치와 경로를 파악하고 시공의 모든 시뮬레이션들이 충족되는 위치를 정합니다. 장비를 설치하기로 정해진 위치에 대해 한번 더 공장 관리 담당자들과 논의하고 시공 기획, 설계 자료와 스펙을 이야기한 뒤 실제 업무가 시작됩니다.

업무가 본격 시작되면 매일 설계된 스펙 자료와 시공계획, 인력들이 왜 필요한지부터 뭘 했는지 까지 많은 서류들을 확인하고 그것에 대해 공장 관리 담당자들과 논의를 거치는 일을 계속 진행하게 됩니다. 그러면서도 다른 일을 해야 하는데 비, 눈을 대비해 실제 설치될 위치의 지대를 콘크리트로 높이고 중장비들과 설치 인력들을 소집해 시공을 진행합니다. 설치 인력들을 관리하며 설계대로 설치했는지 만들어온 장비가 스펙에 맞는지 검수하고 중장비 이용 계획, 세세한 설치 방식을 구상합니다.

이렇게 문제없이 장비의 겉이 잘 설치되고 나면 기계팀은 철수하고 기계팀의 보조를 하고 있던 전기제어기술팀의 업무가 본격적으로 시작됩니다. 배관이 연결되어 있는 고철덩어리일 뿐인 장비에 팬, 버너, 판넬, 각 종 센서 등의 전기 계장품들을 설치하고 이를 판넬 내에 PLC 와 연결하는 작업을 진행합니다. 물론 각각의 계장품들의 성능 테스트 자료부터 스펙, 메뉴얼 자료 그리고 검수들까지 선 진행되어야 하고 배선공 아저씨들을 소집해 이를 완성해 가야 합니다.

전기 설치까지 모두 완료되고 나면 프로그래밍된 PLC 소프트웨어를 하드웨어에 입혀주고 이제 본격적으로 현장 동작들을 하나씩 확인해 나갑니다. 각 동작이 정상적으로 이뤄지면 시운전을 위해 팬을 가동시키고 실제 공장 배기 가스가 아닌 바깥 공기를 활용해 RTO를 가동하고 버너가 현재 배합된 공기로 스파크를 튀겨 불이 정상 연소되는지 연료와 공기의 배합을 테스트 합니다.

불꽃의 색, 연료량, 팬 동작 등을 체크하며 최적의 상태를 만들고 나면 불을 실제로 높여 850도까지 온도를 높이고 모든 센서들과 프로세스들이 설계된 대로 흘러가는지 얼마나 효율적인지 체크해 다시 최적의 상태를 만들게 됩니다.

가장 힘들고 고된 초기 시운전 작업이 끝나면 본격적으로 공장 프로세스를 거쳐서 온 처리해야 할 공기로 다시 시운전을 진행합니다. 공장의 공기는 많은 VOC를 머금고 있기 때문에 VOC를 연료 삼아 화력이 올라가 공기와 연료의 배합을 잘해야 하고 잘못하면 온도가 1000도를 넘어서 기계 장비 스펙에서 버틸 수 없는 온도까지 순식간에 도달할 수 있기 때문에 긴장되는 순간들입니다.

그렇게 공장 내 VOC센서들과 실제 RTO 동작에 대한 동작 계수 값들을 조금씩 변경하며 최적의 상태를 만들고 나면 시운전이 종료됩니다.

며칠 밤을 새가며 시운전이 끝나면 거의 하루정도 지나서 실제 운전이 시작되는데 1주일 간은 대기하며 즉각 대응해주며 안정기를 갖습니다. 그 전에 고생하고 제대로 일을 마무리 했다면 이 1주일은 나름대로 잠깐씩 출근했다가 근처 모텔에서 쉬면서 대기하는 기간이 될 수 있습니다. 회사에서도 고생한 걸 알아서 이 때 좀 더 놀다오라고 하거나 기간을 더 주고 쉬게 해주는 경우도 있습니다.

회사별, 직역별, 상황별로 프로젝트는 약간씩은 다르게 진행되기는 대부분의 시공 프로세스는 위와 같이 진행됐습니다.

전기 배선 설계​

많은 프로젝트들을 거치면서 판넬 도면은 업무 지시를 하는 입장에서 완전히 이해해야 했기 때문에 지속적으로 숙지했고 나중에는 거의 외울 정도로 내용이 숙지됐습니다.

도면 내에 계장품들이 무슨 역할을 하는지부터 판넬을 구성하는 패턴들, 전기 설계 방식들이 익숙해지자 당시 회사에서 한 명만 EPLAN 프로그램을 이용할 줄 알아서 도면을 설계하고 있었는데 그 선임이 도면 설계를 해보라며 가르쳐줬습니다. 친절한 가르침과 그 동안의 프로젝트 경험 덕에 생각보다 이해가 쉬웠습니다.

설계도에 나오는 수 많은 계장품들의 spec 문서를 확인하고 설계한 뒤 실제 판넬 제작 시 설계도와 실제 배선 상태를 눈으로 확인하고 접점 테스트해 가며 판넬 검수를 통해 내 설계대로 됐음을 확인했습니다. 지속적으로 공부하고 직접 실무로 설계하다 보니 익숙해 졌고 할 수 있는 일이 됐습니다.

이후로 모든 프로젝트의 도면 설계는 그 선임분과 내가 나누어서 설계 단계에 일을 맡게 됐습니다.

PLC 엔지니어​

외국계 회사에서 고연봉을 받는 즐거움도 있지만 PLC 엔지니어로서 좀 더 배우고 성장하고 싶었습니다. 하지만 오스트리아 본사에서 프로그래머들이 전달해 준 내용과 거의 변경없이 사용하고 있었습니다. PLC 로직 상에서 뭔가를 변경하진 않고 HMI에서 환경 셋팅을 변경하거나 PLC 로직을 아주 조금 변경하거나 하는 미니멀한 커스터마이징이 전부였습니다. 심지어는 Siemens 소프트웨어 설치부터 PLC 내에 저장되는 데이터가 어디있는지 어떻게 다룰 수 있는지까지 회사 내에 제대로 아는 사람이 없었습니다.

다행히 여기서도 이전 회사에서 배웠던 Simens의 Step7, WinCC 를 주로 사용했기 때문에 설계된 내용과 설계 내용을 환경에 맞게 커스터마이징 하는 것은 그리 어렵지 않았습니다. 하지만 SK인천석유화학은 Allen Bradley 사의 RSLOGIX5000, FactoryView를 사용해 어려움을 겪었지만 이 또한 오스트리아 본사에서 기본 셋을 주기 때문에 파악해 사용할 수 있었습니다.

설계된 내용을 보며 장비 프로세스에 대해 좀 더 깊숙히 알 수 있었던 기억이 있습니다. 프로그램을 통해 공장 장비들을 구동하고 원하는 프로세스로 수정하며 그 동작들을 보는 경험은 아주 재미있는 경험이었습니다.

하지만 회사에서 판매하는 장비는 몇 개 없었고 연구 개발 부서도 따로 없었기에 더 늘어날 일도 없었습니다. 그리고 공장 특성상 석.박사들이 만들어 놓은 화학 프로세스는 정해져 있고 이에 맞춰서 만들어진 프로그램 개발이 크게 달라지기는 힘들었습니다. 고객사마다 약간의 환경차이에 의해 수정되고 버전업되는 소프트웨어 적용 정도의 일을 맡아 하게 됐고 시운전을 위해서는 내가 모든 프로젝트에 고문처럼 등장하게 되고 할 수 있는 일이 많아졌지만 항상 비슷한 일을 하기에 실력은 더 늘수 없어 고민에 빠졌습니다.

P&ID 설계​

P&ID(공정관계장도)는 기계적 설치상태와 전기적 제어 장치의 공정 시의 상세한 프로세스를 살피기 위한 흐름도로서 이 흐름도에 환경장비의 화학적 프로세스가 담겨져 있었습니다. 이걸 그리는 것은 팀장급이었지만 사실 이 또한 오스트리아 본사측에서 제공한 자료를 거의 그대로 사용했고 약간씩 커스터마이징하며 사용 했습니다.

물론 화학 공학 석.박사가 아니기 때문에 새로운 화학적 프로세스를 만들어 새로운 장비 프로세스 기획을 할 수는 없었습니다.

하지만 현재 이미 숙지한 장비의 P&ID는 공장 상황에 맞게 계장품과 배관 등의 설계를 어느정도 화학적 프로세스에 맞게 수정할 수 있었습니다. 그래서 프로젝트를 할 수는 있었지만 이 역시 본질적인 능력을 키울 방법이 없다는 생각이 들었습니다.

이직 결심​

많은 일들을 배우고 겪다 보니 어느새 4년차가 됐습니다. 연봉은 친구들에 비해 자신있게 말할 만큼 많이 받았기 때문에 씀씀이 또한 커졌습니다. 하지만 알고 있었습니다. 나의 전문성은 이 회사에서만 통할 수 있고 언젠가 이 회사가 무너지면 나도 무너질 것을.

회사가 불안정하거나 그랬던 건 아니었습니다. 재정이 꽤나 탄탄한 회사였고 정년도 보장해주는 회사였습니다. 그러나 성장할 수 없다는 생각에 좌절감이 들었습니다.

빠르게 성장하고 스스로 일하거나 집에 혼자 있어도 날 성장시킬 수 있는 그런 일이 있었으면 했습니다. 회사에서 내 성장을 규제하는 분야가 아닌 내가 성장하려 하면 얼마든지 계속 성장할 수 있는 분야. 일을 하면서도 그 모든 게 내 스펙이 되는 분야, 이 회사에 취업하기 전 내가 가고 싶었던 분야 였습니다.

그렇게 내가 가고 싶던 분야를 지금이라도 가고 싶어졌습니다. 더 늦으면 도전도 못해 볼 거란 조바심이 들기 시작했고 이 회사에서 내가 살아남으려면 위 사람들처럼 정치하고 후임이 한 일을 자기가 한 일처럼 공을 뺏으며 충성 경쟁하며 능력은 점점 없어져 가는 나를 상상하기 싫었습니다.

스스로 떳떳하게 내 능력으로 회사에 도움이 되고 반복적인 회사 일이 아니더라도 나만의 뭔가를 만들고 도전해볼 수 있는 분야로 가겠다고 결심했습니다.

만류​

퇴사를 결심하고 직종 전환하겠다는 생각을 밝히자 주변의 모두가 격렬히 반대했습니다. 이번 반대는 사실 설득력까지 있었습니다. 현재를 유지한다면 고연봉이 유지될 거고 탄탄했던 회사인 만큼 정년이 보장될 수도 있는데다가 집에서도 거리가 10분 거리에 회사가 잘 안되도 비슷한 분야로 취업할 수 있었기 때문입니다. 물론 내 능력이 급격히 늘거나 성장할 수 없고 회사에 속하지 않으면 혼자 사업을 할 수 있는 분야는 아니지만 말입니다.

현재를 유지하지 않고 내가 선택한 분야로 도전한다면 이미 30살이 된 늦은 시작에 대한 중압감과 평생 열심히 공부하고 경쟁 속에서 일해야 하며 연봉도 급격히 줄어들 것이 분명했습니다. 하지만 성장하고자 한다면 회사와 상관없이 언제나 성장할 수 있고 이 분야 보다는 수평적인 분위기에 사업이나 디지털노마드가 될 수도 있는 분야 소프트웨어 엔지니어로 전향하기로 했습니다.

어른들과 주변 친구들 모두 강력히 반대했고 현실적으로 얼마나 손해인지를 지속적으로 이야기 했습니다. 하지만 나는 꿈을 꾸고 있었고, 소프트웨어 엔지니어에 대한 동경, 수평적 분위기, 그리고 스스로 성장할 수 있다는 무한한 가능성에 주목했고 결국 직종 전환을 선택 했습니다.

퇴사 계획​

퇴사 후 직종 전환을 할 계획이었기 때문에 회사를 다니며 미리 python을 공부했고 IT회사들의 지원자격을 살피고 인사담당자분들께 메일을 보내 궁금한 사항들도 질문했습니다. 신입으로 지원해 본 많은 회사들도 있었지만 IT 관련 경험이 한 줄도 없는 나의 손을 잡아준 회사는 없었습니다.

지금 분야에서 떳떳하게 할 수 있는 일이 있듯 내가 이력서에 쓸 수 있고 면접에서 자신있게 말할 능력이 필요 했습니다. 그래서 국비지원교육을 찾아보게 됐고 메이저 교육 기관들에 지원했지만 교육 기관에서조차 IT 무경험자들을 탈락시켰기 때문에 결국 사람이 부족해 보이는 교육 기관에 지원해 합격할 수 있었습니다.

그렇게 합격한 교육 기관의 일정에 맞춰 회사일을 인수인계하며 원하는 시기에 정든 회사와 이별할 수 있었습니다.

2014년 9월 첫 회사에 입사해 그 해 12월까지 겪었던 아직은 대학생이었던 시절 이야기입니다.

면접​

이력서 작성도 면접도 모두 처음이던 그 시절, 한번 작성해 본 이력서가 쉽게 통과 됐고 생각보다 빨리 면접을 보게 됐습니다.

대학 시절 그나마 가장 흥미를 느꼈던 자동 제어 분야로 취업하고자 했는데, 자동 제어 분야 중 하나인 공장 자동화 분야로 취업을 하게 되어 설레는 마음이었습니다.

면접 날 질문은 자기소개 1분, 관련 경험, 지원동기 3가지였는데, 첫번째 자기소개에서는 성장 과정과 대학 시절 흥미를 느꼈던 자동 제어 수업에서의 프로젝트 경험을 이야기했고 대학 시절 영어 멘토 경험을 이야기 하며 실무에서 영어가 문제가 되지 않음을 어필했습니다.

관련 경험으로는 아버지가 사업을 하셔서 공장에서 가끔 일을 도운 적이 있어 공장이 친숙하다는 것과 면접 전 실무 수행 능력을 기르기 위해 PLC 툴을 미리 독학한 일을 말했습니다.

지원동기로는 대학시절 자동제어 수업 때 설계한 대로 하드웨어가 움직이는 것에 흥미를 느꼈었고 공장 자동화 분야에 꼭 취업해 보람있는 일을 해보고 싶다고 강조했습니다.

입사일​

인생 첫 입사일, 밤잠을 설쳤지만 아주 일찍 일어났고 9시 출근이지만 8시에 회사에 도착해서 열정있는 신입인 것처럼 행동하려 했습니다.

하지만 직원들은 9시가 다 되서야 멀리서 천천히 걸어와 문을 열어 주었고 배정되어 있는 책상에 눈치껏 앉았습니다.

직원들은 대부분 9시가 넘어 출근했고 나처럼 굳어 보이는데 한껏 꾸미고 출근한 잘생긴 사람이 있었는데, 대화를 나눠보니 동기였습니다. 둘 다 첫 회사, 첫 출근이었습니다. 동기는 한살 어린 동생이었고 말이 잘 통해 금방 친해질 수 있었습니다.

선임들은 친절히 OT를 진행했고 간단한 회사 소개와 앞으로 진행될 교육에 대해 설명해 줬습니다.

교육​

PLC의 정의, 어떻게 사용되고 있는지, 회사에서 하게 될 일이 무엇인지 설명해 줬고 이후 실무에서 사용 중인 Simens사의 Step7, WinCC 툴을 셋팅하고 실제 교육용 하드웨어를 통해 제어해 보며 실무를 익혔습니다.

교육은 빠르게 끝났고, 이후 1주일 간 교육 내용을 반복 숙지하며 자기 것으로 만들었습니다. 교육을 해주던 선임은 교육 내용을 열심히 숙지하는 것을 보고는 다음 교육부터 신입 교육을 나에게 하도록 지시했습니다.

교육 내용을 완전히 숙지했었기 때문에 실무 경험에 대한 자신감도 생기고 직접 신입 교육을 하다 보니 더 자세히 알게 되면서 좋은 시너지가 있었습니다.

실무시작​

첫 교육이 끝날 무렵, 회사에서 진행중인 프로젝트에 신입을 각각 배정했고 동기는 SK하이닉스로, 나는 현대제철로 배정됐습니다.

9 to 6 근무였는데 현대제철 출장이 매일 이어졌고 출장갈 때마다 아침 7시에 출발해 운전하고 공장애 도착해 업무를 하고 나면 저녁 6시가 됐고 집에 운전해서 돌아오면 저녁 8시가 넘어 집에 도착하는 극악의 운전 지옥에 빠졌습니다. 심지어 동기는 그 시기에 출장간 곳의 선임들과 합숙에 들어갔다고 들었습니다.

현장에 갈 때마다 공장 사무실 바닥을 뜯고 통신 케이블을 직접 찍어 설치하거나, PLC 설치된 데스크탑과 모니터, 렉을 들고와 설치하는 등 PLC 외적인 업무가 주 업무가 되어 갔고 처음 교육을 듣고 열심히 실습하던 PLC 소프트웨어 개발과는 멀어졌습니다.

한번씩 사무실에 오면 새로 들어온 신입들에 대한 교육을 했고 이 시간이 PLC 업무를 실질적으로 하면서 성장할 수 있는 유일한 시간이었습니다.

매일 지속되는 현대제철로의 출장과 야근, 특히나 겨울철에는 운전해서 갈 때 빙판에서 사고도 겪으면서 이게 맞는 건가 싶은 회의감이 점점 커져갔습니다.

이직결심​

1달 2달 시간이 지나갔고 일이 익숙해져 가면서 현대제철 쪽 업무를 거의 마무리 하면서 동기가 있는 SK하이닉스 팀 쪽에 지원을 가게 됐습니다. 업무 시작 전 일찍 도착해 동기가 지낸다는 합숙소에 들르게 됐는데 동기의 생활은 제가 생활하던 것보다 더 말이 아니었습니다.

회사에서 오래된 아파트 중 1개의 방을 빌렸고 거기서 4명의 남자들이 합숙하는데 문을 열자마자 나오는 응축된 담배 찌든 향이 코를 찔렀습니다. 재빨리 선임들이 깨지 않게 필요 물품만 챙겨 나와서 업무를 위해 하이닉스로 출발했습니다.

하이닉스에 도착하니 밤샘 작업을 한 듯한 직원 2명이 있었는데 한번도 보지 못한 회사 직원이었습니다. 그 분들과 많은 이야기를 나눴었는데 두 분은은 SI 업체에서 일을 굉장히 잘해서 이사님이 직접 스카웃한 분들이라고 했습니다. 두 분은 C언어 개발자였는데 PLC 관련 데이터를 다루는 업무를 맡고 있었고, 스카웃 조건 상 출퇴근이 자유롭고 워낙 많은 문제들을 해결해 연봉 테이블이 다른 직원들과 달랐습니다.

업무가 끝나고 숙소에 있던 선임들은 지원이 고맙다며 저녁을 먹자고 했고 저녁이 회식으로 이어지면서 많은 이야기를 듣게 됐습니다. 선임들은 회사 연봉 체계에 대해 불만이 굉장히 많았는데 당시 5년차도 3000을 넘기지 못하는 상황이었습니다. 10년 다 되가는 분들도 4000을 넘기지 못했습니다. 앞서 만났던 두 분은 입사한지 얼마 안 됐는데도 연봉이 5000을 넘는다고 들었는데, 내 직종으로는 받을 수 없는 연봉이란 생각이 들었습니다.

26살, 대학 졸업하기도 전이었기 때문에 현재의 적은 연봉에는 불만을 갖지 않았지만 면접 당시 실력에 비례해 급격히 오를 수 있다는 말과는 다르게, 5년 뒤, 10년 뒤 받게 될 연봉이 눈 앞에 보여 암담했습니다.

이대로 31살, 36살이 되면 열심히 출장다니며 선임들 비위 맞춰가며 맘에 들지 않는 연봉을 받으면서 온갖 잡일까지 해가며 견뎌야 한다는 생각이 들었고, 하이닉스에서 스카웃 된 선임들처럼 멋지게 회사를 다니고 싶어졌습니다. 그렇게 컴퓨터 공부의 필요성을 깨닫고 직종 변경을 결심하게 됩니다.

만류​

직종 전환이나 이직에 대해 주변 사람들과 회사 사람들 모두 만류하기 시작했는데 대략 이런 내용이었다.

1. 첫 직장은 정말 중요한 거니 쉽게 생각하지 마라.
2. 다른 직장도 똑같다.
3. 1년도 못 체우면 다른 회사에 취업이 어렵다.
4. 철이 없다.
5. 자기 인생에 무책임하다

1, 4번은 잘 이해 되지 않았고 5번에 대해서는 내 인생인데 나보다 더 치열하게 내 인생을 걱정하는 사람이 있을까 싶었습니다. 2번에 대해서는 다른 좋은 직장들이 있음을 이미 알고 있었고 3번은 불안했지만 혹시 짧은 이력이 문제라면 그 이력을 쓰지 말고 신입으로 지원하면 된다 생각했습니다.

퇴사 의지를 확실히 하자 대화를 나눈 적 없던 선임들까지 갑자기 찾아와 말을 걸어 왔고 인생 조언을 해주기 시작했습니다. 퇴사를 부러워하는 사람도 있고 회사 비전을 이야기하며 남게 하려는 사람들, 왜 나가는지 이유를 남들에게 전하고 싶어 온 사람들도 있고 많은 사람들과 대화를 했습니다. 하지만 결국은 전반적으로는 여기서 나가는 것을 모두 나가고 싶지만 못 나가고 있는데 나가서 부러워 보이는 모습이었고 짧았던 회사 생활만큼 퇴사도 빠르게 진행됐습니다.

퇴사 이후​

나름대로 첫 회사였기에 어린 나이에 심적으로 부담감이 컸습니다. 다음 취업은 오래 다닐 수 있는 회사, 하고 싶던 일을 할 수 있는 회사를 가고 싶었습니다. 그래서 내가 원하는 직장은 어떤 직장인지 자문해 봤습니다.

1. 소프트웨어 엔지니어(직무 만족)
2. 대기업 또는 외국계 회사(고연봉)
3. 공기업(워라벨)

3가지 조건 중 하나라도 충족되는 회사에 가고 싶었습니다. 내가 할 수 있는 노력은 무엇일까를 고민해 봤고 고민 끝에 해야 할 일들에 대해 정리가 됐습니다.

1. 소프트웨어 엔지니어
   1. 컴퓨터 언어 중 하나라도 익숙해지기 위한 공부
   2. 언어를 사용해 할 수 있는 개발 분야에 대한 조사
2. 대기업 또는 외국계 회사
   1. OPIC IM2(토익 700 기준 대체용)
   2. 대기업 시험 준비
   3. 면접 스터디
3. 공기업
   1. 전기기사 공부(3기사가 필요하기에 1기사부터 준비)

그렇게 소프트웨어 엔지니어로의 직종전환을 위해 python 공부를 시작했고 OPIC 학원을 2주 다니며 IM2를 취득해 전기기사 필기 시험을 통과해 실기 시험을 준비하는 등 바쁜 일상을 보내게 됩니다.