0. 개요

최근 취업 특강과, 채용 공고를 보다보니 shift-left testing이라는 말을 듣게 되었다.

보아하니 전략의 일종인 것 같은데, 무슨 전략일 지 찾아보았다.

1. shift left 정의

Shift left 전략은, 말 그대로 "왼쪽으로 이동"하는 것이다.

소프트웨어를 개발할 때, 책을 읽듯이 왼쪽에서 오른쪽으로 흘러간다고 가정해보면, 아래와 같은 순서로 개발된다.

전통적으로, QA라 하면은 테스트 단계에서 "기획자와 개발자가 다 만든 소프트웨어" 를 보고 테스트하는 것을 의미했었다.

여기서 Shift left testing 전략이라 하면, 기획, 개발 단계에서도 좋은 품질을 만들기 위한 전략이라고 볼 수 있다.

2. shift left testing 왜 함?

어차피 테스트 단계에서 테스트 할텐데, 왜 굳이 기획 단계와 개발 단계에서 테스트를 해야 할까?

그 이유는, "비용"과 밀접해 있다.

집을 짓는걸 예를 들자면,

1. "집을 설계대로 정확히 지었는데, 나중에 다 짓고 보니깐 설계도에 입구가 없네..?" (기획 오류)

2. "제대로 된 설계도를 가지고 지었는데, 다 짓고 보니깐 집이 살짝 휘었네..?" (개발 오류)

와 같은 예시를 들 수 있다.

다 짓고 나서 "이 설계도에는 입구가 없는데요?" 라고 하거나, "이렇게 지으면 집이 휘어요.." 라고 해봤자, 이미 비용은 비용대로 나간 후일 뿐이다.

소프트웨어도, 인력, 시간 등의 비용이 기획과 개발 단계에서 지출되는 만큼 이러한 비용을 낮추기 위해 shift left testing 전략을 한다고 볼 수 있다.

3. 개발 단계에서의 shift left testing

개발 단계에서 품질을 높이는 방법은 뭐가 있을까?

단순히 생각하면, QA가 화이트박스 테스트를 해야하는거라고도 생각할 수도 있다.

하지만, 그보다는 "개발 중간중간에 품질 검토를 끼워넣는 방식"이라고 할 수 있다.

개발자 입장에서는, 유닛 테스트, 코드 리뷰, TDD와 같은 방법으로 품질을 높일 수 있을 것이고,

QA의 입장에서는 기능이 추가되었을 때 테스트를 함으로써 신속한 피드백을 제시할 수 있을 것이다.

코드의 깊이를 알고있는 QA라면, 유닛 테스트, 코드 리뷰 등의 방법 또한 참여할 수 있을 것 같다!

이 부분에서, CI (Continuous Intergration) 자동화가 되어있는 회사라면

빌드 이후 테스트 단계를 자동화하는 방법으로 코드 추가에 대한 민첩한 대응을 하여 개발을 지원하는 방법이 있다.

개발자의 입장에서, 기능 하나를 올리는 순간 자동으로 테스트가 되고 기능에 대한 테스트 결과를 알려준다면 정말 땡큐일듯!

물론, 자동화가 무조건 정답은 아니다. 품질을 높이기 위한 효율적인 방법으로 "자동화"를 쓰는것이라는 것을 명심해야 한다!

4. 기획 단계에서의 shift left testing

개발 단계에서 품질을 높이는 방법에 대해 충분히 고민해 봤다면,

기획 단계에서 품질을 높이는 방법은 뭐가 있을까?

이전 경험을 기억하자면, 기획된 기능이 구현이 된 후 기획자와 미팅을 가지고, 기획자가 기능에 대한 설명을 하는 시간을 가졌다.

즉, "기획 + 개발"이 완료된 기능에 대해 테스트할 때 참고하라고 기능에 대한 설명을 하는 것이었다.

기획서로 기능이 구현되기 전에는, 기획서를 볼 기회가 없었다. (물론 짬이 낮아서 일수도..?)

여기서 shift left를 도입한다면, 기획서가 만들어지고 개발단계에 들어서기 전에, 초기 단계 기획부터 QA를 포함해 검토를 하는 문화를 가져야 할 듯 하다.

물론 기획자들이 바보도 아니고 꼼꼼히 기획을 해서 기획서를 만들터이니, 딱 봤을 때 문제가 쉽게 나오진 않을 것이다.

하지만 밥값을 하려면! 꼼꼼히 만들어진 기획서 내 논리적 허점을 찾아내는 탐정이 되어야 한다!

5. shift left testing 의 장점

1. 비용 절감

2번문항에서 나왔듯, 다 지은 집을 허물고 짓는것보다 처음부터 잘 설계하면 비용을 아낄 수 있다.

2. 품질 향상

가끔은, 적당히 잘못된 기획안 / 개발 산출물에 대해서는 "그냥 안고 가자"는 식으로 퉁치곤 한다..!

출시가 임박했다든지, 다 뜯어 고치는 비용이 너무 크다든지의 이유로 문제가 있는 상태에서 배포하고, 이후 수정을 하곤 한다.

하지만, shift left를 한다면, 위와 같은 상황을 최대한 예방할 수 있다.

6. shift left testing 은 문화다.

나는, shift-left testing이라고 하길래, testing=QA, 즉 QA가 알아둬야할 내용인가 했다.

하지만, 이는 팀 전체에 갖춰야 할 문화에 가깝다고 생각한다.

물론, 품질을 담당하는 사람이기 때문에, 이러한 문화를 정착시키기 위해 노력을 하는 사람이 QA라고 생각한다.

출처 : 

Line

https://engineering.linecorp.com/ko/blog/quality-advocator-shift-left-shift-right

IBM

https://www.ibm.com/think/topics/shift-left-testing

0. 개요

제주도 여행을 가게 되면서, 기대가 컸던 장소 중 하나였던 곳은 넥슨 컴퓨터 박물관이다.
윗 사진처럼 수학여행 타이밍과 겹쳐서.. 고등학생들의 땀내 섞인 전시 관람이었으나 그래도 볼게 참 많았다!
결론부터 이야기하자면, IT에 관심이 있다면 한번쯤은 들려봐라 추천하고 싶습니다!
넥슨 컴퓨터 박물관은 지하 1층부터 3층까지, 총 네개의 층 별로 관람하거나 즐길게 있었다.
다만 사람이 너무 많아서 사진 찍기 애매해 다른 글의 사진을 참고해서 작성하려고 한다..

1. 컴퓨터의 역사

1층에는, 마우스, 키보드, 메모리, 그래픽카드와 같은 컴퓨터 구성품들에 대한 과거, 현재, 미래가 있었다.
역시 고등학생들의 흥미를 이끌기에는 무리가 있었는지, 다른 층에 비해 한적한 관람을 할 수 있었다.
가장 인상깊었던건 아래의 엥겔바트 마우스라는 발명품이다.

내가 썼던 마우스인 볼마우스나 광마우스가 아닌, 바퀴를 굴려 마우스를 움직이는 메커니즘이다.
최초에는 "X-Y 좌표 표시기" 라는 이름을 가지고 있었으나 누군가 생쥐같이 생겼다는 말로 인해 지금의 "마우스"가 되었다.
최근 프로젝트에서 CLI 환경만으로 리눅스를 다루는 과정이 너무나도 험난했었고, "보면서 클릭좀 하고싶다.."는 생각이 정말 간절했었다.
아버지도 첫 컴퓨터는 CLI였던 DOS를 썼었다고 한다. (라떼는!)
지금은 너무나도 당연하게 마우스를 활용해 컴퓨터를 자유자재로 쓰는데, 정말로 하나하나 너무 소중한 발명품이다!
이동식 저장장치의 역사도 정말 흥미로웠다.

