유튜브 영상 하나 보고 '깨달음' 얻은 개발자들의 착각 8가지 (10년차 실무자가 속삭입니다)

안녕하세요, 10년 차 IT 실무자이자 테크 블로거, 요즘은 주로 자바스크립트와 AI 에이전트의 매력에 푹 빠져 지내는 제가 돌아왔습니다. 얼마 전 모처럼 달콤한 휴가를 다녀왔습니다만, 그 사이에도 제 머릿속엔 온갖 재미있는 글감들이 맴돌더군요. 아직 연구가 좀 더 필요한 글이라 다음 주에나 공개할 수 있을 것 같고, 그 대신 오늘은 좀 가벼운 이야기를 해볼까 합니다.

아, 그리고 작은 소식 하나! 작년에 '올해는 더 이상 콘퍼런스 연사가 없을 겁니다!'라고 자신 있게 말했는데... 역시 사람은 말을 함부로 하면 안 되는 것 같습니다. 😅 iJS Munich에서 연락이 왔는데, 그 강연자 라인업을 보고 나니 "NO"라고 말할 수가 없더라고요. 말 그대로 천재들만 모인 자리에 저도 슬쩍 끼어들게 되었네요. 10월 말에 React에서의 WebAssembly와 WebGPU에 대해 발표할 예정인데, 벌써부터 엄청나게 설렙니다.

혹시 여유 자금(?)이 있으시거나 (아니면 현실적으로 회사의 교육 예산이 남아있다면), 오셔서 인사라도 나눠주세요! 직접 만나 뵙고 이야기를 나누면 정말 즐거울 것 같습니다. 😊

...자, 그럼 다시 오늘 이야기로 돌아와 볼까요?

아마 많은 분이 아시겠지만, 저는 링크드인 그루들이나 어떤 주제든 절대적인 확신을 가지고 설명하는 사람들을 보면 묘한 매력을 느낍니다. "내 솔루션이 최고고, 나머지는 다 틀렸으며, 단점 따위는 존재하지 않는다!"고 외치는 유형 말이죠. 😄

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

하지만 솔직해져 봅시다. 우리 모두 짧은 영상 하나 보고 "아, 이제 완벽하게 이해했어!"라고 생각했다가, 막상 실제 구현에 들어가 보니 현실은... 살짝 더 복잡하다는 걸 깨달았던 경험이 있지 않나요? 😂

요즘은 주로 자바스크립트와 AI 에이전트 작업을 많이 하는지라, 예시는 그쪽 분야에서 주로 가져올 예정입니다. 여러분도 경험했던 에피소드가 있다면 댓글로 자유롭게 공유해주세요!

1. React / Angular / Vue (불필요한 것은 삭제)는 최고의 프레임워크다

아마 인터넷 그루들의 영상을 보고 가장 흔히 갖게 되는 생각일 겁니다. 특히 아직 자기만의 확고한 관점이 정립되지 않았을 때 더욱 그렇죠.

"앵귤러가 최고야, 모든 게 다 있잖아." "리액트가 최고지, 다들 쓰는데는 이유가 있어." "뷰가 최고인데... 음... 뷰를 쓰는 사람들이 왜 최고인지 말해줄 거야!" 😄

그러다 몇 년간 실제 프로젝트를 빌드하다 보면, 결국 모든 프레임워크가 장단점과 고유한 사용 사례를 가지고 있다는 걸 깨닫게 됩니다. 결국 '최고의 프레임워크'는 대개 내 문제를 가장 잘 해결해주는 프레임워크일 뿐이죠. 제가 신입 시절에는 리액트가 최고라고 굳게 믿었지만, 실무에서 레거시 앵귤러 프로젝트를 맡아보고 나서야 '정답'은 없다는 걸 깨달았죠. 중요한 건 상황에 맞는 도구를 선택하는 지혜입니다.

2. LLM은 그저 자동 완성 기능일 뿐이다

