학습자료 | Project-3rd - 수행 안내 가이드; 전반적 flow

필요한 사전 행정/기획 소요
개발자가 실무에서 마주해야하는 다양한 업무 프로세스
개발 과정 내내 늘 참고서로 활용될 다양한 행정 문건을 직접 작성하고 활용

목차 

---

1. 시나리오 기반 BM(Business Model) 선정

주어진 시나리오에 기반하여, 구현할 비즈니스 모델을 선택하는 단계

A. 시나리오 확인

• 어떠한 배경속에서 탄생하게된 제품 기획인지 해당 시나리오를 확인하고 분석하는 단계
• 핵심 기능과 제품, 대상을 선정하여 어떠한 도메인으로 프로젝트를 진행 할 지 결정하는 단계
• 각 팀은 아래 4개의 시나리오 중 하나를 선택받아 3차 프로젝트를 진행하게 됩니다.
• Case Scenario Options

Case Scenario Options

B. 비즈니스 모델 기획

• 3차 프로젝트 기간동안 직접 해결해 나갈, 비즈니스 모델을 선정하여 구체적으로 기획하는 단계
• 특정 문제를 마주하였을 때, 해당 제품의 어떠한 기능이 그 문제의 열쇠가 될 수 있을지 분석하는 단계

---

2. 기능 요구 정의

팀 내에서 선정한 기능의 기획 내용 구체화

A. 사전 기획 / 문서화 작업:  가상의 요구사항 정의서 작성

• 기능 요구 정의서란?
  • 소프트웨어 개발 프로젝트나 시스템 구축 프로젝트에서 필요한 기능을 명세하는 문서
  • 프로젝트 팀과 고객 또는 사용자 사이의 의사소통을 원활하게 
  • 개발 과정에서 필요한 기능들을 명확하게 정의 -> 프로젝트의 목표를 달성하기 위한 방향성을 제공
  • 개발자들이 요구사항을 이해하고 구현할 수 있도록 도와주며, 고객 / 사용자들이 원하는 기능이 충족되었는지를 검증하는 기준으로 사용됩니다.
• 기능 요구 정의서 포함 내용:
  1. 시스템 개요: 프로젝트의 목적과 범위, 주요 기능에 대한 개요를 설명합니다.
  2. 기능 목록: 필요한 기능들을 상세히 나열하고, 각 기능에 대한 설명과 우선순위를 제공합니다.
  3. 사용자 요구사항: 사용자의 요구사항과 기대하는 기능을 명시합니다.
  4. 비기능적 요구사항: 시스템의 성능, 보안, 안정성 등과 같은 비기능적인 요구사항을 명시합니다.
  5. 시나리오: 사용자의 시나리오나 사용 사례를 통해 기능을 설명하고, 예상되는 동작과 결과를 기술
  6. 제약 사항: 기술적인 제약 사항이나 제한 사항을 명시합니다. 예를 들어, 사용되는 플랫폼이나 기술 스택, 하드웨어 요구사항 등을 기술할 수 있습니다
  7. 우선순위와 일정: 기능들의 우선순위와 개발 일정을 명시하여 개발자들이 작업을 조직할 수 있도록 도움을 줍니다.

• 다음의 예시 작업물을 참고하여서, 우리의 웹 서비스 제품이 필요한 기능을 일목요연하게 정리

