촘두네 블로그

*스포주의*

최근에 넷플릭스에서 공개된 '삼체' 드라마를 재미있게 봤습니다. 예전에 소설로도 읽었지만, 내용이 너무 방대하고 복잡해서 이해가 쉽지 않았지만, 드라마는 간략하게 요점만 정리해 놓았기 때문에 대중적으로도 인기를 끌 수 있는 좋은 작품이라는 생각이 들었습니다.

그런데, 제 기억으로는 삼체인의 특성과 유사한 외계인이 과거 다른 드라마에서 이미 등장한 적이 있었습니다. 1987년에 방영된 "스타트렉: 넥스트 제너레이션"의 시즌 1, 에피소드 18편입니다. 제목은 "Home Soil"입니다. 스토리는 대략 다음과 같습니다.

인간은 어떤 행성을 테라포밍을 하려고 준비 중이었습니다. 해당 행성에는 지적 생명체가 없었기 때문에 바로 진행하려고 했고요. 그런데, 갑자기 드릴 같은 기계가 오작동을 하면서 인간을 공격하는 사건이 벌어졌습니다. 엔터프라이즈호는 이 사건을 조사하려고 이 행성을 방문하게 됩니다. 그들은 사고 현장에서 빛이 나는 이상한 크리스털을 발견하게 되는데, 마치 그 크리스털이 살아 있는 거 같다는 느낌을 받게 됩니다.

자세한 분석을 위해서 그걸 채취해서 엔터프라이즈호로 가져오는데, 엔터프라이즈 호의 컴퓨터가 해킹을 당하는 등 이상한 현상이 벌어집니다. 알고 보니 크리스털 안에는 아주 작은 외계인이 있었는데, 이들은 현미경으로 봐야 보일 정도로 작고, 실리콘이라는 무기질 기반의 생명체였습니다. 일반적으로 생명체는 대부분 유기질인데, 작고 무기질의 생명체라서 미처 발견을 못했던 것이었습니다. 상당한 지능을 갖춘 생명체라는 걸 알게 된 엔터프라이즈호 승무원들은 해당 지적생명체와 소통을 시도하고, 본인들은 지적 생명체가 있는 행성은 테라포밍 하지 않는다고 얘기를 해서, 서로의 오해를 풀게 되었다는 스토리입니다.

스타트렉에 나온 이 외계인은 반도체와 비슷한 특성을 가지고 있습니다. 혼자서는 별다른 능력이 없지만, 여럿이 뭉치면 엄청난 지능을 발휘하게 되죠. 삼체인의 특징과 유사합니다. 삼체인들도 그들의 몸으로 컴퓨터를 만들 수 있죠.

드라마 삼체에서는 사람으로 비유를 했는데, 작은 무기질의 삼체인은 반도체의 트랜지스터 같은 역할을 할 수 있다고 보면 될 거 같습니다.

"스타트렉: 넥스트 제너레이션"이 방영되기 전인 70~80년대는 현대적인 반도체가 본격적으로 등장하기 시작한 때라서, 당시 SF 드라마 작가들에게도 그런 기술의 발달이 영감을 줘서 반도체 같은 외계인이 스타트렉에도 등장한 걸로 보입니다.

그런데 재미있는 사실은, 스타트렉의 해당 에피소드의 시청률은 매우 낮았습니다. 기존의 다른 에피소드와 성격이 많이 달랐기 때문으로 보이는데요. 어떤 평론가는 "오리지널 Star Trek 시리즈와 달리 'Home Soil'은 하드 공상과학소설의 영역을 탐구했다"라고 얘기하기도 했습니다. 즉, 일반인이 이해하기엔 다소 어려운 설정이 아니었나 싶네요.

삼체 소설은 스타트렉의 해당 에피소드가 나온 지 20여 년이 지난 후에 나왔습니다. 그러니, 아무래도 스타트렉에 등장한 외계인이 삼체인의 원조 같다는 생각이 드네요. 다만, 스타트렉에서는 여러 여건상 표현하기가 쉽지 않았던 그 외계인을 삼체에서는 다양한 방법으로 잘 묘사하고 있다는 느낌이네요.

