절대적인 최고의 방법, 그런 것은 없다

IT 인프라의 중요성이 강조되면서, 대기업이나 공공기관이 주도하는 대형 프로젝트를 심심치 않게 볼 수 있습니다. 엄청난 투자 비용이 들어가며, 인력 투입 역시 어마어마합니다. 또한 전문 업체의 컨설팅을 받기도 하고, 훌륭하다고 회자되는 방법론을 적용하기도 합니다.
 
그런데 이러한 SI프로젝트들 중 성공적으로 완료되었다는 소식을 듣기는 쉽지 않습니다. 물론 표면적으로는 모두 대성공을 거둔 것처럼 포장이 됩니다만, 실제 업무를 담당한 사람에게 슬쩍 물어 볼 경우 한숨만 푹푹 쉬는 경우가 꽤 많습니다.
 
훌륭한 트레이닝을 받은 컨설턴트들의 지도를 받고, 유명한 방법론을 적용하였음에도 왜 이런 결과가 나타날까요? 여러 이유가 있겠지만 제가 생각하기에는 이러한 개발 방법의 전제 조건을 무시하였거나 원칙을 지키지 않는 것이 가장 큰 이유일 겁니다.
 
특히 전제조건이 매우 중요한데, 상당히 많은 경우에 이러한 전제 조건을 명확하게 설명하지 않는 경우가 많습니다. 그냥 이런 방법을 사용하면 무조건 성공해! 라는 식인 경우이죠.
 
예를 들어 최근 인기를 얻고 있는 XP의 짝 프로그래밍을 예로 들어 보죠. 이렇게 일할 때의 장점은 많습니다. 기본적으로 버그를 발견할 확률이 높아지고, 전반적으로 이해하기 쉬운 코드가 작성되며 더 나은 아이디어가 추가될 가능성이 큽니다. 하지만 장점만 있을까요?
 
위의 성과를 얻기 위해서는 기본적인 전제 조건이 충족되어야 합니다. 즉 함께 일할 두 사람은 최소한 비슷한 지식 수준을 가지고 있어야 합니다. 두 사람의 지식 수준에 차이가 크다면 더 잘 알고 있는 사람은 지루해 하거나 답답해 할 것이고, 다른 한 명은 위축되어 자기 생각을 제대로 표현하기도 힘들어 질 겁니다. 1+1이 3이나 4가 되길 원하지만 실제로 1.5 정도가 되어 버리는 것이죠.
 
또한 개발 조직 구성이 미치는 영향도 큽니다. 예를 들어 TDD에서 강조되는 유닛 테스트를 생각해 보죠. 유닛 테스트는 소스의 품질을 지킬 수 있는 매우 유용한 방법이라는 것은 분명합니다. 하지만 원하는 성과를 얻기 위해서는 역시 기본적으로 지켜져야 할 것이 존재하죠.
 
즉, 테스트를 할 수 있을만한 충분한 시간이 제공되어야 하고, 개발자 자신이 유닛 테스트를 수행하는 목적과 이유에 대해 충분히 이해하고 있어야 합니다. 그리고 적극적으로 자신의 코드에 대한 테스트 코드를 작성해야 하는 것이죠.
 
하지만 대부분의 SI 프로젝트가 갑을병정으로 이어지는 하도급으로 수행되는 현실에서, 실제로 일하는 개발자가 이러한 전제 조건이 충족되는 환경에 있기는 어렵습니다. 결국 상부에서 “유닛 테스트를 코드 1000라인당 몇 개 이상씩 작성하시오!!”와 같은 지시가 내려오면, 지표에 맞게 적당히 만들고 지나가는 수준으로 끝나 버리기 쉽습니다. 전혀 의미 없는 시간과 노력의 낭비가 되어 버리는 것이죠.
 
이론적으로 훌륭한 방법은 얼마든지 있을 수 있습니다. 하지만 우리는 현실의 세계에서 살고 있습니다. 수 많은 복잡한 요인이 존재하고, 프로젝트의 설계 과정에서 흔히 간과되는 정치적 영향력의 세계에 살고 있는 것이죠. 이러한 현실에서 절대 선이 될 수 있는 방법이란 존재하지 않습니다.
 
