성공.

우리는 대부분 성공 하는 법을 연구합니다.

실패하지 않고 일을 성공 하는 방법.

빠르게 일을 성공 하는 방법.

어떤 작업을 완성 하기 위해서 우리는 여러가지 방법론을 배우고, 연구하고, 도전 합니다.

하지만 여기에 '실패' 를 하는 방법이 있습니다.

시작은 실패 부터 시작합니다.

성공하는 방법을 찾는게 아니라 실패 하는 방법을 찾아서 실패를 합니다.

가령 수수깡으로 탑을 쌓는 것입니다.

우선 수수깡이 없는 부분에서 시작 합니다.

재료가 없으므로 실패를 합니다.

재료를 준비 하면 1개의 실패가 성공으로 바뀌고 다음 실패를 찾습니다.

우선 쌓습니다. 

고정하는 핀이 없으니 무너집니다.

실패 합니다.

다시 고정 하는 핀을 찾습니다.

이렇게 일일히 하나씩 실패 요소를 찾아서 실패를 하고, 이를 보안 합니다.

이 방법은 결코 당신에게 빠르게 일을 성공 시켜주지 않습니다.

대단히 느린 방법입니다.

그럼에도 우리는 맹렬히 실패를 합니다.

이러한 방식으로 개발 하는 방법을 우리는 TDD (Test Driven Development ) 테스트 주도 개발 방법  이라고 부릅니다.

많이 들어본 이 TDD를 실제로 사용 하는 사람은 극히 드뭅니다.

특히 주어진 일정이 존재하고, 그 시간이 짦은 경우에는 도입이 매우 어렵습니다.

다시 반복 하지만 이 방법은 결코 빠르게 완성 시켜주지 않습니다.

최하 10~30%이상 더 느리며, 2배 이상 느릴수도 있습니다.

그럼에도 이 방법에는 뚜렷한 장점이 존재합니다.

유닛별로 실패하는 방법과 성공하는 방법을 넣기 때문에, 해당 코드를 몰라도 인수인계가 수월해집니다.

복잡한 로직을 거쳐서 마지막에 1인지 0인지으로 구분한다면 우리는 먼저 복잡한 로직부터 확인해야만 합니다. 복잡한 로직을 건너뛰고 1을 넣으면 성공이고 0을 넣으면 실패 하는 함수이라면 누가 봐도 무엇이 들어가야 하는지 알수 있습니다.

이 개발 방법은 느리지만,  유지보수에서는 뚜렷하게 장점으로 다가옵니다.

복잡도를 건너뛰고 테스트가 용이하고, 자동화로 각각의 유닛이 정상인지 아닌지를 판별해서 잘못된 부분만 찾아서 수정해 주면 됩니다.

세상에는 성공 하기위해 실패하지 않는 방법을 찾지만, 이 방법은 실패를 찾아야 성공 합니다.

불확실한 일을 안정적으로 끝을 내고 싶으신가요?

그럼 우선 실패 하는 방법부터 찾아보십시오.

먼저 실패하면 실패하는 방법이 줄어들고 남는건 성공 뿐입니다.