brunch

You can make anything
by writing

C.S.Lewis

by 호뎡 May 13. 2024

테스팅을 통해 찾고자 하는 것
(헷갈림 주의)

생각보다 많은 사람들이 오해하는 결함(defect)의 진정한 의미


처음 입사한 후로 가장 기억나는 일을 말하라고 하면, 저는 사업기획이라고 할 것 같습니다.

기획이라니, 너무 막중한 임무이기에 엄청 들뜨기도 하였고 내가 하는 일에 대해 주변 사람들한테 과시도 좀 해보고 그랬었으나..... 지금은 그때를 생각하면 솔직히 조금 어지럽습니다.


쓸 게 정말 정말 많았거든요....


기획할 카테고리마다 뭔 놈의 기업이력, 보유이력, 보유기술, 보유현황.......



진행한 것도 뭐가 그리 많은지 쉴 새 없이 써나간 것 같습니다. 우리 회사 자랑하라고 하면 AI처럼 줄줄이 나열할 수 있을 정도로 우리 회사이력을 써 내려갔었습니다.

그 와중 문득 한 가지 일이 떠오르더군요.


입사 이래로 한 가지 착각한 점이 있었습니다.


솔직히 많은 분들이 테스팅에 심혈을 기울이고 계셔서 주 업무가 테스팅만 있는 것처럼 보였었으나..... 사실 둘이 차이가 있다고 합니다. 더 정확히 말하면, 품질보증(Quality Assurance) 안에 테스팅 업무가 포함되어 있는 것이죠.


사실 제가 입사한 품질보증 회사라고 하면 보유한 제품의 하자가 없음을 인증하는 활동을 주 업무로 삼고 있다고 볼 수 있습니다. 이런 착각을 한 저는 정말..... 분발하겠습니다.

그렇지만 보통 요구사항에 맞게 시스템이 잘 동작하는가를 체크하기에, 테스팅 활동이 중심이 되어있다고 보는 것이죠.


아마 대부분의 대기업들은 시장분석에 굉장히 심혈을 가하기도 하고 기획자의 의도 하나하나가 정말 중요하기에 그만큼 요구사항에 예민하게 반응하는 것 같습니다.


실제 사용자가 프로그램 사용 중 문제가 발생하면 기업 규모가 클수록 이미지 타격이 크다는 것은 누구나 어느 정도 예상할 수 있었죠. 다만 의아한 점은, 그런 것치곤 요구사항을 꼼꼼히 전달하지는 않는 듯하고, 결함 주의 구간에 대해서도 크게 신경 쓰지 않더라구요. 시간이 없어서 그런가?

스타트업의 경우, 이런 경향을 더 크게 보이는 듯했습니다.


확실한 건, 전문가의 시선은 달라도 확연히 다르더라구요. 테스트 시나리오를 보면 지나치게 상세하고 논리적인 구조는 물론이고, 확실히 프로페셔널함이 느껴지는 정도였다고 할까?


여기서 잠깐, 테스트시나리오란?

소프트웨어에 일으키고자 하는 상황을 정리하고, 그 상황을 일으켰을 때 나타날 원하는 결과를 정의한 것. 수행 상황들을 하나의 시나리오로 표현하여 어떤 항목을 테스트할 것인지 명시화 한 것으로 생각해 주시면 좋을 것 같습니다. 


아무튼 덧붙이자면,

저렇게까지 노가다를 하면서 나온 결과를 하나하나 상세히 기록하는 뭐 그게 꼭 필요한가...? 싶던 와중 한 가지 사건이 떠오르더군요.



해당 사건 기억하시나요? 전설의 중학생 해커 등장!.......... 은 아니고 보안 의식 부족에 의한 사고라고 볼 수 있겠군요(아이디와 비밀번호가 전광판에 잠깐 노출되었었다고 합니다). 예상치 못한 개인정보 노출 과정이 있다는 것이 해당 프로그램의 허점이라고 볼 수 있겠죠?


실제로 전광판에 접속한 중학생은 천재 해커는 아니고 전광판에 노출된 아이디와 비밀번호를 통해 광역 도발을 시전 한 겁니다. 생각보다 허무한(?) 사건의 진상이었지만, 원래 보안 사고의 경우 보통 사회공학적인 방법을 통해 이루어진다고 합니다.


한때 저는 해킹 또는 보안 사고들을 생각한다면 어떤 후드를 뒤집어쓴 사내가 어두컴컴한 방에서 기계식 키보드를 두드리며 스크린에 새어 나오는 빛에 의존한 채 이진 코드를 주입하는..... 식의 망상을 하곤 했던 거 같아요.  뭐 물론 그런 경우도 있겠지만 너무 판타지에 가깝죠? 

소위 천재들이 별 것도 아닌 프로그램 잠입을 위해 손수 이런 식의 재롱잔치를 펼칠 순 있으나 보통은 생각보다 시시한(?) 방법을 통해 소프트웨어에 위협을 가하는 경우가 훨씬 많습니다. 인간이 할 법한 실수를 찾아내어 그 부분을 공격포인트로 이용하는 것이죠.


귀멸의 칼날 中


이를 결함이라고 하기도 하고, 때론 취약점이라고 말하시는 분들도 계시는데, 좀 더 정확히 말하자면 위 사례에 쓰기 더 알맞은 표현은 취약점이라고 보시면 좋을 것 같습니다. 해당 약점을 이용한 해킹(?)을 통해 보안 사고가 일어난 형식이기 때문이죠.


무슨 보안, 무슨 정보 침해, 해킹 등등.... 특정 보안 사고에 휘말릴 수도 있는 시스템의 하자는 취약점이라고 보고, 구현 관점에서 의심스러운 또는 강력한 보안 체제가 없는 프로그램의 일부분을 약점이라고 봅니다.


이게 무슨 말이냐면, 해커의 관점에서는 취약점을 발견하는 것이고, 시스템 자체에는 구현되어 있는 곳에 약점이 있다고 이해하시면 됩니다.


품질 또는 보안 관점에서의 용어

그러면 도대체 결함은 무엇일까요? 이게 바로 테스팅 업무를 진행하면서 발견해야 할 문제 중 하나입니다. 꼭 해킹 위험이 감도는 부분이 아니더라도, 해당 시스템을 사용할 사용자가 원하는 방향대로 작동하지 않는 부분도 포함됩니다. 즉 버그, 요구사항에 맞지 않는 구현, 결과가 제대로 출력되지 않는 곳, 오류, 고장 등등 시스템 자체가 가진 오작동이 발견되면 결함이라고 합니다.


취약점, 약점과는 조금 의미가 다르다는 것을 느끼셨나요?


작가의 이전글 무의식 속 진정한 테스트의 개념 (사전은 저리 가라)
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari