팀 회의에서 이렇게 물어보자. "우리 팀에서 AI를 제일 잘 쓰는 사람이 누구야?"
아마 잠깐 정적이 흐를 것이다. 누군가는 툴을 제일 많이 쓰는 사람을 떠올리고, 누군가는 프롬프트를 잘 다루는 사람을 떠올리고, 누군가는 최근에 AI로 뭔가 그럴듯한 걸 만들어온 사람을 떠올린다. 그런데 그 어느 답도 확신이 안 선다. 뭔가 아니라는 직감은 있는데, 그럼 뭘 보고 판단해야 하는지는 아무도 모른다.
지금 거의 모든 기업이 이 벽 앞에 서 있다. AI 역량이 채용과 평가의 핵심 항목으로 올라오고 있는데, 정작 그걸 잴 잣대가 없다. 이 글은 그 잣대를 제안하는 글이다. 결론부터 말하면, ABCD2라는 다섯 축이다. 하지만 그 전에, 질문 자체를 먼저 고쳐야 한다.
나는 앞으로 개발자라는 직군이 근본적으로 다른 무언가로 바뀔 거라고 보고 있다. 단순히 도구가 바뀌거나 생산성이 올라가는 수준의 변화가 아니다. 직업의 정체성 자체가 다른 곳으로 이동한다. 한 단어로 정의하자면, 개발자는 파이프라이너(Pipeliner)가 된다.
이 이야기를 하려면 개발자가 지금까지 정확히 무엇을 하는 사람이었는지부터 짚어야 한다. 우리는 개발자를 '만드는 사람'이라고 부르지만, 실제로 개발자가 한 일의 본질은 번역이었다. 누군가가 정의한 스펙 — 기획서, 요구사항, 티켓, 회의에서 오간 말 — 을 받아서 그것을 기계가 실행할 수 있는 형태로 옮기는 일. 개발자는 인간의 의도와 기계의 실행 사이에 서 있는 인터프리터(interpretor)였다.
그런데 이 번역은 기계적인 번역이 아니었다. 스펙은 언제나 불완전하고, 모순되고, 빈칸투성이였다. 그 빈칸을 판단으로 메우고, 엣지 케이스를 상상하고, 명시되지 않은 것을 추론해서 동작하는 시스템으로 만들어내는 것 — 이건 단순 노동이 아니라 지적인 노동이었다. 그래서 나는 개발자를 좀 더 정확히 지능 수행자(intelligent executor)라고 부른다. 지능을 써서 실행하는 사람. 이게 지난 수십 년간 개발자를 개발자로 만들어준 핵심이었다.
On December 3, 2025, a security vulnerability shook the React ecosystem. CVE-2025-55182, dubbed "React2Shell," received a perfect CVSS score of 10.0. This wasn't just another bug—it revealed a fundamental structural problem facing modern web development.
This article explores why React2Shell happened and how it relates to the absence of web standards for partial rendering.
| Docker 를 공부하면서 기억해둘만한 것들을 메모해둔다. | |
| 1. Container와 Image 개념이 핵심. 찾아보면 많이 나온다 | |
| - 좀 쉽게 생각하면, Image는 설치된 프로그램, Container 는 실행한 프로그램 정도의 개념으로 생각하면 된다. | |
| - docker는 격리된 환경이니 처음 공부할때 Image든 Container든 맘대로 올렸다 지웠다 하면서 연습해보면 된다. 쫄지 말자. |
Firstly, Create React App is good. But it's a very rigid CLI, primarily designed for projects that require very little to no configuration. This makes it great for beginners and simple projects but unfortunately, this means that it's pretty non-extensible. Despite the involvement from big names and a ton of great devs, it has left me wanting a much better developer experience with a lot more polish when it comes to hot reloading, babel configuration, webpack configuration, etc. It's definitely simple and good, but not amazing.
Now, compare that experience to Next.js which for starters has a much larger team behind it provided by a world-class company (Vercel) who are all financially dedicated to making it the best DX you could imagine to build any React application. Next.js is the 💣-diggity. It has amazing docs, great support, can grow with your requirements into SSR or static site generation, etc.
HTML5 기반의 웹 어플리케이션 사용 사례가 늘어나면서, 자연스럽게 SPA 기술에 대한 관심도 늘어나고 있습니다. SPA의 시초는 Angular 였지만, 지금은 React와 Vue가 시장을 양분하고 있습니다. React를 대체하고자 하는 경쟁 라이브러리들이 하나 둘씩 등장하고 있긴 하지만, 아직 React는 왕좌의 자리에서 내려올 생각이 없어 보입니다.
저는 React 기반의 app을 개발하는 사람입니다. 그런데 어느날, React가 무엇인지 제대로 이해하고 있는 사람은 생각보다 많지 않다는 것을 깨닫게 되었습니다. 제 주변에도 React 를 한다는 사람이 여럿 있었지만 리액트가 정확히 어떤 기술인지에 대해서 물어보면, 대부분 "UI Framework" "jquery 다음 세대" 이런 추상적인 얘기만 하면서 얼버무리기만 할 뿐이었습니다.
그래서 저는 잠깐 시간을 내어서, React 가 무엇인지 소개를 하고자 합니다. 글은 길지 않습니다. 하지만 이 글을 읽고나면 당신은 React가 무엇인지 명확하게 알게 될 것입니다.
자 그럼 시작해보겠습니다.
keyword: material ui, mui, typescript, intellisense, vscode
When using mui with typescript, there is performance issue with vscode intellisense, because of type checking.
I've read the comments and found a clue that some csstypes given by mui might be source of issue.
| /** | |
| * addLessLoader_forCRA5 | |
| * customized addLessLoader of customize-cra for create-react-app@5.0.0 | |
| * | |
| * CreatedAt : 2022-01-09 | |
| * | |
| * Description: The customize-cra author copy getStyleLoaders codes from react-scripts@4.0.3 > webpack.config.js | |
| * But as react-scripts upgrade to version 5, they also upgrade postcss-loader, which causes change of options schema. | |
| * So, I re-copy getStyleLoaders codes from react-scripts@5.0.0 > webpack.config.js | |
| * |