갔다가 온지 몇일 되었는데 이제야 올린다. 바캠프에 대해서는 형을 통해서 들은바가 있었는데 이번에 회사 선배의 소개로 P-Camp에 대해서 들어서 바로 신청하고 팀장님께 보고하고 갔다가 왔다. 머 기껏해야 업무시간을 1시간 빼먹는 거(야근 빼고.. ㅡ..ㅡ)였기 때문에 크게 문제는 없으리라고 보긴 했었다. 팀장님이 회사일정땜에 공부할 시간을 따로 제공해 주진 못해도 세미나참석 같은건 밀어주실것 같았기 때무넹...
Process, project, pruduct, & people이라는 슬로건을 가진 P-camp
이번 P-Camp는 TDD(Test Driven Development)에 대해서 진행이 되었고 일반적인 실력좋은 강사가 나와서 가리치는 형식을 취하는 세미나가 아니라 난상토론분위기로 진행이 되기 때문에 TDD에 대해서 거의 모르는 나로써는 좀 불안함이 있었지만 의외로 모르는 사람들이 많았기 때문에 막상 가서는 크게 나쁘지 않았다.
이번 P-camp는 저녁 6시~10시까지 진행이 되었다. 시작할때 약간 시간이가 딜레이 되기는 했지만 마치는 시간은 저녁 10시에 깔끔히 끝이났다. 코엑스에서 진행된 ASTA 2007(소프트웨어 테스팅 컨퍼런스)일정의 저녁시간을 한자리 차지해서 진행이 되었고 300명 정도가 참여했다.
순서상 황재선님이 먼저 나와서 약간의 설명을 한뒤에 애자일컨설팅 대표인 김창준씨가 나와서 ASTA에서 발표한 내용을 약간 축약해서 약간의 발표가 있었다.
김창준 대표의 발표
제목은 저렇게 되어있었지만 TDD자체에 대한 내용은 아니고 TDD의 개념(?)정도의 대한 내용이라고 해야할 듯 싶다. 행사일정에는 "Unit testing best practice @ TDD"라는 이름으로 나왔는데 김창준씨의 말에 의하면 아직 검증이 된것이 아니기 때문에 Best라는 표현을 쓰기에는 무리가 있고 "Unit testing a practice @ TDD"정도가 적당할꺼라고 했다.
여기서의 핵심단어인 Ontogeny는 사전설명을 보면 "[생물] 개체(個體) 발생(론)"이다.
이 발표의 내용을 약간 요약하자면...
- QA 전문가인 브라이언매릭이라는 사람은 Test를 2개로 분류했다. Support와 Critical인데 Support는 "test to pass(성공을 위한)"를 목표로 하며 생상성과 설계를 높여줄 수 있고 Critical은 "test to fail(실패를 위한)"는 결함을 찾는 것이 목표이다.
- 크리스토퍼 알렉산더라는 건축가가 있다. 이사람이 오래전 건축에서 패턴이란 것을 연구해서 만들어 냈는데 이걸 가지고 전산에 적용해서 GoF(Gang of Four)가 디자인패턴이라구 만든 것이 전산학의 명저가 되었다.(나도 아직 안봐서.. ㅡ..ㅡ)
- 그루헤 크리스토퍼는 이 패턴을 뛰어 넘는것을 25년동안 연구했고 발견해냈다. 그리고 출판한 책의 이름이 "Nature of Order"이다.
- "Nature of Order"는 사물을 Living Structure로 분류하는데 살아있는 것과 살아있지 않는 것으로 분류한 것인데 이 기준은 살아있다는 느낌(Feeling of Life)이고 조사결과 문화권에 상관없이 거의 일치한다는 것이다.
- 여기서 Ontogeny가 등장하는데 이를 씨앗이 자라는 과정에 비유했다. 이는 개체가 생성되는 것이 추가(완성된 무언가가 하나씩 붙는..)가 아니라 분화(전체적으로 점점 완성되는 것)라는 것이다.
- 그리고 Living Structure가 가진 특징을 15개로 분류했다.
강대상에 가려서 몇개가 안보인다. 이중 몇개를 설명했는데 내가 이해하기에는 정말 어려웠다. 아직 TDD를 공부하진 못했기 때문에 자세히는 모르지만 Ontogeny는 참 흥미로웠다. 하나씩 만드는 것이 아니라 전체를 차차 만들어 가는 과정이라니...
이어서 P-camp의 핵심인 OST혹은 난상토론회가 이루어졌다. 원래는 이렇게 모여서 자신이 원하는 주제를 보드에 게시하고 그 주제에 흥미있는 사람들이 모여서 토론하고 또 주제를 바꾸고 그런 자유스런 분위기가 OST라는 거라는데 이번에는 인원이 워낙 많았기 때문에 미리 신청을 받은 18개의 주제로 각 테이블에 앉아서 토론하는 방식을 취했다.
나는 18번 주제였던 "TDD의 실무 적용방법과 그 과정의 어려운 점"을 선택했다. 원래 신청할때 내가 썼던 "TDD로 개발할때의 이점이 어느정도인가"도 최종선정되었지만 이쪽이 더 맘에 들어서 이쪽을 선택했다. 우리나라에서는 그리 익숙치 않은 토론 문화... 좀 불안감이 있었지만 초기 약간의 서먹함만 벗어나가 금새 쉴틈없이 토론이 이루어지었다.
내가 걱정했던거와 다르게 TDD에 대해서 나만 모르는 것이 아니었고 몇몇 공부하신 분들을 중심으로 토론은 이루어져 나갔다. 그리고 TDD에 대한 말은 많이 들어봤었는데 아직 보급이 내 생각처럼 되지는 않았는데 TDD가 테스팅에 관한 부분으로 생각하고 많은 QA분들도 참석하셨다.
우리조가 한 토론에 대해서 약간 요약을 하자면....
1. 일반적인 코딩시의 함수화, 모듈화 작업과 시연에서 보여준 TDD에서의 작업이 무엇이 다른가?
- 시연한 것 자체는 TDD는 아니다
- TDD는 테스트 코드를 짜고 생각을 한번 정리할 시간이 생긴다.
- 테스트코드를 통과하도록 프로그램을 짜고 살 붙혀나가면서 계속 통과할 수 있도록 한다.
2. 진짜 실무에서 쓸 수가 있는가? 쓰는 사람들이 있는가? 비즈단은 괜찮지만 웹쪽은 좀 어려움이 있다.
- 사람들의 인식이 부족하다. "언제 Test Code를 만들어. 바뻐죽겠는데..."
- 보통 개발 기간이 촉박하다.
3. 회사들의 테스팅 환경은 어떠한가?
- NHN은 20%정도만 테스팅.
- XP이야기로 전환
- 페어프로그래밍이 가능한가?
- 애자일이 그리 먼 얘기는 아니다.
4. 테스팅이나 형상관리가 없으면 타인의 소스를 어떻게 신뢰하는가?
- 문제를 발견했을때 관계자끼리 의사소통을 해서 해결
- 회사마다 해결방법은 좀 다르다.
5. 회사에서 새로운 것을 도입하는 문제 (TDD, Agile)
- 규모가 작을수록 도입하기는 좋다.
- 바로 도입안하더라도 미리 알고 있으면 필요시 바로 적용할 수 있다.
- 조직에 적용하지 못하면 혼자서라도 해라
6. TDD가 더 시간이 많이 걸리지는 않은가?
- 오히려 더 빠르다.
- Test가 없으면 문제있는 코드가 점점 쌓여서 커질수 있다.
- Test 루틴을 만들면 테스트하는 반복행위를 줄일 수 있다.
- 프로그램을 다 만들고 나면 Test 루틴을 만드는 것이 귀찮기 때문에 미리 만드는것이 좋다.
7. Test코드를 잘못 만들었을 때는 더 역효과가 날수 있지 않은가?
- 그래도 없는 것 보다는 낫다. -> 단위테스트로 잘못될 가능성을 최소화 한다.
- Test코드도 계속 발전시킨다.
8. 버그트래킹이나 이슈트래킹 이야기 약간...
9. 유닛테스트 자동화 프로그램
- 단순히 자동화만 해줄뿐 Test루틴을 만들거나 TDD자체를 해주는 것은 아니다.
- 오히려 툴을 배우느라고 TDD를 익히기 어려울 수도 있다.
10. TDD 적용에 대해서
- TDD자체가 상당히 어렵다. 처음엔 뭘해야할지 난감하다.
- 외국에서는 이미 많이 도입이 되어 있다.
- 처음부터 완벽하게 적용할 필요는 없다.
- 물론 부분별로 한계는 있다. (GUI등등) -> 일부분 이라도 적용하자.
- 새로운 것에 대한 어려움은 실패에 대한 두려움이다. 처음에는 실패할 수밖에 없다.
- 외국의 한 잡지에 따르면 Agile도입시 퀄리티는 상승하지만 일정은 길어지는 것으로 조사되었다.
- 국내에선 프로그램이나 사이트의 Life주기가 짧기 때문에 재사용이 어려워서 적용하기가 쉽지 않다.
- 한꺼번에 전부를 완벽하게 도입하려고 하지 말자
- 바로 도입하려고 하기보다 장점에 대해서 고려해 보자
어쩌다보니 내가 서기가 돼서 정리를 했다. ㅋ
다 하고 나서의 느낌을 말하자면..
댓글 없음:
댓글 쓰기