[ZBF] CS / FRONTEND 멘토링 준비

이 글은 네이버 블로그에 2024년 6월 9일에 올렸던 것을 그대로 옮겨온 것입니다.

DNS에 대해 설명해 주세요.

DNS(Domain Name System)는 도메인 이름과 IP 주소를 매핑하는 시스템으로, 인터넷의 전화번호부 역할을 합니다. 사용자가 이해하기 쉬운 도메인 이름(예: www.example.com)을 숫자로 된 IP 주소(예: 192.0.2.1)로 변환해 주는 역할을 합니다.

주요 역할:

1. 도메인 이름과 IP 주소 매핑:

• DNS는 도메인 이름과 해당하는 IP 주소를 저장하고, 이를 사용자가 요청할 때 제공하여 웹사이트에 접근할 수 있게 합니다.

2. 사용자 편의성 제공:

• 사용자가 기억하기 어려운 숫자로 된 IP 주소 대신 이해하기 쉬운 도메인 이름을 사용하여 웹사이트에 접근할 수 있게 합니다.

DNS 작동 원리:

1. 도메인 이름 입력:

• 사용자가 브라우저 주소창에 도메인 이름을 입력합니다.

2. DNS 조회:

• 브라우저는 먼저 로컬 DNS 캐시를 확인하여 해당 도메인의 IP 주소가 있는지 확인합니다.

• 로컬 캐시에 없으면, 브라우저는 설정된 DNS 서버(보통 ISP 제공)를 통해 도메인 이름의 IP 주소를 조회합니다.

3. DNS 질의 과정:

• 루트 DNS 서버: 요청을 받아 최상위 도메인(TLD) 서버의 주소를 반환합니다.

• TLD DNS 서버: 요청을 받아 해당 도메인의 권한 있는 DNS 서버의 주소를 반환합니다.

• 권한 있는 DNS 서버: 최종적으로 도메인 이름에 대응하는 IP 주소를 반환합니다.

4. IP 주소 반환:

• 조회된 IP 주소를 브라우저에 반환하고, 브라우저는 해당 IP 주소로 웹 서버에 요청을 보냅니다.

5. 웹 페이지 로딩:

• 브라우저는 반환된 IP 주소를 사용하여 웹 서버와 통신을 시작하고, 웹 페이지를 로딩합니다.

브라우저 주소창에 www.google.com을 입력하면 발생하는일

1. 도메인 이름 입력:

