▲

“튜토리얼 지옥”을 대체한 “바이브 코딩 지옥”의 등장

 (blog.boot.dev)
24P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • 최근 코딩 교육 환경에서 “튜토리얼 지옥” 대신 “바이브 코딩 지옥” 이 새로운 문제로 대두됨
  • 튜토리얼 지옥이 "튜토리얼 없이는 아무것도 만들지 못하는" 상태였다면, 바이브 코딩 지옥은 "AI 없이는 코딩할 수 없고, AI가 생성한 코드가 어떻게 작동하는지 이해하지 못하는" 상태를 의미
  • AI 도구의 과도한 사용이 학습 동기를 저하시키며, AI 리터러시가 낮은 사람일수록 AI를 더 많이 사용하는 역설적 상황이 발생하고 있음
  • AI 도구는 적절하게 활용하면 학습 보조에 큰 도움이 될 수 있으나, 무작정 ‘답만 얻기’식 사용은 건설적 이해 형성에 방해가 됨
  • 학습 과정에서 직접 고민하고 스스로 해결하려는 노력이 핵심, 튜토리얼·AI 보조 없이 문제 해결 경험을 쌓는 자세가 중요함

문제의 배경: 튜토리얼 지옥에서 바이브 코딩 지옥으로

  • 2019년 당시 코딩 교육의 주요 문제는 "튜토리얼 지옥" 이었음
    • 튜토리얼을 따라하는 데는 성공하지만 혼자서는 아무것도 만들지 못함
    • 실제 프로그래밍보다 프로그래밍 관련 동영상 시청에 더 많은 시간을 소비하며, 핵심 개념은 이해하지 못함
    • 결과적으로 피상적 지식만 쌓고, 내부 작동 원리는 이해하지 못해서 현실에서는 코드를 스스로 쓰지 못하는 상태
  • Boot.dev는 이를 해결하기 위해 세 가지에 집중함
    • 심층 커리큘럼: 전통 대학 외부에서도 CS 기초를 배울 필요성 강조
    • 실습 중심 방식: 모든 개념 학습과 함께 코드를 직접 작성
    • 비디오보다 리치 텍스트 강화: 비디오는 수동적 소비에 그칠 위험성 있음
  • 2019년에는 수백만 조회수를 기록하던 긴 YouTube 강의들이 현재는 5만 조회수도 달성하기 어려움
    • FreeCodeCamp, Traversy Media, Web Dev Simplified 등의 채널이 이러한 추세를 보임
  • 그러나 "learn to code"에 대한 Google Trends 데이터는 여전히 높은 관심도를 유지하고 있음
  • Boot.dev에 매일 약 1,300명의 신규 사용자가 등록하며, 최근 18개월간 튜토리얼 지옥에 대한 불만은 줄었지만 새로운 형태의 어려움이 나타남

바이브 코딩 지옥의 정의

  • 튜토리얼 지옥의 특징
    • "튜토리얼 없이는 아무것도 만들 수 없다"
    • "문서를 이해하지 못하니 동영상이 필요하다"
    • "간단한 작업에도 복잡한 프레임워크가 필요하다"
  • 바이브 코딩 지옥의 특징
    • "Cursor의 도움 없이는 아무것도 할 수 없다"
    • "멋진 타워 디펜스 게임을 만들었어요. 여기 링크에요 http://localhost:3000";
    • "이미지 lazy-load를 위해 Claude가 6,379줄을 추가한 이유를 모르겠어요"
  • 현재 자기주도 학습자들은 많은 것을 만들고 있지만, 소프트웨어 작동 방식에 대한 멘탈 모델을 발전시키지 못하는 프로젝트를 구축함
  • AI의 환각(hallucination)과 싸우고, 테스트 통과에만 집중하는 봇과 씨름하며 실제 문제 해결보다는 AI가 생성한 코드를 맹목적으로 신뢰함

