2024 개발자 회고

개발자 포커싱하여 회고를 적어볼까.

 

올해는 달마다 적는 월간회고도 거~의 안적고, 그냥 마냥 바쁘게만 살았던 것 같다. 근데 그러다보니까, 막상 1년이 지나고 내가 뭘 했지? 하니까 떠오르는 게 없다. 그나마 다행인건 8월 이전까지는 데일리 업무일지를 꼬박꼬박 써놨어서 확인이 가능했다. (8월 이후에 한 업무는 가장 최근까지 진행했어서 그래도 기억이 난다.)

이래서 주기적으로 적고 업데이트를 해둬야해.

 

================================================

2024 타임라인
1월 [VoC] 회원가입 프로세스 간소화 & 정보 동기화
2-3월 [VoC] 요금제 전환
4월 신규 클러스터 연동
4-6월 프로젝트 시작 - 분석/설계
4-6월 요금제 전환 안정화
7월 쿠버네티스 포팅 & Java/Spring 버전 업그레이드
8-11월 빌링/정산 분리
12월 빌링/정산 분리 안정화 & 프로젝트 파트 업무 전환

12월 사내 세미나 발표

================================================

 

1분기, 이직하고 3개월. 회사와 업무에 적응하는 시간이었다.
다양한 서비스를 운영/개발하는 팀에 있다보니, 크게 3가지 부문에서 적응이 필요했다.
근데 참 재밌게도(사실 재미없음) 1년이 지난 지금도 이 세 가지에 대해 계속해서 역량 강화가 필요하다.

1 운영/유지보수 개발

• "달리는 기차의 바퀴 갈아끼우기"
• 1분기에 진행한 VoC 에서 예상하지 못했던 버그와 사이드 이펙트를 생성하면서, "기존에 잘 돌아가고 있던 걸 망가뜨리는 행위" 에 대해 민감하게 반응하게 되었다.
• 예상치 못한 사이드 이펙트가 발생했던 이유는?
  • 1) 도메인 이해도 부족: A 를 고쳤는데 (전혀 관계 없다고 생각한, 아니 정확히는 있는지도 몰랐던) C 에서 버그가 발생했다.
  • 2) 테스트 부족: 액션이 발생하는 케이스가 너무 많아서 모든 케이스를 테스트하지 못함. 대표 케이스만 테스트했으나, 디테일 옵션에서 버그가 발생
• 3분기에 진행한 파트에서는, "기존에 잘 되던게 안되요" 소리가 안나오도록 하고 싶었다.
  • 1) 잘한 점: 테스트케이스를 자세히 작성 & 통합 테스트 진행 & 테스트 일정을 길게 가져감 (3주)
  • 2) 못한 점: 코드 수정에 소극적이었다. 리팩토링을 할 만한 부분이 있는 코드도, "지금 잘 돌아가고 있는 걸 건드는 건 리스크" 라고 판단해서 최소 수정으로 리팩토링함.
  • -> 잘한 점: 버그가 2건 정도 있었는데, 다행히 보정 기능이 이미 구현되어 있는 케이스였고 이외에는 사용자에게 이슈 리포팅 받은 건이 없었다.
• -> 여전히 남아있는 문제: 어떻게 하면 테스트를 잘 할 수 있을까? 이게 테스트 코드/ 테스트 자동화로 해결할 수 있는 영역일까? 테스트 커버리지를 높이기 위한 효율적인 방법 은 무엇일까?
• -> "달리는 기차의 바퀴 갈아끼우기" 는 피할 수 없는 숙명: 과도한 스트레스는 나만 손해. 최선을 다하되, 필요 이상으로 예민하지 말자. 
  • 98년도에 퇴사한 박종갑과장님 찾아올 거 아니면 돌아가고 있는 코드는 건들지 않기 vs 그럼에도 불구하고 개발자라면 리팩토링

2 컨텍스트 스위칭

• 여러 개의 서비스가 있고, 여러 유관부서로부터 이슈가 들어온다.
• 그 때마다 컨텍스트 스위칭이 일어나고, 스위칭을 위해 필요한 시간을 줄여 나가는 것이 필요했다.
• 그게 정말정말 어려워서, A업무 하다가 B업무 확인해야하면 돌아오는데 시간이 걸리고, 또 중간에 회의 다녀오면 앞서 진행했던 컨텍스트가 휘발되고,....
• -> 여전히 남아있는 문제: 시간이 지나면 익숙해지겠지 싶었는데, 이렇게 휘발되고 시간 날아가는 현상에만 익숙해졌고 전혀 해결을 못하고 있다. 조치가 필요한데 뭘 어떻게 해야할지 감도 안온다... 그저 리더님이 다 협의하고 정해주신 내용으로 개발만 하던 때가 그립다...

3 유관부서 협업

• 여전히 어려운 부분 중 하나인데, 전 직장에서는 혼자 (혹은 같은 팀 팀원) 하던 일을 모두 다른 부서/팀과 협업해야 한다.
• 최근 들어 커뮤니케이션 역량이 더 필요해졌다. A팀 개발일정 - 우리팀 개발일정 - B팀 개발일정 을 유기적으로 연결하여 확인해야 하는 일이 많아졌다. (그런데 모든 태스크가 이런 식인)
• 여기서 어느 한 파트라도 일정이 변경되면, 우리 팀 일정에도 영향이 가기 때문에 정확한 커뮤니케이션이 필요해졌다.

4 리딩이요? 제가요?

• 2025년 전보 발령이 났다. 파트 리딩을 해줬으면 한다는 본부장님의 청천벽력같은 말씀. 리딩이요? 제가요?
  • 이번 전보 발령에 본부장님의 의견이 많이 들어갔고, 본부장님이 나를 픽해서 옮겼다는디....... 도대체 웨.. 저의 뭘 좋게 보셨다는건지? 그냥 써먹기 좋은 나사떼기 1로 보였던걸까
• 내 일만 잘 하면 되었는데, 이제는 다른 팀원의 진행 상황을 파악하고, 이슈가 있으면 해결방안을 고민하고, 내 선에서 해결할 수 없는 일은 빠르게 에스컬레이션 해야 한다.
  • "내 선에서 해결할 수 없는 일" 의 기준이 나와 상사가 다를 때마다, 팀장님이 생각하는 기준이 어디인지 아직 판단하기가 어렵다. 전/현 팀장님의 성향이 꽤나 다른데, 지금의 나는 전 팀장님의 기준에 맞춰서 생각하고 있기 때문인 것 같다.
  • 넵무새가 되지 말자: 나 혼자 일할 땐 [나: 이거 해주시겠어요? 나: 넵] 하면 되었는데, 이젠 내가 넵하면 팀원이 힘들어지거나 vs 팀장님에게 다시 에스컬레이션 되거나가 되었다. 
    • 의사결정을 해야 하는 문제에는, 이것이 "누가" "어떤 문제를 해결하기 위해" 나온 요구사항인지, 그래서 우리 팀이 "왜" 이 요청을 받아들여서 해야하는지 를 생각해보자. "왜" 가 합당하지 못하면 넵 하지 말자.
    • 넵 할 수 없는 일이면, 대안을 제시하자. 부탁이 아니라 솔깃한 제안을 합시다
• 회사와 팀에 적응하였다... 라고 생각할 때 쯤 전보 발령이 나서 좀 슬펐는데, 뭐 어쩌겠어 새롭게 다시 잘 해봐야지.