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

description: |-

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

[? 질문] 중소기업/스타트업 채용 경쟁이 “전쟁터”가 된 상황에서, 신입 백엔드 개발자가 살아남기 위해 갖춰야 할 최소 기준은 무엇인가[^3]
[= 답] “대규모 트래픽/고난도 설계”가 아니라, 현업에서 바로 검증 가능한 기본기 4가지(API 개발·설계, 관계형 DB, 클라우드 배포, 웹 흐름 이해)를 실제로 만들고 설명할 수 있어야 한다.[^6]

[? 질문] 최소 기준이 부족하거나 감이 없을 때, 무엇을 어떻게 연습해야 “기준을 충족”할 수 있는가[^12]
[= 답] **게시판 CRUD(+로그인/로그아웃)**를 REST 규칙에 맞춰 구현하고, (1) 문서화(Swagger), (2) ORM 쿼리 출력→로우 SQL 확인, (3) AWS EC2/RDS 배포 및 외부접속 확인, (4) 웹서버–WAS–DB 요청 흐름을 강의/자료로 보완하면서 “직접 실습”으로 체화한다.[^12]

[? 질문] JWT가 세션/쿠키보다 “무조건 더 좋은 인증 방식”인가[^3]
[= 답] 아니다. 핵심 차이는 “서버가 상태를 기억하느냐(세션) / 덜 기억하느냐(JWT)”의 성격 차이이며, 무엇이 더 우수하다고 단정할 수 없고 둘 다 구현/이해해야 한다.[^3]

2. 큰 그림[^1]

이 콘텐츠는 채용 지원자가 100~200명씩 몰리는 중소기업/스타트업 채용 시장에서 신입 백엔드가 특히 불리해진 현실을 전제로, “포기하고 싶어지는 상황”에서도 기준을 갖고 준비할 수 있도록 신입 백엔드 개발자 최소 역량 기준과 **기준 미달 시 대비책(훈련 루틴/실습 과제)**을 제시한다.[^3] 또한 화자는 실제로 참고한 타 채널(양동주, 널널한 개발자) 및 본인 회사 지원자들의 이력서/면접 경험에서 관찰한 결핍을 토대로 기준을 정리했다고 밝힌다.[^6]

• 핵심 메시지 1: 게시판 CRUD 수준의 API를 REST 규칙/상태코드/문서화까지 포함해 “설계+구현”할 수 있어야 최소 기준이다.[^6]
• 핵심 메시지 2: 백엔드는 관계형 DB가 중심이며, ERD/관계/SQL(조인·서브쿼리·통계)과 인덱스 감각까지 갖춰야 한다.[^4]
• 핵심 메시지 3: “로컬 실행”에서 끝내지 말고 AWS EC2(+RDS) 배포와 웹서버–WAS–DB의 요청 흐름을 이해/설명할 수 있어야 한다.[^7]

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

3.1 채용 시장의 전제: 지원자 폭증과 신입의 불리함[^3]

영상은 인사말 후 곧바로 시장 상황을 “전쟁터”로 규정한다.[^3] 중소기업이나 스타트업에조차 개발자 지원자가 100명, 200명씩 몰리는 현상을 언급하며, 경쟁이 치열해진 만큼 신입이 더 불리해졌다고 말한다.[^3]
이로 인해 “개발을 포기할까”라는 생각이 드는 것도 자연스러운 감정이라고 인정한다.[^3]

그럼에도 “치열한 경쟁 속에서 살아남는 명확한 기준”이 있다면 어떻겠냐고 문제를 던지고, 오늘 영상의 목적을 **신입 백엔드 개발자가 반드시 알아야 할 ‘최소 기준’**을 제시하는 것이라고 선언한다.[^3]
또한 이 영상은 특정 개인(양동주)과 널널한 개발자 영상, 그리고 화자가 실제로 회사 채용에서 지원자 이력서/면접을 보며 느낀 점을 바탕으로 만들었다고 출처를 밝힌다.[^6] 시청 후에는 최소 기준과 그 대비법을 분명히 알게 될 것이니 되도록 스킵하지 말고 따라오라고 요청한다.[^6]

[!IMPORTANT] 이 영상의 “최소 기준” 정의 화자가 말하는 최소 기준은 “넷플릭스 같은 대규모 서비스 수준”이 아니라, 현업 신입에게 실제로 기대하는 가장 기본적인 구현/이해 능력을 뜻한다.[^6]

3.2 최소 기준 1: API 개발 및 설계 능력(게시판 CRUD 수준) + 문서화까지[^6]

