안녕하세요. 지난 글에 이어 지적 덕후생활 공동체(지덕체)개발기를 연재하고 있는 ryukim입니다.
지난 글에서는 두번째 리팩토링 과정과 그 시행착오에 대해 써봤는데요.
오늘은 기능 추가 1주차 과제를 해결한 과정에 대해 이야기 해볼까합니다.
지난 글까지의 이야기는 시간이 꽤 지난 일들이라 기억을 더듬어가며 글을 써서 조금 미흡했을 것 같은데요.
이번 글부터는 비교적 최근에 있었던 일을 정리하는 것이라 조금 더 상세한 저의 경험을 전달해 드릴 수 있을 것 같습니다.
검증이 힘들다면 도구를 이용하자
용량과 확장자는 어떻게 하겠는데…
1주차 첫번째 과제는 바로 파일을 검증할 수 있는 클래스를 제작하는 것이었습니다.
보시는 것처럼 기존 지덕체는 업로드한 파일을 그대로 화면에 출력하여 이미지 크기가 뒤죽박죽이었습니다.
물론 출력할 때 1:1 비율로 고정하는 방법도 있겠지만 이미지마다 보여주고 싶은 위치가 다르기때문에 좋은 방법이 아니라고 생각했습니다.
다행히 파일의 용량과 확장자의 경우 기존의 업로드에 사용하던 앞단 라이브러리 "Dropzone"에서도, 뒷단 라이브러리 "multer"에서도 모두 검증을 지원했기 때문에 쉽게 적용할 수 있었습니다.
그렇다면 정녕 이미지 크기는 직접 1:1로 수정해서 올리는 방법 밖에 없는 것인가..?
하지만 이미지의 크기를 검증하기는 쉽지 않았고, 저의 목표는 유저들이 직접 굿즈를 업로드할 수 있는 커뮤니티를 만드는 것이었기 때문에 유저에게 최대한 편한 방법을 고민할 수 밖에 없었습니다.
몸에 좋은 약이 달기도 하다?!
그렇게 한참을 고민하던 중 한가지 아이디어가 떠올랐습니다.
‘이미지 크기의 검증이 힘들고 유저에게 직접 파일을 수정해야하는 불편함을 주기 싫다면 업로드 페이지 안에 이미지 크기 수정 툴을 넣으면 되지 않을까?’
저는 바로 유튜브를 켜고 react로 이미지 crop하는 방법을 검색했고 훌륭한 예시 강의를 발견할 수 있었습니다.
혹시 같은 문제로 고민하고 계신 분이 계시다면 다음 강의https://youtu.be/jyeRDo2tP_s를 추천드립니다.
가장 구현하기 쉬운 방법인 동시에 UX까지 잡았으니 몸에 좋으면서 달콤하기까지한 해결책이 아닐 수 없었습니다.
깔끔한 랜딩 페이지로 도약하다
그렇게 하루 꼬박 저를 갈아넣은(?) 결과 유저의 편의와 깔끔한 랜딩페이지까지 얻은 새로운 지덕체의 영상입니다.
거대 파일 업로드하기
찾아낸 세가지 방법
1주차 두번째 과제는 바로 용량이 큰 파일을 업로드 해야할 때 트래픽을 어떻게 대응할 것인가 하는 것이었습니다.
인터넷과 나름대로 가지고 있었던 지식으로 총 세가지의 해결책을 생각해봤습니다.
- 로드밸런싱을 통해 서버 여러대로 트래픽을 분산한다.
- 소켓 통신을 이용해 빠른 속도로 처리한다.
- 정적 파일 서버를 별개로 두어 클라이언트가 직접 통신하도록 한다.
저의 짧은 지식으로는 이 중 어떤 것이 가장 좋은 방법인지 알기 어려웠습니다.
남세현 멘토님과의 만남(42에 온 것이 기적인 이유)
그렇게 고민하던 와중에 클러스터에 PUBG 개발자 남세현 멘토님께서 멘토링을 하러 찾아오셨습니다.
아웃게임 개발자이지만 node 지식도 갖추고 계시다는 말을 듣고 제가 찾은 세가지 방법 중 어떤 것이 가장 좋은 방법이고 현업에서 많이 사용되는 방법인지 질문했습니다.
멘토님은 3번째 방법이 가장 많이 쓰이는 방법이라고 알려주셨고, AWS의 S3에서 사용되는 presigned url을 이용해 안전하게 파일서버와 직접 통신하는 원리를 설명해주셨습니다.
멘토링이 끝난 후 따로 만나 지덕체에 대해 소개해드리며 저의 계획과 목표에 대한 이야기, 그리고 어떻게 하면 팀원을 잘 구할 수 있는지 등에 대한 조언을 얻을 수 있었습니다.
현업 개발자를 만나 이런 질문과 대화를 할 수 있는 42서울에 온 것이 정말 기적이라고 또 한 번 느끼는 순간이었습니다.
코드에 침투한 환경 변수의 위험성
지금은 별거 아닌 것 같지만…
1주차 마지막 과제는 코드 속에 숨어있는 DB주소, 서버 주소와 같은 환경 변수들을 따로 떼어내는 작업이었습니다.
멘토님께서 실제로 환경 변수를 제대로 관리하지 못해 발생했던 사건 사고들에 대해 이야기해주셨습니다.
돈이 걸린 문제
지금 당장 개발하는 동안은 환경 변수들이 녹아있는게 크게 문제되지 않고 단지 값을 바꿔야할 때 조금 귀찮은 정도겠지만, 실제 서비스를 시작했을 때 하나를 놓치는 실수가 얼마나 큰 문제를 야기할 수 있는지 알게 되었습니다.
거기에 결제 서비스까지 붙어있는 상태에서 그런 실수가 발생하면 커다란 금전적 불이익이 발생할 수도 있다는 이야기를 해주셨고, 커뮤니티에서 더 나아가 펀딩 플랫폼을 꿈꾸고 있는 저에게 얼마나 환경 변수 관리가 중요한지 마음 속에 새길 수 있었습니다.
다음 과제
파일이 바로 삭제되면 안되는 이유
멘토님께서 상품 삭제를 눌렀을 때 이미지 파일이 어떻게 처리되는지 물어보셨고 저는 자랑스럽게 바로 삭제되는 기능까지 구현했다고 말씀드렸습니다.
하지만 멘토님께서 이런 예시를 들어 주셨습니다.
- 유저가 유일하게 딱 하나 있었던 이미지를 업로드하고 본인 컴퓨터에 있는 파일을 삭제했다.
- 오류 혹은 타인의 잘못된 접근으로 해당 이미지가 포함된 상품이 삭제되었다.
이 때 유저가 해당 파일을 복구해달라고 하면 어떻게 해결할 것인지 물어보셨습니다.
그렇게 2주차 첫번째 과제는 "파일 관리 운영 정책 설계"가 되었습니다.
로그의 중요성
두 번째 과제는 로그를 어떻게 남길지 생각해보는 것이었는데요.
쉬울 줄 알았던 이 과제는 지금까지도 저에게 가장 어려운 해결해야할 과제로 남아있습니다.
메인 페이지에 신상품 8개씩 페이지네이션
마지막으로 랜딩 페이지가 너무 휑하니 신상품란을 추가해 8개씩 페이지네이션 해오는 과제를 내주셨습니다.
미리 스포하자면 이 과제가 2주차 과제 중 가장 큰 의미를 담고 있었다고 개인적으로 생각합니다.
다음 글에서는 2주차 과제를 해결한 과정과 피드백에 대해 적어보도록 하겠습니다.
긴 글 읽어주셔서 정말 감사합니다!