2022년 하반기 회고, Let's focus on impact - 업무편
포스트
취소

2022년 하반기 회고, Let's focus on impact - 업무편

지난 일상편 회고에 이어서 업무편 회고를 이어서 써보려고 한다.

나는 작년에 이직 후 어떤 점들을 느꼈나?

하반기동안 어떤 일을을 했나? 어떤 문제들을 해결했나?

내 가치를 증명해야 한다는 조급함

가장 크게 느꼈던 것은 조급함이었다. 첫 이직이다보니 더 크게 느꼈던 것 같다. 워낙에 책임감을 강하게 느끼는 성격이어서 그런 것도 있다.

하지만 이직한 사람은 누구든 업무 능력이 제로부터 시작한다. 회사의 시스템을 전혀 모르고 업무 문화도 전혀 모른다. (심지어 나는 팀원들도 모두 초면이었다)

업무 능력을 키우기 위해서 학습이 필요하다. 보통 이것을 “온보딩”이라고 부른다.

나의 온보딩 과정 중 서버 개발자로서의 온보딩은 아래와 같이 구성되어 있다.

  • 개발환경 설정: 맥북 환경설정, 프로그램 설치, 권한 신청, 라이센스 등 구매 신청
  • 데모 프로젝트 배포 실습: 배포할 서비스 등록 및 배포 프로세스 이해
  • 운영 서버의 간단한 feature 개발 및 배포: Canay 배포, 배포 모니터링 이해
  • 인프라 아키텍처 이해

이 과정에서 질문들이 굉장히 많이 생긴다. 가이드 문서를 읽다가 이해되지 않는 부분 등등 질문이 무수히 많아진다. 이런 질문들이 생길 때마다 팀 슬랙 채널에 질문했다.

위와 동시에 입사 서류 작업, 신규 입사자 세션 등 해야할 일이 많았다. 아무것도 안 했는데 1개월 2개월이 순식간에 흘러갔다. 업무 능률이 전혀 나오지 않았고 여기서 조급함을 느꼈다.

이렇다보니 팀에 도움이 될 수 있는 내가 당장 할 수 있는 간단한 feature들을 랜덤하게 처리했다. 하지만 그러한 일들은 임팩트나 영향력이 크지 않았고, 중요하지 않았다.

돌아보면 조급함을 느낄 것이 없었다. 팀에 도움이 안되는 것은 당연한 것이었고, 나비가 번데기의 시기를 거치듯 온보딩 시기에는 만반의 준비를 하는 것이 최고의 투자였다.

피드백, 조심스러움과 과감함 (Courage to fail fast)

신규 입사자는 동료들에게 1.5개월 후, 3개월 후에 한 번씩 피드백을 받을 수 있다. 그 때 받은 피드백들을 한 문장으로 표현해보면 아래와 같다.

Courage to fail fast: 실패를 너무 두려워하지 말고 빠르게 실패해라.

ref: https://blog.toss.im/article/core-values-are-evolving

신규 입사자는 모르는 것이 많기 때문에 어떤 생각이 떠올라도 그것을 행동으로 옮기기 어렵다. 자신의 판단이 옳다는 확신이 없기 때문이다.

거기에 나의 조심스러운 성격까지 더해져 불확실한 일에 나서지 못했던 것 같다.

예를 들면 나에게 배경지식이 전혀 없는 업무, 내가 해낼 수 있을지 모르는 업무에는 나서지 못했다.

하지만 그런 업무들에도 과감하게 도전해보라는 것이 팀원들의 피드백이었다. 물론 실패라고 거창하게 말하기엔 그렇게 큰 업무들은 아니었다.

그러한 피드백을 받은 후 조금더 자신감있게 업무에 참여하려고 노력했다.

이 글을 쓰면서 한 가지 생각이 들었다. “나는 지금도 이 가치를 잘 실천하고 있나?”

NOTE: 물론 Courage to fail fast의 의미가 서비스 장애가 나도 상관없다는 의미는 아니다. 음 좋은 사례들을 참고해보면 좋을 것 같은데, 찾아봐야겠다.

한 가지에 집중하기, 임팩트에 집중하기. (Focus on impact)

요즘 매일 스스로에게 리마인드하는 말 중 하나가 “Focus on impact”라는 문장이다.

그 자체로는 의미있는 일이지만 전체적으로 봤을 때 중요하지 않은, 임팩트가 크지않은 일들에 시간을 빼앗기는 경우가 꽤 자주 발생한다.

가장 많은 실패 예시는 리팩토링이다. 리팩토링 업무가 어떤 임팩트있는 업무를 위한 준비 작업이 될 수도 있지만, 때로는 명확한 목표없이 그냥 해놓으면 좋은 것이라는 생각으로 수행되기도 한다.

예를 들어 이상한 DB 컬럼 이름을 바꾸는 업무에는 적지 않은 비용과 노력이 들어가지만, 그 업무가 항상 큰 도움이 되지는 않는다. 이것은 그 문제가 얼마나 자주, 얼마나 큰 문제를 일으키고 있느냐에 따라 다르기 때문이다. 이러한 맥락을 고려해서 이 업무가 진짜로 해야할 업무인지 빠르게 판단할 수 있어야 한다.

하지만 임팩트있는 업무들은 보통 더 어렵다. 더 많은 배경지식이 필요하고, 더 오래 걸린다.

예를 들면 이러한 업무다: 로그에 parent span id가 포함되도록 수정하고, 잘못 연결된 parent span id가 있으면 fix하는 것이다. 이 업무는 서버들이 로그를 남기는 구조(MDC, logback config, MVC Filter config)를 알아야 하고 로그 적재 과정(ELK) 또는 istio/envoy에서 trace id, span id를 어떻게 relay하고 있는지 알아야 할 지도 모른다.

기술적으로 어려운 문제가 항상 임팩트있는 업무는 아니다. 불확실해보이는 업무일수록 임팩트가 큰 경향은 있는 것 같다.

그리고 여러 가지 서버(마이크로서비스)들에 기여하다보니 서버를 개선한 성과 또는 기여 효과가 뚜렷하게 보이지 않았다. 명확한 목표없이 눈에 보이는 일부터, 급한 일부터 보이는대로 했다고 회고한다. 이를 해결하기 위해:

  • 명확한 목표를 정의하고: 어떤 서버의 어떤 문제를 얼만큼 개선할 것인지
  • 그 서버에만 최대한 집중하기(focus)

요약하면, 명확한 목표를 정의하고 그 목표를 따라서 일하자. 그리고 임팩트있는 일에만 집중하자. 라고 회고한다. 요즘도 매일 리마인드 하고있는 문제다.

Conclusion

이직 자체를 통해 기대한대로 배우는 점들이 많아서 보람있었다. 2023년에는 독서, 운동 등 몇몇 목표를 세우고 나름 잘 실천하고 있다.

회고 작성을 자꾸 미루다보니 벌써 4월 중순이다. 상반기도 얼마 남지 않았다. 이번 상반기에는 여기서 회고한 내용들을 최대한 개선할 수 있도록 노력해야겠다.

아, 그러고보니 원래 생각했던 “어떤 일들을 했나?”는 작성하지를 않았네… 이것도 다음 포스트에 꼭 작성해봐야겠다.

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

JPA: optimisstic lock vs pessimistic lock

[TIL] JIT compiler in Java HotSpot VM, and C1 vs C2 compiler mode