프로젝트에서 보기 →

프론트엔드 백엔드 개발자는 무슨일을 하나요?

태그
기타 백엔드 개발자 프론트엔드 개발자 백엔드개발자
시작일
종료일
수정일

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

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

[? 질문] 프론트엔드 개발자와 백엔드(서버) 개발자는 각각 무슨 일을 하는가[^2]
[= 답] 프론트엔드는 디자이너 산출물(웹/앱 화면)을 **HTML/CSS/JS(또는 모바일 클라이언트 기술)**로 구현해 사용자가 보는 화면과 상호작용을 만든다.[^6] 백엔드는 서버 언어와 데이터베이스를 다루며 데이터를 저장·관리하고, 이를 활용해 **API(클라이언트가 호출하는 기능/데이터 인터페이스)**를 만들어 프론트/클라이언트에 제공한다.[^11]

[? 질문] 실무에서 프론트/백이 나뉘는 기준(조직/팀 구성)은 무엇인가[^7]
[= 답] 팀 이름과 역할에서 흔히 드러난다: 웹 개발팀/클라이언트 개발팀은 프론트엔드 성격이 강하고, 서버 개발팀/서버 기술팀/인프라 개발팀/DB팀 등은 백엔드(서버) 성격으로 보는 경우가 많다.[^7]

[? 질문] 나는 프론트엔드와 백엔드 중 무엇이 더 맞을까[^18]
[= 답] 결국은 직접 해봐야 알 수 있으며, 보통 졸업작품·개인/팀 프로젝트처럼 “처음엔 다 해보는 과정”에서 강점과 성향 차이가 드러난다.[^19] 성향 힌트로는 디테일·꼼꼼함을 즐기면 프론트엔드, **큰 그림(데이터/업무 흐름)**을 보는 것을 선호하면 백엔드가 더 맞을 수 있다고 제시한다.[^22]

2. 큰 그림[^3]

이 콘텐츠는 취업 준비나 진로 선택 단계에서 자주 듣는 프론트엔드 개발자, 백엔드(서버) 개발자, 그리고 둘을 아우르는 풀스택이 “정확히 무슨 일을 하는지”를 모르는 사람을 위해, 역할·팀 구성·성향 차이·선택 방법을 순서대로 설명한다.[^3] 또한 실무에서의 스트레스 포인트(성능, 대용량 데이터)나 배포 사이클 같은 차이도 짚어, 단순 정의를 넘어 “일의 결이 어떻게 다른지”를 감 잡게 하는 것이 목적이다.[^22]

  • 프론트엔드는 디자인 산출물을 바탕으로 웹/앱 화면을 구현하는 역할이며, 작은 차이(픽셀/색상/동작)까지 맞추는 디테일 역량이 중요하다고 말한다.[^20]
  • 백엔드는 서버 언어·데이터베이스·API 중심으로 데이터 흐름과 업무 흐름을 설계/구현하는 역할이며, 서비스에 큰 영향을 주는 **데이터 적재·활용 관점(큰 그림)**이 중요하다고 말한다.[^21]
  • 진로 선택은 “이론적 설명”만으로 끝나지 않고, 직접 프로젝트로 경험해 보면서 나에게 쉬운/어려운 파트가 무엇인지로 판단하라고 강조한다.[^19]

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

3.1 왜 이 주제를 이야기하나: 취업 전에 ‘내가 할 일’을 알고 시작하자는 문제의식[^4]

📸 0:11

화자는 영상 초반, 프론트엔드/백엔드/풀스택 같은 용어를 많이 들어봤지만 “정작 무슨 일을 하는지 잘 모르는 상태”로 취업 전선에 뛰어들었던 자신의 경험을 꺼낸다.[^4] 본인도 당시에는 “이게 뭔 얘기인지도 모르고” 취업을 준비했다고 말하며, 그래서 요즘 취업을 준비하는 사람들은 나중에 무슨 일을 하게 될지를 좀 더 정확히 알고 출발하는 게 좋겠다는 생각을 밝힌다.[^5]

