Видео

이게 무슨 의미가 있나 둘다 해보고 자기한테 맞는 방식 따라가면 되는데 정답이 어딧어

수요와 공급 측면에서 맞는 말 아니오? 개나 소나 다 컴공에 인공지능 한다고 난리 들이니.....

컴퓨터 공학 전공 학부생 입니다. 최근 개발자 취업 시장도 안좋다고 하고 세부 직무도 못정해서 막막해 하고 있었는데 영상 덕분에 앞으로의 질문의 방향은 잡을 수 있을 것 같습니다. 감사합니다.

뭔가 잘못된거 아닌가요. 만들면서 배우라는게 정말 아무런 이론공부 없이 진행하라는게 아닐텐데요. 만들면서 배우라의 핵심은 명확한 목표를 설정하고 짧은 성과를 통해 흥미 유발이 중요하다고 많이 얘기하죠. 그런데 핵심이 이렇다고 이론 공부를 전혀 하지 않는다는 말은 아니죠. 막히는 구간이 생기면 이론의 필요성을 느낄 수 밖에 없고 그 분야의 존재 이유와 사용처를 온전히 이해하며 공부하게되죠. 그렇게 부족한 이론체계를 조금씩 메꿔가는게 '만들면서 배워나가는 과정'이라고 생각합니다. 반대로 탑다운 방식이라고 온전히 이론만 쭉 공부해서 다 마스터한 뒤에 개발하지도 않죠. 일정 수준까지 공부한 후 실습을 통해 짧게나마 직접 개발해보는 과정을 경험하죠. 결국 어떤 방식을 취하든 실습과 이론 공부가 어우러질 수 밖에 없기에 영상에서 얘기하는 것처럼 만들면서 배우는 방법의 맹점은 그리 공감되지 않네요. 오히려 취미나 개인적인 공부를 위해 프로그래밍을 공부하는 분이 있다면 '만들면서 배우는게' 최선이라고 봅니다. 워낙 개발분야의 이론이 세세하게 짜여져있기 때문에 아무것도 모르는 입장에선 어떤 이론을 공부해야하는지조차 감을 잡기 어렵습니다. 만들면서 어떤 이론은 왜 배워야하고 어디에 써먹어야하는지 체감하면서 공부해나가는 쪽이 이론부터 공부하는 쪽보다 공부하기 훨씬 수월합니다. 이론만 공부하면 정말정말 재미없어요. 게임 개발위해 처음 공부시작했을 때 베개보다 두꺼운 c++책으로 시작했다가 몇 번을 포기했는지 모릅니다. 지금에야 그 책을 보면 왜 이렇게 자세하고 상세하게 설명했는지 이해는 되지만 다시 그 시절로 돌아간다해도 그 책으로는 공부 안할겁니다. 무조건 만들면서 배우는게 좋고 그렇게 만들면서 공부할 수 있는 서비스도 정말 많고 잘 되어있습니다. 전 지금도 잘 모르는 분야 공부할 때는 무조건 얇고 읽기 쉬운 책부터 보면서 대충 따라 만들어보면서 익혀갑니다. 글만 빽빽한 이론서는 눈에도 안들어오고 공부하기도 싫어요.. 어차피 업으로 코딩공부하는 사람 아니면 더 이상 죽자살자 공부할 필요 없는 시대이고 재밌게 공부하는게 최선이라고 봅니다.

저도 탑다운 바텀업 바뀌었다고 생각합니다. 탑다운은 목적을 위해 필요한 수단만 사용합니다. 바텀업은 수단부터 먼저 만든 후 목적에 맞게 사용하려고 합니다. 만들면서 배운다는 말은 필요하고 실제 쓰이는 것부터 배우는 탑다운입니다. 반대로 실제 쓰이는지 모르겠고 현학적이고 추상적인 이론들은 바텀업으로 기초를 만듭니다..

진짜 최악이다 이런 홍보.

1.5배속인가요? 말이 조금 빠른 느낌입니다.

영상을 다보지도 않고 댓글부터 다는 족속들이 많아서 댓글 남깁니다. 바텀업 뜻도 모르는 무지랭이들은 무시하시고 파이팅 하세요. 양질의 영상 잘 보고 있습니다 !

왤케 부정적이냐ㅋㅋㅋ

