엔지니어의꿈
900
2021-07-26 17:18:48
18
4366

프론트엔드 개발자를 지망하시는 분들을 위한 가이드라인 및 팁


OKKY를 하며 생각 외로 많은 분들이 프론트엔드 개발자가 되시기를 원하는 것을 알게 되어 놀랐습니다. 몇 년 전 제가 처음 프로그래밍을 배울 때만 해도 프론트엔드 개발자의 위상은 그리 대단하지 않았습니다. 저의 경우 처음 프로그래밍을 배울 때 프론트엔드 개발자가 될 것이라 상상도 하지 못했습니다. 프론트엔드를 잘 몰라 편견에 대단치 않은 일로 생각했기 때문입니다. 결론적으로 저의 어린 생각은 틀렸고 지금은 프론트엔드 개발자로 Vue.js를 이용해 개발을 하고 있습니다. 몇몇 분들의 포트폴리오를 리뷰하며 적절한 가이드라인이 있다면 이분들에게 큰 도움이 될 것이라 생각하여 몇 가지 생각을 나누어 보려고 합니다. 비록 신입이라 대단한 경험이나 경력을 가진 것은 아니나 프론트엔드 개발자를 지망하시는 분들에게 도움이 되었으면 합니다. 


1. 나무보단 먼저 숲을 보자.


프론트엔드 공부를 시작하시는 분들은 생각 외로 배워야 할 내용이 많아 어떻게 시작해야 할지 혼란스러울지 모릅니다. 이 때 아무 생각 없이 배우는 것보다는 전체적인 프론트엔드 기술의 맥략을 먼저 공부하는 것을 추천합니다. 가장 쉬운 방법은 웹 기술의 발전사를 공부하는 것입니다. 이를 통해 웹 기술이 어떻게 발전했으면 어떠한 이유로 표준이 나왔고 어떠한 이유로 특정 기술이나 프레임워크가 널리 사용되는지 알 수 있습니다. 이렇나 전체적인 맥략을 잘 이해한다면 학습의 방향이나 목적 혹은 범위를 쉽게 정할 수 있습니다. 또한 기술 스텍을 보고 취업할 회사를 평가할 기본적인 안목을 기르게 됩니다.


2. 기초를 튼튼히 하기. HTML, CSS 그리고 JavaScript부터 공부한 후 프레임워크나 라이브러리 공부하자.


이 부분은 사람마다 의견이 달라서 프레임워크 부터 공부해도 문제 없다는 분들이 있습니다만 경험적으로 볼 때 추천드리지 않습니다. 기초가 부족하면 나중에도 같은 문제로 계속 시달리게 됩니다. 예를 들어, CSS의 기초가 부족한 분들이 SASS나 Styled Components를 배워도 기초 CSS가 안되서 디자인 스텍대로 구현을 못하는 경력자 분들이 꽤 많습니다. 기초가 없는 상태로 시간에 쫓겨 필요에 따라 배우다 보면 결국 단편적인 이해만 가지고 있어 같은 문제를 해결하기 위해 더 많은 시간을 투자하거나 지엽적인 코드를 짜는 경우가 많습니다. 반대로 기초를 튼튼하면 그러한 문제를 겪지 않고 더 좋은 코드를 짤 수 있게 됩니다. 예를 들어, 박스 모델이나 레이아웃을 제대로 이해하지 못한 분들은 배열을 하려고 padding이나 margin을 각 components 마다 넣어 수정하기 어렵고 번거러운 코드를 짜는 반면 기본이 튼튼한 분들은 구조를 잘 만들어 더 적고 깔끔하고 고치기 쉬운 코드를 만드는 경향이 있습니다. 만약 무엇이 기초인지 잘 모르시겠다면 유명 강의나 기초 강의 등을 수강하시거나 목차를 참조하시기 바랍니다.


3. 어떤 UI 프레임워크를 공부하는지는 크게 중요하지 않다. 자기가 좋아하는 것부터 혹은 쉬운 것부터 배우는게 좋다. 하나를 잘 하면 다른 것도 잘 수 있다.


