왜 보안은 필수적으로 가르치지 않는걸까요?

stmaestro의 이미지

웹프로그래밍 꽤나한다는 친구가
부르더군요.

자바, asp, 비쥬얼베이직을 좀 한다고...
하는 친구였는데.

부른 이유인 즉슨...
컴퓨터가 바이러스에 침투당해 죽어버린 상황이였습니다.

처음엔 웹프로그래밍 한다고 오~~ 그래?
라고 생각했는데.

이 친구.
윈도우 업데이트도 할 줄 모르더군요.

마지막에. 야~ 나 갈테니까 윈도우 업데이트로 보안패치 다 받아놔라.. 하는데 묻더군요.
어떻게 하냐고. 에....

무척이나 당황스러웠답니다.
아니 웹프로그래밍 기술도 안다는 얘가 보안에 대해선 아무것도 모르냐?

XP의 경우 서비스팩2를 안까는게 오히려 더 좋다는 이야기를 들었나봅니다. 그래서 이야기 해줬죠.
그런 컴퓨터 보안 상황에서 한달이나 버티나 보자고.

심지언...
제가 원격접속 해서 볼테니까 ip주소 알려달라고 했는데.
어떻게 보냐는 질문.
(농담이겠지란 생각이였건만. 흑흑.. 결국
cmd에서 ipconfig를 통해서 보라는걸..
그것도 ip주소가 그 많은 숫자중 어떤거냐고 물어보더군요.)

아흑..
왜..

보안이나 기본적인 사항들은
웹프로그래밍하는 사람이 안배우는건가요.

결국...
"우와~~ 웹프로그래밍도 해? 우와 L모 회사에서 일하나독. 대단하다"가
"뭐야. 장난하냐?" 로 바뀌어버렸습니다.

서비스팩도 깔줄 몰라요. 흑흑...
IPCONFIG물어볼땐 정말 장난치는줄 알았어요.

다음엔 바이러스와 악성코드 걱정없는
리눅스 데스크탑을 가르쳐 줄랍니다.
아흑...

아파치는 쓸줄 알면서.. 보안은 땡.. 이니..
바이러스는 잡히는데 치료는 돈낸다고 또 뭐라고 그러네요.
흑흑.. 그래서.. 그냥 보안엔 돈 아끼지 말라고 충고해줬죠.

결국 IE가 망가졌나봅니다.

파이어폭스를 추천해줬고. 흑흑. 파이어폭스가 뭐녜요..
지금은 IE는 안되고 파이어폭스 쓴데요..
넘한다. 웹프로그래밍 한다는 친구가..

creativeidler의 이미지

우움. 끝난 줄 알았던 건 또 저의 착각이었나봅니다.
to NeoTuring:
님의 글을 읽다가 xper에서 봤던 SimpleDesign토론이 생각났습니다. 그곳에서 누군가가 상대방의 주장은 전혀 이해하려 하지 않고 자기 주장만 반복하는 통에 토론이 소모적으로 흘렀고 김창준씨의 '토론최소주의' 덕분에 겨우 중단되었죠. 그걸 인용하려고 들어가서 딱 보니 웬걸, 그 사람이 네오튜링님이더군요-_- 그걸 보고나니 님과 생산적인 토론을 할 수 있으리란 생각은 안 듭니다. 죄송합니다.

to bluerain:
님과는 논점이 많이 좁혀진 것 같습니다. 이제는 한 가지만 말씀드리면 될 것 같습니다. 지금 논점은 알고리즘이 도움이 되느냐 아니냐가 아니라 기초인가 아닌가입니다. 농구할 때 렉드로 드리블하고 비하인드 백패스하고 더블클러치하면 도움 됩니다. 그걸로 이길 수도 있습니다. 하지만 그것이 농구의 기초입니까? 농구의 기초는 드리블, 패스, 슛이죠. 프로 농구 선수가 드리블, 패스, 슛 제대로 못하면 비웃을 만하죠. 하지만 렉드로 드리블 못한다고 비웃을 수 있습니까? 서장훈 뛰어넘고 덩크 못한다고 비웃을 수 있습니까?

알고리즘, 당연히 가르치면 좋습니다. 세상에 배워서 나쁜 게 뭐가 그리 많겠습니까. 하지만 이게 프로그래머의 필수 덕목은 아니라는 겁니다. 자바 프로그래머가 자바 문법도 잘 모른다... 비웃어도 안 말립니다. 오라클 DBA가 오라클 스타트도 못 시킨다... 비웃어도 좋습니다. JSP 코더가 CSS도 모르고 HTML도 모른다... 비웃어도 좋습니다. 하지만 알고리즘 모른다고 비웃을 수는 없습니다. 그건 사용되는 경우가 한정되어 있어서 기초라고 할 수 없기 때문입니다.

참고로 얼마 전 모 사이트에서 뽑은 Top 5 Must-read book에는 리팩토링, 디자인 패턴, UML 디스틸트, 프래그머틱 프로그래머, TDD By Example이 꼽혔습니다. 알고리즘? 없었습니다.

학생들에게 알고리즘 가르치는 거, 나쁘지 않습니다. 사고 훈련도 되고 교양도 넓혀주고 좋습니다. 그걸 말릴 생각은 없습니다. 하지만 그거 모른다고 기초가 부실한 프로그래머로 간주하지는 말아주십시오.
세상에는 알고리즘 전혀 모르지만 좋은 프로그램을 만들어내는 프로그래머가 많습니다.

NeoTuring의 이미지

creativeidler wrote:

to NeoTuring:
님의 글을 읽다가 xper에서 봤던 SimpleDesign토론이 생각났습니다. 그곳에서 누군가가 상대방의 주장은 전혀 이해하려 하지 않고 자기 주장만 반복하는 통에 토론이 소모적으로 흘렀고 김창준씨의 '토론최소주의' 덕분에 겨우 중단되었죠. 그걸 인용하려고 들어가서 딱 보니 웬걸, 그 사람이 네오튜링님이더군요-_- 그걸 보고나니 님과 생산적인 토론을 할 수 있으리란 생각은 안 듭니다. 죄송합니다.

