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라는 명목 아래 추한 코드, 망가진 커뮤니케이션, 끔찍한 해고가 계속 나타날 수 있음

[GN⁺]

Hacker News 의견들

• OP가 아쉬워하는 깊은 전문성은 사실 많은 사람에게 꽤 불편한 것이었다고 봄
  브라우저별 특이점, 접근 가능한 컴포넌트 직접 구현, CSS 명시도 숙련으로 먹고살 수 있다는 건 이해하지만, 대부분은 우발적 복잡성에 가깝다. 더 많은 사람이 무언가를 만들 수 있게 되는 건 분명히 좋은 일이고, 그 결과물 일부가 더 느리거나 접근성이 떨어진다면 그건 선택 가능한 절충임
  추상화가 사용자가 선택하지 않은 결과를 떠넘긴다고 말할 수도 있지만, LLM은 나보다 접근성 관례를 더 잘 이해할 가능성도 있다고 봄

  • 접근성, 직관성, 호환성, 반응성, 확장성, 아키텍처, 성능 같은 덜 눈에 띄는 UX/소프트웨어 개발 요소를 제대로 다루는 건 늘 어려웠음
    그런데 초고수준 프레임워크와 이제는 LLM이 이런 부분을 망치면서도 반쯤 익은 MVP를 빠르게 내놓기 쉽게 만들었고, 그래서 “받아들일 만함”과 “괜찮음” 사이의 간격이 더 벌어지고 있음. “괜찮음”을 지향하는 입장에서는 “받아들일 만함”을 밀어붙이는 쪽과 경쟁하기가 점점 어려워짐
    결과적으로 더 많은 야근과 소프트웨어 품질 저하, 어쩌면 직무 만족도 전반의 하락으로 이어진다. 요즘은 기본 기능을 되살리려고 개발자 도구와 uBlock으로 망가진 웹사이트를 고치거나 방해 요소를 지우는 일이 생기기 시작했고, 여기서도 같은 일을 한다는 사람들을 봤음(https://news.ycombinator.com/item?id=47042747). 예전에는 Flash나 초기 브라우저 시절에도 이런 식으로 직접 손댈 필요가 없었음
    덜 일화적인 예도 있음: https://news.ycombinator.com/item?id=47390945
    더 나쁜 건 이런 삭감으로 절약된 돈 대부분이 조직 최상층에만 돌아간다는 점임
  • AI는 애니메이션 객체를 블러 객체 뒤에 놓는 실수를 반복해서 브라우저가 계속 다시 그리게 만듦
    Google의 AI mode에도 그런 게 들어갔고, 다른 웹사이트들도 명백히 바이브 코딩으로 비슷한 걸 넣은 듯함
    처음엔 GPU 사용량이 치솟고 팬이 세게 도는 이유가 헷갈렸지만, 이제는 AI가 흔히 저지르는 실수인데 아무도 제대로 테스트하지 않는다는 걸 봄. 사람도 이런 실수를 할 수는 있지만, 지금 전까지는 평생 거의 겪어본 적이 없었음
    240Hz 모니터를 쓰니 브라우저가 초당 240번 다시 그리려 했고, uBlock Origin으로 막는 수밖에 없었음. 말도 안 됨
  • “우리의 장인정신을 잃고 있다” 류의 글은 늘 같은 우울한 구조를 가짐
    더 별로인 건 중간쯤 가면 스스로의 논지를 반박한다는 점임
    예를 들어 “어떤 세부사항을 중요하지 않다고 볼지는 매우 중대한, 때로는 주관적인 결정이고 결국 세부사항은 항상 새어 나온다”고 했는데, 그렇다면 이 새 기술도 결국 깊은 기술 이해에 보상을 준다는 뜻임. 피할 수 없으니까. 거기엔 동의함. 그런데 왜 전체 톤은 “AI가 내 기술을 싸구려 상품으로 만들고 있다”인가?
    웹사이트는 기술적으로 10년 전보다 대체로 나아졌음. 기능은 더 많고, 더 빠르며, SSL/접근성/반응형은 더 강한 기본값이 됐음. 콘텐츠 공장, SEO, 뉴스 사이트 문제는 광고와 기업 인센티브가 만든 별개의 끔찍한 실패 양상이지, React 탓은 아님
  • “LLM이 접근성 관례를 나보다 더 잘 이해할 것”이라는 건 정확히는 다른 사람들이 이해하고 글로 썼기 때문임
    LLM은 가끔 그걸 활용할 수 있음. 그런데 사람들이 더 이상 쓰지 않게 되면 그다음은 어떻게 되나?
    더 많은 사람이 무언가를 만드는 게 좋다는 데는 동의함. 나머지가 같다면 많을수록 좋음. “AI”가 부정할 수 없는 개선 때문에 모든 곳에 스며든 거라면 상황과 정서는 훨씬 달랐을 것임
    그래도 사람들은 작업을 통해 “생성된” 지식에 대해 당연한 권리를 갖는 건 아님. 귀속과 보상이 진지하게 다뤄지고, 자료를 만든 사람에게 돈을 지불한 자료로만 학습할 수 있다면, 그냥 CSS를 배우는 편이 훨씬 빠르고 쌀 수도 있음
  • “깊은 전문성”을 무시하고 해킹과 게으른 추상화를 쌓아 올린 편의성은, 현대의 수 MB짜리 프레임워크와 Electron까지 이어지는 퇴행이라고 봄
    물론 아무도 사용자의 컴퓨터/메모리 사용량, 저하된 경험, 낭비되는 대역폭, 80억 명에게 추가되는 에너지 비용과 환경 영향을 신경 쓰지 않음
    더 많은 사람이 공공 인프라를 만드는 것도 “분명히 좋은 일”인가? 그 결과가 더 나쁜 도로, 더 나쁜 다리, 실패하는 시스템이라면? 소프트웨어도 마찬가지고, 사실 대부분의 것들이 그렇다

• 이 글이 relevance를 잃고 있다고 한 “프론트엔드 기술”의 상당 부분은 직관적이지 않은 예외, 브라우저 비호환, 역사적 짐, 예외의 예외의 예외로 가득한 지뢰밭을 헤쳐 나가는 일이었음
  현대 프론트엔드, 즉 “새는 추상화의 탑”은 마침내 웹 개발을 위한 상식적인 정신 모델에 가까움. 웹 표준과 관례라는 괴상함의 폭발물 위에 억지로 덧씌워진 것인데, 그래도 작동하고 약간만 새는 수준이라는 것 자체가 성취임

  • “웹 개발을 위한 상식적인 정신 모델”이라는 말은 앞뒤가 맞지 않음. 지뢰밭 같은 예외의 세계이거나 상식적인 모델이거나 둘 중 하나지 둘 다일 수는 없음
    여전히 우리는 예외의 지뢰밭에 있고, 프론트엔드를 만드는 기술이 깨끗하고 예측 가능하며 역사적 짐에서 자유로운 상태가 됐다고 보기는 어려움
    우리가 한 건 기초의 실수와 비호환 위에 회반죽을 바른 것뿐이고, 해결한 건 아님. React는 HTML이 UI 도구상자로 설계되지 않았다는 사실을 해결하지 못함. Next.js는 JavaScript가 안전하고 제정신인 합리적 언어가 되지 못하게 하는 설계 실수로 가득하다는 사실을 해결하지 못함. Tailwind는 스타일링을 위해 설계되지 않은 마크업을 꾸미려고 CSS가 주먹구구로 도입된 문제를 해결하지 못함
    지금 LLM이 하는 일은 회반죽 아래의 공포를 통계 모델 안에 “알고” 있는 것뿐임. 그 모델은 이전 회반죽 층의 균열을 다시 메우는 예제가 99%인 시대의 사례들로 학습됐음
  • 전문가는 아니지만 대중이 보는 프론트엔드를 배포해보면, 프론트엔드는 오즈의 마법사에 나오는 노란 벽돌길 같음
    작고 괜찮은 모범 사례 집합에서 벗어나지 않으면, 지루하고 검증된 라이브러리 몇 개만으로도 꽤 좋은 경험을 제공할 수 있음
    하지만 오늘의 유행 프론트엔드 프레임워크, 혹은 더 나쁘게는 어제의 유행 프레임워크와 엮이거나, 특정 방식만 고집하는 다른 개발자의 기묘한 선호와 맞춰야 하거나, 희망과 덕트테이프로 붙인 “천재적” 해킹을 다루기 시작하면 복잡도와 상호작용 방식이 기하급수적으로 증가함
  • 원문은 존재한 적 없는 황금기를 잃었다고 아쉬워하는 셈임
    그 시절을 겪었음. IE6 전용 순수 JavaScript는 버그 많은 jQuery로 대체됐고, 그다음엔 유지보수 불가능한 Angular 단일 페이지 앱으로, 또 그다음엔 괴물 같은 React 코드베이스로 바뀌었음
  • 무지를 드러내는 말로 보임
    실제로는 그것보다 훨씬 더 많음
    Next.js 전문가라고 면접에 온 사람들을 너무 많이 봤는데, 그 밖의 것은 아무것도 못 하는 경우가 많았음. 그건 기술이 아니라 지식일 뿐이고, 지금은 무료로 널려 있음
  • 그 새는 추상화가 어느 탑, 어느 층, 어느 방에 있는지 이해하는 능력은 여전히 매우 가치 있고 LLM이 보지 못할 수도 있음
    어떤 것이 위원회가 처음부터 완벽히 설계하지 않았다고 해서, 모든 걸 잊고 책을 덮은 뒤 기계가 계산하게 둬도 된다는 뜻은 아님
    나도 후자를 하고 있어서 무엇을 틀리는지 알고 있지만, 그렇다고 유지보수 불가능한 난장판을 만들 정도로 속지는 않음. 에이전트들이 탈선할 때마다 내 프론트엔드 기술이 정말 유용하게 쓰임

• “프론트엔드는 의미 있는 HTML, CSS, 브라우저 차이, 접근성, 점진적 향상, 네트워크 성능, 인터페이스 설계, 사용자 테스트 등을 알아야 하는 고도로 전문화된 기술이었다”는 말은 이전 세대의 프론트엔드 개발자, 즉 C/C++ 개발자에게 꽤 웃기게 들릴 것임
  웹은 진입장벽을 크게 낮추고 기술을 탈숙련화한 것으로 여겨졌음. 어셈블리 프로그래머들도 C/C++ 개발자에 대해 비슷하게 생각했을 것임

  • 모든 계층은 자신들이 가장 중요하고, 가장 전문화됐고, 가장 숙련된 계층이라고 생각함
    하지만 모든 계층은 틀렸음. 각 계층은 아래 계층의 추상화 위에 세워져 있기 때문임. 물리와 수학까지 내려가 보면 집합론자들조차 어떤 공리를 가정한다는 걸 알 수 있음. 논리학자들이 뭘 하는지는 아무도 모름
  • 그 인용문은 글에서 나온 게 아니고 글과도 관계가 없는데, 대체 무슨 일인지 모르겠음

• “새 프로세스가 더 낮은 품질의 결과를 만들고, 많은 사람이 신경 쓰지 않는 것 같아 슬프다”는 식의 논리는 AI 이전에는 이 작업 대부분을 숙련된 장인이 품질에 헌신하며 했다는 전제에 기대는 듯함
  업계에서 실제로 일해봤고 솔직한 사람이라면 알겠지만, 현실은 그렇지 않았음. 평범함 이하가 많았음
  또 “품질”을 어떻게 정의하느냐에 따라 AI 결과물이 더 낮은 품질인지도 확신하기 어렵다. AI는 불편한 획일성을 만들 수 있지만, 동시에 모델이 학습한 관례들이 좋든 싫든 대다수 최종 사용자에게 “작동”하기 때문에 꽤 쓸 만한 결과물도 많음

  • 이건 “벽에 벽돌 하나 더 얹기”에 가까움
    이미 요구사항을 충족하는 최소한만 하고 성공이라고 선언하라는 압박이 많았음. 이제 그 압박이 감당 불가능해진 느낌임
  • AI 이전에는 숙련된 장인이 품질에 헌신했다는 전제에 대해, 커리어 중 몇 번은 운 좋게 그런 시기를 겪은 사람들도 있음
    다만 그건 AI 이전에 이미 사라졌다는 데 동의함
  • 품질 기준이 끔찍하게 낮아 보임
  • 맞음. jQuery와 Bootstrap 이전의 웹은 엉망이었고 코딩하기도 즐겁지 않았음
    낮은 품질을 말하자면 그때가 오히려 일반적이었음

• 최근 나도 비슷한 생각을 했음
  최소 10년은 프론트엔드 개발을 거의 하지 않았지만, 2000년대 후반에 갑자기 모두가 웹 GUI를 손으로 만들지 않고 프레임워크를 쓰기 시작하고, 여전히 HTML/CSS/JS와 데이터베이스 쿼리를 손으로 작성하는 사람은 조롱받던 시절을 기억할 만큼은 나이가 들었음. 채용 공고도 갑자기 PHP/HTML/CSS/SQL/JS 대신 Ruby on Rails, Django, Spring, GWT, 나중에는 Angular 기술을 요구하기 시작했음
  지금과 이상하게 익숙한 느낌임. 깊은 지식이 없어도 몇 분 안에 동작하는 웹 애플리케이션을 만들 수 있었고, 마법 같았음. 이후에는 문서를 대충 훑고 검색하면서 프레임워크 안에서 커스터마이즈하다가, 어느 순간 더 이상 못 하게 됨. 내부가 어떻게 돌아가는지 전혀 모르기 때문임. 바이브 코딩 웹앱처럼, 오후에 이어 붙인 표준 프레임워크 웹앱은 멀리서도 알아볼 수 있었지만 관리자들에게는 크게 인상적이었음
  재미있는 건 개발자들이 자신이 주로 쓰는 최전선 모델을 15~20년 전 GUI 개발자들이 좋아하는 웹 프레임워크를 말하던 방식과 비슷하게 이야기한다는 점임. 도구를 의인화하고 심지어 동일시하며, 버전 X에서는 되던 것이 X.1에서 나빠졌다고 좌절하고, “이제 10배 빠르게 개발한다”, “다시 XYZ를 손으로 쓰겠다” 같은 말들이 반복됨

  • 반대로 이후의 프레임워크 사용은 표준화를 위한 좋은 시도이기도 했음
    아무도 다룰 줄 모르는 자체 제작 GUI가 장점인 것도 아님
    개인적으로는 Nuxt/Next처럼 너무 크게 “느껴지는” 것은 거부하지만 Vue는 좋아함. 다만 지금은 JavaScript를 대부분 없애고 싶어서 서버 사이드 템플릿과 함께 HTMX나 Alpine 계열 해법으로 가려 함
    개인적으로는 쓰는 기술이 적을수록 좋음. 예전에는 커스텀 코드 한 줄 추가하기 전부터 웹앱 안에 온갖 쓸데없는 것들이 들어가던 시절도 있었음
  • 이미 2000년대 초반에도 웹 개발자들은 모든 걸 손으로 코딩하는 데 지쳐 있었고, 프레임워크나 CMS 같은 자동화를 찾고 있었음
    2004년에도 디렉터리 트리에 txt를 넣고 PHP가 줄바꿈 대신 태그를 붙여 HTML에 삽입하는 식의 기본 접근으로 사이트를 만든 적이 있음. 당시 대안은 무거운 콘텐츠 관리 시스템이었음
    직장에서 리드 개발자들이 만든 끔찍한 PHP 프레임워크 두 개를 거친 뒤 Django로 왔기 때문에, Django 같은 프레임워크는 더 점진적인 전환이었고 훨씬 즐거웠음
    물론 더 밀어붙여 객체에 버전 관리를 추가하는 식으로 가면 매우 까다로워지고 작동도 보장되지 않으며 고칠 방법도 없어졌음
    그래도 태도 자체는 지금과 비슷해 보임

• 우리는 소프트웨어 업계에 있음. 이 업계의 핵심은 매우 반복적인 일을 자동화하는 것임
  프론트엔드 프로젝트는 매우 반복적이고, 이제 AI가 그걸 대신 해줌. 훌륭한 일이고, 더 흥미로운 것을 만들 시간을 많이 풀어줌
  더 이상 그리 관련 없는 기술이 탈숙련화되는 건 컴퓨터가 발명된 이후 업계에서 계속된 일임. 문제를 AI든 다른 방식이든 해결했기 때문임
  넘어가서 새 기술을 배우면 됨. 실제로 AI를 효과적으로 쓰는 것도 일부 사람이 어려워하는 기술임. 여전히 물건이 저절로 만들어지지는 않음. 올바르게 프롬프트를 주면 해낼 수 있지만, 제대로 프롬프트하고 있는가? 도구가 요청한 대로 하고 있는가? 그걸 어떻게 아는가? 확인했는가? 나도 AI에 프롬프트하는 데 엄청난 시간을 쓰고 있고, 분명 나아지고 있지만 아직도 풀타임 업무에 가까움
  10년쯤 뒤에는 이 방식이 소프트웨어를 만드는 매우 비효율적인 방식이었다고 돌아볼 것임. 도구는 더 좋아지고 AI는 더 자율적이 될 것임. 하루 종일 같은 프롬프트를 반복하는 일에 시간을 쓴다면, 누군가 또는 무언가가 그것도 자동화해야 함

  • 소프트웨어의 목적은 인간의 의지를 기계가 소통할 수 있는 상태로 인코딩하는 것임
    여기서의 불만은 그 자동화가 원하지 않은 것을 인코딩할 위험이 있다는 데 있음
  • 프론트엔드를 포기하는 대신, AI가 만든 새 효율성은 프론트엔드와 백엔드를 더 밀어붙일 자원을 풀어줘야 함
    세상에는 지금 만들 수 있는 것보다 훨씬 더 많은 소프트웨어가 필요함
  • “프론트엔드 프로젝트는 매우 반복적”이라는 말은 도대체 무슨 뜻인지 모르겠음
    어디서부터 반박해야 할지도 모를 정도로 형편없는 견해임. 모든 UI에 버튼이 들어간다는 점이 반복적이라는 건가?
    사람들이 정말 이렇게 믿는다면, UX가 90년대부터 왜 망가졌고 이후 더 나빠졌는지 이해가 감
  • 만들 “흥미로운 것”이 그렇게 많지 않다는 걸 알면 놀랄 수도 있음

• AI 코딩은 제품 프로토타입을 만드는 데 큰 도움이 되지만, 동시에 멀리서 봐도 AI가 만든 티가 나는 제품을 낳기도 함
  방금도 어떤 스타트업이 앱을 시연했는데, 앱에 딱 바이브 코딩 UI 느낌이 있었음
  그들이 받은 피드백은 차가웠지만 정확했음. “꽤 괜찮긴 한데, AI로 만든 게 너무 보이고, 그렇다면 이걸 원하는 다른 사람도 AI로 아주 빨리 만들 수 있으니 팔려는 것에 별 가치가 없다”는 내용이었음

  • 이런 일이 더 많아졌으면 함. LLM이 만든 UI도, 그걸 충분하다고 여기는 사람들도 견디기 힘듦
  • 재미있는 건 기본적인 디자인 시스템과 CSS만 설정해도 AI가 생성한 프론트엔드 코드가 꽤 자연스럽게 맞아 들어간다는 점임
    하지만 대부분은 그 정도의 기본적인 신경도 쓰지 않음
    둥근 모서리는 여전히 끝없는 유행이고, 이미 잘 정의되지 않은 것은 전부 그 모양에 감염되는 듯함
  • 실제로 있었던 일이라기보다 머릿속 판타지처럼 들림
    유능한 벤처투자자는 이런 무의미한 피드백을 하지 않음. 좋으면 좋은 거지, AI가 만들었는지가 무슨 상관인가? 같은 품질의 제품인데 바이브 코딩 티가 나지 않았다면 괜찮았다는 건가? AI에 이념적으로 반대하는 사람만 신경 쓸 문제임

• 가끔 2000년대 초반에 AJAX나 DOM 조작 없이 HTML로 복잡한 사용자 인터페이스를 만들던 기법이 피라미드 건축 기술처럼 사실상 사라졌다고 느낌
  젊은 풀스택 개발자들이 “탈숙련화”된 면이 있어서, 예컨대 폼 검증을 하려면 JavaScript가 필요하다고 생각하는 사람도 많음
  일단 AJAX를 쓰고 DOM을 조작하기 시작하면 비동기 통신의 복잡도가 React와 비슷한 규모의 무언가로 이어질 수밖에 없음. document.title="A new title"처럼 쓸 수 있고 뭔가를 끌어오지 않아도 된다고 해도, 프론트엔드를 “서버에서 데이터가 오면 UI를 갱신하는 것” 정도로만 봐도 복잡한 애플리케이션은 UI 여러 부분을 갱신해야 하고, 어느 순간 통신이나 상태 관리 버스 같은 것을 만들게 됨. 다르게 만들 수 있었냐면 물론 가능함
  React 생태계에 문제가 있다면, 다른 추상화가 올라가는 추상화를 만든다는 점이 아니라 그 추상화가 샌다는 점임. 아주 단순한 것을 만들고 생김새를 신경 쓰지 않는다면 CSS를 이해하지 않고도 Bootstrap이나 MUI를 쓸 수 있음. 하지만 고객 앞에 내놓을 전문가 수준 작업을 하려면 HTML, CSS, JS와 프로젝트에서 쓰는 모든 프레임워크를 이해해야 함

  • 특히 HN에서는 React가 인터랙티브 웹 전반에 대한 더 넓은 불만을 대신하는 네 글자 욕처럼 쓰인다고 자주 느낌
    React를 비판하는 사람 대부분은 React가 어떤 문제를 해결하는지 실제로 이해하지 못함. 충분히 복잡한 웹앱인데 React에 의존하지 않는 소스 코드를 보여주면, 그 안에서 직접 만든 React 유사물을 찾아낼 수 있음

• NextJS의 서버 사이드 렌더링, 지연 로딩 등을 쓰는 프론트엔드 애플리케이션 운영이 HTML, JS, CSS만 쓰던 시절보다 “쉽다”는 데 동의하지 않음
  복잡도의 수준과 사용자 기대치는 완전히 다른 곳에 있음
  게다가 숙련된 엔지니어는 1000배쯤 많아졌고, 전 세계 시장과 경쟁해야 함. 2000년대 초반에는 경쟁이 거의 없었음. 노동자의 기술은 시장이 요구하는 수준과 대체로 느슨하게 상관관계를 가지는데, 지금은 극도로 경쟁적임