화요일은 신나는 공학수학과 흥미진진한 회로이론 수업이 있는 날. 수요일은 행복으로 가득한 전자기학 수업이 있는 날. 목요일은 기쁨이 충만한 실험 시험을 보고 가벼운 마음으로 시스템 프로그래밍을 듣는 날. 금요일은 마음까지 환해지는 화학수업을 듣고 세심한 배려가 담긴 자료구조와 날아갈 것만 같은 회로이론 시험을 보는 날. 토요일과 다음주는 단 하나 남아 아쉬운 시험인 시스템프로그래밍을 공부하고 언제인지 몰라 설레는 공학수학 2차 시험과 전자기학 퀴즈를 준비하는 기간.
이 글은 당시의 일을 기록으로 남기느라 과거형으로 표현된 부분이 있을 수 있습니다. 다음 링크를 확인하세요. --- 모든 일의 시작이었다. 이 당시에는 앞으로 일어날 일을 전.혀. 예측하지 못 했었다. 지금은 똥 싸는 시간을 제외하고는 항상 붙어있고 뇌의 일부를 공유하고 표현해도 될 만큼이 된, 근범이와의 인연의 시작이기도 하다.
처음에는 EZ-X5 보드를 동아리 차원에서 지원받은 걸 어찌어찌 손을 댔었다. 첨부파일은 그 계획서.
토론의 분위기를 최대한 그대로 표현하고자 필기했던 내용을 그대로 올려놓습니다. 오고가는 내용이 잘 이해되지도 않는
상태에서 적은 메모라 내용이 횡설수설입니다. 약 2시간동안 활발한 토론이 오고갔었는데 중간에 이상한 내용이 있으면 태그를
붙여주시기 바랍니다. 기억나는 한도내에서 답변해드리겠습니다.
L : 초급개발자를 어느 정도의 수준까지 성장시키려면 각 단계를 설정한 다이어그램이 필요할 것이다. 다음과 같이 분류할 수 있을 것.
1
Coder
2
Programmer
코더+노하우
3
Developer
비즈니스를 정규화할 수 있고, 전산적으로 구성할 수 있는 능력이 있는 사람
4
Consultant
시장을 만들어나가는 사람
5
Manager
자신을 대체할 차세대 리더 육성/성장 로드맵을 제시할 수 있는 사람
한국에서는 보통 1~3단계까지를 개발자로 통칭한다. 그리고 3단계의 사람들을 Consultant라고 하기도 한다.
Y : 3~4 단계에 추가를 하자면, Modeler(아키텍터의 청사진으로 모델을 작성하는 사람)와 Architector(해당프로젝트의 철학(사상)을 이해하고 방향성을 제시할 수 있으며 청사진을 그려낼 수 있는 사라)이 들어갈 수 있겠다. 그렇게 될 때 Developer는 모델을 기반으로 코드를 작성하는 사람으로 볼 수 있다. 결국 위와 같은 분류방식은 역할에 따른 분류인데, 우리나라에서는 관리자직군이 따로 분류가 되고 있다.
개발자가 성장할 수 있는 밑바탕에는 성장할 수 있는 환경이 전제되어야 한다. 크게 나누자면 2가지 길, 즉, Technical분야와 Management분야로 나눌 수 있다. 자신이 최근 사회 각계층에 2가지 길의 분류 중요성을 알리고 있다. 그렇게 클 수 있는 사회적 환경이 만들어져야 한다. 그렇다면 그런 환경을 만들기 위해선 무엇을 해야 할 것인가.
우리나라에는 SI벤더는 많지만 Global Product를 만드는 회사는 적다. 이것이 해결되어야 2가지 분류환경을 만들어나갈 수 있는 것이다.
M : James Gosling 은 아직도 코드를 매일 작성하고 있고 경영도 하고 있다. Andy Herzfeld 는 맥킨토시 Interface를 19살 학생때 만들었지만 경영도 매우 즐긴다.
분야별로 한정지어 생각한다면 그것이야말로 스스로를 제약하는 것이다. SUN에는 CEO에 맞먹는 엔지니어 단계(Sun
Fellow)가 있다. 엔지니어를 통해서도 얼마든지 관리자 직급에 맞먹는 단계로 나아갈 수 있는 것이다. 코딩단계의 경우는
인도나 중국으로의 아웃소싱을 생각할 수도 잇는 것이다. 중국에서는 한국을 경쟁상대로 느끼기 때문에 추월당하지 않으려면 한국
고유의 Process에 대한 부가가치를 창출해야 한다. Programmer와 Developer의 단계는 한국이 유지를 해야
한다. 그러기 위해서는 개발자의 IDEA가 중요하다. 일에 있어서 자존심을 필요없는 것이다. 즐기는 자세가 있어야 낮은 단계의
직무도 거리낌없이 할 수 있는 것이다.
Y : 방금 M이 말한 시스템을 만들기 위해선 개발자의 노력도 필요하다. 글로벌 추세는 아웃소싱이다. 하지만 그 중에서도 아웃소싱을 할 수 없는 한국적인 분야가 있다. 그것은 외국 업체들에게는 진입장벽이고 우리에게는 보호벽이다.
개발자로서 자신만의 Domain(분야) 있는지 자문해 봐야 한다. 그러려면 Domain에 대한 이해가 필요하다. 바로 그 Domain에 대한 이해를 높일 수 있는 능력개발이 요구된다.
또한 사회적 이슈 발생에 기여하는, 달리 말하면 개발자의 문제를 이슈화하려는 노력이 부족하다. 그것은 개발자들이 Carrier Path의 중요성을 모른다는 것과 같다.
김창준 : 화이트보드에 도식화된 우리나라 개발자의 성장 단계를 보면, 우리의 소프트웨어 개발 방식과 유사하다. 코더는
statement 레벨에서 작업하고, 메소드와 클래스 레벨에서는 프로그래머나 디벨로퍼가 작업하며, 모델러나 아키텍트는 패키지나
서브시스템 등의 레벨에서 작업한다. 이것은 우리가 어떤 식으로 일을 나눠 진행하는가가 반영되어 있다. 우리가 어떻게 소프트웨어를
개발하는가와 개발자의 성장 단계는 서로 맞물려 있다. 개발자 성장 단계에 새로움을 추구하려면 어떻게 소프트웨어를 개발하는가 하는
쪽의 변화가 필요하다.
김형기 : 도입후 버려지는 도메인의 활용이 낫지 않는가?
Y : Global 과 Korean 은 양날의 칼과 같다. 한국적이라는 것은 충분히 경쟁력이 있다. 우리나라
개발자들이라면 핸드폰으로 영상을 본다는 것에 대해서 별 문제없이 생각해낼 수 있을 것이다. 하지만 외국의 경우에는 아직도 모뎀을
쓰는 경우가 있다. (M : 미국은 아직도 핸드폰으로 그렇게 할 수 없는데요.^^;) 그렇다면 우리가 한국적인, 즉 한국에서의
모델을 개발해 뒀다면 그것은 시간이 지나고서 외국에서 먹히는 모델이 된다는 것이다. 그것이 바로 Korean Solution이
Global 환경에서 먹히는 것이다. 하지만 그러기 위해서는 Korean이란 분야에 대한 핵심적인 이해가 반드시 필요하다.
L : 고객의 산업분야에 대한 지식이 있는 상태에서 Trend를 읽고 자신의 것으로 만들어야 한다.
SDS : 아까 말한 분류의 코더에서부터 시작해서 지금은 manager단계에 와 있다. 후배들을 어떻게 각 단계를
효과적으로 적용하여 교육할 수 있는가? 개개인의 역량 수준을 가늠할 수 있는 방법은 어떤 것이 있는가. 우리나라에서는 경력을
굉장히 우선순위로 치고 있다. 해외에서는 경력말고 다른 어떤 기준이 있는가?
M : SUN에서는 직무레벨에서 근속연수(경력)을 완전해 빼버렸다.
레벨
명칭
특징
1
1 level
2
2 level
3
3 level
기술적 관리도 전담해야 함
4
4 level
기술적 관리도 전담해야 함
5
Principal Engineer
6
Senior Stem Engineer
7
SUN Fellow
우리가 중요시 하는 것은
의사소통 능력.
팀웍.
Technical skill. 이것이 가장 중요하다.
승진되기 전에 앞서 자신이 승진후 해당 직책의 직무를 수행할 수 있음을 보여주어야 한다. 위의 세가지 항목이 완벽해야 확실한
인사이동이 결정이 된다. 가령 어떤 사람이 현재 단계보다 상위의 업무수행능력이 있다면 일선관리자가 3가지 항목에 대하여 평가해야
한다. 하지만 직속상관뿐 아니라 상위 모든 관리자의 개별평가가 다시 들어가서, 만장일치에 가까운 결과가 나와야 인사이동이 결정이
된다.
모두가 자신을 바라보고 평가한다는 것은 기분이 나쁠 수 있는 것이지만 (SUN에서) 굉장히 잘 돌아가는 시스템이다.
SDS : 고객과 계약시 경력직이 얼마나 되는지도 가격책정의 요인이 된다. 외국의 경우엔 어떤가?
M : 프로젝트의 기술적인 복잡성에 따라 가격이 책정된다. 충분한 마진이 나지 않는다면 쉬운건 사업파트너에게 넘기고 어려운 것만 맡아서 시행한다.
경력은 양날의 칼이 될 수 있다. 한국 소프트웨어 공동체의 발전을 위해서는 경력뿐 아니라 능력도 매우 중요하다. 일본의 경우 경력은 높아도 능력이 낮은 경우가 많아 발전이 없는 사례가 많다.
??? : 한국의 경우에는 소프트웨어 개발 방식이 건축개발 방식과 매우 유사하다. 그렇기 때문에 건축사업과 비슷하게
하도급으로 프로젝트를 수주하게 되어 굉장히 낮은 댓가를 받게 된다. 한국의 그런 문제를 알고 있는지, 혹은 미국에서도 이와
유사한 문제가 있는지?
M : 15년 전 쯤, 미국에서 내가 갓 대학졸업을 할 당시에는 신생기업이 많이 생겨났다. 능력이 된다면 창업이 충분히
가능한 상황이 미국의 경우였다. 8년 전쯤, 한국에 처음 방문했을 때, 상황이 안 좋았던 것으로 기억하고 있다. Skill이
얼마나 되는가가 자유시장 체제에서 매우 중요하다. 한국의 경우 창업기회가 많이 만들어지는 것이 중요하다고 본다. 충분한 보상이
없다면 어떻게 해야 내 기술이 인정받을 수 있는지 고민해야 한다. 미국의 경우에는 자신의 Skill이 높다는 것을 인지하고
있다면 학생들의 경우에도 창업을 한다. 대우를 제대로 받기 때문에.
L : 예상은 했지만 토론의 주제가 상당히 빗나갔다. 중간정리를 해서, 3가지 소주제를 하나로 합쳐보자. 어떻게 하면 개발자로서 성장하고, 그에 따른 제대로 된 보상을 받을 수 있을까?
Y : 외국의 경우에는 벤처캐피털이 굉장히 많이 발정되어있다. 캐피털에서 리스크분석까지 해서 투자가 들어가지만 우리나라의 경우에는 돈만 대는 소위 쉬운 투자만 했었다.
우리도 아이디어를 가지고 준비를 하고, 개발도 하고 해야 한다. 자기 아이디어를 형상화 시키는 노력이 필요하다.
경력개발자는 2가지로 나눠볼 수 있다. 같은 3년차 개발자라 하더라도,
1년차 경험을 3년간 되풀이한 사람
1년차에서 해야 할 경험 + 2년차에서 해야 할 경험 + 3년차에서 해야 할 경험
2번째 개발자가 진정한 3년차 개발자라 할 수 있을 것이다.
나 자신의 레벨은 나보다 상위레벨의 사람에 의해서 평가가 될수 있는 것이다. 그것은 경력이 아니라 개인의 질에 의해 평가되어야 한다.
엔지니어라면 한국적인 아이디어의 형상화를 가능하게 해야 한다. 그러기 위해서는 자신의 역량을 어떻게 하면 키울 수 있는가 하는 고민이 필요하다. 그제야 Mission Critical한 분야의 개발자도 나올 수 있는 것이다.
L : 엔지니어는 발명가가 아니다. 예술적인 코드가 아니라, 고객의 원하는 코드를 짜야 한다. 그러기 위해서는
Industry에 대한 지식을 쌓는 것이 중요하다. 오히려 Industry에 대한 이해가 프로젝트의 이해를 높일 수 있다.
(여담 : 책을 많이 봐야 한다!!!) 엔지니어도 비즈니스 룰을 알아야 한다. 그것이 싫다면 비즈니스를 잘 아는 친구를 사귀도록
하라.(^^;)
Y : 알고리즘은 이론을 열심히 배우는 것도 중요하지만 실제문제를 어떻게 해결해야 하는지에 대한 정확한 이해가 뒷받침되어야 좋은 알고리즘이 나온다.
오픈소스에 관심을 가져라. 언어의 장벽을 넘어라. 배워놔야 기회가 왔을 때 잡는다. 배워놔야 Global환경에서
인정받는다. 한국이라는 환경에 갇혀있지 마라. 오픈소스 커뮤니티를 최대한 활용하라. 오프라인 커뮤니티도 찾아가 최신의
Trend를 계속해서 파악해라.
L : 기회를 잡으려면 준비해라. 준비하면 기회가 찾아온다. 준비하면 기회를 아~주 잘 낚을 수 있다.
M : 인터넷의 공용어는 영어다. 그건 현실이다. 한국분들, 영어를 익히십시오. 남부아시아 베트남의 경우 대학에서
영어로 강의하는 것이 의무화 되어서 IT분야에서 빠른 발전이 이루어지고 있다. 대만인 이제 의무화가 되고 있다. 영어가 최고의
언어라고 생각하지 않고 내 경우에도 20년후의 비즈니스 언어는 중국어가 될거라 생각해 딸아이에게 중국어를 가르치고 있다.
배우는 것을 멈춘다면 리더가 될 수 없다. 오픈소스를 활용하라. ClosedSource는 배울 수 있는 것이 없지만 오픈소스는 가능하다. 개발자로서, 다른 사람의 빌드를 살펴보고 검토하는 것이 가장 많이 배울 수 있는 방법이다.
배우는 데 쓰는 시간투자는 굉장히 가치 있는 일이다.
김창준 : 빠르게 성장하는 사람들의 비결은?
M : 모든 것에 끊임없는 호기심을 가져라. 지시에 대해 2가지 이상의 해결책을 제시한다면 상관에게 깊은 인상을 심어줄 수 있을 것이다. 자신의 사고가 빠르게 돌아가야 한다.
많은 이들이 당신이 하는 일에 대해 갈채를 보내고 비난하는 사람은 별로 없다면, 당신이 잘못된 길을 가고 있다고 확신해도 좋다. 바보들이 동의하고 있는 일을 하는 것이기 때문이다. 많은 사람들이 당신을 조롱하고 무시한다면 적어도 이것 한 가지는 확신해도 좋다. 적어도 당신이 현명한 행동을 하고 있을 가능성이 있다는 것이다. - E. W. 스크립스
내가 싸이코 소리를 자주 듣는데...그럼 적어도 난 현명한 행동을 하고 있을 가능성이 있다는 이야기?ㅋㅋㅋ
학교가서 열심히 자바를 공부하고 왔다. 생활패턴을 고정시키려고 밤새고(사실 3~4시간 잠을 잤다.) 왔더니 교회를 가잔다. 따라간 교회...설교와 예배 모두 '그건 아니지. 어찌 그렇게 설명을 하고 그것을 그렇게 받아들이시나?'라는 생각밖에 안 들었다. 중간에 이런 설교가 있었다.
두 아들이 있습니다. 큰아들에게 일을 시켰더니 알겠다고 대답을 하고 실행에 옮기지 않습니다. 작은아들에게 일을 시켰더니 싫다고는 했지만 늬우치고 실행에 옮겼습니다. 하나님은 큰아들보다는 작은아들 같은 사람을 원하십니다.
그 설교가 끝나기가 무섭게 밖에서 웬 노숙자가 행패를 부리는 소리가 들렸다. 밖에서 제지하는 소리도 들리긴 했다. 그런데 금방 제지가 안 되는가 계속 시끄러운 소리가 났다. 그런데...
허허허...아무도 말리러 나가지 않는다. 묵묵히 설교만 들을 뿐... 말씀만 들으면 하나님의 아들이냐? 그 말씀을 방해하는 것은 그냥 있으면 되는 것이냐? 하나님의 말씀을?
기분이 좋지 않아지려고 하는데 갑자기 확 기분이 상한 일이 벌어졌다. 헌금 목록을 말하는 것이다. 젠장...대략 다음 만화가 생각이 나는 것이다.
(예전엔 만화 있었음)
...씁. 기분이 드러워져서 밖에 나가서 시끄러운 사람이나 막았다. 노숙자 티가 팍팍 났다. 옷에서는 지린내가 나고 술냄새 나고 젠장...품에는 과도칼이 있었고...
아, 암튼 승질나네. --- 에잇, 그닥 좋은 기분으로 쓴 글도 아니었는데, 양영순 작가가 저작권 관련해서 대대적인 검열이 있을거라고 알려줘서 그림은 삭제. 웹툰이 발전한 이유가 여기저기서 퍼가면서 알려졌기 때문인데, 에휴, 기업체 게시판 실명제 이후로 나라에서 통제하는게 점점 늘어가는게...짜증나. 권리를 빼앗긴 상황이 뭐가 반가우랴. 감시받는 사회, 정말 우리나라 정책 참으로 씨발것이네. (개인 블로그이므로 순화하지 않고 그대로 씁니다. 거슬리는 분들은, 그냥 그렇게 사세요. 여기서까지 통제받고 싶지 않으니까. 나나 지금 시대나 뭐 쌍팔년도 마인드도 아니고.)
def OnSearchDB(self, event): # 여기에 기존 표에 있던 내용 지우는 과정이 들어가야 된다. ClearGrid() result = GetData(self, self.txtName.Value) for row in range(len(result)): for col in range(len(result[row])): values = result[row][col] # print values # print len(values) try: self.grdData.SetCellValue(row,col,str(values)) except: self.grdData.SetCellValue(row,col,"DB입력이 잘못되어 있습니다. 5줄제한을 맞춰주세요.")
def OnPrint(self, event): #텍스트 파일로 저장. result = GetData(self, self.txtName.Value) SaveFile(result, self.txtName.Value) #텍스트 파일 인쇄. PrintFile() #인쇄한 텍스트 파일 삭제. DeleteFile()
SaveFile.write(' 학 생 : %s\n' % EncodingChange(Name)) for row in range(len(result)): SaveFile.write('%s' % SeperateLine) for col in range(len(result[row])): if col == 0: values = '[상담 일자] : ' + result[row][col] if col == 1: values = '[상담 선생님] : ' + result[row][col] if col == 2: values = '[상담 내용] : \n' + result[row][col]
난 원래 IDLE 만 사용했었다. 한때 사용했었던 BoA 의 끔찍한 매력을 잊기 위해서 IDLE을 사용하고 있었는데 역시 초보에게는 자동완성기능이 너무나도 절실하게 필요해서 이클립스를 사용하기 시작했다.
그런데...
이클립스에서 다음 소스가 동작을 안 하는 것이다. 파일트리를 얻어낼 필요가 있어서 예제코드를 그대로 따라해보고 있었는데,
# -*- coding: cp949 -*- import os
def testmodule(): image_dir = "E:\Firefox" print image_dir t = os.walk(image_dir) print type(t) print "t = ", t
for root, dirs, files in os.walk(image_dir): for name in files: #os.remove(os.path.join(root, name)) print os.path.join(root, name) for name in dirs: #os.rmdir(os.path.join(root, name)) print os.path.join(root, name)
def main(): testmodule() pass
main()
이상하게 결과가 예상대로 안 나오는 것이다. 예상대로라면 디렉토리 안의 파일들이 쭈르륵 쏟아져야 되는데... 더욱 이상한 건 이클립스에서는 안 되는데 IDLE에서는 정상작동한다는 것.
그래서 문자열 처리 방식이 문제인가 싶어서 인코딩 방식을 cp949 에서 euc-kr로 설정해주었더니 정상 작동! 혹시나 싶어 utf-8로 바꿔봐도 정상 작동!
흠, cp949 랑 euc-kr, utf-8 의 차이는 무엇이길래 이클립스가 저리도 편식을 하는 건지?
암튼 앞으로는 utf-8을 애용해주어야겠다. IDLE에서도 문제없이 작동하는 것을 보니 지금까지 cp949에서 코딩하던 습관을 utf-8로 바꿔줘야겠군.
음하하~!! 노트북 셋팅이 거의 끝났다. 이제 프로그래밍 환경이 거의 갖춰졌다. C/C++ 환경은 Dev-C++로, Java/Python 통합으로 Eclipse를 사용하려 한다. 지금까지 Dev-C++ 이야 그렇다고 쳐도, Python 은 IDLE을 주로 사용했는데 노트북 성능이 성능이니만큼 그냥 Eclipse에서 PyDev로 쓰기로 했다.
근데 이거, 기대 이상.
자동완성기능, 백그라운드컴파일(맞나?)을 통한 경고메시지까지야 내가 편하자는 기능이고, Subversion을 통한 버전관리와 ANT를 이용한 빌드 방법이나 익혀놔야겠다.
그리고 아직 모르고 있던 자바나 열심히 써먹어봐야겠다.
그나저나 Unit Test 기능은 이클립스에 안 들어있나? 자바용은 있는 걸로 알고 있는데...
이 글은 당시의 일을 기록으로 남기느라 과거형으로 표현된 부분이 있을 수 있습니다. 날짜 또한 해당월의 1일로 되어있다면 정확한 날짜를 파악할 수 없어 대충 기간을 맞춘 것입니다. 다음 링크(http://leewoosung.tistory.com/99)를 확인하세요. ---
정말 개고생 한 부분.
PWM이 1ms과 2ms간격으로 변할 때 High 상태에서 외부의 빠른 클럭을 카운터로 세어 현재 어느 정도인지 파악하는 회로이다. 아래 사진에 보면 스위처 동작에 따라 Auto/Manual 을 선택할 수 있게 PWM input이 두 포트가 있다. 하나는 FCC에서, 다른 하나는 수신기에서 들어오는 PWM인데, 옆에 달린 추가 PWM(수신기에서 나온) 의 변화를 감지하여 어느 쪽 PWM을 출력으로 내보낼 것인지 선택한다.
작업을 하면서 천만다행으로 생각했던 것은 스위치를 달아놓은 것. 저걸 크기를 줄인답시고 배선을 했다면 카운터의 임계치 조정작업에서 미쳐버렸을지도 모를 일이다.
그래. 이번 만큼은 내 느낌이 틀렸을꺼야. 사랑놀이 따위 이제는 나와는 상관없는 것이라고 생각하고 지낸지 오래지만, 그래도
난 아직 덜 굳었다구. 확인할 용기는 나에겐 남아있지 않아. 애써 아니라고 생각할 뿐이야. 슬픔위에 세워진 기쁨이라면, 모진
바람에도 더 견뎌야 하잖아. 아직은, 아직은 아니야...
...살다 보면 꼭 한번은 재수가 좋든지 나쁘든지 천재를 만나게 된다. 대다수 우리들은 이 천재와 경쟁하다가 상처투성이가 되든지, 아니면 자신의
길을 포기하게 된다. 그리고 평생 주눅 들어 살든지, 아니면 자신의 취미나 재능과는 상관없는 직업을 가지고 평생 못 가본 길에 대해서 동경하며
산다. 이처럼 자신의 분야에서 추월할 수 없는 천재를 만난다는 것은 끔찍하고 잔인한 일이다. 어릴 때 동네에서 그림에 대한 신동이 되고,
학교에서 만화에 대한 재능을 인정받아 만화계에 입문해서 동료들을 만났을 때, 내 재능은 도토리 키 재기라는 것을 알았다. 그러나 그 중에 한두
명의 천재를 만났다. 나는 불면증에 시달릴 정도로 매일매일 날밤을 새우다시피 그림을 그리며 살았다.
내 작업실은 이층 다락방이었고
매일 두부장수 아저씨의 종소리가 들리면 남들이 잠자는 시간만큼 나는 더 살았다는 만족감으로 그제서야 쌓인 원고지를 안고 잠들곤 했다. 그러나 그
친구는 한달 내내 술만 마시고 있다가도 며칠 휘갈겨서 가져오는 원고로 내 원고를 휴지로 만들어 버렸다.
나는 타고난 재능에 대해
원망도 해보고 이를 악물고 그 친구와 경쟁도 해 봤지만 시간이 갈수록 내 상처만 커져갔다. 만화에 대한 흥미가 없어지고 작가가 된다는 생각은
점점 멀어졌다.
내게도 주눅이 들고 상처 입은 마음으로 현실과 타협해서 사회로 나가야 될 시간이 왔다. 그러나 나는 만화에 미쳐
있었다.
새 학기가 열리면 이 천재들과 싸워서 이기는 방법을 학생들에게 꼭 강의한다. 그것은 천재들과 절대로 정면승부를 하지
말라는 것이다. 천재를 만나면 먼저 보내주는 것이 상책이다. 그러면 상처 입을 필요가 없다.
작가의 길은 장거리 마라톤이지 단거리
승부가 아니다. 천재들은 항상 먼저 가기 마련이고, 먼저 가서 뒤돌아보면 세상살이가 시시한 법이고, 그리고 어느 날 신의 벽을 만나 버린다.
인간이 절대로 넘을 수 없는 신의 벽을 만나면 천재는 좌절하고 방황하고 스스로를 파괴한다. 그리고 종내는 할 일을 잃고 멈춰서
버린다.
이처럼 천재를 먼저 보내놓고 10년이든 20년이든 자신이 할 수 있다는 생각으로 하루하루를 꾸준히 걷다 보면 어느 날
멈춰버린 그 천재를 추월해서 지나가는 자신을 보게 된다. 산다는 것은 긴긴 세월에 걸쳐 하는 장거리 승부이지 절대로 단거리 승부가 아니다.
만화를 지망하는 학생들은 그림을 잘 그리고 싶어한다. 그렇다면 매일매일 스케치북을 들고 10장의 크로키를 하면 된다.1년이면
3500장을 그리게 되고 10년이면 3만 5000장의 포즈를 잡게 된다. 그 속에는 온갖 인간의 자세와 패션과 풍경이 있다.
한마디로 이 세상에서 그려보지 않은 것은 거의 없는 것이다. 거기에다 좋은 글도 쓰고 싶다면, 매일매일 일기를 쓰고 메모를 하면
된다. 가장 정직하게 내면 세계를 파고 들어가는 설득력과 온갖 상상의 아이디어와 줄거리를 갖게 된다.
자신만이 경험한 가장 진솔한
이야기는 모두에게 감동을 준다. 만화가 이두호 선생은 항상 “만화는 엉덩이로 그린다.”라고 후배들에게 조언한다. 이 말은 언제나 내게 감동을
준다. 평생을 작가로서 생활하려면 지치지 않는 집중력과 지구력보다 더 중요한 것은 없다.
가끔 지구력 있는 천재도 있다. 그런
천재는 존재하는 것만으로도 축복이고 보는 것만으로도 감사하다. 그런 천재들은 너무나 많은 즐거움과 혜택을 우리에게 주고 우리들의 갈 길을 제시해
준다. 나는 그런 천재들과 동시대를 산다는 것만 해도 가슴 벅차게 행복하다.
나 같은 사람은 그저 잠들기 전에 한 장의 그림만 더
그리면 된다. 해 지기 전에 딱 한 걸음만 더 걷다보면 어느 날 내 자신이 바라던 모습과 만나게 될 것이다. 그것이 정상이든, 산중턱이든 내가
원하는 것은 내가 바라던 만큼만 있으면 되는 것이다.