ATDD와 TDD를 활용한 개발이란 게 내용을 보니 SW Process에 의한 개발 조직에서 이미 기존에 하는 것들이고 별 특별한 내용은 아닌거 같습니다. 요구사양 정의 이후에 개발 쪽에서는 상위설계-상세설계-구현으로 이어질 때, Q/A Test 조직에서는 Test 항목정의-Test Case 도출-(Code 구현완료를 전제로)Test 수행...과 같은 단계를 병렬적으로 수행하도록 되어있습니다. 이는 제가 경험한 회사(대기업입니다.)에서 이미 10여년 전에 표준으로 구축하고 그대로 시행해 온 개발 방법론의 방식입니다.

윗 글에서 "전통적인 개발 방식에서는 소스 코드를 먼저 작성하고 나중에 이를 테스트하는 테스트케이스를 작성해서 테스트 통과 여부를 확인한다."라고 언급했는데 언급한 전통적인 개발 방식이 무엇을 지칭하는지는 잘 모르겠지만, 제가 아는 전통적인 SW Process는 Test Case를 먼저 작성하고 나서 Source Code를 작성하는 것입니다.

다만 여기서 혼동하지 말아야 할 것은... SW 개발과 Q/A를 병렬적인 Process로 진행하기 어려운 조직이 있는 이유는, 그것이 전통적이어서가 아니라 인력 부족때문입니다. 인력이 부족하면 병렬적으로 빠르게 진행해야 할 일을 직렬로 진행할 수밖에 없으며 이런 경우는 원칙의 시각에서 중요한 일이 아닌 조직 Performance 측면의 우선순위적 시각에서 일을 수행하게 되는 것이 조직의 살기 위한 본능입니다. 인력이 부족하나 제품은 출시해야겠고... 등등의 상황이 이유가 되어서 SW를 구현부터 해놓고 나서 남는 시간에 Test를 하느라 Case를 작성하고 해왔던 것입니다.

정리하자면 이론은 이론대로, 현실은 현실대로 비교하고 분석해야지 이론과 현실을 오락가락하며 논리를 펴면 엉뚱한 결론이 나올 수가 있습니다. 뭔가하면 새로운 방법론의 필요성이란 것을 주장하려면 Process적 요구방향과 개발 실무의 현실을 구분해서 그 차이점을 중심으로 논리를 가져가야 한다는 것이 제 생각입니다. 인력이 부족한 현실에서 빚어진 문제가 곧 전통적인 Process를 의미하는 것은 아닐테니까요.

별거 아닌 배경적인 내용을 가지고 뭐 피곤하게 따지는가...라고 할지 모르지만 이것은 중요합니다. 제안하는 신기술(?)의 필요성을 주장하는 사람이 그 필요한 논리를 얼마나 정확하게 이해하고 있는가가 바로 이런 배경 논리에 있기 때문입니다.

따라서 ATDD와 TDD에서 주장하려는 중요한 기본 Concept는...
조직적인 SW Process 표준에 의한 개발 수행이 원칙인 조직에서는 이미 있는 내용이며 새로운 철학이 아닙니다. 이미 있는 내용을 가지고 ATDD, TDD와 같은 그럴싸한 이름을 부여하는 것을 어떤 시각으로 봐야 할지요? 글세요...
제가 보기엔 마케팅적인 접근 그 이상으로 보이지는 않습니다.

실무 상 프로세스 정립은 필요하고, 이론의 타당성을 생각한다면 기존에 알고 내용이라도 본 기고와 같이 체계적인 정리는 필요하다고 봅니다. 이미 알고 있어도 시도조차 안하고 있는게 얼마나 많은지 말입니다..이제 테스팅 분야도 혼자만 알거나 머리속으로만 정리된 것들을 공유하면서 업그레이드 할 필요가 있는거죠. 사실- 개발이나 다른 분야를 보더라도 이미 알고 있는 이론이나 실무가지고 써먹는게(응용 or 업그레이드) 얼마나 많은지 안다면 말이죠

감사합니다.

호시탐탐님의 글이 제 글에 대한 답인지는 잘 모르겠으나... 만일 그렇다라고 한다면, 제 주장의 관점을 잘못 이해하신 것이 아닌가 합니다. 제 글에 대한 답이 아니라면 상관은 없지만... 저의 주장은 Process의 근간이 되는 방법론적인 고찰에서 볼때 첨부 글의 내용의 부적합한 부분을 지적한 것입니다. 즉, 전통적인 Engineering 개념의 시각으로 본 제 생각이 그렇다는 것입니다. 알고 있는데 실천하지 않는 다는 것은 Engineering적 관점이 아닌 Practical 관점에서 보야야 할 또 다른 이야기라 제 주장과는 다소 거리가 있는 이야기입니다. 뭐, 제 주장에 대한 답이 아니라면 이 글 모두 무시해도 되구요...