[GN⁺] AI는 기존 기술 역량에 곱셈 효과를 준다

9bow · 5월 28, 2026, 6:30오전

AI는 기존 기술 역량에 곱셈 효과를 준다 글 소개

AI 모델 은 많은 프로그래밍 작업에서 충분히 쓸 만하지만, 개발자를 대체하기보다 기존 기술 역량을 증폭하는 도구에 가까움
LLM이 모든 규모의 프로젝트를 완전히 설계하고 구축해 인간 개발자가 곧 필요 없어질 것이라는 증거는 보이지 않음
Matt Perry는 Motion 작업에서 Q1 목표 60개 이슈를 넘어 160개 를 닫고, Q2용 대규모 리팩터링도 1월 어느 오후에 끝냄
개발 경험이 적은 사용자의 vibe-coding 은 MVP 이후 막히기 쉬우며, 아키텍처 판단과 도메인 지식이 결과 차이를 만듦
AI는 Iron Man의 슈트처럼 강력하지만 스스로 같은 성과를 내지는 않으며, 구조화된 학습 과 숙련도가 활용 효과를 좌우함

Josh W. Comeau는 이메일 뉴스레터 "The elephant in the room" 에서 "AI 모델은 다양한 프로그래밍 작업을 충격적일 정도로 잘 해낸다" 는 점을 인정하면서도, AI가 개발자를 대체하기보다 기존 기술 역량 위에 곱셈으로 작용 한다는 관점을 제시합니다. 약 20년간 웹 애니메이션을 다뤄온 그의 경험과 동료 개발자들의 사례를 바탕으로, AI 도구의 효과가 사용자에 따라 왜 그렇게 갈리는지를 설명합니다.

Matt Perry의 생산성 사례

Matt Perry는 Popmotion, Motion One, Motion(구 Framer Motion) 등 여러 애니메이션 라이브러리를 만든 개발자임
Motion의 레이아웃 프로젝션 엔진 은 Josh Comeau가 "지금까지 본 것 중 가장 정교한 엔지니어링 중 하나" 라고 평한 결과물임
Matt Perry는 자신의 뉴스레터에서 2026년 AI 활용을 강화했다고 밝히며, Q1 목표였던 이슈 60개 종료를 넘어 160개 를 종료했다고 전함
Q2에 하려던 Motion의 대규모 리팩터링도 1월 어느 오후 한 번에 끝냄
LLM 자체가 최고의 인간 개발자보다 뛰어나다기보다, 숙련된 개발자가 AI를 사용할 때 생산성이 크게 증폭될 수 있음을 보여주는 사례임

도메인 지식이 부족한 vibe-coding의 한계

/r/vibecoding 에는 개발 경험이 거의 없거나 적은 사람들이 vibe-coding 경험을 공유하며, MVP 이후 단계에서 막히는 경우가 많음
Josh Comeau가 인용한 한 Reddit 글의 작성자는 코드를 보지 않고 MVP 3개를 성공적으로 만들었지만, 어느 시점에 벽에 부딪혀 "3시간 동안 유령과 말다툼하듯이 프롬프트를 던지다가, 결국 파일을 직접 열어 30초 만에 한 줄을 고쳤다" 고 토로함
안내 없이 사용되는 LLM은 개별 프롬프트를 해결하는 코드 생성에 집중하고, 애플리케이션 아키텍처를 전체적으로 보지 못해 막다른 길로 들어가기 쉬움
숙련된 개발자는 AI로 할 수 있는 일을 증폭하지만, 도메인 지식이 부족한 사용자는 "MVP" 단계를 넘어서기 어려워짐
같은 AI 도구를 쓰더라도 결과는 같지 않으며, 사용자의 판단력과 구조적 이해가 핵심 차이를 만듦

AI를 도구로 보는 사고방식

AI는 도구 이며, 도구는 능숙하게 다뤄야 효과가 남
Jimi Hendrix의 기타, Gordon Ramsey의 주방, Serena Williams의 테니스 라켓을 갖는다고 같은 결과를 낼 수는 없음
사람들은 도구의 중요성을 과대평가하는 경향이 있으며, 마케팅은 Michael Jordan의 "air technology" 운동화가 덩크 능력을 줄 것처럼 이런 편향을 활용함
AI 에이전트는 의인화되어 도구로 보기 더 어렵고, 자율 로봇처럼 대하면 실제보다 더 큰 공로를 부여하게 됨
Josh Comeau가 제시하는 더 적절한 비유는 Iron Man의 슈트 임: 놀라운 일을 가능하게 하지만, 스스로 작동해 같은 성과를 내는 존재는 아님
Matt Perry가 Motion 저장소 접근권과 LLM 도구를 넘겨줘도, 같은 속도로 움직이려 하면 같은 결과가 아니라 큰 혼란을 만들 가능성이 큼
숙련된 개발자가 LLM으로 해낸 일을 볼 때 핵심 요인은 LLM 자체보다 숙련된 개발자의 역량 임. 결과적으로 AI는 "기존 기술 역량에 대한 곱셈 효과" 를 갖는다는 것이 글의 핵심 주장임

