2020년 Q3 회고

October 18, 2020 · 8 mins to read

Q3에는 정말 바쁘게 움직였던 것 같다. 팀의 프로세스가 안정세에 접어들고 bottom-up으로 진행하는 일들이 본격적으로 늘어나면서 Q2보다 코드에 쏟는 시간이 많아졌고, 새로운 프로세스를 경험하기도 하였다. 다행히도 새로운 프로젝트를 런칭했으며, 프로젝트를 진행하는 과정에서 내 생각과 태도가 많이 바뀌기도 하였다.

아쉽게도 Q3의 OKR은 없다. Q1에서 OKR로 목표관리를 해보았는데, 사실 OKR을 잘 공부하지 않은 탓도 있고 제일 중요한 피드백을 주는 사람이 없었기 때문에 Q2 OKR을 세우는 것이 무의미하다고 느꼈다 혼자 세우고 혼자 만족하기. 분명히 Q1 회고에는 괜찮았다고 되어있었는데 Q2 OKR을 만들며 무언가 뻔하고, 효율이 없음을 느꼈다. 대신 Q3의 회고는 아직 진행 중인 개인 프로젝트 (opens new window)를 통해 (근사값이지만) 그래프와 수치로 진행할 수 있게 되었다.

1. FE 팀, 본격적으로 시동을 걸다

  • 나는 얼마나 코드를 썼을까?
- 화끈했던 스프린트의 결과

살펴보니 개인 프로젝트와 회사 일을 모두 합쳐서 3달간 291 commit을 하였다. 아마 이번에 팀에 처음으로 도입한 스프린트와 스크럼의 영향이 아닌가 싶다. Additions, deletions는 package-lock.json이 섞인 결과라 노이즈가 있을 거라 생각한다.

가장 많이 기여한 프로젝트는 회사의 서비스중 하나인 odc-frontend (opens new window)이다. 그다음은 이번에 런칭한 graphql server이고, 마찬가지로 이번에 릴리즈한 odk-front-server (opens new window)가 그 뒤를 이었다.

- 격렬했던 7월, 퍼졌던 8월, 일을 마무리한 9월

PR이 머지된 시점을 기준으로 commit 수를 합산하였기 때문에 commit 수와 날짜는 정확히 일치하지 않는다. 다만 저 즈음에 저 정도의 일이 있었구나 정도로 생각해 볼 수 있는 것 같다 빨리 query를 수정해서 정확하게 만들어야지. 확실히 7월에 graphql server의 작업이 집중되어있다. 아마 저 즈음에 스프린트 + 스크럼으로 일하기 시작했을 것이다.

8월 중순 ~ 말은 payment PoC와 odk front server에 대해 작업을 했었다. 8월 24일부터 8월 30일까지 그래프가 비어있는 이유는 번아웃이 와서 제대로 일을 못 했기 때문이다.

9월에는 odc web에 graphql을 적용하는 작업을 진행하였기 때문에 주로 그 프로젝트에 기여하게 된 거 같다. 그 와중에 블로그와 timing report 같은 개인 프로젝트에 짬짬이 기여한 것이 보인다.

우리 팀에서 생산성이 낮은 축에 속하는 나도 이정도 양의 일을 했기 때문에, 다른 사람들의 통계를 뽑아본다면 더 많은 기여를 했을 것이라는 예상이 된다(특히 플레이어 팀이 기대된다). 스프린트와 스크럼의 도입이 FE 팀에 날개를 달아준 것이다.

