wanna be a software craftman step by step

성장을 해야한다. 시간이 지날수록, 경력 기간이 늘어날수록, 실력도 증가해야 한다. 단순히 시간이 지난다고 해서 실력도 발전하진 않는다. 여태까지 그랬다. 시간을 어마어마하게 쏟아부으면, 당연히 없던 실력에선 어느정도 발전이 있을수밖에 없지만. 어느새부턴가 단순반복이 되어버리면, 배움도 없고 발전하지 못한다.   회고의 중요성 실력이 증가하려면 시간과 경험이 일단 쌓여야하지만, 무언가 일단락 되었을때 되돌아봐야만 한다. 늘 언제나 there is a room for an improvement 이다. 언제나 항상. 그리고 여태까지 나는 이  과정이 없었기 때문에 더 발전하고 고칠 수 있었음에도 불구하고 잘못을 답습해왔다. 실수도 반복되면 실력이라고. 내가 더 발전하지 못한 가장 큰 이유중 하나는 회고하고, 되돌아보고, 복기하지 않는다는 것이다. 의미있는 회고가 되려면 제일 중요한건 시작하기 전에 계획이 있어야 한다. 계획이 없이 열심히만 했으면. 회고할때 뭘 잘했고 뭘 잘못했으며 다음번에 다시하게 되면 어떻게 더 잘 할수 있을지를 파악하지 못한다. 그저 그 순간순간 밤새 열심히 했다, 밖에 남지 않아버리면. 다음에도 똑같이 반복할 수밖에 없다. 계획을 잘 짜려면 프로젝트 특성상 deadline 단위로 끊을수밖에 없다. 계획이라는게 결국은 일정관리아닌가. 언제까지 뭘 하겠다가 큰 그림이고. 그럼 backward 로 잘라가면서 milestone 별로 break down 해야한다. 그렇게 언제까지 뭐가 되고, 언제까지 뭐가 되고가 나온다. 그럼 나중에 프로젝트다 끝나고 나면 일정 을 짤때 놓친 부분이 나오고, 다음번 프로젝트에 이를 고려한 일정을 계획할 수 있다. 개발이 다가 아니다 아직까지 고치지 못하는 버릇. 내 부분만 하면 끝난다는 생각. 나머지는 신경도 안쓰고 무책임해버린다. 서버개발은 되었어도 프론트가 안되었으면 테스트를 할수 없다. 개발 자체가 물론 중요하고 개발이 안되면 프로젝트가 망하지만. 일정과 전체적인 진행상황, 일을 제때 제대로 되...

독일에 와서 정말 제대로 느낀게 하나 있다. 금요일 이후에, 스케쥴 표에 우리팀만 이름이 빠져있어서, 채워넣야하지 않냐고 물어봤는데 아무도 답이 없었다. 그러다 다음 월요일에, 다른 사람이 이야기를 다시 꺼내서, 채워넣야 하니 미팅을 하자고 했더니 다들 참여했다.  미팅에서 screenshare 할사람이 없어서 조금 기다리는 공백이 있었는데. 이때라도 나섰어야 했는데 머뭇거렸다. 아무일도 아니었음에도 말이다. 그러곤 빈 slot 에 각자 이름을 넣을 사람을 찾는데 저마다 자기 이름을 넣어달라고 했다. 나는 기회를 기다렸다가 말하려고 했는데. 내가 말할 틈을 주지 않았다. 진짜 모여서, 자기가 되는 시간은 주저없이 자기 이름을 넣어도 된다고 바로바로 말했다. 그렇게 약 5분만에 미팅이 끝났다. 공정한 분배나 이런건 말하지도 않았다.  아무도 기다려주지 않는다. 모두가 서로 돕고 돕는다. 그런데 도와달라고 말을 해야한다. 그러면 언제든 도와준다. 하지만 말을 해야한다. 적극적으로 의사표현을 해야한다. 내가 하겠다고 해야한다. 도움이 필요하다고 해야한다. 뭔지 잘 모르겠다고, 내가 할 수 있다고, 말을 해야한다.  쭈볏쭈볏 머뭇머뭇 하면 기회가 날라가는 것이다. 

처음으로 동료들로부터 feedback 을 받았다. 내가 지정한 동료들로부터 받으나, 나에게 돌아오는 결과는 익명이다.  예상했던 대로 self-initiative 는 낮았다. 그러나,quality of work, 나 efficiency  에서도 좋은 점수를 받지 못했다. 평균이란 소리는, 더 잘해야 한다는 소리다. 의외로 team effect 나 knowledge, work commitment 는 좋은 점수를 받았다. 열심히 하고 잘 아는데, 효율적이지 못하고, 스스로 나서지 않으며, 신경써서 일하지 않는다는 결과. 문제를 해결할 때 문제 해결뿐만 아니라, 그 주변의 코드들로 추가적으로 보는 습관들 들여야 한다. 문제를 해결할 때 이 해결된 방안이 다른 부분에 영향을 끼치지는 않는지도 생각해야 한다.  적극적 참여와 의견 개진은, 계속해서 들어오고 있는 피드백이다. 빠르고 바로바로 커뮤니케이션 하라는 주문도 들었다. 말도 못하고 영어는 더 못하는 나를 동료들도 답답해 한것이다.  미안함과 동시에, 답답하기도 했고. 발전의 여지를 인지했고, 발전했음을 나중에 볼 수 있다면 좋겠지만. 참 힘들것이라는것을 알기에. 마음이 좋지만은 않다.

우리 개발팀에는 DoR, DoD,DoP 라는 것이 있다. 이전에는 겪어본적이 없는것들이다. 나중에 따로 정리를 하겠지만, 우선은 코드리뷰에 대해 정리를 해보려고 한다.  이전 회사에서도 코드리뷰가 있었다. 처음부터 있었던건 아니고, 나중에 생겼다. 하지만 반드시 reviewer 가 accept 해야 commit 이 되는것도 일부 모듈에 대해서만 적용되었기 때문에 모든 code commit  에 대해 approval  이 필요하지 않았다. 때로는 빨리 검증 받고 배포해야 하는데 review 안되서 이게 걸림돌이라는 느낌이 강했고, 어떤 경우엔 담당자가 나 혼자여서 review 를 해줄 사람이 없었다. 모듈별로 주담당-백업이 나뉘어 있었는데, 백업 모듈에 대해 review 를 하기엔 잘 알지 못하고, 주담당인 모듈에 대해선 누군가 review  를 해줘야하는데 오래 걸리니 걸림돌이 되고. 백업이 없는 경우는 review 가 없는 상황. code reivew  에 대한 인식이 없다가 생긴것은 좋았으나, 그것이 개발에서 꼭 필요한 일부분이라기 보단 형식적인 통과의례로서 병목처럼 여겨졌다. 여기서는 아니다. review 를 받지 못하면 merge 되지 않는다. 우리 팀은 이제 7명. 옆 팀은 더 많다. 한 9명 되나? frontenf, backend 가 한 팀에 있고,  내 모듈, 네 모듈의 개념이 아닌, 우리 팀의 모듈이다. 그래서 특별히 어려운 티켓을 제외하면 누구나 develop, review, test 를 할 수 있게 되어있다.  reviewer  를 찾는 문화도 있다. daily  에서, 혹은 팀 채널에서 티켓 개발이 끝났으니 reviewer  를 찾고 있다, 라든지, 지금 할거 없는데  도움 필요한 사람? 이런식으로 나서기도 한다.  review 도 대충하지 않는다. 철저하다. 여러번 퇴짜를 맞았다. 나도 마찬가지로 적극적으로 의견을 내려고 한다. 아무리...