커리어 전환에 성공했고 정말 성공했나? 개인적으로 아쉬운 점들이 조금 있지만 만족합니다. 그러던 와중 지난 7개월은 어땠는지 기록해놓고 싶었습니다. 지나고 보니 생각보다 많은 일들이 있었고 압축된 시간동안 많은 경험을 하게 된 것 같습니다. 사실 수습기간이 끝나고 쓰려했는데 미루고 미루다가 잠이 안오는 김에 남겨놓으려 합니다.

주의: 주저리 주저리 개인적인 생각과 경험을 시간대 별로 두서 없이 풀어놓은 것이라 혼란스러우실 수 있습니다.

입사 초기

온보딩과 전반적인 분위기를 파악하기 위해 출근을 하고 있었는데, 출근 한 지 이틀만에 A형 독감판정을 받고 5일간 격리되었습니다. 발을 내딛기도 전에 퍼져버린 셈이 되었죠.

돌아와서 온보딩을 재개하는데 이전에 진행했던 것들이 거의 머릿속에서 초기화되어 처음부터 다시 진행해야했습니다. 팀 내의 온보딩이 프로세스화 되어있지 않았고 무엇을 해야하는지 동료들의 기억과 경험에 의존했어야 했기 때문에 조금 혼란스러웠습니다. 전에는 큰 회사에 있었어서 몰랐는데 비교적 작은 회사로 가면 갈 수록 이런 일이 더 많지 않을까? 라는 생각이 들긴했습니다.

기왕 처음부터 다시 하는 김에 적어도 반드시 해야할 것들은 정리해놓고 다음에 합류할 동료들이 참고하면 좋지 않을까 싶어서 온보딩 때 진행해야 하는 것들을 정리하기 시작했습니다. 여기서 문서화는 정말 중요하고 어렵다는 것을 새삼 다시 깨닫게 되었고, 업무 진행 할 때마다 문서화와 공유에 대해 계속 고민하게된 계기가 된 것 같습니다.

수습 기간: 인터뷰어, 장기화 된 리모트, 많은 동료들의 합류

수습 기간 동안은 회사 전반적으로 업무를 정리하는 기간으로 인해 바쁘진 않았습니다. 어느 수준의 퍼포먼스를 보여줘야할 까라는 고민을 했지만 조급하진 않았고 나름 순탄하게 진행되었던 것 같습니다.

수습 기간 동안 두 세차례 인터뷰어로 인터뷰에 참여하게 되는 새로운 경험을 하게 되었습니다. 전체적인 흐름은 기존의 팀원분들께서 이끄셨고 저는 주로 CORS, SOP, JS 엔진의 GC가 어떻게 동작하는지, HSTS는 무엇인지 등에 대해 이야기를 나눴습니다. 지금 다시 인터뷰어로 참여하게 된다면 기술적인 내용 뿐만 아니라 좀 더 다양한 시각을 가지고 심도 깊은 이야기들을 나눌 수 있을 것 같다는 생각이 들면서 새삼 과거의 제가 부끄러워 지는군요.

그 이후, 코로나로 인해 리모트가 장기화되었고 새롭게 많은 동료분들께서 합류하였습니다. 다양한 배경의 좋은 동료들이 많아져서 너무 좋았고 이는 실제로 코드리뷰에서 큰 이점으로 드러나고 있습니다. 온보딩이 온라인으로 진행되어 약간 걱정했었는데, 입사 초기에 정리해놓았던 것들이 도움이 되셨다고 합니다. 사실 이렇게 빨리 적어놓은 것이 다시 읽히게 될 줄 몰랐습니다.

코로나로 인한 리모트 근무가 장기화되면서 업무프로세스와 생산성에 대해 자연스레 관심을 갖게 되었고 어떻게 일을 해야 효율적일까 라는 생각을 하던 와중 다른 팀에 계셨던 시니어분께서 팀에 합류하게 되며 이는 가속화되었습니다.

아주x100 잠깐이지만 리딩에 대한 고민

수습 기간 이후 인원이 많아졌기에 프로젝트를 진행할 때, 소규모로 팀을 쪼갠뒤 리더를 정하고 리더가 프로젝트를 리딩하는 게 어떨까라는 의견이 팀 내에서 나왔고, 소규모 팀을 리딩하게 되었습니다. 프로젝트에 대한 배경 지식이 전혀 없었고, 다른 팀원들을 리딩한 경험이 전혀 없었기 때문에 막연함과 막막함이 몰려왔습니다.

