vollfeed
138
2017-06-16 15:16:28.0 작성 2017-06-17 20:26:34.0 수정됨
123
9764

알고리즘의 정체, 가치, 그리고 왜 해야 하는가?


알고리즘 주제로 얘기가 오가고 있는 걸 보니 입이 근질근질해서 몇 자 씁니다.


우선 제가 짚고 가고 싶은 게 있습니다.

여기에서 논란이 되긴 하나, 알고리즘이라는 과목?학문?이 무엇을 배우기 위한 것이며

어떻게 쓰기 위한 것인지에 대해서 고민되진 않는 것 같습니다.

그저 시중의 책이나 대학의 과목 정도로 여기는 것 같습니다.


제 지식 범주에서는 저런 생각은 매우 협소한 것입니다.

물론 알고리즘 책/강의는 선대의 컴퓨터 학자들이 고안한 최적의 방법을 소개하는 데 대부분의 분량을 씁니다.

그러나 그걸 외우기'만' 하라고 그러는 것이 아니라, 그들이 어떻게 문제를 해결했는지를 가르쳐야 하기 떄문입니다.


책/강의에서 다루는 각종 알고리즘, 버블/삽입/쉘/퀵/머지 정렬과 트리 탐색/밸런싱 기법, 그래프.해쉬 등등..

아마 논란에 보고 있는 많은 분들이 저렇게 십 수 년 전에 확립된 방법을 배우는 게 알고리즘이라고 생각하겠지만,

사실 저건 "그냥 예시"입니다. C/Java책의 For문 예시, Class 예시 같은 겁니다.


알고리즘에서 배우려면, 물론 예시를 알아야 합니다

하지만 조금 달리 생각해서, 저게 전부 그저 예시라면, 그렇다면 정말 핵심인 개념/원리/기법은 무엇인가요?


대부분 간과하는 (심지어 가르쳐 주지도 않고, 강사도 잘모르는..) 일반 모형(ADT), 평가 척도(BigO 표기) 전략(그리디, 분할정복, 다이나믹 프로그래밍, 백트래킹, 정보 이론, 프루닝, radix, ) 등이 진짜 알고리즘의 핵심입니다. 

즉 20년 전에 수학적 검증까지 끝난 것을 배워서 같은 걸 만들라고 가르치는 게 아닙니다.

이미 체계화된 예시를 통해서, 전략, 평가법, 등등을 익히고 그걸 "내 문제"에 적용하라고 배우는 것입니다.

즉 내가 "어떤 문제"를 만나 더라도, 모형, 평가척도, 전략을 가지고 해법을 찾을 수 있게끔 하기 위해서 가르치는 것입니다.

이게 "알고리즘 잘한다는 능력의 정체"입니다.



그러면 반박가능한 게 저런걸 하지 않아도, 또는 "내가" 하지 않아도 된다, 그래서 잘 몰라도 된다. 라고 할 수 있겠죠.

물론 현실적으로 하드웨어의 성능은 무섭도록 발전하고 있고,

대부분은 연산 능력으로 때울 수도 있습니다.


하지만 알고리즘이을 가르칠 때 무엇을 전제로 하는 지 아시나요?

어떤 문제에 대해서 "주어진 데이터 량 N"을 "일정한 시간 T" 안에 "확실히 해결" 할 수 있는 지를 대상으로 합니다.

무한의 시간, 메모리, 저장소가 있으면 뭐든 지 할 수 있겠죠. 될 때까지 해 보고 그걸 답하면 되니까요. CPU연산능력이 넘쳐나면 알고리즘 안 써도 됩니다. (가령 1ms만에 우주의 모든 원자의 상호작용을 계산할 수 있다던가..)

즉 알고리즘은 가치는 "제한된 환경에서 성능을 논의할 떄" 가치를 가집니다. 

그리고 현실은 항상 CPU능력과 메모리는 제한되어 있고, 역사적으로 CPU/RAM이 우리가 가진 데이터를 다 다루기에 충분했던 적은 없습니다.

다만, 저렴한 100만원짜리 서버도 동접 5000도 안되는 일상적인 업무(쇼핑몰, 게시판)등등을 처리하는 데는 CPU/RAM차고 넘친다는 거죠.

그래서 몰라도 게시판 만들 수 있습니다.


하지만 같은 게시판이라도, 사이즈가 커져서 제한된 서버머신(32CPU, 1TRam이라고 하죠)에서 정해진 시간 T(3초라 합시다)안에 무식한 방법(전부 다 되는지 안 되는지 직접해 보는 방법)으로 처리가 불가능하면 "알고리즘에 생사"가 걸립니다.


이게 "알고리즘 능력의 가치"입니다. 구멍가게는 존재도 몰라도 되고, 큰 사업을 하려면 목숨이 걸립니다. 



알고리즘이란 결국 "최적화"입니다. 

자 그럼, 이걸 바탕으로 보면 알고리즘이 중요한지?

그리고 알고리즘을 모르면 개발자이다?아니다? 에 대해서 각자 판단이 설 것 같습니다.


여튼 제 답은 이렇습니다.


* 알고리즘은 중요합니다.

단,  평생 하드웨어의 연산 능력이 문제가 될 만큼 큰 작업을 안하면 쓸 일이 없습니다.

하지만 과연 그럴까요?


* 알고리즘을 모르면, 개발자라고 불러주기 아깝습니다.

알고리즘은 이해하기 좋게 표현하면 "최적화"입니다. 아이디어만 제시할 거라면 최적화를 필요 없겠지만, 실제 사용할 물건을 만들 꺼라면 극한의 최적화는안 해도 적어도 쓸 만큼의 "최적화"는 해야 합니다. 

그런데 A급 최적화 전문가는 아니라고 해도, 최적화에 대해서 F학점, 낙제를 한다? 과연 개발자라고 할 수 있을지 모르겠습니다. 


물론 현실에서는 최적화 못해도 개발자라고 합니다. 머신파워로 해결하니까요.

그렇다고 해도, "코더"죠. 절대로 "프로그래머"가 될 수는 없다 봅니다.

현실적으로 개발자 = 코더 + 프로그래머 집단으로 본다면,

알고리즘을 몰라도 개발자(=코더)라고 칭할 수 있겠습니다.

하지만 연봉을 많이 주는 개발 회사는 개발자(=프로그래머)를 뽑으려고 하지, 개발자(=코더)를 뽑으려고 하지 않을 겁니다.


알고리즘을 모르면, 아무리 잘해 봐야  C급 개발자(보통은 D급 개발자)입니다. 

(어느 분의 말처럼, 저라면 안 뽑아요.)



결국 왜 해야 하는 지는 간단합니다.

사업 규모가 커서, 돈이 되는 쪽이 알고리즘적 능력을 필요로 합니다. 

디비 튜닝을 하던, 쿼리 최적화를 하던, 반정규화를 하던, 증분 업데이트를 구현하던, 캐쉬를 쓰던, 분할정복을 하던.. 

그 어떤 형태가 되던지요.


같은 사업을 해도, 최적화가 되면, 이익률이 놓습니다. 원가가 적게 들어 가니까요. 


결국 "알고리즘 = 최적화 = 이익율"이 되고, 이게 연봉으로 이어질 수 있습니다.

(물론 사업주가 다 먹을 수도 있겠지만.. 헬조선...ㅡㅡ...)




요약입니다.

* 어려운 일 하지 않고, 기술적으로 쉬운 일만 하면서 "가늘고 짧게 일"하고 싶다.  

    -> 하지 마세요. 누군가가 연봉 많이 받고 어려운 거 하겠죠.

    -> 그리고 가능한 빨리 치킨집 자본을 모으세요. 호봉이 올라가면, 그만큼 기대가 커져서, 쉬운 일만 할 수 없을 테니까요..

* 프로그래머로, 능력자로 대우 받으면서 "남들이 못하는 재미있는 일"하고 싶다.

    -> 알고리즘 못하면 다른 직업을 찾으세요. 

    -> 그게 싫으면, 남들 4시간 공부할 때 8시간 공부하는 겁니다. 단점은 커버해야죠. 그리고 장점을 찾으세요. 내 능력치 중 최고점을 내는 게 알고리즘 과목이어야 할 이유는 없습니다.








