본문 바로가기
Daily Life/Retrospect

2022년도 개발인생 연말정산

by devson 2022. 12. 27.

2022년 짧은 소회

개발을 업으로 삼은지도 5년이 가까워지고 있다.

 

예전에는 막연히 연차가 높아지면 개발이 더 쉬워질 줄 알았는데,
오히려 아는게 더 생기다보니 필요 이상으로 생각을 하는 경우도 생기고 가끔은 단순할 수 있는걸 더 꼬아서 생각할 때도 있어서 여전히 개발은 쉽지 않은 것 같다.

그래도 개발을 하면서 어느 부분을 더 신경을 써야할지, 문제가 생길 만한 부분은 어디인지 보이는게 많아지는 것 같다.

 

또 예전에는 기술적인 것만 팠었는데 서비스 사용성이나 프로젝트 매지닝 같은 부분도 신경을 쓰게 되는 것 같다.

(그런걸 메인으로 고려해야하는 포지션에 있는건 아니지만 업무에서 중요한 부분이니...)

그리고 나이도 먹어가고 경력이 쌓이면서 말에 영향력이 생기는 것을 느낀다.

"권력이 생긴다"라는 뜻 보다는 내 말로 인해서 누군가의 감정이나 결정 등의 변화가 좀 더 직접적으로 느껴지기 시작했다.

나는 나를 예전의 나로 생각하지만, 회사나 동료를 포함하여 내가 속한 환경과 주변은 변해가기 때문에 나도 그에 맞춰가야함을 느낀다.

 

2022년은 그냥 이것저것 해야할건 많다고 생각하고 찍어만 보다가 뭐 하나 진득하게 잡은건 별로 없는 것 같다.

개인적으로 임팩트가 없다고 해야하나...

그래도 이직을 하면서 시야가 넓어지는게 목표였었는데 새로운 도메인과 처음으로 C2C 비즈니스를 경험하기도 하고,
새로운 도메인과 환경에서 개발을 하다보니 기존에 경험했던 것과는 다른 시야가 보이는 것 같다.

 

월간 리포트

1월

새해 첫번째 월에 회사를 퇴사했다.

이직을 결정한 뒤, 작년(2021년)에 8월에 우리 부모님 세대도 말만 하면 다 알만한 빅테크 기업에 최종 합격까지 했지만, 아직 서비스가 출시되지 않은 스타트업을 선택했다.

 

당시에 그런 결정에는 경험하고 싶었던 도메인(커머스)이었기도 했지만, 무엇보다 '스타트업 + 초기 멤버 뽕'에 취해있었기 때문이었던 것 같다.

그동안 스타트업을 다니면서 여러 도메인과 역할을 맡으며 개발/비개발적으로 많은 것을 배울 수 있었기도 했고,

몇 년 동안 운영이 되던 서비스를 중간에 투입되어 개발했었는데, 출시가 되지 않은 제품을 만들고 키워가는 경험을 하고 싶었다.

(내가 조인할 때는 이미 오랫동안 개발되었었고 막판으로 가는 중이었지만..)

 

당시 서버는 MSA를 채택하여 각 도메인 마다 서버와 DB가 분리되어있었고, 나는 각 도메인들의 데이터를 수집하고 프론트에 필요한 형태로 가공하여 뿌려주는 전시 도메인을 맡았다.

 

하지만 당시 이미 제품 출시가 여러 번 연기된 상황이었고, 광범위한 제품 기획 범위, MSA로 인한 통합 불안정 등 상황이 안좋게 돌아갔었다.

나름 경력직으로서 제품 개발 방향을 개선해보려고 여러 의견을 내고 HR, 리더와 여러 얘기를 나눠봤지만 결과적으로는 회사의 상황 상 무엇보다 출시가 먼저였던 상황이었고,

힘들어도 어떻게든 버텨보려고는 했지만 정신적으로 많이 지쳐서 4개월 만에 퇴사를 결정하게 되었다.

 