제가 지향하는것은 "상대방의 주장을 전혀 이해하려 들지 않는것"이 아니라 상대와 토론을 통해 "엄밀하게 개념을 정립해 나가는것"입니다. 그 시절(?)의 토론역시도 제가 그 분들의 의견을 이해하지 못한것이 아니라 오히려 그곳분들께서 제 의도를 제대로 파악하지 못한 이유로-제 사고가 워낙에 정밀해서 그분들이 제 사고의 흐름을 제대로 읽어내지 못했다고 봅니다-마치 제가 잘못한것마냥 매도된것 뿐입니다. 그곳분들도 그랬지만, creativeidler님도 현재 제 의견에 대한 이렇다할 논리적인 반론을 제시해주지 못하고 계십니다.

"5. 4가 참이라면, 학교에서 배운 알고리즘의 적절한 사용으로 1이 자동으로 충족된다." 라는 전제로부터 저는 "협의의 알고리즘을 적절히 사용 할 수 있는 사람"을 "기초가 있는 프로그래머"라고 정의하겠습니다. 아마 이런 정의는 기존의 상식과 배치되는것이 아니기 때문에 어느 누가 보더라도 큰 무리가 없을걸로 생각합니다. 다시 말해 기초가 있는 프로그래머는 알고리즘을 적재적소에 유효적절하게 사용할 수 있는 능력을 가진 사람입니다. 그리고 이러한 사항은 디자인패턴에 대해서도 마찬가지로 적용되고, 개발방법론에 대해서도 마찬가지로 적용됩니다.

따라서 디자인패턴도 엉뚱한곳에 엉뚱하게 사용하는 경우는 철저히 배제됩니다. 그 경우는 디자인패턴을 제대로 이해하지 못하고 쓰는겁니다. 마찬가지 논리가 알고리즘에 대해서도 적용됩니다. 때문에 패턴오용이나 알고리즘오용의 경우를 말씀하실 필요가 전혀 없습니다. 그 경우는 오히려 제 논리를 뒷받침 하는 증거밖에 되지 않습니다. 알고리즘을 제대로 익히지 않았기 때문에 오용한다는것입니다.

물론 그렇다고 알고리즘의 적절한 사용이 알고리즘의 세부사항 전부를 익혀야 할것을 요구하는것이 아닙니다. 알고리즘에 대한 메타지식만 있으면 그것으로 충분하다고 보는겁니다. 그리고 이러한 정의에 의해 협의의 알고리즘 그 자체는 "기초"로 인정될 수 있습니다. "협의의 알고리즘을 적재적소에 유효적절하게"사용하기 위해서는 협의의 알고리즘을 어떤 방식으로든 제대로 익혀야 하기 때문입니다.

제가 여기서 "기초"를 먼저 정의하고, "기초가 있는 프로그래머"를 그로부터 유도해내지 않고 그 반대의 접근을 취한 이유는 전자의 접근을 취할 경우에서보다 실질적인 의미를 더 잘 포착해낼것으로 예상하기 때문입니다. "기초"라는 단어가 포괄하는 의미와 용도가 너무나 다양해서 기초라는 개념을 먼저 정의할수가 없고, 오히려 "기초가 있는 프로그래머"(=어떤것을 잘 수행할 수 있는 소양이 있는 프로그래머)라는 의미있는 맥락안에서 "기초"라는 단어가 어떻게 사용되어져야 하는지를 제대로 파악하고, 이로부터 "기초"가 무엇인지를 정의해 나가는것이 제대로된 순서라고 봤습니다. 이 쓰레드에서는 아무도 "기초"라는것의 개념을 제대로 정의해내지 못하고 있는데, 제가 접근하는 이런 방식을 통해서 "기초"가 정말 무엇인지가 더 명료해질 수 있다고 생각합니다. "패턴을 적절하게 사용할 수 있는 사람", "알고리즘을 적절하게 사용할 수 있는 사람", "여러 개발방법론을 적절하게 사용할 수 있는 사람" 이들이 모두 "기초가 있는 프로그래머"가 됩니다. 그리고 각각의 경우에 대해 각 소항목에 대한 메타지식 및 경험지식이 "기초"로서 정의될 수 있습니다. 여기까지 제 글을 보셨다면, creativeidler님은 제가 무엇을 의도하고 있는지 어느정도 감을 잡을 수 있으리라 봅니다. 이러저러한 얘기로 논지를 흐릴것이 아니라 제 글에 대해 제대로 반박을 해주셨으면 하는군요. 이미 제 글의 논리는 더 이상 반박될 수 없을것처럼 보입니다.

NeoTuring의 이미지

정리하겠습니다. 제 글에서 가장 기초가 되는 전제는 1항목입니다. 1을 달성하기 위한 수단으로 2, 3이 존재하고 4는 3항목의 필연적 귀결입니다. 5항목은 항목 4를 재차 설명한것뿐입니다. 이에 따라 5에서 "알고리즘의 적절한 사용"은 곧 프로그램이 개선되어야 한다는 1항목의 지지로 나타납니다. 자연스럽게 "알고리즘의 적절한 사용"은 "프로그램의 개선"이라는 결과를 주므로 이들간에 인과관계가 성립한다고 볼 수 있습니다. 그리고 "알고리즘의 적절한 사용"은 알고리즘을 제대로 익힐때 가능한 사항입니다. 즉, 알고리즘을 제대로 익힌 사람(기초가 있는 사람)이 그렇지 않은 사람에 비해 그만큼 프로그램을 더 잘 개선시킬 수 있습니다. 위에서의 정의를 받아들이고, 또 이러한 인과관계가 성립하는 한 creativeidler님은 "알고리즘이 기초가 아니다"라고 주장하실 수 없습니다.

cocas의 이미지

creativeidler wrote:

참고로 얼마 전 모 사이트에서 뽑은 Top 5 Must-read book에는 리팩토링, 디자인 패턴, UML 디스틸트, 프래그머틱 프로그래머, TDD By Example이 꼽혔습니다. 알고리즘? 없었습니다.

