Відео

여러분! 제가 이렇게 열일하는 사람입니다. 하핫! 😁

예. 잘 지내고 있습니다. 관심을 가져 주셔서 감사합니다! 조만간 프로젝트 멘토링을 하려는 생각도 있습니다. 자신이 개발하고 싶은 서비스 런칭 가능한 프로젝트를 선정하면 멘토링하거나 개발에 도움을 주는 방법을 생각하고 있습니다. 제가 이래저래 다른 개발 욕심이 많아 문제인것 같습니다. 중간에 유통 직거래앱도 생각을 했었고 간단한 사이드로 정몽규 OUT 이라는 사이트를 만들까도 싶었고.. 지금은 무선 이어폰 타입으로 AI 번역 기기를 만들면 어떨까 생각하고도 있었습니다. 그런데 이런 사업을 한번 잡으면 5년은 해야한다는 생각이 있어서... 참. 이런것이 문제네요. 교육 콘텐츠를 잡았으면 교육쪽에 집중해야하는데 말이죠. 교육쪽은 개인적인 딜레마가 있습니다. 일반적으로 교육은 자신의 강의를 판매하여 수익을 만드는데요. 개인적으로는 교육의 가격이 비싸면 안된다고 생각하고는 있기 때문입니다. 하지만 돈이 안되면 생계 및 확장이 어렵기도 합니다. 제가 교육을 주력으로하고 생각나는 제품이나 서비스는 교육받는분에게 넘기는 것도 좋을것 같다는 생각도 드네요. AI 시대를 맞아 개발을 더 잘해야 살아남는 시대가 올거라서... 좀더 심화된 개발 수요는 있을 거라고 생각은 드는데요. 어떻게 할지 저도 고민중입니다. 간단하게는 우선 디스코드방등을 개설하고 소통하는것도 생각중입니다.

음. 음... 제가 이런말 하면 뭐하지만. 여기는 흑백 요리사 전체 시리즈를 전부 보시고 식사 후 조깅까지 하고 오셔도 충분히 1등 하실 수 있으십니다.

주어진 문제만 생각하면 그렇습니다. 하지만 제가 강조하고 싶었던 부분은 에러 핸들링을 미리 감싸두는 것 자체가 아니라, 문제를 해결하는 사고 방식과 패턴에 관한 것입니다. 특히 라이브러리나 프레임워크를 설계할 때 고려해야 할 두 가지 중요한 측면을 말씀드리고자 합니다. 1. 사용자 인터페이스 우선 설계 함수의 사용자 인터페이스를 먼저 설계하는 것은 중요한 접근 방식입니다. 개발자가 try...catch를 사용해야 한다는 것은 결국 해당 API를 사용하는 사람에게 반복적인 작업을 요구한다는 뜻입니다. 따라서, 먼저 어떻게 API를 더 쉽게 사용할 수 있을지를 생각해보고, 그런 후에 내부 구현을 통해 사용자에게 편의성을 제공하는 것이 좋습니다. 예를 들어, withCallback() 함수는 개발자가 자주 사용하는 람다함수 작성 방식으로 함수 사용을 직관적으로 사용할수 있게 처리했으며, 일일이 에러 처리를 생각하지 않아도 되도록 설계되었습니다. 2. 실수를 없애는 라이브러리및 프레임워크 설계 프레임워크나 라이브러리를 설계할 때, 개발자가 쉽게 실수할 수 있는 부분을 내부적으로 처리하여 안정성을 높여주는 것이 중요합니다. 즉, 개발자에게 에러 처리의 책임을 떠넘기지 않고, 함수나 프레임워크 자체에서 에러를 감싸고 필요한 처리를 하도록 설계함으로써, 사용자가 실수할 여지를 최소화하는 것입니다. 이러한 설계 철학은 다른 영역에서도 자주 등장합니다. 예를 들어, 백엔드 개발에서 데이터베이스 쿼리를 다룰 때, DB connect를 제대로 릴리즈하지 않으면 connection이 유지되어 나중에는 더 이상 연결할 수 있는 리소스가 남아 있지 않을 수 있습니다. 이게 만일 발견하기 쉬운 상황에서 실수하면 바로 고칠수 있지만, 운이 나빠 조건이 몇번 중첩되는 희귀한 상황에서 개발자가 DB연결을 release하는 코드를 빠트릴 수 있습니다. 이 경우에는 사고가 지금 터지는 것이 아니라 상황이 누적되어 몇달후에 서버에 문제가 발생할 수 있습니다. 규모가 있는 프로젝트에서 이런 버그는 상당히 찾기 어려울 수 있습니다. 이에 개발자가 실수할 여지를 애초에 없애버리는 것은 프레임워크와 라이브러리를 만들때 중요한 고려사항일 수 있습니다. withCallback()의 예시도 이러한 철학에 기반하여, 비동기 작업에서 발생할 수 있는 오류를 안전하게 처리하고 있습니다.

