회고록

프론트엔드 스쿨 1기 마지막 프로젝트.
3주간 진행된 프로젝트에대한 회고를 들어봅시다.

팀 포니테일즈는 🦦(Dada), 🦎(Benza), 🐋(Won5), 🍑(dee) 4명으로 팀을 이뤄져있다. 3주간 Vanilla JS로 프로젝트를 진행했다. 코로나19의 영향으로 여행에 대한 니즈가 높아진 상황이다. 또한, MZ세대를 중심으로 ‘기록'이라는 가치가 회자되어 ‘블로그 첼린지’, ‘독립 출판' 등 트렌드가 지속되고 있다.

이러한 시대에 맞추어 팀 포니테일즈는은 여행 일정표를 만들고 기록하며 공유할 수 있는 여행 커뮤니티 “HelloWorld”를 개발 했다. 팀장 🍑의 주도로 프로젝트 초기 기획 단계에서 설정한 최우선 작업을 성공적으로 마무리 했다고 전해졌다. 초기 기획부터, 디자인, 개발 설계부터 구현까지 모든 팀원이 적극적으로 참여했으며 SPA, CBD 개발 방법론으로 프로젝트가 진행되었다.

팀 포니테일즈 4인의 프로젝트 회고를 들어보자.

---

😆 프로젝트가 끝났는데 소감은 어떤가요?

🦦: 무언갈 끝낸다는 것은 언제나 시원하기도 하고 아쉬움도 남는 것 같다.

두 달 반 동안 난 얼마나 성장했는지 알아볼 수 있는 척도가 된 프로젝트다. 다른 동기보다 많이 부족한 상태에서 시작했기에 스스로의 성장에 집중해 나아가기보단 빠른 시간 내에 성장하지 못하는 것에 많은 좌절감을 느꼈었는데, 프로젝트가 끝난 시점에, 다른 이들과 비교하기보단 ‘처음의 나’를 생각해보면 그래도 꽤나 발전했다. 처음에 느꼈던 코딩에 대한 부담보다는 재미를 느낄 수 있었다.

물론 그 배경엔 배려해주는 동기들과 팀원들이 있었기에 가능했다. 내 부족함을 조금이라도 탓하는 이가 있었다면 코딩이 재밌는 것이구나 라는 것을 느끼지 못했을 것 같다. 느리더라도 어제의 나보다 발전한 오늘의 나를 기대할 수 있게 한 프로젝트였고, 더 열심히 해서 도와준 동기들처럼 잘하고 싶다는 욕심도 생겼다. 코딩, 힘들지만 즐거운 것.

🦎: 시원함 조금에 아쉬움은 큽니다.

자바스크립트 강의 초반 아무 것도 구현하지 못하고 땀을 삐질삐질 흘렸을 때를 생각하면 강의가 2달 반이 지나 끝나는 지금 개인적으로 성장을 했다는 게 체감이 되어서 어느 정도 뿌듯하기도 합니다. 이번 프로젝트를 통해 SPA, CBD에 대한 사상과 동작 방식을 통해 프론트 엔드 개발에 시야가 넓어졌다고 느꼈어요.

하지만, 1달 동안 책을 읽으면서 배웠던 내용들을 잘 활용 하지 못하는 제 모습을 자주 발견할 수 있어서 아쉽습니다. 특히, Date 객체를 다루는 부분, 이벤트 헨들러 this 바인딩에 관한 부분에서 생각지 못한 어려움을 겪기도 했으니까 말이죠.

강사님이 자주 하시는 말씀처럼 왕도는 없고 기초가 가장 중요하다는 말을 다시 한 번 가슴에 새기는 계기가 되었습니다.

🐋: 프로젝트와 수강 커리큘럼이 동시에 마무리되어 아쉬움이 큽니다.

처음 기획했던 기능을 모두 구현하진 못했지만 기획 발표 후 강사님의 피드백으로 우선순위를 한 번 더 생각하게 됐고 이후 새로 목표한 주요 기능은 구현해 뿌듯합니다.

하지만 여기서 멈출 순 없죠~ 팀원들과 다 함께 시간을 더 투자해 프로젝트의 최종 완성을 향해 달리기로 해 끝났지만 끝나지 않았습니다!

🍑: 주어진 시간 안에 완벽은 아니지만 90%이상의 목표를 달성하여 뿌듯합니다.

