AI 코딩은 프론트엔드의 ‘잃어버린 10년’을 반복하고 있나

프론트엔드가 먼저 겪은 일

• 글쓴이는 지금 AI가 프로그래머 일자리에 주는 느낌이 프론트엔드 개발자에게는 낯설지 않다고 봄

  • 이미 지난 10년 동안 프론트엔드는 비슷한 변화를 겪었고, Alex Russell은 이를 ‘프론트엔드의 잃어버린 10년’이라고 불렀음
  • 핵심 키워드는 탈숙련화(deskilling)임
  • 숙련 노동이 기술 도입으로 반숙련·비숙련 작업으로 바뀌고, 기업은 비용을 줄이며 노동자의 협상력은 약해지는 현상을 말함

• 예전 프론트엔드는 생각보다 훨씬 전문적인 영역이었음

  • 시맨틱 HTML, CSS, 브라우저별 차이, 접근성, 점진적 향상(progressive enhancement), 네트워크 성능, 인터페이스 디자인, 사용자 테스트까지 알아야 했음
  • 요즘 이 영역을 구분해서 ‘프론트 오브 더 프론트엔드’라고 부르는 사람들도 있음
  • 단순히 화면에 버튼 올리는 일이 아니라, 브라우저라는 런타임과 사용자 환경을 깊게 이해하는 일이었다는 뜻임

• 그런데 프레임워크와 도구가 브라우저를 그냥 컴파일 타깃처럼 다루기 시작하면서 상황이 바뀜

  • React, Next.js, Shadcn 같은 조합을 쓰면 underlying HTML이나 접근성, 로딩 성능을 깊게 몰라도 화면을 만들 수 있음
  • 기업 입장에서는 백엔드 하던 개발자도 프론트엔드 프로젝트에 투입하기 쉬워짐
  • ‘풀스택 개발자’가 프론트와 백엔드를 모두 깊게 아는 사람이 아니라, 자바스크립트 프레임워크를 양쪽에서 적당히 다루는 일반주의자가 되는 경우도 많아졌다는 지적임

AI 코딩도 같은 방향으로 간다

• 글쓴이는 AI 코딩이 프로그래밍 전반에서 비슷한 탈숙련화를 만들고 있다고 봄

  • 수동으로 코드를 쓰는 숙련 노동이, 에이전틱 AI를 다루는 반숙련 작업으로 대체되는 흐름이라는 것임
  • 아직 AI를 잘 다루는 노동자에게 정확히 어떤 스킬셋이 필요한지, 임금과 모델 비용이 어디에 수렴할지는 확실하지 않음
  • 다만 기업이 비용 절감과 노동자 협상력 약화를 위해 이 기술을 쓸 거라는 점은 이미 꽤 명확하다고 봄

• 이 변화에는 상실감이 따라온다는 얘기도 꽤 솔직함

  • 반평생 갈고닦은 기술이 시장에서 덜 가치 있게 평가되는 느낌이 든다는 것임
  • 더 슬픈 건 새 프로세스가 낮은 품질의 결과물을 만들 때가 많은데도, 많은 조직이 별로 신경 쓰지 않는다는 점임
  • 장인과 공예가가 조립라인 노동자로 대체되던 산업화 시대의 감정과 비슷하다고 비교함

추상화는 편하지만, 결국 샌다

• 탈숙련화를 다르게 보면 높은 수준의 추상화로 생산성을 높이는 과정이라고도 볼 수 있음

  • 엔지니어는 원래 자동화를 좋아하고, 세부 구현을 감추는 추상화는 많은 일을 빠르게 하게 해줌
  • 문제는 어떤 디테일을 ‘안 중요한 것’으로 취급할지 결정하는 순간임
  • 그 결정은 기술적이면서도 주관적이고, 시간이 지나면 숨겨둔 디테일이 결국 새어 나옴

• 현대 프론트엔드는 새는 추상화의 탑처럼 보인다는 비판이 나옴

  • 고성능 서버에서 가비지 컬렉션 같은 추상화 비용을 감수하는 건 합리적일 수 있음
  • 하지만 느린 네트워크와 저가형 모바일 기기에서는 무거운 클라이언트 자바스크립트 프레임워크의 비용이 확 튀어나옴
  • React와 대량의 패키지 생태계에 기대면 접근성, 저사양 폰 성능, 느린 네트워크 같은 문제를 사실상 “생각하지 않겠다”고 선택하는 셈이라는 지적임

