[프로젝트] 백엔드 개발자 - 기능 개발 프로세스

백엔드 직무 실무에서 새로운 기능을 개발하고자 하면, 요구사항 정리부터 구현까지 어떤 프로세스를 거치는지의 과정을 정리해본다.

---

신기능 추가 프로세스

1. 요구사항 수집 및 분석
2. 데이터 모델링
3. 프론트 개발자와 API 협의 및 문서 정리
4. DB, 백엔드 개발 및 테스트

---

 

1. 요구사항 수집 및 분석

 

1-1. 요구사항 수집

사용자들의 요구사항을 수집하고, 현실세계의 대상을 분석하여 데이터베이스 구축의 범위를 설정한다.

• 사용자 식별
• 데이터베이스 용도 식별
• 사용자 요구사항 수집 및 명세

요구사항 수집 방법

1. 실제 문서 수집 및 분석
2. 담당자와의 인터뷰
3. 설문조사
4. 비슷한 업무를 처리하는 기존의 데이터베이스 분석
5. 기타 방법 : 각 업무와 연관된 모든 부분 살펴보기

 

1-2. 기능 리스트 작성

수집한 요구사항을 정리하여 기능 리스트를 작성한다.

대분류	기능 목록	설명
회원 가입	이용 약관	이용 약관 정보 노출
	회원 가입	ID, PW, 이름, e-mail, 전화번호, 주민등록번호
로그인	로그인	ID, PW 인증을 통한 로그인
	ID 찾기	주민등록번호 or 전화번호로 ID 찾기
	비밀번호 찾기	ID로 비밀번호를 전화번호, 또는 메일로 찾기

 

 

 

2. 데이터 모델링

기능 리스트가 완성되면, 각 기능에 대해 데이터 모델을 정리한다.

 

2-1. ERD 모델 작성

= E-R 다이어그램, ERD(Entity Relationship Diagram)
데이터베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, 릴레이션 간의 관계들을 정의한 것

 

❗

서비스 구축에 앞서 ERD 모델에 가장 먼저 신경써야 하며, 이를 신경쓰지 않고 서비스를 구축한다면 골조 없이 건물을 짓는 것과 마찬가지이다.

• 앞서 정리한 요구사항을 기반으로 작성하는 모델이고, 이 ERD를 기반으로 데이터베이스를 구축한다. 
• DB 구축 후에도 디버깅, 프로세스 재설계 등의 경우 설계도 역할을 담당하기도 함
• 관계형 구조로 표현할 수 있는 데이터 구성에는 효과적이지만, 비정형 데이터는 충분히 표현할 수 없다는 단점

* 비정형 데이터 : 비구조화 데이터. 미리 정의된 데이터 모델이 없거나, 미리 정의된 방식으로 정리되지 않는 정보

 

2-2. ERD 작성 규칙

* 'B로 구성되어있다' = 'B를 포함하고 있다' 로 이해하면 쉽다.

• 부모-자식 관계 : A 테이블의 기본 키를 B 테이블이 가지고 있음  →  A테이블이 부모, B 테이블이 자식 테이블
• 실선 : 부모 테이블의 기본키를 자식테이블이 가지고 있으며 이를 기본키로 사용하는 경우
• 점선 : 부모 테이블의 기본키를 자식테이블이 가지고 있지만 이를 기본키로 사용하지 않는 경우

예시 자료 : 학생 테이블과 수강내역 테이블과의 관계

• <수강내역> 테이블이 <학생> 테이블 기본키를 외래키로 가지고 있음 ⇒ <수강내역> = 자식, <학생> = 부모
• <학생>테이블쪽 : 1을 뜻함. 하나의 학생
• <수강내역> 테이블쪽 : 0~N을 뜻함. '0~N개의 수강내역'

👉🏻

즉, 학생 입장에서는 '하나의 학생은 0~N개의 수강내역을 가진다.'

👉🏻

수강내역의 입장에서는 '0~N개의 수강내역은 하나의 학생에게 포함되어진다.'

•  실선 : <수강내역> 테이블에서 <학생> 테이블의 기본키를 자신도 기본키로 사용하고 있음

👉🏻

수강내역 테이블은 학생 테이블의 PK인 [ 학생ID ]를 FK로 가진다.

 

예시 2: 부서 테이블과 사원 테이블

• 부모 테이블 : <부서>, 자식 테이블 : <사원>
• ​점선 : 자식 테이블이 부모 테이블의 PK를 가지고 있지만 이를 PK로 사용하지는 않는다.
• 관계 : ​하나의 부서는 0~N 명의 사원을 가질 수 있다.
• ​사원 테이블은 부서 테이블의 PK인 부서번호를 FK로 가진다.

 

2-3. 대표적인 ERD Tool

• draw.io
• Gliffy

draw.io 예시 화면

 

 

 

3. 프론트 개발자와 API 협의 및 문서 정리

백엔드 개발자로서, 프론트에서 어떤 parameter 요청/어떤 URI 요청이 들어왔을 때 내가 어떤 결과를 돌려줄 것인지에 대해 프론트 개발자와 상세한 협의를 한다. 이를 통해 예외 케이스들과 예제 응답까지 간략히 정리한 API 문서를 작성한다.

필수적으로 들어가야 하는 항목은 Request Field, Field Type, Field Description 등이 있다. 

전통적인 방식은 excel 등을 사용하여 API 문서를 관리하는 것이지만, 최근에는 POSTMAN,  Swagger 등의 별도 툴을 사용하기도 한다.

* Swagger

API를 설계하고 문서화 및 테스팅하는 것이 가능한 프레임워크

• 무료 버전 / 상용 버전이 존재한다.
• 기능
  • API 디자인(설계)
  • API 빌드
  • API 문서화
  • API 테스트
  • API 표준화
• 오픈소스로 공개되어 있는 툴
  • Swagger Codegen : 서버와 클라이언트에 설계된 API 코드를 생성하는 툴
  • Swagger Editor : API를 설계 및 문서화하는 툴
  • Swagger UI : 설계된 API를 HTML 페이지로 확인할 수 있는 툴

 

 

 

4. DB, 백엔드 개발 및 테스트

개발과 동시에 테스트를 실행하게 된다.

• 단순 기능 테스트 (개발한 API 테스트) : 개발한 기능 하나하나에 대한 테스트
• 연관 기능 테스트 (신규 기능과 관련된 기능) : 회원가입, 로그인 개발 → 신규 회원 / 탈퇴한 회원의  로그인 가능 여부 등
• 통합 테스트 : 예상되는 회원의 시나리오를 가지고 일련의 프로세스를 한 묶음으로 통합 테스트 → 문제를 개발자에게 전달

이렇게 테스트가 세분화된 것만 보아도 알 수 있듯이, 실제 개발에서도 테스트가 매우 중요하다. 실제로 테스트 관련 QA 직무도 많이 생겨나고 있다.

 

 

 

---

참고자료

• https://mjn5027.tistory.com/43
• https://velog.io/@koo9b9h/29%EC%9D%BC%EC%B0%A8-ER%EB%AA%A8%EB%8D%B8ER%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8
• https://logical-code.tistory.com/145