혹은 이렇게도 말하죠:

"그냥 확률적 앵무새일 뿐이야." "창의적이지 않아." "아무것도 이해 못 해."

음... 만약 그렇게 간단하다면, 왜 수많은 연구팀과 엔지니어들이 수년 동안 이 분야에 매달려 연구하고 있을까요? 왜 기업들은 수십억 달러어치의 GPU를 태우고 있을까요? 😄

LLM이 "창의적이지 않다"는 주장 역시 저를 미소 짓게 만듭니다. 물론, 인류가 이제껏 알던 모든 것과 완전히 동떨어진 무언가를 갑자기 발명해내지는 못할 겁니다.

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

대부분의 사람이 어느 날 아침 갑자기 양자역학을 발명하거나 <반지의 제왕> 같은 대작을 쓰지는 않습니다. 창의성이란 대개 기존 아이디어들을 흥미로운 방식으로 결합하는 것인데, LLM은 사실 이 점에서 놀랍도록 뛰어난 능력을 보여줍니다. 처음 LLM을 접했을 때 저도 '그냥 똑똑한 예측기 아닌가?' 하는 생각을 했습니다. 하지만 복잡한 문제 해결에 활용해보니, 단순히 다음 단어를 맞추는 걸 넘어선 '생각하는 과정'을 엿보는 기분이 들더군요.

3. CQRS (프런트엔드에서는 Redux)는 쉽다

물론이죠. 그러다가 코드베이스를 열면 갑자기 공포 영화에 나올 법한 아키텍처를 마주하게 됩니다.

정말 별의별 경우를 다 봤습니다. 비즈니스 로직이 리덕스 스토어와 컴포넌트 사이에 여기저기 흩어져 있고, 상태의 절반은 전역으로, 나머지 절반은 로컬로 관리되며, 액션이 어째서인지 비즈니스 로직을 담고 있고, 리듀서가 갑자기 서비스로 둔갑해버린 경우까지요.

몇 년 전, 제가 개발자 인터뷰를 더 자주 하던 시절에는 아주 간단한 질문을 했습니다. "우리는 왜 CQRS (혹은 Redux)가 필요한가요?" (참고로... 둘의 차이점조차 모르는 사람도 있었습니다.) 그리고는 다른 질문을 던졌죠. "더 간단한 방법으로는 이걸 해결할 수 없나요?"

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

"모르겠어요... 그냥 다들 이렇게 하더라고요."

레덕스를 도입하면 코드가 깔끔해진다는 말에 혹해서 무작정 적용했다가, 나중에 복잡한 상태 관리 로직 때문에 밤샘 디버깅을 했던 아픈 기억이 떠오르네요. 결국 '왜 필요한가'에 대한 깊은 이해 없이 섣부른 도입은 독이 될 수 있습니다.

4. AI 에이전트는 그저 와일 루프일 뿐이다

솔직히 말하자면! 제 친한 친구이자 전 테크 리더 중 한 명이 실제로 이 제목으로 훌륭한 콘퍼런스 강연을 하는데, 의도적으로 도발적인 제목이죠.

그리고 진실을 마주해봅시다... 어느 정도는 사실입니다. 많은 AI 에이전트가 정말 "그저 와일 루프"일 뿐입니다.

재미있는 부분은 대략 3주 후에 시작됩니다. 갑자기 당신의 작은 와일 루프가 MCP 서버 3개, 오케스트레이션 프레임워크, 재시도 로직, 메모리 관리, 툴 호출 등등을 주렁주렁 달게 되는 거죠.

그래도 최근에 제가 작업했던 것 중 가장 재미있는 기술 중 하나였습니다. 제가 처음 에이전트 개념을 익힐 때, '아, 결국 루프 돌면서 툴 부르는 거네?' 하고 가볍게 생각했어요. 그런데 실제 서비스에 적용하려니, 예상치 못한 오류 처리나 메모리 관리 같은 문제에 부딪히며 '간단한 while 루프' 뒤에 숨은 거대한 복잡성을 실감했죠.

