노년코딩

Google AdMob을 사용해 내가 만들고 있는 유니티 앱에 광고를 넣을 수 있다.
크게 어렵지 않아서 따라 해 보면 바로 광고가 나오는 것을 확인할 수 있을 것이다.
 

우선 첫 번째로 구글 애드몹을 알아야 한다.

1. 구글 애드몹에 가입을 한다.
2. 구글 애드몹에 자신의 어플을 등록시켜 준다.
3. 광고단위를 클릭하고 자신에게 필요한 광고 단위를 선택해 생성해 준다. 나의 경우 전면 광고를 선택해 주었다.
광고 단위 추가 버튼을 통해서 필요한 광고를 추가해 줄 수 있다.

자신의 앱 ID는 알아둬야 하니 복사 필수

 
>> 앱 ID는 두 군데서 확인 가능하다. 1번째로 앱 >> 모든 앱 >> 앱 ID.

 
>> 두 번째로 앱설정에서 앱 ID 확인. 편한 곳에서 확인하고 알아두도록 하자.

자신의 광고 단위 ID도 알아둬야 됨.

 
여기서 저 광고 단위 ID가 중요하다. 일단 적어두거나 다른 곳에 복사해 두자.  나중에 스크립트에서 사용할 것이다.
이제 구글 애드몹에서 해줄 내용은 끝이 났다.
 

두 번째로 유니티 플러그인을 설치해 주자.

1. 유니티 플러그인으로 Google Mobile Ads Unity Plugin을 받아 설치해 주자.
(아래 링크 참고, 블로그에 적어 둘 당시 이게 최신 같아 보였다. 더 최신 버전이 있다면 선택해서 설치하자.)

https://github.com/googleads/googleads-mobile-unity/releases/tag/v9.3.0

 
설치하고 난 뒤에 유니티에서 열어주자. 다 설치가 되면 Assets >> GoogleMobile Ads >>Settings을 누르고  Inspector 창에서 아까 첫 번째로 기억해 뒀던 자신의 Google Mobile Ads App ID를 적어주자.

이제부터가 중요하다.

코드를 써보자. 물론 우리에게는 다행히 도움의 손길이 있다.

https://developers.google.com/admob/unity/interstitial?hl=ko

광고들 마다 어떻게 사용해야 하는지 친절하게 설명해 준다. 역시나 필요한 걸 찾아서 사용하자.
https://developers.google.com/admob/unity/rewarded?hl=ko

나의 경우 전면 광고였으니 위에 나와있는 도움의 손길을 토대로 그대로 따라 해 주자.

나의 경우 광고매니저 오브젝트를 만들어 스크립트를 하나 추가해주었다. 그대로 써주자.

using GoogleMobileAds;
using GoogleMobileAds.Api;
using System;
using UnityEngine;


// https://developers.google.com/admob/unity/interstitial?hl=ko 참고

public class GoogleMobileAdsScript : MonoBehaviour
{
    public GoogleMobileAdsScript instance;

    private InterstitialAd _interstitialAd;

    // These ad units are configured to always serve test ads. 
    //자신의 광고단위ID 넣어주기
#if UNITY_ANDROID
    //private string _adUnitId = "";
    private string _adUnitId = "";
#elif UNITY_IPHONE
   // private string _adUnitId = "";
#else
  private string _adUnitId = "unused";
#endif


    public void Awake()
    {
        // Initialize the Google Mobile Ads SDK.
        MobileAds.Initialize((InitializationStatus initStatus) =>
        {
            // This callback is called once the MobileAds SDK is initialized.
        });
    }


    public void Start()
    {
        LoadInterstitialAd();
    }
    
    
    public void LoadInterstitialAd()
    {
        // 이전에 로드된 광고 체크, 있으면 제거하고 해제
        if(_interstitialAd != null)
        {
            _interstitialAd.Destroy();
            _interstitialAd = null;
        }

        // 새로 광고를 로드하기위한 요청 생성
        var adRequest = new AdRequest();

        // 광고단위 ID _adUnitId와 adRequest 객체를 전달 받아 광고를 로드.
        InterstitialAd.Load(_adUnitId, adRequest,
            (InterstitialAd ad, LoadAdError error) =>
            {
                if (error != null || ad == null)
                {
                    Debug.LogError("interstitial ad failed to load an ad" + "with error : " + error);
                    return;
                }

                Debug.Log("Interstitial ad loaded with response : " + ad.GetResponseInfo());

                _interstitialAd = ad;
                
                // 성공한 경우 로드된 광고에 대한 이벤트 핸들러를 등록.
                RegisterEventHandlers(_interstitialAd);
            });
    }

    // Shows the interstitial ad.
    public void ShowInterstitialAd() //광고 표시
    {
        if (_interstitialAd != null && _interstitialAd.CanShowAd())
        {
            Debug.Log("Showing interstitial ad.");
            _interstitialAd.Show();
        }
        else
        {
            LoadInterstitialAd(); //광고 재로드
            Debug.LogError("Interstitial ad is not ready yet.");
        }
    }

    // 전면광고에 발생하는 이벤트에 대한 핸들러 등록
    private void RegisterEventHandlers(InterstitialAd interstitialAd)
    {
        // 전면광고 지급 관련 이벤트
        interstitialAd.OnAdPaid += (AdValue adValue) =>
        {
            Debug.Log(String.Format("Interstitial ad paid {0} {1}.",
                adValue.Value,
                adValue.CurrencyCode));
        };
        // 
        interstitialAd.OnAdImpressionRecorded += () =>
        {
            Debug.Log("Interstitial ad recorded an impression.");
        };
        // 전면광고가 클릭 되었을 때 이벤트
        interstitialAd.OnAdClicked += () =>
        {
            Debug.Log("Interstitial ad was clicked.");
        };
        // 전면광고가 열렸을 때 호출
        interstitialAd.OnAdFullScreenContentOpened += () =>
        {
            Debug.Log("Interstitial ad full screen content opened.");
        };
        // 전면광고가 닫혔을 때 호출
        interstitialAd.OnAdFullScreenContentClosed += () =>
        {
            Debug.Log("close Scene");
        };
        // 전면광고가 못 열였을 때 호출
        interstitialAd.OnAdFullScreenContentFailed += (AdError error) =>
        {
            Debug.LogError("Interstitial ad failed to open full screen content " +
                           "with error : " + error);
        };
    }

