cdc wiki - 사용자 기여 [ko]

2분반-냉고

2026-03-20T00:26:14Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

<div>__TOC__</div>
==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 : ''' 00000000..

''' 영문 : ''' 00000000..

===과제 팀명===
00000..

===지도교수===
000 교수님

===개발기간===
2019년 3월 ~ 2019년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 ㅁㅁ공학부·과 2011XXX0** 김**(팀장)

서울시립대학교 ㅁㅁ공학부·과 2011XXX0** 정**

서울시립대학교 ㅁㅁ공학부·과 2011XXX0** 조**

서울시립대학교 ㅁㅁ공학부·과 2011XXX0** 이**

서울시립대학교 ㅁㅁ공학부·과 2011XXX0** 남**

==서론==
===개발 과제의 개요===
====개발 과제 요약====
내용
====개발 과제의 배경====
내용
====개발 과제의 목표 및 내용====
내용

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
*전 세계적인 기술현황
내용
*특허조사 및 특허 전략 분석
내용
*기술 로드맵
내용

====시장상황에 대한 분석====
*경쟁제품 조사 비교
내용
*마케팅 전략 제시
내용

===개발과제의 기대효과===
====기술적 기대효과====
내용
====경제적, 사회적 기대 및 파급효과====
내용

===기술개발 일정 및 추진체계===
====개발 일정====
내용
====구성원 및 추진체계====
내용

==설계==
===설계사양===
====제품의 요구사항====
내용
====설계 사양====
내용

===개념설계안===
내용

===이론적 계산 및 시뮬레이션===
내용

===상세설계 내용===
내용

==결과 및 평가==
===완료 작품의 소개===
====프로토타입 사진 혹은 작동 장면====
내용
====포스터====
내용

===관련사업비 내역서===
내용

===완료작품의 평가===
내용

===향후계획===
내용

===특허 출원 내용===
내용

2분반-몇대몇

2026-03-20T00:26:02Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

2분반-이루매납치단

2026-03-20T00:25:52Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

2분반-F1T

2026-03-20T00:25:26Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-0x66

2026-03-20T00:25:13Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-MoodPick

2026-03-20T00:24:59Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-우리어때

2026-03-20T00:24:48Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-아자스

2026-03-20T00:22:36Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-ODISS

2026-03-20T00:22:25Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-둥지

2026-03-20T00:22:02Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

2026학년도 1학기

2026-03-20T00:19:38Z

Adcdc: /* 2026년 1학기 */

==Course Information==
* 과목명 : [2026.1학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2026년 1학기===
'''[[1분반-둥지]]''' - 박*현, 정*홍, 조*현, 최*영 
'''[[1분반-ODISS]]''' - 이*석, 정*기, 유*휘, 주*우 
'''[[1분반-아자스]]''' - 이*권, 유*호, 이*권, 조*형 
'''[[1분반-우리어때]]''' - 김*형, 문*영, 송*영, 박*영 
'''[[1분반-MoodPick]]''' - 박*욱, 강*현, 김*규, 서*훈 
'''[[1분반-0x66]]''' - 김*수, 김*현, 서*근, 황*진 
'''[[2분반-F1T]]''' - 허*준, 김*훈, 김*혁, 박*현 
'''[[2분반-이루매납치단]]''' - 이*원, 이*민, 이*형, 최*영 
'''[[2분반-몇대몇]]''' - 심*용, 유*호, 권*현, 문*현 
'''[[2분반-냉고]]''' - 김*린, 최*성, 백*정, 박*

1분반-0001

2026-03-11T07:46:48Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

2026학년도 1학기

2026-03-11T07:46:30Z

Adcdc: /* 2026년 1학기 */

==Course Information==
* 과목명 : [2026.1학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2026년 1학기===
'''[[1분반-0001]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-0002]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-0003]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-0004]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-0005]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-0006]]''' - 서*진, 김*서, 권*재 
'''[[1분반-0007]]''' - 조*채, 이*호, 이*제 
'''[[2분반-0000]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-0000]]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-0000]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-0000]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

1분반-0000

2026-03-11T07:45:06Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

2026학년도 2학기

2026-03-11T07:41:59Z

Adcdc: /* 2026년 1학기 */

==Course Information==
* 과목명 : [2026.2학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2026년 2학기===
'''[[1분반-00000]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-00000]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-00000]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-00000]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-00000]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-00000]]''' - 서*진, 김*서, 권*재 
'''[[1분반-00000]]''' - 조*채, 이*호, 이*제 
'''[[2분반-00000]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-00000]]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-00000]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-00000]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

2026학년도 2학기

2026-03-11T07:41:44Z

Adcdc: /* 2025년 1학기 */

==Course Information==
* 과목명 : [2026.2학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2026년 1학기===
'''[[1분반-00000]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-00000]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-00000]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-00000]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-00000]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-00000]]''' - 서*진, 김*서, 권*재 
'''[[1분반-00000]]''' - 조*채, 이*호, 이*제 
'''[[2분반-00000]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-00000]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-00000]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-00000]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

2026학년도 1학기

2026-03-11T07:40:25Z

Adcdc: /* 2026년 1학기 */

==Course Information==
* 과목명 : [2026.1학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2026년 1학기===
'''[[1분반-0000]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-0000]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-0000]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-0000]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-0000]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-0000]]''' - 서*진, 김*서, 권*재 
'''[[1분반-0000]]''' - 조*채, 이*호, 이*제 
'''[[2분반-0000]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-0000]]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-0000]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-0000]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

2026학년도 1학기

2026-03-11T07:39:28Z

Adcdc: /* 2026년 1학기 */

==Course Information==
* 과목명 : [2026.1학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2026년 1학기===
'''[[1분반-aPPLY]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-DOS]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-Locauto]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-Ludex]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-슈팅스타]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-올인뷰]]''' - 서*진, 김*서, 권*재 
'''[[1분반-자이로드롭]]''' - 조*채, 이*호, 이*제 
'''[[2분반-Brain Overflow]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-Flat2Form]]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-마음의소리]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-캐슬코더]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

2026학년도 1학기

2026-03-11T07:38:33Z

Adcdc: Adcdc (토론)의 12622판 편집을 되돌림

2026학년도 1학기

2026-03-11T07:38:06Z

Adcdc: /* 2026년 1학기 */

==Course Information==
* 과목명 : [2026.1학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2026년 1학기===
'''[[1분반-aPPLY]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-DOS]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-Locauto]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-Ludex]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-슈팅스타]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-올인뷰]]''' - 서*진, 김*서, 권*재 
'''[[1분반-자이로드롭]]''' - 조*채, 이*호, 이*제 
'''[[2분반-Brain Overflow]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-Flat2Form]]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-마음의소리]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-캐슬코더]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

2026학년도 1학기

2026-03-11T07:36:58Z

Adcdc:

1분반-자이로드롭

2026-03-11T07:36:06Z

Adcdc: Adcdc (토론)의 12615판 편집을 되돌림

<div>__TOC__</div>

[[파일:자이로드롭 그림21.jpg]]

==프로젝트 개요==
=== 기술개발 과제 ===
* '''국문: 협동심 증진 및 공감각 발달을 위한 게임 ‘자이로드롭’ 개발'''
* '''영문: Gyrodrop: A Game for Boosting Teamwork and Enhancing Multisensory Development'''

===과제 팀명===
자이로드롭

===지도교수===
황혜수 교수님

===개발기간===
2025년 3월 ~ 2025년 6월 (총 4개월)

===구성원 소개===
* 서울시립대학교 컴퓨터과학부 2020920058 조성채(팀장)
* 서울시립대학교 컴퓨터과학부 2020920051 이현제(팀원)
* 서울시립대학교 컴퓨터과학부 2019920037 이성호(팀원)

==서론==
===개발 과제의 개요===
====개발 과제 요약====
* 모바일 디바이스의 자이로센서 데이터를 이용해 게임 내 플랫폼을 기울여 캐릭터의 위치를 조작하는 3D-Platformer, 퍼즐 게임 개발
* 1인 모드(전체 축 조작)와 2인 모드(Pitch, Roll 축 분담) 지원으로 협동성 극대화
* 호스트 중심 물리 연산 + WebRTC P2P 네트워킹으로 플레이어 간 멀티 플레이 지원
* 크로스 플랫폼(Windows, macOS) + 모바일 웹 컨트롤러 지원으로 접근성 확대

====개발 과제의 배경 및 효과====
* 모바일 VR·센서 기반 인터랙션 시장 확대, 캐주얼 협동 게임의 수요 증가
* 기기 내장 자이로센서 활용으로 별도 디바이스 없이 본인의 스마트폰 사용 가능
* 실시간 P2P 멀티플레이 지원으로 원격지의 사용자와 협동 플레이 가능
* 교육·재활(노인 치매 예방, 협동 훈련) 등 파생 활용 가능

====개발 과제의 목표와 내용====
* 협동 플레이를 유도하는 게임 맵 디자인 - 하나의 축만을 이용하여 게임을 클리어하기 어렵도록 설계
* 원격지 멀티 플레이 실시간성 확보 – 게임 클라이언트 간 실시간 동기화 지연 시간을 30ms 내외로 유지
* 다양한 기믹 요소(열쇠, 발판, 점프대, 이동 플랫폼, 부숴지는 발판 등)를 구현하여 게임의 난이도와 긴장도를 높임
* 9개의 맵(3가지 난이도, 각 난이도별 3개의 맵) 개발
* 웹 컨트롤러 연동으로 별도의 컨트롤러 없이도 PC에서 플레이 가능하도록 설계 – 컨트롤러 지연 시간은 100ms 내외로 유지
====개발과제의 기술적 기대효과====
* 자이로 데이터 실시간 취합 및 클라이언트(피어) 간 실시간 동기화 기술 개발
* WebRTC 기반의 P2P 게임 상태 동기화 기술 구현
====개발과제의 경제적 및 사회적 파급효과====
* 친구 및 가족과 2인 협동으로 가볍게 즐길 수 있는 소셜 게임
* 협동심 증진 및 공감각 발달에 도움을 주어 노인 치매 예방 프로그램으로 활용 가능

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
# 자이로 센서
#* 자이로 센서는 각속도를 측정하여 회전 방향과 속도를 정확히 감지하는 역할을 한다. 최근의 자이로 센서 기술은 MEMS(미세전자기계 시스템) 기반으로 소형화 및 고정밀화가 이루어졌으며, 현실 세계와 가까운 가상 환경 경험을 제공할 수 있기에 스마트폰, VR 기기, 게임 컨트롤러 등 다양한 분야에서 필수적인 기술로 자리 잡았다.
#* 최근 자이로 센서는 가속도 센서와 결합하여 6축 센서를 구성하며, 여기에 자기장 센서를 추가해 9축 센서로 발전하였다. 이를 통해 더욱 정확한 공간 인식과 자세 추적이 가능해졌다.
#* 최신 자이로 센서는 초당 300~2000 DPS(degrees per second)의 정밀한 각속도 측정 범위를 제공하며, 모바일 게임 환경에서 미세한 움직임까지 정확히 감지할 수 있게 되었다.
# 게임 엔진
#* 게임 개발 및 실시간 시뮬레이션 구현을 위한 대표적인 기술로는 Unity Engine과 Unreal Engine이 있다.
## Unity Engine
##* Unity는 직관적인 인터페이스와 높은 접근성을 바탕으로, 다양한 플랫폼에서의 실시간 콘텐츠 개발을 지원하는 범용 게임 엔진이다.
##* 모바일, 데스크탑, 웹, 콘솔, XR(VR/AR) 등 크로스 플랫폼 개발에 최적화되어 있으며, 하나의 프로젝트로 다수의 플랫폼에 쉽게 빌드할 수 있는 기능을 제공한다.
##* 기술적으로는 NVIDIA의 PhysX 엔진을 기반으로 한 3D 물리 시뮬레이션과, Box2D 기반의 2D 물리 엔진을 내장하고 있어 물리 기반 상호작용 구현이 용이하다. 또한 DOTS(Data-Oriented Technology Stack) 및 ECS(Entity-Component-System) 구조를 통해 성능 중심의 대규모 데이터 처리 및 병렬 연산을 지원한다.
##* Unity는 시각적 툴(Shader Graph, Visual Effect Graph, Timeline 등)과 풍부한 Asset Store 생태계를 갖추고 있어 빠른 프로토타이핑과 개발 효율 향상에 유리하다.
##* 특히 C# 기반의 스크립팅, 높은 커스터마이징 자유도, 사용자 커뮤니티의 풍부한 기술 자료는 Unity의 장점 중 하나로 꼽힌다.
## Unreal Engine
##* Unreal Engine은 Epic Games에서 개발한 고성능 실시간 렌더링 엔진으로, AAA급 게임 및 고품질 비주얼 콘텐츠 제작에 특화되어 있다.
##* 특히 최신 버전인 Unreal Engine 5는 Nanite(가상화 지오메트리), Lumen(실시간 글로벌 일루미네이션)과 같은 첨단 렌더링 기술을 도입하여, 실사 수준의 그래픽 구현이 가능하다.
##* 고급 물리 효과를 위한 Chaos Physics, Cloth Simulation, Rigid/Soft Body Dynamics 등 다양한 내장 기능을 제공하며, C++ 기반의 강력한 성능 제어와 함께 Blueprint라 불리는 시각적 스크립팅 시스템도 함께 지원되어 비전공자도 게임 로직을 시각적으로 구성할 수 있다.
##* Unreal Engine은 높은 성능과 정교한 표현력을 제공하는 대신, 비교적 높은 시스템 요구사항과 학습 난이도를 수반한다. 그럼에도 불구하고 영화, 건축 시각화, 디지털 트윈 등 게임 이외의 산업 분야에서도 널리 사용되고 있다.

===관련 시장에 대한 분석===
====경쟁제품 조사 비교====
# Super Monkey Ball: 해당 게임은 키패드나 조이스틱 기반 조작으로 플랫폼 위의 캐릭터를 조종하는 싱글플레이 중심의 게임이다. 멀티플레이 요소는 제한적이며, 자이로 센서를 활용한 조작 방식은 지원하지 않아 실제 기기 움직임과의 연동 경험이 부족하다. 우리 게임은 자이로 기반의 직관적인 조작감과 플레이어 간 협업 설계를 통해 보다 몰입감 있는 플레이를 제공한다.
# Tiltagon: 빠른 템포의 생존형 싱글플레이 게임으로, 키보드나 마우스를 이용한 입력에 의존하며 멀티플레이나 협동 요소는 존재하지 않는다. 이에 반해 우리 게임은 다양한 기믹과 시간 차 협동이 요구되는 퍼즐 요소, 실시간 네트워크 동기화를 통한 협동 경험에 초점을 맞춘 구조를 제공한다.
# Rolling Sky: 터치 드래그 방식의 싱글플레이 게임으로, 자이로 센서를 지원하지 않으며 협동 요소가 없다. 우리 게임은 단순한 반사신경 게임과 달리 두 명이 동시에 조작하지 않으면 클리어할 수 없는 구조로 협동심을 유도하며, 플레이어 간의 조작 축 분리 및 공동 책임 구조를 강조한다.

====마케팅 전략====
* 대학 커뮤니티(에브리타임·인스타 릴스) 타겟팅 티저 영상 배포
* 자체 렌딩 페이지(gyrodrop.xyz)에 배포
* 게임 스토어(Stove, Steam) 출시

==설계==
===사용자 요구사항===
{| class="wikitable"
! 번호 !! 요구사항 !! D or W !! 중요도
|-
! colspan="4" | '''게임 플레이'''
|-
| 1 || 플레이어가 멀티플레이 룸을 생성 또는 입장할 수 있고, 게임 스테이지를 선택하여 상대방과 게임을 플레이할 수 있다. || D || 대
|-
| 2 || 2명의 플레이어가 자이로 센서를 통해 각각 Pitch/Roll 축을 담당하여 판의 기울기를 조작할 수 있다. || D || 대
|-
| 3 || 게임 내 한 스테이지에서 공이 목표 지점까지 도달하는 최단 거리로 움직이는 시간이 1분 내로 소요되어야 한다. || D || 중
|-
| 4 || 협동 플레이를 유도하도록 맵이 디자인되어야 한다. • 두 축을 동시에 협력하여 기울여야만 통과 가능한 경로 • 시간차를 맞춰 움직여야 클리어 가능한 점프 구조 등 다양하게 설계된 기믹을 바탕으로 다채로운 맵 디자인을 제공 || D || 대
|-
| 5 || 크로스 플랫폼을 지원하고 기기에 자이로 센서가 없는 경우 이를 지원하는 기기로 컨트롤이 가능해야 한다. || D || 중
|-
| 6 || 레벨 디자이너가 게임 내 스테이지를 생성하기 위한 툴이 제공되어야 한다. || W || 소
|-
! colspan="4" | '''기술적 요소'''
|-
| 1 || 자이로 센서의 입력에 대한 반응속도를 100ms 이하로 유지한다. || D || 중
|-
| 2 || 게임 서버–클라이언트 간 실시간 동기화 시간을 30ms 이하로 유지한다. || D || 대
|-
| 3 || 렌더링 속도를 60FPS 기준으로 유지하여 매끄러운 플레이를 제공한다. || D || 중
|-
| 4 || CI/CD를 제공하여 빠른 개발과 배포가 가능하도록 한다. || W || 중
|-
| 5 || 게임 서버의 수평적 확장이 가능하도록 오케스트레이션이 가능해야 한다. || W || 소
|}

===사용자 요구사항 만족을 위한 기능 정의 및 기능별 정량목표===
====기능 정의====
{| class="wikitable"
! 분류 !! 기능 명칭 !! 설명
|-
| GR1 || 게임 룸 생성 || 플레이어가 멀티플레이 룸을 생성할 수 있다.
|-
| GR2 || 게임 룸 입장 || 플레이어가 상대방의 접속 정보를 이용하여 멀티플레이 룸에 입장할 수 있다.
|-
| GR3 || 스테이지 플레이 || 멀티플레이 룸에서 스테이지를 선택하여 게임을 플레이할 수 있다.
|-
| GY1 || 자이로 데이터 취득 || 게임 클라이언트가 구동되는 기기로부터 자이로 센서 데이터를 취득할 수 있다.
|-
| GY2 || 자이로 데이터 대체 취득 || 게임 클라이언트가 구동되는 기기에서 자이로 센서를 가져올 수 없는 경우(예: PC) 이를 지원하는 모바일 기기를 이용하여 컨트롤러 부분만 대체할 수 있다.
|-
| GY3 || 자이로 반응 속도 || 자이로 컨트롤러의 반응이 게임 상에 100ms 이내로 적용된다.
|-
| GY4 || 자이로 데이터 취합 || 두 플레이어의 자이로 데이터를 취합하여 게임 서버에 반영할 수 있다.
|-
| GS1 || 기믹 상호작용 || 점프대, 발판, 열쇠, 부서지는 바닥 등의 기믹 구현 및 상태 변화 처리를 수행한다.
|-
| GS2 || 스테이지 레벨 디자인 || 협동 플레이를 유도하는 맵을 제작한다. 하나의 축만을 이용하여 게임을 플레이할 수 없어야 하며, 두 개의 축을 이용해서 서로 협동하여 스테이지를 클리어 하도록 설계되어야 한다.
|-
| GS3 || 네트워크 동기화 || 게임 서버–클라이언트 간 실시간 동기화 시간이 30ms 이하로 유지되도록 한다.
|-
| GS4 || 렌더링 || 최신 스마트폰을 기준으로 60FPS 렌더링 성능을 보장한다.
|-
| GD1 || 레벨 에디터 도구 || 스테이지 제작 도구를 제공하여 쉽고 빠른 맵 제작이 가능하도록 한다.
|-
| GD2 || 배포 및 서버 관리 || 오케스트레이션 도구(kubernetes, docker 등)를 이용하여 CI/CD 및 수평 확장을 고려한 설계를 한다.
|}

====기능별 정량목표====
{| class="wikitable"
! 분류 !! 기능 명칭 !! 목표 기준치 !! 평가 방식 !! 중요도 계수
|-
| GR1 || 게임 룸 생성 || 구현됨 || 개발 여부 (개발: 1, 미개발: 0) || 0.07
|-
| GR2 || 게임 룸 입장 || 구현됨 || 개발 여부 || 0.07
|-
| GR3 || 스테이지 플레이 || 구현됨 || 개발 여부 || 0.07
|-
| GY1 || 자이로 데이터 취득 || 구현됨 || 개발 여부 || 0.07
|-
| GY2 || 자이로 대체 컨트롤 || 구현됨 || 개발 여부 || 0.07
|-
| GY3 || 자이로 반응 속도 || ≤ 100ms || max(0, 1 - (반응속도 / 100)) || 0.12
|-
| GY4 || 자이로 데이터 취합 || 구현됨 || 개발 여부 || 0.07
|-
| GS1 || 기믹 상호작용 || 구현됨 (3종 이상) || max(1, 구현된 기믹 수 / 6) || 0.08
|-
| GS2 || 협동형 레벨 디자인 || 협동 기믹 포함 맵 비율 ≥ 80% || 실제비율 / 100 || 0.10
|-
| GS3 || 네트워크 동기화 || ≤ 30ms || max(0, 1 - (RTT / 30)) *RTT는 교내 무선랜 환경에서 측정 || 0.10
|-
| GS4 || 렌더링 || ≥ 60FPS || min(1, FPS / 60) *FPS는 평균값 사용 || 0.10
|-
| GD1 || 레벨 에디터 도구 || 구현됨 || 개발 여부 || 0.02
|-
| GD2 || 배포 및 서버 관리 || 구현됨 || 개발 여부 || 0.06
|}

완료 작품의 평가에서 위의 표의 평가 방식으로 점수를 매기고, ((기능 점수 * 기능 중요도 계수)의 합 * 100)을 계산하여 100점 만점을 기준으로 평가한다.

===기능 구현을 위한 세부기술 선택사항===
# '''게임 룸 생성(GR1), 게임 룸 입장(GR2), 자이로 데이터 취합(GY4)''' 기능 개발을 위해 Node.js 기반의 NestJS 웹 서버 프레임워크를 선정하였다.
#* Node.js의 풍부한 패키지 생태계와 빠른 프로토타이핑 및 개발 속도를 고려하여 선택하였다.
#* 플레이어가 상대방의 연결 정보를 직접적으로 알 수 없으므로 중립적이고 안정적인 연결을 보장하기 위해 서버-클라이언트 아키텍처를 도입하고, 이를 통해 게임 룸 및 접속 코드를 생성하고 관리하도록 하였다.
# '''스테이지 플레이(GR3)''' 기능 구현을 위해 게임 엔진으로 Unity를 채택하였다.
#* Unity는 직관적인 시각적 개발 툴과 방대한 플러그인 생태계를 제공하여 초기 개발 속도를 크게 향상시킬 수 있으며, 캐주얼 게임 및 실시간 인터랙티브 콘텐츠 제작에 적합하다.
#* Unity는 또한 UI 시스템, 물리 기반 시뮬레이션, 경로 탐색, 상태 머신 등 주요 게임 개발 기능을 위한 풍부한 라이브러리와 예제를 제공하여 개발의 재사용성과 유지보수성 측면에서 큰 이점을 제공한다.
# '''자이로 데이터 취득(GY1), 자이로 대체 컨트롤(GY2)''' 구현을 위해 모바일 기기 디바이스의 자이로 정보를 취득하기로 했으며, 별도의 애플리케이션 설치가 필요하지 않도록 웹 기반 애플리케이션을 제공하기로 했다.
#* 자이로 센서 데이터를 획득하기 위해 deviceorientation 웹 API를 이용한다.
#* React 라이브러리를 사용하여 개발 효율성을 높였고, React의 방대하고 다양한 라이브러리 생태계를 활용하여 인터랙티브한 UI/UX 설계를 실현할 수 있다.
# '''자이로 반응 속도(GY3)''' 요구사항 충족을 위해 실시간 양방향 통신이 가능한 WebSocket을 도입하였다.
#* HTTP 통신 대비 헤더 등의 오버헤드를 줄이고 실시간 이벤트 전송 방식을 채택하여 통신 지연을 최소화하였다.
# '''기믹 상호작용(GS1), 협동형 레벨 디자인(GS2)'''은 Unity의 MonoBehaviour를 상속받는 방식으로 구현하였으며, Unity 에셋 스토어에서 유/무료 모델을 활용하여 디자이너가 없는 팀 상황에서도 높은 품질의 게임 디자인을 가능하게 하였다.
# '''네트워크 동기화(GS3)'''를 위해 처음에는 Mirror, FishNet과 같은 서버-클라이언트 구조의 동기화 프레임워크를 고려하였으나, 매 게임마다 Unity Headless 서버 인스턴스를 매번 띄우는 오버헤드와 P2P 위한 Transport 계층의 미구현 및 빈약한 문서화로 인해 최종적으로 WebRTC 기반의 P2P 기술을 채택하였다.
#* WebRTC는 서버 연결 없이 Peer 간 직접적인 통신이 가능하고, NAT 및 방화벽을 우회할 수 있으며, 실시간으로 데이터를 전송할 수 있다는 점이 우리의 요구사항에 딱 맞아 떨어진다.
#* 클라이언트는 Unity.WebRTC 패키지로 구현하고, 시그널링 서버는 Node.js 및 Socket.io를 사용하였다.
#* RPC 기술은 C#의 리플렉션 기술을 이용하여 동일하게 배포된 애플리케이션 내에서 원격지의 메서드를 호출하는 방식으로 구현하였다.
# '''렌더링(GS4)''' 성능 최적화를 위해 Unity의 생명 주기(Update, FixedUpdate)를 명확히 구분하여 사용하였으며, Raycast, 복잡한 물리 연산, 충돌 판정 등 고비용 연산을 FixedUpdate에서만 실행하여 성능을 관리하였다.
# '''레벨 에디터 도구(GD1)'''는 시간과 인력의 제한으로 별도의 도구 개발 없이 Unity 프레임워크 내에서 레벨 디자인을 진행하였다.
# '''배포 및 서버 관리(GD2)'''는 AWS를 활용하여 서비스 안정성을 확보하고, CloudFront를 통해 모바일 웹 컨트롤러의 빠른 접근성을 보장하였다. EC2 인스턴스 앞에 Elastic Load Balancing(ELB)을 배치하여 여러 인스턴스를 스케일링 가능하게 구성하였다.

===게임 클라이언트 설계===
====매니저 클래스 설계====
[[파일:자이로드롭 그림1.png]]

게임 내 스크립트에서 우리 게임의 핵심 서비스 로직에 쉽게 접근할 수 있도록 싱글톤 패턴을 사용하여 전역 접근을 용이하도록 하였다. 또한 매니저 위의 매니저 클래스인 Managers 클래스를 두어 하위 매니저 클래스들의 의존성 주입을 담당하도록 하였고, 각 하위 매니저 클래스들은 책임과 역할을 명확히하여 기능 확장 및 디버깅이 용이하도록 하였다. 아래는 각 클래스들의 역할에 대한 설명이다.

# Managers 클래스
#* Singleton 패턴으로 구현된 최상위 매니저 클래스이다.
#* 각 서브 매니저(GameManager, RoomManager, SessionManager, UIManager, SoundManager 등)를 소유하며, 전역 접근을 제공한다.
#* Dispatch(Action) 메서드를 제공하여 Unity 메인 스레드에서 실행되어야 할 작업을 안전하게 큐잉 및 실행
# GameManager 클래스
#* 게임 진행 상태 전반을 관리한다.
#* 주요 기능
#** 스테이지 클리어 로직 수행(FinishAction)
#** 스테이지 로딩(LoadStageScene, LoadMainScene)
#** 스테이지 잠금/해금 관리(GetLastUnlockedStage, UnlockLastStage)
#** 초기화 및 리셋(Init, Clear)
# RoomManager 클래스
#* REST API를 통한 룸 생성, 참가, 자이로 제어 기능을 담당한다.
#* 클라이언트가 속한 룸 정보(Current), 현재 자이로 상태(CurrentGyro), 접속 코드(AccessCode) 등을 관리한다.
#* 주요 기능
#** 룸 생성 및 참가 (OpenAsync, JoinAsync, LoadAsync)
#** 자이로 축 점유/해제 (TaskAxisAsync, ReleaseAxisAsync)
#** 웹 컨트롤러 URL 제공 (GetWebControllerUrl)
#** 전체 초기화 (ResetAsync)
# SessionManager 클래스
#* 상대방과 원격 플레이를 위한 세션 연결 관리를 담당한다.
#* 연결 흐름의 상태(SessionStatus)를 추적하며, 호스트/게스트 역할에 따라 연결 절차를 처리한다.
#* 구체적인 연결 방식은 외부에 노출하지 않기 위해 해당 클래스를 정의하였으며,, 해당 클래스 안에서 WebRTC를 쓸 지 다른 P2P 통신 기법을 사용할지 결정한다.
#* 주요 기능
#** 호스트로서 게스트를 기다림 (StartWaitForGuest)
#** 게스트로서 호스트에 접속 (StartJoinHostRoom)
#** 세션 리셋 (ResetAsync)
#** 연결 종료 처리 (Dispose)
# SoundManager 클래스
#* 게임 내 효과음 및 배경음악 재생을 담당한다.
#* 주요 기능
#** BGM/SFX 재생 (Play)
#** 초기화 및 정리 (Init, Clear)
# UIManager 클래스
#* UI 패널 관리를 담당한다(씬 UI, 팝업 UI)
#* 주요 기능
#** UI 생성 및 표시 (ShowSceneUI<T>, ShowPopupUI<T>)
#** 팝업 닫기 (ClosePopupUI, CloseAllPopupUI)

====플레이어 이동 설계====
기존의 Rigidbody 기반으로 중력으로만 움직이는 설계는 얇거나 기울어진 표면에서 다음과 같은 문제를 유발했다.
* 갑작스럽게 기울어진 바닥에 대하여 공이 바닥 콜라이더를 관통하여 낙하하거나
* 경사진 표면에서 예기치 않게 튕겨 불안정하게 움직이는 현상
이를 해결하기 위해, 기존 물리 기반 이동 방식 대신 표면 정착 및 사영 기반 이동 방식으로 새롭게 움직임을 설계하였다. 구현된 클래스는 플랫폼 회전과 공의 움직임을 자연스럽게 연동하여, 직관적이고 안정적인 조작감을 제공한다.

# 플랫폼(평면) 감지
#* Unity의 Raycast 기능을 이용하여 플레이어의 위치에서 중력 방향으로 보이지 않는 광선을 쏘아 충돌된 객체를 바닥으로 인식한다.
#* 짧은 순간의 오인식이나 접지 흔들림(jitter)을 방지하기 위해 내부적으로 이전 상태를 기억하고, 접지 손실 여부를 일정 거리 이상 벗어난 경우에만 판단하도록 처리하였다.
# 중력 분해 및 표면 사영 적용
#* 인식된 평면의 법선 벡터를 기준으로 중력 벡터를 분해하여, 법선 방향 성분을 제거하고 평면에 평행한 방향의 힘만 공에 가한다.
#* 플랫폼이 회전하면 법선 방향도 함께 변하므로, 플레이어는 해당 표면을 따라 자연스럽게 미끄러지는 형태로 이동하게 된다.
#* 이를 통해 표면 기울기에 따라 실제 물리적으로 이동하는 느낌을 재현하였다.
# 정확한 위치 조정(접지 보정)
#* 공의 중심 좌표를 바닥의 표면에 정사영(수직 사영)하여, 물리 충돌에 의한 튕김이나 겹침을 방지한다.
#* 공은 표면에 붙어 있는 듯한 상태로 유지되며, 얇은 구조물이나 미세한 기울기에서도 안정적으로 동작한다.
#* 사영 위치는 바닥 기준점에서의 상대 거리와 법선 벡터를 이용하여 계산된다.
# 플레이 경험 향상
#* 공의 현재 속도가 최대 속도를 초과할 경우, 반대 방향의 감속력을 추가로 가하여 과도한 가속을 억제한다.
#* 게임 공간의 유효 범위를 벗어나면 자동으로 리셋되어 초기 위치로 돌아오며, 상태도 함께 초기화된다.
#* 이는 사용자의 실수로 인한 낙사 또는 무한 낙하로부터 빠르게 복구할 수 있도록 하기 위함이다.

====기믹 요소 설계====
[[파일:자이로드롭 그림2.png]]

기믹 요소는 게임 내에서 플레이어의 진행을 도와주거나 방해하는 동적인 오브젝트들로 구성되어 있다. 모든 기믹 클래스는 MonoBehaviour(또는 SyncBehaviour)를 상속받으며, 일부는 IClearableGimmic 인터페이스를 구현하여 스테이지 리셋 시 상태 복원이 가능하도록 설계되어 있다. 다음은 각 기믹 클래스들의 역할과 기능이다.

# BrokenBoard 클래스
#* 플레이어가 바닥에 닿으면 일정 시간 후 바닥이 사라지는 붕괴형 발판 기믹이다.
#* 붉은색으로 색상을 바꾼 후 ColliderPlatform을 비활성화하고 자기 자신도 비활성화된다.
# CubeZMover 클래스
#* 일정 속도로 X축 또는 Z축을 따라 왕복 운동하는 움직이는 발판이다.
#* Mathf.PingPong을 활용하여 자연스러운 반복 이동을 구현하며, 호스트 측에서 위치 동기화를 수행한다.
# HammerSwing 클래스
#* Z축을 중심으로 좌우로 회전하며, 회전 방향이나 각도는 설정값을 통해 조정할 수 있다.
#* FixedUpdate()에서 회전 동작을 수행하며, 호스트에서만 회전 값을 네트워크로 동기화한다.
# JumpPad 클래스
#* 플레이어가 트리거에 진입하면 사전에 설정된 방향으로 힘을 가해 점프시키는 발판이다.
#* Rigidbody.AddForce()를 사용하여 물리적 힘을 적용한다.
# KeyTrigger 클래스
#* 플레이어가 트리거에 진입하면 해당 컴포넌트에 연결된 문을 열고, 자신은 비활성화된다.
# MovingScrew 클래스
#* 톱니 모양의 장애물로, 주기적으로 X축으로 좌우 움직인다.
# PickUp 클래스
#* 플레이어가 획득 시 점수 추가, 데스 처리 등의 효과를 발생시키는 수집형 오브젝트이다.
#* PickupType 열거형을 통해 타입을 구분하며, Score 및 Death 타입이 구현되어 있다.
# RepeatingCrusher 클래스
#* 일정 주기로 전방으로 돌진한 후 다시 원위치로 복귀하는 반복형 해머 기믹이다.
#* 돌진 도중 플레이어를 감지하면 플레이어의 BreakDown()을 호출하여 파괴 액션을 취한다.
# TeleportPad 클래스
#* 연결된 게임 오브젝트의 위치로 플레이어를 순간이동시키는 패드형 기믹이다.
#* 대상 플레이어의 인터페이스(IBallControl)를 통해 위치를 직접 조작한다.
# TriggerPlate 클래스
#* 플레이어가 충돌하면 발판이 내려가고 연결된 문이 열리며, 시간이 지난 후 자동으로 복원된다.

====UI 설계====
[[파일:자이로드롭 그림3.png]]

게임 내 상태 변화를 UI에 반영하기 위해 옵저버 패턴을 적극 활용하였으며, 이를 위해 ReactiveProperty<T>와 IReadOnlyReactiveProperty<T>라는 구조를 설계에 도입하였다. 모델 내부의 상태 변경을 View(UI)에 자동으로 반영함으로써, 모델-뷰 간 결합을 줄이고, 유지보수성과 확장성을 향상시켰다.

# 설계 개요
#* ReactiveProperty<T>는 값이 변경되었을 때 구독 중인 콜백 함수들에게 자동으로 알림을 전달하는 구조로, 옵저버 패턴을 기반으로 구현되었다.
#* 외부에서는 IReadOnlyReactiveProperty<T>를 통해 읽기 및 구독만 허용하며, 직접 값 변경은 불가능하도록 캡슐화하였다.
#* Unity 환경의 특성상, 이벤트 콜백은 항상 메인 스레드에서 실행되어야 하므로, 내부적으로 Managers.Dispatch()를 사용해 UI 이벤트를 안전하게 실행하도록 하였다.
# 적용 방식 및 흐름
#* [[파일:자이로드롭 그림4.png]]
#* 모델(Model)에서의 상태 정의
#** 모델 클래스(예: GameManager, SessionManager)에서는 관리하고자 하는 상태 프로퍼티들을 ReactiveProperty<T>로 래핑하여 정의하였다.
#** 외부에는 IReadOnlyReactiveProperty<T> 형태로 노출하여, 구독만 가능하도록 구성하였다.
#* 뷰(View)에서의 상태 구독
#** UI 요소에서는 상태의 변경을 구독(Subscribe)하고, 변경 시 등록한 콜백 함수가 호출되어 화면을 새로 렌더링한다.
#** 이 방식으로 모델 내부에 UI 로직이 들어가지 않도록 분리함으로써 관심사의 분리가 가능해졌다.
#* 컨트롤러(Controller)에서의 상태 조작
#** 사용자의 입력이나 이벤트에 따라 컨트롤러가 모델의 상태를 변경하며, 이 변경은 자동으로 UI 반영으로 이어진다.
# 설계 효과
#* 모델과 뷰 간의 의존성을 제거하여 유지보수가 쉬워졌다.
#* 상태 변경이 있을 때만 UI가 렌더링되어, 렌더링 효율이 향상되었다.
#* UI 반영 누락과 같은 오류 가능성을 줄여 내부 상태와 UI 간의 일관성 유지가 가능해졌다.
#* 값의 변경과 UI의 갱신이 명확하게 연결되어 있어 디버깅 시 흐름 추적이 쉬워졌다.

====P2P 통신 및 RPC 설계====
P2P 통신을 위해 WebRTC를 어떻게 구현하였고, 확립된 통신 채널을 이용해 두 Peer 간 동기화를 RPC로 어떻게 구현하였는지 아래에 설명한다.

# WebRTC 시그널링
#* [[파일:자이로드롭 그림5.png]]
#* WebRTC는 NAT(라우터)를 넘어 Peer 간 직접 연결(P2P)을 설정하기 위해 초기 협상 과정인 시그널링(Signaling) 단계를 거친다. 이 과정에서 양쪽 Peer는 Session Description(Offer/Answer)과 ICE Candidate(네트워크 후보군)을 교환하며, 연결을 설정하기 위한 정보를 주고 받는다.
#* 서로의 연결 정보를 모르는 상태에서 시그널링을 할 순 없으므로, WebSocket 기반 임시 통신 채널을 열어 WebRTC 시그널링 정보를 터널링하는 서버를 구현했다. 이 서버는 추후 설명할 게임 룸 서버와 통합되어 있어, 게임 룸에 입장한 두 플레이어 간의 정보를 알 수 있으며, 시그널링에 필요한 정보 또한 터널링하여 전송할 수 있다.
#* 시그널링 과정은 다음 단계로 구성된다.
#** 호스트가 시그널링 서버(룸 서버)에 등록한다.
#** 게스트는 호스트의 룸 코드를 입력하여 시그널링 서버(룸 서버)에 참가한다.
#** STUN 서버를 통해 호스트 자신의 연결 정보를 수집한다(IP, UDP Port 등).
#** 수집된 호스트의 연결 정보를 시그널링 터널링 서버를 통해 게스트로 전송한다.
#** 게스트도 마찬가지로 STUN 서버를 통해 게스트 자신의 연결 정보를 수집한다.
#** 수집된 게스트의 연결 정보를 시그널링 터널링 서버를 통해 호스트로 전송한다.
#** 게스트는 연결 정보를 기반으로 데이터 채널을 생성하여 연결 제안(Offer)를 호스트에게 전송한다.
#** 호스트는 게스트의 연결 제안(Offer)를 받고 게스트에 답장(Answer)함으로써 통신 채널이 수립된다(이 단계에서는 더 이상 시그널링 터널링 채널이 필요하지 않는다).
# RPC를 통한 게임 상태 동기화
#* [[파일:자이로드롭 그림6.png]]
#* WebRTC로 수립된 데이터 채널을 이용하여 두 Peer 간 정보 교환이 실시간으로 이루어질 수 있게 됐다. 두 Peer는 서로 같은 코드를 공유하고 있다는 가정 하에 RPC(Remote Procedure Call)을 구현하여, 호스트가 필요 시 게스트에게 특정 액션을 취하도록 할 수 있도록 설계했다.
#* 호스트에서 모든 물리 연산을 수행하고 난 위치(Position) 및 회전(Rotation) 결과를 게스트에게 실시간으로 전송하여 호스트와 게스트 간 게임 오브젝트의 동기화를 이루고, 게임의 상태(점수 및 클리어 여부) 변경 또한 호스트에서 이루어질 시 동일하게 게스트에도 적용되도록 설계했다.
#* 구체적인 동기화 과정은 아래와 같다.
#** SyncObjectId가 붙은 게임 오브젝트에 SyncBehaviour를 상속받은 컴포넌트가 SyncRPC 애트리뷰트가 붙은 사용자 정의 RPC 메서드를 호출한다.
#** SyncManager는 SyncBehaviour 컴포넌트가 호출한 RPC 메서드를 내부(호스트)에서도 호출하고 이를 직렬화하여 WebRTC로 수립한 데이터 채널을 통해 상대편(게스트)으로 전송한다.
#** 이때, NAT Traversal이 되는 상황에서는 UDP 전송을 수행하고, 그렇지 않은 특수한 상황에서는 어쩔 수 없이 외부 TURN 서버로 릴레이하여 fallback 처리한다.
#** 상대편(게스트)는 RPC 메시지를 수신하여 역직렬화하여 어떤 게임 오브젝트의 어떤 컴포넌트의 어떤 메서드를 호출해야 하는지 알아내어 이를 호출한다.
# 동기화 클래스 설계
#* [[파일:자이로드롭 그림7.png]]
#* SyncManager: 게임 전체에서 RPC 호출 흐름과 동기화 메시지 송수신을 총괄한다.
#** 데이터 채널: IDataChannelSync<byte[]> 인터페이스를 통해 외부 통신 채널에 의존하며, SessionManager에 의해 원격지와의 통신이 수립되는 시점에 주입되어 생명주기를 공유한다.
#** 메서드 호출: InvokeSyncRPC, FixedSyncRPC 메서드를 통해 실시간 또는 일정 주기마다 RPC 호출을 큐잉하여 원격지에 전송한다.
#** 메시지 처리: SyncRPCMessage 객체를 생성, 직렬화 및 역직렬화하여 RPC 메서드를 호출한다.
#** 오브젝트 매핑: 내부적으로 SyncObjectId와 컴포넌트 이름을 기반으로 SyncBehaviour를 찾아 호출한다.
#** 게스트 준비 상태 추적: 상대 피어의 준비 여부를 확인하고, 필요 시 전송을 지연한다.
#* SyncBehaviour: 게임 오브젝트에 부착되는 동기화 대상 컴포넌트이며, 실제로 원격 호출될 메서드를 보유한다.
#** 메서드 자동 등록: SyncRPCAttribute로 정의된 메서드를 런타임에 반영(reflection)하여 등록한다.
#** 위치/회전 동기화: SyncPosition, SyncRotation 등의 메서드를 통해 Transform을 주기적으로 전송한다.
#** 호출 래퍼 제공: InvokeSyncRPC, QueueSyncRPC를 통해 SyncManager를 직접 호출하지 않고 메서드 이름만으로 원격 호출을 가능하게 한다.
#** 식별자 기반 연동: SyncObjectId를 통해 고유 식별자를 부여받으며, 두 피어 간 동기화 식별자로 사용된다.
#* SyncObjectId: 모든 SyncBehaviour가 부착되는 게임 오브젝트에는 이 컴포넌트가 존재해야 하며, 동기화 대상 객체를 UUID 기반으로 고유 식별한다.
#* SyncRPCAttribute: RPC 메서드를 정의할 때 사용되는 커스텀 어트리뷰트(Attribute)이다. 리플렉션을 통해 해당 속성이 부여된 메서드만 실행 가능하도록 한다.
#** 반환값은 반드시 void여야 하며, 특정 타입만 파라미터로 허용한다.
#** FindMethods(object)를 통해 클래스 단위의 RPC 메서드 매핑을 수행한다.
#* SyncRPCMessage: RPC 호출 정보를 담는 구조체로, 네트워크를 통해 전송되는 단위 메시지이다.
#** ObjectId, ComponentName, MethodName, Parameters를 포함하며, 버퍼 기반 직렬화 및 역직렬화 기능을 내장한다.
#** WriteTo, ReadFrom 메서드를 통해 고정된 크기의 Span<byte>를 사용하여 GC Pressure를 줄이고 성능을 최적화한다.
#* IDataChannelSync<T>: WebRTC 등의 데이터 채널을 추상화한 인터페이스로, SyncManager와 외부 간의 통신 계층을 분리한다.
#** 송신(SendData)뿐 아니라 수신(SubscribeData), 끊김 감지(SubscribeDisconnected), 종료 처리(SubscribeClosed) 콜백을 모두 제공한다.
#** 이 인터페이스는 외부에서 구현되어 SyncManager.Initialize()를 통해 주입된다.

===게임 룸 서버 설계===
# 개요
#* 서로 모르는 두 플레이어가 같은 방(room)에 접속하기 위해 중앙에서 관리되는 서버가 필요하다.
#* Node.js 기반 NestJS 서버를 통해 Room Manager를 구현하여 각 방의 상태와 두 플레이어의 연결 정보를 한 곳에서 관리한다.
#* 각 컨트롤러(웹 또는 게임 클라이언트)는 이 서버를 통해 룸을 생성·입장하고, 지속적으로 자이로 값을 전송한다.
#* 서버는 실시간 WebSocket(또는 REST) API를 통해 자이로 데이터를 모아 Single Source of Truth를 유지하며, 필요 시 WebRTC 시그널링도 제공한다.
# 아키텍처 설계
#* 주요 모델
#** [[파일:자이로드롭 그림8.png]]
## Repository Layer
##* [[파일:자이로드롭 그림9.png]]
##* GameRoomInMemoryRepository: Map<string, GameRoom>을 사용해 룸 정보를 메모리에 저장합니다. create, getById, update, delete 등 기본 CRUD 메서드를 구현한다.
##* ShortCodeBase62InMemoryRepository: 일정 길이의 Base62 문자열을 생성해 룸 ID와 매핑하며 TTL이 지나면 자동으로 정리합니다.
##* ClientVersionJsonRepository: JSON 파일을 읽어 최신·최소 클라이언트 버전을 관리한다.
## Service Layer
##* [[파일:자이로드롭 그림10.png]]
##* GameRoomService: 게임 룸 생성/입장/퇴장, 자이로 점유 관리, 단축 코드 발급 등을 담당합니다. 내부적으로 Repository 인터페이스에 의존한다.
##* WebRTCSignalingService: 피어 간 시그널링 연결을 관리하고 TURN 계정 정보를 동적으로 생성합니다. 연결된 피어의 메시지 전달을 중계한다.
##* ClientVersionService: 클라이언트 버전을 검사하여 호환 여부와 최신 버전을 알려준다.
## Controller Layer
##* [[파일:자이로드롭 그림11.png]]
##* GameRoomController: /rooms 경로에서 룸 생성, 조회, 입장/퇴장, 자이로 관련 REST API를 제공한다.
##* GameRoomGateway: update-gyro 웹소켓 이벤트를 받아 GameRoomService의 자이로 값 갱신 메서드를 호출한다.
##* WebRTCSignalingGateway: /webrtc-signaling 경로에서 register/offer/answer/ice-candidate 등을 처리하여 상대 피어로 전달한다.
##* ClientVersionController: /client-version/check 엔드포인트로 클라이언트 버전을 검사한다.
##* HealthController: /health 경로에서 단순한 상태 체크 API를 제공합니다.
# API 설계
<div style="margin-left: 3em;">
{| class="wikitable"
! 경로 !! 메소드 !! 설명 !! 파라미터
|-
| /rooms || POST || 게임 룸 생성 || Header: game-client-id
|-
| /rooms/{roomId} || GET || 게임 룸 조회 || Path: roomId Header: game-client-id
|-
| /rooms/{roomId}/join || POST || 게임 룸 입장 || Path: roomId Header: game-client-id
|-
| /rooms/{roomId}/leave || POST || 게임 룸 퇴장 || Path: roomId Header: game-client-id
|-
| /rooms/{roomId}/gyro || GET || 자이로 상태 조회 || Path: roomId
|-
| /rooms/{roomId}/gyro || POST || 자이로 상태 갱신 || Path: roomId Header: game-controller-id Body: GyroDTO
|-
| /rooms/{roomId}/gyro/join/{axis} || POST || 자이로 제어권 요청 || Path: roomId, axis Header: game-controller-id
|-
| /rooms/{roomId}/gyro/release/{axis} || POST || 자이로 제어권 반환 || Path: roomId, axis Header: game-client-id
|-
| /rooms/{roomId}/code || GET || 단축 코드 조회 || Path: roomId Header: game-client-id
|-
| /rooms/code/{shortCode}/join || POST || 단축 코드로 입장 || Path: shortCode Header: game-client-id
|}
</div>

===스테이지 레벨 디자인===
{| class="wikitable"
! 번호 !! 미리보기 !! 설명
|-
| 1 || [[파일:자이로드롭 그림12.png]] || Stage 1 (Tutorial) ● Gimmic 요소 : X ● 가장 첫번째 맵으로, 조작감을 익히기 위해 별도의 기믹없이 설계하였다. ● 단, 공이 중력의 영향을 받아 가속도를 지니게하여야만 목적지까지 도달할 수 있도록 설계하였다.
|-
| 2 || [[파일:자이로드롭 그림13.png]] || Stage 2 (Tutorial) ● Gimmic 요소 : Key-Door ● 이동을 방해하는 Collider를 지닌 장애물이 존재 ● 장애물이 있는 통로를 지나가 Key를 획득하면 우측에 존재하는 문이 열림
|-
| 3 || [[파일:자이로드롭 그림14.png]] || Stage 3 (Tutorial) ● Gimmic 요소 : PickUp ● Roll 축을 회전시켜 이동하고, Pitch 축을 회전시켜 도토리를 먹도록 설계 ● 도토리를 모두 획득하지 않으면 게임 클리어가 불가하고, 처음 위치로 돌아가게 된다. ● InGame 내에서는 UX를 고려하여, 도토리를 모두 획득하라는 UI가 출력된다.
|-
| 4 || [[파일:자이로드롭 그림15.png]] || Stage 4 (Easy) ● Gimmic : PickUp ● Stage 3과 구조는 동일하지만, 이번에는 도토리를 획득하면, 다시 게임이 reset되는 구조로 설계하였다. ● Stage 4도 Stage 3과 마찬가지로 UI를 출력함으로써 사용자가 스테이지의 목적을 직관적으로 확인할 수 있도록 설계하였다.
|-
| 5 || [[파일:자이로드롭 그림16.png]] || Stage 5 (Easy) ● Gimmic : Key-Door, Plate-Door, Moving Platform ● Stage 2에서 사용된 Key-Door 기믹을 사용했으며, 동시에 Key-Door과 달리 Plate를 밟으면 한정된 시간동안에만 문이 열리는 Plate-Door 기믹을 사용하였다. ● 또한, 일정 범위를 이동하는 발판을 설치해 타이밍을 맞춰 사용자가 자이로 기기를 조작하도록 설계하였다.
|-
| 6 || [[파일:자이로드롭 그림17.png]] || Stage 6 (Easy) ● Gimmic : Maze, Key-Door ● Stage 6은 타 맵들과 달리 낙하의 위험은 없지만 제한된 시야로 미로를 탈출하도록 설계하였다. ● UI를 사용하여 열쇠를 찾아 문을 열고 탈출하라는 메시지를 전달해 스테이지의 목표를 사용자가 직관적으로 알 수 있도록 하였으며, 목표지점까지 갔을 경우 공중에서 전체적인 맵의 구조도를 알 수 있도록 보여진다.
|-
| 7 || [[파일:자이로드롭 그림18.png]] || Stage 7 (Hard) ● Gimmic : Bouncing Obstacle, Crusher, JumpPad ● Hard 난이도부터는 컨트롤을 신경쓰도록 만들었다. ● Mesh Collider로 장애물의 충돌 범위를 설정하고, Collider와 충돌 시 튕겨져 나가는 Bouncing Obstacle 기믹을 사용하였다. ● 장애물을 피해 JumpPad까지 떨어지면 속도와 방향에 맞게 목적지로 점프하게 되는데, 이때 일정주기(3초)마다 마주보고 있는 Crusher이 달려와 충돌하면 최초 위치로 reset되게 설계하였다. ● 이를 피해 최종적으로 목적지로 가는 것이 본 스테이지의 목적이다.
|-
| 8 || [[파일:자이로드롭 그림19.png]] || Stage 8 (Hard) ● Gimmic : TeleportPad, Hammer ● 본 스테이지는 발판 위로 올라가면 지정된 위치로 좌표가 이동되도록 설정한 Teleport 기믹을 사용했다. 정답인 Pad위로 올라가면 다음 Platform으로 넘어가나, 잘못된 Pad위로 올라가면 처음으로 돌아오게 된다. ● Platform 자체에도 360도 회전하는 Hammer 기믹을 두어 사용자의 정밀한 컨트롤을 요구하는 맵이다.
|-
| 9 || [[파일:자이로드롭 그림20.png]] || Stage 9 (Hard) ● Gimmic : JumpPad, BrokenBoard, MovingPlatform, Hammer ● 해당 Stage는 2단계로 나뉘어져있다. ● 처음에 타이밍을 잘 맞춰 내려가면 JumpPad로 별도의 조작없이 자동으로 두번째 단계로 넘어갈 수 있도록 설계했다. ● 두번째 단계에서는 바닥이 Grid로 이루어져 있어 접촉한 바닥은 4.5초 후에 사라져 사용자가 추락하도록 설계해 타이머 기능을 적용했다. 또한 중간에 MovingPlatform을 3개 추가해 사용자가 타이밍을 잘 맞춰 지나가도록 설계했다. ● 압박에 대한 침착함과 정밀한 컨트롤을 모두 요하는 맵으로 가장 난이도 높은 스테이지이다.
|}

==결과 및 평가==
===완료 작품 소개===
# 게임 타이틀
#* [[파일:자이로드롭 그림21.jpg]]
# 메인 화면
#* [[파일:자이로드롭 그림22.png]]
# 멀티플레이 매칭 및 컨트롤러 연결 화면
#* [[파일:자이로드롭 그림23.png]]
#* [[파일:자이로드롭 그림24.png]]
# 스테이지 선택 화면
#* [[파일:자이로드롭 그림25.png]]
# 게임 플레이 화면
#* [[파일:자이로드롭 그림26.png]]
# 설정 화면
#* [[파일:자이로드롭 그림27.png]]
===설치 및 실행===
# 랜딩 페이지([https://gyrodrop.xyz gyrodrop.xyz]) 접속 후 게임 클라이언트 다운로드
#* [[파일:자이로드롭 그림28.png]]
#* 또는 [https://store.onstove.com/ko/games/101506 Stove 플랫폼]에서도 다운로드 및 설치 가능
# 압축 해제 후 폴더를 열어 Gyrodrop 실행
#* Windows
#* [[파일:자이로드롭 그림29.png]]
#* macOS
#* [[파일:자이로드롭 그림30.png]]
#** code-signing이 되어 있지 않으므로, 설정 > 개인정보 보호 및 보안 > Mac을 보호하기 위해 ‘Gyrodrop’을(를) 차단했습니다의 그래도 열기 버튼을 눌러야 합니다.
===완료작품의 평가===
====평가 점수====
아래의 평가 방식대로 ((기능 점수 * 기능 중요도 계수)의 합 * 100)을 계산하여 100점 만점을 기준으로 평가한다.
{| class="wikitable"
! 분류 !! 기능 명칭 !! 평가 방식 !! 기능 점수 !! 중요도 계수 !! 종합 점수
|-
| GR1 || 게임 룸 생성 || 개발 여부 (개발: 1, 미개발: 0) || 1 || 0.07 || 0.07
|-
| GR2 || 게임 룸 입장 || 개발 여부 || 1 || 0.07 || 0.07
|-
| GR3 || 스테이지 플레이 || 개발 여부 || 1 || 0.07 || 0.07
|-
| GY1 || 자이로 데이터 취득 || 개발 여부 || 1 || 0.07 || 0.07
|-
| GY2 || 자이로 대체 컨트롤 || 개발 여부 || 1 || 0.07 || 0.07
|-
| GY3 || 자이로 반응 속도 || max(0, 1 - (반응속도 / 100)) || max(0, 1 - 80/100) = 0.2 || 0.12 || 0.024
|-
| GY4 || 자이로 데이터 취합 || 개발 여부 || 1 || 0.07 || 0.07
|-
| GS1 || 기믹 상호작용 || max(1, 구현된 기믹 수 / 6) || max(1, 10/6) = 1 || 0.08 || 0.08
|-
| GS2 || 협동형 레벨 디자인 || 실제비율 / 100 || 8/9 = 0.89 || 0.10 || 0.089
|-
| GS3 || 네트워크 동기화 || max(0, 1 - (Latency / 30)) *Latency는 교내 무선랜 환경에서 측정 || max(0, 1 - 34.378 / 30) = 0 *34.378ms는 우리 목표치에 근접한 수치로, 평가 식을 잘못 세워 위와 0점이 나왔으나, 기준치에는 충족함. || 0.10 || 0
|-
| GS4 || 렌더링 || min(1, FPS / 60) *FPS는 평균값 사용 || min(1, 59.547 / 60) = 0.99 || 0.10 || 0.099
|-
| GD1 || 레벨 에디터 도구 || 개발 여부 || 1 || 0.02 || 0.02
|-
| GD2 || 배포 및 서버 관리 || 개발 여부 || 1 || 0.06 || 0.06
|-
! 합계 || || || || '''1.00''' || '''0.792'''
|}
100점 만점 중 79.2점을 달성하였다.

====자이로 취합 Latency 측정(GY3)====
#* [[파일:자이로드롭 그림31.png]]
* 자이로 웹 컨트롤러가 자이로 데이터를 보낸 시점을 Unix Timestamp(ms)로 기록하고, Unity 게임 클라이언트에서는 자이로 데이터를 받은 시점을 Unix Timestamp(ms)로 기록하여, 두 시계열 데이터를 분석하였다.
* 자이로 데이터 중 Pitch 정보만 분석하였으며, 두 시계열 데이터를 10ms 단위로 보간하고 정규화(z-score)하여 상호상관(Cross-correlation) 분석하여 가장 유사한 시점의 시간 지연을 추정한다.
* 분석 방식
<pre>
correlation = correlate(client_z, controller_z, mode='full')
lags = np.arange(-len(client_z) + 1, len(client_z))
best_lag = lags[np.argmax(correlation)]
delay_ms = best_lag * 10
</pre>

====네트워크 동기화 Latency 측정(GS3)====
#* [[파일:자이로드롭 그림32.png]]
* 같은 네트워크 내에 있는 서로 다른 두 피어에 Unity 게임 클라이언트를 설치하여, 호스트는 시퀀스 번호를 전송하여 그 시점의 Unix Timestamp를 기록, 게스트는 시퀀스 번호를 받으면 그 시점의 Unix Timestamp를 기록하여 지연 시간을 측정하도록 했다.
* 두 피어(호스트, 게스트)는 같은 NTP 서버를 사용하도록 하였고, 시간 동기화를 1ms 내로 마쳤다.
* 약 10초 정도 측정하였으며, 호스트와 게스트 간의 시퀀스 번호의 Unix Timestamp의 차를 구하여 Latency를 측정하였다.

===향후 평가===
====어려웠던 점====
# 물리엔진 기반으로 캐릭터를 움직일 경우, 플랫폼 회전 시 공이 의도치 않게 공중에 뜨는 현상이 발생하였다. 특히, 플랫폼이 반대 방향으로 급격히 회전하는 경우에 해당 문제가 심화되었다. 이를 해결하기 위해 캐릭터 위치를 기준으로 플랫폼에 수직으로 사영(투영)시키는 로직을 도입하여 항상 플랫폼에 접지하도록 처리하였다. 이후 접지 상태에서 속도를 별도로 제어하는 방식으로 안정적인 움직임을 구현하였다.
# 자이로 센서의 서로 다른 축 입력값을 실시간으로 통합하여 하나의 플랫폼 회전값으로 계산하는 시스템을 구현하였다. 센서 입력의 수집 및 연산은 정상적으로 처리되었으나, 계산된 회전값을 멀티플레이어 양측에서 동일하게 재현하는 부분에서 어려움이 발생하였다. 양측 클라이언트 간 동기화 차이를 최소화하기 위해 네트워크 연산 구조를 조정하였다.
# 전담 그래픽 디자이너 부재로 인해, 게임 컨셉에 부합하는 적절한 에셋 확보에 시간이 소요되었다. 확보한 에셋을 실제 맵에 배치하는 과정 역시 미적 감각이 요구되어 그래픽 품질 측면에서 한계가 존재하였다. 최적화된 배치와 반복적인 테스트를 통해 최대한 시각적 완성도를 유지하려 노력하였다.
# 초기 맵 제작 시, 각 플랫폼이 독립적으로 자이로센서 값을 받아 움직이도록 설계하였다. 하지만 실제 게임 진행에서는 모든 플랫폼이 하나의 전역 좌표축을 기준으로 움직여야 플레이 감각이 자연스러웠다. Unity에서 제공하는 4가지 좌표계(Center, Pivot, Global, Local) 중, Pivot + Global 기준으로 맵을 재설계하여 일관된 회전 중심을 설정하였다. 이를 통해 자이로센서 입력에 따른 플랫폼 회전이 전체 맵에서 일관되게 적용되도록 시스템을 개선하였다.
# 멀티플레이 게임을 구현하기 위해 기존의 서버-클라이언트 기반 동기화 프레임워크들(Netcode, FishNet, Mirror 등)을 검토했지만, 우리 게임의 특수한 요구사항에 적합한 P2P 기반 동기화 프레임워크는 존재하지 않아 직접 아키텍처를 설계하고 구현해야 했다. 본 프로젝트는 2인 협동 게임으로, 플레이어 간의 물리 연산 상태가 정밀하게 일치해야 하며, 물리적으로 떨어진 위치에서도 원활하게 플레이할 수 있어야 했다. 이러한 요구를 바탕으로, 서버 없이 동작하는 P2P 구조를 도입함으로써 비용을 절감하고 구조를 단순화할 수 있다는 장점이 있었지만, NAT 환경에서의 연결 문제 등 여러 네트워크 제약을 해결하는 데 어려움이 따랐다. 이러한 문제를 해결하기 위해 WebRTC를 도입하였고, NAT Traversal이 불가능한 환경에서도 안정적인 연결이 가능하도록 TURN 서버를 구성하여 릴레이 방식의 Fallback을 제공하였다. 또한 동기화 과정에서 필요한 원격 프로시저 호출(RPC) 기능도 자체적으로 구현해야 했는데, 이 과정에서 C#의 리플렉션 기능을 활용하여 원격에서 호출할 메서드와 게임 오브젝트를 어떻게 식별하고 실행할지에 대해 많은 시행착오를 겪으며 해결해 나갔다. 전체적으로 네트워크 구조뿐만 아니라 통신 안정성과 동기화 정확도를 확보하는 것이 매우 도전적인 과제였지만, 직접 구현한 경험을 통해 네트워크 아키텍처에 대한 이해를 크게 확장할 수 있었다.

====차후 구현할 내용====
# 초기 플레이타임이 짧다는 피드백을 수용하여, 스테이지를 추가 구현하여 전체적인 플레이 시간을 확장할 계획이다. 난이도, 기믹 다양성, 컨트롤 난이도를 적절히 조절하여 플레이어의 몰입감을 유지하며 콘텐츠 볼륨을 증가시킬 예정이다.
# 기존 회전 플랫폼의 크기가 커질 경우, 중심 회전축으로부터 거리가 먼 외곽부에서는 기하학적 속도가 과도하게 증가하는 문제가 있었다. 이로 인해 공이 회전 플랫폼 위에서 미끄러지듯 움직이며, 조작감이 저하되는 현상이 발생하였다. 플랫폼 회전 보정 로직을 개선하여, 회전 반경과 공의 상대적 속도를 보다 자연스럽게 보정하고, 플레이어가 플랫폼에 안정적으로 붙어 이동할 수 있도록 조작감을 개선할 예정이다.
# 네트워크 기반 멀티플레이 환경에서 양측 플레이어 간 위치 동기화 및 물리 연산 지연으로 인해 미세한 입력 차이가 발생하는 현상이 확인되었다. 동기화 알고리즘을 최적화하고, 네트워크 패킷 효율화를 통해 보다 부드러운 화면 전환과 입력 반응성을 제공할 예정이다.
# 일부 유저가 게임 시작 시 자이로 센서 축 방향을 직관적으로 파악하기 어려워하는 문제가 발생하였다. 현재 “수평/수직”이라는 텍스트 안내만 제공되어 초기 적응에 혼란이 있었다. 게임 시작 전, 센서 기준 축 방향 및 초기 자세를 그림으로 시각화하여 안내하는 가이드를 추가할 예정이다. 이를 통해 신규 유저의 초기 적응성을 크게 향상시킬 것으로 기대된다.
# 일부 유저가 별도의 외부 컨트롤러가 필요한 것으로 오인하는 사례가 확인되었다. 본 게임이 모바일 기기의 자이로 센서만으로 조작 가능함을 명확히 안내하는 전용 UI를 추가하여, 혼동을 최소화할 계획이다.

==개발 사업비 정산==
===구성원 및 추진체계===
====구성원====
# 조성채(팀장): 게임 클라이언트 개발, 프로젝트 총괄
# 이현제(팀원): 게임 클라이언트 개발, 레벨 디자인
# 이성호(팀원): 게임 클라이언트 개발, 서버 개발

====개발 일정====
{| class="wikitable"
! 단계별 세부개발 내용 !! 담당자 !! 3월 !! 4월 !! 5월 !! 6월
|-
| 프로젝트 주제 및 컨셉 확정 || 전원 || style="background:#C0C0C0;" |   ||   ||   ||  
|-
| 게임 상세 기획 || 전원 || style="background:#C0C0C0;" |   || style="background:#C0C0C0;" |   ||   ||  
|-
| 그래픽 리소스(에셋 등) 확보 || 전원 ||   || style="background:#C0C0C0;" |   ||   ||  
|-
| 게임 레벨 디자인 || 이성호, 이현재 ||   || style="background:#C0C0C0;" |   ||   ||  
|-
| 게임 기능 개발 || 조성채 ||   || style="background:#C0C0C0;" |   || style="background:#C0C0C0;" |   ||  
|-
| 서버 설계 및 개발 || 이성호, 이현재 ||   || style="background:#C0C0C0;" |   || style="background:#C0C0C0;" |   ||  
|-
| UI 구현 || 조성채 ||   || style="background:#C0C0C0;" |   || style="background:#C0C0C0;" |   ||  
|-
| 설계 보고서 작성 || 전원 ||   ||   || style="background:#C0C0C0;" |   ||  
|-
| 게임 테스트 || 전원 ||   ||   || style="background:#C0C0C0;" |   ||  
|-
| 플랫폼 등록 || 전원 ||   ||   || style="background:#C0C0C0;" |   || style="background:#C0C0C0;" |  
|-
| 피드백 및 보완 || 전원 ||   ||   ||   || style="background:#C0C0C0;" |  
|}

====소스코드 관리 및 협업 체계====
# GitHub Team 기능을 활용하여 모든 코드를 중앙 Repository에서 관리한다.
# 기능 단위 개발은 feature 브랜치에서 진행하며, 완료된 작업은 Pull Request(PR)를 통해 dev 브랜치에 제안한다.
# PR은 팀원 간 코드 리뷰를 통해 Approve된 경우에만 Dev 브랜치에 병합(Merge)할 수 있다.
# 병합 전에는 항상 최신 dev 브랜치 기준으로 Rebase를 수행하여 충돌 가능성을 사전에 방지하고, 커밋 히스토리를 정돈한다.
# 주요 릴리스 시점에는 dev 브랜치를 main 브랜치에 병합하고, 이를 기준으로 최종 배포를 진행한다.

===개발사업비 내역서===
(단위: 원)
{| class="wikitable"
! 항목 (품명, 규격) !! 수량 !! 단가 !! 금액 계 !! 금액 현금 !! 비고
|-
| 개발 관련 온라인 강의 [C#과 유니티로 만드는 MMORPG 게임 개발 시리즈] Part3: 유니티 엔진 || 1 || 66,000 || 66,000 || 66,000 ||
|-
| 개발 관련 온라인 강의 [입문자를 위한 UE5] Part1. 언리얼 엔진 블루프린트 || 1 || 55,000 || 55,000 || 55,000 ||
|-
| 서버 비용 gyrodrop.xyz 도메인, Route 53 || 1 || 26,180 || 26,180 || 26,180 ||
|-
| 다람쥐 모델 에셋 || 1 || 8,570 || 8,570 || 8,570 ||
|-
| 벨킨 connect USB C 6in1 멀티 포트 허브 어댑터 AVC008fqSGY V2 || 1 || 49,900 || 49,900 || 49,900 ||
|-
| 가상 면접 사례로 배우는 대규모 시스템 설계 기초 || 1 || 21,600 || 21,600 || 21,600 ||
|-
| 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 || 1 || 32,400 || 32,400 || 32,400 ||
|-
| 가상 면접 사례로 배우는 머신러닝 시스템 설계 기초 || 1 || 24,300 || 24,300 || 24,300 ||
|-
| 문구비 || 1 || 3,000 || 3,000 || 3,000 ||
|-
| 회의 지원금 || 1 || 113,800 || 113,800 || 113,800 ||
|-
! 합계 || || || '''400,750''' || '''400,750''' || '''400,750'''
|}

1분반-올인뷰

2026-03-11T07:35:26Z

Adcdc: Adcdc (토론)의 12612판 편집을 되돌림

<div>__TOC__</div>

==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 : ''' 할인정보수집시스템

''' 영문 : ''' Discount Information Collection System

===과제 팀명===
올인뷰

===지도교수===
이병정 교수님

===개발기간===
2025년 3월 ~ 2025년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 컴퓨터과학부 20199200** 서*진(팀장)

서울시립대학교 컴퓨터과학부 20199200** 김*서

서울시립대학교 컴퓨터과학부 20219200** 권*재

==서론==
===개발 과제의 개요===
====개발 과제 요약====
◇ 2030 세대가 자주 사용하는 배달 및 온라인 브랜드 웹페이지의 할인 이벤트 정보를 한 곳에서 확인할 수 있는 어플리케이션을 개발한다.
◇ 사진에서 텍스트를 추출하여 할인 관련 정보만 필터링하는 기능을 제공한다.
◇ 사용자 위치를 기반으로 지점별 배달비 정보 및 주변 가게들의 정보를 제공하며, 백년가게 및 전통시장의 정보를 추가적으로 제공한다.
◇ 직관적인 UI/UX를 적용하여 쉽고 빠르게 할인 정보를 탐색할 수 있도록 설계한다.

====개발 과제의 배경====
◇ 배달음식의 수요와 그에 상응하는 배달 플랫폼과 할인 행사의 증가로 인해 제공되는 할인 정보를 일일이 확인하는 것이 어려워졌다.
◇ 할인 정보와 배달비 정보를 자동으로 정리하여 사용자에게 제공함으로써 소비자들의 효율적인 할인 정보 확인이 가능하다.
◇ 위치 기반 기능을 통해 편의성을 제공함과 동시에, 백년가게 및 전통시장 표시 기능을 통해 지역 상권 활성화에 기여한다.
◇ 공익적 요소를 추가함으로써 단순 할인 정보 제공을 넘어 사회적 가치 창출이 가능하다.

====개발 과제의 목표 및 내용====
◇ 인기 배달 앱의 할인 이벤트 정보를 수집하고, 이를 사용자가 쉽게 조회할 수 있도록 정리하는 기능을 구현한다.
◇ OCR 기술을 활용하여 사진 속 할인 정보를 자동으로 추출하고 필터링하는 기능을 제공한다.
◇ 사용자 위치를 기반으로 할인 이벤트에 해당하는 주변 가게 정보를 제공하며, 백년가게 및 전통시장의 위치를 별도로 표기한다.
◇ 반응형 디자인을 적용하여 다양한 모바일 기기에서 최적화된 사용자 경험을 제공한다.

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
*전 세계적인 기술현황

◇ UI 자동화 기술 최신 트렌드
◇ 모바일 앱 데이터 자동화: Appium과 같은 UI 자동화 도구를 사용하여, 모바일 애플리케이션에서 발생하는 데이터를 실시간으로 수집하고 추출하는 기술이 중요해짐.
◇ 자동화된 테스트 및 크롤링: Appium을 활용하여, 모바일 앱 내에서 사용자 인터페이스(UI)를 자동으로 테스트하고, 할인 정보를 추출하는 예시와 같이 자동화된 크롤링 시스템 구축.
◇ 비즈니스 프로세스 최적화: 자동화된 UI 크롤링을 통해 수집된 데이터를 AI와 결합하여, 실시간으로 유효한 정보를 제공하고, 비즈니스 프로세스를 최적화하는 시스템 적용.

◇ OCR 기술 최신 트렌드
◇ OCR 기술은 딥러닝 기반으로 텍스트 인식 정확도를 높이고, AI와 융합하여 데이터를 분석 및 활용하는 방향으로 발전 중.
◇ Transformer OCR 기술은 End-to-End 구조로 문서 내 텍스트와 의미를 동시에 파악하며, 문맥 이해에 탁월한 성능을 보임.
◇ OCR + NLP 융합 기술은 단순 텍스트 추출을 넘어 의미 분석, 자동 요약, 문서 분류 등 문맥 기반의 고도화된 처리 자동화에 활용.
◇ OCR 결과를 활용한 프로세스 자동화 (RPA) 기술도 수요가 증가하고 있으며, OCR + AI 융합을 통해 자동화된 비즈니스 프로세스 적용이 중요해짐.

*특허조사 및 특허 전략 분석

◇ OCR 관련 특허
◇ KR102279456B1(문서의 광학 문자 인식 기법)
◇ CN111539415A (OCR 이미지 인식을 위한 이미지 처리 방법 및 시스템)
◇ US8718375B2 (OCR 필기체 인식 시스템)
◇ 프로젝트 주제 관련 특허
◇ 인터넷 커뮤니티 기반한 상품의 특가 가격 정보를 제공하는 특허(1020240038442)가 존재

◇ 특허전략
◇ OCR + AI 기술의 경우 딥러닝 기반 OCR 핵심 기술이 다수 특허로 보호되고 있음.
◇ 차별화 전략: OCR을 특정 분야에 특화하여 융합형 솔루션으로 특허화 (예: OCR 기반 배달앱 자동 할 인 시스템).
◇ 프로젝트 주제 관련의 경우 본 프로젝트는 정보의 원천이 인터넷 커뮤니티가 아닌 서비스에 비롯되기 에 해당 특허에 저촉되지 않을 것이다.
◇ Appium의 경우 아파치 라이선스 2.0를 사용함에 따라 해당 프레임워크를 이용하였다는 내용을 게재 하면 2차 라이선스와 변형물의 특허 출원이 가능하다.

*기술 로드맵
[[파일:기술로드맵(자동화).jpg]]

====시장상황에 대한 분석====
*경쟁제품 조사 비교
◇ 기존 앱은 특정 제품군에 대한 당일 할인 정보에 특화되어 있거나, 다양한 브랜드의 할인 정보를 제공한다고 하더라도 위치 기반 서비스가 없어 배달비 정보와 사용자 주변의 할인 정보를 찾기 어렵다는 단점이 있었음.
◇ 반면, 개발 예정 앱은 사용자 위치를 기반으로 배달비 및 주변 가게 정보가 제공되며, 지역 상권 활성화에도 기여할 수 있다는 이점이 있음. 뿐만 아니라 2030의 소비의 대부분을 차지하는 음식 및 의류의 할인 정보에 집중하는 것으로 소비 패턴을 반영하여 어플리케이션에 적용함. 필요한 정보를 제 위치 기반의 가게 제공은 타 경쟁제품들과 비교하여 사용자 편의성을 크게 증대할 수 잇는 요소가 될 것임.

*마케팅 전략 제시
◇ 초기 사용자 확보
2030세대가 자주 방문하는 SNS (인스타그램, 페이스북, 트위터 등)을 활용한 홍보
할인 이벤트 정보를 모아둔 네이버 블록, 카페와 협업하여 서비스 노출
커뮤니티에 할인 정보를 공유하며 자연스럽게 앱 홍보
◇ 파트너십 및 제휴
지역 상권 및 백년가게와 협력하여 가게 홍보 기회 제공
배달 및 쇼핑몰 플랫폼과 협력하여 공식 할인 정보 연동 가능성 검토
◇ 차별화된 콘텐츠 활용
할인 정보 알림 기능을 제공하여 사용자들이 즉각적 혜택을 받을 수 있도록 유도
데일리 할인 소식 푸시 알림 등의 기능을 추가하여 지속적인 사용자 유입 유도
◇ 지속적인 개선 및 업데이트
초기 사용자 피드백을 반영하여 기능 개선 및 UI/UX 최적화
시즌별 할인 정보 제공 (블랙프라이데이, 명절 할인 등)

===개발과제의 기대효과===
====기술적 기대효과====
◇ OCR 및 OpenCV를 통해 다양한 플랫폼에서 제공하는 할인 정보를 자동으로 수집 및 필터링하여 최신 할인 정보 제공의 정확성과 효율성 향상
◇ 사용자의 실시간 위치를 기반으로 주변 가게 정보를 제공하고, 백년가게 및 지역시장을 표기함으로써 정확한 위치 기반 검색 기능 강화
◇ 사용자 맞춤형 할인 정보를 추천하고, 사용자 경험을 강화

====경제적, 사회적 기대 및 파급효과====
◇ 소비자 편의성 및 경제적 이익 증대
다양한 할인 정보를 통합해 제공함으로써 소비자가 여러 플랫폼을 직접 확인해야 하는 불편함 해소 및 경제적 혜택 극대화
◇ 소상공인 및 지역 상권 활성화 기여
위치 기반 서비스와 백년가게 표기 기능을 통해 지역 상점의 홍보 및 접근성 증대 효과 기대
◇ 공익적 가치 창출 및 전통 상점 보호
백년가게 표기 기능을 통해 전통 있는 상점의 인지도를 높이고, 지역 상권에 대한 관심 유도 및 보존 기여

===기술개발 일정 및 추진체계===
====개발 일정====
[[파일:개발인정Q1.jpg]]

====구성원 및 추진체계====
[[파일:구성원Q1.jpg]]

==설계==
===설계사양===
====제품의 요구사항====
[[파일:제품요구사항Q1.jpg]]

====설계 사양====
◇ F1 - 기능: OCR 기반 할인정보 수집
설명: 각 배달 어플리케이션의 이벤트 탭에서 제공되는 할인 이벤트 이미지를 수집하고, OCR 및 LLM 기반 분석을 통해 텍스트 기반 할인 정보를 리스트화한다.
정량 목표:
a. Back-end: UI 자동화로 이미지 수집 후 OCR을 통해 텍스트를 추출하고, 이를 할인 정보로 정제하여 DB에 저장한다.
b. Front-end: 사용자에게 할인 정보 리스트를 제공하며, 사용자가 브랜드를 즐겨찾기에 등록할 수 있는 UI를 구현한다.

◇ F2 - 기능: OCR 모델 선택 및 적용
설명: 이미지 내의 텍스트를 정확히 추출하기 위해 OCR 모델을 적용한다.
정량 목표:
a. Back-end: Google Cloud Vision OCR API를 통해 할인 정보 텍스트를 추출하고, 정제된 데이터로 가공한다.
b. Front-end: OCR 결과를 시각화하여 사용자에게 표시하고, 필요시 결과 보정 UI를 제공한다.

◇ F3 - 기능: 위치 기반 할인 지도 구현
설명: 사용자의 현재 위치를 기준으로 반경 내 할인 매장, 백년가게, 전통시장 등을 지도에 시각화한다.
정량 목표:
a. Back-end: 위치 기반 할인 매장 정보를 수집하고, 지도 좌표에 맞춰 매핑 데이터를 생성한다.
b. Front-end: Google Map 및 Naver Map API를 활용하여 위치 기반 할인 매장을 마커와 뱃지로 시각화하고 지도 상에 출력한다.

◇ F4 - 기능: 지도 API 연동 및 커스텀 마커 표시
설명: Expo 환경에서 지도 서비스를 안정적으로 구현하기 위해 Google Map을 기본으로 사용하며, 필요 시 Naver Map과 병행한다.
정량 목표:
a. Back-end: 매장 위치 및 유형 정보(할인, 전통시장, 백년가게)를 반환하는 API 제공.
b. Front-end: 지도 내 마커, 뱃지, 애니메이션 등을 적용하여 사용자 경험 향상.

◇ F5 - 기능: 푸시 알림 시스템 구현
설명: 사용자의 선호 브랜드와 관련된 할인 정보가 발생했을 때 실시간 푸시 알림을 전송한다.
정량 목표:
a. Back-end: Firebase Cloud Messaging을 활용하여 알림 전송 조건을 판별하고, 타겟 사용자에게 메시지를 전송한다.
b. Front-end: 알림 수신 여부 설정 UI 제공 및 수신된 알림을 앱 내 알림센터에 표시.

===개념설계안===
◇ 유스케이스

[[파일:유스케이스Q1.jpg]]

◇ 주요 시퀀스 다이어그램

◇ 사용자 주소 등록 시퀀스
[[파일:시퀀스Q1.jpg]]
◇ 할인 정보 조회 시퀀스
[[파일:시퀀스Q2.jpg]]
◇ 지도 내 위치 조회 시퀀스
[[파일:시퀀스Q3.jpg]]
◇ 푸시 알림 시퀀스
[[파일:시퀀스Q4.jpg]]

===이론적 계산 및 시뮬레이션===
내용

===상세설계 내용===
◇ ERD
[[파일:ERDQ1.jpg]]
◇ 클래스 다이어그램
[[파일:클래스Q5.jpg]]
◇ 아키텍쳐 다이어그램
[[파일:아키텍쳐Q1.jpg]]

==결과 및 평가==
===완료 작품의 소개===
====프로토타입 사진 혹은 작동 장면====
◇ 초기 메인화면 및 주소 등록 화면 

[[파일:실행Q1.jpg]]
[[파일:실행Q2.jpg]] 

◇ 할인 정보 조회 및 정렬 기능 

[[파일:실행Q3.jpg]]
[[파일:실행Q4.jpg]]
[[파일:실행Q5.jpg]]
[[파일:실행Q6.jpg]] 

◇ 주소 기반 지도 화면 

[[파일:실행Q7.jpg]]
[[파일:실행Q8.jpg]]
[[파일:실행Q9.jpg]] 

◇ 즐겨찾기 및 설정 화면 

[[파일:실행Q10.jpg]]
[[파일:실행Q11.jpg]] 

===관련사업비 내역서===
[[파일:내역서Q1.jpg]]

===완료작품의 평가===
[[파일:평가Q1.jpg]]

===향후계획===
가. 어려웠던 내용들

1. Exop 기반의 React Native에서 구현
위 개발 환경에서 종종 발생하는 버전 충돌, 모듈 의존성 문제, 안드로이드 실기기 테스트 한정 기능은 개발 효율성과 테스트 흐름을 저해하는 요소였다.

2. Virtual Android Devices 에서의 접근
에뮬레이터에서 배달어플을 접근하는 과정에 있어서 접근이 차단된 경우와, 주소등록 시 카카오맵과 연동되어 주소등록 이용이 불가능한다든지, 그리고 자동화 사용 시 배달어플 내의 객체 요소에 접근하는게 불가능하여 개발에 어려움이 있었다.

3. Virtual Android Devices 문제
에뮬레이터에서 자동화 작업을 하면서 버전과의 문제로 세션이 너무 빨리 죽는 문제가 생기기도 하였고 로컬에서 병렬처리를 진행하면서 appium서버를 각각 배치할 때 인식을 못하는 어려움도 있었다.

4. 푸시 메시지 구현
푸시 메시지에 대해 처음 다루면서 푸시 메시지가 어떤 원리로 사용자에게 전달되는지에 대해 배우고, 이 과정에서 사용자 인증과 같은 보안을 실제 프로젝트에 적용하는 것이 어려웠다.

5. 사용자 관련 기능 구현
우선 로그인 방식을 따로 구현하는 것은 정보를 정리해서 보여주는 프로젝트에서 의미가 없다고 판단하였기에, 로그인 방식을 구현하지 않고 사용자의 최소 정보만 받아서 처리하기로 결정하였다. 이 과정에서 사용자 인증과 관련된 부분을 어떻게 구현할지 고민하는 것이 어려웠다.

나. 차후 구현할 내용

1. API 에러 및 네트워크 예외 처리 보강
현재는 대부분의 API 요청에 try-catch로 기본적인 에러 처리를 하고 있으나, 향후에는 공통 API 요청 유틸을 만들어 에러 메시지 통합 처리, 로딩 상태 핸들링, 사용자 피드백 메시지 표준화 등의 개선이 필요하다.

2. 디자인 시스템 도입
프로젝트 후반부에 UI 개선을 진행했지만, 스타일 일관성을 유지하기 어려운 부분이 있었다. 추후에는 Tailwind-like 스타일 유틸리티 또는 자체 디자인 시스템을 구축해 재사용 가능한 컴포넌트와 명확한 색상/폰트/여백 규칙을 정의하고 싶다.

3. 병렬처리 구현
현재는 클라우드상에서 에뮬레이터를 실행하고 자동화 작업까지 진행하기에 gpu 랜더링 문제라든지, cpu 가속 등의 문제가 남아있어 어려움이 있지만 추후에 클라우드상에서 에뮬레이터 최적화된 모델이 나온다면 병렬처리를 적용하여 속도 개선을 이루고 싶다.

4. 보안 관련 내용 강화
현재 서버 상에서 처리할 때 위치 정보나 토큰을 암호화하지 않고 POST 형식으로 처리해서 보내고 있는데, 이를 SHA-2과 같은 암호화 알고리즘을 이용해 처리하고 싶다.

5. 사용자 선호도 관련 구현
현재 기본 순으로 정렬할 시 백엔드에서 DB로 매핑한 것 순서대로 출력하게 되어있다. 이렇게 출력되는게 아니라 사용자 선호도 높은 항목을 상단에 띄우게 하고 싶다. 이러한 과정을 진행하기 위해서는 사용자 선호도 관련 테이블을 구성하고, 프론트엔드에서 log로 수집한 선호도 정보를 점수로 치환해서 저장하는 과정에 대해 구현해보고 싶다.

===참고문헌 및 참고사이트===
특허 참고자료 :
https://patents.google.com/
https://www.kipris.or.kr/

OCR 참고자료 :
https://it-stargazer.com/%EC%B5%9C%EC%8B%A0-ocr-%EA%B8%B0%EC%88%A0-%EB%8F%99%ED%96%A5-%EB%B0%8F-%ED%99%9C%EC%9A%A9-%EC%82%AC%EB%A1%80-ai-%EB%A8%B8%EC%8B%A0%EB%9F%AC%EB%8B%9D-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B8%B0/
https://aws.amazon.com/ko/what-is/ocr/

UI자동화 참고자료 :
https://appium.io/docs/en/latest/

OCR 및 UI 자동화 기술로드맵 :
https://en.wikipedia.org/wiki/

OpenCV 참고자료 :
https://opencv.org/

1분반-슈팅스타

2026-03-11T07:34:55Z

Adcdc: Adcdc (토론)의 12611판 편집을 되돌림

<div>__TOC__</div>

==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 : ''' 탑다운 전략 슈팅 게임

''' 영문 : ''' Top-down tactical shooting Game..

===과제 팀명===
슈팅스타

===지도교수===
안상현 교수님

===개발기간===
2025년 3월 ~ 2025년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 컴퓨터과학부 20199200** 한*만(팀장)

서울시립대학교 컴퓨터과학부 20199200** 정*원

서울시립대학교 컴퓨터과학부 20209200** 박*빈

서울시립대학교 컴퓨터과학부 20209200** 임*현

==서론==
===개발 과제의 개요===
====개발 과제 요약====
◇ 전략적 팀플레이를 핵심으로 하는 탑다운 슈팅 게임 개발

◇ 자원의 위치와 장애물이 매 판마다 절차적으로 생성되는 전장 환경에서 전술적 협동이 가능
한 멀티플레이 시스템 구축

◇ 수집한 자원에 따라 무기에 랜덤한 성능이 부여되는 무기 제작 시스템 개발

◇ 슈팅 액션과 전략적 요소를 융합한 신개념 게임 콘텐츠 구현

====개발 과제의 배경====
1) 복잡한 접속 절차
기존의 모바일 멀티플레이 게임은 대부분 인터넷 접속, 로그인, 서버 매치메이킹 등의 복잡한 절차를 요구한다. 이러한 과정은 짧은 시간 동안 빠르게 게임을 즐기고자 하는 사용자에게 불편하게 느껴질 수 있다. 본 게임은 Wi-Fi Direct 기술을 활용하여, 로그인이나 인터넷 연결 없이도 주변 플레이어와 바로 연결되어 즉시 멀티플레이를 시작할 수 있는 환경을 제공한다. 이러한 접근은 ‘빠르고 간편한 게임 경험’이라는 핵심 가치를 실현한다.

2) 온라인 환경 제약
외부 환경에서 모바일 게임을 즐기려 할 때, 데이터 소모는 제약이 될 수 있다.
Wi-Fi Direct 기반의 본 게임은 이러한 제약을 뛰어넘어, 인터넷이 없는 상황에서도 근거리 유저 간의 직접 연결로 언제 어디서나 함께 플레이할 수 있다. 이는 네트워크 환경에 구애받지 않고 자유로운 멀티플레이를 가능하게 하여, 실외나 일상 속에서도 쉽게 함께 게임을 즐길 수 있도록 한다.

3) 반복적인 콘텐츠 구조와 제한된 전략 선택지
기존 탑다운 슈팅 게임은 고정된 맵과 자원 구조로 인해 플레이의 반복성이 강하고 전략적 다양성이 부족하다는 한계를 가지고 있다. 본 게임은 맵과 자원을 절차적으로 생성하여, 매 경기
마다 새로운 환경을 제공한다. 플레이어는 그 안에서 자원을 채집하고, 채집한 자원의 종류와 양에 따라 다양한 무기를 제작하게 된다. 이를 통해 예측 불가능한 플레이 흐름과 전략적 유연성을 확보하였으며, 반복 플레이에서도 지속적인 신선함과 몰입감을 유지할 수 있다.

====개발 과제의 목표 및 내용====
◇ 플레이어는 절차적으로 생성된 맵에서 자원을 자유롭게 탐색하고 채집할 수 있다.

◇ 플레이어는 채집한 자원의 종류와 양에 따라 다양한 무기와 장비를 제작하거나 업그레이드할 수 있다.

◇ Wi-Fi Direct 기반의 P2P 연결을 통해 별도의 로그인이나 인터넷 접속 없이 주변 유저와 즉시 멀티플레이를 시작할 수 있다.

◇ 멀티플레이 시, 플레이어들은 협동 또는 경쟁을 통해 자원을 공유하거나 탈취하며 전략적으로 전투를 전개할 수 있다

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
*전 세계적인 기술현황
◇ Wi-Fi Direct

Wi-Fi Direct는 별도의 무선 액세스 포인트(AP) 없이도 Wi-Fi 기능이 있는 두 기기 간에 직접 연결을 가능하게 해주는 근거리 무선 통신 기술이다. 기존 Wi-Fi 인프라 없이도 빠른 속도와
안정적인 연결을 제공하며, 블루투스보다 높은 전송 대역폭과 더 넓은 통신 범위를 지원한다.
Android OS와 Windows 등 다양한 플랫폼에서 공식적으로 지원되며, 파일 공유, 사진 전송, 실시간 스트리밍, 로컬 멀티플레이 게임 등 다양한 분야에서 활용되고 있다.

◇ 절차적 생성

절차적 생성은 알고리즘과 규칙 기반 로직을 활용해 맵, 지형, 아이템, 캐릭터 등 게임 콘텐츠를 자동 생성하는 기술이다.
개발자가 수작업으로 일일이 제작하지 않아도 콘텐츠를 다양하게 생성할 수 있어, 게임의 반복성을 줄이고 플레이 경험의 다양성을 높이는 데 효과적이다.
특히 로그라이크, 샌드박스, 오픈월드 장르에서 널리 사용되며, 대표적으로 《Minecraft》, 《No Man's Sky》, 《Hades》 등에서 그 활용 사례를 찾아볼 수 있다.
절차적 생성은 개발 효율성을 높이는 동시에, 플레이어마다 매번 다른 환경을 제공하는 핵심 기술로 자리잡고 있다.

◇ Unreal Engine5

Unreal Engine 5는 에픽게임즈(Epic Games)에서 개발한 차세대 실시간 3D 콘텐츠 제작 엔진으로, 고품질 그래픽과 고성능 게임 개발을 동시에 지원하는 대표적인 게임 엔진이다.
UE5는 이전 버전 대비 사실적인 디테일과 표현력을 대폭 향상시킨 나나이트(Nanite)와 루멘(Lumen)이라는 두 핵심 기술을 중심으로 설계되었다.
나나이트(Nanite)는 수십억 개의 폴리곤으로 이루어진 고해상도 메시를 실시간으로 스트리밍하고 렌더링할 수 있는 가상화 지오메트리 기술로,
고사양 모델을 따로 최적화하지 않아도 퍼포먼스를 유지할 수 있게 해준다.
루멘(Lumen)은 실시간 글로벌 일루미네이션 및 반사 시스템으로, 별도의 라이트 베이킹 없이도 사실적인 조명 변화와 반사 표현이 가능하다.
또한 UE5는 World Partition, Control Rig, MetaHuman, Procedural Content Generation(PCG)
등의 기능도 제공하여, 대규모 오픈월드 개발, 애니메이션 제작, 캐릭터 생성, 절차적 콘텐츠 구현 등을 더욱 효율적으로 수행할 수 있게 한다.
게임 외에도 영화, 방송, 건축 시각화, 자동차 시뮬레이션, 메타버스 등 다양한 산업 분야에서 활용되고 있으며,
Blueprint 비주얼 스크립팅을 통해 프로그래밍 지식이 적은 사용자도 직관적으로 시스템을 구현할 수 있도록 돕는다.

*특허조사 및 특허 전략 분석
게임 산업은 기술 특허보다는 콘텐츠의 창의성, 사용자 경험(UX), 그리고 운영 전략이 경쟁력의 핵심이 되는 분야이다.
특허 조사 및 전략 수립보다는 안정적 서비스 구현과 게임성 확보에 중점을 두는 것이 더 실질적이라고 판단된다.

*기술 로드맵
◇ 게임 진입 및 플레이어 매칭
· 근처 기기를 검색하고, 게임 방을 개설하거나 접속 가능한 방을 탐색할 수 있도록 한다.

◇ 로비 및 파티 구성
· 2:2 팀 구성을 위한 간단한 로비 시스템을 제공한다.

◇ 절차적 맵 생성 및 전투 진입
· 절차적 생성 알고리즘을 구현하여 게임 시작 시 맵, 자원, 장애물이 자동 생성될 수 있게 한다.

◇ 무기 제작 및 자원 채집 시스템
· 수집한 자원의 종류와 양에 따라 랜덤성이 가미된 무기를 제작할 수 있게 한다.

◇ 플레이어 조작 및 전투 시스템
모바일 터치 UI 기반의 조작 인터페이스를 사용하여 이동, 공격, 회피 등의 기능을 직관적으로 수행할 수 있도록 구현한다.

◇ HUD
· 플레이어의 체력, 무기 상태 등을 실시간으로 표시한다.

◇ 결과 처리
· 라운드 종료 후 승패를 판단하고 결과 화면을 출력한다.

====시장상황에 대한 분석====
*경쟁제품 조사 비교
1. 브롤스타즈
슈퍼셀의 ‘브롤스타즈’는 2018년 12월 출시된 이후 글로벌 시장에서 큰 인기를 끌고 있는 모바
일 팀 기반 슈팅 게임이다. 특히 2023년 하반기부터 다운로드 수가 꾸준히 증가해 2024년 2월
에는 약 25만 건으로 2020년 5월 이후 가장 높은 월 다운로드 수를 기록했고, 월 매출도 약 750만 달러(약 101억 원)로 50개월 만에 최고치를 달성하는 등 저력을 보여주고 있다. 다양한 게임 모드와 개성 있는 캐릭터, 빠른 템포의 전투 등으로 많은 유저층을 확보하고 있지만, 경쟁전 중심의 콘텐츠 구조는 높은 랭크 구간에 집중된 설계로 인해 일반 유저들이 쉽게 접근하
기 어렵다는 단점이 있다. 실제로 일부 플레이어들은 경쟁전에서 오는 피로도와 진입 장벽을
주요 불만 요소로 꼽는다. 이에 비해 우리 게임은 보다 진입 장벽을 낮추고 즉각적으로 플레이
가능한 환경을 제공함으로써 접근성을 크게 향상시킨다. 특히 Wi-Fi Direct 기반 멀티플레이를
통해 인터넷 연결이나 로그인 없이도 주변 사람들과 빠르게 게임을 시작할 수 있어, 복잡한
매치메이킹 없이도 손쉽게 팀전을 즐길 수 있다. 또한 브롤스타즈와 달리, 반복성에서 벗어나
기 위해 매판마다 절차적으로 생성되는 맵과 자원을 통해 유저마다 매번 새로운 전략을 구성
하게 만들며, 전략적 깊이와 몰입도를 더한다.

2. PUBG: BLINDSPOT
크래프톤의 ‘PUBG: BLINDSPOT’은 2025년 2월에 공개된 5:5 팀 기반 탑다운 전술 슈팅 게임이
다. PUBG IP를 활용해 제작된 이 작품은 현실적인 슈팅 감각과 탑다운 시점의 전략적 플레이
를 결합하며, 기존 배틀로얄 장르와는 차별화된 방향을 제시한다. 다만 시야 제한이 뚜렷하고,
적의 위치를 파악하기 어려운 상황이 발생할 수 있어 전체적인 게임 난이도를 높게 느끼는 유
저들도 존재한다.
이에 반해 우리 게임은 탑다운 시점이 주는 전략적 장점은 살리되, 플레이어의 불편함을 줄이
고 협동의 재미를 강화하는 방향으로 설계되었다. BLINDSPOT이 고정된 전장 구조를 기반으로
하는 반면, 우리 게임은 매 경기마다 맵이 절차적으로 생성되어 매번 새로운 환경에서 자원을
채집하고, 자원의 종류와 양에 따라 무기를 제작하게 된다. 이를 통해 플레이어는 반복되지
않는 전투 흐름 속에서 유동적인 전략을 구성하며, 매번 색다른 플레이 경험을 누릴 수 있다.

*마케팅 전략 제시
※ SWOT 분석

강점 (Strength)

1) 이 프로젝트의 경쟁 우위는 무엇인가?

· Wi-Fi Direct를 활용한 인터넷 없이 즉시 가능한 멀티플레이는 뚜렷한 차별점이다.

· 로그인, 서버 매치메이킹 없이 빠른 2:2 로컬 플레이가 가능해, 접근성과 편의성이 탁월하다.

· 절차적으로 생성되는 맵과 자원을 통해, 매 경기 새로운 전략 구성이 가능하다.

· 자원의 종류와 양에 따라 달라지는 무기 제작 시스템은 유저에게 반복 플레이 동기를 제공한
다.

2) 이 프로젝트의 특별한 점은 무엇인가?

· 인터넷 없이 주변 친구와 즉석에서 함께 플레이할 수 있어, 빠르고 간편한 오프라인 게임 환
경을 제공한다.

· 매 경기 다른 환경에서 자원을 채집하고 무기를 제작하는 방식은, 고착화되고 반복되는 전투
가 아닌, 전략성과 유동성이 높은 전투 경험을 제공한다.

· 게임의 주요 타겟층 중 하나인 10대 남성들은 학교 등 물리적으로 가까운 공간에서 친구들
과 실시간으로 게임을 즐기는 경향이 뚜렷하게 나타난다.
따라서, 해당 사용자층의 이용 패턴에 최적화된 콘텐츠 설계와 마케팅 전략 수립이 가능하다

3) 이 프로젝트가 사용자에게 매력적인 이유는 무엇인가?

· 캐주얼하면서도 전략적인 요소가 결합되어 있어, 라이트 유저와 코어 유저 모두가 쉽게 접근
가능하다.

· 기존 모바일 슈팅 게임보다 더 깊이 있는 전략성과 자유도 제공

· 가입이나 서버 매칭 등의 복잡한 과정 없이, 단말기만 있으면 바로 플레이가 가능한 접근성
이 큰 장점이다.

약점 (Weakness)

1) 업계 내 다른 게임사 혹은 프로젝트와 비교했을 때 이 팀이 겪고 있는 어려움은 무엇인가?

· 비교적 소규모 팀으로 개발이 진행되고 있어, 콘텐츠 양이나 비주얼 퀄리티 면에서 대형 프
로젝트 대비 제약이 있을 수 있다.

· 실제 기기를 활용한 테스트 환경이 부족하다.

· Wi-Fi Direct 기술의 물리적 거리 제한이 존재하기 때문에, 플레이어 간의 근접성이 전제된
구조에서만 원활한 플레이가 가능하다.

· 자본금의 부족으로 인해, 출시 이후 유저 확보를 위한 마케팅 활동에 어려움을 겪을 가능성
이 있다.

기회 (Opportunity)

1) 최근 게임 트렌드는 무엇인가?

· 글로벌 시장 기준으로 모바일 게임은 2023년 767억 달러의 수익을 기록하며, 팬데믹 이전
대비 22% 상승하였다. 2028년에는 1,000억 달러 돌파가 예상될 만큼 성장 속도가 빠르며, 특
히 미국 시장에서도 2024년 19억 6천만 달러, 2027년에는 23억 8천만 달러까지 확대될 전망
이다. 이러한 흐름 속에서 모바일 플랫폼에 최적화된 우리 게임은 더욱 빠르게 사용자층을 확
보할 수 있는 가능성을 가진다.

위협 (Threat)

1) 경쟁 게임들이 더 잘하고 있는 것은 무엇인가?

· 브롤스타즈와 같은 대형 게임은 캐릭터성, 라이브 서비스, 마케팅 측면에서 절대적 우위를 가
진다.
대형 게임이 커버하지 못하는 오프라인 로컬 멀티 중심 유저층(예: 학교, 학원에서 친구들과 즉
시 플레이하려는 10대)을 정조준하여 차별화를 해야한다.

· BLINDSPOT은 배틀그라운드라는 유명 게임을 개발한 PUBG 스튜디오의 차기작으로 유저들의
관심을 선점할 수 있다.
BLINDSPOT처럼 복잡하거나 경쟁 중심인 게임과 달리, 접근성과 간편함을 무기로 내세운 전략
적 차별화를 해야한다.

※ 마케팅 전략

· 우리 게임의 주요 장점인 인터넷 없이 친구와 바로 멀티플레이가 가능한 점을 강조하여, SNS(인스타그램, 트위터, 틱톡)에서 짧은 영상 콘텐츠(릴스/쇼츠) 형태로 홍보한다.

· 대학교 커뮤니티(에브리타임), 게임 중심 커뮤니티(인벤, 스팀 등)에 게임 소개글과 체험판 플
레이 링크를 공유하여 타깃 유저층에게 자연스럽게 노출시킨다.

· “지금 바로 친구와 플레이 가능”이라는 메시지를 중심으로, 무과금-무가입-즉시 멀티를 강조
한 광고 문구를 제작한다.

· 타겟층인 10-20대 남성 유저들이 밀집된 지역(예: 대학가, 기숙사, 고등학교 주변) 중심으로
소규모 오프라인 체험 행사 또는 포스터 마케팅도 고려해볼 수 있다.

· 출시 이후에는 앱 스토어 최적화(ASO)를 적용하여 "로컬 멀티", "친구와 하는 슈팅 게임" 등
의 키워드로 검색 노출을 유도한다.

※ 수익 구조

· 초기부터 유료로 판매되는 게임으로, 한 번의 구매를 통해 모든 기본 콘텐츠를 이용할 수 있
다.

· 출시 이후에는 스킨, UI 테마, 총기 이펙트 등 커스터마이징 요소를 추가 업데이트하고, 이를
유료 인앱 상품으로 제공하여 부가적인 수익을 창출할 계획이다.

===개발과제의 기대효과===
====기술적 기대효과====
◇ 사용자는 별도의 로그인이나 인터넷 접속 없이, Wi-Fi Direct 기반의 빠른 멀티플레이 환경
을 통해 즉시 게임에 참여할 수 있어 진입 장벽이 낮고, 접근성이 높다.

◇ 절차적으로 생성되는 맵과 자원 배치, 장애물 구조를 통해 매 판마다 새로운 전략적 경험을
제공하며, 플레이어는 매번 다른 전장을 탐색하고 대응해야 하는 몰입감을 느낄 수 있다.

◇ 수집한 자원을 기반으로 랜덤한 무기 성능이 부여되는 시스템은 예측 불가능성과 리플레이
가치를 높이며, 유저의 전략적 선택을 유도한다.

◇ UI는 모바일 터치 기반의 직관적인 조작 시스템으로 설계되어 누구나 쉽게 컨트롤할 수 있
으며, 다양한 디바이스 해상도에 대응하는 크로스 플랫폼 UI 시스템으로 구현된다.

====경제적, 사회적 기대 및 파급효과====
◇ 서버를 필요로 하지 않는 P2P 멀티플레이 구조를 통해 인디 개발팀도 낮은 인프라 비용으로
멀티플레이 게임을 개발할 수 있어 개발·유지 비용을 절감할 수 있다.

◇ 기존의 데이터 기반 매치메이킹 구조 대신, 근거리 통신을 활용함으로써 온라인 매칭 없이
도 현장 중심의 이새로운 사용자 경험을 제공할 수 있다.

◇ 고정된 콘텐츠 소비에서 벗어나, 매번 달라지는 전장 구성과 무기 조합을 통해 플레이어는
반복 플레이에도 피로감 없이 지속적인 몰입과 플레이를 유도할 수 있다.

◇ Wi-Fi Direct 환경 기반의 실시간 협동 게임은 네트워크가 제한적인 지역이나 네트워크 비용
이 부담스러운 사용자에게도 적합해, 더 폭넓은 사용자층을 확보할 수 있다.

◇ 절차적 콘텐츠 구성 방식은 개발자가 수작업으로 맵을 디자인하지 않아도 되기 때문에, 콘
텐츠 생산 비용을 절감하고 라이프 사이클이 긴 게임 구조를 구축할 수 있다.

===기술개발 일정 및 추진체계===
====개발 일정====
[[파일:devSchedule.png]]

====구성원 및 추진체계====
※ 구성원

◇ 한규만: 팀장, UI/UX 시스템 구현 및 인벤토리·HUD·로비 UI 개발

◇ 정진원: 절차적 맵 생성 알고리즘, 자원 및 지형지물 배치 시스템 개발

◇ 박하빈: 게임 라운드 시스템 및 서버 연동, RPC 및 클라이언트 동기화 처리

◇ 임정현: 플레이어 입력 및 전투 조작 시스템 구현, 무기 사용 및 피격 처리 담당

※ 추진 체계

◇ 매주 수요일 정기 회의를 통해 진행 상황을 공유하며, 회의록은 한규만(팀장)이 작성한다.

◇ 회의는 모든 팀원이 참여하는 것을 원칙으로 하며, 주요 결정사항은 회의록에 기록하여 투
명하게 공유한다.

◇ 전체 개발 일정은 상단에 기술된 월별 목표를 기준으로 진행하며, 일정 내 기능 구현을 우
선하고 이후 테스트 및 밸런싱에 집중한다.

◇ 1주일 단위 스프린트를 기준으로 개발 목표를 설정하고, 애자일(Agile) 프로세스에 따라 유연
하게 계획을 점검하고 조정한다.

◇ GitHub를 통해 형상 관리를 수행하며, 모든 기능은 Pull Request(PR) 단위로 리뷰 및 반영한
다.

◇ 메시지 컨벤션

기본 형식: 분류:제목

필요 시 본문은 한 줄 띄운 뒤 작성

분류 예시: 문서추가, 기능구현, 코드삭제

◇ 코딩 컨벤션

Epic Games에서 권장하는 Unreal Engine C++ 코딩 표준을 따름

◇ 에셋 네이밍 컨벤션

애셋 이름은 Unreal Engine의 권장 네이밍 규칙을 따르며, 접두어를 통해 애셋 종류를 명확하게 구분함.

예시: SM_, BP_, FX_, UI_, MAT_

==설계==
===설계사양===
====제품의 요구사항====
{| class="wikitable"
|-
! 번호
! 요구사항
! D or W
! 비고(중요도)
|-
| 1
| Wi-Fi Direct 기반의 로컬 멀티플레이 연결이 가능해야 한다.
| D
| 대
|-
| 2
| 절차적 방식으로 맵과 자원이 배치 되어야 한다
| D
| 대
|-
| 3
| 자원을 채집하고 조합하여 무기를 제작할 수 있어야 한다.
| D
| 대
|-
| 4
| 자원 조합 결과에 따라 무기의 성능이 다양하게 변화해야 한다.
| W
| 중
|-
| 5
| 플레이어 간 전투가 가능하고, 공격, 피격, 사망 등의 상태 처리가 가능해야 한다.
| D
| 대
|-
| 6
| 모바일 환경에 최적화된 조작 UI/UX 구성을 지원해야 한다.
| D
| 대
|-
| 7
| 플레이어 상태를 화면에 표시하는 UI를 지원해야 한다.
| D
| 중
|-
| 8
| 라운드 방식의 게임 진행과 승리 조건 처리가 가능해야 한다.
| D
| 대
|-
| 9
| 게임 밸런스를 조절하여 원활한 게임 환경을 제공해야한다.
| W
| 소
|}
===개념설계안===
'''1. 순서도'''
'''MainMenu 레벨 순서도''' 
[[파일:Shooting_star_flowchart_main.png]]
* 본 순서도는 Wi-Fi Direct 기반 멀티플레이 시스템의 초기 접속 및 매치메이킹 과정을 나타낸다. 게임은 MainMenu 상태에서 시작되며, 플레이어는 다음과 같은 세 가지 선택지를 가진다.
* Join Game
** Create Game
** Search Nearby Players
* Join Game을 선택할 경우, 플레이어는 특정 Tag를 입력하게 된다.
* Tag를 입력한 후, 해당 태그가 존재하는지를 검사하는 조건문(Does Tag Exist?)을 통과하게 된다.
** 입력한 태그가 존재할 경우 Lobby Level로 이동하게 되며, 존재하지 않는 경우 다시 Enter Tag 입력 상태로 돌아가게 된다.
* Create Game을 선택한 경우, 즉시 Lobby Level로 이동하여 새로운 게임 방을 생성하게 된다.
* Search Nearby Players를 선택하면, Wi-Fi Direct 기능을 통해 주변 플레이어를 검색하는 단계인 WifiDirectDiscover Level로 이동하게 된다.

'''Lobby 레벨 순서도''' 
[[파일:Shooting star flowchart lobby.png]]
* 본 순서도는 로비에서 플레이어가 선택 가능한 행동들과, 2v2 게임 시작 조건을 포함한 진행 흐름을 나타낸다.
* 게임은 Lobby 상태에서 시작되며, 플레이어는 다음 네 가지 선택지 중 하나를 고를 수 있다.
** Start Game
** Blue Team
** Red Team
** Exit
* Blue Team 버튼을 선택하면 플레이어는 Blue Team Section으로 이동하게 된다.
* Red Team 버튼을 선택하면 플레이어는 Red Team Section으로 이동하게 된다.
* Exit을 선택할 경우, 현재 로비를 떠나 MainMenu Level로 복귀하게 된다.
* Start Game 버튼을 선택하면, 현재 로비에 있는 플레이어들이 2대2(2v2) 매치를 시작할 준비가 되었는지를 확인하는 조건 분기(Are 2v2 Players Ready?)로 이동하게 된다.
* 조건이 충족되지 않은 경우에는 다시 로비 상태로 복귀한다.
* 조건이 충족된 경우, 즉 2v2 구성이 완료된 경우에는 Competitive Level로 전환되며 본격적인 게임이 시작된다.

'''Wifi Direct 레벨 순서도''' 
[[파일:Shooting star state diagram wifidirect.png]]
* 본 순서도는 Wifi Direct 기반 P2P 통신을 활용하여 플레이어들이 그룹을 생성하고, 로비로 진입하기까지의 흐름을 나타낸다.
* 시작 상태는 WifiDirectDiscover 레벨이며, 플레이어는 두 가지 선택지를 가질 수 있다.
** Connect Device
** Exit
* Connect Device를 선택할 경우, 주변 디바이스와의 Wifi Direct 연결을 시도하게 된다.
* 연결이 완료되면, 자동으로 Create Group 단계로 진입하여 Wifi Direct 그룹을 구성한다.
* 그룹이 생성된 이후에는 Assign Host 단계를 통해 해당 그룹 내에서 호스트(Host) 역할을 수행할 디바이스가 자동으로 지정된다.
* 호스트 할당이 완료되면, 모든 플레이어가 Lobby Level로 이동하게 되어 본격적인 로비 대기 상태로 진입한다.
* 반면, 플레이어가 Exit을 선택한 경우에는 Wifi Direct 연결을 시도하지 않고 바로 MainMenu Level로 복귀하게 된다.

'''2. 스테이트 다이어그램'''
'''라운드 흐름 스테이트 다이어그램''' 
[[파일: Shooting star state diagram round.png]]
* 본 다이어그램은 게임의 라운드 진행 방식 및 승리 조건을 상태(State) 기반으로 표현한 상태 전이 다이어그램이다.
* 게임은 RoundStart 상태에서 시작되며, 이 상태는 각 라운드의 시작을 나타낸다.
* RoundStart 이후에는 Playing Round 상태로 진입하며, 각 라운드는 고정된 시간(3분) 동안 진행된다. 3분이 경과하면 Check Kill Count 상태로 진입하여, 양 팀의 킬 수를 비교하여 승패 또는 연장 여부를 판단한다.
* 킬 수가 다른 경우에는 일반적인 승리 조건으로 간주되며, Check Winner 상태로 전이된다.
* 킬 수가 동일한 경우, 즉 무승부일 경우에는 Death Match 상태로 진입한다.
* Death Match 상태에서는 한 팀이 전멸할 때까지 전투가 계속되며, 승자가 결정되면 Check Winner 상태로 이동한다.
* Check Winner 상태에서는 승리한 팀의 라운드 수를 확인하며, 특정 팀이 3라운드를 승리하지 못한 경우, 다시 RoundStart 상태로 돌아가 다음 라운드를 시작한다.
* 반대로, 3라운드를 먼저 승리한 팀이 존재할 경우, 게임은 End Game 상태로 전이되며 최종 승부가 결정된다.
* 전체적으로 이 상태 전이 다이어그램은 라운드 중심 구조와 데스매치 조건을 모두 포괄하여, 게임 진행 로직의 핵심 흐름을 나타낸다.

'''Wi-Fi Direct 멀티플레이어 스테이트 다이어그램''' 
[[파일:Shooting star state diagram wifidirect.png]]
* 위 다이어그램은 초기 상태부터 피어 검색 및 연결, 그룹 형성 과정과 상태 전이를 나타낸 스테이트 다이어그램이다.
* 우선 최초로 게임을 실행하면 Clear 상태로, 이 상태에서는 어떠한 WiFi Direct 관련 작업이 진행되지 않으며 상태 진입시 진행 중이던 WiFi Direct 작업이 있다면 즉시 중지한다.
** 이 상태는 플레이어가 메인 메뉴에 있는 경우 유지된다.
* Clear상태에서 게임 검색을 요청하면 BroadcastAndDiscovering 상태로 전이하며, 주변 ShootingStar 앱을 주기적으로 검색하고 자신의 기기도 광고한다.
** 필요 권한이 부여되지 않은 경우, 지원되지 않는 OS 버전이거나 기기인 경우 Clear 상태로 전이한다.
** 정상적인 상황에서도 플레이어가 메인 화면으로 이동하는 등 검색을 취소하면 Clear 상태로 전이한다.
** 오류가 발생하거나 플레이어의 추가적인 요청이 없는 경우 해당 상태를 계속 유지한다.
* BroadcastAndDiscovering 상태에서 검색된 다른 피어에 대해 연결을 요청하면 Connecting 상태로 전이한다.
** 검색된 피어가 더 이상 유효하지 않게 되어 연결에 실패했다면 다시 BroadcastAndDiscovering 상태로 전이한다.
* Connecting 상태에서 성공했거나, BroadcastAndDiscovering 상태에서 다른 피어가 먼저 해당 기기로 연결한 경우 GroupFormed 상태로 전이한다.
** 최근 P2P 연결하지 않은 기기라면 GroupFormed로 전이하기 전에 안드로이드 OS가 추가적인 연결 수락 여부를 묻는 팝업을 띄울 수 있다.
** GroupFormed 상태 진입시 WiFi Direct 표준에 의해 호스트가 정해지며, 멀티플레이가 가능하다.
* GroupFormed 상태에서 세션을 종료하면 Clear 상태로 전이한다. 만약 호스트가 세션을 종료했다면 모든 클라이언트가 Clear 상태로 전이한다.

'''플레이어 상태 스테이트 다이어그램''' 
[[파일:Shooting star state diagram player.png]]
* 최초 스폰 시 비무장 상태로 스폰
* 비무장 상태에서도 공격 가능
* 플레이어는 채집을 통해 아이템 획득
* 이후 검이나 총을 장착한 상태로 변경
* 해당 상태에서 공격을 통해 전투
* 플레이어의 체력이 0 이하가 될 경우 사망 판정
* 게임이 끝나지 않았다면 사망한 후 리스폰

'''3. 시퀀스 다이어그램'''
'''전투처리흐름 시퀀스 다이어그램''' 
[[파일:Shooting star sequence diagram battle.png]]
* 플레이어가 총을 가지고 있을 시 Attack 함수에서 weapone 클래스에 ProjectileFire함수를 요청
* Weapon은 발사체를 발사 한 뒤 발사체에서 OnComponentBeginOverlap함수를 사용하여 충돌 감지
* 충돌이 감지될 경우 ApplyDamage함수를 통해 적에게 데미지 요청
* 적은 TakeDamage 함수를 통해 자신에게 데미지 적용
* 플레이어가 총을 가지고 있지 않을 시 Attack 함수에서 Weapon 클래스에 바로 OnComponentBeginOverlap 함수를 요청
* 무기에 충돌이 감지될 시 ApplyDamage 함수를 통해 적에게 데미지 요청
* 적은 TakeDamage 함수를 통해 데미지 적용

'''Wi-Fi Direct 모듈 시퀀스 다이어그램''' 
[[파일:Shooting star sequence diagram wifidirect.png]]
* 위 다이어그램은 WiFi Direct의 모듈 동작 방식을, 유저가 다른 기기에 대해 Connect()를 요청하고 성공 결과를 받는 과정을 예로 들어 설명한 시퀀스 다이어그램이다.
* 최초로 유저가 언리얼 엔진의 클래스 형태로 구현된 UWifiDirectInterface의 Connect()를 호출한다.
* Connect()에서는 Java로 제공되는 안드로이드의 API를 호출하기 위해, C언어 라이브러리 형식으로 제공되는 Java Native Interface의 메소드 검색 함수와 호출 함수를 호출한다.
* gameActivity에 정의된 connect() 함수가 호출되어, 안드로이드의 WiFi Direct API가 호출된다. 해당 API는 비동기 함수이므로, 콜백 함수를 등록하고 즉시 반환된다.
* 연결이 성공하면Java의 native 키워드로 선언해 놓은 함수가 호출된다. 이 함수는 C언어 규격으로 정의해 놓은 JNI 함수와 링크되어 있다.
* JNI 함수가 콜백에서 발생한 Java 형식 인자들을 C++와 언리얼 엔진 제공 타입으로 변환한 후, UWifiDirectInterface의 OnConnected() 콜백을 호출한다.
* 최종적으로 유저는 UWifiDirectInterface로부터 OnConnected()를 통해 연결 성공을 확인한다.

===상세설계 내용===
'''전체 게임 세션''' 
[[파일: Shooting star class diagram entire.png]]
* 본 클래스 다이어그램은 하나의 게임 세션을 구성하는 클래스들을 나타낸 다이어그램이다.
* ACompetitiveGameMode와 그것을 구성하는 컴포넌트들은 플레이어 연결 상태 관리, 게임의 시작과 종료, 맵과 오브젝트의 생성, 점수 관리와 같은 공통 게임 로직을 담당하며, UServerComponent로부터 전달받은 클라이언트의 RPC 호출의 실제 판정 및 동작을 담당한다.
** 이 클래스들의 인스턴스들은 원본 컴퓨터, 즉 서버 역할을 진행하는 플레이어에게만 존재하며, 자동으로 게임의 상태를 동기화하는 ACompetitiveGameState 클래스를 제외하면 이 클래스들에 의존하는 클래스는 오직 UServerComponent만이 존재함을 알 수 있다.
* 개별 플레이어들의 상태 관리와 동작은 ACompetitivePlayerController와 그것을 구성하는 클래스들이 담당한다. 이들은 입력 처리, 게임 상태값 UI 출력, RPC를 이용한 송수신과 같은 입출력을 구현하며, 인벤토리 등의 플레이어별 상태값 관리도 담당한다.
* ACompetitivePlayerController를 비롯한 클래스들이 논리적인 로직을 구성한다면, ACompetitiveCharacter와 구성 클래스들은 개별 플레이어의 물리적인 로직을 구성한다고 할 수 있다.
** ACompetitiveCharacter는 플레이어의 입력을 받아 캐릭터를 이동시키는 동작을 담당하며, 공격이나 자원 채집 등의 액션 입력이 발생하였을 때 실제 판정을 위한 대상으로서의 역할도 담당한다.
** 특히 공격 판정의 경우, 캐릭터의 위치와 더불어 부착된 UTeamComponent의 팀 값을 참조하여 진행하게 된다.
* 이외에도 별도로 분리된 무기 시스템 클래스들을 확인할 수 있다. 무기들의 공통 인터페이스 IWeaponBase와 이것을 구현하는 슈퍼클래스 AGunBase, AKnifeBase가 정의되어 있으며, 각각은 원거리 무기와 근접 무기 클래스들의 기반 클래스이다.
** 다이어그램에서 UInventoryComponent가 다수의 무기 시스템 클래스에 의존하는 대신 UWeaponFactory에만 단일 의존 관계를 가지는 구조로, 잦은 확장과 변동이 발생할 수 있는 무기 시스템에 대한 외부 의존성이 최소화되었음을 명확히 확인할 수 있다.

'''절차적생성 컴포넌트 다이어그램''' 
[[파일:Shooting star component procedural.png]]
* 위 컴포넌트도는 본 프로젝트에서 구현 중인 절차적 맵 생성 시스템의 대략적인 구성 요소와 이들간의 상호작용을 시각적으로 나타낸다. 해당 시스템은 ProceduralMapGenerator, ObstacleGenerator, SubObstacleGenerator, FenceGenerator, Resource Generator, DecorationGenerator, Pattern Generator로 구성된다.
* Procedural Map Generator 컴포넌트는 Competitive 씬 진입시 맵 속성을 초기화하고 다른 주요 컴포넌트들을 호출하여 절차적 생성을 시작한다. 우선 Obstacle Generator를 호출하여 가장 크기가 큰 Static Mesh Actor들을 생성한다.
* 다음으로 SubObstacleGenerator, FenceGenerator, Resource Generator, DecorationGenerator를 순차적으로 호출하여 각각 상대적으로 크기가 작은 장애물, 울타리, 플레이어와 상호작용(채굴)가능한 자원들, 맵에 시각적 효과를 추가해주기 위한 데코레이션 액터들을 생성한다. 각 과정에서 생성된 Static Mesh Actor들의 정보는 동일한 좌표 배열 상에서 관리되어 적절한 거리를 유지하도록 하여 부자연스러운 배치를 방지한다.
* Fence Generator 컴포넌트는 울타리의 생성,Decoration Generator컴포넌트는 꽃, 풀, 덤불 등 장식물들의 생성을 담당한다. 이러한 액터들의 생성은 독립적으로 한 번 수행되는 것이 아닌. 일정한 모양이나 군집을 형성하도록 생성해야 한다. 따라서 특정 패턴의 생성 작업을 Pattern Generator에 위임하여 특정 액터의 반복적인 생성을 효과적으로 처리할 수 있도록 한다.
* 최종적으로, 각Static Mesh는 Competitive 씬에서 개별적인 Static Mesh Actor로 생성되어 배치된다.해당 과정을 통해 매판마다 플레이어들이 새로운 구조의 맵에서 게임을 진행하게 됨으로써,반복적이지 않으며 독창적인 플레이어 경험을 창출해낼 수 있게 된다.

'''절차적생성 클래스 다이어그램''' 
[[파일:Shooting star class diagram procedural.png]]
* 본 시스템은 중심 클래스인AProceduralMapGenerator와 생성 책임 분리 클래스, 보조 클래스 등으로 정의된다.
* AProceduralMapGenerator의 BeginPlay() 함수를 통해 Level 진입 시 맵 생성 루프가 시작된다.이 주요 클래스에서는 생성 책임을 분리한 각 GeneratorClass를 순차적으로 호출하여 맵 생성을 수행하게 된다.객체 위치 충돌 검사(HasObjectAtArray, CheckLocationValid)를 통해 생성 대상 객체의 위치가 유효한지를 판단하며,만약 유효하지 않은 위치값이라면 최근접 유효 위치 탐색 기능(FindNearestValidLocation)을 통해 가장 가까운 유효 위치가 대상 객체가 생성될 수 있도록 하였다.
* 생성 책임 분리 클래스들은 각기 별도의 Generator 클래스로 위임받는다. 각 클래스는 AObstacleGenerator, ASubObstacleGenerator, AFenceGenerator, AResourceGenerator, ADecorationGenerator이며 각각 장애물, 서브장애물, 울타리, 자원, 장식물 등의 실제 생성 작업을 담당한다. 이 클래스들은 모두 별도의 Static Mesh 리스트, 생성 객체의 수량및 최소 간격을 속성으로 포함한다. 특히 AFenceGenerator, ADecorationGenerator와 같이 동일한 Static Mesh의 재귀적 생성이 포함될 수 있는 클래스들의 경우 GPU의 부담을 줄일 수 있도록 엔진에서 제공해주는 Instanced Static Mesh Component 기능을 활용하였다. 동일한 Mesh 에셋을 사용하는 각 액터들을 개별적으로 렌더링하는 것이 아닌,개별적인 위치값만을 저장하여 드로우콜을 효과적으로 줄일 수 있었다.
* APatternGenerator 클래스는 특정 패턴 배치를 전담한다. 재귀적인 생성이 필요한 객체들에 대하여 해당 객체를 생성할 원점을 입력받으면,그 원점을 중심으로 미리 정의된 패턴(사각형, U자 모양, L자 모양 등)을 3차원 벡터 배열의 형태로 반환해준다.
* 열거형 EPatternType, EObjectMask는 공통 자료구조로써 각각 패턴의 종류 정의, 객체 타입 식별 및 필터링에 활용된다.
* 위와 같은 클래스 구조로 정의함으로써, 확장성과 유지보수성을 높이고자 하였다. 새로운 Generator 클래스를 추가하거나 새로운 패턴을 정의하는 등의 확장을 고려하였고, 위치 검증, 마스크 필터링, 최근접 위치 탐색 로직 등의 주요 로직은 중앙에서 일괄적으로 관리할 수 있도록 설계하였다.

'''플레이어 클래스 다이어그램''' 
[[파일:Shooting star class diagram player.png]]
* 플레이어
** 플레이어는 체력과 장착된 무기와 같은 전투에 관련한 데이터를 갖고 있음
** 애니메이션이나 사운드와 같은 컴포넌트들을 보유하며 상황에 따라 재생
** 채집은 주변에 있는 자원 액터를 찾아 채집 애니메이션 재생 후 획득하도록 설계
** 장착하고 있는 무기에 공격을 요청하여 전투하도록 설계
* WeaponBase
** WeaponBase는 데미지 및 메시를 갖을 수 있도록 설계
** 무기가 검인지 총인지를 구별할 수 있도록 구현
** 무기가 플레이어에게 장착될 수 있도록 SpawnToHand와 같은 함수들을 설계
* GunBase
** WeaponBase를 상속받도록 설계되며 사격 시 총구 화염과 같은 Flash가 나타날 수 있도록 언리얼의 UParticleSystem을 이용하여 설계한다.
** ProjectileBase에 총알을 발사하도록 요청할 수 있도록 설게
* ProjectileBase
** ProjectileBase는 GunBase에서 요청 받으면 발사체를 스폰하여 발사
** 해당 발사체는 OnComponentBeginOverlap 함수를 이용하여 충돌을 감지한 후 충돌체가 플레이어일 시 ApplyDamage함수를 이용하여 데미지를 적용
* KnifeBase
** KnifeBase는 WeaponBase를 상속받도록 설계되며 GunBase와 달리 무기 자체에서 충돌체를 감지하여 해당 충돌체가 플레이어일 시 데미지를 적용
** 충돌체 감지 및 데미지 적용은 ProjectileBase와 동일하게 함수를 사용하여 설계

'''인벤토리 동작 순서도''' 
[[파일:Shooting star state flowchart inventory.png]]
* 본 플로우차트는 인벤토리 UI 내에서 플레이어가 자원을 선택하고 무기를 제작하거나, 무기를 장착 및 해제하는 과정 전반을 나타낸다.
* 플레이어가 Inventory Button을 클릭하면 인벤토리 UI가 활성화되며, 다음과 같은 초기 작업이 수행된다.
** Fetch Inventory Data : 플레이어가 보유한 자원 정보를 불러온다.
** Generate Player Resource Slots : 플레이어의 자원 정보를 기반으로 자원 슬롯을 생성한다.
** Sync Equipped Weapon Info : 현재 장착 중인 무기 정보를 동기화한다.
** Display Craftable Weapon List : 제작 가능한 무기 목록을 UI에 표시한다.
* 이후 인벤토리 UI 상태에서는 플레이어의 행동에 따라 다음과 같은 동작들이 수행된다.
** Craft Button : 선택한 자원의 개수를 계산한 후, 요구 자원 수량이 충족되면 무기를 제작 및 장착한다.
** Cancel Button : 장착 상태가 아닐 경우 선택 자원을 초기화하고 장착 상태로 변경한다.
** Click Resource Slot : 자원 선택 시, 요구 자원 미만일 경우 선택 자원을 추가한다.
** Click Weapon Slot : 선택한 무기가 현재 선택된 무기와 동일하지 않다면, 선택 자원을 초기화하고, 무기 선택 처리 및 필요한 자원을 다시 선택하게 한다.
** Exit Button : 장착 상태 여부에 따라 선택 자원을 초기화 후 인벤토리 UI를 바로 받는다.

'''인벤토리 유저 인터페이스 클래스도''' 
[[파일:Shooting star class diagram inventory.png]]
* BP_Inventory : 인벤토리 UI의 핵심 클래스이며, 플레이어가 보유한 자원을 표시하고, 무기를 제작하거나 장착하는 기능을 담당한다.
* BP_ResourceSlot : 자원 슬롯 UI 클래스이며, 개별 자원 정보를 표시하고 선택 시 BP_Inventory에 선택 정보를 전달한다.
* BP_WeaponSlot : 무기 슬롯 UI 클래스이며, 제작 가능한 무기 정보를 표시하고 무기 선택 시 BP_Inventory에 선택 정보를 전달한다.

===평가 기준===
* 게임 시스템이 요구사항에 맞게 명확하게 구현되었는가?
* 사용자(플레이어)의 관점에서 기능 이용이 직관적이고 자연스러운가?
* 각 기능 및 시스템이 정상적으로 동작하며, 게임 진행에 문제가 없는가?
* 구현된 기능이 기획 의도에 부합하고, 게임 내에서 효과적으로 활용되는가?
* 다양한 상황 및 환경(멀티플레이, 전투, 자원 수집 등)에서도 안정성과 일관성이 유지되는가?
* 수집된 데이터가 게임 밸런스 조정이나 플레이 분석에 활용 가능한 형태로 제공되는가?

===평가 내용===
* Wi-Fi Direct를 이용해 별도의 로그인이나 서버 접속 없이 주변 사용자가 멀티플레이에 참여할 수 있는가?
* 플레이어가 게임 방을 생성하고, 주변 사용자가 해당 방에 정상적으로 접속 및 참가할 수 있는가?
* 게임 시작 시, 맵과 자원이 절차적으로 랜덤 생성되어 새로운 플레이 환경이 제공되는가?
* 플레이어가 맵 내 자원을 채집하고, 자원 획득 시 정상적으로 인벤토리에 추가되는가?
* 플레이어가 수집한 자원을 이용해 무기를 제작할 수 있으며, 조합된 자원에 따라 무기의 성능이 변화하는가?
* 플레이어가 다른 플레이어와 전투를 수행할 수 있으며, 공격, 피격, 사망 등의 전투 로직이 정상적으로 동작하는가?
* 플레이가 진행되는 동안 라운드 시스템이 정상적으로 동작하며, 승리 및 패배 조건 충족 시 게임 결과가 처리되는가?
* 플레이어의 상태 정보(HP, 무기 상태 등)가 HUD를 통해 정상적으로 표시되는가?
* 게임 플레이 로그 수집 및 자원/무기 관련 밸런스 데이터 확인이 가능하며, 이를 통해 게임 내 데이터 분석이 가능한가?

==결과 및 평가==
===완료 작품의 소개===
====프로토타입 사진 혹은 작동 장면====
'''가. 프로토타입 사진''' 
MainMenu Level 
[[파일:MainMenu.png]] 
IP 주소로 직접 플레이 팝업 
[[파일:IPaddress.png]] 
우측 상단 도움말 버튼 팝업 
[[파일:Guidepopup.png]] 
Lobby Level 
[[파일:LobbyLevel.png]] 
닉네임 변경 버튼 팝업 
[[파일:NicknameChange.png]] 
Wifi Direct Discover Level 
[[파일:WifiDirectLevel.png]] 
절차적 맵 생성 
[[파일:MapGenerate.png]] 
플레이어 모바일 조작 
[[파일:MobileController.png]] 
자원 채집 1단계, 2단계, 3단계 - 돌 
[[파일:Stone1lv.png]][[파일:Stone2lv.png]][[파일:Stone3lv.png]] 
스코어 보드 UI 
[[파일:ScoreBoard.png]] 
인벤토리 UI 
[[파일:Inventory.png]] 
킬로그 UI 
[[파일:KillLog.png]] 
게임 상태 표시 UI - 전투 시작 
[[파일:GameState.png]] 
게임 상태 표시 UI - Round 승리 
[[파일:RoundWin.png]] 
게임 상태 표시 UI - Game 패배/승리 
[[파일:GameDefeat.png]][[파일:GameVictory.png]] 
플레이어 무기 - 칼, 라이플, 샷건 
[[파일:Knife.png]][[파일:Rifle.png]][[파일:Shotgun.png]] 
보급 시스템 - 보급의 위치를 나타내는 UI (현재 상태로는 우하단 보물상자) 
[[파일:Supplyindicator.png]] 
보급 시스템 - 보물 상자, 로켓런처 획득 
[[파일:Supplybox.png]][[파일:Rocketlauncher.png]] 
장애물 반투명화 
[[파일:Obstacle.png]] 
자기장 
[[파일:Magneticfield.png]] 
부쉬 은신 
[[파일:Hidebush1.png]] 
[[파일:Hidebush2.png]] 
무기 재료별 VFX 효과 - 나무, 돌, 철, 우라늄 
[[파일:WoodVFX.png]][[파일:StoneVFX.png]] 
[[파일:IronVFX.png]][[파일:UraniumVFX.png]] 

====트레일러 및 설치 방법====
◇ itch.io 
https://ripepixel.itch.io/shootingstar 

위 링크 접속 후, Download Now 버튼 클릭, zip 파일 다운로드 후 실행. 
[[파일:슈팅스타 트레일러.png]] 

===관련사업비 내역서===
{| class="wikitable"
! rowspan="2" | 구분
! rowspan="2" | 항목 (품명, 규격)
! rowspan="2" | 수량
! rowspan="2" | 단가
! colspan="2" | 금액(단위: 천원)
! rowspan="2" | 비고
|-
! 계
! 현금
|-
| rowspan="12" | 직접개발비
| Location 2 Western - Low Poly 3D Models Pack || 1 || 14.5 || 14.5 || 14.5 ||
|-
| Toon Soldiers || 1 || 40.3 || 40.3 || 40.3 ||
|-
| Lowpoly Mine Assets || 1 || 96.9 || 96.9 || 96.9 ||
|-
| C++ 소프트웨어 디자인 || 1 || 28.8 || 28.8 || 28.8 ||
|-
| Effective Modern C++ || 2 || 25.2 || 50.4 || 50.4 ||
|-
| 게임 서버 프로그래밍 교과서 || 1 || 31.5 || 31.5 || 31.5 ||
|-
| 게임 프로그래밍 패턴 || 2 || 31.5 || 63.0 || 63.0 ||
|-
| 아무도 알려주지 않은 C++ 코딩의 기술 || 2 || 27.0 || 54.0 || 54.0 ||
|-
| 언리얼 엔진 5로 개발하는 멀티플레이어 게임 || 1 || 38.0 || 38.0 || 38.0 ||
|-
| 유니티로 배우는 AI 프로그래밍 콕북 2/e || 1 || 29.7 || 29.7 || 29.7 ||
|-
| 이득우의 언리얼 C++ 게임 개발의 정석 || 2 || 47.0 || 94.0 || 94.0 ||
|-
| 합계 || || || 541.1 || ||
|}

===완료작품의 평가===
{| class="wikitable"
! 평가 항목
! 평가방법
! 적용기준
! 개발 목표치
! 비중 (%)
! 평가결과
|-
| 1. 로컬 멀티플레이어 연결
| 애플리케이션 시연
| Wi-Fi Direct 연결 성공 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 2. 절차적 맵 생성
| 애플리케이션 시연
| 맵 생성 성공 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 3. 자원 채집 기능
| 애플리케이션 시연
| 자원 수집 성공 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 4. 무기 제작 시스템
| 애플리케이션 시연
| 제작에 따른 무기 생성 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 5. 무기 성능 다양화
| 애플리케이션 시연
| 무기별 성능 차이 구현 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 6. 유저간 상호작용
| 애플리케이션 시연
| 유저간 충돌 및 상호작용 구현 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 7. 플레이어간 전투 시스템 구현
| 애플리케이션 시연
| 타격 동작 여부 및 사망 로직 구현 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 8. 라운드 및 승리 조건 처리
| 애플리케이션 시연
| 라운드 종료 및 승리팀 판단 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 9. UI/UX 구성
| 애플리케이션 시연
| 아이템창, 자원 현황 여부
| 완전 구현
| 10%
| 구현 완료
|-
| 10. 팀 플레이 및 밸런스 조정
| 애플리케이션 시연
| 내부 시뮬에 의한 승률 분석
| 완전 구현
| 10%
| 구현 완료
|}

===향후계획===
'''가. 어려웠던 내용들''' 
◇ Wi-Fi Direct 기반 멀티플레이 연결 시 기기 간 호환성 문제로 안정적인 세션 유지 
◇ 절차적 맵 생성 알고리즘에서 맵의 연결성과 균형을 동시에 확보하는 데 시간 소요 
◇ 전투 시스템에서 공격 판정과 피격 판정 간의 동기화 오류 발생 및 반복 디버깅 
◇ 다양한 해상도/화면비율을 지원하는 UI 배치 및 스케일 조정 
◇ 자원 수집 → 무기 제작 → 전투 흐름을 자연스럽게 연결하는 UX 구성에 반복적인 수정 
◇ 테스트 단계에서 예상치 못한 버그가 다수 발견되어 디버깅 및 코드 리팩터링에 어려움을 겪음 
 
'''나. 차후 구현할 내용''' 
◇ 싱글플레이 전용 PvE 콘텐츠 강화
→ 혼자서도 충분히 몰입 가능한 웨이브 방어 모드, 보스 사냥 모드 등을 설계
→ 플레이어 실력을 기반으로 적 난이도 자동 조절 (Dynamic Difficulty Adjustment)

◇ 로컬 멀티플레이 전용 PvE 협동 모드 추가
→ Vampire Survivors 스타일의 쏟아지는 적을 함께 막는 생존형 모드 구현
→ 무기 시너지 조합 및 역할 분담 (ex. 범위 공격 / 회복 / 방어 등) 도입

◇ 게임 모드 확장: 아케이드/스토리/챌린지 모드 분기 구현
→ 기본 루프 외에 짧고 명확한 목표가 있는 미션 기반 싱글/멀티 모드 도입
→ 적 AI와 환경이 유기적으로 변화하는 미션형 구조

===참고문헌 및 참고사이트===
한국콘텐츠진흥원 2024 게임 이용자 실태 
https://www.kocca.kr/kocca/bbs/view/B0000147/2007554.do?menuNo=204153 
[HOW TO 마케팅] 모바일 게임 비즈니스, 핵심은 ‘광고 수익 다각화’, 디지털 인사이트, 
https://ditoday.com/how-to-%EB%A7%88%EC%BC%80%ED%8C%85-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EA%B2%8C%EC%9E%84-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%ED%95%B5%EC%8B%AC%EC%9D%80-%EA%B4%91%EA%B3%A0-%EC%88%98%EC%9D%B5/
Unreal Engine Documenation, 
https://dev.epicgames.com/documentation/en-us/unreal-engine/using-ad-mob-for-in-game-ads-on-android-with-unreal-engine 
https://docs.unrealengine.com/en-US/ProgrammingAndScripting/GameFramework/index.html 
https://docs.unrealengine.com/en-US/InteractiveExperiences/Networking/index.html 
Appodeal’s internal eCPM performance data from January 2020, 
https://wafour.tistory.com/entry/%EB%AA%A8%EB%B0%94%EC%9D%BC-%EA%B4%91%EA%B3%A0-%ED%98%95%ED%83%9C%EC%97%90-%EB%94%B0%EB%A5%B8-%EA%B5%AD%EA%B0%80%EB%B3%84-%ED%8F%89%EA%B7%A0-eCPM 
오퍼월에 대한 4가지 오해와 진실, Unity Blog, 
https://unity.com/kr/blog/4-offerwall-myths-debunked 
Android Developers – Wi-Fi Direct (P2P) Overview 
https://developer.android.com/guide/topics/connectivity/wifip2p

1분반-Ludex

2026-03-11T07:34:33Z

Adcdc: Adcdc (토론)의 12610판 편집을 되돌림

<div>__TOC__</div>

==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 : ''' Ludex - 게임 개발자, 판매자, 구매자 모두를 위한 ESD

''' 영문 : ''' Ludex - A Unified Digital Distribution Platform for Game Developers, Publishers, and Players

===과제 팀명===
Ludex

===지도교수===
이동희 교수님

===개발기간===
2025년 3월 ~ 2025년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 컴퓨터과학부 20149200** 임*우(팀장)

서울시립대학교 컴퓨터과학부 20199200** 김*호

서울시립대학교 컴퓨터과학부 20179200** 서*영

서울시립대학교 컴퓨터과학부 20229200** 이*진

==서론==
===개발 과제의 개요===
====개발 과제 요약====
◇ 인디게임 개발자들을 위한 ESD(Electronic Software Distribution) 플랫폼
◇ 하나의 게임 컨텐츠로부터 여러 파생 게임 컨텐츠를 만들어가는 플랫폼
◇ 스테이블 코인 스마트 컨트랙트를 사용한 개발자 간 수익 분배 기능을 제공
◇ NFT 스마트 컨트랙트를 사용한 게임 정품 구매 인증 기능 제공, 다운로드권 보장
◇ 하나의 IP에 대한 할인 전략을 제공하여 IP를 공유하는 게임들 사이의 수익 증대 제공
====개발 과제의 배경====
◇ 게임 개발 리소스 관련 통합 플랫폼의 부재 해결
게임 개발 관련 에셋을 판매하는 플랫폼은 유니티 에셋 스토어, itch.io 등 현재 많은 상태이다. 또한 게임 유통을 하는 플랫폼도 존재하지만, 이를 통합한 플랫폼이 존재하지 않는다. 이 두가지 목적을 달성할 수 있는 플랫폼은 원작 게임의 개발 리소스를 구매해 만든 파생 게임과 관련되어 여러 긍정적인 기대 효과가 존재한다.

◇ 게임 리소스 공유 허들을 낮춰 게임 개발 시장 활성화
이 플랫폼에선 코드 블록부터 시작해서 에셋, 기획서, 콘텐츠 흐름도, 코드 관리법, 게임 전체 소스 등 게임 개발과 관련된 모든 것들이 판매 및 공유가 가능하다. 낮은 품질의 리소스라도 개발자간 공유가 활발해지며 게임 제작의 접근성이 하락될 것이라 생각된다. 이렇게 만들어진 원작 게임의 파생 게임들을 통해서 하나의 IP가 좋은 퀄리티의 콘텐츠로 성장할 수 있고, 게임을 플레이하는 유저도 파생 게임에 대한 접근성이 좋아져 긍정적인 효과를 얻을 수 있을 것으로 예상된다. 모든 걸 거래 및 공유함으로써 게임의 다양성 및 2차 창작 등 인디 게임 시장의 활성화가 되는 기대 효과 또한 존재한다.

◇ 스마트 컨트랙트를 활용한 신뢰성 있는 로열티 지급
기존의 게임 시장에서는 영세 개발자들 간에 로열티를 지불하는 계약을 맺기가 어려운 상태였다. 본 프로젝트의 플랫폼에서는 게임 개발 리소스를 판매 및 공유할 시 판매자와 구매자간 스마트 컨트랙트를 이용해 계약을 진행한다. 스마트 컨트랙트는 조건이 만족되면 자동으로 대금 지급이 완료되는 변조 불가능한 사이버 계약이므로, 이는 신뢰성 있게 보장되어 계약이 확실히 이행한다는 믿음을 줄 수 있다. 이 때 판매자와 구매자간 서로 협의를 통해 파생 게임의 일부 수익의 로열티를 얼마로 지정할 것인지, 파생 게임 내 원작 게임에 대한 표시를 강제하는지 등 계약 내용을 자유롭게 정할 수 있다. 이 기능을 사용해 영세 개발자라 하더라도 로열티를 지불하는 조건으로 게임 개발 리소스를 공유받아 사용할 수 있어 게임 개발에 대한 접근성을 더욱 낮출 수 있다.

◇ 정품 구매를 인증 가능한 DRM-Free 소프트웨어 유통망
기존 게임 시장에선 불법 복제/크랙 문제에 대해 DRM(Digital Rights Management)기술을 사용하여 정품 구매 이력을 확인을 하곤 하였는데, 이는 코드 입력, 네트워크 연결 등 정품 유저를 불편하게 만드는 요소가 있었다. 이에 대해 DRM 기술을 적용하지 않는 유통망도 있지만, 이는 전적으로 유저의 양심에 의존하는 구조로서 게임을 유통하는 입장에선 악의적인 무단 배포에 대해 부담이 있게 되는 구조이다. 본 프로젝트는 이에 대응하여 게임을 구매한 이력에 대해 NFT를 주조하여 제공함으로써, 오직 구매자 본인만 가질 수 있는 구매 이력 토큰을 통해 유통사가 특정 구매자가 게임을 구매했음을 확인할 수 있는 시스템을 제공하여, DRM-Free 정책을 택하는 시장에서도 정품 구매를 확인할 수 있는 방법을 제공한다.
====개발 과제의 목표 및 내용====
◇ 게임 유통 및 다운로드 시스템 개발
게임 판매자는 자신이 개발한 게임을 플랫폼에 등록해 업로드 및 판매를 할 수 있다. 또한 유저들은 플랫폼을 통해 구매한 게임을 다운로드 할 수 있다.

◇ 게임 리소스 마켓플레이스 구현
Ludex에 게임을 등록한 개발자들은 언제든지 자신의 게임 내 코드, 에셋, 기획서 등을 다른 개발자들에게 로열티를 대가로 판매할 수 있다. 이 리소스 거래는 플랫폼 내 별도의 마켓플레이스를 통해 이루어진다.

◇ 스마트 컨트랙트 기반 계약 관리
게임 리소스 거래 시, 중개자 없이 스마트 컨트랙트를 통해 계약이 자동으로 체결된다. 계약의 내용은 판매자와 구매자 간 합의를 통해 자유롭게 구성하며, 거래 조건 및 권리 분배 등도 함께 명시된다.

◇ IP 기반 파생 게임 허브 기능
플랫폼은 동일한 게임 IP를 기반으로 한 다양한 파생 게임을 유저에게 추천한다. 이를 통해 유저는 하나의 게임을 즐긴 후 해당 IP를 활용한 다른 파생 게임도 쉽게 접할 수 있다. 파생 게임 제작자가 손해를 보지 않는 선에서 한 IP에 일괄 적용 가능한 할인 기능을 제공하여 IP 일반에 대한 접근성을 강화할 수도 있다.

◇ NFT(Non-Fungible Token)를 통한 정품 인증 및 유저 혜택
유저가 게임을 구매할 시 유저의 구매 기록이 담긴 NFT를 발급한다. 이는 유저가 정품 게임을 구매했음을 증명하는 역할을 하며, 유통사는 플랫폼을 거치지 않아도 구매이력을 확인할 수 있다.

◇ FT(Fungible Token)를 통한 플랫폼 내 거래 시스템
플랫폼 내 모든 거래(게임 구매, 게임 리소스 거래)는 FT를 통해 이루어진다. 유저는 실물 화폐로 FT를 구매하여 플랫폼 내에서 사용할 수 있으며, FT는 1USD = 1Token 수준의 스테이블 코인으로 고정된다.

◇ 온라인 결제 시스템 병행 제공
블록체인 사용에 익숙치 않는 유저들을 위해, 토스(Toss), 페이팔(PayPal) 등 일반적인 온라인 결제 수단도 함께 지원한다. 해당 방식으로 구매한 게임의 기록은 플랫폼 내 서버에 저장되며, 이를 유저가 NFT로 소유하고 싶을 경우 언제든지 해당 구매 기록을 바탕으로 한 NFT를 생성해 유저에게 제공한다.

◇ 오프라인 플레이 지원 및 어밴던웨어(Abandonware) 방지
게임 등록 시, 개발자는 DRM-Free 또는 유사한 형태의 오프라인 플레이 지원에 동의해야 한다. 또한 게임이 더이상 판매되지 않더라도, 플랫폼은 이미 구매한 사용자에게는 재다운로드 권한을 계속 제공한다. 이 내용은 서비스 약관에 명시된다.

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
*전 세계적인 기술현황
◇ 이더리움 네트워크 (Ethereum Net.)
이더리움은 블록체인 네트워크 중의 하나로서, 스마트 컨트랙트를 사용한 첫 블록체인 네트워크이다. 이더리움은 지분증명(PoS; Proof of Stake) 합의 알고리즘으로 트랜잭션 기록을 검증/유지하여 환경 오염이 상대적으로 적은 네트워크를 제공한다. 이더리움은 EVM이라는 가상머신 모델을 구현하여 모든 네트워크가 하나의 동일한 상태를 가진 가상의 컴퓨터를 공유하는 모델로서 내부에 작동하는 스마트 컨트랙트들을 지원하며, 이에 사용되는 언어인 Solidity는 Javascript를 기반으로 설계되어 개발 난이도가 낮다. 이더리움에서 트랜잭션에 사용되는 코인인 이더(ETH; Ether)는 현재 비트코인 외에 가장 시가총액이 높고 지명도가 높은 블록체인 네트워크로서 현재 업계에서 가장 널리 사용되고 신뢰도가 높은 것으로 평가되는 것으로 볼 수 있다.

◇ JSON-RPC (JSON-Remote Procedure Call)
JSON-RPC는 JSON 원격 프로시져 호출을 뜻한다. 이는 서버와 클라이언트 상의 상호작용을 위한 통신 프로토콜로서 JSON으로 인코딩 된 데이터를 통해 의사소통이 이뤄진다. JSON-RPC 프로토콜의 작동 원리는 다음과 같다. 서버는 백엔드 상에서 작동하는 프로그램을 조작하기 위한 API를 제공하고, 클라이언트는 JSON으로 호출할 함수와 함수의 인자 값들을 통해 API 상의 함수 호출을 요청한다. 서버는 이 데이터를 통해 요청을 처리하고, 그 결과 값을 다시 JSON으로 반환하여 유저가 프로그램의 결과를 확인할 수 있도록 한다.

◇ DApp (Decentralized App.)
DApp은 '탈중앙화 앱'을 의미하며, 블록체인 상에서 작동하는 스마트 컨트랙트와 상호작용하는 어플리케이션이다. DApp에선 웹/모바일 어플리케이션 상의 UI/UX 조작을 통해 유저가 스마트 컨트랙트와 상호작용이 이뤄지는데, 이때 스마트 컨트랙트 상에 존재하는 함수들을 호출하기 위해 JSON-RPC를 사용한다. 메타마스크 등의 상용 암호화폐 지갑들은 DApp과 연동되어 호출자의 지갑의 주소와 수수료, 트랜잭션에 사용되는 코인의 양 등의 정보를 같이 넘길 수 있다.

◇ 스테이블 코인(Stable Coin)
스테이블 코인은 그 가치가 특정 자산의 가치와 같도록 고정되는 암호화폐로서, ERC-20 표준을 구현하는, Fungible Token의 일종이다. 스테이블 코인은 일반적으로 달러화 등의 기축통화, 석유/금 등의 고가치 자산을 보유한 기관이 자신이 보유한 자산의 가치만큼의 토큰을 발행하여 유지된다. 현재 잘 알려진 스테이블 코인은 USDT/USDC가 있으며, 이들은 달러화와 연동되어 1 USDT, 1 USDC는 1달러와 같은 가치를 갖도록 유지된다. 스테이블 코인은 스마트 컨트랙트로서 일주일 내내 24시간 거래가 가능하다는 점에서 특정 시간에 제약 받는 기존의 해외 송금 결제 방법에 비해 강점이 있어 점점 해외 무역에서 결제에 사용되는 비중이 많아지고 있다.

*특허조사 및 특허 전략 분석
◇ 저작권 침해 방지를 위한 스마트 컨트랙트 시스템; 1020190002448 (2019.01.08)
상기 특허는 저작물에 대한 온라인 결제를 스마트 컨트랙트로 제공하고 해당 저작물에 대한 저작권 항목별로 각 항목에 관련된 계약을 담은 스마트 컨트랙트를 제공하며 표절을 자동으로 감지하는 시스템을 내용으로 담고 있다. 해당 특허의 경우 서버에 등록된 저작물에 대한 저작권만을 관리 대상으로 보고 있으며, 저작물을 제작하는 데에 사용된 중간 산출물에 대한 조항은 없고, 2차 저작의 관리에 대한 부분 역시 존재하지 않는다. 한편 표절 감지를 자동으로 할 수 있는 시스템에 대한 구상을 담고 있으나, 그에 대한 예시로 제공한 이미지 표절 감지의 사례에서 '패턴 코드'를 통한 검출이라는 구현 가능성이 요원한 기능을 제시하고 있다.

◇ 블록체인을 이용한 저작권 보호 시스템; 1020190111692 (2019.09.09)
상기 특허는 온라인 상에 존재하는 저작권이 있는 파일에 대해 해당 파일이 실행되는 경우 스마트 컨트랙트를 통해 계약된 사항에 따라 저작권료가 분배되는 시스템을 구상하고 있다. 이는 사용자가 전자지갑을 가지고 온라인 상에서 Web3 기능을 사용하여 파일을 실행하는 비용을 제공하는 것으로, 이용권에 대한 구매 모델로 이해될 수 있으며, 일종의 클라우드 서비스를 구축하려는 모델로 평가할 수 있다.

◇ NFT를 이용한 디지털 저작물 수익 공유 시스템 및 방법; 1020210098931 (2021.07.28)
상기 특허는 디지털 저작물의 2차 저작물에 대해서 그 정보를 NFT로 기록하는 기능을 구상하고 있다. 해당 특허에서는 콘텐츠의 유사도에 따라 저작권료가 분배되도록 하고 있는데, 이때 콘텐츠의 유사도를 밝히기 위해서 딥러닝을 사용할 수 있다고 명시하고 있다. 다만 수익 분배에 대해서 해당 NFT의 거래 기록에 따라 저작권료가 분배되는 것으로 구상한 것으로 보아 2차 저작물에서 발생한 수익이 아닌 2차 저작물 자체의 값을 거래한 수익을 공유하는 것으로 이해될 수 있다. 한편 2차 저작물에 대해서 해당 2차 저작물이 유해성이 있는 콘텐츠인 경우에 1차 저작권자에게 경고를 전송하는데, 이를 위한 검출 시스템을 구성하는 것은 그 실현 가능성이 요원하고, 꼭 유해성이 있지 않더라도 콘텐츠의 내용이 1차 저작물의 평판을 해하는 것으로 판단될 수 있는 경우에 대해 1차 저작권자가 제어할 수 있는 부분이 존재하지 않는다.

◇ 블록체인 네트워크에 기반하여 NFT 권리 관계를 인증하기 위한 방법 및 이를 이용한 권리 관계 인증 서버; 미등록, 출원 번호 1020220070318 (2022.06.09)
상기 특허는 디지털 콘텐츠에 대한 저작권과 관련된 권리 관계를 블록체인 상에서 장부로 유지하는 스마트 컨트랙트를 구상하고 있다. 이 특허는 권리 관계라는 해석 범위가 넓은 상호작용에 대한 검증을 내용을 하고 있는데, 이에 따라 중간 산출물이나 2차 저작물도 포함될 가능성이 존재한다. 그런데 이 특허의 경우에 저작권으로부터 파생된 수익에 대한 분배를 가능하게 하는 기능은 별도로 명시되어 있지 않은데, 이 기능이 별도로 신뢰 있는 방식으로 제공되지 않는 한 수익 분배에 있어 2차 저작권자가 2차 저작물로부터 발생한 수익에 대해 1차 저작권자에게 보고할 의무를 따로 갖추게 하는 계약으로 법의 보호를 따로 받지 않는 이상 신뢰 있는 저작권 권리 관계를 맺게 하기 어려울 것으로 보인다.

◇ 기존 출원된 특허 중 저작권에서 발생할 수 있는 문제를 스마트 컨트랙트로 해결해보려는 시도가 적지 않음을 확인할 수 있다. 우리는 이에 대응하여 기존 특허의 접근법들과 유사하지만 충분한 기술적 차별점을 가진 모델을 만드는 특허 회피의 전략을 취한다.

◇ 기존 특허들의 경우 저작물의 유사도를 알고리즘적으로 판단하여 표절을 사전배제하거나 2차 저작물의 수익 발생을 분배하는 모델을 취하는데, 이것은 AI를 통해 기술을 마련하더라도 최종적으로는 법적으로 해결해야 되는 문제로 보인다. 우리는 기존의 법률 인프라에 의존하되 수익 분배가 가능한 합리적인 솔루션을 제공하는 것으로 접근법을 달리 취하기로 한다.

◇ 기존 특허에서는 완성된 2차 저작물에서 발생하는 수익의 분배를 추적할 수 있는 방법이 없어 2차 저작물에서 발생한 수익에 대한 정당한 로열티가 1차 저작권자에게 주어지지 않을 수 있다. 이에 대해 본 프로젝트에서는 플랫폼 혹은 플랫폼에서 제공한 스마트 컨트랙트 상에서 구매가 이뤄지도록 하여 발생 수익에 대한 신뢰도 있는 분배가 이뤄지게 할 수 있다.
*기술 로드맵
◇ React: Front-end
웹 앱의 프론트엔드를 개발하는데 사용되는 라이브러리로, 메타에서 개발했다. 동일한 구조로 모바일 앱과 윈도우 앱의 UI/UX를 만들 수 있어 추후 확장에 유용하다.

◇ Node.js: Back-end
웹 앱의 백엔드를 개발하는데 사용되는 런타임 환경으로서 다양한 패키지를 지원하고 있으며, 패키지 매니저인 npm에서 다양한 패키지를 지원하여 기능을 여러 방면으로 확장할 수 있다. DApp 개발을 위한 RPC 기능을 제공해주는 Web3.js 역시 Node.js의 패키지로서 지원되고 있다.

◇ Solidity: 스마트 컨트랙트 프로그래밍 언어
이더리움에서 사용되는 객체지향 언어로서 컨트랙트 기반 디자인 철학을 따르고, 언어 자체에서 수수료를 사용하는 작업과 그렇지 않은 작업을 구분할 수 있는 문법을 지원하여 스마트 컨트랙트 제작에 용이한 프로그래밍 언어이다.

◇ Hardhat: DApp 개발 환경
DApp을 개발하기 위한 개발 툴로서 Node.js를 기반으로 ethers.js와 통합된 구조를 가진 프로젝트를 생성해주는 기능을 제공하며, Solidity의 컴파일러가 내장되어 있다. 또한 컴파일한 컨트랙트의 인터페이스 정의를 기반으로 그에 맞는 wrapper 타입들을 정의한 js 파일 및 d.ts 파일들을 생성하여 웹3 기능 개발에 있어 컨트랙트를 스크립트 파일에서 쉽게 접근할 수 있는 방법을 제공한다.

====시장상황에 대한 분석====
*경쟁제품 조사 비교
◇ itch.io – 인디게임 중심 전자 소프트웨어 유통 플랫폼으로 누구나 게임을 자유롭게 등록하고 판매할 수 있다. DRM-Free, 자유로운 가격 책정의 정책이 특징이다. 하지만 한 IP에 대한 파생과 로열티를 통한 수익 분배의 개념을 지원하지는 않는다.
◇ GOG.com – 고전 게임 중심이지만 인디게임과 최신 게임도 취급하는 플랫폼으로, DRM-Free를 지원한다. 그러나 한 IP에 대한 다양한 파생과 로열티를 통한 수익 분배의 개념을 지원하지는 않는다.
◇ Steam – 세계 최대 규모의 유통 플랫폼으로 DRM을 강제하여 서비스에 종속된 게임 접근권을 제공한다. 인디게임 등록은 가능하지만 높은 수수료와 치열한 경쟁이 문제이며, 개발자 간 자료 공유 및 파생 콘텐츠 제공을 지원하지 않고, 정품 구매자 혜택이 없다.
◇ 기존 개발자 리소스 공유 사이트: 유니티 에셋 스토어, CraftPix.net, OpenGameArt.org 등의 사이트들은 게임 개발에 필요한 자료를 제공한다. 그러나 게임 유통과 개발 자료 공유가 분리되어 있어 즉각적인 파생 게임 제작이나 아이디어를 바로 실현하는 데 제약이 존재한다.
*마케팅 전략 제시
◇ 통합 콘텐츠 큐레이션 및 변주 제공
- 경쟁 플랫폼과 달리 Ludex는 한 게임의 원작은 물론 파생 게임과 다양한 변주 버전을 한 곳에서 큐레이션하여 제공한다. 이를 통해 사용자가 특정 게임을 즐긴 후에 해당 IP의 다양한 파생 게임을 탐색 및 구매할 수 있다.
◇ 개발 자료 직접 구매 기능 강화
- 게임을 플레이하는 도중, 마음에 드는 요소나 새로운 아이디어가 발견되면, 해당 게임의 개발 자료(코드, 기획 문서, 애셋 등)를 바로 구매할 수 있도록 하여 창작과 개발에 직접 연결될 수 있는 생태계를 조성한다.
◇ 개발자 지원 및 수익 모델 개선
- 스마트 컨트랙트 기반으로 파생 게임 제작 권한 및 개발 자료 거래를 관리하여, 인디게임 개발자들이 자신의 IP를 활용해 다양한 수익 창출 기회를 얻을 수 있도록 지원한다.
- 파생 게임의 판매 수익의 일정 비율을 원작 개발자에게 자동 배분하는 시스템으로, 기존 플랫폼 대비 보다 공정한 수익 분배를 강조한다.
◇ 스마트 컨트랙트 기술적 우위 활용한 기능 확장으로 차별화 지위 확보
- 스마트 컨트랙트를 사용하면 투표를 통한 게임잼 개최, 한 게임 팀 내에서의 수익 분배와 같이 기존 플랫폼에선 수행하기 어려웠던 기능을 손쉽게 구현할 수 있다.
- 본 플랫폼에선 스마트 컨트랙트로만 구현할 수 있는 기능들을 지속적으로 추가하여 다른 플랫폼에 비해 차별화된 시장 지위를 갖는 것을 목표로 삼는다.
- 현재 블록체인 기술에 대한 회의적 시각을 갖고 있는 소비자가 많은 현실을 반영하여 스마트 컨트랙트 자체를 마케팅 용어로 삼지는 않지만, 스마트 컨트랙트를 사용해야만 구현 가능한 기능들을 공격적으로 구현하여 활용하는 전략을 사용한다.

===개발과제의 기대효과===
====기술적 기대효과====
◇ 소액 금융 거래에 대한 기술적 수단 제공
현재 대부분의 온라인 마켓플레이스는 구매자 – 판매자 관계를 일대일로 상정하고 있는데, 이는 판매자 측이 소규모 법인 혹은 여러 법인의 연합체인 경우 수익 배분과 관련하여 관리의 어려움을 낳는다. 이는 기존의 Web2 기술에 기반한 금융 인프라 사업들의 경우 금융 거래에 대한 수수료를 거래에 건수별로 적용하고 있기 때문으로, 소액 결제의 경우 수수료를 거래 건당 지불하게 되면 수수료의 비중이 너무 커지는 문제가 있다. 본 프로젝트는 이에 대응하여 이더리움 네트워크에서 사용되는 ERC-20 토큰의 거래로 변경한다. ERC-20 토큰은 거래 건수가 아닌 전체 연산의 복잡성에 따라 수수료를 매기는 방식을 따르는데, 이를 이더리움 네트워크의 L2 솔루션인 옵티미즘 네트워크에 적용할 경우 여러 유저 사이의 수익 배분이 일어나는 거래에 대해서도 수수료를 낮게 유지하면서도 Web2에 뒤지지 않는 거래를 제공할 수 있어서 소액 금융 거래에 대한 실질적인 방법을 제공한다.

◇ Gasless 마켓플레이스 DApp 구현
블록체인 네트워크 상에서 동작하는 탈중앙화 애플리케이션(이하 DApp; Decentralized Application)들은 블록체인 네트워크에 새로운 상태를 기록을 하는 유저 동작에 대해 일정량의 수수료를 가져간다. 이더리움의 경우 이를 Gas라 하는데, 이는 마켓플레이스 DApp에 있어 가격을 정찰제 형식으로 제공하기 어렵고, 추가적인 비용에 대한 우려로 인해 소비자 심리를 약화시킬 수 있는 문제로 작동하게 된다. 이에 대해 현재 이더리움 네트워크 상에서 제안된 표준 중 하나인 ERC-2771은 스마트 컨트랙트의 상호작용을 원격으로 수행할 수 있는 컨트랙트를 만들고 이 원격 호출을 대리해주는 객체, 주로 서비스 제공자가 수수료를 대신 지불할 수 있게 하여 Gas를 지불하지 않는, Gasless DApp을 구현할 수 있는 방법을 제공하는데, 아직 이를 실제로 구현한 DApp은 많지 않은 실정이다. 본 프로젝트에서는 ERC-2771 표준을 실질적으로 구현한 DApp을 개발하여, 아직 미개척의 영역에 있는 Gasless DApp에 하나의 선례를 제공한다.
====경제적, 사회적 기대 및 파급효과====
◇ 게임 콘텐츠 산업의 다양성 창출
게임 산업에 있어서 대규모 자본의 지원을 받지 않는 인디게임은 산업의 건전성에 있어 필수적인 영역으로 자리 잡은 지 오래 되었다. 혁신적인 아이디어를 가진 게임을 만들어 기존과 다른 참신한 컨텐츠를 만드는 인디게임의 중요성은 영화 산업에서 독립 영화들이 가지고 있는 중요성에 대응되는 수준이다. 하지만 인디게임을 만드는 것은 독립 영화를 만드는 일과는 달리 기술적인 요구사항이 많아서 일정 수준의 퀄리티를 갖춘 게임을 만드는 일에는 진입 장벽이 굉장히 높은 편이다. 본 플랫폼은 이에 도움이 될 수 있는 방법으로서 성공한 게임의 개발 리소스를 빌려 사용할 수 있으면서도 원작 제작자에게도 이득이 되는 수익 분배 계약을 제공하여 경험이 없는 개발자들이 인디게임을 조금 더 쉽게 만들 수 있는 환경을 제공한다. 이를 통해 인디게임 제작의 진입 장벽을 낮추어, 게임 산업의 콘텐츠 다양성의 창출에 기여할 수 있다.

◇ 게임 개발의 대안적 모델 제공
현재의 게임 산업은 하나의 게임을 개발하는 전체 과정을 전적으로 하나의 법인이 도맡아서 수행하는 형태로 동작하고 있는데, 이 모델은 개발직 노동자가 한 프로젝트의 성사를 위해 너무 많은 노동 시간을 감내해야 하는 형태로 지적되고 있다. 본 프로젝트는 하나의 IP를 여러 다른 이익집단이 함께 발전시켜나갈 수 있는 형태를 취함으로써, 각자 기여할 수 있는 만큼 기여하면서 점진적으로 게임을 발전시키는 효과를 누릴 수 있는 방법을 제공한다. 이는 오픈소스 소프트웨어가 다른 소프트웨어 분야에서 대안적 모델로 작동하는 것과 유사하지만, 신뢰 가능한 수익 분배 모델을 제공함으로써 소프트웨어를 프리웨어화하지 않고도 합리적인 기여 모델을 세울 수 있다.

◇ 영세 개발자도 할 수 있는 IP 확장
인디게임 개발은 성공하면 큰 돈을 벌지만, 실패할 가능성이 아주 높은 일이라고 알려져 있다. 그런데 인디게임 개발은 소규모 인원이 하는 일이기 때문에 성공하는 경우와 실패하는 경우 모두에게 있어 문제가 발생한다. 성공한 인디게임의 경우 IP를 공격적으로 확장하고 싶어도 인력 부족의 문제로 인해 그것이 원활하게 이뤄지지 못하는 경우가 많다. 예컨대 성공한 게임의 외전을 만들거나 확장팩을 만드는 것도 인디게임 개발자들에겐 품이 많이 들어가는 일이기 때문이다. 한편, 실패하는 경우 개발자는 인디게임 개발자로서 생계를 유지하는 것이 어려운 경우가 많고, 때문에 업계 자체를 떠나게 되는 경우도 많은 상황이다. 이에 대해 게임 IP의 리소스에 대한 로열티를 대가로 새로운 게임을 만들 수 있게 하는 본 프로젝트의 플랫폼의 경우 성공한 게임의 경우 IP 자체를 공격적으로 사용하여 다른 이들이 자신의 IP를 이용하게 함으로써 수익 확대를 노릴 수 있고, 실패한 게임의 경우 개발 중 산출된 리소스의 로열티를 얻을 수 있어 생계 유지에 추가적인 도움을 얻을 수 있다.

===기술개발 일정 및 추진체계===
====개발 일정====
[[파일:개발일정 중간.jpeg]]

====구성원 및 추진체계====
구성원
◇ 임진우
팀장, DB 설계 및 Back-End 개발
◇ 김준호
DB 설계 및 Back-End 개발
◇ 서호영
스마트 컨트랙트 설계 및 개발, DApp 기능 개발
◇ 이희진
PM, Front-End 개발, UI/UX 설계 및 개발

추진체계
◇ 회의 및 개발 운영
본 프로젝트는 매주 주말에 팀 전체가 참여하는 개발 회의를 통해 진행 상황을 점검하고, 스프린트 계획 및 개발 일정을 조율한다. 회의록은 팀원들이 교대로 작성하여, 회의 결과를 체계적으로 기록하고 공유하는 방식을 따른다.
개발 프로세스는 Scrum 방식을 기반으로 운영한다. 스프린트는 1주일 단위로 구성되며, 스프린트 시작 시에는 스프린트 계획 회의(Planning) 를 진행하여 이번 주의 주요 개발 목표를 설정한다. 매일 데일리 스크럼을 통해 팀원들이 각자의 진행 상황을 공유하며, 장애 요소나 협력이 필요한 사항을 빠르게 조율한다. 매주 스프린트 종료 시에는 그 주에 개발한 기능이나 프로토타입을 프로토타입 시연(Prototype Demo) 형태로 공유하고, 이를 바탕으로 스프린트 회고(Retrospective) 를 실시하여 개발 과정에서의 문제점과 개선사항을 도출한다.
전체 개발 일정은 1주일 단위 스프린트를 기준으로 관리하여, 명확한 목표 설정과 주기적인 점검을 통해 일관성 있는 개발 흐름을 유지하고자 한다.

◇ 형상 관리
형상 관리는 GitHub를 통해 진행하며, 브랜치 전략은 git-flow 모델을 기반으로 간소화해 운영한다. 업무 단위 또는 기능별 개발은 별도의 브랜치를 생성하여 관리하고, 작업 완료 시에는 Pull Request(PR)을 생성하여 코드 리뷰를 요청한다.
Merge 방식은 Squash and Merge를 기본으로 사용하여, 작업 이력을 깔끔하게 관리하고자 한다. PR 작성자는 팀원의 승인(Approve)을 받은 후, 본인이 직접 PR을 Merge하는 절차를 따른다. 이를 통해 리뷰와 승인 과정을 명확히 거친 뒤 안정적으로 개발 통합을 수행한다.

◇ 코드 리뷰 프로세스
PR(Pull Request) 작성 시에는 일정한 규칙을 따른다. PR 제목은 [type] subject 형식으로 작성하며, type은 작업의 성격에 따라 구분한다. 주요 타입 종류로는 기능 추가를 의미하는 feat, 버그 수정을 나타내는 fix, 문서 수정 작업인 docs, 코드 포맷팅 및 비기능성 수정을 위한 style, 코드 리팩토링을 나타내는 refactor, 테스트 코드 추가 및 수정을 나타내는 test, 빌드 설정 변경이나 기타 작업을 의미하는 chore가 있다. PR 제목은 예를 들어 feat: 사용자 로그인 기능 추가와 같이 작성하며, 제목의 첫 단어는 반드시 소문자로 시작한다. PR 본문은 두 부분으로 구성한다. 본문(body)에는 작업 내용 요약, 구현 방법, 팀원과 공유할 필요가 있는 정보 등을 작성하며, 꼬리말(footer)에는 이슈 번호 연결 정보를 포함한다. 이슈 연결은 resolves: #123과 같이 작성하여, PR이 특정 이슈를 해결하는 것임을 명시한다. PR 작성 후에는 반드시 팀원 중 1명 이상을 Reviewer로 지정하여 코드 리뷰를 요청한다. Reviewer는 기능 요구사항 충족 여부, 코드의 가독성과 유지보수성, 잠재적인 버그나 예외 처리 누락 여부, 코딩 스타일 준수 여부, 그리고 성능 최적화 여부 등을 중심으로 검토를 진행한다. 리뷰 과정에서 피드백이 발생하면, 작성자는 해당 피드백을 반영하여 코드를 수정하고 다시 리뷰를 요청한다. 모든 리뷰가 완료되고 승인이 이루어진 이후에는 PR 작성자가 본인의 PR을 직접 Merge한다.

◇ Git 브랜치 네이밍 규칙
Git 브랜치 관리는 명확한 네이밍 규칙을 따른다. 배포를 위한 메인 브랜치는 main, 개발 통합을 위한 브랜치는 dev로 고정하여 사용한다. 개별 업무나 이슈 단위의 작업은 issue/#이슈번호 형식으로 브랜치를 생성하여 진행한다. 작업 흐름은 다음과 같다. 우선 GitHub에서 새로운 이슈를 생성하고, 이슈 번호를 확인한다. 이후 로컬 환경에서 issue/#이슈번호 형식으로 새로운 작업 브랜치를 생성하고, 해당 브랜치에서 목표 기능을 개발한다. 개발 완료 후 PR을 생성하여 팀원에게 리뷰를 요청하며, 리뷰 완료 및 Merge 이후에는 작업 브랜치를 삭제하고 관련 이슈를 종결한다.

==설계==
===설계사양===
====액터 정의====
[[파일:액터-정의.jpeg]]

====기능 요구사항 정의====
[[파일:기능-요구사항-정의.jpeg]]

[[파일:기능-요구사항-정의-2.jpeg]]

[[파일:기능-요구사항-정의-3.jpeg]]

====유스케이스 정의====
[[파일:유스케이스-정의-1.jpeg]] 
[[파일:유스케이스-정의-2.jpeg]] 
[[파일:유스케이스-정의-3.jpeg]] 
[[파일:유스케이스-정의-4.jpeg]] 
[[파일:유스케이스-정의-5.jpeg]]

====UML Diagram====
[[파일:유스케이스-다이어그램.jpeg]]

====Sequence Diagram====
*주요 유스케이스 - UC220: 상품 목록 열람
[[파일:시퀀스-UC200.jpeg]]
진행 과정:
콘텐츠 목록 요청 및 표시
사용자는 메인 페이지 UI에 콘텐츠 목록을 요청한다. (requestToViewContent)
메인 페이지 UI는 큐레이션 시스템에 콘텐츠 미리보기 목록을 요청한다. (fetchPreviewList())
큐레이션 시스템은 게임 객체 집합으로부터 미리보기 정보를 요청한다. (getPreview())
각 게임 객체는 큐레이션 시스템에 미리보기 정보를 반환한다. (preview)
큐레이션 시스템은 메인 페이지 UI에 콘텐츠 미리보기 목록을 전달한다. (previewList)
메인 페이지 UI는 사용자에게 콘텐츠 목록을 화면에 출력한다. (displayContents)

콘텐츠 상세 조회 및 화면 출력
1. 사용자는 특정 콘텐츠에 대한 상세 정보를 요청한다. (requestDetails)
2. 메인 페이지 UI는 콘텐츠 상세 페이지 UI로 화면을 전환한다. (navigate)
3. 콘텐츠 상세 페이지 UI는 게임 객체(a game)에 콘텐츠 상세 정보를 요청한다. (getDetails())
4. 게임 객체(a game)는 콘텐츠 상세 정보를 콘텐츠 상세 페이지 UI에 반환한다. (detail)
5. 콘텐츠 상세 페이지 UI는 사용자에게 콘텐츠 상세 정보를 출력한다. (showDetail)

*주요 유스케이스 - UC310: 판매 개시
[[파일:시퀀스-UC310.jpeg]]
진행 과정:
게임 등록 화면 진입
1. 사용자는 메인 페이지 UI에서 ‘Submit Game’ 버튼을 클릭한다. (ClickRegisterButton)
2. 메인 페이지 UI는 게임 등록 페이지 UI로 이동한다. (navigate)
3. 게임 등록 페이지 UI는 게임 등록 화면을 사용자에게 보여준다. (showPage)

콘텐츠 기본 정보 입력 및 검증
1. 사용자는 상품 정보를 입력한다. (provideProductInformation)
2. 게임 등록 페이지 UI는 입력된 정보를 검증하고 사용자에게 결과를 반환한다. (validInformation)
3. 사용자는 태그를 선택한다. (selectTag)
4. 게임 등록 페이지 UI는 선택된 태그의 유효성을 검증한다. (validTag)

파생 콘텐츠일 경우의 처리 (opt)
1. 사용자가 등록하는 콘텐츠가 파생 콘텐츠인 경우, 원작 IP 코드를 입력한다. (EnterIPCode)
2. 게임 등록 페이지 UI는 IP 코드의 유효성을 검증하고 결과를 반환한다. (validIPcode)

콘텐츠 파일 업로드 및 등록
1. 사용자는 게임 파일을 업로드한다. (uploadFile)
2. 게임 등록 페이지 UI는 업로드된 파일의 유효성을 검증한다. (validFile)
3. 사용자는 최종적으로 ‘Launch’ 버튼을 누른다. (pushLaunchButton)
4. 게임 등록 페이지 UI는 새로운 게임 인스턴스를 생성한다. (create → A game : Game)

*주요 유스케이스 - UC340: 할인 개시
[[파일:시퀀스-UC340.jpeg]]
진행 과정:
판매 중인 상품 목록 조회
1. 사용자는 라이브러리 페이지 UI에 자신이 판매 중인 콘텐츠 목록 조회를 요청한다. (viewSellingProductList)
2. 라이브러리 페이지 UI는 사용자에게 판매 중인 콘텐츠 목록을 출력한다. (displaySellingProductList)

할인 시작 팝업 활성화
1. 사용자는 특정 콘텐츠의 할인 시작 버튼을 클릭한다. (clickDiscountStartButton)
2. 라이브러리 페이지 UI는 할인 정보를 입력할 수 있는 팝업을 출력한다. (showDiscountPopup)

할인 정보 입력 및 등록 요청
1. 사용자는 할인율과 할인 기간을 입력하고 할인 시작을 요청한다. (enterDiscountRateAndPeriod && startDiscount)
2. 라이브러리 페이지 UI는 새로운 할인 인스턴스를 생성한다. («create» A discount : Discount)
3. 생성된 할인 인스턴스는 해당 콘텐츠(게임)에 할인 정보를 등록한다. (registerDiscountInfo(discountDetails))
4. 게임 객체는 할인 정보를 성공적으로 등록했음을 할인 인스턴스에 응답한다. (registerSuccess)
5. 할인 인스턴스는 라이브러리 UI에 할인 생성 완료를 알린다. (createSuccess)
6. 라이브러리 UI는 사용자에게 할인 시작 완료를 알린다. (notifyDiscountStart)

*주요 유스케이스 - UC411-UC412: API 활용 상품 구매 - 스마트 컨트랙트 활용 상품 구매
[[파일:시퀀스-UC411.jpeg]]
진행 과정:
결제 UI 진입 및 금액 선택
1. 사용자는 게임 구매 페이지 UI에서 결제 버튼을 클릭한다. (clickPurchaseButton)
2. UI는 결제 팝업을 사용자에게 표시한다. (showPurchasePopup)
3. 사용자는 결제할 금액을 선택한다. (selectAmountToPay)
4. UI는 결제 방식 선택을 위한 드롭다운 버튼을 표시한다. (displayDropdownButton)

결제 방식 선택 – 분기 처리 (alt)
[분기 A] Fintech 결제 버튼 클릭 시
1. 사용자는 핀테크 결제 버튼을 클릭한다.
2. UI는 핀테크 API 제공자에게 결제를 요청한다. (requestViaFintech)
3. 핀테크 API 제공자는 purchase() 동작을 수행한다.
4. 결제 팝업이 표시된다. (showPaymentPopup)
5. 결제가 처리되며, 결제 내역이 반환된다. (processThePayment → paymentHistory)
6. UI는 사용자에게 결제 완료를 알린다. (notifyPaymentSuccess)

[분기 B] 스테이블 코인 결제 버튼 클릭 시
1. 사용자는 스테이블 코인 결제 버튼을 클릭한다.
2. UI는 사용자의 암호화폐 지갑에 결제를 요청한다. (requestViaStableCoin)
3. 결제 팝업이 표시된다. (showPaymentPopup)
4. 결제가 처리되며, 사용자의 지갑이 purchase() 동작을 수행한다.
5. 결제 내역이 UI로 반환된다. (paymentHistory)
6. UI는 사용자에게 결제 완료를 알린다. (notifyPaymentSuccess)

*주요 유스케이스 - UC510-UC520: 리소스 열람 - 리소스 사용 계약
[[파일:시퀀스-UC510.jpeg]]
진행 과정:
리소스 정보 조회
1. 사용자는 게임 구매 페이지 UI에서 리소스 상세 정보를 조회한다. (browseResourceDetails)
2. UI는 리소스 객체에 리소스 세부 정보를 요청한다. (getResourceDetails())
3. 리소스 객체는 요청된 정보를 UI에 반환한다. (resourceDetails)
4. UI는 사용자에게 리소스 정보를 출력한다. (displayResourceDetails)

거래 조건 동의 및 스마트 컨트랙트 실행
1. 사용자는 거래 조건에 동의한다. (agreeToTerms)
2. UI는 사용자의 암호화폐 지갑에 스마트 컨트랙트 실행을 요청한다. (invokeSmartContract())

스마트 컨트랙트를 통한 블록체인 거래
1. 사용자의 암호화폐 지갑은 스마트 컨트랙트에 서명 및 실행 요청을 보낸다. (signAndExecuteTransaction())
2. 스마트 컨트랙트는 블록체인에 거래 정보를 저장한다. (storeInformation())
3. 블록체인은 거래 해시값을 스마트 컨트랙트에 반환한다. (transactionHash)
4. 스마트 컨트랙트는 거래 상태를 사용자 지갑에 반환한다. (transactionStatus)
5. 사용자 지갑은 거래 상태를 UI에 전달한다. (transactionStatus)
6. UI는 사용자에게 거래 완료 메시지와 상태를 표시한다. (displaySuccessMessageWithTransactionStatus)

====UI 구성====
◇ UI 플로우차트
[[파일:UI-flowchart.jpeg]]
해당 UI Flow Chart는 플랫폼 사용자, 판매자, 관리자 각 역할별로 수행할 수 있는 주요 UI 흐름을 정리한 것이다. 상단에서 메인 메뉴 구조를 시작으로 하여, 하위 행동 단계들이 절차적으로 구성되어 있으며, 요구사항 명세서의 유스케이 스와 연동되어 있다.

1. 초기 진입 및 사용자 인증 흐름
사용자는 메인 페이지에서 로그인/회원가입을 선택할 수 있으며, 이메일 또는 전자지갑 인증을 통해 계정을 생성한다.

로그인 후 플랫폼 기능 접근이 가능하며, 이는 UC111 (계정 생성), UC120 (로그인/로그아웃) 등의 요구사항과 대응된다.

2. 게임 검색 및 상세 정보 조회
메인 페이지에서는 게임 검색 또는 상품 등록 기능으로 진입할 수 있으며, 검색어 입력 또는 태그 필터를 통해 원하는 상품 목록을 조회할 수 있다.
사용자는 원하는 게임 슬롯을 선택하여 상세 페이지로 진입할 수 있으며, 이 흐름은 UC210 (검색어 기반 검색), UC220 (상품 목록 열람)에 해당한다.

3. 상품 등록 및 판매
판매자는 상품 등록 페이지에서 게임 정보를 입력하고, 상품 설명, 가격, 태그, 티저 이미지 등을 포함하여 업로드할 수 있다.

상품 등록 시 리소스를 함께 게시할 수 있으며, 파생 콘텐츠인 경우 IP 코드 입력을 통해 연계 정보를 제공한다. 해당 흐름은 UC310 (판매 개시), UC320 (리소스 게시)로 대응된다.

4. 상품 상세 페이지에서의 사용자 행동
사용자는 상품 상세 페이지에서 신고 버튼 클릭 또는 구매 버튼 클릭을 선택할 수 있다.
신고는 UC810 (콘텐츠 신고) 흐름과 연결되며, 관리자에 의해 확인되어 처리된다 (UC820).
구매를 선택한 경우 핀테크 API 또는 전자지갑 기반 결제 방식 중 하나를 선택할 수 있다.

5. 구매 및 결제 프로세스
구매 버튼 클릭 후, 사용자는 결제 방식(핀테크 / 전자지갑)을 선택한다.
핀테크 API의 경우 외부 결제 창이 호출되며 결제 완료까지 연결된다.
지갑 결제는 스테이블 코인을 이용하며 스마트 컨트랙트를 통해 처리된다.

이 전체 프로세스는 스마트 컨트랙트 기반 구매 및 거래 기록 생성까지 이어지며, 블록체인에 기록되는 흐름으로 확장된다.

이는 UC411, UC412 (API 활용 상품 구매, 스마트 컨트랙트 활용 상품 구매)으로 이어진다.

6. 마이페이지 기능
사용자는 마이페이지에서 정보를 수정하거나 계정을 삭제할 수 있으며, 구매 목록 및 판매 상품 목록, 할인 설정 등을 관리할 수 있다.

UC130 (계정 정보 수정), UC140 (전자지갑 연동), UC420~UC430 (구매 이력, 다운로드), UC331~UC340 (판매 목록 열람, 판매 상품 정보 수정, 할인 개시) 등의 유스케이스가 해당된다.

7. 관리자 기능
관리자 페이지에서는 상품 판매 상태 설정, 계정 관리, 신고 확인, 배너 편집 및 알림 발송 등
전반적인 플랫폼 운영 기능이 배치되어 있다.

이는 UC610~UC820에 해당하는 관리자용 유스케이스들과 연결된다.

◇ UI 와이어프레임
사이트화면구성 와이어프레임
[[파일:와이어프레임.jpeg]]
구매자와 판매자가 사이트에 로그인하고, 게임을 탐색, 판매, 등록, 다운로드하는 화면들의 구성

관리자페이지 와이어프레임
[[파일:관리자페이지-와이퍼프레임.jpeg]]
관리자가 신고를 접수, 알림을 보내고 특정 상품의 정보를 확인, 판매를 중단하는 화면들의 구성

====시스템 설계====
◇ 전체 시스템 구성
[[파일:시스템설계.jpeg]]
(Cryptocurrency Wallet은 구현 사항이 아닌 외부 소프트웨어임)

프론트엔드: 유저가 DApp과 상호작용하기 위한 UI를 제공하고, 데이터베이스와 스마트 컨트랙트에 백엔드가 특정 정보를 입출력 해주는 것을 요청할 수 있다. 또한 Ingegration Library를 통해 스마트 컨트랙트 상의 정보를 직접 확인할 수 있다. 본 프로젝트에서는 구현에 node.js와 React 프레임워크, Express를 사용하였다
백엔드: UI 상의 유저 조작으로 인해 발생한 입출력 요청을 기반으로 데이터베이스와 스마트 컨트랙트에 데이터를 입출력한다. 본 프로젝트에서는 node.js와 Express를 사용하였고, 실제 서버 동작에는 AWS 클라우드를 사용하였다
데이터베이스: DApp 상에서 스마트 컨트랙트 상에 저장할 수 없는 데이터를 저장하는 공간으로 기능한다. 본 프로젝트에서는 MySql을 사용하였고, 실제 데이터베이스 동작에는 AWS 클라우드를 사용하였다
통합 지원 라이브러리: 블록체인에 정의된 스마트 컨트랙트를 호출하기 위하여 인증 및 서명과 같은 기능에 복잡한 과정을 캡슐화한 타입을 정의한 라이브러리로 기능한다. 본 프로젝트에서는 node.js를 사용하였고, 스마트 컨트랙트 호출을 위한 모듈로서 ethers.js (v6)를 사용했고, 호출을 위한 API 서비스로는 Alchemy를 사용하였다
EVM(Ethereum Virtual Machine): 이더리움 블록체인 전체가 같은 상태 값을 유지하는 가상 머신 으로서, 프로젝트 진행 중에 정의한 스마트 컨트랙트가 프로그램으로서 작동하고 있다. 컨트랙트 코드의 작성에는 OpenZeppelin 라 이브러리가 사용되었다.

====스마트 컨트랙트 설계====
◇ 컨트랙트 다이어그램
[[파일:컨트랙트-다이어그램.jpeg]]
◇ 컨트랙트 구성

IERC20 (OpenZepplin)
ERC-20 표준을 구현하는 컨트랙트들에 대한 인터페이스로서, 대체 가능한 토큰(Fungible Token)을 사용하기 위한 함수들, 즉 토큰 계좌 잔액 확인, 토큰 전송 등이 정의되어 있고, 다른 전자지갑 소유자 혹은 프로그램이 토큰 전송을 대 행해주는 것을 승인해줄 수 있는 함수 역시 정의되어 있다

IERC20Permit (OpenZeppelin)
ERC-20 표준의 확장인 EIP-2612를 구현하는 컨트랙트에 대한 인터페이스로서, 다른 계좌 소유자 혹은 프로그램에서 토큰 전송을 대행해 주는 작업을 별도의 트랜잭션 없이 오프체인에서 생성한, 검증 가능한 서명을 기반으로 할 수 있는 함수가 정의되어 있다

IERC721 (OpenZepplin)
ERC-721 표준, 즉 NFT를 구현하는 컨트랙트의 인터페이스. 해당 인터페이스를 통해 주소별로 소유하고 있는 NFT들을 확인할 수 있고, 특정 NFT에 대해 소유권자의 주소를 확인할 수 있으며, 소유자가 특정 주소로 자신의 NFT를 전송. 또한, 별도의 승인 과정을 거치는 경우 승인 받은 주소의 호출자가 특정 주소에서 다른 주소로 특정한 NFT를 전송한다.

ERC2771Context (OpenZeppelin)
ERC-2771 표준, 즉 메타트랜잭션이 수행되는 컨트랙트. 해당 컨트랙트는 릴레이어라는 별도의 주소에서 호출한 요청에 대해 그것이 대리하고 있는 실제 호출의 정보를 확인한다.

ERC2771Forwarder (OpenZeppelin)
메타트랜잭션에서 RPC로 요청된 함수 호출에 대해 그 호출이 특정 주소의 호출을 대리하는 호출임을 서명 검증 과정을 통해 확인하는 컨트랙트로서, ERC2771Context 컨트랙트 생성 시에 주입되어 ERC2771Context가 수행하는 호출 들에 대해 그 호출이 안전한 대리자 호출임을 보증한다.

Ownable (OpenZeppelin)
컨트랙트가 특정 주소에 의해 소유되었다고 명시할 수 있으며, 특정 함수를 오직 해당 컨트랙트의 소유자만이 호출할 수 있도록 제한할 수 있는 onlyOwner modifier를 제공한다

OwnableERC2771Context
Ownable 컨트랙트와 ERC2771Context를 다중 상속하는 컨트랙트, 본 시스템의 다수의 컨트랙트가 상속한다

Store
아이템의 구매 요청을 확인하는 컨트랙트로, 구매 요청을 PaymentProcessor에 넘겨 실제 토큰 지불 과정이 수행되도록 하며, Ledger 컨트랙트에 해당 구매에 대한 NFT 토큰 발급을 요청한다

ProfitEscrow
아이템의 구매로 인해 발생한 수익에 대하여 특정 판매자 계좌가 얼마나 많은 토큰을 받기로 되어 있는지 기록하는 에스크로 역할의 컨트랙트로서, 판매자는 이 컨트랙트를 통해 자신의 수익을 확인하고, 해당 수익을 요청할 수 있다. 또한 Web2 금융 인프라에 의해 수행된 결제의 수익은 Owner가 지불할 예정인 토큰의 양이 기록되고, Owner는 실제 토큰을 해당 컨트랙트에 입금하고 정산 기능을 호출함으로써 결제된 수익을 판매자가 요청 가능한 상태로 변경할 수 있다

PaymentProcessor
구매 요청을 받아 구매할 아이템의 가격과 해당 아이템에서 발생하는 수익의 분배 조건을 확인하여 구매자의 주소로부터 토큰을 이체하여 여러 개의 판매자 주소에 대해 어떤 판매자가 얼마나 수익을 가져가야 하는지 ProfitEscrow에 기록 요청을 전달하고, 수수료에 해당하는 양만큼 Owner 계좌에 전달한다

PriceTable
아이템의 가격이 관리되는 컨트랙트로, 오직 아이템의 판매자만이 아이템의 가격을 변경할 수 있도록 하는 기능을 제공하며, 한 아이템에서 파생된 아이템들에 대하여 수익 배분이 어떻게 진행되는지의 정보를 기록할 수 있고, 할인 및 특정 아이템에 대한 수익 지분율 감면을 통한 IP 전체에 대한 할인 기능을 지원한다

Ledger
아이템의 구매가 일어날 때 해당 구매 이력에 대한 정보를 저장하고 이에 대한 NFT를 발행하는 컨트랙트이다
ItemRegistry
판매자가 자신이 판매할 상품 및 상품의 파생 상품에 대한 로열티 조건을 등록할 수 있는 컨트랙트이다. 또한, Owner는 문제를 발생시킨 상품에 대해 판매를 중단할 수 있고, 문제가 해결되는 경우 판매를 재개할 수도 있다

PurchaseProxy
이더리움 전자지갑이 없는 사용자가 Web2를 통해 상품을 구매하는 경우, 이에 대해 해당 상품에서 발생한 수익을 Owner가 지불할 예정임을 Store에 알려서 수익 정산 예정 상황을 기록하게 하고, Ledger로 하여금 구매 이력을 기록하 도록 하는 역할을 수행하는 컨트랙트이다. 유저는 자신이 구매한 상품타에 대해 구매 이력을 확인하고, 이에 대한 권한을 전자지갑으로 옮기도록 할 수 있다

SellerProxy
이더리움 전자지갑이 없는 사용자가 Web2를 통해 상품을 등록한 경우, 해당 아이템에 대해 가격 및 수익 지분율 조정과 같은 작업을 수행할 수 있게 하고, 자신의 상품 수익에 의해 발생한 수익을 Web2로 정산한 경우 해당 양과 동등한 토 큰을 ProfitEscrow로부터 플랫폼이 관리하는 주체의 계좌로 옮길 수 있다

====서버 아키텍처====
◇ 아키텍쳐 다이어그램
[[파일:server-architecture-final.jpeg]]
◇ 구조 설명: 마이크로서비스 아키텍쳐
프론트엔드의 요청을 처리할 때 서버가 각각의 서비스를 분리하여 처리할 수 있도록 마이크로서비스 아키텍처를 사용한다. 구성되는 서비스의 목록은 다음과 같다
- 유저 계정 관리 서비스
- 파일 정보 관리 서비스
- 관리자 계정 관리 서비스
- 이더리움 블록체인과 상호작용을 위한 Web3 관련 서비스
- 게임 및 리소스 파일의 다운로드 서비스
- 파일 업로드 서비스
각각의 서비스에 대해 마치 각각에 대해 별도의 서버가 존재하는 것처럼 서버를 작성하여, 논리적으로 분리되는 서비스 단위를 물리적으로도 분리하여 유지보수성이 높은 서비스를 제공한다

◇ 구현 전략: 도커 컨테이너 오케스트레이션
각각의 마이크로서비스를 도커를 사용하여 구성한다. 각각의 서비스는 각각의 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 작동하며, 이 전체의 조화 작업을 쿠버네티스를 사용하여 오케스트레이션한다. 이때 컨테이너 간 호출을 위한 기술로서 gRPC를 사용하도록 한다

◇ 지원 기술
서비스 아키텍쳐를 뒷받침하는 Backing Sevice들의 목록은 다음과 같다
- AWS RDS: MySql 데이터베이스 입출력을 담당하는 AWS 클라우드의 서비스
- Redis: DB 입출력, 로그인 세션 유지를 위한 Json Web Token Refresh등 빈번한 작업에 캐싱을 수행하는 인프라로 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 동작하며, 전체 서비스의 지원을 담당한다
- Qdrant: 웹앱 상에서 검색 기능을 제공하기 위해 DB 상의 텍스트 데이터들에 대해 생성한 워드 임베딩 벡터들을 담당하는 임베딩 벡터 전용 DB로서 별도의 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 동작한다
- AWS S3: 웹앱 상에서 제공하는 게임, 리소스등의 파일을 저장하고 관리하기 위한 전용 서비스이다

====DB 설계====
◇ ER 다이어그램
[[파일:Ludex DB ERD_real-1.jpeg]]
◇ DB 테이블 구성
account
- 사용자 및 관리자의 정보를 저장하는 테이블
- 비밀번호는 해시값을 저장하여 DB 관리자가 비밀번호를 알 수 없도록 한다.
- 사용자 또는 관리자임을 나타내는 컬럼을 사용하여 구분한다.
- 전자지갑은 다수를 소유할 수 있으므로 무결성을 지키기 위해 별도의 테이블로 둔다.
- 잘못을 범한 유저의 계정 정지/해제를 다룰 테이블을 sanction Table로 둔다.

game
- 플랫폼에 등록되는 게임의 정보를 저장하는 테이블
- 다운로드 URL는 File Chunk단위로 나눠 다운로드를 가능하게 할 예정으로, 여러 URL이 필요해 무결성을 지키기 위해 별도 테이블로 만든다.
- 게임 구동사양 또한 게임별로 자유롭게 여러 항목을 개발자 재량으로 작성할 수 있도록 별도 테이블로 만든다.
- 원작 게임과 파생 게임의 구분을 위한 origin_or_variant 컬럼이 존재한다.
- 파생 게임의 경우 원작 게임이 어떤 것들이 있는지를 저장할 origin_game 테이블 별도로 존재한다.
- 태그들을 저장할 테이블을 game_tag Table로 별도로 둬 무결성을 지킨다.

resource
- 등록된 게임에서 판매 또는 공유할 리소스를 저장할 테이블
- game Table과 마찬가지로 개발자 재량으로 이미지 및 다운로드URL를 제공하도록 별도 테이블로 존재한다.

transaction
- 거래 목록을 담당하는 테이블
- 무결성을 위해 게임 거래와 리소스 거래를 구분하여 각각 테이블로 존재한다.

report
- 유저가 약관위반 등 플랫폼에 등록된 게임에 문제가 있다고 판단했을 때 신고한 내역을 저장하는 테이블
- 내용과 담당한 관리자의 정보들을 저장한다.

sended_email
- 관리자가 유저에게 알림을 보낸 정보를 기록하는 테이블

==결과 및 평가==
===완료 작품의 소개===
====프로토타입 사진 혹은 작동 장면====
◇ 메인 화면
[[파일:메인화면.jpeg]]
- 사용자에게 다양한 게임을 소개하는 LUDEX 플랫폼의 메인 페이지이다. 상단에는 로고, 검색창, 메뉴(Home, Submit Game, My Page)가 위치해 있으며, 중앙에는 대표 게임을 강조하는 배너가 배치되어 있다. 배너 오른쪽에는 장르 또는 태그별로 게임을 탐색할 수 있도록 태그 버튼들이 나열되어 있다. 하단에는 등록된 게임들이 썸네일 카드 형식으로 정렬되어 있으며, 각 게임을 클릭하면 상세 페이지로 이동할 수 있다.

◇ 게임 상세 정보 화면
[[파일:게임상세정보화면.jpeg]]
- 선택한 게임의 상세 정보를 보여주는 페이지로, 게임 플레이 화면이 슬라이드 형식으로 표시되며, 오른쪽에는 게임 제목, 가격, 제작자, 설명, 장르 태그, 구동 사양 등의 정보가 제공된다. 또한 왼쪽 하단에는 해당 게임의 파생 게임 상세 페이지로 이동할 수 있는 썸네일 이미지가 표시된다. 하단에는 “Buy” 버튼이 있어 사용자가 게임을 구매하거나 이전 화면으로 돌아갈 수 있다.

◇ 검색 화면
[[파일:검색화면.jpeg]]
- 상단의 검색창에 검색어를 입력하거나, 메인 화면에서 태그를 클릭하면 진입하는 검색 화면이다. 입력된 검색어는 태그, 게임명(영문/한글), 게임 설명에 속하거나 그에 유사하다 판단되는 항목들과 매치되어 관련된 태그 또는 게임이 검색 결과로 나타난다.

◇ 결제 화면

결제 수단 선택 모달
[[파일:결제방법선택화면.jpeg]]
- 게임 상세 페이지에서 “Buy” 버튼을 클릭했을 때 나타나는 결제 수단 선택 모달이다. 다양한 결제 방식을 제공하여 사용자 편의성과 접근성을 높이는 것을 목표로 한다.

전자지갑 결제 모달
[[파일:전자지갑-결제-화면.jpeg]]
- 결제 수단 선택 모달에서 결제 수단으로 전자지갑 결제를 선택한 경우 나타나는 모달이다. 블록체인 기반의 토큰(USDC)을 활용한 결제를 진행할 수 있도록 구성되어 있다.

카드 결제 모달
[[파일:카드결제-화면.jpeg]]
- 결제 수단 선택 모달에서 카드 결제를 선택했을 때 연동되는 토스페이먼츠(Toss Payments)의 카드 결제 모달이다. 실제 결제는 신용카드 및 간편결제 수단을 통해 이루어지며, 사용자는 원하는 수단을 선택 후 인증을 거쳐 결제를 완료할 수 있다.

◇ 게임 등록 화면
[[파일:게임등록화면.jpeg]]
- 게임을 플랫폼에 등록할 수 있는 게임 등록 화면이다. 게임 등록 시에는 게임 파일 뿐만 아니라 썸네일, 설명, 가격 등 게임의 메타데이터도 함께 입력하게 된다. 또한, 해당 게임에서 사용된 리소스를 함께 등록하고자 할 경우, 게임 등록 과정에서 동시에 리소스 등록도 진행할 수 있다. 리소스 등록 시에는 리소스 파일, 설명, 미리보기 이미지, 수익 분배 비율, 사용 조건, 추가 조건 등의 정보를 입력하게 된다. 여기서 설정하는 수익 분배 비율은, 이 리소스를 다른 제작자가 구매해 파생 게임을 제작 및 등록했을 경우, 해당 게임의 판매 수익을 원작자와 파생 제작자가 어떻게 나누게 될지를 결정하는 기준이 된다.

◇ 마이페이지 화면
[[파일:마이페이지-화면.jpeg]]
- 사용자의 마이페이지 화면으로, 기본 정보(닉네임, 이메일, 지갑 주소)와 함께 구매 및 판매 내역, NFT 조회, 다운로드 기능, 정산(Payout) 등을 확인하고 관리할 수 있다.

구매기록 화면
[[파일:구매기록-화면.jpeg]]
- 마이페이지 내 구매 기록 상세 화면으로, 구매한 게임 리스트와 함께 각 항목의 다운로드, NFT 발급 여부를 확인할 수 있으며, 구매한 리소스에 대한 정보도 하단에 함께 표시된다

판매기록 화면
[[파일:판매기록-화면.jpeg]]
- 마이페이지 내 판매 기록 화면으로, 사용자가 등록한 게임 목록과 함께 각 게임의 가격, 설명, 이미지, 할인 설정(Set Discount) 및 수정(Edit) 기능을 확인하고 관리할 수 있다.

Web3 구매 게임 NFT 조회 모달
[[파일:nft-web3구매-화면.jpeg]]
- Web3 방식으로 구매한 게임의 NFT 발급 정보를 확인하는 팝업 화면으로, Token ID, Item ID, 구매자 지갑 주소, 구매 일시 등의 정보를 보여준다.

정산요청 모달
[[파일:정산요청-화면.jpeg]]
- 사용자가 판매 수익에 대한 정산 요청을 진행하는 화면으로, 정산할 게임과 등록된 지갑 주소를 선택한 뒤 "정산 요청" 버튼을 눌러 수익을 출금할 수 있다.

지분감면 할인 모달
[[파일:지분감면-할인-화면.jpeg]]
- 지분 감면 기반 할인 설정 팝업 화면으로, 할인 기간과 함께 감면율(%)을 입력하면 자동으로 감면된 지분이 계산된다. 설정된 감면율은 해당 게임을 기반으로 제작된 파생 게임들에 할인 혜택으로 적용된다.

◇ 관리자 화면

유저 관리 화면
[[파일:유저관리페이지.jpeg]]
- 관리자가 전체 사용자 목록을 조회하고 차단 여부를 설정할 수 있는 유저 관리 페이지로, 닉네임 또는 이메일로 검색이 가능하며 각 사용자에 대해 "set block" 기능을 통해 제재 조치를 적용할 수 있다.

게임 관리 화면
[[파일:게임관리페이.jpeg]]
- 관리자가 등록된 게임 목록을 조회하고 차단/해제할 수 있는 콘텐츠 관리 페이지로, 게임명 또는 설명을 검색해 상세 정보를 확인하고 "set block" 또는 "set unblock" 버튼을 통해 게임의 공개 여부를 제어할 수 있다.

===관련사업비 내역서===
[[파일:관련사업비내역서 중간.jpeg]]

===완료작품의 평가===
[[파일:완료작품의평가 중간.jpeg]]

===향후계획===
*어려웠던 내용들
◇ 스마트 컨트랙트 및 Web3 관련 개발 환경은 아직 인프라가 완전히 성숙하지 않은 상태라, 통합된 공식 문서를 찾기 어렵고, 자료 간의 일관성도 부족했다. Solidity 언어 자체가 아직 버전 1 이전이며, 버전에 따라 문법이나 기능이 상이한 점이 많았다. 또한 Web3 라이브러리로 사용한 ethers.js의 경우 최신 버전인 v6을 기준으로 개발을 진행했지만, 기존 문서들은 대부분 v5를 기준으로 작성되어 있어 적용에 혼선을 겪었다. 참고용으로 도서관에서 관련 교재를 대출해 공부했으나, MetaMask의 경우 교재 집필 당시에는 지원되던 기능이 우리가 학습하던 시점에서는 더 이상 제공되지 않아 학습 자료의 신뢰성에도 어려움이 있었다.

◇ Web3 외적인 부분에서도 여러 난관이 존재했다. Web3 분야가 아직 생소하고, 이미 시장에는 다양한 유사 서비스가 존재하다 보니 차별화된 방향성을 설정하는 것이 쉽지 않았다. 기획 단계에서는 상품성 있는 아이템을 도출하는 것이 가장 큰 과제였다. 프로젝트 주제에 대한 제한이 없었던 만큼, 어떤 소비자층을 타겟으로 어떤 기능과 서비스를 제공할 것인지 결정하는 데 많은 시간이 소요되었고, 유사 서비스와의 비교를 통해 차별점을 찾는 과정에서도 끊임없는 검토와 고민이 필요했다.

◇ 개발 측면에서는 백엔드 개발 경험이 두 번째인 팀원이 있어, 프로젝트 구조를 잡거나 기능을 설계하는 과정에서 시행착오가 많았다. 특히 Web3와 결합된 백엔드 구조는 일반적인 웹 개발보다 구조가 복잡하고 고려해야 할 보안 요소도 많아 학습과 구현을 병행하는 데 부담이 컸다.

◇ 서비스 간 책임 및 리소스 분리를 위해 쿠버네티스(Kubernetes) 클러스터를 도입했지만, 이 과정에서도 적지 않은 어려움을 겪었다. 기존에 사용하던 서버 인프라와 쿠버네티스 기반 인프라는 구성 방식과 운영 방식에 큰 차이가 있었고, 특히 CI/CD 파이프라인을 새롭게 구축하는 과정에서 설정 방식과 배포 방식의 차이로 인해 시행착오가 반복되었다. 클러스터 내 서비스 간 연결, 환경 변수 관리, 볼륨 설정 등 인프라 레벨의 개념들이 익숙하지 않아 초기 세팅과 디버깅에 많은 시간이 소요되었다. 결과적으로 이는 개발보다 인프라 운영 측면에서 예상보다 더 많은 리소스를 요구하는 작업이었다.

◇ 팀 내 일부 구성원이 게임 산업에 대한 경험이 부족했던 점도 기획과 UX 설계에 영향을 미쳤다. 게임을 평소 즐기지 않다 보니, 소비자 입장에서 어떤 요소가 매력적으로 작용할지 예측하기 어려웠고, 사용자 니즈나 시장 흐름에 대한 인식이 낮아 기능 제안이나 설계에 확신을 가지기 힘들었다. 결과적으로, 기술적인 문제뿐만 아니라 콘텐츠 기획과 소비자 이해도 측면에서도 다방면의 고민이 필요한 프로젝트였다.

*차후 구현할 내용
◇ 개발자간 수익 분배 기능 확장
- 인디게임은 소규모 개발자 또는 법인 간의 협업이 빈번하게 이루어지는 구조다. 그러나 현재의 수익 분배 방식은 플랫폼으로부터 수익을 수령한 팀 리더가 이를 팀원에게 개별적으로 분배하는 형태로, 신뢰성 부족과 함께 리더에게 장기간의 관리 책임이 과도하게 부여된다는 단점이 있다. 특히 게임 수익이 수년, 혹은 수십 년간 발생할 수 있다는 점에서 리더 개인에게 지속적인 관리 책임이 부담으로 작용한다. 현재 itch.io나 Game Jolt 등 인디게임 중심 플랫폼에서는 이러한 협업 구조에 적합한 수익 분배 시스템을 제공하지 않는다. 이는 기술적인 제약 때문인데, 예컨대 Web2 기반의 금융 인프라는 소액 정산 시 건당 수수료가 발생하는 구조여서 효율적인 분배가 어렵다. 또한 에스크로 방식의 경우, 거래 기록을 데이터베이스 상에서 관리하고 별도의 확인 절차를 요구하는 번거로움이 존재한다. Ludex는 이러한 문제를 이더리움 기반 스마트 컨트랙트를 통해 해결할 수 있다. 스마트 컨트랙트는 본질적으로 신뢰 가능한 에스크로 역할을 수행하며, 소액 정산의 경우에도 고정된 건당 수수료가 아닌 연산 비용 기반의 수수료 구조이기 때문에 경제적이다. 아울러 컨트랙트 구현 난이도도 낮아, 비교적 빠른 시간 안에 해당 기능을 플랫폼에 확장 적용할 수 있다

◇ 게임 등급 분류 제도 대안책 BM 확장
- 대한민국에서는 게임을 유료로 배포하기 위해 게임물관리위원회의 등급 분류를 반드시 받아야 한다. 이 제도는 일종의 사전 검열로 기능하며, 절차의 복잡성이나 높은 수수료로 인해 인디 개발자들에게는 진입장벽으로 작용하고 있다. 특히 일부 게임의 경우 심의 수수료가 100만 원을 넘기기도 하여 영세 개발자들에게 큰 부담이 된다. 이러한 문제를 해결하기 위해 Ludex는 예치금 기반의 예약 구매 시스템을 제안한다. 이 시스템은 판매가 개시되기 전, 소비자가 구매 대금을 컨트랙트에 예치하고, 게임이 등급 분류를 마친 이후에야 예치금이 개발자에게 전달되는 구조다. 이 과정에서 발생하는 수익은 등급 분류 이후에 인식되므로, 제도적 검열을 우회할 수 있는 가능성이 존재한다. Ludex는 이와 함께 자사의 수수료 수익도 예치 상태로 유지하며, 예치금이 일정 수준 이상 쌓일 경우에는 심의 신청을 대행하는 방식으로 인디 개발자를 지원할 수 있다. 다만, 이러한 방식은 법적 리스크가 존재하므로, 전문적인 법률 검토를 거친 뒤 적법성이 확보된 경우에만 진행된다. 만약 합법성이 확보되면, 온라인 신문 및 인디게임 커뮤니티를 통해 본 시스템을 널리 홍보할 계획이다. 구현 측면에서는 기존 스마트 컨트랙트에 소폭 수정만 가하면 되므로 기술적 난이도는 낮은 편이다.

*프로모션 방안
◇ 온라인 게임잼 개최
- 게임잼은 인디게임 개발자들이 48~72시간 동안 주어진 주제에 따라 짧은 기간 내 게임을 제작하는 행사로, 인디 커뮤니티에서 가장 널리 사용되는 이벤트 방식 중 하나다. Ludex는 UGC(사용자 제작 콘텐츠) 확장성을 주제로 반년에 한 번씩 총 세 차례 게임잼을 개최할 계획이다. 특히 두 번째와 세 번째 게임잼에서는 첫 번째 게임잼에서 제작된 게임을 기반으로 한 파생 게임 부문을 별도로 마련하여 2차 창작 생태계의 활발한 형성을 유도한다. 이와 같은 파생 게임에 대한 출품 조건은 플랫폼의 정식 출시 이후부터 적용될 예정이다.

◇ 플레이엑스포 2026 부스 참여
- 플레이엑스포는 매년 참가 기업 수와 방문객 수가 증가하고 있는 국내 주요 오프라인 게임 전시회다. 특히 2026년 기준으로는 약 11만 5천 명의 관람객과 721개의 게임 관련 기업이 참여하는 등 그 규모가 상당하다. 다른 대형 전시회인 지스타가 대기업 중심인 것과 달리, 플레이엑스포는 인디게임 친화적인 전시회로서 인디게임 전용관 운영과 같은 실질적인 지원을 제공하고 있다. 또한 게임 출품 기업뿐 아니라 게임 관련 기술 및 플랫폼 기업도 부스를 신청할 수 있어, Ludex와 같은 플랫폼 사업자에게도 적합한 전시 기회가 된다. 반면 부산인디커넥트와 같은 일부 전시회는 게임 출품 기업에 한정해 참가 자격을 부여하므로, 이번 기회에 플레이엑스포를 전략적 홍보 채널로 삼는 것이 적절하다. 부스 운영 방안으로는 게임잼 출품작 중 파생 게임이 존재하는 작품들을 직접 체험할 수 있는 플레이존을 제공할 계획이다. 또한 ‘아이디어잼’이라는 참여형 코너를 통해, 방문객이 제시된 주제에 따라 메모지로 게임 아이디어를 적고 이를 보드에 붙이는 방식의 콘텐츠를 마련한다. 나아가 아이디어 간 파생 관계를 구성하여 연결할 수 있게 하고, 심사를 통해 선정된 아이디어의 제안자와 그 파생 아이디어 제공자 모두에게 상품을 수여함으로써 Ludex의 2차 창작 철학을 효과적으로 전달하고자 한다.

◇ Google Display Network(GDN)
- Google Display Network(GDN)는 전 세계 200만 개 이상의 웹사이트, 앱, 유튜브 등 다양한 온라인 채널을 통해 광고를 노출할 수 있는 구글의 디스플레이 광고 플랫폼이다. Ludex는 게임 2차 창작이라는 독창적 시장 포지션을 기반으로, 해당 차별점을 적극적으로 부각하는 방향으로 GDN을 활용할 계획이다. 특히 CPC(클릭당 과금) 방식보다는 브랜드 인지도 제고에 초점을 맞춘 CPM(노출 1,000회당 과금) 방식을 채택하여, 개발자 및 게임 유저 커뮤니티를 중심으로 플랫폼 인식을 확산시키는 것이 핵심 전략이다. 이는 신규 유저 유입보다는 초기 브랜드 포지셔닝과 업계 내 존재감 확보를 우선시하는 마케팅 방향성과도 부합한다. GDN을 통해 주 타겟은 게임 개발자 관련 블로그, 인디게임 커뮤니티, 게임 유저 대상 매체 등을 중심으로 설정할 예정이며, 시각적 임팩트가 큰 배너와 명확한 가치 제안을 통해 Ludex의 브랜드 이미지를 강화하고자 한다.

1분반-Locauto

2026-03-11T07:33:56Z

Adcdc: Adcdc (토론)의 12609판 편집을 되돌림

<div>__TOC__</div>

==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 : ''' SMB 소프트웨어 비즈니스를 위한 간편한 랜딩페이지 로컬라이제이션 툴

''' 영문 : ''' Easy landing page localization tools for SMB software businesses

===과제 팀명===
Locauto

===지도교수===
이경재 교수님

===개발기간===
2025년 3월 ~ 2025년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 컴퓨터과학부 20199200** 정*혁(팀장)

서울시립대학교 컴퓨터과학부 20199200** 정*호

서울시립대학교 컴퓨터과학부 20199200** 최*훈

서울시립대학교 컴퓨터과학부 20209200** 이*우

==서론==
===개발 과제의 개요===
====개발 과제 요약====
* SMB 소프트웨어 비즈니스를 위한 간편한 프로덕트 로컬라이제이션 툴이다.
* 사용자는 CLI 및 WEB GUI을 조작하여 코드를 적용하여 페이지를 변환하고, SDK가 자동으로 번역 결과를 렌더링한다.
* 웹앱을 통해 번역의 세부 사항 및 기타 설정을 변경한다.

====개발 과제의 배경 및 효과====
* SMB는 글로벌 진출 기회를 이용하고 싶으므로, 로컬라이제이션을 하고 싶어 한다.
* 그러나 '로컬라이제이션'이라는 과정은 굉장히 노동집약적이므로, 소규모의 소프트웨어 비즈니스는 리소스가 부족하다고 느낀다.
* 본 프로젝트를 이용하면 ‘로컬라이제이션’의 과정을 자동화하여 코드 수정, 번역, 적용의 단계를 10분 안에 마칠 수 있다.
* 브랜드와 문맥, 사용자 설정을 반영하는 AI 번역 서비스로 오류 없는 메시지를 명확히 전달한다.
* 다만 모든 IT 프로덕트를 번역하는 서비스로 만들기에는 ‘컴퓨터과학종합설계’ 내에서는 어려우므로, 랜딩페이지에 집중하여 우선적으로 개발하려고 한다.

====개발 과제의 목표 및 내용====
'''목표'''
* 자동화된 로컬라이제이션 환경 구축을 위한 CLI, SDK, 웹앱 개발
* AI를 활용한 브랜드 톤 및 용어의 일관성 있는 자동 번역 제공
* 번역 품질과 현지화 정확도 향상 및 관리 효율화
* 쉽고 빠르게 사용 가능한 사용자 인터페이스 제공

'''CLI 개발'''
* <code>localize init</code>: 번역 프로젝트 초기화
* <code>localize extract</code>: 프로젝트의 문자열 데이터를 추출 및 문자열 데이터를 비교하여 변경사항 추적
* <code>localize push</code>: 프로젝트 디렉토리의 추출된 문자열 데이터를 서버에 전송
* <code>localize pull</code>: 서버에서 최신 번역 데이터를 받아 프로젝트 파일 내 저장
* <code>localize apply</code>: 코드베이스를 읽으면서 문자열 자동 업데이트
* <code>localize translate</code>: 서버에서 최신 번역 데이터를 받아 프로젝트 파일 내 문자열 자동 업데이트

'''SDK 개발'''
* 초기화 시 사용자 locale 설정
* TypeScript 타입 자동 생성 및 로컬라이제이션 파일 export
* 언어 변경 기능 수동 제공
* Next.js 프레임워크를 우선적으로 적용

'''서버 개발'''
* CLI에서 전송된 데이터 수신 및 구조화 매핑
* 번역 데이터 버전 관리 및 변경사항 추적
* 웹앱 대시보드를 위한 CRUD API 제공
* AI 번역 모델과 연계하여 문맥 기반 자동 번역
* 텍스트 유형(제목, 버튼, 설명 등)에 따라 최적화된 번역 프롬프트 개발

'''대시보드 개발'''
* 언어별 번역 데이터 입력 및 저장
* 향후 검색 및 필터링 기능 확장 가능 구조 마련

===관련 기술의 현황===
====관련 기술의 현황 및 분석====
가. State of art

* '''자동 기계번역''': 신경망 기계번역(NMT)의 품질 향상으로, 번역 워크플로우에 자동 번역을 도입하는 것이 일반화되었다. 2024년 기준 전체 번역 작업의 70%가 기계 번역의 도움을 받는 형태로 진행되고 있을 정도로 확대되었으며, 이는 전년 대비 크게 증가한 수치이다. 기업들은 번역 초안을 AI가 생성하고 인간이 후기 편집하는 MTPE(Machine Translation Post-Editing)방식으로 생산성을 높이고 있다. 특히 GPT, Claude 등 대형 언어모델(LLM)기반 번역이 전통적인 번역 엔진을 능가하는 정확도를 보이며 새롭게 주목받고 있다.

* '''코드베이스 해석기''': 리액트(React)와 타입스크립트(TypeScript) 파일을 파싱하는 최신 기술은 주로 다음과 같은 도구와 라이브러리를 활용한다.
** 타입스크립트 컴파일러 API (TypeScript Compiler API): 타입스크립트 자체에서 제공하는 컴파일러 API를 사용하여 TSX 파일을 파싱하고, 추상 구문 트리(AST)를 생성하여 코드 구조를 분석할 수 있다.
** Babel: Babel은 자바스크립트 컴파일러로, <code>@babel/preset-react</code>와 <code>@babel/preset-typescript</code> 프리셋을 사용하여 TSX 파일을 파싱하고 변환할 수 있다. 이를 통해 최신 문법을 구버전 자바스크립트로 트랜스파일하거나, 코드 분석을 위한 AST를 생성할 수 있다.
** ESLint: 코드 품질과 일관성을 유지하기 위한 린터 도구로, <code>@typescript-eslint/parser</code>를 사용하여 TSX 파일을 파싱하고, 코드 규칙을 적용하여 정적 분석을 수행할 수 있다.

나. 기술 로드맵

*'''MVP 기능 구현'''
** 웹 문자열 추출 엔진 개발: 사용자 코드베이스에서 본문 텍스트와 일부 속성값(alt, title 등)을 식별 및 추출.
** 추출된 텍스트를 구조화하여 백엔드로 전송하고 데이터베이스에 저장.
** 번역 API 호출을 통해 각 타깃 언어로 기계 번역된 초안 생성.
** 번역 완료 후, 수정된 텍스트를 코드베이스에 적용하는 기능 구현.

====시장상황에 대한 분석====

가. 경쟁제품 조사 비교

* 글로벌 SaaS 스타트업을 위한 랜딩페이지 로컬라이제이션 툴과 유사한 기능을 제공하는 주요 경쟁 제품으로 Lokalise, Crowdin, Localazy, POEditor 등이 있으며, 자동 번역 엔진으로 Google Translate와 DeepL도 활용되고 있다.
* '''vs 자동 번역 엔진'''
: 자동 번역 엔진은 Google Translate, DeepL과 같은 전문 번역 툴을 의미한다.
: Pros: 자동 번역 엔진은 일반적인 상황에서 높은 번역 품질을 자랑하고 광범위한 언어 지원한다
: Cons: 맥락 고려 부족으로 어색한 번역이 존재한다. 전문용어/업계용어 정확도 한계가 존재하며, 브랜드가 원하는 톤앤 매너로 일관성있게 번역하기 힘들다.
* '''vs 로컬라이제이션 툴'''
: 로컬라이제이션 툴은 Lokalise, Crowdin 같은 앱의 에셋을 관리 및 번역을 도와주는 툴을 의미한다.
:- '''Lokalise'''
:: Pros: 많은 통합 기능과 풍부한 기능 세트, 포괄적인 지원 옵션(이메일/헬프 데스크, 채팅, 지식 베이스, 24/7 실시간 지원 등)을 제공한다.
:: Cons: SMB가 진입하기에는 가격이 높다. 소규모 프로젝트에는 과복잡한 기능 셋이다.
:- '''Crowdin'''
:: Pros: 오픈소스 프로젝트로 스타트업 개발자에게 친숙한 이미지를 쌓았고, 600여개의 통합을 내세워 자동화/개발 워크플로우에 강점이 있다.
:: Cons: 신속한 초기 설정이 불가능하다. 개발자나 일일히 코드베이스에서 sdk 문법에 따라서 작성해줘야한다. 따라서 작은 규모의 스타트업이 제대로 도입하기 위해서는 허들이 있다.
[[파일:Locauto1.png]]

나. 마케팅 전략 제시

* '''포지셔닝''': 경쟁사들은 각자 대상 고객(대기업/스타트업/개인)과 강조 포인트(풍부한 기능 vs 자동화 vs 가격 등)이 다르다. 우리 제품은 SMB를 위한 간편한 로컬라이제이션이라는 컨셉에 맞게, 쉬운 사용성, 즉각적인 결과(자동 번역), 가성비 등을 전면에 내세워 마케팅한다. 이를 통해 글로벌 시장을 노리는 스타트업에게 “낮은 진입장벽의 필요한 기능만 담은 최적화된 솔루션”으로 포지셔닝한다.

* '''초기 시장 진입 채널''': 소규모 개발자들을 타겟하고 있으므로 인스타그램, 쓰레드, geek news 등의 마케팅 채널을 타겟팅한다.

===개발과제의 기대효과===
====기술적 기대효과====
* 본 프로젝트를 통해 개발되는 로컬라이제이션 툴은 기존 대비 뛰어난 자동화 수준과 사용자 경험을 제공함으로써 여러 기술적 혁신을 이끌 것으로 기대한다.
* '''높아진 자동화로 인한 생산성 향상'''
: 기존 툴에서는 개발자가 소스 문구를 추출하고, 번역 완료 후 수동으로 사이트에 반영하는 작업이 필요했다. 반면 본 제품은 이러한 과정을 자동화하여, 번역 필요 문구 감지 → 기계번역 → 편집까지의 사이클을 최소한의 인력 개입으로 완료한다. 이를 통해 IT 프로덕트를 다국어로 개설하는 데 걸리는 시간이 획기적으로 단축된다 (과거 수일 소요 작업을 몇 시간 내로 단축).
* '''사용 편의성 혁신'''
: 기술적으로 아무리 뛰어나도 최종 사용자가 어려움을 느끼면 도입이 망설여진다. 본 제품은 진입장벽을 최소로 빠르게 적용할 수 있는 쉬운 UI/UX를 지향하여, 소규모 스타트업에서도 쉽게 직접 다국어 페이지를 만들 수 있게 된다. 이는 곧 기업 로컬라이제이션 프로세스의 보편화로 이어져, 프로덕트의 글로벌 대응이 가능한 업무 혁신을 가져온다

====경제적, 사회적 기대 및 파급효과====

* IT 프로덕트에 번역을 도와주는 솔루션으로 발전되었다고 가정해본다.
: 여러 조사에 따르면 전 세계적으로 약 3만 800여 개의 SaaS 기업이 활동 중이며, 그중 절반 이상은 직원 10명 미만의 소규모 팀으로 이루어진 스타트업들이다.
: 이러한 시장에서 기업들의 예상 사용량을 다음과 같이 추산할 수 있다.
:: 가격 모델은 월 $20의 구독료에 번역 사용량 기반 요금이 추가되는 형태라고 가정한다.
:: 이를 고려하여 고객당 연간 수익을 산정하면 다음과 같다.
:: 우선 기본 구독료로 연 $240의 고정 수익이 발생한다. 한 고객당 3개 언어로 500단어씩 단어당 $0.02를 사용한다고 가정하면 약 $30의 번역 사용량 요금이 발생한다.
:: 5%의 기업이 사용한다고 가정하면 ($240 + $30) * 30800 * 0.05 = $415,800의 연간 반복 수익이 일어날 것으로 예상된다.

===기술개발 일정 및 추진체계===
====구성원 및 추진체계====

* 정민혁 (팀장) : 프로젝트 총괄 및 Web GUI, CLI/SDK 개발
* 정인호 : CLI/SDK 개발
* 최용훈 : 백엔드 개발
* 이종우 : AI, Web GUI 개발

==설계==
===사용자 요구사항===

MVP 개발에 선택된 사용자 요구사항

* <code>R1</code>: 프로젝트 설정 & 코드 연결
* <code>R2</code>: 프로젝트 생성 및 관리
* <code>R3</code>: 계정 및 인증 관리
* <code>R4</code>: 번역 테이블 편집 및 관리
* <code>R5</code>: AI 기반 자동 번역 요청
* <code>R6</code>: 브랜드 번역 룰 관리
* <code>R7</code>: 용어집(Glossary) 관리
* <code>R8</code>: 번역 리뷰 및 수정 → AI 학습 반영
* <code>R9</code>: 번역 적용 및 배포 (CLI or SDK)

{| class="wikitable"
|-
! 번호
! 요구사항
! 중요도
! 비고
|-
| 1
| 다국어 지원
| 대
| MVP 제작
|-
| 2
| 수정을 위한 웹 애플리케이션 제공
| 대
| MVP 제작
|-
| 3
| 브랜드 톤 학습 번역 기능(용어집)
| 대
| MVP 제작
|-
| 4
| CLI 제공
| 대
| MVP 제작
|-
| 5
| SDK 제공
| 대
| MVP 제작
|-
| 6
| 다양한 파싱 엔진 제공
| 중
| 희망
|-
| 7
| 기계 번역 API 연동
| 중
| 희망
|-
| 8
| 실시간 미리보기
| 중
| 희망
|-
| 9
| 외부 에이전시 협업 기능
| 소
| 희망
|-
| 10
| 분석 및 리포팅
| 소
| 희망
|-
| 11
| SEO 최적화 프롬프팅 지원
| 소
| 희망
|}

===사용자 요구사항 만족을 위한 기능 정의===

기능 정의
* <code>F1: 번역 대상 문자열 추출</code>
: CLI를 실행해 번역 프로젝트를 로컬 코드베이스에 연동함
: 코드베이스에서 문자열(StringLiteral, JSXText 등)을 AST로 추출함
: 추출된 번역 대상 문자열을 서버에 전송해 저장함
* <code>F2: 번역 프로젝트 초기화</code>
: CLI에서 lingotuner init 명령어를 이용하여 번역 프로젝트 초기화
: Web App에 로그인하여 새로운 프로젝트를 생성함 (이름, 기본 언어 지정)
: 기존 프로젝트 목록을 조회하고, 최근 업데이트 상태를 확인함
: 프로젝트 이름, 언어 설정 등을 수정하거나 삭제함
: 각 프로젝트별로 언어별 번역 상태를 시각적으로 파악함
* <code>F3: 마이페이지</code>
: 로그인한 사용자는 자신의 프로필, 이메일, 요금제(Plan)를 조회함
: 인증 토큰을 발급받아 CLI 연동 시 사용함
* <code>F4: 번역 테이블 편집 및 관리</code>
: 프로젝트별 문자열 리스트(원문, 번역)를 테이블 형태로 확인함
: 각 row를 수동으로 수정하거나 직접 번역을 입력함
: AI 번역 버튼을 통해 한 row 또는 전체 column을 자동 번역함
: 번역 대상 언어를 추가함 (예: 영어 → 한국어, 일본어 등)
* <code>F5: AI 기반 자동 번역 요청</code>
: 번역할 텍스트와 브랜드 룰을 함께 AI에게 전달함
: AI는 LLM을 사용해 다국어 번역을 생성함
: 프롬프트 체인을 통해 브랜드 톤 및 용어집을 반영함
: 결과는 테이블에 자동 반영되고, 사용자가 최종 수동 수정 가능함
* <code>F6: 용어집(Glossary) 관리</code>
: 브랜드 고유명사, 기술 용어 등 번역 일관성이 중요한 단어들을 등록함
: 다국어 용어 맵핑 테이블로 관리하며 수정, 삭제 가능함
: 번역 시 AI가 용어집 우선 적용을 하도록 반영함
* <code>F7: 번역 적용 및 배포 (CLI or SDK)</code>
: CLI에서 apply 명령을 실행해 번역 완료 데이터를 코드베이스에 적용함
: SDK를 사용하는 앱에서는 앱 로딩 시 번역 데이터를 자동으로 불러옴

===기능 구현을 위한 세부기술 선택사항 (디자인)===
'''Server'''
* Framework: <code>Spring Boot 3.4.3</code>
* ORM: <code>Spring Data JPA</code>
* 인증: <code>Supabase Auth</code>
* DB: <code>PostgreSQL</code>

'''번역 AI'''

[[파일:Locauto2.png]]

* 사용 프레임워크 & 사용 기술
: - <code>LangChain</code>
: - <code>GPT-4.1</code>

'''Dashboard'''

[[파일:Locauto3.png]]

* 사용 프레임워크 & 사용 기술
: - <code>Next.js</code>
: - <code>TypeScript</code>
: - <code>Tailwind</code>

'''CLI'''

[[파일:Locauto4.png]]

* 사용 프레임워크 & 사용 기술
: - <code>Next.js(ESM)</code>
: - <code>Babel Parser & Traverse</code>
: - <code>JSX/TSX 문법 분석을 위한 AST사용</code>
: - <code>Commander.js (CLI command router)</code>
: - <code>Keytar (OS 레벨 키 저장)</code>
: - <code>Apply를 위한 LLM</code>

===시스템 설계===

[[파일:Locauto5.png]]

* <code>CLI</code>
: 터미널 인터페이스를 통해 서버의 데이터베이스에 있는 번역 프로젝트를 연결하여 데이터를 가져올 수 있는 커맨드를 제공함
: 주로 코드 베이스에 있는 String들을 추출하고 이를 대체하는 기능을 제공함

* <code>WEB APP (Frontend)</code>
: 번역될 데이터들을 관리할 간편한 웹 어플리케이션
: 관리자가 이용하기 쉽도록 GUI를 구성하여 사용할 수 있는 기능을 제공함

* <code>SERVER (Backend)</code>
: 번역 데이터 및 원본 데이터 저장
: CLI/WEB-APP/AI에서 사용할 API들을 노출함

* <code>AI</code>
: 브랜드 톤 앤 매너 학습 및 번역 기능 제공
: 멀티 에이전트로 높은 번역 품질을 제공함
: 사용자 Rule 및 용어집 학습으로 브랜드 최적화된 번역 제공

===이론적 계산 및 시뮬레이션===

* '''Codebase에서 적절한 String을 자동으로 뽑아내기'''

: '''목표''': AST(Abstract Syntax Tree)를 기반으로 소스 코드에서 번역 대상 String을 자동으로 추출한다.
: [[파일:Locauto6.png]]

: '''이론적 배경 및 계산''': 현Typescript 및 React 계열의 프레임워크만 지원할 예정이므로 1개의 언어만 지원한다고 가정한다. TypeScript의 Compiler API나 Babel을 활용하여 코드로부터 AST를 생성한 뒤, 특정 노드 유형(StringLiteral, JSXText, JSXAttribute)을 타겟하여 추출한다. 이를 통해 룰 기반으로 특정 조건을 정의할 수 있으며 String 연산 등 정적 분석으로 불가능한 부분은 MVP 단계에서 고려하지 않는다.

* '''AI에서 높은 품질의 번역 생성하기'''

: '''제약 조건을 고려한 프롬프트 체인''': 중요 키워드나 용어의 정확한 번역을 보장하기 위해, LLM은 특정 제약 조건을 부여하는 프롬프트 체인을 활용하여 번역의 충실도를 높일 수 있다.

: [[파일:Locauto7.png]]

: '''용어집 반영 및 수정 메커니즘''': LLM은 생성된 번역문을 자체적으로 분석하여 오류나 부정확한 부분을 식별하고, 이를 기반으로 수정된 번역문을 생성할 수 있다. 이 과정에서 용어집의 데이터를 참고하고, 맥락을 고려하여 보다 자연스럽고 정확한 번역을 추구한다.

===하드웨어 설계===
* 소프트웨어 시스템으로, 별도의 물리적 하드웨어 설계가 요구되지 않는다.

===소프트웨어 설계===
'''Backend(Spring Boot 3.4.3)'''

* 주요 엔티티: User, Project, Asset, Label

* ORM: Spring Data JPA (with QueryDSL)

* 인증: Supabase Auth JWT 인증 → Spring Security Filter 연동

* '''REST API 구조:'''
{| class="wikitable"
! Controller
! Method & Endpoint
! 설명
|-
| rowspan="4" | account-key-controller
| GET /api/account-keys
| key 조회
|-
| POST /api/account-keys
| key 생성
|-
| GET /api/account-keys/projects
| 계정 프로젝트 목록
|-
| DELETE /api/account-keys/{accountKeyId}
| account key 삭제
|-
| rowspan="4" | glossary-controller
| PUT /api/projects/{projectId}/glossaries/{glossaryId}
| 단어집 수정
|-
| DELETE /api/projects/{projectId}/glossaries/{glossaryId}
| 단어집 삭제
|-
| GET /api/projects/{projectId}/glossaries
| 단어집 조회
|-
| POST /api/projects/{projectId}/glossaries
| 단어집 생성
|-
| rowspan="2" | cli-controller
| POST /api/cli/{projectId}/localize
| CLI 용 번역
|-
| POST /api/cli/projects
| 프로젝트 생성
|-
| rowspan="5" | project-controller
| GET /api/projects
| 프로젝트 리스트 조회
|-
| POST /api/projects
| 프로젝트 생성
|-
| GET /api/projects/{id}
| 단일 프로젝트 조회
|-
| DELETE /api/projects/{id}
| 프로젝트 삭제
|-
| PATCH /api/projects/{id}
| 프로젝트 정보 수정
|-
| rowspan="2" | pull/push-controller
| POST /api/push
| CLI PUSH
|-
| GET /api/pull/{projectId}
| CLI PULL
|-
| resource-controller
| GET /api/resources/assets/{projectId}/{locale}
| project locale 에셋 추출
|-
| rowspan="2" | rule-controller
| GET /api/projects/{projectId}/rules
| 프로젝트 번역 규칙 조회
|-
| PUT /api/projects/{projectId}/rules
| 프로젝트 번역 규칙 수정
|-
| rowspan="4" | table-controller
| PUT /api/projects/{projectId}/tables/rows/{rowId}
| 테이블 ROW 직접 수정
|-
| POST /api/projects/{projectId}/tables/localize
| 테이블 localize
|-
| POST /api/projects/{projectId}/tables/columns
| 테이블 COLUMN 추가
|-
| GET /api/projects/{projectId}/tables
| 번역 테이블 조회
|-
| user-controller
| POST /api/users
| user 생성
|}

'''CLI Tool(Node.js)'''
* 주요 명령어
:{| class="wikitable"
|-
! 명령어
! 설명
|-
| lingotuner signin
| API 키 인증 및 저장
|-
| lingotuner init
| 프로젝트 생성/선택 및 프로젝트 키 저장
|-
| lingotuner extract
| Babel 기반 JSX 파싱, 라벨 JSON 생성
|-
| lingotuner push/pull
| REST API로 서버 전송/수신
|-
| lingotuner translate
| 프로젝트에 Push된 Asset 번역
|-
| lingotuner apply
| AI 기반 사용자 코드 수정 → 라벨 키 적용
|}
* 내부 구조: commander, @babel/core, fs-extra

'''SDK(Runtime)'''
* 역할
: 사용자 locale에 따라서 적절한 string을 불러옴
* SSR 대응
: middleware를 통해 클라이언트의 locale을 감지하여 적절한 url로 리다이렉트 및 accept-language 서버로 전달. url 및 헤더로 브라우저 언어 감지 후 context 전달

'''예외 처리 및 안정성'''
* CLI
: config 경로 오류, asset JSON 오류, 통신 실패 등 예외별 친절한 로그 제공
* Backend
: 글로벌 예외 처리기 (Spring @ControllerAdvice)
: 인증 실패, 프로젝트 미존재, 중복 라벨 등에 대한 상세 응답 코드

==결과 및 평가==
===완료 작품의 소개===
====프로토타입 사진====
<code>[번역 전]</code>

[[File: Locauto8.png]]

<code>[번역 후]</code>

[[File: Locauto9.png]]

===관련사업비 내역서===
{| class="wikitable"
! rowspan="2" | 구분
! rowspan="2" | 항목 (품명, 규격)
! rowspan="2" | 수량
! rowspan="2" | 단가
! colspan="2" | 금액(단위: 천원)
! rowspan="2" | 비고
|-
! 계
! 현금
|-
| rowspan="4" | 직접개발비
| ChatGPT (1달 기준)
| 11
| 30.1
| 331
| 331
|-
| Cursor (1달 기준)
| 1
| 29
| 201
| 201
|-
| AI 토큰 사용 비용
| 1
| 18
| 18
| 18
|-
| 합계
|
|
| 550
| 550
|
|}

===완료작품의 평가===
{| class="wikitable"
! 평가 항목
! 평가방법
! 적용기준
! 개발 목표치
! 비중 (%)
! 평가결과
|-
| 1. 처리 속도
| 번역 시작에서 적용까지 걸리는 시간 측정
| 시스템 로그 측정
| 10분 이내 완료
| 25%
| 25
|-
| 2. 용어 일관성
| 용어집 매칭률 검사
| 용어집 기준 적용 여부
| 95% 이상
| 20%
| 20
|-
| 3. 자동화 수준
| 시스템 내 개입 필요성 측정
| 시스템 작동 로그 및 인터랙션 분석
| 95% 이상 자동화
| 25%
| 20
|-
| 4. 번역 품질
| 완성된 번역본의 품질 평가
| 기계번역 상대 설문 평가
| 70% 이상
| 30%
| 25
|}

===향후계획===
'''가. 어려웠던 내용들'''
* GPT-4.1을 사용한 번역 모델에서, "+ 맥락: 소프트웨어 구독 서비스"라는 것을 번역해야 하는데, 번역하지 않고 이것을 시스템 프롬프트처럼 입력을 받는 것으로 이해하여 출력 오류가 발생하는 상황이 있었다. 따라서 <source_texts>와 같이 태그로 맥락을 구분하는 것과, 출력된 번역 결과의 label을 비교하여, 적절하게 생성되지 않거나 누락된 label만 반복하여 번역을 시도하는 방식으로 수정을 시도하였다.
* Next.js를 사용하여 사용자 대시보드를 개발하고 있다. layout.tsx에서 번역 항목을 표시하는 Table 컴포넌트를 children으로 넘기는 구조이다. 문제는, layout에서 project 데이터를 불러온 후 이 데이터를 기반으로 Table에서 값을 불러오도록 설계했는데, 실제 실행 순서를 보니 Table이 layout보다 먼저 렌더링되는 상황이 발생된다. 그 결과, project 데이터가 준비되기 전에 Table이 먼저 렌더링되어 이전 Table값이 화면이 표시되고, 깜빡임 현상도 함께 발생한다. 이 문제를 해결하기 위해, 각 페이지 진입 시 project 값을 null로 초기화하고, 데이터가 준비되면 Table이 다시 렌더링되도록 로직을 추가하여 해결하였다.
* SSR(Server Side Rendering)과 CSR(Client Side Rendering)을 함께 사용하는 현대 웹 개발 환경에서는, 동일한 코드베이스에서 국제화(i18n)를 적용하는 것이 상당히 복잡하게 느껴졌다. 특히 JSON 기반의 번역 파일을 SSR과 CSR 모두에서 일관되게 적용하려다 보니 여러 가지 문제에 직면했다. 먼저 어려웠던 점은 초기 렌더링 시점의 불일치이다. SSR에서는 서버가 HTML을 렌더링할 때 이미 번역이 적용된 콘텐츠를 만들어야 하기 때문에, 서버 코드가 정확한 언어를 인식하고 그에 맞는 번역 파일을 불러와야 한다. 반면 CSR에서는 브라우저가 JavaScript를 실행한 후 클라이언트 측에서 번역 파일을 비동기적으로 불러오고 적용하기 때문에, 서버에서 렌더링한 내용과 클라이언트가 최종적으로 보여주는 내용이 일치하지 않을 수 있다. 이를 해결하기 위해서 추가적으로 url에서 language를 주는 방법이 필요했는데, 이는 사용자가 수동으로로 설정해야할 것들이 추가되어 불안정한 것 중 하나이다.

'''나. 차후 구현할 내용'''
* 높은 번역 품질을 보장해도, 신뢰성에 대한 피드백을 잠재고객들이 제기했다. 이는 꽤 정확한 AI를 사용하더라도 인간 개입이 없으면 신뢰성을 주지 못한다. 따라서 각 지역의 원어민이나 문화를 잘 아는 번역가가 검토해주는 단계를 보장해주려고 한다. 이는 Optional하게 판매할 서비스이며 이를 위한 웹 UI가 필요하다고 판단된다.
* 현재는 랜딩페이지를 위주로 번역을 진행했다. 다만 본래 목적은 IT 프로덕트 전체를 번역을 손쉽게 도와주는 것이기 때문에 스트링 추출과정과 적용과정이 더 고도화되어야한다. 이를 위한 기술 고도화 과정이 추가적으로 필요하다.
* 현재는 Lambda 내부에서 처리량을 제한하기 위해 스프링 내부에서 sleep 및 순차 처리 방식으로 구현했으나, 이는 유휴 시간 동안 리소스를 점유하게 되어 확장성에 한계가 존재한다. 향후에는 SQS나 Kafka 등의 외부 큐 시스템을 도입하여 비동기적으로 작업을 분산 처리하고, Lambda는 큐에 쌓인 메시지를 소비(consume)하는 방식으로 전환함으로써 시스템의 안정성과 유연성을 높일 수 있다.
* 구독 등에 관련된 사용량 제한이나 과금 체계
* 현재는 asset 데이터를 서버에서 직접 받아와 클라이언트에 렌더링하고 있으나, 일반 사용자 유입이 늘어날 경우 서버 부하 및 응답 속도 저하가 우려된다. 이에 따라 이미지 및 정적 파일을 CDN을 통해 서빙하여 응답 속도를 개선하고, 서버 리소스를 효율적으로 분산할 계획이다.

===특허 출원 내용===
-

1분반-자이로드롭

2026-03-11T07:32:13Z

Adcdc:

1분반-DOS

2026-03-11T07:31:08Z

Adcdc: Adcdc (토론)의 12608판 편집을 되돌림

<div>__TOC__</div>

==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 : ''' AI 기반 개인 맞춤형 등산로 추천 시스템

''' 영문 : ''' AI-based Personalized Hiking Trail Recommendation System

===과제 팀명===
DOS

===지도교수===
김성환 교수님

===개발기간===
2025년 3월 ~ 2025년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 컴퓨터과학부 20209200** 이*영(팀장)

서울시립대학교 컴퓨터과학부 20209200** 문*서

서울시립대학교 컴퓨터과학부 20209200** 장*빈

==서론==
===개발 과제의 개요===
====개발 과제 요약====
본 과제는 산림청 및 국립공원관리공단이 제공하는 신뢰도 높은 탐방로 데이터를 기반으로, 인공지능 기술을 활용하여 개인의 체력, 취향, 등산 경험에 최적화된 등산 목적지 및 코스를 추천하고 안내하는 시스템을 개발하는 것을 목표로 한다.

초기 추천 시스템 구축을 위해 서울 지역 주요 산 4개소(북한산, 도봉산, 수락산, 관악산)를 대상으로, 설문조사를 통해 등산객 106명의 사용자 개개인의 신체 능력과 등산 경험 등을 포함한 설문조사를 실시했다. 설문조사를 통해 수집한 신체 능력 및 등산 경험에 기반하여 사용자의 적정 난이도를 계산하는 알고리즘을 회귀분석으로 구현하였으며, 비슷한 성향을 가진 사람들이 자주 방문한 목적지를 추천하는 알고리즘을 인공지능 분류 모델을 이용하여 구현했다.

또한, 사용자 맞춤형 등산로의 경우 경로 난이도를 우선으로 고려해 다익스트라 알고리즘으로 희망하는 등산로를 생성하는 기능을 구현했다. 등산로의 난이도는 등산로 정보(예: 등산로의 기울기)를 이용해 Tobler’s hiking function을 응용하여 계산하였다. 이를 바탕으로 사용자에게 적절한 난이도와 추천한 목적지, 사용자의 입산 위치와 퇴산 위치를 바탕으로 개인에 최적화된 등산로를 생성하고, 사용자의 위치에 기반하여 등산로를 안내하는 기능을 제공한다.

현재 개발 과제는 서울 지역 주요 산 4개소(북한산, 도봉산, 수락산, 관악산)에 대해서는 목적지 추천 기능까지 모두 제공하며, 대한민국의 주요 산 20여 개에 대해서는 등산로 추천 기능만 제공한다. 추후 각 산에 따른 사용자 데이터를 추가로 수집하여 범위를 확장할 계획이다.

====개발 과제의 배경 및 효과====
[[파일:Dos-등산사고-발생-요인.jpg|1200픽셀|섬네일|가운데|'''그림 1.''' 등산사고 발생 요인 (산림청 제공)]]

::최근 산림청의 조사[[#ref1|[1]]]에 따르면, 대한민국 전체 성인 남녀 중 약 78%가 한 달에 한 번 이상 등산을 즐기고 있다([[#그림_1|그림 1]]). 이처럼 등산은 국민 여가 활동의 중요한 부분을 차지하고 있다. 그러나 기존 등산 정보 제공 서비스들은 탐방로 정보의 신뢰성, 가독성, 그리고 사용자 맞춤형 추천 기능 등에서 한계를 보인다. 특히, 산림청과 같은 공공기관의 공식 데이터([[#그림_2|그림 2]])를 활용한 고품질 정보는 부족한 상황이며, 개인의 체력이나 운동 부하를 고려한 추천 시스템이 부재하여 사용자는 자신에게 적합한 코스를 찾기 어려운 실정이다.

[[파일:dos-산림청제공데이터.jpg|1200픽셀|섬네일|가운데|'''그림 2.''' 산림청 제공 데이터 예시]]

::본 과제는 이러한 문제점을 해결하고자 산림청, 국립공원관리공단의 정밀한 탐방로 데이터를 기반으로 사용자가 손쉽게 접근할 수 있는 인터페이스를 제공하며, 인공지능 기술을 통해 개인 맞춤형 등산 코스를 추천하는 시스템을 개발하는 것이다. 이 시스템을 통해 등산객들은 보다 안전하고 효율적인 코스 선택이 가능해지며, 이로 인해 개인의 안전사고 예방 효과가 기대된다.

====개발 과제의 목표 및 내용====
정확하고 신뢰성 있는 탐방로 정보 제공
:산림청과 국립공원관리공단이 제공하는 공식 탐방로 데이터를 바탕으로, 사용자에게 명확하고 신뢰성 높은 정보를 제공하고자 한다. 이를 위해 사용자 인터페이스와 정보 구조를 재정비하고, 효과적인 데이터 시각화 기법을 도입하여 정보 접근성을 향상할 계획이다.

개인 맞춤형 등산로 추천 시스템 구현

:사용자의 기본 정보, 체력 상태, 운동 부하, 선호도 등 다양한 요소를 종합적으로 분석하여 개인에게 최적화된 등산 코스를 추천하는 AI 기반 알고리즘을 개발한다. 이를 위해 머신러닝 및 딥러닝 모델을 적용하고, 사용자의 피드백을 신속하게 반영할 수 있는 동적 학습 기능을 포함할 예정이다.

지속적 시스템 개선 및 사용자 만족도 증대

:시스템 개발 완료 후에도 사용자 피드백과 평가를 지속적으로 수집·분석하여 정기적인 업데이트를 수행한다. 이를 통해 최신 정보와 최적의 추천 서비스를 제공하며, 사용자의 만족도를 지속적으로 향상하고자 한다.

구체적인 개발 단계는 우선 탐방로 데이터의 정제 및 가공을 통해 데이터베이스를 구축하는 것으로 시작된다. 이후 사용자 프로파일링과 데이터 분석을 기반으로, 등산로와 사용자의 특성을 매칭하는 AI 알고리즘을 개발하고, 이를 챗봇 및 웹 기반 서비스로 개발할 것이다. 최종적으로 사용자 테스트와 파일럿 운영을 거쳐 상용화에 필요한 기술적, 기능적 보완을 진행하여, 실제 등산객들이 안정적으로 사용할 수 있는 완성도 높은 시스템을 구현할 예정이다.

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
등산로의 난이도 측정 알고리즘
:- 지형 데이터를 수치화하여 난이도를 정량적으로 산출하는 알고리즘이 활발히 연구되고 있음.

:- Naismith의 법칙을 기반으로 하면 상승 고도와 수평 거리의 시간적 등가성을 계산할 수 있음[2].

:- Tobler 함수는 경사에 따른 보행 속도를 지수 함수로 모델링해, 경로 탐색과 최적화에 활용됨[3].

추천 시스템
:- 추천 시스템은 다양한 응용 서비스 분야에서 활발히 사용되고 있다.

:- 최근 연구들은 콘텐츠 기반 필터링, 협업 필터링 등 다양한 추천 모델을 활용하고 있음 [4].

:- 특히, 설문조사나 사용자 행동 데이터를 기반으로 한 개인화 추천 시스템이 각광받고 있음 [4].

사용자 위치 기반 경로 안내 기술
:- GPS, 고도계 등의 복합 센서를 활용해 실시간 사용자 위치를 추적하는 기술이 개발됨.

:- 그러나, 실제 등산로와 사용자 방향을 실시간으로 분석해 비교하는 기술은 아직 존재하지 않음.

등산로 데이터 가공 및 시각화 기술

:- 산림청에서는 등산로 데이터를 개방데이터로 공개하고 있음

===기술 로드맵===
1단계: 데이터 수집 및 구조화
:- 산림청 데이터를 정제하고, 필요 정보(경도, 위도, 경로 특성 등)를 추출하여 구조화된 DB 구축
:- 사용자 정보를 수집하기 위한 설문 시스템 기획 및 구축
2단계: 기초 알고리즘 개발
:- Naismith 및 Tobler과 같은 실제 등산로 기반 난이도 산정 알고리즘 구현
:- 기본적인 목적지 및 경로 추천 알고리즘 프로토타입 개발
:- geojson 기반 등산로 시각화 모듈 제작
3단계: 개인화 및 실시간 시스템 통합
:- 사용자 운동 경험, 연령, 희망 난이도 등 특성 기반 추천 시스템 고도화 (머신러닝 적용)
:- 난이도 예측 알고리즘과 사용자 선호도 매칭을 통한 개인 맞춤형 경로 추천 기능 구현
:- 실시간 경로 안내 알고리즘 구현

===특허 조사===
등산 내비게이션 단말 시스템 및 이를 이용한 등산 코스 안내 운영 방법
:- GPS 수신기와 산악 전자지도 DB를 내장한 휴대용 등산 내비게이션 단말기를 이용해 안내
산림 빅데이터 플랫폼에 기반하여 데이터 상품을 제공하는 장치 및 방법
:- 트레킹부터 시작하여 산림 빅데이터를 사용할 때 시스템의 구성에 관한 특허

===특허 전략===
사용자 맞춤의 구체적인 방식에 대한 차별화 전략
:- 기존 특허가 포괄적으로 ‘산림 빅데이터’와 ‘사용자 맞춤 서비스’까지 청구항으로 포함하고 있어, 동작 과정의 구체적인 방식에 주목해 차별화를 시도할 예정임

구체적인 청구 전략
:- Naismith, Tobler 등 복수의 등산 시간/속도 모델을 활용해 등산로의 난이도를 산정할 수 있음
:- 운동 경험, 연령, 성별, 선호 강도를 통해 사용자의 희망 난이도를 산정할 수 있음
:- 등산로의 난이도와 사용자의 희망 난이도를 매칭하여 경로를 추천할 수 있음

===관련 시장에 대한 분석===
====경쟁제품 조사 비교====
네이버 지도
:'''장점'''
::- 서비스의 인터페이스가 사용자 친화적이다.
::- 사용자의 리뷰를 볼 수 있다.
:'''단점'''
::- 경사도, 통제 등의 상세한 등산로 정보를 제공하지 않는다.
::- 코스 정보가 구간 단위로 파편화되어 있어 사용자가 전체 등산로에 대한 정보를 알기 어렵다.

국립공원공단 홈페이지
:'''장점'''
::- 상세한 등산로 정보를 제공한다.
::- 정확한 등산로 정보를 제공한다.
:'''단점'''
::- UI의 가독성이 떨어진다.
::- 같은 등산로에 대한 정보가 여러 페이지에 흩어져 있어 사용자가 등산로 정보를 한눈에 알아보기 힘들다.
트랭글
:'''장점'''
::- 실제 사용자 데이터를 기반으로 등산로 데이터를 제공한다.
::- Gamification을 통해 사용자에게 등산에 대한 동기를 부여한다.
:'''단점'''
::- 등산로 데이터를 사용자가 직접 입력하기 때문에 정보의 신뢰성이 부족하다.
::- 비인기 코스에 대한 등산로 정보가 부족하다.
::- 핵심 기능(예: Gamification)을 유료로 제공하고 있다.

====마케팅 전략====
좋은 사용성을 유지하면서도 정확하고 자세한 등산 경로를 추천하는 서비스를 제공한다.
:- 네이버 지도의 경우는 좋은 사용성을 가졌으나 전체 등산로 정보를 알기 어렵다.
:- 국립공원공단 홈페이지는 정확하고 자세한 등산 경로를 제공하나, 사용성이 나쁘다.
:- 트랭글은 사용성이 좋으나, 정보의 신뢰성이 부족하다.
:- 우리 서비스는 선행 서비스를 따라잡기 위하여 좋은 사용성에 대한 점검을 철저히 할 계획이다.
사용자 개개인의 특성 및 난이도에 맞추어 정보를 제공한다.
:- 사용자 개개인의 특성에 기반하여 등산 목적지를 추천한다.
:- 사용자의 운동 수준 및 희망 수준, 등산 목적지를 고려하여 등산로를 생성하여 제공한다.
:- 이는 선행 서비스에서 제공하지 않는 부분이다.
등산로에 대한 정확한 정보를 적절하게 제공한다.
:- 산림청에 따르면 많은 산악사고가 등산로에 대한 정보 부족 때문에 발생한다[[#ref1|[1]]].
:- 잠재적 사용자(예: 등산객)를 대상으로 조사해본 결과, 블로그 등의 신뢰성을 보장할 수 없는 출처에서 등산로 정보를 얻는다는 점을 발견했다.
:- 또한, 등산로 내 표지판 부족으로 다른 등산객들이 직접 표지판을 만드는 경우도 많다.
:- 산악구조대 소속 전문가 인터뷰 결과, 등산로의 방향을 적절한 때에 제공하면 등산 중 사고가 줄어들 것이라는 의견을 받았다.

:위의 마케팅 전략을 바탕으로, 우리는 다음과 같은 기능을 제공한다.
::- 사용자 정보 입력 기능
::- 사용자 맞춤형 등산 목적지 추천 기능
::- 사용자 맞춤형 등산로 생성 기능
::- 등산로 안내 기능

===개발과제의 기대효과===
====기술적 기대효과====
등산로 데이터 가공 및 구조화 기술 확보
:산림청에서 제공하는 등산로 geojson 데이터를 기반으로, 향후 다양한 등산 관련 서비스의 기술적 기반을 마련할 수 있다.
등산 난이도 분석 알고리즘 개발
:등산로의 길이, 고도차, 경사, 재질 등의 데이터를 종합하여 산행 난이도를 정량화하여, 사용자에게 맞춤형으로 제공할 수 있는 기술적 기반을 마련할 수 있다.
등산 경로 안내 기술 확보
:가공한 등산로 데이터를 사용자에게 내비게이션과 유사한 방식으로 사용자에게 제공하여 등산로 정보를 가독성 있게 제공할 수 있다.

==설계==
===사용자 요구사항===
====기능적 요구사항====
R1: 개인 정보 입력 기능
:- 사용자는 등산 목적지 추천 및 경로 생성을 위해 키, 체중, 성별, 등산 빈도, 선호 목적(예: 운동, 경치, 휴식) 등의 정보를 입력할 수 있어야 한다.
R2: 맞춤형 등산 목적지 추천 기능
:- 시스템은 사용자가 입력한 신체 정보와 등산 경험 데이터를 바탕으로, 유사한 사용자들이 선호한 등산 목적지를 추천할 수 있어야 한다.
R3: 출발 및 도착 지점 선택 기능
:- 사용자는 지도상에서 자신이 원하는 입산 지점과 하산 지점을 선택할 수 있어야 한다.
R4: 개인 맞춤형 등산로 생성 기능
:- 시스템은 사용자의 체력 수준 및 희망 난이도와 등산로의 기울기, 고도, 재질 등의 정보를 고려하여 최적의 등산 경로를 생성해야 한다.
R5: 실시간 등산로 안내 기능
:- 시스템은 GPS를 기반으로 사용자의 현재 위치를 표시하고, 등산 도중 갈림길이나 분기점에서 방향을 알려주는 기능을 제공해야 한다.

====비기능적 요구사항====
R6: 사용성 (Usability)
:- 사용자 인터페이스는 직관적이고 사용자가 각 기능을 쉽게 사용할 수 있어야 한다.
R7: 응답 속도 (Performance)
:- 등산 목적지 추천 기능 및 등산로 생성 기능은 각각 2초 이내에 처리되어야 한다.
R8: 신뢰성 (Reliability)
:- 시스템은 산림청에서 제공한 등산로 데이터에 기반하여 정확한 정보를 제공해야 한다.
R9: 확장성 (Scalability)
:- 추후 더 많은 산과 사용자 데이터를 추가할 수 있도록 시스템 구조는 확장 가능해야 한다.

===사용자 요구사항 만족을 위한 기능 정의 및 기능별 정량목표 ===
F1: 개인 맞춤형 등산 목적지 추천 기능
:'''기능 정의'''
::사용자가 입력한 키, 체중, 등산 빈도, 선호 목적 등 개인 정보를 바탕으로, 유사 사용자군이 선호한 목적지를 인공지능 모델을 통해 추천한다.
:'''정량 목표'''
::- 추천 결과 정확도: 95% 이상 (실제 등산 목적지 도달 성공률 기준)
::- 평균 응답 시간: 2초 이내
::- 사용자 만족도: SUS 점수 상위 5%
F2: 개인 맞춤형 등산로 생성 기능
:'''기능 정의'''
::사용자의 희망 목적지와 입산/퇴산 지점 정보를 바탕으로, 산림청 등산로 데이터를 활용하여 사용자 난이도에 맞는 최적 경로를 생성한다.
:'''정량 목표'''
::- 경로 생성 시간: 2초 이내
::- 개인 맞춤형 등산로 생성 기능에 대한 ASQ 평가 결과 6점 이상
F3: 실시간 등산 경로 안내 기능
:'''기능 정의'''
::GPS 위치 정보를 기반으로, 사용자가 현재 위치에서 어떤 방향으로 이동해야 하는지를 이미지로 안내한다.
:'''정량 목표'''
::- 사용자 위치와 GPS 표기 위치 간 차이 15m 이내
::- 안내 정확도: 99% 이상 (등산로 갈림길 방향 일치 여부)
F4: 사용자 정보 입력 기능
:'''기능 정의'''
::사용자가 자신의 정보를 손쉽게 입력할 수 있는 입력 양식을 제공한다.
:'''정량 목표'''
::- 입력 완료 소요 시간: 2분 이내
::- 사용자 정보 입력 기능에 대한 ASQ 평가 결과 6점 이상
F5: 시스템 성능 및 신뢰성 목표
:'''기능 정의'''
::전체 시스템이 모바일 환경에서 원활히 작동하고, 여러 사용자가 동시에 요청하더라도 서버 부하 없이 빠르게 응답하도록 구성된다.
:'''정량 목표'''
::- 동시 요청 처리량: 10명 기준 초당 5건 이상
::- 평균 응답 시간: 2초
::- 시스템 실패율: 0% (100회 요청 기준)

===기능 구현을 위한 세부기술 선택사항 (디자인) ===
서버 및 클라이언트 프레임워크
:프론트엔드는 React를 활용하여 사용자 인터페이스를 구성하였다. 백엔드는 Python의 FastAPI를 사용하여 경량화된 RESTful API 서버를 구현하였다. FastAPI는 비동기 처리와 빠른 응답 속도를 제공한다. 컴포넌트 기반의 설계로 유지보수와 확장성이 뛰어나며, 사용자 경험(UX)을 고려한 동적 페이지 처리가 용이하다.

하드웨어 인프라 구성
:라즈베리파이 5를 서버로 사용하여 저전력 환경에서도 동작할 수 있도록 구성하였다. 서버의 부하를 분산시키기 위해 파일 서버, 프론트엔드, 백엔드 각각 1개씩 총 3개의 라즈베리파이를 사용하였으며, 이를 통해 트래픽 분산과 장애 시 대체 가능성 확보 등 관리 용이성을 강화하였다.

경로 탐색 알고리즘 설계
:등산로 생성 기능에서는 Tobler’s hiking function을 활용하여 등산로의 난이도를 산출한다. 산출된 난이도를 바탕으로 다익스트라(Dijkstra) 알고리즘을 사용하였다. 이를 통해 등산로 특성을 고려한 사용자 맞춤형 최적 경로를 생성할 수 있도록 설계하였다.

지도 시각화 도구
:등산 경로의 시각화 및 지도 기능 구현에는 Leaflet.js와 OpenStreetMap을 사용하였다. 이를 통해 사용자에게 직관적이고 반응성이 뛰어난 지도 UI를 제공한다. 또한, 지도상에 경로 및 분기점을 효과적으로 표시할 수 있다.

===시스템 설계===
클라이언트 (프론트엔드)
:'''구현 기술: React'''
:'''주요 역할'''
::- 사용자 정보 입력
::- 지도 기반의 등산 경로 표시 (Leaflet.js + OpenStreetMap)
::- 추천 경로 결과 시각화 및 반응형 UI 구성
API 서버 (백엔드)
:'''구현 기술: FastAPI'''
:'''주요 역할'''
::- 사용자 요청 처리 (등산로 추천, 등산 경로 요청 등)
::- 경로 탐색 알고리즘 실행 (Dijkstra 기반)
::- 서버는 RESTful API 형태로 구현되어 있으며, 데이터는 JSON 형식으로 주고받는다.
데이터베이스 및 경로 데이터 처리
::- 사용자 정보 및 등산로 데이터를 저장 및 관리한다.
::- 산 데이터에는 등산로 전체 경로, 분기점 등의 속성이 포함되어 있다.
::- 등산로는 좌표 데이터를 기반으로 Leaflet 상에 Polyline 객체로 변환되어 시각화된다.
::- 좌표, 난이도 등의 속성이 포함되어 있으며, 알고리즘 수행 시 가중치로 사용된다.

===이론적 계산 및 시뮬레이션===

[[파일:산_데이터_통계_1672.jpg|1200픽셀|섬네일|가운데|'''그림 3.''' 22개 산 데이터의 정점 수(왼쪽), 간선 수(오른쪽). 빨간색 점선은 평균값에 해당한다.]]

:본 시스템의 등산로 생성 기능에는 다익스트라(Dijkstra) 알고리즘이 사용되었으며, 알고리즘의 이론적 시간 복잡도 (: 정점 수, : 간선 수)이다. [[#그림_3|그림 3]]은 각 산에 존재하는 등산로의 정점과 간선을 나타내는데, 각 산의 데이터가 크지 않음을 확인할 수 있다. 정점과 간선 개수가 많을수록 등산로 생성이 오래 걸리는데, 정점과 간선 개수가 가장 많은 팔공산 비로봉(정점 334개, 간선 405개를 기준으로 최장 거리 구간 탐색을 수행해도 소요 시간은 약 0.0005초에 불과했다.

:{| class="wikitable"
|-
|+ 표 1. 한 번에 10명의 사용자가 동시에 요청을 보냈을 때 소요 시간
|-
! 지표 !! 동시 사용자 10명 (100회 평균)
|-
| 처리량(요청/초) || 9.24개/초
|-
| 평균 응답 시간 || 1,081.9 ms (약 1.08초)
|-
| 연결 설정 시간 || 7.0 ms
|-
| 서버 대기 시간 || 982.0 ms
|-
| 처리 완료 시간 || 1019.0 ms
|-
| 총 소요 시간 || 1025.0 ms
|-
| P50 (상위50%) || 1066 ms
|-
| P90 (상위90%) || 1482 ms
|-
| P95 (상위95%) || 1512 ms
|-
| P100 (상위100%) || 1517 ms
|-
| 실패율 || 0%
|}

[[파일:dos-자원사용률.jpg|1200픽셀|섬네일|가운데|'''그림 4.''' 실제 서버에서 등산로 추천 요청을 100개 정도 받았을 때 걸리는 서버 부하]]

:실제 서비스를 위하여, 한 번에 많은 등산로 추천 요청을 받는 경우를 테스트했다([[#표_1|표 1]]). 시뮬레이션 결과, 서버에 걸리는 부하는 [[#그림_4|그림 4]]와 같았다. 1초에 약 9개 정도의 요청을 처리할 수 있는 것을 확인했으며, 평균 응답 시간은 1.08초였고, 최대 응답 시간은 1.52초였다. 우리가 제시했던 최대 응답 시간은 2초 이내로, 실제 부하가 있는 환경에서도 개발한 서비스가 제시했던 기준을 충족함을 확인했다.

===상세설계 내용===
====하드웨어 설계====
:{| class="wikitable"
|-
|+ 표 2. 라즈베리파이 5 사양 명세
|-
! 구분 !! 사양
|-
| 모델 || Raspberry Pi 5 (8GB RAM)
|-
| CPU || Quad-core Cortex-A76 @ 2.4GHz
|-
| GPU || VideoCore VII (800 MHz)
|-
| RAM || 8GB LPDDR4X
|-
| Storage || 64GB microSD
|-
| Network || 1Gbps Ethernet, Wi-Fi 802.11ac, Bluetooth 5.0
|-
| I/O || USB 3.0 x 2, USB 2.0 x 2, GPIO, HDMI × 2
|-
| 전원 || USB-C (5V 5A), 평균 소비 전력 약 15W
|}

:본 시스템에 사용한 라즈베리파이 5의 성능은 다음과 같았다([[#표_2|표 2]]). 총 라즈베리파이 5 (8GB 모델) 3대를 활용하였으며, 프론트엔드 서버(React 앱 서빙 및 정적 자원 제공), 백엔드 API 서버(FastAPI, 경로 추천, 사용자 데이터 처리), 데이터 서버(등산로 데이터, 이미지 저장 및 처리)로 역할을 분리한 구조로 설계되었다. 각 장비는 물리적으로 독립된 하드웨어로 구성되며, 동일 네트워크상의 라우터를 통해 상호 연결되어 있다.

:이러한 구조는 저전력으로 운용할 수 있다는 장점을 가질 뿐만 아니라, 마이크로서비스 형태로의 확장이 용이하며, 장애 분리 및 병렬 처리가 가능하다는 장점이 있다. 각 장비는 SSH 접속을 통해 원격에서 제어 및 유지관리가 가능하도록 설정되어 있다.

====소프트웨어 설계====
본 시스템은 사용자 맞춤형 등산로 추천 기능을 중심으로 한 웹 기반 등산로 내비게이션 시스템으로, 다양한 소프트웨어(예: 프론트엔드 등)으로 이루어진다.

전체 아키텍처 설계
:시스템은 클라이언트-서버 구조를 기반으로 하며, 주요 구성은 다음과 같다.
::- 클라이언트 서버(프론트엔드): React 기반으로 구현되어 사용자 정보 입력, 등산로 시각화, 경로 추천 결과 출력, 등산로 안내 기능을 제공한다.
::- API 서버(백엔드): FastAPI를 사용하여 사용자 입력 정보를 처리하고, 등산로 경로 생성 및 경로 안내를 수행한다.
::- 데이터베이스 서버: 산림청 제공 데이터 및 2차 가공 데이터(예: 등산로 데이터) 등이 저장된다.
::- 서버 인프라: 라즈베리파이 5 장비 3대를 병렬 구성하여 백엔드, 프론트엔드, 데이터 서버로 분리 운영하며, 저전력 기반에서도 충분한 성능을 제공한다.

주요 기능별 설계
:'''개인 맞춤형 목적지 추천'''
::- 사용자로부터 성별, 키, 체중, 등산 빈도, 등산 목적 등의 정보를 입력받는다.
::- 회귀분석 기반의 운동 수준 계산 알고리즘과 인공지능 분류 모델을 사용하여 유사한 사용자들이 선호했던 목적지를 추천한다.
:'''개인 맞춤형 등산로 생성'''
::- 사용자의 체력 지수 및 희망 난이도, 시작 지점과 종료 지점을 바탕으로 등산로를 선택한다.
::- 등산로의 난이도는 Tobler’s Hiking Function을 응용하여, 기울기와 고도차 등의 정보를 기반으로 계산한다.
::- Dijkstra 알고리즘을 이용하여 난이도 기반 가중치를 고려한 최적 경로를 탐색한다.
:'''실시간 등산로 안내 기능'''
::- 사용자의 GPS 위치를 기반으로 등산로 진행 방향을 시각적 이미지로 제공한다.
::- 산 내부 갈림길에서의 방향 정보를 제공하여, 표지판이 부족한 지역에서도 올바른 경로를 안내한다.

소프트웨어 실행 흐름도
:개략적인 우리 시스템의 실행 흐름은 다음과 같다([[#그림_5|그림 5]]).
[[파일:소프트웨어흐름도.png|1200픽셀|섬네일|가운데|'''그림 5.''' 시스템의 실행 흐름도]]

==결과 및 평가==
===완료 작품의 소개===
[[파일:Dos-작동사진.jpg|1200픽셀|섬네일|가운데|'''그림 6.''' 프로토타입 메인 화면 및 등산로 추천 기능]]

개인 정보 입력
:사용자는 자신의 키, 체중 및 등산 빈도, 등산 목적과 같은 정보를 입력한다.

개인 맞춤형 등산 목적지 추천
:앞서 입력된 개인 정보를 바탕으로 과거 유사한 사용자들이 선호했던 목적지들을 추천한다.
:사용자는 추천된 목적지들을 저장하고 이를 바탕으로 개인 맞춤형 등산로 생성 기능에서 활용할 수 있다.

개인 맞춤형 등산로 생성
:사용자는 개인 맞춤형 등산 목적지 추천 기능에서 선택한 등산 목적지들의 등산 시작 지점, 등산 종료 지점을 확인할 수 있다.
:이후 등산 시작 지점, 등산 종료 지점을 선택하고, 희망 난이도(매우 쉽게- 매우 어렵게)를 선택한다.
:시스템은 등산 목적지, 사용자 운동 수준 및 사용자의 희망 난이도, 그리고 입력받은 등산 시작 지점 및 등산 종료 지점을 바탕으로 개인 맞춤형 등산로를 생성한다.

생성한 등산로 안내
:앞서 개인 맞춤형 등산로 생성 과정에서 생성한 등산로에 대해 사용자에게 안내하는 기능을 제공한다.
:산 내부의 갈림길에서 표지판이 없는 경우가 있어 해당 기능을 제공하게 되었으며, 각 갈림길에서 진행해야 할 방향을 사용자에게 안내한다.
:사용자는 자신의 현재 위치에 기반하여 정보를 받을 수 있고, 길을 잘못 들었을 경우 GPS를 통해 이를 확인하고 되돌아갈 수 있다.

===실행 방법 (Run)===
아래의 링크를 클릭하거나 인터넷 탐색기에 주소를 입력하여 바로 실행할 수 있다.
모바일 환경에 최적화되어 있다.

[https://uos-dos.shop/ 셰르파(Sherpa)]
[[파일:dos-실행방법.jpg|1200픽셀|섬네일|가운데|'''그림 7.''' 셰르파(Sherpa) 실행 방법]]

===완료 작품의 평가===
:{| class="wikitable" style="text-align:center"
|-
|+ 표 3. 완료 작품 평가 항목 및 결과
|-
! 평가 항목
! 평가방법
! 적용기준
! 개발 목표치
! 비중 (%)
! 평가결과
|-
| 1. 정보의 정확성
| 평가용 질문 & 답변 실제 등산을 통한 확인
| 정확도 (100%)
| 99%
| 50
| 97.2%
|-
| 2. 사용자 만족도
| 시스템 사용성 척도(SUS) 시나리오 후 설문(ASQ)
| 만족도 (5점) 점수 (7점)
| SUS 4점 ASQ 5.5점
| 30
| SUS 상위 5% ASQ 6.67점
|-
| 3. 유지보수 가능성
| 서비스를 운용하는 데 들어가는 비용 & 수익 비교
| -
| 수익>비용
| 20
| 수익>비용
|}

====정보의 정확성====
:{| class="wikitable" style="text-align:center"
|-
|+ 표 4. 생성한 등산로의 각 목적지별 정확도
|-
! 목적지
! 정확도
|-
| 수락산 정상
| 100%
|-
| 수락산 내원암
| 100%
|-
| 수락산 도정봉
| 100%
|-
| 북한산 사모바위
| 97%
|-
| 노고산 정상
| 89%
|-
|}

실제 등산로 안내 기능을 활용해 등산을 진행하며, 서비스에서 표시되는 화살표의 방향이 실제 진행해야 할 방향과 일치하는지를 확인하였다([[#표_4|표 4]]). 수락산에서는 기능이 정상적으로 동작하여 100%의 정확도를 보였다.

북한산 사모바위의 경우 97%의 정확도를 보였는데 33개의 갈림길에 대해 생성된 33개의 화살표 이미지 중 한 개의 화살표에 문제가 있었다. 실제 상황은 사거리에서 직진해야 하는 구조였으나, 좌측 8시 방향 탐방로가 표시되지 않아, 시스템상에서는 삼거리에서 직진하는 이미지가 생성되었다. 8시 방향 탐방로가 반영되지 않은 이유는 해당 구간이 이용이 금지된 비법정 탐방로로, 산림청 제공 데이터에 포함되어 있지 않았기 때문이다. 사거리가 삼거리로 표시되어 사용자에게 혼란을 줄 가능성은 있으나, 진행 방향은 정상적으로 안내되었고, 제공되지 않은 비법정 탐방로로 인해 실제 등산 과정에서 문제는 발생하지 않았다.

노고산 정상의 경우, 89%의 정확도를 보였다. 27개의 갈림길 중 초반 24개의 갈림길에 대해서는 화살표 이미지가 전부 정확하게 생성되었으나 후반 3개의 갈림에 대한 화살표 이미지가 생성되지 않았다. 이미지가 생성되지 않은 이유는, 산림청 제공 데이터에서 24번째 갈림길 이후의 등산로 데이터가 누락되어 있었기 때문이다. 다만, 24번째 갈림길까지는 정확한 길을 제시하였기 때문에 정상까지의 모든 길을 안내해 주지는 못하였으나, 잘못된 길로 안내하지도 않았다.

정보 누락의 원인으로는 두 가지 가능성을 고려할 수 있다.

첫째, 노고산은 국립공원에 속하지 않는 양주시 관할 등산로이기 때문에, 산림청과 기초지방자치단체(양주시) 간의 정보 공유 및 연계가 원활하지 않았을 가능성이 있다.
둘째, 노고산은 상대적으로 탐방객 수가 적은 저명도 산지로, 양주시에서 등산로를 체계적으로 조사하거나 디지털화하여 외부 기관에 제공하는 데에 적극적이지 않았을 가능성도 존재한다.

실제 평가 결과 다섯 개의 평균은 97.2%로, 기존 개발 목표치였던 99%보다 떨어졌으나, 실제 등산 과정에서 사용자에게 치명적인 혼란이나 위험을 유발하지는 않았다는 점에서 기능의 기본적인 유효성은 확보되었음을 확인할 수 있다. 특히, 수락산과 같은 정비된 등산로에서는 화살표 이미지와 실제 경로가 완전히 일치하였고, 북한산도 단일 예외 사례를 제외하면 전반적으로 신뢰할 수 있는 결과를 보였다.

====사용자 만족도====
우리는 프로토타입의 추천 시스템의 초기 데이터로 사용하기 위해 106명의 등산객을 대상으로 설문조사를 진행하였다. 평가 인원을 모집하기 위하여 설문조사에 참여했던 등산객들에게 이메일, 전화번호를 이용해 사용자 평가 인원을 모집했다. 모집한 사용자들을 대상으로 사용자 만족도를 평가하고, 개발한 시스템을 개선하기 위하여 12명의 사용자를 대상으로 노고산(4명), 수락산(8명)에서 두 번의 평가를 진행했다. 사용자들은 실제로 등산 전에 3분 이내로 우리 시스템을 사용할 시간을 제공받고, 우리 시스템을 사용해 다음 Task를 수행했다([[#그림_8|그림 8]]).

:::[[파일:dos-ASQ-tesk.jpg|1000픽셀|섬네일|가운데|'''그림 8.''' ASQ(시나리오 후 설문)에서 각 기능을 평가하기 위한 Task들]]

Task를 수행한 이후, 각 Task와 시스템의 사용성에 대해 질문한 후, 등산을 진행하면서 반구조화된 인터뷰를 수행하여 우리 앱의 좋았던 점, 개선할 점, UI, 추가되었으면 하는 기능을 전달받았다. 인터뷰 내용은 녹음을 통해 확인하였으며, 대본으로 바꾼 이후 즉시 녹음 파일을 삭제하였다.

'''시스템 사용성 척도 (SUS) [[#ref5|[5]]]'''

:::[[파일:Dos-sus.jpg|1000픽셀|섬네일|가운데|'''그림 9.''' System Usability Scale(SUS) 10개 문항(1점 : 매우 동의하지 않는다, 5점 : 매우 동의한다). 오른쪽의 환산 점수가 각 문항별 우리 시스템의 사용성 점수이다.]]

시스템 사용성 척도([[#그림_9|그림 9]])는 시스템의 사용성을 빠르게 평가하기 위해 고안된 설문지이다.

시스템 사용성 척도는 10개의 Likert-scale 문항으로 구성되어 있으며, 홀수 문항은 점수가 높을수록, 짝수 항목은 점수가 낮을수록 높은 사용성을 의미한다[[#ref5|[5]]]. 짝수 문항은 (6 – 점수)를 통해 환산 점수를 산출하며, 을 통해 시스템의 사용성 점수를 도출할 수 있다. 사용성은 84.1점 이상일 경우, 상위 5%의 사용성(Best imaginable)을 가진다. 실제 사용성 평가 결과 우리 시스템의 사용성은 91.8점이 나왔으며, 좋은 사용성을 가졌다는 것을 확인하였다.

'''시나리오 후 설문 (ASQ)'''
[[파일:dos-asq-result.jpg|섬네일|가운데|'''그림 10.''' 시나리오 후 설문(ASQ)]]

시나리오 후 설문([[#그림_10|[그림 10]]]은 각 Task를 수행하는 것이 얼마나 어려운지 확인하는 사용성 평가 방법이다[[#ref6|[6]]]. 우리는 우리 시스템에서 제공하는 주요 기능(개인 맞춤형 등산 목적지 추천, 개인 맞춤형 등산로 생성, 생성한 등산로 안내)을 쉽게 사용할 수 있는 지 확인하기 위하여 우리의 기능에 대응되는 Task를 만든 시나리오 후 설문을 진행했다. 설문 진행 결과, 우리가 제공하는 주요 기능이 모두 사용자가 쓰기 편하다는 것을 확인했다.

'''반구조화 인터뷰'''
우리는 추후 우리 앱을 개선하기 위하여, 앞선 두 개의 설문을 진행한 이후 우리 앱의 좋았던 점, 개선할 점, UI, 추가되었으면 하는 기능을 묻는 반구조화 인터뷰를 진행했다. 주요한 내용은 다음과 같았다.

:'''좋았던 점'''
''기존에 등산로 방향을 찾을 때 사진이 올라와 있는 블로그들을 많이 참조했는데, 직접적으로 방향을 알려주는 점이 좋았다. -P7-''

''아직 개인의 운동 수준과 등산로 난이도 스케일이 정확히 맞지는 않는 것 같지만, 어려운 등산로일수록 등산로 난이도가 어렵게 나오는 건 맞는 것 같다. 등산을 진행할 때 어느 정도 참고가 가능할 것 같다. -P10- ''

:'''개선할 점'''
''등산 목적지에 쉬운 코스가 없을 경우, 난이도를 쉽게 설정해도 어려운 코스가 나오는 문제점이 있다. -P4-'' (해결됨)

''위시리스트 담기라는 표현 자체가 잘 이해되지 않았다. -P8-''

''Navi 페이지에서 진행바가 새로고침할 때마다 리셋되는 것이 아쉬웠다. -P12-''

''목적지 추천 부분에서 산 이름이 영어로 나오는 점이 아쉬웠다. -P11-''

:'''UI 관련'''
''프로토타입 UI는 개인적으론 별 다른 것 없이 깔끔해서 좋았다. -P2, P7-''

''잡다한 기능이 없어서 사용법을 금방 익힐 수 있었다. -P9-''

:'''추가되었으면 하는 기능'''
''코스 예상시간이 표기되면 좋을 것 같다. -P1-''

''더 많은 산들에 대해서도 정보를 제공하면 좋을 것 같다. -P11-''

''나와 비슷한 사용자들을 매칭해주는 기능이 있으면 좋을 것 같다. -P12-''

''등산했던 등산로들을 모아서 저장하고 공유할 수 있는 기능이 있으면 좋을 것 같다. -P12-''

====유지보수 가능성====
서비스를 운영하는 데에 드는 비용은 도메인 유지 비용(10달러/1년), 라즈베리파이를 유지하기 위한 전기료 정도를 고려할 수 있다. 이는 페이지 내 배너 광고를 하나만 추가해도 상회할 수 있으며, 운영 비용 자체가 적기 때문에 수익을 계속 유지할 수 있으며, 유지보수 및 지속적인 개발 또한 가능할 것으로 보인다.

===향후 평가===
====어려웠던 내용들====
:- 산림청에서 제공하는 geojson 데이터를 시스템에서 사용하기 위한 형태로 가공하는 과정에서 많은 시행착오가 있었다.

:- 기존에는 클라우드 서비스를 이용하는 형태로 설계했는데, 클라우드 비용 문제 및 교내망에서는 서버에 접속할 수 없는 문제가 발생하였다.

:- 설문조사 및 인터뷰 대상을 모집하는 과정에서 어려움이 있었다.

:- 추천 알고리즘을 만들기 위한 사람들의 등산 데이터가 너무 적었다.

====차후 구현할 내용====
주로 반구조화 인터뷰 중 아쉬웠던 점, 추가되었으면 하는 기능들 중 구현 난이도가 쉬운 항목부터 진행할 예정이다. 구체적으로 다음과 같다.

:- “위시리스트 담기”와 같이 사용자가 한 번에 이해되지 않을만한 표현, 불필요하게 작성된 영어 표현이 있는지 확인하고 수정한다.

:- Navi 페이지의 진행 바의 진행 상황을 새로고침 되더라도 유지한다.

:- 코스 예상시간 표기 기능을 추가한다.

:- 시스템에서 지원하는 산의 개수를 더 늘린다.

:- 더 많은 사용자들의 검색 데이터들을 참고하여 추천 알고리즘을 개선한다.

:- 등산했던 등산로들을 모아서 저장하고 공유하는 기능을 개발한다.

==개발 사업비 정산==
===구성원 및 추진체계===
[[파일명|사진들어갈자리]]
===자재소요서===
서비스를 제공할 도메인
:10달러/1년의 비용이 발생하며, 서비스를 하기 위하여 항상 필요하다. (현재 사비로 지출)

라즈베리 파이 5
:백엔드, 프론트엔드, 데이터 각각의 서버를 구동하기 위하여 총 3개가 사용되었으며, 마찬가지로 없으면 서비스가 불가능하다.

===개발사업비 내역서===
{| class="wikitable" style="text-align:center"
|+ style="text-align:right" | (단위 : 천원)
|-
! colspan="2" | 항목 (품명, 규격)
! 수량
! 단가
! colspan="2" | 금액
! 비고
|-
! rowspan="2" | 직접 개발비
| 라즈베리 파이 5 || 3 || 130 || 390 || 390 ||
|-
| 합계 || || || 390 || 390 ||
|}

== 부록 ==

=== A-1 참고문헌 및 참고사이트 ===
[1] 산림청. (2022년 8월 2일). 우리나라 성인 78% 한 달에 한 번 이상 산에 간다. 대한민국 정책 브리핑. https://www.korea.kr/news/policyNewsView.do?newsId=148911465

[2] Scarf, P. (2007). Route choice in mountain navigation, Naismith's rule, and the equivalence of distance and climb. ''Journal of Sports Sciences, 25''(6), 719–726.

[3] Goodwin, A., Hammett, M., & Harris, M. (2025). The application of Tobler's hiking function in data-driven traverse modelling for planetary exploration. ''Acta Astronautica, 228,'' 265–273.

[4] Ko, H., Lee, S., Park, Y., & Choi, A. (2022). A survey of recommendation systems: recommendation models, techniques, and application fields. ''Electronics, 11''(1), 141.

[5] Brooke, J. (2013). SUS: a retrospective. ''Journal of usability studies, 8''(2).

[6] Qualaroo. How to create an after-scenario questionnaire (ASQ). Retrieved June 10, 2025, from https://help.qualaroo.com/after-scenario-questionnaire

=== A-2 관련 특허 ===
[1] 등산 내비게이션 단말 시스템 및 이를 이용한 등산 코스 안내 운영 방법
[2] 산림빅데이터 플랫폼에 기반하여 데이터 상품을 제공하는 장치 및 방법

=== A-3 소프트웨어 프로그램 소스 ===
(소스코드 내용이 이곳에 들어감. 필요 시 별도 첨부)

1분반-aPPLY

2026-03-11T07:29:30Z

Adcdc: Adcdc (토론)의 12607판 편집을 되돌림

<div>__TOC__</div>

==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 : ''' 다이어리픽 - 사진기반 일기 자동 생성 앱

''' 영문 : ''' DiaryPic - Photo-based Automatic Diary Creation App

===과제 팀명===
aPPLY

===지도교수===
박관용 교수님

===개발기간===
2025년 3월 ~ 2025년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 컴퓨터과학부 20229200** 박*빈

서울시립대학교 컴퓨터과학부 20229200** 박*찬

서울시립대학교 컴퓨터과학부 20229200** 양*슬

서울시립대학교 컴퓨터과학부 20229200** 이*목

==서론==
===개발 과제의 개요===
====개발 과제 요약====
본 프로젝트는 사용자가 일상 속에서 촬영한 사진을 기반으로 손쉽게 일기를 작성하고 관리할 수 있는 '''AI 사진 일기 앱'''을 개발하는 것이다. 사용자는 사진을 업로드하면 AI가 자동으로 일기 초안을 생성해주며, 이를 수정 또는 확정하여 저장할 수 있다. 캘린더 및 앨범 기능을 통해 기록을 시각적으로 관리할 수 있고, 감정 이모티콘, 위치 기반 분류, AI 베스트샷 추천 등 다양한 기능이 제공되어 감성적이고 효율적인 일기 쓰기 경험을 제공한다.

====개발 과제의 배경 및 효과====
현대 사회에서 사람들은 바쁜 일상 속에서도 자신의 감정을 기록하고 추억을 저장하는 것에 대한 필요성을 느낀다. 그러나 기존의 다이어리 애플리케이션은 대부분 수동 입력 방식으로 제공되며, 사용자가 꾸준히 기록하는 것이 쉽지 않다.

이에 따라 우리는 사진을 기반으로 자동으로 일기를 작성해주는 AI 일기 앱의 필요성을 인식하였다.
우리의 앱은 사용자가 업로드한 사진 정보를 기반으로 AI가 자연어 일기 초안을 생성해주며, 캘린더 기반의 시각적 관리와 감정 태깅, 메타데이터 기반 장소별 앨범 정리 등의 기능을 통해 감성과 편의성을 모두 고려한 사용자 경험을 제공한다.

이를 통해 사용자는 일기 작성의 부담을 줄이면서도 감정 기록과 추억 보관을 쉽게 할 수 있다. AI 기반 장소별 앨범 정리를 활용하여 보다 정돈된 형태로 기록을 관리할 수 있으며, 검색 및 조회 기능을 강화함으로써 과거의 기록을 쉽게 찾아볼 수 있다.

====개발 과제의 목표 및 내용====

이 앱의 주요 개발 목표는 사진을 활용한 자동 일기 생성 시스템을 중심으로, 사용자의 기록 습관을 쉽게 만들어주는 통합형 일기 플랫폼을 구축하는 것이다. 아래는 구체적인 기능 구성이다.

1. 사용자 인증 및 시작화면

- SNS 연동을 통한 회원가입 및 로그인 기능을 제공한다.

2. 메인 페이지: 사진 기반 기록 시작

- 사용자가 하루 중 기록하고 싶은 사진을 한 장 또는 여러 장 업로드할 수 있다.

- 사진 메타데이터(촬영일, 장소 등)를 기반으로 자동 분류 및 활용한다.

3. 캘린더 기반 기록 관리

- 캘린더에서 날짜 선택 후 해당 날짜의 일기를 조회할 수 있다.

- 일기 유무에 따라 썸네일에 해당 일기의 대표 사진을 표시한다.

- 사진이 없는 경우에는 기본 배경화면이 썸네일로 자동 지정된다.

- 새 기록 추가 시, 사진 업로드 또는 텍스트 입력 창을 제공한다.

4. 일기 작성 및 AI 지원 기능

- 여러 장의 사진 중 최대 9장의 대표 사진을 AI가 베스트샷으로 추천한다.

- 사용자는 AI 사진 추천 전 필수 포함 사진을 수동으로 선택할 수 있다.

- Swipe를 통해 사진을 조회할 수 있다.

- 각 사진마다 사용자가 포커스 키워드(인물, 풍경, 음식, 사물, 동물, 커스텀 추가)를 선택한다.

- AI는 사진, 메타데이터, 키워드, 말투 설정을 바탕으로 일기 초안을 생성한다.

- 사용자는 초안을 수동으로 수정하고 텍스트를 입력하여 AI가 생성한 내용을 수정할 수 있다.

- 일기 작성 시 감정 이모티콘 설정 및 좋아요 태그 기능을 제공한다.

5. 말투 커스터마이징 기능

- 사용자는 사전 설정된 말투 유형(예: 기록형, 감성형, 경쾌형, 내면 대화형, 관찰형, 계획형 등) 중 선택할 수 있다.

- 필요 시 직접 수정하거나 새 말투 스타일을 추가할 수 있다.

- AI는 설정된 말투에 맞춰 일기를 생성하여 개인화된 기록 경험을 제공한다.

6. 마이 페이지: 개인 설정 및 통계

- 사용자 정보 수정 기능을 제공한다.

- 사진 기록 알림 On/Off, 시간 설정 등 알림 기능을 제공한다.

- 삭제된 일기를 임시 저장하는 휴지통 기능으로 실수를 방지한다.

:6.1 앨범 페이지: 자동 정리와 검색

:- 작성된 일기들을 썸네일로 한눈에 볼 수 있는 앨범 뷰를 제공한다.

:- 월/년별 일기 작성 통계(작성 수)를 제공한다.

:- 좋아요를 누른 일기만 모아볼 수 있는 좋아요 앨범을 제공한다.

:- 장소 기반 자동 앨범 분류 기능(예: "서울특별시", "미국")을 제공한다.

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
*State of art
{| class="wikitable"
|-
! 기술 분야
! 적용 기술
! 비교
|-
| Multimodal LLM
| GPT, Gemini, Gemma, QWEN
| Image-Text-to-Text Multimodal 모델
|-
| LLM
| GPT, Gemini, LLAMA, QwQ, EXAONE
| Text Generation, 고급 자연어 처리
|-
| Computer Vision
| CLIP, NIMA, InsightFace, EAR
| 입력 이미지 분석 및 Clustering/Ranking
|}
*특허조사 및 특허 전략 분석
:◇ 유사 특허 명 
● 공개 
이미지 인식과 일정 데이터를 통한 자동 일기 작성 서비스 출원번호: 1020230123422 (2023-09-15) 

공유 이미지의 감성분류 기반 자동 문장 완성과 그림일기 서비스 제공장치 출원번호: 1020220062520 (2022-05-23) 

인공지능 서비스를 이용한 일기작성장치 및 그 장치의 구동방법 출원번호: 1020230104800 (2023-08-10) 

● 등록 
시각적 입력의 처리 출원번호: 1020180035734 (2018-03-28) 

일기 및 일정 관리 서비스서버, 일기 및 일정 관리 서비스를 제공하는 단말기 그리고 그 제어방법 출원번호: 1020130126094(2013-10-22) 

⚫ 소멸 (등록료 미납) 
전자장치에서 일기 서비스를 제공하는 방법 및 장치 출원번호: 1020140017769 (2014-01-17) 

⚫ 거절 
일기 분석을 기반으로 사용자의 감정을 관리하는 시스템 및 방법 출원번호: 1020220019676 (2022-02-15) 

:◇ 특허 전략 
- 유사 특허와의 차별점 분석 
1. 자동 일기 작성의 기반 기술 차별화 기존 특허들은 주로 이미지 인식과 일정 관리 또는 감정 분석을 통해 일기를 작성하는 시스템을 다루고 있습니다. 예를 들어, 이미지 인식과 일정 데이터를 통한 자동 일기 작성 서비스(1020230123422) 특허는 이미지와 일정 데이터를 결합하여 자동으로 일기를 생성합니다. 반면, 우리의 프로젝트는 사진 기반으로 자동 일기 초안을 생성하며, 감성 이모티콘과 위치 기반 분류 기능을 추가하여 사용자가 일기를 더 감성적이고 시각적으로 관리할 수 있도록 돕습니다. 

2. 기능적 차별화 기존 특허에서 일기 및 일정 관리 시스템(1020130126094)에서는 일정 정보와 일기를 통합하여 자동으로 일기를 생성하는 방식입니다. 그러나 우리의 프로젝트는 자동 베스트샷 추천, 사용자 맞춤형 감정 태그, 그리고 자유로운 텍스트 수정 기능을 포함해 사용자가 더 개인화된 일기를 작성할 수 있게 도와줍니다. 

3. AI 기반 감정 분석 및 개인화 기존 특허들은 감정 분석을 통해 사용자의 감정을 추적하거나 일기를 생성하는 데 주력하지만, 우리의 프로젝트는 사용자가 선택한 말투에 따라 자동으로 일기 초안을 개인화하며, AI 기반 감성 분석을 통해 자동으로 감정을 분석하여 사용자 맞춤형 결과를 제공합니다. 

- 향후 특허 전략 
{| class="wikitable"
|-
! 구분
! 내용
|-
| rowspan="2" | 기본 특허
| AI 모델 및 감성 분석 기술 보호 - 감성 분석 및 자동 수정 기능
|-
| AI 기반 개인화 기술 - 맞춤형 일기 초안 제공 시스템
|-
| 응용 특허
| 데이터 처리 및 관리 기술 보호 - 사진 메타데이터 처리와 위치 기반 일기 분류
|-
| 방어 특허
| AI 기반 감성 분석 및 자동 수정, UI/UX 차별화 기술
|}

====시장상황에 대한 분석====
*경쟁제품 조사 비교
◇ 마이모리 
- '''서비스''': 채팅형 일기, 일기 생성 및 사진 설명 작성, 답장 제공 
- '''강점''': ui/ux가 직관적임, 습관적 일기를 쓸 수 있게 도와줌, 감성적 문체 제공 
- '''약점''': 일기를 쓰기 위해서는 캐슈넛이라는 재화가 필요함 (광고를 보거나 구독필요) 

◇ 답다 
- '''서비스''': 감정 및 누구와 어디서, 무엇을 했는지 선택을 하면 자동 일기 생성, 12시간 이후 답장 제공 
- '''강점''': 감정에 대한 구체적인 감정을 분류해줌, 쓰기 찬스를 통해 조금 더 편리하게 일기를 작성할 수 있음, 일기 작성 후 감정 태그를 붙여줌 
- '''약점''': 감정 태그 분석 시간이 필요함, 다양한 기능이 없음 

◇ 마인디 
- '''서비스''': 채팅형 일기 및 AI 요약, 줄글형 일기 및 AI 분석 
- '''강점''': 디자인이 다양해 토핑경제가 가능함, 다양한 형식으로 일기 작성 가능 
- '''약점''': 답장 제공 시간이 필요함, 비슷한 기능(채팅형 일기, 줄글형 일기)이 많아서 복잡해보임 
*마케팅 전략 제시
[[파일:마케팅.jpg|600픽셀]]

===개발과제의 기대효과===
====기술적 기대효과====
- 이 프로젝트에서는 이미지에서 추출한 시각 정보를 텍스트 생성에 활용하는 Multimodal AI 기술을 사용한다. 최신 Multimodal AI 기술을 실용적 활용 사례 제공으로 기술적 발전에 기여한다. 또한 사진 인식 및 분석 기술, 자연어처리 등의 실질적 응용기술 개발을 촉진할 수 있다. 

- 사용자에 의해 개인화된 문체를 프롬프트에 사용하여 AI가 사용자 특유의 말투를 반영하여 일기의 초안을 생성한다. 이러한 사용자 맞춤형 기능은 기존 텍스트 생성 모델과 차별화된 성능과 자연스러움을 보여줄 수 있다. 

- 사용자가 직접 좋은 이미지를 고르지 않아도 이미지 분석을 통해 좋은 이미지를 선택하게 된다. 또한 이미지만 업로드 후 일기를 작성하지 않아도 스스로 AI가 초안의 일기를 작성해주고 쉽게 수정할 수 있도록 도와준다. 이는 사용자의 노력을 크게 줄여주어 사용자 경험(UX)을 개선한다.

====경제적, 사회적 기대 및 파급효과====
- 기존 일기 작성 방식과는 다르게 사진 메타데이터 + AI 기술을 접목한 새로운 시장 영역을 개척한다. 
- 바쁜 현대인들에게 AI를 통한 손쉬운 일기 작성 기능으로 자기 표현의 기회를 확대한다. 
- 개인의 추억과 경험을 디지털 형식으로 보존하여 사회 전반의 기록 보존 및 문화 발전에 긍정적인 영향을 미친다. 

===기술개발 일정 및 추진체계===
====개발 일정====
{| class="wikitable" style="text-align: center;"
|-
! rowspan="2" | 단계별 세부개발 내용
! rowspan="2" | 담당자
! colspan="4" | 개발기간 (월단위)
! rowspan="2" | 비고
|-
! 3 !! 4 !! 5 !! 6
|-
| 아이디어 구상 및 요구사항 분석
| 전원
| ● || || ||
|
|-
| 개발 환경 및 컨벤션 설정
| 전원
| ● || || ||
|
|-
| 서버 인프라 및 CI/CD 구축
| 이*목, 양*슬
| ● || ● || ||
| 서버 인프라: aws ec2, aws s3, aws route 53 CI/CD: git action
|-
| UI/UX 설계
| 박*빈
| ● || ● || ||
|
|-
| 데이터베이스 설계
| 이*목
| ● || ● || ||
|
|-
| API 설계
| 이*목, 박*찬
| || ● || ● ||
|
|-
| 프론트엔드 개발
| 박*찬, 박*빈
| || ● || ● ||
|
|-
| 백엔드 개발
| 이*목
| || ● || ● ||
|
|-
| AI서버 개발
| 양*슬
| || ● || ● ||
|
|-
| 이미지 선별 AI 모델 생성
| 박*찬, 양*슬
| || || ● || ●
|-
| 일기 생성 AI 모델 생성
| 박*찬, 양*슬
| || || ● || ●
|-
| 통합테스트
| 전원
| || || ● || ●
|-
| 배포
| 전원
| || || || ●
|-
| 유지보수
| 전원
| || || || ●
|}

====구성원 및 추진체계====
◇ 박*빈 : 팀장, UI/UX 디자인, 클라이언트 개발 
◇ 박*찬 : 클라이언트 개발, AI 모델 엔지니어링 
◇ 양*슬 : AI 모델 엔지니어링, AI 서버 개발 
◇ 이*목 : 백엔드 개발, DB설계 

==설계==
===설계사양===
====제품의 요구사항====
{| class="wikitable"
! ID !! 구분 !! 요구 사항 !! D or W !! 우선 순위 !! 비고
|-
| NAV || 네비게이션바 || '''NAV-01 네비게이션''' - 하단 네이게이션 바를 통해 메인, 캘린더, 마이 페이지로 이동할 수 있다. || D || 상 ||
|-
| USR || 회원가입/로그인 || '''USR-01 SNS 회원가입/로그인''' - 소셜 계정으로 로그인 및 회원가입을 할 수 있다. || D || 상 ||
|-
| || || '''USR-02 초기 설정''' - 닉네임 설정 가능 - 일기 말투 설정 가능 - 이용 약관 동의 가능 - 앱 사용 설명 페이지로 유저의 사용을 도울 수 있다. || D || 상 || 닉네임 글자 수 10자 제한
|-
| MAI || 메인 페이지 || '''MAI-01 사진 업로드''' - 사용자가 일기로 사용하고 싶은 사진을 한 장 또는 여러 장 업로드할 수 있다. - 사용자는 메인 화면이나 캘린더 화면에서 사진을 업로드할 수 있다. || D || 상 || 한 번에 업로드 40장 제한
|-
| || || '''MAI-02 감성 문구 디스플레이 기능''' - 사용자는 요일 별 감성 문구를 볼 수 있다. || D || 중 ||
|-
| CAL || 캘린더 페이지 || '''CAL-01 기록 조회''' - 사용자가 특정(일기 생성이 완료된) 날짜를 선택 시 해당 날짜에 등록된 사진 및 일기 페이지로 이동할 수 있다. || D || 상 ||
|-
| || || '''CAL-02 기록 추가''' - 사용자는 날짜를 선택한 후 새로운 기록을 추가할 수 있다. - '+' 버튼을 누르면 사진 업로드 버튼 및 텍스트 입력 칸이 나타난다. - 사용자는 갤러리에서 사진을 업로드할 수 있다. || D || 중 ||
|-
| || || '''CAL-03 캘린더 날짜별 배경사진 설정''' - 캘린더 날짜별 배경사진은 해당 날짜에 작성된 일기의 대표 사진(사용자가 직접 설정 가능)으로 제공되며, 감정 이모티콘으로 전환할 수 있다. - 사용자가 사진없이 텍스트만 입력할 경우 기본 배경사진을 사용한다. - 일기가 존재하지 않는 경우, 배경사진은 지정되지 않는다. || D || 중 ||
|-
| || || '''CAL-04 일기 초안 생성 표시''' - 사용자는 일기 작성 요일 배경사진에 생긴 링을 통해 AI가 일기 초안이 작성되었다는 것을 인식할 수 있다. - 사용자가 초안을 수정하거나 확정하면 링이 사라진다.|| D || 중 ||
|-
| || ||'''CAL-05 검색 기능''' - 사용자는 장소, 일기 내용을 이용해 일기를 검색할 수 있다. || D || 중 ||
|-
| DIA || 일기 페이지 || '''DIA-01 필수 사진 선택 ''' - 사용자는 업로드한 사진 중 꼭 선택되야하는 사진을 9장 이하로 선택한다. || D || 상 ||
|-
| || || '''DIA-02 사진 선택 AI''' - 사용자가 갤러리에서 사진을 여러장 선택하면 AI가 자동으로 베스트샷 사진을 선택하여 저장한다. || D || 상 || 필수 사진 포함 최대 9장
|-
| || || '''DIA-03 사진 조회''' - 사용자는 쓸어넘기기를 통해 사진을 볼 수 있다. - 사용자는 가로 스크롤바로 사진을 넘겨볼 수 있다. - 사용자는 버튼을 통해 업로드된 사진을 한 화면에서 볼 수 있다.|| D || 상 ||
|-
| || || '''DIA-04 포커스 키워드 선정''' - 사용자는 선택된 사진에 대해 키워드(인물, 풍경, 음식, 사물, 동물, 기타)를 선택할 수 있다. - 사용자는 본인이 원하는 키워드를 추가할 수 있다. || D || 상 || 키워드 개수 제한 없음
|-
| || || '''DIA-05 내가 쓰기 설정''' - 사용자는 사진 별 키워드를 설정한 후 AI 초안 작성 버튼을 누르거나 직접 쓰기 버튼을 선택할 수 있다. || D || 중 ||
|-
| || || '''DIA-06 일기 초안 작성''' - ai는 사진을 메타데이터, 포커스 키워드를 기반으로 분석하여 일기 초안을 작성해준다. - 사용자는 초안을 수정하거나 확정할 수 있다. - ai는 일기를 분석해 초기 감정 이모티콘을 설정해준다. || D || 상 ||
|-
| || || '''DIA-07 일기 초안 수정''' - 사용자는 일기 수정 시 text 명령을 통해 초안을 수정할 수 있다. || D || 상 ||
|-
| || || '''DIA-08 일기 좋아요 기능''' - 사용자는 일기에 좋아요 태그를 할 수 있다. || D || 상 ||
|-
| || || '''DIA-09 사진 순서 수정''' - 사용자는 드래그 앤 드롭으로 사진 순서를 수정할 수 있다. || D || 중 ||
|-
| || || '''DIA-10 감정 이모티콘 설정''' - 사용자는 일기 초안을 수정하거나 확정할 때 감정 이모티콘을 설정할 수 있다. || D || 중 ||
|-
| MY || 마이 페이지 || '''MY-01 닉네임 수정''' - 닉네임 디스플레이 및 수정 기능 || D || 중 || 글자 수 10자 제한
|-
| || || '''MY-02 일기 통계''' - 월/년 단위 일기 통계 - 총 일기 개수 디스플레이 || D || 중 ||
|-
| || || '''MY-03 앨범 조회''' - 사용자는 “좋아요”표시 앨범과 장소 기반 분류 앨범, 스마트 앨범을 볼 수 있다. || D || 상 ||
|-
| || ||'''MY-04 좋아요 앨범''' - 사용자는 “좋아요”를 표시한 일기들을 볼 수 있다. || D || 상 ||
|-
| || ||'''MY-05 장소 기반 분류 앨범''' - 메타데이터를 활용해 장소별로 사진을 자동 분류 예: “일본 여행 앨범”, “서울 여행 앨범” 등의 카테고리 생성 || D || 중 ||
|-
| SET || 설정 페이지 || '''SET-01 고객문의''' - Q&A, 이용약관(서비스 이용약관, 개인정보 수집 이용 동의) || D || 중 ||
|-
| || ||'''SET-02 말투 커스터마이징''' - 회원가입 시 초기설정 후 마이페이지에서 수정 가능하다. - 사용자는 원하는 말투를 선택할 수 있다. - 키워드 별 템플릿이 주어지고, 사용자가 템플릿을 원하는 대로 수정할 수 있다 || D || 상 ||
|-
| || ||'''SET-03 디스플레이 키워드 설정''' - 사용자는 디스플레이될 키워드를 설정할 수 있다. || D || 중 ||
|-
| || || '''SET-04 휴지통''' - 삭제된 일기 임시저장 - 삭제한 일기 30일 후 영구삭제 - 영구 삭제 버튼을 누르면 일기 영구삭제 - 사용자는 휴지통에 있는 모든 일기를 한번에 삭제할 수 있다. || D || 중 ||
|-
| || || '''SET-05 알림 On/Off ''' - 사진 찍기 알림 기능 온오프 - 시간 지정 가능 || D || 상 ||
|-
| || || '''SET-6 로그아웃/회원탈퇴''' - 사용자는 계정을 로그아웃/회원탈퇴할 수 있다. || D || 상 ||
|}

====설계 사양====
''' 1. 거시적 기능 분할 및 각 기능의 구체 설계사양'''
{| class="wikitable"
! '''기능'''!! '''주요 사양'''
|-
| '''사용자 인증''' || SNS 계정 연동(카카오, 네이버, 애플)
|-
| '''사진 기반 기록''' || 사진 업로드, 메타데이터 활용
|-
| '''캘린더 기반 관리''' || 날짜 선택, 일기 유무 표시, 기록 추가 기능
|-
| '''일기 작성(AI)''' || AI 베스트샷 추천, 포커스 키워드 입력, 감정 이모티콘, 텍스트 명령 수정
|-
| '''말투 커스터마이징''' || 말투 템플릿 제공, 수정 가능, 개인화된 AI 일기 생성
|-
| '''마이페이지 및 통계''' || 닉네임 수정, 월/연도별 통계
|-
| '''앨범 분류''' || 좋아요 앨범, 장소 기반 분류
|}

''' 2. 설계사양 변수 중요도 계수 '''
{| class="wikitable"
! '''변수'''!! '''중요도 계수 (1~5)'''
|-
| '''사용자 편의성''' || 5
|-
| '''AI 정확도''' || 5
|-
| '''반응 속도''' || 4
|-
| '''UI/UX 디자인''' || 4
|-
| '''개인화 설정의 자유도''' || 4
|-
| '''데이터 보안''' || 4
|-
| '''저장 기능''' || 3
|}

===개념설계안===

'''가. 핵심 아이디어''' 
'''아이디어 1: “사진이 시작점인 AI 일기장”'''
 
'''설명''': 사용자가 하루 중 의미 있는 사진을 먼저 업로드하면, AI가 그날의 분위기와 키워드 분석을 통해 감성적인 일기 초안을 자동 작성. 사용자는 이를 수정하거나 감정 이모티콘, 말투를 설정하여 완성. 
'''특징''': 
말투 커스터마이징으로 AI 일기 문체 조절 가능 
사진 기반 메모리 앨범 자동 생성 
STT(음성 인식)으로 빠른 수정 지원 
'''도식 예시:''' 
사진 → 키워드 선택 → AI 일기 초안 → 수정 및 확정 → 캘린더 등록 

'''아이디어 2: “AI 스코어 기반 베스트샷 자동 추출기”''' 
'''설명:''' 사용자가 업로드한 사진에 대해, 단순 미적 점수(aesthetic score)에 이미지의 선명도, 중복 여부, 다양성을 고려하여 일기 작성에 어울리는 베스트샷을 추출합니다. CLIP 모델 기반 결과와 MLLM 기반 결과를 앙상블하여 최종 결과를 산출합니다. 
'''특징:''' 
감성 전달력을 수치화하여 정량적 기준 도입 
다양한 수치 기반 베스트샷 선별로 사용자 만족도 상승 
사진 분석을 통한 자동화된 일기 흐름 제공 
'''도식 예시:''' 사진 업로드 → CLIP 모델 기반 이미지 선택 + MLLM 기반 이미지 선택 -> 결과 앙상블 

'''아이디어 3: “말투 맞춤형 일기 생성기”''' 
'''설명''': 유저가 자신의 성향(예: 담백, 감성, 친구에게 말하듯)을 설정하면 AI가 해당 스타일로 일기를 생성. 직접 프롬프트를 수정하여 말투를 세밀하게 다듬을 수 있음. 
'''특징''': 
고정된 말투가 아닌, 사용자 정의 말투 제공 
감성적 개인화의 극대화 

'''나. User Flow Diagram''' 
[[파일:Flowchart_aPPLY.png]] 

'''다. 핵심 기능 시퀀스 다이어그램''' 
사진 업로드에서 자동 일기 생성까지의 상세 흐름을 나타낸 시퀀스 다이어그램 
[[파일:Sequence_diagram_aPPLY.png]]

===이론적 계산 및 시뮬레이션===
◇ MLLM(Multimodal Large Language Model)의 일기 생성 Prompt Engineering

사용자가 제공한 이미지와 해당 이미지에 대한 정보(날짜, 위치, 포커스 키워드)를 바탕으로, 사용자의 말투에 맞춘 자연스러운 일기 형식의 텍스트를 생성하도록 Prompt Engineering을 진행하였다. 이를 위해 아래와 같이 여러 버전의 프롬프트 템플릿이 작성되었으며 각 버전은 기존 프롬프트의 한계점을 보완하거나 개선하기 위한 실험적 시도를 포함한다. 

1. Single Image Prompt 
(1) ver1.0 
[[파일:Single_prompt_ver10_aPPLY.png]] 

(2) ver2.2 
[[파일:Single_prompt_ver22_aPPLY.png]]
 
2. Multi Image Prompt 
(1) ver2.0 
[[파일:Multi_prompt_ver20_aPPLY.png]] 
(2) ver3.3 
[[파일:Multi_prompt_ver33_aPPLY.png]]
 

◇ MLLM(Multimodal Large Language Model)의 이미지 선택 Prompt Engineering

MLLM 기반 이미지 평가 시스템에서 최종적으로 선택할 최상의 이미지 9장을 결정하기 위해 Prompt Engineering을 진행하였다. 프롬프트 내에 이미지 평가 기준을 명확히 제시하며 해당 기준에 따라 이미지에 부여된 번호를 반환하도록 지시했다. 여러 버전의 프롬프트 템플릿이 작성되었으며 각 버전은 기존 프롬프트의 한계점을 보완하거나 개선하기 위한 실험적 시도를 포함한다. 
1. ver1.0 
[[파일:Img_select_ver10_aPPLY.png]]

2. ver2.0 
[[파일:Img_select_ver20_aPPLY.png]]

◇ CLIP(Contrastive Language-Image Pre-training) 모델과 Pre-trained MLP(Multi-layer Perceptron)을 이용한 이미지 선택
[[파일:Clip_model_aPPLY.png]] 
CLIP 모델을 사용해 각 이미지를 768차원의 임베딩 벡터로 변환한다. 이 벡터는 이미지의 전역적 특징을 표현한다. 추출된 임베딩 벡터에 대해 L2 정규화를 수행한다. 이 정규화 과정을 통해 벡터 크기가 1이 되며 각 벡터 간 cosine similarity를 비교하기 용이해진다. 
정규화된 임베딩 벡터를 받아 MLP(Multi-layer Perceptron)을 통해 미적 점수를 산출한다. MLP는 다음과 같은 계층 구조를 가진다. Input Layer: 768차원, Hidden Layer: Linear(768 → 1024) → Dropout → Linear(1024 → 128) → Dropout → Linear(128 → 64) → Dropout → Linear(64 → 16), Output Layer: Linear(16 → 1) 
두 개의 정규화된 임베딩 벡터에 대해 코사인 유사도는 다음과 같이 계산된다. 
[[파일:CosineSim_aPPLY.PNG]] 
계산된 유사도는 모든 이미지 쌍에 대해 행렬 형태로 저장된다. 
각 이미지 i에 대해, 자기 자신을 제외한 다른 이미지들과의 cosine similarity의 평균을 계산한다. 
[[파일:MeanSim_aPPLY.PNG]] 

여기서 N은 이미지의 총 개수이고, S는 Similarity이다. 평균 유사도의 역수를 사용하여 이미지가 다른 이미지와 얼마나 다른지를 평가한다. 평균 유사도가 낮을수록 다양성 점수가 높아지게 된다. 
정규화된 미적 점수 A_i와 정규화된 다양성 점수 D_i를 가중치에 따라 결합하여 최종 점수를 산출한다. 
[[파일:Clip_finalScore_aPPLY.PNG]] 

최종 순위를 산출한 후, 미리 정해진 threshold 값을 기준으로 매우 유사한 이미지를 중복 처리한다. 선택한 이미지 목록에 대해, 새 이미지가 기존 선택된 이미지와의 모든 유사도가 0.9 미만이면 선택한다.또한 각 이미지에 대해, 이미 선택된 이미지들과의 유사도 합에 일정 가중치를 곱한 값을 원래 미적 점수에서 차감한다. 
[[파일:Clip_adjustedScore_aPPLY.PNG]] 

이 과정을 통해 유사한 이미지가 많을수록 최종 점수가 낮아지도록 보정한다. 
이미지 간의 cosine similarity가 미리 설정된 threshold 값 이상인 경우, 같은 cluster로 묶는다. Clustering 알고리즘은 아직 할당되지 않은 이미지를 기준으로 같은 그룹에 속하는 이미지를 선정한다. 각 cluster 내에서 미적 점수가 가장 높은 이미지를 대표 이미지로 선택한다.

◇ MLLM과 CLIP 모델을 앙상블하여 이미지 선택
MLLM(Multimodal Large Language Model)은 텍스트와 이미지 정보를 통합적으로 처리하고, 고차원적으로 의미를 해석 및 미적 점수 산출에 강점을 가진다. 특히 사람의 선호도나 추상적 기준(아름다움, 조화로움, 감정적 분위기 등)을 반영하는데 있어 자연어 텍스트만으로 평가가 가능하기 때문에 기존의 단일 벡터 기반 모델과 차별점이 있다. 
반면, CLIP 기반 모델은 이미지 간 중복(유사도가 높은 이미지들) 제거 및 정량적 유사도 계산에 좋은 성능을 보인다. CLIP 임베딩 기반의 cosine similarity는 이미지 간의 유사도를 정밀하게 측정할 수 있으며, 이로부터 중복 제거, 이미지 다양성, 클러스터링 등 다양한 후처리 전략을 안정적으로 적용할 수 있다. 
따라서 MLLM과 CLIP 두 모델의 강점을 상호보완적으로 결합하기 위해 다음과 같은 앙상블 방식을 채택하였다. 
'''1. CLIP 기반 클러스터링 전처리''' 
- CLIP 모델로부터 얻은 이미지 임베딩을 기반으로 cosine similarity를 계산하고, threshold 이상으로 유사한 이미지들을 하나의 cluster로 묶는다. 각 cluster는 시각적으로 매우 유사한 이미지들의 집합으로 간주된다. 
'''2. Cluster 대표 이미지 선별''' 
- 각 cluster 내에서 미적 점수가 가장 높은 이미지를 대표 이미지로 선정한다. 이로써 중복성이 제거된, 다양성을 갖춘 이미지 집합이 구성된다. 
'''3. MLLM 기반 최종 평가 및 선택''' 
- CLIP을 통해 사전 필터링된 대표 이미지들을 MLLM의 입력으로 넣어, 프롬프트에 정의된 평가 기준(미적 품질, 다양성, 스타일 등)에 따라 최종적으로 9장의 이미지를 선택하도록 한다. 이 단계에서는 사람의 추상적 선호를 잘 반영할 수 있는 MLLM의 장점을 적극 활용한다. 

이러한 앙상블 구조는 CLIP이 제공하는 정량적 유사도 분석을 통해 중복을 제거하고, MLLM의 의미 기반 평가 능력을 통해 고차원적인 미적 기준을 반영할 수 있어, 보다 신뢰도 높은 이미지 선택 결과를 도출한다. 

◇ 최종 모델 선택
실제 구현 및 배포 단계에서, 서비스 제공 시 유저가 체감하는 응답 속도를 고려하면 CLIP 모델은 GPU 자원을 기반으로 운영되어야 했다. 그러나 클라우드 GPU 서버의 비용이 매우 높아, 실제 앱 배포 이후 장기적인 유지가 현실적으로 어려울 것으로 판단되었다. 이에 따라 GPU 서버를 필요로 하지 않는 MLLM 단독 기반의 이미지 평가 방식을 최종적으로 채택하였다. 이는 실용성과 비용 효율성을 종합적으로 고려한 결정이다.

===상세설계 내용===
'''가. 기술 스택'''

''1. Front-end''

'''1.1 React Native Expo'''

* React Native 기반의 개발 플랫폼으로, 크로스 플랫폼 모바일 애플리케이션을 효율적으로 개발할 수 있다.
* Expo의 내장 API와 컴포넌트를 활용하여 이미지 선택, 위치 정보 등의 네이티브 기능을 간편하게 구현한다.
* 개발 환경 설정의 복잡성을 줄이고, iOS와 Android 동시 개발을 통해 효율성을 극대화한다.
* expo-image-picker를 통한 사진 업로드 기능과 expo-notifications를 활용한 푸시 알림 서비스를 구현한다.

'''1.2 소셜 로그인 통합'''

* @react-native-seoul/kakao-login과 @react-native-seoul/naver-login을 활용한 간편 로그인 서비스를 구현한다.
* expo-apple-authentication을 통한 Apple 로그인 지원으로 iOS 사용자 편의성을 향상시킨다.
* expo-auth-session을 활용한 OAuth 2.0 인증 플로우를 구현한다.

''2. Back-end''

'''2.1 Spring Boot'''

* 스프링 프레임워크를 기반으로 한 빠르고 간편한 백엔드 프레임워크이다.
* Spring Security, Spring Data JPA, Spring Validation 등의 다양한 기능을 플러그인 방식으로 쉽게 확장시킬 수 있다.
* 내장 톰캣 서버를 통한 독립 실행 가능한 애플리케이션 구성으로 배포와 운영을 간소화한다.
* AI 서버와의 HTTP 통신을 위한 RestTemplate/WebClient를 활용하여 마이크로서비스 아키텍처를 구현한다.

'''2.2 Spring Data JPA'''

* 데이터베이스와의 상호작용을 간단하게 만들어주는 ORM 기술이다.
* JPA를 통한 객체와 관계형 데이터베이스 간의 매핑을 자동화한다.
* Repository 패턴을 통한 데이터 액세스 계층의 추상화로 개발 생산성을 향상시킨다.
* 사용자 정보, 일기 데이터, 사진 메타데이터 등의 관계형 데이터를 효율적으로 관리한다.

'''2.3 Spring Security'''

* 스프링 프레임워크 기반의 포괄적인 보안 프레임워크이다.
* JWT 기반 무상태 인증 시스템을 구현하여 확장성과 성능을 최적화한다.
* OAuth 2.0 소셜 로그인 통합으로 사용자 편의성과 보안성을 동시에 확보한다.
* 개인 사진과 일기 데이터 보호를 위한 강화된 보안 정책을 적용한다.

'''2.4 MySQL'''

* 관계형 데이터베이스 관리 시스템(RDBMS)으로 ACID 특성을 보장하는 안정적인 데이터 저장소이다.
* 트랜잭션 지원을 통한 데이터 무결성 보장과 동시성 제어를 수행한다.

''3. AI''

'''3.1 FastAPI'''

* Python 기반의 웹 프레임워크로 AI 모델 서빙에 최적화되어 있다.
* Spring Boot 백엔드 서버로부터 이미지 분석 요청을 받아 AI 처리 결과를 반환하는 마이크로서비스로 동작한다.

'''3.2 OpenAI GPT API'''

* OpenAI에서 제공하는 대규모 언어 모델 API로 고품질의 자연어 생성 서비스를 제공한다.
* GPT-4.1을 활용한 일기 자동 생성과 GPT-4.1-nano를 통한 감정 이모티콘 추천 기능을 구현한다.
* GPT-4o-mini를 활용하여 업로드된 여러 사진 중 베스트샷을 자동 선별하는 이미지 분석 기능을 제공한다.
* 프롬프트 엔지니어링을 통한 개인화된 일기 작성 스타일 적용으로 사용자별 맞춤형 콘텐츠를 생성한다.

'''3.3 Google Gemini API'''

* Google에서 제공하는 멀티모달 AI 모델로 일기 수정 및 개선 서비스를 제공한다.
* Gemini-2.5-flash를 활용하여 사용자가 작성한 일기의 문체와 내용을 자연스럽게 수정한다.

'''3.4 Pydantic'''

* FastAPI와 긴밀하게 통합된 데이터 검증 라이브러리로 API 요청/응답 데이터의 타입 안전성을 보장한다.
* 자동 데이터 검증과 직렬화/역직렬화를 통한 안정적인 데이터 처리를 수행한다.

''4. Infra''

'''4.1 AWS EC2 (Elastic Compute Cloud)'''

* Spring Boot 백엔드 서버와 FastAPI AI 서버를 각각 독립된 인스턴스에서 호스팅한다.
* 가상 서버 인스턴스를 제공하여 마이크로서비스 아키텍처를 안정적으로 운영한다.

'''4.2 AWS S3 (Simple Storage Service)'''

* 사용자가 업로드하는 이미지 파일을 안전하고 확장 가능한 객체 스토리지에 저장한다.

'''4.3 AWS RDS (Relational Database Service)'''

* MySQL 데이터베이스를 클라우드에서 안정적으로 운영하기 위한 서비스이다.
* 클라우드 환경에서의 확장성과 안정성을 확보하여 사용자 및 일기 데이터를 관리한다.

'''4.4 AWS Route 53'''

* 고성능 DNS 웹 서비스로 도메인 관리와 트래픽 라우팅을 처리한다.

''5. CI/CD''

'''5.1 GitHub Actions'''

* GitHub 저장소와 통합된 CI/CD 플랫폼으로 코드 변경 시 자동화된 빌드와 배포를 수행한다.
* YAML 기반의 워크플로우 정의를 통해 테스트, 빌드, 배포 파이프라인을 코드로 관리한다.
* 브랜치 전략과 연동하여 개발, 스테이징, 프로덕션 환경별 자동 배포를 구현한다.
* AWS CLI와 연동하여 EC2 인스턴스 배포 자동화를 처리한다.

'''나. 데이터 흐름도'''

* 소셜 로그인
[[파일:데이터2.jpg|400픽셀|]]

* 사진 업로드
[[파일:데이터3.jpg|600픽셀|]]

* 사진 선택 및 AI 추천
[[파일:데이터4.jpg|600픽셀|]]

* 일기 생성
[[파일:데이터5.jpg|600픽셀|]]

'''다. ERD'''

* 전체 ER 다이어그램
[[파일:erd.jpg|600픽셀|]]

'''라. 클래스 다이어그램'''

* User 관련 클래스
[[파일:클래스1.jpg|600픽셀|]]

* Photo 관련 클래스
[[파일:클래스2.jpg|600픽셀|]]

* Diary 관련 클래스
[[파일:클래스3.jpg|600픽셀|]]

* photo <-> diary 관계
[[파일:클래스4.jpg|600픽셀|]]

* Album 관련 클래스
[[파일:클래스5.jpg|600픽셀|]]

* 키워드 관련 다이어그램
[[파일:클래스6.jpg|600픽셀|]]

* 약관 관련 다이어그램
[[파일:클래스7.jpg|600픽셀|]]

==결과 및 평가==
===완료 작품의 소개===
====작동 장면====
'''가. 작동 장면(iOS)''' 
- 로그인 및 회원가입 
[[파일:로그인1.jpg|1000픽셀]]
[[파일:로그인2.jpg|750픽셀]]
[[파일:로그인3.jpg|1000픽셀]]

- 홈 화면 
[[파일:홈화면.jpg|750픽셀]]

- 캘린더 화면 
[[파일:캘린더1.jpg|1000픽셀]]
[[파일:캘린더2.jpg|750픽셀]]

- 일기 화면(생성, 수정, 삭제) 
[[파일:일기1.jpg|1000픽셀]]
[[파일:일기2.jpg|1000픽셀]]
[[파일:일기3.jpg|1000픽셀]]
[[파일:일기4.jpg|1000픽셀]]
[[파일:일기5.jpg|1000픽셀]]
[[파일:일기6.jpg|750픽셀]]

- 프로필 화면 
[[파일:프로필.jpg|750픽셀]]

- 설정 화면 
[[파일:설정1.jpg|1000픽셀]]
[[파일:설정2.jpg|1000픽셀]]
[[파일:설정3.jpg|1000픽셀]]
[[파일:설정4.jpg|500픽셀]]

'''나. 작동 장면(Android)''' 
iOS의 작동 장면과 동일하기에 생략함 
[[파일:Android.jpg|250픽셀]]

'''다. 앱스토어 배포''' 
[[파일:Appstore1.jpg|600픽셀]]
[[파일:Appstore_review_score_aPPLY.jpg|300픽셀]]
[[파일:Appstore_review_aPPLY.jpg|300픽셀]]

===관련사업비 내역서===
{| class="wikitable" style="text-align: center;"
|+ style="text-align: right; caption-side: top;" | (단위 : 천원)
|-
! rowspan="2" | 구분
! rowspan="2" | 항 목 (품명, 규격)
! rowspan="2" | 수량
! rowspan="2" | 단가
! colspan="2" | 금 액
! rowspan="2" | 비고
|-
! 계 !! 현금
|-
| rowspan="6" | 직접 개발비
| Openai Api 크레딧
| 1
| 32
| 32
| 32
| GPT-4.1 모델, 토큰 사용량 기준
|-
| Amazon_AWS 서버 사용비
| 1
| 145
| 145
| 145
| 월 6.8만원 × 2개월
|-
| Apple Developer Program 구독비
| 1
| 129
| 129
| 129
| 연간 구독료
|-
| CURSOR AI 구독
| 3
| 28
| 84
| 84
| 개발 도구 구독료
|-
| claude ai 구독
| 1
| 31
| 31
| 31
| ai 구독료
|-
| 회의비
| 1
| 120
| 120
| 120
|
|-
|
| ! style="text-align: center;" | 합 계
|
|
| 541
| 541
|
|}

===완료작품의 평가===
{| class="wikitable" style="text-align: center;"
|-
! style="width: 12%;" | 평가 항목
! style="width: 30%;" | 평가 방법
! style="width: 25%;" | 적용기준
! style="width: 23%;" | 개발 목표치
! style="width: 5%;" | 비중 (%)
! style="width: 5%;" | 평과 결과
|-
| '''1. 기능 구현 완전성'''
| style="text-align: left;" | - 요구사항 문서 (사진 업로드, 일기 생성, 캘린더 표시, 앨범, 마이페이지 기능)에 따른 각 기능 테스트 - 시나리오별로 Pass/Fail 여부 확인 
| style="text-align: left;" | - 필수 기능(상) 및 중요 기능(중) 기준 100% 구현 - 선택(하) 기능 일부 구현 유무 평가
| style="text-align: left;" | - 필수·중요 기능 100% 구현 - 선택 기능 50% 이상 구현
| 30%
| 10/10
|-
| '''2. 안정성'''
| style="text-align: left;" | - 앱 사용 시 오류 로그, 예외 발생 모니터링 - 비정상 종료 횟수 측정
| style="text-align: left;" | - 사용자 시나리오 중 오류 발생 0건
| style="text-align: left;" | - 정상 시나리오에서 오류 0건 - 예외 상황 최소화
| 20%
| 9/10
|-
| '''3. 응답 속도'''
| style="text-align: left;" | - 사용자 입력(사진 업로드, 일기 업로드, 일기 조회)에 대한 서버 응답 시간 측정 - 클라이언트-서버 간 지연테스트
| style="text-align: left;" | - 90% 이상의 요청 처리 시간 2초 이내 - 최대 요청 처리 시간 5초 이내
| style="text-align: left;" | - 평균 응답속도 2초 이내 - 응답속도 5초 초과 0건
| 10%
| 8/10
|-
| '''4. AI 정확도'''
| style="text-align: left;" | - AI 자동 분류 (베스트샷 선정, 일기 초안) 품질 평가 - 테스트용 데이터셋 준비 후 결과 정확도 측정
| style="text-align: left;" | - 샘플 데이터셋을 통한 AI 분류 정확도 80% 이상 - 일기 초안 적합도 80% 이상
| style="text-align: left;" | - AI 사진 분류 정확도 80% 이상 - 자동 생성된 일기 초안 정확도 80% 이상
| 25%
| 9/10
|-
| '''5. UI/UX'''
| style="text-align: left;" | - 사용자 테스트(설문) 및 피드백 수집 - 직관성, 접근성, 사용 편의성 평가
| style="text-align: left;" | - 5점 척도 평가 시 평균 4점 이상 - 10명 이상의 베타테스터 중 70% 이상이 긍정 의견
| style="text-align: left;" | - 평균 5점 이상 - 긍정 응답률 70% 이상
| 10%
| 10/10
|-
| '''6. 보안'''
| style="text-align: left;" | - 회원가입·로그인, 개인정보 보호 점검 - DB 암호화, 인증/인가 로직
| style="text-align: left;" | - 중요 취약점 (개인정보 보호, SQL 인젝션 등) 0건
| style="text-align: left;" | - 주요 취약점 0건 - 비밀번호·세션 토큰 안전성 확보
| 5%
| 9/10
|}

===향후계획===
* '''어려웠던 내용들''' 
** Git 협업 충돌 문제 - 브랜치 병합 시 코드 충돌 빈발로 개발 일정 지연 
** AI 모델 성능 한계 - GPT API 응답 품질 불안정으로 일기 품질 편차 발생 
** AWS 인프라 관리 이슈 - 클라우드 비용 관리 및 보안 설정의 복잡성 
** 비동기 처리 복잡성 - WebSocket 연결 불안정 및 예외 처리 구현 어려움 
** 성능 최적화 부족 - 대용량 이미지 처리 시 응답 속도 저하 문제 
** 앱스토어 심사 과정 - 애플 앱 스토어 정책 이해 및 심사 통과의 복잡성 

* '''차후 구현할 내용''' 
** AI 기능 고도화 - 사용자별 글쓰기 패턴 학습으로 개인화 정확도 향상 
** 소셜 기능 추가 - 가족/친구와 일기 공유 및 댓글 기능 구현 
** 다국어 지원으로 해외 사용자 확대 
** 테마 커스터마이징 및 다크모드 지원 

* '''수익 모델''' 
{| class="wikitable" style="text-align: center;"
|-
! 플랜명
! 가격
! 주요 기능
! AI/서버 비용 고려
|-
| '''Basic'''
| 무료
| style="text-align: left;" | - AI 일기 초안 생성 (월별 3회 제한) - AI 베스트샷 추천 (월별 1회 제한) - 일기 수정 (수동 입력만 가능) - 말투 커스터마이징 (선택만 가능) - 광고 포함
|
|-
| '''Premium'''
| (연간 월 3,900) '''월 4,900'''
| style="text-align: left;" | - AI 일기 초안 생성 (1일 1회 제한) - AI 베스트샷 추천 (1일 1회 제한) - 일기 수정 (AI 수정 가능 1일 1회 제한) - 말투 커스터마이징 (직접 가능) - 광고 제거
| style="text-align: left;" | - AI 일기 초안 생성: 0.01달러 - AI 베스트샷 추천: 0.03달러 - AI 일기 수정 : 0.01 달러 - 0.01 + 0.03 + 0.01 = 0.05달러 - 월에 한화로 대략 2100원
|-
| '''Pro'''
| (연간 월 8,800) '''월 9,900'''
| style="text-align: left;" | - Premium Plan 모든 기능 포함 - AI 기능 (생성, 추천, 수정) 무제한 - 향후 출시될 AI 기능 베타 참여 기회
|
|}

1분반-올인뷰

2026-03-11T07:26:59Z

Adcdc:

1분반-슈팅스타

2026-03-11T07:26:40Z

Adcdc:

1분반-Ludex

2026-03-11T07:26:14Z

Adcdc:

1분반-Locauto

2026-03-11T07:25:56Z

Adcdc:

1분반-DOS

2026-03-11T07:25:27Z

Adcdc:

1분반-aPPLY

2026-03-11T07:24:57Z

Adcdc:

2026학년도 2학기

2026-03-11T06:22:02Z

Adcdc: 새 문서: ==Course Information== * 과목명 : [2026.2학기] 컴퓨터과학종합설계 * 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반) * 컴퓨터...

==Course Information==
* 과목명 : [2026.2학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2025년 1학기===
'''[[1분반-aPPLY]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-DOS]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-Locauto]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-Ludex]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-슈팅스타]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-올인뷰]]''' - 서*진, 김*서, 권*재 
'''[[1분반-자이로드롭]]''' - 조*채, 이*호, 이*제 
'''[[2분반-Brain Overflow]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-Flat2Form]]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-마음의소리]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-캐슬코더]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

2026학년도 1학기

2026-03-11T06:21:25Z

Adcdc: /* 2025년 1학기 */

==Course Information==
* 과목명 : [2026.1학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2026년 1학기===
'''[[1분반-aPPLY]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-DOS]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-Locauto]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-Ludex]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-슈팅스타]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-올인뷰]]''' - 서*진, 김*서, 권*재 
'''[[1분반-자이로드롭]]''' - 조*채, 이*호, 이*제 
'''[[2분반-Brain Overflow]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-Flat2Form]]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-마음의소리]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-캐슬코더]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

2026학년도 1학기

2026-03-11T06:21:11Z

Adcdc: 새 문서: ==Course Information== * 과목명 : [2026.1학기] 컴퓨터과학종합설계 * 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반) * 컴퓨터...

==Course Information==
* 과목명 : [2026.1학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

== Ongoing Project==
===2025년 1학기===
'''[[1분반-aPPLY]]''' - 박*빈, 이*목, 박*찬, 양*슬 
'''[[1분반-DOS]]''' - 이*영, 장*빈, 문*서 
'''[[1분반-Locauto]]''' - 정*혁, 이*우, 최*훈, 정*호 
'''[[1분반-Ludex]]''' - 임*우, 김*호, 서*영, 이*진 
'''[[1분반-슈팅스타]]''' - 한*만, 정*원, 박*빈, 임*현 
'''[[1분반-올인뷰]]''' - 서*진, 김*서, 권*재 
'''[[1분반-자이로드롭]]''' - 조*채, 이*호, 이*제 
'''[[2분반-Brain Overflow]]''' - 권*호, 구*근, 김*주, 박*빈, 석*진, 송*희 
'''[[2분반-Flat2Form]]''' - 박*규, 김*현, 류*욱, 바****랑, 최*우 
'''[[2분반-마음의소리]]''' - 김*윤, 김*빈, 이*솔, 장*민, 김*하, 김*진, 판*하 
'''[[2분반-캐슬코더]]''' - 박*, 오*찬, 유*호, 경*수, 김*연, 오*훈

대문

2026-03-11T06:20:06Z

Adcdc: /* 서울시립대학교 컴퓨터과학부 Capstone project */

<div style="margin:30px 0px 0px 20px">
== 서울시립대학교 컴퓨터과학부 Capstone wiki 소개 ==
<div style="margin:0px 0px 40px 20px">
{|100%
|
* 서울시립대학교 컴퓨터과학부 Capstone wiki 입니다.
* 서울시립대학교 컴퓨터과학부 Capstone wiki는 각 과목별 Capstone 프로젝트에서 진행한 프로젝트를 바탕으로 구성되었습니다.
|}</div>

== 서울시립대학교 컴퓨터과학부 Capstone project ==
<div style="margin:0px 0px 40px 20px">
* [[2018학년도 1학기]]
* [[2018학년도 2학기]]
* [[2019학년도 1학기]]
* [[2019학년도 2학기]]
* [[2020학년도 1학기]]
* [[2020학년도 2학기]]
* [[2021학년도 1학기]]
* [[2021학년도 2학기]]
* [[2022학년도 1학기]]
* [[2022학년도 2학기]]
* [[2023학년도 1학기]]
* [[2023학년도 2학기]]
* [[2024학년도 1학기]]
* [[2024학년도 2학기]]
* [[2025학년도 1학기]]
* [[2025학년도 2학기]]
* [[2026학년도 1학기]]
* [[2026학년도 2학기]]
</div>

== 교육목표 ( 졸업 후 2-3년 내에 갖추어야 할 능력 ) ==
<div style="margin:0px 0px 40px 30px">
A) 이론과 실무능력을 겸비한 창의적인 컴퓨터 전문 인재 양성 
B) 공학윤리의식과 원활한 소통능력을 갖춘 리더형 인재 양성 
C) 지속적인 자기계발을 통하여 미래 정보화 사회 발전에 공헌하는 글로벌 인재 양성 
</div>

== 프로그램 학습성과 (졸업시점에 갖추어야 할 능력) ==
<div style="margin:0px 0px 40px 20px">
* PO1(공학기반) 컴퓨터과학에 필요한 수학, 기초과학, 공학의 지식과 정보기술을 공학문제 해결에 응용할 수 있는 능력
* PO2(분석실험) 데이터를 분석하고 주어진 사실이나 가설을 실험을 통하여 확인할 수 있는 능력
* PO3(문제정의) 컴퓨터과학 관련 공학문제를 정의하고 공식화할 수 있는 능력
* PO4(도구활용) 컴퓨터과학 관련 공학문제를 해결하기 위해 최신 정보, 연구결과, 적절한 도구를 활용할 수 있는 능력
* PO5(설계능력) 현실적 제한조건을 고려하여 컴퓨터과학 시스템, 요소, 공정 등을 설계할 수 있는 능력
* PO6(팀웍능력) 컴퓨터과학 공학문제를 해결하는 프로젝트 팀의 구성원으로서 팀 성과에 기여할 수 있는 능력
* PO7(의사소통) 컴퓨터과학인으로서 다양한 환경에서 효과적으로 의사소통할 수 있는 능력
* PO8(영향이해) 컴퓨터과학적 해결방안이 보건, 안전, 경제, 환경, 지속가능성 등에 미치는 영향을 이해할 수 있는 능력
* PO9(직업윤리) 컴퓨터과학공학인으로서 직업윤리와 사회적 책임을 이해할 수 있는 능력
* P010(자기계발) 기술환경 변화에 따른 자기계발의 필요성을 인식하고 지속적이고 자기주도적으로 학습할 수 있는 능력
</div>
</div>

대문

2026-03-11T06:19:34Z

Adcdc: /* 서울시립대학교 컴퓨터과학부 Capstone project */

<div style="margin:30px 0px 0px 20px">
== 서울시립대학교 컴퓨터과학부 Capstone wiki 소개 ==
<div style="margin:0px 0px 40px 20px">
{|100%
|
* 서울시립대학교 컴퓨터과학부 Capstone wiki 입니다.
* 서울시립대학교 컴퓨터과학부 Capstone wiki는 각 과목별 Capstone 프로젝트에서 진행한 프로젝트를 바탕으로 구성되었습니다.
|}</div>

== 서울시립대학교 컴퓨터과학부 Capstone project ==
<div style="margin:0px 0px 40px 20px">
* [[2018학년도 1학기]]
* [[2018학년도 2학기]]
* [[2019학년도 1학기]]
* [[2019학년도 2학기]]
* [[2020학년도 1학기]]
* [[2020학년도 2학기]]
* [[2021학년도 1학기]]
* [[2021학년도 2학기]]
* [[2022학년도 1학기]]
* [[2022학년도 2학기]]
* [[2023학년도 1학기]]
* [[2023학년도 2학기]]
* [[2024학년도 1학기]]
* [[2024학년도 2학기]]
* [[2025학년도 1학기]]
* [[2025학년도 2학기]]
</div>

== 교육목표 ( 졸업 후 2-3년 내에 갖추어야 할 능력 ) ==
<div style="margin:0px 0px 40px 30px">
A) 이론과 실무능력을 겸비한 창의적인 컴퓨터 전문 인재 양성 
B) 공학윤리의식과 원활한 소통능력을 갖춘 리더형 인재 양성 
C) 지속적인 자기계발을 통하여 미래 정보화 사회 발전에 공헌하는 글로벌 인재 양성 
</div>

== 프로그램 학습성과 (졸업시점에 갖추어야 할 능력) ==
<div style="margin:0px 0px 40px 20px">
* PO1(공학기반) 컴퓨터과학에 필요한 수학, 기초과학, 공학의 지식과 정보기술을 공학문제 해결에 응용할 수 있는 능력
* PO2(분석실험) 데이터를 분석하고 주어진 사실이나 가설을 실험을 통하여 확인할 수 있는 능력
* PO3(문제정의) 컴퓨터과학 관련 공학문제를 정의하고 공식화할 수 있는 능력
* PO4(도구활용) 컴퓨터과학 관련 공학문제를 해결하기 위해 최신 정보, 연구결과, 적절한 도구를 활용할 수 있는 능력
* PO5(설계능력) 현실적 제한조건을 고려하여 컴퓨터과학 시스템, 요소, 공정 등을 설계할 수 있는 능력
* PO6(팀웍능력) 컴퓨터과학 공학문제를 해결하는 프로젝트 팀의 구성원으로서 팀 성과에 기여할 수 있는 능력
* PO7(의사소통) 컴퓨터과학인으로서 다양한 환경에서 효과적으로 의사소통할 수 있는 능력
* PO8(영향이해) 컴퓨터과학적 해결방안이 보건, 안전, 경제, 환경, 지속가능성 등에 미치는 영향을 이해할 수 있는 능력
* PO9(직업윤리) 컴퓨터과학공학인으로서 직업윤리와 사회적 책임을 이해할 수 있는 능력
* P010(자기계발) 기술환경 변화에 따른 자기계발의 필요성을 인식하고 지속적이고 자기주도적으로 학습할 수 있는 능력
</div>
</div>

대문

2026-03-11T06:19:30Z

Adcdc: /* 서울시립대학교 컴퓨터과학부 Capstone project */

2분반-인테리

2025-11-07T07:04:36Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

<div>__TOC__</div>

==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 : ''' 00000000..

''' 영문 : ''' 00000000..

===과제 팀명===
00000..

===지도교수===
000 교수님

===개발기간===
2025년 3월 ~ 2025년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 ㅁㅁ공학부·과 20XXXXX0** 김**(팀장)

서울시립대학교 ㅁㅁ공학부·과 20XXXXX0** 정**

서울시립대학교 ㅁㅁ공학부·과 20XXXXX0** 조**

서울시립대학교 ㅁㅁ공학부·과 20XXXXX0** 이**

서울시립대학교 ㅁㅁ공학부·과 20XXXXX0** 남**

==서론==
===개발 과제의 개요===
====개발 과제 요약====
내용
====개발 과제의 배경====
내용
====개발 과제의 목표 및 내용====
내용

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
*전 세계적인 기술현황
내용
*특허조사 및 특허 전략 분석
내용
*기술 로드맵
내용

====시장상황에 대한 분석====
*경쟁제품 조사 비교
내용
*마케팅 전략 제시
내용

===개발과제의 기대효과===
====기술적 기대효과====
내용
====경제적, 사회적 기대 및 파급효과====
내용

===기술개발 일정 및 추진체계===
====개발 일정====
내용
====구성원 및 추진체계====
내용

==설계==
===설계사양===
====제품의 요구사항====
내용
====설계 사양====
내용

===개념설계안===
내용

===이론적 계산 및 시뮬레이션===
내용

===상세설계 내용===
내용

==결과 및 평가==
===완료 작품의 소개===
====프로토타입 사진 혹은 작동 장면====
내용
====포스터====
내용

===관련사업비 내역서===
내용

===완료작품의 평가===
내용

===향후계획===
내용

===특허 출원 내용===
내용

2분반-뮤즈

2025-11-07T07:04:25Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

2분반-Chat이루매

2025-11-07T07:04:15Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-팅글(tingle)

2025-11-07T07:04:05Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-위트

2025-11-07T07:03:56Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-심포니

2025-11-07T07:03:36Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-백세밥상

2025-11-07T07:03:15Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

1분반-TrendFeed

2025-11-07T07:03:00Z

Adcdc: 새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...

2025학년도 2학기

2025-11-07T07:01:02Z

Adcdc: /* Ongoing Project */

==Course Information==
* 과목명 : [2025.2학기] 컴퓨터과학종합설계
* 담당교수 : 최혁 교수님(01분반), 김진석 교수님(02분반)
* 컴퓨터과학부에서 배운 전공과목들을 응용하여, 기업체, 연구소 또는 기관에서 주어진 문제를 해결할 수 있는 시스템을 설계 및 구현 개발한다. 3-4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다.

===2025년 2학기===
'''[[1분반-TrendFeed]]''' - 주*원, 서**스, 강*우, 조*영 
'''[[1분반-백세밥상]]''' - 염*윤, 안*중혁, 부*은, 신*운 
'''[[1분반-심포니]]''' - 이*관, 박*환, 박*익, 배*찬 
'''[[1분반-위트]]''' - 김*지, 강*지, 주*은, 최*원, 이*경 
'''[[1분반-팅글(tingle)]]''' - 이*민, 김*은, 서*준, 조*빈 

'''[[2분반-Chat이루매]]''' - 이*림, 정*재, 최*용, 김*훈, 채*관 
'''[[2분반-뮤즈]]''' - 유*승, 조*진, 이*민, 이*호, 고*서 
'''[[2분반-인테리]]''' - 오*민, 류*화, 배*연, 한*민