화자가 제시하는 첫 번째 최소 기준은 API 개발 및 설계 능력이며, “중요한 것을 넘어서 가장 기본이 되는 능력”이라고 강하게 말한다.[^6]
여기서 말하는 API는 대규모 서비스의 복잡한 API가 아니라, 많은 준비생이 한 번쯤 해봤을 게시판 CRUD(영상에서는 CUD/CRUD로 표현) 수준의 API를 가리킨다.[^6]

3.2.1 REST 규칙을 지키며 API 리스트를 설계할 수 있는가[^6]

화자는 게시판 CRUD를 설계할 때 “API 리스트를 어떻게 가져가야 하는지”를 고민해야 하며, 핵심은 REST 규칙을 지키면서 설계하는 것이라고 한다.[^6]
REST API라면 “리소스 중심”으로, HTTP 메서드를 제대로 활용해 개발해야 한다고 정리한다.[^6]

영상에서 열거한 REST/HTTP 설계 체크포인트는 다음과 같다.[^6]

• HTTP 메서드 GET/POST/DELETE/PATCH/PUT의 차이를 이해한다.[^6]
• API path에 create/delete 같은 동사를 넣지 않는다.[^6]
• path는 명사의 복수형을 사용하는 식으로 리소스를 표현한다.[^6]
• 단일 리소스는 id를 받아 식별한다.[^6]
• 응답 상태 코드는 상황에 맞게 준수한다:
  • 정상 처리 200
  • 생성 201
  • 반환 바디가 없을 때 204 등[^6]

이 모든 규칙을 지키면서 “가장 간단한 게시판 API 리스트를 설계하고 개발할 수 있는가”가 최소 기준의 핵심 질문이라고 정리한다.[^6]

3.2.2 게시판에는 프론트가 필요: HTML은 직접 구현[^2]

화자는 게시판 기능을 사용하려면 프론트엔드가 필요하다는 점을 언급하며, 여기서 요구하는 프론트 범위를 명확히 그어준다.[^2]

• “간단한 HTML 정도”는 직접 구현해야 한다.[^2]
• CSS는 필요 없고, HTML만 구현하면 된다고 말한다.[^2]

즉 “프론트 프레임워크/디자인”이 아니라, 최소한의 화면(폼/리스트 등)을 통해 CRUD와 인증 흐름을 실제로 사용해볼 수 있는 수준의 HTML을 뜻한다.[^2]

3.2.3 인증/인가 구현: 세션/쿠키와 JWT 모두 이해·구현해야 함[^3]

이어서 화자는 **인증(Authentication)**과 **인가(Authorization)**를 다룬다.[^3]

• 인증: 요청자가 누구인지 확인[^3]
• 인가: 요청자가 해당 작업을 할 권한이 있는지 확인[^3]

구현 방식은 세션/쿠키 방식일 수도, JWT 방식일 수도 있다고 말한다.[^3] 여기서 흔한 오해를 바로잡는다.

[? 질문] JWT가 세션/쿠키보다 더 좋은가[^3]
[= 답] 그렇지 않다. 핵심 차이는 “서버가 기억하느냐/안 하느냐”의 차이이고, 우열의 문제가 아니며 세션/쿠키도 많은 기업이 여전히 사용한다.[^3]

따라서 두 방식 모두 구현해 보고 특징을 이해해야 한다고 결론 내린다.[^3]

또한 인증 이후의 인가 예시를 들어 “권한 처리”가 무엇인지 감을 잡게 한다.[^3]

• 모든 사용자가 “보기”는 가능하지만, “수정”은 작성자만 가능하게 만들기[^3]
• 관리자는 모든 게시글을 볼 수 있게 하는 등 역할에 따른 권한 제어를 해보기[^3]

3.2.4 에러 처리(Validation + 예외 상황)와 HTTP 상태코드/메시지 판단[^4]

다음은 에러 처리다.[^4]
프론트에서 보낸 데이터가 잘못된 경우 밸리데이션을 하게 되는데, 검증을 통과하지 못할 때 또는 핸들링하지 못한 에러가 발생했을 때 적절한 HTTP 상태 코드와 메시지를 판단할 수 있어야 한다고 말한다.[^4]

여기서의 포인트는 “에러가 났다” 수준이 아니라,

• 어떤 상황에 어떤 상태코드를 내려야 하는지[^4]
• 사용자/클라이언트가 이해할 수 있는 메시지/형식으로 응답해야 하는지[^4] 를 결정하는 능력이 포함된다는 점이다.

