감사합니둥.

GPT4를 구독하면 사용할 수 있는 GPTs를 여러 웹사이트 들을 이용하면 다양한 작업을 날먹 할 수 있다. 이번에는 프로젝트의 초기설계인 디자인, 일정, 여러 다이어그램, 기능 명세서를 작성해보겠다.

주제

이세계 아이돌 굿즈샵

(저의 의견과는 무관합니다) 실제 프로젝트에 도입하기에는 무리가 있으니 가상 프로젝트로 실험

요구사항 명세

UML, 요구사항 명세서, 개발 일정 GPTs - Software Architect GPT 요구사항 명세서, 개발 일정 마크업 시각화 - https://asciidoc.org/

굿즈 판매 아이돌의 최신 일정, 공지, 이벤트 정보 확인 특정 멤버의 생일이면 홈페이지에 이펙트 적용 타켓은 팬층

이런 내용을 잘 정돈해서 gpt에게 제공하면

= 요구사항 명세서: 아이돌 굿즈 샵
:sectnums:
:toc:

== 1. 서론

=== 1.1 목적
이 문서는 "아이돌 굿즈 샵" 프로젝트의 요구사항을 명세하고, 개발 팀과 이해관계자가 프로젝트의 목표와 기능을 명확하게 이해할 수 있도록 도와줍니다.

=== 1.2 대상 독자
이 문서의 대상 독자는 프로젝트 매니저, 개발 팀, UI/UX 디자이너, 그리고 프로젝트의 기타 이해관계자입니다.

== 2. 전체 설명

=== 2.1 제품 관점
"아이돌 굿즈 샵"은 특정 아이돌 팬덤을 대상으로 한 온라인 상점입니다. 사용자는 이 플랫폼을 통해 자신이 좋아하는 아이돌의 굿즈를 손쉽게 구매할 수 있으며, 아이돌의 최신 일정, 공지 및 이벤트 정보를 확인할 수 있습니다.

=== 2.2 제품 기능
- 사용자는 굿즈를 카테고리별로 탐색할 수 있습니다.
- 사용자는 특정 굿즈에 대해 자세한 정보를 확인할 수 있습니다.
- 사용자는 굿즈를 장바구니에 담고, 구매할 수 있습니다.
- 사용자는 아이돌의 최신 일정, 공지, 이벤트 정보를 확인할 수 있습니다.
- 특정 멤버의 생일에는 홈페이지에 생일 이펙트가 나타나며, 생일을 알릴 수 있습니다.

=== 2.3 사용자 클래스 및 특성
- **팬**: 특정 아이돌의 팬이며, 굿즈 구매 및 아이돌 정보에 관심이 많습니다.
- **일반 방문자**: 특정 아이돌에 대한 관심이 있으며, 굿즈 구매 의사는 있지만 적극적이지 않은 사용자입니다.

== 3. 구체적 요구사항

=== 3.1 기능적 요구사항
[width="100%",options="header"]
|===
|ID |요구사항 |우선순위
|FR1 |사용자는 굿즈를 카테고리별로 탐색할 수 있어야 한다. |필수
|FR2 |사용자는 특정 굿즈에 대해 자세한 정보를 확인할 수 있어야 한다. |필수
|FR3 |사용자는 굿즈를 장바구니에 담고, 구매할 수 있어야 한다. |필수
|FR4 |사용자는 아이돌의 최신 일정, 공지, 이벤트 정보를 확인할 수 있어야 한다. |필수
|FR5 |특정 멤버의 생일에 홈페이지에 생일 이펙트가 나타나며, 생일을 알릴 수 있어야 한다. |필수
|===

=== 3.2 비기능적 요구사항
[width="100%",options="header"]
|===
|ID |요구사항 |우선순위
|NFR1 |웹사이트는 사용자 친화적이어야 한다. |높음
|NFR2 |로딩 시간은 2초 이내로 유지되어야 한다. |높음
|NFR3 |웹사이트는 모바일 및 데스크톱 환경에서 모두 접근 가능해야 한다. |높음
|===

이런 코드를 준다. 이거를 변환하면

대충 이런게 나온다. 완벽하진 않지만 나름 잘 만든다.

여러 다이어그램

https://www.plantuml.com/ UML을 시각화 해주는 사이트

챗지피티에게 일정 UML을 받고

@startuml

skinparam componentStyle uml2

package "Implementation" {
    package "환경 설정 및 초기 구성" {
        [개발 환경 설정]
        [MySQL 데이터베이스 초기 설정]
        [프로젝트 저장소 설정]
    }

    package "백엔드 개발" {
        [REST API 설계 및 구현]
        [데이터베이스 연동]
        [아이돌 이벤트 및 생일 이펙트 관련 로직 구현]
    }

    package "프론트엔드 개발" {
        [사용자 인터페이스 설계]
        [프론트엔드 로직 구현]
        [사용자 경험 개선]
    }

    package "테스트 및 검증" {
        [단위 테스트]
        [통합 테스트]
        [사용자 테스트]
    }

    package "배포 및 유지보수" {
        [초기 배포]
        [지속적인 업데이트 및 유지보수]
    }

    [개발 환경 설정] --> [MySQL 데이터베이스 초기 설정]
    [MySQL 데이터베이스 초기 설정] --> [프로젝트 저장소 설정]

    [REST API 설계 및 구현] --> [데이터베이스 연동]
    [데이터베이스 연동] --> [아이돌 이벤트 및 생일 이펙트 관련 로직 구현]

    [사용자 인터페이스 설계] --> [프론트엔드 로직 구현]
    [프론트엔드 로직 구현] --> [사용자 경험 개선]

    [단위 테스트] --> [통합 테스트]
    [통합 테스트] --> [사용자 테스트]

    [초기 배포] --> [지속적인 업데이트 및 유지보수]
}

@enduml

사이트에 들어가서 코드를 입력하면 이런게 나온다.

이 외에도 클래스 다이어그램

유즈케이스 다이어그램

@startuml

