맛난호빵

챗봇 명령어 매개변수 파싱 코드

맛난호빵 — Sat, 26 Aug 2023 14:49:05 +0900

토이 프로젝트로 회사 슬랙에서 사용할 챗봇을 만들다가 따옴표와 쌍따옴표로 구분되는 매개변수 파싱이 필요해서 파서를 만들었다. (띄어쓰기가 들어간 문자열을 받아야했다.)

정규 표현식을 사용해도 됬지만... 괜히 잡스럽게 내부 코드가 덕지덕지 붙어 돌아갈 것 같아서 IndexOf와 Substring을 활용해서 경량 파서를 직접 구현했다.

따옴표가 없을 땐 그냥 특정 문자를 대상으로 Split 함수를 사용하거나 IndexOf와 Substring을 활용하더라도 간단하게 구현되는 것과 다르게 따옴표라는 추가 제약 조건 하나가 등장함으로써 여러가지 예외를 처리해주어야 했다.

아래는 직접 구현한 파서 코드다.

추가적으로.. 패턴 매칭 구문을 사람들이 많이 경험해봤으면 좋겠다. 코드가 확실히 엄청나게 짧아지고 읽기도 편하다.

tar의 유래와 자주 쓰이는 옵션

맛난호빵 — Tue, 6 Jun 2023 14:44:30 +0900

tar [<옵션>...] [<파일>]...

tar 파일은 유닉스와 리눅스의 오래된 아카이브 포맷으로 유닉스 시스템 간 파일을 주고받을 때는 tar 파일로 주고받는 것이 일반적이다.

윈도우에서 흔하게 쓰이는 zip 포맷을 쓰기도 하지만 잘 쓰지 않는 이유는 일반적으로 zip 포맷이 처음 설계될 때 파일 시스템에 권한 등의 세부적인 메타데이터가 포함되는 유닉스 계열 시스템과 달리, DOS에서 시작된 포맷이기 때문에 비교적 세부 정보가 덜 기록된다. (압축 프로그램마다 다르지만 추가적으로 파일시스템의 메타데이터를 기록하는 경우도 있긴 하다.)

tar 파일은 애초에 권한이 포함된 유닉스 파일을 테이프에 담을 수 있도록 만든 포맷이기 때문에 파일 시스템의 권한 정보까지 보존되도록 설계되었다(Tape Archiver). 따라서 유닉스를 비롯해서 리눅스 진영에서는 tar를 이용해서 파일을 주고받거나 백업을 하는 등의 용도로 사용되고 있다.

옵션

주의: 이 표에서는 tar의 모든 옵션을 나열하지 않는다. 이 글은 파일을 묶고 압축하고 다시 푸는 것만 집중해서 요약한 글이다.

단축형 옵션	전체 옵션	설명
-c	--create	새 아카이브 만들기
-r	--append	아카이브에 파일 추가 (아카이브 끝에 추가)
-A	--catenate --concatenate	tar 파일 병합
-v	--verbose	처리된 파일 목록 보기
-f	--file=<아카이브 파일 이름>	입출력 대상 아카이브 파일 혹은 장치 (참고로 리눅스는 모든게 파일로 표현됨)
-p	--preserve-permissions --same-permissions	퍼미션 보존
-z	--gzip --gunzip --ungzip	gzip 기반으로 tar 압축 (tar.gz)
-J	--xz	xz 기반으로 tar 압축 (tar.xz)
-I	--use-compress-program=<프로그램>	압축 프로그램 지정, 멀티스레딩을 사용하려면 이를 이용해서 옵션을 주거나 다른 프로그램을 사용하는 것이 권장됨

압축

