1. 다이어트 챌린지 프로젝트
사실(fact)
4명의 팀원들이 2주라는 짧은 시간 안에 기획/개발/배포까지 완료해야 했다.
모두가 프론트엔드를 희망했으나 나와 팀장이 백엔드를 맡게 되었다.
프론트엔드를 지망한다고 해도 백엔드 또한 할 줄 알아야 한다고 생각하기 때문에 나는 오히려 잘 됐다고 생각했다.
짧은 시간 안에 프로젝트를 완벽히 끝내야 한다고 생각에 모든 팀원들이 초조해했다.
하지만 프론트엔드 팀원 한분이 적극적으로 팀을 이끌어주면서 체계적으로 진행되기 시작했다.
나 또한 적극적으로 의견을 내세우면서 백엔드의 전반적인 작업 흐름을 이끌게 되었다.
첫 1주는 기획과 배포를 수행했고, 자동 배포까지 시도하다보니 수많은 에러를 접하게 되어 힘들었지만 주말동안 열심히 원인을 찾고 문제를 해결해 팀원들의 신뢰를 얻게 되었다.
git을 이용한 코드 관리에 익숙하지 않다보니 혹시나 실수를 해 시간을 지체하게 될까봐 다른 팀원이 자신이 맡은 기능의 코드를 내게 넘기고, 나는 그 코드를 검수하고 잘못된 코드는 수정하고, 내 코드에 합치는 식으로 진행하게 되었다.
제일 힘들었던 부분은 크게 3가지로 친구 관계를 정의하는 모델을 짜는 것과 multer를 이용한 사진 업로드 기능 구현, pagination 구현이었다. 특히 사진 업로드 기능과 pagination 기능은 프론트와 백엔드가 함께 고려해야 할 것들이 많다보니 다른 기능보다 좀 더 시간이 걸렸다.
하지만 개발을 하면서 가장 큰 문제는 기획을 치밀하게 하지 못해 api의 내용이 계속 자잘하게 바꼈다는 것이다.
그래서 프론트엔드 팀원들이 테스트를 하는 데에 큰 불편함을 느꼈다.
2주간의 노력 끝에 우리 팀은 무사히 프로젝트를 완성했고, 발표까지 마무리를 했다.
하지만 프로젝트 발표 결과는 그닥 좋지 못했다.
평가단 엔지니어분들께서 css에 대한 아쉬움을 많이 언급하셨기 때문이다.
사실 우리 팀은 기능을 완성하는 데에만 너무 초점을 맞춰서 사이트의 외관에는 많은 신경을 못 썼다.
그래도 적지 않은 시간에 친구 기능과 사진 업로드 기능까지 구현한 것에 대해서는 좋은 평가를 받았다.
느낌(Feeling)
프로젝트를 진행하면서 답답함, 초조함, 뿌듯함, 재미, 짜증, 죄책감 등 다양한 감정의 소용돌이 속에 이리 치이고, 저리 치이는 느낌이었다.
교훈(finding)
기획의 중요성을 깨달았다.
팀원들과의 원할한 협업을 위해서는 api의 변화를 최소화해야 한다.
의사소통의 소중함을 느끼게 되었다.
팀원들과 매일 아침마다 회의를 하고 서로 아쉬운 점, 잘한 점을 전달하면서
오해를 풀거나 서로에 대한 고마움을 표현한 것은 전반적인 팀 분위기와 프로젝트의 원할한 진행에 있어 큰 도움이 되었다.
원방향이 아닌 쌍방향 협업을 해야했다.
내가 백엔드 작업의 주 관리를 하다보니 다른 백엔드 팀원의 주도성이 떨어트린 것 같다.
어쩌면 너무 내 위주의 진행이 아니었나 반성하게 되었고, 다른 팀원의 개발 기회를 뺏어버린 것만 같아 약간의 죄책감을 느꼈다.
로직을 짤 때 메모가 중요하다.
특히 친구관계 로직을 짤 때 노션에 깔끔히 정리하면서 사고의 흐름을 볼 수 있어서 코드를 짜는 데 수월해짐을 느꼈다.
향후 행동(Future action)
꼼꼼하게 기획하고, 솔직하면서도 예의바르게 소통하고, git을 적극적으로 이용한 코드 관리를 통해 쌍방향으로 협업하고, 전 팀원들이 주도적으로 프로젝트에 임할 수 있도록 팀 분위기를 조성할 것이다.
피드백(Feedback)
- 깃헙의 마일스톤 기능을 이용해 업무의 진척 사항을 시각화했으면 더 좋았을 거 같다.
- multer 말고 aws s3를 이용하여 이미지를 업로드 하는 방식이 더 바람직한 것 같다.
- 새로고침시 로그인 풀림 현상이 일어나는데, 로그인 정보를 웹 브라우저 상에 저장하여 로그인을 유지하는 방법을 알아봐야겠다.
- 디비 테이블 컬럼 중 lastPostId는 굳이 안 만들고도 친구들의 마지막 게시글 id를 조회할 수 있는데 이 부분은 나중에 다시 정리해야겠다.
2. 인포마켓 프로젝트
사실(fact)
4주간 4인이 진행하는 파이널 프로젝트이며, 이전 미니 프로젝트보다 폼이 훨씬 크기 때문에 기획 단계에 많은 시간이 소요됐다.
나는 이때 프론트엔드를 처음으로 맡은 것이기 때문에 자신감이 많이 떨어진 상태였다. 하지만 다른 프론트엔드 팀원이 경력자였고, 기획 단계에서 매우 적극적인 태도를 보였기에 프로젝트가 무사히 끝날 수 있을 거라는 믿음이 생겼다.
문제는 기획 단계 이후부터였다. 기획을 하다보니 사이트의 범위가 우리가 4주안에 할 수 있는 수준을 넘어섰고, 우리는 2주차 초에 범위를 축소하는 방향으로 급히 수정하게 되었다. 그런데 그 뒤로 프론트엔드 팀원의 개인 사정으로 인해 회의에 참석하지 못하거나, 개인이 맡은 업무 수행이 더뎌지면서 내 업무에도 차질이 생기기 시작했다.
나는 이 과정에서 상당한 스트레스를 받게 되었다. 기획부터 업무 분배, 리액트 초기 세팅까지 마친 이후부터 협업이 거의 불가했기 때문이다. 우리는 팀 규칙으로 서로 모르거나 막히는 부분이 있으면 솔직하게 도움을 요청하거나 의견을 전달하기로 정해놨는데, 사실상 프론트 팀은 대화가 잘 되지 않았다.
프론트 팀의 저조한 진행률로 인해 백엔트 팀에서도 불안을 내비쳤고, 참여율이 낮았던 해당 프론트 팀원을 프로젝트에서 제외시키는 것이 어떠냐는 의견까지 나왔다. 하지만 이미 3주차에 접어든 애매한 시기이기도 했고, 미완성 작업들이 남아있었기에 그대로 진행하기로 했다. 사실상 나는 혼자 프론트를 맡은 것과 같은 상태였다.
개발 과정은 결코 쉽지 않았다. 어설픈 리액트 실력으로 구현이 까다로웠던 기능으로는 검색, 무한 스크롤, 페이지네이션, aws s3 사진 업로드 등이 있었다. 같은 정보가 중복되어 리스트에 나타나거나, 코드들이 동기적으로 동작하지 않는 등의 문제를 마주하게 되었다. 그리고 코드 효율성을 전혀 고려하지 않아서 중복 코드가 많았다는 것 또한 아쉬웠다. 하지만 개인적으로 css 레이아웃을 짜는 데 큰 어려움을 느꼈다. 이때 css 공부를 미리 해두지 않은 것을 후회했다.
중간에 또다른 팀원의 깃을 이용하던 중의 실수로 인해 서버쪽 최신 코드와 프론트 일부 코드가 날아간 에피소드도 있었다. 다행히 복구를 했으며 좋은 경험을 했다고 생각한다.
4주차쯤에도 프론트 기능 구현이 늦어지면서 css를 거의 막판에 벼락치기 하듯이 끝내게 되었다. 그래서 디자인적으로 부족함이 있었다.
나는 사실 별 문제없이 든든하게 뒤를 바쳐준 백엔드의 역할이 컸다. 개발 과정에서 서버 기능 구현이 일찍 끝나 테스트 하기 수월했고, 오류 발생시 백엔트 팀원의 깔끔한 코드로 인해 소통하기 힘든 시간대에도 원인을 알아내고 해결하는 것이 어렵지 않았다.
비록 발표날 모두의 부주의로 인해 매끄러운 진행이 되지 않았지만 무사히 프로젝트를 마무리할 수 있었다.
느낌(Feeling)
뒤로 갈수록 미완성인 프론트로 인해 프로젝트의 운명이 나에게 달린 것만 같아서 큰 부담감과 책임감을 느꼈다. 그러면서도 재촉하지 않고 기다려준 백엔드 팀원들에게 고마움을 느꼈다.
더 나은 기능들을 추가해 보고 싶은 욕심도 생겼다.
교훈(finding)
기획 단계에서 의욕이 넘친다고 폼을 함부로 키우면 안 된다.
팀원을 믿는 것도 중요하지만 중간에 팀원이 올바른 방향으로 가는지 서로 관심을 갖고 어느 정도는 제재할 줄도 알아야 한다.
로직이 꼬이거나 구상이 어려울 때, 산책 중에 또는 침대에 누우면서 천천히 생각하다보면 어느새 문제를 해결할 아이디어가 나온다는 것을 알게 되었다. 즉, 문제를 깊게 파고들다가도 안 풀리면 전체 그림을 보는 과정을 반복하는 것이 효과적이었다.
때론 직설적인 것이 좋다.
서로 간의 예의를 차리는 것은 중요하지만 그로 인해 거리감을 두다 보면 정작 솔직하게 말하고 재빨리 해결해야 할 문제를 뒤로 미루게 된다.
향후 행동(Future action)
css 공부를 더 한 후 전반적인 css를 수정할 것이다.
리액트 라이프 사이클에 대한 이해가 부족하니 이 또한 다시 공부해야겠다.
피드백(Feedback)
- 팀원으로부터 내가 자신감이 부족한 것 같다는 피드백을 받았다.
나의 그런 태도는 다른 팀원들에게 신뢰를 주지 못할 수도 있다고 생각하니 앞으로 고쳐야겠다. - 리덕스로 상태관리를 했는데, 너무 많은 상태를 만들고 이 결과물들이 코드를 짜기 복잡하게 만든 것 같다. 상태 관리 오염을 주의해야한다.
- 비효율적인 코드가 많은 것 같이 중복을 제거하고, 기존 코드를 활용하는 방식으로 개발해야한다.
- 관리자 페이지를 만들었으면 더 좋았을 것이다.