처음에는 펀치 카드로 120byte만을 저장했었다가, 점점 늘어나더니 마지막에는 지금 우리가 쓰는 HDD, SSD가 있었다.
다나와와 같은 곳에서 일반 PC용으로 4TB짜리 SSD를 파는걸 감안하면, 체감상으로는 무려 366.5억배의 메모리 혁신이 있었다!!

2. 게임의 역사

2층에는 가장 설레는, 게임의 과거와 현재, 미래가 있었다.
정말 많은 게임들이 있었고, 직접 체험을 할 수 있었다..만!
수 많은 고등학생들이 자리잡고 게임을 하고 있어서 멀찍이 구경만 할 수 밖에 없었다..
그래도 게임을 직접 플레이하지 않고 구경하는 것도 재미있는 일이어서, 조금은 색다른 관람을 했다!

이런식으로, 고전게임이 입장할 때 많이 널려있었다. 갤로그, 스페이스 인베이더 등등..
라떼는 저런게임 너무 재밌게 했었는데, 지금 내가 하려고 하니 뭔가 손이 안간다... 이미 더 큰 도파민의 게임에 절여져서 그런듯
인상깊었던 건, 역시 모션인식으로 저스트댄스를 즐기고 있던 고등학생 무리들이었다.

얼마 전 닌텐도 처분하면서 가지고있었던 저스트댄스 칩도 당근🥕했었는데, ㅋㅋㅋ역시나 어린 친구들이 사갔다!
어린 나이에 즐기기 딱 좋은 게임인가봐..
개인적으로 아타리쇼크의 주인공 E.T 게임이 혹시나 있을까 했었는데, 못찾은건지 없는건지 모르겠지만 없었다.
(사람이 너무 많아서 열심히 찾진 않음)
뭔가 게임 역사에 큰 비중인지라 있을수도 있지 않을까 했었는데, 아쉬웠다.

3. 히든 스테이지, 오픈수장고

3층에는, 조금 1층과 주제가 비슷한게 있었다. 마우스, 키보드의 역사!
이런건 과감히 Skip 했다.
한 구석에는 타자연습 프로그램이 있었다. 해보니까 500타가 나와서 조금 자랑도 할 겸 띄워놓고~ ^ㅇ^
코딩 체험도 있었다.
스크래치(https://scratch.mit.edu/)와 유사한 방식으로 꼬꼬마 난이도의 코딩 문제들이 있었고, 만약 아이가 있었으면 뇌 말랑말랑해지게 해줄 수 있지 않았을까 싶었던 유익한 장소였다.
오스모,오조봇이라는 코딩 교구도 있었고, 피쳐폰들도 전시되어 있었던걸로 기억한다!
솔직하게 내가 크게 체험해 볼만한 것은 없었다.
Lab 1.0의 주제는 마음에 든다.

익숙한 것에 의문을 갖고 낯설게 바라보는 것으로부터 변화는 시작된다

익숙함은 안정감을 주고, 오랜 시간 쌓아온 노하우는 귀한 자산이다.
하지만 문제는, 그 자산에 너무 안주하게 되는 순간이다.
변화는 대단한 용기에서 시작되는 게 아니라, 아주 작은 ‘왜?’에서 시작된다.
“왜 이건 이렇게 해야 하지?”
“이 방식 말고 다른 길은 없을까?”
그 질문 하나가 생각의 물꼬를 트고, 전혀 다른 길로 이어지기도 한다.
아직 주니어인 입장에서는 생각할 주제는 아니겠지만, 언젠가 나도 어떤 분야이든 시니어가 되었을 때 도움이 될 말이다!

4. 굿즈카페 느낌의 지하 1층

3층까지 관람을 마치고, 지하로 내려가면 온 세상이 메이플스토리다!
크게 제주도와 콜라보한 테마로 가득했다.

위 이미지처럼!
메이플스토리 IP 좋아하는 나는 지갑이 한번 열렸으나, 돌아갈 캐리어에 공간이 없어서 눈물을 머금고.. PASS..
근데 진짜 귀여운거 많으니까 메이플 IP 좋아하면 눈이 돌아갈 것이다 ㅎ_ㅎ
 

5. 마무리

넥슨 컴퓨터 박물관은 게임이나 컴퓨터 산업쪽으로 관심이 없는 사람이라면 그다지 추천하지는 않는다.
하지만 반대로 말하자면, 좋아한다면, 혼자 가도 즐거울거고, 넥슨 게임을 좋아하는 지인과 함께 가도 즐거울 것 같다.
지하 1층을 보면, 메이플스토리를 좋아하는 지인을 데리고 가면 최고의 코스로 기억되지 않을까!
하지만, 수학여행 시즌의 평일에는 조금 알아보고 가는것이 현명하다......정말로..

0. 개요

프로젝트에서, Jenkins와 Frontend, Backend, DB를 도커로 실행시켰었다.
하지만, 문제가 발생했다.
바로, 도커 컨테이너 끼리는 소통을 기본적으론 못한다는 것.

1. 기본 환경

"도커 컨테이너 끼리의 소통" 을 설명하기 위해, 아래처럼 두개의 컨테이너를 만들었다.

C:\Users\A> docker run -d -p 8080:8080 -p 50000:50000 jenkins/jenkins
054232dce4aad83b1fb0e5d26eeae666582edaa66c17910c2bb01372e59b1e8e
C:\Users\A> docker run -d -p 80:80 nginx
f02cf55a548ff1dfbcea0a539a72f73c07f7e5a9acabfe3909d06e0532047cb8
C:\Users\A>docker ps -a
CONTAINER ID   IMAGE             COMMAND                  CREATED                  STATUS         PORTS                                              NAMES
f02cf55a548f   nginx             "/docker-entrypoint.…"   Less than a second ago   Up 9 seconds   0.0.0.0:80->80/tcp                                 vigorous_bose
054232dce4aa   jenkins/jenkins   "/usr/bin/tini -- /u…"   About a minute ago       Up 2 minutes   0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp   naughty_knuthC

그럼 여기서, 만약
젠킨스 컨테이너가 nginx 컨테이너에 접근하려면 어떻게 해야할까?

2. 로컬에서 시도

우선, 도커가 아닌, cmd에서 nginx를 대상으로 curl을 날렸을 때 다음과 같이 결과가 출력된다.
curl이란, URL을 통해 웹 요청을 보내고 응답을 확인할 수 있는 명령줄 도구다!

C:\Users\A>curl 127.0.0.1:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
~~ 기타 내용 ~~
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

로컬과 도커는 서로 127.0.0.1을 통해 소통이 가능하다!
는 결론을 얻을 수 있다.

3. 젠킨스에서 시도

이제, 주제 내용인
"젠킨스 컨테이너"에서 "nginx 컨테이너"로 소통을 시도해보자.

C:\Users\A>docker exec -it -u root 05 bash
root@054232dce4aa:/# curl 127.0.0.1:80
curl: (7) Failed to connect to 127.0.0.1 port 80 after 0 ms: Couldn't connect to server

명령어를 해석해보자면,
docker 05 컨테이너(젠킨스)를 root 권한으로 들어가서,
curl 127.0.0.1:80을 날려보았다.
즉 이걸 그림으로 그려보자면,

이런 식이다.
분명 내 컴퓨터(호스트 컴퓨터)에서는 localhost:80으로 연결이 되는데,
어째서 젠킨스에서 nginx, 즉 컨테이너끼리는 연결이 안되는 걸까?

4. 해결 방법

컨테이너는 컨테이너끼리 소통하기 위해, 아래 스킬을 써야한다.

1. 도커 네트워크를 만들고
2. 그 네트워크에 가입시키고
3. 컨테이너명 또는 할당된 ip로 호출해야한다.
   말로해서는 어려우니, 아래 realworld 프로젝트 당시 썼던 docker-compose 파일을 보면서 이해하면 쉬울 것 같다.
   

   networks:            #(1. 네트워크 만들기!)
     realworld-network:
       external: false
       driver: bridge
       ipam:
         config:
           - subnet: 172.25.0.0/16
             gateway: 172.25.0.1
   services:
     realworld_db:
   	#"""설정들"""
       networks:            #(2. 네트워크에 가입시키기!)
         realworld-network:
           ipv4_address: 172.25.0.10
   
     realworld_backend:
       build: ./backend
   	#"""설정들"""
       networks:            #(2. 네트워크에 가입시키기!)
         realworld-network:
           ipv4_address: 172.25.0.20
   
     realworld_frontend:
   	#"""설정들"""
       networks:            #(2. 네트워크에 가입시키기!)
         realworld-network:
           ipv4_address: 172.25.0.30

1. 이런 식으로,realworld-network라는 네트워크를 만들고,
2. 그 네트워크에 가입시키고,
3. 컨테이너명 또는 할당된 아이피로 호출해야한다.
이 중, 컨테이너명을 종종 헷갈리곤 해서 IP를 할당하고 이를 호출하는 방식으로 도커 네트워크 내부 연결을 성공시킨 경험이 있다.

위 이미지처럼, 172.25.0.x 으로 네트워크로 묶어 연결을 성공했다.

5. 연결 해보기

그럼, 주제였던 젠킨스와 nginx 연결에 대입해보자.
이를 위해 sample이라는 이름으로 네트워크를 만들었다.

C:\Users\A>docker network create --subnet=172.25.0.0/16 --gateway=172.25.0.1 sample
0835b83943be2d58f77e17f80970dac57bc247e6408f86c3e798bf81774e36e7
C:\Users\A>docker network inspect sample
[
    {
        "Name": "sample",
        #내용 생략
            "Config": [
                {
                    "Subnet": "172.25.0.0/16",
                    "Gateway": "172.25.0.1"
                }
            ]
        },

    }
]

