4개월차 개발자, 느낀 것 4가지

입사한지 3개월을 지나 4개월도 얼마 안남았다. 그동안 나는 성장을 많이 한걸까 고민해보면 항상 부족하다는 느낌이 든다. 사실 입사하고나서 처음에는 적응하느라 힘들다는 핑계로, 지금은 적응이 되어서 게을러진 핑계로 공부 계획을 세워놓고 미루는 일들도 꽤 있었다. 이 게시물도 3개월이 지났을즈음 회고한번 해볼까 하고 마음 먹었던 건데 이틀뒤면 4개월차가 되서 제목을 변경했다..ㅋㅋㅋ

그동안 나는 이전보다 훨씬 더 큰 세상(?)을 경험했다. 이전에는 그냥 장고로 API 구현하고, 프론트랑 맞춰보고 화면에서 원하는대로 잘 굴러간다 -> 성공! 이라고 생각했고 원하는 기능을 구현할 수 있는 코드를 잘 짜는게 가장 중요하다고 생각했었다. 하지만 그 이외에도 백엔드 개발자가 하는 일은 더 많고 광범위했다. 그렇기에 4개월동안 헤매면서 느꼈던 것들을 간단히 회고해보고자 한다.

코드 작성보다 코드를 읽는 일이 더 많았다.

기존 서비스들이 어떻게 작동하고 있는지 확인하기 위해 기존의 레거시 코드를 읽고 흐름을 파악해야했다. 하지만 내가 이제까지 해보았던 프로젝트들과는 차원이 다르게 수 많은 파일들과 긴 코드들이 있었고 어디부터 봐야할지 정말 막막했다. 사실 한번 볼때 이걸 다 낱낱이 파악하자!보다는 다음에 볼때 좀 더 빨리 볼 수 있도록 흐름이라도 알아둬야겠다는 마음으로 보았던 것 같다. 혼자 공부할때나 프로젝트를 할때 vim을 고수해온 나였지만 파이참으로 갈아타게 되는 아주 큰 계기가 되었다. 디버그 모드 짱...👍🏻

그렇게 여러 개의 레거시를 보다보니 앞으로 유지보수를 염두한 친절한 코드를 작성해야겠다라는 생각이 들었다. 일단 내가 느꼈던 친절한 코드는 각 클래스나 함수, 변수에 대한 설명을 주석으로 달아주는 것, 또한 변수명을 최대한 줄여서 쓰지 않는 것이었다. 일단은 간단히 목적만 적혀있어도 코드의 흐름을 파악하는데에 큰 도움이 되었고, 변수를 줄여서 쓰는 것(예를들면 list_abc를 l_abc로 쓴다던가 하는것)은 이전에 사용하고 있던 변수를 통해서 유추할수도 있었지만 그렇지 않은 경우에는 의도를 파악하기가 어려울때가 있었다.

이전에는 숏코딩을 보면서 와 짱이다 어떻게 이런 생각을 하지?라고 생각했다면 지금은 유지보수는 어렵겠다..라는 생각이 든다.ㅋㅋㅋ 이 글을 쓰면서 유지보수에 대한 글을 하나 발견했는데 댓글도 각자 생각이 다양해서 재밌는 것 같다.

먼저 알려주기를 기다리지 말 것 + 질문 잘 하는법?

신입으로 입사하게 되면 모든 일을 하나하나 알려줄 것이라는 것은 내 착각일 뿐이었다. 어떤 업무가 주어지면 처음 해보는 일이라도 처음부터 하나하나 알려주지는 않는다. 일단 나와 구글만이 있을뿐...⭐️ 이제까지 한번도 해본 적 없었던 CI/CD나 마이그레이션과 같은 것들을 맡게되었을때 걱정되기도 했지만 하나씩 헤쳐나가는 것이 재밌기도 하고, 문제 상황에서 흔쾌히 도와주는 동료분들이 있어서 감사했다🙏🏻

맡은 일을 하다가 일단 모르는게 생기면 구글링을 해보고 충분히 고민해봤다고 생각했으나 못풀겠다 싶으면 현재 문제 상황 + 하고자하는 질문을 생각해서 질문을 한다. 도와주시는 분들도 본인 업무 시간을 할애해서 해결 방법을 같이 찾아주시는 것이기 때문에 질문을 어떻게 하느냐도 중요하다는 것을 느꼈다. 나도 말을 잘하는 편이 아니라 자주 횡설수설 하고는 있지만 노력하고 있다...😭 근래에 본 개발자, 질문 잘하는 법 동영상 링크를 걸어둔다.

기능 구현만이 전부가 아니었다. + CS 지식의 중요성

