⭕️ Today I Learned
매일 할 일 ✅ ❌
✅ 1일 1커밋
❌ 1일 1알고리즘 문제 풀이
✅ 1일 2기술면접 개념 정리
✏️ 오늘 한 공부
알고리즘 문제풀이
백준
기술 면접 대비 개념 공부
[ 기술 면접 대비 개념 정리 통합본 ]
31. 대용량 트래픽 발생 시 어떻게 대응해야 하나요?
로드 밸런서를 이용하여 여러대의 서버가 분산 처리하도록 합니다.
클라우드 서비스 제공 업체의 오토 스케일링 기능(서버의 부하를 체크하여 서버를 생성하는 방식)을 사용해 봅니다.
데이터 베이스 샤딩을 적용(DB 테이블을 수평 분할하여 물리적으로 서로 다른곳에 분산 저장)
데이터베이스 레플리카 적용
서버를 스케일 업합니다.
정적 컨텐츠에 대해 CDN 서비스를 이용하여 컨텐츠 다운 시간을 단축시킵니다.
API의 응답속도를 단축시키위해 코드를 리팩토링해봅니다.
32. ORM을 사용하면서 쿼리가 복잡해지는 경우에는 어떻게 해결하는게 좋을까요?
일단 JPA 자체는 정적인 상황에서 사용하는걸 권장하기 때문에 복잡한 쿼리와 동적인 쿼리에 대한 문제가 발생하게 되는데, 그럴때는 JPQL과 Querydsl을 사용할 것을 권장하고 있습니다.
33. GET, POST의 개념과 함께 데이터 흐름에 대해서 설명해주세요.
GET 메서드:
GET 메서드는 정보를 서버로부터 요청하는 데 사용됩니다. 주로 데이터의 조회 및 검색과 관련이 있습니다.
데이터는 URL 파라미터를 통해 전송됩니다. 예를 들어, https://example.com/resource?param1=value1¶m2=value2와 같은 형태로 데이터가 전달됩니다.
데이터는 URL의 일부이므로 브라우저 히스토리에 저장되며 북마크할 수 있습니다.
GET 요청은 캐싱할 수 있으며, 요청이 반복될 때 동일한 결과를 반환하기 때문에 멱등(idempotent)한 특성을 가집니다.
POST 메서드:
POST 메서드는 데이터를 서버로 제출하는 데 사용됩니다. 주로 데이터의 생성, 업데이트 및 삭제와 관련이 있습니다.
데이터는 HTTP 요청 본문(body)에 포함되며, URL에 직접 노출되지 않습니다. 이로써 데이터는 안전하게 전송됩니다.
POST 요청은 데이터의 길이나 형태에 제한이 없으며, 파일 업로드와 같이 큰 데이터를 전송할 때 사용됩니다.
POST 요청은 캐싱할 수 없으며, 요청이 반복될 때 다른 결과를 반환하기 때문에 멱등하지 않은(non-idempotent) 특성을 가집니다.
데이터 흐름
클라이언트(웹 브라우저 또는 다른 클라이언트 애플리케이션)는 HTTP GET 또는 POST 요청을 생성합니다.
GET 요청의 경우, 데이터는 URL에 쿼리 문자열로 포함됩니다. POST 요청의 경우, 데이터는 HTTP 요청 본문에 포함됩니다.
요청된 데이터와 함께 요청 헤더와 메서드(GET 또는 POST) 등의 메타데이터가 포함된 HTTP 요청이 서버로 전송됩니다.
서버는 요청을 수신하고, 해당 요청을 처리합니다.
GET 요청의 경우, 서버는 데이터를 응답의 일부로 다시 클라이언트로 전송합니다. POST 요청의 경우, 서버는 요청에 대한 응답을 생성하고 다시 클라이언트로 보냅니다.
클라이언트는 서버로부터 받은 데이터를 해석하고 원하는 방식으로 표시하거나 처리합니다.
34. OSI 7계층에 대해 아는대로 설명해주세요.
1. 물리 계층 (Physical Layer):
물리적인 데이터 전송을 담당합니다. 케이블, 스위치, 허브 등의 하드웨어 디바이스와 관련이 있습니다.
데이터 비트를 전송하고 신호를 변환하는 역할을 합니다.
2. 데이터 링크 계층 (Data Link Layer):
물리 계층에서 송수신된 데이터를 프레임(frame)으로 분할하고, 오류 검출 및 수정을 수행합니다.
MAC 주소를 사용하여 로컬 네트워크 내에서의 데이터 전송을 관리합니다.
스위치 등의 장비가 이 계층에서 동작합니다.
3. 네트워크 계층 (Network Layer):
데이터 패킷(packet)의 경로 선택 및 라우팅을 담당합니다.
IP 주소를 사용하여 패킷을 목적지까지 전달하며, 서브넷 간의 통신을 지원합니다.
라우터가 이 계층에서 동작합니다.
4. 전송 계층 (Transport Layer):
데이터 전송의 신뢰성과 정확성을 관리하며, 데이터의 오류 복구와 흐름 제어를 수행합니다.
포트 번호를 사용하여 프로세스 간의 통신을 지원하며, TCP와 UDP 프로토콜이 이 계층에서 동작합니다.
5. 세션 계층 (Session Layer):
세션의 설정, 유지, 종료를 관리하며, 데이터 교환을 동기화합니다.
다른 시스템 간의 다중 작업 및 동시성을 관리합니다.
6. 표현 계층 (Presentation Layer):
데이터를 응용 프로그램이 이해할 수 있는 형식으로 변환하고, 데이터 압축, 암호화, 인코딩 등의 작업을 수행합니다.
데이터 형식 및 문법 변환을 제공합니다.
7. 응용 계층 (Application Layer):
최종 사용자와 응용 프로그램 간의 상호 작용을 지원합니다.
프로토콜, 데이터 전송 및 응용 프로그램 인터페이스를 포함하여 다양한 응용 프로그램 서비스를 제공합니다.
각 계층은 그 자체로 독립적이며, 상위 계층은 하위 계층의 서비스를 활용하여 데이터를 처리하고 전달합니다. 이러한 계층화 구조를 통해 서로 다른 하드웨어 및 소프트웨어 시스템 간의 통신을 효과적으로 관리하고, 상호 운용성을 확보할 수 있습니다. 이 모델은 컴퓨터 네트워크 및 통신 시스템의 설계와 이해에 중요한 도구로 사용됩니다.
35. 세션 기반 인증과 토큰 기반 인증의 차이에 대해 설명해주세요.
세션 기반 인증(Session-Based Authentication):
-
서버 측 저장: 세션 기반 인증은 사용자 인증 정보(예: 로그인 상태)를 서버 측에 저장하고 관리합니다. 일반적으로 서버는 사용자 세션을 유지하기 위해 메모리나 데이터베이스에 정보를 저장합니다.
-
쿠키 사용: 일반적으로 세션 ID가 쿠키를 통해 클라이언트에게 전달됩니다. 클라이언트는 이 세션 ID를 요청 헤더에 포함하여 서버에 요청을 보냅니다. 서버는 세션 ID를 확인하고 해당 세션에 연결된 사용자 정보를 검색합니다.
-
서버 측 유지: 세션은 서버 측에서 유지되므로 클라이언트는 세션에 대한 관리나 저장을 하지 않습니다. 이는 클라이언트에게 상대적으로 덜 부담을 주는 장점일 수 있습니다.
-
로그아웃 및 세션 관리: 로그아웃은 서버 측에서 관리되며, 세션의 만료 시간을 설정하여 세션 관리가 가능합니다.
토큰 기반 인증(Token-Based Authentication):
-
서버 측 저장 없음: 토큰 기반 인증에서는 서버 측에 사용자 정보를 저장하지 않습니다. 사용자 정보는 토큰 자체에 포함되어 있거나, 토큰이 서버 측에서 검증될 수 있는 정보를 가지고 있습니다.
-
토큰 사용: 사용자는 인증 후 서버로부터 토큰을 받습니다. 이 토큰은 일반적으로 클라이언트 측에 저장됩니다(로컬 저장소, 쿠키, 브라우저 메모리 등).
-
클라이언트 측 유지: 토큰은 클라이언트 측에서 유지되며, 클라이언트는 토큰을 서버에 제공하여 자격 증명을 확인합니다.
-
로그아웃 및 토큰 관리: 로그아웃 및 토큰 만료는 클라이언트와 서버 간의 상호작용으로 이루어집니다. 토큰에는 유효 기간을 설정할 수 있어서 클라이언트 측에서 관리됩니다.
차이점 요약:
- 세션 기반 인증은 서버 측에서 사용자 정보를 관리하고, 클라이언트는 세션 ID만 가지고 있습니다. 토큰 기반 인증은 클라이언트가 사용자 정보를 가지고 있으며, 서버는 토큰의 유효성을 확인합니다.
- 세션은 서버 측에서 유지되고 관리되며, 로그아웃 및 세션 관리는 서버가 처리합니다. 토큰은 클라이언트 측에서 유지되며, 로그아웃 및 토큰 관리는 클라이언트와 서버 간의 협력으로 이루어집니다.
- 토큰 기반 인증은 RESTful API 및 분산 시스템에서 더 유용하며, 클라이언트가 다양한 서버로 분산되는 경우에도 잘 동작합니다. 세션 기반 인증은 전통적인 웹 응용 프로그램에서 더 일반적으로 사용됩니다.
36. JWT, Refresh, Access Token에 대해서 설명해주세요.
-
JWT (JSON Web Token):
- JWT는 웹 및 네트워크 보안에서 토큰 기반 인증을 구현하는 데 사용되는 컴팩트하고 자체 수용 가능한 방식의 토큰입니다.
- JWT는 JSON 형식으로 인코딩되며, 주로 사용자 인증 정보와 클레임(claim) 정보(예: 사용자 ID, 만료 시간, 권한 등)를 포함합니다.
- JWT는 서버에서 서명되어 있어 변경되지 않도록 보장되며, 클라이언트에서 서버로 전달됩니다.
- JWT는 주로 웹 애플리케이션 및 API에서 사용자 인증 및 권한 부여에 활용됩니다.
-
Access Token:
- Access Token은 사용자를 대표하여 API 또는 서비스에 접근하는 데 사용되는 토큰입니다.
- 주로 OAuth 2.0 및 OpenID Connect와 같은 프로토콜에서 사용되며, 사용자가 자원에 접근할 권한을 부여하고 인증하는 데 사용됩니다.
- Access Token은 일반적으로 JWT 또는 다른 형식의 토큰일 수 있으며, 일반적으로 짧은 유효 기간을 갖습니다.
-
Refresh Token:
- Refresh Token은 Access Token을 갱신하거나 재발급하는 데 사용되는 특수한 토큰입니다.
- Access Token은 일반적으로 유효 기간이 짧기 때문에, Refresh Token을 사용하여 Access Token을 주기적으로 갱신할 수 있습니다.
- Refresh Token은 주로 보안을 강화하고, 만료된 Access Token을 대체하기 위해 사용됩니다.
- Refresh Token은 일반적으로 Access Token과는 별도로 저장 및 보호되며, 더 긴 유효 기간을 가질 수 있습니다.
37. OAuth에 대해서 설명해주세요.
OAuth(Open Authorization)는 인터넷을 통해 다른 웹 서비스 또는 애플리케이션에 대한 제한된 액세스 권한을 부여하기 위한 권한 부여 프레임워크입니다. OAuth는 사용자 또는 서비스 소유자의 동의를 기반으로 다른 서비스 또는 애플리케이션에 대한 인증 및 권한 부여를 가능하게 합니다. OAuth는 다양한 웹 서비스 및 API에서 사용자 인증 및 권한 부여를 구현하는 데 널리 사용됩니다.
OAuth의 핵심 요소와 개념은 다음과 같습니다:
-
인증 서버(Authentication Server): OAuth 프로토콜을 사용하는 애플리케이션은 사용자 인증을 위해 인증 서버에 의존합니다. 인증 서버는 사용자를 식별하고 인증을 수행합니다.
-
클라이언트(Client): OAuth를 사용하는 웹 애플리케이션 또는 서비스를 클라이언트라고 합니다. 클라이언트는 사용자의 데이터에 액세스하려는 애플리케이션을 나타냅니다.
-
리소스 서버(Resource Server): 사용자 데이터 또는 서비스에 대한 액세스가 필요한 서버 또는 API를 리소스 서버라고 합니다.
-
리소스 소유자(Resource Owner): 리소스 서버의 데이터를 소유하거나 제어하는 사용자를 리소스 소유자라고 합니다.
-
액세스 토큰(Access Token): OAuth 프로세스를 통해 클라이언트가 리소스 서버에 액세스하기 위한 권한을 부여하는 토큰입니다. 이 토큰은 제한된 권한을 가지며, 유효 기간이 제한되어 있습니다.
OAuth 프로세스는 다음과 같은 단계로 진행됩니다:
-
애플리케이션 등록: 클라이언트 애플리케이션은 OAuth 프로토콜을 사용하기 위해 인증 서버 및 리소스 서버와 등록합니다.
-
사용자 인증 및 권한 부여: 클라이언트는 사용자를 인증하기 위해 인증 서버로 리다이렉트하고, 사용자는 자신의 자격 증명으로 인증합니다. 그러면 사용자가 액세스할 수 있는 리소스의 범위를 선택하고, 권한을 부여합니다.
-
액세스 토큰 요청: 인증이 성공하면 클라이언트는 액세스 토큰을 요청합니다. 이 요청은 권한 코드(authorization code)나 리소스 소유자의 자격 증명(비밀 번호)을 사용하여 이루어질 수 있습니다.
-
액세스 토큰 발급: 인증 서버는 클라이언트에게 액세스 토큰을 발급합니다.
-
액세스 토큰을 사용한 리소스 서버 액세스: 클라이언트는 액세스 토큰을 사용하여 리소스 서버에 액세스하고, 사용자의 데이터나 서비스를 요청합니다.
OAuth는 클라이언트가 사용자의 비밀 정보를 저장하거나 전달하지 않도록 하며, 사용자가 클라이언트 애플리케이션에 대한 제어를 유지하면서 다른 서비스와 상호작용할 수 있는 표준 방법을 제공합니다. 이것은 많은 웹 및 모바일 애플리케이션에서 소셜 미디어 로그인, API 액세스 및 권한 부여 등에 사용됩니다.
38. HTTP 상태코드에 대해서 설명해주세요.
HTTP(하이퍼텍스트 전송 프로토콜) 상태 코드는 웹 서버가 클라이언트에게 반환하는 3자리 숫자 코드입니다. 이 코드는 클라이언트에게 현재 요청의 결과를 나타내며, 클라이언트와 서버 간의 통신에서 중요한 역할을 합니다. HTTP 상태 코드는 요청이 성공했는지, 실패했는지, 그리고 실패한 경우 그 이유를 알려줍니다.
HTTP 상태 코드는 다음 세 가지 범주로 나눌 수 있습니다:
-
1xx (Informational - 정보): 요청이 받았으며 처리 중임을 나타내는 상태 코드입니다. 실제 응답은 아직 도착하지 않은 상태이며, 클라이언트는 기다려야 합니다.
-
2xx (Successful - 성공): 요청이 성공적으로 처리되었음을 나타내는 상태 코드입니다. 가장 흔한 상태 코드는 200(OK)이며, 요청이 성공했고 클라이언트는 응답을 받습니다.
-
3xx (Redirection - 리디렉션): 추가 조치가 필요한 경우를 나타내며, 요청을 다른 위치로 리디렉트해야 합니다.
-
4xx (Client Error - 클라이언트 오류): 요청에 오류가 있거나 요청을 처리할 수 없는 경우를 나타내는 상태 코드입니다. 예를 들어, 404(Not Found)는 요청한 리소스를 찾을 수 없음을 의미합니다.
-
5xx (Server Error - 서버 오류): 서버가 요청을 처리하는 동안 오류가 발생한 경우를 나타내는 상태 코드입니다. 예를 들어, 500(Internal Server Error)는 서버에서 내부 오류가 발생했음을 의미합니다.
39. CI/CD에 대해서 설명해주세요.
CI/CD는 소프트웨어 개발 및 배포 프로세스를 자동화하고 향상시키기 위한 개념과 방법론을 나타내는 용어입니다. CI는 "지속적인 통합(Continuous Integration)"의 약자이며, CD는 "지속적인 전달(Continuous Delivery)" 또는 "지속적인 배포(Continuous Deployment)"의 약자입니다. 이 두 가지 개념은 소프트웨어 개발 및 배포의 효율성과 품질을 향상시키는 데 중요한 역할을 합니다.
-
지속적인 통합(CI - Continuous Integration):
- CI는 개발자가 코드를 작성하고 변경 사항을 공유 코드 저장소(예: Git)에 푸시할 때 자동으로 통합 및 테스트되는 개발 프로세스를 나타냅니다.
- CI 시스템은 코드 통합 후 자동화된 빌드 및 테스트를 실행하여 코드 변경 사항의 품질을 확인합니다.
- 이로 인해 개발자는 빈번한 코드 통합과 품질 향상을 달성할 수 있으며, 잠재적인 버그 및 충돌을 조기에 발견하게 됩니다.
-
지속적인 전달(CD - Continuous Delivery):
- CD는 소프트웨어를 프로덕션 환경으로 자동으로 전달하고, 프로덕션 배포를 수동으로 승인하는 프로세스를 나타냅니다.
- CI와 함께 CD는 빌드, 테스트, 패키징 및 프로덕션 환경으로 배포를 자동화합니다.
- CD를 통해 개발된 소프트웨어는 프로덕션 준비 상태로 계속 전달되므로, 릴리즈 버전의 배포를 언제든 수행할 수 있습니다.
-
지속적인 배포(CD - Continuous Deployment):
- CD의 한 단계로, 소프트웨어 변경 사항이 테스트 및 스테이징 환경을 통과하면 자동으로 프로덕션 환경으로 배포됩니다.
- 사용자의 승인 없이 프로덕션 배포가 이루어집니다.
- 이 방식은 클라우드 환경 및 웹 기반 서비스에서 많이 사용되며, 지속적인 혁신과 배포 속도를 향상시킵니다.
40. TDD에 대해서 설명해주세요.
TDD(Test-Driven Development)는 소프트웨어 개발 방법론 중 하나로, 개발자가 소프트웨어를 개발할 때 테스트를 먼저 작성하고, 그 다음에 코드를 작성하는 접근 방식을 강조하는 방법론입니다. TDD는 다음 세 가지 주요 단계를 따릅니다:
-
테스트 작성 단계 (Red - 빨강):
- 먼저, 새로운 기능 또는 모듈을 개발하기 전에 해당 기능 또는 모듈에 대한 테스트 케이스를 작성합니다. 이 단계에서 작성된 테스트 케이스는 아직 구현되지 않은 기능 또는 모듈을 검사하는 역할을 합니다.
- 이로 인해 테스트는 실패합니다(빨간 불) because the functionality is not yet implemented.
-
코드 작성 단계 (Green - 초록):
- 이 단계에서 목표는 테스트를 통과하도록 최소한의 코드를 작성하는 것입니다. 코드 작성은 주로 테스트를 통과시키기 위한 코드 작성에 초점을 맞춥니다. 코드가 아직 완벽하지 않아도 됩니다. 주요 목표는 테스트를 통과하는 것(초록 불)입니다.
-
리팩터링 단계 (Refactor):
- 성공한 테스트를 통과한 후, 코드를 개선하고 리팩터링하는 단계입니다. 리팩터링은 코드의 가독성, 효율성 및 유지보수성을 향상시키는 작업을 수행합니다. 이 과정에서 코드의 품질을 높이고 중복을 제거하는 등의 작업을 수행할 수 있습니다.
TDD를 따르면 테스트 케이스는 개발 중에 코드의 예상 동작을 정의하고, 코드 변경 사항이 예상한 대로 동작하는지 확인하는 데 사용됩니다. TDD를 통해 소프트웨어의 안정성과 신뢰성을 향상시키며, 코드 변경에 대한 자신감을 제공하고 버그를 조기에 발견하는데 도움이 됩니다.
TDD는 소프트웨어 개발 프로세스를 단순화하고 개발자들 간의 협업을 촉진하며, 변경 사항이 코드에 영향을 미칠 때 이를 감지하는 데 도움을 줍니다.
실전 프로젝트
- Jmeter로 부하 테스트 하며 scale up, scale out 적용 후 개선점 체크
- RDS 연결시 발생하는 성능 저하문제 DB 커넥션 수 늘려서 개선
⭐️ 하루 생각 정리 ⭐️
