이론 vs 구현 "대한민국에는 소프트웨어가 없다"

지인이 어떤 책을 하나 읽어보고 내용이 필드와 비슷한지 아니면 거리가 있는지 평해달라고 했다.
책 제목은 "대한민국에는 소프트웨어가 없다"였다. 이 책의 저자이신 김익환씨는 안철수 바이러스 연구소에 근무했던 컨설턴트로서 꽤 네임밸류가 있는 분이다.

대한민국에는 소프트웨어가 없다 카테고리 경영/경제 지은이 김익환 (미래의창, 2003년) 상세보기

* 책의 포인트

1. 한국의 IT는 사상누각이다. 제대로 된 전문인력이 없기 때문이다.
   제대로 된 전문인력이란 언어(영어), 문화(협업), 이론적 지식, 스킬or테크닉이 있어야 한다.
2. 한국은 개발단계와 소프트웨어에 대한 이해가 부족하다.
   소프트웨어는 코딩이 중심이 아니다. 한국은 가장 중요한 설계나 준비과정이 보스(관리자)에게 무시당한다.
3. 설계가 간과되는 소프트웨어 개발은 소프트웨어라 부를 수 없다.
4. 근본적인 문제는 잘못된 SI 업계 관행(구현에만 집착) 때문이다.
5. 단순 구현(모로가도 서울만 가면 된다는 식)에만 집중하게 되면 개발 노하우가 쌓이지 않는다
6. 소프트웨어 개발 방법론을 제대로 아는 사람이 부족하다.

책에는 다른 내용도 많지만 전체 맥락에서 중요한 포인트는 위와 같다. 본인도 책에서 지적하는 점을 공감한다. 실제로 전반적인 내용이나 지적하는 상황이 현실과 어느정도 일치한다고 생각하기 때문이다. 그렇다고 이 책이 담고 있는 내용이 업계의 탑 시크릿이라고 말할 정도는 아니며 소프트웨어 업계 종사자라면 누구나 공감할만한 수준이다.(그래서인지 업계 종사자라면 굳이 이 책을 보지 않아도 될 것 같다.) 

따라서 내 생각으로는 읽어서 나쁠 것은 없지만 꼭 필독할 수준은 아니라고 생각한다.

---

* 비공감하는 내용들

1. 개발방법론에 대한 환상
다만 "대한민국에는 소프트웨어가 없다"라는 것에 공감하긴 해도 세부적인 내용에서 약간 의구심을 가지게 하는 부분이 있다. 그것은 바로 개발방법론에 대한 과도한 환상이라는 것이다.

개발 방법론은 대규모 프로젝트에서 프로젝트 관리를 위해서 나온 것이다. 그런데 최근에는 너무 정형화되면서 오히려 프로젝트를 과도하게 옭아맨다는 소리까지 나온다. 심지어 개발방법론을 빗대어 "프로크루스테스의 침대"라고 말하는 사람도 있다.
(프로크루스테스는 나그네를 잡아다가 침대보다 길면 긴 부분을 자르고, 짧으면 늘여서 맞추는 억지를 부린 것을 말한다.)

 그럼에도 불구하고 개발방법론이라는 환상이 이렇게 오랫동안 매료시키는 이유는 자명하다. 바로 이전에 개발방법론을 적용하여 프로젝트를 성공(?)시킨 경험을 하면 이 맛에 들려서 어떤 프로젝트나 문제가 나와도 자신이 알고 있는 "개발방법론"이라는 침대에 억지로 자르든 늘리든 해서 넣어버린다. 그 결과 심각한 오류를 발생시키기도 한다. (대부분의 오류는 과도한 오버헤드나 구현된 프로젝트가 비정상적으로 성능이 하락하는 경우다.)

그렇다면 개발방법론은 쓸모가 없는 것이냐? 아니다, 매우 중요하다. 그런데 왜 이 글을 쓰는 블로그 주인장은 개발방법론에 대해서 환상을 가지지 말라고 헛소리를 하는 것이냐고 반문할 수 있을 것이다.