앞서 말한대로 입사전에 해보았던 팀프로젝트에서는 기능 구현 -> 프론트와 맞춰봄 -> 잘 돌아감 -> BAAAM 성공!이었지만, 그것은 시작에 불과할 뿐 완성이 아니었다. 회사에서 온프레미스의 서비스를 AWS로 마이그레이션하는 업무를을 맡게 되면서 처음으로 운영 서버를 구축해보았는데 4개월동안의 업무중에 가장 어렵게 느껴졌다. 일단 간단한 인프라와 서버를 구성하기 위해서는 나에게 부족한 네트워크 지식이나 리눅스에 대한 지식들이 필요했다. 특히 권한 문제가 어려웠다. 초반에 헤매면서 만들어서 ubuntu 계정과 jenkins 계정이 섞여 중간중간 권한에 대한 에러를 꽤 많이 마주치기도 했다.💦

nginx, uwsgi를 처음 다뤄보았을뿐더러 왜 이 파일을 작성해야하는거고 왜 이 옵션을 추가해야 하는건지 이해가 안가니 답답했다. 또한 에러가 나면 에러 로그를 찾아서 확인하고 해결을 해야하는데 장고에서의 친절한 에러 로그와는 달라서 왜 그 에러가 났는지 한번 더 생각이 필요했고 그 과정에서 CS 지식이 필요했다. 그래서 CS 개념에 대한 부족함을 절실히 깨닫게 되는 계기가 되어 네트워크와 리눅스에 대한 공부를 해나가고 있는 중이다.

또한 배포가 제대로 된 것 같아서 이제 잘 돌아가겠구나 생각했는데 며칠이 지나면 502나 504에러가 나는 것을 보고, 안정적인 서버를 구축하는게 어려운 일이구나라는 것을 한번 더 느꼈고 서버와 인프라에 대한 공부도 앞으로 차근차근 해나가야겠다는 생각이 들었다.(역시... 해야할 공부는 산더미쓰📚)

테스트 환경, 테스트 코드의 필요성

사실 팀프로젝트 했을때는 운영되고 있는 서비스도 아니었고 그냥 다같이 db 하나를 쓰면서 밥먹듯이 dropdb를 날렸고(회사가면 절대 그러면 안된다고 했다) 테스트 환경에 대한 중요성을 잘 몰랐다. 하지만 회사에 오니 production db나 서버를 만질 때는 혹시나 잘못 건드릴까 떨면서 작업을 하고 있다.🥶

또한 운영되고 있는 서비스에 새로 추가된 기능을 바로 적용했을 때 어떤 문제가 발생할지 모르기때문에 dev server에 먼저 배포를 해보는데 이렇게 미리 테스트를 해보는게 심신에 큰 안정을 가져다주었다. 그래서 최종 운영 환경에 업데이트를 적용하기까지 여러 단계의 테스트를 거쳐서 적용하는 것이 중요하다는 것을 깨달았다.

기능을 하나 둘씩 추가해보면서 내가 짠 코드가 기존 서비스에 에러 없이 잘 녹아들 수 있을까 확신이 안들기도해서 최근에는 테스트 코드의 중요성을 느끼는 중이다. 이번에 장고에서 클래스 하나를 더 추가해야했는데 웹은 잘 돌아가는데 나중에 배포하고 보니 기존에 돌고있던 배치잡에서 추가된 클래스에 대한 정보가 없어서 에러가 나고 있었다. 장고 뿐만이 아니라 스크립트도 테스트가 필요한 것이었다. 스크립트는 또 테스트를 어떻게 짜야하는지... 그렇게 테스트에 대한 갈증(?)이 생겨서 TDD책을 보기 시작했는데 너무 어렵다. 다 읽을 수 있을까🤦🏻‍♀️

마치며

4개월동안 나는 백엔드 개발자가 어떤 일을 하는지 아직은 발 정도만 담궈본 느낌이다. 혼자 공부할때는 딱 내가 경험한 부분에서만 부족함을 알 수 있었는데 이제는 좀 더 시야가 넓어졌다. 구직을 할때는 면접을 준비하면서 아는 것도 많이 없다고 느껴지고 자존감도 하락했던 때가 있었다. 나를 뽑아주는 회사가 있을까 공부를 더 하고 준비해야하나 걱정이 앞섰었다. 하지만 지금은, 매일 일을 해나가면서 나의 부족한 부분들을 받아들이고 그에 맞는 공부를 계속 해나가는 것이 현재 나의 부족함을 채울 수 있는 가장 빠른 길일 수도 있다는 생각이 들었다. 그래서 만약 누군가가 처음 개발자로 일을 하려고 하고 나와 같은 고민 때문에 구직을 할까말까 망설이고 있다면 일단 시작해보라고 말해주고 싶다.

아직은 4개월차지만, 1년차가 되어 뒤돌아보았을때 그래도 열심히 했구나라는 생각이 들 수 있도록 더 힘을 내봐야겠다. 아자잣✊🏻