https://www.youtube.com/watch?v=ULWtha1Gwio

description: |-

1. 이건 꼭 알아야 한다[^1]

[? 질문] 웹개발자는 정확히 무엇을 만드는 사람이며, 왜 “문서”를 만든다고 말하는가[^2]
[= 답] 웹은 원래 문서 공유 목적(초기에는 제한된 조직/부대 내 문서 공유)에서 출발했고, 오늘날 우리가 보는 화려한 UI/기능도 결국 브라우저가 해석해 보여주는 “문서(컨텐츠)”의 확장 형태이기 때문에, 웹개발자는 근본적으로 웹브라우저가 해석할 문서와 그 문서를 생성/동작시키는 체계를 만드는 사람으로 이해해야 한다.[^2][^6]

[? 질문] 웹개발자의 종류(웹퍼블리셔/프론트엔드/백엔드)는 무엇이 다르고, 실제 업무 감각은 어떻게 다른가[^7]
[= 답] 웹퍼블리셔는 브라우저/기기별 표준·호환성과 HTML/CSS 중심의 표현을 맞추는 역할이 크고, 프론트엔드는 브라우저에서 실행되는 JavaScript 중심의 상호작용/동적 UI를 다루며, 백엔드는 사용자에게 노출되지 않는 서버 쪽에서 데이터·검증·DB·보안을 포함한 로직을 처리한다.[^7][^24][^31]

[? 질문] 프론트엔드 vs 백엔드 중 무엇을 선택해야 하고, 언어/스택은 무엇이 “정답”인가[^31]
[= 답] 어느 쪽이든 깊게 들어가면 끝이 없을 정도로 어렵고(난이도 비교가 단순하지 않음), 먼저 둘 다 경험해보고 적성을 확인한 뒤 한 분야를 특화하는 것이 낫다.[^31][^46] 언어는 우열의 문제가 아니라 목적과 환경의 문제이며, PHP/Java/Python/Node.js 등은 각각 쓰임이 있고 “하등한 언어”는 없으니 특정 언어를 폄하하는 강사/담론은 걸러야 한다.[^26][^29]

[^1]: @[00:01] “이번에는 웹개발자에 대한 이해를 좀 도와주고 싶어서 이 영상을 찍게 됐어요” [^2]: @[02:09] 웹페이지/웹브라우저/사이트를 “하나의 페이지(문서)”로 설명하고, 초기 웹의 목적을 “단순 문서”에 둠 + @[04:13] “웹 개발자는… 문서를 만드는 사람이다” [^6]: @[04:24] 지금은 역동적이지만 “정적인 하나의 문서를… 기능들이 표현되서 그렇게 보이는 것”이라는 설명 [^7]: @[07:30] “웹개발 잘하는 게… 프론트엔드… (퍼블리셔)… 백엔드”로 갈래를 나눠 설명 시작 [^24]: @[24:14] 백엔드의 핵심을 “명령어/소스가 노출되지 않아야” 하는 영역으로 설명 [^31]: @[31:18] “뭐가 돈이 되냐/뭐가 더 힘드냐… 점수 매기기 힘들다… 양쪽 다 깊게 들어가면 끝이 없다” [^46]: @[46:03] “양쪽 다 해보시고 하나의 특화 시키세요”

2. 큰 그림[^1]

이 콘텐츠는 “웹개발자”라는 직업을 **역사적 맥락(웹의 기원)**부터 잡아주고, 실무에서 흔히 구분하는 웹퍼블리셔·프론트엔드·백엔드의 역할/난이도/수요/커리어 선택 기준을 초보자 눈높이로 풀어 설명한다.[^2][^7] 또한 언어/기술 스택에 대한 흔한 오해(언어 서열, 특정 언어 폄하)를 비판하면서, 학습·진로 선택에서 무엇을 기준으로 판단해야 하는지 관점을 제시한다.[^26][^29]

• 웹의 본질은 문서이며, 웹개발은 화려해 보이더라도 “브라우저가 해석하는 문서 체계” 위에 서 있다.[^4][^6]
• 프론트엔드/백엔드/퍼블리셔는 사용자 노출 여부(앞단/뒷단), 실행 위치(브라우저/서버), 책임 범위(표준·UI/로직·DB·보안)로 구분해 이해해야 한다.[^24][^31]
• [h 언어는 우열이 아니라 목적 적합성의 문제이며, “하등한 언어”라는 말은 걸러야 한다]—언어의 철학/탄생 목적을 보면 단순 서열화가 얼마나 무의미한지 알 수 있다고 강조한다.[^26][^29]

[^1]: @[00:24] “진로를 선택할 때… 도움이 될만한 영상을 만들고 싶었다” [^2]: @[02:09] “네이버/구글 같은 사이트들을 하나의 페이지라고… 처음엔 단순 문서” [^4]: @[04:13] “웹 개발자는 문서를 만드는 사람” [^6]: @[04:24] “정적인 하나의 문서를… 복잡하게 기능들이 표현” [^24]: @[24:30] “프론트는 앞쪽… 백은 뒤쪽… 사용자에게 보여지지 않는 영역” [^31]: @[31:09] “프론트는 브라우저… 백은 서버… 양쪽 다 깊게 들어가면 끝이 없다” [^26]: @[26:46] “php는 하등… 그런 소리 하는 사람들 보면 그냥 걸으세요… 언어의 열등/하등한 거 없어요” [^29]: @[29:38] “망치/칼 비유… 목적이 다른 언어”

3. 하나씩 살펴보기[^1]

3.1 이 영상의 목적: 초보가 ‘웹개발자 직무 그림’을 먼저 그리게 하기[^1]

화자는 영상의 목적을 “웹개발자에 대한 이해”를 돕는 것으로 시작한다.[^1] 현업 개발자라면 어느 정도 알지만, 초보 개발자는 웹개발자 직무가 어떻게 나뉘고 각 분야에서 실제로 어떤 일을 하게 되는지 감이 없을 수 있다고 전제한다.[^2] 그래서 진로를 선택할 때 “나는 웹개발자를 할 것인가/아닌가” 혹은 웹개발 안에서도 어떤 방향으로 갈 것인지 판단하는 데 도움이 되는 “그림”을 제공하고자 한다.[^1][^3]

또한 팀노바의 커리큘럼(특히 PHP 기초 단계에서 이 주제를 정리해 줌)에서 일부 다루는 내용이며, 강의 일부처럼 보일 수 있지만 “처음 하는 사람을 위해 더 쉽게 순화해서” 풀겠다고 말한다.[^4][^5] 국비 과정이든 독학이든, 큰 그림이 그려져야 공부가 수월해지고 “웹개발자 스킬셋이 어떤 느낌인지” 이해에 도움이 된다고 덧붙인다.[^5]