• 인프라 아키텍처 설계 도식화 작업
  • 고객이 만족하는 제품은 좋은 인프라 아키텍쳐 설계에서 나오기 마련입니다.
    • [참고] 백엔드 인프라 설계가 중요한 8가지 이유
      1. 성능과 응답 시간: 고객은 빠른 응답 속도와 우수한 성능을 기대합니다. 백엔드 인프라 설계가 최적화되어 있지 않으면 시스템이 느려지거나 응답이 느려질 수 있습니다. 예를 들어, 온라인 상점에서 고객이 제품을 구매할 때 결제 처리 시스템이 느려지면 고객은 당황하고 실망할 수 있습니다. 따라서 백엔드 인프라는 고객의 요청에 신속하고 효율적으로 응답할 수 있도록 설계되어야 합니다.
      2. 확장성: 고객의 비즈니스가 성장하면 시스템도 함께 성장해야 합니다. 백엔드 인프라 설계는 확장성을 고려하여 스케일링이 용이하도록 해야 합니다. 예를 들어, 소셜 미디어 플랫폼에서 신규 사용자가 급증할 경우, 백엔드 시스템은 이에 대응하여 수많은 동시 접속과 데이터 처리를 처리할 수 있어야 합니다. 만약 백엔드 인프라가 확장성을 고려하지 않은 설계라면 시스템이 불안정하거나 다운될 수 있으며, 이는 고객에게 신뢰성과 사용성 면에서 좋지 않은 경험을 제공할 수 있습니다.
      3. 안정성과 신뢰성: 고객은 안정적이고 신뢰할 수 있는 서비스를 원합니다. 백엔드 인프라 설계는 시스템의 안정성과 신뢰성을 보장해야 합니다. 예를 들어, 은행 애플리케이션에서 고객은 자신의 계좌 정보와 거래 내역을 안전하게 보호받을 것을 기대합니다. 백엔드 시스템이 취약점이 많거나 보안에 취약한 설계라면 해커의 공격을 받을 수 있으며, 이는 고객의 개인정보 유출이나 금전적 피해로 이어질 수 있습니다. 따라서 백엔드 인프라 설계는 보안 강화와 신뢰성을 고려해야 합니다.
      4. 유지보수 용이성: 백엔드 인프라는 시간이 지나며 변화하는 비즈니스 요구사항에 대응해야 합니다. 고객은 유지보수 및 기능 추가/변경이 용이한 시스템을 원합니다. 예를 들어, 온라인 쇼핑몰에서 새로운 결제 시스템을 도입하려고 할 때, 백엔드 인프라가 모듈화되고 잘 구조화된 설계라면 새로운 결제 시스템을 쉽게 통합하고 확장할 수 있습니다. 이는 고객이 비즈니스 요구사항을 신속하게 충족시킬 수 있는 능력을 제공하며, 결과적으로 고객 만족도를 높일 수 있습니다.
      5. 비용 효율성: 적절하게 설계된 백엔드 인프라는 시스템의 확장이 용이하고 비용 효율적입니다. 시스템이 예상치 못한 트래픽 부하에 직면하거나 사용자 수가 급증할 때, 추가 서버 또는 리소스를 쉽게 확장할 수 있는 인프라 설계는 비용 절감과 시스템 성능 개선에 도움이 됩니다. 이는 고객에게 안정적이고 원활한 서비스를 제공할 수 있는 장점을 제공합니다.
      6. 유연성과 기술 혁신: 백엔드 인프라 설계가 유연하고 혁신적인 기술을 적용할 수 있는 구조라면, 새로운 기술 및 도구를 도입하고 기존 시스템을 개선할 수 있습니다. 이는 기술적인 발전에 발맞춰 고객에게 더 나은 서비스를 제공하고 경쟁 우위를 유지할 수 있는 기회를 제공합니다.
      7. 확장 가능한 데이터 관리: 백엔드 인프라 설계는 데이터 관리를 위한 효과적인 방법을 제공해야 합니다. 데이터의 수집, 저장, 처리, 분석, 보안, 백업 등을 효율적으로 관리할 수 있는 구조를 갖추어야 합니다. 이는 고객의 데이터에 대한 안전성과 개인정보 보호를 보장하며, 데이터 중심의 비즈니스에서 경쟁력을 확보하는 데 도움을 줍니다.
      8. 인프라의 유연한 구성 관리: 고객은 인프라 구성을 유연하게 관리하고 운영할 수 있는 기능을 원합니다. 백엔드 인프라 설계는 클라우드 컴퓨팅, 컨테이너화된 환경, 오케스트레이션 도구 등의 기술을 활용하여 인프라를 효율적으로 관리하고 자동화할 수 있는 기능을 제공해야 합니다. 이는 고객이 인프라 자원을 효율적으로 활용하고 운영 비용을 최소화할 수 있는 장점을 제공합니다.
  • 보다 효과적이고 능률이 높은 업무 프로세스를 위해서, 전체 프로젝트 웹서비스의 인프라 / 설계구도를 도식화 합니다.
  • 각 기능별 API는 어떠한 웹 서비스의 인프라 / 설계구도 속에서 동작하는지 모든 팀원들의 동기화를 이루어 냅니다.
  • 아래 설계의 도식화 예시를 참고하여 팀별 고유의 아키텍쳐 도식화를 완성해주세요!
  • [참고] AWS를 이용한 인프라 설계 예시
•  

 

3. API 목록 정리