결국 왜 이러한 방법을 쓰는가에 대한 명확한 이해, 현재 상황에 대한 냉정한 분석, 성공에 필요한 전제조건의 확인 과정이 없이 어떠한 방법을 기계적으로 사용하는 것은 반드시 실패할 뿐입니다. 현실에서는 최적의 방법이 있을 뿐, 절대적인 최고의 방법이란 없는 것입니다.
스마트플레이스의 글을 편리하게 구독하세요. 한RSS 추가 구글추가
크리에이티브 커먼즈 라이센스
Creative Commons License이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

트랙백 (1) | 덧글 (22)
트랙백 주소: http://www.smartplace.kr/trackback_post_172.aspx
스마트플레이스의 트랙백은 스팸방지를 위해 관리자 승인 후 등록됩니다.
연봉의 경제학 - 프로그래머의 적정연봉은 얼마인가?
사실 이 문제에 진정한 답은 없는 것 같지만, IT업계에 종사하는 프로그래머 분들이 가끔씩 자신의 연봉에 대해서 불만을 토로하는 이야기를 하시는 것을 보면 이해가 되는 부분도 있고, 이해를 하셔야 하는 부분이 있기에 글을 써 봅니다. 기실 우리나라 프로그래머의 초임연봉은 다른 직종에 비해서 상당히 낮은 편이라고 생각됩니다. 상황이나 조건에 따라 다르기는 하...

김창준 2007-05-27 10:25:26     답글 삭제
안녕하세요.

세론에서는 의견을 달리합니다(예를 들어 지식 수준이 비슷해야 효과적인 짝 프로그래밍이 가능하다는 것). 하지만 "어떠한 방법을 기계적으로 사용하는 것은 반드시 실패할 뿐입니다"라는 결론에는 공감을 합니다. 예컨대, 도요타 방식의 표면적인 방법과 테크닉을(정신과 철학이 아니라) 베끼려던 무수히 많은 회사들의 실패가 한가지 반증이라고 봅니다.

애자일 쪽에서는 Best Practice라는 말을 쓰지 말자고 하는 사람들이 최근에 많이 생겼습니다. 맥락 없이 베스트라는 건 없다는 이야기이죠.

(그리고 사족인데, "낳은 아이디어 -> 나은 아이디어"가 바른 표기입니다)
바비 2007-05-27 15:15:40     삭제
오타는 앤디 대신 제가 고쳐 놓았습니다. ^^
앤디 2007-05-28 07:46:17     삭제
피드백 감사합니다. 오타를 수정해 주신 바비님께도 감사합니다. ^^;;

김창준 2007-05-27 10:41:28     답글 삭제
그리고, 글의 예를 보면, 이상적인 방법이 있다면, 그런 것보다 더 낮은 위치의 타협적인 방법을 취하는 게 낫다는 예가 있어서 자칫하면 "패배주의"로 해석될 위험이 있는 것 같습니다.

도요타를 따라하려던 많은 회사들이 실패한 이유는 처음부터 알아모셔서 허리 구부리고 소극적이고 타협적인 목표를 잡지 못해서가 아니라고 생각합니다.

우리의 이상과 야망을 더 낮추는 것이 아니라 오히려 더 높여야 하는 것은 아닐까요. 다만, 그 접근에 있어서는 기본 정신과 철학, 그리고 맥락을 고려해서 우리에게 맞는 현실적인, 그렇다고 현실 안주적이진 않은 방식을 찾아 나가야겠지요.
바비 2007-05-27 15:31:29     삭제
프로세스를 중요하게 생각하는(그리고 강요하는) 대기업에 국한해서 얘기해보죠.

국내 대기업의 상당수에는 전체주의로서 강요되는 경영철학 내지는 문화가 있습니다. 그것에 대응한다는 것은 단순히 업무 수행의 방법을 선택하는 정도가 아니라, 조직 문화와 싸우는 것 그리고 조직 구성원 전체를 상대로 하는 것이라고 할 수 있습니다.

조직원으로서의 선택의 폭, 외부 컨설턴트로서의 선택의 폭은 상당히 다를 수 밖에 없습니다. 김창준님이 모대기업에 가서 "짝프로그래밍을 해보세요?"라고 조언하는 것에 어떤 용기가 필요하지는 않을 것입니다.

