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

stmaestro의 이미지

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

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

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

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

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

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

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

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

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

아흑..
왜..

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

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

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

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

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

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

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

버려진의 이미지

표준도 가르쳤으면...

"표준이 왜 필요하냐?"

라고 하는 사람이..

"영화 받는게 불법이에요?"

라고 하는 사람들 못지 않게 많더군요. 황당 황당...

khris의 이미지

제 생각에 그 친구분...
그분께서 만드신 웹페이지는 파이어폭스에서 십중팔구는 깨져나올거라고 생각합니다.
웹프로그래밍쪽이라면 더욱 더 보안등에 치중해야하는데...
사실 우리나라 사람들은 보안이나 바이러스에관해서는 무감각하죠.
거의 경각심이 없다고 봐도 과언이 아닌지라...
사람들이 인지하기를 해킹등의 행위는 덩치 큰, 자신의 컴퓨터와는 다른 거대 컴퓨터만을 대상으로 하고, 또 윈도우와는 관계가 없다고 인지하죠.
물론 전혀 아니지만... ;)

───────────────────────
yaourt -S gothick elegant
khris'log

OoOoOo의 이미지

보안을 안 가르쳐준다고 하기보다는..

윈도우를 잘 못 쓰는 것 같네요.

윈도우 입문 책 하나 사주심이.. :D

chadr의 이미지

공장에서 찍어내는 대량 양산이 문제이지요..

컴공 나온사람이 정보처리기능사 수준의 문제도 못푸는 것을 보고 경악을 했습니다.

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

jedi의 이미지

chadr wrote:
공장에서 찍어내는 대량 양산이 문제이지요..

컴공 나온사람이 정보처리기능사 수준의 문제도 못푸는 것을 보고 경악을 했습니다.


아니 버블소트도 못한다는 말인가요??

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

chadr의 이미지

jedi wrote:
chadr wrote:
공장에서 찍어내는 대량 양산이 문제이지요..

컴공 나온사람이 정보처리기능사 수준의 문제도 못푸는 것을 보고 경악을 했습니다.


아니 버블소트도 못한다는 말인가요??

현실이지요-_-);

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

정태영의 이미지

jedi wrote:
chadr wrote:
공장에서 찍어내는 대량 양산이 문제이지요..

컴공 나온사람이 정보처리기능사 수준의 문제도 못푸는 것을 보고 경악을 했습니다.


아니 버블소트도 못한다는 말인가요??

정보처리 기능사 실기정도는.. 버블소트정도도 필요없습니다..
standard I/O 정도랑.. for 문정도만 쓸줄 알아도 다 풀 수 있습니다 =3=33

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

Mins의 이미지

저는 지방의 모대학인데 프로그램 못 짜더라도 졸업 할수 있는거 같습니다. -_-;

그리고 그러한 사람들 대부분이 이쪽에 뜻이 없는거 같고요.
다들 공무원 시험 준비한다는...

관련 분야의 경쟁자들 많이 줄었다는 생각을 해야 될까요....

얼마전에 저도 필요에 의해서 산업기사 시험을 봤는데...
시험 전날 관련 책 한번 보고 가서 붙었습니다. -_-;

생전 쓰지도 않는 비베로 시험을 봤는데...
(지금은 또 이걸로 프로그램을 짜고 있으니 사람 일이란 -_-;)
그전에 비베 책 잠깐 들여다 보고 갔으면 피볼뻔 했습니다.
무조건! 관련 수험 서적을 봐야 되겠더군요. -_-;

컴퓨터 하나도 모른 다는 전공자들이, 기사 자격증을 따야 되는데 어떻게 해야 되냐고 물어보는 일들도 흔한 일이죠. ㅡ.ㅡ

컴퓨터를 하니까, 관련 전공자라 기사를 따는게 아니라..
공무원 시험을 위한 불필요한 통과 의례 정도로 생각들 하는거 같습니다. 그리고 그러한 사람들도 손쉽게 합격할 정도로 수준이 낮고요. -_-;; (뭐 개인적으론 시험 준비하면서 얻는것들도 많긴 하지만, 그런거 없어도 손쉽게 딸수 있으니...)

warpdory의 이미지

jedi wrote:
chadr wrote:
공장에서 찍어내는 대량 양산이 문제이지요..

컴공 나온사람이 정보처리기능사 수준의 문제도 못푸는 것을 보고 경악을 했습니다.


아니 버블소트도 못한다는 말인가요??

멀고 먼 중학교때 기능사를 땄는데, 소트 문제는 그냥 넘어가도 합격에 하등 지장이 없었던 것으로 기억합니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

creativeidler의 이미지

컴퓨터 활용 능력과 프로그래밍 능력은 다른 것이지요. 게다가 말씀하신 것들은 웹 프로그래밍의 보안과는 아무 상관 없는 것 아닌가요. 사실 컴퓨터를 안 배우고 프로그래밍부터 배운 사람은 그런 경우가 많죠. 제 여자친구도 자기 컴터 고장난 것도 못 고치지만 상당히 괜찮은 품질의 코드를 만든답니다. 프로그래머는 컴퓨터 활용 능력이 아니라 코드로 말하는 겁니다. 전 리눅스에도 빠삭하고 네트워크 전문 지식도 많은데 쓰레기 같은 코드를 만들어내는 사람이 더 싫더군요.

khris의 이미지

creativeidler wrote:
컴퓨터 활용 능력과 프로그래밍 능력은 다른 것이지요. 게다가 말씀하신 것들은 웹 프로그래밍의 보안과는 아무 상관 없는 것 아닌가요. 사실 컴퓨터를 안 배우고 프로그래밍부터 배운 사람은 그런 경우가 많죠. 제 여자친구도 자기 컴터 고장난 것도 못 고치지만 상당히 괜찮은 품질의 코드를 만든답니다. 프로그래머는 컴퓨터 활용 능력이 아니라 코드로 말하는 겁니다. 전 리눅스에도 빠삭하고 네트워크 전문 지식도 많은데 쓰레기 같은 코드를 만들어내는 사람이 더 싫더군요.

음... 저는 컴퓨터에 대한 이해를 바탕으로 더 좋은 코드가 나올수있다고 생각합니다.
일반적인 생각도 그렇고요.

웹프로그래밍의 경우에도 일반 어플리케이션보다 훨씬 더 많은 예외상황들이 발생 할 수 있고, 대개가 실시간으로 어디서 어떻게 될지 모르는 상황이라 보안에 대한 경각심이 무엇보다도 우선시되어야합니다.

어쩌다보니 웹 프로그래머의 보안불감증에 대한 이야기가 프로그래머 전체로 확대된거같네요.
저 역시 앞에서 떠들어대놓고 코드 한 줄 없는 사람은 싫어합니다.
주변에 그런놈이 하나 있기에... :twisted:

───────────────────────
yaourt -S gothick elegant
khris'log

viper9의 이미지

전 그런 경우 많이 봤는데;;; 흠흠... 전 미술전공이라 그런지 주위에 디자인 계열로 뛰어든 사람이 많습니다.

그러한 디자이너들은 컴퓨터가 고장나면 고치질 못합니다. 가끔은 단순히 윈도우를 재설치 못하는 경우도 있었습니다. ㅡㅡ;; (그리고 그런 사람들에게 리눅스를 가르쳐주는건 너무나 힘든 일이더라구요.)

그들에겐 필요로 하는 해당소프트웨어(예를 들면, 포토샵이나 일러...)만 빨리, 안정적으로, 잘 돌아가는 컴퓨터만 있으면 되는 것이거든요. 어차피 그거밖에 쓸일이 없으니...

컴퓨터를 쓰는 디자이너라고 모두가 컴퓨터에 만능은 아닙니다. 다만, 자기가 해당하는 분야에만 전문적인것이지요.

어찌보면 그게 당연하다고도 생각됩니다. 디자이너가 시간을 투자해 컴퓨터 전반에 대해 배우는 것보다 자기가 하는 분야에 더 시간을 투자하는게 훨씬 효율적이고 생산적이지 않을까요?

회사 차원에서도 보안을 담당하는 사람 한명만 배치해서 전부다 관리하게 해주면 될것을 모두가 보안에 대해 배우라고 하면 훨씬 손해가 아닐까용...

마지막으로 이말이 생각나네요. '컴퓨터는 그 자체가 목적이 아니라 어떤 목적을 이루기 위한 도구일뿐이다'라고... (물론 그렇지 않은 분도 상당히 많겠지만. 저 포함. ^^)

fox9의 이미지

jedi wrote:
chadr wrote:
공장에서 찍어내는 대량 양산이 문제이지요..

컴공 나온사람이 정보처리기능사 수준의 문제도 못푸는 것을 보고 경악을 했습니다.


아니 버블소트도 못한다는 말인가요??

소트가 뭔지도 잘 모르는 사람들도 많습니다 :(

khris의 이미지

fox9 wrote:
jedi wrote:
chadr wrote:
공장에서 찍어내는 대량 양산이 문제이지요..

컴공 나온사람이 정보처리기능사 수준의 문제도 못푸는 것을 보고 경악을 했습니다.


아니 버블소트도 못한다는 말인가요??

소트가 뭔지도 잘 모르는 사람들도 많습니다 :(

제 친구는 이렇게 말합니다.

"소트? Sort? 종류."

근데 저는 이 문장을 이렇게 번역했었습니다.

"That argument...(후략)"
-> 그 인자가...

사람마다 틀린거죠 ;)

───────────────────────
yaourt -S gothick elegant
khris'log

creativeidler의 이미지

Quote:
음... 저는 컴퓨터에 대한 이해를 바탕으로 더 좋은 코드가 나올수있다고 생각합니다.
일반적인 생각도 그렇고요.

그런 분야도 있습니다. 하지만 오히려 그런 분야에 종사하는 프로그래머가 훨씬 적습니다. 특히 웹 프로그래밍은 더 그렇죠. 팀에서 한두 명만 그런 컴퓨터에 대한 이해가 필요한 부분을 코딩하면 되고 웹 프로그래머의 절대 다수는 비즈니스 로직을 얼마나 잘 코딩하느냐가 더 중요합니다.

이것은 포토샵을 돌릴 수 있을 정도의 컴퓨터에 대한 이해에 자신의 IDE에 대한 이해만 있으면 얼마든지 좋은 코드를 만들어낼 수 있습니다. ipconfig는 커녕 cmd조차 몰라도 일반적인 비즈니스 로직 프로그래밍에는 하등의 지장이 없습니다. 그걸 위해 프레임웍이라는 게 존재하는 것이지요.

creativeidler의 이미지

덧붙여, 소트를 할 줄 안다는 게 뭐 그리 대단한 건지 모르겠습니다. 프로그래밍하면서 소트 알고리즘을 알아야하는 경우는 극히 드뭅니다. 알고리즘 따위 전혀 몰라도 프로그래밍하는데 별 지장 없습니다. 그런 지식 따위는 필요할 때 익히면 되는 겁니다.

blueruin의 이미지

creativeidler wrote:
덧붙여, 소트를 할 줄 안다는 게 뭐 그리 대단한 건지 모르겠습니다. 프로그래밍하면서 소트 알고리즘을 알아야하는 경우는 극히 드뭅니다. 알고리즘 따위 전혀 몰라도 프로그래밍하는데 별 지장 없습니다. 그런 지식 따위는 필요할 때 익히면 되는 겁니다.

글쎄요. 소트같은 개개의 알고리즘이 그렇게 중요하지 않을지는 모르겠지만 프로그램이라는것은 코드의 나열이 아니라 알고리즘의 배열이라는 측면에서 본다면 소트도 중요하지 않을까요?
"그런 지식 따위" 가 모여서 효율적인 한개의 프로그램을 만들게 되는것입니다.
물론 필요할 때 익히면 되겠지만 저희 팀 사람을 뽑는다면 미리 익힌분을 뽑겠습니다. :wink:

time to wait...

chadr의 이미지

creativeidler wrote:
덧붙여, 소트를 할 줄 안다는 게 뭐 그리 대단한 건지 모르겠습니다. 프로그래밍하면서 소트 알고리즘을 알아야하는 경우는 극히 드뭅니다. 알고리즘 따위 전혀 몰라도 프로그래밍하는데 별 지장 없습니다. 그런 지식 따위는 필요할 때 익히면 되는 겁니다.

그따위 지식 하나 모른다는 사실이 신기했을 따름입니다.

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

warpdory의 이미지

creativeidler wrote:
덧붙여, 소트를 할 줄 안다는 게 뭐 그리 대단한 건지 모르겠습니다. 프로그래밍하면서 소트 알고리즘을 알아야하는 경우는 극히 드뭅니다. 알고리즘 따위 전혀 몰라도 프로그래밍하는데 별 지장 없습니다. 그런 지식 따위는 필요할 때 익히면 되는 겁니다.

기초가 허약하면 부실공사 밖에는 안나오는 겁니다. 그래서 SI 가 그 따위 결과 밖에는 안나오는 거지요.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

creativeidler의 이미지

Quote:
물론 필요할 때 익히면 되겠지만 저희 팀 사람을 뽑는다면 미리 익힌분을 뽑겠습니다.

그리고 마이크로소프트는 컴퓨터 프로그래밍을 한 번도 안해본 사람을 뽑기도 하죠. 어느 회사가 더 잘나가나요? :D
저라면 소트 알고리즘은 몰라도 그 정도는 10분 만에 이해할 수 있는 능력이 있는 사람을 뽑을 것 같군요.

Quote:
글쎄요. 소트같은 개개의 알고리즘이 그렇게 중요하지 않을지는 모르겠지만 프로그램이라는것은 코드의 나열이 아니라 알고리즘의 배열이라는 측면에서 본다면 소트도 중요하지 않을까요?

프로그램을 알고리즘의 배열이 아닌 '문장의 서술'로 이해하는 사람이 좋은 코드를 만듭니다. 현업 프로그래머 중에 소트 알고리즘을 알 필요가 있는 사람이 얼마나 될까요? 컴파일러 개발자, DBMS 개발자 정도?

creativeidler의 이미지

Quote:
기초가 허약하면 부실공사 밖에는 안나오는 겁니다. 그래서 SI 가 그 따위 결과 밖에는 안나오는 거지요.

알고리즘이 프로그래밍의 기초라고 생각하시나요? 10년 전 얘기를 듣는 기분이군요. 게다가 SI가 실패하는 이유를 그런 데서 찾다니 참 신선한 발상이군요.

Quote:
그따위 지식 하나 모른다는 사실이 신기했을 따름입니다.

그 따위 '몰라도 되는 지식'을 모르는 것이 신기한가요?
warpdory의 이미지

creativeidler wrote:
Quote:
기초가 허약하면 부실공사 밖에는 안나오는 겁니다. 그래서 SI 가 그 따위 결과 밖에는 안나오는 거지요.

알고리즘이 프로그래밍의 기초라고 생각하시나요? 10년 전 얘기를 듣는 기분이군요. 게다가 SI가 실패하는 이유를 그런 데서 찾다니 참 신선한 발상이군요.

기초중 하나입니다. SI 가 실패하는 이유중 하나가 그런 기초를 모르는 소위 페이퍼 자격증 멤버들이 마구 투입되기 때문이기도 합니다. 알고리듬이 소트 나 그런 걸 구현하는 것만 알고리듬은 아닙니다. 자료구조, flow, 등등 모든 것이 알고리듬으로 구현됩니다. 학원에서 그런 것 안 배우고 ctrl-c, ctrl-v 로 당장 눈에 보이는 것만 구현하는 것을 배워서 현업에 투입 되기 때문에 질이 떨어지고 결국 단가는 떨어지고 결국 SI 가 실패하는 이유 중 하나를 제공합니다. 대기업 이나 공기업 등의 횡포도 물론 큰 이유이지요.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

chadr의 이미지

제 생각으로는 프로그래머가 100% 컴퓨터 활용에대한 지식이 있을 필요는 없다고 생각합니다..

하지만 명색이 컴퓨터 프로그래머! 프로그램을 만드는 사람이면서 좀 최소한 윈도우 설치는 스스로 할 수 있었으면 좋겠군요..

프로그래머는 프로그래밍만 잘 해도 뭐라 할 말은 없지만..

기초는 알고 있는 성의는 보여야 하지 않을까요?

필요할때 배우면 되긴 하지만 조금 안일한 자세 아닌가요?
준비되이있지 않고 닥치면 하는 사람은 저같으면 안뽑겠습니다.

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

chadr의 이미지

creativeidler wrote:

Quote:
그따위 지식 하나 모른다는 사실이 신기했을 따름입니다.

그 따위 '몰라도 되는 지식'을 모르는 것이 신기한가요?

어째서 몰라도 되는 지식인지 모르겠군요..

소트라는것은 기본적으로 어떻게 변형이 되서라도 사용이 되게 마련입니다.

하물며 게임 개발시 draw call을 줄여 드라이버 호출을 최대한 줄이기 위해 batching을 하는데서 vertex buffer에 vertex를 밀어넣어줄때 같은 texture는 한번 세팅하고(texture를 그래픽 카드로 전송을 자주 하는것이 꽤나 부담이 되기에) 뿌리기 위한 정렬을 수행하는데..

그때도 소트가 사용됩니다. 이때는 소트를 알고 있다면 stl의 함수객체를 만들어 sort 알고리즘에 세팅하는 수고를 할 필요없이 단 몇줄에 소트가 끝나지요..

여튼 위에 분들의 말씀은 꼭 소트가 중요하다는것이 아니라..

소트와 같은 "기초" 가 중요하다는 말씀 같습니다..

기초는 중요하지 않습니까? 기초 없이 무엇을 할수 있다는것은 어불성설 같군요.

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

blueruin의 이미지

creativeidler wrote:
그리고 마이크로소프트는 컴퓨터 프로그래밍을 한 번도 안해본 사람을 뽑기도 하죠. 어느 회사가 더 잘나가나요? :D
저라면 소트 알고리즘은 몰라도 그 정도는 10분 만에 이해할 수 있는 능력이 있는 사람을 뽑을 것 같군요.

말장난같지만 일반적으로 기본에 충실한 사람이 새로운것을 배우는 능력도 좋습니다.

Quote:
프로그램을 알고리즘의 배열이 아닌 '문장의 서술'로 이해하는 사람이 좋은 코드를 만듭니다. 현업 프로그래머 중에 소트 알고리즘을 알 필요가 있는 사람이 얼마나 될까요? 컴파일러 개발자, DBMS 개발자 정도?

저와는 생각이 많이 틀리군요.
프로그래밍은 "사람이 필요한일을 컴퓨터가 가장 잘하도록 사람이 컴퓨터를 길들이는 과정" 이라고 표현 할 수 있습니다.
해야할일을 잘 판단하는 작업도 중요하지만 컴퓨터가 그 일을 최적으로 수행하도록 길들이는 과정역시 중요합니다. 이과정에서 필수적인것이 효율적인 알고리즘입니다.
소트는 알고리즘의 단편적인 예일뿐이고 실제 프로그래머작업의 상당부분은 알고리즘등을 사용한 프로그램 설계이고 나머지는 코더의 몫이지요. - 좀 진부한 이야기군요. :(

결론은 알고리즘(지혜/식)를 알고있다면 손발이 편해지고,
결국 효율적인 프로그램을 만들 확률이 높아진다는 것입니다.
더구나 머리싸매고 만들어야 하는 새로운 알고리즘이 아닌 이미 수많은 선배들에 의해 검증된 선물을 습득하지 않을 이유는 없을것 같습니다.

time to wait...

ed.netdiver의 이미지

사실 creative idle r 님 말씀대로 그런거 몰라도 코드 만들어낼수 있습니다.
하지만, MS가 그런 사람을 뽑는다는건 좀 예로서는 안맞는것 같습니다.

코드하나 제대로 0부터 자신이 만들줄 몰라도 회사생활 잘만 합니다.
모르면요? 아는사람한테 물어보면 된다.는 생각들로 사는 사람들
투성이죠. 자신이 그 아는 사람이 될 생각을 할필요가 없거든요.
하지만 어차피 그런 사람은 한계가 명확합니다.
있는거 수정하거나, 갖다 붙여서 (compile)되도록 만드는정도야
기본적인 정보(지식이 아닌)만 있어도 충분하죠.
자신만의 과제를 수행할수도 없고, 한마디로 부속품으로서
부속품인 코드만 만들다 끝낼수밖에 없습니다.
(팀장 입장에서는 이렇게 저렇게 업무분장해서 좀더 상위로의
shift를 유도하지만, 그런 생활에 맛들인 친구들은 좀처럼
자신이 무엇이 잘못되어있는지, 어떻게 해야 하는지에 대한
고민의 필요성을 못느낍니다. 왜? 지금도 해피하거든요)

openlook.org 함 가보세요.
퍼키님 사이트인데, 얼마전에 아주 좋은 사이트를 소개해주셨더군요.
Joel사이트 따라가다 보시면 ahnlab에서 한글 번역페이지도
만들어두고 했더군요.

덧. 그렇다고 제가 뭐 이런 얘기 할 자격이 있다고 생각해서가
아니라, 오히려 스스로에게 하는 말이기도 합니다.
이바닥, 흐름 빠르다고 하지만, 안주해버리기도 십상입니다.

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

cjh의 이미지

저도 버블소트 알고리즘 당장 쓰라고 하면 못쓰겠습니다. 모모 회사는 못들어가겠군요 :) 외국계 회사는 인터뷰 할때 그런것도 물어본다는데...

하지만 버블소트라는것이 있고, 여러가지 소트 알고리즘 중에서 비교적 쉽게(반면에 성능이 좀 떨어지는) 쓸 수 있는 것으로 압니다. 일단 그정도면 충분하지 않을까요? 아예 기억도 못한다면 좀 문제가 있겠지만, 어느때 사용해야 하고 필요하면 찾아서 구현 코드를 작성할 수 있다면 좋지 않을까 합니다. 물론 그 전에 어떻게 하면 qsort() 함수에 끼워넣어 버리고 잊겠습니다만 항상 적용되는건 아니니까요.

일전에 수업할 때 소트할 일 있으면 굳이 구현하지 말고 qsort() 함수 쓰라고 했습니다. (괜실히 소트 구현하는데 치여서 딴거 못할까봐) 이러면 기초를 익혀야 하는 학생들에게 안좋은 영향을 미치는 건 아니겠지요? 하지만 자료구조 수업은 아니었으까요 :)