팀원들과 의견을 나누는 것이 프로젝트 달성하는 데 큰 도움이었습니다. 프로젝트 시작할 때부터 팀원들과 계획을 세우고 중간 작업을 체크하면서 목표를 조정해나갈 수 있었습니다. 하지만 처음에 기획했던 부분이 남아있고, 팀원 모두가 완성에 같은 뜻을 두고 있기 때문에 조금 더 힘을 내서 완성도를 높여보겠습니다.

😲 프로젝트를 하면서 좋았던 점, 앞으로 유지해야겠다고 느꼈던 것은 어떤 것이 있나요?

🦦: 좋았던 것은 혼자 했다면 이런 퀄리티로 만들어낼 수 없었을 것 같은 프로젝트를 완성했다는 것입니다. 하나의 부품을 만들어 프로젝트가 돌아가게끔 만들었다는 것에 나름의 뿌듯함을 느낍니다. 행여나 그것이 아주 작은 부품일지언정, 만들면서 배우는 것들이 있었고 동료가 만든 기능을 그 자리에서 바로 보고 설명을 듣는 것도 재밌고 배우는 것이 많았습니다.

앞으로 유지해야할 자세는 지금과 같이 부끄러움 없이 질문하는 태도인 것 같습니다. 과정 초반엔 다른 사람에게 누가되진 않을까, 너무 바보같은 질문이지 않을까 하는 생각 때문에 잘 물어보지 못했는데, 질문을 했을 때 항상 오픈 마인드로 답을 해주던 동기들 덕분에 이해가 안 되는 부분을 물을 수 있었고 내 것으로 만들 수 있었습니다. 이 용기와 태도를 잃지 않고 질문하고 기억하고 적용하며 성장하는 개발자가 되고싶다는 생각이 들었습니다.

또한 문서 작업을 통해 작업하는 사항에 관한 많은 것들을 세분화해 기록했는데, 개인 프로젝트를 진행하더라도 이렇게 기록하며 정리하는 습관을 들여야 겠다는 생각을 했습니다.

🦎: 배려심 많은 동료들과 3주간 즐겁게 프로젝트를 할 수 있어서 좋았습니다. 각자 의견을 낼 때 자신의 생각을 전달하기 위해 스스로 한 번 씩 정리하고 다른 사람의 의견에 귀 기울일 수 있는 수용적인 팀원들이어서 트러블도 딱히 없었습니다. 의사소통이 원활한 팀이었기 때문에 issue 사항이 발생했을 때 서로 즉각적인 피드백을 해줄 수 있어서 보다 효율적으로 프로젝트를 진행할 수 있었다고 생각합니다.

매일 아침 회의를 하면 회의록을 작성했는데 전일 했던 작업(Preview)와 해야할 작업(todo)을 우선 순위 분리해서 작업을 한 점이 프로젝트를 진행한 것이 적극적인 의사소통을 할 수 있던 창구가 될 수 있었습니다.

차후 다른 프로젝트를 할 때도 이번 프로젝트에서 느낌 의사 소통의 중요성을 상기해서 적극적인 의사소통을 할 수 있는 태도와 방법을 찾고 유지하도록 노력 해야겠습니다.

🐋: 지속적으로 함께 할 개발 동료를 이어준 좋은 프로젝트였습니다. 팀원들이 회의 시 각자의 의견에 대해 존중을 해줘 눈치 보지 않고 적극적으로 의견 표출을 할 수 있었습니다. 그리고 작업에 문제가 발생했을 때 다들 본인의 문제처럼 관심을 가지고 피드백을 줘서 문제 해결을 효율적으로 할 수 있었습니다. 여러모로 상대방을 배려하고 이타적으로 행동하는 팀원들을 보며 저도 조금 더 상대방을 배려할 수 있도록 생각하고 행동하고 말하도록 성장할 수 있었습니다.

그리고 “급할수록 돌아가라” 라는 속담이 생각납니다. 프로젝트의 마감 기한이 있었기에 시간 여유가 많지 않았지만 당장의 성과보단 더 넓고 더 멀리 보기 위해 매일 아침 시간 내서 회의를 하고 중간 중간 쉬는 시간도 가지며 서로의 진행 사항을 공유했던 것이 오히려 더 나은 결과물을 도출할 수 있었습니다. 앞으로도 빠르게 완성하는 것에 급급해 하지 않고 의사소통을 원활하게 하며 멀리 갈 수 있게 노력 해야겠습니다.