이 문제의식 위에서 오늘 다룰 구성(목차)을 제시한다.[^6]

  • 프론트엔드 개발자란 무엇인지[^6]
  • 백엔드 개발자란 무엇인지[^6]
  • 프론트/백으로 나뉘는 기준은 무엇인지(조직/팀 관점 포함)[^6]
  • 마지막으로 “나는 어떤 게 잘 맞는지” 선택 관점[^18]

즉, 이 영상은 “한 문장 정의”로 끝내는 게 아니라, 실제 일을 상상할 수 있게 만드는 설명과 선택 조언까지 포함하려는 구조로 진행된다.[^6]

3.2 프론트엔드 개발자: 디자이너 산출물을 웹/앱 화면으로 구현하는 사람[^6]

📸 0:40

화자는 프론트엔드 개발자를, 디자이너가 만든 화면 설계/시안 산출물을 기반으로 실제 서비스 화면을 만들어내는 역할로 설명한다.[^6] 예시로 예전에는 디자이너 산출물이 보통 PSD(포토샵 파일) 형태였고, 요즘 모바일 쪽에서는 Sketch(스케치) 같은 도구를 쓰는 경우도 많다고 언급한다.[^6]

웹에서의 프론트엔드: HTML/CSS/JavaScript로 페이지 구현[^6]

웹 환경에서는 다음 기술들을 “무기”로 삼아 페이지를 만들어내는 사람들이 프론트엔드라고 말한다.[^6]

  • HTML
  • CSS
  • JavaScript

즉, 사용자가 브라우저에서 보는 화면을 구조화하고(HTML), 꾸미고(CSS), 동작하게 만들며(JS), 사용자 상호작용을 처리하는 영역이 프론트엔드라는 관점이다.[^6]

모바일에서의 프론트엔드(클라이언트): Android/iOS 등 앱 클라이언트 개발[^7]

모바일 환경에서는 프론트엔드 범주가 웹만이 아니라, 안드로이드 개발자, iOS 개발자, 즉 “클라이언트 개발자”도 프론트엔드로 분류될 수 있다고 설명한다.[^7] 여기서 화자의 기준은 “사용자 단말에서 실행되는 화면/클라이언트 구현”을 프론트엔드로 보는 실무적 분류다.[^7]

팀 이름으로도 역할 성격이 드러난다: 웹 개발팀/클라이언트 개발팀[^7]

화자는 조직에서 팀 이름을 보면 대략 역할을 유추할 수 있다고 말한다.[^7] 예로:

  • 웹 개발팀
  • 클라이언트 개발팀

이렇게 구성되어 있으면 “보통 프론트엔드 개발 그룹”으로 생각하면 된다고 한다.[^7]

3.3 백엔드(서버) 개발자: 데이터 저장/관리와 API 제공을 담당[^8]

📸 1:13

프론트엔드 팀 이름 예시를 든 뒤, “반면에” 백엔드 개발자는 어떤 팀명으로 불리는지 연결해서 설명한다.[^8]

팀 이름 예시: 서버 개발팀/서버 기술팀/인프라 개발팀/DB팀[^8]

백엔드 개발자는 조직에서 다음 같은 이름을 가진 팀에 속해 있는 경우가 많다고 한다.[^8]

  • 서버 개발팀(가장 흔히 쓰는 것 같다고 언급)[^8]
  • 서버 기술팀[^8]
  • 인프라 개발팀[^8]
  • DB팀도 서버 쪽으로 묶이는 경우가 있다고 덧붙임[^8]

이런 이름의 팀들은 “보통 백엔드 개발자”라고 보면 되겠다고 정리한다.[^8]

서버(백엔드) 개발에서 사용하는 언어 예시[^9]

