[글] 프론트엔드 개발의 종말

요즘IT에서 찾아본 좋은 글.

스크랩하고 싶은 구절을 원문과 함께 인용하겠다.

프론트엔드 개발의 종말 | 요즘IT

In a way, web developers have been made obsolete! These days, if a local bakery or a dentist or an artist needs a website, they're probably not hiring a developer and paying them tens of thousands of dollars to build something from scratch. They'll hop onto SquareSpace, find a template they like, and spend $20/month.
And yet, web developers continue to exsit.

어떤 의미에서 웹 개발자는 이미 쓸모없는 존재가 되었습니다! 요즘에는 동네 빵집이나 치과를 운영하는 사장님, 혹은 예술가들이 굳이 수천만 원을 지출하며 개발자를 고용해서 웹사이트를 만들지 않습니다. 이들은 스퀘어스페이스 같은 곳에 접속하여 마음에 드는 템플릿을 찾은 후 월20달러 (한화 약 2만 6천원) 정도를 지출하는 선택을 하겠죠.
그런데도 웹 개발자 직군은 지금도 계속 존재합니다.

* be made obsolete : 쓸모 없어지다.

But let's be clear: we haven't needed web developers to build these sorts of pages in decades. There is an enormous difference between this HTML document and the sorts of code front-end developers write today.

(ChatGPT가 명세서만으로 제작한 간단한 웹사이트)
지난 수십년을 돌아봐도 이 수준의 페이지를 제작하는 데 굳이 웹 개발자가 필요하지 않았습니다. 이러한 HTML 기반의 문서와 현대의 프론트엔드 개발자가 작성하는 코드 사이에는 엄청난 차이가 있습니다.

I'm far from an expert when it comes to LLMs like GPT-4, but I do understand how they work at a high level. Fundamentally, LLMs are super-powerful text predictors. Given a prompt, they use machine learning to try and come up with the most likely set of characters that follow the prompt. Companies like OpenAI spend a ton of time and energy tweaking the models to improve the output. An army of human labelers “grade” the model's output, and the model learns and evolves.

저는 GPT-4와 같은 LLM 분야의 전문가는 아니지만, LLM이 고수준에서 작동하는 원리는 이해하고 있습니다. 기본적으로 LLM은 매우 강력한 텍스트 예측 도구입니다. 프롬프트가 주어지면 머신러닝을 사용하여 프롬프트 다음에 나올 가능성이 가장 높은 문자 집합을 찾아냅니다. OpenAI와 같은 회사들은 결과물을 개선하기 위해 모델을 조정하는 데 엄청나게 많은 시간과 에너지를 소비합니다. 인간 *라벨러 군단이 모델이 출력한 결과물에 '등급'을 매기면 모델은 이를 학습하고 진화합니다.

* Labelling : 인공지능이 학습할 수 있는 형태로 데이터를 가공하는 작업을 의미. 

Sometimes, parts of that response are nonsensical. The OpenAI team refers to these as “hallucinations”.

LLM은 때때로 말도 안 되는 응답을 하는 경우도 있습니다. OpenAI팀은 이를 '환각(hallucinations)'이라고 부릅니다.

Augmenting, not replacing

대체가 아니라 보완일 겁니다.

* augment : 늘리다, 증원하다

Code snippets are all over the internet, and are often generic. By contrast, every codebase is unique. There are very few large open-source codebases. How's the AI supposed to learn how to build big real-world projects?

AI가 비교적 우수한 성능을 보이는 코드 조각(snippet)들은 인터넷에서 쉽게 찾아볼 수 있고, 제너럴한 경우가 많기 때문에 상대적으로 학습하기 용이합니다. 반면에 모든 코드베이스는 각자가 고유하며, 특히 대규모 오픈소스 코드베이스는 거의 없습니다. 그 말인즉 AI가 대규모 프로젝트를 학습할 데이터를 확보하기 어렵다는 얘기이며, AI만으로 대규모 프로젝트를 구축하는 것은 비현실적이라는 말과 같습니다.