• 에이전틱 코딩은 더 특이한 종류의 추상화임

  • 요구사항을 높은 수준의 말로 설명하면 AI가 누락된 세부사항을 훈련 데이터와 주변 컨텍스트를 보고 채움
  • 잘 맞을 때도 있지만, 입력 문구나 모델이 조금만 달라도 결과가 크게 달라질 수 있음
  • 컴파일러처럼 결정적인 추상화가 아니라서, 사람들이 AI를 주니어 개발자에 비유하는 이유도 여기에 있음
  • 다만 사람은 배우지만, 모델은 AGENTS.md나 SKILL.md를 끝없이 손봐도 같은 방식으로 성장하지 않는다는 차이가 있음

스택오버플로 복붙의 다음 단계

• 글쓴이는 LLM 사용을 예전 구글 검색과 스택오버플로 복붙의 연장선으로 봄

  • 예전 개발자에게는 정확한 키워드를 골라 포럼 글이나 스택오버플로 답변을 찾는 ‘구글푸’가 중요한 기술이었음
  • LLM 프롬프팅도 훈련 데이터의 고차원 공간에서 원하는 조합을 꺼내는 fuzzy lookup이라는 점에서 비슷하다고 봄
  • 단어 하나만 바꿔도 결과가 달라지는 민감함 역시 예전 검색과 닮아 있음

• 구글과 스택오버플로도 프로그래밍을 되돌릴 수 없게 바꿨음

  • 매뉴얼을 정독하는 대신 답변을 복붙해도 꽤 자주 “대충 돌아가는” 결과가 나왔음
  • LLM도 마찬가지로, 아는 사람은 조금 더 빨라지고 모르는 사람도 그럴듯한 결과를 얻을 수 있게 해줌
  • 글쓴이는 이 자체를 나쁘다고만 보지는 않음
  • 다만 추상화가 새는 순간에는 누군가 시간을 들여 깊이 이해하고 고쳐야 한다고 강조함

• 그래서 교육의 핵심도 바뀌어야 함

  • 예전에는 주니어에게 스택오버플로 답변을 읽고 이해한 뒤 쓰라고 가르쳤음
  • 이제는 LLM이 뱉은 코드를 읽고 이해하고, 기존 코드베이스에 어떻게 들어맞는지 판단하도록 가르쳐야 함
  • 그냥 돌아간다는 이유로 넣으면, 나중에 팀 전체가 디버깅 비용을 떠안게 됨

품질은 정말 돈이 되나

• 글쓴이는 불편한 사실도 짚음: 많은 회사는 나쁜 소프트웨어를 만들면서도 돈을 잘 번다

  • 개발자들이 믿고 싶어 하는 것과 달리, 비즈니스 성공과 소프트웨어 품질은 자주 강하게 연결되지 않음
  • 브랜드, 가격, 시장 위치 같은 다른 요인이 훨씬 크게 작동할 때가 많음
  • 소프트웨어 프로젝트는 실패할 수도 있는 블랙박스로 취급되고, 안 되면 다른 팀이 다시 만드는 식으로 리스크를 분산하기도 함

• 프론트엔드도 비슷했음

  • 느린 웹사이트와 쿠키 배너가 전환율을 떨어뜨릴 수는 있음
  • 하지만 브랜드 충성도나 가격 같은 요인에 비하면 영향이 작게 보일 수 있고, 경쟁사 사이트도 다 느리면 더더욱 문제로 덜 보임
  • “React 골랐다고 해고당한 사람은 없다”는 식의 조직 논리가 여기서 나옴

• 그렇다고 사용자와 craft를 포기하자는 얘기는 아님

  • 다만 그런 걸 신경 쓸 수 있는 일자리를 찾기가 더 어려워졌다는 현실을 말함
  • AI 과열이 지나가고 어떤 작업에 LLM이 맞고 맞지 않는지 더 명확해지면, 어느 정도 균형은 돌아올 수 있다고 봄
  • 그래도 프로그래밍 직업이 예전과 같지는 않을 거라는 결론임

바우하우스에서 가져온 힌트

• 글쓴이는 산업화 시대의 바우하우스를 소프트웨어의 비유로 가져옴

  • 대량생산이 등장했을 때 어떤 사람들은 과거 수공예 스타일을 흉내 내는 방향으로 대응했음
  • 바우하우스는 공장 노동자와 장인을 대립시키기보다, 산업 공정에 맞춰 예술과 공예를 다시 설계하려 했음
  • 디자이너가 재료를 직접 만지고 이해하되, 최종적으로는 대량생산될 제품을 설계하는 접근이었음