서버 개발자(백엔드 개발자)가 주로 사용하는 언어/프레임워크 예시로 다음을 나열한다.[^9]

  • Java / Spring
  • Ruby on Rails
  • PHP
  • Node.js(가능한 선택지로 언급)

즉, 웹/서비스에서 “서버 측 로직”을 구현하는 생태계가 프론트와는 다르다는 점을, 기술 스택 예시로 감각적으로 보여준다.[^9]

백엔드의 핵심 작업: DB 적재/관리 + 활용 가능한 SQL + API로 제공[^10]

화자는 백엔드가 하는 일을 조금 더 구체적으로 풀어 말한다.[^10]

  • 여러 서버 언어를 사용하면서[^10]
  • 데이터베이스에 데이터를 적재하고 관리하며[^10]
  • 데이터를 통해 “활용 가능한 SQL”을 만들고[^10]
  • API를 만들어서[^10]
  • 클라이언트 개발자/프론트엔드 개발자에게 제공하는 일을 한다[^10]

즉, 프론트엔드가 “화면 구현”에 가깝다면, 백엔드는 “데이터가 쌓이고 돌고 제공되는 구조”를 만들며, 프론트는 그 API를 호출해 화면을 구성하는 협업 그림이 암묵적으로 제시된다.[^10]

[!NOTE] API를 왜 강조하나
화자는 백엔드의 산출물이 “클라이언트/프론트엔드에게 제공하는 API”라고 표현한다.[^10] 이는 실무에서 프론트-백 협업의 접점이 주로 API 명세/응답 구조로 형성된다는 현실을 반영한 설명 방식이다.[^10]

3.4 풀스택: 프론트와 백을 ‘둘 다 믹스해서’ 할 수 있는 사람[^11]

📸 1:53

프론트와 백을 모두 할 수 있는 “슈퍼 짱짱맨” 같은 사람들을 풀스택 개발자로 부른다고 설명한다.[^11] 즉, 풀스택은 별도의 완전히 다른 직군이라기보다, 앞서 말한 프론트 작업과 백 작업을 둘 다 수행 가능한 역량 범주로 제시된다.[^11]

3.5 “다 잘해야만 일할 수 있다?” → 실제로는 분업화되어 프론트/백으로 나뉜다[^12]

📸 2:01

화자는 많은 초보/준비생들이 “내가 모든 걸 다 잘해야지만 뭔가 일을 할 수 있을 것 같다”고 느끼지만, 실제로는 각 팀에 소속되어 분업화된 일을 하기 때문에 보통은 프론트엔드 개발자와 백엔드 개발자 “이 둘로 나뉘게 된다”고 말한다.[^12]

여기서 메시지는 다음과 같이 정리된다.

  • “다 할 줄 알아야 취업/실무가 된다”는 불안이 흔하지만[^12]
  • 실무는 팀 단위로 역할이 쪼개져 있고[^12]
  • 그래서 직무도 프론트/백으로 분화되는 게 일반적이다[^12]

3.6 프론트 성향: 디테일·꼼꼼함, ‘1픽셀’과 ‘색상 차이’를 잡아내는 세계[^13]

📸 2:13

화자는 프론트엔드와 백엔드가 “처음 시작부터 완전히 다른 것”은 아니지만, 성향이 약간 다르게 되어 있다고 말하며 본인이 두 가지를 다 경험해 봤다고 전제한다.[^13]

프론트엔드 개발자의 성향을 설명할 때 핵심은 꼼꼼함과 디테일이다.[^13] 그 이유로 “디자이너 분들이 좀 그렇다”는 실무 에피소드를 예시로 든다.[^14]

디자이너와의 협업에서 요구되는 정밀함: 1픽셀, 색상 차이[^14]

화자는 디자이너들이 “정말 신기하게도 1픽셀만 살짝 어긋나도 다 안다”고 말한다.[^14] 개발자 입장에서는 “같은 빨간색”처럼 보여도 디자이너는 “이 컬러 아닙니다”라고 정확히 짚어내는 식의 상황을 묘사한다.[^14]

