asmpro
722
2016-07-27 22:34:52
64
52786

인정받는 프로그래머가 되는 것은 어려운 일이 아닙니다.


저는 타인의 실력을 볼 때 몇 가지 기준이 있습니다.


1. 자신도 시간이 지나면 알아볼 수 없는 코드

많은 프로그래머들이 말도 안되는 핑계를 댑니다.

코멘트나 네이밍에 신경쓰면 더 개발이 오래 걸린다구요.

좋은 네이밍에 좋은 코멘트를 달고 있는 프로젝트가 코멘트 없는 프로젝트보다 똑같은 기능을 개발하는 데 더 오래 걸리는 경우는 존재할 수가 없습니다.

구구단 같은 거 만드는 그런게 아닌 이상요.

네이밍, 코멘트는 습관입니다.

그냥 귀찮아서 안하는 것 그 이상도 그 이하도 아닙니다.

몇 년뒤에 본인이 짠 코드조차 햇갈리면 기본이 안되어 있는 겁니다.


2. 상수, 문자열을 코드에 직접 사용

C에서 배열의 시작인 0과 같은 변하지 않는 상수가 아닌 이상 모든 상수는 따로 제대로된 네이밍으로 정의를 해야 합니다.

문자열은 리소스로 관리하구요.

리소스 귀찮다구요?

어셈블리로도 매우 쉽게 다국어 문자열 리소스 매우 쉽게 관리합니다.

어셈블리보다 어려운 언어가 존재하지 않는 이상 문자열을 직접 집어넣어야 할 이유가 없습니다.

프로그밍 6개월만 했어도 상수와 문자열을 코드에 집어 넣지 않고 따로 관리하는게 얼마나 편하고 버그를 줄이는지 알 수 있습니다.


3. 비슷한 코드를 복사, 붙여넣기

전혀 어렵지도 않게 모듈화 할 수 잇는 것을 그냥 복사해서 붙여 넣습니다.

거기다 값까지 리소스를 사용하지 않고 사용하면 나중에 수정할 때 일일히 검색하거나 눈으로 보면서 찾고 고치다 에러나면 어디서 났는지 모르는 둥 이건 프로그래밍의 경력의 문제가 아닙니다.


4. 인터넷에 떠도는 코드 복사해 붙여넣기

적어도 코드를 가져다 붙여 넣을 때는 그 코드가 어떤 원리로 작동하는지 정도는 이해를 해야 합니다.

이해를 해서 처낼 부분 처내고 수정할 부분은 수정해서 최적화 할 정도는 되야 되는데 원리조차 이해 못하는 것을 가져다 붙여넣는게 너무나 흔합니다.

무슨 논문수준 지식이 필요한 것이면 몰라도 떠도는 코드 중 99%는 고난이도를 요구하지 않는데도 불구하고 알려고 하지를 않죠.

자신이 집어 넣은 코드에 대해 잘 모르면 프로그램이 필요 이상 비대해지고 파일도 커지며 문제가 생기면 해결도 곤란해 집니다.

거대한 프로젝트 일수록 필요이상의 리소스를 낭비하게 되는 것이죠.


5. 최소한의 디버깅 지식

디버깅이 어려워 보이지만 아주 단순한 방법으로도 디버깅을 할 수 있습니다.

모든 언어에 통용되는 방식인 로그를 찍는 거죠.

이상 작동하면 관련 함수들 변수 로그 찍으세요.

로그 찍어보면 원인의 90%이상 발견이 됩니다.


많은 프로그래머들이 신입이나 경력이 짧은 사람들에게 너무 큰 걸 요구한다고 하는 경우가 많은데 제 경우 습관자체가 잘못 들어서 프로그래밍을 잘할 수 없는 사람들을 너무 많이 봤습니다.

제가 위에 써 놓은 5가지중 4가지는 그냥 습관만 잘들이면 되는 그런 것입니다.

코멘트, 네이밍 좀 신경쓰고, 코드에 숫자, 문자열 직접 넣지 않고 겹치는 코드 모아서 하나의 함수 만드는 것은 컴공과 1년 정도만 다녀도 하고도 남는 일입니다.

로그 찍는 것 알다시피 거의 대부분이 다 지원합니다.

난이도의 문제가 아니라 습관의 문제입니다.


위의 다섯가지만 몸에 배면 코드를 매우 읽기 쉬워지며 버그 또한 극히 줄어듭니다.

어셈블리어로 개발할 때 조차 디버깅 때문에 골치 아픈 경우가 드뭅니다.

습관만 잘 들이면 컴공 입학해 졸업할 때까지 충분히 몸에 배고도 남을 습관들인데 코드들 보면 정말 이렇게 개발하면서 돈을 받을 수도 있다는 생각이 들게 할 때가 많습니다.


그리고 뛰어난 개발자가 되기 위한 가장 기본적인 자세는 제대로 모르는 코드를 그냥 넘어가지 말라는 것입니다.

어떤 코드를 봤는데 이해가 안되면 코드를 분해해서 보세요.

잘 모르는 명령 있으면 검색해서 명령의 정의와 샘플 코드보고 이해하고 넘어가기 바랍니다.

그걸 계속하다보면 검색횟수가 점점 줄어들기 시작할 겁니다.


또 한가지는 라이브러리 없이 프로그래밍 하는 훈련을 하기 바랍니다.

개인적으로 C + OS API 프로그래밍을 추천합니다.

C로 표준 라이브러리도 사용하지 말고 C 기본 문법에 OS API만 사용하는 것이죠.

하면 할수록 알기 싫어도 알고리즘에 대해 알게 되고 OS에 대해 이해하게 됩니다.

학생 때 하면 가장 좋고 직장인이더라도 취미 삼아 해보기 바랍니다.

일단 어셈블리리, C + OS API 프로그래밍이 가능해 지면 어느 정도 플랫폼과 CPU의 제한에서 벗어나게 됩니다.

컴파일러가 어떤 식으로 최적화 할지도 보이구요.

고급언어로 프로그래밍을 하더라도 로우레벨 프로그래밍을 해보지 않은 사람보다 구조적으로 더 빠르게 작동하게 만듭니다.

알고리즘 또한 라이브러리 없이 모든걸 만들어봤기 때문에 비교자체가 안되구요.


아마 제말을 못믿는 분들도 있을 겁니다,

하지만 어셈블리, C, OS API 프로그래밍을 해본 사람이라면 공감할 수 있을거라 생각합니다.

위의 단계를 익히고 나면 새로운 프로그래밍 언어를 익히는 것에 대한 어려움은 거의 없을 겁니다.

제가 30년전 8BIT 어셈블리 프로그래밍을 4년 정도 하고 난 이후 언어를 익히는데 어려움을 느껴본적이 없듯이요.

