fender
14k
2019-03-17 09:46:57 작성 2019-03-18 12:56:53 수정됨
46
10033

패러다임, 디자인 패턴, 리팩터링의 중요성 그리고 성능에 대해


어제 게시판에서 몇몇 분들과 저수준 지식의 중요성 등에 대해 꽤 격앙된 토론을 했습니다. 주제 자체는 사실 하마님 말씀대로 이 곳에서도 주기적으로 등장하는 고수준 언어에 대한 이런 저런 오해에 관한 내용이라, 못 보신 분들께 굳이 찾아볼 것을 권할 만큼 대단한 내용은 아니었다고 생각합니다.

하지만 토론을 통해 그런 오해가 얼마나 뿌리 깊게 남아있는지 재확인할 수 있었고, 토론 과정에서 VM 언어는 성능 때문에 사용하면 안된다던지 디자인 패턴, 리팩터링 등은 '가짜 지식'이라는 등 꽤나 극단적인 주장까지 오갔기 때문에 혹시 경험이 부족한 개발자 분들이 잘못된 생각을 하게 될 까 우려해서 별도의 글로 관련 내용을 정리해보려 합니다.

이 글은 해당 토론을 이어 가거나 토론에 참여했던 어느 분이든 직접적으로 '저격'할 의도로 쓴 글이 아님을 먼저 밝히고 싶습니다. 사실 위에서 언급한 주장은 과격하긴 해도 이 곳에서 처음 접한 내용은 아닙니다. 저수준에 대한 맹신과 고수준에 대한 멸시, 마이크로 최적화에 대한 집착, 패러다임이나 리팩터링 수준의 소프트웨어 공학에 대한 몰이해 등은 영어권 인터넷에도 이전에는 흔히 볼 수 있었고, 요즘엔 거의 사라졌지만 여전히 게임 개발자 커뮤니티 등에서는 심심찮게 등장하는 주제이기도 합니다.

그래서 이번 글은 특정 개인이 아닌 그런 주장들이 경험이 부족한 개발자들에게 잘못된 인식을 심어주는 것을 경계하기 위한 목적으로 이해해주시면 감사하겠습니다.

우선 성능에 대한 이러한 '미신'은 자바 언어 초창기에는 매우 흔하게 볼 수 있었고, 지금도 많은 초보 개발자들이 빠지기 쉬운 함정이기도 합니다. 세부적인 내용은 달라도 큰 줄기는 대략 이렇습니다:

어떤 언어 A는 B 보다 50% 빠르다. 50%는 엄청난 차이이고, 성능이 곧 돈이나 사용자 경험에 직결되는 마당에 50%나 느린 언어를 쓰는 건 바보 짓이다.

이는 얼핏 당연하게 들릴 수 있는 말이기 때문에 성능이나 최적화에 대한 경험이 부족한 개발자들이 쉽게 빠지는 함정이라고 생각합니다. 자바 언어 초창기에는 비슷한 논리로 많은 공격을 당했지만 자바는 한 때 미션 크리티컬한 비즈니스 시스템 시장을 장악할 수 있었고, 요즘에는 자바보다도 성능이 훨씬 느린 언어들이 그 시장에 진입하고 있습니다. 그렇다면 위의 주장이 어떻게 잘못된 것일까요?

이에 대한 답은 기술적인 설명 보다는 쉬운 비유를 드는 것이 더 효과적인 방법이라고 생각합니다. 여기서는 빠른 언어 A는 F1 레이싱카, 느린 언어 B는 평범한 SUV라고 하겠습니다. 그리고 편이를 위해 고속도로의 속도 제한 같은 건 없다고 가정하겠습니다.

F1 경주차와 SUV가 트랙에서 경주를 한다면 보나마다 경주차가 압승할 것입니다. 문제는 일반적인 시스템이라는 환경은 자동차 경주 트랙이 아니라 명절에 꽉막힌 고속도로와 비슷하다는 것입니다.

즉, F1 경주차가 레이싱 트랙에서 SUV보다 두 세 배 빨리 달릴 수 있을지는 몰라도, 명절에 서울에서 부산까지 SUV로 8시간이 걸리는 길을 경주차로 달리면 4시간에 주파할 수 없다는 것은 굳이 이유를 설명하지 않아도 이해하실 것으로 믿습니다.

서울에서 부산까지 걸리는 시간은 시스템에 비유하면 요청 이후 응답까지 걸리는 시간입니다. 그리고 그 시간이 8시간이 걸렸다면 대부분의 시간은 실제 도로를 달리는 게 아니라 정체가 풀리기를 기다리는데 소모하는데, 시스템에서 이는 보통 네트워크나 데이터베이스 등과 관련된 입출력 관련 오버헤드에 해당합니다.

이는 성능을 무엇보다 중요하게 여기는 게임에도 적용되며, 이 경우는 주로 렌더링 파이프 라인이나 물리 계산 등이 '정체 구간'에 해당합니다.

즉, 일반적인 시스템은 응답/반응 시간 대부분을 잡아먹는 '정체 구간'이 있기 때문에 언어의 단순 실행 성능(raw speed)은 소요 시간을 단축 시키는데 유의미한 차이를 보이지 않는 경우가 많다는 것이 바로 최근 20년 간 VM이나 가상화 기술이 대세로 떠오를 수 있었던 주된 이유입니다.

또한 이를 통해 왜 서버 시스템의 사양을 무한정 높이는 것보다 클러스터 등을 활용해서 '스케일 아웃(scale out)'하는 것이 훨씬 효율적인 최적화의 방식인지 또한 부분적으로 이해할 수 있을 것입니다.

다시 말하면 명절에 도로가 꽉 막혀서 서울에서 부산까지 8시간이 걸린다면, 문제를 해결하기 위한 방법은 자동차의 속도를 높이는 것이 아니라 차선을 확장하는 것이라는 간단한 원리입니다.

정리하면, 비교적 느린 자바나 C#, 혹은 파이선 같은 언어들이 대세가 될 수 있었던 것은 실제 구동 환경에서 언어 자체의 실행 속도가 전체 성능에 미치는 영향이 미미한 경우가 많기 때문이고, 어차피 경주차가 제 속도를 못낸다면 비싼 유지비용이나 불편한 좌석 등을 감수하고 SUV 대신 운전할 이유가 없다는 것과 동일한 이유로 C와 같은 언어보다 여러 분야에서 각광 받게 된 것입니다.

반면 분야의 특성상 그런 큰 정체 구간이 존재하지 않는 경우도 있는데, 그런 이유로 아직 디바이스 드라이버 개발이나 임베디드 분야 등은 속도나 메모리 최적화를 위해 C를 주력으로 사용하는 것입니다.

성능에 대한 이야기는 이 정도로 마무리하고 이제는 저수준 지식에 대한 맹신, 혹은 고수준 지식에 대한 멸시에 대한 이야기를 해볼까 합니다.