tar는 파일을 묶을 뿐, 자체적으로 압축을 하지 않기 때문에 다른 압축 소프트웨어의 힘을 빌어 압축하도록 되어 있다. tar와 같이 가장 많이 쓰이는 압축 포맷으로는 zip처럼 평균적인 압축 성능을 보여주는 DEFLATE 알고리즘을 사용하는 gzip, 7z처럼 강력한 압축 성능을 보여주는 LZMA2 알고리즘을 사용하는 xz 등이 있다. (bzip2 등도 있지만 사실 쓰이는 건 못 봤다.)

압축 옵션을 주고 tar를 실행해 보면 싱글 스레드만을 이용해서 압축이 진행된다는 것을 확인할 수 있다. gzip의 경우, 멀티코어 옵션이 전무하고, xz의 경우 최근의 경우 멀티코어 옵션을 제공하지만 tar의 단축 옵션으로 지정이 불가능하기 때문에 명시적으로 압축 프로그램을 지정해 주는 옵션을 사용해야 비로소 멀티코어를 온전히 활용하도록 옵션을 줄 수 있다.

gzip의 경우 'pigz'라는 추가적인 소프트웨어를 설치해서 병렬 압축을 진행할 수 있고, xz의 경우 '-T0'라고 옵션을 주어 병렬 압축을 진행할 수 있다.

tar -I pigz ...
tar -I 'xz -T0' ...

참고로 xz 압축은 정말 압축 효율이 좋지만 (평균적으로 gzip의 1/2 크기로 압축됨) 그만큼 오래 걸리는 편(거의 두 배)이기 때문에 개인적으로 gzip 기반으로 압축하는 것을 선호하는 편이다... 상황과 기호에 따라 선택해서 쓰자.

백업 용도로 한정 지어 말하자면... 다른 시스템으로 옮기는 등의 잠깐 백업을 하는 경우 gzip을 사용하고, 장기적으로 보관해야 하는 경우에는 xz 압축을 사용하는 것이 좋겠다...

자주 쓰일 옵션 조합

#gzip 압축
tar -I pigz -cvf <아카이브> <대상 폴더>

#gzip 해제
tar -I pigz -xvf <아카이브>

#xz 압축
tar -I 'xz -T0' -cvf <아카이브> <대상폴더>

#xz 해제
tar -I 'xz -T0' -xvf <아카이브>

참고로 리눅스에서 <아카이브>에 파일 경로 대신 - 를 입력하면 stdin 스트림에 출력하며 이를 다시 파일이나 네트워크로 송수신하는데 이용할 수 있음을 참고하자.

백업을 위한 원격 tar 압축

ssh와 결합해서 원격의 파일을 tar로 묶어서 로컬로 가져오는 테크닉이 있다.

ssh [<옵션>...] <접속 정보> 'tar -I pigz -cvf - <대상 경로>' > <아카이브 파일>

이렇게 하면 원격의 파일이 tar로 묶이며 stdin에 파일 내용이 출력되게 된다. '>'기호를 사용해서 stdin 스트림을 아카이브 파일에 리디렉션 해주면 ssh를 통해 넘어온 stdin이 아카이브 파일에 저장된다.

반대로 로컬의 tar 파일을 원격에 넘겨서 푸는 상황을 상정해보자면...

cat <아카이브 파일> | ssh [<옵션>...] <접속 정보> 'tar -I pigz -xvf - <대상 경로>'

이 경우 로컬에서 cat으로 읽혀진 파일이 stdout에 출력되며 파이프를 뜻하는 '|'기호를 통해 ssh에 stdin으로 전달된다. 전달된 stdin을 원격에서 해제하면 덧씌워지게 된다.

다만 이런식으로 진행할때 sudo를 사용하기 어렵다는 문제점이 있다... 이 문제는 아에 ssh로 접속 후 역으로 PC로 보내는 방식을 쓰거나 파일로 저장한 후 scp 명령을 통해 가져오는 방식을 쓰는게 보안상 이로울 것 같다. 비밀번호를 sudo에 stdin으로 보내는 방법이 있겠지만... 비밀번호가 bash 히스토리에 기록되서 유출될 수도 있기 때문에 굳이 한다면 sh 스크립트를 작성하는 것에 응용하는 방향으로 쓰는게 좋을 듯 하다...

