데이블

📈 빠르게 학습하는 개발자가 되는 방법

해당 글은 요즘IT와 번역가 Chase가 함께 조쉬 코모(Josh Comeau)의 글 <How To Learn Stuff Quickly>를 번역한 글입니다. 요약하면 다음과 같습니다. ✅ 가이드 따르기와 가이드 없는 학습 혼합하기 * 가이드를 따르는 학습: 튜토리얼 읽기, 강좌 수강, 유튜브 시청 등 * 가이드 없는 주도적 학습: 나만의 프로젝트 만들기, 튜토리얼에서 확장하기 등 ✅ 일부러 실수하기 * 코드를 그대로 복붙하는 대신 한 줄을 생략하면 어떻게 될지, 일부 값을 변경하면 어떤 결과가 나올지 본다. * 과학자처럼 행동한다. 코드가 어떻게 작동해야 하는지 가설을 세우고, 코드를 변경해 예상한 결과가 나오는지 확인해 본다. ✅ 튜토리얼에서 확장하기 * 완전한 기능을 갖춘 앱에서 확장을 한다. 예를 들어 리액트 공식 튜토리얼의 틱택토 게임을 완성한 후 다음과 같은 것들을 고려하여 확장한다. * 각 플레이어가 이긴 게임 수 카운트하기 * 더 보기 좋은 컴포넌트 UI 개선하기 * 사용자가 보드 크기를 설정할 수 있게 하기(4x4, 5x5) * … ✅ 관련 프로젝트 구축 * 위 틱택토 게임을 성공적으로 마쳤다면, 비슷한 프로젝트를 처음부터 만들어 본다. (ex. 빙고 게임 등) * 이런 전략은 ‘원 온, 원 오프(one on, one off)’라 불린다. 가이드를 따라가면서 배우고, 그 후에 가이드 없이 유사한 프로젝트를 만드는 것을 말한다. ✅ 올바른 사고방식 갖기 * 동일한 현상을 어떻게 해석하느냐에 따라 사고방식은 달라진다. (나는 볼링 실력이 형편 없으니 나와 맞지 않는다 vs 나는 볼링 실력이 좋지 않으나 마음만 먹으면 훌륭한 선수가 될 수 있을지도 모른다) * 우리는 사실 쉽게 성공하는 것보다 고군분투하고 실패하는 과정에서 훨씬 더 많은 것을 배운다. ✅ 목표와 동기부여 * 정말 원하는 구체적인 목표가 있으면 좌절을 극복하고 계속 발전할 수 있다. 단순 재미나 이력서에 넣기 위함이라면 금방 포기했을지도 모른다. * 본인이 진정으로 흥미를 느끼는 목표가 무엇인지 염두에 두는 것이 중요하다. 그렇지 않으면 처음 시작할 때의 설렘이 사라진 후, 필요한 동기를 유지하기 어렵다. ✅ 기억력 훈련 * 간격 반복 시스템 활용하기 * 간격 반복 학습의 핵심 아이디어는 기억이 사라지려고 할 때 바로 그 기억에 접근하는 것이다. 그리고 기억을 강화할 때마다 그 기억은 조금씩 더 오래 지속된다. * 간격 반복 학습법은 닉키 케이스(Nicky Case)의 ‘무엇이든 영원히 기억하는 방법(How To Remember Anything Forever-ish)’ 참고하기. ✅ 매일 습관 만들기 * 나는 적은 시간을 자주 투자했을 때 훨씬 더 많은 성공을 거두었다. 여유가 있다면 매일 일정 시간을 투자하는 쪽을 강력히 추천한다. (매주 1시간 투자 > 일요일에 7시간 투자) ✅ 공개적으로 학습하기 * 새로운 것을 발견하면 블로그, 트윗, 유튜브 동영상과 같은 작업을 통해 문서화해야 한다. * 학습 시간에 블로그를 작성하는 것은 시간 낭비 아닌가요? * 누군가에게 무언가를 설명하려다가 생각만큼 본인이 충분히 이해하지 못했다는 사실을 깨달은 적이 있나? 블로그 작성은 자신의 이해도를 파악할 수 있는 가장 좋은 방법이다. * 세상에서 가장 끔찍한 기분은 이전에 해결했던 버그를 발견 했는데 어떻게 해결했는지 기억이 나지 않을 때다. 포스팅을 했다면 참고할 수 있다. * 개발 커뮤니티에 적극 참여하게 되고, 인맥을 쌓을 수 있다. * 주의할 점은 완벽한 블로그를 만드느라 몇 주를 소비하지 않는 것이다. ✅ 기술 네트워크 * 기술은 재산과 같다. 더 많은 기술을 습득할수록 빠르게 축적된다. 한 분야에서 얻은 아이디어와 기술은 다른 영역에서도 충분히 도움이 된다. https://yozm.wishket.com/magazine/detail/2334/

