Skip to main content

사라진 즐거움을 찾아주시겠습니까?

며칠전에 소프트웨어 컨플릭트 2.0라는 책을 읽었습니다. ((로버트 L. 클래스)) 내용들이 다 유익했지만 특히 다음 장이 기억에 남네요.

사라진 즐거움을 찾아주시겠습니까?

이 장은 왜 예전에는 소프트웨어 개발이 재미있었는데 시간이 흐를수록 그렇지 않은가에 대한 내용입니다. 저자가 생각한 이유는 다음과 같았습니다.


  1. 고용주가 30년 경력 개발자를 너무나도 귀중하게 여긴 나머지 프로그래밍을 맡기지 않는다.

  2. 프로그래머가 지쳐 나가 떨어진다.

  3. 나이를 먹을수록 꼬장꼬장하게 변한다.



그런데 이 에세이를 읽은 독자가 아래와 같은 답장을 써서 보냈다네요. :-)

"엎질러진 물은 담을 수 없다"는 옛말이 있듯이, 꿈도 꾸지 마세요. 현실을 직시합시다. 업계는 우리 같은 늙은이를 반기지도 않는데, 우리는 몸값이 너무 비쌉니다. 또한 우리가 봉급을 적게 받아도 좋다고 말하면, 업계 사람들은 우리 실력이 떨어졌다고 여깁니다. 어느 쪽이든 지는 경기이므로 불가피한 현실을 받아 들여야만 하겠죠."

.
.
.

한해씩 나이를 먹다 보니 저런 얘기가 남의 얘기로만 들리진 않더군요. 그나마 책의 저자는 자신이 관리직으로 갈지 개발직으로 갈지 결정할 수 있어서 학계로 가기 전까지 개발직에 끝까지 남았다고 합니다. 저도 언제까지나 개발직에 남기를 원하지만 우리나라에서도 저런 선택이 가능할진 모르겠네요. 물론 제 옆의 동료들만 보더라도 진심으로 프로그래밍을 좋아하는 사람이 아니면 빨리 진급해서 코딩하고 디버깅하는 저주받은(?) 작업을 안했으면 하는 사람들이 있습니다. 위 리스트의 2번에 해당하는 사람들이죠.

모 SI 업체에 근무하는 마눌님의 얘기를 들어보니 과장쯤 되면 더 이상 그사람이 코딩하고 있어서는 인건비가 나오지 않는다고 얘기하더군요. 결국 코딩같은 단순한 작업은 아무나 할 수 있다는 생각을 가지고 있는거겠죠. ((왜 사람들은 Code Complete를 읽지 않는걸까요? :-( ))

그래도 마눌님이 다니는 회사는 나름 S/W 업체라 그런지 관리직군과 개발직군중에 career path를 선택할 수 있다더군요. 개발직군들에게는 특정 기술을 깊이 파도록 유도해서 그 기술의 전문가로 키우는 제도인 것 같습니다.

그런데 정말 코딩이 그렇게 아무나 해도 되는 걸까요? 그 많은 요구 사항 분석과 설계와 문서들은 결국 다 코드를 만들기 위해선데 말이죠. ((역시 Code Complete에 있는 내용!)) 굳이 무슨 연구 결과들을 참고 하지 않더라도 제 경험에 따르면 잘하는 사람과 못하는 사람의 결과는 수배에서 수십배 차이가 나는 것 같습니다. 굳이 찾아보자면 생산성이 minus인 사람들도 있죠. (제발 저 사람은 코딩을 안했으면 하고 바라게 됩니다. 근데 혹시 이런걸 원했던 걸까요? :-? 참... 그리고 저희 팀엔 없어요. ;-) )

능력있고 경험있는 사람들이 관리직으로 가진 않는다 해도 코딩은 안하고 설계만 한다는 것도 문제가 있습니다. 설계만 보고 일대일로 코드를 만들어낼 수 없다면 결국 코드의 질은 코더에 많이 좌우될텐데 말이죠. 너무 코딩을 천시하는 경향이 있는 것 같습니다.

게다가 코딩이 제일 재밌는 단계지 않나요. (제가 원하는게 바로 이겁니다! 저한테 계속 코딩을 할 수 있게 해주세요~ ;-) )

