fender
8k
2017-06-14 10:24:12.0 작성 2017-06-14 11:45:59.0 수정됨
11
1688

알고리즘 논란에 대한 단상


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

그 분들에 의하면 저는 갑질을 즐기고 신입 개발자의 실력을 두려워 하는, 그리고 개발은 그냥 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
  • 댓글 11

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

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


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


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


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

    0
  • fender
    8k
    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
  • 신입
    3k
    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
    2
    2017-06-15 09:21:02.0 작성 2017-06-15 09:23:42.0 수정됨

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


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


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


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

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

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


    하마답변//

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

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

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

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

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

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

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

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

    0
  • fender
    8k
    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
  • 장지락
    493
    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
  • 로그인을 하시면 댓글을 등록할 수 있습니다.