성능에 대한 오해와 마찬가지로 이러한 편견 역시 꽤나 뿌리가 깊습니다. 그리고 성능에 대한 부분은 실제 시스템으로 증명이 되지만 고수준 언어를 잘 다루는 사람들이 어떤 식의 고민을 하고 개발을 하는지는 그보다는 쉽게 접하기 어렵기 때문에 이런 편견은 조금 더 타파하기 어려운 것 같습니다.

또한 저수준 지식은 대학에서 여전히 중요한 커리큘럼으로 가르치지만 상대적으로 고수준 분야의 기술 추세가 커리큘럼에 반영되는데는 상당한 시간이 필요합니다. 해외 대학들은 입문 언어를 C에서 자바로, 그리고 다시 파이선으로 바꾸는 추세이지만 아마도 국내 대학들은 아직 C나 C++을 고수하고 있을 것 같습니다.

여기에 당장 포인터나 하드웨어 특성 등을 고려하지 않아도 되는 고수준 언어의 낮은 진입장벽이 합쳐지면, 대략 하드웨어나 운영체제와 같은 저수준 지식이 프로그래밍의 '근본' 지식이고 자바나 파이선 코딩 같은 '응용' 분야는 상대적으로 쉽기 때문에 시간만 있으면 언제나 배울 수 있다는 식의 편견, 혹은 묘한 자부심이 생겨나게 되는 것이 아닌가 싶습니다.

대학의 소프트웨어 관련 학과의 목적은 자바나 파이선 전문가를 양성하는 것이 아니기 때문에, 당연히 컴퓨터의 구조와 같은 저수준 주제로 부터 객체지향이나 함수형 언어 같은 고수준 주제까지 소프트웨어에 관한 폭넓은 주제를 커리큘럼으로 다루고 있습니다.

그래서 만일 본인이 막 그런 대학에 입학한 전공자이거나, 이미 본인의 분야에서 충분히 전문성을 확보하고 다른 분야의 교양 지식을 쌓고 싶은 개발자라면 그런 포괄적 커리큘럼을 착실하게 공부하는 것은 상당한 도움이 될 것입니다.

하지만 만일 본인이 학원으로 프로그래밍에 입문해서 무작정 자바 같은 언어로 실무에 투입되었는데 더 나은 개발자가 되는 방법을 모르겠다면 어떨까요? 바로 이런 분들에 대한 우려가 제가 이 주제에 대해 항상 강한 주장을 하게 되는 이유입니다.

고등학교 때 배운 지식이 교양은 될지라도 직접적인 직업 활동에 도움을 주는 내용은 제한적입니다. 즉, 기초 수학이 필요한 분야에 취업을 한 사람이 고등학교 수준의 수학 과정을 복습하는 것은 의미가 있어도 그 사람이 세계사, 국어 등 모든 고교 교과 과정을 다시 공부하지 않으면 절대 해당 분야에서 성공할 수 없다는 식의 주장은 성립하지 않습니다.

소프트웨어 관련 학과의 전공 지식도 이와 비슷합니다. 즉, 실무에서 어떤 분야를 택하느냐에 따라 대학에서 배운 어떤 내용은 필수 지식이 되지만 다른 지식은 '알면 좋은' 수준의 교양 지식이 되는 것입니다. 그리고 만일 본인이 선택한 분야가 자바나 C#, 또는 프론트엔드 개발자라면 컴퓨터 구조나 운영체제 같은 분야는 반드시 알아야 하는 지식이 아니라 알면 좋은 교양 지식으로 분류할 수 있습니다.

물론 교양지식도 중요합니다. 세상에 알아서 나쁜 것은 없습니다. 단, 필수 지식을 충분히 갖추지 않고 교양 지식에 집착하는 것은 스스로 커리어를 망치는 지름길일 뿐입니다.

학원에서 속성으로 자바를 배우고 막 실무에서 프레임워크를 이용해서 페이지를 찍어내는 식의 업무를 하는 개발자라면 아마도 더 나은 개발자가 되기 위해 넘어야 하는 장애물을 만나게 될 것입니다. 그리고 이러한 벽'은 현재 서있는 자리 아랫쪽, 그리고 윗쪽으로 모두 존재합니다.

아래에 있는 벽을 뚫고 내려간다면 C++로 구현된 JVM을 만나게 될 것이고, 더 파고 내려가면 운영체제에 다다를 것이며, 거기서 더 파고 내려가면 궁극적으로는 하드웨어에 도달하게 됩니다.

하지만 자바나 C# 개발자에게 있어 그 방향의 벽은 애초에 뚫지 말라고 만들어 놓은 것입니다. 이는 막 학원을 수료한 자바 입문자에게나 20년 경력의 고수에게나 똑같이 적용되는 규칙입니다. 그런 벽이 존재하는 이유는 그 아랫 방향의 복잡성은 가상머신이 책임질테니 개발자는 남는 여력으로 보다 높이 올라가라는 의도입니다.

그리고 그런 벽의 존재에 대해 그 아래 있는 개발자들에 대해 열등감을 가질 이유도 전혀 없습니다. 그 중에는 바닥 아래로 못 내려오는 개발자들을 뭔가 근본이 부족한 것으로 멸시하고 자신들은 마음만 먹으면 그걸 뚫고 올라가 하늘 끝까지 갈 수 있다고 착각하는 부류가 있지만, 그건 그 바닥 윗쪽으로도 얼마나 높고 넓은 공간이 있는지 경험한 적이 없기에 부릴 수 있는 객기에 불과합니다. 그런 사람들이 아래에서 올라올 동안 이미 그 보다 높은 바닥에서 시작한 놀고 있는 것이 아니라면 당연히 같은 노력을 들이면 더 높이 올라갈 수 있을 따름입니다.

애초에 자바나 닷넷 같은 기술을 만든 이유는 저수준 지식을 공부할 능력이 없는 개발자들을 차별하거나 배려하기 위함이 아니라, 기술이 발전해서 소프트웨어가 다루는 분야가 하드웨어로 부터 아득하게 먼곳까지 확장하게 되어 더 이상 같은 개발자가 바닥부터 그런 경계의 끝까지 모두 능숙하게 다루는 것이 사실상 불가능해졌기 때문입니다.

그래서, 스스로 자바나 C#와 같은 언어를 주력으로 삼은 개발자라면 자신이 서 있는 바닥 아래에 무엇이 있는지를 공부하는 것은 교양 수준의 지식이 됩니다. 그 바닥을 뚫고 내려가고 싶다면 공부를 더하는 것이 아니라 더 저수준을 다루는 분야로 전직을 하는 것이 올바른 접근입니다.

반면, 윗쪽에 존재하는 벽은 노력에 따라 얼마든지 뚫고 올라갈 수 있고 또 고수준 언어를 다루는 개발자라면 다음 단계로 가기 위해 당연히 그렇게 해야하는 것입니다.