개인적으로는 소프트웨어 오류는 무조건 있다고 생각합니다. 이건 없을 수는 없거든요. 아시겠지만 2010년 도요타 리콜 사태 때 소프트웨어 분석결과 8만개 이상의 경고가 발생했습니다. 그리고 그 당시보다 훨씬 많은 전자 제품이 들어가는 요즘에는 이러한 소프트웨어 경고가 훨씬 더 많을 것 같다고 생각합니다. 제 입장으로는 이정도의 경고가 있는 코드에서 버그가 없는 제품이 있다고 주장하는것이 더 납득하기 힘든 일입니다. 경고가 하나도 없어도 오류가 있을 수 있는데 말이죠. 말씀하신 렉이 걸리는 현상도 있을 수 있습니다. 하지만 이건 더 입증하기도 어렵고 하드웨어를 이상을 동반하지 않는다면 인정될 수도 없습니다. 이유는 하드웨어 오류가 동반되지 않으면 페달 블랙박스가 없는 이상 절대 인정되지 않을 겁니다. 이걸 인정하는 순간 이제 모든 사고 발생시 운전자들이 모두 급발진이라고 주장할 테니까요. 급발진이라고 추정되는 강릉 사고도 인정하지 않는게 현실입니다. 일단 우선은 급발진이 실제 입증된 사례가 나와서 제조사가 인정을 해야 다음단계로 넘어갈 수 있을 것 같습니다. 말씀하신 억울한 상황을 방지하기 위해서 페달 블랙박스도 좋다고 생각합니다. 개인적으로는 이런 오류 발생시 조치할 수 있는 방안이 최 우선순위 같은데요. 현재는 이런 안전장치를 달면 급발진을 인정하는것 아니냐는 의심이 있을 수 있어 개발이 반려된 사항도 있을 것 같네요.

말씀하신 렉 걸리는 현상은 급발진과는 조금 다르게 멀티 스레드로 돌아가는 곳에서 발생하는 연산장치 부하 때문에 발생될 수 있는 현상 같아 보입니다. 이런 차량 제어에서는 0.1초간 매번 실행되는 함수, 0.2초간 매번 실행되는 함수등 여러개의 멀티 스레드, 멀티 프로세서에서 각 부품으로 정보를 받아 명령을 처리할 건데요. 일시적으로 부하가 몰리게 되면 명령 처리가 버벅거릴 수 있습니다. 여기서 사용자 명령을 추가한다고 해도 지금 처리 못하는 명령이 많기 때문에 해당 조작이 무시됩니다. 그렇기에 잠시 놓아두면 명령들이 처리되고 다시 정상으로 돌아 올 수 있습니다. 이것도 또한 위험하긴 마찬가지입니다.

시청해 주셔서 감사합니다.

예 감사합니다.

관심을 가져 주셔서 감사합니다. 😄

관심 주셔서 감사합니다. 제가 지금 사이트를 만들고 있습니다. 목적은 영상에서도 계속 강조하지만 지식보다도 더 중요한 것은 연습입니다. 입문때는 작은 퀴즈를 풀거나 조금만 벗어나더라도 사용자가 사용할 수 있는 간단한 앱을 만들 수 있습니다. 간단한 오픈 프로젝트를 시작할 수 있고 어느정도 코드를 볼 수 있다면 제가 맞추어 리뷰나 질문에 대한 답을 더 자세히 드릴수가 있는데요. 이런것을 한번 해보기 위해서입니다. 지금 영상에서는 조금 한계가 있는데요. 다른 분들이 작성한 좋은 내용들을 제가 가져다가 사용하기가 쉽지 않다는겁니다. 링크를 걸어도 잘 볼지 의문이구요. 이에 링크 및 글을 작성해서 다른 분들의 영상이라도 개발에 도움이 되는 내용이라면 볼 수 있도록 생각하고 있습니다. 영상에서처럼 코드를 보고 책을 추천드릴까도 생각하고 Q&A 등의 게시판도 만들어야 하네요. 보시는 분들이 어떻게서라도 실력을 증진에 도움이 되면 좋겠네요. 감사합니다.

이번과 계속해서 하는 이야기는 전통적인 개발입니다. 😅 어쩌면 이번에 올린 영상은 나중에 인공지능 코드의 신뢰도가 95% 이상이 되면 서서히 의미가 퇴색될 수 있습니다. 지금 말한 내용을 AI가 해줄 수 있는 부분입니다. 그렇기에 제가 했을때처럼 연습이 필요할 것인가는 생각해 봐야 할 문제입니다. 하지만 전제가 최상위 개발자를 목표로 했을 경우에는 저는 해야한다고 생각합니다. 적어도 AI가 사기치지 않는지 검토해야 하며 AI가 대체될 수 있는 영역으로는 프론트 엔드의 화면단과 서버 API를 만들때 단순 데이터 입출력과 API 등을 만들때 반복적인 노가다 작업일 겁니다. 이번 내용은 임베디드를 해야 한다면 무조건 짚고 넘어가야 하긴 합니다. 임베디드와 IoT를 한다면 여기서 메모리 및 OS, 하드웨어를 추가로 공부해야 합니다. AI 시대에 중요해지는것은 다음번에 짚어볼 설계와 만들려고 하는 분야의 이해도일 수 있습니다. 제가 사이트를 만들고 있는데요. 퀴즈나 자신이 만드는 프로젝트를 공유하면 해당 프로젝트에 대한 리뷰 혹은 조언등의 기능도 생각해 보고 있습니다. AI 튜터가 궁극적인 목표일 수 있는데요. AI 튜터는 제출한 코드에 코드 리뷰를 통해 좀 더 나은 프로그래밍 코드를 안내해 주는 역할을 생각하고 있지만... 문제는 학습입니다. 작년부터 제가 AI에서 학습을 최적화 하는 것을 시도해보고 있는데요. 이게 상용화 수준까지는... 현재로서는 쉽지 않습니다. 일단 목표가 AI를 대비한 공부라기보다는 실력을 높이는데 초점을 맞추고 있습니다. 이유는 앞으로의 시대는 실력있는 개발자가 더욱더 대접받는 시대가 올 것이라 생각합니다. 예를들어 자율주행을 대비해 자동차 제어 프로그래밍을 한다고 합시다. 제가 계속 Error 0, Warning 0를 많이 강조하는데요. 이런 분야에서는 오류 하나로 몇 명이 죽거나 다칠지 모르는 분야입니다. 그리고 그렇게 크리티컬한 분야를 담당하는 개발자의 연봉은 작지 않을 겁니다.

