레벨3 팀 프로젝트 6주차 회고

mo-rak.com

 

데모데이

이번 스프린트의 데모데이 발표를 맡아서 진행했다. 5분 정도밖에 안 되는 발표였지만, 엄청 떨렸다.

하루정도 준비를 하는 시간을 가졌지만, 막상 발표를 시작하니 다 까먹었다.

그래서 프리스타일로 발표를 진행해버렸고, 뭐라고 발표를 했는 지도 기억이 안 난다.

이렇게 부족한 말하기 능력은 앞으로 내가 극복해야 할 문제인 것 같다.

 

프로젝트 진행.. 이게 맞나?

데모데이에서 우리 팀이 발표한 것과 다른 팀들이 발표한 것들을 보면 다른 팀들은 이제 거의 마지막을 향해 가고 있는 데, 우리 팀은 이제 시작한 것 같은 느낌이 들었다. 분명 같은 시간 동안 프로젝트를 진행했는데, 왜 차이가 많이 나는 걸까?

이에 대해서 데모데이가 끝난 후 회고를 진행하였다.

우리가 생각한 원인 중 제일 큰 문제는 프로젝트를 처음 설계할 때 너무 무리한 양을 계획을 세운 것이었다.

원래는 한 스프린트에 하나의 기능을 만들 예정이었지만 이는 무리한 계획이었던 것이다.

그래서 하나의 기능을 만들기 시작하면 다음 스프린트까지 이어졌기 때문에, 다음 스프린트에서 새로 만들어야 할 기능을 제대로 못 만들었다. 

우리는 한 스프린트에서 기능 자체는 동작할 수 있는 정도로 구현을 하였다. 그런데 예외 사항이 너무 많이 발견되었기 때문에 스프린트가 끝나도 계속해서 예외 상황을 처리해야 했다. 따라서 팀원들과 회의 결과 하나의 기능을 구현하는 것 자체가 굉장히 많은 작업을 해야 하고 이것을 한 스프린트에 구현하려고 했던 것이 무리한 계획이다라고 결론을 지었다. 

그러나 나는 우리가 이렇게 한 스프린트에 하나의 기능을 못 만들고 다음 스프린트까지 이어간 이유는 테스트 코드를 제대로 짜지 않았기 때문에 발생한 문제라고 생각한다. 테스트 코드에 대해서는 프로젝트 초반에 나와 다른 팀원들 사이의 의견 충돌이 있었다.

 

팀원들은 우리의 서비스가 기능을 많이 만들어야 되는 서비스이기 때문에 일단 기능을 만들기 위해 테스트 코드를 짜는 것보다 기능 구현에 집중해야 하고 예외 사항은 나중에 발견하면 처리하자는 의견이었다. 그리고 반대로 나의 의견은 기능을 만드는 것도 중요하지만 테스트 코드를 통해서 최대한 많은 예외를 찾아내고 수정하면서 진행을 해야 한다는 것이었다. 나는 이것을 질보다 양이냐, 양보다 질이냐의 문제로 이해했다. 물론 나의 의견대로 진행한다면 기능을 만드는 속도는 조금 더 느려졌을 것이다.

이 의견 대립 과정에서 모든 팀원들이 일단 기능이 먼저라고 생각하였고, 나는 이 꼼꼼함, 세심함 성향이 프로젝트를 망칠 수 있다 라는 블로그 글을 보고 팀원들의 의견을 수용하기로 하였다. 이 블로그의 내용을 간략하게 요약하자면 다음과 같다.

한정된 시간과 자원으로 성과를 도출할 때 모든 일을 꼼꼼히 처리하려고 하면 오히려 중요한 부분을 놓치게 된다.
따라서 우리의 목표에 큰 영향을 미치지 않는다면 허점이나 빈틈에 관대해져야 한다.

 

이 글을 보고 내가 너무 팀원들에게 많은 것을 요구하는 걸까? 라는 생각과 많은 예외 사항을 다 처리하려다보면 우리가 만들고자 하는 서비스는 결국 못 만들게 될까? 라는 생각이 들었다. 그래서 테스트 코드를 소홀히 하고 기능 구현에 집중하였다.

 

하지만 그 결과, 우리는 제대로 된 서비스를 만들지 못하게 되었다. 

 

테스트 코드가 잘 작성되지 않은 코드를 서버에 올려서 서비스를 진행해보았는데, 상당히 참담했다.

알 수 없는 예외들로 인해 우리의 의도대로 서비스가 진행되지 않았다. 기능만 빠르게 구현하여 많은 기능을 추가하려고 했지만, 만들어낸 기능들이 제대로 동작하지 않았다. 이 부분에서 '기능을 많이 만들어봤자 제대로 사용할 수 있는 기능이 없는데 사용자들이 이런 서비스를 사용하고 싶어 할까? 굳이 이런 걸 왜 쓰겠어'라는 생각이 들었다. 내가 직접 만든 서비스임에도 불구하고 이런 생각이 들었다는 것은 상당히 심각하다고 생각하였다.

 

사실 저번 주까지는 이런 상황이 나중 가면 괜찮아지겠지? 라는 안일한 생각을 가지고 있었다. 그러나 6주차가 되어서 깨달았다. 우리는 지금 잘못된 방향으로 가고있었다. 너무 늦게 깨달은 것이 아닐까? 라는 생각도 들지만 한편으로는 다음에는 최초의 나의 의견처럼 하나의 기능을 만들더라도 더 꼼꼼하게 만들면 더 좋은 서비스를 만들 수 있을 것이다라는 생각이 들었다.

 

특히 이번주에는 우아한형제들의 대표 김범준님의 방문이 있었는데, 김범준님의 말씀을 듣고 더욱 더 테스트 코드의 중요성에 대해 인지하였다. 김범준님께서 우아한형제들은 좋은 기술력을 가지고 있다고 하였다. 배달의 민족에 많은 트래픽으로 인해 시스템에 장애가 발생해도 빠르게 시스템을 복구할 수 있다고 하였다. 

 

나는 이것을 듣고 지금 우리 팀의 수준에서는 테스트 코드를 잘 작성하는 것이 팀의 기술력을 높이는 것이라 생각했다.

서비스에 방어로직이 많을 수록 시스템에 장애가 발생해도 어떤 이유로 장애가 생기는 지 빠르게 판단하고 대처할 수 있기 때문이다.

 

6주의 프로젝트 과정을 겪으면서 테스트 코드의 중요성에 대해 다시 한번 생각해볼 수 있었다.

그리고 팀 프로젝트의 실패를 겪어보는 것도 굉장히 좋은 경험인 것 같다. 항상 성공할 수는 없는 법이다.

물론 아직 2주의 시간이 남아서 실패를 했다고는 볼 수 없다. 남은 2주를 불태워서 좋은 결과물을 얻어봐야겠다.

 

 

 

 

[프로젝트 깃허브]