2009년 3월 23일 월요일

소스코드가 그렇게 중요한가요?

소스코드를 신주단지 모시듯 하는 회사나 개발자들을 자주 볼 수 있습니다.
소스코드가 자신들의 모든 기술이 함축된 집합체라고 생각들을 합니다.
 
저는 이런 회사나 개발자들 딱 접하는 순간 그 수준을 한번에 알 수 있습니다. 다른 것들은 별로 물어볼 필요도 없이 그로 인해서 회사가 어떤 식으로 개발을 하고 있다는 것을 쉽게 짐작할 수 있습니다.
 
그러한 회사들은 소스코드를 개발자를 제외한 다른 직원들은 접근하지 못하도록 하기 위해서 보안장치를 두고 개발자는 자신이 작성한 소스코드를 공유하기 꺼려하기도 합니다. 개발의 내용은 SRS나 설계서에 포함되어 있기보다는 그냥 코드에 숨어 있어서 이를 작성한 사람이 아니면 전체를 파악하기 정말 어렵습니다. 해당 개발자가 아니면 유지보수가 어렵고 신입사원이 들어와도 공유가 잘 안됩니다.
 
이런 말이 있습니다.
"경쟁회사를 어렵게 만들고 싶으면 자사의 소스코드를 실수인척하고 공개해서 경쟁회사로 흘러 들어가게 하라"
그 경쟁사는 소스코드를 얻고 횡재한 줄 알겠지만, 이를 분석하다 보면 몇 달 후 별로 얻은 것은 없이 시간만 낭비했다는 것을 알게 될 것입니다.
 
가슴에 손을 얹고 생각해보면 우리가 작성하는 소스코드 중에서 정말 획기적인 것이 있나요? 남들은 절대로 만들지 못할 엄청나게 어려운 것이 있나요? 대부분은 이미 다 공개된 알고리즘과 모듈들입니다. 물론 그런 것들이 있다면 잘 지켜야 겠지요. 하지만 그런 경우는 거의 찾아보기 힘듭니다.

정작 중요한 것은 그 아키텍처이고, 스펙입니다. 그리고 개발자들의 역량과 팀웍이죠. 그것들이 다른 회사와 우리 회사를 다르게 만들어주는 요소입니다. 소스코드는 아니죠.
 
물론 소스코드가 소프트웨어를 이루는 중요한 요소이기는 하지만 소스코드의 보안에만 신경 쓰는 순간 자신의 수준을 확 낮춘다는 것을 알아야 하겠습니다.