--
익스펙토 페트로눔

bubicom의 이미지

Quote:
웹프로그래밍의 경우에도 일반 어플리케이션보다 훨씬 더 많은 예외상황들이 발생 할 수 있고, 대개가 실시간으로 어디서 어떻게 될지 모르는 상황이라 보안에 대한 경각심이 무엇보다도 우선시되어야합니다.

예외나 만들기 까다로운 것은 어플보다 더~ 합니다.

좀 확대된거 같은데요..

웹프로그래머가 다 그렇진 않습니다.

웬지 확대 해서 말씀하시는 거 같습니다.

그리고, 컴퓨터 일반 에 대해서, 어플프로그래머나, 웹프로그래머나, 디자인으로 인해 컴퓨터를 써야만 하는 일반사람들에게 컴퓨터 일반 에 대해서 기대 안한지 오래입니다. :D

일반인에게 많은 것을 바라는 건 포기해야죠..

다만.. 자기 컴의 수리나 os새로 까는 것 정도는 스스로 하라고 합니다. .. os, app 설치 배우기 싫거든..... 대기업 가라고 합니다. :lol:

-------------------------
모든것에 감사합니다.
http://bubicom.winmir.com

hackexpert의 이미지

일단 웹프로그래머가 "운영체제"에 대한 지식을 굳이 알 필요는 없다고 봅니다.
개발담당 PM이나 서버 관리자가 알고 조언을 해주면 되니까요..
운영체제를 알아야 프로그램을 효율적으로 짤 수 있는 환경이라면 그 환경을 탓해야 할 것 같습니다.
분명 프로그래머로서 좋은 환경은 아닌 것 같군요..

그리고 소트라.. 소트라는 것이 기초적인 알고리즘을 대표하는 의미로 쓰였겠죠?
소트만 가지고 따지자면 소트는 몰라도 상관 없는 것 같습니다.
기초적인 알고리즘이라면.. 글쎄요..
이것은 알고 모르고를 떠나서 이해를 했느냐 외웠느냐가 중요한 것 같습니다.

많은 분들이 대량 양산된 사람들의 문제를 기초적인 알고리즘을 모르는 것에서 찾으시는 것 같은데 모르는 것이 문제가 아니라, 새로운 것을 배우려는 의지가 부족하고, 이해하기보다 외우려는 자세가 문제인 것 같습니다.

그리고 웹프로그래밍에 국한된 이야기일지 모르겠지만..
저라면 기초 알고리즘을 많이 알고 있는 사람보다, 프로그램의 흐름을 논리적으로 설명할 수 있는 사람을 뽑을 것 같습니다.
기초알고리즘을 많이 알고 있는 것과 논리적인 사고와는 전혀 별개의 것입니다.

기초알고리즘을 하나도 몰라도 논리적인 사고를 가진 사람은 이것저것 쉽게 가르키고 쉽게 이해를 합니다. 그리고 그런 사람이 짜낸 코드는 다른 사람이 이해하기도 쉽구요..

오히려 어중간하게 알고리즘만 잔뜩 알고 있는 사람이 써낸 코드를 보면.. 효율적일지는 모르겠습니다만.. 다른 사람이 이해하기는 힘든 코드들을 만들어 내곤 하죠..

vacancy의 이미지

기초 알고리즘을 많이 익히면
동시에 논리적인 사고도 많이 늘지 않나요 ?
사고력이 완전히 타고나는 것도 아니고요.

그리고 기초 알고리즘을 모르는채
사고력만으로 인정을 받기 위해서는,
그냥 사고력만으로도 이미 알려진 '좋은 알고리즘'들의 퀄리티만큼
코드를 낼 수 있어야겠죠.

알려져있는 '좋은 알고리즘'들은 대개 ..
여기서 무시당해도 좋을만큼 낮은 퀄리티가 아니잖아요 ..
전부다 먼저 산[?] 사람들의 사고력의 결과물이고요 ..

자료구조나 알고리즘 같은건 이 바닥에선 기본 소양이 아닌지 ..

hackexpert의 이미지

vacancy wrote:
기초 알고리즘을 많이 익히면
동시에 논리적인 사고도 많이 늘지 않나요 ?
사고력이 완전히 타고나는 것도 아니고요.

많이 익히는 것과 많이 아는 것과는 다르다고 생각합니다..
알고리즘을 익힌다면 논리적인 사고도 당연히 늘겠지요..

그리고 사실 웹프로그래밍을 하는데에는 전체적인 흐름이 중요하지, "무슨 무슨 알고리즘" 해서 따로 나와 있는 알고리즘이 필요했던 일은 없는 것 같습니다.

-- 추가로.. 논리적인 사고를 키우는 것에는 알고리즘을 익히는게 좋은 방법이긴하나 알고리즘을 익히는 방법만 있는건 아니지요.. ;)

skjk의 이미지

높은 수준의 프로그램을 개발하려고 할수록 학교에서 배우는 이론적인 지식이 더욱 중요합니다. 그리고 웹프로그래밍이라는 게 대게 어떠한 자료를 가공해서 어떤 특정 형태로 보여주는 게 주된 목적인데 기초적인 소팅알고리즘조차 모른다면 그 결과물은 볼 가치도 없을 거 같네요.

stmaestro의 이미지

아. 물론 저도 완벽하게 운영체제 사용을 인식하고 있는 것까진..
뭐 그렇다 치더라고도요.

최소한 '웹'프로그래밍을 쓰는 사람에게
보안이나 윈도우에서 IP주소 찾는것쯤은
알아두어야 할 것들 아닌가요?

아무리 그래도 관련이 없는 것도 아니고.
게다가 보안이라는 것은..... 말이 필요없죠

괜히 우리나라에 윈도우 보안 패치 안해줘서
웜바이러스 대란 났겠습니까.
(물론 책임이 반드시 사용자로만은 아닙니다만)
그동안 서버운영하는 사람들은
다들 뭐했길래.. 라는 생각이 들더랍니다.

심지어 저는 예전에. 모 초고속 인터넷 업체에서
시설 점검한다고 오신분이 인터넷 만지다가.
엑티브엑스가 차단되는 것을 못찾으시기에
무척이나 당황스러웠습니다.
모르신다고 하더라고요.
엑티브엑스는 인터넷 점검하는 것과
상당히 연관이 있을텐데도 말이죠.

litdream의 이미지

skjk wrote:
높은 수준의 프로그램을 개발하려고 할수록 학교에서 배우는 이론적인 지식이 더욱 중요합니다. 그리고 웹프로그래밍이라는 게 대게 어떠한 자료를 가공해서 어떤 특정 형태로 보여주는 게 주된 목적인데 기초적인 소팅알고리즘조차 모른다면 그 결과물은 볼 가치도 없을 거 같네요.

절대 동감합니다.
요즘 학교수업들었던것까지 다 꺼내서 프로젝하고 있습니다.
다닐때는 모르다가, 학교가 이럴때 쓸모가 있구나~~ 싶습니다.

소트를 몰라도 프로그램은 한다는 분이 소트를 알기보단 소트를 빨리
익힐수 있는사람을 선택하겠다고 마이크로 소프트를 거론하셨는데...
제 옆자리에서 같이 프로젝트 짜는친구 같아서, 그냥 말을 말으렵니다.
그럴때는.. "오~~ 넌 그러냐? " 하고 넘어가야지, 같이 얘기하면
같이 바보됩니다.

삽질의 대마왕...

creativeidler의 이미지

프로그래밍에도 여러 가지 종류가 있습니다. 여기서는 주로 단위 애플리케이션 프로그래밍을 이야기하는 듯 한데, 소프트웨어 업계에서 가장 큰 비중을 차지하는 것은 엔터프라이즈 애플리케이션, 보통 SI라고 부르는 것들입니다. 그리고 요즘은 SI의 주류가 바로 웹 프로그래밍이죠. 일단 이런 배경을 깔고 이야기를 해야할 것 같습니다.

이런 SI에서 중요한 것은 고객의 요구사항을 정확하게 파악해서 프로그램으로 옳겨놓는 것입니다. 이 과정에서 중요시되는 능력은 논리적인 사고 능력과 필요한 기술을 빨리 배울 수 있는 학습 능력, 그리고 고객을 대하는 겸손함이죠. 솔직히 머리만 좋으면 프로그래밍 한 번도 안해본 사람도 1달만 가르치면 웹 프로그래머의 일원으로써 충분히 잘 기능하게 교육시킬 수 있습니다.

어떤 분이 SI가 실패하는 이유로 알고리즘 같은 기초를 모르기 때문이라 하셨는데, 기초가 부족한 프로그래머가 투입되는 것이 실패의 중요한 원인은 맞습니다만 그 기초가 알고리즘은 저~~~얼대 아닙니다. 알고리즘 몰라서 실패한 프로젝트가 세상에 어디 있습니까-_- SI의 주요 실패 원인은 부적절한 갑과 을의 관계가 첫번째이고 그 다음이 부적절한 방법론, 개발자들의 마인드 부족, 기술 부족 등이죠. 알고리즘 자체는 전혀 중요하지 않습니다.

물론, 알고리즘이 기초로 작용하는 분야도 있습니다. 그것까지 부정하진 않습니다. 그러나, 웹 프로그래밍에는 알고리즘 책에 나오는 알고리즘들이 전혀 필요 없다고 해도 과언이 아닙니다. DB는 뭐하러 있는 거겠습니까.

알고리즘을 배우는 과정에서 사고 능력이 느는 것은 인정합니다. 저 역시 정보올림피아드 하던 시절의 경험이 적지 않은 도움이 되고 있으니까요. 하지만 알고리즘 자체는 거의 필요가 없고 필요할 경우에도 단 몇 시간이면 충분히 배울 수 있습니다. 솔직히 퀵 소트 같은 거 이해시키는데 10분도 안 걸립니다. 이미 필요한 알고리즘들이 다 연구된 지금 시대에 알고리즘은 단순 지식일 뿐이며 이를 기준으로 '능력'을 판단하려는 우를 범해서는 안될 것입니다.

그리고 코더와 프로그래머를 나누는 것도 웃기지만 굳이 나눈다면 코더는 단순히 무언가를 코드로 옮기기만 하면 되는 사람이고 프로그래머는 스스로 무엇을 코딩해야하는지를 판단하는 사람으로 나눌 수 있겠죠. '이미 다 연구된 소트 알고리즘'을 코드로 옮기는 사람은 코더일까요? 프로그래머일까요? 현실 세계의 요구사항을 추상화해서 객체로 만들어내는 사람은 코더일까요? 프로그래머일까요?

creativeidler의 이미지

Quote:
소트를 몰라도 프로그램은 한다는 분이 소트를 알기보단 소트를 빨리
익힐수 있는사람을 선택하겠다고 마이크로 소프트를 거론하셨는데...
제 옆자리에서 같이 프로젝트 짜는친구 같아서, 그냥 말을 말으렵니다.
그럴때는.. "오~~ 넌 그러냐? " 하고 넘어가야지, 같이 얘기하면
같이 바보됩니다.

풋, 이런 식의 인신공격성 발언 밖에 못하는 사람이 저보다 똑똑할 꺼라고 생각되진 않는군요.

alfalf의 이미지

자동차 구조나 정비하는 법을 몰라도 운전은 다 할 수 있지 않습니까? 다만, 전문 레이서들은 운전 연습 외에도 최고의 자동차 성능을 내기 위해 자동차 구조나 정비에 대해서 열심히 공부하더군요. 우리가 프로라는 이름을 붙이기 위해서 (돈을 받고 일한다고 무조건 프로가 아니라...) 자기가 하고 있는 일과 관련된 지식에 대해 어느 정도 이상의 소양이 필요한거 아닐까요?

cocas의 이미지

alfalf wrote:
자동차 구조나 정비하는 법을 몰라도 운전은 다 할 수 있지 않습니까? 다만, 전문 레이서들은 운전 연습 외에도 최고의 자동차 성능을 내기 위해 자동차 구조나 정비에 대해서 열심히 공부하더군요. 우리가 프로라는 이름을 붙이기 위해서 (돈을 받고 일한다고 무조건 프로가 아니라...) 자기가 하고 있는 일과 관련된 지식에 대해 어느 정도 이상의 소양이 필요한거 아닐까요?

전문 레이서 뿐만 아니라 일반 운전자들도 기초적인 정비는 할줄 알아야 합니다. 운전 면허 시험을 볼때도 차량의 기본 구조를 가르치도록 하고 있습니다. ( 만 별로 실효성은 없습니다. -_-;; )

차량 정비, 튜닝을 끝내주게 잘한다고 다 좋은 운전자는 아닙니다. 그리고 alfalf님 말씀대로 정비하는 법 전혀 몰라도 운전할 수 있습니다. 하지만 고속도로에서 갑자기 차가 이상을 보인다던가, 그런 경우엔 어떻게 될까요? 아는 사람과 모르는 사람의 차이가 극명하게 드러나리라 봅니다. 정말 베테랑 운전자들은 구조, 정비에 대해 정비사 만큼은 아니더라도 충분히 익히고 있습니다.

웹 프로그래머가 자기 컴퓨터의 웜, 바이러스를 고칠 줄 모른다고 했을 때 이런 상황도 가정할 수 있습니다. 다른 사람들은 멀쩡히 컴퓨터를 쓰고 있습니다. 해당 프로그래머는 메신저로 전파되는 웜 파일을 모르고 실행합니다. 해당 파일은 회사 내의 다른 컴퓨터에게 과도한 트래픽을 전송합니다. 회사 내부와 외부를 아무리 잘 차단하더라도 회사 내부의 신뢰받는 컴퓨터 하나가 당하면 회사 전체에 문제가 생길 수 있습니다. 작게는 해당 웹 프로그래머의 작업 중지부터 크게는 회사 전체의 작업 중지까지 피해가 있을 수 있네요.

자기 컴퓨터가 악성 프로그램의 활동지가 될 수 없게 미리 조치하고 후에라도 치료하는 것은 컴퓨터 사용자의 기본 덕목입니다. 프로그래머 또한 컴퓨터 사용자일때 이 경우 프로그래머는 잘못이 많다고 생각합니다. 프로그래머로서가 아니라 컴퓨터 사용자로서 말이죠.

warpdory의 이미지

