현업 프로그래머가 되면 알고리즘을 어느 수준까지 알아야 하나요?

yoiyong의 이미지

제가 가지고 있는 알고리즘 관련 책은 The Art of Computer Programming , Introduction to Algorithm, 뇌를 자극하는 알고리즘, c언어로 배우는 알고리즘(?) 이재규저
이렇게 있는데요...
프로그래밍 공부하는데 어느수준까지 현실적으로 알고리즘을 요하는지 알고싶습니다.
알고리즘이 필요한지 그렇다면 어떻게 알고리즘을 공부해 나가야할지요??
제 개인적인 생각으로는 알고리즘이 프로그래밍의 핵심이라고 생각되어지는데....

36311의 이미지

어떤 프로그래머이냐에 따라 다릅니다. 대학 수준의 알고리즘을 전혀 사용하지 않을 수도 있습니다.
책은 버리셔도 될 거 같습니다.

* 포럼 주제와 무관한 신변잡기를 반복해서 올리지 맙시다.
* 질문 게시판 만이라도 익명 글쓰기를 막아야 한다고 생각합니다.

ds5pnz의 이미지

한국의 대다수 프로그래머가 SI 쪽이라고 가정한다면...

(제 주변에 있는 개발자가 거의 웹, 모바일 뿐이네요. ㅠ.ㅠ)

알고리즘 따위는 거의 필요 없습니다.

다만, 12시 퇴근을 야근이라 생각하지 않는 마인드가 필요할 뿐이죠.

오리가날지못해우물에빠진날의 이미지

SI에 있는 저로서는 자료구조, 알고리즘 하나하나가 퇴근시간을 00시에서 18시로 바꿔주더군요.

specialcase의 이미지

저흰 18시에 할꺼 끝내면 0시까지 일할꺼 또 주던데 ㅋㅋ

neocoin의 이미지

00 까지 서핑하는걸 의미하시는듯. :)

feanor의 이미지

Introduction to Algorithms 정도면 실제 쓰는데는 차고 넘치는 것 같습니다.

JuEUS-U의 이미지

Abstract Data Type은 SI에서도 자주 쓰이지 않나 싶네요 'ㅅ')
뭐 라이브러리를 쓰거나 복붙하는게 안정성과 성능면에서 더 유리하지만 말이죠 - ㅅ-)

preisner의 이미지

알고리즘. 많이 보다는 제대로.

rgbi3307의 이미지

쉽게 생각해볼 수 있는 예로, 자동차를 생산하기 위해서 수많은 사람들이 일을 합니다.
1. 엔진
2. 동력전달계
3. 내부 인테리어
4. 타이어
5. 외부 차체 디자인
6. 생산라인 조립
7. 도장
8. 영업
생각나는 것이 이정도라서 적어 봤습니다만,
생산라인에서 조립하는 사람들은
조립 공정에 따라서 제공된 도구를 사용하여 부품들을 맞추고, 조이는 작없을 수없이 반복합니다.
생산라인에 있는 사람들이 자동차 엔진이나 동력전달계 설계에 대해서 신경쓸 수도 있습니다만,
이 엔진은 왜 이모양으로 생겼나? 이 동력축은 왜 이렇게 조립하기 힘든가?
하지만 일일히 신경쓰다보면, 제시간에 자동차를 만들어 내지 못하므로 그냥 조립만 열심히 해야 합니다.

컴퓨터 프로그래밍도 여러분야에서 사람들이 일을 하고 있습니다.
1. 기업업무전산화(SI, SM)
2. 웹프로그래밍
3. 통신,보안..
4. 수치해석, 데이터처리, 영상이미지처리..
5. 스마트폰 앱
6. 지능형 로봇..
...
위와같이 각자에게 주어진 분야의 SDK(Software Developmnet Kit)을 사용하여 프로그래밍을 합니다.
현재 자기가 만들고 있는 프로그램이 SDK에서 제공하고 있는 라이브러리(부품)로 만들어도 충분하면
알고리즘 따위는 필요없습니다. SDK 사용법만 열심히 익혀서 적당한 곳에서 잘 활용만 하면 되니까요.
하지만, SDK에서 제공하지 않는 라이브러리가 있을 수 있는데 이때는 내가 손수 만들어야 합니다.
이때 알고리즘이 필요합니다. 되도록이면 잘 만들어야 합니다.
경우에 따라서는 머신에 의존하는 로우레벨의 코드를 만들어야 하고,
데이터 처리 용량이 엄청 많거나 또 그것을 빠르게 처리하기 위해서 튜닝을 해야 할때 알고리즘이 필요합니다.
Stack, Queue, List, Tree, Hash, Graph, Sorting, Search... 이것에 대해서 잘 알고 있으면,
어떤 환경의 어떤 도구를 가지고 프로그래밍을 하던지 간에 자신감이 생깁니다.

