기능 명세 싱크 맞추기

팀원 들과 스프린트를 진행하며, 어려움을 겪은 부분은 특정 기능에 대해 어떤 요구 사항이 있었는지 알기 힘들다는 점이었다.

예를 들면 이런 식이다.

여행기 상세 페이지에 태그 만들기로 한 거 아니었나요?

지도 상세 보기 버튼은 어떻게 하나요?

분명 3차 스프린트에서 구현해야 할 것들도 서로 알고 있는 부분이 다르다고 생각해 구현 할 기능 명세에 대해 업데이트하는 회의를 따로 진행하였다.

싱크 맞출 기능을 정한 후 기능 명세서를 업데이트 하는 과정을 진행했다.

업데이트 하는 과정에서 얻을 수 있는 이점은 아래와 같았다.

의견이 갈리지 않는다.

스프린트 내에서 합의 된 내용을 기반으로 진행하기 때문에, 의견이 갈릴 수 없다. 이미 합의 된 내용을 바탕으로 진행하기 때문에 충돌 없이 기능 구현 - QA 까지 이어질 수 있었다.

인지 부하를 예방한다.

처음부터 모든 기능을 정해놓고 기억하기는 쉽지 않다. 하지만 구현해야 할 기능을 조금씩 쪼개어 처리하니 무엇을 해야할지, 뭐가 필요한지 더 쉽게 인지할 수 있다. 이는 기능이 의도와 다르게 만들어지는 것을 방지할 수 있었다.

백엔드 - 프론트엔드 협업 하기

3차 공통 요구사항에서 다음 항목이 추가되었다.

FE or AN 에서 BE까지 관통하는 업무 중 최소 하나를 FE or AN / BE 개발자가 짝으로 (3인 짝도 가능) 진행해주세요. ex - 한 명의 웹 백엔드 크루와 한 명의 모바일 안드로이드 크루가 짝을 이루어 서버 요청부터 응답까지 하나의 기능을 개발

이런 요구 사항이 추가된 이유는 다음과 같이 설명되어있었다.

프로젝트는 무엇보다 협업의 경험이 중요하다. 서로 다른 교육 분야끼리 ‘나는 나, 너는 너' 처럼 업무를 나누고 비즈니스 관계로 일하기 보다는 각각의 분야를 이해하면서 긴밀하게 협업하는 경험이 필요하다.

이를 위해 백엔드 - 프론트엔드가 함께 협업할 수 있는 기능을 찾아보았고 3차 스프린트에서 진행할 수 있었던 업무는 다음과 같았다.

1. 프로필 기능
2. 삭제(여행기 & 여행 계획)
3. 링크 공유

마침 프론트엔드가 3명이었기 때문에 팀을 다음과 같이 나누었다.

팀 내에서 소통 방식은 자유롭게 정하되, 노션에 기록하고 매일 진행 사항을 공유하는 것으로 진행했다.

그 결과 노션에 각 팀의 개성이 묻어났다.

우리 팀의 경우 공유 기능에 대해 아래와 같은 순서로 진행했다.

1. erd 기반 response 스키마 합의
2. 확인 후 각자 작업 시작(백엔드 - api 설계, 프론트엔드 - ui 작업)
3. 중간중간 의사소통 하기(ex - 공유하기 ui 한번 확인 부탁드려요!, 공유하기 api 명세 반영된거 확인해주세요!)

공유 기능에 대해 response가 기존 여행 계획 api에 share key 정도 추가된다는 사실이 아쉬웠지만, response가 erd를 기반으로 만들어진다는 것만으로도 충분히 가치 있는 시간이었다.

또한, 사전에 api response를 빠르게 체크하니, 지체되는 시간 없이 msw로 모킹하는 작업을 더 빠르게 진행하여 공유 모달에 대한 페이지 피드백을 받을 수 있다는 사실이 좋았다.

cors 에러

3차 스프린트 기간 동안 cors는 총 3번 발생했다.

1. 인가(authorization header 내 access token으로 검증) 처리 추가
2. 이미지 업로드 시 발생
3. 여행기 등록 버튼을 누를 시 발생

이전에 https(프론트) - http(백엔드)로 인한 mix-content 문제를 해결해놓은 상태에서 다시 한번 cors가 터지니 머리가 아팠다. get 요청에 대해선 문제가 없었는데, post 요청에 대해 다시 문제가 발생한 것이었다.

cors 에러가 발생 시 프론트엔드 개발자는 어떻게 대처해야할까?에 대해 여러 레퍼런스를 찾아보려했고, 결국 백엔드 개발자 분들에게 도움을 요청했다.

터졌던 3가지 case 모두 백엔드 내부 처리에서 발생한 문제였다.

이제 부터 cors 에러가 발생하면 백엔드 분들에게 여쭤봐야겠다고 생각했고, 내가 할 수 있는건 cors 에러가 발생할 수 있는 case들을 확인하여 백엔드분들에게 말씀드리는 정도가 최선이라고 생각하게 된 계기가 되었다.

정리해 둔 글은 아래에서 확인해볼 수 있다.

• cors 정리

소통 방식 개선해보기

우리 팀의 경우 일 관련 소통을 할 때 주로 슬랙에서 소통을 한다.

주로 어떤 상황이 발생했을 때 스레드에 글을 남기면 누군가가 읽는 방식이다.

이 방식의 문제점은 위 사진에서 확인해볼 수 있다.

문제가 발생했을 때, 채팅으로 계속 이야기하려고 하니 아래와 같은 문제점이 있었다.

1. 답변이 올 때까지 기다려야한다.
2. ~ 확인 부탁드려요.라는 말을 반복적으로 하는 것이 눈치 보인다.

2번의 경우 팀원들에게 계속 닦달하는 듯한 뉘앙스로 오해할 수 있다고 생각했고, 이를 방지하기 위해 discord와 같은 화상 공간에서 소통하는 것이 좋겠다고 생각했다.

그래서 다음과 같이 소통 방식 개선을 제안드렸다.

주말에 작업하시는 분들은 게더에서 마이크 끄고 일하되, 소통 사항이 생기면 바로 바로 마이크 키고 소통하는 것이 어떨까요?

3차 데모데이가 끝난 지금, 이런 방식으로 소통함으로 인해 위 2가지 문제점을 빠르게 해소할 수 있어서 좋았고 앞으로도 이런 방식을 유지하려고한다.

데모데이

팀 피드백

3차 데모데이가 시작했고, 우리 팀에서 받은 피드백은 아래와 같았다.

우리 팀의 협업은 기대한 대로 잘가고 있나요?

코치 분들이 우리에게 눈 감고 손을 들어 위 사항에 대한 점수를 1~5점 까지 표시하라고 제안주셨다.

눈을 뜨고 나서 결과를 알려주시는데 우리팀은 4.8점이라고(..!) 말해주셨고, 0.1을 올리기 위해 어떤 것을 하면 좋을지에 대해 제안 주셨다.

그 후 우리는 상호 피드백에 대한 이야기를 했다. 스스로 아는 자신과 타인이 보는 나는 서로 다르기 때문에, 팀 내에서 더 나은 방향으로 나아가려면 서로에 대해 피드백하는 부분이 필요하다고 생각했기 때문이다.