해당 영상은 우선 앞으로의 10년에 대해서 생각해 본 사항입니다. 지난 10년을 되돌아본다면 스마트폰으로 인한 변화가 있었다고 봅니다. 그리고 앞으로의 10년은 AI가 세상 밖으로 나오려면 실제 물리적으로 움직여야 하기에 임베디드와 IoT 그리고 AI의 결합으로 변화가 올 것이라고 생각했습니다. 모든것이 로봇으로 의해서 동작하는 세상이 앞으로 30년 안에는 올까요? 아니면 지금 세대가 죽은 다음에는 오게 될까요? 어쩌면 앞으로의 10년 안에 AI에 의한 군비 경쟁으로 세계에 위협이 되는 가능성도 있습니다. 아니면 지금 예상과는 달리 스스로 학습된 AI가 등장하여 사람을 학살하는 영화같은 일도 배제할 수 없습니다. 제가 생각하는 이상적인 미래는 의식주의 해결은 로봇이 해 주며 사람은 더 가치있는 일을 할 수 있다고 생각하는 겁니다. 더 가치있는 일이란 여러가지가 있을 수 있겠죠. 만일 제가 정말 돈이 많고 자유롭다면 우주와 블랙홀, 혹은 심해를 연구해봤을 수 있습니다. 로봇이 생산을 책임지고 그 안에서 사람이 새로운 규칙을 만들고 사는 계획 도시를 만들 수 있을까? 라는 상상이 제가 정말 이상적으로 상상하는 일이기도 합니다. 그냥 어떠한 길도 열려 있는 미래에 제가 원하는 미래가 될 수 있기를 바랄 뿐입니다. 하지만 이상은 이렇게 꿈꾸더라도 현실을 봐야 합니다. 소프트웨어 개발자는 실력이 없다면 AI에 대체되고 실력있는 개발자의 코어 개발자가 살아남는 시대가 올 겁니다. 100명의 입문자 보다 1명의 실력있는 개발자가 대우받을 겁니다. 애초에 한국에서 학원에 의한 개발자 양성은 너무 돈을 버는 수단으로만 기능해 왔습니다. 제가 예전에 몇 번 언급한 내용은... 미래를 바꿀수 없다면 미래를 선도해야 한다고 생각합니다. 이러한 기술의 발전을 한 국가가 개인이나 기업, 혹은 국가가 막을 수 있을까요? 오히려 그런 국가는 뒤쳐지게 될겁니다. 그리고 실력 있는 코어 개발자는 그 사람이 죽을 때까지 일자리 걱정을 하지 않아도 될 수 있습니다. 그렇기에 영상의 목적은 실력있는 개발자가 되는것을 이야기하려고 만들었습니다. 말씀하신 내용은 점차 로봇이 사람의 일자리를 차지했을때... 복지에 관한 이야기가 논의되어야 한다고 생각합니다. 빈부 차이로 칼부림 난다고 생각하신 것처럼 저도 영상에서도 빈곤층이 80%가 넘었을때 나라는 뒤엎어 질 수 있다고 생각합니다. 그래서 공산주의는 너무 빨리 출현했다고 생각했었습니다. 공산주의는 사람이 일하지 않아도 생산력이 줄어들지 않는 시대에 더 적합한 체제라고 생각하기 때문입니다. 말씀 감사합니다.

윽..윽...커억... 발음이 문제이긴 합니다. 이게 빨리 고쳐지지는 않을거라... 개발자는 항상 처음에 많은 야망을 가지고 있습니다. 제 영상이 수 십개국에 시청하지 않을까 저어하여 유튜브 캡션으로 자막을 올립니다만... 아무도 누르지 않은 부작용이 있네요. 다음 영상에서는 영상에 아예 자막을 넣는 것을 생각해 보겠습니다.