creativeidler wrote:
어떤 분이 SI가 실패하는 이유로 알磁??같은 기초를 모르기 때문이라 하셨는데, 기초가 부족한 프로그래머가 투입되는 것이 실패의 중요한 원인은 맞습니다만 그 기초가 알고리즘은 저~~~얼대 아닙니다. 알고리즘 몰라서 실패한 프로젝트가 세상에 어디 있습니까-_- SI의 주요 실패 원인은 부적절한 갑과 을의 관계가 첫번째이고 그 다음이 부적절한 방법론, 개발자들의 마인드 부족, 기술 부족 등이죠. 알고리즘 자체는 전혀 중요하지 않습니다.

물론, 알고리즘이 기초로 작용하는 분야도 있습니다. 그것까지 부정하진 않습니다. 그러나, 웹 프로그래밍에는 알고리즘 책에 나오는 알고리즘들이 전혀 필요 없다고 해도 과언이 아닙니다. DB는 뭐하러 있는 거겠습니까.

알고리즘을 배우는 과정에서 사고 능력이 느는 것은 인정합니다. 저 역시 정보올림피아드 하던 시절의 경험이 적지 않은 도움이 되고 있으니까요. 하지만 알고리즘 자체는 거의 필요가 없고 필요할 경우에도 단 몇 시간이면 충분히 배울 수 있습니다. 솔직히 퀵 소트 같은 거 이해시키는데 10분도 안 걸립니다. 이미 필요한 알고리즘들이 다 연구된 지금 시대에 알고리즘은 단순 지식일 뿐이며 이를 기준으로 '능력'을 판단하려는 우를 범해서는 안될 것입니다.

제가 언제 '알고리듬이 전체다' 라고 했습니까 ? 알고리듬 등을 포괄하는 '기초'가 중요하다고 했습니다.
퀴소트 같은 거 이해시키는데 10분도 안 걸리겠지요. 하지만, 그 10분도 안 걸리는 기반을 닦는 데에는 몇년이 걸립니다. 즉, 퀵소트 알고리듬을 10분내에 이해할 수 있을 정도라면 다른 '기반'은 어지간히 닦여져 있는 '고급 인력'이라는 얘기입니다.
즉, 10분내에 이해할 수 있는 수준의 소트 알고리듬도 이해 못하는 페이퍼 MCSE, 정보처리기사 ... 등등의 자격증 소지자들이 공장에서 찍어내듯이 학원에서 문제 외워서 투입 되기 때문에 기본적으로 결과가 개판이 될 수 밖에는 없는 겁니다. 그러한 것들이 개발자들의 마인드 부족이고(대충 하면 되겠지.. 라는 것) 기술 부족이고, 기술이 부족하고 마인드가 부족하니 제대로 된 방법론이 나올 수 없는 것이고, 그렇기 떄문에 불공정하게 갑과 을의 계약에서 밀릴 수 밖에는 없는 겁니다.

즉, 10분만 투자하면 되는 기초수준의 알고리듬도 이해 못하는 상태에서 개발자들이 투입되는데(실제로 저는 SI 업계에서 일하지는 않습니다만, 그들과 같이 일을 몇넌 해 봤기 때문에 제 3 자의 관점 - 갑도 아니고 을 도 아닌 관점이지요. - 에서 볼 수 있기 때문에 어느쪽체 치우치지 않을 수 있다고 생각합니다.) 그것을 옆에서 지켜 보면, 환장합니다. db 관리자라고 투입된 사람이 오라클 스타트도 못 시키는 것도 봤고, 네트웍 관리자라고 투입된 사람이 ip address 충돌난 것 해결 못해서 배쨰고 있는 것도 지겨도록 겪었었습니다.

저쪽 쓰레드에도 썼었는데... 슬램덩크에서 강백호가 매일 꿈꾸던 건 멋진 슬램덩크지만, 결국 산왕을 이기는 데 썼던 기술은 멋진 슬램덩크가 아닌 오른쪽 45 도 각도의 슛입니다. 농구에서는 아주 '기초'에 해당하는 것이지요. 기초가 허접하면 될 것도 안됩니다. 강백호가 멋져 보인다고 드리블, 레이업 슛, 리바운드, 골밑 슛 .. 이런 거 연습 안하고 '까짓 것 10분이면 배울 수 있어.' 라며 연습 안하고 대충 넘어갔다면 오른쪽 45 도 슛은 나올 수 없었지요.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

creativeidler의 이미지

Quote:
제가 언제 '알고리듬이 전체다' 라고 했습니까 ? 알고리듬 등을 포괄하는 '기초'가 중요하다고 했습니다.

저 역시 기초가 중요하지 않다고 한 적은 처음부터 끝까지 단 한 번도 없습니다. 알고리즘은 기초가 아니라고 했을 뿐이죠.

님은 알고리즘이 전체라고 하진 않았지만 알고리즘을 모르는 것이 기초가 부족한 것이고 기초가 부족하기 때문에 SI가 실패한다는 논리를 전개하셨으니 결국 알고리즘에 대한 이해의 부족이 SI를 실패하게 만든다는 주장이나 다름 없습니다. 그래서 전 알고리즘 몰라도 SI는 얼마든지 잘할 수 있으며 SI가 실패하는 요인에 알고리즘은 절대 포함되지 않는다는 주장을 한 것입니다.

그리고 기술력 부족 때문에 갑과 을의 계약에서까지 말린다는 얘기는 SI를 모르기 때문에 하는 말이라고 밖에 보이지 않는군요. 많은 SI들이 처음부터 어떤 인력이 투입되건 실패할 수 밖에 없는 상황에서 출발을 합니다. 방법론? 제안서 쓸 때부터 다 정해지고 심지어 갑이 정해놓는 경우도 부지 기수입니다. 감리 때마다 필요도 없는 문서들 밤낮 없이 써내야하고 갑 뒷바라지 하느라 바쁘죠. 이런 상황에서 기술력의 문제는 작은 문제입니다.

이런 건 당장 자기 회사만 마인드를 갖춘다고 해결이 되지 않습니다. 자기 회사만 좋은 마인드를 갖추면 갑에게 미움 받아 자기 회사만 일거리 못 따고 망할 뿐이죠-_- 한국 SI 업계 전반에 걸쳐 있는 문제입니다.

그리고 퀵 소트를 10분 만에 이해하려면 몇 년의 기반을 닦아야한다는 건 오바입니다. 퀵 소트를 배우기 위해 알아야하는 사전 지식은 해당 언어의 기본 문법과 재귀 호출 뿐입니다. 이 정도 배경 지식을 갖추는데 몇 년이 걸린다굽쇼?고급 인력? 저런 거 하는데는 전문대 나올 사고 능력만 되도, 아니 고등학교 교과 과정을 이해만 할 수 있는 수준이 되도 절대 어려운 일이 아닙니다. 말도 안된다구요? 한 명 시험 삼아 데려와보십쇼. 아무 프로그래밍 언어든지 언어 하나 기본 문법만 잘 알고 있으면 10 분안에 퀵 소트 이해시키고 2시간 안에 스스로 구현할 수 있도록 만들어드리죠.

거듭 말하지만 기초의 중요성은 저도 부정하지 않습니다. 하지만 알고리즘은 결코!! 프로그래밍의 기초가 아니며 몰라도 얼마든지 좋은 프로그램을 만들 수 있습니다.

계산기 알고리즘. 리커전 한 번 돌리면 끝나는 퀵소트에 비하면 훨씬 복잡한 알고리즘이죠? 전 알고리즘 하나도 모르고 프로그래밍 입문한지 2주도 안되는 사람이 혼자서 계산기를 만들어내는 것을 본 적이 있습니다. 제가 가르쳐준 건 단지 TDD 뿐인데 말입니다.

NeoTuring의 이미지

creativeidler wrote:

거듭 말하지만 기초의 중요성은 저도 부정하지 않습니다. 하지만 알고리즘은 결코!! 프로그래밍의 기초가 아니며 몰라도 얼마든지 좋은 프로그램을 만들 수 있습니다.

계산기 알고리즘. 리커전 한 번 돌리면 끝나는 퀵소트에 비하면 훨씬 복잡한 알고리즘이죠? 전 알고리즘 하나도 모르고 프로그래밍 입문한지 2주도 안되는 사람이 혼자서 계산기를 만들어내는 것을 본 적이 있습니다. 제가 가르쳐준 건 단지 TDD 뿐인데 말입니다.

SI분야가 타분야보다 알고리듬을 더 필요로하는것은 아니라는것을 놓고 알고리듬이 기초가 아니라는 얘기로 일반화 시킬 이유는 없습니다. 중요한것은 특정 알고리듬을 외우고 있느냐가 아니라 그런 알고리듬들을 이해해서 얼마나 잘 사용할 수 있도록 준비되어 있느냐하는것이죠. 아무리 봐도 알고리듬이 기초가 아니라는 얘기는 어불성설인것 같습니다.

그리고 TDD 너무 믿지 마시길... 코딩시 TDD 로 하는것은 괜찮다고 보지만, 설계시부터 사용하는것은 반대입니다. 물론 애자일쪽에선 이런 제 입장을 거부하겠지만...

creativeidler의 이미지

Quote:
SI분야가 타분야보다 알고리듬을 더 필요로하는것은 아니라는것을 놓고 알고리듬이 기초가 아니라는 얘기로 일반화 시킬 이유는 없습니다.

확대해석하는 경우는 많이 봤지만 축소해석하는 경우는 또 처음이군요. 제 말은 SI가 타분야보다 알고리즘을 덜 필요로 하기 때문에 기초가 아니라는 게 아닙니다. SI는 아예 알고리즘을 필요로 하지 않거나 극히 드물게 필요로 한다는 거죠.

일반화는 오히려 당신이 하고 있는 것 아닌가요? 필요하지도 않은 것을 기초라고 말하는 것이 훨씬 더 어불성설인 거 같은데요?

알고리즘이 기초라고 강변하면서 그게 웹 프로그래밍에서 왜 필요한지에 대해 구체적으로 언급하는 사람이 없는 것도 참 재밌군요. 알고리즘 모르면 프로그래밍 못할 것이라는 막연한 추측. 그것이 근거의 전부인가요?

blueruin의 이미지

creativeidler wrote:

거듭 말하지만 기초의 중요성은 저도 부정하지 않습니다. 하지만 알고리즘은 결코!! 프로그래밍의 기초가 아니며 몰라도 얼마든지 좋은 프로그램을 만들 수 있습니다.

알고리즘은 결코 프로그램의 기초가 아니다.. 라는건 아주 진보적인 사고방식이거나 남들보다 뛰어난 천재성을 필요로 하는 발상이네요.

그냥 문득 생각난 일화로,
얼마전 모 유명회사와 공동프로젝트를 할때 윈도우즈 클라이언트 부분을 그 회사자체개발팀에서 담당했는데 프로젝트 초기술자리에서 이런이야기를 하더군요.
"API 같은거 난 모른다, 그냥 MFC에 다른사람들이 만들어놓은 라이브러리 사쓰면 된다"
효율적인 사고방식이지만 이게 현실인가.. 라는 생각에 좀 씁쓸했습니다.

또 그 팀의 소스(그사람이 검수한 코드)를 살펴보면 좀 과장해서 지루한 장편소설이었습니다.
같다 붙이는 라이브러리도 해당 루틴에 익보다는 실을 더 많이 주고, 사용방법도 전혀 효율적이지 못했습니다. 왜 이렇게 했냐고 물어보니 그건 그냥 그렇게 하면 된답니다. 지금까지 해왔던대로 한거죠.

답답한 마음에 저희팀 신입한테 테스트할겸 코드 수정해오라고 했더니 한시간만에 3,000줄짜리를 500여줄로 줄여왔습니다.
더 놀라운것은 그 사람이 하는 말이 "이런것도 있네요?"
우리 신입친구는 "그냥 배운대로 했는데요" 였습니다.

간단한 소트알고리즘은 고등학교 전산과목, 혹은 대학 교양전산정도에 배우는걸로 알고있습니다.
연산, 통계, 사인,코사인, 미/적분, 인수분해... 이런 아주기초적인것들이 효율적인 코드를 만드는 발판이 됩니다. 이런것들을 프로그래밍에 효율적으로 사용할 수 있도록 공식화 해놓은것이 바로 "알고리즘" 이고요.
그런데 왜 알고리즘이 프로그래밍의 기초의 부분집합이 아니라고 주장하시는지 모르겠네요.
전 오히려 문법보다 효율적인 알고리즘을 사용하는것이 더 중요한 기초라고 생각합니다.
왠만한 언어의 문법은 3달과정이면 대부분 익히지만 상황에 맞는 적절한 알고리즘이 존재한다는것을 발견하는데는 3년도 부족합니다.

