▲

AI가 주니어 개발자를 쓸모없게 만들고 있다

 (beabetterdev.com)
14P by GN⁺ 8시간전 | ★ favorite | 댓글 4개
  • AI 도구가 주니어 개발자에게 얕은 역량만 만들어주고 있으며, 코드를 빠르게 출력하지만 왜 그런 접근을 택했는지 설명하지 못하는 상황이 빈번해짐
  • 시니어 개발자의 진정한 가치는 코드 작성 속도가 아니라, 수년간 실패를 통해 축적한 실패 패턴 인식에 있음
  • AI를 사용하더라도 에러를 직접 분석하고, 코드를 추적하고, 가설을 세우는 의도적 고군분투 과정이 필수적임
  • 커밋하는 모든 코드에 대해 라이브러리 선택 이유, 패턴, 트레이드오프를 직접 설명할 수 있어야 하며, 그렇지 않으면 출시 준비가 안 된 것임
  • AI를 단순 답 생성기가 아닌 튜터로 활용해, 여러 접근법의 장단점을 학습하는 방식으로 전환해야 함

문제의 본질: AI가 만드는 얕은 역량

  • LLM 활용으로 빠른 기능 구현과 배포가 가능해졌지만, 코드 선택 이유를 설명하지 못하는 상황 발생
    • 코드 리뷰에서 접근 방식을 묻는 질문에 답하지 못하는 얕은 역량(shallow competence) 현상이 확산
    • AI가 제시한 코드를 그대로 수용하는 패턴이 반복됨
  • 겉으로는 생산성이 높아 보이지만, 설계 의도와 트레이드오프에 대한 이해가 부족한 상태
  • 이러한 문제는 시간이 지나며 신뢰 하락으로 이어질 가능성이 있음

시니어 개발자가 가치 있는 이유

  • 경험 많은 개발자가 비싼 이유는 코드를 빠르게 쓰기 때문이 아니라, 무엇을 하지 말아야 하는지 오랜 시간에 걸쳐 체득했기 때문
  • 잘못된 아키텍처 결정을 내리고 그 결과와 함께 살아본 경험, 새벽 2시에 장애 호출을 받아본 경험 등에서 비롯된 실패 패턴 인식이 기업이 실제로 지불하는 비용
  • 현재 많은 주니어 개발자가 AI 활용 과정에서 이 과정을 건너뛰는 현상이 발생

5가지 전략

  • 1. 기초를 제대로 학습할 것

    • 좋은 코드가 무엇인지 알아야 AI가 내놓는 결과물을 평가할 수 있으며, 그렇지 않으면 AI 출력을 맹목적으로 수용하게 됨
    • 추천 도서: Head First Design Patterns(코딩 패턴과 선택 이유 이해)와 Designing Data-Intensive Applications(데이터 집약 시스템 설계 원리)

  • 2. 장애 사례를 공부할 것

    • Cloudflare, AWS, Azure, Google 등 대형 서비스 장애 시 발행되는 상세 포스트모템(post-mortem) 문서를 읽을 것을 권장
      • 원인, 근본 원인 분석, 수정 방법, 재발 방지 대책 등이 포함되어 있음
    • Amazon에서는 COE(Correction of Errors), Facebook 등 대부분의 대형 기술 기업에도 내부 유사 문서가 존재
    • 복잡한 시스템이 어떻게 무너졌는지 이해하는 것이 문서를 읽는 것보다 훨씬 강하게 기억에 남음

  • 3. 고군분투를 의도적으로 만들 것

    • AI 이전에는 문제를 직접 해결하는 과정이 선택이 아니라 기본이었으나, 이제 24시간 사용 가능한 탈출구가 존재
    • 에러를 AI에 붙여넣기 전에 먼저 스택 트레이스를 읽고, 코드를 추적하고, 로그를 확인하고, 무엇이 잘못되었는지 가설을 세워볼 것
      • 이 과정이 진짜 디버깅 감각을 구축하는 방법
      • AI는 이후에 활용해도 됨
    • 온콜에 참여하고, 아무도 안 잡는 티켓을 맡는 것이 시스템 작동 원리를 배우는 가장 효과적인 방법

  • 4. 이해하지 못한 코드를 절대 출시하지 말 것

    • 코드 리뷰에서 특정 접근법을 택한 이유를 물었을 때 "AI가 제안했다"고 답하면, 즉시 신뢰를 잃음
      • AI를 사용한 것이 문제가 아니라, 자신이 제출하는 코드를 이해하려는 노력을 하지 않은 것이 문제
    • 커밋하는 모든 라인에 대해 왜 이 라이브러리인지, 왜 이 패턴인지, 트레이드오프가 무엇인지 설명할 수 있어야 함
    • 속도를 줄이더라도 이해가 선행되어야 하며, 단순 복사-붙여넣기하는 사람이라는 평판은 회복하기 매우 어려움

  • 5. 답이 아니라 "왜"를 프롬프트할 것

    • AI에게 문제 해결만 요청하는 대신, 여러 접근법과 각각의 장단점 설명을 요청할 것
    • 이렇게 하면 두 가지 효과 발생:
      • 트레이드오프에 대해 실제로 학습하게 됨
      • AI가 추론 과정을 거치면서 추천 자체가 바뀌는 경우도 있어, 더 나은 답을 얻을 수 있음

