유튜브 영상 하나 봤다고 '다 알았다'는 당신, 혹시 이 8가지 함정에 빠져있나요?

안녕하세요! 휴가 잘 보내셨나요? 저는 99%의 폴란드 사람들처럼 크로아티아에서 모처럼의 휴식을 만끽하고 돌아왔습니다. 도바르 단! 🇭🇷

지금 머릿속에는 정말 재미있는 글감이 하나 있는데, 발행 전에 조금 더 자료 조사가 필요해서 다음 주쯤에나 소개할 수 있을 것 같아요. 그 전에 오늘은 가볍게 읽을 수 있는 이야기를 풀어볼까 합니다.

아, 그리고 작은 소식 하나! 제가 올해 프론트콘이 마지막 컨퍼런스일 거라고 했었죠? 음... 아무래도 거짓말을 한 것 같네요. 😂 iJS Munich에서 연락이 오면 거절할 수가 없더라고요. 특히 발표자 라인업을 보니 더더욱 그랬습니다. 저 빼고는 전부 천재들만 모인 것 같더라고요! 😅 그래서 10월 말에 그곳에서 React 기반 WebAssembly와 WebGPU에 대해 발표하게 되었는데, 벌써부터 엄청나게 기대하고 있습니다.

혹시 여유로운 돈다발이 굴러다니시거나(농담입니다 xDDD, 훨씬 현실적으로는 회사에 교육 예산이 남아 있다면!), 오셔서 인사 나눠주시면 좋겠어요! 직접 만나서 이야기 나눌 수 있다면 정말 즐거울 거예요. 😊

자, 그럼 오늘의 주제로 돌아가 볼까요?

아마 많은 분들이 아시겠지만, 저는 링크드인 구루들이나 모든 것을 절대적인 확신을 가지고 설명하는 사람들에게 묘한 매력을 느낍니다. "내 방식이 최고고, 다른 사람들은 다 틀렸으며, 단점 따위는 존재하지 않는다!"고 외치는 그런 부류 말이죠. 😄

가끔은 그 엄청난 자신감의 상당 부분이 고작 15분짜리 유튜브 튜토리얼 영상 하나에서 비롯된 건 아닐까 하는 생각이 들 때가 있습니다.

하지만 솔직해져 봅시다. 우리 중 누가 짧은 영상을 보고 *"아, 이제 다 이해했어!"*라고 생각했다가, 실제 구현에 들어가서 현실이... 생각보다 훨씬 복잡하다는 걸 깨달아 본 경험이 없겠어요? 😂

요즘은 주로 자바스크립트와 AI 에이전트 관련 작업을 많이 하고 있어서, 예시들은 대부분 이 분야에서 나올 것 같네요. 여러분도 댓글로 자신만의 경험을 공유해주세요!

1. React / Angular / Vue (불필요한 것은 지우세요)는 최고의 프레임워크입니다.

이건 인터넷 구루의 영상을 보고 난 후, 특히 아직 자신만의 견해가 확립되지 않았을 때 가장 흔하게 접하는 의견일 겁니다.

Angular가 최고인 이유는 모든 것을 갖추고 있기 때문이고요. React가 최고인 이유는 모두가 사용하기 때문이죠. Vue는 최고인 이유가... 음... Vue 팬들이 설명해 줄 겁니다. 😄

하지만 몇 년 동안 실제 프로젝트를 구축하다 보면, 이 모든 프레임워크가 각자의 장단점과 고유한 사용 사례를 가지고 있다는 걸 깨닫게 됩니다. 결국 "최고의 프레임워크"란 당신의 문제를 가장 잘 해결해 주는 프레임워크일 뿐이죠. 제가 실무에서 여러 프로젝트를 경험해 보니, 특정 기술 스택에 대한 맹목적인 믿음보다는 당면한 문제와 팀의 역량에 맞는 선택이 훨씬 중요하다는 것을 매번 확인하게 되더라고요.

2. LLM은 그냥 자동 완성 기능일 뿐입니다.

또 다른 인기 있는 버전은 이렇죠.

"그것들은 그냥 확률적 앵무새일 뿐이야." "창의적이지 않아." "아무것도 제대로 이해하지 못해."

글쎄요... 만약 그렇게 단순하다면, 왜 수많은 연구자와 엔지니어 팀이 수년간 매달려 개발하고 있을까요? 왜 기업들은 수십억 달러어치의 GPU를 쏟아붓고 있는 걸까요? 😄

LLM이 "창의적이지 않다"는 주장도 항상 저를 미소 짓게 만듭니다. 물론 인류가 이제껏 알지 못했던 완전히 새로운 무언가를 발명하지는 못할 겁니다.

하지만 솔직히... 대부분의 인간도 마찬가지 아닌가요?

대부분의 사람이 어느 날 아침에 일어나 양자역학을 발명하거나 <반지의 제왕> 같은 대작을 쓰는 건 아니죠. 창의성이란 대개 기존 아이디어들을 흥미로운 방식으로 결합하는 것인데, LLM은 실제로 그런 면에서 놀랍도록 뛰어난 능력을 보여줍니다.

3. CQRS (또는 프론트엔드의 Redux)는 쉽습니다.

그럼요, 쉽죠. 그러다가 코드베이스를 열어보면 갑자기 공포 영화에나 나올 법한 아키텍처를 마주하게 될 겁니다.

저는 정말 온갖 상황을 다 봤습니다. 비즈니스 로직이 Redux 스토어와 컴포넌트 사이에 여기저기 흩어져 있거나, 절반은 전역 상태로 관리하고 나머지 절반은 지역 상태로 두는 경우, 심지어 액션에 비즈니스 로직이 포함되어 있거나 리듀서가 서비스 역할을 자처하는 광경까지요.

