AI는 프런트엔드의 잃어버린 10년을 반복하게 하는가?

• 탈숙련화는 숙련 노동을 낮은 숙련의 기술 운용으로 대체해 비용과 진입장벽을 낮추지만, 노동자의 협상력도 약화시킴
• 프런트엔드는 지난 10년간 프레임워크와 도구가 브라우저·접근성·성능 지식을 가리며 front of the frontend 전문성을 밀어냈음
• 에이전트형 AI는 코딩을 더 높은 추상화로 끌어올리지만, 비결정적이고 작은 입력·모델 변화에도 결과가 크게 달라지는 새어나가는(Leaky) 추상화임
• LLM은 Stack Overflow 복붙의 연장선에 있어 숙련자는 빨라지고 초보자도 작동하는 결과를 만들지만, 누군가는 출력물을 이해하고 고쳐야 함
• AI는 더 많은 AI 슬롭과 비용 절감을 만들 수 있지만, 품질·사용자·절충을 이해하는 사람의 필요가 사라지는 것은 아님

탈숙련화로 본 프런트엔드와 AI 코딩

• 탈숙련화(deskilling) 는 숙련 노동을 반숙련 또는 비숙련 노동자가 다룰 수 있는 기술로 대체하는 과정이며, 비용 절감과 진입장벽 하락을 만들지만 노동자의 협상력을 약화시킴
• 프런트엔드 개발은 지난 10년 동안 JavaScript 프레임워크와 도구를 통해 탈숙련화를 겪었고, 프로그래밍 전반에서도 에이전트형 AI가 비슷한 변화를 만들고 있음
• Frontend’s Lost Decade라는 표현처럼, 브라우저와 사용자 환경을 깊이 이해하던 프런트엔드 전문성은 프레임워크 중심 개발에 밀려났음

프런트엔드에서 사라진 전문성

• 과거의 프런트엔드 개발에는 시맨틱 HTML, CSS, 브라우저 차이, 접근성, 점진적 향상, 네트워크 성능, 인터페이스 설계, 사용자 테스트 같은 전문 지식이 필요했음
• 일부 실무자는 이런 영역을 현재의 “frontend”와 구분해 front of the frontend라고 부름
• 프런트엔드 탈숙련화는 브라우저를 JVM이나 iOS 같은 앱 런타임처럼 단순한 컴파일 대상으로 취급하는 프레임워크와 도구의 도입으로 진행됨
• Shadcn radio button 같은 구성요소를 가져오면, 기반 HTML, 브라우저별 미묘한 차이, 페이지 로딩 성능, 접근성을 깊이 이해하지 않아도 기능을 만들 수 있음
• 기업은 일반 프로그래머를 프런트엔드 업무에 쉽게 투입해 비용을 줄일 수 있음
• “풀스택 개발자”는 프런트엔드와 백엔드를 모두 깊이 이해하는 사람이 아니라, JavaScript 프레임워크로 양쪽을 처리할 수 있는 범용 개발자를 뜻하는 경우가 많아짐
• 같은 개발자를 여러 프로젝트 사이에서 쉽게 전환할 수 있고, React Native와 Electron으로 네이티브 앱까지 맡길 수 있음
• 진입장벽이 낮아지는 장점과 함께 노동자의 협상력은 약해짐

AI 코딩은 더 높은 추상화이자 새어나가는(Leaky) 추상화

• 현재 프로그래밍 전반에서 벌어지는 변화는 웹 개발자가 이미 겪은 변화와 닮아 있음
• 손으로 직접 코드를 작성하는 숙련 업무가 반숙련 또는 비숙련 노동자가 다루는 기술로 대체되는 방향으로 움직이고 있음
• 에이전트형 AI를 다루는 노동자에게 최종적으로 어떤 역량이 필요할지, 노동 가격과 로컬·원격 LLM 비용이 어디에 도달할지는 아직 명확하지 않음
• 기업이 이 기술을 비용 절감과 노동자 협상력 약화에 활용할 가능성은 분명해 보임
• 오래 갈고닦은 숙련의 시장 가치가 낮아지는 상황은 장인과 수공업자가 조립라인 노동자로 대체되던 변화와 닮아 있음
• 탈숙련화는 자동화를 통한 효율성 향상, 즉 더 높은 추상화 수준에서 일하게 되는 변화로도 볼 수 있음
• 새로운 기술은 세부사항을 감추고 운영자가 더 큰 그림에 집중하게 만들지만, 어떤 세부사항을 “중요하지 않다”고 볼지는 중대한 판단임
• 추상화의 세부사항은 결국 언젠가 새어 나옴

