차봇에서의 B2C 회고

TL;DR

• 배운점

  • Bastion, Replication
  • MSA를 어떻게 해야 할지
  • TDD가 무엇인지

• 아쉬운점

  • 해도해도 바뀌지 않는 회사의 개발 업무 프로세스
    • 실무자 의견 반영이 안되는 프로젝트 기간
    • 프로젝트마다 바뀌는 Team
    • 뭘보고 개발해야할지 모르겠다
    • 의도는 알겠지만 의미없는 회의들
  • 무턱대고 Micro Service Arcitecture를 하자고 해서 서비스를 분리 한것
  • 서비스 기획단계에서 좀더 커뮤니케이션을 하지 않은 것

• 다음부턴

  • 서비스 개발자는 서비스를 이해하려는 노력을 끊임없이 노력해야함.
  • 도메인 전문가와 이야기를 많이 해보자

---

회고

회사에 와서 4번째 프로젝트로 B2C Mobile Application 프로젝트에 참여 하게되었고, 앱런칭을 앞둔 시점에서 그동안 해왔던 프로젝트들을 회고해야겠다는 생각이 들어 글을쓰게 되었다.

1. 프로젝트의 시작

작년 말 부터 B2C프로젝트가 시작된다는 얘기가 들려왔고 1월에 COO님이 합류 하시면서 전체적인 B2C의 IR자료를 보여주시면서 설명을 해 주셨다. 여기서 드는 생각은 두가지였다.

• 우리 인원으로 이걸 7월까지 만든다고? 개발자 50명은 있어야 할거같은데?
• 컨셉은 알겠는데 그래서 뭘 만들자는 거지?

이 두 생각을 하게된건 정말 IR자료가 아이디어만 있었기 때문에 도저히 기간안에 이 IR자료를 구체화 하기 힘들거라고 생각이 들었다. 그래서 COO님께는 이건 안될거 같다고 말씀을 드렸었다.
( 여기서 내 잘못이 있는데 이걸 듣고 7월까지 구체화 해야할 범위가 어디까지인지 먼저 여쭤보고 판단을 했어야했는데 IR자료를 기반으로 출시해야할 어플리케이션을 상상해서 안된다고 말씀드렸던건 잘못 된점이란걸 깨달았다. )

어찌저찌 1월엔 삼성카드쪽에 붙어 한달이 후딱 가게되었고 2월부터 B2C에 참여를 하게되었다. 처음에 Front쪽으로 개발인원이 없었고 IR자료만 보고 쓸수있는 데이터를 달라고 하셔서 당황… 뭘 만들지도 모르는 상황에서 어떤데이터를 달라고 하는건지 이해를 할 수 없었다.

2. PM님의 합류

3월이 되었고 PM으로 실장님이 입사하시고 팀이 조금씩 꾸려지고 있는 상황에서 개발팀장님께서는 4월 까진 팀빌딩 (적어도 3년차 이상…)과 기획이 fix되면 7월말까지 가능할 거라고 통보를 하셨다고 말씀 해 주셨고 4월까지 기획이 되는줄로만 알고있었다.
그렇게 4월이 되어서 기획이 다되었다고 받아본건 figma에 디자인 시안뿐이었고 story borad는 찾아볼 수 없었고 글자 하나 보이지 않는 figma를 보며 물어물어 디비 설계를 시작 했다. 그와중에 개발팀장님은 개인사정으로 나가버리셨다.

3. 팀 빌딩

5월이 되어서야 CTO님, Infra팀장님, Front팀장님(프리랜서), 백엔드 신입 1명, 프론트 신입 1명, 주니어 1명 으로된 팀이 꾸려 졌다. 분명 시니어를 뽑아서 간다고 했는데… 그나마 인프라팀장님이 AWS에서 네트워크와 RDS, EC2등 제대로 인프라 구성을 해 주셔서 인프라 쪽은 문제 될 일들이 없었다.

