베르의 프로그래밍 노트

Visual Studio 2017 Community 설치 실패 문제 해결하기(Error 0x80004003:)

Visual Studio에 추가적인 워크로드를 설치하는 도중에 실수로 컴퓨터를 재부팅하게 되었는데 그 이후로 추가 워크로드를 설치할 수 없는 문제가 발생했다. 그래서 Visual Studio를 완전히 제거하고 다시 설치해야 했는데, Visual Studio를 제어판에서 삭제한 이후에 Microsoft Download Center에서 vs_Community 설치 파일을 받아서 설치할 때 문제가 발생했다.

vs_Community 부트스트랩이 설치 파일들을 받아오는데까지는 성공하지만 이후에 Visual Studio를 설치하는데는 계속해서 실패하는 문제였다. 그래서 로그를 확인해보니 다음과 같은 내용이었다.

[----:----][2017-06-09T10:54:38] Error 0x80004003:
   위치: Microsoft.VisualStudio.Setup.Cache.InstanceRepository.GetInstance()
   위치: Microsoft.VisualStudio.Setup.Cache.CacheRepository.<GetInstances>d__28.MoveNext()
   위치: System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   위치: Microsoft.VisualStudio.Setup.Engine.VerifyInstallationPath(IServiceProvider services, String installationPath, IInstance instance, IQuery query)
   위치: Microsoft.VisualStudio.Setup.Engine.Install(Product product, String destination, CancellationToken token)개체 참조가 개체의 인스턴스로 설정되지 않았습니다.

해결법

위의 로그에서 발견한 에러 코드를 구글에 검색한 결과 다음과 같은 해결 방법을 찾았고, 해결 방법대로 수행한 결과로 성공적으로 Visual Studio 2017 Community의 설치를 마칠 수 있었다. 해결책은 다음과 같다.

1) 현재 설치되어 있는 Visual Studio가 있다면 제어판에서 언인스톨할 것.

2) Program Files 폴더 내 혹은 Visual Studio가 설치된 경로에 있는 Microsoft Visual Studio 폴더를 삭제할 것.

3) C:\ProgramData\Microsoft\Visual Studio\Setup 폴더를 삭제할 것.

4) C:\ProgramData\Microsoft\Visual Studio\Packages 폴더를 삭제할 것.

위의 과정을 모두 진행했다면, Visual Studio의 재설치를 진행하면 문제없이 재설치가 가능할 것이다.

해결법의 출처

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

악마의 문법, goto

프로그래밍을 공부하면 여러가지 프로그래밍 문법과 기능과 그것을 다루는 기술들을 배우게 된다. 그렇게 배우는 문법들의 중의 하나가 바로 goto 인데, 이 goto 문에 대해서는 여러 프로그래머들의 부정적인 시각이 강하다. 오죽하면 이 goto 문을 알려주고 나서 하는 제일 첫 마디가 "가급적 사용하지 말라"이겠는가?

이 goto 문의 사용을 권장하지 않는 이유는 하나다. 코드의 가독성을 심각하게 해친다는 것이다. 물론 goto를 사용한다고 해서 무조건 코드의 가독성을 해치는 것은 아니지만 다음처럼 사용하게 된다면 많은 문제가 발생하게 될 것이다 :

void f()
{
    int i = 10;

    if (i > 100)
    {
        I100:
        if (i < 200)
        {
            goto I200;
        }
        else if (i < 300)
        {
            goto I300;
        }
    }
    goto I100;

I200:
    cout << 1 << endl;
    return;
I300:
    cout << 2 << endl;
    return;
}

위의 예시처럼 코드 이곳저곳을 뛰어넘게 되는 goto 문이 많을 경우나 goto I100; 부분처럼 조건에 맞지 않는 상황에서 조건문 안으로 강제 진입하게 만드는 goto 문이 있을 경우는 심각한 문제가 된다. 다른 작업자가 작업하게 되거나 작성자 자신이 재작업할 때, 코드의 흐름을 읽어내기가 어려워지고 조건문과 코드를 신뢰할 수 없게 될 것이다.

그렇다면 적절한 goto 문의 사용법이란 무엇인가? 사실 모든 프로그램은 goto 문 없이도 작성이 가능하다. 그렇기 때문에 goto문을 사용하지 않도록 권장하는 것이기도 하다. 하지만 이 goto 문 역시 적절하게 사용하면 기존의 방식보다 편하게 코드를 작성이 가능하다.