참고: https://en.wikipedia.org/wiki/Home_Soil

WSL의 우분투에서 앱을 실행하려고 하는데, 이런 에러가 발생한다면

libssl 1.1 라이브러리를 설치해 줘야 한다.

일단 OpenSSL 라이브러리를 모아 둔 경로는 다음과 같다.

http://nz2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/?C=M;O=D 

윈도 10이나 윈도 11 64비트에서 WSL을 사용 중이라면, 위의 경로에서 libssl 1.1 중에서는 AMD64 버전을 받아야 하는데, 이름과 다운로드 경로는 아래와 같다.

libssl1.1_1.1.0g-2ubuntu4_amd64.deb

다운로드 경로: http://nz2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.0g-2ubuntu4_amd64.deb

설치 방법은 다음과 같다.

1. 우분투를 실행하고 위의 파일을 다운로드한다. 명령어는 다음과 같다.

2. 다운로드한 파일을 설치하자. 명령어는 다음과 같다.

참고 링크: https://stackoverflow.com/questions/72378647/spl-token-error-while-loading-shared-libraries-libssl-so-1-1-cannot-open-shar/73074916#73074916

윈도우즈 운영체제에서는 윈도우 애플리케이션이 정상 작동 중인지 확인하기 위해서, 지속적으로 윈도우 메시지를 해당 애플리케이션으로 보내는데, 만약 일정 시간이 지나도 응답이 없으면, 해당 애플리케이션이 응답이 없으니 (강제로) 종료하겠느냐는 팝업을 띄운다. 그런데, 게임 등의 애플리케이션을 개발하다 보면 로딩해야 될 리소스가 많아서 시간이 오래 걸릴 경우가 있는데, 그렇게 로딩하는 와중에 이 팝업이 뜨면 유저는 해당 애플리케이션에 문제가 있다고 생각하고 강제 종료를 하게 될 수 있다. 해결 방법은 크게 두 가지이다.

1. 로딩 처리를 시간이 많이 드는 부분, 특히 파일 로딩을 비동기로 처리해서 메인 스레드에서 윈도우 메시지 처리가 끊기지 않게 하기.

2. 응답 없음 처리(고스팅 처리) 기능을 그냥 끄는 방법

1번이 바람직한 방법이긴 하지만, 프로그램 구조를 바꿔야 하고, 바꾸는 와중에 버그가 발생하기도 하고, 암튼 좀 어려울 수 있다. 2번 방식은 그냥 다음의 함수를 한번 호출해 주면 된다.

DisableProcessWindowsGhosting();

링크: https://learn.microsoft.com/ko-kr/windows/win32/api/winuser/nf-winuser-disableprocesswindowsghosting

참고로, 해당 기능을 다시 켜는 함수는 없다.

UE4Game.Target.cs 파일에 다음의 코드를 추가한다.

if (Target.Configuration == UnrealTargetConfiguration.Shipping || Target.Configuration == UnrealTargetConfiguration.Test)
{
  bAllowGeneratedIniWhenCooked = false;
  bAllowNonUFSIniWhenCooked = false;
}

엔진을 빌드한다.

이후, 게임 프로젝트의 *.Target.cs 파일에도 동일한 코드를 넣는다.

위의 코드를 넣어주면, 게임 구동시 [게임명]/Saved/Config/[빌드설정]/Config 폴더에 ini 파일을 쓰지도 않고, 읽지도 않는다. 단, GameUserSettings.ini 파일은 여전히 읽고 쓴다.

[부작용]

게임 옵션에서 인풋액션 설정을 Input.ini 파일을 통해서 저장하고 있었다면, 해당 기능을 더 이상 쓸 수 없다.

그런 경우, GameUserSettings.ini 파일을 이용하도록 코드를 수정하면 된다.

혹은, 엔진 수정을 통해 Input.ini 파일도 예외로 추가할 수도 있겠다.

몬티홀 딜레마는 미국에서 약 40여 년간 방영한 미국의 TV쇼에서 유래한 확률 문제임.

