NIH(Not invented here) 신드롬이란?
카츠와 알렌(Katz & Allen)은 기업연구에서 “선진 기업의 연구조직은 흔히 자신들이 직접 개발하지 않은 기술이나 연구 성과에 대해 배타적 성향으로 보인다”고 주장하며 이러한 현상을 NIH 신드롬이라고 정의했다.
소프트웨어를 개발하는데 있어서도 NIH신드롬과 유사한 현상이 많이 발생합니다.
개발하는데 필요한 라이브러리나 개발 방법, 개발툴들을 모두 입맛에 맞게 직접 만들어서 쓰는 경우를 말하는 겁니다.
우리나라의 개발자들이나 소프트웨어 회사들은 특히나 더 자신만의 방법들을 선호하는 경향이 있는 것으로 생각됩니다. 여러가지가 이유가 있겠지만 몇가지만 나열해보면 다음과 같습니다.
- 라이브러리를 구매하는 비용을 비싸다고 생각한다. 특히나 회사에서 개발에 필요한 라이브러리는 잘 안사준다.
- 더 좋은 방법이나 라이브러리, 툴이 있을 수도 있지만 이것들을 찾을 시간이 없이 바쁘거나 귀찮다.
- 관련 자료들이 대부분 영어로 되어 있는데 영어가 딸려서 영어로 된 자료는 꺼려한다.
- 외부의 기술이나 방법은 자신이나 회사의 상황에 맞지 않는다고 생각한다.
- 자신의 기술과 실력이 더 우월하다고 생각한다.
- 주변에 경험이 많은 선배들이 적어서 자문을 구하기가 어렵다.
이러한 현상은 집을 만들어야 하는 사람이 나에게 알맞은 망치는 내가 더 잘 만든다고 생각하고 망치도 직접 만드는 것과 비교할만 합니다.
| 상용 라이브러리는 비싸다. |
흔히들 상용라이브러리는 너무 비싸다고 생각하고 직접 만들어 쓰는 경향들이 있습니다. 하지만 직접 만들어 쓸 때 발생하는 유지보수 비용은 미처 생각하지 못하고 이런 결정을 하는 경우들이 많습니다. 아니 이런것들을 고려하는 것은 커녕 개발자들이 무슨 라이브러리를 만들었는지 회사에서는 또는 동료들은 잘 모르는 경우도 있습니다.
물론 세상에 이전에는 없었던 라이브러리던가 진짜 그 회사만의 독특한 상황을 반영한 라이브러리나 툴이 없는 경우는 예외일 것입니다. 경계할 것은 이런 경우는 그렇게 흔하지 않기 때문에 착각하면 안될 것입니다.
일단 직접 만들고 나면 유지보수 비용이 상용 라이브러리를 썼을 때보다 비용이 몇배 더 드는 경우가 아주 흔합니다. 이때 직접 개발한 것이 훨씬 비싸다는 것을 깨달았어도 이쯤되면 다시 되돌리기가 매우 어렵습니다. 앞으로도 비용이 계속 더 들 것이지만 이를 되돌리는데도 너무 비용이 많이 들기 때문에 그냥 계속 가는 수밖에 없는 경우가 많습니다.
요즘은 오픈 소스 라이브러리가 매우 많으므로 선택의 폭이 매우 넓습니다. 이때 오픈 소스를 수정해서 쓰게 되면 나중에 오픈 소스가 업그레이드 되었을 때 머지(Merge)하는 것이 어려울 수 있으므로 이에 따른 비용도 감안해서 검토해야 합니다.
| 직접 만들 시간은 있어도 남이 만든 좋은 것을 찾을 시간은 없다. |
사실 대한민국의 개발자들은 항상 바쁜 것처럼 보입니다. 그래서 차분하게 검토할 여유가 없습니다. 이는 매우 안타깝게 생각합니다. 또한 뭔가 계속 코딩을 해야 일한 것 같은 분위기는 검토하는데 시간을 쏟는 것을 어렵게 만듭니다.
라이브러리를 무작정 직접 만들기보다는 쓰기 적합한 좋은 상용라이브러리가 없는지 미리 검토하는데 시간과 노력을 투자하는 것이 대충 만들어 놓고 나중에 후회하는 것보다는 훨씬 효율적입니다. 물론 모든 검토 결과 직접 만들어 쓰거나 오픈 소스를 수정해서 사용하는 것이 더 좋다는 결론이 날 수도 있습니다. 하지만 이런 결정을 하기 위해서 쏟은 노력과 시간은 그렇게 아깝지 않습니다.
| 영어자료는 꺼려진다. |
이 부분에 대해서는 할 말이 별로 없습니다. 영어는 소프트웨어 개발자를 평생 따라다닙니다. 꾸준히 공부하는 수 밖에 없을 겁니다.
| 이건 우리에게는 맞지 않다. |
"우리회사는 다르다."라고 생각하는 것은 착각입니다. 우리에게 필요한 것의 99.99%는 이미 다 나와 있다고 생각하면 됩니다. 즉, 있을 것은 다 있고 문제는 가격, 배우는 비용 등입니다.
그리고 프로세스나 툴을 보면 특히나 자신의 회사가 독특하다고 생각하는 사람들이 많습니다. 물론 이 세상에 똑같은 회사는 하나도 없습니다. 하지만 소프트웨어를 개발하는 방법은 거의 모든 회사가 별로 다르지 않습니다. 유명한 툴이나 흔히 사용하는 프로세스가 자신의 회사와는 맞지 않다면 자신의 회사에 딱 알맞은 것을 무조건 만들기보다는 회사의 프로세스가 잘못된 것이 아닌가 먼저 검토해보는 것이 좋습니다. 회사의 프로세스가 잘못된 경우가 99%입니다.
거꾸로 말하면 세계적인 툴이나 프로세스를 쓰면서 이에 적응해 가는 것이 개발을 더욱 효율적으로 만드는데 도움이 될 수 있습니다.
| 내가 더 잘한다. |
지금 내가 가지고 있는 지식은 99%이상 선각자들이 이룩해 놓은 것들입니다. 모짜르트도 제대로된 방법으로 훈련을 받지 못했으면 지금같이 위대한 작곡가가 되지 못했을 겁니다.
99%의 것을 배우는데 노력하고 거기에 내가 1%를 더하는 것이 올바른 방법일 겁니다.
물론 특정 분야에서 이전의 모든 선각자보다 뛰어난 사람이 있을 수 있습니다. 이렇게 뛰어난 개발자라면 그 실력을 망치를 만드는데 쓰기 보다는 빌딩을 만드는데 쓴다면 더 뛰어난 빌딩이 만들어 질 겁니다.
물론 망치를 제일 잘만드는 사람은 망치를 만들어서 팔면 될 것입니다.
| 물어보고 싶은데 물어볼 사람이 없다. |
이 부분도 안타깝습니다. 대분의 개발자들의 경험담을 들어보면 회사에 입사에서 별로 배우지 못했다고 합니다. 회사를 입사해서 스스로 거의 모든 것을 만들어야 했고 선배들이 별로 없는 경우가 많았고, 회사가 커진 다음에 입사를 한 경우에도 선배들도 유지보수에 바빠서 각자 개발하느라고 정신이 없어서 선배들에게 별로 배울 기회가 없었다고들 합니다.
다행이라면 요즘은 인터넷을 통한 소셜 커뮤니티가 발달해서 정보를 공유하기 훨씬 수월해졌습니다. 이런 다양한 외부 자원들을 활용하는 것도 좋은 방법입니다.
| 결론 |
소프트웨어를 개발하면서 내가 겪는 거의 모든 상황은 이전에도 있었습니다. 그것도 매우 여러번 발생했었고 그에 대한 해결책도 이미 다 나와있습니다. 라이브러리, 툴, 프로세스 거의 모든 것이 이미 나와있고 이중에서 꼭 필요한 것을 제대로 찾아서 사용하는 것이 매우 중요하며 쉽지 않은 일입니다.
뭔가 툴이나 라이브러리를 만들고 싶으시면 한번 더 생각해봅시다.
회사에서 필요한기능은 A인데 라이브러리에 포함된 기능은 A,B,C 일때 웬지 부하는 걸리지않을까 라는 걱정이 생기는것도 한몫 하지않을까요?
답글삭제여러 라이브러리를 아는것도 실력인것같습니다~~재밌는글 잘봤습니다
오산돌구님 안녕하세요.
답글삭제좋은 지적이십니다.
실제로 외부 라이브러리를 선택할 때 이런 종류의 이슈들을 많이 접하게 됩니다.
우선 말씀하신 것처럼 내가 쓰지 않는 기능도 많이 포함되어 있을 경우.
또, General하게 만들다보니 성능이 느린 경우.
64bit나 unicode를 지원하지 않는 경우.
i18n이 적용되지 않은 경우.
이런 경우 조사나 공부를 더 해보면 해결 되는 경우도 있고, 결국에는 해결책이 없어서 직접 만들거나 수정해서 쓸 수도 있습니다.
또는 라이브러리를 만드는 회사에 변경 요청을 하는 경우가 있습니다. 이런 과정을 거치면서 더 많은 지식을 쌓게 되고 결론이 어떻게 나든 그 과정이 가치 있게 되곤 합니다.
예전 회사에서 엔진채용을 심각하게 고민했는데 엔진을 적응하는데 걸리는 시간에 차라리 필요한 기능을 만드는게 더 빨라서 새로운 라이브러리를 꺼리게 되는 경우도 생기더라고요...
답글삭제적응되면 사온 엔진이 편하겠지만서도 엔진 사면 프로젝트 끝나는줄 아는 경영진들이 많아서 말이죠....
안녕하세요. black_H님
답글삭제"엔진을 사는 것보다 매우는 것이 더 빠르다"....
아주 좋은 경험담입니다. 저도 실제로 이런 경험담을 매우 자주 듣습니다. 단기적으로는 대단히 맞는 말입니다.
하지만 몇달 장사하다 말것이 아니면 이런 판단이 문제가 생기는 경우가 많습니다.
나중에 계속 업그레이드를 하다보면 사오려고 했던 엔진의 속에 숨어있는 엄청난 기능들을 계속 발견하게 되고 우리 엔진에 기능을 계속 추가하고 버그잡고 유지보수하다 보면 사오는 비용보다 훨씬 커지는 경우가 많습니다.
경영층에게도 엔진이 제품에서 차지하는 위치나 역할을 잘 보여줘야 하는데 변변한 문서도 없다면 경영층이 오해를 할 수도 있습니다. 엔진을 사오는 이유는 제품을 만든는데 집중하기 위해서인데 엔진만 사오면 제품의 거의 다 끝난 것으로 착각한다면 문제입니다.
아무리 좋은 엔진과 라이브러리를 많이 사와도 제품을 하나 만들려면 엄청남게 많고 또 귀찮은 일들이 남아 있죠. 이런 것들은 사실 재미도 없는 부분이 많거든요. 그래서 재미있고 도전의식에 불을 댕기는 엔진이나 라이브러리쪽으로 끌리는 것인지도 모르겠습니다.
안녕하세요, 전규현 님,
답글삭제책도 잘보고, 블로그도 즐겁게 보고 있습니다.
저희 팀도 이 부분에 대해서 많은 도전과 실수를 반복하고 있는데
조언해주신대로 이미 만들어진 Library를 적용하는 방향으로 선회하는 중입니다.
그러면서 드는 질문은 그러면 import 하는 것과 inhouse의 비율 혹은 무엇을 스스로 만들고, 어떤 것을 이미 개발 된 것을 적용할까 하는 질문이 듭니다.
이번 글은 이미 만들어 진 것을 사용하는 것에 대한 장점이라면,
스스로 만들어야 하는 것들의 장점, 혹은 이런 것은 반드시 스스로 만들어야 한다 하는 내용을 글을 한번 써주시면 어떨런지요. (혹은 link) 그 부분을 이해하면 그 부분 빼고는 가져다 혹은 사서 쓰는 것이 좋은거구나 하고 이해할 수 있을 것 같아서요.
고맙습니다.
조엘 온 소프트웨어의 글이 떠오릅니다.
답글삭제http://www.joelonsoftware.com/articles/fog0000000007.html
아마도 자기 회사의 핵심 역량은 직접 만들되, 핵심이 아닌 것은 사서 쓴다가 정답인 것 같습니다.
안녕하세요. 제임스님
답글삭제제 책과 블로그를 즐겁게 보고 계시다니 고맙습니다.
네 말씀하신 것과 같이 inhouse를 완전히 피할 수는 없겠죠. 사례를 중심으로 이 주제에 대해서도 글을 써도 좋겠네요.
감사합니다.
안녕하세요. 주의사신님
답글삭제좋은 얘기하는 사람은 많은데 그걸 보고 바뀌기는 대단히 어렵습니다. 그래도 아주 약간씩은 바뀌어 가겠죠.
저는 실제 겪는 경험을 위주로 쉽게 풀어서 써보려고 노력하고 있습니다.
사용하려는 모듈이 프로젝트와 맞지 않거나
답글삭제수정이 과도하게 들어가야 하므로 직접 개발하는게 편해 보이기도 하는데
문제는 하다보면 그게 바로 시궁창으로 빠지는 길이기도 하죠 ^^;
오픈소스 특성상 누군가에게 책임을 물수 없다는 것도
개발자들이 직접 모듈을 개발할 수 밖에 없는 함정에 빠지는 이유가 아닐까 생각이 됩니다.
안녕하세요. 구차니님
답글삭제사실 이런 이유로 직접 개발해야 하는 경우도 있습니다.
그런데 개발이 특히 분석과 설계가 제대로 되지 않기 때문에 그런 경우가 많습니다.
분석과 설계가 제대로 진행이 된다면 설계단계 이전에 분석단계에서 어떤 라이브러리를 써야 하는지 미리 검토가 됩니다.
심지어는 이 때문에 기능이 바뀔 수도 있습니다. 기능을 조금 바꾸는 것이 라이브러리를 직접 만드는 것보다 더 효과적인 때가 많기 때문이죠.
대충 코딩부터 시작하고 필요한 라이브러를 찾는다면 세상에 입맛에 딱 맞는 것은 별로 없을 겁니다.
결국, 기본에 충실하면 다 해결되는 것입니다.
요즘, 경계해야 할 것 중의 하나가 오픈소스가져다가 수정하는 것인데 꼭 필요하면 그렇게 해야겠지만 대부분 추후 발생할 문제를 생각하지 않고 일단 저지르고 보는 것입니다. 만들 때는 뭔가 근사한 것 만든 것 같고 뿌듯하지만 몇년 후 심지어는 몇개월후에 본인이나 후배들이 엄청나고 고생하고 회사는 손해를 입을 수 있습니다. 하지말라는 것은 아니고 이것을 모두 감안하고 결정을 해야 한다는 것입니다.
오픈소스는 라이센스 위반하지 않는 것도 잊지 말고요. :)
우리나라현실에서 솔직히 딱 까놓고 얘기하자면
답글삭제세상의 널리 퍼진 유용한 정보에 관심이 없고
주위로 부터 조금 인정받는다고 자존심 센 어정쩡한 개발자들이 그러는 게 젤 많은 경우가 아닌가요?
다른곳으로부터 정보를 얻는것도 자기개발의 중요한 수단과 필수요소일텐데...
정말 피곤해...
스피드님 안녕하세요.
답글삭제저도 동감입니다. 자신이 아는 지식과 경험의 카테고리에 갇혀서 그 외에는 배척하려고 하는 개발자도 많습니다.