pen's miscellaneous pursuit of truth (bla blag)

결정적 증거!에 대한 기사를 보고 내가 생각한 진실은 이렇다.

(1) 북한에서 김덩일은 우찌 남한을 골탕먹일까 고민하다가...
폭발에도 지워지지 않는 파란색 매직의 개발을 명령한다.
... 북한의 과학자들이 밤샘과 혼신의 힘을 다한 결과 그 매직은 만들어진다.
마치 매직처럼... (엄청난 폭발에도 남아 있는 글씨에 과학자는 눈물이 났을 것이다.)

(2)
때를 노리던 김정일, 안도와주는 엠뷔정부를 엿먹이기 위해
'1번'이라 쓰인 어뢰로 남한의 함정을 침몰시키는데 성공한다.
그의 계획은 이것이었다...
어뢰의 잔재를 확인한 남한은 1번이라 생생히 써있는 글씨를 보고 북한것으로 추정할 것이다.
(설마 누가 장난을 치지는 않았을테니)
그러나 폭발한 어뢰에서 그것도 손으로 쓴 매직 글씨를 증거물로 내세울수는 없는법.
이러지도 저러지도 못하는 엠뷔는 분함을 못이기고 혈압이 올라 쓰러질 수도 있지 않은가.!

(3)
북한의 계획대로 어뢰의 잔재를 발견한 남한.
그러나 북한의 계획과는 틀리게 확신에 찬 엠뷔는 외친다.
'북한의 소행이란 결정적인 증거닷!!!'

(4)
김정일...' 이런 ㅆㅂ.. 설마.. 저럴줄이야'
.....
.....



ㅎ.. 쓰다만 글들도 많고만 이런글을 쓰게 하다니 .. 당신은 쵝오!!!
그게 사실이건 아니건 나는 정치적인 사람도 지나친 애국자도 아니다. 색깔도 회색에 가깝겠지...
그러나 먹고 살기 바빠 뉴스를 타이틀만 읽는 내가 ' 아 그랬대더라...' 라고 하다가
며칠뒤 그 신문기사를 클릭했을 때, 사진을 보고 얼마나 기가 막혔는지...
비전문가인 내가 백번양보해서 그게 '증거'라고 한들,
'결정적'이라고 이름붙인 당신들에게 하고 싶은 말은 한가지 뿐이다.

'그래서 좋은 국민학교를 나와야 혀...'

일반적으로 소프트웨어 개발 기업에는 Software Engineering에 대한 가이드 라인이 있다.
단계별 문서양식은 어떻고, 산출물은 어때야 하며, 코딩 스타일은 어때야 하고,
또 소스 관리나 문서 관리는 어떻게 해야 한다는 등이다.

일반적으로 지키라고 하면 괜히 하기 싫은게 우리다.
특히나 같은 부서가 아니라 '기준'을 만드는 부서에서 하는 말이라면 말이다.


최근 가게된 부서는 신규 사업팀이라 SE 부서가 없다.
그렇게도 지키기 싫어했던 개발 가이드들이지만 막상 강제성이 없으니 룰이 없으니 정작 필요한 것들에 대해서는 아쉬움이 생기더라는 말이다.

그래서 이 글에서는 소프트웨어 개발 프로젝트의 효율성을 높이기 위한 SE 요소를 경험에 비추어 이야기 하고자 한다.
어디까지나 비전공자의 글이므로 딴지는 사양한다. 조언은 감사하게 받아들이지만...

대강 이야기 하면...

다음 사항은 내가 일하거나 내와 함께 일하는 사람들이 지켜주길 바라는 내용이다.

하나. 코딩 스타일 통일

사실 코딩 스타일까지 이야기 하고 싶지는 않은 생각도 있다.
워낙 쓸데없는 자유를 좋아하는데다가, 코딩 스타일에 어느정도 개인적인 성향이 나타난다고 생각하기 때문이다.
(모 대기업같은 경우는 한 건물에서 일하는 소프트웨어 인원이 한 2000여명 된다고 생각된다. 이 사람들이 짠 코드가 다 한 사람이 짠것같다면... 웬지 좀 매트릭스스럽지 않은가.)

그러나 이러한 생각은 사실 한사람이 한가지 알고리즘을 맡는 특수성을 지니는 소프트웨어나 한 사람이 한 플랫폼을 담당하는 벤처에서는 별 문제없이 작동했다.
그러나 대기업에서 여러사람이 개발을 하고, 선배가 후배의 코드를 보며 (사실 그러는 경우는 거의 없다! ^^), 담당자가 자주 바뀌는 경우 문제가 발생한다.
남의 코드를 보기 싫어하기 때문이다. ('차라리 새로 짜는게 쉽다'라는 얘기들은 한번씩 들어봤을 것이다.)

