10P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • AI는 학습 곡선에서 입문자와 중급자의 진입 장벽을 낮추는 역할을 하며, 개개인의 수준에 맞는 맞춤형 지원이 가능함
  • 전문가 수준의 마스터리에 도달하는 것은 여전히 어렵고, AI는 깊이 있는 주제나 논쟁적인 분야에서 한계가 존재함
  • AI를 단순 답변 도구로만 사용하면 실질적 성장 없이 AI의 한계에서 멈추는 부작용이 발생할 수 있음
  • 코딩, 창작, 일상 앱 사용 등 다양한 영역에서 AI의 영향이 다르게 나타나며, 특히 새로운 아이디어와 혁신성이 중요한 분야에서는 AI의 파급력이 제한적임
  • AI가 변화의 바닥선을 올렸지만, 모든 분야에서 큰 변화를 만든 것은 아니며, 각자의 필요와 맥락에 따라 활용 가치가 다르게 평가됨

요약: AI가 바꾼 학습 곡선

  • AI 등장 전에는 각 학습 자료가 특정 대상을 기준으로 제작되어, 학습자의 배경지식을 제대로 반영하지 못하는 한계점이 존재함
  • 예를 들어, 익숙한 분야에서 새로운 주제로 연결해 배우거나, 필요한 선수 지식의 존재조차 모르는 상황, 중급 단계에서 적합한 자료를 찾지 못하는 문제가 흔함
  • 기존에는 기술 습득 과정에서 맞춤형 지원이 어려웠음
  • AI는 개별 학습자의 이해 수준에 맞춰 질문에 직접 답하거나 반복 작업을 대신 수행, 학습 곡선을 변화시킴
  • AI 기반 학습 경험으로, 이제는 어떤 수준에서든 AI가 출발점이 되어주는 바닥(최소 수준) 자체가 올라가는 변화가 발생함

마스터 수준의 한계

  • 분야별 전문가들은 AI의 유효성에 대해 비판적 시각을 가짐
  • AI가 제공하는 정보는 대중적이고 기본적인 내용에서는 강점을 보이지만, 심화·전문 지식이나 논쟁적 주제에 대해서는 한계가 큼
  • AI의 학습 데이터는 일반화된 내용이 많을수록 더 강력한 결과를 내지만, 고난도·진보적 지식에는 훈련 데이터 부족이나 상충된 정보가 많아 정확하고 깊이 있는 답변 제공이 어려움

AI 학습의 부작용: 치팅

  • OpenAI Study Mode 등 정답만 바로 요구하는 기능은, 사용자의 학습정체(plateau)를 심화시킬 수 있음
  • AI 답변을 단순 수단으로 삼는 사용자는, 그 이상 성장하지 못하는 한계를 가짐
  • 장기적으로는 이 방식이 장기적 성장에 불리

변화된 학습 곡선의 실제 영향

  • 기술 변화는 생태계 전체의 변화를 불러옴
  • AI의 영향력은 제품이나 결과물에 얼마나 높은 마스터리(숙련도)가 필요한지에 따라 달라짐
  • 소프트웨어 개발: 관리자에게는 호재, 대규모 코드베이스에는 제한적

    • 엔지니어링 관리자는 원리와 품질판단력은 있으나, 특정 프레임워크 경험 부족으로 애플리케이션 제작에 어려움이 있었음
    • AI 도구로 인해 기초부터 빠르게 습득하고, 기존 경험을 살려 작동하는 앱을 빠르게 완성하는 사례가 증가함
    • 반면, 대규모·복잡한 코드베이스에서는 AI의 도움 한계가 분명함
      • 기존 시스템의 맥락이나 고유 요구사항에 대한 이해가 부족해, 실제 작업에는 큰 도움이 되지 않음
  • 창작 분야: 경쟁이 치열하여 영향 제한적

    • 창의적 분야에서는 경쟁이 극심하고, 새로운 독창성이 중요
    • AI로 이미지를 쉽게 만들 수 있어도, 진정한 창작 성공의 핵심인 '새로움'이라는 진입장벽은 낮춰지지 않음
    • 인간은 쉽게 파생·모방을 간파하기 때문에, 단시간 유행 이후 금방 관심이 사그라드는 현상이 발생
    • Studio Ghibli 스타일의 아바타 유행처럼 단발적 사례는 있으나 문화적 입지나 대중성에서는 AI가 미치는 영향이 미미함
  • 기존 앱 영역: 영향 최소

    • 이메일, 음식 주문 등은 이미 특화 앱이 잘 구축되어 있음
    • AI 기반 요약 기능이 있어도, 스팸 정리는 이미 자동화되어 있고, 중요한 메일은 직접 확인이 더 신뢰도 높음
    • 음식 주문 등도 이미 세심하게 설계된 UX가 존재해, AI가 더 효과적으로 바꾸기는 어려움

