대망의 부트캠프의 꽃.... 메인 프로젝트
팀원 정하기
스택오버플로우 를 만드는 pre 프로젝트를 끝내고 메인프로젝트에 입성했다.
이번주는 팀원 모집? 그리고 프로젝트를 어떤 주제로 어떤 기술들을 사용해서 구현할건지 거의 기획 단계였다.
팀원 모집 첫날에 Zep에서 각 영역안에서 어떤 주제로 어떤기술들을 사용해서 프로젝트를 구현할건지 사람들끼리 모여서 토론하고 팀원을 모집하는 방식인데 전날부터 이렇게 팀원을 구성한다고 했을때 느낌이 안좋았다. 그래서 pre프로젝트를 같이했던 팀원분들에게 같이해보는게 어떻냐고 여쭤봤고 우여 곡절 끝에? 프론트에서 3명은 프리때 같이 했던 멤버로 구성이 되었고 백엔드에서는 zep 에서 팀원을 구하지 못하고 계신 정민님과 태영님을 만나게 되었고 한분은 랜덤으로 들어오셨다.
기획단계
사실 28일에 처음 팀을 정하고 29 일 부터는 기획을해서 주말을 끼고 7월3일부터는 코딩을 들어갈줄 알았다. 하지만 코딩을하려고 하면 어디선가 기획에서 문제가 발생해 수정하는 상황이 계속 발생했다. 일단 우리팀의 프로젝트 방향성은
1. 반려동물 물품 중고 거래 (Competnion 컴펫니언)
반려동물 물품 중고 거래 (위치기반)
실시간 채팅
편의기능
가출한 반려동물 찾는 기능 (위치기반)
반려동물이 가출할 경우, 개가 1시간 가는 거리를 계산해서 그 반경에 있는 모든 사용자에게 알림 보내기
찾은 사람 - 주인 1대1 채팅
동네 집사 커뮤니티 기능 (위치기반)
거주지 일정 반경 안에 등록된 회원 표시, 실시간 채팅으로 소통
기술
FE
무한 스크롤
다크 모드 (부가사항)
다음맵 api
실시간 채팅
으로 기획했었다 하지만 생각보다 기술적인 어려움이있었고 무엇보다도 시간이없었다 그래서 우리팀은 의견을 조율해서 동네 반려동물 산책 메이트 구하기 게시판과 지도api를 띄워서 현재위치와 산책할 위치를 알려주는 웹사이트를 만들기로 정했다.
내용을 정리해보면
베어미니멈
/지훈
(상) 회원가입 / 로그인 / 로그아웃 - jwt 이메일 인증
(상) 마이페이지 반려견 정보 등록, 사용자 주소 등록 - 다음맵 api 활용한 유저의 위치 좌표 정보 추출
/예훈
(상) 산책 공고 상세페이지 - Read, Delete + 지도 api 활용
(상) 메인 랜딩페이지 - 스크롤에 따른 CSS 애니메이션, 디자인
/영탁
(상) 산책 공고 상세페이지 작성 페이지 Create, Update - 지도 api 본인주소 반경 내에서만 장소선택 가능
(중상) 산책 공고 리스트 페이지 - 무한스크롤, 지도 api 마커 활용
/추가구현
(상) 채팅창 - 중고물품 판매자와 구매 희망자 간의 1:1 실시간 채팅 기능
헤더 Header
푸터 Footer
어드밴스드 (시간이 된다면 추가구현)
동네기반(반경기반) 애견용품 중고거래
- 거래 체결 후 거래 상대방 거래 만족도 리뷰,
- 중고물품 북마크 기능,
(상) 가출한 반려견 찾기 - 가출한 강아지 *km 반경내의 유저에게 강아지를 찾는 전단 알림 발송,
회원가입 이메일인증, 비밀번호 찾기,
동네 애견 커뮤니티 - CRUD 게시판,
(상) 다크모드
처음 기획했던거에서 완전히 뒤집어서 새로운 목표치를 만들어냈고 이제 부터 코딩을 들어가야겠다는 찰나에 각자 맡은 영역을 정리를하던중 수많은 문제점들이 발생했다. 예를들어 산책을 갈때 강아지 한마리만 키우는게아니라 여러마리의 강아지를 키우면 강아지는 누굴데리고 갈껀지? 본인주소라는게 애매해서 3km의 반경을 정했는데 산책하는사람 3km미터 반경, 산책하는사람 3km 반경 어떻게 겹치는게 어떻게 시스템을 구축할건지... 악의적으로 게시판의 글을 쓰는사람들을 제제하기위한 시스템적으로 어떻게 구축할건지 등등 많은 문제들이 발생했다. 그래서 거의 코딩하기로 마음먹은 1주일간은 거의 무한회의로 보낸것 같다.
갈등
사실 회의를 할때 월요일부터시작해서 거의 목요일? 금요일까지 회의를 하는데 화가 사실 조금 나기도 했다. 회의라는게 목표를 딱정해두고 그 안건에대해서 어떻게 처리할건지 논의를 했으면 좋겠는데 주먹구구식으로 한가지 제안을 하면 꼬리물기식으로 그럼 이거는 어떻게 대처할 것인가? 이 경우에는 무슨값을 줄건가? 식으로 계속 진행이되서 이제 마음속으로 혼자만의 답답함? 조급함이 많이 느껴졌다. 왜냐하면 주어진 시간은 많이 없는데 회의를 하면 할수록 신경써야할 기능들이 2~3개가 계속 추가되고 작업량이 더욱 많아져 갔기 때문이다.
이렇게 되는 이유도 팀원중 한분은 여러가지 기능들을 사용하고 싶으신것 같았고 한분은 정해진 기능들 딱 정해놓고 결점없는 사이트를 구축하고 싶으신것 같았다 ( 유효성 검사를 면밀하게?) 그래서 의견을 전부 종합하다보니 끝도 없었던것 같았다. 그래서 나는 현재 말했던 기능들을 먼저 구현하고 (유효성 검사까지 어느정도 마치고) 어드밴스 기능들을 추가하자고 의견을 제시했다.
사실 팀원 두분의 말씀이 다맞았다. 나도 여러가지 스택들 여러가지 기능들을 사용해보고 싶긴하나 시간이 너무 짧았고 유효성검사를 하면서 촘촘한 구성을 하고싶긴하나 그러면 기능들을 구현하지도 못해서 이도저도 아닌 사이트를 만들 것 만 같았다. 사실 중간에 악의적인 사용자를 제한하려고 하루에 글을 3가지 정도만 제한하자고 했을때는 이해가 정말 안되었다.
만약 여러마리의 강아지를 키우는 사람이 계획적인 사람이라 강아지를 시간순으로 같이 산책할수도 있는데 그렇게 제한해버리면 소수의 악의적인 사용자 때문에 웹사이트를 이용하는 고객이 피해를 입는다는것은 내 상식선에서는 이해가 전혀 되지를 않았다.
무슨 말씀을 하는건지는 알고있으나 어떤 웹사이트에서 글을 제한을 두는 사이트는 본적이 없었고 이해가 안되었었다. 그래서 보통 그런기능들은 사이트에서 따로 구축한 신고 하기 기능들을 이용해 첫번째는 AI를 통해서 신고누적순으로 제제가 들어가고 그런다음 운영진에서 악의적인 사용자를 패널티를 주자고 했었고 사실 이런 것 들 때문에 작업량이 추가가되고 문제가 계속 발생된다고 생각했었다.
회의가 끝도없이 진행될것 같아서 나는 팀원들에게 이렇게 세세하게 하나하나 생각 하는것은 되게 좋은 토의인것 같다 하지만 우리는 약 2주라는 특수한 상황이고 시간안에 정해진 기능들을 완성시키고 통합테스트를 해야하는데 이렇게 진행하다가는 끝도없을것 같아서 정해진 기능 먼저 완성하고 그 뒤에 생각하자고 의견을 제시했고 그 의견이 받아들여져서 어드밴스로 빼기로했다.
멘토님 말씀
1. 매주 회고를 했으면 좋겠다.
팀회고 1주일에 한번.
개인입장에서는 매일해도됨.
애자일, 스프린트.
지난 1주 동안에 어떤걸 목표로 했는데 잘했는지 못했는지, 앞으로 개선사항 있는지.
생산성을 높이기 위한 피드백, 상처주지 않고 상처받지 않기.
까먹지 않기 위해서 포트폴리오 기록용으로도 좋음!
2. 코드 리뷰
신입들을 줄세워보면 사실 비슷비슷하다
기술스택, 포트폴리오 개수를 채우는것도 중요하지만 그것보다 중요한건,
실력이 판가름 나는건 ‘코드’ - 코드가 깔끔한지, 이해하기 쉬운지, 단단한지 중요해
당신 코드 못알아보겠다, cnt 가 뭐에요? 오류가 있는지 등 팀원끼리의 코드리뷰.
코드 리뷰를 받고. 코드 리뷰 잘하는것도 실력이야.
코드 자체를 잘 작성하는 방법, 네이밍 잘하는거, if 잘하는데, 컴포넌트 잘분리하는거
3. 완성된 작품을 내보냈으면 좋겠다. (완성도)
일정이 있고, 만들어야하는 제품이 있고, 다같이 일하는 환경.
마지막 1주는 추가기능 개발없이 우리딴에는 완성됐다고 하는걸 테스트하는 기간으로 가져야되.
리팩토링. 테스트, 내가 유저라고 생각하고 다양한 케이스를 테스트해봐.
javascript 인젝션 테스트도 해보고.
2주의 기능개발은 누구나 다 해본 경험이고 경쟁력 가지기 어려워.
근데 완벽하게 완성된 제품이라고 생각하고 내보내는 경험은 누구나 해보기 힘든 경험이고 썰풀게 많아.
경쟁력을 가질 수 있어.
좋은 회사일수록 QA 기간이 엄청 빡세고 힘들고 길어
에러 핸들링을 잘해야 나중에 테스트할때도 문제가 어디인지 빠르게 찾을 수 있어.
유저단의 밸리데이션 체크, 시스템적으로 문제가 생겼을때 (예를들면 response 에서 백에서의 에러) 에러 핸들링 등
마지막 문서화를 공유하는 경험.
느낀점
멘토님이 우리의 문제를 정확하게 짚어 주셨다. 현재 주어진시간을 생각해보면 되게 짧고 완성도 있는 작품을 내보낼수는 없다. 하지만 우리가 주어진 특수한 상황에서 제일 중요한것은 협업을 해보는거다. 그리고 이렇게 멘토를 배정해줘서 협업을 할수있는 상황에서 최대한 뽑아먹을 것을 뽑아먹어라. 라고 말씀해주셨다. 그리고 선택지를 2가지 인것 같은데 ( 여러가지 기능들을 사용해보기, 기능을 제한을 두고 사용자입장에서 완벽한 시스템구축하기) 이것도 정하기 나름이라고 하셨다. 팀원 중에서는 여러가지 기능을 사용하고싶은 사람, 기능들을 최소화하고 완성도 있게 내보내고 싶은 사람 둘다 있을때는 이럴때는 의견을 조율해서 팀이 원하는 방향을 가야한다.
당연히 의견조율과정에서 의견이 서로 대립되고 안맞을 수는 있다고 하셨다. 지금 우리의 상황이 그랬었다. 말씀을 듣고 많은 것을 느꼈다. 우리 팀은 현재 2가지의 의견이 존재했었고 우리는 기능에 초점을 맞출것인지 여러가지 기능들을 만들어볼건지 확실하게 얘기를 안하고 있었다.
그래서 멘토링을 듣고나서 이것도 경험의 일부라고 생각하고 의견이 생겼을때 우리가 현재 목표를 무엇으로 두고있는지? 어떤것에 중점을 둘건지 등을 고려해보고 기획을 해야겠다고 느꼈다. 다행이 우리팀은 서로 예의를 지키며 현재상황에서 무엇이 우리팀에 최선인가를 먼저 중점을 두고 목표를 세웠고 이제 진짜 7월 3일부터는 개발을 시작할 예정인데 개발을 하면서도 많은 추가사항들이 나올 것으로 예상되지만 팀원들과 잘 소통해서 해결해 나아갈 생각이다.
문제를 직면했을때 마인드 셋
문제를 직면할때 단순함과 명확함이 중요하다.
복잡하고 어려운문제는 단순하고 명확하게 .