    private void RegisterReloadHandler(InterstitialAd interstitialAd)
    {
        // Raised when the ad closed full screen content.
        interstitialAd.OnAdFullScreenContentClosed += () => 
        {
            Debug.Log("Interstitial Ad full screen content closed.");

            // Reload the ad so that we can show another as soon as possible.
            LoadInterstitialAd();
        };
        // Raised when the ad failed to open full screen content.
        interstitialAd.OnAdFullScreenContentFailed += (AdError error) =>
        {
            Debug.LogError("Interstitial ad failed to open full screen content " +
                           "with error : " + error);

            // Reload the ad so that we can show another as soon as possible.
            LoadInterstitialAd();
        };
    }

}

 
이제 다 끝났다. 유니티에서 광고를 사용하고 싶은 부분에서 ShowInterstitialAd 함수를 불러오면 된다.
 

그럼 얘가 나올 것이다.
 
 
 
 
 
 
이렇게 다 하고 광고 나오는 건 확인했는데 유니티 Gradle 문제가 생겨서 빌드가 안된다. 하... 속이 상한다.
뭐가 또 문제인 걸까!

룰루루루루루룰루 블로그에 짧은 후기를 남기고 한동안 가을만 느끼며 살던 나에게 기적 같은 일이 일어났다.
찍었던 문제가 다 맞은 것인지 푼 문제가 다 맞은 것인지 합격을 했다.
istqb 불합격 ㄴㄴ!! 유후!

사실 정말 시험이 어려웠어서 기대가 하나도 되지 않는 상황이었다. 집에 돌아오는 길 내내 복기하면서 왔을 정도로 다음 시험을 준비해야 되겠구나 싶었는데 이렇게 합격이 뜨다니! ㅎㅎㅎㅎㅎㅎ
최근 들어서 지금 이 순간이 제일 기분이 좋다.
목요일 밤 9시에 결과가 발표 난다는 것을 알고 있었지만 속상할 것 같아서 텐트 밖은 유럽을 보며 애써 잊었다.
그러다 자기 전에 내일 친구를 만나러 가기 전 결과를 보면 친구한테도 별로 좋지 않은 영향을 줄 것 같다는 생각을 하고 슬그머니 sten을 들어가 봤다.
지난번보다 많이 틀렸으려나 하고 들어간 화면에서 “합격” 문구를 본 순간. 난 내 눈을 의심했다. 뭔가 잘못된 것인가 하는 마음으로 로그아웃하고 다시 들어가 봤다. 새로고침도 하고 결과확인도 다시 클릭해 보고 다해봐도 합격이었다. “합격.” 모두가 자고 있는 이 시간에 난 쾌재를 불렀다. 에헤라디야 둥가둥가 룰룰루 합격이라는 두 글자에 이렇게 기쁠 수 있을까.

일단 istqb ctfl v4.0 시험 합격의 기쁨은 여기까지 하고 간단하게 나의 합격 방법을 적어둔다. 누군가에게 도움이 되길 바라며.

0. 시험 시간 진짜 촉박하다. 40문제를 1시간 안에 풀어야 된다 생각하지 말고 50분 안에 푼다 생각하자. 20문제를 풀고 있는데 25분이 지나가고 있으면 속도를 내야 한다. 시험 보는 날 시간이 여유롭다면 일찍 와서 공부하자. 그때가 제일 공부가 잘 된다. 시험장에는 일찍 들어갈 수 있다. 긴장되니까 화장실은 다녀오고 들어가자. 컴싸도 상관없지만 다한증이라도 있다면 볼펜을 추천한다. 안 번진다. 난 그냥 두 개 다 들고 갔다.
 

1. 나는 샘플문제를 각각 5번 정도 풀어봤다. 아이패드를 사용하는 나로서는 레이어를 나눌 수 있어서 풀고 채점하고 복기하고 다른 날 다시 풀고 채점하고 복기하고를 반복했다. (처음엔 A, B, C, D 순서대로 풀고 두 번째부터는 순서대로 하지 말고 계속 섞어가면서 풀었다.)
 

2. 나의 경우 시험 보러 가기 3일 전 인공눈물을 잘못 사용해서 눈병에 걸렸다. 눈알이 검은 눈동자 빼고 전부 부풀어 올라서 눈이 터지려고 하는 상황에 더 이상 눈을 뜨고 공부를 할 수 없어 다시 유튜브 “김기태 님의 sw강의”를 밤새 들었다. 근데 이게 공부했던 내용을 꽤 정리해 주는 계기가 되었다. 전부 외웠다고 생각해도 놓칠만한 게 분명 생긴다. 나는 강의를 시험 보러 가기 이틀 전 정도에 다시 들어보는 걸 추천한다. + 유튜브 “라메드랩스“ - 단어 풀이해 주는 강의도 꼭 들어보기. 강추. 강추.
 

3. 실라버스 한국어 해석이 그렇게 잘 되어 있지 않다. 영어 버전도 다운로드하여서 번역해서 같이 읽어보는 것을 추천한다. 나의 경우엔 테스트 피라미드 부분을 영어 번역본을 통해 다시 읽어봐서 이해가 됐다. 다른 부분들도 꽤 도움이 되니 화면을 이중으로 켜두고 같이 읽어보는 것을 추천한다. 나는 캡쳐해서 내 한국어 실라버스 옆에 붙여두고 공부할 때 같이 읽었다.
 

4. 외워야 되는 건 그냥 암기가 답이다. 자기 전에 외우고 일어나서 암기했던 부분을 다시 적어보면서 공부를 시작했다. 외워서 맞출 수 있는 문제를 틀리기엔 시험이 너무 어렵다. 그렇게 틀리기엔 아까워서 두고두고 후회할 것이다. 외워서 맞출 수 있는 문제는 꼭 다 외워가자. (테스트 활동과 업무, 테스트 웨어는 무조건 다 외우는 게 낫다. 그 외에 테스트 레벨, 테스팅 사분면, 동적테스트와 정적테스트 차이, 테스팅 지원도구 등등)
 