다행히(?) 요구사항 분석/리서치 과정에서 쪼개진 소규모의 팀이 다시 합쳐지면서 리딩을 하지 않게 되었지만 이 짧은 시간동안 수많은 고민과 깨달음을 얻게 되었습니다. 아직 리딩할 능력과 커뮤니케이션 능력이 많이 부족하다고 느꼈고 아직 더 성장해야 하는 구나라고 느꼈습니다.

이 과정에서 든 생각들은 아래와 같습니다.

  • 나는 주어진 업무를 명확하게 파악하고 있나? 아무것도 모르는데 리딩을 어떻게 해요
  • 어떻게 팀원들에게 방향성을 제시하고 설득하지?
  • 어떤 기준을 가지고 업무를 쪼개지?
  • 어떤 기준을 가지고 적절한 일정을 추정하지?
  • 어떤 기준을 가지고 퍼포먼스를 측정하지?
  • 업무의 어느 수준, 지점까지 내가 관여 할 수 있는거지?
  • 너무 먼 미래를 생각하긴 했는데 나아가서 업무로 인해 팀원들이 성장할 수 있을까?

확실히 일을 하는 것과 리딩하는 것은 완전 다른 영역이라고 생각했고, 둘 다 잘하는 것은 굉장히 어려운 일이겠구나라고 생각했습니다. 아마 둘 다 잘해내는 사람은 많이 않을 것 같다는 생각이 들었습니다.

나중에 언젠가 리딩하게 될 일이 생기면 다시 고민하게 되겠지만 짧게나마 고민해본것이 나중에 도움이 되지 않을까라는 생각은 하고있습니다. 이 경험이 저의 성향과 앞으로 방향성에 대해 꽤 오래 생각하게 된 계기가 되었는데, hands-off 보다는 hands-on이 잘 맞지 않을까라는 생각을 가지게 되었고 이것은 계속 고민해봐야 될 것 같습니다.

1 on 1 에서 받은 피드백

Lead 분과는 1 on 1 을 두 차례 진행했었고, 다른 팀원들 몇몇 분과도 1 on 1 을 요청받아서 진행하게 되었습니다. (1 on 1 은 쉽게 얘기하면 그냥 1:1 인터뷰라고 생각하면 됩니다.)

이전 회사에서는 거의 경험해보지 못했었고, 이것 또한 새로운 경험으로 다가왔었습니다. 평소에 얘기하지 않았던 진솔한 얘기들을 나누게 되었고 받은 피드백 중 하나는 좀 더 적극적인 자세를 보여줬으면 좋겠고, 의견을 피력했으면 좋겠다 였습니다.

스스로 생각을 해보니 그랬었던 이유는 아래와 같았던 것 같습니다.

  • 아직 업무 파악이 끝나지 않았다 + 내가 뭘 해야할 지 명확히 모른다
  • 질문에 대한 막연한 두려움
  • 커뮤니케이션에 대한 부담감
  • 완벽히 아는게 아니거나 경험해보지 않는 것에 대해 안다고 말할 수 있나?

시간이 지나고나니 괜찮아진 부분들이 많은데, 마지막에 언급한 생각 때문에 뭔가 좀 소극적인 자세가 되지 않았나 싶었습니다. 요즘은 여기저기 질문을 많이 하고 다니고 어느정도 극복하고 개선이 된 것 같은데 다음 1 on 1 때 다시 피드백을 받아봐야 할 것 같습니다.

우리 팀은 과연 일을 잘하고 있을까?

우리 팀은 JIRA로 일감을 관리하고 팀 보드를 따로 가지고 있었지만, JIRA 생성해주는 리포트들을 보면서 일을 하고있진 않았습니다. 또한 Lead 분께 집중되어있는 일감을 분배하는 방식으로 일을 하고 있었기 때문에 체계적으로 일하는 느낌은 아니였습니다.

위에 언급되었던 시니어분께서 현재 상황과 리포트를 보고 업무프로세스를 다시 정립하는게 좋을 것 같다는 이슈 라이징을 하셨고, 우리 팀의 업무 방식을 개선하려면 어떻게 해야할까를 다 함께 고민하고 JIRA를 적극 활용하며 재정립하게 되었습니다. 이 과정을 겪으면서 도대체 Agile은 무엇일까를 계속 고민해보고 있는데, 아직도 정확히 무엇인지는 잘 모르겠습니다.

