Talk Lowy(kr)

영상버전 :  https://youtu.be/l8S85XwETtI 컨설팅 업체에 들어가도  이걸 가르쳐 주는게 아니라  템플릿을 주고 채우면서 스스로 공부를 해야 하기 때문에 10년이 넘게 컨설팅을 해도 전체적으로 알기 어려운 부분입니다.  이번에도 제게 오퍼를 준 기업은 원래 솔루션 개발회사였는데,  회사가 자회사화가 되면서  갑자기 SI까지 같이 받는 식으로 확장 되었다고 합니다.  회사 내부에는 SI경험자가 없다보니 가벼운 프로젝트를 모회사의 영업력으로 꽂아주었지만,  그 프로젝트의 진행 자체의 경험이 없다보니  제가 도와드리기로 한 것입니다.  한국의 경우는 보통 영업회사가  RFP부터 도와주면서 자기네 회사에서만 가능한  특징적인 부분들을 넣어서 수주받기 좋은 조건들을 같이 넣는데요,  여기는 그런거 없이 RFP는 발주사가 직접 만드는 것 같습니다.  참고로 RFP는  Request for Proposal이라고 제안 요청서라고 한국말로 이야기하죠.  나 이런거 만들고 싶은데 제안좀 해줘 하고  SI업체에 던지거나 관공서 같은데는  RFP를 공시하는 사이트 등에 올리게 됩니다.  이 RFP에 대해서 어떻게 대응해야 수주가 가능한지를  가볍게 설명을 드리겠습니다.  RFP에는 pain point가 있고,  그걸 해결하고 싶어하는 배경과 이유가 적힙니다.  RFP에서 특정 기술을 사용하고 싶다고 적힌 경우도 있는데,  이런 경우는 이미 수주 회사를 지정해서  그들이 딸 수 있는 기술 중에 가장 어려운 기술들을 넣어서  타사들을 탈락 시키게 하는 경우가 많죠.  즉, 기술의 깊이가 깊을 수록  이미 수주사는 결정 되어 있다고 생각하시면 됩니다.  상식적으로 생각해보면  그 정도로 깊이 있는 기술을...

영상버전 :  https://youtu.be/YA9icWWSDZY 많은 개발자 채널에서는 개발자의 시선에서 AI를 활용하는 방법이 많이 소개되고 있죠? 전 컨설팅이나 프로젝트 매니징을 하고 있다보니 조금 시선이 다른 듯 합니다. 그래서 실제 현장에서 느끼는 현재의 AI의 현실감에 대해서 설명을 드리고자 합니다.  현재 제가 관여하고 있는 프로젝트는  크게 개발 프로젝트 하나와 기 개발된 서비스의 운영 프로젝트,  그리고 데이터베이스 시스템의 클라우드화 프로젝트를 하고 있구요..  그 밖에도 몇몇 소규모 프로젝트에 조언을 구하거나  직접 코딩하는 곳도 있습니다.  모두 많게든 적게든 AI를 사용하고 있습니다. 데이터베이스 프로젝트에서는  데이터베이스의 구축, 운영을 개발팀 내에서 해결하고 있습니다.  현재 우린 DBRE팀이라고 해서  개발자들이 DB를 운영할 때 퍼포먼스 저하가 일어날 부분을 조언해서 도와주고,  전체적인 성능 개선을 위해 인프라, 네트워크 또는 DBMS의 교체나 분산 등을 제안하고 보다 안정적인 성능을 사용할 수 있게 도와주고 있습니다.  이 경우는 개발과 직접 관련이 없지만 4명의 엔지니어 중에 AI를 사용하는 두 명의 엔지니어가 두각을 나타내고 있구요,  이들은 기존 대비 몇 배의 업무량을 처리하고 있습니다.   심지어는 다른 사람의 쿼리튜닝에 대한 리뷰나  Terraform으로 AWS인프라 설정을 한 내용이 요청에 맞도록 되었는지 리뷰하는 곳에 AI를 사용하고 있습니다.  이젠 쿼리나 코드를 읽는 시간이 10배 이상 빨라지고, 실수를 쉽게 찾아낼 수 있죠.  서버 작업 역시 AI가 짜준 쉘스크립트를 이용합니다.  하나하나 커맨드를 찾아가는 시간이 줄어들었죠..  이건 개발자랑 관련이 없는 내용이죠?? 다른 프로젝트인  개발 프로젝트에서는 AI의 비율이 엄청...

