1. Pre-engagement Interactions

Basic/Application

1. Pre-engagement Interactions

LimSeongHyeon 2025. 8. 1. 13:36

본 게시물 PTES(http://www.pentest-standard.org)의 내용을 기반으로 작성됩니다.

The Penetration Testing Execution Standard

High Level Organization of the Standard The penetration testing execution standard consists of seven (7) main sections. These cover everything related to a penetration test - from the initial communication and reasoning behind a pentest, through the intell

www.pentest-standard.org

Preview

실제 테스트 시작 전 모든 사항을 명확히 정의하고 계약을 수립하는 단계이다. 계약 내용에 내포되어야 할 사항들과 고려해야할 사항들을 PTES에서 명시해주고 있다. 해당 항목들은 세계에서 가장 성공적인 침투 테스터들의 수년간 경험을 결합한 결과라고 한다.

Introduction to Scope

네트워크 접근을 위한 다양한 도구와 기법에 대해서는 정말 많은 자료들이 존재한다. 하지만 침투 테스트 이전 단계인 Preparation 에 대한 내용은 거의 찾아볼수가 없다. 이 사전 준비 활동을 제대로 완료하지 않으면 Scope Creep (범위가 계속 확장되는 문제), 목적 및 기대치 불일치에 대한 고객 불만족, 허가받지 않은 영역에 대한 테스트로 인한 법적 문제와 같은 문제를 발생시킬 수 있다.

Scope를 정의하는 것은 결국 "무엇을"테스트 할 것인가를 정의하는 것이다. 가령 내가 Scope에 정의되지 않은 영역을 테스트했는데 실제 장비들이 오동작을 일으키는 문제를 범했다. 그런데 그 장비들이 의료장비라고 생각해보자. 법적 문제를 회피할 수 도, 감당할 수 도 없을 것이다. 결국 불미스러운 상황에 대해 테스터와 고객의 책임소지를 명확히 하는 장치 중 하나가 될 것이다.

Scope에 대해 테스터들이 어떻게 시간을 분배하고 사용하는지 작성되어야 한다. 침투 테스트는 본질적으로 시간 기반 서비스이다. 무작정 테스트 하는 것이 아니라 어떤 스코프에 얼만큼의 시간을 배분할 것인지 명시되어야 한다. 하지만 결코 시간으로만 비용 측정이 불가능한 상황도 존재한다. 때문에 단위 가격에 대한 설정이 존재해야 한다.

예를들어 고객이 100개의 IP주소를 1,000만원의 가격으로 테스트 해달라고 요청한다면 결국 IP 주소 하나당 10만원을 제공한다는 의미이다. 절대적으로 1개의 IP 주소에 대한 노동력이 모두 동일할 순 없지만, 이런 단위체계가 존재해야 고객과 공급자 모두에게 명확한 가격 구조를 형성하게 될 것이다.

그럼 이러한 의문을 갖게 될 것이다. "아무리 명확한 가격 구조를 형성하게 된다해도 특정 IP에 들어있는 서비스의 복잡도가 매우 높으면 작업량이 너무 달라지는 것 아닌가?". 이런 의심처럼 Scope에 대한 선형적인 가격 측정은 특정 Volume에 대해서만 효과적이다. 특정 지표가 결코 작업량을 대체하는 단위가 될 수 없다. 이런 단위 불일치는 결국 이 서비스에 대해 저가 책정하게 되고, 불완전한 작업을 하게하는 동기를 유발한다.

이때 이러한 비즈니스에서 발생할 수 있는 문제점은 "고객이 이 Scope 책정에 대해 납득할 수 있는가?"이다. 테스터들은 같은 IP여도 복잡도와 작업량이 크게 달라진다는 것을 인지한다. 심지어 어떤 작업에서는 기하급수적인 작업량이 필요해짐도 유추할 것이다. 하지만 과연 고객도 그렇게 생각할 수 있을까?. 사실상 이러한 기술적 지식 차이로 인한 의사소통 문제를 해결하기 위해 컨설턴트가 존재한다고 생각한다. 그리고 이 소통에 대한 이해를 바탕으로 문서가 작성되어져야 하는 것이다.

다시 돌아와서 이 모든 내용을 정리하자면, 모의 침투는 자선 사업이 아니다. Scope를 커버하기 위해서는 노동력이 필요하고 이는 곧 가격이된다. 그럼 이 Scope를 어떻게 정의해야 하는가? 선형적인 단위만으론 측정할 수 없고 각 항목에 대한 좀 더 자세한 복잡도로 인한 노동력 산출 작업이 필요하다. 하지만 고객은 이러한 복잡도 산출에 대해서 이해하지 못할 수 있다. 때문에 이를 이해시키고 가이드 해주는 것이 결국 테스터의 일 중 하나이기도 하다. 이 때 테스터는 Deep dive와 Wide Scan 사이에서 고객의 목적에 맞는 Scope를 설정하고 계약 과정에서 이 사실을 망각하지 않아야 한다.

Metrics for Time Estimation

이제 위에서 범위를 산출했다면 해당 범위들을 테스트하기 위한 시간을 정해야 한다. 경험이 많은 테스터라면 직감적으로 얼마나 오래 걸릴지 판단할 수 있겠지만, 그렇지 않다면 이전에 수행한 유사항 테스트의 이메일이나 스캔 로그들을 검토하고 시간 요구사항을 추정하는 것이 좋다. 이 때 반드시 추정시간 안에 끝낼 수 있으리란 보장이 없기 때문에 20% 정도를 패딩(Padding)한다.

패딩은 모든 테스트에 절대적으로 필요하다. 테스팅 과정에서 방해가 발생할 경우를 대비한 완충 역할을 한다.예를들어, 네트워크에서 중대한 취약점이 발견되어 이를 해결하기 위해 여러 권한자와 회의가 필요할 수 있다. 테스터의 업무적 의지와는 별개로 많은 시간을 소모할 수 있다는 의미이다. 이로 인해 반드시 패딩을 추가하여 예상치 못한 사항에 대해 완충할 수 있도록 하여야 한다.

하지만 패딩된 시간으로 넘어가지 않고 산출했던 시간안에 모든 분석이 끝나게 되면 어떻게 해야할까?. 고객은 패딩된 시간적 금액까지 금전적으로 지불하게 된다. 만약 패딩된 시간을 사용하지 않는다면 고객은 아무것도 제공되지 않는 시간에 대한 비용을 지불한 셈이 된다. 때문에 보안팀 혹은 개발팀에게 악용하기 위해 취한 단계를 설명해준다던가, 원래 제공 목록에 포함되지 않았던 경영진 요약 보고서를 작성해준다던가, 스코프 내에서 부가적인 취약점들을 해결하려고 시간을 더 사용한다던가 등의 추가적인 가치를 제공하는 것 까지가 테스터들의 몫이다.

마지막으로 모든 프로젝트에는 명확한 마감일이 있어야 한다. 테스팅이 종료되는 날짜에 도달 했거나, 그 날짜를 넘겨 추가 테스팅이나 작업이 필요한 경우에 반드시 작업과 소요 시간 그리고 서명된 작업 명세서가 있어야 한다. 일부 테스터들은 고객에게 추가 비용을 요구하면 돈에 너무 집착하는 사람으로 보일까 걱정하고 이로인해 추가적인 계약서를 작성을 요구하길 꺼려한다. 하지만 pentest-standard의 저자에 의하면 경험상 주요 테스트에서 좋은 가치를 제공한다면 고객은 비용 지불을 거부하지 않을테니 걱정할 필요가 없다고 한다.

Scoping Meeting

범위 설정 회의는 대부분 계약서를 체결한 후에 열리게 된다. 범위와 관련된 내용들 자체가 고객의 비밀이고 법적 문제가 발생할 소지가 있기 때문이다. 때문에 불가피하게 범위 설정 회의를 먼저 진행해야 한다면 비밀유지협정(NDA)을 체결하는 것이 중요하다.

다시 돌아와서, 범위 설정 회의의 목적은 "무엇을 테스트 할 것인가?"이다. 지금까지도 무엇(What)에 대해 이야기 해놓고 이게 또 무슨 소린가 싶다. 여기서 중요한건 테스트 수행 규칙이나 비용에 대한 이야기는 해당 회의에서 다루지 않는다. 온전히 범위에 대한 이야기만 다루고, 나머지에 대한 금액적, 수행 규칙에 대한 내용은 별도로 논의하는것이 바람직 하다. 여러 주제를 함께 논의하면 이 범위 설정에 대한 핀트가 혼돈이 생길 수 있기 때문이다.

프로젝트의 대략적인 규모(ROM)가 정해졌으면 고객과 만나서 시스템의 구조들에 대해 세운 가정들이 맞는지 확인해야 한다. 특히 중요한 사항은 어떤 IP 대역이 테스트 범위에 포함되는지 명확히 해야한다. 간혹 고객들은 테스트를 현실적으로 만들기 위해 "테스터가 알아서 알아내고, 알아서 침투해야죠"라는 태도로 말하기도 한다. 물론 그렇게 하면 이상적이지만 그럴수 없는 이유가 크게 두가지가 있다.

하나는 법적 책임이다. 범위를 정하지 않고 침투함으로써 실제 서비스에 큰 문제가 생기게 된다면 테스터는 면책을 증명할 방법이 없다. 말을 그렇게 했으나 서면으로 작성되어 있는 사항이 아니니 고객이 "그렇게까지 할거라고 이야기 하지 않았잖아요!"라고 하면 책임을 피할 방법이 없는 것이다. 특히 개발자나 엔지니어에게 자신의 설계에 문제가 있음이 커리어에 크게 문제되거나 책임을 피하지 못할거라는 생각 때문에 비협조적인 경우도 있다. 때문에 범위를 규정한 내용의 계약서는 테스터를 보호하기 위한 가장 효력있는 수단이 될 것이다.

하나는 시간도 자원이라는 점이다. 실제 해커들은 이런 계약 관계처럼 시간을 지정하고 행하지 않는다. 만약 몇 년을 걸쳐 취약점 분석을 진행할 대규모 프로젝트이고, 그만큼 금전적인 보상도 충분히 이루어 진다면 당연히 문제되지 않을 것이다. 하지만 대부분 그렇지 않다. 테스터는 실제 해커보다 훨씬 제한된 시간 안에 최대한 많은 취약점들을 찾아야 한다. 대상 시스템이 어느 나라에서 운영되고 있고, 백업 서버는 어디에 몇개가 있고, 실제 하드웨어와 방화벽, IDS, IPS 솔루션은 어떤걸 소유하고 운용중이고, 각 관리자 마다 접근할 수 있는 범위는 어디까지이고, 실제 코드 백업 전략은 어떤 것을 사용하고 있고 등등 모든것을 확인하기에는 시간이 너무 오래 걸릴 것이다.

결국 테스터와 고객 모두 "레드티밍"인지 "모의해킹"인지 구분을 명확히하여 범위를 지정해야 된다는 말이다. 대다수의 외부 테스터에게 의뢰하는 내용이 레드 티밍일 확률이 적다. 고객이 이러한 구분히 명확할 확률이 낮기에 테스터는 이를 이해시키고, 함께 범위를 지정해야 한다. 결국 고객은 금전적인 비용을 지불하고 테스트를 받는 것이기 때문에 이 비용이 아깝지 않게 테스터에게 범위를 지정하고 필요하다면 권한에 대한 부분도 고려해야 한다. 동시에 테스터는 이 범위 지정으로 인해 법적 책임으로부터 자유로워 질 수 있다.

Additional Support Based on Hourly Rate

테스터가 과연 고객과 모든 업무 범위에 대해서 빠짐없이 서면으로 규정할 수 있을까? 모든일이 그렇듯 당연히 불가능 할 것이다. 언제나 항상 예외가 발생할 것을 염두해 두어야 한다. 이 파트에선 왜 임의로 테스트를 하면 안되는지에 대한 두 가지 이유와 그럼 어떻게 해야할지를 살펴보자.

첫번째 이유는 범위 확장(Scope Creep) 때문이다. 위에서도 언급했지만, 범위가 확장되면 자원이 소모되어 테스터의 수익을 깎게되고 이러한 부정적인 동기가 결과물에 영향을 줄 가능성이 높다. 이로 인해 고객은 결과에 대해 불만족할 확률이 높아진다. 결국 테스팅도 하나의 비즈니스이기 때문에 고객 만족도를 관리할 필요가 있다. 이런 부정적인 동기부여는 사실상 고객 만족도도 비즈니스 평판도 깎아내리는데 일조할 것이다.

두번째 이유는 법적 책임이다. 많은 임시 요청들이 제대로 문서화 되지 않아 법적 분쟁이나 조치에 대해서 정당성을 입증하기 굉장히 곤란스러운 상황에 처하곤 한다. 누가 무엇을 말했고, 어떤것을 요구했고 받아들여 졌는지 그 무엇도 입증할 수 없다. 더군다나 계약서에는 수행할 작업을 명시하는 법적 문서이자 허가증이다. 객관적으로 이런 상황에서 테스터의 손을 들어줄 확률이 매우 낮아지게 된다.

사실 위 스코프 설정에 관한 이야기에 포함된 내용이기도 하고 계속 반복되는 느낌이 있지만 사실 굉장히 중요하다. 우리는 윤리적인 테스트를 하는 사람들이지 일방적인 수사를 하는 사람들이 아니다. 때문에 원래 범위를 벗어나는 모든 요청을 수행할 작업들을 명확하게 식별할 수 있도록 작업명세서(SOW) 형태로 문서화 해야하고, 추가 작업 또한 시간당 고정 요금으로 진행하여 상호간의 서명 없이는 추가 작업을 진행할 수 없음을 계약서에 반드시 명시해야한다.

고객이 "하는김에 이것도 조금 봐주시면 안될까요?"하는 요청들을 좋은 마음에 문서화 없이 넘어가서는 절대 안된다는 말이다.

Questionnaries

이제 테스터가 고객의 요구사항을 파악하기 위해 해야할 질문(질문 내용이 아닌 질문하는 행위 그 자체)에 대해 다뤄보려고 한다. 많은 테스터들이 기술적인 부분에 집중하여 이 단계를 소홀히 하곤 한다. 하지만 이 질문들이 고객이 원하는 목표를 명확하게 할 수 있는 유일한 방법이다.

고객과의 첫 미팅에서 던져야 할 핵심 질문들이 있다. 단순히 체크리스트를 채우는 것이 아니라 고객의 진짜 의도를 파악하기 위해서 말이다. "침투 테스트를 왜 하려고 하시나요?"라는 질문 하나로 프로젝트의 방향이 어느정도 정해지게 된다. 컴플라이언스 때문에 어쩔 수 없이 하는 고객도 있을 것이고, 실제로 시스템들이 얼마나 안전한지 확인하고 싶은 고객도 있을 것이다. 같은 침투 테스트도 이 두 목적은 전혀 다른 접근 방식을 요구한다.

만약 "컴플라이언스 만족"을 위해서라면 체크박스를 채우는 형식적인 테스트가 될 가능성이 높다. 하지만, "실제로 얼마나 안전한지"를 확인하기 위해서라면 좀 더 깊이 있고 실질적인 보안 검토가 필요할 것이다. 테스터 입장에서도 같은 시간과 노력을 투입하더라도 이러한 방향성에 따라 시간 분배를 달리 해야하고 이로인해 결과의 질이 달라질 수 밖에 없다.

여기서 주의할 점은 고객 스스로도 자신이 정확히 어떤 테스트를 해야할지 모르는 경우가 많다는 것이다. "그냥 해킹 당하는지 확인해주세요."와 같은 말을 하는 고객이 많다는 이야기이다. 때문에 이러한 장르를 결정할 수 있도록 테스터는 컨설턴트의 입장에서 접근해야 한다. 네트워크 침투 테스트를 원하는건지, 웹 애플리케이션 테스트를 원하는건지, 물리적 보안까지 포함한 종합 테스트를 원하는건지 말이다.

질문은 결국 소통의 도구이다. 기술적 전문성도 물론 중요하다. 하지만 고객이 진짜 필요로 하는 것이 무엇인지, 혹시 고객이 자신의 목적을 잘 모르고 있는 것은 아닌지에 대해 확인하고, 설명하고, 솔루션을 제시할 수 있는 자세가 필요하다. 그리고 그것을 빠짐없이 확인하기 위해 이러한 질문하는 시간이 필요한 것이다.

General Questions

그럼 질문하는 행위가 중요하다는 것을 알았으니 이번에는 그럼 구체적으로 어떤 질문들이 왜 필요한지에 대해서 다뤄보려고 한다. 모든 질문들은 PTES의 General Questions에서 확인이 가능하다. 이번 색션에서는 모든 질문을 다루는 것은 아니고 특히 필요한 내용만 다루도록 한다.

"언제 테스트를 하시겠습니까?"

이 질문은 당연해 보이지만 여기에 사실 꽤나 많은 인과가 담겨있다. 업무 시간중에 하면 실제 운영 환경에서의 반응을 확인할 수 있지만, 서비스에 영향을 줄 위험이 있다. 반면, 업무 시간 외에 하면 안전하지만 평상시와 다른 환경에서 테스트를 하게된다. 특히 금융권이나 의료 시설 같은 곳에서 이러한 문제가 생긴다고 생각해보자. 평범한 손해에서 그치지 않을 것이다. 그럼, 그 책임을 누가 질 것인가?. 때문에 이러한 사실을 사전에 확인할 필요가 있다.

"방화벽, IDS/IPS, WAF, 로드 벨런서와 같이 침투 테스트 결과에 영향을 줄 장비가 있습니까?"

앞서 침투 테스트는 시간 기반의 서비스임을 설명했었다. 이러한 침투 테스트에 대한 결과에 영향을 주는 장비가 있는데 이를 모르고 테스트를 시도한다고 생각해보자. 끝없는 시행착오를 반복하며 해당 장비들이 있는지 없는지를 확인하는 행위에 굉장히 많은 시간을 쏟아야 할 것이다. 정해진 기한동안 정해진 비용으로 테스트를 진행하는데 해당 행위에서 시간을 낭비하게 된다면 고객도 테스터도 손해인 상황이 발생하게 되는 것이다. 때문에 사전에 이러한 장비들이 있는지 확인할 필요가 있다. 그리고 전달받지 못한 장비들로 인하여 지연이 발생할 수 있음을 사전에 고지해야 한다.

"소스코드나 시스템에 대한 문서 제공이 가능합니까?"

어떻게 보면 위 질문에 가장 좋은 케이스가 될 수 있는 질문이다. 잘 정리된 소스코드나 시스템에 대해서 제공받으면 테스터는 해당 내용을 파악하는 시간을 획기적으로 줄일 수 있다. 이 말은 테스터가 자원 식별 및 분석하는 시간을 아끼고 취약점 분석에 많은 시간을 투자할 수 있음을 의미한다.

이러한 자원을 받아서 테스트를 진행하는 것이 반드시 옳은 방법은 아니다. 특정 상황에서는 내부 구조를 알지 못하고 테스트를 진행하는 것이 목적에 맞을 수 있다. 하지만, "줄 수 있지만, 의도적으로 목적을 위해 주지 않는 것"과, "주는 것이 좋은 결과를 만들지만, (유출 등과 같은 이유로)찝찝해서 주지 않는 것"은 전혀 다른 결과를 가져온다는 말이다. 고객에게 이러한 장단점을 잘 이해시키고 좋은 결정을 하도록 만드는 것도 결국 테스터의 몫이다.

"어디까지 확인이 필요하십니까?"

쉘을 획득했을 때 root 권한까지 획득할 것인가?, 패스워드와 같은 해시값을 발견하면 키크랙을 시도할 것인가?, 데이터베이스 접근이 확인되면 데이터베이스 조작 및 권한 획득도 가능한지 확인할 것인가?와 같이 침투 테스트의 상한선을 지정할 필요가 있다. 또한 퍼징이나 DoS와 같은 시스템 부하가 발생할 수 있는 작업들을 허용할 것인지에 대해서도 논의가 이루어져야 한다. 지금까지 이야기와 마찬가지로 논의되지 않고 임의로 시도했을때 책임 소지는 온전히 테스터에게 있으므로 반드시 논의되어야 하는 내용이다.

결국 이런 질문들은 단순 정보 수집이 아니라 "고객과 테스터간 기대치 조율", "고객과 테스터간 지켜야할 법적 증거를 만드는 지표", "테스터가 테스트 해야할 방향성"을 제공해주는 지표가 되는 것이다.

Scope Creep

PTES에선 범위 확장(Scope Creep)은 침투 테스팅 회사를 파산시키는 가장 효율적인 방법 중 하나라고 표현하고 있다. 많은 회사와 관리자들이 이를 식별하는 방법이나 발생했을 때 어떻게 대응해야 하는지에 대해 대부분 모르고 있다.

"이것도 한 번 봐주시면 안될까요?" 이런 말을 듣다 보면 어느새 원래 계약보다 두 배, 세 배의 작업을 하고있게 된다는 것이다. 고객이 추가 작업을 요청하는 것은 사실 좋은 신호다. 해당 작업에 만족하고 서비스를 더 받고싶다는 의미이기 때문이다. 하지만 여기서 "서비스 정신"을 발휘해서 "그 정도는 그냥 해드릴게요"라고 하는 순간 당연한 서비스가 된다는 것이다. 특히 한국의 비즈니스 문화에서는 이런 일들이 많이 발생한다는 것이다.

여기서 딜레마는 기존 고객과의 관계는 정말 소중하다는 것이다. 새로운 고객을 들이기 위해서는 영업 비용, 제안서 작성 비용, 신뢰 구축 등 많은 시간적, 금전적 자원이 들어가게 되는 것이다. 그럼 어떻게 기존 고객과 유대감을 유지하며 이러한 범위 확장을 막을 수 있을까?

가장 근본적이게도 처음부터 명확하게 선을 긋는 것이다. 기존 범위에 포함되지 않는 작업이기 때문에 추가적인 보상을 요구해야 한다는 의미이다. 다만, 기존 고객에 대해서는 가격을 낮게 유지하는 것이 좋다. 기존 고객에 대한 작업으로 나오는 소스들은 새로운 고객을 유치할 수 있는 가장 좋은 자료가 될 뿐더러 이러한 좋은 결과물로 반복적인 비즈니스를 산출할 수 있을 것이다.

아마 대부분 이런 경험이 있을 것이다. 가족들과 함께 계곡에서 행복한 추억을 만들기 위해 추억을 쌓고 밥을 먹으려는데 음식의 가격이 부당하게 비싸다고 느껴진 경험 말이다. 계곡에 다시 가고 싶은가? 계곡에 간 근본적인 이유는 놀며 행복한 추억을 만들기 위함이였고 그 목적을 달성 했다. 그럼에도 불구하고 음식점 가격이 높아 다음엔 가고 싶지 않아진다. 좋은 상황을 이용해 폭리를 취하게 된다면 반복 비즈니스를 무너뜨리는 계기가 될 것이다. 우리는 어떤 음식점이 되어야 하는가?

Specify Start and End Dates

범위 확장을 방지하는 다른 중요 요소는 시작일과 종료일을 명시적으로 지정하는 것이다. 프로젝트가 명확한 끝을 가질 수 있어야 한다. 그럼에도 불구하고 일자 조정이 어려운 흔한 이유가 뭘까? 흔히 실수하는 항목이 재테스트 기간이다. 재테스트는 계약 시 좋은 조건처럼 느껴진다. "취약점을 발견하고 조치하시게 되면 재테스트 해드리겠습니다."라고 자신 있게 말하면 책임감 있는 회사처럼 생각하게 될 것이고, 새로운 고객을 확보하는데 많은 도움이 될거라고 생각한다. 혹은 테스팅 회사가 제안하지 않더라도 고객이 이러한 제안을 먼저 할 수도 있다. 이러한 재테스트가 왜 문제인지 생각해볼 필요가 있다.

고객에게 테스팅을 진행한 후 확인된 취약점을 알려 주었다. 고객이 취약점을 받아 패치를 하는데 2주가 걸렸다. 그래서 재테스트를 했더니 문제가 발견됐다. 고객이 취약점을 받아 패치를 하는데 2주가 걸렸다. 그래서 재테스트를 했더니 문제가 발견됐다... 당신은 재귀함수 이야기를 아는가?

어느 한 컴퓨터공학과 학생이 유명한 교수님을 찾아가 물었다. "재귀함수가 뭔가요?"

"옛날 옛날 한 산 꼭대기에 이 세상 모든 지식을 통달한 선인이 있었어. 마을 사람들은 모구 그 선인에게 수많은 질문을 했고, 모두 지혜롭게 대답해 주었지. 그의 답은 대부분 옳았다고 하네. 그런데 어느 날, 그 선인에게 한 선비가 찾아와서 물었어"

"재귀함수가 뭔가요?"

"옛날 옛날 한 산 꼭대기에 이 세상 모든 지식을 통달한 선인이 있었어. 마을 사람들은 모구 그 선인에게 수많은 질문을 했고, 모두 지혜롭게 대답해 주었지. 그의 답은 대부분 옳았다고 하네. 그런데 어느 날, 그 선인에게 한 선비가 찾아와서 물었어"

이래도 당신은 재테스트를 무료로 제공할 것인가? 결국 명확한 시작일과 종료일을 정하는 것은 우리 자신을 보호하는 일이다. 동시에 고객에게도 명확한 기대치를 제공하는 일이기도 하다. "언제 테스트가 끝나나요?"에 대한 답을 명확히 할 수 있어야 함과 동시에 달콤해보이는 조건에 현혹되어 재귀함수에 빠지지 않아야 한다는 말이다. 재테스트는 서비스가 아닌 별도의 프로젝트임을 명심해야 한다.