🍑: 팀원들이 다른 사람의 의견에 귀 기울여 주는 것이 가장 좋았습니다.

매일 오전에 회의하는 시간을 가지는 데 전체적인 일정을 조율할 때 모두 집중을 해주고 각자의 의견들을 정리해서 말을 해주었습니다. 또한 의견차이가 있을때 상대방의 의견을 차분하게 들어주는 점이 의견을 존중받는 느낌이 들어서 팀을 생각하면서 프로젝트에 집중할 수 있었습니다.

이런 부분을 상기하며 앞으로 프로젝트를 하면서 팀원의 의견에 귀를 기울이고 존중하여 즐겁게 개발하는 환경을 만들도록 하겠습니다.

😣 4명이 함께 협업하면서 어려움이 있었나요?

🦦: 어려움이라면 스스로에 대한 문제인 것 같습니다. 혼자 할 때는 원하는 결과물이 나오지 않더라도 나 혼자 짊어지고 간다면 된다는 생각이 있지만 팀 작업을 할 때는 부담감이 비교할 수 없이 커집니다. 제게 맡겨진 부분을 제대로 해내지 못하면 그 몫은 다른 이에게 짐이 될 수 있는 부분에서 그렇습니다. 그것을 제외하고 물리적으론 시간 관리라고 할 수 있는데요, 식사 시간을 맞춰야 하고, 쉬는 시간을 맞춰야 하고, 심지어 병원 갈 시간, 화장실 갈 시간 모든 것이 함께라는 범위 안에서 조절해야 하는 것입니다. 사소하지만 쉽지 않았던 것 같습니다.

🦎: 가장 어려웠던 부분으로 용어가 통일 되지 않아, 의사소통에 피드백이 느렸던 부분이 생각 납니다. 특히, 여행 일정을 각각 trip-planner, trevel-schedule, itinerary로 부르고 있어서 코드를 보면서 회의를 할 때 한번에 눈에 안 들어오는 경우가 꽤나 있었습니다.

협업을 하는데 있어서 공통으로 주로 사용될 내용들에 대한 변수 명을 먼저 설계하는 것에 중요성을 다시 한 번 느낄 수 있었습니다.

저의 경우에 여러 화면에서 쓰이는 Date 객체를 생성, 수정, 삭제하는 DatePicker 컴포넌트 구현을 담당했는데, 날짜(시작일, 종료일 등)의 타입이 객체, 문자열 혹은 null으로 관리되는 경우가 생기게 되었고 그로 인해 생각지 못한 부분에서 type 에러가 많이 발생했습니다. 컴포넌트를 만드는 데 있어서 확장성 혹은 기획를 파악하고 정확한 스펙을 설정해야 더 사용성이 높은 컴포넌트를 만들 수 있겠다는 것을 느꼈습니다.

경험이 적은 것도 문제 였지만, 탄탄한 초기 설계가 협업을 하는데 있어서 가장 중요한 부분이라는 것을 크게 체감할 수 있었습니다.

🐋: 맡은 업무에서의 우선 순위를 정하는 일이 쉽지 않았습니다. 사실 우선순위를 고려하지 않았다고 표현하는게 맞을 지도 모르겠어요. 담당한 파트가 다른 팀원의 파트와 이어지는 경우가 많았는데 서로가 연결되는 부분을 우선 순위로 두지 않고 작업을 진행해 중간 중간 합쳐 테스트를 할 때 dataset이 맞지 않아 수정을 하는 경우가 많았습니다.
2~3번의 시행착오를 겪었지만 이후 회의 시간에 dataset을 정해 우선 순위를 바로 잡고 이후 원활하게 작업을 할 수 있었습니다.

그리고 convention에 적응하는 것이 어려웠습니다. 이번 프로젝트에서 Git Convention으로 commit 시 gitmoji를 사용했는데 commit시에 어떤 emoji를 사용해야 하는 지에 대한 추가적인 공부가 필요했습니다. 이후 적응하여 사용하다 보니 commit log를 볼 때 emoji만으로 commit의 목적이나 의도를 식별할 수 있어 뿌듯했고 다시 한 번 convention의 중요성을 알게 되었습니다.

🍑: 다른 팀원의 코드를 파악하는 것이 어려웠습니다.

Pair programming에서는 같이 작업을 하고 리팩토링할 시간도 충분했기에, 자연스레 여러 번 반복 학습을 하게 되었고 코드를 충분히 파악할 수 있었습니다.