일단 입문부터 다시한번 정리할건데요. 프로그래밍을 배워야하는 동기부여 설명부터 해서 들어갑니다. 그리고 일반적인 프로그래밍에 관한 이야기이기에 특정 언어에 국한되는 이야기는 아닙니다. 음... 오히려 만일 사용하시는 언어가 있다면 해당 언어에 맞추어 진행할수 있는 사항입니다. 제가 보통 신입 개발자가 오면 예전부터 회사에서는 시간이 날때마다 코드 체크해서 알려주었었는데요. 그냥 그걸 인터넷에서 한번 해보는 것이라고 보시면 됩니다. 회사에서야 웹, 네이티브를 많이 하고 가장 많이 사용하는 프레임워크로 진행한 경우가 많기에 웹이라면 React, NodeJS 를 가지고 많이 하는 편이고 PostgreSql을 많이 사용했었습니다. 여기서 서버라면 기본 NodeExpress에 상당히 많이 수정해서 약간 프레임워크 형식을 만들어 사용합니다. 어려운 사항은 이렇게 프레임워크 형식을 만드는 이유와 작성 목적. 즉 어떻게 만드는가가 어려운 주제이나 단순 사용방법은 쉬운 편임니다. 여기서 프레임 워크는 NodeExpress위에 한번 커스텀으로 더 올리는 내역입니다. 개인적으로 입문이라면 어떠한 언어든지 변수, 상수, 조건문, 순환문으로 끝납니다. 이 4가지로 모든 로직과 표현이 다 있습니다. 그렇기에 익숙한 개발자라면 어떤 언어를 접하더라도 하루안에도 코드를 읽을수가 있고 수정할수도 있습니다. 물론 해당 언어의 특징을 공부하고 손에 익기까지는 시간이 조금 걸릴겁니다. 그냥 언어만을 사용하기보다 특정 프레임워크 위에 올라가는 일이 많기에 해당 프레임워크도 공부해야 겠지요. 그리고 중요한것은 기본적인 Base의 이해입니다. 예를들어 Network 이라면 소켓통신이라던지, 로그인한 사용자가 헤더에 Authorization에 OAuth Key를 적는 이유라던지 아니면 패킷 통신에서 사용자가 주소를 입력하면 실제 해당 통신이 주소값으로 변환되어 서버에 어떤 방식으로 오게 되는지등이 있을 수 있습니다. 이런 Base를 이해해야 나중에 서버를 설정할때 왜 이렇게 설정해야 하는지 이해할수 있습니다. 오히려 분야를 윈도우를 따로 설명해야 하거나 Stream에 관한 설명이나 아니면 개발 설계에 대한 설명이 있을 수도 있습니다. 개인적으로 기술 스택은 그리 중요하다고 생각하지는 않습니다. 기술 스택을 배우는 과정은 금방 걸릴수 있습니다. 단지 실제 제가 실력을 체크할때 입문이라면 얼마나 위에서 말한 변수, 상수, 조건문, 순환문에 익숙해서 잘 표현하는지에 관해 보고, Base에 관해 더 설명이 필요하다면 더 하는것이구요. 사용자가 Backend인지 FrontEnd인지에 따라서 더 특화되어 설명할 경우가 있습니다. 개인적으로는 이렇게 기본을 배우고 해당 사항으로 어떤 프로그램을 만들어 내가 사용하던지 누군가 사용할수 있도록 프로젝트를 만들어보는것이 더 추천하는 편입니다. 이러한 프로젝트를 만들어 봐야 더 자세한 사항을 실제적으로 체감할 수 있습니다. 만일 진행하는 프로젝트가 있다면 해당 프로젝트의 코드를 보고 조언할수도 있을 것 같네요. 일단은 제가 기본적으로 입문부터 설명을 해 드릴거구요. 만일 프로젝트 진행한 부분이 있으시거나 질문하시거나 코드를 볼수 있다면 제가 좀더 자세한 사항을 이야기하기 편하기는 합니다. 아직 초기 단계이며 사이트도 구체적으로 만들기 전이라 잡힌것은 없습니다. 지금 많이 하는 웹이라면 React (혹은 뷰나 플로터로도 해볼수 있습니다. 일반적으로 팀원이 편한걸 선택하는 편입니다.) NodeJS (만일 제대로된 사이트를 만든다면 노드를 주로 선택합니다. 작은 프로젝트나 AI라면 장고도 괜찮습니다. 이유는 서버 속도 때문입니다.) PostgreSql 로 (Mysql이나 MariaDB는 선호하지 않습니다. MySql은 오라클이라 유료로 사용해야 실 퍼포먼스가 나올수 있습니다.) 진행할 수 있습니다. 제가 실 프로젝트를 만들기 권하는 이유가 어떤 프로젝트를 시도하고 만드느냐에 따라 오히려 해당 기술스택이 정해집니다. 해당 프로젝트를 가장 편하게 만들수 있는 기술 스택이 달라질수 있기 때문입니다. 예를들어 제가 연구소에서 AI에 관해 이런저런 테스트를 하면서 한다면 파이썬의 장고를 선택할 수 있습니다. 윈도우에서 일반 어플리케이션을 만들때는 제가 예전에는 델파이를 선택했습니다. 만일 일반 서버를 만든다면 리눅스를 선택하겠고 속도에 민감하다면 C++을 선택한 적도 있습니다. 이렇게 선택하는 이유는 같은 기능이라도 만드는 시간이 차이나기 때문입니다. 예를들어서 제가 오라클 게이트웨이 서버를 만들었을때 윈도우로 만드는 코드가 몇천라인으로 만들어야 하는 내역이 리눅스로는 몇백라인이면 같은 기능을 제공할 경우도 있습니다. 오히려 기술 스택은 개발자가 이용하는 툴일 수 있습니다.