AI 도입의 편차와 미래

  • AI는 지식 노동의 바닥을 올렸지만, 모든 사람에게 같은 영향을 미치지 않음
  • 각자의 기술 수준과 역할, 환경에 따라 AI의 체감 효과에 큰 편차가 존재함
  • 일부는 AI를 통해 혁신을 경험하지만, 다른 이들은 효과를 체감하지 못하거나 오히려 위기감과 혼란을 느낌
  • AI는 아직 모든 방식과 분야에서 '대체 불가능'하지만, 실험할만한 잠재력을 가진 강력한 기술
  • 만약 개별적으로 AI가 의미 없어 보인다면, 당신의 상황에서는 실질적 변화가 크지 않은 것
Hacker News 의견
  • 블로그 글에는 여러 차트가 있어서 객관성과 엄격함이 있는 것처럼 보이지만, 실제로는 느낌과 추측뿐임을 강조함. 최근 실증 연구들은 오히려 AI가 불평등을 악화시키는 방향을 보여줌. 이코노미스트의 그래프기사에서 관련 내용을 확인할 수 있음

    • 당연히 AI가 불평등을 심화시킨다는 생각임. AI는 사람들이 경험을 쌓아 올라가는 사다리의 하위 단계를 자동화해서, 미래의 전문가가 될 사람들에게 발판을 제공하지 않고, 이미 정상에 있는 사람들이 투자하여 그 사다리를 더 빠르게 올리는 기술이라고 봄

    • 그래프는 너무 큰 가정을 하고 있는데, 이는 AI 극성주의자의 머릿속에서만 뒷받침되는 느낌임. 특히 '사이드 프로젝트' 관련해서는 애매하게 다루고 있는데, AI가 초보의 입력을 받아서 '충분히 괜찮은' 결과를 만들어 내기에 부족하다고 생각함

    • 글의 요지에 어느 정도 공감함. 과학자처럼 실험실 가운을 입은 듯 위장하지만, 사실 자신들이 어떻게 세상을 보는지에 대한 관계성만 표현했을 뿐임. 그래도 그래프에 '가설'임을 명시하거나, 축 끝을 물결선으로 표현하는 등 시각적 방법으로 가설임을 강조하면 커뮤니케이션 수단으로 가치는 있다고 봄. 곡선의 평탄화(숙련도 정체)가 생긴다고 전제하는 것 역시 확신할 수는 없음. 저자는 오히려 경제학자들의 링크보다 더 선의의 글쓰기를 했다고 생각함. 나는 사람들이 솔직한 의견을 드러내고, 데이터가 있으면 가설 검증까지 보여주면 이상적이라고 봄

    • 그래프에는 불평등 증가를 보여주는 연구가 4개, 불평등 감소를 보여주는 연구가 6개 언급됨

    • 은퇴한 수학자 입장에서, 2025년에 AI에 푹 빠지게 됐고 Claude Max 요금제를 써서 제한 없이 Claude Code Opus 4를 사용하고 있음. 병렬 세션으로 방대한 레거시 코드 베이스를 리뷰하면 사용 한도에 닿기도 함. 한동안 AI에 관한 그 어떤 소통도 기피했으나, 최근에는 HN에서 흥미로운 논의들이 보여 다시 관심 가짐. 내 의견으론 신경다양성(neurodivergent)이 있는 사람들이 AI 사용에 더 성공적인데, 이는 AI가 거대한 연상 엔진이기 때문임. 나는 선형대수 전공이니, AI의 연상 구조와 내 독특한 사고방식이 잘 맞음. 결국 AI는 바닥이 아닌 천장을 올리는 효과를 가져옴

  • Andrew Ng의 최근 AI 스타트업 발표와 비슷한 통찰임. 요즘 창업가들에게 주는 새 조언은, 피벗할 때 프로토타입을 버리고 처음부터 새로 하라는 것임. 이는 본문의 내용과도 연관됨. 프로토타입 개발은 최대 10배 향상되지만, 기존 코드베이스는 30~50% 정도만 개선된다고 함. 이 변화는 과거 VM에서 컨테이너로 옮겨갈 때의 '펫 vs 가축' 비유와 유사함. 코드베이스를 정성스럽게 아끼는 '펫'이 아니라 효율적으로 대하는 '가축'처럼 다뤄야 하는 시대일 수도 있음. 관련 발표 동영상에서 10:30 부분 참고할 수 있음

    • 나의 생각에는 '펫 vs 가축' 비유가 코드에만 집중해서, 진짜 가치는 개발자의 머릿속에 있다는 점을 놓치기 쉬움. AI는 코드 관리는 도와줄 수 있지만, 진정한 가치는 개발자의 이해와 정신적 모델에 있음

    • 좋은 포인트지만, '가축'보다는 '가축(cattle)'이라는 표현을 더 자주 들어봤음. 지리적 차이인지 궁금해짐

    • 이 비유 언급 감사함. 앞으로 생성형 코드를 대규모 클라우드 인프라처럼 다룰 필요가 있을 것 같음. 오랜 세월 써온 레거시 코드에는 덜 적용될 수 있음. 혹시 통찰을 블로그로 정리한 적 있는지 궁금하고, stillpointlab.com 나 @stillpointlab 트위터가 궁금해서 찾아봤으나 자료가 별로 없음

    • "펫 vs 가축" 비유가 "장인 vs 대충 만드는 사람" 논쟁보다 훨씬 잘 맞는다고 느낌. LLM을 써도 결과물의 가치가 깎이는 게 아니라, 코드에 대한 정서적 애착 대신 실용적으로 바라보는 시각의 전환임

  • LLM으로는 아직 할 수 없는 일이 꽤 있음. 예를 들어 체스를 같이 두다보면 5~10수 정도 지나면 불법 수를 두기 시작하고, 최고의 경우에도 18수 정도가 한계였음. 상대방의 잘못된 움직임도 바로잡지 않으므로 잘못된 학습이 될 수 있음. 결국 실제로 복잡한 문제를 모델링하지 못하니, 사용자가 무엇을 질문해야 할지 인식하는 것이 매우 중요함. LLM은 나이트의 이동 방법이나 유명한 오프닝 정도는 알려줄 수 있지만, 체스 기보 전체를 올바르게 따라가거나, 현 보드 상황에서 최선의 수를 알려주는 것은 불가능함. 많은 사용자가 얼마나 잘못된 답변이 나올 수 있는지 모르는 채로, 자신있게 뱉는 답변을 그대로 믿을 가능성이 큼. 얼핏 보면 단단해 보이지만, 사실은 보이지 않는 크레바스 위를 걷는 것과 같음

    • LLM이 체스에 약한 것은 큰 문제라고 생각하지 않음. 체스 전용 모델은 꽤 괜찮은 수준의 ELO로 합법적인 수만 두게끔 할 수 있음. 포스트 트레이닝이 체스 능력을 저해할 수 있고, OpenAI 같은 곳에서도 크게 신경 쓰지 않는 듯함. LLM으로도 체스 잘 둘 수 있음. 관련 논문평가 예시 참고함

    • 나도 주변에 박사나 의사 같은 전문가들이 LLM이 실수할 거라는 건 아예 상상도 못하는 경우를 자주 봄. 환상적이고 논리적인 문장에 자신감까지 더해지니, 완전 전문가라 착각하는 ‘후광 효과’도 있을 것 같음

    • LLM으로 코드 에이전트 모드에서 작업해보면, 처음엔 잘하다가 점점 엉뚱한 방향으로 흐르기도 하고, 전혀 상관없는 코드 들여쓰기를 시도하는 등 의외의 행동을 많이 목격했음

    • 체스의 경우, 전문 AI는 인간보다 훨씬 뛰어나는데, 반면 범용 LLM은 합법적인 수를 두기도 어렵다는 점이 흥미로움. AI의 천장은 LLM보다 훨씬 높은 위치에 있음

    • "10수 이상 따라가기 어려움"에 대해, 체스에서는 과거 수보다 현재 보드 상태가 더 중요함. LLM은 불필요한 정보를 거르는 데 약하니, 오히려 보드 상태만 입력하면 성능이 좋아짐. 더 자세한 토론 참고

  • 에이전트가 그린필드 프로젝트에만 좋다면, 기존 코드베이스도 새 기능마다 새로운 그린필드 프로젝트처럼 준비해서, 인턴이 플러그만 꽂으면 동작하도록 해야 함. 나머지 부분은 사람의 손이 필요하고, 그렇지 않으면 인턴이 벽 전체를 다 뜯어버릴 수 있음

    • 말도 안 된다고 생각함. npm의 Y 프로젝트를 WebStorm으로 GitHub에서 받아서 Junie에게 물어보면, 바로 답을 받을 수도 있고, 이해 안 되는 데이터 구조도 예시와 함께 문서화해줌. PR까지 바로 만들 수는 없어도, 페어 프로그래머로 충분히 활용할 수 있음. 오히려 더 많은 테스트를 쓰고 오류 처리도 더 신경 쓰게 되어 최종적으로 더 나은 결과를 만듦

    • 에이전트는 잘하는 것도 많고 못하는 것도 많음. 쓸수록 뭐가 더 잘되는지 헷갈릴 지경임

    • 에이전트가 완전히 새로운 프로젝트 시작은 오히려 별로고, 소~중간 규모 프로젝트에는 매우 좋으며, 크기가 커질수록 점차 효율이 떨어지는 경향이 있다고 생각함. 완전히 새 프로젝트의 경우엔 실제로 써먹을 수 없는 '예제 수준' 코드가 많이 나옴.

  • AI는 보간(interpolation)을 잘하는 도구이고, 외삽(extrapolation)은 못한다는 한줄 요약임

    • 나는 'interpolator'를 'intruder'로 착각해서 읽었음. 그렇다면 'extraloper'라는 단어도 있는지 궁금해짐
  • 본문의 대부분에는 동의하지만, "AI가 제공할 수 있는 수준에서 실력 향상이 멈춘다"는 것에는 agree하지 않음. 내 경험상 AI를 잘 쓰려면 '고정적'이 아니라 '성장적' 마인드로, 나는 AI의 매니저처럼 역할 놀이하며 출력을 계속 개선함. 어느 정도 한계는 있지만, 직접 해당 스킬을 배우지 않아도, 문제의 경계에 집중해가며 결과의 품질을 상당히 높일 수 있었음. 시간이 흐를수록 현장 전문가가 되지 않고도, 그 분야의 더 나은 매니저로 성장함을 느끼고 있음

    • 본인이 "어떻게"를 모른다면 품질이 충분히 나아졌다는 걸 무슨 기준으로 아는지 궁금함. 결국 시작 품질과 비교한 상대적 향상일 텐데, 자기 만족만 되면 실제로 품질이 낫지 않아도 상관 없는 걸로 보임

    • 나는 이런 방식이 "치팅"이라고 보지 않음

  • 학습 곡선에서 AI를 쓰다가도, 절정 근처에 이르면 오히려 AI 없이 배우는 경우가 더 좋아질 것임. 최고의 숙련도는 천천히, 자기주도적으로 배우는 시간을 통해서만 가능함

  • LLM의 가장 큰 장점은 광고나 소셜 미디어에 방해받지 않고, 통일된 포맷으로 정확한 답변을 받을 수 있다는 점임. reddit이나 insta, tvtropes에서 답변을 찾는 것과 정반대임. 생각 도우미로서 완전히 집중할 수 있는 OS와, 자녀가 콘텐츠 함정에 빠지지 않게 도와주는 환경이 빨리 나왔으면 좋겠음. 나는 ad hoc UI에 방해받지 않고 필요한 문서와 정보만 빠르게 받는 게 정말 좋음

    • 나는 AI 답변이 정확하다고 생각하지 않고, 오히려 위험할 정도인 경우가 흔하다고 느낌. 커뮤니티에서는 누가 전문가인지 판단하기 쉽고, 결국 맞는 답변을 얻을 수 있지만, AI 역시 이 데이터를 다 수집했으니 틀린 답을 내놓을 위험도 똑같음. 광고 없는 환경도 얼마 못 갈 것 같음. AI 기업들은 엄청난 적자를 내고 있으니 곧 광고와 소셜 요소가 넘칠 테고, 지금의 무료 혜택은 그냥 고객을 유인하는 손실 보전 전략에 불과함

    • "정확하다"는 표현이 주관적임을 비꼼

  • 내가 더 잘 아는 AI 분야도 이 흐름과 일치함. 평균 이하인 사람도 AI로 평균에 가까운 결과를 얻을 수 있음

    • 더 많은 지식을 가진 사람이 LLM을 써야 제대로 이득을 본다는 또다른 요약과도 일치함

    • 평균 이상인 사람도 AI를 써서 평범한 결과물을 낼 수 있음. 많은 작업에서 '충분히 괜찮다'의 기준이 오히려 매우 낮음

    • 그래서 여기 있는 사람들이 AI를 반대하는 이유는 다들 평균 이상이라서 그런 것 같다는 농담임

    • "평균 이하가 AI로 평균 수준의 결과를 내면" 전체 평균도 그만큼 올라가는 셈임

  • "AI는 프로토타이핑에 좋고, 엔지니어링에는 좋지 않다"고 요약할 수 있을 것 같음. AI 도구는 속도는 빠르지만 breadth(넓이)와 depth(깊이)가 부족함. 빠르게 PoC나 부분 문제 해결에는 유용하지만, 전체 맥락과 깊이는 부족하고, 진정한 엔지니어링은 구현 이상의 훨씬 더 많은 요소(문맥, 예외, 실패 형태, 깊은 이해 등)가 필요함. 아무리 뛰어난 프로그래머여도 엔지니어가 아닐 수 있고, 최고의 leetcoder가 팀에 실질적으로 도움이 안 될 수도 있음. 진짜 마스터리로 가려면 경험이 필요하고, 그건 미묘한 것들(비직관적 요소)까지 알아야 함. 매니저가 버튼 하나로 제품을 엔지니어링할 수 있는 시대는 오지 않겠음. 현재의 AI 코드 생성기도 '매니저용 자동화'라는 착각에서 출발했고, 오히려 현업 엔지니어의 설명을 바탕으로 동작하는 툴이 더 낫다고 생각함. Dijkstra의 "자연어로 프로그래밍하는 어리석음"에 대한 논평이 여전히 유효하다고 봄. 관련 원문

    • Michael A. Jackson의 Problem Frames Approach, T.S.E Maibaum의 수공학적 수학 기반, Donald Schön의 암묵지(tacit knowledge) 등 기존 사고도 읽어봤음. LLM 기반 프로그래밍은 프로그램 텍스트와 주석에 지나치게 치중된 논의가 많음. 소프트웨어 엔지니어링은 단순히 프로그램 텍스트를 만드는 게 아니고, 응용수학이나 과학에도 국한되지 않는 분야임. AI 에디터에는 이런 암묵지가 많이 내재되어 있다고 보지만, 이런 부분을 좀 더 명확하게 검토하고 논의하는 것이 좋다는 입장임