프로그래머는 모든 소스를 새로 짜야 할까?
프로그래밍 언어를 처음 배우게 되면 생전 경험해 보지 못한 낯선 “문법”을 보게 된다. 고등학교 수학 시간에 배웠던 것을 넘어서 낯선 “논리 연산” 이나 “조건문”, “진법” 등을 다루게 되는게 이런걸로 프로그래밍을 한다니 머리가 아플 뿐이다.
어떻게~~어떻게 해서 문법을 어느정도 뗐다고 해도 문제는 프로그램을 어떻게 짜느냐는 것이다. 필자가 대학때 전공과목 수업시간에서 “C언어 기초”를 수강했던 시절에 C 문법을 어느 정도 배웠을때 교수님이 내준 프로그래밍 과제를 가지고 어떻게 짜는 건지 무척이나 고민했던 순간이 떠올려진다.
특정 프로그램에 대해서 “~이렇게 짜시오” 라고 낸 과제에 무엇부터 시작해야 할지 감이 오질 않았다. “변수, 상수, 함수의 개념은 배웠는데 과연 이걸 어떻게 프로그래밍을 하는데 활용을 하지?” 라는 생각밖에 들지 않았다. “아… 난 프로그래밍의 재능이 없다 보다..” 라는 탄식과 함께 인터넷을 열심히 뒤져서 소스를 대략 복사한 후에 과제에 맞게 수정하여 제출했다. 그렇게 나의 학창시절은 프로그래밍과 궁합이 맞질 않았다.
여기서 궁금해 지는 것이 있다. 필자의 경우처럼 프로그래밍을 처음 접하는 학생들이나 사람들은 과연 프로그램을 어느 목적에 맞게 아예 새로 짜야 되는 것일까? 만약 소프트웨어 기업으로 새로 취업을 한다면 학교 수업과 마찬가지로 팀장이나 관리자가 지시한 프로젝트의 소스 코드를 아예 처음부터 새로 짜야 되는 걸까?
프로그래밍 초보자들의 공포
나같은 경우에도 대학 시절에 “C언어” 를 다뤄본 후 프로그래밍이 적성이 맞지 않음을 깨닫고 다른 분야로 진출했지만(하드웨어) 회사의 정책상 과감하게 소프트웨어 프로그래머로 전향을 한 케이스다. 만약 그렇게 전향을 하지 않았다면 여전히 회사에서 하드웨어 개발을 하고 있었을 수도 있다.
프로그래머 생활을 하기 직전까지만 해도 “소프트웨어” 라는 것은 어렵고 공포스러운 존재였다. 처음부터 프로그래머가 일일이 소스 코드를 짜야 한다면 그거 만큼 정신적으로 스트레스를 받을 께 뻔하기 때문이다. 그러면서 “박봉”을 주는 프로그래머들은 그닥 매력적이지 않은 직업으로 치부했다.
하지만 프로그래머 전향후 경력을 이어 가면서 그동안 느꼈던 공포는 나의 오해였음을 깨닫게 되었다.
회사에서 프로그래밍을 해보니 프로그래머가 소스 코드를 완전 새로 짜는 경우는 눈에 꼽을 만큼 흔하지 않은 경우다. 특히 우리나라 같이 응용 분야가 발달했으면 더더욱 그렇다.
이게 무슨말일까? 우리나라가 응용 분야가 발달했다니? 사실 우리나라의 IT 산업은 “원천 기술”을 개발하여 공급하는 경우는 극히 드물다. 일례로 “오픈소스”의 경우에도 대부분 해외의 프로그래머들이 참여한 프로젝트의 소스코드를 그대로 가져다 쓰는 경우가 허다하다.
즉 소프트웨어 산업에서도 “솔루션 기업”들은 국내에서 거의 없다는 얘기다. 주로 서비스를 운영하는 IT 서비스 기업들과, SI(시스템 구축), IT 제조업 등은 대다수가 오픈소스를 그대로 사용하거나 해외의 솔루션을 사다가 쓴다.
어느정도 잘 동작하고 검증된 소스 코드를 들여와서 프로그래머들이 제품의 목적에 맞게 “커스텀(Custom)” 작업을 하는 것이다. 어느 공장에서 해외의 목재를 수입해다가 가공하여 제품을 만드는 것과 같은 이치다.
따라서 국내의 “프로그래머”들은 처음부터 소스코드를 짤 일이 그리 많지 않다는 것이다. 필자의 경우에도 리눅스 기반의 시스템을 개발했는데 리눅스는 오픈소스를 많이 활용할 수 있으므로 오픈소스를 활용해서 소스 코드를 수정 작업을 통해 제품을 개발했던 것이다.
그래서 프로그래머들은 소스 코드를 새로 짜기 보다는 오픈소스나 구입한 소스를 적절히 커스텀 작업이나 패치하는 것에 많이 할당이 된다. 따라서 기존의 소스를 잘 이해하여 시스템이 버그가 없이 잘 돌게 하는게 임무라고 볼 수 있다.
프로그래밍을 시작할 때는 남의 것을 배껴라
그렇다. 프로그래밍을 처음 시작하거나 시작한지 얼마 안된 사람들은 프로그래밍을 가장 빨리 익히는 방법은 “남의 소스”를 열심히 따라하는 것이다.
위 글은 필자가 코드도사 사이트에 “코딩을 빠른시간 내에 익숙해지게 하는 방법”에 대해 기술해 놓은 것이다. 자세한 내용은 위 링크 글을 들어가서 확인해 보면 되겠지만 “열심히 따라” 하는 게 핵심이다.
프로그래밍을 많이 해보지 않은 사람이라면 필자가 대학 시절에 느꼈던 대로 문법은 익혔더라도 “어떻게 짜야” 하는지 도통 감히 잡히지 않는다. 경험이 없는 이는 “매우” 당연하다. 이럴 때는 프로그래밍에 대한 감을 익혀야 하는데 감을 익히는 가장 좋은 방법은 “예제를 많이 보고 직접 타자를 치면서 컴파일을 해서 실행을 해보는 것”이다.
즉 많이 남의 것을 따라해보고 소스 코드를 배껴보는게 프로그래밍의 감을 익히는데 많은 도움이 된다. 프로그래밍이라는 것이 “창의” 적인 부분은 명백하지만 아예 백지 상태에서 창작을 할 수 있는 천재적인 능력자들은 현실에서는 그리 많지 않을 것이다.
따라서 일반적인 사람이라면 프로그래밍을 할때 최대한 다른 사람의 소스를 참고하면서 응용하고 수정하는 작업이 필요하다. 그리고 실제로는 현업에서 소스 코드를 처음부터 새로 짜는게 아닌 오픈소스를 활용하던지 솔루션을 사서 그걸 토대로 소스를 수정하여 제품을 개발하는게 일반적이다. 그러므로 초보나 신입 프로그래머들은 그런 부분에 대해 크게 걱정할 필요는 없다.
그렇다고 하더라도 기본적인 프로그래밍 능력을 갖춰야 함은 분명하다. 아무리 다른 사람의 소스를 수정하여 응용한다고 해도 기본 스킬이 있어야 소스를 수정하는게 가능하기 때문이다. 또한 실제 업무를 하다보면 제품의 어느 한 부분은 완전히 새로 짜야 할 부분이 분명 생기기 때문에 기본적인 스킬은 반드시 갖춰야 할 것이다.
복제는 창조의 어머니
1990년대 가요계는 종종 “표절”로 인해 핫 이슈가 발생하기도 했다. 그 대상은 아이러니 하게도 당시에 가장 인기 있었던 가수들이다.
당시만 해도 음반 판매가 주 수익원이었기 때문이었을까? 음반을 오래 판매하려면 어떻게든 오랬동안 인기 유지가 필수였는데 그렇게 하기 위해서는 빠른 시일내에 곡을 출시하는게 급선무였을 것이다. 또한 인기 가수인 만큼 인기 유지에 많은 스트레스를 받았을터… 해외의 곡을 표절하여 음반을 출시하는 일이 꽤 있었던 듯 하다.
음악이나 미술, 즉 예술쪽은 “표절”에 꽤 민감한 편이다. 새롭게 창의적인 작품이 사람들에게 인정을 받고 주목을 받는다. 누군가가 해놓은 작품의 일부분만 배껴도 가치있는 작품으로 보지 않는다.
하지만 “소프트웨어”는 그렇지는 않다. 오히려 “표절”을 권장하는 편이다. 인터넷 상에 올라와있는 수많은 “오픈소스” 들과 예제들을 프로그래머들에게 공개를 해놓고 있다. 과거 2000년대 이전까지 소스코드를 비공개 해왔던 정책과는 완전 대조적이다. 이제 “오픈소스”는 대세이며 유명 기업일수록 잘 만들어진 오픈소스를 출시하는게 거의 기본으로 되다 시피 하고 있다.
게임계의 전설인 “존 카멕”이 출시한 여러 명작 게임들이 있는데 그 중에서 가장 돋보이는 게임은 “퀘이크”다. 그런데 이런 잘만든 상용 게임들을 존 카멕은 과감히 “오픈소스”화 시켜버리는 결단을 내려버린다.
“퀘이크 3” 출시 당시만 해도 3D 그래픽이 뛰어난 명작 게임이었는데 이 게임을 오픈소스로 공개해버린 존 카멕이 이해가 되지 않았지만 이런 그의 정책으로 인해 더 유명해지는 계기가 되었다. 또한 “퀘이크 3″가 오픈소스로 공개되자 “퀘이크 3 엔진”을 기반으로 한 3D 액션 게임들이 여기저기서 출시된다. 존 카멕의 오픈소스화가 게임업계를 한층 더 발전시킨 것이다.
물론 일반 사람들의 눈으로 봤을때는 한편으론 “창의적”이지 못하고 남이 짜놓은 소스를 활용하는게 소프트웨어 기술 발전에 도움이 되냐고 되묻기도 한다. 거기에 대한 대답은 당연히 “예”다.
소프트웨어는 음악, 미술 등의 예술과는 거리가 멀게 보이지만 실제로는 매우 “창의적인” 작업 중 하나이다. 같은 기능을 구현하더라도 열사람이 짠 코드는 절대 서로 같을 수 없다.
그만큼 소프트웨어는 지구상에 사람들이 단 한 사람이더라도 성격이 다르듯이 그 사람의 성향을 따라간다. 물론 비슷한 코드가 만들어질 수는 있지만 완전히 같을 수는 없다. 이렇듯 소프트웨어 코드는 사람의 성향마다 천차만별이라고 볼 수 있다.
그런데 오픈소스 같은 다른 사람이 짠 소스를 활용하는게 기술 발전에 도움이 된다니 무슨 소리일까? 여기서 중요한 것은 다른 사람이 “잘 짜놓은” 코드라는게 전제가 되어야 하는 것이다.
잘 짜놓은 코드는 여러 종류가 있을 수 있지만 몇가지 예를 들어보면 이렇다.
- 버그가 발생하지 않고 잘 동작하는 코드
- 프로그램이 중간이 죽지 않고 안정적으로 동작하는 코드
- 성능이 뛰어나고 가벼운 코드
- 남들이 쉽게 잘 알아보고 이해할 수 있는 코드(물론 전제는 버그가 없고 죽지 않는 코드)
위의 예처럼 잘 짜여진 코드는 “재활용”을 하기에 수월하다. 버그가 없고 안정적으로 동작하면 그만큼 활용 가치가 높은 코드인 것이다. 실무에서 이런 코드들은 비용과 시간을 절약해준다. 특히 실무자인 프로그래머들에게는 이런 코드들을 짜는게 목표일 수 있다.
잘 짜놓은 코드인 유명 오픈소스들은 그래서 활용가치가 높은 코드이다. 경험이 많지 않는 프로그래머들은 이 소스들을 잘 분석해서 내것으로 만든다면 스킬 발전에 많은 도움이 될 것이다. 또한 이 소스들의 스타일을 잘 익혔다가 나의 코딩 스타일에 적용시킨다면 그만큼 자신의 발전에도 도움이 되는 것이다.
십몇년동안 프로그래머로 생활하면서 사실 큰 프로젝트에서 새로 짠 코드는 그리 많지 않다. 기능 구현상 필요한 일부 코드는 새로 짠 적이 꽤 있지만 대부분 오픈소스를 활용하거나 기존에 짜여 있는 소스들을 활용한 적이 많다. 그렇지만 최근에 드는 생각은 나 스스로가 아예 처음부터 코드를 짜보고 싶은 “목표”는 가지고 있다. 그런데 그게 언제 이루어질지는 아직 기약은 없다.
코딩 경험이 없는 프로그래머들이 학생들에게 가장 스킬을 높일 수 있는 빠른 방법은 “남이 짜놓은 소스를 열심히 배껴서 분석” 하는 것이다. 그리고 그 것을 내것으로 만들면 금상첨화일 것이다.
초보자들이여 당신이 실력을 향상시키려면 당분간 열심히 남이 짜놓은 코드를 배껴라!!