한가지 더... 설계와 구현, 두 단계를 다른 사람이 혹은 다른 팀에서 하게 되면 둘 사이엔 의견 mismatch가 생길 수 밖에 없는 것 같습니다. 구현팀에선 설계를 정확히 이해하지 못하고 구현하는 부분이 생기게 되고 설계팀에선 자신들의 우아한 설계를 반영하지 못했다고 불평하고요. 게다가 설계에는 불가피하게 구현상의 detail이 빠질 수 밖에 없습니다. 둘 사이에 이런 어긋남이 쌓이게 되면 서로 신뢰가 떨어지고 결국은 서로 제 갈길 가는 형태가 되곤 하는 것이죠. ("넌 떠들어라. 난 모르겠다." - 구현팀, "난 완벽하다. 잘못되면 다 너네 잘못이다." - 설계팀)

따라서 설계와 구현은 같은 사람이 아니면 적어도 같은 팀에서 해야 하지 않을까 합니다.

.
.
.


저희 회사도 작년에 career path를 관리직군과 개발직군으로 나눠야 하나 같은 설문 조사를 한 적이 있는데 이후로 소식이 없네요. 한 십년쯤 지나면 선택할 수 있게 될지도 모르겠어요. 그나저나 사라져 가는 제 즐거움을 지키려면 어떻게 해야 할까요? :-|

Comments

  1. SI업체에서는 코딩을 폄하(?)할 수 밖에 없는 것 같습니다. -ㅅ- (그러면 안되지만요!)
    패키지(?)의 입장에선 많이 다르지요.

    (다행히 제가 있는 곳은 패키지 회사.. 에헤)

    ReplyDelete
  2. 코딩이 회사에 직접적인 금전적 이익을 가져다 주지 않는경우에 윗분들이 값을 좀 낮춰 보는 것 같습니다. 그리고 나 외에 대체 가능한 코더가 존재할 때는 값이 더 낮아지겠죠 ^^
    또한 코딩이라는게 특이하게도 초고수가 인공지능을 가미한 객체지향으로 짜든 쌩초보가 스크립트로 구조적으로 짜든 목적에 도달하는 방법만 알고있다면 그럭저럭 굴러가는 프로그램을 짤 수 있다는겁니다. 제가 로봇 분야에 있는데, 예를 들어보자면, 로봇이 장애물을 피해서 목적지까지 이동하는 코딩을 해야할 때 연구원들이 난관에서 헤어나지 못하는 이유가 훌륭한 코딩 기술보다는 주로 적절한 알고리즘을 구현하지 못하였기때문입니다.

    ReplyDelete
  3. 까막님/ 네, SI업체들은 수입이 전부 인건비에서 나오는 것이라 더 그런거 같아요. 그래도 까막님은 좋은 환경에 계시는 듯 하네요. :-)

    야옹/ (뭘 존댓말씩이나. 어색하게... -_-+) 그런 코더가 짠 코드가 그럭저럭 굴러간다면 1) 좋은 framework 위에서 시작했거나 (예를 들어 MFC만 있으면 누구든 적당히 굴러가는 Windows GUI 프로그램을 할 수 있는 것처럼. 이는 기본적으로 MFC가 Doc/View라는 나름 잘 짜여진 구조를 가지고 있기 때문이지.) 2) 규모가 크지 않은 경우가 아닐까?
    로봇 분야는 잘은 모르지만 이전의 단순하던 로봇에서 점점 복잡해질수록 프로젝트에서 소프트웨어가 차지하는 비중이 커질텐데 그럼 당연히 하드웨어 전문가나 알고리즘만 필요한 것이 아니라 소프트웨어 공학도 필요할듯... 그런데 문제는 소프트웨어 공학이 더 필요한 분야에서도 아직 그렇지 못하다는거지... -_-;

    ReplyDelete

Post a Comment

Popular posts from this blog

1의 개수 세기

저도 간단한 알고리즘 문제 하나... :-)

어떤 수 n이 주어졌을때 1~n까지의 수를 쭈욱 썼을때 나오는 1의 개수를 구하는 문제입니다.

예를 들어 13이라는 수가 주어지면 1~13까지의 수 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13에서 1은 1, 10, 11, 12, 13에 나오며 그 개수는 6이 됩니다. 즉, f(13)=6.

