프로젝트에서 보기 →

프론트엔드 + 백엔드 + 인프라? #개발자

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

https://www.youtube.com/watch?v=NyHoHsk1-34

description: |-

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

[? 질문] 웹 개발을 공부할 때 왜 프론트엔드/백엔드만이 아니라 인프라까지 등장하는가[^3]
[= 답] 웹 서비스는 프론트엔드와 백엔드가 “일할 수 있는 환경” 위에서 돌아가며, 특히 클라우드로 전환된 이후 개발자도 인프라를 “직접 운영”하진 않더라도 기본 원리와 영향 요소를 아는 것이 유리하기 때문이다.[^8][^11]

[? 질문] 인프라란 정확히 무엇을 의미하며, 프론트엔드/백엔드와 어떤 관계인가[^4]
[= 답] 인프라는 레스토랑 비유로 “레스토랑 자체(건물·전기·물·보안·설비·공간 등)”에 해당하며, 프론트엔드(웨이터)와 백엔드(셰프)가 일할 수 있도록 기반 환경을 제공하는 모든 요소를 뜻한다.[^6][^7]

[? 질문] 개발자가 인프라를 어디까지 알아야 하는가[^11]
[= 답] 개발자가 인프라를 전부 상세히 알고 직접 관리하는 것은 불가능하고(또한 보통 전담 팀이 있음), 대신 하드웨어·네트워크·운영체제·미들웨어 등 계층별 ‘원리’와 핵심 개념을 이해하면 개발한 프로그램의 성능/보안/배포/운영에 미치는 영향을 파악할 수 있다.[^11][^12][^19]

2. 큰 그림[^2]

이 콘텐츠는 웹 개발을 공부하는 사람이 흔히 접하는 프론트엔드와 백엔드 구분을 출발점으로, 학습 과정에서 왜 **인프라(Infra)**라는 주제가 필연적으로 등장하는지 설명한다.[^2][^3] 특히 과거 온프레미스 환경과 달리, 현재는 많은 회사가 클라우드로 옮기면서 개발자와 인프라의 거리가 가까워졌다는 맥락을 제시한다.[^10][^11]

  • **인프라는 “개발 환경의 바탕”**이다: 프론트엔드/백엔드가 기능을 만들기 위해서는 그들이 활동할 수 있는 기반(설비·시스템·보안·공간)이 필요하다는 관점으로 인프라를 정의한다.[^6][^7]
  • 클라우드 전환이 ‘기본 지식 필요성’을 높였다: 예전엔 전담 팀이 온프레미스로 관리해 개발자가 몰라도 됐지만, 클라우드 이후 개발자는 인프라를 완전히 모르는 것보다 기본 원리를 아는 편이 좋다고 말한다.[^10][^11]
  • 전부가 아니라 ‘원리’가 핵심: 하드웨어/네트워크/OS/미들웨어/소프트웨어로 이어지는 여러 계층을 다 알아서 코딩까지 하는 건 불가능하나, 원리 이해는 개발 의사결정에 도움을 준다.[^11][^12]

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

3.1 프론트엔드·백엔드는 익숙한데, 왜 인프라가 나오나^1

📸 0:00

영상은 “개발자 공부를 하고 있다면 프론트엔드와 백엔드는 잘 알 것”이라는 전제를 깔고 시작한다.^1 이어서 사람들이 웹 개발자를 떠올리면 보통 프론트엔드 개발자와 백엔드 개발자를 말하는데, 공부를 하다 보면 그 “중간에” 인프라라는 주제가 등장한다고 한다.[^2]

여기서 화자가 던지는 핵심 문제의식은 다음과 같다.[^3]

[? 왜 프론트엔드/백엔드를 배우는데 인프라 이야기가 코딩 공부에 등장할까]
[= 웹을 만들고 운영하려면 프론트엔드와 백엔드가 ‘일하는 무대’가 필요하고, 그 무대를 구성하는 것이 인프라이며, 최근 환경 변화(클라우드)로 인해 개발자가 기본을 이해해야 할 필요가 커졌기 때문이다][^3][^11]

또한 프론트엔드와 백엔드의 역할을 간단히 재확인한다.[^3]

  • 사용자가 보는 웹사이트(화면)를 만드는 사람이 프론트엔드 개발자.[^3]
  • 서버와 데이터베이스 등 뒤쪽에서 데이터를 관리하고 엔지니어링을 수행하는 사람이 백엔드 개발자.[^3]

이 대비를 통해 “그렇다면 인프라는 무엇이길래” 코딩 공부 맥락에서 언급되는지 설명을 예고한다.[^3]

