[현업 프로젝트 - 1] Semi-Regression

신입으로 취업한지 어느덧 5개월차... 거의 반년이 되어가는데, 다른 의미로 현타가 오고있다...

 

우선, 현 회사에서 처음으로 큰? 프로젝트를 들어갔고, 개발한 지 3개월 차가 되었다. 나는 현재 Web (React, Node), Chrome Extention, Electron으로 이루어진 3개의 프로덕트 개발을 맡았다.

 

기존 당차게 당부한, "이미 개발되었던 적이 있던 것들!" 이라는 매니저분들의 말들과는 200% 다르게... 살이 붙고 뼈가 붙고, 또 바뀌고 또 바뀌었다...

 

그 과정 속에서 팀이 이루고 있는 프로세스의 결함, 개발 과정 속에서 지속적으로 바뀌는 변곡점, 문서의 부재와 커뮤니케이션 오류, 빡빡한 일정과 고려되지 않은 세부 기능들... 이 외에도 정말 많은 것들이 힘들게 하고 있는 것은 사실이다...

 

현 프로젝트를 진행하며, 많은 개발-비개발 실무자들의 불만이 쌓여있고, 앞으로의 방향성과 업무 효율성에 대해 많은 의구심을 갖고 있기 때문에, 현재 가장 중요하다고 생각하는 문제들을 Regression에서 효율적으로 전달 할 수 있도록 정리해보고자 한다...

 

---

과연 우리 팀은 "애자일"일까 "워터폴"일까?

사실, 요즘 소프트웨어를 운영하는 IT기업들의 트렌드는 애자일 방법론을 따라간다. 애자일하게 일하면 일할수록 유연한 대처와, 빠른 피드백이 가능하기 때문이다. 목적 조직으로 이루어진 팀 일 수록, 이러한 방법론은 빛을 바라기 마련이다.

 

그렇다고 워터폴 방식이 OLD 하고, UNSTABLE 한 것은 아니다. 가장 장수한 만큼, 확실하고 타임라인 관리가 용이하며, 설계-개발-테스트 과정을 효율적으로 가져갈 수 있다.

 

하지만 3개월동안 개발을 하며 느낀점은 워터폴 방식에서 애자일의 스타일을 따라가고 있다는 느낌을 너무 쌔게 받았다.

자세한 설명없이는 좋아보이는 이 말이, 각 방법론에서 단점만 가져갔다라고 생각하면, 다시 한번 생각하게 될 것이다.

 

우선 큰 틀은 워터폴 방식이다. 다만 이 워터폴의 큰 틀, 즉 큰 플로우가 단 두개로 이루어져있다. 코딩-테스트...

 

실질적으로 개발을 들어 갈 당시 받아본 기획서에는, 정말 너무하다 싶을 정도의 설명밖에 없었다. 각 페이지에 약 6개의 섹션, 각 섹션별로 큰 의미에서의 동작 설명, 세부 설명으로서는 "기존 개발되었던 기능"... 심지어 해당 부분들은 1주일도 안가 Backlog로 가득 쌓여 버려 의미가 없어졌다. 공부 할 당시 진행했던 프로젝트에서도, 사용자 명세서, 기능 명세서, 간단한 목업과 프로토타입 등등 모든 실무자들이 같은 그림을 볼 수 있도록 노력하는 것이 선행되었는데, 실무에서 이래도 되나? 할 정도의 의구심을 들게 하였다.

 

애자일한 조직에서 위의 경우는 문제가 되지 않는다. 각 파트에 참여하는 인원끼리 모여 논의 후 해당 부분들을 정리하여 실질적인 개발에 반영하면 그만이다. 그만큼 유연하기 때문이다. 하지만 워터폴인 방식에서 이러한 문제에 놓여있다면...? 결과적으로 불필요한 회의의 연속과 일치하지 않는 프로젝트의 그림, 용어와 기능의 혼동 등, 프로젝트에 있어 난항을 겪게 했다.

 

두 번째로, 워터폴 방식이지만, 기획-디자인-개발이 모두 같은 선상에서 출발했다. 각 프로덕트에 대하여 어느정도의 시간을 두고 플로우가 흘러간 것이 아닌, 일별로 기획-디자인-개발이 이루어지다보니, 일 단위로 작업이 이루어지고 개발이 팔로우 업 하는 방식이 되었다. 그렇다보니 여러 프로덕트를 함께 개발하는 만큼, 실무자들은 후작업을 진행하고 있는 사람들의 질문에 혼동을 갖기도 하고, 불안정한 결과물을 전달하기도 하였다. 이 모든 것이 너무 압박적인 시간에 의해 생성되었다... 야근은 물론, 주말 근무를 매일 하고 있는 결과물을 갖고왔다.

 

---

누가 어떤 일을 진행하고, 완료했는지 아무도 모른다.

기본적으로 Jira를 활용하고 있지만, 그 누구도 작업의 의미를 찾기 위해 Jira를 들여다 보지 않는다. 현재 각 인원의 Task 관리용도로만 활용되고 있는게 현실이다.

 

해당 현상이 이루어진 이유에는 첫째로 숙제 관리 식이 되어버린 티켓이다. 티켓을 사용하는 용도로는, 해당 Task의 상태를 확인하는 수단으로 밖에 쓰이지 않고있다. Story, Sub Tasks, Description 등등... 다양한 기능을 활용하여, Jira로만 일 할 수 있는 환경이 되야하지만, 직접 물어보며 서로를 귀찮게 하는 방식으로만 작업들이 진행되고 있다. 매일, 매주 들려오는 작업에 대한 진행도 체크와, 언제까지 되냐는 질문이 굉장한 스트레스로 다가오고 있다...

 

또한 이러한 티켓의 생성 때문에, 해당 티켓이 어떠한 의미를 갖는지 매번 스스로, 그리고 관리자에게 상기시켜줘야한다. 부모 티켓, 즉 스토리나 큰 Task 단위로 관리되고 있지 않기 때문에, 해당 작업이 어떠한 부분의 작업인지, 디팬던시가 무엇인지, 해당 작업 이후 어떠한 작업이 이루어질 지 등, 각 티켓에 어사인 된 실무자만이 인지하고 있을 뿐이다.

 

---

너무 단점만 나열한 일종의 한풀이 같은 글이지만, 아직 나는 프로젝트를 진행 중이다. 해당 글은 프로젝트가 끝날 때 까지 업데이트 될 것이고, 이 후 Regression을 갖은 이후에는 어떻게 바뀌었는지, 어떻게 바꾸고자 노력했는지 등 조금 더 희망적이고 생산적인 이야기를 할 것이다. 실패는 성공의 어머니 이듯, 실패에도 떳떳해야 성공 할 수 있다고 믿는다. 고로 문제가 되지 않는다면, 내가 느낀 단점과 장점들은 명백하게 인지한체, 주니어 생활을 보내고 싶다.

 

다행히 좋은 점도 있다...! 내가 개발을 정말 좋아한다는 것이다! 만약 모든 과정들이 단순히 '일'이라면 굉장히 힘들게 느껴졌을 것이다. 하지만 '개발'의 과정이 '일'로 느껴지지 않는다. 따라서 개발 함에 있어 하는 고민들이나, 시간들이 아깝거나 힘들다고 느껴지지 않는 것 같다 ㅎㅎ