fender
22k
2017-06-08 18:51:12 작성 2017-06-10 09:51:06 수정됨
94
54088

개인적으로 알고리즘 관련 논란에 민감한 이유


이미 다른 글에서도 적었지만, 알고리즘의 필요성에 대한 토론은 이 곳에서도 꽤 흔하게 접할 수 있는 주제 중 하나입니다. 그리고 느끼셨을 지 모르지만 저는 이 문제에 대해 꽤 강한 의견을 가지고 있고 그런 주제의 글이 올라올 때 자주 토론에 참여해서 생각을 피력하는 편입니다.

알고리즘이 더 이상 모든 분야의 기본 지식이 아니라고 생각하는 이유는 이미 그런 토론을 통해 충분히 이야기했기 때문에, 지금은 왜 제가 이런 문제를 특히 민감하게 느끼는지에 대해 적어볼까 합니다.

제 생각에 자바나 C#, 혹은 자바스크립트 개발자에게도 '기초 지식'으로 알고리즘이나 운영체제 등을 공부할 것을 주문하는 것은 대체로 그런 '기본'을 배우면 나머지 '응용분야'는 쉽게 익힐 수 있을 것이라는 가정에서 출발하는 것 같습니다.

그리고 경우에 따라선 한 걸음 더 나아가 자바 같은 고수준 언어로 다루는 분야는 모두 그런 '응용'에 해당하기 때문에 보다 근본적이고 깊이 있는 운영체제나 C언어 등만 제대로 하면 어렵지 않게 익힐 수 있을 것이라는 근거없는 자부심으로 표출되기도 합니다.

일부 전공자의 그런 자만심이나 편견이야 무시해버리면 그만이겠습니다만, 보다 중요한 문제는 비슷한 논리에 현혹되서 잘못된 공부 방향을 잡는 초보 개발자를 꽤 많이 보았다는 점입니다.

이는 여러 차례 언급한 우리나라 특유의 SI시장 환경과 밀접한 관계가 있는데, 많은 분들이 제대로 개발의 기초를 다지지 않고 속성으로 스프링MVC 기반의 사이트를 빨리 찍어내는 기술을 습득해서 현장에 투입되고 있는 현실을 감안해야 할 문제입니다.

이런 식으로 기초없이 특정 분야의 단순 응용 기술만 반복 숙달한 경우 조금만 문제가 달라져도 곧바로 벽에 부딪힐 수 밖에 없습니다. 또 어찌어찌 버티면서 경력을 쌓는다 해도 단순 반복작업만 하다보면 정말 자신이 하는 것이 제대로 된 개발이 맞는지 회의감이 들기 마련입니다.

문제는 이 상황에서 막연하게 "제대로 된 개발을 하려면 전공 지식을 알아야하지 않을까"하는 생각으로 알고리즘이나 자료구조의 심화 과정 등을 뒤적이는 경우나, 또 그런 공부를 추천하는 분들이 많다는 것입니다.

물론 그런 내용을 알아서 나쁠 건 없습니다만, 이 분야에서 알아서 좋은 정도의 지식은 평생 공부해도 다 못배울 만큼 방대한 것이 문제입니다. 그리고 자바나 C# 같은 언어를 주력으로 하는 개발자가 앞서 말한 단순 반복 작업의 한계를 극복하는데 있어서는 알고리즘 지식은 우선적으로 도움이 되는 내용이 아닙니다.

그 이유에 대해선 앞서 링크한 글에서 자세히 이야기했으니 반복할 필요는 없을 것 같습니다. 다만, 왜 아직까지 전공 교과가 그런 내용으로 구성되어있는지에 대해 잠시 이야기해보는 것은 의미가 있을 지 모르겠다는 생각도 듭니다.

제 생각에 아직 전산 전공 교과가 운영체제, 알고리즘, 컴파일러 이론, C언어 등의 주제로 구성되어 있는 가장 큰 이유는, 그런 이론이 확립되고 교재가 만들어지고, 또 이를 가르치는 교수들이 전산을 배운 것은 지금 보다 훨씬 개발 분야가 덜 분화되고 세분화가 되기 이전이었기 때문인 것 같습니다.

그 시절에는 개발 분야 자체도 단순했고, 대부분의 분야는 지금보다 훨씬 더 하드웨어 쪽에 근접해 있었습니다. J2EE 컨테이너니 닷넷 프레임워크니 하는 고수준의 추상화 계층이 일반적이지도 않았고, C언어 하나만 잘해도 못 다루는 분야가 없는 시기이기도 했습니다.

20년 쯤 전의 게임 개발의 '기본'이 저수준의 OpenGL API를 능숙하게 다루는 것이었지만 고수준의 추상화 계층을 제공하는 다양한 게임 엔진이 보편화된 뒤로 전혀 다른 종류의 지식이 이를 대신하게 된 것처럼 소프트웨어 개발 분야의 '기본' 지식은 시간이 지나면 함께 변하기 나름입니다.

그리고 소프트웨어 기술의 발전은 결국 추상화, 일반화 기술의 발전으로 해석할 수 있는 점을 감안하면, 결국 변화의 방향은 개발자가 점점 더 고수준의 도구를 통해 전에는 복잡도를 감당할 수 없었던 문제를 보다 쉽게 다룰 수 있게하는 쪽으로 발전한다고 말할 수 있을 것입니다.

그래서 이 분야에서, 만일 20년전과 지금 '기본'으로 가르치는 내용이 동일하다면 이는 결국 가르치는 쪽이 기술 발전의 흐름을 따라잡지 못했다는 반증이라고 생각합니다.

물론 시대가 변한다고 저수준 지식이 필요없어지는 것도 아니고 알고리즘 같은 학구적(academic)한 접근이 의미 없어지는 것도 아니긴 합니다.

하지만 알고리즘이 학구적 분야라면 집합론이나 타입 이론도 개발과 직결되는 학문적 지식이고 어쩌면 머지 않은 장래엔 기계학습 같은 내용도 추가될 지 모르겠습니다.

결국 중요한 것은 자신이 주력으로 삼는 기술이 그런 큰 흐름에서 어디에 위치하는지 인지하고, 해당 분야의 핵심이 되는 내용부터 공부를 시작해서 시간이 허락하는 한 다른 분야로 지식을 확장해나가는 요령이 아닐까 생각합니다.

그런 식으로 꾸준히 공부를 하면서 개발 경험을 쌓다보면 어느 순간에는 알고리즘을 포함해서 방대한 분야를 포괄하는 지식을 자랑하는 고급 개발자가 될 수 있을지 모르겠습니다.

하지만 고급 언어를 주력으로 하는 개발자가 자신의 분야의 기초도 안되어 있는 상황에서 C언어 개발자 흉내부터 낸다면 죽도 밥도 안되기 십상이라고 생각합니다.

그런 이유로 저는 자바나 C#를 주력으로 하는 개발자가 객체지향이나 디자인 패턴 등을 어느 정도 능숙하게 다루지 못하는 상황에서 알고리즘 같은 내용부터 너무 깊게 공부하는 것은 득보다는 실이 많은 접근이라고 봅니다.

