[TIL] 2주 프로젝트의 끝

Seungjae Han·2020년 11월 21일
0

2주간의 프로젝트가 완전히 끝나고 발표까지 했다. 프로젝트는 많은 것을 배운 기회였다. 내가 무엇이 부족한지에 대해 다시 알아보게 되었다. 협업을 어떤식으로 이끌어가야 할 지에 대해 자세히 배웠다. 웹에 대한 협업은 처음이다 보니 꼼꼼하게 초반 대화를 나누지 못했던 점이 아쉬웠고 배포와 관련된 이슈를 결국 마지막까지 풀지 못했다. 이제 느낀 회고를 정리해서 적어보려고 한다.

SR(Software Requirements)

팀이 편성이되고 SR을 먼저 시작했다. 우리 서비스는 2주에 적당한 서비스라고 생각됐다. 기사를 크롤링해오고 이 기사를 DB에 저장시키고 코인 거래소 API를 가져와서 띄워주는 방식 자체에서 크게 어려움이 있을 것이라고 생각 하지 않았다. 그래서 Front에서의 UI는 깊게 대화를 나누지 않은 상태로 알아서 진행하게 나두었고 내가 속한 Back에서도 API를 깊게 생각하지 않고 대략적으로 데이터의 Output만 제시한 상태로 참고해서 진행하자 하며 깊은 대화를 나누지 않은 상태로 일을 진행했다. 하루 이틀 지나 윤곽이 잡히고 완성된 상태라고 느끼며 모두가 만족했다. 일이 잘 진행되는 듯한 느낌을 받았을 때 버그가 생겼다. 프론트에서 받은 데이터가 우리와 피팅이 맞지 않고 authorization에서 우리가 생각하는 방식으로 진행되지 않아 코드를 수정했어야 했다. 서로 피팅되지 않은 상태이고 수정이라기 보단 리펙토링을 해야 될 수 있는 상황이였다. 결국 프론트와 백이 계속 버그에 걸리자 영역은 사라지고 모두가 같이 포지션 없이 일하게 되었다.
SR을 할 때는 프론트에선 모든 컴포넌트 단위를 생각해야 된다 느꼈다. "간단히 와이어프레임을 짜고 이렇게 만들자 "에서 끝나서는 안된다. React를 예시로 들어보자.
React에는 많은 컴포넌트들이 생성된다. 이 컴포넌트에서 무슨일을 해야되는지까지 SR 시간에 정해야한다. 코드를 치기전에 팀에서 같이 협업을 해나가는 과정, 그 과정에서 컴포넌트들이 어떤 일을 해야될 지까지 해야된다고 느겼다. 그래야만 버그가 생겼을때, 팀에서 어느곳이 바뀌어야 하는지 인지가 된다. 나만 그 잘못을 알고 있고 다른 팀원들은 그 버그를 알지 못한다면 결국 결론도 나혼자 내야하는 상황이 발생한다. Back에서도 마찬가지다. 처음 작성한 API가 맘에 들지 않고 그대로 나오지 않는 버그가 발생했을때 나혼자 그 코드들을 이해한 상태로는 팀들과 대화가 되지 않는다. 이런 이유로 SR은 깊게해야되고 시간을 많이 써야한다.
배포도 SR을 해야한다. 어느 방식으로 배포해야 될 지에 대해 생각해야된다. 우리는 AWS를 사용했지만 AWS를 잘 아는 사람이 없었다. 나혼자 공부를 해나갔고 이를 해결하기위해 나혼자 시간을 사용했다. 팀장인 내가 AWS에서 문제를 생각하게 되니 팀원들은 어떤점이 문제인지를 모른다. 내가 AWS에 대해 잘 아는 상태여도 다른 팀원들에게 무엇이 문제인지와 AWS가 어떻게 돌아가는지를 함께 대화 나눠야 다른 팀원들도 우리가 어떤 상태에서 문제가 생긴지를 안다. 그렇기 때문에 SR은 중요한 시간이고 코드를 작성하는 시간보다 더 소중한 시간이다. 몇 번을 강조해도 부족하다. SR은 그정도로 많이 해야한다.

HTTPS

