프론트엔드 개발자의 백엔드 개발자/기획자/디자이너와의 협업과 투쟁

프론트엔드 개발자의 백엔드 개발자/기획자/디자이너와의 협업과 투쟁

업무중 이렇게 곤란에 처하는 것이 꽤 쉽지 않다.

 

 

프론트엔드 개발자는 필연적으로 백엔드 개발자 / 기획자 / 디자이너 등등 많은 다른 직군들과 협업하고 커뮤니케이션하며 업무를 진행해야 합니다.

 

개발자라는 직업이 혼자서 주로 일하고 사람들과 부딪히는 일이 별로 없다고도 합니다. 하지만 직접 프론트엔드 개발자가 되고 나서 일을 경험해 보니 개발자인 프론트엔드는 오히려 반대라고 생각합니다.

3년 가까이 프론트엔드 개발자로 일을 하면서 겪었던 커뮤니케이션 이슈, 협업 등등 깨달은 점들을 프론트엔드 개발자 관점에서 기록해보고자 합니다. 예비 프론트엔드 개발자 혹은 예비 기획자 / 디자이너 등등 IT 업계의 업무 방식이 궁금한 분들에게 많은 도움이 되고자 합니다.

 

 

 

 

 

 

 

 

왜 프론트엔드 개발자는 결국 부딪히는 운명인가

---

이유는 단순합니다. 프론트엔드 개발자는 최종 산출물을 만들고 마무리하는 포지션입니다. 디자인의 최종 결과물, 백엔드 서버 연동후 기능 실현, 기획자의 의도된 완성품, 거의 모든 다른 직군이 프로덕션 배포전까지 한 곳만 바라봅니다. 프론트엔드 개발자가 만들어서 내놓은 산출물을 말이죠.

 

결국 프론트엔드 개발자는 할 일이 많을 수밖에 없으며 완성된 산출물에 잘못된 것이 있으면 첫 번째로 이슈의 원인으로 프론트단을 먼저 지목합니다. 다르게 말하자면 프론트엔드 개발자는 일을 하면서 디자인, 기획, 백엔드 서버 다양한 배경 지식이 많이 요하게 될 수밖에 없습니다.

 

 

 

프론트엔드 개발자로 일하면서 생기는 이유와 예시를 상황별로 나눠보았습니다.

 

프론트엔드 <-> 기획자

기획자가 기획안을 완성하여 공유하면 바로 프론트엔드, 벡엔드 개발자와 회의 및 논의가 필요합니다. 실현이 가능한지, 공수가 얼마나 드는지 허용된 개발 일정에 대한 조율 등등 많은 설정들이 기획자와 오고 갑니다.

 

프론트엔드 개발자는 개발을 하면서 기획자와 많이 협업하게 됩니다. 프론트엔드 개발자가 개발 도중 발견한 기획의 오류, 기술적인 한계에 대한 대체 논의, QA 테스트 등등 하나의 Task 개발이 완벽히 완성될 때까지 서로 많은 소통이 오고 갑니다. 기획자가 프론트엔드 개발자에게 기능의 플로우, 정책 등등 개발을 진행하는데 정립이 필요한 요소들을 하나하나 체크해 주고 오더 해주는 것이 특징입니다.

 

기획자분이 IT 서비스 기획에 경험이 많지 않거나 개발에 대한 배경지식이 거의 없는 기획자분들과 협업하게 된다면 결국 프론트엔드 개발자는 일을 두 번하는 고생을 겪거나 오히려 기획을 대신해주기거나 기획을 다시 하고 다시 처음으로 돌아가 개발을 다시 해야 하는 불상사가 발생하기도 합니다.

 

 

 

프론트엔드 <-> 디자이너

디자이너와 프론트엔드 개발자 또한 많은 소통과 협업을 진행합니다. 눈에 보이는 디자인적인 것을 직접 그려주는 역할 하는 프론트엔드 개발자는 백엔드 개발자와 다르게 디자이너와 큰 비중을 차지하는 협업 관계를 가집니다.

 