class User {
  - username: string
  - password: string
  + browseGoodsByCategory()
  + viewGoodsDetails()
  + addToCart()
  + purchase()
  + viewIdolSchedule()
  + viewIdolUpdates()
  + viewNews()
  + participateInEvents()
}

class Goods {
  - name: string
  - description: string
  - price: float
  - category: string
  + viewDetails()
}

class Cart {
  - items: List<Goods>
  + addItem()
  + removeItem()
  + checkout()
}

class Idol {
  - name: string
  - schedule: string
  - announcements: string
  - events: string
  - birthday: Date
  + displayBirthdayEffect()
}

class Review {
  - user: User
  - rating: int
  - comment: string
}

class Community {
  - posts: List<Post>
  + shareOpinion()
}

class Post {
  - user: User
  - content: string
}

User -- Cart
User — Review
User — Community

Goods "1" — "many" Cart : in
Goods "1" — "many" Review : has
Idol "1" — "many" User : follows
Community "1" — "many" Post : has

@enduml

액티비티 다이어그램

@startuml

(*) --> "User: Selects Browse Goods by Category"
--> "System: Displays Goods by Category"
--> "User: Selects a Good"
--> "System: Displays Good Details"
--> "User: Adds Good to Cart"
--> "System: Updates Cart"
--> "User: Proceeds to Checkout"
--> "System: Processes Payment"
--> "System: Confirms Purchase"
--> "User: Selects View Idol Schedule"
--> "System: Displays Idol Schedule"
--> "User: Selects View Idol Updates"
--> "System: Displays Idol Updates"
--> "User: Selects View News"
--> "System: Displays News"
--> "User: Selects Participate in Events"
--> "System: Displays Events"
--> "User: Exits"

@enduml

등을 만들 수 있다.

디자인

웹사이트 디자인GPTs - DesignerGPT, Midjourney

korean virtual idol goods sales website design, simple, vivid

이렇게만 내용을 보내도

이런 웹사이트 디자인을 그려준다. 아직 완벽하게 구현은 못해서 참고만 하면 좋을 것 같다.

끝

지피티는 어떻게 사용하냐에 따라 결과가 천차만별인 것 같다. 누구는 좋다하는데 누구는 병X이다 라는 말이 나오는 이유인 것 같다.

이런 프로젝트 초기설계에도 잘 이용하면 좋을 것 같다만 아직까지는 부족한 점이 많아서 참고 선에서 끝내는게 적당해 보인다.

좀 더 지켜보자.

액티비티 다이어그램은 소프트웨어 개발이나 비즈니스 프로세스 등 다양한 분야에서 사용되는 그래픽 표현 방법입니다. 주로 시스템이나 비즈니스 프로세스의 작업(flow of activities)과 동작을 시각적으로 나타냅니다.

액티비티 다이어그램은 다음과 같은 주요 요소로 구성됩니다.

• 액티비티(Activity): 프로세스나 동작의 단계를 나타내는 요소입니다. 각 액티비티는 작업이나 활동을 나타내며, 동작을 수행하는 시스템의 일부분을 표현합니다.

• 시작 및 종료(Start and End): 프로세스의 시작과 종료 지점을 나타냅니다. 보통 시작 지점은 화면 상단에 원 형태로 표시되고, 종료 지점은 화면 하단에 원 형태로 표시됩니다.

• 흐름(Flows): 액티비티 간의 연결을 나타내는 화살표입니다. 화살표는 액티비티 간의 작업 흐름을 보여줍니다. 보통 화살표는 액티비티 간의 순서를 나타냅니다.

• 의사 결정(Decision): 조건에 따라 프로세스의 흐름을 제어하는데 사용됩니다. 조건이 만족되면 다른 경로로 흐름을 변경할 수 있습니다.

• 병합(Merge): 병합 지점에서 여러 경로의 흐름이 하나로 합쳐집니다. 여러 개의 화살표가 하나의 점에서 만나는 것을 통해 나타냅니다.

• 객체(Objects): 액티비티 다이어그램에는 작업을 수행하는데 필요한 데이터나 자원을 나타내는 객체도 표시될 수 있습니다.

액티비티 다이어그램은 시스템이나 프로세스의 동작을 이해하고 설명하는 데 유용하며, 요구사항 분석, 시스템 설계, 프로세스 개선 등 다양한 단계에서 활용됩니다.

클래스 다이어그램

클래스 다이어그램(Class Diagram)은 객체 지향 소프트웨어 개발에서 가장 널리 사용되는 구조적 모델링 도구 중 하나입니다. 클래스 다이어그램은 시스템의 클래스, 그들의 속성과 메서드, 클래스들 간의 관계 등을 시각적으로 표현합니다.

클래스 다이어그램은 다음과 같은 주요 요소로 구성됩니다.

- 클래스(Class): 시스템의 기본 구성 요소입니다. 클래스는 속성(데이터)과 메서드(행위)를 가지며, 특정 형태의 객체를 나타냅니다. 클래스는 직사각형으로 표시되며, 클래스 이름이 맨 위에 위치하고 그 아래에 속성과 메서드가 포함됩니다.

- 속성(Attributes): 클래스가 가지는 상태를 나타냅니다. 클래스 내의 데이터 필드로써, 클래스의 특징을 설명하는 변수나 상수를 포함합니다. 속성은 클래스 이름 아래에 표시되며, 일반적으로 이름과 데이터 타입으로 표현됩니다.

- 메서드(Methods): 클래스의 동작을 나타냅니다. 클래스가 수행할 수 있는 작업이나 기능을 정의하는 함수나 프로시저를 포함합니다. 메서드는 속성 바로 아래에 표시되며, 이름과 매개변수 목록, 반환 값 등으로 표현됩니다.

- 관계(Relationships): 클래스 간의 관계를 나타냅니다. 다양한 종류의 관계가 있으며, 가장 흔한 것들은 다음과 같습니다.

- 연관(Association): 클래스들 간의 연결을 나타냅니다. 일반적으로 클래스들 간의 데이터 교환을 나타냅니다.