개발자 ... 이 업계가 인력이 늘었다가 줄었다가 하는데요 .... 인력이 남아돌고 일이 부족한 비수기에 살아남는 개발자가 소수입니다.. ... 그리고 사실 실력있는 개발자라는 것이 생각보다 쉽지가 않아요.... 파고들면 한없이 파고들어야 하고 ... 개발은 그냥 자기가 하고 싶은 일을 살짝 활용할수 있는 정도만 하면 되요. 이걸로 취업하는건 .... 비추입니다. 일단 개발자로 취업하면 경쟁이 시작되고 경쟁에서 이기기 위해서 더 파고들게 되는데 ... 이게 별로 비효율적이에요. 여기서 경쟁력 있는 개발자가 되라는 식으로 말씀하셨는데 ... 정말 개발이 미치도록 좋은 사람이나 하시구요.... 그냥 개발에 대해서 개념만 가지고 다른 일을 알아보는 것이 더 효율적입니다. 밤새도록 프로젝트 하고 .... 연장수당이나 야근수당 커녕 집에 갈 택시비도 못받는 그런 일이 ... 요즘은 없나요? 나때는 그랬어요 .... 개발하는데 젊음을 너무 오래 낭비한것이 좀 후회스러워요.

이젠 개발 공부을 넘어서 다른 분야와의 접목을 통해 독자적인 가치를 만들어야 살아남는 시대라는 얘기인가여

일단 공감 받지못하고 대부분 반대여론이 많은 것을 보면 이번 영상은 망했군요

제목부터 바꿔야 할 듯 "개발자의 근본적인 약점과 해결책" 이 아니라 "국비 보조등으로 개벌업계에 뛰어든 비전공자 출신 웹개발자의 약점과 해결책"에 가깝겠네.. 제목 이렇게 어그로성으로 지으면 현업 개발자들 승질낼듯 ㅋㅋㅋ

하나 마나한 소리하고 있네 ㅋㅋㅋ 기술은 사용하기 쉬운 방향으로 발전하기 마련임 2000년 초반 수십명의 웹개발자가 수개월을 할 일을 지금 초딩 중딩이 프레임워크 하나 배우고 유튜브 딸깍해서 몇주만에 가능한 시대임 시스템 개발이 무슨 성역처럼 얘기하는데 일단 여긴 수요가 어플리케이션 개발자 대비 말도안되게 적음 거기다 여기도 당연하게도 AI 시대에 영향을 받는건 당연한거고 시스템 개발자가 맨날 C/C++에 맨날 쓰던 라이브러리랑 컨셉으로 한우물만 파던거에 비해서 웹 / 어플리케이션 개발은 하루에도 수십 수백개의 새 개념 새 프레임워크 새 라이브러리가 난무함 각 분야마다 특성이랑 장단점이 있는거지 뭐는 성역이고 뭐는 아니라고 하는게 어불성설 도메인지식 중요한 건 이제와서 그런게 아니라 원래 그래 아재야 ㅋㅋㅋ 기본 기술 지식은 영어 배우는 걸로 치면 문법 단어 간단한 회화 배우는 그자체에 가깝고 도메인 지식 바탕으로 비즈니스 로직 짜는게 실무인거지 영어배워 통역하고 취직해서 외국인들이랑 실무 커뮤니케이션 하고 그런거란 말 뭔 수십년동안 당연하게 있어왔던 일을 뭔 이제사 그런 것 처럼 말하는데 할 말이 없네 원래 그래왔고 앞으로도 그럴거임 그리고 장담컨데 단기간에 AI가 시니어 개발작까지 대체하는 일은 아직은 없을 거임 아직 돈벌기회는 더 남음 그게 얼마나 오래갈지는 모르겠지마만

뭐라노 처음에는 닥치고 타이핑이ㅡ답임

하고싶은 사람은 하세요. 무슨 일을 하든 내가 하고싶어서 하는 게 아니면 힘든 시기때마다 무너지고 다른 일자리로 옮기려고 하죠. 내가 좋아서 하는 일은 누가 뭐래도 하게됩니다.

옥순이 짱