아주 좋은 A 라는 방법이 있는데 그 방법을 몰라 A 와 비슷한 일을 하는 B를 만드는건 최악중 최악이죠. :(

요즘 유치원에서 구구단을 많이 가르친다고 합니다.
"이일은이, 이이사... 구구팔십일" 기똥차게 합니다.
하지만 이아이들은 초등학교들어가서 "구구팔십일" 이 "9가 9개 있어서 81이구나.." 라고 감탄할겁니다.
또, 구구단을 모르는 아이는 "9가 9개 있으면?" 을 9+9+9... 로 계산을 하다 구구단을 알게되면 그 위력을 실감하겠죠.

추가>>
전 요즘도 논문으로 발표되거나 새로나온 기술에 적용된 알고리즘들이 있으면 틈나는대로 읽고있습니다.
꼭 그걸 익히기위해서가 아니라 그렇게 눈길한번 줘두면 언젠가는 유용하게 사용하는 경우가 많기때문입니다.
복잡한 알고리즘들을 수학공식써내려가듯이 쫙 외울필요없습니다.
그냥 이해하고 필요할때 적용할 수 있을정도로 내용을 이해하고 필요할때 구현할수있으면 됩니다.

time to wait...

fox9의 이미지

creativeidler wrote:
그리고 퀵 소트를 10분 만에 이해하려면 몇 년의 기반을 닦아야한다는 건 오바입니다. 퀵 소트를 배우기 위해 알아야하는 사전 지식은 해당 언어의 기본 문법과 재귀 호출 뿐입니다. 이 정도 배경 지식을 갖추는데 몇 년이 걸린다굽쇼?고급 인력? 저런 거 하는데는 전문대 나올 사고 능력만 되도, 아니 고등학교 교과 과정을 이해만 할 수 있는 수준이 되도 절대 어려운 일이 아닙니다. 말도 안된다구요? 한 명 시험 삼아 데려와보십쇼. 아무 프로그래밍 언어든지 언어 하나 기본 문법만 잘 알고 있으면 10 분안에 퀵 소트 이해시키고 2시간 안에 스스로 구현할 수 있도록 만들어드리죠.

원글을 쓰신분이 퀵 소트를 10분 안에 이해하려면 무조건 몇년을 준비해야 한다고 말씀하신게 아니라 꽤 오랜 시간이 필요할 수 있다는 뜻으로 얘기한듯 한데요. 이런 말꼬리 잡기 싸움은 되도록 피하는 것이 좋을 듯 합니다.
약간은 틀린 예이지만 '나 지금 배고파 죽겠다' 라고 말했을때 사실 그말은 죽을 정도로 아픈건 아니니깐요.
자신의 주장 및 근거 그리고 반론 등으로 토론을 해야지 말꼬리 잡기는 썩 좋아 보이지 않습니다.
그리고 위처럼 말씀하셨는데 10분안에 퀵소트 이해시키고 2시간안에 스스로 구현할 수 있도록 만들어 주신다 했는데 그 시간에 가능한 사람도 있겠지만 못하는 사람도 많이 있을 것입니다.
말씀하신 내용으로 아무도 실험해 본적이 없으니깐요.

creativeidler wrote:
거듭 말하지만 기초의 중요성은 저도 부정하지 않습니다. 하지만 알고리즘은 결코!! 프로그래밍의 기초가 아니며 몰라도 얼마든지 좋은 프로그램을 만들 수 있습니다.

알고리즘 모른다고 좋은 프로그램 못 만든다고 하신분은 없으신듯 합니다. 해석하기에 따라서 약간 애매모호한(?) 문장들은 좀 있지만 말입니다.

fox9의 이미지

creativeidler wrote:
알고리즘이 기초라고 강변하면서 그게 웹 프로그래밍에서 왜 필요한지에 대해 구체적으로 언급하는 사람이 없는 것도 참 재밌군요.

웹프로그래밍이라고 찝어서 말하지는 않았지만 윗글들을 잘 보시면 왜 알고리즘이 프로그래밍에서의 기초인지에 대한 설명글들은 많이 있습니다.

creativeidler wrote:
알고리즘 모르면 프로그래밍 못할 것이라는 막연한 추측. 그것이 근거의 전부인가요?

알고리즘 모르면 프로그래밍 못할 것이라고 어느분이 말씀하셨는지 모르겠지만 방금도 제가 쭉 글들을 읽어봤는데
알고리즘 모른다고 프로그램 못짠다는 글을 안 보입니다.

그리고 글들을 잘 읽어보시면 알고리즘은 기초라고들 모두 말하고 있지 필수라고 말하고 있지 않습니다.

creativeidler의 이미지

Quote:
알고리즘 모르면 프로그래밍 못할 것이라고 어느분이 말씀하셨는지 모르겠지만 방금도 제가 쭉 글들을 읽어봤는데
알고리즘 모른다고 프로그램 못짠다는 글을 안 보입니다.

그리고 글들을 잘 읽어보시면 알고리즘은 기초라고들 모두 말하고 있지 필수라고 말하고 있지 않습니다.

허허, 그렇다면 버블 소트를 모르는 사람에 대한 비웃음과 경멸이 담긴 글들, 그딴 것도 모르는 게 신기하다는 표현, 기초가 부실해서 SI가 실패한다는 말들은 다 뭔가요? 다 그런 것도 모르면서 웹 프로그래밍하냐는 의미가 담겨 있는 것 아니던가요? 이게 제 확대 해석인가요?

기초와 필수의 차이? 말꼬리 잡지 말자면서 말장난을 하고자 하십니까? 제가 보기에 여기서 기초라는 말을 쓰신 분들은 다 필수라는 의미를 내재하고 쓰신 것으로 보이는데 이것도 제 오해인가요? 필수가 아닌 기초는 대체 어떤 것들이 있나요?

Quote:
원글을 쓰신분이 퀵 소트를 10분 안에 이해하려면 무조건 몇년을 준비해야 한다고 말씀하신게 아니라 꽤 오랜 시간이 필요할 수 있다는 뜻으로 얘기한듯 한데요. 이런 말꼬리 잡기 싸움은 되도록 피하는 것이 좋을 듯 합니다.

몇 년이라는 건 상대의 표현을 그대로 인용한 것일 뿐 오랜 시간이 걸린다는 의미는 받아들였고 거기에 대해 아주 짧은 시간에 가능하다는 말로 반론을 하고 있는 것입니다. 이런 게 말꼬리 잡기면 도대체 뭘 근거로 반론을 하란 얘긴가요?

Quote:
웹프로그래밍이라고 찝어서 말하지는 않았지만 윗글들을 잘 보시면 왜 알고리즘이 프로그래밍에서의 기초인지에 대한 설명글들은 많이 있습니다.

글쎄요. 제가 보기엔 설명이라기보다 그냥그냥 알고리즘이 프로그래밍의 기초라는 말의 동어 반복 밖에 없는 것 같은데요. 주장만 있고 근거는 별로 없는.. 그 외에 알고리즘을 배우는 과정에서 사고 능력이 신장되는 것이 중요하다는 말은 있었지만 그건 알고리즘 이외의 수단으로도 가능하다는 말로 반박되었죠. 그 외에 또 동어 반복이 아닌 설명이 있었던가요?

warpdory의 이미지

저는 '기초'라고 했지 '필수' 내지는 '전부'라고 한 적 없습니다.
알고리듬을 모른다고 해서 프로그래밍을 못한다고 한적도 없습니다. 제 글을 다시 잘 읽어 보시길 권합니다.

SI 에서 갑과 을 중요합니다. 그런데, 그 반대의 경우도 많거든요 ? 을이 더 센 힘을 가지고 갑을 가지고 노는 경우도 많습니다. 중소 업체들이 뭐 할 때 많이 당합니다. 1999년에 수없이 많은 SI 업체들이 중소기업 돌아다니면서 Y2K 인증 필요하다며 사기친 경우도 그런 경우이지요.

--------

더이상 말꼬리나 잡는 논쟁아닌 말꼬리 유희는 여기서 그만두겠습니다.

기초가 중요한 겁니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

creativeidler의 이미지

creativeidler:

Quote:
덧붙여, 소트를 할 줄 안다는 게 뭐 그리 대단한 건지 모르겠습니다. 프로그래밍하면서 소트 알고리즘을 알아야하는 경우는 극히 드뭅니다. 알고리즘 따위 전혀 몰라도 프로그래밍하는데 별 지장 없습니다. 그런 지식 따위는 필요할 때 익히면 되는 겁니다.

warpdory:

Quote:
기초가 허약하면 부실공사 밖에는 안나오는 겁니다. 그래서 SI 가 그 따위 결과 밖에는 안나오는 거지요.

creativeidler:

Quote:
알고리즘이 프로그래밍의 기초라고 생각하시나요?

warpdory:

Quote:
기초중 하나입니다.

이 말들을 기준으로 생각하면 warpdory님의 주장은 이렇습니다.
1. 알고리즘은 기초다.
2. 기초가 없으면 부실공사가 생긴다.
3. 따라서, 알고리즘이 없으면 부실공사가 생긴다.

설마 이걸 보고 제가 왜곡되게 인용했다고 하진 않으시겠죠? 물론 3번을 직접 주장하진 않으셨지만 1, 2번을 주장하신 이상 3번은 삼단논법상 자동이죠. 이대로라면 님은 알고리즘이 없으면 부실공사가 생긴다고 주장하면서도 알고리즘은 필수가 아니라는 말을 하는 셈입니다. 기초니 필수니 말장난으로 피해가지 마십시오. 어쨋든 필수가 아닌 기초라 주장했다고 해도 전 어차피 기초건 필수건 다 아니라고 주장하는 거니까 마찬가지입니다.

NeoTuring의 이미지

creativeidler wrote:
Quote:
SI분야가 타분야보다 알고리듬을 더 필요로하는것은 아니라는것을 놓고 알고리듬이 기초가 아니라는 얘기로 일반화 시킬 이유는 없습니다.

확대해석하는 경우는 많이 봤지만 축소해석하는 경우는 또 처음이군요. 제 말은 SI가 타분야보다 알고리즘을 덜 필요로 하기 때문에 기초가 아니라는 게 아닙니다. SI는 아예 알고리즘을 필요로 하지 않거나 극히 드물게 필요로 한다는 거죠.

일반화는 오히려 당신이 하고 있는 것 아닌가요? 필요하지도 않은 것을 기초라고 말하는 것이 훨씬 더 어불성설인 거 같은데요?

알고리즘이 기초라고 강변하면서 그게 웹 프로그래밍에서 왜 필요한지에 대해 구체적으로 언급하는 사람이 없는 것도 참 재밌군요. 알고리즘 모르면 프로그래밍 못할 것이라는 막연한 추측. 그것이 근거의 전부인가요?

무엇을 축소해석했는지 모르겠습니다. 또 "SI가 타분야보다 알고리즘을 덜 필요로 한다"는것과 "아예 알고리즘을 필요로 하지 않거나 극히 드물게 필요로 한다"라는것이 의미상 얼마나 차이가 나는 진술인가요? 게다가 알고리즘을 전혀 필요로 하지 않는다는것은 엄밀하게 말해 사실이 아닙니다. 범용라이브러리, API에 이미 알고리즘이 결합되어 있기 때문이죠. 라이브러리에 의존성을 가지는 이상 자신도 모르게 이미 널리 알려진 알고리즘을 사용하고 있는걸로 생각해야 합니다.

그럼 자신이 만드는 프로그램 코드자체에 그런 알고리즘을 사용하지는 않는다고 얘기하실건가요? 그것도 그렇지 않습니다. 시퀀스로 표현되는 모든 코드가 전부 알고리즘으로 규정될 수 있습니다. 모든것이 알고리즘입니다. 다만, 학교에서 책으로 배우게 되는 알고리즘은 그중에 가장 "효율적"이라고 판명되었거나 특히 자주 사용되는것들, 또 수학적으로 엄밀하게 증명된 것들을 엄선해서 차후에 어떤 문제를 대하든지 그것을 풀고자 할때 시행착오를 줄이게 하려는 의도로 학생들을 훈련시키기 위해 하나의 책에다가 그런 알고리즘들을 모아 놓은것에 불과합니다.

물론 SI 프로젝트가 그런 "범용" 알고리즘을 덜 사용한다는 특성은 잘 이해하고 있습니다. 하지만, 앞서 말했듯 모든 프로그램이 알고리즘(그것이 효율적이든 아니든간에)을 사용하고 있으므로 SI 분야의 프로그램이 알고리즘을 사용하지 않는다고 얘기하는것은 말이 되지 않습니다. 그리고 알고리즘은 문제를 해결하는 시퀀스의 패턴이라는 점을 상기해보면 SI 분야조차도 수없이 많은 시행착오를 통해 검증되고 또 재사용되는 공통의 루틴이 존재한다면 그것을 공용의 알고리즘으로 약속해둘 수 있습니다. 비록 학교의 책에서 배운 그런 알고리즘이 아닐지라도 필드에서 일하면서 그런 시퀀스의 공통된 패턴을 추출해내는것은 가능한 일입니다. 그리고 그런 패턴을 잘 사용하는 사람이 더 좋은 결과물을 내는것은 더 말할 나위도 없는것입니다. 물론 그러한 패턴들 역시도 결국엔 학교에서 배우는 범용 알고리즘들로 환원되겠지만 말이죠. (알고리즘의 스케일에 차이가 있을겁니다) 적합한(좋은) 알고리즘이냐 아니냐의 기준이 있을뿐이지 어떤것이 알고리즘이냐 아니냐는 무의미한 얘기입니다. 말장난은 그만하시죠.

creativeidler의 이미지

여기서 논의가 되는 것은 그런 광의의 알고리즘을 말하는 게 아니라는 거, 몰라서 그런 말씀 하시는 건가요? 제가 소트 라이브러리를 사용하는 일조차 없다고 말하는 것처럼 보이나요?

맞는 말이라고 언제나 '의미 있는 말'은 아닙니다. 이 쓰레드는 버블 소트를 모르는 것에 대한 비웃음에 제가 반론하기 시작하면서 여기까지 내려온 겁니다. 흐름 속에서 이해해주시기 바랍니다.

NeoTuring의 이미지

creativeidler wrote:
여기서 논의가 되는 것은 그런 광의의 알고리즘을 말하는 게 아니라는 거, 몰라서 그런 말씀 하시는 건가요? 제가 소트 라이브러리를 사용하는 일조차 없다고 말하는 것처럼 보이나요?

맞는 말이라고 언제나 '의미 있는 말'은 아닙니다. 이 쓰레드는 버블 소트를 모르는 것에 대한 비웃음에 제가 반론하기 시작하면서 여기까지 내려온 겁니다. 흐름 속에서 이해해주시기 바랍니다.


버블소트를 사용하지 않는 매우 일반적으로 사용되는 루틴조차도 검증되고, 재사용되는 빈도가 높으면 그것이 이미 "협의의 알고리즘"에 포함될 수 있다는것을 말하는겁니다. 결국 SI분야에서 개발 경험이 오래된 사람은 그렇지 않은 사람에 비해 그 분야의 "알고리즘"을 더 많이 더 잘 이해하는 사람입니다. 제가 말하는뜻을 이해하시겠는지요?
creativeidler의 이미지

그런 용도라면 이미 '패턴'이라는 단어가 있죠. 물론 알고리즘도 틀린 표현은 아니고 그렇게 볼 수 있는 것도 사실입니다만 일반적인 엔터프라이즈 컴퓨팅에서는 알고리즘이라는 용어조차 잘 등장하지 않습니다.

그리고, 설령 그게 '협의의 알고리즘'인 건 인정할 수 있다 해도 지금 논의가 되는 '기초로서의 알고리즘'과는 분명 다른 얘깁니다. 지금 버블 소트를 모른다고 비웃는 글에서의 알고리즘과 지금 NeoTuring님이 말씀하신 알고리즘은 분명히 거리가 있죠? 설마 그런 것들을 '기초'라고 주장하실 생각은 아니시겠죠?

정태영의 이미지

creativeidler wrote:
그리고, 설령 그게 '협의의 알고리즘'인 건 인정할 수 있다 해도 지금 논의가 되는 '기초로서의 알고리즘'과는 분명 다른 얘깁니다. 지금 버블 소트를 모른다고 비웃는 글에서의 알고리즘과 지금 NeoTuring님이 말씀하신 알고리즘은 분명히 거리가 있죠? 설마 그런 것들을 '기초'라고 주장하실 생각은 아니시겠죠?

버블소트는.. 프로그래밍을 시작할때 간단하게 해볼 수 있는.. 아주 대중화된 예제가 아니었던가요..? 충분히 상징적인 의미가 있지 않을까 싶습니다.. 물론 sorting 을 어떻게 하는 지 몰라도..

c standard library 에.. 이미.. qsort 등이 이미 들어가 있고.. 그냥 아주 간단하게 가져다 쓸 수 있지요.. (실제... 내부적으로 총 개수가.. 일정 수 이하면 버블소트등으로 처리하지만요.. )

요 근래 컴퓨터는 바이너리 서치같은걸 하지 않아도 충분히 빠르게 데이타를 찾아주기 때문에.. 구지 뭐 간단한 서칭 알고리즘등은 몰라도 되는 것도 맞구요..

뭐 데이타베이스를 사용하는 경우라면.. 그런 것들은 다 DBMS 에서 처리해주는 부분인 것도 맞습니다만..

알고서 쓰는 것과 모르고서 쓰는 것의 차이는 "분명히" 나지 않을까 싶군요..

뭐 하튼.. 쓰레드가 그다지.. 영양가 있는 쪽으로 흘러가는 듯 하진 않군요.. 잠금에 한 표 던집니다 :evil:

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

NeoTuring의 이미지

creativeidler wrote:
그런 용도라면 이미 '패턴'이라는 단어가 있죠. 물론 알고리즘도 틀린 표현은 아니고 그렇게 볼 수 있는 것도 사실입니다만 일반적인 엔터프라이즈 컴퓨팅에서는 알고리즘이라는 용어조차 잘 등장하지 않습니다.

그리고, 설령 그게 '협의의 알고리즘'인 건 인정할 수 있다 해도 지금 논의가 되는 '기초로서의 알고리즘'과는 분명 다른 얘깁니다. 지금 버블 소트를 모른다고 비웃는 글에서의 알고리즘과 지금 NeoTuring님이 말씀하신 알고리즘은 분명히 거리가 있죠? 설마 그런 것들을 '기초'라고 주장하실 생각은 아니시겠죠?

물론 디자인패턴도 알고리즘도 모두 패턴이라는 공통된 범주로 묶이는 것이지만, 여기서 DP를 말하고자 하는게 아닙니다. DP는 OO에서 객체들간의 관계를 나타낸 말이고, 제가 말하는 알고리즘과는 차이가 있습니다. 또 특정 분야의 특정 문제를 풀어내는 알고리즘은 많이 존재하며 그것들도 모두 "알고리즘"이라는 이름으로 명명되고 있습니다.(SI분야든 게임분야든 정도의 차이일뿐 그런것들이 어느정도 갖춰져 있습니다. creativeidler님도 해당 분야의 특정 문제에 대한 알고리즘을 한번 찾아보시죠.) 그리고 그런 알고리즘들은 거의 예외없이 "기초로서의 알고리즘"들(소팅을 포함하여 학교에서 배우는것들)을 기본 도구로서 사용하고 있습니다. 그럴 수 밖에 없는 이유가 있습니다. 학교에서 배우는 알고리즘은 그 단위가 매우 작고, 또 수학적으로 검증된것이므로 재사용성이 극히 높을 수 밖에 없기 때문입니다. 따라서 특정 분야에 사용되는 알고리즘을 이해하려고 한다손 치더라도 학교에서 배운 알고리즘이 그 기초가 되어야 하는것은 더 말할 필요도 없는것입니다.

물론 특정 분야에 사용되는 domain specific algorithm을 사용하지 않고서도 얼마든지 프로그램을 만드는것이 가능하고, 또 그렇게 해서도 문제가 없는 경우가 많습니다. 하지만, 프로그램이 돌아가기만 하면 된다는 식으로 프로그램을 만드는 사람과 실제로 그런 알고리즘을 사용해서 프로그램을 작성하는 사람 사이에는 기본 레벨에 차이가 있다는것은 명심해 두셔야 할것으로 봅니다. 이것은 프로그램을 만들어내는것이 가능하냐 안하냐의 문제가 아니라 얼마나 품질좋은 프로그램을 만들어내느냐의 문제입니다. 소음도 음악으로 쳐준다면 음악을 만드는것은 누구나 가능하지만, 음악을 "잘"만드는것은 누구나 할 수 있는 일이 아닙니다. 음악을 잘 만드려면 최소한 콩나물 대가리를 읽을 수 있어야 하고, 필요한 화성법을 익혀야 합니다. 그러나, 개가 피아노 위를 밟고 지나가면서 나는 피아노음도 음악으로 친다면 굳이 그것도 음악으로 못 들어줄 이유는 없습니다. 결국 이 문제는 그 정도 레벨에 머물러 있으면서 그정도에서 자족하느냐 아니면 "잘"만드는 정도의 레벨로 올라서느냐의 선택문제입니다. 본인이 소음수준의 음악을 만들어내면서 그것을 "음악"이라고 지칭한다면 그것을 굳이 음악이 아니라고 반박할 생각은 없습니다. 다만, 음악을 "잘"만드는데 화성법을 익힐 필요도 없다고 말 하지는 말아달라는것입니다. 본인의 주관적 생각을 일반화시켜 얘기하려면 근거가 있어야 합니다. 그런데 creativeidler 님의 글에는 그런 부분이 전혀 보이지 않는것 같습니다.

chadr의 이미지

Quote:
이 쓰레드는 버블 소트를 모르는 것에 대한 비웃음에 제가 반론하기 시작하면서 여기까지 내려온 겁니다.

제가 지은 비웃음은 버블소트조차도 자기 스스로 구현 해보지 않고 복사&붙여넣기로 컴공을 졸업한 사람에 대한 비웃음이었습니다만-_-a

버블소트.. 자신이 굳이 구현 할 필요 없죠..
이미 버그없고 견고한 알고리즘이 구현된 STL이라는게 있는데 엉뚱한데에 힘을 쓸 필요는 없죠..

그런다고 해서 항상 그런 라이브러리가 자신이 제작하는 프로그램에 적합하다고는 생각하지 않습니다.

불가피하게 해당 알고리즘을 약간 변형하여 작성해야 할 필요도 반드시 있을 것입니다.

그런데 이떄 알고리즘을 기본적으로 알고 있는 사람이 더 효율적인 코드를 만들어낼까요.. 아니면 생판 모르고 바로 책보고 이해하고 그대로 따라하기 식으로 만든사람이 더 효율적인 코드를 만들어낼까요?

뭐 그런 세세한 옵티마이징이야 요즘 머신 성능을 보면 무시해도 되겠지만..

두 사람중 어떤 사람이 덜컥하니 생뚱맞은 문제에 직면했을때 손쉽게 풀어나갈지는 안봐도 뻔하군요..

뭐 두번째 사람이 아주 뛰어난 천재적인 사람이라면 모르겠습니다.

예를 들어봅시다.

어떤 AI를 작성한다고 할떄..

기존에 알려진 AI 알고리즘중 대표적인것이 A*라는 알고리즘이 있습니다.
이 알고리즘은 구현도 매우 용이하고 잘 알려져서 자료도 많기 때문에 사용하기에는 좋습니다.
하지만 이 알고리즘의 큰 문제점은 특정조건에 속도가 무지 느릴수 있다는 것입니다. 그렇다면 이를 개선해야하는데.. 검색해보니 관련 자료가 무지 없었습니다.
그런데 그래프 알고리즘을 자신이 알고 있고 이 알고리즘을 A*에 접목시킬수 있다는 것을 발견했습니다.

여기까지 과정중 과연 어떤 사람이 이 과정을 더 빨리 알아차릴수 있고 접목을 시켰을 경우 더 효율적으로 접목을 시킬수 있을까요?
(참고로 A*와 그래프 알고리즘과 접목이 가능할지 않을지는 저도 모르겠습니다. 생각을 안해봤으니까요.. 단지 예로써 이해해 주시길 바랍니다.)

기초적인 알고리즘 지식을 가지고 있는 사람과 없는 사람중 어떤 사람이 더 일을 효율적으로 할 수 있을까요?

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

creativeidler의 이미지

네오튜링님과 제 생각의 차이는 '무엇이 기초인가'의 차이이지 '기초가 필요한가 아닌가'의 차이가 아닙니다. 화성법의 예는 조금 잘못 드신 것 같군요.

그리고, 실제로 그런 알고리즘의 예를 단 하나만이라도 들어주실 수 있겠습니까? 엔터프라이즈에서 미리 알지 못하면 빙빙 둘러가서 한참 걸릴 만한 그런 알고리즘 말입니다.

알고리즘을 모른다고해서 '돌아가기만 하는 프로그램'을 만든다고는 생각지 마시기 바랍니다. 오히려 전 알고리즘이나 패턴 때문에 냄새 나는 코드를 만드는 사람을 더 많이 봐왔습니다. 프로그램 디자인의 원칙들만 잘 지키면 알고리즘이니 디자인 패턴이니 하나도 몰라도 만들다보면 결과물이 자연스럽게 알고리즘의 틀이나 패턴의 형식으로 갖춰지면서 자연스럽게 좋은 코드를 만들어나갈 수 있습니다. 전 거의 처음부터 '좋은 코드'를 만드는 것이 중요하지 지식이 중요한 게 아니라는 말을 했습니다. 알고리즘 미리 안다고 '좋은 코드'를 만들까요? 천만에 말씀입니다.

근거로 말한다면 제가 보기에 님을 포함해서 알고리즘이 기초라고 주장하는 사람들이 "기초가 프로그래밍에서 중요한 이유"는 말하고 있지만 "알고리즘이 왜 프로그래밍의 기초인지"에 대해서는 말하고 있지 않습니다. 그에 비하면 "알고리즘을 사용하지 않는다"는 알고리즘이 프로그래밍의 기초가 아니라는데 대한 충분한 근거가 되지 않나요?

creativeidler의 이미지

Quote:
그런데 이ㅤㄸㅒㅤ 알고리즘을 기본적으로 알고 있는 사람이 더 효율적인 코드를 만들어낼까요.. 아니면 생판 모르고 바로 책보고 이해하고 그대로 따라하기 식으로 만든사람이 더 효율적인 코드를 만들어낼까요?

여기에는 전제에 잘못이 있습니다. 알고리즘을 모르는 사람이라 해서 "그대로 따라하기"식으로 프로그래밍을 한다고 가정하면 안되죠. 제가 가정해볼까요? A는 퀵 소트를 이미 알고 있고 B는 퀵 소트를 10분 만에 이해할 수 있는 사람입니다. 둘이 같이 프로그래밍을 하면 어떻게 될까요? A가 10분 일찍 완성할 가능성이 있겠죠-_- 그런 차이일 뿐입니다. 알고리즘이란 것은 일종의 지식 범주입니다. 알고나면 금방 같은 선상에 설 수 있는 그런 것이죠.

님이 드신 AI의 예는 알고리즘을 알면 좋은 경우의 예는 될 수 있으나 '알고리즘이 프로그래밍의 기초인 이유'는 되지 못합니다. 특수한 상황이니까요. 그런 예로 말한다면 소켓 프로그래밍을 해본 사람과 안해본 사람이 같이 채팅 프로그램을 만든다면 당연히 소켓 프로그래밍 해본 사람이 더 빨리 만들 것입니다. 그러나, 그렇다고 소켓 프로그래밍이 프로그래밍의 기초라고 말할 수는 없지 않겠습니까?

지식의 가치도 물론 중요합니다. 기초가 되는 지식도 물론 많습니다. 하지만 알고리즘은 아닙니다. 퀵 소트 알고리즘을 안다고 소트를 더 잘 사용할까요? b-tree 안다고 DB 인덱스 잘 잡습니까? 천만의 말씀입니다.

그리고, 버블 소트를 모른다고 copy&paste로 컴공을 졸업했으리란 건 비약입니다. 제가 갖고 있는 자료구조 & 알고리즘 책이 다섯 권 정도 되고 그 외에 본 것이 두 권 더 있는데 이 중에 제 기억으로 세 권은 버블 소트란 단어도 안 나옵니다. 지금 마침 고향집에 버려두고 갔던 책 하나 보이네요. 홍릉과학출판사의 자료구조론. 여긴 O(n^2)은 삽입 정렬 밖에 안 나옵니다. 제가 기억하기로 제 대학 교재(DS & Algo~ in Java)에도 버블 소트는 안 나왔었습니다.

그래서 프로그래밍에 대해 대학 가서 처음 접한 사람은 열심히 배웠더라도 모를 수 있죠. 게다가 초등학생도 이해할 수 있는 버블 소트를 모른다는 것이 그 사람이 그 정도 능력도 안된다는 것을 의미하진 않습니다. 그보다 말 그대로 접한 적이 없다고 봐야겠죠.

있으면 유용한 지식과 '기초 지식'은 구분해야할 것입니다. 알고리즘을 이미 알고 있으면 좀더 잘할 가능성은 물론 있습니다. 하나 그것이 '기초 지식'이라는 근거는 되지 못합니다.

nohmad의 이미지

creativeidler님과 대립하는 입장을 가지신 분들은 현재의 웹개발이 어떻게 이루어지고 있고 또 어떤 식으로 흘러갈 것인가에 대해 다른 생각을 가지고 계신 것 같습니다. 저는 creativeidler님의 견해에 대부분 동의하며, 현재의 웹개발은 이미 모든 프레임웍들이 다 갖추어져 있고, 개발자는 (프레임웍에 익숙하다면) 당장 투입되서 비즈니스 로직만 구현해주면 끝나게 되어 있습니다. 심지어 알고리듬 따위는 '그래도 알면 좋은' 수준도 아니고, '알아봤자 쓸데나 있나?' 하는 수준이라고 생각합니다.

이런 현실을 개탄하는 분들도 있으시겠지만, 어떤 종류의 프로그래머에게는 고전적인 전산 커리큘럼과는 다른 종류의 전문성이 현실적으로 요구되고 있고, 그 요구를 기존의 전산학이 해소할 수 있느냐 아니냐는 또 다른 문제일 것입니다. 화려한 개인기로 알고리듬을 구현하는 것보다는 좋은 팀웍을 유지하기 위해 읽기 좋은 코드를 만들어내고, 패턴화된 방식으로 자기 코드의 밑그림을 제시할 수 있는 사람이 이 분야에서는 훨씬 환영받는다고 할 수 있습니다.

cocas의 이미지

creativeidler wrote:

근거로 말한다면 제가 보기에 님을 포함해서 알고리즘이 기초라고 주장하는 사람들이 "기초가 프로그래밍에서 중요한 이유"는 말하고 있지만 "알고리즘이 왜 프로그래밍의 기초인지"에 대해서는 말하고 있지 않습니다. 그에 비하면 "알고리즘을 사용하지 않는다"는 알고리즘이 프로그래밍의 기초가 아니라는데 대한 충분한 근거가 되지 않나요?

어떤 프로그램이건간에 먼저 문제를 정의하고 문제를 해결하기 위한 절차와 객체를 잘 정의한 다음에 코딩으로 들어가는 대강의 순서를 갖고 있다고 알고 있습니다. 또한 잘 정의된 절차와 객체를 알고리즘이라고 하는 걸로 알고 있고요. 정녕 알고리즘을 사용하지 않고 프로그래밍을 할 수 있는건가요?

알고리즘을 정말 알고리즘 교과서에나 나올법한 수학적으로 엄밀하게 증명된 알고리즘만 논한다고 생각해도 '알고리즘은 프로그래밍의 기초가 아니다' 라고 생각하지 않습니다. 수학이란 과목은 여러가지 형태와 이름으로 초등학교때부터 배워 왔습니다. 지금 생각해보면 앞으로 크게 진로를 바꾸지 않는 이상 고등학교 이상의 수학은 전혀 쓸 일이 없습니다. 혹여 있더라도 다른 사람에게 물어보거나 계산기로 처리하거나 하는 정도로 처리할 수 있는 정도입니다. 하지만 전 그동안 배운 수학이 무의미하다고 생각하지 않습니다. 유형의 형태로 제시할 수는 없지만 수학을 배우는 과정 속에서 여러가지 능력을 향상시킬 수 있었고 이 능력들은 충분히 제게 도움이 되었습니다.

기초라는 것은 당장 쓰이는 형태로만 보이는 게 아니라고 생각합니다. 당장 쓰이는 것만 필요하다면 전 제 전공인 CS를 함에 있어서 물리, 화학, 생물같은 과목들은 전혀 쓸모가 없다고 할 수 있습니다. 많은 CS 학과에서 배우는 이산수학 역시 SI를 함에 있어서 전혀 쓰이지 않네요. 이런 것들이 정말 필요가 없을까요?

알고리즘 전혀 모르고 좋은 코드를 만드는 사람은 알고리즘도 금방 익힙니다. 알고리즘을 제대로 배우고 사용하는 사람은 금방 좋은 코드를 작성하게 됩니다. 경험은 미천하지만 제 경험으로는 그러했습니다.

khris의 이미지

nohmad wrote:
화려한 개인기로 알고리듬을 구현하는 것보다는 좋은 팀웍을 유지하기 위해 읽기 좋은 코드를 만들어내고, 패턴화된 방식으로 자기 코드의 밑그림을 제시할 수 있는 사람이 이 분야에서는 훨씬 환영받는다고 할 수 있습니다.

저도 비슷한 생각입니다.
제한된 시스템에서 극한의 퍼포먼스를 뽑아내야하는 프로그래밍이라면 입장이 다르겠지만,
하이레벨중에서도 정말 하이레벨인 프로그래밍쪽들은 굳이 알고리즘이라던가 컴퓨터의 메모리가 어떻게 돌아가는지 신경쓰기보다는 유저 인터페이스나 팀 개발을 위한 "예쁘고 보기좋은" 소스를 짜는데 신경을 써야한다고 생각합니다.
특히나 웹 프로그래밍쪽은 개발 언어등이나 기타 환경들이 굳이 알고리즘을 머리싸매고 공부하지 않아도 될 만큼 받쳐주고 있습니다. 오히려 미관에 더 신경을 써야하겠죠.

───────────────────────
yaourt -S gothick elegant
khris'log

blueruin의 이미지

creativeidler wrote:
알고리즘 미리 안다고 '좋은 코드'를 만들까요? 천만에 말씀입니다.

creativeidler 님은 전반적으로 극단적인 표현을 많이 사용하시네요. 그게 이 쓰레드가 길어지는 이유인것 같습니다.

알고리즘 많이 안다고 반드시 좋은코드를 만들어내지는 않습니다.
다만 알고리즘을 많이 알고있는 사람이 좀더 논리적으로 생각할 수 있고 그래서 좀더 좋은 코드를 만들어낼 수 있다.
(수정:혹시 이문장이 인용될까 첨부합니다. 그렇다는게 아니라 그럴 수 있다는 것입니다. :!: )
이것이 아마 다른분들의 요점이 아닌가 싶습니다.

그리고 위에 다른분께서 화성법을 비유하셨는데 전 나름대로 적절한 비유라고 생각합니다.
음악? 화성법몰라도 좋은 곡 만들어내는 사람도 많습니다.
오히려 몇몇 음악인들은 화성법은 오히려 창작활동에 방해가 될 수 있다고 주장하곤 합니다. (그 음악인들의 논리가 creativeidler 님과 비슷하다고 할 수 있습니다.)
하지만 흔히 말하는 "좋은 곡"들은 대부분 기본부터 충실히 닦아 나간 사람들이 만들어냅니다.

다음은 "곱셈" 알고리즘에 대해서 모르는 사람과 아는 사람의 코드입니다.

/* 100명이 1000원짜리 물건을 샀을때 총 매출액을 출력하라 */

int people = 100;
int price = 1000;

A 의 코드 :
for(i=0;i<people;i++) total_price += price; printf("%d",total_price);

B 의 코드 :
printf("%d",people*price);

예가 너무 한가요? 하지만 실제로 이런 식으로 만드는 사람들이 아주 많습니다.
이때 A는 자신의 코드도 불편함이 전혀 없다고 말합니다.

좀더 다른경우를 하나 예를 들어볼까요?
가벼운 엑세스가 아주 많은 서버/클라이언트환경에서 간단한 암호화가 필요해서 직접 암호화/복호화 루틴을 만들어야 하는 경우, RSA/DES/DSA 혹은 Euclid, Rijndael 알고리즘등을 대충이라도 이해하는 사람은 좀더 빠르고 깔끔하게 구현할 수 있을것입니다.
물론 이런거 몰라도 자신만의 알고리즘을 사용해도 되지만 이건 저 위에 A와 B코드의 예정도가 되지 않을까요?
그냥 라이브러리 갖다 붙이겠습니다.. 라고 하면 할말없습니다. :cry:

알고리즘이란 모를때는 그 위력을 알 수 없는 것입니다.
일단 문제가 해결되면 다시 연구하지 않고 자신이 했던 방법을 재사용하는 경우가 많기때문에 문제의 유무조차 인지하지 못하는 경우가 많습니다.
이런걸 막기 위해 이런 이런게 있구나. 라고 알아두는것이 필요하다고 주장했던것입니다.

많은 학생들이 중/고등학교 수학시간에 투덜거립니다.
이딴거 몰라도 살아가는데 지장없는데 왜 배우지... 라고
하지만 그것들은 살아가면서 응용이라는 이름으로 적지않은 도움을 줍니다.
성과가 눈에 직접 보이지 않고 없어도 될것 같고등의 이유로 무시될만한 성격은 아니라고 생각합니다.
또 이런생각을 뱃지달고계신 높은분들이 하게되어 교육의 개선으로 연결될까 주제넘은 걱정도 됩니다.
안그래도 기초과학이 버려지는 마당에 나름대로 공학도라면 최소한의 것은 하는것이 자기를 위한것 아닐까요?

모든 프로그래머가 기초적인 이론에 박식할 필요는 없습니다.
말씀대로 박식한 프로그래머가 반드시 좋은 코드 짜내라는 법 없고요.
자신이 일하는 쪽에 알고리즘같은게 필요하지 않다면 안배워도 그만입니다.
혹시 필요하다면 아는 사람을 불러오면 되니깐요.
자기가 어떤 프로그래머가 될건지는 자신이 결정할 문제겠지요.

그냥 개인적으로는 일단 한번 관심갖아보고 필요없으면 그때 버려도 시간낭비는 아니라는 것입니다.

time to wait...

NeoTuring의 이미지

creativeidler wrote:
네오튜링님과 제 생각의 차이는 '무엇이 기초인가'의 차이이지 '기초가 필요한가 아닌가'의 차이가 아닙니다. 화성법의 예는 조금 잘못 드신 것 같군요.

무엇이 기초가 되든 프로그램을 "잘"만들기 위해서 기초가 필요하다는 사실에는 변함이 없다는것입니다. SI분야에서 나름대로 검증된 재사용성이 높은 코드가 있으며 이것을 잘 이해하고 또 많이 알고 있는 사람이 SI분야에서 생산성이 높고, 고품질의 코드를 만들 확률이 높다는거죠. 그리고 '기초'라는것은 다른게 아니라 이런 능력을 더 잘 사용할 수 있도록 하는 개인의 기본 소양을 얘기하는겁니다. 이건 너무 당연한 얘기 아닌가요? 이런면에서 화성법을 더 잘 아는 사람이 작곡도 잘 하게 된다는것이 부적절한 비유는 아니라고 생각합니다.

creativeidler wrote:

그리고, 실제로 그런 알고리즘의 예를 단 하나만이라도 들어주실 수 있겠습니까? 엔터프라이즈에서 미리 알지 못하면 빙빙 둘러가서 한참 걸릴 만한 그런 알고리즘 말입니다.

글쎄요. SI분야는 대부분 유지보수성에 초점을 맞추다보니(모두가 그렇다는것이 아닙니다) 아무래도 컴퓨터가 실행하는 부분을 최적화하는것보다는 사람이 코드를 읽기에 편하게 하는것이 더 관습화되어 있는걸로 보입니다. 또 그렇게 해도 요새는 워낙에 컴퓨터 사양이 좋아지다 보니 약간 엉성하게 코딩을 해도 그 부분이 성능의 제약조건으로 크리티컬하게 걸리지 않습니다. 설령 성능상 제약이 걸린다 하더라도 그 부분을 좀 더 효율적인 코드로 대체하여 성능을 끌어올리는 방법보다는 좀 더 높은 사양의 컴퓨터로 대체해서 소프트웨어의 비효율성을 커버하겠다는 마인드가 강한것으로 보입니다.(적어도 제가 볼때는 그렇습니다.) 제가 현재 현업에 종사하지 않고 있기 때문에 구체적인 예를 들긴 뭐합니다만, 확실히 SI분야에서 비효율이 개입된 코드가 남발되는것(그러나 그 부분이 성능상 무시할 수 있는 정도)은 어느정도 공공연하게 인정되는 사실이 아닌가 합니다.

creativeidler wrote:

알고리즘을 모른다고해서 '돌아가기만 하는 프로그램'을 만든다고는 생각지 마시기 바랍니다. 오히려 전 알고리즘이나 패턴 때문에 냄새 나는 코드를 만드는 사람을 더 많이 봐왔습니다. 프로그램 디자인의 원칙들만 잘 지키면 알고리즘이니 디자인 패턴이니 하나도 몰라도 만들다보면 결과물이 자연스럽게 알고리즘의 틀이나 패턴의 형식으로 갖춰지면서 자연스럽게 좋은 코드를 만들어나갈 수 있습니다. 전 거의 처음부터 '좋은 코드'를 만드는 것이 중요하지 지식이 중요한 게 아니라는 말을 했습니다. 알고리즘 미리 안다고 '좋은 코드'를 만들까요? 천만에 말씀입니다.

접근방식이 저와는 전혀 다른것 같습니다. 이 부분은 대화가 통하지 않을것 같군요. 저는 철저히 top-down approach를 지지하는 formalist입니다. 경험적으로 접근하는 애자일과는 정 반대노선을 걷고 있습니다.

creativeidler wrote:

근거로 말한다면 제가 보기에 님을 포함해서 알고리즘이 기초라고 주장하는 사람들이 "기초가 프로그래밍에서 중요한 이유"는 말하고 있지만 "알고리즘이 왜 프로그래밍의 기초인지"에 대해서는 말하고 있지 않습니다. 그에 비하면 "알고리즘을 사용하지 않는다"는 알고리즘이 프로그래밍의 기초가 아니라는데 대한 충분한 근거가 되지 않나요?

리팩토링을 왜 하시나요? 나쁜냄새를 제거하기 위함입니다. 나쁜냄새를 제거하는것은 같은 코드의 중복을 방지합니다. 디자인관점에서 나쁜냄새가 제거된 코드는 런타임에서 좀 더 효율적인 코드로 나타날 확률이 높습니다. 잘 정의된 알고리즘은 이런 나쁜냄새를 미리 제거해서 최적의 해법을 제시해주는것과 기본적으로 같습니다. 잘 정의된 알고리즘을 사용하라고 권장하는것은 근본적으로 애자일 진영에서 리팩토링을 권장하는것과 다를것이 전혀 없습니다. 결국 품질 좋은 코드를 사용하라는 기본 취지는 같기 때문입니다. 리팩토링이 극도로 많이 반복되어 더 이상의 코드 중복이 없으며 또한 다른곳에서 많이 재사용되는 코드의 시퀀스를 따로 모아놓으면 그것이 바로 잘 정의된 알고리즘이 됩니다. 애자일 접근의 문제점(나름의 특성이 되겠군요)이라면 바로 그 부분입니다. 애자일 접근방식은 try & error를 통해 시간이 한참 지난 뒤 최선의 알고리즘을 자연스럽게 택하게 합니다. 하지만, formal한 접근법은 문제를 공학적으로 접근해서 처음부터 최적의 솔루션을 선택하게 합니다. 전자는 인간에게 보다 친숙하고, 후자는 기계에 좀 더 친숙한 방식입니다. 어떤 방식을 택하든 그것은 프로젝트의 규모나 특성에 따라 달리 할 일이겠지만, 공학적 관점에서 더 완성도가 높은 코드는 아무래도 후자라는것을 인정할 수 밖에 없습니다.

제가 여기서 무조건 후자의 방식으로 프로그램을 작성해야 한다는것을 주장하려는게 아닙니다. 필요한 개발 방식은 취사선택하는겁니다. 하지만, 여기서 확실하게 짚고 넘어가야 할것이 있다면 전자의 접근방식이 "최적"을 지향하는 공학과는 그 방향이 완전히 다르다는것입니다. 학생때 책에서 배우는 알고리즘은 분명히 후자에 초점이 맞춰져 있는 해법입니다. 따라서 이런 기본 특성을 이해한다면 이 맥락에서 나쁜냄새니 어쩌니 하는 전혀 다른 접근법의 얘기를 하실 필요가 없습니다. 알고리즘을 사용하는 이유는 디자인 패턴을 사용하는 이유와 같습니다. 기초가 되는 알고리즘을 익힐 필요가 없다고 한다면 패턴을 익히는것도 불필요하다고 주장하실듯 합니다. 만약 그렇다면 더 이상의 논의는 불가능할것 같습니다. 저와 접근방법이 전혀 다르기 때문입니다.

galien의 이미지

재미도 없는 쓰레드가 자유게시판에서 쓸데없이 자라고 있군요.

잠금 한표 추가합니다.

yglee의 이미지

뎃글들을 쭉~ 읽어보니 문득 이런 생각이 듭니다.

Quote:
리눅스 사용자들은 커널컴파일 or 소스컴파일을 의무적으로 할 줄 알아야 되는구나.

인문학 전공자에게 미적분 문제 물어보고

"에잇, 대학생이 미적분도 몰라?"

라고 말하는 것 같습니다.

사람은 know-how가 아니라 know-where를 할 줄 알면되지 않을까요?

stmaestro의 이미지

으으으~~ 갑자기 왠 알고리즘......

뭐 후속으로.
제가 그 친구덕에 몇몇 보안 관련 문서를 보고 있는데.
아주 괘씸하단 생각이 들더라고요,
보안문제라는게..
웜이나 백도어 해킹 프로그램 등등....
웹프로그래밍을 능숙하게 다룬다면...
쉽게 이해했어야 할 문제였더라고요.

이미 웜에 대한 경로라는지.
네트웍 관련된 보안관련 문제라든지 말이죠.
이런 문제는 오히려 잘 이해하고 있었어야 하는데...

왜 이걸 모르고 있었나 경악스럽더라고요,

그렇다면 이런것도 모르고 있었나..
문젠 그 친구는 정말 아무것도 모르고 있더군요.

그 컴퓨터
일단 증상을 보니 블래스터웜과 백도어 해킹프로그램까지.
컴퓨터가 바이러스 온상이더군요.

에휴.. 또 부릅니다.
이젠 돈받을까 라는 생각도 듭니다.

실컷 sms로 관련 정보를 보내줘도.
자긴 보안에 대해선 아무것도 모른다고 하고...

chadr의 이미지

creativeidler wrote:
님이 드신 AI의 예는 알고리즘을 알면 좋은 경우의 예는 될 수 있으나 '알고리즘이 프로그래밍의 기초인 이유'는 되지 못합니다. 특수한 상황이니까요. 그런 예로 말한다면 소켓 프로그래밍을 해본 사람과 안해본 사람이 같이 채팅 프로그램을 만든다면 당연히 소켓 프로그래밍 해본 사람이 더 빨리 만들 것입니다. 그러나, 그렇다고 소켓 프로그래밍이 프로그래밍의 기초라고 말할 수는 없지 않겠습니까?

저와 기초를 구분하는 방식이 다르신 모양이군요..

하이레벨의 구조적인 측면에서 알고리즘과 상세 구현에 대한 구체적인 지식은 없어서 상관 없다는 이야기에는 동의 합니다..
있는거 가져다 써야지 만들어 쓸 필요는 없을테니까요..
웹프로그래밍에서 그런거 일일이 신경 쓰기보다는 UI에 신경을 쓰는것이 더 고객들이 좋아할테니까요. 속이야 어떻든 겉으로 잘만 보이면 고객들은 OK를 할테니까요.

그런데 제가 기반으로 깔고 있는 생각은 프로그래머라는 직업을 달고 언제까지나 하이레벨만으로는 먹고 살기가 힘들기에..-_-
상대적으로 인력이 적은 미들레벨(?) 정도의 지식을 가지고 있으면 좋다는 이야기입니다.

저는 주로 게임을 개발하는지라 소켓프로그래밍과 AI는 거의 필수라서 배울때부터 "이건 기초야!!" 라고 하면서 배웠습니다.

뭐 대학교 레포트 수준의 프로그래밍이라면 소켓 프로그래밍과 AI와 같은 어떤 특정분야에서는 기초중에 기초라고 여겨지는것은 구현 할 일이 없으니까 기초가 아니겠습니다만..

하지만 버블소트를 아는 사람과 10분만에 배운사람중 아는 사람이 10분 더 빨리 만들수 있다는 말에는 동의를 못하겠군요-_-

버블소트 자체에서가 아니라 알고리즘의 측면에서 시스템이 복잡하면 복잡할 수록 10분이 아닌 하루가 걸릴수 있고 일주일이 걸릴수 있으니까요.(코딩보다는 설계가 이렇게 오래걸리지요)

여튼 알고리즘이 기초가 아니다 라는 말씀에 대해서는 웹프로그래밍과 같은 하이레벨의 상황에서는 동의가 가능하나 만약 다른 레벨의 상황에서도 기초가 아니다라고 생각하신다면 그것에 대해서는 좀처럼 동의를 할 수가 없습니다.

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

hackexpert의 이미지

쭉.. 내용을 보면
creativeidler님이 말씀하시고자 하는 바는

"알고리즘이 필요없다" 가 아니라

"흔히 기초라고 말하는 알고리즘을 몰라도 프로그램을 잘 짤 수 잇다."

가 요지 인 것 같습니다.

여기에 반박이 될만한 근거는 이 쓰레드에서 아직 못 본 것 같습니다.

알고리즘을 알면 더 좋다.. 등등의 의견은 많지만
기초적인 알고리즘을 모르면 프로그램을 잘 짜지 못한다는 주장은 없는 것 같네요.

아.. 한가지 더.. 여기서 알고리즘에 대한 의미가
쓰레드 내에서 참 다양하게 쓰인 것 같은데 정리해야 할 것 같습니다.
creativeidler님이 말씀하시는 알고리즘은
큰 범위의 의미인 잘 정의되어 있는 논리적인 흐름을 의미하는 것이 아니고,
학교등에서 배우는 지식에 가까운 알고리즘을 의미하는 것 같습니다. ( 맞나요? ㅡㅡㅋ )

누군가의 의견에 반박을 할 때는 상대방의 언어로 단어를 해석해야 하지 않을까요?

atie의 이미지

글쓰신 분이 "나는 아는데 너는 모르냐"라고 시작한 글이 재미있게 진행되는 군요. (양편 주장이 모두 일리있는 내용이라 끼워들고 싶지는 않군요.)

아마도 그 웹프로그래머라는 친구분의 집에 있는 PC를 말하는 듯한데, 술 사라고 하세요.

PS. 내 PC, 남 시스템, 네트웍, 웹 서버, 프로그램 언어, 내 코드, 데이타베이스, 시스템 설정, 해킹, 바이러스 등등 보안을 가르칠 수 있는 사람이 있을까요? 단편의 지식을 스스로 모으고 모아서 네트웍에 연결된 내 PC를 망치지 않는게 보안의 첫 걸음이라고 누가 이야기 한다고 해도 가르쳐야 할 게 너무 많네요.

----
I paint objects as I think them, not as I see them.
atie's minipage

byung82의 이미지

알아야 하는 분야이기는 하지만 자세히는 몰라도 상관없다고 생각이 듭니다.

보안의 중요성은 굳이 여러사람이 애기 하지 않아도 중요하지만 직접 격어 보기 전까지는 한귀로 들리고 한귀로 나갑니다 .

한번 당하고 나면 직접 찾아서 보기도 할테구 컨설팅 회사도 많으니 그쪽에 맡겨서 해결하는게 더 좋다고 생각이 듭니다.

자기 PC에 윔이 많이 깔려있다고 해도 실질적이 피해 예전처럼 악성 바이러스들이 잘 안보이지만 시스템을 포멧을 해서 날려버린다는지 .

기타 등등 실질적인 피해를 입기 전에는 아 조금느려졌구나 하는 느낌 정도로는 그 문제 해결을 할려고 직접 시스템 분석하지는 않을거라 생각이 듭니다.

일단은 보안의식을 강화 시켜주시고 몰래 살짝 하드 포멧바이러스를심어서 날려버리세요.

그러면 그 다음부터는 알아서 보안에 관련된 자료 윈도라면 백신을 까실테구 유닉스/리눅스라면 보안관련 사이트를 더 많이 보시게 되겠죠

k2hyun의 이미지

gnoyel wrote:

사람은 know-how가 아니라 know-where를 할 줄 알면되지 않을까요?

동의합니다.

인터넷(특히 웹)의 비약적인 발전으로 know-how 보다는
know-where
즉,
how-search
what-use
가 개인 능력의 일부분이 되는 것 같습니다.

더 이상 없다.

khris의 이미지

웹 프로그램은 언제나 노출되어있는 가련한 어린양인지라...
좋은 미스릴 우리를 만들어줘야죠 :)
그러기에 보안에 대한 경각심이 필요합니다.
경각심이 없는 상태에서 백날 보안 배우고 기술 습득해봤자 소용없습니다.
필요없다고 생각하면 안쓰기 마련이니까요.