말꼬리 잡고 늘어지는 느낌이 좀 들어서 죄송합니다만 이건 부적절한 예입니다. 언급하신 책들은 '기초'에 해당하기 보다는 '기초'가 되는 사람들이 꼭 보고 넘어가야 할 책들인 것 같군요. 데이터 구조 같은 책 역시 위에 없지만 기초중의 기초입니다. 또 위의 것들은 보통 대학교 교과상에서 다루지 않는 실무분야입니다. 추천자가 피추천자들에 대해 생각할 때 '당연히 자료구조, 알고리즘, 자기가 다루는 언어의 문법등은 알고 있을꺼야' 라고 가정했다고 볼 수 있지 않을까요?

Quote:
세상에는 알고리즘 전혀 모르지만 좋은 프로그램을 만들어내는 프로그래머가 많습니다.

전 논란의 중심이 여기에 있다고 생각합니다. 과연 알고리즘 전혀 모르는 사람이 좋은 프로그램을 만들어 낼 수 있는가? 평균적으로 그러한 결과가 가능한가? ( 특출난 경우야 뭔들 못하겠습니까? :D )

전 알고리즘을 배울 때 알고리즘의 문제 해결 절차라고 배웠고 알고리즘을 잘 안다는 것은 알고리즘 리스트를 줄줄 꿰고 외우고 있는 게 아니라 문제가 주어졌을 때 이를 잘 해결한다는 것이라고 알고 있습니다. 제가 SI 쪽에 대한 경험이 전무한 상태여서 자세한 상황은 모릅니다만 문제 해결이라는 기본 전제는 다 같으리라 생각합니다. 문제 해결을 위한 절차 서술이 알고리즘의 서술 아닐까요?

creativeidler님이 알고리즘을 전혀 모르지만 좋은 프로그램을 제작하시는 분들은 이미 알게 모르게 알고리즘이라는 기초를 쌓고 있는 게 아닌가 싶습니다. 이게 알고리즘이라는 건 전혀 모른체요.

blueruin의 이미지

creativeidler wrote:
to bluerain:
님과는 논점이 많이 좁혀진 것 같습니다. 이제는 한 가지만 말씀드리면 될 것 같습니다. 지금 논점은 알고리즘이 도움이 되느냐 아니냐가 아니라 기초인가 아닌가입니다. 농구할 때 렉드로 드리블하고 비하인드 백패스하고 더블클러치하면 도움 됩니다. 그걸로 이길 수도 있습니다. 하지만 그것이 농구의 기초입니까? 농구의 기초는 드리블, 패스, 슛이죠. 프로 농구 선수가 드리블, 패스, 슛 제대로 못하면 비웃을 만하죠. 하지만 렉드로 드리블 못한다고 비웃을 수 있습니까? 서장훈 뛰어넘고 덩크 못한다고 비웃을 수 있습니까?

물론 제 주장(기본이 중요하다는)에는 알고리즘은 프로그래밍의 기초라는 의미를 내포하고 있습니다.
제가 들었던 예들도 그러하고요. (그 예들에 대해서 반론하신다면 좀더 구체적으로 이해할수 있을것 같습니다)
그리고 알고리즘은 렉드로 드리블, 비하인드 백패스,,(솔직히 잘 모르는 용어들이네요) 같은 화려한 테크닉이 아닌 패스정도의 기본기라고 생각하고 있습니다.
언어의 문법은 워킹이나 공잡는 법정도되겠네요.

creativeidler wrote:
참고로 얼마 전 모 사이트에서 뽑은 Top 5 Must-read book에는 리팩토링, 디자인 패턴, UML 디스틸트, 프래그머틱 프로그래머, TDD By Example이 꼽혔습니다. 알고리즘? 없었습니다.

문법은 왜 없을까요? 위에 같은 글이 있지만 좀 다른 의미의 must-read book 이라는것은 잘 아실거라 생각됩니다. (노파심이자만 여기서 문법은 특정언어지향적이라는 반론은 어울리지 않겠습니다.)

creativeidler wrote:
학생들에게 알고리즘 가르치는 거, 나쁘지 않습니다. 사고 훈련도 되고 교양도 넓혀주고 좋습니다. 그걸 말릴 생각은 없습니다. 하지만 그거 모른다고 기초가 부실한 프로그래머로 간주하지는 말아주십시오.
세상에는 알고리즘 전혀 모르지만 좋은 프로그램을 만들어내는 프로그래머가 많습니다.

전 학생들이 기본적인 공식(알고리즘)을 모른다면 기본적인 교양서적(알고리즘이 주를 이루는)을 추천해줍니다. 자신을 위해 배워두면 좋으니 배워두라는 의미입니다. 이것의 교육이 존재하는 일부이기도하고요.
알고리즘을 몰라도 좋은 프로그램을 만들 수 있다는 의견에는 백분인정하지만 기초에 충실하면 더 좋은 프로그램을 만들 수 있다는것의 또 다른 강조입니다. 물론 그것에는 기초적인 알고리즘이 기본이 된다는 뜻이기도 합니다.
알고리즘은 아주 바닥의 기본이기도 하며 최상위의 테크닉이기도 합니다.
기본없이 만들어내는 경험의 know-how는 꽁수가 되는 경우가 많으며 소프트웨어 공학에서 지양해야하는 방법론으로 정의하고 있습니다.
말씀대로 알고리즘이 프로그램의 기초인지 아닌지가 중요 논점인데 알고리즘이 어떤 문제를 효율적으로 처리하기위한 검증된 방법이라는 측면에서 충분히 기초가 된다고 생각합니다.

좀 답답한 마음에 수많은 알고리즘을 사용하면서도 왜 프로그래밍에 알고리즘의 이해가 필요없다고 하는지 모르겠습니다.
구구단은 외우면 그만이지(이건 동의 하십니까? 설마 외울필요도 없다고 생각하시는것은 아닌지..) 이해할필요없다는 이론과 크게 다르지 않다는 주장과 무엇이 틀린지 모르겠습니다.
프로그래밍에 있어 알고리즘의 유용함을 증명하는것은 수학에서 수많은 공식의 유용함을 증명하는것과 크게 다를것 없습니다.