나는 개발방법론 자체는 매우 훌륭하고 좋다고 생각한다. 다만 제대로된 인력구성이 되었을 경우에만 좋다고 생각한다. 역으로 말하면 한국의 프로젝트는 개발방법론이 문제가 아니라 실제로 구현하는 프로그래머(라고 쓰고 노가다꾼, 혹은 코더라고 읽는다.)들 때문이라고 본다. 왜냐하면 대다수 코딩은 비전공자나 비숙련 프로그래머가 하기 때문이다. 물론 개발방법론에는 이미 인력구성을 제대로 했다는 가정이 들어가는 경우도 있으므로 인력구성이 잘못된 것은 개발방법론이 실패일 수도 있다. [쓰다보니 클린턴의 "문제는 경제야, 이 바보야 (It's The Economy, Stupid!!)"가 생각난다. 그래서 난 이렇게 말해주고 싶다.]

It's the Programmer, Stupid(Stupid는 본인 의도는 아니고 패러디하다보니...)!!!

2. 객체지향에 대한 환상
그리고 책의 뒷 부분에는 객체지향에 대해서 환상을 가지고 있는 부분이 있다. 모든 개발은 객체지향으로 개발되어야 한다는 것처럼 들리기까지 한다. 그렇다면 정말로 객체지향만이 답일까?

우선 객체지향의 정의에 대해서 생각해보자. 간혹 객체지향하면 그냥 막무가내로 추상화(Abstraction), 다형성(Polymorphism), 캡슐화(Encapsulation)이라고 말하는 사람들이 있다. 물론 답으로 친다면 맞다. 근데 그게 뭔데?라고 물으면... 그냥 reset되는 경우가 많다.

객체지향의 환상에서 헤어나올려면 왜 객체지향이 나왔는지 배경부터 알아야 한다. 원 주제와 동떨어진 이야기이긴 하지만 과거 프로그래밍은 사람보다 더 빠른 계산기로서 공학계산을 목적으로 했기에 절차적인 순서를 빠르게 처리하는게 목적이었다. 그래서 구조적 프로그래밍(Structured Programmin)이 효율적이었다.

그러나 80년대부터 기업정보를 처리하는데 데이터베이스가 도입되고 이는 데이터에 어떤 행위(behavior)를 가하여 원하는 데이터를 뽑고 처리하는 기법이 주가 되었다. 그러다보니 구조적 연산보다 데이터를 변경하는 필터링 기법이나 클러스터링한 데이터를 처리하는 창구형태가 필요하게 된 것이다. 그래서 데이터와 행위를 결합한 프로그래밍 형태인 객체지향이 빠르게 기업 데이터베이스 시장에서 최강자가 된 것이다. (이 이야기만 해도 매우 길기 때문에 자세한 이야기는 나중에 따로 포스팅하든지 해야 겠다.)

그래서 결론부터 놓고 보자면 객체지향은 SI 같은 비지니스 데이터를 통합하는 프로그래밍이나 데이터와 행위에 중점을 두는 형태(e.g. GUI 프로그래밍)에 매우 좋다. 그러나 그 외에 공학계산이라든지 데이터 통신 등과 같은 분야에서는 아직도 구조적 프로그래밍(Structured Programming)의 형식이 효율적이다.(따라서 SI에서도 통신이 발생하는 부분까지 객체지향으로 만들면 오버헤드나 여러 구조적 문제가 생길 수 있다.)

그러므로 뭐든지 객체지향이라는 형태에 Lock-in되는 것은 바람직하지 않다. 즉 프로그래밍이란 목적에 따라 방법론이나 프로그래밍 스타일, 언어가 바뀔 수 있다는 유연한 자세를 가지는 것이 더 좋다. 만일 지금 본인이 한 가지 방법론이나 언어만 고집하고 있다면 좀 더 넓은 시야를 가지기 바란다.