영상버전 :  https://youtu.be/4N0v9QUGD_I 얼마전 태국 개발팀이 만들고 운영하던 서비스를 인수인계 받았는데요..  인수인계를 받으면서  서비스 회사의 대표에게서는 태국 개발자들의 대응이 너무 느리다고 불만이 많았고,  태국 개발자들은 일이 많은데 알아주지 않는다고 불만이 많았습니다.  저야 인수인계를 받는 입장이다보니 양쪽 비위를 맞추어 최대한 잘 받아내야 하므로 이런저런 불만을 계속 들어주면서 어르고 달래서 최대한 받아냈죠.. 인수인계를 받고 한달 남짓.. 아직도 이 서비스를 100% 이해를 못했습니다.  하지만, 점점 양쪽의 입장을 이해하기 시작했습니다.  일단은 구조를 보시죠..  이 구성도 역시 타이 개발자들이 준게 아니라 그냥 디플로이 매뉴얼과  어카운트 정보 표를 보고 하나하나 들어가서 보면서 만든겁니다.  즉, 아직도 빠진게 있을지도 모른다는 것.. 구조를 보면 이상한 툴들이 많이 보이죠? 대부분의 대규모 경험을 한 사람일 수록 리스크 포인트를 줄이기 위한 노력을 합니다.  그 결과가 단순화,  그리고 장애시 빠른 복구가 가능한 구조,  확장이 편리한 구조를 많이 생각하죠.  이 말은 이 서비스는 MSA가 되어있느냐를 항상 질문하게 되죠. MSA는 아주 작은 단위로도 독립적인 서비스로서 기동이 가능하게 만들어야 하구요..,  그 기능들끼리 API등으로 연결해서  장애시 장애 포인트의 확인이 쉽고,  병목이 발생하면 그 부분만 확장이 가능한 구조를 가져가게 됩니다.  그렇게 하면 쉽게 확장이 되고,  운영이 간단하죠.  즉, 특정 모듈이나 솔루션, 미들웨어를 설치할 때,  이것 없이 더 단순화 할 수 있는지를 계속 물어가면서 만들어야 하구요,  개발 공수보다 이 모듈을 넣는게 낫겠다면,  그 모듈을 넣고나서 운영을 어떻게 편리...

영상버전 :  https://youtu.be/StZQGYVGTQs 제가 보통 개발자 욕을 잘.. 하긴 하지만,  그렇다고 나쁜 개발자는 일부에 지나지 않잖아요? 모든 개발자를 욕하는 건 아니고  제 주변에도 일잘하는 개발자들은 많으니  이런 사람만 되지 않았으면 해서 하는 말입니다. 문제는 그 일부에 지나지 않는 나쁜 개발자를 한국에서 참 많이 봤다는 얘기죠. 그런데.. 그게 한국 개발자만 그런게 아니었네요..  1월부터 맡기로 한 농산물 유통 서비스인데요..  사장은 일본 사람이고, 개발팀은 모두 타이 사람입니다.  처음부터 그 타이 사람들이 개발을 해왔다고 하구요.. 그런데 타이 사람들에게 유지 개발, 버그 수정등을 던지면 너무 시간이 많이 지체 되어  신규 고객이 대기하고 있는 상황이라고 하네요..  보통은 신규 고객이 들어오면 회원 가입하고 바로 쓰는게 일반적이잖아요? 그게 아니라 신규 고객이 들어오면 며칠에 걸쳐서 서버 작업을 하고 나서  고객 어카운트가 발급되는 방식이라고 하네요..  게다가 뭔가 하나 수정을 요청하면 이런저런 핑계를 대면서  메뉴의 오탈자 수정에 일주일이 걸리지 않나 풀다운 메뉴의 내용에 항목 하나 더 추가하는데 두 달이 걸려도  아직도 진행중이라고 그러더랍니다.  그래서 그 중간에서 기술적인 체크를 하고 말도 안되는 공수를 이야기 하면 태클을 걸고 하는게 제 입장인 거죠..  때문에 개발자들이 일부러 어려운 표현 같은거 쓰면 그게 뭔소린지 알거나 말도 안되는건 잘라낼 수 있는 스킬은 필요합니다.  그런데 문제는 개발자들이  Github 초대나 서버 어카운트의 공유를 해주지 않더랍니다.  환경은 Ubuntu에 Proxmox라는 VM및 Container가상화 오픈소스 솔루션을 사용중이고  DB는 별도 DB에 고객별로 데이터베이스를 추가하는 방식 같네요..  그...