비록 내가 그곳에서 무언가를 이루고 당당하게 퇴사한 것은 아니었지만,

기술적으로는 CQRS 경험해봤고, 그 외로는 제품을 어떻게 만들어가야할까에 대해 많이 고민할 수 있었다.

또한 'What도 중요하지만 그만큼 How 역시 중요하다'는 내 생각이 더욱 굳어지게 되었다.

 

2월

이전 회사를 다니면서 정신적으로 너무 지쳐서 쉬면서 공부도 하고 구직을 하며 지냈다.

 

뒤돌아보니 이직할 회사를 정하지 않고 구직을 하다해서 당시 마음이 조급했었는데,

구직 과정에서 좀 더 많은 회사를 알아보고 지원해볼 걸하고 후회가 된다.

 

3월

한 달 정도 구직기간을 거쳐 현재 회사에 입사했다.

이 회사를 선택한 이유는 무엇보다도 수세대 이전부터 이어져온 고질적인 사회적인 문제를 푸는 조직이라는 점이었다.

개인적으로 개발을 통해 제품을 만드는 것도 좋지만, 제품을 통해 사회에 공헌할 수 있다면 내 일이 더욱 보람차다고 생각한다.

게다가 이미 다른 유명 기업에서 여러 경험을 한 좋은 개발자들이 있었기에 이 회사를 선택을 하게됐다.

 

입사 후에는 온보딩 프로세스를 밟으면서 회사 인프라, 개발 방법에 익숙해졌다.

이런 개발자 온보딩 프로세스는 처음 경험해봤는데, 나중에 조직을 만든다면 온보딩 프로세스를 만들어가는 것을 높은 우선순위에 두어도 되겠다고 생각할 정도로 직원 경험에 있어 좋은 영향을 받았다.

 

또 입사 직후가 상대적으로 시간이 널널한 기간이기에 도메인 지식과 팀원들과의 신뢰 자본을 쌓기 위해 도메인을 가리지 않고 PR을 살펴보고 간단히 코멘트를 남기려고 노력했다.

(아무리 좋은 지식과 옳은 방향일지라도 신뢰와 친분이 없는 상태에서 다른 의견을 낸다면 거부감이 들기 마련이다)

 

덕분에 팀원들과 더 쉽게 가까워질 수 있지 않았을까 싶다 :)

 

4, 5월

당시 서비스에 빌링/정산 기능을 넣고자하는 니즈가 있었고, 나는 빌링/정산을 위한 주변 기능인 예약근무 기록에 대해 개발을 시작했다.

 

페어 프로그래밍으로 기존에 있던 팀원과 작업을 하였는데, 페어로 작업을 하니 기존 회사의 코드와 회사 제품의 방향에 대해 실시간으로 들을 수 있어서 개발을 하는데 있어서 부담이 많이 줄었던 것 같다.

 

6월

회사에 사업 전략과 제품 개발 방향이 틀어져서 그동안 개발하던 것을 잠시 중단하고 사용자의 사용성을 끌어올리는 작업을 하였다.

기존에 작업했던 것들을 뒤로 해야하니 아쉽긴 했지만, 새로운 제품 개발 전략으로 짧은 시간에 여러 기능을 사용자들에게 전달해보고 실험할 수 있었다.

 

또 새로운 기능을 개발하면서 얻은 지식과 경험을 그대로 휘발시키기엔 아쉬워 회사 기술 블로그에 글도 하나 작성했다.

https://tech.mfort.co.kr/blog/2022-07-12-chat-image-upload/

 

AWS 인프라 위에서 채팅 이미지 업로드부터 조회까지 - 맘시터 기술블로그

채팅 이미지 업로드 기능을 개발하며 익힌 지식을 공유합니다

tech.mfort.co.kr

 

7, 8월

다시 빌링/정산 기능 개발을 재개했다.

전에는 관련하여 예약과 관련된 부분을 작업했는데, 기획 방향이 뒤바뀌고 팀 편성도 바뀌게되어 빌링/정산 파트를 개발하게 되었다.

 

