첫 프로젝트, 프론트엔드 개발자의 협업

✅들어가며

❗ 본 글은 IT 연합동아리 코테이토의 프론트엔드 네트워킹 3차시 활동을 목적으로 작성된 글이며, 상당히 주관적인 내용을 담고 있습니다.
기획자, 디자이너, 백엔드 개발자와 처음으로 협업을 진행하는 예비 프론트엔드 개발자분들에게 조금이나마 도움이 되길 바라면서 적는 글이며, 기업에서의 협업 방식은 저도 아직 경험해보지 못한 영역이기 때문에 혹시 기업에서의 협업 방식과 크게 다른 부분이 있다면 지적해주시면 감사하겠습니다.

---

👨🏻‍🏫공통

1. 프론트엔드 개발자의 숙명 📢

프론트엔드 개발자는 기획자, 디자이너, 백엔드 개발자와 모두 밀접하게 맞닿아 있기 때문에, 각 직군과의 의사소통이 가장 잦습니다.

그렇다면 프론트엔드 개발자는 어떻게 훌륭한 소통을 만들어갈 수 있을까요?
-> 제 생각에 이상적인 의사소통에 있어 필수불가결한 두 가지는
올바른 문서 작성 및 사용 + 정형화된 용어 라고 생각합니다.

2. 자주 사용되는 툴에 대한 기초적인 사용법을 숙지해놓자

저 같은 경우에 동아리 단위 프로젝트에서는 팀 단위에서 Notion, 디자이너와는 피그마, 백엔드 개발자와는 API 명세서 (ex. Swagger)를 사용하여 소통하는 일이 잦았습니다.
앞서 나온 툴들은 동아리 단위 프로젝트에서는 스탠다드에 가까우며 혹시 사용법을 잘 모르고 있다면 시간을 내서 조금이라도 숙지하도록 합시다.

저는 디자이너 한 분을 붙잡고 2시간 동안 피그마 특강을 들었습니다...

3. 모르면 물어보자

저는 첫 프로젝트에서 회의를 진행하면서 모르는 단어, 처음 써보는 툴이 정말 많았습니다.

ERD? 포스트맨?(가수 X) LO-FI?(노래 장르 아님) Ideation? 피그마에 메모 남기는 법 등등....

너무 기본적이거나 간단하게 느껴지는 것은 자기가 직접 찾아봅시다.
그래도 잘 모르겠으면, 회의의 흐름을 끊지 않는 선에서(쉬는 시간이나 회의 직후) 꼭 물어봅시다. 다들 처음이고 미숙한건 당연하니까요.

모르는 것은 잘못이 아니나 모르는 것을 알면서도 방치하는 것은 죄입니다..

👨🏻‍🏫직군 별

💻백엔드 개발자와의 협업

백엔드와의 협업 = API 통신
그 중에서도 RESTful API 통신이 대표적인데요.
이게 어떤건지 잘 모르시겠다면 이 글을 한 번 읽어보시면 좋을 것 같습니다. 저는 첫 프로젝트를 할 때 처음 들어봤어요..

통신 과정에서, 프론트나 백이나 한 번에 API 연결 딱딱 진행되서 값을 잘 넘겨주고 받아오면 좋겠지만 현실은 녹록지 않죠...😪
대표적인 예로 처음 프로젝트를 경험하게 되면 자주 겪는 CORS 에러, 상황에 따른 request 파라미터 변경 등 서로 소통하게 될 일이 많은데요. 이 때 2가지 정도만 주의하여 진행하면 적어도 욕먹을 일은 없을거에요!

1. 질문 / 문제 발생 시에는 상세히 알려주기

FE : 로그인이 안돼요! - X 

FE : 로그인 해보니 이러이러한 에러가 떴어요! - △

FE : api/~~/login 으로 login, password 값 담아서 post 요청 보냈는데 ~~~한 에러가 돌아옵니다. 확인 부탁드려요 - O

에러 등 문제상황이 생겼을 땐 최대한 모든 정보를 알려주세요! 그래야 원인을 찾기도 쉽고, 시간 낭비도 피할 수 있습니다. 이건 백엔드뿐 아니라 동료 개발자에게도 물론 적용되는 사항입니다.