30
38
  • 댓글 94

  • kenu
    54k
    2017-06-08 19:02:18

    자동차 정비를 몰라도 면허증만 있으면 운전할 수 있는 것처럼, 내부 깊은 곳은 몰라도 사용할 수 있다고 생각합니다.


  • 협군
    6k
    2017-06-08 19:11:12

    ^^ 레이서가 자동차 정비까지 배워서 우승권에서 놀아보자는 건데

    여기는 레이서들의 커뮤니티가 아니죠.

    운전 면허증 따서 택시 몰려는 사람들인데 레이서들이 섞여 있어서 그런 것 같습니다.

    적당히 차량 튠업도 하면서 놀고 싶은 애호가들도 많구요.

    반대로 교통법규 하나도 모르면서 무면허 택시를 운전하시는 분들도 많습니다 ㅠㅠ


  • fender
    22k
    2017-06-08 19:22:01

    협군 // 전 고수준 개발자가 저수준 개발자보다 전문성이 떨어진다고 생각하지도 않습니다. 단적으로 말해서 C언어 잘하면 자바 스크립트 따위는 그냥 할 수 있는 시대는 아니니까요.

    그래서 전 F1 레이서가 최적의 타이어 소재를 찾기 위해 재료공학부터 전공해야할 필요는 없다 정도의 비유가 더 적합하지 않나 싶습니다.


  • 가가멜리
    1k
    2017-06-08 19:23:16

    슈프림팀의 do 라는 곡이 생각나네요

    음표를 몰라도 가수가 될 수 있어
    색깔을 몰라도 화가가 될 수 있어
    글자를 몰라도 작가가 될 수 있어
    Do! What u wanna do!



    -1
  • kkey21a
    4k
    2017-06-08 19:52:15

    JDK나 프레임워크 소스 그 자체를 까지말고, 돌아가는 원리를 이해하라는 이야기 인거죠?

  • fender
    22k
    2017-06-08 19:55:20 작성 2017-06-08 20:01:54 수정됨

    kkey21a// 네, 객체지향 언어에서 무언가를 이해하기 위해 구문 단위 코드를 보아야한다면 그 코드를 잘못 설계한 것이거나 보는 사람이 객체지향을 잘 이해하지 못하고 있을 가능성이 높다고 봅니다.

    링크한 글에서 지적했지만, 알고리즘은 거의 구문 단위의 해법을 다룬다면 디자인 패턴은 객체지향에서 API 수준의 문제를 다루는 차이가 있습니다. (어느 한 쪽이 다른 쪽을 완전히 대체한다는 뜻은 아닙니다.)

    개인적인 경험상 자바나 C# 같은 언어의 기초가 부족한 개발자가 벽에 부딪힌다면 조건문이나 반복문 같은 구문 수준의 흐름은 이해해도, 계층이나 패턴 단위의 의미를 이해하지 못하는 것이 원인이되는 경우가 상당히 흔한 것 같습니다.

    그런 의미에서도 그런 고수준 언어 개발자가 우선적으로 습득해야하는 것은 정렬이나 검색 알고리즘이 아닌 그런 API 단위의 프로그램을 구성하고 이해하는 능력이라고 봅니다.

  • byeworld
    3k
    2017-06-08 19:56:01 작성 2017-06-12 14:43:23 수정됨

    댓글들 모두 비유가 훌륭하군요.. 

    그래서 저도.. 

    가수가 작곡을 잘해야 하는 것은 아니죠..

    라고 하고 싶군요... 

    추가로.. 이 노래 좋은 노래다, 부를 수 있는 노래다. 부르고 싶은 노래다. 이런 판단은 할 수 있어야겠죠..

  • fender
    22k
    2017-06-08 20:29:55 작성 2017-06-08 20:30:21 수정됨

    알고리즘과 디자인 패턴의 보다 정확한 정의에 대한 내용을 찾다가 마음에 드는 설명이 있어서 소개합니다:

    Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm.


    쉽게 말하면, 디자인 패턴은 언어의 패러다임보다는 낮은 수준, 그리고 알고리즘 보다는 높은 수준의 개념이라고 이해할 수 있다는 뜻입니다.

    그렇게 보면 왜 예컨대 자바 언어를 주력으로 한다면, 객체지향과 같은 큰 단위의 패러다임을 이해한 다음에는 디자인 패턴을 공부하는 것이 좀 더 연속성 있는 접근 방법이 될 수 있는지 쉽게 이해할 수 있을 것 같습니다.

  • kkey21a
    4k
    2017-06-08 20:37:12 작성 2017-06-08 20:53:48 수정됨

    fender//

    우선은 fender님 의견에는 저또한 공감합니다.


    그러나 실상 저도 si/sm 계열에 있긴 하지만, 어느정도의 개발 관련 사전 지식만 있다면, sm은 외워서도 프로그램 할 수 있는 수준입니다.

    sm 분들은 실상 어떻게 프로그램을 잘 설계할까 보다 어떻게 잘 운영을 할 수 있을까라는 포인트여서 실상 객체지향 프로그래밍은 제쳐두고 자신들이 알게 모르게 사용하고 있는 servlet 기본 원리에도 전혀 관심이 없습니다.


    다시 이야기 하자면 고객 입장에서 소스 품질에 대한 판단 할 수 있는 역량도 안되며, 기껏 일부 솔루션 등으로 소스 품질 검증을 하는 수준이라 그 품질 검증 솔루션에 걸리는 부분만 수정하면 넘어갈 수 있는 수준입니다.


    그리고 무엇보다도 서비스 중심이 아닌 데이터 중심이며, 기술 중심이 아닌 업무 중심 입니다. 또한 객체지향 개발한다고 해서 어느 누구도 알아주지 않습니다. 그런데 더 웃긴건 누군가 이런 식으로 개발을 한다면 일부러 어렵게 짜서, 본인 몸값을 올릴려고 한다는 어처구니 없는 이야기도 주변에서 한번씩 듣게 됩니다.


    이러다보니 저도 변명 아닌 자기 변명만 늘게 되고 그렇네요. 솔직히 편하게 일하면서 꼬박꼬박 나오는 돈을 무시하기에는 너무 나이가 든 것 같네요.

    (실상은 어린편인데 말이죠ㅎ)


    PS

    1.SI/SM 분야에서도 위와 같이 안 그런 분들이 더 많다고 믿고 싶습니다. 그러니 저 까지 마세요 ㅠㅠ

    (지는 깔거 따 까고 까지 말라니 -ㅅ-;)

    2. 알고리즘과 디자인패턴 어떤 차이가 있는지 묻고 싶었는데, 맥락을 이해하니깐 따로 안 물었던 것인데, 바로 위 댓글에 따로 설명해 주셨네요ㅎ

  • 전재형
    4k
    2017-06-08 20:56:31

    저는 반대로 반대의견을 피력해볼까 합니다.


    위에서 말씀하신 것처럼 디자인 패턴은 문제 해결에서 있어서 알고리즘보다 높은 레벨. 입니다.


    따라서 작은 문제를 해결하기 위해서는 알고리즘에 대한 개념이 있어야 하지요.


    패턴이든 알고리즘이든 문제 해결을 위해 존재하는 역활 또는 설계를 대변하는 말일테니까요.


    그러면 신입 개발자한테 요구되는 항목은.. 큰 그림을 그리는 역활을 맡길까요?

    아니면 패턴 적용보다 더 작은 역활을 맡기게될까요?


    그런 측면에서 알고리즘의 방법론들에 대하여 패턴에 앞서 알고 있어야 하지 않을까요?


    - 패턴이 필요없는것이 아니라. 정말 패턴이 다른 지식분야보다 우선해야지를 알고 싶어서

    반대 의견을 만들어봤어요.

  • fender
    22k
    2017-06-08 21:19:54 작성 2017-06-09 05:58:16 수정됨

    전재형// 말씀하신 부분은 토론하기에 흥미로운 주제라고 생각합니다.

    제 생각에 자바나 C# 같은 언어를 배울 때 디자인 패턴을 우선시 해야하는 이유는 대체로 두 가지가 있는 것 같습니다.

    우선 앞서 이야기한 배움의 연속성을 근거로 들 수 있는데, 아마도 많은 경우 입문서나 기초 강의를 통해 그런 언어를 배웠다면 객체지향, 즉 패러다임 수준의 기본적인 내용을 배웠을 것입니다.

    물론 조건문이나 반복문 같은 가장 세세한 구문 단위의 내용도 마찬가지로 배우긴 합니다만, 중요한 것은 디자인 패턴이 그 두 가지 서로 다른 계층의 간극을 이어줄 수 있다는 점입니다.

    객체지향 기초를 배우고 현업에 투입된 후 어떤 벽을 느낀다면, 모르긴 해도 바로 그런 간극 때문에 다음 단계로 나아가지 못하고 있을 가능성이 높습니다.

    단적으로 말해서 그런 개발자가 실무에서 추상 클래스나 인터페이스 등을 얼마나 자주 써봤을까요? 아마도 '스프링을 쓰면 인터페이스를 써야한다' 같은 부정확한 내용을 배워서 뜻도 모르고 기계적으로 적용하는 경우를 제외하면 정말 객체지향적 설계를 위해 추상 클래스와 인터페이스를 작성하는 경우는 생각보다 많지 않을 것입니다.

    그래서 저는 자바 같은 언어를 주력으로 하는 개발자가 인터페이스나 추상 클래스를 제대로 못다루는 것은 패러다임 자체를 전혀 활용하지 못한다는 뜻이고, 이는 이진 검색(binary search)이나 퀵 소트(quick sort) 알고리즘 등을 외워서 짤 수 있는 등의 능력보다는 훨씬 더 근본적이고 중요한 지식이라고 생각합니다.

    두 번째 이유는 기본적으로 자바나 C#과 같은 고수준의 언어는 이미 알고리즘 수준의 문제 해결을 위한 많은 도구를 기본 제공하고 있기 때문입니다.

    단적으로 말해서 알고리즘을 이야기하면 가장 흔하게 드는 예가 정렬이지만, 자바 핵심 API에서는 개발자가 기본적으로 정렬 알고리즘을 선택할 수 없습니다. 다른 글에서도 예로 들었지만, Comparator와 같은 API 수준의 사용법을 이해한다면 그냥 Collections.sort() 같은 API를 호출하면 어지간 하면 뜯어볼 필요없는 내부 구현에서 정해진 규칙에 따라 적절한 정렬 알고리즘을 사용할 뿐입니다.

    다른 예를들자면, 우리나라에선 자바 개발자라면 무조건 익혀야하는 스프링MVC 같은 프레임워크가 왜 그런 모양으로 구성되어 있고 어떤 원리로 동작하는지 이해하려면 우선 알아야하는 지식은 디자인 패턴이지 알고리즘이 아닙니다.

    객체지향 API를 이해하는데는 소스를 뜯어볼 이유도 없고, 아마 뜯어봐도 딱히 중요하게 '알고리즘'이라고 부를 만한 구문을 찾을 수 있는 경우는 생각 만큼 많지 않을 것이라고 예상합니다.

    마지막으로 우리나라 SI 현업에서 신입에게 디자인 패턴을 쓸만한 일을 맡기겠느냐는 현실론을 말씀하신다면, 글쎄요... 아마"디자인 패턴이고 알고리즘이고 간에 SQL만 잘하면 된다"가 좀 더 현실에 가까운 답이 아닐까 싶습니다.

  • unthinkall
    1k
    2017-06-08 22:19:55

    개인적으로 fender님께 참 감사를 드립니다.

    이 글은 개발에 입문한 단계에서 정말 중요한 지표라고 생각합니다. 

    저 또한 대학에서 전공으로 알고리즘을 공부했었습니다.

    이 글의 대부분 내용에 대해서 동의하고 

    널리 알려졌으면 합니다.

    잘몰라서 헤매는 사람들에게 등불같은 존재입니다.

    제가 하고 싶은 말을 너무 속시원히 해주셔서 사이다 한잔 마신거 같네요...


  • yangbuk84
    46
    2017-06-08 23:00:38

    본문도 좋고 바로 윗 댓글은 더좋네요. 너무나 현실적인 가이드.

    저는 4년차 무렵에야 늦게나마 운좋게 디자인패턴을 심도 있게 학습하게 되었습니다. 디자인 패턴이 무엇인지에 대한 설명을 듣고 필요성을 뼈저리게 느끼고 공부한 후 코드를 보는 눈이 즉시 확 떠지는 걸 직접 경험한 바... 디자인 패턴의 우선 학습은 정말 중요한 것 같습니다.

    회사 수준의 업무에선 사실 알고리즘이라고 할만할 것을 신입이 짜야 할 상황이라면 그것 자체로 끔찍한 상황이지 않을까 싶게 그럴 기회가 거의 없고...


    알고리즘을 학습했을 때 디자인 패턴을 학습했을 때만큼 내가 당장 봐야 하는 코드들의 이해도가 높아지기도 어려운게 사실입니다. 왜냐면 지금 당장 볼 spring mvc의 코드들은 다들 아시다시피 전부 크고 작은 디자인 패턴의 조합이니까요;;

    만약 제가 신입 시절로 돌아가게 된다면 java, db, sql, html, css, js, 네트워크 정도까지 기초만 다진 후 디자인 패턴을 제일 먼저 공부할 것 같네요... 디자인 패턴에 대한 이해도가 생기면 스프링 공부는 훨씬 수월해질테니 스프링 mvc 등은 그 후에 학습하게 되겠죠;;

  • kkey21a
    4k
    2017-06-08 23:00:42 작성 2017-06-08 23:05:26 수정됨

    솔직히 시험치는 것도 아니고 필요한 알고리즘이 있으면 인터넷 찾아보고 구현하면 되지만, 객체지향이나 디자인 패턴들은 단순히 외워서 프로그램에 적용하려고 하면 막상 쉽지만은 않은게 사실이닌깐요.

    다시 말해보면 알고리즘은 외우면 되지만, 디자인 패턴은 이해가 필요하닌깐요.

  • 창천향로
    5k
    2017-06-08 23:20:02

    fender님 정말 정말 좋은글 감사합니다

    짧은 경력이지만 100퍼센트 공감하는 이야기입니다.

    이건 진짜 많은 회사와 개발자분들이 참고해야하지 않나 싶습니다.

    항상 좋은 방향을 제시해주시는 글을 작성해주셔서 감사합니다.


  • kingbbode
    129
    2017-06-08 23:37:54

    저에게 항상 가려웠고, 항상 고민하고 있던 부분을

    해결할 수 있는 방향을 보여주셔서 감사합니다.

  • charsyam
    20
    2017-06-08 23:38:11

    fender님 좋은 글 감사합니다. 어느 정도 동감하면서도,

    알고리즘만 공부하는 사람 <-> 프레임워크 내부를 공부하고 인터페이스등 추상화를 공부하는 사람이라고 하면...

    전 도리어... 이런 분류의 대립보다는

    아무것도 안하는 사람 <-> 알고리즘도 공부하고 프레임워크 내부랑 다 공부하는 사람

    으로 구분되는 경우가 더 많지 않을까 싶네요.

    제 주변에서 잘하시는 분들이나 잘하게 되는 사람들은 호기심이 강해서 이런것들을 스스로 찾고 공부하는 사람들이더군요. 하나의 필요성을 알면 다른 부분도 더 알고 싶어했던 사람들이 더 많았던거 같습니다.

  • flyso2
    702
    2017-06-08 23:51:19

    플그램하면서 스택이나 큐를 쓰거나 정렬알고라즘을 코딩하는 개발자 손드세요


    숙제하고 있는 컴공대학생 빼고 없죠?

  • charsyam
    20
    2017-06-09 00:03:16
    flyso2 실제로 코딩을 하는 경우보다는, array를 써야할지, tree를 써야할지, hash를 써야할지, 링크드 리스트를 써야할지... 이런건 구분해서 쓰는 사람이 많지 않을까요?
  • kingbbode
    129
    2017-06-09 00:17:18 작성 2017-06-09 00:18:32 수정됨

    charsyam //

    제가 보고 있고 알고 있는 요즘의 개발자들 중에서는 이직, 입사를 위한 알고리즘을 공부하는 개발자들이 정말 많습니다.

    "알고리즘만 공부하는 사람 <-> 프레임워크 내부를 공부하고 인터페이스등 추상화를 공부하는 사람"

    이라고 하지만, 제가 보아온 많은 주니어 개발자 분들은 전자의 비중이 훨씬 높았습니다. (요즘 알고리즘 교육들이 그렇게 핫하다고 합니다..)

    경력이 짧아 "아무것도 안하는 사람 <-> 알고리즘도 공부하고 프레임워크 내부랑 다 공부하는 사람"에 대해서는 잘 모르겠습니다. 

    저와 같이 자바를 주력하는 개발자가 입사를 위해, 이직을 위해 알고리즘을 공부하고,(입사를 위한 공부는 어쩔 수 없지만..) 알고리즘을 잘하는 것이 진짜 개발을 잘하는 것이라고 생각하는 일부 사람들의 득보다는 실이 많은 접근을 최소화하기 위해 이 글이 널리 알려졌으면 좋겠습니다.

  • 사브리너
    46
    2017-06-09 01:11:19

    좋은글이네용

    그래도 저는 알고리즘 공부는 필요하다고 생각해요

    물론 제가 말하는 알고리즘은

    퀵소팅의 시간복잡도가 얼마고 이진트리를 c로 짜보고 이런걸 말하는게 아니라

    icpc 문제들 같은..복잡한 현실세계의 상황을 코드로 옮길수있는 그런 연습

    위에 어떤 분이 말씀하신대로 디자인패턴의 한 단계 아랫부분이죠

  • 전재형
    4k
    2017-06-09 01:36:26
    "단적으로 말해서 그런 개발자가 실무에서 추상 클래스나 인터페이스 등을 얼마나 자주 써봤을까요? 아마도 '스프링을 쓰면 인터페이스를 써야한다' 같은 부정확한 내용을 배워서 뜻도 모르고 기계적으로 적용하는 경우를 제외하면 정말 객체지향적 설계를 위해 추상 클래스와 인터페이스를 작성하는 경우는 생각보다 많지 않을 것입니다."

    위 글에서 알수 있듯, 초급개발자는 굳이 스프링 구조를 몰라도 프로젝트에 일익을 담당할수 있습니다. 진짜로 필요한 일은 자신에게 주어진 구현입니다.


    "단적으로 말해서 알고리즘을 이야기하면 가장 흔하게 드는 예가 정렬이지만, 자바 핵심 API에서는 개발자가 기본적으로 정렬 알고리즘을 선택할 수 없습니다. 위에 연결한 글에서도 예로 들었지만, Comparator와 같은 API 수준의 사용법을 이해한다면 그냥 Collections.sort() 같은 API를 호출하면 어지간 하면 뜯어볼 필요없는 내부 구현에서 정해진 규칙에 따라 적절한 정렬 알고리즘을 사용할 뿐입니다."

    윗 글에서는 중요한건, 필요하면 Comparator를 구현해야 해라고 상급자가 설계이후 알려줄수만 있다면 초급개발자가 굳이 패턴이 어떻게 구성되어 있나를 이해할 필요까지도 있을까요?


    이 상황에서 당장 일을 맡은 개발자가 해야 하는 일은  "Comparator"를 구현하는 일이 되겠죠.

    이 임무에서는 알고리즘(거창해 보이지만..)이 아닐까 싶은데요?

    거듭 말하지만, 알고리즘의 가진바 정의는 유한문제를 푸는 방법과 액션의 집합일테니까요.



    말씀하신 것처럼 큰 규모(특히 설계레벨)에서 패턴을 모르면, 프로그램을 이해할수 없듯이, 알고리즘을 이해하지 못하면, 특정 문제가 발생했을 때, 해결방안 모색에 크게 어려움을 겪을 것으로 생각됩니다.


    예를 들어, 재귀구조로 이루어진 계산기 로직이 있다고 가정합시다.  (1 + 1) * 2 / 3 - 3 이런 식의 문제의 결과값을 구하는 로직입니다. 이경우 실수가 있어서, ()괄호에 대한 처리 로직이 빠져있을 때, 재귀에 익숙하지 않은 사람이 어느 구문에 어떻게 끼워넣을 것인지 과연 판별할수 있을까요?



    몇몇 댓글에서 자료구조가 스택과 큐 같은 것만 자료구조라고 생각하시는 분이 계시는것처럼 느껴지는데, 자료구조는 말구대로 data structure인 것이죠. 

    예를 들어 사전 프로그램을 구현한다고 가정해 봅시다. 이 경우, data structure는 "음절"별로 나누어져서 앞음절과 다음음절간의 링크를 가게 될 것이겠죠. 이 관계를 바로 자료구조라고 표현할 수 있는 것 아닐까요? 굳이 스택과 큐, 리스트만 자료구조인가요?


    뻔하게 쓰여지는 스택과 큐, 리스트, 맵의 개념을 알고 있다면 data structure를 구성할수 있는 아이디어를 더 쉽게 얻을 수 있지 않을까요?

    (물론 위에서 사용한 자료구조가 trie 라고 이름 붙여진 놈이긴 합니다.. 그리고 당연히 자바 기본 collection 라이브러리에서는 없죠..)


    그리고 또 java lib에서 얻을수 없는게 머가 있을까요? 순환큐.circle queue.도 기본 자료구조에서는 없어요. 


    이렇듯 정말 java lib는 너무나 뻔하게 쓰여지는 자료구조만 있을 뿐이죠.


    물론 이것만 가지고도 충분하지 않냐라고 물을수 있겠습니다만.. 결국 제가 하고 싶은 말은 프로그램을 만들게 되면 어떻게든 우리는 객체간의 구조를 머리속에 그리게 되잖아요. 그게 자료구조인거죠..

    다들 자료구조는 거창한 거야.. 라고 말하는 듯한 뉘앙스를 받아서 제 생각은 그게 아니야 라고 말하고 싶었습니다.



    그리고... 알고리즘은 외우면 된다는 댓글은 정말로 인정하기 힘드네요.



    알고리즘 문제들을 보세요.. 과연 외워서 풀어지는 문제가 있을까요? 얘네들은 정말로 순발력, 응용력을 필요로 하죠.

    (당연한 얘기지만, 알고리즘 문제가 성능 이슈만을 다루는 문제만 있는 것이 아닙니다.)



    언제든, 제가 쓴 글에 대해서 잘못된 부분이 있다면 지적해주세요.




    정리하자면,  제 생각은 이렇게 정리됩니다.

    1. 패턴은 상급자가 지정해주기만 하면 된다.

    2. 패턴을 정의할 필요가 없는 개발자는 자신에게 주어진 문제만 해결하면 되는데, 이렇듯 문제를 푸는데 더 필요한 스킬은 자료구조/알고리즘이 될 것이다.

  • jachin
    27
    2017-06-09 02:16:03

    오랫동안 연락이 없다가, 페북에서 이 글의 공유를 통해 인사하게 되었습니다. fender 님.

    알고리즘에 대한 필요성 유무, 초급 프로그래머 분들의 다음 목표로서 알고리즘 학습의 개연성이 확실히 문제가 있기는 있습니다. 조금은 긴 이야기일지도 모르겠지만, 저는 프로그래밍 언어의 발달로 알고리즘 학습의 개연성이 엷어지고 있다고 생각합니다.

    최근에야 공부를 다시 하면서 알게된 것 중 하나는
    프로그래밍 언어가 존재함에도 프로그래밍 언어를 다시 만드는 이유가 메모리 제어를 효율적으로 하기 위한 것에 있다는 것과 그것이 프로그래밍 언어 존재의 이유라는 것입니다.

    여러 알고리즘이 '계산효율'을 위한 것이라고 알고 있게 된 데에는, '튜링머신'의 구조원리를 이용한 컴퓨터 발전이 지금까지 이어지고 있고, 그에 기반하여 컴퓨터 구조 연구, 알고리즘 연구 등이 이어져오면서 하나의 정형화 된 사실이 되었기 때문입니다. 

    최신의 컴파일러, 언어 가상머신, 인터프리터 등은 저희가 학부였을 때 배웠던 알고리즘의 내용을 이미 내포하고 있고, 프로그래밍 소스코드 상에서 비효율성을 띄는 문제가 있었어도 그것마저 효율적인 구조로 재해석하고 구현해주게 되었습니다.

    디자인 패턴은 그러한 프로그래밍 소스코드의 재해석을 가속화 시켜주는 데에 일조했다고 생각합니다.

    즉, 앞으로는 컴퓨터 구조나 알고리즘과 같은 내용이 시스템 프로그래밍이나, 표준 함수 구현, 라이브러리의 개발과 같은 저수준(Low End)의 내용이 될 것이라 생각합니다.

    그리고 저도 fender님의 의심은 당연하다고 생각합니다. 도서로 접할 수 있는 알고리즘 서적들의 내용들이 공학측면의 '왜' 라는 질문에 대답하고 있지 못한지 오래입니다. 이미 오래전 컴퓨터 구조와 파서 기술에서나 이야기 할 법한 효율에 대한 내용이 지금에도 계속 되고 있기 때문입니다.

    하지만, 적어도 지금 현재의 프로그래머들에게는 꼭 배워야 하는 부분이 아닐까 생각합니다. 지금은 알고리즘을 구현하는 일을 하는 프로그래머는 적어질 거라 예상합니다. 그 대신, 알고리즘을 이해한 프로그래머가 그 구현체를 선택해서 쓰는 일을 하게 될 거라 생각합니다. 그러기 위해 알아야 하는 내용이 되어가고 있는듯 합니다.

  • fender
    22k
    2017-06-09 05:03:30 작성 2017-06-09 06:04:24 수정됨

    와... 자고 일어나니 덧글이 엄청 많이 달렸네요 ㅎㅎ;; 일일이 인용해서 답글 달아드리지 못하는 점 양해 부탁드립니다.

    우선, 이 글의 핵심은 특히 중급 이하 단계에 있는 고급 언어 개발자들이 공부를 해야할 때 권장하고 싶은 우선순위에 대한 것이지, 알고리즘 자체가 필요 없다는 이야기가 아님을 다시 한 번 강조하고 싶습니다.

    여전히 알고리즘도 매우 중요하고, 조금이라도 빠르고 메모리를 적게 쓰는 방법을 찾는 것도 중요하고, 또 그런 방식에 대한 이론을 정립하는 것도 중요합니다.

    누군가가 꼭 해야할 일이지만 그 '누군가'가 이제 막 객체지향의 기본 정도를 익힌 고급 언어 개발자가 아니라는 것 뿐이고, 예컨대 머신러닝이 매우 중요한 시대이지만 머신러닝과 다른 분야에서 일한다고 수준 낮은 개발자가 아니라는 것 뿐입니다.

    다른 글에서도 적었지만, 저는 자료구조는 최소한 어떤 종류가 있고 어떤 맥락에서 무엇을 써야하는지 정도는 여전히 고급 언어 개발자에게도 기본 지식에 해당한다고 생각합니다. 그 점에 대해 문제제기를 한 적은 없습니다. 내부 구조를 뜯어보거나 직접 구현해보는 일이 필수적이고 우선 공부해야할 내용이 아니라는 정도의 생각입니다.

    그리고 알고리즘을 이해못하고 외우는 것이 말이 안되는 것이라면 그건 디자인 패턴이나, 좀 더 일반적으로 객체지향 기반의 설계도 마찬가지입니다. 아마 디자인 패턴은 고급 개발자가 정해주는 대로 하면 그만이라는 생각을 하신다면 객체지향적 설계 자체를 하지 않는 환경(현업 SI 대부분이 그럴 것 같습니다만...) 만 경험해보신 탓이 아닐까 싶습니다.

    이를 근거로 디자인 패턴의 중요성을 따지는 건 그냥 우리나라 SI에서 안쓰니 객체지향은 필요없다라는 것이나 마찬가지 이야기가 됩니다.

    데이터베이스 스키마부터 놓고 API 안만들고 스프링MVC 템플릿 도장 찍듯 페이지 추가하는 식의 프로젝트는 디자인패턴 몰라도 개발할 수 있지만 알고리즘 몰라도 얼마든지 할 수 있습니다.

    그리고 모든 것을 떠나서 그런 비정상적 환경에 적응하는 것을 궁극적 목표로 한다면 사실 애초에 이런 부류의 고민을 할 이유가 없다고 봅니다. 그냥 선배 개발자들하는 거 보고 똑같이 따라하면 되는 것이고 그러다보면 '통밥'이 생겨서 능숙하게 되면 그만일 것입니다.

    굳이 구분을 하자면, 고급 객체지향 언어에서 디자인 패턴은 프로그램을 설계하기 위해 알아야할 지식이고, 알고리즘은 보다 효율적인 구현을 위해, 또는 특정한 문제를 해결하기 위해 알아야할 지식입니다.

    그리고 알고리즘을 모르는 자바 개발자는 꽤 높은 수준까지 갈 수도 있지만, 디자인 패턴이나 객체지향을 능숙하게 쓰지 못하는 자바 개발자는 알고리즘에 아무리 통달해도 초급 수준을 벗어날 수 없습니다.

    물론 둘 다하면 좋고 둘 다 잘하는 개발자도 꽤 있을 겁니다. 그런데 자신이 선택한 기술을 능숙하게 다루기 위해 무엇이 필요하고 어떤 것이 보다 중요한지에 대한 스코프(scope)를 이해하지 못한 상태에서 덮어놓고 "가장 밑바닥부터 닥치는대로 다 공부해주겠어!"라고 덤비는 건 만용입니다.

    덧글: jachin // 잘 지내셨죠? 오랜만에 소식들어 저도 반갑습니다 ^^



  • 배고픈잠만보
    34
    2017-06-09 08:15:32

    그럼 알고리즘, 디자인패턴, 객체지향 등을 모두 공부를 한다고 가정한다면

    알고리즘보다는 디자인패턴이나 객체지향쪽에 좀 더 비중을 두는 편이 좋겠군요...!!

  • Be Head
    1k
    2017-06-09 08:55:50

    좋은 정보 감사합니다

    항상 잘 읽고만 있습니다..

  • kkey21a
    4k
    2017-06-09 09:11:49 작성 2017-06-09 09:13:19 수정됨

    전재형//

    우선 이미 제 다른 글에서 여러 알고리즘 문제들을 풀면서 문제 해결을 위한 일련의 절차나 문제를 푸는 방법등 개인 능력 향상에 도움을 줄 수 있다 밝혔습니다. 다만, 재형님께서 말씀하신 진짜로 필요한 일은 자신의 일을 구현하는 거라는 말씀을 하셨는데, 저 역시도 이 부분에는 공감합니다.


    그런 의미에서 이 부분과 알고리즘과 관련하여 한마디 더 하자면 본인이 푸신 여러 알고리즘 문제들 중에 실무에 직접적으로 쓰이는 경우가 얼마나 되셨는지 궁금합니다. 또한 내가 접해보지 않은 알고리즘이 있었다면, 그 때는 어떻게 해결하셨는지 궁금합니다. 제 개인적인 답을 먼저 해 보자면, 전 구글링했고 그 코드 응용해서 제 프로그램에 맞게 사용했습니다.

    다시 정리하자면, 자주 사용하는 알고리즘들은 어떤 것들이 있고 이에 대한 특징만 머릿 속에 있다라면 필요할 때 인터넷을 이용해 구현할 수 있다라는 것이 제 생각입니다.


    그렇다면 이번에는 특정 패턴의 경우는 어떨까요? 물론 알고리즘처럼 구글링해서 프로그램에 적용할 수도 있습니다. 그렇지만 아무래도 알고리즘 적용보다 단위도 크며 손이 많이 가지는 않았는지 궁금합니다. 그런데 이번에는 전체 프로그램을 객체지향으로 바꾼다면요? 알고리즘 처럼 쉽게 가능할까요?

    객체지향 프로그램을 하려면, 우선 이에 맞는 프로그램 설계가 우선시 되어야 하는데 실무에서 이런 프로그램 설계를 중요시 하지 않을 뿐더러 누구도 해주지 않습니다. 결국 그 프로그램을 만드는 이가 설계를 하고 개발을 하여야 하는데, 전혀 객체지향이나 디자인패턴에 대한 이해가 없다면 제대로 설계를 할 수 있을지 의문입니다.


    아무튼 오늘 조금 바쁜관계로 이만 글을 줄일까 합니다. 그럼, 좋은 하루되시길...

  • iops
    1k
    2017-06-09 09:34:12 작성 2017-06-09 09:35:16 수정됨

    알고리즘이 핫한 이유는 시험문제로 내기 좋기 때문이죠.

    뭐하나 만들라고 하긴 시간부족하고 알쏭달쏭한거 하나내면 사람 떨어뜨리기 좋죠.

    최근의 알고리즘은 그냥 개발자가 푸는 퀴즈? 정도의 의미밖에 없다고 생각합니다.


    알고리즘이 정 배우고 싶다면 머신러닝 알고리즘을 배우세요. 머신러닝은 알고리즘이 정말 중요합니다.

    그리고 향후에도 정말 유용하게 사용될 수 있습니다.

    (근데 머신러닝쪽도 사실 알고리즘 배워야하나에 대한 논란은 좀 있긴 하지만)


    그래도 정 알고리즘 하고 싶다면 자신이 쓰는언어에 기본적으로 뭐가 구현되어 있는지는 알고 했으면 좋겠습니다.

    java를 예로들면 java.lang 패키지에 뭐가 있는지는 기본적으로 알고 했음 좋겠습니다.

    소팅을 배우기 전에 자신이 쓰는 언어의 기본 정렬이 뭔지는 알고 했음 좋겠습니다.

    java의 경우 레거시가 아니면 TimSort를 사용합니다.

  • booiljoung
    47
    2017-06-09 09:38:24

    ㅎㅎ

    고급언어냐 저급언어냐의 문제가 아니라

    SI냐 아니냐의 차이가 아닐까요?

    DB는 DBA가 설계해줄테고

    쿼리문으로 관계형 DB에 데이터 넣고 빼고

    메시지 큐가 알아서 해줄테고

    딱히 알고리즘 필요 없겠죠  

    어제 밤 모 게임 커뮤니티에 올라온 질문은 알고리즘을 알아야 풀수 있는 문제 였습니다   언어는 c#이었고요.  컴포넌트 기반이라 딱히 디자인 패턴을 몰라도 별문제 없고요.

    케바케이고 분야 문제라고 봅니다.  

  • 더미
    15k
    2017-06-09 09:39:25

    알고리즘을 너무 어렵게 보시는게 아닌가요?

    알고리즘을 가르치거나 배우는 이유는

    문제를 해결하기 위한 방법같은걸 알기 위함입니다.

    처음부터 걷지도 못하는데 뛸 순 없잖아요?

  • fender
    22k
    2017-06-09 09:43:46 작성 2017-06-09 10:20:49 수정됨

    booiljoung // 물론 특정 알고리즘을 꼭 알아야만 풀 수 있는 문제는 꽤 있습니다.

    그런데 C#을 쓰면서 객체지향이나 디자인 패턴을 모르면 특정 문제를 못 푸는 게 아니라 그냥 설계 자체를 할 수 없고 남이 만든 API를 읽기도 어렵습니다.

    흔히 하는 잘못된 생각이 남이 만든 걸 그냥 쓰려면 문법만 알면 되고, 설계를 하려면 알고리즘 같은 기본을 알아야 한다는 것인데, 사실은 자바나 C# 같은 언어에서 패러다임 모르고 디자인 패턴 모르면 알고리즘을 얼마나 잘알던 간에 제대로 된 프로그램 설계를 할 수 없습니다.

    반면에 패러다임이나 디자인 패턴은 잘알지만 알고리즘을 모르면 설계는 맞지만 비효율적인 구현을 할 가능성이 있고, 어쩌면 특정 문제 해결을 위해 검색에 의존해야할 수는 있습니다.


    더미// 알고리즘을 '문제 해결을 위한 방법'이라고 넓게 정의한다면 디자인 패턴도 똑같습니다. 그 문제가 구현의 단위이냐 구조의 단위이냐의 차이일 뿐입니다:

    In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

  • 컴포지트
    2k
    2017-06-09 10:25:01

    좋은 의견입니다. 개발자 씨말리기 프로젝트에 참고할 수 있는 의견이군요. 개발자 양극화를 위한 좋은 의견 감사합니다. 제가 개인적으로 정상으로 생각하면 당연히 동의하지는 않지만요.

    어쩌면 그저 만들어진 API나 프레임워크를 갖다쓰는 사람이 있을 테고, 아예 코어를 개발하는 사람도 있을 텐데, 이런 다양성을 생각하면 그저 하나의 개발자 분류로 볼 때 개인 의견이라면 환영하지만, 일반적인 소양으로 본다면 아니라고 보거든요.

    -2
  • fender
    22k
    2017-06-09 10:28:58 작성 2017-06-09 10:36:42 수정됨

    컴포지트 // 바로 위에서 적었습니다만, 알고리즘만 알면 설계는 다 할 수 있고, 자바 같은 '응용 기술'은 어차피 남이 만들어 놓은 거 잘 가져다 쓰는 게 전부니까 마음만 먹으면 쉽게 배운다는 편견에서 비롯된 말씀이라고 생각합니다.

    20-30년 전에는 알고리즘 알고 C 포인터 잘 다루면 무서운게 없었는지 몰라도, 지금은 그런 이야기 하면 자바 스크립트 개발자들이 비웃는 세상입니다.

    알고리즘을 마스터 해도 디자인 패턴 모르면 말씀하신 프레임워크 코어 개발은 커녕 API보고 이해도 못하는 게 현실입니다.

  • iops
    1k
    2017-06-09 10:33:05

    컴포지트 / 작성자분이 알고리즘 아예 하지말라라고 한거도 아니고 우선순위만 얘기했는데

    양극화랑 씨말리기는 갑자기 왜 나온건가요. 너무 비아냥이 심하네요.

    알고리즘보다 디자인 패턴을 먼저하면 개발자가 씨가 마르나요?



  • 초오찌
    5k
    2017-06-09 10:36:04

    백프로 공감합니다

  • Mommoo
    901
    2017-06-09 10:44:33 작성 2017-06-09 10:49:07 수정됨

    fender  님 내용에 크게 공감합니다.

    저 역시도 언어의 패러다임을 열심히 공부하면서

    전반적인, 객체지향개념을 익혔습니다. 확실히 공부 할 수록, 코드 품질이 올라갈 뿐만 아니라,

    무언가 암묵적인 규칙(?) 과 같은 디자인 패턴등을 접하면서 코드 설계의 중요성을 알게 되었습니다.

    그 결과로 점점 눈이 트인다고 해야하나요,

    라이브러리나 다른사람의 코드를 객체지향의 장점중 하나인 구조적으로 읽을 수 있는 능력이 점점 생겼고,

    이해도가 확 달라진걸 느낄 수 있었습니다. 

    또한 알고리즘 역시 매우 중요하다는걸, 알고리즘 공부를 통해서가 아니라 fender님이 말씀하신 방법으로 

    공부를 하던 도중 깨닫게 되었습니다. 그래서 저는 처음 공부하시는 분들은  알고리즘 부터 하기 보다는 

    JAVA같은 객체지향언어를 하나 잡고 공부하는게 좋다고 생각합니다.

    알고리즘도 중요한걸 알게됬는지라, 시간날때 마다 필요한 알고리즘 공부도 하나씩 하고 있습니다. 

    하지만 비중은, 여전히 디자인패턴과 같은 구조적인 공부쪽에 많이 두고 있습니다.

    아직도, 미천한 실력이지만 과거에 아무것도 모르는 저랑 비교했을시, 많이 발전됨을 느낍니다.

    좋은글 감사합니다.

  • Dive_Drink_Develope
    5k
    2017-06-09 11:03:39

    알고리즘이라는 용어의 정의가 달라서 논쟁이 끝없이 반복되는 느낌이네요.


    CRUD만 알면 왠만한건 다 처리할수 있는 SI 쌩초급개발자 혹은 SM 입문자들에게는 말씀하신대로 디자인 패턴이 우선순위가 될수 있다고 봅니다.


    알고리즘을 그냥 자료구조에 이어지는 과목정도로 본다면

    외우면 되는 것 이라고 정의하시는 분들이 있을 것 같습니다.


    그런데 알고리즘을 강조하시는 대부분의 사람들(저를 포함)은 아마

    우리가 어떠한 현실세계의 문제를 해결하는데 있어서 그 과정을 컴퓨터의 입장에서 어떻게 기술하고 해결해나가야하는지 생각하는 능력을 키우는게 최우선이라고 보는게 아닐까요.

    또한 어떠한 형태의 문제들을 해결할 때는 어떤 방식이 효율적인지 미리 여러 방법론을 연구하고 정의해놓았는데(DP나 BFS DFS 같은 방식들) 그런 방법론을 알고 문제해결에 뛰어드는지 모르고 뛰어드는지도 같이 일할 사람을 평가하는데 중요한 항목이 될수 있죠.


    데이터 CRUD해서 화면찍어내는 초급 코더가 아니라면

    데이터의 생성과 조작에 필요한 알고리즘을 모른다면 디자인패턴이 무슨 소용인가요. 

    데이터를 불러온 다음에 어떻게 조작해야될지를 모르는데 무슨 문제를 해결할 수 있을까요.


    음....말하다보니 산으로 흘러가는 경향이 있네요. 적당히 걸러서 읽어주시면 감사하겠습니다.

    정서를 하고싶지만 이제 일을...ㅠ

  • namjals
    68
    2017-06-09 11:09:37
    공부 우선순위
  • fender
    22k
    2017-06-09 11:10:06 작성 2017-06-09 11:13:52 수정됨

    Dive_Drink_Develope// 위에서도 이야기했지만, 알고리즘이 무언가 '근본 원리'에 해당 하고 디자인 패턴은 보다 쉬운 '응용'에 해당하는 내용이 아닙니다.

    둘 다 문제를 해결하는 방법에 대한 고민이라는 부분에서는 동일하지만 서로 다루는 계층이 다를 뿐입니다.

    다시 말하면, '알고리즘보다 디자인패턴을 우선해라'라는 것이 '원리 같은 거 알 필요 없으니 활용이나 잘하라'라는 이야기가 아니라는 뜻입니다.

    오히려 자바나 C# 같은 언어를 하면서 알고리즘에 과도하게 비중을 두어 디자인 패턴을 무시하는 것이야 말로 원리를 무시하고 구현에만 집중하는 접근입니다. 그런 언어들은 '함수'를 죽 늘어놓고 내부 구현만 잘하면 끝나는 개념이 아니기 때문입니다.

    이건 정말 뿌리 깊고 흔하게 보는 편견인데 자바나 C#이 가장 널리 쓰이는 언어 대열에 합류한지 한참인 지금까지 없어지지 않는 건 무척 안타깝게 생각합니다.

  • iops
    1k
    2017-06-09 11:47:54

    농담으로 만일 신입이 입사를 했는데 알고리즘 배웠다고

    데이터를 정렬을 하려고 버블소트를 짜고있다던가

    데이터를 찾으려고 바이너리서치등을 짜고 있으면 

    오 저 개발자는 기본이 된 개발자구만 이라고 그럴까요 아니면 아니 그걸 왜 짜고있어! 소리가 나올까요.

    싱글톤, 팩토리 같은건 실무에서도 아직까지 많이 쓰고 짜니깐

    실용적인 측면에서 그런쪽을 먼저 배우는것이 저도 더 낫다고 생각합니다.

    (장난처럼 얘기했지만 사실 버블소트 얘기는 실화입니다)


  • kkey21a
    4k
    2017-06-09 11:58:55 작성 2017-06-09 12:18:39 수정됨

    조금 과장되게 짧게 표현해보면,


    프로그램 구조의 이해가 우선인지?

    프로그램 응용 능력이 우선인지?


    결국 이 두 선후 관계인데,

    이 글에 '고급 언어를 다루는 초급개발자' 라는 전제 조건이 이미 있죠. 

    위의 내용에 큰 문제가 없다면, 전 초보 개발자는 프로그램 구조의 이해가 선행되어야 한다고 생각합니다.



    booiljoung//

    SI 한번도 안 해보신듯 합니다.

    (비아냥 아니니, 오해 없으시길 바랍니다.)

    우선 SI에서 DBA가 DB설계 안 해줍니다. -ㅅ-

    프로그램 설계 역시 안 해줍니다. -ㅅ-

    그리고 특별한 공식 혹은 알고리즘이 필요하다면 요건 설계서에 설계자가 알려줍니다.

    물론 어떤 일이든 선후관계를 따진다면 웬만하지 않고서는 경우에 따라 다르겠지만, 윗 글에는 '고급 언어를 다루는 초급개발자'라는 전제 글이 있는 걸로 알고 있습니다.


  • 하마
    7k
    2017-06-09 12:50:13 작성 2020-07-08 08:36:15 수정됨

    이 글은


    알고리즘(자료구조) 등에 집중해야 할 사람은 없다 라고 주장하는 글이 아니며
    알고리즘(자료구조)등에 집중해야 할 사람도 있을 테지만  다른 것에 더 우선순위를 높여야하는 상황이 많아 졌다.
    옛날부터 전혀내려오던 모든 것을 밑바닥 부터 시작하자 라는 것에 대한 의심을 품어보자!! 

    즉 세상은 다양해 졌다. 다양해 진 만큼 집중해야 할 대상이 달라 졌다.라고 주장하는 글이 므로
    사실 저것 만이라면 전혀 논쟁의 이유가 없어 보입니다. 너무 맞는 말이기 때문이죠.
    더군다나 이게 맞다라기보다는 경각심 차원의 글이니까~ 매우 동감합니다. 

    다만 자료구조,알고리즘은 모든 개발자의 기본 소양이다. 무조건 어느 정도 해야한다. 하지말아도 된다 혹은 신경 덜 쓰고, 더 중요한것에 신경 쓰자라는 것에 대해서는 물컵의 물을 바라보는 시각차라 답이 없을테지요. "어느정도" 라는 게 어느정도냐? 는 사람마다 다를 테니까요~

    개인적으로는 "하지 않아도 된다" 라는 사람이 있다면 그것에는 동의하기 어렵구요. (참고로 fender님은 그러한 주장을 하고 있지 않습니다)  라이브러리에서 제공되는 것들에 대한 이해를 위한 기본소양은 개발자에게 반드시 필요할 것이며, (최소한 큐,스택,힙,맵,트리에 대한 이해) 추가적으로 자신이 다루는 분야 (DB 라면 R-tree) 에 대한 작동 방식은 우선순위 높여 공부하고 이해해야 한다고 생각합니다. 

  • Dive_Drink_Develope
    5k
    2017-06-09 12:51:10

    inyl // 사실이라면 맙소사네요. 그리고 여전히 소트나 서치를 "짤줄안다"는 개념에 알고리즘을 가둬두시는 것같습니다. 데이터에서 정렬이 필요한지, 바이너리서치가 적합한지, 해쉬가 적합한지를 파악하는 능력이 알고리즘이라고 생각합니다.


    fender // 초급개발자가 기존소스를 파악하거나 하는데 있어서 패턴을 알때와 모를때 습득속도에 차이가 나리라는 것에는 동의합니다. 그런데 소스를 짤 때 기본적인 클래스 구조등은 위에서 설계해주고 내부 처리로직 구현부터 시작하지 않나요?



  • 전재형
    4k
    2017-06-09 12:58:36

    끝없이 같은 말을 뒤풀이하게 될것같아서 겁이 나네요.

    정말 마지막으로 제 의견을 정리하면, "알고리즘을 문제를 푸는 방법론"이라 정의한다면, "패턴 이후에 공부해야하는 과목이 아니다"


    키씨... 알고리즘을 어디다 쓰냐고 물으셨죠?..

    정말 여기저기다 가져다 붙일수 있죠. 이건 코드를 짜는 작은 단위의 방법이니까요...

    패턴 몰라도 절차적으로 쭉 짜면 프로그램이 왼성되겠죠? 알고리즘도 거의 비슷한 맥락인데 더 작은 규모일뿐이라고 말씀드리고 싶네요.

  • fender
    22k
    2017-06-09 13:04:11 작성 2017-06-09 13:14:21 수정됨

    Dive_Drink_Develope// 말씀하신 위에서 구조를 정해주는 상황은 디자인 패턴보다는 아키텍쳐 수준의 이야기에 조금 더 적합한 이야기가 아닐까 생각합니다.

    그리고 위에서도 몇 번 언급했지만, 현업에서 스프링MVC 같은 구조를 정해놓고 어떠한 API 수준의 설계도 없이 오직 SQL에만 의존해서 시스템을 만들어가는 것은 우리나라 SI 환경의 특수한 문제입니다.

    그것을 일반적인 상황으로 가정해서도 안되고, 그런 환경이라면 객체지향도 무의미하지만 알고리즘도 무의미하긴 마찬가지라고 봅니다.

    모든 것을 떠나서, 프로그래밍은 기본적으로 작은 단위에서 큰 단위의 시스템을 쌓아가는 작업이라는 점은 쉽게 동의하실 것 같습니다.

    그리고 자바나 C# 같은 패러다임의 언어에선 그런 작업을 위한 가장 기본이 되는 단위가 클래스라는 것이고, 그렇기 때문에 어떻게 그런 단위 블록을 쌓아나가야 하는 지를 배우는 것이 매우 중요한 기본 지식이 된다는 주장일 뿐입니다.


    전재형// 토론의 맥락을 따져야 할 문제가 아닌가 싶습니다. 몇 차례 이야기했지만, 알고리즘을 그냥 '문제 푸는 방법' 같이 최대한 확대 해석하면 결국 필요한 것이다라는 논리에선 생산적인 토론을 이끌어 내기 어렵습니다.

    4대강 정책이 잘됐는지 못됐는지 토론을 한다면 구체적으로 환경에 미치는 영향등을 이야기해야지, 이를 일반화해서 '어차피 치수 정책은 국가에 필요한 것이다'라고 결론을 내고 만다면 토론에 무슨 의미가 있을까요?

    이 논의의 맥락에서 이야기하는 '알고리즘'은 예컨대 이 곳에서 흔히 알고리즘 스터디 같은 것을 한다면 보게되는 '백준 사이트'나 전산 관련 학과에서 교재로 사용하는 그런 구체적 내용을 이야기하는 것입니다.

  • kkey21a
    4k
    2017-06-09 13:08:01

    전재형//

    재형님 말씀 100%는 아니지만, 어느 정도 이해했고 서로의 의견차가 있다는 걸로 하고 이쯤에서 저와는 마무리하시는걸로 하시죠.

    아무튼 즐거운 하루되세요.


    ALL//

    fender님께서 글을 잘 쓰시닌깐 -1점 주고 시작합시다. ㅎㅎ

  • 그래하자고
    127
    2017-06-09 13:08:08 작성 2017-06-09 13:13:38 수정됨

    엄청난 토론들이 오고가고 있는데 제가 글을 써도 될까 모르겟습니다.. ㅎㅎ

    fender님이 이야기하신것은 알고리즘을 공부할 필요가 없다! 라는것이 아니라 초보 개발자들에게 시간은 한정되어있고

    공부해야할것은 엄청나게 많은데 '초보개발자'들의 기준에서 '우선순위'는 무엇인가에 대해 이야기하신것으로 저는

    받아들였는데 다른분들은 아닌가보네요 ㅎㅎ

    취준생의 입장에서 현재 많은 기업들이 알고리즘 시험을 보고있다보니 이런 토론이 오갈수있다 생각합니다.

    요즘 여러 세미나를 가면서 느낀것은 프로그램의 본질은 '문제를 해결한다'인데 이것은 '문제를 해결하기 위해 프로그램을 만들어서 해결한다'의 관점에서는 디자인패턴이 알고리즘보다 좀더 유용할거같습니다. 물론 성능의 문제가 나오면 그땐 알고리즘도 꼭 필요하구요. 

    이 글은 시간은 한정되어있고 초급개발자가 공부할것은 많은데 우선 개발을 한다는 관점에서 무엇이 좀 더 유용할까? 

    라는 관점에서 읽으면 매우 유용할것 같습니다. 알고리즘, 디자인패턴 둘 다 중요하고 우리 모두는 그것을 알고있다고 생각합니다.


    fender님 항상 좋은 글 감사합니다. 도움이되는 많은 글을 써주셧는데 저는 아직 가르쳐주신것들을 이해하는데도

    많은 시간이 걸리고 있네요 ㅎㅎ 항상 정진하도록 하겠습니다.

  • larcyuki
    1k
    2017-06-09 13:09:31

    알고리즘은 모든 곳에 쓰일 수 있습니다.

    다만 안쓰고도 할 수 있을 뿐이죠.

  • 더미
    15k
    2017-06-09 13:13:28

    네 맞는 말이죠.

    다만  전산과목에 대해서 말씀하셔서 드린 말입니다.


  • 전재형
    4k
    2017-06-09 13:19:01

    알고리즘에는 구체적인 방법들이 존재합니다.

    "DP나 BFS DFS 같은 방식들"이라고 drive씨께서 말하셨는데, 이런 구체적인 방법론을 저역시도 중요하다고 얘기하였습니다.


    이야기의 중심논제가 "패턴을 알고리즘에 우선하여 공부해야하는가"라는 질문이 맞다면, 저는 더미씨와 같은 파?라고 할 수 있는 것이죠 :)


    이제 주말입니다. 모두 즐거운 주말 보내세요.

    저는 주말에도 일해야 겠군요.    ;(

    -1
  • 전재형
    4k
    2017-06-09 13:23:01

    그리고 사실 이야기가 진행될 수록 기분이 좋습니다. ㅎㅎ

    알고리즘 정말 필요없잖아에서 점점 그래도 최소한 고급개발자가 되려면 알아야하는 필수 소양이지 쪽으로 의견들이 돌아서고 있는 것처럼 느껴져서요.



    -1
  • 그래하자고
    127
    2017-06-09 13:26:40

    전재형 // 제가 이 글을 읽을때 그 누구도 알고리즘은 정말 필요없잖아 라는 글은 본적이 없는데 글이 너무 공격적이신거같습니다.. 알고리즘 당연히 필요하지요; 근데 이 글 중 어디에서 알고리즘이 필요없다는 말이 나오는것인가요?

  • iops
    1k
    2017-06-09 13:26:47

    Dive_Drink_Develope / 저도 위의 예는 반장난으로 적은거니 크게 신경쓰지 않으셔도 됩니다.

    서로의 의견차는 있을수 있다고 생각합니다. 알고리즘을 어떤 로직이 적합한지 파악하는 능력이라고 해버리면

    알고리즘이란 단어가 너무 추상적이지 않나요?

    그러면 알고리즘이 아닌게 아예 없지 않잖아요. 사실 디자인패턴도 알고리즘이고 자료형도 알고리즘이되고

    유닛 테스트도 알고리즘이 되겠네요. 그런의미의 알고리즘은 저뿐만 아니라 누구나 반대할 이유가 없죠.


    말그대로 논란이 되는거도 이 알고리즘이란 단어 자체가 사실 너무 추상적이여서 발생한다고 생각합니다.

    서로 머리속에서 제각기 다른생각을 하고 있어서 토론이 끝이 안난다고 보여지고요

  • booiljoung
    47
    2017-06-09 14:18:02

    설계는 10년 20년 경험을 해도 어렵지 않나요?

    문제가 같다 하여도 정답이 같지도 않고요.

    디자인 패턴을 배우면 설계를 잘 할까요?

    알고리즘이나 자료구조도 못떼고 디자인 패턴을 배운 신입에게 설계를 맡긴다는게 넌센스 같습니다.

    설계는 10년 20년차 개발자에게 맡기고, 신입들은 그 설계를 보고 배우면서 내부 로직을 구현하는게, 교육 과정을 줄이고 훈련 비용을 줄여서, 개발자 수급면에서 더 낫다고 봅니다.

    신입들이 설계를 제대로 해낼때까지 훈련을 해야 한다면 10년 20년까지 학교에서 공부해야 할 것입니다.

  • fender
    22k
    2017-06-09 14:27:32 작성 2017-06-09 14:31:07 수정됨

    booiljoung// 여기서 말하는 '설계'는 SI 프로젝트 같은데서 PL이 전체 사이트 아키텍쳐를 정하고 그런 걸 이야기하는 것이 아닙니다.

    개발을 한다면 무언가 계획이 필요하고, 그것이 바로 설계입니다. 그리고 자바나 C# 같은 패러다임의 언어에선 어떤 클래스를 어떤 구조로 추가할지, 그리고 어떤 메서드를 선언할지 등을 고민하는 것이 여기에 해당하고, 그런 부분에 대한 방향을 잡아주는 것이 디자인 패턴입니다.

    프로그램을 짜는 것이 10년, 20년차 개발자가 모든 클래스 목록을 만들고 빈 메서드까지 템플릿을 다 마련해놓으면 나머지 개발자들은 그 안에다가 조건문, 반복문만 채워 넣으면 된다는 정도로 생각하시는 것이 아니라면, 이런 의미의 설계는 연차와 관계없이 개발자의 기본 지식이라는 데 동의하실 것 같습니다.

    여담이지만, 우리나라의 자바 기반 SI 프로젝트 환경이 지극히 비정상적이라는 것은 객체지향 언어를 사용하면서 그런 설계의 여지를 거의 없애버리고 모든 것을 SQL에 의존하는 방향으로 개발을 진행하기 때문입니다.

    그러다보니 객체지향에서 'API를 설계한다'라는 개념 자체를 생소해하는 분들이 많고, '설계'의 의미를 아키텍트가 무슨 프레임워크를 사용할지 무슨 하드웨어를 쓸지 등을 정하는 것으로 착각하는 경우가 많은게 아닌가 싶습니다.


  • 전재형
    4k
    2017-06-09 15:00:03

    그래하자고 / 제가 분명히 알고리즘 필요없잖아. 라고 말하는듯한 늬앙스를 받은 댓글이 몇 분명히 존재합니다. 논쟁이 될까 걱정되어서 더 적지 않습니다.


    inyl / drive씨가 말하는 알고리즘의 정의는 분명 더 구체적인 방법론을 말하는 것처럼 생각됩니다.

    그래서 그 용어까지 밝히셨죠. 보통 알고리즘을 공부한다고 말할때는, 도메인의 로직 공부와는 다른 부분이 존재합니다. 

    딥러닝을 공부한다고 할때, 분명 알고리즘과 공통되는 성질이 있지만 굳이 알고리즘을 공부한다고 인하죠. 단지 딥러닝의 도메인을 공부하는 것이고 딥러닝 공부한다라고 필드를 밝히죠.

    하지만 알고리즘을 공부한다고 표현할 때는. 재귀. 백트래킹 동적 프로그래밍 등에 대해서 체화되도록 "훈련"한다가 더 큰 것같네요

  • iops
    1k
    2017-06-09 15:31:21

    전재형 / 머신러닝 알고리즘 공부한다고 합니다.

    구글에 머신러닝 까지만 쳐도 알고리즘이 자동완성으로 뜨는데요

    책제목에도 있는데

    http://www.yes24.com/24/Goods/29229139?Acode=101

  • kkey21a
    4k
    2017-06-09 15:47:23 작성 2017-06-09 16:02:17 수정됨

    booiljoung//

    디자인 패턴을 배우면 설계를 잘 할까? 물으시닌깐, 몇 마디 더 해볼까 합니다.

    우선 제가 이야기 하고자 한 프로그램 설계는 전체 어플리케이션의 큰 아키텍쳐만을 이야기 하고자 함은 아니었습니다. 이에 대해 fender님께서 잘 설명해 주신 듯 하여 이 부분은 생략하고자 합니다.

     대신해서 제가 지금 이야기하고자 하는 것은 디자인 패턴을 배우면 설계를 잘 할 수 있을까? 라는 원초적인 질문에 답을 해보고자 합니다.


    우선 디자인 패턴이란?

    디자인 패턴(Design pattern)은 건축학 및 컴퓨터 과학에서 사용되는 용어로, 설계 문제에 대한 해답을 문서화하기위해 고안된 형식 방법이다.

    (출처 - 위키백과)


    다시 말해, 많은 숙련된 개발자들이 설계를 하고 프로그램을 만들면서 발생한 설계 문제에 대한 해답을 문서화하기 위한 하나의 방법이라는 겁니다.

    또한, 이러한 패턴들을 만들면서 보다 더 프로그램 설계를 유연하게 하여, 변화에 쉽게 대응할 수 있도록 만든 것도 사실입니다.


    위 내용이 적어도 틀리지 않았다면, 개인의 역량차는 있더라도 적어도 디자인 패턴은 설계에 도움이되지 않는다라고는 말하지 못할 것 같습니다.


    PS

    설계라는 것이 어떤 특정한 분야만 많이 알거나 잘 안다고 하여 꼭 잘 한다고 할 수는 없는 분야 이닌깐요.

  • fender
    22k
    2017-06-09 16:14:02

    여담입니다만, 알고리즘의 중요성을 말씀하신 분들의 의견 중 알고리즘을 배우면 코드의 시간, 공간 복잡성을 최적화하는 방법을 이해할 수 있다라는 내용이 있었습니다.

    이는 분명히 충분히 공감할 수 있는 내용입니다만, 디자인 패턴을 공부하는 목적 역시 한 편으로는 SOLID 원칙(실제 이런 이름으로 정리된 건 GoF가 나온 후입니다만 핵심은 일맥상통하기 때문에 예로 들었습니다) 같은 객체지향을 다루는 기본 원리를 이해하기 위한 것임을 감안해야 합니다.

    디자인 패턴은 흔히 접하는 문제에 대한 반복되는 해법을 정리한 것인데, 왜 그것이 문제가 되고 왜 그런 해법이 더 나은 방법인지를 깨닫는 것은 바로 그런 원칙을 배우는 과정이 되는 것입니다.

    그렇게 본다면 결국 알고리즘과 디자인 패턴의 차이는 구문 단위에서 데이터를 다루고 코드 흐름을 제어하는 문제에서의 기본을 다루는지, 아니면 메서드나 클래스 계층 단위의 코드를 구성하는 문제에서의 기본을 다루는지의 차이일 뿐입니다.

    이런 전제로, 제가 자바나 C#과 같은 언어를 주력으로 하는 개발자들에게 디자인 패턴을 배우는 데 더 무게를 두어야 한다고 이야기하는 건, 그런 패러다임의 언어는 기본적으로 클래스 계층 단위를 조합해서 문제를 해결하라고 만든 도구이기 때문입니다.

    그리고 그런 언어로 다루는 스프링 프레임워크 같은 도구 역시 같은 관점에서 설계되고 구현된 것이기 때문에, 그런 기술을 주력으로 다루는 개발자라면 디자인 패턴을 이해하는 것이 필수적인 소양이 되는 것입니다.

    물론 자바나 C# 개발자가 알고리즘을 배우면 더 기초가 탄탄해지는 것은 분명합니다. 하지만 핵심은, 만일 공부에 같은 시간을 투자한다면, 알고리즘 퀴즈를 풀 줄 알지만 자바나 C#을 C 언어처럼 작성하는 개발자가 되느니 차라리 객체지향적인 코드를 작성할 줄 알지만 알고리즘 문제는 검색이나 기존 라이브러리에 의존하는 개발자가 되는 게 백 배 낫다는 것입니다.

    '알면 좋은' 내용을 공부하는 건 적어도 내 분야에서 '모르면 안되는' 내용이 무엇이 있는지 범위부터 파악하고 생각해도 늦지 않습니다.

  • 전재형
    4k
    2017-06-09 16:32:24

    inkl // 당연히.. 머신러닝을 공부하면 해당 도메인에서 사용되는 알고리즘을 공부하게 되죠.

    하지만, 그게 일반적인 알고리즘은 아닙니다.

    도메인에 특화된 로직 조합인 것이죠.


    일반적으로 알고리즘 공부한다고 누가 말하는 사람이 있다면,  딱 두가지 부류이겠죠.

    첫번째는 시험을 위해 잘알려진 알고리즘 기법을 외운다.

    두번째는 앞서 말한 것처럼 논리구조, 방법론을 훈련한다.


    스프링을 얘기할 때. 누구나 디자인 패턴을 얘기하지만. 디자인패턴=스프링이라고 생각하는 것이 아닌 것과 동일한 말일테죠.

    디자인패턴중에 일부 패턴이 스프링을 개발하는데 사용, 혹은 응용되었다.

    이런 ㅇ이야기에요.

  • iops
    1k
    2017-06-09 17:13:41

    전재형 / 

    위에 제가 쓴글 다시 봐보세요 제가 "머신러닝 알고리즘" 이라고 적었잖아요

    머신러닝 = 알고리즘 이라고 한적도 없는데 왜 디자인패턴 = 스프링은 갑자기 왜 말씀하신거죠?

    당연히 디자인패턴 != 스프링 이고 머신러닝 != 알고리즘이죠. 


    그리고 저는 '알고리즘이란 단어 자체가 사실 너무 추상적이여서 토론이 끝이 안난다' 라고 글도 남겼었습니다.

    그렇게 "일반적으로"라는 단어를 쓰면서 딱 끊어버리면 토론이 끝날래야 끝날수가 없겠네요.

  • urstory
    12
    2017-06-09 17:16:00

    전산학과 졸업생들은 선행학습을 많이 했으니깐 유리할 수 있지만.... 개발이라는 것이 알고리즘만 잘안다고 되는게 

    아니죠. 요즘같은 세상엔 커뮤니케이션 능력이 더 중요할 수도 있으니깐요. 알고리즘은 잘아는데 소통안되는 사람도 많이 봤습니다. 이런건 다 개인의 경험에 따라 다른 판단이 있을 수 있을것 같아요.

    모든 것을 선행학습 할 수 없기 때문에..... 개발하다가 필요한 알고리즘이 있으면 그때 공부하고.... 계속 공부/개발 을 반복하는 거 아닐까 합니다.

    공부하는 내용이 알고리즘일수도 있고, 패턴일수도 있고, 다른 사람이 작성한 소스일수도 있고....... 안 중요한게 있나요?


    그리고.... 기본지식이라는 것도 파고들어가면 끝도 없습니다. 아트 오브 프로그래밍 이런건 그냥 수학책이엥요.... 그정도는 봐야 알고리즘을 학습했다고 말하는 사람도 있을 수 있죠. 분야마다 그러한 내용이 필요한 경우도 있고, 없는 경우도 있습니다.

    자신의 분야의 최신 트랜드, 기본적인 지식 등을 꾸준히 탐하면서 개발하는 사람이 젤 잘하는 것 같아요. 

  • Dive_Drink_Develope
    5k
    2017-06-09 18:23:41

    전재형  // drive 말고...dive입니다..ㅠㅠ

  • Taewoong La
    553
    2017-06-09 21:45:55

    실무 경력은 오래되지 않았지만 공부는 13년 째하고 있는 사람입니다.

    저는 글쓰신 fender님의 의견에 전적으로 동의합니다.

    알고리즘은 문제를 해결하기 위한 유한한 집합일 뿐이죠.

    자료구조는 현실의 데이터를 메모리라는 1차원의 공간에 어떻게 효율적으로 저장할까 라는 것에 불과합니다.

    알고리즘 문제를 풀 때 자료구조나 알고리즘에 대한 지식이 전혀 없더라도 논리적으로 사고할 수 있다면 문제를 풀 수 있습니다. 제가 그랬습니다. 정보올림피아드에서 금상도 탔으니까요. 근거없는 이야기도 아닙니다.


    저는 알고리즘을 수학의 인수분해에 비유하기를 좋아하는데요.

    a^2 + 2ab + b^2 = (a + b)^2 이라는 공식이 있을 때, 좌항을 쉽게 빠르게 효율적으로 푸려면 우항을 알아두는게 좋습니다. 그런데 대부분 그냥 외우죠. 이럴 때 무슨 알고리즘을 쓰는구나, 저럴 때 무슨 알고리즘을 쓰는구나.

    우항을 몰라도 좌항만으로도 값을 도출할 수 있습니다. 그냥 곱셈, 덧셈 하면 되잖아요.

    당장 신입들이 중급 이상으로 올라가기 위해서는 자료구조, 알고리즘이 당연히 중요하겠지만, 강제로 선행되서는 안된다고 생각합니다. 필요를 느끼고, 그에 맞게 공부를 하는게 맞지 않을까요.

  • Taewoong La
    553
    2017-06-09 21:53:06

    a[0] = 3

    a[1] = 4

    a[2] = 2

    a[3] = 1

    a[4] = -1


    위의 배열에서 a[i] = K 라고 했을 때, K는 다음 인덱스를 가리킵니다.

    a[0] = 3은 a[3]을 가리키는 것이죠.

    이를 쭉 타고 갔을 때 -1을 만나면 종료됩니다.

    -1까지의 길이를 구하는 프로그램을 작성하는 문제가 있다고 생각해보겠습니다.


    어떤 알고리즘을 써야지, 어떤 자료구조를 써야지 라는게 먼저 떠오르시나요?

    저는 그냥

    int a[5] = { 3, 4, 2, 1, -1 };

    int len = 1;

    int i = 0;

    while (a[i] != -1) {

    i = a[i];

    len++;

    }

    이렇게 풀면 되겠구나 하고 생각합니다. (재귀를 써서 풀 수도 있겠죠.)

    이게 무슨 자료구조를 써야하고 무슨 알고리즘을 써야하는지 모릅니다.

    그런데 이런 형식을 쓰면 중간중간 인덱스 삽입과 삭제가 쉬워질 것 같다는 생각이 듭니다.


    링크드리스트죠.


    알고리즘 문제는 내가 알고리즘, 자료구조 열심히 했으니까 시험해봐야지! 라는 취지로 접근하면 안된다고 생각합니다.

    이러한 문제를 풀었을 때, 이걸 실무에 어떻게 적용할 수 있을까? 라는 취지로 접근하는게 맞다고 봅니다.

  • 전재형
    4k
    2017-06-09 23:38:42

    inyl // 


    머신러닝 알고리즘 공부한다고 합니다.
    구글에 머신러닝 까지만 쳐도 알고리즘이 자동완성으로 뜨는데요

    위 댓글을 보는 누군가는 머신러닝=알고리즘이라고 말하고 싶은가보구나 라고 생각할수도 있는 거죠.


    저는 '알고리즘이란 단어 자체가 사실 너무 추상적이여서 토론이 끝이 안난다' 라고 글도 남겼었습니다.

    굳이 논쟁하고 싶지 않으나, 게시한 의견에 대해서 그렇게 받아드리시면, 제가 왜 그렇게 생각했고, 일반적인 알고리즘이 무엇을 말하는거고 당신이 말한 알고리즘의 뉘앙스는 무엇이었고. 이렇게 논쟁이 전개될수 밖에 없을 듯하네요.


    https://ko.wikipedia.org/wiki/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98

    우리가 쓰는 용어에 일반적인 통용되는 뉘앙스가 없고, 다들 각기 다른 정의를 가지고 말한다고 가정한다면, 말이란것자체를 할 필요가 없겠죠.

    하지만 우리들이 일반적으로 사용되는  용례는 있다고 생각하며, 그 용례가 저는 위키피디아의 의견과 비슷한 맥락으로 정의하고 있습니다.


    inyl 씨가 아니라고 말하고, 나는 다른 정의를 가지고 있고, "알고리즘" 이라는 단어를 들었을 때, 저런걸 떠올리지 않아라고 말씀하신다면, 굳이 다른 말 안하겠습니다.


    서로 다른 대상을 바라보는데 말을 해 무엇하겠씁니까 


    -1
  • 전재형
    4k
    2017-06-09 23:40:38 작성 2017-06-09 23:42:18 수정됨

    그런 그렇고.. 큐 스택에서 시작된 이야기가... 벌써 뷰가 10K군요..



    Dive_Drink_Develope // 이제까지 폰으로 한번씩 보고 댓글 달고 그러고 있어서 ㅎㅎ. 잘못 읽었네요. 

  • 동목경
    142
    2017-06-10 00:02:47

    글쓴분께서 난독증 있는 사람 때문에 고생이 많으시네요

    저는 아무리 읽어도 글의 요지가 알고리즘이 필요없다는게 아니라

    막 성장하려는 개발자들에게 어떤 것이 더 필요한 것인가 선후관계를 말하려고 하신것 같은데..

    알고리즘 디자인패턴 객체지향보다 글읽는 법부터 배우는게 먼저라는 생각이 드네요


  • 욥욥욥
    939
    2017-06-10 01:19:30

    댓글 많네요 고생들 많으십니다 ㅎㅎ

    알고리즘 중요하지 않다 비슷하게 말하기만 해바란식으로 벼르고 있는 분들이 있죠.

    이런분들 특징이 그런내용이 아닌데도 알고리즘 단어만 나오면 바로 흥분하고 치고 나오십니다.

    댓글 계속 달리지만 그런내용 아니니 진정하시고요..

    그나저나 수백대 서버의 고속 동기화가 없는 프로젝트는 허접한 거라는거에 급우울..


  • Taetrees
    550
    2017-06-10 01:57:53

    이미 이 주제는 몇 번 있었어서 전재형님과 fender님의 대화가 오갈거라고 예상을 했는데 역시나 그렇군요.

    뭐, 저는 길벗님 말씀처럼 알고리즘의 중요성을 강조하는 입장인데 길벗님처럼 말해서는 사람을 설득하기 힘들다고 봅니다.

    일단 오독하신점도 있고 솔직히 까라면 깔 내용이 엄청 많은데 딱 한마디로 하자면 상대적 비교와 내로남불의 원리로 말하고 있습니다.

    본인의 경험에서 나오는 이야기는 아주 진리인척 생각하시는 것 같은데 님 글도 주장입니다.

    상대적 비교는 자랑이 될까 딱히 언급하지는 않지만 사람을 돈, 점수로 비교하는 짓은 사람이 가장 듣기 싫어합니다. 또한 너무 자본주의에 찌든 사고에요.

    알고리즘을 중요성을 강조하시려고 했으면 좀 더 설득하기 쉬운 '논리'로 해주셨어야 한다봅니다.

    반대 의견자를 '무시'하는 태도로는 주장이 먹히지 않습니다.

    적합한 알고리즘을 구현해보세요.

  • fender
    22k
    2017-06-10 06:04:13 작성 2017-06-11 15:05:46 수정됨

    [삭제된 글에 대한 답글입니다] // 여전히 쓰신 내용의 절반 쯤은 지인 자랑, 경력 자랑으로 채우시는 걸 보니 공연히 덧글 달았나 하는 생각부터 듭니다.

    저 같으면 그 시간에 우선 본문과 덧글부터 읽어보고 이게 정말 '알고리즘 따위 아무 필요 없다'는 주장의 글인지, 아니면 구체적으로 자바나 C#과 같은 패러다임의 고급언어를 처음 배우는 분들이 패러다임이나 디자인패턴보다 알고리즘을 우선 공부해야 할 필요가 없다고 이야기하는 글인지부터 제대로 파악할 것 같습니다.

    그리고 '한 때 나도 그렇게 구현에만 몰입했다'고 하면서 역시 본인 자랑을 늘어놓으시는 데 도대체 제가 언제 이론적 배경이 없이 구현만 잘하면 된다는 주장 따위를 했던가요?

    참고로, 디자인패턴과 알고리즘의 가장 큰 차이 중 하나가 후자가 구문 단위의 보다 구체적인 구현 방식을 다룬다면, 전자는 보다 큰 구조적 단위의 추상적 설계를 다룬다는 것입니다:


    도대체 무슨 근거로 알고리즘은 기본이고 디자인 패턴은 실무에서 쓰는 구현 수준의 응용 기술이라고 생각하시는지 모르겠습니다. 오히려 알고리즘은 디자인 패턴에 비해 매우 구체적인, 그리고 특화된 문제의 구현 기법을 다루는 분야입니다.

    그리고 알고리즘이나 디자인 패턴 말고도 개발과 직간접적으로 연결된 학술적 이론 지식은 많습니다. 그 종류나 숫자가 더 이상 개발자 한 명이 학부에서 모두 섭렵하고 실무에 들어가는 것이 어려울 만큼 방대하다는 게 문제일 뿐입니다.

    참고로 그런 종류의 전문화나 세분화는 어느 분야에서나 관찰할 수 있습니다. 17세기말 뉴튼(Isaac Newton)이 중력에 대한 이론을 처음 발표했던 저서의 이름은 '자연철학의 수학적 원리(Philosophiæ Naturalis Principia Mathematica)' 였습니다. 당시에는, 그리고 그 후로도 상당한 기간까지 모든 학문 분야는 철학의 분과로 인식되었고, 지식인이라면 당대의 거의 모든 분야의 지적 성과를 두루 섭렵하고 이해할 수 있었습니다.

    그러던 것이 지금은 같은 물리학자라도 양자역학을 전공한 학자와 유체역학을 전공한 학자 간에 별로 할 수 있는 이야기가 없는 시대가 되었을 뿐입니다.

    개발 분야에서도, 2-30년전에는 C언어만 알면 못하는 분야가 없었고, 10-15년 전 쯤에는 자바스크립트는 굳이 따로 배우지 않아도 누구나 할 수 있는 기술이었다면, 지금은 C언어를 아무리 잘해도 자바 스크립트를 장시간 공부하지 않으면 자바 스크립트 개발자들이 무슨 이야기를 하는지도 이해하지 못할 만큼 복잡한 독립 분야가 되었다는 점에서 비슷한 흐름을 확인할 수 있습니다.

    주니어 개발자 입장을 이해해야한다고, 그런 입장에서 무엇이 더 중요하냐고 질문하시는데, 오히려 그런 입문 단계의 개발자의 입장을 배려 하니까 이런 글을 쓰게 된 것입니다.

    님 생각엔 비전공자로 막 취업을 고민 중이거나 아니면 국비지원 학원 등을 통해 기본기도 쌓지 못하고 이미 실무에 투입되어 과중한 업무에 시달리는 개발자들이 개발 공부를 위해 얼마나 시간을 투자할 수 있을 것 같나요?

    님이 바이블 처럼 이야기하는 '프로그래밍의 기술(The Art of Computer Programming)'을 그런 분들이 완독하고 이해하는 데 얼마나 시간이 걸릴 것 같습니까? 그리고 더 중요하게, 그 책을 완독하면 자바나 C# 같은 언어로 복잡한 시스템을 구축하고 이해하는 데 얼마나 큰 도움을 받을 수 있나요?

    아시겠지만, 그 책이 처음 나온 건 지금부터 대략 반 세기 전입니다. 개발 분야에서 5년이면 새로운 언어와 프레임워크가 생겨날 기간이고, 50년이라는 시간은 앞서 말한 전문화, 세분화, 계층화가 진행되면 새로운 전문 분야와 패러다임으로 개발 분야가 천지개벽을 해도 열 번을 할 기간입니다.

    물론 그 책에서 다루고 있는 내용 중 많은 부분이 여전히 개발 분야의 중요한 기본 지식으로 남아있음을 부정하는 것은 아닙니다. 50여년이 흐르는 동안 그런 저수준의 구현 지식이외에도 매우 다양한 종류와 계층의 또 다른 '기본 지식'이 생겨났고, 그 모든 지식을 시대순으로 순차적으로 섭렵하는 것은 매우 비효율적이고, 불필요해졌을 뿐입니다.

    지금 시대에 어떤 가장 낮은 수준의 구현 기법들만 알면 무슨 분야든 쉽게 할 수 있다고 이야기하는 건 오직 개발 분야에 어떤 종류의 다양한 계층의 전문 분야가 있고, 각 분야에서 얼마나 빠른 속도로 새로운 이론과 트렌드가 생겨나는지에 대해 무지했을 때 보일 수 있는 만용에 불과합니다.

    피보나치 수열이나 소수값 구하는 알고리즘을 공부한다고 객체지향을 조금이라도 쉽게 배울 수 있는 것도 아니고, 객체 지향을 잘안다고 모나드(monad)나 불가변성 같은 개념을 더 빨리 익힐 수 있는 것도 아닙니다.

    앞서 이야기한 입문 단계의 비전공 개발자의 이야기로 돌아가서, 그런 분들이 자바나 C# 같은 기술을 주력으로 하고, 일주일에 다섯 시간 쯤 공부에 투자할 수 있다면 과연 그 시간 동안 반세기 전의 알고리즘 서적을 보는 것이 기본을 착실하게 다지는데 도움이 될지, 아니면 객체지향 패러다임이나 디자인 패턴을 배우는 것이 보다 근본적인 도움이 될지 한 번 생각해보시기 바랍니다.

    솔직히 주장의 절반 이상을 자기 과시와 권위에의 호소로 일관하시는 것을 보면 아마 님은 누가 뭐라하건 자신의 생각을 바꾸진 않을 것 같습니다.

    하지만 자바나 C# 언어의 입문자 분들, 특히 제한된 시간을 투자해서 이런 저런 공부를 했는데도 여전히 어떻게 하면 단순 예제보다 크고 복잡한 프로그램을 설계하고 구현하는지에 대해 감을 잡지 못하는 분들이라면 제 글이 공부 방향을 잡는데 보탬이 되었으면 좋겠다는 생각이 듭니다.

  • 앙앙이
    4k
    2017-06-10 06:27:18

    알고리즘 중요하고 디자인 패턴도 역시 중요합니다.


    알고리즘이 디자인 패턴보다 더 중요하다.

    디자인 패턴을 더 우선해서 공부해야 한다.

    이러한 주장들 엄마 좋아 아빠 좋아 이런 유치한 질문 하는것 같지 않습니까?


    알고리즘 초급편 정렬이 우습나요.

    예.. 저두 학부 수업때 그거 왜 하나 했습니다.

    그런데요. 제 이야기를 한번 들어보세요.

    "조엘온 소프트웨어" 에 러시아 페이트공 알고리즘이라고 들어 보셨나요?

    정말로 깔깔대고 웃었습니다.

    그런데 맙소사 러시아 페이트공 알고리즘으로 구현된 소스 코드를 보여주는 순간

    저는 얼굴이 빨게졌습니다.


    void strcat(char* dest, char* src) 
    {
          while(*dest) dest++;
          while(*dest++ = *src++) ;
    }


    일반적인 c 언어에서 스트링 길이 구하기 코드는 아래와 같습니다.


    int strlen(char **src) {
    int len = 0;
    while($src) len++;
    return len;
    }


    그럼 이제 저만의 strcat 을 만들겠습니다.


    void mystrcat(char* dest, char* src) 
    {
    int len = strlen(dest);
    dest+=len;
    copySourceAllString(dest, src);
    }
    
    void copySourceAllString(char* dest, char* src) {
    while(*dest++ = *src++) ;
    }


    이 mystrcat 로직에 무슨 문제가 있습니까?

    이 로직은 사람 머리속에서는 O(n) 1 이지만

    폰노이만 기계에서는 O(n) n 입니다.

    사람 머리속 O(n) 이 1 이라고 폰노이만 기계에서도 그렇것이다 착각하지 않고

    폰노이만 기계에서는 O(n)이  n 이라는 것을 확실하게 알게 하는 공부가

    바로 하찮게 여기는 정렬 알고리즘들 소개및 비교하는 공부입니다.

    정렬 알고리즘 견습생들 수준에 딱이잖아요.


    디자인 패턴이 이러한 역활을 해 줄수있나요?

    디자인 패턴이 과연 견습생들이 소화할 수 있을만큼 쉬운가요?

    디자인 패턴은 날고 기는 프로그래머(들)가 만든것들을 살펴보니

    공통된 모습이 있다 하여 그 공통된 구조에 이름을 붙여서 세상에 나온겁니다.

    그런데 어떻게 이러한것을 견습생 수준에서 단 시간에 습득할 수 있단말입니까?

    디자인 패턴은 폰노이만 기계에서 O(n) 이 무엇인지 알려주는데 적합하지 않는 내용이며

    또한 견습생한테도 난이도가 너무 어렵습니다.


    객체지향 언어를 사용하는 개발자라면 디자인 패턴은 피할수없는 숙명입니다.

    알고리즘 또한 개발자라면 피할 수 없는 숙명이기도 합니다.


    저희 누나가 유치원생 선생님이신데요.

    요즘 아이들 발칙하다고 합니다.

    엄마 좋아 아빠 좋아 물으면 그런건 묻지 말라며 질색한답니다.

    저는 그 이야기를 듣고 좀 충격을 받았습니다.

    왜냐하면 제 앞에서 그 아이가 짖궂게 유치한 질문을 하는 저를 질타하는것 같았기때문입니다.


    우리는 너무 공부할것이 많은 개발자입니다. 서로 서로 화이팅 외치며 격려해 줍시다.


  • fender
    22k
    2017-06-10 06:39:08 작성 2017-06-10 06:40:00 수정됨

    앙앙이// 디자인 패턴을 먼저 공부해야하는지, 아니면 알고리즘을 먼저 공부해야하는지를 따지는 이유는 보통 사람은 읽는 데 각각 두 시간씩 걸리는 책 두 권을 동시에 펴놓고 두 시간만에 양 쪽의 내용을 모두 파악할 수 없기 때문입니다.


  • Taetrees
    550
    2017-06-10 09:42:34

    길벗

    저는 님의 주장에 꽤 찬성하는 입장에서 님의 의도대로 님의 글을 보게 될 사람들의 설득을 말한 것입니다. 여전히 같은 논조의 글이군요.

    약간 도발적으로 댓글을 쓴 것에 죄송하게 생각하네요. 저는 그냥 말을 아끼겠습니다.

    더욱 정진하여 더 좋은 개발자가 되시길 바랍니다.

    댓글도 오독하지는 말아주셨으면 하네요.

  • 하마
    7k
    2017-06-10 10:38:03 작성 2017-06-10 10:44:02 수정됨

    앙앙이/  

    그 코드로는 길이를 구할 수 없지요.  또한 일반적으로 장문 보다는 단문이 훨씬 많은 상황을 고려하면 님이 새롭게 짠 코드가 더 안좋을거 같군요.

  • ee32321
    1k
    2017-06-10 10:38:07 작성 2017-06-10 10:58:30 수정됨

    글과 댓글을 읽어 봤습니다.

    눈에 가는 글들을 자세히 읽었습니다.

    알고리즘, 디자인 패턴... MVC모델, SQL문등...

    이 내용은 비슷하면서도 관계가 있다고 생각해봅니다.


    또 실제, 지금 저의 생각에는 코딩으로서 프로그래밍을 생각한다. 물론, 이것도 중요하겠지만 실제로 github의 명령어, gcloud의 명령어와 같은 프로그래밍을 하기 위한 여러 명령어의 사용이 중요해지는 건 아닐까?

     이런 생각이 드네요.

     저의 생각으로서, 현재로서는, 프로그래밍코드를 짜서, 동작이 되게는 한다. 또 그 다음에 웹호스팅, 서버관련 셋팅등. github사용이나 gcloud명령과 같은 자질구레해보이는 명령(프로그래밍언어. 디자인패턴이나 알고리즘에 비해서.)과 같은 것을 정리할 수 있는 힘이 필요하지 않나. 이 부분은 실제 프로그래밍언의 알고리즘이나 디자인패턴처럼 정해진 것도 아니고, 상황에 따라서 적용할 때에 살펴보는 식의 순간적인 판단력이 필요하다. 개인적으로 이렇게 생각하고 있습니다.


     디자인패턴이나 알고리즘. 기계어의 처리, 임베디드와 같은 부분을 또 생각하여 본다고 하면, 마찬가지로, 잘 사용하지 않았달까.. 익숙하지가 않은 여러 부품들이나, PC연결등. 이런 하나하나역시, 프로그래밍의 알고리즘과 디자인패턴과는 비슷하나, 또 다른 모양이 있겠죠.


     알고리즘이나 디자인패턴, MVC모델과 같은 형태와 함께, 그런 부분부분을 잘 소화시킬 수 있느냐.. 이런 생각을 해보게 되네요. 지금의 상황으로서, 표준기술(소프트웨어 라이센스,하드웨어표준기술)과 알고리즘,디자인패턴과 같은 형태 또, 부분부분들(웹호스팅,서버셋팅,gcloud와 같은 명령어의 활용.). 이의 것들을 접목시켜서, 생각해야하겠다. 그래야 개발이 잘 일어날 수 있겠다.. 이런 생각을 해봤습니다.


     여기의 글과 댓글을 읽으면서, 혼자서 이렇게 생각해봤네요.


    그럼, 글 잘 보고 갑니다. 정보공유, 감사합니다.


  • 앙앙이
    4k
    2017-06-10 10:44:21

    // 하마

    급히 짠 코드라 엉망입니다.

    새로짠 코드는

    더 빠른 코드 보여 주려는것이 아닌

    인간 관점에서 O(n) 1  

    폰노이만 관점 O(n) n 임을 강조하기 위해

    예시로 제시한것뿐입니다

  • iops
    1k
    2017-06-10 12:43:54

    전재형 / 그거는 님이 

    `딥러닝을 공부한다고 할때, 분명 알고리즘과 공통되는 성질이 있지만 굳이 알고리즘을 공부한다고 인하죠.`

    딥러닝은 알고리즘을 공부한다고 안한다고 글을 써서 그거에 대한 답변이고요


    이글을 보면 정말 사람은 다양하구나 라는 생각이 많이 들었습니다.

    아마 개발자라면 "좋은 코드"를 짜야한다 라는 생각에는 모든 개발자가 동의할것입니다.

    근데 좋은 코드란 단어가 사실 추상적이죠.


    어떤 사람은 버그가 없는 코드를 짜는것이 좋은코드다 말하는 사람이 있을거고

    어떤사람은 나중에 확장하기 용이한 코드를 짜는게 좋은 코드다 말하는 사람이 있을거고

    어떤 사람은 사람기준에 알아보기 쉬운 코드를 짜는게 좋은 코드다 말하는 사람이 있을거고

    멋지고 특수한 핵심알고리즘의 프로그램을 짜는게 좋은코드다 말할수도 있을것입니다.

    물론 당연히 모두다 맞는 얘기입니다. 모두다 개발자가 가야할 목표기도 하고요.

    근데 사람 손이 두개고 사람뇌가 하나고 시간은 누구에게나 동일해서 결국 뭐를 먼저 우선할지를 선택을 해야하는데


    버그를 중요시하면 유닛테스트를 먼저 배워라라고 얘기할꺼고

    확장을 중요시하면 OOP나 디자인패턴을 먼저 배워라 얘기할꺼고

    쉬운코드를 중요시하면 협업방법 XP나 리팩토링을 먼저 배워라 얘기할꺼고

    멋진 알고리즘을 중시하면 알고리즘을 먼저 배워라 할껀데

    (저는 참고로 테스트 파입니다. 이유는 어떤 코드든지 버그가 발생할 수 있고 개발자가 버그때문에 고통받지 알고리즘 몰라서 고통받는 케이스는 솔직 많지 않다고 보기 때문입니다.)


    이글에 찬성하는 쪽도 아예 알고리즘 공부 하지 말라라고 글쓴거도 아니고 그렇게 생각하는 사람 아무도 없는데

    그냥 학습의 우선순위에 대한 글일 뿐이고 이 우선순위도 특정 언어에 한정 해서만 쓴글인데

    저기위에 회사 들먹이면서 니네가 구린데 있어서 그래라는 어그로나 당할 글인가?는 의문이네요.

    충분히 고민해볼 수 있을만한 글인데.. 


    소프트웨어 장인이란 책에서도 코딩 면접 파트에서 이와 비슷한 내용이 나오는데 면접시 알고리즘보다 

    지원자가 비즈니스 도메인을 표현하고 솔루션을 설계할 역량이 되는지를 봐야한다라고 나옵니다.

    저도 물론 이 생각에 동의합니다.


    다시 얘기하지만 공부를 아예 하지 말라는거도 아니고 특히 자료구조는 정말 중요한 부분이 맞습니다.

    자료구조는 문법과 자료형 다음으로 배워야할 정말 중요한 부분입니다.


    이글에 찬성하는 사람들의 의견은 하지말라는게 아니라 가뜩이나 공부할거도 많은데

    현실에서 쓰이지도 않는 버블소트같은거 공부하지 말라는 얘기지요. 알고리즘은 전부 배척하고 딴사람이 짜게 놔둬! 가 아니라.

  • booiljoung
    47
    2017-06-10 15:08:06

    inyl // 그렇습니다. 케바케죠!

  • moonti
    3k
    2017-06-10 19:05:03

    되게 생삿적인 글이라 출근길에 봐야 겠네요

  • exexexe
    339
    2017-06-11 08:39:56

    비전공이신 분들은

    아무래도 전산과 과목의 기초 부족 때문에 실력이 늘지 않을 까 고민하는데요...

    디자인 패턴은 제가 허접 개발자라서 그런지 몰라도...참 어렵게 느껴지더라고요...

    외국의 고수분들이 잘 만들어 놓으셨겟지만...

    참 이것도 잘써야지...적용해 보아야지 하지만...실제로 싱글턴 정도인 것 같아요...

    막상 실제 업무에서는 알고리즘은 갖다 쓰고 있고,

    원하는 기능은 만드는데...확실히 기초는 어느정도는 알고 있어야 갖다 쓰지요..ㅎㅎ

    초급이 디자인패턴 부터 공부하는 것은...어려워서 빨리 포기할 것 같고요...

    어느정도 자료구조와 알고리즘이 어느정도 기초가 있어야 할 것 같습니다.

    그 상태에서 어느정도 현업의 경험 + 기초(자료구조와 알고리즘) + OOP에대한 약간의 개념

    이후에...이제 이 엉망인 프로젝트에 대해서 디자인 패턴이 필요하겠구나....하고..

    필요성이 생기게 되어 공부하는 모양새로 나가게 됩니다....

    이제 필요가 생긴 것이죠....그 때 부터 디자인 패턴을 공부하면 어떨까 합니다.

    결론적으로 디자인 패턴은 나중으로 밀렸네요..ㅎㅎ

    우짜됐든, 배워서 잘써먹었으면 좋겠네요...

    재주는 곰이 부리는데...사장은 그딴걸 왜하냐 하는 사람 환경에서는...참 거시기 합니다.

    열심히 배워도 써먹지 못하면 죽은 지식이니까요...



  • coding8282
    1k
    2017-06-11 11:53:51

    fender님이 이제까지  쓰신 글을 모으면 '한국에서 소프트웨어 개발자 길잡이'라는 책이 나올 듯합니다.

  • fender
    22k
    2017-06-11 15:04:23 작성 2017-06-11 15:07:01 수정됨

    지금 보니 위에서 논지와 무관하게 권위적인 덧글을 다신 분은 글을 지우셨군요. 해당 글에 대해 작성한 제 첫 답글은 민망하기도 하고 토론에 도움이 되지 않는 내용이니 같이 삭제 했습니다.

    다만, 두 번 째 답글은 어느 정도 논지가 담겨있는 내용이니 아이디를 지칭하는 내용만 수정해서 그대로 두도록 하겠습니다.

    꽤 논란이 생길법한 글이지만 다른 분들은 대체로 차분히 찬반 의견을 개진해주시는 데 감사드리고 싶습니다.


  • fenchSoda
    32
    2017-06-12 00:46:47

    제 개인적인 생각으론 알고리즘 정말 중요하다고 생각합니다.


    물론 알고리즘이 정말 많이 안쓰이는 분야도 있는건 사실이죠.


    하지만, 프로그램을 만드는일 자체가 뭔가를 좀더 효율적으로 만드는 것 아니겠어요.


    알고리즘을 정말 대충배우면 뭣도 없어보이긴합니다만, 그걸 실전에 적용시켜가는 노력을 하거나 벤치마킹을 하면서 효율성을 따지다보면 정말 알고리즘이 중요하고 재밌다는걸 알게되실겁니다.


    어떤분께서 큐나 스택 쓰는 사람이 진짜 있냐고 물어보시는데

    정말 안쓰시나요...


    bfs,dfs, 정말 중요하고 자주나오는건데...



  • 앙앙이
    4k
    2017-06-12 02:46:48

    // fender 

     "조엘온소프트웨어" 책을 읽으신적 있으시나요?

    거기 p18 페이지에 나온 내용 일부분 인용해 드리겠습니다.

    저는 조엘의 주장에 동조를 하지만

    아마도 fender 님은 다르게 생각하실것 같습니다.

    저를 이해하는데 도움이 되시기를 바라며 인용합니다.


    -------------  "조엘온소프트웨어"  p18 부분 인용

    전산과 신입생은 CPU 부터 시작해 C를 활용하는 데까지 차곡차곡 기초를 닦아야 합니다. 저는 솔직히 너무나도 많은 컴퓨터 관련 교육과정들이 자바를 가장 좋은 초보자용 언어라고 선전하는 현실에 질려 버렸습니다.<중간생략>하지만 여기에는 교육적인 재앙이 기다리고 있습니다. 졸업생들은 하향 평준화돼 러시아 페이트공 알고리즘을 여기저기 만들어내며, 심지어 자신의 잘못을 인식조차 못할 겁니다.

  • fender
    22k
    2017-06-12 05:28:23 작성 2017-06-12 06:24:05 수정됨

    fenchSoda// 본문과 덧글의 내용을 꼼꼼히 읽어보셨다면 아시겠지만, 알고리즘이 쓸 데 없다는 주장을 하는 것이 아닙니다.

    그리고 자료 구조는 이미 이야기했지만, 최소한 어떤 종류가 있고 어떨 때 써야한다 정도는 저 역시 기본지식이라고 생각합니다.

    앙앙이// 두 가지 관점에서 볼 수 있는데, 학부 수준에선 소프트웨어 관련 해서 어떤 분야가 있는지 두루두루 접해보고 그 중에 주력으로 선택할 분야를 고르기 위한 목적이라면 C나 알고리즘을 배워보는 것도 교양으로 괜찮다고 생각합니다.

    하지만 인용하신 부분 같이 자바부터 배우면 덜 기본에 충실해지고 하향 평준화가 되니 저수준 언어부터 배우라는 시각이면 전혀 동의하지 않습니다. 참고로 미국에서 전산 관련 학부에서 C/C++ 대신 자바를 가르치게 된 것도 한참 지난 이야기이고, 지금은 파이선(Python)이 자바를 제치고 가장 많이 사용하는 언어가 되었습니다.

    파이선이 C보다 수준 떨어지는 언어인가요? 아니면 파이선을 배우려면 반드시 C를 먼저 배워야 하는 건가요?

    그리고 말로 모든 것을 할 수 있다면 저도 뭐 알고리즘, 자료구조, 운영체제, 컴파일러 이론, 네트워크 기초, 객체지향, 함수형 프로그래밍 등등 모두 중요하고 동시에 다해야 한다고 주장할 수 있습니다.

    그리고 마치 저수준 지식이 무조건 더 근본적이고 어려운 것인 양 일침을 놓는 것도 어려운 일이 아닙니다.

    "함수형 언어를 처음 배우겠다고? 그래, 클래스 기반 객체 지향 언어는 하나 쯤은 이미 마스터했겠지? 뭐? 자바 기초만 봤다고? 그래선 메모리를 못 다루지 않나! C++ 같이 강력한 언어를 알아야지 자바 같은 쉬운 언어만 보면 실력이 안느는 거야.

    그리고 C++ 할 생각이면 내 생각엔 C를 먼저 보는 게 좋겠어. 결국 C++는 C언어에서 파생된 거니까 말이지... 아참, 어셈블리는 할 줄 아나? 컴퓨터 언어라는 건 말이야, C든 C#이든 어차피 가장 근본으로 내려가면 기계가 이해할 수 있는 명령의 집합인 거야.

    개발할 땐 컴파일러를 쓰더라도 최종적으로 소스가 어떻게 기계가 이해할 수 있는 명령으로 바뀌는지 정도는 알아야 고급 언어도 잘할 수 있지 않겠어?"

    이런 소리 늘어놓는 게 뭐 어렵겠습니까. 저런 이야기를 하면서 실제로 C부터 객체지향이나 함수형까지 자유자재로 다룰 수준으로 섭렵하는 것이 정말 어려운 일이고, 그것을 이제 막 이 분야에 입문한 개발자에게 요구하는 건 불가능에 가까운 일일 뿐이죠.

  • fender
    22k
    2017-06-12 06:21:54 작성 2017-06-12 07:05:41 수정됨

    여담입니다만, 이번 글에 대한 몇몇 분들의 날선 반응(주로 사이트 바깥에서 반박 당할 위험없이 일침을 놓는 분들이 많더군요)을 살펴보니 자바나 C#으로 대변되는, 정적 타입 기반 객체지향 언어의 가치가 무엇인가에 대해 조금은 근본적인 회의감이 들기도 합니다.

    아시다시피, 우리나라 SI 시장은 자바가 지배하고 있지만 거의 아무도 객체지향적 접근을 사용하지 않습니다.

    최근 유니티 게시판에서 비슷한 토론을 해보았는데, C#을 기본 언어로 사용하는 환경임에도 객체지향을 제대로 활용하지 않거나 심지어 적대적인 반응을 보이는 사람들이 다수였습니다.

    또한, 이번 토론에서도 드러나듯이, 전공자들은 자바나 C#을 초급자도 사용할 수 있게 물타기한 언어 쯤으로 우습게 아는 경향이 있고, 기술 동향에 민감한 이른바 '힙스터(hipster)' 개발자들은 함수형 언어나 최소한 동적 타입 언어를 다루면서 자바나 C# 개발자들을 시대에 뒤떨어진 '기업형 개발자'라고 조롱하곤 합니다.

    이런 현실을 볼 때 과연 모두에게 외면 받는 정적 타입 객체 지향 언어의 가치가 여전히 유효한가 하는 의문이 들게 되었습니다.

    아직 깊게 생각해보지 않은 주제이긴 합니다만, 어쩌면 바로 위와 같은 업계에 널리 퍼진 편견들이 어쩌면 그런 패러다임의 성공으로 인한 부작용이 아닌가 하는 역설적 생각이 들기는 합니다.

    즉, 정적 타입 객체지향 언어의 장점이 가장 빛을 발하는 분야는 대규모 코드베이스에서 구조적인 복잡도를 관리하는 측면이고, 그런 특성에 기대어 매우 강력한 개발도구와 플랫폼, 프레임워크들이 시장에 등장하게 되었습니다.

    그런 기술의 특징은 내부 구조 자체는 매우 복잡할 지 몰라도 사용자들에게는 그런 복잡도를 추상화 계층 뒤에 감추고, 대신 매우 편리한 - 심지어 원리를 모르고 무작정 따라해도 될 만큼 쉬운 - 사용 인터페이스를 노출한다는 것입니다.

    그래서 그런 기술을 활용해서 보다 쉽게 개발에 입문할 수 있고, 시장은 실용주의적인 관점에 따라 제품을 만들 수 있는 최소 수준의 기술과 낮은 단가의 인력을 선호하고, 또 그런 개발 인력들이 다수가 되면서 전통적 커리큘럼 중심으로 공부한 전공자들이나 '힙스터' 개발자들의 조롱거리가 되는 것이 아닌가 싶습니다.

    하지만 간과해선 안되는 것은, 예컨대 '개나 소나' 스프링MVC로 웹 사이트를 찍어낼 수 있다면, 그건 스프링 프레임워크나 자바가 '개나 소'가 쓸 법한 쉽고 수준 낮은 기술이기 때문이 아니라, '개나 소'도 제법 그럴 듯한 웹 사이트를 찍어 낼 수 있을 만큼 강력한 구조를 쌓아올릴 수 있는 이론과 관행이 그런 기술을 중심으로 오랜 기간 확립되어 왔기 때문이라는 사실입니다.

    그런 이론과 관행을 구문 단위의 최적화를 고민하는 기법의 응용 쯤으로 이해하는 것은, 그 만큼 쉽고 강력한 프레임워크나 플랫폼을 만들기 위해 패러다임이나 디자인, 아키텍쳐 수준에서 얼마나 다양하고 깊은 이해가 필요한지에 대해 무지하기 때문에 가능한 착각이라고 봅니다.

  • the6thm0nth
    3
    2017-06-12 17:31:35

    독학으로 개발을 시작해서 고급 언어를 사용하는 초급 개발자의 마음으로 그동안 품어왔던 물음표에 대한 답이 될 수 있는 좋은 글인 것 같아 감사합니다. 이 글은 글 본문 뿐만 아니라 댓글에서 이어지는 토론 내용, 또 맥락에서 빗나가는 듯한 댓글들까지 모두가 굉장히 유익한 내용들인 것 같네요.


    제가 생각했을 때 디자인 패턴과 알고리즘을 모두 뭉뚱그려 '문제를 해결하기 위한 방법'이라고 이야기한다면, 디자인 패턴은 프로그램을 작성하기 위한 방법, 알고리즘은 함수를 작성하기 위한 방법 정도로 설명할 수 있을 것 같습니다. fender 님이 말하신 '계층의 차이'가 이 차이가 아닐까 싶네요. 한 프로그램을 만들기 위해서 하드코딩을 할 수도 있고, 싱글톤을 적용할 수도 있듯이 특정한 인풋에 따른 특정한 결과값을 내기 위한 함수를 작성하기 위해서는 여러 알고리즘 중 하나를 선택할 수 있을테니까요.


    비전공자로서 개발을 공부하면서 느낀점은 알고리즘과 자료구조 등과 같은 기본지식을 먼저 쌓는 것은 '필수적'이다는 거의 불변의 진리지만 상대적으로 디자인패턴은 고급개발자로 넘어가기 위한 관문이다 정도였거든요. 하지만 막상 개발을 하면서 이 이야기에 물음표가 많았는데 이 글 덕분에 좋은 깨달음을 얻은 것 같습니다.

  • unigoon3
    295
    2017-06-12 21:45:25

    "알아서 좋은 정도의 지식은 평생 공부해도 다 못배울 만큼 방대한 것이 문제입니다." => 알고리즘의 문앞에서 쓸쓸히 발길을 돌리는 알고리즘이 반복됩니다

  • unigoon3
    295
    2017-06-12 21:50:07

    " '기본'을 배우면 나머지 '응용분야'는 쉽게 익힐 수 있을 것이라는 가정" => 응용분야들을 해쳐나가는데 필수불가결한 기본들이라 할 수 없다고 봅니다. 

  • 스타
    3k
    2017-06-15 08:41:46 작성 2017-06-15 08:44:56 수정됨

    댓글의 흐름이 주장에 대한 반박으로 싸우다가 어느정도 지나면 조율의 흐름으로 기류가 바뀐다고 어디서 본 것 같은데요.. 저는 어디에 속할지...

    알고리즘 배우는 것과 디자인 패턴 배우는 시기가 조금 다르다는 것 외에 어느것이 더 좋다라고 말하기 어렵네요.

    제 생각에는 알고리즘은 논리적인 사고 영역이고 디자인 패턴은 경험에 의한 영역 아닌가 해요.

    그래서 알고리즘은 성능에 대한 지표가 있고, 패턴은 지표 보다는 다수의 경험적 의견에 따라 바뀌기도 하는 것 같아요.

    그래서 순위를 논하는게 맞는지 모르겠어요.

  • roksoulmc
    2017-06-22 11:35:20

    너무 길어서

    알고리즘, 디자인패턴, 자격증, 언어에 대한 경력???


    정답을 몰라도 해답을 아는 사람이 개발을 했으면 합니다.

    그러면 위와 같은것들에서 벗어난 시각에서 목표만 순수하게 바라볼 수 있으니깐요.



  • 퀑크탱
    414
    2017-06-24 13:16:02

    flyso2  이야 이런 지능을 가지고도 타이핑을 하시는구나.  컴공 외엔 떠오르는게 없으셔 ㅠㅠ

  • 지나가던개
    43
    2018-07-11 23:25:05
    알고리즘을 한 사람과 안 한사람의 격차는 하늘과 땅차이 이지요
    해보질않았으니 모르지요
    -2
  • 로그인을 하시면 댓글을 등록할 수 있습니다.