스타시티즌 입문하시려는 분께 도움이 될만한 글인듯 싶어요.
----------
스타시티즌 3.0 정보가 담긴 독일 게임 잡지 Gamestar 의 컬럼을 Reddit 에 영문으로 kruben95님께서 요약 번역해주셨습니다. 영문 요약 번역본은 여기에서 보실 수 있습니다.
GameStar: The technique behind Star Citizen
스타시티즌의 기술들
- 크리스 로버츠에게 자주하는 질문은 "당신은 당신의 게임을 완성할 수 있다고 믿나요?" 입니다. 이러한 질문을 하는 이유는 큰 규모의 게임이며 기술적으로 만만치 않기 때문입니다. 크리스 로버츠와 그의 팀들은 완성할 수 있다고 확신합니다.
- 열정과 노하우가 대단히 인상적입니다.
- 모든 목표는 현재의 기술로 가능하다고 크리스로버츠는 말합니다.
- 하지만 모든 목표와 아이디어가 실현되야 하기 때문에 계획된 방식으로 구현되지 않는 것은 즐겁지 않거나 좋은 방법은 아닙니다.
- 기반 구축을 위해 팀은 엄청난 시간을 투자하였습니다. (게임 엔진 변경 등...)
- 마르코 콜베타와 카스텐 웬젤(전 Crytek 직원, 현 2년차 CIG 직원)은 스타시티즌이 사용하는 엔진은 크라이엔진이라 할 수 없다고 말했습니다. 사용중인 게임엔진에는 크라이엔진 코드 50% 와 나머지 50%는 새로 만든 코드를 사용하며 실질적으로 스타시티즌에 사용되는 코드 중 90%가 새로 만든 코드를 활용합니다.
- 2 가지 결과가 나온 리팩터 코드: 엄청난 크기의 게임속 우주와 오브젝트와의 상호작용 가능성
- 거대한 행성들이 포함된 태양계 시스템을 만들려면 엔진이 엄청난 좌표를 처리해야합니다. 이러한 거대한 세계는 64bit 환경에서만 구현가능합니다.
- 이러한 변화를 주기 위해 1년이라는 시간이 걸렸습니다.
- NPC 및 오브젝트와의 많은 상호작용이 이루어 질 수 있도록 Job Management System 을 다시 만들어야 했습니다. 그래서 이제는 이 시스템이 메인 쓰레드를 막지 않습니다. 수많은 게임속 엔티티들을 처리하기 위해 이제는 CPU 의 모든 코어를 최대한 활용합니다.
- 크라이엔진의 단점을 극복하여 새로운 엔진은 모든 엔티티들은 다른 구성요소를 가질 수 있게되었습니다. 함선은 비행 제어 시스템을 구성요소로 가지게 되었고 생명유지 구성요소를 추가할 수 있었습니다.
- 이것을 아이템 2.0 시스템이라고 각각의 구성요소들을 독립적으로 테스트 할 수 있습니다.
- 크리스 로버츠의 말에 따르면 이러한 확장가능성 높은 시스템이 네트워크를 통해 게임세계를 쉽게 동기화 할 수 있으며 프로그래밍에서는 매우 현대적인 원칙이라고 하였습니다.
- 아이템 2.0 시스템을 활용한 첫 번째 계획은 많지않은 플레이어를 수용할 수 있는 인스턴스를 가지고 타 MMO 게임처럼 스타시티즌을 만드는 것 이었습니다.
- 3.0 에서 수용가능한 플레이어 수는 기존과 동일합니다. 한 서버에는 최대 24명이 접속이 가능합니다.
- 게임엔진의 재 작업 또한 네트워크에 영향을 미치며, 수많은 서버 속 수천개의 인스턴스가 플레이어의 정보를 서로 동기화 할 수 있을 것입니다.
- 물리적 서버에는 32개의 코어가 있으며 8개의 가상머신이 구동되고 있습니다. 왜냐하면 크라이엔진은 4개보다 더 많은 코어를 활용할 수 없기 때문입니다.
- 그리고 다른 문제로는 코어의 개수와 수용가능한 플레이어 양과 비례하지 않기 때문입니다. 미래에 이 문제는 수정될 것입니다.
- 4개의 CPU 코어로 24명을 수용할 수 있습니다. 게임엔진이 활용할 수 있는 최대 CPU 개수가 늘어난다면 한 서버에 100명이상의 플레이어를 수용할 수 있을 것입니다. (역자 주. 현재 4코어 이상의 서버에서도 24명만 받을 수 있고, 이걸 해결하려면 게임엔진 수정이 필요하며, 이 작업이 완료되면 서버 코어 개수에 따라 최대 동접자 수를 증가시킬 수 있다는 말인 것 같습니다.)
- 서버 네트워크와 서버 간 원활한 전환이 될 때, 모든 플레이어는 실질적으로 한 인스턴스에 있는 것 같은 효과를 낼 수 있습니다. (역자 주. 모든 서버들을 서로 동기화시켜, 단일 서버와 같은 환경을 만들겠다는 내용인 것 같습니다. )
- 이를 향한 커다란 발걸음은 Batch Updateing 입니다. 이 기술을 통해 하나의 Batch 는 모든 코어로부터 함께 처리됩니다. 이로인해 서버간 동기화가 훨씬 쉬워집니다. 특히 피지컬은 이 방법이 훨씬 더 확장성이 좋습니다.
- 이 기술은 아직 약간 더 시간이 필요하기 때문에 미래에 엄청난 숫자의 NPC 를 처리하기 위해서는 더 많이 처리할 수 있도록 크라이엔진을 수정 하는 것이 중요합니다.
- 현재 계획으로는 스타시티즌 우주 속 인구 90%를 NPC 들로 채워넣는 것입니다.
- 게임에서 이러한 모든 요구(거대한 우주, 행성, 함선 역학, 피지컬 그리드)을 만족하기 쉽지 않습니다.
- 게임 시연에 사용되었던 컴퓨터의 사양은 i7 5930k, GTX 980, 32GB 램 이며 30프레임이 나왔습니다.
- 엘리베이터 시스템, Ragdoll 시스템, 서버 충돌 문제가 남아 있습니다.
- 새로운 라이젠 CPU 를 최적화 할 예정입니다.
- 게임의 최소 사양은 쿼드코어 CPU, 2GB 이상의 그래픽 카드, 8GB 램, SSD 입니다.
- 그래픽 설정은 여러분의 사양에 맞출 수 있도록 세분화 될 것입니다.
- 그래픽 설정이 많을 수록 테스트가 많이 필요하므로 20개 이상의 옵션이 제공되지 않을 것입니다. 그러나 게임 성능을 컴퓨터에 맞도록 변경하는 데 충분할 것입니다.
- 콘솔 지원을 위해 게임 그래픽을 다운그래이드하는 일은 없을 것입니다. 현재의 최고사양의 PC 는 2~3년이 지나면 중간사양으로 되기 때문에 스타시티즌을 플레이하는데 부담이 없을 것입니다.
- 스타시티즌은 크라우딩 펀드로 개발되는 게임이며 몇달마다 퍼블릭 빌드를 공개하고 커뮤니티의 피드백을 받을 것입니다.
- 많은 후원자들이 자신의 팀이 시간을 올바른 방향으로 사용하고 있음을 이해해 주어서 크리스 로버츠는 행복합니다. (역자 주. 비록 시간이 걸리지만 게임 완성을 위해 시간을 투자하고 있음을 후원자들이 지지하고 믿어주어서 크리스 로버츠가 행복하다는 의미 인듯합니다.)
- 내부 테스트는 70여명의 사람들이 진행하며, 그 후 2단계에 걸쳐 커뮤니티와 함께 테스트를 합니다. (에보카디 테스트는 1000명, PTU 는 최대 2만명)
- 모든 테스트를 거친 버전만이 모든 후원자들에게 공개됩니다.
- 크리스 로버츠가 말하기는 멀티플레이를 테스트하는 것은 큰 도전이라고 하였습니다. 에디터에서 모든 것을 혼자서 테스트하고 다른 위치에 있는 사람들과 함께 인터넷을 통해 함께 게임세계를 테스트하기 때문입니다.
- 인터넷으로 서로 동기화 되는 클라이언트를 통해 게임세계의 많은 것들을 추척할 수 있습니다.
- 큰 문제는 인터넷을 통해 물리엔진을 서로 동기화하는 것이였습니다. 왜냐하면 플레이어들은 서로 다른 중력과 중력방향을 가지고 있기 때문입니다.
- 3.0 에서 구현되어야 것들이 많이 남아 있어, 지연될 수 있습니다.
- 게임이 아직 알파단계이지만 개발팀들은 큰 야망을 품고 있습니다.
Vulkan VS DirectX
- DirectX 11를 사용하고 있습니다. DirectX 12 는 윈도우 10에서만 구동될 수 있기 때문에 Vulkan 으로 변경할 예정입니다. 어쩌면 DirectX 11를 완전히 사용 안할 수 도 있습니다.
- Vulkan 은 코어 활용도가 높기 때문에 그래픽 품질이 향상됩니다.
- 크라이엔진은 Vulkan 5.4를 이미 지원하지만, 스타시티즌이 사용하는 크라이엔진는 자체 수정한 부분이 많기 떄문에 크라이엔진을 업데이트 할 수 없습니다. CIG 는 이와같은 유사한 계획을 가지고 있지만 많은 구성요소들을 재 작업해야 합니다.
- 현재는 그래픽 API 보다 게임 개발이 시급하기 때문에 그래픽 API 변경이 늦어질 것입니다.
크고 아름다운 64bit
- 가장 큰 도전은 게임엔진을 64bit 로 동작하도록 수정하는 것이였습니다.
- 크라이엔진과 럼블야드엔진도 하지 않은 것입니다.
- 32bit 로는 거대한 태양계 시스템을 만들지 못할 것입니다.
- 몇년동안 CPU 는 64bit 를 지원하고 윈도우즈도 지원했지만 오늘날의 대부분의 게임들은 32bit 로 실행됩니다.
- 위쳐 3 의 맵은 스타시티즌 우주 속 위성의 한 분화구 안에 배치할 수 있습니다. (역자 주. 위쳐 3 보다 맵이 엄청 크다는 말 같습니다.)
절차적 생성...
- 언젠가 스타시티즌에 100개의 항성계와 300개의 위성과 행성을 우주에 포함시켜야합니다.
- 모든 행성과 위성은 플레이어가 직접 걸을 수 있어야합니다.
- 크리스 로버츠는 처음 런칭때 5 ~ 10 개 항성계를 구현하는 것으로 목표로 합니다.
- 목표를 달성하기 위해 절차적 행성 시스템을 개발했습니다.
- 이것은 개발자가 행성 베이스를 만들기 위해 사용되는 도구 입니다.
- 여러분이 방문할 행성들은 절대 절차적으로 생성되지 않습니다. (역자 주. 행성 베이스를 절차적 생성을 통해 만든 다음 개발자들이 행성의 특성에 맞게 수정하고 오브젝트를 추가합니다. )
- 절차적 행성 시스템은 새 행성에 수많은 바이옴과 레이어를 생성합니다. 숲, 돌, 호수, 바다등과 같이 여러 바이옴을 생성합니다. (우리는 이미 바다를 보았습니다.)
- 크리스 로버츠는 이것을 큰 붓으로 그림을 그리는 것이라고 말했습니다.
- 그러나 모든 행성과 달에 특정 장소를 만들기 위해 개발자들이 많은 검토를 할 것입니다.
모든 데이터가있는 곳
- 여러분이 게임 세계를 여행하려 할 때, 여러분의 PC 는 미리 데이터를 준비한 다음 화면에 띄어줍니다.
- 항성계와 실제 행성을 구현하는 것은 기술적 도전이며, 이 방대한 데이터들을 매우 효율적으로 스트리밍 해야합니다.
- 이 문제를 해결하기 위해 Object Container Streaming 라는 것을 개발했습니다.
- Object Container는 그룹화 된 오브젝트들을 표시하기 위한 데이터를 포함하며 이것은 우주 정거장이나 플레이어가 돌아다닐 수 있는 우주 정거장 속 구역이 될 수 있습니다.
- 스타시티즌은 어떤 오브젝트가 필요할지 식별하여 데이터를 적시에 불러옵니다. 이것이 가능한 이유는 계층 구조를 통해 가장 중요한 데이터를 선별하여 먼저 불러오기 때문입니다.
- 멀티 코어 시스템으로 더 나은 데이터 스트리밍을 지원합니다.
- 이러한 기술들을 보다 더 잘 활용하기 위해서는 SSD 와 많은 용량의 램을 가지고 있는 것이 좋습니다.
- 현재 행성과 달에는 4~5개의 특별 구역이 있습니다.
- 곧 Object Container Streaming 을 사용할 수 있을 것입니다.
번역 Laeng
어그로인가 했는데 본인글이셨구나ㅋㅋ
가독성이 꽝이네여 --
BitBox
어그로인가 했는데 본인글이셨구나ㅋㅋ
본인이 반성하는 댓글에 비추가 ㅠㅠ
뭐야 작성자였넼ㅋㅋㅋㅋㅋㅋㅋ 저도 어그로인줄 알았습니다ㅜㅜ 댓글은 삭제할게요ㅕ
개발사에서 가장 능력있고 대우받고 중요한 사람은 기획자라고 생각하는데 스시는 엄청난 기술력이 필요하다보니 아티스트나 프로그래머에 치중되어 예쁜똥이 되지않길 바람
이거 얼마전에 비슷한 내용을 유투브에서 본거 같은데 ㅋㅋㅋ 팀 분리수거라고 들어는 보셨나. ㅋㅋㅋㅋ
요즘 3.0 이야기 많이 나오는 것 보니까 조만간 나오겠네요 빨리 나와라 ㅠㅠ
- 3.0의 한 서버에는 최대 24명 접속 가능. - 4개의 CPU 코어로 24명을 수용할 수 있습니다. - 물리적 서버에는 32개의 코어 > 이론상 서버 최대수용인원 = 24 / 4 * 32 = 192명 - 다른 문제로 코어의 개수와 수용가능한 플레이어 양과 비례하지 않음 - 게임엔진이 활용할 수 있는 최대 CPU 개수가 늘어난다면 한 서버에 100명이상의 플레이어를 수용할 수 있을 것입니다. > 현재는 32코어에도 100명의 수용이 불가능하며, 개선할 경우 192에 다가설 것이라는 이야기 이게 퍼시스턴스 월드를 구현하는 목표의 게임인건지... 프리랜서의 재림인건지....
AWS가 자원관리하는거랑 비슷한 방식인것같긴한데.... MMO월드를 생각하는 사람들의 의사와는 크게 다른 녀석을 만들고있다는 생각이 좀 드네요.. 게임이 복잡한 만큼 데이터도 크고 연산도 많이 요구할 수 밖에 없었을꺼고 결국 이런 구조도 예견된 문제일텐데, 유저들이 기대하는건 EVE같은 대규모 우주물의 1인칭 시점이 아니였나 싶어서요. 이것도 사람마다 기대방향은 전부 다르긴 하겠네요.. ㅎㅎ
처음부터 수천명이 한 자리에 모이는 건 불가능하다고 해서 EVE같은 대규모 우주물 기대하는 사람은 없음
그럼 퍼시스턴트 월드가 아니라 인스턴트 게임을 기대하고 있던건가요? 자세히 알아본건 아니라 몰랐네요... 그 돈으로...
원래 초기부터 IMO라고 인스턴스를 이용한 게임인데 그 인스턴스가 칼로 나눈거처럼 되는것이 아니라 유기적인 변형을 가지게 될것이라 계속 말해왔고 최근에는 기술 한계를 넘는게 가능하게 된다면 원샤드 MMO도 도전한다는 늬앙스로 말했어요. 원샤드 MMO가 가능하다면 좋겠지만 현실적으로는 아직까지 이정도 데이터, 퀄리티로 원샤드 MMO가 구현된적이 없어서 힘들지 않을까싶네요.
뭔가 디비전 스타일과 유사해보이긴 한데...모르겠네요.
아니요 규모가 이브에 못미칠 뿐 대규모 멀티 플레이 게임 지향하는거 맞습니다. 초창기에 IMO(인스턴스 멀티 온라인) 이라고 했던거는 서버에 대해서 설명하느라 그랬던 거구요. 처음부터 대규모 멀티 플레이 지향했습니다. 윗분이 말씀 해주셨다시피 단일 물리 서버 한계치가 저정도라는거지 처음부터 전세계 단일서버 멀티 플레이 게임이었습니다. 애초에 서버 하나만 돌리는것도 아니고 구축함이라던지 대형함 인원 수용컷이 최소 40입니다. 항공모함 뱅갈급까지 가면 3자리수도 넘볼 수도 있구요. 저 인스턴스라는 설명은 거대한 지역을 서버당 할당해서 인스턴스라는 개념으로 나눈거지 디비전이나 와우 인던마냥 독립된 공간이 아닙니다.
https://youtu.be/9yJXlju1rFc?t=1m36s 크리스가 자기 입으로도 Massive MultiPlay 라고 발언한적도 있습니다.
어느정도 대규모일지는 아직 알 수 없습니다. 플레이어 티켓이 얼마나 할당될지는 CIG도 아직은 예측 못합니다. 주력함기준으로 대다수의 보직을 유저에게 할당하지는 않습니다. 하급선원 업무를 유저가 한다면 해군군함을 타보신 분들은 공감하실 따분함이 있습니다. 그런 부분은 결국 NPC로 채우게 될거고 사관급 이상의 역활만 유저 또는 AI힘을 빌리게 될겁니다. 문제는 IMO를 하게된 경위인데 EVE는 함선시점기반에 플레이로 프레임에 대한 민감도가 여타 FPS 게임이나 스타시티즌 보다 낮습니다. 그래서 대규모 접전이 발생하면 다같이 느리게 하는 것으로 공정성이 유지되고 프레임이 떨어지는 것으로 인한 체감적인 불편함이 많이 높아지지는 않습니다. 반면에 스타시티즌은 FPS입장에서 게임을 하기 때문에 전역적인 속도 지연이 발생해서 프레임이 떨어지거나 게임속도가 느리게 되면 바로 답답함이 옵니다. 알파 2.X 대에서 서버 최적화 문제로 프레임이 안나오니 NPC 해적과 전투에서 플레이가 힘들어지는 것과 같은 문제들이 도래합니다. 요약하면 스타시티즌에서는 프레임과 게임시간을 포기 할수 없기 때문에 결국 유저간 접속량에 따른 과부하를 인스턴스라는 공간으로 분산 처리합니다. ravvit님이 잘못 설명하신 부분이 지역적으로 인스턴스 할당한다는 말은 한적 없습니다. 인스턴스 분류에서 공간도 어느정도는 영향을 주지만 IMO 설명에서 주로 언급되는 부분은 데이터량입니다. 전세계의 모든 유저가 접속하는 환경에서 자신이 조작한 정보를 서버에보내고 다른이들이 조작한 결과를 자신이 받는데 필요한 정보량 (정확하게는 네트워크 트래픽)이 초당 몇회 이상을 확보해야 자신이 플레이하는 상황과 주변의 다른 유저들이 보는 상황과 일치화 할 수 있습니다. 단편적으로 공간 이외에도 유저수, 각 함선들이 데이터 소비량(함선당 서버 계산량과 네트워크 대여폭 )에 맞춰서 유동적으로 인스턴스 하나에 배치 가능한 유저수가 온다고 언급되어 있습니다. 다만 IMO이지만 와우 인던마냥 딱딱하게 방을 구분하는 의미로 접근이 아닌 디비전의 세이프하우스 처럼 자연스럽게 나타났다가 분리되는 형태를 취해서 만남과 헤어짐을 목표로 IMO를 구성하는 방향으로 봅니다. 결론적으로 EVE와 같은 에픽스케일의 수천대급의 대규모 함대전이 한눈에 그려지지는 못하지만 디비전의 파티플레이처럼 단절된 공간에서 개별따로 노는 것 또한 아닙니다. 모르는 이는 우연히 주변에 있으면 만날 수도 못만날 수도 있고 아는이 (동료이던 적이던)는 대부분 눈앞에 보게 됩니다.
제가 하고 싶었던 이야기는 윗분들이 이야기 하는것처럼 소수의 인원끼리만 모여서 독립된 인스턴트 던전처럼 플레이 한다는게 아니라는 말이었습니다. 인원수는 당연히 개발하면서 유동적으로 변화하니 어느정도의 규모가 될지는 알수 없겠지만 윗분들 말씀처럼 프리랜서급은 아니라고 개인적으로 예상합니다. 인스턴스를 할당한다는 이야기는 거대한 우주 공간을 플레이어의 활동에 따라 다수의 서버로 나누어 처리한다는걸 이야기 하고 싶었는데 단어를 잘못 사용한거 같습니다.
말씀하신 내용을 보면.. 대규모 함대전이 그려지지 못하나, 아는 사람은 보이는 시스템인데 디비전은 아니라고 하셨는데.. 모순이 좀 있어보이고... 결국 채널시스템인것같네요 그럼. 우주정거장 #1채널 #2채널.. 채널 바꾸면 보이는 유저 바뀌고.. 전투하고 있는 상황 다르고..
언급에 대해서 보충 설명드리면 디비전이 인스턴스의 채널을 따로 선택하는 구성이 아닙니다. 위에 디비전을 2번 언급한 부분에 일반적인 파티플레이는 파티원 4명만 모여서하는 단절된 공간입니다. 와우의 인던과 같이 같은 공간에 여러 채널이 존재하는 방식이죠. 또 한가지는 세이프하우스 같은 경우인데 이 경우는 파티원 이외에도 랜덤적으로 많은 유저들이 있습니다. 다만 디비전은 채널선택같은게 없습니다. 그냥 같은 공간에서 랜덤적으로 현재 있는 유저를 매칭해서 보여줍니다. 이 하우스 입장 또는 퇴장시 자동으로 연결 해주고 분리해줍니다. 디비전 플레이에서 채널선택을 따로 하는 경우가 없는게 바로 그런 이유입니다. 이 부분에 구체적으로 설명을 드리면 우선 인스턴스는 당연히 같은 공간에 있지만 채널개념으로 서로 다른 상황이 발생 할 수 있습니다. 때문에 해당 부분에 갈라져 있다면 서로 관여 못하는 부분에 대해서는 사실 맞습니다. 다만 이게 마구잡이로 분리하는건 아니고 일단 같은 공간상에 매우 많은 유저와 함선이 몰려 있는 경우에 분산이 되는 방식입니다. 우주라는 공간이 매우 넓기 때문에 주요 정거장이나 도시 행성 착륙장 같이 사람이 밀집화가 이루어지는 공간이 아니면 결국 자연스레 공간과 밀도가 분산됩니다. 인스턴스는 최대한 이부분에서 서로 영향을 주는 관계 우선으로 묶어주고 이영향이 미치지 않거나 더 높은 영향이 가진 유저나 그룹, 인스턴스가 있다면 해당 유저를 다른 인스턴스로 별도의 로딩이나 채널선택같은것이 없이 연결이 됩니다. 즉 채널의 선택권은 유저가 가지거나 조작하는게 아니라 인스턴스를 관리하는 서버측에서 연관성이 높은 순으로 묶어 줍니다. 그리고 그것이 공간적으로 멀리 떨어지거나 관여할 필요성이 없다면 이부분에서 다시 다른 인스턴스로 이동시켜주거나 새롭게 생성하는 방식으로 융통성 있는 관리를 합니다. 그래서 인스턴스이지만 "하나의 통합된 우주처럼" 자연스럽게 연결하는 방향을 제시한 것입니다. 그리고 인스턴스가 가진 장점은 대규모 우주정거장 같은 지역에서 착륙 요청을 하게 될 때 단일 공간 시스템이면 앞에 100명의 유저가 착륙을 위한 대기중이면 100명이 모두 처리된 이후 자신에게 착륙할 기회가 옵니다. 허나 밀도 높은 지역에 많은 인스턴스 채널이 있으면 앞에 대기 유저들이 공간상 분리되어 분산되기 때문에 100명이 아닌 수명내로 바로 착륙을 거칠 수 있게 됩니다. 스타시티즌에서 후원자들이 다양한 요구중에 리얼리티 관련한 사항에 대해서 매번 언급하지만 장르가 우주시뮬에이션이지만 이는 게임이라는 목적내에서 리얼리티이지 실제 리얼리티를 구현할 방향은 아닙니다. 그래서 항성계 크기를 1/10로 줄이고 행성의 크기를 1/4로 줄이고 대기권 높이를 매우 낮추는 과정이 리얼 스케일 그대로 진행하기에는 행성 착륙과정 자체만 2~3시간이 걸리기 때문이죠. 어쩌든 이들은 자기들이 만드는 게임에대해서 기술적으로 많은 도전도 있지만 현실성 없는것까지 도전하는건 아닙니다. IMO선택은 그런 부분이지만 그 장점과 단점을 알고있기 때문에 크리스 로버츠가 후원자들의 질문에 대한 답변과 개발보고서 같은 곳에서 언급해줍니다.
자세한 설명 감사합니다! 프로젝트 이해에 많은 도움이 되었습니다.