크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

실용주의 프로그래머를 위한 단위 테스트 with JUnit -
데이비드 토머스 외 지음, 이용원 외 옮김/인사이트

최근 다른 글에서도 이야기 했지만, 유닛 테스팅의 필요성을 온 몸으로 느끼고, 제가 작업하고 있는 코드에 슬쩍 집어 넣어 볼려고 노력 중입니다. 이미 회사 내의 다른 팀에서는 유닛 테스팅을 활발히 쓰고 있고, Test Driven Development 로 개발하고 있는 팀들도 꽤 됩니다. 아무튼 팀에 뭔가 새로운 것을 도입하려면 직접해서 효과를 보여주는 게 최고라고 생각하기에 없는 시간 쪼개서 유닛테스팅을 만들고 있습니다.

책 두께 핸드북 처럼 얇습니다. 며칠이면 금새 읽을 수 있었습니다만, 이 책은 읽독 하는 것보다 직접 프로젝트에 유닛테스팅을 도입해 볼 때 가이드북으로 쓰는 게 더 좋을 것 같습니다. 책의 뒷부분에 있는 요약한 장을 그대로 가져왔습니다.

일반 원칙

• 망가질 가능성이 있는 모든 것을 테스트한다.
• 망가지는 모든 것을 테스트한다.
• 새 코드는 무죄가 증명되기 전까지는 유죄.
• 적어도 제품 코드만큼 테스트 코드를 작성한다.
• 컴파일을 할 때마다 지역 테스트를 실행한다.
• 저장소에 체크인하기 전에 모든 테스트를 실행해 본다.

자문해 봐야 할 사항

• 이 코드가 옳게 동작한다면, 어떻게 그것을 알 수 있는가?
• 이것을 어떻게 테스트할 것인가?
• '그밖에' 어떤 것이 잘못될 수 있는가?
• 이와 똑같은 종류의 문제가 다른 곳에서도 일어날 수 있을까?

무엇을 테스트해야 하는가 Rigth-BICEP

• 결과가 옳은가(right)?
• 모든 경계 조건(Boundary)이 CORRECT 한가?
• 역 관계(Inverse)를 확인할 수 있는가?
• 다른 수단을 사용해서 결과를 교차 확인(Cross check) 할 수 있는가?
• 에러 조건(Error condition)을 강제로 만들어낼 수 있는가?
• 성능(Performance) 특성이 한도 내에 있는가?

좋은 테스트는 A-TRIP 해야 한다.

• 자동적 (Automatic)
• 철저함 (Thorough)
• 반복 가능(Repeatable)
• 독립적 (Independent)
• 전문적 (Professional)

CORRECT 경계 조건

• 형식 일치 (Conformance) - 값의 형식이 예상한 형식과 일치하는가?
• 순서 (Ordering) - 적절히 순서대로 되어 있거나 그렇지 않은 값인가?
• 범위 (Range) - 적당한 최솟값과 최댓값 사이에 있는 값인가?
• 참조 (Reference) - 코드가 자기가 직접 제어하지 않는 외부 코드를 참조하는가?
• 존재성 (Existence) - 값이 존재하는가? (예: null 이 아님, 0이 아님, 집합 안에 존재함 등)
• 개체 수 (Cardinality) - 확실히 충분한 값이 존재하는가?
• 시간 (Time)(절대적으로, 그리고 상대적으로) - 모든 것이 순서대로 일어나는가? 제시간에? 때맞추어?

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

토요일에 재방송으로 '베토벤 바이러스'라는 드라마 두 편을 봤는데, 드라마를 안 좋아하는 나도 푹 빠져서 봤다. 어설픈 러브라인이 없는 것도 마음에 들고, 특히나 성격 더러운 김명민 캐릭터가 완전 매력 만점!

