프로젝트 프로세스 분석

안준성·2024년 4월 9일

back-end 개발 프로세스

Project::BoardPick

목록 보기

1/11

이번에 스위프 4기에 지원하면서
백엔드 개발자로서 프로젝트에 참여하게 되었다.

프로젝트를 시작하기 전에
전체적인 프로세스와
이를 위해 준비해야 할 사항들을 정리해보려 한다.

전체적인 프로세스

프로젝트 아이디에이션
기한에 맞는 프로젝트 목표 설정
기대 결과물
요구사항 분석
- 프로젝트의 비즈니스 목표와 사용자 요구사항을 명확히 이해하자.
- 프로젝트의 기능적 요구사항을 상세하게 문서화
기술 스택 선정
- 프로그래밍 언어와 프레임워크 선택
- 데이터베이스 시스템 결정
- 인프라 및 배포 방법 결정
시스템 아키텍처 설계
- 데이터 모델링
- 시스템 구조 설계
  - 마이크로서비스, 모놀리식 등의 시스템의 전체적인 구조를 설계
- API 설계
  - RESTful API, GraphQL 등의 API 인터페이스를 설계
개발 환경 설정
- 버전 관리 시스템 설정
- 개발 도구 및 라이브러리 설치 (버전 통일)
개발
1. 기능별로 모듈을 나누어 코드 작성
2. 단위 테스트
3. 코드 리뷰
통합 및 테스트
1. 모듈 통합
2. 통합 테스트
  - 시스템의 다양한 부분이 제대로 기능하는지 검증
3. 성능 테스트
  - 성능을 측정하고 최적화
배포 준비
1. 보안 취약점을 검토 및 조치
2. 배포 자동화 설정
  - CI/CD 파이프라인을 설정하여 코드 변경 사항을 자동으로 배포할 수 있게 함
배포 및 모니터링
1. 초기 배포
2. 모니터링 및 로깅
유지보수 및 업데이트
1. 발견된 버그 수정
2. 기능 개선 및 업데이트

기술 스택

서버 환경

호스팅 유형 (클라우드, 온프레미스, …)
운영체제 (Linux, Window, …)
서버 사양 (예상 트래픽에 맞는 CPU, RAM, 스토리지 용량 등)
DB 서버
웹 서버 및 애플리케이션 서버 선택(Apache, Nginx, Tomcat, JBoss, …)
보안 설정 (방화벽, SSL 인증서 구성, 보안 패치 관리 등)
백업 및 재해 복구 전략 수립
CI/CD 도구 선택

언어 및 프레임 워크

스프링 부트
- 스프링 시큐리티 : 인증 및 권한 부여를 위한 프레임워크
- 스프링 데이터 JPA : 데이터베이스 작업을 용이하게 하기 위한 라이브러리
- 스프링 배치 : 대규모 데이터 처리 작업을 위한 배치 프로세스 구현을 도움
- 스프링 클라우드 : 마이크로 서비스 아키텍처를 구축하기 위한 다양한 도구 제공

데이터 베이스

MariaDB: 오픈 소스이며 널리 사용되는 관계형 데이터베이스 관리 시스템(RDBMS)입니다. 대부분의 웹 애플리케이션에 적합
PostgreSQL: 강력한 오픈 소스 객체-관계형 데이터베이스 시스템으로, 복잡한 쿼리, 대용량 데이터, JSON 데이터 처리 등을 지원
MongoDB: 스키마가 없는 NoSQL 데이터베이스로, 유연한 데이터 모델을 필요로 하는 경우 유용

서버 인프라

AWS : EC2(가상 서버), RDS(관리형 관계형 데이터베이스), S3(스토리지 서비스) 등 다양한 클라우드 기반 인프라 서비스를 제공
Google Cloud Platform (GCP) : Google의 클라우드 서비스로, Compute Engine, Cloud SQL, Cloud Storage 등을 포함
Microsoft Azure : 가상 머신, SQL Database, Blob Storage 등을 포함한 클라우드 서비스를 제공

데이터 모델링

실제 세계의 정보를 데이터베이스 내의 구조로 표현하는 과정
데이터의 구조, 데이터 간의 관계, 데이터에 적용될 규칙을 정의
크게 3단계로 나누며 각 단계는 추상화 수준에 따라 다름
1. 개념적 모델링
  - 시스템에서 다룰 고수준의 데이터 개체(Entity)와 그 관계를 식별. 보통 ERD를 사용해 표현
  - 예시
    1. 데이터 개체 : ‘책’, ‘회원’, ‘대출’
    2. 관계 : ‘회원’은 여러 ‘책’을 ‘대출’할 수 있다.
2. 논리적 모델링
  - 개념적 모델을 바탕으로 데이터 구조를 더 상세하게 정의
  - 테이블, 키, 속성의 데이터 타입 등을 정의