AI 코딩의 미래와 현실

  • 나는 단기적으로 AI가 개발자를 완전히 대체하지는 않을 것이라는 데 긍정적 입장
    • "AI가 일자리를 빼앗을 때까지 6개월"이라는 말이 나온 지 3년이 지났지만 여전히 개발자를 고용하고 있음
  • GPT-5가 출시되었지만 GPT-4 대비 점진적 개선에 그쳤으며, AGI가 곧 도래하지 않을 것임을 보여주는 증거로 해석됨
  • 매일 AI 도구를 사용하지만 실제로 생산성이 얼마나 향상되는지 확신하지 못함
    • AI가 더 생산적이게 만드는지, 아니면 더 게으르게 만드는지 불분명
  • 2025년 연구 결과: 개발자들은 AI가 20-25% 생산성을 높인다고 가정했지만, 실제로는 19% 느려짐
    • 7조 달러 투자 대비 실망스러운 결과

AI와 학습동기 저하의 위험성

  • AI 활용 문화가 학습자의 동기 부여에 부정적일 수 있음
  • AI 열풍(버블?)에서 가장 우려되는 점은 "왜 배워야 하나? AI가 다 알잖아"라는 태도를 가진 세대가 등장한다는 것
  • AI가 실제로 모든 화이트칼라 직업을 대체하지 못한다면, 주식 시장 버블뿐 아니라 교육받은 인력의 가뭄도 겪게 될 것
  • 기술적 배경이 없는 투자자들은 “AI가 이미 코딩의 전부를 대체했다”고 오해하고, 시니어 개발자들은 여전히 AI 도구를 일상 업무에 통합할 유용한 방법을 찾지 못함
  • AI 리터러시가 낮은 사람일수록 AI를 더 많이 사용하는 경향이 있어 우려됨
    • 궁극적인 ‘Dunning-Kruger(더닝-크루거)’ 함정으로 작용 - 지식이 부족한 사람이 오히려 자신이 잘 안다고 착각하는 현상
    • 학습자들이 "AI가 이미 알고 있으니" 자기계발이 무의미하다고 결론 내림

AI는 학습에 유익한가?

  • 여전히 코딩 배우기에 대한 사회적 관심도 높음
  • AI가 학습에 유익할 수도 있지만, 두 가지 구조적 문제가 존재함

  • 첫 번째: 아첨(sycophant) 문제

    • AI 챗봇은 질문자 의견에 과도하게 동조하는 경향이 있음
    • “ROAS(광고수익률)에 대해” 채팅해보면, 같은 데이터를 놓고 질문 방향에 따라 정반대 결론을 내며, 모두 전문가적 어조로 확신 있게 답함
    • 이는 학습자에게 검증, 비판적 사고, 오류 지적을 경험할 기회를 박탈함
      • 전문가에게 묻는 이유는 우리가 틀렸을 때 알려주기 위함
      • IRC 채팅이나 Stack Overflow는 이를 잘 수행했음(아마도 너무 잘)
      • LLM(대형언어모델) 챗봇은 기존 학습자의 근본적 오해를 바로잡지 못하는 경향이 강함
      • 현재 학생들은 LLM과 편안한 대화를 나누며 필요한 것이 아닌 듣고 싶은 것을 듣게 됨

  • 두 번째 문제: 학습자는 실질적 ‘의견’을 원함

    • AI는 지나치게 균형 잡힌 입장을 제시함
      • "어떤 사람들은 X라고 생각하고 어떤 사람들은 Y라고 생각한다"
      • 학습자가 어느 쪽에 동의할지 결정하기 더 어려워짐
    • "자본주의자 역할" 또는 "마르크스주의 혁명가 역할"을 하도록 프롬프트했지만 만족스러운 결과를 얻지 못함
    • 학습자는 실제 경험에서 나온 의견과 논평을 듣고 싶어함
      • DHH가 Turbo에서 TypeScript를 제거한 이유
      • Anders Hejlsberg가 TypeScript가 JavaScript 개발자에게 해결해주는 것
      • 각 저자의 편견과 맥락이 명확히 드러나는 실제 의견을 통해 미묘한 멘탈 모델이 형성됨
    • LLM 특유의 중립적·조심스러운 답변은 실제 지식 내면화에 방해가 됨