💥 프론트엔드 개발자의 종말

요악하면 이렇습니다. 1️⃣ GPT-4 등의 AI 툴 발전이 개발자(특히 웹 개발자)의 취업 기회를 사라지게 하지 않을까 하는 우려에 전적으로 반대한다. 👉 이 위기는 처음 있는 일이 아니다. ‘노코드’ 웹사이트가 등장했을 때도, 워드프레스가 등장했을 때도, 웹플로우가 공개되었을 때도 마찬가지였다. 2️⃣ LLM(Large Language Model)은 스스로의 가정을 검증하거나 가설을 테스트할 수 없다. 그들은 자신이 말하는 것이 사실인지 아닌지 검증할 수도 없다. 👉 예를 들어, GPT-4로 리액트를 사용하여 <모달>을 생성했는데 결과물은 놀라울 정도로 좋았다. 하지만 몇 가지 접근성 문제를 일으켰다. 개발자가 코딩할 때는 이런 문제를 알아차리지 못할 수도 있지만, 최종 사용자는 분명 불편함을 느낄 것이다. 3️⃣ 대체가 아닌 보완일 것이다. 가장 현실적인 시나리오는 GPT-4와 같은 도구가 개발자 도구에 통합되어 숙련된 개발자의 업무 효율을 증가시키는 것이다. 👉 목수가 전동 공구로 대체되지 않았고, 회계사가 스프레드시트로 대체되지 않았으며, 사진가가 디지털카메라/스마트폰으로 대체되지 않았듯이, 개발자도 LLM으로 대체되지 않을 것이다. 4️⃣ 개발자 개개인의 업무 효율이 높아지면 개발자 일자리가 줄어든다고 생각하는가? 그렇지 않다. 현재 소프트웨어 개발자에 대한 수요는 공급보다 훨씬 더 많다. 5️⃣ 만약 내가 틀렸고 LLM이 소프트웨어 개발자를 완전히 대체할 수 있다면 어떻게 될까? 그렇다면 LLM은 개발뿐만 아니라 상당수의 지식 근로자를 대체해 버릴 것이다. 👉 개발자가 커리어를 전환한다고 해서 피할 수 있는 쓰나미가 아니다. 👉 그러니 미래에 어떤 일이 일어날지 도박을 하는 대신 자신이 열정을 가지고 있는 분야, 관심 있는 분야, 잘하는 분야에 집중하는 건 어떨까. 6️⃣ 온라인에서 일부 사람들은 프론트엔드가 특히 위협 받을 것이기에 백엔드 또는 데이터 엔지니어링으로 전환해야한다고 말한다. 👉 정반대라고 생각한다. 어떤 개발자도 이것에 대해 걱정할 필요는 없지만, 만약 취약한 분야가 있다면 백엔드일 것이다. 👉 OpenAI의 GPT-4 라이브스트림에서는 코드 관련 데모 두 가지를 선보였다. 1. “농담 웹사이트(Joke Website)”의 프론트엔드 2. 파이썬 기반 디스코드 봇 👉 위 데모 중 파이썬 코드가 훨씬 더 프로덕션에 적합해 보였다. 👉 지난 10여 년 동안 많은 복잡한 엔지니어링 기법들이 서버에서 클라이언트로 이동해왔다. 👉 명심해야할 것은 기업들은 자사 브랜드에 맞게 독특하고 세심하게 제작된 맞춤형 제품을 원한다. 프론트엔드는 제품이 직접 사용자와 상호작용하는 부분이기에 더 신경을 쓴다. 👉 업계에서는 우울할 정도로 많은 사람들이 백엔드 개발이 프론트엔드 개발보다 더 어렵거나 복잡하다고 생각하지만 말도 안 되는 이야기다. (참고로 글쓴이는 백엔드로 커리어를 시작했으며 풀스택 개발자다) 7️⃣ 학습에 도움 되는 방식으로 LLM 활용하기 👉 툴을 네비게이션처럼 사용하지 않기. 운전할 때 정신적인 노력은 줄어들었으나 그 대가로 방향 감각은 많이 사라졌다. 👉 네비게이션처럼 취급하는 대신 증언대에 선 LLM을 판결하는 법정의 배심원이 된 것처럼 대하는 것. LLM이 하는 말을 듣되 절대적 사실로 받아들이지 않아야 한다. 👉 GPT가 생성한 코드를 무조건 복붙하지 말고 코드를 보며 이해를 하자. 모르겠으면 추가 요청을 하고, 의심스러운 부분은 공신력 있는 출처를 통해 확인한다. - 해당 글은 요즘IT와 번역가 Chase님이 함께 조쉬 코모(Josh comeau)의 글 <프론트엔드 개발의 종말(The End of Front-End Development)>를 번역한 글입니다. https://yozm.wishket.com/magazine/detail/2201/