3.2.5 개발로 끝나면 안 된다: Swagger로 OpenAPI 문서화[^4]

화자는 개발 후 반드시 API 문서화를 해야 하며, 이것이 “굉장히 중요”하다고 강조한다.[^4]
또한 문서화의 형식 기준을 제시한다.

• 노션/구글닥스에 “1번 API…” 식으로 적는 문서화가 아니라[^4]
• OpenAPI 규격에 맞춘 Swagger를 사용해, 자신이 만든 API를 명확하게 문서화해야 한다.[^4]

즉, 협업/검증 가능한 표준 규격 문서화를 최소 기준으로 포함한다는 맥락이다.[^4]

[!TIP] 최소 기준 1을 “면접에서 증명”하는 방식 게시판 CRUD 자체보다, REST 규칙·상태코드·인증/인가·에러 처리·Swagger 문서까지 일관되게 갖추면 “기본기 증명”이 쉬워진다는 흐름으로 읽힌다.[^6]

3.3 최소 기준 2: 데이터베이스(관계형 중심, ERD/SQL/인덱스) — NoSQL은 ‘차이’만[^4]

화자는 두 번째 최소 기준으로 데이터베이스를 제시한다.[^4]
여기서 “백엔드의 3요소”를 언급하며(웹서버/와스/DB 흐름을 뒤에서 다시 연결), 그중 하나로 DB가 중요하다고 위치시킨다.[^4]

3.3.1 NoSQL이 아니라 관계형 DB가 우선[^4]

화자는 MongoDB 같은 NoSQL을 깊게 파는 것이 아니라,

• NoSQL은 “차이점만 알고” 넘어가고[^4]
• 중요한 건 관계형 데이터베이스라고 선을 긋는다.[^4]

3.3.2 무엇을 쓰면 되나: MySQL 또는 PostgreSQL[^5]

관계형 DB 선택에 대해 화자는 “정해주겠다”는 톤으로 구체 권고를 한다.[^5]

• MySQL 또는 PostgreSQL을 쓰라고 말한다.[^5]
• 둘의 차이점/장단점 정도를 공부하고, 하나 정해 쓰면 된다고 정리한다.[^5]

3.3.3 ERD/관계(1:N, 1:1 등)를 설계하고 설명할 수 있어야 함[^5]

관계형 DB의 핵심 역량으로 ERD 설계 및 설명을 든다.[^5]
테이블 간 관계를 이해해야 하며, 예시로 다음을 언급한다.[^5]

• 작성자와 게시글은 1대다(1:N) 관계[^5]
• 계정과 유저는 1대1(1:1) 관계 같은 것들을 이해해야 한다는 식으로 설명한다.[^5]

(영상의 예시는 표현이 다소 구어체이지만, 요지는 “도메인 모델을 관계형 스키마로 매핑하고 관계를 말로 설명”하는 능력이다.)[^5]

3.3.4 SQL을 짤 줄 알아야 한다: ORM만 쓰다 쿼리 못 쓰는 문제 지적[^5]

화자는 “SQL 쿼리 짤 줄 알아야 한다”고 직접 요구한다.[^5]
이유는 나중에 쿼리 최적화 작업을 하려면 SQL을 알아야 하기 때문이라고 연결한다.[^5]

또한 실제 지원자들 중 “ORM만 쓰다 보니 기본 쿼리도 못 쓰는 사람”이 있다고 지적한다.[^5]
그래서 ORM을 쓰더라도, ORM이 생성한 쿼리가 실제 DB에서는 어떤 로우 쿼리로 실행되는지 확인해야 한다고 말한다.[^6]

• ORM 쿼리를 로우 SQL로 출력할 수 있으니[^6]
• “내가 지금 실행하는 쿼리가 어떤 로우 쿼리로 실행되는지” 반드시 확인하라고 강조한다.[^6]

3.3.5 단순 조회가 아니라 조인/서브쿼리/통계 쿼리 + 결과 예측[^6]

화자는 “쿼리는 단순 조회가 아니다”라고 말하며 요구 수준을 올린다.[^6]
다음을 할 줄 알아야 한다고 한다.[^6]

• JOIN을 사용하는 쿼리 작성[^6]
• 서브쿼리를 사용하는 쿼리 작성[^6]
• 단순 조회가 아니라 통계 쿼리를 작성하고[^6]
• 그 결과를 예상할 수 있어야 한다.[^6]

즉, “문법 암기”가 아니라 실제 데이터가 어떤 결과를 만드는지까지 이해하라는 요구다.