사회자의 이름인 몬티 홀(Monty Hall)의 이름을 따서 몬티홀 딜레마 혹은 몬티홀 문제(Monty Hall Problem)이라고 불림.

A, B, C 세 개 문 중 하나의 문 뒤에 자동차가 있고, 나머지 문 뒤에는 염소가 있다.

참가자가 하나를 고르면, 정답을 아는 사회자가 나머지 두 개의 문 중 염소가 있는 문을 하나 연다.

이후 참가자에게 답을 바꿀 기회를 준다. 이때, 답을 바꾸는 게 좋을까 아니면 그대로 있는 게 좋을까?

얼핏 보면 최종적으로는 2개 중 하나이니까 50% 확률이라고 생각하기 쉽다.

하지만, 처음에 정답을 골랐을 확률은 1/3이고, 오답이 제거된 상황에서 처음 답을 유지하면 여전히 1/3 확률로 정답이지만, 선택을 바꿀 경우 1 - 1/3 = 2/3로 정답을 맞힐 확률이 올라간다.

좀 더 이해하기 쉽게 처음에 선택지가 10개가 있었다고 가정하자.

처음에 정답을 맞힐 확률은 10%밖에 안된다. 이후 사회자가 나머지 8개의 오답을 모두 제거하고 이제 딱 2개만 남았다고 생각해보자. 이런 경우엔 당연히 본인이 처음에 선택한 문보다는 사회자가 열지 않은 마지막 남은 문에 자연스럽게 눈길이 가게 될 것이다. 사회자가 남긴 문이 정답일 확률이 90%인 것이다.

이 문제를 코드로 작성해서 확인해 보자.

// Online C# Editor for free
// Write, Edit and Run your C# code using C# Online Compiler

using System;

public class HelloWorld
{
    static Random rand = new Random();
    
    static float TestMontyHall(int totalItemCount, bool changeFirstSelection, int testCount)
    {
        int successCount = 0;

        for (int i = 0; i < testCount; ++i)
        {
            int correctIndex = rand.Next(totalItemCount);
            int firstAnswerIndex = rand.Next(totalItemCount);
            
            // 처음 선택을 바꾼 경우
            if (changeFirstSelection)
            {
                // 첫번째 선택이 답이 아닌라면, 바꾼 후에 성공!
                if (correctIndex != firstAnswerIndex)
                    ++successCount;
            }
            else // 선택을 바꾸지 않은 경우
            {
                // 첫번째 선택이 정답인 경우에만, 성공
                if (correctIndex == firstAnswerIndex)
                    ++successCount;
            }
        }
        
        return (float)successCount / testCount;
    }
    
    public static void Main(string[] args)
    {
        Console.WriteLine ("Hello Monty Hall Problem World");
        
        Console.WriteLine ("If you change the first selection, success ratio is " + TestMontyHall(3, true, 10000));

        Console.WriteLine ("If you don't change the first selection, success ratio is " + TestMontyHall(3, false, 10000));
    }
}

결과는 아래와 같다.

몬티홀 문제를 풀게 될 경우가 생긴다면, 처음 선택을 고집하지 말고 답을 바꾸자!

잡을 복사했는데 "빌드" 버튼이 보이지 않는다.

이럴 경우 "구성"으로 들어가서..

"저장"을 한번 해 주면 된다.

끝.

4.26 기준.

1.Diff 후 BP 컴파일 에러

소스 컨트롤과 Diff를 하고 난 이후 게임을 컴파일하면 느닷없이 컴파일 에러가 뜰 때가 있음.

자세히 보면 에러나 블루프린트(BP) 파일에 temp 어쩌고 하는 이름이 들어 있음.

Diff를 할 때 임시로 생성한 예전 BP파일을 컴파일하려다가 오류가 발생하는 걸로 보임.

대처법: 에디터를 껐다가 다시 켠다.

2.BP 컴파일 도중 검색하면 에디터 먹통

Find in blutprints에서 뭘 찾고 있는 동안 BP를 컴파일하면 에디터가 간혹 먹통이 된다.