1. 기여한 프로젝트

  • Odc graphql + Odc web

    처음 런칭해본 백엔드 프로젝트였다. 그만큼 신경이 많이 쓰이기도 했고, Q3의 대부분을 할애했다고 볼 수 있다. Graphql query를 기존의 서비스에 적용하는 PoC를 해보면서 api server - graphql - frontend app과 k8s 등 회사 서비스에서 사용되는 전반적인 기술 스택을 두루두루 들여다볼 수 있어 좋았던 기억이 난다.

    특히 우리 팀에서 사용하는 데이터를 스키마의 형태로 한번 정리하고, 정의했다는 것에서 큰 의미가 있다고 생각한다. 본격적으로 런칭하는 과정에서 실수와 혼란이 있었고, 역시나 운영되는 서비스를 크게 개선하는 것은 어려운 일임을 다시 한번 깨닫게 되었다.

    스키마 필드를 빼먹거나, 아예 엉뚱한 endpoint를 graphql server에서 요청하고 있던 부분, QA팀에서 테스트할 때 리포트한 문제인데 재현이 되지 않아 대수롭지 않게 넘어갔던 부분에서 모두 문제가 발생하였다. 당연히 많은 반성과 함께 팀장이신 그 분2에게 석고대죄를 하였다.

    인프라에서의 이슈였지만, internal ingress의 문제도 발생했기 때문에 첫 배포가 절대 쉽지 않았다. 하지만 막상 안정화를 해놓자 기술적, 인간적으로 좋은 영향을 주고 있어 기분이 좋다.

    참고로, 이번에 graphql을 도입했던 과정을 에 정리해두었다.

  • Payment PoC

    어쩌다 보니 백엔드 팀의 제권님, 우리 팀의 지훈님과 함께 payment PoC를 진행하게 되었다. 왜인지 모르겠지만 지훈님과 내가 이런 종류의 PoC를 전담하게 된 느낌이다. 아무튼 무사히 잘 끝나게 되었고, Q4에는 본격적으로 payment feature와 관련한 작업을 진행하게 될 것 같다.

  • Odk front server

    백엔드와 프런트엔드가 분리되어있지 않은 기존의 django page를 nextjs를 이용해 react로 대체한다는 그 분2의 원대한 계획을 실현하기 시작했다. docker와 nginx, nextjs와 기존의 django web이 뒤섞여있는 혼돈 속에서 작업을 진행했고 특히 nextjs를 처음 써 볼 수 있어 좋았던 기억이 있다. 특히 오래된 서비스를 신선한 방법으로 바꾸는 시도를 해보는 것이 재미있었다.

    덧붙여, 연초에 만들었던 e2e 프로젝트에 테스트 케이스가 추가되기 시작했다는 것도 좋았다. 만들어놓고 잘 쓰지 못해 항상 마음에 걸렸는데 이번에 제대로 사용하게 되어 연초의 노력이 헛되지 않았다는 느낌을 받았다.

    다만 아쉬운 점은, 맡은 부분을 진행하다가 마무리 짓지 못하고 번아웃으로 장렬히 전사하는 바람에 다른 팀원들이 마무리 짓게 되었다는 것이다. 이 부분은 굉장히 미안하게 생각하고 있고, 나중에 맥주라도 한잔 사면서 감사해야 할 것 같다.

    docker, nginx, nextjs, django가 어떻게 연결되는지 궁금하다면, 팀장님이 직접 쓰신 글이 여기 (opens new window)있으니 궁금하다면 일독을 권한다.

2. 칸반, 스크럼반, 스크럼

  • Graphql의 시작 - 칸반

병대님이 오셔서 업무 프로세스를 정리해주셨을 때, graphql project는 에픽 단위로 묶인 칸반으로 관리하고 있었다. 이때 혼자서 티켓의 일정을 추정하고 실제로 걸린 시간을 기록하는 등 예측에 대해 연습을 하고 있었는데, 같이 호흡을 맞추게 된 지훈님이 굉장한 관심을 보였다.

결국 지훈님도 티켓을 처리하는 시간을 측정하기 시작하였고, 티켓을 하나 처리할 때마다 서로 작업 시간을 측정하는 노하우를 주고받았다.

  • 병대님의 실험 - 스크럼반

이때 팀의 프로세스 확립을 위해 모든 프로젝트의 PM 역할을 하시던 병대님이 나와 지훈님의 변태 같은 모습을 보시고 스크럼반 형태의 프로젝트 관리를 제안하셨다. 기존 칸반과 크게 다른 것은 없었고 에픽 단위로 묶이는 하나의 phase에 계획한 작업을 플래닝하여 티켓으로 만들고 예측 시간을 기록하는 방법이었다.

