오랜 만에 글을 올립니다. 왠지 그럴듯한 이야기나 가치있다고 여겨지는 기술 내용을 써야만 할 것 같은 중압감에 글을 잘 못 적고 있었습니다. 누가 압박을 주는 것도 아닌데 말입니다.
블로그 글쓰기를 다시 재개 할때는 역시 가벼운 이야기를 짧게 하면서 시작하는것이 답인것 같습니다. 그리고 이번 글은 별다른 퇴고의 단계를 거치지 않고 생각의 흐름대로 그냥 적어보려고 합니다. (어색해도 그러려니 해주세요 :)
오늘 하려는 이야기는 '왜 TDD를 배워야 하는가?' 그리고 '왜 Old fashioned IT Man인 제가 이렇게 질기게 TDD를 이야기 하는가?'에 대한 이유를 이야기 하려고 합니다. 600페이지에 가까운 책을, 그것도 기초적인 내용위주의 책을 써가면서 까지 말입니다.
사실 저는 약간 Geek스러워서 오래된 기술/제품 보다는 새로운 기술/경향에 더 열광하는 스타일입니다. 그런데도 나온지 10년이 넘은 기술(?)인 TDD를 이제와서 다시 이야기하려는데는 이유가 있습니다.
강의때 종종 하는 말입니다만, '현실을 변화시킬 수 없는 기술'은 그 한계가 명확하다고 생각합니다. 연구실 안의 기술, 책 속의 이야기일 뿐이기 십상이니까요.
어느날 문득 든 생각이 있습니다. 그간 등장했던 다양한 기술이나 테크닉이 과연 우리의 삶을, 특히 개발자의 삶을 얼마나 풍요롭게 해주었나? 하는 의문점입니다. 개발자의 삶이, 그것도 자신의 일을 천직이라 느끼고 살아가는 개발자에게 있어 일상이 어느정도 나아졌는가? 하는 질문이었습니다.
아이러니 하게도 제가 그동안 배웠던 기술관련 지식중 가장 오래 남아있고, 지금까지도 유효한 지식 하나는 언제 배웠는지도 제대로 기억이 나지 않는, 장치의 속도에 대한 지식입니다.
(빠르다) ------------------------(느리다)
CPU > 메모리 > HDD > Network
물론 까다롭게 따지고 들어가면 레지스트리라던가 L1캐시, L2캐시에, HDD와 Network의 전송량, 응답시간특성등등으로 복잡해 지지겠지만, 기본적으로는 위의 순서를 따릅니다.
어느 분야가 되었든 튜닝을 하는데에 있어 기본 원칙은 아주 분명합니다.
그리고 저는 이 기본원칙이 튜닝의 시작과 끝을 아우른다고 생각합니다.
'빠른속도의 장치를 더 많이 쓰도록 만든다' '병목이 생기지 않도록 밸런스를 맞춰준다'
이 이외에는 튜닝이 아니라 '증설'이 답이 되니까요.
이 원칙을 위해서 트릭을 쓰고 기술을 적용하는 것일 뿐입니다.
기본원칙에 대한 생각이 견고해야 더 앞으로 많이 나아갈 수 있습니다. 그리고 새로운 기술을 접했을 때에도 더 빨리 더 잘 응용할 수 있게 됩니다. 기술 그 자체에만 집중하면 대부분 우왕좌왕하기 쉽곤합니다.
저는 TDD가 프로그래밍의 기본적인 원칙이자 근본 기술중 하나가 될 수 있다고 생각합니다. 많은 초보자들이 특정 언어의 문법을 배운 다음에는 보통 곧바로 프로그래밍에 들어가곤 하는데, TDD를 빨리 익히면 익힐수록 더 많이 더 빨리 진보할 수 있습니다.
저도 나름 어린시절부터 프로그래밍을 해봤다고 생각합니다만, 이십년 넘게 프로그래밍을 해왔던 시절을 되돌아보면 크게 두 부분으로 연대기를 나눌 수 있습니다.
TDD를 모르던 시절과 TDD를 배우고나서 실천하기 시작한 시절.
기간적으로는 후자의 기간이 훨씬 짧지만, 저의 프로그래밍 스타일과 프로그램을 대하는 방식, 그리고 제 삶에 있어서 여러가지 것들이 TDD를 배운 이후로 드라마틱하게 변화되었습니다.
프로그램과 삶에 대한 관점이 바뀌었다고 할까요?
프로그램이 만만치 않다고 느꼈고, 그러면서도 좀 더 즐길 수 있는 방법을 배웠고, 그리고 삶에 있어서 '실패'가 갖는 의미에 대해서도 다시 생각하게 되었습니다.
제 책 첫장에도 나옵니다만, 영화감독이자 배우인 우디 앨런의 한 마디.
'때때로 실패하지 않으면, 안이하게 살고 있다는 확실한 증거이다'
에 이르는 수준으로 제 삶에 있어 TDD는 확장되었습니다. :)
제가 더 어린 시절에 더 빨리 TDD를 배웠으면 어떻게 되었을까? 하는 생각을 하곤 합니다.
내년 부터는 언어를 막 배운 신입사원에게 TDD를 가르치려고 준비하고 있습니다. 저 혼자가 아니라 회사 차원에서 말입니다. 좋은 습관을 초반부터 만드는것이 중요하기 때문입니다. 그리고 주변의 많은 윗 분들께서도 제 생각에 동참해 주셨습니다.
TDD는 배우기는 쉽지만, 마스터하긴 어려운 기술입니다. 하지만 충분히 가치있는 기술이고, 프로그래밍을 하는 우리의 삶을, 그리고 주변의 모습과 세상을 변화시길수 있는 근본 기술 중 하나라고 저는 믿기 때문에, 앞으로도 조금 더 이야기 하고 다니려고 합니다.
한동안 Agile에 대해 제가 그랬던 것처럼 말입니다.
ps.
외국에서 Agile 기법중 가장 크게 효과를 본 기술 Top5와 가장 배우기 어려웠던(즉 제대로 실행하기 어려웠던)기술 Top5를 조사한 적이 있었습니다. 양쪽 다 순위에 포함된 기법 두 가지가 있는데, TDD와 짝 프로그래밍입니다. 배우긴 어렵지만 배우면 효과가 뛰어난 기술 두 가지인 겁니다.
제 생각은 이렇습니다.
고만고만한 기술 경쟁에서 남들 다하는거 더 잘 하려고 노력해서 우위를 차지 하기는 어렵습니다. 잘해야 반보 앞서거니 뒷서거니 하면서 출혈경쟁이 되기 쉽거든요. 차라리 남들이 어려워서 못한다고 생각하는 기술이나 분야를 '우리'는 잘해야 제대로 앞서 나갈수 있는 겁니다. 그게 블루오션으로 가는 길이고요.
Comments
관점이 저와 많이 비슷하군요. 저도 후배들에게 기술적인 이야기나 전달을 할 때 기술적인 홍보에 너무 솔깃하지 말라는 이야길 하곤합니다.
기술은 흥망성쇄가 있고 변하는것과 변하지 않는것이 있다고 이야길합니다.
원리와 사상을 먼저 이해하고 기초부터 차근차근히 실력을 갈고 닦으라고 이야기합니다.
잘 아시다시피 SI를 하다보면 이런 이야기나 관점들이 타인에게 잘 전달이 되지 않을때가 많습니다.
고작해봤자 TDD한다고 혼자 깨작되던게 전부였지요.
일정은 짧고 스팩은 거대한데 누구하나 짝프로그래밍이나 TDD를 논할 수도 논하지도 관심조차 갖으려고 하지 않더군요. 글의 내용이 TDD에 관한 이야기를 하셨지만 TDD와 같은 맥락에서, 원리와 사상을 먼저 이해하는데 노력해야 한다고 봅니다.
최근 신입들은 신 프레임웍에만 눈이 멀어 그것이 전부인줄알고 있는 사람들이 많습니다. 이점 매우 안타깝죠. 프레임웍이나 그 기술이 없으면 어떤거 하나라도 제대로 구현할 수 없는 그들을 보면서 항상 옆에서 씁쓸함도 많이 느끼곤 했습니다. 그전에 그 기술이 가지고 있는 의도나 구조론, 또는 존재가치에 대한 이유를 먼저 알려고 노력하고 api보다는 설계위주의 사상, 예를들어 OOAD나 원리를 먼저 깨우치는 모습이 중요하지 않을까 합니다.
저 같은 경우 경쟁을 위해 이 바닥에서 일해온게 아니라서 마지막 결론에 대한 관점은 글쓴이와 많이 차이가 납니다. 물론 남들이 하지 않는걸 한다는 입장은 꽤 오래전에 마음에 담아두고 있었던 관점이었는데, 이런 관점이 지금은 많이 없어졌습니다. 경쟁보다는 융화가 앞으로의 자기 발전에 더 좋다고 깨우쳐서인것 같습니다.
적절한 하드웨어에 대한 비유(AMD와 InTEL의 계산방법은 틀리지만...) 그리고 글 잘보았습니다.
신입들에게 좋은 로드맵이 되어 줄 수 있는 선배와 교육자가 되어주십시오.
간만에 신선하고 관점이 90% 비슷해서 댓글을 좀 길게 달아놨습니다. 저도 제 지식을 물려줄 수 있는 이들을 찾고 있어서 요즘 고민이 많거든요:) 최근엔 개인적으로 레일즈로 TDD를 시도해 보고 있습니다. 쿨럭:)
제가 보는 TDD는 사람의 실수를 막는 하나의 방법으로 보고 있습니다. The art of unix programming에서 부록에서 나오는 이야기에 "그가 위대한 이유는 그는 자신이 바보라는 것을 알았기 때문이다."라는 말이 있지요. 실수를 막아주는 것 말고도 작은 성취를 계속해서 경험하게 하는 좋은 면 등등 여러가지 좋은 점들이 있지만, 여러가지 편견과 몰이해로 관심을 두지 않는 사람이 더 많은 것 같습니다.
전 후배에게 알고리즘과 자료구조를 항상 강조하고 있습니다.(SI에서는 거의 고려되지 않을 수도 있겠지만요.) 좀 더 앞서겠다는 생각보다는 "좀 더 좋은 프로그램을 만들고 싶다."라는 욕망이 더 바람직하지 않을까 생각합니다.
@doortts (doortts) 님이 작성한 게시글입니다. ---
오랜 만에 글을 올립니다. 왠지 그럴듯한 이야기나 가치있다고 여겨지는 기술 내용을 써야만 할 것 같은 중압감에 글을 잘 못 적고 있었습니다. 누가 압박을 주는 것도 아닌데 말입니다.
블로그 글쓰기를 다시 재개 할때는 역시 가벼운 이야기를 짧게 하면서 시작하는것이 답인것 같습니다. 그리고 이번 글은 별다른 퇴고의 단계를 거치지 않고 생각의 흐름대로 그냥 적어보려고 합니다. (어색해도 그러려니 해주세요 :)
오늘 하려는 이야기는 '왜 TDD를 배워야 하는가?' 그리고 '왜 Old fashioned IT Man인 제가 이렇게 질기게 TDD를 이야기 하는가?'에 대한 이유를 이야기 하려고 합니다. 600페이지에 가까운 책을, 그것도 기초적인 내용위주의 책을 써가면서 까지 말입니다.
사실 저는 약간 Geek스러워서 오래된 기술/제품 보다는 새로운 기술/경향에 더 열광하는 스타일입니다. 그런데도 나온지 10년이 넘은 기술(?)인 TDD를 이제와서 다시 이야기하려는데는 이유가 있습니다.
강의때 종종 하는 말입니다만, '현실을 변화시킬 수 없는 기술'은 그 한계가 명확하다고 생각합니다. 연구실 안의 기술, 책 속의 이야기일 뿐이기 십상이니까요.
어느날 문득 든 생각이 있습니다. 그간 등장했던 다양한 기술이나 테크닉이 과연 우리의 삶을, 특히 개발자의 삶을 얼마나 풍요롭게 해주었나? 하는 의문점입니다. 개발자의 삶이, 그것도 자신의 일을 천직이라 느끼고 살아가는 개발자에게 있어 일상이 어느정도 나아졌는가? 하는 질문이었습니다.
아이러니 하게도 제가 그동안 배웠던 기술관련 지식중 가장 오래 남아있고, 지금까지도 유효한 지식 하나는 언제 배웠는지도 제대로 기억이 나지 않는, 장치의 속도에 대한 지식입니다.
(빠르다) ------------------------(느리다) CPU > 메모리 > HDD > Network
물론 까다롭게 따지고 들어가면 레지스트리라던가 L1캐시, L2캐시에, HDD와 Network의 전송량, 응답시간특성등등으로 복잡해 지지겠지만, 기본적으로는 위의 순서를 따릅니다.
어느 분야가 되었든 튜닝을 하는데에 있어 기본 원칙은 아주 분명합니다. 그리고 저는 이 기본원칙이 튜닝의 시작과 끝을 아우른다고 생각합니다.
'빠른속도의 장치를 더 많이 쓰도록 만든다' '병목이 생기지 않도록 밸런스를 맞춰준다'
이 이외에는 튜닝이 아니라 '증설'이 답이 되니까요. 이 원칙을 위해서 트릭을 쓰고 기술을 적용하는 것일 뿐입니다.
기본원칙에 대한 생각이 견고해야 더 앞으로 많이 나아갈 수 있습니다. 그리고 새로운 기술을 접했을 때에도 더 빨리 더 잘 응용할 수 있게 됩니다. 기술 그 자체에만 집중하면 대부분 우왕좌왕하기 쉽곤합니다.
저는 TDD가 프로그래밍의 기본적인 원칙이자 근본 기술중 하나가 될 수 있다고 생각합니다. 많은 초보자들이 특정 언어의 문법을 배운 다음에는 보통 곧바로 프로그래밍에 들어가곤 하는데, TDD를 빨리 익히면 익힐수록 더 많이 더 빨리 진보할 수 있습니다.
저도 나름 어린시절부터 프로그래밍을 해봤다고 생각합니다만, 이십년 넘게 프로그래밍을 해왔던 시절을 되돌아보면 크게 두 부분으로 연대기를 나눌 수 있습니다.
TDD를 모르던 시절과 TDD를 배우고나서 실천하기 시작한 시절.
기간적으로는 후자의 기간이 훨씬 짧지만, 저의 프로그래밍 스타일과 프로그램을 대하는 방식, 그리고 제 삶에 있어서 여러가지 것들이 TDD를 배운 이후로 드라마틱하게 변화되었습니다.
프로그램과 삶에 대한 관점이 바뀌었다고 할까요? 프로그램이 만만치 않다고 느꼈고, 그러면서도 좀 더 즐길 수 있는 방법을 배웠고, 그리고 삶에 있어서 '실패'가 갖는 의미에 대해서도 다시 생각하게 되었습니다.
제 책 첫장에도 나옵니다만, 영화감독이자 배우인 우디 앨런의 한 마디.
에 이르는 수준으로 제 삶에 있어 TDD는 확장되었습니다. :)
제가 더 어린 시절에 더 빨리 TDD를 배웠으면 어떻게 되었을까? 하는 생각을 하곤 합니다.
내년 부터는 언어를 막 배운 신입사원에게 TDD를 가르치려고 준비하고 있습니다. 저 혼자가 아니라 회사 차원에서 말입니다. 좋은 습관을 초반부터 만드는것이 중요하기 때문입니다. 그리고 주변의 많은 윗 분들께서도 제 생각에 동참해 주셨습니다.
TDD는 배우기는 쉽지만, 마스터하긴 어려운 기술입니다. 하지만 충분히 가치있는 기술이고, 프로그래밍을 하는 우리의 삶을, 그리고 주변의 모습과 세상을 변화시길수 있는 근본 기술 중 하나라고 저는 믿기 때문에, 앞으로도 조금 더 이야기 하고 다니려고 합니다.
한동안 Agile에 대해 제가 그랬던 것처럼 말입니다.
ps. 외국에서 Agile 기법중 가장 크게 효과를 본 기술 Top5와 가장 배우기 어려웠던(즉 제대로 실행하기 어려웠던)기술 Top5를 조사한 적이 있었습니다. 양쪽 다 순위에 포함된 기법 두 가지가 있는데, TDD와 짝 프로그래밍입니다. 배우긴 어렵지만 배우면 효과가 뛰어난 기술 두 가지인 겁니다.
제 생각은 이렇습니다.
고만고만한 기술 경쟁에서 남들 다하는거 더 잘 하려고 노력해서 우위를 차지 하기는 어렵습니다. 잘해야 반보 앞서거니 뒷서거니 하면서 출혈경쟁이 되기 쉽거든요. 차라리 남들이 어려워서 못한다고 생각하는 기술이나 분야를 '우리'는 잘해야 제대로 앞서 나갈수 있는 겁니다. 그게 블루오션으로 가는 길이고요.
Comments
관점이 저와 많이 비슷하군요. 저도 후배들에게 기술적인 이야기나 전달을 할 때 기술적인 홍보에 너무 솔깃하지 말라는 이야길 하곤합니다. 기술은 흥망성쇄가 있고 변하는것과 변하지 않는것이 있다고 이야길합니다.
원리와 사상을 먼저 이해하고 기초부터 차근차근히 실력을 갈고 닦으라고 이야기합니다. 잘 아시다시피 SI를 하다보면 이런 이야기나 관점들이 타인에게 잘 전달이 되지 않을때가 많습니다. 고작해봤자 TDD한다고 혼자 깨작되던게 전부였지요. 일정은 짧고 스팩은 거대한데 누구하나 짝프로그래밍이나 TDD를 논할 수도 논하지도 관심조차 갖으려고 하지 않더군요. 글의 내용이 TDD에 관한 이야기를 하셨지만 TDD와 같은 맥락에서, 원리와 사상을 먼저 이해하는데 노력해야 한다고 봅니다.
최근 신입들은 신 프레임웍에만 눈이 멀어 그것이 전부인줄알고 있는 사람들이 많습니다. 이점 매우 안타깝죠. 프레임웍이나 그 기술이 없으면 어떤거 하나라도 제대로 구현할 수 없는 그들을 보면서 항상 옆에서 씁쓸함도 많이 느끼곤 했습니다. 그전에 그 기술이 가지고 있는 의도나 구조론, 또는 존재가치에 대한 이유를 먼저 알려고 노력하고 api보다는 설계위주의 사상, 예를들어 OOAD나 원리를 먼저 깨우치는 모습이 중요하지 않을까 합니다.
저 같은 경우 경쟁을 위해 이 바닥에서 일해온게 아니라서 마지막 결론에 대한 관점은 글쓴이와 많이 차이가 납니다. 물론 남들이 하지 않는걸 한다는 입장은 꽤 오래전에 마음에 담아두고 있었던 관점이었는데, 이런 관점이 지금은 많이 없어졌습니다. 경쟁보다는 융화가 앞으로의 자기 발전에 더 좋다고 깨우쳐서인것 같습니다.
적절한 하드웨어에 대한 비유(AMD와 InTEL의 계산방법은 틀리지만...) 그리고 글 잘보았습니다. 신입들에게 좋은 로드맵이 되어 줄 수 있는 선배와 교육자가 되어주십시오.
간만에 신선하고 관점이 90% 비슷해서 댓글을 좀 길게 달아놨습니다. 저도 제 지식을 물려줄 수 있는 이들을 찾고 있어서 요즘 고민이 많거든요:) 최근엔 개인적으로 레일즈로 TDD를 시도해 보고 있습니다. 쿨럭:)
moova | 2010-08-29 일요일 오후 6:36
--
제가 TDD 이야기할때 먼 처음에 하는 이야기 중 하나는, '더 나은 세상과 나와 더 나은 삶을 만들기 위해서'라고 말하곤 합니다.
경쟁에서 앞서기 위해서라는 건, 그것만으로는 동기부여가 되지 않을 경우, 의사결정자 분들을 설득하기 위해서 하는 말입니다. :)
저도 moova님과 생각이 비슷합니다. 그래서 Agile을 하는거구요.
좀 더 행복하고 즐겁게 함께 일하자!
:)
doortts | 2010-08-30 월요일 오후 5:52
--
압박을 드리겠습니다. "자주" 글 써 주세요.
토비 | 2010-08-29 일요일 오후 6:52
--
:(
doortts | 2010-08-30 월요일 오후 5:55
--
제가 보는 TDD는 사람의 실수를 막는 하나의 방법으로 보고 있습니다. The art of unix programming에서 부록에서 나오는 이야기에 "그가 위대한 이유는 그는 자신이 바보라는 것을 알았기 때문이다."라는 말이 있지요. 실수를 막아주는 것 말고도 작은 성취를 계속해서 경험하게 하는 좋은 면 등등 여러가지 좋은 점들이 있지만, 여러가지 편견과 몰이해로 관심을 두지 않는 사람이 더 많은 것 같습니다. 전 후배에게 알고리즘과 자료구조를 항상 강조하고 있습니다.(SI에서는 거의 고려되지 않을 수도 있겠지만요.) 좀 더 앞서겠다는 생각보다는 "좀 더 좋은 프로그램을 만들고 싶다."라는 욕망이 더 바람직하지 않을까 생각합니다.
Samuel | 2010-08-30 월요일 오전 9:39
--
:) 네. 말씀하신 내용이 맞는 것 같습니다. 의견 달아주셔서 감사합니다.
doortts | 2010-08-30 월요일 오후 5:55
--
--- attachments --- WoodyAllan.jpg cpu.jpg