좋게 보아 주셔서 갑사합니다.

네 ... 알겠습니다. 🤣🤣 설명의.... 가독성 이군요. 😂😂

실제는 저 또한 영상을 찍기 전까지 계속 vi만을 사용했습니다. 제 경우는 오래된 습관이고 크게 불편하지 않았기 때문입니다. 말씀하신 것처럼 GUI와 병행해서 사용하면 그다지 크게 불편하다는 생각도 들지 않기도 합니다. 그런다 문득 VI 명령어를 정리하면서 만일 VI를 처음 접하시는 분들에게는 학습 곡선 때문에 VI를 그다지 크게 추천하지는 못할것 같다는 생각이 들어서 찍게 되었습니다. 개인적으로는 VI의 강점은 터미널 상황에서 긴 문서를 작성할때 상당히 강력한 툴이라고 생각했습니다. 간단한 편집은 어떤 도구를 사용하던지 그건 선택사항이라고 생각했거든요. 언급하신 것처럼 GUI와 병행해서 사용했을때 키가 혼돈이 된다면 실수를 방지하기 위해서 VI를 선택하는 것도 좋은 선택일 수도 있을 것 같습니다. 아무래도 해당 에디터는 서버에서 사용할 확률이 높기에 서버에서의 오타나 실수는 크리티컬 하니까요. 좋은 의견 감사합니다. 👍

시청해주셔서 감사합니다. 😄

다... 다음에는 작게 하겠습니다.

네 맞는 내용입니다. 제가 영상을 다시보니 touch를 파일을 생성한다고 설명했군요. 지적해 주셔서 감사합니다.

아뇨 버그레포트한 내역입니다.

제가 시간이 나게 되면 완전히 동작되는 버전을 한번 오픈소스로 올려보겠습니다. 영상을 올릴때에도 코드도 새로 작성하고 완전히 돌아가는 버전을 만들었을건데요. 오픈소스로는 올리지 않았었네요. 개인적으로는 영상을 보고 한번 자신이 코드로 작성해 보라는 의도는 있었는데요. 지금은 예시를 보여드리는 것도 좋다고 생각이 들고 있습니다.

@@bgprogramming7929 만약 추후 오픈소스로 올려주신다면 연구해서 Go로 포팅 해보겠습니다.

UUID의 경우 찍어서 맞추기는 쉽지 않습니다. 해킹의 방지는 프로젝트의 규모등에 따라 달라지게 되는데요. 가장 좋은 해킹 방지는 해킹에 의한 이득을 주지 않는 것입니다. 해커 툴을 사용한 공격의 경우 그 사용자가 IP 추적등의 위험에 대비해야 할 수 있습니다. 일반적으로 해킹을 시도해도 그냥 넘어가는 경우도 많지만, 정말 악의적이고 지속적으로 해킹을 시도한다고 판단되면 IP 추적후 업무 방해죄로 고소할 수 있습니다. 말씀하신 해킹 방지는 유명해지고 카카오, 네이버등의 규모가 된다면 점점 많은 대비를 하게 될겁니다. SM에서 제가 잠시 맡았던 방송신청 페이지 제작이 오히려 말씀하시는 해킹의 니즈가 있는 프로젝트였을 겁니다. ua-cam.com/video/cmZkuw0ELF0/v-deo.html 해당 프로젝트에서는 해킹 시도하는 IP를 선별하여 악의적인 해킹 시도와 방송 신청을 빠르게 하려고 하는 매크로 사용을 구분해서 방비했었습니다. 초기 스타트업은 말씀하신 해킹공격에 대한 고려보다는 빠른 개발이 우선이라고 생각합니다. 그리고 초기에는 암호를 해시 알고리즘보다는 보안에 더 강력한 알고리즘으로 변경하는 것이 초기에 훨씬 좋지 않을까 합니다.

서비스를 써서 저장하지 않고 직접 관리합니다. S3가 초반 프로젝트에서는 상당히 편하기는 합니다. 파일에 관한 많은 사항을 신경쓰지 않을 수 있지요. 하지만 사업이 커지게 된다면 S3에 저장된 자료들이 전부 비용이 발생하는데요. 해당 문제와 S3에 묶이게 되면 AWS에서 떠나기가 쉽지 않습니다. 프로젝트에서 1명당 사용하는 평균 파일 용량을 계산해서 내가 목표로 하는 유저수등을 계산하면 어느정도의 디스크 공간이 산출됩니다. 그리고 해당 파일들을 직접 관리한다면 어느 시스템에 묶이지 않고 자유롭게 이전할 수 있습니다.

제가 오히려 퇴사를 하고 교육쪽을 시도하려고 생각하고 있습니다. 관심을 가져주셔서 감사합니다.

