어머나. 소스코드를 복사하다니! 다음 vs. 네이버

뒷북을 울려라~ 이히~ 둥둥둥~

하드코어모드로 끝간데 없이 달리는 회사일정에 때맞추어 열린 World of warcraft: Burning Crusade의 흥미진진한 새로운 세상에다가 활동을 재개한 밴드일정으로 정신이 하나도 없는 까막군에게 심심함을 덜어주는 포스팅거리가 생겼으니 뒷북을 울려라~!

사건의 요지는 다음에서 만든 자바스크립트 소스를 네이버에서 홀랑 베껴다 써먹었다는 훈훈한 이야기입니다. 출처는 스마트플레이스. 덕분에 읽을만한 블로그를 찾았군요. (처음에 어디서 봤는지는 기억이 -_- ZDNet이었나..)

여하튼, C++을 이용해 패키지를 만드는 업체에 근무하는 저로서는 상상하기 힘든 일입니다. 저희팀에선 External Copy & Paste가 드물거든요. (회사 내부코드에선 간간히 있지만..)

일단은 스펙(프로토콜 문서 혹은 인코딩 문서)이 공개되어있는 경우에는 스펙보고 코드를 만들면 그만이고, 스펙이 안나와있으면, 코드도 없기 마련인지라.. 하핫. 외부 코드를 가져와서 사용할때는 라이센스를 면밀히 살피죠. 나중에 문제될까봐. (그래서 남은건 boost, ACE, STLPort 정도이군요..)

심지어는 C++ 개발자들이 많이 보는 Code Guru같은 사이트에 올라온 코드들도 무용지물인 경우가 많습니다. MFC를 배제하는게 기본 원칙인데 MFC코드가 많거든요. MFC코드를 배제하더라도 네이밍규칙같은 것에 위배되는게 많아서 고쳐쓰려면 결국 코드를 다시 작성하는거나 다름 없답니다. (고쳐쓰느니 그냥 짜고 말죠.) 그리고, 이해하지 못하면 유지보수가 불가능한데 이해를 하다보면 그냥 짜는게 깔끔한 코드를 만드는 지름길인지라..

서비스를 만드는 환경과 패키지를 만드는 환경의 차이일까요?

어느쪽이나 시간압박은 비슷하고, 주어지는 외부 압력도 유사합니다. (큰 차이는 모르겠군요.) 아마 개발자 자신의 자세가 문제였을거란 생각이 드네요. 소프트웨어 프로그래밍을 예술로 생각하고, 장인정신이 없는 코딩은 스스로 만족하지 못해 몸을 빌빌 꼬는 제 입장에서 볼 때 말입니다. (모로가도 돌아가기만 하면 된다. 오픈만 빨리하면 된다. 라고 생각하시는 일부 혹은 대다수의 어떤분들과는 매우 사이가 안좋아질 가능성이 농후한거죠.)

자신의 코드에 애착을 갖고, 자신의 작업 결과물에 자부심을 느끼며, 그 성과물로 인정을 받는 정직한 소프트웨어 엔지니어가 많아지기를 기도하며, 뒷북울리기를 그만 할랍니다. (5분 쉬었으니 이제 다시 일하러.. ;ㅁ;)

ps. clearable_pool이라는 쓸만한 템플릿을 완성한지라 조만간 포스팅할지도 모르겠습니다아.

ps2. 아 편집하다 날아간 내용이 있어서.. Daum과 Naver양사 모두 CCL을 위반한 케이스가 됩니다만(문제의 라이브러리), 문제가 되는 flexInput은 Naver가 Daum코드를 가져다 쓴게 맞는듯 합니다. 냐앙.

글쓴이: crowmania

Chief Developer in Somansa Guitar/Vocal in Tonics Member of Justice Party

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다