일례로... 지금 이름/주민번호등의 각종정보가 약 1200건 노출되어있는 허술한 사이트가 있습니다.
자기 귀찮다고 약간만 삐끗해버리면 1200명의 사기용 온라인게임계정이 만들어지는셈이지요.
"에이 뭐 설마 내가 만든데에 그런짓 하겠어" 할때 나쁜놈들은 그런짓을 해버립니다.

근데 저도.... 덜렁대는 편이라 지금 만드는 게시판이 개판이군요. :oops:

───────────────────────
yaourt -S gothick elegant
khris'log

stmaestro의 이미지

byung82 wrote:
알아야 하는 분야이기는 하지만 자세히는 몰라도 상관없다고 생각이 듭니다.

아.. 예. 저도 자세히는 알필욘 없다고 생각합니다.

단지. 그래도 최소한은 알아둬야죠.

최소한 ms에서 제공해주는 보안패치 받을 줄은 알고.
웜에 걸려도 자기가 해결은 할 줄 알아야겠죠.
그리고 간단한 네트웍기술도요.
ip주소 본다던가...
등의 최소한이요.

이친구는 서비스팩조차도 받을 줄 모르고 있으니. 쩝...
게다가 알고보니 그게 다 웹프로그래밍 관련 항목으로도
되더라고요... 이걸 알았을땐 얼마나 괘씸하게 보였는지.