그 첫 번째 예시는 2중 이상의 반복문에서 탈출할 때이다. 반복문에서 탈출할 때 주로 사용되는 문법은 break인데, 이 break는 한 번에 단 하나의 반복문만을 탈출할 수 있다. 그래서 break로 2중 이상의 반복문을 탈출할 때는 다음과 같이 코드를 작성해야 한다 :

int main()
{
    bool isBreak = false;
    for (int i = 0; i < 10; i++)
    {
        for (int j = 0; i < 10; j++)
        {
            if (/*탈출조건*/)
            {
                isBreak = true;
                break;
            }
        }
        if (isBreak)
            break;
    }
}

위의 예제처럼 goto 문을 사용하지 않아도 2중 반복문을 탈출할 수 있지만, 하나의 논리 변수를 추가로 사용하고 분기문 역시 추가로 사용해야 한다. 그리고 이것은 반복문의 깊이가 깊어질 수록 사용되는 분기문의 숫자 역시 늘어나게 될 것이다(흔하지 않은 경우이기는 하다). 하지만 다음과 같이 goto 문을 사용하면 논리 변수와 반복문을 추가로 사용하지 않고도 단번에 다중 반복문을 탈출할 수 있게 된다 :

int main()
{
    for (int i = 0; i < 10; i++)
    {
        for (int j = 0; i < 10; j++)
        {
            if (/*탈출조건*/)
            {
                goto BREAK;
            }
        }
    }
BREAK:
}

두 번째 예시는 재입력 처리이다. 만약 1-3 값 만을 입력해야 하는 프로그램이 있다면,  그 이외의 값이 들어온다면 사용자가 값을 다시 입력하도록 프로그래밍해야할 것이다. 여기에 사용되는 일반적인 방법은 do-while 문을 사용하는 방법과 무한 loop에 진입시킨 이후에 옳은 값을 입력했다면 루프에서 탈출시키는 방법이다.

int main()
{
    int i = 0;

    // do-while 문을 사용하는 방법
    do
    {
        cout << "값을 입력하세요(1~3)(do-while) :: ";
        cin >> i;
    } while (i < 1 || i > 3);

    // 무한 loop를 사용하는 방법
    while (true)
    {
        cout << "값을 입력하세요(1~3)(무한루프) :: ";
        cin >> i;
        if (i > 0 && i < 4)break;
    }
}

이 경우에도 충분히 goto 문이 사용될 수 있다.

int main()
{
    int i = 0;

WRONGINPUT:
    cout << "값을 입력하세요(1~3)(무한루프) :: ";
    cin >> i;
    if (i < 1 || i > 3)
        goto WRONGINPUT;
}

이렇듯 충분히 가독성을 해치지 않는 선을 지키면서도 goto 문을 사용할 수 있다. 프로그래밍을 하면서 중요한 점은 바로 이것이다. 프로그래밍에 필요한 모든 것을 최대한 활용하되 과하게 사용하지 말고 적절한 위치에 적절하게 사용하라는 것이다. 그것만으로도 코드는 충분히 깔끔해지고 작업 효율성이 상승하게 될 것이다.

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

나는 과거에 같은 학교를 다니는 후배들에게 프로그래밍 멘토링을 진행한 적이 있다. 물론 지금도 그렇게는 뛰어나지 않고 그 당시에도 뛰어나지 않은게 내 프로그래밍 실력이었지만 적어도 막 입문한 친구들에게 가르쳐줄 정도는 되었던 것 같다.

뭐, 중요한 점은 그 부분은 아니고, 내가 그때 가르쳤던 친구들이나 혹은 내 주변 사람들이 가르치던 사람들이 공통적으로 하던 이야기가 있는데, 그것은 바로 "머리 속으로는 어떻게 만들어야 할지 알겠는데, 막상 코드로 옮기려고 하니 너무 어렵다." 라는 것이었다. 물론 이런 이야기 없이 그냥 쭉쭉 잘해 나가던 친구들도 있었다. 자랑은 아니지만 나 역시 저런 생각을 해본 적이 없는 편에 속해서, "아니 이게 무슨 말인가?" 싶었다. 어떻게 만들어야 할지 알았으면, 그냥 코드로 만들면 되는거지, 왜 코드로 옮기려고 하면 그게 안된다는 것인지 그 당시에는 도무지 이해가 되지 않았다.

