우리 프로젝트는 왜 망했는가?

8개월간 진행했던 프로젝트에 관해 회고해보려고한다.

프로젝트 진행에 대해 문제가 있었다고 생각하는 부분에 대해서만 작성해 보려고한다.

우리 프로젝트는 왜 릴리즈 하지 못했는가?

처음 시작할 때까지만 해도 적어도 프론트팀은 어떤 스택으로 진행할지 어떤 라이브러리를 쓸지 자유롭게 의견논의가 되었기때문에 나는 이프로젝트가 순조롭게 진행될거라고 생각했다.
적극적으로 의견을 내고 원하는 라이브러리가 채택되고 이번 프로젝트는 느낌이 좋은데? 라고 시작했었다.

하지만 생각처럼 순조롭게 흘러가지않았다. 처음부터 커뮤니케이션 문제에 봉착했다. 공통컴포넌트 수정에 있어서 의견 공유가 되지않고 리더는 단 2명뿐인 멤버의 태스크도 핸들링 하지못했다. 이 당시에 프론트팀 멤버는 나와 또 다른 멤버 둘 뿐이어서 내가 적극적으로 미팅을 열어 문제를 해결하려고 노력하면 해결 가능한 문제들이었다.
하지만 이 다른 멤버는 미팅을 하고 메신저로 공유하고 코드 리뷰를 해도 독단적으로 업무를 진행하고.. 미팅에서 정해진 내용조차도 지키지않고 프로젝트를 진행했다. 이때부터 삐그덕거리기 시작했는데 점점 프론트팀의 인원은 늘어갔다.
멤버가 늘어가면서 팀내 커뮤니케이션 문제는 점차 더 커져갔고 다른팀과의 연계에서도 문제가 발생되기 시작하였다. 문제가 해결되지않은 상황에서 스케쥴은 점점 촉박해져갔고, 스케쥴을 맞추기위해 제품의 퀄리티는 점차 뒷전이 되기 시작했다. 당연스럽게 리뷰는 형식상 존재하게 되었고 코드컨벤션정도는 그냥 무시하고 넘어가고 머지에서 문제되지않으면 동작 테스트도 없이 메인브랜치에 머지되는 결과를 낳았다....
스케쥴내에 작동하는 코드는 만들어졌지만 결국 테스트에서 많은 버그들이 발생하였다. 결국 릴리즈를 할 수 없는 상황이 와버렸다.

여기까지가 내가 약 8개월 참여했던 프로젝트의 간략한 상황이다. 이 프로젝트가 왜 릴리즈 할 수 없었는가? 에대해 많은 고민을 했고, 프로젝트에 참여하는동안 개선했으면 하는 점들이 많았기때문에 글로 작성을 해보고자 한다.

우리프로젝트는 무슨 문제가 있었는가?

• 각 팀간의 커뮤니케이션 부재

  • 리더들사이에서는 커뮤니케이션이 가능했는지는 모른다. 매일 아침 리더회의가 있었지만 리더회의에서 무슨 말이 있었는지 팀원들에게 공유되지않았다.
    • 사양변경 → 수정되지않는 설계서
      • 프론트팀의 경우 화면 설계서와 API정의서를 기준으로 개발을 진행하였다. 그리고 초반엔 API가 제공되지않아 목데이터를 사용해서 개발을 진행하였다. 하지만 추후 제공된 API는 실제 설계서와 달랐고 달라진 데이터에 대한 정보는 어디에도 적혀있지않았다. 단지 개별적으로 API정의서와 리스폰스가 다르다고 연락해서 개인적으로 정보를 제공받고 그 정보 역시 어디에도 수정되지않았다. 이전 담당자가 퇴사한 순간 상상력에 의존해 일을 진행할 수 밖에 없었다.
    • 각 팀별 멤버의 발란스
      • 프로젝트에 팀 구성이 달라지겠지만 우리 프로젝트의 경우 이유는 프론트는 10명정도 백엔드는 4,5명정도의 인원이 어사인 되었다. 게다가 백엔드의 경우 초반부터 인원이 변경되지않고 유지되었지만 프론트팀의 경우, 도중에 합류한 인원들이 너무 많았다. 백엔드의 인원은 부족하고 프론트에만 사람이 어사인되면서 성능상 백엔드에서 처리해야할 로직도 프론트에서 처리해줬으면 좋겠다. 라는 요청이 들어오기시작했다. 업무를 하면서 SQL쿼리만 조금 수정하면 재가공 없이 완벽한 데이터를 입력받을 수 있을텐데... 라는 생각을 상당히 많이 했다. 수정되지않은 API를 그대로 프론트로 넘겨 프론트에서 모든 처리를 진행하는 부분이 이해가 되지않았다. 리더에게도 이건 프론트에서 하는건 성능적으로 좋지않다고 건의도 해봤지만 돌아오는건 “현재 백엔드에선 할 여력이 되지않는다. 그러니 느려도 해달라”였다 → 이건 나중에 성능문제로 클레임이 들어온건 덤이다.
    • 설계 따로, 개발 따로
      • 처음 개발하기전에 기획부분에서 타회사에 외주를 줘서 진행했고 완벽히 끝나지않은 상태에서 그 회사와의 계약이 끝이났다. 설계서의 정보가 부족한데 작성자뿐만아닌 그 팀 전체가 날아갔었기에 누구한테도 문의할수없는 말도안되는 상황이 벌어졌다;;
    • 어떻게 보완했어야할까?
      • 설계변경에 대해서는 정확하게 기록을 남기기 → 설계서 수정 (버전관리이용) → 이부분 역시 구글드라이브로 관리 했으나 버전은 없이 같은 이름으로 여러가지 폴더가 생겼지만 어떤게 최신판인지 명시되지 않았다..
      • 프론트팀 리더의 핸들링 → 리더가 좀 더 강하게 프론트에서 처리하지않아도 될부분은 강하게 주장했어야한다는 생각이든다.
      • 단가를 낮추기위해 여러 회사를 고용하는것은 어쩔수없는일이라고 생각한다. 하지만 최소 이를 컨트롤할 수 있는 리더의 부재는 매우 아쉽다. 여러 회사가 모여 일을 하기때문에 리더의 역량이 더욱더 필요하지않았을까? 라는 생각을 해본다.