5. 아이패드나 갤럭시탭이나 용지로 직접 공부하는 것이 아니라면 레이어를 적극 활용해 보자. 한번 정리해서 공부하고 난 뒤 다시 새로운 레이어에서 아무 필기가 안되어 있는 상태로 다시 공부를 하면 내가 놓치고 못 본 부분도 다시 볼 수 있다. 두 개 정도 레이어를 나눠서 공부했다면 두 개의 화면을 같이 켜두고 안 보고 넘긴 부분이 있는지 다시 체크해서 읽어보는 것을 추천한다. (나의 경우는 총 3개의 레이어를 사용했다. 1 레이어 - 번역본 + 용어 설명 + 키워드, 2 레이어 - 꼭 외워야 되는 내용, 3 레이어 - 샘플 문제에서 틀린 부분 정리해서 다시 키워드 정리)
시험은 정말 실라버스의 모든 내용에서 나오는 것 같다. 한 문장이라도 대충 보고 넘어간 그 부분에서 문제가 나온다. 나도 알고 싶지 않았다가 두 번째 시험 보고 나서 깨달았다.
 

6. 문배를 풀어보는 것을 추천한다. 문배의 문제도 문제지만 해설에서 도움을 꽤 받았다. (특히 4장 테스팅문제 푸는 부분) 실라버스를 어느 정도 공부를 했다면 문배를 풀어보자. 문배에서 내용이 너무 예전 것이라 헷갈릴 수 있지만 공부를 했다면 시험범위가 아닌 부분을 바로 캐치할 수 있다. 넘길 부분들은 넘기고 그 외의 부분들을 풀어보면서 해설과 실라버스 내용을 같이 읽어보는 것을 추천한다. 실라버스만 공부해서는 사실 쉽지 않은 것 같다.
 

7. 샘플 문제 안에서 틀린 문제들은 자신이 문제 안에서 나온 단어들을 제대로 이해하였는지 확인하는 것이 중요하다. 구글을 통해 이해가 안 된 단어들을 자세하게 알아보는 게 이해하는데 도움이 된다. + 답만 찾지 말고 답이 아닌 애들은 왜 틀렸는지, 뭘 설명하는지 적어두고 풀이할 때 맞게 썼는지 확인해 보면 1문제로 여러 공부를 할 수 있다. 이것도 강추.
 

사실 나는 정말 실라버스를 거의 다 외우고 갔다고 생각했는데 문제를 받고 머리가 새하얘졌다. 모두 시간도 적당히 봐서 넘길 문제는 넘기고 풀 수 있는 문제 먼저 푸는 것을 추천한다. 혹시나 시간을 들여서 이미 풀려고 했다면 아닌 답들이라도 확실하게 지워두고 넘어가자. 나중엔 시간이 촉박해서 다시 풀고 싶어도 못 푸는 상황이 올 수 있다. 그럴 땐 어쩔 수 없이 찍는다 하더라도 적어도 맞출 확률은 높여둬야 하니까!

모두 화이팅! 이제 취업의 문을 두드리러 가봐야지!

++ 그리고 지난번 시험이 끝나고 궁금했던 나가는 순서에 대한 의문점이 풀렸다. 감독관님께서 싸인을 해주시고 나가도 된다는 말을 해주신다. 시험이 완전히 끝나기 전에 끝마친다면 감독관님이 싸인을 해주시면서 이야기해 주신다. 나도 두 번째 시험에서는 나가도 된다는 허락을 받고 먼저 일어났다. 시험 시간이 완전히 끝나면 나가는 게 보류되는 것 같았다. 내가 나가려고 일어났을 때 다시 한번 다른 감독관님께서 오셔서 허락받았는지 확인하셨었다.

나는 꿈들을 많이 꾼다. 영화같이 긴 내용의 꿈들도 꾸기 때문에 꿈을 꾼 날에는 기분이 극명하게 갈린다.
흥미진진한 내용의 꿈들을 꾸면 꿈에서 깨기 싫어진다. 도망을 치거나 무언가 사건의 목격자가 된 꿈들에서는 깨고는 싶지만 결말까지 보고 싶은 아이러니한 기분을 느끼게 된다. 달콤한 상상의 꿈들에선 꾸고 난 후 나의 일상에 영향을 미칠 정도로 기분 좋은 스타트가 되지만 불쾌할 정도로 찝찝한 꿈들에서는 하루 종일 꿈에 대해 되새겨 보다가 그날 하루가 끝나기도 한다.
 
내 꿈에서는 시점들이 계속해서 변화된다. 지난번 어떤 꿈에서는 피해자, 가해자, 목격자의 모두의 시점을 볼 수 있었다.
역시나 오늘의 꿈에서도 나의 시점은 계속해서 변했다. 
 
오늘 꾼 꿈은 약 40분 정도의 짧은 시간 동안 꾼 꿈이었다. 꽤 오랫동안 기억에 남길래 적어본다.

 
< 꿈속의 시점 변화 > 
1. 의사들.
2. 실험체로 추정되는 두 분류로 나뉜 사람들.
3. 특이한 형태의 괴물들.
4.곳곳에 설치된 CCTV
 
< 꿈속에서의 등장인물 형태 >
1. 의사 - 공통 오브젝트 : 의사 가운. 가운 외에는 캐주얼하게 입거나, 와이셔츠를 입고 넥타이를 매고 있는 사람도 있었다.
2. 사람들 - 병원 환자 복을 입고 있기도 했고, 일반 복을 입고 있는 사람들도 있었다. 환자복이 70%, 일반복이 30%
3. 괴물 - 검은 봉지를 얼굴에 쓰고 있어서 눈이 보이지 않았다. 얼굴, 몸 전부 살이 있을 곳엔 검은 물감이 묻어 있다. 입고 있는 것도 밭에서 사용한 비닐 멀칭처럼 모래가 묻은 낡고 찢어진 검은 비닐이었다. 공사장 같은 데서 보이는 기다란 검은 비닐들로 온몸이 감아져 있었다.
4. 스프레이 - 우리가 흔히 알고 있는 세모난 삼각원뿔형태의 스프레이. 플라스틱으로 되어 있으며 투명한 것도 있고 뿌연 파란색도 있지만 내부의 액체는 보인다.
5. 주사기 - 얇은 주사기. 의사들은 주사기를 들고 있을 때 모두 흰색 손장갑을 꼈다.
 