Whimsical Animations와 구조화된 학습

Josh Comeau가 새로 출시한 웹 애니메이션 강좌는 Whimsical Animations 임
약 20년 동안 웹사이트와 웹 애플리케이션을 만들며 기억에 남고 영향력 있는 애니메이션과 인터랙션을 만드는 방법을 축적해 옴
웹 개발자를 대상으로 한 애니메이션 자료는 많지 않아, 게임 개발 분야의 개념을 웹에 맞게 적용해 왔다고 밝힘
선형 보간(linear interpolation), simplex noise, delta time 같은 개념은 일반적인 웹 개발자 기술 범위에 잘 포함되지 않지만, 프로젝트를 돋보이게 만들 수 있음
ChatGPT 같은 도구로 새 주제를 배우기는 쉬워졌지만, 효과적으로 배우려면 무엇을 질문해야 하는지 알아야 한다는 점이 강조됨
강좌는 다양한 기법을 소개하는 큐레이션된 커리큘럼을 제공함
커스텀 강좌 플랫폼이 업데이트되어 모든 연습문제와 코드 스니펫을 로컬에서 실행할 수 있게 됨
로컬 실행 지원으로 평소 사용하는 코딩 환경과 워크플로에서 챌린지를 완료할 수 있음

Hacker News 의견들