하얀 거탑도 그렇고 최근의 인기 있는 드라마들을 보면 일상의 이야기를 소재로 한 것들이 많은 것 같다. 사람들은 모르는 특정 직업군들만의 일상이 그 자체로 훌륭한 이야깃거리이기 때문이다. 물론 약간의 과장이야 들어가겠지만 뭐. 베토벤 바이러스의 재미도 사실 거기 있다. 음악회에서 한번 듣고 마는 그 잠깐의 순간을 위해 오케스트라 단원들이 어떤 노력을 기울이는가 하는 이야기가 사람들에게는 아주 재밌게 다가오는 것이다.

그러고 보면 영업 성공담도 있고 의사 이야기, 변호사 이야기, 오케스트라 이야기까지 나왔는데 이쯤 되면 프로그래머들의 이야기도 한번 나옴 직하다. 알고 보면 소프트웨어 개발만큼 드라마틱한 일도 흔치 않지 않은가. 서로 다른 스타일을 가진 프로그래머들이 팀을 이루게 돼서 우여곡절 실패를 거듭하다 결국 멋진 소프트웨어를 만들어 시장에서 대박을 치는 이야기. 이거 왠지 좀 재밌을 것 같은데?

블로그들을 찾아봐도 소프트웨어 개발 회사들의 소소한 이야기를 들을 수 있는 곳이 많지 않은 것 같다. 개발자들이 글을 쓰다 보면 자칫 알아듣기 힘든 기술 이야기로 빠져버리는 경우가 많아서 그럴까? "어떤 제품의 새 버전이 나왔어요" 이런 글보다 "오늘 부장이랑 코딩 컨벤션에 대해서 논쟁을 버리다 홧김에 ..." 뭐 이런 글들 많이 생기면 재밌을 것 같다. 임백준씨가 쓴 '뉴욕의 프로그래머'가 딱 그 스타일인데... 임백준씨 다음 소설 좀 쓰세요.

아무튼, 수요일 목요일 밤은 베토벤 바이러스 예약이다. ㅋ

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

(여기는 프로그래머 B 씨의 직장. 회의실에선 기획자와의 회의가 한 창이다.)

기획자 : "B 씨, 이 작업 언제까지 할 수 있을 것 같아요?"

아 또 시작됐다. 왜 방금 알게 된 작업의 스케쥴을 그 자리에서 말해줘야 되는 거지? 하여간 이해할 수 없는 사람들이야. 내가 나중에 내 회사를 가지게 되면 저렇게는 안해야지. 쯧. 아차, 시간이 너무 지체됐군. 어서 대답을 해주자. 그래야 능력있어 보이지. 좋아 일단 뭔가 생각하는 흉내를 내자.

('음' 하는 소리를 내며 연필 뒷꼭지를 입에 지그시 깨문다.)

어디보자. 일단 저 일을 할려면, 예전에 빼버렸던 소스코드들을 다시 살리는 것부터 해야겠군. 다행히 버전관리툴을 쓰고 있으니 그건 별 문제가 안 되겠어. 아니지. 그때 웹서비스 호출하는 프레임이 바꼈다고 해서 그 작업을 하다가 말았잖아. 프로젝트가 다음 버전에 릴리즈 안된다고 해서 관둔 거였는데, 하여간에 에휴. 아무튼 이건 코딩을 해야겠구나.

(눈동자를 빙글 빙글 돌려가며 뭔가 꼴똘히 생각하는 척을 한다. 한번씩 손을 꼽아가며 계산하는 모습을 보여주는 것도 잊지 않는다.)

그 다음은 어디 보자. 무슨 일을 더해야 되지? 세부작업이 큰 게 한 덩어리 있을 것 같은 느낌인데, 지금은 잘 모르겠네. 어라 사람들이 전부 나만 빤히 보고 있잖아. 뭔가 리액션을 줘야 돼. 질문을 하나 해서 시선을 돌리자.

"저거 X64 에서도 작동해야되죠?"
"당연하죠."

