대형배포 끝 (?), 그렇게 9개월차가 되다 - part 1.

🌟 신입 개발자 적응기 / 4, 5, 6, 7 월 

지난 4월부터 생각했던 것보다 무척이나 바쁜 시기를 보냈다. 

우리 팀은 서비스 개발 조직이다보니 아무래도 산출된 일정에 맞춰 기능을 개발하기 위해 일일 근무량을 초과하는 경우가 많다. 

그런데 3월부터 투입되었던 프로젝트는 기능 한 두가지를 추가하거나 개선하는 것이 아니라

전체 서비스 리뉴얼 + 이를 위한 대규모 마이그레이션 + 몇 가지 기능 추가/개선이 목적이다보니 

팀원 모두가 기존보다 더 강도 높은 업무량을 소화하며 달려왔다. (5, 6월은 다들 주말, 공휴일에도 쉬지 못하고 일했으니..) 

불행인지 다행인지 글을 올리는 오늘은, 드디어 그간의 작업들을 배포하는 날이다.

덕분에 나도 이제서야 그동안 배우고 느꼈던 점들을 여유롭게 정리할 수 있는데...

과연 배포가 무사히 마무리 되어서 다음 글을 기쁘고 가벼운 마음으로 작성할 수 있을지? 그건 다음 글에 다시 다뤄보도록 하겠다.

일단 이번 글에서는 이번 스프린트 동안에 굵직하게 느꼈던 점들부터 톺아보고자 한다. 

 

요즘 나의 심정이었달까

 

 

💫 일정 산정의 중요성

 

흔히 초보는 나무를 보고 고수는 숲을 본다고 하는데, 고수 개발자는 숲의 무엇을 볼까?

아마 숲의 생태계 (개발 아키텍처), 위치 (서비스의 비즈니스적 기여도), 크기 (서비스의 규모) 등일 것이다. 

그 중 숲의 크기를 볼 때, '이 정도 숲은 대략 이 정도 비용을 들여 짓겠군' 을 잘 산정할 수 있는 사람이 곧 고수 중의 고수가 아닐까..

하는 생각을 새삼스래 해보게 된다. 

찔찔이 초보에 불과한 내가 이런 고민을 하게 된 이유는, 이번 프로젝트를 통해 일정 산정의 중요성을 뼈저리게 느꼈기 때문이다. 

 

사실 프로젝트 초반에만 해도 지라 티켓의 'story point estimate' (예상 작업 시간) 항목을 대단히 여기지 않았다. 

다들 형식적으로 찍는 것인 줄 알았고, 때문에 나도 실 소요 시간이 내가 찍었던 예상 시간과 조금 어긋나도 크게 개의치 않았다. 

그런데 중반부로 접어들 때부터 그 항목이 다른 것보다 더 눈에 들어오기 시작했고, 가장 신중히 기입하는 란이 되었다. 

 

그 이유는, 한 사람의 작업 소요 시간은

1) 다른 연관 작업들의 우선순위에 영향을 미치며, 

2) QA 가능 항목에 영향을 미치며,

3) 전체 팀의 진척도를 판단하는 주요 지표가 되기 때문이다. 

 

결국 개개인이 산정하는 작업 소요 시간의 총집합이 곧 팀의 총 작업 시간이 되는 것이었고,

이를 토대로 작업 시기 협상이 이루어지곤 하는 것이었다. 

단순히 책임감과 목표의식을 고양하기 위한 도구인 줄만 알았는데, 사실은 일정 산정을 위한 도구로써 서비스의 품질과 완성도에 기여하는 가장 작은 단위의 작업이었던 것이다. 

 

사실 이번 배포 일정도 우여곡절이 정말 많았는데, 그 중 하나가 '일정' 에 대한 이슈였다.

최초로 잡았던 배포 일정에 비해 작업 범위가 너무 컸고, 여러 팀에 얽힌 수정사항이다 보니 예상했던 일정보다 개발 속도가 더뎠다.

처음에는 '그래도 설마' 하는 마음이 컸지만, 배포 예정일이 다가올수록 '어..? 이거 안 되겠는데..?' 하는 불안과 두려움이 엄습해 왔다.

다행히 여러 팀간의 조율을 통해 배포 시기를 조정해 작업과 검증을 모두 끝마친 채 배포가 나가게 되었지만,

과거의 내가 일정을 더 철저히 여기지 못하고 안일하지는 않았는지 후회하고 자책하는 계기가 되었다. 

덕분에 개발 일정의 중요성과, 개개인이 산정하는 예상 소요 시간의 중요성에 대해서도 실감했다. 

 

이번 스프린트를 회고한다면 여러 가지 점들을 꼽아 볼 수 있겠지만, 그 중 하나는 단연 '소요 시간을 예상하는 능력' 일 것이다. 