처음 맡아보는 도메인이지만 기존에 해당 파트를 작업하셨던 분과 함께 개발을 하였기 때문에 돈을 다루는 일이었지만 부담이 상대적으로 덜했다.

하지만 당시 시간적 여유가 거의 없다시피 하여 밤낮으로 영혼을 갈아넣어 개발했고 일정에 맞춰 8월에 빌링/정산 기능이 무사히 오픈되었다.

 

처음에는 개발을 하면서도 과연 사용자들이 많이 사용할까? 하며 반신반의 했었지만, 실제로 오픈 당일에 결제가 일어나기도 했고

현재까지 (구체적인 금액을 쓸 순 없지만) 달마다 많은 금액의 결제가 일어나고 있어 고생한 보람이 있었고 회사에 실질적으로 기여를 할 수 있어서 의미있는 프로젝트였다.

그렇지만 동시에 시간적인 제약으로 기술적인 완성도가 떨어진게 아쉬움으로 남는다. 이렇게 경험이 쌓이고 교훈이 느는 거겠지...


8월 말에 둘이서 밤낮없이 빌링/정산 기능을 함께 개발하고 고생하셨던 팀원 분이 나가셨다... ㅠ

경력 자체가 많으시기도 하고 생각의 관점이 많은 분이셔서, 같이 협업하면서 기술적으로도 많이 배우고 평소에 내가 보는 관점과는 다른 측면에서의 생각을 배울 수 있었는데 퇴사를 하시게되어 매우 아쉬웠다.

 

9~12월

기존에 있던 서버 개발자 팀원분이 나감으로써 팀이 1인 서버 개발 체제로 돌아가고 있었는데,

회사에서 내가 맡은 파트의 추가 사업 투자로 인해 다른 팀에 있던 분이 우리 팀으로 들어오게 되었다.

하지만 당시 그 과정이 매끄럽지 않았고, 당사자만큼 그 결정에 대해 나도 의아한 부분이 많아 처음 영입 과정에 있어서 유쾌하진 않으셨을텐데 그 부분에 있어서 죄송했고 잘 해드려야겠다고 반성을 했다.


이 기간 동안 주로 사용성 개선 작업을 했는데, 큰 프로젝트를 진행하지 않아 기술적으로 대단한 것을 하진 않았지만

대신 기존 코드를 자주 건드려야 했어서 설계 결정에 따른 트레이드 오프에 대해 많이 생각할 수 있게되었다.


10월에는 사내 개발팀이 3-tier 구조의 좁은 시스템 규모로 인해 시스템 설계에 대한 시야가 좁아지는건 아닐까라는 생각이 들었다.

이에 동기를 받아 블로그에 Redis를 활용한 다양한 시스템 설계 라는 글을 썼고, 이를 토대로 사내 발표도 하였다.

(시간이 촉박해서 급하게 진행했는데 잘 전달이 되었는지 모르겠다 😇)

 

블로그 글은 3주 가량 쓴 글인데, 왜인지 모를 바이럴이 타서 신기한 경험도 해봤다.

 

스터디

  • 인프런 - 스프링 핵심 원리 - 강의 (강의형)
  • GoF 디자인 패턴 (강의형)
  • 이펙티브 코틀린 - 책
  • 테스트 주도 개발 시작하기 - 책
  • 도메인 주도 개발 시작하기 - 책
  • 클린 코드 - 책
  • 클린 소프트웨어 - 책 (강의형) - 진행 중

 

2023년 플래닝

그동안은 목표가 에게 초점이 맞춰져 있었다.

주로 개인의 성장과 경험에 관련된 것이었는데, 내년에는 그동안 겪은 경험들을 통해 내 주변에 성장을 도와주는 역할이 되었으면 좋겠다.

 

그리고...

내년엔 새로운 프로그래밍 언어를 사용해보고 싶다.

 

'Daily Life > Retrospect' 카테고리의 다른 글

스터디 회고 - 스프링 핵심 원리 기본편  (0) 2022.01.16

댓글