저는 프론테엔드 코딩을 배울 때 React.js로 시작했습니다만 회사에서는 Vue.js를 사용하여 Vue.js를 새로 배워야 했습니다. 둘이 닮은 점이 매우 많기 때문에 React.js에서 Vue.js로 적응하는데 1주일도 걸리지 않았습니다. 마찬가지로 Vue.js를 잘 이해하고 있다면 React.js도 쉽게 배울 수 있습니다. 개인적으로 처음 배우시는 분들이라면 Vue.js를 추천드리고 싶습니다. React.js보다 잘 구조화 되어 있고 배우기 쉽기 때문입니다. 그러나 React.js 배워도 좋습니다. 결국 경쟁하는 기술들은 서로를 모방하여 수렴 진화하기 때문입니다. 


4. 개인 프로젝트 진행하기.


많은 분들이 그룹 프로젝트를 진행하시는데 이력서에 제출할 포트폴리오가 아닌 실력을 향상시키시고 싶다면 혼자서 프로젝트를 해보시기 바랍니다. 프론트엔드 개발자라도 결국 백엔드를 알아야 일하기 쉽습니다. 더불어 혼자서 전체 서비스를 구현해야 웹이 어떻게 움직이는지에 대한 대략적인 감이 생깁니다. 

어떤 분들은 자기보다 잘하는 사람에게 배울 수 있다고 하시는데 취업하시면 진짜 잘하는 분들에게 제대로 피드백을 받을 수 있습니다. 냉정하게 말해서 어중이 떠중이들 끼리 서로 조언을 한다고 제대로 된 조언이 나오지도 않을 뿐더로 시간만 낭비할 뿐입니다. 만약 강제성이 있어야만 프로젝트를 할 수 있는 분들이라면 프로그래밍과 적성이 맞지 않을 가능성이 높습니다. 이런 분들은 결국 취업을 해도 힘들어 하는 경우가 많습니다.


5. 순수 CSS로 프로젝트 구현해보기.


많은 분들이 부트스트랩 등의 CSS framework 등으로 개인 프로젝트를 하시는데 개인적으로 프론트엔드 개발자라면 순수 CSS로 개인 프로젝트를 진행해야 한다고 생각합니다. 왜냐면 이를 통해서 CSS가 어떻게 적용되고 사용되지는에 대한 이해를 얻기 때문입니다. 이를 잘 이해하면 CSS framework를 수정해서 사용할 때도 빠르게 수정할 수 있습니다. 반대로 CSS framework만 사용하신 분들은 막상 응용을 하거나 프레임워크 없이 구현할 때 고생을 하는 분들이 많습니다. 


6. ESLint 사용하기.


ESLint 플러그인만 잘 사용해도 초보자들이 하는 웬만한 실수는 다 필할 수 있습니다. Airbnb 플러그인이나 Vue 플로그인 등의 다양한 플로그인들은 best pratice를 추천하거나 anti pattern을 피할 수 있게 하고 자잘한 실수를 막을 수 있습니다. Var를 쓴다던지 쓸데 없이 let을 쓰거나 잘못된 formatting을 피할 수 있게 됩니다. 


7. 꾸준히 프로그래밍 관련 글을 읽기.


블로그나 커뮤니티에는 다양한 정보나 조언들이 지속적으로 올라오며 이를 통해 업계의 트렌드 뿐만 아니라 전반전인 프로그래밍에 이해를 높일 수 있습니다. 다른 개발자와의 정보 교류는 개발자에게 필수 소양 중 하나라고 생각합니다. 따라서 꾸준히 개발 동향 관련 글을 읽는 것을 습관화 하는 것이 필수입니다.


8. 기초적인 자료 구조와 알고리즘을 배우자.


여러분 중 거의 대다수의 분들은 개발을 하며 평생 직접 자류 구조를 구현하거나 알고리즘을 구현할 일이 없이 없을지도 모릅니다. 그러나 이를 배우는 것이 중요한 이유는 단순히 코딩 인터뷰를 통과하기 위해서가 아니라 좋은 코드를 작성하기 위해서 입니다. 예를 들어, Hash map을 알고 있다면 Array가 아닌 Object나 Map을 활용해 시간복잡도를 n에서 1로 줄이거나 n^2를 n으로 줄이는 일도 가능합니다. 더불어 어떤 상황에서 어떤 문제를 해결해야 하는지에 대한 감이 생깁니다. 이를 모르는 분들은 필연적으로 나쁜 코드를 작성할 가능성이 높습니다.


9. 읽기 좋은 코드를 작성하자.