처음 시작할 때는 아무 생각 없이 주어진 일정을 받아들였던 나지만,

이번 경험을 자양분 삼아 앞으로는 주어진 일정을 세분화 하여 기획 리뷰, 명세 작성, 개발, 코드 리뷰, 버그 픽스, QA 등등의 과정들을 전부 포함할 수 있을지 꼼꼼히 살펴볼 수 있을 것임을 믿는다. 적어도 나에게 주어진 업무에 한해서는, 그렇게 해야만 한다! 

 

 

 

💫 좋은 선배와 좋은 후배

 

좋은 선배를 만날 수 있다는 것은 어쩌면 천운이 따라야 하는 일일지도 모르겠다. 

그런데 나는 팀에 따를 수 있는 좋은 선배들이 정말 많아, 운이 무지막지하게도 좋은 사람이라고 생각한다.

 

이번 프로젝트를 시작할 때는 이제 막 수습을 뗀 찐신입 개발자였다. 

여러모로 역량이 부족한 상태에서 큰 단위의 기능을 개발하게 된 상황이었던지라, 실수도 많았고 때론 스스로의 부족함에 좌절하기도 했다.

 

이쯤에서 잠시, 되짚어보는 나의 실수들

- git force push 해서 메인 브랜치 커밋 꼬아버리기

- API 수정사항 테스트 누락하고 PR 올리기 

- 무수한 typo 들

- confluence 에 반영한 내용 swagger 에 누락하기 (& vice versa)

- 레거시 코드 로직 정리 잘못해서 클라이언트에게 잘못된 로직 전달하기 

- 공식문서 내용을 제대로 못 보고 신규 라이브러리로 작업해서 수정했던 내용 또 수정하기

 

... 너무 많으니 그만 되짚어보자 .. 

 

적어놓고 보니 기본적인 사항을 지키지 않아 문제가 되었던 적도 있고, 분명 꼼꼼히 확인했다고 생각했는데도 무언가를 누락했던 적도 있다. 

나의 의도가 어쨌든 이번 스프린트 초반의 나는 실수도 정말 많았고, 작업이 미숙한 개발자였음에는 분명하다. 

하지만 중요한 것은, 내가 벽에 부딪힐 때마다 동료들과 팀장님의 도움을 받아 다시 일어날 수 있었다는 점이다.

작업이 느리거나 형편없어도, 혼자 쩔쩔매는 모습에도 나무라기보다는 더 성장할 수 있는 방향을 제시해주고, 

개선이 될 때까지 믿고 기다려주는 분들 덕분에 한 두 번의 실수가 되풀이 되지 않을 수 있었다.

분명 나를 기다리기보다는 동료들과 팀장님이 직접 작업을 가져가서 하는 것이 빨랐을 법함에도, 차분히 인내하며 견뎌주셨다..

(정말 감사합니다..)

그 덕에 나도 앞으로 다른 누군가에게 어떤 모습의 선배가 되어야 하는지, 협업할 때 어떤 자세를 갖춰야 하는지 배우고 체화했다. 

 

아 물론, 혼자 온갖 문서와 슬랙 히스토리, 커밋 기록을 뒤져가며 도메인을 이해하려고 했던 노력과

동료들의 코드를 더 잘 이해하기 위해 책과 강의를 찾아봤던 노력 덕분에 

낯설었던 업무 프로세스도, 이해되지 않던 도메인 용어들도 조금은 자연스러워졌지 싶다! 

그런 내 자신의 수고에도 박수쳐 주고 싶은 바이다. 

 

지난 몇 개월 정신적으로, 육체적으로 힘들기도 했지만 그 덕에 고농축 지식을 빠르게 흡수한 것 같기도 하다.

아직 부족한 점이 많지만 나의 부족함에 잠식되기보다, 꾸준한 노력을 통해 보완해 나가는 역량을 기르는 계기가 되었다. 

 

그리고 이번에 또 한 차례의 성장을 꾀하며 도약할 수 있는 기회가 찾아왔다.

우리팀 백엔드 파트에 인턴 분이 들어왔고, 처음으로 사수 위치에서 누군가를 이끌게 되었다.

부디 그 분이 나에게서 최대한 많은 것을 얻어가실 수 있도록 나도 앞으로 지금보다 더 분발하고 공부해야겠다는 다짐이 드는데, 

서로 상호작용하며 협업해 가는 과정 속에서 나도 한 차례 더 대폭 성장하고 싶다는 기대감이 있다. 

 

좋은 선배들을 곁에 둘 수 있음에 대한 감사함이 다시금 나 스스로를 좋은 선배로 만들어주길 바라며,

심기일전하여 다시 정진해 나가자..! 

 

 

 

======

to be continued... (part 2)