• 소프트웨어도 craft와 산업 디자인 사이 어딘가에 있음

  • 우리가 쓴 프로그램은 제조 단계를 거치지 않고 거의 그대로 사용자에게 배포됨
  • 동시에 수천, 수만 명의 사용자가 같은 제품을 쓰고, 우리는 그들이 실제로 쓰는 모습을 직접 보지 못할 때가 많음
  • 그래서 웹 디자이너가 HTML과 CSS를 깊게 알아야 한다는 점은 여전히 중요하다고 봄

• 도구가 진입 장벽을 낮추는 건 좋은 일이지만, 끔찍한 결과물도 늘어난다는 게 문제임

  • Wix와 Next.js가 느리고 접근성 나쁜 사이트를 많이 만들 수 있게 했지만, 여전히 좋은 프론트엔드 전문가가 존재함
  • LLM도 AI slop을 많이 만들겠지만, 그렇다고 제대로 알고 신경 쓰는 사람이 필요 없어지는 건 아님
  • 오히려 “대충 되는 것”이 쉬워질수록, “제대로 되는 것”을 구분하는 능력이 더 중요해짐

결국 도구 상자 안의 하나가 될 것

• 글쓴이는 모든 걸 제대로 만드는 영역이 전체 파이에서 더 작은 비중이 될 수 있다고 봄

  • 하지만 싸고 쉽게 만들 수 있게 되면서 전체 파이 자체는 커질 가능성이 큼
  • 제대로 만드는 사람의 절대 숫자가 늘지 줄지는 아직 모르겠다고 함
  • 다른 디자인 분야처럼, 안 좋은 결과물이 넘쳐도 좋은 작업은 계속 존재할 수 있음

• 빠른 프로토타입이나 MVP가 맞는 순간도 분명 있음

  • 아직 제품시장적합성(product-market fit)을 찾지 못했다면, 미래 확장성보다 빠른 반복과 학습이 중요할 수 있음
  • 다만 무엇을 배우려는지, 어떻게 검증할지 알아야 함
  • 때가 되면 처음부터 제대로 다시 설계하는 게 낫고, 특히 잘못 설계된 프론트엔드에서 나중에 성능을 끌어올리기는 매우 어렵다고 함

• 시스템의 각 부분마다 트레이드오프를 의식적으로 골라야 한다는 게 결론임

  • 서비스를 살지, 오픈소스 라이브러리를 쓸지, LLM에게 만들게 할지, 직접 작성할지 판단해야 함
  • AI 과열이 가라앉으면 업계는 LLM을 도구 상자의 도구 하나로 보게 될 가능성이 큼
  • 그전까지는 못생긴 코드, 깨진 팀 커뮤니케이션, AI를 명분으로 한 해고 같은 보기 싫은 장면을 꽤 많이 보게 될 거라는 전망임

---

기술 맥락

• 이 글에서 중요한 선택지는 “프레임워크나 LLM을 쓸 것인가”가 아니라 “어떤 디테일을 도구에 맡길 것인가”예요. 프론트엔드에서는 HTML, CSS, 접근성, 네트워크 성능을 프레임워크 뒤로 밀어뒀고, AI 코딩에서는 구현 디테일과 코드 판단을 모델에게 넘기기 쉬워졌거든요.

• React 같은 클라이언트 중심 스택이 문제가 되는 이유는 브라우저를 단순 실행 타깃으로 보기 때문이에요. 서버나 고성능 데스크톱에서는 비용이 작아 보여도, 느린 모바일 네트워크와 저사양 기기에서는 자바스크립트 번들 크기와 렌더링 비용이 그대로 사용자 경험에 드러나요.

• Agentic coding은 기존 추상화보다 더 조심해야 해요. 컴파일러는 같은 입력에 같은 결과를 주지만, 대규모 언어 모델(LLM)은 프롬프트와 주변 컨텍스트에 따라 다른 코드를 만들 수 있거든요. 그래서 결과물을 검토하는 능력이 코드를 직접 쓰는 능력만큼 중요해져요.

• 스택오버플로 복붙과 LLM의 공통점은 ‘대충 돌아가는 코드’를 얻기 쉬워졌다는 점이에요. 하지만 기존 코드베이스의 설계 원칙, 테스트 전략, 성능 제약을 모르면 그 코드는 나중에 유지보수 비용으로 돌아와요.

• 바우하우스 비유가 꽤 적절한 이유도 여기에 있어요. 좋은 산업 디자이너가 재료를 이해한 상태에서 대량생산을 설계하듯, AI 시대의 개발자도 도구를 쓰되 HTML, CSS, 런타임, 코드 구조라는 재료를 계속 직접 이해해야 해요.