다른 사람이 짠 코드를 누구나 쉽게 볼수 있게 하는게 코딩 스타일 통일의 목적이다.
흔히들 '가독성' (readibility)를 높인다고 고상하게 표현하곤 한다.

초심자는 자신의 코딩 스타일을 고집하거나, 특별한 코딩 테크닉을 쓰기도 한다.
더구나 코드를 공유하는 것을 싫어한다. (누가 감히 내가 짠 코드를 함부로 보는건 좀 건방지잖아?)
(나 역시 오랬동안 초심을 읽지 않았었다!!!)

그러나 통일성을 높여 공유를 할 수 있게 만드는게 결국은 좋다는 결론이다.
(내 경험에 비추어보면 회사에만 좋은 것이 아니다.
내가 부서를 옮길때도, 쉽게 도망갈 수 있다. 또, 다른 사람에게 일을 맡기고 휴가가기도 쉽다!!!)

둘. 개발 환경

대부분 통합 개발 환경은 컴파일러가 속한 툴에 의해 결정된다.
여기서 개발 환경이란 에디터, 컴파일러, 빌드 유틸리티, 프로젝트 관리 툴, 디버깅 툴들을 전부 이야기 하는 것이다.
예를 들어, 윈도우 어플리케이션을 개발할때는 MS Visual Studio를 쓰는 것처럼 말이다.
그러나 플랫폼과 CPU 아키텍쳐가 다양해지면 선택의 폭도 넓어진다.
또 메인 환경에 추가적인 툴을 사용하기도 한다.
(MSVS를 사용하면서도 코드 분석을 위해 추가적인 에디터로 source insight를 쓰는 것은 그다지 놀라운 일은 아니다.)

각각의 툴은 장단점을 가지고 있으나 개발자들간에 대략적으로 통일된 툴을 사용하는 것이 혼돈을 줄일 수 있다.
(예를 들어 GNU환경에서 누구는 make 사용을 좋아하고, 누구는 eclipse 프로젝트를 주로 사용한다면, 이 역시 서로간에 침범할 수 없는 영역이 될 확률이 높다.)
중요한 것은 사용 편의성과 범용성을 고려하여 가장 효과적인 툴을 사용하는 것이다.

셋. 버전 컨트롤 시스템

버전 컨트롤 시스템의 목적은 소프트웨어 변화의 역사를 기록하는 것이다.
이 기록의 필요성은 분명히도, 용이한 디버깅과, 여러사람의 공동 작업으로 이야기 할 수 있으나,
단순히 소스 관리의 목적만으로도 매우 훌륭하다.
(복사해서 만들어놓은 코드 디렉토리들이 늘어가기 시작하면 그 필요성을 절감한다.)

넷. 버그/이슈 트래킹 툴

버그 트래킹 툴또한 버그의 역사를 기록하는 것이다.
이것은 재생산되는 버그를 줄이고, 한번 나온 이슈를 끝까지 추적하여 해결하며,
흔히 말하는 '저절로 없어진 버그' 즉 '숨은 버그'에 대해서 관리할 수 있도록 한다.
의료 장비 개발시 FDA등의 인증 기관에서는 소프트웨어의 버그 추적 가능성을 필수 항목으로 생각할 정도로
소프트웨어 완성도를 위해서 중요한 사항이다.

다섯. 스펙

프로젝트 관리를 할때, 문서 작업처럼 귀찮은 것이 없다.
형식에 맞춰야 하고, 잘 써야 하고, 항목을 채워야 한다고 생각이 든다.
그러나 대부분의 회사에서 가지고 있는 문서 양식에 있는 항목은 필요한 정보들이며,
사업화를 위해 조사해야 하는 내용들이다.
소프트웨어 역시 마찬가지이다. 그냥 소프트웨어를 짜면 된다고 생각이 들기도 하지만,
'소프트웨어를 어떻게 만들지'에 대해 고민을 먼저 하지 않는다면,
계속해서 수정에 수정을 더하는 소프트웨어가 되며, 계획도 잘 서지 않는다.
소프트웨어를 만들때 대부분 SRS라는 것을 기본으로 작성하지만,
단순화된 소프트웨어 스펙만으로도 계획적으로 소프트웨어를 개발하고 관리하는데 훨씬 도움이 된다.

다음에는 위의 항목들에 대해 더 자세히 써보고자 한다.

http://news.naver.com/main/read.nhn?mid=smn&sid1=100&oid=023&aid=0002135918&datetime=2010032614500235918

북한이 살기 힘들다는 얘기가 여기저기 들려온다.
정치도 불안하고 어찌 어찌 하다는 얘기도 들려오고, 먹을게 없어 어찌 어찌 하다는 이야기도 들려온다.