AI가 학습에 진짜 도움 되는 경우

  • AI는 올바르게 사용하면 학습을 위한 놀라운 도구임
  • 코딩을 배우기에 이보다 쉬운 시대는 없었음
  • Boot.dev의 Boots(AI 교육 보조 도구) 사례
    • 학생들이 인스트럭터 솔루션(이상적인 정답)을 보는 것보다 AI 튜터(Boots)와 채팅하는 것을 거의 4배 더 많이 사용
    • Boots는 일반 챗봇과 달리 다음 방식으로 학습에 도움 줌
      • 답을 직접 알려주지 않도록 사전 프롬프팅됨
      • 소크라테스식 방법을 사용하여 학생이 문제에 대해 더 깊이 생각하도록 유도
      • 강사의 솔루션에 접근할 수 있어 정답에 대한 환각 가능성이 훨씬 낮음
      • 즐거운 캐릭터성 부여(마법사 곰)

바이브 코딩 지옥 탈출법

  • 결론적으로, 튜토리얼 지옥이든 바이브 지옥이든, ‘남에게 맡기지 말고 스스로 해보는 경험’ 이 매우 중요함
    • 튜토리얼 지옥: 비디오 끄고 직접 코드 작성 경험 쌓기
    • 바이브 지옥: 코파일럿 등 AI 자동완성 꺼두고, 스스로 문제 해결 경험 쌓기
  • 피해야 할 것:
    • 에디터 내 AI 자동완성
    • 에이전트 모드 및 AI 자동화 도구로 프로젝트 처리
  • 활용할 수 있는 것:
    • 질문에 답하고, 개념을 설명하고, 예제를 제공하는 챗봇
    • 소크라테스식 방법으로 질문하도록 유도하는 시스템 프롬프트를 통해 깊은 사고 촉진
    • 주장을 할 때 출처를 인용하고 문서에 링크하도록 요청하는 시스템 프롬프트로 정보 신뢰성 확보

핵심 원칙

  • 학습은 반드시 불편해야 함
    • 튜토리얼 지옥은 다른 사람이 코딩하는 것을 보면서 불편함을 피할 수 있게 해줌
    • 바이브 코딩 지옥은 AI가 코드를 작성하게 하면서 불편함을 피할 수 있게 해줌
  • 진짜 학습은 막히고, 좌절하고, 가장 중요하게는 문제 해결을 강제당할 때 일어남
    • 이것이 인간의 신경망이 재배선되는 방식
  • "학습은 어려워야 한다"는 개념을 지나치게 확대하면 형편없는 교육 설계의 변명이 될 수 있음
    • 저자는 이를 옹호하지 않음
    • 개념이 최선의 방식으로 설명되더라도, 학생은 여전히 그것과 씨름하고 새로운 맥락에서 스스로 사용해야 진정으로 이해할 수 있음
  • 진짜 학습 은 직접 막히고, 좌절하고, 자신의 힘으로 돌파하는 과정에서 완성됨
▲
aer0700 1일전  [-]

