NIH(Not invented here) 신드롬이란?
카츠와 알렌(Katz & Allen)은 기업연구에서 “선진 기업의 연구조직은 흔히 자신들이 직접 개발하지 않은 기술이나 연구 성과에 대해 배타적 성향으로 보인다”고 주장하며 이러한 현상을 NIH 신드롬이라고 정의했다.
소프트웨어를 개발하는데 있어서도 NIH신드롬과 유사한 현상이 많이 발생합니다.
개발하는데 필요한 라이브러리나 개발 방법, 개발툴들을 모두 입맛에 맞게 직접 만들어서 쓰는 경우를 말하는 겁니다.
우리나라의 개발자들이나 소프트웨어 회사들은 특히나 더 자신만의 방법들을 선호하는 경향이 있는 것으로 생각됩니다. 여러가지가 이유가 있겠지만 몇가지만 나열해보면 다음과 같습니다.
- 라이브러리를 구매하는 비용을 비싸다고 생각한다. 특히나 회사에서 개발에 필요한 라이브러리는 잘 안사준다.
- 더 좋은 방법이나 라이브러리, 툴이 있을 수도 있지만 이것들을 찾을 시간이 없이 바쁘거나 귀찮다.
- 관련 자료들이 대부분 영어로 되어 있는데 영어가 딸려서 영어로 된 자료는 꺼려한다.
- 외부의 기술이나 방법은 자신이나 회사의 상황에 맞지 않는다고 생각한다.
- 자신의 기술과 실력이 더 우월하다고 생각한다.
- 주변에 경험이 많은 선배들이 적어서 자문을 구하기가 어렵다.
이러한 현상은 집을 만들어야 하는 사람이 나에게 알맞은 망치는 내가 더 잘 만든다고 생각하고 망치도 직접 만드는 것과 비교할만 합니다.
| 상용 라이브러리는 비싸다. |
흔히들 상용라이브러리는 너무 비싸다고 생각하고 직접 만들어 쓰는 경향들이 있습니다. 하지만 직접 만들어 쓸 때 발생하는 유지보수 비용은 미처 생각하지 못하고 이런 결정을 하는 경우들이 많습니다. 아니 이런것들을 고려하는 것은 커녕 개발자들이 무슨 라이브러리를 만들었는지 회사에서는 또는 동료들은 잘 모르는 경우도 있습니다.
물론 세상에 이전에는 없었던 라이브러리던가 진짜 그 회사만의 독특한 상황을 반영한 라이브러리나 툴이 없는 경우는 예외일 것입니다. 경계할 것은 이런 경우는 그렇게 흔하지 않기 때문에 착각하면 안될 것입니다.
일단 직접 만들고 나면 유지보수 비용이 상용 라이브러리를 썼을 때보다 비용이 몇배 더 드는 경우가 아주 흔합니다. 이때 직접 개발한 것이 훨씬 비싸다는 것을 깨달았어도 이쯤되면 다시 되돌리기가 매우 어렵습니다. 앞으로도 비용이 계속 더 들 것이지만 이를 되돌리는데도 너무 비용이 많이 들기 때문에 그냥 계속 가는 수밖에 없는 경우가 많습니다.
요즘은 오픈 소스 라이브러리가 매우 많으므로 선택의 폭이 매우 넓습니다. 이때 오픈 소스를 수정해서 쓰게 되면 나중에 오픈 소스가 업그레이드 되었을 때 머지(Merge)하는 것이 어려울 수 있으므로 이에 따른 비용도 감안해서 검토해야 합니다.
| 직접 만들 시간은 있어도 남이 만든 좋은 것을 찾을 시간은 없다. |
사실 대한민국의 개발자들은 항상 바쁜 것처럼 보입니다. 그래서 차분하게 검토할 여유가 없습니다. 이는 매우 안타깝게 생각합니다. 또한 뭔가 계속 코딩을 해야 일한 것 같은 분위기는 검토하는데 시간을 쏟는 것을 어렵게 만듭니다.
라이브러리를 무작정 직접 만들기보다는 쓰기 적합한 좋은 상용라이브러리가 없는지 미리 검토하는데 시간과 노력을 투자하는 것이 대충 만들어 놓고 나중에 후회하는 것보다는 훨씬 효율적입니다. 물론 모든 검토 결과 직접 만들어 쓰거나 오픈 소스를 수정해서 사용하는 것이 더 좋다는 결론이 날 수도 있습니다. 하지만 이런 결정을 하기 위해서 쏟은 노력과 시간은 그렇게 아깝지 않습니다.
| 영어자료는 꺼려진다. |
이 부분에 대해서는 할 말이 별로 없습니다. 영어는 소프트웨어 개발자를 평생 따라다닙니다. 꾸준히 공부하는 수 밖에 없을 겁니다.
| 이건 우리에게는 맞지 않다. |
"우리회사는 다르다."라고 생각하는 것은 착각입니다. 우리에게 필요한 것의 99.99%는 이미 다 나와 있다고 생각하면 됩니다. 즉, 있을 것은 다 있고 문제는 가격, 배우는 비용 등입니다.
그리고 프로세스나 툴을 보면 특히나 자신의 회사가 독특하다고 생각하는 사람들이 많습니다. 물론 이 세상에 똑같은 회사는 하나도 없습니다. 하지만 소프트웨어를 개발하는 방법은 거의 모든 회사가 별로 다르지 않습니다. 유명한 툴이나 흔히 사용하는 프로세스가 자신의 회사와는 맞지 않다면 자신의 회사에 딱 알맞은 것을 무조건 만들기보다는 회사의 프로세스가 잘못된 것이 아닌가 먼저 검토해보는 것이 좋습니다. 회사의 프로세스가 잘못된 경우가 99%입니다.
거꾸로 말하면 세계적인 툴이나 프로세스를 쓰면서 이에 적응해 가는 것이 개발을 더욱 효율적으로 만드는데 도움이 될 수 있습니다.
| 내가 더 잘한다. |
지금 내가 가지고 있는 지식은 99%이상 선각자들이 이룩해 놓은 것들입니다. 모짜르트도 제대로된 방법으로 훈련을 받지 못했으면 지금같이 위대한 작곡가가 되지 못했을 겁니다.
99%의 것을 배우는데 노력하고 거기에 내가 1%를 더하는 것이 올바른 방법일 겁니다.
물론 특정 분야에서 이전의 모든 선각자보다 뛰어난 사람이 있을 수 있습니다. 이렇게 뛰어난 개발자라면 그 실력을 망치를 만드는데 쓰기 보다는 빌딩을 만드는데 쓴다면 더 뛰어난 빌딩이 만들어 질 겁니다.
물론 망치를 제일 잘만드는 사람은 망치를 만들어서 팔면 될 것입니다.
| 물어보고 싶은데 물어볼 사람이 없다. |
이 부분도 안타깝습니다. 대분의 개발자들의 경험담을 들어보면 회사에 입사에서 별로 배우지 못했다고 합니다. 회사를 입사해서 스스로 거의 모든 것을 만들어야 했고 선배들이 별로 없는 경우가 많았고, 회사가 커진 다음에 입사를 한 경우에도 선배들도 유지보수에 바빠서 각자 개발하느라고 정신이 없어서 선배들에게 별로 배울 기회가 없었다고들 합니다.
다행이라면 요즘은 인터넷을 통한 소셜 커뮤니티가 발달해서 정보를 공유하기 훨씬 수월해졌습니다. 이런 다양한 외부 자원들을 활용하는 것도 좋은 방법입니다.
| 결론 |
소프트웨어를 개발하면서 내가 겪는 거의 모든 상황은 이전에도 있었습니다. 그것도 매우 여러번 발생했었고 그에 대한 해결책도 이미 다 나와있습니다. 라이브러리, 툴, 프로세스 거의 모든 것이 이미 나와있고 이중에서 꼭 필요한 것을 제대로 찾아서 사용하는 것이 매우 중요하며 쉽지 않은 일입니다.
뭔가 툴이나 라이브러리를 만들고 싶으시면 한번 더 생각해봅시다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
