[19주차 Day2] 스프린트 4 프로젝트: 오픈소스 기반의 웹 파이프라인 구축

반 히·2024년 7월 4일
TIL데브코스프로그래머스

데브코스

목록 보기
58/58
post-thumbnail

📚 Part 0 Intro

📁 웹 기반 문서 편집기 제작 프로젝트

📌 강의 (및 실습) 목표

🔗 React와 Express를 이용한 통합 프로젝트 수행

  • 지금까지 배운 기술을 활용하여 데이터베이스와 사용자 인터페이스를 포함하는 웹 응용 개발
  • 실제 사용을 염두에 둔 서비스를 개발 및 통합 (빌드, 테스트, 배포) 하는 과정을 자동화 파이프라인으로 구축

🔗 웹 개발 프로세스를 개발자 관점에서 이해

  • 소프트웨어 개발자 (프론트엔드, 백엔드) 로서 직접 맡아서 해야 할 일들과 그 범위
  • 타팀 (예: DevOps) 에서 수행하는 코드 개발 이외 업무에 대한 이해
    • 이것을 잘 알고 있는 것은 역할 정의 및 부드러운 협업과 효율 향상에 필요한 일
  • 프로덕션 환경을 고려한 응용 소프트웨어의 설계와 구현에서 염두에 두어야 할 점
    • 환경 구성 자동화를 통하여 도구의 지원을 받을 수 있는 부분과
    • 개발자로서 서로 다른 (개발, 통합 테스트, 프로덕션,....) 환경 구성에 주의해야 할 부분

📌 학습 포인트

  • 개발환경과 프로덕션 환경의 차이를 염두에 둔 프로그래밍은 중점에 해당
    • 웹 개발의 전체 싸이클을 한 프로젝트 내에서 경험하고자 하는 것이 이 과목의 주안점
  • CI/CD 관련으로 새로 도입되는 내용들이 있음
    • E2E 테스트, AWS 활용, 인프라 모니터링,...

📁 프로젝트 개요

📌 사용하는 기술 스택

  • Backend
    • Main framework: Express.js (v4.18)
    • DB: MariaDB 10.6.16
  • Frontend
  • Production deployment
    • AWS, Kubernetes, Minikube
    • Jenkins, Terraform, Selenium

📌 프로젝트 명세

  • 소프트웨어 요구사항 명세서
    • 개발할 소프트웨어(서비스)의 요구사항을 기술한 것으로서 전체 프로젝트의 출발점이 됨
  • 구조 설계서
    • BE-API 입/출력 및 동작에 대한 명세 (+소스 코드 패키지 구조)
    • FE - 컴포넌트 구분 및 계층 구조 명세 (+소스 코드 패키지 구조)
  • 상세 설계서
    • BE-생략
    • FE-각 컴포넌트의 기능 명세 및 와이어프레임 (스크린샷)

📌 개발 (및 그 이후) 과정의 흐름

  • 요구사항을 분석하고 소프트웨어 아키텍처를 설계한다.
    • 연습을 위한 프로젝트이기 때문에 아키텍처는 사실 제시되어 있음
  • 개발 환경을 셋업하고 뼈대만 있는 코드로도 (BE, FE 각각) 개발 단계 테스트가 가능함을 확인한다.
    • 단위 테스트를 확보하고 코드를 개발한다.
  • 배포를 위한 컨테이너 구조를 설계하고 이에 연관한 각 요소들을 테스트를 통해 확인한다.
    • 실제의 제품(서비스) 개발 프로젝트에서는 이 설계가 코드 개발보다 앞서 이루어져야 함
  • CI/CD 파이프라인을 구축하고 통합 (인수) 테스트 시나리오를 설계, 적용한다.
  • 코드 품질 (형태/기능)을 확보하기 위한 개선 및 기능 추가를 수행한다.
    • 지속적 유지보수와 자동화된 통합/배포 실습을 위해 도전과제를 활용하는 것을 추천

📁 소프트웨어 요구사항 명세서

📌 소프트웨어의 요구사항 명세서

  • 프로젝트에 있어서 가장 중요한 것
    • 개발자의 임무 ‒ 요구사항을 만족하는 소프트웨어를 개발하는 것
    • (잠깐!) 경험 많은 개발자도 프로젝트에 몰입하여 자칫 요구사항을 충실히 따라가는 일을 잊는 경우가 자주 있음
  • 주의할 점
    • 요구사항은 여러 가지 이유로 프로젝트 수행 도중 변경될 수 있음
      • 요구사항 변경에 따라 세부 구현 사항, 때로는 전체 구조에 변경이 생기는 경우도 있음
    • 테스트 케이스의 작성은 요구사항을 반영해야 하며, (이론적으로는) 명세된 요구사항을 빠짐 없이 반영해야 함
      • TDD: 요구사항 🡪 테스트 케이스 🡪 코드
    • 고객 (또는 시장) 요구에 따라 소프트웨어 요구사항을 도출하는 것이 프로젝트의 시작
      • 우리의 경우에는 이미 문서로 주어진 요구사항 명세를 분석하는 것으로 시작