'이론과 실습을 적절히 병행'하라는 말로 요약되는 듯 합니다. 우리는 초등학교에서 '+' 라는 기호의 본질적인 의미를 깨닫기 전에 1+1, 10+20, 123+321 같은 실전(?) 문제를 풀었습니다. 그리고 더하기의 의미를 복소수의 영역으로 넘어가는 순간 우리는 새로운 정의를 '배워야만' 합니다. 그러나 그걸 응용하는건 또 여전히 이리저리 해봐야 되는 영역입니다. talk is cheap 이라는 토발즈의 말은 "너나 나나 지금 무슨 상황인지 이해하고 있으니까 이제 결과(code)로 얘기해보자" 라고 생각합니다. 즉, 둘 중 한명이 내용을 이해하지 못하는 상태라면, talk (learn) 은 여전히 필요합니다. 댓글에 찬반이 많은걸 보니 오늘도 좋은 내용이네요. 잘 봤습니다!

하는 사람이 많다면 그들을 이끌 단 하나의 용기있는 리더가 필요하겠네요..

좋은 영상 감사합니다. 덕분에 많이 생각해 보고 생각을 정리해 보았습니다. 1. 제가 들은 “만들면서 배워라”라는 맥락은, “소프트웨어는 코딩이 전부가 아니다”라는 맥락입니다. 반면 영상에서는 “닥치고 코드를 보여줘라”라는 말을 "만들면서 배워라"라는 말의 예시로써 인용하고 시작하는데, 먼저 여기서 갸우뚱 했습니다. 혹시 내가 “만들면서 배워라”라는 말을 잘못 이해했나? 싶었습니다. 2. 몇 번이고 돌려 봐도, 영상에서 말씀하신 bottom-up/top-down이 어떤 대비를 지칭하는 것인지 불분명한 것 같습니다. 실습 vs 이론이라는 대비로써 영상 초반에는 구체적인 것 vs 추상적인 것을 지칭하다가, 중반부터는 쉬운 것 vs 어려운 것을 지칭하고, 후반에 이르러서는 단순한 것 vs 복잡한 것을 지칭하는 것처럼 보입니다. 이 점은 제게는 영상을 이해하는데 큰 문제점이 되었습니다. 왜냐하면 (아시다시피) 소프트웨어에서 bottom-up이란 부분을 통해 전체를 이해하는 접근 방식을 의미하고, 쉽다/단순하다/구체적이다라는 뉘앙스는 없습니다. 단순히 작다 vs 크다라는 의미를 가집니다. 반면 사회과학/경제학에서 bottom-up은 구체적인 것으로부터 추상적인 것을 해석하는 방법을 주로 일컫습니다. 철학/수학에서 bottom/top은 근원적인 것 vs 파생적인 것을 의미합니다. 이렇듯 bottom-up으로 표현되는 맥락이 워낙 다양하기 때문에, 어떤 대비에 집중해야할지 혼란스러웠습니다. 부딪히면서 배우다 보면 상상도 못한 엉뚱한 곳에서 문제가 발생하기도 합니다. 작은 부분에 집중하다 보면 큰 결을 놓치게 되고, 따라서 “부딪히면서 배우는 것은 top-down식 사고방식을 요구한다”고 주장할 수도 있을 것 같습니다. “bottom-up 방식의 학습”이라는 용어를 설명하는데에 시간을 더 할애하셨으면 영상의 취지를 금방 이해했을 것 같습니다. 3. 영상의 취지를 이렇게 이해했습니다: 1. 만들면서 배우면 좋은 이유 = 실습을 통한 학습의 장점 + 소프트웨어의 특징 2. 실습을 통한 학습은 쉽고 실질적이다. 3. 소프트웨어의 특징은 진입장벽이 낮고, 피드백이 빠르다. 4. 따라서 지속하기 쉽다. 5. 동시에, 복잡한 건 못 한다는 한계점을 가진다. 결론적으로 “만들면서 배우라는 말의 함정”이란, 체계적인 학습의 대안으로써 제시하는 해결책이 아니며, 소프트웨어의 특정 분야를 암묵적으로 포기해야 한다는 것이라고 이해했습니다. 정말 그렇다고 생각했습니다. 4. 이와는 별개로 Bottom-up이라는 표현을 “실습”이라고 치환하면서 영상을 쭉 시청해보아도, 세세한 부분에서 갸우뚱하는 부분이 몇몇 있어서 정리해보았습니다. 1:12 “탑다운 방식으로 배우는 것은 이론적/체계적으로 배울 수 있다는 장점이 있다”
 이 주장이 성립하려면 두 가지를 가정해야 합니다. 1. 이론/체계적 학습은 실습을 통한 학습보다 좋다. 2. 직접 부딪히면서 배워서는 이론/체계를 알기 어렵다. 1번의 가정은 이 영상의 결론에 해당하는 부분이므로 가정해서는 안 될 것 같습니다. 2번 가정은 댓글을 써야겠다고 마음먹은 계기가 되었습니다. 이론이 여러 복잡한 현상을 설명할 수 있는 간단한 원칙을 제시하지 못하면, 이론은 의미가 없습니다. 수 많은 예시를 대충 아는 것보다 적은 수의 예시를 완벽하게 이해하는 것이 이론을 이해하는 데에 훨씬 도움이 된다고 생각해서, 완전히 동의하기 어렵습니다. 1:40 "소프트웨어는 진입장벽이 낮고, 피드백이 빠르다
