🐽 모아모아 프로젝트를 진행하면서 백엔드와 어떤 방식으로 협업했는지 정리해본다!
🚀 백엔드 api 이용하기
API는 프론트엔드와 백엔드가 소통하는 지점이라고 볼 수 있다. 개발과정에서 프론트엔드는 로컬에서 백엔드가 개발한 api를 이용해야 한다.
로컬에서 백엔드 api를 이용하는 여러가지 방법이 있는데...
- 배포된 백엔드 서버 이용하기
- 로컬에서 백엔드 서버 실행하기
처음에는 첫 번째 방법을 선택했는데 쿠키 이슈로 인해 두 번째 방법을 이용했다.
이때 백엔드 api를 이용하려면 CORS 정책을 피해갈 수 없다. CORS 정책을 위반하지 않기 위해 백엔드에서 Access-Control-Allow-Origin을 알맞게 설정하거나 클라이언트 측에서 proxy 서버를 설정해야 한다.
- 만약 첫번째 방법을 이용한다면 클라이언트 측에서
proxy설정을 하면 CORS 정책을 우회하여 백엔드 api를 호출할 수 있다. - 만약 두번째 방법을 이용한다면 클라이언트 측에서 로컬 서버 base url를
proxy로 설정하고, (ex.http://localhost:8080) 백엔드에서는 배포된 클라이언트 url를Access-Control-Allow-Origin으로 설정해주면 된다. - 백엔드에서
Access-Control-Allow-Origin을http://localhost:3000(로컬 클라이언트 url)으로도 설정할 수 있다. 하지만, 이 출처는 범용적이기 때문에, 보안 상의 issue가 발생할 수 있다. 차라리 클라이언트 측에서 로컬 백엔드 서버 url이나 배포된 백엔드 서버 url를proxy로 설정하는 것이 보안적인 측면에서 더 좋다.
👍 Swagger 활용하기
개발한 API를 프론트엔드 개발자가 확인할 수 있도록 Swagger를 이용했다. Swagger를 모아모아 프로젝트를 하면서 처음 알게 되었는데 프론트엔드와 백엔드의 협업에 도움을 주는 좋은 도구라는 것을 느꼈다. 백엔드에게 일일히 어떤 API에 어떤 파라미터를 보내줘야 하는지, 어떤 데이터로 응답해주는지 물어보는 것은 매우 비효율적이다. 하지만, Swagger를 이용하면 API의 HTTP Method, 보내줘야 할 파라미터 혹은 쿼리스트링, 응답을 쉽게 파악할 수 있다.
🗣️ 명확한 의사전달
먼저, 기획서와 와이어프레임을 바탕으로 어떤 api가 필요할지 파악했다. 이후에 개발을 진행다가 프론트엔드에서 필요한 api가 있거나 api 인터페이스에서 변경되어야 할 사항이 있다면 다시 백엔드분들과 협의하는 식으로 진행했다.
모아모아 프로젝트 중에 백엔드와 API 인터페이스를 협의하는 과정에서 혼선이 있었다.
게시물 POST API에서 request body에 imageUrl string 배열 파라미터를 추가하여 해당 유형의 데이터도 같이 보내고 싶었다. 그래서 게시물 POST api 인터페이스 변경을 위해 다음과 같은 대화가 이루어졌다....
FE : 커뮤니티 게시글 생성 api에서 imageUrl도 보내도록 할 수 있나요??
BE : 게시글 생성 api는 이미 imgurl을 반환하고 있지 않나요?!
FE : 백엔드에서 보내는게 아니라 프론트에서 게시글 생성 api 사용할 때 payload로 imageUrl도
보낼 수 있도록 수정가능한지 궁금합니다.
BE : 커뮤니티 게시글 생성 API에서 이미지 경로를 보내서 어떤걸 리스폰스 해줘야하는건가요?
FE : response는 지금 그대로 해도 됩니다. 커뮤니티 공유하기를 하면 이미지가 게시물에 등록이 안돼요.
머니로그에서 가져온 이미지라서 file이 아니라 url 형태입니다. 그래서 추가로 imageUrl (string 배열 형태)도
게시물 등록할 때 페이로드로 보낼 수 있을까요??
BE : 게시물 등록할때 파일을 form-data로 보내는데 이미지경로를 어떻게 보내신다는건가요??
FE : imageUrl 스트링 배열로 해서 form-data로 보낼 수 있지 않나요??
BE : 네 보낼 수 있는데 그 보내는 이미지 경로가 커뮤니티 게시글 이미지인가요? 머니로그 게시글 이미지인가요?
FE : 머니로그 게시글 이미지 입니다!
BE : 네 만들어볼게요!첫 대화부터 보내는 주체가 프론트인지 백엔드인지 명확하게 전달하지 않았다. 만약 게시물 POST API request body에 parameter를 추가하고 싶다고 처음부터 이야기했으면 백엔드 분이 api 인터페이스 변경의 요구사항을 쉽게 이해했을 것이다. 명확한 용어 (request body, parameter) 를 사용했기 때문에 imageUrl를 보낸다는 표현을 사용했을 때보다 더 명확하게 의사전달이 되었을 것이다.
더불어, 어떤 유형의 파라미터인지 (imageurl string 배열), 해당 파라미터를 추가해야 하는 이유 (머니로그를 커뮤니티에 공유할 때 머니로그 이미지 url를 게시물에 등록하기 위해) 를 명확히 설명했다면 원만하게 협의가 이루어졌을 것이다.
백엔드와 소통할 때는 명확한 용어를 사용해야 한다는 것을 느꼈다. 이때 명확한 용어는 프론트엔드만 이해할 수 있는 용어가 아니라 백엔드 분들도 같이 공유하고 공식적이고 널리 사용되는 용어여야 한다. API 인터페이스는 프론트엔드와 백엔드가 소통하면서 지켜야 할 약속이기 때문에 API 인터페이스를 협의하는 과정에서 명확한 의사전달이 중요하다!
👂경청의 자세
위 대화는 채팅으로 이루어진 것이다. 채팅으로 이루어진 대화는 텍스트를 보고 상대방의 말을 충분히 이해한 다음 대화를 이어나갈 수 있다. 하지만, 말을 통해 이루어지는 대화는 눈으로 볼 수 없기 때문에 경청의 자세가 필요하다. 내 말이 항상 맞지 않다는 것을 인정하고, 상대방의 말을 진심으로 들어주고, 이해하는 자세가 중요하다.
🙌 공유는 필수!
모아모아 팀은 일주일에 두 번 회의를 진행했다. 한 번은 전체 회의이고, 다른 한 번은 FE와 BE별 회의이다. 프론트엔드와 백엔드 각자 회의를 진행해도 팀 노션에 반드시 회의록을 작성하여 공유했다. 서로의 진행상황을 파악할 수 있고, 서로의 요청사항이나 부탁할 것들도 미리 파악할 수 있다. 그리고 공유하는 회의록이기 때문에 회의 내용을 자세하게 적을수록 좋다.
회의록뿐만 아니라 다른 공유 문서들도 자세하고 정확하게 작성해야 한다. 프로젝트를 진행하면서 백엔드 분들이 기획서와 와이어프레임을 바탕으로 DB를 짜고, 어떤 api가 필요할지 파악하여 api를 개발했다. 기획서 작성과 와이어프레임 만드는 것을 기획하시는 분과 프론트엔드가 담당했는데 의외로 백엔드분들이 기획서와 와이어프레임을 많이 참고하셔서 놀랐다. (특히, 와이어프레임) 그래서 기획서와 와이어프레임과 같이 프론트엔드와 백엔드가 같이 공유하는 문서는 혼선이 빚지 않도록 자세하고 정확하게 만들어야 겠다고 생각했다.