[^1]: @[00:01] “웹개발자에 대한 이해를…” [^2]: @[00:09] “웹개발자 종류가 다양… 초보 개발자면 잘 모르는 경우” [^3]: @[00:24] “내 진로를 선택할 때… 도움이 될만한” [^4]: @[00:41] “팀노바… php 기초 단계에서 이걸 다 정리” [^5]: @[01:07] “국비를 가시던 독학을 하시던… 그림이 그려져야… 스킬셋이 어떤 느낌인지”

3.2 웹/웹페이지의 출발과 ‘웹개발=문서 만들기’ 관점[^2]

화자는 웹 개발 설명에 앞서 “역사/어원”처럼 배경을 잠깐 짚는다.[^1] 웹은 “World Wide Web(WWW)”에서 ‘web’만 떼어 부르는 것이며, 우리가 웹개발이라 부르는 것은 결국 웹브라우저로 보는 웹페이지를 만드는 일이라고 시작한다.[^2] 네이버/구글 같은 사이트에서 “각각의 페이지”를 하나의 웹페이지로 본다.[^2]

그리고 웹페이지라는 말이 붙은 이유를 “처음 형태”에서 찾는다. 초기 웹은 지금처럼 예쁘고 역동적이고 기능이 많은 형태가 아니라, 군사 목적(혹은 제한된 조직 목적)으로 “단순 문서”를 공유하기 위한 형태에 가까웠다고 설명한다.[^3] 특정 지역/부대 내에서만 쓰는 제한된 문서 공유 방식이었는데, 시간이 지나 전 세계인이 교류하는 수단으로 바뀌었다는 것이다.[^4]

여기서 화자는 월드와이드웹이 무료로 공개되어 많은 사람이 함께 사용하게 된 배경도 언급한다.[^5] (영상 중간에 해당 인물의 이름을 잠시 기억하지 못해 검색하겠다고 하고, 나중에 영상/자료를 찾아 올리겠다고 말한다.)[^5]

이 역사적 맥락을 통해 화자는 결론을 내린다.

• [h 웹의 근본은 “문서”다]—그래서 “웹 개발자는 문서를 만드는 사람”으로 정리하는 것이 맞다고 한다.[^6]
• 오늘날 웹은 애니메이션도 많고 역동적으로 보이지만, 실체는 “정적인 문서(컨텐츠)”를 기반으로 하며, 기능들이 복잡하게 표현되어 역동적으로 보이는 것이라는 관점이다.[^7]
• 따라서 “웹개발은 역동적인 것만 한다”는 인상과 달리, 큰 틀에서 정적인 컨텐츠를 다루는 분야로 이해하라고 안내한다.[^8]

또한 웹개발은 (운영체제 프로그래밍 같은) 저수준 영역에 비해 “연속성(난이도의 체감/진입 장벽)”이 상대적으로 덜한 느낌이 있을 수 있다고 말한다.[^9] 다만 고수가 되면 어떤 분야든 어렵고, 웹도 “제대로 공부하고 제대로 들어가면 장난 아니다”라고 강조한다.[^10] 즉 초반 장벽이 낮아 보이지만 갈수록 어려워지며, 제대로 하는 사람은 의외로 흔하지 않을 수 있다는 문제의식이 깔려 있다.[^10][^11]

[^1]: @[01:26] “웹개발자 장단점과 공부한 순서… 이전에 약간 역사를” [^2]: @[01:43] “월드와이드웹 www… web만 정리” + @[02:00] “웹페이지… 네이버/구글… 하나의 페이지” [^3]: @[02:16] “군사 목적으로… 단순 문서…” [^4]: @[03:39] “자기 부대에서만… 제한된 문서 공유… 전 세계인들이 교류하는 수단” [^5]: @[02:48] “월드와이드웹을 무료로 사용하게 해주신 분” 언급 + @[03:09] “찾아서 올려 드릴게요” [^6]: @[04:13] “웹 개발자는… 문서를 만드는 사람” [^7]: @[04:24] “굉장히 정적인 하나의 문서를… 복잡하게 기능들이 표현” [^8]: @[04:43] “굉장히 정적인 컨텐츠를 다루는 분야” [^9]: @[04:53] “운영체제 프로그래밍에 비해서 연속성을 상대적으로 덜” [^10]: @[05:14] “진입장벽이 낮아 보이… 웹도 제대로 공부… 장난 아니에요” [^11]: @[05:32] “갈수록 어려워지는 분야… 제대로 하시는 분들은… 흔하지는”

3.3 수요/처우의 전제: “잘하는 프론트·백은 구하기 어렵고 수요가 많다”[^6]

화자는 웹 분야에서도 실력이 뛰어나면 먹고 사는 데 문제가 없고(특히 실리콘밸리 등) 좋은 기회를 얻을 수 있다는 맥락을 깐다.[^1] 그리고 “좋은 프론트엔드 개발자”를 양성/확보하는 데 시간이 많이 들며, 정말 잘하는 프론트엔드 개발자를 구하기가 “하늘의 별 따기”라는 이야기를 전한다.[^2] 그만큼 “잘하는 프론트/잘하는 백”에 대한 수요가 크다는 주장이다.[^2][^3]

이어 국비/학원에서 흔히 배우는 스택(자바 과정의 JSP/서블릿, 혹은 스프링/마이바티스 등)이 많이 가르쳐지는 이유를 “수요가 많기 때문”으로 설명한다.[^4] 다만 프레임워크가 10년 넘은 경우 올드하게 느껴질 수 있고, 특히 정부 프로젝트 등에서는 그런 스택이 계속 쓰이는 측면이 있다고 언급한다.[^5]

여기서 화자는 업계의 “실력 격차”를 강조한다. 겉보기에는 “적당히 해도 먹고 살 수 있는 개발자”처럼 보일 수 있지만, 제대로 볼 줄 아는 사람이 보면 차이가 어마어마하다고 말한다.[^6] ‘휘뚜루마뚜루’로 사는 사람도 많고, 정말 잘하는 사람은 많지 않다는 뉘앙스다.[^6]

[^1]: @[05:44] “엄청 잘하면 먹고 사는데 큰 문제가 없고… 실리콘밸리에서…” [^2]: @[06:01] “좋은 프론트엔드 개발자를… 6개월… 연봉을 억대… 하늘의 별따기” [^3]: @[06:13] “잘하는 프론트/백엔드 수요는 많” [^4]: @[06:20] “국비… 자바 과정에서 jsp/서블릿… 스프링/마이바티스… 왜 많이 배우냐면 수요가 많” [^5]: @[06:48] “프레임… 10년도 넘… 올드… 정부 프로젝트” [^6]: @[06:57] “잘 몰라도 적당히 해도 먹고 살 수… 제대로 볼 줄 아는 사람들이 보면 차이 어마어마”