그렇지만 이번 프로젝트는 CBD & SPA로 작업하면서 여러 개의 컴포넌트로 나누어져 있다 보니 전체 구조를 파악하고 하나씩 코드를 분석해야 했습니다. 그래서 매일 오전에 회의를 하며 각자 맡은 부분을 어떻게 코드로 구현했는지 설명을 듣고 어떤 오류가 있었는지 이야기를 나누며 서로의 코드를 파악했습니다. 또한 기능을 구현하면서 필요한 개념, 오류가 난 원인 등을 문서로 작성하여 다른 팀원들의 코드를 이해할 수 있도록 했습니다.

이런 부분 덕에 코드를 수월하게 파악할 수 있었으며 오류, 리팩토링 등을 할 때 어떤 부분을 고려해야 하는 지에 대해 생각하며 코드를 수정할 수 있었습니다.

🤔 CBD, SPA로 작업을 하셨는데 구체적으로 어떤 부분이 어려우셨나요?

🦦: 개념적으로 아는 부분을 코드로 구현하는 과정 자체가 어려웠던 것 같습니다. 컴포넌트를 나눠 조립해야 하는 과정이 생소했고, 컴포넌트를 나누는 기준 또한 많은 고민이 들었던 부분이었습니다. 이거 어떻게 해야되나 막연했던 부분들을 팀원들과 충분한 회의를 통해 맥락을 짚어가며 기획 단계에서 논리적 근거를 바탕으로 컴포넌트를 나눠 진행할 수 있었습니다.

상태 관리 또한 쉽지 않았습니다. 전역으로 관리하는 상태가 있지만 컴포넌트 내에서만 관리가 필요한 것은 컴포넌트 내에서만 관리하면 안되나 생각하기도 했는데 결국은 전역에서 관리해줘야 혼선이 생기지 않는다는 것을 깨닫게 되었습니다. 어느 정도의 통일성을 가져야 유지 보수가 쉽다는 것을 알게 되었습니다.

🦎: 렌더링을 컨트롤 하는 것이 가장 어려웠습니다.

main 페이지와, trip-planner-view페이지는 초기 렌더시에 서버에서 필요한 data를 받아와야하는 페이지 였습니다. data를 전역 상태에 추가하기 위해서 init() 메서드를 정의하고 , Component contructor에서 init() 메서드 실행하도록 구현 했습니다. 이때 전역 상태 변경이 일어나면서 re-rendering이 발생하게 되는데 발생하면서 다시 컴포넌트의 인스턴스를 생성하고 다시 init()메서드가 실행되게 되었습니다. 즉, 인스턴스 생성→init()메서드→전역 상태 변경→render()함수 호출→ 인스턴스 생성 → … 으로 무한 반복이 되었습니다.

저희는 이벤트 헨들러를 통해 문제를 해결하려고 했습니다. 하지만, window.location.pathname 변경과 새로고침 시 다시 DOM을 그릴는 것을 동시에 감지할 이벤트를 찾았지만 찾을 수 가 없었습니다.

그래서 3번째로 찾은 방법이 mutation observer를 사용하여 DOM 변경을 추적해서 server와 통신을 하도록 만들었습니다. 초기 데이터를 받아오는데는 문제가 없었으나 필요하지 않은 렌더링이 발생할 뿐이니라, google map API를 활용하기 매우 까다롭다는 문제가 발생했습니다. Google Map API가 초기 렌더시 Map을 그리면서 header와 Target Element에서 수십에서 많게는 수백번의 DOM 변경이 일어나는데 그때마다 re-rendering을 하게 되어 불필요한 요청을 무수히 많이 하게 되었고, 기능 동작도 무한 rendering으로 제대로 수행되지 않았습니다.

결론적으로 전역 상태에 window.location.pathname을 파악하는 상태를 만들어 초기 접근 시에만 init()메서드를 호출 하는 방식으로 문제를 해결할 수 있었습니다.

그저 SPA를 single-page-app으로 필요한 모든 정적 리소스를 최초 접근시 단 한번만 다운로드하고, 새로고침이 일어나지 않는다는 것만 얕게 알고 있었지만, 이번 프로젝트를 통해 Routing과 window.history API 개념을 더 깊게 알게 되었고 상태 변경 컨트롤에 대해서 알 수 있게 되었습니다.

