입사를 하고 일을 하면서 백엔드 개발자와 소통하는 과정에서 많은 것을 배우고 있는 것 같다.
효율적이지 못했던 나의 몇 가지 경험과 소통의 부재로 인해 발생했던 이슈에 대해 기록해보려한다.
🔥 마주했던 이슈들
1. 백엔드에서 내려주면 간단할 일을 프론트에서 해결하려 함
2. 연차가 높은 백엔드 개발자가 프론트와의 협업에 대한 모든 것을 알고있다는 착각
3. api의 변경된 데이터구조에 대한 정보를 전달하지 않아 클라이언트단에서 발생한 에러
📌 비효율을 불러오는 '내려오는 api가 정답이겠거니'
착각의 시작 - 난 신입이니까
백엔드에서 내려주는 api가 최종본이라고 믿었다. 나는 신입이고 백엔드 분들은 모두 경력자이기 때문에 백엔드에서 내려오는 모든 값들은 전부 맞다 라는 나의 어리석음이었을까나.
백엔드와 협업의 경험이 없었고 api라고는 토이프로젝트 만들 당시에만 오픈 api를 어찌저찌 끌어다 쓴 경험이 전부이다보니 "주는 대로 써야한다, 내려오는 것에서 알아서 필요한 건 계산하고 정렬하여 써야한다" 라는 생각이 있었다.
눈으로 보이는 차이
매번 동적으로 내려오는 값들을 계산해서 렌더링해야하는 부분이 있었다.
열심히 줄을 늘려가며 계산을 해놓고 나니 한참 한참 뒤 '백엔드에서 내려주는 게 더 간편하고 나을 것 같아서 수정하겠다' 라는 답변이 돌아왔다.
처음부터 계산을 백엔드에서 해주고 내려준 값만 그려주었더라면 단 몇줄에 끝날 로직이었을 것을 몇배로 들어난 코드를 보자니 골치가 아파졌다.
다시 코드를 회수하고 백엔드에서 내려준 값을 넣으니 훨씬 깔끔하고 간단해진 코드를 볼 수 있었다.
요즘 원티드 강의를 수강하고 있는데, 마침 비슷한 내용이 나왔다.
- 신입들의 착각
백엔드 개발자가 바쁘다고 하네 내가 프론트에서 다 해주겠어. 이게 바로 협업이고 기여지. 난 협업을 잘 하는 사람이야!
난 저런 생각보단 그냥 몰랐다. 그래서 백엔드와 소통할 수 있을 정도의 지식은 가지고 있어야 겠다는 생각이 들었다.
📌 정확하게 소통해야하는 이유
버튼 동작 하나를 완전하게 개발하기까지 오랜시간이 경험이 있다.
사용자가 버튼을 눌렀을 때 세 가지
- 성공
- 실패 - 제한사항1
- 실패 - 제한사항2
버튼 하나에 세 가지로 구분해 모달을 띄워 사용자에게 알려야 하는 부분이 있었다.
response로 들어오는 message로만 분기해야 한다고?
처음 데이터가 내려올 때 실패에 대한 response 안에 message만 들어와 있었다.
모든 게 끝난 시점에서 돌이켜보면 백엔드 개발자분은 message를 그대로 팝업에 띄워줄 것이라 생각하신 것 같다.
- 처음 나의 액션
백엔드 개발자와 처음 소통해보는 나로서는 백엔드가 주도하는대로 (이게 맞겠지.. 경력이 꽤나 있으신데, 난 잘 모르니까)진행.
하.지.만
- 내가 해야했던 작업
실패 두 경우를 분기해 실패 메세지를 띄워줘야하는데 백에서 들어오는 메세지가 사용자에게 노출되는 메세지와 상이했다. 또한 디자인에 따라 개행점도 달랐다.
이러한 상황에서 메세지로 분기하는 것은 적절치 못하다고 생각했다. 언제는 바뀔 수 있는 게 메세지 이므로! - response에 메세지 이외의 에러 타입 추가 요청하기
에러는 두 가지이므로 메세지처럼 가변할 확율이 적은 에러의 type을 요청했다. 그 결과 아주 간편하게 분리하여 에러에 대한 처리를 할 수 있었다.
갑자기 동작하지 않는 문제
잘 동작하던 버튼이 어느날 갑자기 이슈로 등록되었다. 사용자가 버튼을 눌렀을 때 혜택을 받을 수 없다는 내용의 팝업이 안 나온다는 것이다.
아니 잘 되던 게 갑자기 왜?
하지만 직감적으로 알 수 있었다. response로 들어오는 type과 프론트에서 enum으로 지정해놓은 type이 일치하지 않는다는 것을..
백엔드 개발자분에게 해당 이슈가 할당되고 오래 지나지 않아 백엔드 개발자분은 에러가 난다며 나에게 문의하셨는데 확인 결과 이전에 전달하신 타입과 현재 들어오는 에러의 타입이 일치하지 않는다는 것을 알려드렸다.
너무나 의아했던 것은 '프론트에서 type을 관리하여 진행하고 있냐'는 질문이었다. 생성을 요청할 때 전달 드렸던 내용이긴 하지만 워낙 많은 일을 하시다보니 잊으셨을 것이라 생각하고 결과적으로 이 이슈는 짧은 시간에 해결을 하였다.
- 내가 여기서 느낀 것은
나보다 연차가 높다고 해서 모든 것을 알고 계실거라고 생각하는 것은 나의 나태와 게으름이란 것이다. 작업하고 있는 부분에 대한 경험이 없으실 수도 있고 정확히 프론트에서 무얼 하는지 모르신다면 다년차의 경력자라도 충분히 모를 수 있겠구나 라는 생각이 들었다.
무언가를 요청할 때는 좀 더 정확하게 왜 필요하여 생성을 요청하는지, 이걸 통해 무엇을 할 것인지를 전달하고 그에 따라 변경사항이 있을 때는 전달 할 것을 부탁드려야 겠다는 그런 생각..
📌 아니 잘 되던 게 갑자기 에러가 난다니까?
소통은 비단 개발뿐만이 아니라 모든 분야에서 효율적인 업무를 위해 꼭 필요한 도구인 것 같다.
위에서도 언급했듯 나지 않아도 될 에러가 나서 -> 이슈에 등록이 되고 -> 원인을 찾는 과정은 효율과 거리가 멀다.
가끔 슬랙에서 프론트엔드 개발자들의 아우성이 들린다.
백엔드에서 데이터를 수정하면 꼭 알려달라는 내용
의 아우성이다.
나 역시도 관련 에러를 마주한 적이 있는데 들여다보면 에러를 추적하는 과정에서 지정해놓은 타입과 들어오는 api의 타입 혹은 구조가 상이한 게 이유였다.
우리는 효율을 위해서라도, 한 번 작업하면 될 것을 두세번 작업하는 것을 방지하기 위해서라도 꼭 소통을 통해 함께 일하는 사람들의 시간을 아껴줘야한다.
가령 글의 첫 부분에 썼던 계산의 문제도 내가 해당 상황을 일찍 파악하고 백엔드에 먼저 요청 했더라면 개발 시간을 단축했을 것이다.
이런 것을 보면 더 많이 공부하고 알고 있을 수록, 내가 하는 작업이 같이 일하는 사람에게 어떤 영향을 줄까 생각할 수록 우리는 더욱 더 효율적인 업무를 할 수 있을 것이란 생각이 든다.
