퇴사 한달 차 신입(이었던 것)의 회고
OO회사에 퇴사한지 약 한달이 지났습니다.
열심히 회고록을 작성한다고 하였지만, 회고록을 작성한지 벌써 4개월이 지났습니다.
저 글을 작성한 이후로 업무에 치이기도 했고, 굳이 회고록을 작성할 필요를 느끼지 못했는데요.
퇴사하고, 여행을 잠시 다녀오고 주변을 둘러보고 나니 처음 회고를 하는 이유를 상기시키며 다시 회고를 하려 합니다.
1월 21일까지 전 직장에서 인턴으로 6개월간 백엔드 개발자로 근무했습니다.
사용된 기술 스택은 Java, Spring(전정프), JSP, MySQL(+ Oracle) 등을 사용했습니다.
맡았던 기능 개발, 유지보수는 다음과 같습니다.
- (서비스기능)견학 신청, 문화강좌 신청, 설문 조사, 방문자 통계 기능
- (화면) 위의 서비스 기능의 관리자 페이지 (JSP)
- 유지보수
- 핫픽스 배포
시작할 당시 Java, OOP, Spring이 뭔지도 잘 모르면서 많이 까불었습니다.
(진짜모름 아직도 모름)
감사하게도 이곳에서 기본기를 배우며 성장할 수 있었습니다.
잘하는 다른 사람들의 코드를 베끼고, 왜 저렇게 작성했지?를 생각하며 내 코드에 적용해보고 많이 배울 수 있었습니다.
그러나, 처음 작성한 입사 회고록에서 쓰인 문제점들은 업무에도 그대로 직격탄으로 박혀버렸습니다.
자, 왜 퇴사(이직 준비)했을까요?
1. 돈
제일 큰 이유는 돈입니다.
나의 직업선택 기준에 돈이 일순위는 아닙니다.(마지막도 아니지만.)
건방지게 "이건 좀 아니지 않나요?"했습니다.
2. 피드백
두번째는 사수(피드백)입니다.
실제 문제가 닥치면 혼자 해결할 수 밖에 없었습니다.
다른 분들은 다른 부분에서 매우 바빴었습다.
어찌어찌 이렇게 문제를 쳐내고 나면 내 코드가 멀쩡한 건지 봐줄 수 있는 사람이 없었습니다.
닥쳐오는 기능 구현에 안절부절했습다.
엄청난 결합도, Spring, Java, OOP 개념을 이해하지 못한 문법과 의미없는 VO 선언들의 향연이었습니다.
이론적으로 배우는유지보수의 용이성의 중요성을 뼈저리게 느꼈습니다.
내가짠거야?
3. 개발 문화/체계
대부분의 작은 규모의 업체들이 체계가 없을 수도 있습니다만, 개발 시스템 자체가 부족했습니다. 가장 충격받은건 다음과 같습니다.
- 테스트코드 없이 짠 나의
500 Internal Server Error를 불러올작고 귀여운 코드를 내 손으로 서버에 직접 배포하는것 - gitflow 까진 아니어도 버전컨트롤의 브랜치 자체가 없는 것
이외에도 여러가지가 있지만, 흉보는 것 같아 싫으니 줄이겠습니다.
추가적으로
.war파일을 배포할때 마다 죽어버리는 서비스를 보며 무중단 배포에 대한 지식을 배우긴 했지만 직접 구축하지 못한 점이 아쉬웠습니다.
또, SOLID나, 디자인 패턴을 잘 알았더라면 더 좋은 구조를 고민해보고 weight해봤을 것 같습니다.
이를 통해 CI/CD, TDD 등에 관심을 갖게 되었습니다.
그래도 결론적으론 다른 사람들의 코드를 보며 많이 배웠습니다.
그렇다면, 구성원으로써 이런 불편함을 해결하기 위해 나는 무엇을 했을까요?
1. 개발 환경 설정 메뉴얼 작성
제가 인턴으로 들어오면서 약 1~2일간 혼자 해결했던 문제는 개발 환경 설정이었습니다.
개발 환경을 설정할 줄 아시는 백엔드 개발자는 모두 출장하거나 바쁘신 상태였고, 도움을 얻기 어려웠습니다.
혼자 개발 환경을 설정하며 배운점도 많고 시스템적으로 이해할 수 있던 것도 많았습니다.
그럼에도, 개발 환경 설정 시간은 아까웠습니다.
후에 들어오시는 분들을 위해 현재 진행하던 프로젝트 뿐만 아니라, 다른 프로젝트로 바뀌더라도 어느정도는 유연히 적용 가능한 메뉴얼을 작성하였습니다.
아쉬운 점은, 사내 분들이 사실상 거의 모두 eclipse를 사용하셔서, ecliplse기준으로 작성했다는 것입니다. IntelliJ 짱짱맨,,
2. Postman 문서화
API 명세 문서는 잘 작성되어 있지만, 엑셀 스프레드 시트에 정리된 수준이었고
모든 API는 아니어도 현재 프로젝트에 이용되는 API, 특히 자주 사용되는 API는 문서화 하여 Postman 파일로 남겨놓았습니다.
3. 자동...화 시도
첫째로, 테스트 자동화를 시도하였으나, 스프링 MVC 패턴에서, 복잡한 DB를 가지고 테스트를 작성할 엄두가 나지 않아서 실패, 이후로 Swagger라는 툴에 관심이 생겼습니다.
둘째로, 배포할때 마다 다운되는 서버를 차마 볼 수 없어서, k8s를 이용하여 무중단 배포를 하고 싶었으,,나 프록시 설정 등 시스템 설정을 1도 몰루고, 막상 시스템 설정을 건드리려니 무서워서 포기하였습니다.
이후로 자연스럽게 쿠버네티스, AWS EC2 등에 관심을 가지게 되었습니다.
결론적으로..
말로만 찡얼찡얼 막상 어떤걸 개선하지 못한 우이천이었습니다.
변명하자면, 시스템을 개선시키고 싶었으나 못했다.
음.. 몇차례 정도 같은 시스템을 공유하는 분들에게 문제점을 공유해보았으나,
생산성 문제로 불가능하다는 답변을 여러번 받았습니다.
그래서 매우 아쉽지만, 퇴사는 잘 한 것으로 생각합니다.
이러한 문제점들을 해결 할 수 있는 토이 프로젝트를 진행해보고자 합니다.
또한, MyBatis 뿐만 아니라 Spring JPA에도 관심이 많이 생겨서 관련한 공부를 해볼 계획입니다!
(6개월 뒤의 나) 그러나.. 그러지 못했다