앞선 기능요구서와 설계 기획을 바탕으로, 실제 제품내 필요한 API 요청-응답 내용을 정의하는 단계

A. 웹 서비스에서 API 정의

Web / App 서비스에 있어서 API란 무엇 일까요?

사용자가 서비스를 원활하게 이용하기 위해서

필요한 운영체제 혹은 서버에서 실행되고 있어야하는 애플리케이션은 크게 3가지를 얘기할 수 있습니다.

 

1. 사용자에게 웹 사이트를 표출하기 위해서 필요한 클라이언트 애플리케이션(Chrome 브라우저)

2. 인스타그램 서비스의 모든 정보가 저장되어 있는 데이터베이스 애플리케이션(MySQL, Oracle, Postgres)

여기서 브라우저는 여러가지 이유로 데이터베이스에서 서비스에 필요한 정보들을 직접 요청해서 받아올 수 없습니다.

3. 그렇기 때문에 중간에서 소통해줄 수 있는 인터페이스가 필요합니다. 바로 이러한 소통의 역할을 해주는 응용 프로그램(애플리케이션)이 API 

 

B. API 기능 정의 상세 정리

• 아래의 항목을 포함하여 전체 API의 기능을 정리한 도표를 작성합니다.
• 이렇게 정리된 도표는 프론트/백엔드 개발 팀 모두가 상호간 통신을 할 때 , 필요한 요청과 응답의 조건을 한 눈에 볼 수 있다는 이점이 있습니다.
  • 카테고리
  • 상세 설명
  • 로그인 필요 여부
  • HTTP 메소드
  • 호출 RESTful API 엔드포인트
  • 전송시 데이터(Content Type) 타입

 

 

C. 웹 서비스 PET 분석

• 위 내용이 완성된 후, 주어진 시나리오에 기반하여 제품, 고객, 기술 중심의 PET 분석을 진행합니다.
• 이를 통해 API 별 구성 요소에 기획 의도와 선정 배경을 더욱 구체화하여 정리합니다.

영화 예매 사이트 PET 분석 예시

4. API Endpoint Archicecture | Front + Back

API 기능별 사용자의 동선과 흐름을 상세히 그려내는 단계입니다.

A. API Flow Chart를 그려야 하는 이유

yes/no로 간단하게 

• API 기능별 동작을 수행하는 단계에서, 요청-응답의 중간 단계 흐름의 모든 경우의 수를 그리는 작업입니다.
• 올바르게 요청을 했을 때 뿐만 아니라 의도한 예외 사항 또한 상세히 기술하여서, 향후 개발작업에 문제가 없게끔 유도합니다.
• 해당 도식화 작업을 통해 사내 제품의 비즈니스 로직과 그 흐름을 상세히 표현해 낼 수 있습니다.
• 다음의 예시를 통해서, 우리 프로젝트에서 구현하는 제품의 전체 구조와 흐름을 구현해냅니다.

[참고 1] 회원 가입 Flow 예시

[참고 2] 예외처리 적용 Flow 예시

 

5. Dataset 설정 | Front + Back

앞서 기획한 각 API 별 필요한 데이터를 정의 내리는 단계입니다.

A. 데이터 종류 / 타입 세부 설정

• 프론트엔드와 백엔드가 API 요청-응답 Flow 내에서 서로 주고받아야하는 데이터를 정의합니다.
• 이때 어떠한 데이터 종류와 타입을, 어떠한 데이터 구조로 주고 받는지 확정 짓습니다.
• [참고] 기능 별로 필요한 데이터 선정 (수상 택시 API 예시)
  • 유저 데이터
    • 이름
    • email
    • 비밀번호
    • 등등
  • 택시 데이터
    • 운영 회사
    • 이름
    • 좌석 수
    • 등등
  • 예약 데이터
    • 예약 날짜
    • 예약 한 사람
    • 승객 정보
    • 예약 택시 정보
    • 등등

6. Page 기획 정리 | Front

---

앞선 단계에서 잘 정의된 UserFlow에 맞게 각 페이지별 디자인, 레이아웃 기획을 설정하는 단계입니다.

A. 페이지 별 기획 정리

• UX/UI 를 고려하여 정리된 User Flow를 페이지별로 어떻게 구현해낼지 기획하기
  • 각 페이지를 어떠한 디자인으로 기획해야하는지 고민합니다.
  • 사용자의 동선에 따라 어떻게 page가 이동하는지 고민합니다.
  • 어떤 페이지에서든지 공통으로 필요한 부분은 없는지 고민합니다.