🐋: 컴포넌트를 나누는 기준을 잡기 어려웠습니다.

처음에는 재사용을 하는가를 기준으로 일정, 세부 일정 등 render 자체를 map 메서드를 사용하여 부분과 여러 영역에서 사용되는 calendar 정도를 생각했고 재사용을 하기 위해 어디까지 쪼개야 하는가에 대한 고민을 했는데 회의 시간 얘기를 나눠보니 개인마다 컴포넌트를 나누는 기준이 같지 않음을 알 수 있었습니다.

컴포넌트를 나눌 때도 Presentational and Container Component Pattern, Atomic Design Pattern **등 디자인 패턴이 있다는 것을 알게 되었고 맹목적으로 어떤 패턴이 좋다라기보다는 각 각의 장점과 단점을 정확히 알고 적절히 디자인패턴을사용할 줄 아는 것이 중요하다고 생각되었습니다. 그리고 컴포넌트 구조에 따라 directory 관리를 함께**해 주는 것이 일관성있고 자연스럽다는 것을 알게 되었습니다.

평소 크게 관심을 가지지 않은 부분이었는데 디자인 패턴 설계에 대한 중요성을 알게 되었고 다양한 패턴을 경험하며 학습해야겠다는 생각을 했습니다.

🍑: 컴포넌트 첫 렌더링 시, 서버에 요청을 보내는 시점을 생각하는 것이 쉽지 않았습니다.

팀원들이 DOMContentLoaded 이벤트가 발생할 때 서버에 요청을 보내면 App.js가 첫 실행되는 시점에만 발생하고 컴포넌트의 새로운 인스턴스가 생성될 때 발생하지 않는다고 했습니다. 그래서 인스턴스가 생성되는 시점인 constructor에서 메서드를 호출하고자 했습니다. 그렇지만 서버 요청을 하고 그 결과 값을 store에 저장하게 되면서 다시 렌더를 호출하게 되고 무한 루프에 빠지게 되었습니다. 그렇게 팀원들이 다른 방법을 시도하게 되었지만 일관성 있게 작동하지 않는 문제가 있어 다시 원점으로 돌아가게 되었습니다. 마지막으로 render함수 안에서 서버에서 요청한 데이터로 바로 domString을 만들고자 했습니다. 하지만 이 부분도 서버에 계속 요청하게 되어서 다른 방법을 생각하게 되었습니다. 그러다 강사님께 이 방법에 대해 상의하게 되었고 서버에 요청을 보내는 것도 상태값으로 관리를 하여 현재 path와 상태 값을 비교하여 렌더 하게 되었습니다.

이것을 구현하면서 프레임 워크에서 생명주기가 이런 점 때문에 필요한 거구나라고 느끼게 되었습니다. cbd, spa의 원리에 따라 구현에 보면서 React, Angular 등의 프레임워크의 전반적인 흐름에 대해 이해할 수 있는 시간이 되었습니다.

🫠 어떤 부분이 이번 프로젝트에서 가장 아쉬우셨나요?

🦦: 제 실력이 팀원들과 비슷했다면 좀 더 적극적으로 의견을 내면서 보다 다양한 방법들을 두고 고민해볼 수 있었을텐데 아직은 그러지 못해 많은 아쉬움이 남습니다. 같은 맥락으로, 팀원들에 비해 느리다보니 충분히 고민할 시간이 부족해 공동 작업 부분에서도 기여를 많이 못한 부분이 아쉬움으로 남습니다. 하지만 작은 기여임에도 의미있는 시작이라 생각하고 앞으로 성장해 나아갈 것입니다. (어디서가 됐든)다음 팀 프로젝트시 팀원들에게 도움이 되며, 공부한 지식을 바탕으로 보다 나은 방향을 도출해내는 프로젝트를 하고 싶다는 생각이 들었습니다.

🦎: 많은 아쉬움들이 있었지만, 바로 생각 나는 아쉬움은 이런것들이 있습니다.

기획 단계에서 webSocket을 사용해서 실시간 여행 일정 co-operate 기능을 핵심 기능으로 설정 했습니다. 하지만 3주라는 기간 동안 우리가 배운 부분 이외의 영역을 새로 공부하면서 작업하기에는 무리가 있었습니다. 그래서 초기 작업 우선 순위 설정 부분에서 co-operate기능 등 webSocket을 활용할 부분 추후로 미뤄졌습니다. webSocket이 사용자 편의적 측면에서 편리함을 제공하고 여러 컴포넌트에서 쓰이기 때문에 이번 프로젝트를 끝까지 완성하는 단계에서 webSocket을 적용해 보도록 공부해야겠습니다.

