니플
34k
2017-06-11 22:47:13
26
7363

실무 개발자에게 알고리즘은 덜 중요할까?


https://medium.com/@ghilbut/%EC%8B%A4%EB%AC%B4-%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%97%90%EA%B2%8C-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98%EC%9D%80-%EB%8D%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-fcbab7f87074


제가 쓴 글은 아니고

읽어보시면 좋은 것같아 가져왔습니다

1
4
  • 댓글 26

  • 전재형
    4k
    2017-06-11 23:52:38 작성 2017-06-11 23:53:29 수정됨

    와드 박습니다.


    일리 있는 말이지만, 실제 논제는....

    "코딩 학원을 당장 졸업할 즈음의 개발자에게..."라는 단서가 달렸을 때의 양손의 책 중, 무엇을 먼저 볼 것인가 하는 주장이다.


    초급개발자라는 말의 정의를 저는 위처럼 인식하고 있어요

    0
  • aeba
    2017-06-12 01:56:29

    자료구조랑 알고리즘 열심히 공부하면, 스케일아웃 해야 할 문제에 스케일업을 선택하지 않는 사고방식을 가질 수 있다는 글로 보이네요.

    알고리즘 문제풀이 책을 백날 봐야 동시성과 병렬처리를 배울 수는 없을텐데 말입니다.

    0
  • fender
    14k
    2017-06-12 06:49:22 작성 2017-06-12 08:07:44 수정됨

    저 글에 의하면 저는 갑질을 좋아하고 이론을 무시하는 SI 바닥의 시니어 개발자 쯤 되는 사람이군요 ㅎㅎ

    제가 쓴 토론 글 원문에는 제 경력이 어떻고 무슨 회사를 다니고 연봉이 어떻고 그런 이야기는 한 마디로 없는데, 저 분이나 비슷한 취지로 덧글을 달다가 삭제한 분들은 저에겐 "자신의 경력을 근거로 삼지 말라"고 일침을 하면서, 꼭 본인이 얼마나 큰 회사에 다니느니, 내가 얼마나 실력 있는 개발자를 많이 아느니 하는 식의 이야기는 빠짐없이 등장하는 것도 재미있는 지점인 것 같습니다.

    개인에 대한 공격은 그렇다 치고, 제 생각에도 aeba님이 말씀하신 '스케일 아웃'과 '스케일 업'의 의미를 정확하게 이해하지 못하는 문제는 이와 같은 오해와 일맥상통하는 면이 있어 보입니다.

    즉, 소프트웨어 개발에 있어서 문제를 이해하는 접근에는 여러가지의 '축'이 존재하고, 패러다임, 디자인, 알고리즘, 아키텍쳐는 각각의 서로 연관은 있지만 연속적이지 않은 서로 다른 축이나 차원으로 보는 것이 보다 정확한 이해일 것입니다.

    그런 다양한 축이나 차원의 존재를 모르거나 자신이 어느 한 두 가지 종류에만 익숙할 경우 이른바 '들고 있는 것이 망치라면 모든 문제가 못으로 보인다'는 현상을 초래하는 것 같습니다.

    오히려 알고리즘이야 말로 구문 단위의 최적화를 통해 스케일 업을 고려할 때 주로 의미가 있고, 스케일 아웃에 대한 문제는 그 보다 구조적인, 즉 디자인이나 아키텍쳐 - 또는, 함수형의 경우는 패러다임 - 수준에서 다루어야 할 문제임을 제대로 이해했다면, 그런 예제가 역으로 모든 문제에 있어서 한 가지 축의 접근만을 보다 근본적인 것으로 생각하는 사고의 위험을 보여줄 수 있다는 점도 깨달았을 것으로 봅니다.

    0
  • kkey21a
    3k
    2017-06-12 08:07:17 작성 2017-06-12 08:25:33 수정됨

    결국 위 링크 글의 핵심은

    '스타(구글, 페이스북) 개발자들은 구현 그 자체보다 알고리즘을 더 중시한다'

    정도로 요약되네요.


    그런데 전 fender님 글을 구현이 아니라 어디까지나 프로그램의 이해가 우선시 되어야 한다는 글로 봤는데, 잘못 파악한건가요?

    그렇다면 위 링크 글과 fender님 글 모두 프로그램 원리를 먼저 이해해야 한다는 근본적인 입장은 동일하다 보여지는데, 단지, 그 프로그램 이해 수단에 있어 선행 수단을 디자인패턴으로 보느냐 알고리즘으로 보느냐 차이 아닌가요?



    PS

    물론 본인의 경력 만큼 좋은 근거는 없겠지만, 그 경력만큼 자신의 주장에 대한 논리도 보다 주니어 개발자들이 합리적으로 받아들일 수 있는 글이 되었음 좋았을텐데 아무튼 아쉽네요.

    2
  • fender
    14k
    2017-06-12 08:24:51 작성 2017-06-12 08:29:14 수정됨

    kkey21a // 제 관점은 쉽게 말해, 디자인 패턴이건 알고리즘이건 각각 서로 다른 수준에서 소프트웨어의 문제를 해결하기 위한 기법이고, 맥락없이 어느 쪽이 더 '근본'이 되고 중요한지를 따지는 것은 무의미하다는 것입니다.

    예를들어, 제가 디자인 패턴을 강조했지만, 만일 자바스크립트를 주 언어로 하는 개발자라면 실력을 키우는데, 전통적인 GoF 패턴은 별 도움이 안될 가능성이 높고, 순수 함수형 언어를 주력으로 삼겠다면 애초에 클래스 기반 객체지향 개념부터 먼저 배울 이유가 없는 것과 비슷한 이야기입니다.

    그래서, 전 어떤 분야를 택하던지 해당 분야의 핵심 개념을 중심으로 연속성을 따져서 가까운 쪽에서 부터 지식을 확장해나가는 것이 가장 효과적인 공부 방법이라고 생각합니다.

    이는, 만일 이야기하는 '맥락'이 자바나 C#과 같은 정적 타입 기반 객체지향 언어라면, 우선 배워야 하는 것은 패러다임에 대한 개념이고, 그 다음으로는 문제 해결을 위해 해당 패러다임의 빌딩 블록 - 즉, 클래스나 인터페이스 등을 어떻게 쌓아 나가는 것이 바람직한지에 대한 이해를 높이는 것이 가장 중요하게 다루어야할 기본이라는 주장입니다.

    그런 맥락에서도 패러다임이나 디자인을 배우기 전에 소수값 구하기나 최단경로 구하기 같은 연습문제부터 열심히 풀어보는 것이 더 '근본적' 지식을 쌓는 길이라고 주장한다면, 아마도 시야가 아직 구문 단위에 갇혀있거나, 아니면 자바나 C#을 대충 '이지 모드(easy mode) C 언어' 쯤으로 우습게 여기는 사람일 가능성이 높다고 생각합니다.

    2
  • kkey21a
    3k
    2017-06-12 08:47:34 작성 2017-06-12 08:57:24 수정됨

    fender//

    제 개인적으로는 fender님 의견에 동의합니다. 

    Language에 따라 패러다임이 변화해 온 것은 어디까지나 사실이닌깐요.


    다만 윗 댓글에서 언급하신 함수형 프로그래밍에서도 저는 디자인 패턴은 중요하다 생각하지만, 단순히 알고리즘과 선 후의 관계를 논하기는 제 프로그래밍 소양이 부족한 관계로 판단은 미루고 싶네요.


    뭐 어쨌던 제 개인적으로는 위 링크 글에서 강력하게 언급된 소위 스타 개발자들의 생각도 궁금하긴 하네요. 정말 제가 잘못된 생각을 하고 있는지...?

    (너무나 당연하다 생각하는지라... 또한 논리적으로 생각을 해도 어떤 패러다임에 있어서도 알고리즘은 무조건적으로 가장 기초가 되는 학문이다!?)

    0
  • fender
    14k
    2017-06-12 09:06:23 작성 2017-06-12 09:10:08 수정됨

    kkey21a// 제 생각도 다르지 않습니다. 그래서 'GoF 디자인 패턴'이라고 전제를 했던 것이고, 함수형 언어라면 해당 패러다임의 특성에 걸맞는 다른 종류의 패턴들이 필요할 것입니다.

    같은 객체지향 패러다임이라도 언어적 특성이 다르면, 예컨대 스칼라의 '케이크(Cake) 패턴' 같이 특화된 패턴이 생겨나는 것 같습니다.

    조금 더 추상적으로 이야기 하자면 디자인 패턴은 어떤 단위의 개념(빌딩 블록)을 쌓아나가는 원리에 대한 규칙이고, 보다 작은 단위로는 클래스, 클로져, 모나드 등 핵심 개념들이 존재할 것입니다.

    그리고 그런 핵심 원칙이나 개념등은 대체로 각각의 분야나 패러다임에 종속적입니다.

    그런이유로, 저는 일부 유명 기업에서 개발자 채용시 알고리즘 문제를 낸다는 것도, 지원 분야와 관련없이 이를 필수 조건으로 내세우는 것이라면 매우 비판적으로 생각합니다.

    저로서는 자바 개발자를 뽑으면서 '퀵 소트(quick sort) 알고리즘을 의사코드로 작성해라'라는 문제를 내는 것이, 예컨대 C개발자를 불러놓고 '참조 투명성(referential transparency)의 개념을 설명하라'는 식의 질문을 던지는 것보다 얼마나 더 변별력이 있을지 모르겠습니다.

    0
  • 칠역한천겁
    2k
    2017-06-12 09:53:48 작성 2017-06-12 10:12:26 수정됨

    10년도 더 전에 제 첫 직장에 백발의 프리랜서가 생각이 나네요.


    저(신입)을 불러놓고 너네들은 Library 쓸줄만 알지 알고리즘 구현은 생각도 안하지? 라며 약간 깔보는 듯한 말투로 거드름을 피우시던...ㅋㅋ


    나중에 쓰레드 버그 심어놓고 가셔서 회사 개발자들 다 달라붙어서 2주정도 만에 해결했다능...-_-

    유닉스 c 할때였었죠.


    저 글에서 경력 몇년차 어쩌고 하면서 말을 하는 사람을 꼰대 비스무리 하게 표현을 한거 같은데요.

    별수 있나요. 경험이 돈이 되고 경험이 무기가 되는건데..


    제 생각으로는 개발자는 고객의 요구사항을 최고의 품질에 가깝게 구현해 주는 사람이지 어떤 기술적 자기만족 과 연구를 하는 연구원은 아니라고 생각합니다. <= 연구직 말고 SI/SM을 하는 개발자에 한해서 입니다. 


    그냥.. 약간 머리속에 그려지는데...

    나는 열심히 공부를 해서 어떤 솔루션이나 프레임웍의 구조부터 자세히 알고 있는데 주위를 보니 그냥 사용법만 알고도 구현에 무리가 없고..


    대우도 머 나랑 대동소이 하다.. 그래서 불만이다.. 라는걸로 저는 보게 되네요.

    삐딱한건가요. ㅎㅎ  한때는 제가 가지고 있던 생각이기도 해서..


    옛생각도 나고.. 이래저래 생각이 많아지는 아침이네요. ^^;

    0
  • fender
    14k
    2017-06-12 10:16:58

    칠역한천겁// 조금 관점이 다를 수 있는 문제인 것 같습니다. 제가 원 글을 쓴 가장 큰 계기는 바로 자바 언어에 입문 하신 분들이 프레임워크의 구조를 파악하거나 직접 API를 설계하기 위해 필요한 지식을 공부하는 시간에 알고리즘 문제풀이에 많은 시간을 투자하는 경우를 종종 접했기 때문이었습니다.

    저도 원리나 구조를 아는 것을 매우 중요하게 생각하고 실무적 경험에는 이론적 지식의 뒷받침이 있어야 한다고 봅니다.

    단지 자바나 C# 개발자에게 최우선으로 중요한 원리나 이론적 지식이 알고리즘이 아니라고 생각할 뿐입니다.

    0
  • 도각도각
    3k
    2017-06-12 10:25:14 작성 2017-06-12 10:26:45 수정됨

    모든 개발자들이 구글, 페이스북에 입사하기 위해 일하는 것 도 아니고..


    구글, 페이스북에 입사하는 것이 개발자로서의 가장 큰 성공이라고 보지도 않습니다만..


    오히려 링크의 글이 문제삼고 있는 원글에 비해서 편협한 시각에 사로잡혀 공격적으로 쓴글 같네요..

    0
  • 칠역한천겁
    2k
    2017-06-12 10:27:09

    fender 님.


    저도 그 생각에 전적으로 동의를 하는 입장입니다.

    제가 전의 C개발자 선배를 예로 들었던 상황은..


    학교에서 ms 비주얼스튜디오 기반의 윈도우 C만 했던 제가 유닉스 C를 하면서..

    make, gcc 및 유닉스 환경에 적응을 해야 하는 상황이었는데 그런 배려(?)나 고려 없이 그저 알고리즘 운운해 하시는 분을 보면서 지금 생각해보면 좀 경솔하신 분이 아니었나 생각이 들어서 입니다.


    유한한 시간에 구현을 함에 있어서 기반 지식 혹은 근본지식 부터 쌓고 실제 활용하는 기술은 나중에 해도 된다라는 말을 별로 좋아하지 않아서요.


    야근과 결과물이 없는 상황에서 어떠한 변명이 통할지..-_-

    머 기본적으로 학교에서 자료구조 & 알고리즘 수업을 이수했다는 전제이긴 합니다.


    아예 근본이 없이는 무엇도 할 수 없으니까요.

    0
  •  (づ。◕ ܫ ◕。)づ
    4k
    2017-06-12 12:15:55

    페이스북 타고 넘어가봤더니

    fender님은 같이 근무하고싶지 않은 분이 되어있으시네요.. ㅠㅠ

    0
  • fender
    14k
    2017-06-12 12:24:27

    KDEV// 뭐 저도 저런 부류와 같이 근무하고 싶지 않기 때문에...

    사실 정확하게는, 그냥 근무는 그만하고 싶어요 -ㅅ-;

    1
  • 더미
    13k
    2017-06-12 12:28:18
    ~_~
    0
  • byeworld
    2k
    2017-06-12 14:40:04

    fender님의 글에도 문제점이 있다고 생각하고, 동의하는 입장은 아닙니다만, 

    글을 저런식으로 쓴다면, 작정하고 비난하고자 글을 쓴 것인데 보기 안좋군요.. 

    0
  • Hyperglide
    382
    2017-06-13 00:03:47

    https://www.facebook.com/kivoloid/posts/1494990520573156

    1
  • 욥욥욥
    892
    2017-06-13 00:07:41
    사실, 그런 사람들은 그런 시시한 커뮤니티를 하지도 않는다. 나도 페친들 링크 타고 가게됐을 뿐이다

    하하..



    0
  • 하마
    6k
    2017-06-13 14:06:04 작성 2017-06-14 12:00:33 수정됨

    별로 좋은 글은 아니네요.  전형적인 우물안 개구리로써 이해력 부족과 좁은 시야를 가지고 있는 것 만으로도 문제인데, 남을 비하해서 자기 주장의 정당성을 가지려는 나쁜 글쓰기 까지..


    fender님 애도를 ~~ 수준이하의 저격을 당하시네요. ㅎㅎ

    0
  • byeworld
    2k
    2017-06-13 18:14:08 작성 2017-06-13 18:19:54 수정됨

    to. Hyperglide

    제 취향의 글이군요.

    제 생각과도 가깝고..

    좋은 글 감사합니다.

    0
  • 양산형개발자43
    234
    2017-06-13 20:10:37

    저 분 프로그램 코드는 잘 읽을시려나....? 독해력은 떨어지시는거같은데...

    권위에 호소하지말라면서 권위 찬양하는건 뭐지 도대체 ㅋㅋㅋㅋㅋ 논리력은 일단 제로인듯..

    저런 자기 할말 하고 싶어서 쓴 글은 무시하시고, (별로 신경쓰시는것 같지는 않지만..)

    앞으로도 좋은 글 많이 써주셨으면 좋겠습니다.

    0
  • Taetrees
    546
    2017-06-14 01:10:03

    분노기반의 수준 떨어지는 글이군요.

    혹 저번에 길벗님이 자기 댓글 지우고 블로그에 쓴게 아닌가 할 정도로 비슷한 내용이네요.

    독해능력이 의심되는 제목과 부족한 논리가 알고리즘을 지지하는 자가 맞는지 의심될 정도군요.

    0
  • 술술
    161
    2017-06-14 02:20:53 작성 2017-06-14 02:22:01 수정됨

    알고리즘이 기본이며 근간이라는건 동의하는 바이나 제시하는 근거가 저질스럽기 짝이 없네요.

    구글이 그렇게 한다,  대기업에서 일해봤더니, 뛰어난 개발자는 그런 커뮤니티를 안하겠지만...

    왜 굳이 저런 걸 집어넣어서 본인의 품격과 글의 논리와 설득력을 떨어뜨리는지 모르겠네요. 

    0
  • kkey21a
    3k
    2017-06-14 07:34:24 작성 2017-06-14 07:51:48 수정됨

    Taetrees//

    같은 사람인 것 같은데요 ㅎㅎ


    그러닌깐 논리도 비슷하죠. 단, 지인들이 볼 수 있으닌깐 급여 자랑은 뺀 듯~ 


    솔직히 링크 글 본인 프라이드 강한 건 인정하는데, 그에 반해 원 글의 대전제를 망각하고 알고리즘 개념 또한 본인 생각으로 확대하여, 이에 대한 반박 논리만 빈약해 진 것 같아 조금 아쉽긴 하네요.

    0
  • Floki
    2017-06-14 12:56:20

    매번 느끼는 것이지만 fender님은 글을 참 어렵게 쓰시는 듯 합니다.


    " 패러다임, 디자인, 알고리즘, 아키텍쳐는 각각의 서로 연관은 있지만 연속적이지 않은 서로 다른 축이나 차원으로 보는 것이 보다 정확한 이해일 것입니다.

    그런 다양한 축이나 차원의 존재를 모르거나 자신이 어느 한 두 가지 종류에만 익숙할 경우 이른바 '들고 있는 것이 망치라면 모든 문제가 못으로 보인다'는 현상을 초래하는 것 같습니다."


    이거 도저히 이해가 안되는 문장인데요.. 무슨 글인지 조금 쉽게 써 주실 수 없습니까?

    1
  • aeba
    2017-06-14 21:52:43

    제 이해는 이렇습니다. 축을 (문제에 대한) 접근 방식이나 (문제의) 추상화로 이해하면 편할것 같습니다. 대체해서 다시 써보면:


    다른 종류의 문제를 해결하기 위해 패러다임, 디자인, 알고리즘, 아키텍처라는, 연관은 있지만 엄연히 다른 "문제에 대한 접근 방식"(추상화)가 있다.

    여러 접근 방식의 존재를 알지 못하거나, 익숙하고 선호하는 접근 방식이 있을 경우에는, 자신이 처한 모든 문제 상황에 대해 적합한지 여부를 따지지 않고 한가지 방식으로만 문제에 접근하고 해결하려고 한다.

    0
  • Taetrees
    546
    2017-06-15 00:29:08

    Floki//

    관련 있지만 다른 분야의 것을 같은 분야라고 착각해
    한가지 잣대로 평가, 해결하려고 드는 사람이 있다.

    정도로 해석 되는군요.


    문어와 구어를 꽤 구분하시는 분이라서 어렵게 느껴질 때가 있긴하죠.

    요즘 인터넷의 글들이 구어 위주로 흘러가기 때문에 보기 어려운 글, 잘 안 읽히는 글들은 중요하지 않으면 스킵하는 경향이 생기는 것 같습니다.


    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.