B. 페이지 디자인, 레이아웃 기획 적용

• Figma 등을 이용한 최소한의 디자인 프로토타입 완성 및 문서화
• 최소한의 디자인 툴을 이용하여 프로젝트 내 페이지별로 어떻게 디자인 할 지 고민하여 표현해냅니다.
• 해당 디자인 툴은 모든 개발팀에게 실제 모델의 초안을 제공하기 때문에 유용하게 활용될 수 있습니다.

[참고] Nike 피그마 모델링 예시

 

 

7. DB ERD 모델링 | Back

앞선 단계에서 잘 정의된 DataSet에 맞게 데이터베이스 ERD/schema를 모델링 

A. DB ERD / Schema 모델링

• 요구된 기능에서 정의한 데이터들을 어떠한 관계도 속에서 표현할지 고민합니다.
• ERD 다이어그램 그리기 툴을 이용하여 도식화 합니다.
• 해당 ERD와 스키마는, 데이터 관련 기획 변경이 생길 때마다 실시간으로 수정 반영을 하여서 데이터 관리의 청사진의 역할을 할 수 있게 유도합니다.

 

8. API Documentation 작성

최종적으로 기능 동작이 되는 엔드포인트에 대한 API 명세서를 작성하는 단계입니다.

A. API Documentation이란?

“API 문서화”란 백엔드가 작성한 각각의 API 기능을 문제없이 사용하기 위해서,

개발자간 어떠한 구성 요소를 주고 받아야하는지 일목요연하게 정리하는 작업

 

전통적인 행정 업무 방식을 따라

각각의 API가 지닌 특성들을

구두로 혹은 직접 작성한 문서로 주고 받기에는 불편함이 많을 것 

 

개발 작업 특성상 서로 간 공유해야하는 수많은 내부 요소들이 있고,

이들 중 단 한 개라도 누락이 되면 정상 기능을 방해하는 오류가 발생하기 때문

 

이러한 불편함을 해소하고자

많은 개발자들이 API를 자동으로 문서화 할 수 있는 방안을 고안해내었고,

그 결과 많은 제품들이 출시

 

이제 API Documentation은

서로의 통신 내용을 직관적으로 파악할 수 있게끔하는

웹 개발자의 필수 보조 작업물이 되었습니다.

 

API를 문서화 함으로써 얻을 수 있는 개인의 장점은,

자신의 작업물을 다른 사람과 보다 효율적으로 공유할 수 있다는 점 

 

대게 잘 작성된 API 기능정의서에는

목적 / 의도 / 엔드포인트 / API별 필수 인자 등에 대한 세부 정보가 구조화

(개발자는 물론 일반 사용자 까지 모두 이해하기 쉬운 형식으로)

 

개발자 개인이 직접적으로 타인과 소통해야만 하는 빈도를 확연히 줄여줄 수 있고,

그 결과 일의 능률을 높일 수 있습니다.

 

또한 사용자로 하여금 다양한 요청-응답 방식을 더 잘 이해할 수 있게,

관련 예제나 영상도 같이 업로드 하기도 하는데,

이는 초기에 소비한 시간 이후의 학습 비용은 최소화됨을 의미합니다.

 

B. API Documentation의 구성 요소

API 문서: API를 효과적으로 사용하는 방법에 대한 지침서

 

내가 선택한 API로 작업하는 데 필요한 모든 정보가 포함된 참조 매뉴얼

 

포함해야 할 주요 필수 내용

• 해당 API의 사용 예시
• URI (엔드포인트)
• 샘플 request 양식
• request 파라미터
• 샘플 response 양식
• response 파라미터
• 에러 핸들링 정보

 

C. API Documentation 문서화 작업

• 선택1 - 기초) Postman을 이용한 문서 정리
  • 간편 GUI 형태로 설정가능한 Postman을 이용한 API 문서화 방법입니다.
  • 모든 교육생 분들이 최소한으로 만들어 배포까지 해야하는 문서화 방법입니다.
• 선택2 - 심화) Swagger 툴을 이용한 문서 정리
  • API 코드와 연동되어 각 API 별 필요 내용을 정리해주는 Swagger를 이용한 API 문서화 방법입니다.
  • 작업 시간에 비교적 여유가 있을 때 해당 방법을 사용합니다.

[참고] Postman 결과 예시

 

[참고] Swagger 결과 예시