즉, 프론트엔드 개발자는 다음을 맞춰야 한다는 뉘앙스로 설명된다.

  • 픽셀 단위 정렬/간격의 정확성[^14]
  • 색상/스타일 가이드의 정확한 재현[^14]
  • 디자이너가 의도한 결과물과 “똑같이” 구현하는 능력[^15]

화면 요소의 “움직임”까지 구현: 디자이너가 표현하는 언어를 코드로 번역[^15]

화자는 단순히 정적인 화면만이 아니라, 버튼/컴포넌트 등 “움직이는 것들”의 표현도 중요하다고 말한다.[^15] 그리고 디자이너들이 표현하는 “수많은 언어들(요구/표현 방식)”이 있으며, 이를 완벽하게 만들어 낼 수 있는 성향/역량이 필요하다고 정리한다.[^15]

[!IMPORTANT] 프론트엔드에서 화자가 강조하는 역량의 결
“디자이너 산출물을 똑같이 만든다”는 표현으로, 프론트엔드의 품질 기준이 종종 시각적/상호작용적 동일성(pixel-perfect, motion fidelity)에 의해 결정되는 현실을 강조한다.[^15]

3.7 서버(백엔드) 성향: 전체 데이터 흐름·업무 흐름을 보는 ‘큰 그림’[^16]

📸 3:08

프론트엔드의 디테일 중심 성향과 대비해, 서버 개발자(백엔드)는 “하나하나의 동작도 중요하지만” 그보다 전체 데이터의 흐름과 업무의 흐름을 아는 것이 굉장히 중요하다고 말한다.[^16]

DB 관점: 데이터를 어떻게 적재하고 어떻게 활용하느냐가 서비스에 큰 영향[^17]

화자는 데이터베이스를 배웠다면 떠올릴 만한 내용이라며, 데이터를 어떻게 적재하는지, 어떻게 활용하는지가 많은 서비스의 “큰 영향”을 준다고 설명한다.[^17] 그래서 백엔드에서는:

  • 큰 그림을 이해하고[^17]
  • 데이터를 적절히 활용하는 안목이 필요하다[^17]

라는 결론으로 이어진다.[^17]

3.8 그래서 나는 무엇을 해야 하나: 결론은 “해봐야 한다”[^18]

📸 3:29

프론트와 백이 있다는 것을 알았으니 “그럼 나는 무슨 일을 해야 될까요”, “어떻게 다른 게 잘 맞을까요”라는 질문으로 전환한다.[^18]

여기서 화자의 핵심 답은 단호하다.

[? 질문] 나는 프론트/백 중 뭐가 맞을까[^18]
[= 답] 해봐야 한다. 직접 해봐야 안다.[^19]

화자는 이것을 “아까 말한 결론”이라고도 하며, 반복해서 강조한다.[^19]

3.9 ‘해보려면’ 처음엔 다 해보게 된다: 졸업작품/개인 프로젝트/팀 프로젝트 맥락[^19]

📸 3:40

“직접 해봐야 알 수 있다”를 좀 더 현실적인 과정으로 풀어 설명한다.[^19] 보통:

  • 졸업작품
  • 여러 가지 나만의 프로젝트
  • (대개) 팀 프로젝트

이런 것을 하다 보면 “처음부터 다 해봐야” 하는 상황이 온다고 말한다.[^19] 이 과정에서 역할/파트별 난이도 체감이 갈린다는 식으로 설명한다.[^20]

사람마다 ‘쉬운 파트/어려운 파트’가 갈린다[^20]

팀 프로젝트를 하면,

  • 나는 너무 괜찮은데 친구들은 어려워하는 파트가 있을 수 있고[^20]
  • 반대로 나는 쉬운데 남들은 어려워하거나[^20]
  • 또는 나는 어려운데 다른 사람은 쉽게 하기도 한다[^20]

