BE 와 FE 는 어떻게 협업해야 할까.

부제 : 확신을 가지는 개발자가 되고 싶다.

저는 2년차 백엔드 개발자임을 먼저 알리며, 정답을 말하고자 작성하는 글이 아니라 저의 경험을 공유하고자 쓰는 글입니다.
오해 없으시길 바라겠으며, 다른 생각이 있으시다면 언제든 댓글로 의견 나눠주시면 감사하겠습니다.

백엔드와 프론트엔드는 보통 API를 통해 협업을 진행하게 될 텐데요. 보통은 아니, 저희는 api 설계를 진행하고 그 설계내용을 프론트에 전달 한 뒤, 프론트와 백엔드가 그 설계내용을 맞추기 위해 작업을 합니다. 

문제가 없이 그 설계내용대로 작업이 진행된다면 서로 의견이 대립할 일 없이 아주 좋은 업무 진행이 되겠지요. 하지만 종종 수정요청이 들어오는 경우가 있었습니다.

저는 대부분 그런 경우 백엔드에서 키 값을 변경하거나, 데이터 구조를 요청에 맞춰 변경하는 작업을 진행하곤 했습니다. 물론 설계를 해치는 작업건에 대해서는 프론트에 설계내용에 맞춰달라 말씀드리기도 하구요.
작업을 하다보니 과연 어떤 기준에 따라 FE와 BE 작업 건을 나누는게 맞는걸까? 하는 궁금증이 생겼습니다. 

그래서 블라인드 IT개발자 커뮤니티에 이런 글을 올렸습니다.

"FE 와 BE가 업무 협의를 할땐 어떻게 해야하나요" 글의 내용은 위에 적은 내용을 좀 더 허심탄회 하게 적은 글입니다. 
그리고, 많은 개발자분들이 답변을 달아주셨습니다 ㅎㅎ

 

많은 분들이 댓글 달아주신 내용에서 반복되는 것은 협의 였습니다.

저는 API 설계의 영역은 BE가 주도해야 한다는 생각을 은연 중에 가지고 있었습니다. 하지만 다른 개발자분들의 의견을 들어보니 같이 설계하는 분들이 꽤 많은 것을 볼 수 있었습니다. 
참 달린 댓글 하나하나 읽어보면서 생각을 많이 하게되었는데요.  

그렇게 읽으면서 제 나름대로의 기준을 세웠습니다.

1. FE 와 BE의 소통을 통한 설계를 하자!
2. 데이터 구조 변경에 대한 기준을 잡기 위해 아키텍처에 대한 기준을 정립하자!

초기 작성한 아키텍처에 반하는 내용 변경일 경우 FE에 양해를 구하고, 아키텍처에 대한 오류가 있거나 규칙에 맞지않는 변경 건이면 BE가 작업한다. 라는 기준입니다.

물론 팀에는 리더가 있고, 누군가는 "사수가 정해주는대로 하세요." 라고 말씀하시는 분도 계실거라 생각합니다. 
개발은 개인이 하는게 아닌 팀이 하는 거니까 물론 맞는 말씀이라고 생각합니다. 저도 그렇게 따를 예정이구요. 

그래도 제 개발인생에 이런 기준을 세우고 고쳐나가면서 언젠가 제가 팀의 리더가 된 후, 저의 팀에게 이런 내용을 말해주고 이끌어 나갈 수 있는 그런 리더가 되고 싶은 마음에 이런 글을 썼습니다.

부족한 글 읽어주셔서 감사합니다.