Unity3D에서의 부드러운 씬 스트리밍

맛난호빵 — Thu, 25 Nov 2021 11:23:09 +0900

출처: Smooth Scene Streaming with Unity3D (80.lv)

저자: Dimitar Popov, 게임 개발자

Smooth Scene Streaming with Unity3D

The Co-Founder of The Sixth Hammer Dimitar Popov has returned to tell us about designing a big seamless 2D world without loading screens in Unity.

80.lv

개요

저는 불가리아의 소규모 독립 게임 스튜디오인 Sixth Hammer의 Dimitar입니다. 현재 Unity3D 엔진을 사용한 2D 게임 개발에 주력하고 있습니다. 저희의 가장 큰 게임인 Moo Lander는 일반적으로 더 복잡한 게임에서 발생하는 많은 어려운 문제에 대한 창의적인 솔루션을 찾아야 했습니다. 저희는 Moo Lander가 로딩 화면을 포함하지 않고 대신 하나의 거대한 열린 2D 세계가 되기를 원했습니다. 그래서 저희는 게임 플레이 중에 콘텐츠를 성능 좋게 스트리밍 하는 문제에 대한 해결책을 찾아야 했습니다.

Unity에는 씬(Scene)이라는 개념이 있으니 게이머가 게임을 플레이하는 동안 백그라운드에서 해당 씬을 로드하는 방법을 찾아야 했습니다. 충분히 간단해 보이죠? 아닙니다!

씬을 언제 언로드 하는지? 예를 들어 멀리 떨어진 배경 물체가 보이지 않고 씬에서 더 이상 필요하지 않다면?
여러 플레이어가 게임 세계의 다른 위치에 있을 수 있는 경우 로드해야 하는 씬을 추적하는 방법은?
성능 스파이크 없이 백그라운드에서 씬을 로드 및 언로드 하는 방법은?

이것들은 이 글에서 제가 답하고자 하는 몇 가지 질문입니다. 자, 이 주제에 자세히 알아봅시다.

Unity가 제공하는 현재 즉시 사용 가능한 기능

Unity의 씬을 게임 개체의 "묶음"으로 생각할 수 있습니다. Unity는 씬 로드의 두 가지 유형인 가산형[Additively]과 비가산형[Non-Additively]을 제공합니다. 비가산적 로딩은 현재 씬을 로드될 씬으로 대체하는 반면에, 가산적 로딩은 이미 로드된 씬을 유지합니다. 이 경우에는 가산적 로딩이 필요했죠.

또한 Unity는 두 가지 유형의 로딩 방법을 제공하는데 각각 동기[Synchronously] (기본적으로 로드가 완료될 때 까지 다른 모든 것을 일시 중지함.)와 비동기[Asynchronously] (백그라운드에서)가 있습니다. 우리 게임의 경우 가산적 비동기 로딩(Additive Asynchronous loading)을 사용했습니다.

저희의 솔루션

저희는 개발 중에 발생한 앞서 언급한 문제를 해결하기 위해 장면 로딩을 위한 게임 오브젝트 및 헬퍼 클래스 전체 시스템을 구축해야 했습니다.

씬 전환기

저희는 적절한 순간에 장면을 로드 및 언로드 하기 위한 최적의 솔루션이 무엇인지 오랫동안 고민했습니다(액션이 최소화될 때, 장면 자체가 보이지 않을 때, 장면이 다른 곳에서 더 이상 필요하지 않을 때 등). 결국 저희는 씬 전환기[Scene Switcher]에 대한 아이디어를 생각해 냈습니다.