3.3.6 인덱스: 간단하지만 DB에 큰 영향을 주며, ‘아무데나’ 걸면 안 됨[^6]

조인과 함께, “간단하면서도 DB에 가장 큰 영향을 미치는 것 중 하나”로 인덱스를 든다.[^6]
그리고 인덱스는 “진짜 잘 써야” 하며, 아무데나 거는 게 아니라[^6]

• 정말 자주 사용하고
• 꼭 필요한 곳에 인덱스를 설정할 줄 알아야 한다고 말한다.[^7]

[!IMPORTANT] DB 최소 기준의 핵심 결 관계형 DB(MySQL/Postgres) 기반으로 ERD 관계 설명 + SQL(조인/통계) + ORM 쿼리 검증 + 인덱스 감각을 갖추는 것이 “신입 최소 기준”이라고 구조화한다.[^6]

3.4 최소 기준 3: 클라우드 배포(AWS EC2 필수, RDS 권장) + 외부에서 접속 검증[^7]

세 번째 최소 기준은 클라우드 배포다.[^7]
화자는 “코드를 로컬에서 실행하는 것에 그치지 않고”, 실제 사용자가 접속할 수 있는 환경에 배포하는 것이라고 정의한다.[^7]

3.4.1 EC2 배포는 필수[^7]

화자는 AWS EC2로 애플리케이션 배포는 필수라고 단언한다.[^7]
단지 “해보면 좋다”가 아니라 “필수”라는 표현을 반복한다.[^7]

3.4.2 RDS까지 해보면 차별점이 된다(EC2만 하는 사람은 많다)[^7]

EC2에 더해 AWS RDS 사용을 강하게 추천한다.[^7]
근거로는, EC2까지는 해본 사람이 많지만 RDS까지 사용해본 사람은 “상대적으로 훨씬 적다”는 관찰을 든다.[^7]
따라서 RDS까지 포함해 클라우드에 배포해보는 것을 강력 추천한다고 정리한다.[^7]

3.4.3 배포 검증: 로컬호스트가 아니라 ‘외부 요청’으로 처리 확인[^7]

EC2에는 IP 주소가 있고, 로컬호스트에서만 접속하는 게 아니라 실제 외부에서 요청을 보내 접속/처리가 되는지 확인해보라고 한다.[^8]
즉, “배포했다”가 아니라 “외부에서 접근 가능한 상태로 만들고, 요청/응답을 확인”하는 것이 최소 역량에 포함된다.[^8]

3.5 최소 기준 4: 전반적인 웹의 흐름(웹서버–WAS–DB 관계) 이해가 ‘정말 중요’[^8]

화자는 네 번째 기준을 “정말 중요”하다고 강하게 말한다.[^8]
많은 초보가 Postman/CURL로 단순히 요청-응답만 해보는 수준에 머무르는데, 실제로 웹의 흐름이 어떻게 진행되는지 이해하는 것이 매우 중요하다고 주장한다.[^8]

그는 “백엔드의 3요소”로 웹(웹서버) + WAS + DB를 다시 언급하면서, 이들의 관계와 흐름을 알고 있어야 한다고 말한다.[^8]

3.5.1 구성요소 예시: 웹서버(Nginx/Apache), WAS(Tomcat/Uvicorn/Node), DB(MySQL/Postgres)[^8]

화자는 각각의 대표 예시를 나열해 초보가 용어를 연결할 수 있게 한다.[^8]

• 웹서버: Nginx, Apache[^8]
• WAS: Tomcat, (Python) Uvicorn, (JS) Node.js[^9]
• DB: MySQL, PostgreSQL[^9]

3.5.2 로그인 요청 흐름 예시로 설명(도메인, Nginx, WAS, FastAPI, DB, 응답 역순)[^9]

화자는 “유저 로그인 과정”을 바탕으로 흐름을 설명한다.[^9]

1. 사용자가 브라우저 로그인 페이지에서 아이디/패스워드를 입력하고 로그인 요청을 보낸다.[^9]
2. 브라우저는 정보를 담아 예시 도메인 example.com의 로그인 주소로 HTTP POST 요청을 전송한다.[^9]
3. 요청은 가장 먼저 웹서버인 Nginx에 도달한다.[^9]
4. Nginx는 보통 설정 파일에 따라 “로그인 요청은 WAS로 넘겨라”처럼, 웹서버에서 처리하기 복잡한 요청을 애플리케이션 서버(WAS)로 프록시한다는 식으로 설명한다.[^10]
5. Nginx가 요청을 WAS로 넘기면, (파이썬 예시로) Uvicorn이 Nginx로부터 HTTP 요청을 받고, FastAPI가 이해할 수 있는 형태로 변환해 애플리케이션에 전달한다고 말한다.[^10]
6. FastAPI 애플리케이션이 아이디/패스워드로 DB를 조회해 성공/실패를 판단하고, 결과를 역순으로 다시 사용자에게 전달한다.[^11]