" 분야마다 다른 것 같습니다. 예컨데 이론 공부는 5만원짜리 두꺼운 책만 있으면 되는 반면, 소프트웨어 실습에는 적어도 백만원을 호가하는 컴퓨터가 필요합니다. 잘 모르지만, 기계공학에서도 값싼 실습, 예컨데 지역 구청에 있는 3d 프린터만 있으면 할 수 있는 실습도 많지 않나요? 또한 전문적인 실습은 소프트웨어도 그닥 싼 것 같진 않습니다. HPC, 대규모 인프라 등 여러 분야는 실습이 안 되니 주로 시뮬레이션으로만 공부하지 않나 싶습니다. 

피드백이 빠른 것도 잘 모르겠습니다. 코드를 쓰다 에러가 나는 건 당연히 빠른 피드백에 해당하겠지만, 기계공학이라면 “볼트가 헛돈다” 수준의 피드백에 지나지 않는, 국소적인 경우가 아닐까 하고 생각합니다. 내 코드가 잘 쓴 코드인지, 내 설계가 좋은 설계인지 알 길이 없고, 치명적인 버그가 한참 지나서야 발견되기도 합니다. 대조적인 예로 들어주신 "생물 실험이 최소한 몇 달이 걸린다"는 것도 잘 모르겠습니다. 눈의 맹점을 확인하는 것처럼, 수 초만에 확인할 수 있는 것도 많지 않나? 하는 생각이 들었습니다.
 3:00 "바텀업 방식이 지속하기 쉽다." 
실습을 통한 학습은 능동적인 과정이고, 이론적/전통적인 교육은 수동적인 과정이니까, 당연히 전자가 더 어렵다고 생각해서 갸우뚱 했습니다.
 3:30 바텀업의 한계: “바텀업도 어차피 어렵다” 3:40 바텀업의 한계 2: “규모가 커지면 바텀업으로는 안 된다”
 처음부터 큰 규모의 시스템을 만들려고 하지 말라는 조언으로, 딱히 작은 규모의 시스템을 만드는 연습을 부정하는 것 같지는 않습니다. 4:30~ “크고 복잡한 규모의 시스템을 공부하는 데에는 바텀업 과정을 쓸 수 없다” 
대단히 동의합니다. 그런데 운영체제를 예로 드는 것은 부적절하지 않나 싶습니다. 예를 들어 리눅스 OS 교과서에는 반드시 커널 소스코드가 예시로 들어가 있습니다. 윈도우 OS 공부는 커널 디버깅을 하며 그야말로 맨땅에 헤딩하는, 바텀업의 원초적인 예시라고 생각합니다.
 앞으로도 좋은 영상 또 부탁드립니다 (_ _)

어그로 ㅋㅋ 할건데용

기업에서 비전공자보다 전공자를 우대하는 이유

복잡한 시스템을 이해할 때 바텀업으로 하는 거에요.

멋있어요😊