명령어를 간단히 설명하자면, sample이라는 네트워크를 만들고 inspect를 통해 네트워크 정보를 본다.
유심히 봐야할 건, 172.25.0.x 이다.
아까 네트워크도 그랬듯, 마지막 숫자를 바꿔가며 사설 IP를 할당할 수 있다.
이제,

C:\Users\A>docker run -d --name jenkins --net sample --ip 172.25.0.10 -p 8080:8080 -p 50000:50000 jenkins/jenkins
083b022e148568171500f627408b381ed694c8a9f414a8d18536239ccf89a473
C:\Users\A>docker run -d --name nginx --net sample --ip 172.25.0.20 -p 80:80 nginx
231509c08197e9df734c53b81e78429b2995151c25afd496039d582b47106623

젠킨스와 nginx를 다시 sample 네트워크의 ip에 할당해서 실행했다.
이후,

C:\Users\A>docker exec -it -u root 08 bash
root@083b022e1485:/# curl 172.25.0.20:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
~~ 기타 내용 ~~
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

이렇게 curl을 사설 IP인 172.25.0.20으로 던졌을 때 응답이 오는 것을 확인할 수 있다.

root@083b022e1485:/# curl nginx:80

물론, 172.25.0.20 대신 nginx라는 컨테이너 이름을 명시해도 좋다. 더 깔끔하기 때문에 선호되는 방식이라고 한다.

6. 마무리

이 사실을 알고 모르는건 천지차이였다.

위에 언급된 realworld 프로젝트 당시, 컨테이너 간 연결이 되지 않아 문제 해결을 위해 엉뚱한 원인 추정으로 무려 3일이라는 긴 시간을 썼다.

GPT는 당연히 내가 이러한 사실을 간과했다는 것 조차 몰랐기에 함께 삽질을 대차게 해버렸다!

하지만 3일이나 삽질을 한 결과, 도커를 자유자재로 다룰 수 있는 초능력자가 되어버렸다 ^ㅇ^

어떻게 보면 3일이나 걸릴 문제는 아니라고 생각도 하는데, gui가 아닌 cli만으로는 문제 추정이 어렵다는걸 느꼈다..

📌 이 글은 엘리스트랙의 지원을 받아 작성되었습니다.

1. 수강 전 나의 상태

산업경영 공학과를 졸업하고 첫 회사인 아웃소싱 업체에서, 모바일 디바이스의 테스터로 소프트웨어 QA 업계에 진입했다.

비전공자였던 내가 들어갈 수 있었던 만큼, 어떠한 기술적인 지식이 필요한 건 아니었고, 중요한건 "사수가 알려주는거 잘 듣고 잘 따라하기" 였다.

일은 단순했다.

1. 고객에게 TC를 받으면

2. TC를 수행하고

3. 결과를 고객사에게 알려주기.

일에 익숙해지면서, 여유시간에 고객사가 만든 자동화 툴 둘러볼 시간이 생겼다.

당연히 비전공자인 나에게 소프트웨어적인 지식은 부족했고, 수개월에 걸쳐 30분짜리 업무를 자동화하는 툴을 만들어냈다.

수개월에 걸쳐 실패하고, 만드는 과정에서 점점 재미를 느끼게 되었다.

그때 당시 한창 부트캠프 열풍이 돌았던 때였고, 혹시 소프트웨어 QA 자동화 관련된 부트캠프도 있지 않을까? 라는 생각에 찾아봤으나... 그런건 없었다..

QA 부트캠프는 커녕 QA에 관련된 지식 공유 관련된 커뮤니티도 적었고, 나와 같이 "스트릿 출신" 비전공자 QA는 그냥 부딪히고 실패하면서 배우는게 최선이었다. 그때는 Chat GPT와 같은 조력자도 없었기도 하고..

2. '엘리스트랙' 커리큘럼 & 학습 방식

2-1. 전체적인 커리큘럼 요약

• 기간 : 4개월 과정 (660시간)
  이론 주간 매일 아침 10시부터 18시까지
  실습(프로젝트) 주간 매일 아침 10시부터 23시까지
• 가장 좋았던 파트
  프로젝트 주간. 하루에 10시부터 23시까지 굉장히 긴 시간동안 프로젝트를 진행한다!
  하지만, 그만큼 성장이 가장 가파랐던 구간이기도 하다.
• 실무 프로젝트 진행 여부
  처음엔 "회사도 9 to 6를 하는 마당에, 13시간을 달린다고?" 라고 생각했었으나, 프로젝트가 너무 재미있었던 나머지 13시간이 지나가는줄도 몰랐다.
  생각이 비슷한 사람들을 모아두고, 하루 13시간 같은 주제로 머리를 싸매는 과정이 굉장히 몰입된다.
  내 생각과 다르면, 왜 다를까? 생각하게 된다.
  때로는 내 의견을 설득시키기도 한다.
  어쩔때는 내 의견이 틀리기도 한다.
  가끔은 내가 맞아서 뿌듯해진다!
  

  

  이렇게 치고받다보면 하루가 끝났을 때 뇌가 말랑말랑해져 있다.