📌 요구사항 명세서

  • Software Requirement Specification (SRS)
    • 소프트웨어 구현물의 기능적/비기능적 요구사항을 기술한 문서
      • 기능적 요구사항: 소프트웨어가 갖추어야 (제공해야) 하는 기능
      • 비기능적 요구사항: 성능, 자원 사용량 등에 존재하는 여러 측면의 제약
    • 워터폴 (waterfall) 모델의 소프트웨어 개발 프로세스에서 필수 산출물로 정의하는 것이지만, 애자일 (agile) 방법론을 적용하는 경우 민첩성을 높이기 위하여 산출을 생략하는 경우도 꽤 있음
  • Requirement-driven development 방식을 택하는 경우도 있음
    • 특히 mission critical system 등에서는 formal verification 방법과 조합하여 요구사항 만족을 엄격하게 검증하는 것을 중요시하고 있음
    • 웹 개발 맥락에서는 흔히 적용하는 방법은 아님

📌 우리의 요구사항 명세서

  • 기능적 요구사항에 대한 개괄적 설명
  • 적용 기술에 대한 지정
    • 일반적으로는 요구사항 명세서의 요소가 아니지만, 여기에서는 동일한 기술 적용을 훈련하기 위해서 지정하고 있음
  • 각 요소 기능에 대한 명세 (표)
  • 데이터베이스 스키마의 약식 표현
    • 이것도 일반적으로 요구사항 명세의 일부는 아니지만, 여기에서는 데이터베이스를 별도로 제공하므로 이의 스키마를 요구사항 명세서에 기술하였음
  • 백엔드 API 세트의 정의
    • 기능에 대한 설명은 생략하고 (이후 구조설계서에서 약간 상세화), 제공하는 리소스와 메서드를 나열


# 📚 Part 1 요구사항 분석과 구조 설계 --- ## 📁 응용 구조의 설계 ### 📌 전체 응용의 구성 #### 🔗 Frontend - React 응용으로 만들어져 UI 에 해당하는 부분을 서비스 - Backend 로 향하는 API 호출은 브라우저의 js 실행에 의해서 이루어짐 🡨 이 코드를 FE 가 제공

🔗 Backend

  • Express 응용으로 만들어져 데이터베이스를 이용한 데이터 모델을 서비스
  • JWT (JSON Web Token) 를 이용한 사용자 인증을 통해 데이터 접근을 보호
  • CORS (Cross-Origin Resource Sharing) 정책을 통해 악의적인 접근을 방지

🔗 Database

  • “prgms_notes” 라는 이름의 데이터베이스에 두 개의 테이블을 포함

📌 개발 환경의 구성

  • 코드를 변경할 때마다 로컬 테스트 환경에 배포하는 것은 부담스러운 일
    • 시간 소요: 개발 작업의 효율성이 떨어짐
    • 환경 설정 및 디버깅에 드는 수고: 코드가 어느 정도 구조를 갖추기 전에 구성을 확정하기 어려움
  • 개발 단계에서의 가벼운 테스트를 위한 환경 설정 필요
    • 단위 테스트 작성 및 활용 🡨 이것은 이후 CI/CD 를 위해서도 매우 중요한 일
    • 간단한 사용자 테스트: npm 을 이용해서 FE/BE 각각을 서로 다른 포트에서 서비스하도록 하고 테스트
    • (주의) 이 단계에서 적용되는 코드와 프로덕션 빌드에 적용되는 코드는 같지 않음
    • 배포 모델을 염두에 두고 유연한 설정을 적용할 수 있는 코드를 개발하는 것이 중요

📁 개발 환경과 배포 환경

📌 개발 환경의 운용

  • 개발 단계에서 빠르게 코드의 동작을 확인할 수 있는 것은 중요
    • 코드의 변경이 빈번함
    • 특정 부분의 코드를 구현하기에 앞서 다른 특정 부분의 코드 동작을 확인하는 것이 유리할 때가 꽤 있음
  • TDD 를 적용함으로써 효율을 상당히 높일 수 있음
    • 그러나 코드의 구조 또는 인터페이스의 변경이 예측 (또는 예상) 될 때에는 테스트 코드의 정비도 만만하지 않음
    • 요구사항을 명확히 반영하여 테스트 코드를 먼저 작성하는 일은 쉽지 않은 경우가 꽤 있음
      • 특히, 사용자 인터페이스를 다루는 코드는 단위 테스트에 한계와 어려움이 있음
  • 따라서, 코드의 동작을 눈으로 확인할 수 있는 환경을 구축하는 것이 필요

📌 데이터베이스 준비

  • 가능한 한 데이터베이스에 의존성을 갖지 않는 상태에서 코드를 개발하는 것이 수월
  • 그러나 어느 시점에 이르면 코드의 검증을 위해 데이터베이스의 상태가 필요
    • 예 1: 사용자 인증에 따른 동작이 올바른지를 검증하기 위해 (어디까지 피할 수 있을까?)
    • 예 2: BE 의 CRUD 동작이 올바른지를 검증하기 위해 (어디까지 피할 수 있을까?)
  • 스키마가 확정되어 있다면 데이터베이스를 조기에 마련하는 것도 좋은 방법
    • 우리의 프로젝트에서는 적용할만한 접근법
      • 데이터베이스의 구조가 매우 간단하고 변경될 가능성이 없어 보이며
      • 프로덕션 환경에는 이미 데이터베이스가 (빈 상태로) 제공된다고 하던데
    • (그러나) 프로덕션 데이터베이스를 테스트에 활용하는 것은 절대 있어서는 안 되는 일

-> 로컬 환경에서 테스트에 이용할 수 있는 데이터베이스를 마련하자

profile
반 히
이전 포스트

[19주차 Day1] 스프린트 4 프로젝트: 오픈소스 기반의 웹 파이프라인 구축

0개의 댓글