2년차 주니어 개발자 회고(feat.이직)

resilient

·

2024. 4. 24. 00:14

728x90
반응형

 

이 글을 쓰고 있는 이 시점은 새로운 회사로 이직을 한 지 3개월이 된 시점입니다.

 

그리고, 콴다라는 스타트업에서의 11개월에 더해 이제 2년차 개발자로서의 한 걸음을 내딛고 있기도 하죠.

 

이쯤에서 제가 현재 '개발'에 대해서 어떤 태도로 임하고 있는지, 앞으로는 어떤 부분을 중점으로 성장할 건지에 대해 이번 포스팅에서 짚고 넘어가 보려고 합니다.

 

최근에 올려주시는 족족 시청하고 있는 개발 유튜브가 있습니다.

 

제미니의 개발실무라는 유튜브 채널인데요.

 

'좋은 개발자와 좋은 소프트웨어' 에 대한 주제의 영상이 인상적이여서 저도 제가 생각하는 '좋은 개발자'에 대해서 정리를 좀 해보려고 합니다.

 

0. 현재는 어떤일을 하고 있나?

 

제주항공에서 결제/예약 및 발권 팀에서 근무하고 있습니다.

 

콴다에서 사내 개발팀들을 위한 모니터링 툴이나 여러 어드민을 관리하고 개발하는 팀에서 근무했던지라 B2C를 경험해보고 싶은 마음이 커졌던 것 같습니다.

 

많은 이용자들이 이용하고 꾸준한 트래픽을 가지고 있는 B2C면서, 여러 서비스에서 필수적으로 사용이 되고 있는 결제파트를 경험해보고 싶어서 이직을 했습니다.

 

현재 결제 시스템에 대한 이해도를 높이면서 팀의 전체적인 아키텍처와 도메인을 익히는데 집중하고 있습니다.

 

1. 이곳에 와서 '좋은 개발자'에 대한 정의가 바뀌었나?

 

'회사'에서의 좋은 개발자와 '좋은 개발자'는 약간의 거리가 존재할 수밖에 없다고 느낍니다.

 

물론 회사가 원하는 핏과 정확하게 부합하는 개발자는 없겠지만 '일'을 잘하는 개발자가 회사에서는 '좋은 개발자'라고 불리기 마련입니다.

 

제가 생각하는 '좋은 개발자'에 대한 정의는 바뀌지 않았습니다.

 

끊임없이 공부하고, 개발적으로 성장하면서 현재 속한 집단에 좋은 결과를 안겨주는 개발자가 '좋은 개발자' 라고 생각합니다.

 

2. 그럼 어떻게 '좋은 개발자'로 성장하려고 하는가?

 

먼저 막연하게 회사에 도움이 되는 개발자, 팀원이 되어야지라는 생각보다, 저는 스텝을 만들었습니다.

 

첫 번째 스텝은 믿음을 주는 팀원이 되자 입니다.

 

일이 많아지면서 일을 분배하는 데에 있어서 가장 중요한 건 일을 맡겼을 때 안심할 수 있는 사람이라고 생각했습니다.

 

빨리한다고 좋은 건 아니더군요 가끔은 같은 일을 두 번 일하게 만드는 팀원들도 있었으니깐요.

 

두 번째 스텝은 현재 상황을 정확하게 이해하는 팀원이 되자입니다.

 

좋은 기술, 좋은 아키텍처, 좋은 패턴을 공부하는 것은 '좋은 개발자'로 성장하기 위한 중요한 발판이라고 생각합니다.

 

하지만 회사에서 이 모든 것을 적용시킨다고 해서 '좋은 개발자' 인 것은 아닙니다.

 

회사에 맞는 기술이 있고, 로직이 있고 아키텍처가 존재합니다.

 

상황을 정확하게 이해하고 넓게 바라보면서 개발을 하는 개발자가 '좋은 개발자'라고 생각합니다.

 

세 번째 스텝은 최선을 다해 책임을 지는 개발자입니다.

 

두 번째 스텝에서 상황을 정확하게 파악했다면, 현재 할 수 있는 범위 내에서 가장 효율적인 방법을 찾고 실행에 옮기는 개발자가 되어야겠다고 생각했습니다.

 