예. 구인하고 있습니다.

@@bgprogramming7929 혹시 실례가 안된다면 이력서 한번 넣어봐도 될까요? ㅎㅎ 😅😂😀

영상의 일이 계기가되서 회사를 다니니 시간이 안나서 일단 기본적인 앱과 프로젝트 베이스를 만들어 놓고 나와서 개발 교육쪽을 한번 생각해 보고 있습니다.

@@bgprogramming7929 나중에 개발 교육쪽으로 회사를 차린다는 말씀이신가요 ..? 혹시라도 직원이 필요하실때 불러주시면 감사하겠습니다!

@@user-jh3by8pd6i 항상 관심을 가져주셔서 감사합니다. 일단 최우선 과제는 개발자 분들의 실제 실력 향상을 생각해 보고 있습니다. 그 이후 회사를 만든다면 수익 모델을 잡아야 할 것 같습니다. 말씀이라도 감사합니다. =)

1. 개인적으로는 규모에 관계없이 나를 이끌어줄수 있는 사수가 있는곳으로 가는것이 좋다고 생각합니다. 가상의 개발자 A의 케이스를 한번 이야기하겠습니다. 개발자 A는 비전공 출신의 개발자입니다. 어느정도 인지도 있는 학원 캠퍼스의 6개월 과정을 수료했습니다. 학원에서는 실무에서 많이 물어보고 필요하는 것들을 이것저것 많이 가르쳐 주었습니다. 그리고 실전 프로젝트 몇개를 시도하고 이 과정을 마무리를 해서 이것을 바탕으로 중소 기업에 취업하였습니다. 그런데 막상 취업해보니 회사는 일을 맡기기 바빴습니다. PM은 실제 개발에 대한 세부사항은 알지 못하고 영업 및 일정 조율만을 했습니다. A씨는 그래도 맡은 일에 책임을 가지고 꾸역꾸역 일을 하면서 어떻게든 프로젝트를 만들었습니다. 그러나 자신의 실력이 좋은건지 나쁜건지 자신이 판단할 수가 없었습니다. 그리고 2~3년 지나고 경력이 어느정도 쌓이고 지금보다는 규모가 있는 SI 중견 기업으로 이직을 했습니다. 그런데 여기서도 상황은 비슷했습니다. 사수는 없이 이리저리 일에 치이기 바빴습니다. 그렇게 몇년 회사에서 일하니 처음 배웠던 개발 언어가 약간 구시대의 언어가 되었습니다. 그리고 나이가 들어 32~35세 즈음되고 차장정도의 직급이 되자 회사는 그동안 다녔던 공로가 있기에 자신을 PM 자리를 맡겼습니다. 그런데 이런 PM은 기존 개발과는 달랐습니다. 개발보다는 일정조율이나 영업또한 해야 했지요. 그러나 운이 좋게도 자신은 PM 적성이 어느정도 적성이 맞아 PM 역할로 팀을 이끌게 되었습니다. 자신의 동기는 PM이 되었지만 성과가 나지않아 이직을 하는 경우도 있었습니다. 이렇게 나이가 들어 40이 넘어가니 이제는 회사에서 은근히 퇴직을 강요받는 위치가 되게 되었습니다. 지금 해당 사항은 제가 15년 정도전에 생각했던 가상의 개발자 시나리오입니다. 그 당시는 회사의 정년이 그렇게 길지 않았습니다. 그런데 이런 가상의 시나리오가 지금도 아예 말이 되지 않는 시나리오는 아닌것 같습니다. 개인적으로 회사를 선택할때 가장 좋은것은 내가 배울수 있는 곳인가? 하는 것이라고 생각합니다. 개발자에게 가장 중요한것은 자신의 실력 그 자체입니다. 제가 이력서를 볼때는 나이와 이력서를 아예 주지 말라고 합니다. 오로지 포토폴리오와 코드만을 달라고 이야기합니다. 즉, 어떤 사람이 어떤 프로젝트를 수행했는지 그리고 해당 프로젝트에서 어떤 역할을 했는지. 그리고 코드는 어떤지만 보게 됩니다. 말과 이론은 괜찮지만 실제 같이 일해보면 정작 일을 잘 못하는 경우도 많았거든요. 2. 소프트웨어 기업이 업체마다 분위기와 근무 형태등이 너무 많이 차이가 나이에 이건 어떻게 답변해 드릴수 없을 것 같습니다. 카카오, 네이버, 삼성 및 국내 대기업 회사, NC등 이게 분야별, 업체별로 근무 형태가 상당히 다릅니다. 추천순으로는 외국의 인지도 있는 소프트웨어 업체 혹은 국내 소프트웨어를 주력으로 하는 업체인 것 같습니다. 그러나 해당 사항은 자신의 실력이 있을때 근무환경이 괜찮은 곳이지 이것이 자신의 실력을 대변하지는 않습니다. 회사의 경쟁 업체의 CTO는 나사에서 인공위성 프로젝트를 개발한 사람이었는데요. 소프트웨어는 점점 글로벌로 갈 것이고 경쟁자는 세계에서 알아주는 대학 출신일 확률이 높습니다. 거기서도 10년 이상 일해서 살아남은 사람들이 경쟁 상대가 되겠지요. 개발자라면 어떠한 길을 선택해도 결국 자신의 개발 실력이 자신을 나타내게 될 겁니다. 3. 혼자서 개발했다고 하더라도 실력이 충분하면 괜찮습니다. 하지만 현실적으로는 혼자서 개발하면 비교 대상이 없어서 자신의 실력 평가가 어려울 수 있습니다. 꾸준히 공부하고 프로그램 만들어서 소프트웨어를 이해하는 것이 중요할 것 같습니다. 개인적으로 년차가 중요하다고 생각하지 않습니다. 10년 이상의 경력을 가진분들이 실제 실력이 그리 뛰어나지 않는 경우도 많이 볼수 있거든요. 만일 코드 리뷰를 원하시면 제가 한번 볼수도 있을 것 같습니다. 감사합니다.

