fender
9k
2017-06-14 10:24:12.0 작성 2017-06-14 11:45:59.0 수정됨
19
2512

알고리즘 논란에 대한 단상


알고리즘에 대해 가볍게 쓴 글이 페이스북에 퍼지면서 뜬금없이 유명세(?)를 타고 있어 기분이 묘합니다. 그 와중에 특히 제 신상에 대해 비상한 관심을 가진 분들이 있어서 놀랐습니다.

그 분들에 의하면 저는 갑질을 즐기고 신입 개발자의 실력을 두려워 하는, 그리고 개발은 그냥 SQL 잘하고 라이브러리 잘 가져다 쓰면 전부라고 생각하면서 근근히 SI 바닥에서 연명하는 그런 개발자라고 하더군요.

요샌 나이가 들어서 그런지 그런 글에 일일이 대응하거나 하는 일은 귀찮게 느껴집니다. 그리고 사실 논리와 관계없이 내가 얼마나 잘났네 니가 얼마나 못났네 하는 건 말려드는 것 자체가 수준 떨어지는 일이기도 합니다.

전 요즘에는 작은 스타트업에서 스칼라 프로젝트를 하고 있습니다. 개발자는 저와 다른 한 명 뿐인데, 어찌어찌 개발 기간이 늘어나다 보니 구조도 꽤 복잡해져서, 어제 확인하니 클래스/트레잇(인터페이스)이 3천 개가 훌쩍 넘어가더군요.

뭐 클래스 3천 개짜리 프로젝트가 그 자체로 크게 대단한 게 아니라는 걸 알 정도, 그리고 그런 걸로 '나 이런 것도 짤 줄 아는 개발자야' 따위의 자부심을 부리는 것이 얼마나 유치한 것인지는 알 정도의 나이와 경력은 있다고 생각하기에, 그런 의도로 이야기하는 것은 아닙니다.

대신, 제가 강조하고 싶은 것은, 자바, 스칼라, C#과 같은 계층의 언어는 주로 그런 식의 개발을 하는 데 최적화된 도구라는 것입니다. 함수형 언어의 빌딩 블록(building block)이 함수라면, 언급한 종류의 언어의 핵심 구성 요소는 클래스나 인터페이스이고, 그렇기 때문에 이러한 단위 기능을 어떻게 쌓아 올리는 것이 좋은 지에 대한 지식이 무엇보다 중요하고 우선 공부해야 되는 내용이 되는 것입니다.

그리고 포인터만 이해하면 C 언어는 마스터 하는 것이 아니듯이, 클래스 생성할 줄 알고 인터페이스 가져다 구현할 줄 알면 객체지향은 더 배울 것이 없는 것도 아닙니다.

앞서 말한 3천여 개의 클래스와 인터페이스는 단순히 페이지별, 기능별 코드를 파일 처럼 분류해놓은 것이 아니라 시스템의 복잡도를 관리하기 위해 서로 유기적인 관계로 연결되어 여러 추상화 계층을 구성하고 있고, 핵심 유형의 클래스를 IDE에서 살펴보면 스무 개 씩 되는 트레잇이나 상위 클래스로 구성된 계층 구조를 확인할 수 있습니다.

