6개월간의 인턴십이 끝을 고했습니다.
첫 회사였고, 그만큼 제가 잘 할 수 있을지 걱정부터 앞섰던 기억이 있는데요.
많은 것을 겪었고, 그 이상의 값진 것들을 배운 멋진 시간이었습니다.
좋았던 점, 겪었던 문제, 개선점을 회고하겠습니다.
Keep - 좋았던 점
1. 일지 작성
매일 일지를 썼던 것입니다.
일종의 TIL이었는데, 인턴십 중반부터 동기의 권유로 같이 쓰게되었어요. 하루의 업무를 마무리할 때 오늘은 어떤 문제가 있었는지, 문제를 어떻게 해결했는지, 느낀 점들을 적었습니다. 일지는 모두에게 공개되는 사내 위키에 작성했는데, 사측에서도 인턴들이 스스로 일지를 작성하는 걸 굉장히 좋게 봤어요. 심지어 저희의 일지를 보시고 본인도 일지를 쓰기 시작하신 직원분도 계셨습니다.
이렇게 작성한 일지는 추후 본인 평가서를 작성할 때 내 과거 작업을 트레킹할 때 사용하기도 했고, 일지에서 등장했던 이슈와 비슷한 과제를 해결할 때도 사용되곤 했습니다. 작성하는 것 자체로 기억에 한번 더 각인되기도 했어요.
2. 작업 시작 전의 히스토리 파악
작업을 시작하기 전 히스토리를 찾아보는 습관을 들인 것입니다.
저희 회사는 FE 커뮤니티가 잘 발달되있는 편이라 FE 관련 자료가 사내 위키에 잘 정리되어 있다는 장점이 있었습니다. 또 FE 코드베이스가 오픈되어 있기 때문에, 유사한 문제에 대해 각 팀에서 어떻게 접근해서 해결해냈는지 조사하기도 편했어요.
무작정 구현에 들어가는 것과, 시간을 내어 히스토리를 충분히 파악하고 구현에 들어가는 것은 큰 차이가 있었습니다. 이 부분은 작업 전 설계 과정에 포함될 수도 있을 것 같은데, 설계와 구상이 실제 작업보다 더 중요하게 작용할 수 있다는 것을 의미하기도 하는 것 같아요!
3. 태도
추진력 있는, 적극적인 자세를 유지한 것입니다.
이 부분은 태도에 대한 이야기인데, 저는 빠른 템포로 업무를 해나가는걸 선호합니다. 한 지점에 오래 머물다 보면 축 가라앉고 무기력한 느낌이 드는 것이 싫더라구요. 항상 동적인 자세를 유지하고, 가능하다면 저에게 주어진 것보다 더 많은 걸 성취하고자 했습니다. 이런 태도에 대한 긍정적인 피드백이 많았습니다.
Problem - 겪은 문제들
1. 일정 산정
가장 아쉬웠던 점은, 일정 산정에 대한 점입니다.
작업을 할당받고, 이 작업에 소요될 일정을 산정합니다. 이 과정에서 작업을 0.5~1 업무일 정도의 작은 단위로 나누어 전체 작업에 필요한 리소스를 산정하게 되는데요, 이것을 정확하게 해내지 못했습니다. 제 생각에 이건 상당한 패착입니다. 이렇게 되면 실제 개발에 필요한 일정보다 부족하게 되고, 그러다보니 서두르게 됩니다. 서두르면 실수가 많아지고 코드 퀄리티가 떨어집니다. 결국 악순환의 수렁에 빠져 역량을 발휘하지 못하는 경우가 종종 있었습니다.
2. 사내 생산성 기여
사내 생산성에 기여하지 못한 점입니다.
사내 위키에 문서를 작성하거나, 공통 라이브러리에 기술 개선점을 기여하는 등의 활동을 하지 못했어요. 항상 해야지 해야지 하다가 계속 들어오는 업무에 우선순위가 밀리는 경우가 많았습니다. 조직 생산성에 기여하는 건 작업 하나를 해결하는 것 보다 훨씬 큰 임팩트를 준다고 생각하는터라 아쉬움이 컸습니다.
3. 적극적인 질문
더 적극적으로 질문하지 못한 점입니다. 제가 끙끙 앓던 문제들이, 동료에게 질문했다면 단순하게 해결할 수 있었던 경우들이 많았어요. 물론 시도때도 없이 찾아가 물어보는 것도 문제지만, 적당한 고민을 했다면 문제를 공유하고 의견을 구하는 게 전체에게 더 나은 결과를 가져오는 케이스가 많았던 것으로 생각합니다. “이 질문을 하면 바보같아 보이지 않을까?” 하는 생각에 주춤거렸던 때도 많은데, 그냥 물어보는게 낫습니다. 모르는 채로 있는게 바보같은 거였어요.
Try - 개선점들
작업을 정확히 산정하고 버퍼를 고려하여 최종 리소스를 결정해야 합니다.
저는 러프하게 작업을 나누거나, 혹은 그것조차 생략해 눈대중으로 작업의 규모를 판단하고 뛰어드는 경우가 많았습니다. 또는 타인이 산정해준 의견에 의존해서 스스로 판단하지 않은 경우도 있었구요.
일정 산정에 충분한 시간을 들어야 한다는 것을 배웠습니다. 어쩌면 실제 개발보다 더 중요한 게 리소스 산정과 사전 설계가 될 수 있겠구요. 실제로 경험이 많은 개발자일수록 문제를 파악하는데에 더 많은 시간을 쓴다고 하네요!
사내 생산성 증진에 도움이 되는 일들은 즉시 합니다. 당장 배포가 나가야 할정도로 급한 일이 아니라면 그 날의 개선 과제들을 해결하는게 맞을 것 같아요.
마지막으로, 자기 계발에 있어서 완벽한 환경이 만들어지기를 기다리지 않습니다.
업무가 많을수도, 몸이 좋지 않을수도, 개인적인 일로 힘들수도 있습니다. 그래도 내 바운더리 안에서 최선의 환경을 만들고, 그 환경에서 할 수 있는 걸 해야한다고 느꼈어요. 실천하기 쉽지만은 않은 부분이지만 의식적으로 노력해보려 합니다.
이제.. 전환 결과를 기다려야겠네요. 행운을 빌어주세욧!
