Spring Study Club - s2c.pe.kr

아래 올린 글이 좀 길었죠? 짧게 쓰는 연습을 좀 해야할 것 같습니다.
여러 의견들을 올려주셔서 우선 감사드리고, 스터디하는데 너무 긴장할 필요가 없지
않느냐 좀 릴렉스하고, 열정만 가지고 임해 보자는 말씀에 동의합니다.

그런데 스터디를 어떻게 준비하고 있느냐고 물어본 이유가 있습니다.
저 역시 대의명분이나, 그럴싸한 철학 따위는 좋아하지 않는 사람이지만,
열정 만으로는 충분한 원동력이 되지 않는다고 생각합니다.

작심삼일이라는 말이 있지 않습니까? 왜 자꾸 각오를 다지는데 실패하는 상황이 재발하는 것일까요?
여러 스터디에 참여해봤고, 스터디를 이끌기도 해봤습니다만,
열정만 가지고는 의미있는 성과를 얻지 못하는 경우가 많습니다.
완주하지 못하는 스터디도 있었고 많은 스터디에서 중도 탈락자가 꽤 많이 나옵니다.

이런 문제에 대해서 IT 분야를 담당하는 기자 분과 이야기를 나눈 적이 있는데
시작할 때는 열정이 필요하지만 지속하기 위해서는
중간 중간에 무언가 보상이 있어야 한다고 동의한 바 있습니다.
보상심리라는 것은 인간 뿐만 아니라, 의식을 가진 모든 존재가 가지고 있는 것이지 않습니까?
유사한 말로는 동기 부여라는 것이 있지요.

느슨한 조건으로 편안하게 스터디를 시작하는 것도 좋지만 아무런 준비가 없이
스터디에 참여했다가 문화적 충격(?)이라던가? 심정적으로 어울리지 못하거나,
전혀 무슨 말인지 못알아 듣는다거나, 용어가 낯설다는 등 온갓 이유로 자꾸
이탈자가 발생하는 일이 많이 있습니다.

물론, 각자의 사정이 있는 것이니 그걸 다 어찌 배려하느냐... 네, 당연히 현실적으로 어렵죠.
하지만, 운동을 시작하기에 앞서서 주의 사항을 알려주고,
스트레칭을 하고, 나아갈 과정에서 얻을 수 있는 것이 무엇인가?
동기를 부여하고, 기운을 모으고, 동료 의식을 끌어올리는 과정도 필요하지 않을까요?
전문 용어로는 ice breaking이라고도 하더군요.

물론 스터디가 강의 형식으로 진행되서는 안될 것입니다.
하지만, 참가자 간의 격차를 무시할 수도 없다고 생각합니다.

그런 의미에서 참여하시는 모든 분들이 어떤 각오로 어떤 준비를 하고 있는지
미리 공유하는 것이 의미 있지 않을까요? 강요는 아닙니다.
다 함께 목적지에 도착하기 위한 준비 운동입니다.

만약, 조금 도움이 필요한 분들이 있다면 어떤 식으로 도와드려야 할지 고민해 보도록 하겠습니다.
부디 3기에는 낙오자가 최소한의 인원이 되기를 바람에서 잔소리를 늘어놓았습니다.

더불어 20여명에 가까운 인원이 모여서 3기 첫모임에서 자기소개만 하다가 끝나는 것도 문제가 있겠죠.
그러니 더욱 더 사전에 서로를 알아가는 준비가 필요하다고 생각합니다.

그러고 보니, 이미 참가하고 있는 사람들도 자기 소개를 사전에 해두어야 하지 않을까요?
저 부터 이 글에 댓글로 제 소개와 각오, 준비 중인 내용을 적도록 하겠습니다.

며칠 잠수하다 다시 논쟁거리를 들고 돌아왔습니다.

툭하면 문제를 던지는 문제아(?)라서 죄송하지만, 무턱대고 TDD 스터디를 진행하는게 과연 옳은가 싶은 생각이 자꾸 들어서 결국 참지 못하고 화두를 제기하고자 합니다. 여기서 제가 던지는 한 마디에 또 욱하실 분 있을지 모르지만, 섣불리 TDD에 접근하는 건 아닌지 하는 우려는 이미 다른 분들이 올리신 글에 포함된 늬앙스에 나타나고 있지 않습니까...?