각 씬 전환기는 자식으로 두 개의 "게이트" 게임 오브젝트를 보유합니다. 각각에 2D 물리적 트리거 콜라이더가 있습니다(일반적으로 직사각형이지만 장면 레이아웃에 맞게 필요한 경우 어떤 식으로든 모양이 지정될 수 있음). 씬 전환기에는 로드 및 언로드 해야 하는 씬 이름 필드도 있습니다. 그런 다음에 게이트와의 상호작용을 추적합니다. 1 => 2 방식의 플레이어와의 상호작용은 씬을 로드 해야하고 2 => 1의 상호작용은 장면을 언로드해야 합니다.

작은 "1" 및 "2" 텍스트가 있는 흰색 직사각형은 장면 전환기입니다. (역주: 문자가 길게 늘어나 있습니다.)

씬 시스템

씬 전환기는 씬을 로드하거나 언로드하려는 플레이어의 의도를 알 수 있습니다. 그러나 저희는 씬을 로드하는 실제 프로세스를 다른 싱글톤 시스템 클래스로 분리하여 플레이어의 모든 의도와 이미 로드된 장면을 추적합니다.

이것은 다음과 같은 몇 가지 작업을 수행합니다.

씬 이름과 씬이 필요한 플레이어의 목록이 키와 값인 필요한 씬이 포함된 딕셔너리(Dictionary)를 저장합니다. 그런 다음 딕셔너리를 갱신하기 위해 UpdateGameObjectNeededScenes(GameObject GO, string sceneName, bool shouldLoad) 메서드를 제공합니다.
Unity 내장 씬 관리 이벤트를 구독하여 최신 상태로 유지하는 현재 로드된 씬(씬 이름과 로드 상태를 키와 값으로)이 포함된 딕셔너리를 저장합니다.
게임의 업데이트 루프에서 로드된 씬과 현재 필요한 씬이 일치하는지 확인하는 기능을 실행하고, 일치하지 않으면 씬의 로드 및 언로드를 시작합니다.

물론 실제 구현에는 수십 개의 헬퍼 함수와 기타 변수가 포함되지만 어쨌든 이것이 핵심입니다. 이 아키텍처를 사용하여 처음 두 가지의 문제(이 글의 시작 부분에 언급됨)를 정상적으로 해결하고 있습니다.

반면에 성능에 대한 세 번째 문제는 따로 장문의 글이 필요합니다. 그러면 어떤 문제점과 도전이 있었고 저희가 어떻게 해결했는지 알아보겠습니다.

가산적 로딩 성능 개선

Unity가 백그라운드에서 씬을 로드하는 방식은 씬이 로드되는 동안 잘 작동합니다. 그러나 마지막 프레임에서 Unity는 모든 게임 개체를 생성하고 활성화합니다(엔진이 개체 간의 종속성을 알 수 없기 때문에 정상적인 동작). 이로 인해 상당한 지연[Rag]이 발생하게 됩니다.

지연의 심각성은 주로 다음 두 가지 사항에 따라 달라집니다.

각각 사용된 에셋 및 리소스 수와 씬의 게임 오브젝트 수
연결된 MonoBehaviour 컴포넌트의 수(특히 Awake 혹은 Start 메서드에서 실행되는 논리가 있는 경우에 해당됨)

따라서 저희는 이를 기반으로 성능을 개선하기 위한 몇 가지 다른 접근 방식이 있습니다.

씬을 더 작게 만듭니다. 예를 들면 그 안에 있는 게임 오브젝트의 수를 줄이면 성능이 향상될 수 있습니다. 하지만 전체 게임에서 씬 전환 및 로딩이 더 자주 발생해서 게임의 관리가 훨씬 더 어려워집니다.
MonoBehaviour의 수를 줄입니다. 이는 성능 향상을 위한 유효한 접근 방식입니다. 하지만 저희의 경우에는 Moo Lander에 있는 대부분의 게임 오브젝트가 수행하는 복잡한 동작 때문에 쉽지 않았습니다.
어떻게든 씬의 모든 게임 오브젝트를 동시에 활성화하지 않는 방법을 찾습니다. 그렇게 하면 복잡성을 줄일 필요도 없었고 엄청난 성능 향상을 달성했기 때문에 이것이 우리에게 가장 좋은 접근 방식이었습니다.