"있으면 좋지만 없어도 그만"의 차이와 "있으면 더 좋은" 의 의미의 차이정도의... 작지만 큰 차이정도입니다.
이차이가 알고리즘이 프로그래밍의 기본인지 아닌지의 결정점이 된다면 충분히 수긍하고 제 주장 역시 충분히 어필하였다고 생각합니다.
그렇게 생각해도 맞는지요?

알고리즘의 그릇된 사용은 알고리즘의 이해부족에 비롯됩니다.
어떠한 문제를 해결하기 위해 가장 최적의 방법을 찾아 효율적인 결과를 얻는것은 모든 프로그래머의 이상입니다.
100만원짜리 컴퓨터가 50만원짜리 컴퓨터에 비해 두배의 성능이 있다고 1억짜리 컴퓨터가 5천만원짜리 컴퓨터에 비해 두배의 성능향상이 있을거라 기대할 순 없습니다.
하이엔드로 갈수록 작은 차이가 큰 가치를 만드는것입니다.

time to wait...

stmaestro의 이미지

계속 이야기가 삼천포로 빠진다는.....

자자.. 이쯤해서 후속이야기를 해드리겠습니다.

제가 수십통의 문자를 보냈죠.
침착하게 따라하라고

Quote:
일단 윈2000 서비스팩4를 네트웍 설치로 다운받아서
시디에 백업해놓고.
"랜선을 뽑은뒤."
윈도우를 깔아라. 그리고 연결하면 반드시 윈도우 업데이트를 해라
(근데 윈도우 업데이트 할줄 모른다고 한다는 난처함이)

라고 했는데. 못 알아먹겠답니다.
못알아먹는건지. 자기가 귀찮으니까 안하고.. 나보고 와서 하라고 그러는건지.
정말 여러 방안을 알려줬는데. 뭐 답을 주든지. 아님 시도라도
해본 '척' 이라도 해줘도 갈까말까겠구만(차비 1100원 나옴)
참.. 너무 하더라고요. 밥은 사준다고 해도.. 좀 자기가 처리라도
하는 척이라도 해주지. 모른다고 닥달이니. 쩝..

익스플로러도 안된다고 하니. 무슨 해킹프로그램에 노출되었나봅니다.
저번에 봤을땐 수십종의 백도어가 놀고있던데.

하여튼. 사람이 도와달라고 이야기하면 성의라도 보여줘야하는데.
쩝.. 막무가내여서 관두긴했습니다만..

그.. 인터넷 연결 차단하고 윈도우 까는게 어려웠나봅니다.
용산들고 간데요.
(그리고 여의도도 간데요. ahn lab에!!! 이건 말려야 되죠?)
헉... 1년반 전에 나온 바이러스랑 해킹프로그램때문에
쩝...

creativeidler의 이미지

to cocas:
top 5 must read book은 링크를 걸지 않은 게 제 실수인 듯 합니다.
http://java.about.com/od/advancedjava/tp/mustreadsoftdev.htm

Quote:
Whatever the language or domain in which you practice your craft, these tomes hold an essential body of hard-earned, collective wisdom and knowledge.

Quote:
전 알고리즘을 배울 때 알고리즘의 문제 해결 절차라고 배웠고 알고리즘을 잘 안다는 것은 알고리즘 리스트를 줄줄 꿰고 외우고 있는 게 아니라 문제가 주어졌을 때 이를 잘 해결한다는 것이라고 알고 있습니다. 제가 SI 쪽에 대한 경험이 전무한 상태여서 자세한 상황은 모릅니다만 문제 해결이라는 기본 전제는 다 같으리라 생각합니다. 문제 해결을 위한 절차 서술이 알고리즘의 서술 아닐까요?

여기서 논란의 중심이 되는 것은 그런 문제해결 절차로서의 알고리즘이 아니죠. 그건 '미리 알고 있어야할 기초 지식'이 아니지 않습니까. 알게 모르게 익혀나가는 걸 가지고 '기초 지식'이라고 할 수는 없죠. 지금 말하는 것은 협의의 알고리즘, 버블 소트니 퀵소트니 백트래킹이니 하는 것들을 말하는 것입니다. 이런 것들이 기초냐 하는 거죠. cocas님까지 왜 이러십니까-_-

to bluerain:
블루레인님은 지금 스스로가 얼마나 입증하기 힘든 주장을 하고 있으신지 잘 모르시는 것 같습니다. 그냥 '알면 좀더 좋은 것'을 두고 기초라고 하진 않습니다. 기초라는 말 자체의 어원도 건축물의 무게를 떠받치고 안정시키기 위하여 설치하는 밑받침이라는 말에서 나온 겁니다. 즉, 기초가 없으면 건물은 아예 짓지도 못하고 기초가 부실하면 약간의 충격에도 무너지는 그런 부실 공사가 되고 맙니다. 기초란 그런 걸 두고 기초라고 하는 겁니다. 알고리즘이 그런 거라고 생각하십니까? 알고리즘 모르면 아예 프로그래밍 할 수도 없거나, 혹은 만들어놓은 프로그램이 언제 문제를 일으킬지 모르는 그런 거라고 생각하십니까?

이 주장을 입증하기 위해서는 한두 가지 '알고리즘이 유용하게 쓰이는 사례'로는 부족합니다. 알고리즘을 모르는 사람이 만든 프로그램은 열이면 열, 백이면 백 실패할 수 밖에 없다는 정도의 증거를 들이대야 입증이 가능합니다. 험난한 길이죠.

다른 예를 들어보죠. 윈도우 프로그래밍하려면 윈도우 API를 주로 사용합니다. 그럼 윈도우 API가 내부적으로 어떻게 동작하는지 알아야합니까? XML 쓰려면 XML 파서를 쓰게 되는데 그럼 XML 파서의 원리를 이해해야 XML 잘 쓸 수 있나요? 아파치 쓰려면 HTTP 스펙을 다 이해하고 있어야하나요? 그래도 이 예들은 최소한 쓰는 것들에 대한 예입니다. SI에서는 교과서에 나오는 알고리즘들을 직접 사용하는 경우는 거의 없습니다. 직접 사용하지 않으니까 당연히 몰라도 무너지지 않는 튼튼한 프로그램을 만들 수 있습니다. 그래도 알고리즘이 기초입니까?

