지난 40년에 걸쳐 많은 수의 테스팅 원칙들이 제안되었다. 그리고 모든 테스팅에 대하여 가이드라인이 제공되었다.
원칙 1 - 테스팅은 결함의 존재를 보여준다.
테스팅은 결함(defect)이 존재하는 것을 보여줄 수 있다. 그러나 결함이 없다는 것을 증명하진 못한다. 테스팅은 소프트웨어에 확인되지 않은 결점이 남아 있을 확률을 줄인다. 그러나 결점이 발견되지 않는다고 하여도 이것이 완전하다는 증명이 될 수 없다.
원칙 2 - 소모적인 테스팅은 불가능하다.
사소한 경우를 제외하고 모든 것을 테스팅하는 것(입력과 선행조건의 조합)은 불가능하다. 소모적인 테스팅 대신에, 우리는 위험(risk)와 우선순위(priorities)를 이용하여 테스팅하는데 드는 노력에 초점을 맞춘다.
프로그램을 완전히 테스트하는 것은 불가능하다. 간단한 소프트웨어라고 해도 프로그램을 완전히 테스트하는 것은 불가능하다. 불필요하다고 느껴서 혹은 시간을 절약하기 위해 특정 조건에서의 테스트를 건너뛰기로 결정하는 것은 프로그램을 완전히 테스트하지 않는다는 것을 뜻한다.
모든것을 테스트하려고 하면 비용은 엄청나게 증가하며 놓치게 되는 버그의 숫자는 일정 수준으로 감소하기 때문에 이와 같은 작업을 계속하는 것은 비용 면에서 효율적이지 못하다. 테스트를 축소시키거나 테스트할 대상에 올바른 판단을 내리지 못하면 비용은 감소하지만 많은 버그를 방치하게 된다. 따라서 너무 많지도 적지도 않은 적절한 양의 테스트 작업을 수행하는 것이 중요하다.
소프트웨어나 시스템 개발주기에서 가능한 빨리 테스트 활동을 시작하여야 하며, 정의된 목표에 초점을 두어야 한다.
작은 수의 모듈이 선행 배포(Pre-release) 테스팅 동안에 발견된 대부분의 결함을 포함하거나, 대부분의 운영 실패(oprational failure)를 보여준다.
동일한 테스트가 계속적으로 반복된다면, 실제적으로 동일한 테스트 케이스의 집합은 더 이상 새로운 버그를 발견하지 못할 것이다. 이러한 "살충제 패러독스(Pesticide paradox)"를 극복하기 위해서는 테스트 케이들이 주기적으로 검토되고 새로이 고안되어야 하며, 잠재적으로 좀 더 많은 결함을 발견하기 위하여 소프트웨어나 시스템의 다양한 부분들을 실행하도록 다양한 테스트 케이스들(test cases)을 작성해야 한다.
소프트웨어나 시스템에 대한 잠재적인 더 많은 결점을 발견하기 위하여 여러 부분을 테스트하기 위해 작성된 다양한 새로운 테스트들이 필요하다.
원칙 6 - 테스팅은 내용(context)에 종속적이다.
테스팅은 다양한 내용에 따라서 다르게 행하여진다. 예를 들어, 안전에 민감한 소프트웨어는 전자 상거래 사이트와는 다르게 테스트 된다.
만일 구축된 시스템이 쓸모 없으며, 사용자의 요구와 기대를 채우지 못한다면, 결함을 찾고 고치는 것은 의미가 없는 일이다.
소프트웨어 테스터가 배워야 할 한가지 중요한 개념은 많은 영역의 테스트 대상을 테스트 가능한 범위로 축소하는 방법이다. 이렇게 하려면 무엇이 중요하고 무엇이 중요하지 않은지에 대하여 현명하게 판단하는 방법을 알아야 한다.
발견한 모든 버그를 수정할 수 없다.
소프트웨어 테스트 작업의 실상 중 하나는 버그를 찾아내기 위해 기울였던 많은 노력에도 불구하고 발견된 버그를 모두 수정할 수 없다는 사실이다.
버그를 수정하지 않기로 결정하는 이유는 아래와 같다.
* 버그라고 말하기 힘든 버그도 있다.
* 제품 명세서는 결코 최종적인 것이 아니다.
* 소프트웨어 테스팅은 훈련이 필요한 전문 기술이다.
테스팅의 가장 명백한 부분은 테스트를 실행하는 것이다. 그러나 효과적이고 효율적인 테스팅이 되기 위해서는 테스트를 계획하고, 테스트 케이스를 설계하고, 실행을 준비하고 상태를 평가하는데 보내는 시간 역시 포함되어야 한다.
기본적인 테스트 프로세스는 다음의 주된 액티비티들(activities)로 구성된다.
• 계획과 통제 (Planning and Control)
• 분석과 설계 (Analysis and Design)
• 구현과 실행 ( Implementation and Execution)
• 종료 기준의 평가와 보고 (Evaluating exit criteria and Reporting)
• 테스트 종료 액티비티들 (Test closure activities)
논리적으로는 순차적이지만, 프로세스내에서 액티비티들은 중첩되거나 동시에 진행될 수 있다.
1.4.1 테스트 계획(Planning)과 통제(Control)
테스트 계획(Test planning)은 테스트의 목적과 임무(mission)를 만족시키기 위하여 테스팅의 임무을 검증하고, 테스팅의 목적과 테스트 액티비티들의 명세를 정의하는 액티비티이다.
테스트 통제(Test Control)은 실제 진행상황과 계획을 비교하고, 계획의 오차를 포함한 진행 상태를 보고하는 계속 진행되는 액티비티이다. 테스트 통제는 프로젝트의 임무와 목표를 만족시키기 위하여 필요한 액션들(actions)을 포함한다. 테스팅을 통제하기 위해서는, 프로젝트 전체에 걸쳐 모니터링 되어야 한다. 테스트 계획은 모니터링과 통제 액티비티로 부터 피드백(feedback)을 받는다.
테스트 계획(Test Planning)은 다음의 주요 작업들(tasks)을 포함한다.
• 테스팅의 범위(scope)와 위험(risk)를 결정하고, 테스팅의 목표를 정한다.
• 테스트 방법을 정한다.(기법, 테스트 항목, 적용 범위, 테스팅에 포함되는 팀들간의 정의와 조정, 테스트웨어)
• 요구되는 테스트 자원을 정의한다. (e.g 인력, 테스트 환경, PC등)
• 테스트 정책과/또는 테스트 전략을 결정한다.
• 테스트 분석과 설계 작업을 계획한다.
• 테스트 구현과 실행 그리고 평가를 계획한다.
• 종료 기준을 결정한다.
테스트 통제(Test Control)는 다음의 주요한 작업들을 포함한다.
• 결과의 측정과 분석
• 프로세스, 테스트 커버리지(test coverage), 그리고 종료 기준(exit criteria)의 모니터링과 문서화
• 올바른 동작의 초기화
• 의사결정
1.4.2 테스트 분석(Analysis)과 설계(Design)
테스트 분석과 설계는 일반적인 테스팅 목표를 구체적인 테스트 조건과 테스트 설계로 변환하는 액티비티이다.
테스트 분석과 설계는 다음의 주요한 작업을 포함한다.
• 테스트 관련 기본사항을 검토한다.(요구사항, 아키텍쳐, 디자인, 인터페이스)
• 테스트 조건 또는 테스트 요구사항과 테스트 항목, 명세, 동작과 구조에 분석을 기초로 필요한 테스트 데이터를 정의한다.
• 테스트들(tests)을 설계한다.
• 시스템과 요구사항의 테스트 가능성을 평가한다.
• 테스트 환경을 설정하고, 테스트에 요구되는 기반 구조와 도구를 정의한다.
1.4.3 테스트 구현(Implementation)과 실행(execution)
테스트 구현과 실행은 테스트 조건들이 테스트 케이스(test case)와 테스트웨어(testware) 그리고 테스트 설정 환경으로 변환되는 액티비티이다.
테스트 구현과 실행은 다음의 주요한 작업을 포함한다.
• 테스트 케이스의 개발과 우선 순위화, 테스트 데이터의 생성, 테스트 절차(test procedures)의 작성, 그리고 테스트 장치의 준비와 자동화된 테스트 스크립트 작성
• 효과적인 테스트 실행을 위한 테스트 케이스들로 부터의 테스트 슈트(test suite) 작성
• 테스트 환경이 올바르게 설정되었는지의 검증
• 계획된 순서에 따라 수동이나 테스트 실행 도구에 의한 테스트 케이스의 실행
• 테스트 실행의 결과 로깅(logging)과 테스트웨어, 그리고 테스트 도구, 테스트 중인 소프트웨어의 버전과 특성(identities)들을 기록
• 실제 테스트 결과와 예상 테스트 결과의 비교
• 실제 테스트와 예상 테스트 결과 사이의 불일치(discrepancies)를 보고하고, 그 원인을 찾기 위하여 분석한다. (e.g 코드, 특정 테스트 데이터, 테스트 문서안의 결점이나 실행된 테스트 방법 내의 잘못)
• 각각의 불일치에 대하여 취해진 행위의 결과와 같은 테스트 액티비티를 반복한다. 예를 들어, 이전에 실패한(failed) 테스트의 재실행(re-excution)은 잘못을 수정한 것을 확인하기 위한 것이다. (확인 테스트-confirmation test) 정정된 테스트의 실행과/또는 다른 테스트들의 수행은 소프트웨어의 변경되지 않은 부분에는 아직 결점이 나타나지 않았다는 것과 결점을 고친 것이 다른 결점들을 커버 하였다는 것을 확신하기 위해서 진행된다.(회귀테스팅-regression testing)
1.4.4 종료 기준(Exit criteria) 평가와 보고(Reporting)
종료 기준을 평가하는 것은 테스트의 실행이 정해진 목표에 대한 것인지를 평가하는 액티비티이다. 이것은 각각의 테스트 레벨에 대하여 반드시 수행되어져야 한다.
종료 기준을 평가하는 것은 다음의 주요한 작업을 포함한다.
• 테스팅 계획에 정의된 종료 기준에 비교하여 테스트 로그들(logs)을 확인한다.
• 더 많은 테스트가 필요한지, 정의된 종료 기준이 변경되어져야 하는지를 평가한다.
• 이해당사자를 위한 테스트 요약 보고서를 작성한다.
1.5.5 테스트 종료(Test Closure) 액티비티
테스트 종료 액티비티는 경험, 테스트웨어, 실제 사실과 숫자들을 통합하기 위하여 종료된 테스트 액티비티로부터 데이터를 수집한다. 예를 들어, 소프트웨어 시스템이 릴리즈되면, 테스트 프로젝트가 완료되며(또는 취소되며), 목표(milestone)가 성취되었거나 유지보수를 위한 배포가 완료된 것이다.
테스트 종료 액티비티는 다음의 주요한 작업을 가진다.
• 부가적인 사건의 종료 보고서와 오픈된(opened) 상태로 남아 있는 부분에 대하여 일어나는 변경 기록들, 그리고 시스템의 승인에 대한 문서와 같은 계획된 소프트웨어 구성요소들(deliverables)이 전달되었는가 확인한다.
• 테스트웨어, 테슽 환경 그리고 테스트 기반 구조를 정리하고 최종적으로 승인한다.
• 유지보수 조직에 테스트웨어를 이양한다.
• 다음 프로젝트와 릴리즈 그리고 테스트 성숙도의 향상을 위하여 경험으로 배운 사항(lessons learned)을 분석한다.
===========================================================================
* 소프트웨어 업계에서는 일단 제작되어 다른 사람에게 전달되는 소프트웨어 제품 구성요소를 deliverable이라 한다.
* 초기 구상 단계부터 대중에게 출시되기까지 소프트웨어 제품을 만드는 데 사용되는 과정을 소프트웨어 수명주기 모델이라고 한며 가장 많이 사용되는 모델은 다음의 4가지 모델이다.
- 빅뱅 (Big-bang) 모델
- 코딩- 수정(Code-and-Fix) 모델
- 폭포(Waterfall) 모델
- 나선형(Spiral) 모델
◆ Test Plan
▪ Purpose
- Test의 개요를 정의한다.
- 테스트 전략 및 테스트 수행의 개요를 정의한다.
▪ Goal of the Test
- Test의 최종 목표를 정의한다.
▪ Scope of the Test
- 테스트 대상 기능과 비 대상 기능을 정의한다. 해당 기능들은 업무요구 사항 및 기술 요구사항에 정의되어 있어야 한다.
◆ Test Estimation
▪ 예측 방법
- 과거 프로젝트나 유사 프로젝트의 매트릭을 근거로 테스트 업무량(effort) 예측
- 전문가나 테스크의 주체에 의한 예측
▪ 테스팅 업무량에 영향을 주는 요소들
- 제품의 특성 : 테스트 베이스의 품질, 제품 사이즈, 문제 도메인의 복잡성, 신뢰성 및 보안성 요구수준, 문서화 요구수준
- 개발 프로세스 특성 : 조직의 안정성, 사용한 틀, 테스트 프로세스, 관여자들의 스킬 수준, 시간 압박 정도
- 테스팅 결과물 : 결함 수와 요구되는 재작업량
◆ Test approaches
▪ 분석적 접근법 (Analytical approachs) : Risk-based testing
▪ 모델 기반 접근법(Model-based approaches) : Stochastic testing(reliability growth model, operational profiles)
▪ Methodical approaches : Failure based(error guessing, fault-attacks), check-list based, quality characteristic based
▪ Process - or standard-compliant approaches
▪ Dynamic and heuristic approaches
▪ Consultative approaches (by expert advice)
▪ Regression-averse approaches (reuse of existing test materials and automation)
◆ Test Strategies and factors
▪ 테스트 전략은 무엇을 어떻게 테스트하고 어느 정도의 깊이/커버리지로 할 것인지를 결정하는 것으로 리스크 기반 테스트 전략이 대표적이다.
▪ 테스트 전략의 결정 요소로는 Product technology, product criticality, product complexity, component selection 등이 있다.
◆ Risk - 시간과 자원의 한계를 고려
▪ Defect -> Failure -> Risk (*Error - relate to human)
▪ Defect : Failure 원인 (a specific cause of failure) (Related to product)
▪ Failure : 의도된 기능을 수행하지 못한것 (relate to events)
▪ Risk : failure 때문에 주어진 기간에 발생하는 비용
Risk = failure 가능성 * Damage
Chance of Failure = frequency of use * chance of fault
◆ Exhaustive 테스팅 전략
▪ 모든 가능한 경우를 테스팅
▪ 생명 관련 소프트웨어 -> Exhaustive 테스팅 & 안전분석 필요
▪ 안전 분석을 위한 Safety manager와 엔지니어가 있어야 함
◆ Test Environment
▪ 테스트가 수행될 물리적 환경, H/W 환경을 정의한다.
▪ 테스트가 수행될 S/W 환경을 정의한다.
소프트웨어 수명 주기 모델 (참고)
빅뱅 모델 (Big-Bang Model)
우주의 생성을 설명하는 이론 중 하나가 빅뱅이론이다. 수 십억년전 우주는 무한한 에너지로 인한 한 번의 거대한 폭팔로 인해 생성되었다는 것이 이 이론이다. 소프트웨어 개발에서의 빅뱅 모델도 같은 이론을 따른다. 많은 양의 물질(사람과 자본)이 한데 모여 종종 매우 격렬하게 많은 양의 에너지가 소모되고 그 결과 완벽한 소프트웨어 제품이 탄생하거나 혹은 그 반대가 된다.
빅뱅이론의 장점은 간단함이다. 계획, 일정 또는 형식적인 개발 과정이 포함된다면 이 이론의 매력은 반감된다. 모든 노력은 소프트웨어를 개발하고 코드를 작성하는데 사용되어야 한다. 이 방법은 제품의 요구사항이 분명하지 않고 최종 출시 날짜가 변동 가능할 경우에 이상적이다. 고객의 요구사항이 유동적이이어야 한다는 점 역시 중요하다. 마지막 순간까지 어떤 제품이 나올지 모르기 때문이다. 대부분의 빅뱅 모델에서는 형식적인 테스팅이 아예 없거나 거의 이루어지지 않는다. 테스팅 과정이 있는 경우에는 제품이 출시되기전 아주 잠깐 동안만 이루어진다.
코딩-수정 모델 (Coding-Fix Model)
코드-수정 모델은 프로젝팀이 특별히 다른 모델을 사용하려는 노력을 기울이지 않는 한 대개 기본적으로 안주하게 되는 모델이다. 적어도 이 모델에서는 제품의 요구 사항이 무엇인지에 대한 생각을 필요로 한다는 점에서, 절차상으로는 빅뱅 모델보다 한 단계 위에 위치한다. 이 접근 방법을 사용하는 팀은 대개 그들이 원하는 바에 대한 대략적인 아이디어만 가지고 간단한 설계 작업을 하고 코딩, 테스팅, 버그 수정의 단계를 끊임없이 반복한다.
이 모델의 경우 계획과 문서화하는 단계가 거의 없기 때문에 프로젝트 팀은 즉시 결과를 보여줄 수 있다. 이러한 이유로 코딩-수정 모델은 프로토타입, 데모 등 빠른 시간 내에 제작하고 제작이 끝나면 금방 버리도록 계획된 작은 규모의 프로젝트에 매우 적합하다. 하지만 코딩-수정 모델은 규모가 크고 잘 알려진 많은 소프트웨어 제품에 사용되고 있다. 빅뱅 모델과 같이 코딩-수정 모델에서도 테스팅 작업이 특별히 요구되지 않지만 코딩 작업과 수정 작업 사이에 매우 중요한 역할을 담당한다.
폭포수 모델 (Waterfall Model)
이 모델에서 중요한 세가지 사실은
1. 어떤 제품을 만들 것인가를 명확히 해 두는 것이 매우 중요하다. 개발 및 코딩은 제품에 있어 하나의 단계에 지나지 않음을 명심해야 한다.
2. 단계는 분리되어 있고 겹치는 일이 없다.
3. 이전 단계로 되돌아 갈 수 없다. 한 단계에 발을 들여 놓은 다음에는 해당 단계에 대한 작업을 완전히 마무리 지은 후 다음 단계로 이동해야 한다.
나선형 모델 (Spiral Model)
나선형 모델의 기본 아이디어는 처음 시작 단계에서는 모든 세부 사항을 정의 할 수 없다는 것에서 출발한다. 중요한 기능을 정의하여 시도해보고 고객의 의견을 수렴한 후 다음 단계로 이동한다. 나선형 모델은 다음의 단계를 반복한다.
1. 목표, 대안, 장해 요인 결정
2. 위험 요인 확인 및 분석
3. 대안 평가
4. 현재 단계 개발 및 테스트
5. 다음 단계 계획
6. 다음 단계에 대한 접근 방법 결정
참고로 이 모델은 이상향이 아니다.
========================================================================================
◆ Iterative and Incremental Developement & Approach
▪ 점진적으로 효과적인 결과물(해결책)을 산출하기 위해 일련의 활동(Requirement -> Analysis -> Design -> Implmentation -> System Test)을 반복적으로 적용하는 개발 스타일
▪ Interative (반복적인) : 핵심적인 개발 활동을 "리스크(우선순위)"에 따라 반복적/발전적으로 적용하여 결과물/해결책 도출
▪ Incremental (점차적으로 증가하는) : 반복 사이클을 통해 개발이 진행됨에 따라 "문제"에 대한 이해를 높여, 해결능력을 향상시킨다.
◆ Waterfall VS Iterative
▪ Waterfall은 결과물로 수행전까지 문서만 존재하지만 Iterative는 각 Iteration 별 실제 개발
결과물이 존재한다.
▪ Waterfall은 Risk를 프로젝트 중간이후의 코딩 단계까지 가지고 가지만 Iterative는 Risk를 개발 앞단에서 처리
▪ Waterfall은 개발 프로젝트 예측이 어렵지만 Iterative는 개발 프로젝트 예측이 용이하다.
1.5 The psychology of testing
테스팅하고 검토하는 동안의 사고방식과 분석하고 개발하는 동안의 사고방식은 다르다. 올바른 사고를 가진 개발자들이 자신의 코드를 스스로 테스트 할 수 있지만, 각자 맡은 일에 집중할 수 있도록 도와주고 훈련된 전문 테스팅 인력들에 의한 독립적인 관점을 얻을 수 있는 혜택을 더하기 위해서 테스터에게 테스팅 책임을 분리하여 준다. 독자적인 테스팅은 테스팅의 모든 레벨에서 수행될 수 있다.
(저자의 편향을 피하는) 독립적인 어떤 단계는 종종 결점이나 실수를 발견하는데 더 효과적이다. 그러나 독립성은 정통함의 대체수단은 아니며 개발자들은 효과적으로 자신의 코드에서 많은 결점을 발견할 수 있다. 다음과 같이 독립성의 몇가지 레벨이 정의될 수 있다 :
• 테스트중인 소프트웨어를 작성한 사람(들)에 의하여 설계된 테스트 (낮은 수준의 독립성)
• 다른 사람(들)에 의하여 설계된 테스트 (e.g 개발팀에 의해 설계된 테스트)
• 다른 조직이나 그룹의 사람(들)에 의하여 설계된 테스트(e.g 독립적인 테스팅 팀)
• 다른 조직이나 회사의 사람(들)에 의하여 설계된 테스트(e.g 아웃소싱 혹은 외부의 인증)
조직 구성원들은 관리자와 다른 이해당사자들에 의해 설정된 목표에 자신들의 계획(예를들어, 결함 찾기, SW 정상 동작 확인)을 맞추려는 경향이 있다. 따라서 테스팅의 목적을 명확히 하는 것은 중요하다.
테스팅 동안에 실패들을 정의하는 것은 제품이나 저자에 대한 비평으로 인식될 수 있다. 그러므로 테스팅은 비록 제품의 위험 관리에 있어서 매우 건설적이더라도 종종은 파괴적인 액티비티로 보여질 수 있다. 시스템에서 실패를 찾는 것은 호기심, 전문적인 비관론, 비평적인 눈, 세부사항에 관한 관심, 개발자 동료와의 건전한 의사소통, 그리고 기본적인 에러를 추측하는 경험등을 요구한다.
만약, 에러나 결점 혹은 오류들이 건설적인 방법으로 전달된다면, 테스터와 분석가, 설계자와 개발자 사이의 나쁜 감정들을 회피할 수 있다. 이것은 테스팅은 물론 검토(reviewing)에서 적용된다.
테스터와 테스트 리더는 결점, 진보, 그리고 위험에 대한 사실적인 정보를 건설적인 방법으로 전달하기 위한 좋은 대인관계의 스킬이 필요하다. 소프트웨어나 문서의 저자들은 결점에 대한 정보를 통하여 그들의 기술을 향상시킬 수 있다. 테스팅 동안의 결점 발견과 수정은 나중에 들어갈 시간과 비용을 절약해 줄 것이다. 그리고 위험을 줄인다.
만약 테스터들이 결점에 대한 원하지 않는 소식의 전달자로만 보여진다면, 의사소통에 문제가 일어날 수도 있다. 그렇지만, 다른 사람과 테스터 사이의 의 사소통과 관계를 향상시키는 몇가지 방법이 있다.
• 전투보다는 협력으로 시작하라 - 모두의 공통적인 목적은 더 좋은 품질의 시스템인 것을 생각하라
• 제품을 생산한 사람에 대하여 비판하는 것없이 제품에 대한 발견사항을 중립적이고 사실에 중점을 둔 방법으로 전달하다. 예를 들어, 객관적이고 실질적인 사건 보고서와 발견 사항에 대한 검토 보고서를 작성하라.
• 다른 사람이 어떻게 느끼는지와 왜 그들이 그렇게 반응하는가를 이해하려고 노력하라.
• 다른 사람이 당신이 말한 것을 이해했는지를 확인하라 그리고 반대 상황도 마찬가지이다.
===========================================================================
테스터의 역할은 동료의 작업을 비판하고 문제점을 찾아낸 다음에 공개하는 일이다. 다음은 테스터가 동료와 잘 지낼수 있는 몇가지 TIP이다.
1. 버그를 일찍 발견하라.
- 테스터의 당연한 의무이긴 하지만, 이 규칙을 지키도록 노력해야 한다. 예정된 제품 출시 몇 달 전에 버그를 찾아내는 것이 출시 일주일 전에 버그를 발견하는 것보다 개발 팀이 받는 타격이 줄어들며, 테스터에게 우호적일 것이다.
2. 지나친 의욕은 금물이다.
- 대단한 버그를 찾아내면 열광하는 것은 당연하다. 하지만 테스터가 프로그래머에게 가서 히죽 히죽 웃으면서 그가 작성한 코드 중에 테스터로서 가장 끔직한 버그를 찾았다고 말하는 것은 원만한 인간 관계를 유지하기 위한 길은 아니다.
3. 나쁜 소식만 전해서는 안된다.
- 테스트 중 버그가 없는 부분이 있다면 모두에게 말하라. 나쁜 소식만을 전하는 사람이 된다면 모두들 대화 자체를 기피할 수 있다.