프론트엔드에서 자료 구조와 알고리즘을 잘 공부해도 퍼퍼먼스적 차이를 제대로 이해 못한다면 잘못된 코드를 작성하기 쉽습니다. 예를 들어, for loop를 사용하는 것이 Array function을 사용하는 것보다 성능상은 빠르지만 유저은 거의 체감이 불가능합니다. 반대로 가동성은 떨어져 나쁜 코드가 탄생하게 됩니다. 따라서 3D 그래픽을 처리하는 등의 높은 최적화가 (이 경우 일반적으로 Web Assembly를 사용해 C++로 작상해야 할테지만) 반드시 필요한게 아니라면  Array functions을 사용하는게 코드 가독성을 위해 도움이 됩니다. 


10. 함수형 프로그래밍 공부하기.


프론트엔드는 백엔드나 다른 분야와 다른 개발 철학을 가지고 있습니다. JavaScript라는 언어가 가진 태생적 한계나 특징 때문입니다. 그리고 OOP (Object Oriented Programming)가 아닌 FP (Functional Programming)가 오랜 시간동안 개발의 패러다임으로 자리 잡아왔습니다. 웹이 발전함에 따라 OOP의 출신의 많은 개발자들이 웹으로 이주하며 OOP style을 TypeScript 등을 통해 도입하려는 시도가 있어왔고 TypeScript가 점차 새로운 개발 표준으로 자리잡고 있지만 그럼에도 FP의 중요성은 사라지지 않습니다.


처음 C++로 프로그래밍을 배웠고 Java와 C#을 좋아해 TypeScript를 통한 OOP 스타일로 좋아하지만 현재 개발 환경에서 TypeScript 없이 순수 JavaScript를 사용하여 FP 스타일로 개발하지만 OOP나 정적 타입 시스템이 필요하다고 느낀 적은 거의 없습니다. 또 실제 개발에서 사용되는 FP가 매우 높은 수준의 High order function, curry, composition 등을 사용할 필요도 그렇게 많지 않습니다. 대부분의 경우 side effect를 잘 이해하고 immutable과 mutation이 필요한 경우와 방법 수준으로도 높은 퀄리티의 코드를 작성할 수 있습니다. 반대로 이러한 이해 없이 OOP 스타일로만 접근하시는 분들은 프론트에서 나쁜 스타일의 코드를 짤 가능성이 있습니다. 따라서 함수형 프로그래밍을 어느 정도 공부하시는 것을 추천합니다.


함수형이 왜 좋자면 배열을 예로 들어 생각해 봅시다. 특정 조건에서 배열형의 값을 바꿀 때 함수형을 모른다면 직접 배열에 인덱스를 이용해 접근해 변경할 가능성이 높습니다. 이 때 배열의 값이 달라진다면 이러한 코드는 쉽사리 문제를 일으킵니다. 그런데 배열을 직접 수정하는 대신 함수형을 사용하면 어떨까요? 함수형을 사용하면 값을 변경할 때 배열 그 자체를 변경하는게 아니라 배열을 복사한 후 필요한 부분 많은 변경합니다. 변경하는 방식도 직접적으로 값을 바꾸는게 아닌 조건에 따라 값을 바꾸어 직접 값을 변경함으로 생길 수 있는 문제를 애초 차단합니다. 


막상 좋은 예가 생각나지 않은데 나중에 시간이 되면 좋은 예를 업데이트 하겠습니다.


11. 테스트 코드 작성하기.


테스트 코드를 작성하면 코드를 변경해야 하거나 새로운 기능을 추가할 때 발생하는 실수를 줄일 수 있습니다. 프론트엔드의 유닛 테스트는 벡엔드보다 약간 더 번거러운데 모든 것을 테스트하는게 아닌 유저와 UI의 상호작용하는 상황을 테스트 하는게 좋습니다. 예를 들어, 유저가 delete 버튼을 누르면 어떤 이벤트가 발생해서 어떤 컴포넌트와 사용해 어떤 결과를 보여주어야 하는가와 같은 것을 테스트하면 좋습니다. 물론 유닛 테스트만으로 모든 버그나 문제를 감지할 수 있는 것은 아니지만 상당부분 실수를 커버할 수 있습니다. 물론 유닛테스트를 작성해도 실제 테스트는 필수 입니다. 프론트엔드는 머리로만 생각해서 놓칠 수 있는 부분이 꽤 많기 때문입니다.


