2차 프로젝트 회고

항상 좋은 점보다는 아쉬운점만 남는다.

작업 내용

INFLEARN Clone Project (MECOOK)

동영상 강의 플랫폼 사이트인 inflearn 웹사이트 클론.

개발 기간 / 개발 인원

개발 기간: 2021-10-18 ~ 2021-10-29

개발 인원: 백엔드 X2명(본인 포함), 프론트엔드 X4명

직접 구현 파트 : 영상 스트리밍, AWS S3 사진 업/다운로드, 학습 페이지 API

시도 기술 : AWS RDS, GIT REBASE, Django - Annotate 메소드, UNIT TEST, Oauth2 (카카오)
-> 사용은 했으나 제대로 습득하지 못함. 이후 반복학습 필요

DB 모델링

• 실제로 구현할 만큼의 데이터 테이블만 만들었다.

실제 구현 화면

영상링크

공유하고 싶은 코드

코드라기 보다는 사실의 나열이다.

• 텍스트가 아닌 이미지/음악/영상 등은 바이트형태로 읽거나 편집해거나 송신해야 한다.
• 큰 데이터를 한번에 HTTP 송신하는 것은, 서버 메모리/통신환경을 고려했을 때 적절치 않으므로, 적절한 데이터 단위(적절한 크기는 서버/통신환경에 따라 유동적)로 잘라서 송신해야 한다.
• 파일(바이트)를 잘라서 읽을 때는, 파일을 iterable한 형태로 만들어 두는 것이 인터페이스적으로 편리하다.
• 브라우저에서 데이터를 받을 때는 해당 데이터가 어떤 파일인지 알기 위해 'Content-Type'이라는 것을 필요로 한다.
• 동영상을 중간부터 다운로드 받는 소위 '건너뛰기' 기능을 사용하기 위해서는 서버에서 동영상을 보낼 때 'Accept-Ranges' 라는 값을 헤더에 포함해야 한다. (대부분 bytes)
• HTTP 환경에서 동영상 스트리밍을 하기 위해서는, 동영상 파일 자체가 스트리밍을 지원해야 한다. (MPEG DASH)

---

좋은점

1. 많은 기술에 대한 경험

• AWS 기초, GIT REBASE(응용단계라고 할 수 있을지?), 소셜로그인, UNIT TEST, 스트리밍(+ 이를 위한 파일 읽고쓰기)등 다양한 기술에 대해 학습의 기회가 있었다.

2. 적어도 프론트에게는 Blocker가 되지 않음

• 프론트엔드 분들의 어떠한 요청이 있는 경우 30분,1시간 내로 작업/편집을 제공할 수 있었다.
• 지난 프로젝트에서 API를 제공받는 것을 힘들어한다는 걸 깨닫고 항상 최우선 작업으로 처리했다.

아쉬운점 - 팀킬 X2

1. 내가 잘하고 있다는 착각

• 작업 시작하자마자 프론트엔드에게 API 샘플을 만들었다.
• 해당 파트는 내가 작업을 맡은 부분이 아니었다.
• API 명세서까지 프론트엔드랑 공유해놓고 백엔드 팀원과 공유하지 않았다.
• 백엔드 팀원이 나중에 내 명세서대로 재작업을 하느라 시간을 또 날림

2. 충돌 유발

• 해당 샘플을 제공하고 가짜 데이터를 넣느라 내 맘대로 DB를 바꿈
• DB 변경한 내용을 git에 공유하지 않음. (초기에는 에러를 피하기 위해 각자 쓰는걸로 내 멋대로 생각했음)
• 나중에 내 DB를 AWS RDS에 올려서 공유 시도했음
• 에러 발생해서 해결하려고 엄청 시간날리게 만듬

원래 코드를 짜는 것보다 에러를 해결하는게 몇배는 더 힘들고 짜증나는 일이다.
나는 이런 에러를 유발해놓는 발암인자가 되었다.
사실 아쉬운 점이라는 말이 너무 부드러운 표현이다.
다시는 이런 일은 없어야 한다. 절박한 마음이다.