새해를 시작하는 마당에 새로운 마음가짐으로 한걸음 나아기기 위해서 스터디를 신청하신 분도 많을 것이고, 수박 겉핧기로 공부한 것들을 제대로 체득해보고 싶다고 결심하신 분들도 많을 것입니다. 그런데 늘 우리가 잘못 알고 사는 것이 있는데 무언가를 익힌다는 것에 대해서 억지로라도 노력하면 내 것이 될거라는 그릇된 신념이 아닐까 생각합니다. 열심히 하면 될거다. 과연 그럴까요?

이미 새벽 시간이 되었으니 어제 일이 되어 버렸지만, 어제 회사에서 있는 에피소드를 하나 이야기해보고 싶습니다. 저는 최근 10년 넘게 거의 자바로만 개발을 해왔기 때문에 C++, 그것도 임베디드 리눅스 환경에서 개발하는 일을 떠맡고 나서 한동안 버벅거리고 있습니다. PC에 우분투 리눅스를 설치하는 것도 난감하고, 시리얼 케이블로 하드웨어와 통신하는 방법도 처음이라 이리저리 헤매다가 최근 며칠 사이에 겨우 개발 환경을 구축하고 더듬더듬 개발을 하고 있는 상황이죠. 휴대용 디바이스에 리눅스가 포팅되어 있고, 그 내부에서 동작하는 GUI 어플리케이션 구동을 위한 엔진을 개발하는 작업입니다.

그런데 한참 뚜닥뚜닥 거리면서 소스를 편집하고 있는데, 뒤에서 물끄러미 바라보던 동료들이 의아한 눈빛으로 쳐다보더군요. 마우스도 안쓰고 텍스트 에디터도 없는 것 같은데 곧잘 소스가 편집되고 있다는 겁니다. 유닉스, 리눅스를 좀 써보신 분은 알겠지만, 제가 지금 우분투 리눅스에서 사용하는 소스 편집기는 vi 입니다. 마우스를 전혀 사용하지 않고 control, alt 키도 누르지 않고 오로지 알파벳 키와 ESC 키 만으로 모든 편집 명령을 구사하죠.

vi 를 10년 만에 사용하는데 모든 명령을 자연스럽게 기억하고 있는 자신이 놀랍다는 생각이 들었습니다. 자랑하려는 얘기가 아닙니다. 왜 C++ 함수나 문법은 낯설기만 한데, vi는 기억할 필요도 없이 손가락이 알아서 명령들을 찾아내고 있는걸까 하는 생각을 하게 되었다는 겁니다. 자전거나 수영을 배우는 것과 비슷한 것이겠죠. 처음 배울 때는 답답해도, 어느새 익숙해지면 평생 잊지 않게 된다는 것입니다.

16년 전에 처음 vi를 사용하는 선배들을 보면서 신기해 하고, 또 열심히 암호 같은 vi 명령어 사용법을 인쇄해서 외우려고 애쓸 때에는 vi를 제대로 사용하지 못했습니다. 소위 말하는 독수리 타법 처럼 키보드를 쳐다 보면서 계속 필요한 명령을 되네이던 식이었습니다. 그런데, 지금은 어떤 명령을 떠올리는게 아니라, 소스를 복사해다 붙여야 겠다는 생각을 하면 자연스럽게 손가락이 움직여서 10여 단계에 이르는 명령키를 척척 누르고 있는 겁니다.

vi 사용 방법을 공부할 때 시험공부 하듯이 명령을 외우기만 했다면, 이렇게 오래도록 기억하고 있지는 못할 겁니다. 자연스럽게 타이핑을 하는게 아니라, 다시 vi 명령어 목록표를 인쇄해서 모니터 옆에 붙여 두고 몇 줄 고칠 때마다 흘긋흘긋 쳐다보고 있을 겁니다. 그렇다면 이런 방식이라고 해야 할까... 아니면 학습 자세라고 해야 할까... 억지로 외우기 보다는 자연스럽게 반복 학습하는 태도를 TDD를 공부할 때 적용하는 건 어떨까 하는 생각을 해봤습니다. (물론 제 의견이지 이래야 한다는 강요가 아닙니다.)

