프로젝트 초반 프론트, 백 각자가 어디까지 작성이 완료됐고, 어느 부분을 할 차례인지 명확하게 공유가 되지 않은 것 같다.
다음에 같은 방식으로 프로젝트가 진행된다면 프론트, 백 모두가 얘기해야 할 시간에 각자가 어떤 부분까지 완료됐는지를 명확하게 공유하는 시간을 초반부터 가져갔을 것 같다.
코드를 작성해 가면서 API 호출 응답을 어떻게 가면 좋을지 점점 뚜렷해지는데, 그런 과정 없이 이런 데이터들이 있으면 좋겠다 싶은 내용들로 구상하다 보니까 백엔드에게 전달한 응답 형태에 대한 신뢰도가 막 높지는 않았던 것 같다.
같이 기능을 정하기보다는 프론트엔드쪽에서 피그마를 그린 후에 기능을 설명하는 형식으로 초반 회의가 진행되다보니 서로 이해하고 있는 부분이 달라서 힘들었다.
API의 요청과 응답 데이터 구조를 좀더 빠른 시기에 그리고 명확하게 설정했다면 계속해서 API를 수정하는 일이 줄었을 것 같다.
계속해서 이해도를 높이기 위해 소통을 많이 했고, 최대한 백엔드에서 원하는 부분 그리고 백엔드가 프론트에게 원하는 부분을 맞춰주기위해 노력했다. 그리고 데이터의 구조나 필드명을 확실히 정하기 위해 API설계서를 꼼꼼하게 작성했다.
1. 서비스 로직에 대한 이해가 동기화 되지 않았을 때
프론트쪽에서는 이렇게 생각하는데 백엔드 쪽에서는 저렇게 생각할 때
데이터 스키마를 미리 작성해서 소통하여 이해도를 높이려고 노력했던 점이 기억에 남는다.
2. 소셜로그인에 대한 이해 차이
이전에 소셜로그인을 구현할 때 소셜로그인 API처리를 프론트에서만 해봤었다. 그리고 이번에도 프론트에서 해줘야하는게 아닌가 생각했는데 백엔드에서 처리하는 방식도 있었다.
프론트의 생각만 하는게 아니고 백엔드의 입장이 되어서 생각해야겠다라는 생각이 들었고
백엔드와 협업을 해서 어떤 구현을 하게 되면 프론트의 입장과 백엔드의 입장을 모두 고려하여 생각하고 서치하도록 태도를 바꾸게 되었다.
3. api요청이 너무 쪼개지거나 복잡해졌을 때
한가지 아쉬운점은 백엔드에서 api를 페이지 단위로 구현하려고 하다보니 하나의 네트워크 요청으로 충분히 커버할 수 있는 부분을 여러개로 쪼개진것 같다라는 아쉬움이 든다.
이부분은 내가 백엔드의 상황을 잘 몰라 함부로 이야기 할 수 없는 부분이지만 덩달아 프론트에서도 네트워크 요청이 복잡해져서 어려웠던 적이 있기 때문에 백엔드의 개념까지 알고 있어야 피드백을 드리거나 제안을 하여 더 간결하게 네트워크 요청처리를 할 수 있게 되고 좋은 서비스가 될 수 있을것 같다느 생각이 들었다.