소프트웨어WSL & Docker

[WSL] Docker 테스트 환경을 정리하기로 한 이야기

, , , , , ,

WSL과 Docker 연재 및 정리를 시작하며…

필자는 오랜 시간 동안 Software Test Specialist, 그리고 Quality Assurance라는 정체성으로 살아왔다. 이 정체성으로 살아가다보면 그 업을 수행하는 자체로 여러 가지 문제점들이 존재하는데, 그 중 가장 대표적인 부분이 바로 이 두 업(Testing과 QA)의 차이를 이해를 못하는 사람들이 많다는 점이다. 업의 정체성에 대해 논의하는 과정이 빠져 있던 채로 누군가 업계를 이끌어왔고, 그대로 확장되었고, 그 상태로 재논의 하려는 누군가들을… 정체를 특정할 수 없는 누군가들이 의견들을 짓밟아 온 흔적들을 자주 발견하곤 한다.

그래서 필자는 주변 동료들과 팀을 결성하여 이런 프로젝트 블로그 → 소프트웨어 테스팅 참고서를 작성하고 있기도 하다. 특정 업계 종사자들이 각자의 회사에서 정치적인 관점 혹은 조직 내부의 포지션 구축에 어려움을 겪고 있어 정체성을 논의하는 장이 이루어지기 힘들다면, 그에 대해 충분히 고민한 사람들이 이를 정의하는 새로운 프로젝트를 수행하고 있는 거다.

바로 이 지점이 이 글을 쓰고 있는 이유, 다시 블로그를 재 정비하기로 한 이유, 그리고 여러 가지 글들을 카테고리로 나누어 정리하려는 이유이기도 한다. 정체성 논의가 정상적으로 이루어지지 못했다보니 「Tester」들은 업계 진입 후 정상적인 가르침을 받거나 이끌어줄 구심점을 찾기 어려워 「Test Export」가 되기 어려운 문제점이 있다. 그래서 어떤 도구를 사용할 때 ‘테스트 업무 목적’외 응용 방법을 찾지 못하는 경우가 많고, 이런 결과로 다시 ‘수동 테스팅(Manual Testing)’으로 귀환하여 결국 사람 손을 타는 테스팅 기법들이 만연하게 되는 문제점을 해결해야 하기 때문이다.

사실 이걸 필자가 할 필요는 없었다. 더 잘 하시는 분들이 했으면 됐다. 그래서 손 놓고 몇 년 간 지켜봤는데 안되더라. 그래서 깨달았다. 이건 Programming과 Testing을 전반적으로 모두 이해하는 사람이 해야 할 수 있다는 것을. 그래서 결국 필자가 해야만 하는 일이라는 어떤 사명감 같은게 생겼다. 그래서 이제부터 필자는 가능한 많은, 다양한 테스트 환경 구축에 대한 내용들을 블로그에 남겨둘 예정이다. 뜻이 있는 자는 찾을 것이고, 간절히 찾는 자는 이를 수 있을 것이라 믿기에…


참고

본 글과 블로그에서 필자는 Testing과 QA를 구분해서 설명할 것이다.

QA != Testing

이에 대한 긴 글은 이미 기본적인 내용 정리는 마쳤으나, 전체적인 관점에서 오해 없게 하기 위해 기반 지식들을 다시 정리하여 하나의 묶음으로 공개할 예정이다. 해당 글들의 공개에는 몇 년이 걸릴 수도 있다. 언제 공개할 지 모르겠지만, QA 및 Testing 업계 종사 인원들 대부분이 ‘이 업계는 가망이 없어’라며 울분을 성토하기 전에 공개할 예정이다.

QA is not testing


테스트 전문가는 테스트 환경을 만들 수 있어야 한다.

1. 뭘 알아야 전문가일까?

어느 분야든 ‘전문가’가 되기 위해서는 해당 분야에 대해 전문적으로 알고 있어야지, 자기가 하는 일만 잘 하고, 잘 이해한다고 주변 사람들이 그를 ‘전문 지식을 갖춘 사람’으로 인정해 주지 않는다.