• 사용자가 웹 브라우저 주소창에 [www.google.com을 입력합니다.](http://www.google.com%60%EC%9D%84%C2%A0%EC%9E%85%EB%A0%A5%ED%95%A9%EB%8B%88%EB%8B%A4.)

2. DNS 캐시 확인:

• 웹 브라우저는 먼저 로컬 DNS 캐시를 확인하여 해당 도메인 이름과 대응하는 IP 주소가 있는지 확인합니다.

3. DNS 요청:

• 로컬 DNS 캐시에 해당 IP 주소가 없으면, 브라우저는 설정된 DNS 서버(보통 ISP 제공)에게 입력된 도메인 이름의 IP 주소를 요청합니다.

4. DNS 응답:

• DNS 서버가 해당 도메인 이름에 대응하는 IP 주소를 찾아 브라우저에 응답합니다.

5. TCP 연결 설정:

• 브라우저는 반환된 IP 주소를 사용하여 Google 웹 서버와 TCP 연결을 설정합니다. 이 과정에서 3-way 핸드셰이크가 이루어집니다.

6. HTTP/HTTPS 요청 전송:

• TCP 연결이 설정되면, 브라우저는 HTTP 또는 HTTPS 요청을 Google 웹 서버에 전송하여 HTML 문서를 요청합니다.

7. 서버 처리:

• Google 웹 애플리케이션 서버(WAS)와 데이터베이스가 요청을 처리합니다.

8. 응답 전송:

• 처리된 결과를 Google 웹 서버로 전송하고, 웹 서버는 브라우저에게 HTML 문서를 응답합니다.

9. 웹 페이지 렌더링:

• 브라우저는 받은 HTML 문서를 파싱하고, 추가 리소스(CSS, JavaScript, 이미지 등)에 대한 요청을 처리합니다.

• 브라우저는 최종적으로 웹 페이지를 화면에 렌더링하여 사용자에게 보여줍니다.

브라우저 렌더링 과정을 설명해 주세요.

1. HTML 파싱 및 DOM 트리 구축:

• 브라우저는 HTML 문서를 파싱하여 DOM(Document Object Model) 트리를 구축합니다. 이 트리는 HTML 요소들을 노드로 표현한 구조입니다.

2. CSS 파싱 및 CSSOM 트리 구축:

• 브라우저는 CSS 파일과 \<style> 태그 내의 스타일을 파싱하여 CSSOM(CSS Object Model) 트리를 구축합니다. 이 트리는 스타일 규칙들을 노드로 표현한 구조입니다.

3. JavaScript 파싱 및 실행:

• 브라우저는 \<script> 태그를 만나면 HTML 파싱을 중단하고 JavaScript 코드를 파싱하고 실행합니다. 이 과정에서 DOM이나 CSSOM이 변경될 수 있습니다.

• async 또는 defer 속성이 없는 \<script> 태그는 HTML 파싱을 중단시키고, 스크립트가 실행된 후에 다시 HTML 파싱을 계속합니다.

4. 렌더 트리(Render Tree) 구축:

• 브라우저는 DOM과 CSSOM을 조합하여 렌더 트리(Render Tree)를 구축합니다. 렌더 트리는 화면에 표시될 요소들만 포함하며, 각 요소의 스타일 정보를 포함합니다.

5. 레이아웃 계산:

• 브라우저는 렌더 트리의 각 노드가 뷰포트에서 가지는 정확한 위치와 크기를 계산합니다. 이 과정을 레이아웃 또는 리플로우(reflow)라고 합니다.

6. 페인팅(Painting):

• 브라우저는 계산된 위치와 크기를 기반으로 렌더 트리의 각 노드를 화면에 그림(painting) 작업을 수행합니다. 이 과정에서 요소의 색상, 글꼴, 크기 등을 적용하여 최종적으로 화면에 표시합니다.

URI와 URL의 차이에 대해 설명해 주세요.

URI (Uniform Resource Identifier):

• 통합 자원 식별자로, 인터넷상의 리소스(자원) 자체를 식별하는 고유한 문자열 시퀀스입니다.

• URI는 리소스를 식별할 수 있는 모든 유형의 식별자를 포함합니다.

URL (Uniform Resource Locator):

• 통합 자원 위치로, 네트워크상의 리소스(자원)의 위치를 나타내기 위한 규약입니다.

• URL은 리소스의 위치를 포함하여 해당 리소스에 접근하는 방법을 제공합니다.

REST(Representational State Transfer API)란 무엇인가요?

RESTful API는 Representational State Transfer (REST) 아키텍처 스타일을 따르는 API입니다. 이는 리소스(데이터)를 HTTP 메소드를 통해 접근하는 방식을 사용합니다. 주요 HTTP 메소드로는 GET(데이터 조회), POST(데이터 생성), PUT(데이터 수정), DELETE(데이터 삭제)가 있습니다. RESTful API는 클라이언트와 서버 간의 통신을 간단하고 효율적으로 만들어 주며, 각 요청은 고유한 URL을 통해 특정 리소스를 나타냅니다.

REST 설계 규칙:

1. 슬래시(/):

• 슬래시는 계층 관계를 나타내는 데 사용합니다.

• 예: /users/123 (123번 사용자)

2. URI 마지막 문자:

• URI 마지막 문자로 슬래시를 포함하지 않습니다.

• 예: /users/123 (올바른 예), /users/123/ (잘못된 예)

3. 하이픈(-):

• 불가피하게 긴 URI를 사용할 때 하이픈을 사용하여 가독성을 높입니다.

• 예: /my-resource-list

4. 밑줄(_):

• 밑줄은 사용하지 않습니다. 대신 하이픈을 사용합니다.

• 예: /my_resource_list (잘못된 예), /my-resource-list (올바른 예)

5. 파일 확장자:

• 파일 확장자는 URI에 포함하지 않습니다.

• 예: /users (올바른 예), /users.json (잘못된 예)

6. 자원 명칭:

• 자원은 동사보다 명사로 표현하며, 대문자보다는 소문자로 표현합니다.

• 예: /users (사용자 목록), /users/123 (특정 사용자)

JWT란 무엇인가요?

JWT(JSON Web Token)는 JSON 객체를 사용하여 두 개체 간에 정보를 안전하게 전송하기 위한 컴팩트하고 자가 포함된 토큰입니다. JWT는 주로 인증과 정보 교환에 사용됩니다.

구성 요소:

JWT는 세 부분으로 구성됩니다:

1. 헤더 (Header):

• 토큰의 타입(JWT)과 해싱 알고리즘(예: HMAC SHA256)을 지정합니다.

2. 페이로드 (Payload):

• 토큰에 포함될 클레임(claims)을 담고 있습니다. 클레임은 엔터티(사용자)와 관련된 정보(예: 사용자 ID, 만료 시간 등)를 포함합니다.

3. 서명 (Signature):

• 헤더와 페이로드를 인코딩한 후, 지정된 비밀 키를 사용하여 서명을 생성합니다. 서명은 토큰의 무결성과 출처를 검증하는 데 사용됩니다.

사용 방법:

1. 토큰 생성:

• 서버는 사용자가 로그인을 성공하면 JWT를 생성하고 사용자에게 전달합니다.

• 생성된 JWT는 클라이언트(브라우저, 모바일 앱 등)에 저장됩니다. 보통 HTTP 쿠키 또는 로컬 스토리지에 저장됩니다.

2. 토큰 전송:

• 클라이언트는 인증이 필요한 요청을 서버로 보낼 때, JWT를 HTTP 헤더(예: Authorization: Bearer \<token>)에 포함하여 전송합니다.

3. 토큰 검증:

• 서버는 클라이언트로부터 받은 JWT를 검증합니다. 헤더와 페이로드를 디코딩하고, 서명을 확인하여 토큰의 무결성과 출처를 검증합니다.

• 검증이 성공하면, 페이로드에 포함된 정보를 사용하여 사용자를 인증합니다.

장점:

1. 자가 포함:

• JWT는 클레임을 자체적으로 포함하므로, 별도의 서버 저장소 없이도 사용자 정보를 안전하게 전송할 수 있습니다.

2. 컴팩트:

• JWT는 URL로 안전하게 전달될 수 있도록 작은 크기로 설계되었습니다. 따라서 HTTP 헤더나 URL 경로에 쉽게 포함될 수 있습니다.

3. 무결성 보장:

• 서명을 통해 토큰의 무결성과 출처를 검증할 수 있어, 데이터 변조를 방지합니다.

사용 사례:

• 사용자 인증 및 권한 부여

• 정보 교환 (예: 사용자 정보, 세션 상태 등)

• 마이크로서비스 간의 안전한 통신

CORS가 무엇이며, 해결하기 위한 방법에 대해 설명해 주세요.

CORS(Cross-Origin Resource Sharing)란 교차 출처 리소스 공유란 뜻이며, 웹 페이지가 제공하는 도메인이 아닌 다른 도메인에서 리소스를 요청하는 것을 의미합니다. 브라우저는 CORS 에러를 발생시켜 악의적인 스크립트가 중요한 데이터에 접근하거나 무단 요청하지 못하도록 방지합니다.

[해결 방법]

1. 프록시 서버 설정

프록시 서버를 설정하여 동일 출처 정책을 우회할 수 있습니다. 클라이언트는 프록시 서버를 통해 다른 도메인에 요청을 보내게 됩니다.

2. 서버에서 CORS 헤더를 추가하여 특정 도메인의 요청을 허용

서버에서 응답 헤더에 CORS 관련 헤더를 추가하면 특정 도메인에서의 요청을 허용할 수 있습니다. 필요한 헤더는 다음과 같습니다:

• Access-Control-Allow-Origin: *

모든 도메인에서의 요청을 허용합니다. 특정 도메인만 허용하려면 "*" 대신 도메인 주소를 명시합니다.

• Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS

허용할 HTTP 메서드를 지정합니다.

• Access-Control-Allow-Headers: Content-Type, Authorization

허용할 요청 헤더를 지정합니다.

• Access-Control-Max-Age: 86400

사전 요청(preflight request)의 응답을 캐시할 시간을 지정합니다.

3. Chrome 확장 프로그램 "Allow CORS" 사용

개발 단계에서만 사용하는 방법으로, Chrome 확장 프로그램을 사용하여 브라우저에서 CORS 정책을 임시로 무시할 수 있습니다. 실제 배포 시에는 사용하지 않는 것이 좋습니다.

로컬 스토리지, 세션 스토리지, 쿠키에 대해 설명해주세요.

로컬 스토리지 (Local Storage)

로컬 스토리지는 웹 브라우저에서 제공하는 저장소로, 웹 페이지가 닫히거나 브라우저를 종료해도 데이터가 유지됩니다. 주로 사용자 설정이나 상태 정보를 저장하는 데 사용됩니다.

• 특징:

• 데이터는 영구적으로 저장됩니다.

• 데이터 용량은 약 5MB로, 쿠키보다 많은 양을 저장할 수 있습니다.

• 서버와의 통신 없이 클라이언트 측에서 데이터를 읽고 쓸 수 있습니다.

세션 스토리지 (Session Storage)

세션 스토리지는 로컬 스토리지와 비슷하지만, 세션이 끝날 때(브라우저 탭이나 창을 닫을 때) 데이터가 삭제됩니다. 탭별로 독립적인 저장소를 제공합니다.

• 특징:

• 데이터는 브라우저 탭이나 창이 닫히면 삭제됩니다.

• 데이터 용량은 약 5MB로, 쿠키보다 많은 양을 저장할 수 있습니다.

• 동일한 창이나 탭 내에서만 데이터가 유지됩니다.

쿠키 (Cookies)

쿠키는 작은 데이터 파일로, 클라이언트와 서버 간의 상태 정보를 저장하고 전송하는 데 사용됩니다. 주로 인증 정보, 사용자 추적 및 설정 정보를 저장하는 데 사용됩니다.

• 특징:

• 데이터는 만료 시간을 설정할 수 있으며, 만료 시간이 지나면 삭제됩니다.

• 데이터 용량은 약 4KB로, 로컬 스토리지나 세션 스토리지보다 적은 양을 저장할 수 있습니다.

• 서버와의 요청 및 응답 시 자동으로 전송됩니다.

웹소켓(WebSocket)에 대해 설명해주세요.

웹소켓은 웹 애플리케이션에서 클라이언트와 서버 간의 양방향 통신을 가능하게 하는 프로토콜입니다. HTTP와 달리 웹소켓은 연결을 유지한 상태에서 실시간으로 데이터를 주고받을 수 있습니다. 주요 특징은 다음과 같습니다:

1. 양방향 통신: 클라이언트와 서버가 동시에 메시지를 주고받을 수 있습니다. 이는 실시간 채팅, 주식 거래 시스템 등 실시간 데이터 교환이 필요한 애플리케이션에 유용합니다.

2. 지속적인 연결: 웹소켓 연결은 한 번 설정되면 끊어지기 전까지 지속됩니다. 이는 지속적인 데이터 스트림이 필요한 애플리케이션에서 성능을 향상시킵니다.

3. 낮은 오버헤드: HTTP의 경우 요청-응답마다 헤더 정보를 포함해야 하지만, 웹소켓은 처음 연결할 때만 핸드셰이크 과정이 필요하며 그 이후에는 최소한의 오버헤드로 데이터 전송이 가능합니다.

4. 표준화: 웹소켓은 IETF에 의해 RFC 6455로 표준화되었으며, 대부분의 현대 웹 브라우저에서 지원됩니다.

HTTP와 HTTPS의 차이

HTTP와 HTTPS는 웹에서 사용되는 두 가지 프로토콜로, 주요 차이는 보안입니다. 자세한 차이는 다음과 같습니다:

1. 보안:

• HTTP (HyperText Transfer Protocol): 데이터를 암호화하지 않고 전송합니다. 따라서 전송 중 데이터가 중간에서 탈취되거나 변조될 수 있는 위험이 있습니다.

• HTTPS (HyperText Transfer Protocol Secure): HTTP에 SSL/TLS 암호화 계층을 추가하여 데이터를 암호화합니다. 이를 통해 데이터의 기밀성과 무결성을 보장합니다.

2. 포트 번호:

• HTTP: 기본적으로 80번 포트를 사용합니다.

• HTTPS: 기본적으로 443번 포트를 사용합니다.

3. SSL/TLS 인증서:

• HTTP: 인증서를 사용하지 않습니다.

• HTTPS: SSL/TLS 인증서를 사용하여 서버의 신원을 인증하고, 클라이언트와 서버 간의 암호화된 연결을 설정합니다.

4. 성능:

• HTTP: 암호화 과정이 없으므로 HTTPS보다 빠를 수 있습니다.

• HTTPS: 암호화 및 복호화 과정 때문에 HTTP보다 약간 느릴 수 있지만, 하드웨어와 네트워크 최적화로 인해 성능 차이는 최소화되고 있습니다.

5. SEO 및 사용자 신뢰:

• HTTPS: 구글 등 검색 엔진에서 HTTPS를 사용하는 웹사이트를 선호하며, 사용자에게 더 신뢰감을 줍니다. 특히 민감한 정보를 다루는 웹사이트는 반드시 HTTPS를 사용해야 합니다.

페이지 로드 시간을 줄이는 방법들에 대해서 설명해 주세요.

1. 이미지 최적화: 이미지 크기를 줄이고, 적절한 포맷(JPEG, PNG, WebP)을 사용합니다.

2. 브라우저 캐싱: 자주 변경되지 않는 리소스를 캐싱하여 재방문 시 로드 시간을 단축합니다.

3. 코드 압축 및 축소: JavaScript와 CSS 파일을 압축하고, 불필요한 공백과 주석을 제거하여 파일 크기를 줄입니다.

4. 콘텐츠 전송 네트워크 (CDN): CDN을 사용하여 지리적으로 가까운 서버에서 리소스를 제공함으로써 로드 시간을 단축합니다.

5. 비동기 로딩: JavaScript 파일을 비동기로 로드하여 페이지 렌더링을 차단하지 않도록 합니다.

6. 지연 로딩 (Lazy Loading): 사용자 화면에 보이지 않는 이미지나 콘텐츠를 나중에 로드하여 초기 로드 시간을 단축합니다.

테스트 코드에 대해 설명해 주세요.

테스트 코드는 소프트웨어의 기능이 기대한 대로 작동하는지 확인하기 위해 작성된 코드입니다. 주요 테스트의 종류는 다음과 같습니다:

1. 유닛 테스트 (Unit Test): 개별 모듈이나 함수가 올바르게 동작하는지 확인합니다.

2. 통합 테스트 (Integration Test): 여러 모듈이나 시스템이 함께 동작하는지 확인합니다.

3. 엔드 투 엔드 테스트 (End-to-End Test): 애플리케이션 전체가 사용자 관점에서 올바르게 동작하는지 확인합니다.

4. 회귀 테스트 (Regression Test): 새로운 변경 사항이 기존 기능에 영향을 주지 않는지 확인합니다.

웹 서비스 배포 시스템 구축 경험이 있으신가요?

최근 프로젝트에서 Jenkins와 Mustard를 사용하여 효율적인 웹 배포 파이프라인을 구축한 경험이 있습니다. Jenkins를 CI/CD 도구로 활용하여 코드 변경 사항이 푸시될 때마다 자동으로 빌드, 테스트, 배포가 이루어지도록 설정했습니다. 이를 통해 코드 품질을 유지하고 배포 프로세스를 자동화했습니다. 또한, Mustard를 사용하여 각 배포 단계를 시각화하고, 배포 히스토리를 관리함으로써 문제 발생 시 빠르게 대응할 수 있었습니다. 이러한 자동화 파이프라인을 통해 배포 주기를 단축시키고, 팀의 생산성을 크게 향상시킬 수 있었습니다.

CI/CD에 대해 설명해 주세요.

CI/CD는 Continuous Integration and Continuous Deployment/Delivery의 약자입니다.

• Continuous Integration (CI): 개발자들이 변경한 코드를 정기적으로 리포지토리에 통합하여 빌드와 테스트를 자동화합니다.

• Continuous Deployment (CD): CI에서 통합된 코드를 자동으로 프로덕션 환경에 배포합니다.

• Continuous Delivery (CD): CI에서 통합된 코드를 프로덕션에 배포할 준비를 자동으로 합니다. 실제 배포는 수동으로 이루어질 수 있습니다.

CI/CD의 주요 장점:

• 코드 변경 사항을 신속하게 배포하여 시장 출시 시간을 단축합니다.

• 빌드 및 배포 프로세스의 자동화로 개발 효율성을 높이고 인적 오류를 줄입니다.

• 지속적인 테스트를 통해 코드 품질을 보장합니다.

객체 지향 프로그래밍에 대해 설명해 주세요.

객체 지향 프로그래밍(OOP, Object-Oriented Programming)은 프로그램을 객체들의 모임으로 구성하여 개발하는 방식입니다. 객체는 데이터(속성)와 이 데이터를 처리하는 함수(메서드)를 포함하는 단위입니다. OOP의 주요 개념에는 캡슐화, 상속, 다형성, 추상화가 있습니다.

• 캡슐화: 데이터를 보호하기 위해 객체의 속성과 메서드를 하나로 묶고, 외부에서 접근할 수 없도록 제한합니다.

• 상속: 새로운 클래스가 기존 클래스의 속성과 메서드를 상속받아 재사용하고 확장할 수 있게 합니다.

• 다형성: 동일한 메서드 이름이 다양한 객체에서 다르게 동작할 수 있습니다.

• 추상화: 객체의 복잡성을 줄이고, 필요한 인터페이스만을 노출합니다.

프로세스와 스레드의 차이에 대해 설명해 주세요.

• 프로세스:

• 프로그램이 실행된 인스턴스로, 독립된 메모리 공간을 가집니다.

• 운영 체제에서 자원을 할당받아 실행됩니다.

• 서로 독립적이므로, 한 프로세스의 오류가 다른 프로세스에 영향을 미치지 않습니다.

• 스레드:

• 프로세스 내에서 실행되는 단위로, 프로세스의 자원을 공유합니다.

• 한 프로세스 내에서 여러 스레드가 병렬로 실행될 수 있습니다.

• 자원을 공유하므로, 하나의 스레드에서 발생한 오류가 같은 프로세스의 다른 스레드에 영향을 줄 수 있습니다.

멀티 프로세스와 멀티 스레드의 차이에 대해 설명해 주세요.

• 멀티 프로세스:

• 여러 프로세스를 병렬로 실행하여 작업을 분할합니다.

• 각 프로세스는 독립된 메모리 공간을 사용하며, 프로세스 간의 통신은 IPC(Inter-Process Communication)를 통해 이루어집니다.

• 안정성이 높지만, 프로세스 간의 문맥 전환 비용이 높습니다.

• 멀티 스레드:

• 하나의 프로세스 내에서 여러 스레드를 병렬로 실행하여 작업을 분할합니다.

• 스레드들은 프로세스의 메모리와 자원을 공유하므로, 빠른 문맥 전환이 가능합니다.

• 자원 공유로 인해 동기화 문제가 발생할 수 있으며, 안정성 면에서 다소 취약할 수 있습니다.

Stack과 Queue의 차이에 대해 설명해 주세요.

• Stack(스택):

• LIFO(Last In, First Out) 구조로, 나중에 추가된 요소가 먼저 제거됩니다.

• 주로 함수 호출, 되돌리기 기능 등에서 사용됩니다.

• 주요 연산: push(추가), pop(제거), peek(탑 요소 확인).

• Queue(큐):

• FIFO(First In, First Out) 구조로, 먼저 추가된 요소가 먼저 제거됩니다.

• 주로 작업 대기열, 프로세스 스케줄링 등에서 사용됩니다.

• 주요 연산: enqueue(추가), dequeue(제거), front(첫 요소 확인).

List, Map, Set의 차이점을 설명해 주세요.

• List(리스트):

• 순서가 있는 요소들의 컬렉션으로, 중복 요소를 허용합니다.

• 인덱스를 사용하여 요소에 접근할 수 있습니다.

• 예: 배열(Array), 연결 리스트(LinkedList).

• Map(맵):

• 키-값 쌍으로 이루어진 컬렉션으로, 키는 중복될 수 없고, 값은 중복될 수 있습니다.

• 키를 사용하여 값에 접근할 수 있습니다.

• 예: 해시맵(HashMap), 트리맵(TreeMap).

• Set(셋):

• 중복되지 않는 요소들의 컬렉션으로, 순서가 없습니다.

• 중복을 허용하지 않으므로, 유일한 값들의 집합을 표현할 때 사용됩니다.

• 예: 해시셋(HashSet), 트리셋(TreeSet).

라이브러리와 프레임워크의 차이점을 설명해 주세요.

• 라이브러리:

• 특정 기능을 모듈화하여 제공하는 코드 집합입니다.

• 개발자가 필요한 기능을 호출하여 사용합니다.

• 개발자가 흐름을 제어하며, 라이브러리는 이를 돕는 도구로 사용됩니다.

• 예: jQuery, Lodash.

• 프레임워크:

• 애플리케이션의 구조와 흐름을 제공하는 전체적인 틀입니다.

• 개발자가 프레임워크의 규칙과 구조에 맞춰 코드를 작성합니다.

• 프레임워크가 흐름을 제어하며, 개발자는 특정 부분을 구현합니다.

• 예: React, Angular, Django.