하지만 내가 프로그래밍을 공부한 과정을 곰곰히 되새겨본 결과, 프로그래밍을 배우기 시작한 지 얼마 되지 않았을 때의 나 역시 같은 문제에 부딪힌 적이 있다는 것을 깨달을 수 있었다. 그것을 깨닫고 난 이후에 내가 다시 생각하게 된 것은 "머리 속으로는 어떻게 만들어야 할지 알겠는데, 막상 코드로 옮기려고 하니 너무 어렵다."라는 문제에는 누구나 부딪히게 된다는 것이고, 진짜로 그 시점에서 중요한 문제는 "코드로 옮기려고 하니 어렵다."가 얼마나 어려우냐보다 "그 상태에서 얼마나 빨리 벗어나느냐"라는 것이다.

누군가는 "머리 속으로는 어떻게 만들어야 할지 알겠는데, 막상 코드로 옮기려고 하니 너무 어렵다." 라는 말을 일주일 정도 하더니 더 이상 그런 말을 하지 않고 프로그래밍을 하게 되고, 누군가는 그 말을 1년도 더 넘게 하고 있다면, 그 차이는 무엇에 있는 것일까?

난 그 차이가 숙달과 경험, 그리고 연습량에 달려있다고 본다.

간단한 예를 들자면, 한 번도 요리를 해본 적도 없는 사람에게 마파두부를 만들고 시켰다고 해보자. 그 사람의 머리 속에는 자신이 평소에 먹던 마파두부가 떠오를 것이다. 하지만 막상 요리를 진행하면 그 사람은 무엇부터 해야하는지 모르고 우왕좌왕하게 될 것이다.

그러면 그 다음엔 요리를 해본적 없는 사람에게 마파두부를 만드는 법을 알려주고 만들라고 시켜보자. 과연 그 사람은 완벽하게 마파두부를 만들어낼 확률이 높을까? 아니다. 분명 상당한 시간이 걸리고도 제대로 된 결과물을 만들어 내지 못할 확률이 높을 것이다. 칼질은 서투르고, 재료도 볶다가 태울지도 모른다. 그리고 레시피를 이미 알고 있지만, 그것을 제대로 따라하지 못하고 버벅대는 경우가 많을 것이다. 그렇다면 이 사람이 마파두부를 잘 만들기 위해서는 어떻게 해야 할까? 답은 하나 뿐이다. 마파두부를 계속 만들어 보는것.

나는 프로그래밍도 이것과 마찬가지라고 생각한다. 머리 속에 만들어진 논리를 코드로 바꾸는 능력을 많은 프로그래밍을 통해 숙달시키는것과 머리 속에 들어있는 마파두부 만드는 법을 많은 연습을 통해 익히는 것. 무엇이 다른가?

앞서서 나는 이 과정을 상당히 빨리 벗어났다고 이야기 했었다. 나는 한때 내 꿈이 무엇인지를 놓고 방황하다가 24의 나이가 되어서야 프로그래밍에 입문했다. 게임을 만들기 위해서. 그리고 내가 게임 프로그래밍을 배울 수 있는 학교에 왔을 때, 내 주변의 친구들은 아직 20살이었고, 군대를 다녀온 시간 2년을 그 친구들보다 앞서있다고 생각해도 2년은 뒤쳐져서 시작하는 것이었다. 그러니 당연히 이렇게 생각할 수 밖에 없었다. 남들보다 더 많이 코딩을 하자. 분명 이 프로그래밍 책의 뒤에 예제의 해답이 있는 건 알지만, 나만의 답, 내가 해결하기 전에는 보지 말자. 책의 해답이 더 나은 것이라면 익히고, 내 답이 더 나은 것이라면 뿌듯함을 느끼면 된다. 그렇게 공부를 하니 남들이 "코드로 옮기는 것이 어렵다"는 말에 공감하기 어려워질 정도로 그 단계를 빨리 지나가 버렸다.

연습량이 적은 데에는 3가지 이유가 있을 수 있다.

1. 정말 게을러서.

2. 너무 완벽을 추구해서.

3. 겁이 많아서.

1번은 절실함을 느끼지 않는 한 답이 없다.