프로젝트가 시작되었고 매주 있는 Sprint회의는 정말 의미가 없게 느껴졌다. 각 팀이 뭘하는지에대해 리뷰하는 회의에서 마케팅팀은 마케팅용어를 써가며 뭘 하는진 모르겠지만 어떤 무언갈 하고있었고 프로덕트팀에선 안에들어갈 컨텐츠 제작에 대해 뭔갈 하고있다라는걸 알려 주었다. 개발팀에서도 뭘 하고있다고 말하는데 이걸 이해할까 라는 의문도 들었고 이게 반복이되니 정말 회의시간에 집중도 안되었다.

그렇게 5월에 Figma Driven Design을 통해 설계를 하고 7월 한달 분노의 질주모드 라는 이상한 분노 유발 현수막이 걸리면서 야근을 하게 되었고 막바지에는 이미지에대한 해석차이로 결국 IR 자료와는 전혀 다른 앱이 탄생을 하게 되었다.

---

마무리 정리

당연한 결과라고 생각이 된다. 전체적인 프로젝트 기간을 보면 1월 말부터 7월말까지 반년이란 시간이 주어졌지만 결국 개발팀에게 주어진 시간은 짧게보면 두달 길게봐야 세달이므로 이 결과는 개발팀의 최선이라 생각한다.

아쉬운점

1. 개발

• MSA를 제대로 알아보지 않고 Micro Service를 생각없이 나누어 개발을 시작 했는데 처음엔 그냥 모놀리식 개발로 해야하는게 맞는것 같다… 2명으로 하기엔 너무 벅찬 일정
• TDD를 해보지 못한점. 처음 기획이 나왔을때 TDD를 할 수 있는 기회가 있었지만 내가 가서 하지 못한게 아쉽다. 기획을 보고 어떤 API필요한지 정리가 되기만 했더라면, 그래서 Test코드를 먼저 짜고 개발을 시작했더라면 API 수정하는데 있어서 두려움은 훨씬 줄 수 있었을텐데 라는 아쉬움이 크다.

2. 회사
회사에 들어오고 4번재 프로젝트지만 항상 프로젝트를 시작하면 같은 패턴 위에서 어떤개발이 들어갈지 대략적으로 알려주면서 기간도 항상 같이 정해져서 내려왔다. 결국 PM을 맡은 팀장님들도 못버티고 나가시고 왜 프로젝트가 기간내에 안되는지에 대한 문제정의도 없이 반복되는 문제를 겪고있는게 너무 아쉽다. 매 프로젝트가 반복 되면서 새로운 PM 밑에서 새로운 팀원들과 새로운 PM님의 업무방식으로 팀이 뭔가 맞춰갈 시간이 없었다.
이건 B2C 프로젝트 회고이니 적을말은 많지만 이정도만 해야겠다.

배운점

이번 프로젝트는 내가 여기서 하는 마지막 프로젝트라고 생각하고 임한 프로젝트 이기에 단순 매니저 실무자의 입장에서 개발을 진행하기 보다는 내가 팀장급 또는 PM과 같은 리더라면 어떻게 문제를 해결해 나갔을지에 대해 매 순간 생각하면서 개발을해 나갔었다. 그리고 많은것을 느낄 수 있었다.

🧐 서비스 개발
서비스를 개발해 나가는데 개발보다 어떤 서비스를 만드는건지에대한 이해도가 더 중요하다고 느꼈다. 이 이해도를 가지기 위해서는 기획자와 더 소통을 많이 해야하고 커뮤니케이션 스킬이 굉장히 중요하단걸 깨달았다. 기획과 디자인 개발의 일은 다르지만 우리가 만드는건 같은 무언가를 만드는거란걸 항상 기억하자.

🛠 개발
어디서 이런말을 들은적이 있다. 호기심만 너무 강한 개발자는 힘들다.
나는 이말이 새로운 기술에대한 말인것 같다고 생각이 들었다. 새로운 기술? 도구? 좋다 그런데 그것에만 너무 빠져있다보면 기본을 놓지기 쉽다는 생각을 하게 되었다. 다시한번 상기하자 우리는 서비스를 만드는거지 기술을 개발하는게 아니다. ( 물론 기술도 중요하다 )
기술적인것들은 따로 정리 예정!

글을 다 써놓고보니 진짜 글 못쓴다...이제 배운거 머리속에 저장하지말고 블로그를 통해 글쓰는법도 익히고 배운걸 티도좀 내야겠다...😎