디자인 안이 나오고 프론트엔드 개발자는 디자인 안을 통해 퍼블리싱 개발부터 시작하게 됩니다. 디자이너는 프론트엔드 개발자에게 디자인 안에 나온 픽셀 단위, 애니메이션 효과 등등 눈에 보이는 것들에 대하여 소통하고 협업하게 됩니다.

 

디자이너분과 갈등이 생긴다면 디자인 시스템의 공백으로 인한 일의 공수도 증가, 공수가 많이 드는 애니메이션 효과 등등 많은 것들이 있습니다. 특히 한정된 개발 기간에 개발 기간 중간에 난이도가 꽤 있는 애니메이션 효과를 넣어달라는 긴급 요청 사항에 난감해지기도 합니다.

 

특히 하나의 프로젝트에서 디자인 시스템이 구축되지 않은 디자인안을 만난다면 개발을 진행할 때 활용성 없는 컴포넌트 대량 생산에 프론트 엔드 개발자는 시간과 체력을 낭비하고 일에 대한 피로도가 증가합니다.

 

 

 

 

프론트엔드 <-> 백엔드 

백엔드 개발자와의 협업 또한 당연합니다. 프론트/백단의 조합이 있어야 결과물이 나옵니다. 백엔드 개발자가 기획안을 검토하고 개발한 API을 전달받아 프론트엔드 개발자는 기획안과 디자인 안을 보고 산출해야 하는 기능을 개발하여 구현합니다. 이때 프론트엔드 개발자와 백엔드 개발자는 최적화/서버 오류 등등 계속 이번 Task가 끝날 때까지 함께합니다.

 

갈등이 있다면 구현된 기능에 이슈가 발생하면 프론트쪽 이슈인가 백엔드 이슈인가 서로를 의심할 때를 예를 들 수 있습니다. 서비스 프로덕션 배포 후 혹은 QA 테스트 결과를 통한 상황이나 등등 기능 이슈가 나면 일어날 수밖에 없는 일들입니다.

 

또 어떤 기능을 만들때 이건 프론트단에서 처리해도 되면서도 백엔드 단에서 처리해도 되는 것인데 누가 더 일해서 어느 한쪽이 편해질까 라는 딜레마입니다. 정말 중요한 순간이면서도 개발 협업을 넘어 커뮤니케이션의 능력을 요하기도 합니다.

 

 

 

 

 

 

 

프론트엔드 개발자가 협업을 잘하기 위해서는

---

제일 중요하고 공통적인 것은 커뮤니케이션이라고 생각합니다. 하나의 이슈가 발생한다면 이 이슈를 해결하기 위하여 분명히 다른 직군의 사람들과 소통해야 하는 것은 피할 수 없습니다.

 

많은 소통이 필요한 프론트엔드 개발자는 소통을 잘한다면 더욱 좋은 개발자가 될 수 있다고 생각 합니다.

 

이때 말을 통해서 혹은 메신저를 통해서 대부분 소통하게 되는데 이때 상대방이 기분 나쁘게 하지 않으면서도 전달하려는 뜻과 의미를 잘 정리해서 말하거나 글을 쓰는 능력이 중요한 것 같습니다.

 

말할 때는 말투나 단어 선택, 메신저 혹은 문서는 글의 가독성, 간결한 문장과 핵심 내용의 압축성 등등이 있는 것 같습니다.

 

 

 

 

더 나아가 포지션별 상황을 통한 관점에서 더 나은 협업을 위한 해결 방안들을 나열해 보았습니다.

 

 

프론트엔드 <-> 기획자

기획자분과 원활한 협업을 하기 위해서는 프론트엔드 개발자는 개발 지식만이 아닌 IT 서비스의 분위기과 원리 그리고 기본적인 정책에 비롯되어 보이는 개발 검토를 할 수 있을 만큼 경험을 많이 쌓아 놓고 있어야 하며 많이 알고 있어야 하는 것 같습니다.

 

