글

[ Essay - Technology ] 바이브 코딩의 허와 실

-
이미지
지금 우리는 가히 AI 시대라는 패러다임의 전환에 시대에 살고 있다고 해도 과언이 아니다. 특히, IT 업계에서 대다수의 작업량을 차지하는 프로그래밍의 영역에서 생성 AI를 이용한 생산성 향상의 가능성이 보이면서 어느 분야보다 가장 빠르게 괄목적인 성과를 이루고 있는듯 하다. 고작 몇 년전에는 커서에 의해 프로그래밍을 AI에게 프로그래밍을 위임하는 것이 더 나을 수 있다는 것이 어느정도 증명되면서, 작년에는 Claude Code의 영향으로 인해 이러한 이슈가 좀 더 가속화되지 않았나 싶다. 이러한 굉장히 빠르게 이루어지고 있는 생성형 AI 솔루션의 발달은 개발자의 종말론을 더더욱 부각시키면서 업계 전반이 큰 변화를 겪고 있는 것으로 보인다. 특히 이러한 변화 속에서 “프로그래밍을 몰라도 생성형 AI만 있으면 제품을 만들 수 있다”는  주장도 자연스럽게 힘을 얻고 있다. 최근에는 Saas 솔루션은 종말할 것이라는 다소 파격적인 이야기도 들리는 것으로 보면 소프트웨어 업계가 큰 격변의 시기가 온것임에는 틀림 없어 보인다. 허(虛): 빠르게 만들 수 있다는 환상 이런 상황에서 가장 주목받는 주장들은 서론에서 언급했다시피 ‘프로그래밍을 알지 못한다고 하더라도  생성형AI를 이용하면 빠르게 제품을 개발이 가능하다’라는 주장이고, 실제로 이는 어느 정도 타당성이 있어 보인다. 정말로 움직이는 결과물을 단 몇초 만에 보여주기 때문이다. 하지만, 이러한 ‘빠르게 제품 개발 가능하다’는 주장의 가장 큰 맹점이 있는데 개발자의 존재 이유가 단순한 제품이나 기능개발에 있지 않다는 점이다. 만약, AI를 통해 그럴듯 한 솔루션을 만들었다고 치자. 이것에 얼마만큼의 비지니스성과 지속가능성이 있을까? 예컨대 AI에게 넷플릭스나 트위터, 인스타그램과 같은 페이지를 만들어달라고 요청한다면, 아마 실제로 그럴듯 하게 만들어 줄 것 이다. 이러한 인기 서비스들은 토이 프로젝트로 다루기 쉽고, 하나의 트렌드로 자리 잡아 관련 자료를 찾기도 어렵지 않다. 코드 또한 깃허브에 충분...
자세한 내용 보기

[ 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...
자세한 내용 보기