- 상속(Inheritance): 상위 클래스와 하위 클래스 간의 관계를 나타냅니다. 하위 클래스는 상위 클래스의 속성과 메서드를 상속받습니다.

- 의존(Dependency): 한 클래스가 다른 클래스에 의존하는 관계를 나타냅니다. 한 클래스의 변경이 다른 클래스에 영향을 줄 수 있음을 의미합니다.

클래스 다이어그램은 소프트웨어 시스템의 구조를 이해하고 설계하는 데 사용되며, 객체 지향 프로그래밍의 기본 원칙을 시각화하는 데 유용합니다. 클래스 간의 관계와 특성을 명확히 나타내어 소프트웨어 개발자들이 코드를 구현하고 유지보수하는 데 도움이 됩니다.

선형 회귀(Linear Regression)란?

선형 회귀는 통계학과 기계 학습에서 널리 사용되는 회귀 분석 기법 중 하나입니다. 이는 입력 변수(또는 독립 변수)와 연속적인 출력 변수(또는 종속 변수) 간의 선형 관계를 모델링하는 것을 목적으로 합니다.

선형 회귀의 기본 가정:

• 선형성: 독립 변수와 종속 변수 간의 관계는 선형적이어야 합니다.
• 독립성: 각각의 독립 변수는 다른 독립 변수와 상관 관계가 없어야 합니다.
• 등분산성: 잔차(실제 값과 예측 값 간의 차이)는 모든 독립 변수에서 동일한 분산을 가져야 합니다.
• 정규성: 잔차는 정규 분포를 따라야 합니다.

선형 회귀의 과정:

데이터 수집: 연구자가 분석하고자 하는 데이터를 수집합니다. 데이터 전처리: 데이터를 정제하고 필요한 형식으로 변환합니다. 누락된 값이나 이상치를 처리합니다. 모델 선택: 선형 회귀 모델을 선택하고 독립 변수를 결정합니다. 모델 피팅: 모델 파라미터(회귀 계수)를 학습 데이터에 맞춥니다. 이는 주로 최소 제곱법(Ordinary Least Squares)을 사용하여 수행됩니다. 모델 평가: 모델이 얼마나 잘 데이터를 설명하는지를 평가합니다. 주로 잔차 분석, 결정 계수(R-squared), AIC(Akaike Information Criterion) 등을 사용합니다. 모델 활용: 만들어진 모델을 사용하여 새로운 데이터에 대한 예측을 수행하거나 관심 있는 변수의 영향을 해석합니다.

선형 회귀는 간단하면서도 강력한 툴로, 경제학, 의학 등 다양한 분야에서 사용됩니다.

CNN

CNN, 또는 합성곱 신경망(Convolutional Neural Network)은 이미지 인식 및 패턴 인식을 위한 딥러닝 알고리즘 중 하나입니다. 이름 그대로 합성곱(Convolution) 연산을 사용하여 이미지의 특징을 추출하는 신경망 구조를 말합니다.

이미지 처리에서는 픽셀 간의 공간적 관계를 유지하면서 특징을 추출하는 것이 중요합니다. CNN은 이를 위해 입력 이미지에 대해 여러 개의 합성곱 층과 풀링 층을 쌓아 올립니다. 합성곱 층은 입력 이미지를 작은 필터로 슬라이딩하면서 특징 맵을 생성하고, 풀링 층은 특징 맵을 다운샘플링하여 계산 효율성을 높입니다.

이러한 구조는 이미지의 공간적 특성을 보존하면서도 차원을 축소하고 중요한 정보를 추출할 수 있게 해줍니다. 이를 통해 CNN은 이미지 분류, 객체 검출, 세그멘테이션 등 다양한 컴퓨터 비전 작업에 효과적으로 적용됩니다.

뿐만 아니라, 최근에는 자연어 처리 분야에서도 CNN이 활용되고 있습니다. 텍스트 데이터에 대한 합성곱 연산을 통해 문장이나 문서의 특징을 추출하고, 이를 바탕으로 감성 분석, 텍스트 분류, 기계 번역 등의 작업을 수행할 수 있습니다.

CNN은 이미지 및 텍스트와 같은 다양한 유형의 데이터에서 효과적으로 특징을 추출하고 패턴을 학습하는 딥러닝 알고리즘입니다. 이를 통해 컴퓨터 비전 및 자연어 처리 분야에서 다양한 응용이 가능하며, 현재 머신러닝 분야에서 널리 사용되고 있습니다.

전이학습과 전이학습 예제

전이 학습은 머신 러닝 및 딥 러닝 분야에서 중요한 개념 중 하나입니다. 이는 한 작업에서 학습된 모델의 지식을 다른 관련 작업으로 전송하여 성능을 향상시키는 기술입니다.

기본적으로 전이 학습은 두 가지 주요한 상황에서 사용됩니다.

• 작은 데이터셋 문제: 새로운 작업에 대해 충분한 데이터가 없는 경우, 처음부터 모델을 훈련하는 것은 어려울 수 있습니다. 이런 경우에는 대규모 데이터셋에서 사전 훈련된 모델을 사용하여 초기 가중치로써 모델을 초기화하고, 그 다음 새로운 작업에 대한 데이터를 사용하여 추가로 훈련하는 것이 효과적입니다.

• 유사한 작업: 사전 훈련된 모델이나 네트워크 아키텍처가 타겟 작업과 유사한 경우, 해당 모델을 사용하여 초기 가중치로써 모델을 초기화하고, 몇 개의 층을 동결하거나 재사용하여 특징을 추출하거나 수정하여 새로운 작업에 맞게 조정합니다.

전이 학습은 다음과 같은 여러 장점을 가지고 있습니다.

• 데이터 효율성: 새로운 작업에 대한 학습 데이터 양을 줄일 수 있습니다. 시간과 비용 절감: 처음부터 모델을 학습하는 대신, 사전 훈련된 모델을 재사용하여 더 빠르게 작업을 수행할 수 있습니다.
• 성능 향상: 사전 훈련된 모델은 보다 일반적인 특징을 학습하므로, 이를 새로운 작업에 적용할 수 있습니다.