실행에 옮긴다는 것은 책임을 진다는 말이기도 하죠. 책임을 지는 것을 두려워하면 성장할 수 없습니다.

심한 부담감에 스트레스를 받는 것은 좋지 않지만 적당한 부담감은 강한 책임감을 가질 수 있고 빠르게 성장할 수 있는 방법이라고 생각합니다.

 

네 번째 스텝은 긍정적인 마인드입니다.

 

개발자뿐만 아니라 회사에 다니다 보면 매사에 부정적인 사람이 있고 긍정적인 사람이 있습니다.

 

긍정적인 영향력은 주변사람들에게 시너지를 내게 하고 함께 목표를 달성할 수 있게 하는 큰 힘이 됩니다.

 

현재 상황에서 어찌할 도리가 없으면 주저 않고 부정적인 말을 하기보다 빠르게 받아들이고 위의 두 번째, 세 번째 스텝을 밟아나가는 것이 훨씬 더 도움이 됩니다.

 

위 네 개의 스텝을 인지하고 하나씩 밟아나가고 여러 번 돌다 보면 제가 생각하는 '좋은 개발자'에 한 걸음 가까워지리라 생각합니다.

 

3. 앞으로의 계획은?

 

약간은 구체적으로 회사에 도움이 되기 위한 일들을 적어놓고 하나씩 도전해보려고 합니다

 

3-1. 통합로그 수정

 

현재 회사에서는 elk 스택을 적용해서 통합로그를 쌓고 관리하고 있습니다.

 

도입한 지 얼마 되지 않았고 elk의 기능, 장점을 정확하게 이해하고 쓰는 팀원들이 많이 없다 보니 오히려 비효율적인 통합로그를 사용하고 있다고 생각이 들었습니다.

 

앞으로 통합로그를 구조화하는 방법들에 대해서 스터디를 통해 이야기를 많이 나누고 개선을 해보려고 합니다.

 

3-2. 결제 프로세스 시각화 자료 공유

 

아무래도 항공 도메인이다 보니 우리가 흔히 알고 있는 결제 시스템에서 추가되는 부분들이 많습니다.

 

각 유닛별로, 파트별로 많이 사용하고 있는 결제 프로세스가 조금씩 다르다 보니

 

전체적으로 통합된 결제 프로세스를 확인하려면 꽤나 리소스가 많이 필요하고 사실 모든 결제 프로세스를 아는 사람이 없다고 판단했고 비효율적이라고 생각했습니다.

 

전체적인 결제 프로세스를 조금씩 정리해서, API문서와 시각화된 자료로 만들어서 전사에 공유할 예정입니다.

 

3-3. Sentry 도입 및 유실되는 데이터, 예외 관리

 

항공도메인이라 외부서비스로 요청을 보내고 응답을 받아서 처리해야 하는 로직이 필수적입니다.

 

그만큼 의존성이 강해서 해당 요청과 응답이 유실되면 큰 문제로 이어질 수 있지만 현재는 통합로그로 관리되고 있는 상황입니다.

 

제가 콴다에서 사용했던 Sentry를 클라우드가 아닌 폐쇄망에 적합한 온프레미스환경으로 구성해서 테스트를 거친 뒤에 팀원들에게 장점을 어필하고 공유해보려고 합니다.

 

오픈 소스를 이용해서 적은 리소스로 충분히 활용 가능한 모니터링이 가능하다는 것을 증명해보려고 합니다.

 

4. 정리

 

이렇게 줄 글로 길게 정리를 해보니까 정리가 많이 되는 거 같고 제가 지금까지 어떤 마음가짐으로 회사를 다니고 있고 현재 중요하게 생각하는 가치가 무엇인지가 단번에 보이는 것 같습니다.

 

제가 앞으로 해야 할 일들을 미루지 않고 빠르게 실행에 옮기며 '좋은 개발자'로 성장하는 과정들을 꾸준하게 블로그에도 기록해보려고 합니다.

 

긴 글 읽어주셔서 감사합니다.

 

 

반응형