이 설명은 “매우 간단하게 설명했고 세부 과정은 생략했다”고 덧붙인다.[^11] 하지만 최소한 아래의 추가 요소까지 머릿속에 들어 있어야 한다고 말한다.[^11]

• 도메인이 DNS를 통해 IP로 바뀌는 과정 등[^11]
• 자신이 쓰는 프레임워크(스프링/노드/장고/패스트API)가 이 구조의 “어느 지점(WAS 등)에서 동작하는지”[^11]

따라서 단순히 코드를 짜는 수준이 아니라, 요청이 어디로 들어오고 어디서 처리되며 어떤 컴포넌트가 무슨 역할을 하는지 구조적으로 이해해야 한다고 정리한다.[^11]

3.6 최소 기준 4가지의 정리[^12]

화자는 지금까지 제시한 신입 백엔드 최소 기준을 다음 4가지로 다시 묶어 반복한다.[^12]

1. API 개발 및 설계 능력[^12]
2. 데이터베이스[^12]
3. 클라우드 배포[^12]
4. 전반적인 웹의 흐름[^12]

그리고 “만약 이것들이 모르겠다/잘 이해가 안 된다면 이렇게 대비하라”며 곧바로 대비책(훈련법)으로 전환한다.[^12]

3.7 최소 기준이 안 될 때 대비책 1: REST 게시판 CRUD(+로그인/로그아웃) 직접 만들고, ‘2일 이내’로 반복 훈련[^12]

첫 번째 대비책은 “REST API 게시판 CRUD 만들어 보기”다.[^12]
구체적으로 다음 기능을 포함하라고 말한다.[^12]

• 작성(Create)
• 리스트 조회(List)
• 단일 조회(Read one)
• 업데이트(Update)
• 삭제(Delete)
• 로그인, 로그아웃[^12]

구현 도구는 본인이 배운 백엔드 프레임워크(스프링부트/익스프레스/패스트API/장고 등)로 만들라고 안내한다.[^12]
그리고 연습 방식에 “시간 제약”을 단계적으로 도입한다.[^12]

• 처음에는 기간 신경 쓰지 말고 일단 만들어보기[^12]
• 익숙해지면 2일 이내로 만드는 연습을 해보기[^12]
• 2일 = 하루 8시간 근무 기준으로 16시간 이내 개발 연습[^13]

DB는 “무조건 관계형 DB”를 쓰라고 못 박고, MySQL/Postgres 중 하나를 쓰면 된다고 반복한다.[^13]

[!TIP] “2일/16시간” 제한의 의미 단순 구현 과제가 아니라, 실제 업무처럼 제한된 시간 안에 CRUD+인증+문서화 등을 완성하는 속도/숙련도 기준을 스스로 만들라는 제안이다.[^13]

3.8 대비책 2: DB가 약하면 — ORM 쿼리 출력→로우 SQL 실행, 최소 1번은 JOIN 포함[^13]

“DB를 잘 모르겠다”는 경우의 접근도 게시판 CRUD 실습을 기반으로 한다.[^13]
화자는 게시판 CRUD를 만들면서 다음을 반드시 하라고 한다.[^13]

• ORM이 실행하는 쿼리를 반드시 출력해서 보기[^13]
• “실행하고 끝”이 아니라, 어떤 쿼리가 실행됐는지 확인하기[^13]
• 그 로우 쿼리를 DB에서 직접 실행해보기[^13]

또한 관계형 데이터 모델을 반영한 쿼리를 요구한다.[^13]

• 단일 쿼리만 하지 말고[^13]
• 작성자–게시글 같은 1:N 관계를 전제로[^13]
• 최소한 JOIN이 들어간 쿼리를 한 번은 보고/짜고/실행해보라고 말한다.[^13]

더 깊게 DB를 공부하고 싶다면, 화자는 추천 자료로 정광철 유튜브 채널을 제시한다.[^13]
강의가 17개이고 유튜브라 무료라고 언급하면서 “왜 무료로 듣는지 모르겠다, 꼭 보라”고 강하게 권한다.[^14]