creativeidler의 이미지

to stmaestro:
제가 볼 때 stmaestro님의 잘못은 사람을 비웃기에 불충분한 정보를 늘어놓고 비웃었다는 것입니다. ipconfig 같은 건 프로그래머가 몰라도 프로그래밍하는데 별 지장 없습니다. 웹 프로그래밍은 네트워크를 직접 건드리지 않습니다. 윈도우 업데이트는 윈도우 사용 능력이지 프로그래밍 능력이 아니죠. 게다가 제목과는 전혀 어울리지 않습니다. 웹 프로그래밍을 한다고해서 보안을 알아야하는 것도 아니고 설령 필요하다 한들 윈도우 업데이트 수준의 개인 보안 지식이 필요한 건 아닙니다.

그래서 거듭해서 그 사람이 비웃을 만하다는 증거를 올리고 있으신데 여전히 프로그래머로서 비웃을 만하다기보다는 컴퓨터 사용 능력이 좀 없는 것 뿐인 것 같군요. 물론 그 정도 컴터 사용 능력이 떨어지면 프로그래밍 능력도 떨어질 꺼라는 추론을 하고 있는 줄은 알지만 그 추론은 때때로 틀립니다. 요즘은 컴퓨터보다 프로그래밍부터 배우는 사람이 많으니까요. 사실 따지고보면 프로그래머가 일반 사무직이나 디자이너보다 '컴퓨터를 더 잘 알아야할 이유'는 그렇게 많지 않습니다. 위에 어떤 분이 자동차 예를 드셨는데 자동차 타고 가다가 고장나면 스스로 고쳐야 자동차 탑니까? 서비스 부르면 요즘 금방 옵니다. 프로그래머를 비웃을 만한 증거는 지저분한 코드를 만들어내는 것, 그것 뿐입니다.

stmaestro의 이미지

어?
알고리즘 이야기
아직 안끝났어요?
계속 달려나오네요.

저.... 제가 맨처음 쓴글이긴 하지만.
이거 쓰레드 닫으면 안되요?

blueruin의 이미지

stmaestro wrote:
어?
알고리즘 이야기
아직 안끝났어요?
계속 달려나오네요.

저.... 제가 맨처음 쓴글이긴 하지만.
이거 쓰레드 닫으면 안되요?


저도 닫는데 한표 추가합니다.

time to wait...

죠커의 이미지

결론 부터 말해서 나는 알고리즘이 프로그래밍의 기초 파트라는 것에 반대합니다.

프로 레이서라면 차의 하중 이동을 알아야 한다고 합니다. 언더든 오버든 모든 고속 조작이 하중이동이 만드는 예술이기 때문이라고 합니다. 하지만 일반인들은 차의 하중 이동을 알 필요가 없습니다. 객체 설명할때 자주 인용되듯이 차는 브레이크와 엑셀레이터, 핸들 등의 몇가지 인터페이스를 가지고 있는 제품이기 때문입니다.

차의 하드웨어 구동이나 실제 로드와의 영향에 의한 하중 이동등의 결과는 일반적으로는 유저에게 상관없는 "레이어"에 위치해 있습니다.

펄이나 파이썬 프로그래머로 로컬 컴퓨터에서 작업하는 프로그래머에겐 알고리즘이 "기초"가 되지는 못할 거라고 확신합니다.

하지만 세상의 대부분의 환경은 "레이어"가 잘되어 있지 않다고 생각합니다. 그래서 알고리즘과 자료구조를 알아야 하는 파트가 생긴다고 생각합니다. 그런 시점에 갈때쯤이면 이미 프로그래머는 "프로그래밍 언어"를 비교적 능숙하게 써야 한다고 생각합니다. 그때 쯤 되면 그에게 있어서 "기초 학문"이라는 권위는 없을 것입니다.

Dijkstra는 사람을 뽑을때 수학 보다는 "영어"를 뽑았습니다. 진정한 프로그래밍이라면 언어를 잘해야 된다는 생각에 그렇게 했습니다. 10년 안에 컴퓨터 커리큘럼에 "우리말"과 "영어"의 비중이 더 커져야 할 것입니다.

creativeidler의 이미지

푸, 닫는 거야 상관 없지만 자신이 1시간 전에 글 써놓고 아직 안 끝났냐고 묻는 건 무슨 심리인지. 끝까지 자신는 아무 잘못한 거 없다고 생각한다면 그냥 닫으세요. 그게 낫겠군요.

NeoTuring의 이미지

creativeidler wrote:

여기서 논란의 중심이 되는 것은 그런 문제해결 절차로서의 알고리즘이 아니죠. 그건 '미리 알고 있어야할 기초 지식'이 아니지 않습니까. 알게 모르게 익혀나가는 걸 가지고 '기초 지식'이라고 할 수는 없죠. 지금 말하는 것은 협의의 알고리즘, 버블 소트니 퀵소트니 백트래킹이니 하는 것들을 말하는 것입니다. 이런 것들이 기초냐 하는 거죠. cocas님까지 왜 이러십니까-_-

여기서 문제해결 절차로서의 알고리즘은 광의의 알고리즘이고, 광의의알고리즘 영역에서 일종의 수학적 검증절차를 통과한것이 협의의 알고리즘입니다. 때문에 일반적인 프로그래밍 환경에서 좋은 문제해결 절차를 시행착오의 형식으로 찾으려 하다보면 결국엔 (시간이 한참 지나서야) 그런것이 이미 협의의 알고리즘으로 마련되어 있다는것을 발견하게 될겁니다. 그래서 제가 그 과정을 "시간낭비"라고 본겁니다. 시행착오는 한두번 정도 해볼 가치가 있지만, 그 이상의 출혈(?)을 해가면서 협의의 알고리즘에 근사한 어떤것을 스스로 "발견"하기를 기대하는것은 전혀 생산적이지 못합니다.

