RicoCheesethe studio log · v2.0
Live · KRRead posts
목록으로
뉴스PUBLISHED · 2026년 7월 14일·9 MIN READ

유튜브 영상 하나 보고 자신 있게 설명하는 개발자들의 8가지 착각

15분짜리 튜토리얼 한 편으로 모든 걸 이해했다고 믿는 순간들. 프레임워크 전쟁부터 마이크로서비스까지, 개발자들이 흔히 빠지는 과신을 개발자 Sylwia Laskowska가 유머러스하게 짚었다.

#career#webdev#ai#discuss#programming
8 Things Developers Confidently Explain After Watching One YouTube Video

개요 #

15분짜리 유튜브 영상 하나를 다 보고 나면 이런 생각이 든다. "이제 완벽하게 이해했어." 그런데 막상 코드를 짜기 시작하면 현실은 훨씬 복잡했다는 걸 깨닫는다. 개발자 Sylwia Laskowska는 자신의 경험을 담아, 영상 한 편으로 모든 걸 다 안다고 확신하는 개발자들이 흔히 던지는 8가지 단정을 유쾌하게 정리했다.

그는 무엇이든 자신만만하게 설명하는 "링크드인 구루" 스타일에 애정 어린 시선을 보낸다. 자기 해법이 항상 최선이고, 남들은 다 틀렸으며, 트레이드오프 같은 건 없다는 그 특유의 자신감 말이다. 주로 자바스크립트와 AI 에이전트를 다루는 저자답게 예시도 그쪽에 몰려 있다.

어두운 책상 위 코딩 화면이 켜진 노트북과 커피잔 Photo by Daniil Komov on Pexels

프레임워크와 아키텍처를 둘러싼 과신 #

1. "React / Angular / Vue가 최고의 프레임워크야" #

아직 자기만의 기준이 없을 때 가장 흔히 나오는 말이다. Angular는 다 갖췄으니까 최고, React는 모두가 쓰니까 최고, Vue는... 뭐 Vue 쓰는 사람들이 알아서 이유를 대줄 거다. 그런데 실제 프로젝트를 몇 년 굴려 보면 셋 다 강점과 약점이 있고 쓰임새가 다르다는 걸 알게 된다. 결국 "최고의 프레임워크"란 대개 내 문제를 가장 잘 푸는 그 프레임워크일 뿐이다.

3. "CQRS(또는 프론트엔드의 Redux)는 쉬워" #

그렇게 말하고 코드베이스를 열면 아키텍처판 공포영화가 펼쳐진다. 비즈니스 로직이 Redux 스토어와 컴포넌트에 나뉘어 있고, 상태의 절반은 전역, 절반은 지역으로 관리된다. 액션 안에 비즈니스 로직이 들어 있고, 리듀서는 어느새 서비스 노릇을 하기로 마음먹은 듯하다.

저자가 예전에 개발자 면접을 자주 보던 시절 던진 질문은 단순했다. "우리가 CQRS(또는 Redux)를 왜 써야 하죠?" 그리고 한 번 더. "더 간단하게 풀 수는 없나요?" 놀랄 만큼 많은 지원자가 이렇게 답했다고 한다. "글쎄요... 다들 그렇게 하니까요."

8. "마이크로서비스 / 마이크로프론트엔드만이 정답이야" #

화면 여섯 개에 백엔드 서비스 하나뿐인 애플리케이션이라면? 아니면 팀원 모두가 이해하는 건강한 모놀리스가 이미 있다면? 분산 아키텍처가 딱 맞는 순간도 분명 있다. 하지만 어떤 때는 그저 복잡함만 분산될 뿐이다.

AI를 둘러싼 오해 #

어두운 작업대 위의 마이크로컨트롤러와 도구들 Photo by Tanha Tamanna Syed on Pexels

2. "LLM은 그냥 자동완성이야" #

"확률적 앵무새일 뿐", "창의적이지 않아", "사실 아무것도 이해 못 해"라는 버전도 흔하다. 그런데 그렇게 단순하다면 왜 연구자와 엔지니어 팀 전체가 몇 년씩 매달리고, 기업들은 수십억 달러어치 GPU를 태우고 있을까.

특히 "LLM은 창의적이지 않다"는 말에 저자는 웃는다. 물론 인류가 한 번도 몰랐던 무언가를 뚝딱 만들어 내진 못한다. 그런데 그건 대부분의 인간도 마찬가지다. 아침에 일어나 양자역학을 발명하거나 『반지의 제왕』을 써 내려가는 사람은 거의 없다. 창의성이란 대개 기존 아이디어를 흥미롭게 조합하는 일이고, LLM은 의외로 그걸 꽤 잘한다.

4. "AI 에이전트는 그냥 while 루프야" #

솔직히 이 말엔 진실이 담겨 있다. 저자의 친구이자 예전 테크리드는 아예 이 제목으로 도발적인 콘퍼런스 발표를 한다고 한다. 실제로 많은 AI 에이전트는 정말 "그냥 while 루프"다. 재미있는 건 그 다음이다. 3주쯤 지나면 그 작은 while 루프에 MCP 서버 세 개, 오케스트레이션 프레임워크, 재시도 로직, 메모리, 툴 콜링이 줄줄이 붙는다. 그래도 저자는 최근 다뤄 본 것 중 가장 재미있는 작업이었다고 말한다.

7. "그냥 RAG 붙이면 되잖아" #

문서를 찾고, 정제하고, 관리하고, 적절한 걸 골라내는 그 과정이 마치 쉬운 일이라도 되는 것처럼. 저자는 여기에 짧은 웃음만 남긴다.

성능과 테스트에 대한 착각 #

작업대 위 아두이노 회로 기판과 도구들 Photo by Tanha Tamanna Syed on Pexels

5. "WebAssembly는 언제나 더 빠르다" #

누군가 이렇게 말하면 저자는 늘 두 가지를 되묻는다. "뭐보다 빠른데요? 그리고 무슨 작업에서 빠른데요?" WebAssembly가 대단한 건 맞다. 계산량이 많은 알고리즘이나 시뮬레이션 같은 작업에서는 자바스크립트를 압도한다. 하지만 애플리케이션이 대부분의 시간을 HTTP 요청이 끝나기를 기다리며 보낸다면, WebAssembly가 인터넷 속도까지 빠르게 만들어 주진 않는다. 대시보드를 NASA 소프트웨어로 둔갑시켜 주지도 않는다.

6. "유닛 테스트가 우리의 황금 티켓이다" #

특히 프로덕션 코드를 짠 바로 그 LLM이 생성한 테스트라면? 자신감 100%다. 아니면... 아닐 수도 있다. 프론트엔드에서는 이 함정이 더 교묘하다. 유닛 테스트가 검증하는 건 대개 애초에 짜기 가장 쉬웠던 코드다. 축하한다. 테스트 커버리지 100% 달성. 그리고 신뢰도 0%.

마치며 #

저자는 이런 예시를 스무 개쯤 더 늘어놓을 수도 있었지만 오늘은 여기까지라고 말한다. 그러면서 독자에게 묻는다. "여러분도 '유튜브 영상 한 편 구루'를 만난 적 있나요?"

한 가지 덧붙이자면, 저자는 올해 마지막 콘퍼런스라던 FrontKon 이후로도 10월 말 뮌헨 iJS에서 React에서의 WebAssembly와 WebGPU를 주제로 발표할 예정이라고 한다.


이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.