From:
*알지비 (메일: rgbi3307(at)nate.com)
*학창시절 마이크로마우스를 만들었고, 10년동안 IT관련 개발자로 일하고 있음.
*틈틈히 커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

From:
*알지비 (메일: rgbi3307(at)nate.com)
*커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

semmal의 이미지

쓰게 되든 안쓰게 되든 알고리즘은 다다익선입니다.
알고 있을 때는 별 것 없는데, 모르면 엄청 답답하고 무식하게 일처리하는 외길로 가야하기 때문이죠.
또 알고리즘 많이 알고 있으면 윗사람에게 개기는데(?) 유용합니다.
P-NP문제 들고 오면 지구상에 누구를 대리고 와도 못한다고 뻗댈 수 있거든요.
그게 NP문제인지 모르는데다 의욕만 넘치면 죽어라 삽질하고 깨지기만 하겠지요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

winner의 이미지

저는 차라리 NP 문제 들고와서 해달라고 했으면 좋겠군요. 간단하게 충돌되는 요구사항들이 한사람한테서 나오는 상황이 아니면 좋겠습니다.
NP문제쯤 되면 프로그래밍을 하는 윗사람이 있으면 complexity가 복잡하다는 것은 이해할 겁니다. 굳이 NP문제인지 분간하지 않아도 한계치를 적절히 파악만 하면 될 것 같네요.

semmal의 이미지

국내에서 알아주는 SI업체인데도 팀장님은 모르시더군요.

고객분에게 말했더니 알아주셔서 다행히도 "쓸만한" 수준까지만 만들었습니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

dingkyu의 이미지

개인적으로는 어떤 알고리즘에 대해 많이 알고 있는것 보다는 어떤 문제가 주어졌을 때 어떤 알고리즘을 쓰면 좋겠구나 라는 생각만 들정도면 될것 같습니다. 구체적인 구현이나 적용방법등은 그때 그때 찾아보면 되구요.. 즉 어떤 알고리즘이 있는가 ? 어떤 알고리즘을 선택하면 좋겠는가 정도만 기억해 두고 실제 프로그래밍에 적용할 수 있는 수준이면 괜찮을거 같습니다.

고민이 많아 고민인 애늙은이 입니다.

jeongheumjo의 이미지

학부 알고리즘 수업에서 A 정도 받을 정도는 개념을 잡아야 하고요..
이후 잘 만들어진 라이브러리 사용방법을 익히는게 필요합니다.
STL 을 예로 들면 어려운 알고리즘들이 잘 준비되어있어서 쉽게 사용할 수 있습니다.
현업에서 알고리즘을 구현하는 경우는 임베디드 시스템인 경우입니다.
그 외의 경우는 거의 라이브러리로 해결하는 것 같아요.
말씀하신 책들 중 한가지만이라도 이해하시고 나서 STL 공부하시길 추천드립니다.

소타의 이미지

어떤 알고리즘을 적용할 지 선택할 정도의 지식은 있어야 합니다.
그 중 유명한 몇 가지는 직접 구현해 보세요. 그래야 상황에 따라 변종도 만들수 있고 실제로 코드로 구현할 때의 차이를 알 수 있습니다. 논리적으로 복잡도가 낮지만 실제로 구현할 때 메모리를 많이 쓴다거나 특별히 디스크에 친화적이지 않다거나 하는 구조들이 있을 수 있는데 안해보면 모릅니다.

필요합니다. 조립만 하고 살 거 아니면 소홀히 하지 마세요. 어차피 현업 진입하면 계속 공부해야 합니다.

ifree의 이미지

그래도 프로그래밍의 꽃은 알고리듬 아닐까요?
기존의 라이브러리 가져다가 끼워 맞추는 것이 프로그래밍이라고 할 수 있나요.

powerson의 이미지


글쎄요.. 알고리즘 분명히 중요한건 사실입니다만, 그렇다고 라이브러리 가져다가 끼워 맞추는 것이 프로그래밍이라고 할수 없다는건, 아닌거 같네요. 단순히 알고리즘을 직접 구현하는 것만이 능사는 아니지요. 코드 최적화 부분도 상당히 중요하기 때문에, 직접 구현해서 성능이 나빠질 바엔, 현재 기본적으로 어느정도는 최적화된 라이브러리를 가져다 쓰는 게 어찌 보면, 현명한 선택이라고 생각합니다. 저 역시 윗분들이 말씀하신 것처럼 현 상황에서 내가 어떤 알고리즘을 써야 하나를 판단할 수 있는 정도의 지식은 갖추어야 한다고 된다고 생각합니다. 이 상황에서 라이브러리가 없거나 적용시키기 힘든 경우에 직접 구현하면 되죠.. 거기다가 이런거 하나하나 다 개발하면서 안 그래도 적은 일정을 소화하려면, 밤새는거 외에 방법 있을까 싶네요..