전이 학습은 이미지 분류, 객체 감지, 자연어 처리 등 다양한 머신 러닝 작업에서 효과적으로 사용되고 있으며, 관련 분야에서 널리 사용되는 기술 중 하나입니다.

요구사항은 소프트웨어 개발, 프로젝트 관리 등 다양한 분야에서 핵심적인 역할을 합니다. 아래는 요구사항이 왜 중요한지에 대한 몇 가지 이유입니다.

• 목표 설정: 요구사항은 프로젝트의 목표와 범위를 명확히 정의하는 데 도움이 됩니다. 이는 프로젝트가 올바른 방향으로 진행되고 완료될 때까지 필요한 가이드가 됩니다.

• 의사소통: 요구사항은 프로젝트 팀 간에 명확한 의사소통을 가능하게 합니다. 모든 이들이 동일한 요구사항에 대해 이해하고 있을 때 혼란이 줄어들고 효율성이 증가합니다.

• 기대 관리: 요구사항을 충족시킴으로써 이해 관계자들의 기대를 관리할 수 있습니다. 이는 프로젝트가 완료될 때까지 고객이나 이해 관계자들이 만족할 수 있는 결과물을 제공할 수 있게 합니다.

• 품질 보증: 요구사항은 최종 결과물의 품질을 보장하는 데 도움이 됩니다. 정확하고 완전한 요구사항을 충족시키는 것은 최종 제품이나 서비스의 품질을 향상시키는 데 중요합니다.

• 변경 관리: 요구사항은 프로젝트가 진행되는 동안 변경될 수 있음을 인정합니다. 새로운 요구사항이나 변경 사항이 발생할 때 이를 효과적으로 관리하여 프로젝트의 성공을 보장할 수 있습니다.

요구사항은 프로젝트의 성패에 큰 영향을 미치는 중요한 요소이며, 이를 올바르게 관리하는 것이 프로젝트의 성공을 위해 필수적입니다.

요구사항 엔지니어링이란

요구사항 엔지니어링은 소프트웨어 및 시스템 개발 프로세스에서 요구사항을 정의, 관리, 분석 및 문서화하는 과정을 가리킵니다. 이는 소프트웨어나 시스템이 실제 사용자 또는 이해 관계자의 요구를 충족시키고 기대하는 기능을 제공하기 위해 필요합니다.

• 요구사항 수집: 사용자, 고객, 시스템 이해 관계자 등으로부터 요구사항을 수집합니다. 이는 인터뷰, 설문 조사, 워크샵 등 다양한 기법을 사용하여 이루어질 수 있습니다.

• 요구사항 분석: 수집된 요구사항을 분석하여 목표와 범위를 명확히 이해하고, 충돌하는 요구사항이나 누락된 부분을 식별합니다. 이를 통해 요구사항의 일관성과 완전성을 보장할 수 있습니다.

• 요구사항 명세화: 분석된 요구사항을 명확하고 이해하기 쉬운 형식으로 문서화합니다. 일반적으로는 요구사항 명세서나 사용자 스토리 등의 형태로 작성됩니다.

• 요구사항 검증: 명세화된 요구사항이 실제로 사용자의 요구를 충족시키는지 검증합니다. 이는 프로토타입, 시뮬레이션, 검사 및 검토 등의 방법을 사용하여 이루어질 수 있습니다.

• 요구사항 관리: 프로젝트가 진행되는 동안 요구사항이 변경될 수 있음을 인정하고, 이를 관리합니다. 변경된 요구사항을 적절히 관리하여 프로젝트 일정과 예산을 유지하는 데 도움이 됩니다.

요구사항 엔지니어링은 소프트웨어 개발 생명 주기의 초기 단계에 해당하며, 프로젝트의 성패에 큰 영향을 미치는 중요한 활동입니다.

요구사항의 종류

• 기능적 요구사항(Functional Requirements): 시스템이나 소프트웨어가 수행해야 하는 작업 또는 기능을 정의합니다. 예를 들어, 사용자가 로그인하고 데이터를 검색하고 주문을 생성하는 기능은 기능적 요구사항에 해당합니다.

• 비기능적 요구사항(Non-functional Requirements): 시스템이나 소프트웨어의 성능, 보안, 사용성 등과 관련된 특성을 정의합니다. 예를 들어, 응답 시간, 보안 요구사항, 사용자 인터페이스의 사용성 등이 비기능적 요구사항에 해당합니다.

• 시스템 요구사항(System Requirements): 전체 시스템에 관련된 요구사항을 정의합니다. 이는 소프트웨어나 하드웨어, 네트워크 등 시스템 전반에 관한 요구사항을 포함합니다.

• 사용자 요구사항(User Requirements): 최종 사용자 또는 고객이 시스템에 대해 원하는 것을 정의합니다. 이는 사용자의 기능적 및 비기능적 요구사항에 대한 설명과 기대치를 포함합니다.

• 비즈니스 요구사항(Business Requirements): 조직 또는 비즈니스의 목표와 필요를 정의합니다. 이는 조직의 비전, 전략, 프로세스, 규정 등에 관련된 요구사항을 포함합니다.

• 요구사항 우선순위(Priority Requirements): 요구사항이나 기능들에 대한 중요도 또는 우선순위를 나타냅니다. 이는 프로젝트나 제품 개발 중에 리소스 할당 및 작업 우선순위를 결정하는 데 사용됩니다.

이러한 요구사항 유형은 프로젝트의 성공적인 실행과 제품의 품질 향상에 중요한 역할을 합니다. 각 요구사항 유형은 프로젝트나 조직의 요구사항에 맞게 조정되어야 합니다.

요구사항 엔지니어링 프로세스

요구사항 엔지니어링 프로세스(Requirements Engineering Process)는 소프트웨어나 시스템 개발에서 요구사항을 수집, 분석, 문서화, 검증 및 관리하는 데 사용되는 체계적인 접근 방법입니다. 아래는 요구사항 엔지니어링 프로세스의 주요 단계를 요약한 것입니다:

• 요구사항 수집(Requirements Elicitation): 이 단계에서는 사용자, 고객 및 다른 이해 관계자들로부터 요구사항을 수집합니다. 인터뷰, 설문 조사, 워크샵 등 다양한 기법을 사용하여 요구사항을 식별하고 문서화합니다.

• 요구사항 분석(Requirements Analysis): 수집된 요구사항을 분석하여 목표와 범위를 이해하고, 요구사항 간의 충돌이나 누락된 부분을 식별합니다. 이를 통해 요구사항의 일관성과 완전성을 보장할 수 있습니다.

• 요구사항 명세화(Requirements Specification): 분석된 요구사항을 명확하고 이해하기 쉬운 형식으로 문서화합니다. 요구사항 명세서, 사용자 스토리 등의 형태로 작성됩니다.

• 요구사항 검증(Requirements Validation): 명세화된 요구사항이 실제로 사용자의 요구를 충족시키는지 검증합니다. 프로토타입, 시뮬레이션, 검사 및 검토 등의 방법을 사용하여 요구사항을 확인합니다

• 요구사항 관리(Requirements Management): 프로젝트가 진행되는 동안 요구사항이 변경될 수 있음을 인정하고, 이를 관리합니다. 변경된 요구사항을 추적하고 관리하여 프로젝트 일정과 예산을 유지하는 데 도움이 됩니다.

요구사항 엔지니어링 프로세스는 반복적이고 순환적인 특성을 가지며, 프로젝트의 생명 주기 동안 여러 번 반복될 수 있습니다. 요구사항 엔지니어링 프로세스를 체계적으로 수행함으로써 프로젝트의 성공 확률을 높일 수 있고, 최종 결과물의 품질을 향상시킬 수 있습니다.

FAST guidelines

FAST(Flexible, Appropriate, Simple, Testable)는 요구사항을 작성할 때 고려해야 하는 지침입니다. 이를 준수함으로써 요구사항이 명확하고 효과적으로 작성되고 구성될 수 있습니다. Flexible은 요구사항이 변경 가능해야 함을 의미하며, Appropriate는 요구사항이 해당 프로젝트나 제품의 범위와 목표에 적합해야 함을 의미합니다. Simple은 요구사항이 가능한 한 간단하고 명확해야 함을 의미하며, Testable은 요구사항이 검증 가능해야 함을 의미합니다.