이렇게 2주 정도 일을 하고 나자 어느 정도 graphql 티켓에 대한 시간 측정의 오차가 줄어들었고 병대님은 스크럼 형태의 프로젝트 관리를 제안하셨다. 물론 채찍에 목말라 있던 지훈님과 나는 바로 수락해버렸다.

  • 그렇게 우리는 달려간다 - 스크럼

8월 한 달 정도는 스크럼 형태로 프로젝트를 관리하며 스프린트를 이어갔다. 우리는 마치 경주마처럼 일하게 되었는데, 보통 하나의 스프린트를 2 ~ 3주 단위로 잡지만 하나의 스프린트를 1주로 잡은 탓이었다. 결국, 4주간 4번의 스프린트를 통해 graphql server를 어느 정도 마무리 지을 수 있었다. 확실히 스크럼 + 스프린트로 일하는 것은 경쾌한 느낌이 들어 정말 재미있었고, 그 덕분에 위에서 말한 번아웃이 왔다.

아마 다른 회사를 가더라도 한 번쯤은 이 프로세스를 시도해 볼 것 같은데, 경험이 상당히 좋았기 때문이다. 좋은 경험을 할 수 있게 도와주신 병대님께 감사를 드린다.

칸반, 스크럼반, 스크럼을 차례대로 도입하며 팀의 퍼포먼스가 어떻게 개선되었는지는 지훈님이 쓰신 글이 여기 (opens new window)있으니 한번 읽어보는 것을 추천한다.

3. 또다시 번아웃

  • Runner’s high

스크럼 + 스프린트의 형태로 일하다 보면 정말 미친듯이 일하게 된다. 지훈님의 글에 쓰여있듯 번다운, 번업 차트의 압박은 실로 대단해서 누군가 말하지 않아도 일할 수 밖에 없었다.

- 누가 일을 하는지 안하는지는 말을 하지 않아도 알 수 있다. (출처: 스크럼에 대한 경험 및 개인적인 생각 (opens new window))

특히 같이 프로젝트를 진행하는 팀원이 일을 멈추지 않아 덩달아 신나게 일했고, 결국 티켓을 처리하면서 극한의 박진감과 희열감을 느끼는 runner’s high를 경험하게 되었다 써놓고 보니 이상하다.

  • 6번의 스프린트, 그리고 장렬한 전사

위에서도 썼듯, graphql server는 총 4번의 스프린트를 1주일 단위로 진행하였다. 월요일에 플래닝하여 금요일까지 스프린트를 마무리 짓고 데모 시연을 한 후에, 다음 월요일에 회고와 플래닝을 진행하여 다시 금요일까지 달리는 사이클을 총 4번 반복한 것이다.

Graphql server를 어느 정도 마무리한 후 지훈님과 다시 1주일짜리 payment PoC 스프린트를 1번 진행하였다. PoC branch가 배포되자 나는 곧바로 odk front server 스프린트에 투입되어 마지막을 버티지 못하고 장렬히 전사하였다. 이때가 8월 말이었는데, 팀원들에게 굉장히 미안했던 기억과 시원-한 아이스커피 마시고 쉬고 싶다는 생각밖에 들지 않아 스스로 놀랐던 기억이 난다.

이즈음 있었던 팀 워크샵에서 스크럼과 업무 몰입에 대한 이야기가 나왔고 다행히도 (다행인 건가?) 나만 이런 증상을 겪은 것이 아니었다. 그래서 우리 팀은 하나의 결론을 도출해 내었는데, bottom-up으로 빠르게 성과를 보여줘야 할 때는 스크럼 + 스프린트로 프로젝트를 운영하고, 그 뒤에는 칸반으로 전환하기로 하였다.

  • 마약과 같은 그것

되돌아보면 스크럼 + 스프린트를 하면서 마치 모르핀에 중독된 것 같았다는 생각이 든다. 스스로가 고통스러운지도 모르고 서서히 죽어간 느낌이 들어서 그렇다. 그렇기 때문에 앞으로는 적당한 시점에 안식주를 가질 생각이다. 지금 생각하는 것은 스프린트 2~3번 후 1주 휴식 정도다.