게임 개체의 지연된 활성화

그렇게 하려면 먼저 Unity가 씬 로드 시 자동으로 이 작업을 수행하지 않도록 해야 합니다. 불행스럽게도 저희는 그렇게 할 수 있는 내장된 방법이 없었기 때문에 그냥 진행했고 다음 작업을 수행해야만 했습니다.

씬의 모든 게임 오브젝트를 하나의 씬 게임 오브젝트의 자식으로 만들었습니다.
모든 물리적 상호 작용 가능한 게임 오브젝트는 씬 게임 오브젝트의 직계 자식인 Interactables 게임 오브젝트로 이동시켰습니다.
게임 빌드를 만들 때 모든 씬 게임 오브젝트를 비활성화하는 툴을 만들었습니다. 이렇게 하면 Unity가 씬을 로드할 때 비활성화된 상태로 로드됩니다.

그런 다음에 씬이 로드된 후 다음 동작으로 장면 로드 및 언로드를 담당하는 씬 시스템을 확장했습니다.

로드된 장면의 맨 위에 비활성화된 씬 오브젝트가 있는지 먼저 확인합니다.
하나가 있으면 하위 게임 개체의 지연된 활성화를 수행하려는 것을 의미하므로 모든 다중 수준 하위를 반복하고 하나씩 비활성화합니다.
상위 씬 오브젝트를 다시 활성화합니다. 이 시점에서는 모든 하위 항목이 비활성화되어 있기 때문에 아무것도 표시되지 않습니다.
모든 자식을 순회하는 코루틴을 시작하고 프레임마다 일정량씩 활성화합니다. 매우 중요한 점은 이 코루틴 루프가 Interactables 홀더를 건너뛰어야 한다는 것입니다. 시간이 지남에 따라 물리 오브젝트를 활성화하면 잠재적으로 잘못된 동작이 발생할 수 있기 때문입니다(땅보다 먼저 적을 활성화하면 적을 떨어뜨리는 것처럼).
그런 다음 모든 Interactable 게임 오브젝트를 한 번에 활성화합니다(여전히 약간의 성능 지연이 발생하지만 처음과 같이 수 천 개의 오브젝트 대신에 수 십 개만 활성화하기 때문에 훨씬 더 작음).

이를 통해 저희는 Unity로 씬을 추가 및 비동기식으로 로드할 때 불쾌한 성능 스파이크를 제거하여 플레이어 경혐의 품질을 개선했습니다.

보너스 팁 - 씬을 언로드해도 실제로 씬에서 사용된 텍스쳐 및 기타 에셋이 모두 언로드되는 것은 아닙니다. 그렇기 때문에 게임 플레이 중에 액션이 많지 않은 순간에 내장된 UnloadUnusedAssets 메서드를 때때로 호출해주어야 합니다. 이는 성능에 약간의 스파이크를 일으키지만 저희는 여전히 Unity 동작을 최적화해야하는 지점에 도달하지 못했습니다.

또한 씬의 비동기 로드 개선에 대한 다른 통찰을 보고싶다면 이 링크를 확인하세요.

결론

보셨다시피 게임 내내 플레이어가 필요로 하는 모든 것을 로드하기 위해 많은 일이 일어나고 있습니다. 그리고 Moo Lander를 마친 후에는 이 모든 것을 플러그인으로 패키징하여 미래의 동료 개발자를 위해 많은 시간을 절약할 것입니다.

물론 게임 씬과 오브젝트(씬 사이를 이동할 수 있는 영구 오브젝트[Persistent objects]등)에 더 많은 일이 발생하지만 향후 글에서 이에 대한 통찰을 공유해보겠습니다. 현재로서는 이 글이 추가 씬 로딩 문제에 대한 훌륭한 솔루션을 구축하는데 충분한 지침이 되기를 바랍니다.

