[데브코스 웹 풀스택 과정 TIL] 19주차 - 웹에디터 제작 프로젝트 (1) - 설계

요구사항 명세서 (SRS - Software Requirement Specification)

요구사항 명세는 프로젝트에 있어 가장 중요한 것이라 할 수 있겠다. 프로젝트의 목표가 클라이언트의 일련의 요구사항을 만족하는 소프트웨어를 개발하는 것이기 때문이다.

그런데 이 요구사항이 고정된 것이 아니라 여러 이유들로 인해 프로젝트 수행 도중에도 변경될 수 있고, 이에 따라 세부 구현 사항이 바뀔 수 있으며 때에 따라서는 전체 구조를 바꿔야 하는 경우도 생긴다. 또 테스트케이스를 작성할 때에는 클라이언트의 요구사항을 반영해야 하고, 이론상으로는 명세된 요구사항을 전부 반영하는 테스트케이스를 만들어야 한다. 물론 현실적으로는 이렇게 하기는 힘들긴 하다. 여기서 참고할 만한 개발 기법에는 TDD(=Test-Driven Development)가 있다. 

TDD란?: 요구사항을 먼저 도출하고 테스트케이스를 만든 다음에 본격적으로 테스트케이스를 만족하는 코드를 작성하는 순으로 이루어지는 개발 기법

그리하여 프로젝트의 시작은 클라이언트나 시장의 요구에 따라 소프트웨어 요구사항을 도출해 내는 것이라 할 수 있다.

그렇다면 요구사항 명세서는 무엇일까.

소프트웨어 명세서는 소프트웨어 구현물의 기능적/비기능적 요구사항을 기술한 문서이다. 

여기서 기능적 요구사항과 비기능적 요구사항이 등장하는데 각각 소프트웨어가 제공해야 하는 기능, 성능/자원 사용량 등에 존재하는 다방면에서의 제약을 말한다.

이 명세서는 워터폴 모델(폭포수 모델이라고도 함)의 소프트웨어 개발 프로세스에서 필수 산출물로 정의하고 있으나 애자일 방법론을 적용하게 되면 모델 특성상 민첩성을 위하여 산출을 생략하는 경우도 있다.

 

프로젝트 구성 (기술 스택)

Frontend

• React, Tiptap(참조)

Backend

• Express, JWT(사용자 인증에 사용)
• DBMS: MariaDB (11.2.2)
• CORS 정책 적용으로 악의적 접근 방지

배포

• Production: minikube on AWS EC2 instance (single-node k8s cluster), Terraform (설정 적용에 사용), Nginx (Reverse Proxy 구성에 사용, 하단 참조)
• Testing: Local k8s cluster with Docker desktop
• Selenium, Jenkins

서비스 모델 아키텍처

• 전체 아키텍처

Copyright 2024. Grepp inc. All rights reserved.

• Testing 환경

Copyright 2024. Grepp inc. All rights reserved.

실제 배포 시의 k8s 환경과 비슷하나, 테스트 환경의 차이점은

• 중간에 웹서버를 두지 않고,
• 인터넷 domain으로 접근 불가
• DB 인스턴스 또한 동일 클러스터 내에 배치
• SSL 인증을 거치지 않으며 JWT 쿠키 처리 방식에도 차이

가 되겠다.