글쎄요 복잡한 무언가를 만든사람이 바텀업은 안했을까요?? 너무 흑백논리 같습니다. 기초적인 실습도 이론도 같이 진행되어야지 뭐하나 극단적으로 하나만 선택하는 개발자가 있을까요?? 바텀업은 어찌됐든 복잡한 이론공부를 할 수 밖에 없습니다 나중에 스스로 깨닿는거죠. 기초적인 블로그도 못만드는데 대규모 서비스를 공부하는것도 웃기잖아요? 예시를 들어준 기계공학이나 화학, 생명공학 이것들도 기초적인 실습을 하면서 배워나갑니다.

동의하지않습니다. 어떠한 일을 할 때 필요한 지식이 무엇인지를 정확하게 알고 있다면 그 지식을 먼저 습득하고 진행을 하는게 가능하겠으나, 초보의 경우 "무얼 모르는지 모르는 상태"이기 때문에 일단 부딪혀서 "무얼 모르는지 파악하고" 그 모르는걸 하나씩 알아가는 과정이 더 맞다고 보여지네요. 자기가 무얼 모르는지 아는 사람은 바텀업으로 머리 깨면서 할 필요가 없죠.

기존의 통념에 대해서 반박하기 위한 영상으로 보이긴 하지만 여기에 반박을 해보자면! 1. CS에서 유독 바텀업이 많은 이유 이게 단순히 유용해서라기 보다는 너무 사람들이 탑다운 방식으로 시작하기에 바텀업이 너무 유용한데 대부분이 탑다운으로 가고 있기에 해보라는 의미에서 퍼졌는데 지금은 너무 바텀업으로 치우쳐져있는 느낌입니다. 2. 만들면서 배우라 말 그대로 입니다. 만들면서 배우라는 의미이지 제대로 이해하고 체계를 잡으라는 의미는 아닐듯하네요. 뭔가를 운영하는데 필요한 소프트웨어를 만드는데 만들면서 해보라는건 말이 안되는듯합니다. 말씀드하셨듯이 규모를 확장하고 변경이 자주 일어나는 프로젝트의 경우에는 제대로된 설계게 없다면 운영과 유지보수가 어렵죠. 3. 운영체제를 만들면서 배우라는 의미 이건 제가 탑다운 방식을 고집하며 배운 사람으로써는 무조건 바텀업이라고 생각합니다. 탑다운으로 이해하려면 cpu에서 부터 시작해서 하드웨어의 구조를 이해하고 운영체제의 철학과 프로그래밍의 역사를 한꺼번에 제대로 엮은 교과서가 필요한데 본적이 없는듯합니다. 아니, 애초에 운영체제라는 과목의 교과서들 조차도 바텀업으로 구성해놓았다고 생각합니다. process, scheduler 등 이러한 개념을 차라리 코드의 단위에서 따라 쳐보면서 이해하는게 훨씬 빠르다고 생각합니다. 이게 얼핏보면 운영체제 코드를 보는거나 c언어, 그리고 이걸 띄우고 보는 법, 등등 여러 태클들이 있을텐데 그럼에도 불구하고 이 모든 장벽들이 탑다운에서 나오는 허들보다 엄청나게 낮기 때문에 만들면서 배우는게 낫다고 생각합니다.

이론+실무 다 중요 합니다. 그런데 전제 조건 두 가지가 빠져 있네요. '자신이 좋아하는 공부 성향 기질'과 '현재 주어진 환경'이요. '자신이 좋아하는 공부 성향 기질'은 Bottom-up(바텀업)과 Top-down(탑다운) 다 해보고 자신에게 맞는거 쭉 밀고 나가면 됩니다. 저도 처음엔 코딩공부를 'Bottom-up(바텀업)'으로 했다가 어느 정도 지식이 쌓이니까 'Top-down(탑다운)'으로 바뀌더군요. 장기적으로 보면 '자신이 좋아하는 공부 성향 기질'을 모르면 오래 집중 못 합니다. 그래서 자기 성향이 중요해요. 또 '현재 주어진 환경'은 자기가 현재 학생인지, 취준생 인지, 현직개발자인지에 따라서 공부법이 달라집니다. 학생 아니면 취준생은 인터넷이 떠도는 오픈소스 찾아서 자기 생각대로 바꿔보면 실력이 많이 늘어 납니다. 예를 들면 C언어 제대로 배우고 싶다면 리눅스 커널이 오픈소스에 C로 되어 있으니 그거 분석 하면 왠만한 C언어 소스코드 분석은 다 됩니다. 현직 개발자 면 실력 높일 수 있는 환경이 휠씬 좋습니다. 그 이유는 선배들이나 동료들이 만들어 놓은 소스코드를 참고하면서 자기만의 버전으로 바꾸면서 공부하면 됩니다. 저도 신입사원 시절 그렇게 공부했고, 지금도 동료들 소스코드를 보면서 나만의 버전으로 만들면서 공부하고 있습니다. 그래서 실력을 높이기 위해서는 현직 개발자가 유리하기는 합니다.

