[회고]프로젝트1

회   고

 

이번 글은 프로젝트 1의 회고로서, 코드스테이츠에서 권고하는 회고 방법인 사실-발견-배운점-다짐 의 내용을 최대한 모두 담으려했습니다.

Github 주소 : https://github.com/cs-devops-bootcamp/devops-01-P1-TeamC

사실, 완성도 요약 : 💜💜💜💜🤍

완료 : 🎀

• 쇼핑몰 웹 어플리케이션 만들기
• 백엔드 구현
  • API 설계 ( 1일차 목표 ) 🎀
  • API 만들기 ( 2일차 목표 ) 
    • 비디오 api 🎀
    • 장바구니 api 🎀
    • 페이지네이션 api
  • DB 만들고 연결하기 ( 3일차 목표 ) 🎀
  • 검색 기능 구현 ( 3일차 목표 ) 🎀
  • 발표자료 만들기/ 제출 ( 3일차 목표 ) 🎀
  • 깃헙에 api.md 제출 ( 최종목표 ) 🎀
• 프론트엔드 구현( 2차 목표, 시간되면 )
  • 초기화면 만들기 - 비디오 썸네일 정렬, 검색창, 프로필
  • 비디오 상세화면 - 비디오, 상품 목록(체크박스), 결제 버튼, 장바구니 버튼
  • 개인프로필 화면 - 사용자 이름, 장바구니, 결제완료 버튼 연결
  • 장바구니 목록 뷰
  • 결제완료 목록 뷰

 

발견, 배운점, 다짐 + 느낀점 :

D - 1 

 

 2월 7일부터 부트캠프를 시작하고 처음으로 동기들과 엔지니어님들을 대면하는 기회가 되었다. 솔직히 조금 설레기도 했다. 새로운 사람들을 만나는 것은 언제나 떨리고 부담스럽고 즐거운 일이다. 코로나로 인한 비대면 방식들이 여러모로 효율적이긴 하나 꽤 지루하다고 느껴졌는데 오랜만에 오프라인으로 사람들과 협업이라니 많이 기대되기도 했다. 여기에 참석하려고 병원도 마다하고 준비했다. 꼭 여래 엔지니어님께 말을 붙여보고싶었다. 성공할 수 있을까.

 