가장 난이도가 높다고 평가 되었고 핵심 기능 중 하나였던 DnD 부분 코드에 직접 기여하지 못 한 것이 아쉬움이 남습니다. 각자 정해진 부분이 있었고 제가 담당한 부분이 늦어지면서 코드에 기여할 수 있는 시간적인 여유가 부족했습니다. 개인 프로젝트로 DnD 부분 예제 코드를 작업 해보면서 기술적인 아쉬움을 극복하도록 하겠습니다.

담당 했던 Google Map API를 계속 rendering 되지 않도록 하기 위한 방법을 찾지 못한 것에 찝찝함이 남습니다. Google map이 이벤트가 발생하면서 계속 렌더링이 되게 되는데, map을 계속 새로 그리는 것이 사용자적 측면에서도 사용성이 좋지 않을 뿐아니라 API 요청 횟수도 무수히 증가하기 때문에 성능적으로도 좋지 않습니다. Map을 새로 그리지 않고 사용성을 높일 수 있는 방법을 더 고민 해봐야겠습니다.

마지막으로, 구현에 힘을 들일 수록 기록에 소홀해지는 것이 아쉬웠습니다. 구현이 비교적 급하지 않던 초반에는 이슈 사항, 고민한 점, 배운 점 등을 기록했지만, 예상 외의 문제들을 발견하고 해결하면서 심리적으로 조금씩 부담이 쌓일수록 기록하지 못했던 아쉬움이 남습니다. 급해도 즉각 즉각 기록하는 습관을 만들어야겠습니다.

🐋: 구현할 수 있다고 생각했던 부분들이 아직까지 이전 코드나 구글링의 도움을 받지 않고 코드 짜기에 어려움을 느껴 아쉬웠습니다. 이전 페어프로그래밍에서 로그인, 회원가입, 캘린더 등 학습했던 부분들이 프로젝트 내 많이 포함되어 있었는데 직접 구현을 하려고 하니 완벽히 숙지가 되지 않았음을 깨달았습니다.

로그인, 회원가입의 경우로 얘기하자면 전체적인 스키마 구조는 숙지가 되었지만 express로 구현한 server.js 와 연동하고 jwt 토큰 관련의 경우는 많이 미흡하다는 것을 알게 되었습니다.

이번 프로젝트를 통해 제가 알고 있는 부분과 모르는 부분에 대해 다시 한번 생각할 수 있었고 프로젝트 종료 후 반복적인 학습을 통해 모르는 부분을 꼭 저의 코드로 만들겠습니다.

🍑: 4명의 팀 단위로 작업을 하는 기회가 많지 않은데 다양한 방법으로 작업하지 못한 것이 아쉬웠습니다. 3주 동안 프로젝트를 하면서 1인, 페어, 전체 팀으로 나눠서 진행해보았지만 장점도 있었지만 아쉬움이 있었습니다.

1인 작업은 기능에 대해서 혼자만의 고민을 해보는 시간이 주어져 좋았지만 개인 작업이다보니 다른 팀원의 코드를 파악하기 위한 시간이 필요했으며 기능의 난이도를 고르게 분배하는 것이 어려웠습니다.

페어로 리팩토링을 진행했을 때는 다른 팀원이 어떤 생각으로 기능을 구현했는지 자세하게 알 수 있었습니다. 또한 다른 시각으로 문제를 바라볼 수 있었습니다. 하지만 리팩토링의 시간이 많지 않았던 터라 페어 팀을 돌려가면서 전체 코드에 대해서 세세하게 파악하는 시간을 갖지 못한 것이 아쉬웠습니다.

팀 작업은 jwt같은 개념을 러버덕하거나, 병합 단계의 오류를 해결하는 것으로 진행했습니다. 라이브 쉐어로 같이 코드를 보며 작업을 하거나 드라이버와 내비게이터의 형태로 진행하기도 했습니다. 다만 드라이버와 내비게이터의 경우 드라이버를 한 명으로 역할을 부여하니 집중력이 흐려지기도 했던 것 같습니다.

하지만 이를 계기로 협업에 도움이 되는 방법이나 시간 관리에 대해서 생각해보게 되었고 다음 팀 프로젝트가 있을 시에 적극적으로 적용해보고 싶습니다.