• 기본적인 실력부족, 그리고 리뷰 부족

  • 물론 나도 리액트에 대한 지식이 높은편은 아니기때문에 내 코드 역시 부족함이 많았다고 생각한다. 부족한 만큼 초반에 조금 더 리뷰에 신경썼으면 좀 더 높은 퀄리티의 코드를 만들 수 있지않았을까? 라는 생각을 했다. 초보 멤버는 많은데 코드의 컨벤션은 통일되지않고 “tableA”, “tableB”등의 변수까지 등장했지만 리뷰에서는 어떠한 피드백도 돌아오지않았다. → 이는 이후 온갖 버그가 발생했을때 대처를 늦게 만든 원인중 하나라고 생각한다. 또한 입력 컴포넌트를 A, B화면에서 사용하고있을때 B화면에서 수정후 A화면은 확인을 안해서 A화면에서 에러가 나는등 총체적 문제가 있었다.
    • 어떻게 보완 했어야할까?
      • 프론트팀의 리더는 온갖 미팅에 참석했기때문에 기본적인 리뷰시간이 부족 했으리라 생각한다. 나는 리뷰를 꼭 실력자가 해야한다고 생각하지도 않는다. 최소 팀원간에 크로스체크정도라도 진행했다면 변수네임정도는 누군가 지적하지않았을까? 또한 무지성 머지를 통해 이미 수정된 버그가 되살아나는 케이스도 상당히 많았는데 이부분도 최소 다른 팀원들이 확인했다면 적어도 이렇게 많은 문제가 나진 않았을거라고 생각한다. 또한 리뷰를 하면서 다른 팀원의 코드를 보며 공부할 수 있기때문에 팀원간의 리뷰가 없었던 부분은 매우 아쉽다고 생각한다.

• 테스트데이터 부족

  • 프론트팀에서는 API연결이후에도 실제 API가 아닌 목업데이터(1건밖에 존재하지않는)를 받다보니 실제로 제대로 데이터가 갱신 되는지, 각 조건에 따라 어떻게 보이는지 확인할 수 있는 방법도 없었다. 또한 테스트 관점조차 제대로 연계된 부분이 없었기에 굉장히 많은 버그를 만날 수 밖에 없었다.
    • 어떻게 보완 했어야할까?
      • 다양한 테스트데이터 제공 → 목업데이터를 만들어서 테스트를 하는 방향으로 개선 하긴 했지만 테스트 케이스를 만드는 시간까지 포함하면 비효율적이라고 생각했다.