이런 식으로 사람마다 성향이 나뉘는 부분이 분명히 있다고 말한다.[^20] 그리고 이런 경험을 할 때 자신의 성향을 더 쉽게 파악할 수 있다고 조언한다.[^20]

3.10 그래도 감이 안 오면: 성향 체크로 접근 (디테일 vs 큰 그림)[^22]

📸 4:19

프로젝트를 해봐도 잘 모르겠다면, 성향 관점에서 힌트를 준다.[^22]

  • 좀 더 디테일하고 꼼꼼하게 작업하는 걸 좋아하면 프론트엔드가 잘 맞을 수 있다[^22]
  • 좀 더 큰 그림을 보길 좋아하는 사람은 **서버(백엔드)**가 잘 맞을 수 있다[^22]

다만 화자는 “모든 개발이 하하 어렵고” 고도화될수록 스트레스 받고 어려워지는 건 맞다고 전제한다.[^23] 즉, 어느 쪽이든 어렵지만, 스트레스의 성격이 다르게 온다는 뉘앙스다.[^23]

서버 쪽 스트레스 예시: 퍼포먼스, 대용량 데이터 처리의 리스크[^23]

화자는 특히 “나중에 퍼포먼스에 대한 스트레스가 많이 오는 건 서버 쪽”일 수 있다고 말한다.[^23] 그리고:

  • 대용량의 데이터를 처리한다거나[^23]
  • 그런 상황에서는 서버 쪽이 좀 더 리스키하다는 점[^23]

을 알고 있으면 좋겠다고 덧붙인다.[^23]

3.11 (모바일 맥락) 배포 사이클 차이: iOS/Android는 심사로 시간이 걸리고, 서버는 무중단 배포도 가능[^24]

📸 4:45

화자는 모바일 클라이언트 개발(안드로이드/iOS)과 서버 개발 사이에 배포(릴리즈) 사이클에서 차이가 난다고 추가로 언급한다.[^24]

  • iOS는 배포 시 심사가 있으며, “이미 진행 중인 프로젝트”라도 하루 정도는 꼭 잡아야 한다고 말한다.[^24]
  • 안드로이드도 배포에 “적어도” 시간이 든다는 식으로 언급한다.[^25]
  • 반면 서버 개발자는 무중단 배포도 가능하다고 하며, 이런 측면에서 업무 사이클이 조금 달라진다고 설명한다.[^25]

즉, 같은 “프론트 계열(모바일)”이라도 앱스토어/마켓 정책과 심사 프로세스 때문에 배포 리드타임이 생기고, 서버는 배포 전략에 따라 더 유연해질 수 있다는 현실을 포인트로 제시한다.[^24]

3.12 마무리: 겉보기엔 비슷해도, 들어오면 성향 차이가 크게 느껴진다[^26]

📸 5:12

화자는 프론트엔드 개발자와 서버(백엔드) 개발자에 대해 한번 알아봤고, 겉으로 보기에는 “크게 다른 게 뭐야”라고 느낄 수도 있지만, 실제로 이 필드 안에 들어와 보면 서버 개발자와 클라이언트(프론트) 개발자는 성향이 많이 다르다고 정리한다.[^26] 그리고 이 내용이 진로 선택에 도움이 되었으면 한다고 말하며 영상이 끝난다.[^27]

