Nyannyacha d5524fc4eb3a4bdc95d86cfab6afb308
질문하기 앞서서, 몇일 전에 이 질문을 한번 HK 에서도 올렸던 적이 있었다냥.
묻는 의도야 여러가지가 있겠지만냥, 내가 만들고 있는 개인 프로젝트와도 연관이 있는 것이기도 하다냥.
토론 비슷한 질문이여서 내용이 길다냥
참고냥.
그 커뮤니티에서 올렸던 질문은 이 언어를 쓰는 가장 큰 이유가 무엇이냐 라는 것이였다냥.
이 질문은 프로그래밍 이라는 개념을 어느정도 알아서 산업용 언어(Java, Kotlin, C++, Javascript 등) 를 잘 쓰고 있는 애들을 대상으로 하는 것은 아니다냥.
마크를 하던 도중에 소소하게 마크의 컨텐츠를 바꿔보기로 마음먹어서 프로그래밍이라는 주제를 접하는 스펙트럼에 있는 애들을
대상으로 한다냥.
보통 마크의 무언가를 바꿔보겠다라고 하면 너네들도 알겠지만, 서버쪽을 고치는 소위 플러그인(Plugin; Spigot, Paper) 내지 Skript나, 클라이언트를 고치는 모드(Mod; Forge, Fabric) 라는 것을 알게되지냥. 물론 통틀어서 모드라고 부르는게 맞지만 유독 마크 모드 생태계 내에서는 이 용어들이 고착화 되서 그냥 이렇게 계속 언급냥.
우선, 마크를 손대는 것 중에 가장 쉬운 카테고리에 속하는건 아무래도 서버쪽이겠지냥.
이 서버쪽을 손대기 위한 언어는 대략적으로 이 질문에서 언급하는 Skript 랑 Java, 요즘 많이 언급되는 Kotlin 정도다냥.
사실 Skript 는 마인크래프트 플러그인을 대체할 목적으로 만들어진 언어라서 범용 언어인 Java 와 Kotlin 과는
많은 비교가 힘들기는 하다냥.
그럼에도 질문하는 목적은,
1. 내가 생각하는 Skript 의 여러 단점에도 불구하고 이것을 보완하거나 대체할 대체재가 빈약하거나 전무해서
계속 사용하는 것인지,
여기서 프로그래밍을 어느정도 잘 안다는 애들은 "대체재가 없다는게 무슨 말이냥, 자바나 코틀린 같은 Skript 같은 훌륭한 대체재가 있는데 헛소리 하지 말아라냥"할 수도 있다냥.
근데 내가 생각하기에는 그저 마인크래프트의 컨텐츠 자그마한 부분을 수정한다는 목적이였을텐데 그것을 대가로 많은 것을 배워야 한다는 비용의 문제가 크다고 생각하다냥.
여기에는 기회비용의 문제도 있고 인지비용의 문제도 있다냥.
2. 밑에 기술할 Java 나 Kotlin 으로 넘어가기 위한 허들이 생각보다 넘어가기 벅차서 계속 사용하는 것인지
를 알고 싶어서다냥.
우선 범용 언어야 다 마찬가지지만냥, 자바나 코틀린같은 언어로 무언갈 만든다는 것은 거의 무조건적으로 개발 환경을 세팅해야 한다는 전제가 따른다냥.
이건 매우 서버 세팅보다도 귀찮을 수도 있고 번거로운 과정일 수도 있지냥.
게다가 잘못하면 의도한 대로 세팅이 안되서 다시 밀어야 하는 수고를 들여야 하지냥. 계속 말하지만 이건 프로그래밍을 알고 도구를 다룰줄 아는 애들을 범주로 두고 하는 질문이 아니다냥.
개발환경이 어찌저찌 해서 잘 세팅되었다고 치자고냥, 그러면 바로 마인크래프트 컨텐츠를 뚝딱 수정할 수 있을까냥?
여기서 가로막는건 자바나 코틀린같은 언어를 배우는 스트레스는 둘째 치고 마인크래프트 컨텐츠를 수정하기 위한 별도의 과정의
존재다냥.
Spigot-API 라던가 Paper-API 를 공식 사이트로부터 받아서 프로젝트랑 연결시켜야 하는데 이것 부터 곤혹이다냥.
왜냐면 그 연결을 하는 방식이 되게 애매할거거든냥.
누군가는 프로젝트 폴더에다가 집어넣고 추가버튼(InteliJ 라이브러리 추가) 누르라고 할거고, 누군가는 메이븐이나 그래들의 pom.xml 이나 그루비 스크립트나 kotlin dsl 로 의존성을 추가하라고 하겠지냥.
여기서 하다가 못 넘어가면 커뮤니티에 질문으로 남기고, 복사 붙여넣기 하는 애들 여럿 봤다냥. 그렇게 하고서도 이 과정을 못 넘어가는 애들이 몇몇 보이는데 그런 애들은 얼마 안가 커뮤니티에서 자취를 감춘다냥.
자바나 코틀린을 배우기에도 벅찬데 곁가지로 딸려있는 이런 그래들이나 메이븐의 문제로 스트레스 받아서 쉽게 포기해버리는거지냥.
이런 내 생각의 핀트가 맞길 바란다냥.
--
다음은 Skript 의 문제에 대해서인데냥.
근데 난 Skript 는 별로 좋아하지는 않지만 안티는 아니다냥, 개발자는 항상 존중받아야 한다냥 '3'b
이걸 전제로,
내가 알고 있는 이것의 문제는 몇가지로 귀결된다냥.
- 구문의 일관성 부재(가독성이 떨어짐, 일관성이 떨어져서 구문의 예상되는 효과를 예측하기 힘듬), 어떤 것은 생략 가능해도 작동 가능하거나, 생략되면 다른 구문등으로 작동되는 일관적이지 않은 방식
- 소위 이 언어에 더 많은 기능을 추가해주는 애드온이라는 개념이 유발하는 문제
- 구문이 더욱더 일관적이지 않게 유도함 (파편화)
- 다른 애드온과 잘(자주) 충돌함
- 이러한 것을 관리하거나 완화할 수 있는 중앙화된 관리 체계의 부재
- 편집 도구의 빈약함 혹은 부재
- 물론 어느 위치에 오류가 났는지 하이라이팅 해주는 도구 스크립트가 있는건 안다냥.
근데 그건 정확한 의미에서의 도구는 아니지냥. - VSCode 에 몇몇의 Skript 를 위한 구문 강조, 구문 분석을 위한 확장이 존재하기는 한다냥.
하지만 거의 대부분의 확장이 동력을 잃어서 방치된 상태로 있다냥.
- 물론 어느 위치에 오류가 났는지 하이라이팅 해주는 도구 스크립트가 있는건 안다냥.
- 언어 그 자체로서 가지고 있는 문제 (고립된 언어)
- 결국 한가지 목적(마인크래프트 플러그인 대체)을 위한 언어
- 외부로부터 신규 언어 유저 층을 유입받기 힘들다(이것은 Skript 가 마인크래프트 단 하나만을 위한 언어이기 때문에 다양한 개발자(때로는 실력이 있는)로부터의 관심을 받기 힘들다는 뜻이다냥)
- 유입되지 않는 커뮤니티는 고립되고 퇴색된다냥. (몇가지 징후를 보이는 것이, 아직도 기존 유저층들이 Skript 통해 이용하는 것들은 대부분 커뮤니티가 아직 활발했던 시절에 만들어졌던 몇년전 애드온이나 리소스의 변형들이다냥. 즉 새로운 것이 추가되려고 할 기미가 보이지 않는다냥.)
하지만 이런 문제점이 Skript 를 사용하는 유저 생각하기에는 위에 지적한 2번의 허들 만큼은 크지 않다고 생각할 수 있다냥.
어찌 되었든 그저 내가 원하는건 소소한 수정이였을테니깐냥.
자바나 코틀린을 사용한다는 선택지 보다는 훨씬 빠른 시간 안에 설치도 빠르고 편집하고 바로 적용하면 바로 내가 원하는 대로 작동해주는지
확인할 수 있지 않냥 비주얼적으로냥.
플러그인이야 핫로딩도 가능하긴 하지만 꼬이면 재시작해야 해서 일단은 서버를 계속 재시작해야한다는 수고가 추가로 들고냥.
이쯤되면 Skript 보다는 플러그인식 개발이 더 나빠보여서 오히려 내가 Skript 신봉자로 보이겠네냥.
계속 말하지만 난 Skript 안좋아한다냥. '3'
그럼에도 이런 내 생각이 너네들의 생각하는것과 맞길 바란다냥.
HK 에 비슷한 질문을 올렸을땐 지문을 몇개 더 추가해서 올렸었다냥 근데 내가 생각했던 것과는 다른게 의외의 결과가 나와서
추리게 된거였는데 참고 사항으로 올렸던 지문도 올려줄께냥.
(복수 선택 가능)
1. 스크립트라는 언어가 마크에 쓰기에 다른 프로그래밍 (Java 같은거) 보다 직관적이라고 생각해서 (5명 투표)
2. 마크에 적용할 수 있는 관련 한글 자료가 많아서 (1명 투표)
3. 작성하고 나서 바로 테스트 (핫로딩, 재로딩) 할 수 있다는게 좋다고 생각해서 (1명 투표)
4. 다른 언어를 배워볼 엄두가 안나서(스크립트 보다 어려워 보인다던가 하는 이유로) (5명 투표)
위에 올렸던 두가지의 질문은 사전에 HK 에 올렸던 질문을 토대로 다시 가다듬어서 질문한 것에 불과하기 때문에
결은 같다냥.
때에 맞지 않게 심오해 보이는 토론 같은 질문이라 댓글이 별로 안달릴거라 예상하는데 가능하면 댓글로 많은 의견 부탁냥
자신이 1번 의견인지, 2번 의견인지 아니면 그것도 아닌 다른 의견인지냥 근데 이러면 그냥 내 생각이 망상에 불과했다는 거겠지만냥.
의식의 흐름대로 작성한 거라서 읽다가 뭔가가 거슬릴수도 있다냥, 근데 거슬려도 별 수 없다냥
수정하기에는 너무 글을 써버려서 교정하기가 싫다냥. 이해해주면 좋겠다냥.
호우로 피해입은 애들 힘내라냥
수고냥
작은거인
2022.08.10전 사람들이 이걸 전부 다 읽을지가 고민이다....냥(?) ㅋㅋㅋ...ㅠㅠ
냥냐챠
2022.08.10안읽으면 어쩔수 없는거고냥 '3'
정현우니
2022.08.10저는 이미 플러그인 개발을 하고있어서 1번 케이스가 될 듯 하네요.
간단한 수준의 구현(예: 서버에 접속했을 때 특정 메시지 출력)이나 1회성으로 사용되는 시스템(방송 컨텐츠에서 사용되는 시스템 등)에서는 Skript를 간간히 쓰는 편이긴합니다.
쓰는 이유는.. 가장 큰 이유로는 귀찮아서 혹은 시간이 없어서 정도...?
그 외의 플러그인으로 하는 경우는 정리하면 이 정도일 듯 합니다.
냥냐챠
2022.08.10하이브리드고만냥
우니냥은 경험도 있고 하니깐 Skript 를 쓸 기준을 명확히 나눌 수 있나보네냥.
아예 산업용 언어를 접하지 않는 애들은 어떤 생각을 가지고 있을지 궁금해지는고만냥
의견 감사냥
'^'b
코코냐
2022.08.10생각해보면 모드계에도 ZenScript라는 고립된 언어가 있긴 한데, 이쪽은 kube.js로 넘어가는 추세라 스크립트도 차라리 누가 JS 기반 스크립팅 같은거 만들면 몰려가지 않을까 싶긴 하네요
냥냐챠
2022.08.10그 모드 한번 훑어봤다냥 kube.js 라는 모드냥. 모질라 재단의 자바스크립트 엔진이 내장된 모드더만냥.
약간 변환 수준이 많이 내려가지는 않는 엔진이기는 한데냥 자바스크립트를 바이트코드 수준으로 끌어내려서 큰 성능 손실 없이
자바스크립트를 자바에서 돌릴 수 있는 좋긴 하지만 모질라에서 손 뗀듯한 엔진이다냥.
의견 감사냥
'^'b
감파르다
2022.08.10전 2번이네요
스크립트가 문제가 많다는건 알고있지만 Java 공부가 많이 어려워서..
냥냐챠
2022.08.11스크립트는 역할에 충실할 뿐이다냥.
자바 공부가 어려운 것인지, 자바를 이용해서 마인크래프트 모딩이 어렵다는 것인지는 댓글이 명확하지 않아서
모르겠지만냥, 모딩은 다른 게임도 그러하듯 원래 만들어진 게임을 변형시키는 것이기 때문에 어려울 수 밖에 없다냥.
개발자가 정말 개발하기 편하라고 처음부터 틀을 잡고 개발하지 않는 이상냥.
국어로 번역된 마크 모딩 관련 자료가 적어서 아마 관련 커뮤니티 성장도 정체되있고, 배우려는 사람도 적다냥.
그런 환경에서 모딩을 배운다는 것은 어려운게 맞지냥. 그쪽이 어렵다고 느끼는게 이상한건 아니다냥.
힘내라냥
'^'-o
Vive
2022.08.10Typescipt, C# 을 사용해본 개발자입니다. (최근 마크 서버를 하나 만들어보려고 이리저리 공부해보고 있어요)
저도 아래 내용으로 Skript 의 단점을 느끼고 Java 플러그인으로 재개발/변경해보려 합니다.
Skript는 Java 프로젝트 설정 및 개발 보다 더 적은 공수, 더 간단한 로직일 경우 적용되면 좋을 것으로 생각합니다!
냥냐챠
2022.08.10내가 플러그인이란 것의 존재를 모르고 Skript 를 접했을 예전 그때의 느낌과 닮아있고만냥.
근데 백트레이스는 있지않냥?
스크립트는 그런 정도의 "복잡성 예산" 을 감당할 정도로 정교하게 설계된 언어랑은 틀리지냥.
사실 범용 언어와는 비교하긴 힘들다냥.
댓글 감사냥 '^'b
Vive
2022.08.11음 조금 더 보강을 하자면, Java로 짠다면 내가 예상치 못한 Input을 받았다면 Exception을 내고 StackTrace를 찍어보거나 그런 처리가 가능하겠지만은..
복잡한 스크같은 경우 인풋이 어디서 꼬였는지 찍으려면 호출부쪽에 로그들을 다 찍어봐야하지 않을까 싶었어요.
물론 정교하게 설계된 언어를 따라갈 수 없다는 것도 알지만 복잡한 것을 구현하시는 목표라면 조금 더 정교한 타이핑이 가능한 언어로 가야하지 않을까 했던거였어요! :)
냥냐챠
2022.08.11몬가 어조가 내가 만든다는 개인 프로젝트에 조언을 주는 듯한 인상이고만냥 그런거라면 참고할께냥
근데 말이지냥 난 따로 스크립트 같은 언어를 만들 생각은 추호도 없거든냥 '3'
좋은 언어들 두고서 왜 다른 언어 만들까냥
Vive
2022.08.11ㅋㅋㅋ 맞아요.. 복잡한거 구현해볼라 했다가 손 때서... 말리는것이였.. 다행 bbb
qsef1256
2022.08.11제가 Skript 시작한건 2번 이유가 컸네요
그때는 본격적으로 달라붙어보자! 가 아니였으니까요
베개냥이
2022.08.11난 완전 예외 케이스인데, 서버의 모든 부분을 커맨드 기반의 데이터팩으로 작동시켜요.
커맨드가 굉장히 어렵고, 자바나 스크립트를 어느 정도 할 수 있어도 이렇게 하는 이유는 여러 가지가 있는데
일반적으로 내가 제작하는 서버가 상황에 따라 여러 패키지를 유동적으로 토글해야 한다는 있는 이유도 있겠지만 의외로 커맨드는 강력해서 스크립트에 어느 정도 비비면서도 스크립트의 장점은 대부분 상속받아 있다는 점, nbt를 직접적으로 다루기 때문에 복잡한 몇몇 일을 가볍게 처리할 수 있다는 점, 그리고 작성자의 역량에 가독성이 정비례한다는 점이 있겠네요.
커맨드는 특정 구현을 어떻게 만들어야 하는지 직접적으로 가르쳐 주기 않기 때문에 그 부분을 배우는 과정이 정말 오래 걸리고 협업 난이도가 개박살나지만, 인게임 인터프리터(?)를 지원하고 대부분의 상황에서 의도한대로 작동하고 최적화의 여지도 크기 때문에 난 스크립트를 굳이 사용하지 않아요.
냥냐챠
2022.08.11의지가 강한냥이고만냥
그럼 됐다냥
의견 감사냥
'^'b
글로
2022.08.11개인적으로는 3번 의견이 큽니다
최근 모드서버의 컨텐츠를 주로 제작하다보니 서버를 재로드 시킴에 있어 건축하시는분들에게 피해가 가는 편이 어느정도 있어서
간단하고 바로 적용하거나 수정이 필요한 부분이 있을 경우 3번의 케이스를 자주 사용하게됩니다.
꿈틀
2022.08.12최근에 자바로 갈아타긴 했지만... Skript를 사용했던 이유는 1,3,4번이었던 것 같네요.
대부분의 분들이 Skript는 애드온을 달고 산다고 하시는데, 어떻게 보면 맞는 말이긴 합니다만 사실상 자바를 어느정도 할줄 안다면 skript-reflect/skript-mirror 애드온 하나로 거의 모든 애드온들을 대체할 수 있어서 저는 틀린 말이라 생각합니다.(사실 skript-reflect를 사용하기 시작하면 그건 사실상 Skript가 아닌 자바로 도배가 되긴 하지만요...)
제가 Skript -> Java로 갈아타게 된 과정을 생각해보면
Skript를 접함 -> 애드온 떡칠 -> skript-reflect 접함 -> skript-reflect로 애드온 대체 -> 뭐야 자바랑 다를게 없잖아? -> 자바로 갈아탐
사실 최적화를 필요로 하지만 않는다면 뭘 쓰던지간에 편한게 가장 낫다고 생각합니다
냥냐챠
2022.08.12skript-mirror 애드온을 좋아하는 애들에게서 찾아볼 수 있는 공통점은 거의 대부분 범용 언어를 알고있는 애들이라는거지냥.
난 마인크래프트를 잘 몰랐을때 Skript 외에 범용 언어로 모딩을 할 수 있는 방법이 존재한다는 것을 skript-mirror 로 알게됐었다냥.
하지만, 하나 바로잡자면, 그쪽도 이미 댓글에 써놓았듯이, Skript 가 무의미할 수 있다라는 경험의 전제는 범용 언어를 아는지에 대한 여부다냥.
이런 주관을 Skript 를 사용하는 모든 애들로 확장시킬 수 없다고 생각한다냥.
모두 다 범용 언어를 아는 것이 아니니깐냥.
의견 감사하다냥
'^'b
Jumsimbab
2022.08.15제 의견이 작성자분이 의도하는것에 많이 어긋나있는듯 하지만 제가 스크립트를 하고있는 명확한 이유로서는 1,2,3,4번에 전부 해당이 안되는듯하여 댓글을 작성해봅니다.
제가 스크립트를 하는 이유는 스크립트의 장단점 또는 산업용 언어의 장단점에 대한걸 막론하고 그냥 '주변에 스크립트를 이용하는 사람이 많아서'입니다.
제가 팀으로서 여러명이서 무언가를 만들다보면 스크립트 개발자분이 꼭 계셨습니다.
그러다보니 '나도 스크립트를 해볼까?' 라는식으로 시작을 하게 되었고 그렇게 시작해보게 되었고, 시작한 이후에도 여전히 스크립트를 하는분이 주변에 꽤 많았기에 그냥 스크립트를 계속하게 되었습니다.
그리고는 그냥 스크립트가 손에 익어서 지금은 혼자서 서버팩을 제작하여 배포하고 있음에도 스크립트를 쓰고 있습니다.
이걸 의견으로서 받아들이기에 애매하거나 그럴 의향이 없으시다면 저는 1,2,3,4 번 의견에 조금씩 전부 동의하는 입장인지라 복수투표가 허용된다는 조건하에 모든 의견에 1표씩 던지는걸로 하겠습니다.
냥냐챠
2022.08.16괜찮다냥, 이건 X 언어가 좋냐 Y 언어가 좋냐를 물어보는 의도가 아니였기 때문에 충분히 이런 의견도 나올거란 예측도 했다냥.
게다가 그쪽은 내 의도랑 많이 어긋나있다고 생각하는 듯 하지만 그쪽의 글에는 이미 어느 스펙트럼에 속하는지 충분히 가늠할 수 있어서
도움이 된다냥.
이런 비슷한 입장 내지 생각(주로 Skript 를 판매, 혹은 그것의 효율성의 관점에서 바라보는)을 가지고 있던 애도 마침 알고 있었거든냥.
비슷한 관점의 애도 볼 수 있어서 도움이 되었다냥.
의견 감사냥
'^'b
IRONBLOCK
2023.08.23저는 간단한 거는 스크립트로 하려고 하지만, 자바같은 언어는 배워두면 좋을것같아서 간단한 거라도 자바로 해보려고 하고있어요
테빌
2024.01.21스크립트 = 플러그인 렉 x 46
스크립트 언어: 절차지향 언어
솔직히 스크립트는 c언어보다 언어 구조가 이상하고 속도는 스크래치급.
특히 변수 구조는 끔찍함.
솔직히 말하자면 하이픽셀도 스크립트 안쓰잖음. 다 이유가 있음.
서버 관리 잘하는 사람은 스크립트 안씀.
스크립트가 안좋은 이유가
일단 스크립트라는게 뒤지게 느려요
이게 제가 경험해봤는데
램응 2기가로 설정해놨는데
스크립트가 한 1000줄정도 되거든요?
2명만 들어와도 서버가 제대로 작동을 못할정도.
스크립트 장점은 딱 하나.
쓰기 쉬움
솔직히 저도 모르는 패킷 관련해서
할수있는 애드온이 있잖음?
그래서 스크립트는 배우고 최대한 빨리 빠져나오는게..
IRONBLOCK
2024.06.011000줄에 2GB면 당연한거 아닐까요..
fhgthrtd
21 일 전현재 서버 운영중입니다.
저희의 경우 Skript와 Skript-reflect + 자체 플러그인으로 동작합니다.
자주 수정해야 하거나 실시간으로 업데이트 해야하는 시스템은 스크립트,
추가해놓고 길게 사용할 수 있거나 스크립트로 제작시 렉이 심할 것으로 예상되는 시스템은 플러그인으로 제작하며,
필요에 따라 스크립트 애드온을 제작하여 사용하기도 합니다.
물론 스크립트가 느린건 사실입니다.
다만, 1000줄정도 되는 스크립트 하나를 적용했다고 해서 플레이어 2명을 못버틴다는건 이해가 잘 되지 않네요.
스크립트 코드를 잘못 작성하셨거나 서버 사양이 심각하게 낮지 않은이상 그렇게 되긴 어렵다고 생각됩니다.
현재는 7950X서버를 사용중이지만, 현재 제가 설명드리는 환경은 i5 12600 환경 기준입니다.
저희 서버의 경우 반야생 서버이며 수십기가의 메모리를 할당하여 운용합니다.
또, 스크립트의 개수가 거진 100개 가까이 되므로 절대 적은 양이 아닙니다.
하지만 12600환경에서 동접 140명에 TPS20을 달성했습니다.
스파크상 스크립트의 서버 부하량은 7%내외이더군요.
스크립트는 사용처나 개발자의 최적화를 많이 타는 언어라고 생각합니다.
그럼에도 불구하고 2기가 메모리가 할당된 서버에 1000줄짜리 스크립트를 넣었는데 제대로 작동을 못했다고 설명하시면 제 입장에서는 납득하기가 힘드네요..
스크립트가 느린건 맞지만, 이런식의 단면적인 해석으로 스크립트는 무조건 렉걸린다는 해석의 글이 있다는 사실에 그저 안타까울 따름입니다.