기본 콘텐츠로 건너뛰기

라벨이 chatgpt인 게시물 표시

chatgpt로 DB튜닝 전문가 되기!

영상버전 :  https://youtu.be/3bhK0B96zIQ 이젠 chatgpt를 사용하면 저와 같은 레벨의 db튜닝을 하실 수 있습니다.  단! 아래와 같은 접근을 잘 연습하신다면 말이죠.. 1. 인덱스 점검 먼저 ChatGPT에게 “이 테이블에 어떤 인덱스가 이미 있고, 어떤 게 부족해 보이는지”를 물어봤습니다. 그러자 놀랍게도, 각 테이블에 필요한 인덱스 목록과 개선 방향을 꽤 체계적으로 제시해주더군요. 2. 복합 인덱스 인덱스를 최소화하면서도 효율을 높이려면 복합 인덱스가 답일 때가 많습니다. 그래서 ChatGPT에게 “그럼 복합 인덱스를 구성한다면 어떤 필드 조합이 좋을까?”라고 물어봤죠. 예: return_date + shop_id, order_id + return_flag 등등 필드 순서를 어떻게 두느냐에 따라 성능이 확 달라진다는 이야기 Include 옵션을 활용하면 인덱스만으로 데이터를 조회할 수 있어 훨씬 빠르다는 조언 이런 내용이 나오는데, 솔직히 저도 모르는 건 아니었지만 다른 시각에서 정리된 결과를 보니 훨씬 명쾌했습니다. 3. ‘카디너리티’ 인덱스 튜닝하면 꼭 등장하는 단어가 **카디너리티(Cardinality)**입니다. 쉽게 말해, 특정 필드가 갖는 값의 다양성 정도죠. 예를 들어, shop_id가 수천 개라면 카디너리티가 높고, dtenpocd처럼 점포코드가 57개밖에 안 된다면 카디너리티가 낮습니다. ChatGPT가 강조하더군요. “카디너리티가 높은 필드는 인덱스의 앞쪽에 두어야 효율을 극대화할 수 있어요.” 반면 카디너리티가 낮은 필드는 필요하면 Include에 넣거나 뒤로 빼서 쿼리 범위를 좁히는 식으로 사용하라고 했습니다. 4. 인덱스 필드 순서 실제로 저도 “기간 검색을 먼저 하고, 그 다음에 shop_id로 필터링하는 게 낫지 않을까?”라는 의문이 있었어요. 그런데 ChatGPT는 “shop_id로 먼저 필터링하고 기간 검색을 거는 게 더 나을 수도 있다”라고 하더군요. 그 이유는 shop의 개수가...

DB엔지니어라면 코드를 몰라도 API서버가 만들어지는 것 같습니다.

영상버전 :  https://youtu.be/JGgTOA5Tcsc 2007년에 SQL Server에 있는 SP를 기반으로 만든 서비스가 있습니다.  다른 RDBMS에서는 그냥 프로시저라고 부르는데 유독 SQL Server에서만 Stored Procedure라고 하네요..  이유가 뭔지는 모르겠지만.. 아뭏든..  거의 모든 처리는 SP에서 처리하고  웹페이지는 그냥 SP를 실행한 결과만 호출하는 방식이죠. 결과 또한 표시 화면에 맞추어 쿼리를 만들었기 때문에 계산이나 변수에 받아서 조정할 일이 없습니다.  여기에는 많은 개념이 있었는데요..  2007년이면 AWS가 막 이름을 내기 시작했고, VMWare가 일본을 장악 했던 떄이죠.  VMWare의 3.5를 쓰다가 VMWare 4.0부터 많은 부분이 안정화 되었고,  이 VMWare를 이용한 인프라 관리가 관건이었습니다.  Xen도 이 때 많이 커지는 듯 하였으나, 어느 정도 중대규모 및 상업용은 VMWare가,  초 대규모 또는 무상은 Xen이 점령하고 그 밖에 virtualserver, hyper-v, kvm등등 많은 가상화 솔루션들이 있었죠.. 그리고 2011년 정도 되어서 openstack과 cloudstack을 기반으로 오픈소스 진영이 엄청나게 전쟁중이었구요.. VMWare같은 가상화 솔루션은 하나의 머신에 VM을 쓰다가  vMotion이란 것을 이용해서 가동 중에 여기저기 머신을 오다닐 수 있는 기능을 가지고 있구요,  그러다 보면 local IP를 바꾸기 일상이죠.  300대의 물리머신에 대당 10개의 가상머신이 있다면 일일이 동일한 IP로 옮겨다니기 어렵거든요..   가상 IP를 마구잡이로 넣고 나중에 글로벌IP를 Routing으로 매핑하거나 NAT를 많이 쓰기도 했구요..  이 즈음에 Azure 클라우드 서비스가 처음 선보였는데,  이 때...