하지만 조직원이 부서장한테 "짝프로그래밍을 해야합니다"라고 주장하는 것에는 예컨대, 지하철에 떨어진 승객을 구할 정도의 용기가 필요할 수도 있습니다. 그래서 그런 용기를 발휘하는 사람을 보기 힘듭니다.

기업의 조직원으로서 이상을 높인다면, 그것은 사망에 이르는 길입니다. 기업은 이상을 받아주는 곳이 아니기 때문입니다.

(몇몇 기업을 제외하고) 대부분의 기업에서, "이상"이라는 말은 전혀 어울리지 않습니다. 만일 어떤 개인이 그런 것을 정말 갖고 있다면, 일개 기업이 아니라 이 사회 그리고 우주를 향해 펼치는 것이 훨씬 효과적일 것입니다.
데니 2007-05-28 00:10:45     삭제
저의 경우 "짝프로그래밍"이든 무엇이든 몰라서 안 하는 것이 아니라 할 수 없어서 못합니다. 회사에 도입을 주장할 용기는 있으나, 누울 자리가 아니기에 말하지 않습니다.

납득시킬 수도 없을 것이며, 마치 납득 시킨 것처럼 만들어 도입을 하게 된다 하더라도 도입에 따른 긍정적 효과보다는 더욱 많은 무의미한 일들만 발생할 것을 알기 때문입니다. 윗사람들은 긍정적 효과를 평가하는 잣대가 우리와는 전혀 다르기 때문이지요.

그로 인한 에너지 낭비는 팀 내에 그나마 남아있던 긍정적인 에너지까지 부정적 에너지로 바꿔버릴 수 있기 때문입니다. 그래서 도입을 하려는 용기는 혼자서 가슴 속에 묻어 둡니다.

때로는 이상과 야망 이런 것을 모른다면 차라리 속이라도 편하지 않을까 싶을 때도 있습니다. 언젠간 할 수 있지 않을까 라는 희망을 갖고 살 뿐이지요. 너무 우울한 현실인가요? ^^

좋은 글, 좋은 댓글을 보고 몇 글자 남겨 봅니다.
앤디 2007-05-28 07:58:44     삭제
음..더 낮은 위치의 타협적인 방법을 취하는 것이 더 낫다고 주장한 것은 아닌데, 제 필력이 모자라 오해의 소지가 있었나 봅니다. 제가 말하고 싶었던 것은 어떠한 방법이건 "적절한" 수준을 찾아야 한다는 것입니다.

물론 말씀하신 것처럼 이상과 야망을 높여서 밀고 나가야 할 때도 있을 겁니다. 하지만 대부분의 국내 기업에서 그런 도전을 한다는 것은 바비님께서 말씀하신 것처럼 매우 어렵습니다.

그런 이야기를 하는 순간 수 많은 이해 관계자들의 화살을 맞고 사망해 버릴 것이 뻔하기 때문이죠.

얻고자 하는 것이 무엇이건, 그 기본 정신과 철학을 지켜야 한다는 점에는 동의합니다. 하지만 환경상 적절하지 못할 경우, 적용하지 않느니만 못한 결과가 나오기 쉽습니다.

수 많은 인원이 공동으로 프로젝트를 진행할 경우, 기본 정신과 철학 자체를 공유하는 것조차 매우 어려운 일이기 때문입니다.
oojoo 2007-05-28 11:32:15     삭제
여러 의견들을 보니 이상과 현실에 대한 괴리에 대한 입장이 상이하다는 생각이 듭니다.

누구나 떠들 수 있는 이상은 있지만 그걸 현실에 적용하기란 무척 어렵습니다. 그 어려움을 적절한 타협으로 푸느냐, 수긍하며 패배주의에 빠져 사느냐, 적극적으로 싸워서 쟁취하느냐는 속한 조직의 환경과 내 역량, 시대 분위기 등에 따라 달라지겠죠.

제가 주로 사용하는 방법은 겉으로는 수긍하고 적극 따라주되 칼을 품으며 후일을 도모하는 것입니다.

후일 권한을 쟁취할 때 이상을 실현하거나, 분위기를 타서 강하게 비수를 드리미는 방법이죠.


