< 목차 >
0. 들어가며
1. PM 및 Design | 비효율적인 문서 관리 및 소통 방식 개선
2. FE & Design | 소통 방식 통일
3. 팀 전체 | 팀원 전체의 진행상황 파악이 잘 안 됨 → 팀 전체 <작업 진척도 페이지> 생성 요청
4. Design | 디자인 시스템에 들어가는 요소의 명확한 기준 부재 → 서로 다른 페이지 3개 이상 들어가면 디자인 시스템으로 들어가는 걸로 확정
5. BE | API 명세서 불일치 문제 해결 → 구체적인 수정 요청 후 백엔드와 협의하여 문서 일관성 확보
6. PM | 기획을 너무 러프하게 해옴 → 피드백 전달
7. 마무리하며
0. 들어가며
저번에 갖고 온다고 했던 협업 관련 트러블 슈팅을 들고 왔다 (주섬주섬)
프로젝트하며 대략적으로 작성을 해두었지만 막상 블로그에 올리려니 귀찮아져서 조금 미뤘다,,, 기술 트러블 슈팅은 바로 다음 포스팅으로 작성할 계획이다.
PM, Design, Back-end.. 모두 소통 문제가 있었다. 그리고 다른 직군에서 일의 방향을 잘못 잡으시면 내 일이 많아졌고, 일에서 실수가 있으셨으면 Front-end 개발 진행이 안 되거나 더뎌지는 경우가 빈번히 발생했다.
그 이야기를 시작해 보려고 한다.
당사자인 나는 좀 쉽지 않았지만 이걸 보는 분들은 편하게 읽어주시길 바란다,,
1. PM 및 Design | 비효율적인 문서 관리 및 소통 방식 개선
PM 및 Design 팀원과의 2가지 문제가 발생했다.
(1) PM이 FE와의 상의 없이 기능 추가 및 수정
⇒ FE와 먼저 상의 후에 기능을 수정하기를 요청했다.
(2) 기획 내용이 3개의 문서에 기록되는데 통일성이 없음
⇒ PM과 디자이너가 상의해서 IA(정보구조도)랑 프로젝트 기획안 중 1개를 택해서 통합해달라 요청했다.
기획 내용이 3개의 기획 문서(IA, 기획안, 회의록)에 기록되는데 각각 다른 내용이 추가되어 일관성이 없는 문제가 발생했다. 그로 인해 모든 팀원이 매번 문서 여러 개를 대조하며 체크해야 했다.
이 문제를 자각하자마자 얘기한 건 아니고 나름 몇 번 고민을 하다가
1. 이대로라면 일 진행이 너무 더뎌질 것 같고,
2. 가뜩이나 Front-end 문서 읽을 시간도 부족한데 불필요한 곳에까지 시간을 낭비할 수 없어서
요청드렸다. 위 대화 내용처럼 얘기하여 이 문제는 해결되었다.
2. FE & Design | 소통 방식 통일
각자 소통할 때 사용하는 메신저(Notion 댓글, Figma 댓글, 디스코드 DM 등)가 달라서 매번 전부 하나씩 확인해봐야 하는 비효율적인 상황이 발생했다.
긴급/미긴급 전달사항을 나누고, 소통 경로를 통일했다. FE & Design 회의 때, 소통 방식을 다음과 같이 확정했다.
(1) [안 급함] UX/UI 디자인 or 개발 중 생긴 전달/질문사항 공유 (✅ 따로 Notion 페이지 생성 ⇒ 'FE ↔ Design | 답해줘!')
(2) [급함] FE → Design, Design → FE 요청사항
: [디스코드 FE 채팅방] FE & Design 모두 알아야 하는 걸 의논할 때 (알아야 하는 사람 언급)
회의 끝내고 호다닥 만들어서 위 사진처럼 전달했다.
표 속성도 꼭 필요한 것만 추가하였다. 활발히 사용되었으면 했는데 내 바람대로 되었다.
프로젝트 도중에 캡처한 건데 생각보다 더 잘 사용되어서 기분이 좋았다.
+) 추가적으로, FE & Design의 현재 진행 상황, 앞으로의 일정 공유 및 파악이 안 되는 문제도 있었다.
⇒ Notion에 작업 상황 상세히 작성하고, 디스코드로 전달하는 것으로 결정했다.
- FE: FE 작업 진척도에 상세히 기록하고, 하위 작업이 끝날 때마다 디스코드 FE 채팅방에 전달
- Design: Design 작업에 상세히 기록하고, 하위 작업이 끝날 때마다 디스코드 FE 채팅방에 전달
모든 하위 작업이 끝날 때마다 전달한 것은 아니었고, 아래 두 상황 위주로 전달했다.
1. 누군가 요청했던 부분을 완료했을 때
2. 작업이 완료됐음을 전달해야 다른 직군이 작업할 수 있을 때
이렇게 한 덕에 일 평균 90분 이상 소요되던 소통 시간을 15분 내로 단축하는 효과를 볼 수 있었다.
매우 효율적,, 편-안
3. 팀 전체 | 팀원 전체의 진행상황 파악이 잘 안 됨 → 팀 전체 <작업 진척도 페이지> 생성 요청
FE 구현은 단계상 마지막이기 때문에 앞선 일정이 밀릴수록 일정이 엄청 빠듯해짐을 깨달았다. 즉, 다른 직군이 일을 늦게 하면 FE는 눈물을 머금고 밤새워가며 개발해야 한다.
전체 직군 및 각 팀원의 To-do가 보여지되, ‘큰 틀의 작업(상세하지 않은 To-do)’이 보이게끔 해달라고 요청했다. 팀원 모두가 뭘 했고, 뭘 하고 있는지와 각 작업의 마감 기한까지 공유되었으면 좋겠다고 하였다.
요청한 결과, '전체 작업 대시보드' 페이지가 생성되었고 각 팀원의 주요 작업 및 마감 기한이 공유되기 시작했다.
4. Design | 디자인 시스템에 들어가는 요소의 명확한 기준 부재 → 서로 다른 페이지 3개 이상 들어가면 디자인 시스템으로 들어가는 걸로 확정
디자인 시스템에 들어가는 요소의 명확한 기준이 부재해, 단 1번 사용해도 디자인 시스템에 들어가 있었다.
내가 디자인 시스템을 맡아서 구현했다.
나는 당연히 여러 번 쓰이니까 디자인 시스템에 들어가 있겠거니 하고 개발하고 있었고, 페이지 디자인이 완료되었다고 해서 Figma Draft를 봤다. 근데 디자인 시스템에서 개발한 컴포넌트가 단 1번 사용되는데도 디자인 시스템에 들어가 있길래 FE & Design 회의 때 이에 대한 얘기를 꺼냈다.
결론부터 얘기하자면 Design 팀원에게 이야기하여 서로 다른 페이지의 3군데 이상 사용되면 디자인 시스템으로 빼내주시길 제안드렸고, 받아들여졌다.
'디자인 시스템'의 정의에 대해 설명드렸고, 이미 디자인 시스템이 거의 완성된 것도 전달드렸다.
디자인 시스템에 대한 개념이 없으셨던 거였다.
1. 단 1회만 사용되는 컴포넌트는 Props를 전부 변경해야 했고,
2. 그게 아니더라도 디자인 시스템에 대해서 알게 되신 이후에 수정되는 컴포넌트가 많았다. (거의 전부였음)
솔직하게 화가 많이 났다.
수정되는 사항이 너어어무 많고 잦았기 때문이다. 도저히 개발 진도를 뺄래야 뺄 수가 없었다.
난 Front-end이고, Design에 대해 배운 게 없음에도 불구하고 나보다도 모르셔서 '이게 맞나?..' 하는 생각이 진짜 수없이 들었다.
더불어, '반응형'에 대해서도 잘 모르셔서 컴포넌트 수정사항이 또 늘어난 것은 이 이후의 일이었다..
5. BE | API 명세서 불일치 문제 해결 → 구체적인 수정 요청 후 백엔드와 협의하여 문서 일관성 확보
Postman 요청 데이터와 Notion API 문서 간 내용 불일치로 개발 진행에 어려움이 발생했다.
문제는 다음과 같았다.
1. 요청 데이터와 문서 간 필드 차이가 있음
2. 일부 요청 예시 누락 및 불완전한 문서 작성이 존재
Postman으로 준 요청 데이터 참고하라고 해서 그것도 보고, Notion API 명세서도 봤다.
둘 다 일관성도 없고 작성하다 만 부분도 있었다. 작성하다가 만 부분이 꽤 있기 때문에 더 헷갈려서 뭘 어떻게 질문해야 할지 몰라, 시간을 좀 썼다.
더 자세히 얘기하면,
1. Notion은 Request 예시가 없는 것도 있고, 내용이 다 작성이 안 돼있는 부분이 존재
2. Postman 참고하라셔서 전에 주신 JSON이랑 비교하는데 Notion 예시랑 다른 부분이 많음
Notion상에선 요청을 body로 하라고 적혀 있었는데 Postman에선 params로 요청하는 예시가 있다거나 요청하는 주소(/image/request로 요청하라고 했는데 /image로 요청하는 걸로 돼있음)가 아예 다르다거나 하는 식이었다.
내가 백엔드를 잘 아는 게 아니라서 내 잘못인가 하고 3일을 계속 코드만 수정하면서 보내기도 했었다.
이 계기로 인해 Java 과외를 시작하게 된다.
해결은 다음과 같은 방법으로 했다.
1. 실제 API 응답값과 문서를 비교하여 차이점 정리
2. 구체적인 수정 요청 후 백엔드와 협의하여 문서 일관성 확보
위 내용처럼 문서의 일관성을 위해, Back-end 측의 실수를 보강하기 위해 문서를 수정해주시길 간곡히.... 부탁드렸다.
6. PM | 기획을 너무 러프하게 해옴 → 피드백 전달
솔직히....... 이것도 화가 진짜 너무 많이 났다.
1. 원래는 기획자가 없으니 PM이 해와야 하는 모든 페이지 및 기능의 기획을 팀원 모두와 함께 함 + 기획만 한 달 동안 함
2. 2차 데모데이 발표가 목전인데 늦어진 다른 직군의 일정으로 인해 FE의 일정이 쪼들리고 있었고, 확인해야 할 문서도 많은데 심지어 러프하게 해온 기획을 일일이 피드백해야 했음
3. 3D 전시회 페이지 정도는 알아서 잘 해오길 바랐는데 퀄리티가 쉽지 않음
각자 1명분의 일만 해도 수월할 텐데 다른 직군의 팀원까지 알려주며 프로젝트를 하니 지치기도 했다.
웬만하면 상냥하게 말할 텐데 인내심이 마이너스를 향해 달려가고 있어서 다소 딱딱하게 얘기했다.
그럼에도 불구하고 '문제 - 해결책' 엮여서 전달드렸는데 날카롭게 느껴진다고 하셔서.. 음.. 할 말은 많았지만 하지 않았다.
7. 마무리하며
'그럴 수 있지..' 하다가 '아니, 그럴 수가 있나?!'를 반복한 프로젝트였다.
우여곡절이 꽤 많았지만 그래도 잘 마무리되었다.
공식 일정이 마무리됨과 동시에 다른 직군과의 협업도 마무리했고, 3D 전시회 페이지는 Front-end끼리 구현하는 것으로 확정하였다.
그래도 협업을 하니 기존에 Front-end만으로 이뤄진 팀 프로젝트, 그리고 나 혼자 했던 개인 프로젝트와는 완전히 달랐다.
크게는 아래 4가지가 많이 달랐다.
1. 프로젝트 기간 자체가 오래 걸림
2. 다양한 부분을 함께 논의하고 결정해야 함
3. 다른 직군의 일 처리가 늦거나 문제가 생기면 Front-end에게 직결됨
4. 소통 방식을 많이 맞춰가야 함
그리고 앞서 얘기했지만, Back-end 공부를 해야 됨을 아주 절실히 깨달았다. Full Stack은 선택이 아니라 의무였음을 알게 되었다. 오히려 좋아
다음은 '기술' 문제 해결을 가지고 오겠다!
'[Front-end] 개발자 공부' 카테고리의 다른 글
| 팀 프로젝트 | 혼란했던 '기술' 문제 해결 (1) | 2025.03.09 |
|---|---|
| 트러블 슈팅 | 405 Method Not Allowed Error 해결 (2) | 2025.02.09 |
| 2024년 회고 | "요즘 뭐 하고 살아?" (방황과 새 시작) (4) | 2025.01.07 |
| Next.js에서 국문/영문 폰트 전역으로 설정하기 (+ next/font 사용) (2) | 2025.01.02 |
| Storybook 설치 및 세팅 방법 (1) | 2025.01.01 |