@@bgprogramming7929 답변 정말 감사합니다! 도움 많이 되었습니다! 😄

현재 제가 회사 일을 하고 있습니다. 이에 시간이 많이 남는 상황은 아닙니다. 보통은 회사에서 개발자분들 시간나면 알려드리고 있구요. 일단 질문사항이 있으시면 댓글이나 만들다만;;;; spacehubsociety.com 라는 곳의 게시판에 올려주시면 답변해드리겠습니다. 그 시간 외에는 시간이 일반적으로 평일 밤이나 주말정도 밖에 되지 않는데요. 만일 질문 사항이나 가이드가 필요하다면 알려드리는 방향으로 하겠습니다. 온라인 미팅이나 그런 도구를 이용해도 될 것 같구요. 일단 어떤 방향이던지 말씀 주시면 될 것 같습니다.

정말 감사합니다!😂@@bgprogramming7929

@@bgprogramming7929 현재 제 포지션이 웹 개발 2~3년차 정도되었고 DB설계부터 프론트&백엔드 가리지않고 하고있습니다. 다만 지금까지 다닌회사들이 전부 개발자가 저혼자이거나 2~3명 남짓한 작은회사였구요 대부분 혼자서 프로젝트를 맡아서 한경우가 많았습니다. 기술스택도 가리지않고 이것저것 끊임없이 공부하는 편입니다. 메인으로 php, javascript, jquery 에 간간히 node를 사용한편이구요. 이런상태로 3~4년을 채우고 나중엔 규모가 있는 기업으로 넘어가겠지만 .. 아래 질문들이 제가 궁금한사항입니다. 1. 제가 지금 잘하고있는건지 - 이렇게 글로만 읽으면 잘모르실수도 있을텐데 이력서라도 한번 봐주실 수 있으신지 여쭙고싶습니다 ? 2. 네임벨류있는 IT기업에 가신분들은 어떤식으로 개발을 하는지? 3. 그분들은 코드리뷰를 통한 성장을 하거나 주위에 시니어 개발자들을 목표로 삼고 가실텐데 이런 개발자분들과 비교했을때 이렇게 혼자서 계속 개발해서 3~4년을 채워도 되는건가? 이런게 걱정이더라구요.. 감사합니다 :)

문제는 이걸 업데이트하려고 해도 너무 오래 지난 버전이라 업데이트하기도 힘들었다는 겁니다. 이 프로젝트의 경우는 새로 만드는 것이 나았던 상황이었습니다. 그대로 사용하면 문제가 없었겠지만 소프트웨어라는 것이 계속 업데이트 하면서 개선해나가야 할 경우가 많아서요.

이렇게 기본적인 것부터 튼튼히 잡아가서 구축하면 초기에는 귀찮고 프로젝트 진행이 더뎌 보일 수 있습니다. 하지만 프로젝트 크기가 점점 커졌을 때 이러한 사항이 정말 큰 도움이 될 겁니다. 프로젝트의 크기가 커졌을 때 가장 문제 상황은 어디서 잘못 되었는지도 분간하기 힘든 경우입니다. 그렇다면 이 경우 팀끼리 책임 전가가 있을 수 있습니다. 테스트 주도 개발이 유명해진 계기가 책의 저자인 켄트백님이 거의 실패한 대규모 프로젝트를 테스트 주도 개발로 성공 시킨 것에 있습니다. 테스트 주도 개발의 장점은 프로젝트 크기가 커졌을때 In, Out 결과값을 명확히 함으로써 어느 부분에서 오류가 발생했는지 빠르게 검토하는데 있다고 생각합니다. 안 좋은 코드는 프로젝트 규모가 커졌을 때 그 유지 보수 비용이 지수로 증가 될 수 있습니다. 한 곳을 고쳤는데 전혀 다른 곳에서 버그가 발생하는 경우들이 많다면 코드의 기본이 튼실하지 않음에 있습니다. 하지만 튼튼한 코드를 쌓아간다면 복잡도가 증가해도 기존에 만들어 놓은 코드가 오히려 재사용을 하면서 비용을 감소 시킬 수 있습니다. 또한 말했다시피 기존에 stable 한 코드는 오류가 발생할 가능성이 적기에 코드를 살펴보는 구역도 제한적이 됩니다. 버그를 자꾸 감추려고 한다면 stable한 코드는 작성될 수 없습니다. 버그를 빠르게 판별하도록 하고 같은 버그에 다시 당하지 않도록 하면서 코드를 작성하도록 하면 좋습니다.