Davis` Principles

Davis의 원칙은 소프트웨어 공학 분야에서 고려해야 하는 중요한 원칙들을 설명합니다. 이러한 원칙은 소프트웨어 개발 프로세스를 개선하고 효율적으로 관리하기 위한 지침을 제공합니다. Davis의 원칙은 다음과 같습니다.

• 처리 과정(Process): 소프트웨어 개발에 사용되는 프로세스는 표준화되어야 하며, 이를 통해 일관성 있고 효율적인 개발이 가능해집니다.

• 상호작용(Interaction): 소프트웨어 개발자와 고객 또는 사용자 간의 상호작용은 개발 프로세스의 핵심입니다. 이러한 상호작용을 통해 요구사항이 명확하게 이해되고 프로젝트가 성공적으로 완료될 수 있습니다.

• 변형(Variation): 소프트웨어는 다양한 환경과 요구사항을 충족시켜야 하므로, 다양성을 수용할 수 있는 유연한 구조로 개발되어야 합니다.

• 유연성(Flexibility): 소프트웨어 개발은 변화에 대응할 수 있도록 유연성을 가지고 있어야 합니다. 이는 요구사항의 변경이나 새로운 기술의 도입에 대응할 수 있는 능력을 의미합니다.

• 측정(Measurement): 소프트웨어 개발 프로세스와 제품의 질을 측정하는 것은 성공적인 프로젝트 관리의 핵심입니다. 측정을 통해 문제를 식별하고 개선할 수 있는 기회를 얻을 수 있습니다.

• 기술(Technology): 적절한 기술 및 도구를 사용하여 소프트웨어를 개발하는 것은 효율적인 개발과 유지보수를 가능하게 합니다.

• 변화(Change): 소프트웨어 개발은 동적이고 변화무쌍한 과정입니다. 이러한 변화에 대응하기 위해 프로세스와 제품은 지속적으로 조정되어야 합니다.

이러한 Davis의 원칙은 소프트웨어 개발의 복잡성을 이해하고 효과적으로 관리하기 위한 지침으로 사용됩니다. 이를 준수함으로써 프로젝트의 성공 확률을 높일 수 있습니다.

Use Case Model이란

Use case model은 소프트웨어 시스템의 기능을 사용자 시점에서 설명하는 모델입니다. 이 모델은 사용자가 시스템을 어떻게 사용하는지를 시나리오로 기술하여 시스템의 요구사항을 명확하게 전달합니다. Use case는 사용자의 목표를 달성하기 위한 시스템의 행동을 나타내며, 액터는 시스템과 상호작용하는 외부 개체를 나타냅니다. Use case model은 소프트웨어 개발에서 요구사항 수집, 분석, 설계에 활용되며, 시스템의 사용자 관점에서 시스템을 이해하는 데 도움이 됩니다.

Use Case 예시

웨이터, 고객, 출납원, 요리사 사이의 상호작용을 볼수 있다. 웨이터는 주문을 받고, 성사되면 요리사에게 음식을 요청하고 서빙을 한다. 고객은 음식(와인)을 주문하고 주문요청을 한고 음식을 먹은 후에 돈을 지불한다. 출납원은 돈을 받고 확인 후 결재를 한다. 요리사는 음식 주문을 확인 후 음식을 조리한다.

목표

언리얼 기본 캐릭터에 믹사모 애니메이션 적용시키기

Mixamo Converter 다운로드

Mixamo Converter Link

Mixamo Converter 사이트로 들어가서 다운 받고 원하는 곳에 압축을 풀어준다. 비밀번호는 terribilis

애니메이션 다운로드

Mixamo Link

다음으로는 믹사모에 들어가서 Upload Character를 누른 후 다운 받은 mixamo_converter - Mannequins - Manny unreal engine 5 - _SKM_Manny.FBX 를 드래그앤 드랍 한다.

그러면 이렇게 캐릭터가 등록이 되는데 Animation탭에 있는 원하는 Animation을 골라보면 잘 적용되는 것을 볼 수 있다.

원하는 애니메이션 선택 후 DownLoad - Skin을 Without Skin으로 - Keyframe Reduction을 uniform으로 바꿔주고 DOWNLOAD 버튼을 눌러준다.

적용

다운로드 받은 fbx를 IncomingFbx폴더로 옮겨준다.

다운 받은 Mixamo Converter에서 exe파일을 열어주고 아무데나 클릭 - Enter the conversion process - Click here to convert the animations - Open the folder with converted animations 를 눌러주면 OutgoingFbx 파일에 변환된 fbx 애니메이션 파일이 있는 것을 볼 수 있다.

이제 언리얼로 애니메이션을 드래그앤 드랍하고 Skeleton을 SK_Mannequin으로 바꾸고 import를 누르면

잘 적용된 것을 볼 수 있다.

끝

처음 언리얼을 배우고 막 애니메이션을 공부하기 시작할 때 많은 사람들이 믹사모를 이용할 것 같다. 도움이 됐길

그래서 믹사모에서 원하는 캐릭터를 찾아서 애니메이션까지 적용시켜봤다. 간단하게 방법을 알아보자.

목표

UE에 믹사모 캐릭터 와 애니메이션 적용시키기

믹사모 링크

우선 믹사모 Chracter 탭에 들어가서 원하는 캐릭터를 고른 후 다운로드한다. 그리고 Animation 탭에 들어가서 원하는 애니메이션을 캐릭터에 적용시켜준 후 Frames per Second를 60으로, Skin을 without Skin으로 바꾼 후 다운로드한다.

먼저 다운로드 받은 캐릭터를 먼저 원하는 폴더로 드래그앤 드랍한다. 그리고 나오는 창에서 Reset to Default - Skeleton이 None인지 확인 - (Mesh - advanced - Use TO Ref Pose 체크) - Import All 을 한다. 임포트하면 경고창이 뜨는데 무시해도 된다.

똑같은 방법으로 애니메이션도 드래그앤 드랍 한 후 옵션에서 Reset to Default - Mesh에 앞서 임포트한 Skeleton이 있는지 확인 - Import All 을 한다.

애니메이션을 씬으로 꺼내서 시작해보면 잘 움직이는 걸 볼 수 있다.

끝

쇼츠에서 봤던 영상이 이런 식으로 간단한 장면을 여러개 만들고 이어붙혀서 말과 자막이랑 적절한 브금을 넣어서 쇼츠를 만들지 않았나 싶다. 심심할 때 해봐야지

프로젝트 시작하기

레벨 생성

ContentBrowser 에서 Content 밑에 개인 폴더를 만든다.

개인폴더 밑으로 Level 폴더를 만들고 Level 폴더 안에 새 레벨 에셋을 만든다.

오른쪽 위에 Settings - Project Settings 를 열어주고 Maps & Modes - Editor Startup Map - 새 레벨 드래그앤드랍 을한다. 이렇게 하면 엔진을 껐다 켰을 때 이 레벨에서 시작하게 된다.

또 검색창에 virtual texture - Enable virtual texture support체크 를한다. 체크를 하게 되면 오른 쪽 밑에 재시작을 하라는 알림이 오면 재시작을 해준다. 방대한 양의 고품질 데이터를 사용하면서 사용되는 컴퓨터 메모리, 성능을 아껴줄 수 있는 기능이다.

라이트 구성

Env. Light Mixer - 5가지의 Create 버튼 클릭 을 하면 하나하나 구성할 필요없이 간편하게 라이트 구성을 할 수 있다.

Env. Light Mixer 창에서 간편하게 라이트 값들을 조절할 수 있다.

바닥 생성

좌측 상단 +모양에서 Shapes - Plane 을 생성한다. 위치를 0,0,0으로 바꿔주고 scale도 100,100,1로 바꿔주면 넓은 땅이 생기게 되고 시작버튼을 눌러보면 캐릭터가 자유롭게 땅 위를 움직일 수 있게 된다. 언리얼엔진에서 Scale은 실제 사람과 비례해서 만들어서 Scale값 1은 1M라고 보면 된다.

Quixel Bridge

소개

Quixel Bridge에는 수만개의 고해상도 모델링 들이 준비되어 있다. 다양한 컨셉의 모델링들이 많아 처음 시작할 때 아이디어 구상이나 초기 컨셉을 구상할 때 도움이 될 수 있다.

+버튼을 누르고 Quixel Bridge에 들어가고 우측 상단에 버튼을 눌러 로그인을 해준다.

Quixel Bridge에서 받아오는 에셋들은 대부분 고해상도 데이터들이기 때문에 계속해서 받아오다보면 용량부족 문제가 생길 수도 있다. 받아온 데이터는 한 번 저장을 하고 에디터 내로 복제해오는 방식이여서 파일 경로를 하드디스크나 다른 공간에 여유가 있는 경로를 걸어주면 좋다.

에셋 다운로드

검색창에 Warehouse를 검색한다.

7개의 상자들과 선반들을 선택 - Nanaite로 변경 - 다운로드 를 한다.

Add 를 눌러준다.

위에 박스 하나는 Add가 안되는 걸 볼 수 있다. 가끔 Nanaite를 지원하지 않는 것들이 있어서 High Quality로 바꿔서 Add를 하면 된다.

다운로드 받은 에셋들은 Contents - Megascans - 3D_Assets 폴더에 저장되고 Static Mesh만 체크한 후 드래그해서 사용하면 된다.

Static Mesh 란 3D오브젝트 데이터로 3개의 텍스쳐를 가진 머티리얼을 가지고 있다.

최적화 팁 - 텍스쳐 용량 최적화

다운받은 텍스쳐를 보면 200MG를 상회할 정도의 용량을 가지고 있고, 8192x8192라는 고해상도인 것을 알 수 있다. 많은 용량을 사용하기 때문에 4K나 2K로 필요에 따라 낮춰서 사용할 필요가 있다.

이번엔 Texture만 체크 - Ctrl+A를 통해 전체 선택 후 우클릭 - Asset Actions - Bulk Export 를 통해 윈도우 파일로 추출을 해서 포토샵과 같은 다른 소프트웨어를 활용해서 해상도를 낮춘 후 다시 들고 오는 방식으로 텍스쳐 용량을 최적화 할 수 있다.

Static Mesh 배치

준비한 Static Mesh 들을 한 눈에 보기 쉽게 환경에 가지런히 배치를 해놓고 사용한다.

그런데 이 선반을 보면 부품이 하나하나 분리가 되어있다. 모델식이라는 에셋 구성의 유형 때문인데 이런 경우에는 Shift + 왼클릭으로 전체 선택후 드래그앤 드랍 을 하면 조립된 형태로 배치할 수 있다.

또 이렇게 땅에 박혀 있는 오브젝트들을 볼 수 있는데

위로 끌어올린 후 End키 를 누르면 바닥으로 붙혀 준다.

또 오브젝트를 선택 후 Ctrl+B를 누르면 에셋이 위치한 폴더 경로로 바로 이동하게 된다. 필요할 경우 이런 식으로 에셋 경로로 바로가기를 해준 후 꺼내서 사용할 수 있다.

또는 레벨에 배치된 오브젝트를 선택 후 Alt를 누른 채로 드래그 하는 방법으로 복사를 해서 사용할 수도 있다.

바닥 머티리얼 할당

다시 Quixel Bridge에 들어와서 Home - Surfaces - Ground 에서 원하는 바닥 머티리얼을 골라준다. 똑같이 Download - Add 해주면 된다.

Add를 하면 Content - Megascans 폴더 밑에 Surfaces라는 폴더가 새로 생긴 것을 알 수 있다. 들어가서 머티리얼을 드래그해서 바닥에 드랍하면 적용이 되는데 보다시피 엄청 크게 적용이 된다.

머티리얼을 더블클릭해서 들어가면 이런 창이 뜬다. 여기서 Tilling/Offset 체크 - 화살표 - Tilling X, Tilling Y를 50으로 조정 해준다. 전에 바닥의 Scale을 100,100,1으로 조정해줬기 때문에 머티리얼도 비슷하게 조정해주면서 자연스러운 바닥을 만들면 된다.

레벨 인스턴스

레벨 인스턴스는 Static Mesh들을 하나의 블루프린트로 묶어내는 기능으로 환경을 만들 때 시간절약을 할 수 있다.

8개로 분리되어 있던 오브젝트를 모두 선택 - 우클릭 - Level - Create Packed Level Actor 를 누르고 Ok를 누른다. 그리고 개인폴더 밑에 LevelInstance 폴더를 생성하고 Name을 MetalPalletRacking_1 정한 후 Save를 누른다.

그러면 분리되어 있던 선반부품들이 Outliner창에 하나의 블루프린트가 된 것을 볼 수 있다.

이제는 하나하나 선택할 필요없이 하나만 드래그해서 에셋을 꺼낼 수 있다.

또 Edit - 원하는 부품 조정 - 최상단 오브젝트(초록색) 클릭 - Commit Changes 를 누르면 다른 오브젝트 들에도 일괄 적용 되는 것을 알 수 있다.

Ctrl+Alt를 누른 채로 그림처럼 드래그를 하면 바닥을 포함해서 전부 선택이 된다. Ctrl만 누른채로 바닥은 선택 해재 후 Alt를 누른채로 드래그해서 복사를 한다.

오브젝트들을 복사해서 선반위에 실제 박스를 쌓아 놓은 것 처럼 구성해준다. 그리고 드래그 해서 전체 선택 후 LevelInstance를 만들어준다. 그럼 다음과 같이 박스를 일일이 배치하지 않아도 묶음으로 배치할 수 있다.

Edit에 들어와서 드래그로 전체 선택 후 Outliner창에서 Pivot만 선택 해제한 후에 Ctrl+C로 복사를 해준다. 그리고 Esc를 눌러 나와 Ctrl+V를 해주면 레벨인스턴스가 아닌 각각의 오브젝트들을 만들 수 있다. 여기서 박스들의 종류와 위치를 바꿔서 다른 상자묶음을 만들어준다.

두 상자묶음은 다음에 또 복사해오기 쉽게 복사를 해둔다.

앞에 만들었던 선반과 박스파일들을 복사해와서 이런 큰 박스선반을 만든다. 레벨 인스턴스들끼리도 레벨인스턴스를 만들 수 있기 때문에 똑같이 드래그 - 바닥 제외 - 레벨인스턴스 생성 을 통해 박스선반도 블루프린트로 만들어 복사를 할 수 있다.

선반의 중심이 바닥 밑에 있는 것을 알 수 있다. Edit - Perspective 뷰를 Front로 - Pivot 선택 - 조정 을 통해 정확한 Pivot위치를 맞춰줄 수 있다.

마지막으로 ~를 누르고 HighResShot 3840x2160 이라고 치면 고해상도 스크린샷을 찍을 수 있다.

정리

개인폴더 아래에 Level, LevelInstance와 같은 폴더로 파일들을 정리한다.

Settings - Project Settings - Maps & Modes - Editor Startup Map 에서 엔진을 껏다 켰을 때 나오는 레벨을 정해줄 수 있다.

Settings - Project Settings - virtual texture - Enable virtual texture support 체크 를 통해 고품질의 데이터를 사용하면서 컴퓨터의 메모리와 성능을 아낄 수 있다.

Env. Light Mixer에서 간편하게 라이트 설정을 할 수 있다.

Scale값 1은 1M

수만개의 무료 에셋들이 있는 Quixel Bridge

텍스쳐가 은근 용량을 많이 차지한다. 필요에 따라 외부 소프트웨어로 해상도를 낮출 수 있다.

모델식 에셋은 한 번에 선택 후 배치

End키 를 통해 오브젝트를 땅에 붙힐 수 있음

머티리얼을 더블클릭 - Tilling/Offset 체크 - 화살표 - Tilling X, Tilling Y 조정 으로 바닥 머티리얼을 자연스럽게 조정 가능

분리되어 있던 오브젝트를 모두 선택 - 우클릭 - Level - Create Packed Level Actor 로 레벨인스턴스를 생성하여 하나의 블루프린트로 만들 수 있음

Ctrl+Alt+드래그 로 다중 선택

Edit 에서 Pivot조정, 레벨인스턴스에서 각각의 오브젝트 복사해오기 가능

~키 - HighResShot 3840x2160입력을 통해 고해상도 스크린샷을 찍을 수 있다

끝

생각보다 재밌어서 정리하면서 따라만드는데 시간이 금방금방 갔다. 예상 외로 하나하나 따라가면서 하니 크게 어려운 부분은 없었고, 유니티를 하다와서 그런지 익숙한 게 많았다. 따라 만드면서 가장 큰 문제는 PC의 사양이였다. 사정상 PC가 없어 피시방에 와서 했는데 Quixel Bridge에서 에셋을 다운 받고 저장하는데만 10번 가량 튕겨서 빡종할 뻔 했지만 참고 끝까지 따라했다. Ram 16GB는 많이 부족한 것을 느꼈다.

시작

우선 버전은 가장 최신 버전인 5.3.2 버전을 사용하기로 했다. 젤 최신이니까 젤 좋겠지

언리얼은 기본적으로 제공해주는 여러 템플릿이 있다. 게임말고도 영화, 건축, 자동차 같은 템플릿도 있는 거 보면 게임에만 국한되지 않는 엔진임을 알 수 있었다. 우선 1인칭 블루프린트로 생성을 했다.

딱 프로젝트를 처음 열었을 때 나오는 화면이다.

일단 유튜브나 인터넷 자료를 쉽게 참조하기 위해서 설정을 영어로 바꿔주겠다.

편집 - 에디터 개인설정 - 지역&언어 에서 에디터 언어를 영어로 바꾸어주었다.

Unity와 비교

크게 Unity와 다른 점은 못 느꼈고, 비슷한 기능을 하는 창들이 몇 개 있었다.

1. Outliner

UE에서의 Outliner는 Unity의 Hierarchy창과 같은 역할을 하는 창이였다. 기본적으로 FirstPersonMap이라는 상위 폴더 안에 여러 파일들이 있는 형태인데 처음 느낀점으로는 아이콘이 다양하다는 느낌을 받았다.

2. Details

UE에서의 Details는 Unity의 Inspector창과 같은 역할을 하는 창이였다. Unity에서는 오브젝트를 생성하면 Transform과 MeshRenderer정도 꼭 필요한 컴포넌트만 들어있는 느낌이였는데, UE에서는 냅다 다 받아둔 거 같은 느낌을 받았다. "이걸 다 쓰나?", "언제 다 외우지.." 같은 생각이 들었다.

3. Viewport

UE에서의 Viewport가 Unity의 Scene창과 같은 역할을 하는 창이였다. 어떤 오브젝트들이 있고, 어떤 장면을 담을 수 있는지 확인 할 수 있다. 기본적으로 유니티와 비슷하지만 큰 차이점들이 몇 개 보였다.

3.1 XYZ축

가장 큰 차이점이라고 느낀 것은 XYZ의 방향이 다르다는 것이다.

Unity에서는 y가 위아래 z가 앞뒤였는데 Unreal에서는 y가 앞뒤 z 가 위아래를 가리키는 축이였다. 헷갈리지 않아야 할듯

3.2 이동

유니티와 거의 비슷한 거 같다.

좌클릭+드래그 카메라를 앞뒤로 움직이고 좌우로 회전

우클릭+드래그 뷰포트 카메라를 회전

좌클릭+우클릭+드래그 위아래로 양옆으로 이동

우클릭을 누른채로 WASDQE 카메라를 앞뒤양옆위아래로 이동 휠버튼을 위로 굴려 이동속도를 높이고 아래로 굴려 낮출 수도 있음.

우클릭을 누른채로 CZ 줌인, 줌아웃 (우클릭을 때면 풀림)

오브젝트 선택 후 F 카메라를 해당 오브젝트로 이동

3.3 툴바

• 트랜스폼 툴 qwer로 바꿀 수 있고

• q는 아무것도 건드리지 않고 이동만 w는 좌표 이동 e는 회전 r은 스케일* 을 조정할 수 있다.

• 좌표계 오브젝트를 월드 기준으로 움직일지 로컬 기준으로 움직일지를 정하는 역할을 한다.

• 스냅 클릭을 통해 활성화/비활성화 할 수 있고, 각각이 활성화 되면 이동, 회전, 스케일 조절을 특정 값만큼 조절할 수 있다. 예를 들어 회전 스냅을 10으로 설정해두면 오브젝트를 돌릴 떄 10도씩만 돌아가게 된다.

• 카메라 속도 우클릭 휠 또는 이 칸에서 조정이 가능하다.

3.4 에디터 뷰포트

기본적으로는 Perspective 자유롭게 움직이고 볼 수 있는 뷰포트가 기본이고 추가로 위 아래 앞 뒤 양옆에서 볼 수 있는 뷰포트를 제공한다. 오른쪽 위의 창문 모양 버튼을 통해 한 번에 4개의 뷰포트를 볼 수도 있다.

3.5 Content Drawer

Content Drawer 는 프로젝트에 포함된 모든 에셋, 블루프린트 및 기타 파일을 표시하는 창이다. 콘텐츠 탐색, 레벨에 에셋을 드래그, 프로젝트 간에 에셋 이동 등의 동작을 할 수 있다.

끝

언리얼의 기본적인 기능들을 살펴봤다. 유니티와 비슷하다면 비슷하고 다르다면 다른 것들이 많았다. 하나하나씩 살펴보면서 천천히 적응해 나가야 할 것 같다.