원래 문제는 f(n)=n이 되는 1이 아닌 가장 작은 수를 구하는 문제인데 이 문제의 경우에는 처음부터 쭈욱 세어나가면 되기 때문에 간단히 다음과 같이 구현을 하면 됩니다. ((한가지 주의할 점은 이전에 찾았던 n-1값을 사용하지 않고 다시 처음부터 n까지 값을 계산하면 시간이 너무 많이 걸린다는 점입니다. 위의 코드에서는 static 변수를 사용하여 이전 값에 계속 더해나가는 방법을 사용했습니다.))


#include

int count1(int n)
{
static int cnt = 1; // not 0 because n starts from 2. see main.

while (n > 0) {
if ((n % 10) == 1) ++cnt;
n /= 10;
}

return cnt;
}

int main()
{
using namespace std;

int n = 2;

while (count1(n) != n) ++n;
cout << n << endl;
}


좀 재미가 없죠? 그래서 이번 문제는 어떤 수 n에 대해서 f(n)을 O(1)시간에 구하는 알고리즘을 만드는 것입니다. 관심있으신 분들은 한번 풀어보세요. 제가 만든 코드는 내일 올려보겠습니다.

C++ of the Day #9 - Boost.Python 사용하기 #1

Python은 가장 인기있는 interpret 언어중의 하나입니다. Python의 장점 중 하나는 C/C++ 모듈과 쉽게 연동할 수 있다는 점입니다. 물론 손으로 일일히 wrapper를 만드는 것은 손이 많이 가고 에러를 만들수 있는 작업이나 SWIG등과 같은 도구를 사용하면 쉽게 python 모듈을 만들 수 있습니다.

Boost.Python은 이런 SWIG와 같이 python 모듈을 쉽게 만들 수 있도록 도와주는 라이브러리로 순수 C++만을 사용한다는 점이 SWIG와 다른 점입니다. 그리고 개인적으로는 Boost 라이브러리에 포함되어 있는 것들이 왠지 좀 더 믿음직스러워서... :-)

이번 글에서는 Boost.Python 문서에 나와 있는 예제를 가지고 간단하게 python 모듈을 만드는 방법에 대해서 알아보겠습니다.

Requirements리눅스
이 글에서는 리눅스 환경에서의 사용 방법을 설명한다.Boost.Python 라이브러리 (1.33.1)
Boost 라이브러리를 다운로드받아 아래와 유사한 명령으로 라이브러리를 빌드한다.
bjam -sTOOLS=gcc -with-python install

bjam의 --prefix 옵션으로 라이브러리가 설치될 위치를 변경할 수 있다.Python 라이브러리 (2.4.3)
Python을 다운로드 받아 빌드하여 설치한다.
위의 경우와 유사하게 configure의 --prefix 옵션으로 설치될 위치를 변경할 수 있다.

Write C++ Code다음과 같이 코드를 작성한다.

// greet.cpp #include <stdexcept> char const* greet(unsigned x) { static char const* const msgs[] = { "hello", "Boost.Python", "world!" }; if (x > 2) throw std::range_error("greet: index out of range"…

Hello Wordpress, again.

한 두주일 정도 Textpattern을 사용해봤는데 다시 Wordpress로 돌아오기로 결정했습니다. 무엇보다 스킨 변경이 너무 복잡하고 사용자층이 Wordpress에 비해 너무 앏네요. 원하는 plugin도 찾기 어렵고... :-|

그동안 Textpattern에 썼던 글들은 모두 Wordpress로 옮겼습니다. 2개 있던 댓글도 옮겼는데 그중의 하난 제가 쓴... ;-)

애초에 wp-dokuwiki plugin이 무거워서 옮겼던 것이라 이 plugin은 설치를 안할 예정인데 몇가지 아쉬운 점이 있네요.

첫째는 code highlighting 기능인데 이 기능은 예전에 만들어 놨던 것을 조금 수정해서 쓰려고 준비중입니다. 두번째는 Footnote 기능인데 찾아보니 Footnotes 0.9 Plugin for WordPress 2.0.x라는게 있네요.

이정도면 비록 wiki syntax에 비할바는 아니지만 쓸만할 것 같습니다. :-)