< 환경 >
1. 밤이였다. 
2. 건물 위층에서 아래를 보면 나무들이 빼곡하게 많아 온통 검은 숲들로 둘러쌓져 있다. 
3. 달의 빛이 은은하게 건물을 비추고 있다.
4. 건물의 내부에 어느 벽들은 힘을 주면 슬라임처럼 벽 안으로 들어갈 수 있는 구조로 되어있다.
5. 건물 내부 : 통유리로 되어 있는 창문이 깨져있으며 꽤 오랫동안 방치되어 이끼가 끼어있는 층들이 있는가 하면 어제까지도 사용했던 것 같이 모든 오브젝트들이 깔끔하게 들어가 있는 층들도 있다. 
6. 의사들이 시체를 옮기고 있던 곳엔 화장터처럼 네모난 직육면체 공간이 길게 뚫려 있는 벽이 있었다.
7. 복도 곳곳에 나무로 만들어진 파티션들이 벽 쪽에 세워져 있었다.
8. 이불이 있는 방의 이불들과 위에 달려있는 스프링 클러는 이전에도 사용했던 것 같이 사용 흔적이 남아있었다.
9. 의사들이 연구하는 연구실에는 파란색 불이 희미하게 있고 중간중간 책상에 LED 조명이 켜져 있었다.
10. 형광물질이 사람의 몸에 닿을 때는 형광색 물감이 물풍선에서 터지듯 묻은 것처럼 보였다.  
 
커다란 건물 두개가 쌍둥이처럼 붙어있었으며 가운데 연결된 통로로 넘어갈 수 있게 생긴 구조였다. 통유리의 창문을 통해 반대쪽 건물에서의 움직임을 전체적으로 볼 수 있었다.
나는 실험체에 포함되는 인물 1이었는데, 시간 안에 살아남은 후, 다시 불특정한 쉬는 시간을 가지고 반복하는 형태였던 것 같다. 
 
내가 있는 쪽 건물에서는 눈이 안보이는 괴물들이 스프레이를 들고 뿌리면서 사람들을 찾고 있었다. 
스프레이 속에는 형광 물질이 들어있는지 사람한테 뿌리면 형광이 반응하였다. 벽이나 물건들에 뿌렸을 때는 형광이 발현되지 않았던 걸로 보아 아무래도 체온이라거나 사람에게만 있는 반응에 반응하는 것 같았다. 형광 물질이 몸에 묻은 사람들은 스프레이 뿌리는 괴물 뒤에 있던 괴물들에게 끌려갔다. 형광물질이 몸에 묻어 있어도 괴물들의 눈을 피해 도망을 친다면, 불이 꺼질 때까지 쉴 수 있는 이불이 있는 방에서 옷을 갈아입거나 묻은 옷을 벗고 피할 수도 있었다. 하지만 워낙 건물 내부의 빛들이 없었기 때문에 형광의 색들은 눈에 너무 잘 띄었다. 사람들 또한 그들과 같이 있는 것을 극도로 꺼렸다. 이유는 당연하게도 형광물질이 닿아 몸에 묻거나 같이 있다가 표적이 되어 스프레이에 맞을 확률이 커지기 때문이었다. 극한의 이기심들이 눈앞에서 일어났지만 딱히 서로를 도와줄 수 있는 방법은 없었다.
 
일정 시간동안 괴물들을 피해 스프레이를 맞지 않고 피하면서 건물에서 불이 켜져 있는 이불들이 펼쳐진 방으로 들어가면 불이 켜져 있을 때까지 잠시 동안은 쉴 수 있었다. 물론 불이 꺼지면 다시 도망쳐야 되는 상황이었다. 
건물 내부는 거의 모든 곳이 불이 꺼져 있기 때문에 불이 켜져 있는 공간은 반대쪽 건물에서 알 수 있었다. 그래서 우리는 팀을 나눠 반대쪽 건물과, 본 건물에서 서로에게 불빛이 있는 공간의 위치를 알려주었다.
 
도망치던 사이에 반대쪽 건물에서 의사들이 사람을 죽이고 유기를 하는 모습을 보았다. 
목이 잘린 시신의 목에는 붕대로 돌돌 말아져 있었다. 의사들이 시신의 팔다리를 들어 어딘가로 이동하던 중 도망치던 또 다른 사람들과 마주쳐서 시체를 바닥에 두고 그 사람들을 쫓아가는 모습을 보았다. 
거기 있던 의사들은 괴물들이 데려간 사람들을 데리고 임상 시험을 하고 있는 중이었던 것 같다.
 
반대쪽 건물에는 두 종류의 의사들이 있었다.
임상시험을 진행하는 의사와 몰래 형광 물질에 대한 백신을 만들고 있는 의사.
 
CCTV의 시점으로 보게 된 기억은 이렇다.
< 복도의 CCTV - 소리 녹음 X >
엘리베이터의 문안으로 숨어 들어가 숨죽이고 있던 사람들에게 의사들이 무언가를 이야기하면서 다급하게 접근했다. 이후 파란 물질이 들어가 있는 주사기를 그들의 팔에 주사하는 것을 보았다.
< 연구실의 CCTV - 소리 녹음 O >
의사들끼리도 의견이 다른지 주사를 맞겠다고 싸우는 의사들이 생겨났다. 어떤 의사는 자신한테도 주사를 놔달라며 옆의 의사의 멱살을 잡으면서 소리를 지르고 있었는데 뒤에 있던 다른 의사가 와서 파란색 약물이 들어있는 주사기로 주사를 놓는 척하다가 주황색의 약물이 들어있는 주사기로 바꿔 치기 해서 주사하는 것을 보았다.
어떤 영향을 받는 건지는 알아내지 못했지만 투약할 양이 인원수대로 있었던 것은 아니었던 것 같다. 
 
++
< 불이 켜져있는 이불이 펼쳐진 방 >
여기에는 이불들이 수련회에 갔을 때처럼 바닥 전체에 침구가 깔려있다. 침대가 있거나, 바닥에 이불이 깔려 있거나, 또 이불이 작거나 크거나, 침낭이거나 했는데, 방을 찾아 간신히 살아 들어온 후에도 내부에서 다시 자리를 차지하기 위해 싸웠어야 됐다. 어떤 사람들은 자신의 가족이 5명이라 5명의 자리를 맡아 둔 거라면서 이불을 움켜쥐는 사람이 있는 가 하면, 4명 정도의 인원이 들어갈 수 있는 대형 침대에서 혼자만 쓸 것이라면서 소리 지르는 아저씨도 볼 수 있었다. 문 앞에서는 사람들이 자리를 찾기 위해 이동을 했고, 문 바로 앞에 있는 이불들에서는 쟁탈전이 펼쳐지기도 했다. 아무래도 문 앞자리인 만큼 사람들 사이에서 뺏고 뺏는 싸움이 일어났었다. 그 사이에서도 어떤 사람들은 자신들의 자리옆에 사람 한 명 더 들어올 수 있다면서 자리를 뺏기고 돌아다니고 있는 사람들을 불러 데려가기도 했다.
 