3.2 레스토랑 비유로 역할을 직관화: 웨이터(프론트)·셰프(백)·레스토랑(인프라)[^4]

📸 0:32

화자는 “예를 들어서 설명”하겠다며, 이전 영상에서 웹 개발을 레스토랑에 비유했다고 상기시킨다.[^4][^5]

비유의 구성은 다음처럼 대응된다.[^5][^6]

  • 주문을 받는 웨이터 = 프론트엔드 개발자[^5]
  • 주방에서 요리하는 셰프 = 백엔드 개발자[^5]
  • 그리고 이 둘이 활동하는 기반인 레스토랑 자체 = 인프라[^6]

이때 인프라를 “레스토랑 자체”라고 정의하면서, 인프라가 단순히 서버 한 대를 뜻하는 것이 아니라 서비스가 운영될 수 있는 물리/논리적 기반 전체임을 강조하는 흐름을 만든다.[^6]

3.3 인프라는 ‘일할 수 있는 환경’을 통째로 제공한다: 건물·전기·물·보안·공간까지[^7]

📸 0:52

화자는 인프라를 레스토랑의 구성 요소로 세분화한다.[^7]

인프라에 포함되는 것(레스토랑 예시):

  • “가장 큰” 단위로 건물 자체[^7]
  • 운영에 필요한 전기와 물[^7]
  • 손님이 앉는 의자[^7]
  • 음식이 놓이는 테이블[^7]
  • 전체적인 보안 시스템[^7]
  • 식재료 등을 보관할 수 있는 공간(저장 공간)[^7]

그리고 이 모든 요소를 묶어 다음 결론을 제시한다.[^7]

  • 인프라는 말 그대로 프론트엔드 개발자와 백엔드 개발자가 “일을 할 수 있는 환경을 제공”한다.[^7]

즉, 인프라는 애플리케이션 코드를 작성하는 두 역할(프론트/백)이 “작동”할 수 있게 해주는 전제 조건이라는 설명이다.[^7]

[!IMPORTANT] 인프라를 ‘개발자 업무의 배경’으로 놓는 관점[^7] 인프라는 기능 개발(프론트/백)과 분리된 별개의 주제가 아니라, 기능이 서비스로 작동하기 위한 기반(전기·보안·공간 등)을 제공하는 층위로 설명된다.[^7]

3.4 인프라는 서비스(식당)마다 다르다: 규모·요구사항 차이[^8]

📸 0:59

화자는 인프라가 모든 곳에서 동일하지 않다고 말한다.[^8]

  • 인프라는 “식당에 따라 규모와 요구 사항이 다르다.”[^8]

이어서 식당 종류에 따라 인프라가 다르다는 점을 간단 비교로 제시한다.[^9]

  • 예: 일식집과 햄버거를 파는 식당은 인프라가 다르다.[^9]

이 대목의 의도는 “서비스 특성에 따라 필요한 기반이 달라진다”는 것을 직관적으로 전달하는 것이다.[^8][^9] (예를 들어 고급 일식집과 패스트푸드점은 주방 설비, 좌석 구성, 운영 방식이 다르듯이, 웹 서비스도 트래픽/보안/지연시간/데이터 특성 등에 따라 요구 인프라가 달라진다는 전제를 깔아둔다.)[^8][^9]

+++ 상세 예시(비유 확장: 콘텐츠의 논리 흐름을 따라 이해 돕기) 영상은 구체 항목을 더 나열하진 않지만, “요구 사항이 다르다”는 문장을 비유 안에서 해석하면 다음처럼 읽을 수 있다.[^8][^9]

  • 어떤 식당은 회전율이 중요해 좌석/동선이 핵심이고,
  • 어떤 식당은 신선 보관이 중요해 냉장/저장 설비가 핵심이며,
  • 어떤 식당은 보안/안전이 더 중요할 수 있다.
    이처럼 웹 서비스도 목적과 특성에 따라 인프라 설계 포인트가 달라진다는 메시지를 강화하는 장치다.[^8][^9] +++

3.5 과거엔 몰라도 됐던 이유: 온프레미스 + 전담 운영팀 분리[^10]

📸 1:24

여기서 화자는 “원래는” 프론트엔드나 백엔드 개발자가 인프라 지식이 별로 필요하지 않았던 시기가 있었다고 말한다.[^10]

그 이유는 다음과 같이 제시된다.[^10]

  • 인프라 시스템 자체가 온프레미스(회사 내부/자체 환경)로 운영되었고[^10]
  • 개발자들과 “완전 다른 팀”이 이를 관리했기 때문이다.[^10]