🫡 앞으로 어떻게 개발 공부를 하겠다는 생각이 들었나요?

🦦: 기록이 중요하다는 생각이 들었습니다. 어떠한 어려움을 겪었고 해결 방법을 정리해 놓는 것이 큰 자산이 될 것이기 때문입니다.

또한 단순히 구현에 치우친 개발보단 어떻게 해야 내 동료가 이 코드를 보고 쉽게 이해할 수 있는지, 효율적인 코드인지를 생각하며 짜야겠다는 생각이 들었습니다. 프로젝트시 팀원들과 서로에게 이해하기 쉽게 리팩토링하는 과정을 통해 더욱 많이 느꼈습니다. 그리고 어느정도 패턴에 익숙해지는 것 또한 중요하다는 것을 깨달았습니다. 내가 구현하고싶은 기능을 생각할 때 적절하게 익혀놨던 패턴을 꺼내어 쓰는 것이 중요하다는 생각이 들어서 더 많이 쳐보는 연습을 해야겠습니다.

🦎: 단기적으로는 앞으로 심도있게 공부할 예정인 React를 공부하기에 앞서 좀 더 SPA와 CBD 개발 방식의 원리를 파악하도록 노력해야겠다고 느꼈습니다. 왜 React를 사용하는지 vanilla JS에서 발생했던 rendering issue와 state관리, props drilling 등의 문제를 더 깊이 있게 파악하고 해결 방법을 고민해보려고 노력해야합니다.

필연적으로 계속 학습을 해야하는 개발자라는 직업을 선택한 만큼 좋은 공부 습관을 만들어야겠다고 느꼈습니다.

가장 중요한 것은 내가 모르는 것을 정확하게 알고 채워나가는 것이라고 생각합니다. 내가 모른다는 사실을 인지하면 즉시 조금이라도 기록하는 습관을 가지면서 공부하는 습관이 필요하다고 느꼈습니다. 평소에 알고 있다고 착각하던 지식들을 직접 마주하거나 동료들이 질문을 했을 때 당황했던 경우가 있습니다. 좀 더 스스로 겸손한 태도로 공부를 할 수 있는 자세를 가지고 끊임 없이 배우려고 노력해야겠다고 느꼈습니다.

🐋: 기록을 습관화하며 공부해야겠다고 생각했습니다.

저에게 기록은 습관화하는 것이 좋다고 당연하게 생각하면서도 막상 하기 쉽지 않은 일이었습니다. 혼자서 공부를 할 때는 어려움을 느꼈거나 알게 된 부분에 대해 제대로 기록을 남기지 않다 보니 같은 어려움을 겪어도 해결을 못하거나 심지어 그 어려움이 이미 겪었던 어려움인지도 인지하지 못한 경우가 있었으리라 생각합니다.

이번 프로젝트를 하며 포트폴리오를 남겨야 하니까, 프로젝트니까 당연히 남겨야지, 팀원에게 제 상황을 알려야 하니까 라는 이유로 처음에는 기록을 시작했습니다. 기록하면서 다시 한번 고민한 내용을 생각하고 어떤 해결 방법이 있을지 생각해 제가 어떤 고민을 했었는지 잊어버려도 기록을 보는 순간 기억이 났습니다. 팀원들을 위해서도 당연히 중요한 기록이지만 스스로를 위해 더욱더 중요하다는 것을 느꼈습니다.

🍑: 생각했던 것을 메모하는 습관이 필수라고 느꼈습니다. 코드 양이 방대해짐에 따라 내가 왜 이런 코드를 생각했는지, 왜 오류가 발생했는지 명확히 알 수가 없었기 때문입니다.

파이널 프로젝트에서 DnD 기능을 구현하면서 추가적으로 필요한 기능들이 있었습니다. 그에 따라 전역 상태에 관리해야 하는 상태가 늘어났고 코드를 파악하는 시간을 더 많이 소요해야 했습니다.

또한 기능 구현을 끝내고 문서를 정리하려고 하니 어떤 오류가 있었고 내가 어떤 식으로 해결했는지 잘 기억이 나지 않았습니다. 그러면서 자연스럽게 다시 공부하는 기회도 놓치게 되었습니다.

앞으로는 개발관련 탬플릿을 하나 만들어서 잘 정리해야겠습니다.