Thinking

2020년 상반기 회고

코딩하는 Jay 2020. 7. 5. 22:51
반응형

개발자로 일한지 꽤 오래된 것 같은데, 크게 성장하지 못한 내 모습을 생각하며 후회를 할 때가 종종있다. 지금의 내 모습에 만족한다면 다행이지만, 만족은 못하고 후회만 반복하고 있다. 이렇게 지내다가는 후회만하다 개발자로서의 인생을 마무리 할 것 같은 두려움도 생긴다. 이왕이면 개발자로서의 마지막 모습이 최고의 실력을 가진 개발자는 아니더라도 주위에서 괜찮은 개발자였다는 평을 듣고 마무리하고 싶다. 그렇게 되기 위해서는 좀 더 노력해봐야하는 게 아닐까 생각한다. 올해는 조금 덜 후회하는 한 해를 보내기 위해, 그 중간의 시기에서 회고해보고자 한다. 첫 회고다보니 정리가 잘 될까 걱정이 들지만, 그래도 시작이 중요하니까 한 번 써내려가본다.

 

1. 회사

1-1. Scrum Master

2017년 초에 Scrum Master라는 조금은 어색한 역할을 받았다. 그 역할이 복잡하지는 않고, 매일 아침마다 하는 Scrum 모임을 진행하는 역할이다. 처음에 이 역할을 시작했을 땐, 큰 고민도 하지 않았고 그냥 아침마다 회의를 소집하는 일만 했다. 그리고 매일 매일 하는 것은 좀 귀찮기도 하니 월/수/금 이렇게 주 3회만 소집했다. Scrum Master인 나도 큰 의미를 갖지 않았고 팀 내에서도 굳이 이런것 해야하나? 그냥 위에서 하라고 해서 했던 것 같다. 그래서 그런지 대략 6개월 정도 유지되다가 자연스럽게 안하게 되었다.

그러다 작년 12월쯤 다시 팀내에서 Scrum 회의를 해야할 것 같다는 얘기가 나오게 되었고, 자연스럽게 Scrum Master 역할이었던 내게로 화살이 날라왔다. 그런데, 이번엔 조금 느낌을 달리했다. 이왕 맡은 김에 제대로 해보자 생각하고 Scrum Master의 역활에 대해 공부도 했다. 생각보단 가벼운 역할은 아니었다. 그래도 Scrum Master에 대해 공부하며 팀 내 일정에 문제가 생기지 않도록 팀원들을 돕고 있다.

 

1-2. Kanban (Trello)

기본에 Scrum 회의는 그냥 말로만 어제 한 일/오늘 할 일/에로사항(있다면) 이렇게 말하는 방법을 사용했다. 그런데, 말로 진행한 회의는 쉽게 잊혀지고 필요한 순간에 한 눈에 팀원들이 어떤 일을 하는 지 파악하는데 어려움을 가지고 있다. 그래서 Trello를 도입했다. 기존에 Trello를 사용하긴 했지만, Milestone마다 필요할 때만 사용했었고, 현재 팀내 모든 진행상황과 이슈를 공유하는 용도로 사용한 건 처음이다. Scrum Master로서의 역할을 다시 시작하며 효율적으로 프로젝트 진행 상황을 공유하고 싶어 팀장님과 상의후에 Trello를 제대로 사용하기로 결정했다. 결과는 대 성공. 지금은 각자의 일들이 어떠한 상황에 있는지 공유되고 있을 뿐 아니라 휴가나 회식 그리고 지식공유등에도 활용되고 있다.

 

1-3. Waterfall X Sprint

Scrum Master, Kanban등의 용어를 보면 애자일한 프로세스로 업무를 하는 회사라고 생각할 수도 있겠지만, 사실 우리 회사는 전통적인 Waterfall 방식으로 개발을 진행한다. Waterfall 개발이 무조건 나쁘다라는 건 아니지만 분명 단점도 존재한다. 이러한 단점을 극복하기 위해 우리 팀에서는 Waterfall과 Sprint를 결합한 개발을 시도 했다. 먼저 지난 Milestone에서 첫 도입을 해봤고 처음이라 그런지 한 60점 정도의 모습이었던 것 같다. (그래도 온전한 Waterfall 방식보다는 낫다!)지금은 이전에 부족했던 부분을 보완하여 두 번째 도전을 진행하고 있다. 자세한 내용은 지난 글을 참고.