3.4 웹개발 직무 구분의 큰 틀: 퍼블리셔/프론트엔드/백엔드[^7]

화자는 웹개발을 “페이지를 만드는 일”로 두고, 직무를 크게 프론트엔드와 백엔드로 나누며, 여기에 퍼블리셔(그리고 경우에 따라 웹디자이너)가 끼는 형태로 설명을 전개한다.[^1] 다만 현장/회사마다 역할 경계가 섞여 “왔다 갔다 해서 답이 없다”는 말로, 구분이 절대적으로 고정돼 있지 않음을 먼저 인정한다.[^2] 그럼에도 이해를 돕기 위해 3개로 나눠 설명하겠다고 한다.[^2]

• 웹디자이너: 디자인 중심.
• 웹퍼블리셔: 디자인 시안을 웹에서 표준/호환성에 맞게 구현하는 역할이 섞임(HTML/CSS, UI 구현, 웹표준).
• 프론트엔드: JavaScript 등으로 동적인 동작/상호작용 구현.
• 백엔드: 서버에서 동작, DB/검증/보안 등 사용자에게 노출되면 안 되는 영역.

이 중 화자는 먼저 웹퍼블리셔를 예시로 풀어간다.[^3]

[^1]: @[07:23] “웹개발… 페이지 만드는 건데… 특징이 두 가지… 프론트엔드… 백엔드” [^2]: @[07:56] “웹 디자이너도 있고… 왔다갔다… 큰방 줄기는… 3개로 나눠” [^3]: @[08:02] “웹퍼블리셔… 1페이지를 보면…”

3.5 웹퍼블리셔: 브라우저/기기 파편화와 웹표준을 맞추는 사람[^8]

3.5.1 브라우저마다 다르게 보이는 문제(파편화)와 ‘맞춰주는 일’[^8]

화자는 자신의(팀노바) 홈페이지를 예로 들며, 같은 사이트가 웹브라우저에 따라 폰트/표현이 달라질 수 있음을 보여준다.[^1] 그는 크롬은 구글이, (당시 맥락상) 인터넷 익스플로러/엣지 계열은 마이크로소프트가 만들었고, 회사/브라우저마다 “태그를 해석하는 방법”이 다르기 때문에 이런 차이가 생긴다고 설명한다.[^2]

즉, 같은 HTML 태그를 써도 렌더링/해석 방식이 달라서 결과가 달라지므로, 이를 “맞춰줘야” 한다는 것이다.[^2][^3] 모바일에서도 마찬가지이며, 이런 현상을 파편화로 볼 수 있다고 말한다.[^3]

3.5.2 웹표준과 W3C: 기준은 있으나 강제성은 약함[^9]

파편화를 줄이기 위해 “같은 태그는 비슷하게 해석해 쓰면 좋겠다”는 취지로 기준을 정하고, 이를 흔히 웹표준이라고 부른다고 설명한다.[^4] 그리고 이러한 기준을 만드는 단체로 W3C(World Wide Web Consortium)를 언급한다.[^5]

또한 W3C가 만든 학습 사이트(‘W3Schools’를 가리키는 맥락)를 예로 들며 기본 태그 등을 배울 수 있다고 한다.[^6] 다만 표준 문서/설명은 초보에게 “블라블라”처럼 어렵게 느껴질 수 있고, 영어 실력만으로 해결되는 문제는 아니며(영어 잘해도 개발을 어려워하더라는 경험), 개발 자체가 어렵다는 코멘트를 덧붙인다.[^7]

또 웹표준은 “맞추면 좋은 것”이지 강제성이 약해서 힘든 면이 있다고 말한다.[^8] 예전에는 파편화가 훨씬 심해 브라우저 버전별 설치까지 해야 했고, 맞추는 난이도가 높았다는 과거 경험도 언급한다.[^10]

3.5.3 퍼블리셔를 따로 뽑는 회사의 성격: 웹에이전시/SI와 분업화[^11]

화자는 퍼블리셔를 따로 채용하는 회사는 보통 웹에이전시(외주·SI 형태로 웹개발을 맡아 수행하는 업체)에서 많이 보인다고 말한다.[^11][^12] 외주로 “홈페이지 만들어 주는” 업체들이고, 웹에 특화된 일을 반복적으로 많이 하다 보니 세분화/분업이 발생한다는 논리다.[^12][^13]

여기서 화자는 산업혁명 시대의 분업화를 비유로 든다. 자동차를 분업화해서 만들면 더 빠르게 생산되듯, 웹개발을 주로 하는 조직(특히 새 앱 개발, 유지보수 건이 많은 조직)에서는 퍼블리셔처럼 표준/태그/호환성 맞추는 역할이 중요할 수 있다는 것이다.[^13]

3.5.4 퍼블리셔 직무의 현실적 제약(화자의 개인 견해)과 커리어 조언[^13]

화자는 개인 의견임을 전제하면서, 웹퍼블리셔라는 직업은 “엄청나게 잘하지 않다면” 회사 선택 폭이 제한될 수 있다고 본다.[^14] 이유는 다음과 같이 제시된다.

• 작은 기업은 웹퍼블리셔를 “따로” 뽑는 경우가 드물다.[^15]
• 차라리 프론트엔드/백엔드까지 일부 가능한 “뭉뚱그린” 형태로 채용하는 경우가 많다.[^16]
• 결과적으로 큰 기업이나 웹 특화 조직에서 수요가 더 있을 확률이 높다.[^16]

또한 퍼블리싱은 역량 편차가 크기보다 “덕력(경험/숙련)” 차이 정도로 보일 때가 많고, (솔직히 말하면) 연봉도 고만고만해지는 경향이 있다고 말한다.[^17] “이 사람 아니면 안 된다” 수준의 깊은 기술로 인정받기에는 상대적으로 깊이감이 덜하다는 평가도 덧붙인다.[^17][^18] 물론 내부적으로 연봉 차이가 있을 수는 있지만, 전체적으로는 난이도/보상 곡선이 프론트·백의 상위권만큼 가파르지 않을 수 있다는 인상이다.[^18]