생성형AI가 만들어가는 인간불신 사회

영상버전 :  https://youtu.be/h9mVZ6MHQ4k #생성형AI 가 아무리 발전해도 그걸 쓰는 사람의 능력 이상은 끌어낼 수 없다.  요즘 이런 이야기를 하시는 분들이 늘고 있습니다.  저 역시 공감하고 있고, 어제 그 공감이 또 확신이 되었네요.  신규 고객의 환경은 #proxmox 로 #kubernetes 를 관리하는 환경인데요. kubernetes가 원래 #docker #container 관리를 편하게 해주는 툴 이잖아요? 그런데 kubernetes를 바로 안쓰고 다시 proxmox라는걸 이용해서 #가상환경 까지 통합관리를 하더라구요..  즉, #VMWare + Kubernetes 랄까요? Kubetnetes를 그냥 쓰면 어딘가 docker 이미지를 디플로이 할 수 있는 환경을 손수 준비를 해야 하지만, proxmox에서 설정하면 자동으로 VM과 docker 이미지를 같이 디플로이 할 수 있다.. 인데요..  어떻게 보면 참 편리한 도구 같잖아요? 하지만, 역으로 이게 더 관리가 어렵네요.  이유는 VM을 위한 환경 변수도 다 설정해야 하고,  VM이 설치 된 뒤의 Docker이미지 관련 환경 변수도 다 설정하고 해야 하니 어짜피 한 화면에서 하느냐 서너화면에서 하느냐 차이 밖에 없더라구요.. 너무 복잡하게 설정되어 있어서, 이걸로 서비스를 하나 만들었는데 신규 고객용으로 디플로이 하는거 자체가 엄청난 수작업 해야하는 상황입니다. 이 이야기는 관리포인트가 더 많아서 장애에 대한 대처 지식이 더욱 필요한 것이지요.   그런데 일이 터져 버렸습니다.  인수인계를 받자마자 일 주일도 안되어 서비스가 떨어졌습니다.  인계를 해준 타이 개발자들은 나몰라라 하고 인계후 연락을 끊어버렸구요..  이 원인을 찾기 위해 #chatgpt 를 사용해서 에러 메시지와 그에 따른 원인을 묻고 그 원인처럼 보이는 것을 하나씩 찾아서 제거해 갔죠....

DeepSeek의 소스를 까보자..

영상버전 :  https://youtu.be/zFXmIoSQU5Q 요즘 핫한 이슈니까 좀 얻어타볼께요..  제가 좋아하는 안될공학 이란 곳에서 공식 문서나  기타 정보를 베이스로 신뢰성있고 깊이 있는 정보를 다뤄주고 있어서  그 곳을 참고하시면 왜 DeepSeek가 생각보다 부풀려 있는지를 잘 이야기 해주고 있습니다.  거기까지 가서 보기 귀찮으신 분들께 요약을 해드리자면 DeepSeek는 결고 학습 비용이 싸지 않습니다.  이건 DeepSeek의 공식 문서에서도 나와 있는데요,  거의 1/10의 비용을 들였다고 하는 부분만 기사화가 되어서  다들 그런줄 아시는데,  필요한 전제 학습은 모두 끝낸 뒤 마지막 테스트 비용이 1/10이라서 전제 학습에 들어간 비용은 포함되지 않았다는 이야기 입니다.  즉, 그게 100배 들어갔는지 알 방법이 없는거죠..  두 번쨰, 오픈소스라고 했는데,  AI개발하시는 분들은 다들 아시겠지만,  AI는 이미 Python의 pytorch나 tensorflow 모듈을 설치하고  거기서 호출하는게 다 입니다.  즉, 모든 알고리즘은 1950년대에 이론이 완성되었구요,  그 알고리즘들의 조합을 이용한 여러가지 방법론이  클라우드 시대의 분산 컴퓨팅 파워를 활용해서  나오기 시작한거죠.  그 조합 중에 Neural Network가 있는거구요,  Neural Network의 조합 개념을 활용하여  알고리즘 조합 차이로 DNN과 CNN, SNN이 있는 겁니다. 그 중 DNN을 활용한 것 중에   transformer라는 방법론이 있는거구요,  이번 deepseek의 오픈 소스를 보시면 아시는 분들은 아시겠지만,  Pytorch의 transformer의 모듈을 그냥 갖다 쓴게 아니라 어짜피 transformer도 여러가지 알고...

