나는 이 책의 군데 군데에 '전문가 따라하기' 가 위험하다는 것을 여러 차례 이야기하였다.
자료 구조2)나 알고리즘을 배울 때에도 마찬가지이다.
선배 프로그래머들에 의해서 C언어나 C++언어 등,
특정 언어로 구현된 알고리즘을 그대로 따라서 배우는 것은 위험하다.
이런 식의 교육 방식이나 학습 방법은 가르치거나 배우기에 쉽지만 창의성을 없앤다는 점을 잊지 말아야 한다.
나는 조만간에 자료 구조를 구현하는 구체적인 알고리즘을 설명하지도 않고 코드를 동원하지 않으며, 말과 의사 코드3)로만 개념을 설명하는 식으로 자료 구조에 관한 책을 써내기로 계약이 되어 있다.
이 책이 필요한 이유는 간단하다.
풀이 방법까지 모두 다 기재된 수학 참고서를 생각해 보자.
이런 책은 인기가 많다.
아주 친절하게 풀이의 정석과 해법을 다 제시하고 있으니 얼마나 좋겠는가? 그렇지만
이런 수학 책으로 공부한 사람은 시험장에서 낭패를 보기 쉽다.
시험장에서 풀이 방법을 알려주지 않기 때문이다.
자료구조나 알고리즘의 구체적인 구현 방법을 알려 주는 것은
수학 문제의 풀이 방법을 알려주는 것과 다름이 없다.
이렇게 되면 창의적인 생각이 비집고 들어갈 자리가 없어진다.
그렇기 때문에 자료구조나 알고리즘을 개념 중심으로 공부하는 것이 좋다.
일단 개념을 잡은 뒤에 구체적인 구현 방법은 직접 고안해 내보도록 하라.
이런 식으로 공부하게 되면, 현업에서 문제에 부딪힐 때에 직접 자료 구조와 알고리즘을 고안하기가 쉬워진다.
자신의 힘으로만 수학 문제를 풀어본 학생이 시험장에서 문제를 풀 수 있는 것과 같은 원리인 것이다.
2)자료 구조(data structure)：자료를 일정한 형태로 담기 위한 서식.
예를 들면, 출석부를 아무렇게나 적는 것보다는 표 즉, 서식을 만들어 적으면, 출석 상황을 관리하기가 쉽다.
마찬가지로 컴퓨터에서 처리하는 자료도 일정한 서식을 만들어 관리하는 편이 좋은데, 이런 자료의 서식을 자료 구조라고 부른다.
3)의사 코드(pseudo code)：프로그래밍 언어로 소스 코드를 작성하기 전에, 즉 '소스 코드는 아니지만 소스 코드와 유사하며 사람의 말에 가까운 형태의 코드'로 프로그램을 미리 설계해 보게 되는데, 이 때 작성한 코드를 소스 코드를 모방한 코드라 하여 의사코드라고 부른다.
2010년 07월 27일 17시 30분 06초
'Tip'에 해당되는 글 164건
프로그램에는 많은 식별자(identifier)가 쓰인다.
변수의 이름·함수의 이름·클래스의 이름·객체의 이름 등이 모두 식별자에 해당한다.
이런 식별자를 한글로 지을 수도 있으나, 프로그램 언어가 영어 어휘로 이루어져 있기 때문에
식별자도 영어 어휘로 짓도록 강요된다.
그럼에도 불구하고 영어 어휘가 풍부하지 않은 사람들은 jojik 이라든가 hyubsang-result처럼
우리말 발음을 알파벳만 차용하여 표현하거나, 그것과 영어 어휘를 혼합해서 사용하기도 한다.
이것이 얼마나 효율적이지 못하고, 또 그런 이름을 짓는 프로그래머들이 무시당하는지는
여기서 새삼 말하지 않겠다.
무시하는 사람들이 오히려 무지한 것이라고 나도 생각하지만,
어찌 되었든 프로그래밍 세계에서는 그 쪽의 습관이나 규칙을 따르는 것이 좋다.
그러므로 풍부한 영어 어휘를 갖춰 놓을 일이다.
학교에서 미처 늘리지 못했다면 직장 다니는 틈틈이 어휘를 갖추라.
그렇지 않다면 적절한 영어 어휘를 사전에서 찾는 수고를 아끼지 말아야 한다.
한 가지 더 권고한다면 영어 어원을 익혀 두는 것이 좋겠다는 점이다.
영어는 여러 언어들이 혼합되어 형성된 말이다.
영어 어휘에는 라틴어나 게르만어에서 비롯된 어휘들이 가장 많다.
영어 어휘의 뿌리가 된 말을 어원이라고 부른다.
예를 들어, penta라는 말은 다섯을 뜻한다.
여기에 도형을 뜻하는 gon이 붙으면 pentagon이 되어 오각형이라는 말이 된다.
그렇다면 육각형은 무엇일까?
육을 뜻하는 어원인 hexa를 붙인 hexagon이라는 말이 있다.
다각형은 polygon이다.
poly가 많다는 뜻을 지닌 것인 줄을 자연스럽게 유추해 볼 수 있을 것이다.
이렇게 어원을 중심으로 영어 어휘를 늘려가는 방법이 한 때 꽤 유행한 적이 있었다.
일단 어원을 익히면 여러 단어의 뜻을 쉽게 유추할 수 있기 때문이다.
이런 공부 방법을 어원을 통한 연상 학습법이라고 부를 수 있을 것이다.
어원을 알면 영어 어휘를 늘리기가 쉽다는 장점도 있지만 또 다른 장점이 있다.
식별자를 지을 때처럼 지금까지 그 누구도 만들어보지 못한 어휘를 만들어 낼 수 있는 것이다.
예를 들어, 그것을 보는 순간에 어떤 혐오감을 일으키는 이상한 모양의 도형들이 있다고 하자.
한 마디로 '혐오 유발 도형' 이라고 부르기로 했다고 하자.
그런데 영어 어휘에 이런 말이 없다고 한다면 어떻게 할 것인가?
hyumo-yubal-dohyung 같이 식별자를 지을 것인가?
아니다.
이럴 때 어원을 알고 있는 것이 도움이 된다.
'어떤 것을 싫어하는 것' 에 적절한 어원은 miso-이다.
그리고 도형의 어원은 -gon이므로, 이 둘을 합쳐 misogon이라는 새로운 어휘를 만들면 되는 것이다.
그리고 이 어휘를 사용하여 변수라든가 하는 식별자를 선언하고, 그 옆에 설명을 한글로 덧붙이면 된다.
int misogon;
// misogon = miso(싫어하다) + gon(도형)을 합성한 어휘
내가 어원을 공부할 때에 가장 도움을 받았던 책은 '워드파워 메이드 이지(Word Power Made Easy)'였다.
내가 이 책으로 공부한 지 20년이 넘었지만 아직까지 이만한 책을 보지 못하였다.
어휘를 늘려라.
그리고 어원을 익혀라.
그리하면 식별자를 쉽게 지을 수 있을 것이다.
1)식별자(identifier)：프로그램에서 처리 중인 자료를 임시로 저장할 수 있는 장소를 변수라고 하고, 프로그램의 기능을 담당하는 부분을 함수라고 부르는데, 변수나 함수에는 이름을 붙여주어야 한다.
이 이름을 식별자라고 한다.
다른 변수나 함수와 구분할 수 있게, 즉 식별할 수 있게 해주는 것이기 때문이다.
2010년 07월 26일 15시 51분 07초
프로그래머로 오래 근무하게 되다 보면 세상의 모든 일을 프로그램 같이 생각하게 되는 경향이 있다.
한 사건이 발생하게 되면, 그 사건이 다른 사건에 미칠 영향을 변수와 연산자를 동원하여
마음 속으로 계산하고 있는 자신을 발견할 수 있다.
사람을 만나는 중에도 '이렇게 하면 이런 결과가 나오겠지?'하는 식으로 미리 결과를 추정해 보고,
실제적인 결과가 예측과 다르게 되면 당황하고는 한다.
사고 방식이 '프로그램' 형태로 굳어 버리는 것이다.
사고 방식, 곧 생각하는 순서나 방법이 프로그램 형태로 굳어버리게 되면 인간관계에 지장을 받게 된다.
나를 포함한 모든 현상을 프로그램 속의 변수에 대입하고,
프로그램 짜듯이 인간관계를 코딩하는 문제가 생기는 것이다.
'인간미'도 없어진다.
흔히 말하는 인간미란 어느 정도 실수도 하고, 시행 착오도 겪고, 정을 나눌 줄 아는 것을 말한다.
그런데 프로그램식 사고에 익숙한 프로그래머들은 약간의 결벽증이 생긴다.
늘 버그를 잡아야 하는 데서 비롯된 결벽증이다.
프로그램에 버그가 있으면 문제가 생긴다는 것을 늘 생각해왔기 때문에,
인간 관계도 하나의 흠결도 없이 깔끔하기를 원한다.
그래야 좋은 결과가 나올 것이라고 생각하기 때문이다.
이런 지나친 완벽주의는 오히려 인간관계를 소원하게 만든다.
'정이 없는 사람' 이라거나 '완벽주의자' 라는 말을 듣기 십상이다.
결국 좋은 결과를 얻으려고 했던 동기 덕분에 나쁜 결과를 가져오고야 마는 것이다.
결국은 프로그래머로 생활하면서 자기도 모르게 형성되어 버린 '사고 방식'이 문제인 것이다.
나는 이것은 '프로그래밍 사고'라고 부른다.
프로그래머로 사는 동안에는 지속적으로 프로그래밍 사고가 형성된다.
그렇기 때문에 의도적으로 이 사고 방식을 개선해 줄 필요가 있다.
내가 택했던 방법은 인문학 관련 도서를 읽는 것이었다.
소설이나 수필처럼 인간미가 살아나는 문학 작품을 읽는 것이 도움이 많이 되었다.
역사나 철학도 나름대로 프로그래밍 사고를 깨뜨리는 데에 도움이 되었다.
첨언하자면, 이런 다양한 독서는 어휘력도 늘려주어 커뮤니케이션 능력을 기르는 일에 도움에 된다.
이 시간에도 어딘가에서 '아, 이렇게 하면 우리 사랑에 버그가 생길 텐데' 라고 생각하는 사람을 위해 조언한다.
소설과 수필을 읽어라.
사랑은 프로그래밍이 아니다.
인간 관계는 결코 해법으로 풀리지 않는다.
2010년 07월 24일 22시 08분 20초
패턴을 응용은 하되 의존하지 말자는 말에 이어 한 마디 더하고자 한다.
패턴이 한국에서 열광적으로 환영 받은 이유는 무엇일까?
여기에는 우리나라 특유의 '따라하기' 교육 방식에 익숙해진 세대의 맹점이 자리잡고 있다.
지금의 초/중/고 교육과정이 어떻게 변화되었는지는 모르겠지만,
80년대에 교육을 받고 자란 우리에게는 항상 '모범 답안'이라는 것이 있었다.
어떤 문제에 대해서 가장 그럴 듯하게 답을 만들어 놓은 것이 모범 답안이다.
모범 답안을 누가 작성하느냐 하면 '교사'들이었다.
그 중에서도 '일류대를 졸업한 유명한 교사'였다.
우리 세대에서는 이 모범 답안에 가장 근접한 답을 써야만 문제를 푼 것으로 인정받을 수 있다.
물론 객관식 문제의 정답도 바로 이 모범 답안에 해당되는 것이다.
객관식이 모범 답안을 기계적으로 고르는 방식이라면,
주관식 문제는 모범 답안에 가장 근접하게 낱말이나 문장으로 써 내려가는 것이라고 할 수 있다.
이런 방식의 교육에 창의성이 존재할 수가 없었다.
나는 신라가 삼국을 통일한 것이라고 믿지 않았다.
한 지역 국가가 다른 지역 국가들인 백제와 고구려를 멸망시키고,
그 영토 중 상당 부분을 동맹국인 당나라에 떼어 준 전쟁이라고 보고 있었다.
게다가 그 후에 발해가 일어섰으므로 엄밀하게는 그 이후를 '통일 신라 시대'가 아닌
'남북극 시대'라고 불러야 한다고 믿었다.
물론, 이것은 나의 주관적인 견해이고, 일부 학자들이 주장한 것이다.
그렇지만 중/고등학교 시절의 필기 시험에서 이 시기를 '통일 신라 시대' 라고 적지 않고
'남북국 시대'라고 적는다거나,
'정답 없음'이라는 견해로 오지선다의 문항 중에 아무 것도 고르지 않으면
어김없이 문제의 답을 틀리게 적은 것으로 처리되었다.
지금, 이 시점에서 당시와 같이 모범답안을 작성하는 사람들이 존재한다.
그들은 일류 프로그래머이며 주로 소프트웨어의 본고장인 '미국에서 활동하는 일류 프로그래머'인 것이다.
그들과, 우리나라의 '일류대 출신의 이름 난' 교사들과 다른 점이 있다면,그들은 모범 답안을 작성할 의도도 없었고 또 그것을 그대로 모방하는 프로그래머들이 생기기를 바라지도 않았다는 점일 것이다.
그들이 작성한 프로그램들에서 공통적으로 찾을 수 있는 패턴을 찾아 모범답안으로 만들려고 애쓰고 있다.
그러나 모범 답안을 속속들이 안다고 해서 프로그래밍의 실력이 늘지는 않는다.
수학 문제 풀이의 정석이나 해법을 속속들이 외우고 응용할 수 있다고 해서 뛰어난 수학자가 될 수 없듯이,
프로그래밍 패턴들을 속속들이 외우고 응용할 수 있다고 해서 뛰어난 프로그래머가 될 수는 없다.
그러므로 현업에 종사하는 팀장들은 일선 프로그래머들에게 모범 답안대로 프로그램을 작성해 줄 것을
강요해서는 안된다.
패턴에 맞게 작성하지 않았다고 꾸지람을 주어서는 안된다.
오히려 지금까지 존재하지 않던 해법을 찾아낸 프로그래머들을 칭찬해 주어야 한다.
그들이야말로 새로운 패턴을 형성해 가는 일류 프로그래머인 것이다.
2010년 07월 22일 16시 23분 00초
요즘에 디자인 패턴(design pattern)이 유행하고 있다.
모든 건축물에 일정한 패턴이 있고, 이 패턴을 이용하여 설계할 수 있듯이, 모든 프로그램에도 일정한 패턴이 있고 이 패턴을 본따서 프로그램을 작성할 수 있다는 것이다.
남들이 이미 작성한 바 있는 패턴을 따르기 때문에 짧은 시간에 프로그램을 더 많이 작성할 수 있다.
이런 패턴 개념은 프로그래밍 분야에 충격을 주었고, 지금 이 패턴을 익히고자 하는 사람들이 많다.
앞으로도 꾸준히 연구되어야 할 분야이다.
그러나 패턴은 어디까지나 패턴일 뿐이다.
즉, 여러 프로그램에서 나타나는 동일한 형상일 뿐이지 프로그램 자체는 아니다.
패턴이 프로그램 제작에 도움을 줄 수 있지만, 프로그램 자체를 완성케 하는 것은 아니다.
결국 프로그램 자체를 완성하는 것은 사람의 두뇌다.
패턴을 응용할 능력도 사람이 두뇌에서 나온다.
이렇게 생각하면 패턴보다 더 중요한 것이 사람의 두뇌라고 할 수 있다.
즉, 프로그래머의 창의성이나 응용력이 패턴 그 자체보다도 중요하다는 것이다.
그런데 패턴 중심의 교육은 프로그래머의 창의성이나 응용력을 떨어뜨릴 위험이 있다.
예술 작품을 완벽하게 모방해 낼 수 있는 사람들이 결코 다빈치나 고호가 될 수 없듯이, 패턴을 줄줄이 외우고 그것들을 이용해 프로그램을 작성할 수 있다고 해서 창의성을 발휘할 수는 없는 것이다.
패턴 중심의 교육에 의해, 다른 사람들의 아이디어·알고리즘·패턴에 매달리기 시작하면 그런 경향이 지속될 가능성이 있다.
다른 사람의 결과물에 의존하는 경향이 심화될 가능성이 높아지는 것이다.
그러므로 패턴을 이용은 하되 의존하지는 않는다는 정신이 중요하다.
패턴을 가르치되 생산성을 높이기 위한 방편으로만 가르치고 창조성마저 저해하도록 해서는 안 된다.
2010년 07월 20일 17시 01분 22초
프로그래머의 세계는 고달프다.
끊임 없이 쏟아지는 신기술을 소화해내야 하기 때문이다.
프로그래머가 가장 갖고 싶은 직업이 '수학 교수'라는 우스개 소리를 들어 보았을 것이다.
수학은 한 번 배우면 평생 가르칠 수 있지만, 컴퓨터 기술은 평생 배워도 한 번 가르치고 나면 소용이 없게 되기 때문이다.
컴퓨터 기술이 어찌나 빨리 반전하는지 그것을 따라잡이 못해서 컴퓨터 관련 직업을 버리는 사람도 있는 실정이다.
게다가 우리의 두뇌는 한계가 있다.
그렇게 쏟아지는 지식을 전부 소화하거나 기억하지 못하는 것이다.
프로그래머들이 기억해야 할 것은 신기술이나 신지식이 전부는 아니다.
회의 시간에 오고간 이야기, 고객과의 면담 내용, 프로그램 작성 과정 중에 나타난 오류, 개선해야 할 점, 갑자기 떠 오른 아이디어 등이 모두 기억할 내용이다.
이것들을 모두 기억하려 하다보면 주의가 산만해져 아무 일도 되지 않는다.
그렇기 때문에 프로그래머들에게는 마스터 워크북(master workbook)이 필요하다.
마스터 워크북은 공책으로 만들면 된다.
여기에 기억해야 할 모든 것을 날짜와 함께 기록해 두면 된다.
마스터 워크북에는 프로그래밍 아이디어, 순서도, 알고리즘, 의사 코드, 실제 코드를 포함한 무엇이든지 기록하면 된다.
생각나는 대로, 정보를 얻은 대로, 기억할 내용이 발생한 대로 그때 그때 기록하면 된다.
이렇게 기록하여 만든 워크북은 나중에 큰 지적 재산이 된다.
업무상의 노하우가 그대로 다 담기기 때문에 나중에 새 직장을 구할 때에도 큰 도움이 된다.
시간이 된다면 워크북에 담긴 내용을 시기별로나 주제별로 따로 정리한다면 더욱 좋다.
예를 들어 A라는 프로젝트와 관련된 내용은 'A 프로젝트 워크북'이라는 식으로 따로 정리하는 것이다.
또 예를 들면 코딩 노하우와 관련된 것만을 따로 모아 '코딩 노하우 워크북'과 같은 식으로 정리하는 것이다.
정리하는 데에 시간은 좀 걸리겠지만, 이 작업을 하는 재미가 쏠쏠하다.
이 작업을 하는 동안에 지난 일을 회상하기도 하고, 자신의 지식이 정리되는 느낌도 가질 수 있게 된다.
마스터 워크북에서 내용을 선별하여 만든 워크북을 주제별 워크북이라고 부를 수 있을 것이다.
나의 생각에 프로그래머라면 1년에 서너 권 분량의 마스터 워크북을 가볍게 만들 수 있다.
이런 마스터 워크북을 일년이나 이년 또는 삼년 단위로 주제별 워크북으로 정리하는 시간을 가지면 될 것이다.
2010년 07월 19일 11시 53분 05초
우리나라에서 생산되는 프로그램들의 가장 큰 문제점을 한마디로 표현하라고 하면 '졸속(拙速)'이란 말이 적당할 것이다.
졸속은 '너무 서두르다가 소용 없게 만드는 것' 이다.
우리나라의 개발 프로젝트 계약은 대개 개발 기간에 투입되는 인력에 용역 단가를 곱한 금액으로 정한다.
그러니, 제안을 할 때에 개발 기간이 무척 중요해진다.
기간이 길면 용역비가 커지고, 기간이 짧으면 용역비가 작아진다.
개발 회사 입장에서야 기간을 늘리면 좋겠지만, 경쟁 회사들이 개발기간을 줄여 낮은 금액을 제시하기 때문에, 개발 기간을 늘리지는 못하고 대체로 줄이는 편이다.
이런 상황들이 지속적으로 반복되다보니 절대로 끝내기 힘든 기간을 개발 기간으로 제시하는 업체들이 많아졌다.
'어떻게든 되겠지'하는 심정으로.
나의 경험으로는 대체로 개발 업체들이 제시하는 기간보다 약 2배에서 3배 정도가 적당한 기간인 것 같다.
계약 기간이 6개월이라면 실제로는 1년이나 1년 6개월 정도를 실제 프로젝트가 끝나는 시점으로 보면 된다.
물론, 납기를 정확히 준수하는 업체들도 있겠지만, 프로그램의 특성상 고객의 요구 사항의 변경이라든가 하는 예외적인 일들이 많아서, 대체로 납기를 지키지 못하는 면이 많다.
이럴 때에 발주 업체에서는 이행지체금이라는 것을 물린다.
그렇기 때문에 개발업체에서는 프로그램의 품질이 떨어지는 한이 있어도 일단 계약기간까지는 프로젝트를 완료한 것처럼 보이려고 한다.
나는 여기서 '완료한 것처럼 보인다'라고 말했다.
실제로 완료하는 것이 아니라, 완료되지도 않았는데 일단 완료한 것처럼 꾸미는 것이다.
매우 비참한 현실이지만 진짜 개발은 그때부터 시작이라고 보면 된다.
대충 만들어 놓은 프로그램을 뜯어 고치는 것이다.
제대로 만들어지지 않았기 때문에 오류가 여기저기서 발견된다.
상부에서는 어떻게 된 거냐며 질책하는 질문을 한다.
개발자들은 밤샘 작업을 해서라도 속히 결과를 보여주려 한다.
이럴수록 프로그램은 땜질 처방이 되고, 결국 그 땜질이 또 다른 문제를 지속적으로 만든다.
대개 이런 식으로 진행되는 프로젝트는 매끈하게 마무리 되지 못한다.
실패하거나 개발 기간이 한 없이 늘어나 개발 업체와 발주처, 양쪽에 모두 손해를 끼친다.
그렇기 때문에 이제라도 개발 기간으로 개발 비용을 산정하는 방식을 버리는 것이 좋다.
예비 분석과 예비 설계를 마친 후에 개발 공수를 산정하여 보고, 그 공수에 따라서 개발 비용을 산정하는 것이 좋을 것이다.
물론 예비 분석과 예비 설계에 따른 비용은 따로 청구하면 될 것이다.
개발 공수는 작업량을 산정하는 기준을 세워 셈하여 보면 될 것이다.
작업량을 산정하는 기준은 코드의 길이가 될 수도 있고, 생산하는 문서의 분량이 될 수도 있고, 예상되는 업무 처리 비용의 절감을 기준으로 삼을 수도 있을 것이다.
이런 형태로 개발 비용을 산정하게 되면, 개발 비용에 맞추어 개발 기간을 정하는 어리석은 행위를 하지 않아도 될 것이다.
개발 공수에 맞추어 개발 비용과 개발 기간을 정하는 합리적인 행위를 할 수 있게 될 것이다.
이렇게 되면 개발자들은, 충분히 확보된 개발 기간 덕분에, 느긋하게 일할 수 있게 된다.
느긋한 개발은 품질 향상을 가져올 것이다.
2010년 07월 18일 19시 22분 40초
응급실에 환자가 실려왔다.
환자는 과다 출혈로 곧 사망할 것으로 보인다.
당직 의사를 호출한다.
당직 의사는 지금 화장실에 있다.
그는 변비가 심하다.
도저히 변비를 해결하지 않고서는 화장실을 나설 수 없을 것 같다.
수간호사가 달려와 당직 의사를 찾으려고 외치는 소리가 들린다.
그럼에도 당직 의사는 어떻게든 변비를 해결해 보려고 한다.
변비는 지금 당직 의사에게 있어서 어떤 것보다 더 심각한 문제 상황이다.
그렇다고 환자가 죽게 내버려 둘 수는 없다.
당직 의사는 결국 '히포크라테스의 선언' 을 떠올리면 옷을 주섬주섬 챙겨 입는다.
여전히 묵직한 배는 불쾌감을 더한다.
그러나 나름대로 의사의 윤리를 잊어서는 안 된다는 생각에 옷을 더 빨리 챙기려고 한다.
아차, 허리띠를 잠그는 것을 잊었다.
바지의 지퍼도 열려 있다.
다시 옷을 추스린다.
결국 그 시간에 환자의 몸은 차가운 얼음의 계곡으로 서서히 떨어지고 있다.
프로그래머는 항상 환자를 대하는 의사로 산다.
기업은 환자요, 프로그래머는 의사다.
기업이라는 환자에 대해서 분석이라는 진단과, 설계와 구현이라는 치료 행위를 담당하는 의사다.
그런데 요즘 프로그래밍 병원7)을 찾는 기업들은 대부분이 응급 환자다.
워낙 체감 시계가 빨리 돌아가다 보니, 예전 같으면 몇 일에 걸쳐서 천천히 진단하고 수술해도 될 환자들이, 수 분으로 생사가 결정되는 시대가 되었다.
결국 모든 프로그래머들은 응급실 당직 의사가 되어 버렸다.
당직 의사가 변비 때문에 화장실에 조금 더 오래 앉아 있는 시간에 환자는 죽어간다.
당직 의사의 사소한 실수로 지연된 시간은 환자에게 생명을 건질 수 있는 마지막 기회가 된다.
오늘날 프로그래머들은 응급실 당직 의사의 위기를 겪고 있다.
그렇기 때문에 지금까지와 같은 '느긋한' 개발 방식으로는 근무해서는 안 된다.
'신속한' 개발 방식이 필요하다.
그러나 신속하기만 하다가 실수하면 안 되므로 '신속하면서도 주도면밀한' 개발 방식이 요구되고 있다.
이 시점에서 '애자일 프로그래밍'(agile programming)이라고 불리는 기민하면서도 정확한 개발 방법론들이 그래서 필요하고, 또 그런 이유로 출현하고 있는지도 모른다.
'익스트림 프로그래밍(eXtreme Programming)' 도 애자일 프로그래밍 방법론 중의 하나다.
이것 외에도 앞으로 더 많은 '신속하고 정확한' 개발 방법론이 출현할 것으로 보인다.
프로그래머들은 이런 개발 방법론의 시대적 변화에 관심을 기울이고 있어야 한다.
순식간에 개발 과정이 바뀔 것으로 보이기 때문이다.
7) 프로그래밍 병원：프로그램 제작 회사를 은유적으로 표현한 것.
07월 12일 22시 25분 20초
아니 정확하게 말하면 라이브러리(library)5)를 찾지 않는다는 것이다.
프로그래밍 언어의 컴파일러를 제조한 회사에서는 프로그래밍에 필수적인 함수들을 라이브러리 형태로 제공한다.
그리고 그 함수들의 쓰임에 대해서는 매뉴얼에 기록해 두고 있다.
그것 외에도 프로그래머에게 요긴하게 쓰이는 함수라면 대부분 라이브러리의 형태로 판매되거나 무료로 인터넷을 통해 배포되고 있다.
그럼에도 불구하고 초보 프로그래머들은 라이브러리를 찾는 일에 게으르다.
이미 구현되어 있는 함수를 구현하기 위해서 며칠씩 애쓴다.
생각해보라.
주위에서 기성 부품을 쉽게 구할 수 있는데, 그것을 찾아볼 생각은 하지 않고 처음부터 쇠를 깎는 사람이 있다면 어떻게 볼 것인가?
어리석다고 하지 않겠는가?
자동차 제조사는 자동차를 만들려고 하지 자동차 부품을 만들려고 하지는 않는다.
자동차 부품은 부품 전문 회사에서 만든 것을 가져다 써야 생산성도 높아지고, 더 신뢰할 수 있다.
프로그래머가 만들려고 하는 것은 프로그램이지 함수(function)6)가 아니다.
프로그래머가 만든 함수보다 컴파일러 제조사나 라이브러리 제조사에서 만든 함수를 가져다 쓰는 편이 더 생산적이고, 또 그렇게 전문 업체에서 만든 함수를 더 신뢰할 수 있는 것이다.
프로그래머는 자동차 제조 회사의 종업원과 같은 존재다.
부품 회사의 종업원이 아닌 것이다.
만약 굳이 함수를 일일이 만들어 보고 싶다면 차라리 라이브러리를 전문적으로 제조하는 회사에 취업하는 편이 낫다.
그렇지 않다면 모든 함수를 자신의 힘으로 작성해 보려는 어리석은 생각을 버리고, 라이브러리에 포함된 함수를 가져다 쓰도록 하라.
5) 라이브러리(library)：본래는 '도서관'이라는 뜻.
컴퓨터 업계에서는 프로그램에서 쉽게 끼워 쓸 수 있는 작은 기능을 갖춘 '작은 프로그램(모듈)'을 모아 놓은 것이라는 뜻으로 씀.
보통 컴파일러 제조 회사나 라이브러리 제조 회사에서 전문적으로 제작하여 프로그램의 형태로 공급하며, 프로그래머들이 구입하여 사용한다.
6) 함수(function)：프로그램은 기능 중 일부를 담당하는 부분.
프로그램은 이런 함수들의 집합체라고 볼 수 있다.
흔히 모듈(module)이라고 부르기도 한다.
자주 쓰는 함수들은 라이브러리에 포함되어, 전문 제조회사들이 공급한다.
07월 10일 17시 23분 27초
프로그램을 작성하다 보면 고객의 입맛에 맞추는 것이 얼마나 힘든 것인지를 실감하게 된다.
고객은 항상 컴퓨터 기술보다 앞서 간다.
그들은 어디서 들었는지, 최신 기술을 프로그래머보다 먼저 알고 있다.
다운사이징(downsizing)3) 관련 방법론이나 기술이 보급되기도 전에 그들은 다운사이징을 구현해 달라고 요구한다.
유비쿼터스(ubiquitous)4) 컴퓨팅에 대한 개념조차 제대로 정립되지 않은 이 시점에서 벌써 유비쿼터스 컴퓨팅으로 공장의 모든 부분을 제어할 수 있게 해달라고 한다.
그러나 프로그램을 구현하는 환경인 기계(운영체제를 포함)의 입장은 어떠한가.
기계는 언제나 컴퓨터 기술보다 한 발 늦게 발전한다.
추상적인 개념과 기술이 논의되고 나서야 비로소 기계 장치나 운영체제에 구현된다.
프로그래머들은 항상 이 양자 사이에서 줄다리기를 해야 한다.
고객의 입맞에 맞추려고 하면 컴퓨팅 환경이 따라주지 못하고, 컴퓨팅 환경에 맞추려고 하면 고객들이 만족하지 못한다.
그렇기 때문에 프로그래머들은 유능한 조정자가 되어야 한다.
고객도 만족하고 컴퓨팅 환경에도 적합한 최적의 합의점을 이끌어 내어야 하기 때문이다.
이 양자의 협의를 이끌어 내려면 프로그래머는 양자의 입장을 충실히 대변하는 대변자가 되어야 한다.
'만약 고객이라면 기계의 어떤 기능을 원할까', '만약 기계라면 어떤 점이 고객의 무리한 요구라고 생각할까' 라는 생각들을 해 보아야 한다.
이렇게 양자의 입장에 서서 충실한 대변자가 되려고 하다 보면 양자의 합치점이 보이게 된다.
이렇게 보이는 양자의 합치점은, 처음 프로그래머가 예상했던 설계 방안이나 작성 방안과는 전혀 다른 것인 경우도 있다.
즉, 양자의 입장에 서서 생각함으로써 아주 색다른 해결방안이 보이기도 하는 것이다.
3) 다운사이징(downsizing)：'규모 줄이기'라는 뜻.
은행이나 대기업과 같은 규모가 큰 기업에서는 규모에 맞게 컴퓨터도 막강한 성능을 가진 대형 컴퓨터를 써 왔다.
그러나, 컴퓨터 기술의 발달로 굳이 대형 컴퓨터를 쓰지 않고, 소형 컴퓨터를 여러 대 연결하여 업무를 처리하는 편이 여러 가지 장점을 지니게 되자, 컴퓨터의 규모를 줄이기 시작하였다.
이것을 다운사이징이라고 한다.
4) 유비쿼터스(ubiquitous)：본래 신학 용어로 어디에나 존재하는 신의 속성을 나타내는 말.
이것을 컴퓨터 업계에서 도입하여 언제 어디서나 컴퓨터를 쓸 수 있도록 하자는, 컴퓨터 사용의 미래 이상을 나타내는 말로 씀.
07월 04일 00시 17분 45초