TDD를 공부하려는 마당에 TDD의 정의, TDD의 법칙, TDD의 정석, TDD의 효과... 이런 걸 공부하고 또 외우려고 하는게 의미는 없다라고 생각합니다. 물론, 어느 공공기관에 TDD 자격증을 내놓을 계획이 있다면 열심히 외우고 예상문제 풀이를 해야겠죠. 하지만, 당분간은 그럴 일이 없을 것 같습니다. UML이나 방법론은 자격증 시험에 포함되고 있습니다만... (어차피 몇년 지나면 변할 기술에 왜 그리 자격증을 남발하는지 모르겠습니다만...) 소프트웨어 개발 방법론이니, 요구분석 노하우라던가, 설계 기법, 디자인 패턴... 이론적인 이야기들은 아무리 외워놔도 실전에 적용할 때는 전혀 떠오르지도 않고, 자연스레 적용이 되는 걸 본 적이 없습니다. (여기서 꼬투리 잡힐만한 이야기를 하나 던지는 군요... 어차피 논쟁을 위한 글이니 그냥 정돈하지 않겠습니다. 자칫하면 이론 공부 하지마라는 이야기로 와전될 수 있을 듯 한데... 에라 모르겠습니다..)

TDD를 학습하기 위해서 꼭 필요한 준비과정은 'TDD란 무엇인가?'라는 정의를 예습하는게 아니라, 왜 나는 TDD를 필요로 하는가? 하는 의문이 아닐까요? 그리고, 그런 질문에 대해서 각자에게 의미있는 답을 품고 첫 시간에 모여야 하지 않을까 싶습니다. (제게 있어서 TDD가 필요한 이유는 적지 않겠습니다. 이건 논쟁을 위한 글이니까요 ^^;)

아니 좀 더 과격하게 물어보고 싶은 게 있습니다. TDD를 학습하기 위한 선행 과정을 이해하고 계십니까? 그런게 필요 없다는 의견도 있을 수 있다고 생각이 들기는 합니다만, 비유를 들자면 무턱대고 자바 언어를 학습한다고 해서 자연스럽게 프로그램을 잘 짜게 되는 건 아니지 않습니까? 왜냐하면 자바, TDD, 스프링 이런 건 도구이니까요. 도구를 사용하기 위해서는 도구를 사용하는 사람이 언제, 어떻게, 왜 써야 하는지를 충분히 이해해야 하고 도구를 사용하기 위한 적합한 환경을 준비할 필요가 있는 것입니다.

너무 추상적인 질문을 드리는 것 같아서, 좀 더 구체적인 얘기를 해볼까 합니다. 저는 TDD에 대해서 Test Case를 작성하고 Test Case를 중심으로 구현해 나가는 과정이라고 알고 있습니다. 제가 알고 있는 지식이 틀릴 수도 있을 겁니다. 그러니 일단, 제가 아는 범주에서 TDD를 위한 준비는 무엇인가라고 묻는다면 저는 문제 이해, 혹은 요구사항 분석이라고 말하고 싶습니다.

웹 게시판을 제작한다거, 소매점을 위한 주문/판매 관리 시스템을 만든다거나, 혹은 메신저 같은 통신 프로그램을 작성하는 경우를 생각해봤을 때, 테스트 케이스를 만들기 위해서는 어떤 것을 테스트 해야 하는가에 대해서 고민할 필요가 있는 것이죠. 별로 중요하지도 않거나, 필요한 기능도 아닌데 열심히 테스트 케이스를 만드는 것은 의미 없는 일이 될 뿐이니까요. 아~ 그런 바보가 어디 있냐구요? 글쎄요. 바보가 없는 세상이라면 왜 모든 소프트웨어 개발 프로젝트는 절대로 예상한 시간에 끝나지 않는 것일까요?

그러니까, 잠시 짚어두고 넘어가겠습니다. TDD 자체에서 벗어난 것을 선행 학습하자는 이야기는 아닙니다. TDD를 위한 TDD, TDD라는 것을 도구로 바라보지 않고 자칫 목적으로 이해해버리는 어이를 상실해버리는 상황을 만들지 않기 위한 각자의 노력이 필요하다는 것을 말씀드리고 싶은 겁니다.

구체적으로 어떤 노력이 필요한 것일까요? 앞서 말씀드린 에피소드를 다시 떠올려 주시면 좋겠습니다. 즉, 노력하려 하지 않는 것이 필요하다고 생각합니다. 필요성을 느끼고, 정말 필요하다고 여기는 것을 자꾸 반복해서 학습하는 것. 그런 과정을 통했을 때에 비로소 깊이 경험이 체득되고 오래도록 남는 것이 아닐까요?

세상에 나온 많은 TDD에 대한 글을 읽고 이해해 보겠다거나, 이번 스터디 과정을 통해서 TDD에 대한 자신감을 얻고 싶다거나... TDD에 대한 이론들을 달달 외워 버리겠다는 시도는 하지 않았으면 좋겠습니다. 심하게 말해서 TDD를 실전에 적용할 수 있는 수준이 되겠다는 것조차 욕심이라고 생각합니다.

