ZDNet 기사에 대한 사과 및 칼 포터의 반증주의

[성진이아빠]

안녕하세요? ZDNet에 기사를 올렸던 이종국이라고 합니다.
먼저 죄송하다는 말씀을 드립니다.
제가 원래는 기사를 15페이지 정도를 올렸는데 ZDNet의 요청으로 4페이지로 대폭 축소하는 바람에 내용에 오해가 있었던것 같습
니다.

제가 의도했던 것은 Agile 특히 TDD가 성공적으로 적용되는 이유는 심리학이나 인지과학 측면에서 분석해 보는 것이었습니다.
그 일환으로 칼 포퍼의 반증주의와 TDD의 연관성에 대해 글을 작성했습니다.

포퍼는 과학이 성공을 거둘 수 있었던 것이 엄밀한 검증 내지 반증을 거쳤기 때문이라고 주장합니다. 그리고 어떤 가설도 실험적으
로 확인이 안되면 가차없이 버려야 한다고 주장합니다. TDD도 유사하다고 생각합니다. 테스트 케이스를 만들때 우선 요구사항을
정형화 해서 테스트 케이스로 만들죠. 그리고 그 테스트 케이스를 통과하는 프로그램을 작성합니다. 만일 테스트를 통과하지 못하면
그 프로그램은 수정이 불가피합니다. 여기서 제가 고민한 것이 개발자라면 충분히 기교를 부려서 프로그램을 적게 수정하고 테스트는
통과하게 만들 수 있다는 것입니다. 저도 과거에 그렇게 했으니까요.
그렇게 되면 테스트케이스를 만드는 의미가 없어집니다. 과학사에서도 이런 일이 있었습니다. 실험을 통과하지 못하자 과학자가 내세
운 가설에 새로운 가설(이런것을 ad hoc 가설이라고 합니다.)을 넣어서 자신이 주장이 아무 문제가 없다고 주장합니다. 포퍼
는 이런 폐단을 막기 위해서는 어떤 가설도 실험을 통과하지 못하면 가혹하게 버려야 한다고 했습니다. 프로그램도 마찬가지고 처음
에 프로그램의 구조가 잡히고 업무가 파악되기 전에는 refactoring보다는 재 작성이 더 낫다고 생각합니다.

이런 제 의도가 ZDNet에는 충분히 전달되지 못했습니다.

아, 그리고 저는 주로 실무도 관심 있지만 Agile이나 소프트웨어 공학의 철학적인 면, 인지과학적 측면에 관심이 많습니다. 소
프트웨어 공학적인 측면에서 해결되지 않는 문제가 이런 면에서는 명확해지는 것도 많습니다.

하여튼 앞으로 자주 글을 올리고 여러분의 비판을 겸허히 받아서 생각을 고치고 배우도록 하겠습니다.

그럼 많은 의견 보내주세요.

[송홍진]

저도 성진이아빠님의 의견에 동조하는 부류입니다.

하지만 국내에서는 인지과학이나 심릭학 적인 접근 방법에 대단한 거부감이 있는 것 같습니다.

몇군데 시도해 보았는데 내외부의 반발에 적잖게 당황하게 됩니다.

물론 설명하면 이해하고 동조하지만 정성적인 데이터를 신뢰할 수 없다는 반응들입니다.

저는 TDD를 수행하면 만들어진 테스트 케이스를 테스터들이 교차 리뷰하도록 강제하는 편입니다. 머.. 모든 테스트 케이스를 다 그렇게 하는건 불가능하고 중요한 부분에 대해서는 그렇게 하도록 합니다만 문제는 일반 테스터들이 테스트 코드에 대해 이해하지 못하는 경우가 많기 때문에 문서화에 대한 부담이 개발자에게 가중되면서 그다지 호응이 없습니다.

이래 저래 어려운것 같습니다.

2009/6/24 성진이아빠 <jkle...@naver.com>

[gyehong park]

환영합니다~ : )

야간 이상한 느낌은 들었지만, 무엇인가 이론적으로 접근하는 느낌이 들어서 재미있기도 했습니다. 논리적으로 단계를 밟아가는 느낌이랄까? 가능하다면 원래 글을 볼 수 있다면 좋겠군요~ : )

