모과이의꿈

정부가 2015년까지 전국 유치원과 초·중·고를 대상으로 스마트스쿨을 구축한다. 관련 IT 시장 규모는 1조5000억원에 이를 전망이다.

행정중심복합도시건설청은 최근 세종시 내 유치원과 초·중·고교 대상 스마트스쿨 구축사업을 발주했다. 광주·전남공동혁신도시도 나주혁신도시 내 180억원 규모 스마트스쿨 구축사업을 준비 중이다. 영종도 미단외국인학교도 스마트스쿨 사업을 발주한다. 정부는 내년부터 신도시 중심으로 기존 유치원과 초·중·고에 스마트스쿨 사업을 확대한다.

스마트스쿨 구축은 지난 6월 국가정보화전략위원회와 교육과학기술부가 수립한 스마트교육 추진전략에 따라 진행되는 사업이다. △등·하교 관리시스템 △u교실시스템 △급식관리시스템 △전자도서관시스템 △출결관리시스템 △u안전시스템 △방과후학습시스템 △u스쿨 시설관리시스템 △u스쿨 통합관리시스템이 구축된다. △거점 전산실 △내·외부 연계시스템 △통합포털 △스마트패드나 스마트폰을 통한 정보제공 인프라도 마련된다.

행정중심복합도시건설청은 최근 123억원 규모 스마트스쿨시스템 구축사업을 발주했다. 유치원 2개와 초·중·고 4개 학교가 대상이다. 학교 내 통합전산망을 구축하고 서버 및 스토리지가 들어간 통합 전산실을 만든다. 데스크톱 가상화 기반 PC 환경과 전자태그(RFID) 기반 시설물관리·물품관리·학사관리시스템도 구축한다. 지문인식시스템을 구축해 학생증 미지참 시 활용하도록 할 예정이다. CCTV 및 무인경비시스템과 스마트스쿨 통합시스템도 구축한다.

각 교실에는 70인치 이상 풀(Full) HD급 LED 3D 모니터가 들어간다. TV는 전자칠판과 연동해 사용한다. 유무선 마이크, 강의용 앰프, 중앙집중식 통합 컨트롤러, 강의용 태블릿 모니터, 셋톱박스, SW가 포함된 전자교탁 등도 도입한다. 원격영상회의시스템도 갖춘다.

민자임대사업으로 추진 중인 세종시 내 또 다른 스마트스쿨 구축사업은 3개 유치원, 6개 초·중·고교를 대상으로 진행한다. 계룡건설이 시공사로 선정돼 실시설계가 완료된 상태다. 계룡건설은 이르면 연내 100억원 규모 스마트스쿨 구축사업을 발주한다.

나주혁신도시 스마트스쿨 구축사업은 이 도시 u시티 설계사업을 수행한 바 있는 삼성SDS가 수주할 가능성이 높은 것으로 알려졌다. 사업규모는 180억원에 이를 전망이다.

한국교육학술정보원의 미래연구센터(가칭)도 구축된다. 이 센터는 전국 스마트스쿨 IDC 역할을 수행하게 된다. 2015년까지 총 400억원이 투입되는 센터 설립사업은 내년 초 발주된다.

스마트스쿨 구축 관련 IT 시장 규모는 교육과학기술부 사업 예산인 1조2400억원에 지방자치단체 예산, 교과과실제 사업 추진 예산 등을 더하면 1조5000억원에 이른다. 삼성SDS, LG CNS, SK C&C 등 국내 대형 IT서비스기업과 대교CNS 등 교육IT 전문기업이 수주전에 나섰다.

신혜권기자 hkshin@etnews.com

교육과학기술부 스마트스쿨 사업 예산 (단위:억원)

사업 내용	2012년	2013년	2014년	2015년	계
무선 인터넷 환경 구축	678	679	679	679	2715
교육용 스마트기기 보급	1250	2550	2896	2144	8840
미래연구센터 설립	200	100	50	50	400
스마트 스쿨 시범 구축 운영	120	160	120	120	520
계	2248	3489	3745	2993	12475

주:지방자치단체와 교과과실제 추진 예산은 제외

자료:교육과학기술부

2009년 JAOO 컨퍼런스에 발표되었던
“깨끗한 코드 만들기: 매소드”에 대한 자료를 소개합니다.

자료는 아래 참고자료 부분에서 받아 보실 수 있습니다.

깨끗한 코드 만드는 일은 설계와 리팩토링이 체질화되지 않으면 참 어려운 일인것 같습니다.
하지만 객체 지향 언어가 갖는 기본적인 성질 정도를 이해하는 사람이
좀 잘해보겠다는 의지만 갖는다면 정말 자료에서 예로 말하고 있는 것 같은
말도 안되는 상황은 피해갈 수 있지 않을까 합니다.

자료를 보면 남의 얘기 갖지만,
우리 프로젝트만 보아도 이 같은 상황을 참 자주 만나게 됩니다.

심지어 메소드 하나가 화면의 크기에 서너배를 차지하는 일은 예삿일이고,
JSP는 끝이 어딘지도 모를 정도로 길고 복잡한 경우도 보았습니다.
이런 상황을 구조적으로 파악하고 리포팅을 해주는 여러 가지 툴도 있지만
리뷰 활동은 문제가 생길 때만 진행하는 게 대다수의 현실인 것 같습니다.
심지어 어떤 툴들은 생산성이라는 이유로 더 심한 복잡한 상황을 유도하는
경우도 있는 것 같습니다.

대부분 이런 상황이 발생한 이유는
비지니스 로직의 복잡성 때문이라고 하기도 하고
데드라인에 쫒겨 기능을 개발하기에도 정신이 없어 그렇게 되었다고도 합니다.

비즈니스 로직이 복잡하고 바쁘면 한 매소드 내에 들어가는 코드가 길어지나요?
어디에서도 이런 이론을 본적은 없는 것 같습니다.

사실은 원칙과 설계에 대한 초기 고민의 부족이
이런 상황을 만드는 경우가 대부분이고
이렇게 한번 시작이 되면 시간이 지날 수록
여러가지 추가 요구사항이 가미되면서 점점 더 코드가 커지고
복잡한 형태로 발전이 되는 경우가 대부분인 것 같습니다.

예전에 싱가폴 컨퍼런스에서 컨설턴트 중 한 사람이
개발에 있어 가장 중요한 두 가지는 테스트 케이스와 API를 작성하는
일이라고 했던 기억도 납니다.

이런 상황에서 테스트 중심의 개발이나
제대로 된 API의 제공은 꿈꿀 수도 없는 상황이지 않나 싶습니다.

하지만 초기에 좀 오래 시간이 걸린다 하더라고
요건 중심의 설계, 그리고 지속적인 테스트와 리팩토링을 통해
보다 적은 코드와 구조적인 모습을 지향하려고 노력한다면
이런 근본적인 문제를 보다 쉽게 풀수 있을 뿐만 아니라
결함이 적고 확장에 유연한 대응구조가 되면서
오려히 테스트나 운영시에 발생하는 비용을 상당히 단축할 수 있지 않을까 합니다.

누구나 다 아는 사실이지만 쉽지 않은 것 같습니다.
이 일은 특히 프로젝트 초기의 역량과 부지런함, 그리고 협업을
전제로 하죠.

JAOO라는 유명한 유럽쪽에서 컨퍼런스에서 발표되었던
깨끗한 코드 만드는 방법에 대한 자료에서 말하는 첫번째와 두번째 원칙은
너무나도 쉽고 명료합니다.

The first rule:
- They should be small.

The second rule:
- They should be smaller than that.

이러한 깨끗한 코드 만들기의
다른 하나로는 언어 자체가 유발시키는 boilerplate code 발생을
효과적으로 차단할 뿐만 아니라, 뛰어난 확장성을 가지고
최근 주목받고 있는 Scala라는 언어가 있습니다.

Groovy의 저자는 2003년 Scala를 보았더라면 Groovy라는 언어 자체를
만들지 않았을 거라는 말도 해죠.
이 저자는 Java5의 Generic System을 만든 사람으로도 유명하죠..
Scala는 자바의 차세대 언어라는 말을 듣고 있기도 합니다.

하지만 언어를 새로 배운다는 게 보통일은 아닌것 같습니다.
Scala는 많은 개념과 Syntax Sugar가 혼재하고 있어
처음 접근시 어렵고 복잡하게 느껴지지만 여태 경험하지 못했던
정말 놀라운 생각의 힘을 볼 수 있습니다.

특히 scala로 된 언어를 컴파일하여 클래스를 생성하고 JVM 위에서
동작할 수 있도록 되어 있어 자바의 모든 API를 사용할  수
있을 뿐만 아니라, 기존의 자바 프로그램과도 쉽게 통합하여
사용할 수 있는 강점이 있습니다.

참조자료

http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/MichaelFeathers_CleanCodeIIIFunctions.pdf
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-1

1. 꿈을 크게 가져라.
스스로 꿈을 크게 갖고 당신이 살기를 원하는 삶을 상상하라. 그리고 그러한 삶을 살기 위해 얼만큼의 재산이 있어야 하는지 생각해보라. 이러한 장기적 미래 비전을 세우는 것은 당신이 좀더 긍정적이고 동기부여가 되고 확신에 찰수 있도록 도와준다.

2. 확실한 방향성을 개발하라
항상 당신의 목표에 대해 생각하고 그것에 다가가려 노력하라. 당신의 삶에서 하고자 원하는 것을 결정하고 이를 구체적인 목표로 적으라. 그리고, 그것에 대해 마감시한을 정하고 그것을 달성하기 위해 필요한 모든 것들을 리스트로 만들라.
그런 다음, 그 리스트를 행동 계획으로 옮겨라 직접 실천하는 것이다.

3. 스스로를 고용하라
당신은 당신 삶에 일어나는 일들에 대해 책임이 있다. 따라서, 당신이 주인공인 것이다. 당신이 누군가를 위해 일한다고 생각하는 것은 실수이다. 당신 스스로를 고용하라. 그리고 독립적이고 스스로 책임지며 스스로 시작하는 기업가라고 생각하라.

4. 당신이 하기를 원하는 것을 하라
당신이 진정으로 하기를 원하고 재능이 있는 것을 찾으라. 그리고, 자신을 철저하게 그 일에 던져라. 당신이 좋아하는 일을 한다면, 그것은 더 이상 일로 느껴지지 않을 것이다.

5. 최고를 추구하라
당신이 무엇을 하든, 최고가 되려고 노력하라. 당신 분야에서 상위 10%가 되도록 목표를 세우라. 모든 성공한 사람들은 매우 경쟁력 있는 사람들이기 때문에 당신도 충분히 경쟁력 있는 사람이 되어야 한다.

6. 더 오래 더 열심히 일하라
모든 자수성가한 사람들은 열심히 일했기 때문에 당신도 열심히 일해야 한다. 열심히 일한다는 것은 더 빨리 일을 시작하고 더 늦게 까지 일構?더 집중해서 일하는 것을 의미한다. 여기서 가장 중요한 것은 근무 시간 동간 계속해서 일하고 시간을 낭비하지 않는 것이다.

7. 평생 동안 배움을 계속하라
당신 분야에서 지속적으로 배우고 향상하도록 하라. 자신의 지능을 근육으로 생각하고 쓰면 쓸수록 개발된다고 생각하라. 육체적 근육처럼 당신의 정신적 근육들도 일하고 또한 늘리도록(stretch) 하라. 평생 학습을 위해 중요한 3가지 요소는 바로 첫째는 하루에 한 시간이나 30분 동안 자기 분야에 대해 독서를 하는 것이고, 둘째는 출퇴근 시에 오디오 프로그램 등을 통해 학습을 하는 것이고 셋째는 될 수 있으면 많이 당신 분야의 교육과 세미나에 참석하는 것이다.

8. 미래를 위해 투자하라
될 수 있으며 소득의 많은 부분을 저축하고 소득 중 적어도 10%는 투자를 하도록 하라. 검소하도록 하고 돈에 대해 신중히 생각하라. 모든 비용에 대해 검토를 하고 될 수 있으면 지출에 대해 미루도록 해라. 미룰수록 싸게 사고 그리고 낭비를 줄일 수 있다.

9. 당신 사업에 대해 철저히 배우라
일을 더 잘할 수 있는 방법에 대해 배워서 그 분야에서 전문가가 되라. 전문가가됨으로써 최고에 오를 수 있다. 그 분야의 최신 잡지나 도서를 항상 곁에 두라.

10. 고객 서비스에 헌신하라
고객 서비스는 매우 중요하고 모든 자수성가한 사람들은 고객을 서비스하는데 헌신적이었다. 이들은 고객에 대해 항상 생각하고 이들에게 서비스하기 위한 새롭고 더 나은 방법을 찾기 위해 항상 노력하였다.

11. 절대적으로 정직하라
앞서 간다는 것은 당신의 성품에 대한 평판을 요구한다. 왜냐하면, 모든 성공적인 비즈니스는 신뢰에 기초하기 때문이다. 올바른 성품을 갖기 위해서는 자신에 대해 정직하고, 다소 더 많은 비용이 들더라도 항상 올바른 일을 하는 것이다.

12. 우선순위에 집중하라
정기적으로 우선순위화하고 이를 달성하기 위해 집중하는 것을 배움으로써 당신은 당신이 원하는 것을 성취할 수 있다. 우선순위화의 비법은 당신이 목표를 위해 해야만 하는 것들을 모두 리스트화하고 이들에 대해 더 높은 가치를 주는 활동들에 대해 기록하고 우선순위화하는 것이다.

13. 신속함에 대해서 평판을 얻으라
오늘날 사람들은 신속함을 원하고 기다리는 것에 익숙하지 않다. 따라서, 신속함과 민첩한 행동에 대한 평판을 얻는 것이 중요하다. 당신 상사나 고객을 위해 무엇을 할 때, 빠른 일 처리를 통해 그들을 놀라게 할 필요가 있다.

14. 정산에서 정상으로 오르도록 하라
인생은 오르고 내리고 굴곡이 있기 마련이다. 장기적인 관점을 세우고 항상 2년 이상의 계획을 세우도록 하라. 그래야, 당신이 도중에 내리막길을 맞나더라도 자신감을 가질 수 있게 된다.

15. 항상 스스로 규율을 정하라
스스로 해야 할 때 해야 하는 것에 대해 규율을 정함으로써 당신을 성공을 담보할 수 있다. 당신은 스스로 제어하고 방향성을 가질 필요가 있으며 또한 장기적인 성공을 달성하기 위해서 단기적인 만족을 지연시킬 필요가 있다.

16. 당신의 창의력을 펼치라
창의력을 자극하기 위한 3가지 요소는 강렬한 목표와 문제에 대한 압박, 그리고 해법에 대한 집중이다. 당신이 당신의 목표 달성과 문제 해결에 더 집중할수록 당신은 더 현명해 질 것이다.

17. 올바른 사람들과 교제하라
당신이 더 많은 사람들을 알수록 당신은 더욱 성공하게 되고 그리고 더 빨리 나아갈 수 있게 된다. 당신이 교제하는 그룹들은 특히 중요해서 당신이 태도나 가치관, 행동, 그리고 신념들을 그들과 닮아가게 된다.

18. 당신의 건강을 돌보라
당신이 전문적으로 일을 더 잘할 수 있기 위해서는 좋은 건강 상태를 유지하는 것 이 필요하다. 

김창준 (마이크로소프트웨어) 
2002/06/02       
 
우리 프로그래머들은 항상 공부해야 합니다. 우리는 지식을 중요하게 여깁니다. 하지만 지식에 대한 지식, 즉 내가 그 지식을 얻은 과정이나 방법 같은 것은 소홀히 여기기 쉽습니다. 따라서 지식의 축적과 공유는 있어도 방법론의 축적과 공유는 매우 드문 편입니다. 저는 평소에 이런 생각에서 학교 후배들을 위해 제 자신의 공부 경험을 짬짬이 글로 옮겨놓았고, 이번 기회에 그 글들을 취합, 정리하게 되었습니다. 그 결실이 바로 이 글입니다.
이 글은 공부하는 방법과 과정에 관한 글입니다. 이 글은 제가 공부한 성공/실패 경험을 기본 토대로 했고, 지난 몇 년간 주변에서 저보다 먼저 공부한 사람들의 경험을 관찰, 분석한 것에 제가 다시 직접 실험한 것과 그밖에 오랫동안 꾸준히 모아온 자료들을 더했습니다. '만약 다시 공부한다면' 저는 이렇게 공부할 것입니다.

부디 독자 제현께서 이 글을 씨앗으로 삼아 자신만의 나무를 키우고 거기서 열매를 얻고, 또 그 열매의 씨앗이 다시 누군가에게 전해질 수 있다면 더 이상 바랄 것이 없겠습니다.

이 글은 특정 주제들의 학습/교수법에 대한 문제점과 제가 경험한 좋은 공부법을 소개하는 식으로 구성됐습니다. 여기에 선택된 과목은 리팩토링, 알고리즘·자료구조, 디자인패턴, 익스트림 프로그래밍(Extreme Programming 혹은 XP) 네 가지입니다.

이 네 가지가 선택된 이유는 필자가 관심있게 공부했던 것이기 때문만은 아니고, 모든 프로그래머에게 어떻게든 널리 도움이 될만한 교양과목이라 생각하여 선택한 것입니다. 그런데 이 네 가지의 순서가 겉보기와는 달리 어떤 단계적 발전을 함의하는 것은 아닙니다. 수신(修身)이 끝나면 더 이상 수신은 하지 않고 제가(齊家)를 한다는 것이 어불성설인 것과 같습니다.