DB튜닝 전문가 망했습니다..ㅠㅡㅠ

영상버전 :  https://youtu.be/iTmkJ2iWJuU 지금 프로젝트에서 개발자들이 프로시저를 만들다보니  개발자의 의식의 흐름대로 데이터 처리를 만들다보니 커서를 이용해서 테이블 변수에 넣고  그걸.  변수로 다른 테이블에서 조회하는 식으로 짜놨네요..  튜닝할 때 항상 하는 이야기 이죠.. Trigger와 커서는 절대 쓰지 말라구요..  이것처럼 속도를 저하시키고 락을 유발 시키는 장치는 없거든요..   트리거는 트리거링 포인트가 되었을 때 대상 테이블을 락을 건 뒤에 트리거 처리를 하고 나서 락을 해제 하기 때문에 아무리 빨리 끝나도 동시에 들어오는 쿼리에 따라서는 데드락에 빠질 가능성도 있습니다.   마찬가지로 커서 역시 테이블을 열고 커서를 만들어 처리하기 때문에 그 모든 처리가 끝날 때까지 락이 걸린 상태가 됩니다. 데이터가 변동하면 안되니까요..  그래서 트리거와 커서를 사용하면 기본 서너배는 느려집니다.  커서랑 트리거만 없어도 50만명 받을 서비스가 15만명도 못받게 되는거죠.. 경우에 따라서는 수백배 느리게 짤 수도 있는게 커서와 트리거 입니다. 그냥 서비스를 떨구든 말든 자기 편한대로 만들겠다는 생각이 있지 않는한 커서는 피하셔야 합니다.   개발자들이 커서를 많이 이용하는 이유는 커서를 이용해서 만들면 복잡한 처리를 할 때 별로 생각하지 않고 개발 코드처럼 만들어도 가능하기 때문이죠  이번 쿼리도 커서를 사용해서 아주 길게 만들어놨네요..   한 줄 읽어서 상태에 따라서 데이터를 매핑해서 테이블 변수에 넣고를 쭈욱 한 뒤에  그 테이블 변수를 다시 읽어서 다른 테이블의 값을 가져오는데..   튜닝을 잘하려면 이 모든 데이터가 머리속에 연결구조를 그려서   하나의 비정규화 된 배열을 만들 수 있어야 합니다.   매번 이야...

chagpt를 625배 빠르게 처리하는 AI반도체가 한국에서 나왔다?