동일 선상에서 해석해 보면, 누구든 ‘소프트웨어 테스팅 전문가(Software Testing Expert)’가 되기 위해서는 ① 소프트웨어, 그 소프트웨어를 만드는 방법인 ② 프로그래밍, 소프트웨어가 잘 만들어졌는지 확인하는 작업인 ③ 테스팅을 이해하고 있어야 한다. 간단하게 설명해서 저 세 단어를 가로지르는 개념인 「소프트웨어 개발」에 대해 전반적으로 이해하고 있어야 한다. 그래야 ‘소프트웨어 (개발) 테스팅 전문가’라고 할 수 있을 것이다.

먼저 테스팅 전문가들이 이해해야 하는 내용이 있다. 바로 ‘프로그래밍이란 무엇인가?’에 대한 이야기이다. 대부분의 ‘수동 테스터(Manual Tester)’들은 “전 프로그래밍을 잘 못해서요~” 하는 경우가 많은데, 필자가 보기에 그들은 모두 뭔가 이상할 정도로 “학습된 무기력증”에 잠식되어 있다는 느낌을 받는다. 자, 필자가 설명해 준다. 일단 겁먹지 말자.

잠깐 겁먹지 말아봐요.


2. 프로그래밍이란 무엇일까?

Programming이라는 단어는 Program + ing이다. 여기에서 ‘ing’는 어떤 행위(동사)에 대한 표현을 명사 형태로 변경할 때 영어에서 쓰는 어미이다. 그 중 Program의 어원은 그리스어로 「pro(사전에) + graphein(기록하다)」이라 한다. (출처) 그러므로 Program이라는 말은 ‘사전에 (무언가를) 기록한다’라는 의미를 어원으로 가진 단어이다. 즉, ‘사전에 기록함’ 정도로 이해하면 되겠다.

사실 ‘프로그래밍이란 무엇인가’에 대한 훌륭하신 분들의 여러가지 정의들이 있다. 훌륭하신 분들이 정리하시면 Programming이란 행위에 대해 간단히 정리하면 「특정한 목적을 해결하기 위해 사용자가 시간 순서에 따라 일어나타야 하는 일을 컴퓨터에 알려주는 명령 체계」라 할 수 있다. 그런 정의에서 크게 벗어나지 않아야 겠지만, 필자의 개인적인 생각에 ‘프로그램’이란, 「인간들이 컴퓨터에 명령을 주기 위해 컴퓨터가 알아 들을 수 있는 형태의 ‘규약(Protocol)’을 만들었고, 그 ‘규약에 맞추어 컴퓨터라는 기계를 조종하기 위한 규칙을 나열’하는 행위」라 본다.

즉, 프로그래밍이란 상황에 따라 뭔가 되게 유기적으로 변화하는 무언가를 다루는게 아니라, 일종의 ‘제약 사항을 가지고 있는 기계의 조종을 위한 규약’인거다. 쉽게 예를 들어, 방에 불을 켜기 위하 스위치는 On과 Off 외 다른 규약은 없다. 사용자가 할 일은 On/Off를 선택하는 것이다. 방에 불을 켜기 위한 스위치에 Move 같은 명령은 내릴 수 없다. 프로그래밍이라는 행위도 결국은 (‘프로그래밍 언어’라 부르는) 소프트웨어의 스펙(Spec)에 따라 특정 명령들을 주르륵 나열하는 것일 뿐이다.

프로그래밍 그 자체가 ‘뭔가 되게 어려운 행위인 것이 아니다’라는 점을 테스트 전문가가 되기 전에 알아야 한다. 프로그래밍을 처음 배우는 사람들은 이를 이해하려고 들지 말고, 외워야 한다. 외우다보면 이해가 된다.

물론 프로그래밍이 작동하는 환경인 ‘컴퓨터’, 그리고 그 ‘컴퓨터의 원리’는 어느 정도 이해해야 한다. 외우기엔 내용이 너무 방대하기 때문이기도 하고, 외워봐야 의미 없는 내용들이 대부분이기 때문이다.

What is Programming?


3. 왜 테스트 환경을 잘 알아야 할까?