전혀공감을 못하겠음 그 이론적으로 알고 시작하는 사람들의 99.999%가 입모아서 하는소리가 닥치고 코드나쳐라임 주둥아리는 진짜 아무런 쓸모가없음 걍코드치기 귀찮고 밍기적거리고싶으니까 책이니 이론이니 하는 이름의 핑계를 대고싶어하는거임 그냥

추상화가 높을 수록 이해하기 어려운데 이를 구체적으로 실습해볼 수 있는 환경은 축복이에요.. 컴공이 타 자연과학, 공학과는 달리 실습 진입장벽이 매우 낮은 것은 축복입니다 이를 학습할 때 적극 활용해야죠 직접 구현해보고 눈으로 돌아가는걸 본 뒤 이론을 접하는거랑 아무런 감도 없이 추상화된 이론을 접할 때 이해도의 차이는 엄청납니다. 그리고 해당 주장은 전제가 조금 잘못된게 탑다운에서 '다운'은 당연하다고 생각하는데 바텀업에서 '업'은 당연하다고 생각하시지 않네요

맞는말. 프로그래밍뿐만아니라 모든일이 기본이 다져져야 세계관이 확장됨. 그냥 예제중심으로 공부를 하게 되면 당장 구현은 가능할지 모르지만 나중에 벽에 부딪힘. 이것이 과연 맞게 돌아가는 것인지. 본인이 모르는 시점이 오게 됨. 코드를 봐도 전혀 개선해야 할 것이 떠오르지 않는 시점이 온다. 어쩌면 전부 갈아엎게되는 불상사가 올지도. 반드시 기본은 알아야 함. 바텀업으로 가더라도 항상 의미를 알고 넘어가는 것이 중요함. 내가 만일 물리학 연구를 한다고 하면 실험을 실행한다고 끝이 아님. 얻어진 결과와 그 과정에 생기는 문제들. 어떻게 발생된 것인지 이해를 해야함.

내가 생각한 '만들면서 배우라'는 말의 의미는 시도를 통해 흥미와 몰입을 가지라는 뜻으로 해석했음. 이 '흥미'와 '몰입'이 있으면 이론이나 다른 기타 여러가지 어렵고 복잡한 요소도 스스로 찾고 알아내려고 하는 탐구심이 발동됨. 즉 '배우려는 자세'가 만들어짐. 바텀 업이니 탑 다운이니 그런 용어 쪽은 잘 모르겠지만 뭔가를 해나갈 때 '배우려는 자세'가 되어 있지 않으면 아무 발전이 없음. 그래서 난 만들면서 배우라는 말에는 발전을 위한 향상심을 고취하란 뜻이 있다고 봄. 중요한 건 본인의 의지. 만들면서 배워도 흥미와 몰입을 얻지 못하면 이 영상에서 말한 단점에 봉착하게 될 것임

의도는 이해했습니다. 그런데 영상을 보는 분들이 이해하기로는 실무 습득을 바텀업이라 하고 이론습득을 탑다운방식이라 이해할 수도 있을 것 같습니다

35년 개발만 지금까지 하고 있는 개발자 입니다. 어떤 언어나 기술을 배울 때, 관련 철학이랑 그에 따른 구현 구조를 공부하지 않고 코딩을 부딪치면서 만든 결과물은 항상 엉망이었습니다. 개발하면서 배우고 그러면서 결과를 내면 된다고 쉽게 이야기하는 개발자들 많았는데, 그 시스템은 그냥 버리는게 답이었습니다.