3.9 대비책 3: 클라우드 배포가 약하면 — 게시판을 AWS에 올리고, 인바운드(인그레스) 설정 + (심화) VPC/서브넷 구성[^14]

클라우드 배포 대비는 “첫 번째에서 만든 게시판”을 그대로 활용한다.[^14]
로컬에서 끝내지 말고 AWS에 배포하라고 하며, 다음을 한다.[^14]

• 서버를 EC2에서 실행[^14]
• DB도 RDS를 사용해보기[^14]
• localhost:... 로만 하지 말고 EC2의 IP 주소로 요청을 보내 응답이 오는지 확인[^14]

화자는 처음에는 “제대로 안 될 것”이라고 현실적인 난관을 예고한다.[^14]
그 이유/대응으로 외부 접근을 가능하게 하는 규칙 설정이 필요하다고 말한다.[^14]

• 외부에서 EC2 IP로 접근하도록 인그레스 규칙을 설정해야 한다[^14]
• AWS에서는 이를 인바운드라는 용어로 더 잘 알려져 있다고 덧붙인다.[^15]

3.9.1 배포에 익숙해진 뒤의 심화: 네트워크(VPC) 구성 직접 해보기[^15]

여기까지 익숙해졌다면 더 나아가 “네트워크 설정”도 해보라고 제안한다.[^15] 다만 “좀 어렵다”고 난이도를 표시한다.[^15]
화자가 제시한 심화 실습 예시는 다음과 같다.[^15]

• AWS VPC 생성[^15]
• EC2와 RDS를 프라이빗 서브넷으로 설정하는 구성 언급[^15]
• NAT Gateway와 Internet Gateway를 이용해 “EC2만 외부에서 접근 가능”하도록 구성하는 식으로 클라우드 구조를 잡아보기[^15]

(구어체 설명이므로 세부 구성은 단순화되어 있지만, 의도는 “네트워크 레벨로 구조를 그려보고 손으로 구성”해보라는 것이다.)[^15]
이 과정을 통해 AWS/클라우드가 어떻게 돌아가는지 “머릿속에 그림이 그려질 것”이라고 말한다.[^15]

화자는 이건 강의나 책으로만 보는 게 아니라 직접 해봐야 한다고 반복해서 강조한다.[^15]

3.9.2 비용 주의: 실습 후 EC2/RDS 인스턴스 삭제(요금 폭탄 경험담)[^15]

배포 실습에서의 주의사항도 구체적으로 준다.[^15]

• EC2 비용이 발생할 수 있으니, 프리티어더라도 실습 후 EC2와 RDS 인스턴스를 삭제해야 한다.[^15]
• 본인 경험담으로, 과거에 AWS DocumentDB(노SQL 서비스)를 스터디로 만들었다가 삭제를 깜빡해 “요금 폭탄”을 맞았고, 그때 30만 원 정도 요금이 나온 적이 있다고 말한다.[^16]

그래서 결론은 다음과 같이 정리된다.[^16]

• 클라우드 배포는 “무조건 해봐라”[^16]
• 실습 후에는 “인스턴스를 꼭 삭제하라”[^16]

[!WARNING] 실습형 학습의 ‘숨은 과제’ 배포 능력에는 서버 실행만이 아니라 보안그룹(인바운드) 설정, 외부 접근 확인, 그리고 비용/리소스 정리(삭제) 같은 운영 감각이 포함된다는 메시지를 함께 전달한다.[^15]

3.10 대비책 4: 웹의 흐름이 약하면 — ‘널널한 개발자’ 네트워크 강의(미리보기라도)로 보완[^16]

네 번째(웹의 흐름) 대비책으로, 화자는 “웹의 흐름을 이해하는 것은 매우매우 중요”하다고 다시 한번 강조한다.[^16]
추천 자료로는 영상 제작 시 참고했다고 밝힌 널널한 개발자를 제시한다.[^16]

• 인프런에 “네트워크 핵심 이론” 기초 강의가 있고, 유료(약 7만 원)라고 언급한다.[^16]
• 유료라 보기 어렵다면, 강의의 미리보기로 공개된 부분이라도 꼭 보라고 권한다.[^17]
• 특히 “36강: 그림 한 장으로 외워서 끝내는 웹서비스 구조 이론”을 콕 집어 추천하며, 정말 쉽게 설명해준다고 말한다.[^17]

이 강의를 보면 웹서버–WAS–DB 관계가 이해될 것이라고 연결한다.[^17]

3.11 마무리: 기준 제안 + 댓글로 추가 기준 요청[^17]