영상버전 : https://youtu.be/6N43PnaHNqo 원래 이번에는 인덱스 튜닝 관련 이야기를 하려고 했는데,  이걸 먼저 올리고 싶어서 끼어들었습니다.  다들 파견이 안좋다고 많이 하는데 전 파견 관련 이야기를 많이 하고 있잖아요? 그리고 그에 대한 상담도 받고 제 경험에 비추어 안내를 해주고 있습니다.  일본의 비정규직이란 사람들은  보통 두어 군데 파견회사에 등록을 합니다.  그리고 파견회사가 소개해준 곳 중에 마음에 드는 곳으로  비정규직으로 들어갑니다.  외국인 중에 비자가 해결되지 않은 사람들은  비자를 발급해 준 곳에서 일을 해야만 하지요.  비자가 해결된 사람과 해결 안된 사람의 이 정도 현장 선택의 자유도가 차이납니다. 일을 하다가 맘에 안들거나 현장에서 일하는 사람이 마음에 안들어 교체 요구를 하는 등 서로 안맞으면 쉽게  현장을 바꿀 수 있는게 파견의 장점이면서,  회사도 개인도 계속 맞는 사람과 현장을 찾아서 돌아다닐 수 있다는게 매리트가 있지요.  그러다가 서로 잘 맞는 현장이 나타나면 10년이든 20년이든 하는 것 같습니다.  오래 하게 되면 정사원이 나은 경우 원청업체가 파견 알선 회사에 이야기 해서  정사원을 제안하기도 합니다.  이 때 파견 업체는 원청업체에 정사원으로 주는 대신 연봉의 30%를 감사료로 받습니다.  저 역시 자주 원청업체에서 제안이 오는데 제가 거부하고 있지요..  일본에서는 하나의 현장에서 3년 이상 비정규직을 지속할 수 없게 하는 법이 있다보니  3년마다 이동하거나, 약간 우회 방법을 통해 계약을 바꿔가며 한 곳에서 일하기도 합니다.  그렇다보니 괜찮은 인재가 있다면 정사원 영입을 해버리지요.  회사의 입장에서는 개인의 월급의 50%가 부대비용으로 나갑니다. 즉 회사는 한 사람을 고용해서 나가는 비용이 월급의 1.5...

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

영상버전 :  https://youtu.be/z5hrHi-82ZY 얼마전 비즈니스 관련 이야기를 하다가 나온 말이었는데요..  한국에선 솔루션은 반드시 SI업체와 끼거나 솔루션 업체에 SI팀이 있어야 합니다.  이유는 특정 솔루션 영업을 가면  PoC를 하면서 자기네 입맛에 맞춰서 엄청 뒤집어야 하지요.  어떨 때는 완전히 새로운 솔루션이 탄생하기도 합니다.  그래서 한국의 솔루션 업체들 중에 업력이 오래된 곳의 상품을 보면,  정말 많은 커스텀 모듈이나 상품들이 즐비합니다.  그리고 신생 솔루션 업체는 솔루션이라고 만들었지만 대부분 커스터마이징 당할 것이라 생각해서 도큐먼트나 기능이 부족한 상태에서 영업이 들어가는 경우가 많습니다.  어짜피 솔루션 업체에서 아무리 기능을 미리 만들어둬도 거의 새로 커스터마이징 하는게 더 많거든요.. 해외의 모든 나라 통계는 모르겠는데요..  일본의 경우는 솔루션 영업을 가면..  솔루션에 있는 기능을 그대로 사용하고 없는기능은 api 를 찾아가면서 직접 개발 하는 경우가 많습니다.  즉, 솔루션 업체는 솔루션만 안정적으로 공급하면 된다는 것이지요.  때문에 솔루션을 사용하는 기업에서는 기본 기능 이외에도, 커스터마이징을 위한 API 문서가 얼마나 충실한지도 중요합니다.  여기서 일본환경과의 오해와 차이가 생기는데요..  한국 솔루션 기업은 어짜피 고객들이 자기 멋대로 말하면 솔루션 업체가 그 요구에 맞추어 커스터마이징 할게 뻔하다보니,  API를 만들어줘도 고객이 API를 쓸 이유가 없지요. 그냥 솔루션 업체에 시켜서 커스터마이징 된 UI만 쓰겠다고 자기네에 맞춰달라하니 API문서를 만들필요가 없고, API도 고객의 요구에 맞추다보니 새로 만들거나 사양 변경이 빈번하게 일어납니다.  때문에 문서화에 의미가 없어서 문서를 점점 등한시 하게 되었지요.  그걸 일본으로 가져...

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