• 팀 프로젝트 방식
  팀은 기존 이론 수업 간 퀴즈와 테스트 결과, 수업 몰입도, 온/오프라인 여부에 따라 나눈다.
  1차때는 온라인을 희망했던 이유로 온라인 프로젝트를 진행했고, 2차때는 오프라인을 희망해 오프라인 프로젝트를 진행했다.
  결과부터 말하자면, 당연한 소리겠지만, 더 많이 배우고 싶다면 오프라인을 강추한다!
  오프라인이면 더욱 자잘한 커뮤니케이션이 가능해지고, 더 많은 의견을 들을 기회가 생긴다.

2-2. 수업 방식

• 이론 VS 실습 비율
  프로젝트 주간은 총 20일이 잡혀있고, 그 외 모두 이론주간이다.
• 과제나 프로젝트 난이도
  이론 주간은 말 그대로 QA에 관련된 기초 지식부터, 파이썬, 자동화 라이브러리, 툴 등을 배운다.
  수강 전 실패하면서 배운게 있었던 덕분인지, 초반 몇주까지는 난이도가 평이했다.
  하지만 스터디나 프로젝트에서 마주친 수업 동기들의 말에 따르면 정말 템포가 빨랐다고 한다!
  물론 그렇다고 해서 아주 못할 정도는 아니었는지 열정 있는 사람들은 잘 따라올 수 있었다.
• 코치님 리뷰, 멘토링 방식
  이론 주간을 가르친 코치님은, 백엔드 개발자 출신이셨다.
  그래서, 한번은 내가 게임 회사에서 경험했던 애로사항에 대해 해결 가이드를 준 적도 있었다.
  

  

  위 이미지는, 대충 요약하자면
  1. xml로 저장된 값을 일목요연하게 정리하고싶다.
  2. 그걸 좀 쉽게하는 방법이 있는가?
  라는 질문을 던졌는데, 자세하게 알려주셨다.
  그때 당시의 파일이 없어 코치님의 솔루션을 시행해볼 수는 없겠지만, 어느정도 길라잡이를 얻을 수 있었다!
  아마 다른 동료들도, 이런 질문을 던지고 배울 기회가 있었을 것이다.
  //
  또한, 프로젝트 주간에는 "오피스 아워"라는 시간이 있었는데, 1시간 가량 코치님과 프로젝트 내외적인 질문을 던질 수 있었다.
  프로젝트 초반과 후반에는, 많은 프로젝트 관련 질문이 생기곤 한다. 또한, 현업자인 만큼 프로젝트가 아닌 다른 질문들도 던질 수 있었는데, 굉장히! 큰 도움되는 말을 들을 수 있었다!

3. 장점 & 만족했던 부분

3-1. 자신감

2년의 시간동안, 내가 독학한 내용에 대한 확신을 가질 수 없었다.

독학이다보니, 이게 정말 실무에서 쓰이는 지식일까? 와 같은 의심이 가득했다.
아무리 구글링하고, gpt와 씨름을 해도 내가 정도를 걷고 있는지를 알 수 없었다.

하지만 이 수업을 들으면서, 적어도 틀린 길을 가고 있지 않는다는 걸 알게 되었다.

수업을 듣기 전까지는 "자동화 비슷한 거 조금 해봤습니다." 라고 말을 한다면,

이 수업을 듣고 나서는 "자동화 좀 해보긴 했습니다." 정도로 말 할 수 있을 것 같다!

3-2. 시행착오

또한, 실무 느낌의 프로젝트가 두번이나 진행되는 것 또한 크나큰 장점이다.

이론수업만으로는 분명 실무에서 마주칠 문제상황을 배울 수 없겠지만, 프로젝트를 직접 진행하면서 거기서 시행착오를 겪는 과정을 통해 성장할 수 있었다.

4. 결과 & 성장 변화

4-1. 해당 분야의 이해

프로젝트 코치님께서, 이런 말을 했었다.

"결국은 다 도토리 키재기에요"

뼈 아플 수도 있지만, 진짜 맞는 말이라고 생각한다.

아무리 2년의 경력이 있고, 혼자서 또는 부트캠프를 통해 공부를 해봤더라도 아직도 배울게 산더미같다.

하지만, "배울게 산더미같다"는 사실을 알게 되었다는 것이 가치라고 생각한다!

SQA 분야에 대한 이해가 높아졌다 뿐 아니라, IT 업계에서 잘 살아남는 법에 대한 이해도 또한 높아진 것 같다.

4-2. 결과물

아직 포트폴리오나 이력서 작성은 하지는 않았다. 이제 시작했으니깐!

과정이 너무 즐거웠고, 그래서인지 결과물인 포트폴리오나 이력서에는 너무나도 자신이 있다.

만약 이후 취업을 못한다면, 내가 결과물을 이쁘게 포장하지 못한 죄 정도???

4-3. 엘리스트랙을 추천하고 싶은 사람

수업을 마치고 드는 생각은, 수업의 내용보다 더 가치있는 내용을 배울 수 있었다.

기업은 단순히 jmeter, selenium, pytest, postman을 잘 쓰는 기계를 원하는게 아닌, 배울 의지가 있는 사람을 원한다고 한다.

엘리스 이전에 있었던 3개월 교육형 인턴십에서, 나를 비롯한 인턴 동기 모두 소프트웨어 관련 지식이 풍부한 사람은 아니었다.

하지만 모두, 본인의 자아를 내려놓고 배울 준비가 된 사람들이었다.

만약 본인의 ego가 너무 강력하다면, 엘리스트랙 뿐만 아니라 어떤 부트캠프를 듣더라도 쪽박일 뿐이다.

따라서, 배울 준비만 되어있다면 누구든지 추천하고 싶다.

그렇게까지 열심히 할 필요는 없었다. 그렇게 치열하지도 않았다. 그냥 즐겁게 하다보면 좋은 결과가 쫓아왔다.

5. 커넥팅데이

수료식날, 커넥팅데이를 끼워놓았다.

현직자 두명이 와서 취업 특강을, 그리고 엘리스 채용담당자와 커피챗을 했는데, 상상 이상의 소득을 얻었다.

5-1. 17년차 베테랑

소만사라는 보안 관련 회사에서 17년을 일 한, 베테랑 중 베테랑 현업자분이 강사로 나왔다.

인상깊었던 내용은, QA가 품질 "ASSURANCE" 아닌, 품질 "ASSISTANCE"로 가야한다는 내용이었다.

단순히 SDLC에서 테스트 단계에서만 머물 것이 아닌, 기획, 개발 단계에서도 품질을 담당하는 SHIFT LEFT,

배포, 보수 단계에서도 품질을 담당하는 SHIFT RIGHT 에 대한 내용을 맛보기로 한모금 할 수 있었다.

5-2. 엔테크, 카카오, 그리고 아드리엘

두번째는 일부러 대비를 주기라도 한 듯 다양한 회사 경험이 있는 현업자분이 다음 강사로 나왔다.

기억에 남았던 내용은 역시 현실적인 내용인, 재무제표 GPT에 넣어보기다!!!

어쩌면.. 기업을 알아봐야 하는 입장인 나에게 정말 큰 도움이 될 것 같았다.

5-3. 엘리스 커피 챗

주로 이력서 어떻게 써야하는가, 그리고 채용 공고에 나와있는걸 어떻게 해석해야하는가에 대한 이야기를 나눴다.

