항해 (9기) 6주차 WLI 회고

• 기간 10월 21일(금)~10월 28일(목)
• 프론트 랑 첫 협업

1. 미니 프로젝트

주특기 숙련 주차에는 백엔드 끼리 협업을 하는 방법을 경험해봤다면 미니 프로젝트 주차는 백엔드 끼리 협업 뿐만 아니라 프론트 엔드와도 협업을 해볼 수 있는 기간이었다.
프론트와 백은 한 주동안 어떠한 주제에 대해서 프로젝트를 진행할 지 얘기하였고 우리 조는 벨런스게임을 만들기로 했다.

협업을 진행하면서 어려웠던 점

• 아무래도 프론트와 백 모두 협업을 처음 진행하다 보니 프론트와 백의 역할 경계가 애매했던 것 같다.
  -> 아이디, 비밀번호 등의 유효성 또는 예외처리 같은 것들을 어디서 처리해야 하나 고민을 했지만 안전성을 위해 프론트와 백 모두 진행하였다.
  
  
• 도커로 깃액션을 사용한 자동 배포를 해보았다. 아주 잘 되었다.
• 무료 SSL 인증서 발급이 생각보다 많이 어려웠다. 기존의 백에서 배포를 했을 때는 HTTP로 배포를 했지만 프론트 분들은 HTTPS로 배포를하여 맞춰줄 필요가 있었다. 이를 위해 SSL 인증서를 발급받아 스프링부트에 적용을 해야했다. 처음은 Certbot으로 진행하였지만 잘 되지 않아 무료 인증서를 발급해주는 사이트를 통해 SSL 인증서를 발급받을 수 있었다.
  
  

이번 협업을 통해 중요하다고 느낀점

이번 협업을 통해 처음 API 설계에 중요성에 대해 느꼈다. 항상 미니 프로젝트 전까지는 API 명세서에 작성할 때 간단하게 적어놓고 Postman이나 Swagger를 통해 API 명세서를 만들곤 했다.
하지만 프론트와 협업을 진행할 때 처음부터 API 설계를 할 때에 해당 API의 url과 어떤 것을 request할지, 이에 대해 어떤 내용을 response할지 명확히 정해두지 않으면 백은 해당 API에서 request 받기를 원하는 데이터를 제대로 받지 못해 null이 떴고 프론트도 마찬가지로 데이터를 제대로 화면에 띄어줄 수 없는 상황이 발생하였다.

또한 API 설계 명세서에 최신화의 중요성을 깨달았다. 주고받는 데이터가 바뀌거나 url에 변경이 생기는 등 무언가 수정사항이 있을 때 제때제때 설계 명세서에 반영해놓지 않으면 프론트와 백 모두 혼선을 야기할 수 있다. 따라서 무언가 API 설계 명세서에 대해 변경점이 생기면 변경점에 대해 수정을 해놓고 서로에게 어디에서 이러한 변경점이 생겼다 ~~ 얘기해주는 것이 좋을 것 같다.