1주차 발제를 하고 5일동안 새로 만난 팀원들과 미니 프로젝트를 진행하였다. 1주차이기 때문에 서로 어떤 기술을 공부하였는지 정확하게 알지 못한 상태에서 최대한 방어적으로 프로젝트를 설계하였다. 테크니컬한 기능을 구현하려고하기보다는 CRUD에만 집중하였고, 그결과 짧은 시간 안에 괜찮은 결과물을 만들었다. 그 과정에서 느꼈던 점을 적어보려고 한다.
프로젝트를 성공적으로 이끄려면, 중심을 잘 잡아야 한다.
한 집단은 여러 명의 개인으로 구성되어 있다. 서로 다른 환경에서 살아온 사람들끼리 합을 맞추려면 공통의 목표를 정하고 팀장은 그 목표에 대한 중심을 잃지 않으며 리딩을 하여야 한다. 나는 이번 프로젝트에서 팀장직을 맡았고, 기술적으로 무언가를 배워야겠다기보다는 팀원들의 일정을 체크하고 일을 진척시킬 수 있는 방법을 궁리하는데 더 많은 시간을 쓰었다. 일을 할 때는 독단적으로 보일만큼 단호한 태도를 취하였다. 그렇지만 그 이면에는 왜 그래야만 했는지 이유를 항상 설명하였다. 다행히도 팀원들이 나의 이유에 대하여 충분한 공감을 해주었고 서로 순항을 할 수 있었다.
한 번은 어떤 팀원이 에러를 마주하여 자신은 이 일과 맞지 않는 것 같다고 이야기를 하였었는데, 어떻게든 포기하지 않게 동기부여를 하였다. 왜냐하면 누구 한명이 나가면 팀의 중심이 흔들릴 수 밖에 없기 때문이다. 그리고.. 나도 그랬었던 적이 있었고 그때 포기를 하지 않았기 때문에 지금 이렇게 글도 쓰고 있는 것 아니겠는가. 에러를 친구로 생각했으면 좋겠다. 그 에러를 해결함으로써 사용자 경험과 개발자 경험은 한층 더 개선될 것이니까.
그럼에도 불구하고 팀원들에게 단호하지는 않은 태도를 보였으면 어땠을까 하는 아쉬움은 있다. 처음 팀장직을 맡아봤기 때문에 나도 이 모습을 처음 보았고, 지금 이 모습을 봤으니 앞으로는 더 개선할 수 있지 않을까 싶다.
JWT에 관한 단상
- 페이로드에 유저에 관한 DB 정보를 넣는 것도 하나의 방법이 될 수 있다는 피드백을 받았고 이에대해 공감하였다. 이 방법은 비밀키를 얼마나 빡세게 잡느냐에 따라 안정적일 수도 있고 불안정적일 수도 있겠다는 생각을 하였다.
- 유저id를 넣기보다는 다큐먼트의
objectId를 페이로드에 넣는게 인덱싱에도 유리하지 않을까 싶다. - 개인 프로젝트를 진행하면 Refresh Token을 사용해보아야겠다.
API에 대한 단상
- 개발을 하기 전 가장 중요한 부분은 와이어프레임을 구체적으로 짜서 UI에 대한 합의가 어느정도 이루어져야 한다는 것과 API 설계를 탄탄하게 하여 그대로 개발을 진행할 수 있게 만들어야 한다는 점이다. 물론 시간에 따라 기존 설계를 유연하게 변경할 수 있지만, 합의가 제대로 이루어지지 않은 상태에서 서버단 작업을 과연 할 수 있을까? 다음 프로젝트 때에는 이러한 합의를 확실하게 하고 진행을 해보아야 겠다.
- 프론트 엔드 개발자는 서버 개발자와 소통하여 프로덕트를 만들어야한다. 그러면 서버 개발자가 무슨 언어를 쓰는지 알아야하지 않겠는가? 아무리 서버쪽 작업이 싫다고 하더라도 REST는 뭔지, 웹개발 플로우가 어떻게 되는지는 알아야 한다고 느꼈다. 세명! 열심히 공부하자! 결국 프로젝트는 소통을 기반으로 하는거잖아?
Template Literal은 짱이다.
- 도대체 ES6 이전에는 어떤 방식으로 DOM조작을 하였는지.. 많이 힘들었을 것 같다. Interpolation의 혜택으로 인하여 프론트엔드 개발의 질이 더 편해진건 아닐까? 리액트에서나 썼던 삼항 연산자 표현식을 바닐라로 재현해보았으니 참 재밌을 수가 없었다. 나는 프론트엔드 체질이기는 한가보다.