DAY 1 

 

 살짝 위장이 아파오는 긴장감으로 오프라인장소로 들어서니 어째 나 빼고 다들 안면이 있는 듯한 느낌을 받았다. 그런 느낌속에 우선 자유롭게 앉으라는 말을 들으니 위장이 아파오는 것이 확실해지기 시작했다. 다행스럽게도 곧 조를 짜주신다고 해서 위장의 고통이 약간 가라앉았던 것 같다. 대충 아무곳에나 쭈그러들어있었는데, 미묘하게 다들 안면있는 듯한 느낌이 사실이었다. 게더타운에서 자주 모이던 회의실 A라는 팀이 있었나보다. 나는 게더타운에서 뭘 해야하는지 몰라 잘 안들어가거나 들어가서 늘 맵의 구석에 있는 공원 벤치자리에 앉아있어서 몰랐지만, DevOps 1기 스터디룸과 회의실 A라는 스터디 룸에서 다들 오며가며 인사를 했었나보더라. 거기다 의외로 같은 학교 출신이라던가 하는 분들도 꽤 계셨다. 이 때부터 점심을 혼자 먹게 될까 걱정했다. 물론 세션 중에 집중해야 하지만 처음 줌으로만 만났던 엔지니어님들을 현실로 만나게 되었더니 트위치 스트리머를 현실로 보면 이런 느낌일까, 하는 딴생각도 들곤 했다. 미묘하게 호용 엔지니어님은 낯이 익었다. 왜일까 곰곰히 생각했는데, '컴공선배'라는 유튜브의 '스카이'님과 인상이 비슷했다고 나중에 떠올랐다. 말투가 비슷한 것도 같다. 서울 사람이라 그런걸까. 쭉 부산에서만 나고자라서 잘 모르겠다.

 

 조를 처음 만나고 잠깐의 침묵시간이 너무 힘들었다. 차라리 얼른 일을 하고싶다는 생각까지 하면서 최선을 다해서 아무말을 뱉었다. 조원들이 상냥해서 다행이었다. 아무말이나 뱉은 말들을 친절하게 받아주었다. 누구든 처음 만나면 공평하게 힘들어하니 사람을 특별히 가리는 것은 절대 아니지만, 그래도 왠지 같은 여자분이거나, 또래거나 하면 아무래도 조금 더 편한 건 사실이다. 그런 의미에서 또래 조원과 비교적 적은 수의 여자분들 중 한 분이 같은 조에 배정되어 정말 다행이었다. 지나치게 사적으로 친밀할 필요는 없다지만 그래도 원활한 업무와 적절한 라포형성은 절대 떼낼 수 없다는 것을 느꼈다. 기술 외에도 배워가는 것이 많은 과정이다.

 

 주제를 쇼핑몰, 투표, LMS 등과 같이 좁혀주면서 API 설계와 요구사항 명세서를 쓰는데 하루를 온전히 할당하기에 처음엔 "음..친해지는 시간도 같이 주는 건가" 라는 건방진 생각을 했다. 아니었다. 정말 하루가 온전히 필요한 작업들이었다. 백엔드가 프론트엔드보다 협업이 적을 것이라 생각했는데 착각이었다. 요구사항 명세 같은 경우 아무래도 소프트웨어 공학을 전공시간에 다뤄보다보니 제법 수월하게 쓸 수 있다고 생각했다. 아니었다. 3일이라는 제한된 시간과 나와 팀원들의 역량 모든 것을 볶아서 나온 실제 구현 가능한 정도 사이의 간극을 짐작해 내는 것을 전혀 못했다. 왜 IT 전공자 출신의 PM이 별도의 직군으로 존재하는지, 왜 책으로만 배우면 안된다고들 하는지, 왜 RESTful API 라는 말이 나왔으며 이를 짜는 능력이 우대사항인지 느꼈다. "동영상을 누르면 관련된 상품들이 영상 옆에 리스트 될 수 있도록 하자" 라는 문장은 전혀 구체적인 것이 아니었다. 이 것을 API 로 만들때, GET /vidoes/로 만들 것인지, GET /videos/items/ 로 만들것인지는 차이가 아주 컸다. 리소스 중심의 설계라는 조건은 대부분의 개발자가 혼자 일하지 않는 다는 점에서 더욱 중요하더라.

 

 팀원들이 설계 과정에서 마주친 더 큰 문제는 이러한 사항들이 구현체 보다 논리체의 가깝다는데서 발생했다. 차라리 프론트엔드는 구현 > 피드백 을 반복하면 된다. 제플린같은 도구도 있고 삽질이 있을지언정 전달코자 하는 것이 명확했다. 하지만 DB설계는 그와 조금 달랐다. 각자 머리속에서 구동되는 프로덕트가 다를 수 밖에 없다. 눈으로 보이지 않으니까. 정말 많이 대화해야했다. 왜 명세서를 쓸 때는 내가 그리는 바를 명확히 전달하고 상대가 그리는 바를 명확히 전달받기 위해서 아무리 스키마를 사용한다고 해도 약간만 의도가 틀어지면 조인 테이블이 바뀔 수 있더라. 발표를 하게 되서 조금 더 세심한 피드백을 받을 수 있었다. 내놓는게 부끄럽고해도 아무튼 내놔야 바뀌는게 있는 것 같다.  

 

DAY2

 

 본격적인 API 모델 구현이 오늘의 마일스톤이었다. 단 하나의 모델이라도 포스트맨으로 요청을 보내고, DB를 통해서 응답이 나오게 하는 것이었다. 정말...쉽지않았다. 사실 첫날의 설계가 얼추 끝나고 우리팀은 관계형 DB가 필요해서 mongodb를 택하는 다른팀과 다르게 mySQL로 진행을 했는데, 팀원들에게 정말 감사한 마음 뿐이다. 나는 전공선택에서도 db를 하지않았다. 그냥 db를 해본 적이 없다. mySQL은 졸업과제때 나 말고..백엔드 담당 팀원이 썼다. 알아듣는건 코드를 조금 읽는 것...그래서 사실 효율적으로 가자면 나는 api 설계까지 첫날 했고, db를 연결하는 것 까지 했다면 그 이상은 db를 다뤄 본 팀원이 하고 나는 다른 걸 만지는게 맞다. 하지만 우리는 팀원 모두가 감사하게도 이번 기회는 모두 배우는게 목표인 만큼, 설령 다 못한다 하더라도 각자가 처음부터 끝까지 만져보자고 으쌰으쌰 해주셔서 첫날 설계한 api를 섹션별로 나눠(video, item, order)브랜치를 하나씩 담당하고 풀리퀘까지 하는 방식을 택했다. 그게 너무 고마웠다. 우리팀이 이번 프로젝트에서 집중한 가치는 효율이 아닌 성장과 배움이었다.

 내가 담당한 리소스는 item이었다. get /video/item 으로 넘어오면 item을 보여주는 식으로 item이 엔드포인트에 있는 api들을 담당했다. order(장바구니)나, 검색이 포함된 video를 담당한 다른 팀원보다 쉬운 부분을 받았다고 생각했다. 물론 사실이다. 그럼에도 SQL문 자체가 낯선 나에게는 데이터를 넣은 DB 테이블을 만드는 것 조차 오래 걸렸다. fastify로 서버를 구축했는데, 이를 sql과 연결하기 위해 공식 문서, fastify팀의 깃헙 리드미 등을 열심히 찾아 읽었다. 한글로 된 정보는 깔끔하게 포기하고 차라리 공식문서나 깃헙을 찾는게 오히려 더 정신건강에 이로울 수도 있구나를 느꼈다. 한글로 된 정보는 읽기 편하지만 나의 에러 모음집이 그렇듯, 너무나도 다양한 각자 환경에서 발생한 각자의 에러사항에 대한 대처기 때문에 오히려 표준화된 제안이 필요할 때는 도움이 되기 어려울 수도 있다. 그리고 영어를 번역하는걸 포기하는게 나을 때도 많다. 왜 전공시간에 교수님들께서 한글 수업인데도 은,는,이,가 같은 조사를 제외하곤 모조리다 원어로 말씀하셨는지 느껴지더라. 정확한 번역이 어려우면 오히려 뜻 전달이 이상하게 되는 것 같다.

 