3. 이론/설계에 대한 지나친 환상
책에서는 설계(design?)의 중요성에 대해서 말하고 있다. 물론 설계는 중요하다. 그런데 코딩은? 코딩은 안 중요한가?

한국에서는(물론 외국도 비슷하다) 코더(coder)라고 하면 좀 비하하는 면이 강한데, 개나소나 하는 "Hello world" 같은 코딩을 할 때는 비하해도 되겠다. 하지만 퍼포먼스와 보안등을 고려해서 작성하는 코딩은 비하하기엔 너무 큰 스킬을 필요로 하기에 코더가 하는 일이라고 치부하기엔 좀 그렇다.

따라서 "개발코딩=단순작업"이라는 명제를 참으로 만드려면 지금 어떤 작업을 하는가부터 알아야 한다.

사실 나도 학교에 있을 때는 이론과 디자인(설계)이 중요하고 코딩이야 그냥 아무나 시키면 된다는 생각을 가진 적이 있었다. 그거 바로 소프트웨어공학을 배울 쯔음이었던 것 같다. 당시에 담당 교수가 그렇게 말하니 생각없던 나 같은 학생은 그냥 그런가 보다하고 받아들였다.

그런데 사회에 나와서 이런저런 일들을 겪다보니 이론과 구현의 갭을 알게되었고, 설계파트가 실무/구현방법에 대한 세부사항을 잘 모르고 진행될 때 어떤 재앙을 불러오는지 목격하게 되었다. 그리고는 코딩이란 매우 중요하다는 것을 깨닫게 되었다. 그래서 지금은 소프트웨어공학 교수의 말은 그 교수가 프로그래밍 실력이 젬병이라서 자기변명을 위해 한 말이 아니였을까 생각해본다.(실제로 코딩하는 것을 본적은 없었다.)

그러면 다시 원래 이야기로 돌아와서 코딩이 별것도 아닌 작업이라면 좋은 설계만 있다면 개나소나 다 할 수 있을까?

답부터 이야기 하자면 "No"다. 왜냐하면 이론만을 중시하여 코딩을 전혀 해보지 않은채 설계를 하다보면 이런저런 곳에서 계속 막힌다. 마치 영어 참고서를 보고 영어를 배웠을때 실제 생활과 동떨어진 언어를 구사하게 되는 것처럼 말이다. 마찬가지로 한글 교과서에 나온대로 "~습니다."로 끝나는 말을 대화체에서 쓰는 사람은 없는 것처럼 말이다.

그리고 또하나 우리가 사용하는 윈도우즈나 리눅스도 설계는 따로하고 코더들이 삽질을 해서 탄생한 것일까? 스프레드쉬트의 최강자인 MS 오피스 엑셀은 설계자와 코더가 따로 있을까?

상상은 본인들에게 맡기겠다. 다만 해줄 수 있는 말은 플라이트 시뮬레이션 게임만 한 사람은 절대로 제트기 파일럿이 될 수 없다는 점이다.


* 결론

이론 vs 코딩, 둘 중에 어느 것이 더 중요할까?

정답은 둘 다 중요하다. 이론 몰라서 삽질하거나 코딩을 못해서 삽질하거나 삽질하는 것은 매 한가지니 말이다.

음악에 비유하자면 이론은 작곡이나 곡을 이해하는 능력이고, 코딩은 연주하는 스킬이라고 보면 된다. 좋은 작곡자가 연주를 아예 못한다든지 초보수준인 경우는 없다. 마찬가지로 좋은 연주자는 어느정도 이론적인 부분도 알게된다. (물론 간혹 괴물같이 한쪽에 너무 뛰어난 재능을 받는 경우도 있으나 exception을 일반화하지는 말자.)

그런데 이론은 공부라지만 코딩은 연주 스킬처럼 반복 연습과 좋은 곡을 청취함으로서 다져지는 것이다.