어떤 문제의 증명에 피타고라스 정리가 사용되는데 "피타고라스 정리를 참고하지 않고 풀어보겠다"라고 선언하고, 그 문제를 붙들고 삽질하는 태도는 처음 학습할때의 과정에서는 충분히 그럴 가치가 있지만 문제를 만날때마다 그런 과정을 반복하는것은 피타고라스 정리를 참고해서 문제를 풀어나갈때의 이점을 철저히 무시하는 입장에 불과합니다. 이곳에서 XP를 주 방법론으로 채택하는 프로그래머의 얘기를 해서 좀 뭐하지만, 그쪽에 있는 사람들은 이런 부분을 거의 깡그리 무시하는 태도로 일관하고 있습니다. 심지어는 같은 문제라도 반복해서 여러가지 방법으로 풀어낼 수 있다는것을 대단한 자랑인것인양 말을 하기도 하는데 그것은 결코 자랑이 아닙니다. 물론 저도 학습의 과정에서 그렇게 하는것은 의미있다고 생각하지만, 그 이상은 되지 못합니다. 그쪽을 지지하는 사람들은 소프트웨어에 설계가 없고, 코드만 있으며 코드가 곧 설계 그 자체라고 여기는데 제가 볼때 이것은 인간의 추상능력을 전혀 염두에 두지 않고 있는 발언입니다. 그래서 그들은 패턴도 반대합니다.(물론 무조건 쓰지 말라는식의 반대는 아닙니다) 알고리즘의 경우는 어떤지 모르겠지만, 패턴을 반대하는 논리라면 알고리즘도 반대하지 못할 이유가 없어 보입니다.(코드 시퀀스의 패턴==알고리즘이니까) 특히 알고리즘이 기초가 아니다라는 creativeidler님의 글을 봤을때 역시 제 예상이 맞아들어가고 있다는 확신까지 드는군요.

일단 일반화된 공식(그것이 피타고라스 정리이든 디자인 패턴이든 협의의 알고리즘이든)을 정식으로 익혔다면(배우는 과정포함), 그러한 추상성을 가지고 더 높은 추상성(피타고라스정리를 이용한 더 추상화된 문제 풀기, 디자인 패턴을 이용한 더 커다란 패턴찾기, 협의의 알고리즘을 이용한 분야종속적인 더 큰 알고리즘 찾기)을 향해 나아가는것이 인간의 특성이고, 이렇게 했을때 비로소 문제 해결에 대한 효율성을 얻을수가 있는것인데 이 부분을 그저 "학습의 과정"으로 전락시키고, 시행착오를 통해 그런 부분을 스스로 찾아나가게 하는것이 그들의 문제라고 봅니다. 자신이 바닥부터 삽질하지 않아도 이미 마련되어 있는 더 좋은 해법이 존재하고, 그것을 제대로 익혔을때 더 효율적으로 문제를 해결해 나갈 수 있음에도 불구하고 지나치게 구성적인 학습법을 강조한 나머지 인간의 추상능력(공인된 알고리즘, 공인된 패턴, 공인된 정리)을 사용하는것이 무슨 죄가 되는것마냥 생각하는듯 보여진다는거죠. 그래서 그쪽에서 맨날 강조하는것이 프로그래밍을 무슨 권법수련에 비유하는것 아니었습니까?

인간은 항상 자신의 추상능력을 알게 모르게 사용하는데 가령 사람의 몸을 이해하고자 할때도 머리, 몸통, 팔다리로 구분하고 이것을 점차 더 작은 단위로 쪼개어 파악합니다. 그런데 XP를 지지하는 사람들은 무조건 세포수준에서 인간의 몸을 봐야 하며 인간의 몸에서 어떤 부분이 잘못되었다고 하면 세포수준에서 그 잘못된 부분을 고쳐야 한다고 주장하는걸로 보입니다. 인간 몸의 구조(추상화된 설계)는 없으며 오로지 세포집합(코드뭉치)만이 실재를 대표하는것이라고 착각하는것이죠. 뭐 그것도 인간의 추상능력을 깡그리 무시하는 그들의 입장을 이해한다면, 수긍할 수 있는 부분이긴 합니다만 저로선 도무지 인간의 몸을 개선하는데 이미 "공인된 구조"를 사용하지 않고 세포수준에서 일일이 다 고쳐나가는 그러한 막대한 "시행착오 비용"을 어디서 어떤방법으로 회수 할 수 있을지 난감하기만 합니다. 이것은 수학에서 기본적인 정리와 따름정리를 익히지 않고 꽤나 추상화된 문제를 그저 주어진 정의와 공리만으로 풀어나가려는 시도와 다를것이 없습니다. 그리고 그들은 이러한 정리와 따름정리들은 문제를 풀어가는중에 자연스럽게 "발견"되는것이며, 이것이야 말로 더 위대한것이다! 라고 주장하는 모양으로 밖에 보이지 않습니다. 개인적으로 이 부분은 인간의 추상능력을 전혀 염두에 두지 않고 있는 그들의 "오류"라고 생각하고 있습니다.

물론 주어진 문제자체가 지속적으로 변경된다면, 추상능력을 발휘하기 보다는 시행착오를 거치는 편이 더 나을 수 있고, 또 실제 효과도 크다고 생각합니다만 그것을 인정한다 하더라도 아무래도 XP쪽의 주장은 지나치게 앞으로 나가서 자신들의 주장을 일반화시킨 면이 없지 않습니다. creativeidler 님도 그들의 입장과 마인드를 그대로 답습하고 계신것 같은데 (creativeidler님이 쓰신 여러 글에서 그런 냄새가 아주 강하게 풍겨왔습니다.) 이쯤되면 더 이상 대화가 통하지 않으리라 판단하고 접어야 하는것이 옳겠습니다만, creativeidler님이 논란의 "핵심"을 아직 간파하지 못하고 계신듯해서 제가 이렇게 지적하면서 글을 끝냅니다. 사실 이 글은 이 쓰레드와 별 관련이없는 부분인것 같으면서도 은근히 감춰진 서로간 "핵심적인 인식의 차이"를 드러내줄 수 있는 글이라 얘기하지 않으려고 했던것 그냥 말해버린것이니 삼천포로 빠졌다느니 하며 불평하시지는 않으셨으면 합니다. 현재까지도 creativeidler님은 "기초"라는것에 대한 엄밀한 정의를 못내리고 계시고, 그에 따라 "기초"를 여러가지로 해석할 수 있는 길을 스스로 터놓고 계십니다. 이런 일의적인 정의없이 더 이상의 논쟁은 무의미하죠. 제가 기초라는것을 따로 정의해놓았는데 그것을 받아들이고 계신것 같지도 않아보이고... 그럼 여기서 저는 이만 물러가겠습니다.