DAY 3

 

 협업을 정석대로 깃으로 진행 하려고 했더니 에러가 조금..아니 아주 많이 발생했다. 에러 모음집이 풍부해 질 예정인데 아직 다 못채웠다. 두번째 날에서 각자 리소스별로 api를 담당했는데 우여곡절끝에 포스트맨으로 반응하는 것은 확인을 했다. 너무 기뻤고 이대로 git에 올리면 끝나는 줄 알았다. 물론, 제대로 된다면 끝나는게 맞다. 하지만 제대로 되지않더라... git을 써봤다고 말했지만 역시 나는 감자였다. 어디가서 전공자라고 말 못하겠다. add, commit, push 만 해봤으면서 할 줄 안다고 했던 내가 너무 부끄러웠다. 깊이 반성했다. 리소스 별로 담당했으니 리소스 별로 브랜치를 만들어 작업을 했는데, 반드시 협업을 할 때는 설계에 가장 많은 시간을 배분해야한다. 그렇지 않으면 공통된 파일에서 각자가 건드릴 수 있는 파일, 각 파일의 권한을 제대로 정해놓지않으면 무한 컨플릭트의 함정에 빠질 수 있다.

협업 시 미리 정해 놓을 것에는,

 

1. 파일의 계층구조

2. 파일과 파일에 대한 팀원들의 권한 설정

3. 공통된 변수 명과 파일명

4. 각종 디펜던시들의 버전

 

들이 있다. 더 많겠지만 이 네가지는 무조건 정하고 시작해야하더라. 실전으로 아찔하게 배웠다.

다 잘하고 변수명이 달라서..파일명이 달라서...버전이달라서...눈물이 앞을가렸다.

계속 봐달라고 요청해서 엔지니어님들께도 죄송하다. 너무 절박한 나머지...민폐를 끼친 것 같다.

여차저차해서 끝이 났고, 최종발표에는 참여하지 않았다. 가위바위보를 이겼다! 다른 팀들이 한 걸 봤는데 다들 그 바쁜와중에 언제 또 발표자료까지 만들고, 발표의 정석 구조를 다 지키셨는지 궁금할 따름이다. 역시 내가 제일 감자다. 전공자라고 말 안해야겠다.

 

 최종 구현율의 80% 정도를 준 이유는 페이지네이션, 결제(put 혹은 patch로 item의 결제완료 데이터를 boolean으로 바꾸는 것), 한번에 장바구니에 아이템을 복수로 넣고 수량을 수정하는 기능(put과 post에 배열을 전달하고자 함), 동작만 간단하게라도 보여줄 수 있는 프론트 등을 구현하지 못했기 때문이다. 사실 마음같아서는 내가 해낸 정도로는 3개 반쯤 주고싶지만, 같이 고생한 팀원들의 달성율, 이번 프로젝트의 전체적 목표인 crud관련 API 명세서 작성과 포스트맨을 통한 구현을 생각하면 그래도 80% 정도의 완성도를 보여 준 것 같다. 내가 못한거지..팀원들은 잘했으니까...

 특히 db 설계 경험이 있는 팀원님이 설명까지 조곤조곤 잘 해주시는 분이어서 정말 다행이었다. 아니었으면 정말 3일 동안 마음이 많이 힘들 뻔 했다. 그리고 프로젝트 정말 구성이 알차다. 교육 엔지니어님이 계시겠지만 정말...네...딱 그간 배운것을 모조리 다 털어넣어야 완주할 수 있도록 실무 과제를 내주시더라. 덕분에 체계적이면서도 현장감 넘치게 배움을 쑤셔넣을 수 있어서 소화할 수 있어서 여러모로 감사했던 시간이었다.