퍼블리셔가 주로 다루는 영역으로 HTML, CSS(스타일시트)를 들고, 웹디자이너와 겹치는 부분도 있지만 UI를 잘 만들고 표준을 잘 맞추는 뛰어난 퍼블리셔도 존재한다고 말한다.[^19][^20] 다만 프론트엔드와도 많이 겹치기 때문에 “퍼블리셔만 하겠다”는 상담을 받으면, 학원 커리큘럼을 보고 직업이 존재할 것이라 오해하는 경우가 있고, 학원은 수요를 정확히 아느냐는 문제 제기도 한다(“잘 모른다”는 뉘앙스).[^21][^22]

마지막으로 웹개발 수요 자체는 매우 크며, 과거 조사에서 “전 세계 개발자의 70% 정도가 웹개발자”라는 이야기를 인용한다.[^23] 웹이 없는 세상이 상상하기 어려울 정도로 웹이 많기 때문이라는 것이다.[^23] 다만 그 안에서 “엄청 뛰어나지 않으면” 커리어/처우가 크게 좋아지기 어려울 수 있다는 개인적 견해를 덧붙인다.[^24]

[!NOTE] 퍼블리셔 파트에서 화자가 강조하는 숨은 전제
“직무 자체가 존재하느냐”보다 “시장에 그 직무를 단독 채용할 만큼 조직이 웹에 특화되어 있느냐(분업 구조가 있느냐)”가 중요하다는 관점이 깔려 있다.[^15][^16]

[^1]: @[08:11] 홈페이지 예시를 띄우며 “웹브라우저 별로 좀 달라요… 폰트 다르죠” [^2]: @[09:05] “크롬=구글… 인터넷 익스플로러=마이크로소프트… 태그를 해석하는 방법이 다르기 때문에” [^3]: @[09:29] “모바일도 마찬가지… 파편화… 맞춰 놓은” [^4]: @[09:44] “맞추는 패러다임을 웹표준이라고” [^5]: @[09:56] “기준을 정해주는 곳… w3c” [^6]: @[10:43] “기본 태그 배울 수 있는 곳… w3c에서 만든 스쿨” [^7]: @[10:56] “영어가 문제가 아니더라고요… 영어 잘해도 개발 어려워” [^8]: @[11:15] “강제성이 없으니까 좀 힘들죠” [^10]: @[11:23] “옛날에는 파편화 훨씬 심… 브라우저 버전별로 설치… 난이도” [^11]: @[11:49] “퍼블리셔 따로 뽑는 회사… 웹 에이전시” [^12]: @[12:06] “외주업체… 홈페이지 만들어주는… si 회사” [^13]: @[12:35] “산업혁명 시대 분업화” 비유 [^14]: @[13:51] “엄청나게 잘 하지 않다면… 회사가 제한” [^15]: @[13:59] “아주 작은 기업… 웹 퍼블리셔를 따로 뽑는다… 드물” [^16]: @[14:11] “프론트엔드/백엔드까지 가능한 웹퍼블리셔… 뭉뚱그려서 뽑는 케이스” [^17]: @[14:28] “연봉도 고만고만… 깊이가 있는 기술이라 말하기엔 깊이감이 덜” [^18]: @[14:48] “난이도도 높지… 미친듯이…” [^19]: @[15:21] “웹퍼블리셔… html… 스타일시트” [^20]: @[13:11] “뛰어난 퍼블리셔… 꼼꼼하게 표준도 잘 맞추고” [^21]: @[15:41] “퍼블리셔… 프론트엔드랑도 많이 겹… 퍼블리셔 되고 싶다 상담” [^22]: @[16:01] “학원… 수요를 정확히 알고 있잖아요… 잘 몰라요” [^23]: @[16:09] “전세계 70퍼센트… 웹 개발자” 언급 [^24]: @[16:40] “엄청나게 뛰어나지 않으면… 박봉(?) 좋아지긴 힘든…”

3.6 프론트엔드 개발자: 페이지 소스/스크립트와 ‘브라우저에서의 동작’[^17]

3.6.1 “소스 보기”: 브라우저가 해석하는 문서가 곧 화면[^17]

화자는 프론트엔드를 설명하면서 크롬에서 “소스 보기”를 통해 방금 본 페이지가 HTML 소스로 표현되어 있고, 그 소스를 웹브라우저가 해석해서 화면으로 보여준다고 말한다.[^1] 여기서 디자인 관련 요소는 CSS(스타일시트) 영역과 많이 엮이고, 퍼블리셔/디자이너가 주로 만지는 부분이 이쪽이라는 연결을 한다.[^2]

그리고 소스 안에 “script”가 있으며, 이것이 프론트엔드 개발자가 다루는 핵심 요소(자바스크립트)로 넘어가는 징검다리로 쓰인다.[^3]

3.6.2 자바스크립트: 알림창부터 ‘살아 움직이는 UI’까지[^18]

화자는 자바스크립트 예로 “alert 창”처럼 브라우저에서 메시지를 띄우는 동작을 보여준다.[^4] 즉, 브라우저의 자바스크립트를 이용해 화면에 알림 메시지를 띄운 것이고, 코드를 페이지에 넣으면 그런 동작이 발생한다는 식으로 전통적인 예시를 든다.[^4][^5]

이어서 마우스를 올리면 색이 바뀌고, 요소가 움직이고, 더 “생기 있는” 인터랙션이 있는 사이트들이 있는데, 이런 것들이 자바스크립트(및 CSS)로 만드는 영역이라고 설명한다.[^6] 이런 상호작용이 사이트를 액티브하게 만들고, 사용자가 “재밌게” 느끼게 해준다는 흐름이다.[^6][^7]

3.6.3 프론트엔드도 깊게 들어가면 ‘공학 기본기’가 필요하다[^21]

화자는 프론트엔드가 겉보기에 UI/스크립트지만, 제대로 파고들면 매우 어렵고 연봉도 높아질 수 있다고 말한다.[^8] 특히 해외(실리콘밸리 등)에서 처우가 좋다는 이야기를 전하며, 국내 처우는 자신이 단정하긴 어렵다고 조심스럽게 말한다.[^8]

중요한 강조점은 다음이다.

• 프론트엔드도 깊게 들어가면 장난 아니게 어렵다.[^9]
• 프론트엔드를 “제대로” 하려면 공학의 기본을 알아야 하고, 진짜 잘하는 사람들은 굳이 프론트를 안 해도 전반적으로 잘하는 경우가 많았다고 말한다.[^10]
• 학원에서 “깨작깨작” 배운다고 곧바로 잘해지는 게 아니며, 어느 수준까지 가야 하는지 아는 좋은 코치가 필요하다고 주장한다.[^11][^12]