저도 심리학이나 인지과학에 많은 관심을 가지고 있습니다.

앞으로도 좋은 글 기대하겠습니다~

2009/6/24 성진이아빠 <jkle...@naver.com>

[gyehong park]

인지과학과 심리학에 모두 관심을 가지고 있습니다. 

어떤 시도와 거부감들이 있었는지 많~~~이 궁금합니다. ^^*

2009/6/24 송홍진 <y2k0...@gmail.com>

[아샬]

몇 가지 의문이 드는데, 토론을 원하시는 것 같아서 일단 2가지만 이야기하고 싶습니다.


1. 저는 프로그램을 "이론(내지는 가설)"으로 비유하는 연결 고리가 궁금합니다.

저는 이 둘을 연결하는 것이 굉장히 어색하다고 생각하거든요.

프로그래밍은 신의 코드를 발견하는 게 목표가 아니라,

(디자인이 주축인) 코드의 성장을 끌어내는 게 목표라고 생각합니다.


2. 리팩터링을 하지 않는 상황을 전제하신 것 아닌가 싶습니다.

기교를 부려서 적게 수정하고 테스트를 통과한다면

사실 그야말로 최소 노력으로 최대 효과를 거둔 것입니다.

대표적인 성공 사례라고 할 수 있겠죠.

만약 매우 특수한 상황에 대한 분기를 의미하거나 핵에 가까운 조취를 뜻한 거라면

오히려 리팩터링 과정이 생략됐다고 보는 게 옳지 않을까요?

저는 단순한 코드 수정이 리팩터링으로 오해되지 않아야 TDD와 선순환이 가능하다고 봅니다.

2009년 6월 24일 오후 12:54, 성진이아빠 <jkle...@naver.com>님의 말:

[송홍진]

제가 우려하는 것은 TDD를 하는 개발자들이 시간에 쫓기거나 여러 이유로 테스트케이스를 성공하는 테스트 케이스만을 만드는 경우입니다.

정말 최소한의 성공하는 테스트 케이스만을 고려하고 예외사항에 대하여 고려하지 않은 경우 단위나 통합테스트가 성공했다고 하더라도 시스템 테스트에서 정말 물밀듯이 결함이 쏟아져 나오는 경우가 있습니다.

그런 경우 테스터들은 단위 테스트와 TDD에 대해 의심의 눈초리로 바라볼 수밖에 없습니다.

이것이 가속화되면 정말 신뢰할 수 없는 건널 수 없는 요단강을 건너는 거죠..

그래서 개인적으로 TDD가 성공하기 위한 여러가지 중에서도 개발자가 테스트 케이스를 만드는 사고 방식을 전환하는것이 필요하고 테스트 케이스를 감시(리뷰)하는 과정이 필요하다고 생각합니다만.. 문제는 그럴 경우 비용 문제도 있고 커뮤니케이션 등등 여러가지 잡음이 생긴다는 겁니다.

TDD는 뜻도 좋고 얼핏 보면 쉬운듯 하지만 막상 그렇게 쉬운것만은 아닌것 같습니다.

제가 아는 어떤분은 TDD를 반대하면서 하시는 말씀이 TDD는 개발자의 자기 만족의 또다른 일면일 뿐이고, 책임 면피용 도구일 뿐이다라고 하시는 분도 계셨습니다만.. 전 그렇다고는 생각하지 않습니다.

그런데 쓰다 보니 무슨 소리인지...

2009/6/24 아샬 <ahas...@gmail.com>

[박성철]

안녕하세요. 반갑습니다.
평소 어떤 분인지 궁금했었는데 이렇게 인터넷으로나마 만나게 되었네요. ^^
TDD를 Test 부분을 강조하시는 것 같은데 TDD를 적용하는 규모의 차이 때문인지 모르겠지만 그저 TDD 주기를 수십분에서
수분 내에서 수행하는 저에게는 검증 보다는 확인이라고 가볍게 부르는 것이 더 적당해 보입니다.

관련은 없겠지만 칼 포퍼를 말씀하시니 며칠 전에 켄트 벡이 쓴이 생각나네요.
http://www.threeriversinstitute.org/blog/?p=242
재미있게 토마스 쿤의 과학 혁명과 설계를 연관지어 얘기하는데 칼포퍼의 정형화된 방법론 보다는 더 역동적인 개발 풍경이 그려집니
다.