< 이불이 켜져 있는 방의 규칙 >
1. 괴물들이 방 근처를 걸어갈 때 방의 불이 꺼지면서 방에 있는 모두가 이불속으로 들어가야 됐다.
2. 만약 누군가가 이불 밖을 나와있다면 천장에 있던 스프링클러가 작동하면서 형광물질이 비처럼 나오게 된다.
3. 그 사이 괴물들은 형광물질을 맞은 사람을 데려가고 형광물질을 피해 이불속에 있던 사람들은 괴물이 지나간 후 방에서 나와 다시 도망가야 됐다.
4. 스프링 쿨러가 작동된 방은 더 이상 불이 켜지지 않게 되며 괴물에게서 안전하지 않게 된다.
5. 만약 모두가 이불속에 있어서 스프링 클러가 작동되지 않았다면 불이 다시 켜지며 안전한 공간으로 남는다. 
 

결과를 못보고 꿈에서 깼기 때문에 그 후로 어떻게 됐는지는 모르겠지만 생각보다 꿈꾸고 난 후 시간이 꽤 지나고도 기억되기에 적어둔다.
지난번엔 파만 먹는 게스트 하우스에 가서 아침밥으로 익은 파를 통째로 썰어 먹고 있었던 게 오래 기억됐었는데 이번 꿈으로 갱신한 것 같다. 아, 참고로 다른 손님들은 파로 샌드위치를 해 먹거나, 파를 갈아 우유쉐이크를 해 먹거나, 파를 먹는 척하고 그릇에 두고 신문만 읽거나 하고 있었다.  

6.1 테스팅 지원 도구

6.2 테스트 자동화의 효과와 리스크

▶ 테스트 자동화가 가져올 수 있는 효과

• 반복적 수작업을 줄여 시간 절약.
• 일관성 및 재현성 향상으로 사람의 단순 실수 방지.
• 더욱 객관적인 평가 및 사람이 도출하기 너무 복잡한 측정치의 제공.
• 테스트 관리 및 테스트 보고에 필요한 테스팅 정보의 접근성 향상.
• 결함 조기 식별, 빠른 피드백, 출시 시간 단축을 가능하게 하는 테스트 실행 시간 단축.
• 테스터가 새로운, 그리고 더 심층적이며 효과적인 테스트를 설계할 시간 확보.

▶ 테스트 자동화 활용 시 잠재적 리스크

• 도구의 효과에 대한 비현실적인 기대.
• 도구 도입, 테스트 스크립트 유지 관리, 기존 수동 테스트 프로세스 변경에 필요한 시간, 비용, 노력에 대한 부정확한 추정.
• 수동 테스팅이 더 적합한 곳에 테스트 도구 사용.
• 도구에 지나치게 의존.
• 폐업, 도구 지원 중단, 다른 공급업체로 도구 매각, 열악한 지원 등의 문제가 생길 수 있는 도구 공급업체에 대한 종속성.
• 지원이 중단되거나 , 추가 개발을 통해 내부 컴포넌트를 빈번하게 업데이트해야 할 필요가 있을 수 있는 오픈 소스, 소프트웨어의 사용.
• 자동화 도구가 개발 플랫폼과 호환되지 않을 수 있음.
• 규제 요건이나 안전 표준을 준수하지 않는 부적합한 도구의 선택.

ISTQB 4.0 정리가 끝났다. 이제는 다시 처음부터 외우면서 문제를 풀어봐야겠다.

시험이 3주 남았으니까 잘 준비해 보면 지난번 시험보단 확실히 점수가 잘 나오지 않을까 싶은데.

정리를 하면서 느낀 점은 확실히 처음에 무조건적으로 외울 때보다 자세하게 이해를 할 수 있었던 것 같다.

역시 무작정 외우는 것보단 확실하지 않아도 이해를 어느 정도 했느냐가 더 중요한 것 같다.

문제로 푸는 소프트웨어 테스팅 책이 너무 기대가 된다. 드디어 나에게도 풀 수 있는 문제집이 있다니!! 다시 생각해도 잘 산 것 같다. 시간이 좀 많이, 아주 많이 많이 지났지만 그래도 풀 문제가 있다는 사실이 너무 좋다.

자 다시 해보자고!

들어가기 전 알아둬야 할 5.4 용어, 5.5 용어 설명

형상 관리 : 변경 사항을 체계적으로 추적, 통제한다는 것.

베이스 라인 : 기준, 기준치, 기준선. 각 형상항목들의 기술적 통제시점으로 개발 과정의 각 단계별 산출물을 검토, 평가, 조정, 처리 등의 모든 변화를 통제하는 시점의 기준.

지속적 통합 : 커밋되는 즉시 모든 변경 사항을 병합, 통합 및 테스트하는 자동화된 소프트웨어 개발 절차.
지속적 테스팅 : 소프트웨어 릴리스 후보와 관련된 비즈니스 리스크에 대한 피드백을 가능한 빨리 얻기 위해 조기에 테스트하고, 자주 테스트하고, 모든 곳에서 테스트하고, 자동화하는 프로세스포함하는 접근 방식.

결함 보고서 : == 인시던트 보고서. 결함의 발생, 유형, 상태에 대한 문서.

5.4 형상 관리
: 식별, 제어, 추적

테스팅에서 형상 관리는??
: 테스트 계획서, 테스트 전략서, 테스트 컨디션, 테스트 케이스, 테스트 스크립트, 테스트 결과, 테스트 로그, 테스트 보고서와 같은 작업 산출물을 형상 항목으로 식별, 제어, 추적하는 지침을 제공한다.

복잡한 형상 항목의 경우 형상 관리는 구성 항목, 항목 간 관계, 버전 등을 기록.
형상 항목이 테스팅용으로 승인되면 베이스라인이 되며, 공식적인 변경 제어 프로세스를 통해서만 수정할 수 있다.