내용은 공감하지만 탑다운 바텀업 학습이라는 용어는 처음 들어보네요. 대충 느낌상 경험으로 학습, 이론으로 학습이라는 더 좋은 용어가 있는거 같아요. 제 경험상 이론으로 배우는건 직접 코딩하는 것 보다 언제나 효율적입니다. 그래서 저는 새로운 프로그램이 있으면 무조건 책부터 사서 봅니다. 경험으로 새로운 것을 배우려면 그 프로그램의 철학을 추론해야 하지만 책에는 친절하게 설명되어 있거든요. 더 이상 책으로 배울 수 없는 것들은 불가피하게 코딩을 하면서 경험하는거고 그렇게 배우는건 굉장히 고통스러운 과정이죠. 특히 아키텍처 쪽은 정리된 자료도 없고 내가 알더라도 남에게 전수해 줄 수도 없는거 같아요.

바텀업 탑다운 거꾸로 알고계신듯. 그리고 무슨방법이 적합한지는 사람마다 다릅니다. 과학 잘하고 엔지니어적 사고가 좋은사람은 탑다운 방식이 좋을거고, 수학처럼 기초부터 지식을 쌓아나가는 게 맞는사람은 바텀업 방식으로 학습하는게 좋겠죠. 쉽게 비유하면, 체스를 배울때 체스 규칙, 오프닝, 기술 등 이론부터 먼저 배우는게 적합한 사람이 있을거고, 실전 경험으로 먼저 배우는게 적합한 사람이 있는것처럼요. 그런데 고수가 되려면 이론과 실전경험 모두 필요합니다. 즉 어쨋든 둘다 하긴 해야하는데 어떤것이 먼저냐죠

기술은 발전해왔습니다. 지금은 탑다운 방식이라고 말하지만, 과거엔 지금의 TOP개념이 있는지도 몰랐습니다. UNIX초창기에 지금의 운영체계를 상상할 수 있었을까요? 그리고 만들다보면, 알아서 그 문제점에 봉착하게 됩니다. 제 경험상 이론을 배워도 실습이 필요하고, 이론상으로 1) ~~을 ~~로 관리하는게 필요하다.를 배운다하더라도 그 의미를 만들다가 된통 깨지고 훨씬 잘 느끼는것 같습니다. 그러나 때로는 이론을 배웠으면, 삽질은 10시간할 것을 1시간이면 끝내지 않았을까 생각도 듭니다. 근데 그 과정은 만들면서 막혔을때, 관점을 바꿔서 생각하면 됩니다. 그때 보이는 이론지식은 단순히 이론지식이 아닌, 해결책이 될겁니다. [바텀업]이 정답이다 보다는 바텀업과 이론학습에 가중치를 둔다면, 0.9 , 0.1 정도 주겠습니다.

이 영상을 다 보진 않았지만 초반 부분만 보고 드는 생각을 말씀드리자면 말씀해주신 거장들이 만들면서 배우라는 의미는 중요한 것에 집중하라는 걸로 저는 이해했습니다. 즉, 비지니스에 집중하라는 것이죠. 공부를 다하고나서 무언가를 만들려고 하면 공부는 끝이 없기 때문에 정작 중요한 본질을 놓치게 되죠.

바텀업 탑다운 정의가 서로 바뀐거 아닌가요?? 바텀업이 기초부터 배워나가는 의미로 알고 있습니다

기계 소프트웨어쪽은 진짜 사람이 없더라구요. 회사들 아주 몇몇 채용하긴하는데. 지원자수가 한두명될까말까 ㅎㅎㅎ . 사실 그런 분야는 회사도 매우 적고.. 전통적인 산업분야의 단점이.. 거의 대부분 독과점에 보안타령한답시고 너무 빡빡하구.. 물론 오픈소스들도 진짜 복잡한것들 많습니다.. 그러면 바텀이 매우 높은 바텀이 되겠지요 ㅎㅎ