우리는 결국 배포전까지 왔다. 하지만 SameSite문제로 크롬에서 쿠키가 삭제된다. 배포를 했음에도 가장 중요한 쿠키가 삭제된다. 이러면 Stateless의 웹은 로그인을 했는지 인지하지 못하게 된다. 그러면 이 쿠키를 삭제 하지 못하게 HTTPS로 통신을 해야 했다. 우리는 쉽게 이 과정도 해결이 될 거라 생각했지만 AWS를 이용해서 배포한 우리는 AWS를 잘 몰라 HTTPS로 통신을 하는 방법을 결국 찾지 못했다. 클라이언트 부분에서는 SSL이 적용됬지만 서버에서는 SSL이 적용되지 않아 그부분을 해결하지 못하고 프로젝트를 마무리했다. 다음 프로젝트때는 무조건 목표는 배포다. 아무리 잘 만들고 효율적이며 멋있는 웹이여도 배포하지 못하면 소용이 없다. 웹은 서비스를 만드는 것이고 결국 이용자가 필요하기 때문이다. 이렇기 때문에 배포하지 못한 점이 아쉽고 다음 기회에는 꼭 배포에 성공해야된다는 목표가 생겼다. 성공하는 방법에 대해 그리고 HTTPS에 대해서는 해결된다면 블로깅을 해야겠다.

프로젝트를 통해 배운점

팀장을 하며 너무 많은 점을 배웠다. 일단 팀원들이 코딩을 하며 생긴 버그들은 그 팀원에게 해결해주세요. 라고 끝내는 것이 아닌 모두가 알고있어야 한다. 그래야 서비스가 버그때메 막혔을 때 빨리 풀어 나갈 수 있다. 내가 생긴 버그도 난 스스로 해결하려고만하고 조금만 기다려 달라고 말했다. 이점에서 다른 팀원들은 우리의 프로젝트가 어느 점에서 문제가 있는지를 생각하지 못했고 우리는 일이 막히게 되었다. 잘 생각해보면 우리는 팀이다. 서로 팀의 일은 공유가 되어야하고 이슈에 대해 항상 이야기를 해야된다. 그게 협업이다.
워크플로우에 대한 고민도 많았다. 효율적인 git의 사용법에 대해 마지막에 알게되어 아쉽지만 그 git의 협업은 어마어마했다. 우리는 commit하는 법도 잘 몰랐고 branch의 중요도도 인지하지 못한 상태로 일을 진행했다. 위에 문제의 연장선상으로 우리는 버그가 생기면 git을 이용해서 같이 문제를 볼 수 있었다. 하지만 그렇게 진행하지 않고 나의 로컬에서만 문제를 풀려했다. 우리는 소통을 잘한다고 생각했지만 사실은 소통을 진행 못하고 있었다. 이점은 팀장으로 부족한 점이었다. 다음 프로젝트에서는 이 일을 무조건 적으로 풀어 나갈 것이다.
프로그래밍은 혼자 해나가는 것이 아니다. 이번 프로젝트는 규모가 크지 않았다. 하지만 규모가 크고 나혼자 해나 갈 수 없는 정도의 규모라면 모두가 같이 해야된다. 그때 우리는 코드의 규칙이 정해져 있어야하고 다른 사람들과 맞춰나가야 된다. 그래야 모두의 코드가 일관성이 있어 버그를 방지 할 수 있고 해결 할 수 있다. 이점을 많이 배울 수 있었다.

다음 프로젝트에 대한 나의 각오

나의 관심사는 프론트에 있다. 프론트는 직접적으로 이용자가 보는 곳이다. 그러므로 더욱 사용자에 맞춰저야 한다. 이점은 내 음악 취향에 비유해 말할 수 있다. 난 평소에 장범준과 빈지노를 좋아한다. 이들은 전혀 공통점이 없어보이지만 존재한다. 장범준은 아주 높은 고음을 내지 못한다. 하지만 음악을 듣는 소비자들의 마음을 공략하는 방법을 잘 안다. 빈지노는 아주 빠른 랩을 하지 못하고 스킬적으로도 남들보다 뛰어난 위치에 있지는 않다. 하지만 대중들의 귀를 즐겁게 하는 방법을 안다. 나또한 이런 개발자가 되고 싶다는 생각을 가지고 있다. 아주 스킬적으로 뛰어나고 세계에서 제일 효율적인 프로그램을 만들기 보다 나의 기술들이 소비자가 이용했을때 만족했으면 좋겠다. 그런 관점에서 다음 프로젝트들 부터 그리고 앞으로 나의 개발자의 삶에서는 이런 개발자로 성공해야된다는 생각을 가지고있다.
이런 개발자가 되기 위해서는 소비자의 입장을 잘 생각해주는 것은 기본이다. 그리고 넓게 많은 지식을 가지고 있어야 된다고 생각한다. 소비자가 원하는 것이 어떤 것인지 인지가 된 상태에서 내가 그 원하는 것을 못 만들어준다면 소용이 없다. 그렇기 때문에 항상 기술에 대한 공부를 해나갈 것이고 넓고 전문적인 지식을 소비자의 입장에 맞춘 개발자가 될 것이다. 다음 프로젝트는 소비자가 좋아하며 잘 만들었다는 평을 받도록 노력할 것이다.

profile
공부하는 개발자 재밌게 일하고 싶습니다.

0개의 댓글