뭐 어차피 알고 있던 대답이었어. 사람들이 웅성웅성하며 자기들 것도 같은 작업을 해야하는지 생각하고 있군. 좋아. 먼저 큰 작업은 소스코드를 살리고, 예전 프레임웍을 쓰는 부분을 덜어내고, 새로운 프레임웍으로 교체해야겠군. 코드 살리는 거야 한, 두시간도 안 걸릴 거고 프레임웍 교체가 큰일인데. 예전 코드 덜어내는 거야 길어도 하루면 될 것 같고, 새로운 코드 구현은 어느 정돌까? 음. 뭐 대략 4일 정도면 되겠지? 하지만 조금 불안하니 5일로 하자.

(노트에 1+5 라고 쓴다.)

여기에 코드리뷰 받고, 테스터에게 빌드를 넘겨주려면, 어디보자. 5 일 정도 더 추가해야겠구나.

(아까 쓴 숫자 뒤에 다시 +5 라고 쓴다.)

어디보자. 토탈이 11 일이네? 뭐야 이거 두 주하고 하루 더 잖아. 깔끔하게 떨어지지 못하는데? 대략적인 스케쥴이면 주단위로 얘기해주길 바라는 것 같은데, 좋아.

B : "글쎄요. 아직 세부 작업들이 어떤 게 있는지 확인해 봐야 될 것 같은데.."
기 : "아니 뭐 내가 부담주려고 그러는 게 아니니까 편하게 얘기해요. 그냥 궁금해서 그러는 거니까"
B : "하하, 네. 음 확실하지는 않지만 대략 두주 하고 조금 더 걸릴 것 같습니다."

뭐야 그냥 물어보는 거라면서, 왜 미팅 노트에 꼬박꼬박 다 적어 놓지? 젠장, 이거 너무 빡빡하게 잡고 부른 것 같은데, 버퍼를 좀 둘 걸 그랬어. 그나마 '조금 더' 라는 애매모호한 표현을 써 놓길 잘했어.

(약간의 얘기가 더 오간 뒤, 회의는 끝이 났다.)

(그 후 뒷얘기)
사실 웹서비스를 위한 새 프레임웍의 핵심 기능이 아직 구현되어 있지 않았고, 해당 팀에게 문의를 해보니 앞으로 4일 뒤에 체크인 된다고 했다. 일정에 변경이 생겨야 했지만, 그 날 B 씨가 대답한 스케쥴에 맞춰 진행되고 있었고, 관리자의 끊임없는 쪼아대기 덕분에 불가능은 현실이 되어 2주 뒤 구현은 끝이 났다. 수 많은 버그와 함께.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

프로그래머들이 야근을 자주 한다는 이야기는 이미 숱하게 들어서 아실 겁니다. 오늘은 하고 싶지 않은 데 반 강제로 하게 되는 야근말고 자기가 좋아서 하게 되는 야근 이야기를 좀 해볼까 합니다.

유독 프로그래머 중에는 일 중독, 야근 중독이 사람들이 많습니다. 저녁 먹고 나면 그 때부터 제대로 시작하는 거지요. 적당히 늘어진 자세로 아무도 없는 사무실에서 집중하기 시작하는 겁니다.

플로우라는 게 있는 데요. 미하일 칙센트미하이라는 분이 쓰기 시작했다는 이 말은 고도로 집중한 상태를 말합니다. 다시 말하면 플로우는 ‘어떤 행위에 깊게 몰입하여 시간의 흐름이나, 공간, 더 나아가서는 자신에 대한 생각까지도 잊어버리게 되는 심리적 상태’ 를 뜻합니다.

하지만 안타깝게도 현실에는 프로그래머가 플로우 상태로 들어가는 걸 방해하는 게 너무 많습니다. 전화, 이메일, 주변의 소음 등이 넘쳐나지요. 게다가 밀려드는 일들 처리한답시고 이 일 저 일 왔다 갔다 하는 것도 집중을 저해하는 낭비지요. 특히 이 Context switching 의 경우, 기계와는 달리 많은 비용을 지불해야 합니다. 기껏 시작된 플로우 상태를 깨야 되는 것도 그 중 하나입니다.