예전에 3000개가 넘는 경고가 있는 프로젝트도 있었는데요. 일반적으로 이렇게 경고가 많은 프로젝트는 설계 또한 좋지 못한 경우가 많습니다. 이렇게 경고가 많이 발생하는 프로젝트의 경우 규모가 커지면 거의 반드시 무너지더라구요.

조만간 자기소개 영상을 올려보도록 해 보겠습니다. 제 개발 경력은 20년이 넘은 것 같습니다. 10년 이상 계속 CTO를 했었습니다. 대중에게 알려진 것은 잔디 서비스 정도 이지만 음.... 초기 창업자와 관계가 좋지 않기에 잘 언급하지 않습니다. 스파크랩이라는 엑셀레이터에 6기로 참여하기도 했습니다.

말씀하신 것처럼 지금 내용은 기획/영업하는 사람에게 더 중요한 내용일 수 있습니다. =) 제대로 된 프로그램을 만들고 운영하려면 계속 소통해야 합니다. 기획/영업하는 사람이 보는 시각과 개발자가보는 시각이 다르고 해결 방안이 다를수 있습니다. 특히 프로젝트 초반일수록 정말 많은 소통이 필요합니다. 말씀하신 무엇을 어떻게 해결하는가? 라는 것을 정확히 파악을 해야 목적지가 바로 잡힙니다. 이게 정확히 잡히지 않않다면 필패입니다. 명확하지 않은 목표가 두루뭉슬하게 이야기가 된다면 기획/영업하는 사람과 개발자가 생각하는 프로그램이 달라지게 됩니다. 그리고 이런 의도나 기획들이 정확히 소통되어야 개발자는 자신이 파악한대로 대비해서 만들게 됩니다.

도움이 되셨다니 다행이네요. 😀

신고를 하는 목적이 무엇이죠? 공익을 위한건가요? 개인의 복수인가요?

저는 홀더로써 지난번에 올리신 영상과 이번에 올리신 영상을 여러번 재반복해서 봤습니다. 히든 버너 등에 문제가 있다는걸 사전에 인지하고 계셨다는 의미신데 만약 급여를 정상적으로 잘받으셨고 토큰을 이상없이 받으셨으면 입싹 닫고 아무일도 없으셨겠죠? 저는 이 부분이 참 위선스럽다고 느껴집니다.

@@kkkkk_ 글쎄요. 언급하지 않은 문제가 있습니다. 해당 사항은 민감한 부분입니다. 진짜 범죄와 관계 있을수 있으니까요. 제가 거의 개발만 한 상황 이구요. 음... 슬렉 같은 것을 보여드려도 좋은데... 진짜 허리 다쳐가면서 개발을 정말 많이 한 상황입니다. 그 2년간 거의 대부분의 제품을 혼자 개발하다시피한 상황이구요. CSS 할줄 아는 개발자 가르쳐가면서 개발했습니다. 그리고 정말 약속등이 아무것도 지켜지지 않아 나오게 된 상황입니다. 나오고 나서 정신차리고 보니 이상한 정황이 많이 발견되었네요.

@@kkkkk_ 지금 이 사실만을 본다면 말씀한것처럼 위선적이고 개인의 복수라고 생각하는 것도 당연하다고 생각되어 지네요. 그런데 그렇게 자기 이익만을 추구했으면 애초에 라우들리에 들어가지 않는 것이 맞습니다. 왜냐면 제가 받는 연봉의 1/3 수준입니다. 코인도 솔직히 얼마줄지 약속하지도 않았구요. 처음에는 해당 대표가 사기꾼으로 몰렸는데... 제품이 안나와서 그런것 아닌가해서 그냥 도와주는 측면에서 만들어 준 상황입니다.

@@kkkkk_ 프리랜서 6000이라면 신입 연봉인데요. 그때 당시 코로나로 신입 연봉이 6000이 넘어가는 시기였습니다. 음...제가 개발로는 계속 슈퍼개발자로 불렸는데요. 조건이 너무 맞지 않습니다. 제 영상을 보시면 아시겠지만 제 경우는 한국의 미래는 제조업이 아니라 소프트웨어와 문화 컨텐츠가 되어야 한다고 생각했습니다. 사람이 모두 가질 수 없으니 내가 포기할 수 있는 것은 포기하고 이룰 수 있는것은 이루고 싶었구요. 그 와중에 7년 동안 끌어온 넥스트메이커스의 유산을 마무리 짓겠다라는 목표가 훨씬 컷습니다.

예 기운이 많이 나네요. 😄 다시 개발 이야기가 진행되면 좋겠네요. 6개월이면 재미있기도하고 아직 모르는 부분도 많을 겁니다. 자신의 생각대로 코딩이 잘 안될수도 있구요. 왕도가 없기에 꾸준히 코딩이 필요합니다. 굿잡님도 힘내시기를 바랍니다. Good Job!