3. 물리적 모델링
  - 논리적 모델을 실제 데이터베이스 시스템에서 구현할 수 있는 형태로 변환
  - 인덱스, 성능 최적화, 스토리지 구성 등의 물리적 구현 세부 사항을 고려
  - 예시
    - 책 테이블 : title에 대한 인덱스를 생성하여 검색 성능 향상
    - 대출 테이블 : 대출일에 대한 인덱스를 추가하여 최근 대출된 책의 조회 성능 향상

협업을 위한 GitHub 설정

GitHub 리포지토리 생성
브랜치 전략 수립
- Git Flow : 기능 개발, 개발, 출시, 유지보수, main 브랜치를 활용하는 전략
- GitHub Flow : 더 단순화된 방식으로, 기능별 브랜치를 생성하고 main 브랜치로 병합하기 전에 PR을 통해 코드 리뷰를 진행하는 방식
이슈 및 마일스톤 사용
- 이슈 관리 : 프로젝트에서 발생하는 버그, 개선사항, 새 기능 요청 등을 이슈로 등록하여 관리
- 마일스톤 설정 : 프로젝트의 주요 목표나 단계별 릴리스를 마일스톤으로 설정하여 진행상황을 추적
PR과 코드 리뷰
- PR 생성 : 새 기능 개발이나 버그 수정이 완료되면 main 브랜치로 PR 생성
- 코드 리뷰 : 팀원들이 PR을 리뷰하고 피드백 제공. 승인되면 메인 브랜치에 병합
GitHub Actions를 이용한 CI/CD 구성
- GitHub Actions 설정 : ./github/workflows에 YAML 파일을 생성하여 빌드, 테스트, 배포 등의 워크플로우를 자동화
- CI/CD 파이프라인 구축 : 변경 사항이 병합될 때마다 자동으로 테스트와 빌드가 수행되고, 조건을 만족하면 배포까지 이루어지도록 설정
프로젝트 문서화
- README 파일 작성 : 프로젝트의 목적, 설치 방법, 사용 방법, 기여 방법 등을 포함하여 중요 정보를 문서화
- 기여자 가이드라인 제공 : 외부 기여자가 프로젝트에 기여할 수 있도록 CONTRIBUTING.md 파일을 통해 가이드라인 제공
보안 및 액세스 관리
- 액세스 권한 설정 : 적절한 팀원에게만 액세스 권한 부여
- 보안 취약점 관리 : GitHub의 보안 알림 기능을 활용하여 프로젝트 의존성에서 발견되는 취약점을 관리

GitHub Actions

GitHub 리포지토리에 워크플로우 파일을 추가하여 진행.
워크플로우는 이벤트(ex. push, PR)에 반응하여 실행되는 자동화된 프로세스.
이 워크플로우는 .yml 또는 .yaml 파일 형식으로 정의되며, 리포지토리의 ./github/workflows에 위치해야 한다.

API 설계

프론트와 백엔드 간의 통신을 위한 RESTful API or GraphQL 설계
엔드 포인트, 요청 및 응답의 형태, 인증 방법 등을 고려
- 엔드 포인트 : 리소스에 대해 서버에서 외부로 노출되는 부분
- 요청 및 응답의 형태 : 서버와 클라이언트 간의 통신 규약. 일반적으로 요청에는 HTTP 메소드와 바디(데이터) 포함. 응답에는 상태 코드와 바디 포함
- 인증 방법 : 사용자가 누구인지, 사용자가 수행할 수 있는 작업을 결정
  - 세션 기반 인증
    1. 사용자가 로그인하면 서버는 세션을 생성해서 세션 ID를 쿠키를 통해 클라이언트로 전송.
    2. 클라이언트는 이후 요청에서 세션 ID를 전송
    3. 서버는 세션 저장소에서 찾아서 사용자 인증
  - 토큰 기반 인증
    1. 사용자가 로그인하면 서버는 토큰을 발행
    2. 클라이언트는 헤더에 토큰을 포함시켜 전송
    3. 서버는 토큰의 유효성을 검증
  - OAuth : 사용자가 별도의 로그인 없이 다른 서비스의 계정을 사용하여 로그인할 수 있게 하는 오픈 스탠다드 프로토콜 (Google 로그인 등)

보안 고려사항

데이터 암호화
API 보안
- 무단 액세스로부터 데이터를 보호, 정보를 안전하게 전송(모든 API 통신은 HTTPS(SSL/TLS)를 통해)
- 과도한 트래픽이나 DDos 공격등을 방지하기 위해 Rate Limiting과 사용량 제한 도입
인증 및 권한 부여 방법

안준성

안녕하세요

다음 포스트