여기서 화자는 “잘하는 사람한테 배워야 한다”는 말을 반복하는 이유가 이것 때문이라며, 잘하는 개발자의 머릿속 세계관 자체가 다르다고 표현한다.[^12] 하지만 역설적으로, 정말 잘하는 개발자들은 강의를 굳이 하지 않는 경우가 많고(잘 벌고 잘 사는데 굳이?), 또 가르치는 재능이 없는 경우도 많다고 한다.[^13] 팀노바는 오래 연구하고 오래 해 왔기 때문에 가르칠 수밖에 없고, 그래서 자신들이 “미쳤다”는 표현을 쓴다는 식의 자기 설명도 덧붙인다.[^14]

[!TIP] 프론트엔드 선택 감각(화자의 기준)
“역동적인 UI, 사용자 관점에서 화려한 인터랙션, 성능(렉 없이), 사용자에게 전달되는 소스가 잘 돌아가게 만드는 것”에 흥미가 크면 프론트엔드 집중이 어울릴 수 있다고 제안한다.[^15]

[^1]: @[17:07] “방금 보신 페이지가 이거예요… 웹브라우저가 해석” [^2]: @[17:18] “퍼블리셔/웹디자이너… 스타일시트… 디자인적인 부분” [^3]: @[17:24] “스크립트… (JS)…” [^4]: @[19:09] “팝업… 웹브라우저의 자바스크립트를 이용… 메시지를 띄운” [^5]: @[19:22] “코드 상에 이런걸 입력하면 뜨는” [^6]: @[19:38] “마우스 커서… 올리면 색깔 바뀌고… 움직이고…” [^7]: @[20:14] “확실히 훨씬 생기… 재밌어지고… 액티브” [^8]: @[20:29] “연봉도… 해외… 실리콘벨리…” [^9]: @[20:52] “깊게 들어가면 되게 어려워요” [^10]: @[21:09] “프론트엔드 제대로… 공학 기본… 진짜 잘하는 분들… 그냥 잘해요” [^11]: @[21:28] “학원에서 깨작깨작 배운다고… 잘해진다… 힘들” [^12]: @[21:52] “어느 영역까지 가야 되는지… 좋은 코치… 잘하는게… 잘하는 사람한테 배워야” [^13]: @[22:15] “굳이… 잘 벌고… 강의를 해야 되나… 가르치는 재능이 없어요” [^14]: @[22:39] “팀노바… 오래 연구했고 오래 해 왔으니까…” [^15]: @[34:29] “역동적… 사용자 관점… 렉없이… UI 화려… 프론트엔드 집중”

3.7 백엔드 개발자: ‘사용자에게 보이지 않는’ 서버 측 로직과 검증/DB/보안[^23]

3.7.1 PHP 예제로 설명하는 백엔드의 핵심: “소스가 노출되지 않는다”[^23]

화자는 백엔드를 보여주기 위해 간단한 테스트 페이지를 만들고 PHP를 호출하는 예시를 든다.[^1] 화면에는 “abcd” 같은 출력만 보이는데, 페이지 소스 보기로 보면 실제 출력(abcd)만 있고, 서버에서 실행된 PHP 로직 자체는 보이지 않는 점을 “신기하죠”라고 짚는다.[^2]

이 차이를 통해 프론트/백의 구분을 다음처럼 정의한다.

• 프론트엔드: “앞쪽” — 사용자가 브라우저에서 보게 되는 영역(노출되는 소스).[^3]
• 백엔드: “뒤쪽” — 사용자에게 보여지지 않는 영역(노출되면 안 되는 소스/명령/정보).[^3][^4]

왜 이런 구조가 필요하냐는 질문에 대해, 사용자가 알면 안 되는 정보(개인정보, DB 접속 ID/PW 등)가 있고, 서버에서 한 번 더 검증한 다음 프론트엔드로 “줄 수 있는 소스/줄 수 없는 소스”가 나뉘기 때문이라고 설명한다.[^4][^5]

즉 백엔드는 서버 측에서 안전하게 처리해야 하는 로직의 영역이라는 것이다.[^5]

3.7.2 백엔드 언어/스택은 다양하다: PHP는 예시일 뿐[^25]

화자는 자신이 여기서 PHP를 선택했을 뿐이며, 백엔드는 Java(JSP), Python, Node.js, Swift, Go, 심지어 C로도 할 수 있다고 말한다.[^6] “자기 하기 나름”이고, 다만 싫어하는 사람은 거의 없겠지만 보통 Java를 많이 쓰며 PHP도 의외로 많이 쓰인다고 덧붙인다.[^6][^7]

그리고 교육 현장에서 “PHP는 하등하다” 식으로 학생에게 주입하는 강사들을 강하게 비판한다.[^8] 교육자는 잘 모르면서 함부로 떠들면 안 되고, 자신이 하는 말에 책임을 져야 한다는 윤리까지 붙인다.[^9]

반대로 화자는 PHP가 문법이 직관적이고 쉬운 편이며, 웹에서 점유율도 높고(“거의 세 손가락” 수준이라고 표현), 페이스북/트위터 같은 글로벌 서비스도 시작은 PHP였다는 사례를 든다.[^10] 또한 W3Schools에서도 PHP를 중요하게 두는 듯한 맥락을 언급하며, 학습 경로에서 PHP가 자주 등장하는 이유를 “여러 가지”로 해석한다.[^11]

3.7.3 언어 서열화 비판: “망치 vs 칼” 비유로 보는 목적 적합성[^29]

화자는 언어에 대해 “우월/열등, 1등/하등” 같은 프레임으로 말하는 사람들을 무시한다고까지 말하며, 그 이유를 ‘목적이 다른 도구’ 비유로 설명한다.[^12][^13]

+++ 상세 예시: 망치와 칼 비유(원문 흐름 재구성)

• 망치질을 할 때는 망치(장도리)가 최고다.[^13]
• 하지만 음식을 썰어야 할 때는 칼이 최고다.[^13]
• 언어도 마찬가지로 “목적이 다른 언어”가 있고, 의도/설계 철학이 다르다.[^13]
• 언어를 제대로 공부해보고(홈페이지의 개요/의도만 읽어봐도) 그런 “서열” 발언은 하기 어렵다고 말한다.[^14] +++

또한 파이썬이 느리다는 성능 특성을 인정하면서도, 미국 대학의 입문 언어로 많이 쓰이고 인공지능/데이터마이닝 분야에서는 파이썬이 대체하기 어려울 정도로 라이브러리 의존성이 크다는 점을 든다.[^15] 즉 성능이 느리다는 단점만으로 “구리다”고 결론내리기 어렵다는 논지다.[^15]

