19살
내가 19살이 되는 해에 선생님께 추천을 받아 한 약 180명 규모의 IT 중소기업에 면접을 보게 되고, 9월 달부터 현장실습생 3개월 과정과 정규직으로 약 3년 동안 다녔다. 그중 2년은 사내시스템을 개발하고, 1년은 부서를 이동하여 b2c 플랫폼을 개발했다.
나는 입사하면 사수가 분명 있을 줄 알았다. 정말 내가 생각하는 이상적인 회사는 책상에 웰컴키트나.. 뭔가 환영받는 듯한 느낌이 있을 줄 알았다. 하지만 이는 현실로 되지 않았다. 사회생활의 첫 시작인 입사 첫날에 출근을 해보니 그냥 책상 위에 방금 배송 온 듯한 테이프로 칭칭 감긴 컴퓨터 박스와 한 5년은 쓴 것 같은 본체만 덩그러니 놓여 있었다. 나랑 같이 입사한 친구에게 아무런 가이드 또한 없었다. 하지만 열정 가득한 신입이었기 때문에 우리보다 먼저 입사한 선배들한테 물어보면서 열심히 가르침을 받았다.
정말 19살의 나는 머리가 백지장이라서 실수도 정말 많이 했고, 무엇보다 적응이 정말 어려웠다. 아무리 고등학교에서 3년동안 코딩 공부했다 하더라도 실제 코드를 보게 되니 정말 내가 이때까지 뭘 했지..라는 회의감이 들었다.
내가 제일 처음 한 실수는 dev db의 특정 항목을 쿼리 문으로 update해야 되는데.. where조건을 안 걸고 전체를 update 시켜버린 것이다. 매우 식겁했지만.. 다행히도 도움을 요청했고, db덤프라는 존재를 알게 되어 복구할 수 있게 됐다. 그 후로 덤프 뜨는 것은 내 습관이 되었다. 실수를 하게 되면 머릿속이 하얘지면서 이걸 다른 분에게 어떻게 설명해야 잘 넘어갈까..?라는 생각으로 가득했던 거 같다. 하지만 뒤돌아보면 실수를 통해 배운 게 더 기억에 오래 남는 것 같다.
20살~21살
대학과 병행 동시에 회사를 3개월 정도 다닌 후.. 상사에게 일을 받았다. 나에게 ‘사내 직원들이 휴가를 신청 할 때 서면으로 직접 결재를 받아야 하니 휴가를 신청할 수 있는 시스템과 관리자 페이지를 개발해 봐’였다. 그게 끝이었다. 기술 스택.. 배포 환경 다 그냥 나와 또 같이하는 선임님 한분에게 맡겼다. 그래서 우리는 단순하게 그때 한창 떠오르고 있던 리액트를 프론트로 하고, 백은 자바, db는 JPA를 사용하기로 결정했다. 그리고 MSA구조로 api를 netflix zuul, eureka를 사용했다. 리액트의 ㄹ도 모르는데 말이다. 기술 스택을 결정하고 2주일 뒤에 같이 하던 분이 다른 부서로 발령 나셨다..??🤨
입사한 지 3개월 만에 나는 1인 프로젝트를 맡게 됐다. 진행은 리액트 공부와 병행하면서 개발을 같이 시작했다. 리액트는 구글링, 자바와 JPA도 구글링 해가면서 프론트와 백을 진행했다. 프로젝트를 진행하면서 나에게 닥친 시련들은..
(1) 내가 현재 막힌 상황을 이해해주고 같이 고민해 줄 개발자가 없다(리액트를 할 수 있는 사람이 없었다)
(2) 휴가와 관련된 정책들과 기능셋들을 관련부서와 논의해야 되는데, 직접 소통하는 과정이 어려웠다.
(3) 프로젝트 일정을 조율하고 진행사항을 상사에게 보고를 해야 되는데.. 나조차도 이 프젝이 어떻게 흘러갈지 모른다.
(4) 프론트 배포는 어떻게… 하는 거지?
(5) api호출할 때 apigateway 타임아웃 에러로 데이터가 간헐적으로 안 불러와진다..
… 등
정말 위와 같은 스트레스 때문에 매일 새벽에 자연스럽게 눈이 떠져서 계속 에러 나던 서버와.. 자꾸 실패되는 배포만 뚫어지게 쳐다봤다.
그래서.. 난 구글링해서 나온 A가 안되면.. B로 해보고,.. Z까지 다 해봤다. 만약 그래도 해답이 없으면 직접 스택오버플로우에 질문을 하여 답을 얻기도 했다. 이런 과정들을 통해 개발자는 인내심과 끈기가 무엇보다도 중요하다는 것을 깨달았다.
그래서 약 5개월 동안 혼자 프로젝트 진행하면서 상사에게 혼나본 적도 있고, 사장님 앞에서 진행상황을 발표하기도 했다.
이런 과정 끝에,, 아무리 내가 작성한 코드가 스파게티일지라도,, 껍데기는 돌아가니 회사 사내 직원들에게 배포를 하여 회사의 첫 버전인 휴가 시스템을 만들었다.
해당 프로젝트를 하며 얻은 점은
(1) 사용자 UI/UX를 무조건적으로 고려하여 구성해야 한다. (다음 액션을 사용자가 예측할 수 있게 UI를 구성해야 한다.)
(2) 지금 내가 처한 상황을 숨기지 말고, 적극적으로 공유하자
(3) 내가 만든 서비스로 인해, 기존 불편함을 개선시켜 줬구나 (뿌듯)
(4) 깨달음을 확실히 하자! 그때의 나는 분명 이해한다고 생각했다. 하지만 5분 뒤의 나는 이해를 못 할 수 있으므로, 확실히 짚고 넘어가자
매우.. 많은 버그 제보들
배포를 하고 기능은 오픈이 됐으니 직원들은 상시 사용할 수 있다. 이로 인해 넘쳐나는 버그 제보들이 엄청났다.
나에게 다이렉트로 메일이 오거나 직접 내 자리로 찾아와서 물어보는 건 물론이었다. 상사에게 전달돼서 넘어오는 건까지 혼자 진행했던 프로젝트인 만큼, 버그 픽스의 몫도 오로지 내 몫이었다. 사실 개발보다 더 큰 산은 버그 잡기이다.
수많은 디버깅과 해당 이슈가 어떻게 나왔는지 재현하는 것까지 그리고 버그 해결된 반영 사항 공유까지 정말 힘들었다. 내가 짠 코드인데도 물음표가 가득했다.
약 2개월 동안 해당 서비스가 안정적으로 되기 위해 몰두했다. 이런 시간 때문에 껍데기만 돌아가는 스파게티 코드보다는, 코드도 깔끔하고 즉,, 유지보수가 잘되는 코드를 짜자였다. 이를 통해 내가 노력한 것은
(1) 문서 기록을 잘하자!
코딩하게 되면 핵심적인 코드가 있을 것이다. 휴가 신청 시 휴가 산정 로직, 특정인 월차 부여 스케줄러 로직 등 이런 기능들은 문서화하여 히스토리들을 남겼다.
(2) 변수명을 잘 짓자
변수명은 정말 중요하다. 값의 성질을 가장 잘 보여줄 수 있는 값이다.
(3) API 명세서를 작성하자
swagger을 통해 API명세서를 작성하여 코딩한 API를 정리했다.
(4) 커밋메시지을 직관적으로 명확하게 쓰자
내가 전에 변경했던 코드라도 미래의 나는 까먹게 된다. 그러므로 가끔 해당 파일의 커밋내역을 볼 때가 있는데 커밋메시지가 두리뭉실하게 되어있을 경우 그때의 코딩 의도를 파악하기가 어렵다.
이렇게 나는 나중에 휴가시스템에 직원들 근태관리 기능까지 추가로 새로 개발하고 피그마를 통해 ui설계까지 하여 전보다는 훨씬 개선된 버전 2를 배포했다.
22살 - 새로운 환경에서의 적응
연초에 다른 부서의 팀장님이 나를 데려오고 싶다 하여 부서 발령이 이루어졌다. 이때까지 2년 동안 내가 사내 시스템을 혼자 개발했던 경험이 많았다면 여기서는 다른 팀원들과의 협업이 중요했다. 한 프로젝트를 개발하기 위해 팀원들과 역할을 분배하고, 언제까지 해야 하는 완료일도 정해져 있었다. 그리고 기획자, 디자이너, 인프라팀 들도 세분화되어 나누어져 다른 팀들과도 소통이 중요했다.
새로운 부서 발령으로 인해 많은 경험들을 해봤다. 내가 개발한 부분에 버그가 일어나 핫픽스 배포도 해봤고, 갑자기 다음날까지 프로젝트를 끝내 달라하여 팀원들과 오후 11시 넘게 개발해서 새벽4시쯤에 끝난 적도 있다. 그리고 현장 설치할 때 직접 따라가서 큰 도움은 안 됐지만, 어떻게 프로젝트 계약이 이행되는지도 보게 되었다. 그리고 다른 선임님이 나에게 물어본 기술적인 요소들도 해결해 준 뿌듯한 기억들도 있다.
약 3년 동안 개발자로 일하면서, 같이 일한 동료들의 퇴사로 인해 인연이 끊기기도 하고 너무 정들었기 때문에 그로 인해서 슬프기도 했다. 그리고 동료들이 퇴사할 때마다 일들이 나에게 몰리는 부분이 있어서 부담감도 높아졌던 기억들도 있다.
사실 23살이 된 지금도,, 부족한 게 정말 많다. 같은 실수를 반복한 적도 있다. (그럼 안되지만..) 앞으로도 개선해야 하고 성장할 건 무한대이므로, 내가 사회생활을 하면서 만난 값진 소중한 인연들에게 항상 감사해하고 더 열심히 해야 할 생각뿐이다.