플로우가 프로그래머에게 왜 중요하냐 하면 이 상태에서 프로그래머의 생산성이 몇 배나 높아지기 때문입니다. 뿐만 아니라 플로우 상태에서 코딩을 실컷 하고 다시 현실 세계로 돌아왔을 때의 그 기분은 이루 말 할 수 없습니다. 눈 앞에 펼쳐진 코드들과 그 코드들이 지향하는 논리의 작은 세계를 보고 있노라면 아주 뿌듯해 지지요. 이 집중의 순간이 프로그래머에겐 마약과도 같습니다.

그래서 그들은 플로우에 들어 갈 수 있는 입구를 찾느라 야근을 하곤 합니다. 물론 이 야근에는 몇가지 조건이 붙겠지요. 대충 꼽아보자면

1. 상사는 같이 야근을 하지 않아야 한다.
2. 주변에 사람이 없어야 한다.
3. 그 날 저녁은 한가지 일만 한다.

정도가 있겠네요. 사실 이외에도 많은 방해 요소가 더 숨어 있을 수 있습니다.

안타까운 것은 야근을 통해 플로우에 빠지는 것도 어느 정도 한계가 있다는 겁니다. 계속되는 야근은 일상이 되어 더 이상 집중력을 높이는 효과를 주지 못합니다. 역시 평상시 근무환경 개선에 중점을 두는 게 결과적으로는 더 좋겠네요. 야근은 어쩌다가 한번씩 할 수 있도록 하고요.

관련 링크

• 몰입
• 몰입의 즐거움 - Finding Flow

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

살다 보면 그런 사람들을 왕왕 만나게 됩니다. 개발자인데 반쪽이 없는 사람들 말입니다. 반쪽짜리 개발자란 기술에 너무 심취해 기술만능주의를 가지고 있거나, 다른 사람과의 커뮤니케이션 능력이 없는 사람들입니다.

예전에 봤던 기사를 링크 걸어 봅니다.

“내 꿈은 골방에 처박힌 프로그래머”

사실 개발자라면 누구나 그런 환상을 가져본 적은 있습니다. 어두컴컴하고 적막이 흐르는 방에서 모니터의 불빛에만 의존한 채 딸깍거리며 키보드를 두드려대는 모습. 모니터에는 곧 세상을 놀라게 해 줄 소프트웨어의 소스 코드들이 잔뜩 나와 있고 책상 옆에는 쌓여 있는 탄산음료 캔. 이런 해커의 환상을 누구나 한 번쯤 꿈 꿔 봅니다.

하지만, 눈을 뜨고 현실로 돌아오게 되면 다른 이야기죠. 다른 사람들과 떨어져서 할 수 있는 일은 거의 없습니다. 현실이라는 아날로그 세계에 있는 문제를 디지털의 논리로 풀고자 하다 보니 어쩔 수 없이 적절한 선에서 타협을 해야 합니다. 그리고 그 타협은 기획자와 개발자 사이의 커뮤니케이션을 통해 이뤄지기 일 수입니다. 그래서 골방 스타일의 프로그래머는 이런 환경에서 쉽게 도태되 버릴 수 있지요.

입만 살아 있는 개발자가 돼서는 안 되지만, 입을 열지 못하는 개발자가 돼도 안 될 것 같습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

류한석님이 zdnet 에 쓰신 칼럼 링크를 걸어둡니다. http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39158827,00.htm

한국에서 소프트웨어 개발자가 성공하지 못하는 이유를 몇가지 언급하셨네요. 그 중에서 개발자들의 커뮤니케이션 스킬에 대해 얘기를 해볼까 하네요.

셋째, 끝으로 개발자들의 커뮤니케이션 스킬 부족과 태도 문제를 지적하지 않을 수 없다. 이 문제는 한국적 기업문화(상명하복)와 결합하여 더욱 복잡한 문제를 야기하고 있다. 개발자들은 특히 다른 직종에 비해 성격이 까칠한 경우가 많다. 자신만의 지식과 세계가 있기 때문에 그것이 전부라고 우쭐한 채로, 다른 개발자나 다른 직종을 존중하지 못하는 사람들이 꽤 많다.

