첫번째 팀프로젝트를 마치며
About Team
[팀구성]
팀명 : rgb.
Product Manager: 윤해찬(B)
Project Manager: 이수빈(F)
Teammates: 탁호진(B), 이원준(F), 문유현(F), 김수정(F), 이경진(F)
[프로젝트 기간]
2023.05.01 ~ 2023.05.12 (총 2주)
[적용 기술 및 협업 툴]
⚙️ FrontEnd
JavaScript, React, HTML, CSS
⚙️ Collaboration Tool
Github, Trello, Figma, Notion, Slack, Postman
[프로젝트 진행 방식]
매일 오전 stand-up meeting에서 trello 툴로 작업 진행상황 및 해결 방안 공유
매주 월요일 sprint 회의를 통해 프로젝트 전반에 걸친 피드백 진행
기획 초반 노션으로 기획의도, 전체적인 컨벤션 정리
피그마 툴로 레이아웃을 미리 기획/구상 하여 프로젝트 진행
About Product
[Intro]
MZ세대(25~40세)를 타겟으로 매달 초청된 아티스트의 그림과 굿즈를 로테이션으로 판매하는 사이트 개발했다.
요즘 세대의 예술 작품에 대한 많은 수요를 배경으로 제품 이미지 중심의 이솝 사이트 레이아웃을 참조하여 rgb 만의
큐레이팅 아트 사이트를 기획했다. rgb 는 매달 새로운 아티스트를 선정하여 작품과 굿즈를 한정판으로 판매하며, 그림에 대한 희소성을 부여하고 rgb 의 소비자들은 매달 새로운 아티스트들의 작품과 철학을 즐길 수 있도록 구현하였다.
[end-user]
자신만의 분명한 취향을 가진 MZ세대를 타겟으로 하여 단순한 소비를 넘어 소장품을 수집하는 것에 관심이 많고, 희소성을 중점적으로 생각하는 소비자층을 타겟으로 했다.
그림이라는 부분을 소비자의 형태로 분리했을때 크게 두가지 분류로 나타났다. 첫번째는 기존의 X세대와 MZ세대로 이루어져있는 기본 유형이다. 이들은 특별히 그림이라는 것을 따로 소비하지는 않지만, 교양이라는 타이틀 아래 유명한 그림들만 아는 유형이다. 두번째는 주로 MZ세대로 이루어진 흔히 말하는 힙스터들이다. 이들은 자신의 개성을 표출하는것을 좋아하며, 이들의 소비습관 또한 그들의 개성을 나타내고 있다. 우리의 End-User는 두번째 유형이다. 이 유형은 그림에 대한 소비관점을 좀 더 자기 개성을 표출하려는 욕구가 강했다. 그들이 원하는 것은 흔하고 유명한 그림보다는 희소성과 수집의 가치가 있는 작품들이다.
자신의 개성과 취미 활동에 투자하기를 아끼지 않는 이들은 가성비보다는 가치에 더 집중하는 타입들이다.
또한 후자의 유형을 타켓으로 하는 서비스는 찾아보기 어려웠다.
따라서 그들이 추구하는 가치에 부합하는 서비스를 만들면 많은 잠재고객층을 확보할 수 있는 기회라고 생각했다.
[Product purpose]
그래서 우선 첫번째 유형의 고객들의 사이트들을 먼저 분석해봤다. 이들의 가장 큰 단점은 다른 이커머셜과의 차별성이 없는 획일화된 레이아웃이었다. 그림을 판매한다는 특수성이 전혀 고려되지 않은 레이아웃은 불특정 다수를 겨냥하여 기존 유명 아티스트들에게 라이센스를 받아와서 다시 파는 구조이기 때문이다. 그리고 그림 자체로 얻는 수입보다는 액자를 끼워파는 형식으로 부수적인 수익을 올리는 방식이 가장 흔하게 나타났다. 이러한 점 때문에 오히려 한번에 너무 많은 정보들을 보여주려고 해서 그림에 집중하기 어려운 구조였다.
우리팀이 가장 중점적으로 생각한 부분은 희소성과 그림 자체에 대한 집중도를 높이는 것이었다. 소장과 수집에 관심이 많은 소비자층을 타겟으로 하였기 때문이다. 그림 자체에 대한 희소성이 떨어져 소비자로 하여금 특정 사이트를 이용해야 하는 이유가 불분명했다. 이러한 사이트와 프로덕트는 얼마든지 대체가 가능하다는 점에서 경쟁력이 떨어졌다. 이러한 특징들을 바탕으로 타사이트들과 차별화되는 서비스를 제공하여 우리 사이트만의 경쟁력을 갖추고자 했다. 그 대안으로 한달에 딱 한 명의 작가만을 집중 조명하여 그 작가의 작품을 한정 판매하는 방식을 선택했다. 이러한 방식은 작품의 희소성과 함께 한정판매라는 특수성을 서비스에 부여했다. 이를 통해 소비자는 우리 서비스를 이용함으로써 프라이빗하고 특별한 경험을 한다고 느낄 수 있다.
그리고 전체적으로 불필요한 정보들을 최소화하고 사용자의 동작을 간소화하여 작품 구매까지 이어지는 플로우를 단순화하였다. 그래그래서 고객들이 그림에 더 집중하고 쉽게 구매로 이어질 수 있도록 했다.
[Product Detail]
그림에 포커스를 맞춘 사이트 디자인
우리팀에서 레이아웃을 참고했던 사이트는 이솝이었다.
이솝은 제품 중심의 레이아웃 구성이 특징적이다.
불필요한 디자인 요소들이나 과정들을 전부 배제해 제품 자체에 최대한 집중할 수 있도록 하였다.
특히 로그인 및 회원가입 단계에서 정보를 최소한으로 요구하여 구매로 이어지는 장벽을 낮춘점이 우리의 전략과 결이 맞았다.
또한 제품 상세 페이지에서 불필요한 정보들을 최대한 배제하고 제품 본연에 매력을 보여줄 수 있도록 구성한 점이 참고하기 좋았다.
이러한 이솝의 장점들을 참고하여 우리팀은 소비자가 그림에 집중할수 있게 전반적인 디자인 레이아웃을 잡았다.
장바구니 디자인과 제품 상세 페이지에 이르기까지, 심플한 디자인과 최소한의 정보 노출을 중요한 포인트로 잡고 최대한 우리 사이트만의 고유한 색깔을 녹여낼수 있도록 집중했다.
유저의 간단한 회원가입 및 로그인
유저는 회원가입 시 이메일, 이름, 비밀번호 등의 간단한 정보들로 가입을 진행할수 있다.
이는 회원가입 단계에서 사용자들이 일탈률이 높기 때문에 이러한 문제를 예방하고자 최소한의 정보만들 기입하도록 하였다.
추후 상품을 구매하는 단계에서 주소 및 필수 입력 사항을 적을 수 있도록 만들어
사용자가 구매까지 이어지는 과정에서 생기는 부담을 줄이고자하였다.
회원 구매 제도
작품을 구매하기 전 단계에서는 누구나 작품들을 볼 수 있지만 구매를 하려면 회원가입을 해야한다.
이러한 전략은 우리가 추구하는 희소성과 차별성을 위해서이다.
회원가입을 하면 제공받는 여러 혜택들을 통해 사용자는 프라이빗한 살롱에 일원이 되어 특혜를 누리는 기분을 느낄 수 있다.소수의 사람들만이 알고 누리는 작가의 작품이라는 컨셉으로 소장욕구와 브랜드 충성도를 자극한다.
결제 완료 후 마지막 단계에서 받는 in-voice는 이러한 효과를 극대화 하는 하나의 장치이다.
작품 구매 가능 수량 표기
우리 서비스의 특징인 희소성에 맞추어 작품들은 재고량이 정해져있다.
제품의 상세 페이지에서 구매가능한 수량을 바로 확인할 수 있도록 했다.
이를 통해 서비스를 이용하는 고객들에게 우리 사이트에서 판매되는 작품들의 희소성을 느낄 수 있도록 했다.
[User Flow]
메인 둘러보기 → 상품리스트/ 상세페이지 둘러보기 → 원하는 상품 선택 → 장바구니 담기 버튼 누름 → 로그인 창 뜸
→ 로그인 : 회원일 경우
⇒ 장바구니 → 결제하기 → 결제완료 → 인보이스 페이지에서 내역 확인
→ 로그인 : 비회원의 경우
⇒ 로그인창에서 회원가입 하기 버튼 클릭 → 회원가입창 → 회원가입 후 자동 로그인 → 원하는 상품 담기 → 주문/결제하기 →
인보이스 페이지에서 내역 확인
메인페이지에서 바로 로그인
⇒ 상단 네비게이션바에서 로그인 버튼 클릭
메인페이지에서 회원가입 ⇒ 상단 네비게이션바에서 로그인 버튼 클릭 → 로그인창 하단의 회원가입 버튼 클릭
Project Process
[첫 기획 회의]
팀 결성 후 첫 회의 진행
팀원들 각자의 아이디어를 조합하여 온라인 큐레이팅 서비스를 만들기로 결정
각자 구현하고 싶은 기능과 구현 할 수 있는 기능들을 정리하는 시간을 가짐
[두번째 기획 회의]
각자 정리해온 자료들을 바탕으로 전체 프로덕트의 기능들을 유저 플로우 기반으로 문서화
필요로하는 모든 페이지 및 기능들을 노션으로 정리
노션으로 문서화한 기능서를 바탕으로 피그마 작업 진행 / 백엔드도 함께 참여하여 상세한 기능 정리
[첫 스프린트 및 리뷰]
피그마 작업물과 노션에 정리한 기능서를 바탕으로 첫 스프린트 회의 진행
회의에서 2주라는 시간동안 완성도를 가장 높일 수 있는 방법에 대해 고민
현실적으로 모든 기능들을 완벽하게 구현하기에는 어렵다고 판단하여 몇가지 기능들을 추가 구현 사항으로 변경
추후 팀프로젝트가 끝난 후 다시 의논하여 추가 개발 진행 예정
[레이아웃 작업 시작]
회의전 미리 만들어둔 피그마 작업물을 기반으로 각자 할당받은 페이지 레이아웃 작업 진행
프론트엔드 팀원 5명이 기능별로 페이지를 나누어서 작업 진행
[레이아웃 완성 및 기능 개발 시작]
레이아웃 완성과 함께 팀원 모두가 기능 개발 시작
[2차 스프린트 회의]
일주일간의 프로젝트 진행 방식에 대한 회고 및 개선사항 의논
기능 개발속도가 더디다는 의견이 있었으나 팀원들 모두 밤까지 작업하는 시간을 늘려 프로젝트 일정에 맞추어 작업 진행
[기능 개발 중반 API연결 시작]
상세한 기능이 모두 구현 되기 전에 서버 통신이 필요한 부분부터 우선적으로 백엔드와 협업 시작
데이터를 가져와서 화면에 구성해야 하는 파트부터 순차적으로 진행
[기능 개발 후반 API연결 및 오류 해결]
기능 개발 후반부부터는 주로 API 연결과 관련된 이슈들이 발생
데이터 통신 과정에서 생기는 오류들을 백엔드와 협업하여 해결
프론트엔드의 경우 팀원들의 코드를 합치는 과정에서 생기는 오류들을 팀원들이 함께 의논하여 해결
[기능 개발 완료 및 유저 플로우에 맞추어 점검]
최종 발표를 앞두고 팀원들과 함께 유저 플로우에 맞춰서 테스트 진행
그 과정에서 찾아낸 오류들을 수정하며 프로덕트의 완성도를 높임
[프로젝트 최종 점검 및 발표]
발표 전날 기능 개발 및 오류 수정을 모두 끝마침
프로젝트 진행과정에서 틈틈이 작성했던 문서들을 모아서 발표 자료 준비
프로젝트 발표 전 마지막으로 팀원들과 전체 내용 점검
[프로젝트 종료]
프로덕트 완성 후 프로젝트 종료 전 팀원들 모두와 프로젝트 회고 진행
좋았던 점과 아쉬웠던 점들을 얘기하고 추후 유지 보수 및 추가 구현 사항에 대해 의논
AWS를 이용해 서비스 배포
담당했던 기능
1. 회원가입
What : 회원가입시 정보 기입 최소화 - 받는정보 : 성, 이름, 이메일, 비밀번호
Why : 사용자의 회원가입 이탈율을 낮춤
What : 유효성 검사 조건 불충족 혹은 잘못된 입력 정보의 경우, 실시간으로 입력창 하단에 안내 메세지 출력
Why : 사용자의 실수를 예측하고 사용자가 바로 그 사실을 알 수 있도록 함
How : 정규표현식과 조건부 랜더링을 활용
What : 필수 입력 사항 미입력시 가입하기 버튼 비활성화
Why : 사용자의 실수를 예측하고 사용자가 바로 그 사실을 알 수 있도록 함
조건 불충족 시 버튼을 누르지 않고 확인할 수 있어 사용자의 불필요한 확인 동작을 간소화
How : input value 값을 저장하는 배열을 만들어 관리하고 value 값의 유무에 따라 조건부 랜더링
What : 비밀번호 확인란 입력내용 보기 버튼
Why : 사용자의 실수를 사용자가 예방하는 차원
What : 체크박스 전체 동의버튼 (약관 동의 필수 항목 및 선택항목)
Why : 사용자의 편의성 제공
How : filter() forEach() 활용하여 배열로 체크박스 상태 관리
What : 회원가입 완료시 팝업 안내창
Why : 사용자가 선택한 행위에 대해 성공적으로 작업이 완료된 사실을 즉각적으로 알 수 있도록 함
How : localStorage.getItem()으로 토큰을 받아오고 토큰 유무에 따라 조건부 랜더링
What : 회원 가입 안내창 실행 후 화면 클릭 시 자동 로그인
Why : 다시 로그인을 진행해야하는 번거로움을 제거해 사용자의 편의성을 높임
How : 화면을 클릭하면 안내창 컴포넌트가 사라지도록 조건부 랜더링
2. 로그인
What : 로그인 값 - 이메일 주소 및 비밀번호
유효하지 않은 정보일 경우 입력창 하단에 알림 메세지 출력
Why : 사용자의 실수를 바로 잡을 수 있도록 안내
How : 유효하지 않은 정보일 경우 토큰이 발급되지 않는 것을 이용하여 토큰 유무로 조건부 렌더링
What : 네비게이션 기능 중 로그인이 필요한 동작을 할 경우 자동으로 로그인 창을 띄우는 기능
회원이 아닐 경우 회원가입으로 이어질 수 있는 플로우 / 모달 형식
Why : 사용자가 바로 로그인이 가능하도록 하여 사용자의 편의성을 높이고
로그인 또는 회원가입 요구 시 발생하는 사용자의 이탈을 예방
How : 버튼을 클릭할 경우 토큰 유무를 판별하여 조건부 렌더링
What : 제품 상세페이지에서 비회원이 구매하기를 누를 경우 로그인 창 띄우는 기능
Why : 페이지 이동없이 로그인 창을 띄워 로그인 또는 회원가입을 할 수 있도록하고
로그인이 완료되면 이전에 작업하던 동작을 이어서 할 수 있도록함으로써
사용자가 불필요하게 페이지를 이동하는 번거로움을 해소
How : 버튼을 클릭할 경우 토큰 유무를 판별하여 조건부 렌더링
3. 네비게이션 바
What : 화면 상단에 고정
Why : 사용자의 접근성을 높임
How : Routes밖에 nav component를 Routing하여 페이지를 이동해도 계속 나타나도록 구현
What : 마이포인트를 바로 확인할 수 있도록 네비게이션에 현재 보유포인트 출력
Why : 마이페이지로 이동하여 확인해야하는 번거로움을 없앰
How : useEffect의 의존성 배열에 point state를 넣어서 포인트에 변동이 있을 경우 랜더링되도록 구현
What : 현재 카트에 담긴 상품 수량을 바로 확인 가능하도록 구현함
Why : 사용자가 장바구니를 눌러서 수량을 확인해야하는 번거로움을 제거
How : useEffect의 의존성 배열에 product count state를 넣어서 count에 변동이 있을 경우 랜더링되도록 구현
What : 토큰 유무에 따라 로그인과 로그아웃 버튼 토글 기능
Why : 사용자가 현재 상태를 바로 알 수 있는 직관적인 구성
How : localStorage.getItem()으로 토큰을 받아오고 토큰 유무에 따라 조건부 랜더링
What : 로그인 버튼을 누르면 로그인 창에서 회원가입까지 바로 가능하도록 기능 구현
Why : 로그인과 회원가입을 한번에 진행할 수 있어 사용자의 편의성을 높임
How : 로그인 창에서 회원가입 버튼을 누르면 상위 컴포넌트인 user에서 state값이 바뀌면서
로그인 컴포넌트를 지우고 회원가입 컴포넌트로 바꾸도록 구현
4. 인보이스 페이지
주문자 정보와 주문 내역 확인 가능
보유 포인트와 사용 포인트 확인 가능
상품의 세금 포함 전 가격과 세금 포함 후 가격 확인 기능
5. 공통으로 사용되는 요소들 개발
NotFound page
사용자가 잘못된 경로로 접근할 경우 보여짐
Loading page
결제창에서 인보이스페이지로 넘어가는 동안에 로딩타임이 길어질 경우 보여짐
버튼 컴포넌트
프로덕트 내에서 사용되는 버튼을 컴포넌트로 만들어 clasName을 적용해 활용할 수 있도록 구현
버튼의 모양과 클릭할 경우 발생할 이벤트를 props로 넘겨받아 작동하도록 구현
자주 사용하는 스타일 속성값 변수화하여 파일로 관리
프로덕트 메인 컬러 변수로 만들어 variables파일로 관리
자주 사용하는 스타일 속성 mixin으로 만들어 mixin파일로 관리
Product Review
[Good Point & Bad Point]
Good Point
팀원들과 처음 만들었던 피그마 작업물과의 싱크로율은 100%
기능 구현은 추가 구현으로 변경된 사항들을 제외하면 90% 이상의 완성도를 만들었다.
필수 구현 기능들은 빠짐없이 구현했다.
Bad Point
부가적으로 구현하고 싶었던 모달창 트랜지션 효과나 세부적인 효과들은 시간 관계상 다 구현해내지 못했다.
모달창이나 페이지 위치를 나타내는 페이지 내 상단영역을 컴포넌트로 분리하여 더 효율적으로 만들 수 있었는데 그러지 못해 아쉽다. 컴포넌트 재사용에 대해 좀 더 공부해서 프로덕트 내에서 모듈화 할 수 있는 요소들을 찾아 리팩토링하고 싶다.2주라는 시간적 제한으로 인해 처음 기호기에서 하고싶었던 것들 중 몇가지를 추가구현 사항으로 변경했다.특히 유저의 정보를 수정할 수 있고 구매 이력을 볼 수있는 마이페이지 기능을 구현하고 싶었는데 결국 구현하지 못했다.
2차 프로젝트가 시작되기 전에 팀원들과 의논하여 추가구현 사항으로 빼두었던 기능들을 추가 개발해서 꼭 완성도를 높이고 싶다 .
모달창으로 로그인과 회원가입, 장바구니 기능 등을 구현하였다.
모달창의 장점인 페이지 이동없이 원하는 동작을 이어서 진행하는 점을 살리고 싶었다.
사용자가 원하는 다음동작으로 매끄럽게 이어지도록 기능 개발은 잘 되었으나
모달창을 페이지의 형태로 구성하여 모달창 안에 또 모달창이 생기는 비효율적인 구조가 되었다.
다음 프로젝트에서 다시 모달창으로 기능을 구현하게 된다면
기획 단계에서 컴포넌트화하여 좀 더 사용성있고 호율적인 작동 방식으로 만들어내고 싶다.
Project Review
[Good Point & Bad Point]
Good Point
처음 기획단계에서 소비자 분석을 바탕으로 체계적으로 계획을 하고 프로젝트를 진행했다.
프로젝트를 진행하는 동안에 프로덕트에 대한 정체성이 흔들리지 않고 원하는 목표대로 완성해 낼 수 있었다.
유저 플로우를 기반으로 필요한 모든 페이지와 기능들을 정리하여 문서화 하였다.
프로젝트를 진행하는 과정에서 그 문서들을 아주 유용하게 활용하였다.
팀원들과 논의한 내용들을 빠짐없이 노션에 기록하여 추후 팀원들간의 기억이 엇갈릴 때 확인하는 용도로도 유용했다.
레이아웃 작업 전에 컨벤션을 정해 className이나 공통적으로 사용되는 UI들의 혼동을 예방하였다.
공통으로 사용되는 컴포넌트를 미리 만들어 함게 사용하고, 메인으로 사용하는 컬러를 변수로 만들어 사용하여 작업 생산성을 높였다.
팀원들과 실시간으로 의견을 주고 받고 정해진 내용을 공유문서로 바로 공유하였다.
개인의 기능 개발에만 초점을 맞추는 것이 아니라 팀원의 기능 개발에도 관심을 가지고 의견을 냈다.
필요한 자료가 있으면 서로 공유하였다. 팀원 개인이 어떤 문제를 마주했을 때 팀이 함께 그 문제를 해결하는 방식으로 개인의 부담을 최소화하고 생산성을 높였다.
Bad Point
문제점
팀원의 현재 역량을 좀 더 객관적으로 판단하고 티켓을 분배했어야 했는데 팀원들 개개인의 상황을 더 자세히 파악하지 못하였다.
결국 팀원이 개발 일정을 따라오지 못해 티켓을 재분배해야 했다.
해결 방안
팀원이 개발 일정을 따라오지 못한 것을 팀원의 개인의 문제로 볼 수 도 있지만, 팀원들이 함께 서로의 상태를 체크하고 계속 피드백을 주고 받았어야 했는데 각자의 기능 개발에 초점을 맞추다보니 소홀해진 부분이 있었다. 이후 해당 팀원과 다시 의견을 조율하여 작업이 가능한 분량만큼만 해당 팀원에게 할당하고 다른 부분들은 비교적 작업속도가 빠른 내가 이어서 작업했다. 팀원들과 함께 합을 맞추는것도 프로젝트의 중요한 부분이라는 것을 다시 한번 느꼈다. 앞으로는 프로젝트 시작 전에 팀원들 개인의 현재 상태와 가능한 작업량을 좀 더 상세하게 정리하여 계획해야겠다고 생각했다.
문제점
프론트엔드와 백엔드가 서로 다른 언어를 사용하다보니 의사소통에 어려움이 있었다. 백엔드 팀이 설명해주는 서버에 대한 내용들을 완전히 이해하지 못한 상태에서 프론트엔드 팀이 개발을 진행해서 중간에 통신하는 과정에서 어려움이 있었다.
해결 방안
서로 완전히 이해가 안되었을때는 솔직하게 현재 상태를 팀원들과 공유하고 어떤 부분에서 이해가 어려웠는지 얘기 했어야 했는데 팀원들이 모두 서로의 입장을 배려해서 각자 찾아보고 해결하려다가 시간이 지체되었다. 결국 프로젝트 중반에 프론트엔드와 백엔드가 서로의 문제점에 대해 솔직하게 이야기하고 설명이 필요한 부분들은 다시 설명을 들으며 양측 모두 완전히 이해한 후 개발을 재개하였다. 프론트엔드와 백엔드가 서로 다른 방식으로 작업한다는 것을 인지하고 서로의 입장에서 이해해보려고 더 노력하는 자세가 필요하다는 것을 느꼈다. 프론트엔드라고 서버에 대해서 몰라도 된다는 생각은 위험한 생각이라는 것을 느끼고 백엔드의 DB 구조에 대해 물어보고 공부했더니 확실히 통신을 하는 과정이 수월해졌다.
[내가 마주했던 문제들]
추후 기능별로 정리하여 링크 첨부 예정
토큰 유무에 따른 조건부 랜더링 / token undefined가 true로 인식되는 오류 해결
컴포넌트가 마운트 될 때 fetch로 서버에서 받아오는 데이터 값이 없어서 생기는 오류 해결
useParams를 사용해서 경로 이동을 해야할 때 발생하는 페이지 공백 오류 해결
[프로젝트를 통해 배운점]
처음으로 팀프로젝트를 하며 느낀점이 많다. 우선 팀으로 작업을 하는 것이 어떤 측면에서 개인으로 작업하는 것보다 훨씬 복잡하고 어렵다는 점이다. 혼자서 작업물을 만들때와는 다르게 작은 부분들까지도 팀원들 모두가 함께 결정하고 함께 따라줘야지 문제 없이 프로덕트를 만들어 낼 수 있다는 것을 배웠다. 프로젝트를 시작하며 팀원들과 컨벤션을 정하고 공통으로 사용되는 컴포넌트나 컬러들을 미리 만들었다. 그런데도 작업을 진행하다보니 미처 생각하지 못했던 그 외의 부분들에서 내 코드와 팀원들의 코드가 충돌이 일어났다. 실제 기능 개발에 들어가기 전에 기획단계에서 나름 꼼꼼하게 문서로 정리하고 컨벤션도 만들었다고 자부했는데 막상 기능 개발에 들어가니 우리가 생각하지 못했던 너무나도 많은 사항들이 의논의 대상이 되었다. 결국 팀원들과 회의를 통해 필수적으로 논의되어야 할 사항들을 다시 한번 점검하고 프로젝트를 이어서 진행하였다. 이 과정에서 내가 당연하다고 생각했던 부분을 팀원은 전혀 다르게 생각하고 다른 방식으로 작업을 진행했던 것을 보고 나의 관점이 꼭 보편적인 관점이 아닐 수 있다는 것을 잊지 말아야겠다고 생각했다. 나의 기능을 개발하는 것도 물론 중요하지만 틈틈이 팀원들과 합을 맞추어 우리 팀이 함께 잘 가고 있는것 인지 아니면 각자의 방향으로 흩어지고 있는지 확인하는 과정이 꼭 필요하다는 것을 배웠다.
프로젝트를 진행하며 문제들을 마주할 때마다 팀원들과 함께 의견을 조율하고 합의점을 찾아갔다. 그 과정이 반복되다보니 개발자의 필수 능력이 소통능력이라는 말이 이해가 되었다. 팀원들간의 의사소통이 원활하지 못하면 그 모든 것들이 프로덕트에 이슈를 만들어 낸다. 프로젝트를 진행하면서 우리가 하려고하는 것이 무엇인지 그 방향성을 유지한채로 대화를 지속할 때만 생산성이 있는 결과를 얻을 수 있다는 것을 배웠다. 그리고 내가 원하는 것이 무엇인지, 팀원이 지금 필요한 것이 무엇인지 분명하게 이해하기위해 소통을 소홀히 하지 않는 것 또한 팀의 생산성에 영향을 준다는 것을 배웠다. 그리고 중간중간 결정되는 새로운 사항들이나 변경 사항, 함께 맞춰야하는 공통의 조건들을 노션에 컨벤션 문서를 만들어 정리하고 실시간으로 팀원들과 공유하였다. 모든 팀원들이 알아볼 수 있도록 정확한 표현으로 가독성 있게 쓰려다보니 자연스레 글을 잘 정리해서 쓰는 연습도 되었다. 노션에 정리를 잘 해두면 여러번 설명하지 않고도 팀원들과 정보를 빠르게 교환하여 작업 생산성을 높일 수 있다는 것을 배웠다.
팀프로젝트를 하면서 나로 인해 팀에 피해를 끼치는 일이 생길 까봐 모든 팀원들이 책임감과 부담감을 느꼈다. 팀원이 작성한 코드가 에러가 나면 그 팀원이 괴로워하는 일이 많았다. 그때마다 서로의 탓을 하기보다는 팀원들 모두 그 문제를 해결하기 위해 검색을 하고 자료를 모아서 공유하는 등 팀원이 마주한 문제를 함께 해결하려고 노력했다. 내 코드 치기가 바빠서 팀원의 어려운 상황을 모른척했더라면 아마 우리팀은 시간안에 프로젝트를 끝내지 못했을꺼라는 생각이 들었다. 다른팀에서 우리팀을 부러워한 이유도 바로 팀워크였다. 팀원 개인이 마주한 문제를 팀 전체가 함께 우리의 문제라고 생각하고 도와주는것이 개인 느끼는 부담감이나 압박감을 덜어주고 실수에 대한 두려움을 줄여주었다. 그 결과 팀원들은 에러가 나도 두려워하기보다는 어떻게 해결하면 좋을지 빠르게 의견을 공유하고 함께 해결해 나갔다. 이러한 일이 반복되니 팀원들의 사기가 오히려 높아져 "우리팀"이라는 소속감이 커지고 서로의 코드에도 관심을 가지고 더 유심히 보고 배우려고 노력하게되었다. 나도 팀원들의 코드를 모두 돌아보며 함께 에러를 고치는 과정이 어렵기도 했지만 즐거웠다. 문제를 마주했다는 것은 배움의 기회를 얻은것과 같다는 생각으로 문제를 해결하는 과정을 즐기려고 했다. 그래서인지 프로젝트가 진행되면서 지칠 때도 있었지만 팀원들 모두 안되는 문제를 만나도 포기하기보다는 다시 한번 도전해보고 새로운 방법으로 시도해보려고 했고, 그런 팀원들과 함께 나도 더 도전적이고 열정적으로 기능 구현을 할 수 있었다.
그리고 팀프로젝트를 통해 팀원의 컨디션이 팀의 컨디션이 되고 팀의 컨디션이 곧 나의 컨디션이 된다는 것을 배웠다. 내가 팀원에게 건낸 위로와 응원의 말이 다시 나에게로 돌아와 힘이 되는 순간들이 있었다. 팀으로 작업을 진행하며 개개인의 실력이 출중한것도 프로젝트의 성공에 기여를 하겠지만, 팀원 모두가 한마음으로 목표를 향해 달려가고, 서로가 최선을 다하고 있다는 믿음이 있을 때 프로젝트는 성공하는 것 같다. 팀원이 지칠 때 힘을 낼 수 있도록 응원해주고, 팀원이 실수하거나 방황할 때 나무라기보다는 팀원을 이해해보고 함께 해결방안을 찾아주는 것이 팀플레이의 힘이라는 생각을 했다.
개인적으로 이번 프로젝트를 진행하며 나의 개발 성향에 대해서도 알게 되었다. 나는 코드를 작성하기 전에 꼭 손으로 직접 로직을 다 작성하여 기능이 어떤 플로우로 진행되는지 파악한 후에 코드를 써야 더 정확도 높은 코드를 작성할 수 있었다. 머리속으로 생각한 것을 손으로 쓰며 직접 논리를 검증하는 과정에서 미처 생각지 못했던 허점들을 발견하고 보완할 수 있었다. 빨리 기능을 개발하고 싶은 급한 마음에 이 과정을 생략하면 꼭 사소한 부분에서 오류가 발생하여 시간을 잡아먹었다. 초반에 조금 허둥대던 것을 끝으로 프로젝트를 진행하면서는 계속해서 손으로 로직을 정리해보는 시간을 가졌더니 확실이 계획했던대로 기능이 작동하는 확률이 높아졌다. 물론 나의 부족한 경험으로 예상치 못한 오류들이 발생하기도 했지만 내가 쓴 코드는 완벽하게 로직을 이해하고 직접 작성했기 때문에 비교적 어렵지 않게 오류들을 바로 잡을 수 있었다. 무작정 코드를 작성하기보다 내가 구현하고자 하는 기능에 대한 이해를 먼저 한 후에 코드를 작성하는 습관을 프로젝트를 진행하는 동안 들였다.
끝으로 프로젝트를 무사히 끝마치며...
함께 수고한 우리 팀원들 감사합니다.
그리고 편을 나누기보다 함께 성장하는 동기로서 기꺼이 도움의 손길을 내밀어줬던 동기들 감사합니다.
밤낮으로 코드 리뷰를 남겨주시고 문제 해결에 많은 도움을 주신 멘토님들 감사합니다!
'개발 기록 > 프로젝트 회고' 카테고리의 다른 글
| wecode / 2nd team project 회고록 (0) | 2023.06.26 |
|---|