영상 버전 :  https://youtu.be/qCA0oP1-DFI 기사 본문 https://www.koreatimes.net/ArticleViewer/Article/157870 요즘 한국에서 AI반도체를 만들었다는 둥의 이야기가 여기저기서 나오고 있네요..  AI반도체란게 그렇게 갑자기 툭 튀어 나올 정도로 얕은 기술인건가요? 아니면 다들 신경 안쓰고 있는 시기에 십수년에 걸쳐서 연구를 했던걸까요? 이 내용은 한국의 특정 기관을 까내리는 것이 아닌 제가 느낀 이상한 점을 이야기한 것 뿐이기 때문에,  제가 틀렸을 수도 있습니다.  실제로 IEEE라는 글로벌 표준을 지정하는 곳에도 신청이 들어갈 정도면 그만큼의 기술력과 자부심이 있는것은 아닌가 싶습니다.  단지, 기사화 된 내용이 정말 맞는 건지 의문이 들어서 꼬집어 보는 것 뿐이니, 이런 의문점이 좀더 클리어하게 공개가 되면 좋겠다 싶습니다.  내용을 보면  입력 값의 길이로 SNN과 DNN을 분기시키는 것이 골자입니다.  원래 DNN은 엄청난 수의 연산이 필요한데, Core를 3400개 이상 가진 NVIDIA가 병렬로 연산하면 이론상으론 8코어 CPU의 400배 이상 빠릅니다.  하지만 SNN의 경우 그렇게 많은 연산을 필요로 하지 않기 떄문에 DNN만큼의 획기적인 변화는 나오지 않지요.. 즉, SNN만으로 처리하는 경우 역으로 더 빠를 수 있습니다.  그렇다고 하면 모두 SNN을 쓰지 왜 DNN을 쓸까요?  서로 처리하는 영역이 다르기 때문에 그렇게 쓸 수가 없었던 것이죠.  그걸 처리 요청을 받아서 굳이 DNN으로 쓸 필요가 없는 단순연산은 SNN으로 변환하고자 하는게 이번 뉴스거리 일 겁니다.  단지 그 이야기라면 그냥 요청 처리시에 구분해서 던진다거나,  DNN의 오픈소스에 입력값을 전처리할 때 SNN으로 분기만 시키면 되는거 아닌가요? 만약 그렇다고 한다면  기사 내...

chatgpt를 이렇게 쓰고 있습니다. 쓰면서 느끼는 AI의 근미래

영상 버전 :  https://youtu.be/-mnNq8f9LA8 얼마전에 개발코드를 좀 만져야 할 일이 있었습니다.  서버 작업이 귀찮아서 bash shell 코드를 chatgpt에게 요청 했지요.  그 코드를 붙여 넣자, 에러가 나왔습니다.  그래서 그 에러 구문을 다시 chatgpt의 소스코드 보여준 세션에 넣고  centos에서 하니까 에러가 뜨는데? 라고 하니 centos용 수정된 버전을 알려주네요..  centos버전으로 받은 스크립트를 실행하니까 이번엔 다른 에러가 떠서 에러 코드를 넣어봤죠.  그랬더니 Bash 에서 지원되지 않은 부분을 파악해서 수정을 해주네요..  수정된 것을 넣었는데도 에러가 떠서 다시 말했습니다.  그랬더니 chatgpt는 내가 사용하는 bash버전이 안맞는다는 사실을 인지하고 낮은 버전의 centos에서도 돌아가는 스크립트를 만들어 주었습니다.  그래서 돌렸더니 잘 돌아가더군요.. 제가 직접 일을 하면서 사용하고 있는 내용입니다.  다른 많은 영상에서는 실제 사용하는 느낌보다 이렇게 되는 겁니다 하는 식의 좀 먼 이야기 같은 영상을 보셨겠지만,  개발 또는 서버 작업을 하시는 분들은 이 내용을 보시고 어떤 생각이 드시나요? 혹시 개발자 분들, 나 이대로 개발자 해야하는건가?  라던가,  개발자는 앞으로 chatgpt가 말한거를 붙여넣고 실행만 하는 직업이 되는거 아냐? 라고 생각하시지 않으셨나요?  chatgpt로 인해 인류의 일자리가 없어진다느니 하는 이야기 이전에,  chatgpt로 인해 많은 고급 일자리의 허들이 낮아져서  초보들도 복붙만 할 수 있고, 내용만 알면 고급 업무를 할 수가 있는 것입니다.  이게 현실이고 여러분의 눈앞에 일어나고 있는 일이지요.  많은 IT엔지니어들이 비슷한 레벨에서 치열하게 경쟁을 하는 모습이 눈에 선하네요....

Chatgpt가 사람을 바보로 만든다! 개발자가 아닌 유저들에게 던지는 경고!