댓글 23개:

  1. 정확한 지적이십니다.
    소스코드 그까이꺼 라는 의미는 아니지만, 가장 중요한건 역시나 아키텍쳐가 아닐까 합니다.
    스펙은 그 다음^^!

    답글삭제
  2. 좋은 지적입니다. 비워야 무언가 다른 것으로 채울 수 있으니까요.
    하지만 문제가 발생할 경우 관리 소홀에 대한 물적 책임은 개발자에게...ㅠㅠ 좌절이지요.^^

    그래도 업무관련된 공적인 소스가 아니라면...
    개발자는 언제나 공부하는 마음으로 자신의 것을 공유해야 한다고 생각이됩니다. 그래야 자기 스스로도 발전이 있기 때문이죠.^^
    즐거운 하루되세요.

    답글삭제
  3. kkommy님 안녕하세요. 대박씩이나 ^^...

    답글삭제
  4. 돌이아빠님 안녕하세요.
    돌이아빠님 블로그는 항상 즐겨 보고 있습니다. 의견 감사합니다.

    답글삭제
  5. 위즈님 안녕하세요.
    반갑습니다. 좋은 의견 감사합니다.

    답글삭제
  6. 대기업의 울타리안에서 매일매일 비슷한 일만 하다가 가끔씩 바깥세상이 어떻게 바뀌어 가는지를
    느끼게 되면 깜짝 놀라게 됩니다.
    Web 2.0 의 홍수속에서 프로젝트를 위한 유용한 툴들이 꽤 많아졌군요.

    요즘 새로 맡은 일과 관련하여 이것저것 찾다가 이곳에 들르게 되었습니다.
    http://www.projectlocker.com/


    뭐냐하면

    답글삭제
  7. 아키텍쳐와 스펙이 중요하다고는 해도 이를 테스트 수준이 아닌 실제의 상용서비스 수준으로 어떻게 구현해 내느냐는 또 별개의 문제가 아닐지요. 결국 이건 개발자 역량의 문제이고 그 역량과 기술이 담겨 있는게 소스코드라고 생각합니다.

    돌아보면 소스코드가 별로 중요하지 않았던 프로젝트나 서비스는 아키텍쳐나 스펙도 그닥 중요한 건 없었습니다. 이미 다 공개된 스펙에 해당 아키텍쳐를 지원하는 WAS나 프레임워크를 쓰는 식이었지요. 시스템 아키텍쳐도 서버/스위칭 장비의 댓수만 좀 차이가 날뿐 비슷비슷하구요.

    말씀하시려는 의도는 잘 알겠지만 약간은 한쪽으로 치우친 글이 아닌가 해서 댓글 남겨봅니다.

    답글삭제
  8. 안녕하세요. 우울한딱따구리님
    의견 감사합니다. 원래 글이라는 것이 한쪽으로 치울칠 수 밖에 없죠. 딱 중간을 지키는 것은 또 무미건조할 것이고. ^^ 저는 컨설팅을 하면서 겪는 경험들을 강도있게 표현하려고 하고 있습니다. 따라서 이런 종류의 주제를 다룰 때는 이런 논조를 유지하려고 합니다.
    그리고 말씀하시는 의도도 충분히 알고 있습니다. 이 정도의 글이 아니면 그렇게 코드만을 중요시 하는 개발자들이 생각을 조금도 움직일 수 없겠죠.

    답글삭제
  9. 버전 컨트롤 시스템을 쓰는 회사에서도 저런 일이 일어날 수 있는지요?

    답글삭제
  10. 툴이 이슈는 아니고 마인드의 문제를 지적한 것입니다. 개발에 있어서 코딩의 비중이 그렇게 높지 않고, 소스코드는 중요하지만, 소스코드 자체가 개발 결과물을 대표하지 않는 다는 것입니다. 소스코드를 누가 본다고 해서 모든 것을 잃는 것이 아니라는 뜻이기도 합니다. 버전컨트롤 시스템을 쓰는 회사에는 소스코드를 숨길 수는 없지만, 그렇다고 개발자들간에 소스코드가 잘 공유된다고 볼 수도 없습니다. 결국 마이드가 중요하죠.

    답글삭제
  11. 약간은 다른 문제이겠지만
    보안의 관점에서는 신주단지 같지않은 소스라도 공개되면 곤란한 경우가 있습니다.
    암호화관련 모듈이라든지 인프라 정보가 노출될 수도 있고 회사 입장에서는
    기술유출 보다는 이런 보안쪽이 더 문제이기때문에 철저히 관리하는게 아닐까요..

    답글삭제
  12. 개인적인 느낌은, 간단한 룰 및 툴의 도입으로 해결가능한 문제가 '회사 개발자 전체의 마인드 문제다' 로 지적되는 건 아닌가 해서 그럽니다. 생각보다 사람들은 자신에의 문제상황이 실제로 문제상황인지를 인지하는데 시간이 걸립니다.

    자신의 버그를 자기 눈으로 찾는 것보다 다른 사람이 외부의 시각에서 발견하는 것이 더 빨리 보이는 경우는 많습니다. 그건 다른 사람이 더 똑똑해서가 아닙니다. 다른 관점으로 바라보는 것이 (혹은 내부 이해관계에 얽매이지 않은 시각으로 바라볼 수 있는 것이) 더 빨리 볼 수 있는 문제들이여서 그런 것 뿐일지도 모릅니다.

    여담으로 농담 섞어 이야기하면.. 저라면 해당 회사에서 소스를 훔칠까 스펙 & 디자인 문서 훔칠까 하면 소스를 훔칠겁니다. 이유는, 소스가 스펙 & 디자인 문서보다는 거짓말을 덜하기 때문입니다. ;)

    답글삭제
  13. bluecodea님 의견 감사합니다.
    맞습니다. 소스코드가 오픈되면 공격을 당할 수도 있습니다. 물론 Reverse engineering을 하면 왠만한 것은 알아낼 수 있지만, 소스코드가 있다면 훨씬 쉽게 공격당할 수 있죠. 물론 좋은 보안 솔루션은 소스코드가 공개되도 안전한 솔루션이겠지만, 그렇지 못한 경우도 있고, 허술하게 짜여진 보안 관련 코드들이 있으므로 소스코드를 안전하게 지키는 것이 가장 쉬운 수단이죠. 사실 많은 개발자들이 허술하게 코드를 작성해도 별문제가 안되는 이유는 공격자들이 별로 관심이 없기 때문입니다. ^^ 윈도우즈가 그렇게 많은 보안 취약점이 발견되는 이유는 바로 많은 사람들이 관심을 가지고 있기 때문입니다.
    감사합니다.

    답글삭제
  14. 좋은 의견 감사드립니다.
    저도 소스코드를 훔칠 것 같네요. ^^ 그 이유는 대부분의 회사가 스펙이나 설계문서는 잘 작성되어 있지 않지만, 적어도 소스코드는 진짜 동작하거든요. 그리고 내가 소스코드를 잘 알고 있는 상황에서 소스코드는 상당한 가치가 있지만, 덜렁 소스코드를 남을 주면 소스코드 분석하기도 쉽지는 않습니다.

    답글삭제
  15. 소스코드... 우리팀에게는 무척이나 중요합니다. :)

    왜냐하면, 우리팀은 소스코드를 관리해주는 실루엣이라는 형상관리 솔루션을 개발하고 있기 때문이죠.

    소스코드는 우리게 고객이랄까요? 물론 여러분들께는 창작물이 되겠지만 말입니다. :)

    답글삭제
  16. 머샤머샤님 안녕하세요.
    소스코드관리는 매우 중요하고 소프트웨어 개발의 기본중의 기본이죠. 소스코드관리시스템을 만드시니까 당연히 잘 아시겠죠. ^^ 실루엣은 과거에 컨설팅을 했던 고객사를 통해서 들어본 적이 있습니다. 고객사가 어딘지는 짐작하실 겁니다. 앞으로 좋은 의견 많이 교환하길 기대합니다.

    답글삭제
  17. 오늘 무료 SVN 호스팅 서비스에 관한 글을 쓰려고 제 블로그에 접속해서 글쓰기 전에 잠시 검색을 했습니다. 그랬더니 ^^;; 벌서 많은 분들이 글을 작성해 두셨더라구요 ^^; 어제 가입한 무료 서비스 주소를 잊어 버리지 않기 위해서 그 주소에 관한 이야기는 적고 나머니지는 여러분들께 선택의 자유를 드리기 위해서 ^^;; 그 글들을 소개 합니다. http://kyogun.egloos.com/3808559 소규모 개발팀을 위한 SVN 무료 호스팅 서비..

    답글삭제
  18. 찌질개발자인 저에게는 '소스코드=비급문서' 라는 인식이 있었던 듯 합니다.
    잠깐 여러 생각을 하다 갑니다.

    답글삭제
  19. miing님 안녕하세요.
    누구나 다 사연이 있습니다. 주변이 환경이 열심히 일하려는 개발자들은 뒷받침 못해주는 것이 첫번째 이유입니다. 이런 환경에서 오래 일하면 발전하기 어렵죠.

    답글삭제
  20. 소스코드가 그렇게 중요한가요.

    답글삭제
  21. 제 생각에 전규현님은 경쟁이 치열한 분야에서,
    상용엔진을 만들어본적이 없는 분 같네요.

    답글삭제
  22. 안녕하세요. 개발자님

    이런 글들은 대부분 익명으로 올라오더군요.
    저를 한번도 뵌적이 없는 분 같은데(정체를 알 수 없으니)... 절 평가하네요. :)

    저는 소프트웨어 업계에서 17년 개발자로서 일을 했고, 한글과컴퓨터, 안철수연구소 등에서 일해왔습니다. 그리고 제 글들은 이론적이지 않습니다. Global standard에 가까운 글들을 쓰고 있습니다.

    제 글들은 소프트웨어 초보자들은 이해하기 어렵습니다. 또한 고참이라고 하더라도 오랫동안 주먹구구 방식으로 개발하던 개발자들도 이해하기 어렵습니다.

    또한 국내 소프트웨어 개발자나 회사나 얼마나 열악한 환경에서 주먹구구식으로 개발을 하고 있는지, 또 얼마나 미래가 없는지 잘 알고 있습니다. 또한 엔진이라고 부르는 것들, 솔루션이라고 하는 것들이 얼마나 제 값어치를 못하고 있는 것들인지도 잘알고 있습니다. 물론 개발자들이 열심히는 하지만 그것만으로는 부족하죠. 그래서 저는 컨설턴트로서 개발자를 교육하여 역량을 향상시키고 회사를 개혁시키 일을 하고 있습니다.

    배우지 않으려고 하는 사람에게 도움을 줄 수는 없습니다.

    물론 제글과 다른 의견들도 있을 수 있고 언제든지 토론을 환영합니다. 가능하면 토론이 될만한 의견을 올려주면 좋겠네요.

    답글삭제