WebSite(wiselyshave) Clone Project - Part.4 후기

안녕하세요. 이 포스트는 시리즈로 구성되어있습니다. 지난번 포스트까지가 전체적인 코드와 자세한 기술적 리뷰였고, 이번에는 후기를 작성해보겠습니다.

<1차 Clone Project 회고>
WebSite(wiselyshave) Clone Project - Part1. 시작&데이터 모델링
WebSite(wiselyshave) Clone Project - Part.2 Data Modeling & End Point Refactoring
WebSite(wiselyshave) Clone Project - Part.3 views.py Refactorin
WebSite(wiselyshave) Clone Project - Part.4 후기

1. 프로젝트 소개

프로젝트 소개는 part1 포스트에도 기록되어 있습니다. 이 클론 프로젝트는 단순한 일부 구현만 기능하는 것이 아닌 회원가입, 로그인부터 상품 보기, 장바구니, 구매(간소화) 전체를 클론 하는 것을 목표로 합니다.

애자일 개발 방식이기 때문에 일부 기능이 미처 구현되지 못할 수도 있습니다. 저희 팀은 국내 구독형 면도기 사이트인 와이즐리 면도기(https://www.wiselyshave.com/) 사이트를 대상으로 클론 프로젝트를 진행했습니다.

저는 Back-end 개발을 맡았고 Django에서는 Product, Order App을 담당하였습니다.

2. 사용된 기술

[Back-end]

• Python
• Django web framework
• Beautifulsoup
• Selenium
• Bcrypt
• Json Web Token
• AWS EC2, RDS
• CORS headers
• Gunicorn
• Unittest

[Front-end]

• HTML
• CSS
• JavaScript
• React.js
• styled-components
• Redux

3. 맡은 역할/파트

역할로는 PM(Product Manager)를 맡았습니다. 2주짜리 프로젝트에서 관리 역할을 맡는게 대단해 보이지 않을 수도 있는데, 한 번의 경험 유무가 크다고 생각합니다. 전체를 계속 봐야 하기 때문입니다.

파트는 백엔드 개발로 Django에서는 Product/Order App의 개발을 맡았습니다. 조금만 더 자세히 적자면 아래 그림의 붉은 박스로 표기된 부분이 제가 맡은 역할입니다.

그 외에 크롤링과 데이터 모델링을 진행하였습니다.(백엔드 팀원 한 명과 같이 진행)

4. 프로젝트 전체를 돌아보며

대학교 때도 분명히 개발을 주제로 팀플, 개발을 진행했었습니다. 그렇지만 많이들 겪는 것처럼 조별과제 잔혹사나 주먹구구식의 경험이 더 많았습니다. 위코드에서 진행한 프로젝트는 그 보다 기간이 비교도 되지 않게 짧은 2주의 프로젝트지만, 개발방식이나 회의는 기업과 동일하다고 느꼈습니다.(전에 회사에서 프로젝트로 잠깐 들어갔는데 그곳에서 스크럼 개발방식을 진행했었습니다.)

개인적으로는 무엇보다 PM의 역할을 해볼 수 있었던 게 값지고 감사한 경험이었습니다. 혼자 하는 것과 팀으로 하는 것이 다르지만 팀장으로 하는 것과 팀원으로 하는 것은 또 다른 것 같습니다. 이 프로젝트의 책임을 갖고 매니징 해야 하기 때문입니다.
매일 진행되는 스탠딩 미팅에서 어떻게 얘기해야 팀원분들이 힘을 얻고 효과적으로 회의할 수 있을지 고민하는 것은 정말 중요하다고 느꼈습니다. 개인적으로 옆 사람 칭찬하기를 한 번 해봤는데, 훈훈해지는(?) 효과를 얻었습니다.

이제 기술적인 부분입니다. 지나고 나서 안 아쉬운 게 없을 수 없겠다만, 아쉽고 또 아쉽습니다. 전체 발표에서도 얘기했었는데 좋은 데이터 모델링이 좋은 코드를 만드는 지름길입니다. 제가 맡은 프로젝트 사이트의 모델링이 다소 특이했기에 경험해볼 수 있었습니다. 첫 주는 오고 가면서 검색하고 계속 모델링에 대해서 찾아봤습니다. 어떤 게 효과적일지 고민하다 결국 프로젝트에 진행한 모델을 적용했는데 아쉽습니다.
그렇지만 오히려 복잡한 모델을 겪으면서 더 배울 수 있었다고 생각합니다. 동일할 수는 없겠지만 비슷한 기획을 할 때 이 시행착오를 녹여낼 수 있기 때문입니다.

어찌 됐든 결국 저는 프로젝트에서 사용하는 다소 복잡한 모델링을 적용했고, 시간이 부족하다고 느껴지는 조급함까지 더 해졌습니다. 그래서 관련 API를 이른바 막 코딩을 하게 되었습니다. 좋은 QuerySet인 select_related나 prefetch_related 같은 기술의 활용도 예상보다 적었습니다. 이게 PM의 역할을 하는 것도 이유가 됐던 것 같습니다. 빨리 맡은걸 끝내고 조율하고 붙여봐야 한다는 생각 때문에 서둘렀습니다.
여유롭게 Refactoring을 할 때, 비로소 급하게 지나쳤던 것들이 눈에 들어오고 하나씩 적용하기 시작했습니다. 사실 여유가 없어서 배운 것을 적용하지 못했다기 보단 아직 완벽히 적용할 실력이 없었다는 것이 더 맞는 것 같습니다.

프로젝트를 하면서 느낀 또 다른 한 가지는 자기 것으로 만드는가 못 만드는 가의 차이입니다. 비슷한 코드도 많고 참조하고 배울 자료는 넘치지만 온전히 자신의 것으로 만드는 가는 100% 자신의 몫이라고 생각합니다. 꼭 꾸준히 배운 것을 나의 것으로 만드는 것의 중요성을 경험했습니다.

5. 어떤 개발자가 되고 싶을까

IT인이었지만, 아닌 것 같기도 한 지난 몇 년을 돌아봤을 때 최근 2개월과 비교하면 '전혀 다른 세계'인 것 같기도 합니다. IT 직군에서 결국은 다들 개발자를 하려고 한 이유를 알 것 같습니다.

첫 번째는 끊임없이 성장할 수 있기 때문입니다. 물론 모든 직종도 마찬가지지만 시스템을 운영하는 것과 지구 어딘가에서 새로운 기술이 매일 발전해 따라가기도 벅찰 만큼 배울 것이 많다고 여겨집니다.(제 생각일 뿐입니다.)

두 번째는 자신의 생각과 개발 철학을 녹여낼 수 있다고 생각합니다. 이 역시 다른 직종도 마찬가지겠지만 무언가를 계속 표현해야 하는 개발자에게 이 개발 철학은 선택이 아니라 필수라고 생각합니다. 전에 누군가가 Coder(코더) 말고 Programmer(프로그래머)가 어라고 했던 것을 생각해볼 때 너무 공감되는 말입니다.(물론 코더가 프로그래머로 통용됩니다만)

이 두 가지를 보았을 때, 제가 되고 싶은 개발자는 다음과 같습니다.

가장 먼저는 사람을 좋아하는 따뜻한 개발자가 되고 싶습니다. 개발이라는 것이 곧 사람을 위해 만들어 진다고 생각합니다. 그리고 넓게 보면 우리가 사는 지구를 위한 것이 되야 한다고 생각합니다. 좋은 세상을 만드는 개발을 하고 싶습니다.

두 번째, 하고 싶은 것을 할 수 있는 개발자를 지향합니다. 모두가 그렇겠지만 남이 시켜서 또는 부담감으로 하는 것은 결국 한계가 있다고 생각합니다. 예전에는 제가 억지로 하는 걸 제일 잘한다고 생각했는데 사실 그게 아니었던 것 같습니다. 결국은 하고 싶은 일을 할 수 있는 개발자가 되어야 자신도 행복하고 팀원도 행복하고 회사도 행복한 선순환이 이뤄진다고 생각하기 때문입니다.

세 번째, 꾸준한 개발자를 지향합니다. 앞서 말씀드린 하고 싶은 것을 하는 개발자가 되러면 실력이 먼저여야 한다고 생각합니다. 저는 개발자로 천부적 재능을 갖고 있지 않다고 생각합니다. 그렇기에 더더욱 꾸준한 학습과 개발로만 성장할 수 있다고 생각합니다. 이 꾸준에는 단순한 성실함을 넘어 어느 것이 더 효과적인가를 늘 생각할 수 있는 지혜를 갈구하는 꾸준함도 필요하다고 생각합니다.

프로그램에는 정답이 없다고들 합니다. 그렇지만 오답은 또 있다고 합니다. 자신의 영역에서 꾸준히 할 수 있고 탐구하는 개발자(A.K.A 코린이)가 되겠습니다.

오답은 있단다!