시리즈 설명
이 시리즈는 ab180의 PlanB(JoMinGyu)님이 작성하신 '백엔드가 이정도는 해줘야 함'을 토대로 프로젝트에 적용 시킨 것들입니다.
목표
- 백엔드가 이정도는 해줘야 함을 참고하여 프로젝트와 서버 아키텍쳐를 구성, 개발하여 애플리케이션 출시까지를 목표로 한다.
그동안의 프로젝트
-
서버 분산 없음
S3와 같은 데이터 저장소와 인스턴스 한 개로 구성
서버가 데이터를 못받거나 망가진 상황에서 개발을 아예 할 수가 없었음
19년 여름 세미나에서 API와 인증, DB 서버를 분리해야 한다는 것을 배움 -
저장소 관리 없음
브랜치 전략? git flow? 전부 없었음
전부 받고 전부 올리고 -
버젼 관리 없음
매 기능을 추가하고 추가 된 기능을 사용/테스트 해보려면 클라이언트와 서버 모두 로컬에서만 관리 되다보니 재빌드를 거쳐야 했음 -
테스트 없음
따로 테스트 코드를 확인하지 않고 개발
오류를 찾는 법은 일일이 로그를 확인 했는데 입력은 항상 개발자가 상상하지 못한 방향으로 들어올 수 있기에 테스트 해야한다고 19년 여름 세미나에서 배움 -
raw SQL 사용과 DB 때려박기
뭐 있나 그냥 쌩 SQL 때려박고 데이터도 모두 테이블에 때려박음
그때는 서비스 구성도 개발도 배포도 개판이라 문제가 없었지만 뭐가 어떻게 돌아가는지도 몰랐고 프로시져가 뭔지 ORM이 뭔지도 모름 -
개판인 배포
그냥 URL 열어두고 URL로 접속
서버 빌드하면 에러 뿜어냄 -
암호화와 인증 모름
세션, 쿠키, JWT, 난독화 등 개념은 알고 있었지만 어떻게 적용할지 몰랐음
2019년 여름 세미나에서 JWT와 난독화를 배움
2020년의 프로젝트
백엔드 개발자가 되겠다고는 했지만 지금까지 한 것들은 백엔드 개발자라기 민망한 수준
학교를 졸업하기 전 제대로 된 백엔드 프로젝트를 한번 구성 해보겠다는 생각으로 시작
- 이 글을 읽고서 방식을 따라하며 아키텍쳐를 구성 해보려고 함
왜 이런 아키텍쳐를 구성했는지가 백엔드 개발자에게 가장 중요한게 아닐까 싶다
암튼 화이링 화이링
2020 프로젝트 구성 계획
버전 관리 시스템의 결정
구상 중인 API 서버 설계와 실제 서버 아키텍처를 비교
프로젝트 관리
API 설계 방식과 원칙 결정, 직렬화 포맷 결정
사용자 인증 방식 결정
API 문서화와 스펙 설계 결정
애플리케이션 서버 기술 스택 결정
의존성 관리 도구 결정 Maven vs. Gradle
서버 컴퓨팅과 배포 방식 결정
데이터 베이스 결정
무중단 배포와 배포 자동화 결정
라이브러리 선정과 데이터 포맷팅 방식 결정
참고