PHP에 대해서도 역사적 라이브러리/확장 생태계가 많고 튜닝 장점이 있지만, 확장/공유 구조가 난해한 측면이 있다는 식으로 장단을 언급한다.[^16] Java는 PHP/Python에 비해 문법이 직관성 측면에서 떨어질 수 있으나 규칙이 엄격하다는 특성이 있고, 이를 “완벽하다”는 식으로 단순 찬양하는 사람들을 비꼬는 표현도 나온다.[^17] 결론적으로, 잘하는 개발자는 언어의 장단을 알고 상황에 맞게 쓴다는 태도를 강조한다.[^18]

3.7.4 백엔드의 난이도: 보안(OWASP Top 10), DB, 서버 관점까지 포함[^31]

화자는 프론트/백 모두 “깊게 들어가면 점수 매기기 힘들 만큼” 어렵다고 한 뒤, 백엔드가 깊어질수록 특히 보안 관점이 중요해진다고 말한다.[^19] 보안 컨설팅을 받을 수도 있지만, 개발자 본인이 최소한의 웹 보안은 알아야 한다는 입장이다.[^20]

구체적으로는 OWASP 같은 곳에서 매년 리포팅하는 “최신 유행 10가지” 정도는 막을 줄 알아야 한다고 말한다.[^21] 이게 쉽지 않다고 강조하면서, SQL 인젝션 같은 공격도 겉으로는 쉬워 보여 “이런 걸로 해킹하냐”는 식의 반응이 있지만, 잘하는 해커가 붙으면 매우 복잡하고 “장난 아니다”라고 한다.[^22] 해커들은 게임하듯 해킹을 즐기고 중독처럼 파고들기 때문에, “즐기는 사람을 이기기 힘들다”는 표현으로 보안 대응의 어려움을 비유적으로 말한다.[^23]

또 백엔드에서는 작은 회사일수록 DB 통신, DB 설계까지 개발자가 해야 하는 경우가 많고, 큰 회사에는 DBA가 따로 있는 경우도 있다고 설명한다.[^24][^25] 따라서 초보/비전공자 관점에서는 “백엔드 자체도 공부할 게 많은데 DB까지 하니 힘들 것”이라고 난이도를 체감할 포인트를 짚어준다.[^26] 여기에 서버 관점(부하/과부하 등 성능/운영 관점도 포함)을 알아야 한다고 말한다.[^27]

[!IMPORTANT] 백엔드를 “서버에서 동작하는 부분”으로 정의
프론트엔드는 “웹브라우저에서 동작”, 백엔드는 “웹브라우저 이전에 서버에서 동작”이라고 구분해 설명한다.[^28]

[^1]: @[22:52] “테스트 페이지 하나 만들어… php” [^2]: @[24:07] “페이지 소스 보기 하면 abcd 밖에 없어요… 신기하죠” [^3]: @[24:23] “프론트엔드… 앞쪽… 백엔드… 뒤쪽” [^4]: @[24:46] “개인정보… db 접속 id 패스워드… 서버에서 검증” [^5]: @[25:01] “줄 수 있는 소스와 주지 못한 소스가 나뉘어져” [^6]: @[25:15] “php를 선택했을 뿐… jsp… 파이썬… 스위프트… c로도” [^7]: @[25:46] “보통 자바 많이 쓰고… php 의외로 많이” [^8]: @[26:46] “php는 하등… 그런 소리 하는 사람들… 언어의 열등/하등한 거 없어요” [^9]: @[26:01] “교육자는 잘 모르는데 함부로 떠들면 안 돼요… 책임” [^10]: @[26:17] “php 문법 쉬워… 점유율 높아… 페이스북/트위터도 시작은 php” [^11]: @[26:03] “w3 스쿨에서도 php를 상당히 중요…” [^12]: @[27:10] “각자 목적이 다르거든요” [^13]: @[29:38] “망치… 칼… 목적이 다른 언어” [^14]: @[30:03] “홈페이지… 만든 의도 정도만 읽어봤어도…” [^15]: @[28:10] “파이썬 느려요” + @[28:31] “인공지능/데이터마이닝… 파이썬… 라이브러리 엄청” [^16]: @[28:38] “php… 확장… 역사적인 라이브러리… 튜닝 장점… 공유/확장 난해” [^17]: @[29:08] “자바… 문법 규칙 엄격” [^18]: @[29:22] “진짜 잘하는 개발자… 장단장 두고… 때에 따라 쓰는 거지” [^19]: @[31:36] “백엔드… 보안적 관점도 신경” [^20]: @[31:42] “보안 컨설팅… 아주 기본적인 웹 보안은” [^21]: @[31:50] “owasp… 최신 유행 10가지 정도는 막을 줄” [^22]: @[32:03] “sql 인젝션… 잘하는 사람은 장난 아니야” [^23]: @[32:14] “해커… 게임하듯… 중독… 즐기는 사람을 이기기 힘들어” [^24]: @[36:59] “DB 통신… DB 설계… 작은 회사에서 해야” [^25]: @[37:21] “큰 회사엔 dba 따로… 대기업은 애초에 다 나뉘어” [^26]: @[38:06] “백엔드 자체도 공부할게 많은데… 그것까지 하니까 힘들” [^27]: @[38:13] “서버 관점에서 과부하 관점도” [^28]: @[31:13] “프론트=웹브라우저에서 동작… 백=서버에서 동작”

3.8 프론트 vs 백: 돈/난이도 비교 질문에 대한 답, 그리고 ‘게임 개발’ 비유[^31]

화자는 사람들이 가장 궁금해할 질문을 먼저 꺼낸다.[^1]

[? 질문] 프론트엔드와 백엔드 중 뭐가 더 돈이 되고, 뭐가 더 힘드냐[^1]
[= 답] 단순 비교/점수 매기기가 어렵다. 양쪽 다 깊게 들어가면 끝이 없고 너무 어렵다.[^1][^2]

화자는 프론트/백의 구분이 웹에서만의 독특한 개념처럼 보이지만, 사실 “개념적으로”는 다른 개발 영역에도 적용될 수 있다고 말한다.[^3] 예로 게임 개발을 든다.[^4]

• 사용자에게 친숙한 앞단(그래픽/UI 쪽)을 “프론트엔드”로 볼 수 있고(예: 게임 클라이언트 개발자),[^4]
• 서버 통신/온라인 게임 서버 쪽을 “백엔드”로 볼 수 있다(게임 서버 개발자).[^5]

즉 프론트/백은 ‘웹 전용’ 용어처럼 쓰이지만, 본질은 사용자와 가까운가(클라이언트) vs **뒤에서 받쳐주는가(서버)**라는 추상 개념이라는 설명이다.[^3][^4]