즉, 개발 조직과 인프라 운영 조직이 분리되어 있었기 때문에 개발자는 애플리케이션 코드에 집중해도 되었고, 인프라는 다른 팀의 영역이었던 구조를 설명한다.[^10]

3.6 클라우드 이후 변화: 개발자는 인프라를 ‘완전 모르는 것보다’ 기본을 아는 게 좋다[^11]

📸 1:32

화자는 전환점을 “클라우드로 많은 회사들이 옮긴 이후”라고 명시한다.[^11]

변화 이후의 권고는 다음 문장으로 정리된다.[^11]

  • 개발자라고 해서 인프라를 “완전 모르는 것보다” 적어도 기본 지식은 아는 것이 좋다.[^11]

다만, 여기서 오해를 방지하기 위해 선을 긋는다.[^12]

  • “물론 그렇다고 해서 개발자가 인프라를 직접 관리하는 건 아니다.”[^12]

즉, 화자는 개발자가 SRE/인프라 엔지니어처럼 모든 운영을 맡아야 한다고 주장하는 것이 아니라, 클라우드 환경에서 개발과 인프라의 접점이 늘어났기 때문에 이해 수준이 필요하다고 말한다.[^11][^12]

[!NOTE] ‘운영 담당’과 ‘기본 이해’의 구분[^11][^12] 콘텐츠는 “인프라를 공부하라”를 “인프라를 직접 운영하라”로 동일시하지 않는다.[^12] 클라우드 시대에 개발자가 겪는 문제(성능, 네트워크, 배포, 보안 등)를 이해하기 위한 최소한의 원리 습득을 권한다는 톤이다.[^11]

3.7 인프라는 계층이 많다: 하드웨어→네트워크→OS→미들웨어→소프트웨어[^13]

📸 1:46

화자는 인프라의 기본 요소를 나열하며, 겉으로 보이는 것보다 “여러 단계”가 있음을 강조한다.[^13]

인프라의 구성 요소(화자가 열거):

  • 하드웨어[^13]
  • 네트워크[^13]
  • 운영 체제(OS)[^13]
  • 미들웨어[^13]
  • 소프트웨어[^13]

그리고 중요한 한계를 분명히 말한다.[^13]

  • 실제 웹 개발자에게 “보이는 소프트웨어 말고도” 여러 단계가 있으며[^13]
  • 이 모든 내용을 자세히 알고 하면서 개발자로서 코딩까지 하는 건 “불가능”하다고 말한다.[^13]

이어서 학습의 목표를 “원리는 알면 좋다”로 정리한다.[^14]

  • [h 인프라의 모든 세부를 다루는 것이 아니라, 원리를 이해하는 것이 목적이다][^14]

3.8 하드웨어 관점: CPU·메모리를 생각하면 ‘언어/성능’ 차이가 이해된다[^15]

📸 2:01

화자는 “하드웨어만 보아도” 인프라 관점이 개발에 도움이 된다고 말한다.[^15]

제시하는 논리 흐름:

  1. 복잡한 코드를 실행할 때 CPU와 메모리를 고려하며 개발하면[^15]
  2. 왜 특정 언어가 다른 언어보다 느린지 같은 차이를 이해할 수 있다는 것.[^16]

화자는 예시로 다음 비교를 든다.[^16]

  • CPU/메모리를 생각해 보면 “왜 파이썬이 (다른 것, 예: C++) 보다 느린지” 이해할 수 있다고 말한다.[^16]

이 부분은 하드웨어 자원과 실행 모델을 고려하면 성능 특성을 납득할 수 있다는 취지로, 인프라 이해가 단순 운영 지식이 아니라 개발 판단에도 연결됨을 보여주는 예시다.[^15][^16]

3.9 네트워크 관점: HTTPS, CDN, 로드 밸런싱이 프로그램에 큰 영향을 준다[^17]

📸 2:16

화자는 네트워크 분야에도 다양한 내용이 있지만, 웹 개발자가 알아두면 프로그램에 “큰 영향”을 주는 요소들이 있다고 말한다.[^17]

네트워크에서 알아야 한다고 제시한 예시:

  • HTTPS의 차이를 알아야 하는 이유[^17]
  • CDN이 무엇인지[^17]
  • 로드 밸런싱이 왜 중요한지[^17]

그리고 이러한 네트워크 개념들이 “실제 웹 개발자가 만든 프로그램”에 큰 영향을 끼친다고 연결한다.[^17]