4. 핵심 통찰[^28]

  1. [h 프론트엔드와 백엔드는 ‘사용자 화면’ vs ‘데이터/서버/API’로 책임 경계가 나뉜다.] 웹은 HTML/CSS/JS로 화면을 만들고, 백엔드는 DB와 서버 언어로 데이터를 관리하며 API로 제공한다는 협업 구조를 중심으로 설명한다.[^6]
  2. [h 조직에서는 팀 이름이 역할을 암시한다.] 웹/클라이언트 개발팀은 프론트, 서버/인프라/DB 성격 팀은 백엔드인 경우가 많다는 실무적 힌트를 준다.[^7]
  3. [h 성향 차이는 ‘품질 기준’에서 온다.] 프론트는 픽셀/색상/모션 등 “눈에 보이는 동일성” 요구가 강하고, 서버는 데이터 적재·활용과 전체 흐름 이해처럼 “시스템적 큰 그림”이 핵심이라고 대비한다.[^14]
  4. [c 진로 선택의 결론은 경험 기반이다.] 결국 프로젝트에서 “내가 상대적으로 편한/잘하는 파트”가 드러나므로, 직접 해보는 것이 가장 확실한 판단 방법이라고 반복 강조한다.[^19]
  5. [m 스트레스의 결도 다르다.] 서버는 퍼포먼스와 대용량 데이터 처리에서 리스크/스트레스가 커질 수 있고, 모바일은 배포 시 심사 등으로 사이클이 달라질 수 있다고 언급한다.[^23]

실행 관점 시사점(콘텐츠가 권하는 방향을 행동으로 풀면):[^19]

  • 팀/개인 프로젝트에서 프론트와 백 파트를 일부러라도 둘 다 맡아보며, 어떤 종류의 문제(디자인 재현 vs 데이터/흐름)가 더 잘 맞는지 기록한다.[^19]
  • 디테일 작업(픽셀·색상·인터랙션)을 맞추는 과정이 즐거운지, 혹은 데이터 모델링/흐름 설계가 더 흥미로운지로 성향을 점검한다.[^22]
  • 서버 쪽을 고려한다면 성능/대용량 처리 상황에서의 부담을 미리 인지하고 학습 계획을 세운다.[^23]

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

프론트엔드 개발자: 디자이너 산출물을 기반으로 웹(HTML/CSS/JS) 또는 모바일 클라이언트(Android/iOS 등)에서 사용자가 보는 화면을 구현하는 역할로 설명된다.[^6]
백엔드 개발자(서버 개발자): 서버 언어와 데이터베이스를 사용해 데이터를 적재·관리하고, 이를 활용하는 SQL 및 클라이언트가 쓰는 API를 만들어 제공하는 역할로 설명된다.[^10]
풀스택 개발자: 프론트엔드와 백엔드 일을 “둘 다 믹스해서” 할 수 있는 사람으로 표현된다.[^11]
클라이언트 개발자: 모바일 환경에서 안드로이드/iOS처럼 사용자 단말에서 실행되는 앱을 개발하는 역할을 가리키며, 콘텐츠에서는 프론트엔드 범주로 묶어 설명한다.[^7]
API: 백엔드가 만들어 프론트/클라이언트 개발자에게 제공하는 인터페이스(기능/데이터 제공 창구)로 언급된다.[^10]
무중단 배포: 서버 개발자 쪽에서는 가능하다고 언급되는 배포 방식으로, 서비스 중단 없이 배포하는 맥락에서 등장한다.[^25]

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

  • 제목: 프론트엔드 백엔드 개발자는 무슨일을 하나요?[^30]
  • 채널: 기술기획본부[^30]
  • 길이: 5분 31초[^30]
  • 링크: https://www.youtube.com/watch?v=G7crMao49_I[^30]