------------------------------------------------------
아직은 젊다. 모든 것을 할 수 있는 나이란 말이지.

------------------------------------------------------
아직은 젊다. 모든 것을 할 수 있는 나이란 말이지.

puk101의 이미지

제 생각에는 기존의 라이브러리 가져다가 끼워 맞추는 것이 오히려 알고리즘보다 더 프로그래밍이라고 말할 수 있을 거 같은데요?

어느 천재가 뚝딱하고 기존에 작성된 모든 라이브러리를 압도하는 프로그램을 만들 수 있나요?

필드에서 알고리즘의 대부분은 이미 구현되어있고 검증까지 되어있죠.

실제로 능력있는 사람은 그걸 잘이용하는 사람이구요.

OS나 DB의 low level을 개발하는게 아니라면

알고리즘은 어떤게 있고 어떤 장점이 있다 정도만 알아도 충분한거같습니다.

ifree의 이미지

필드에서 사용 가능한 알고리듬이 대부분 구현되어 있다고 하지만,
실제로 기존의 라이브러리는 어느 정도 범용의 사용성을 가지고 있어서 자기 업무에 맞춰 특수화를 해야 하거나 적합하지 않은 경우가 많이 있습니다. 물론 필요한 라이브러리가 아예 없는 경우도 많구요.

Computer Vision 관련 프로그래밍을 하면서 초창기에 openCV 를 잠깐 가져다 쓴 적이 있었는데,
예을 들어, edge detection 의 경우에 openCV 는 단일 채널의 이미지에만 적용할 수 있게 되어 있기 때문에 컬러 이미지에 맞도록 수정해야 했고, 지금은 독자의 루틴을 사용하고 있습니다. 또 이 분야에서 동영상과 관련한 라이브러리는 존재하지도 않죠.

hiseob의 이미지

안드로이드 iOS MFC WinForms 하다못해 STL 까지

기본적으로 죄다 라이브러리 아닌가요?

stdio.h 는 라이브러리가 아니라 그저 헤더일 따름?

글쎄요 웬만한 프로그램중에 라이브러리 안가져다 쓰는게 있는지 그게 더 궁금하네요.

clnoe의 이미지

알고리즘을 많이아는 것보다는 확실히하는것이 좋을거라도 생각됩니다.

winner의 이미지

그럼에도 지금까지 이야기되고 있는 것을 보면 나름대로 괜찮은가 봅니다. 알고리즘 책 치고 학자스타일로 쓴 책도 아닌데 말이죠. 개인적으로는 Neapolitan이 쓰고, 한양대 도경구 교수님이 번역하신 책을 좋아합니다. 두께가 그리 두껍지는 않으면서도 알차거든요. 물론 Introduction to Algorithms에 비하면 모자른 면도 있습니다만...
좀더 현업에 실용적인 책으로는 Programming Pearls(생각하는 프로그래밍)을 추천합니다. 이 책 저자도 학자는 아닙니다만 이재규씨 책 스타일도 아니고, 사실 알고리즘 책도 아니지만 알고리즘을 중심으로 programming에 대해서 여러가지 생각을 하게 해주는 아주 멋진 책입니다.
그리고 전산한의 중요한 것들이 알고리즘을 중심으로 펼쳐지고 있습니다. 소프트웨어 공학에서 가장 중심에서 작업되는 것이 설계라면 전산학은 알고리즘이 중심이라고 생각합니다. 현업에서 알고리즘을 잘 아는 것이 고급 프로그래머가 되는 중요한 요소 중 하나라고 생각합니다만 또한 혁신적인 프로그래머가 되기 위해서는 알고리즘을 기반으로 다른 분야까지 손을 뻗을 수 있어야 한다고 봅니다.

choisey의 이미지

제 경우를 말씀드리자면...

그래도 꽤 이론쪽 성향이 쎈 분야에서 박사까지 했고요. 그 후로 계속 현업에서 개발을 해오고 있습니다 (미국에서 소프트웨어 엔지니어로 일하고 있습니다).