속도 압박에 대한 현실적 조언 : 생산성과 학습의 균형

  • 속도를 늦추면 뒤처질 것이라는 우려는 현실적이나, 업무를 완전히 멈출 필요는 없음
  • 여유 시간, 사이드 프로젝트, 경쟁이 적은 티켓 등에서 의도적이고 불편한 학습을 수행할 것
  • 실제 기술을 쌓는 시간과 단순 출력하는 시간을 의식적으로 구분해야 함

AI를 튜터로 활용할 것

  • 이전 세대 개발자에게는 없었던, 무엇이든 원하는 깊이로 설명해주는 AI 튜터를 지금 가지고 있음
  • AI에게 일을 시키기만 하지 말고, 설명을 요청하고 가르치게 하는 방식으로 활용해야 함
  • 개발자의 가치는 코드를 출력하는 능력이 아니라, 어떤 코드든 보고 좋은 코드인지 판단할 수 있는 능력에 있음
  • AI가 생성한 코드 여부와 무관하게, 좋고 나쁨을 구분하는 능력이 핵심 역량
  • 의도적 학습과 실패 경험 축적만이 장기적 경쟁력을 형성할 수 있음
▲
roxie 7시간전  [-]

???: "무엇을 하지 말아야 하는지 신중하게 고려해"

답변달기
▲
pluto 6시간전  [-]

ㅋㅋㅋㅋㅋㅋ

답변달기
▲
kimjoin2 6시간전  [-]

AI 가 출력하는 텍스트라도 읽었으면 이 꼴은 안남.
그냥 주니어가 아니라 복붙 딸깍만 하는 주니어가 문제.

사실 AI 이전에도 있었죠.
스택오버플로우에서 AI 가 됐을 뿐이지.