몇 년 전, 제가 개발자 면접을 자주 볼 때 아주 간단한 질문을 던지곤 했습니다. "우리는 왜 CQRS(또는 Redux)가 실제로 필요한가요?" (참고로, 둘의 차이조차 모르는 사람도 꽤 많았습니다.) 그리고 이어서 또 다른 질문을 했죠. "이것을 더 간단한 방법으로 해결할 수는 없을까요?"

놀랍게도 많은 사람이 이렇게 답했습니다.

"음... 그냥 다들 그렇게 하니까요."

제가 실무에서 이 부분을 테스트해 봤을 때, 단순히 '유행하는 기술'이라서 도입하는 팀치고 성공적으로 안정화시킨 경우를 거의 보지 못했습니다. 핵심은 '왜?'라는 질문에 대한 명확한 이해와 필요성입니다.

4. AI 에이전트는 그냥 while 루프일 뿐입니다.

솔직히 말하자면, 제 친한 친구이자 전 테크 리더가 정확히 이런 도발적인 제목으로 아주 훌륭한 컨퍼런스 발표를 합니다.

그리고 사실... 어느 정도는 맞는 말이죠. 많은 AI 에이전트가 정말 "그냥 while 루프"입니다.

재미있는 부분은 대략 3주 후에 시작됩니다. 갑자기 당신의 조그만 while 루프는 세 대의 MCP 서버, 오케스트레이션 프레임워크, 재시도 로직, 메모리 관리, 툴 호출 등등을 포함하게 됩니다.

그럼에도 불구하고, 최근에 제가 작업했던 것들 중 가장 재미있는 분야 중 하나임은 분명합니다. 처음엔 간단해 보였던 프로젝트가 어떻게 덩치를 불리는지 저는 정말 여러 번 목격했습니다.

5. WebAssembly는 항상 더 빠릅니다.

누군가 이런 말을 할 때마다 저는 똑같은 두 가지 질문을 합니다. "무엇보다 더 빠르다는 거죠?" 그리고 "무엇을 하는 데 더 빠르다는 거죠?"

오해는 마세요, WebAssembly는 정말 대단합니다. 특히 계산 집약적인 알고리즘, 시뮬레이션 또는 유사한 워크로드를 다룰 때는 자바스크립트 성능을 압도하는 시나리오가 많습니다.

하지만 애플리케이션의 대부분이 HTTP 요청이 완료되기를 기다리는 데 시간을 보낸다면... WebAssembly가 인터넷 속도를 갑자기 빠르게 만들어주지는 않을 겁니다.

그리고 당신의 대시보드를 갑자기 NASA 소프트웨어로 변신시켜주지도 않겠죠. 😄 제가 예전에 특정 고성능 이미지 처리 알고리즘을 WebAssembly로 포팅해본 경험이 있는데, 분명한 성능 향상은 있었지만, 단순히 '빠르다'는 환상만으로 도입하면 오히려 개발 복잡도만 늘어날 수 있다는 것을 깨달았습니다.

6. 단위 테스트는 우리의 황금 티켓입니다.

특히 프로덕션 코드와 똑같은 LLM이 생성한 단위 테스트라면요. 😂 100% 확신!

...아니, 아마 아닐 겁니다.

이것은 프론트엔드에서 특히 오해의 소지가 있는데, 단위 테스트가 종종 처음부터 가장 작성하기 쉬웠던 코드를 검증하는 데 그치는 경우가 많기 때문입니다.

축하합니다, 100% 테스트 커버리지를 성공적으로 달성했고, 확신은 0%가 되었습니다! 테스트 커버리지 수치만 보고 안심했다가 버그 폭탄을 맞았던 기억도 생생합니다. 진짜 중요한 비즈니스 로직이 아닌, 그저 '작동하는 부분'만 테스트하고 넘어가는 함정이죠.

7. 그냥 RAG를 추가하면 됩니다.

네에...

마치 올바른 문서를 찾고, 정제하고, 유지보수하고, 선택하는 과정이 쉬운 부분인 것처럼 말이죠. 😄

RAG(Retrieval Augmented Generation) 도입을 너무 쉽게 생각했다가 데이터 정제에만 몇 달을 날린 팀도 봤습니다. 단순히 '추가'하는 개념이 아니라, 방대한 데이터 관리와 품질 유지가 동반되는 일임을 잊으면 안 됩니다.

8. 마이크로서비스 / 마이크로프론트엔드가 유일한 좋은 아키텍처입니다.

물론이죠! 특히 애플리케이션이 6개의 화면과 하나의 백엔드 서비스로 구성되어 있을 때 그렇습니다. 😄 혹은 팀원 모두가 완벽하게 이해하고 있는 건강한 모놀리스를 가지고 있을 때도요.

때로는 분산 아키텍처가 정확히 필요한 해답일 수 있습니다. 하지만 때로는 그것이 그저 '분산된 복잡성'에 불과할 때도 많습니다. 초기 스타트업에서 "요즘 대세니까!"라는 이유만으로 마이크로서비스를 도입했다가 배포와 디버깅의 지옥을 맛보며 고생하는 걸 보면 안타까움을 금할 수 없습니다.

아마 스무 가지 예시를 더 들 수도 있겠지만, 오늘은 이 정도로 충분할 것 같네요. 😂

여러분은 어떠세요? 그런 **"유튜브 영상 하나짜리 구루"**들을 만나본 적 있으신가요?

이 글이 마음에 드셨다면, 제 LinkedIn에서도 팔로우해주세요: https://www.linkedin.com/in/sylwia-laskowska-5a8467131/

원문: https://dev.to/sylwia-lask/8-things-developers-confidently-explain-after-watching-one-youtube-video-3jio 수집일: 2026-07-15 01:09:45