첫 운영서버 배포 회고
이제 차차 회사에 적응을 하고 내가 썼던 코드들을 운영서버에 배포하면서, 그동안 느꼈던 점과 성장했던 점, 아쉬웠던 점을 정리하려고 한다.
느낀 점
입사 전 후 가장 달라진 점은 협업의 중요성이다. 실제 배포까지는 local, dev, main까지의 단계를 거치며 보통 내가 local에서 개발 후 팀장님의 승인을 받고 dev에 merge한 뒤, dev서버에서 에러 로그를 살핀 후 운영에 배포한다. git을 공부할 때 귀찮아서 하지 않았던 branch를 나누는 것도 굉장히 중요하고 획기적인 업무라는 것을 깨달았다. 내가 주로 하는 일은 API를 개발하는 것이였는데 프론트, 안드로이드, ios 팀원들과 주고받는 데이터들을 정하고 소통하며 일하는 과정은 되게 즐거웠다. 외부 업체, 기획팀과 미팅하고 테이블 컬럼, API 파라미터 들을 바꿔가는 작업들도 내가 혼자 개발 공부했을때는 절대로 느끼지 못했던 새로운 분야였다. 그동안 유튜브나 개발자 블로그에서 글로 읽었던 의사소통의 중요성을 몸소 깨달을 수 있었다.
성장했던 점
회사에서 담당하는 API 개발에는 자신감이 붙었다. 그동안 커밋했던 걸 살펴보면
- 테이블에 컬럼을 추가하거나
- 데이터를 조회, 수정, 등록하거나 (CRUD)
- 업로드가 느린 페이지에 캐싱작업을 하거나
였다. 처음엔 구조가 너무 복잡하고 모르는 어노테이션이 많아서 코드에 손을 대는 게 무서웠는데, 기존 것을 레퍼런스 삼아 불필요하거나 내가 모르는 부분을 제거하고 최대한 심플하게 구현해보자 라고 생각하고 코드를 쓰니 웬만한 작업들은 속도가 붙었다. 혹시 이해가 안되는 부분은 물어보거나 구글링을 통해 해결하면 된다고 생각하니 마음이 편해졌다. 회사의 전반적인 업무 프로세스까지 알게 되니 내가 만든 API를 팀원들이 사용하는 것에 뿌듯함을 느끼기 시작했다.
혼자 개발할때는 쓰지 않았던 AWS EC2, Beanstalk, codepipeline을 쓰면서 devOps에 대해서도 관심이 많아졌다. 확실히 시야가 넓어진 것을 느낄 수 있었다. 나중에 기회가 된다면 도커나 쿠버네티스도 공부해 보고 싶다.
그런데 예상치 못한 문제는 연휴 전 운영 서버에 배포할 때 터졌다. cms 관리자 사이트 업로드 속도가 늦어서 입사하자마자 캐싱 작업을 했었는데, 그 전까지 캐시에 대한 개념이 없었다. 대략적인 개념만 안 상태로 어노테이션에 키를 붙여서 커밋했는데, 운영 서버에 배포하자 데이터를 불러오지 못하는 이슈가 생겼다. 처음엔 프론트쪽 문제인줄 알았으나, 알고보니 같은 이름의 캐싱이 몇 개 있어서 가져온 데이터가 꼬이는 현상이였다. 로컬에서 테스트 할 때는 DB또한 내 로컬 DB이기 때문에, 그저 200 OK만 보고 문제 없다고 판단했던 게 착각이였다. 빠르게 코드를 수정하고 배포하자 페이지는 정상 작동 했지만 속도가 여전히 느렸다. 다시 살펴보니 Controller에 몇몇 메서드에 캐싱을 빼먹은 것이었다. 물론 입사한지 며칠 안돼서 그럴 수 있다고 하지만, 명백한 내 실수였다.
이 일은 나에게 큰 교훈을 줬는데,
- 개발은 두리뭉술하게 되겠지 하고 하는게 아니다. 어떻게 작동하는지 꼼꼼히 이해해야 한다.
- 주고받는 데이터를 정확히 알아야 제대로 테스트 할 수 있다.
평소 덤벙거리는 성격이 일을 할때도 나왔는데, 개발은 정말 꼼꼼함이 중요한 것 같다. 천천히 디버깅을 걸어보고, 로그를 남겨봐야 나중에 에러가 터지면 처리할 수 있다. 겸손한 자세로 이 부분은 고쳐가도록 해야겠다.
아쉬웠던 점
- 아무래도 구현에 급급하다 보니 좋은 코드가 뭔지, 객체지향 설계가 뭔지에 대한 고민이 부족했다.
- 테스트코드 또한 작성하지 않았다.
시스템이 덩치가 커지면서 기존에 했던 테이블 설계들이 꼬이기도 했다.가장 기본적인 null check도 하지 못하고 PR을 올린적도 있었다. 성장에 대해 고민할 때는 항상 이 부분이 크게 걸렸는데, 내가 지금 단지 구현이 되는 수준에서 만족을 하고 있지는 않나? 라는 불안감이 항상 있었다. 물론 지금은 일이 항상 생기고, 앞으로 갈 길이 막막하지만 배우려는 자세로 겸손하게, 꼼꼼하게, 꾸준히 가고 싶다.