https://www.youtube.com/watch?v=_WQR6-sqqjM
1. 이건 꼭 알아야 한다^1
[? 질문] 백엔드 개발은 무엇을 “시작점”으로 삼아 이해해야 하는가[^2]
[= 답] 백엔드는 서버만 떼어 외우는 게 아니라, 사용자가 쓰는 앱/웹 화면에서 버튼을 누르는 순간부터 서버 기능이 호출되고 데이터가 오가는 전체 흐름에서 출발해 이해해야 한다.[^7][^8]
[? 질문] 백엔드 개발자가 “자바/스프링을 잘한다”만으로는 왜 충분하지 않은가[^9]
[= 답] 백엔드 업무는 코드(자바/스프링)뿐 아니라 **API 스펙·프로토콜·통신·저장(데이터)·인프라(서버/클라우드/IDC)**까지 연결된 구조 위에서 동작하므로, 전체 관점(아키텍처)의 이해가 필요하다.[^11][^12][^13]
[? 질문] 앱(API 기반)과 웹(웹서버 기반)은 서버에 어떻게 “다르게” 붙는가[^21]
[= 답] 앱은 보통 화면은 단말(클라이언트)에 있고 서버와는 데이터(API 인터페이스)만 주고받는 구조로 이해하면 되고, 웹은 브라우저가 웹서버에 접속해 HTML 등 “화면을 구성하는 내용”을 내려받아 그려지는 구조로 이해하면 된다.[^22][^24][^26]
2. 큰 그림[^2]
이 콘텐츠는 백엔드 입문자가 “백엔드”를 서버 코드로만 좁게 보지 않도록, 앱/웹 클라이언트에서 서버까지 이어지는 전체 아키텍처 흐름을 먼저 잡아주는 설명이다.[^7][^12] 번역 참여한 책(“백엔드 30일”)의 1장을 소개하며, 백엔드의 시작을 “앱에서의 사용자 행동 → 서버 기능 호출”로 두는 관점을 강조한다.[^2][^7]
- 시작점은 앱(사용자 화면): 서버를 먼저 보기보다 사용자가 누르는 버튼/화면에서 어떤 요청이 발생하고 서버 기능이 어떻게 호출되는지부터 보라고 말한다.[^7][^8]
- 백엔드는 ‘전체’ 이해가 필요: 자바/스프링뿐 아니라 API, 프로토콜, 통신, DB, 인프라까지 이어진 구조를 알아야 실무 백엔드를 이해할 수 있다고 주장한다.[^11][^12]
- 앱과 웹의 접속 지점이 다르다: 앱은 주로 API 서버에, 웹은 웹서버에 붙는다는 큰 구분을 통해 시스템 구성을 한눈에 설명한다.[^20][^22][^26]
3. 하나씩 살펴보기[^2]
3.1 영상의 출발: “백엔드의 시작점”을 책 1장(앱)에서 찾다[^2]
화자는 최근 자신이 “백엔드 30일”이라는 책에 번역으로 참여했다고 밝히며, 오늘은 그 책의 첫 번째 장에서 다루는 “백엔드의 시작” 이야기를 해보겠다고 한다.[^2] 그리고 그 1장의 시작점이 “앱 이야기부터 나온다”는 점이 특히 좋았다고 평가한다.[^3][^4]
여기서 화자의 문제의식은 다음과 같다.
- 백엔드에 관심 있는 사람들은 종종 “백엔드” 자체(서버 코드/서버 기술)에만 집중한다.[^5]
- 하지만 화자는 두 가지 관점을 함께 가져가야 한다고 말한다: 첫째는 앱, 둘째는 **전체(전체 흐름/전체 아키텍처)**다.[^5][^6]
즉, 입문 단계에서 백엔드를 서버 기술 목록으로 접근하기보다, 앱에서 서버로 이어지는 사용 흐름과 그 흐름을 떠받치는 전체 구조를 함께 보라는 방향을 제시한다.[^6][^8]
3.2 “프론트엔드/백엔드”는 나뉘지만, 백엔드는 단독으로 존재하지 않는다[^6]
화자는 “엔드라 해서 백엔드만 존재하는 것이 아니다”라고 말하며, 어느 순간부터 업계에서 프론트엔드/백엔드라는 표현을 쓰기 시작했음을 언급한다.[^6][^7] 이 말의 의도는 “백엔드만 떼어서 완결된 무언가로 착각하지 말라”는 쪽에 가깝다.[^6][^10]
이어 프론트/백을 매우 실무적인 방식으로 구분한다.
- 프론트엔드: “화면 위주”, “단말(클라이언트) 위주의 개발”이라는 감각으로 구분한다.[^8]
- 백엔드: “서버 사이드”, 즉 서버 측에서 처리되는 것들을 통칭한다.[^8]
그리고 백엔드(서버 측) 안에 포함되는 범위를 다음처럼 확장해서 말한다.
- 서버의 대표 예시는 API 서버다.[^9]
- 하지만 백엔드는 API 서버 “뿐만 아니라” 데이터(저장) 관련도 포함되고,[^9]
- 통신이 되려면 인프라 관점(서버가 어디에 있고 어떻게 운영되는가 같은 관점)도 포함된다고 설명한다.[^10]
[!IMPORTANT] “백엔드 = API 서버 코드”로만 축소하지 말라는 경고
화자는 백엔드를 “프론트와 통신하는 상황에서 서버를 다 표현한다”고 말하며, 그 안에는 API, 데이터 저장, 인프라까지 자연스럽게 포함된다고 선을 긋는다.[^11][^10]
3.3 왜 ‘앱 이야기부터’ 시작하는가: 사용자 화면에서 서버 호출까지의 흐름을 잡기 위해[^7]
화자는 “앱의 얘기부터 시작된다”는 의미를 “전체 흐름을 안다”는 관점으로 풀어 설명한다.[^7]
구체적으로 화자가 말하는 “흐름”은 이런 장면이다.
- 앱에서 어떤 화면이 있고,[^8]
- 그 화면에서 버튼이 눌리면, 어떤 이벤트/행동이 발생하고,[^8]
- 그로 인해 서버의 어떤 기능이 호출되는 상황이 생긴다.[^8]
이 설명의 핵심은 “서버 기능”을 공중에 띄운 채로 배우는 게 아니라, 사용자가 실제로 보고 누르는 화면에서 출발해 서버 호출을 이해해야 한다는 것이다.[^8]
즉, 백엔드 입문자가 처음부터 “서버 내부 구현(프레임워크/언어)”로 들어가면 전체 그림을 놓치기 쉬운데, 앱 화면 → 서버 호출로 잡으면 백엔드가 왜 필요하고 무엇을 하는지 맥락이 생긴다는 취지다.[^7][^8]
3.4 백엔드 개발자는 “전체 아키텍처 관점”에서 흐름을 알아야 한다[^9]
화자는 “오늘 또 하나”의 주제로 전체 아키텍처 관점을 꺼내며, 백엔드 개발자는 “뭐가 어떻게 흘러가는지도 잘 알아야” 한다고 말한다.[^9]
여기서 화자는 흔히 백엔드 입문자/주니어가 갖는 생각을 인정한다.
- 자바나 스프링은 “너무 중요”하다.[^10]
- 백엔드 개발자가 “주로 하는 일”이기 때문에 “당연히 잘 알아야” 한다.[^10]
하지만 그 다음 문장이 오늘 메시지를 결정한다.
- “당연히 잘 알아야 되지만 이거만 안다고 다 되는 것은 아니다”라고 못 박는다.[^11]
그리고 “이것만으로는 부족한 이유”를 구성 요소 단위로 열거한다.
- API 스펙도 알아야 하고,[^12]
- API가 **어떻게 호출되는지(호출 방식/프로토콜)**도 알아야 하고,[^12]
- 그러다 보면 통신 단(통신 계층/네트워크 관점)도 알아야 하며,[^12]
- 뒤에 **저장되는 DB(데이터베이스)**도 알아야 한다.[^12]
이런 나열을 통해 화자는 결론적으로 “전체 관점에서의 이해도가 필요하다”에 동의한다고 말하고, 그 결과 “아키텍처도 알아야 된다”로 이어간다.[^13]
[c 백엔드 역량을 ‘프레임워크 숙련’으로만 정의하면 실무의 절반을 놓친다]
화자의 논리는 “자바/스프링(구현)”은 필요조건이지만, 실제 서비스는 API·통신·DB·인프라가 묶인 시스템이므로 전체를 함께 이해해야 한다는 구조다.[^11][^12]
3.5 “백엔드가 알아야 할 아키텍처” 그림을 놓고 흐름으로 설명하기[^14]
화자는 지금부터 “백엔드가 알아야 되는 아키텍처”를 설명하겠다고 하고, 잠깐 화면(그림)을 보면서 설명하겠다고 한다.[^14]
다만 곧바로 다음과 같은 한계를 언급한다.
- 그림의 구성 요소만 이해해도 “상당히 수준이 높은 것”처럼 보일 수 있다.[^15]
- 이 자리에서 “아주 자세한 얘기”를 다 하기 어렵다.[^15]
- 나중에 강의를 만들게 되면 “하나하나 자세히 설명”하는 시간을 가져보겠다고 한다.[^15]
그래서 오늘은 목적을 “대략적으로, 딱 보고 흐름이 보이게 정리”하는 것으로 설정한다.[^16] 즉, 상세 구현이 아니라 큰 흐름/연결 관계를 설명하는 모드로 전환한다.[^16]
3.6 클라이언트(단말) 쪽: 안드로이드 / iOS / 웹 / IoT 등 다양한 진입점[^17]
화자는 흐름을 설명하기 위해 그림에서 “안드로이드, IoT, 웹” 등 여러 단말(클라이언트) 유형을 먼저 짚는다.[^17]
3.6.1 모바일 앱: 안드로이드와 iOS, 그리고 다양한 개발 스택[^18]
- 앱의 종류는 큰 틀에서 안드로이드와 iOS가 있다는 정도로 말한다.[^18]
- 안드로이드는 자바/코틀린으로 개발된다는 예를 들고,[^19]
- iOS는 스위프트를 언급한다.[^19]
- 그리고 크로스플랫폼/대안으로 리액트 네이티브, 플러터, 아이오닉 등의 선택지들도 같이 언급한다.[^19]
여기서의 의도는 “클라이언트가 어떤 기술로 만들어졌든 서버와 연결된다”는 전제를 깔고, 백엔드가 마주치는 다양한 클라이언트 세계를 보여주는 것이다.[^17][^19]
3.6.2 리액트(웹) vs 리액트 네이티브(앱)의 차이를 짚는 이유[^20]
화자는 “살짝 하나만 짚고 가자”며 리액트와 리액트 네이티브를 구분해 설명한다.[^20]
- 리액트는 웹사이트/홈페이지를 만드는 데 쓸 수 있고, 웹 개발을 할 수 있다고 말한다.[^21]
- 리액트 네이티브는 이름 그대로 “네이티브는 앱 개발용”이라고 정의한다.[^22]
그리고 차이를 “화면을 무엇으로 그리느냐”로 설명한다.
- 리액트는 기본적으로 반환(렌더링)하는 곳이 HTML 태그 기반으로 화면을 만들게 되어 있다고 말한다.[^23]
- 반면 리액트 네이티브는 “HTML 태그로 화면을 그려주고 데이터 같은 걸 보여줘서 화면을 만든다”는 식으로 설명하며(표현은 다소 구어적), 핵심은 앱 화면 요소가 앱 소스에 포함된다고 정리한다.[^24][^25]
결론 문장으로 화자는 “리액트 네이티브는 화면 소스가 포함된다라고 생각하면 된다”고 말해, 앱과 웹의 구성 방식 차이를 직관으로 남긴다.[^25]
[!NOTE] 화자의 설명이 전달하려는 요지
프론트 기술의 디테일을 깊게 파기보다는, “웹(HTML 중심)”과 “앱(단말 내부에 화면 구성 요소 포함)”이라는 감각적 차이를 통해, 서버 입장에서 두 클라이언트가 어떻게 다르게 연결되는지(다음 섹션의 API vs 웹서버)로 넘어가기 위한 징검다리 역할을 한다.[^22][^26]
3.6.3 IoT와 웹/PC 클라이언트도 서버에 붙는다[^26]
- IoT 기기들도 통신할 수 있으니 “이렇게 붙을 수가 있죠”라고 하며 서버 연결 가능성을 언급한다.[^26]
- 웹은 웹사이트/홈페이지뿐 아니라 “PC 프로그램에서 PC 클라이언트도 해당”된다고 말한다.[^27]
- 홈페이지를 만드는 기술은 많고, 예로 뷰 JS 등을 언급하며 웹 기술 스펙트럼이 넓음을 상기시킨다.[^28]
- “데스크탑”으로 표현한 것은 PC 애플리케이션을 말하며, 이것도 여러 가지로 만들 수 있다고 정리한다.[^28]
이 구간은 “클라이언트는 모바일만이 아니다”라는 관점을 깔아주면서, 이후 “서버 접속 지점이 두 군데”라는 구조 설명으로 들어가기 위한 준비다.[^29]
3.7 서버로 들어가는 두 접점: API로 붙는 경우 vs 웹서버로 붙는 경우[^29]
화자는 “이런 단말들이 웹사이트 포함해서 서버로 접속을 한다”고 말하며, 여기서 접점을 두 군데로 잡았다고 한다.[^29]
그 두 군데는:
- API 접속하는 부분[^30]
- 웹 서버 접속하는 부분[^30]
그리고 “설명을 쭉 듣고 보면 싹 보일 것”이라고 말하며, 이제 이 둘을 대비해서 이해시키겠다고 예고한다.[^29]
3.8 API란 무엇인가: “화면이 아니라 데이터만 주고받는 인터페이스”[^30]
화자는 API 접속을 “인터페이스라는 걸로 접속”한다고 표현한다.[^30] 그리고 API라는 단어 자체를 “어플리케이션 프로그램 인터페이스”로 풀어 말하며, 너무 어려워질 수 있으니 직관적으로 이해하자고 한다.[^31]
그 직관은 다음 한 문장으로 정리된다.
- 웹처럼 화면이 보이는 게 아니라, 어떤 데이터만 주고받는다고 생각하면 된다고 말한다.[^31]
그리고 이 구조를 다음처럼 대비시킨다.
- “화면은 여기에 있고요(클라이언트)”[^32]
- “데이터만 주고 받아지는 거예요(서버와)”[^32]
3.8.1 카카오톡 예시: 화면은 폰에서, 메시지(데이터)는 서버와 교환[^33]
화자는 예시로 카카오톡을 든다.
- 카카오톡 같은 서비스의 화면은 내 핸드폰에서 다 구동된다.[^33]
- 대신 메시지가 “주고받아지잖아요”라고 하며, 그때 오가는 것은 데이터라고 이해하라고 말한다.[^33][^34]
즉, 앱 기반 서비스의 많은 경우 “UI/화면 렌더링”은 단말에서 하고, 서버는 데이터 요청/응답(API)을 처리하는 형태라는 점을 카카오톡이라는 익숙한 사례로 고정시킨다.[^33][^31]
3.9 웹서버란 무엇인가: “웹(콘텐츠/HTML)을 가지고 있고, 접속하면 내려와서 그려진다”[^35]
API와 대비하여 화자는 웹서버를 이렇게 정의한다.
- 웹서버는 “웹을 가지고 있는 거”라고 표현한다.[^35]
- 네이버 같은 곳에 접속하면 “안쪽 내용들이 다 웹에 그려져 있고”, 웹에 접속해서 보는 것이라고 말한다.[^35]
조금 더 구체화하면:
- 사이트에 들어갔을 때 “대부분의 내용이 내려오고 그게 그려지는 것”이 웹서버 역할이라고 설명한다.[^36]
그리고 다시 API 상황과 대비한다.
- API는 “내용들이 다 클라이언트에 있고 데이터만 주고받아지는 상황”이라고 재확인한다.[^37]
이어서 화자는 “앱과 웹의 느낌 차이로 보면 된다”고 말해, 기술 정의보다 체감 차이(사용/접속 방식 차이)로 기억시키려 한다.[^37]
정리 문장:
- 앱은 API 접속이다.[^38]
- 웹서버는 브라우저에서 주소를 쳐서 내용을 받는 것이다.[^38]
3.10 “스마트폰으로 네이버(웹)를 보면 어디로 붙나요?”라는 질문 처리: 모바일 브라우저는 API가 아니라 웹서버로 간다[^39]
화자는 청중이 가질 법한 질문을 직접 던진다.
[? 질문] 스마트폰에도 웹브라우저가 있는데, 폰에서 웹(예: 네이버)을 접속하면 어디로 붙는가?[^39]
[= 답] 그 경우는 “API 붙는 건 일단 아니”고, 웹 접속이므로 웹서버 쪽으로 붙는다는 의미라고 정리한다.[^40][^44]
그리고 폰에서 네이버를 접속할 때 PC에서 보는 화면과 다른 이유를 설명한다.
- 웹은 웹(HTML로 만들어져 그려지는 외부 맵/페이지)인데, 크기, 버튼 위치 등 레이아웃이 전체적으로 많이 다르다고 말한다.[^41]
- 그래서 모바일용을 별도 화면으로 구성하기도 하고,[^42]
- 혹은 같은 화면을 동적으로 작게 만들어 표현하기도 한다.[^42]
화자는 이를 “다이나믹 HTML이라고 하는데”라는 표현으로 언급하며(용어는 소개 수준), 구현 방식은 두 갈래가 있을 수 있다고 말한다.
- 모바일/PC용으로 웹서버를 두 개 별도로 두기도 하고,[^43]
- 하나의 서버에서 분기 처리로 다르게 내려주기도 한다.[^43]
하지만 어떤 방식을 쓰든 결론은 동일하다고 못 박는다.
- 결국 “여기로 붙는다(웹서버)”
- “API 아니다”라는 의미라고 정리한다.[^44]
[!TIP] 입문자가 헷갈리기 쉬운 포인트를 정리하는 방식
“폰에서 보이는 웹”은 “폰 앱”과 달리 기본적으로 브라우저가 HTML을 받아 그리는 흐름이므로, 화자는 이를 API 호출과 분리해서 이해시키려 한다.[^38][^44]
3.11 API 스타일 언급: REST를 중심으로 GraphQL, gRPC도 존재[^45]
화자는 API의 대표로 “REST를 쓴다고 보면 된다”고 말한다.[^45] 동시에 다른 개념도 있음을 언급한다.
- GraphQL이라는 개념도 있고,[^45]
- gRPC라는 개념도 있다고 한다.[^45]
책에서는 이 부분이 좀 더 자세히 터치된다고 말하면서도, 본인은 “어쨌든 REST를 강조드리고 싶다”고 한다.[^46]
즉, 입문 단계에서는 API 방식이 여러 개라는 사실을 인지하되, 기본 축을 REST로 잡는 것이 좋다는 톤이다.[^46][^45]
3.12 인증(Authentication) vs 인가/권한(Authorization): “들어올 수 있나” vs “어디까지 가능하나”[^47]
화자는 그림의 인증 관련 영역을 보며 용어 차이를 묻는다.
[? 질문] Authentication(인증)과 Authorization(인가/권한)의 차이를 아는가?[^47]
[= 답] 인증에는 “두 가지 개념”이 있는데, 하나는 **들어올 수 있냐 없냐(승인/접근 허용 여부)**이고, 다른 하나는 **어디까지 접근 가능하냐(권한 범위)**다.[^48][^49][^50]
화자는 설명 도중 용어를 “인허가/인가”로 말했다가 정리하기 위해 “이걸 승인으로 할게요”라고 표현을 바꾸며, 의미 중심으로 풀어준다.[^49]
- (화자가 ‘승인’으로 부른) Authentication 쪽: “당신이 여기를 들어올 수 있어요/없어요를 나누는 것”[^50]
- Authorization 쪽: “어디까지 접근이 가능해요”라는 개념[^50]
3.12.1 관리자 메뉴 예시: 로그인은 했지만, 관리자 기능은 제한될 수 있다[^51]
화자는 로그인 이후를 예로 든다.
- 로그인해서 들어갔는데, 관리자는 일반 사용자가 보지 않는 기능을 접속할 수 있는 부분이 따로 있을 수 있다.[^51]
- 카페 같은 데서 주인장이 “관리자 메뉴”로 들어갈 수 있는데,[^52]
- 주인장이 아닌 사람은 그런 버튼 자체가 안 보이거나, 눌렀을 때 “귀하는 사용할 수 없습니다”로 막히는 경우가 있다고 한다.[^52]
이게 바로 “권한”이라고 결론낸다.[^52]
이 구간의 목적은 백엔드가 다루는 요소 중 “인증/인가”가 아키텍처 그림의 한 축으로 들어가며, 실무에서 기능 접근 제어로 바로 연결된다는 점을 이해시키는 것이다.[^47][^52]
3.13 API 서버는 어디에 있나: 서버(클라우드/IDC)에 있고, 백엔드 프로그램은 서버에 있다[^53]
화자는 다시 아키텍처 그림으로 돌아와 “API 서버 결국 여기는 어디에 있을까요”라고 질문하고 스스로 답한다.[^53]
[? 질문] API 서버는 어디에 있는가?[^53]
[= 답] “서버에 있죠”라고 말하며, 지금까지 설명한 게 “서버를 얘기하는 것”이라고 정리한다.[^54]
그리고 매우 직접적으로 말한다.
- “백엔드는 프로그램 다 서버에 있습니다.”[^55]
이어서 서버가 위치한 환경에 대해 현실적인 관점을 제시한다.
- 서버가 “요즘 클라우드에 있다”라고 말하지만,[^56]
- 사실 지금도 IDC(Internet Data Center)에 “어마어마하게 많고”, 클라우드로 “1도 안 간” 경우도 있다고 말한다.[^57]
- 본인이 최근 본 사례로 “한 대의 서버도 클라우드 없”는 곳도 있었다고 한다.[^57]
- 특히 금융권 등은 여전히 IDC를 많이 쓴다고 설명한다.[^58]
결론적으로 화자는:
- 클라우드를 갈 수도 있고 안 갈 수도 있는 상황이라고 정리한다.[^59]
그리고 마지막에 “API 게이트(게이트웨이로 보이는 요소)도 말했고 AWS도 말했다”는 식으로, 그림에서 언급한 요소들을 가리키며 정리한다.[^60] (즉, API 기능은 서버에 있고, 그 서버는 클라우드(AWS 등)일 수도, IDC일 수도 있다는 큰 구조를 다시 묶는다.)[^60][^61]
또한 서버의 정의를 비유적으로 설명한다.
- 서버는 우리가 다루는 핸드폰/컴퓨터(클라이언트)가 아니라, “어딘가에 존재하고 우리의 응답을 기다리는 컴퓨터”라고 말한다.[^61]
- 그 컴퓨터들이 모여 있는 곳이 IDC이고, 요즘은 클라우드에 위치하기도 한다고 덧붙인다.[^62]
- 따라서 “API 프로그램은 거기에 올라가 있는 것”이라고 결론낸다.[^62]
3.14 마무리 멘트: 자세히 설명했으니 아는 사람은 스킵해도 된다[^63]
화자는 오늘 설명이 “되게 자세하고 친절”했다고 말하며, 이미 다 아는 사람들은 “퀵하게 넘어가시고 패스하셔도 된다”고 마무리한다.[^63] 즉, 이 영상이 입문자를 강하게 의식한 “큰 그림 안내” 성격임을 다시 확인하는 결말이다.[^63]
4. 핵심 통찰[^9]
- [c 백엔드 입문은 ‘서버 기술’이 아니라 ‘사용자 행동에서 시작되는 요청 흐름’으로 출발할 때 이해가 빨라진다] 앱 화면에서 버튼이 눌리고 서버 기능이 호출되는 장면으로 시작하면, API/DB/인프라를 외우는 게 아니라 연결해서 이해하게 된다.[^8][^13]
- [h 백엔드는 API 서버만이 아니라 데이터와 인프라까지 포함하는 서버 사이드 전체를 다룬다] API가 대표일 뿐, 저장(DB)과 운영 환경(클라우드/IDC)까지가 실제 백엔드의 일부라는 관점이 반복된다.[^9][^10][^55]
- [h “자바/스프링 잘함”은 필요조건이지 충분조건이 아니다] 실무에서 요청은 스펙과 프로토콜을 통해 들어오고, 통신과 DB와 인프라 위에서 돌아가므로 아키텍처 지식이 필요하다는 논리다.[^11][^12][^13]
- [h 앱과 웹의 차이는 ‘화면이 어디에 있느냐’로 잡으면 단순해진다] 앱은 화면이 단말에 있고 API로 데이터만 주고받는 경향, 웹은 웹서버에서 내려오는 HTML 등을 브라우저가 그리는 흐름으로 구분해 이해하라고 한다.[^31][^36][^38]
- [m 모바일에서 보는 웹도 본질은 웹서버 접속이며, API 접속과 구분해야 한다] 모바일/PC 화면 차이는 별도 화면 구성 또는 동적 처리로 해결할 수 있지만, 접속 축은 웹서버라는 점을 강조한다.[^41][^44]
- 실행 관점에서의 행동 항목(영상이 직접 “해야 한다”고 말한 취지를 행동으로 풀어쓴 것):
- 앱에서 “버튼 클릭 → API 호출 → 서버 처리 → DB 저장/조회 → 응답” 흐름을 한 번 그림으로 그려보라.[^8][^12]
- 본인이 쓰는 서비스(예: 메신저/포털)에 대해 “이건 API 호출인가, 웹서버 렌더링인가”를 구분해보라.[^33][^35]
- 인증/권한을 기능 요구사항으로 분리해 생각하라(로그인 성공 vs 관리자 기능 접근 범위).[^50][^52]
5. 헷갈리는 용어 정리 (해당 시에만)[^30]
API: 웹처럼 화면을 내려받아 보는 것이 아니라, 데이터를 주고받기 위한 인터페이스로 이해하라고 설명한다.[^31][^32]
웹서버: 네이버 같은 사이트에 접속했을 때 웹 콘텐츠(대부분의 내용)가 내려오고 브라우저에서 그려지게 하는 역할로 설명한다.[^35][^36]
REST: API 방식의 대표로 언급되며, 화자는 입문 관점에서 REST를 특히 강조한다고 말한다.[^45][^46]
GraphQL / gRPC: REST 외에도 존재하는 API 관련 개념으로 “있다” 수준으로 언급된다.[^45]
Authentication(인증): (화자 표현상 ‘승인’) “들어올 수 있어요/없어요”를 나누는 개념으로 설명한다.[^50]
Authorization(인가/권한): “어디까지 접근이 가능해요”라는 범위/권한의 개념으로 설명한다.[^50][^52]
IDC(Internet Data Center): 서버(컴퓨터)들이 모여 있는 곳으로 설명되며, 클라우드로 안 간 조직(예: 금융권)에서 여전히 많이 쓴다고 언급된다.[^58][^62]
참고(콘텐츠 정보)[^2]
- 제목: 백엔드 개발 이 영상만 보셔도 거의[^2]
- 채널: 기술노트with 알렉[^2]
- 길이: 11분 59초[^2]
- 링크: https://www.youtube.com/watch?v=_WQR6-sqqjM[^2]
[^2]: @[00:10] "오늘 주제는 백엔드의 시작... 백엔드 30일... 첫 번째 장..." + 사용자가 제공한 메타데이터(제목/채널/길이/링크)
[^3]: @[00:20] "저는이 책에서 이런 시작점이 되게 좋았어요"
[^4]: @[00:22] "앱의 얘기부터 나옵니다"
[^5]: @[00:27] "백엔드에 관심... 백엔드에 굉장히 집중... 두 가지 관점..."
[^6]: @[00:32] "첫 번째 앱... 두 번째는 전체"
[^7]: @[00:37]~@[00:48] "엔드라 해서 백핸드 많이 존재... 프론트엔드 백엔드..."
[^8]: @[01:39] "화면부터 시작... 버튼이 눌러졌을때... 서버에 어떤 기능이 호출... 사용자가 사용... 화면부터 시작"
[^9]: @[01:06] "서버에는... 대표적인 것이 API 서버... 데이터도 관련"
[^10]: @[01:16] "인프라 관점도... 포함"
[^11]: @[01:26] "백엔드는... 서버 을 다 표현... 전체 흐름..."
[^12]: @[02:33] "API 스펙... 프로토콜... 통신... 저장... DB..."
[^13]: @[02:39]~@[02:49] "전체 관점... 아키텍처도 알아야"
[^14]: @[02:49]~@[02:55] "백핸드가 알아야 되는 아키텍처... 말씀"
[^15]: @[03:03] "그림의 구성 요소들... 수준이 높은... 자세히... 강의..."
[^16]: @[03:12] "대략적인... 흐름을 정리"
[^17]: @[03:32]~@[03:39] "안드로이드 IoT 웹"
[^18]: @[03:39]~@[03:47] "앱의 종류... 안드로이드와 iOS"
[^19]: @[03:47] "안드로이드 자바 코틀린... iOS 스위프트... 리액트 네이티브... 플러터 아이오닉"
[^20]: @[03:51]~@[03:58] "리액트... 리액트 네이티브... 살짝..."
[^21]: @[04:02]~@[04:13] "리액트로 웹사이트... 홈페이지... 웹도 개발"
[^22]: @[04:20]~@[04:29] "리액트 네이티브... 앱 개발 용"
[^23]: @[04:29]~@[04:36] "리액트... html 태그... 기반"
[^24]: @[04:42]~@[04:49] "리액트 네이티브... 화면... 데이터... 보여줘서"
[^25]: @[04:49]~@[04:56] "화면의 요소들도 앱의 소스... 포함"
[^26]: @[05:06]~@[05:14] "IoT 기기들도... 붙을 수... 통신"
[^27]: @[05:14]~@[05:21] "웹... PC 프로그램... PC 클라이언트... 웹사이트"
[^28]: @[05:21]~@[05:30] "뷰 JS... 자바스크립트... 데스크탑... PC 어플리케이션"
[^29]: @[05:30]~@[05:54] "단말들이... 서버로 접속... 접점을 두 군데"
[^30]: @[05:54]~@[06:02] "API 접속... 웹 서버... API는 인터페이스로"
[^31]: @[06:02]~@[06:11] "API... 인터페이스... 화면이 보이는게 아니라 데이터만"
[^32]: @[06:11]~@[06:20] "화면은 여기에... 데이터만 주고 받아"
[^33]: @[06:20]~@[06:28] "카카오톡... 화면은 핸드폰... 메시지 주고받"
[^34]: @[06:40] "데이터만 주고 받는다"
[^35]: @[06:46]~@[06:52] "웹 서버... 웹을 가지고... 네이버... 접속"
[^36]: @[06:52]~@[07:01] "대부분의 내용이 내려오고 그게 그려지는... 웹서버 역할"
[^37]: @[07:05]~@[07:09] "API 내용... 클라이언트에 있고 데이터만"
[^38]: @[07:14]~@[07:18] "앱은 API 접속... 웹 서버는 브라우저 주소"
[^39]: @[07:18]~@[07:31] "스마트폰에도 웹브라우저... 웹 접속하면 어디로 붙나요"
[^40]: @[07:31]~@[07:35] "그 경우는 API 붙는 건... 아니에요"
[^41]: @[07:59]~@[08:14] "네이버... 크기... 버튼 위치... 다르"
[^42]: @[08:14]~@[08:20] "별도 화면... 동적으로 작게"
[^43]: @[08:27]~@[08:35] "다이나믹 html... 웹서버 두 개... 분기 처리"
[^44]: @[08:35] "결국... 여기로 붙는다... API 아니다"
[^45]: @[08:41]~@[08:47] "API 대표적으로 레스트... 그래프GL... grpc"
[^46]: @[08:56]~@[09:04] "책에... 자세히... 어쨌든 저는 레스트를 강조"
[^47]: @[09:04]~@[09:12] "인증... 케이션... 라이션... 차이 아시나요... 오스"
[^48]: @[09:12]~@[09:22] "인증... 두 가지 개념"
[^49]: @[09:22]~@[09:35] "인증 인허가... 죄송... 승인으로"
[^50]: @[09:35]~@[09:41] "승인... 들어올 수 있어요 없어요... 션은 어디까지 접근"
[^51]: @[10:05]~@[10:11] "관리자... 사용자들이 보지 않는 기능"
[^52]: @[10:11]~@[10:23] "카페... 주인장 관리자 메뉴... 사용할 수 없습니다... 그게 권"
[^53]: @[10:33]~@[10:36] "API 서버 결국 여기는 어디에 있을까요"
[^54]: @[10:36]~@[10:43] "서버에 있죠... 서버를 얘기"
[^55]: @[10:43]~@[10:47] "백엔드는 프로그램 다 서버에 있습니다"
[^56]: @[10:47]~@[10:50] "서버가 요즘 클라우드에"
[^57]: @[10:50]~@[10:59] "IDC... 1도 클라우드로 안 간... 한대의 서버도..."
[^58]: @[10:59]~@[11:06] "금융권... 여전히 IDC... 많이"
[^59]: @[11:06]~@[11:09] "클라우드를 갈 수도 있고 안 갈 수도"
[^60]: @[11:09]~@[11:15] "API 게이트... aws"
[^61]: @[11:15]~@[11:26] "서버... 우리가 다루는... 핸드폰이나 컴퓨터가 아니라... 응답을 기다리는 컴퓨터"
[^62]: @[11:26]~@[11:36] "IDC... 모여져 있거나... 클라우드... API 프로그램은 거기에 올라"
[^63]: @[11:47] "설명... 자세하고 친절... 다 아시 분들은... 패스"