2주간의 CHANEL 웹사이트 클론 프로젝트가 끝났다.
너무나도 유명한 그 이름 CHANEL......
ERD 구성도 결과물만 보면 그렇게 복잡해보이지 않지만,
그 과정은 전쟁터였다.
홈페이지 nav_bar 기준으로 모델링을 그대로 구현하려 했으나,
데이터베이스 정규화에 어긋나며, 또 수정을 거듭하면
테이블에서 다른 테이블로 접근이 불가능한 경우 등이 생기며
수정에 수정을 거듭했다.
그나마 다행인 점은
다른 팀들은 product 수가 1000개 ~ 5000개를 훌쩍 넘긴다.
우리의 고귀한 샤넬은 귀걸이 등의 액세서리까지 포함해서 500개가 채 안됐다.
하지만, 그 가격은 어마무시했다.
드레스 한 장에 1000만 원인 제품도......
1. 조금은 긴 회고
7/3일 금요일 저녁 6시가 조금 넘은 시간에 모든 조의 발표가 끝났다.
모두들 박수를 치며 축하하는 자리에서 문득, 정말 문득
무라카미 하루키가 떠올랐다.
나 역시 함께 축하하던 도중 오랜만에 찾아온
프로그래밍이나 장고 이외의 생각에 놀랐었다.
위코드 시작 전에 여러번 반복해서 읽던 책이라서 그런가,
정확한 이유는 나도 잘 모르겠다.
하루키는 말했다.
소설가가 되고싶거든 언제든 링 위에 올라오라고 말이다.
그 링은 누구에게나 열려 있다고, 누구든 언제나 환영한다고 했다.
하지만 중요한 말을 덧붙였다.
"단 한 권의 베스트셀러 도서를 출판하여 조명을 받은
타 분야의 천재들을 숱하게 봐왔다.
하지만 그렇게 창의적인 방식으로 문단에 돌풍을 일으킨 사람은 있어도,
그것을 오래 지속하는 사람은 없었다"
라고 말이다.
가수, 배우, 전문직의 사람들이 소설가의 링위에 올라
짧은 주목을 받았지만, 그렇게 5년, 10년, 20년 그 링위에
머문 사람은 없다는 말이었다.
나 역시 중학교 때까지는 육상선수,
대학교에서는 축구에 미쳐서 학과 수업을 다 제쳐두고 운동에 몰입한 적이 있다.
제주도 대표로 전국체전 육상부문에 나간 적도,
대학생 아마추어 축구리그 4강까지,
그리고 대학교 교내 리그에서 득점왕을 한 적도 있다.
하지만
나는 지금 육상을 하지도 않고,
조기 축구조차 나가지 않은 지 2년이 되어 간다.
내가 오래 지속하는 것은 무엇이 있을까?
그것을 오래 지속하는 이유나 비결은 무엇일까?
이 두 질문에 대한 해답을 찾으면 나는 좋은 개발자로 성장할 수 있지 않을까 라는 생각을 해본다.
오래 지속하는 것들에는 금전, 사람들의 인정 혹은 기대가 머물 공간은 없다.
그렇다면 무엇이 있을까? 그건 진심이 아닐까 한다.
- 가족과 함께 여유를 즐기며 나누는 대화,
- 느긋한 저녁에 부모님과 전화 통화를 할 때의 평온함,
- 강아지를 보면 '저 강아지를 더 행복하게 해주고 싶다'는 생각,
- 누군가에게 어떤 방식으로든 도움을 줄 때 느끼는 행복.
내가 꾸준히 하는 것에 어떤 분야의 세계 최고가 오더라도,
그 사람들보다 오래 지속할 수 있다는 자신이 있다.
진심이라는 것은 온전히 나만의 것이기 때문이다.
1) 어떤 프로젝트에도 대응이 가능한 개발자
2) 속도는 느리지만 개발하는 서비스에 진심을 가지는 개발자
둘 중 하나를 택할 수 있다면 나는 후자를 택하겠다.
그렇게 하는 것이 멋있어 보여서가 아니다.
그것이 오래 지속할 수 있는 비법이자 나를 사랑하는 방법이기 때문이다.
서론이 매우 길었지만,
샤넬 프로젝트를 진행하며 기술적인 문제를 해결하는 것은
그리 어려운 문제가 아니었다.
주변에 도움을 요청하든,
구글링과 스택오버플로우 등을 통한 7시간의 고민을 하든
결국엔 해결됐다.
하지만,
내가 개발한 서비스는 지속돼야 한다.
지속하기 위해서는 진심이 필요하다.
내가 먼저 이 서비스는 꼭 도움이 된다고 설득이 될 때,
남들을 설득시킬 수 있고 오래 지속할 수 있다.
다음주 월요일에 2차 프로젝트가 진행된다.
어떤 프로젝트를 맡을지 아직 정해지지 않았다.
기존 웹페이지를 최대한 비슷하게 클론한다는 생각보다
이 방식이 사용자에게 더 도움이 된다는 판단이 선다면
그 방식으로 구현해보겠다.
진심을 담고 싶다는 이야기다.
그리고는 2차 프로젝트 최종 발표를 할 땐,
그 누구보다도 기술이 아닌 진심을 담은 작품을 선보이고 싶다.
2. 내가 구현한 것들
CHANEL 하면 바로 떠오르는 것은 백(Bag)이 아닐까 싶다.
프로젝트 시작 전까지 샤넬에 대해 비싸다정도만 알고 있었다.
내심 CHANEL의 메인 아이템을 맡고 싶다는 욕심이 있었는데,
자연스럽게 팀 회의를 하는 과정에서 내가 샤넬 백 크롤링 및 리스트 뷰(엔드포인트) 구축을 맡게 됐다.
운이 좋았다.
2주 동안 프로젝트를 진행하며 샤넬 홈페이지만 100번은 들어갔던 것 같다.
가끔 샤넬 홈페이지에서 프랑스어로 '접근이 불가능하다'는 의미의 페이지가 보일때마다,
'크롤링을 너무 많이해서(=request 과다) 내 ip의 접근을 금지시킨건가?' 같은 생각을 많이했다.
참고로,
7/4일 토요일부터 샤넬 홈페이지의 컬렉션 페이지가 새롭게 단장을 시작하게되어 접근이 금지가 되었다. 샤넬이 그 일을 한 주만 더 일찍 착수했어도, 크롤링 자체가 불가능했을 것이다. 정말 다행이다.
프랑스의 여유로운 일 진행 속도, 아주 마음에 든다.
1) 샤넬 bag 엔드포인트 구축
- 백(Bag) 리스트 보기(필터 적용)
- 백(Bag) 상세 정보 보기
(1) 데이터베이스
MySQL DB엔 샤넬 bag의 모든 정보가 저장되어 있다.
모델링을 하며 샤넬 홈페이지에서
어떤 정보들이 필요한지
이미 충분히 숙지한 상태였다.
크롤링은 단순히 도구에 불과하다.
오히려,
ForeignKey, ManyToMany 데이터 연결 관계를 생각하며
어떻게 하면 더 빠르고 쉽게 db_uploader.py 코드를 짤지,
또 그러기 위해서 어떻게 csv파일을 받아올지가
눈에 보이지는 않지만 더 중요한 생각이란걸 깨달았다.
모델링이 잘못되면, 크롤링도 다시 해야한다.
모델링이 잘못되면, 엔드포인트를 구현할 수도 없고, 어떻게든 구현한다고 해도 비효율적이게 된다.
모델링(ERD 구성도)은 건물의 기초공사이며, 마치 모든 운동에 필요한 기초 체력과 같은 것이다.
(2) 효율
데이터베이스 hit를 최소화하고
views.py의 코드를 개선하는 데에 집중했다.
단순히 양적으로 엔드포인트 여러 개를 만드는 것보다
내가 만든 코드는 내가 확실히 책임지고 싶었기 때문이다.
이전 직장의 직무는 자동차 품질 QA였다.
생산/기술팀에서 CAPA를 맞추기 위해 제품을 "마구 찍어대는" 모습에
엄청난 비난을 들으면서도 심심치 않게 태클을 걸곤했다.
그게 품질부서의 역할이니 말이다.
"품질팀에서 제품 출하 불가에 대한 근거자료를 만들었습니다.
그래도 계속 진행해서 불량발생시, 생산/기술팀에 귀책을 물을 수밖에 없습니다.
그 대책서 서명에는 생산/기술팀 본부장 서명이 필요합니다" 라고 말이다.
대충 만든다. --> 어찌됐든 고객 납기일 만족 -->
불량 대량 발생 --> 8D REPORT 작성, 리워크 및 재생산 -->
품질 비용 발생 --> 손실
대충 만들면 결국 불량이 발생할 수 밖에 없다.
불량 발생은 결국 비용손실을 의미한다.
마구 찍어대서 양적인 목표에만 집중하는 것은 예전에도 그렇고 앞으로도
정말 지양해야 하는 태도라고 생각한다.
git push를 이미 한 상황에서도
내 코드는 개선할 곳이 분명있다는 생각을 가졌다.
최대한 list_comprehension을 사용하려 노력했고,
데이터베이스 hit를 최소화하기위해 장고의 prefetch_related, select_related를 적용했다.
그리고 멘토님 그리고 팀원에게
내 코드의 가독성이 어떤지 끊임없이 물었다.
샤넬의 꽃은 Bag이기에,
문제가 발생한다면 그건 백엔드의 잘못은 아니라는 확신을 스스로 갖고 싶었다.
그 덕분에 서버에서 status 200을 숱하게 확인했다.
try, except 와 같은 예외처리를 적용하여
에러 메시지 모두가
예외처리가 되어 식별될 수 있도록 했다.
숨겨진 예외들을 찾고자 Postman으로 try, except에 아직 정의하지 않은
예외 케이스들을 계속 실험했다.
또한, dir명령어를 통해 나올 수 있는 에러들이 무엇이 있는지 확인했다.
그러한 연유로 1PR에 19 commits을 했다 ㅎㅎㅎㅎ
(3) bag 필터 기능 구현
샤넬 백을 아래와 같이 필터링 될 수 있게 구현했다.
- 컬렉션 별
- 재질 별
- 모양 별
- 색깔 별
- 테마 별
물론,
내가 이렇게 구현했지만
프론트엔드에서 쿼리스트링으로 Param(Key, Value) 값을 보내는 방법까지 구현하지 못했기에 발표 때는 필터값이 {}인 채로 시연됐다.
(즉, 모든 제품 보기가 적용됐다.)
완성된 API의 일부 기능만 사용된다는 점이 아쉬웠다.
2) 모델링(ERD 구성도)
우리팀은 모델링에 사활을 걸었다.
다른 팀들이 수요일부터 크롤링을 시작할 때,
우리 샤넬팀은 목요일까지 모델링을 수정하고, 또 수정했다.
세 분의 멘토님들에게 찾아가 피드백을 요청했고,
현직 개발자에게 두 번이나 찾아가 코드 리뷰가 아닌 모델링 리뷰를 받았다.
그 덕분에 목요일 이후에는 모델링을 수정한 적도,
크롤링을 다시 해야하는 일도 발생하지 않았다.
3. 부족했던 점
블라인드 사이드
프로젝트 시작 전 멘토님들이 그런 말씀을 했다.
프론트엔드 그룹에서 API 언제 완성되나요?와 같은 압박을 받게 될 것이라고 말이다.
하지만,
그 말을 백엔드 그룹에서는 진지(?)하게 받아들였고,
모델링 및 데이터베이스가 구축되자마자 API들이 우후죽순 개발됐다.
그래서 오히려 우리가 프론트엔드 그룹에
"페이지 언제 완성되나요?" 와 같은 요청을 정말 많이 하는 상황이 연출됐다.
본의 아니게 프론트엔드 그룹에 압박을 준 것 같아 정말 미안한 마음이 든다.
그래도 만약,
"Bag의 경우는 시간 관계상 페이지의 어떤 부분까지만 제작될 것 같다" 등과 같은 말을 들었다면, 시연되지 못할 백(Bag)필터에 집중하지 않았을 거다. 오히려 검색이나 위시리스트에 집중했을 것이다.
(내가 봐도 뒤끝 장난 아닌 것 같다. 정말 필터 기능이 웹 페이지와 구현되는 모습을 내 눈으로 직접 보고 싶었다ㅜㅜ)
백엔드 개발은 나도 처음이라, 직접 상황을 마주하지 않고서는
이와같이 예측하지 못하는 영역들이 존재했다.
그래도 이것은 정말 원망이 아니다.
우리 프론트엔드 그룹은 정말 열심히 해줬고, 밤도 여러번 새는 것을 봤다.
주말 동안 이 부분에 대해 어떤 점이 근본 원인이었을까 고민을 해봤다.
단순히 이것을 소통의 부재라고 할 수 없다.
경험 부족에 의한 자연스런 결과라는 생각이 든다.
일부러 프론트엔드 팀원 옆자리에 앉아서 하루종일 붙어앉으며 대화를 해왔으니 말이다.
다들 처음 해보는 프로젝트이기에 현재 자신이 개발하는 페이지 혹은 API가 언제쯤 그리고 어느 수준으로 완성될지 가늠하기란 쉽지 않았을 것이다.
중요한 것은 같은 실수를 반복하지 않으면 된다는 것이다.
2차 프로젝트 땐,
페이지 구현 정도,
페이지 구현 데드라인 등을 미리 파악하여
내가 만든 엔드포인트의 모든 기능이 사용될 수 있도록 하겠다.
4. 프로젝트 결과
5. 마치며
status 200(위코드 은어로는 이백오케)를 보는 것도 기분 좋지만,
다양한 유형의 에러 메시지를 보는 것 역시 좋았다. 정말이다.
오히려 이런 생각을 하게된다.
적어도 위코드에서 만큼은 최대한 많은 에러를 경험하고 싶다고 말이다.
에러를 통해 많이 성장하는 것 같다.
2차 프로젝트도 화이팅!