2. 요청 사항이 있을 시에는 정중하게, 존중하며

위험한 생각 = 이거 하나 바꾸는게 어렵나?

우리도 잘 알잖아요. 하나 바꾸는게 어렵고 귀찮은 경우가 많다는거..
넘겨주는 값, 넘겨받는 값 등 수정이 필요해 보일 땐 1에서와 같이 어떤 이유로, 어떻게 바꾸면 좋을 지 상세하게 부탁해보도록 합시다. 또한 개발자 간 의사소통에서는, 명확하고 공식적인 용어를 사용하여 착오가 없도록 합시다. API는 프론트와 백엔드 간의 "약속" 입니다.

🎨디자이너와의 협업

다들 개발을 배우는 요즘이지만, 대부분의 사람들에게 개발은 어렵고, 낯선 영역입니다. 디자이너와 협업 시에는 이 점을 명심하고 들어가면 좋을 것 같습니다!

1. 이해하기 쉬운 용어를 사용하자

백엔드 개발자와의 협업에서 공식적인 개발 용어를 사용했다면, 이젠 비유를 통해 설명할 때입니다. 디자이너가 어떤 요청을 했을 때

개발하기 힘들어서 안돼요
렌더링 이슈도 있고 마땅한 라이브러리가 없어서 구현하기 힘들 것 같아요

이런 식으로 얘기하면 능력이 없다거나, 예의가 없다고 뒷담화를 들을 수도 있겠죠? 객체에 대해 배울 때 붕어빵에 비유했던 것처럼, 우리도 비개발자가 알아듣기 쉽도록 설명해줍시다.

2. 존중, 또 존중

프론트엔드 개발자는 디자이너가 만든 화면을 토씨 하나 빠짐없이 그 대 로 퍼블리싱하도록 합시다. 개인의 의견을 넣어 수정, 추가, 삭제 등의 행위를 하는 것은 디자이너를 무시하는 행동이며, 좋은 프론트엔드 개발자가 아닙니다.
그럼에도 불구하고 정말 이건 아니다 싶거나, 사정상 수정이 필요할 때가 있습니다. 그럴 때는 지겹도록 말했듯, 정중하게 물어보도록 합시다.

너무 프론트엔드 개발자가 상대적 약자(?)인 느낌으로 이것저것 적은 것 같은데요.
그래서 이번에는 프로젝트 경험이 적은 디자이너에게 요청하면 좋을 것
들을 알려드리려고 합니다.

1. 컬러 팔레트, 자주 사용되는 컴포넌트(ex.버튼) 따로 빼놓아 주세요!

페이지에서 자주 사용되는 색, 컴포넌트들을 미리 피그마 한 곳에 빼두면, 프로젝트 초기 설정 단계부터 색상을 변수화시키거나, 컴포넌트를 미리 만들어 두기 편하겠죠? 한 번 요청해보도록 합시다.

2. 여러 플로우에 따른 디자인 모두 만들기

그런 경우가 있었습니다.

// 화면에는 좋아요 버튼이 있는데 빈 좋아요 버튼만 있고 눌러진 좋아요 버튼은 없는 경우
// 로그인, 회원가입 중 누락된 입력 값에 대한 알림 텍스트 디자인이 없음

이와 같이 디자이너도 사람이다 보니, 사소한 것들을 빼먹는 경우가 발생합니다. 이런 경우를 미연에 방지하기 위해 한 번씩 미리 말씀드려 요청해보도록 합시다.

마지막으로 VSCode를 쓰시는 분들께 팁 하나 드리자면,
피그마에는 개발자 모드가 있으며, VSCode에도 피그마 익스텐션이 존재합니다.

저 버튼을 눌러 개발자 모드를 활성화시키면

위와 같이 값들만 따로 보기 편하게 활성화됩니다!

또한 VSCode에서도 피그마 익스텐션을 설치하시면

위와 같이 피그마를 보면서 개발할 수 있습니다. 근데 이건 듀얼 모니터 쓰시는 분들에게 권장드려요