• “현대적” 프런트엔드의 새는 추상화

  • 추상화는 흔히 성능 비용을 동반하며, 개발자 생산성을 위해 런타임 성능 일부를 포기하는 선택은 고성능 서버와 보통 수준 부하에서는 합리적일 수 있음
  • 느린 네트워크 위의 모바일 폰에서는 같은 절충이 전혀 다른 문제가 됨
  • React 같은 무거운 클라이언트 측 JavaScript 프레임워크와 생태계 패키지를 많이 쓰면 접근성과 저사양 폰·느린 네트워크에서의 성능을 추상화해 버림
  • 결과적으로 그런 문제를 생각하지 않고, 신경 쓰지 않는 선택이 됨

• 에이전트형 코딩의 비결정성

  • 에이전트형 AI로 기능을 만들거나 버그를 고칠 때는 직접 모든 코드를 쓰는 대신 더 적은 말로 높은 수준의 변경을 기술함
  • AI는 훈련 데이터와 주변 맥락을 보고 생략된 세부사항을 채우며, 때로는 잘 추측하고 때로는 실패함
  • 이 방식이 유용한지는 코딩에서 무엇이 중요하다고 보는지에 크게 좌우됨
  • 에이전트형 코딩은 컴파일러처럼 결정적이지 않고, 입력이나 모델의 작은 변화가 매우 다른 결과를 낳을 수 있어 기존 프로그래밍 추상화보다 훨씬 더 많이 새어 나옴
  • AI를 “주니어 엔지니어”와 비교하는 이유도 비결정성에 있지만, 사람은 AGENTS.md나 SKILL.md 파일을 끝없이 조정하지 않아도 학습할 수 있다는 차이가 있음

LLM은 Stack Overflow 복붙의 연장선

• LLM 사용에 가장 가까운 비유는 과거의 Google 검색 사용 방식임
• 적절한 포럼 글이나 Stack Overflow 답변을 첫 검색 결과 페이지에 띄우기 위해 정확한 키워드를 고르는 능력도 개발자가 배워야 할 기술이었음
• LLM 프롬프트도 훈련 데이터의 적절한 조합을 반환하게 만드는 과정이며, 퍼지 웹 검색처럼 매우 고차원 공간에서의 조회에 가까움
• 검색 결과는 문구의 작은 변화와 Google 검색 색인 변화에 민감했고, LLM도 입력 표현과 모델 변화에 민감함
• 최근 Google은 입력 용어를 더 강하게 정규화하도록 검색을 바꿨고, Google-fu에 익숙하지 않은 사람에게는 검색이 쉬워졌지만 숙련자에게는 덜 강력해짐
• Google과 Stack Overflow는 프로그래밍을 되돌릴 수 없게 바꿨고, 매뉴얼을 읽는 대신 답변을 복사·붙여넣기해도 놀라울 정도로 자주 어느 정도 작동하는 결과를 얻을 수 있게 했음
• LLM은 같은 흐름의 연장선에 있음
  • 무엇을 하는지 아는 사람을 조금 더 빠르게 만듦
  • 무엇을 하는지 잘 모르는 사람도 어느 정도 작동하는 것을 만들 수 있게 함
• 추상화는 언젠가 새어 나오며, 그때는 누군가가 실제로 무슨 일이 벌어지는지 깊이 이해하고 고쳐야 함
• 주니어 개발자에게 Stack Overflow 답변을 쓰기 전에 읽고 이해하라고 가르쳤듯, 이제는 LLM 출력물을 읽고 이해하며 기존 코드베이스에 어떻게 맞는지 파악하게 해야 함

품질과 비즈니스의 거리

• 일부 프로그래머는 Stack Overflow 답변을 진짜로 이해하는 단계까지 나아가지 않았고, 결과가 작동하면 충분하다고 여겼음
• 많은 회사도 공개적으로 인정하지는 않았지만 이런 접근에 만족했음
• 지금은 회사들이 결과물을 들여다보는 척조차 하지 않으면서 AI를 얼마나 많이 쓰는지 공개적으로 내세우는 상황이 됨
• LLM의 유효한 사용 사례는 분명히 있지만, 코드를 망치고 조직의 커뮤니케이션과 프로세스를 망칠 새로운 방식도 많아짐
• 코드 리뷰와 마찬가지로 LLM을 워크플로에 어떻게 사용하고 통합할지에 대한 견해 차이가 크며, 팀이 무엇을 가치 있게 여기는지 맞지 않으면 작업 흐름에 큰 문제가 생김
• 많은 회사는 형편없는 소프트웨어를 계속 만들어도 잘 운영됨
• 프로그래머가 믿고 싶어 하는 것과 달리, 비즈니스 성공과 소프트웨어 품질은 매우 드물게만 상관됨
• 보통은 브랜드, 가격 등 다른 요인이 더 크게 작용하고, 소프트웨어 프로젝트는 성공과 실패가 비슷한 확률로 발생하는 블랙박스처럼 다뤄짐
• 프런트엔드에서도 느린 웹사이트와 많은 쿠키 배너는 전환율을 해칠 수 있지만, 그 영향은 브랜드 충성도와 가격 같은 요인보다 작고 경쟁사 웹사이트도 느린 경우가 많음
• “React를 골라서 해고된 사람은 없다”는 식의 분위기 속에서 품질보다 안전한 선택이 선호됨
• 사용자와 장인정신을 신경 쓰는 일을 그만둬야 한다는 뜻은 아니지만, 그렇게 할 수 있는 직장을 찾기는 더 어려워졌음
• 과열이 지나가고 LLM이 실제로 적합한 작업과 그렇지 않은 작업에 대한 이해가 생기면 일부 균형이 돌아올 수 있지만, 직업 자체는 이전과 같지 않을 것임