마지막으로 저도 잠그는데 한표 던집니다.

njh1983의 이미지

creativeidler, nohmad, hackexpert 님들의 이야기와 전반적으로 같은 의견입니다.

버블소트, 퀵소트, b-tree, 그래프니 하는 "미리알려진 지식 수준의 알고리즘"은 확실히 반드시 공부해야할 기초는 아니라는데 동의합니다. creativeidler님이 아래 정리를 깔끔하게 하셨네요.

Quote:
1. 버블 소트와 같은 협의의 알고리즘은 프로그래밍의 기초가 아니다.
2. 부당한 이유로 남을 비웃는 것은 옳지 못하다.
3. 그러므로 버블 소트를 모르는 것을 가지고 마치 기초가 부실한 양 비웃는 것은 옳지 않다.

제가 보기에도 "알고리즘을 알면 좋은 프로그램을 만들 가능성이 높다"라는 주장은 맞습니다. 예를 들어 최근 유닉스커널에서 fork() 함수가 copy-on-write방식으로 경량프로세스를 생성해낸다는 지식이 있다면 더 좋은 프로그램을 만들 가능성이 높은것이 사실입니다. 또 경량프로세스는 clone() 함수를 호출하여 만들어진다는 것도 알고 있다면 다양한 실수를 예방할 수 있을 겁니다.

하지만 creativeidler이 말씀한 "협의의 알고리즘은 프로그래밍의 기초가 아니다"라는 주장에, 다른분들의 제대로된 반박이나 근거는 제시되지 못했다는 생각입니다.

분명히 요사이 프로그래머의 자질에 관한 논란이 이어져 왔던 것은 사실입니다. 하지만 그것을 주장하는데 있어서 잘못된 예를 들면서 타인을 비웃는 것은 설득력이 없습니다. 최근의 프로그래머 자질론에 있어서는 creativeidler님의 말씀이 더 진보된 의견이고, 설득력이 있다고 생각합니다.

프로그래머 자질론에 대한 것은 계속 논의되면 좋다고 생각하는데, 자꾸 핀트가 맞지않는 의견들이 개진된다면 저도 잠금에 한 표 하겠습니다.

kkb110의 이미지

카레이서와 차의 비유가 적절할것 같네요

"카레이서는 자동차의 구조를 알아야 하는가?

글쎄 이건 생각하기 나름인것같습니다 -_-;

개인적인 의견으로는 필수는 아니여도 교양과목정도는 되는것같습니다.

그리고 웹프로그래밍한다는 사람이 ip볼줄도 모르고 보안패치도 할줄 모른다면 자질이 심각하게 의심되기는 합니다.
아주 조금이라도 자기가 일하는분야에 애정을가지고 탐구하는사람이면 저렇지는 않을겁니다.
아니면............. 아직 탐구중인가? 8)

chadr의 이미지

다시 봐도 아무래도 관점의 차이인것 같습니다.

low한 영역을 하시는분은 어떤 프로그래머가 "버블소트도 몰라?!" 라고 하면 상당히 놀라실것 같습니다.(저도 충분한 low는 아니지만 성능이 중요한 분야에서 일을 하고 있기에 놀랐습니다.)

하지만 high한 영역에서 일을 하시는 분은 "버블소트도 몰라?!" 라고 하면 "그딴거 찾아쓰면 되지!" 라고 하실 것 같습니다.

알고리즘또한 분야에 따라서 이해의 차이가 있는것 같습니다.

low한 분야에서의 알고리즘이란 최소한의 자원을 활용하며 최소한의 시간안에 어떤 일을 수행하는 정도로 이해할수 있겠구요..

high한 분야에서의 알고리즘이란 최소한의 코딩시간을 들이며 최대한의 유지보수가 가능한 코드를 작성하는 정도로 이해할수 있겠군요.

따라서 버블소트도 모르는 사람들 비웃는 말을 한것도 저의 개인적인 편견에서이지요.

low한 부분에서 보자면 버블소트를 모르는것은 충분히 비웃음 거리가 될듯 하군요.. 최소한 제가 가지고 있는 3권의 자료구조책에는 모두 버블소트가 언급 되어있었구요.(다시한번 말씀드리지만 여기서 모르는다는 의미는 구현을 할줄 모른다는게 아니라 구현을 해본적이 없다는 의미입니다)

따라서 저의 low한 입장에서 보자면 반드시 부당한 이유로 비웃은것은 아니라고 생각을 합니다.

반대로 high한 영역에서 보자면 위의 주장은 정말 말도 안되게 보이겠지만말입니다.:)

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

kane의 이미지

왠지 글들이 빙글빙글 돌고 있다는 느낌을 지울 수가 없네요.

'기초가 중요하다'라는 부분엔 동의를 하시고,
'알고리즘이 기초인가, 아닌가'하는 부분에 논란에 여지가 있다는 곳까지 왔습니다만,
제가 보기에는 '알고리즘은 기초다'(또는 알고리즘은 중요하다)라는 부분에서도 암묵적인 동의 내지는 공감대가 이미 있지 않을까 싶습니다.