사실 더 개선된 점이 많고 다양한 시도들을 하고 있지만, 그 중 일부를 나열해보자면 아래와 같습니다.

해야할 일을 만들어놓고 진행하지 않는다

이런 경우들은 과거에 해야했던 일인데 어떤 이유로 진행을 보류한 경우이거나 우선순위가 높지 않은데 해야하는 일이긴 해서 만들어진 경우가 대다수였습니다. 간혹 퇴사자분들이 만들어 놓고 간 이슈들도 있긴했고, 이미 완료된 일인데 간혹 남아있는 경우가 있었습니다. 이것은 JIRA의 필터를 통해 걸러낸 뒤, 팀원의 합의 하에 이슈를 닫거나 삭제했습니다.

머지가 너무 느리다

점검해본 결과 우리팀의 업무 Cycle 중 병목은 리뷰에서 머지로 가는 시간이였습니다. 대부분 릴리즈 일정이 변경되어 리뷰의 Approve를 모두 받았는데 머지되지 않는 경우였고, 리뷰어를 리뷰를 기다리고 있거나 Approve 받은 PR을 단순히 머지하지 않는 경우가 있었습니다. 이로 인해 팀내 머지룰을 다 같이 점검하게 되었습니다.

머지 속도를 높이기 위해 레포지토리마다 code owner를 두고, owner외에 1~2명 이상의 리뷰어를 지정하여 절반의 owner와 지정한 리뷰어로부터 Approve를 받으면 누구나 머지할 수 있다는 룰을 만들었습니다. 또한, JIRA에서 PR 리뷰를 받을 수 있는 이슈의 상한선을 두고 넘어가면 알람을 줘서 상한선에서 내려올 때 까지 팀원들이 하던 일을 잠시 멈추고 리뷰를 진행하기로 협의했습니다.

사실 이것은 정답은 없는 것 같고 팀의 상황에 맞는 룰을 협의하에 만드는 것이 가장 중요하다고 생각합니다.

하나의 이슈 단위가 너무 크거나 어느 범위까지 해결해야 할지 기준이 모호하다

이슈 생성할 때 어떤 이슈인지 명확히 title과 description을 작성하는 것이 중요하다는 것은 모두 알고 있는 사실이지만, 실제로 만들다보면 그것이 참 쉽지 않습니다. 따라서 너무 큰 이슈로 인해 In Progress 상태에 오래 머물러 있는 경우가 간혹 있었습니다.

이는 이슈 생성 단계에서 최대한 상세히 작성하되 불가능하다면 진행하는 도중 subtask를 만들어서 쪼갠뒤 진행하는게 좋을 것 같다는 의견이 있었고, 리서치 이슈와 같이 범위가 정해져 있지 않는 경우는 마감일을 정해놓고 해당 기간동안까지만 진행 한 뒤 필요하다면 추가로 이슈를 생성하기로 했습니다.

GraphQL?

GraphQL을 다뤄본적은 없었고 이번에 새로 적용하게 되었습니다. 일반적인 상황과 약간 다르고 특이한 배경을 가지고 있는데 아직 완료되지 않았고 배포가 된 것은 아니라 공유하는 것은 무리가 있을 것 같고 기회가 된다면 글을 작성하고자 합니다.

이 과정에서 팀원 한 분과 거의 Scrum 방식으로 한달간 달려보았는데, 이 경험에 대해서도 프로젝트가 완료된다면 공유하고 싶습니다. 팀원 분이 동의 하신다면 말이죠

계속 이어지는 고민들

  • 나는 좋은 동료일까? 어떻게 좋은 동료가 될 수 있지?
  • 나는 스스로에게 Front-End 개발자라고 부끄럽지 않게 말할 수 있을까?
  • 어떤 엔지니어가 좋은 엔지니어일까?
  • 공부해야 하고 싶은 것도 많고 할 것도 너무 많은데 삶의 균형을 어떻게 잡는 것이 좋을까? 요새 특히 Platform과 Infra에 관심이..

사실 7개월 동안 더 많은 일이 있었고(개인적인 큰 변화들도 많았고) 느낀 점도 많긴 한데, 이미 길지만 너무 길어질 것 같아 이만 줄이고자 합니다. 계속 이어지는 고민들에 대해 생각해보고 다양한 분들과 이런 저런 의견들을 나눌 수 있으면 좋을 것 같군요.