부스트캠프에서의 Lesser

부스트캠프에서 마지막 6주는 팀 프로젝트 기간입니다. 저는 마음이 맞는 백엔드 팀원을 미리 구해 놓았고, 아래의 사진처럼 프론트엔드 팀원을 모집했습니다.

팀 모집을 할때 가장 중요한 목표로 “1년 이상 유지보수 및 개선을 해보자!”를 작성했는데 다행히 이 목표에 공감하는 팀원들과 만났고, 팀장의 역할을 맡아 ‘Lesser’ 프로젝트를 진행할 수 있었습니다.

덕분에 부스트캠프 이후 약 4개월간 지금까지도 같은 팀원들과 프로젝트를 개발하고 있습니다. 6주 동안의 경험인 부스트캠프에서의 아쉬웠던 점, 배웠던 점을 공유하고, 부스트캠프 이후의 개발에서 아쉬운 부분을 어떻게 개선하고 좋았던 점, 배운 점은 어떻게 이어 나갔는지 공유하려 합니다.

아쉬운 점

애자일한 척

저희 팀은 애자일 방법론을 지원하는 프로젝트 관리 서비스입니다. 저를 포함해 팀원들 모두 애자일에 대한 지식이 전혀 없는 상태에서 애자일 방법론을 프로젝트에 적용하기는 쉽지 않았습니다. 그러서 애자일에서 사용하는 다양한 절차를 팀의 절차에 적용해보기로 했습니다.

‘Lesser’는 매일 회고했습니다. 회고 시간에는 무엇을 해야 할까요? 저희 팀은 하루를 돌아보는 정도의 의미를 생각하고 회고를 진행했습니다. 팀단위 혹은 개인단위로 매일 돌아본다면 더 팀이 나아질 거라고 생각했습니다.

그러나 아래 이미지에서 보다시피 팀의 문제는 없어지지 않고 계속 반복되었습니다. 애자일 방법론에서 회고의 의미는 팀과 개인의 문제를 파악하고 추적해 개선하기 위함입니다. 이를 모르고 돌아보기만 한다면 문제가 해결되지 않습니다.

저희 팀은 이것을 몰랐습니다.

애자일한 조직에서는 팀원끼리 유기적으로 연결되어 서로의 일정을 알맞게 조율해 업무의 순서를 결정하고, 필요하다면 개개인의 업무를 변경할 수 있어야 합니다. 이러한 조율이 데일리 스크럼에서 일어나야 합니다.

데일리 스크럼 또한 매일 진행했으나 업무를 조율하는 절차가 아닌 서로의 진척 보고회에 가까웠습니다.

“저는 오늘 여기까지 했습니다”가 모든 팀원의 주요한 멘트였고, 저를 포함한 팀원들은 서로의 업무를 전혀 모르고 있었습니다. 이러한 상황에서는 항상 업무 담당자만이 문제를 해결할 수 있습니다. 팀원들은 문제에 도움을 줄 수 없어서 문제를 해결하는 시간이 길어지고, 더 좋은 방법으로 문제를 해결할 기회를 잃어버립니다. 이러한 문제점은 애자일방법론에서 해결하고자 하는 전통적인 팀의 문제점에 가깝습니다.

애자일한 팀을 원했지만 우리는 애자일의 정반대에 서 있었습니다.

결국 ‘Lesser’는 애자일의 절차를 모두 따랐지만, 전혀 애자일하지 않았습니다.

왜 이런 문제가 생겼을까요?

결론부터 이야기하면 애자일 방법론의 본질과 애자일 절차의 본질에 집중하지 않았기 때문입니다. 애자일 방법론을 따랐지만 기민하지 못한 조직이었고, 애자일의 절차를 따랐지만 개선하려고 하지 않았고 협업하지 않았습니다. 오히려 각자의 일을 하고 서로를 감독하는 스터디에 가까웠습니다.

팀원 모두 이에 대해 아쉬움을 느껴 애자일 절차를 개선했습니다. 이 부분은 다음 포스팅에서 다시 말씀드리겠습니다.

깊은 고민을 하지 못한 나와 우리

6주간 하나의 프로젝트를 완성 시켜야 했기 때문에 프로젝트의 크기를 적절하게 계획해야 마땅하지만, 저희는 그러지 못했습니다. ‘Lesser’를 프로젝트 관리 서비스로서 회원, 백로그 관리, 스프린트, 칸반보드, 회고의 기능을 모두 지원하는 큰 프로젝트를 기획해 백엔드 기준으로 30개가량의 API를 개발해야 했습니다.

기획과 발표를 제외하면 실제로 코딩에 몰입해 작업 할 수 있는 기간은 3주~4주이고 인프라 관련 태스크도 해야 하기 때문에 백엔드 2명이 처리하기에는 더더욱 과도한 크기입니다. 게다가 애자일 절차는 절차대로 소요가 있어 작업할 시간은 더더욱 줄었습니다.