그러니 '제'가 이 고생이죠.

아까
IE를 아예 못쓰고 있다는 연락 들어왔습니다.

이제서야.. 보안에 돈 아끼지 말라는 제 충고를
고이 듣겠다고 하고 V3사러 나간다고 하더군요. 흑...

byung82 wrote:
일단은 보안의식을 강화 시켜주시고 몰래 살짝 하드 포멧바이러스를심어서 날려버리세요.

그러면 그 다음부터는 알아서 보안에 관련된 자료 윈도라면 백신을 까실테구 유닉스/리눅스라면 보안관련 사이트를 더 많이 보시게 되겠죠

예. 적어도..
자기 컴퓨터 하난 지키거나. 구멍이 뚫리더라도..
대처는 할 수 있어야겠죠. 흑흑..

atie wrote:

PS. 내 PC, 남 시스템, 네트웍, 웹 서버, 프로그램 언어, 내 코드, 데이타베이스, 시스템 설정, 해킹, 바이러스 등등 보안을 가르칠 수 있는 사람이 있을까요? 단편의 지식을 스스로 모으고 모아서 네트웍에 연결된 내 PC를 망치지 않는게 보안의 첫 걸음이라고 누가 이야기 한다고 해도 가르쳐야 할 게 너무 많네요.
creativeidler의 이미지

이제 제 뜻이 어느 정도 전달이 되가는 것 같으네요.

참고삼아 제가 올해 1월호 마소에 기고했던 글을 링크합니다.

http://youngrok.com/wiki/wiki.php/자바웹프로그래머의기본

위키니까 의견 있으신 분들은 의견 적어주시면 감사하겠습니다. ^^

NeoTuring의 이미지

hackexpert wrote:
쭉.. 내용을 보면
creativeidler님이 말씀하시고자 하는 바는

"알고리즘이 필요없다" 가 아니라

"흔히 기초라고 말하는 알고리즘을 몰라도 프로그램을 잘 짤 수 잇다."

가 요지 인 것 같습니다.

여기에 반박이 될만한 근거는 이 쓰레드에서 아직 못 본 것 같습니다.

알고리즘을 알면 더 좋다.. 등등의 의견은 많지만
기초적인 알고리즘을 모르면 프로그램을 잘 짜지 못한다는 주장은 없는 것 같네요.


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

그리고 모든 지식은 메타수준의 지식이 더 중요합니다. 저는 알고리즘에 대한 구체적인 지식의 중요성을 강조하는게 아니라 어떤 알고리즘들이 있으며 어느때 어떤 용도로 사용하면 적합한지 또 각각의 특성은 어떠한지 등등을 대략적으로 알고 있는것이 알고리즘의 세부사항을 아는것보다 중요하며 바로 그런 지식을 얻기 위해서라도 알고리즘을 익힐 필요가 있다고 보는겁니다. 한번 배운 지식이 오래지나면 구체사항이 제거되고 기본 뼈대와 추상화된 특성들만 머릿속에 남게 됩니다. 이럴때 필요한 살점은 참고서적을 레퍼런스해가면서 보충하면 되는거죠. 저는 이러한 메타지식을 '기초'라고 생각합니다. 그리고 알고리즘에 대한 메타지식은 그런 기초사항들중 하나를 이루는 중요한 항목입니다. 또 이런 메타지식조차 없는 사람은 프로그램을 만드는데 있어 그 사항을 익힌 사람과 차이가 날 수 밖에 없습니다.

현실적으로 버블소트가 어떻게 동작하고, LR파싱이 어떤방식으로 수행되고 하는 세부사항을 전부 알아야 할 필요가 없습니다. 또 실제로 그런 알고리즘의 세부사항들을 전부 꿰고 있는 사람도 드뭅니다. 필요할때 빠르게 부족한 살점을 채워넣을 수 있는 능력만 있으면 되는겁니다. 그렇게 하려면 기본 뼈대가 있어야 하는데 이것조차 필요없다고 한다면 아마 try & error 를 통해 삽질해서 본인이 책에 나온 알고리즘에 근접한것을 발견해내던지 아니면 좋지 않은 알고리즘을 써두고 그냥 그 수준에서 만족하든지 둘 중 하나의 선택을 할 수 밖에 없습니다. 아마 creativeidler 님은 후자의 입장인것 같고, 그것이 성능의 제약으로 크게 걸리지 않는한 전혀 문제가 없다는 의견인것 같습니다. 프로그램을 만드는데 요구되는 충분조건을 배제한 필요조건만 강조한 의견이죠. 프로그램을 "잘"만드는것은 그정도로는 부족하거든요. 물론 creativeidler 님이 그런 요구조건을 고려하지 않고 있다면 할말이 없습니다. creativeidler님의 생각이 그렇다면 그냥 그 수준에서 만족하는 수 밖에요.

creativeidler의 이미지

음..끝난 줄 알았는데..아니었나보군요-_-

네오튜링님, 거듭 말씀드리지만 제 주장은 '기초가 중요하지 않다'가 아니라 '알고리즘은 프로그래밍의 기초가 아니다'입니다. 화성법 비유는 기초의 중요성을 말하기에는 적절한 예이지만 '왜 알고리즘이 프로그래밍의 기초인지'를 설명하진 못합니다.

offree의 이미지

끼어 들고 싶지는 않지만..

서로의 주장이 많이 엇갈리고 있는 듯 합니다.

토론이 정상적으로 되려면, 알고리즘이 무엇인가에 대한 것부터 해야 할 듯 합니다.

주장하시는 분들이 한걸음씩 물러서서 보시면 바로 해결될 문제 같네요.

