가지고 그들이 이해할 만큼 설명을 하자니 세월이 까마득하고 간단한 힌트를 주자니 쪽지로 질문
공세고...이러지도 못하고 저러지도 못하고... 답답하니 잠이 오는것같다.
VB 첫화면에도 필독 문서가 있어 질문 전에 읽어 보기를 권장을 하고 있지만 아직도 읽어보지않은
분들이 많은가 보다. 검색....이것을 해보도록 권하지만 이것도 자주 해봐야 요령이 생기는데
아니하니 무슨 검색어로 해야 내가 원하는 답변이 나올지 모른다. 그러니 검색을 하지 않는다.
마침 이런글이 보여서 연구 보존코자 공지로 등록을 하니 부디 차근 차근 읽고 마음에 새겨서
스스로을 위한 마음을 다스림에 사용하자.......
=======================================================================================
원리 파악과 경험 축적으로「프로그래밍 길들이기」
중학교 시절 첫 프로그램인 격투기 게임을 완성하기 위해 수업 시간 뒤편에 앉아 베이직 코드를 적어 나갔다. 주말이면 이 코드를 컴퓨터에 옮기는 작업을 했고, 이런 일을 거의 몇 주 동안 반복했다. 드디어 게임 프로그램 완성의 시간이 다가왔고, 조심스럽게 RUN을 쳤다. 결과는 참담했고 그날 필자는 하늘에서 떨어지는 눈을 맞으며 펑펑 울었다. 사춘기 소년의 눈물이 아니었다. 이유가 무엇이었을까?
유경상 (마이크로소프트웨어) 2002/02/20
다음은 1부터 1000까지의 합을 구하는 C 코드이다. 하지만 제대로 작동하지 않는다. 왜 그럴까?
int i, sum;
sum = 0;
for(i=1; i <= 1000; i++);
sum += i;
printf("sum = %d", sum);
단번에 알아낸 독자들도 있겠지만 앞의 코드 오류는 for 문 맨 뒤의 세미콜론 때문이다. 이 세미콜론 때문에 sum 값은 1001이 된다. 필자는 몇 년 전 이와 비슷한 코드를 작성하면서 4시간 정도를 허비한 경험이 있다. 코드가 앞의 코드보다는 훨씬 더 복잡했지만 잘못된 세미콜론 하나 때문에 제대로 된 수치 해석 결과가 나오지 않았다. 덕분에 여기 저기 코드를 마구 수정했고 원인을 발견하고 수정한 코드를 다시 복구하는 데 모두 4시간이나 소요해야 했다.
프로그래머라면 누구나 코드를 작성하면서 겪는 황당한 경험들이 많이 있을 것이다. 사소한 실수부터 개발환경, 개발도구 등의 버그 등등…. 이러한 황당한 경험들을 겪었을 때 각자의 반응들은 다양할 것이다. 부정적인 반응 중에서 좀 심한 경우 "이 짓거리 더 이상 못하겠다"며 나동그라지는 사람이 있는가 하면, 긍정적인 반응으로 "앞으로 이런 실수는 하지 말아야지"하며 씨익 웃는 사람도 있을 것이다.
필자 역시 십 수년 동안 프로그램을 작성하면서 많은 경험을 했다. 필자가 직접 겪은 경험들도 있으며 후배나 선배를 통해 간접적으로 겪은 경험도 있다. 필자가 직간접적으로 겪은 이런 일들 중 몇 가지를 여기서 독자들에게 소개하고, 몇 가지 사건들로부터 필자가 얻은 교훈을 공유해 보고자 한다.
점진적 프로그래밍
중학교 2학년 때였다. 80년대 중반 필자가 처음 접했던 컴퓨터는 Z80이라는 8비트 CPU를 탑재한 퍼스널 컴퓨터였다. 64KB(64MB가 아니다)의 메모리에 BASIC을 기본 탑재한 이 컴퓨터는 그 당시 고가의 제품이었다. 필자의 기억으로 TV와 냉장고보다 훨씬 비쌌던 것 같다. 그다지 넉넉하지 않은 집안 사정상 필자는 이 컴퓨터를 사달라고 말할 엄두도 못 냈다.
필자는 모 회사의 컴퓨터 전시장에서 매주 토·일요일은 살다시피 하면서 프로그램을 작성했다. 처음 도전한 프로그램다운 프로그램은 격투기 게임. 매일 수업시간 뒤편에 앉아 노트에다 베이직 코드를 적었다. 컴퓨터가 없었기 때문에 평소에 코드를 정확히 기록해 놓고 주말이 되면 이 코드를 그대로 컴퓨터에 옮기는 작업만을 몇 주 동안 반복했다. 그리고 수천 라인의 게임이 완성되고 처음으로 실행시켜볼 때가 왔다.
RUN(베이직의 수행 커맨드)을 조심스럽게 타이핑하고 리턴 키(지금의 엔터 키)를 눌렀다. 결과는 참담했다. 코드는 전혀 제대로 작동하지 않았고 게임 화면은 엉망으로 나왔으며 캐릭터는 전혀 움직이지도 않았다. 그날 집에 돌아가던 필자는 내리는 눈이 왜 그리 서러웠던지 펑펑 울었던 기억이 난다.
갑자기 웬 자서전? 필자가 여기서 말하고 싶은 이야기는 점진적으로 코드를 작성하라는 조언을 하고 싶어서다. 필자가 겪은 실수의 원인은 점진적으로 코드를 작성하지 않고 수백 수천 라인의 코드를 단번에 작성하려고 했기 때문이다. 인간은 결코 완벽할 수 없는 존재다. 단 수십 라인의 코드를 작성하더라도 실수를 할 수 있다. 더 많은 코드를 작성해야 한다면 실수의 가능성이나 실수 횟수는 더 늘어날 것이다.
이러한 오류를 줄이기 위해서는 프로그램을 작은 기능 단위로 나누고 이것들을 하나하나 작성하고 테스트하는 작업을 반복하면서 전체 프로그램을 완성하는 것이 중요하다. 필자는 거의 하나의 함수를 작성할 때마다 그 함수가 제대로 작동하는가를 테스트한다. 그 함수가 예상대로 작동하는 경우에 다음 함수 작성에 들어간다. 물론 항상 이런 경우만 있는 것은 아니지만 대부분의 코딩 작업을 이러한 방식으로 수행한다.
시간이 더 많이 소요될 것 같지만 실제로 전혀 그렇지 않다. 더 많은 코드를 작성하고 테스트하는 것보다 더 적은 시간이 소요된다. 왜냐면 더 많은 코드는 보다 정확히 테스트하기 위해 더 많은 경우의 수를 테스트해야 하기 때문이다. 또한 코드에 문제가 발생했을 때 어느 부분에서 문제가 발생했는가를 알아내기 위해서도 더 많은 시간이 필요하다.
반면 적은 양의 코드, 즉 함수 단위를 테스트하는 데는 훨씬 더 적은 경우의 수만을 테스트해도 되며 문제가 발생한 곳을 정확히 알아낼 수 있다. 그리고 단위 함수가 제대로 작동하기 때문에 이들 함수들이 연동돼 작동하는 작업 역시 테스트하고 문제를 파악해 내기가 쉽다.
하나의 변수가 프로젝트의 실패로 연결된다
필자의 후배가 아르바이트를 할 때였다. 그 후배가 맡은 일은 국회의원 선거 결과를 통계적으로 추측해 당선 여부를 유추해 내는 프로그램을 작성하는 것이었다. 그리고 그 결과는 모 방송사를 통해 생방송으로 방송될 예정이었다.
선거 날이 다가왔고 예비 조사가 수행되고 그 조사 결과가 프로그램의 입력으로 주어졌다. 프로그램은 당선 가능성이 있는 후보들을 지목했고 이 내용이 일부 방송됐다. 하지만 개표가 진행됨에 따라 프로그램이 예측한 것은 전혀 엉뚱한 것이었음이 밝혀졌다. 프로그램의 수행 결과가 테스트할 때와는 달리 이상하게 나온 것이다.
그 방송사는 추측 보도를 포기하고야 말았다. 프로젝트는 완전 실패로 돌아간 것이다. 그 후배가 저지른 실수는 5개의 중첩된 for 문장에서 반복 변수 하나를 잘 못 썼기 때문이었다. 이 실수는 그 코드를 수행하는 함수가 별도로 테스트되지 않았기 때문에 발견되지 않았다. 단 하나의 변수가 프로젝트의 실패라는 참담한 결과를 낳은 것이다.
바보가 아닌 다음에야 누구나 점진적인 방식으로 코딩할 것 같지만 실제는 전혀 그렇지 않다. 많은 개발자들이 수 백 라인의 코드와 십 수개의 함수를 작성하면서 단 한번의 테스트 수행을 해보지 않고 개발하는 경우가 많다. 이렇게 하면 한 번에 제대로 작동할 수도 있지만 그렇지 않을 확률이 훨씬 더 높다. 그리고 코드가 원하는 대로 작동하지 않을 때 문제를 찾아 해결하는데 오랜 시간이 소요될 것이다.
오류 메시지의 중요성
필자는 가끔씩 프로그래밍 관련 사이트에 들어가 질문에 답변을 하거나 필자에게 직접 전달되는 질문에 대한 답변을 하곤 한다. 이 때 필자를 황당하게 하는 질문들은 '막연히 이렇게 저렇게 했더니 오류가 나더라 어떻게 하면 되느냐'는 것이다. 어떤 오류인지는 말하지도 않고 막연히 안 된다는 것이다. 이럴 때는 정말 답변해 주기 난감하다. 원인을 알아야 그 문제를 해결할 텐데 이 경우는 아예 원인에 접근하기 위한 단서를 주지 않는 경우이기 때문이다.
오류 메시지는 문제를 해결하기 위한 중요한 단서다. 하지만 초보 개발자나 많은 개발자들이 이 오류 메시지의 중요성을 간과하는 것 같다. 프로그램을 개발하다 보면 예상하지 못한 오류 메시지가 자주 등장할 것이다. 그리고 이 오류를 해결할 수 있는 첫 번째 단서는 이 오류 메시지다. 메시지를 잘 읽어보면 왜 오류가 발생했는가를 알 수 있다. 때에 따라 친절하게도 오류가 발생한 위치도 알려준다. 비록 이 위치가 정확하지 않을 때도 많지만 말이다. 한 가지 예를 들어보자. 다음 비주얼 베이직 스크립트 코드를 살펴보자. 얼핏 봐서는 별다른 문제가 없는 듯한 코드다.
strConn = "Provider=SQLOLEDB;Data Source=(local);User ID=Tester;Password=Test"
strSQL = "SELECT * FROM Employees"
Set adoRS = WScript.CreateObject("ADODB.RecordSet")
adoRS.Open strSQL, strConn, adOpenStatic, adLockReadOnly
이 코드를 윈도우 스크립팅 호스트나 ASP에서 수행해보자. 분명히 오류 메시지가 나타날 것이다. 오류 메시지는 "잘못된 형식이거나 올바른 범위 밖에 있거나 서로 충돌하는 인수입니다"로 나타나며, 오류가 발생한 위치는 네 번째 라인인 adoRS.Open에서 발생한 것으로 표시될 것이다. 메시지는 인수(parameter)에 문제가 있음을 알려주고 있다. strSQL이나 strConn의 문제는 아닌 듯하다.
그렇다면 adOpenStatic과 adLockReadOnly 둘 중 하나가 혹은 모두가 문제일 가능성이 높다. 하지만 우리가 사용한 매개변수는 ADO에서 정의하는 정확한 상수임에 틀림없다. 정확한 상수이지만 이 상수는 어디에도 정의되지 않았다. 따라서 이 상수 값은 0이 되며 이것을 ADO가 거부하는 것이다. 이 코드를 제대로 작동시키기 위해서는 adOpenStatic과 adLockReadOnly의 상수 값을 미리 정의하든가 이 상수 대신 숫자 값을 사용해야 한다.
비록 단순한 예이지만 이 예를 통해 오류 메시지가 주는 힌트를 조금만 생각해 보면 오류 메시지의 원인을 찾아 낼 수 있다는 것을 알았을 것이다. 대부분의 오류 상황은 이 보다 훨씬 복잡한 상황일 것임에 틀림없다. 하지만 이 오류를 해결하는 최초의 단서는 오류 메시지임을 누구도 부정하지는 않을 것이다.
소스 코드는 가장 훌륭한 메모장
프로그램을 작성해본 사람이라면 누구나 소스 코드에 주석(comment)을 다는 것이 좋은 습관이라는 것을 알고 있다. 필자가 아는 K 프로그래머는 프로젝트 진행 중에 한 모듈의 코드를 보고 "누가 이렇게 작성했냐"며 길길이 날뛴 적이 있다고 한다. 그 코드는 너무 복잡했기 때문에 유지 보수가 어렵다는 것이었다.
하지만 팀원 누구도 그 코드를 작성하지 않았다. 자세히 코드를 살펴본 결과 그 코드의 작성자는 다름 아닌 K 씨 자신이었다. 그리고 그는 그렇게 복잡하게 코딩하지 않으면 안 되었던 이유를 겨우 생각해 냈다. 왜 그런 식으로 코딩했는지 몇 줄의 주석만 달아 놨더라도 아마 이런 해프닝은 발생하지 않았을 것이다.
주석만 달았어도 이 고생은 안했을텐데…
자기가 작성한 코드라도 몇 개월이 지나면 기억하기 어렵다. 특히 대형 프로젝트일수록 이러한 상황이 심하다. 필자가 리눅스 커널의 TCP/IP 시스템 코드를 수정할 때였다. 그때 커널 버전은 1.0.8이었지만 여전히 거대한 분량의 커널 코드는 필자를 압도하고도 남았다. 논문은 고속의 데이터 전송을 위한 운영체제 레벨의 지원에 대한 것이었는데, 커널의 디바이스 드라이버를 수정해야 했다.
드라이버를 수정해 원하는 속도 향상을 얻었다. 그리고 두 달 후, 관련 논문을 작성하다가 드라이버 코드를 참고해야 할 상황이 왔다. 하지만 코드를 아무리 살펴봐도 정말 '무식한' 방법으로 코딩이 되어 있었다.
아무리 생각해봐도 왜 내가 그렇게 코딩했는지 생각이 나지 않았다. 그래서 좀더 효율적인 코드로 바꿔보았다. 수정한 코드는 제대로 작동하지 않았고 그때서야 왜 그렇게 무식한 방법을 사용했는지 이유가 떠올랐다. 이 경우도 비슷하게 몇 줄의 주석만 있었다면 이런 고생은 안 했을 것이다.
그 이후로 필자는 코드에 주석을 다는 습관을 들였다. 그리고 추가적으로 코드를 메모장처럼 사용하는 습관도 들였다. 대부분의 프로그래머는 많은 시간을 소스 코드와 함께 보낸다. 따라서 코딩과 관련된 사항을 종이나 다른 파일 등에 기록하는 것보다 소스 코드에 기록해 두는 것이 매우 효율적이다.
다음에 작업할 내용이나 다른 코드가 완성된 후에 수정해야 할 사항, 하드 코드(hard code)된 내용 등을 소스 코드 내에 주석으로 남겨두는 것이다. 그리고 차후 작업할 때 이 주석을 보면 앞으로 해야 할 내용, 수정해야 할 내용 등이 설명과 함께 남게 될 것이다. 다음은 필자가 소스 코드에 사용한 몇몇 주석을 예로 들어본 것이다.
// FIXME : 테스트 후 잘 작동하면 삭제할 것!
// FIXME : 다음 멤버 변수를 private로 바꿀 것!
// CONSIDER : 여기서 예외를 발생하는 것이 합당할까?
// HARD CODE : 보다 간단히 하기 위해 아스키 코드를 하드 코드함
이렇게 작성된 주석들을 탐색기의 검색 기능이나 대부분의 에디터가 제공하는 검색을 통해 키워드(FIXME, CONSIDER 등)를 찾으면 소스 코드에서 어떤 작업을 더 해야 하는가가 명백히 드러난다. 소스 코드는 다른 어떤 것 보다 훌륭한 개발 일지이자 메모장이다.
고수는 자료를 잘 찾는 사람
독자들이 프로그램을 작성하다보면 어려운 문제나 쉽게 해결되지 않는 오류에 부딪힐 때가 많을 것이다. 그럴 때 독자들 중에 많은 사람은 인터넷의 개발자 포럼에 자신이 부딪힌 문제를 질문할 때가 종종 있을 것이다.
대개 제목은 "고수님들 부탁 드립니다…로 시작되기 쉽고" 얼마 후에 고수가 문제에 대한 해결책 혹은 해결을 위한 실마리를 알려준다. 그렇다면 그 고수라 불리는 사람들은 다양한 분야의 여러 질문을 어떻게 척척 대답해 주는 것일까? 그들의 머리는 정말 좋아서 모든 상황을 기억하고 있는 것일까?
필자의 경험에 비추어 본다면 전혀 그렇지 않을 가능성이 높다. 10여 년 전이라면 모를까 요즘에는 너무도 많은 기술과 너무도 많은 개발환경, 프로그래밍 언어, 플랫폼이 쏟아져 나오고 있다. 이들에 대해 모두 잘 알고 있는 사람은 정말 드물다. 그렇다 할지라도 게시판에서 답변을 잘해주는 고수들을 보면 세세한 함수들의 매개변수까지 정말 잘 알고 있다는 생각이 드는 것은 사실이다.
필자는 요즘의 고수란 필요한 프로그래밍 자료, 기술 가이드, How-to 등의 자료를 잘 찾는 사람이라고 말하고 싶다. 수만 개의 함수와 클래스 등을 모두 외우고 다니는 사람은 없을 것이다. 하지만 간략한 키워드만으로 필요한 함수와 클래스를 찾을 수 있는 능력이 있다면 그는 고수 반열에 오를 충분한 자격이 있다.
누군가가 질문을 하거나 자신이 프로그램을 작성할 때 특정 함수 혹은 기능이 필요하다면 고수라 불리는 사나이는 "어디서 봤었지…"'라고 몇 마디 중얼거리며 인터넷이나 관련 책자를 뒤적거릴 것이다. 오랜 시간을 소요하지 않고도 그는 자신이 필요한 기능을 찾을 것이고 구체적인 사용법 등은 그 자료에 모두 실려있다. 이제 프로그램을 작성하는 데 별 어려움은 없을 것이다.
반면에 남들이 고수라고 부르지 않는 사람들은 무언가 하고 싶지만 그것을 어떻게 할지 모를 때면 먼저 가슴이 답답하고 눈알이 튀어나올 것 같은 막막함에 부딪힌다. 관련 자료를 찾아보고 싶지만 어디서 자료를 찾아야 할지도 잘 모른다. 겨우 자료가 인터넷이나 어떤 책에 나와 있다고 주워 들어 구하게 된다. 됐다 싶은 마음에 자료를 살펴보지만 자료의 양이 너무 방대하다. 요즘 컴퓨터 관련 책들이 좀 두꺼운가? 게다가 MSDN 라이브러리 같은 자료는 CD 3장 1.8GB에 달하는 방대한 분량이다. 숨이 막히기 딱 좋은 분량 아닌가?
고기도 먹어본 사람이 잘 굽는다
"그렇다면 고수들처럼 자료를 빨리 잘 찾으려면 어떻게 해야 합니까?" 먼저 많이 찾아봐야 한다. 고기도 먹어본 사람이 잘 굽는다고 했다. 자료를 많이 찾아 본 사람은 어디에 유사한 자료가 있는지 알고 있다. 게다가 이렇게 자료를 찾다보면 자신도 모르는 사이에 공력이 쌓인다. 공력이라 함은 예전에 찾아보지 않았더라도 '이런 자료는 여기에 있을 거야'라고 추측할 수 있는 능력을 말한다. 그리고 실제로 찾아보면 대개 80∼90%는 원하는 자료가 찍어 본 그곳에 떡(?)하니 있기 마련이다.
비록 원하는 자료를 찾지 못하더라도 그것을 찾기 위한 실마리 정도는 얻을 것이다. 필자가 주로 참조하는 자료는 뭐니뭐니 해도 MSDN 라이브러리다. 윈도우 플랫폼에서 개발하는 개발자라면 모두 이 MSDN 라이브러리를 끼고 살아야 한다. 개발에 가장 많이 참조하기 때문에 하드디스크 용량이 아무리 부족해도 MSDN 라이브러리 CD 3장을 거의 모두 설치한다.
그리고 필자가 겪는 문제의 많은 부분을 여기 MSDN 자료에서 해결하곤 한다. MSDN 라이브러리를 한번이라도 돌아본 사람은 알겠지만 여기서 원하는 자료를 찾기란 쉽지 않다. 인덱스가 잘 갖춰져 있지만 키워드 하나를 던지더라도 그 키워드에 포함되는 자료가 수십 수백 개가 나타나기도 한다. "이들 중에서 내가 필요한 것은?" MSDN 라이브러리를 많이 참고해 본 사람은 그 많은 내용 중 내가 원하는 것이 무엇인가를 어렵지 않게 골라낼 수 있다.
대충 이번 이야기의 결론은 이렇다. 고수라고 해서 모든 것을 알고 기억하는 것은 불가능하다. 그러나 그들은 필요한 자료를 빨리 찾는 방법을 알고 있다. 그 방법은 배울 수 있는 것이라기보다는 자료를 많이 찾아봄으로써 스스로 터득하는 것이다. 물론 누군가가 옆에서 계속 자료 찾는 것을 도와 줄 수 있지만 스스로 고생하면서 터득한 자료 찾는 방법이 훨씬 더 값지다는 것을 명심하자.
보다 많은 경험
이제까지 필자가 직간접적으로 경험한 에피소드 몇 개를 소개했다. 마지막으로 황당한 에피소드는 아니지만 필자가 초보 프로그래머와 보다 고급 프로그래밍을 하고자 하는 개발자에게 해줄 수 있는 몇 가지 조언을 해보기로 하겠다. 다분히 개인적이고 주관적인 내용이기 때문에 모든 독자들이 공감하리라고 생각하지는 않는다. 그래도 1985년부터 프로그램을 짜온(대개 프로그래머들은 프로그램을 '짠다'라고 표현한다) 한 프로그래머의 이야기니 들어봐 주기 바랄 뿐이다.
프로그래밍은 경험이다
먼저 권장하고 싶은 것은 보다 많은 경험을 해보라고 권하고 싶다. 필자의 주관 하에 프로그래밍은 경험이라고 말하고 싶다. 보다 많은 프로그래밍 경험을 갖고 있는 사람은 주어진 문제를 보다 빨리 해결할 수 있는 능력을 갖고 있다. 말을 좋게 해서 많은 경험이지 속된 말로 '닥치는 대로 프로그램을 짜보라'고 권하는 것이다. 아무리 프로그램이 작더라도 직접 작성해 본 것과 그렇지 않은 것은 매우 큰 차이가 난다. 작은 연습 프로그램을 많이 작성해 본 사람은 큰 프로그램도 잘 짜기 마련이다. 큰 프로그램도 결국은 작은 모듈들의 집합이기 때문이다.
경험을 늘리는 방법 중 하나는 다른 사람이 작성해 놓은 예제를 분석해 보는 것도 좋은 방법이다. 하지만 반드시 그리고 정말 중요한 것은 예제를 분석하는 것에 그치지 말고 스스로 비슷하거나 진보된 예제를 작성해 보라고 권하고 싶다.
필자가 2000년 말 닷넷과 C#을 처음 접한 이후로 지금까지 작성한 예제 코드들이 수백 가지이며 7만여 라인이 넘는다면 믿겠는가? '믿거나 말거나'지만 필자는 이렇게 많은 코드들을 작성해 보면서 닷넷 플랫폼과 C#이라는 언어를 이해할 수 있게 됐다. 독자들은 어떠한가?
필자는 왜 이렇게 프로그래밍 경험을 중요시할까? 경험에 관련된 필자의 한 후배 이야기를 하고자 한다. 필자의 한 대학 후배는 대학교에 들어와 처음으로 프로그래밍을 시작했다. 상당히 성실했고 머리도 매우 좋아 프로그래밍을 빠르게 배워나갔다. 필자가 보기에도 짧은 기간에 빠르게 프로그래밍을 배우는 것 같았다.
하지만 그 후배는 프로그램을 작성하다 예상하지 못한 문제에 부딪히면 그 문제를 해결하는데 상당한 시간을 소비하고 있었다. 후배가 부딪힌 문제들은 대개 경험 많은 개발자라면 손쉽게 해결할 수 있는 것이었다. 여기서 프로그래밍 경험의 차이가 조금씩 나타나기 시작했다.
그 후배는 프로그래밍을 배운지 얼마 안되 어느 경지에 이르게됐지만 그 경지 이후부터는 성장이 크게 둔화됐다는 것이다. 그 이후의 고급 프로그래머 나아가서 컨설턴트가 되기까지는 많은 경험을 요구하고 있었던 것이다. 짧은 기간에 그러한 경험을 쌓기는 아무래도 무리가 있었나보다.
비단 프로그래밍이 아니더라도 어느 경지까지는 학원이나 도서나 다른 사람의 도움을 통해 열심히 공부해 다다를 수 있다. 그 이후부터는 부단히 많은 경험을 쌓아가면서 다듬는 과정이라 할 수 있다. 경험은 곧 실력과 연결되며 그것은 곧 프로그래머로서의 자신의 가치를 높이는 일이다.
경험을 쌓아가는 좋은 방법은 실제적인 코드를 작성해 보는 것이다. 실제 프로젝트가 있다면 매우 좋겠지만 항상 그럴 수는 없을 것이다. 또한 자신의 관심사와는 다른 프로젝트를 수행할 수도 있을 것이다. 이럴 때에 수십 라인에서 수백 라인정도의 샘플들을 작성해 보는 것은 자신의 경험을 축적하는 좋은 방법이 될 것이라 필자는 생각한다.
한 기술에 정통하려고 노력하자
보다 넓은 경험 외에 한 가지 더 추천하고 싶은 것은 한 가지를 깊이 파고들라고 권하고 싶다. 한 가지 기술에 정통한 사람은 다른 기술에도 쉽게 적응할 수 있다. 대부분 기술들의 뿌리가 비슷하거나 같기 때문이다. 이 규칙이 가장 잘 적용되는 것은 아마도 프로그래밍 언어 분야일 것이다. 한 가지 언어에 정통한 사람은 다른 프로그래밍 언어도 쉽게 배운다.
그것도 초보적인 수준이 아닌 고급 수준에 쉽게 다다를 수 있다. C++에 정통한 사람은 델파이에서 사용하는 오브젝티브 파스칼(Objective Pascal)을 어렵지 않게 습득할 수 있다. 비슷하게 자바에 정통한 사람 역시 C#, 오브젝티브 파스칼 등의 언어에 쉽게 접근할 수 있다. 이유는 프로그래밍 언어들의 기저에 깔려 있는 기술·사상·구현이 서로 비슷하기 때문이다.
프로그래밍 언어뿐만 아니라 분산객체 기술 역시 한 가지 기술에 정통하면 나머지 역시 어렵지 않게 접근할 수 있다. 분산 객체의 기본 사상이 서로 비슷하기 때문에 한 가지 기술을 마스터한 사람은 자기가 알고 있는 기술과 배우고자 하는 기술의 차이점 위주로 지식을 습득하기 때문에 시간을 절약할 수 있다.
게다가 한 기술을 마스터 하면서 쌓은 노하우와 경험은 대부분 새로운 기술에도 비슷하게 적용될 수 있기 때문에 빠른 시간에 고수 반열에 오를 수 있는 것이다. CORBA 고급 엔지니어와 COM 고급 엔지니어가 의사 소통하는데 별다른 어려움이 없는 것은 이런 맥락에서 풀어볼 수 있겠다.
필자는 98년부터 지금까지 COM에 대해 공부하고 실제 프로젝트를 수행해 왔다. 이제 COM 컴포넌트나 액티브X 컨트롤을 만드는 일은 C++, VB, 델파이 등의 다양한 언어로 작성할 수 있게 됐고 다양한 분야에 COM 기술을 응용할 수 있게 됐다. 그리고 1년 전에 등장한 새로운 기술인 닷넷으로 이전하는 데는 그다지 긴 시간을 요구하지 않았다. COM이나 닷넷의 뿌리가 비슷했기 때문이다.
현 세대의 IT 기술은 세분화돼 있으며 정말 다양한 분야가 존재한다. 그리고 많은 기술들의 깊이는 수년에 걸쳐 상당히 심화돼 있다. 개인이 이렇게 다양한 분야의 기술을 모두 정통할 수 없을 것임은 너무도 자명하다. 그렇다면 한 가지 기술을 마스터할 정도로 깊숙이 파고드는 것은 중요하다고 볼 수 있다.
물론 모든 것을 다 할 수 있다면 금상첨화겠지만 그렇게 할 수 없기에 한 가지만이라도 깊숙하게 그 기술을 파고들라는 것이다. 남들이 대부분 알고 있는 정도를 내가 알고 있다면 그것은 그 기술을 심화했다고 할 수 없다. 내가 알고 있고 자유 자재로 남들에게 설명할 수 있는 내용이 다른 사람들이 잘 모르고 있다면 그는 어느 정도의 수준에 올랐다고 볼 수 있을 것이다.
한 가지 기술을 파고들어야 한다면 어떤 기술을 파고들어야 할까? 닷넷인가? 자바인가? 아니면 새로운 그 무엇인가? 만일 자바라면 자바에 대한 모든 것을 깊이 파고들 것인가? 아니면 JSP, EJB 등의 세부 분야에 대해 파고들 것인가? 이것이 선택의 갈림길이며 어려운 부분 중에 하나이다. 이 선택은 순전히 독자들의 몫이다. 기술이 지금까지 발전돼 온 방향과 앞으로 발전 방향을 고려하며 자신의 진로 역시 고려해야 할 것이다. 다만 현재 상황으로 C#과 자바 중 어느 것을 선택하더라도 향후 몇 년 동안 후회하지는 않을 것 같다.
원리를 파악하자
마지막으로 독자들에게 권고하고 싶은 사항은 원리를 파악하라는 것이다. 원리를 파악하는 것만큼 중요한 것은 없다. HTTP의 원리나 TCP/IP의 원리를 모르고 ASP나 JSP를 코딩하는 것과 알고 코딩하는 것은 많은 차이를 드러낸다. 원리를 알고 코딩하는 사람은 다양한 응용이 가능하며, 문제가 발생했을 때 그 문제의 원인이 무엇인지 빨리 알아내고 해결책 역시 빨리 찾아낼 가능성이 높다.
반면 원리를 잘 이해하지 못한 사람들은 응용은 둘째치고 문제가 발생하면 문제의 원인조차 파악해 내지 못하는 경우가 많다. 기초를 건실하게 다져가면 새로운 기술들이 등장하더라도 빠르게 대처할 수 있다. 앞서 제시한 한 가지 기술을 깊게 파고드는 것과 비슷한 맥락으로 한 기술을 깊게 파고들면 그 원리를 터득하게 되는 것은 당연한 결과로 볼 수 있겠다.
그렇다고 지금부터 운영체제·컴파일러·TCP/IP 네트워킹 원리를 공부하라는 얘기는 아니다. 자신이 사용하는 기술을 단순히 '사용'하는 방법만 아는데 그치지 말고 '그 원리가 어떤 것일까'라는 호기심을 갖고 알아보라는 얘기다. ASP 개발자라면 HTTP라는 것이 어떤 프로토콜인가 한번 찔러 보고, HTTP가 TCP/IP를 사용한다던데 하면서 TCP/IP도 한번 찔러 보라는 얘기다. 이런 식으로 원리를 파악하려고 자주 시도하고 실제로 원리를 파악해 내는 것이 중요하다. 원리만을 위해서라면 다시 학교로 돌아가야 할 것이다.
지금까지 필자는 경험을 바탕으로 프로그래밍에 대한 몇 가지 이야기를 소개했다. 황당 에피소드라는 제목 하에 정말 황당한 이야기를 재미있게 했어야 하는데 필자의 글발로는 무리가 있었던 것 같다. 아무쪼록 프로그래밍의 고수가 되는 길은 자신의 부단한 노력과 상당한 시간이 필요함에는
Posted by Dual