그저 여러분과 제가 10년 후에도 여전히 IT 분야의 소프트웨어 개발 현장에 남아있게 된다면, 그 후에도 아무런 거리낌 없이 Test Case를 작성하고 있을 거라는 희망을 걸고 싶습니다. 다시 얘기해 보겠습니다. 예전에는 vi 편집기를 잘 사용하는 개발자는 대단한 사람이라고 인정 받던 시절이 있었습니다. 지금은 어떻습니까? 리눅스에서도 웹 브라우저가 기본 설치되어 있고, 이클립스도 사용할 수 있습니다. vi를 사용한다는 저 같은 사람은 그냥 매니아일 뿐이라는 것이죠. 하지만, 저는 vi를 잘 다루기 때문에 나름 편하게 일을 하고 있습니다. 우분투는 낯설지만, 우분투에서도 vi가 동작하기 때문에 쉬이 적응하게 되는 것이죠.

지금은 TDD가 대단히 새로운 기술처럼 여겨지지만 과연 10년 후에도 그럴까요? 그러니까 굳이 긴장하고, 눈에 힘주고, 어깨 펴가면서 공부할 필요가 없다고 생각합니다. 편안하게 학습해야, 진정 앞으로 저와 여러분의 10년 후를 편하게 만들어주는 그런 도구로 남지 않을까요?

논쟁하겠다고 선언해 놓고 용두사미가 되어버렸습니다만, 그래도 논쟁거리(?)를 계속 남기고 싶습니다. 1월 4일까지는 며칠 남은 것 같은데 여러분은 TDD를 어떻게 준비하고 계십니까? 의견을 기다리겠습니다.

물론 제 의견에 대한 비판도 감사히 듣겠습니다.

----- 여기서부터는 제 주관적인 의견입니다. -----

참고로 제 나름의 노하우를 하나  알려 드릴까 합니다.
만약 프로젝트를 시작해야 하는 마당에 갑자기 본격적으로 스프링을 사용해야 하는 상황이 도래한다면, 저는 절대로 토비님이나, 영회님 블로그를 참조하지 않습니다. 나아가, 거의 모든 스프링 전문가들의 사이트를 읽지 않습니다. (그렇다고 제가 토비님이나, 영회님을 미워한다는 얘기는 아니고...)

왜냐하면, 대가이신 분들이 쓰시는 글과 그 내용은 그 분들이 몇 날, 몇 달 혹은 몇 년에 걸쳐서 고민하고, 실험하고, 시행착오를 거치면서 깨달은 내용을 압축한 것이기 때문입니다. (같은 맥락으로 저는 김창준님이나, 강규영님 블로그도 자주 읽지 않습니다... ^^;) 대체 그런 엑기스를 단숨에 소화해낼 자신도 없고, 도저히 불가능하다고 생각하기 때문입니다. 제가 드래곤 볼에 나오는 손오공이나 베지터는 아니니까 말이죠. 저는 크리링 수준에도 못 미친는 듣보잡 엑스트라 캐릭터입니다.

일단은 당장 현장에서 써먹을 수 있는 샘플 코드, 당장 써먹을 수 있는 예제, 간단한 가이드 위주의 문서를 읽습니다. 그리고 몇번에 걸쳐서 적용하고 응용하면서, 예제에 나와 있지 않지만 필요한 부분이 있으면 레퍼런스 문서를 참조합니다.

점점 실전에서 스프링은 어떻게 쓰는구나라는 감을 익히고 전체적인 윤곽을 파악한 후에 그제서야 스프링에 관한 전문가 블로그들을 찾아 다닙니다. 기본은 익혔으니까, 응용법도 학습해야될 테니까요. 그리고, 어느 정도 실전 경험과 이해력을 얻은 후에 전문가 글을 읽어야 그 분들이 시행착오 경험을 추론할 수 있고, 간접 경험 만으로도 빠르게 새로운 지식을 체득할 수 있게 됩니다. 이런 말이 있죠? 고기도 먹어본 놈이 안다고 말입니다.

아~ 참고로 기선님 블로그도 수준이 높으니까, 스프링 공부하시려면 즐겨찾기에 일단 저장해두시고 나중에 보세요. ^^;

----- 여기서까지는 주관적인 의견입니다. -----