답변달기
▲
GN⁺ 8시간전  [-]
Hacker News 의견들

  • 나는 앞으로 AI 없이 배우는 기간이 필수적이라고 생각함
    모든 기술 습득에는 ‘직접 손으로 해보는 반복 연습’이 핵심임
    학습 단계는 “AI 없이 직관 형성 → AI를 점진적으로 활용해 한계를 이해 → AI 네이티브 전문가”로 발전할 것이라 봄
    하지만 대규모로 이걸 구현하는 방법은 아직 미정임
    아이러니하게도 AI는 개인 맞춤형 튜터로 유용하지만 동시에 실습을 회피하게 만드는 유혹이 됨
    현재의 시험 중심 교육 시스템은 오히려 AI 의존을 강화함
    그래서 나는 견습 제도가 다시 부활할 것이라 예측했고, Microsoft의 preceptorship 제안을 그 신호로 봄
    대기업이 문제를 인식하고 해결책을 제시했다는 점이 고무적임

    • 나도 비슷한 경험이 있음. Mathematica나 WolframAlpha 같은 도구가 있었지만, 미적분을 배우려면 수백 번의 손 계산을 직접 해야 했음
      이런 도구들은 내가 어디서 틀렸는지 이해하는 데 도움을 줬지만, 결국 손으로 하는 연습이 핵심이었음
    • 수세기 동안의 연구는 ‘직접 실습’과 ‘이론 학습’을 대비시켜 왔음
      하지만 지금의 AI 사용은 단순히 이론을 배우는 게 아니라, 마치 노예에게 일을 시키는 것과 같음
      역사적으로 그런 방식은 숙련을 낳지 못했음
    • 학생들이 AI를 남용하지 않게 하려면 간단함 — 종이와 연필 시험, 전자기기 금지
    • 자기 절제만으로 AI를 피하는 건 현실적으로 매우 어려움
      이미 수많은 사람들이 소셜 미디어 중독을 통제하지 못하고 있음
    • 나도 동의하지만, 요즘 소프트웨어의 단순함과 미학이 사라지고 있음
      Rich Hickey의 Simple Made Easy 강연이 내 커리어에 큰 영향을 줬음
      AI는 ‘맛’이 없고, 코드 양을 늘리는 방향으로 작동함
      진짜 엔지니어링은 적은 코드로 가장 영향력 있는 기능을 만드는 예술임

  • 예전에도 주니어 개발자는 생산성보다 학습을 위해 존재했음
    시니어가 몇 시간 만에 끝낼 일을 일부러 일주일짜리 과제로 줬던 이유가 그거였음
    지금은 기업들이 그 ‘훈련 비용’을 회피하려 함

    • 아이를 키우는 사회적 비용과 비슷한 구조임
      모두가 단기적 이익만 보고 장기적 붕괴를 초래함
      주니어가 없으면 시니어도 사라지고, 결국 산업 자체가 무너질 것임
    • 우리 회사는 지역 대학과의 협약 때문에 매년 인턴과 주니어를 뽑아야 함
      비용 절감과 승진 구조의 균형을 위해서도 주니어는 필요함
      하지만 AI가 등장하면서 이제는 중간급 개발자까지 대체될 가능성이 있음
    • 현실적으로 주니어는 투자 대비 효율이 낮고, 이직률도 높음
      단기 목표를 맞추는 입장에서는 “주니어는 마이너스 생산성”임
    • 좋은 주니어는 다름. 에너지와 열정이 넘치고, 빠르게 성장함
    • 어떤 신입들은 시니어보다 빠르게 배우고 뛰어남
      느린 이유는 실력이 아니라 비효율적인 조직 프로세스 때문임

  • 나는 학생들에게 항상 말함 — “주니어는 직접 코드를 써야 함”
    htmx의 글처럼, 시니어는 주니어가 코드를 쓸 수 있게 해야 함
    시니어는 주니어로부터 나오기 때문임

    • 하지만 요즘은 짧은 근속 기간 때문에 회사가 사람을 키우지 않음
      “시니어가 필요하면 시니어를 채용하라”는 식으로 바뀌었음
      이게 COBOL 세대의 반복이 될 수도 있음
    • “LLM이 주니어만큼 똑똑하다”는 말이 문제의 출발점임
      시니어와 주니어의 격차가 커졌고, 손으로 부딪히며 배운 경험이 사라지고 있음
    • 비용에 민감한 기업이 주니어를 키우는 건 어렵지만, 결국 경험 많은 개발자 부족으로 스스로 발목을 잡게 됨
      나 같은 30년차 개발자는 지금 높은 계약 단가를 받음
    • “주니어에게 돈을 주고 코드를 쓰게 해야 하나?”라는 질문이 생김
      코딩이 예술이라면, 결국 예술가처럼 생존 경쟁을 해야 할지도 모름
    • 기업들도 이 딜레마를 알고 있음
      모두가 주니어 양성을 포기하면 결국 시니어 공급 붕괴로 이어짐
      하지만 단기 이익 때문에 규칙을 깨려는 유인이 큼

  • 사실 많은 시니어 개발자도 별로 뛰어나지 않음
    프로젝트 품질은 일정 시점 이후 항상 하락함

    • 내가 속했던 두 팀 모두 ‘시니어’로만 구성됐지만, 진짜 10배 생산성을 내는 사람은 극소수였음
      대부분은 그저 타이틀만 시니어였고, 나도 이름만 시니어일 뿐 중간 수준이었음
    • 문제는 개인의 과대평가보다 조직 전체의 연극화된 구조임
      매니저, 리크루터, 개발자 모두 ‘일하는 척’만 하고, 실제 가치는 소수의 진짜 실력자에게서 나옴

  • 내가 두려워하는 시나리오는, 우리가 프롬프트 관리자로 전락하는 것임
    코드베이스를 제대로 이해하지 못한 채 AI가 고친 코드만 믿게 되는 미래임

    • 나도 요즘은 직접 코드를 거의 안 쓰지만, AI 네이티브 워크플로우에서 새로운 재미를 찾고 있음
      여전히 깊이 있는 문제 해결의 쾌감이 존재함
      다만 React나 NextJS 같은 스택을 직접 안 써도 돼서 행복함
      AI 이전에 탄탄한 기본기를 익힌 사람들은 지금 정말 운이 좋음
    • 이미 현실화됨. 프레임워크 남용과 추상화 과잉이 낳은 비효율이 LLM 코딩으로 이어짐
      ‘left-pad 문화’의 다음 단계일 뿐임
    • 이해 가능한 코드베이스는 여전히 중요함
      그래야 AI도 더 잘 작동하고, 인간의 도메인 지식이 빛을 발함
    • 실제로 이 글도 같은 문제를 다룸
      나도 같은 불안을 느낌
    • 내가 새로 들어간 회사는 코드의 80~90%가 AI 생성임
      리뷰도 거의 없고, 장기적 아키텍처 고려가 사라짐
      품질 저하를 사회 전체가 받아들이는 중인 듯함

  • 요즘은 시니어보다 주니어가 더 유용하다고 느낌
    시니어에게 질문하면 “AI가 이렇게 답했다”고만 함
    반면 주니어는 배우려는 열정이 있고, 스태프급은 여전히 훌륭한 멘토임

    • 나도 봤음. 특히 관리 트랙 시니어들이 이런 경향이 강함
      반면 일부 중간급은 AI 없이는 아무것도 못 함
      문제를 이해하지 못하고, AI가 대신 해결해주자 오히려 자기 무능에 무감각해짐
    • 결국 “쓰지 않으면 잃는다”는 말이 현실이 됨
      LLM 남용은 인지적 퇴화를 초래할 것임
      나는 LLM에 오염되지 않은 사람만 채용하려고 함

  • 이 글 자체가 LLM이 쓴 것처럼 느껴짐
    “It’s not X, but Y” 같은 문체가 너무 전형적임

    • 맞음. 홈페이지 썸네일도 전부 AI 생성이고, 클릭 유도형 제목뿐임
    • 누군가 말했듯, “이 패턴을 한 번 인식하면 세상 모든 글이 그렇게 보인다”는 말이 떠오름
      이제 웹 콘텐츠 대부분이 AI 생성물일 거라 생각하니 우울함
      결국 우리는 진짜와 가짜의 구분이 사라진 세계로 가고 있음
      그래서 나는 차라리 용접을 배우러 갈까 생각 중임
    • 요즘 “AI가 코딩을 쉽게 만들었지만 엔지니어링은 어렵게 했다”류의 글이 넘침
      이 글도 같은 스타일임

  • 문제의 근원은 시니어에게 있음
    주니어에게 쓸모없는 일거리만 주고, 새로운 도구를 활용할 기회를 주지 않음
    이제는 “이메일 템플릿 수정”이 아니라 “내부 프로세스 자동화 서비스 만들기” 같은 과제를 줘야 함

    • 하지만 요즘은 너무 빠르게 결과가 나오다 보니 직관을 쌓을 기회가 줄었음
      주니어가 무엇을 모르는지도 모르는 상태에서 배우기 어렵고, 시니어도 가르치기 힘듦

  • 나는 AI 덕분에 HTML도 모르는 주니어를 채용할 수 있었음
    예전엔 불가능했지만, 이제는 약간의 끈기만 있으면 진입이 가능함
    결국 쉬운 길을 택하면 그만큼의 결과를 얻게 됨

    • 나도 독학으로 수백 통의 이력서를 보냈지만 인터뷰조차 못 받음
      어떻게 그런 주니어가 채용됐는지 궁금함
    • 어려운 길이야말로 인생을 흥미롭게 만드는 요소임
      쉬운 길만 택하면 삶의 깊이가 사라짐
    • HTML도 안 배웠다니, 그게 꼭 필수 과정인가 싶음
      나도 그런 강좌는 들어본 적 없음
    • AI가 대신 일할 수 있는데, 왜 그 주니어에게 급여를 주는지 의문임

  • 결국 AI는 창의성의 원천을 고갈시킬 위험이 있음
    인간이 새로운 아이디어를 내지 않으면 AI는 자기 복제만 하게 됨
    이런 순환은 기술적 정체와 종속을 낳을 것임

    • 하지만 미래의 학습 방식은 달라질 수 있음
      비지도 학습이 이런 한계를 극복할 가능성이 있음
    • 어쩌면 새로운 아이디어보다, 기존 블록을 조합해 새로운 형태의 창조를 하는 시대가 될 수도 있음
    • 오히려 평균 개발자의 역량이 낮아질수록 코딩 LLM의 가치는 더 커짐
      좋은 개발자가 사라지면, 나쁜 AI조차 유용해짐
    • 이런 문제를 깨닫는 시점은 이미 늦은 뒤일 것임
    • 나도 이런 생각을 공유하는 커뮤니티가 있다면 함께하고 싶음
답변달기