Talk Lowy(kr)

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

영상버전 :  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 관련 개발이나 블록체인 개발 등의 특수한 분야에 대해서는 가파르게 몸값이 상승 중입니다. 생성형 AI는 거의 python으로

Scrum은 소프트웨어 개발 및 프로젝트 관리 분야에서 널리 사용되는 Agile의 한 형태로, 복잡하고 빠르게 변하는 프로젝트에 대응하기 위한 유연한 프레임워크입니다. 다음은 Scrum의 주요 구성 요소를 자세히 설명합니다. 역할 (Roles): 프로덕트 오너 (Product Owner): 고객이나 이해관계자의 대표로서, 제품의 비전과 요구 사항을 명확히하고 우선 순위를 정합니다. 개발 팀과 긴밀한 협력을 유지하며 제품의 진행 및 결과에 대한 기대를 관리합니다. 스크럼 마스터 (Scrum Master): 팀이 Scrum의 원칙을 따라 적절하게 기능하도록 지원합니다. 문제 해결, 장애 제거, 프로세스 최적화 등이 주된 역할입니다. 개발자 (Development Team): 실제로 제품을 개발하는 교차 기능적인 팀입니다. 개발자는 자체 기구화되어 스프린트 목표에 따라 효과적인 작업을 수행합니다. 아티팩트 (Artifacts): 프로덕트 백로그 (Product Backlog): 모든 기능 및 요구 사항이 기록된 목록입니다. 프로덕트 오너가 우선 순위를 정하고 필요에 따라 업데이트합니다. 스프린트 백로그 (Sprint Backlog): 스프린트 내에서 실행되는 작업 목록입니다. 개발자는 이를 기반으로 스프린트 목표에 따라 작업을 진행합니다. 인크리먼트 (Increment): 스프린트 종료 시 완성되는, 기능적이고 테스트 가능한 제품의 일부입니다. 인크리먼트는 스프린트마다 누적되어 최종적으로 릴리스 가능한 제품이 됩니다. 이벤트 (Events): 스프린트 (Sprint): 고정된 기간(보통 1~4주) 동안 제품의 인크리먼트를 생성하기 위한 작업이 진행됩니다. 스프린트 계획 미팅 (Sprint Planning Meeting): 스프린트의 목표를 수립하고 스프린트 백로그를 작성하기 위한 회의입니다. 데일리 스크럼 (Daily Scrum): 개발자가 매일 15분 정도 소요하여 진행 상황, 장애, 협력이 필요한 사항 등을 공유하는 일일 미팅입니다. 스프린트 리

영상 버전 :  https://youtu.be/mzjpuLg4ru4 제 영상을 보면 어떤 큰 장애가 터져도 재섭게 엄청 잘 해결하고 있죠? 하지만 경험이 적었던 시절에는 해결 못한게 더 많았구요, 거의 죽일듯이 절 바라보는 사람들도 있었지요.. 시작하기 전에, 일본에서는 장애 라는 표현을 쓰지 않고 장해 라는 표현을 씁니다. "장애"는 개인이 일상생활에서 특정 기능이나 능력에서 일시적 또는 지속적으로 어려움을 겪는 상태를 가리킵니다. 반면에 "장해"는 기능이나 능력의 손상 또는 손실을 나타내며, 이로 인해 일상생활에 제한이 생길 수 있습니다. 따라서, 장애는 어려움이 발생한 상태를 나타내고, 장해는 그 어려움의 원인인 손상 또는 손실을 의미합니다. 시스템에서의 관점에서, "장애"는 주로 소프트웨어나 하드웨어에서 발생하는 기능적인 문제를 가리킵니다. 반면에 "장해"는 전반적인 시스템의 성능에 영향을 미치는 더 큰 범위의 문제나 결함을 나타낼 수 있습니다. 따라서, 장애는 특정 기능의 동작에 문제가 있을 때 사용되고, 장해는 시스템 전체적인 문제를 나타내는 데 사용될 수 있습니다. 뭐, 이건 chatgpt가 해준 대답일 뿐 제가 찾아본 사전들에선 혼용의 여지가 있습니다. 단지 한국에서의 경험에서는 거의 장애라는 표현으로 통일 되어 내가 장해라고 쓰면 이상하게 쳐다보는 경향이 있지만, 일본은 障害(장해) 라는 표현만 씁니다. 이는 장애인을 뜻하는 장애라는 단어는 사용하기 민감해서 라고 하네요.. 제가 너무 단어의 의미에 고집하는 경향이 있는데, 그건 프로젝트에 참여하는 사람들이 많을 수록 애매한 표현이 최종적으로 전혀 다른 결과를 일으킨 경험이 많기 때문에 프로젝트마다 사전을 만들고 인식을 통일시키다 보니 직업병 같은 거리 보시면 됩니다. 고객이 “고급스러운 색감” 이라고 하면 결과물은 빨강이 나올지 녹색이 나올지, 금색이 나올 지 모릅니다. 때문에 고객마다 고객이 원하는 “고급스러운”을 명확히