12.끊임없이 리펙토링하기.


앞서 그룹 프로젝트를 권하지 않은 이유 중 하나는 자신의 코드라는 소유감이 없기 때문에 프로젝트가 끝나면 방치하는 경우가 많기 때문입니다. 그렇게 계속 공부를 하면 성장함에 따라 자신의 이전 코드를 어떻게 개선할 수 있는지 보이기 시작합니다. 많은 프로젝트를 하는 것도 중요하지만 더 중요한 것은 기존의 코드를 개선하여 더 나은 코드를 작성하는 것입니다. 따라서 이미 끝난 프로젝트라도 자신을 키운다는 마음으로 지속적으로 개선하는 애정은 필수 입니다. 


13. OKKY에 질문하지 않고 스스로 찾고 문제해결하는 습관을 기르자.


여러분이 특별한 상황에 있는게 아니라면 여러분이 직면한 대부분의 문제는 코드를 제대로 작성하지 않았거나 기본 컨셉을 제대로 이해하지 못해서 발생할 가능성이 높습니다. 이 경우 자신의 코드를 다시 읽거나 혹은 놓친 개념을 확인함으로 문제를 해결할 수 있습니다. 기본 개념이 부족한 분들이라면 비슷한 문제로 계속 고생을 하실텐데 그렇다면 문제의 해결책은 부족한 개념을 다시 공부하는 것이지 자신의 코드가 왜 작동하지 않는지 커뮤니티에 묻는게 아닙니다. 문제가 생길 때마다 질문을 한다면 이는 실질적인 문제 해결능력은 그대로인채 단편적인 지식만 늘어날 것 입니다. 그리고 다른 문제를 만나도 스스로 해결할 수 능력이 없어 다시 묻게되는 악순환을 반복할 것입니다. 더불어 직장에 취업하기 전에 여러분이 직면한 거의 99%의 문제는 구글링을 통해 해결이 가능한 문제입니다. 만약 답변을 찾을 수 없다면 영어 실력이 부족하거나 검색 능력이 부족한 것입니다. 좋은 개발자가 되기 위해서는 어느 하나도 부족하면 안됩니다. 


작성하도 보니 상당히 길어졌습니다. 저도 신입이라 제가 가진 의견이 틀릴 수도 있고 경험이 쌓이고 시간이 지나 바낄 수 있으나 가이드라인이란 점에서 이해하고 보신다면 좋을 것 같습니다. 이 글이 조금이라도 도움이되어 원하는 곳에서 프론트엔드 개발자로 일하시길 바랍니다.