1957년, Charles L. Baker는 “디버깅과 테스팅은 다른 활동이다. 이 두 활동은 서로 구분해야 한다.”라고 선언하였고, 이후 소프트웨어 테스팅 기법이 정리된 최초의 책이 출간된 1979년 이후 많은 시간이 흘렀음에도 불구하고 아직도 많은 수의 Programmer들은 Testing이라는 작업을 ‘Programing의 Pattern’ 정도로 인식하고 있다.

음… 필자가 너무 고상하게 표현했나 싶다. 다르게 이야기 하자면…

테스트 전문가들이 테스트 환경을 만드는 방법을 잘 알아야 하는 이유는 2021년인데 아직도 ‘Testing 환경’을 ‘QA 환경’이라는 명칭으로 부르며, Testing과 QA의 차이를 인지하지 못하는 사람들의 무지가 너무 많고 널리 퍼져있기 때문이다. 이렇게 서로 다른 용어를 같다고 취급해 버리면, 정작 특정 활동이 필요할 때 해당 활동에 대한 용어적 정의를 내릴 수 없는 문제가 발생한다. 현실에서는 정의할 용어가 마땅치 않으니 마치 눈 앞에 존재하는 문제인데도… 없다는듯이 문제를 직시할 수 없게 되어버리는 결과로 나타나곤한다.

그러니, 필자가 이런 글들을 정리하는 이유는 이렇다. 필자는 테스트 전문가들이 테스트 환경을 설정하고, 테스트 환경으로 인해 얻어야 하는 결과와 수행 목적을 명확히 하기를 희망한다. 그렇게 한다면… 적어도 ‘Testing’과 ‘QA’ 활동을 분리할 수 있지 않을까, 그리고 그로 인해 이 두 표현을 두루뭉실하게 사용하면서 보지 못했던 여러 소프트웨어 품질 관련 문제점들을 직시할 수 있게 될 거다. 그리고 결과적으로 대한민국 전체 소프트웨어 업계의 품질 향상으로 이루어질거라는 믿음이 있다.

관련한 또 다른 내용은 필자가 진행 중인 프로젝트 팀 블로그의 내용을 참고하시기 바란다.


4. Testing을 Testing이라 부르지 못하고…

필자와 필자 주위 지인들은 소프트웨어 관련 용어들에 꽤나 민감한 편인데, 이는 Testing과 QA라는 업무를 정상적으로 수행한 사람이라면 당연히 자연스레 체득하게 되는 버릇이다. Testing 활동을 하게 되면 당연히 결과 기반의 과정 유추의 사고를 하게 되고, 또 QA라는 행위를 하다보면 자연스럽게 Software Engineering 기반의 사고를 하기 때문이다. (이 이야기는 나중에 기회가 되면 다시 하기로 하겠다.)

이를 기반으로 간단히 이야기를 해 보면, 테스트 전문가들이 Testing을 수행하고 그 결과로 프로세스에 변경을 할 수 있어야 ‘QA환경’이라 할 수 있다. 그냥 버그 찾고 제품/서비스를 수정할 목적으로 꾸민 환경이라면 ‘Testing 환경’ 혹은 ‘Test 서버’가 옳은 표현이다. 만약 외국 나갔는데 당신을 보고 “당신은 아시아 사람이니까 중국 사람이거나 일본 사람이군요” 라고 하면 한국인으로써 얼마나 기분 나쁘겠는가? 우리는 홍길동이 아니므로, 아버지를 아버지라 똑바로 부르자. 그래, Testing은 Testing이라고 부르자. Testing을 애매하게 QA라고 부르지 말자.

  • QA 환경 (X) ▶ Testing 환경 (O)
  • QA 기간 (X) ▶ Testing 기간 (O)
  • QA 했어요? (X) ▶ Testing 했어요? (O)
  • QA 실패했다. (X) ▶ Testing 실패했다. (O)

Testing과 QA는 엄연히 다른 활동이고 구분되어야 한다. 그러니 자신의 회사에 “QA환경” 이라는 서버가 있다면 일단 이름부터 “Test 환경”으로 변경하자. 제발.


참고 자료