10
5
  • 댓글 123

  • 승천하는_흑염룡
    520
    2017-06-16 15:23:55.0

    치킨집 자본을 모으라니ㅋㅋ

    요새 치킨집도 하기 힘들지 않나요

    0
  • dkb
    1k
    2017-06-16 15:26:32.0

    수학을 배우는 이유가 체계화된 논리적 사고 능력을 기르기 위한 것과 같은 이유죠.


    0
  • vollfeed
    138
    2017-06-16 15:37:57.0

    승천하는_흑염룡

    뭐 그래도 C,D 급 개발자로 일가족 부양하는 것보다는 쉽지 않을까요? 

    요리나 경영, 마케팅에 재능이 있을지도 모르죠.


    dkb

    우리나라는 교육이 병신이라, 수학은 문제풀이만 시키고(인간 계산기 만들기 ㅡㅡ...)

    알고리즘 수업때는 그냥 암기를 하더군요.. 쯧...



    0
  • iops
    1k
    2017-06-16 15:43:56.0

    높은 TPS를 보장하는 어플리케이션을 만드는데 중요한게 알고리즘이라고 보기 너무 어렵습니다.

    높은 TPS를 내려면 네트워크, 소켓튜닝, 로드밸런싱, 샤드, 레플리카, 프로토콜버퍼같은 rpc, nio, redis같은 in memory db, kafka같은 고가용성 mq, 리눅스 관리, 자동스케일아웃, curcuit breaker같은 failover 등을 알아야지 알고리즘이란 단어 하나로 퉁쳐서 대답하면 안되죠.


    제가 면접을 보는 입장이면 사이즈가 큰 웹어플리케이션을 구현할때 필요한거가 뭐가있냐라는 질문의 대답으로 알고리즘이라고 대답하면 탈락시킬거 같습니다. 

    3
  • dkb
    1k
    2017-06-16 15:50:43.0

    inyl/

    그런 요소도 물론 중요하지만,

    구현할때  시간복잡도를 줄이는 것도 매우 중요하니까요.


    그리고 시간복잡도는 진짜 알고리즘 문제가 맞죠.


    0
  • 가가멜리
    1k
    2017-06-16 15:57:18.0

    위키 참조

    애플 주식회사(영어: Apple Inc.)은 컴퓨터휴대전화 등의 전자제품을 생산하는 미국의 기업이다.


    전자제품을 생산하는데.. 전자제품 특허와 제조 기술이 없는 apple 은 d급 회사이고

    삼성전자는 s급 회사이다

    알고리즘 중요 .. 인정

    알고리즘을 모르면 c급 d급 은 인정 못하겟네요.

    0
  • fender
    9k
    2017-06-16 16:03:34.0 작성 2017-06-16 16:56:30.0 수정됨

    백 만 번 째 강조합니다만, 저는 한 번도 알고리즘이 필요없다고 한 적 없습니다.

    그리고 역시 비슷한 만큼 반복한 이야기입니다만, 원글의 문제는 객체지향 언어 입문자들의 공부 우선순위에 대한 것입니다.

    그럼 한 가지 묻겠습니다. 알고리즘이 정말로 모든 공부에 우선한다면, 예컨대 자바를 배우는 개발자는 객체 지향이나 디자인 패턴은 언제부터 배우면 되나요? 빅오 표기법을 배우고나서? 아니면 다이나믹 프로그램을 배우고 나서 하나요?

    그리고 알고리즘을 모르면 최적화를 못한다는데, 그럼 알고리즘만 잘 알면 프로파일러 못다루고, 동시성의 문제 이해 못해도 대용량 시스템 얼마든지 만드나요?

    "그런 것도 다 필요하다"고 하실 거면 그럼 알고리즘만 알고 아직 아키텍쳐 수준의 이해가 없는 개발자는 그럼 무슨 급의 개발자인가요?

    예컨대 제가 다른 개발자에게 "리액티브 아키텍쳐(Reactive Architecture)가 뭔지 모르면 넌 'D급'이니 개발자도 아닌 코더에 불과하다, 그러니 가서 치킨집이나 차려라"라고 하면 납득하실 건지요?

    아니면 제가 알고리즘 잘하는 개발자에게 디자인 패턴이나 객체지향 패러다임 문제 내서 못맞추면 'D급'이라고 하면 인정하실 건가요?

    알고리즘 중요한 거 맞습니다. 그런데 세상에 중요한 게 알고리즘만 있는 게 아닐 수 있다는 가능성 정도는 생각해보셨으면 합니다.

    6
  • iops
    1k
    2017-06-16 16:06:27.0

    dkb / 시간복잡도가 중요하다는것은 동의합니다만

    최근에 알고리즘이 마치 군대때 바르는 빨간약처럼 만능약처럼 통용되서 불리는것 같은 느낌이 듭니다.

    이거 해결 하려면 어떻게 해야되요? 알고리즘 알아야됨

    저거 해결 하려면 어떻게 해야되요? 알고리즘 알아야됨


    현실에 여러종류의 약이 있는것처럼 복잡한 어플리케이션에 알고리즘 하나만 가지고 돌아가는 것은 없습니다.

    제가 위에 언급한 것들을 알아야 서비스가 가능한데 알고리즘 하나만 알면 모든게 해결되는것처럼 쓰인글은 좀 많이 두렵습니다.

    1
  • vollfeed
    138
    2017-06-16 16:08:33.0

    inyl

    높은 TPS를 내려면 알고리즘적 사고 능력이 당연히 있어야합니다.


    언급하신 것들

    네트워크, 소켓튜닝, 로드밸런싱, 샤드, 레플리카, 프로토콜버퍼같은 rpc, nio, redis같은 in memory db, kafka같은 고가용성 mq, 리눅스 관리, 자동스케일아웃, curcuit breaker같은 failover 

    등등의 제품이나 기법등은 전부 "성능을 내기위한 어떤 전략" 또는 "문제를 해결하기위한 어떤 전략"을 쓰고 있습니다.

    달리말하면,  Big O류의 성능 평가 척도로 치환 할수 있습니다. 

    그래서 어떤 제품을 쓰면 어느정도 성능을 기대할수 있고, 뭐뭐는 호환성이 있을꺼다라거나,  어떻게 조합할수 있을지 등을 가늠할수 있습니다. 

    알고리즘적 사고를 모르고서 대략적인 성능 기대값 및  총평 낼 수 있을까요?


    가령 Redis가 hash를 쓰는지 B Tree를 쓰는지, 그래서 NLgN인지 C인지 등등을 통해서, 총평을 낼수 있습니다.

    Redis가 어떤 경우든(ex>10억 레코드 1TB사이즈라도) 정해진시간 T(ex> 0.01 ms)안에 데이터 줄테니 써라 라고 하는게 아니자나요?

    우리 아키텍쳐를 이렇습니다. 테스트케이스는 이렇게 디자인했고, 그때 성능이 이렇습니다.

    라고 소개를 하지.)


    알고리즘적 사고가 되면 어떤 새로운게 튀어 나와도 학습하고 그걸 평가할수있습니다. 즉 그걸 쓸때 어떤 이점이 있는지 알수있다는 거죠. 

    뭐 이걸 케바케로 외우고 매번 누군가에게서 결과만 들어도 되긴하겠지요. 


    inyl님도 결국 저 각 요소들을 채용했을 때, TPS에 얼마나 기여를 할지를 결국 알고리즘에서 배운걸로 평가하고 있으실텐데요? 



    0
  • 카트맨
    2k
    2017-06-16 16:09:51.0

    inyl 님과 생각이 같습니다. 

    두명의 경력직 면접 지원자에게 반응속도 최적화, 빅데이터 튜닝 등에  대한 질문을 했을 경우


    redis, kafka, spark, 잘 알려진 방법들의 장단점 같은게 나오면 통과지만

    알고리즘이 어쩌고 이렇게 떠들면 탈락시킬거 같네요. 


    0
  • fender
    9k
    2017-06-16 16:11:10.0 작성 2017-06-16 16:24:48.0 수정됨

    분산 캐시, 비동기 API, 메시징 시스템, 빅데이터, 직렬화, 리플리케이션 등등의 주제를 모두 다 '빅오로 치환할 수 있다'라고 퉁치는 건, 쉽게 말하면 "니가 아무리 날고 기는 개발자라도 어차피 코딩은 영어로 할테니 영어부터 배우라"는 수준의 이야기입니다.

    2
  • iops
    1k
    2017-06-16 16:17:47.0

    vollfeed / 아뇨 저는 알고리즘으로 평가하지 않습니다.

    저는 서비스의 스펙을 측정할때 모두 BMT 벤치마킹 테스트 진행해서 결론냅니다.

    JMeter, Ngrinder, JMH, Gatling등으로 직접 돌려보고 성능 결론내지 현실에서 BIG O만 가지고 대충 n log n이니 이정도 겠거니 판단하는건 너무 위험합니다.


    근데 결국 이런 행동도 알고리즘 아니냐 하면 뭐 할말은 없습니다.


    0
  • 하마
    4k
    2017-06-16 16:20:19.0 작성 2017-06-16 17:37:41.0 수정됨

    난 또 정렬,검색이 알고리즘이 아니다 그냥 예시다 라고 했을때 먼가 엄청난게 나오나 했더니..
    동적프로그래밍,백트래킹,최적화..등등 이다 라니요.........

    야구에서 달리기,배트휘두르기, 공던지고,받기는 야구가 아니다. 야구 교본 앞에 항시 나온다.
    진짜는 교본 뒷쪽에 있거나, 다른 교본에 있는 싱커,포크볼,스틸,선구안이다 라는 것과 비슷한데요 ㅎㅎ

    p.s

    알고리즘'도' 열심히 공부하자라는 거라면 저는 어느정도 동감합니다. 알고리즘은 항상 공부해두면 좋죠. 알고리즘 공부하지 말자는 건 아니고..정렬,검색은 기본으로 어디에서나 중심을 잡아준다고 생각하기에 님의 정렬,검색을 낮추어(?) 보는 모습, 진정한 알고리즘(?) 과 구분짓는 모습은 제 생각과는 매우 다르다고 말해두죠.


    0
  • seibeki
    124
    2017-06-16 16:23:43.0

    흠... 도대체 어디서일하길레 알고리즘을 모르면 개발자가 아니라고 말하는지 모르겠네...  인터뷰볼때 칠판에다가 sorting 알고리즘 문제내는 병신 HR 꼰대 스타일같음.  플그래밍 하다보면 99.9999% 케이스는 알고리즘 필요없고 프레임워크에대한이해도 + 뭘빨리 습득하는 좀더좋은 대가리 + 구글링 스킬 + 커뮤니케이션 스킬임.  코드리뷰할때 조차도 알고리즘 뭐뭐 하는 닝겐은 싸다구임.  진심 지금까지 코딩하면서 알고리즘 깊게파고들어가서 뭔가를 최적화시켰다면 박수쳐드림.  근데 이러면 일느리다고 욕안먹나? 99.9%의 최적화는 사용하는 스택바꾸면서 이루어지는거고 0.1%미만이 알고리즘에대한이해도로 생기는걸꺼임.  

    1
  • dkb
    1k
    2017-06-16 16:40:40.0

    음. 이거 빅오 이야기가 나오는게 저 때문에 그런건 아니겠죠? -.- 괜히 부담스럽네요.


    사견입니다만, 각 도구들이 유용한 분야가 있습니다.

    알고리즘은 최적화 할 때.

    일반적인 설계, 구현 단계에서 디자인 패턴.

    (사실 작명능력이 제일 유용한듯 -___-)


    ...뭐 사실 어디가 느려요 하면

    알고리즘 꺼내기전에 SQL 튜닝이 직빵인거 같기는 하지만요 ㅠ.ㅠ


    이리저리 굴러먹다보면 전 영역에서 쑥쑥 성장하겠지만

    사실 디자인패턴이 좀 더 유용할거라고 보는게,

    안이쁜 코드는 보기가 싫지 않나요...


    1
  • vollfeed
    138
    2017-06-16 17:01:02.0

    fender  //

    일단 제글에 대해서 오해하신것 같습니다.

    근데 제 글은 학습순서나, 개발의 다른 요소인 OOP, 아키텍쳐 등과 알고리즘을 비교한적이 없습니다.

    다만 이슈가 알고리즘인데, 그 알고리즘의 정체에 대해서 다들 너무 피상적으로 애기하는 것 같아서 그걸 좀 꼬집은 내용입니다.


    학습순서 등에 대한 글을 쓰셨다고 알고있습니다.

    학습순서에 대해서는 대학등에서 채택하는 일반적 순서, 언어 > 자료구조 + 알고리즘 > OPP 순서를 맞다고 생각하지만, 절대로 WaterFall 식이 아니로 Prototyping 개발처럼 순환식어야 한다고 봅니다.

    여튼, 학습순서 문제는 제가 이 글로 애기하고 싶은것과는  초점이 아주 다른 별개의 문제라고 봅니다.


    글고 리액티브는 같은 후기 패러다임하고는 다르죠. 그건 몰라도 분야가 틀린것 뿐입니다.

    하지만, 컴퓨터 위에서 돌리는데 컴퓨터에서 성능을 평가하고 비교하는 가장 원초적인 도구를 모른다면 그건 문제가 있지 않을까요? 

    그리고 알고리즘을 제가 '충분 조건'처럼 말한것으로 해석하였는데, 제가 의견은 알고리즘은 컴퓨터에서 성능을 평가, 개선 하는데 필요한 '필요 조건'이다 입니다. 

    리액티브는 '충분 조건'도  '필요 조건'이 될수는 없습니다. 하지만 설계에 대해서 단일 모듈 단일 책임의 원칙은 '필요조건'입니다.


    어찌 생각할지 모르겠으나, '필요 조건'에  결격이 있다면, 저는 D급 밖에 못 주겠습니다.


    0
  • vollfeed
    138
    2017-06-16 17:05:24.0

    inyl //

    이게 빨간약 처럼 글쓴것처럼 보인다면 솔직히 저도 걱정입니다.

    제가 전달하고 싶은걸 비유하자면 소설을 쓰려면 '적어도' 국문법 낙제는 안된다 정도입니다.

    알고리즘 과목 내용은 사실상 개발자 사이에서 초등 산수 아닌가요? 

    수학 포기자는 몰라도 산수 포기자가 개발자하는건 아니라고 봅니다.






    0
  • vollfeed
    138
    2017-06-16 17:10:16.0

    fender //

    사족인데, 영어 못하면, 개발자로써 자료 입수처가 10분의 1로 줄어들텐데요..? 영어 회화는 못해도, 읽기는 해야한다고 봅니다.

    그리고 아무리 OOP 다이어그램이나 서비스 구조도로 날고 기어도, 시간 복잡도를 평가할 능력이 없다면, 성능 분야 문제는 전혀 해결할수 없을테니 알고리즘 공부해두라는 애기는 맞습니다.


    아키텍쳐 설계시 각 세부 요소는 상식적으로 통용되는 성능을 낼것을 가정합니다만, 

    그렇다고 해도, 핵심 모듈이나 연산이 중요한 경우, 또는 시중에 나온것으로 해결이 어려운 경우에는 다양한 기법을 동원해서 해결할수 있는 구조를 구축하지 않나요? 


    0
  • vollfeed
    138
    2017-06-16 17:12:50.0

    inyl //

    벤치마크 결과도,

    벤더가 주장하는 "아키텍쳐 및 그로 인한 기대 성능"이  "실제로 만족하는지" 평가하는 단계이죠.

    하지만 애초에 어떤게 검증할 가치가 있는 대상인지 선별하는 것은 머릿속에서 합니다.

    초보가 격는 문제중 가장 큰것 중 하나가, 무엇이 검토대상이고 무엇은 그럴가치가 없는지 구분조차 못하는것에 있습니다.



    0
  • vollfeed
    138
    2017-06-16 17:23:37.0

    seibeki // 

    SKY중 한개 대학원에 있으면서 사업합니다.

    주 연구는 시멘틱 웹 분야고, 대충 1,400,000,000개의 엣지가 존재하는 그래프 구조의 데이터로  

    집에 굴러다는 i7으로 어찌 지지고 볶아서 뭔가  할수있는 방법을 찾고있는 뭐 그런 일입니다. 

    나이 먹을만큼 먹어서 꼰대일지도 모르죠. 


    글고 그거 압니까?

    SW는 100%완벽이란건 없고 99.9999%를 위해 달려가는 겁니다.

    하지만 디자인이 50%진척도에서 평가받을수있지만 SW는 99%가 아니면 0%한것 같습니다.

    글고 95%까진 성능 이슈가 없겠지만, 99%갈때까진 글쎼요..?


    글고 지금 알고리즘에 대해서, T시간내에 푸는 것만 애기했는데, 

    짐작으로 맞추는게 아니라 "정확히 풀어내는것"으로 가면 전혀 다릅니다.


    ps. 박수칠 준비나 하세요.

    0
  • vollfeed
    138
    2017-06-16 17:29:42.0

    가가멜리 //

    찌라시에 속으니 좀 안타깝습니다.

    삼성과 애플이 특허 소송하는 뉴스는 들으셨나요?


    튀김기 없는 피자집은 D급, 화덕이 없는 치킨집도 D급으로 평가하라고 받아들일것 같으니 많이 안타깝네요.

    0
  • fender
    9k
    2017-06-16 17:48:08.0 작성 2017-06-16 18:05:57.0 수정됨

    vollfeed // 제가 그렇게 말씀 드린 것은, 최근 몇 일 동안 이어진 알고리즘 관련 논쟁이 바로 그 자바나 C# 같은 언어의 입문자가 객체지향 패러다임이나 디자인 패턴보다 알고리즘을 먼저 배워야 하는가에 대한 문제제기로 비롯된 것이기 때문입니다.

    물론, 페이스북 등에서 제 글을 '자바 개발자면 응용만 잘해도 먹고 산다' 쯤으로 곡해해서 비난하는 분들이 몇몇 있었고, 덧글에서 비슷한 식의 해석으로 기본 지식의 가치를 저평가하는 분이 없었던 것은 아닙니다.

    하지만 이 논쟁을 촉발한 일련의 제 글들도, 그리고 논쟁에 참여한 대부분의 분들의 답글도 모두 논의의 핵심 주제가 공부의 우선순위에 대한 것을 전제로 하고 있습니다.

    그런 상황에서 "이야기를 지켜보자니 시야가 너무 협소한 것 같다"는 식으로 싸잡아서 일침을 날리려면 최소한, 이제까지 이야기하던 주제가 무엇인지는 파악을 하셨어야 하고, 만일 주제와 다른 원론적 말씀을 하시고 싶으시다면 기존 토론 내용을 언급해서 비판할 이유는 없다고 봅니다.

    참고로 전 알고리즘은 몰라도 자료구조는 내부 구현이나 자바 API를 떠나서 따로 볼 필요까진 없더라도 최소한 알아야하는 기본지식에는 속한다는 이야기는 이 토론에서 몇 차례 한 적이 있습니다.

    그리고, 자바나 C# 입문자가 자료구조를 제외한 알고리즘을 언제 어디까지 배우는 것이 좋은가 정도의 이견이라면, 저라면 제 생각과 다르다는 이유만으로 'D급 개발자'나 '치킨집' 운운하면서 비난하고 무시하진 않을 듯 합니다.

    또한, 말씀처럼 리액티브 프로그래밍 같은 개념의 이해가 중요한 것은 그런 분야에 대한 이야기입니다만, 제가 지적하는 것이 정확하게 그런 이유이기 때문에 예로 든 것입니다.

    vollfeed님 께서는 모든 최적화의 문제는 결국 알고리즘으로 귀결되기 때문에 이를 모르면 성능이 중요한 시스템은 다룰 수 없다고 하지 않으셨나요?

    그리고 아시겠지만, 실제로 대용량, 고가용성 시스템을 최적화 하기 위해서 필요한 지식은 다른 분도 지적하신대로 특정 함수 구현의 알고리즘 수준의 최적화가 아닌 보통 메시징 시스템이나 분산 캐시 등 시스템 전체의 아키텍쳐 수준의 지식을 요구합니다.

    예컨대 알고리즘을 잘하는 임베디드 개발자라면 아마도 대부분의 성능 문제는 함수 최적화 수준에서 해결할 수 있을테고, 데이터 샤딩이니 백 프레셔니 하는 수준의 이야기를 모른다고 'D급 개발자' 소리를 들을 이유는 없을 겁니다. 말씀대로 그건 그냥 분야가 다를 뿐이니까요.

    그런데 반대로, 대용량 고가용성 시스템을 구축하는데 그 임베디드 개발자를 데려온다면, 그런 내용을 잘 몰라도 어차피 최적화는 모두 알고리즘 문제이니 바로 잘할 수 있을까요? 그게 아니라면 왜 임베디드 개발자는 알고리즘만 잘해도 고급 개발자로 인정하는데, 객체지향이나 분산 환경 개발자는 빅오 표기법 모르면 자신의 분야를 아무리 잘해도 'D급 코더'라고 단정을 하는 걸까요?

    그리고 '단일 모듈 단일 책임 원칙'을 말씀하셨는데, 아시다시피 그건 알고리즘과는 전혀 다른 축인 디자인에 대한 공부를 해야 알 수 있는 지식이고, 그런 개념이 없으면 제대로 된 설계를 할 수 없습니다.

    그렇다면 알고리즘을 모르면 최적화를 못하니 'D급 코더'라는 논리가 성립하면, 마찬가지로 그런 설계 원칙을 모르면 'D급 코더'라는 논리는 성립이 안되는 건가요?

    그리고 자바 같은 언어라면 결국 그런 설계 원칙을 공부하는 것이 객체 지향 패러다임이나 디자인 패턴을 익히는 것이 아닌가요?

    물론 둘 다 잘할 수 있다면 좋겠습니다만, 애초에 토론의 주제인, 비전공 입문자 입장에서 시간의 제약이 있다면 둘 중에 어느 한 쪽을 먼저 공부할 수 밖에 없는 것은 필연입니다.

    그렇다면, 알고리즘을 먼저 선택해서 자바를 가지고 최적화된 코드를 C처럼 짜는 개발자와, 객체지향/디자인 패턴을 먼저 선택해서 최적화는 부족해도 제대로된 구조를 올릴 수 있는 개발자가 있다면 전자는 기본기가 충실한 개발자이고 후자는 'D급 코더'라고 비하할 근거는 또 무엇인가요?

    그리고 '최적화가 안된다'는데 입문 단계 개발자가 잘 검증된 자바와 스프링 등 API 기반으로 개발할 때 구문 단위에서 심각하게 성능 저하가 발생할 가능성이 높겠습니까, 아니면 객체 지향 개념이 없는 개발자가 자바 언어를 C처럼 이해해서 쓰면서 제대로된 구조를 만들 가능성이 높겠습니까?

    마지막으로, '알고리즘의 의미를 피상적으로 이야기한다'라고 비판하셨지만 오히려 알고리즘의 정의를 기존 토론의 주제와 무관하게 지나치게 확장하는 것은 vollfeed님이라고 생각합니다.

    알고리즘을 "문제를 해결하기 위한 어떤 전략"이라고 극단적으로 광의로 정의해버리면 그럼 디자인 패턴은 "문제를 해결하기 위한 어떤 전략"이 아니라는 뜻인가요?

    다른 분들이 '빨간약'에 빗대어 vollfeed님의 정의를 비판한 것은 바로 이 점을 지적한 것입니다.


    덧말: '사족'으로 첨언하신 내용은 지금 봤습니다만... 정말로 대용량 고가용 시스템의 구축이나 최적화 작업이 함수 구현의 시간 복잡도를 수식으로 계산하는 차원의 문제라고 생각하시나요?

    극단적인 이야기로, 빅오 표기법조차 몰라도 예컨대 아카나 Vert.x 같은 시스템의 구조나 왜 그런 시스템을 도입했을 때 동시성 문제 해결에 도움이 될 수 있는지는 충분히 이해할 수 있습니다.

    반면에 알고리즘을 마스터한 개발자가 이벤트 기반 분산 시스템을 한 번도 접해보지 않았다면 알고리즘 지식만 가지고 그런 시스템을 구축할 수 있습니까?

    아키텍쳐 설계시 각 구성요소는 어차피 '상식적으로 통용되는 성능을 낸다'라고 말씀하셨는데, 그런 대용량 아키텍쳐를 구성하는 문제를 '오라클 데이터베이스를 구매할지 MS-SQL을 구매할지' 쯤의 문제로 이해하시는 것이 아닌가 싶습니다.

    그리고 전 영어 못하지 않습니다. 그런데 제가 언제 개발자가 영어 못해도 된다고 했던가요?

    2
  • iops
    1k
    2017-06-16 17:59:14.0

    vollfeed / 음

    굴러다니는 i7에 하는것을 포기하고 aws에 인스턴스 여러개에 graph database 샤딩해서 올리시고 

    분석하셨음 14억개정도 되게 금방 끝나고 그시간에 다른거 더 하셨을거 같은데...

    다쓴 서버 다시 내리면 비용도 안나오고요.

    알고리즘도 중요하지만 모든것을 알고리즘으로만 해결하려는것도 안좋은 습관입니다.


    1
  • vollfeed
    138
    2017-06-16 18:18:18.0

    Inyl // 

    저를 이상한 사람 만드려 하는 군요.

    여튼, 해당 이슈는 연구로써 하는 것이고, 사업은 아닙니다.

    연구는 당장 기술로 쉽지 않는 것에 대해서 궁리해서 돌파구를 찾는 것입니다.

    분산 시스템을 몰라서 안쓰는게 아니고, 그렇게 해야 더 나은 단계로 갈수있으니까 하는겁니다. 

    개인에게 서버 10씩 준비하라고 할수는 없으니까요.



    0
  • vollfeed
    138
    2017-06-16 19:43:14.0

    fender // 

    제 글을 다시 한번 봐주시면 좋겠네요.

    일단 저는 학습 순서에 대한 의견 개신을 한게 아닙니다.

    상당히 많은 사람들이 OOP나 설계에 대해서 다양한 애기를 하고 있는거에 반해

    알고리즘에 대해 애기하는 사람이 너무 없어서 내용 추가를 한것입니다.


    공부의 우선순위에 대한 것을 전제로 하고 있습니다. 라고 하셨는데,  그렇다면 제 글은 기존에 논의된 공부의 우선순위에는 첨언한게 없습니다.

    "알고리즘에 대해선 자료가 없어서 추가한다"의 입장입니다.

    절반은 "알고리즘적 능력이란 무엇이며 어떻게 작용하는가?" 이고,

    절반은 앞 내용을 전제할떄, 알고리즘 능력과 개발자의 평가에 대한 저의 의견입니다.

    싸잡아서 일침이라고 하셨는데, 무엇을 싸잡았나요? 그 앞문단 내용을 보자면 "알고리즘이라는 과목 학문... 여기는것 같다" 입니다. 이게 토론에 나온 많은 이슈를 포괄하지 않고, 

    알고리즘 분야 자체에 초점을 맞춤을 분명히 하였습니다.


    덧붙여 언제 배우는게 좋은가는 의견을 낸적 없고,

    어디까지 배우는게 좋은가에 대해서는 의견을 냈습니다.

    언제 배웠는지에 따라서 사람의 능력이 평가되는건 불합리하지만,

    어디까지 배웠느냐, 또는 배웠는가? 안 배웠는가에 따라 평가를 하는 것은 불합리 하지 않습니다.

    그리고  'D급 개발자'나 '치킨집'을 비난으로 받아들일 수도 있겠습니다.

    그러나 하위 25%에 속한다 라고 표현하면 비난이 아니라 비판인지요? 다들 치킨집을 자조적으로 말하는 상황에서 "다른 커리어"라고 표현하면 비난이 아니라 비판인지요?

    현실에 감정이 상하는건 현실 탓이지, 제 탓이 아닙니다.


    현대 수준의 서비스의 최적화는 물론 아키텍쳐 수준의 지식을 요합니다. 그러면, 그 아키텍쳐 수준의 지식을 받아들일떄, 알고리즘적 요소, 시공간의 Trade Off나 입력량 N에 대한 관계 등 제반 지식이 없이 받아들일수 있습니까?  

    각 요소의 기대 성능에 대한 척도는 입력량 N에 대한 CPU 사용 RAM사용 Disk사용, Overhead등 알고리즘 과목에서 언급되는 요소를 이용하지 않고, A 아키텍쳐와 와 B 아키텍쳐의 장단점을 비교할수 있습니까?

    비교할수 있다고 해도, 교육용으로 더 작은 사이즈인 함수나 모듈단위의 평가를 건너뛰고, 산업적 요구에 맞춰서 더 고도화되고 정교해진 것을 예시로 하여 얻는 이점은 무엇입니까?

    그리고 시공간 트레이드 오프나 오버해드등 에 대한 기초적인 제반 지식이 없는 고급 개발자분의 예시를 들수 있으실런지요? 컨설팅 레벨에서 SW단위로  이러한 것을 결정하더라도 직접 구현하지 않는다 뿐이지, 구성요소에 대해서는 저 도구를 사용하여 평가를 합니다. 

    그리고  설계 원칙을 모르면 'D급 코더'라는 논리도 성립이 됩니다. 

    단일 모듈 단일 책임 원칙을 줄이면, 단일함수 단일 책임 원칙이기도 합니다. 당연히 모르면 D급입니다.


    물론 둘 다 잘할 수 있다면 좋겠습니다에 동의를 합니다.

    그러나 설계 A 알고리즘 C나 설계 C 알고리즘 A가 개발업무를 하는데 문제가 없으나,

    설계 A 알고리즘 D나 역으로 설계 D 알고리즘 A같은 구성은 실제로 존재하기도 어렵지만, "과락"에 해당하는 것이라 생각되지 않는지요?

    레이서급으로 차를 몰아도 주차를 못하면, 면허증은 안나와야 하는것 아닌가요?


    자바를 가지고 최적화된 코드를 C처럼 짜는 개발자와 그 역을 예시로 들었는데, 

    간단히 정리하자면, "과락"은 어쩃든 "과락"입니다. 하나를 덜 잘할수는 있어도, 못 하는건 말이 안되는것입니다. C개발자가 D급이 아니라면, 당연히 파일단위로 모듈화가 되어, 단일 파일 = 단일모듈 이며 단일 책임을 져야하는것 아닌가요? 


    어째서 C는 한 파일안에 모두 때려박는게 맞다라고 생각하시는건지 모르겠습니다.

    제대로된 C개발자가 JAVA에서 제대로된 구조를 못만들 이유가 없으며, 반대로 못만들어 낸다면, 동작 위주의 D급 C언어 코딩을 하고 있는 것입니다.


    그리고 어째서, 디자인 패턴과 알고리즘을 완전한 대척점으로 보는지 모르겠습니다.

    알고리즘은 학문적으로 닦이는 시기상 명령형 패러다임이 보편적인 시기이어서 그렇게 보일수 있으나, 객체 지향과  완전한 대척점에 있는 것이 아닙니다. 

    알고리즘이 문제 해결 전략을 찾는 것에 초점을 맞춘다면, 디자인 패턴을 그 전략을 좀더 모듈화 된 구조로 만드는 것에 초점이 놓이고 있습니다. 

    Flyweight패턴과 Dynamic Programming의 공통점은 없는지요? Back Tracking 전략과 Memento패턴 및 Chain of Responsibility는요?

    제 의견은 디자인 패턴은 "문제 해결 전략 + 모듈화"입니다. 같이 배워도 무방하지만 집중해서 배우는게 나을수도 있죠. 그건 개인 선택이라고 봅니다. 애초부터 GOF가 OOP로 구현하다보니 반복되어 나오는 패턴에 대해서 체계를 잡은 것인데, 무엇을 구현하고 있었을까요? 결국 그전에 나왔던 문제 해결 전략(알고리즘 과목이죠)을 상황에 맞게 구현하고 있던것입니다. 그 문제 해결의 전략이라는게 하늘에서 뚝떨어진게 아닙니다.

    지나치게 확장이라고 하셨는데, 글쎄요. 제 사견은 What이 아니라 How, Why를 알아야한다라서 확장이라는 것에 동의할수는 없겠습니다. OOP든 디자인 패턴이든 국사든 물리든 How, Why를 알아야한다고 봅니다. 그러나 커뮤의 대다수가 이를 지나친 확장으로 간주할 것이라는 건 알고 있습니다.

    대용량,고가용과  Operation레벨에서 최적화는 분명히 차이가 납니다. 그런데 말입니다. 미시 경제학이든 거시 경제학이든 기본원리는 같은걸 깔고 가는 것입니다. 분명 거시 주력인 사람과 미시 주력인 사람이 서로 바꿔서 하면 탈이 나는게 당연합니다. 하지만, 그밑에는 같은걸 깔고 가는 것은 분명합니다. 

    어차피 알고리즘을 공부한다고 하여도,  20년전에 굳어진 케케묵고 그만큼 밑에 깔리는것만 배우기에, 알고리즘을 배운다고 미시적으로 마스터가 된다고 보기는 어려울것 같습니다.

    '상식적으로 통용되는'에 대해서는 마치 SW구매 문제로 치환하셨는데, 이게 어떻게 그리 해석되는지 모르겠습니다. 

    아키텍쳐는 설계할때 각 세부 요소에 대해서 특별한 뭔가를 동원하지 않더라도 보편적인 것을 낼것을 기대합니다. 특수하면 전부 명시를 하죠. 특수한만큼 다른것도 영향을 받아서 전체적인 밑그림도 바뀌죠. 

    여튼 RDBMS라면, B-Tree와 Index등 기본적 골격이 있으니 그에 대한 통용되는 기대값이 있습니다. Hash기반의 메모리 DB라면 역시 기준선이라는것이 있는거고, TripleStore같은 Graph구조라면 그래프 구조라는 특성에 기인해서 상식적으로 기대할 수 있는 (달리말해 교과서에서 배울수있는) 기대할수 있는 특성이 있습니다.  Row  중심인지 Column중심인지에 따라서도 기대할수있는게 다르고, 통신규격이 HTTP-JSON인지, Binary인지에 따라서도 기대값이 형성되죠. 


    ps. 영어는 그냥 논란을 보는 사람에게 더 하고 싶은 소리였습니다.


    2
  • 전재형
    3k
    2017-06-16 20:09:00.0

    vollfeed 씨도 프로그래머에 대한 자부심이 대단하신 것 같네요. ㅎㅎ

    다음 말이 눈에 꽂힙니다.


    레이서급으로 차를 몰아도 주차를 못하면, 면허증은 안나와야 하는것 아닌가요?



    0
  • iops
    1k
    2017-06-16 20:16:54.0 작성 2017-06-16 20:21:46.0 수정됨

    vollfeed / 이상한 사람 만드려는 의도는 아니였습니다.

    만일 그렇게 보였다면 사과드리겠습니다.



    그리디, 분할정복, 다이나믹프로그래밍, 백트래킹, 정보 이론, 프루닝, radix이 알고리즘의 핵심이라고 하셨으니 어떤 프로그램이 이런 알고리즘들을 사용해서 퍼포먼스를 극대화 하였고 좋은 선례가 되었는지 설명해주시는 글이라면 급을 나누는 글보다 아마 좀 더 많은 사람들에게 공감과 찬사의글이 되지 않았을까 생각됩니다.


    ex) hadoop은 mapreduce알고리즘을 이용해서 기존에 분석하지 못하였던 대량의 데이터를 분석할 수 있었습니다

    0
  • vollfeed
    138
    2017-06-16 20:20:49.0

    전재형 //

    영어나 국어나,

    알파벳(자음,모음), 단어, 문법, 상용구(속담, 경언), 문단 구성, 논리 전개, 기법(비유,대조)등

    다양한게 모여야 문학이든 비문학이든이 되는 것처럼


    SW개발도 정말 다양한 요소 위에 서있는 겁니다.

    하나를 좀 못해도 되요.

    시인이 산문이 그리 감동적이지 않아도 되고, 소설가가 시 좀 못써도 돼죠. 

    근데 아예 하질 못한다? 그건 말이 안되는겁니다.


     

    0
  • iops
    1k
    2017-06-16 20:31:35.0 작성 2017-06-16 20:34:00.0 수정됨
    그리고 하나만 더

    글쓴님도 알고리즘 수업을 암기를 하는것에 부정적이신거 같은데


    보통 신입한테 알고리즘을 배우라고 하면

    공부하는 방식을 몰라서 결국 책한권 사거나 강좌 등록해서 처음부터 끝까지 셀렉션소트,이진트리 뭐시깽이등 달달 외우면서

    하나하나 타이핑 해가면서 공부하는데 저는 이게 별로 좋지 못한 방식이라 생각합니다.

    일반적인 이 책이나 강좌에서 알려주는 알고리즘은

    지금 production level에서 사용하는 알고리즘들과 많이 차이가 난다는것에는 동의하실겁니다.

    싱글머신에서 13억 edge를 연산해보셨으면 더 잘 아실거라 생각합니다.


    어떤 알고리즘이 중요한 알고리즘이고 현재 production level에서도 쓸 수 있는 알고리즘이며 이런것들을 어떻게 잘 공부할 수 있는지에 대해 글을 공유하신다면 아마 많은 공감과 어린개발자들에게 많이 도움이 될거라 생각합니다.

    0
  • vollfeed
    138
    2017-06-16 20:34:25.0

    inyl // 

    제 스스로 저를 평가하기에  알고리즘이 B면, OOP가 A입니다.

    절대 알고리즘에 목매는 사람이 아닙니다.

    애초에 성능을 쥐어짜내기 위한 이상 야릇한 코드를 극혐하고, 한번 코딩하면 수십번 읽음을 강조합니다.


    그리고 사실 그렇지 안나요. 글로 예시를 들어봐야 별로 전달이 안된다는 것이요.

    여튼, 예시 하나 들자면, 유명항 책인 "생각하는 프로그래밍"의 전화번호부에 관련 애피소드가 Radix Sort가 사용한 문제 해결 전략을 기똥차게 응용한 사례입니다.

    radix 정렬은 수(연속된 0~9)는 n진수일 때 각 자릿수에 따른 고정된 정보량이 있으며, 이를 이용해서 정렬을 합니다.

    전화번호부 에피소드에선 각 전화 번호 = 특정 Radix의 발생횟수 1 로 간주하여(달리말하면, 100만 진수로 치환하여) 1bit로  미국의 전화번호를 표현했죠. 


     

    0
  • vollfeed
    138
    2017-06-16 20:39:42.0

    inyl //

    그건 참 힘들죠.

    근데 별수 없이 외우긴해야 합니다. 

    토론을 통해서 How,Why를 깨칠수 있는데, 외우질 않으면 토론 자체가 성립이 안되니까요.

    솔직히 좋은방법은 저도 못찾았습니다. 


    게다가 시대에 따라서 변하죠.

    예전에 Graph문제, 트레블링 세일즈맨 같은건  "어차피 PC로 그래프 다룰일이 별로 없어" 였습니다.

    하지만 지금 차세대 DB는 그래프 구조로 가려는 움직임도 있고,

    Facebook은 GrahphAPI라고, 자기들 데이터를 GRAPH로 제공하겠다는 것을 확실히 하고 있죠.

    웹 자체도 그래프 구조라서, 그에 따른 알고리즘이 다수 나오구요.


    이러다 누군가가 NP를 풀면, 그에 따른 뭔가가 나오면서, 또 틀이 바뀔수도있죠.


    0
  • vollfeed
    138
    2017-06-16 21:03:56.0

    inyl //

    알고 계실것 같지만 mapreduce전략은 하둡이 최초로 한게 아닙니다. 유명하게는 만들었죠. 

    기본적으로 분할- 정복(Map연산)을 하되, 그 결과가 완벽하지 않으니까 합병 + 정제(Reduce)하는 구조죠. 

    저렇게 쪼갠다음에 MAP 연산도  1 머신에서 돌아갈만한 사이즈이다 뿐이지 최대한 많은 량을 빨리 처리하려면 뭐든 기법이 필요하죠.

    Reduce연산은 기본적으로 MAP의 결과의 합이 중복등 요소를 가지고 오는게 기본인 상태인데,

    그걸 Identity를 정확하게 식별해서 합쳐야 하는게 기본이니, 이에 대한 최적화를 어떻게 할것인가?를 고민도 해야죠. 


    그리고 Map Reduce가 말이 되려면, 일단 문제가 분할 정복이 가능해야하고, 

    분할된 문제의 답의 합이 최종 결과의 합이거나, 

    거기에 특정한 연산을 더 하여 합이 될 수 있어야 합니다.


    때문에 Graph에서 2점을 있는 모든 경로(달리말해 2 entity의 관계) 같은건 Hadoop처럼 데이터를 분할해 놓고, 거기에 연산을 적용하는 방식으로는 효과적으로 못풀어요. 


    0
  • fender
    9k
    2017-06-16 21:16:35.0 작성 2017-06-16 21:28:20.0 수정됨

    vollfeed // 스스로 작성하신 글을 다시 봐야할 것은 vollfeed님인 것 같습니다.

    다시 한 번 이야기하지만, 디자인 패턴과 알고리즘의 우선순위에 대한 주제는 이미 사이트 안팍으로 몇 일 째 뜨겁게 토론되는 내용이고, 몇몇 분들이 원글의 의도를 '알고리즘은 필요없다'로 곡해해서 적지 않게 논란이 되기도 했습니다.

    그 상황에서 "토론을 보고 있자니 입이 근질근질해서" 글을 쓴다면서 '알고리즘 모르면 개발자도 아니다'라고 선언하면 그걸 누가 디자인 패턴과 관계없는 이야기로 받아들이겠습니까?

    뭐 그렇게 주장하신다니 인정해드리겠습니다. 그럼 결국 vollfeed님이 하고 싶은 말씀은 객체지향을 먼저 배우건 말건 알고리즘 모르면 개발자도 아니란 것이 되는 건가요?

    그렇다면 저도 vollfeed님과 똑같은 논리로, 알고리즘을 알건 말건 객체지향을 못하면 개발자도 아니니 치킨집이나 차리라고 하면 납득 하실건가요? vollfeed님이 정말 디자인 패턴과 알고리즘의 선후 관계나 상대적 중요성에 관심이 없다면 반박하실 이유가 없는 주장 아닌가요?

    제가 디자인 패턴과 알고리즘을 대척점에 놓고 있다고 하셨는데, 저는 두 가지가 '다른 축'의 지식이라고 강조를 했지 어느 한 쪽이 불필요하다고 한 적이 없습니다. 반면에 vollfeed님은 아키텍쳐나 패러다임 차원의 이야기도 모조리 알고리즘으로 환원해서 알고리즘 지식의 절대적 중요성을 역설하고 계십니다.

    그리고 디자인 패턴이든 알고리즘이든 둘 다 'why'에 해당하니 똑같이 중요하다고 말씀하시면 그건 결국 스스로의 주장과 모순되는 이야기가 됩니다.

    디자인 패턴이든 알고리즘이든 둘 다 원리니까 똑같이 중요하다? 도대체 누가 "개발할 때는 원리 따위 알 필요없다"라는 주장을 했나요?

    아니면 아무튼 알고리즘이 본인 표현처럼 '생명처럼 중요하다'? 그럼 디자인 패턴은 덜 중요하단 이야기가 되는 것 아닌가요?

    반박을 피하자고 두루뭉실 양다리를 걸치면 아무 의미도 없는 이야기가 되는 것입니다.

    그리고 이젠 '알고리즘'이란 개념이 확장하다 못해 "CPU 사용, RAM사용, Disk사용"을 재보는 것까지 포괄하는 이야기가 되는 건가요? 역시 의미있는 주장이 되려면 둘 중에 하나만 하셔야 합니다... 성능을 측정하려면 빅오 표기법이건 이진 탐색이건 클래식한 알고리즘 커리큘럼 정도는 마스터 해야한다고 하시던지, 아니면 CPU나 메모리 사용량 측정할 줄 알고 양자간 트레이드 오프 관계 이해하면 가능하다고 하시던지요.

    양쪽을 합쳐서 "성능은 아무튼 CPU 사용량 따지는 거니 알고리즘이 제일 중요하다"라고 한다면 모든 프로그램은 아무튼 CPU에서 도는 거니 무조건 칩 설계부터 배워야 한다는 거나 뭐가 다른 이야기인가요?

    언제부터 'CPU 사용량', '디스크 사용량', '트레이드 오프', '오버헤드' 정도의 용어가 'C급'이니 'D급'이니 개발자 등급까지 따질 정도로 대단한 개념이었던가요?

    그리고 앞서 말한 메시징 아키텍쳐나 리액티브 프로그래밍 등을 '컨설팅 수준의 이야기'라고 하셨는데, 이를 무슨 파워포인트에 서버 그림 그려놓고 A 제품 구매할지 B 제품 구매할지 정도 따지는 수준의 이야기로 이해하시고 있는 게 아닌가 우려됩니다.

    왜 제가 그 발언을 구매 문제로 치환하느냐 반문하셨는데, "시중에 나온 제품'이라면 어차피 상식적으로 통용되는 성능"을 낼테니 진짜 중요한 건 알고리즘이라고 주장하지 않으셨던가요?

    참고로, 그런 단위의 성능에 대한 문제는 말씀하신 내용과 정반대입니다. 오히려 알고리즘 단위의 최적화는 보통 자바 같은 언어의 개발자가 손대기 힘든 계층에 이미 구현되어 있습니다. 설사 무작위 접근을 해야할 때 연결 리스트를 썼다고 그게 병목이 되서 시스템 성능이 크게 저하되는 일 같은 건 생각보다 드문 일입니다.

    반면에, 같은 시스템을 전통적인 서블릿 기반으로 할지, 비동기 메시징 기반으로 할지, 또 후자라면 메시지 라우팅은 어떻게 처리하고 풀이나 서킷 브레이커 등은 어떻게 활용할지, 직렬화는 어떤 방식으로 처리할지, 조회와 갱신 단을 분리할지 말지 등과 같은 문제는 성능에 절대적인 영향을 줍니다.

    그리고 그런 문제는 무슨 '컨설턴트'가 파워포인트에 그림 그려서 결정할 문제가 아니라 개발자가 설계를하고 플랫폼을 설정해서 처리하는 문제이고, 그런 문제를 이해하려면 당연히 상당한 노력이 필요합니다.

    직접 경험하고 익숙하신 분야가 단일 노드에서 대용량 그래프 데이터를 직접 조작하는 그런 문제라면 훨씬 저수준의 알고리즘 지식이 훨씬 중요하게 작용할 것은 쉽게 짐작할 수 있습니다만, 문제는 요즘 시대에 고가용 대용량 시스템을 구축하는 데 있어서 모든 문제가 그런 차원의 내용으로 환원되지 않는다는 점입니다.

    그리고 말씀하신 RDBMS에 대한 예에서도 앞서 지적한, 반박을 피하기 위해 주장을 모호하게 만드는 문제를 확인할 수 있습니다.

    물론 RDBMS 내부 뜯어보면 이런 저런 알고리즘 많이 적용되어있을 겁니다. 아니면 저장 방식이나 프로토콜 따지면 무언가 성능 관련된 내용이 나오기야 하겠죠. 그런데 그게 클래식한 전산과 학부 수준 알고리즘을 공부하는 문제와 어떻게 이어지는 주장이 됩니까? 그걸 반드시 모두 알아야 스키마 설계하고 SQL 최적화를 할 수 있나요?

    똑같은 논리를 따지면 RDBMS 내부에도 이런 저런 구조적 설계는 많이 들어가있을 겁니다. C++ 같은 언어로 짰다면 객체지향도 썼겠죠. 그럼 모든게 객체지향이니 개발자는 무조건 객체지향을 알아야 데이터베이스도 쓸 수 있다는 주장을 할 수 있는 건가요?

    개발의 모든 것이 '알고리즘'이니 알고리즘을 배우라는 이야기는, 결국 개발을 잘하려면 개발을 잘해야 한다는 동어 반복이 될 뿐입니다. 그리고 그런 식으로까지 일반화 하면 '알고리즘' 자리에 '디자인'을 집어넣던 '아키텍쳐'를 집어넣건 아무 상관없는 무의미한 주장이 됩니다.

    1
  • vollfeed
    138
    2017-06-16 21:18:47.0

    inyl // 

    그리고 아까 TPS에 대한 면접에 대한 예시도 저도 같은 생각입니다

    면접은 현재 능력을 평가해서 쓸 사람을 뽑는거지, 

    대학에서 잠재력 있는 학생을 뽑는게 아니죠.

    알고리즘적 사고는 그많은 기법이나 제품등을 서로 비교 평가하면서 제대로 파악하기 위해서 꼭 필요한거지, 그 자체로 해결되지는 않습니다. 

    그러니 면접에서 알고리즘이면 다된다고 하면, 20년전껀 공부했는데 5년전꺼는 안했다는 소리가 되죠. 

    하지만 5년전꺼를 제대로 파악하려면 20년전꺼를 알아야하는게 함정이라고 생각합니다.

    하지만 우리회사가 당장쓸거에 대해서는 정확히 몰라도, 10년에 유행한 비슷한 무엇인가에 대해서 정확이 파악하고 있으며, 그것을 비교 분석하여 평가/ 가치 판단할수 있다면, 

    시간만 준다면 우리회사가 쓸것도 할수있을겁니다.


    반면에 우리회사가 쓸 툴/프레임워크에 대해서 메뉴얼을 보고 명령 몇개를 안다고 해도, 

    결국 어떻게 동작하며 왜 쓰는지를 모르면 문제 상황에 대응할수 없다고 봅니다.


    그런 경우 이 인력을 모니터링 요원으로는 쓸수 있겠는데, 저는 개발시키고 싶지는 않아요. 



    0
  • fender
    9k
    2017-06-16 21:36:29.0 작성 2017-06-16 21:36:56.0 수정됨

    반면에 우리회사가 쓸 툴/프레임워크에 대해서 메뉴얼을 보고 명령 몇 개를 안다고 해도, 

    결국 어떻게 동작하며 왜 쓰는지를 모르면 문제 상황에 대응할수 없다고 봅니다.

    그래서 자바 개발자라면 객체지향과 디자인 패턴이 중요하다는 이야기입니다. 자바 개발자가 코드 수준에서 사용하는 프레임워크는 대부분 자바로 되어 있고, 그건 결국 디자인 패턴의 거대한 덩어리이니까요.

    전산과 학부 커리큘럼 수준의 알고리즘을 완벽하게 마스터한 개발자가 디자인 패턴을 모르면 스프링 프레임워크의 구조나 동작 원리를 이해할 수 있나요, 아니면 디자인 패턴을 배우려면 그 수준의 알고리즘부터 반드시 배워야 하나요?

    이 토론의 시작은 바로 그걸 따지는 내용이었습니다.

    1
  • 초오찌
    5k
    2017-06-16 21:46:18.0

    fender//하아.. 펜더님이 이 기분일까요. 너무 답답합니다. 펜더님 주장은 알고리즘 필요없다가아닌뎅. 0아니면1로만 생각하는게 답답..알고리즘을 공부하기 전에 좀더.... 

    0
  • vollfeed
    138
    2017-06-16 21:49:04.0

    fender //

    한가지만 언급하겠습니다.

    최초의 토론이 fender님이 애기한 "학습 순서"라고 합시다.

    그런데 많은 사람의 참여인해  토픽이 "알고리즘 공부가 필요한가?"로 넘어갔습니다.

    여전히 주제가 "학습순서"인가요? "알고리즘 공부가 필요한가?"인가요?

    최초의 글을 썼다고 흐름을 좌우할수 있는건 아닙니다. 


    그리고 이미 "설계 원칙을 모르면 'D급 코더'라는 논리도 성립이 됩니다."라고 명확히 애기했습니다.

    설계 원칙이 OOP가 아니라 함수형일수는 있겠죠, 그런데 그걸 모르면 중급이라고 하기 어렵다고 봅니다.

    내가 애기한걸 나에게 납득하냐고 물으면 어떻게 합니까? 

     

    그리고 본인글은 아키텍쳐 수준 지식이면 알고리즘은 필요없다고 안보이는줄 아십니까? 저말고 이미 여러 사람들이 그렇게 오해한 상태 아닌가요? 그런 문제로라면 저보다 더 문제가 되실텐데요?

    저는  알고리즘 지식의 절대적 중요성을 강조하긴 했습니다만, 아키텍쳐 수준의 지식을 받아들일때, 알고리즘적 지식이 "필요하냐?필요하지않냐?"를 물었습니다. 

    다시말하지만 "필요조건"은 "충분 조건" 아닙니다. 

    [필요조건과 충분조건] 이거라도 좀 보세요

    환원은 A => B 아닌가요? 언제부터 필요조건이 필요충분조건이 되었는지 모르겠네요.

    게다가 스스로 모순이 된다고 주장하는건 제가 "알고리즘'만' 절대적으로 중요하다"라고 할때나 성립되는거 아닙니까?

    다시한번 말하겠습니다.

    레이서급으로 차를 몰아도 주차를 못하면, 면허증은 안나와야 하는것 아닌가요?

    제 원글에 "디자인패턴, 설계, 모듈"등등의 단어는 등장도 안합니다. 간과 되고 있는 알고리즘을 강조좀 했더니, 그럼 너는 "디자인 패턴 무용론자구나!" 라고요?

    그럼 맥주가 맛있다고 하면, 자동으로 "와인,소주,막걸리,위스키"는 맛없다고 한게 됩니까?

    맥주산업이 중요하닥하면, 자동으로 나머지 산업은 안중요하다고 되는게 됩니까?

    fender님은 자기만의 세계에서 좀 나오시기 바랍니다. 

    솔직히 제 글을 읽지 않으신것 같습니다. 


    게다가 "이젠 '알고리즘'이란 개념이 확장하다 못해" 라구요?

    그럼 Fender님의 알고리즘 개념을 어디 한번 들어봅시다. 어떻게 정의 내리시는지요? 


    위키피디아 한번 빌려볼까요?  

    An algorithm is an effective method that can be expressed within a finite amount of space and time[1] and in a well-defined formal language[2] for calculating a function.[3] Starting from an initial state and initial input (perhaps empty),[4] the instructions describe a computation that, when executed, proceeds through a finite[5] number of well-defined successive states, eventually producing "output"[6] and terminating at a final ending state. The transition from one state to the next is not necessarily deterministic; some algorithms, known as randomized algorithms, incorporate random input.[7]


    effective method ~ finite amount of space and time, 스페이스 & 타임이 무엇을 의미하는지 모릅니까?

    Time은 CPU사용 시간이고 Space는 RAM/Disk 사용량입니다.

    CPU/RAM 재보는게 뭐라고요?


    게다가 컨설팅 애기는 더 웃기거 아십니까? 컨설팅 애기를 제가 할떄는 메시징 아키텍쳐나 리액티브는 근처에도 없습니다. 고급개발자의 예시를 들라고 하면서 들어지요. 

    게다가 그 아래 설계 원칙 모르면 D급이라고 했네요.

    제대로 읽으시긴 한겁니까? 솔직히 합리적 의심이 드네요.


    제가 언제 "시중의 것 = 상식적 성능" 이라고 했나요?

    반대로, "상식적 성능 > 시중의 것" 인 경우에  "구조를 구축해서 해결" (구매말고 직접 구현으로 해결한다는 의미입니다.)한다고 했지.

    그 밑에 내용은 맞는내용인데 뭐라고 안하겠습니다.

    제 주장을 제대로 읽지 않고 성급한 결론을 마음속으로 낸뒤, 저를 비난하기 위해서 맞는 내용 가져온거니까요. 


    여튼 지금까지, 

    fender님이 "제 주장을 마음대로 해석하여 날조한 증거"를 가져왔으니, 

    이번에는 제가 "반박을 피하기 위해 주장을 모호하게 만드는"을 하기위해서 무엇을 어떻게 했는지 가져와보시기 바랍니다.








    0
  • fender
    9k
    2017-06-16 22:27:06.0 작성 2017-06-16 22:50:01.0 수정됨

    그런데 많은 사람의 참여인해  토픽이 "알고리즘 공부가 필요한가?"로 넘어갔습니다

    도대체 알고리즘 따위 누구에게도 필요 없다는 주장을 하는 그 '많은 사람'이 어디에 얼마나 있던가요? 오히려 그런 주장을 할 때마다 저 뿐 아니라 다른 많은 분들도 그런 이야기가 아니라면서 적극적으로 변호를 했을텐데요?

    그리고 이미 "설계 원칙을 모르면 'D급 코더'라는 논리도 성립이 됩니다."라고 명확히 애기했습니다. 설계 원칙이 OOP가 아니라 함수형일수는 있겠죠, 그런데 그걸 모르면 중급이라고 하기 어렵다고 봅니다.

    내가 애기한걸 나에게 납득하냐고 물으면 어떻게 합니까?

    그래요? 그럼 본문의 의도가 알고리즘도 알고 패러다임도 알고, 아키텍쳐도 다 잘 알지 않으면 모두 'D급 코더'니 "치킨집이나 하라"는 건가요?

    그리고 본인글은 아키텍쳐 수준 지식이면 알고리즘은 필요없다고 안보이는줄 아십니까? 저말고 이미 여러 사람들이 그렇게 오해한 상태 아닌가요?

    아, 그럼 그렇게 오해하고 쓰신 건 맞다는 건가요? 그리고 그렇게 오해한 거라면, 그런 식으로 오독해서 여러 사람 싸잡아서 비판한 건 '여러 사람들'이 아니라 이 사이트에선 님이 딱 두 번 째 입니다.

    그리고 제 글이 그런 의도 아니라고 이야기한 게 모르긴 해도 다섯 번은 족히 넘을 겁니다. 그걸 굳이 다 무시하고 어떻게든 꼬아서 보겠다는 사람들의 독해 능력이나 심보를 제가 왜 책임져야 하나요?

    저는  알고리즘 지식의 절대적 중요성을 강조하긴 했습니다만, 아키텍쳐 수준의 지식을 받아들일때, 알고리즘적 지식이 "필요하냐?필요하지않냐?"를 물었습니다.  다시 말하지만 "필요조건"은 "충분 조건" 아닙니다.

    제 원글에 "디자인패턴, 설계, 모듈"등등의 단어는 등장도 안합니다. 간과 되고 있는 알고리즘을 강조좀 했더니, 그럼 너는 "디자인 패턴 무용론자구나!" 라고요?

    아니, 좀 아까까지 디자인패턴이나 아키텍쳐 지식과의 선후 관계와 아무 관계도 없다고 그렇게 강변하지 않으셨나요? 알고리즘이 그런 지식에 대한 필요 조건이면 그게 선행 관계를 따지는 글과 뭐가 다릅니까?


    A가 B의 필요조건이면 B를 하려면 A를 먼저하라는 이야기 아닌가요? 그런 건 알고리즘에 안나오나보죠?


    Time은 CPU사용 시간이고 Space는 RAM/Disk 사용량입니다. CPU/RAM 재보는게 뭐라고요?

    그래서, 학부 수준 알고리즘 커리큘럼 안배우면 CPU 사용 시간하고 디스크 사용량 못 따져요?

    게다가 컨설팅 애기는 더 웃기거 아십니까? 컨설팅 애기를 제가 할떄는 메시징 아키텍쳐나 리액티브는 근처에도 없습니다. 고급개발자의 예시를 들라고 하면서 들어지요. 

    그 아키텍쳐 이야기가 어디서 등장했는지 말입니다...

    현대 수준의 서비스의 최적화는 물론 아키텍쳐 수준의 지식을 요합니다. 그러면, 그 아키텍쳐 수준의 지식을 받아들일떄, 알고리즘적 요소, 시공간의 Trade Off나 입력량 N에 대한 관계 등 제반 지식이 없이 받아들일수 있습니까? 

    바로 그 '현대 수준의 서비스 최적화를 하기 위한 아키텍쳐 수준의 지식'이 바로 메시징 기반 구조니 CQRS니 리액티브 프로그래밍이니 하는 차원의 이야기란 겁니다.

    이번에는 제가 "반박을 피하기 위해 주장을 모호하게 만드는"을 하기위해서 무엇을 어떻게 했는지 가져와보시기 바랍니다.

    충분한 대답이 됐나요?



    0
  • vollfeed
    138
    2017-06-16 22:54:18.0

    아뇨 전혀 되지 않았습니다. 

    우선 제 주장이 무엇입니까? 

    그리고 그것에 제가 무엇을 섞었습니까? 

    그리하여 제 주장이 어떻게 달라 졌습니까? 

    그래서 그 결과가 모호합니까?




    덧. 많은사람의 참여는  주장이 아닙니다.  필요없나요? 하고 질문하는 사람은 참여 아닙니까?


    본문의도는 기초알고리즘 안할꺼면 치킨집하라 맞습니다.

    댓글로 논의하며  설계도 중요하니 안되면 치킨하라 추가된게 맞습니다.

    하지만 주장이 바뀐건 아니죠.


    님 최초의 글은 본적이 없고 다들 오해한다고 하니 오해한다고 알고있습니다. 게다가 제가 오해했다고 먼저 주장하셨습니다. 


    전 CPU 따지는데 전공이 필요하다고 한적없죠. 

    물타기하지 마시죠.cpu왜 재냐고 님이 물었죠.


    아키텍처 얘기는 긁어오셨네요? 그럼 컨설팅어디있습니까? 저는 아키텍쳐 = 컨설팅 수준의 얘기라고 한적없습니다. 그리 해석한 이유를 해명하시기 바랍니다.

    또 말하지만 제 글의 컨서팅을  고급개발자 예시로 차용했을 뿐이고, 등장시 아키텍쳐 얘기는 없습니다. 잘라붙이기 하지 마시죠


    충분하지 않으니 다시 해주시죠

    0
  • vollfeed
    138
    2017-06-16 23:09:48.0

    fender //  

    또있습니다. 

    저는 fender님이  제 주장을 마음대로 해석 내지 짜집기 해석을 하여

    날조한 증거를 가져와서 보였습니다.

    그러니, 날조한 것을 인정하시든지, 날조가 아니라는 증거를 대시기 바랍니다.


    0
  • fender
    9k
    2017-06-16 23:34:15.0 작성 2017-06-16 23:40:09.0 수정됨

    vollfeed//

    본문 의도는 기초알고리즘 안할꺼면 치킨집하라 맞습니다.

    댓글로 논의하며  설계도 중요하니 안되면 치킨하라 추가된게 맞습니다.

    그래서, "알고리즘 과목 모르던 디자인 패턴을 모르던 다 'D급'이니 때려치고 치킨 팔아라"는 뜻이란거죠?

    치킨값 많이 내리겠군요.


    저는 fender님이  제 주장을 마음대로 해석 내지 짜집기 해석을 하여 날조한 증거를 가져와서 보였습니다. 그러니, 날조한 것을 인정하시든지, 날조가 아니라는 증거를 대시기 바랍니다.

    저기요... '날조'라는 건 이런 걸 이야기하는 거에요:

    (1) 전 CPU 따지는데 전공이 필요하다고 한적없죠.  물타기하지 마시죠.

    (2) CPU 사용 RAM사용 Disk사용, Overhead등 알고리즘 과목에서 언급되는 요소를 이용하지 않고, A 아키텍쳐와 와 B 아키텍쳐의 장단점을 비교할수 있습니까?

    아, 이젠 "'알고리즘 과목'은 전공이 아니라도 책 사서 배울 수 있다는 뜻이었다"라고 빠져 나가실 건가요? ㅎㅎ


    아키텍처 얘기는 긁어오셨네요? 그럼 컨설팅어디있습니까?

    여깄네요:

    ...A 아키텍쳐와 와 B 아키텍쳐의 장단점을 비교할수 있습니까?

    비교할수 있다고 해도, 교육용으로 더 작은 사이즈인 함수나 모듈단위의 평가를 건너뛰고, 산업적 요구에 맞춰서 더 고도화되고 정교해진 것을 예시로 하여 얻는 이점은 무엇입니까?

    그리고 시공간 트레이드 오프나 오버해드등 에 대한 기초적인 제반 지식이 없는 고급 개발자분의 예시를 들수 있으실런지요? 컨설팅 레벨에서 SW단위로  이러한 것을 결정하더라도 직접 구현하지 않는다 뿐이지, 구성요소에 대해서는 저 도구를 사용하여 평가를 합니다.

    그러니까 저나 다른 분들이 이야기하는 '아키텍쳐'라는 게 '컨설팅 수준'에서 SW로 부하 측정하는 이야기가 아니라구요.

    본문에서 '일반 모형(ADT), 평가 척도(BigO 표기) 전략(그리디, 분할정복, 다이나믹프로그래밍, 백트래킹, 정보 이론, 프루닝, radix)' 같은 게 진짜 '알고리즘의 핵심'이니까, 그런 거 모르면 'D급'이니, 안할 거면 때려치고 "치킨집이나 하라"면서요?

    그리고 그 '근거'라는 게 알고리즘은 '최적화'이고 아무튼 'CPU' 들어가고 '오버헤드', '트레이드 오프' 따지는 건 다 '최적화'니까 알고리즘이 필요하다는 식으로 무지막지한 논리를 펴니까 아키텍쳐 수준의 성능은 그런 것만 있는게 아니라고 한 거 잖아요?

    0
  • fender
    9k
    2017-06-16 23:47:08.0 작성 2017-06-16 23:47:42.0 수정됨

    vollfeed// 그리고 밤도 늦었는데 이 쯤에서 그만하시죠? 님 생각대로 진짜 님 주장이 다 논리적이고 제가 억지를 쓰는 거면 이 글 읽는 분들도 다 그렇게 느끼지 않겠습니까?

    과연 누가 다른 사람들을 우습게 여기고, 논리를 수시로 바꾸고, 성능 문제를 이해 못하는지는 이 쯤 서로 떠들었으면 사람들이 각자 알아서 판단하겠죠.

    0
  • vollfeed
    138
    2017-06-16 23:51:44.0 작성 2017-06-16 23:53:36.0 수정됨

    맥락 한번 볼까요?


    fender: 

    그리고 이젠 '알고리즘'이란 개념이 확장하다 못해 "CPU 사용, RAM사용, Disk사용"을 재보는 것까지 포괄하는 이야기가 되는 건가요? 


    vollfeed: 


    게다가 "이젠 '알고리즘'이란 개념이 확장하다 못해" 라구요?
    그럼 Fender님의 알고리즘 개념을 어디 한번 들어봅시다. 어떻게 정의 내리시는지요? 
    위키피디아 한번 빌려볼까요?  
    An algorithm is an effective method  that can be expressed within a finite amount of space and time[1]  and in a well-defined formal language[2]  for calculating a function .[3]  Starting from an initial state and initial input (perhaps empty ),[4]  the instructions describe a computation  that, when executed , proceeds through a finite[5]  number of well-defined successive states, eventually producing "output"[6]  and terminating at a final ending state. The transition from one state to the next is not necessarily deterministic ; some algorithms, known as randomized algorithms , incorporate random input.[7] 
    effective method ~ finite amount of space and time, 스페이스 & 타임이 무엇을 의미하는지 모릅니까?


    Time은 CPU사용 시간이고 Space는 RAM/Disk 사용량입니다.
    CPU/RAM 재보는게 뭐라고요?


    fender: 

    그래서, 학부 수준 알고리즘 커리큘럼 안배우면 CPU 사용 시간하고 디스크 사용량 못 따져요?


    vollfeed: 

    전 CPU 따지는데 전공이 필요하다고 한적없죠.  물타기하지 마시죠. 

    fender 

    저기요... '날조'라는 건 이런 걸 이야기하는 거에요:  

    (1) 전 CPU 따지는데 전공이 필요하다고 한적없죠.  물타기하지 마시죠.
    (2) CPU 사용 RAM사용 Disk사용, Overhead등 알고리즘 과목에서 언급되는 요소를 이용하지 않고, A 아키텍쳐와 와 B 아키텍쳐의 장단점을 비교할수 있습니까?

    알고리즘 과목에서 언급되는 요소 = CPU 사용 RAM사용 Disk사용, Overhead등 =Time & Space  입니다.


     

    fender 

    여깄네요:

    ...A 아키텍쳐와 와 B 아키텍쳐의 장단점을 비교할수 있습니까

    비교할수 있다고 해도, 교육용으로 더 작은 사이즈인 함수나 모듈단위의 평가를 건너뛰고, 산업적 요구에 맞춰서 더 고도화되고 정교해진 것을 예시로 하여 얻는 이점은 무엇입니까?

    그리고 시공간 트레이드 오프나 오버해드등 에 대한 기초적인 제반 지식이 없는 고급 개발자분의 예시를 들수 있으실런지요? 컨설팅 레벨에서 SW단위로  이러한 것을 결정하더라도 직접 구현하지 않는다 뿐이지, 구성요소에 대해서는 저 도구를 사용하여 평가를 합니다. 


    그러니까 저나 다른 분들이 이야기하는 '아키텍쳐'라는 게 '컨설팅 수준'에서 SW로 부하 측정하는 이야기가 아니라구요.


    "그리고", But이 나오면 주제 전환 모릅니까?


    한가지는 제가 취소 하죠.
    님은 날조한게 아니라 
    커뮤니케이션 능력이 낮은겁니다.


    0
  • fender
    9k
    2017-06-16 23:55:19.0 작성 2017-06-16 23:58:07.0 수정됨

    한가지는 제가 취소 하죠.
    님은 날조한게 아니라 
    커뮤니케이션 능력이 낮은겁니다.

    뉘에... 뉘에... 자-알 알겠으니 맘대로 생각하시고 이 쯤 에서 그만하죠.

    뭐 다들 저보다 커뮤티케이션 능력도 월등하다면 모두 님 말이 다 맞다고 이해해주실텐데 뭐가 그리 걱정인지 ㅎㅎ

    0
  • vollfeed
    138
    2017-06-17 00:07:52.0

    논리에 근거를 두고 토론하는 것에 흥미를 느끼고 있었는데,


    그저 뉘에 뉘에 라니 생각보다 유치하시네요.

    0
  • Bill
    54
    2017-06-17 00:14:31.0

    좀 이해가 안되는 부분이 있습니다.

    알고리즘을 모르면 잘해봐야 C,D급 개발자라고 하셨는데 알고리즘을 모른다는 정의가 무엇인가요??

    저를 예로 들면 4년차 풀 스텍 개발자이고 기본적인 정렬 알고리즘은 대략 어떤것이다 알고 있고 시간 복잡도(BigO)에 대해서도 어느정도는 알고 있습니다. 고급 알고리즘은 말만 들어봤지 실제 사용해 본적은 없고 어떻게 돌아가는지도 잘 모릅니다.

    개발하는 분야가 계산 성능이 매우 중요하다면 알고리즘을 통한 최적화가 필수이겠지만 제가 지금까지 해온 프로젝트 중에는 아쉽게도 없었습니다. 

    그러면 저는 잘해야 C급 또는 D급 개발자가 되는건가요? 저는 아니라고 생각합니다. 

    실제로 알고리즘을 많이 알고 잘하는 개발자와도 같이 일을 해본적이 있으나 알고리즘을 잘 안다고 해서 개발을 잘하는건 아니더군요..


    2
  • vollfeed
    138
    2017-06-17 00:30:13.0

    Bill //

    알고리즘의 정의는 다시 한번 위키를 빌리겠습니다. 

    An algorithm is an effective method   that can be expressed within a finite amount of space and time[1]   and in a well-defined formal language[2]   for calculating a function  .[3]  


    한정된 CPU시간, RAM 공간에서 "효율적인" 기능을 하도록 하는 것입니다.

    즉 시간 공간 효율성에 대한 고려를 할수 있으면 아는 것이고 모르면 모르는 것입니다.


    SQL 쿼리를 최적화되게 짜는 것도 같은 맥락에서 평가할수 있습니다.

    분명 같은 작업 하는데도 어떻게 작성하였는지에 따라서 성능이 크게 차이가 날수 있습니다.

    인덱스를 위해 얼만큼의 공간을 할당할지 말지나,  SQL Round Trip을 줄인다등 그러한 판단을 내리는 기준은 알고리즘 과목에서 배우는 요소들( 시간 & 공간 & 효율성)입니다.

    절대로 많은 알고리즘의 슈도 코드를 외운것이 알고리즘을 아는게 아닙니다. 시간 & 공간 & 효율성을 위해서 무엇을 신경써야 하고 왜 그렇게 하는지 아는지가 중요합니다. 


    구체적인 예시를 들겠습니다.

    시공간과 성능에 대한 개념 학습이 안되어 있어서, 게시판에 댓글 숫자를 찍기위해서 게시판 구현시 List 20개 레코드 획득  + 각 레코드별 요소별 댓글수 조회 * 20회 하여 21회 쿼리를 날리는 것도 봤습니다. 

    단순 목록페이지 구성을 다른 평범한 수준의 프로그래머에 비해 21배의 코스트를 내고 기능하도록 프로그래밍하는 사람을 저로써는 C급이라 평가하기도 어렵다고 생각합니다. 


    0
  • vollfeed
    138
    2017-06-17 00:42:16.0

    이를 일반적으로 말하면, 

    극한의 최적화는안해도 적어도 쓸만큼의 "최적화"는 해야합니다. 


    그 최적화 하기 위한 최소한의 도구인 성능 평가의 개념이나, N에 대하여 산술적으로 어떻게 늘어나는지, 

    이미 케케묵은 방식으로 확립되서 누구나 쓰고있는 최소한의 기준선이 얼마나되는지 등 

    명확히 꼬집어서 말하는 용어를 들기 어렵다고해도

    생각보다 많은 것을 알고리즘 시간에 배웁니다.


    시험지에다 썼던 알고리즘의 슈도코드는 까먹지만, 프로 개발자는 저런 내용은 기억하고 쓰게 됩니다.

    라이브러리나, 모듈, 오픈 소스를 쓸때도 때때로 저런게 이슈가 될때도 있죠

    정렬이 되기만 하는 버블소트에 비해, 최적화가 된 N LgN급 정렬이 얼마나 빠른지도 기억하고 

    본능적으로 그런 것을 추구합니다. (개발자 = 최초의 사용자이기도 하여 너무 느리면 못견디죠) 


    이런걸 배운바가 없다면..? 

    뭐가 잘못됬는지도 모릅니다. 

    제 애기가 뻥같은면, 아직 이 동네 바닥을 못 보신겁니다 



    그렇기 때문에 제가 앞서 쓸때

    모형, 평가척도, 전략등이 알고리즘에서 배워할 진짜 내용이고, 그많은  코드는 전부 예시라고 한것입니다.



    0
  • vollfeed
    138
    2017-06-17 00:48:16.0

    bill//

    실제로 알고리즘을 많이 알고 잘하는 개발자와도 같이 일을 해본적이 있으나 알고리즘을 잘 안다고 해서 개발을 잘하는건 아니더군요..

    라고 하셨는데,

    그분은 know many는 되는데, know well은 안되는 상태라고 말할수 있습니다.

    물론 know many가 know well이 되는데 많은 도움이 될수 있습니다. (그러니 배울때는 많이 보는것도 좋습니다)


    알고리즘 잘한다는 능력의 정체는 절대 예시를 많이 아는게 아닙니다. 




    0
  • vollfeed
    138
    2017-06-17 00:52:22.0

    bill //

    아, 그리고..

    알고리즘을 아는 것과  생산성은 아무 관계 없습니다.


    고급 알고리즘은 사실상 수학인데, 이건 "복잡한 문제를 정확히 푸는것"에 더 치중되거나,

    "수학적 해법을 통한 극단적인 or 주어진 상황에 Best한 최적화 " 로 가는 겁니다.

    이건 제한조건 안에(Time & Space & Input) 되냐? 안되냐?의  상태지,

    개발을 빨리하냐? 느리게 하냐? 가 아닙니다.


    알고리즘 잘한다고  개발을 잘 할꺼라는 것도 편견입니다.


    0
  • PRO그래머
    679
    2017-06-17 02:15:20.0 작성 2017-06-17 02:15:57.0 수정됨

    구체적인 예시를 들겠습니다.

    시공간과 성능에 대한 개념 학습이 안되어 있어서, 게시판에 댓글 숫자를 찍기위해서 게시판 구현시 List 20개 레코드 획득  + 각 레코드별 요소별 댓글수 조회 * 20회 하여 21회 쿼리를 날리는 것도 봤습니다. 

    단순 목록페이지 구성을 다른 평범한 수준의 프로그래머에 비해 21배의 코스트를 내고 기능하도록 프로그래밍하는 사람을 저로써는 C급이라 평가하기도 어렵다고 생각합니다. 



    라고 하셨는데 저렇게 해도 정답은 나옵니다.

    논지에서 살펴본다면 더 좋은 방법이 있는데 그걸 고려하지 않고 단순하게 생각했기 때문에

    C급이하다 라고 말씀하신 거라고 생각 됩니다.

    언급한 예시는 알고리즘을 모르는 개발자가 짠 쿼리여서 그런게 아니라

    쿼리를 잘 못짜는 개발자가 짠 쿼리여서 그렇다고 봅니다.

    같은상황에서 최적화된 쿼리를 짠 개발자도 알고리즘을 모를 수 있습니다.



    알고리즘을 아는 것과  생산성은 아무 관계 없습니다.



    애초에 프로그래밍을 하는데 알고리즘이 중요한가 자료구조 학습이 중요한가였습니다.

    그게 변질되어서 알고리즘은 필요없다와 알고리즘 모르면 개발자도 아니다로 바뀌었는데

    이글에서 작성자님은 알고리즘 고려하지 않는 개발자는 개발자도 아니다 라고 주장하고

    있다고 판단 됩니다.

    거기서 그와 관련된 근거를 나열하셨다면  그렇게 생각하는구나 라고 넘어갈 수 있는데

    성능과 속도에 관한 주장을 지속적으로 하고 계십니다.


    자바, 객체지향프로그래밍은 성능과 속도에선  절차지향 프로그래밍보다 느립니다.

    같은 설계 방식을 사용했을때 성능이 C보다 느린데 자바를 이용해서 개발하는 개발자들은

    그럼 C급이하인건가요.

    성능에 관해 더 좋은 언어가 있는데 자바를 사용하니까 BEST한 최적화가 아니지 않습니까?


    자바를 쓰는이유는 간단합니다.

    생산성 이걸 보고 자바를 씁니다.



    또한 규모가 큰 시스템에서의 알고리즘 최적화를 말씀하셨는데

    빅데이터 처리의 기본 베이스인 K/V형식 분산병렬 처리방식은

    결과를 얻기위한 최적의 알고리즘으로 판단했을때 좋은 방식이 아닙니다.


    그럼 그 방식을 처음 발표한 구글은 알고리즘을 몰라서 최적화를 못해서 그랬을까요.


    아닙니다.

    더 효율적인 자원 분배를 위한 새로운 모델을 발표한겁니다.



    주장하시는 내용대로 알고리즘이라는 개념 자체가

    결과를 얻기위한 최적의 방향이라는 전재하에


    새롭게 발표되는 기술은 잘 모르나 알고리즘을 이용한 최적화를 잘하는 개발자와 

    알고리즘은 잘 모르나 새롭게 발표되는 기술은 잘 알고 있는 개발자


    누가 더 좋은 결과물을 만들어 낼까요?


    알고리즘에 대한 공부는 필요하다는걸 인정하나 알고리즘을 모르는 개발자를

    C,D급으로 매도하는게 정당한지 다시 생각해보셨으면 좋겠습니다.

    0
  • 욥욥욥
    714
    2017-06-17 02:38:50.0

    논리적 근거에 흥미를 느끼고 계셨는데 느닺없이 날조에 커뮤니케이션 능력이 낮다고 대문짝만하게 비하를 하시다니요 ㅡ.ㅡ

    감정이 좀 섞였지만 이런가 저런가 하며 관람했던 입장에서 확 찬물이네요

    다들 시간도 늦었는데 이만 끝내시거나 다음에 하시죠

    0
  • 하마
    4k
    2017-06-17 11:18:49.0 작성 2017-06-17 16:03:42.0 수정됨

    저는 the art of computer programming 에 대해 완전히 이해를 하지도 못한 채 개발하는 사람들을 단순코더라 보고 있습니다.

    글쓴님(vollfeed)도 글을 보아하니 단순코더 레벨이시니 레벨타령은 본인 얼굴에 침밷기 같습니다. (혹시 도널드 커누스를 완전히 이해했다면 변을 하시구요)  그냥 알고리즘은 항상 공부해야 할 만큼 중요하다 정도였으면 쿨 할뻔했습니다 그려

    아~

    동적프로그래밍과 flyweight 패턴을 (백트래킹하고 메멘토) 의도적 측면에서 일부분 연관 (반복제거에 관함.정확히는 시간과 공간측면에서 다른 의도) 될 수있다고 생각하신거 보면 나름 진지하게 책을 보셨으니 D급은 아니고 B급 코더라고 인정해드리죠^^

    1
  • iops
    1k
    2017-06-17 12:12:58.0

    근데 이렇게 하나하나 아는걸로 등급 나누면 결국 좋은게 있나요?


    저는 쥐뿔 아는게 없어서 한 X급 개발자 정도로 하고 싶습니다.

    0
  • vollfeed
    138
    2017-06-17 12:46:48.0

    욥욥욥 //

    저도 인간이니까요.

    제가 하지도 않은 말을 마구 지어내고 프레이밍 당하면,

    당연히 감정이 앞섭니다.

    좋아보이진 않겠지요. 저도 압니다. 그렇다고 부당함을 참고 살 순 없겠지요.

    0
  • vollfeed
    138
    2017-06-17 12:54:06.0

    하마 //

    어차피 제가 그 내용중에 뭐하나 붙잡고 설명해도 다른것 모르겠지 하겠죠?

    토픽을 고르세요. 

    0
  • vollfeed
    138
    2017-06-17 13:02:37.0

    inyl //

    제입장은 하나하나 아는게 문제가 아니라, "모형, 전략, 평가도구" 등을 알아야한다 입니다.

    그 많은 코드는 전부 예시라고 했습니다.

    제 사견일수있겠으나, 이것은 화학의 주기율표, 수학의 사칙연산과 같은 정도의 토대입니다.


    그리고 등급이라는 표현이 싫어서, 연봉을 넣더라도 결국은 같지 않나요? 현실을 살아가는 인간이니까요. 

    1
  • 채앵
    29
    2017-06-17 13:02:57.0

    대학원생인것 같은데

    알고리즘은 회사오면 왠만해선 쓸일 없으니으니


    면접 전까지만 열심히 공부하시길 ^^

    0
  • 채앵
    29
    2017-06-17 13:07:21.0

    협업 안해본 티가 너무나요 글쓴이분

    회사가서 코드리뷰할때 꼭 빅오표기법 들먹이면서 알고리즘적으로 잘못되었다고 하시길 바래요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ



    같은 직종사람 무시하는거봐

    c,d급 개발자 ㅋㅋㅋㅋㅋㅋ?

    에휴 완전 지잘난맛에 사네 ㅋㅋㅋㅋㅋㅋ

    0
  • 하마
    4k
    2017-06-17 13:16:35.0 작성 2017-06-17 13:25:42.0 수정됨

    ㅎㅎ 아니요.

    님이 the art of computer programming 를 완전히 이해하셨다면 그런 줄 알겠습니다.믿고 안 믿고가 뭐 중요하겠습니까. 대단하시네요. 생각하는 프로그래밍 같은것은 연례 행사로 읽지만 크누스는 읽다 말았습니다. 단순코더죠.@@

    그 정도 실력자시니 오픈소스 정도는 하시죠? 링크 주시면 공부해보겠습니다.사실 개발자는 코드로 말하니 다른 오키 개발자들도 좀 더 님의 의견에 더 귀기울이고 신빙성을 갖게 될거라 확신합니다.

    (사실 fender님도 항상 오픈소스 공개해주셔서 공부했습니다. 제 아이디도 HAMA 라는 오픈소스 읽다가 만들게 된거구요.^^)

    마지막으로 오키에 님 같은 실력자가 자주 방문해서 좋은 기술글(특히 자신의 코드를 예제로) 들 많이 써주셨으면 하는 마음이 큽니다.

    0
  • vollfeed
    138
    2017-06-17 13:18:26.0

    PRO그래머 //

    CPU보가 개발자가 비싸니까요. 최적화의 기준이 경제논리일때도 있죠.

    그리고 자바는 생산성이 좋은 언어가 아닙니다. http://datavirtualizer.com/popularity-vs-productivity-vs-performance/ 


    알고리즘에 대해서 논할떄, 아무래도 쉬운쪽인 "최적화"에 초점을 두고 전달해서 그런것 같은데,

    (알고리즘 책에 일반적 PC에서 풀수없는 문제는 안나오니까, 제가 예시를 못들어서 그런거겠죠)

    "제한 안에서 풀수있는가?"는 더 중요한 문제입니다. 

    구글의 입장에서는 "효율적인 자원 분배"를 고려한게 아닙니다. 효율이 떨어져도, 단일 HW를 넘어서는 데이터 사이지를 제한된 조건 (128G 머신 * 100대)안에서 풀수 있는가?를 해결한것입니다.


    그리고 본문에도 적었습니다만, 

     실제 사용할 물건을 만들꺼라면 극한의 최적화는안해도 적어도 쓸만큼의 "최적화"는 해야합니다. 

    극한의 최적화를 위해 비용이 얼마가 들든 C언어로 하는게 맞는거 아니냐로 해석하지 마시길 바랍니다.


    0
  • 채앵
    29
    2017-06-17 13:19:44.0

    @하마

    글쓴이 지잘난맛에 사는데 오픈소스같은거 하겠어요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ?

    분명 회피하겠죠 ㅋㅋㅋㅋㅋㅋㅋ

    0
  • vollfeed
    138
    2017-06-17 13:27:48.0

    하마 //

    https://docs.google.com/document/d/1VDGXn6RsSM2-rOuF8e2KyG2ywZegJZFx1SpKxJOC630/edit#heading=h.3sh1h0xmq1c2 

    링크로 대신할게요. 문서 끝에 오픈 소스도 있습니다.

    아이러니 하게 오픈 소스 활동중 인기가 제일 많은건 코드가 아니라

    http://steamcommunity.com/sharedfiles/filedetails/?id=377330400 이거네요.  

    바뻐서 버그수정도 못해주는데 말이죠.


    채앵 // 

    네, 전 협력하는 경우보다 자연스럽게 일을 가르치고 시키는 쪽이 더 많네요.

    그래서 그런가 봅니다.


    0
  • vollfeed
    138
    2017-06-17 13:28:58.0

    채앵 //

    이거, 제가 회피 안해서 어떻게 하시나요?

    0
  • 하마
    4k
    2017-06-17 13:38:19.0 작성 2017-06-19 09:15:05.0 수정됨

    감사합니다.시간 될 때 참고하겠습니다. 후에 질문도 좀 하고요.

    사실 이런 훈계(?)식의 글도 필요하지만 반발도 당연히 뒤따르게 (계급화 하려는 저열함 때문에) 됩니다.. 하지만 논란없이 더 도움되는것은 실질적으로 쉽게 풀어서 쓴 강좌입니다. 다시 말하지만 이번 기회를 통해서 오키에 그런 글을 앞으로 올려주신다면 좋지 않나 합니다. 저 같은 단순코더(제 기준에서)도 여러차례 올렸으니 부담 갖지마시구요.

    0
  • vollfeed
    138
    2017-06-17 13:46:10.0

    하마//

    제가 강좌를 쓰는 것은 의미가 없습니다.

    현실적으로 개발자가 알아야하는 FACT를 전달하는 글은 차고 넘칩니다.

    도서관에 가든 서점에 가든, 오픈 소스 문서를 읽든..

    자료는 넘쳐나요. (실버 불릿문제가 있긴하지만요)


    문제는 저자가 아무리 해박해도 그걸 글로 풀어서 쓰면 제대로 전달되기가 힘들다는거죠.

    결국 행간에 숨은 것을 읽어야 하는데, 

    제가 아는 범주내에서 그게 가능한건 소크라테스가 썼다던, '산파술' 뿐입니다.

    1+1같은 기초 개념부터 산파술로 가려면, 학생이 교사를 먹여 살려야 할텐데, 그건 무리지 않나요?

    결국 현실에서는 학생이 교과서를 전부 외우면

    그 내용을 토대로 빠르게 토론해가며 행간을 파악하게 이끄는것이 최선이라는게 제 생각입니다.


    그리고 이글도 앞쪽 절반은 다른데서 하지 않는 행간을 읽어주는 내용입니다.

    나머지 절반은 솔직한 제 의견입니다.

    누구나 연봉많이 받고 싶어하는데, 조금만 어려워 보여도 회피하려고 들더군요.

    안타깝게도 저는 고생해서 많이 배운 전산쟁이지 날때부터 성인군자가 아니라 좋은소리가 안나오더군요. 




    0
  • vollfeed
    138
    2017-06-17 13:56:49.0

    하마 //

    잼있는게 초급 프로그래머는 배울게 많다고 스스로를 코더라고 하고,

    진짜 코딩이나 툴만 쓰는 경우에는 다 할줄 안다고 생각하는게 많은것 같습니다.


    제가 쓴소리 하고 싶은쪽은 

    이분야에 이제 진입하는데 굉장히 마음 쉽게 먹고 온 사람들입니다.

    툭하면 뭘 안하려고 하고, 그래도 별 문제가 없을꺼라고 믿고,

    자신이 비전공자인걸 방패삼아 정당화 하려고하죠.


    대학 전공이 IT인지 아닌지는 상관없어요.

    개발자가 되기로 했다면 그때부터는 다른 요소 상관없이 개발에 관련된것으로 평가되는겁니다.

    흑인이든 한국인이든, 눈이 하나든 둘이든요 

    하지만 대학과정에서 가르키는 건 전부 관련된거니까 평가요소에 넣더라도 부당하지 않습니다.

    다만 뭐하나 C 학점이어도 다른게 A라면 장점 위주로 운용하면 되죠.


    그래도 저는 기초 공통중에 F학점이 있으면 졸업 안시켜야한다고 생각합니다.

    0
  • PRO그래머
    679
    2017-06-17 14:03:09.0

    vollfeed


    링크를 살펴보았으나 제가 말하는 생산성에 관한 내용이 아니라고 봅니다.

    링크의 작성자는 코딩 라인수로 생산성을 표현했는데

    글대로 생각한다면 파이썬이 자바보다 5~10배 더 생산성이 좋다 라는 결론이 나오는데

    정말 그렇게 생각하시나요?


    생산성에서의 코딩은 전부가 아니라 일부죠.

    자바 기반으로 나온 많은 오픈소스 , 라이브러리 등을 적절히 활용해서 개발을 할 수 있는데

    이건 생산성에 들어가지 않나요?



    또한 분산병렬처리는 제한된 조건에서 풀수 있는가가 아니라

    제한된 조건에서(H/W의 한계) 풀수 없는 문제에 관해 분산처리를 통한

    제한의 완화를 제시한 모델입니다.


    결과를 구하기 위한 최적의 알고리즘으로 세팅을 했어도 데이터가 커서 

    H/W가 견뎌주지 못하면 결과를 얻을 수 없는데 그걸 풀기위한 처리방식을 고안해낸거죠.



    0
  • kkey21a
    2k
    2017-06-17 14:12:39.0 작성 2017-06-17 14:21:52.0 수정됨

    vollfeed//

    우선 알고리즘을 배워야만 하는 이유와 핵심에는 공감하며, 좋은 의견 제시해 주셔서 감사합니다.

    내가 "어떤 문제"를 만나더라도, 모형, 평가척도, 전략을 가지고 해법을 찾을수 있게끔 하기 위해서 가르치는 것입니다.


    다만, 그 어떤 문제를 해결하는 방법이 본인이 의도했든 하지 않았든 단순히 알고리즘밖에는 없다는 이야기로 전개되는 것 같아 제 개인적으로는 본문의 핵심에서 벗어나는 것은 아닌지 하는 아쉬운 생각이 드는 것도 사실입니다.

    물론, 그러한 문제들을 분석하기 위해 알고리즘만큼 보편적이며 방법적으로 타당하다는 데에는 큰 이의가 없습니다. 다만, 위와 같은 문제를 해결하기 위해서는 이런 분석능력 이외에도 다양한 방식으로 표현할 수 있는 능력, 또 이 표현을 공학적으로 설계할 수 있는 능력, 또한 지금 현 주제에 대한 갈등처럼 갈등을 조정하면서 함께 협력할 수 있는 사회적 능력 두루두루 필요하지 않을까 합니다.

    만약 위 의견에 동의하신다면, 프로젝트를 진행할 때 각자 본인의 역할이 있을 텐데, 단지 분석능력을 가진 분만 개발자라 할 수 있을지는 저로서는 솔직히 공감이 가지 않는 것도 사실입니다. 


    그리고 세상사 모든 일을 이런 알고리즘으로 다 설명할 수 있지 않은 것도 사실이고, 알고리즘에 대한 개개인의 이해와 한계 때문에 이미 알고리즘들을 이용한 다양한 솔루션들 출시되었고, 현재는 빅데이터를 이용한 다양한 기술들이 시도되는 것 아닐까 생각합니다.



    PS 

    물론 분야마다 다르겠지만, 위와 같은 Software engineering보다 Domain 능력이 우선시 되는 곳도 많습니다.

    즉, 많은 기업에서는 위와 같은 engineering이 강한 사람보다 이미 검증된 솔루션으로 대체하고, 오히려 Domain 능력을 우선시 하여 사람을 뽑는 것도 사실입니다.

    0
  • 앙앙이
    1k
    2017-06-17 14:13:08.0 작성 2017-06-17 14:13:58.0 수정됨

    // 채앵

    아.. 정말로... 논리적인 주장없이 이모티콘 사용하면서 자극만 하는 사람 정말 싫네요.

    아이디 급조하신 "채앵" 님  껀수 잡으셨나봐요.


    채앵 ---> 활동점수 19

    0
  • vollfeed
    138
    2017-06-17 14:15:04.0

    PRO그래머  //

    동일 기능에 대한 구현시간을 측정요소로 하겠지만, 

    그런 데이터는 구하기 쉽지 않을테니까요. 그나마 리서치가능한게 저런 자료입니다.


    여튼 파이썬이 자바보다 생산성은 분명히 좋습니다.

    다먄 5~10배가 되느냐?는  개발자의 능력에 상당히 달려있습니다.

    오픈소스 숫자는 생산성에 영향을 줄수 있는 부분입니다.

    기존까지 통념은 자바가 오픈소스가 가장 많다 였습니다만, 

    근래 Github의 사용언어 추세를 볼때 이러한 구도는 깨어지고 있습니다.

    현 시점에서는 오픈소스이점은 자바만 가진게 아니다 라고 해야할것 같습니다.


    제한된 조건은 Ram 1G CPU 30초와 같이 1개에 대해서 주어질수도 있지만, (Ram 10G CPU 30초) * 100대 식으로 주어질수도 있습니다. 

    제한이 완화된것은 맞으나 여전히 제한이 있으며, (총 RAM 1000G, CPU 3000초) 이 안에서 기존에는 생기지 않던 Overhead(데이터교환/명령교환)까지 해결해야한다는 제한이 추가됩니다. 

    즉 1000T바이트의 데이터를 RAM 1000G, CPU 3000초 조건에서 풀어도 되지만, 그런 머신은 너무 비싸니까, 

    Overhead해결이라는 조건을 추가해서라도 (Ram 10G CPU 30초) * 100 또는 110대에서 해결하는게 더 싸다 입니다. 

    흔히 분산하면 안전성이 있다고 생각하는데 그것도 편견입니다.

    HW오류율이 동일하다면, 1대의 머신이 정상동작할 확률이 100대가 전부 정상 동작할 확률보다 높습니다. 

    그렇기 떄문에, 분산처리를 하게되면, 단일머신이면 하지 않아도될  "오류 수용" 개념을 적용하여 더 복잡하게 디자인해야하며, 디자인인 복잡한 만큼 안정성도 떨어집니다.

    다만, "오류 수용"으로 인해 떨어진 안정성으로 15% 손실이 생겨도 결과는 정상적으로 낼수 있다가 되는 것입니다.

    그리고 경제적인 이득이 저런 문제를 씹어버릴만큼 상당하죠. 




    0
  • vollfeed
    138
    2017-06-17 14:29:39.0

    kkey21a //

    알고리즘 밖에 없나는 물론 아니지요.

    댓글 논의중에 나오지만, 디자인 패턴 = 전략 + 구조화로 볼수 있습니다. 

    솔직히 저는 알고리즘이 모형, 평가척도, 전략을 배우가 가장 좋은 Toy Example이기 때문에 하는게 이득이라는 입장이긴 합니다.

    그러나 글 내용상 개발의 다른 요소 (OOP, 설계 등의 요소등)은 언급도 안했는데 부득불 그걸 가져다 붙이니 좀 짜증이납니다. (기계가 아닌 인간이라서요..)


    만약 위 의견에 동의하신다면, 프로젝트를 진행할 때 각자 본인의 역할이 있을 텐데, 단지 분석능력을 가진 분만 개발자라 할 수 있을지는 저로서는 솔직히 공감이 가지 않는 것도 사실입니다. 

    그리고 저는 분석능력을 가진 사람 개발자라고 한게 아니라

    분석능력 가져야 개발자(= 분석 능력이 없으면 비개발자)라고 하였습니다.


    제가 분석 능력이 없으면 개발자라고 인정 못하겠다라고 한것은 맞지만, 

    그게 '꼭' 있어야 한다고 했지, 그것만 있으면 된다고 한적은 없습니다.


    세상사 모든일은 안되지만 CPU위에서 실행되면 다 설명될수 있다고 생각합니다. 그러나 이게 핵심은 아니겠죠. 

    알고리즘에 대한 개개인의 이해는 차이가 나며, 직접구현은 너무 코스트가 크니까

    우리는 그것을 아웃소싱/추상화 해서 사용합니다.

    즉 그 문제를 해결할수 있는 라이브러리, 오픈소스, 모듈, 서버 API, 상용 제품 등등을 사용합니다. 

    다만 이때도, 그 것의 매커니즘은 몰라도(경우에 따라선 사업기밀이기도 하겠구요)

    제공하는 기능별로 어떤 입력에 어떤 결과를 내며, 입력사이즈 N에 대해서 얼마나 걸리는지 등등은 알고 쓰는게 맞습니다. 

    굴러가기만 하면 된다는 영업 담당이 가져야할 자세죠, 기술자의 자세는 아닙니라고 생각하기 때문입니다.

    0
  • kkey21a
    2k
    2017-06-17 14:54:33.0 작성 2017-06-17 15:06:11.0 수정됨

    vollfeed //

    정말 궁금해서 묻습니다.


    1. CPU 위에서 실행되면 다 설명 될 수 있다고 하셨는데, 전제 자체가 잘못된 데이터가 입력 되었을 때는 어떻게 됩니까? CPU가 설명해 줄 수 있나요?


    2. CPU 위에서 모든 것이 설명 된다면, 빅데이터는 대체 왜 필요한 걸까요?


    3. 제가 위에 제시한 능력 이외에도 개발자가 되기위해서 '꼭' 필요한 조건들이 더 있다고 생각하는데, 어떤 것들이 더 있을까요? 또, 그러한 능력을 갖춘 사람은 소위 개발자로 불리는 사람들 중에 몇 %정도 될까요? (혹시 가능하시다면, 수치로 계산해서 보여줄 수 있는지 궁금합니다.)


    4. 위 소위 개발자로 불리지 않는 사람들의 정의는 뭐라고 불러야 할까요? (저도 고민이라 ㅋ)


    5. 제가 생각하는 분석능력은 바로 위 댓글에서 이야기 해 주신

    제공하는 기능별로 어떤 입력에 어떤 결과를 내며, 입력사이즈 N에 대해서 얼마나 걸리는지 등등은 알고 쓰는게 맞습니다. 

    위 정도를 생각하는데, 그 분석능력이 대체 얼마나 되어야 vollfeed님의 잣대에서는 개발자로 불릴 수 있습니까?


    ----- 추가질문------

    6. 기업은 업무 (도메인) 능력을 더 중시하며, 사람을 뽑는데 왜 개발자도 아닌 사람들로 몇 천억을 들여 차세대를 하는 걸까요? 


    7. 왜 기업은 엔지니어링 능력을 가진 사람보다 도메인 능력을 더 중시하며, 왜 도메인 능력이 많은 사람을 더 뽑을까요?

    0
  • 앙앙이
    1k
    2017-06-17 14:55:51.0

    자바 SI 프로젝트 품질들 만족하시나요?

    품질을 만족하지 않는 생산성 강조가 무슨 의미가 있는지 모르겠습니다.


    0
  • 앙앙이
    1k
    2017-06-17 15:01:16.0 작성 2017-06-17 15:02:25.0 수정됨

    // vollfeed

    혼자서 너무 애 쓰셔서 안타깝네요.

    저두 다굴 당한적 있어서 남일이 아닌듯합니다.

    CPU위에서 실행되면 다 설명될수 있다는것은 기계는 시키는 일만 하기 때문인데

    그 말에 딴지를 건는 사람과 토론을 잘 할 수 있을지 현명하게 판단하여 거르시기 바랍니다.


    0
  • kkey21a
    2k
    2017-06-17 15:09:45.0

    vollfeed //

    어느 분 말처럼 전 다굴 하는 건 아니닌깐 오해 없으셨으면 합니다.

    위에서도 밝혔지만, 제가 보는 현실과는 조금 괴리가 커서 정말 궁금해서 여쭤보는겁니다.


    그리고 제 개인적으로는 알고리즘의 중요성에 대해서 이전 댓 글들 찾아보시면 아시겠지만 부정하고 있는 부분은 없습니다.

    0
  • vollfeed
    138
    2017-06-17 15:10:24.0

    kkey21a //

    1. 원론적으로 애기가 될것같은데,

    CPU위에서 실행 = 현대 컴퓨터에서 실행 이라는 의미는, 한정된 RAM / CPU를 사용해서 돌린다는 의미죠.

    알고리즘은 한정된 CPU/RAM에서 효율적으로 답을 낼수있으면 알고리즘입니다. 

    그게 거창하게 정렬/탐색 같은게 아니라, 단순히 가위,바위,보 게임을 하는데 누가 지고 이겼는지를 한정된 자원으로 효과적으로 판단하면 알고리즘 입니다.

    이때 효과적이라는걸 좀더 부연하자면, 가위 바위 보 게임을 2명이 참여한다고 할때, 발생 가능한 경우의 수는 3 * 3 = 9가지이고, 이를 9개의 모든 케이스 쌍 (즉, 가위/가위, 가위/바위, ~ ,보/보)  = 입력 값(A가낸것/B가 낸것)과 비교하여 승패 판정하면, 브루트포스한 풀이법입니다. 

    즉, O(n^3)은 무식하게 푸는 최적 성능이나, "어쩃든 다항식시간 안에 풀수 있음"으로  "알고리즘(효율은 최저인)"입니다.(알고리즘 같지도 않겠지만요 ㅋ) 

    하지만 현실적으로 비교문을 잘써서, n^3보다 짧은 시간에 풀수 있을테고, 그게 소위 말하는 "효율좋은 알고리즘" 입니다

    다만, 알고리즘은  잘정의된 입력 -> 잘정의된 아웃풋도 조건으로 걸고있습니다.

    데이터가 잘못된 경우는 2개로 봐야하는데, 형식이 틀린경우/값이 기대화 다른 경우 입니다.

    형식이 틀린경우는 그냥 알고리즘을 잘못쓴거로 봐야합니다.(컴파일러가 걸러주면 좋은거죠)

    값이 기대와 틀린경우, 알고리즘이 안 뻣으면 방어적 코딩/우아한 종료 라고 불리며 그렇지 않은경우는 그냥 죽는거죠. 


    0
  • vollfeed
    138
    2017-06-17 15:10:57.0

    앙앙이//

    아, 품질은 알고리즘과 연관성이 크죠. 생산성과 달리...

    조언 감사합니다.

    0
  • vollfeed
    138
    2017-06-17 15:14:29.0

    2. 빅데이터도 결국 CPU/RAM으로 하죠.

    하기 전에 잘게 자르는걸 하죠.

    한편 빅데이터는 솔직히 마케팅용어인데, 

    단순히 데이터가 큰게 문제가 아니라, 

    비선형 데이터/ 비정형 데이터는 또 애기가 다릅니다.

    혼재되서 떠들지만, 

    실제 빅데이터에서 중요한건  비선형 데이터/ 비정형 데이터를 가공하는 것입니다.

    이것도 큰 줄기는 2가지, 한가진는 기존에 주로 개발된 선형 데이터를 대상으로 하는 알고리즘을 적용하기 위해서, 비선형->선형으로 바꾸거나,

    아니면 데이터 자체가 비선형/비정형인걸 전제로 개발된 알고리즘을 쓰거나 입니다.

    그와중에 데이터가 너무커서 1PC에 넣을수 없어 분산처리하는건 곁다리입니다.

    할수있다면 메임프레임/슈퍼컴퓨터 쓰는게 나아요 ㅠㅠ


    0
  • vollfeed
    138
    2017-06-17 15:15:40.0
    0
  • 술술
    140
    2017-06-17 15:15:56.0

    알고리즘 간단하잖아요. 입려값 받고, 처리한다, 그리고 출력 내뱉는 계산 과정.

    항상 자연스럽게 하고 있고 프로그래밍의 기본 요소인데, 계속 논쟁이 되는게 안타깝네요.


    대학교과나 여타 알고리즘 책에서 나오는 문제들은 알고리즘 방식으로 해결하는 과정을 보여주고 있는 거고(특히, 컴퓨터 계산은 유한한 값과 시간을 가정하고 있으니까요), 해답 자체는 '알면 좋지만 이걸 전부 알필요는 없지'라고 생각되지만, 알고리즘으로 문제를 해결하는 사고 방식은 프로그래머에게 필수불가결입니다. 어려운 문제를 이야기하는게 아니라 함수 하나 짜는 것도 알고리즘이잖아요.


    그냥 제 결론 : 알고리즘은 기본이다. 알고리즘으로 푸는 문제, 그리고 과정, 해결 방안을 공부하면 아주 좋다.(그러한 사고방식에 익숙해지니까)



    0
  • vollfeed
    138
    2017-06-17 15:23:31.0

    3. 이건 어려운 문제죠. De Facto가 아직 없으니까요.

    제 견해로는 대학 학부수업의 70%는 포함되어야합니다.

    http://biz.khan.co.kr/khan_art_view.html?artid=201305192211135&code=930100 를 보면,(2013년이지만)


    대졸 2만 전체 6만이라고 하네요. 학부수업 충실히 안따라하는거 알지만, 그래도 듣긴들었으니라고 퉁치고,

     30%는 제가 애기한 알고리즘 능력을 그래도 배웠다 라고 해도 되지 않을까요?

    (사회 조사 같은건 별로 안해서, 어설프네요..씁)


    술술 //

    네 맞습니다. 바로 그거에요. 


    0
  • kkey21a
    2k
    2017-06-17 15:24:19.0 작성 2017-06-17 15:25:50.0 수정됨

    vollfeed //

    1. 제가 묻고 싶은 던 것은 데이터를 적재함에 있어서, 도메인을 잘 몰라서 설계를 잘못 하여, 잘못된 데이터가 적재 되었는데, 이는 어떤 알고리즘으로 해결 가능한 걸까요?

    과연 이를 CPU가 알 수 있는 것인지 궁금해서 묻는 것 입니다.


    2. 빅데이터를 구성하기 위한 알고리즘이 궁금한 것이 아니라, 위 댓글에서 이야기하신 CPU(알고리즘)에서 다 설명되는데  굳이 빅데이터가 나온 이유가 궁금하며, 왜 요즘에는 이런 빅데이터가 대세가 되고 이와 접목한 기술들이 상용화 되고 있는지 궁금하여 여쭤봤던 것입니다.


    3. 단지, 그 정도 수준에서 이야기 하시는 것이라면 이 글에서 솔직히 문제가 전혀 없어보이긴 한데, 대체 다른 분들은 왜 그러는걸까요?

    0
  • vollfeed
    138
    2017-06-17 15:28:01.0

    4. 저는 "코더" 라고 부르는게 타당하다고 생각합니다.


    Code란 부호 집합 A를 부호 집합 B로 바꾼다는 것입니다. 

    즉 인간 언어를 그저 기계언어(프로그래밍언어)로 바꾸면 Code한거죠. 


    다만 이걸 효과적/효율적/논리적/일관성 등을 유지하면서 해내면, 

    철저하게 계획된것을 한것이니까 Program 한것입니다.

    그래서,  코더  / 프로그래머 경계선이 명확하다고 보는 입장입니다. 


    근데 "코더"를 멸칭으로 여기니까 말이죠... 흠..

    하지만 제가 볼때, 그냥 쫄리니까 뭐라고 부르든 멸칭으로 여기는 겁니다.


    코더가 아니라 Translater라고 부르면 멋있어지나요? 

    결국 컴퓨팅 자원에 대한 고려없이  프로그래밍언어가 제시하는 수십개의 예약어로 조합된 명령문을 쓰고 있다면, 어차피 하는 일이 똑같지 않나요? 



    0
  • vollfeed
    138
    2017-06-17 15:29:21.0

    5. 술술님이 애기한 정도요.


    6. 경영자는 기술로 평가안합니다. 

    그들은 세상은 "스케쥴과 예산"으로 운영된다고 믿습니다.

    저랑 믿음이 달라요. 그러니 저는 모릅니다. 


    7. "스케쥴과 예산"이 평가 기준이니까요. 

    0
  • vollfeed
    138
    2017-06-17 15:33:34.0


    //kkey21a

     

    1. 그러니까 데이터 구조 설계의 논리적 정합성이 없는 경우를 말씀하시는 거군요. 

    음.. 제가 연구하는 시맨틱 웹 분야는 Open Asssumption을 깔고가서 어떤 데이터를 넣어도 되지만 차후 Ontology를 사용하여 주어진 논리적 정합성에 어긋나는 데이터를 무시하거나, 어떤 규칙으로 유도하여 정정할수 있습니다.

    다만, 일반적인 RDBMS및 흔히 알려진 알고리즘은 거의 예외없이 Closed Assumption을 전제하여, 잘못된 데이터가 입력된것은 그냥 사용자 잘못으로 봅니다.

    요약하면,

    할수 있습니다. 그러나 지금 흔히 쓰는 도구들은 못해요.

    덧붙여 시맨틱 웹은 빅데이터의 한갈래로 여겨집니다만, 다른것과 달리 아직 10년은 더 연구되어야하는거 아니냐는 평가입니다.


    0
  • vollfeed
    138
    2017-06-17 15:34:57.0

    //kkey21a 

    3. 

    그러게요. 대체 다른분들은 왜그러는 걸까요?

    저도 모르겠어요..


    0
  • kkey21a
    2k
    2017-06-17 15:36:29.0

    vollfeed//

    우선 글쓴이님의 의견에 대해 조금 더 이해하고자 막무가내 형태로 질문 드렸지만, 답변 잘 해주셔서 감사합니다.

    뭐 솔직히 위 답변 수준 정도로만 본다면, 이 글이 딱히 큰 문제가 있어 보이지는 않기는 합니다. 다만, 글 전달과정에 서로간의 오해가 있었던 것 같습니다.


     아무튼 논란은 이제 덮어두고 주말인데 쉬시지요 ㅎ

    0
  • vollfeed
    138
    2017-06-17 15:43:32.0

    2. 빅데이터는 결국 마케팅용어입니다.

    기술적 판단으로 붙었다고 보긴 어렵죠.


    예전부터 Grid도 연구하고 분산 OS도 연구하고,

    하여간 메인프레임 가격이 억소리 나오니까  어떻게 좀 해결해볼려고 많이들 노력해왔습니다.


    한편 동시에, 데이터로 부터 의미있는 정보를 얻는 것에 대해서 연구를 많이 했죠.

    대표적이게 장바구니 알고리즘, 즉, apriori 알고리즘 입니다.

    이건 빅데이터스럽지만 빅데이터스럽지 않은데, 

    대부분 1PC에서 다 해결이 됩니다.

    결국 구매내역 = 영수증 데이터인데, 

    (품목 코드,수량 )* N 이 전부라서, 데이터 개당 1kb 숫자가 10M(천만개)라고 해도, 경우 10G밖에 안하거든요.

    빅이긴 한데(수량이 많긴한데), 빅이 아닌거죠(용량이 작은 거죠)


    여튼, 질문 하신 요지와 관련되서 봐야할건,

    이 알고리즘을 이용해서 

    월마트가 매출을 몇퍼센트씩 늘렸다고 합니다.

    4천억 달러의 1%면 얼마일까요? (가지고 싶네요) 


    0
  • 욥욥욥
    714
    2017-06-17 15:50:46.0

    다른 분들이 왜 그러는지 모르신다니 제가 느끼는 바를 조금 적어봅니다..


    일단 저는 vollfeed 님 기준으로 이런 토론에 참여할 깜냥도 안되는 코더입니다.

    하지만 제가 확실히 아는 것은 글쓴님이 작성하신 일부 내용이

    보는 이로 하여금 안좋은 자극을 받게 하셨다는 것입니다.


    알고리즘 못한다고 어려운 일 하지 말고 가능한 빨리 치킨집 자본 모으라니요.

    알고리즘 못한다고 다른 직업 찾으라니요.

    알고리즘 못해도 할 수 있는 개발일 널리고 널렸습니다.

    소위 말씀하시는 알고리즘 잘하고 연봉 많이 받아 잘나가는 분들 그런일 하실생각 없잖아요.

    어떤 분은 그런 일 하는 사람들을 심지어 '그냥 공장 노동자'라고까지 비하하는데 정말 가관입니다.


    "알고리즘등의 공부를 하지 않으면 연봉 높은 좋은 회사 취업에 불리하고, 빠른시일 안에 누군가에게 밀려나기 쉽우며 이 직업군에서 오래 살아남기는 힘들어 보인다"

    를 꼭 그런식으로 과격하게 말씀하셔야 했는지 모르겠습니다. (혹시 뭐가 다르냐고 하시면 할 말 없습니다.)


    과격하고 모질게 충고해서 상대방이 좋은 자극을 받아 열심히 하고, 훗날 둘이 얼싸안는 상황은 만화영화에나 있는 일입니다.

    현실은 본인이나 그 의견에 동조하는 몇만 속이 후련할뿐, 상대방을 욱하게 하는 것이죠..


    일단 기분상하게 해놓고 대화를 시작하신 것 같습니다.


    1
  • 양산형개발자43
    70
    2017-06-17 15:56:19.0
    오픈소스를 공개하니 조용해졌다고 한다...
    1
  • vollfeed
    138
    2017-06-17 16:03:59.0

    욥욥욥 //


    저도 제 말/글이 공격적인것은 인정하는 바입니다.

    근데 정말로 뭐가 다르냐라고 할수밖에 없습니다. 


    게다가 저는 그런 자극을 받고

    극복해서 살아남은 사람을 이 업계에서 보고 싶습니다.

    그렇지 않으면 퇴출시키고 싶습니다. 

    네, 제게 그럴 권리는 없습니다.

    하지만, 제가 개인의 직업 선택의 자유에 간섭할수는 없지만, 

    현실을 허들을 있는 그대로 전달할수는 있다고 봅니다. 


    제 사견 일 수있으나,

    IT단가가 후려쳐지는 것은

    자기 노동의 댓가를 기술 임금이 아니라 시간 임금으로 여기는

    자칭 개발자가 많기 떄문이라고 생각하기도 합니다.


    덧붙여 앙앙이 님이 언급하신

    SI 프로젝트 품질 문제도 해결되어야 한다고 봅니다.


    그리고 제가 그런 프로젝트를 하진 않을수 있겠지만, 

    제가 그 프로젝트의 사용자/소비자가 되지 않는건 아닙니다. 


    0
  • 앙앙이
    1k
    2017-06-17 16:12:40.0

    // 욥욥욥

      정년이 보장되면 좋고 정년을 넘어서도 일할 수 있다면 더욱 좋은거지요.


    울나라 환경을 노년에서도 코더로써 일할수 없는 환경이라고 생각하셔서

    시니어 급이 아닌데 연차가 되었다고 시니어 역활을 하여

    여러사람 민폐만 끼치는 사람에 대하여 치킨집을 알아보라고 일괄한거다 생각합니다.


    개인적으로 노년에서도 코더로 일할 수 있는 세상이 행복한 세상이라고 생각합니다.

    아울러 노녀기에서 코더로써 일할수있는 여건이 충분한데도 불구하고

    연차 있으면 당연히 시니어 되어야 한다며

    그렇지 못한 사람들은 치킨집 가라는 말을 하는 사람이 있다면 그 사람이 삐뚫어져 있다고 말하고 싶네요.

    그렇지만 지금 당장은 노년기에도 코더를 할 수 있는 환경이다 라고 말하기에는 어려움이 있지 않나요.

    0
  • vollfeed
    138
    2017-06-17 16:25:05.0

    앙앙이 // 

    맞습니다.

    능력이 안되는 상사는 최악이죠  

    회사가 아니라 상사를 떠나는 것이다.라는 구글의 분석도 있네요.https://brunch.co.kr/@voiz/29


    제가 볼땐, 사람은 자기 적성에 안맞는 일을 하면 무지 괴롭습니다.

    알고리즘적 사고가 되지 않는다면, 개발이 적성에 맞는다고 보긴 어렵고,

    그렇다면 차라리 다른 커리어를 하는게 낫겠죠.

    근데, 이걸 나이들어서 깨달으면 자영업 밖에 안남잔아요?

    그러니  이걸 미리미리 고민해보는게 어떠냐고, 솔직하게 조언하고 싶습니다.

    이런 애기는 뱅뱅 돌려말하면 못알아 듣기도하고 ㅡㅡ.....

    여튼 제 경험은 그렇습니다.


    0
  • iops
    1k
    2017-06-17 16:36:35.0

    술술 / 알고리즘의 논쟁은 알고리즘이 배울 필요가 없어서 그런것이 아닙니다.

    자꾸 주변에 드문드문 서식해있는 알고리즘 그런거 뭐하러 배움? 복붙하면 다되는데~ 라고 얘기하는 사람들과 헷갈려 하는거 같은데

    여기는 개발자 커뮤니티고 그런 사람들은 애초에 이런 사이트를 들어오지 않습니다.


    술술님이 말한부분은 너무나 당연한거고요. 그것에 대해 부정하는 사람은 없습니다.

    마치 사람이 사는데 숨을 쉬어야 한다처럼 너무 쓸필요조차 없는 당연한 얘기입니다.

    개발자가 로직짜는게 일상생활인데 그부분을 부정할 사람은 아무도 없겠죠. 


    다만 알고리즘 알아야 A급 개발자.

    모든것은 결국 전부 알고리즘이야. 같은 알고리즘만 알면 모든게 일사천리 만능으로 해결되는거 같은 글들에 대해 반대하는 것입니다. 

    이세상이 모두 하나의 원소로 이루어져있는것이 아니듯이 개발도 알고리즘 하나만 가지고 해결되는 문제는 아니거든요.

    특히 분야에 따라 알고리즘의 중요성이 조금 낮을 수도 있고 이부분에서 우선순위를 조절해도 관계없다는 정도에 동의하는것이고

    다른 분들의 의견도 저랑 동의할것입니다.


    그리고 세상엔 이미 무수히 많은 알고리즘이 존재하고 있죠. 몇개정도 있을까요? 만개? 십만개? 백만개?

    이 무수히 많은 알고리즘들이 모든 개발자한테 전부 필요할까요?

    근데 신입한테 알고리즘을 배우라 하면 신입들은 자신한테 무엇이 필요한지 필요없는지 선별해내는 능력이 없습니다.

    그냥 책한권 사서 처음부터 끝까지 달달 외우는거에요. 앞으로 쓰지도 않을 구닥다리 낡은 알고리즘들.

    그럴시간에 좋은 알고리즘으로 구현된 다른 프로그램을 배우는것이 차라리 훨씬 더 날수도 있습니다. 

    가령 RDBMS, hadoop, kafka, zookeeper, akka같은것들이요.

    이런프로그램들을 쓰다보면 구현에 호기심을 생기고 그러다보면 자연스럽게 알고리즘이 학습이 되게 되겠죠.


    연차가 있는 개발자는 뭐 알아서 잘할테니 별 상관없고요.

    알고리즘 학습을 하려면 뭐가 정말 필요한지 안필요한지 분간할 수 있을때 하라고 권하고 싶습니다.


    정리하면 여기사람들이 알고리즘을 하냐 하지않냐, 중요하냐 안하냐에 대해서 말하려고 반대의견을 다는것이 아니라는겁니다. 그런 사람들은 개발자 커뮤니티에 들어오지도 않고 관심도 없어요.

    1
  • vollfeed
    138
    2017-06-17 16:43:14.0

    inyl  //

    제가 언제  알고리즘 알아야 A급 개발자라고 했나요?

    전혀 구도가 다른 애기를 하고 있지 않나요?


    기초알고리즘을 모르면 D급 개발자라고 했습니다.

    기초 알고리즘을 알면, 다른 능력에 영향을 받아서 C부터 A사이 어딘가겠죠. 


    게다가 제가 알고리즘 외우라고 한적도 없습니다. 제가 뭘 공부해야된다고 적었나요?

    그 많은 코드는 그저 예시이고, "모형, 평가척도, 전략"등을 배워야한다고 했습니다. 


    제가 하지도 않은 말에 대해서 비판하는것은 피해주시기 바랍니다.





    0
  • 욥욥욥
    714
    2017-06-17 16:46:11.0

    vollfeed //

    프리랜서 고용하는 사람에게 난 알고리즘도 이정도 알고 실력자이니 돈을 더주세요 하면 알아 들을까요?

    IT 단가가 후려쳐지는 것과 품질, 환경 등은 여러가지 복합적인 문제입니다.

    (개인적인으로는 사장부터 임원, 관리자까지 싸그리 유능한 개발자가 아니면 해결할 수 있는 문제인가 싶습니다.)

    이 부분은 여기서 다른 논쟁들이 많았고 꼭 그런 뜻으로 말씀하신것도 아닌 것 같으니 줄이겠습니다.


    게다가 저는 그런 자극을 받고

    극복해서 살아남은 사람을 이 업계에서 보고 싶습니다.

    정말 그게 목적이시라면 과격한 충고보다 부드러운 말이 비교도 안될 정도로 도움이 될 것입니다.

    여러분들의 충고어린 말들이 있지만 사실 그런 부분에서 fender 님의 글들이 좋게 받아들여 지는 것도 있다고 생각합니다.


    휴.. 제가 괜히 껴들어서 끝나가는 글 질질 끄나하는 생각도 드네요

    많은 글들 써주셨는데 좋은 내용만 잘 걸러 보겠습니다.

    이만 좋은 주말 되세요..



    0
  • iops
    1k
    2017-06-17 16:56:10.0

    vollfeed / 결국 grade를 구분하는건 별반 차이 없는거 같은데

    틀린 말이라 생각하심 정정하겠습니다.

    그리고 직접적으로 알고리즘 외우라고 말하지 않더라도

    주니어 개발자들에게 알고리즘을 배우라고 얘기하면 갈 수 있는 방향성이 결국 외우는거밖에 없다라고 생각됩니다.

    아무도 중요한것을 제대로 가르쳐주지 않으니깐요.


    0
  • kenu
    37k
    2017-06-17 19:32:04.0

    vollfeed//

    맘에 드는 글 감사합니다. 편집 죄송합니다.

    0
  • 술술
    140
    2017-06-17 22:49:00.0

    실무에 쓰는 프로그램은 종류가 수십, 수백에 이르는데 그걸 언제 다 공부하고 있습니까. 모든 기술 분야가 완전히 동일한게 없고 조금씩 다 다른데, 그걸 통과하는 기초 분야가 있고 그게 알고리즘이고 자료구조잖아요.

    이걸 가장 쉽게 익히는 방법인 책에 나오는 낡고 구닥다리인(이 말도 웃기네요. 여기서부터 시작인데 낡고 구닥다리라) 문제들을 알고리즘으로 풀어나가는 과정을 공부하라는 겁니다.


    가장 당연한 걸 기초적인 부분이 부족한 게 신입이고(물론 저도 그렇습니다^^), 우선순위가 있다면 자료구조랑 알고리즘이 먼저라고 이야기하고 싶은 겁니다.

    0
  • start28
    36
    2017-06-18 09:12:28.0

    귀감이 되는 글 너무 감사합니다.. 처음 프로그래머로 직업 전향을 결정했을 때 항상 어떤 분야든 기초가 존재하고, 그 기초를 잘 쌓아둬야 중역이 되었을 때 생산적인 일을 할 수 있을것이라 판단하여 컴퓨터구조(Code라는 책이 컴퓨터의 역사와 컴퓨터 구조의 전체 뼈대를 이해하는데 많은 도움이 되었습니다), C언어, 자료구조 등 기초적인 부분부터 학습을 해왔었습니다. 하지만 주변 지인(프로그래머)이나 okky사이트의 영향력 있는 분들이 이러한 부분을 '알면 좋으나 실무에 쓰이지 않는 교양'정도로 이야기하시기에 '공부방향이 잘못된 것인가' 하고 혼란스러웠던 적이 많았는데 제 학습 방향에 대해 다시 한번 확신을 가지게 되었습니다.


    0
  • 거울
    2017-06-18 11:15:03.0

    인간은 아둔한 것이 

    이 안에서도 서로 위아래로 나누고 분류를 하네요.

    이래서 전인교육이 필요하다 하는 것 같습니다.


    그 해박한 지식으로 필요성만 설파하고 자신은 어떻게 다른지 은연중에 내포할 시간에 지식 컨텐츠를 만들어주시면 좋겠네요

    여기서 이러시는거 헛똑똑입니다.


    0
  • 앙앙이
    1k
    2017-06-18 11:37:48.0 작성 2017-06-18 11:39:15.0 수정됨

    // 거울

    아.. 미챠.. 활동 점수 50점... 


    이보세요.

    기술 세계에서 기술력이 계급인거지 인문학인줄 아십니까?

    그런 정신으로 우주 왕복선 만들면 어찌 되는지 아세요? 발사하는 과정중에 꽝~ 하고 터지는겁니다.

    0
  • 거울
    2017-06-18 11:58:28.0

    인문학을 잘못 알고 있군요...

    그리고 전 인문학을 이야기 한것이 아닌데..

    아 그리고

    활동점수가 높아야 말 할 수 있는 건가요

    그렇다면 죄송합니다.

    0
  • seychelles
    405
    2017-06-18 13:32:35.0

    개발자 되기 어렵네요. 저는 코더 하겠습니다.

    0
  • seychelles
    405
    2017-06-18 14:29:00.0

    vollfeed님이 말씀하려는 것은 현재 상태에 대한 것보다는, 이래야 한다 이랬으면 좋겠다는 바람 혹은 주장에 가깝습니다. 어떤 의미에서 이렇게 말하냐면, vollfeed님 관점에서는 치킨집을 차려야 할 만한 사람들이, 여전히 돈을 받고 이 직종에서 일하는 것이 가능하다는 뜻입니다. 알고리즘에 대해 딱히 고민하지 않는 사람들도 여전히 밥벌이를 잘 하고 있으며, 오히려 숫자로 치면 vollfeed님이 말씀하시는 '개발자의 자격'을 갖춘 사람들보다 vollfeed님 기준에서 부적격인 사람들이 더 많을 것 같습니다. 물론 돈을 벌 수 있다고 해서 그들이 충분히 '좋은' 개발자라고 보기는 어려울 것 같습니다. 하지만 적어도 치킨집을 차릴 정도로 무능력해서 시장에서 살아남지 못할 정도는 아닙니다. 그래서 현재에 대한 투영이라기보다는 바람이라는 표현을 써보았습니다.


    저도 이 토론에 참여할 만한 기본적인 소양은 부족합니다. 다만 저는 심리학적인 관점에서 이 글을 바라보게 됩니다. 어쩌면 좀 예상치 못한 특이한 댓글일 수 있겠다는 생각도 듭니다.

    토론이 이렇게 길어질수밖에 없는 것은 감정을 뗴어놓고 생각할 수 없습니다. 상대를 설득하기 이전에 상대가 어떤 이유로 이러한 주장을 고수하게 되는가에 대한 심리적 근거를 찾아보아야 합니다. 본인이 특정 주장을 고수하고 있다면 그 기저에 있는 심리적 근거를 찾아보고, 이것을 제끼고 생각해 볼 필요가 있는지 확인하여야 합니다. 

    저는 프로그래밍 자체에 대한 지식은 많이 부족합니다. 하지만 최근의 논의를 대략적으로 살펴본 결과, 이렇게 거칠게 요약해 볼 수 있었습니다. 예전보다 프로그래밍에 있어서 중요한 요소들은 전보다 많으면 많아졌지 절대 줄어들지 않았습니다. 기존에 중요하게 취급받던 알고리즘 자료구조와 같은 개념들에 대해서, 그것이 우선순위가 아니다 라는 주장이 나오는 이유는, 80년대 인기스타와 최신의 인기스타의 인기를 비교하는 것과 비슷할지도 모르겠습니다. 80년대 인기스타의 인기는 어마어마했고, 그에 비하면 지금 정상급 스타들의 인기는 별로라고들 이야기합니다. 다만 그 이유는 TV에 조명되는(그리고 단순 숫자로 보더라도) 스타 풀이 워낙 예전보다 많아졌고, 그만큼 인기는 분산되었습니다. IT에서 필요한 기술들처럼요. 일단 이것이 하나의 이유가 될 수 있겠고요. 또한 환경의 변화가 있겠습니다. 사용하는 기술의 발전에 따라, 수동으로 확인해야했던 어떤 분야들은 자동으로 처리가 되기 시작했고, 그러한 변화로 인해 또 새로운 분야에서 신경써야 할 일이 발생하는 등 (우선순위의 관점에 있어서) 예전보다 알고리즘 자료구조에 대한 중요성이 유지되는 것도 어쩌면 쉽지 않은 일일 것입니다. 위의 인기스타를 예로 들자면 개개인의 인기 순위 변동이겠습니다.

    그럼에도 여러 가지 중요한 것들 중 하나가 된 어떤 한 요소를 모르는 것에 대해서 개발자의 자격이 없다고 단정지을 정도로 그것을 중요시한다는 것은, 한 가지 가능성이 있습니다. 


    사람은 원래 본인 기준으로 생각하기 마련이므로 본인이 알고 있는 것은 '이정도는 알아야 한다'라고 생각하는 경향이 어느 정도 있습니다. 기본 상식에 대한 기준도 다들 다르죠. 내가 아는 것은 대개 '이정도는 알아야 한다' 범주에 속하지만, 생전 처음 들어본 것은 '이건 모를 수도 있다'고 관대하게 생각합니다. 

    또한 이런 마음가짐도 있습니다. 본인이 강점으로 가지고 있는 것을 다른 사람들도 중요시하길 바라는 마음. 저는 어렸을 적에 한문을 배워서 꽤 많은 한문을 알고 있습니다. 하지만 요새 한문이 잘 사용되지 않는 것에 대해 약간 아쉬운 마음이 있습니다. 그것을 다른 사람들 또한 중요시하여야 내 실력이 사용될 기회가 많아질 것이고 인정받게 될 것입니다. 그래서 자연스럽게 자신이 잘 하는 분야와 본인을 동일시하는 느낌, 알고리즘이 비교적 외면받는다 느낄때 그것을 원래 가야 할 자리로 되돌려야 할 사명을 받은 것 같은 그런 느낌이 들지도 모릅니다.


    저는 확실히 단정지을 수는 없습니다. 다만 그런 감정이 기저에 있는 것은 아닐지, 그래서 어떤것의 실제 가치보다 더 높게 그것을 평가하게끔 자신을 부추기고 토론을 도돌이표로 만드는 것은 아닌지 한번쯤 생각해 볼 필요는 있지 않을까 하고 생각거리를 던져 봅니다. 그리고 적어도 그러한 것들을 파악할 때, 좀 더 자유롭게, 주제에 대해 날을 세우지 않고 이야기할수 있는 토론 분위기가 될 수 있지 않을까 합니다. 일단은 적어 주신 여러 가지 용어들조차도 제가 처음 듣거나 잘 모르는 부분이 많기 때문에 댓글 자체는 매우 흥미롭게 보았습니다. 제가 이 댓글에서 말씀드린 부분을 한번 살펴 보신다면 좀 더 좋은 토론이 되지 않을까 생각합니다.

    0
  • 술술
    140
    2017-06-18 16:00:23.0

    seychelles //


    이 논란이 커질 때 어떤 분이 반대로 '니들이 그 분야에 실력이 부족하니까 다른 개발자를 물귀신으로 잡는 거다'라고 주장한 것과 무엇이 다른지 모르겠네요.


    게다가 알고리즘의 중요성, 개발자가 기본으로 가지고 있어야하는 부분이라고 주장하는 만큼 그 부분을 공부하고 있는 거겠죠. 아 물론 저는 중요하다고 주장하는 반면 제대로 못하고 있습니다. 부끄럽네요.


    1
  • seychelles
    405
    2017-06-18 17:03:21.0 작성 2017-06-18 17:13:15.0 수정됨

    술술//


    제 느낌이고 동의하지 않으실지도 모르지만 조금 다릅니다. 글쓰신 분은 토론의 주제를 '알고리즘에 대해서'라고 못박을 만큼 '다른 것과 비교한 알고리즘'이 아니라 그냥 '알고리즘'에 대해서 이야기하려고 하고 있습니다. 그러면서 '알고리즘을 모르면 개발자 자격이 없다'라는 말은 원글에 적혀 있는 '알고리즘에 대한 협소한 이해를 바로잡고자 나섰다'라는 말에 걸맞지 않게 IT 기술 전반을 놓고 보았을 때는 전체적으로 협소하게 느껴질 수 있는 결론으로 끝맺습니다. (이 결론이 없었다면 이 글의 주제가 이전의 토론과 맥락을 달리한다는 명분이 섰을지도 모르겠습니다) 그에 비해 어떤 경우에는 다른 것들이 우선순위가 되어야 할 필요가 있다고 주장하시는 분들은 적어도 대신해서 우선순위가 될 수 있는 대안을 몇 가지 내놓았기 때문에 특정한 주제에 얽매이는 느낌을 덜 느꼈습니다. 그리고 계속해서 '절대 알고리즘이 중요하지 않다는 것은 아니다'라고 꾸준히 이야기하셨고요. 그저 알고리즘이 초급이 공부할 최우선순위의 자리에 계속 있기에는 다른 중요한 것들이 더 생기지 않았느냐는 이야기인 것이죠.

    넵 저는 술술님이 말씀하신 2번째 문장의 반대, 본인이 이미 공부한 것, 그동안 내가 해온 작업에 대한 가치의 합리화라는 측면으로 해석할 수도 있다고 보는 것이죠. 이렇게 본다면 어떤 기술에 대해서 이야기할 때 왜 이렇게 태산과 같이 입장을 고수하는 사람들이 나타나는가에 대해서 이해할 수 있죠. vo와 map에 대한 이야기가 나올 때마다 스크롤바가 눈에 안보이게 짧아지는 것처럼요. 자신이 그동안 해왔던 수많은 작업들을 담보로 하기 때문에(설사 같이 토론을 나누는 사람은 모를지라도) 말이 길어지는 것 같습니다.

    0
  • 더미
    5k
    2017-06-18 19:23:08.0

    헐 건설적으로 보였는데

    중간중간이 아쉽네요.

    0
  • 열렙전사
    220
    2017-06-19 08:42:46.0 작성 2017-06-19 08:43:39.0 수정됨

    안녕하세요 이제막 사회에 진입하는 신입인데요

    알고리즘이 중요하다는건 예전부터 알고있었는데요 물론 글쓴이님 처럼 상세히는 몰라서 도움이 조금되긴했지만 이제 지긋지긋한 이 알고리즘이 왜 중요한지에 대해서는 그만 토론하고 말씀하신것처럼 how? 어떻게 배울것인가에 대한 조언을 해주신다면 참 좋을것 같습니다.

    0
  • 전재형
    3k
    2017-06-19 10:05:36.0

    단지, 이 글이 "알고리즘은 개발자에게 필수적인 교과목이다."라는것이 주제인데.

    왜 물어뜯는 것인지 모르겠네요.


    단지 글쓴이의 태도가 강경해서, 맘에 안든다는 것은 이해하나.

    '맘에 안듬'이 '잘못된 생각'이라고 연관 오류를 나타내는 듯한 댓글이 많은 것같아서

    보기 좋지 않네요.


    열렙전사 // 이글은 단지 '알고리즘은 개발자에게 필수' 이 말만 하고 싶은 거에요.

    HOW는 전공을 하셨다면, 교과서를 봐도 되고, 인터넷에 늘렸고, 알고리즘 문제풀이 사이트에서

    꾸준히 문제 푸는 걸로 훈련하실 수도 있겠네요.


    정리하면 // 어조가 마음에 들지 않는다해서, "감정"과 "논리"를 구별하지 못하고.

    하려고 하는 진짜 얘기가 뭔지도 모르게 이야기 전개를 흐리는 댓글이 마음에 안듭니다.

    1
  • kkey21a
    2k
    2017-06-19 10:54:49.0 작성 2017-06-19 10:56:37.0 수정됨

    전재형//

    대부분 간과하는 (심지어 가르쳐 주지도 않고, 강사도 잘모르는..) 일반 모형(ADT), 평가 척도(BigO 표기) 전략(그리디, 분할정복, 다이나믹 프로그래밍, 백트래킹, 정보 이론, 프루닝, radix, ) 등이 진짜 알고리즘의 핵심입니다. 

    말투를 떠나 위 예시들을 들면서 프로그래머가 가져야 할 기본 소양인 알고리즘이 먼가 거창한 것처럼 표현된 것도 사실이긴 하죠.


    PS

    물론 아래 댓글로 전 오해는 풀렸습니다만, 아무래도 오해할 소지는 충분히 있었다 생각합니다.

    0
  • fender
    9k
    2017-06-19 11:51:07.0 작성 2017-06-19 11:57:13.0 수정됨

    논리적으로 보아 둘 중 하나를 하면 되는 문제입니다:

    • "CPU를 다루는 모든 것은 알고리즘 문제이다" => 그냥 개발을 잘하려면 컴퓨터를 잘해야 된다는 동어 반복이 됩니다.
    • "알고리즘은 최소한 분할정복, 빅오표기, 동적 프로그래밍 등등... 을 알아야한다" => 각 개념들이 정말로 분야를 막론하고 우선적으로 배워야할 문제인지를 설득하면 됩니다.


    두 번 째 주장 자체는 근거에 따라 찬성할 수도 못할 수도 있는 이야기인데, 이를 증명하는 데 첫 번 째를 근거로 쓰니까 이야기가 이상해지는 것 뿐입니다.

    알고리즘이 중요한 건 맞지만 그게 무슨 무안단물인가요... 저도 반 세기 넘게 컴퓨터 관련 모든 분야의 근본 지식이 되는 절대 교본 같은 게 있었으면 참 좋겠습니다. 뭐 새로운 거 나올 때마다 보기 귀찮거든요.

    그리고 뭐 개발자끼리 등급 메겨서 남 비하하고 자부심 세우는 건 누가 무슨 이유로 언급해도 잘못된 태도입니다. 그게 아니라면 전에 '일당x부' 운운하던 분에겐 왜 그렇게 다들 민감했던 건가요?

    그리고 오픈소스 이야기는 그걸 주장의 근거로 쓰나 반박의 근거로 쓰나 권위에 대한 호소라는 점에서 똑같이 유치한 겁니다.

    여기서 오픈소스는 제가 제일 활발하게 한 것 같은데, 그럼 논리 필요없이 제가 결론 내면 다 납득하실 건가요? 최소한 논리를 다루는 개발자 사이의 토론은 그런 식으로 권위에 기대선 안된다고 봅니다.

    전 진짜로 알고리즘 관련해서는 이쯤에서 말을 줄일까 합니다. 이 정도까지 파급이 될 줄 몰랐는데 일주일도 넘게 토론이 이어지니 솔직히 좀 질리는 느낌입니다.

    찬성이든 반대든 논리는 나올 만큼 다 나온 것 같으니, 각자 오독이나 권위에 대한 호소나 타인 비하나 감정 싸움 등등 쓸데없는 부분을 걷어내고 논지만을 열린 마음으로 살펴보고 자신이 생각하는 최선의 공부 방향을 선택하면 될 문제라고 봅니다.


    1
  • 앙앙이
    1k
    2017-06-19 12:13:16.0

      나참.. 어떤 분들은 시니어, 주니어 이런 구분은 안하고 사시나봐요.

    그렇게 나누는것은 등급 나누기에 해당 없나봐요.

    이 글이 등급 나누고 비하했다고 하는데

    잘도 그런글을 오키에서 "Editor's Choice" 첫글로 올려났습니다.

    유저하고도 쌈하는것이 모자라서 오키 운영진들하고도 쌈하고 싶나봅니다.

    0
  • tale33
    44
    2017-06-19 12:23:20.0 작성 2017-06-19 12:28:20.0 수정됨

    위에서 설명하는 내용이 대부분

    내가 '서비스하는 프로그램에서는' 이라는 전제조건이 붙는것 같습니다.

    제가 생각했을때,

    최근 서비스하는 90%이상의 프로그램에서 OOP, DDD등의 설계 패러다임과 기본적인 자료구조의 쓰임이 중요한 가치를 가지는것 같습니다. ( 대부분의 앱 및 기타 서비스 )

    10%정도의 프로그램은 알고리즘이 필수적인 요소인것도 같습니다. (이미지 프로세싱, 코어 엔진, 대용량 서버, 기타)

    이제껏 일했던 경험으로는,

    설계 패러다임이 중요하지 않은 프로그램은 없었지만, 알고리즘은 필수요소는 아니었던 적이 많습니다.

    둘다 잘 하면 좋겠지만, 우선한다면.. 전자가 좋은것 같네요. ( ABCD중 : 설계 B, 알고리즘 C의 느낌으로) 


    A아니면 D다 라는 생각은 좋지 않은것 같습니다.

    (이미 설계가 끝났고, 최적화만 하면 된다면 알고리즘이 중요할 수도 있고, 상황에 따라 다르니까요.)


    0
  • 모드쿠
    571
    2017-06-19 15:25:27.0

    알고리즘을 문제해결 능력, 사고력으로 보는게 맞다고 봄.

    0
  • 양산형개발자43
    70
    2017-06-19 15:44:47.0

    fender님의 글을 평소에 좋아하는 1인입니다

    이번에 쓰신 알고리즘과 디자인패턴 학습순서 글에 관련된 대부분의 글을, 자신의 글에대한 의견으로 받아들이셔서 하나하나 답변을 해주시는 모습을 보고 좀 약간 책임감을 많이느끼시는(?) 분이구나.. 라고 생각했습니다. 그래서 많이 지치신거같고.. 좀 안타까웠습니다. 

    그리고 누가 옳냐 그르냐는 제쳐놓고, 이런식으로 내공이 많으신분들이 서로의 주장(삼국지 일기토를 보는듯한..?)을 하시는것만 읽어봐도 내용이 많이 유익한것 같습니다. 감사합니다.

    0
  • unigoon3
    242
    2017-06-19 19:56:41.0

    곁다리 얘기: 씨로 배우는 알고리즘 이 책이 좋았는데 2권은 너무 어려워서 집어던졌다는.

    교과서 내용 이론적으로 증명 같은게 많고 너무 재미없었다는 기대하던 흥미진진한 알고리즘이 아니었다는.


    0
  • unigoon3
    242
    2017-06-19 19:59:28.0 작성 2017-06-19 20:00:17.0 수정됨

    참으로 외람된 말이나 교과서 내용 확 바꿨으면 좋겠음. (예를들자면)알고리즘의 5원칙 같은걸 만들어서(ex 분할정복) 탑다운 방식으로 설명해나가면서 예시 프로그램들도 보여주고

    0
  • 카이사르
    6
    2017-06-20 16:08:13.0

    글을 잘 쓰셨지만, 글 안에 몇 가지 비약이 있었기 때문에 논란도 되고 그런 것 같습니다.

    개인적으로 회사 업무(해당 회사가 먹고 사는 사업모델)에 따라 다르지 않을까요.

    알고리즘을 개발해서 먹고 사는 회사는 알고리즘을

    복잡한 시스템을 구축해서 먹고 사는 회사는 설계 부분을


    어떤 회사는 사업 특성 상 C언어만을 사용해야 하는 경우도 있고,

    어떤 회사는 자바나 C#과 같은 언어를 사용해야 되는 경우가 있습니다.

    뭐 등등 다양하겠죠.


    이런 부분들을 뭐가 좋다 나쁘다로 일반화 시키기 어렵습니다.

    개발자로서 둘다 공부하는 것은 맞다고 봅니다.

    하지만,

    저는 업무 특성 상 복잡한 분산 시스템을 설계하고, 고객이 원하는 아키텍처의 품질 속성을

    만족시킬 수 있는 기술을 뽑아내는 작업을 많이 합니다.

    그리고 설계된 부분들이 무엇을 해야할지를 정의합니다.

    개발 12년차이지만 솔직히 알고리즘을 알아도 어떠한 도움없이 구현을 제대로 하지는 못합니다.

    물론 옆에 서적이 있다면 또는 구글링(좋은 도움)이 가능하다면 멋지게 구현해 냅니다.


    하지만, 앞서 설명한 제 업무는 아쉽게도 책이나 구글링이 되지 않습니다.


    그래서 저의 경우는

    알고리즘 공부는 어떤 아이디어를 찾아내는 방법을 연습한다는 차원에서는 좋지만

    결국 고객과 그 주변의 이해 당사자들과 업무를 하는 측면에서는

    많은 도움이 되지는 못했습니다. 그래서 12년이 되도록 공부를 안했을 수도 있고요.


    결국, 글의 제목처럼 왜 해야 되는가는 좋지만, 내용에서 처럼 못하면 등급이 나눠지고,

    채용을 안하고 이런 문제는 잘못 다뤄진것 같습니다.

    0
  • 슈붕이
    10
    2017-06-21 00:34:45.0 작성 2017-06-21 00:37:03.0 수정됨

    알고리즘의 효용성은 구글이 이미 사업적으로 가치있는 일임을 증명한 것 같습니다.


    다만, 저 역시... 알고리즘에 약한 탓에... 나약한 짜증을 쉽게 토해내네요.


    요즘들어 알고리즘을 열심히 공부하고 있지만

    몸만 혹사시켜봤지, 머리를 혹사시킨 경험이 적어서...

    이거 쉬운건데... 라는 잘난척 하는 글귀들에 서럼이 북받혀 오르곤 합니다. (ㅡ_ㅜ)


    알고리즘 잘한다고 잘난척 할 필요도 없고

    마찬가지로 최신기술에 빠삭하다고 자만할 필요도 없고...

    저희 업의 본질을 망각하지 말고

    내가 부족한 무언가를 타인은 잘한다는 사실을 진심으로 인정하는게...

    그리고... 내가 부족한 무언가가 정말 갖고 싶은거라면

    그걸 열심히 채워넣는 게 어떨까 싶습니다.

    (개인적인 사견입니다만... 알고리즘이란 분야... 너무 갖고 싶은 능력입니다. ㅡ_ㅜ)


    늦었지만, 다들 즐코 하세요. ^-^

    0
  • 호두
    25
    2017-06-21 19:08:23.0 작성 2017-06-21 19:20:12.0 수정됨
    "알고리즘 모르면 D급 개발자".. 가 아니라 "알고리즘 모르면 절대로 A급 개발자가 못된다" 정도가 적절한 표현 아니였을까 싶네요
    0
  • Helix7
    12
    2017-06-22 22:39:09.0 작성 2017-06-22 22:39:24.0 수정됨

    필드에서 뛴지 4개월 되가는 신입입니다.

    아직 학생 말투에서 못벗어나서 헛소리해도 봐주세요 ㅎ.ㅎ


    알고리즘은 꼭 필요한 게 맞습니다.

    글 작성자분 처럼, 알고리즘 모르면 C, D 급 개발자라고 생각합니다.

    알고리즘이 꼭 다는 아닙니다.

    여러 분들이 댓글 다신 것 처럼 알고리즘만 알고 딴건 모르면 말짱 도루묵이죠.


    그런데, 둘다 상반되고 둘다 맞는 소리긴 한데


    꼭 필요한 것은 자기가 배운 '알고리즘'을 

    '어떤 상황'에 '어떤 알고리즘'을 적용 시킬 것인지를 알고 있는

    개발자가 진짜 개발자, 소위 말하는 A급 개발자라고 생각합니다.


    물론, 이렇게 결정할 수 있으려면, 알고리즘을 항상 염두해 두고

    개발하시는 분들이겠죠?!


    그리고, 알고리즘을 모른다고 해도 정말로 개발자시라면

    자기가 짠 코드 자기가 책임지려 합니다.

    (다들 아시자나요?)

    언젠간 최적화 문제에 맞닿게 됩니다.

    그러다보면 구글링 하던, 정말 좋은 스승님을 만나던 점점 성능이 좋아지는

    어플 or 솔루션 or 인프라 등등을 만들겠죠...


    자기가 짠 코드 자기가 책임 안질려고 하는 분들이

    진짜로 치킨집 자본 모으는 분들이 됬으면 합니다...


    p.s

    실제 필드에 그런분들이 너무 많아서 충격을 받았습니다.

    소위 말하는 학교 플젝때 버스타는 놈들 수준이더라구요 ㅎ.ㅎ

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