2020/04/28 - [Thinking] - Waterfall X Sprint 회고

 

Waterfall X Sprint 회고

제가 근무하는 회사는 전통적인 Waterfall 방식의 개발을 하고 있습니다. 요구사항 - 설계 - 구현 - 테스트 PM(Project Manager)이 요구사항을 정의하고 개발자는 요구사항을 바탕으로 설계와 구현을 합��

jayprogram.tistory.com

 

1-4. 코드리뷰

우리 회사는 기존에도 코드리뷰를 진행하고 있었다. 그런데, 코드리뷰에 대한 규칙이 없다보니, 코드리뷰로 인한 작업 병목, 한 번에 너무 큰 수정의 리뷰 요청등 제대로 리뷰할 수 없는 경우도 있었다. 이러한 비효율적인 코드리뷰를 막기 위해 다른 회사들은 어떠한 방법으로 코드리뷰를 하는지 확인해보고 이를 바탕으로 몇 가지 코드리뷰 규칙을 제안했고, 이를 바탕으로 우리 팀 내에서는 코드리뷰를 진행하고 있다.

2020/04/29 - [Thinking] - 코드리뷰에 관한 정리

 

코드리뷰에 관한 정리

코드리뷰란? 한 명 또는 여러 명의 개발자가 본인이 만들지 않은 코드의 내용을 점검하고, 피드백을 주는 과정. 단순히 문제를 파악하는데 그치지 않고 코드에 대한 책임이 그 코드를 만든 사람

jayprogram.tistory.com

 

2. 블로그

What did you learn today?

내 카카오톡 프로필에 써놓은 글이다. 매일 매일 배우자는 마음을 담아 써놓았다. 그리고 내가 배운 것을 글로 남겨놓자는 마음으로 블로그도 시작했다. 그런데, 돌아보면 그렇게 많은 글을 쓰지는 못한 것 같다.

  • 1월: 0개
  • 2월: 1개
  • 3월: 0개
  • 4월: 18개
  • 5월: 4개
  • 6월: 2개

뭔가 4월에 반짝!? 했던 것 같다. 매일 매일 올리는 건 무리더라도 한 주에 2개 정도의 포스팅을 목표로 하면 좋을 것 같다는 생각이 든다.

 

3. 개인 프로젝트

연 초에 여러가지 프로젝트를 동시에 시작했다. 개인 프로젝트 1개, 팀 프로젝트 2개. 어떻게 보면 너무 많은 프로젝트를 동시에 시작한게 아닐까 생각한다. 지금은 프로젝트들이 제대로 돌아가지 않는 상황이라고 봐도 무방하다ㅜㅜ... 너무 큰 욕심을 부린게 아닐까 생각도 들지만 이왕 시작한거 끝을 봐야한다고 생각한다. 다시 맘을 다 잡고 테스크 정리부터 해봐야겠다.

 

4. 일일커밋

위 프로젝트 항목과 겹치는 부분이 있다. 다양한 프로젝트를 하면서 모든 코드를 Github에서 관리하도록 했다. 그리고 매일 매일 커밋하는 것을 목표로 시작했다. 4월쯤 시작했는데, 처음엔 정말 잘 된 것 같다. 그러다 개인적으로 더 중요한 일들을 생기면서 한 두 번 놓쳤더니 그 이후로는 제대로 하지 못한 것 같다.

 

5. 총평

지속적인 것. 내게 가장 필요한 부분이다.

사실 연초에 내가 성장하는 것보다 더 중요한 것을 경험했다. 바로 아내와 나의 사랑의 결실이 생긴 것 ❤️아이가 생겼다는 것으로 인해 부부가 함께 준비해야 할 것들도 생각보다 더 많았다. 그 부분에 더 많은 시간을 사용했다. 그리고 지금은 어느정도 정리가 된 것 같다.

어느정도 정리가 되었으니 다시 열심히 해야겠다. 사랑하는 아이를 기다리며, 부끄럽지 않은 아빠가 되기 위해 후반기에는 좀 더 성장한 나를 기대해본다.

반응형