원래는 글 후미에 일반론으로서의 공부 패턴들을 쓰려고 했습니다. 하지만 지면의 제약도 있고, 독자 스스로 이 글에서 그런 패턴을 추출하는 것도 의미가 있을 것이기에 생략했습니다. 그런 일반론이 여기 저기 숨어있기 때문에 알고리즘 공부에 나온 방법 대부분이 리팩토링 공부에도 적용할 수 있고, 적용되어야 한다는 점을 꼭 기억해 주셨으면 합니다. 다음에 기회가 닿는다면 제가 평소 사용하는 (컴퓨터) 공부패턴들을 소개하겠습니다.

알고리즘·자료구조 학습에서의 문제
우리는 알고리즘 카탈로그를 배웁니다. 이미 그러한 해법이 존재하고, 그것이 최고이며, 따라서 그것을 달달 외우고 이해해야 합니다. 좀 똑똑한 친구들은 종종 "이야 이거 정말 기가 막힌 해법이군!"하고 감탄할지도 모릅니다. 대부분의 나머지 학생들은 그 해법을 이해하려고 머리를 쥐어짜고 한참을 씨름한 후에야 어렴풋이 왜 이 해법이 그 문제를 해결하는지 납득하게 됩니다.

그리고는 그 '증명'은 책 속에 덮어두고 까맣게 사라져버립니다. 앞으로는 그냥 '사용'하면 되는 것입니다. 더 많은 대다수의 학생은 이 과정이 무의미하다는 것을 알기 때문에 왜 이 해법이 이 문제를 문제없이 해결하는지의 증명은 간단히 건너뜁니다.

이런 학생들은 이미 주어진 알고리즘을 사용하는 일종의 객관식 혹은 문제 출제자가 존재하는 시험장 상황에서는 뛰어난 성적을 보일 것임은 자명합니다. 하지만 스스로가 문제와 해답을 모두 만들어내야 하는 상황이라면, 또는 해답이 존재하지 않을 가능성이 있는 상황이라면, 혹은 최적해를 구하는 것이 불가능에 가깝다면, 혹은 알고리즘을 완전히 새로 고안해내야 하거나 기존 알고리즘을 변형해야 하는 상황이라면 어떨까요?

교육은 물고기를 잡는 방법을 가르쳐야 합니다. 어떤 알고리즘을 배운다면 그 알고리즘을 고안해낸 사람이 어떤 사고 과정을 거쳐 그 해법에 도달했는지를 구경할 수 있어야 하고, 학생은 각자 스스로만의 해법을 차근차근 '구성'(construct)할 수 있어야 합니다(이를 교육철학에서 구성주의라고 합니다. 교육철학자 삐아제(Jean Piaget)의 제자이자, 마빈 민스키와 함께 MIT 미디어랩의 선구자인 세이머 페퍼트 박사가 주창했습니다). 전문가가 하는 것을 배우지 말고, 그들이 어떻게 전문가가 되었는지를 배우고 흉내 내야 합니다.

결국은 소크라테스적인 대화법입니다. 해답을 가르쳐 주지 않으면서도 초등학교 학생이 자신이 가진 지식만으로 스스로 퀵소트를 유도할 수 있도록 옆에서 도와줄 수 있습니까? 이것이 우리 스스로와 교사들에게 물어야 할 질문입니다.
 

왜 우리는 학교에서 '프로그래밍을 하는 과정'이나 '디자인 과정'(소프트웨어 공학에서 말하는 개발 프로세스가 아니라 몇 시간이나 몇 십 분 단위의, 개인적인 차원의 사고 과정 등을 일컫습니다)을 명시적으로 배운 적이 없을까요? 왜 해답에 이르는 과정을 가르쳐주는 사람이 없나요? 우리가 보는 것은 모조리 이미 훌륭히 완성된, 종적 상태의 결과물로서의 프로그램뿐입니다. 어느 날 문득 하늘에서 완성된 프로그램이 뚝 떨어지는 경우는 없는데 말입니다.

교수가 어떤 알고리즘 문제의 해답을 가르칠 때, "교수님, 교수님께서는 어떤 사고 과정을 거쳐, 그리고 어떤 디자인 과정과 프로그래밍 과정을 거쳐서 그 프로그램을 만드셨습니까?"하고 물어봅시다. 만약 여기에 어떤 체계적인 답변도 할 수 없는 분이라면 그 분은 자신의 사고에 대해 '사고'해 본 적이 없거나 문제 해결에 어떤 효율적 체계를 갖추지 못한 분이며, 따라서 아직 남을 가르칠 준비가 되어있지 않은 분일 것입니다. 만약 정말 그렇다면 우리는 어떻게 해야 할까요?

자료구조와 알고리즘 공부
제가 생각건대, 교육적인 목적에서는 자료구조나 알고리즘을 처음 공부할 때 우선은 특정 언어로 구현된 것을 보지 않는 것이 좋을 때가 많습니다. 대신 말로 된 설명이나 의사코드(pseudo-code) 등으로 그 개념까지만 이해하는 것이죠. 그 아이디어를 절차형(C, 어셈블리어)이나 함수형(LISP, Scheme, Haskell), 객체지향(자바, 스몰토크) 언어 등으로 직접 구현해 보는 겁니다. 그 다음에는 다른 사람이나 다른 책의 코드와 비교합니다. 이 경험을 애초에 박탈당한 사람은 귀중한 배움과 깨달음의 기회를 잃은 셈입니다.

만약 여러 사람이 함께 공부한다면 각자 동일한 아이디어를 같은 언어로 혹은 다른 언어로 어떻게 다르게 표현했는지를 서로 비교해 보면 배우는 것이 무척 많습니다.

우리가 자료구조나 알고리즘을 공부하는 이유는, 특정 '실세계의 문제'를 어떠한 '수학적 아이디어'로 매핑시켜 해결할 수 있는지, 그것이 효율적인지, 또 이를 컴퓨터에 어떻게 효율적으로 구현할 수 있는지 따지고, 그것을 실제로 구현하기 위해서입니다. 따라서 이 과정에 있어 실세계의 문제를 수학 문제로, 그리고 수학적 개념을 프로그래밍 언어로 효율적으로 표현해내는 것은 아주 중요한 능력이 됩니다.

알고리즘 공부에서 중요한 것
개별 알고리즘의 목록을 이해, 암기하며 익히는 것도 중요하지만 더 중요한 것은 다음 네 가지입니다.

①알고리즘을 스스로 생각해낼 수 있는 능력
②다른 알고리즘과 효율을 비교할 수 있는 능력
③알고리즘을 컴퓨터와 다른 사람이 이해할 수 있는 언어로 표현해낼 수 있는 능력
④이것의 정상작동(correctness) 여부를 검증해 내는 능력

첫 번째가 제대로 훈련되지 못한 사람은 알고리즘 목록의 스테레오 타입에만 길들여져 있어서 모든 문제를 자신이 아는 알고리즘 목록에 끼워 맞추려고 합니다. 디자인패턴을 잘못 공부한 사람과 비슷합니다. 이런 사람들은 마치 과거에 수학 정석만 수십 번 공부해 문제를 하나 던져주기만 하면, 생각해보지도 않고 자신이 풀었던 문제들의 패턴 중 가장 비슷한 것 하나를 기계적·무의식적으로 풀어제끼는 문제풀이기계와 비슷합니다. 그들에게 도중에 물어보십시오. "너 지금 무슨 문제 풀고 있는 거니?" 열심히 연습장에 뭔가 풀어나가고는 있지만 그들은 자신이 뭘 풀고 있는지도 제대로 인식하지 못 하는 경우가 많습니다.

머리가 푸는 게 아니고 손이 푸는 것이죠. 이렇게 되면 도구에 종속되는 '망치의 오류'에 빠지기 쉽습니다. 새로운 알고리즘을 고안해야 하는 상황에서도 기존 알고리즘에 계속 매달릴 뿐입니다. 알고리즘을 새로 고안해 내건 혹은 기존의 것을 조합하건 스스로 생각해 내는 훈련이 필요합니다.

두 번째가 제대로 훈련되지 못한 사람은 일일이 구현해 보고 실험해 봐야만 알고리즘 간의 효율을 비교할 수 있습니다. 특히 자신이 가진 카탈로그를 벗어난 알고리즘을 만나면 이 문제가 생깁니다. 이건 상당한 대가를 치르게 합니다.

세 번째가 제대로 훈련되지 못한 사람은, 문제를 보면 "아, 이건 이렇게 저렇게 해결하면 됩니다"하는 말은 곧잘 할 수 있지만 막상 컴퓨터 앞에 앉혀 놓으면 아무 것도 하지 못합니다. 심지어 자신이 생각해낸 그 구체적 알고리즘을 남에게 설명해 줄 수는 있지만, 그걸 '컴퓨터에게' 설명하는 데는 실패합니다. 뭔가 생각해낼 수 있다는 것과 그걸 컴퓨터가 이해할 수 있게 설명할 수 있다는 것은 다른 차원의 능력을 필요로 합니다.

네 번째가 제대로 훈련되지 못한 사람은, 알고리즘을 특정 언어로 구현해도, 그것이 옳다는 확신을 할 수 없습니다. 임시변통(ad hoc)의 아슬아슬한 코드가 되거나 이것저것 덧붙인 누더기 코드가 되기 쉽습니다. 이걸 피하려면 두 가지 훈련이 필요합니다.

하나는 수학적·논리학적 증명의 훈련이고, 다른 하나는 테스트 훈련입니다. 전자가 이론적이라면 후자는 실용적인 면이 강합니다. 양자는 상보적인 관계입니다. 특수한 경우들을 개별적으로 테스트해서는 검증해야 할 것이 너무 많고, 또 모든 경우에 대해 확신할 수 없습니다. 테스트가 버그의 부재를 보장할 수는 없습니다. 하지만 수학적 증명을 통하면 그것이 가능합니다. 또, 어떤 경우에는 수학적 증명을 굳이 할 필요 없이 단순히 테스트 케이스 몇 개만으로도 충분히 안정성이 보장되는 경우가 있습니다. 이럴 때는 그냥 테스트만으로 만족할 수 있습니다.

실질적이고 구체적인 문제를 함께 다루라
자료구조와 알고리즘 공부를 할 때에는 가능하면 실질적이고 구체적인 실세계의 문제를 함께 다루는 것이 큰 도움이 됩니다. 모든 학습에 있어 이는 똑같이 적용됩니다. 인류의 지성사를 봐도, 구상(concrete) 다음에 추상(abstract)이 옵니다. 인간 개체 하나의 성장을 봐도 그러합니다. 'be-동사 더하기 to-부정사'가 예정으로 해석될 수 있다는 룰만 외우는 것보다 다양한 예문을 실제 문맥 속에서 여러 번 보는 것이 훨씬 나을 것은 자명합니다. 알고리즘과 자료구조를 공부할 때 여러 친구들과 함께 연습문제(특히 우리가 경험하는 실세계의 대상들과 관련이 있는 것)를 풀어보기도 하고, ACM의 ICPC(International Collegiate Programming Contest: 세계 대학생 프로그래밍 경진 대회) 등의 프로그래밍 경진 대회 문제 중 해당 알고리즘·자료구조가 사용될 수 있는 문제를 같이 풀어보는 것도 아주 좋습니다. 이게 가능하려면 "이 알고리즘이 쓰이는 문제는 이거다"하고 가이드를 해줄 사람이 있으면 좋겠죠. 이것은 그 구체적 알고리즘·자료구조를 훈련하는 것이고, 이와 동시에 어떤 알고리즘을 써야할지 선택, 조합하는 것과 새로운 알고리즘을 만들어내는 훈련도 무척 중요합니다.