지난주에 UI 디자인을 바이브 코딩 하면서 옆 화면에는 컴포넌트 테스트를 띄워둔 채 Iron Man 같은 순간을 겪었음. 요소를 옮기고, 강조를 줄이고, 레이아웃 선택지를 탐색하라고 지시하면서 반복했는데, 거의 실시간 루프처럼 돌아가서 굉장했음. 생성된 코드는 끔찍했지만, 혼자서는 못 했을 디자인에 쉽게 수렴했고, 이후 그 참조 디자인을 보고 더 나은 코드로 직접 구현할 수 있었음
- 내가 전문가인 영역은 쓰레기처럼 보이고, 전문가가 아닌 영역은 괜찮아 보였던 게 우연이 아닐 수도 있음. 디자이너들은 반대로 "Claude Design Studio가 쓰레기 UI를 만들었지만, 내가 직접 고쳤고 대신 내가 못 짰을 훌륭한 코드를 만들어줬다" 고 말할 수 있음
- 며칠 전 Tailwind 스레드에서는 많은 프레임워크의 의도된 경험이 쓰기 전용 코드 라고 들었으니, 이게 받아들여야 할 미래일지도 모름. 어떻게 연결됐는지 걱정하지 말고, 작동하면 된 거고 멈추면 AI에게 고치라고 하면 된다는 식임. 해방감이 있긴 한데, 아직 이걸 받아들이는 AI 열반에 도달했는지는 모르겠고 그 순간이 가까운 것 같기는 함
- 이게 얼마나 지식의 관성 에 기대는 건지 궁금함. 지금은 기본 기술을 이해하고 직접 만들 수도 있지만, 어딘가에 정리 가능한 엉망 코드가 있다는 걸 알면서도 빠른 반복을 선택하는 단계임. 기업들이 충분히 오래 버티면 그 지식이 완전히 사라지고 도구만 남게 되며, 그때는 Iron Man이 아니라 iron lung에 가까워짐
- 이제 어떤 작업이 비싸고 어떤 작업이 싼지 다시 배워야 함. 프로토타입은 사실상 공짜에 가까워졌고, AI에게 아키텍처나 스타일 선택지를 각각 시도하게 한 뒤 어떤 코드가 더 마음에 드는지 보면 됨. 재작성과 재설계도 꽤 잘 먹히는 편이라, 여러 해법을 바이브 코딩으로 만든 뒤 접근법을 고르고 테스트를 보강하고 큰 리팩터링으로 유지보수 가능하게 만드는 패턴을 좋아함
- 내가 도달한 모델도 비슷함: 먼저 시스템 아키텍처가 어떻게 보여야 하는지에 대한 스킬 템플릿 을 만들고, LLM에게 그 지침을 따르라고 시킴. 100% 따르지는 않지만 충분히 괜찮은 결과가 나오고, 이후 생성물을 검토해 템플릿에 맞추며 마음에 드는 아이디어는 다시 스킬 템플릿에 추가함. 다만 지속적인 감독 이 필요하고, 건드리지 말라고 한 부분을 건드리거나 지시를 따르지 않을 때도 있으며, 출력량이 압도적일 수 있어 동료 검토는 여전히 필요함
AI 도구로 작업을 가속할수록, 유용한 소프트웨어를 출시하는 일이 실제로 얼마나 어려운 장인 기술 인지 더 실감함. Claude Code와 Codex가 대부분의 코드를 써줄 수는 있지만, 무엇을 어떻게 만들지 결정하는 데 필요한 기술 지식은 여전히 막대함. 지금 Claude Artifacts처럼 사용자 정의 HTML+JS 앱을 더 큰 애플리케이션 안의 iframe 샌드박스에서 안전하게 실행하는 시스템을 만들고 있는데, 이게 왜 유용하고 가능한지 이해하려면 샌드박싱, 보안 위협, 브라우저 보안 모델, 수십 년간 진화한 여러 플랫폼 기능에 대한 깊은 지식이 필요함. AI 때문에 경력을 그만두겠다고 말하는 개발자들을 보면 슬픈데, 기존의 깊은 기술 경험이 어느 때보다 가치 있어진 시점이기 때문임
- AI와 상호작용하는 경험 자체가 끔찍함. 코드를 쓰는 건 좋아하지만, 기계가 올바른 코드를 쓰게 하는 마법 주문을 찾거나, 틀렸을 때 고치는 일은 좋아하지 않음. 또 이 도구들이 만들어진 방식은 내 기준으로는 도둑질 이고, 비윤리적으로 만들어진 도구를 쓰는 것 자체도 비윤리적이라고 봄
- 이 관점은 신선하고 내 경험과도 맞음. 내가 쓰는 프롬프트는 전부 매우 기술적이고, 내 전문성 없이 에이전트와 대화만으로 처리하기는 어려움. 전문 영역 밖의 일을 할 때마다 사람들이 상상하는 만큼 빠르지 않고, 전문성 은 질서를 유지하는 데 큰 도움이 됨
- 하지만 고위 임원들은 그렇게 생각하지 않음. 그들이 AI가 엔지니어를 대체할 수 있다고 믿으면 그렇게 흘러갈 가능성이 크고, 품질이 무엇인지 임원들이 제대로 아는 경우도 드묾. 그들은 매출과 이익만 보니, 깊은 기술 경험이 더 가치 있다는 말은 맞아도 현실은 슬프게도 그렇게 안 될 수 있음
- 훌륭한 아이디어와 훌륭한 제품 사이에는 엄청난 장인정신 이 필요하다고 예전에 썼다가 많은 비추천을 받았음. LLM은 현실에서 이 사실을 바꾸지 못함. 그래서 고부가가치 제품이 폭발적으로 늘지 않은 것이고, 애초에 가치를 만드는 제품을 만드는 일은 매우, 매우 어려움
"AI 도구가 Iron Man 슈트에 가깝다" 는 말에 대해, GitHub 별 63,600개짜리 흥미로운 저장소가 있음. 개발자는 GitHub 주간 인기 기여자 1위지만, 애플리케이션은 설명된 것과 달라 보이고, 개발자들도 이게 진짜인지 명확히 답하지 못하는 듯함. 결국 지저분한 LLM 출력일 뿐이라는 점에서, 슈트만으로는 Iron Man이 될 수 없음 을 보여줌
- 세 AI 시스템인 Claude, Codex/GPT-5.2, Gemini의 교차 검증을 포함한 독립 코드 감사를 통해 이 프로젝트가 동작하지 않는 껍데기 라고 확인했다는 문구가 있음. AI가 만든 비동작 프로젝트를 AI가 비동작이라고 증명하는 셈이라, 참 멋진 신세계임
- ruvnet 전체가 좀 섬뜩함. 여러 프로젝트가 있는데 그냥 AI 출력이 아주 많고, GitHub 인프라를 범람시키는 느낌이라 GitHub가 왜 힘들어하는지 이해하기 쉬움
수학자로서 지난주에 나도 Iron Man 순간 을 겪었음. 몇 년간 교수인 친구 둘과 공동 수학 연구를 하고 있었고, 연구 일부를 ChatGPT로 탐색해봤음. 생각이 떠오르면 GPT에 제시하고, 증명하기 쉬운 정리를 쓰게 한 뒤 증명을 LaTeX로 만들게 했고, 증명은 항상 조심스럽게 확인했음. 중간에 특정 식의 상계를 잡지 못해 이해가 부족했던 부분은 종이와 연필로 직접 다시 유도하니 큰 도움이 됨. 전체 과정은 GPT 없이 할 때보다 약 10배 빨랐고, 몇 시간 뒤에는 올바른 증명 20쪽 정도와 관련 수치 시뮬레이션에 필요한 코드가 모두 생겼음
AI는 능력의 배수가 아니라 시간을 줄이는 도구 라고 봄. 경험이 적은 개발자에게는 프로젝트 초반부터 즉시 시간을 줄여주지만, 초기 결정이 나중에 발목을 잡을 가능성이 큼. 시니어 개발자에게는 설명만 충분히 해주면 즉시 능력 범위 안의 일을 처리하는 주니어 또는 중급 개발자처럼 작동함. 다만 중요한 결정을 맡기면 완전히 틀리거나 미묘하게 틀릴 수 있고, 특히 미묘한 오류는 발견하기 어려워 가장 위험함
- 꼭 그렇지만은 않음. 배우고자 하는 마음이 있다면 AI는 기술을 다듬고 익히는 데 걸리는 시간을 줄여주고, 그 결과 실제 능력 배수 가 될 수도 있음. 원래도 찾을 수 있던 정보지만 시간이 너무 오래 걸렸는데, 원하는 답에 도달하는 시간 규모가 크게 줄어 실제 산출물과 능력이 달라졌음
- 작은 Bash나 Python 유틸리티 스크립트를 번개처럼 뽑아주는 건 진짜 게임 체인저임. Raspberry Pi에서 작은 웹 서버를 돌리고 싶어서 Gemini에게 코드와 systemd 서비스로 실행하기 위한 설정용 Bash 스크립트를 써달라고 했음. 단독으로 보면 대단하지 않아도, 다른 책임들 때문에 에너지가 없어서 미뤄둔 홈 자동화 작업들을 이제 처리하게 됨
맞음. AI는 순수한 능력이나 재능을 구식으로 만드는 게 아니라 오히려 더 가치 있게 만듦. 깊은 기술 지식은 AI를 적용할 수 있는 접점이 많아지기 때문에 현실에서 더 큰 지렛대 효과 를 갖게 됨. 이 깨달음 때문에 AWS 같은 클라우드 서비스 대신 내 기술 SaaS를 호스팅할 홈랩 데이터센터를 직접 만들게 됨. 예전 같으면 RouterOS를 익혀 데이터센터급 Mikrotik 라우터를 설정하는 데 몇 시간이나 며칠이 걸렸겠지만, Claude 덕분에 20분짜리 작업이 됐고 라우팅 설정도 많이 배움
- 그렇게 확신하진 못하겠음. 전동 공구와 못총이 나왔을 때도 비슷하게 생각했을 것 같지만, 집은 훨씬 빨리 지을 수 있게 된 대신 임금은 내려가고 작업 품질은 떨어졌으며 숙련과 경험의 가치는 크게 줄었음. 평범한 석고보드 작업도 생산 요구는 올라가고 임금은 정체됐으며, 요즘은 이음매도 엉망인 경우가 많고 돈이 되는 건 생산 속도와 불평하지 않는 태도뿐임
"방 안의 코끼리" 는 모두가 말하지 않는 큰 주제를 뜻하는데, AI는 모두가 말하고 있음. 더 나은 제목은 "AI가 개발자 기술을 대체하는 대신 증폭하는 이유" 에 가까움
- 맥락상 이 글은 내 최신 강의를 위한 마케팅 캠페인의 뉴스레터 이슈였음. 그 시점까지 해당 마케팅 캠페인에서 AI를 다루지 않았다는 의미에서 "방 안의 코끼리" 였음. 이 링크는 이메일 클라이언트에서 제대로 표시되지 않을 때 읽으라고 만든 웹 보기 링크라, 더 넓은 독자를 의도한 글은 아님
- 결과는 결국 같음. 같은 일을 해내는 데 필요한 개발자 수가 줄면 많은 사람이 실직하게 됨. 주니어 급여와 AI 구독료로 "같은 결과" 를 얻을 수 있다고 생각한다면 왜 시니어 급여를 주겠음. 솔직히 다른 업계로 재교육 을 고민 중이고, 돈을 덜 벌더라도 이 난장판을 피하는 게 나을 수 있음
Josh의 견해에 대체로 동의하지만, AI와 일할 때 시니어와 주니어 경험을 이야기하는 글 상당수는 좀 헛소리 같음. 시니어가 AI 도구로 더 좋은 결과를 얻고 주니어가 더 고생한다는 건 맞지만, 달라진 건 그 차이가 증폭 됐다는 점뿐임. 다만 AI가 주는 즉각적인 만족감이 마찰을 겪는 과정을 약화시킬 수 있고, AI 네이티브는 마찰 을 이해하지 못하고 의문시할 가능성이 있음
- 주니어가 AI 연구 보조로 훨씬 빨리 배운다는 건 잘 보이지 않음. 대학 수준에서 보이는 상황을 보면 그렇게 기대하기도 어려움
- 핵심은 AI의 즉각적인 만족감이 마찰을 겪는 과정을 약화시킬 수 있다는 부분이라고 봄. 가장 중요한 배움은 질문하고 즉시 답을 받을 때가 아니라, 답을 찾으려고 애쓰고 몇 번 실패하고 깊이 생각하다가 잠깐 쉬고 나서 문제를 풀 때 생김. 그런 지식은 답뿐 아니라 앞으로 피할 수 있는 잘못된 경로와 자기 사고에 대한 신뢰까지 주기 때문에 값어치가 큼
- 읽는 것만으로 배우는 게 아니라 직접 해보면서 배움. 이 경우 LLM 출력만 읽는다고 해서 실질적으로 교육되지는 않음
- 오히려 가능한 한 게을러지게 해줌. AI 도구로 더 깊게 파고드는 사람은 본 적이 없음
- 실제로 AI는 주니어 개발자를 더 멍청하게 만든다고 봄. 시니어 개발자는 자신이 만든 수많은 실패한 프로젝트라는 산을 넘으며 배웠음. 내게 AI는 올바른 방향으로 시속 100마일로 가게 해주지만, 주니어들은 바다나 벽을 향해 시속 100마일로 달리는 모습을 봄. AWS가 우리를 더 멍청하게 만들어 역방향 프록시를 모르는 주니어가 생겼고, 고수준 언어가 메모리 관리를 이해하지 못하게 만들었듯 AI도 그 사슬의 다음 고리임. 10년 뒤에는 대부분의 개발자가 코드를 읽지 못할 것 같음
많은, 어쩌면 대부분의 소프트웨어 엔지니어는 자기 코드베이스의 전문가이기 때문에 상당수 엔지니어가 AI에서 높은 가치를 얻고 있음. 불분명한 건 엔지니어당 더 많은 코드를 쓸 수 있게 되면 개발자가 줄어드는지, 아니면 UX, 테스트, 개발자 경험, 문서처럼 전통적으로 밀리던 영역에 더 많은 소프트웨어 가 생기는지임. 어쩌면 기준선이 올라갈 뿐일 수도 있음
Claude와 이야기하다가 이런 점을 봤음. 내가 "X가 Y보다 낫다는 게 놀랍지 않냐" 고 말했더니 Claude는 "통찰력 있는 비판" 이라며 Y가 X보다 낫다는 이유를 잘 정리해 답했음. 답 자체는 좋고 사려 깊고 논리적이었지만, 내가 말하려던 것과 반대라서 "아니, 내가 말한 건 X가 Y보다 낫다는 반직관적 주장이다" 라고 정정했음. 그러자 Claude는 다시 "맞다, X가 Y보다 낫다" 며 역시 잘 정리된 이유를 내놓았음. 결국 바벨의 도서관 처럼 세상의 모든 천재성이 있어도 올바른 색인 키가 있어야만 쓸 수 있음
- LLM이 예측 엔진이라는 건 잘 알려져 있지만, 1차 근사로 LLM은 사용자가 원하거나 기대하는 답을 예측함. 환각의 큰 유발 요인 중 하나는 LLM이 해석한 사용자 기대가 현실과 맞지 않을 때이며, LLM은 현실을 자신이 파악한 기대에 맞추려 함. 환각을 줄이는 좋은 방법 중 하나는 프롬프트에서 단정문 을 최대한 제거하는 것임. 변호사들이 가짜 판례 인용으로 곤란해지는 것도 비슷해서, "X를 보여주는 판례를 찾아줘" 는 위험하고 "X에 관한 판례는 무엇인가" 가 더 나은 출발점임

원문

출처 / GeekNews

알려드립니다

이 글은 국내외 IT 소식들을 공유하는 GeekNews의 운영자이신 xguru님께 허락을 받아 GeekNews에 게제된 AI 관련된 소식을 공유한 것입니다.

출처의 GeekNews 링크를 방문하시면 이 글과 관련한 추가적인 의견들을 보시거나 공유하실 수 있습니다!

아래쪽에 좋아요를 눌러주시면 새로운 소식을 정리하고 공유하는데 힘이 됩니다~