물론 시스템을 좌지우지하기 편한 '갑'의 입장에선 프리랜서나 PM이라면 저런 고민도 필요없겠네요.

암튼 중요한 것은 그러한 Action에 따른 최종 산출물이 어떤 성과를 주느냐(내 스스로 느끼는 평가가 아닌 외부 평가)가 앞으로 그런 유토피아를 계속 주장할 수 있느냐 아니면 비주류로 평생 떠들기만 하고 사느냐를 결정해주겠죠~

5throck 2007-05-27 16:59:07     답글 삭제
저도 XP 프로그래밍 방식의 좋은 점에는 상당 부분 동의를 하지만, 아마도 이런 경우는 패키지를 개발하는 형태에만 적합하지 않을까 생각합니다.

국내에서 벌어지는 대부분의 프로젝트는 수주업 형태로 진행이 되기 때문에 원가압박이 상당히 심한 상태이고, 어떤 코딩을 2명이 같이 진행을 한다는 것은 상당한 원가를 요한다고 생각합니다.

여러 가지 이유가 있을 수 있겠지만 한국의 개발이 지금의 머리수를 채워서 단가를 계산하는 구태의연한 현실을 벗어나지 않는다면 국내의 현실을 고려해 볼 때 아마도 이러한 형식의 개발은 상당히 요원한 일이 않을까 생각해 봅니다.
앤디 2007-05-28 08:02:33     삭제
국내 SI업계 최대의 시장 점유율을 자랑하는 S사 인력의 경우, 1 man/month당 1500 ~ 2200만원 정도의 비용이 들어갑니다.

말씀하신 것처럼 현재의 머리수 계산 방식이 유효한 현실에서, 상부를 납득시키기는 불가능에 가까운 일일 것이라고 생각합니다.

고원규 2007-05-28 11:34:23     답글 삭제
비밀 댓글이 등록되었습니다.

이벤트 2007-05-28 11:44:36     답글 삭제
자칫 본문의 주제와 다른 방향으로 덧글이 작성되는 느낌이 듭니다. 프로젝트 실패 원인을 프로그램 개발에서 찾으려는 느낌 또한 듭니다. 결론을 우선 말하면 이런 접근은 다시 한번 생각해 볼 필요가 있습니다.
프로젝트의 성공과 실패는 요구분석과 설계에 달려 있습니다. 흔히들 프로그램 개발이 잘못되어 프로젝트가 실패하였다고 하는데요... 그것은 PM/분석가/설계자의 비양심적인 발언이며, 자신을 돌아보지 않은 언행입니다.

프로그램 개발자는 설계서를 기준으로 개발을 하면 됩니다. 설계서에 없는 내용을 개발자가 임의로 추가하는 것도 문제가 됩니다. 프로그램에서 오류가 나더라도 스펙을 기준으로 테스트하는 사람이 엄격하게 테스트를 하면 됩니다. 그런데 프로젝트에서는 이 모든 것을 프로그램 개발자에게 의존하고 있습니다.

요구에 대한 기준을 명확하게 작성하지 않고, 설계서를 정확하게 작성하지 않고 프로그램이 제대로 나와 줄것을 기대하는 분석가, 설계자가 우선 반성할 필요가 있습니다.

프로젝트에서 프로그램 개발이 차지하는 비중이 그리 크지 않습니다. 일반적으로 30~40%를 프로그램 개발에 설정하는데 나머지 60~70%를 대충하고 프로젝트가 성공하길 바라는 것은 말이 되지 않습니다.

이벤트 2007-05-28 12:07:02     답글 삭제
제가 작성한 위의 글을 '등록'한 후 추가하려고 하니 불가능한 것 같습니다. 그래서 추가합니다.

시스템은 시스템적으로 접근해야 합니다. 미국에서 만든 스펙이 그날 인도에서 개발되고 다음날 다시 미국에서 인수할 수 있는 것은 시스템적으로 접근한 것입니다. 사람 중심이 아닌 스펙 중심의 접근이며 개인에 의존하는 시스템 개발이 아니라 시스템이 시스템을 개발하는 형태가 되어야 합니다.