사실 개인적인 질문만 가득했기에, 별도로 담을 내용은 없지만 꽁꽁 숨겨져있던 인사담당자에 대한 정보를 캐내는 소중한 시간이었다..!!

6. 마치며

분명 시작할때 겨울 꽃인 포인세티아를 구매했는데, 어느새 방에는 에어컨을 켤 날씨가 찾아왔다.

4개월의 시간은 너무나도 짧았다.

너무나도 당연했던 아침 수업 알람이 없으니 허전하기도 했다.

이 수업을 총평하자면, "할 수 있을까?" 에서 "할 수 있다!" 로 바뀌는 수업이었다.

독학으로는 배울 수 없는 장점이 존재하니, QA의 자동화에 빠진 사람들은 이 수업을 한번쯤 찾아보는걸 추천한다!

링크

(https://elice.training/)

0. 개요 : Airtest란?

1. AirtestIDE는 중국의 넷이즈 게임즈 만든 테스트 자동화 툴
2. 파이썬 언어를 기반으로 제작
3. Airtest는 이미지 캡쳐를 이용하여 테스트를 자동화하는 툴

https://koreascience.kr/article/CFKO202125036551390.page

즉, 이미지를 캡쳐해 원하는 요소를 검증 해주는 파이썬 언어 기반 자동화 툴이다.

1. 기존 게임 테스트의 문제

 아래 게임은 Pikmin Bloom으로, Unity 기반으로 만들어진 게임을 Appium inspector로 켜 본 결과다.

이미지에서 보다시피, 요소가 전혀 잡히지 않는다.

보통의 앱이라면, 아래와 같이 요소가 나와야 한다.

대다수의 게임이 이런진 모르겠으나, Unity 게임은 이런식으로 화면에서 요소(Element)를 찾을 수 없다.

따라서, 요소를 기반으로 클릭하는 Selenium스러운 방식을 사용하기 어려운 부분이 있다.

그렇다면 게임 자동화는 어떤 식으로 할 수 있을까?

2. 이미지 매칭

Opencv2에서, matchTemplate 함수가 있다.

import cv2

original_img = cv2.imread("original.png") # 원본 이미지
template_img = cv2.imread("template.png") # 원본에서 잘라낸, 찾고자 하는 템플릿 이미지
res = cv2.matchTemplate(original_img, template_img, cv2.TM_CCOEFF_NORMED) # 템플릿 이미지 찾기
min_val, max_val, min_loc, max_loc = cv2.minMaxLoc(res)
'''
min_val = 템플릿과 가장 일치하지 않은 곳의 점수 (필요 없음, 값은 0~1)
max_val = 템플릿과 가장 일치한 곳의 점수 (필요함, 값은 0~1)
min_loc = 가장 일치하지 않은 곳의 좌표 (필요 없음)
max_loc = 가장 일치한 곳의 좌표 (이 곳이 목표 좌표)
'''

즉,

1. 원본 이미지를 준비하고,
2. 원본에서 찾고자 하는 요소을 잘라 준비하고,
3. matchTemplate 기능을 이용해 max_val, max_loc 값을 얻고,
4. max_val 값이 일정 수준(임계치) 넘길 시 max_loc 좌표를 돌려준다.

의 형식으로 "원하는 이미지가 어디있는지 찾기" 가 가능하다.

아래는 실제로 구현한 예시다.

이렇게 원본 이미지와, 템플릿 이미지를 준비하고 matchTemplate 함수를 활용하면

좌표를 찾아 낼 수 있다.

3. Airtest

Airtest는 이러한 방식으로 만들어진 것으로 확인된다.

airtest의 template_matching.py를 보면, (어느정도 전처리를 거친) 이미지를 템플릿매칭해서 

best_match라는 이름으로 max_loc  좌표를 (전처리하여) 돌려준다.

4. 사용법

Airtest에서 다음과 같이 사용할 수 있는 함수가 있다.

말고도 많은데

5. 한계

원하는 이미지가 가만히 있는다면 깔끔하게 목표 영역을 찾아낼 수 있다.

하지만, 누르고자 하는 영역이 움직이거나 색이 변한다면, 찾는 데에 실패할 수 있다.

ex 1.) lv 10까지는 "구매" 버튼이 빨간색인데, lv 11부터는 "구매" 버튼이 파란색으로 노출되는 ux 디자인

ex 2.) 버튼이 누르고 싶게 유도하기 위해 화려하게 이펙트가 발생

실제로, 이미지 매칭 유사도의 한계는 0.8이다.

또한, 안드로이드 기기를 대상으로 테스트 했을 때 결국 python의 subprocess에서 adb 명령어를 이용하여 화면을 불러오고, 캡쳐하고, 클릭하곤 한다.

appium 서버에, opencv 사용에, adb subprocess까지 하려고 하면 컴퓨터 자원을 아주 많이 잡아먹지 않을까?

디바이스가 하나 뿐이라면 문제가 없겠지만, 디바이스를 수십대 연결하면 컴퓨터가 비명을 지르지 않을까.. 생각된다!

6. 결론

Airtest IDE에서는 리포트 생성 기능도 있고, 캡처를 도와주고 빠르게 붙이는 강력한 기능도 있는데, 왜인지 마음이 안간다.

뭔가 쓰고싶지 않은 느낌?

아마 이런 거부감 때문에 현업에서는 새로운 툴 도입이 어려운 걸 수도 있다.

그치만 하나 확실한건, 이미지 매칭 기반 자동화 프로세스에 대해 배울 수 있는 훌륭한 프로젝트다!

많은 게임은 요소 찾는게 불가능 하지만, 어떻게든 자동화를 구현할 수는 있는듯.

Docker compose란?

여러 개의 Docker 컨테이너들을 한번에 실행할 때 쓰기 위해 사용함
복잡한 명령어를 간소화하기 위해 사용함

compose 흐름 - nginX

1. compose.yml 생성
2. 아래와 같이 내용 작성

   services:
    my-web-server:
    container_name: webserver
    image: nginx
    ports:
        - 80:80
    volumes:
        - ./my_data:/var/lib/sql

   services = docker compose에서는 컨테이너를 service라고 적음
   my-web-server = service의 이름
   container_name = 컨테이너의 이름 (--name 옵션)
   image = 어떤 이미지 쓸지 (이미지명)
   ports = 어떤 포트 쓸지 (-p 80:80)
   yml = 들여쓰기로 계층을 판단함 (like python)
3. 이 파일이 있는 경로에서 docker compose up 하면 실행이 됨
4. docker compose up -d 를 쓰면 백그라운드가 켜짐
5. docker compose ps를 하면 컨테이너들이 보임
6. docker compose down 하면 컨테이너들이 종료됨

자주 사용하는 Docker compose CLI

compose.yml에서 정의된 컨테이너 중에서만 작동한다.
docker compose up -d : 백그라운드에서 실행
docker compose ps : 실행 중인 컨테이너
docker compose logs : 컨테이너의 로그를 모아 출력
docker compose up --build : 빌드부터 다시
docker compose pull : 최신 이미지로 업데이트함
docker compose down : 컨테이너 종료

한번에 두개 띄우는 방법

services:
  first-server:
    image: redis
    ports:
      - 6379:6379
    container_name: server_1

  second-server:
    image: nginx
    ports:
      - 8080:80
    container_name: server_2

요런식으로! 파이썬 코드 작성하듯이 하면된다.

꿀팁

