🔥백엔드를 공부하는 사람이 작성한 글이므로 편향적일 수 있습니다.
이번 스터디 주제는 네트워크 였는데 네트워크에 대해서 어떤 이야기를 할까 고민했는데 수업시간에 이야기했던걸 발표하려니 뭔가 지루할 것 같고 흥미로운 주제를 하고는 싶은데 할게 마땅치 않아서 고른게 통신에 대한 이야기인데 사실 조금 걱정되는 부분이 있다 통신방법이나 이런 이야기를 한다면 네트워크라는 주제의 범주안에 들어갈 부분이긴 하지만 이건 좋은 점이니까 사실은 조금 애매하다. 그래도 도움이 되었으면 하는 바람에 발표를 진행했다.
이번에도 발표자료는 https://www.slideshare.net/ssuser4913c5/study-4-233588641 이 링크에서 볼 수 있다.
통신이란?
모든 정답을 알려주는(?) 구글에 통신이라는 단어를 검색하면 위의 사진과 같은 결과를 제공해준다. 소식을 전하는 것, 또는 그 소식, 전달하는 일을 통신이라고 하는데 우리가 흔히 사용하는 소프트웨어에서 이야기하는 통신, 즉 서버통신은 서버(백엔드)에 있는 정보를 클라이언트(프론트)에서 받아와서 띄워주는 일련의 과정이라고 볼 수 있다.
이러한 서버 통신을 할 때 대부분 백엔드 엔지니어가 작성해준 Api 문서를 보고 프론트 엔지니어가 코드를 작성한다. 흔한 일이라고 볼 수 있지만 백엔드 엔지니어가 설계한 것을 그대로 따라가는 것보다 같이 머리 맡대고 고민하는게 더 좋지 않은가? 그래서 간단하게 지금까지 통신하면서 설계하기전에 프론트 엔지니어와 합의 해두면 좋았던 것들에 대해 이야기 하려고 한다.
1. 인증에 대해
서비스 안에는 다양한 인증 방식이 존재한다. 그리고 구현 방식또한 인증에 따라 다른 경우가 많다. 대부분은 백엔드에서 인증방식을 정하는 경우가 많지만 미리 이야기를 해둔다면 프로젝트 셋팅, 이해도가 높아질 것이라고 생각한다.
2. 각 엔드포인트별 HTTP method
메서드의 종류는 매우 다양하고 표준화 되어있지 않은 경우가 많다. 여기서 말하는 표준화는 어떤것을 성공했을 때는 200을 줘라라고 정해져 있는 것을 말한다. 그래서 취향이 갈리는 경우도 있다. 인증에 대한 정보를 refresh 할 때 새로 생성한다는 느낌이 강하니 POST를 쓸수도있고, 있던 정보를 날리고 채워넣는 것이라고 생각되어 PUT을 쓸 수도 있다. 이런 식으로 취향에 따라 갈리는 부분을 어떤것이 더 잘 어울릴 지 미리 의견을 묻는다면 더 좋을 것 같다.
3. Status code에 대해
매우 많은 status code가 있고 이 또한 이 경우에는 딱 몇번! 이라고 정해져 있지 않다보니 이도 메서드와 똑같이 취향에 따라 갈리기도 한다. id가 중복되었을 때 충돌을 의미하는 409를 사용하는 개발자도 있고, 잘못된 id이므로 400을 사용하는 개발자도 있다. 특히 이 status code를 사용해서 프론트에서 경우에 따른 컴포넌트를 띄워주는 경우가 많다.
예시를 들자면 성공했을 때(200)의 컴포넌트, 실패 했을때(400)의 컴포넌트가 다르게 띄워져야 하는데 이를 구분하는 것은 대부분 status code가 될 것이다. 그런데 나눠져야 하는 분기점은 있는데 이가 만약 둘다 같은 status code를 가지고 있다면 다른 구분자를 찾아야 되는 문제점이 생긴다. 따라서 이에 대한 부분도 미리 상의를 해두면 좋을 것 같다.
4. 에러가 났을 때
연동을 하다 에러가 났을 경우에 대한 이야기 이다. 연동을 하다 에러가 나면 대부분의 개발자들은 당황하여 "500 떴는데요?" 라고만 이야기해주는 경우가 많다. 이때 어느 엔트포인트에서 오류가 났는지 요청을 어떻게 보냈는지에 대해 이야기해주면 연동과정에서 나는 오류는 매우 찾기 쉬울 것이다.
물론 실제로 프로덕션 환경에서는 다 모니터링 되어 있을 테니 그런 걱정은 줄어 들 것이다.
5. 네이밍에 대해
가끔씩 네이밍을 이거 썼다 저거 썼다 하는 경우가 많았다. 그래서 연동을 할 때 이거 문서에는 카멜인데 다 스네이크를 쓴다고 뭐가 맞는거냐는 질문을 몇번 받았었다. 그래서 아예 통신을 할 때 사용하는 모든 네이밍을 하나로 통일 했었던 적이 있었다. 그러다 보니 훨씬 더 간결해지고 이해하기 쉬워서 좋았었다. 위와 같은 헷갈리는 사태를 대비하기 위해서는 어느정도 네이밍을 맞출 필요가 있는 것 같다.
물론 이것들 외에도 이야기해두면 좋을 내용이 많지만 기존적으로 생각날 만한 내용만 작성해 보았다. 그리고 마지막으로 백엔드 엔지니어가 작성한 api 문서는 개발을 들어가기 전에 꼬옥 읽고 구현하기 힘든 부분, 틀린 부분을 지적해주면 나중에 겪을 시행착오를 줄일 수 있어서 좋다.
위의 글은 그간의 경험을 바탕으로 작성한 글이지 꼭 지켜야할 것을 정리해 둔 글이 아닙니다. 그저 조언정도로 생각하고 프로젝트 할 때 참고하시면 될 것 같습니다.