38
36
  • 댓글 64

  • asmpro
    722
    2016-07-27 22:49:39

    많은 프로그래머들이 왜 기초지식이 필요하고 컴파일러, OS 등에 대해 알아야 되는지 이해를 못하는 경우가 있습니다.

    제 경우 프로그래밍 입문 이후 한동안 8비트 어셈블리를 주로 사용했습니다.

    CPU가 곱셈과 나눗셈을 지원하지 않았기 때문에 쉬프트와 더하기 빼기 연산을 이용해서 곱셈, 나눗셈 부터 만드는게 프로그래밍의 시작이였죠.

    한마디로 아무것도 없는 바닥에서 모든 걸 만든다고 생각하면 됩니다.

    인터넷은 커녕 PC통신도 없던 시절이고 책도 어셈블리 관련 책은 몇권 되지 않았습니다.

    그냥 아무것도 없는 상태에서 하드웨어 제어까지 직접 어셈블리로 제어했습니다.

    알고리즘은 저절로 익혀지는게 CPU가 워낙 느려 수단과 방법을 안가리고 빠르게 속도를 내는 방식을 써야 합니다.

    별짓을 다하는 거죠.

    메모리 또한 엄청 작으니 데이터를 비트단위로 쪼개 저장하는 건 기본이였습니다.


    위와 같은 프로그래밍을 현업에서 하라는 게 아닙니다.

    본인만의 학습방법으로 사용하라는 것이죠.

    처음에는 매우 시간이 오래 걸릴 수 있는 인내가 필요한 방법입니다.

    하지만 일단 익숙해지면 프로그래밍이 훨씬 쉬워지게 됩니다.

    수학과 대학원 생에게 중학교 수학이 쉬운 것처럼 되는 겁니다.

    4
  • asmpro
    722
    2016-07-27 22:55:16

    기초는 프로그래밍에 대한 전반적인 이해력을 높이는데 매우 중요합니다.

    초등학생에게는 중학수학이 어려울지 몰라도 대학생에게는 중학수학은 매우 쉽습니다.

    기초를 탄탄하게 하는 가장 좋은 방법은 근본적인 이해를 하는 것입니다.

    프로그래밍의 근본적인 이해는 결국 OS와 CPU에 대한 이해입니다.

    OS와 CPU에 대해 가장 쉽게 이해할 수 있는 방법은 C (가능 하면 어셈블리) + OS API  프로그래밍이구요.


    어셈블리, OS API 프로그래밍이 엄청 어려운 걸로 아는 분들이 많은데 과거에는 프로그래머들 대부분이 어셈블리, C, OS API로 프로그래밍을 했습니다.

    직업이 프로그래머라면 그냥 누구나 다 하던 그런 겁니다.

    고전 8비트 게임들 전부 어셈블리로 개발됐습니다.

    업무에 사용하라는 게 아닙니다.

    학습하는 방법으로 사용하라는 것이죠.

    익숙해지면 프로그래밍의 범위가 과거와는 비교가 안되게 넓어지게 될테니까요.

    4
  • fender
    14k
    2016-07-27 23:03:11

    우선 좋은 글에 추천부터 누르고 적습니다.

    제가 워낙 로우레벨 쪽과 거리가 먼 분야만 해서 그런지, 라이브러리를 사용하지 않는 코딩이나 알고리즘 연습의 중요성을 강조하신 부분을 제외하고는 모두 공감이 가는 내용인 듯 합니다.

    개인적인 생각으로는 이젠 저수준 / 고수준 프로그래밍의 구분은 웹에서 백엔드와 프론트 엔드 이상으로 각각 전문화 된 영역이 된지 오래인 것 같습니다.

    물론 둘 다 잘해서 나쁠 것은 없지만, 더 이상 자바스크립트는 서버 개발자라면 누구나 할 수 있는 그런 것이 아니듯이, 고수준의 프로그래밍도 저수준만 이해하면 자연히 알게되는 그런 분야가 아니게 된지는 꽤 오래 되었다고 생각합니다.

    그래서 저는 주력 언어가 자바나 닷넷 같은 고수준의 언어라면 굳이 운영체제 수준의 코딩이나 알고리즘에 집착하기 보단 차라리 디자인 패턴이나 아키텍쳐와 같은 고수준 영역에 집중하는 것이 경쟁력을 키우는 데 도움이 된다고 생각합니다.

    8
  • asmpro
    722
    2016-07-27 23:08:50

    제가 얘기하는 것은 근본적인 이해가 컴퓨터 프로그래밍의 전반적인 학습능력을 높힌다는 겁니다.

    새로운 언어를 익히는데 들이는 시간부터, 객체지향, DB 등 거의 모든 분야에 있어 쉽게 접근할 수 있게 됩니다.

    중학교 때 중학교 수학 어렵다고 느꼈는데 대학가보면 아무것도 아니잖아요?

    3중 적분 난이도를 이해하게 되었는데 2차 함수 수준을 공부해야 하면 매우 쉬운 것과 비슷합니다.

    코드에 대한 최적화, 알고리즘, 설계 등 이해력 자체가 월등하니 추상화된 영역에 있어서도 훨씬 쉽게 접근하고 익히게 됩니다.

    저는 시작은 어셈블리로 했지만 90년대 중반이후 비주얼 언어 위주의 프로그래밍을 하면서 서버 개발할 때와 DLL 등 속도가 필요한 부분만 C로 개발했었습니다.

    시간으로 따지면 어셈블리나 C보다 비주얼 언어의 사용기간이 월등히 깁니다.

    저는 지금 급하게 뭘 만들어야 하면 Visual Studio부터 실행할 겁니다.

    4
  • 리액트_어셈블러
    171
    2016-07-27 23:11:38

    좋은 내용이네요.

    어셈블리나 OS,컴파일러등은 알면 좋은거 같아요 ㅎㅎ

    해킹 유튜브 좋은 방송이에욤~

    짬날때 한번씩 보면 좋을듯 합니다.

    원리를 안 다음에 GITHUB에 있는 jquery,java,v8engine,linuxos,httpprotocol,

    nodejs,php,mongodb,tomcat,android,angularjs,javascriptwebkit,jenkins,

    ionic,html5,spring,mybatis,maven,hibernate,mariadb,gcc,eclipse

    등의 소스를 짬날때 보면 실력이 많이 늘거 같은데 시간이 없어서 잘 안하게 되긴하네요.

    java-----------------------------------------------------------------------------------------------.....

    (짬)    javascript

                  linux

                      android

                          c,c++,assembly

                                compiler

                                     html5,jquery

                                          php,asp

                                                ......

    java-----------------------------------------------------------------------------------------------.....

    [스무디 TV]

    https://www.youtube.com/user/tmanelshrghk

    2
  • Bill
    92
    2016-07-27 23:14:49

    저도 fender님 글에 동의합니다. 

    운영체제나 CPU등을 깊게 이해해서 나쁠껀 전혀없지만 꼭 필요한것도 아닙니다. 최신 기술들이 주는 혜택 중 하나가 프로그래머들도 하여금 이러한 로우레벨을 신경쓰지 않아도 쉽게 개발할수 있게 해준다고 생각합니다. 어느 영역의 개발을 하냐에 따라 집중해야 하는 분야가 확실하게 분리되는거 같습니다.

    0
  • fender
    14k
    2016-07-27 23:20:50

    글쎄요... 과연 지금 시점에서 운영체제를 이해하는 것이 자바 같은 언어를 배우기 위한 근본적인 기초 지식일까요?

    개인적인 경험으로는 C언어를 오래하다 자바 언어로 넘어오는 분들의 경우 C언어 경험이 도움이 되는 경우보단 되려 방해가 되는 경우를 좀 더 자주 본 것 같습니다.

    스크립트 언어와 컴파일언어, 객체지향 언어와 함수형 언어의 관계도 그렇지만, 특정 언어만 오래하다보면 해당 언어의 고유한 접근 방식이나 그 언어를 사용하는 개발자 커뮤니티의 문화 같은 것들이 습관으로 굳어져서 다른 성향의 언어 적응이 힘들어지는 경우가 흔합니다.

    실제로, C 언어만 오래한 분들의 경우 자바 같은 언어를 접하면 객체지향에 대한 이해 부족으로 철저히 절차지향적인 접근을 한다던지 마이크로 최적화에 지나치게 집착하는 등의 어려움을 겪는 경우를 꽤 많이 보았습니다.

    그렇다고 C언어를 알면 무조건 자바를 배우는 데 해가 된다던지 C언어는 배울 필요가 없다던지, 언어는 한 가지만 배우라는 이야기를 하고 싶은 것은 아닙니다.

    단지 자바 같은 고수준 객체지향 언어와 C 같은 저수준 절차지향 언어를 익히는 데 필요한 기본지식이나 접근 방법은 확연히 차이가 나기 때문에, 어느 한 쪽이 다른 쪽 언어를 배우는 데 기본이 된다거나 크게 도움이 되는 관계는 아니라는 주장일 뿐입니다.

    1
  • asmpro
    722
    2016-07-27 23:33:03

    흠...

    학생들은 학교 공부를 하고, 직장인의 경우 직장일을 하면서 "학습용도로 로우레벨 프로그래밍을 해보라"는 의미로 쓴 글입니다.

    절차지향과 객체지향은 둘 다 기본이상은 다뤄야 하는 기본의 문제라 생각했기에 따로 언급하지 않았구요.

    컴공과에서 배우는 과목은 기초수준으로 당연히 익혀야 한다는 가정하에서 쓴 글입니다.


    사람들이 로우레벨 프로그래밍에 대한 오해가 좀 있는데 제대로 로우레벨 프로그래밍을 익혔다면 어떤 언어를 사용하던 도움이 될 수 밖에 없습니다.

    일단 코딩 습관 자체가 효율적일 수 밖에 없습니다.

    메모리를 적게 쓰고 성능을 높이는 방식으로 코딩하는게 아예 몸이 밸수밖에 없거든요.

    디버깅 능력자체도 로우레벨 프로그래밍에서 디버깅을 잘하는 사람이 고급언어에서 디버깅 못하는 경우는 존재할 수가 없습니다.


    C언어에 익숙한데 자바를 잘 못다룬다는 얘기는 제가 예전 8비트 도스시절 프로그래밍 하다 윈도우 이벤트 베이스 프로그래밍에 적응 못하는 사람 봤던 경우와 비슷한 경우 같습니다.

    그런 경우는 솔직히 얘기해서 그 사람이 언어에 익숙한거지 프로그래밍에 대한 이해도 자체가 높은게 아니기 때문에 발생한 일인 것 같습니다.

    제 경우 시작은 어셈블리로 시작했지만 생산성 높은 언어로 계속 갈아타면서 결국엔 .Net에 정착했습니다.

    2
  • Bill
    92
    2016-07-27 23:46:08
     직장인의 경우 직장일을 하면서 "학습용도로 로우레벨 프로그래밍을 해보라" 

    저는 시스템 엔지니어나 로우레벨 언어를 쓰는 개발자가 아니라면 추천하고 싶지는 않습니다. 물론 로우레벨 언어를 할 줄안다면 어떠한 경우에도 플러스가 될수 있습니다. 예로 자바나 .NET 개발자가 학습용도로 로우레벨 프로그래밍을 하는것보다 아키텍쳐나(예를들어 DDD, Event Sourcing, CRQS 등등) 프로그래밍 기법(Event driven, Reactive programming...)등을 공부하는게 실력향상이나 커리어에 훨씬 도움이 된다고 생각합니다. 지극히 개인적인 생각이지만 어떤분야에 있냐에 따라 뭘 공부해야되는지를 모르는 분들이 많은거 같습니다.

    1
  • asmpro
    722
    2016-07-27 23:46:21

    라이브러리 없이 개발해 보는 것은 응용력의 배양에 엄청난 도움이 됩니다.

    아무것도 없으니 오직 자신의 머리로 모든 알고리즘을 구현해야 합니다.

    책에서 본 알고리즘도 있지만 때에 따라서는 본인이 생각한 방식이 더 좋을수도 있습니다.


    문제 해결 능력 또한 매우 좋아집니다.

    없으면 만들면 되거든요.

    언어가 제공하지 않거나 인터넷에 라이브러리로 없으면 못만드는 사람들이 태반입니다.

    이 세상에 모든게 다 만들어져 있을리도 없을뿐더러 있더라도 모든 상황에 적절하게 사용할 수 있는 것도 아닙니다.

    0
  • Bill
    92
    2016-07-27 23:53:51

    물론 라이브러리 없이 혼자 만들어 보면 문제해결능력도 늘어나고 실력도 좋아집니다. 하지만 그게 효율적이지는 않습니다.

    공부하는 학생이라면 그렇게 해보라고 권장은 하겠지만 실무에 있는 개발자에게는 오히려 세상에 어떠한 라이브러리들이 있는지 알고 올바른 것들은 선택해서 개발할수 있는 능력이 더 중요하다고 생각합니다.

    진짜 원하는 기능을 해주는 라이브러리가 없다면 어쩔수 없지만.. 거의 90% 이상은 이미 존재 하고 있다고 생각됩니다. 

    0
  • asmpro
    722
    2016-07-27 23:54:15

    많은 사람들이 오해를 하는 것 같습니다.

    직업 프로그래머가 어셈블리로 OS API프로그래밍에 어느 정도 익숙해지는데 걸리는 시간은 6개월이면 충분합니다.

    일단 6개월 정도 익히면 평생 도움이 됩니다.

    제 경우 30년전 익힌 어셈블리 프로그래밍이 수십년간 도움이 됐습니다.

    실제 어셈블리 프로그래밍으로 돈 번적이 없음에도 불구하고 어셈블리 프로그래밍 덕분에 그 이후 프로그래밍을 매우 쉽게 익혔습니다.

    전공이 컴공이 아니였는데도 불구하고 언어를 익히는데 어려웠던 적이 없었고 지금 제가 갖고 있는 책들도 프로젝트관리, Code Complete, Effective 시리즈, Design Pattern, Game Programming Gem시리즈, 네트웍, 보안, DB 책 등 직접언어 매뉴얼은 단 한권도 없습니다.

    C의 경우에는 특별히 익힌다는 개념자체 없이 사용을 해서 언제부터 C를 다뤘는지도 기억이 안납니다.

    0
  • fender
    14k
    2016-07-27 23:58:51

    @asmpro //

    말씀하신 그 효율적인 코딩 습관이라는 건 좋은 덕목이긴 합니다만, 다루는 계층이 달라지면 실질적인 성능은 예컨대 특정 코드 블록 내부에서 무슨 자료구조를 쓰고 하는 문제보다는 캐시 레이어를 어떤 식으로 활용할지, 아니면 클러스터를 어떻게 구성할지 같은 수준의 문제가 좌우하는 경우가 있습니다.

    (자료구조가 중요하지 않다는 이야기가 아니라 앞서 언급한 마이크로 최적화에 대한 집착 같은 문제를 이야기하는 것입니다)

    디버그의 경우도 계층이 올라가면 로그 찍는 노하우 보단 해당 프로그램이 실행되는 프레임워크의 전반적인 구조를 이해하는 게 훨씬 도움이 되는 경우가 많습니다.

    아마도 C언어를 마스터하고 자바 언어를 6개월 배운 사람보다는 C언어를 전혀 모르고 자바를 5년쯤 배운 사람이 아마도 스프링 프레임워크의 API 문서나 스택트레이스는 훨씬 쉽게 파악할 수 있을 겁니다.

    언어 자체를 배우는 문제만 보아도 예컨대 고수준 함수형 언어를 배운다면 기본 지식은 운영체제나 컴파일러 같은 내용이 아니라 차라리 기본적인 수학 이론으로 보는 것이 훨씬 적합할 것입니다.

    물론 다양한 분야를 배우는 건 시야를 넓히기 위한 매우 좋은 방법이고 실제 많은 고수들은 자신의 전문 분야 이외에도 꽤 폭넓은 지식을 자랑하는 경우가 많긴 합니다.

    하지만 어떤 지식이 다른 지식의 기본이니 모든 입문자가 배워야 한다고 이야기하는 건 꽤 다른 문제입니다.

    지금 시점에서 자바나 닷넷 같은 언어의 가장 기본 지식은 객체지향이지 운영체제나 컴파일러에 대한 지식이 아니라고 봅니다. 그리고 객체지향이란 것이 C 언어만 오래하면 훨씬 쉽게 익힐 수 있을 만큼 만만한 내용도 아닙니다.

    제 생각엔 학문과 마찬가지로 프로그래밍 언어도 시간이 지날 수록 점점 전문화, 파편화 되는 것은 불가피한 것 같습니다.

    불과 십여년 전만해도 자바스크립트는 개발자라면 누구나 금방 배워서 쓸 수 있는 무엇이었습니다. 지금은 관련 기술 흐름에 무지한 사람만 그렇게 생각합니다.

    지금 시점에서 자바나 닷넷은 C++은 몰라도 C와는 특별한 접점이 없는 언어입니다. 지금에 와서 C만 제대로 할 줄 알면 자바는 쉽게 배울 수 있다고 주장하는 사람이 있다면 아마도 그건 객체지향이나 아키텍쳐, 프레임워크 같은 자바 분야의 필수 지식에 대해 무지하기 때문일 거라 생각합니다. 

    3
  • Cookies
    271
    2016-07-28 00:04:42

    글에 내용에는 전반적으로 동의하고 공감합니다.

    다만 읽으면 읽을수록 글에 제목과는 멀어지내요. 

    그리고 그 주장이 강하면 강할수록 '노오력이 부족하다'는 곤대 느낌이 납니다. 

    제목을 '인정 받는 프로그래머가 되는 법' 정도가 더 적당할 듯 합니다. 

    또 C와 OS API 만 가지고 공부하는 것에 한정하기 보다는 

    javascript로 게임 만들기, 이 okky에 올리셨지만 zepinos 님의 게시판 만들기, 

    저의 경우에는 java로 마이바티스 만들기 등으로 변환해서 제시하는것도 

    좋아 보입니다. 

    어짜피 하나의 언어를 이용해서 무언가 만들어보고 그것을 최적화 하는 과정에서 

    기초지식이라는 것을 배우고 활용하게 되는거니까요.

    그 경험이 다른 새로운 것을 배울 때도 도움이 되고요. 

    쉽다는 것은 많이 해본다는 건데.. 경험적으로 이 쉬운걸 해 본 사람이 그다지 많지 않더군요.. 

    0
  • asmpro
    722
    2016-07-28 00:09:10

    흠...

    아시다시피 한가지 언어에 정통하게 되면 다른 언어를 배우는데 걸리는 시간이 비교도 안되게 줄어듭니다.

    제가 가장 많이 사용한 프레임워크는 닷넷입니다.

    어셈블리 -> C -> C + Windows API -> Visual C++ -> Visual Basic -> .Net

    제가 주로 쓰던 언어의 변천사 입니다.

    물론 C와 C + API는 DLL 등이나 서버를 개발하는데 자주 사용했습니다.

    메인으로 사용하지 않았을 뿐이죠.


    제가 하려는 얘기는 로우레벨 프로그래밍이 프로그래밍에 대한 이해도 자체를 높인다는 겁니다.

    로그 얘기는 어떤 환경에서도 디버깅을 쉽게 하는 방법에 대해서 한 얘기입니다.

    기본이 되있으면 최악의 언어인 어셈블리에서도 쉽게 디버깅이 가능하다는 그런 의미로 쓴 글입니다.

    0
  • asmpro
    722
    2016-07-28 00:21:14

    게시판 만들기등은 이미 수많은 사람들이 얘기 했으니 대부분 얘기하지 않은 것에 대한 얘기를 썼습니다.

    그리고 알고리즘 공부하기 위해 알고리즘 사이트 가서 문제푸는 사람들 있듯이 (문제 푸는 거 외국기업 취업에 꽤 도움되는 부분이 있습니다.) 로우 레벨 프로그래밍도 공부하면 프로그래밍 전반에 도움된다는 그런 얘기입니다.


    엄청난 노력을 하라는 게 아닙니다.

    하던일 접고 그것만 하라는 것도 아니고 로우레벨로 대단한 것을 만들라는 것도 아닙니다.

    학생 때 배웠던 알고리즘 구현 직접할 수 있고 OS API로 그래픽 테트리스 정도는 어렵지 않을 정도로 만들 수 있을 정도만 되도 도움이 됩니다.

    0
  • fender
    14k
    2016-07-28 00:22:59

    @asmpro //

    하나의 언어를 배우면 다른 언어를 배우기 쉽다는 건 맞는 말씀입니다. 그런데 그건 보통 비슷한 계열의 언어일 때 통용됩니다.

    자바를 알면 C#을 쉽게 배울 수 있고, 파이선을 알면 루비를 쉽게 배울 수 있을 테고, 해스켈 같은 언어를 알면 스칼라를 좀 더 쉽게 배울 수 있기는 합니다.

    그런데 비주얼베이직을 잘하면 자바 언어를 매우 쉽게 배울 수 있다거나 C언어를 잘하면 스칼라를 대단히 빨리 배울 수 있는 건 아닙니다.

    그리고 언어를 사용할 줄 아는 것과 제대로 쓰는 건 상당히 차이가 있습니다. 어떤 블로그에서 읽고 인상깊었던 표현인데, 개발 언어도 자연 언어와 같은 '액센트'가 존재한다는 이야기가 있습니다.

    즉, 어떤 언어를 장기간 사용하다 보면 해당 언어 고유의 접근 방식이 몸에 베어  다른 언어를 사용할 때도, 마치 외국인의 한국어 발음 처럼 이질적인 습관으로 드러나는 경우가 있다는 뜻입니다.

    앞서 말한 개인적으로 경험한 C 경험만 많고 자바 경험이 부족한 분들이 작성한 자바 코드가 그런 경우입니다. 그 분들도 대체로 '자바를 잘 안다'라고 이야기했지만 실제 코드를 보면 객체 지향적인 설계보다는 절차지향적 함수 단위 프로그램을 선호하고, 이미 존재하는 라이브러리나 프레임워크를 배우기 보단 어떻게든 나름대로 만들어 쓰는 데 시간을 낭비하는 성향도 보였습니다.

    그리고 디버깅에 있어서도 IDE나 프로파일러를 활용하기 보단 로그를 찍는 접근을 선호하고 성능 문제에서도 구조적인 해결책을 찾기보단 지엽적인 코드 최적화에 집착하는 경우도 꽤 있었습니다.

    물론 이런 문제들은 모든 개발자에 대해 일반화 할 수 있는 것은 아닙니다만, 최소한 C언어에서 자바로 넘어올 경우 이런 유형의 문제를 겪을 가능성은 상당하다고 할 수 있을 정도로 두 가지 언어의 기본적인 접근 방법은 매우 다릅니다.

    단지 문법을 알고 검색해서 어떻게든 잘 돌아가는 프로그램을 만드는 정도라면 저도 아마 사람들이 이야기하는 어지간한 언어들은 다 짤 수 있다고 주장할 수 있을 것 같습니다.

    하지만 실제 해당 언어를 그 언어를 주력으로 공부한 개발자와 비슷한 수준으로 배우는 건 완전히 다른 문제이고, 특히 특정 언어를 익히겠다고 그 언어와 접근 방법이 완전히 상이한 언어를 우선 배우는 건 시간낭비라고 봅니다.

    2
  • asmpro
    722
    2016-07-28 00:32:26

    흠...

    혹시 학원 출신과 카대, 외국 컴공 출신 본적 있으신가요?

    한마디로 기초가 많이 깔려 있을수록 배우는 속도자체가 아예 비교가 안됩니다.

    배우는 속도가 비교가 안되는데다 발전할 수 있는 한계 또한 비교가 안됩니다.

    그리고 C언어를 쭉 쓰다 자바를 쓰면 당연히 적응하는 시간이 필요합니다.

    C언어를 쓰던 사람이 어느 정도의 프로그래밍 전반에 대한 이해가 있는지에 따라 자바에 잘 다루는데 걸리는 시간도 달라지겠죠.

    자바 쓰던 사람이 C쓰는 것보다는 적응하는 게 빠를 거라 생각합니다.


    계속 오해하시는 것 같은데 저는 컴공과에서 이런 저런 과목들 쭉 공부하듯이 로우레벨 프로그래밍을 공부하면 좋다는 겁니다.

    저는 로우레벨 프로그래밍으로 시작해서 그걸로 톡톡히 덕을 봤지만 저처럼 하라는 얘기가 아니예요.


    맨위에 첫글 부터가 학습 용도로 하라고 했지 주언어로 쓰라고 하지를 않았습니다.

    중간에도 끊임없이 얘기했구요.


    아까부터 계속 제가 로우레벨 프로그래밍만 죽어라 파라고 얘기한것 처럼 얘기를 하십니까?

    그리고 언어의 이해도에 따하 무조건 절차지향형 언어를 사용했다고 객체지향형 언어를 제대로 사용 못하는게 아닙니다.

    0
  • 즈루시
    12k
    2016-07-28 00:37:30

    30년전부터 코딩을 하셨다니 대단하시네요

    내용 자체는 공감합니다 소켓 프로그래밍만 하더라도 요즘 라이브러리로 코딩하지 옛날처럼 로우레벨로 처리하진 않으니까요

    로우레벨 수준의 지식이 있다면 좀 더 이해하기 쉽고 응용하기 쉬워집니다

    단 자바 하나만 놓고 보자면 공감받기 힘든 공부법이 아닌가 싶네요... 자바 API가 만능도 아닐뿐더러 이미 훌륭한 알고리즘 / 로직이 있는데 혼자 삽질하는 시간은 꽤나 비생산적이지 않나 싶습니다 

    0
  • asmpro
    722
    2016-07-28 00:46:46

    아무래도 말이 헛도는게 자바, 닷넷 다루는 분들한테 공감이 안가서 그런 것 같습니다.

    C + OS API 프로그래밍 하라는 건 그걸 통해 알고리즘 트레이닝과 OS가 어떤 식으로 작동하는지를 파악하라는 의미입니다.

    라이브러리가 없을 경우 어떻게 해야할지도 익히구요.

    컴공과에 컴파일러, 공룡책, 어셈블리 등 밖에서 안써먹는 과목이 있는 이유와 비슷한 겁니다.

    그리고 모든 사람이 자바, 닷넷만 다루는 게 아니지 않습니까?

    윈도우, 리눅스 데스크탑 프로그래머에게는 무조건 도움이 됩니다.

    0
  • fender
    14k
    2016-07-28 00:59:24

    @asmpro //

    제 이야기의 핵심이 바로 분야마다 '기초'에 해당하는 내용이 다르다는 것입니다.

    당연히 임베디드나 시스템 프로그램을 주력으로 한다면 C언어는 필수지식이 될테고, 윈도우즈나 리눅스 기반 커맨드 응용프로그램을 만든다면 사용하는 기술이나 프로그램 성격에 따라 도움이 되는 경우가 있겠죠. 하지만 그게 파이선이나 스칼라를 배우는 데도 기본 지식이라 할 수 있을까요?

    전 모든 사람이 자바 닷넷만 다룬다는 이야기를 한 적이 없고 C나 컴파일러 지식이 기초가 되는 분야가 없다고 이야기한 적이 없습니다.

    반대로 분야에 따라선 그런 지식이 큰 도움이 되지 않는 경우가 있고, 그런 경우 전혀 다른 성격의 지식이 '기초 소양'으로 간주된다는 이야기를 하고 있는 것 뿐입니다.

    자바나 닷넷 같은 언어를 배워서 엔터프라이즈 개발자가 되려한다면 포인터나 컴파일러 같은 걸 공부하느라 몇 개월을 소비하는 것 보다는 그 시간에 객체 지향부터 제대로 공부하는 게 우선이고, 지금은 그런 분야만 십 년을 넘게 해도 기술 동향 따라가는 것도 벅찰 만큼 이미 전문화, 파편화가 진행될 만큼 진행된 상황이라는 말씀을 드리고 싶었습니다.

    1
  • asmpro
    722
    2016-07-28 01:10:57

    기본 지식이 아니라 익히는 속도를 증가시킨다는 개념으로 한 말입니다.

    학교에도 똑같이 입학해서 1년 뒤에 비슷한 시간 투자했는데 훨씬 프로그래밍을 잘하는 학생이 있는가 반면에 진도 쫓아가기에 벅차하는 학생이 있을 겁니다.

    0
  • fender
    14k
    2016-07-28 01:12:48

    제 경험상 그런 건 컴파일러 구조에 대한 지식 같은 내용 보단 추상화 능력이나 문제해결을 위한 체계적 접근 방법 같은 부분에서 갈리는 것이고, 이는 C가 아니라 어느 언어를 배워도 익힐 수 있습니다.

    0
  • 리액트_어셈블러
    171
    2016-07-28 01:20:06

    알아두면좋다(공감)

    경험상 우선순위 및 효과(사람마다 다르다)

    시간= 놀시간도 없다.

    적당히 자기한테 맞는방법으로 하면

    좋을듯 합니다. 저는 짬날때 객체지향 및

    업무에 필요한 공부요소(웹단) vs

    어셈블리컴파일 중 흥미가 더 가는

    공부는 어셈블리컴파일입니다.

    어쨋든 둘다 잘하고싶네요(의지,시간부족)

    0
  • asmpro
    722
    2016-07-28 01:39:38

    제가 누구나 다 하면 좋다고 하기 보다는 데스크탑 프로그래머에게 좋다는 식으로 썼었어야 되는 글이 맞는 것 같습니다.

    단지 제가 위와 같은 글을 쓴 이유는 저는 어셈블리로 프로그래밍을 했고 일은 객체지향으로 프로그래밍을 가장 많이 했지만 언어가 발달하면서 언어를 넘어갈 때 어렵지 않게 넘어갔습니다.

    전공이 컴공이 아니고 단 한번도 교육과정을 겪어본 적이 없는 제가 어셈블리로 시작해서 .Net을 사용하는데 문제가 없었던 가장 큰 이유가 어셈블리로 프로그래밍의 이해도를 넓혔기 때문이라고 생각했습니다.

    실제로 극단적으로 느린 CPU와 적은 메모리에서 어셈블리로 프로그래밍을 한 덕분에 온갖 방법을 다 써보다 보니 새로운 언어를 익히거나 문제 해결에 있어서 타 프로그래머 보다 월등히 유리했구요.

    살면서 사수가 존재하지 않았고 제가 해결 못하면 그게 끝인 식으로 프로그래밍을 해왔기에 아무래도 어셈블리에 대해 과도하게 남들에게 얘기했던 것 같습니다.


    아무래도 그냥 말만 많은 떠벌이로 생각하는 분이 있을까봐 제 블로그 링크를 남깁니다.

    http://blog.naver.com/asmpro


    현재 진행중인 개인 프로젝트는 닷넷과 유사한 문법의 어셈블리 프로그래밍 언어 개발입니다.

    배포수준까지는 진행되지 않았지만 일단 FastASM으로 개발한 테트리스 소스와 실행파일은 올려놓은 상태입니다.

    특징은 닷넷의 문법을 일부분 차용했고 속도와 성능은 어셈블리로 개발한 것에 거의 흡사하다는 겁니다.

    테트리스를 100% 어셈블리로 개발한 것이 10KB이고 FastASM으로 개발한것도 10KB입니다.

    변수, 함수 상속이 가능한 클래스를 지원하며 Rust와 같이 비용없는 추상화로 상속 비용이 없습니다.

    FastASM은 아직 완전한 컴파일러의 형태를 띄고 있지 않아 Hybrid라고 완전히 컴파일러 형식으로 넘어가려고 준비중입니다.

    현재 비용없이 오버로딩, 오버라이딩을 구현하는 것등 몇가지를 더 지원하고 완전히 컴파일러로 갈 생각입니다.


    이런거 왜 만드냐고 할 수도 있는데 sourceforge와 github에 있는 오픈 소스 생각하면 제가 왜 이런 거 만드는지 이해가 될거라 생각합니다.

    1
  • asmpro
    722
    2016-07-28 01:54:36

    공감 받기 힘든 글을 썼으니 그에 따른 반작용으로 댓글들이 달린건데 제가 제 생각에 너무 취해 있었네요.


    이글은 삭제하고 싶지만 반성하는 의미로 그냥 놔두겠습니다.

    0
  • fender
    14k
    2016-07-28 07:23:20

    asmpro님이 실력이 없을 것이라거나 하시는 일이 의미없을 것이라고 생각한 적은 없습니다.

    첫 덧글에서 말씀드렸듯이 전 본문 내용 중 일부를 제외한 내용에는 적극 공감하는 편이고, 그렇지 못한 부분에 대해서도 생각은 모두 다를 수 있으니 단지 모두에게 공감 받지 못하다는 자체로 사과하실 필요는 없다고 생각합니다.

    토론 과정 중에 막판에 다소 비슷한 이야기가 반복된 감은 있지만, 적어도 이 곳에서 흔히 볼 수 없는 주제에 대한 흥미로운 대화였다고 생각합니다.

    앞으로도 asmpro님의 글을 자주 접할 수 있었으면 좋겠고, 하시는 프로젝트도 잘 진행하시길 바라겠습니다.

    2
  • unthinkall
    1k
    2016-07-28 07:57:29

    저는 도스에서 C언어와 C++을 공부했었습니다

    인터넷도 없고 다만 하이텔이 있었고 대부분의 공부는 서적에 의존했고 printf 함수가 느리다고 해서 어셈블리코드로 짜서 속도를 빠르게 하고 게임을 만들때도 메모리 관리나 대부분의 함수를 직접만들어 썼었죠 

    그때와 비교하면 지금은 상전벽해 수준입니다.

    컴공에서 OS 컴파일 컴퓨터 구조 알고리즘 네트워크 배워서 나왔지만 현재의 소프트웨어 업계를 보면 예전과는 달리 패러다임도 많이 바뀌었고 무엇보다 가장 중요한 것은 분업화 전문화가 잘되어있고 계층또한 매우 두터워졌습니다

    이런 전반적인 부분들을 모두 경험해보면 현재는 특수한 분야말고는 아키텍트나 프레임워크 객체지향 패러다임 훈련에 집중하는 것이 더 중요해 보입니다

    개발언어는 도구인지라 필요하면 공부하는 것이고 굳이 필요가 없는데 공부하는건 시간낭비일수도 있습니다 

    우리는 한정된 시간과 자원속에 살고있는 현실적인 존재이기 때문에 자신의 위치에서 필요한 것을 집중적으로 공부하고 필요하지 않은건 과감히 다른 사람에게 맡기거나 쳐내는게 중요하다고 생각합니다


    0
  • kkey21a
    3k
    2016-07-28 09:07:48

    전 asmpro 님의 의견에 충분히 공감이 갑니다.


     다만, 모든 개발자들은 모든 것들을 다 로우레벨로 개발해봐야 된다는 것은 아닙니다. 개발자의 선택에 따라 혹은 경우에 따라 특정 프로그램은 로우레벨로 개발해 보는 것도 본인에게는 도움이 된다고 생각합니다. 그동안 그냥 사용만해서 그 라이브러리에 대해 자세히 알지 못했던 내용이나 그 라이브러리에 적용한 알고리즘을 좀 더  이해하고 사용함에 있어 더 많은 도움이 될 수 있다고 생각해서 입니다.

    물론 어떤 프로그램을 만들어야 할 일이 있는데 그에 필요한 라이브러리가 있는데도 불구하고 그 라이브러리를 사용하지 않고 그 부분을 제가 직접 로우레벨로 개발하겠다는 말도 아니고 이제 갓 프로그래밍을 시작하는학생들을 대상으로 하는 말도 아닙니다. 어느정도 일정수준의 개발을 할 수 있다는 전제하라면 본인의 선택에 따라 한번쯤은 로우레벨로 작성해보는 것도 괜찮을 것 같다라는 말이며, asmpro님도 위와 같은 맥락에서 얘기하신게 아닐까 합니다.

    0
  • kon
    1k
    2016-07-28 09:09:23
    좋은 내용과 좋은 댓글들 모고 갑니다. 좋은 글 써 주셔서 감사합니다. ^^
    0
  • 하마
    6k
    2016-07-28 09:09:29

    손으로 땅을 파다보면  땅에 대해 많은걸 느낄 수도 있습니다.
    삽질 하다보면 나름의 노하우를 가질 수있겠지요.

    근데 포크레인기사라면 일 하다 여유있을 때 기계정비,기계조작연습,더 좋은 방식의 땅파기 기술 조사, 공사현장의 전기줄, 수도관매설 여부 같은 현장 지하분석을 해야지  땅에 엎드려 손으로 땅을 파 보라고 하거나 지질학 공부 하라고 하면 공감받기 힘들겠죠. 


    그래서

    굳이 어셈블리를 강조해서 언급하기 보다 그냥

    뿌리기술을 알면 가지기술들에 접근하는데 유리하다라든지, 알고리즘 자료구조 공부를 아무언어로 틈틈히 공부하자 라고만 했으면 본문글 초반부의 좋은 덕목과 함께 공감이 많이 되지 않았을까 합니다.

    참고로 데스크탑솔루션에서도 어셈블리는  필요없습니다.메모리 덤프분석시 도움되긴 하지만 (진짜 어려운 쓰레드 동시성에 의한 버그는 덤프분석 효과도 그닥) 거의 대부분의 개발자에겐 우선순위로 공부해야 할 것들이 훨씬 많습니다.


    1
  • de
    2016-07-28 09:42:17

    좋은내용 댓글 잘 읽어 봤습니다. 

    이제 30살이고 만4년 정도 개발자입니다. 제한된 시간을 가지고 있다고 하면 저도 어셈블리쪽보단 공부해야될 다른 분야들이 참 많은것 같습니다.

    선택과 집중이 이런데 쓰여도 될런가요.

    도움이 아예 안되진 않겠지만 어떤 분야 개발을 하냐에 따라 필요한 배경지식이 다르다고 봅니다.

    0
  • 근원으로
    348
    2016-07-28 09:50:16

    저도 개인적으로 asmpro님 의견에 매우 공감합니다.

    저 또한 그렇게 공부하려고 학부시절부터 지금까지 노력하고 있고요(요즘은 좀 게으릅니다...)

    학부 시절에 "해킹 파괴의 광학"이란 책을 본적이 있는데 아직까지 기억에 남는 내용 중 하나가

    모든 기술은 뿌리가 있고 근원을 알게 되면 뿌리에서 파생된 하위 기술은 쉽게 접근이 가능하다는

    내용이 었습니다. 전적으로 이말에 공감하고 제 프로그래밍 철학(?)이기도 하구요 ^^

    실제로 뿌리 기술을 습득한 상태에서 파생 기술을 습득하긴 쉽지만, 반대는 훨씬 어렵습니다.

    하지만 현실은 이 모든 것들을 해나가며 살기가 녹록하지 않고, 몇몇분의 말씀처럼 요즘 프레임워크가

    워낙 잘되어 있다보니, 이런 근원적이고 세세한 것 보다는 좀더 추상적이고 큰 영역에(설계 등) 힘을

    쏟는 것이 실질적으로 도움이 되는 경우가 많은 것도 사실입니다.


    어떤 부분을 중요시 할지는 개인의 선택이고 어느 것을 선택하든 좋다고 생각합니다.

    개인적으로는 학생 신분이라면 근원 공부를 현업이라면 본인의 전문 분야 공부에 우선순위를 두는게

    현실적이라고 보여지네요.

    1
  • 북삼촌사람
    953
    2016-07-28 09:59:55

    좋은 글, 좋은 의견들을 잘보고 갑니다.

    한가지 방식 맞다는 말보다는 여러가지 방식이 있다고 생각합니다.


    분야에 따라서 공부하는 방식 또는 해야하는 공부가 틀리다고 생각하고, 

    한 가지만 정통하면 되는 시대가 아니라, 상세하게 공부해야하는 시대라고 생각합니다.

    0
  • samchon
    380
    2016-07-28 10:18:33

    C로 표준 라이브러리도 사용하지 말고 C 기본 문법에 OS API만 사용하는 것이죠.

    -------------

    역으로 표준 라이브러리를 직접 만들어보는 것도 도움이 됩니다.

    본인은 TypeScript (JavaScript) 를 사용하면서, 표준 라이브러리 및 컨테이너의 필요성을 절감하여 STL을 직접 구현한 적이 있는데, 알고리즘을 깊게 이해하고 활용력을 기르는 데 큰 도움이 되었습니다.

    https://github.com/samchon/typescript-stl

    0
  • samchon
    380
    2016-07-28 10:23:12

    다만, 상수나 문자열을 과하게 코드화(enumeration, static 등)시켜 사용하는 것은, 가독성을 해치기 때문에, 지양해야 합니다. 가령 XML 파서를 만드는 데 있어, 빈번하게 사용되는 문자열을 아래처럼 코드화시켜 사용하는 코드가 있다면, 그처럼 끔찍한 코드도 없을 테니까요

    • "<" 대신 LEFT_OPENED_PARENTHESIS
    • "/>" 대신 RIGHT_CLOSED_PARENTHESIS
    0
  • zepinos
    19k
    2016-07-28 10:44:11

    어제 글을 보고도 글을 적을 수 없는 상황이어서 이제야 저도 제 의견을 피력해 볼 수 있겠네요.


    먼저, 저수준의 언어를 다뤄보는 것은 분명 도움이 됩니다. C/C++ 하는 사람들이 Java 을 가소롭게(?) 생각하는 경향이 있는데, 어셈블리를 하는 사람들이 그런 생각을 가지지 않겠지만, 분명 Java 로서는 접근 차제가 안되기 때문에 생각조차 할 수 없는 것들을 다뤄보기 때문에 사고의 확장에는 분명 도움이 된다고 생각합니다. 저 역시 어셈블리는 대학교 이전부터 어느 정도 알고 있는 상태였고, 수업도 들었지만...다른 언어를 이미 깨우친 이후라 그런지 크게 감흥은 없었습니다만, 그렇다고 다른 사람들에게 도움이 되지 않는다라고 생각하지 않습니다.


    하지만, 언어를 배울 때 도움이 될지언정...그건 어셈블리가 아니라 다른 언어를 배워도 타 언어로 넘어갈 때 도움이 된다는 건 변함이 없다고 봅니다. 웹 스크립트 언어 하나를 어느 정도 숙달하게 되면 다른 웹 위주로 많이 쓰는 언어로 넘어갈 때 도움이 될 것이고, 함수형 언어를 배웠으면 다른 함수형 언어를 배우는데 도움이 될 것입니다. 하지만, 위에서도 잠깐 나왔듯이 절자지향 위주의 언어를 배운 사람이 갑자기 함수형 언어를 배운다고 해도 언어 자체의 컨셉에 맞는 결과물이 나오는데 큰 도움이 된다고는 생각하기 힘드네요.


    그리고, 이 글이 특히나 여기서 환영 받음에도 불구하고 우려 섞인 내용이 나오는 이유는...여기 오시는 분들 상당수가 주로 웹 페이지 개발을 하시고, 특히나 웹이라고 하는 환경을 통해 발전된 개발 패러다임이 이 글의 내용과 어울리지 않기 때문이라고 생각합니다.



    하나의 예를 먼저 들어보겠습니다.

    예전에 웹을 개발할 때 가장 강력한 언어가 perl 이었던 시절이 있었습니다. 제 기억이 맞다면 90년대 중후반 쯤 되겠네요. 그 때에는 방명록이나 게시판을 만들면 모든 내용을 텍스트 파일에 썼습니다. (한줄) 방명록의 경우 새로운 글이 입력되면 기존 내용을 한 줄 밀치고 제일 상단에 한 줄 입력하고, 첫 페이지에는 readLine 10 번이나 read 후 \n 을 10 번 만날 때까지 계속 buffer 에 담아서 그걸 출력하는 형태로 구현했고, 게시판은 한 게시물마다 하나의 파일을 생성하곤 했습니다. 개발자가 perl 이라는 언어를 통해 모든걸 구현했던 시절이었죠.

    지금 이렇게 구현하는 분 계신가요? 설령 모바일이라고 해도 sqlite 쓰지 저렇게 파일로 쓰는걸 선호하는 개발자는 드뭅니다. 특히나 고수준의 언어에 익숙하거나 RDBMS 에 익숙한 사람일수록, 심지어 new File() 이라는 Java 의 기본 파일 개체도 안써본 초급 Java 개발자도 많이 봤습니다. 그래도 개발을 다 하죠. 대신에, 어셈블리나 C/C++ 같은 언어를 배워도 거의 도움이 되지 않는 SQL 을 배워야 합니다. SQL 을 쓰다 보면 알겠지만, 하나의 개체, 하나의 변수 단위로 생각하는 건 크게 도움이 되지 않습니다. 데이터 덩어리를 기준으로 조합하는게 기본 사상이기 때문이죠.

    HTML 은 어떤가요? CSS 는? 이런 웹 개발 위주로 많이 쓰는 분들에게 어셈블리는 반드시 도움이 된다고 하면...사실 이건 어폐가 있는 말입니다.


    또다른 예를 들어보겠습니다. 불과 며칠 전에 제가 겪은 일입니다.

    Netty 기반으로 채팅 서버를 구현했습니다. 클러스터를 어설프게 구현해서 두 개 이상의 서버에 설치한 뒤 설정만 하면 각 서버의 채팅 서버는 모두 Master 가 되는, Master-Master 형태의 구성입니다. 소켓 기반인데, 소켓은 서버당 최대 포트 수(2^16...보다 조금 적겠죠) 밖에 못받기 때문에, 동시접속자가 훨씬 많을 것 같은 이번에 사용할 곳에서는 부득이하게 서버가 2대 이상이 필요한 상황이었고, 제가 M-M 기반을 선호해서 이렇게 만들었습니다. 그리고, 당연히 FailOver 등도 감안해야 하고 서버가 언제 증설될지도 모르기 때문에 L4 의 힘을 빌리기로 했습니다.

    그런데, 저는 기본적으로 L4 를...(정식용어는 모르지만) NAT 모드 혹은 Source NAT, 그 중에서도 Full NAT 라고 불리우는 형태의 제품만 써봤었습니다. 사족을 먼저 길게 적자면...

    이 방식은 사용자의 요청이 L4 로 오면, L4 는 패킷을 열어서 사용자의 IP(Source IP 라고 합니다)을 L4 의 IP 로 바꾼 뒤 자신의 저장공간에 해당 패킷의 사용자 IP 을 따로 저장을 해주고, 자신이 분배해야 할 서버 목록(흔히 Group 이라고 부릅니다)에서 서버를 하나 선정해서(이 때 대상 IP 도 서버 IP 로 바꿔주겠죠) 패킷을 전달합니다. 그럼 실제 처리할 서버는 내용을 처리한 뒤에 Source IP 가 목적지가 되도록 내용을 전달하기 때문에 L4 가 다시 이 결과를 받게 됩니다. 다시 L4 는 패킷 내용에서 목적지 IP 을 사용자의 IP 로 바꾼 뒤 전달을 하는 형태가 됩니다.
    이 형태에서 Group 에 속한 서버는 그냥 아무런 설정도 할 필요가 없습니다. 그냥 한 대 있던 것과 동일한 구성으로 놔두면 L4 가 알아서 처리를 하죠. 이 때에도 lo:0 을 만든다고 해도, eth0 를 통해서 메세지를 전송해도 목적지가 L4 이기 때문에 데이터 자체는 내부에서 이동하게 되는 것이기 때문에 장애는 없을 것입니다.

    하지만, 이번에 제가 만든 프로그램을 쓰는 곳에서 설치한 L4 는 DSR 모드로 동작하는 곳이었습니다. 저는 써본 적이 없는 형태라 이게 뭔지도 모르고 있었고, 이 모드로 동작한다고 알려준 바도 없었기 때문에 아무런 준비도 하지 않은 상태였습니다. 역시나 사족을 먼저 길게 적자면...

    이 방식은 NAT 모드와 달리 패킷을 열어서 Source IP 을 바꾸지 않고 목적지 MAC Address 만 바꾸고 그냥 그대로 Group 내 서버에 바로 패킷 내용을 전송합니다. 대신에, 서버에서 통신을 위한 Ethernet 카드(OS 차원에서는 Interface, 랜카드를 인식한 이름, 리눅스에서 흔히 말하는 eth0 같은...이후 인터페이스라고 하겠습니다)에 가상의 인터페이스를 하나 만듭니다. lo:0 와 같이요. 이름은 lo 지만, 실제로는 eth0 위에 가상으로 생성되고, 이 lo:0 는 L4 와 같은 IP 을 가지게 됩니다. 즉, 모든 서버가 lo:0 는 L4 와 동일한 주소를 가지고 생성이 되는거죠. 이 곳으로 L4 는 데이터를 전송하게 되고, 서버는 이 데이터를 Netty 에 전달하면 데이터를 처리해서 다시 사용자에게 보내는데...이 때 Source IP 는 여전히 사용자의 IP 가 유지되어 있기 때문에 L4 을 거치지 않고 바로 사용자에게 응답이 되어서 부하가 훨씬 줄어들게 됩니다. (물론 NAT 모드에도 Half-NAT 라고 중간 쯤 되는 방식도 존재합니다. 대상 IP 만 바뀌고 Source IP 는 안바꿉니다)

    문제는, 이 DSR 모드로 설정을 해놓곤, eth0 는 외부 통신이 차단된 Private 영역의 IP 이고, lo:0 에 설정된 정보를 통해서 나갈 때에만 데이터가 외부로 나간다는 것이었습니다. 그런데, Netty 는 0.0.0.0:포트 형태로 binding 되어 있다가(즉, 지정된 포트이기만 하면 여러 인터페이스에서 오는 모든 정보를 다 수신) 결과를 보내줄 때 처음 수신된 인터페이스가 아닌 기본(Default) 인터페이스로 응답을 해버린다는 것이었습니다. 저도 이건 몰랐습니다. -_-;;;

    그래서, Netty 가 응답은 하는데...데이터는 차단이 되어서 망망대해에 빠지게 되는 것이었죠.

    해결 방법은, 강제로 Netty 가 lo:0 의 IP 을 binding 해서 시동을 하면, lo:0 로 응답을 하게 되는 것이었습니다.

    그런데, 문제가 또 생겼습니다. 이 L4 가 서버의 프로그램이 살았나 죽었나 계속 확인을 하는데, 이건 또 eth0 에 설정된 내부 IP 을 통해서 한다고 합니다. 당연히 lo:0 에 강제 binding 을 했으니 eth0 의 신호는 무시...L4 에서 이 서버는 죽었다고 판단하고 Group 에서 live 상태가 아닌 dead 상태라고 표시를 해서...서버들이 다 죽은 상태여서 응답 자체를 못받게 되는 현상이 발생되었습니다.

    해결은...L4 에서 다른 방식의 우회를 통해 살아있음을 체크하는 것으로 했다고 하더라구요. 이건 시스템 엔지니어들이 처리한 것이라 어떻게 했는지는 저는 잘 모릅니다.

    이렇게 긴 이야기를 적게 된 것은...이 문제를 어떻게 해결했냐는 절차가 이 이야기와 관련이 있기 때문입니다. 당연히 프로그래머라면 Netty 을 뜯어고쳐서 lo:0 에서 온 정보는 ctx.write(Netty 써보신 분은 무슨 의미인지 아실 겁니다) 할 때 lo:0 로 보내게 해야지, 혹은 binding 될 때 0.0.0.0:포트 형태가 아니라, 시스템의 모든 인터페이스에 각각 (아이피):포트 형태로 binding 되도록 개선해야지...할 것입니다.

    하지만, 그럴 시간이 없고, 그렇게 하지 않더라도 다른 지식이 있고 다른 전문가들이 있기 때문에 다른 방식으로 문제 해결을 할 수 있다는 것입니다.


    제가 처음 프로그래밍을 접한 꼬꼬마 시절이 지금으로부터 정확히 32년전입니다. 그 때라면 컴퓨터 안에서 다 하고 여러 시스템이나 미들웨어 등을 거치지 않고 독자적으로 움직이던 시절입니다. 하지만 지금은 아니죠. 다른 이기종 시스템과의 통신을 하는데 누가 소켓 프로그램 일일이 작성하고 날릴 패킷을 정의하고 그럽니까...미들웨어 쓰고, Thrift 나 Prototype 같은 걸로 바로 정의해서 쓰죠. 물론 이게 직접 구현하는 것보단 성능이 떨어집니다. 범용적인 것을 추구하다 보니 그런거죠. 하지만, 직접 짠 프로그램의 무결성은 누가 검증해주고 누가 개선해주고, 상황에 따른 변인을 모두 충족할 수 있다고 자신할 수 있는 사람이 누가 있을까요?


    얼마 전에도 제가 여기 남긴 내용 중에, Sort 을 구현하는 알고리즘을 입사 때 물어보는건 무의미하다고 한 적이 있습니다. 그냥 "with test (select 데이터 from dual union all select 데이터 from dual union all ...) select * from test order by 정렬" 같이 하면 알아서 잘 해줍니다...혹은 TreeSet 에 넣으면 알아서 잘 해줍니다...라고 하면 안되냐구요. 실제 자바의 내부 정렬 알고리즘은 Quick Sort 가 아닙니다. 퀵소트가 항상 빠르지 않기 때문인건 누구나 알고 계실 꺼구요. 그럼 본인이 개발해야할 어떤 프로그램에서 어떤 상황에서 어떤 정렬 알고리즘(혹은 본인이 개발한 정렬 알고르즘) 쓸지 코드로 완벽하게 판별해낼 수 있게 구현할 수 있을까요? 그럼 그 시간은요? 이 쯤 되면 개발이 단순 취미가 아니라 직업이 되고...직업이 되면 개발 효율과 비용 등을 고려 안할 수 없게 되기 때문에...언어의 깊이 보다는, 결과물을 어느 정도 신뢰할 수 있게 빨리 만들어낼 수 있는, 양질의 라이브러리나 미들웨어, 좋은 서버, 서버 구성 설계 능력 등이 더 요구될 수 있습니다.




    당연히 프로그램의 기본이 되는 언어학 자체의 깊은 이해도는 중요합니다. 그리고 생각보다 그게 시간이 안들 수도 있습니다. 하지만, 지금 당장 취업이 급한 사람들에게...그런 얘기 해줘봐야 별로 안통한다는게 사실입니다. 제가 왜 사파의 방식이라고 언급까지 하면서 단순한 코드(게시판)를 반복해서 만드는 학습을 해보라고 권했을까요...

    이게 바로 이 글이 추천받으면서도 우려의 이야기가 나오는 이유라고 생각합니다.


    이 글은 분명 좋습니다. 하지만, 어셈블리로 처음 공부해야하나...라는 생각을 가지시는 건 대학교에서 공부하는 분들에게 권할 방법이지, 일단 어떻게 취업해서 회사 업무에 바로 들어갔는데 머리 속이 하얘진 사람들에겐 별나라 이야기라는 걸 굳이 밝히고 싶네요. 거듭 말씀드리지만, 글이 나빠서, 전하고자 하는 내용이 잘못되어서가 아니라...현실이 반드시 그렇지 않기 때문입니다. 어셈블리부터 공부를 해야하는 산업분야가 있기 때문에 이글이 정말 바이블이 되는 사람들도 있지만, 그렇지 않은 분야가 더 많은게 현재 우리나라 프로그래밍 업계의 현실이거든요.

    3
  • 하마
    6k
    2016-07-28 11:08:50

     zepinos 님 이거 

    소켓 기반인데, 소켓은 서버당 최대 포트 수(2^16...보다 조금 적겠죠) 밖에 못받기 때문에, 동시접속자가 훨씬 많을 것 같은 이번에 사용할 곳에서는 


    즉 글의 맥락상  포트수가 아니라 동시접속자를 말씀하시는거라 보여지는데 , 하나의 포트와 연결되는 소켓수는 제한이 없을 겁니다. 보통 '64K' limit 로 알려졌지만  OS 정책에 따라서 달라지는 부분이라 ,  socket descriptor 를 무한대로 해놓으면 메모리의 크기에 따라서 한대의 서버가 받을 수 있는 동시접속자의 수가 달라지게 됩니다. (즉 최대접속자수는  메모리에만 영향을 받는것으로 알고 있음. 하나 서버에 백만명,천만명도 가능함. 하지만 성능문제 때문에 다른 요소가 개입됨. AWS 키네시스나 IoT 서비스 경우는 확장한다고 알고 있음)  

    실제 대규모 게임서버같은걸 만들어 보지 못해서 실제와는 차이가 있는 부분이 있을지도 모르겠습니다만 , 대국민용 always connected 센서데이터수집서버를 구상하면서 알아본 결과로는 그렇게 알고 있습니다.  이 댓글 보는분들 중  오류가 있으면 바로 잡아주시길..


    관심있는 분들을 위한 관련 링크 )

    C10k problem
    Scaling to 12 Million Concurrent Connections: How MigratoryData Did It

    IBM® MessageSight

    AWS Kinesis 및 AWS IoT


    0
  • zepinos
    19k
    2016-07-28 11:15:50

    하마 님 // 지적해주신 부분은 저의 오류입니다. 저의 머리 속이 혼동이 되어서 M-M 기반 서버를 만드는 목적 자체에 엉뚱한 이유가 붙어 버렸네요. 이부분은 오류이긴 하지만, 본문에는 그냥 두겠습니다.

    Netty 의 경우 서버 소켓이 바인드한 포트를 로컬 포트로 사용하므로 제한이 없습니다.


    0
  • muttinaong1
    2016-07-28 11:36:09

    솔직히 기본기 없어도 프로그래밍 잘만하고 일하는데 지장없습니다.

    그래도 기본기 튼튼하게 쌓은 사람들이 기본기 기본기 그러는 건 

    실제 자기가 체험하고 좋으니까 남들도 알려주고 싶은 심리인거죠. 


    진짜 좋습니다. 물론 기본기 시간 많이 잡아먹습니다. 

    하지만 그 들이는 시간의 몇배의 효율로 돌아오는게 기본기입니다.

    (그리고 무엇보다도 커뮤니케이션과 취업시에 유리함. )


    0
  • fender
    14k
    2016-07-28 11:51:03

    기본기는 어느 분야를 해도 무척 중요합니다. 어떤 분야를 배우는 데 어떤 종류의 기본기를 익힐 것이냐의 문제가 아닐까 싶습니다.

    컴퓨터 공학과에서 운영체제나 컴파일러 이론 등을 기본기로 가르치는 것은 그것이 모든 개발 분야의 기본이라서 라기 보다는 그런 과목들이 그런 교육과정이 생겨났던 시점의 기술 환경을 반영한 결과이기 때문이라고 생각합니다.

    컴퓨터 공학과의 존재 이유가 실무에 당장 써먹을 개발자를 양성하는 것인가에 대한 근본적인 의문은 잠깐 접어두고 말하자면, 보통 학교에서 가르치는 커리큘럼과 해당 시점의 기술 동향 사이에는 적어도 십 년 이상의 시차가 존재합니다.

    실제로 미국의 여러 대학의 커리큘럼도 기술 동향을 반영해서 자바 중심의 교육과정을 채택하기 시작하고 또 그것이 보편화되는 과정에서 비판의 목소리가 나오기 시작한 건 상대적으로 최근의 일입니다.

    아마도 십 년 쯤 더 지나면 클라우드 컴퓨팅 같이 현 시점에 각광 받는 기술들이 대학 교육과정에 적극 반영되기 시작할 가능성이 높습니다.

    그런 시차가 존재하는 것은 아마도 대학 교수들이나 교재를 집필하는 사람들이 동시대의 관련 분야에서 일하는 현업 개발자가 아니기 때문일 것입니다.

    그것이 바람직한 일이건 아니건 간에, 따라서 그런 시차로 인한 현장에서 사용하는 기술과 학교에서 가르치는 기술 간의 괴리를 반드시 전자는 후자가 전자의 기본이 되는 선행 지식으로 이해할 이유는 없다고 생각합니다.


    1
  • zepinos
    19k
    2016-07-28 11:53:29

    그런 시차가 존재하는 것은 아마도 대학 교수들이나 교재를 집필하는 사람들이 동시대의 관련 분야에서 일하는 현업 개발자가 아니기 때문일 것입니다.

    지극히 동감합니다.


    0
  • 오키좋아
    513
    2016-07-28 11:57:44

    좋은 글과, 좋은 댓글들 잘 읽고 갑니다.


    음, 인정받는 프로그래머가 되는 법은 상사가 시킨 업무 빠르게 처리하는 게 아닐지...

    0
  • 오키좋아
    513
    2016-07-28 12:00:21

    추가적으로, 메인 글과 댓글들은 저 포함 여러 개발자분들에게 도움이 되리라 생각됩니다. 안지우셨으면,,,

    0
  • zepinos
    19k
    2016-07-28 12:02:42

    오키좋아 님 // 그럼 제가 나서서...좋은 의미에서 박제 한 번 하겠습니다. ^^;;;


    http://archive.is/XDN0u


    0
  • fender
    14k
    2016-07-28 12:03:13

    관련해서 재미있는 통계가 있어 소개합니다. 앞선 덧글에 미국의 대학들이 C언어 중심에서 자바 언어로 기초 교육 과정을 재편하는 동향을 언급했는데, 지금은 자바에 이어 파이선이 대세를 이어받은 모양입니다:


    이런 현상을 보면 대학의 교육 과정도 고정된 것이 아니라 시대에 따라 시차를 두고 변화하는 것임을 알 수 있습니다.

    0
  • 가가멜리
    1k
    2016-07-28 14:11:15

    사실 인정받는 프로그래머라.. 모호하죠..

    실력이 있다고 인정받나요? 

    실력이 있어도 인정 못받는 사람이 있고 실력이 없어도 인정 받는 사람이 있습니다.


    차라리 제가 인정받는 프로그래머가 되는 방법 in korea 라면

    자기가 못하는 것을 티 안나게 하는 방법

    자신 때문에 생긴 문제를 남한테 돌리는 방법  등등 결국 어필의 차이가 가장 크다고 생각합니다.


    그리고 본문 내용에 있어서 화제가 된 어셈블리가 도움이 된다! 에 대해서는

    저도 전자과라 어셈블리를 배웠습니다.

    어셈블리알면 -> 다른언어를 배우는데 도움이 된다 O

    다른언어를 수준급으로 아는 상태에서 어셈블리를 알면 능력이 높아진다 ?

    어셈블리를 아는 사람이 더 나은 개발자다 X 

    정도로 요약하겠습니다.


    카대, 외국 컴공 출신 많이 봣는데 개인 차입니다.

    그냥 개인적으로 익히는 게 빠른 사람이 좋은 대학을 나왔고 좋은 대학사람이 더 빨리 배우는 경향이 있지만... 좋은 대학나와도 일못하는 사람 한둘 보셧습니까..ㅎㅎ


    0
  • 참서빈
    3k
    2016-07-29 07:00:40

    몇 자 적겠습니다. 

     

    인정받는 개발자 < 좋은개발자 

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

    주석 : 없으면 나만 보는 소스 라생각하면서  유지보수 가능한 정도로 자세하게 정확하게

    로직 : 간결하고 길면 누구나 수정가능 하니 짧고 복잡하기보다는 배려가 필요함

    언어종류 : 많아도 무방하나 주무기 2 개 정도 보유 필요,  SQL실력은 필수

    업무경험 : 유사사례 경험이 많을 수록 많은 도움이 됨

    인간관계 : 아는 사람이 많고, 급하거나 문제생겼을때 도와줄 사람이 있어야 함

    근태 : 출근시간 10분전 착석, 정시 퇴근 필요시 미리 책임자에게 사유를 알림

     불만사항 : 큰소리로 여러명 모였을때 말하지 않고 책임자에게 조용히 별도로 이야기함

    0
  • kkey21a
    3k
    2016-07-29 09:15:56

    참서빈님//

    "근태 : 출근시간 10분전 착석, 정시 퇴근 필요시 미리 책임자에게 사유를 알림"


    꼭 출근시간 10분 전 착석해야 하나요?  

    그리고 일찍 퇴근하는 것도 아니고 정시 퇴근한다는데 왜 책임자에게 개인 사유를 알려야 하는지 도대체가 이해가 안 갑니다. 윗 분들이 이런 마인드를 가지고 있다는 자체가 문제 같아요.

    정시퇴근이란 회사에서 일하는 직장인들이 회사에서 정하는 퇴근 시간에 맞춰서 바로 퇴근하는 것일텐데, 대체 왜 상사에게 인사도 아니고 보고까지 해야하는지 ㅡ.ㅡa


    정시퇴근은 당연한겁니다.

    0
  • 쯔앙구
    276
    2016-07-29 09:29:13

    @참서빈  근태는 잘못작성하신게 아닌지?

    정시퇴근하는걸 꼭 책임자에게 알려야하나요??

    정시 출근해서 정시퇴근한다는데...

    0
  • 근원으로
    348
    2016-07-29 09:35:01

    @참서빈

    근태는 진짜 잘못 쓰신듯..

    늦게 출근한 것도 일 처리를 못한것도 아니고

    정시 전에 출근해서 정시 퇴근하는데 왜 보고를 해야하는지...;;

    0
  • Courage
    2k
    2016-07-29 13:28:34

    인정받는 개발자에 근태는 중요하죠.. 한국에서는요.

    근태 개판이면 분명 이런말 나옵니다. "개발좀 한다고 우쭐대고 다니고 애가 싸가지 없다고..."

    이게 국내의 현실 아닌가요? 근태는 아니라고 생각하시는 분들은 왜 그런지 모르겠네요..

    저도 지각은 많이 합니다만... ㅋ

    그리고 댓글에 있는 기초에 대한 부분... 요즘 트렌드에 맞나 모르겠네요..

    저도 지금 자신이 담당하고 있는 분야의 기초는 중요하다고 말하고 계속해서 공부하라고 푸쉬도 하지만...

    cup, 메모리, 버스, 등 만들줄 알면 개발 마스터할 기세네요...;;

    요즘도 학부에 어셈블리나 컴파일러 등 있긴 하지만..

    이렇게 관련된 모든것들의 기초까지 알아야 하는것인지는 진짜 의문입니다.

    0
  • kkey21a
    3k
    2016-07-29 15:21:57

    Courage//

    전 그럼 할 수 있어도 인정받는 개발자는 안 할랍니다 ㅎ

    대신에 좋은 개발자 되도록 노력해야 겠네요 ㅋ

    0
  • 나뚜
    37
    2016-07-29 20:39:45

    저는 그냥 책을 읽습니다~

    그리고 책에서 얻은 지식을 실무에 적용해봅니다~

    0
  • Bill
    92
    2016-07-30 00:06:18

    @참서빈

    정시퇴근하는데 왜 책임자에게 알려야 하는거죠?? 한국에 있는 출퇴근, 야근 문화는 참 이해하기가 힘드네요. 개발자가 좋은 대우를 받기 위해서는 이런 악습들이 없어져야 하고 그러기 위해서는 윗사람들이 먼저 실천해 나가야 할텐데... 참 안타깝네요

    한국 개발자 커뮤니티에있는 글들을 읽어보면... 화가 납니다.. 왜 개발자들이 이런 대우를 받는지..

    1
  • aIucard
    124
    2016-07-30 13:55:08

    와...fender 님의 댓글은 뭔가가 다르네요;;

    좋은 글 좋음 댓글들 정말 잘 봤습니다

    0
  • Nerd
    97
    2016-08-01 19:02:32

    1부터 5까지 다 잘 지키고 하고 있는데도... 아직 인정을 .. 아흑..ㅠㅠ


    좋은글 감사합니다!


    0
  • compsoite
    652
    2016-08-03 13:09:43
    저기 누군지 굳이 얘기 안하겠는데 꼰대개발자 마인드 강요하는 분 있네요. ㅋㅋ
    0
  • 참서빈
    3k
    2016-08-22 18:43:58

    현실이죠.. 에효.....

    0
  • return true
    2k
    2016-08-29 13:06:15

    늦게나마 저도 댓글하나 달고 갑니다...

    나중에 정독하려구요

    0
  • 여행매니아
    140
    2017-03-25 15:34:28

    글을 쓰신 분의 말씀에 크게 공감하는 1인 입니다. 이클립스가 없으면 기본 문법도 타이핑 할 수 없는 개발자가 많은 요즘 그들은 툴이 없으면 컴파일도 할 수 없더군요. 어셈블리어를 몰라도 자바를 공부하는데 아무런 불편이 없습니다. 하지만 어셈블리어를 제대로 익힌 사람이 자바를 공부한다면 습득속도나 깊이가 다르겠지요. 아주 가끔 정말 정말 열심히 하는 비 전공자가 대충 배운 전공자보다 나은 경우는 봤습니다. 그러나 제대로 열정을 가지고 컴퓨터를 전공한 사람들을 능가하는 경우는 찾기 힘들더군요.

    배우는 동안 도대체 이런 과목들이 프로그래밍과 무슨 연관이 있을까? 싶었던 전공과목들, 논리회로, 컴퓨터구조, 이산수학, 수치해석, 운영체제 등등등... 그런 과목에 대한 개념이 있고 없고는 천지차이입니다.

    열악한 H/W 환경에서 부족한 메모리를 고민하고 느린 CPU를 걱정하며 개발하던 그 때는 이제는 추억이 되어 버렸지요. 오히려 조금 메모리를 더 쓰고 CPU 부하를 좀더 걸더라도 유지보수가 쉽도록 설계하고 구현하는 것이 능력이 되어 버린 요즘,

    "고급언어를 배울거면 저변의 H/W측에 가까운 지식보다 해당언어를 더욱 효율적으로 구사할 수 있도록 디자인 패턴같은 논리적인 이론쪽을 들여다 보는게 낫다" 라는 댓글도 틀린 말은 아닙니다.

    누구나 가지고 있는 생각은 다를 수 있습니다. 사람들의 생각이 획일적으로 동일하다면 세상이 참 재미없을 것입니다. 누군가가 제시한 의견을 들어보고 거기서 얻을 것을 얻고 감사를 표시하면 될 것입니다.

    누군가 완전 터무니 없는 거짓말로 사람들을 현혹한다면 그땐 침묵하지 맙시다 ^^

    0
  • GunBBangOFyou
    109
    2018-10-30 11:17:06

    이럴수가... 저에게 가장 필요한 조언인거같네요 감사합니다!!

    이렇게 좋은 조언이 이미 2년이나 전에 작생해주셨다니 !!! 늦은 감이 없지않지만 참고하여 열심히하겠습니다!! 

    0
  • 공부하는기계
    9
    2019-02-11 20:57:30

    머리가 아프게 공부하면 됩니다.

    저는 절망감을 느끼고 있습니다... 정말. 끝이 있는걸까.

    이렇게 해도 되는걸까...

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