[기업협업 브랜디]🔨 인턴 5주간 생활

코로나로 심각할 때 쯤 인턴을 지원했습니다.
그래서 인턴이 불가능할지도 모르겠다 생각했는데,
감사하게도 위코드 3개월차에 '브랜디'에서 인턴 생활을 할 수 있었습니다.

브랜디 직원분들도 모두 친절하셨어요!
기업 분위기도 좋아서 좋은 추억을 많이 남기고 왔습니다. 😁
갑자기 지하 1층 카페에 딸기스무디가 생각이 나네요ㅎㅎㅎ

자, 그럼 인턴 생활 마무리를 위해 글을 써보겠습니다!

프로젝트 소개

기업 협업을 하면서 완성한 동영상 입니다.

브랜디 어드민 웹사이트 클론

참여 기간 : 2020.09.14 - 2020.10.15
적용 기술 : Python, Flask, Database Mysql, AWS S3/EC2/RDS
구성 인원: 프론트 엔드 2명, 백엔드 3명

기능 구현

셀러 회원가입, 로그인 기능
셀러 상태 변경에 따른 과거와 현재 이력
셀러 계정 관리, 회원 커뮤니티 관리 수정/등록 (페이지네이션)

구체적인 기술

1. 셀러 회원가입

• validate를 사용하여 회원 가입 유효성 체크 부합하지 않을 경우 에러 메시지 리턴
• bcrypt 단방향 해시 함수 암호화를 이용한 비밀번호 암호화

2. 셀러 로그인

• 로그인 사용자 id 존재 여부, password 일치여부
• 성공시 jwt 토큰 발급, payload 유저 테이블의 primary key, 권한 id(마스터, 셀러 여부)
• 데코레이터를 이용한 로그인 여부

3. 셀러 계정 관리/ 유저 커뮤니티 관리

• 선분 이력을 사용하여 셀러 상태, 셀러 속성 등 추적이 필요한 데이터를 관리
• 수정할 때마다 새로운 record를 생성
• 등록된 셀러의 이력을 시작, 종료 시점으로 관리하고, 데이터를 조회할 때 가장 최신의 종료 시점을 가진 데이터를 불러오도록 함
• 필터(회원 번호, 회원 입점 상태, 이름, 담당자 이름, 담당자 번호 등) 기능
• 회원 목록 조회시 Pageing처리(10,20,50...150개)
• 판매자 프로필 이미지/배경이미지은 S3 버킷을 이용한 이미지 파일 업로드
• 판매자 해당 필터 리스트 엑셀 다운로드 , 미검색시 전체 리스트 엑셀 다운로드
• 숫자는 equal 검색, 한글과 영어는 like검색으로 구현해 조회 성격에 따라 결과를 구분
• 회원 가입한 판매자의 경우 입점 승인을 통해 권한을 수정
• 퇴점, 입점 거부 적용은 soft delete로 구현하고 조회 리스트에서 제외

4. RESTFUL API

• POST, GET, PUT, Delete method 사용
• resource가 url을 설명할 수 있도록 구현
• 수정은 PUT method

프로젝트를 하면서 고민했던 부분

1) 엑셀 다운로드 파일

• 전체 내용/ 검색 조건으로 다운 가능
• 검색 조건으로 다운 시, 검색할 때의 조건을 Query String으로 받아서 dao에서 해당값에 해당하는 모든 데이터를 나오게 하기 위해서 where절에 and로 넣어주었습니다.
• uuid.uuid4() : 파일명을 겹칠 이슈로 파일명이 겹치지 않게 해주었습니다.
• save_date(): 파일 생성을 위해 인자로 생성위치, 파일명, 파일에 들어갈 데이터를 넣어주었습니다.

2) S3 파일 이미지 업로드

• 왜 S3를 이용하였을까??
  저장 용량 무한대, 파일 저장 최적화, 정적 페이지 이용시 비용절감, HTTP프로토콜만으로 이미지 따운로뜨/DJQFHEM 가능!!

하지만,