[[1002]]

안녕하세요. 반갑습니다.

궁금한 점이.. zdnet 이 출판잡지인지요? (웹으로만 알고 있어서) 해당 글이 전제로 삼은 배경들이

있다면 이를 명시를 해주어야 하는데, 웹 사이트로만 운영되는 것이라면 이라면 무리해서 저자의

의도도 제대로 전달하지 않고 15페이지 기사를 4페이지로 축소할 필요가 있는가 하는 점이..;

종국님은 자신의 의견을 개진하신 것 뿐이고, 편집 시 저자 의도를 제대로 살리지 못한 zdnet 의

문제라는 생각을 해봅니다.

그리고.. 제가 제대로 이해를 했는지 모르겠는데, 앞에서 말씀하신 이론에의 개념과 TDD의 개념을 다음과 같이 대입하신 것 같습
니다.

현실, 현상 중 일부 - 테스트
현상을 설명하는 이론 - 구현 및 리팩토링
새로운 현상이 발견되었고 이를 앞의 이론이 올바르게 설명하지 못할 때 기존 가설을 수정 (ad-hoc 가설) - 일부 코드의 수
정 혹은 리팩토링
새로운 현상이 발견되었을 때 이를 설명하는 확실한 새 이론의 도입 - 새 코드의 작성

그런데, 제가 지금까지 알아온 리팩토링을 볼 때 리팩토링이 ad-hoc 가설에 대입되는 것은

여러 오해들을 만들 것 같습니다. 제게 'ad-hoc 가설' 은 TDD 기법 중 깨끗하고 명확한 구현에

미치지 못한 중간단계 코드들 (Fake It 을 했다던지 하는..)에 대입하는게 더 적절하지 않을까 생각이 듭니다.

저는 리팩토링에서 수학적 일반화 혹은 일반 이론으로의 정리의 느낌을 받곤 합니다.

On 6월24일, 오후12시54분, 성진이아빠 <jklee...@naver.com> wrote:

[성진이아빠]

ZDNet의 문제가 아니고 기사에 제한이 있는지 파악하지 못한 제 잘못입니다. ZDnet 위치는 다음과 같습니다.(http://
www.zdnet.co.kr/ArticleView.asp?artice_id=20090615193506) 원문 파일도 올렸으니
보십시요.

아마 TDD는 실험을 통해 실효성이 평가된 몇 안되는 기법중 하나가 아닌가 합니다. TDD의 가치에 대해서는 IEEE
Transactions of Software Engeering에도 논문이 올라와 있습니다.
저의 고민은 전통적인 소프트웨어 기법과는 전혀 다른 이런 기법들이 왜 통할가 하는 것인데 사람의 인지구조를 따르기 때문이라고 나
름대로 생각하고 있습니다.
우리는 어짜피 trial and error로 일단 답을 만들어 보고 검증하고 다시 지우고 새답을 내놓고 하기 때문에 소프트웨어
개발도 이 방식으로 하는것이 자연스럽다고 봅니다.

그런데 저는 TDD를 통해 개발하는 것에 관심이 많은데 TDD의 테스트 측면을 보시는 분도 많은 것 같네요.

음. 그리고 저는 제 팀과 제 자신을 실험쥐로 만들어서 여러차례 TDD와 refactoring을 적용해 보았습니다. 정말 좋더군
요. 제가 프로그래머로서 자질이 없다는 절망감이 극복되었습니다.
(설계를 잘 해야 된다고 해서 UML을 써서 그림도 많이 그려보았지만 프로그램과 연결이 잘 되지 않았습니다.)
그런데 문제는 TDD를 적용하려면 객체지향 방식의 설계를 해야 한다는 것이고 우리 회사도 그렇지만 대다수의 프로젝트가 UI 중
심이 아니면 DB 중심으로 프로그램을 짜고 있는데
이것이 걸림돌이 되는 것 같습니다.

그래서 다시 새 과제로 OR 매핑을 적용할 수 있는 방법을 찾고 있습니다. 언젠가 정리되면 다시 한번 설명할 기회를 만들어 보겠
습니다.