[^1]: @[31:18] “뭐가 돈이 되냐… 뭐가 더 힘든 야… 점수 매기가 힘들어요” [^2]: @[31:30] “양쪽다… 깊게 들어가면 끝이 없어요” [^3]: @[33:22] “웹… 프론트엔드 개발자… 추상적인 개념” [^4]: @[33:35] “게임 개발자도 프론트/백으로… 게임 클라이언트 개발자” [^5]: @[34:01] “게임 서버 개발자… 백엔드… 서버 개발자”

3.9 커리어 선택 조언: “포괄적으로 공부한 뒤 특화”, 작은 회사일수록 더 넓게 한다[^38]

화자는 퍼블리셔/프론트/백을 개인적으로 추천하는 관점도 제시한다.

• 사용자 관점에서 역동적 UI, 화려한 인터랙션, 렉 없이 잘 도는 소스, 프론트에 흥미가 있으면 프론트엔드를 집중하는 것이 나쁘지 않다.[^1]
• 프론트엔드도 연봉이 꽤 괜찮은 편이며, 영어가 되고 프로젝트를 매우 잘하면 실리콘밸리로 가라는 식의 강한 수요 이야기도 덧붙인다.[^2] “개발자들이 너무 없다”는 표현으로 인력 부족을 강조한다.[^3]

동시에 백엔드는 DB/보안/서버 관점까지 포괄해 힘들 수 있지만, 익숙해지면 “제대로 해놔서 나쁠 게 없다”는 방향으로 말한다.[^4]

화자는 본인이 “엘리트 아니면 양성하지 않는다”는 표현으로, 어중간한 수준이 아니라 제대로 하자는 메시지를 강하게 드러낸다.[^5] 그래서 처음부터 “나는 퍼블리싱 안 갈 거야/프론트 안 할 거야/백만 할 거야”라고 좁히기보다, 연관이 깊고 회사 규모가 작으면 3개를 다 하기도 하니 포괄적으로 공부한 다음 두드려 맞으며(?) 성장하는 게 낫다는 식으로 말한다.[^6]

특히 대기업은 역할이 나뉘지만, 그럼에도 기초를 알아야 소통이 가능하고, 모르면 서로 피곤해지고 답답해진다고 말한다.[^7] 모를수록 힘든 영역이라 “실력으로 깔아야” 한다는 다소 직설적인 표현도 이어진다.[^8]

또한 온라인에서 “연봉이 불가(말이 안 된다)” 같은 말을 하는 사람들을 “잘 모르니까 그런다”는 뉘앙스로 비판하면서, 잘하는 사람은 신입이든 뭐든 상관없이 “많이 줄 테니 와라” 하는 회사가 많다고 말한다.[^9] 결국 문제는 회사가 원하는 수준의 사람을 “맞추기 힘들다”는 것, 그래서 코치/교육이 필요하다는 결론 쪽으로 연결된다.[^10]

[^1]: @[34:29] 프론트엔드 추천 조건(역동적/UI/렉 없이/사용자 관점) [^2]: @[34:51] “연봉… 꽤 괜찮… 영어… 실리콘벨리 가세요” [^3]: @[35:03] “개발자들이 너무 없대요” [^4]: @[38:18] “힘들 수 있다… 익숙해지면… 나쁠 거 없” [^5]: @[38:42] “엘리트 아니면 양성을 안하기 때문에…” [^6]: @[39:03] “포괄적으로 공부… 처음부터… 하나 빼고… 연방 관계” [^7]: @[39:50] “소통… 잘 모르면 서로 피곤… 답답” [^8]: @[40:01] “모르면 모를수록 힘든 영역… 실력 바로 깔아야” [^9]: @[40:27] “온라인… 연봉이 불가… 잘 모르니까… 잘하는 사람들은… 많이 줄 테니까 와라” [^10]: @[40:42] “사람이 원하는 게 뭔지 맞추는게 힘든… 코치 필요”

3.10 학습/스택 조언: Node.js, Java/PHP/Python, 그리고 “수요 많은 것 선택”[^43]

화자는 마지막에 웹개발을 하려는 사람에게 스택 선택 감각을 정리해준다.[^1]

• 프론트엔드는 자바스크립트를 많이 쓰며, 자바스크립트를 그대로 백엔드에서도 쓰게 해주는 Node.js가 있으니 프론트를 공부하면서 Node.js를 보는 것도 괜찮다고 말한다.[^2]
• 장기적 비전 관점에서는 Java도 괜찮고, PHP도 괜찮고, Python도 괜찮다고 말한다.[^3]
• 새로운 걸 하고 싶다면 Go, Swift 등으로 웹 개발을 하는 것도 가능하다고 언급한다.[^4]

하지만 현실적인 조언으로 [h 웬만하면 수요 많은 걸 선택하라]고 강조한다.[^5] 국비에서 많이 배우는 JSP/스프링 같은 선택을 “그렇게 나쁜 생각은 아니다”라고 말하면서도, 쉽게 배울 거면 PHP나 Python이 “만만한” 편이라고 개인적 인상을 말한다.[^6]

그리고 언어는 금방 습득하니 “언어에 너무 중점 두지 말고”, 자신이 예전에 추천한 축(php나 python)을 참고하라고 한다.[^7]

프론트 쪽 학습 순서로는:

• 자바스크립트를 먼저 익숙해져라.[^8]
• 그 다음 의존 라이브러리/다양한 스크립트(예: 제이쿼리, 커피스크립트 등 “스크립트가 진짜 많다”)를 보라고 말한다.[^9]
• 퍼블리셔 영역은 HTML/CSS가 공통이므로 그것도 공부해야 한다고 덧붙인다.[^10]

화자는 자신이 10분 정도 설명한 것 같은데 시간이 45~46분이 지나 놀랍다고 말하며(말이 많아서/집중해서), 질문은 댓글로 달면 돕겠다고 마무리한다.[^11][^12]

[^1]: @[43:01] “플랫폼 추천…” [^2]: @[43:01] “node js… 자바스크립트 그대로 사용할 수 있게” [^3]: @[43:26] “장기적인 비전… 자바도 괜찮고 php도 괜찮고 파이썬도” [^4]: @[43:47] “고… 스위프트…” [^5]: @[43:59] “웬만하면 수요 많은거 선택하세요” [^6]: @[44:04] “jsp/스프링… 나쁜 생각 안 해요” + @[44:17] “쉽게 배울 거면 php나 파이썬… 만만” [^7]: @[44:22] “언어… 금방 습득… 너무 중점 두지 마시고” [^8]: @[45:00] “자바스크립트… 먼저 익숙해 지시는 걸” [^9]: @[45:09] “커피스크립트… 스크립트가 진짜 많…” [^10]: @[45:19] “퍼블리셔… html… 스타일시트…” [^11]: @[45:40] “10분도 설명한 것 같은데… 45분… 신기” [^12]: @[46:22] “질문 있으시면 댓글… 도와드릴께요”