https://www.composerize.com/
웹사이트에 docker run 명령어를 넣으면 copose.yml에 넣을 커맨드를 받을 수 있다.
https://www.decomposerize.com/
거꾸로, 여기서는 compose.yml 명령어를 docker run 형식으로 바꿔줄 수 있다!

이 수업 다음은 뭘 배워야할까?

이 강의에서 클라우드 서비스를 이용해 배포하는 과정까지 포함되었으나, 딱히 해당 내용은 필요한 것 같지 않아 PASS!
강사님은, 우선 도커를 이런 저런 프로젝트에 적용해보라고 하셨다.
그 다음,

1. 쿠버네티스에 대한 소개를 했다.
   쿠버네티스는, 다수의 컨테이너를 관리하고 배포하는 데에 도움을 주는 툴이다!
   컨테이너 오케스트레이션 툴이라고도 부른다.
2. CI/CD 구축을 해보는 걸 추천했다.
   Docker 컨테이너 기반으로 CI/CD 구축을 해보라는 내용이다.

완강!

기본적인 내용만 사용해본 입장에서, 간단하게 사용하는 입장에서는 러닝커브가 높은 툴이 아니라고 느낀다.
어쩌면 잘 가르치는 강사님 이라서 그런걸수도.
과연 실무에는 어떤 무지막지한 내용이 있을지는 모르겠으나.. ㅎㅎ;
적어도 아는 지식이 전혀 없었던 과거보다는 나아진듯!

애초에 이 강의의 타겟이 비전공 초보자들을 위한 강의인데, 큰 도움이 됐다.

Dockerfile이란?

docker 이미지를 만들게 해주는 파일.
내가만든 프로젝트를 dockerfile로 만들고, 이걸 활용하면 docker 이미지로 쓸 수 있게 한다.

1. Dockerfile안에 베이스 이미지 넣기

# Dockerfile
FROM [이미지명]
FROM [이미지명]:[태그명]

태그명을 적지 않으면 가장 최신 버전을 사용한다.

2. Dockerfile 기반 이미지 만들기

# 터미널
docker build -t my-server .
docker build -t my-server:beta .

docker build // 도커에게 빌드를 명령
-t 태그 // 안적으면 latest, 적으면 적은 태그가 적힌다.
. // 상대 경로로, 점 하나는 "현재 여기"를 표시

3. 이미지 기반 컨테이너 띄우기

docker run -d my-server

my-server 실행해보기

4. 컨테이너 조회

docker ps -a

my-server의 STATUS가 Exited 로 적혀있다..!
이유 : FROM 이미지명 만 적으면 저거 실행하고 끝내버림.
내부 확인하려면?
일단 실행중이지 않기 때문에, exec로 내부를 볼 수 없음.
그럼 어떻게 하는가?

5. 꼼수

# Dockerfile
FROM 이미지명
ENTRYPOINT ["/bin/bash", "-c", "sleep 500"]

이렇게 하고 다시 빌드부터 해보면,
docker ps -a에서도,
docker exec -it 컨테이너명 bash에서도
실행이 되고있는걸 확인할 수 있다.
저 명령어는, 이후 디버깅할 때 유용하게 쓸 수 있다. 마치 셀레니움 할때 time.sleep(5)와 같은 느낌

COPY

FROM ubuntu
COPY a.txt /a.txt
COPY ./ / # 모든 파일을 다 붙여넣겠다
COPY *.txt /text-files/ #와일드카드같은것도 사용 가능
ENTRYPOINT ["/bin/bash", "-c", "sleep 500"]

해당 이미지에 호스트 a.txt 파일을 컨테이너 a.txt를 집어넣겠다.
폴더를 복사할땐 COPY folder /folder/ <<- 슬래시로 가둬야 정상적으로 폴더로 인식됨

.dockerignore

a.txt # a.txt는 넣지마라

gitignore처럼 , 추적을 원치 않는 파일을 지정할 수 있음. COPY에서 제외됨.

ENTRYPOINT

컨테이너가 시작될 때 실행되는 명령어.
즉, 컨테이너(미니컴퓨터)가 실행되고 바로 실행되는 명령어.

From ubuntu
ENTRYPOINT ["/bin/bash", "-c", "echo hello"]

해보면 echo hello 하고 바로 꺼지는 도커파일 생성이 된다.

RUN

run은 이미지 생성 과정에서 명령어를 실행시켜야 할 때 사용.
RUN vs ENTRYPOINT
RUN = 이미지 생성 과정에서 필요한 명령어를 실행시킬 때.
ENTRYPOINT = 이미지 생성 이후 컨테이너 실행된 직후에.
RUN 예제

FROM ubuntu
RUN apt update && apt install -y git

즉, 이미지 생성 중에 git이 설치된다.
RUN = docker build 중에
ENTRYPOINT = docker run 할 때

WORKDIR

작업 디렉토리를 전환. 마치 윈도우에서 cd (change directory) 느낌
이후 도커파일에 오는 모든 명령어들은 해당 위치에서 실행됨

FROM ubuntu
WORKDIR /new_directory
COPY ./ ./

위와같이, new_directory 라는 디렉토리로 이동 후 모든 파일을 복사하겠다는 뜻.
기본적으로는 루트 디렉토리에 파일이 저장되는데, 옮긴 후 COPY할 수 있다.

EXPOSE

컨테이너가 사용하는 포트를 명시적으로 알려주는 용도.
근데, 진짜 포트를 열지 않음.
docker run -p 옵션에서 진짜 포트를 염
그냥 주석처럼 "가이드라인"을 제공하는 느낌.

FROM ubuntu
EXPOSE 3000

주석처럼 없어도 되나, 적어두면 개발자나 도구에게 감초 역할을 한다.

전체 흐름

FROM node    # 기본적으로 node를 실행한다
WORKDIR /app    # 디렉토리를 app 폴더로 이동
copy . .    # 호스트의 현재 디렉토리 내 모든 파일을 복사, app 폴더에 붙여넣어짐
RUN npm install    # 이미지 생성 중 npm install을 실행
RUN npm run build    # 이미지 생성 중 npm run build를 실행
EXPOSE 3000    # 3000번 포트를 쓸거라고 알려만 준다.
ENTRYPOINT ["node", "dist/main.js"]    # node dist/main.js를 컨테이너에서 실행하라

효율적인 도커 파일 생성 방법

1. alpine 빌드를 사용.
   alpine = 불필요한 프로그램을 포함하지 않고 이미지 크기를 최소화한 버전.

변경이 적은 명령어를 위쪽에 배치하기.
dockerfile은 빌드할 때 docker cache를 만든다. 명령어 실행 내역을 캐시에 저장했다가, 다음에 다시 dockerfile을 재사용할 때 캐시를 이용하여 빠르게 빌드되게 만든다.
근데 만약 dockerfile 중간에 변경이 생긴다면, 그 아래에 있는 모든 명령어는 변경이 없음에도 다시 빌드된다.

이미지에서 main.c가 바뀐다면,
1,2 번 라인은 캐시에 저장되어있어 빨리 실행되나 3,4,5번은 캐시에 없던 내용이라 "무효화"된다.
모르겠으면, 그냥

"변경이 적은 명령어를 위쪽에 배치하기"

https://www.inflearn.com/course/%EB%B9%84%EC%A0%84%EA%B3%B5%EC%9E%90-docker-%EC%9E%85%EB%AC%B8-%EC%8B%A4%EC%A0%84

비전공자도 이해할 수 있는 Docker 입문/실전

개요

만우절날 인프런에서 단 돈 천원에 Docker 강의를 파는 소식에 낼름 사게 되었다!