32
45
  • 댓글 18

  • moonti
    4k
    2021-07-26 19:02:31 작성 2021-07-26 19:03:35 수정됨

    넘나 좋은 글입니다 . 추가적으로 

    html도 시멘틱한 의미와 다루는 것들을 시간잡고 공부하시는게 .. 태그는 이제 거의 안 늘어나기 때문에 있는 거 잘 공부해두면 계속 그 개념은 사용합니다..

  • return true
    3k
    2021-07-26 20:53:09 작성 2021-07-26 20:59:37 수정됨

    "프론트엔드는 백엔드나 다른 분야와 다른 개발 철학을 가지고 있습니다. JavaScript라는 언어가 가진 태생적 한계나 특징 때문입니다. 그리고 OOP (Object Oriented Programming)가 아닌 FP (Functional Programming)가 오랜 시간동안 개발의 패러다임으로 자리 잡아왔습니다. "


    이 부분에서 함수형 프로그래밍과 절차지향 프로그래밍을 헷깔리신거 같네요.

    백엔드에서도 역시 함수형 프로그래밍을 경험할 수 있고 그러한 언어들도 많이 등장했죠. 자바에서도 대표적으로 Stream과 Optional을 사용하는게 예시가 될 수 있겠네요.

    그리고 함수형 프로그래밍이 오랜시간동안 개발의 패러다임으로 자리잡았다고 했는데 이는 절차지향을 말하는듯 하네요.

  • 프로그램 탐험가
    283
    2021-07-26 23:03:21

    프론트엔드 취준생인데 좋은 글 감사합니다 :)

  • 엔지니어의꿈
    900
    2021-07-27 13:34:22

    return true 절차형 프로그래밍과 함수형 프로그래밍을 착각한게 아닙니다. JS는 OOP 기반이 아닌 ProtoType기반이라 OOP를 구현하는데 여러 가지 제약이 있었습니다. 제가 의미하는 바는 프론트엔드는 OOP를 제대로 사용할 수 없었기에 함수형으로 개발하는 방법론이 성장했다는 말입니다. 물론 최근 언어들은 멀티 패러다임 언어라 이러한 구별이 무의미 하지만요. JS에 함수형 프로그래밍은 꽤 오랜 역사를 가지고 있습니다. 

  • moonti
    4k
    2021-07-27 15:43:26

    js는 oop를 완전히 사용할수 없다는 말은 틀린 것에 가깝고요 클래스보다 익숙하지 않는 형태여서 글쳐 ..

  • return true
    3k
    2021-07-27 16:02:45

    아 js에서는 그렇게 볼 수 있긴 하죠.

    근데 본문에 typescript가 객체지향을 하기 위한것이라는듯이 적혀있고 함수형과 대치되는 개념으로 적어놓으셨길래

    잘못 이해하신줄.

    typescript는 객체지향을 위해 나타난게 아니죠. 그걸 쓴다고 함수형프로그래밍을 못하게 되는것도 아니구요.

    타입스크립트는 협업 시 가독성을 높이고 오류를 줄이고 변수/함수의 잘못된 사용에 대한 풍부한 피드백을 통해 생산성향상에 의의가 있다고 봐야죠

  • 엔지니어의꿈
    900
    2021-07-27 23:38:53

    return true

    일단, 지금 글에서 명시적으로 언급한게 아니라면 해석할 때 암묵적 가정을 하지 않으시는게 좋습니다. 토론이 아닌 간단한 가이드라인에 해당하는 글이기에 풍부한 Context를 제공할 수 없고 부족한 Context를 암묵적 가정을 통해 해석을 하면 전혀 다른 내용으로 오독될 수 있기 때문입니다. 


    함수형 프로그래밍과 객체지향형 프로그래밍의 비교는 논란이 많은 주제이며 전문가들 사이에서도 의견이 달라지기 때문에 별도 언급을 하지 않겠습니다. 


    그리고 TypeScript에 관한 말씀은 절반의 진실이라고 생각합니다. TypeScript의 기반되는 되는 언어가 무엇이며 어떤 회사에서 누구의 주도로 개발을 했는지 생각한다면 그리고 TypeScript를 활용하는 Angular의 철학이나 Angular를 주로 이용하는 개발자들의 주류가 .Net 개발자라는 것을 생각한다면 타입스크립트와 OOP를 분리해서 생각하는 것은 어렵습니다. 실제 Node.js로 작성된 백엔드 코드만 살펴봐도 TypeScript로 작성된 것과 JavaScript로 작성된 코드는 접근 방식이나 아키텍처에 큰 차이가 있습니다. 물론 TypeScript가 함수형 프로그래밍을 지원하지 않거나 잘 맞지 않다고 오독하시면 곤란합니다. 다만, 함수형 프로그래밍 커뮤니티 내에서도 정적 타입에 대한 다양한 의견이 있다는 것을 아셨으면 합니다. 


    다만, 참고하실 점은 저는 북미에서 개발자로 활동하고 있으며 따라서 개발 환경이나 문화적 측면에서 한국의 개발 환경과 다소 차이가 날 수 있음을 염두해 두시기 바랍니다. 예를 들어, 북미에서는 데스크탑 어플리케이션을 개발하던 닷넷 개발자들이 Angular 등으로 넘어간 경우가 많고 OOP적 관점에서 TypeScript를 사용하고 OOP의 design patterns을 사용하는 경우가 많은 반면 적어도 한국에서 비슷한 기류가 있었는지는 잘 알지 못합니다. 아무튼 이러한 이유로 처음부터 JS를 함수형으로 접근하던 기존 JS 개발자들과 OOP 진영에서 넘어온 개발자 커뮤니티 간의 의견 대립이 있습니다. 이런 역사적 문화적 배경을 거세한 채 원론적인 이야기만 한다면 현실과 동떨어진 담론이 되지 않을까 생각합니다.



  • 엔지니어의꿈
    900
    2021-07-27 23:52:50

    moonti 

    JavaScript는 Prototype 기반에 Dynamic Type 언어라 본래 제대로 OOP를 지원하지 못했습니다. ES6의 class syntax는 syntax sugar이며 JavaScript Good parts의 저자 Douglas Crockford의 경우 class syntax를 사용하지 말자고 주장하기도 합니다. 단순한 일례로 접근 권한을 제약하기 위해 private을 만드는 일이 얼마나 어려운지 생각해 볼 필요가 있습니다. 최근에야 WeakMap을 통해 진정한 의미의 private을 구현하는게 가능했으며 그 이전까지 Closure을 통해 흉내를 내는 수준이었습니다. 아직도 # 키워드를 지원하지 않는 환경이 얼마나 많은지도 생각해볼 일이죠. OOP를 언급할 때 OOP와 함께 OOP의 Design pattern도 함께 언급됩니다. 그리고 OOP의 전통적인 Design pattern을 JS에 어떻게 구현해볼지 시도해보신 분들이라면 한 번 쯤 어떻게 구현을 할 것인지 고민을 해보셨을 것입니다. Interface가 없는 JS에서 어떻게 strategy 패턴을 구현할 건가와 같은 단순한 것부터 좀 더 복잡한 패턴까지 말이죠. 그래서 JS로 OOP를 부분적으로 흉내내던가 JS Style로 구현할 수 있다는 말은 맞지만 JS가 OOP를 완전히 혹은 완벽히 지원할 수 있다는 말은 틀린 주장에 가깝습니다. 


  • 마라토집착
    5k
    2021-07-28 00:18:44

    엄청나게 좋은글입니다 ㅎ  존경 ㅋ 

  • return true
    3k
    2021-07-28 08:04:09 작성 2021-07-28 08:04:32 수정됨

    북미에 계시는군요 

    글 잘 읽었고

    화이팅하세요

  • 궁예
    36
    2021-07-28 16:29:57

    좋은글감사합니다

  • ISA
    5k
    2021-07-29 09:42:29

    죄송한데 oop의 한종류가 프로토타입 기반 입니다.

    Js가 oop를 완전히 지원하지 않았다는건 잘못된 정보입니다.

    애초에 js는 처음부터 멀티 패러다임 언어 였습니다. 클래스 지원이 완전하지 않다는 말은 맞지만요.

    프론트엔드에서 함수형이 최근에 주가 되는 요인도 js의 언어적 한계가 아닙니다. 함수형 프로그래밍의 패러다임이 말하는 개념들이 view를 그리는데 적합하기 때문입니다.

  • ISA
    5k
    2021-07-29 09:44:56

    그래도 기본적으로 좋은 글입니다!

  • 엔지니어의꿈
    900
    2021-07-29 10:33:49

    ISA

    JS가 프로토타입 기반이며 OOP의 한 종류이라고 하신 말씀은 맞는 말씀입니다. 그러나 이렇게 분류한 것은 개념적 분류가 아닌 개발 문화적 분류이기 때문입니다. Java나 C#과 같은 언어의 디자인 패턴과 JS의 디자인 패턴은 엄연한 차이가 있고 이로 인해 일반적으로 말하는 객체지향과 뜻이 달라지기 때문입니다. 이를 개념적으로 JS도 OOP라고 설명했다면 아마 자바나 닷넷 개발자 분들 중 JS는 OOP가 아니라고 주장하는 댓글이 달릴 것입니다. (혹은 반쪽 자리 OOP라거나 혹은 JavaScript는 언어로 논할 가치가 없다는 극단적인 주장도 2021년에도 자주 봅니다.) 실제로 이 주제를 두고 개발자 간의 소모적인 논쟁이 많이 일어나고 이 글의 주제와도 크게 상관 없어 간략화 했습니다. 


    JS가 OOP를 완전히 지원하지 않는다고 주장하지 않았습니다. JS의 OOP 지원이 완벽하진 않다. 달리 말해서 몇몇 OOP의 특성은 불완전하게 지원이 된다는 뜻입니다.


    JS가 단일 패러다임에 프로그래밍 언어라 주장한 적이 없습니다. 물론 뷰를 구현하는데 함수형 프로그래밍 패러다임이 적합하다는 의견에 동의하나 다른 측면에서 일반적인 객체 지향 언어에 발전된 디자인 패턴을 적용하기 힘들다는 점도 있습니다. 


    사실 언어에 대해 논하는 것을 별로 좋아하지 않습니다. 프로그래밍 언어는 특정 개인이나 집단에 의해 개발되지만 많은 경우 커뮤니티의 개발 문화에 따라 발전하기 때문에 언어 자체에 대해 논하는 것은 보통 정말 다양한 관점과 이유 중에서 자기 주장만 옳다고 관철되는 경우로 가기 때문입니다. 


    그래서 저의 경우 모든 의견을 수용할 수 없기 때문에 일반적인 견해나 영향력있는 개발자의 견해를 바탕으로 소개했습니다. 


  • ISA
    5k
    2021-07-29 11:09:39 작성 2021-07-29 11:19:08 수정됨

    그럼 oop라는 말대신 클래스 기반, 프로토 타입 기반이라는 용어를 사용하는게 좀 더 나을거 같습니다.

    Js가 OOP에 대한 지원이 완벽하지 않다는 말은 이 글을 주로 볼 초심자들에게는 부적절한 정보를 줄 수 있다고 생각하네요. OOP의 정의에 대해서 논한다는건 대댓에 다신 개인의 주장을 관철하는거에 가까워 보이구요.

    디자인패턴이라는게 힘들다는 것도 솔직히 조금은 이해가 안갑니다.

    그리고 클래스가 문법 설탕이긴하지만 최신으로 추가 되는 문법에서 기존 기능들이 추가 되고 있습니다.. 아직 실 사용은 어렵지만 #도 추가 되긴했죠.

    완벽하지 않다는게 어느 시점인지에 대해서도 좀 더 추가적인 설명이 있음 좋겠네요.

  • moonti
    4k
    2021-07-29 16:47:07 작성 2021-07-29 16:47:34 수정됨

    댓글 달기 주저 하다가 그래도 달아보겠습니다.
    JS가 OOP를 기반으로 두었다고 말할 수 있는 이유에 대해 이전에 짧은 강의를 본적이 있어서요.


    시간이 되신다면 강의를 한 번 보시는 것을 추천드리고, 짧게 요약을 하겠습니다.

    OOP는 다음의 두 조건을 만족하면 됩니다.

    - 대체 가능성

    - 내적 동질성


    OOP 를 완전히 지원하지 못한다는 것에서 조금 저도 생각에 잠기게 되는데, wiki에 소개된 내용에 보면 c++이 가지는 일반적인 특징들이 OOP의 특징으로 굳혀진 것 같은 느낌을 받았습니다. 그렇게 따지면 js는 꽤나 OOP에 불충분한 언어로 보이긴 합니다.
     뭐 물론 지금은 그것이 꼭 필요하냐, 꼭 따라야 하냐라고 했을 때는 '글쎼' 로 생각해서... js가 OOP에 충실하지 않다는 내용에도 이제 발끈 하지 않으려고요.

    js에서 대체 가능성을 보면, 상속한 객체가 이전의 객체를 완전히 대체할 수 있으면 됩니다.

    var anotherObject = {
    	a: 2
    }
    
    var myObject= Object.create(anotherObject);
    myObject.a   // 2


    내전 동질성

    아무리 확장 되기 전 메소드를 호출해도 나의 본질은 변하지 않는다.

    var parent = {
      action: function() {
        console.log('parent');
      },
      wrap: function() {
        this.action();
      }
    }
    
    var child = Object.create(parent);
    child.action = function() {
      console.log('child');
    }
    
    
    child.action();  // child
    child.wrap();   // child



  • 엔지니어의꿈
    900
    2021-07-29 23:49:19 작성 2021-07-29 23:52:27 수정됨

    moonti ISA 


    각기 좋은 의견 나누어주셔서 감사합니다. 초고 없이 30분도 안되는 시간동안 작성한 글이라 오해의 소지가 있었습니다. 글을 읽을 분들에게 보완적인 정보가 될 것이라 생각합니다. ISA님 지적대로 제 개인적 의견이 혼란을 초래할 가능성이 있습니다. 다만, 글의 목적이나 깊이를 생각하면 우려할 수준은 아니라고 생각합니다. 더불어 JS가 왜 완벽히 OOP를 지원하지 못할까라는 의문을 갖고 생각을 하고 정보를 찾다보면 JS가 가진 객체지향이 어떻게 다른 언어와 다르며 이에 발생하는 한계점 등을 찾아갈 계기를 제공한다고 생각합니다. JS에 관한 언어적 논쟁은 앞서 언급한 것처럼 정확한 답이 없기 때문에 더 이상 논하지 않겠습니다. 


    영상에 대해 언급하자면 나름 타당한 논지라 생각하나 정확히 객체지향이 무엇이냐는 논쟁이 많은 주제입니다. 심지어 자바나 C# 등의 현존하는 객체지향은 제대로 객체지향이 아니라는 주장도 있습니다. 객체 지향의 시발점인 SmallTalk의 개발자는 지금의 OOP가 원래 의도한바와는 상당히 다르다는 것이라고 말하기도 했죠. 객체지향의 아이디어는 세포 간의 커뮤니케이션에서 얻은 것입니다. 세포 간의 상태를 서로 교환하는 방식에 아이디어를 얻은 것인데 내적 상태를 다른 객체에서 접급하여 수정할 수 있는 것 자체가 객체지향의 본래 생각에 부합하지 않는다는 것입니다. 


    개발 문화에서 특정 언어나 프레임워크의 발달은 복잡계에서 발생하는 창발적 현상입니다. 때문에 특정 개념이나 언어나 툴 등은 지속적으로 발전하고 재정의될 수 있습니다. 따라서 엄밀한 의미의 정의를 논하는 것이 큰 의미가 없습니다. 비록 SmallTalk가 객체 지향의 아이디어를 제공했지만 이것이 발전하는 과정에서 지향성이 달라진 것처럼 말이죠.


    따라서 이러한 정의는 개발 문화와 역사에 따라 지속적으로 변화할 수 있습니다. 그러므로 학문적 정의는 매우 추상적이 최소한일 수 밖에 없습니다. 그런 관점에서 영상의 객체 지향의 정의란 그 개인이 경험적으로 체득한 객체지향의 정의이지 보편성을 가진 객체 지향의 정의가 될 수 없다는 것입니다.


    때문에, 자바나 닷넷 개발자들이 가진 객체 지향과 자바스크립트 개발자들이 가진 객체 지향의 생각은 다를 수 밖에 없습니다. 특정 환경에서 특정 언어를 사용하며 축적된 커뮤니티의 내의 지식이나 경험이 판이하게 다르기 때문입니다. 개발자 커뮤니티 내에서 JavaScript와 확장형인 TypeScript를 둘러싼 논쟁 중 상당 부분은 타입 시스템 뿐만 아니라 객체지향과 함께 묶여서 논쟁되는 부분입니다. 다소 극단적이나 이해하기 쉬운 예를 들어보겠습니다. 이동수단이 발단되지 않는 곳에서 차(Vehicle) 의 정의는 바퀴를 지키고 있으며 사람이나 물건 등의 수송을 편의하게 하는 것이라 정의할지 모릅니다. 그러나 매우 발달된 기술 수준을 가진 곳에서는 말이나 사람의 인력으로 움직이는 차의 개념은 사실상 소멸했습니다. 따라서 이곳에서 차의 정의는 바퀴를 가지며 기계적 구조의 동력기관을 가진 것이 될 수 있습니다. 이곳에서 볼 때 말이 끄는 수레는 차의 정의에 부합하지 못한 것이 됩니다. 


    이런 관점에서 볼 때, OOP가 무엇이다라고 OOP가 주제가 아닌 글에 깊이 논할만한 내용은 아니라고 생각합니다. 물론, 다른 이들의 참고 사항은 된다는 점에서 의의가 있다고 생각합니다. 다만, 지엽적이고 종교적인 주제는 끝이 없으므로 그리 권장되는 바는 아니라고 생각합니다. OOP를 논하시고 싶으시다면 이 글의 댓글이 아닌 OOP를 주제로 글을 따로 쓰시는게 더 합리적이라 생각합니다. 

  • 메이플시럽
    6
    2021-08-20 11:01:14 작성 2021-08-20 11:01:57 수정됨

    혹시 댓글알림 가나요? 전글에 남긴건 안가는지 답을 안달아주셔서 여기에 한번 남겨봅니다.. 현재 캐나다에서 sd학과 다니고 있는데 진로문제로 고견 여쭤보려합니다..

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