화자는 여기까지가 본인이 생각하는 “신입 백엔드 최소 기준과 대비책”이라고 정리한다.[^17]
그리고 본인이 제시한 것 외에도, 시청자가 생각하는 최소 기준이나 특히 중요하다고 생각하는 항목이 있다면 댓글에 남겨달라고 요청하며 영상을 마친다.[^17]

4. 핵심 통찰[^1]

1. 신입에게 요구되는 “최소 기준”은 거창한 아키텍처가 아니라, CRUD·인증·문서화·DB·배포·웹흐름 같은 기본기를 “끝까지 완주”하는 능력으로 정의된다.[^6]
   • 실행: 게시판 프로젝트를 기능/품질 체크리스트(REST, 상태코드, 권한, Swagger)로 완성해보기.[^6]
2. JWT vs 세션/쿠키는 유행/우열 문제가 아니라 “상태 관리 방식 차이”로 이해해야 하며, 기업에서 둘 다 쓰이니 둘 다 구현 경험이 필요하다는 관점이 제시된다.[^3]
   • 실행: 같은 로그인 기능을 세션/쿠키 방식과 JWT 방식으로 각각 구현해보고, 차이를 문서로 정리하기.[^3]
3. DB는 NoSQL보다 먼저 관계형 DB를 깊게 다져야 하며, ORM을 쓰더라도 “로우 SQL로 무엇이 실행되는지”를 확인해야 실무 최적화로 이어진다는 문제의식이 깔려 있다.[^6]
   • 실행: ORM 쿼리 로그 출력 → 동일 쿼리를 DB에서 직접 실행 → 실행계획/인덱스 후보를 고민해보기.[^6]
4. 배포 역량은 “서버에 올림”이 아니라, **외부 접근 가능하게 만들기(인바운드/인그레스)**와 검증, 그리고 비용 관리(리소스 삭제)까지 포함된다는 실전 관점이 강조된다.[^14]
   • 실행: EC2+RDS 배포 후, 외부에서 실제 요청 테스트 / 실습 종료 후 리소스 삭제 루틴 만들기.[^16]
5. 웹서비스 구조 이해는 Postman으로는 채워지지 않고, 웹서버–WAS–애플리케이션–DB로 이어지는 “요청 처리 파이프라인”을 설명할 수 있어야 한다는 기준을 제시한다.[^9]
   • 실행: 로그인 요청 1건이 DNS→Nginx→WAS→앱→DB→응답으로 흐르는 과정을 그림으로 그려 말로 설명 연습하기.[^11]
6. “2일/16시간 내 게시판 완성” 같은 시간 제한은, 신입이 반복을 통해 생산성/숙련도를 정량화하는 장치로 사용될 수 있다는 함의가 있다.[^13]
   • 실행: 동일 과제를 3~5회 반복하며 목표 시간을 단계적으로 단축하고, 체크리스트로 품질(문서/에러/권한)을 유지하기.[^13]

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

REST API: 리소스(명사) 중심으로 URI를 설계하고, HTTP 메서드(GET/POST/DELETE/PATCH/PUT)로 행위를 표현하는 스타일. 경로에 create/delete 같은 동사를 넣지 않는 등 규칙을 지키라고 설명된다.[^6]
인증(Authentication): 요청자가 누구인지 확인하는 절차.[^3]
인가(Authorization): 인증된 사용자가 특정 작업을 수행할 권한이 있는지 확인하는 절차(예: 작성자만 수정, 관리자는 전체 열람).[^3]
세션/쿠키 방식: 서버가 로그인 상태(세션)를 “기억”하는 전통적 인증 방식으로, 여전히 많은 기업이 사용한다고 언급된다.[^3]
JWT: 토큰 기반 인증 방식으로, 세션/쿠키 대비 “더 좋다”가 아니라 서버 상태 기억 여부 등 성격 차이라고 설명된다.[^3]
Swagger / OpenAPI: 노션/구글닥스식 문서가 아니라, OpenAPI 규격 기반 도구(Swagger)로 API를 명확히 문서화하라고 제시된다.[^4]
ERD: 관계형 DB에서 테이블 간 관계(1:1, 1:N 등)를 설계/표현하는 도식(엔터티-관계 다이어그램)으로, 설계하고 설명할 수 있어야 한다.[^5]
ORM: 객체-관계 매핑 도구. ORM만 쓰다 SQL을 못 쓰는 문제를 지적하며, ORM이 실제로 어떤 로우 SQL을 실행하는지 출력해서 확인하라고 한다.[^6]
인덱스(Index): DB 성능에 큰 영향을 줄 수 있는 구조로, 아무 데나 걸지 말고 자주/필요한 곳에 설정하라고 강조된다.[^6]
EC2: AWS의 가상 서버 서비스로, 애플리케이션 배포가 “필수”라고 언급된다.[^7]
RDS: AWS의 관리형 DB 서비스. EC2만 하는 사람보다 RDS까지 해본 사람이 적으니 함께 해보라고 권한다.[^7]
인그레스 규칙 / 인바운드: 외부에서 EC2로 접근 가능하게 만드는 접근 규칙 설정을 말하며, AWS에서는 인바운드로 더 잘 알려져 있다고 설명한다.[^14]
웹서버: Nginx/Apache 같은 구성요소. 요청을 받아 WAS로 넘기는 역할 예시가 나온다.[^9]
WAS: Tomcat/Uvicorn/Node.js 같은 애플리케이션 서버 계층. 웹서버에서 넘긴 요청을 애플리케이션이 처리하도록 연결한다고 설명된다.[^10]
DNS: 도메인이 IP로 바뀌는 과정이 흐름 이해에 포함된다고 언급된다.[^11]