[!TIP] 네트워크 지식이 ‘코드 바깥’이 아니라 ‘코드의 체감 품질’을 좌우한다[^17] HTTPS, CDN, 로드 밸런싱 같은 요소는 애플리케이션 코드만으로 해결되지 않는 성능/보안/가용성 특성에 직접 영향을 주기 때문에, 개발자가 기본 개념을 알면 설계·디버깅·운영 협업에 유리하다는 문제의식을 깔고 있다.[^17]

3.10 운영체제 관점: 윈도우·맥·리눅스 차이, 그리고 도커 컨테이너의 필요성[^18]

📸 2:31

화자는 운영체제(OS) 영역에서의 학습 포인트를 제시한다.[^18]

포함해서 알아두면 좋다고 언급한 것:

  • 흔히 말하는 윈도우, 맥, 리눅스의 차이[^18]
  • 그리고 도커 컨테이너가 왜 필요해졌는지[^18]

즉, 개발 환경/배포 환경에서 OS 차이가 의미를 가지며, 컨테이너 기술이 등장한 배경을 이해하는 것이 도움이 된다는 메시지다.[^18]

3.11 미들웨어 관점: 서버·데이터베이스처럼 ‘직접 만드는 소프트웨어’와 가까워 잘 알아야 한다[^19]

📸 2:40

화자는 미들웨어를 “아마 이미 공부하실 수도” 있다고 말하며, 웹 개발 학습에서 미들웨어가 비교적 친숙한 축임을 시사한다.[^19]

미들웨어에 대한 설명 포인트:

  • 미들웨어는 서버와 데이터베이스처럼 개발자가 다루는(혹은 활용하는) 요소들과 연결된다.[^19]
  • “직접 만드는 소프트웨어와 가깝게 사용”되기 때문에 잘 알아야 한다고 말한다.[^19]

이로써 인프라를 구성하는 여러 계층 중에서도, 개발자에게 특히 접점이 큰 영역(서버/DB 등)이 미들웨어로 언급된다.[^19]

3.12 결론 정리: 인프라팀은 따로, 그러나 클라우드 때문에 개발자도 더 가까워졌다[^20]

📸 2:49

화자는 앞선 내용을 “좀 더 심플하게 생각하면”이라는 표현으로 정리한다.[^20]

결론 구조:

  • 인프라를 관리하는 팀은 따로 있다.[^20]
  • 그러나 코딩을 하면서도(웹 개발을 하면서도) 클라우드 영향으로 인프라와 “더 가까워졌기” 때문에[^20]
  • 이런 정보(기본 지식/원리)를 알면 좋다는 것.[^20]

마지막으로 영상은 구독/좋아요 요청과 감사 인사로 마무리된다.[^21][^22]

4. 핵심 통찰[^2]

  1. [c 인프라는 ‘서버 한 대’가 아니라, 프론트/백이 일할 수 있게 하는 기반 환경 전체라는 관점 전환이 핵심이다][^6][^7]
  2. [h 클라우드 전환은 개발자와 인프라의 경계를 약화시켜, 개발자에게 ‘기본 이해’를 사실상 요구하는 방향으로 바꿨다][^11][^20]
  3. 인프라를 “직접 운영”하는 것과 “원리를 이해”하는 것을 분리해 생각해야 한다.[^12][^14]
  4. 인프라는 하드웨어·네트워크·OS·미들웨어·소프트웨어 등 다층 구조이며, 전부를 깊게 아는 건 불가능하다는 한계를 인정한 뒤 학습 목표를 ‘원리’로 잡는다.[^13][^14]
  5. 하드웨어/네트워크/OS의 기본은 개발 결과물의 성능·보안·배포/운영 안정성에 영향을 미치므로, 코딩 실력과 별개가 아니라 실무 이해를 넓힌다.[^15][^17][^18]
  • 실행 관점 시사점(콘텐츠가 권하는 방향을 행동으로 풀어쓰기)[^11][^14]
    • 프론트/백 공부를 하면서도 인프라를 “운영 레벨”이 아니라 개념/원리 레벨로 병행 학습한다.[^14]
    • 네트워크에서 HTTPS, CDN, 로드 밸런싱 같은 키워드는 “정의”뿐 아니라 왜 중요한지(프로그램에 미치는 영향)를 연결해 이해한다.[^17]
    • OS 차이(윈도우/맥/리눅스)와 도커 컨테이너의 필요성을 개발/배포 흐름과 함께 이해한다.[^18]

5. 헷갈리는 용어 정리 (해당 시에만)[^2]