형상 관리는 새 베이스라인을 만들 때 변경된 형상 항목에 대한 기록을 유지한다. 이전 베이스라인으로 되돌리면 이전 테스트 결과를 재현할 수 있게 된다.

테스팅을 적절히 지원하기 위해 형상 관리는 다음을 보장한다.

• 테스트 항목을 포함한 모든 형상 항목에는 고유한 식별지가 부여, 버전 관리, 변경사항 추적, 다른 형상 항목과 가지는 연관성 식별 ==> 테스트 프로세스 전체에 추적성 유지.
• 식별된 모든 문서와 소프트웨어 항목은 테스트 문서에서 명확히 참조됨.

▶ 지속적 통합, 지속적 전달, 지속적 배포, 그리고 관련된 테스팅은 일반적으로 자동화된 데브옵스 파이프라인으로 구현하며, 여기에 보통 자동화된 형상 관리가 포함돼 있다.

5.5 결함 관리

테스트의 주요 목적 중 하나가 결함 식별이므로 잘 확립된 결함 관리 프로세스가 필요하다.

이상 현상은 소프트웨어 개발수명주기 모든 단계에서 보고 될 수 있다.

결함 관리 프로세스에는 기본적으로 개별 이상 현상을 발견 부터 종료까지 처리하는 작업 흐름과 분류 규칙이 포함되어야 한다.
>> 이 작업 흐름은 보통, 보고된 이상 현상을 기록하고, 분석 및 분류하고, 수정하거나 유지하기로 하는 등의 적절한 대응책을 결정하고, 끝으로 결함 보고를 종료하는 활동으로 구성된다. 이 프로세스는 관련된 모든 이해관계자가 따라야 한다. 정적 테스팅에서 식별한 결함도 비슷한 방식으로 처리하는 것이 좋다.

날씨가 좋았던 어느 하루, 경희궁 근처 카페에 자리를 잡았다.
원래도 좋아했던 에스프레소를 유럽여행을 통해 더 좋아하게 된 나는 오늘도 이탈리아에서 마셨던 그 맛을 잊지 못해 주문해 보았다. 그리고 메뉴판 끝에 내가 좋아하는 샤케라또가 있는 것을 발견했다.
다들 샤케라또에 대해 알고 있는가? 어느 날 문득 처음 가본 카페에서 샤케라또를 발견했다. 이름이 참 특이하네 싶었던 나는 주저없이 주문했고 원래도 쓰고 단 걸 좋아하는 나로서는 기가 막힌 데스티니를 느낄 수 있었던 맛이었다. 에스프레소를 시럽과 함께 얼음과 미친 듯이 흔들어 마시는 음료를 도대체 누가 처음 만들어 먹었을까? 그 누가 되었든 내 입맛이었다. 하지만 생각보다 카페에 잘 없는 메뉴 중 하나이다. 그렇기에 메뉴판에서 만날 때는 기대감에 부풀어 주문하게 되는 음료 중 하나이다.
다행히도 나는 카페인에 놀라울 정도로 무디다. 하루에 커피를 5잔 마셔도 전혀 두근 거리지 않는다. 잠도 물론 잘 잔다. 그렇기에 부담 없이 다양한 커피를 맛보고 즐길 수 있다. 처음 에스프레소를 주문한 날 느꼈던 작디작은 나의 컵을 기억하며 두 번째로 여운을 즐길 샤케라또도 같이 주문했다.

커피가 나오길 기다리며 창가쪽에 여유롭게 자리를 잡았다. 창문 밖에 조경으로 돌들을 담처럼 쌓아 넣어둔 벽을 보고 있자니 날씨가 딱 이 정도 가을의 느낌이 날 때 친구랑 같이 간 카페에서 주문했던 후추 에스프레소가 생각났다. 성당을 전망으로 옥상에 있는 카페였는데 메뉴를 주문하러 간 데스크가 이런 돌들로 껴서 만들어져 있었다. 사실 그때를 기억하는 이유는 그때 주문했던 후추 에스프레소 때문이었다. 후추가 생각보다 에스프레소랑 어울리데?
후추 에스프레소를 생각하다 내가 언제부터 커피를 이렇게 좋아 했었나 기억을 되돌려 보았다. 아마도 대학생 때 처음 만났던 커피 장인이 내가 커피를 좋아할 수밖에 없게 만들었던 이유 중 하나였다. 나는 대학생이 되면서 드디어 커피를 당당하게 마실 수 있었다. 초등학생 때 엄마 옆에서 한 개씩 얻어먹었던 에이스 과자에 묻힌 맥심커피 맛. 나의 소중한 기억 중 하나이다. 우리 엄마는 커피는 커서 먹어야 된다고 했었다. 그리고 지금에나 카페들이 이렇게 많지 사실 내가 고등학생 때는 카페도 그렇게 많이 있지 않았었다. 있어도 핫초코를 먹었었지. 그렇기에 대학생 때부터 진정한 커피를 마시게 되었었는데 진정한 커피 맛에 눈뜬 날이 바로 친구들과 간 정동진 여행 때였다.

정동진역 옆에 있는 해돋이를 볼수 있는 카페에는 커피 장인이 살고 있다. 대학생 때 갔던 기억이라 지금은 없어졌을 수도 있겠지만 그곳에는 엄청난 장인이 바다와 함께 npc처럼 존재했다. 그 당시 밤 기차를 타고 정동진역에서 내리면 새벽이 지날 때까지 세 가지 선택지가 있었다.

1. 새벽이 지날 때 까지 깜깜한 새벽 공기를 맞으며 역에 있는 벤치에 앉아 있는다.
2. 기차가 정동진 역에 도착하자마자 역 앞에서 방을 빌려주기 위해 기다리고 계신 여러 어르신들 중 한 분의 집으로 가서 3만원을 내고 대실한다.
3. 걸어서 갈수 있는 위치의 24시간 하는 카페를 찾아간다.