4. 핵심 통찰[^1]

1. [h 웹개발을 ‘문서 만들기’로 잡으면 프론트/백/퍼블리셔의 경계가 더 명확해진다]—브라우저가 해석하는 문서(HTML/CSS/JS)와 서버에서 문서를 생성·검증하는 로직을 분리해 생각하게 된다.[^2][^6]

   • 실행: “화려함” 대신 “브라우저 해석 결과물” 관점으로 웹페이지를 분석해보라(소스 보기/개발자도구 습관).[^^3]

2. [h ‘직무가 존재한다’와 ‘그 직무를 단독으로 채용할 시장이 크다’는 다르다]—퍼블리셔처럼 분업 직무는 웹에 특화된 조직에서 더 잘 분리되며, 작은 회사에서는 뭉뚱그려 채용되는 경우가 많다.[^15][^16]

3. [c 프론트·백 모두 깊게 들어가면 끝이 없고, 어느 쪽이 더 쉽다고 단정하기 어렵다]—따라서 “돈/난이도” 단순 비교 대신, 관심사(사용자 경험 vs 데이터/검증/보안/서버)를 기준으로 접근하라는 메시지다.[^31][^34]

   • 실행: 둘 다 찍먹해보고(간단한 UI 인터랙션 + 간단한 CRUD/인증) 흥미가 더 붙는 쪽을 특화하라.[^46]

4. [h 언어 서열화는 무지에서 나오는 경우가 많다]—언어는 목적이 다르고, 도구처럼 상황에 맞게 선택해야 한다(망치/칼 비유).[^29][^27]

   • 실행: 기술 선택 때 “왜 만들어졌는지(탄생 목적) + 어떤 문제를 잘 푸는지”를 먼저 조사하라.[^30]

5. [h 백엔드의 실전 난이도는 ‘보안·DB·서버 운영 관점’이 겹치면서 상승한다]—OWASP Top 10 같은 최소 방어선, SQL 인젝션 등 공격 벡터에 대한 이해가 필요하다는 경고가 포함된다.[^31][^32]

[^1]: @[40:48] “정리를 한번 할게요” [^2]: @[04:13] “문서를 만드는 사람” [^6]: @[24:46] “db 접속 id 패스워드… 서버에서 검증” [^15]: @[13:59] “작은 기업… 퍼블리셔 따로 뽑기 드물” [^16]: @[14:11] “뭉뚱그려서 돕는 케이스” [^31]: @[31:30] “양쪽 다 깊게 들어가면 끝이 없” [^34]: @[34:29] 프론트엔드 적성 기준(역동/UI/사용자 관점) [^29]: @[29:38] “망치… 칼… 목적” [^30]: @[30:03] “만든 의도…” [^32]: @[31:50] “owasp… 10가지… 막을 줄” [^46]: @[46:03] “양쪽 다 해보시고 하나의 특화”

5. 헷갈리는 용어 정리[^9]

웹(WWW / World Wide Web): 전 세계적으로 연결된 정보(문서)를 하이퍼링크/프로토콜로 공유·열람하는 체계. 화자는 “웹=문서 공유에서 출발”로 설명한다.[^2]
웹페이지: 네이버/구글 같은 사이트에서 브라우저로 보는 “한 페이지(문서)” 단위의 결과물.[^2]
파편화: 브라우저/버전/기기(모바일 포함)마다 HTML 태그 해석/렌더링이 달라 동일 사이트가 다르게 보이는 현상.[^3]
웹표준: 브라우저들이 “비슷하게 해석”하도록 권고되는 기술 기준/규격(강제성은 약할 수 있음).[^4][^8]
W3C: 웹표준 등 웹 기술 규격을 정하는 단체로 언급됨.[^5]
웹퍼블리셔: 브라우저/기기별 표현 차이를 줄이고(표준/호환성) HTML/CSS 중심으로 UI를 구현·정리하는 역할로 설명됨.[^19][^20]
프론트엔드: 사용자에게 보이는 앞단. 브라우저에서 실행되는 JavaScript 등으로 상호작용/동적 UI를 구현.[^3][^6]
백엔드: 사용자에게 노출되면 안 되는 뒷단. 서버에서 실행되며 검증, 개인정보/DB접속 정보 보호, DB 연동, 보안 등을 담당.[^4][^28]
DBA: 데이터베이스에 특화된 관리자/엔지니어 역할. 큰 회사에서는 분업으로 존재할 수 있다고 설명.[^25]
OWASP: 웹 보안 취약점 트렌드(Top 10 등)를 리포팅해 주는 곳으로 언급.[^21]
SQL 인젝션: 입력값을 악용해 SQL을 조작하는 대표적 공격. 쉬워 보이지만 깊게 들어가면 매우 어렵다고 언급.[^22]
Node.js: 자바스크립트를 백엔드에서도 실행 가능하게 해주는 런타임으로 소개.[^2]

[^2]: @[02:09] “웹페이지… 단순 문서…” [^3]: @[09:29] “모바일도… 파편화” [^4]: @[09:44] “웹표준” [^5]: @[09:56] “w3c” [^8]: @[11:15] “강제성 없으니까 힘들” [^19]: @[15:21] “html… 스타일시트” [^20]: @[13:11] “표준도 잘 맞추고” [^21]: @[31:50] “owasp…” [^22]: @[32:03] “sql 인젝션…” [^25]: @[37:21] “dba…” [^28]: @[31:13] “프론트=브라우저… 백=서버” [^2]: @[43:01] “node js…”

---

참고(콘텐츠 정보)[^1]

• 제목: 웹개발자의 종류와 해석. 프론트 앤드(front end), 백엔드(back end) 개발자란?[^1]
• 채널: 팀노바[^1]
• 길이: 46분 31초[^1]
• 링크: https://www.youtube.com/watch?v=ULWtha1Gwio[^1]
• 키워드(제공): 코딩, 코딩학원, 팀노바, 개발자, 교육기관, 소프트웨어, 인공지능, 컴퓨터프로그래머, 프로그래머, 컴퓨터학원[^1]

[^1]: 사용자 제공 메타데이터 및 원문 전체(YouTube: TeamNova, “웹개발자의 종류와 해석…”, 46:31)