알고리즘 디자인 과정의 중요성
알고리즘을 좀더 수월하게, 또 잘 만들려면 알고리즘 디자인 과정에 대해 생각해 봐야 합니다. 그냥 밑도 끝도 없이 문제를 쳐다본다고 해서 알고리즘이 튀어나오진 않습니다. 체계적이고 효율적인 접근법을 사용해야 합니다. 대표적인 것으로 다익스트라(E. W. Dijkstra)와 워스(N. Wirth)의 '조금씩 개선하기'(Stepwise Refinement)가 있습니다. 워스의 「Program Development by Stepwise Refinement」(1971, CACM 14.4, http://www.acm.org/classics/dec95)를 꼭 읽어보길 바랍니다. 여기 소개된 조금씩 개선하기는 구조적 프로그래밍에서 핵심적 역할을 했습니다(구조적 프로그래밍을 'goto 문 제거' 정도로 생각하면 안 됩니다). 다익스트라의 「Stepwise Program Construction」(Selected Writings on Computing: A Personal Perspective, Springer-Verlag, 1982, http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD227.PDF)도 추천합니다.

알고리즘 검증은 알고리즘 디자인과 함께 갑니다. 새로운 알고리즘을 고안할 때 검증해 가면서 디자인하기 때문입니다. 물론 가장 큰 역할은 고안이 끝났을 때의 검증입니다. 알고리즘 검증에는 루프 불변식(loop invariant) 같은 것이 아주 유용합니다. 아주 막강한 무기입니다. 익혀 두면 두고두고 가치를 발휘할 것입니다. 맨버(Udi Manber)의 알고리즘 서적(『Introduction to Algorithms: A Creative Approach』)이 알고리즘 검증과 디자인이 함께 진행해 가는 예로 자주 추천됩니다. 많은 계발을 얻을 것입니다. 고전으로는 다익스트라의 『A Discipline of Programming』과 그라이스(Gries)의 『The Science of Programming』이 있습니다. 특히 전자를 추천합니다. 프로그래밍에 대한 관을 뒤흔들어 놓을 것입니다.

알고리즘과 패러다임
알고리즘을 공부하면 큰 줄기들을 알아야 합니다. 개별 테크닉도 중요하지만 '패러다임'이라고 할만한 것들을 알아야 합니다. 이것에 대해서는 튜링상을 수상한 로버트 플로이드(Robert Floyd)의 튜링상 수상 강연(The Paradigms of Programming, 1978)을 추천합니다. 패러다임을 알아야 알고리즘을 상황에 맞게 마음대로 변통할 수 있습니다. 그리고 자신만의 분류법을 만들어야 합니다. 구체적인 문제들을 케이스 바이 케이스로 여럿 접하는 동안 그냥 지나쳐 버리면 개별자는 영원히 개별자로 남을 뿐입니다. 비슷한 문제들을 서로 묶어서 일반화해야 합니다.

이런 패러다임을 발견하려면 '다시 하기'가 아주 좋습니다. 다른 것들과 마찬가지로, 이 다시 하기는 알고리즘에서만이 아니고 모든 공부에 적용할 수 있습니다. 같은 것을 다시 해보는 것에서 우리는 얼마나 많은 것을 배울 수 있을까요. 대단히 많습니다. 왜 동일한 문제를 여러 번 풀고, 왜 같은 내용의 세미나에 또 다시 참석하고, 같은 프로그램을 거듭 작성할까요? 훨씬 더 많이 배울 수 있기 때문입니다. 화술 교육에서는 같은 주제에 대해 한 번 말해본 연사와 두 번 말해본 연사는 천지 차이가 있다고 말합니다. 같은 일에 대해 두 번의 기회가 주어지면 두 번째에는 첫 번째보다 잘 할 기회가 있습니다. 게다가 첫 번째 경험했던 것을 '터널을 벗어나서' 다소 객관적으로 볼 수 있게 됩니다. 왜 자신이 저번에 이걸 잘 못 했고, 저걸 잘 했는지 알게 되고, 어떻게 하면 그걸 더 잘할 수 있을는지 깨닫게 됩니다. 저는 똑같은 문제를 여러 번 풀더라도 매번 조금씩 다른 해답을 얻습니다. 그러면서 정말 엄청나게 많은 것을 배웁니다. '비슷한 문제'를 모두 풀 능력이 생깁니다.

제가 개인적으로 존경하는 전산학자 로버트 플로이드(Robert W. Floyd)는 1978년도 튜링상 강연에서 다음과 같은 말을 합니다.

제가 어려운 알고리즘을 디자인하는 경험을 생각해 볼 때, 제 능력을 넓히는 데 가장 도움이 되는 특정한 테크닉이 있습니다. 어려운 문제를 푼 후에, 저는 그것을 처음부터 완전히 새로 풉니다. 좀 전에 얻은 해법의 통찰(insight)만을 유지하면서 말이죠. 해법이 제가 희망하는 만큼 명료하고 직접적인 것이 될 때까지 반복합니다. 그런 다음, 비슷한 문제들을 공략할 어떤 일반적인 룰을 찾습니다. 아까 주어진 문제를 아예 처음부터 최고로 효율적인 방향에서 접근하도록 이끌어줬을 그런 룰을 찾는 거죠. 많은 경우에 그런 룰은 불변의 가치가 있습니다. … 포트란의 룰은 몇 시간 내에 배울 수 있습니다. 하지만 관련 패러다임은 훨씬 더 많은 시간이 걸립니다. 배우거나(learn) 배운 것을 잊거나(unlearn) 하는 데 모두.

수학자와 프로그래머를 포함한 모든 문제 해결자들의 고전이 된 죠지 폴리야(George Polya)의 『How to Solve it』에는 이런 말이 있습니다:

심지어는 꽤나 훌륭한 학생들도, 문제의 해법을 얻고 논증을 깨끗하게 적은 다음에는 책을 덮어버리고 뭔가 다른 것을 찾는다. 그렇게 하는 동안 그들은 그 노력의 중요하고도 교육적인 측면을 잃어버리게 된다. … 훌륭한 선생은 어떠한 문제이건 간에 완전히 바닥이 드러나는 경우는 없다는 관점을 스스로 이해하고 또 학생들에게 명심시켜야 한다.

저는 ACM의 ICPC 문제 중에 어떤 문제를 이제까지 열 번도 넘게 풀었습니다. 대부분 짝 프로그래밍이나 세미나를 통해 프로그래밍 시연을 했던 것인데, 제 세미나에 여러 번 참석한 분이 농담조로 웃으며 물었습니다. "신기해요. 창준 씨는 그 문제를 풀 때마다 다른 프로그램을 짜는 것 같아요. 설마 준비를 안 해 와서 그냥 내키는 대로 하는 건 아니죠?" 저는 카오스 시스템과 비슷하게 초기치 민감도가 프로그래밍에도 작용하는 것 같다고 대답했습니다. 저 스스로 다른 해법을 시도하고 싶은 마음이 있으면 출발이 조금 다르고, 또 거기서 나오는 진행 방향도 다르게 됩니다. 그런데 중요한 것은 이렇게 같은 문제를 매번 다르게 풀면서 배우는 것이 엄청나게 많다는 점입니다. 저는 매번, 전보다 개선할 것을 찾아내게 되고, 또 새로운 것을 배웁니다. 마치 마르지 않는 샘물처럼 계속 생각할 거리를 준다는 점이 참 놀랍습니다.

알고리즘 개론 교재로는 CLR(Introduction to Algorithms, Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest)을 추천합니다. 이와 함께 혹은 이 책을 읽기 전에 존 벤틀리(Jon Bentley)의 『Programming Pearls』도 강력 추천합니다. 세계적인 짱짱한 프로그래머와 전산학자들이 함께 꼽은 위대한 책 목록에서 몇 손가락 안에 드는 책입니다. 아직 이 책을 본 적이 없는 사람은 축하합니다. 아마 몇 주간은 감동 속에 하루하루를 보내게 될 겁니다.

리팩토링 학습에서의 문제
먼저, 본지 2001년 11월호에 제가 썼던 마틴 파울러의 책을 추천하는 글을 인용하겠습니다.

OOP를 하건 안 하건 프로그래밍이란 업을 하는 사람이라면 이 책은 자신의 공력을 서너 단계 레벨업시켜줄 수 있다. 자질구레한 술기를 익히는 것이 아니고 기감과 내공을 증강하는 것이다.

혹자는 DP 이전에 RF를 봐야 한다고도 한다. 이 말이 어느 정도 일리가 있는 것이, 효과적인 학습은 문제의식이 선행해야 하기 때문이다. DP는 거시적 차원에서 해결안을 모아놓은 것이다. RF를 보고 나쁜 냄새(Bad Smell)를 맡을 수 있는 후각을 발달시켜야 한다. RF의 목록을 모두 외우는 것은 큰 의미가 없다. 그것보다 냄새나는 코드를 느낄 수 있는 감수성을 키우는 것이 더 중요하다. 필자는 일주일에 한 가지씩 나쁜 냄새를 정해놓고 그 기간 동안에는 자신이 접하는 모든 코드에서 그 냄새만이라도 확실히 맡도록 집중하는 방법을 권한다. 일명 일취집중후각법. 패턴 개념을 만든 건축가 크리스토퍼 알렉산더나 GoF의 랄프 존슨은 좋은 디자인이란 나쁜 것이 없는 상태라고 한다. 무색 무미 무취의 무위(無爲)적 자연(自然) 코드가 되는 그 날을 위해 오늘도 우리는 리팩토링이라는 유위(有爲)를 익힌다.

주변에서 리팩토링을 잘못 공부하는 경우를 종종 접합니다. 어떤 의미에서 잘못 공부한다고 할까요? '실체화'가 문제입니다. 리팩토링은 도구이고 방편일 뿐인데, 그것에 매달리는 것은 달은 보지 않고 손을 보는 것과 같습니다. 저는 리팩토링 책이 또 하나의 (이미 그 병폐가 많이 드러난) GoF 책이 되는 현상이 매우 걱정됩니다.

리팩토링 공부
사람들이 일반적으로 생각하는 바와는 달리 리팩토링 학습에 있어 어떤 리팩토링이 있는지, 구체적으로 무엇인지 등의 리팩토링 목록에 대한 지식과 각각에 대한 메카닉스(Mechanics: 해당 리팩토링을 해나가는 구체적 단계)는 오히려 덜 중요할 수 있습니다. 더 기본적이고 유용한 것은 코드 냄새(Code Smell)와 짧은 테스트-코드 싸이클입니다. 이것만 제대로 되면 리팩토링 책의 모든 리팩토링을 스스로 구성해낼 수 있으며, 다른 종류의 리팩토링까지 직접 발견해낼 수 있습니다.

그 책에서는 테스트의 중요성이 충분히 강조되지 않았습니다. 하지만 테스트 코드 없는 리팩토링은 안전벨트 없는 자동차 경주와 같습니다. 그리고 테스트 코드가 리팩토링의 방향을 결정하기도 합니다. 양자는 음과 양처럼 서로 엮여 있습니다. 이런 의미에서 리팩토링은 TDD(Test Driven Development)와 함께 수련하는 것이 좋습니다. 훨씬 더 빨리, 훨씬 더 많은 것을 배울 수 있을 겁니다.

리팩토링을 공부할 때는 우선 코드 냄새의 종류를 알고, 왜 그것이 나쁜 냄새가 될 수 있는지 이해하고(그게 불가하다면 리팩토링 공부를 미뤄야 합니다) 거기에 동의할 수 있어야 합니다. 그런 다음, 대충 어떤 종류의 리팩토링이 가능한지 죽 훑어봅니다. 그 중 몇 개는 메카닉스를 따라가면서 실험해 봅니다. 이제는 책을 덮습니다. 그리고 실제 코드를 접하고, 만약 거기에서 냄새를 맡는다면 이 냄새를 없애기 위해 어떻게 해야 할지 스스로 고민합니다. 리팩토링 책의 목록은 일단 무시하십시오. 그 냄새를 없애는 것이 목표이지, 어떤 리팩토링을 여기에 '써먹는 것'이 목표가 되어선 안 됩니다. 이 때, 반드시 테스트 코드가 있어야 합니다. 그래야 '좋은' 리팩토링을 할 수 있습니다. 책을 떠나 있으면서도 책에서 떠나지 않는 방법입니다.

리팩토링을 하기 전에 초록색 불(테스트가 모두 통과)이 들어온 시점에서 코드를 일부 고치면 빨간 불(테스트가 하나라도 실패)로 바뀔 겁니다. 이게 다시 초록색 불이 될 때까지 최소한도의 시간이 걸리도록 하십시오. 현 초록색에서 다음 초록색까지 최소한의 시간을 소비하도록 하면서 코드와 테스팅을 오가게 되면 자기도 모르는 사이에 훌륭한 리팩토링이 자발공으로 터져 나옵니다. 여기서 목적지는 우선은 OAOO(Once And Only Once: 모든 것은 오로지 한 번만 말해야 한다)를 지키는 쪽으로 합니다. 그러면 OAOO와 짧은 테스트-코드 싸이클을 지키는 사이 어느새 탁월한 디자인이 튀어나옵니다. 참고로 저는 '모래시계 프로그래밍'이란 걸 가끔 합니다. 모래시계나 알람 프로그램으로 테스트-코드 사이클의 시간을 재는 것입니다. 그래서 가급적이면 한 사이클이 3분 이내(대부분의 모래시계는 단위가 3분입니다)에 끝나도록 노력합니다. 여기서 성공을 하건 실패를 하건 많은 걸 얻습니다.

리팩토링 수련법
제가 고안, 사용한 몇 가지 리팩토링 수련법을 알려드립니다.

①일취집중후각법: 앞에 소개한 본지 2001년 11월호에서 인용된 글 참조
②주석 최소화: 주석을 최소화하되 코드의 가독성이 떨어지지 않도록(혹은 오히려 올라가도록) 노력합니다. 이렇게 하면 자동으로 리팩토링이 이뤄지는 경우가 많습니다.
③OAOO 따르기: OAOO 법칙을 가능하면 최대한, 엄격하게 따르려고 합니다. 역시 자동으로 좋은 리팩토링이 이뤄집니다. 여기서 디자인패턴이 창발하기도 합니다. GoF 책을 한번도 보지 못한 사람이 디자인패턴을 자유자재로 부리는 경우를 보게 됩니다.
④디미터 법칙(Law of Demeter) 따르기: 디미터 법칙을 가능하면 지키려고 합니다. 어떤 리팩토링이 저절로 이뤄지거나 혹은 필요 없어지는가요?
⑤짝(Pair) 리팩토링: 함께 리팩토링합니다. 혼자 하는 것보다 더 빨리, 더 많은 걸 배우게 됩니다. 특히, 각자 작성했던 코드를 함께 리팩토링하고, 제3자의 코드를 함께 리팩토링해 봅니다. 사람이 많다면 다른 짝이 리팩토링한 것과 서로 비교하고 토론합니다.
⑥'무엇'과 '어떻게'를 분리: 어떻게에서 무엇을 분리해 내도록 합니다. 어떤 리팩토링이 창발합니까?

여기서 번, 짝 리팩토링은 아주 효과적인 방법입니다. 저는 이것을 협동적 학습(Collaborative Learning)이라고 부릅니다. 상대가 나보다 더 많이 아는 경우만이 아니고, 서로 아는 것이 비슷해도 많은 양의 학습이 발생합니다. 특히, 전문가와 함께 짝 프로그래밍을 하면 무서울 만큼 빠른 학습을 경험할 수 있습니다. 저와 짝 프로그래밍을 한 사람이 학습하는 속도에서 경이감을 느낀 적이 한두 번이 아닙니다. 문화는 사회적으로 학습되는 것입니다. 우리가 지식이라고 하는 것의 상당 부분은 문화처럼 암묵적인 지식(Tacit Knowledge)입니다. 전문가가 문제가 생겼을 때 어떻게 사고하고, 어떤 과정을 거쳐 접근하며, 어떻게 디버깅하고, 키보드를 어떤 식으로 누르는지, 사고 도구로 무엇을 사용하는지, 일 계획과 관리를 어떻게 하는지, 동료와 어떻게 대화하는지 등은 성문화되어 있지 않습니다. 그러나 이런 것들은 아주 중요합니다. 프로페셔널의 하루 일과의 대부분을 이루고 있기 때문입니다. 이런 것들은 전문가 바로 옆에서 조금씩 일을 도와주면서 배워야 합니다. 도제 살이(Apprenticeship)입니다. 진정한 전문가는 모든 동작이 우아합니다. 마치 춤을 추는 것 같습니다. 이 모습을 바로 곁에서 지켜보게 되면, 주니어는 한마디로 엄청난 충격을 받습니다. 그리고 스펀지처럼 빨아들이게 됩니다. 도대체 이 경험을 책이나 공장화한 학교가 어떻게 대신하겠습니까. 이와 관련해서는 레이브와 웽거(Jean Lave, Etienne Wenger)의 『Situated Learning : Legitimate Peripheral Participation』을 강력 추천합니다. 이 글을 보는 모든 교육 종사자들이 꼭 읽어봤으면 합니다. 이 협동적 학습은 두 사람만이 아니고 그룹 단위로도 가능합니다. 스터디에 이용하면 재미와 유익함 일석이조를 얻습니다.

이 외에, 특히(어쩌면 가장) 중요한 것은 일취집중후각법 등을 이용해 자신의 코드 후각의 민감도를 높이는 것입니다. 코드 후각의 메타포 말고도 유사한 메타포가 몇 가지 더 있습니다. 켄트 벡은 코드의 소리를 들으라고 하고, 저는 코드를 향해 대화하라고 합니다. 코드의 소리를 듣는 것은 코드가 원하는 것에 귀를 기울이는 것을 말합니다. 코드는 단순해지려는 욕망이 있습니다. 그걸 이뤄주는 것이 프로그래머입니다. 그리고 짝 프로그래밍을 할 때 두 사람의 대화를 코드에 남기도록 합니다. 주석이 아닙니다. 왜 이것이 중요한가는 본지 2001년 12월호 「허실문답 XP 강화」를 참고하기 바랍니다.

기학으로 우리 사상사에 큰 획을 그은 철학자요, '서울서 책만 사다 망한 사람'으로 이름을 날릴 정도로 엄청난 지식욕을 과시하던 조선시대 사상가 혜강 최한기는 그의 저술 『신기통』(神氣通)에서 '눈에 통하는 법(目通), 귀에 통하는 법(耳通), 코에 통하는 법(鼻通)' 등을 이야기하고 있습니다. 어떻게 하면 우리는 코드에 도통할 수 있을까요? 리팩토링을 공부하거나 혹은 했던 사람들에게 많은 영감과 메타포를 주는 책으로 일독을 권합니다. 필자가 기회가 닿는다면 프로그래밍을 혜강의 사상적 측면에서 조망한 글을 써보고 싶습니다.

앞서의 것들이 어느 정도 이뤄지고, 리팩토링에 대한 감이 오게 되면 그 때 비로소 리팩토링 책을 하나 하나 파헤치고 또 거기서 제대로 된 비판을 할 수 있게 됩니다.

디자인패턴 학습에서의 문제
잡지에 연재되거나 서적으로 출간된 혹은 세미나에서 진행되었던 디자인패턴 '강의'를 몇 가지 접했습니다. 훌륭한 강의도 많았지만 그렇지 못한 것도 있었습니다. 몇 가지 문제점을 지적하겠습니다.

◆패턴을 지나치게 실체화, 정형화해 설명한다.
◆컨텍스트와 문제 상황에 대한 설명이 없거나 부족하다. 결과적으로 문제를 해결하기 위해 패턴이 도입된 것이 아니라 패턴을 써먹기 위해 패턴이 도입된 느낌을 준다.
◆문제의식을 먼저 형성하게 하지 않고 답을 먼저 보여준 뒤 그걸 어디에 써먹을지 가르친다. 왜 이걸 쓰는 게 좋은지는 일언반구 언급이 없다. 독자는 '어린아이가 망치를 들고 있는 오류'에 빠질 것이다.
◆패턴이 어떻게 생성되었는지 그 과정을 보여주지 못한다. 즉, 스스로 패턴을 만들어내는 데 도움이 전혀 되지 않는다.
◆해당 패턴이 현실적으로 가장 자주 쓰이는 맥락을 보여주지 못한다. 대부분 장난감 문제(Toy Problem)에서 끝난다.

그런 패턴 강의를 하는 분들이 알렉산더(Christopher Alexander, 패턴언어 창시자)의 저작을 충실히 읽어봤다면 이런 병폐는 없을 것이라 생각합니다. 알렉산더의 저작을 접해보지 못 하고서 패턴을 가르치는 사람은 성경을 읽어보지 않은 전도사와 같을 것입니다. 알렉산더가 『The Timeless Way of Building』의 마지막에서 무슨 말을 하는가요?

이 마지막 단계에는 더 이상 패턴은 중요하지 않다. … 패턴은 당신이 현실적인 것에 대해 수용적이 되는 것을 가르쳐줬다.

패턴 역시 도구요, 방편일 뿐입니다. 패턴은 현실적인 것에 대해 수용적이 되도록 가르친다는 말은 결국 우리가 궁극적으로 추구하는 것은 패턴이 아니라 현실이어야 한다는 이야기입니다. 물론 처음 단계에는 교육적인 목적에서, 어느 정도 패턴에 얽매여도 괜찮다고는 해도, 나중에 패턴을 잊고 패턴에서 자유로워지려면 처음부터 패턴에 대해 도구적·방편적인 인식을 가져야 합니다.

미국 캘리포니아 주립대학의 교수 베티 에드워즈(Betty Edwards)가 쓴 책 중에 『Drawing on the Right Side of the Brain』이라는 유명한 베스트셀러가 있습니다. 사람의 뇌와 그림 그리기의 관계에 대한 탁월한 책입니다. 에드워즈는 자신의 그리기 실력을 향상시키기 위해 우뇌를 적극적으로 사용하는 구체적인 방법들을 가르쳐줍니다. 그 중 대표적인 것 하나가 대상을 뒤집어 놓고 그리는 것입니다. 지금 실험해 보길 바랍니다. 1000원권 지폐를 바로 놓고 그걸 비슷하게 그려보고, 이번에는 그걸 위아래가 거꾸로 되게 놓고 따라 그려보십시오. 아마 무척 놀랐을 겁니다. "아니 내가 이렇게 그림을 잘 그리다니! 그것도 거꾸로!" 그렇습니다. 우리는 자신의 머리 속 패턴에 얽매여 세상을 제대로 보지 못 할 때가 많습니다. 실체가 코에 약간이라도 비슷하게 보이면 우리는 그것을 이미 우리 머리 속에 추상적으로 갖고 있던 기하학적 '코'의 패턴으로 대체해버리는 것입니다.

디자인 패턴 공부
우선은 제 교육철학과 언어교습론, 그리고 공부론 이야기를 잠깐 하겠습니다.

기본적으로 교육은 교육자가 피교육자가에게 지식을 그대로 전달하는 행위가 아닙니다. 진정한 교육은 피교육자의 개인적 체험에 기반한 전폭적 동의에서 출발합니다. 저는 이를 동의에 의한 교육이라고 합니다.

제가 "주석문을 가능하면 쓰지 않는 것이 더 좋다"는 이야기를 했을 때 이 문장을 하나의 사실로 받아들이고 기억하면 당장 그 시점에는 학습이 일어나지 않는다고 봅니다. 대신 여러분이 차후에 여러 가지 경험을 하면서도 이 화두를 놓치지 않고 있다가 어느 순간엔가, "아! 그래, 주석문을 쓰지 않는 게 좋겠구나!"하고 자각하는 순간, 바로 그 시점에 학습과 교육이 이뤄지는 것입니다. 이는 기본적으로 삐아제와 비갓스키(Lev Vygotsky)의 구성주의를 따르는 것이죠. 지식이란 외부에서 입력받는 것이 아니고, 그것에 대한 모델을 학습자 스스로가 내부에서 구축할 때 획득할 수 있는 것이라는 사상이죠.

권법에서 주먹에 대해 달통한 도사가 '권을 내지르는 법'에 대한 규칙들을 정리해서 애제자의 머리 속에 아무리 쑤셔 넣는 데 성공한들 그 제자가 도사만큼 주먹이 나갈리는 만무합니다. 권을 내지르는 법을 유추해 내기까지 그 스승이 겪은 과정을 제자는 완전히 쏙 빼먹고 있기 때문입니다. 소위 '몸'이 만들어지지 않은 것이지요. 제자는 마당 쓸기부터, 물 긷기 등의 수련 과정을 겪어야만 하고 스승이 정리한 그 일련의 규칙에 손뼉을 치고 춤을 추며 기쁨의 동의를 할 수 있을 정도로 수련 과정이 축적된 이후에야 비로소 진정한 '가르침'이 이뤄지는 것이며, 청출어람의 가능성도 생각해 볼 수 있는 것입니다.

이런 동의라는 것은 학습자 자신만의 컨텍스트와 문제의식을 바탕으로 한 것입니다. 우리는 많은 경우, 어떤 지식과 동시에 그 지식의 필요성까지도 지식화해서 외부에서 주입을 받습니다. 하지만 진정 체화된 지식을 위해서는 스스로가 이미 문제의식을 갖고 있어야 합니다.

패턴도 마찬가지인데, 대부분 그 패턴의 필요성을 체감하지 못한 채 그냥 도식적 구조를 외우기에만 주력하는 사람이 많습니다만, 사실 그렇게 되면 어떤 경우에 이 패턴이 필요하고 어떤 경우에는 사용하면 안 되는지(GoF는 패턴을 정말 안다는 것은 그 패턴을 쓰면 안 될 때를 아는 것이라 했습니다) 등을 알기 힘듭니다. 설령 책에 나온 가이드를 암기했더라도요. 자신의 삶 속에서 문제의식이 구체적으로 실제 경험으로 형성되지 않았기 때문입니다.

GoF 중 한 명인 랄프 존슨(Ralph Johnson)은 다음과 같이 말합니다.

우리[GoF]는 책에서, 정말 그 패턴들이 필요하다는 것을 알만큼 충분한 경험을 갖기 전에는 그것을 [시스템 속에] 집어넣는 것을 피해야 한다고 말할 만큼 대담하진 못했다. 하지만 우리 모두는 그 사실을 믿었다. 패턴은 프로그램의 초기 버전이 아니고 프로그램 생애의 훨씬 나중에 가서야 비로소 등장해야 한다고 나는 늘 생각해 왔다.

결국은 어떤 패턴의 필요성을 자신의 경험 속에서 절감하지 못한다면 그 패턴을 제대로 아는 것이 아니라고 말할 수 있을 겁니다. 따라서 패턴 하나를 공부할 때는 가능한 한 실제 예를 많이 접해야 합니다. 그리고 패턴을 적용하지 않은 경우에서 그 필요를 느끼고 설명할 수 있게끔 다양한 코드를 접해야 합니다.

소프트웨어 개발에 푹 빠지기
패턴 중에 보면 서로 비슷비슷한 것이 상당히 많습니다. 그 구조로는 완전히 동일한 것도 있죠. 초보자를 괴롭히는 것 중 하나입니다. 이것은 외국어를 공부할 때 문법 중심적인 학습을 하면서 부딪치는 문제와 비슷합니다. '주어+동사+목적어'라는 구조로는 동일한 두 개의 문장, 즉 'I love you'와 'I hate you'가 구조적으로는 동일할지라도 의미론적으로는 완전히 반대가 될 수 있는 겁니다. 패턴을 공부할 때는 그 구조보다 의미와 의도를 우선해야 하며, 이는 다양한 실례를 케이스 바이 케이스로 접하면서 추론화 및 자신만의 모델화라는 작업을 통해 하는 것이 최선입니다. 스스로 문법을 발견하고 체득하는 것이라고 할까요.

DP는 사전과 같습니다. 이 책은 순서대로 소설 읽듯이 읽어나가라고 집필된 것이 아니고, 일종의 패턴 레퍼런스로 쓰인 것입니다. 역시 GoF의 한 명인 존 블리스사이즈(John Vlissides)는 다음과 같이 말합니다.

여기서 내가 강조하고 싶은 것은 디자인패턴, 즉 GoF 책을 어떻게 읽느냐는 것이다. 많은 사람들은 그 내용을 온전히 이해하기 위해서는 순서대로 읽어야 한다고 느낀다. 하지만 GoF는 소설이 아니라 레퍼런스 북이다. 독일어를 배우기 위해 독영 사전의 처음부터 끝까지 하나하나 읽으려고 하는 경우를 생각해 보라. 그렇게는 결코 배울 수 없을 것이다! 독일어를 마스터하기 위해서는 독일어 문화에 자기 자신을 푹 담궈야(immerse) 한다. 독일어로 살아야 하는 것이다. 디자인패턴도 똑같다. 그걸 마스터하기 이전에 소프트웨어 개발에 자신을 푹 담궈야 한다. 패턴으로 살아야 하는 것이다.
만약 꼭 그래야 한다면 소설 읽듯이 디자인패턴 책을 읽어라. 하지만 거의 아무도 그 방식으로 유창해지지 못한다. 소프트웨어 개발 프로젝트의 열기 속에서 패턴이 동작하게 하라. 실제 디자인 문제를 직면했을 때 그 패턴들의 통찰을 이용하라. 이것이 GoF 패턴들을 자신의 것으로 만드는 가장 효율적인 방법이다.

어떤 지식을 체화하기 위해선 그 지식으로 살아야 한다는 말을 확인할 수 있습니다. 영어를 배우려면 영어로 살고, DP를 배우려면 DP로 살라는 단순하면서도 아주 강력한 말입니다.

어떤 특정 문장 구조를 학습하는 데 최선은 그 문장 구조를 이용한 실제 문장을 나에게 의미 있는 실제 컨텍스트 속에서 많이 접하고 스스로 나름의 모델을 구축하여 교과서의 법칙에 '기쁨에 찬 동의'를 하는 것입니다.

주변에서 특정 패턴이 구현된 코드를 구하기가 힘들다면 이 패턴을 자신이 만지고 있는 코드에 적용해 보려고 노력해 볼 수 있습니다. 이렇게 해보고 저렇게도 해보고, 그러다가 오히려 복잡도만 증가하면 "아 이 경우에는 이 패턴을 쓰면 안 되겠구나"하는 걸 학습할 수도 있죠. GoF는 패턴을 배울 때는 한결 같이 "이 패턴이 적합한 상황과 동시에 이 패턴이 악용, 오용될 수 있는 상황"을 함께 공부하라고 합니다.

이런 식의 '사례 중심'의 공부를 위해서는 스터디 그룹을 조직하는 것이 좋습니다. 혼자 공부를 하건, 그룹으로 하건 커리프스키(Joshua Kerievsky)의 「A Learning Guide To Design Patterns」(http://www.industriallogic.com/papers/learning.html)를 참고하세요. 그리고 스터디 그룹을 효과적으로 꾸려 나가는 데는 스터디 그룹의 패턴 언어를 서술한 「Knowledge Hydrant」(http://www.industriallogic.com/papers/khdraft.pdf)를 참고하면 많은 도움이 될 겁니다. 이 문서는 뭐든지 간에 그룹 스터디를 한다면 적용할 수 있습니다.

LG2DP(「A Learning Guide To Design Patterns」) 뒷부분에 보면 DP를 공부하는 순서와 각 패턴에서 던질만한 질문이 같이 정리되어 있습니다. DP는 순차적으로 공부해야만 하는 것은 아닙니다. 효과적인 공부의 순서가 있습니다. sorry라는 단어를 모르면서 remorseful이라는 단어를 공부하는 학생을 연상해 보세요. 외국어 공부에서는 자기 몸에 가까운 쉬운 단어부터 공략하는 것이 필수적입니다. 이런 걸 근접 학습(Proximal Learning)이라고도 하죠. 등급별 어휘 목록 같은 게 있으면 좋죠. LG2DP에서 제안하는 순서가 그런 것 중 하나입니다.

랄프 존슨은 이런 순서의 중요성에 관해 다음과 같은 말을 했습니다.

… 하지만 나는 언제나 싱글톤 패턴을 가르치기 전에 콤포짓, 스트래터지, 템플릿 메쏘드, 팩토리 메쏘드 패턴을 가르친다. 이것이 훨씬 더 일반적인 것들이며, 대다수의 사람들은 아마도 이것들 중 마지막 두 가지를 이미 사용하고 있을 것이다.

마이크로패턴
그런데 사실 GoF의 DP에 나온 패턴들보다 더 핵심적인 어휘군이 있습니다. 마이크로패턴이라고도 불리는 것들입니다. DP에도 조금 언급되어 있긴 합니다. 이런 마이크로패턴은 우리가 알게 모르게 매일 사용하는 것들이고 그 활용도가 아주 높습니다. 실제로 써보면 알겠지만, DP의 패턴 하나 쓰는 일이 그리 흔한 게 아닙니다. 마이크로패턴은 켄트 벡의 『Smalltalk Best Practice Patterns』에 잘 나와 있습니다. 영어로 치자면 관사나 조동사 같은 것들입니다.

그리고 이런 마이크로패턴과 함께 리팩토링을 공부하는 게 좋습니다. 리팩토링은 패턴의 필요를 느끼게 해줍니다. 제가 리팩토링 공부에서도 언급했지만 OAOO를 지키면서 리팩토링을 하다보면 자연스레 디자인패턴에 도달하는 경우가 많습니다. 이 때는 지나친 엔지니어링(Overengineering)이 발생하지 않고, 오로지 필요한 만큼만 생깁니다. 이에 관해서는 커리프스키의 「Stop Over-Engineering!」(Software Development Magazine, Apr 2002, http://www.sdmagazine.com/documents/s=7032/sdm0204b/0204b.htm)의 일독을 권합니다. 리팩토링이 디자인패턴을 어떻게 생성해낼 수 있는지 보여주고 있습니다.

1980년대 이후 최근 알렉산더의 향방도 이런 쪽으로 가고 있습니다. 그는 자신이 발표한 기존 패턴들이 너무 크다고 생각해 그런 패턴들을 구성하고, 자동으로 만들어 내며, 또 관통하는 더 작은 원칙들을 발견하는 데 노력해 오고 있습니다. 코플리엔(James Coplien)은 컴퓨터계가 알렉산더의 최근 발전을 쫓아가지 못한다고 늘 이야기합니다.

제대로 된 패턴 구현을 위한 다양한 접근 시도하기
우리의 지식이라는 것은 한 가지 표현양상(representation)으로만 이뤄져 있지 않습니다. 사과라는 대상을 음식으로도, 그림의 대상으로도 이해할 수 있어야 합니다. 실제 패턴이 적용된 '다양한 경우'를 접하도록 하라는 것이 이런 겁니다. 동일 대상에 대한 다양한 접근을 시도하라는 것이죠. 자바로 구현된 코드도 보고, C++로 된 것도 보고, 스몰토크로 된 것도 봐야 합니다. 설령 '오로지 자바족'이라고 할지라도요(전 이런 사람들을 자바리안(Javarian)이라고 부릅니다. 자바와 바바리안(barbarian)을 합성해서 만든 조어지요). 이런 '오로지 하나만 공부하는 것'의 병폐에 대해서는 존 블리스사이즈가 쓴 「Diversify」(http://www.research.ibm.com/people/v/vlis/pubs/gurus-99.pdf)라는 글을 읽어보세요. 이렇게 다양화를 해야 비로소 자바로도 '상황에 맞는' 제대로 된 패턴을 구현할 수 있습니다. 패턴은 그 구현(implementation)보다 의도(intent)가 더 중요하다는 사실을 꼭 잊지 말고, 설명을 위한 방편으로 채용된 한 가지 도식에 자신의 사고를 구속하는 우를 범하지 않기를 빕니다.

이런 맥락에서 저는 DP를 공부할 때 GoF와 동시에 『Design Patterns Smalltalk Companion』을 필수적으로 읽기를 권합니다. 두 권은 말하자면 양날개입니다. 하나는 정적언어로 구현되었고(간간이 스몰토크 구현이 있긴 합니다), 다른 하나는 동적언어로 구현되어 있습니다. 언어와 패턴의 고리를 느슨하게 하고, 패턴을 여러 관점에서 신선하게 볼 수 있는 계기가 될 것입니다. 또, 한 쪽을 보고 이해가 잘 되지 않을 때 다른 쪽을 보면 쉽게 이해됩니다. 서로 상보적인 것이죠.

패턴도 결국 '문제해결'을 위한 한 가지 방편에 지나지 않습니다. 주변에서 "이 경우에는 무조건 이 패턴을 써야 합니다"하고 생떼를 쓰는 사람을 보면 씁쓸한 기분을 감출 수 없습니다.

디자인패턴 추천서
디자인패턴 책 중에 중요한 서적을 몇 권 소개하겠습니다.

◆『Design Patterns Explained』(Shalloway, Trott): 최근 DP 입문서로 급부상하고 있는 명저
◆『Design Patterns Java Workbook』(Steven John Metsker): DPE 다음으로 볼만한 책으로 쏟아져 나오는 시중의 조악한 자바 패턴 책들과는 엄연히 다르다. 워크북 형식을 채용해서 연습문제를 풀고 뒷부분의 답과 대조해 볼 수 있는 등 독학자가 공부하기에 좋다.
◆『Refactoring』(Martin Fowler): DP 공부 이전에 봐서 문제의식 형성하기(망치를 들면 모든 것이 못으로 보이는 오류 탈피)
◆『Design Patterns』: 바이블.
◆『Design Patterns Smalltalk Companion』: GoF가 오른쪽 날개라면 DPSC는 왼쪽 날개
◆『Pattern Hatching』(John Vlissides): DP 심화학습. 얇지만 밀도 높은 책.
◆『Smalltalk Best Practice Patterns』(Kent Beck): 마이크로 패턴. 개발자의 탈무드. 감동의 연속.
◆『Pattern Languages of Program Design』 1,2,3,4: 패턴 컨퍼런스 논문 모음집으로 대부분은 인터넷에서 구할 수 있음
◆『Pattern-Oriented Software Architecture』 1,2: 아키텍처 패턴 모음. 2권은 네트워크 애플리케이션의 아키텍처 모음.
◆『Concurrent Programming in Java』(Doug Lea): 컨커런트 프로그래밍에 대한 최고의 서적.
◆『Patterns of Software』(Richard Gabriel): 패턴에 관한 중요한 에세이 모음.
◆『Analysis Patterns』(Martin Fowler): 비즈니스 분석 패턴 목록. 비즈니스 애플리케이션 개발자에게 많은 도움이 됨.
◆『A Timeless Way of Building』(Christopher Alexander): 프로그래머들이 가장 많이 본 건축 서적. 패턴의 철학적·이론적 배경. '구약'('신약'은 올해 안에 출간 예정인 동저자의 『The Nature of Order』).
◆『A Pattern Language』(Christopher Alexander): 알렉산더의 건축 패턴 모음집.
◆『Problem Frames』(Michael Jackson): DP의 해결(solution) 지향식의 문제점과 극복 방안으로서의 문제 지향식 방법. 마이클 잭슨은 요구 사항 분석 쪽에서 동명의 가수만큼이나 유명.

DP를 처음 공부한다면, DPE와 DPJW를 RF와 함께 보면서 앞서의 두 권을 RF적으로 독해해 나가기를 권합니다(하버드 대학의 뚜웨이밍 교수는 요즘 칸트를 유교적으로 독해하고 있다고 합니다. 하나의 책을 다른 각도에서 독해하는 것, 여기서 배우는 것이 많습니다). 이게 된 후에는 GoF와 DPSC를 함께 볼 수 있습니다. 양자는 상호 보완적인 면이 강합니다. 이쯤 되어 SBPP를 보면 상당히 충격을 받을 수 있습니다. 스스로가 생각하기에 코딩 경험이 많다면 다른 DP 책 이전에 SBPP를 먼저 봐도 좋습니다.

이 정도의 책을 봤다면 POSA와 PLOPD 등에서 자신이 관심이 가는 패턴들을 찾아 읽는 것이 좋습니다. 그리고 동시에 알렉산더의 원저들을 꼭 읽기를 권합니다. 가브리엘의 책이 알렉산더의 사상 이해에 많은 도움이 될 것입니다.

패턴 공부를 해나가면서 남을 가르치는 것이 공부에 많은 도움이 됩니다(사실 자바 패턴 책 중에 어떤 것은 "내가 패턴을 처음 공부하면서 같이 쓴 것이다"라고 저자가 고백한 것도 있습니다). 보이스카웃에서는 보통 다음 과정을 통해 뭔가를 '학습'하게 한다고 합니다. 처음은 어떻게 하는지를 보여주고, 다음은 스스로 그것을 해보게 하고, 다음으로 그걸 남에게 가르치게 합니다. 이 때 중요한 것은 상대가 이해하지 못 하면 그 이유를 자기 자신에게서 찾는 것이 나에게 더 이득이 된다는 것입니다. "내가 설명을 잘못 했군"하고 생각하는 것이죠. 그러면 다음번에는 설명을 좀더 잘 할 수 있게 되고, 동시에 자기의 이해도 더욱 명료해지게 됩니다. 저는 'OOP 개념을 한 시간 만에 가르치기'나 '특정 언어 문법을 한 시간 만에 가르치기' 등을 하나의 도전으로 생각하고 즐깁니다. 가르치면서 동시에 배운다는 것은 정말 놀라운 경험입니다.

익스트림 프로그래밍 학습에서의 문제
앞의 경우와 비슷합니다. 익스트림 프로그래밍을 공부하는 사람들은 실제로 행해보지 않고 책만 들여다보면 안 됩니다. 그렇다고 책이 중요하지 않다는 말은 아닙니다. 하지만 자전거 타기는 자기 몸으로 직접 굴려봐야 합니다.

게다가 켄트 벡 스스로가 『XP Explained』를 만약 다시 쓴다면 뜯어고치고 싶은 부분이 상당히 된다고 말하는 것을 봐도 알 수 있듯이 초기 XP 이후 바뀌고 보완된 점이 상당수 있습니다. 따라서 책만으로 XP를 공부하기는 힘듭니다. 지금은 책 속의 XP가 사람들의 머리 속 XP에 한참 뒤쳐져 있습니다.

어찌 되었든 XP에는 무술이나 춤, 혹은 악기 연주 등과 유사한 면이 많습니다. 따라서 글을 보고 그것을 익히기는 쉽지 않습니다. 그나마 메일링 리스트 같은 '대화'를 보면 훨씬 더 많은 것을 얻을 수 있기는 하지만, 태권도 정권 찌르기를 말로 설명하는 것이 불가능에 가깝듯이 XP를 언어를 통해 익히기는 정말 어렵습니다. 우리의 언어는 너무도 성글은 미디어입니다(XP는 매 초, 매 순간 벌어지는 '일상적' 장면의 연속이 매우 중요합니다).

익스트림 프로그래밍 공부
XP를 이해하려면 다음 기본 자료에 대한 이해가 우선해야 합니다(본지 2001년 12월호 「허실문답 XP 강화」 참조).

◆『XP Explained』(Kent Beck): XP 선언서
◆『XP Installed』(Ron Jeffries et al): C3 프로젝트에 적용한 예, 얻은 교훈 등
◆『Planning XP』(Kent Beck, Martin Fowler): 계획 부분 설명(관리자, 코치용)
◆『Refactoring』(Martin Fowler): 리팩토링에 대한 최고의 책
◆『XP Applied』: 유즈넷과 메일링 리스트의 논의 등 최근 자료를 반영
◆『XP Explored』: 가장 쉽고 구체적인 XP 안내서

이 중에서 XPI나 XPX를 먼저 권합니다. XPE는 좀 추상적인 서술이 많아서 봐도 느낌이 별로 없을 수 있습니다(2001년 본지 11월호에 제가 쓴 리뷰 참고). 여유가 되면 다음 자료를 더 참고합니다.

◆『The Timeless Way of Building』: 패턴 운동을 일으킨 알렉산더의 저작. 현장 고객(On-site Customer), 점진 성장(Piecemeal Growth), 소통(Communication) 등의 아이디어가 여기에서 왔음.
◆『XP in Practice』(Robert C. Martin 외): 두세 사람이 짧은 기간 동안 간단한 프로젝트를 XP로 진행한 것을 기록. 자바 사용(중요한 문헌은 아님).
◆『XP Examined』: XP 컨퍼런스에 발표된 논문 모음
◆『Peopleware』(Tom DeMarco): 개발에 있어 인간 중심적 시각의 고전
◆『Adaptive Software Development』(Jim Highsmith): 복잡계 이론을 개발에 적용. 졸트상 수상.
◆『Surviving Object-Oriented Projects』(Alistair Cockburn): 얇고 포괄적인 OO 프로젝트 가이드라인
◆『Software Project Survival Guide』(Steve McConnell): 조금 더 전통적인 SE 시각.
◆『The Psychology of Computer Programming』(Gerald M. Weinberg): 프로그래밍에 심리학을 적용한 고전. 코드 공유와 짝 프로그래밍에 필수인 비자아적 프로그래밍(Egoless Programming)이 여기서 나왔다.
◆『Agile Software Development』(Alistair Cockburn): 전반적 애자일 방법론에 대한 개론서
◆『Software Craftsmanship』(Pete McBreen): 장인으로서의 새로운 프로그래머 상
◆『Agile Software Development with SCRUM』(Schwaber Ken): 최근 확장성(Scalability)을 위해 XP+SCRUM의 시도가 애자일 쪽의 큰 화두임.
◆『A Practical Guide to eXtreme Programming』(David Astels 외): 저자들이 직접 참여한 프로젝트를 따라가 보면서 배움. 자바로 구현. XPP보다는 스케일이 큼.
◆『Agile Modeling』(Scott Ambler): 애자일 쪽에서 모델링이 무시되는 느낌이 있을 수 있는데, 그쪽으로 깊게 천착한 사람이 앰블러임.
◆『Agile Software Development Ecosystems』(Jim Highsmith): 각각의 애자일 방법론에 대한 소개와 동시에 각 방법론의 대표자들 인터뷰가 백미.
◆『Test Driven Development』(Kent Beck): 곧(아마 올해 내에) 출간 예정인 최초의 TDD 서적. TDD를 모르면 XP도 모르는 것(TDD를 실제 적용하려면 적어도 반년 정도는 계속 훈련해야 함)
◆IEEE Software/Computer, CACM, Software Development Magazine 등에 실린 기사
◆『XP Conference, XP Universe 등의 논문들(특히 최근 것들)
◆유즈넷, 메일링 리스트, 오리지널 위키(http://c2.com)의 논의들

특히 유즈넷, 메일링 리스트, 오리지널 위키는 늘 가까이 하고 있어야 합니다. 이 세 곳을 살필 때, 특히 다음 사람들의 글은 꼭 읽어보고 항상 레이더를 열어두면 좋습니다(이 외에도 개발 경력 10년, 20년이 넘는 짱짱한 사람이 많으므로 눈 여겨 관찰하세요. 모든 글을 읽는 것은 무리이므로 그들의 대화를 일차적으로 읽어야 합니다).

켄트 벡, 론 제프리즈(Ron Jeffries), 워드 커닝엄(Ward Cunningham), 앨리스테어 코번(Alistair Cockburn), 마틴 파울러, 로버트 마틴 혹은 엉클 밥(Robert C. Martin aka Uncle Bob), 마이클 페더즈(Michael Feathers), 켄 아우어(Ken Auer), 윌리엄 웨이크(William Wake), 로이 밀러(Roy Miller), 데이브 토마스(Dave Thomas), 앤디 헌트(Andy Hunt), 랄프 존슨, 스카트 앰블러(Scott Ambler), 짐 하이스미스(Jim Highsmith), 조슈아 커리프스키(Joshua Kerievsky), 로렌트 보사빗(Laurent Bossavit), 존 브루어(John Brewer) 등

이런 자료들 외에, 기회가 된다면 주변에서 XP를 직접 사용하는 곳을 방문해서 하루만 같이 생활해 보기를 권합니다. 반년 공부를 앞당길 수 있습니다. 제가 공부할 때는 주변에 XP를 아는 사람이 없어서 혼자 공부했는데, 그것에 비해 XP를 직접 사용하는 상황에 처한 사람은 (제가 억울하리만큼) 더 적은 노력으로 몇 배 이상 빨리 몸에 익히는 것 같았습니다.

이게 힘들면 같이 공부하는 방법이 있습니다(앞서 언급된 스터디 그룹에 관한 패턴 참고). 이 때 같이 책을 공부하거나 하는 것은 시간 낭비가 많습니다. 차라리 공부는 미리 다 해오고 만나서 토론을 하거나 아니면 직접 실험을 해보는 것이 훨씬 좋습니다. 두 사람 당 한 대의 컴퓨터와 커대란 화이트보드를 옆에 두고 말이죠. 제 경우 스터디 팀과 함께 저녁 시간마다 가상 XP 프로젝트를 많이 진행했고, 짤막짤막하게 프로그래밍 세션도 많이 가졌습니다. 나중에 회사에서 직접 XP를 사용할 때 많은 도움이 되었습니다.

Refactor Me
제가 하고 싶은 말은 더 있지만 이 글은 일단 여기서 끝이 납니다. 서두에서 말씀드렸듯이 애초 쓰려던 '일반론'은 생략하고, 대신 독자들의 몫으로 남겨두려 합니다. 이 글 자체가 여러분의 리팩토링 수련의 연장(延長)이 되었으면 하는 바램입니다. 이 글과 함께 실생활에서 직접 실험을 해보면서 - 이 때 욕심 부리지 않고 한 가지씩 지긋이 해보는 느긋함과 음미의 정신이 필요할지도 모르겠습니다 - 자신의 경험을 축적해 나가고, 동시에 이 글을 적절히 리팩토링해서 자신만의 패턴을 차근히 만들어 나가길 바랍니다. 그렇습니다. 리팩토링은 대상에 대한 이해가 깊고 경험이 많을수록 더 잘할 수 있습니다.

이 글에 소개된 제 공부론은 어찌 보면 상당히 진부해 보이기도 할 것입니다. 하지만 저는 이런 상식적이고 일상적이며 심지어는 소소해 보이는 것들에서 많은 감동을 받아왔습니다. 이 글도 사실 제 감동의 개인사입니다. 저는 "만약 오늘 어떤 것에라도 감동한 것이 없었다면, 오늘은 뭔가 잘못 산 것이다"라는 신조를 갖고 있습니다. 그것이 컴퓨터이건 대화이건 상관없이 말이죠. 저는 날마다 감동하며 살려고 노력합니다. 그러나 이 감동에 뭔가 꼭 대단한 것이 필요한 것은 아닙니다. 저는 오히려 감동 받기 위해 스스로 대단해져야 할 필요를 느끼기도 합니다. '감동'이라는 것은 주어지는 것이 아닙니다. 나와 타자가 공조하여 만드는 대화입니다.

감동해야 체득할 수 있다고 생각합니다. 그리고 이 감동은 개인적 삶 속에서 자기가, 자신의 몸으로, 직접 얻는 것입니다. 工夫 열심히 합시다.

-출처 : www.ehclub.net

[출처] http://najsulman.tistory.com/

http://msdn.microsoft.com/ko-kr/library/9xyb5w93(v=vs.80).aspx

- 의대생 시절 만난 첫사랑, 지금의 아내
- 일본 수학자 히로나카 헤이스케의 책 <학문의 즐거움>이 인생에 큰 영향 미쳐

이름만으로 브랜드를 형성하는 사람들이 있다. 국민 피겨 요정, 국민 MC처럼 호칭만으로 쉽게 이름이 떠오르는 이들이 브랜드 가치를 갖는 이유는 단순히 인기 때문만은 아니다. ‘김연아라면’ 여느 피겨선수와는 다른 경기를 보여줄 것이라는 믿음, ‘유재석이라면’ 재미와 의미가 있는 프로그램을 매끄럽게 진행할 것이라는 기대는 다름 아닌 ‘신뢰’에서 비롯된다. 오늘의 명사 역시 그 이름만으로 믿음직한 브랜드를 형성하는 인물이다. 바이러스 백신 전문가, 컴퓨터 의사. 다름 아닌 국민 멘토 안철수 카이스트 교수다.

자신의 이름을 내걸고 설립한 연구소를 ‘가장 안전한 이름’으로 만들어 낸 그는 보안 정보 분야에서 큰 성과를 거둔 이후에도 사리사욕을 채우기보다 사회에 책임을 다하는 면모를 보여줬다. 그 덕분에 ‘안철수’라는 이름은 이제 국가적 브랜드가 됐으며 누구나 안철수라는 이름을 들으면 믿음을 갖게 된다.

수많은 사람들이 선호하는 의사라는 직업을 버리고, 자신이 하고 싶은 일을 찾아 바이러스 백신 연구소를 차린 그의 일화는 이미 유명하다. 그러나 그런 그에게도 다른 대학생들처럼 방황하고, 사랑에 빠졌던 시기가 있었다는 사실은 잘 알려지지 않았다. 하지만 자칫 평범할 수도 있었던 그의 젊은 시절이 남들과 달랐던 이유는 그 스스로 ‘원칙’을 만들고 치열하게 지켜왔기 때문이다. 남이 대신 살아줄 수 없는 나 자신의 삶에 대한 열정, 그리고 애정이 묻어나는 안철수 교수의 원칙이 담긴 젊은 시절 이야기를 들어봤다.

대학 교실에서 의대 친구들과 함께

안 교수는 '남 보기에 좋은 삶'이 아닌 '자신의 만족하는 삶'을 찾기 위해 안철수 연구소를 설립했다. 리더피아 9월 호에 실린 사진.

- 삶에 대한 태도와 원칙은 무엇입니까?

제가 삶에서 가장 중요하게 여기는 것은 정직, 성실 그리고 끊임없이 공부하는 자세, 이렇게 세 가지입니다. 단어로만 봤을 때 얼핏 구태의연해 보이기까지 하는 이 세 가지를 일일이 설명할 필요는 없겠죠?

분명한 것은 이러한 개인적인 가치관들이 CEO로서의 행동기준과 경영철학의 근간이 되고 있다는 사실입니다. 그리고 이 가치관은 우리 회사의 핵심가치 속에도 녹아 들어 있습니다. 즉, 정직은 고객과의 약속을 반드시 지키는 것에, 성실은 세 가지 핵심가치 모두에, 공부하는 자세는 자신의 발전을 위해서 노력한다는 것에 스며들어 있습니다.

이러한 가치관을 뿌리로 해 제게는 또한 ‘삶의 원칙’과 ‘판단 기준’이라는 현실적 줄기가 있습니다. 살아가는 동안 중심을 잡아줄 삶의 원칙은 내 자신에게만 적용하는 것과 다른 사람과의 관계에서 적용하는 것으로 나눌 수 있을 것입니다. 내 자신이 스스로 지키고자 하는 ‘삶의 원칙’을 소개하자면 다음과 같아요.



다른 사람과의 관계에서 지키고자 하는 삶의 원칙은 다음과 같습니다.



삶의 원칙 못지않게 ‘판단 기준’ 또한 그 사람의 삶에 있어 무척 중요하죠. 판단기준에 의해 선택을 하게 되고 그러한 선택들 하나하나가 인생을 만들어 나가는 것이니까요. 어떤 판단을 해야 할 때는 다음과 같은 세 가지 기준으로 결정을 합니다.

첫째 기준은 원칙을 지킨다는 것입니다.
매사가 순조롭고 편안할 때는 누구나 원칙을 지킬 수 있습니다. 그렇지만 원칙을 원칙이게 만드는 힘은 어려운 상황, 손해를 볼 것이 뻔한 상황에서도 지켜냄으로써 생겨난다고 생각합니다. 그처럼 힘든 상황 하에서도 원칙을 지켜간다면, 언젠가는 큰 힘을 발휘하게 될 것이라고 믿습니다.

둘째 기준은 본질에 충실 한다는 것입니다.
어떤 사안에 대해 판단을 내려야 할 때 그 사안에 대해 여러 가지 선택이 주어질 경우가 있는데, 본질과 직접 관련이 없는 것은 제외하고 본질과 직접적인 관련이 있는 것들만 고려해서 판단을 내린다면 옳은 결정을 할 수 있다고 생각합니다.

예를 들어서 돈, 명예, 주위의 평판 등은 본질이라기보다는 열심히 노력한 후에 얻을 수 있는 결과이기 때문에, 판단을 할 때 고려하지 않는 것이 바람직하다고 생각합니다. 결과에 해당하는 것들을 제외하고 나면 고려해야 할 점들이 훨씬 단순해져서 올바른 판단에 한걸음 더 다가갈 수 있는 것이죠.

제가 판단기준으로 삼는 셋째 기준은 장기적인 시각으로 본다는 것입니다.
단기적인 이익이나 승부에 집착하다 보면 당장에는 작은 이익을 볼 수 있을지 몰라도 장기적으로 보면 실패할 가능성이 높아진다고 생각합니다. 눈앞의 순간적인 이익에 연연하기보다는 장기적인 관점에서 옳은 쪽으로 판단하고 차근차근 일을 진척시켜 나가는 것이야말로 결국 참된 성공에 이르는 길이라고 믿어요. 성공이라는 것의 본질 자체가 단기적인 것이 아니기 때문이죠.

처음 회사를 만들 때부터 지금까지, 저는 변함없이 제 자신, 개인보다 전체 조직을 더 중요하게 생각해 왔습니다. 그리고 그러한 생각 자체가 사람들이 모인 조직을 이끄는 리더라면 조직의 크기와 상관없이 필수적으로 가져야 하는 생각이라고 믿고 있습니다.

단언하건대, 전체가 잘될 수 있다면 나는 개인적인 이해타산과 상관없이 어떠한 선택도 할 수 있는 마음의 자세를 가지고 있습니다. 그리고 지금까지 말로만 이야기하기 보다는 실제로 행동으로 보여준 때도 많은 것 같습니다.

그러한 행동들 중에는 외부에서 보기에는 놀라운 선택도 있었던 것 같아요. 그러나 그 모든 선택들은 나 나름대로의 기준에서 우리 모두가 잘될 수 있기 위해 필요한 것들이었죠. 그런 마음은 앞으로도 변하지 않을 것입니다.

- 그렇다면 본인이 생각하는 성공이란 무엇입니까?

제 인생의 성공의 정의는 ‘삶의 흔적을 남기는 것’입니다. 영어 표현으로는 ‘Make a difference’하고 싶네요. 내가 죽고 나서도, 내가 처음부터 존재하지 않았을 때와는 다른 것이 이 세상에 남았으면 해요. 크로마뇽인의 벽화처럼, 이름이 남아있지도 않고 누구인지는 알 수 없지만, 사람들의 생각의 변화나 제도, 책, 조직처럼 누군가가 있었다는 흔적이 남기를 바라는 거죠.

영화 ‘스파이더맨을 보면 이런 말이 나옵니다. "With great power comes great responsibility" 그는 파워를 원하진 않았지만 그걸 가지고 있으면 합당한 일을 해야 합니다. 이름이 알려지는 것을 원하지 않았지만, 열심히 공부하다보니 한 사람 두 사람, 소문 나서 사람들이 보고 있고 기대를 해 책임감도 생겼어요. 제가 원하지 않는 책임감이지만 많은 사람의 기대를 저버리는 일은 해선 안 된다는 생각입니다.

대학 교실에 혼자 있는 안철수 교수의 과거 모습

- 젊은 시절 가장 열중했던 일은 무엇입니까?

공부 양이 많았던 의대생이다보니 공부에 열중할 수밖에 없었습니다.

그리고 20대 시절에는 이런 고민을 많이 했던 것 같아요. 개인이 사회 속에서 얻을 수 있는 여러 이익들이 결코 자기 혼자만의 힘으로 이루어진 것이 아니라 선조로부터 내려온 지혜와 동시대에 산업 현장에서 열심히 일하시는 분들의 노력이 모여서 만들어진 것인데, 당시 저는 학생이었기 때문에 주어진 공부만 성실히 해내면 그러한 혜택들을 비교적 쉽게 받을 수 있었습니다. 그래서 사회에 항상 빚진 마음이 들었고, 어떻게 하면 사회의 한 구성원으로서 제가 받은 혜택의 일부라도 돌려드릴 수 있을까 하는 것들이 고민으로 자리잡았습니다.

그리고 그러한 고민을 해결할 방법을 찾다가 의료봉사를 시작하게 되었는데요. 당시 구로동 공단이나 무의촌 주변에서 무료 진료를 실시하면서 사회구성원으로서의 역할에 대한 많은 생각들을 할 수 있었습니다. 그리고 그러한 경험들이 나중에 컴퓨터 바이러스 백신 프로그램을 무료로 배포할 수 있도록 만들어준 생각의 기초가 된 것 같습니다.

- 젊은 날에 지녔던 초심을 일관되게 지켜왔다고 생각하십니까?

살아가면서 내 스스로가 만든 삶의 원칙들을 100% 지켜냈다고는 할 수 없습니다. 그렇지만 늘 충실히 지키려고 노력하고 있다는 것은 자신 있게 말할 수 있어요. 또한 앞서 이야기했듯 제 판단 기준 첫 번째는 ‘원칙을 지킨다’ 입니다. 물론 어려운 상황도 많았지만 오히려 이러한 상황이 원칙이 더 필요한 순간이죠. 힘든 상황, 손해 볼 것이 뻔한 상황 하에서도 원칙을 지켜간다면, 그것이 언젠가는 큰 힘을 발휘하게 될 것이라고 믿으며 살아가고 있습니다.

80년 서울대학교 의대 입학 시절의 모습

- 자신이 가장 자랑스러웠던 순간은 언제였습니까?

처음 백신을 개발한 후 의대 교수로서, 군의관으로서 일하며 틈틈이 시간을 쪼개 백신 개발을 계속했습니다. 박사 학위를 받고 군의관 복무를 마친 뒤에 컴퓨터와 의학 중 하나를 선택해야 하는 시점이 되어 깊은 고민에 빠지게 되었습니다.

거듭된 고민을 해결해 줄 실마리는 ‘내가 이때까지 살아왔던 삶은 남이 보기 좋은 삶이었다’라는 사실을 깨달으면서 풀렸습니다. 서울대 의대 졸업, 20대 의학 박사, 20대 의대 교수로 이어지던 순탄한 과정은 남이 보기에는 좋았을지 모르지만 컴퓨터를 하면서 느낄 수 있었던 자부심, 보람, 사명감, 성취감 등을 주지는 못했죠. 살아온 시간보다는 살아갈 날이 더 많은 시점에서, 지금까지 쌓아온 것에 연연하기보다는 앞으로 더 보람을 느낄 수 있고, 해 나갈 일이 많은 쪽을 선택하는 것이 올바르다는 생각이 들었습니다. 결국 14년간 공부해서 박사 학위까지 받았던 의학을 포기하기로 결심하고 안철수 연구소를 설립하게 되었죠. 많은 고민을 했지만

- 자신이 가장 부끄러웠던 순간은 언제였습니까?

세상에는 똑똑한 사람이 너무 많고 노력하는 사람들도 많죠. MBA과정을 40대 중반에 밟게 됐는데 편하게 청강생이나 연구원으로 갈 수도 있었습니다. 그러나 27년 동안 공부를 했지만 마음 편하게 하는 공부는 남는 게 없더라고요. 그래서 인터뷰를 거쳐 학위과정을 선택했어요. 과제, 프로젝트, 시험 등 고생을 하며 공부할 때가 남는 것이 많기 때문이었죠.

‘No pain, no gain’ 남들은 속일 수 있어도 자신은 못 속입니다. 공부할 때 편하다고 생각하면 나에게는 위험신호에요. 회사경영만 10년 해서 많은 부분을 알 수 있을 거라 생각했지만, 어떤 부분은 부끄러울 정도로 부족하다는 것을 알게 됐습니다. 경험만으로는 채울 수 없는 부분이 있었죠.

- 본인에게 부모님이란 어떤 의미입니까?

이렇게 해라 저렇게 해라 말씀을 많이 하시지는 않았습니다. 어렸을 때 아버지가 신문에 난 적이 있는데 신문배달 하는 소년이 교통사고를 당해서 무료진료를 해주었다는 내용이었습니다. 올해 여든이신 데 환자 볼 때 말고는 계속 책만 읽으셨던 것으로 기억합니다. 아버님께선 50대 중반의 나이에 가정전문의 시험을 쳐서 합격을 하기도 하셨죠. 제가 뒤늦게 공부하러 갈 수 있었던 것도 그런 영향을 받은 것 아닌가 싶어요.

어머니께서는 저에게 늘 존댓말을 쓰셨어요. 고등학교 때, 급한 일로 택시를 타게 되어 어머니가 택시를 잡아주셨는데 차가 떠나자마자 기사가 내게 물었어요. “형수님이신가요?” 제가 어머니라고 대답하자 그는 깜짝 놀라면서 “학생은 훌륭한 어머니를 두었으니 나중에 그 은혜를 잊지 않고 잘 모셔야 한다.”고 했어요. 늘 듣던 말이라서 그랬는지 그날도 “다녀오세요.” 하는 말에 그냥 “예” 하고 대답했던 것인데 택시기사가 그 점을 새삼스럽게 일깨워준 것이었죠. 그런 영향으로 군 대위로 복무하던 시절에는 하급자들에게 반말이 나오지 않아 애를 먹기도 했습니다. 배려는 생활 속에서 여러 가지 형태로 나타날 수 있어요. 제가 생각하는 배려의 모습은 이렇게 부모님께 배운 것들이죠.

저는 어릴 적부터 기계나 전자 부품 만지는 것을 무척 좋아했어요. 적성만 생각하면 공대에 가는 것도 괜찮았을 것입니다. 그러나 고등학교 때 제 스스로 의과 대학에 가기로 결심했습니다. 부모님이 내게 부담을 주지 않기 위해서 말씀은 안 하시지만 의대 진학을 바라신다는 것을 짐작하고 있었어요. 부모님께서 내게 얼마나 많은 것을 무조건적으로 베풀어주셨는지를 생각하면서 그런 결정을 내렸던 것입니다.

- 인생에서 돈이란 무엇입니까?

정보보안 분야는 특히 사명감과 책임감을 가지고 철학적으로 무장하지 않고 단순히 돈벌이로만 접근하면 사회악이 될 수도 있습니다. 보안 문제는 누가 책임지고 대응할 수 있는지, 그런 조직이 있는지가 근본적인 질문이 돼야 합니다. 지난 1999년 CIH 바이러스 사태, 2003년 인터넷 대란, 2009년 디도스 공격 때 안철수연구소가 자체 인력을 투입해 혼란을 막은 바 있죠. 외국에서 엔진만 갖고 와서, 또는 돈벌이만 생각하고는 그 같은 일을 제대로 할 수는 없을 것입니다.

대학시절 MT 갔을 때 찍은 단체 사진

- 젊은 날, 가장 힘들었던 경험은 무엇입니까?

의대 본과 일 학년 과정이 끝난 겨울 방학 때에 저는 부산에 내려가서 하고 싶은 일들을 하며 실컷 놀았습니다. 정처없이 기차를 타고 낙동강 변의 아무 역에나 내려 낚시를 하기도 하고 바둑 책이나 영화를 보면서 휴식을 취했습니다.

부산에서 길지 않은 겨울 방학을 보내고 서울에 올라가야 하던 참이었습니다. 그때 갑자기 지긋지긋하다는 생각이 들었어요. 그동안 잘 참고 있었는데 불쑥 그런 감정이 치솟아 오른 것이죠. 도저히 서울로 갈 마음이 나질 않았습니다.

의대생들에게는 성적이 평생 지고 다닐 멍에가 됩니다. 레지던트 시험에도 학부 때의 성적이 그 중요한 지표가 돼죠. 반에서 어느 정도 이상은 되어야 자기가 원하는 과를 갈 수 있게 돼 있습니다. 대학 입시를 앞둔 수험생과도 같은 처지인 것이죠.

말하기로는 십등 안에는 들어야 자기 원하는 과를 선택할 수 있다고들 했어요. 그 등수 안에 들기 위해서 비인간적인 생활을 계속해야 한다는 것이 싫었죠. 그러나 한편으로는 그 성적을 따야 했기에 걱정이 되어 겨울 방학 끝나기 일주일 전에 서울로 올라왔습니다. 미리 가서 공부를 해야겠다고 생각했기 때문입니다.

그런데 하숙을 하던 방에 발을 디딘 순간 혼자가 된 기분이었습니다. 방에 오도카니 앉아 있는데 늪에 빠지는 듯한 두려움이 엄습해 왔습니다. 제 주위에는 친구도 없어서 고민을 털어놓고 말할 사람도 없었어요. 더구나 부모님들은 멀리 계셨으므로 내가 어떤 생활을 하는지도 모르실 것이라 생각하니 마음이 더 답답해져 왔습니다. ‘성적이 잘 나온 걸 보고 서울 생활에 잘 견디고 있는 줄로만 아시겠지.’ 그렇게 생각하니 부모와 자식 간에 공유할 수 있는 부분에는 한계가 있다는 것을 처음으로 실감할 수 있었어요.

아마도 그때가 내 평생 가장 어려운 시기였던 것 같습니다. 마음은 점점 정처를 모르고 떠돌아 다녔어요. 방황이란 말이 처음으로 실감되었는데 한번도 겪어보지 못한 느낌이라 어떻게 처리해야 좋을지 난감하기만 했습니다. 그때 든 솔직한 심정으로는 학교에 다니기 싫었습니다. 어쩔 줄 몰라 쩔쩔 매다가 어머니께 장거리 전화를 드렸습니다. 저는 울면서 말했어요. “어머니, 공부가 너무 힘이 듭니다.”

깜짝 놀라신 어머니께서는 곧바로 비행기를 타고 올라오셨습니다. 그날로 어머니와 함께 기차를 타고 부산으로 내려가셨어요. 기차를 타고 가는 중에도 저는 계속 울었습니다. 어머니께서 걱정하지 말라고 달래주셨지만 무슨 이야기를 하더라도 눈물부터 먼저 나왔어요.

아버지께서는 걱정스런 마음에 저를 잘 아는 정신과 의사한테 보내셨어요. 그 의사 선생님께 제 이야기를 털어놓았죠. 그러나 결국은 제가 해결해야 할 문제였습니다. 그 선생님의 이야기는 나의 고민과는 거리가 있는 조언이었죠.

선생님은 의과대학 공부만 하다 보니 시야가 너무 좁아져서 그러는 것이니까 이제는 서클에도 들고 친구도 사귀고 놀러도 다니고 그래 보라고 하셨어요. 그러나 그 길은 바로 성적과 연결되어 있었습니다. 그렇게 하면 당연히 성적이 떨어지게 돼 있는데 어떻게 그 길을 택할 수 있겠어요?

부산에서 며칠을 보내고 마음을 달랜 나는 부모님의 걱정을 뒤로하며 서울에 올라왔습니다. 의과대학 생활을 계속하기 위해서는 나에 대한 스스로의 구속과 기대를 어느 정도 풀 수 밖에는 없었던 것입니다.

의대생 시절 봉사활동을 간 안철수 교수

- 첫사랑이란?

의과대학 생활에 잘 적응하기 위해서 들어갔던 서클에서 내 인생을 바꾸는 사건이 생겼습니다. 들어간 지 일년쯤 되어 지금의 아내가 된 한 여학생을 만났던 것이죠.

의과대학생들은 흔히 본과 이 학년 때 서클엘 많이 들어가게 됩니다. 본과 일 학년 올라갈 때는 전투를 치르는 심정으로 또는 수도자처럼 모든 속세와의 인연을 끊는 결심이라도 하지 않으면 안돼요. 그렇게 긴장하며 살다가 일 년쯤 시간이 흐르면 대개는 그 생활에 적응하게 됩니다. 거기서 적응하지 못한다는 것은 자포자기나 낙오를 의미하구요. 그런데 이상한 것은 흔히 성적이 나쁜 사람보다 좋은 사람이 더 깊은 고민에 빠진다는 것입니다. 심하면 휴학을 하는 사람도 있습니다. 중상 정도의 성적을 거둔 학생들이 더 잘하고는 싶은데 몸은 따라가지 않아서 괴로워하는 경우가 많은 것이죠.

그 여학생도 그런 적응 기간이 끝나갈 무렵인 본과 이 학년 올라갈 때 서클에 들어왔습니다. 카톨릭 신자였으므로 자연스럽게 그 서클엘 들어오게 된 모양이었습니다. 나는 그 여학생보다 한 학년이 높아서 삼 학년이 되었을 때였어요.

아내에겐 이미 고백한 이야기지만 이상하게도 처음부터 그 여학생에게 마음이 끌렸습니다. 그래서 깊은 관심을 가지고 지켜보기로 했습니다. 그런데 나중에 들어보니 그 여학생도 나에게 마음이 끌렸다고 하더군요.

진료 서클이었으므로 그 활동 내용을 놓고 우리끼리 세미나를 자주 열었습니다. 예를 들어 고혈압 환자가 있다고 치고 그 환자를 어떻게 진단하고 처치할 것인가에 대해 미리 공부해 두는 것이죠. 그런 세미나가 있을 때마다 가만히 살펴보면 그 여학생은 무척 열심히 경청하고 있었습니다.

어느 여름 진료를 가기 얼마 전의 일이었습니다. 도서관에서 공부를 하다 나와서 커피를 뽑아들고 혼자서 한잔 하려는데 저만치에 그 여학생이 보였습니다. 친구들과 따로 떨어져 혼자 앉아 있는 모습을 보고 다가가서 말을 걸었어요. 가만히 보면 그 여학생은 늘 혼자인 것 같았습니다. 그래서 유난히 내 눈길을 더 끌었는지도 모르겠네요. 내성적인 성격이라면 누구 못지 않은 나였지만 본과 이 학년 올라가서부터는 노선을 바꿔서 남들하고 많이 어울려 다니려고 노력하던 중이었으므로 그 여학생은 아마도 나의 본성을 눈치채지 못하고 있는 것 같았어요. 그때 나를 본 사람들은 내가 무척 활동적인 사람인 줄 알았을 거에요. 그러나 혼자 있기 좋아하는 제 본성이 어디가겠어요. 우리 두 사람은 척 보기에도 무척 닮은꼴이었어요.

같은 서클 후배였으므로 부담없이 다가가서 말을 걸었습니다. 말을 하다 보니 살아온 과정이나 좋아하는 것들이 너무도 비슷했어요. 공부하다 잠깐 쉬러 나왔던 것이 그냥 세 시간 동안 정신없이 이야기를 주고받게 되고 말았어요. 도서관 앞 그 자리에 그대로 앉아서. 더구나 우리는 일 초가 아쉬운 의과대학생들이었는데도 말이죠. 하는 수 없이 다음 날을 기약했습니다. 그 뒤로도 거의 매일마다 만나서 이야기를 나눴습니다. 무슨 이야기가 그리 많던지 만나면 이야기가 끊어질 줄을 몰랐어요. 그 누구에게도 털어놓지 않았던 이야기들이 산더미처럼 쌓여 있었던 것이 사실이었죠. 그러다가 그 여학생과 친해지게 되었습니다. 내 눈에는 남자도 들어오기 힘든 서울 의대에 여자가 들어와서 배겨내는 것이 장하게만 보였어요.

알고 나서 봐도 두 사람은 무척 닮은꼴이었습니다. 의과대학 다니면서 추리소설을 즐겨 읽는 것부터 시작해서 혼자서 책읽기를 좋아하며 자란 것이 우선 비슷했습니다.

두 사람의 가치관이 비슷해서였을까 우리는 서로에게 참 편한 데이트 상대가 될 수 있었습니다. 의과대학생들은 일상 대화에도 의학용어가 섞인 말을 많이 하게 됩니다. 그래서 고등학교 동기들과 만나 이야기할 때 내 말을 잘 못 알아듣는 수가 생기기도 했습니다. 나도 모르게 그런 말들이 불쑥 나왔기 때문이죠. 그래서 컴퓨터 쪽 사람들을 만날 때는 의도적으로 의학용어를 쓰지 않도록 스스로 조심하고 있어요. 그러나 그 여학생을 만나서는 공통 화제도 많은 데다 서로 사용하는 의학용어를 잘 이해할 수 있어서 아주 편했어요. 가족들 중에 누가 아프기라도 하면 어렵게 설명할 필요없이 말이 척척 통하곤 했죠.

의과대학교 삼 학년때는 학기제가 아닌 학년제로 학점을 주기 때문에 일년 걸 몰아서 두 달 동안 시험을 다 봅니다. 장거리 경주라서 시험 하나 끝나도 쉴 틈이 없이 곧바로 다른 과목 공부를 해야 하므로 정말로 인간의 한계를 경험할 수 있는 드문 기회라고 할 수 있어요. 저야 그 고비를 어떻게든 넘겼지만 그 여학생이 겪을 때에는 너무 안타까워 보였습니다. 그뿐 아니라 힘들게 레지던트 생활을 해나가는 것을 보고도 크게 도와줄 수 없어 미안했죠. 레지던트 때에는 이미 우리가 혼인을 하고 아이까지 있었던 때라 아내에게는 무리가 될 수밖에 없었어요.

그러나 그 지독한 과정을 무사히 다 끝내고 나서 사회 생활을 시작한 아내는 아주 사람이 달라 보였습니다. 제가 학교 생활에 잘 견디는 체질인데 반해 아내는 사회 생활 체질이었다. 늠름하게 직장을 다니며 어느 자리에서건 꼭 필요한 사람이 되어 있는 아내를 보면서 저는 자랑스럽기도 하고 뜻밖이라 놀라기도 했습니다. 부모님의 보호 속에서만 자라서 그런지 공부밖에 할 줄 몰랐던 저는 특히 대인 관계에서는 아내에게 배워야 할 점이 많습니다.

- 타임머신이 있다면, 과거로 돌아가 가장 바꾸고 싶은 순간은 언제입니까?

후회는 하지 않는 편입니다. 아주 어릴 적부터 아버님을 바라보면서 나도 나이가 들면 아버님처럼 백발이 성성하고 흰 가운을 입은 의사가 될 것이라고 굳게 믿었습니다. 그러나 최선을 다해서 살다보니 오히려 의사를 그만두어야 하는 상황이 오게 되었습니다. 그때부터 매순간 최선을 다해서 열심히 산다면 그 이후에 할 일이 정해진다는 신념으로 살게 되었습니다.

책장을 배경으로 책을 들고

- 자신의 인생에 큰 영향을 미친 스승이 있다면 누구입니까?

‘우리는 우리가 읽은 것으로 만들어진다’는 독일의 유명한 문호 마틴 발저의 말처럼, 책은 우리 인간이 ‘어떤’ 것을 이루고 ‘무엇’인가가 되는 데 가장 유익한 길잡이라고 생각합니다. 존경하는 사람도 마찬가지입니다. 몇 사람에 한정되지 않고 다양한 관점에서 존경할 만한 사람이 많습니다. CEO로서 롤 모델 중 한 분은 인텔사의 전 CEO였던 앤디 그로브였습니다.

또한 교수로서 롤 모델 중 한 분은 펜실베이니아대 와튼스쿨의 랜 로디쉬 교수입니다. 그는 현업에서 학생들의 창업을 도와준 케이스가 몇 백 건이나 될 정도며, 마케팅 분야에서 학문적으로도 유명한 분이죠. 학생들이 제시하는 사업계획이 마음에 들면 그 자리에서 도전해보라며 격려하고 창업자금을 직접 투자하기도 하는 등 많은 사람의 귀감이 되고 있습니다.

- 내 인생에 영향을 준 책 또는 젊은이들에게 추천하고 싶은 책이 있다면.

일본인 수학자 히로나카 헤이스케가 쓴 <학문의 즐거움>이란 책의 한 구절을 생활 신조로 삼고 있습니다. 그는 수학의 노벨상이라고 불리는 필즈 상을 받은 바 있는 저명한 학자입니다. 그 책을 보면 한 평범한 사람이 노력을 거듭한 끝에 원래 천재였던 사람보다 더 빛나는 업적을 남길 수 있었던 이야기를 읽을 수 있어요. 그 책은 제 정신에 큰 반향을 불러 일으켰습니다.

그 책의 내용에 ‘어떤 문제에 부딪히면 나는 미리 남보다 시간을 두세 곱절 더 투자할 각오를 한다. 그것이야말로 평범한 두뇌를 지닌 내가 할 수 있는 유일한 방법이다.’라는 구절을 읽었을 때에는 저의 갈 길을 한 줄기 빛이 인도하는 듯한 감동을 받았습니다. 그후 남보다 더 노력하고자 했습니다. 항상 노력하고 남에게 도움이 되는 삶은 아름답다고 생각합니다.

한 가지 유의할 것은 과거에는 한 사람의 천재가 다양한 일을 할 수 있었지만, 이제는 그렇지 않다는 점입니다. 다른 분야에 대한 상식과 포용력을 갖춰야 합니다. 자기 분야만 알고 다른 분야 사람과는 협조도 이해도 안 된다면 아무런 성과도 낼 수 없는 사람이죠.

안철수 연구소 사내 교육을 하던 당시의 모습

- 마지막으로, 어떻게 살면 후회하지 않는 삶을 살 수 있을지 젊은 세대에게 한 말씀 들려주십시오.

현대 사회는 10년 후를 내다볼 수 없을 정도로 급변하고 있습니다. 10년 전 인기 있었던 직업도 현재에는 다른 직업이 각광받고 있죠. 그렇기 때문에, 어린 시절에는 자신이 하고 싶은 일에 대한 목표를 세우고, 그 목표를 위해 열심히 노력하는 것이 중요합니다.

자기 나름대로 방향을 잡는 데 도움이 될 만한 조언 여섯 가지를 소개하고자 합니다.

첫째는 ‘자신에게는 엄하고 다른 사람에게는 관대하라’는 것입니다.
이것은 말처럼 쉬운 일이 아닙니다. 사실 자신에게는 관대하고 다른 사람들에게는 엄하기 쉬운 것이 인지상정이지 않겠어요? 그렇지만 어떻게 보면 그런 태도가 많은 사람들이 발전 없이 제자리에만 머무르게 하는 이유가 아닐까 생각합니다.

둘째는 ‘다른 사람과 비교하면서 살지 말라’는 것입니다.
특히 다른 사람의 내적인 능력과의 비교가 아닌, 외적인 모습만의 비교는 삶을 불행하게 할 뿐입니다. 세상에는 잘난 사람이 많죠. 말 잘 하는 사람, 재산이 많은 사람, 그리고 지위가 높은 사람, 이렇게 외적으로 보이는 모습들은 일종의 결과로 나타나는 것이라고 생각합니다.

다른 사람의 내적인 능력과 비교하는 것은 자신의 발전에 자극이 될 수도 있지만, 결과로 나타나는 외적인 부분들만 가지고 비교를 한다면 여러 가지 부작용이 생길 수 있습니다. 특히 멀리 있는 사람이 아니라 같이 일하는 주변 사람들의 외적인 모습과 비교하는 것은 불행한 삶을 초래할 수 있습니다.

셋째는 ‘매사에 긍정적으로 생각하면서 살라’입니다.
긍정적인 시각으로 사물과 현상을 해석하는 사람들은 스스로가 즐거울 뿐만 아니라 주변까지 밝게 만듭니다. 반면에 부정적이고 방어적인 사람들은 다른 사람이나 주변 상황에 대해서 불평하고 절망하면서 주위 사람들을 긴장시키고 조직 전체에 나쁜 영향을 미칩니다.

외부적인 환경이 나쁘다고 해서 그 환경을 탓하고 불평하는 것만으로는 상황을 바꿀 수도 없을 뿐더러 자신에게도 도움이 되지 않습니다. 극복하려는 노력도 하지 않고 그렇다고 주어진 일에도 최선을 다하지 않다보면, 결국 자기 인생만 낭비하는 결과를 초래할 뿐이죠. 따라서 부정적이고 방어적으로 살기보다는 자기 자신을 바꾸거나 환경을 바꾸도록 노력하는 것이 중요하며, 그러한 삶이 가치 있는 삶입니다.

넷째는 ‘매순간을 열심히 살아라’는 것입니다.
우리는 살아가면서 여러 가지 많은 어려움을 겪습니다. 매 순간 어려움에 닥쳤을 때, 쉽게 포기하기보다는 바로 지금이, 내 한계를 시험하는 순간이라는 마음으로 노력하는 것이 중요해요. 쉽게 포기해버린다면 바로 거기가 자신의 인생에서 평생 다시는 넘지 못할 한계가 되는 것이죠. 매 순간이 자신의 한계를 만들어가는 때라는 것을 명심하고, 스스로의 한계를 높이기 위해서 노력해야 합니다.

다섯째, ‘미래의 계획을 세우라’는 것입니다. 자신의 30대, 40대, 50대, 60대의 모습을 스스로 그려보세요.
‘계획 없는 삶은 꿈이 없는 삶이고, 꿈이 없는 삶은 불행한 삶이다’는 말이 있습니다. 꿈이라는 것은 꿈 그 자체에 의미가 있는 것이라고 생각합니다. 어떠한 꿈이 이루어질 수 있느냐 없느냐가 중요한 것이 아니라, 인생에 방향성을 제시함으로써 활력을 주고 발전적으로 살아가게 하는 것이 꿈이 가지는 의미에요. 그리고 만약 노력 끝에 현실로 이루어질 수 있다면 더욱 좋은 게 아니겠습니까.

여섯째는 ‘각자 자신에게 맞는 삶의 철학, 즉 원칙을 가져라’는 것입니다.
원칙을 정하는 것이 엄청난 일이라고 생각할 필요는 없습니다. 지금까지 살아온 삶을 되돌아보고 그 삶 속에서, 행동에서 일관성을 찾으면 그것이 바로 자기 나름대로의 삶의 원칙이 되는 것입니다. 중요한 것은 그 일관성을 인식하는 것이죠. 스스로 인식함으로써 자기 자신의 무게중심이 설 수 있기 때문입니다.

그렇지만 처음부터 완벽한 원칙을 세워야 한다는 강박관념에 사로잡힐 필요는 없습니다. 실천해 나가면서 수정하고 보강해나가면 되기 때문이죠. 반면에 그런 원칙조차 없다면 삶을 살아가는 동안 흔들리고 우왕좌왕하다가 좌절하는 경우가 생길 수 있습니다. 보통 종교를 가진 사람들이 시련을 이겨내는 힘이 크다고 하는데 그 이유는 종교에는 나름대로의 가이드라인, 원칙이 있기 때문일 것입니다.

스스로 자신의 인생을 경영하는 CEO로서 인생의 원칙을 하나하나 정립하고 만들어간다면 그 삶은 의미 있는 삶이 될 겁니다. 그리고 그러한 원칙을 가지고 스스로 자기 인생의 주인으로 살아가는 사람들은 힘들 수는 있더라도 결코 불행하지는 않을 것입니다.

김정윤/인터넷 경향신문 대학생 기자 (웹場 baram.khan.co.kr)
경향신문 ‘오늘의 핫뉴스’

프로그래머 경력 3년차, 이제 어디로 갈까? PC/개발 2003/11/13 02:36

프로그래머 경력 3년차, 이제 어디로 갈까?

35세 정년 과감하게 뛰어 넘는 경력 관리 해법 찾기

지금 다니는 직장에 몇 개월째 근무하고 있는가? IT 종사자들의 근무 주기가 점점 짧아지고 개발자들도 한 분야만 알아서는 경력 관리를 하기가 힘들어졌다. 평생 직장 개념은 이미 사라진지 오래. 프로그래머라는 직업을 갖고 언제까지 일할 수 있을지 자문해 보자. 프로그래머 정년이 35세라는 말이 공공연히 나돌면서 이제는 자신의 경력을 꼼꼼하게 관리해야 할 때가 왔다. 목표를 확실히 세우고 50세가 되어 있을 자신을 그려 보자.

중소 IT 업체에 근무하는 A씨는 요즘 아침에 출근해 컴퓨터를 켜면 암호로 잠궈 둔 이력서를 연다. 자신의 경력기술서를 주욱 보다가 한숨짓는 K씨. 프로그래밍이 좋아 IT 업계로 뛰어든지 어언 3년째, 회사에선 주임으로 승진도 했고 자리도 잡았다. 그동안 갖가지 프로젝트에 밀려 일주일에 서너 번은 밤을 새고 까다로운 클라이언트사의 비위도 맞춰 가면서 프로그래머 경력을 쌓아 왔지만 요즘은 왠지 모르게 자괴감이 밀려 온다.
프로그래머 정년 35세라는 주변의 이야기들을 차치하고서라도 지금하고 있는 업무를 언제까지 할 수 있을지 의문이기 때문이다. 실력이 뛰어난 후배들은 계속 밀려들어 오고 학교다닐 때처럼 계속 공부를 한다는 것도 심적으로 부담이다. K씨는 회사를 계속 다니고는 있지만 앞으로 어떻게 경력을 관리해야 할지 심각하게 고민 중이다.

프로그래머는 왜 이직율이 높을까?

취업 사이트인 인쿠르트의 통계에 따르면 IT 종사자의 이직 주기는 상당히 짧은 것으로 나타났다. 인크루트( www.incruit.com)가 1,982명의 IT 재직자를 대상으로 이직 동향에 대해 설문 조사를 실시한 결과 1~2년마다 회사를 옮기는 종사자가 38.4퍼센트(761명)에 달했다. 5년 이상 주기로 회사를 옮기는 종사자는 4.7퍼센트(94명)에 불과한 것으로 나타났다. 이직시 10~20퍼센트의 연봉을 올려 받는 것으로 드러났다.
‘2~3년마다 이직한다’는 대답은 31.4퍼센트, 3~5년 단위로 이직하는 경우는 13.6퍼센트, 1년 이하 주기로 이직하는 경우는 11.9퍼센트 등이었다. 전체 이직 주기로 보면, 1~3년마다 이직하는 비율이 전체의 69.8퍼센트에 달해 대다수 IT 종사자들이 1~3년 내에 다른 직장으로 옮기는 것으로 조사됐다. 이직 사유로는, ‘회사의 비전이 없기 때문’이라고 답한 응답자가 33.5퍼센트(664명)로 가장 많았고, 그 뒤를 이어 ‘자기 계발을 위해 이직한다’가 33.1퍼센트(655명)에 달해 직장 생활에서 회사 비전과 개인의 발전 가능성을 가장 중시하는 것으로 드러났다.

그렇다면 프로그래머들은 왜 이직을 자주 하는 것일까? 물론 고용 불안에서 오는 구직자들의 자발적 이직도 있지만 거꾸로 이야기하면 그만큼 기회가 많기 때문이라고 해석할 수도 있다.
잡서치코리아의 이기대 사장은 국내 2~3년차 프로그래머들의 문제점을 IT 산업 계층 구조에서 기인한다고 설명한다. 그는 “국내 IT 업체들은 산업 자체가 영세한데다 SI 업체가 많아야 프로그래머가 대접을 받는데 SM(시스템 운영) 업체들이 대부분이다. IT업체들이 2차, 3차로 하청을 주는데 이 하청 업체에 2~3년차 프로그래머들이 몰려 있다. 따라서 업무 환경도 열악하고 자기 개발할 여유도 없이 경력을 쌓게 된다. 노가다성 코딩 작업만 하다보니 자신의 능력을 업그레이드할 기회가 없어 슬럼프에 빠진다”고 말한다.

프로그래머 10년, 관리자 10년
국내 IT 환경에서 개발자들이 전산 업무를 10년 정도 하면 관리자로 승진하고 더 이상 개발자로 일하지 않는다. 이는 본인의 선택적인 측면이 많지만 장유유서(長幼有序)로 대변되는 사회분위기와 무관하지 않다. 또 30대 중반이 되면 아이들이 커가고 밤새고 일하는 것이 즐겁지 않다. 관리하고 싶은 마음이 생기는 것이다. 여기에서 프로그래머 ‘35세 정년’이라는 말이 나오기 시작한다.

개발자로서 수명이 다한 인력들은 다른 분야로 전직하거나 개발자들을 관리하는 매니저로 승진하는 것이 통상적인 국내 프로그래머들의 경력 지도이다. 일부 IT 컨설턴트라고 하는 개발자와 관리자의 중간 단계의 직종으로 자리를 옮기는 경우도 있지만 문과 출신이면서 IT 기업 근무 경력이 있고 경영학 석사 등 각종 학위로 무장한 이들에 밀려 빛을 보지 못하는 경우가 많다. 사정이 이렇다보니 서른만 넘겨도 의욕을 상실하는 프로그래머들도 생겨난다. 그렇다면 경력 관리는 언제, 어떻게 시작해야하는 것일까. 헤드헌팅 포털 HP존에 따르면 헤드헌터들은 이직 희망자들의 가장 큰 문제점을 경력 관리 미흡과 조직 생활 부적응을 꼽았다.

전문가들은 초보 개발자 시절부터 자신의 목표를 명확히 해야한다고 말한다. 삼성멀티캠퍼스 교육사업팀 오형석 과장은 “자신이 제너럴리스트로 성장할 것인지 스페셜리스트로 성장할 것인지에 대해서는 확실한 주관이 있어야 한다”고 말한다. 경력 관리에 기술적인 접근이 필요하다는 것.

계속 프로그래밍을 할 것인지, 개발 지식을 토대로 기술 영업을 할 것인지, 프로젝트 매니저가 될 것인지 2~3년차에 결정해야 한다는 인크루트 김현정 IT 담당 부장은 “취업 시장에서는 프로그래머의 수명은 약 20년이다. 이 중 순수하게 프로그래밍(코딩) 업무만으로 파악하면 약 10년 정도이다. 이는 다른 산업군에 비하면 상당히 길다. 프로그래밍 분야 즉, 코딩 작업을 할 수 있는 기간이 10년이라는 이유는 IT 트렌드가 끊임없이 바뀌고 있고 개발 언어 또한 계속 교체되기 때문”이라고 쐐기를 박는다. 그러나 이 기간 동안 프로그래머 업무에 충실하고 경력 관리를 제대로 하면 길을 얼마든지 있다.

변화에 알맞는 경력 지도 그려야
올해 31세인 5년차 프로그래머 장윤기씨의 경우 현재 네 번째 직장에 다니고 있다. 이 중 1년씩 일한 직장이 2곳, 3년 동안 일한 업체를 거처 포스데이타라는 SI 업체에 안착했다. 그는 중소 IT 업체에서 경력을 쌓고 대기업으로 경력을 업그레이드 했다. 올해 30세인 권영민 시큐어소프트 과장의 경우 병역특례 경력을 합하면 프로그래머 경력만 7년째다. 비주얼 C에서 자바로 업그레이드하고 프로그래머로써 경력을 쌓다가 경력이 10년쯤되면 독자적인 프로젝트 매니저로 승부를 낼 생각이다.

프로그래머의 일반적인 경력 지도는 약 10여 년의 프로그래머 생활을 거친 후 기술 영업을 하거나 전산실 매니저가 되거나 프로젝트 매니저로 성장하는 방안을 들 수 있다. 기술적인 백그라운드가 있고 전문성이 있기 때문에 가능하다.

이 중 프로그래머 실력을 기반으로 성장하고 싶은 개발자들은 프로젝트 매니저에 관심을 가져보자. 급변하는 IT 트렌드를 봤을 때 개발자가 2~3가지 프로그래밍 언어까지는 학습이 가능하지만 그 이상은 어려운 것이 현실이다. 메인프레임을 사용하던 개발자가 C/S 환경에서 웹으로 전환하기가 사실상 힘들기 때문이다.

프로젝트 매니저는 프로젝트 일정을 관리하고 전산 자원을 배분하여 프로젝트를 효율적으로 이끄는 역할을 하는 핵심 인력이다. 자신이 수행한 프로젝트로 경력을 인정받는 프로그래머는 금융이나 통신과 같은 산업 분야 별로 경력을 쌓거나 원가, 회계, 재무와 같은 직무별 커리어를 쌓는 것이 경력 관리에 도움이 된다.

분야별 전문 지식을 토대로 관리 능력을 쌓아가는 것이 프로그래머 경력을 극대화시키는 방법 중 하나이다. 국내의 경우 ‘관리자=People Management’로 인식되는 경향이 있으나 점차 바뀌어가고 있다. 이는 우리나라 전산인들이 프로젝트 관리를 제대로 하지 않는다는 반성에서 비롯된다. 잡서치코리아 이기대 사장은 “프로그래머로 경력을 쌓고 관리자가 되면 피플 관리가 아닌 프로젝트 관리로 포지셔닝을 해야 한다. 건별 계약이든 기업의 전산 관리자로 있든 경력이 어느 정도 쌓이면 PM(Project Manager)역할을 할 수 있어야 하는데 국내에는 이러한 인력이 턱없이 부족하다. SI 인력도 적을 뿐더러 프로젝트 관리 능력이 떨어져 결과적으로 IT 결과물의 퍼포먼스가 떨어진다”고 말한다.

실제로 30대 중반의 프로젝트 매니저를 헤드헌팅업체에서 많이 찾는데 국내에서 찾기 힘들다는 것이 전문가들의 견해이다. 전반적인 기술이나 프로젝트에 대한 관리 능력을 갖춘 전문가가 시급하다는 것. 프로그래머는 많아도 관리자는 드문 것이 국내 전산 환경의 현 주소이다.

경력을 쌓아 교육 분야로 진출하는 것도 바람직하다. IT 교육 전문가가 턱없이 부족하기 때문이다. 대학이나 기업에서도 IT 분야를 가르칠 사람이 없어 애를 먹고 있다.

얼마 전 한 중견 IT 업체는 최근 호주 소프트웨어 회사의 수석 엔지니어를 초빙해 3일간 프로그램 교육을 실시했다. 강사료는 1,000만 원. 국내에서는 이같은 인력을 찾을 수 없었다는 업체 측의 전언이다. 노동연구원 조사 결과에서도 고급 인력이 절대적으로 부족한 직종 1위는 IT 교육 전문가이다. 지난해 보고서에 따르면 대학과 학원, 직업 훈련 기관의 부족한 IT 교원은 1,374명이었다. 1년차 개발자 100명 중 5년이 지나고 남는 개발자가 15명밖에 안된다는 말이 이를 반증해 준다.

조직 내 커뮤니케이션·리포팅 능력 중요
일반적으로 프로그래머의 특성을 살펴 보면 외곬수에 커뮤니케이션 능력이 약하다는 평가를 내리는 사람들이 많다. 한 대기업의 마케팅 부서 이사는 “자신의 의사를 적절히 표현하지 못하는 프로그래머들이 많다. 회의 시간에 한 마디도 못하거나 요점없는 이야기로 시간을 낭비하고 대답을 못하거나 의견을 제시하면 무조건 할 수 없다고 말하는 개발자들이 많아 현업에서 불만”이라고 이야기한다. 어려운 프로그래밍 서적만 보다보니 커뮤니케이션 능력이 상대적으로 떨어진다는 것.

인크루트 김현정 부장은 “프로그래머들은 업무 성향이 오기와 비슷한 독특한 특성이 있다. 커뮤니케이션 활동이 폐쇄적인 데다 오픈마인드를 갖고 있지 않다”고 평가한다. “IT 조직은 서비스 조직이라는 생각을 갖고 있어야 한다. 지원 조직이고 현업을 서비스하는 조직이라는 마인드를 갖고 있어야 한다. 프로그래머가 현업과의 커뮤니케이션에서 융통성을 발휘하고 서포팅을 잘하면 인정받기도 쉽다”고 조언한다. 그러나 프로그래머들이 현업을 이해가기가 만만치 않은 것이 현실이라고 말한다.

실제로 프로그래머들 중 상당수는 상사와의 갈등이나 동료와의 불협화음으로 이직을 하려는 개발자도 많다. 소규모 IT 기업에서 근무하던 개발자 B씨는 회사가 급성장 하면서 조직이 확대되어 개발 인력이 수십 명으로 불어났으나 이에 적응하지 못하고 실직한 경우다. 이전의 가족같은 분위기가 사라진 데다 새로 영입된 팀장의 업무 스타일에 적응하지 못한 것. 조직 내 커뮤니케이션이 프로그래머에게 큰 문제로 나타난다는 것이 전문가들의 의견이다. 이기대 사장은 “커뮤니케이션을 잘하는 가장 손쉬운 방법은 상대방이 하는 말을 주의 깊게 듣고 있다가 그 방식으로 그대로 설명하는 것”이라고 조언한다.

프로그래머들에게 또 하나의 벽은 글쓰기와 프리젠테이션 능력이다. 자신의 생각을 표현해 내는 과정에서 타 부서인들의 이해를 구하려는 노력이 필요하다는 것. 권영민 시큐어소프트 과장은 “개발자들이 스케줄 관리와 다큐멘테이션에 약하다. 프리젠테이션 능력과 글쓰기 노력을 병행해야 한다. 자신이 가진 기술만큼 중요한 것이 생각을 표현해 내는 능력”이라고 말한다.

장기계획 세우고 목표 확실히 설정
초보 개발자 시절부터 장래에 대한 계획을 확실히 세우고 꾸준히 계단을 올라 가면 더할 나위 없겠지만 안타깝게도 경력 관리에 대해 여유를 갖게 되는 것은 시간이 한참 흐른 후이다. 이번 기회에 다시금 자신을 되돌아보는 계기를 만들어 보자.

여러 가지 이유 때문에 실직했다면 공백을 최우선으로 줄이는 것이 경력 관리에 흠을 없애는 방법이다. 무엇보다 공백 기간이 6개월 이상 장기화되지 않도록 노력해야 한다. 프로그래머에게 있어 반년 이상의 공백은 일을 안한다는 의미가 아니라 직무 능력이 떨어짐을 의미하기 때문이다. 따라서 실업이 장기화될 가능성이 있을 때는 차라리 직장 눈높이를 낮춰서라도 재직 상태를 유지하는 것이 좋다. 불가피하게 공백기를 가졌다면 업무의 연속성을 가져야 한다. 아르바이트를 하거나 커뮤니티 활동, 연구, 단기 프로젝트 활동을 할 수 있도록 노력해야 한다.

특히 유의할 점은 일을 놓고 싶더라도 목표없이 그만 둬서는 안된다. 업무를 진행하면서 주기적으로 휴식을 취할 수 있는 공간을 만들어야 한다. 또, 취업 정보를 꾸준히 받을 수 있는 상황인지 살펴 봐야 한다. 퇴직 준비를 하면서 정보 검색을 하지 않았다면 반성해야 한다. 프로젝트 매니저로서 대우를 받을 수 있는 경력은 5년차 이상일 때 옮기는 것이 좋다. 프로젝트 경험 많은 7년차가 가장 좋다.

슬럼프에 빠졌다면 보직이나 근무지를 바꿔 같은 일이라도 새로운 환경에서 일하도록 하는 것이 좋다. 업무와 관련된 교육 기회를 찾아 그간의 관점을 바꿀 수 있는 신선한 주제를 제공하여 분위기를 전환하는 것도 좋은 방법이다.

<아이뉴스24>

[로스앤젤레스=이균성 특파원] 혁신의 대가(大家)라고 할 수 있는 스티브 잡스는 평소 이와 관련된 많은 말을 해왔다.

그의 어록을 분석해보면, 혁신은 기술과 세상에 대한 폭넓은 이해를 바탕으로 지속적으로 ‘변화’와 ‘다름’을 추구하는 행위라 할 수 있다.

또 스티브 잡스의 혁신 이론은 4단계 과정을 그 핵심으로 삼은 듯하다. 그가 직접 그렇게 말한 것은 아니지만 어록을 분석해보면 그렇게 봐도 무방하다.

1. 모방하고 훔쳐라

첫 번째 과정은 주변의 것을 배우고 학습하는 '모방' 혹은 '훔침'의 단계다.

그는 1996년 미국 방송 PBS 다큐멘터리에 출연해 “위대한 아이디어를 훔쳤다는 사실에 한 점 부끄러움이 없다”고 말했다. ‘뛰어난 예술가는 모방하고, 위대한 예술가는 훔친다’는 피카소의 유명한 격언을 인용한 것이다.

그는 결국 혁신과 창의성은 어디 특별한 데서 나오는 게 아니라 주위를 열심히 탐구하고 획득하는 데서 나온다고 본다.

그는 2000년 포춘과의 인터뷰에서 “창의성은 단순히 여러 가지 요소들을 연결하는 것을 말한다”며 “인간의 경험에 대해 폭넓게 이해할수록 더욱 훌륭한 디자인을 내놓을 수 있다”고 설명했다.

그러면서 “디자인이란 제품의 외관에서부터 포장 그리고 서비스라는 여러 단계를 통해 표현되는, 인간이 만들어낸 창조물의 근본적인 영혼”이라고 말했다.

2. 가진 것을 모두 합쳐라

두 번째로 강조되는 게 '통섭(統攝)' 과정이다.

통섭은 에드워드 오스본 윌슨(Edward Osborne Wilson)'의 책 'Consilience'를 국내 최재천 교수가 '통섭(統攝)'으로 번역한 뒤 노무현 정부 때 유행한 말인데 그 ‘통섭’의 실천자가 바로 잡스였던 것이다.

잡스는 지난 2일 아이패드2를 발표하면서 맺음말을 통해 다음과 같이 말했다.

“애플의 DNA는 '기술만으로는 (좋은 제품을 만들기에) 충분하지 않다'는 것이다. (그래서) 애플의 기술은 (사람들에 대한 이해를 풍부하게 해주는) 인문학과 결합했다.” 기술은 사람을 위해 복무해야한다는 게 그의 생각이고, 이게 제대로 되려면 인문학적 이해가 전제돼야 한다는 것이다.

잡스는 이 점에서 폴라로이드를 만든 발명가이자 물리학자, 에드윈 H. 랜드(Edwin H.Land) 박사를 사숙(私淑)했다고 할 수 있다.

잡스는 1999년 타임과의 인터뷰에서 “‘나는 폴라로이드가 예술과 과학의 교차점에 서길 바란다.’는 랜드 박사의 말을 단 한 번도 잊은 적이 없다”고 말했다. 그래서 기술과 인문학의 결합을 그토록 강조한 것이다.

3. 다르게 생각해라

이미 존재하는 모든 요소들을 ‘모방’하고 ‘훔침’으로써 세상에 대한 폭넓은 통섭을 바탕으로 변화의 길목에 미리 가려고 끊임없이 노력하는 게 세 번째다.

잡스는 2007년 맥월드 행사 때 이런 자신의 노력을 캐나다의 전설적인 아이스하키 영웅인 웨인 그레츠키(Wayne Gretzky)의 말을 인용해 대신했다. 그레츠키는 “나는 퍽(puck)이 있었던 곳이 아니라 퍽이 갈 곳으로 스케이트를 타고 간다.”라는 말로 잡스에게 영감을 줬다.

애플이 1984년 매킨토시를 만들어냄으로써 개인용 컴퓨터(PC) 시장에 일대 혁신을 가져온 게 이를 테면 퍽이 갈 방향이었으며, 2001년에 내놓은 아이팟과 아이튠스, 2007년에 내놓은 아이폰, 2010년에 내놓은 아이패드 등과 같은 제품 또한 퍽이 갈 길목에 미리 내놓은 제품이었던 것이다.

여기서 눈여겨 볼 건 이들 제품 모두 이미 존재했던 것들에 대한 ‘모방’과 ‘훔침’을 통해 세상에 대한 폭넓은 이해로 다시 변주됐다는 점이다.

3. 쉽게 단순화 해라

네 번 째 요소는 ‘단순화’라고 할 수 있다.

스티브 잡스는 ‘직감 혹은 직관(intuition)’이라는 말을 많이 썼다. 통섭이 난해해지면 일반인으로써는 별로 쓸 모가 없어진다. 기술과 인문학을 결합하되 그것을 가장 단순하게 표현해야 한다. 세상이 발전할수록 기술과 사람의 일은 복잡해지게 돼 있다. 이를 섞어서 통찰하면서도 직감적으로 해결할 수 있게 해주는 것이 중간에서 그 제품을 만들어내는 자의 사명이라는 게 스티브 잡스의 생각이다.

고등학교 시절부터 선(禪)에 심취했다는 스티브 잡스는 1998년 비즈니스위크와의 인터뷰에서 “단순함은 복잡함보다 어렵다. 생각을 깔끔하고 단순화하기 위해 많은 노력이 필요하다.”고 말했다.

자신의 상품을 엘리베이터가 올라가는 3분 안에 설명할 수 있어야 한다는 이른바 ‘엘리베이터 브리핑(Elevator briefing)’은 스티브 잡스에게는 단순한 마케팅 이론이 아니라 인간을 위한 상품을 만들어 파는 기업가의 철학으로 생각된다.

/로스앤젤레스(미국)=이균성 특파원 gslee@inews24.com>