구체적으로, 앞서 언급한 막 학원을 수료한 흔한 SI 환경의 자바 개발자라면 그러한 윗쪽 방향의 벽은 예컨대 스프링 프레임워크를 사용은 할 수 있지만 구조를 이해하거나 그런 프레임워크를 직접 설계할 수는 없다거나 하는 고민일 것입니다.

여기서 중요한 것은 그런 종류의 벽을 깨기 위한 최적의 도구는 바로 패러다임, 리팩터링, 디자인 패턴과 같은 지식이라는 점입니다. 알고리즘 같은 주제가 꽤 유용한 주제일 수는 있어도 이 단계에서 그런 벽에 막혀있는 개발자들이 지나치게 집착하는 것을 경계하는 글을 많이 썼던 것도 바로 그런 이유입니다.

알고리즘 역시 그런 개발자의 위치에선 바닥 아랫쪽에서 주요 무기로 사용할 수 있는 지식이고, 그 윗쪽으로 올라오면 유용성이 급격하게 떨어집니다. 여전히 실무에선 가끔씩 도움을 줄 수 있는 정도인지는 몰라도 적어도 그 윗쪽의 벽, 즉 자바나 C# 개발자가 다음 단계로 올라가기 위해 돌파해야하는 벽을 깨는데는 사실상 거의 도움을 주지 못한다고 보아야 합니다.

반면 앞서 언급한 바대로 패러다임, 리팩터링, 디자인 패턴 등과 같은 주제는 바로 윗단계의 벽을 부수기 위한 최적의 도구입니다. 예를들어 스프링 프레임워크의 구조를 이해하고 싶다면 필요한 것은 소스를 내려받아 한 줄 한 줄 분석하는 것이 아니라, API 수준에서 클래스의 계층구조나 메서드의 시그네쳐를 보고 동작이나 의도를 이해하는 것입니다.

그리고 패러다임이나 디자인 패턴은 그런 식의 보다 추상적인 이해를 가능하게 하는 '기본 문법'에 가깝습니다. 예컨대 스프링에서 'AbstractSingletonProxyFactoryBean'이란 클래스를 접한다면, 디자인 패턴을 이해하는 개발자라면 소스를 열어서 한 줄 한 줄 조건문과 메서드 호출을 따라가지 않아도 클래스 이름의 '싱글턴', '프록시', '팩토리' 같은 단어만 가지고도 대체적인 역할과 메서드 구성, 사용 방법 등을 짐작할 수 있습니다.

패러다임, 리팩터링, 디자인 패턴 등의 지식은 그런식으로 언어의 기본 문법을 가지도 더 복잡한 구조를 쌓아 올리는 원리를 제시하며, 그 과정에서 접할 수 있는 흔한 문제를 풀 수 있는 가이드라인을 제공합니다. 물론 그런 해법이 항상 정답은 아닐 수 있겠지만, 오랜 기간 여러 능력있는 개발자들이 쌓아올린 경험에서 비롯된 그런 가이드라인이, 그런 걸 깡그리 무시하고 언어 문법만 가지고 혼자서 도닦듯 수련해서 '발견'한 패턴보다 정답에 가까울 확률은 매우 높습니다.

모든 것을 떠나서, 그런 지식들은 고수준 개발자가 다음 단계로 나가기 위해 익혀야하는 지식을 만들고 전파하는 사람들이 공유하는 기본 문법입니다. 그래서 적어도 인터넷 기술 블로그에 언급된 '커플링'이 무엇이고 왜 나쁜지, 또는 API 문서에서 찾은 '팩토리'가 무슨 역할을 하는지 같은 상식은 최소한 이해할 수는 있어야 그 다음 단계로 발전할 수 있는 길이 열리는 것입니다.

그리고 개발 분야의 어려움 중 하나는 자신이 일정 수준에 도달하기 이전엔 그 다음 단계에 있는 문제나 고민들이 보이지 않는다는 점입니다. 예를들어 경력이 얼마 안되는 개발자들은 자바 같은 언어를 두고 '쉽다'라고 착각을 하는 경우가 많습니다. 또한 언어는 어차피 반복문, 조건문, 함수 호출 같은 문법만 알면 다 거기서 거리라는 식으로 피상적 이해를 하는 경우도 흔하게 볼 수 있습니다.

하지만 어느 수준의 개발자는 어차피 반복문이 문법만 다르지 뭐 별거 있냐는 식의 우물안 개구리 식의 사고의 틀에 갇혀 있을 때, 누군가는 반복문의 명령형적 특성에 주목하고 이를 선언적 파이프라인으로 대체하는 고민을 하며, 그런 고민의 결과가 람다 같은 스펙으로 반영이 됩니다.

어떤 개발자는 입력값이야 에러 안나게 꼼꼼하게 널체크 해주면 끝이라고 생각할 때, 누군가는 아예 '널'이라는 개념을 사용하지 않는 옵셔널(optional)이라는 새로운 방식을 고안하고 언어에 도입하며, 또 다른 개발자는 계약(contract) 기반 프로그래밍의 가능성을 고민합니다.

또한 누군가 리눅스 좀 만지고 서버 몇 번 구성해봤다고 서버 쪽은 알만큼 안다라고 자만할 때, 누군가는 가상화를 도입하고 마이크로서비스와 서버리스 아키텍쳐를 고민하는 것입니다.

이렇듯 그 단계에 도달하기 전에는 이해하거나 심지어 존재 자체도 인식하기 힘든 고민의 영역은 수도 없이 많습니다. 그렇기 때문에 그런 지식을 얻고 자신의 능력을 다음 단계로 끌어올리기 위해선 끊임없이 기술 동향을 파악하고, 관련된 토론이나 스펙을 찾아보며, 때에 따라선 타입이론 같은 이론적 기반을 공부해야하는 것입니다.

그런 노력을 다 무시하고 분야와 무관한 어떤 '근본 지식' 같은 게 있어서 그와 관련된 매우 좁은 분야의 공부에 매진하다 보면 나머지 분야는 도를 깨치듯 자연히 통달하게 된다는 태도는 개발자로서 꽤 편협하고 오만한 것이며, 이제 막 입문해서 아직 방향을 잡지 못하는 개발자에게 권하기엔 매우 위험한 접근이기도 합니다.

더구나 그런 분야가 직접적인 도움이 되기 힘든 고수준 분야의 개발자라면, 무턱대고 그런 쪽으로 공부 방향을 잡아 정작 자신에게 훨씬 중요한 분야의 노력을 게을리할 경우 영원히 남이 만든 프레임워크의 영역을 벗어나지 못할 수도 있습니다.

일부 저수준 개발자들이 그런 편협한 생각으로 고수준을 멸시하고 그런 분야에선 어떤 고민을 어떤 깊이로 하는지 이해 못하는 거야 그 사람들이 스스로 틀에 갇히는 문제이니 무시하면 그만이지만, 고수준 개발자가 그런 이야기에 혹해서 방향을 잘못 잡으면 커리어를 망치게 됩니다. 그리고 이 것이 이 주제로 토론이 있을 때마다 제가 반복적으로 강한 주장을 제시하고 장문의 글을 쓰게 되는 이유입니다.