공부가 아닌 작업

1. 제대로 공부하지 않음.

• GIT (rebase/squash)
• AWS (EC2/RDS/S3)
• 유닛테스트 (TestCase)
• 동영상 스트리밍 기술

위는 이번 프로젝트에서 처음 사용해본 기능의 목록이다.
튜토리얼이라도 처음부터 끝까지 공식문서를 다 읽어본 것이 없다.
모두 한 몇 시간 읽다가 시간이 없다는 핑계로 그만 둬 버렸다.
결국 그때 그때 블로그에 소개된 메서드만 사용했다.
혹은 발생하는 에러를 해결하기 위해서만 검색했다.
나는 이 프로젝트를 이전 보다 더 나은 사람이 되었는지?
나는 이 모든 서비스/기능을 "경험"해본 사람이 되었지, "알고 있는" 사람이 된 것이 아니다.
너무 아쉽다.

그러나 한편으로 .. AWS기능을 공부하면서 느낀 점은
마치 CS공부를 처음 할 때와 비슷한 감정이었다.

양이 너무 방대하고 기초지식이 굉장히 모자란 상태로 응용단계의 기술을 찾아봤다.
따라서 튜토리얼을 다 읽더라도 (모르는 내용을 찾아가며 봤지만 끝도 없었다.) 제대로 이해하거나 기억하지 못했을 가능성이 매우 높다.

위의 기술들은 조금 더 시간을 들여서 네트워크, CS의 기초적인 지식들을 단단히 다진 후 공부해야 겠다는 생각이 많이 들었다.

2. 대충하는 습관

이번에 알게되었다.
나는 코드를 짤 때 고민을 하고 짜지 않는다.
먼저 결과를 정한다.(화면을 보면서 프론트엔드와 회의를 통해 만든 API 명세서)

그 다음에는 이를 위한 코드를 쑤셔 넣을 뿐이다.
내가 당장 알고 있는 방법으로, 남들이 알아보기 힘든 엄청나게 긴 코드를 짠다.

그렇게 해도 결과 자체는 빨리 나온다.
효율도 고려하기 때문에 지금 당장은 나쁘지 않은 코드처럼 보인다.

하지만 유지보수와 재작업을 생각한다면 매우 나쁜 방식을 사용하고 있다.
적어도 지금 당장은.. 스스로가 협업하기에 안좋은 사람이라는 생각이 든다.

그나마 다행인 점은 문제점을 알았으니 고쳐 나가면 될 것이라는 점이다.

결론

결과가 아닌 과정

이번 프로젝트는 취업용 포트폴리오를 제출하기 위해서,
좋은 결과물이 필요한 작업일 수도 있다.

그러나 더 큰 목적은 모르는 부분을 학습하고 채워나가는 과정이었을 것이다.
나는 과정이 더 중요하다는 점을 마지막 순간에 와서야 깨달았다.

나의 행동 돌아보기

나는 항상 팀원들에게 다가가서 "뭐 도와드릴 것이 있을까요? 필요한것이 있나요?" 하고 물어봤다.
그리고 이것이 남들을 돕는, 팀워크를 향상시키는 이타적인 행동이라고 생각했다.

그러나 내가 다가간 것은, 진심으로 팀원을 돕기 위해 다가간 것이 아니었다.
더 좋은 결과물을 뽑아내기 위해
더 작업시간을 단축시키기 위해
학습을 돕는 것이 아닌 결과만을 재촉했다는 것을 다 지나서야 깨닫는다.

주변 돌아보기

아마 팀원들도 내가 그들을 진심으로 돕기보다는 결과물만 원한다는 것을 느꼈을 것이다.
이건 시험도 아니고, 대회도 아니고, 업무도 아니었다. 그저 학습을 위한 과정이었을 뿐이다.
너무 늦게 깨달았다.

그리고 이런 나의 행동때문에 많이 힘들고 상처받았을 나의 백엔드 팀원에게 진심으로 사과드립니다.