산업화 이후에도 남는 기술

• 일상 제품과 건물이 산업 공정으로 대량생산될 수 있게 되었을 때, 한 반응은 과거 양식을 모방해 수공예품처럼 보이는 제품과 건물을 공장에서 찍어내는 것이었음
• 이런 역사주의에 맞서 20세기 초 Bauhaus는 공장 노동자와 장인을 대립시키기보다, 둘이 함께 일하고 산업 제조 공정을 전제로 예술과 공예를 다시 개발하는 접근을 발전시킴
• Bauhaus는 디자이너가 작업장으로 돌아가 재료를 직접 다루되, 최종 목표는 대량생산 가능한 디자인에 두도록 요구했음
• 소프트웨어는 작성한 프로그램이 제조 단계를 거치지 않고 “그대로” 사용자에게 전달된다는 점에서 공예에 가깝고, 같은 것을 수천 명의 사용자에게 배포한다는 점에서는 산업디자인에 가까움
• 손으로 코드를 쓸 수 있는 능력은 여전히 필요하며, 산업디자이너가 제품의 재료를 알아야 하듯 웹 디자이너는 HTML과 CSS에 매우 익숙해야 함
• Google, Stack Overflow, 바로 쓸 수 있는 라이브러리, LLM은 초보자가 더 쉽게 시작하도록 만들지만, 무언가를 작동하게 만드는 자연스러운 장벽도 계속 낮춤
• 산업화는 사용 방식과 사용자를 충분히 생각하지 않은 싸구려 플라스틱 제품을 많이 만들었지만, 좋은 산업디자인은 여전히 존재함
• 워드프로세서는 형편없이 서식이 잡힌 문서를 많이 만들었지만, 타이포그래피와 그래픽 디자인은 여전히 존재함
• Wix와 Next.js는 느리고 접근성 낮은 웹사이트를 많이 만들 수 있게 했지만, front of the frontend 실무자도 여전히 존재함
• AI는 많은 AI 슬롭을 가능하게 하지만, 무엇을 하는지 알고 자신의 일에 신경 쓰는 사람이 필요하지 않다는 뜻은 아님

앞으로의 변화와 절충

• 다른 산업과 마찬가지로 제대로 하는 일의 비중은 전체에서 더 작아질 가능성이 있음
• 동시에 더 쉽고 저렴하게 만들 수 있게 되면서 전체 파이는 계속 커질 것임
• 일을 잘하는 대가를 받는 사람의 절대 수가 늘어날지 줄어들지는 지금 판단하기 어려움
• 빠른 프로토타입이나 MVP를 찍어내는 것이 올바른 선택일 때도 있음
• 제품-시장 적합성을 아직 찾지 못했다면 모든 것을 미래 대비로 만드는 것보다 빠른 반복과 학습이 더 중요함
• 다만 무엇을 배우려는지, 그 학습을 어떻게 검증할지 알아야 함
• 적절한 시점이 오면 보통 한 걸음 물러서서 처음부터 제대로 하는 편이 더 나음
• 예를 들어 나쁜 아키텍처의 프런트엔드에서 나중에 좋은 성능을 달성하기는 매우 어려움
• 단순한 스택으로 시작해 나중에 기능을 추가하는 편이 그 반대보다 쉬움
• Mastro는 좋은 성능과 단순한 스택 출발을 명시적으로 장려함
• 서비스 구매, 오픈소스 라이브러리 사용, LLM 생성, 직접 작성 중 무엇을 택하든 시스템의 각 부분에서 어떤 절충을 하는지 알아야 함
• 과열이 가라앉으면 업계는 AI가 도구상자의 또 하나의 도구일 뿐이라는 점을 깨닫게 될 것임
• 그때까지는 AI라는 명목 아래 추한 코드, 망가진 커뮤니케이션, 끔찍한 해고가 계속 나타날 수 있음