가장 큰 이유는 버전 관리를 해야하기 때문입니다. 회사에서는 이력관리를 굉장히 중요시 여겼습니다. S3는 데이터를 여러 시설에서 중복으로 저장해 데이터의 손실이 발견할 경우 혹은 사용자에 의한 실수로 인한 손실일 경우에도 복원이 가능한 기능이 있어 택하게 되었습니다.

secure_filename(): 파일이름 같은 경우에 업로드 되는 디렉토리를 ../../ 몇번으로 해킹 공격에 대한 이슈가 있기 때문에 이름이 안전 한가를 확인해주는 Secure_filename 메소드를 이용하였습니다. secure_filename() 메소드가 이 디렉토리를 변경하여 리턴을 해줍니다.

3) 변경 이력 관리

이전 프로젝트와 달리 회사에서 요구사항으로 이력 관리를 구현해야했습니다.

처음에 프로젝트 모델링도 약 50개가 되는 마당에...
이력관리....??그거 어떻게 하는 거임..ㅠㅠ😂 이랬던 기억이 있습니다.

하지만 불굴의 의지를 가지고 김기창님의 관계형 데이터 모델링 프리미엄 가이드 책을 보면서 조금씩 감이 잡히기 시작했습니다.

프로젝트를 진행하면서 이력관리를 하려는데...

이게 무슨일이야....이력관리를 하려니까 문제가 생겼었습니다.

왼쪽은 n차적 모델링 완성입니다.
그리고 오른쪽 실제 개발에 적용된 모델링입니다.

원래는 sellers테이블에 하니에서 과거데이터와 현재데이터가 함께 존재하는 변경 이력을 관리 하려하였습니다.

기존 테이블처럼 sellers테이블 하나에 다 컬럼을 모아두면 누가 누구의 과거데이터인지 현재데이터인지 구분을 할 수 가 없었습니다.
마감이 얼마 남지 않자 심각성을 깨닫고 팀원들에게 건의를 해서 테이블을 수정하는 작업을 하였습니다.

상의 끝에 최초 가입시 주어지는 고유한 id값을 sellers테이블에 pk로 두고 seller_informtaions에는 그 고유 seller_id값을 참조하며 누구의 과거, 현재 데이터인지 알 수 있게 테이블을 위와 같이 변경하였습니다.

과거 이력:

• 현재 디비에 저장되어 있는 셀러에 대한 정보를 그대로 가져와서 insert한다.
• 단 , experied_at만 변경하려는 현재 날짜로 한다.

수정 이력:

• 기존에 가입했을 때 insert되었던 row에 반영한다.
• 현재 즉 최신 데이터였던 row는 계속 해서 최신 데이터로 유지되도록 ‘9999년 12월 31일 23:59:59”로 고정 시켜놓는다.

소감

초반에 위코드에서 1차, 2차 프로젝트를 하면서와는 다르게 많은 테이블을 다루고 심지어 FLASK도 처음 써QHKtTMQSLEK.
그래서 초반에 허둥지둥대기도 하고 책상에 머리도 박고 있는 날도 많았습니다.

그런데, 매일 퇴근후에도 집에서
불코딩을 하며 새벽 3-4시에 자는게 일상이 되었습니다.

추석도 껴있는 바람에 본가에서 밥만
먹고 서둘러
집으로와
코딩했었습니다.

지금껏 살면서 제일 열심히 살았던 BEST5에 들어갑니다.

그만큼 후회하지 않습니다.
하지만,내 코드를 다른 사람에게 설명해주는 건 아무리 노력해도
잘 안돼서
그 부분을 연습을
할려고 합니다.

5주간 첫 회사생활이라 걱정도 되고, 때론 설레는 일도
많았습니다.

그리고 기술적으로도 django만 써서 걱정했는데,
누가 가르쳐주지도 않았고 도와주지 않았지만
혼자 스스로 MYSQL과 FLASK도 다뤄보고 자신감이
조금 생겼습니다.감사합니다.성장시켜주셔서

개발자는 평생을 공부해야한다는 말이 두려울 때도
있지만 할 수 있다는 마인드를 DJEDJtTMQSLEK.

팀원들과 함께 아침마다 회의하고 힘들때 시시콜콜한 얘기도 했었습니다.
다들 더더 화이팅하시고 응원하겠습니다.👍