인용한 글에서는 개발자의 안 좋은 모습이 두 가지가 나왔네요. '까칠한 개발자' 와  '우쭐한 개발자'. 둘 다 좋지 않은 모습임에는 틀림 없습니다. 여기서 류한석 님이 말씀하신 건 Developer vs Other roles 에서 말씀하셨던 것들이고 저는 그냥 일반적 관점에서 특성을 말하고 싶은데요, 까칠함 과 우쭐함으로 나눠서요.

결론부터 말씀드리면 까칠한 개발자가 우쭐한 개발자보다 훨씬 낫다고 봅니다.

대부분의 까칠한 개발자들은 어느 정도의 선을 지켜주면 충분히 커뮤니케이션할 수 있고 때로는 그런 업무태도가 프로젝트 진행에 도움이 될 때도 있습니다.

보다 위험한 것은 '우쭐한 개발자' 라고 생각합니다. 자신의 실력에 대한 과신이 지나쳐 남을 깍아내리거나 일을 쉽게 보는 경향이 있기 때문입니다. 특히 일을 쉽게 생각한다는 것은 자신감이 있어보여 좋기도 하지만 다른 한 편으로는 업무 스케쥴링을 현실적으로 할 수 없다는 얘기도 됩니다.

우린 모두 코드 앞에 겸손해져야 되겠습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

회사일만 열심히 해서 실력도 쭉쭉 늘면 좋겠지만, 그게 그렇지는 않을 것 같아서 따로 스터디할 계획을 세워보려고 합니다. 이왕 하는 거 잘해보자 싶어 검색을 좀 해봤습니다.

김창준 님의 글이 가장 먼저 눈에 띄네요.
- 어떻게 공부할까? 프로그래머를 위한 공부론 -김창준-

알고리즘, 리팩토링, 익스트림 프로그래밍, 디자인 패턴등에서 학습 방법에 대한 좋은 얘기들을 알 수 있습니다.

piknic12 님의 공부 방법 이란 글도 읽을 만 합니다. 이 분은 여러 이야기들을 철학적으로 잘 풀어내십니다.

그리고 저번에 썼던 책들 모음 글 - 개발자가 읽으면 좋은 책들

말이 나왔으니 말인데, 저런 책 모음 글 같은 건 이제 쓰지 말아야겠습니다. 구체적인 독서 계획도 없이 "읽으면 좋은 책" 이 랍시고 긁어 모아 놨더니 부담감에 마음만 무겁네요. :( 공부는 항상 즐거운 마음으로 집중해서 하는 것이 중요하지요.

어쨋든 지금은 디자인패턴 책부터 읽기 시작했습니다. 이 글을 쓰기 전부터 이미 읽던 거였으니까 시작했다고도 하기도 좀 그렇네요. 원래는 GoF 책을 읽으려고 했지만, 아침 저녁으로 지하철에서 잠깐 보는 거라 우리말로 된 책을 중심으로 보고 GoF 책은 Reference 정도로 보려고 합니다.

  GoF 디자인 패턴! 이렇게 활용한다 

장세찬/한빛미디어
실제로 컴파일하고 실행할 수 있는 디자인 패턴의 완전한 구현-. 문제 유형과 해결 사례를 통해 디자인 패턴의 이해를 높인다. -. 일반적인 설계와 패턴 활용 설계의 비교를 통해 패턴 활용 능력을 자연스럽게 익...

이 책인데, 각 패턴별 문제 상황을 잘 만들어 설명해 주고 있어서 이해가 잘 됩니다.

아 원래 이 글의 의도는 공부 계획을 세우고자 함이었는데, 계획의 '계'자도 나오지 않고 이 만큼 와버렸네요. 일단 패턴공부한 것들을 틈틈이 정리해서 글로 써봐야겠습니다. 계획끝.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.