Front-end vs. other engineering disciplines
Some folks online have been suggesting that front-end development is particularly susceptible to AI replacement, and suggesting that developers move up the stack, to focus on back-end or data engineering. This seems completely backwards to me. (..) but if there's any vulnerability here, I think it's on the back-end.

프론트엔드 vs 다른 엔지니어링 분야
온라인에서 일부 사람들은 프론트엔드가 특히 AI에게 위협받을 것이기 때문에 개발자들이 백엔드 또는 데이터 엔지니어링으로 전환해야 한다고 말합니다.
저는 정반대라고 생각합니다. (..) 만약 취약한 분야가 있다면 백엔드일 것입니다.

This is an over-generalization, but over the past 10ish years, a lot of complexity has been moving from the server to the client. Monolithic Express applications have been turning into collections of serverless functions, while our front-ends have evolved from hyper-linked digital documents to full-blown desktop-quality applications.

지나친 일반화이긴 하지만, 지난 10여년 동안 많은 복잡한 엔지니어링 기법들이 서버에서 클라이언트로 이동해 왔습니다. 모놀리식 익스프레스 애플리케이션은 서버리스 기능 모음으로 바뀌었고, 프론트엔드는 하이퍼링크된 디지털 문서에서 본격적인 데스크톱급 애플리케이션으로 진화했습니다.

Also, the front-end is the part of the product that users interact with. Companies generally want their product to be bespoke, unique, carefully crafted according to their brand. By contrast, the back-end is invisible. A generic back-end is way more acceptable than a generic front-end.

또 명심해야 할 것은 기업들이 자사 브랜드에 맞게 독특하고 세심하게 제작된 맞춤형 제품을 원한다는 겁니다. 프론트엔드는 제품이 직접 사용자와 상호작용하는 부분이기 때문에 기업들은 프론트엔드에 더 신경을 쓰죠. 반면 백엔드는 눈에 보이지 않기 때문에 보다 제너럴하게 개발되어도 괜찮은 편입니다.

A depressingly-large number of folks in our industry feel like back-end development is harder or more complex than front-end development, that the “real” engineering happens on the server. This is, of course, nonsense.

업계에서 우울할 정도로 많은 사람들이 백엔드 개발이 프론트엔드 개발보다 더 어렵거나 복잡하다고 생각하며, '진짜' 엔지니어링은 서버에서 이루어진다고 생각합니다. 이건 말도 안 되는 이야기입니다.

* susceptible : 민감한, ~을 허용하다

* daylight between : (어떤 것 사이에) 큰 차이가 있다

* bespoke : 맞춤생산된 (tailor-made)

 

 

백엔드 요구사항을 "제너릭하다"라고 볼 수도 있다는 관점이 신선한 기사였다.

'개발자가 사라질지도 모른다'는 불안감에 대해서는, <클린코드> 서문의 내용을 인용하고 싶다.

p.2
코드가 사라질 일은 없다.
코드는 요구사항을 상세히 표현하는 수단이니까.
기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍.

앞으로 프로그래밍 언어에서 추상화 수준이 높아질 것.
특정 응용 분야에 적합한 프로그래밍 언어 domain-specific language 도 점차 많아질 것.
바람직한 현상이지만 그렇다고 코드가 사라지진 않을 것.

p.3
언젠가 코드가 사라지리라 생각하는 사람들은 언젠가 비정형적인 수학이 나오리라 기대하는 수학자와 비슷하다.
요구사항을 모호하게 줘도 우리 의도를 정확히 꿰뚫어 프로그램을 완벽하게 실행하는 그런 기계 말이다.
그건 불가능하다.

 

* 비정형 명세기법 : 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 방법.

장점 - 요구사항을 명세하는 데 특별한 기술이 필요치 않아 작성하기 쉽다. 사용자와 분석가 간에 의사 전달이 용이하다.

단점 - 자연어를 사용함으로써 표현이 애매모호할 수 있고, 그에 따라 달리 해석할 수도 있다는 점. 일관성이 떨어지고, 명세가 불충분할 수 있다.

 

 

요구 명세 기법