쪽팔린 얘기지만, 알고리즘 거의 기억 안납니다. 퀵소트같은 거 정말 깜깜하게 다 잊어먹었습니다. 딱 "퀵소트" 라는 이름만 기억 납니다. 다른 소팅 방법도 거의 기억 못합니다. 그밖에 알고리즘에서 뭐 배웠는지 가물가물 합니다. 그래서 알고리즘 많이 기억하는 분들 보면 감탄스럽습니다.

STL 을 쓰다보니 그런 거 같습니다.

알고리즘하고는 다른 문제지만, 디자인패턴도 10여년 전에 아주 공부 열심히 한 기억이 납니다만, 지금 하나도 기억 안납니다.

저같은 사람도 있습니다.

뭐든지 일하다가 막히면 웹에서 검색해보고, 잘 읽어보다보면 10여년 전에 봤던 내용이라는 게 조금씩 기억이 나기 시작합니다.

알고리즘, 아마 나중엔 다 잊어먹을 것입니다. 그러므로 시험공부하듯이, 어릿속에 정확하게 암기해놓는 건 그다지 중요하지 않을 거 같습니다. 그러나 그 개념을 한번 잘 이해해놓고 나서 잊어먹으면, 나중에 (심지어 20년 후에도 현업에서 일하다가 필요해질 수 있습니다) 다시 들여다보면 그때는 처음부터 다시 공부하듯이 들여다볼 필요는 없고, 보면 바로 이해가 되게 될 것입니다.

cinsk의 이미지

제 개인적인 생각으론,

업무의 성격에 따라 다르겠지만, SI, Embedded 등 회사에서 처리할 수 있는 업무들 대략적으로 생각해 볼 때,

알고리즘 실력이 뛰어나서 업무를 해결할 수 있는 것은 거의 없다고 생각합니다. (물론 알고리즘 실력이 뛰어나면 처리 결과가 상당히 좋을 수는 있을 겁니다.) 하지만, 그것보다, 해당 제품/서비스에 대한 이해가 먼저 갖춰져야 할 것 같습니다. 현업을 물어보신 것을 보니, 취업을 준비하고 계신 것 같은데, 일하고 싶은 방향에 따라, 해당 업무에 직접적으로 영향을 미치는 응용 능력에 힘쓰는 게 좋을 것 같네요.

ACM IPC 등이 아닌, 취업을 위한 기술 면접을 본다고 생각할 때, 자신의 능력을 어떻게 PR할 수 있을 것인지를 생각해보기 바랍니다.

예를 들어 mySQL/php 등을 써서 서비스를 제공하는 업무라면, mySQL/php에 대한 능력을 키우는 것이 좋을 것이고, messagener 등을 제작하는 곳이라면, XML, socket, xmpp 등에 능숙한 것이 더 좋을 것이고, game 개발이라면 3d에 대한 이해도와 opengl 또는 directX에 대한 능력, embedded system에 관련된 회사라면 CPU에 대한 깊은 이해도가 있다는 것을 PR할 수 있으면 좋겠죠.

--
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://www.cinsk.org/cfaqs/

cjh의 이미지

알고리즘을 아는 것도 중요하지만 적시적소에 쓸줄 아는게 더 중요합니다.
qsort()를 부르면 되는 때에 퀵소트 알고리즘 알고 있다고 직접 구현하고 있는
사람은 현업에서는 저평가받겠죠. (코드 줄수로 평가받는게 아니라면)

그보다는 working prototype을 만드는게 더 중요할 때가 많습니다. 최적화는 나중에
얼마든지 할 수 있습니다. 물론 예외적인 케이스 (메모리 제한을 심각하게
받고 있다든가)는 다를 수 있습니다.

--
익스펙토 페트로눔

--
익스펙토 페트로눔

winner의 이미지

필요한만큼 적당히가 정답인 듯... 세상에 수많은 일이 있듯, 공부할려면 한도 끝도 없는 것이 또한 전산학이니까. 현업들어가고 당장은 알고리즘이 별로 필요없다는 것은 사실입니다. 그런 일 안 시키니까... 하고 싶어도 할 기회도 없을테고. 하지만 계속 일하다보면 조금씩 계속 더 필요성을 느낄테고, 거기에 맞춰서 공부해나가면 되겠죠.
그런데 말이죠. 알고리즘이 아닌 것을 공부하면서도 그것을 제대로 이해할려면 알고리즘이 필요하다고 생각합니다. 그리고 알고리즘을 공부하면서 가장 좋았던 점은 무엇인가를 정형적으로 명세하는 법을 배웠던 것 같습니다. 물론 이것이 알고리즘은 아니겠지만 알고리즘을 표현할 때 이런 연습을 가장 많이 하게 되더군요.
그런데 정형명세를 해봐야 사람이 안 보면 의미가 없더군요. 알고리즘의 중요성을 상대적으로 저평가하시는 분들의 의견은 그런 의미라고 생각합니다.