개발자가 많으므로 개발자를 위한 책과 논리가 나오고 회자되는 상업적인 측면도 있다고 생각합니다. 프로젝트에서 프로그램 개발은 30~40% 비중을 차지하며 앞에서 잘못한 것을 뒤에서 마무리 지으려는 잘못된 접근을 떠나 앞에서 한 것을 검증할 수 있는 방법을 찾고 이를 완벽하게 실행할 수 있는 방법을 찾아야 할 것으로 생각됩니다.
앤디 2007-05-28 12:49:12     삭제
좋은 피드백 감사합니다. 말씀하신 시스템의 중요성에 동의합니다. 특히 대규모의 인력이 투입되는 큰 프로젝트일수록 이러한 시스템적 관점이 매우 중요해 집니다.

특히 말씀하신 것처럼 앞에서 잘못한 것을 뒤에서 막으려는 접근은 분명히 문제가 있습니다. 프로젝트의 성공이란 프로젝트 참여자 모두의 노력과 기여에 기반하는 것이지, 개발자만의 노력으로 해결 되는 것이 절대 아니니까요.

하지만 실제로 개발을 담당하는 개인의 관점 역시 무시되어서는 안 됩니다. 어떠한 설계가 존재하건간에, 결국 코딩을 수행하는 것은 각각의 개발자이기 때문이죠.

아무리 탁월한 전술을 가지고 전투를 하려 한다 해도, 전투를 수행할 병사들이 훈련되어 있지 않다면 전투에서 승리할 수 없는 것과 같을 것입니다.

즉 시스템적인 관점과 개발자 개인의 관점 모두 중요합니다.

결국 소프트웨어 프로젝트는 설계, 프로세스, 원칙, 그리고 개인의 역량이 종합되어 최종 결과를 도출해 내는 복잡한 과정인 것이죠.

제가 이 글에서 이야기하고 싶은 것은 어느 하나의 관점에 매몰되거나, 현실을 제대로 고려하지 않아 적절하지 않은 방법을 무조건적으로 적용하는 것의 위험성입니다. 그로 인해 고통 받는 사람들을 찾는 것은 너무 쉽기 때문에 말이죠.

yuzi 2007-05-28 14:07:43     답글 삭제
도입부를 보고, CMMI등의 프로세스 개선 모델에 무분별한 도입을 이야기 할것이라 기대했는데요. 의외로, Agile 개발 프랙티스의 도입에 대한 이야기였군요. 개인적으로 Agile방법론은 "자기조직화"에 근본을 두고 있다고 봅니다. 이러한 근본을 가진 XP 프랙티스에 너무 큰 사업적 기대를 하게되면 안됩니다.
앤디 2007-05-28 14:39:45     삭제
CMMI에 대해서는 이전에 작성했던 제 글에서 잠깐 기술했던 바가 있습니다. http://www.smartplace.co.kr/blog_post_81.aspx

전체 프로세스를 포괄적으로 바라보건, 개발자의 입장에 초점을 맞추건, 설계 과정에 집중하건, 이 모든 것은 범위가 다를 뿐이죠.

실무에 적용하기 위해서는 여러 다양한 현실적 제약과 환경 요인을 검토해야 한다고 믿습니다.

XP를 예로 든 것 역시 그러한 맥락에서 든 것이지, 딱히 Agile 방법론을 공격하고자 적은 것은 아닙니다. ^^

어떠한 방법론이건 가장 중요한 것은 "우리 상황에 잘 맞을까? 아니면 맞출 수 있을까?"여야 한다고 생각합니다. 피드백 감사합니다.

불휘 2007-05-29 13:35:30     답글 삭제
안녕하세요. 광저장장치 제조회사에 다니는 안경호입니다.

과거에 SI 개발자에서 순수 소프트웨어 개발자로 현재는 펌웨어 디버거로 사는 이가 피드백 남김니다.

대기업에서 고군분투하며 칼도 갈았다가 사람들과 낮고 구체적인 부분까지 타협의 에너지를 투입시키며 사망신고도 받지 않으려고 고통스런시간들을 보내고 있지만, 그런 고통들이 이러한 블로깅을 통해 사회적인 결실로 공유되지 않으면, 저의 고통과 보람들은 그저 개인적인 성공이야기로 끝나겠죠.