인프라(Infra): 프론트엔드/백엔드가 서비스를 만들고 운영할 수 있도록 제공되는 기반 환경. 레스토랑 비유로는 건물, 전기/물, 좌석/테이블, 보안 시스템, 저장 공간 등 “레스토랑 자체”에 해당한다.[^6][^7]
온프레미스(On-premise): 회사 내부에서 자체적으로 인프라 시스템을 운영/관리하던 방식. 과거에는 개발자와 분리된 다른 팀이 관리했다는 맥락으로 등장한다.[^10]
클라우드(Cloud): 많은 회사가 이전한 인프라 운영 방식/환경으로, 이 전환 이후 개발자가 인프라를 완전히 모르기보다 기본을 아는 것이 좋다는 논지를 만든다.[^11]
미들웨어(Middleware): 서버와 데이터베이스처럼 애플리케이션(직접 만드는 소프트웨어)과 가깝게 사용되는 계층으로, 잘 알아야 한다고 언급된다.[^19]
CDN: 네트워크 관련해서 알아야 할 예시로 제시된 개념(무엇인지 알아야 한다고 언급).[^^17]
로드 밸런싱(Load balancing): 네트워크 관련해서 왜 중요한지 알아야 할 예시로 제시된다.[^17]
도커 컨테이너(Docker container): OS 맥락에서 왜 필요해졌는지 알면 좋다고 언급된다.[^18]

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

  • 제목: 프론트엔드 + 백엔드 + 인프라? #개발자[^2]
  • 채널: NewLearning 뉴러닝[^2]
  • 길이: 3분 7초[^2]
  • 링크: https://www.youtube.com/watch?v=NyHoHsk1-34[^2]

[^2]: 입력 메타데이터 "채널: NewLearning 뉴러닝 / 길이: 3분 7초 / 키워드 ... / https://www.youtube.com/watch?v=NyHoHsk1-34" [^3]: @[00:18] "사용자가 보는 웹사이트를 만드는 프런트엔드 개발자 ... 백엔드 개발자 그렇다면 왜 인프라란 것에 대한 이야기가 코딩 공부에 나올까요" [^4]: @[00:32] "예를 들어서 설명할게요" [^5]: @[00:38] "주문을 받는 웨이터는 프론트엔드 개발자이고 주방에서 요리를 하는 셰프는 백엔드 개발자입니다" [^6]: @[00:45] "그렇다면 인프라는 바로 레스토랑 자체를 말하는 것입니다" [^7]: @[00:52] "건물... 전기와 물... 의자들... 테이블... 보안 시스템... 보관할 수 있는 공간들까지 ... 프론트엔드 ... 백엔드 ... 일을 할 수 있는 환경을 제공" [^8]: @[00:59] "또한 인프라는 식당에 따라 규모와 요구 사항이 다릅니다" [^9]: @[01:16] "식당은 이렇게 인프라가 다릅니다" [^10]: @[01:24] "이유는 이런 인프라의 시스템 자체가 온프레미스로 ... 완전 다른 팀이 관리했기 때문입니다" [^11]: @[01:32] "클라우드로 많은 회사들이 옮긴 이후에는 ... 적어도 기본 지식이 아는 것이 좋습니다" [^12]: @[01:39] "물론 그렇다고 해서 개발자가 인프라를 직접 관리하는 건 아닙니다" [^13]: @[01:46] "하드웨어 네트워크 운영 체제 미들웨어 그리고 소프트웨어까지 ... 여러 단계가 있습니다 ... 코딩까지 하는 건 불가능합니다" [^14]: @[01:53] "하지만 원리는 알면 좋습니다" [^15]: @[02:01] "하드웨어만 보아도 ... CPU 메모리를 생각하면서 개발하다 보면" [^16]: @[02:10] "왜 파이썬이 ... 느린지 이해하실 수 있습니다" [^17]: @[02:16] "https ... cdn ... 로드 밸런싱이 왜 중요한지 등 ... 큰 영향을 끼치는 내용들" [^18]: @[02:31] "운영 체제는 ... 윈도우와 맥 그리고 리누스 차이 ... 도커 컨테이너가 왜 필요해졌기" [^19]: @[02:40] "미들웨어는 ... 서버와 데이터베이스처럼 ... 잘 알아야 합니다" [^20]: @[02:49] "인프라를 관리하는 팀은 따로 있지만 ... 클라우드 영향으로 인프라와 더 가까워졌기 ... 알면 좋다" [^21]: @[03:00] "이 영상이 도움이 되셨다면 구독과 좋아요를 부탁드려요" [^22]: @[03:02] "영상을 봐주셔서 감사합니다"

← 프로젝트에서 보기