2번은 완벽한 코드를 만들어 내야한다는 압박감에 시달려서, 혹은 코드가 작동하는 원리의 깊은 곳까지 알고싶어서, 코드를 이리 뒤지고 저리 뒤지다 한 세월이 걸려서 연습하는 속도도 느려지고 연습량이 적어진다. 물론 이것은 좋은 자세임에는 틀림이 없다. 하지만 지금의 문제를 느끼는 단계라면 너무 과한 태도라고 생각된다. 지금의 단계는 분명 빨리 지나가도 되는 단계일 것이다. 지금 이 단계를 넘어가면 깊이를 알 수 없고 드넓은 바다가 있는데 작은 물웅덩이 속에서 웅덩이 속을 떠다니는 모래 알갱이를 세고 있는 꼴이다. 지금 단계가 그렇게까지 완벽하게 파야되는 단계인지 그렇게까지 완전해야 하는 단계인지 잘 생각해보라.

3번이 가장 일반적으로 많은 케이스라고 생각된다. 코드를 치기 전에도 버그가 나면 어떻게 하지? 하고 시작조차 못하는 혹은 코드 한줄한줄마다 이게 틀렸으면 어떻게 하지? 하는 부류이다. 내 친구의 프로그래밍 과외를 받는 어떤 사람은 그랬다. "이런 것을 만들어보라"고 시키면 마우스를 이리저리 움직여보다 코드 한 줄을 겨우 치고는 묻는 것이다. "이렇게 하는게 맞나요?"하고. 그리고 그 질문은 한줄한줄 계속 된다.

나는 이런 겁 많은 사람들에게 일단 버그가 있든 없든 알 수 없지만 신텍스 에러(Syntax error, 문법 오류)만 없게 주어진 문제를 완성하라고 말하고 싶다. 그리고 컴파일해보면 알게 될 것이다. 버그가 있는지 없는지. 만약 버그가 있다면 버그를 수정하면 되는 것이고 없다면 좋은 것이다. 물론 처음부터 버그가 없게 설계를 한다면 좋겠지만 아무리 좋은 설계라고 해도 버그가 아예 없을 확률은 낮으니, 완성해서 컴파일 해보는 것이 중요한 것이다. 그래야 당신은 프로그래밍 연습을 한 것이고, 공부를 한 것이다.

그러니 연습을 해라. 코딩을 해라. 프로그래밍을 해라.

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

효과적으로 Debug를 하기 위해서는 Debug 빌드를 유지해야한다.

하지만 사람들은 Debug 빌드를 잘 사용하지 않는데 그것은 Debug 빌드의 속도가 Release 빌드에 비해서 컴파일 시간도 실행 시간도 느리기 때문이다.

Debug 빌드는 기본적으로 최적화 기능이 꺼져있기도 하고, 프로그래머가 에러를 찾기위해 온갖 assert를 넣고 하다보면 프로그램이 더욱 느려지기 마련이다.

하지만 Release 빌드는 속도가 빠른 반면에 에러를 잡기위한 디버깅이 힘들어진다. 최적화 단계에 들어선 이후에는 성능이 매우 중요하겠지만 그 이전 단계에서는 프로그램이 얼마나 올바르게 동작하는 가가 제일 중요하다. 그렇기 때문에 버그를 빠르게 찾아내고 수정하기 위해서는 반드시 Debug 빌드를 언제나 컴파일되고 실행되게 유지해야한다.

만약 Debug 빌드가 컴파일되지 않게 망가뜨린 프로그래머가 있다면 그는 반드시 다른 프로그래머가 언제든지 Debug 빌드를 실행시킬 수 있도록 복구시켜 두어야 한다.

Debug 빌드를 사람들이 잘 쓰지 않는 이유는 속도가 느리기 때문인데 속도를 빠르게 하기 위해 무조건 Release 빌드는 쓰는 것이 아니라 어떻게 해서든 Debug 빌드를 빠르게 만들어야 한다.

Debug 기능을 쓸 수 있지만 어느 정도 최적화 기능을 켠 Fast Debug 빌드를 만든다던가. 각 부서별로 자기 부서에 필요한 부분만 Debug로 돌리고 나머지는 Release로 돌릴 수 있게 자동화를 한다던가. 여기저기 있는 assert를 효과적으로 제거한다던가하는 방식으로 말이다.

참고 ::

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]