기초가 중요하다는 것은 서로 동의하시는 것 같네요.

제 경우를 말씀드리면, 프로그래밍을 처음할때 알고리즘이니 뭐니 부터 배우지는 않았던 것 같습니다.(정상적인 과정인지는 모르겠지만..)
다만, 내가 하고자 하는 것을 프로그래밍으로 표현하는 것을 배웠던 것 같습니다.
실제로 그것이 알고리즘일 수도 있고, 아닐수도 있겠지요.(논리적인 사고가 알고리즘의 범주에 속하느냐 아니냐에 따라 달라지겠죠.)

단순히 교과서에 "알고리즘" 이라고 나오는 것이 정석이 될 수도 있고, 아닐수도 있다고 생각이 됩니다.

그 정석을 잘 알고 있다고 해서, 프로그램을 잘 할 수도 있고, 아닐수도 있구요.

요즘 많이 나오는 패턴, 프레임웍 같은경우도 그런 알고리즘의 범주에 들어갈 수도 있을지도 모르겠습니다.

라이브러리, 패턴, 프레임웍 등 프로그래밍이 발전하면서, 그런 교과서에 나오는, 혹은 나왔던 것들이 대부분 포함이 되었다고 생각이 됩니다.
그렇게 되면서, 소팅이라는 것이 어떤역할을 한다 정도만 알아도(굳이 내부적인 것을 몰라도) 프로그래밍을 할 수 있는 상황이 되었습니다.
그 정도는 앞으로 더 심해질 것 같구요.(실제로도 그렇죠?)

서로의 생각들을 정리하셔도 될 듯 합니다. 더 이상의 발전적인 토론은 어려울 듯 하네요. ^^

새해 복 많이 받으시구요.

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

cocas의 이미지

creativeidler wrote:
음..끝난 줄 알았는데..아니었나보군요-_-

네오튜링님, 거듭 말씀드리지만 제 주장은 '기초가 중요하지 않다'가 아니라 '알고리즘은 프로그래밍의 기초가 아니다'입니다. 화성법 비유는 기초의 중요성을 말하기에는 적절한 예이지만 '왜 알고리즘이 프로그래밍의 기초인지'를 설명하진 못합니다.

알고리즘을 체계적으로 배우고 훈련을 쌓은 사람이 비지니스 로직, 웹 로직도 더 빠르고 잘 설계할 거라고 추측합니다. 그리고 이런 측면에서 본다면 알고리즘은 충분히 프로그래밍의 기초라고 생각할 수 있습니다. 하지만 이건 순전히 제 생각일 뿐이고 강하게 주장할만한 경험이나 통계적 근거는 없습니다.

이에 대한 createveideler님의 경험과 생각을 듣고 싶습니다.

PS. 배운것을 직접적으로 써먹는 것만 기초라고 생각하지는 않습니다. 학교에서 배운 것을 직장에서, 사회에서 그대로 써먹는 경우가 1%나 될까요?

blueruin의 이미지

creativeidler wrote:
이제 제 뜻이 어느 정도 전달이 되가는 것 같으네요.

참고삼아 제가 올해 1월호 마소에 기고했던 글을 링크합니다.

http://youngrok.com/wiki/wiki.php/%C0%DA%B9%D9%C0%A5%C7%C1%B7%CE%B1%D7%B7%A1%B8%D3%C0%C7%B1%E2%BA%BB

위키니까 의견 있으신 분들은 의견 적어주시면 감사하겠습니다. ^^

서론/결론만 읽어봤습니다.
저글이 creativeidler 님의 글이 라고 믿기어려울정도로 양쪽 주장이 틀리네요.
무언가 논의에 핀트가 맞지 않는군요.
알고리즘의 범위에 대해서 정의할 필요가 있을것 같습니다.

윗글에서 "미분방정식을 풀려면 어느 페이지를 찾아봐야 하는지 알아야 한다" 라는 문장이 있었던것같은데 이 미분역시 "알고리즘" 중의 하나입니다.
"미분의 이해"는 필수로 주장하면서 "알고리즘"의 이해는 전혀필요하지 않다는 주장은 쉽게 납득가지 않습니다.

또 많은 IT계열 표준(스펙)의 바닥엔 그것을 존재케하는 알고리즘이 있는 경우가 많습니다.
즉 표준(스펙)의 이해는 알고리즘의 이해와 일부 뜻을 같이합니다.
하다못해 인코딩/디코딩역시 하나의 알고리즘의 또다른 이름입니다.
md5() 라는 함수를 쓴다고 md5 알고리즘을 꿰뚫고있을 필요는 없지만 이것이 어떻게 hash 된다는것정도는 이해하는것이 md5를 md5답게 사용하는 기본이 되는것입니다.
당연하지만 md5() 함수를 사용하는것만으로도 벌써 md5알고리즘을 사용하는 것입니다.

알고리즘이라는의 범위를 너무 한정하여 정의하시는것 같습니다.

time to wait...

NeoTuring의 이미지

creativeidler wrote:
음..끝난 줄 알았는데..아니었나보군요-_-

네오튜링님, 거듭 말씀드리지만 제 주장은 '기초가 중요하지 않다'가 아니라 '알고리즘은 프로그래밍의 기초가 아니다'입니다. 화성법 비유는 기초의 중요성을 말하기에는 적절한 예이지만 '왜 알고리즘이 프로그래밍의 기초인지'를 설명하진 못합니다.

이만 여기서 그만두겠습니다. 관점이 다른것 같습니다. 제가 볼때 알고리즘은 프로그래밍의 기초입니다. 그리고 "왜 알고리즘이 프로그래밍의 기초"인지는 계산이론을 생각해보시면 잘 이해하실 수 있을걸로 생각합니다. 좀 러프하게 표현하자면 수행되고 있는 프로그램은 UTM이 매순간 주어진 문제를 규칙에 따라 증명하는것과 같고, 효율적인 알고리즘이란 이런 증명수행의 절차를 가능한한 적은 단계로 줄일 수 있는것을 지칭합니다. 이에 따라 전술했듯이 프로그램의 모든 시퀀스는 알고리즘이지만, 어떤 알고리즘이 효율적이냐가 관건이 될뿐입니다. 때문에 어떤 프로그램의 시퀀스가 알고리즘이냐 아니냐는 말 자체가 되질 않습니다. 이것을 염두에 두고 있다면 학교에서 배우는 알고리즘은 "효율적인 알고리즘 목록"을 배우는것이고, 프로그래밍의 기초로 생각하지 못할 이유가 전혀 없다고 봅니다. creativeidler님과는 프로그래밍을 바라다보는 관점도 다르기 때문에 더 이상의 논의가 진행되기 어려울듯합니다. 그냥 여기서 관둘랍니다.

NeoTuring의 이미지

알고리즘에 대한 정의 참고글입니다. (나름대로 정의해서 사용하고 계신것 같지만-현재 논의되고 있는 "알고리즘"은 알고리즘이라는 포괄적 개념의 subset으로 이해하여야 할것입니다-)
그럼 여기서 저는 진짜 끝냅니다. 8)

http://kr.100.yahoo.com/result.html?pk=15827400

http://ko.wikipedia.org/wiki/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98#.EC.95.8C.EA.B3.A0.EB.A6.AC.EC.A6.98.EC.9D.98_.EC.9A.94.EA.B1.B4

http://kr.ks.yahoo.com/service/wiki/wiki_n_view.html?wnum=123842

creativeidler의 이미지

to cocas:
제 경험을 듣고 싶다 하셨는데 솔직히 저의 프로그래밍 경험은 제 주장을 뒷받침하긴 무리가 있습니다. 전 이미 16년 전에 버블 소트를 배웠고 10년 전에 정보올림피아드에 나갔고 제가 읽은 알고리즘 책만 7권입니다. 이런 상황에서 난 알고리즘 안 쓰고 잘 하지 않느냐 해봤자 별 설득력이 없겠죠-_- 그보다 도움이 될만한 이야기는 제가 보아온 사람들에 대한 경험일 것입니다. 이에 대한 이야기를 잠깐 해보자면...

우선, 전 컴공 출신에 대해 어느 정도의 불신을 갖고 있습니다. 제가 보아온 컴공 출신들은 일반적으로 문제를 해결하는 능력은 비전공자에 비해 뛰어납니다. 시스템에 대한 이해도 깊고 자료구조&알고리즘에도 빠삭합니다. 하지만 남이 이해할 수 있는 코드를 만드는 능력은 많이 뒤쳐졌습니다. 대학에 따라 컴공(Computer Engineering)과 전산(Computer Science)이 따로 있는 경우가 있는데 전산 쪽이 더 그런 경향이 심합니다. 분명 어렵고 복잡한 일을 잘 해내지만 그들이 만든 코드는 남들이 유지보수하지 못합니다.
물론 이건 일반론입니다. 1년 전에 만난 직장 동료 하나는 컴공 출신인데 누가봐도 깔끔한 코드를 만들어냈죠.

그런 반면, 전 또 대학 때까지도 프로그래밍에 관심이 없다가 뒤늦게 입문한 사람을 몇 명 알고 있습니다. 그들이 알고리즘에 대해 알고 있을 가능성은 극히 적다고 봅니다. 하지만 그들이 만들어내는 코드는 다른 사람이 읽기 좋은 코드였습니다.

이 차이가 어디에서 왔다고 생각하십니까? 단지 그 사람들의 능력이 다른 것이었을까요? 그렇지 않습니다. 무엇이 중요한지에 대한 시각 차이에서 나온 결과입니다. 근본적으로 전 마틴 파울러의 말, '컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 만들 수 있다. 중요한 것은 사람이 이해할 수 있는 코드를 만드는 것이다.'에 전적으로 동의합니다. 이것이야말로 프로그래밍에서 가장 중요한 것입니다. 하지만 알고리즘은 여기에 전혀 기여하지 못합니다. 알고리즘은 '컴퓨터가 이해하게 만드는 방법'이지 '사람이 이해하게 만드는 방법'은 아니니까요.

전기공학(EE)에도 여러 가지 분야가 있습니다. 에너지공학, 반도체, 디지탈시스템설계, 제어, 통신 등이죠. 미적분학 같은 건 이 모든 분야에 기초가 됩니다. 하지만 전자장은 반도체의 기초이긴 하지만 제어의 기초는 아닙니다. 논리회로는 디지탈시스템설계의 기초이긴 하지만 에너지공학의 기초는 아니죠.

프로그래밍도 이렇습니다. 프로그래밍도 정말 다양한 분야가 있습니다. 같은 웹 프로그래밍을 하더라도 비즈니스로직을 하는 사람에게는 SQL이 기초이고 HTML은 알 필요도 없지만 UI단을 만드는 사람에겐 HTML이 기초이고 SQL이 필요 없는 거죠. 알고리즘도 마찬가지입니다. 게임 프로그래밍이라든지 AI, GIS, DBMS 등 알고리즘이 기초가 되는 분야도 많이 있습니다. 하지만 대부분의 엔터프라이즈 컴퓨팅에서는 알고리즘은 그 용어조차 알 필요가 없습니다.

문제의 발단은 프로그래밍이 전부 같은 것이라고 치부해버린 데서 온 게 아닌가 싶습니다. 특히나 여기 kldp에는 로우레벨을 좋아하는 사람이 많은데 로우레벨을 아는 것이 그 사람이 프로그래머로서 상식이 넓다는 정도는 말해줄 수 있지만 더 좋은 프로그래머라는 보장은 절대 하지 못합니다. 저도 나름대로 최하위 레이어에서부터 최상위 레이어까지 모두 프로그래밍을 해봤지만 어떤 부분이 더 어렵다거나 더 프로그래머의 가치를 높여준다거나 하는 건 없습니다. 단지 분야가 다를 뿐입니다. 레이어의 가치는 하부레이어를, 혹은 상부레이어를 몰라도 자신의 레이어를 충실히 잘 만들 수 있게 한다는 데 있습니다.

학창시절에 배우는 것은 과목별로 다양한 목적이 있습니다. 국어 같은 건 사회의 일원으로서 의사소통하기 위해 필수적인 기초이기 때문에 배우는 것이지만 문학을 배우는 것은 그 사람이 인생을 좀더 풍요롭게 살 수 있게 하기 위한 교양으로서 배우는 것입니다. 수학을 배우는 것은 수학 자체가 인생의 기초라거나 모든 직업의 기초라거나 그래서가 아니고 그것을 배우는 과정에서 사고력과 수학 능력을 키울 수 있기 때문입니다. 수학을 가지고 모든 것의 기초라고 하기는 좀 무리가 있지 않겠습니까. 물론 알면 좋겠지만 말입니다.

알고리즘도 따지자면 수학과 비슷합니다. 알고리즘을 배우는 과정에서 사고력이 늘 수 있고 이런 지식들은 분영 '알아두면 좋은 것'이긴 합니다. 그러나 이것이 '기초'라고 하기는 근거가 약합니다.

그래서 알고리즘 하나 모른다고 기초도 없는 사람인양 비웃는 것이 싫었던 겁니다. 제가 인터넷 게시판에서 제일 싫어하는 것이 부당한 비난입니다. 부당한 비웃음 역시 마찬가지죠. 그래서 모를 수도 있는 것, 그리고 몰라도 별 지장 없는 걸 가지고 비웃는 것을 그냥 보고 지나칠 수 없었습니다.

creativeidler의 이미지

to bluerain
생각해보세요. 마소에 그렇게까지 기초를 중시하는 글을 기고한 사람이 기초가 중요하지 않다고 생각하고 있을 것 같습니까? 찬찬히 제 글을 다시 한 번 읽어보시기 바랍니다.

to NeoTuring
아직도 광의의 알고리즘을 끌어와서 말씀하고자 하십니까? 제가 알고리즘의 정의를 모르는 것 같아보이나요? 제가 볼 때 지금 제 주장에 대해서 이해 못하는 사람은 블루레인님과 네오튜링님두 분 밖에 없는 것 같습니다. 제 의견에 동조하고 아니고를 떠나서 먼저 상대방의 주장에 대해 이해하려는 노력이 있어야하지 않을까요? 님은 특히나 처음부터 한 번 쭉 읽어보실 필요가 있는 것 같습니다.

blueruin의 이미지

creativeidler wrote:
to bluerain
생각해보세요. 마소에 그렇게까지 기초를 중시하는 글을 기고한 사람이 기초가 중요하지 않다고 생각하고 있을 것 같습니까? 찬찬히 제 글을 다시 한 번 읽어보시기 바랍니다.

to NeoTuring
아직도 광의의 알고리즘을 끌어와서 말씀하고자 하십니까? 제가 알고리즘의 정의를 모르는 것 같아보이나요? 제가 볼 때 지금 제 주장에 대해서 이해 못하는 사람은 블루레인님과 네오튜링님두 분 밖에 없는 것 같습니다. 제 의견에 동조하고 아니고를 떠나서 먼저 상대방의 주장에 대해 이해하려는 노력이 있어야하지 않을까요? 님은 특히나 처음부터 한 번 쭉 읽어보실 필요가 있는 것 같습니다.

creativeidler 님의 논지는 충분히 이해했습니다.
"프로그래밍에 있어 알고리즘은 필요없다" 아닌가요?
그리고 부수적으로는 "게시판에 모른다고 무시하는 글을 쓰지말자" 정도가 되는것 같습니다.
반면 신세대에게 무시당하지 않으려면 더욱 열심히 공부해야겠다라는 경각심이 생겼습니다.
시간이 되시면 제 글의 논지를 찍어주시겠습니까?

쓰레드가 주제에 비해 지나치게 길게가는군요.
프로그래밍에 있어 기초가 중요하다 라는 생산적인 결론으로 마무리 짛고 저는 이 쓰레드 지켜보시는 다른분들처럼 빠지겠습니다.
알고리즘의 이해가 프로그래밍에 있어 도움을 주는지 쓰레기인지는 각자의 판단인것 같습니다.

time to wait...

mach의 이미지

stmaestro wrote:

...

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

...

글세요. 제가 보기에는 더 많은 웹프로그래밍하는 사람들은 보안이나 기본을 알것으로 생각되는데요.
단지, 소수 몇몇은 모를 수도 있겠지요. 그러나, 그게 큰 잘못은 아니겠지요.

------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.

NeoTuring의 이미지

creativeidler wrote:

to NeoTuring
아직도 광의의 알고리즘을 끌어와서 말씀하고자 하십니까? 제가 알고리즘의 정의를 모르는 것 같아보이나요? 제가 볼 때 지금 제 주장에 대해서 이해 못하는 사람은 블루레인님과 네오튜링님두 분 밖에 없는 것 같습니다. 제 의견에 동조하고 아니고를 떠나서 먼저 상대방의 주장에 대해 이해하려는 노력이 있어야하지 않을까요? 님은 특히나 처음부터 한 번 쭉 읽어보실 필요가 있는 것 같습니다.

계속 글을 쓰게 되는군요. 이래서는 안되는데 말입니다. :roll: 저는 이미 creativeidler의 의견을 다 이해하고 있었고, 그 상태에서 글을 썼지만 creativeidler님은 제가 의도적으로 광의의 알고리즘개념을 끌어들이고 있다는것을 모르고 계신것 같습니다. 현재 논의되고 있는것도 광의의 알고리즘의 subset이기 때문에 광의의 알고리즘이 가진 특성을 다 갖고 있다고 할 수 있으며 때문에 마치 학교에서 배우는 알고리즘을 광의의 알고리즘과 전혀 별개인것처럼 생각하시는 그러한 생각은 전적으로 부당하다고 지적드리고 싶군요. 이와는 좀 다른 맥락에서 아래 일련의 진술들을 잘 살펴보시기 바랍니다.

1. 프로그램은 개선되어야 한다.
2. 리팩토링 노력을 통해 1을 만족시킬 수 있다.
3. 2를 상당기간동안 많은 case에 반복적으로 적용했을때 재사용될만한 작은 루틴들이 발견되고, 이것이 엄밀하게 검증된 결과가 학교에서 배웠던 "알고리즘"이다.
4. 따라서 학교에서 배웠던 알고리즘의 사용은 수십년간의 리팩토링 경험결과를 거의 공짜로 한번에 사용하는것과 동일하다.
5. 4가 참이라면, 학교에서 배운 알고리즘의 적절한 사용으로 1이 자동으로 충족된다.
6. 따라서 학교에서 배운 알고리즘을 굳이 익힐 필요가 없다고 한다면, 많은 2의 시행착오를 통해 3에 근접한 결과를 달성하려고 하거나(기본 프레임웍을 사용하는 경우일지라도) 그게 아니면 아예 1에 대한 의지가 없는것으로 본다.
7. 6에서 전자의 경우라면 3,4에 의해 "쓸데없는 낭비"를 하는것이다.
8. 6에서 후자의 경우라면 애자일 접근법에서 2를 권장할 이유도 없다.
9. 7은 공학의 관점에서 8은 나쁜냄새를 제거하려는 관점에서 기존의 이론들과 모순된다.