• 능력없는 팀원의 영입

  • 단가를 낮추기위해 하청의 하청의 하청으로 업무를 이관하는것은 일본 기업들의 오래된 특징중 하나이다. 그로인해 우리회사에서도 저렴한 인건비를 위해 다른 회사 직원을 고용하는 경우도 있었다. 자사직원이라고 말하면 실력검증없이 프로젝트 합류하는 것이 가능했기때문에 가능한 일이었다. 이 직원은 몇번의 지적이 있었음에도 불구하고 다른 사람의 코드를 확인하거나 사양변경에 대해 독단적으로 처리하는 일이 많았다. 이는 2시간이면 끝날 업무를 5,6시간씩 하게만든 원인이 되었다.
    • 어떻게 보완 했어야할까?
      • 철저한 실력검증 & 후속조치→ 물론 누구나 개발을 잘할 수는 없다. 나 역시도 누군가가 볼 때 저런 실력으로 개발자라고? 말할수도 있다고 생각한다. 하지만 최소 다른 사람의 피드백을 들으려는 노력은 하고있다고 생각한다. 하지만 그런 노력도 존재하지않고, 팀원의 불만이 쌓여만간다면 그에대한 대응은 필요하다고 생각한다. 이러한 대응이 존재하지않는다면 결국 팀원이 먼저 지쳐서 그만두게 될것이다.

나는 이 프로젝트에서 무엇을 잘못했는가?

• 커뮤니케이션 부족
  • 재택이라는 핑계로 커뮤니케이션을 소홀히한 부분이 있다. 내가 가진 불만이나 힘든 점을 먼저 공유했으면 내 업무환경은 조금은 괜찮아졌을텐데. 왜 말하지 못했지? 라고 생각하면 아쉬움이 남는다. 핑계를 대보자면.. 재택근무로 인해 정해진 미팅시간 외에는 쉽게 대화하기 어려운 상황이 만들어졌고 그러다보니 도피한 부분이 있던 것 같다.
    
  • 설계서의 부족한 부분이 많았는데 그 부분에 있어서 확인 작업이 미숙했던 것 같다. 물론 매번 화면마다 물어봐야한다는것이 귀찮기도 했지만 그러다보니 부족한 부분은 상상력을 동원했던 것 같다. 이것은 이 후 사양과 다르기때문에 많은 수정이 필요하게 되었던 것 같다.
• 타입스크립트에 대한 이해도 부족
  • 타입스크립트에 대해 공부하려고 책을 구매해놓고 제대로 읽지않은 자신을 반성하며.. 타입스크립트를 좀 더 스마트하게 쓸수있는 여러 방법이 있었는데 나중에 공부하면서 코드를 보면 수정할 점이 너무나 많았던 것 같다.. 기술적인 부분은 계속 공부해나가자!!

그럼에도 불구하고 나는 이 프로젝트를 통해 무엇을 배웠는가?

• 리액트와 조금은 친해졌다?
  • 리액트를 개인적으로 공부를 해봤지만 실제로 현업에서 사용한건 처음이었다. 거기다 팀원들도 초보들이 많아서 코드 퀄리티를 높이기위해선 정말 많은 공부가 필요했다. 처음엔 정말 제대로 모르고 그냥 복붙했는데 점점 아 이게 이런거구나? 점점 코드를 이해할 수 있었던 것같다.
  • 처음엔 리액트라이브러리를 제대로 이해하지못하고쓰는 경우가 많았지만 점차 익숙해졌고 어느정도 능숙해졌다고 생각한다.
• 커뮤니케이션 능력 향상
  • 앞서 커뮤니케이션이 부족했다고 말을 했지만 아쉬운 한편 성장도 했다고 느끼는 부분이다.
  • 처음부터 팀에 합류해서 사양적으로도 코드에대해서도 가장 많이 알고있었기때문에 새로 들어오는 멤버들에게 전체적인 플젝에 대한 설명을 많이 하면서 커뮤니케이션능력이 조금은 상승하지않았을까? 라고 생각한다.
  • 초반부터 쓰고싶은 라이브러리가 있다면 쓰고싶은 이유와 우리 프로젝트에 적합한 이유, 그리고 썻을 때의 메리트와 디메리트를 정리해서 적극적으로 어필했다. 단순히 쓰고싶다고 우긴것이아니라 적합한 이유를 정리하고 설명하면서 이부분에 대한 능력이 향상되었다고 생각한다.
• 좋은 프로젝트, 좋은 리더란 무엇인가? 라는 생각을 깊게하게되었다.
  • 처음엔 불만이 쌓여만 갔지만 왜 이렇게되었을까? 라는 생각하고 나라면 어떻게 보완을 했을까? 라는 생각을 하게되었다.
  • 좋은 프로젝트에서 배우는것도 많지만 왜 안 되었을까? 를 생각하면서 보완점을 생각해보고 개선하려고 했던 노력은 나에게 있어서 큰 성장이 되었다고 생각한다.