본인만의 언어로 강의를 블로그에 적는 걸 권장한다고해서, 일단 보면서 올려보게 되었다.

총 76개 수업이 있고(단순히 유튜브 / 노션링크만 주는 수업도 포함) 현재 34강 중 정리해서 올리는 글이다.

단돈 천원에 구매해서 그런가? 너무나도 만족스럽게 수업을 듣고있다 ㅎㅎ

별개로, 옵시디언으로 필기를 하면서 보는데, 티스토리에 복붙하면 좀 흉하게 붙여진다...

별수있나 ㅎ

Docker란?

환경 설정이 컴퓨터마다 다른걸 가볍게 해결하기 위함.

Docker쓰는 이유

• 이식성이 좋다.
  ex)내가 만든 프로그램이 우리집 컴에서는 돌아갔는데, 팀원 컴에서는 안돌아간다...
  버전이 다르거나, 운영 체제가 다르거나, 다른 프로그램과 충돌이 났거나..
• 위와 같은 이유를 해결하기위해

도커(Docker)?

• 컨테이너를 사용하여 각각의 프로그램을 분리된 환경에서 관리할 수 있는 툴컨테이너(container)?
• 하나의 컴퓨터 환경 내 독립적인 컴퓨터 환경을 구성해, 각 환경에 프로그램을 별도로 설치할 수 있게 만든 개념

• 컴퓨터 - 호스트 컴퓨터
• 컨테이너 내에는 독립성이 있다.
  1. 일반적으로 A 컨테이너 내부에서 B 컨테이너 접근 불가 ❌
  2. 네트워크에도 접근 불가 ❌
• 이미지 - 닌텐도 칩과 같은 이미지. 필요한 설치과정, 설정, 버전 정보 등이 포함되어 있음.

Docker 간단 실습하기 with Nginx

Nginx => html 웹페이지 렌더링하는 기능

docker pull nginx => docker에서 nginx라는 게임칩(이미지) 다운받은거임
docker image ls => 게임칩(이미지) 다운받은거 확인하는거임
이제, nginx 게임칩(이미지) 꽂아보자.
docker run --name webserver -d -p 80:80 nginx
이러고, chrome에서 localhost:80 하면 작동하는거임.
docker ps => 현재 실행되고있는 컨테이너 목록이 뜸
docker stop webserver => 이름지은 거(--name webserver) stop하는 용도

이미지 (게임칩)

이미지 다운로드

• docker pull 이미지명 => 도커의 이미지를 다운받는다.이미지 잘 다운받아져있는지 확인
• docker image ls => 이미지 리스트 확인Docker Hub
• github과 유사하게, 이미지를 저장, 다운할 수 있는 저장소 역할. 여기서 pull 해옴
• Tags => 다양한 버전이 있음. 특정 버전을 나타내는 태그 명.
• docker pull 이미지명:Tag 하면 특정 태그의 이미지를 다운 받을 수 있음.
• 태그가 없으면, 가장 latest태그를 붙여서 다운받는다.

이미지 조회

• docker image ls
  Repository = 이미지명
  Tag = 버전
  IMAGE ID => 고유 ID
  CREATED => 그 이미지를 만든 회사에서 언제 만들었는지
  SIZE => 그 크기
• docker image rm IMAGE_ID
  • 이미지 ID의 일부만 쳐도 삭제가 됨.(그 일부가 고유할때)
• docker image rm 중, unable to delete - stopped container오류발생 시
  • 멈춘 컨테이너에 포함되어있는 이미지라서 지워지지가 않음
  • docker image rm -f <- 멈춘 컨테이너에 포함된건 지울수있음
  • 실행중인 컨테이너의 이미지는 지울 수 없음. 컨테이너 멈추고 > 이미지 삭제해야함.
• docker image rm $(docker images -q)
  • docker images -q => Docker의 ID만 출력함
  • 근데 windows cmd에서는 못씀.. 그럼 젠킨스에서는 for문으로 반복하든 해야겠음.
  • for /f %i in ('docker images -q') do docker image rm %i 요런 느낌

컨테이너 (미니 컴퓨터)

• docker create nginx => 컴퓨터 만들기
• docker start 컨테이너_ID => 컴퓨터 실행하기
  이러면 STATUS에 UP 13 seconds 처럼 컴퓨터가 켜진 시간이 나옴.
• docker create ~~ => 컴퓨터 만들 때, 이미지(게임 칩)이 없어도 docker hub에서 알아서 다운 받음
• docker run => docker create + docker start, 즉 컴퓨터 만들고 실행
  • -d 옵션 = 백 그라운드에서 실행
  • -p 옵션 = 포트를 연결하는 기능
    이미지 = 호스트에서 4000번 포트로 요청을 보내면 80번 포트와 연결시키겠다.
    localhost:4000으로 연결 가능.

    

    ---

    
    컨테이너 조회 / 중지 / 삭제
• 조회
  docker ps => 실행 중인 컨테이너 조회
  -a 옵션 = 중단된 컨테이너 포함 조회
• 중지
  docker stop 컨테이너_ID => 실행 중인 컨테이너 멈추기 (정상적으로 종료)
  docker kill 컨테이너_ID => 실행 중인 컨테이너 "강제 종료"
• 삭제
  docker rm 컨테이너_ID => 컨테이너 삭제
  docker rm $(docker ps -qa) => 중지된 컨테이너 모두 삭제인데.. 여기도 $명령어는 안됨
  docker rm -f 컨테이너_ID => 실행 중인 컨테이너 중지 후 삭제컨테이너 로그 조회실행(docker run) 상태에서 로그를 읽어볼 수 있는 방법이 있음
  docker logs 컨테이너_ID => 로그 읽기
  • --tail 숫자 옵션 = 숫자만큼 꼬리의 로그를 불러옴. (너무길때 추천)
  • -f 옵션 = 도커의 실시간 로그 볼수있게해줌 (백그라운드로 돌린 도커를 포어그라운드로 보기)
  • --tail 0 -f = 이전꺼 말고 지금 시점부터의 로그 조회실행중인 컨테이너 내부 접속실행(docker run) 상태의 도커 내부 진입함
• docker exec -it 컨테이너_ID bash => 컨테이너에 bash 쉘로 접속한다.

1. SQLD?

- 자격증 정보

• 데이터베이스와 SQL에 대한 기본적인 지식을 검증하는 시험
• 데이터베이스 기초, 데이터 모델링, SQL 작성 및 활용 등의 내용

- 취득 목적

• QA 직무에서 데이터 관련 검증이 필요할 때 유용할 것으로 생각됨
• 데이터베이스에 대한 이해

2. 시험 정보 및 일정

• 비용 : 50,000원
• 시험 장소 : 전국 어디서든!
• 시험 범위
  1. 데이터 모델링의 이해 (10문제)
  - 기본 용어부터, 데이터베이스의 이론적 이야기가 많이 나옴
  2. SQL 기본및 활용 (40문제)
  - SELECT, From , Where과 같은 기본부터, groupby, orderby, join의 기본 내용
  - 서브쿼리, 집합연산자, 그룹함수, 윈도우함수, TOP N 쿼리, 계층형 질의, 셀프조인, 정규표현식의 활용성 높은 응용
  - DML, TCL, DDL, DCL 관리구문 내용
• 시험 시간 : 90분
• 합격 기준 : 객관식 50문항 중 30문제(60%) 취득 시, 과락이 존재

3. 공부 방법

- 사용한 학습 자료

이 책 하나면 충분했다!

