1. 문제 상황

• 백 엔드, 프론트엔드, 디자이너의 직군 별 소통이 잘 안되고 있습니다.
  • 계속해서 백엔드가 확정지으면 프론트가 따라가야하는 입장(ex) 기능요구사항 정의, API 명세)에 놓여 있습니다.
    • api 요구사항을 저희쪽에서 작성해도, 자의적으로 동작 방식을 지정하는 등의 일이 있습니다.
• 처음에 생각한 프로세스는 다음과 같습니다.
  • 우선 디자인이 확정되기전에 백엔드 개발자와 소통하면서 필요한 API 명세를 같이 얘기하고 정리
  • 디자인이 나오면 컴포넌트, UI 개발
  • 실제 API를 사용하면서 수정사항이 있다면 다시 백엔드 개발자와 소통
• 전체가 같이 이야기 할 내용과 특정 직군 끼리 이야기를 해야하는 부분을 잘 구별하지 못해 한 직군이 소외되는 경우가 있습니다. 특히나 기획 부분에서 디자이너 직군이 크게 비중을 차지했기 때문에 기능 정의와 데이터 정의나 디스플레이, UI 기능에 대해서 백엔드와 디자이너 끼리 회의하는 경우가 많았습니다.
• 페이지의 기능 명세의 정의가 각 직군 별로 흩어져 정리되었습니다. 기능 명세의 경우, 처음 프론트엔드가 페이지 별 요구사항을 작성했었는데 이 후 백엔드 쪽에서 다른 기능 명세가 따로 작성되었고 해당 기능 명세가 확정되면서 백엔드 관점의 기능 + api 문서가 만들어졌습니다.
  • api 요구 사항 문서를 작성했음에도 불구하고, 해당 사항이 제대로 반영되지 않고 관련 진행상황에 대해서 이야기를 안해주시고 다소 일방적인 방법으로 알려주십니다.
  • 반복해서 확실한 API 명세 확정 요청을 드리는데 그 말을 제대로 듣지 않고 error response와 success response 둘 중 하나가 빠져 있거나, 요청 형식이 없거나, response 값이 기능요구사항이나 API 요청 사항이 반영 안되어 있는 경우가 발생해서 프론트 측에서 json 형식과 기능요구사항, API 요청 사항들을 검토하며 맞는 json 형식인지 확인해서 백엔드 에게 요청하고 있는 상황입니다.

2. 문제 원인 파악

• 타 직군과의 이해도가 부족하여, 서로의 작업이 영향을 미치는 부분에 대한 인지가 부족하고, 일부 포지션끼리 논의할 내용과 다함께 논의할 내용이 잘 구분되지 못하는 상태인 것 같습니다.

  ex: api 명세를 작성하면 기능을 구현하지 못할 것 이므로, 개발 기간이 오래 걸릴 것이라서 명세 작성에 대한 우선 순위를 미루거나 작성을 하지 않을 것을 고려하게 됨

• 프론트엔드 쪽에서도 타 직군의 관점에서 잘 생각하지 못하여, 중간 포지션 역할을 제대로 수행하지 못하는 것 같습니다.

3. 여쭤보고 싶은 점

3-1) 백엔드, 프론트엔드, 디자이너 (일부 기획자의 포지션을 겸함) 의 직군의 프로세스가 어떻게 이루어지고 현업에서는 모든 포지션에서 소통이 어떤 식으로 이루어지는지 궁금합니다.

• 기획자 따로 존재, 전반적인 기획은 기획자가 잡고 디자이너 에게 전달 → 개발자에게 전달 개발 기간, 구현 가능 여부, 소스 배정 가능 여부 등의 스펙 검토 후 진행 하게 됨. 이후에는 크게 다르지 않음

  • 디자인 먼저
  • 클라이언트 착수
  • 백엔드 착수

  → 아예 백엔드에서 api 완성할 때 까지 기다려주는 경우가 대다수. 그래서 이런 이슈가 잘 생기지는 않음. but. 경쟁사에서 기능 출시했는데 따라가야한다-등의 촉박한 상황에서는 명세를 주거나 json을 요구하기 도 함.

• 다만 사이드프로젝트에서는 기간이 짧아서 (현직에서는 긴 긴간을 잡고 그 기간동안 스텝바이스텝으로 하지만..) 스텝바이스텝으로 못하고 병렬로 진행해야하기 떄문에 이슈들이 발생하는 것.

3-2) 협업에 있어서 백엔드 입장에서는 프론트엔드가 각 포지션 중간에서 어떤 역할(ex) 백 - 프에서 프가 백에게 어떤 요구 하는지)을 해야한다고 생각하시나요?

• 프론트에서 뭔가 처리 시에 상태에 따라 다르게 노출해야 한다면 (회원의) api를 어떻게 호출하는 지 (프론트한테는 응답ㄱ이 길어질 수 밖이ㅔ….) ⇒ 즉, 백엔드와 프론트의 의견 차이, api 구성 차이로 이야기를 많이 한다고 함.
• 백엔드 개발 하다보면 생각보다 여러 군데 연동 관계가 엮일 수 있음. 다 맞춰줄 수 없어서 최소한만 맞춰주는 경우 (즉 요구사항을 쉽게 들어줄 수 없는 경우가 많음)
• 성능 뿐만이 아니라 유지 보수과 같은 부분에서 생각할 부분이 많음.
• 항상 원칙 고수 x → 서로의 입장을 감안해서 협업하세요