대처법: 작업 관리자에서 에디터를 강제로 종료하고 다시 켠다.

3.PIE 도중 검색하면 에디터 먹통

에디터에서 게임을 플레이(PIE)하는 도중에 Find in blutprints에서 뭘 찾으면 간혹 에디터가 먹통이 된다.

대처법: 작업 관리자에서 에디터를 강제로 종료하고 다시 켠다.

퍼포스에서 sync나 submit 작업 시 멀티 스레드로 동시에 여러 파일을 전송하면 성능을 향상할 수 있다.

해당 기능을 적용하려면 퍼포스 관리자 권한이 있어야 한다.

관리자라면 퍼포스 서버에 직접 들어갈 필요 없이 본인 PC에서 원격으로 설정할 수 있다.

먼저, 콘솔창을 연다.

현재 서버에 설정된 값을 보는 방법은 다음과 같다.

서버의 병렬처리 기능을 켜고 싶다면 다음의 명령어를 쓰면 된다. (숫자는 스레드 개수인데 1보다 커야 한다)

참고로, 서버를 재시작할 필요 없이 바로 적용된다.

서버에 위의 옵션을 켜 놓으면 클라에서는 바로 멀티 스레드를 활용할 수 있다.

예를 들어 다음과 같이 사용하면 된다.

만약, 모든 클라에 기본으로 병렬 sync 옵션을 적용하고 싶으면, 다음의 변수를 추가로 설정하면 된다.

submit에 대해서도 모든 클라에 기본으로 적용하고 싶으면, 다음의 변수를 설정하면 된다.

위의 모든 옵션을 적용했을 때 설정값은 다음과 같다. (p4 configure show 명령어 사용)

설정된 변수를 지우고 싶으면 unset 옵션을 써서 삭제하면 된다.

참고로 퍼포스 클라이언트 UI(p4v)에서는 병렬 서밋 옵션은 기본적으론 꺼져 있다.

참고 링크:

https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_sync.html#Parallel

ps. 병렬처리 옵션을 켠다고 다 좋은 건 아니다. 싱글 스레드 방식의 p4v에서 sync 시에는 읽기 전용 속성이 풀린 파일을 찾아내 강제로 받을 것인가를 물어보는 팝업이 뜨지만, 병렬처리 시에는 이게 작동하지 않을 수 있다. 또, 많은 사람이 동시에 sync를 받으면 서버에 과부하가 걸리기도 한다.

서밋을 할 때도 여러 사람이 동시에 많은 파일을 서밋 하면 서버가 멈추는 경우가 생길 수 있다.

ps. 사실, 이런저런 문제점들 때문에 net.parallel.max 옵션만 설정하고, 빌드서버에서만 --parallel=threads 옵션을 넣어서 사용 중이다. 바이너리 파일을 서밋 할 때 zip으로 압축을 하는데, 멀티 스레드를 사용하지 않으면 많이 느리다.

보안 이슈 등으로 인해 젠킨스 플러그인들에 대한 업데이트가 필요하다는 경고가 떴다.

젠킨스 플러그인 들을 업데이트를 하려고 하니 에러가 난다.

대략 위와 같은 에러이다.

해결책 1.

젠킨스 관리의 플러그인 관리 페이지로 들어간다.

"고급" 탭을 누른다.

업데이트 사이트에서 프로토콜이 https로 시작하고 있다면, http로 바꾼다.

Submit을 눌러서 적용한다.

그런데, 본인의 젠킨스는 위의 방법을 적용했더니, 플러그인이 한번에 딱 하나만 받아지는 문제가 발생했다.

하나 받고 재부팅하고, 하나 받고 재부팅하는 식으로 계속 반복을 해줘야 했다.

에러 내용도 처음에 얘기했던 것과 같은 인증 문제이다.

한참 구글링을 하다가 아래의 사이트에서 방법을 찾았다.

https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/SunCertPathBuilderException-fix-for-Jenkins-plugin-download

해결법2.

젠킨스 플러그인 중에 skip-certificate-check 라는 게 있다.

이걸 설치하고 재부팅을 한번 하자.

이후엔 잘 된다.