특히 노랭이책을 많이 추천하는데, 이론을 배우고 기출문제를 하고싶은 마음에 이 책을 선택했다.

책의 장점
1. 150문제 + 기출 7회라는 어마어마한 문제의 양

2. 유튜브 강의 제공 ( 목소리가 상당히 달달해서 듣기 좋았다 )
책의 단점
1. 프로시저와 같은 개정되어 사라진 내용들이 한두문제씩 섞여있다.

유튜브 강의를 잘 듣고, "이 문제는 안나오는거니까 넘어갑니다" 이런식으로 말하는걸 잘 듣고 문제를 걸러야했다.

2. 많은 문제 사이에서 중복된 문제들도 있었다.

그럼에도 문제의 양이 많아서 좋긴하다..

- 공부 기간 및 학습 계획 :

수업을 병행하면서 듣기엔 쉽지 않을것 같아서 공부 기간을 길게 잡았다. 한 4주?

평일에는 하루 한두시간만 하자는 마인드로 했었고, 주말에는 3시간에서 4시간정도 잡았다.

이론을 보다보면 이해가 안가는 내용이 많은데, 그럴때는 (누워서) 태블릿으로 유튜브 강의를 들었다.

내용과 문제는 정보처리기사에서 봤을법한 내용이라 쉽게 딸 수 있었는듯!

4. 시험 후기 및 난이도

- 시험에서 어려웠던 부분

전체적으로 뭔 문제인지 전혀 이해 못하는 문제도 있었고, 기출에서 봐서 10초도 안돼 푼 문제도 있었다.
준비를 나름 한 시험인 만큼, 모르는 문제는 없고 어려운 문제가 많을 줄 알았는데, 모르는 문제가 나와서 좀 당황했지만!

- 38점 체감 난이도

그래도, 38문제를 맞춘 걸 보니 쉬운 편 이었던 것 같다.

시험 발표 전까지는 굉장히 조마조마했다. 합격 확신을 못했었는데, 생각보다 고득점을 했었다!

5. 느낀점 & 목표

- 취득 후 느낀점 

자격증 내용 중 많이 알찼던 내용이 많았다. 물론 실무에서 DB에 접근해본 적은 없지만, 이론으로나마 DB 구조를 상상보고, 데이터를 어떻게 가져올지 생각해볼 수 있었다!

실제로 실무에서, 기획자와 개발자 사이에서 SQL문을 공유하는걸 봤었는데, 이제야 어떤말인지 볼 수 있는 눈이 생기지 않았을까 싶다.

- 목표

실제 데이터베이스 접근할 일이 생기면 많이 써보면서 익숙해지고싶다.

지금의 수준은 배운 수준의 SQL 구문이 주어지면 어떤 구문인지 읽을수는 있는 단계인 것 같다.

외국어와 같이, 글을 읽는거랑 글을 쓰는건 다를거니까..

0. 개요

Garbage in, Garbage out.
올바르지 않은 입력값을 넣으면 올바르지 않은 출력값이 나온다. 

라는 IT의 속담이 있다.

대학교 1학년때, C언어 강의를 들을 때 교수님이 저런 말을 하면서,

니들이 오타낸거 아니냐?

를 예쁘게 돌려 말했던 기억이 난다.

1. 컴퓨터가 틀렸다?

소숫점 계산을 배운 초등학생에게 1.1 + 0.1을 물어보면, 너무나도 당연하게도 1.2라고 대답 할 것이다.

하지만, 파이썬에서 1.1 + 0.1 == 1.2 를 입력하면, False를 대답한다!

그럼 왜 이런 결과를 내는걸까?

2. 2진법

컴퓨터는 0과 1로 이루어져있고, 숫자를 표현하기 위해 2진법을 사용한다.

예를들어, 8칸짜리 공간이 있다고하면 

2진법의 (00000010) 은 10진법의 (2)와 같다.

그렇다면, 만약 8칸짜리 공간에서 마이너스를 표현하고싶다면?

3. 부호

8칸의 공간에서 마이너스를 쓰고싶다면, 한칸을 마이너스와 플러스를 구분하는 숫자로 "약속" 하면 된다.

제일 앞의 숫자를, "부호" 라고 약속하는 것이다. 0 = +, 1 =  -

약속을 하기 전에는 2의 8승 만큼 표현이 가능했는데,

약속을 한 이후에는, 마이너스로 2의 7승, 플러스로 2의 7승만큼 표현이 가능해졌다!

이 기세로, 소수점도 표현해보려고한다면?

4. 소수점

정수는 2진법으로 쉽게 표현할 수 있지만, 소수점을 2진법으로 표현하기에는 어려움이 있다.

마치 10진법에서도 1/3을 소수점으로 표현할 때 0.33333333...... 같은 순환소수가 있듯, 2진법에도 표현하려고 하면 끝없이 반복되는 케이스가 있곤 하다.

그래서, 숫자를 표현할 때, 부동소수점 이라는 방식을 사용한다.

너무 어려운 내용이라 담지는 않았다!

대충 이해한 바로는, 그 숫자와 가장 근사값을 찾는 방식으로 작동된다고 한다.

따라서, 정확한 값을 출력해주지는 못하고, 0.1이 0.100000000000000001 같은, 아주 작은 오차가 발생하곤 한다.

그래서 0.1 + 1.1을 했을 때 1.2가 아닌 1.200000001과 같은 아주 작은 오차가 발생한다.

5. 문제

이렇게 작은 오차가, 실제로 문제를 일으킬 수 있다.

예를 들자면,

• 재료 양에 따라 확률이 정해지는 게임 강화 시스템에서, 100%를 채웠는데 사실 100%가 아닌 99.99999%여서 실패함
• 금융권에서, 0.1달러를 송금 후 다시 받을 때마다 0.00001달러가 더 들어옴
• 의료용 기기를 만드는데, 소수점 단위로 정밀 의료 용품을 만들었는데 고장나버림

이런 이슈가 있을 수도 있을 것 같다! (금융과 의료는 좀 과장된 내용일수도 ?)

그렇다면, 소프트웨어 QA의 입장에서 이러한 문제를 발견했을 때 어떻게 해야 할까?

6. 해결

실무에서는, 정말 단순한데 너무나도 확실한 방법을 사용한다.

실무자 : 그냥 소수점 안쓰지 뭐 ㅋㅋ

실제로, 대부분의 실무에서는 이러한 방법을 사용한다고 한다.

즉, 100프로가 백만이라면 50%의 확률을 구현할 때 50만을 쓰는 방식으로 구현한다.

꼭 소수점을 써야하는 상황이라면, 파이썬으로 치면 round와 같은 반올림 함수를 사용해서 사용하는 것을 권한다고 한다.

7. 결론

사실 너무나도 유명한 내용이기에 실무에서 이런걸 마주할 일은 없을 것 같다.

하지만, 자동화 스크립트를 만든다고 할 때, 소수점을 쓸 일이 있다면 한번은 생각하고 쓸 수 있는 내용이다.

또한 만약 누군가가 소수점을 사용해서 코드를 짜는걸 발견 한다면, 취약점을 훈수할 생각에 입꼬리가 씰룩거릴 수도 있다.

8. 세줄 요약

1. 컴퓨터에 소수점을 넣으면 가끔은 근사 값을 준다.

2. 그냥 정수로 바꿔 쓰면 마음 편하다.

3. 사실 실무에서는 볼 일 없는 문제일 것 같다. 다 정수로 쓰고있거나 반올림 처리 하고 있거나.