그리고 그런 종류의 계층을 구성하는 원리는 이진 검색이나 정렬 알고리즘을 열심히 공부한다고 알게되는 것도 아니고, 상대적으로 더 간단한 내용도 아닙니다. (아마 객체지향이 알고리즘에 비해 배울게 별로 없고 쉽다고 생각하는 사람들은 자바나 C# 문법으로 C 같은 코드를 양산하는 그런 부류일 것입니다.)

바로 그렇기 때문에 특히 비전공 출신으로 막 개발에 입문한 분들에게는 어느 쪽을 우선 공부할 것인지가 중요한 선택의 문제가 되는 것입니다.

제가 이 곳에서 그런 경로로 자바 실무에 입문한 분들의 글을 읽으며 가장 안타까웠던 점은, 너무 많은 개발자가 API 문서조차 읽지 않는다는 것이었습니다. 국비지원 학원 등에서 스프링 같은 프레임워크를 어떻게 쓰는지, 그 것도 딱 한 가지 방식의 특정 구현만을 가르치지 그것이 어떻게 동작하고 왜 그렇게 개발하는지에 대해선 제대로 다루지 않는 것이 문제인 듯 합니다.

쉽게 말해, 자바 개발을 하면서 SQL 정렬은 알아도 Collections.sort() 라는 API가 있는지 조차 모르는 것이 상당수 비전공 출신 국내 자바 개발자들의 현주소입니다.

그런 분들이 바로 다음 단계로 넘어가기 위해선, 우선 API 문서를 보는 습관을 들여야 하고, 그 다음으로는 ComparatorComparable이 각각 어떤 의미이고 언제 쓰이는 것인지 객체지향적 원리에 대한 이해를 넓혀야 하는 것이지, Collections.sort()에 대한 자바 런타임 라이브러리의 소스를 까서 내부 구현에 무슨 정렬 알고리즘이 쓰였는지를 확인하는 것이 아니란 이야기입니다.

그리고, 설사 알고리즘 공부에 많은 시간을 투자해서 정렬 알고리즘 뿐 아니라 인터넷 문제풀이 사이트의 상위권에 랭크될 실력을 쌓는다 해도, 그 자체로 이 도메인 클래스가 'Comparable한 무엇'의 개념이 되는 것이 맞는지, 아니면 외부의 Comparator에 정렬을 의존하는 것이 맞는지를 판단하는 종류의 지식이 조금이라도 쉽게 얻어지는 것도 아닙니다.

아마 알고리즘이 모든 개발의 기본이자 핵심이라고 주장하는 분들은 알고리즘을 이해해야 제대로 풀 수 있는 문제나 알고리즘 지식을 바탕으로 현격한 성능 개선이 가능했던 경험을 많이 해보았을 것이라 짐작합니다.

하지만 그런 개발자들이 이해하지 못하는 것은, 자신과 다른 종류의 개발자들은 객체지향이나 디자인 패턴, 또는 아키텍쳐 수준의 깊은 이해가 없이는 해결 불가능한 복잡한 문제들을 실무에서 수없이 다루고 있다는 사실일 것입니다.

경험상 라이브러리나 가져다 쓸 줄 아는 허접한 SI 개발자들을 자주 보았다는 건 외주 개발 자체나 객체지향 언어가 개나 소나 다 할 수 있는 분야이기 때문이 아니라, 단지 그 분야가 현재 우리나라에서 돈이 많이 몰리고 진입 장벽이 낮은 분야이기 때문일 뿐입니다.

사실 해외의 유명한 아키텍트들 상당수는 자바나 C# 언어로 아웃소싱(우리나라에선 'SI'라고 부르는) 업체의 CTO나 컨설턴트와 같은 직함을 달고 있는 사람들입니다.

자바, C#, 스칼라 등의 언어가 알고리즘 수준의 디테일을 감추는 것은, 그런 종류의 언어가 기본을 몰라도 쓸 수 있는 초보 개발자의 도구이기 때문이 아니라, 보다 추상화된 상위 계층의 복잡도를 주로 다루기 위한 도구이기 때문일 뿐입니다.

멋모르고 국비 지원 학원을 수료하고 실무에 뛰어들어 스프링 MVC 템플릿만 무한히 복사 붙여넣기를 반복하는 입문자들이 다음 단계로 나아가도록 돕기 위해서는, 무턱대고 구글 검색에 의존할 것이 아니라 API 문서를 보고 자신이 사용하는 자바나 스프링의 API가 어떻게 생겼는지부터 살펴보게 하는 것이 시급한 문제입니다.

그 다음으로는 왜 그런 API가 그런 모양으로 구성되어 있고, 기존 예제나 검색으로 찾을 수 없는 기능을 확장하려면 어떻게 해야하는지, 또 그런 API를 설계하는 원리에 따라 나만의 프로젝트의 비즈니스 계층을 구성하려면 어떤 것을 공부해야 하는지에 대해 방향을 제시하는 것이 필요한 것입니다.

객체지향 언어 따위 알고리즘만 알면 쉽게 배운다거나, 4년제 정규 과정 전공자가 아니면 개발 입문 따위 꿈도 꾸지 말라는 식의 우물안 개구리식 자부심을 재확인하고 싶은 것이 아니라면, 그런 입문 단계의 자바 개발자들에게 객체지향도 제대로 이해하기 전에 알고리즘 연습문제나 열심히 풀라고 일침을 날릴 이유는 없습니다.

12
1
  • 댓글 19

  • Floki
    128
    2017-06-14 12:32:55.0

    논란이 없는 내용같은데요.. 누군가 살짝 언급한 내용을 가지고 너무 과대해석 하시는듯 합니다.


    그리고 알고리즘과 패턴은 그다지 관련이 없는데 굳이 관계를 찾으려고 글을 쓰다보니 정신차려서 읽어보면 뭘 주장하는지 모르겠습니다. 주로 알고리즘은 비트 단위의 로직을, 패턴은 추상화된 entity와 relation 을 다루지 않나요?  알고리즘도 중요하지만 더 중요한 것은 패턴이고 추상화다! 이런 주장이신지요? 아니면 인터페이스와 (추상)클래스, 상속, override, overload를 이용하여 궁극적으로는 고도의 추상화 작업을 할 줄 알아야 한다라는 주장이신지요?


    추상화, 패턴, 인터페이스 등등은 물론 설계를 위한 것들이지만 초급자가 이해하려면 어느 정도의 학습 기간과 시행착오가 필요한 개념입니다. 당구 처음 치면 공밖에 눈에 안들어옵니다.  시간이 지나면 벽이 보이고 스핀이 보이고 마침내 패턴이 보이는데 이걸 터득하기까지는 많은 시간과 비용이 드는 것과 같습니다.


    정적언어를 사용하려면 객체지향의 개념을 잘 이해하고 사용해야 한다는 의미로 받아들이겠습니다. 

    0
  • fender
    9k
    2017-06-14 12:51:18.0 작성 2017-06-14 12:55:55.0 수정됨

    Floki // 그 '살짝' 언급한 글들이 제가 본 내용만 이 사이트와 페이스북, 트위터 등에서 수 십 건은 되는 것 같습니다.

    논의가 어디서 시작되었는지 궁금하시다면 첫 머리에 연결한 원글을 보시면 됩니다.

    학원 수료하고 스프링MVC 복붙으로만 개발하는 분들이 답답함을 느끼고 여기서 "개발을 잘하려면 무엇을 더 공부해야 되나요?"라고 질문하면 가장 흔하게 듣는 답변이 "알고리즘, 자료구조를 공부하세요"입니다.

    원문은, 그런 분들이 알고리즘 스터디도 만들고 문제도 풀어보다가 또 실무에선 그런 내용을 활용할 여지를 못찾으니 다시 스프링MVC 페이지 찍어내기만 무한 반복하는 모습을 자주 보았기에 쓴 글입니다.

    0
  • kkey21a
    2k
    2017-06-14 15:53:36.0

    개인적으로 fender님이 알고리즘 관련해서 쓴 글이 이처럼 논란이 된 주된 이유는 fender님이 언급하지 않은 컴공과 교수님들도 이 글을 꼭 보시면 좋겠다는 멘트가 주된 영향을 줬다고 생각합니다.



    PS

    제 개인적으로는 적어도 학생 때는 알고리즘 우선으로 공부하는 것이 좋지 않을까라 생각하는 입장인지라...

    0
  • 신입
    5k
    2017-06-14 18:12:21.0

    알고리즘에 대한 개념이 서로 달라서 그런 것도 같습니다.

    알고리즘은 학습하면 좋지만 일에서 많이 나타나지않는 이상

    크게 도움은 되지않지만요

    0
  • ee32321
    1k
    2017-06-15 00:55:43.0 작성 2017-06-15 01:12:54.0 수정됨

    글 잘 읽었습니다.

    API관련하여서, 자바API를 보면, 왜 쓰지도 않는 것이 있을까.. 이런 생각정도 들었었습니다.


    어떻게 보면, fender님이 행운이라고 생각해봅니다. 그렇게 개발을 하기도, 행운처럼, 생각하게 되네요.

    저의 생각에는 API의 구석구석.. 또 살펴볼 수 있었다.. 이런 식으로도 생각되네요.

    개인적으로는 운영체제의 스케쥴러랄까. 그런 부분 비슷하게 생각이됩니다.


    클래스가 늘어났다? API를 다 살펴보고, 다 만들어봤다. 저는 이렇게 이해했네요. 또 있다면, 디자인패턴으로, 어떤 것을 만들었다. 안드로이드API를 섭렵했다. 이런 생각도 해봅니다. 또, 지금 만드신게, 거창하지는 않는(눈에 띠지 않는) 이론적 부분일거라는 추측도 해봅니다.


     API를 잘아는 것은 중요하다고 봅니다. 또 실제 MVC패턴을 이용해서, 비즈니스로직, 웹빌드는 만드는 실무를 살펴본다면, 실무에서는 MVC패턴을 통한 웹빌드정도라면, 어느정도 정보시스템의 실제 효과가 발생되기 때문에, 그만큼만 되어도 문제없는 형태. 효과가 발생하는 형태. 이렇게 이야기할 수 있겠죠. 또한 그렇게 만들어낸 MVC모델, 정보시스템으로 인해서 업무개선, 온라인에서의 정보의 빠른 교환을 통하여, 오프라인에서의 오해나, 불필요한 마찰, 대면이 줄어드는 요소등. MVC패턴, 웹빌드, 정보시스템만으로도 어느정도 포괄하여, 만족할 만한 효과가 많이 있다는 생각을 해봅니다.

    0
  • jjmean2
    4
    2017-06-15 09:21:02.0 작성 2017-06-15 09:23:42.0 수정됨

    사람은 어느 레벨에서나 추상화하여 사고가 가능하고, 알고리즘과 디자인 패턴은 그 추상화를 시작하는 단계가 다를 뿐이라고 생각합니다. 절차적으로 진행되는 언어의 기본 문법을 빌딩블록으로 삼느냐, 알고리즘을 적용하여 좀더 추상화된 행위를 담은 API를 빌딩블록으로 삼느냐가 다를 뿐인 거죠. 


    API를 남이 만든 API를 가져다 쓴다고 하지만, 알고리즘도 남이 만든 알고리즘 이론을 가져다 적용하기만 할 수도 있는 것인데, 어떤 것을 빌딩블록으로 삼느냐에 따라 수준을 이야기할 수는 없는 것 같습니다. 단지, 대부분의 사람들이 가장 먼저 접하는 게 API이고 거기서 발전하면 API를 빌딩블록으로 삼아 더 좋은 구조로 쌓아나가는 것을 선택하거나 API의 아랫단의 알고리즘을 최적화하고 발전시키는 것을 선택하게 되는데 (둘 다 할 수도 있겠지만요) API를 단순 사용하는 데에 머무는 경우도 많기 때문에, API를 사용하는 것이 수준이 낮다라고 인식하게 되는 것이 아닌가 싶습니다. 알고리즘을 고민한다는 것은 이미 한 단계 나아간 것이니까요. 


    그렇다고 해서 API를 가지고 더 상위의 좋은 구조를 설계하는 것을 고민하는 사람이 수준이 낮은 것도 아니고 해결하려는 문제영역이 다른 것이라고 생각합니다. 예를 들어, 성능, 효율성을 높이려는 알고리즘과 생산성, 유지보수성을 높이려는 디자인 패턴 같은 식으로 말이죠. 단지 알고리즘을 고민하든 디자인 패턴을 고민하든 각 영역에서 사람마다의 차이는 있겠지요. 새로운 알고리즘 이론을 정립하는 사람이 있는가 하면 기존의 알고리즘을 이해하고 효율적으로 적용하는 사람이 있고, 새로운 디자인 패턴을 고안하는 사람이 있는가 하면 기존의 디자인 패턴을 이해하고 적재적소에 활용하는 사람이 있고.. 


    단지 디자인 패턴 쪽의 상위단계보다 알고리즘 쪽의 하위단계를 먼저 공부한 사람이 많고 알고리즘을 잘하는 분들이 이미 고수분들이라 이후 디자인 패턴을 공부하는 데 상대적으로 수월했기에 상위단계가 쉬운 것이고 수준이 낮은 것이라 인식하시는 것이 아닐지.. 라는 생각이 듭니다. 저는 둘다 어려운데 말이죠 ㅜㅜ

    0
  • 하마
    4k
    2017-06-15 09:27:16.0 작성 2017-06-15 20:41:28.0 수정됨

    요즘 좀 한가한지 페이스북에서 fender 님의 "수호자","대변인" 쯤으로 활약하고 있습니다. ㅎㅎ 나중에 밥이라도 사셔야 할판~ 아래 저의 페이스북에 올린 정리에 대해 검증해 주시고 혹시 정정되어야 할 부분이 있으면 말해주십시요. ^^  


    하마답변//

    본 주제가 점점 알려지면서, 본질과 벗어나고 두리뭉실해지는거 같아서 정리해봅니다. 위 글에서는 "알고리즘,자료구조" 에 추가적으로"문제해결"이라는 모호한것이 또 추가가 되었고 말이죠. 문제해결 능력 고취는 당연히 높은 우선순위에 있습니다.

    처음 발제자가 "알고리즘에 민감하다고 한 이유는" 아래와 같은 연유로 보입니다.

    1. 주구장창 자료구조,알고리즘 책보고 그거 외우고 공부하는 세태가 있음
    2. 그러지마라. API 에서 제공되는 자료구조,알고리즘에 대한 이해를하고서~
    3. 문제해결을 위해 "자료구조,알고리즘 외우는거보다" 블랙잭을 개발할 때 어떻게 설계할것인가? (플레이어,카드,판자체등) 하둡을 만들려고 하면 어떻게 설계해야할 것인가? 객체지향과 디자인패턴의 의도를 이해하여 그것에 맞게 만들어보라~ 즉 레고로 다양한 집을 많이 지어보라고 한것입니다.

    레고의 재료라든지, 레고가 얼마나 효율적으로 껴맞춰지는것에 집중하기 보다는 집을 만들어 보아서, 작은 부분의 디자인패턴부터 큰 부분의 설계까지 객체지향으로 느껴보는게 중요하다. 이러한 주장이었습니다. (레고 예는 생각하기 따라서 달라질 수 있음을 인정합니다) 

    "문제해결" 에는 퀵소트도 있지만, 집을 만들기위해 클래스를 적절하게 연관시키는 작업 또한 포함됩니다. 즉 "문제해결" 을 그렇게 본다면, 그것의 우선순위가 낮춰라라고 주장하는것은 아닌것이지요.

    즉 우선순위가 자료구조,알고리즘 책 계속 공부하는것보다는 라이브러리에서 제공되는 것들이 어떻게 동작하는지 이해한 후에, 객체지향 설계쪽으로 무게를 옮겼으면..이라는 것이었습니다. 그것도 초보자들에게 말이지요. (경력쌓이면 자기가 알아서 자기 업무에 맞춰서 옮기면 됩니다) 

    -------- 여기까지가 발제자의 의도이고  ----------

    이후에 "알고리즘이 젤 중요해. 난 알고리즘 문제만 주구장창 풀어왔고, 그래서 난 좀 알고리즘 자신있어. 그리고 소위 큰 기업들이나 잘나가는 기업들은 알고리즘 테스팅을 당연히하는데, 너 따위가 감히 알고리즘 공부를 하지 말래?? 너 그 큰기업 다녀봤냐? 니 수준이 낮으니깐 다 같이 낮아지자고 그러는거지? 구직자들이 너 때문에 그런 좋은(?) 기업 못가면 니가 책임질래? 악당아~~~" 라는 좀 어처구니 없는 반론글도 있고, 그것에 대한 재 반론글이 있습니다.

    0
  • fender
    9k
    2017-06-15 09:54:27.0 작성 2017-06-15 09:55:16.0 수정됨

    하마// 제 의견에 동의하고 말고를 떠나서 아예 이해 자체를 못하는 경우는 아마도 학부나 자신의 분야에서 알고리즘 지식에 큰 도움을 받았거나 어떤 깨달음을 얻은 경험이 있는 개발자들일 것 같습니다.

    그런 사람들이 자바나 C#과 같은 패러다임도 깊이 있게 다루어 보고 디자인 패턴 같은 지식을 통해서도 큰 도움을 받거나 다른 종류의 통찰을 얻을 수 있다는 걸 경험하지 못했다면, 앞선 알고리즘에 대한 본인의 경험만을 절대적인 것으로 착각하는 게 아닌가 싶습니다.

    그 동안 쓰신 글을 보아 하마님은 그런 좁은 시각에 갇혀있을 정도로 경험이나 지식이 부족한 분이 아니라는 것은 알고 있습니다. 그래서, 아마 제가 이야기하는 내용을 어쩌면 저 이상으로 잘 이해하고 계실테니, 제가 검증이나 정정을 해야할 이유가 있을까 싶습니다.

    그 와는 별개로 제 글에 대해 그런 오해나 악의적으로 곡해를 하는 분들에게 정확한 의도를 설명해주셨다면 매우 감사드립니다 ㅎㅎ;

    0
  • 그래하자고
    80
    2017-06-15 14:44:42.0

    소셜미디어가 좋은 정보를 많은 사람들이 공유하기 좋은 세상을 만들었지만

    자신과 생각이 다른 사람에 대한 분노도 쉽게 표출되게 만든거같아요.

    상대방의 생각은 상대방의 생각일뿐 그렇게 생각하는구나~ 하고 넘어가면 될것을

    굳이 상대방의 신상을 캐고 너의 생각은 뭐가 뭐가 뭐가 잘못함!!! 이런식으로 행동하는 사람이 많네요.

    모든 사람의 생각은 다르고 그것을 존중해야하는 사회가 와야한다고 생각이들어요 ㅎㅎ

    fender님은 좋은의도로 글을 쓰셧지만 남을 존중하지 못하는 사람들 때문에 너무 많은 스트레스를

    받지않으셨으면 합니다.



    1
  • 장지락
    534
    2017-06-20 06:58:18.0

    제가 15년 현업에 있으면서 경험은 (SCI급) 새로운 알고리즘 구현하는 친구들 거의 못봤고, 회사도 많이 필요로 하지 않고, 또 이쪽으로 하고픈 사람들은 대부분 금새 학교나 유학 핑계로 신속한(?) 퇴사합니다. 제 경우(솔루션 개발 및 응용어플 개발; 70~100인 조직에서) 가장 많이 필요한 인력은 경험 많고 숙달되고 응답성 높은 소프트웨어 아키텍트들 입니다.

    즉, 쉽게말해서 OOP 설계 vs 알고리즘 구현 능력의 비율이 9:1 정도랄까요. 제 경험에서는 아키텍쳐 설계 잘하는 사람들은 대체로 알고리즘 기본 이해도 및 접근/구사도 잘 합니다. 그런데 C언어의 함수 수십개 규모(SCI급 논문용) 알고리즘 개발 경험있는 대학원 출신들 조차도 OOP 구현 및 설계능력이 안되서 결국 퇴사하거나 기술지원 부서로 가는 경우 심심찮게 봐 왔죠.

    입사 면접시 (시간 많이 소요되는) 구체적 OOP 설계를 질문할 수 없으니, 논리적 상관 관계가 약하지만 알고리즘 퀴즈를 묻고 기본이 된 인재인지 확인하는 것이지 알고리즘 설계/개발 자체를 시키려고 묻는거 아닙니다. 위에도 말했듯 '통상 OOP적 사고/설계 및 구현을 잘하는 인재는 알고리즘도 대체로 잘 하더라.'이므로 인사담당 부서에서 간편하고 정답이 정해져있는 알고리즘 퀴즈를 물어보는거죠.

    1
  • 말년개발
    1k
    2017-06-21 14:04:33.0

    마치 끝없이 팽창하는 나무 같네요 다들 가지 하나, 줄기하나씩은 만들고 있네요.

    0
  • kapamaxcore
    10
    2017-06-30 18:41:21.0 작성 2017-06-30 18:49:42.0 수정됨

    ============================================================================

    쉽게 말해, 자바 개발을 하면서 SQL 정렬은 알아도 Collections.sort() 라는 API가 있는지 조차 모르는 것이 상당수 비전공 출신 국내 자바 개발자들의 현주소입니다.

    ============================================================================


    ============================================================================

    멋모르고 국비 지원 학원을 수료하고 실무에 뛰어들어 스프링 MVC 템플릿만 무한히 복사 붙여넣기를 반복하는 입문자들이 다음 단계로 나아가도록 돕기 위해서는, 무턱대고 구글 검색에 의존할 것이 아니라 API 문서를 보고 자신이 사용하는 자바나 스프링의 API가 어떻게 생겼는지부터 살펴보게 하는 것이 시급한 문제입니다.

    ============================================================================


    ============================================================================

    하지만 그런 개발자들이 이해하지 못하는 것은, 자신과 다른 종류의 개발자들은 객체지향이나 디자인 패턴, 또는 아키텍쳐 수준의 깊은 이해가 없이는 해결 불가능한 복잡한 문제들을 실무에서 수없이 다루고 있다는 사실일 것입니다.

    ============================================================================


    ============================================================================

    내가 얼마나 잘났네 니가 얼마나 못났네 하는 건 말려드는 것 자체가 수준 떨어지는 일이기도 합니다.

    ============================================================================


    이런 글 올리시는 것은 수준이 높은 것인지 의문이네요. 글이 상당히 모순적이고 좁은 식견으로 일반화하는 것이 대부분입니다. 그리고 이미 본인 조차 위에서 시선을 아래로 향하며 말하고 있으면서, 니가 잘났네 얼마나 잘났네 하는 행위가 수준이 낮다고 말씀하시는겁니까...


    이 땅에서 얼마나 많은 개발자를 겪어보셨기에, 이리도 쉽게 대한민국 대다수 개발자를 다 안다는 것 처럼 "국내 자바 개발자의 현주소" 라는 말을 함부로 쓰시는 것인지 본인 근본적인 태도부터 고치셔야 할 것 같습니다만...


    여기저기서 알고리즘과 자료구조보다 언어 패러다임, 문서를 읽고 프레임워크 구조를 이해하는 능력, 디자인 패턴이 더 중요하다고 말씀하시는데, 그게 정말 알고리즘과 자료구조보다 중요하다면 대다수의 소프트웨어 기술에 기반을 둔 회사들이 왜 기술면접시 알고리즘과 자료구조 평가하느라 시간을 대부분 할애하는지에 대해서는 생각 안 해보셨습니까? 왜 컴퓨터 공학 및 관련 전공자를 선호하는지는? 비전공자인데도 알고리즘 및 자료구조 이해도가 높으면 붙을 수 있는 이유는? 학부에서는 왜 알고리즘을 배우는지는? 


    언급하시는 그 능력이라는 것은 구두 수준으로 물어보는 것이 대부분입니다. 단답형 지식에 가깝다는 것이죠. 직접 코드 작성해보고 성능비교 해보는 일정 수준의 반복 작업 경험과 개념에 대한 적절한 암기만 있다면 언제든지 대답할 수 있습니다. 하지만 알고리즘은 그게 가능할까요?


    그 지식을 폄하할 생각은 전혀 없지만, 알고리즘이나 자료구조를 비교선상에 놓으면 당연히 무게추는 후자로 어마어마하게 기울게 됩니다. 알고리즘 / 자료구조 제대로 익히는 데에는 상당한 시간과 노력이 요구됩니다. 이것이 안되어 있으면 Not structured enough 라며 낙오하기 마련입니다. 이건 논란의 여지도 없는 사실 그 자체입니다. 이런 방식으로 알고리즘 타겟으로 중요도에 대해서 언급하시는 것 자체가 알고리즘 및 자료구조의 위력을 모른다는 반증입니다.


    무엇이 더 중요한 것인지 판단짓고 의견을 주장하기 전에 알고리즘과 자료구조를 깊이 이해함으로써 얻을 수 있는 것이 무엇인지 상세하게 기재하고 설명할 수 있는 수준이 되어보십시오. 본인 틀에서 시스템 구현하는 데 문제 없다고 생각되시면 계속 그 기준으로 개발자 생활하셔도 아무도 간섭하지 않습니다. 근데 그게 옳은 방향이라고 다른 사람에게 이해시키려고 하지만 마세요. 일반화도 섣불리 하지 말아주셨으면 합니다.


    이런 의견 피력하시는 것 자체가 말씀하시는 국내 개발자의 현주소로 사람들 모으시는 겁니다.


    본인 현주소는 어디라고 생각하세요?

    국내 개발자들의 현주소보다는 보이지 않을만큼 앞선 곳에 계시나요? 

    유수 개발자들 앞에서 한없이 작아지는 경험은 얼마나 해보셨습니까?


    자신이 친 울타리 안에서만 놀다보면,

    얼마나 더 넓은 초원이 펼쳐져 있는지 생각을 안하려고 하기 마련입니다.  


    그 우월감을 조금 낮추시어 아래만 보지 마시고 시선을 위를 향해보는 것만으로도 

    생각이 많이 바뀌실텐데 안타깝군요.

    0
  • fender
    9k
    2017-06-30 19:09:21.0 작성 2017-06-30 19:13:15.0 수정됨

    kapamaxcore//


    알고리즘과 자료구조를 깊이 이해함으로써 얻을 수 있는 것이 무엇인지 상세하게 기재하고 설명할 수 있는 수준이 되어보십시오


    그 지식을 폄하할 생각은 전혀 없지만, 알고리즘이나 자료구조를 비교선상에 놓으면 당연히 무게추는 후자로 어마어마하게 기울게 됩니다. 알고리즘 / 자료구조 제대로 익히는 데에는 상당한 시간과 노력이 요구됩니다. 이것이 안되어 있으면 Not structured enough 라며 낙오하기 마련입니다. 이건 논란의 여지도 없는 사실 그 자체입니다. 이런 방식으로 알고리즘 타겟으로 중요도에 대해서 언급하시는 것 자체가 알고리즘 및 자료구조의 위력을 모른다는 반증입니다

    진짜 왜 하나 같이 이런 글 쓰는 분들은 만나 본적도 없는 제 실력은 그렇게 쉽게 단정하면서 제가 쓴 글의 핵심이 무엇인지는 제대로 읽어볼 생각조차 안하는지 모르겠군요.

    일단 제가 '개발자의 현주소'를 이야기하는 건 국내 SW 산업의 거의 80%가 'SI' 이고, 외국에 비해 (외국에선 '아웃소싱'이라고 합니다만) 대단히 인력지향적으로 운영되는 것은 기정 사실이기 때문입니다.

    그리고 님은 무슨 근거로 제 실력을 그렇게 내리깔아보며 훈계하는 지 짐작도 안갑니다만, 전 최소한 그런 경로로 SI에 발을 들여놓은 초보 개발자들보다야 실력과 경력이 있는 개발자라고는 할 수 있을테고, 무엇보다 제 의도는 그런 분들에게 제가 생각하는 올바른 더 효율적인 방향을 제시하려는 것이지 누구처럼 그분들 실력을 폄하할 의도 따윈 없습니다.

    제 글을 한 번이라도 정독해봤다면 제 의도가 "알고리즘 필요없다"가 아니라는 것임은 충분히 알 수 있었을겁니다. 님같은 사람들 때문에 적어도 열 번 이상은 그 의도가 아니라고 설명했거든요.

    제 글의 핵심은, 그런 자바나 C# 언어로 기초없이 SI 실무에 막 뛰어든 개발자들이 알고리즘 보단 패러다임과 객체지향을 우선 보라는 것이었습니다만... 그럼 님의 주장의 핵심은 그런 개발자들이 패러다임 같은 건 잘 몰라도 우선 알고리즘 공부부터 하는 게 훨씬 중요하다는 건가요?

    전 평소엔 전혀 동의는 안되는 의견이라도 존중은 하려고 노력하는 편입니다. 하지만 패러다임이나 아키텍쳐, 리팩터링, 디자인 패턴 수준의 지식은 그렇게 우습게 취급하고 같이 일 한 번 안해본 제 실력은 그렇게 쉽게 속단하면서 훈계질부터 하는 분 의견 따위 존중해드릴 아량은 없습니다.

    0
  • kapamaxcore
    10
    2017-06-30 23:18:59.0 작성 2017-07-01 00:19:44.0 수정됨

    제가 속단했으니 한번 여쭤보지요.

    순수하게 알고리즘과 자료구조만을 위해 2년 이상의 세월을 보내보신 적 있으신지요? 

    단언컨대 아니십니다.


    그리고 정의를 변경하지 마십시오.

    개발자의 현주소에 대한 진정한 의미가 한국 IT 산업 구조에 대해서 말씀하신 것이라구요?


    자바 개발을 하면서 SQL 정렬은 알아도 Collections.sort() 라는 API가 있는지 조차 모르는 것이 상당수 비전공 출신 국내 자바 개발자들의 현주소입니다.

    본인이 다시 한 번 읽어보세요. 바로 이어지는 글이


    그런 분들이 바로 다음 단계로 넘어가기 위해선, 우선 API 문서를 보는 습관을 들여야 하고, 그 다음으로는 Comparator나 Comparable이 각각 어떤 의미이고 언제 쓰이는 것인지....


    입니다.


    - 너무 많은 개발자가 API 를 읽지 않는다.

    - 학원에서 제대로 가르치지 않는 것 같다.

    - Collections.API() 가 있는지 없는지 모르는 것이 비전공 출신 자바 개발자의 현주소다.


    이게 결국 누구 타겟입니까?

    학원?

    80% 가 넘는 한국의 IT SI 사업구조?

    아니면 API 도 모르는 개발자? 


    본인의 진짜 의도를 교묘하게 감추고 싶을 뿐, 발톱은 다 드러나는 글 입니다. 

    fender 님 글 스타일 자체가 딱 이 수준입니다.


    '

        잘난 척은 하고 싶고, 대놓고 잘난 척은 하면 안되겠고,

        내가 경험한 것이 올바른데, 중요성에 대해서 이견이 들어오고,

        나는 사실 알고리즘에 대해서는 깊이 들어가 본 적이 없어서

        내가 알고 있는 중요성만 피력하고 싶고....

    '


    제가 소설을 쓰고있나요?

    그런 태도로 글을 쓰시니 님이 말씀하시는 "저같은 사람" 들이 생기는 것 아닙니까.

    오해가 없게 하고 싶으면 글을 똑바로 쓰세요. 단어 선택에도 신중을 기하시구요.

    본인 의도는 그게 아니였다고 비겁하게 변명하고, 핵심을 바꾸지도 마시구요.


    글의 핵심이 알고리즘이 필요없다가 아니다?

    네 명시적으로 알고리즘은 필요없습니다 라고 언급하신 적 없죠. 그 반발을 어떻게 감당하시려고

    그런 글을 쓰실 수 있겠어요. 근데 있죠, 사람을 칼로 찔러야만 죽이는 게 아니에요.

    이미 여러 항목에서 알고리즘의 중요성은 계속 배제 하고 계십니다.


    1.

    그런 분들이 바로 다음 단계로 넘어가기 위해선, 우선 API 문서를 보는 습관을 들여야 하고, 그 다음으로는 Comparator나 Comparable이 각각 어떤 의미이고 언제 쓰이는 것인지 객체지향적 원리에 대한 이해를 넓혀야 하는 것이지, Collections.sort()에 대한 자바 런타임 라이브러리의 소스를 까서 내부 구현에 무슨 정렬 알고리즘이 쓰였는지를 확인하는 것이 아니란 이야기입니다.



    2.

    아마 알고리즘이 모든 개발의 기본이자 핵심이라고 주장하는 분들은 알고리즘을 이해해야 제대로 풀 수 있는 문제나 알고리즘 지식을 바탕으로 현격한 성능 개선이 가능했던 경험을 많이 해보았을 것이라 짐작합니다. 



    3.

    하지만 그런 개발자들이 이해하지 못하는 것은, 자신과 다른 종류의 개발자들은 객체지향이나 디자인 패턴, 또는 아키텍쳐 수준의 깊은 이해가 없이는 해결 불가능한 복잡한 문제들을 실무에서 수없이 다루고 있다는 사실일 것입니다.


    이것도 알고리즘이 중요하지 않다라고 말하려는 것은 아니신건가요?
    그리고 알고리즘 좋아하는 개발자들이 객체지향이나 디자인 패턴, 아키텍처에는 무지할 거라는
    말도 안되는, 우물안 개구리 수준의 의견을 말씀하시고 계시네요. 그럼 fender 님께도 똑같이 정의해드려야죠
    하지만 알고리즘 및 자료구조 잘 모르는 개발자들이 이해하지 못 하는 것은...


    단도직입적이고 공격적으로 말해서 fender 님은 개발의 기본을 모르시는 분 입니다.

    알고리즘 공부하는 이유를 성능 향상에서 밖에 못 찾으시겠지요? 아무리 머리를 굴려봐도?
    알고리즘 공부하는 사람들은 절차지향에만 목메는 사람 같습니까? 얼마나 만나보셨는데요???

    내부 알고리즘이 뭐가 쓰였는지 몰라도 된다??

    Java 8 에서 HashMap 내부가 linked list 구조로 동작하다가, 키 검색시 Access 에 소비되는
    O(n) 성능 개선을 위해 아이템 개수가 특정 수치로 증가시 Binary Tree 를 사용해서
    O(log n) 을 보장하는 게 중요하지 않다구요?? 

    HashMap 을 쓸 때 내부 자료구조가 linked list 임을 몰라도 된다는겁니까?
    Time Complexity / Space Complexity 는 어떻게 계산하시려고 그거 몰라도 된다고 하십니까???
    프로그램 구현부터 때리고 퍼포먼스 체크를 테스트 데이터 집어 넣으면서 하실겁니까?
    아니면 타이머로 밀리세컨 프린트해서 시간 차이로 퍼포먼스 테스트 하실건가요?
    아니면 나름대로 유닛테스트 셋업 구성해서 테스트할겁니까?
    100만건 10초 떨어졌는데 1000만건은 얼마나 증가할지, 10,000만 건은 얼마나 증가할지
    테스트 데이터 10배, 100배 추가하고 프로그램 수행시간 세월아 내월아 기다리실겁니까?

    저런 사상 자체가 fender 님을 그저 그런 개발자로 만드는겁니다.

    이거 알고 있는 것이 Comparator, Comparable 차이 따위 아는 것보다 100배 경쟁력 있습니다.
    원래 알고 계셨나요? 그런데 그렇게 글을 쓰십니까??

    "현주소" 에 있는 개발자들이 "다음 레벨" 로 나아가기 위해서는 API 문서 보고 Comparator, Comparable 차이 알아야 된다? 그 다음 레벨이란 것이 지식 노트에 Comparator vs Comparable 차이점 선험&개념 설명할 줄 아는겁니까? 네? 정말 그런겁니까??

    여기까지만 보아도 fender 님이 기초 지식이 매우 약하다는 것이 그대로 드러납니다. 그러면서 현주소라는 사회 부정적인 현상 설명할 때나 쓰는 말이나 갖다 붙히고, 불특정 다수 개발자들 본인은 알고있는 기본도 모른다고 비하하면서 겉으로는 개발자들 위하는 척하는 것 하지마시란 말입니다.

    할려면 제대로하세요.
    독설이더라도, 흡수했을 때 정말로 약이될 수 있도록.
    이렇게 이도저도 아닌 논리와 지식 수준으로 여러 사람 가르치려들지 마시란 말입니다.

    존중? 아량? 제가 fender 님한테 아량 베풀어달라고 한 적도 없거니와, 존중 바라고 쓴 글 아닌 건 딱 보면 아실텐데... 굳이 그렇게 라도 자존심 챙겨가고 싶으시면 챙겨가십시오. 

    내 주장이 아키텍처, 프레임워크 구조 따위는 중요하지 않다는 것이냐구요? 아니죠. 다시 읽으세요.
    전 어디까지나 그 항목들과 알고리즘 및 자료구조를 비교선상에 올려두었을 때 더 중요한 것을 얘기한 것 입니다. 공부 순서 따위는 언급한 적 없는데 순서 관점으로 왜 질문을 왜 하시는지...?.

    프레임워크 구조 파악, 언어 특성에 대한 깊은 이해 좋죠. 꼭 해야 할 일이구요. 마찬가지로 원리 파악하는 길입니다.
    그런 자세와 생각은 높게 사겠습니다. 그렇지만 왜 거기까지만 하시나요...??

    앞서 말씀드렸 듯 그렇게 사시던 말던 제가 관여할 바 아닙니다만, 그게 진리인 것 처럼
    여기저기서 떠들고 다니시지 말라 이겁니다. 알고리즘이 왜 중요한지도 모르면서, 우선순위 정하지 마시라구요.

    아래 글은 fender 님이 읽으면 좋고, 아니면 말고입니다.
    그래도 그 알량한 자존심을 위해 제 입에서 하는 말이 아닌, 세계적으로 성공한 사업가의 말을 인용하는 것이니
    훈계라는 편협한 시각으로 받아들이지 않으셨으면 좋겠군요. 

    그리고 알고리즘과 자료구조의 필요성에 의문을 갖고 계신분들이 읽어보시고
    조금이라도 인사이트를 얻어가시길 진심으로 바라겠습니다.



    일론 머스크는 최근 물리학회지의 인터뷰에서 '추상세계로 들어가 기본원리부터 생각하는 것의 의의' 에 대해 다음과 같이 논의했다.

    질문 : 최근 인터뷰에서 이노베이션 즉 기술혁신을 추구하고 있는 젊은이들에 대한 조언으로 '누군가를 흉내 내는 것이 아니라 기본원리로 되돌아가서 생각하는 일의 중요성' 을 말씀하셨는데, 그 점에 대해서 좀 더 많은 이야기를 부탁드립니다.

    머스크 : 우리는 일상생활 속에서 일일이 기본원리로 되돌아가 생각할 수는 없습니다. 이것은 정신적으로 상당히 힘든 일입니다. 그래서 우리는 비슷한 것에 기초해서 미루어 추측하거나 타인을 흉내 내는 것으로 인생의 대부분을 보냅니다. 그러나 새로운 지평을 개척하거나 진정한 의미의 혁신을 일으키기 위해서는 기본원리에서부터의 접근이 필요합니다. 어떤 분야에서나 가장 기본적 진리를 찾고 거기서 다시 생각해야 합니다. 그러기 위해서는 정신적 노력이 필요합니다.

    - 출처 : 수학의 언어로 세상을 본다면 -




    0
  • fender
    9k
    2017-07-01 06:56:08.0 작성 2017-07-01 09:50:34.0 수정됨

    kapamaxcore//

    이게 결국 누구 타겟입니까?

    학원?

    80% 가 넘는 한국의 IT SI 사업구조?

    아니면 API 도 모르는 개발자?

    본인의 진짜 의도를 교묘하게 감추고 싶을 뿐, 발톱은 다 드러나는 글 입니다. 

    fender 님 글 스타일 자체가 딱 이 수준입니다.

    정 못 믿겠으면 지난글 보기해서 제가 이전에 어떤 글들을 썼는지 좀 보시기 바랍니다. 전 이제까지 꾸준히 업계 선배 개발자 입장에서 국내 SI 시장 구조를 비판했고, 그런 환경에서 고통 받는 후배 개발자들의 공부 방향을 바로 잡아주기 위한 글을 써왔습니다.

    남의 의도 멋대로 곡해해서 비난했으면 부끄러운 줄이나 아세요. 제가 왜 님의 독해력까지 책임을 져야 하나요?

    그런 태도로 글을 쓰시니 님이 말씀하시는 "저같은 사람" 들이 생기는 것 아닙니까.

    오해가 없게 하고 싶으면 글을 똑바로 쓰세요. 단어 선택에도 신중을 기하시구요.

    본인 의도는 그게 아니였다고 비겁하게 변명하고, 핵심을 바꾸지도 마시구요

    이 주제로 그렇게 많은 이야기가 오가는 와중에 여기서 그런 '오해'를 한 건 님 혼자입니다. 비슷하게 "니가 알고리즘을 알아?" 따위 저급한 논리로 비난한 분은 님 포함 딱 세 명이었구요.

    단지, 신기하게 그 세 분 모두 논리가 아닌 제 개인의 개발 능력에 대해 관심이 많으시더군요. 무슨 자신감으로 그러는 지는 잘 모르겠습니다만...

    Java 8 에서 HashMap 내부가 linked list 구조로 동작하다가, 키 검색시 Access 에 소비되는 O(n) 성능 개선을 위해 아이템 개수가 특정 수치로 증가시 Binary Tree 를 사용해서 O(log n) 을 보장하는 게 중요하지 않다구요?? 


    HashMap 을 쓸 때 내부 자료구조가 linked list 임을 몰라도 된다는겁니까? Time Complexity / Space Complexity 는 어떻게 계산하시려고 그거 몰라도 된다고 하십니까???


    프로그램 구현부터 때리고 퍼포먼스 체크를 테스트 데이터 집어 넣으면서 하실겁니까? 아니면 타이머로 밀리세컨 프린트해서 시간 차이로 퍼포먼스 테스트 하실건가요?


    아니면 나름대로 유닛테스트 셋업 구성해서 테스트할겁니까?


    100만건 10초 떨어졌는데 1000만건은 얼마나 증가할지, 10,000만 건은 얼마나 증가할지


    테스트 데이터 10배, 100배 추가하고 프로그램 수행시간 세월아 내월아 기다리실겁니까?

    이거 알고 있는 것이 Comparator, Comparable 차이 따위 아는 것보다 100배 경쟁력 있습니다.

    원래 알고 계셨나요? 그런데 그렇게 글을 쓰십니까??

    "현주소" 에 있는 개발자들이 "다음 레벨" 로 나아가기 위해서는 API 문서 보고 Comparator, Comparable 차이 알아야 된다? 그 다음 레벨이란 것이 지식 노트에 Comparator vs Comparable 차이점 선험&개념 설명할 줄 아는겁니까? 네? 정말 그런겁니까??

    아마 지금 반복하면 한 스무 번은 채울 것 같습니다만, 제 원 글의 내용은 초보 개발자가 무엇을 먼저 공부를 해야하는 지에 대한 것이지 알고리즘이 필요없거나 중요하지 않다는 내용이 아니었습니다.

    제 발... 좀... 글 좀... 제대로... 읽고 비난이든 비판이 좀 하세요.

    그리고 그런 자바나 C# 개발 입문자 입장에서 빅오 표기법 같은 걸 배우는 것이나 자료구조 내부 구현을 배우는 것보다 패러다임이나 그런 API 수준의 독해력일 기르는 게 낫다는 건 제 경험과 지식에 의하면 그렇습니다. 이견은 환영합니다만, 그러려면 "니가 수준이 낮은거야" 따위 보단 좀 진지한 근거를 가져오시기 바랍니다.

    순수하게 알고리즘과 자료구조만을 위해 2년 이상의 세월을 보내보신 적 있으신지요? 단언컨대 아니십니다.

    단도직입적이고 공격적으로 말해서 fender 님은 개발의 기본을 모르시는 분 입니다.

    저런 사상 자체가 fender 님을 그저 그런 개발자로 만드는겁니다.

    왜 저 따위 글을 쓰는 분들은 모두 남의 글 멋대로 오독해서 비난 퍼붓는 주제에 글 하나만 가지고 만나본 적 한 번 없는 개발자 실력이 허접하네 아니네 뭔 깡으로 그리 쉽게 단언하는지 이해하기 어렵더군요.

    솔직히 똑같은 사람되기 싫어서 제 실력이 어떻고, 무슨 프로그램을 만들었고, 주변 평가가 어떻고 이야기는 안하겠습니다. 주제 넘은 조언 하나 드리자면, 님이야 말로 좀 세상을 넓게 보는 시야를 키우기를 바랍니다.

    이 바닥엔 고수도 많고 파보면 어려운 분야도 많습니다. 자기 딴엔 좀 어려워 보이는 내용도 이해되고 경력도 쌓인 거 같아서 실력있다고 착각하면 주변에서 조용히 비웃습니다.

    솔직하게 말하자면, 님 글의 내용이야 말로 님의 개발자로서의 수준이 어느 정도인지 바닥을 뻔히 드러내고 있습니다.

    단지, 본문에 이야기한 대로 이 글의 주제가 누구 실력이 낫네 못하네를 따지자는 것도 아니니까, 그리고 전 님과 다르게 그게 의미 없고 유치한 짓인 걸 이해하니 그런 걸 근거랍시고 토론에 끌어들이지 않을 뿐입니다.

    나중에 이불킥하지 말고 자중하시기를.

    0
  • kapamaxcore
    10
    2017-07-01 11:15:47.0 작성 2017-07-01 11:26:22.0 수정됨

    휴~

    제가 이 글, 그리고 fender  님이 어떤 인간인지 이해하기 위해서 다른 글을 읽어보아야 할 이유가 있습니까???


    제가 언급한 핵심적인 항목에나 제대로 된 답을 해보시죠?

    왜 님이 말하는 패러다임이나 API 분석 능력이 알고리즘보다 중요하다고 말씀하시는 것인지.

    겨우 답변하시는 거라곤, 님 경험과 지식에 의하면 그렇다 가 전부 아닙니까.

    설득력이 있습니까??


    그렇게 빈약한 전제로 함부로 본인 생각 투영해서 판단한 글과 생각을 퍼뜨리지 말라는겁니다.

    거기서부터 이미 본인이 경솔하고, 깊게 생각 안 하고, 우월감에 젖어있다는 걸 간접 증명하는 겁니다.


    지금 fender 님 보면 그냥 " 난 알고리즘 몰라도 이렇게 잘 해왔는데? " 라는 사고방식을 갖고 계십니다.

    제가 틀렸습니까?


    이 바닥엔 고수 많죠.

    그러니까 함부로 이런 글 작성하지 마세요.

    억지 주장 펼치면서 그런 의도가 아니라고 징징거리지 마시고, 글을 똑바로 써주시구요.

    그리고 핵심이 무엇인지 파악해서 정확히 그 부분만 답변할 자신 없으면 그냥 댓글 달지마세요.


    지금 누가 유치한 방향으로 몰아가는지는 본인이 더 잘 아실텐데 남에게 책임전가를 참 쉽게 하시는 분이네요.

    0
  • fender
    9k
    2017-07-01 11:27:28.0 작성 2017-07-01 11:30:35.0 수정됨

    kapamaxcore// 아... 그래서 제 글은 읽을 필요도 없는데 그래도 까긴 해야겠다 이건가요? ㅎㅎ

    왜 제가 그런 개발자들 입장에서 패러다임이나 디자인패턴을 먼저 봐야하는 지에 대해선 적어도 A4지 열 장 분량 정도는 적었습니다.

    자기가 제대로 안읽어 놓고 근거를 대라고 윽박지르면 대체 어쩌란 건지...

    그냥 가던길 가세요. 주말에 기본도 안되먹은 이야기에 일일이 토달고 상대할 시간도 아깝습니다.


    0
  • kapamaxcore
    10
    2017-07-01 11:50:03.0

    타짜에서 유명한 대사가 하나 있죠.


    " 쫄리면 뒈지시든지 "


    기본도 안 된것이 누구인지는 본인이 더 잘 아실거에요.

    앞으로는 글을 좀 잘 쓰세요. 본인 의도 오해 없도록, 사람들이 정말 중요한 것 망각하지 않도록.

    0
  • 장지락
    534
    2017-07-01 16:30:14.0

    1. 알고리즘 중요, 하지만 소수가 잘하고 조직에서 수요가 적다. 가시적이고 혁신적인 성과가 있다면 대박친다.

    2. 아키텍쳐 중요, 하지만 배워야할 것이 많아 학습자의 꾸준한 연마가 필요하지만 조직에서 수요가 많고 대우가 좋다.

    3. 특정 조직/집단에서 "좀 잘 하는 친구(S급)"인 경우 1번/2번 모두 재미있게/열성적으로/자기주도로 꾸준한 학습과 실전 도전에 적극적적이다. 또한 이런 부류는 대학 학부/대학원에서도 전산필수 과정들을 충실하게 이수한게 보통이다.

    4. 나머지 1번만 잘 하는 이에 대한 경험 없고, 또 2번만 잘 하는 부류도 못 봤다. 단, 둘다 못 하는 경우는 많이 봤다.

    5. 학습 순서는 [ 특정 언어기초->데이터구조->알고리즘/OOP&고급언어)->SW공학/아키텍쳐 설계 ] 순서로 통상 커리큐럼이 구성된다. 중요도 및 난이도의 주관적 지수는 개개인 각기 다름.

    6. 전산학 학습에도 다른 분야와 마찮가지로 불변의 "왕도"는 없고 끊임없이 발생하는 새로운 목적지가 생겨날 뿐이다.




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