거짓말과 착각은 전혀 다른 문제일지 모르지만 사실 알고 보면 굉장히 밀접한 관계가 있다. 네이버에서 사전상 의미를 찾아봤다.
예를 들어 철수라는 사람이 이런말을 한다.
철수 : 나는 아이큐 400의 천재다.
철수는 천재가 아닌데 스스로는 천재로 지각하고 있고 스스로 그렇게 믿고 있으니 착각이다. 하지만, 남들이 보기에는 거짓말이 되어버린다(머리속에서는 허모씨가 떠오르겠지만, 그 얘기를 하려는 것은 아니다. :p ).
나는 오픈 소스, 공개 프로그램 정책을 제법 싫어하는 편이다(하지만 그것들의 모든 장점을 전면적으로 부정하려 드는 것은 아니다). 분명 더 많은 장점이 있는 것은 사실이지만, 많은 단점이 있고, 그것들의 문제가 시너지 효과로 점점 커지고 있는 것을 우려하고 있다.
현재 인터넷의 발달, 그리고 오픈 소스의 의식 발달로, 많은 소스들은 쉽게 접할 수 있다. 이것이 정말 필요한 사람에게는 도움이 되겠지만, 실제로는 오히려 방해가 되는데, 스스로 필요하다고 느끼고 이것에 너무 많은 의지를 받는 경향이 있다.
나는 프로그래밍은 머리를 쓰는 것이라 생각한다. 물론 거기에 경험까지 더해지면 금상첨화. 하지만 경험의 실무가 아니라면, 프로그램은 최대한 머리를 쓰고 훈련을 해야 한다. 오픈 소스는 그것에 치명적인 타격을 준다.
흔히들 한번 짜본 프로그램은 다시 짤때 훨씬 쉽게 짤 수 있다고 말을 한다. 이것은 명백한 경험적 사실이다. 더 나아가면 '한번 본 소스' 역시 더 쉽게 짤 수 있다고 볼 수 있다.
여기서 착각과 거짓말이 구분된다.
어떤 프로그래머(혹은 학생)가 다른 사람들의 소스를 잠깐 본다. 그 후 나중에 그 프로그램을 짤 때 자기도 모르게 수월하게 짤 수 있다. 스스로는, '이것은 순전히 내가 짰다' 라고 생각하겠지만, 실제로는 예전에 봤던 코드, 혹은 코드의 흐름들이 희미하게 남아 있기 때문에 훨씬 쉽게 짤 수 있었던 것이다. 과연 그것이 스스로 짰다고 말을 할 수 있을까? 그렇다면 책을 옆에다 두고 그대로 변수 이름 바꿔가면서 짜는 것과, 책을 외우고나서 직접 짜는 것과는 어떤 차이가 있을까...
사실상 많은 상황에서는 니가 짰느냐, 남이 짰느냐는 그다지 문제가 되지 않는다. 중요한건, 머리를 썼느냐 기억만 들춰냈느냐이다. 스스로는 자신이 머리를 써서 짰다고 생각하겠지만, 실상 알고보면 기억을 들추어 다른 소스에서 나와 있던 '해답'을 기억해 내고 그것을 베껴쓴 것 밖에 안된다(그 다음에 할일은 버그 잡기이다. 일반적으로 외부 소스에 의존을 많이 할 수록 버그가 많이 나올 수 밖에 없다).
스스로 짜는 훈련이 되지 않는다면, 코딩 실력이 늘리가 없다. 알고리즘을 다 이해하고, 그 설명만으로 코딩을 하다보면 많은 에러를 접하게 되고, 그 과정에서 많은 것을 얻게 된다. 하지만 코드을 보고 그것으로 알고리즘을 이해하다보면, 나중에는 코드 없이는 설명을 이해할 수도 없고, 이해한다 하더라도 코딩을 하는데 큰 어려움이 따를 수 밖에 없다. 본보기가 되는 코드가 항상 있어 왔는데, 그것이 없으니 될리가 있을까...
물론 이것은 또 하나의 측면이고, 반대되는 의견으로도 얼마든지 많은 얘기를 할 수가 있다. 쉽게 반론하자면, 이렇게 말할 수 있다.
'세상에 순수하게 자신의 머리속에서 나온 창작이 어디있겠는가... 수학 문제 풀이도 많은 자료구조/알고리즘도 그렇고 따지고보면 남들이 했던 것들을 그대로 쓰는 것이지 않은가'
NIH(위키 링크) 라는 말이 있다. Not Invented Here('여기서 만들어지지 않은') 의 약자인데, 이런 단어가 존재한다는 것 자체로도 제법 흥미롭다고 볼 수 있다. 위키에는 Mac OS 의 예시가 나온다.
실제로 이런 현상들은 많이 발견될 수 있다. 좋은, 그리고 검증된 오픈 소스 프로그램들이 많은데, 그것을 사용하느니 직접 개발하는 경우가 많다(나도 오픈 소스를 거의 사용하거나 참고하지 않는다).
결론적으로 양날의 검이라고 할 수 있다. 어느 쪽이던 한쪽으로만 과하면 좋지 않다. 내 경우는 남의 소스를 거의 참고 하지 않아, 필요한 기술이 필요할 때 최대한 좋은 책을 참고 하거나 기술의 원천이 되는 논문을 참고하려고 노력하는 편인데, 장점도 많지만, 시간이 너무 많이 걸린다는 심각한 단점이 있다(그리고 검증된 것들 보다 나은 경우가 그렇게 많지 않다는 것도 문제라고 할 수 있겠다). 그리고 비슷한 관점의 얘기로, 바퀴를 다시 발명할 필요가 없다는 말이 있다[1]. 물론 이 바퀴 얘기도 검색을 해보면 많은 반대 논의가 이루어지기도 한다[2].
역시 그 양쪽 방향 사이를 잘 오고 가는 것이 가장 좋겠지만, 다양성을 인정한다면 어느 한쪽에 있는 것도 나름대로의 개성이라고 할 수 있을지 모르겠다.
ps. 오픈 소스의 단점들에 대해서 말을 하고 싶은데, 나름대로 신중하게 해야 되는 얘기라 선뜻 포스팅을 못하고 있다. 좀 더 구체적으로 자료 수집을 시작해야지 않그러면 영영 쓰지 못할 것 같다.
거짓말 : 사실이 아닌 것을 사실인 것처럼 꾸며 대어 말을 함. 또는 그런 말.한 개인의 입장에서 보면 이 둘은 전혀 다르다. 하지만 다른 사람의 입장에서 보면 얘기가 달라진다.
착각 : 어떤 사물이나 사실을 실제와 다르게 지각하거나 생각함.
예를 들어 철수라는 사람이 이런말을 한다.
철수 : 나는 아이큐 400의 천재다.
철수는 천재가 아닌데 스스로는 천재로 지각하고 있고 스스로 그렇게 믿고 있으니 착각이다. 하지만, 남들이 보기에는 거짓말이 되어버린다(머리속에서는 허모씨가 떠오르겠지만, 그 얘기를 하려는 것은 아니다. :p ).
나는 오픈 소스, 공개 프로그램 정책을 제법 싫어하는 편이다(하지만 그것들의 모든 장점을 전면적으로 부정하려 드는 것은 아니다). 분명 더 많은 장점이 있는 것은 사실이지만, 많은 단점이 있고, 그것들의 문제가 시너지 효과로 점점 커지고 있는 것을 우려하고 있다.
현재 인터넷의 발달, 그리고 오픈 소스의 의식 발달로, 많은 소스들은 쉽게 접할 수 있다. 이것이 정말 필요한 사람에게는 도움이 되겠지만, 실제로는 오히려 방해가 되는데, 스스로 필요하다고 느끼고 이것에 너무 많은 의지를 받는 경향이 있다.
나는 프로그래밍은 머리를 쓰는 것이라 생각한다. 물론 거기에 경험까지 더해지면 금상첨화. 하지만 경험의 실무가 아니라면, 프로그램은 최대한 머리를 쓰고 훈련을 해야 한다. 오픈 소스는 그것에 치명적인 타격을 준다.
흔히들 한번 짜본 프로그램은 다시 짤때 훨씬 쉽게 짤 수 있다고 말을 한다. 이것은 명백한 경험적 사실이다. 더 나아가면 '한번 본 소스' 역시 더 쉽게 짤 수 있다고 볼 수 있다.
여기서 착각과 거짓말이 구분된다.
어떤 프로그래머(혹은 학생)가 다른 사람들의 소스를 잠깐 본다. 그 후 나중에 그 프로그램을 짤 때 자기도 모르게 수월하게 짤 수 있다. 스스로는, '이것은 순전히 내가 짰다' 라고 생각하겠지만, 실제로는 예전에 봤던 코드, 혹은 코드의 흐름들이 희미하게 남아 있기 때문에 훨씬 쉽게 짤 수 있었던 것이다. 과연 그것이 스스로 짰다고 말을 할 수 있을까? 그렇다면 책을 옆에다 두고 그대로 변수 이름 바꿔가면서 짜는 것과, 책을 외우고나서 직접 짜는 것과는 어떤 차이가 있을까...
사실상 많은 상황에서는 니가 짰느냐, 남이 짰느냐는 그다지 문제가 되지 않는다. 중요한건, 머리를 썼느냐 기억만 들춰냈느냐이다. 스스로는 자신이 머리를 써서 짰다고 생각하겠지만, 실상 알고보면 기억을 들추어 다른 소스에서 나와 있던 '해답'을 기억해 내고 그것을 베껴쓴 것 밖에 안된다(그 다음에 할일은 버그 잡기이다. 일반적으로 외부 소스에 의존을 많이 할 수록 버그가 많이 나올 수 밖에 없다).
스스로 짜는 훈련이 되지 않는다면, 코딩 실력이 늘리가 없다. 알고리즘을 다 이해하고, 그 설명만으로 코딩을 하다보면 많은 에러를 접하게 되고, 그 과정에서 많은 것을 얻게 된다. 하지만 코드을 보고 그것으로 알고리즘을 이해하다보면, 나중에는 코드 없이는 설명을 이해할 수도 없고, 이해한다 하더라도 코딩을 하는데 큰 어려움이 따를 수 밖에 없다. 본보기가 되는 코드가 항상 있어 왔는데, 그것이 없으니 될리가 있을까...
물론 이것은 또 하나의 측면이고, 반대되는 의견으로도 얼마든지 많은 얘기를 할 수가 있다. 쉽게 반론하자면, 이렇게 말할 수 있다.
'세상에 순수하게 자신의 머리속에서 나온 창작이 어디있겠는가... 수학 문제 풀이도 많은 자료구조/알고리즘도 그렇고 따지고보면 남들이 했던 것들을 그대로 쓰는 것이지 않은가'
NIH(위키 링크) 라는 말이 있다. Not Invented Here('여기서 만들어지지 않은') 의 약자인데, 이런 단어가 존재한다는 것 자체로도 제법 흥미롭다고 볼 수 있다. 위키에는 Mac OS 의 예시가 나온다.
During the evolution of Mac OS through OS 9, many user interface innovations of other operating systems were not adopted because they went against, or were not discussed in, Apple's original human interface guidelines.
OS 9 을 거친 Mac OS 의 발전 기간 중, 다른 OS 의 많은 유저 인터페이스의 신 기술들이 애플의 휴먼 인터페이스 가이드라인을 따르지 않거나, 논의 되지 않았다는 이유로 채택되지 않았다.
OS 9 을 거친 Mac OS 의 발전 기간 중, 다른 OS 의 많은 유저 인터페이스의 신 기술들이 애플의 휴먼 인터페이스 가이드라인을 따르지 않거나, 논의 되지 않았다는 이유로 채택되지 않았다.
실제로 이런 현상들은 많이 발견될 수 있다. 좋은, 그리고 검증된 오픈 소스 프로그램들이 많은데, 그것을 사용하느니 직접 개발하는 경우가 많다(나도 오픈 소스를 거의 사용하거나 참고하지 않는다).
결론적으로 양날의 검이라고 할 수 있다. 어느 쪽이던 한쪽으로만 과하면 좋지 않다. 내 경우는 남의 소스를 거의 참고 하지 않아, 필요한 기술이 필요할 때 최대한 좋은 책을 참고 하거나 기술의 원천이 되는 논문을 참고하려고 노력하는 편인데, 장점도 많지만, 시간이 너무 많이 걸린다는 심각한 단점이 있다(그리고 검증된 것들 보다 나은 경우가 그렇게 많지 않다는 것도 문제라고 할 수 있겠다). 그리고 비슷한 관점의 얘기로, 바퀴를 다시 발명할 필요가 없다는 말이 있다[1]. 물론 이 바퀴 얘기도 검색을 해보면 많은 반대 논의가 이루어지기도 한다[2].
역시 그 양쪽 방향 사이를 잘 오고 가는 것이 가장 좋겠지만, 다양성을 인정한다면 어느 한쪽에 있는 것도 나름대로의 개성이라고 할 수 있을지 모르겠다.
ps. 오픈 소스의 단점들에 대해서 말을 하고 싶은데, 나름대로 신중하게 해야 되는 얘기라 선뜻 포스팅을 못하고 있다. 좀 더 구체적으로 자료 수집을 시작해야지 않그러면 영영 쓰지 못할 것 같다.
- 이 얘기를 처음 한 사람이 누군지는 모르겠다. 그냥 속담 같은 것인가... [본문으로]
- 참고 : 썰렁한 엔지니어 - 바퀴를 다시 발명하는 것, PerlMonk - Re-inventing the wheel is a 'Good Thing' [본문으로]







460429
227
954







댓글을 달아 주세요
'오픈된 소스'와 '오픈 소스'를 구별하면 더 좋은 논의가 될 것 같습니다. 오픈 소스는 단순히 소스 코드가 오픈되어 있다는 것을 넘어 프로그램을 개발하는 방법론에 대한 이야기입니다. 만약 제가 짠 프로그램의 소스를 공개하되 참고만 허락하고 제안이나 수정을 허락하지 않는다면 이를 오픈 소스라고 할 수 없습니다. 진정한 오픈소스는 참여를 유도하고 자유를 보장하며 효율적인 협업을 통해서 프로그램 개발의 생산성을 극대화하려는 노력이자 그 시스템이니까요.
정말 그렇네요..
지적 감사합니다...
:-)
단순히 다른 소스에서 나와 있던 '해답'을 기억하기 보다 최대한 그 과정을 이해하려고 노력하는 것도 중요하다고 생각합니다.
그렇지만 책을보고 직접 구현한거보다 남의 소스를 이해해서 구현한건 쉽게 잊혀지더군요..
확실히, 쉽게 얻은건 쉽게 사라지는거 같습니다.. ㅎㅎ