SPC 프로젝트

프로젝트 일정 

8월 26일에 시작 - 12월 13일에 운영 오픈

SPC 허브앱에 들어가는 할일 관리 시스템

웹/모바일 전부 개발하는데 인력은 7명이다.

아쉬운 점

우리팀이 너무 힘들다고 3명이나 퇴사했다ㅜ 10명에서 7명으로 줄었다.

본부장님은 미팅쪽 감당하기도 벅차셔서 신경도 못써주시고, 신입도 안준다.

1년내내 개고생 시켜서 팀장으로써 미안한데 다들 고생한만큼 잘되어서 다행이라고 생각한다.

 

아쉬운 부분이라면 스터디도 하고, 새로운 것도 가르쳐주고, 새로운 기술스택도 경험하게 해주고 싶은데 못해줬다.

원래 협업툴 프로젝트 끝나고는 기존에 우리가 작성했던 테스트 시나리오들을 토대로 셀레니움을 통한 프론트 테스트 시나리오 자동화와, 백엔드 스프링 전환 및 테스트 코드 작성 등을 하려고 했는데 본부장님이 원하는대로 와플웍스 아키텍처를 구성해달라고 해달라는 것을 설득을 못했다. 본부장님 방을 10번 가까이 찾아갔는데 설득 못했다. 이게 한이다.

그래도 노션은 도입했다.  다른 회사에서 많이 쓰는 협업툴이라도 도입해봐서 다행이다. 

 

그래도 말도 안되는 업무량과 인력과 일정덕에 개발도 많이하고 이슈도 엄청나게 많이 해결했고 문제를 해결하기위한 토론은 엄청많이 했으니 어딜가든 1인분 이상은 할거라고 생각한다. 이직한 회사에서 다들 한자리씩 차지했으면 좋겠다. 다른팀이랑 비교해봐도 우리팀원들이 정말 A급으로 큰 것 같다. 2020년에 얘네들 가르치느라, 내 업무는 6시부터 시작했던 기억이 난다. 그래도 훌륭하게 성장했고 아직도 열심히 해줘서 고맙다. 나중에 창업하게 된다면 우리팀원들을 데려가고 싶다.

 

거의 막바지라 지금도 너무 바쁘다. 진짜 화장실도 뛰어다닐정도로 바쁘다.

우리팀만 유일하게 점심시간에 밥먹자마자 바로 일하는게 습관이 되었다.

프로젝트가 바뻐서 시험 준비할 시간도 빠듯하다.

신경써야하는 부분도 너무 많고 할일도 너무 많다.

너무 피곤하지만 정리를 해야할 것 같아서 정리하려고 한다.

 

신경 썼던 부분

1. 아무리 바뻐도 코드리뷰를 철저히 하도록 했고 팀의 문화로 정착시켰다.

지금 진행하는 프로젝트가 자사 솔루션이 될 코드이기에 최대한 완성도 있게 개발하도록 최선을 다했다.

바쁜 와중에 오픈소스도 조사해서 어떻게 구현할지 철저하게 팀원들과 토론했고 지금 생각해도 과장 한수푼 더하면 오픈소스로 내놓아도 부끄럽지 않을 퀄리티로 개발했다.

 

지속적으로 가져가야하는 코드이기 때문에 모든 이슈를 그냥 처리하지 않고, 철저하게 앞으로 발생할 일과, 시간이 걸리더라도 근본적인 원인을 해결하는 방향으로 이슈를 처리하도록 철저하게 관리했고, 해결 방법또한 최선인지 꼼꼼하게 체크했다. 아무리 바뻐도 일주일에 한번은 팀원과 토론을 했다.

 

GitLab들어가서 우리팀 코드 리뷰한 흔적을 바라보면 참 기특하고 기분이 좋아진다. 갖고 나갈 수 있다면 가져와서 블로그에 올려놓아 자랑하고 싶을 정도다.

 

2. 현재 개발하는 시스템을 추후에 구독형 솔루션으로 올라갈 와플웍스로 가져갈 수 있도록 구현하였다.

- 와플 플랫폼의 메인급 앱으로 가져갈 예정이고, 구독형 서비스로 제공되는 자사 제품이 될 예정이기 때문에 추후 발생할 일을 대비하는게 필요했다.

- 실제로 현재 와플 플랫폼 위에 올라가 있고 다른 기능은 뺀 상태로 SPC에 제공한다. 와플 스택에 올라가 있기 때문에 고려해야하는 포인트가 굉장히 많다. 그냥 개발하는거보다 두배는 힘든 것 같다. 실제 개발하는 드라이브나 토크 등이 와플 플랫폼에 있는 앱을 사용한다. 이런것도 고려하면 이슈가 굉장히 많다.

 