듣기 버전 :  https://youtu.be/INi1zqWlol4 챗gpt가 사람을 바보로 만든다! 요즘 너무 챗gpt로 낚시성 글이 많아서 기피하는 주제였는데요.. 슬슬 이야기 하지 않으면 안될 거 같아서 가지고 나와 봤습니다. 전 단순히 이용자로서 좀 쓰고 마는게 아니고 ChatGPT로 대화봇을 만들어서 서비스 런칭을 했습니다. 그러면서 문득 주위를 둘러 보고 느낀 내용입니다. 사람과 로봇의 차이는 뭘까요? 보통 생각하느냐 아니냐 차이라고 말을 많이 할 겁니다. 바보와 천재의 차이는? 이것도 생각 못하냐고 누군가에게 화를 내신 적 있나요? 저의 어릴 때는 휴대폰이란게 없이 공중전화에서 전화를 하고 언제나 전화번호장 또는 주소록 이라는 손바닥만한 수첩을 가지고 다녔고 웬만한 지인의 전화번호는 기억하고 다녔습니다. 우리는 언젠가 부터 전화번호를 기억하는 것을 멈추었을까요? 여러분은 지금 몇 명의 전화번호를 외우고 계신가요? 예전에 TV가 나왔을 때 TV를 바보상자라고 했죠. 사람들은 시간이 남을 때 TV를 보면서 시간을 보냈습니다. 하지만 TV에 빠져든 사람들은 오히려 TV가 생활의 중심이 되었지요. TV가 주는 쾌락에서 헤어나올 수가 없었죠. 사람들은 TV를 보는 순간은 생각을 멈추게되었습니다. 스마트폰의 가장 큰 문제가 스마트폰에서 주는 동영상이나 게임 등의 재미에 빠져서 멍하니 보는 것이라는 것은 다들 알고 있으리라 봅니다. 도파민을 바라면서 해야 할것도 멈추고 멍하니 누워서 핸드폰만 바라보는 바보가 되고 있습니다. 지금 휴대폰을 하루만 꺼봐 주세요. 내가 그 동안 의지했던 스마트폰이 없어져도 지금 하던 일상이 문제가 없나요? 조금 불편하다고 생각 되시는 분들은 아직 스마트폰 중독이 아닙니다. 하지만 뭐하나 찾는데 화가 나거나 동영상을 못봐서 뭔가 답답하다면 의존도가 높다는 이야기지요. 무언가를 찾을때 그 동안은 어떻게 찾았을까요? 검색엔진에 이런 단어를 입력하면 잘나올까 고민하여 단어를 입력하고, 예상과는 다른 결과를 보면서 점점 내가 원하는 ...

AI를 지배하는 자가 세상을 지배할 것 같습니다.

AI를 지배한다는 표현을 지난 글에서 적었는데요..  AI활용이라면 chatGPT나 stable diffusion을 사용해서 생성하거나 하면 될텐데.. 어떻게 하면 AI를 지배할 수 있을까요? AI를 사용하는 인프라를 내가 가진다? AI알고리즘을 내 관리하에 둔다? 2014년 Gartner에서 이야기한 내용이 있지요.  데이터는 21세기 원유다.  https://talklowykr.blogspot.com/2019/03/blog-post_12.html 그래서 데이터 사이언티스트가 되는 것이 아니라 데이터의 석유왕이 되어야 한다는 표현을 제가 한 적이 있습니다. AI도 목말라 하는 것은 바로 학습할 데이터 입니다.  stable diffusion도 갑자기 획기적으로 바뀌게 된 것이 해서는 안되는(?) 데이터의 학습을 한 모듈이 세상에 나왔기 때문이지요.  결론이 보이지 않나요?  이게 진실인지는 모르겠습니다.  단지 말하고 싶은 것은 재주넘는 곰이 되지 않길 바랄 뿐입니다.  테슬러도 매일 버려지는 3TB가 넘는 각 자동차의 데이터를 담기 위해서 많은 노력을 하고 있습니다.  여러분도 지금 매일처럼 버리고 있는 의미 있는 데이터가 있지 않은가요? giip :: Control your future! https://giipasp.azurewebsites.net/