Dimitar Popov, The Sixth Hammer의 공동 설립자이자 게임 개발자

번역 후기

저도 유니티에서 씬 스트리밍 까지는 아니지만 로딩 화면 구현과 관련해서 고생한 적이 있었는데요. 처음 구현하는 것 이기도 했고, 로딩하는 과정 자체가 게임 진행에 부하가 큰 작업이기 때문에 씬 간에 전이 효과를 주려고 해도 버벅거리는 문제가 있었습니다. 그 이후에 원글을 보게 되었는데요. 유니티의 성능 한계를 뛰어넘기 위해 고군분투한 모습에 감명받았고 잠이 확 달아난 저는 바로 블로그와 번역기를 켜서 한땀 한땀 번역해버렸습니다.

의역이 많은데, 완전 의미가 다른 의역이 있다면 이 글을 읽으시는 다른 분들을 위해 댓글로 달아주시면 감사하겠습니다.

페이지 테스트

맛난호빵 — Tue, 24 Aug 2021 16:22:48 +0900

가나다라마바사아자차카타파하

이동식 저장소 폴더 숨기기 유틸리티 - Hider 1.1v

맛난호빵 — Sat, 31 Jul 2021 20:40:26 +0900

Hider 1.1v.zip

0.73MB

Hider는 등록된 컴퓨터에서만 실행되는 포터블형 폴더 숨김 프로그램입니다. VeraCrypt와 같은 파티션 단위 암호화 프로그램이나 다른 폴더 숨기기 프로그램과는 다르게 비밀번호 없이, Hider가 설치된 이력이 있는 컴퓨터에서만 폴더를 숨기고 드러낼수 있습니다. 따라서 이동식 저장소에 있는 폴더를 숨길 때 적절합니다.

설치 및 사용법

Hider 프로그램을 숨길 폴더의 상위에 복사합니다.

명령 프롬프트를 실행하고 해당 폴더로 이동합니다.
시스템 등록을 위해 '<Hider 프로그램 파일 이름> install'이라고 입력합니다. (일반적인 경우 'Hider install')
만약 이전에 시스템 등록 과정을 수행한적이 있다면 탐색기에서 바로 Hider를 실행하셔도 좋습니다.
Hider가 실행되었습니다.
'숨기기'를 선택하고 숨길 폴더의 이름을 입력합니다.
폴더가 숨겨졌습니다.
폴더를 드러내려면 메인메뉴에서 '드러내기'를 선택하고 숨겨진 폴더의 이름을 입력합니다.
폴더가 드러났습니다.
컴퓨터에서 Hider의 실행을 방지하기 위해 등록을 해제하려면 명령프롬프트에서 '<Hider 프로그램 파일 이름> uninstall'이라고 입력합니다.

동작 원리

폴더의 속성을 시스템, 숨김 속성으로 변경하는 원리입니다. 숨겨진 시스템 폴더는 탐색기에서 일반적인 방법으로 볼 수 없게 되어있습니다.

주의사항

Hider는 폴더를 암호화하지 않습니다. 이 프로그램을 사용함으로써 발생되는 모든 문제는 책임 지지 않습니다.

이동식 저장소를 일시적으로 다른 사람에게 빌려주어야하는 경우에만 이 프로그램을 사용하는 것을 권장합니다.

C# 파일 API의 한계로 전체 경로 길이가 260자를 넘어갈 경우 오류가 뜰 수 있습니다. 가급적 짧은 경로에서 사용을 권장합니다.

업데이트 이력

1.0v	- 최초 배포
1.1v	- 폴더 이름이 영어일 때 실제 이름의 대소문자가 입력된 대로 치환되는 문제 수정 - 폴더 이름 입력시 단일 이름 대신 경로를 입력했을 경우 가장 상위의 폴더만 동작하도록 수정