영상버전 :  https://youtu.be/pYqlz5DyfzE IT프로젝트에는 많은 문서가 필요합니다. 하지만 작은 프로젝트나 자사 시스템은 문서가 부족한 경우가 많지요. 그래서 저는 경험이 적은 사람은 외부 SI같은 경험을 통해 문서 만드는 것을 몸에 익히게 하는 것을 추천하고 있습니다. 한국은 경험을 많이 할 수 있으나 남은 문서가 적어 스스로 무얼 했는지 정리하지 못하는 사람들이 많고, 문서가 필수인 일본에 넘어와서는 실력이 좋음에도 문서를 못만들어 평가 절하 되는 경우가 많거든요. 그러면 결국 실력이 있으면서 상류 공정을 뺏기는 경우가 많지요. 항상 프로젝트 또는 사내 기술문서는 내게 아니라고 지나치지 마시고, 열람 권한이 있는 문서는 모두 보고, 스스로 만들어보는 버릇을 들여야 합니다. 그게 단순히 앉아서 코딩하는 것 보다 훨씬 빨리 성장하는. 길이거든요. 그레서 개발자 및 IT엔지니어들이 꼭 봐야 하는 문서를 정리 해 봅니다. ISP보고서 ISP보고서는 프로젝트 시작 전에 외부 컨설팅 업체에 이 프로젝트의 정당성, 시장상황 등의 큰 그림을 볼 수 있어 프로젝트에 참여한 사람들이 방향을 일치 시키는데 중요한 역할을 합니다. 하지만 ISP보고서 하나 작성에 수억이나 하기 때문에 보통 10억엔 이상 하는 프로젝트가 아니면 없는 경우가 많습니다.  그래도 일본에서는 많은 이유는 IT프로젝트 하나에 수천억엔 하는 경우도 있기 때문에 충분히 볼 기회가 많습니다. RFP(Request for proposal) 제안 요청서 라고 하는데, 발주사가 나는 이런거 만들테니 제안서좀 가져와봐 하는 제안서를 만드는 기업에 제출하는 사양서 입니다. 보통 여기에 기술적 요건들이 들어가는데요..  발주사의 담당자가 전체를 퍼악할 수 없는 경우가 많기 때문에 ISP프로젝트를 진행하는 외부 컨설팅 업체가 발주사의 환경을 분석해서 만들곤 하는데요. 규모가 작은 경우는 발주사가 자주 발주하는 업체에 요청해서 만들기도 합니다. 때문에 rfp에 침여한 업체는 ...

영상버전 :  https://youtu.be/uk1OQ4g1dXk 개발자로 계시면서 미래가 불투명하거나 이제 막 개발자를 지망하신 분들께 이야기를 해볼까 합니다. 많은 채널이 개발자 중에서 연봉 높이는 법을 이야기 하죠? 하지만 개발자가 어떤 언어를 알아야 연봉이 높고 어떤 기술 스택을 알아야 연봉이 올라간다는 것은 정설이라고 보시나요? 실제로 그걸 믿고 현업에 뛰어드신 분들, 만족스러운 연봉을 받고 계신가요? 제가 이번에 해드리려는 이야기는 여러분의 지금까지의 노력을 헛수고로 만들어버릴 지도 모릅니다. 하지만 보다 높은 연봉을 위해서라면 제로부터 다시 시작해도 괜찮다는 분들은 끝까지 봐주시면 좋겠습니다. 일단 IT엔지니어를 크게 나누어 보겠습니다. 잘 안보이시나요? 확대... 를 하셔도 깨질겁니다. 원래 해상도가 낮아서리;;  하나씩 확대를 해드릴께요..  아, 개발자는 그림에 없네요.. 텍스트로.. 개발자 - 업무를 IT언어로 바꾸어 컴퓨터 위에서 업무를 하는 프로그램을 만드는 사람을 뜻합니다. 게임이 무슨 업무냐구요? 그냥 예를 업무로 든 걱 뿐이니 태클은 사양… 예전에는 서버 개발자, 클라이언트 개발자로 나뉘었으나, 요즘은 프론트엔드, 백엔드, 콘솔, 임베디드 개발자 등 여러 종류가 있죠. 이들은 수요가 많기 때문에 쉽게 접근을 할 수 있으나 최고봉까지 올라가는 사람은 극소수 이고, 많은 사람들은 수요가 많은 400 ~ 600만엔 정도 전후에서 급여를 받겠지요. 하지만 PL, SE 등등으로 올라가면 갈수록 연봉 상승의 폭이 커집니다. PL은 보통 600~750만엔이 많구요 SE는 800만엔 정도부터.. 비즈니스 영어가 되면 1500만엔까지 노려도 됩니다. 물론 외자계 프로젝트로 가야하지요.. 일본에는 외자계 프로젝트가 상당수 있습니다. 일은 언제나 많으니 다른 사람이 채갈 걱정은 마시고.. ^^ 개발 언어문제가 아니고, 생성형AI 관련 개발이나 블록체인 개발 등의 특수한 분야에 대해서는 가파르게 몸값이 상승 중입니다. 생성형 A...