데모 전날에 모든 팀원이 모여서 API를 연결하는 작업을 했는데 이 시간이 점점 길어져 4~5주차에는 3~4시간 동안 끝없이 터지는 버그를 수정하고 데모날에 정상적으로 동작하기를 기도했습니다. 이렇게 끝없는 버그 수정과 동작에 자신이 없는 것은 분명 코드의 퀄리티에 문제가 있다는 증거입니다.

간단한 API 하나를 작성할 때도 분명한 근거를 가지고 확실하게 구현해야 한다고 생각합니다. 또한 프로젝트가 커짐에 따라 동작을 보장하기 위해 최소한 e2e 테스트코드는 꼭 필요합니다.

하지만 시간이 없다는 이유로 고민하지 않고 가장 구현하기 쉬운 방향으로 구현을 하게 되었습니다. 초반에는 문제가 없었으나 시간이 지남에 따라 점점 스스로 기술적인 능력이 정체됨을 느꼈고, 코드에 확신이 없어 다음 코드를 작성하는 것이 두려운 지경에 이르렀습니다. 이렇게 고민 없이 작성한 부분은 부스트캠프 팀 프로젝트에서 스스로 가장 아쉬운 부분입니다.

배운 점

열정적인 사람들을 주위에 두자.

지금까지 개발과 비개발을 포함해서 여러 번 프로젝트를 해보았지만 ‘Lesser’의 팀원처럼 열정적인 팀원과 함께 한 적은 없었습니다. 이전의 프로젝트를 돌이켜보면 저를 포함한 팀원들 모두, 학점을 위해서든 또는 졸업을 위해서든 해당 목적을 넘어서는 스스로에 대한 성장 의지, 좋은 팀과 좋은 결과에 대한 욕망이 적다 못해 없었습니다.

하지만 ‘Lesser’는 달랐습니다. 팀은 방향이 잘못될지라도 앞으로 뛰길 원했고, 개개인은 더 좋은 개발자, 더 좋은 팀원이 되기를 원했습니다. 6주간 매일매일 저녁 10시까지 코딩하며 힘들더라도 군말 없이 참여해주었고 오프라인 회의를 위해 매주 한 번 3시간가량을 서울로 이동하는 팀원들도 있었습니다.

특히 모르는 것을 대하는 자세가 가장 인상 깊었습니다. 팀원들은 모르는 게 있으면 확실히 물어보았고 자신의 생각과 언어로 표현할 수 있을 때까지 짚고 넘어갔습니다. 그러나 과거의 저를 돌이켜보면 모르는 것을 들키기 싫어 적당히 웃으며 넘긴 적도 많았습니다. 또한 이것은 서로 귀찮게 하지 말고 적당히 하고 넘어가자는 의미도 있었 던 것같습니다. 하지만 이런 자세는 분명 팀과 개인의 성장을 방해하는 자세입니다. 열정적인 팀원들 사이에서 이런 태도는 금방 없애버릴 수 있었습니다.

기억보단 기록을

사실 저는 기억에 의존하는 사람에 가까웠습니다. 그 이유는 기록하는 당시에는 기억이 생생하기 때문에 기록에 대한 필요성을 못 느꼈고, 추후 기억이 휘발되어 기록이 필요한 시점에는 기록에 필요한 정보를 다시 학습하는 게 싫어서 기록하지 않았던 것 같습니다.

하지만 이런 습관은 정말 위험하고 좋지 않습니다. 당연하게도 사람의 기억은 유한하고 자주 접하는 정보가 아니라면 휘발될 수밖에 없습니다. 이럴 때 다시 돌아볼 기록이 필요합니다. 하지만 돌아볼 수 있는 기록이 없으면 영영 잃어버리게 됩니다.

또한 기록을 하는 것은 자신의 생각을 정리하는 장점도 있습니다. 기억으로 정보를 가지고 있을 때 스스로 정확하고 논리적으로 생각하고 있다고 착각할 수 있습니다. 하지만 실제로 말을 해보면 논리적이지 못하고, 빈틈이 있는상태로 말을 하게 되었던 경험이 여러차례있습니다. 이를 기록의 형태로 작성해보면 생각이 단단해지고, 스스로 정확하게 알지 못했던 놓친 부분을 잘 메꿀 수 있습니다.

팀 프로젝트를 하며 기록을 꾸준히 하는 좋은 팀원들을 만난 덕분에, 저는 기록하는 습관을 점진적으로 익힐 수 있었습니다. 학습한 내용을 정리해 학습공유 문서를 작성하고, 문제를 겪고 해결한 것을 정리해 트러블 슈팅 문서를 작성하는 등 제가 깨닫고 느낀 많은 것들을 기록해 보는 경험을 꾸준히 했습니다.

그리고 이러한 깨달음은 지금까지도 저에게 많은 영향을 끼쳤습니다. 프로젝트를 작업하는 날에는 거의 매일 학습 및 트러블 슈팅 문서를 작성해 기억보다는 기록을 가지려고 노력합니다.

앗! 그리고 ‘기억보단 기록을’은 향로 님의 블로그 제목입니다.

그래서 부스트캠프 이후에 어떻게 되었는데?

→ 분량 조절을 실패해 다음 포스팅에서 이어 나가겠습니다! 감사합니다~~