우선 첫번째는 해보려다가 너무 무서워서 그만뒀다. 정동진을 찾아갈 때쯤엔 내 시간은 항상 겨울이었는데 추운 바람과 함께 노숙을 하기엔 그곳은 너무 깜깜했다. 두 번째, 친구들과 선택했던 인심 좋아 보이는 할머니네 집은 너무나도 더러웠다. 바닥이 끈적거리는 건 양말로 어떻게든 버텨보았지만 침대 위에 머리카락인지 알 수 없는 무언가의 털은 3만원을 깃털처럼 날려 버릴 수 있을 정도의 더러움이었다. 우리는 바닥에도 침대에도 못 앉아 있다가 해가 뜨자마자 벗어났다. 소중한 추억이며 값진 경험이었다. 세 번째로 선택했던 카페는 폭신한 기다란 의자가 가득 있었다. 커피 냄새가 가득했던 그곳은 우리 말고도 여러 사람들이 와서 따뜻한 커피를 시켜 마셨다. 그 새벽에 자리가 없을 정도였으니 우리만 몰랐던 히든 카페였던 것 일지도 모르겠다 생각할 때쯤 바리스타 자격증이 줄줄이 있는 한쪽 벽을 보았다. 장인이 살고 있었다. 외국어로 휘갈겨 뭔가를 증명하는 것 같이 생긴 자격증들이 한가득 있었다. 아저씨 장인이셨구나 싶은 마음으로 마셨던 커피는 어른이 된 지금까지도 아직 잊히지가 않는다. 여기저기 따뜻한 커피로 몸을 데우고 수면제를 먹은 것 같이 픽픽 쓰러져서 자는 모습을 보면 진짜 게임 속 여관느낌이었다. 해가 뜨기 시작하면 통유리였던 카페에서 일출을 볼 수 있었다. 주황색의 빛이 카페 가득 들어오던 그날의 따스함은 오랫동안 기억된다.

이런저런 생각을 하던 중 창문 밖으로 선선한 바람이 흘러 들어왔다. 어디선가 나타난 호랑나비가 내 옆에서 날아다녔다. 열린 창문은 못 찾고 닫힌 창문들에만 다가가 부딪히는 중이라 문을 열어줘야 되나 하고 고민하고 있을 때 나의 커피들이 나왔다.

나의 샤케라또. 그건 내가 생각했던 이미지가 아니였다. 내 거품 어디 갔어?
10월의 시작, 나의 설레는 마음은 샤케라또 거품처럼 사라져 갔다.

들어가기 전 알아둬야 할 5.3 용어 설명

마일스톤 : 프로젝트 진행 과정에서 특정할 만한 건이나 표를 말함. 프로젝트 계획에서 진척 상황을 나타내는 강력한 이정표.

메트릭 : 측정에 쓰이는 측정 척도와 방법.

번다운 차트 : 잔여 작업량과 잔여 시간을 세부적으로 비교해 애자일 팀이 기한까지 어떻게 작업하고 있는지를 시각적으로 나타냄. == 시간에 따라 남아있는 작업의 양을 보여주는 시각적 표현. (팀이 업무를 완료하는 데 충분한 시간이 있는지 효율적으로 계산하기 위해 사용. 일반적으로 짧은 반복 작업을 할 때 사용 된다.)

5.3 테스트 모니터링, 테스트 제어, 테스트 완료

테스트 모니터링 : 테스팅에 대한 정보 수집과 관련이 있다. 이 정보는 테스트 진행 상황을 판단하고 테스트 완료 조건 또는 완료 조건과 관련된 테스트 업무가 충족됐는지 측정하는 데 사용.

테스트 제어 : 테스트 모니터링에서 얻은 정보로 가장 효과적이고 효율적인 테스팅을 위한 제어 지침/지도/필요 수정 조치 등을 제공.
제어지침 ex.
1. 식별된 리스크가 발현될 경우 테스트 우선순위 재지정.
2. 재작업 이후 테스트 항목이 시작 조건 및 완료 조건을 충족하는지 재평가.
3. 테스트 환경 인도 지연에 대응하기 위한 테스트 일정 조정.
4. 필요한 지점과 시기에 신규 자원 추가.

테스트 완료 : 끝난 테스트 활동에서 데이터를 수집하여 경험, 테스트웨어, 기타 관련 정보를 수집하는 단계.
테스트 완료 활동은 어떤 프로젝트 마일스톤에 도달했을 때 이루어짐. 테스트 레벨이나 애자일 반복 주기의 끝, 테스트 프로젝트를 완료(또는 취소)한 시점, 소프트웨어를 배포했거나 유지보수 릴리스를 끝냈을 때 등이 여기에 해당.

5.3.1 테스팅에 사용하는 메트릭

테스트 메트릭 : 계획한 일정 및 예산 대비 현재 진행 상황, 테스트 대상의 현재 품질, 테스트 목적이나 반복 주기 목표 대비 테스트 활동의 효과를 보여주기 위해 수집한다.

테스트 모니터링은 테스트 제어 및 테스트 완료 활동을 지원하는 다양한 메트릭을 수집한다.

5.3.2 테스트 보고서의 목적, 내용, 대상

테스트 보고 : 테스팅 도중과 이후에 테스트 정보를 요약해 전달하는 활동.

테스트 진행 상황 보고서 : 테스팅의 지속적인 관리를 지원. 계획에서 벗어나거나 상황이 바뀌어 테스트 일정, 자원, 테스트 계획을 수정해야 할 경우 그것을 할 수 있는 충분한 정보를 제공해야 함.

테스트 완료 보고서 : 테스팅의 특정 단계(ex. 테스트 레벨, 테스트 주기, 반복 주기)를 요약하고, 후속 테스팅을 위한 정보를 제공할 수 있다.

>> 테스트 진행 상황 보고서는 테스트 모니터링, 제어 과정에서 작성을 하고 테스트 완료에서 가장 많이 활용함.

▶ 테스트 모니터링 및 제어 과정 중 테스트팀은 이해관계자에게 정보를 제공하기 위해 테스트 진행 상황 보고서를 작성한다. 일반적으로 테스트 진행 상황 보고서는 정기적으로 작성한다.

▶ 테스트 완료 보고서는 프로젝트, 테스트 레벨, 테스트 유형이 끝나고, 이상적으로는 완료 조건도 충족된 상황에서 이루어지는 테스트 완료 활동 중 작성한다. 이 보고서는 테스트 진행 상황 보고서와 기타 데이터를 기반으로 작성한다.

5.3.3 테스팅 상황 전달

테스트 상황을 전달하는 가장 좋은 의사소통 방법은 테스트 관리자의 관심, 조직의 테스트 전략, 규제 표준, 자체 조직 팀일 경우 팀 자체에 따라 달라진다.

