깔끔한 코드 작성을 위한 여러 전문가들의 글을 모아 놓은 책이다. 특정 프로젝트의 코드를 가지고 얘기하는 것들이 많아서 읽기에 조금 지루한 면도 없잖아 있었다. 그래서 몇몇 챕터는 읽지 않고 뛰어넘었다. 나중에 기회되면 다시 읽어보겠지.
Boy Scouts’ Rule : Leave the campground cleaner than you found it. -p14
One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. –p25
Ch3. Functions 는 흥미롭게 읽었다. Ch4. Comments 에서는 평소 아무 의심 없이 달던 주석에 의문을 품게 해줬다. Jeff Langr 글들은 짧지만 강렬한 인상이 남았다. (Ch10 Classes, Ch12 Emergence). Ch14, Ch15 는 코드가 너무 길어서 읽지 않았다.
이 책 읽으면서 느낀 생각인데, 코드가 잔뜩 담긴 글을 읽는 매체로서 ‘책’은 좀 어울리지 않는 것 같다. 동영상 + 소스코드가 훨씬 빠르고 효과적인 공부 방법 인 듯 하다.
업무상 의무적으로 만들어야 하는 프로그램은 아닌데, 자신의 업무를 보조하기 위해 만들어 쓰는 프로그램으로 어떤 것이 있습니까?
업무 외로 자신의 삶을 위해 프로그래밍해 쓰는 것이 있다면?
올해 들어 자신을 위해 만든 프로그램이 몇 가지인가요?
자신이 가장 가치를 느끼는(혹은 느꼈던) 자작 프로그램을 보여주세요.
자신이 직접 사용자의 역할을 해본 프로그래머들은 단순함의 가치를 알고 있습니다. 그 사람들은 어떤 소프트웨어가 진정한 가치를 주는지 몸으로 알고 있습니다. 다른 프로그래머들이 1000줄에서 얻을 가치를 이 사람들은 10줄에서 얻어 냅니다. (하지만 계속 뭔가 자기를 위해 만들어 내지만 완성한 것도 드물고, 또 1년 이상 개선시켜 가며 써본 것이 하나도 없는 프로그래머라면 이야기가 다릅니다.)
나는 나를 위한 프로그래밍을 해본 적이 있던가? 내가 쓰기 위해 만들어본 프로그램은? 프로젝트가 잠시 소강상태를 맞이하고 있는 요즘, 딱히 할 일이 없어 빈둥거리며 시간을 보내고 있다. 프로그램을 만드는 방법은 알지만, 왜 만들어야 하는지 몸으로 배우지 못했다. 소프트웨어가 사람을 어떻게 이롭게 하는지 바닥부터 차근차근 생각해 볼 일이다.
프로그래밍을 우물에서 한 두레박의 물을 길어 올리기 위해 크랭크를 돌리는 것으로 상상해보라. 작은 두레박일 때에는 자유롭게 돌아가는 크랭크로도 괜찮다. 큰 두레박에 물이 가득 담겨 있을 때에는 두레박이 다 올라오기도 전에 지쳐버릴 것이다. 몇 차례 크랭크를 돌리고 나면 쉴 수 있게 해주는 어떤 톱니바퀴 매커니즘이 필요하다. 두레박이 크면 클수록 톱니바퀴의 이빨이 더 촘촘해야 한다.
테스트 주도 개발의 테스트가 그 톱니바퀴의 이빨과 같다.
책 내용의 대부분은 Money 라는 클래스를 TDD 로 만들어 보는 데 할애하고 있다. 백 번 듣는 것 보다 한 번 보는 게 낫다는 이야기다. TDD 의 핵심은 간단하다.
빨강 – 초록 – 리팩토링
실패하는 테스트를 작성하고, 테스트가 통과하도록 만들고, 리팩토링한다. 하지만 역시 이걸 ‘잘’ 하는 건 쉽지 않다. 태권도의 움직임을 배우는 건 쉽지만 발차기를 잘 하려면 많은 노력이 드는 것과 같은 이치다.
“어려운 일을 힘든 일로 만든다” 라는 관점에서 봤을 때, 코딩을 어떻게 시작해야 할 지 넋 놓고 있을 개발자에게 명확한 가이드라인을 제시한다. 일단 테스트 코드를 만든 다음 수단과 방법을 가리지 말고 테스트가 성공하도록 한다. 그 다음은 Refactoring 이다. 이 과정 속에서 설계는 점점 나아질 것이고, 기능들은 자동화된 테스트들에 의해 보장받게 된다.
레거시코드를 수정할 때 어떻게 접근해야 하는 지 알려주는 책이다. 실제로 그 내용은 유닛테스팅을 이용한 전술 교본이라 할 수 있다. 막중한 임무를 가지고 낯선 환경에 홀로 떨어진 공수부대원처럼 친숙하지 않은 코드들 속에서 버그픽스를 시작 해야 할 때 어떤 목표를 가지고 어떻게 접근해야 하는지 잘 설명해준다.
책의 두께는 420page 정도로 그리 두껍지 않으나, 전부 읽는 데는 상당한 시간이 걸렸다. 마틴 파울러의 리팩토링도 아직 제대로 읽어보지 못했지만, 거기에 나오는 기법들의 많은 부분을 이 책에서도 소개해 주고 있어 이것을 읽고 그 책을 보면 수월하리라 예상된다.
XP 등의 애자일 방법론을 신봉하는 것은 아니지만, 그것들이 던져주는 메세지는 확실해서 좋다. 그 중에서 스크럼은 무척이나 간단하다.
스크럼은 럭비에서 공이 경기장 바깥으로 나가서 플레이를 다시 시작할 때 취하는 전술 대형을 말한다. 스크럼이 배제하려고 하는 제품 개발 프로세스와 럭비 경기 사이의 유사성 때문에 우리는 스크럼이라는 이름에 반해 버렸다. 둘 다 현실 적응적이고, 기민하며, 자기 조직적이다. 쉴 틈이 별로 없다.
스크럼을 하는 방법은 간단하다.
Product backlog 를 작성한다.
Sprint backlog 를 작성한다.
일일 스크럼 회의와 Burndown chart 를 활용하여 스프린트를 진행한다.
2,3 을 반복한다.
스크럼은 직설적이다. 스크럼은 부적절하고 성가신 관리 관행들을 날려버리고 오직 업무 그 자체만을 남겨둔다. 스크럼은 팀을 자유롭게 놓아두고 업무에 집중하도록 하며, 가능한 최고의 제품들을 만들 수 있도록 해준다. 비록 스크럼 프로세스가 간단하고 별거 없어 보여도, 스크럼은 개발자들로 하여금 업무에 집중해서 재빨리 고품질의 제품을 만들어 내도록 하는데 필요한 모든 관리 및 통제권을 제공한다.
더 이상의 자세한 설명은 생략하고, 아래 동영상을 보는 게 훨씬 이해가 쉬울 듯 하다.
자 이제 이렇게 괜찮은 걸 알게 됐는데, 이걸 어떻게 실제 업무에 도입하느냐 문제가 남는다. 의외로 애자일 프락티스에 반감을 가진 사람들이 많기 때문에 필요한 걸 도입할 때 몹시 조심해야될 필요가 있다. 옮긴이 글에 보면 이에 대해 좋은 조언이 있다.
연착륙을 시도하세요. 이상적으로 어떻게 해야 하는지에 대해서 이야기하는 책은 많습니다. 그러나 여러분의 상황에서 실제로 지금 당장 어떻게 해야 하는가를 알려주는 책은 어디에도 없습니다. 따라서 중간 단계를 신중하게 설정하는 것은 매우 중요합니다.
….
작게 시작하세요. 절대로 하루 아침에 회사 전체에 적용하려고 하지 마세요. 자신부터 시작해서, 같이 일하는 동료, 그와 일하는 다른 동료… 이런 식으로 서서히 퍼져나가도록 하십시오.
할 수 있는 것부터 시작하세요. 완벽하게 하려고 미루다가 하지 않는 것보다는 작은 거라도 일단 실천하는 게 좋습니다. …
이름 없이 시작하세요. 많은 사람이 변화를 싫어합니다. 그게 거창한 이름을 달고 있다면 더욱더 그렇습니다. 낯선 용어, 특히 영어로 된 용어는 절대 사용하지 마세요.
호의적인 사람들에 집중하세요. 호의적인 사람에게 집중하면, 그 사람도 즐겁고 훨씬 적은 수고로도 성과를 낼 수 있습니다. …
아 또 지각이다. 어제도 한 시쯤 잠이 들었다. 30분 정도 늦잠을 잤고 지금 허겁지겁 회사로 가는길이다. 아마 10 분정도 지각 할 것 같다. 어제와 마찬가지로 하루를 출발하는 기분이 영 좋진 않다.
10:04:42
보통 때는 지하철에 서서 책을 읽으며 가지만, 당분간은 가방을 안가지고 다니기로 했다. 어깨도 가볍고 홀가분하다. ‘딩동’ 이런 이메일이 도착했다. 파트너 팀들이 이런 저런 질문들을 해댄다. 출근을 일찍하는 테스터가 보낸 메일도 있다. 지하철 한켠에서 스마트폰을 꺼내 답장을 써내려간다. 몇 통 쓰다보면 어느새 내려야 할 곳에 와 있다.
10:51:56
이메일들을 처리하고, 버그 트래킹 툴을 실행한다. Priority 와 중요도 순으로 정렬을 한 다음 좀 쉬워 보이는 버그를 하나 골라 잡는다. 요즘 슬럼프라 짧고 빨리 끝낼 수 있는 일들을 우선 하기로 했다. 개발 머신에 접속하여 곧바로 버그를 잡기 시작했다.
13:05:34
간단한 버그 하나 픽스를 완료하고, 점심을 먹으러 갔다 왔다. 팀 사람들 몇몇은 회의가 있어 햄버거를 사서 점심을 대신했다. 햄버거가 내키지 않아 남은 사람들과 곰국을 먹고 왔다. 아침을 못 먹고 나왔었는데, 밥을 먹고 나니 포만감에 편안해진다.
13:13:33
자리에 앉자 마자 바로 오후에 작업할 버그를 고르고 준비한다. 내일 하루 종일하는 교육이 잡혀 있어 오늘 버그를 많이 잡아두지 않으면 이번주 스케쥴이 밀릴 수 있다. 그래서 될 수 있으면 오늘내로 많은 버그를 수정해둬야 한다. 아무래도 오늘은 야근을 피할 수 없을 듯 하다.
16:17:57
PM 과 tester 가 찾아와 어제 고친 버그 중 하나를 그냥 고치지 말고 그대로 두자고 했다. 헛수고 한 것 같아 조금 기운이 빠졌다. 다음 부터는 버그 고치기 전에 그게 적절한 priority 를 메겨놨는지 다시 한번 확인해야겠다.
17:38:57
온 몸이 저리고 피곤하다. 잠시 자리에서 일어나 스트레칭을 한다. 목과 팔을 몇번 돌리고 발끝 잡기를 시도 해 본다. 갑자기 굽히니 피가 쏠려 어지럽다. 회사에서 헬스클럽 등록비를 지원해준다는 메일이 왔다. 오랜만에 웨이트 트레이닝이나 다시 시작해볼까?
19:22:27
야근을 할려다 오늘 집에가서 하지 않으면 안되는 일들 -주로 세탁,청소 따위의 생존을 위한 필수 액션 - 이 있다는 것을 깨닫고 회사를 나섰다. 그나마 다행인건 퇴근 전 버그를 하나 더 잡았다는거. 코드리뷰를 보내놓고 집으로 향한다.
어제 잠들기 전 불현듯, 내 하루를 일일이 기록해보면 어떨까 하는 생각이 들었다. 한시간 단위로 한번씩 기록을 해보려고 했지만, 일하는 중에 그리 뜻대로 되진 않더라. 쭉 써놓고 나니까, 아침에 버그 잡고 오후에 버그 잡고 그냥 그게 그거다. 다음에는 다른 형식으로 또 하루를 남겨봐야 겠다.
소프트웨어 개발이라는 건 결국 무한히 계속되는 버그 수정이다. 아쉽게도 이 버그들은 결코, 절대, 바닥나지 않는데 그것은 현실의 불완전함에 기인한다. 음 표현이 조금 이상하다. 현실의 불완전함이라기 보다는 인간의 불완전함이 더 맞겠다. 세상은 그 자체로 완전하게 존재하고 있지 않은가! 다만 그것을 받아들이는 우리 인간이 불완전한 존재일 뿐이니까. 더 엄밀히 말하면 세상을 알아가는 우리의 인식이 완전치 못하다.
그리고 또 하나의 세계가 있다. 이건 순전히 허구속에 존재하는 세계인데, 가증스럽게도 한계가 명백한 인간들이 만든 세계다. 그것은 참 아니면 거짓이라는 흑백논리 속에 존재하며, 그 자체로는 완벽해 보이지만 허술하기 짝이 없다.
개발자들의 문제는 이 두 세계를 잇는 대서 출발한다. 불완전한 머리로 이해한 현실을 나름 완전해 보이는 논리 세계로 옮길 때, 이 두 우주의 간극에서 버그들이 튀어나온다. 그것도 끝도 없이. 그러니 이 직업을 평생 가져가기로 마음을 먹었다면 이 거대한 모순 앞에 당당히 마주설 각오부터 해야 할 것이다. 버그를 만드는 게 내 일이고 그걸 다시 고치는 게 내 일이다.
그럼 이 우주적 모순과 반복되는 일상에서 우리는 무엇을 추구해야 하는가? 그것은 통찰력이다. 하루에 천번의 정권 찌르기 연습을 하는 무도가처럼 우리는 일상의 반복에서 모종의 '득도'와도 같은 깨달음을 얻어야 한다. 그것은 작게는 함수와 클래스의 디자인에 대한 통찰력일 수도 있고, 보다 크게는 소프트웨어와 그 개발 프로세스에 대한 통찰일 수도 있다. 또한 요구사항 변경과 요동치는 현실에 대한 꿰뚫음일 수도 있다.
그럼 어떻게 해야 '득도'를 할 수 있는가? 여기에 명확히 알려진 방법 같은 건 없다. 다만 한가지 확실한 건 반복, 통찰, 성장의 과정이 행성계의 궤도들과 유사하다는 것이다. 계단형 성장이라고 봐도 비슷한데, 어느 순간에 성장을 통해 자신의 궤도를 능가해 다음 궤도를 달리게 되는 식이다. 그래서 궤도를 바꾸기 위해 우리가 첫번째로 성취해야 하는 것은 빠른 속도다. 일상의 반복들을 전보다 빠르게 해결할 수 있는 데 집중하면 구심력이 특정치를 넘어설때 성장이 일어나 다음 궤도를 돌고 있는 자신을 볼 수 있게 될 것이다.
급하게 쓰다 보니 글과 거기에 담긴 생각이 짧기 그지 없다. 딱히 결론이라고 낼 만한 것도 없지만, 그래도 일상의 반복들이 날 단련할 수 있는 기회라 믿고 오늘도 버그 잡고 스케쥴에 쪼이러 간다.
저자의 통찰력에 깊은 인상을 받았다. 스타트업 기업을 만들어 야후에 성공리에 인수 합병 시킨 경험들 속에서 그가 터득한 것들을 이야기 하는데, 언어 뿐만이 아니라 프로그래밍, 공부, 돈, 회사 등에 대해서도 독특한 시각을 가지고 있다. 책을 읽으며 줄을 그어 놨던 몇 구절들을 인용해본다.
프로그래밍 언어는 당신이 이미 머릿속으로 생각한 프로그램을 표현하는 도구가 아니라, 아직 존재하지 않는 프로그램을 생각해 내기 위한 도구다. - 2. 해커와 화가
사람들이 이 부분에서 길을 잃고 혼란스러워 하는 까닭은 돈을 추상화시켰기 때문이다. 돈은 부가 아니다. 돈은 단지 부를 움직이기 위한 수단에 불과하다. 그렇기 때문에 다른 사람과 교환할 수 있는 화폐 양이 어느 일정한 순간에는 일정한 분량으로 정해져 있다고 해도, 세상에 존재하는 부의 크기는 일정한 값으로 정해져 있는 것이 아니다. - 6. 부자가 되는 법
어떤 부분에서는 조금 독선적이라고 느껴졌던 것도 있었지만, 글에 스며있는 깔끔한 논리가 부족한 부분을 잘 채워주는 것 같다.
미래의 프로그래밍 언어에 대한 이야기를 하는 11 장이 특히 재미있었다.
비효율적인 소프트웨어가 그 자체로 엉터리인 것은 아니다. 진짜 엉터리는 프로그래머에게 불필요한 일을 하도록 강제하는 언어다. 기계의 시간이 아니라, 프로그래머의 시간을 낭비하는 것이 진짜 비효율성이다. 컴퓨터의 속도가 더 빨라질수록, 이러한 사실은 점점 더 명확해질 것이다. - 11. 100 년 후의 프로그래밍 언어
옳은 말이다. 하드웨어의 속도는 지금껏 그랬듯이 그 때 까지도 빠르게 증가할 것이고, 그 환경에서는 프로그래밍 패러다임이 지금과는 많이 달라져 있을 것이다. 그렇기에 표현력이 좋은 언어, 익숙하지 않은 언어를 하나 정도는 꼭 익혀봐야 될 필요가 있다.
문제의 하나는 어떤 언어를 오랫동안 사용하면, 어느 순간부터 사고 자체가 그 언어로 이루어진다는 사실이다. 이런 상황이 되면 실질적으로 다른 내용을 가지고 있는 언어는 그게 어떤 모습을 가지고 있든 상관없이, 본질적으로는 잘못된 것이 아무것도 없음에도 불구하고, 터무니없는 엉터리 언어로 보이게 된다. 경험이 부족한 프로그래머들이 언어에 대해서 내리는 판단은 종종 이러한 심리적 효과에 의해서 왜곡된다. - 10. 프로그래밍 언어에 대한 설명
책을 읽고 난 결론. "SICP 좀 더 열심히 봐야 겠다."
프로그램은 오직 사람이 읽기 위해서 작성되어야 한다. 컴퓨터가 그것을 실행하는 것은 부차적인 일이다. - SICP
어떤 경우에 assertion 을 써야 하는 지 Code Complete 를 보고 한번 정리해봤습니다.
절대 일어나선 안되는 경우에만 assertion 을 써라
함수에서 에러인 경우로 리턴되는 상황은 두가지로 나눠볼 수 있습니다. 예측했던 에러와 예측하지 못했던 에러. 이 중 assertion 을 써야 되는 건 후자 입니다. 일어나선 안되는 경우 에러 핸들링이 되지 않는 경우에 assertion 을 씁니다.
assertion 에 executable code 를 넣지 마라
assertion 구문은 debug 빌드에서는 활성화되지만 ship 빌드 경우에는 수행되지 않는 경우가 많습니다. 특히 assertion 을 위한 특정 매크로를 만들어 쓰는 경우라면 더욱 그렇습니다. 그러므로 assertion 에는 결과 값을 확인하는 코드만 넣고 프로그램의 수행에 영향을 줄 수 있는 코드는 사용하지 말아야 합니다.
도큐먼트화와 precondition 과 postcondition 검증에 assertion 을 써라
assertion 은 함수의 시작 부분에서 들어온 parameter 가 유효한지 검증할 때도 쓸 수 있고, 함수가 끝날 때 리턴값 검증에도 쓸 수 있습니다. 이 precondition / postcondition 체크 외에도 특정 제약조건들에 대해서도 사용하면 도움이 됩니다. 예를 들어 이 시점에서 얻어온 SampleObject 라는 오브젝트가 가지고 있는 Count 라는 property 는 10 보다 커야 한다. 코드 자체가 아니라 spec 등에서 생겨난 제약사항들에 대해 assertion 을 해두면 그 자체로 도큐먼트 효과가 생깁니다. 나중에 코드를 볼 때 한결 이해하기 쉽겠지요.
보다 튼튼한 코드를 만들려면 assert 한 뒤 에러를 어떻게든 처리하라
assertion 이 발생한 경우에 대해서도 될 수 있으면 에러 핸들링 코드를 달아두는 게 좋습니다. 보통 assertion 이 생길 정도라면 어떻게 해볼 수 없는 상황일 때도 많은 데 그런 경우라 하더라도 최소한 애플리케이션이 크래쉬가 된다거나 하는 최악의 상황은 막고 종료할 수 있도록 처리를 해두면 금상첨화입니다.
프로그래밍 수련법 - 브라이언 W. 커니핸.롭 파이크 지음, 장혜식.신성국.김정민 옮김/인사이트
이 책에 대해서는 혹평을 하지 않을 수가 없네요. 인사이트 출판사는 알찬 IT 책들을 많이 내줘서 아주 좋아하는데, 이 책만큼은 독자를 낚아 올린 책이더군요. 책 제목이 프로그래밍 수련법이라고 되어 있는데, 의도한 건지는 모르겠지만 잘못된 번역입니다. '실전 프로그래밍' 정도가 적절합니다.
아마도 저자가 의도한 독자층은 이제 막 문법을 익히고 프로그래머로 시작하려는 학생들이 아닐까라고 생각됩니다만, 표지로 사용한 무예도보통지나 '수련법' 이라는 단어는 이걸 오도하기에 충분해 보이네요.
그러다 보니 브라이언 커니핸 이라는 대가가 쓴 책임에도 크게 얻을 만한 내용이 없습니다. 아 표현이 좀 잘못됐네요. 얻을 게 없다기 보다는 제가 기대했던 '수련법' 에 대한 내용은 없습니다. 프로그래밍과 테스트 디버깅에 관해 예제 프로그램을 만들어가며 저자가 자신의 노하우를 알려주지만 보다 깊게 다뤄주었으면 하는 아쉬움이 남습니다.
책의 두께는 얇습니다만 크기는 커서 읽어야할 글의 양은 꽤 됩니다. 지하철에서 들고 읽기에 조금 불편할 정도의 크기라서 후딱 읽고 책장에 넣어두고 싶은데, 재미가 없다보니 읽는 것도 지지부진이네요.
이 책이 쓰인지 40년 가까이 된다는 사실이 믿어지지 않네요. 지금의 소프트웨어 분야에도 시사하는 바가 적지 않습니다. 인상 깊었던 구절들을 옮겨와 봤습니다.
예를 들어 어떤 프로그래밍 작업은 팀 크기가 아무리 크다 해도 초보자들만으로는 불가능하기 때문에, 경제에서 말하는 인력을 두 배로 늘려도 전혀 소용이 없을 것이다. 일정에도 이와 비슷한 특성이 있는데, 여성을 9명 동원하여 한 달 만에 아이를 낳게 해보려 했다는 우스꽝스러운 실험만 예로 들어도 무슨 뜻인지 이해될 것이다.
프로그래머를 많이 붙인다고 프로젝트의 진행속도가 빨라지지 않습니다. 협력이 효과를 보려면 몇 명 이하의 적절한 수 안에서 만이겠죠.
최소의 비용으로 최고의 프로그래밍을 원한다면, 가능한 한 최고의 프로그래머들을 구하고 그들에게 최소한의 인원으로도 문제가 없을 만큼 충분한 시간을 주어야 한다.
적당히 코딩할 줄 아는 프로그래머를 낮은 임금에 고용한 다음 가차없이 닦달을 해대면 언젠가는 프로젝트가 끝이 날 거라는 믿음을 가진 관리자들이 있습니다.
따라서 프로젝트를 오랜 기간 동안 안정적으로 수행하려면, 관리자는 프로젝트가 일종의 프로그래머 생산 공장으로 기능하도록 만들어야 한다. 즉, 초보자라는 신선한 재료를 공급 받아 숙련된 리더를 생산하는 것이다.
개발팀이 어떤 내부 순환을 타고 있어야 하는 지 잘 말해주는 문장입니다. 초보 프로그래머를 숙련 프로그래머로 키워낼 수 있는 역량을 가진 팀이라야 한단계씩 계속 발전해 나갈 수 있습니다.
절대 없어서는 안 될 프로그래머가 있다면, 한시라도 빨리 그를 프로젝트에서 제거하라.
이건 앞 뒤 문장을 잘라내서 뜻이 잘못 전달될 수도 있겠네요. 원 문장의 뜻은 프로그래머의 지식과 기능을 팀 단위로 확장해서 공유하라는 이야기였지요.
마지막으로, 프로그래머에게는 유머감각이 필요하다. 컴퓨터는 자신 앞에 앉은 사람을 모두 바보로 만드는 기계이기 때문에 우스꽝스러운 꼴을 당한 자신의 모습을 웃고 넘길 수 없는 사람이 프로그래머로 오랫동안 버티기는 어렵다.
프로그래밍 언어가 진보하려면, 성배를 찾으려는 즉, 프로그래밍을 위한 진짜 언어를 찾으려는 노력을 그만둬야 한다. 프로그래밍 언어는 절대로 인간의 언어와 같을 수 없기 때문이다. 우리가 추구해야 할 것은 프로그래밍 언어를 더 자연스럽게 만드는 일이다.
이 외에도 정말 주옥같은 얘기들이 많습니다. 제랄드 M.와인버그, 그 놀라운 통찰력을 정말 존경하지 않을 수가 없네요.
아 또 시작됐다. 왜 방금 알게 된 작업의 스케쥴을 그 자리에서 말해줘야 되는 거지? 하여간 이해할 수 없는 사람들이야. 내가 나중에 내 회사를 가지게 되면 저렇게는 안해야지. 쯧. 아차, 시간이 너무 지체됐군. 어서 대답을 해주자. 그래야 능력있어 보이지. 좋아 일단 뭔가 생각하는 흉내를 내자.
('음' 하는 소리를 내며 연필 뒷꼭지를 입에 지그시 깨문다.)
어디보자. 일단 저 일을 할려면, 예전에 빼버렸던 소스코드들을 다시 살리는 것부터 해야겠군. 다행히 버전관리툴을 쓰고 있으니 그건 별 문제가 안 되겠어. 아니지. 그때 웹서비스 호출하는 프레임이 바꼈다고 해서 그 작업을 하다가 말았잖아. 프로젝트가 다음 버전에 릴리즈 안된다고 해서 관둔 거였는데, 하여간에 에휴. 아무튼 이건 코딩을 해야겠구나.
(눈동자를 빙글 빙글 돌려가며 뭔가 꼴똘히 생각하는 척을 한다. 한번씩 손을 꼽아가며 계산하는 모습을 보여주는 것도 잊지 않는다.)
그 다음은 어디 보자. 무슨 일을 더해야 되지? 세부작업이 큰 게 한 덩어리 있을 것 같은 느낌인데, 지금은 잘 모르겠네. 어라 사람들이 전부 나만 빤히 보고 있잖아. 뭔가 리액션을 줘야 돼. 질문을 하나 해서 시선을 돌리자.
"저거 X64 에서도 작동해야되죠?" "당연하죠."
뭐 어차피 알고 있던 대답이었어. 사람들이 웅성웅성하며 자기들 것도 같은 작업을 해야하는지 생각하고 있군. 좋아. 먼저 큰 작업은 소스코드를 살리고, 예전 프레임웍을 쓰는 부분을 덜어내고, 새로운 프레임웍으로 교체해야겠군. 코드 살리는 거야 한, 두시간도 안 걸릴 거고 프레임웍 교체가 큰일인데. 예전 코드 덜어내는 거야 길어도 하루면 될 것 같고, 새로운 코드 구현은 어느 정돌까? 음. 뭐 대략 4일 정도면 되겠지? 하지만 조금 불안하니 5일로 하자.
(노트에 1+5 라고 쓴다.)
여기에 코드리뷰 받고, 테스터에게 빌드를 넘겨주려면, 어디보자. 5 일 정도 더 추가해야겠구나.
(아까 쓴 숫자 뒤에 다시 +5 라고 쓴다.)
어디보자. 토탈이 11 일이네? 뭐야 이거 두 주하고 하루 더 잖아. 깔끔하게 떨어지지 못하는데? 대략적인 스케쥴이면 주단위로 얘기해주길 바라는 것 같은데, 좋아.
B : "글쎄요. 아직 세부 작업들이 어떤 게 있는지 확인해 봐야 될 것 같은데.." 기 : "아니 뭐 내가 부담주려고 그러는 게 아니니까 편하게 얘기해요. 그냥 궁금해서 그러는 거니까" B : "하하, 네. 음 확실하지는 않지만 대략 두주 하고 조금 더 걸릴 것 같습니다."
뭐야 그냥 물어보는 거라면서, 왜 미팅 노트에 꼬박꼬박 다 적어 놓지? 젠장, 이거 너무 빡빡하게 잡고 부른 것 같은데, 버퍼를 좀 둘 걸 그랬어. 그나마 '조금 더' 라는 애매모호한 표현을 써 놓길 잘했어.
(약간의 얘기가 더 오간 뒤, 회의는 끝이 났다.)
(그 후 뒷얘기) 사실 웹서비스를 위한 새 프레임웍의 핵심 기능이 아직 구현되어 있지 않았고, 해당 팀에게 문의를 해보니 앞으로 4일 뒤에 체크인 된다고 했다. 일정에 변경이 생겨야 했지만, 그 날 B 씨가 대답한 스케쥴에 맞춰 진행되고 있었고, 관리자의 끊임없는 쪼아대기 덕분에 불가능은 현실이 되어 2주 뒤 구현은 끝이 났다. 수 많은 버그와 함께.
아주 재밌게 읽었습니다. 내용도 무겁지 않고 경험담도 많은 IT 에세이를 좋아하는데, 이 책이 딱 제 입맛인 것 같네요. 책을 다 읽고 나니 마치 업계의 오랜 선배와 긴 시간 동안 이야기를 한듯한 기분이 듭니다.
이야기는 중국, 인도 등에서 쏟아져 나오는 개발자들에 대한 것들에서부터 시작됩니다. 싼 인건비와 적당한 수준의 실력으로 무장한 이들에게 마냥 밥그릇을 뺏기고 있을 것이냐? 그렇지 않으려면 어떤 노력들을 해야 될 것인가? 결국 이야기는 개발자들의 자기 계발로 이어집니다.
Stage 1-6 로 나누어 이야기하는데, 자신이 일할 분야를 선택하는 문제에서 멘토링, 하루를 사는 자세, 마케팅에 대한 인식을 가지는 것 등 많은 걸 이야기해줍니다. 인용하고 싶은 문구들이 무척 많은데 그 중 몇몇개만 써봅니다.
전설적인 재즈 기타리스트 팻 메스니(Pat Metheny)는 젊은 연주자들에게 조언을 한마디 했다. "속해 있는 밴드에서 항상 가장 못하는 사람이 되라."
무엇인가를 정말 배우고 싶다면 그것을 다른 누군가에게 가라쳐 보라. 어떤 것에 대한 이해를 구체화하는 데 가장 좋은 방법은 다른 사람들이 이해할 수 있도록 그것을 표현하는 것이다. 말을 한다는 것은 단순한 행동이지만 불분명한 사고를 다루는 데는 특효약이다. 인형과 같은 물체와 얘기하는 것은 소프트웨어 개발에서 전승되어온 잘 알려진 문제 해결 수단 중 하나다.
신중하게 근무시간 계획을 세우라. 적게 일하면 더 많은 것을 성취할 것이다. 쉬어야 일도 더 즐겁다.
이 외에도 가슴에 와닿는 많은 부분들이 있었는데 전부 인용하지는 못하겠네요. 곁에 두고 한번씩 펼쳐봐야겠네요.
세계 1 위의 자동차 제조 회사인 도요타로부터 소프트웨어 개발에 대한 지혜를 배울 수 있게 해주는 책입니다. 높은 품질을 유지하면서 파트너사들로 부터 존경받고 업계의 경쟁에서 1 위를 할 수 있었던 그 노하우를 소프트웨어 개발에 적용시켜 봅니다.
예전부터 소프트웨어 개발은 다양한 분야에서 그 모델을 가져왔었는데, 가장 대표적인 경우는 건축 입니다. 아키텍트의 설계가 끝난 다음 공사가 시작되지요. 소프트웨어 개발도 이것을 본 떠 Waterfall 방식으로 진행되던 때가 있었습니다. 하지만 문제점들이 들어났고, 많은 개량이 가해졌습니다. 건축에서도 고정된 설계는 그다지 환영받지 못하는 추세입니다. (애자일이야기 : 건축 비유)
설계는 그 자체만으로 완전할 수 있습니다. 하지만 그것이 몹시도 불완전한 인간이라는 존재를 통해 현실 세계에 구현 될 때는 변경이 불가피해 집니다. 아마도 이 세계가 가지고 있는 복잡성이란 게 그만큼이나 다루기 힘들다는 이야기이겠지요.
어쨋든 여기 그 복잡성을 멋지게 다뤄내는 1 위의 자동차 기업, 도요타가 있습니다.
도요타 생산방식의 아버지 중 한 사람인 오노 다이이치는 직원들의 지속적인 프로세스 개선을 촉구하며 이런 말을 했다고 한다. "한 달 동안 표준을 바꾸지 않으면 회사에서 돈을 훔치고 있는 것이다." 명백히 도요타의 표준은 따르라고 있는 것이 아니고 개선하라고 있는 것이다.
- 김창준, 감수의 글 중에서
그렇습니다. 현실의 복잡도를 한번에 다 이해하지 못할 바에야 끊임없이 다시 배우고 고치는 자세를 가지는 것이 바람직합니다. 도요타는 이것을 실천에 옮긴 기업이며 그로 인해 많은 수익을 얻어냈습니다.
린 소프트웨어 개발방법은 도요타의 이런 태도에서 영감을 얻은 것입니다. "모든 불필요한 낭비를 제거하라" 라는 모토에서 시작하여 크게 7 가지의 원칙을 제시합니다.
1. 낭비를 제거하라
낭비는 제품에 가치를 부가하지 못하는 모든 것을 일컫는데, 이때 가치란 고객이 인지하는 것을 말한다.
2. 배움을 증폭하라
소프트웨어 개발은 정해진 방법대로 요리를 만드는 게 아니라 조리법 그 자체를 만드는 것과 유사합니다. 그렇기에 처음부터 완벽한 조리법을 만들 수 는 없습니다. 여러가지 변형을 거쳐 맛이 더 좋고 쉬운 방법을 찾게 됩니다. 이런 변화와 시도가 조직을 통해 증폭될 수 있도록 하라는 이야기 입니다.
3. 가능한 늦게 결정하라
이것은 결정을 차일피일 미루라는 것이 아니라 될 수 있는 한 많은 정보를 얻은 후 결정을 하라는 이야기 입니다. 이렇게 함으로서 불확실하게 바뀌는 현실에 보다 빠르고 유연하게 대응할 수 있게 됩니다.
4. 최대한 빨리 납품하라
익스트림 프로그래밍에서도 강조하던 요소입니다. 고객에게 빨리 배달하고 피드백을 얻는 것이 시간을 들여 고객의 의도를 추측하는 것보다 낫다는 이야기지요.
5. 팀에 권한을 위임하라
6. 통합성을 구축하라
통합성을 지닌 완전한 소프트웨어는 구조가 일관되고, 목적에 대한 유용성과 적합성에서 높은 점수를 받으며, 유지보수가 가능하며 적응성과 확장성이 좋다.
7. 전체를 보라
업계의 1위 자리를 유지하려면 끊임없는 자기 혁신 없이는 불가능합니다. 오노 다이이치의 말처럼 현재의 도요타는 혁신을 버릇으로 만드는 좋은 문화를 가지고 있는 것 같습니다. 그것은 계속 바뀌는 현실에 보다 높은 적응력을 제공해줍니다. XP 에서 이야기하는 것과 도요타가 외치는 것들의 본질은 같다고 할 수 있습니다.
좋은 개발자를 뽑으려면 어떻게 해야 하는가? 라는 질문에 대한 조엘의 대답을 볼 수 있는 책입니다. 과연 우리나라에서도 저런 식으로 할 수 있을까 싶은 내용도 있지만 천리길도 한걸음 부터 아니겠습니까?
얘기를 하기 전에 잠깐 이 책에 단점들을 얘기하자면, 먼저 표지에 적혀있는 '조엘 온 소프트웨어 시즌2' 라는 문구는 출판사의 100% 낚시질입니다. 아래의
이 책과는 같은 사람이 썼다는 것 말고는 하등 상관이 없습니다. 그리고 책 뒤의 몇 챕터는 조엘 온 소프트웨어에 있는 내용 그대로를 가져다 놔서 이미 읽어보신 분이라면 그냥 넘어가시는 게 나을 겁니다.
자 다시 돌아와서, 이 책의 원제는 Smart and Gets things done 입니다. 조엘이 인재 채용의 원칙으로 삼는 문구인데요. 1. 영리하고 (Smart) 2. 주어진 일을 완벽하게 처리할 수 있는(Get things done) 사람을 뽑아야한다고 합니다.
고급 인재들을 구하기 위한 원칙으로는
범을 잡으려면 산으로 가라 - 개발자들이 많이 오는 컨퍼런스 등에 참석하고
인턴십 제도를 활용하라 - 인턴십을 이용해 잠재력있는 인재를 미리 점찍고
독자적인 공동체를 형성하라 - 블로그등을 통해 구축한 공동체에서 인재를 물색하라
라고 합니다. 어느 것 하나 쉽지 않아 보이네요. 특히 2 번의 경우는 갓 시작한 벤처기업으로서는 해보기가 쉽지 않을 것 같습니다.
또 좋은 개발자를 끌어들이기 위한 물리적인 방법으로는 개인 사무실, 깨끗하고 좋은 작업장 환경, 좋은 의자, 듀얼 모니터 등을 가능한 제공하라고 하네요. 비물리적인 것들로는 조직내에서의 대우, 좋은 동료들, 독립과 자율, 정략의 배제가 중요하다고 합니다.
그 외에도 이력서를 분류하는 방법, 현장 인터뷰 및 전화 인터뷰의 중요성과 주의할 점 등에 대해 이야기 합니다.
책에서 이야기하는 대로 된다면 그야말로 개발자 천국 같은 회사겠습니다만 그렇다고 그게 아주 불가능한 이야기들은 아닙니다. 구글의 유명한 업무환경이나 마이크로소프트의 인재채용방식은 조엘이 이야기하는 것들과 상당수 부합합니다. 우리 나라 기업들도 하나, 둘 문화를 바꿔가면 좋겠지요.
이 책이 가장 필요한 사람은 경험이 많지 않은 인사담당자들일 겁니다. 개발자 집단이 가지는 성격이 워낙에 독특한 지라 인사 담당자가 좋은 개발자를 알아보지 못하는 수가 많습니다. 그외에도 우리 회사에는 왜 개발자들이 오래 머무르지 않을까 라는 생각을 하고 계시다면, 이 책을 사장이나 간부들에게 권할 만합니다.
오늘 팀원들에게 세미나를 준비해서 발표했습니다. 집에 인터넷이 안 돼서 일요일 저녁에 회사를 가는 기염을 토했음에도 아침내 내 준비하면서 여전히 부족함을 느꼈습니다. 다른 프레젠테이션과는 달리 개발 관련 프레젠테이션은 발표 내용을 발표자가 숙지했는지 확 티가 나기 때문에, 이번 발표를 미뤘으면 했지만 스스로 뱉어낸 약속이라 억지로 밀어붙였습니다.
아니나 다를까 발표시간 내내 묻는 말에 제대로 대답도 못하고 더듬대는 모습만 보이다 시간이 다 지나버렸습니다. 샘플로 만든 코드마저 엉성하기 짝이 없어 정말이지 엉망이 돼버린 발표였습니다. 팀원들의 시간을 뺏은 듯해서 더욱 미안하더군요.
이메일로 싹 다 알려드리겠습니다. ㄳ
제가 발표 같은 걸 못하는 편은 아닙니다. 군중 공포증 같은 것도 없고요. 하지만, 발표 내용이 코드와 관련된 걸 하다 보면 정말이지 말로 모면할 수 없는 상황을 만나게 됩니다. 그도 그럴 것이 짧은 시간 준비해서는 코드가 작동하는 밑바닥까지 이해하기가 어렵거든요. 뭐 어쨌든 그럴 때면 앞이 막막한 게 마구 머리를 굴려 순식간에 답이 나오면 다행이지만 그렇지 않으면 '알아보고 이메일로 알려드리겠습니다.' 이거밖에 할 말이 없죠.
이번 추석 고향을 갔다 오는 동안 기차 안에서 읽은 책입니다. 저자인 임백준씨는 프로그래밍 에세이를 많이 쓰시는 분이죠. 프로그래밍에 대해서 기술 서적도 아닌 에세이를 쓸 만한 거리가 있나 싶지만, 프로그래머의 어쩌면 지루해 보이기도 하는 일상을 아주 재밌게 잘 묘사하시는 분입니다.
지금까지 몇 권의 에세이를 써왔지만 책을 쓰는 목적은 언제나 변함이 없었다. 그것은 '장시간 노동'에 시달리는 것에 비해서 '예술적'이고 '창조적'인 열정을 제대로 인정받지 못하는 프로그래머들이 잠시 머리를 식힐 때 재미있게 읽을 수 있는 글을 쓰는 것이었다.
임백준씨가 저자의 말에 쓴 위 글처럼 이번에 나온 '뉴욕의 프로그래머' 도 쉽고 재미있게 읽을 수 있는 글입니다. 다만, 한 가지 다른 점은 소설의 형식을 빌렸다는 것인데, 기승전결이나 갈등구도 등은 없지만 등장인물들을 전해주는 소프트웨어 개발자들의 하루하루는 충분히 빠져들게 합니다.
Concurrent Exception으로부터 시작되는 이야기는 천재 프로그래머의 전설을 거쳐, 경험이 있는 프로그래머, 자유분방한 프로그래머, 허울뿐인 프로그래머 등 다양한 사람들의 이야기를 풀어갑니다. 그중에서 주인공 '영우' 는 저자 자신을 인물로 만든 걸로 보입니다. 한국에서 왔으며 약간은 내성적이기도 하지만 가슴 속에는 열정을 담고 있습니다. 또 자기 멋대로 지만 GUI만큼은 잘 만드는 콜린이라든가 천재 프로그래머인 프라빈 등의 다양한 인물들은 저자가 만났던 많은 프로그래머를 투영시킨 것일 겁니다.
버그를 잡고 패치를 만들고 소스 트리에 Fix를 집어넣는 등의 프로그래머의 '업무'를 세세히 묘사한 글들을 보고 있노라면, 저 사람들은 정말 재밌게 일하는구나 싶습니다. 저도 매일같이 하는 것들임에도 소설 속의 인물들이 하는 게 더 재밌어 보이지요. 그들이 미국이라는 선진국의 뉴욕이라는 대도시에서 일해서 그런 걸까요? 아니겠죠. 그건 아마 임백준씨의 프로그래밍에 대한 열정이 인물들 하나하나에 배어들었기 때문일 겁니다. 반복되는 업무에 시들해져 가는 가슴을 다시 따뜻하게 데워주는 군요.
한겨레에 올라온 기사가 국내 엔지니어 처우 논란에 다시 불을 지피네요. 이런 논의가 더욱 활발하게 이루어져야 된다고 봅니다. 왜냐하면 이건 벌써 엔지니어 개인의 문제를 넘어섰기 때문이지요. 자기에게 주어진 일을 제 때 못해 야근을 하게 되면 그것은 개인의 문제겠지만, 지금 논의되는 IT 개발자들의 야근은 그네들에겐 선택권 한번 주어지지 못한 채 결정된다는 점에서 사회적인 접근이 필요하다고 봅니다.
예전 모 SI 업체에서 일했던 기억을 떠올리지 않을 수 없네요. 1 년 반 밖에 일하지 않았지만 그 때 고생했던 기억은 평생 갈 것 같습니다. 특히나 ㅅㅇ은행에서 보냈던 5 개월, 도저히 잊을 수가 없네요. 그때까지만 해도 큰 폭으로 변해 본적이 없었던 제 몸무게가 반 년 만에 6 kg 이 빠지고 얼굴 살들이 모두 실종되는 등 성격까지 나빠져 아주 참담한 모습이 되었었죠. 특히나 인상 깊었던 일은 그 당시 ㅅㅇ 은행의 어떤 차장님이 막 개발중인 시스템을 클릭해보곤 했는데 한번씩 뜨는 에러가 보기 싫다고 해서 그 분이 업무종료를 하는 오후 4시 반부터 일을 시작했었습니다. 거의 새벽 3,4 시가 되어야 끝이 났고 항상 택시를 타고 집에 들어가서 대충 잠을 잔 뒤 다음날 오후 2,3시쯤에 출근을 하곤 했지요.
한국의 개발자여, 단결하라
그 계약도 피라미드 식으로 이루어져 있었습니다. ㅅㅇ 은행이 삼성 SDS 에 프로젝트를 허가했고 저희 회사는 삼성 SDS 와 다시 계약하여 들어가 갑을병 상태였습니다. 또 거기에서 다시 저희 회사와 계약하여 들어온 병정 관계의 회사가 있었고요. 그렇게 갑을 병정이 한 데 모여 있으니 제대로 된 근무환경이 만들어질 리가 없었지요.
현재의 국내 소프트웨어 개발 관행은 많이 고쳐야 합니다. SW사업 하도급 금지된다 에서 위와 같은 피라미드를 근절하려는 노력들이 있습니다만 그 외에 많은 부당한 대우들을 얘기하고 논의해야 된다고 봅니다. IT 에 종사하시는 분들의 이야기로 훨씬 더 시끌시끌해졌으면 하는 바램입니다.
SW 프로젝트를 따낸 뒤 하청을 주는 관행이 조금은 줄어들었으면 좋겠네요. 개발력을 가진 회사들이 보다 더 잘 먹고 살 수 있는 계기가 되기를 기대해봅니다. 더불어 개발자 몸값도 좀 올라가구요.
삼성이나 LG 같은 대기업이 입찰에 참여하면, 누구나 그들의 손을 들어주고 싶을 겁니다. 대기업의 인프라가 있으니 마음이 든든한 거지요. 그러나 실제 프로젝트에서 대기업이 직접 개발을 하는 경우는 거의 없습니다. 대부분 하청에 하청에 하청을 거치게 되지요. 하청을 주는 것이 나쁘다는 것은 아니지만, 소프트웨어 개발에 있어서 다뤄야 되는 것이 '사람' 이라는 것을 고려해본다면 부작용은 있습니다. 기업과 기업간의 계약으로 묶여 있을 때 '을' 의 입장에 있는 개발자는 자신의 생산력을 제대로 발휘할 수 없을 거라고 봅니다. 여러 가지 제약과 개발자가 속해 있는 회사 내부에서 들어오는 압력으로 팀의 일원으로 일하긴 힘들겁니다.
예전에 산업은행에서 인터넷 뱅킹 개발을 했던 기억이 납니다. 삼성 SDS 가 프로젝트를 따냈고, 우리 회사는 거기에 하청을 받아 들어간 다음, 다시 하청을 줘서 조그만 개발사를 불러다 개발을 시켰습니다. 이 거대한 하청 구조의 하부쯤에 도달할 때는 프로젝트 수주로 인한 이득은 이리저리 뜯기고 몇푼 남지도 않습니다. 돈이 없으니 실제 개발해야 하는 사람들도 그다지 실력이 좋은 사람들은 아니었지요. 게다가 프로젝트에 대한 불만 사항이나 개선하고자 하는 점이 있어도 얘기할 곳이 없다는 게 큰 문제였습니다. 고작 자기네 회사에 얘기해보지만 돌아오는 대답이라고는 회사가 힘들어서 그러니 조금만 참아다오 뭐 이런 얘기 뿐이었지요.
회사간에 계약을 해서 서로 주고 받는 게 물건이라면 차라리 속편하겠지만, 소프트웨어는 전적으로 사람을 가지고 하는 일들입니다. 프로젝트 하청은 이것을 갉아 먹는 짓이구요. 전 개인적으로 소프트웨어 하청이 완전 없어져 버렸으면 좋겠다고 생각하지만, 컨설팅이나 매니지먼트의 프로젝트에 대한 영향력도 무시할 수 없으니, 위의 기사에 올라온 시도만이라도 박수를 쳐주고 싶네요.