정리하면, 모든 공부는 다 유익한 것이지만, 어떤 공부를 먼저하고 얼마나 비중을 둘 것인지는 분야에 따라 다르다는 것이 핵심입니다. 특히 비전공자로 출발해서 회사 업무에 치이는 와중에 짬을 내서 공부를 하는 입장이라면 더욱 그 시간을 본인의 실력을 향상 시키는데 직접 연관이 있는 방향으로 집중하는 것이 중요할 것입니다.

76
50
  • 댓글 46

  • rebwon
    176
    2019-03-17 10:22:48

    좋은 글 감사합니다. 글에 많은 부분에 동의가 되고 공감되네여

    1
  • 세브라이드
    1k
    2019-03-17 10:39:09

    정성들여 써주신 글 감사합니다. 앞으로 진로에 큰 도움이 되었습니다!

    0
  • ....
    2019-03-17 10:41:29 작성 2019-03-17 11:34:06 수정됨
    좋은 글 감사합니다
    0
  • freestyle
    3k
    2019-03-17 11:05:36

    fender님의 견해에 전적으로 공감하는데... 저는 사실 그게 일반적이고 상식이라고 생각했는데 그 글을 보니 다른 생각을 가진 분들도 있는 것 같습니다. 

    얼핏 자수성가(?)형으로 성공을 하거나 그렇게 살아온 분들에게서 보이는 그런 "확신" 내지는 소위 말하는 장인정신(?), 또 다르게 보면... 자신만의 체계에 지나치게 매몰된 듯한 느낌이 들었습니다.  옹고집이라는 말도 있지 않습니까?

    자기 분야에서 오래 있다보면 어느 정도 안목이 생기는 것은 어찌보면 당연하겠지만 그렇다고 그것만이 내 세상은 아니겠죠. 특히 IT쪽은 전통의 장맛을 유지하는 식은... 아닌것 같다는 말입니다. 

    아무튼 저는 이런 구도를 코어 레벨과 애플리케이션 레벨이라고 봅니다. 둘 다 중요한데 너무 한 쪽에 치우치다보면 극단적인 일반화의 오류로 빠질 수 있지 않을까 싶네요.

    1
  • fender
    14k
    2019-03-17 11:25:38

    본문에도 언급했지만 저는 이 글을 특정 회원을 비난할 목적으로 쓴 것이 아니기 때문에, 가능하면 덧글에서도 그런 방향의 논의는 피했으면 좋겠다는 생각입니다.

    물론 그 회원의 주장을 경험 부족한 분들이 무턱대고 따라하는 것을 우려해서 이런 글을 적긴 했으니 주장 자체에 대한 논의는 피할 수 없겠습니다만, 그 분 자체에 대한 내용이라면 필요할 경우 해당 글타래에서 이어가는 게 어떨까 싶습니다.

    5
  • 라임
    451
    2019-03-17 11:28:25

    좋은 글 잘 읽고 갑니다. bb

    0
  • Amunt
    14
    2019-03-17 11:46:47

    혼자 개발하는 시대는 한참 지났고

    자기가 한 평생 그 프로젝트만 붙잡고 있을것도 아닌데

    남이 봐도 딱 이해가 갈만한 코드를 쓰는것도 매우중요하죠


    1
  • 박가사탕
    668
    2019-03-17 11:51:27

    분야와 무관한 어떤 '근본 지식' 같은 게 있어서 그와 관련된 매우 좁은 분야의 공부에 매진하다 보면 나머지 분야는 도를 깨치듯 자연히 통달하게 된다는 태도


    근본지식은 없습니다. 근본역량이 있죠.

    만약 코더란게 정말 있다면..

    저 감각을 한번도 느껴보지 못한 개발자입니다.

    -2
  • 우헤헤
    274
    2019-03-17 11:55:42

    구구절절 옳은 말씀이네요

    0
  • flydof
    385
    2019-03-17 12:04:33

    바퀴를 다시 발명하지 마라

    Dry- dont repeat yourself

    0
  • flydof
    385
    2019-03-17 12:07:20

    고수준 언어 c# java

    저수준 언어 C c++

    0
  • ZETT
    747
    2019-03-17 12:48:49

    패턴 필요하죠

    다만 요즘 보면 

    뭣도 모르면서 어디서 뭐가 핫하다는 소리만 듣고 그걸 그대로 입으로 옮기는 사람들을 꽤 만나고 보는 중이라

    극혐중입니다. 


    3
  • adtech_so
    171
    2019-03-17 13:22:01

    > 어떤 공부를 먼저하고 얼마나 비중을 둘 것인지는 분야에 따라 다르다는 것


    공감합니다. 현재 자신의 위치를 파악하고 각 테마에 관해 우선순위를 나눠서 꾸준히 해나가는 습관이 필요하다고 생각합니다. 음.. 메타인지의 전략화라고 할까요?..

    0
  • 스텁
    1k
    2019-03-17 13:30:27

    모니터만 깨끗이 닦아도 컴퓨터는 빨라진다고 합니다. 자바를 잘하기 위해서는 OOP/디자인 패턴보다는 C/C++이 더 낫고 그 이전에 어셈블리를 하는게 더 낫고 그 전에....아...물리학부터 마스터를 ...

    1
  • 심심한사부
    1k
    2019-03-17 14:13:35

    디자인 패턴은 개발자의 직관에 의존해 무질서 하게 막코딩 하던 세계에서 그나마 혁명적인 결과물이라고 생각 됩니다.

    고객이 요청한 비즈니스 로직을 주어진 시간에 구현하는데 집중해야지

    주객이 전도 되서 시스템 하부 연구에 몰두해서는 안됩니다.


    과거에는 Turbo-C 하나만 잘 쓰고 BIOS만 조금 들여다 보면 시스템 전체를 어느정도 파악할 수 있지만

    이제는 한사람이 시스템 전체를 이해하기에는 너무 커져 버렸습니다.



    1
  • oddapi2
    16
    2019-03-17 15:41:10

    마지막 줄의  비전공자로 출발해서 회사 업무에 치이는 와중에 짬을 내서 공부를 하는 입장인 사람으로써 정말 도움이 되는 글이었습니다. 항상 주어진 시간안에 어떤 공부를 해야하나 모든걸 다 알아야하나 이런 저런 글들을 보면 혼란이 오는데 fender님 말씀처럼 제 커리어에 맞게 실력을 향상시킬 수 있는 방법으로 효율적이게 공부해야겠습니다.

    2
  • fender
    14k
    2019-03-18 05:32:52 작성 2019-03-18 07:14:37 수정됨

    다른 글을 보니 디자인 패턴은 실무에서 잘 사용하지 않는다거나 자연히 알게되는 것이라는 주장이 있더군요. 따로 글을 쓸까 하다가 이어지는 내용이라 그냥 여기에 적습니다.

    제 생각에 그런 이야기는 절반은 맞고 절반은 틀린 내용입니다. 우선 국내 SI 기준으로 디자인 패턴 같은 건 사실상 거의 쓸일이 없다는 점에는 동의합니다. 그런데 애초에 커리어 목표가 그런 방식의 개발을 벗어나지 않는다면 디자인 패턴을 볼 시간에 차라리 SQL이나 데이터베이스 튜닝 같은 주제를 공부하는 것이 더 유용할 것입니다.

    이 글은 무슨 이유에서 건 스프링 속성으로 배워서 페이지 찍어내는 식의 국내 SI 환경 이상의 실력을 원하는 분들을 위한 것입니다. 그리고 그 단계가 되려면 스프링을 하던 대로 사용만하는 게 아니라 이해하고 비슷한 걸 만들 수도 있어야 하며, 그런 수준이 되려면 바로 본문에 언급한 내용들이 필요해 집니다.

    디자인 패턴은 하다보면 알게된다는 이야기는 어느 정도는 맞는 이야기입니다. 특히 팩토리 같이 흔하게 사용하는 패턴 같으면 그런 소스를 자주 본다면 개발 감이 좋은 분들은 의도까지 짐작하는 경우가 없진 않겠죠. 그런데 일반적인 SI 환경에서 하다 못해 팩토리라도 몇 번이나 써보셨나요? 그런 환경에서는 다양한 디자인 패턴을 쓸 기회도, 볼 기회도 많지 않습니다.

    디자인 패턴은 외우는 게 아니라는 부분까지는 저 역시 거의 전적으로 동의합니다. 특히 리팩터링 지식이 없이 패턴만 외워서는 별 쓸모가 없는게 사실입니다.

    하지만 흔히 쓰는 디자인 패턴이 어떤 것이 있는지 각각 의도와 예제를 한 두 번 쯤 읽고 이해하고 잊어버리는 것과 아예 접하지 않은 것은 꽤 차이가 있습니다.

    일단 스트래티지라는게 왜 존재하고 어떻게 생겼는지, 팩토리라는 건 어떤 부류의 문제를 해결하기 위해 쓰는 것인지를 한 번이라도 읽어보고 완전히 이해한 적이 있다면, 나중에 비슷한 소스를 보거나 그런 부류의 문제를 적용할만한 상황을 접하면 전에 보았던 내용이 떠오르게 되는 것입니다.

    반면에 그런 정도의 지식도 없이 스프링 API 같은 걸 한참 쳐다보고 있으면 어느날 갑자기 "패턴이 보인다!" 하고 각성하게 되는 그런 일이 가능할지는 의문입니다.

    프로게이머가 될 수 있는 천재적 소질을 가진 게이머라면 그냥 프로들 리플레이만 아주 많이 보다보면 무언가 초반 패턴을 발견하고 나름대로 분석해서 패턴 사이의 상성을 파악하고 나름의 빌드 이론으로 정립하는 그런게 가능할 수도 있습니다.

    그런데 특히 본인이 남들보다 늦게 시작한 게이머라면 본인에게 그 수준의 소질이 없을 가능성이 높습니다. 빌드 한 번 훑어보는거나 디자인 패턴 한 번 훑어보는 거 기껏해야 몇 일 안걸립니다. 그 시간이 아깝다고 본인의 커리어 걸고 그런 모험을 할 이유는 없다고 생각합니다.

    빌드만 집착하면 좋은 프로게이머가 못된다? 패턴만 쓰면 창의적인 개발자가 못된다? 일단 평범한 프로게이머나 기본은 하는 개발자가 되고 나서 고민해도 늦지 않습니다. 아직 남들처럼 뛰지도 못하는 데 무슨 창의적인 스타일로 날아야 멋질까 고민해봐야 쓸 데 없습니다. 

    그리고 디자인 패턴 같은 건 한 번 알아두면 적용한 코드가 보이고 적용할 만한 문제가 보이기 시작하지만 아예 안봤다면 이런 부분은 패턴을 적용해서 풀만한 문제라는 생각 자체가 들지 않습니다.

    반면에 패턴을 한 번 이해하고 잊어버리면 패턴이 적용된 코드가 자연히 읽혀지고 스스로도 패턴이 적용된 코드를 굳이 이런저런 패턴을 써야겠다는 생각을 하지 않아도 쓰게 됩니다.

    특히 SI 실무에 종사하는 중이라면 그런 건 의식적으로 공부하지 않으면 자연히 깨닫게 되는 건 어렵습니다. SI 하면서 프레임워크가 아닌 프로젝트 소스에서 무슨 팩토리 같은 게 들어간 코드를 몇 번이나 보셨나요?

    디자인 패턴까지 갈 것도 없이, 그런 실무 프로젝트에서 인터페이스나 추상 클래스는 몇 번이나 써보셨나요? 이유도 모르고 그렇게 배웠으니 그냥 서비스나 매니저에 습관처럼 인터페이스 나누는 걸 제외하고 진짜 설계의 이유로 인터페이스를 만든 적이 있나요?

    그런 환경에서 그런 코드만 보면 그냥 그 수준에서 개발하는 것이 익숙해지는 것입니다. 그래서 시간이 지나면 디자인 패턴을 깨닫게 되는 것이 아니라 그런 건 실무에서 필요가 없다는 생각이 들게 되는 것이고 그럼 점점 더 스프링 같은 걸 이해하고 직접 만드는 그 이상의 수준에서 멀어지는 것입니다.

    6
  • 아플라
    589
    2019-03-18 08:59:46

    항상 좋은글 감사합니다.

    fender님 글은 항상 설득력있고 힘있게 다가와서 읽는내내 즐겁습니다.

    0
  • 라이라
    1k
    2019-03-18 09:36:29

    로보넥스가 생각나네요

    0
  • 디늑
    356
    2019-03-18 09:52:00

    스스로를 다시 돌아보는 계기가 되는 좋은글 감사합니다

    0
  • choju
    818
    2019-03-18 10:22:19 작성 2019-03-18 10:28:54 수정됨

    이런가치도 있고.. 저런가치도 있고..

    전 저수준이 아직도 꽤 중요하다고 봐욤..

    한가지 아쉬운점은 학원출신 개발자라는 형태를 양산하여 소프트웨어 업계의 인력난을 급하게 해결하려는 문제에서 오는 단순한 문제일 수도 있을 수도 있어요.

    1
  • fender
    14k
    2019-03-18 10:38:16

    choju // 네, 저수준이 중요하지 않다는 주장을 한 적은 없습니다. 저수준을 하는 입장에서 고수준의 관심사들이 필수 지식이 아니듯, 반대로 고수준을 주력으로 하는 개발자는 - 학원 출신 신입이건 20년 넘은 베테랑이건 - 고수준의 필수 소양들이 저수준 지식에 우선한다는 이야기일 뿐입니다.

    0
  • uphiller
    629
    2019-03-18 10:41:08 작성 2019-03-18 10:43:09 수정됨

    좋은글 감사합니다.

    사실 장인정신을 가지고 공부를 하고 기술에 정진하고 공부한것을 프로젝트에 녹여내서 

    퀄리티가 높은 프로젝트의 비중을 높이는 것이 전체적으로 지향해야할 방향입니다.

    하지만 현실적으로는 프로젝트별로 케바케인것입니다. 

    무언가를 만들때 기술적으로 완벽해야만 엄청나게 좋은 서비스가 만들어 지는 것도 아닙니다.

    그리고 SI라고 해서 기술력이 떨어지고 프레임웍을 가져다 쓰고 화면만 찍어 만들어 내는건 아니고요

    SI에서도 분야별로 TA 같은 분야도 있고, 포털에서 서비스를 구축할때 자체인력으로 감당이 안되어 프리를 쓰는 경우도 

    있구요. 그리고 스타트업이라고 해서 엄청나게 기술적으로 구축하거나 그렇지는 않구요 이것또한 프로젝트의 상황별로 

    달라지는 경우입니다.

    프로젝트의 상황에 따라 코드의 품질이 완벽해야 하는 것을 지향하는 경우도 있구요 기간을 단축시키길 원하는 경우도 있습니다. 

    저또한 스타트업에서 프로젝트의 의도와는 달리 코드의 질이나 패턴의 구현에 집착한 개발자 때문에 고생했던적도 있습니다. 

    그래서 결론은 개발에서 공부도 중요합니다만, 

    내가 공부한것을 실무에 반영시키고 공유하고 하는 부분의 고민도 충분히 해보아야 한다고  생각합니다.

    내가 공부한것이 공부로만 끝나면 꾸준함이 떨어집니다.

    그래서 이분야 저분야 핫한분야의 겉만 공부하다가 끝나는 경우가 대부분입니다.

    저또한 그랬고 지금도 그것을 좀 벗어나기 위해서 공유의 중요성을 인지하려고 노력하고 있습니다.

    이런 부분을 좀 보완하는데 도움이 되는 툴들은 다들 아시는 것처럼 블로그 , 오픈소스, 강의 등이 있겠지요.

    고수들은 그러더군요 처음할때는 이런것들이 일이었는데 이런것들을 하다보니 일상이 되었다구요.

    모든 오픈소스 프로젝트들이 이렇게 출발했지 않을까요.

    이상 SI 5년, 스타트업 5년 정도 경험한 실력이 좀 없는 개발자의 의견이었습니다. 


    1
  • Gump
    13
    2019-03-18 11:49:31

    좋은 글 감사합니다.

    생각만해도 따끈따끈한 토론이었겠네요.

    개인적으로는 몇 가지 미묘하게 의견이 다른 부분들도 있지만,  대부분의 굵은 줄기에 대체로 동감하고 있어서 재미있는 글이었습니다.

    주변 지인들에게 추천하겠습니다.

    잘 읽었습니다.

    0
  • 소마구나
    50
    2019-03-18 12:51:09

    좋은 글 감사합니다. C 서버 개발하면서 왜 디자인패턴이나 리팩토링얘기가 잘 안나오는지 궁금했었는데 궁금증이 풀렸네요.

    0
  • lelumiere
    57
    2019-03-18 16:58:44 작성 2019-03-18 16:59:48 수정됨

    fender 님 글을보고 댓글을 적지 않을수가 없습니다.

    처음부터 끝까지 정말 공감되는 내용이여서 몇 번이고 읽은 것 같습니다.

    학부를 졸업하고 첫 실무 하면서, 1~2년 동안 저를 정말 힘들게 했던 고민들이 그대로 적혀있는 것 같습니다.

    "실무에서 어떤 분야를 택하느냐에 따라 대학에서 배운 어떤 내용은 필수 지식이 되지만 다른 지식은 '알면 좋은' 수준의 교양 지식이 되는 것입니다."

    이라는 결론을 스스로 내리기까지 많은 시간을 허비했었습니다. 

    어느 분야든 마찬가지겠지만, IT라는 분야가 너무 방대하기 때문에

    본인의 위치와 나아가야할 방향을 파악하는 것과, 타인의 입장에서 생각하기란 정말 힘든 것 같습니다.

    그리고 

    "예를들어 스프링 프레임워크의 구조를 이해하고 싶다면 필요한 것은 소스를 내려받아 한 줄 한 줄 분석하는 것이 아니라, API 수준에서 클래스의 계층구조나 메서드의 시그네쳐를 보고 동작이나 의도를 이해하는 것입니다."

    에서 한 번 더 배워갑니다.

    좋은 글 감사합니다.

    그리고 저는 얼마나 더 경험과 지식이 쌓여야 본인의 생각을 이렇게 글로 녹여낼 수 있을지.. 부럽습니다

    2
  • 원숭이부대
    683
    2019-03-19 00:25:49 작성 2019-03-19 16:39:56 수정됨

    구구절절 옳은 말씀이십니다.


    패턴은 쓸모 없는 것

    패턴은 복잡도를 불필요하게 증가시키기만 하는 것

    패턴은 겉멋충들의 것


    이라는 주장을 피력하는 답답한 사람들이 읽고 정신좀 차렸으면 좋겠습니다.


    실제 주변 SI하는 대다수 동기들이 패턴 뭐하러 공부함?

    이라고 하는 말을 듣고 암에 걸렸는데, 뻰더님  글을 읽고 암이 낫고 있습니다.


    뭔가 제가 추상적으로 생각은 하지만 말을 못하는 것들을 아주 깔끔하게 정리해주셨습니다.

    1
  • 마르세유1
    860
    2019-03-19 09:40:55

    이전 글까지 보고 느낀점은..

    같은 개발자라도 분야나 언어가 다르면 생각하는것도 많이 다르구나...

    low레벨 언어에 가까울수록 pattern, refactoring 보다 속도나 알고리즘을 중요시하는것 같고

    high레벨 언어에 가까울수록 속도, 알고리즘보다 pattern, refactoring 같은 유지보수에 필수적인 것들을 중요시 하는것 같고..



    2
  • sm&si
    2k
    2019-03-20 09:57:18

    좋은글 감사합니다.


    최근에  학교 때 배운 C언어와 운영체제를 다시 공부를 했습니다.

    그리고, 그 이론은 지금 내가 하고 있는 java를 이해하는데 많은 도움이 되었습니다.


    하지만, 공부를 했다고 해서 그걸로 뭔가 만들 수준은 안됩니다.

    가끔, 공부한걸 써먹지 못하면 쓸데없는 짓이라고 생각하는 분들이 있는데요.

    교양은 교양으로 공부할 뿐, 전공을 이해하는데 도움이 되었으면 충분한겁니다.


    전공과목과 교양과목을 확실히 구분하고, 그에 맞게 공부하는게 좋을것 같습니다.

    물리학과와 수학과가 서로 잘났다고 싸울 이유가 있나요.

    비슷해 보여도 각자의 분야가 있는건데요.




    -1
  • 라이언킹
    61
    2019-03-20 13:09:42 작성 2019-03-20 14:31:55 수정됨

    참으로 좋은 글을 써주셔서 감사합니다. 

    개인적으로 fender 님께서 쓰시는 글은 유심히 보고, 꼼꼼히 읽고 있습니다.


    저는 전직장에서는 임베디드 환경에서 C로, 지금은 C#으로 개발을 하고 있습니다.

    원글의 분류대로 하면 저수준 언어와 고수준 언어를 모두 업무로 경험을 한것인데

    개인적으로는 저에게는 저수준 언어의 개발 경험은 큰 도움이 되었습니다. 




    글의 모든 내용이 다 공감되고, 동의 되는 내용인데,

    저랑 생각이 다른 부분이 있어서 댓글을 쓰게 되었습니다.

    그리고 만일 본인이 선택한 분야가 자바나 C#, 또는 프론트엔드 개발자라면 컴퓨터 구조나 운영체제 같은 분야는 반드시 알아야 하는 지식이 아니라 알면 좋은 교양 지식으로 분류할 수 있습니다.

    개발자는 운영체제, 자료구조, 알고리즘은 알면 좋은 교양지식이라기 보다는 꼭 알아야 하는 지식이라고 생각합니다.

    예를 들자면 자동차의 엔진과 중요한 요소라고 생각 됩니다. 개발 및 운영의다양한 문제와 원인을 찾는 과정에서 필요한 기반지식(기초체력)이 되기 때문에 주기적으로 반복해서 생각하고, 학습해야 한다고 생각합니다. 


    맺어주신 결론에 대해 매우 공감합니다.

    정리하면, 모든 공부는 다 유익한 것이지만, 어떤 공부를 먼저하고 얼마나 비중을 둘 것인지는 분야에 따라 다르다는 것이 핵심입니다. 특히 비전공자로 출발해서 회사 업무에 치이는 와중에 짬을 내서 공부를 하는 입장이라면 더욱 그 시간을 본인의 실력을 향상 시키는데 직접 연관이 있는 방향으로 집중하는 것이 중요할 것입니다.


    결론에 제 의견을 조금 첨언하자면,

    저는 본인 업무에 직접 연관 있는 부분을 75% 공부하면서 업무 능력을 향상 시키고, 

    남는 25% 가량은 운영체제, 자료구조, 알고리즘을 먼저 공부하면서

    원글에서 언급한 교양적인 부분을 공부 하면서 외연을 넓게 가지고 가면 어떻까 싶습니다. 


    다시 한번 좋은 글을 남겨주셔서 감사합니다.

    제 생각은 이러한데, fender님의 의견이 듣고 싶습니다. 

    2
  • 로직X
    408
    2019-03-20 13:19:11
    와.. 진짜 너무 좋은글입니다. 공감하고 갑니다.
    0
  • fender
    14k
    2019-03-20 16:15:23

    라이언킹 // 의견 감사드립니다. 말씀하신 내용에 대한 제 생각을 요청하신 부분에 대해서 간략하게 정리해볼까 합니다.

    저는 우선 자료구조는 특별히 저수준 지식이라고 생각하지는 않고, 말씀하신 내용 중에서는 가장 분야와 상관없는 기본기에 가까운 내용이라고 봅니다. 다만, 자료구조를 반드시 C 같은 언어로 배워야 한다거나 아니면 C로 구현시 메모리에 대한 내용을 세세하게 이해하는 것은 고수준 개발자에게 우선 순위가 높은 필수 지식이라고 보지는 않는 정도입니다.

    예컨대 자바 개발자라면 적어도 일반적으로 많이 사용하는 자료 구조의 종류와 특성 등을 익히는 부분까지는 필수적이지만, 그 다음으로 필요한 내용이라면 그런 내부 구현의 디테일보다는 예컨대 자바 컬렉션 API의 구성이나, ArrayListRandomAccess인터페이스를 구현하지만 LinkedList는 그렇지 않은 이유 등을 이해하는 것이 우선이 아닐까 싶습니다.

    반면 알고리즘의 경우 어느 정도까지는 자바 개발자도 배워두면 유용한 지식에 속한다는데는 이견이 없지만 적어도 객체지향 패러다임이나 리팩터링 등을 제쳐놓고 먼저 공부해야할 내용은 아니라고 생각하고, 운영체제 같은 부분은 그런 고수준 언어를 주력으로 한다면 교양지식에 더 가깝다고 생각합니다.

    한 가지 라이언킹님과 저의 시각이 다른 부분은, 라이언킹님의 경우 알고리즘, 운영체제 등을 제외한 본문에 언급한 내용을 업무 능력 향상을 위한 응용 기술에 가까운 것으로 말씀하시는 내용입니다.

    제 생각에 리팩터링이나 디자인 패턴 등 제가 언급한 내용들은 고수준 분야에서는 응용 지식이나 도메인 지식이 아닌 기반 지식으로 분류해야 한다고 봅니다.

    알고리즘이 근본이고 리팩터링이나 디자인 패턴이 응용이라기 보단, 전자가 주로 구문 단위의 문제 해결 방법을 다룬다면 후자는 보통 구조 측면의 해법을 다루는 계층상의 차이가 있을 뿐이라고 봅니다. 그렇게 보면 자바나 C# 같은 고수준 언어를 주력으로 하는 개발자가 - SQL으로 모든 업무가 끝나는 SI 환경을 잠깐 잊어 버리고 이야기한다면 - 더 흔하게 접하는 건 후자의 경우이기 때문에, 적어도 그런 수준의 공부를 후순위로 미루어선 안된다고 생각할 뿐입니다.

    그리고 고수준 언어와 관련된 내용도 파고 들면 이론적 기반이 필요한 분야는 얼마든지 있습니다. 예를들어 함수형 언어를 주력으로 한다면 컴퓨터 구조에 대한 지식이 더 중요한 기반 지식이될지, 혹은 카테고리 이론 같은 것이 더 그런 성격에 가까울지는 명백하다고 생각합니다.

    0
  • 마니
    977
    2019-03-20 16:30:12

    이맛에 옥히합니당

    0
  • 라이언킹
    61
    2019-03-20 17:28:22 작성 2019-03-20 17:30:19 수정됨

    fender 님

    부족한 제 생각에 상세히 의견 주셔서 감사합니다.


    리팩터링과 디자인 패턴에 대해 다시 한번 생각하게 되었습니다. 

    언급되었던 키워드들은 선후 관계라기 보다는 계층의 차이라는 표현이  맞는것 같습니다.

    제가 간과했던 부분에 대해 생각하게 되었습니다.

    덕분에 배웠습니다. 


    감사합니다.

    0
  • 무명소졸
    5k
    2019-03-20 21:37:35

    소중한 식견이 담겨있는 장문의 글

    감사합니다.

    0
  • 연호파파
    1k
    2019-03-21 17:19:50

    좋은 내용이네요. 공감되어 추천 드립니다.

    0
  • linuxer
    1k
    2019-03-22 13:14:44

    fender님께 // 좋은 글 감사합니다

    yua111님께 //님도  C++ 전문가로 알고있습니다.

    님 의견도 듣고 싶습니다.

    글좀 써주세요^^

    0
  • sam works
    17
    2019-03-22 16:23:13

    저도 글쓴분의 생각에 상당히 공감을 합니다.


    제 개인적인 사견과 경험에는 두가지 부류가있어요

    첫번째 내가 코딩한 프로그램이 특정 머신에서만 도는 것.  기껏해야 디비왔다갔다 경우,

    두번째 내가 코딩한 애플리케이션 여러개가 어떤건 우분투/톰캣 어떤건 AIX/ nodejs,  어떤건 aws s3식으로 연계되며 클라우드 서비스를 구성하고 만드는 경우.


    첫번째 경우의 어플리케이션은 당연히 상태가 있을 것이고 (무상태로 왜 어렵게 디비를 쓰는가 주고받는 통신속도도 아깝다! ),

    내 시스템의 os는 항상 변하지 않고  이 시스템의 장치(파일시스템이나 네트워크)도 변하지 않는 환경에서 프로그램도 동기식인 경우 (넌블럭킹으로 비동기 C/C++하는 분들 진짜 진심 리스펙! )

    그냥 이거들어오면 스위치에 불들어오고 저거 나오면 이거 돌리고  이런 작업을 효율적으로 정확하게 빠르게 잘 해내느냐에 관심이 있기때문에 http 보다는 그냥 tcp소켓으로 첫번째 비트는 뭐고 두번째 부터 일곱번째 비트는 뭐로 해주세요  가 편한 분들 

    뭔가 연동한다고 전문 정의한거 변수명만 딱봐도 느낌이 오는 그런 시스템

    윈도우만 되고 맥은 안되고,  리눅스는 되는데 윈도우는 안되고;;  느낌


    이쪽 개발자는 자료구조나 소팅알고리즘 같은 것을 잘 알고 계실 확률이 높고 뭐 세마포어나 IPC 정도 읊어주시고! 

    다만;  데이터가  천만건 억건 넘어가면 아마도 손사래를... 치실 확률이 높다고 봅니다.  뭐 SAN을 사야해요 천만원 주세요  랩을 1000기가 꽂아야합니다. (조크입니다) 


    뭐 누가 잘하냐 못하냐 옳은거냐 그른거냐 는 아닌 문제라고 보구요.


    다 개발자이지만 어떤 문제를 많이 접해봤는가? 에 따른 분류라고 생각해요.  그리고 다 필요하구요.


    뭔가 개발자가 예전에는 한분야였는데 이제 전문직종으로 점점 세분화되어서 테크트리가 분화하는 것 같습니다. 


    결론은 함수형하세요 좋아요;  이제 객체지향 그만합시다.  ㅠㅜ 
    그렇게 해도 현업에서 보면 제대로 하는데가 없어.  스프링으로 강제하면 뭐하노... 오히려 그냥 절차형으로 짬뽕되어있으면 한 소스파일에 있어서 보기나 쉽지 ㅋㅋㅋㅋ 
    (객체지향 제대로 공부해서 쓰자는 말입니다...) 
     

    0
  • aselius
    9
    2019-03-23 09:04:50

    와.. 글 정말 잘 쓰시네요. 읽기도 쉽고 구절구절 끄덕거리며 읽었습니다. 좋은 글 잘 보고 갑니다.

    0
  • skyfox83
    25
    2019-03-26 09:30:02

    좋은 글과 토론 내용 잘 읽었습니다.

    요즘 많은 고민이 있었는데 어느정도 답은 되었던것 같습니다. m(_ _)m

    0
  • 초밥석션
    18
    2019-04-12 00:51:02

    제가 지금까지 헤매고 있었다는 사실을 깨달았어요.

    0
  • yadameda
    170
    2019-04-12 10:57:08

    잘 읽었습니다. 내용도 내용이지만 글을 진짜 명료하게 잘 쓰시네요.

    0
  • valencia
    22
    2019-04-12 13:48:34 작성 2019-04-14 00:23:19 수정됨

    본문 글과 댓글 까지 다 읽어 봤습니다.


    모든 글들은 .. 저와 비슷하게 입문, 이론,필드 지금의 경력에서 느꼇던것을.. 마치 제가 쓴것처럼

    공감이 가는것도 있었고, '이렇게도 생각하시는 분도 있구나' 라고 느낀글도 있었습니다.


    '개인적인' 결론은 이론(프레임워크, 패턴,리팩토링) 과 실전(필드 경험)은

    출밤점이 각기 다르기에 , 어느 한쪽에 치우쳐 지지 않고, 적절하게 배합 되어야 합니다.

    (이 댓글 또한, 사람 생각이 각기 다르기에 , 그래서  '개인적'이란 어휘를 강조 합니다.)


    이론은 실전에 쌓은 경험을 가지고, 다음(?)을 위한..지렛되역활 하는것 이라고 생각됩니다.

    다음이란 개발자로써 자기가 생각하는 이상적인 목표라고 생각됩니다. 


    실전은 자기가 공부한 이론과지식이 필드에서 어떻게 적용되나 인것 같으며, 이것은 케바케 이듯,

    필드에서 자기가 아는 범위(이론, 지식)이라면,  응용을 통해 차츰 더 견고 해지거나..

    필드에서 자기가 몰랏던, 생소한 것이라면, 이런것도 있고.. 점차 이것에 대해 적응과 공부를 하게됩니다.


    이론과 실전은 결국 지식과경험이 네트워크가 되어 다음을 위한, 아니면 본문에서 표현했듯이

    벽을 뚫기 위한.. 즉, 더 나은 개발자가 되기 위한것이라 생각됩니다.


    그리고 이것은 주어진 상황에 따라, 자기 철학에 따라, 변모될것 같습니다.

    0
  • zicar
    2
    2019-04-13 21:51:29

    잘봤습니다.

    0
  • dongwoo00
    183
    2019-07-07 01:25:51 작성 2019-07-07 01:27:16 수정됨

    C++ / C# 을 각각 4년씩 실무에서 사용한 개발자입니다. 글 잘 읽었습니다. 이런 장문의 글에 저와 이견이 하나도 없다는게 신기하네요. 저의 평소생각과 100% 일치합니다. 단 저는 이런 생각들을 fender님처럼 글로 풀어내는 능력은 없습니다...^^;

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