khris의 이미지

뽑을때는 디게 따지는데 평소에는 쓸 일 없다가 가끔 시련이 찾아옵니다 ;D

───────────────────────
yaourt -S gothick elegant
khris'log
cIRCle ― Qt based IRC Client for S60 5th

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

wontop의 이미지

정보통신 전공해서..
학교 수석으로 졸업할 정도로 알고리즘 및 기타 등등 달달 외우고 프로그래밍으로 구현까지 잘 했었습죠 ^ㅡ^

그런데 지금 기억 하나도 안나요..

가끔 다시 보면 아~ 맞아.. 그랫었지 하면서 넘어가죠.

그런데 지금 네트웍 프로그래밍 현업에서 하고 있지만, 알고리즘 몰라도 큰 문제 없어요.

--------------------------------------------------
그걸 이루던지 이루지 못하던지 사람은 꿈에 이끌리는 법이죠.
'꿈'이라는 이름의 신의 순교자로서의 일생을

--------------------------------------------------
그걸 이루던지 이루지 못하던지 사람은 꿈에 이끌리는 법이죠.
'꿈'이라는 이름의 신의 순교자로서의 일생을

wontop의 이미지

a

--------------------------------------------------
그걸 이루던지 이루지 못하던지 사람은 꿈에 이끌리는 법이죠.
'꿈'이라는 이름의 신의 순교자로서의 일생을

emptynote의 이미지

그래도 알고보면 알고리즘의로 도배된 세상아닌가 하네요.

DB 만 해도 알고리즘 떡칠?이라고 하면 너무 과격한 표현일까요?

DNS 만해도 호스트명으로 IP 주소 매핑을 순차? 검색으로 하진 않겠죠.

보안에도 당근 사용되지요.

수만은 노력과 검증으로 탄생된 DB 를 이용하다 보면 아 나는 알고리즘과 상관없는 프로그래머인가?
회의가 들지요. 대부분의 업무에서는 DB 알고리즘 파혜칠 필요 없습니다.
DB query 최적화 보다는 잘 돌아가게 라는것에 더 가치를 더하기 때문입니다.
개발 프레임워크에 갇혀서 일을 할때도 비슷합니다.
훌륭한 프레임워크는 개발자가 업무에 필요한 것만 집중하게하여 쉽게 업무 프로세스를 작성하도록 하기때문에,
대부분 프레임워크에 갇혀 일하는 분들은 단순 반복적인 작업에 흥미를 잃기 쉽습니다.
포장마차에서 술잔을 기울일때 꿍시렁 거리지요. 알고리즘 필요 없다라고요.
정말 그렇까요?

또, 이것을 극복한 고수님들중 몇몇은 알고리즘 몰라도 된다고 말하는데,
그것은 미래 경쟁자들을 지치게 할려는 고수님들의 쉐이크 같습니다.

쉐이크에 속지 말고 쉐이크도 하지 맙시다.

niuzeta의 이미지

디자인 패턴...

...And all in war with Time for love of you,
As he takes from you, I engraft you new.

-Sonnet XV
전산계획설계사 지망 영문학과생

익명 사용자의 이미지

알고리즘도 중요하지만,
디자인패턴, low level에 대한 이해, 프레임웍에 대한 이해, 에러발생시 효율적으로 대처하는 방법, 사용자 UI의 편의성에 대한 배려 등등의 중요한 내용들도 있죠.
알고리즘만 파고들기에는 시간이 너무 아까울거 같아요.
알고리즘은 그냥 이런저런 알고리즘이 이런저런때 사용되는구나 정도만 알면 그때그때 가져다 쓰면되고,
만들어서 써야할 필요가 생기면 해당 부분만 더 깊이 들어가도 되지 않을까 싶네요.

RedPain의 이미지

필요한 얘기는 위 분들이 이미 다 해주신 것 같군요.

제일 공감가는 이야기는 "평소에는 쓸 일 없다가 가끔 시련이 찾아옵니다"랑 "알고리즘을 아는 것도 중요하지만 적시적소에 쓸줄 아는게 더 중요합니다"군요.

사실 제가 하고 싶은 말은... Knuth 대제님의 Holy Bible을 가지고 계시는군요. 그 책... 현업에 쓸려고 보면 바봅니다.

근데 읽다보면 진짜 재미있죠. Knuth 대제님이 워낙 위트가 넘치는 분이셔서. (먼산)