하지만 이번 스크럼 + 스프린트에 대해서는 후회하지 않는다. 팀이 성과를 보여줘야 하는 상황이었고, 다행히 그 결과물이 어느 정도 인정을 받았기 때문이다.

4. 그밖의 기억나는 일들

  • Strength finder

회사에서 검사 비용을 지원해 주었다. 처음에는 MBTI같아서 약간의 거부감이 있었는데 막상 해보니 재미는 있었다. 복구(문제해결), 책임, 회고, 분석, 공부 이렇게 다섯 가지의 강점이 나왔는데 솔직히 나하고 잘 맞는 것인지 잘 모르겠다. 기회가 되면 팀원들에게 물어봐야겠다.

  • AWS certificate 공부

제프리와 시작했는데 나중에 나 혼자 흐지부지 관두었다. 아무래도 목표가 뚜렷하지 않았기 때문에 동기부여가 잘 안 된 것 같다. 이런 면에서는 강한 의지를 갖고있는 제프리가 부럽다.

  • 우아한 테크 러닝

원래 정원이 아주 적은 과정이었는데 COVID-19 덕분에 온라인 강의로 전환되며 정원이 확 늘어났고, 운 좋게 들을 수 있게 되었다. 솔직히 기술에 대한 부분보다는 우아한형제들 CTO인 김민태 님의 태도와 생각을 듣고 배울 수 있었던 것이 가장 좋았다. 특히 컨텍스트가 사라지면 코드만 남기 때문에 일관성이 중요하다 라는 말이 가장 기억에 남는다. 내가 썼던 코드들은 어떨까?

마지막 강의는 장애 대응 때문에 듣지 못했지만, 주변 사람들에게 정말 추천하고 싶다. 여담으로 우아한 테크 캠프와 다른 교육이다. 같은 팀원에게 말했더니 우아한형제들로 이직하는 줄 알고 깜짝 놀랐다고 한다.

2. 그동안의 고민들

  • Graphql을 진행하며

    • HDD 하는 것은 아닌가? 나는 왜 PM의 물음에 제대로 대답하지 못했을까?
    • 뛰어난 팀원의 능력을 엉뚱한 곳에 끌어다 쓴 것은 아닐까. (나를 원망하고 있지는 않을까)
  • 잘 돌아가는 서비스를 바꾸는 것

    • 대충 보고 지나간 부분에서 전부 문제가 발생하였음. 좀 더 점진적으로 향상시킬 수 있는 방법은 없을까?
    • 똑같은 실수를 반복하지 않기 위해서는 어떻게 해야 할까?
  • 누가 등화가친의 계절이라 하였는가

    • 생각보다 독서를 많이 안 했다. 더 정확히는 많은 책을 읽다가 마무리하지 않고 다른 책을 읽었다.
    • 피곤하다는 핑계로 주중에 일이 끝나면 그대로 쉬었던 것 같다. 이런 나약함은 채찍질 당해야 마땅한 것 같다.
    • Q4에는 읽던 것들을 마무리 짓고 독서록을 남겨야겠다.
  • 여전히 답없는 고민 - 나는 잘 하고 있는가?

    • 솔직히 스스로가 만족스럽지는 않다.

3. Conclusion

  • 정말 바빴고 불꽃같이 일했던 Q3이었다.
  • 프로젝트 리딩에 대해 생각해 보게 되었다.
  • 실수를 줄일 수 있는 법에 대해 고민하게 되었다.
  • Q4는 개인 프로젝트에 rescuetime와 연동된 리포팅 기능이 추가될 예정이라, 코드뿐만 아니라 사용한 시간 추세에 대해서도 회고할 수 있을 것 같다. 덧붙여, 코드 기여에 대해 정확한 날짜를 볼 수 있게 업데이트를 할 생각이다.
  • 책을 읽어야겠다. 이러다 멍청이 되겠다. 더는 나태해지면 안 될 것 같다.

© 2021, Built with Gatsby