---

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

• 제목: 신입 백엔드 개발자 업무역량에 대한 최소 기준과 대비책[^1]
• 채널: 원투코딩 OneTwoCoding[^1]
• 길이: 18분 3초[^1]
• 링크: https://www.youtube.com/watch?v=vixYMoSJZfE[^1]

[^1]: 제공된 영상 정보(제목/채널/길이/링크) 및 전체 대본. [^2]: @[02:18] “게시판이니까… 프론트엔드… 필요한 간단한 HTML… CSS 같은 거는 필요 없고… HTML에만…” [^3]: @[00:03] 지원자 100~200명, “전쟁터”, 신입 불리, 최소 기준 필요 / @[03:10] 인증·인가 정의, 세션/쿠키 vs JWT 우열 아님, 둘 다 이해. [^4]: @[03:44] 에러 처리와 상태코드/메시지 / @[04:15] Swagger(OpenAPI)로 문서화 / @[04:52] NoSQL이 아니라 관계형 DB. [^5]: @[05:11] MySQL 또는 PostgreSQL 권고 / @[05:24] ERD·관계(1:N, 1:1) / @[05:47] SQL 필요, ORM만 쓰다 쿼리 못 짬. [^6]: @[01:06] 최소 기준 1: API 개발/설계, 게시판 CRUD, REST 규칙·상태코드 / @[06:06] ORM 쿼리 로우 SQL로 확인, 조인/서브쿼리/통계, 인덱스. [^7]: @[06:53] 인덱스는 자주/필요한 곳만 / @[07:13] EC2 배포 필수, RDS 추천. [^8]: @[07:48] EC2 IP로 외부 요청 테스트 / @[08:11] 웹 흐름 이해 “정말 중요”. [^9]: @[09:18] 로그인 요청, example.com에 POST / @[09:46] Nginx 도달, 웹서버/WAS/DB 예시 나열. [^10]: @[10:04] Nginx 설정으로 로그인 요청을 WAS로 전달 / @[10:37] Uvicorn이 HTTP 요청 받고 FastAPI 형태로 변환해 앱 전달. [^11]: @[10:59] 앱이 DB 조회 후 역순으로 응답 / @[11:21] DNS로 도메인→IP, 프레임워크가 어디서 동작하는지 이해 필요. [^12]: @[12:00] 최소 기준 4가지 정리 후 대비책 안내 / @[12:23] 게시판 CRUD(+로그인/로그아웃) 만들기. [^13]: @[12:43] 익숙해지면 2일 이내, 16시간 연습 / @[13:17] ORM 쿼리 출력·로우 SQL 실행·JOIN 포함. [^14]: @[13:48] 정광철 유튜브 추천 / @[14:15] 게시판을 AWS에 배포(EC2+RDS), IP로 요청, 인그레스/인바운드 설정. [^15]: @[15:10] VPC/서브넷/NAT/IGW 구성 실습 제안 / @[15:45] 비용 주의, 인스턴스 삭제. [^16]: @[16:05] 삭제 깜빡해 30만 원 요금 폭탄 경험, 배포는 무조건 해보고 삭제 / @[16:40] 웹 흐름 중요, 널널한 개발자 인프런 강의 언급. [^17]: @[17:10] 미리보기라도 시청 권장, 36강 추천 / @[17:47] 마무리, 댓글 요청.