지구 저 반대편에 재해가 일어났다고, 저기 먼나라에 먹을게 없다고, 군대와 식량과 돈과 자원봉사를 지원하는 우리나라가,
어찌하여 엎드려 코닿을 거리에 있는 우리 부모의 형제들은 굻어죽도록 내버려두고 있는걸까?

난 정치에 외교에 일말의 관심도 없는 사람이다.
(솔직히 그건 과장이나.. 귀닫고 눈감고 사는 회색분자라 분류될수 있다)
그냥 내가 내 분야에서 열심히 일을 잘해서 많은것이 수출되고 우리나라가 부강해지고, 잘 살았으면 좋겠는
그런 사람이다. 그런 사람이 하도 열받아 생각하는 이유를 풀어보자.

과연 우리나라가 엄청나게 잘사는데 아프리카 어린이는 도와주며 저 북한 어린이는 돕지 못하는 이유는 무엇인가.
물론 정치 외교적인 이유이다.
우리가 주는 쌀이 군량미로 사용될까봐, 우리가 원조해주는 돈이 들어가면 한국/미국 정부 말을 안들을까봐 안주는 것이다.

자 이해는 간다. 북한과는 묘한 밸런스가 유지되어야 하는 관계이다. 그들이 힘을 가져서도 안되지만, 그들의 힘을 잘못빼면, 우리 동포들이 굶어죽는다.

그렇다면 엠비는 왜 그들이 굶어죽게 놔두는 걸까?
그는 미국인이라 한민족은 별 신경 안쓰나? 일본인이라 조선사람은 신경안쓰나? 이리 저리 가서 굽신굽신 하는거 보면
그래 보이기도 한다.
우주인이라 지구인의 목숨은 그냥 들판에 뛰노는 원산지 지구, 음식으로 보이는건가? 생긴걸 보면 그래 보이기도 한다.

내가 생각하는 이유는 그렇다. 그는 기업가였다. 그것도 개발도상국의 개발도상국에서 쪼금 잘사는 나라로 가기위해 발버둥치는 기업의 기업가였다. 나도 사회생활 십수년해봤지만 그 위치까지 가기 쉽지 않다는 것을 안다.
그 위치까지 가기위해서는 어떻게든 수단과 방법을 가리지 말고 '목표'를 달성할 수 있는 '능력'이 필요하다.

자, 그런 세계에서 그런 마인드를 뼈에 깊게 사무친 그가 기업을 떠나 정계로 갔다. 무엇을 할 수 있을까?
결론은 똑같다. 똑같은 방법으로 살 수 밖에 없는 것이다. 그럼 그 에게 '목표'는 무엇인가.
우리 나라를 위하는 것은 무엇인든 그의 목표가 될것이다. (그의 말을 따르면)

문제는 너무나 단편적이라 세상과는 맞지 않는다는데 있다.
잠깐 딴 길로 새서 말하자면, 기업에선, 이윤을 내면 된다. 사원이 잘살건, 힘들건, 내가 세상에 기여를 하건, 우리 회사가 비리를 저지르건 상관 없다. 무조건 '이윤'을 내면 된다.
'사회로의 환원?' '사회를 위하는 공헌?' 다 멍멍이 말씀이시다. 기업이 사회에 공헌하려 하고, 소비자를 위하며, 자원봉사를 하는 이유는 '기업이 이윤을 내는데 유리하기 때문'이다. 다시 말해 '목적'을 위한 장기적이고 약간 더 깊고 우회적인 마케팅에 불과하다는 것이다.

다시 돌아오자.
'뭐? 사람들이 못산다고? 돈이 없어? 직업이 없어 그렇다고? 취업난이 심각하다고? 실업율이 높다고?'
그에게 답은 무엇인가?
' 취업을 시켜 무조건!, 실업을 없애 무조건!' 이다.
그게 어떤 형태든, 그 직업을 통해 그 사람이 장기적으로 일을 할수 있건 없건, 그 일이 우리 사회를 살찌우는 일이건
아니건, 그건 중요하지 않다.

'뭐? 북한이 말을 안들어? 말을 듣게 해야지!' 가 목적인 것이다.

자, 나는 욕하는 것으로 끝나는 것을 싫어한다.
어떻게 하면 엠비가 좀 더 나은 길을 택할 것인가?

나는 그에게 목적을 '사람'으로 바꾸라고 권하고 싶다.
'취업율이 아니라, 사회생활을 하려고 하는 사람',
'북한이 아니라 북한에 사는 우리 민족인 사람'
'수출 실적'이 아니라 '우리가 수출해서 잘살게 하고자 하는 사람'
'4대강이 아니라 4대강을 이용할 사람과 득볼 사람,그리고 해가 되는 사람'


이래도 당신이 그따위로 정치한다면, peanuts의 루시가 해준 말을 해주고 싶다.