조금 다른 맥락이지만, 튜토리얼 지옥이 벌어지는 건 프레임워크 튜토리얼이 기본적인 cs 교육자료로서 쓰인것이 아니기 때문이기도 합니다.
Django 튜토리얼을 보고 poll app을 만들어본 초보자가 혼자서 블로그를 만들 수는 없는 건, django 튜토리얼은 http가 뭔지, 템플릿, ws가 뭐고, db가 뭔지, 등등 이미 다 알고 있는 사람을 대상으로 django를 설명하기 위한 글이지, web을 설명하는 글이 아니기 때문입니다. 굉장히 많은 맥락이 django 튜토리얼에는 생략되어있고, 이게 튜토리얼 지옥이 생기는 원인이 아닌가 싶습니다.
Django 튜토리얼을 오늘 처음 프로그래밍을 해본 사람을 위한 것으로 재작성해보는 것도 괜찮은 과제 같네요. Http의 구조를 먼저 설명하고, django가 각 요소를 어떻게 핸들링하고 있는지 설명하는 식으로요.

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • "Tutorial Hell"이라는 말이 너무 공감됨, 6시간짜리 강의를 보고 따라 코딩하긴 하지만 막상 처음부터 뭔가 만들어라고 하면 손이 꽉 막힘, 이게 바로 전형적인 튜토리얼 헬임, 그래서 역사적으로 장인 수업(apprenticeship)이 가장 효과적인 학습 방법이었음, 주니어가 시니어를 따라다니고, 마스터 장인이 상위에서 전체를 끌어가는 구조, 장인이 프로젝트의 관리와 지도를 병행하는 모습임, 우리 개발자 집단이 오랫동안 길드처럼 운영되지 않았던 건 아쉬움, 1980년대 말부터 이미 그러지 말았어야 했다고 생각함, 만약 길드가 있었다면 개발자 수 자체가 훨씬 적어져 업계 발전 자체가 다르게 흘러갔을 수도 있음을 짐작함

    • 신입뿐만 아니라 경력 있는 개발자도 그냥 무에서 프로젝트 시작하라 하면 어려움을 느낌, 대개 기존 코드베이스에서 작업하고, 새로운 앱 필요해도 템플릿이나 카피&페이스트로 시작함, 정말 완전히 새로운 걸 처음부터 만드는 경우는 흔하지 않음, 전기기술자가 신축 건물에 배선하듯 회사 개발자가 진짜로 무언가를 완전 처음부터 세팅할 일은 드물다는 점, 장인 수업도 근본적으로 이 구조를 크게 바꾸지 못함

    • 내 경험으로는, 좋은 대학은 점진적이고 실전적인 과제를 통해 학생을 훈련시킴, 처음엔 간단한 자료구조나 알고리즘, 퍼즐을 풀다 OS, 데이터베이스, 영속 데이터구조, 컴파일러, CPU, 시뮬레이션, 머신러닝 모델까지 만들게 됨, 함수 하나에서 점점 큰 무언가를 직접 짓게 되며, 이런 훈련에 정말 감사함, 관련 링크 참고

    • 나는 LLM을 장인-도제 관계처럼 코딩 학습에 활용함, LLM은 내가 시킬 때만 앞으로 나아가고, 설명과 지도만 하고 쓰기는 내가 직접 함, 새로운 강의나 튜토리얼 찾는 것보다 훨씬 나음, 사실 튜토리얼 헬은 스스로 교사라고 생각하는 사람들이 만들어낸 현상임, 수많은 책과 강의도 결국 실질적으로 뭔가를 가르쳐주지 못함, 지금의 코딩 교육 모델이 완전히 잘못됐다고 여김, 요즘은 LLM이 새 언어나 라이브러리의 최신 문서를 요약하거나, 내가 직접 계획을 짜는 방식을 선호함, 다만 LLM이 환각(hallucinate)하는지는 확신이 없어 약간 불만임

    • 나는 학교를 매우 일찍 그만뒀음(지루함과 고리타분한 교육방식이 원인임), 소프트웨어 엔지니어 도제로 현장에 뛰어들었고 학교 과정은 전혀 쓸모없었음, 90년대 후반엔 실수와 시행착오의 연속이었고, 나와 마스터, 그의 마스터까지 모두 직접 부딪히며 배웠음, 리눅스 가지고 ISDN 라우터 만들고, 웹사이트 서버도 꾸미고, HTML, Perl, PHP 다루며 진짜 DevOps와 엔지니어링을 경험함(당시엔 그런 단어조차 없었지만), 문서 거의 없이 창의력과 도전정신 하나로 경계를 넓혀가는 시절이었음, 지금 AI시대의 vibe coding과 느낌이 통하는 부분도 있고 압박감은 훨씬 커졌지만 정말 재밌는 추억임

    • 기술업계는 직업에 대한 게이트키핑(문턱세우기)이 부정적으로 받아들여짐, 업계 내 자만심 때문이고, 자본 힘으로 인력 수급을 키워 임금을 낮추려는 의도도 있음, 이 바람에 제대로 된 직업 표준이 사라졌고, 리트코드(leetcode) 같은 굴욕적인 면접이 직업 자체와 무관하게 게이트키퍼가 됨

  • Zed Pro와 GPT를 매일 코딩에 활용하는 사람으로서, 이런 툴의 발전이 현대 프로그래밍의 비효율을 드러낸다고 봄, 현대 웹은 놀라우면서도 끔찍함, 관료주의란 복잡한 규칙으로 얽힌다는 뜻이라면, 현대 개발이야말로 그 대표 주자임, 가장 간단한 일조차 확률 기반 자동화 툴의 안내가 필요하다면 좀 슬픈 일임, 예전엔 후배들한테 "특정 언어를 아는 게 중요한 게 아니라, 계속 새로 배우는 역량이 핵심"이라 조언함, 일부 트렌드는 오래가겠지만 결국 새 툴과 언어는 끊임없이 배워야 함, 내 나이 때문인진 몰라도, 언젠가부터 그 복잡함이 넘쳐나기 시작했다고 느낌, 예전엔 프로그래밍이 너무 전기공학적이거나 수학 같았다면, 지금은 또 다른 복잡함이 쌓여 있음

    • 나도 이런 느낌에 공감함, SF영화에서처럼 "에너지 앞으로 몰아라!" 같이 부품이나 시스템이 언제든 손쉽게 호환, 재사용되는 컴퓨팅 환경을 원했던 적 있음, 하지만 실제로는 안드로이드 폰의 카메라를 아이폰에 갈아끼우는 것도 거의 불가능한 과제임

    • 무슨 말을 하려는 것인지 정확히는 파악이 어렵지만, 관료주의란 용법은 이상해 보임, 실제론 검색력이야말로 핵심 능력이므로, 무엇이든 찾아내는 사람이면 뭐든 할 수 있음, 자동화 툴도 결국 책이나 교사와 본질적으로 다르지 않음, 일부 사람이 이런 역량이 부족한 건 인간 본연의 불변성이니, 툴이 좋아진 걸 탓할 바는 아님

    • 문서란 걸 잘 쓰고, 검색하고, 읽기가 진짜 어렵다는 점이 큰 문제임, 그래서 학습이 힘들지만 AI 덕분에 배우는 게 더 쉬워졌음, 예를 들어 언리얼 엔진 같은 것도 AI가 놀라울 정도로 잘 이해함

    • 우리가 떠안은 여러 문제는 모두 Brooks의 '은총알은 없다'에서 말하는 우발적 복잡성임, LLM은 이런 복잡성을 뚫고 언어나 프레임워크마다 쌓인 지식 사일로까지 무너뜨리는 역할을 함

    • 지금처럼 투기적인 업계가 조금만 더 지속되면, 아예 프로그래밍 자체가 사라지는 세상이 올 수도 있음

  • 요즘은 모두가 코드를 쓸 수 있으니 조직 차원에서 코드량이 10배쯤 늘어남, 하지만 리뷰어 수는 그대로라 감당이 안 됨, LLM 코드 sanity check도 못 쓴다면 도대체 어떻게 해야겠냐는 생각임, 실제로 어제 비전문가가 Codex로 최적화 알고리즘을 만들었고, 그걸 내가 개선해 달라는 요청을 받음, 문제는 그 코드가 완전 엉망이었다는 것임(수천 개 정수 조합에서 단순 탐색을 하고, 제약도 잘 못 지켜서 결과적으로 신뢰할 수 없는 결과들), 결국 하루종일 코드를 검토하고, 이게 본질상 쓸모없는 거라는 내용을 임원 앞에서 프레젠테이션까지 해야 했음

    • "LLM 코드 sanity check"에 대한 해답은 단위테스트임, LLM이 테스트 코드와 testable한 코드도 아주 잘 생성함(요청했을 때), 테스트가 실제로 코드를 호출하고, 엣지케이스까지 잘 검사하면 코드 리뷰보다 훨씬 빠름, 퍼포먼스 테스트 등도 포함 가능함, 앞으로는 선언(definitions)과 테스트 중심으로 일하고, 함수 내부 구현방식은 점점 덜 중요해지는 흐름이 올 것이고, 이건 큰 관점 전환임

    • 엑셀 프로그래밍 사태를 참고하면 됨, 처음엔 모두 무시하다가 폭발하면 뒤늦게 수천만 원씩 써가며 회사 망하기 전에 수습하려 드는 식임

    • '리뷰어 수가 같다'는 부분에 대해, LLM도 코드 리뷰에 도움을 줄 수 있음, GPT-5만 해도 오프바이원 같은 지역적 오류나 누락된 반환값 탐지 등에 강함, 다만 더 고차원의 전체 구조이해가 필요한 문제엔 아직 한계가 있음, 미래엔 아마 대규모 코드베이스를 정기적으로 LLM에 파인튜닝 시켜서, 모든 변경사항에 대해 1차 리뷰어로 쓰는 식의 도입도 가능할 것으로 봄

    • OR(조합최적화) 문제는 즉흥식으로 코딩하는 사람들이 자신이 본질적으로 특별한 알고리즘 영역에 빠졌다는 걸 잘 모르는 데서 비롯함, 심지어 지적해줘도 수학적 이론을 이해하지 못해서 그냥 자신의 방식대로 해보려는 경향이 큼

    • 이런 상황에서 회사 리더들에게 기술적 프레젠테이션을 해서 현 상황을 정확히 인식시켜 주는 게 사실상 유일한 대응법일 수 있음

  • AI가 주니어 개발자를 망친다, 그래서 시니어 대체 인력 위기 온다는 얘기가 또 나올 거라 생각했는데, 이번 글은 간접적으로는 그런 내용도 있고 전반적으로 동의함, 하지만 아첨(sycophancy)에 대한 부분이 특별히 인상적이었음, 예전엔 ChatGPT 같은 인터페이스가 학습에 도움이 된다고 여겼는데, 유튜브 ROAS 예시가 강렬하게 다가옴, 질문을 어떻게 하느냐에 따라 교사의 결론을 얼마든지 학생이 왜곡시키는 구조라면 수 없는 초보 개발자가 그릇된 방향으로 인도 받을 수밖에 없음, 심지어 AI "Boot"에 적용한 다양한 프롬프트링이 충분한지조차 모르겠음, 결국 AI 시대에도 "누군가"가 반복적으로 내 PR을 거절해줘야 성장할 수 있음, 그 "누군가"는 아직 AI가 될 수 없음

    • 내 경험상 혹평(Scathing critique)을 요청해도 AI는 나를 기분 좋게 만들려는 태도가 섞임, GPT 옛 버전이든 최신이든 비슷함, 뭔가 애매한 느낌을 받음, 결국 도구는 자신이 도움받고 싶고, LLM의 특수한 문제점을 자각하는 사람만이 가장 잘 활용하는 수단에 그침

    • 아첨 현상을 방지하려고 항상 반대 편향을 넣어 두 번 질문함, 하지만 내가 가진 숨은 편향까지 AI가 강화하는지는 알 수 없음

  • 초보는 아니지만, 새로운 프레임워크나 언어, 알고리즘을 계속 배우기 때문에 AI 오토컴플리트가 나쁘다고 생각하지 않음, 예전의 IntelliSense나 ReSharper 오토컴플리트도 새로운 라이브러리나 언어 기능 배울 때 큰 도움이 됐음, ReSharper가 예전 방식으로 코딩하면 새 기능을 추천해주는데, 그걸로 새로 배운 적도 많음, AI 기반 오토컴플리트는 훨씬 더 발전된 느낌임, 무언가를 자연스럽게 제안해주고, 실제로 써도 되고 안 써도 되니까 학습에도 도움됨, 결국 호기심 있게 제안을 읽고 이해하려는 태도만 있다면 AI 덕분에 배움이 더 쉬워짐, 예전엔 그저 스택오버플로에서 복붙하는 거였음

    • 전통적 오토컴플리트는 해당 스코프의 모든 메소드, 변수, 상수 등을 다 보여주고, 문서도 연결해 줌, 내가 어떤 옵션이 있는지 스스로 판단할 수 있으니 정말 학습에 좋았음, AI 오토컴플리트는 사실상 스택오버플로 정답을 맥락 설명 없이 붙여주는 것과 비슷함, 배우는 입장이라면 직접 스택오버플로 검색하거나, 필요하면 챗봇에 프롬프트해서 왜 그 코드가 그렇게 되는지 설명까지 들으면 더 좋긴 함

    • 내 생각엔 약간 차이가 있음, 어느 정도 경력이 있으면 새 언어로 오토컴플리트 써도 자연스러움, 하지만 기본기 없는 초보가 처음 for문부터 배우는 건 다름

    • AI Agentic 프로그래밍을 좋아함, 만드는 게 행복이고, 아이디어 실험의 일부임, 코드를 프로덕션에 배포하는 게 아니라서 남 시선 신경 안 씀, 기술적으로 뛰어난 동료들과 이야기하려면 꼭 스스로 시도해보고 학습하는 게 필요함, 10살 때부터 프로그래밍을 좋아했지만 직업 개발자는 아니었음, AI 시대가 오니 코딩과 실험에 대한 사랑이 다시 살아남, WASM 등 미래 웹 기술이나 다양한 시스템, 버그 찾기, 나만의 방식대로 해보는 게 큰 즐거움임, Cursor AI 같은 도구가 내 git 세팅까지 자동화해줘서 ssh로 푸시까지 간편함, 물론 직접 할 수 있지만 AI가 하도록 맡김, 어릴 때 C 문법부터 시작해 굳어진 습관도 있지만, python 백엔드, flask 웹서버, 자바스크립트 프론트엔드 다루는 즐거움이 큼, WASM Python은 아직 많이 부족하지만 계속 실험 중임, 기본기를 다지고 내 방식대로 배우는 게 내 취향임, 엔지니어들은 필요이상으로 복잡하게 만드는 경향이 있다는 것도 자주 느낌

    • AI 오토컴플리트는 최고의 도구임, 문서 없이도 원하는 코드 제안을 받고, 몇 줄이라서 검토도 쉬움, 큰 덩어리를 자동으로 만들어주진 않아 배우는 데 해가 되지도 않음

  • 초보가 아니지만, Copilot 덕분에 Rust 배우는 게 확실히 쉬워졌음, Intellisense랑 조합해 쓰면 문법 부담이 줄어들어 언어의 중요한 부분 학습에 집중할 수 있음, Rust 관련 책을 펴는 데서 일주일 만에 돌아가는 툴까지 만들 수 있었음, 물론 이걸로 시니어 엔지니어가 된 건 아니지만, '0에서 1'의 허들을 확실히 줄여줌, 나는 Copilot에 코드 작성 지시를 하지 않고, 개선된 오토컴플리트처럼 제안만 받아보고 직접 수락 여부를 결정함

    • 여기서 반복되는 주제는, 경력 많은 시니어는 새 언어를 몰라도 '코딩하는 법'을 알기 때문에 이런 도구에서 가치를 뽑아낼 수 있다는 점임, 언어가 바뀌어도 코드 냄새는 똑같음, 초보는 '코드 냄새'의 개념조차 잘 모름

    • 나도 과거엔 Copilot이 Rust 학습에 큰 도움 주는 줄 알았는데, AI 없이 직접 코딩해보니 정말 어려웠음, AI를 끄고 학습해야만 진짜로 알고 있다는 착각에서 벗어날 수 있었음

  • 다양한 교육 지름길에도 똑같은 문제가 있음, 학생들이 과외에서 숙제를 대신 풀어준다든가, 설명만 듣고 시험은 자신 있을 거라 착각함, 사실 설명 들을 땐 간단해 보여도, 정말로 스스로 해내는 게 전혀 다른 능력임

  • AI가 정말로 몇 년 안에 모든 화이트칼라 직업을 대체하지 않는다면, 주식시장 버블만이 아니라 교육받은 인력 기근까지 맞게 될 것 같음, 내겐 '내 세대 최고의 인재들이 이렇게 흩어지는 걸 지켜본다'라는 느낌과 같은 충격이 있음

  • 기사 제목 대체로 쓸 만한 대표 문구를 찾으려 했으나 적당한 걸 못 찾아 최선을 다함, 더 정확하면서 중립적인 제목 제안 있으면 바꿔도 됨, 관련 안내

  • "이해는 했지만, 처음부터 써 보라면 완전히 막힘" 이란 부분에 크게 공감함, 처음 튜토리얼을 쫓아가기만 하다 비슷한 걸 만들어보려다 막히는 게 가장 괴로웠고 어려웠던 점임, 하지만 이런 고통스러운 과정이 학습 효율 최고밀도의 경험이었음, 이후 더 복잡하고 다양한 걸 배웠지만, 그 밀도의 학습을 다시 경험한 적이 없음, 고등학교 수학 때 느꼈던 뭔가 머리가 아프고 스트레스 받는 감정과 비슷함, 누구에게나 흔한 경험은 아닐 거라는 생각임

답변달기