들어가기 전 알아둬야 할 5.2 용어 설명
: 이해 ㄱㄱ

프로젝트 리스크 : 잠재적인 문제가 발생해 이로 인한 직접적인 효과가 프로젝트의 성공에 영향을 미칠 때, 그러한 잠재적인 문제들을 프로젝트 리스크라고 부름. ex> 프로젝트의 완성을 연기시킬 수 있는 인력 부족.
제품 리스크(== 품질 리스크) : 잠재적인 문제가 발생해 이로 인한 직접적인 효과가 제품의 품질에 영향을 미칠 때, 그러한 잠재적인 문제들을 제품리스크라고 부름. ex. 제품을 사용하는 일반적인 상황아래서 시스템 크래시를 일으키는 잠재적 신뢰성 결함.

++ < 리스크 대응 4가지 방법 >
- 리스크 수용 : (== 리스크 흡수) 반복적이고 피해가 크지 않은 리스크의 경우, 이 리스크에 대해 아무것도 하지 않고 피해를 받아들인다고 결정할 수 있는데 이것이 리스크 수용이다.
- 리스크 완화 : 리스크 빈도와 강도를 낮추기 위한 대응을 하는 것을 의미.
- 리스크 전가 : 리스크를 다른 제 3자에게 넘기는 것을 의미.
- 리스크 회피 : 리스크를 감당하는 것을 피하는 것. 발생하면 너무 피해가 클 것으로 예상되는 리스크의 경우 회피 대응을 할 수 있다. ex. 계약 협상 시 계약서 조항에 예외 조항을 넣거나 몇몇 조문을 거부함.

5.2 리스크 관리

리스크 관리란?
: 조직이 목표를 달성할 가능성과 제품의 품질을 높이고 이해관계자의 신뢰와 믿음을 얻을 수 있게 한다.

주요 리스크 관리 활동 2가지
리스크 분석	리스크 식별과 리스크 평가로 구성.
리스크 제어	리스크 완화와 리스크 모니터링으로 구성.

리스크 기반 테스팅이란? 
: 리스크 분석과 리스크 제어를 기반으로, 테스트 활동을 선택하고 우선순위를 정해 관리하는 테스트 접근법.

5.2.1 리스크의 정의와 리스크의 속성
: 리스크 발생 가능성과 리스크 영향도는 독립적이다.

리스크 : 발생시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황을 말한다.

< 리스크의 특징 두 가지 요소 >
1. 리스크 발생 가능성 - 리스크 발생 확률(0보다 크고 1보다 작음).
2. 리스크 영향(피해) - 발생했을 때 생기게 될 피해.
>> 이 두가지 요소로 리스크 수준을 표현한다.

▶ 리스크 수준 = 리스크를 측정한 값.
리스크 수준이 높을수록 그에 대한 조치 또한 중요해진다.

5.2.2 프로젝트 리스크와 제품 리스크

5.2.3 제품 리스크 분석

< 테스팅 관점에서 제품 리스크 분석의 목표 >
: 제품 리스크를 인식해 잔존 제품 리스크 수준을 최소화하는 방향으로 테스트 노력을 집중할 수 있도록 하는 것.
- 제품 리스크 분석은 소프트웨어 개발수명주기 초기에 시작하는 것이 이상적.

제품 리스크 분석은 리스크 식별과 리스크 평가로 이루어진다.

리스크 식별	포괄적인 리스크 목록을 생성하는 것. 이해관계자는 브레인스토밍, 워크숍, 인터뷰, 원인-결과 다이어그램 등 다양한 기법과 도구를 사용해 리스크를 식별.
리스크 평가	식별한 리스크를 분류하고, 리스크 발생 가능성/영향/수준을 결정하고, 우선순위를 정해 조치 방법을 제안하는 작업을 포함.

▶ 리스크 평가는 정량적 또는 정성적 접근법을 사용하거나, 두 가지를 혼합해 사용할 수 있다.

• 정량적 접근법 : 리스크 수준은 리스크 발생 가능성과 리스크 영향을 곱한 값으로 계산.
• 정성적 접근법 : 리스크 행렬을 사용해 리스크 수준을 판단.

▶ 제품 리스크 분석은 테스팅의 강도와 범위에 영향을 미칠 수 있다.

< 분석 결과 활용 방향 >

• 테스팅 수행 범위 결정.
• 테스트 레벨 결정 및 수행할 테스트 유형 제안.
• 사용할 테스트 기법과 달성할 커버러지 결정.
• 업무별 필요 테스트 노력 추정.
• 중요 결함을 가능한 빨리 식별하기 위한 테스트 우선순위지정.
• 리스크를 줄이기 위해 테스팅 외 다른 활동을 할 수 있는지 판단.

>> 평가된 리스크 수준은 테스팅을 얼마나 엄격하게 해야 하는지 판단하는 데 도움이 된다.(철저성과 범위에 영향)

5.2.4 제품 리스크 제어

제품 리스크 제어는 식별 및 평가된 제품 리스크에 대응해 취하는 모든 조치를 말한다.

제품 리스크 제어는 리스크 완화와 리스크 모니터링으로 이루어진다.

리스크 완화	리스크 평가 때 제안된 조치를 실행해 리스크 수준을 낮추는 활동.
리스크 모니터링	목적 : 리스크 완화 조치가 효과적인지 확인하고, 리스크 평가 개선을 위해 추가로 필요한 정보를 확인하고, 새롭게 나타난 리스크를 식별.

▶ 제품 리스크 제어 측면에서 리스크를 분석하면 거기에 대응하기 위한 다양한 완화 방안을 수립할 수 있다.

ex. 테스팅을 통한 리스크 완화, 리스크 수용, 리스크 전가, 대안 계획 등.

▶ 테스팅으로 제품 리스크 완화를 위해 취할 수 있는 조치

• 주어진 리스크 유형에 적절한 경험과 기술을 갖춘 테스터 선정.
• 적절한 수준의 테스팅 독립성 적용.
• 리뷰 및 정적 분석 수행.
• 적절한 테스트 기법 및 커버리지 수준 적용.
• 영향을 받는 품질 특성을 다루는 적절한 테스트 유형 적용.
• 리그레션 테스팅을 포함한 동적 테스팅 수행.