이 역량을 갖추게 된다면 프론트엔드 개발자는 기획안을 보고 처음 개발을 시작하기 전에 발견한 오류 사항들을 바로바로 정리하여 기획자분에게 요청하면 업무적인 면에서 불필요한 상황들을 많이 피할 수 있다고 생각합니다.

 

상대방을 존중할 수 있는 원활한 커뮤니케이션과 더불어 기획의 메인 플로우를 망치지 않는 선에서 다양한 해결책 혹은 충분히 납득 갈만한 대안책들을 제안할 수 있는 능력이 된다면 기획자분도 납득하며 더 아는 개발 업무를 진행할 수 있다고 생각합니다.

 

 

 

 

프론트엔드 <-> 디자이너

디자이너 분과의 협업 또한 프론트엔드 개발자가 개발을 시작하기 전에 디자인 안을 보고 기능 구현 후 발생할 수 있는 이슈나 구현 제한 사항들을 파악하여 디자이너 분과 타협하고 검토하는 것입니다. 

 

디자이너분들은 확정된 디자인을 중간에 수정하는 것을 좋지 않게 생각하기 때문에 초기에 검토 및 컨펌을 받는 것이 중요한 것 같습니다. 예를 들어 처음부터 이 애니메이션 구현은 공수가 많이 드니 다음 Task로 미루거나 최소한의 효과들로 대체하자는 제안 등등 많은 타협의 방법들이 있는 거 같습니다.

 

그리고 디자인 시스템에 대한 정립입니다. 간혹 디자인 시스템이 대부분 구축되지 않아 프론트단을 개발하는 입장에서 너무 많은 공수를 들 때가 많았습니다. 디자인 안을 만들기 전에 디자이너분과 함께 효율적으로 산출물을 뽑기 위한 디자인 시스템에 데한 정립을 미리미리 하고 타협하는 것이 중요한 것 같습니다.

 

 

 

프론트엔드 <-> 백엔드 

백엔드 개발자분과의 협업은 다른 직군분들과 마찬가지로 아는 것이 해결입니다. 프론트엔드 개발자는 백엔드 쪽 지식들을 잘 파악하고 알고 있어야 합니다. 다른 직군들과 비교하여 알지 못하면 협업이 거의 불가능할 정도로 중요합니다.

 

어떤 기능을 만들 때 이건 프론트단에서 처리해도 되면서도 백엔드 단에서 처리해도 되는 것인데 누가 더 일해서 어느 한쪽이 편해질까 라는 딜레마는 특히 개발 지식을 많이 요합니다. 사실 둘 중 한쪽이 고생하면 기능이 구현되는 것은 맞지만 최적화의 측면 혹은 기능의 궁극적인 목적에서 생각해 보면 어느 한쪽이 반드시 해야 하는 것이 대부분입니다.

 

예를 들어 결제 시스템 기능은 보안상으로도 그렇게 이론상 프론트단에서 처리하여 기능을 완성할 수 있지만 백엔드단에서 결제 로직을 타서 처리하고 프론트단에서 결과만 호출하여 확인하는 방식이 기본입니다. 반대로 UI 로딩뷰를 띄우는데 사용되는 분기점을 어떤 API의 호출 시간이 끝났다라는 것을 백엔드단에서 처리하고 보내줄 필요가 없으며 비용/최적화면에서 불리하므로 프론트단에서 처리합니다.

 

 

 

 

 

마무리하며..

---

더 많은 협업의 상황들이 있지만 제가 경험한 것들 중 대표적이고 중요한 상황들로 아주 간단하게 겉햛기 식으로 기록하여 분위기와 상황을 소개해드린 것 같습니다.

 

아직 많이 부족하다고 느끼는 프론트엔드 개발자지만 앞으로도 더 좋은 협업 관계를 유지하는, 트러블이 생기지 않는 누구에게나 환영받는 훌륭한 개발자가 되는 것을 목표로 하고 있습니다.

 

감사합니다.