[^1]: @[00:06] “오늘의 프론트엔드 개발자 … 백엔드 개발자 … 이런 얘기 많이 들어보셨죠” + 영상 전체가 직무 설명과 선택 조언으로 구성됨.
[^2]: @[00:29] “프론트엔드 개발자가 뭔지 백엔드 개발자 … 정의 … 나뉘어지는 기준 … 마지막으로 … 어떤게 잘 맞을지”
[^3]: @[00:20] “요즘 … 내가 나중에 무슨 일을 할지 정확히 알고 출발 … 좋다”
[^4]: @[00:11] “무슨 일을 하는지 잘 모를 텐데 … 취업”
[^5]: @[00:20] “정확히 알고 출발하시는 게 … 좋다”
[^6]: @[00:40]~@[00:58] “디자이너가 만든 … PSD … 스케치 … 웹의 경우 html css 자바스크립트 … 페이지를 만들어 내는 사람”
[^7]: @[00:58]~@[01:10] “모바일 … 안드로이드 … ios … 클라이언트 개발자 … 프론트엔드 … 웹 개발 팀 … 클라이언트 개발 팀”
[^8]: @[01:13]~@[01:27] “서버 개발 팀 … 서버 기술팀 인프라 … db 팀 … 이런 팀들은 보통 … 백엔드 개발자”
[^9]: @[01:31]~@[01:43] “자바 스프링 루비 … php 노드 js”
[^10]: @[01:43] “데이터베이스 … 적재하고 관리 … sql … api … 클라이언트 개발자 프론트엔드 개발자 … 제공”
[^11]: @[01:53] “둘다 믹스 … 풀스택 개발자”
[^12]: @[02:01]~@[02:13] “모든 걸 다 잘 해야 … 실제로는 … 분업화 … 보통 … 백엔드 … 프론트엔드 … 나눠”
[^13]: @[02:13]~@[02:27] “성향 … 다르게 … 프론트엔드 … 꼼꼼하고 디테일”
[^14]: @[02:30]~@[02:39] “1픽셀 … 다 아십니다 … 이 컬러 아닙니다 … 픽셀 어긋나서”
[^15]: @[02:45]~@[03:03] “디자이너가 원하는 산출물 … 똑같이 … 움직이는 것들 … 수많은 언어들 … 완벽하게”
[^16]: @[03:08] “서버 개발자들 … 전체에 데이터의 흐름과 … 업무의 흐름 … 중요”
[^17]: @[03:18] “데이터를 어떻게 적재 … 어떻게 활용 … 서비스 … 큰 영향 … 큰 그림 … 적절하게 활용”
[^18]: @[03:29]~@[03:40] “그럼 나는 무슨 일을 해야 될까요 … 어떻게 … 잘 맞을까요”
[^19]: @[03:40]~@[04:02] “해봐야 합니다 … 직접 해보셔야지 … 졸업작품 … 프로젝트 … 처음부터 다 해봐야 돼요”
[^20]: @[04:02]~@[04:15] “팀 프로젝트 … 나는 괜찮은데 친구들은 어려워 … 사람마다 성향 … 나뉘는 부분”
[^21]: @[03:18]~@[03:23] “데이터 … 적재/활용 … 서비스 … 큰 영향” (백엔드의 큰 그림 관점 근거)
[^22]: @[04:19]~@[04:28] “디테일하고 꼼꼼 … 프론트엔드 … 큰 글(큰 그림) … 서버 개발자”
[^23]: @[04:28]~@[04:45] “퍼포먼스 … 스트레스 … 서버 쪽 … 대용량 … 리스키”
[^24]: @[04:45]~@[04:51] “ios … 심사 … 하루 정도는 꼭”
[^25]: @[04:51]~@[05:00] “안드로이드도 … 시간 … 서버 개발자 … 무중단 배포 … 업무 사이클 … 달라”
[^26]: @[05:12]~@[05:20] “크게 다른게 뭐야 … 들어와서 보면 … 성향이 많이 달라요”
[^27]: @[05:20]~@[05:25] “진로 선택 … 도움이 됐으면”
[^28]: @[02:22]~@[03:23] (성향 대비), @[03:40]~@[04:02] (해봐야 한다), @[04:28]~@[05:00] (스트레스/배포) 등 영상 전반 종합.
[^29]: @[00:40]~@[01:53] (프론트/백/풀스택/클라이언트/API 정의 근거), @[04:58] (무중단 배포).
[^30]: 사용자가 제공한 메타데이터(제목/채널/길이/링크) 및 영상 링크 정보.

← 프로젝트에서 보기