글

[ Essay - Technology, Essay - Intuition ] Chat GTP시대의 도래와 생각하는 방식에 대해 : 개발자의 미래에 대해

-
이미지
벌써 올해도 반쯤 지나 뜨거운 여름이 다가왔다. 굉장히 빠르게 지나간듯한 느낌이 드는데  아마 의미있는 시간을 보냈다는 이야기이기 때문에  그렇게 나쁜 신호는 아닐 것 이다. 괴로운 시간이였다면, 1초가 1년 같이 느껴졌을테니 말이다. 더위에 매우 약한 나에게 있어서는 지옥과 같은 시기이기도 하지만 늘 그렇던 것 처럼 에어컨 덕분에 어찌저찌 버틸 수 있을 것 같다. 어쨋든, 이번에는 저번의 에세이 주제, Chat GTP시대의 도래와 생각하는 방식에 대한 이야기에 이어서  과연 개발자의 미래는 어떻게 될 것인가에 대해 이야기를 나누어보려고 한다. 어쩌면 모두가 인식하고 있듯이 지금 2025년 현재,  꽤나 중요한 시기에 직면하고 있는지도 모른다. 왜냐하면, 생성AI의 발전 속도가 생각보다 빠르게 발전하고 있고,  그에 따라 실제 업무에서도 빠르게 사용되어지고 있기 때문이다. 이러한 상황에서 개발자에게 있어서 가장 두려운 점은  당연히 생성AI에 의해 개발자가 대체될 것 이라는 두려움일 것 이다. 이는 개발자에게만 한정된 이야기는 아니지만 말이다. 아마 필드에서 나와 같이 일하고 있거나  개발자로서 직업을 가지려는 생각이 있는 사람이라면  한번쯤은 생각해볼법한 주제라 생각 한다. 물론 미래가 정확히 어떻게 될 지는 알 수 없으나  이런 생각을 함으로써 몇 가지 힌트는 얻게 될지도 모르니  만약 얻게 된다면 미래에 대한 방향성을 조금이나마 올바른 쪽으로 돌릴 수 있을 것 이다. 이 글을 끝맽을 때는 조금이라도 힌트에 도달하기를 바란다. 과거의 역사 이러한 의문에 대한 해결책으로서 일반적으로 자주 사용하는 방법이 있다. 바로 역사를 보는 것 이다. 물론 이러한 역사를 해결책을 찾는거에 대한 전제조건은  우리가 '구 인류'라는 전제조건이 있었을 때 의미가 있다. 그러니깐 현대인도 기원전 8세기의 고대 로마인도  본질적으로 다르지 않다는 것을 인정해야만 한다. 예컨데...
자세한 내용 보기

[ Redefinition, 생각 ] 새로운 카테고리를 만들면서

-
이미지
이번에 Redefinition라는 카테고리를 생성 했다. 이유는 사실 지금 까지 작성했던 글들은  이번에 새로 만든 재정의에 가깝기 때문이다. 왜 재정의를 해야만 할까? 결론적으로 말하면, 이 세상이 점점 빠르게 발달하고 실제로 변하고 있기 때문이다. 세상이 빠르게 발달하고 변하고 있다는 것은  패러다임의 변환이 끊임없이 이루어지고 있다는 것이고 이에 따라 기존에 사용되었던 단어에 대한 정의 또한  크고 작던 간에 변하고 있다는 것 이다. 나는 오프라인/디지털로 변하는 그 사이 쯤에 있던 세대 였고 이 사이에서 이루어지는 변화는 과정을 모두 겪었기 때문에 이러한 변화에 대해 다소 민감하다. 하지만, 이런 재정의는 사실상 이루어지지 않는다. 왜냐하면 일이라는 일상 생활에 매몰되어 있기도 하지만 자본주의 패러다임에서는 눈 앞에 보이는 경제력이 굉장히 중요하기 때문이다. 그렇기 때문에 사회 구성원들은  이런 경제력을 얻기 위한 요소들을 얻어내기 위해  많은 시간을 쏟아부어야 한다. 그렇기에 이런 철학적인 담론들이  중요도에 비해 상대적으로 가치가 떨어지는 것은 어찌보면 당연하다. 이러한 철학적인 담론들이  사회 내부에서 중요한 가치가 있던 시절이 있듯이 현재는 자본주의라는 개념하의 경제력은  현 시대에 굉장히 중요한 가치이다. 이런 나의 말에 어떤 사람들은  노골적으로 싫은 눈치를 줄지는 모르겠지만 말이다. 하지만 그러한 사람들을 포함한 이 흐름은 사회 내부의 구성원들 그 누구도 벗어날 수 없다. 거대한 파도, 패러다임 그 자체이기 때문이다. 사회 구성원들은 좋든 싫든  이러한 거대한 파도 아래 서핑을 즐겨야 한다. 그렇지 못하면 거대한 파도에 휩쓸리기 때문이다. 그렇기 때문에 어찌보면  이러한 사회 내부의 구성원들에게  진정한 자유 의지란 존재할 수 없을지도 모른다. 왜냐하면 좋던 싫던 이 게임에 참가해야만 하기 때문이며 대부분의 사회 구성원들에게 선...
자세한 내용 보기

[ React, JavaScript ] 함수형 컴포넌트 정의에 대해: function 정의, const 정의(Arrow Function)

-
이미지
서론 React에서 컴포넌트를 새로 작성한다고 가정해보자. 이 때 가장 먼저해야 하는 것은  어떤 형식으로든 메인 함수를 정의하는 것 부터 시작할 것 이며 이와 동시에 하단에 이를 export 할 때,  디폴트로 설정한다는 코드를 작성하게 될 것이다. 아래와 같이 말이다. function NewComponet (){   return < div > null </ div > ; } export default NewComponet ; 나는 React를 배울 때,  위와 같은 방식으로 배웠기 때문에 항상 위와 같은 방식을 선호 했다. 하지만, 개발자라면 모두 느끼고 있듯이 코딩 스타일이라는 것이 일부 다를 수 있다는 것을 가장 잘 알 것이다. 가장 대표적으로 중괄호를 어떻게 쓰느냐를 예를 들 수 있다. function NewComponet () {   return < div > null </ div > ; } export default NewComponet ; 중괄호 스타일 1 function NewComponet (){   return < div > null </ div > ; } export default NewComponet ; 중괄호 스타일 2 재미있게도 나는 실무를 하면서 이런 선언 방식이  사람에 따라 두 가지 방식으로 정의하는 것을 발견했다. 정의 방법은 아래와 같다. 첫 번째, function 정의  두 번째, const 정의 무엇이 다를까 매우 흥미롭다. 이번에는 이 두 가지 정의 방법에 대해 알아보고 이에 대한 차이점에 대해  그리고 이런 정의 방법에 따라 퍼포먼스 문제를  야기 할 수 있는지에 대해 이야기를 나누어 보자. 함수형 컴포넌트 정의에 대해 : 정의 예 먼저 이 두 가지 방법을 한눈에 보기 위해  두 가지 정의 코드를 먼저 살펴보자. function NewC...
자세한 내용 보기

[ React ] React에 대해 : 리렌더링과 memo 메소드

-
이미지
서론 React는 기본적으로 언제 리렌더링 될까? React에 대해 조금 지식이 있다면 잘 알다시피 아래와 같이 크게 2가지로 나눌 수 있다. 첫 번째, 컴포넌트의 상태(state), 프로퍼티(props) 변경되었을 때 두 번째, 상위 부모 컴포넌트가 변경되었을 때    첫 번째의 경우는 React의 가상 DOM(VDOM)에서 이전 VDOM과 비교해서 변경 된 곳만 실제 DOM에 업데이트 해주기 때문에 이 경우 신경 쓰지 않아도 된다. 하지만, 이 중 두 번째의 경우가 가장 문제일 수 있는데  부모 컴포넌트가 어떤 값이던 간에 바뀐다면 그 하위의 자식 컴포넌트 모두가 리렌더링 대상이 되기 때문이다 즉, 어떤 한 하위 자식 컴포넌트의 값이 변했을 때, 그와 관련 없는 또 다른 자식 컴포넌트 까지 렌더링 대상이 된다는 것 이다. 그렇기 때문에  여기서 우리는 최적화에 대한 문제에 직면하게 된다. 먼저 두 번째에 경우에 대해 이야기하기 전에  React의 이해를 돕기 위해 첫 번째의 경우 부터 이야기를 나누어보자.   첫 번째: 상태와 프로퍼티가 변경되었을 때 본론에 들어가기 앞서 먼저 VDOM에 대해 이야기를 해보자. 사실 React의 매력은 이 VDOM에 있다고 볼 수 있다. 왜냐하면 일반적인 DOM에서 내부 구성 변경되면 UI를 새로 다시 그리기 때문에  기본적으로 애플리케이션의 성능이 그렇게 썩 좋다고 보기는 힘들다.  하지만 이와 다르게 React의 VDOM은  업데이트 된 부분만 수정하기 때문에 일반 DOM을 활용한 시스템보다는  퍼포먼스 측면에서 유리하다고 할 수 있다. 이렇게 실제 DOM과 가상 VDOM을 동기하는 과정을  reconciliation(조정)이라고 하는 것 같지만 실제로는 diffing이라는 단어를 자주 사용하는 것 같다. VDOM [1]  에 대한 내용과 Reconciliation [2]  에 대해서는...
자세한 내용 보기

[ Neural Network, Python] Python에서 뉴럴 네트워크는 어떻게 표현되는가? : 뉴럴 네트워크의 모듈(객체)화

-
이미지
이전 포스팅에서 오류률을 최소화하기 위해서 역전파를 구현해 수직, 나선 분포 데이터의 테스트 까지 완료하였다. 물론 여기서 끊을 수도 있겠지만, 좀 더 욕심을 내서 모듈화(객체화)까지 완성해보자. 현재 코드의 가장 큰 문제점은  하드 코딩으로 레이어와 활성화 함수를 고정 시켰다는 점에 있다. 좋은 코드가 되기 위해서는 레이어의 선택과 활성화 함수 선택까지 할 수 있어야 하며 코드 또한 간결할 필요가 있다. 이번에는 코드의 최적화를 하여, 레이어 생성 부터 시작해 최적화(역전파)를 비롯한 전체 과정을 객체로 불러올 수 있게 최적화 해보자. 이것으로 꽤 나 길었던 포스팅이 끝이 날 것이다. 레이어의 모듈화 이번 모듈화는 따로 소스 파일 까지 분리 하였다. 먼저 레이어에 관련된 소스 코드의 모듈화다. 1 2 3 4 5 6 7 8 9 10 #layer.py class  Layer:      def  __init__( self ):          pass        def  forward( self ):          pass        def  backward( self ):          pass cs 이 파일은 단순히 상속하기 위한 코드이다. 대부분 파일에서 사용한다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 #layer_dense.py from  layer  import  Layer import  numpy...
자세한 내용 보기