아, 또 한가지는 제가 고전적인 소프트웨어공학이 뭔가 잘못됐다는 느낌을 계속 받고 있는데 여러분은 어떠신지요? 저는 사람이 사고
하는 방식과 맞지 않는 분석, 설계, 개발의 분리,
폭포수 방식, 요구사항이 확정되지 않았는데 WBS 상세히 작성하기, UML만 사용하여 설계후 코드 자동 생성하기 등에 강한 거부
감을 가지고 있습니다. (저는 UML도 싫어합니다. 그냥 코드를 작성하는것보다 나을게 없는것 같습니다.) 여러분은 어떻게 생각
하시는지 알고 싶습니다.
그럼 많은 의견 부탁드립니다.

On 6월24일, 오후12시54분, 성진이아빠 <jklee...@naver.com> wrote:

[chungha]

저도 분석, 설계, 개발의 분리...정말 안좋아하게 되었습니다.^^ (이제 애자일을
업무에 적용한지 6개월 되었습니다. 완전 행복..ㅋㅋ)

저희 회사는 전통적인 방법을 매우 잘 따릅니다.
잘 되고 있는지는 잘 모르겠지만..^^;;
설계서 작성 및 검토만 몇주..하루종일 회의만..설계서만 있으면 코딩은
기계적인 작업이라는 인식 등..
사실 전통적인 방법론이 뭐가 어떻게 잘못되었는지는 아직 초보라 모릅니다.

하지만 중요한건 몸은 알고 있습니다. 즐겁습니다^^


Ps. 매일 눈팅만 하다가 처음으로 답변 달아봅니다.^^ 많은 걸 알게 해주셔서
감사합니다.

[박동욱]

안녕하세요.

프로그래머 레벨 1 정도 되는 초보 프로그래머입니다.

저는 UML 을 상당히 선호하는 편인데, 작성된 프로그램의 흐름과 전체적인 이해를 돕는 다고 생각합니다.

누군가 만든 프로그램을 읽을때, 또는 과거 제가 작성한 프로그램을 살펴볼때, UML 을 보고 나서 코드를 읽는것이 확실히 가독성이 높아지더군요. 

어디까지나 제 개인적인 생각입니다. ^^;

[김영현]

안녕하세요.

 

전통적인 방법이 문제가 있다기 보다는 사용하는 사람들이 제대로 사용하지 못하기 때문에 발생하는 문제들이 그런 인식을 가지게 만드는 것이 아닌가 합니다. 제가 아는 어떤 외국분은 XP, 스크럼이 유명해지기 전 부터 이 들과 비슷한 방식으로 일을 계속 해왔다고 하시더군요. 효율성이 문제라면, 다른 사람들을 이해시키고 개선하면 되지 않을까 합니다.

 

매일 글만 읽다가 글을 쓰니 어색합니다. ^^;;

 

감사합니다.

 

2009년 6월 25일 오후 7:35, 박동욱 <ncsh...@gmail.com>님의 말:

[Jake Kim]

저는 고전적인 소프트웨어 공학이 잘못됐다고는 생각하지 않습니다. 다만 그것들을 잘못 사용한것일 뿐 아닐까요.
고전적인 소프트웨어 공학은 대규모 프로젝트 (NASA 의 우주왕복선 같은) 에는 중요하다고 생각합니다. 또 그러한 프로젝트들을
기반으로 설립이 된 것이기도 하구요. 그런 프로젝트들에서 하나의 요구사항 수정은 수십수백억의 비용을 요구될 수도 있고 사람의 생
명까지도 연관되어질 수 있기 때문에 정확한 문서와 검증 절차를 거치는 방식은 당연하다고 봅니다. 하지만 그렇지 않은 중소 규모
의 프로젝트에서 그런 소프트웨어 공학을 그대로 받아 들인다면 득 보다는 손실이 더 크겠죠. 그리고 그런 방법론 (예를 들면, 폭
포수)이 나온 시대와 현대 사회및 컴퓨팅 환경을 비교해 보면 변화의 속도와 프로젝트의 소규모화라는 것이 가장 큰 변수가 아닐까
싶습니다. 따라서 가장 최근에 등장한 애자일류의 방법론이 가장 최근의 시대적 요구사항을 반영하고 있기 때문에 인기가 있고 더 맞
아 떨어진다고 생각합니다.