결국 우리는 우리를 구체화시킬 수 있는 연대적인 성공이야기가 필요할 것입니다.

글 잘 읽었습니다.

추가글: 김창준님의 댓글로 이런 포스팅이 뜨겁게 달궈질 수 있다는 데 그저 놀라울 뿐입니다. 역시 각 분야의 한사람이 해야할 몫은 우리가 상상하는 것보다 훨씬 큰 것 같습니다.
앤디 2007-05-29 16:55:25     삭제
좋은 피드백 감사합니다. 개인적으로 현재 나와 있는 대부분의 방법론은 관리자의 관점에서 도출되어 있다고 봅니다. 물론 예외도 있긴 하지만요.

그렇기 때문에 말씀하신 것 같은 훌륭한 Success Story가 나오는 것이 매우 중요하다는 점에 동의합니다.

그리고 그러한 성공 스토리가 쌓인 후에야 실무자와 관리자 양쪽에 균등한 비중을 두는 방법론이 도출 될 수 있을 것이라 생각합니다.

김민수 2007-05-31 00:47:48     답글 삭제
결국 일을 하는 건 사람입니다. 아무리 뛰어난 방법론이 나오고 기가 막힌 환경이 주어져도 제대로 못하면 아무 소용 없다는 얘기입니다. 근데 우리나라는 쉽게 말해 상당히 그 벤치가 주전선수들 빼면 약합니다. 즉, 개발자 층이 얇습니다.
앤디 2007-05-31 08:08:07     삭제
말씀에 100% 동의합니다. 개발자 층이 얇기도 하거니와, 더 심각한 것은 그나마도 점점 더 사라져 간다는 것이죠.

사람이라는 요소를 간과하는 경우가 너무 많아 안타깝습니다.

cat 2007-06-03 20:42:14     답글 삭제
솔직히 말해서 한국식 재벌은 70년대 고속성장시대에나 맞는
방식입니다..현재의 중국같은..
21세기 한국에는 현재의 재벌 체제는 부적합니다..
재벌들도 압니다..억지로 강요할 뿐이죠..
무능한 재벌 2세들을 빨리 손떼게 해야 좋은데..
현재 재벌의 성장은 국가 전체적으로 도움이 안되고 있습니다..

winever 2007-06-08 18:26:05     답글 삭제
공공이던, 민간기업이던, 아니면 내부 프로젝트이건.. 중요한건 어떤 Needs에서 출발했으냐의 문제이고, 참여하는 분들의 의지와 마인드 문제가 크다고 봅이다. 어느 일이나 마찬가지이겠지만서도, 검증된 절차와 산출물을 만들어내는 것은 주어진 과제의 Minimum을 보장하기 위함일 뿐입니다.

지금 오늘 당장도 역시나 한 프로젝트의 PM 입장에서, 같이 투입된 우리 팀원들에게 동기를 부여하고, 긍정적으로 과제를 바라보게 하고, 더불어 고객과 좋은 관계를 유지하고, 프로젝트의 목표를 달성하기 위해 매진해야 한답니다.

우리나라 IT 현실의 어두운 모습들은 극복의 대상으로 바라보아야하지 않을까 싶습니다. 너무 아쉬워하시는 글들만 보이는 것 같아서 안타깝네요. 밤이 깊을수록 새벽이 가깝다고 했나요..? <- 너무 적절치 않은 비유같군요.. 흐흐..

어떤 컨설팅펌의 유명한 방법론을 이용했는지, 얼마나 비싼 장비와 많은 개발인력이 들어왔는지의 문제이기보다는.. 현업으로부터 절실하게 요구되는 요소들을 긍정적이고, 합리적인 프로젝트팀(개발자 및 대상 고객 포함)이 열심히 고민하고 극복해가는 과정일 뿐입니다.

요즈음은 너무 관리적인 요소에 치우친다는 느낌을 지울 수 없지요. 그러면서 지금도 매우 세세한 WBS를 만들어야 함에 안타깝습니다. (다 지키지도 못할텐데.. 흑흑..)

이름 비밀번호
홈페이지
덧글
비밀글
RSS 피드
전체글한RSS 추가 구글추가
스마트가젯북스타일
Demo Day