creativeidler님은 6에 따라 7, 8중 하나이거나 혹은 두가지 경우 모두를 취하는것처럼 보입니다. 그러나, 어떤 경우든 creativeidler님의 주장은 기존의 이론들과 모순되어 보이는군요.

creativeidler의 이미지

글쎄요. 제가 보기엔 아직도 모르고 있으신 것 같습니다. 제가 '왜' 글을 쓰고 있다고 생각하십니까? 광의의 알고리즘을 일부러 끌어오셨다면 정말로 off-topic을 끌고 오신 겁니다.

다시 한 번 네오튜링님을 위해 마지막으로 제 주장을 정리해드리죠.

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

이겁니다. 광의의 알고리즘은 전혀 상관이 없다 이겁니다. 이 쓰레드 전체를 걸쳐서 광의의 알고리즘을 말하는 사람인 지금 네오튜링님 한 사람 밖에 없습니다. 그리고 이 쓰레드에 여전히 제 의견에 동조하지 않는 분은 많지만 제가 왜 이런 말을 하는지를 모르는 사람은 네오튜링님 한 분 뿐입니다. 이쯤 되면 이 의사소통의 실패는 제 책임이 아니라고 말해도 괜찮을 것 같은데요.

그리고 님이 번호를 붙인 논리에도 문제가 있습니다. 우선 알고리즘은 리팩토링의 산물이 결코 아닙니다. 광의의 알고리즘은 리팩토링을 하지 않은 것도 알고리즘으로 포함하며 협의의 알고리즘은 그 발전과정이 리팩토링과는 전혀 상관 없습니다. 리팩토링의 목적은 사람이 이해하는 코드이고 협의의 알고리즘의 목적은 최적해를 찾는 것입니다. 따라서 4번 진술은 거짓입니다.

그리고 5번도 XP와는 현격한 입장의 차이가 있습니다. XP에서는 이미 알려진 패턴이나 알고리즘을 먼저 적용하지 않습니다.
http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork
즉 XP의 기본 입장은 네오튜링님의 방식으로 표현한다면 6번의 전자입니다. 그리고 이것은 결코 '낭비'로 간주되지 않으므로 7번 또한 참이 아닙니다.

토론의 목적을 지지 않는데에 두면 서로가 피곤해질 뿐입니다. 네오튜링님은 지금 왜 이 토론을 이어가고 있으신가요? 스스로에게 자문해보셔야할 때가 아닌가 싶습니다.

전 이제 어느 정도 목적을 달성한 것 같습니다. 제 목적은 어디까지나 알고리즘에 대한 무지에 대해 기초 부족이라는 비난과 비웃음이 쏟아지는 것을 막는 것이었고 어쨋든 많은 분들이 제 뜻을 이해해주신 것 같습니다. 네오튜링님도 저에게 동조하진 않으셨지만 남을 비웃거나 할 사람은 아닌 것으로 보이니 전 이제 토론의 목적이 모두 달성되었으므로 이만 물러갈까 합니다.

hackexpert의 이미지

blueruin wrote:

creativeidler 님의 논지는 충분히 이해했습니다.
"프로그래밍에 있어 알고리즘은 필요없다" 아닌가요?
그리고 부수적으로는 "게시판에 모른다고 무시하는 글을 쓰지말자" 정도가 되는것 같습니다.

blueruin wrote:

알고리즘의 이해가 프로그래밍에 있어 도움을 주는지 쓰레기인지는 각자의 판단인것 같습니다.

제가 괜히 끼어드는 것은 아닌지 모르겠지만
전혀 이해가 안되고 있는 상황 같습니다.

Quote:

"프로그래밍에 있어 알고리즘은 필요 없다"
"좋은 프로그램을 만드는데 반드시 알고리즘에 대한 지식이 필요한 것이 아니다"

두가지는 분명히 의미가 다릅니다.

Quote:

"알고리즘의 잘못된 쓰임이 문제가 될 수 있다"
"알고리즘은 쓰레기다"

위 두가지도 마찬가지로 다른 말이지요.

그리고 첨언하자면..
사실 현재 웹프로그래머가 만들어내야할 생산물 가운데에는
딱히 배워야할 알고리즘이 많은 것 같지는 않습니다.
(광의적인 의미가 아닌 xx알고리즘 과 같은 지식을 이야기하는것입니다.)

당장 생각해보죠..
쇼핑몰이나 게시판등의 프로젝트를 진행한다고 하였을 때,
무슨무슨 알고리즘을 배워야 잘 만들 수 있을까요?

저로서는 딱히 생각나는 것이 있지는 않네요..
그 흔하게 쓰인다는 소팅 알고리즘조차 쓰일 곳이 없는 것 같습니다만..

drops02의 이미지

그런건 대부분이 자신이 지금 하는 일에 대한 애착이나 애정이 없는게 아닐까요? 해당 분야만 적당히?처리해주면 다른 것이야 어떻든 관계없는..

그것 말고는 아마도 해당 일을 하는데 필요성을 느꼈기 때문에 지식을 필요로 해서 알게 되는 경우가 있는것 같습니다.

차나 사람이나 컴퓨터나 모든 대부분이 할 수 있다가 아니라 하고싶어져서 하는것과 차이가 있겠죠 아무것도 않하고 싶다면 굶어죽는 수밖에 없을테니.. 돈을 벌어 먹고 살아야 되겠죠? :D

머리는 느려지고 늘어가는건 담배 꽁초 수..

NeoTuring의 이미지

creativeidler wrote:

1. 버블 소트와 같은 협의의 알고리즘은 프로그래밍의 기초가 아니다.

이 진술이 제가 전술했던 전제9를 이끌어 낸다는것이고, 이것들의 기초전제들은 1~8에 주어져 있습니다.(즉, creativeidler님의 이런 주장은 기존의 이론들과 모순된다는겁니다) 이제 이 전제들의 일부를 부정했던 creativeidler 님의 반론을 제가 재반론하면 제 진술이 옳다는것이 다시한번 입증되는셈이겠군요.
creativeidler wrote:

그리고 님이 번호를 붙인 논리에도 문제가 있습니다. 우선 알고리즘은 리팩토링의 산물이 결코 아닙니다. 광의의 알고리즘은 리팩토링을 하지 않은 것도 알고리즘으로 포함하며 협의의 알고리즘은 그 발전과정이 리팩토링과는 전혀 상관 없습니다. 리팩토링의 목적은 사람이 이해하는 코드이고 협의의 알고리즘의 목적은 최적해를 찾는 것입니다. 따라서 4번 진술은 거짓입니다.

광의의 알고리즘이 리팩토링을 하지 않은것도 포함한다는것은 당연한 얘기인데, 제 글을 어떻게 보셨는지 모르겠지만, 바로 그러한 포함관계가 성립된다는것 때문에 협의의 알고리즘이 광의의 알고리즘의 subset이라고 했던겁니다.(이건 너무나 당연한 얘깁니다)

그리고 알고리즘이 리팩토링의 산물이 아니라는것도 거짓입니다. 엄밀한 기하학조차도 각자의 대지 영역을 구분하고 치수작업을 하기 위한 경험이 축적되어 후에 그것이 공리적으로 재구축되어 나온것입니다. 마찬가지로 협의의 알고리즘도 우선 어떤 문제를 풀기 위해 여러가지 시행착오를 거치면서 경험적으로 여러가지 대안적 광의의 알고리즘을 찾다가 이전의 것보다 더 좋다라고 판단되는것을 발견해낸것이 하나의 패턴으로 굳어진것에 불과하지, 그 이상의 어떤것이 있는것은 아닙니다. 물론 이런 "발견"뒤에는 반드시 정당화의 맥락속에서 수학적으로 검증하는 작업이 필요하지만, 그 이전까지는 경험적으로 탐색하는 과정이 필요하며 이것은 많은 시행착오를 통해 얻어질 수 있는 것입니다. 이를 위해 굳이 포퍼의 반증주의까지 끌어들이면 너무 논의가 크게 빗나갈것 같아 이 부분은 자제하겠습니다. 다만, 알고리즘의 수학적 증명 이전에 먼저 경험적 탐색의 바탕이 있어야 할것이며 이것이 바로 리팩토링을 통한 시행착오와 다를것이 없다는것을 기억하셨으면 합니다. 이에 따라 4번 진술이 거짓이라는 반론은 재 반론됩니다.

creativeidler wrote:

그리고 5번도 XP와는 현격한 입장의 차이가 있습니다. XP에서는 이미 알려진 패턴이나 알고리즘을 먼저 적용하지 않습니다.

네 이미 알고 있는 사항입니다. 그래서 처음부터 creativeidler님과 저의 입장차이를 밝히는 글을 쓰려고 했습니다. 현재 저와 creativeidler님이 서 있는 토양이 다른걸로 보입니다. 쉽게 얘기해서 소프트웨어 개발을 공학의 하위 분야로 보느냐 아니면 소설쓰기와 같은것으로 보느냐의 관점차이가 존재하는것 같은데 저는 당연히 공학의 하위로 분류하고 있습니다. 어쨋든 이 부분은 별도의 주제로 논해도 될만큼 울궈먹을게 많고, 이 논의에서 주변부에 머물러 있는 부분이기 때문에 어떤 접근이 옳으냐 그르냐에 대한 논의(별로 생산적일것 같지도 않지만)는 하지 않겠습니다. 다만, 4가 참이라면 2에 의해 1이 자동으로 충족된다는것만을 기억하시기 바랍니다. 4가 참이라는것은 이미 위에서 설명해 드렸습니다. 5전제는 바로 이에 대한 설명입니다. 그리고 5에서 "적절한"이라는 단어를 빼먹지 않으셨으면 합니다.
creativeidler wrote:

즉 XP의 기본 입장은 네오튜링님의 방식으로 표현한다면 6번의 전자입니다. 그리고 이것은 결코 '낭비'로 간주되지 않으므로 7번 또한 참이 아닙니다.

저는 "낭비"라는것을 3, 4의 전제에 의해 뒷받침 했습니다. 낭비로 간주되지 않는다는것을 제대로 반론해주시기 바랍니다. (본인이 그렇게 생각하지 않는다는것과 xp진영에서 그렇게 간주한다는것은 또 다릅니다. 양자를 분리해서 논증해주십시오.)
creativeidler wrote:

토론의 목적을 지지 않는데에 두면 서로가 피곤해질 뿐입니다. 네오튜링님은 지금 왜 이 토론을 이어가고 있으신가요? 스스로에게 자문해보셔야할 때가 아닌가 싶습니다.

지지 않는데에 둔다기 보다는 올바른 개념을 정립하는것을 목적으로 합니다.
blueruin의 이미지

hackexpert wrote:
blueruin wrote:

creativeidler 님의 논지는 충분히 이해했습니다.
"프로그래밍에 있어 알고리즘은 필요없다" 아닌가요?
그리고 부수적으로는 "게시판에 모른다고 무시하는 글을 쓰지말자" 정도가 되는것 같습니다.

blueruin wrote:

알고리즘의 이해가 프로그래밍에 있어 도움을 주는지 쓰레기인지는 각자의 판단인것 같습니다.

제가 괜히 끼어드는 것은 아닌지 모르겠지만
전혀 이해가 안되고 있는 상황 같습니다.

Quote:

"프로그래밍에 있어 알고리즘은 필요 없다"
"좋은 프로그램을 만드는데 반드시 알고리즘에 대한 지식이 필요한 것이 아니다"

두가지는 분명히 의미가 다릅니다.

Quote:

"알고리즘의 잘못된 쓰임이 문제가 될 수 있다"
"알고리즘은 쓰레기다"

위 두가지도 마찬가지로 다른 말이지요.


저의 주장은 "알고리즘이 프로그래밍에 도움을 줄 수 있다" 이고 반대 주장은
"알고리즘은 프로그램에 '전혀' 도움이 안된다" 입니다.
이건 이전글들을 읽어보면 직절설으로 여러번 표현되어있으니 참고하시기 바랍니다.
이 두문장의 차이를 표현그대로 따지지 않고 토씨몇개 바꿔가며 언어측면에서 따지면 말장난밖에 안됩니다.
Quote:

A : 김치만 있어도 밥잘먹어.
B : 이왕이면 국도 있으면 더 잘먹지.
A : 아니야 김치만 있어도 잘 먹는다니깐!
B : :shock:

그리고 남을 무시하는 행위는 어떤경우든 올바르다고 할 수 없습니다.
하지만 프로그래밍교육을 받은 사람이 아주 간단한 알고리즘을 모른다는것은 그만큼 공부를 안했다는것입니다.
학교에서는 알고리즘을 강조하며 시간을 충분히 할애하지 않는 이유는 그것이 중요해서가 아니라 그쪽으로 나갈사람들은 알아서 공부하라는 것입니다. 또 학부같이 범용인재를 가르치는 곳에서 가르칠만한 성격의 것도 아니고요.
학교에서 커널을 만든다던가 실무에 직접 사용할 수 있는 복잡한 프로그램을 만들던가요?
그건 정규과정이 아닌 자신의 능력을 올리기 위해 스스로 하는것들입니다.

아, 그렇다고 제가 이 쓰레드에서 누굴 무시하는듯한 발언은 한적없습니다 :?

hackexpert wrote:

그리고 첨언하자면..
사실 현재 웹프로그래머가 만들어내야할 생산물 가운데에는
딱히 배워야할 알고리즘이 많은 것 같지는 않습니다.
(광의적인 의미가 아닌 xx알고리즘 과 같은 지식을 이야기하는것입니다.)

당장 생각해보죠..
쇼핑몰이나 게시판등의 프로젝트를 진행한다고 하였을 때,
무슨무슨 알고리즘을 배워야 잘 만들 수 있을까요?

저로서는 딱히 생각나는 것이 있지는 않네요..
그 흔하게 쓰인다는 소팅 알고리즘조차 쓰일 곳이 없는 것 같습니다만..

제가 겪었던 일을 하나 쓰겠습니다.
예전에 팀장을 맡고있을때 코더(코딩일을 하는 수습프로그래머)가 새로 들어왔는데 프로그래머와 코더에게 '이부분의 비밀번호는 html form 단에서 암호화시켜 서버로 전송시켜라'라고 했습니다.
저녁에 코드를 봤는데 자바스크립트를 만든 코더는 나름대로 문자열을 지지고 볶아 암호화시키고 프로그래머는 그 방법을 반대로 지지고 볶고있었습니다. 왜 이렇게 했냐니깐 자바스크립트로 암호화하는걸 모르겠답니다.
최소한 그 프로그래머가 md5알고리즘을 알고있었다면 하다못해 "javascript md5" 라는 검색어로 간단하게 해결했을겁니다.
(이경우는 md5라는것이 있다는건 알았지만 그냥 딴나라 세상의 이야기인줄 알고 적용할 생각조차 못했던것입니다. 하지만 대충이라도 알고리즘의 원리를 봤다면 구현해보려고 하던가 검색을 해봤을겁니다.)
이것의 아는것과 모르는것의 차이입니다.
몰라도 프로그램 잘 만들 수 있습니다. 하지만 알면 더 잘 만들 수(possibility) 있습니다.

또 쇼핑몰/게시판에도 분명 '정렬 알고리즘'이 들어갈 수 있습니다.
단순히 생각나는 예로
db에서 데이타를 뽑아와서 출력합니다. 하지만 이걸 한번에 다른 순서로 출력해야한다고 칩시다.
그럼 SELECT * FROM tb ORDER BY idx_a, SELECT * FROM tb ORDER by idx_b 이렇게 두번 쿼리를 주는 사람이 있을것이고 한번 돌려 CGI단에서 처리하는 사람이 있을겁니다.
CGI단에서 처리하기 위해서는 그 상황에 맞는 적절한 코드가 필요한데 여기서 소트알고리즘을 많이 알고있는 사람이 좀더 효율적인 코드를 만들어 낼 가능성! 이 많습니다.
이것도 예로 들라면 상황에 따라 BubbleSort로 10초걸릴것이 RadixSort 로 정렬하면 1초도 안걸릴수 있습니다.
쇼핑몰/게시판에서는 그렇게 큰 배열을 취급하지 않아요.. 라고 하면 역시 할말없습니다.

"소트알고리즘" 이라는 단적인 예가 아닌 알고리즘(광의적이든 편협적이든)전반에 걸치면 꺼리는 더 많아집니다.
복잡한 알고리즘의 내부에는 단순하고 아주 기본적인 알고리즘들을 포함하는 경우가 대부분이라는것을 생각하면 기초적인 알고리즘이라고 무시할 수 는 없는겁니다.
가로 5, 세로 10cm 평면사각형의 넓이를 구하라.. 사각형의 넓이가 w*h 라는 공식을 모르는 사람도 지지고 볶아 답은 구할수는 있을겁니다. 하지만 그 공식을 알고있는 사람은 지지고 볶을 필요가 없습니다.
이 공식이 바로 "알고리즘" 입니다.
아주 기똥찬 알고리즘의 구현을 보고 "와 죽이네" 라고 감탄하고 "이런거야 말로 알고리즘이야" 라고 말할 수도 있습니다.
하지만 그런 '와 죽이네표 알고리즘'을 만들어내는 사람들은 소트같은 기본적인 알고리즘에 충실한 사람들입니다.

몇년동안 눈팅하다 몇몇분들의 눈쌀마저 찌푸리게 만드는 장문의 글을 여러번 포스팅하는 이유는 저역시 올바른 개념의 정립이 목적입니다.
"기본알고리즘은 프로그래밍에 도움이 되지 않는다" 라는 생각이 제게 배우는 학생들에게 전해질까 두려운 마음도 있습니다.
물론 정말 도움이 안된다면 상관없지만 제 지론으로는 그렇지 않다고 생각하기때문에 또 이렇게 글을 남깁니다.

time to wait...

페이지