설계는 어떤 관점에서 볼 것인가에 따라 그 가치에 차이가 있다고 봅니다. 설계 그 자체를 목표로 본다면 그 효용성과 가치가 많
이 떨어지는 것을 경험했습니다. 아무리 설계를 그럴듯 하게 하더라도 코드 몇줄 쓰다 보면 미처 예상치 못한 부분이 떠 오른다는
것이죠. 그것을 다시 설계에 반영하지 않으면 설계와 구축의 괴리는 점점 더 커질 것이고 이로 인해 설계에 대한 거부감을 많이 갖
는 것이 사실입니다. 모델링 툴이 있지만 Round-Trip Engineering 이 안정적인 기능을 발휘할 수 있기 전까지는
설계와 구축간의 간격을 좁힐 수 없을 것 같습니다.

하지만 설계를 그 자체가 목표가 아닌 개발의 수단으로 보았을 때는 상당한 효과를 발휘하는 것을 경험했습니다. 설계를 하는 과정
이 문제영역을 이해하는 과정으로 이해가 되고 모든 관련된 사람들 (stake holders)의 의사소통 수단을 만들어가는 과정으
로 이해가 되는 것입니다. Eric Evans가 Domain-Driven Design 에서 설명하는 Ubiquitous
Language 가 성립되는 것이죠. 의사소통을 위해 표현하는 수단은 UML 이 될 수도 있고 아닐 수도 있지만 그것은 중요하
지 않다고 봅니다. 저는 UML 2.0 이 1.0 과 어떻게 다른지도 모르지만 UML 비슷한 다이어그램으로 전혀 기술적 기반이
없는 사람들과의 문제 영역의 이해를 위한 의사 소통에 지장이 없다는 것을 경험하곤 합니다.

아무리 잘 그려진 설계 문서라도 서로 다른 기반을 갖고 있는 프로젝트 관련자들 사이의 상호이해에 도움이 안된다면 그 가치는 별
로 없다고 생각합니다. 설계 문서보다는 문제 영역에 대한 이해도의 차이를 좁히는 것이 가장 중요하다고 봅니다. 그리고 설계는 이
를 돕기 위한 수단으로 사용될 때 가장 큰 가치를 창출하는 것 같습니다.

On Jun 24, 9:11 pm, 성진이아빠 <jklee...@naver.com> wrote:
> ZDNet의 문제가 아니고 기사에 제한이 있는지 파악하지 못한 제 잘못입니다. ZDnet 위치는 다음과 같습니다.(http://www.zdnet.co.kr/ArticleView.asp?artice_id=20090615193506) 원문 파일도 올렸으니

> > 그럼 많은 의견 보내주세요.- Hide quoted text -
>
> - Show quoted text -

[Youngrok Pak]

이종국님의 기분을 상하게 할까 걱정해서인지, 아니면 흑백을 가리는 것은 생산적이지 않다고 생각해서인지 이 이야기가 안 나오고 있네요. 생산적으로 토론이 전개되는 것도 좋지만 짚을 건 짚고 넘어가야 하지 않을까요?

제가 보기에는 이종국님이 TDD와 리팩토링을 잘못 이해하고 있습니다. 물론, 이종국님이 하시고 싶어하는 논지도 알겠고, 그 논지가 틀린 말도 아니라고 생각합니다만, 그 논지의 전개 과정에서 연결지은 몇몇 개념들에 착오가 있습니다. 이전 쓰레드에서 창준님이 제기한 의문, 이번 쓰레드에서 석천님이 제기한 의문도 그 착오들을 의식하신 것으로 보이구요.

c2.com, xprogramming.com 등에서 TDD에 대한 글들을 좀 읽어보시면 그 오해들을 교정하는데 도움이 될 것 같습니다.

[Simon, Song]

설계는 개발의 수단이다.
설계보다 문제 영역에 대한 이해도의 차이를 좁히는 것이 가장 중요.
설계는 이를 돕기 위한 수단으로 사용될 때 가장 큰 가치를 창출.

insight가 열립니다. 감사합니다.

> > - Show quoted text -- 원본 텍스트 숨기기 -
>
> - 원본 텍스트 보기 -