물론, '버블 소트는 기초인가?', 'A*는 기초인가?'와 같이 특정 알고리즘이 기초가 되는가에 대한 대답은 '그렇지 않다' 내지는 '그렇지 않을 수 있다'일 겁니다. 특정 알고리즘의 사용 여부는 전적으로 직면한 문제에 따라 다르기 때문입니다.
하지만, '알고리즘을 공부한다'라는 것을 특정 알고리즘의 과정을 외운다는 것을 떠나서, 여러 알고리즘(혹은 해결 방법)을 비교, 분석하고 적절한 알고리즘(혹은 해결 방법)을 선택할 수 있는 공부를 한다는 것과 같은 뜻으로 해석한다면 알고리즘이 프로그래밍에 도움을 주고 좋은 프로그램을 만들 수 있도록 해준다는 점에 반대하시는 분은 없으실 것 같습니다.

creativeidler님께서 '버블 소트도 모른다'라는 말을 문자 그대로 해석하셔서 '버블 소트 몰라도 상관없다' (나아가 알고리즘 몰라도 상관없다)라고 말씀하신데서부터 어긋나지 않았나하는 생각이 드는데요.
(알고는 계시겠지만) '버블 소트도 모른다'는 말은 '기초가 형편없다', '기초가 부족하다'라는 표현의 한 종류였던 것 뿐입니다.
정말로 '버블 소트'를 아느냐 모르느냐의 문제가 아니라, 전공자라는 사람들 중에 또는 개발자라는 사람들 중에 기초적인 것도 모르는 사람들이 있더라(혹은 자주 보게되더라)고 얘기한 것 입니다.
(그렇다고 보안이나 버블 소트가 꼭 알아야할 필수 요건이라는 이야기는 아닙니다.)

그리고 쓰레드가 점점 진행되면서 '버블 소트'(협의의 알고리즘)와 '알고리즘'(광의의 알고리즘)이 알게 모르게 섞여 쓰이면서 서로 간의 불필요한 오해를 계속 낳고 있는 것 같습니다.

결국 같은 얘기를 서로 돌아가며 다르게 하고 있었다고 생각합니다.

저는 기초가 중요하다고 생각하고,
그 연장선상에서 알고리즘이 중요하다고 생각합니다.
(특정 알고리즘을 반드시 알아야 한다거나,
특정 알고리즘을 레퍼런스없이 구현할 수 있어야 한다는 뜻은 아닙니다.)

cleansugar의 이미지

Quote:
creativeidler님의 주장은 앞서 예를들었듯이 화성법을 모르고서 작곡을 할 수 있다라는 주장과 차이가 없는걸로 생각합니다. 콩나물대가리 몇개 붙여놓고 그것도 음악이라고 부른다면 인정해줄 수 있는 주장이긴 하지만, 그런식으로는 결코 음악을 "잘"만들수는 없습니다.

네오튜링님은 튜링을 좋아하시거나 약간 개선해보자고 생각하시는 분 같군요.

유한상태기계를 어떻게 생각하시나 여쭤보고 싶군요.

화성법이 서양 중세 때 정립되기 이전부터 사람은 입으로 노래를 흥얼거렸습니다.

요리법이 나오기 전부터 사람은 음식을 해먹었고,

문자를 만들기 전부터 사람은 말을 했습니다.

각 민족들의 전통 민요가 못 만든 노래라고 생각하십니까?

일단 이런 전제를 깔고 화성악을 열심히 배우면 좋습니다.

컴퓨터도 '프래그매틱'하게 탄도 빨리 계산하려고 만든거지, 알고리듬 연구하려고 만든 건 아닙니다.

이쪽 분야는 대충

수학, 물리화학, 전기전자, 컴퓨터과학(알고리즘), 컴퓨터공학 등등이 연관되어 있습니다.

이련 류의 영역 싸움은 위의 분야에서도 서로 맨날 하는겁니다.

모든 것은 통하기 때문에 고수들은 그런 싸움 안한다고들 하죠.

알고리즘이 좋다 안좋다는 별로 싸울꺼리는 못 됩니다.

웹디자이너도 알고리즘이 필요할 때가 있고, 수학자도 UI를 그려볼 경우도 있죠.

플래시 만드는 것도 넓은 의미의 프로그래밍이 될 수 있고, 어차피 프로그래밍 언어의 개선 방향도 이런 쪽 아닙니까?

음악도 컴퓨터의 도움을 받아야 한다는 단점이 있지만, 흥얼거리기만해도 작곡이 되고, 버튼 하나만 눌러도 코드가 눌러지는 악기가 개발되었고 개선되고 있습니다.

좀 빗나간 얘기지만,

반대로 UI마져도 열심히 하다보면 수학화하려는 연구를 얼마든지 할 수 있습니다.

제가 대충 생각해보니,

예를 들어 정해진 2차원 정수 공간(쉽게 말해 픽셀)에서 얼마나 다양한 정보를 어느정도 효과적으로 전달할 수 있는가등을 연역적으로 연구해본다거나

커맨드라인(CUI)은 청각적인 1차원, UI는 시각적인 2차원, 요즘 유행하는 입체 GUI나 입체 게임은 2.x 차원, 마우스등 만져지는 감각적인 것는 3차원, 뇌파는 3.x차원, ..., n차원 등으로 구분할 수 있다고 생각해본다거나...

뭐 이런 것을 생각해볼 수 있습니다.

나중에 후손이 이런 새로운 UI 알고리즘을 더 중시하도록 교육받는다면 교육이 비효과적일겁니다.

프랑스는 노벨상 수상자의 권고대로 과학 교육을 손으로 만져보는 것으로 시작해 효과를 보기도 했는데, 역시 모든 배움은 온몸으로 느끼는 것부터 시작하는 것이 좋습니다.

노래도 화성악보다는 어려서부터 부담없이 부르며 배우고,

프로그래밍도 조이스틱으로 하는 컴퓨터 게임부터 시작하고

요리도 요리책 없이 먹는거부터 시작합시다.

저는 배고파서 뭣좀 먹으러 일어나렵니다.

아까 귤을 다 먹어서 아쉽군요.

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

pynoos의 이미지

다섯분이 잠금의사를 표시하였으므로 잠그겠습니다.

앞으로는 잠글 때마다 누적값을 좀 써주셨으면 관리하는데 더 편리(?)하겠습니다. :)

페이지