5. WebAssembly는 항상 빠르다

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

오해하지 마세요, WebAssembly는 정말 놀랍습니다. 특히 계산 집약적인 알고리즘, 시뮬레이션 또는 유사한 작업 부하를 다룰 때는 자바스크립트 성능을 압도하는 수많은 시나리오가 존재합니다.

하지만 당신의 애플리케이션이 대부분의 시간을 HTTP 요청이 끝날 때까지 기다리는 데 보낸다면... WebAssembly가 인터넷을 더 빠르게 만들지는 못할 겁니다.

그리고 갑자기 대시보드를 NASA 소프트웨어로 변신시켜주지도 않겠죠. 😄 웹어셈블리가 특정 연산에서 자바스크립트를 압도하는 성능을 보여주는 건 분명합니다. 저도 이미지 처리 라이브러리를 포팅하며 그 장점을 체감했지만, 네트워크 통신 위주의 웹 애플리케이션에 맹목적으로 적용하려다가는 기대만큼의 속도 향상을 얻지 못하고 개발 복잡성만 키우는 결과를 낳을 수도 있죠.

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

특히 프로덕션 코드를 생성한 동일한 LLM이 방금 생성한 유닛 테스트는 더더욱 그렇겠죠. 😂 100%의 자신감!

...아니면 아닐 수도 있습니다.

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

축하합니다, 100% 테스트 커버리지를 달성했지만, 실제 코드에 대한 신뢰도는 0%가 되었네요! 테스트 커버리지 100%라는 숫자에 집착하다가, 정작 핵심 비즈니스 로직의 결함을 놓친 경험도 있습니다. 저도 한때 AI가 생성한 테스트 코드에 기대려 했지만, 결국 '무엇을, 왜 테스트하는지'에 대한 개발자의 비판적 사고가 없으면 숫자놀이에 불과하다는 걸 깨달았죠.

7. RAG만 추가하면 된다

음... 그럴 리가요.

마치 올바른 문서를 찾고, 정제하고, 유지 관리하고, 선택하는 과정이 쉬운 부분인 것처럼 말이죠. 😄 RAG가 LLM의 환각 현상을 줄여준다는 말만 듣고 '이거다!' 싶었죠. 그런데 실제 프로젝트에서 문서들을 수집하고, 정제하고, 의미 있는 청크로 나누는 과정이 생각보다 훨씬 고되고 복잡해서 '쉽게' 추가할 수 있는 기능이 아니라는 걸 뼈저리게 느꼈습니다.

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

당연하죠! 특히 애플리케이션이 6개의 화면과 하나의 백엔드 서비스로 구성되어 있을 때라면 말입니다. 😄 아니면 팀원 모두가 완벽하게 이해하고 있는 건강한 모놀리식 아키텍처를 가지고 있을 때도 마찬가지입니다.

때로는 분산 아키텍처가 당신에게 정확히 필요한 것일 수 있습니다. 하지만 때로는 그저 복잡성을 분산시키는 것에 불과할 때도 많죠. 초기 스타트업에서 '유연성과 확장성'을 이유로 마이크로서비스 아키텍처를 도입했다가, 팀원들이 도메인 경계 설정과 분산 시스템 관리에 허덕이는 모습을 여러 번 봤습니다. 저 역시 무조건적인 도입보다는, 팀 규모와 서비스의 성장 단계에 맞춰 모놀리식 아키텍처가 더 합리적인 선택이 될 수 있다는 점을 항상 고려합니다.

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

여러분은 어떠신가요? 혹시 **"유튜브 영상 하나 보고 온 그루"**를 만나본 적 있으신가요?

이 글이 재미있으셨다면, 제 블로그의 다른 글들도 살펴보시거나 피드백을 남겨주시면 감사하겠습니다!

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