주니어 개발자의 우당탕탕 이직기

안녕하세요, 1호입니다.

정말 바쁘게 지냈던 2022년 8월8일 합류 이후 현재까지의 여정을 기록하고자 글로 써 내려가 봅니다.

여러분 모두가 오늘도, 내일도 웃으시며 보내시는 행복한 하루를 보내셨으면 좋겠습니다.

저의 이직후의 여정은 목표했던 기술 스택을 이루는 과정,

앞으로의 미래를 꿈꾸며 그려보는 과정,

짧았지만 좋은 동료를 이별하는 과정,

현재까지의 나를 되돌아보는 과정이었던 거 같아요.

 

앞으로도 각자의 여정에서 힘내서 같이 도전해보면 좋겠습니다 🤭

 

 

요약

• 서비스: Grassroots Football 관련 서비스
• 업무:
  • API 개발 그런데 RDB도 처음인데, Graphql을 곁들였다고..?
  • 인프라에 대해 아무것도 모르는 내가 인프라를..?
  • CI/CD 써보지도 못했는데, 내가 만들라고..?
• 괴로울것같지만, 즐거웠던.
  • ( 내 심정 )

 

 

이직 후 만족스러운 점

• AWS를 전혀 사용할 수 없었다가, 어떻게든 “사용은” 할 수 있게 되었습니다.
  • vpc, ECS, ec2, alb, security group, target group, load balance …
• AWS를 사용하며 전반적인 네트워크 지식을 익혀볼 수 있었습니다.
• front, back이 나누어진 협업 과정을 처음으로 체험해볼 수 있었습니다.
• 마이그레이션을 체험하였습니다. ( bass(mongo Realm) → backend 서버 구축 )
• 업무 소통을 하는 게 너무 즐겁습니다. ( slack, 근무가 길어져도 웃으면서 함 )
  • 단어 선택 하나의 중요성을 알고 있는 분들이 모여있는 회사라는 게 느껴집니다.
• 업무에 대한 보상을 명확히 해주는 점이 좋습니다
  • 서버를 새로 구축하다 보니, 개발팀이 다 같이 야근하며 보냈던 적이 있었는데, 이에 대한 보상을 명확하게 챙겨주셨습니다.

 

이직 후 겪은 생각의 흐름

• graphql 처음 써 봄 → graphql을 왜 써야 하는지, 어떻게 쓰는지 알게 되었습니다.
  • 익숙한 restapi를 첫 번째 업무로 잡고 진행하였습니다.
  • 이거 어떻게 하는 거야 ㅠㅠ.. 이거 왜 이렇게 써야 하는 거지..? 이렇게 쓰는 게 맞는 건가? 의 영겁의 시간
  • 하지만 잘못된 판단은 미래의 내가 해줄 거라는 생각으로, 일단은 되게 하는것에 초점을 두고 진행했어요!

이렇게 쓰는게 맞는건가..?

미래의 나

   

• nestjs 에 rdb를 처음 써보았습니다. ( typeorm )
  • redis 처음 써 보았습니다.
  • 왜 Redis를 채택하는지 알 수 있었습니다. 시간 체크해보고 놀라움을 느껴보세요…. 엄청나요..
  • 앞으로, 언제 어떻게 써서 서버의 부하를 줄일 수 있는지 재미난 도전과제일 것 같네요.
• 인프라 관련 처음 만져봄
  • 네트워크 지식도 이리저리 찾아보고 AWS를 사용해도 모르는 거투성이라 반대로 AWS 위주로 공부했더니 추상적인 이론과 AWS의 연관관계가 이어졌어요.
• 디자이너님과의 첫 협업!
  • 이메일에 대해 html 작업을 진행하였어요, AWS ses와 연동하여 회원가입, 비밀번호 찾기 등에 이메일 템플릿을 서버 측에서 제어하고 있는데 디자인이 있는 상태에서… html 작업을 하니 너무 편한 거 있죠…정말…. 최고예요 전 회사에서는 기획서( #ppt, #흑백, #no 디자인 )를 보고 알아서 해야 해서 매번 구글 검색에 ** design, template 등을 검색하면서…. 보고 했었는데, 디자인 시안이 있으니까.. 정말 정말 편하고 행복했어요. 디자이너님의 유무는 작업시간에 많은 영향을 끼치는 것을.. 다시 한번 체감하였네요. 🥲email에에 보내는 html을작업하다 보니니, 여러 안되는 element요소 등이이 많았는데, 본의 아니게 괴롭히게 되었네요…

 

 

• 대망의 마이그레이션 당일
  • 진짜.. 무서움 그 자체였어요 기존 데이터를 JSON, CSV 형태로 백업해두고 ( -최종본-최종본-진짜 최종본 ) parser를 이용하여 데이터를 집어넣었는데 데이터 확인을 몇 번 했는지 모르겠네요…. ㅠㅠ 하지만 한번 하고 나니 뭐야 쉽네?? << ( 플래그였음 ) 넣고 보니…. 분명 잘 되었는데…. 잘 되었는데… 안 되어 있는 부분을 확인해서.. table drop하고 다시 …table 생성하여…. 데이터를 넣게 되는…과정이 있었습니다….

 

• 앞으로 배포는 어떻게 해..?
  • prod 서버에는…ERC에 올린…. docker container를 pull 하여…docker-compose를 통해 실행하고 있었습니다… 그 당시의 저는…무중단 배포가 아닌.. 간이 배 밖으로 튀어나온 중단 배포를 불가피하게…. 하고 있었습니다..다행히..런던에서 하는 서비스이고 유저 또한 많이 없었기에, 큰 이슈는 없었지만 현황을 유지하기에는 너무 위험부담이 컸기에 무중단배포를 해보고 싶었습니다.
  • 그래서 찾았던게..ECS!! 여러 문서를 봐가며 ECS로 세팅을 해두고 CI/CD까지 완료했습니다! 뭐든 처음이 어렵다는것을 많이 느꼈습니다. 현재까지도 CodePipeoLine을 통해 ECS로 진행을 하고 있습니다. ( Code Build에서 Docker Image를 생성하여..ECR로 올리는데 약 7분이 걸리는 것이 조금 🤔 이여서 방법을 천천히 찾아보고 있어요 )

 

이직 후 내게 남은 과제

---

• 테스트 코드 작성 시도
  • 예전에 CI/CD 알림봇이 없었을 때 배포를 수동으로 AWS CodePipeLine을 통해 확인했어야했는데, 확인하지 못한경우 캐치를 하지 못함 → health check fail에 대한 test code를 우선과제로 시작해보고자 함.
• 개발팀 문서 카테고리 분류
  • 기존 문서와 현재 문서가 섞여있어 카테고리를 나누어 오래된 문서에 대한 컨펌이후, 문서함의 중요성을 높이고자 합니다.
• 쿠버네티스 도입
  • 현재 ECS 까지 해보았는데, 쿠버네티스 도입을 해보고 싶습니다.
• Logger 에대한 고찰
  • 어떻게 Log를 잘 수집하고 분석할 수 있는지 방법을 탐구해보고 싶습니다.
• 장애보고서 형식 제정
  • 주기적 장애보고서에 대한 틀을 만들어보고, 분석하며 과제를 설정해보고 싶습니다.
• 기술 스택 시각화 자료
  • 사용 기술 스택과 로직등에 관해 피그마, 피그잼을 통하여 시각화 자료를 구축해보고 싶습니다.