3년째 열심히 프로그래밍하고 있는 갈 길이 먼 주니어 그래픽 엔지니어입니다. 두 방식을 모두 쓰는 것이 중요한 것 같습니다. 이론적인 배경은 엔지니어의 시야 자체를 바꾸는 것 같습니다. 경력이나 이론적인 바탕이 있는 친구나 동료들의 설명을 들을 때면 아 이 사람들은 나와 문제를 다른 차원에서 이해하고 질문하고 있구나 라는 느낌을 많이 받았었습니다. 내가 사실 아무것도 이해하지 못하고 있구나 라는 느낌도 많이 받았었고요. 항공 관련 대기업에서 C++ 엔지니어로 인턴쉽을 했던 것도 도움이 많이 되었습니다. 100MB 정도되는 소스코드가 사실 SOA 의 한 컴포넌트라는 설명을 들었을 때나 Software Architect의 피드백을 들었을때, 실제 산업에서 쓰이는 코드는 단순히 앱 만드는 거랑은 차원 자체가 다르다는 것을 알게 된 후부터 이론적인 공부를 더 열심히 하게 된 것 같습니다. 단지 내가 만들고 싶은 거 만들면서 되는데로 할래, 라는 입장은 엔지니어한테는 게으름이자 오만인 것 같습니다. 컴공을 나오지 않은 프로그래머로서 유투브나 Coursera에서 이론적인 강의를 찾아 들을 때도 있지만, 매뉴얼을 꼼꼼히 읽으면서 모르는 개념들을 계속 파헤쳐 나가는 것도 도움이 많이 되는 것 같습니다. 그렇게 개념들을 하나 하나씩 이해해나가면 결국에는 컴퓨터 공학적인 지식에 도달하게 되더라고요. 바텀업 방식과 탑다운 방식의 어느정도 절충안이 될 수도 있지 않을까 생각해봅니다. 좋은 영상과 인사이트 감사드려요~

한국 개발 유투브에서 주를 이루는 의견들을 보면서 알게모르게 느꼈던 반감을 쑤난님 영상을 보고 해소하고 있습니다. 항상 솔직한 영상 감사드립니다❤

이보세요. 말같지 않은 소리 하는 이유가 뭔가요? 용돈 떨어져 영상으로 점심값 벌어야 되요? 세상 물정 모르는 햇볏아리들이 하는 소리가 개발자는 끝났다는겁니다. 개발자가 과잉이고, AI가 등장하고..., 말도 안도는 소리 할꺼 뻔하니 영상은 볼 필요도 없지요. 개발자로 사는게 힘드니 하지 말라고요? 그럼 뭐 할껀데? 조리사? 자동차 정비? 항공정비? 공무원? 의사? 변호사? 이중 자리 넘쳐나서 지나가는 강아지라도 잡아다 일 시킬 만큼 인력 모자란 업종 하나만 말해보쇼. 부모님이 용돈 주니 세상 살이 만만해 보이죠? 개발 하느니 차라리 한 2년 정도 다른거 공부하면 어느 어디서 누군가가 짠 하고 나타나 제발 와달라고 돈 싸짊어지고 쫒아다닐 줄 알죠? 이렇게 세상물정 모르는 사람들이라니....

좋은 영상 감사합니다 앞으로 나아가야 할 방안을 제시해 주셔서 생각이 많이 바뀌네요

멋지네요 전문적인 내용들 군더더기 없이 간단명료하게 정리한 느낌입니다 비전공자인 제겐 지식 채널 보는 느낌이라 재밌게 봤네요

좋은내용이네요..!.

좋은 주제 토론 같아요 저두 머신러닝 딥러닝 배웠고 모델도 만들어서 돌릴수 있지만 이게 왜? 이렇게 되는지 명확하게 설명못하고 자신없고 그래서 프론트엔드쪽 공부하고있어요. ai가 기본적이고 대부분을 해결해주다보니 뭔가 여기서 나만의 hook 이 있어야 할거 같다는 생각이 매번 들긴하네요

‘기술 자체가 목적인가’라는 기준점 자체는 여전히 모호한 정의라고 생각합니다만 말로 이렇게 풀어내주시니 저도 한 번 더 생각해보게 되는 것 같아요. 좋은 영상이네요 😊

요약하면 다른 분야 공부하고 그거에 합치라는 거 같은데. 진입장벽이 너무 큰데. udemy 에서 공부한 학위도 없는 게 받아들여지는 지도 모르겠고

도메인 전문가가 되고 동료들이랑 커뮤니케이션 잘해서 일을 풀어 나가고 어떻게 일하는 지를 알아야 함 단지 수단을 공부하느라 정작 해야 할 것을 못하면 안됨 ㅋㅋ 경력은 많은 척하는데 기술적인 것에 집착해서 일 못하고 커뮤니케이션 안되는 개발자들도 있음 그런 사람은 회사에서 오래 못감