3. 본부 와플 플랫폼 CI/CD를 맡았다.

별도로 관리하던 협업툴 프로젝트와 달리 현재 SPC 프로젝트는 와플 플랫폼에 올라가 있고 긴급한 프로젝트를 진행하고있는 우리팀의 특성상 우리팀이 가장 이미지 배포를 많이 할 수 밖에 없는데다가, 그때마다 부탁할 수 없기 때문에 자발적으로 뺐어왔다. 처음 러닝커브쯤이야 감수할 만 하다. 지금 생각하면 이게 제일 잘한 일인거 같다. 야근도 밥먹듯이 하는데 그때마다 다른팀에게 부탁할거 생각하면 끔찍하다.

 

4. 환경이 변동됨에 따라 어떤 이슈가 발생할 수 있는지 철저하게 체크했다.

협업툴 프로젝트는 자체 이미지이기 때문에 고려가 필요 없었고, 본부 인력 리소스상 QA도 우리팀에서 자체적으로 진행했다.

하지만 와플 플랫폼에 올라갔기 때문에, QA, 스테이징 환경, 운영환경에 따라 이슈가 발생할 가능성이 있는 부분을 철저하게 관리했다. 본부 CI/CD 가져온 이후로 파일 hotfix없애버리고 철저하게 이미지로 관리하도록 변경했다.

 

5. 기획 아키텍처 체크

기획이란 단어아 아키텍처라는 말을 붙이는게 과하다는 생각을 하는 사람도 있을 것이다.

하지만 기획이 개발에 얼마나 큰 영향을 끼치는지를 협업툴 프로젝트하면서 깨달았다.

8월 26일에 시작해서 12월 13일에 운영 오픈하는.. 심지어 웹/모바일 다 개발해야하는 진짜 말도 안되는 프로젝트였기 때문에 사소한 것도 놓칠 수 없었다.

 

어떤 프로젝트든 VOC가 없는 프로젝트는 존재하지 않는다. 아무리 처음 협의할 때 이대로 fix하겠다고 협상하고 장미빛을 그려도 막상 사람의 욕심은 끝이 없기 때문에 그대로 되지 않는다. 앞으로 발생 가능성있는 모든 고객의 요구사항을 예측하고, 그거에 대응가능한 SOLID 패턴을 DB나 백엔드뿐만 아닌 기획과 프론트에도 적용하는게 정말 중요하다고 생각한다.

 

그래서 처음 프로젝트 시작할 때 기획방에 PM, UX, 실장까지 다 모아서 SPC 기획방을 개설했다 .

기획 하나 때문에 하던 개발했던 코드의 구조를 갈아엎는 대공사를 할 가능성이 없도록 철저하게 검증하고 토론했다.

기획하는 사람들은 그런 일이 발생하는 것에 대한 이해를 못하기 때문이다. 그래서 개발의 입장에서 이해가도록 충분하게 의사소통이 필요하다. 기획 문서 발행하는 주면 일주일에 최소 10시간은 썼다. 사실 PM이 해야하는데 티맥스가 서비스하는 회사가 아니기에 PM은 명목상으로 있는거고 내가 PM 역할을 수행했다.

 

양재에 있는 SPC 고객사에 방문해서 IE지원에 대한 것도 불가능하다고 협의했다. SPC에 들어가는 다른 모든 앱은 IE도 지원한다. 영업은 IE도 지원가능하다고 했었기에 내가 욕을 먹었다. 이런것도 기술에 치명적이다. IE는 mobx4 버전을 사용해야하지만, 우리가 개발할 구독형 솔루션에 mobx4를 적용할 수 없기 때문에 용기를 냈다. 다행이 고객사측에서 양해를 해주어서 IE는 지원하지 않게 되었다.

 

나에 대한 피드백

아무리 생각해도 최선을 다했다고 생각한다. 주말에 공부를 더 했어야하는데라는 아쉬움은 있지만 일에서는 없다. 우리 본부에 나보다 더 열심히 일한 사람이 있을까? 진심으로 궁금하다. 근무 시간으로 따지든 성과든 뭘로 따지든 퍼포먼스야 말할것도 없다. 물론 교수님 면담은 많이 못하긴 했다. 그렇다해도 VOC가 있어 기획도 바뀌고, 일정이 빠듯한 우리팀이 전체 12개 팀중에 이슈 숫자가 제일 적다. 실장님한테 프로젝트 끝나고 한번 물어봐야겠다.

 

너무 피곤하다. 나중에 마저 정리해야겠다ㅜ