본문 바로가기
항해 99

기술면접 대비 5주차

초록용사 2024. 5. 16. 14:11

객체지향 프로그래밍이란 무엇이고 어떻게 활용할 수 있나요?

객체지향 프로그래밍(OOP) 정의:
객체지향 프로그래밍(OOP)은 소프트웨어 설계 패러다임 중 하나로, 프로그램을 객체(object)라는 단위로 구성하여 개발하는 방식입니다. 객체는 데이터(속성)와 데이터를 조작하는 코드(메서드)를 함께 포함하며, 현실 세계의 개체를 모델링합니다. OOP의 주요 개념에는 클래스, 객체, 상속, 캡슐화, 다형성, 추상화가 포함됩니다.

  • 주요 개념:
    • 클래스(Class):
      • 객체를 생성하기 위한 설계도나 청사진입니다. 클래스는 속성(데이터)과 메서드(기능)를 정의합니다.
    • 객체(Object):
      • 클래스의 인스턴스(instance)로, 실제 메모리에 할당된 실체입니다. 객체는 클래스에서 정의한 속성과 메서드를 가집니다.
    • 상속(Inheritance):
      • 기존 클래스(부모 클래스 또는 슈퍼클래스)의 속성과 메서드를 새 클래스(자식 클래스 또는 서브클래스)가 물려받는 기능입니다. 상속을 통해 코드의 재사용성을 높일 수 있습니다.
    • 캡슐화(Encapsulation):
      • 객체의 속성과 메서드를 하나로 묶고, 외부에서 객체의 내부 상태를 직접 접근하지 못하도록 제어하는 것입니다. 이를 통해 데이터의 무결성과 보안을 유지할 수 있습니다.
    • 다형성(Polymorphism):
      • 동일한 인터페이스나 메서드 이름이 여러 객체에서 다양한 방식으로 구현될 수 있는 특성입니다. 다형성은 주로 메서드 오버로딩과 오버라이딩을 통해 구현됩니다.
    • 추상화(Abstraction):
      • 복잡한 시스템에서 필요한 부분만을 간추려 모델링하는 것을 말합니다. 추상화는 인터페이스와 추상 클래스를 통해 구현됩니다.
  • 활용 방법:
    • 모듈화(Modularity):
      • 객체지향 프로그래밍은 프로그램을 독립적이고 재사용 가능한 모듈(클래스)로 나눌 수 있어 유지보수와 확장이 용이합니다.
    • 코드 재사용성(Reusability):
      • 상속과 클래스의 재사용을 통해 중복 코드를 줄이고, 코드의 일관성을 유지할 수 있습니다.
    • 유지보수성(Maintainability):
      • 캡슐화를 통해 객체의 내부 구현을 숨기고, 인터페이스를 통해 외부와 상호작용하게 하여 코드의 변경이 용이하고 유지보수가 편리합니다.
    • 유연성(Flexibility) 및 확장성(Extensibility):
      • 다형성과 상속을 이용하여 시스템의 기능을 쉽게 확장할 수 있으며, 새로운 기능 추가 시 기존 코드를 최소한으로 수정할 수 있습니다.
    • 복잡한 문제 해결:
      • 객체지향 프로그래밍은 복잡한 현실 세계의 문제를 객체 단위로 모델링하여 자연스럽고 직관적인 방식으로 해결할 수 있습니다.

객체지향 프로그래밍은 소프트웨어 개발의 복잡성을 줄이고, 유지보수성과 확장성을 높이는 데 중점을 둔 프로그래밍 패러다임입니다. 이를 통해 개발자는 현실 세계의 문제를 보다 효율적으로 모델링하고 해결할 수 있습니다.

 

대용량 트래픽 발생 시 어떻게 대응해야 하나요?

대용량 트래픽 대응 방안

  • 서버 확장성 (Scalability)
    • 수평적 확장 (Horizontal Scaling):
      • 설명: 더 많은 서버를 추가하여 부하를 분산합니다.
      • 장점: 쉽게 확장 가능하며, 고가용성을 제공합니다.
      • 예시: 로드 밸런서를 사용하여 트래픽을 여러 서버에 분산.
    • 수직적 확장 (Vertical Scaling):
      • 설명: 기존 서버의 하드웨어 성능(CPU, 메모리 등)을 향상시킵니다.
      • 장점: 단순한 구조로 성능 향상.
      • 단점: 물리적 한계가 있으며, 고비용 발생 가능.
  • 로드 밸런싱 (Load Balancing)
    • 로드 밸런서 사용:
      • 설명: 로드 밸런서를 통해 트래픽을 여러 서버에 균등하게 분산.
      • 장점: 트래픽 분산, 서버 과부하 방지, 고가용성.
      • 유형: DNS 기반, L4(네트워크 레벨), L7(애플리케이션 레벨) 로드 밸런싱.
  • 캐싱 (Caching)
    • CDN (Content Delivery Network):
      • 설명: 전 세계에 분산된 캐시 서버에 콘텐츠를 저장하여 사용자에게 빠르게 제공.
      • 장점: 대기 시간 감소, 서버 부하 감소.
    • 애플리케이션 레벨 캐싱:
      • 설명: 자주 요청되는 데이터를 메모리에 저장하여 빠르게 제공 (예: Memcached, Redis).
      • 장점: 데이터베이스 부하 감소, 응답 시간 단축.
  • 데이터베이스 최적화
    • 데이터베이스 샤딩 (Sharding):
      • 설명: 데이터를 여러 데이터베이스로 분할하여 저장.
      • 장점: 데이터베이스 부하 분산, 확장성 향상.
    • 리플리케이션 (Replication):
      • 설명: 데이터를 복제하여 여러 데이터베이스 인스턴스에 저장.
      • 장점: 읽기 성능 향상, 고가용성 제공.
    • 인덱스 최적화:
      • 설명: 적절한 인덱스를 통해 쿼리 성능을 향상.
      • 장점: 데이터 조회 속도 향상.
  • 비동기 처리 및 큐잉 (Asynchronous Processing and Queuing)
    • 메시지 큐 (Message Queue):
      • 설명: 작업을 큐에 저장하고 비동기적으로 처리 (예: RabbitMQ, Kafka).
      • 장점: 시스템 부하 분산, 처리 속도 향상.
    • 비동기 작업:
      • 설명: 사용자 요청과 독립적으로 백그라운드에서 작업 처리.
      • 장점: 사용자 응답 시간 단축, 시스템 안정성 향상.
  •  모니터링 및 자동화
    • 실시간 모니터링:
      • 설명: 서버 및 애플리케이션의 상태를 실시간으로 모니터링 (예: Prometheus, Grafana).
      • 장점: 문제를 조기에 발견하고 대응 가능.
    • 자동화 스케일링:
      • 설명: 트래픽 증가에 따라 자동으로 서버를 추가하거나 제거 (예: AWS Auto Scaling).
      • 장점: 자원 효율적 사용, 탄력적 대응.
  • 최적화된 코드 및 아키텍처
    • 효율적인 코드 작성:
      • 설명: 코드 최적화, 불필요한 연산 제거.
      • 장점: 시스템 자원 절약, 성능 향상.
    • 마이크로서비스 아키텍처:
      • 설명: 애플리케이션을 독립적인 서비스로 분리.
      • 장점: 독립적 확장, 장애 격리.
  • 기타 전략
    • SSL 오프로드:
      • 설명: SSL 암호화/복호화 작업을 전용 장비에서 처리.
      • 장점: 웹 서버의 부하 감소.
    • DB Connection Pooling:
      • 설명: 데이터베이스 연결을 미리 생성해 두고 재사용.
      • 장점: 연결 설정 시간 단축, 효율적인 연결 관리

 

ORM을 사용하면서 쿼리가 복잡해지는 경우에는 어떻게 해결하는게 좋을까요?

  1. JPQL (Java Persistence Query Language) 사용
    • JPQL은 JPA(EntityManager)를 사용하여 데이터베이스와 상호작용할 때 사용할 수 있는 쿼리 언어입니다. SQL과 유사하지만, 객체 지향적인 접근을 제공하여 엔티티 객체를 대상으로 쿼리를 작성할 수 있습니다.
    • 복잡한 쿼리도 객체와 관계를 기반으로 간결하게 표현할 수 있습니다.
  2. Criteria API 사용
    • Criteria API는 동적 쿼리를 타입 세이프하게 작성할 수 있도록 도와줍니다.
    • 컴파일 타임에 쿼리를 검증할 수 있어 런타임 에러를 줄이는 데 도움이 됩니다.
    • 복잡한 쿼리의 경우 조건을 동적으로 조립하는 데 유리합니다.
  3. Native Query 사용
    • Native Query는 SQL 쿼리를 직접 사용할 수 있게 해줍니다.
    • 복잡한 SQL이나 특정 DBMS에 특화된 기능을 사용할 때 유용합니다.
    • 성능 최적화가 필요한 경우에 사용할 수 있습니다.
  4. DTO (Data Transfer Object) 사용
    • DTO를 사용하여 필요한 데이터만 선택적으로 가져오는 쿼리를 작성할 수 있습니다.
    • 쿼리의 복잡성을 줄이고 성능을 향상시키는 데 도움이 됩니다.
  5. QueryDSL 사용
    • QueryDSL은 타입 세이프하고 코드 작성이 편리한 방식으로 쿼리를 작성할 수 있는 도구입니다.
    • Predicate, BooleanExpression 등을 활용하여 복잡한 조건을 명확하게 정의할 수 있습니다.
    • 코드 가독성이 높아지고 유지보수가 용이합니다.
  6. Repository Customization
    • Spring Data JPA에서 제공하는 Repository 인터페이스를 확장하여 복잡한 쿼리 로직을 별도의 구현체로 분리할 수 있습니다.
    • 예: CustomUserRepository를 만들어 복잡한 사용자 검색 로직을 구현합니다.
  7. Specification 패턴 사용
    • Specification 패턴을 사용하여 쿼리 조건을 객체로 캡슐화할 수 있습니다.
    • 조건을 조합하여 동적으로 쿼리를 생성할 수 있습니다.
    • 특히, 복잡한 검색 조건이 필요한 경우 유용합니다.
  8. Pagination과 Sorting
    • 복잡한 쿼리를 작성할 때 Pagination과 Sorting을 함께 사용하여 성능을 최적화할 수 있습니다.
    • 대용량 데이터 처리 시 효과적입니다.
  9. Database View 또는 Stored Procedure 사용
    • 복잡한 비즈니스 로직이 포함된 경우, Database View나 Stored Procedure를 사용하여 서버 측에서 미리 데이터를 가공할 수 있습니다.
    • 성능 최적화와 쿼리 간결화에 도움이 됩니다.

복잡한 쿼리를 처리할 때는 위의 방법들을 상황에 맞게 조합하여 사용하는 것이 중요합니다. 각 방법의 장단점을 이해하고, 프로젝트의 요구사항에 맞게 선택적으로 적용하여 효율적인 데이터 접근을 구현하는 것이 좋습니다.

 

GET, POST의 개념과 함께 데이터 흐름에 대해서 설명해주세요.

  • GET 메서드:
    • 개념:
      • GET 메서드는 웹 서버에서 데이터를 요청할 때 사용되는 HTTP 메서드입니다. 주로 데이터를 조회하기 위한 요청에 사용되며, 요청된 데이터를 URL의 쿼리 스트링에 포함시켜 서버로 전송합니다.
    • 특징:
      • URL에 데이터 포함: 데이터가 URL에 쿼리 스트링의 형태로 포함되므로, URL에 데이터가 노출됩니다.
      • 캐싱 가능: GET 요청은 캐시될 수 있어, 서버의 부하를 줄이고 빠른 응답을 제공할 수 있습니다.
      • 아이덴포텐트(Idempotent): 동일한 GET 요청을 여러 번 호출해도 결과가 동일합니다.
      • 데이터 크기 제한: URL 길이에 따라 전송할 수 있는 데이터의 크기에 제한이 있습니다.
    • 데이터 흐름:
      • 클라이언트 요청: 클라이언트가 GET 요청을 보냅니다. 예: http://example.com/api/resource?id=123
      • 서버 처리: 서버는 URL에서 데이터를 추출하여 요청을 처리합니다.
      • 응답 전송: 서버가 요청된 데이터를 포함한 응답을 클라이언트에 전송합니다.
      • 클라이언트 수신: 클라이언트는 서버의 응답을 받아서 처리합니다.
  • POST 메서드:
    • 개념:
      • POST 메서드는 웹 서버에 데이터를 전송하거나 제출할 때 사용되는 HTTP 메서드입니다. 주로 데이터를 생성하거나 업데이트하는 요청에 사용됩니다.
    • 특징:
      • 본문에 데이터 포함: 데이터가 요청 본문에 포함되어 전송되므로, URL에 노출되지 않습니다.
      • 캐싱 불가: POST 요청은 캐시되지 않으므로, 매번 서버에서 새로운 처리가 이루어집니다.
      • 아이덴포텐트가 아님: 동일한 POST 요청을 여러 번 호출하면 서버의 상태가 변경될 수 있습니다.
      • 대용량 데이터 전송 가능: URL의 길이 제한이 없기 때문에 대용량 데이터 전송에 적합합니다.
    • 데이터 흐름:
      • 클라이언트 요청: 클라이언트가 POST 요청을 보냅니다. 예: http://example.com/api/resource
      • 헤더: Content-Type과 같은 헤더를 포함합니다.
      • 본문: JSON, XML, 폼 데이터 등 데이터를 본문에 포함합니다.
      • 서버 처리: 서버는 요청 본문에서 데이터를 추출하여 요청을 처리합니다.
      • 응답 전송: 서버가 처리 결과를 포함한 응답을 클라이언트에 전송합니다.
      • 클라이언트 수신: 클라이언트는 서버의 응답을 받아서 처리합니다.

GET과 POST는 각각의 목적과 데이터 전송 방식에 따라 사용됩니다. GET은 주로 데이터 조회에 사용되며, URL에 데이터를 포함시키는 반면, POST는 데이터 생성 또는 업데이트에 사용되며 데이터를 요청 본문에 포함시킵니다. 이러한 차이를 이해하고 적절히 사용하는 것이 중요합니다.

 

OSI 7계층에 대해 아는대로 설명해주세요.

OSI 7계층 모델 개요:
OSI (Open Systems Interconnection) 모델은 네트워크 통신을 7개의 계층으로 나누어 설명하는 개념적 프레임워크입니다. 이 모델은 각 계층이 특정 기능을 수행하며, 계층 간 상호작용을 통해 데이터 통신이 이루어집니다. OSI 모델은 네트워크 프로토콜을 설계하고 이해하는 데 중요한 가이드를 제공합니다.

  • 각 계층의 역할과 기능:
    • 물리 계층 (Physical Layer)
      • 역할: 실제 물리적 매체를 통해 비트 스트림을 전송하는 역할을 합니다.
      • 기능: 전기적 신호, 광 신호, 무선 신호 등을 통해 데이터를 전송합니다. 케이블, 핀 배치, 전압 수준, 데이터 전송 속도 등이 포함됩니다.
      • 장비: 허브, 리피터, 케이블 등.
    •  데이터 링크 계층 (Data Link Layer)
      • 역할: 물리적 네트워크 내에서 오류 없는 데이터 프레임 전송을 담당합니다.
      • 기능: 프레임의 생성, 전송, 에러 검출 및 수정, 흐름 제어를 수행합니다. MAC 주소를 사용하여 장치 간 데이터 전송을 관리합니다.
      • 프로토콜: Ethernet, PPP, HDLC 등.
      • 장비: 스위치, 브리지 등.
    • 네트워크 계층 (Network Layer)
      • 역할: 서로 다른 네트워크 간 데이터 패킷 전송을 담당합니다.
      • 기능: 경로 선택, 패킷 전달, 논리적 주소(IP 주소) 할당 및 변환을 수행합니다.
      • 프로토콜: IP, ICMP, ARP 등.
      • 장비: 라우터 등.
    • 전송 계층 (Transport Layer)
      • 역할: 종단 간(end-to-end) 통신을 제공하며, 데이터 전송의 신뢰성을 보장합니다.
      • 기능: 데이터 세그먼트화, 흐름 제어, 오류 검출 및 수정, 데이터 재전송을 수행합니다.
      • 프로토콜: TCP, UDP 등.
    • 세션 계층 (Session Layer)
      • 역할: 통신 세션을 설정, 관리, 종료하는 역할을 합니다.
      • 기능: 세션 설정, 유지, 동기화, 복구를 담당하며, 세션 간의 데이터 교환을 관리합니다.
      • 프로토콜: NetBIOS, PPTP 등.
    • 표현 계층 (Presentation Layer)
      • 역할: 데이터를 응용 계층에서 사용할 수 있는 형태로 변환합니다.
      • 기능: 데이터 암호화, 압축, 변환(예: 인코딩 및 디코딩) 등의 작업을 수행합니다.
      • 포맷: JPEG, GIF, ASCII, EBCDIC, TLS/SSL 등.
    • 응용 계층 (Application Layer)
      • 역할: 최종 사용자가 네트워크에 접근하는 인터페이스를 제공합니다.
      • 기능: 네트워크 서비스 요청 및 제공, 데이터의 의미 이해, 응용 프로그램 간 데이터 교환을 담당합니다.
      • 프로토콜: HTTP, FTP, SMTP, DNS, Telnet 등.
  • OSI 7계층 요약:
    • 물리 계층: 비트 전송, 하드웨어 요소.
    • 데이터 링크 계층: 프레임 전송, MAC 주소, 오류 검출.
    • 네트워크 계층: 패킷 전송, 경로 선택, IP 주소.
    • 전송 계층: 데이터 전송의 신뢰성, TCP/UDP.
    • 세션 계층: 세션 관리, 동기화.
    • 표현 계층: 데이터 변환, 암호화/압축.
    • 응용 계층: 사용자 인터페이스, 응용 프로토콜.

OSI 7계층 모델은 네트워크 통신을 체계적으로 이해하고 설계하는 데 중요한 역할을 합니다. 각 계층은 고유의 기능을 가지고 있으며, 상호 작용을 통해 데이터를 신뢰성 있게 전송합니다. 이 모델을 통해 네트워크 문제를 진단하고, 프로토콜 및 네트워크 장비의 기능을 이해할 수 있습니다.

 

세션 기반 인증과 토큰 기반 인증의 차이에 대해 설명해주세요.

  • 세션 기반 인증 (Session-Based Authentication)
    • 동작 원리:
      • 사용자가 로그인하면 서버는 사용자 정보를 기반으로 세션을 생성하고, 세션 ID를 클라이언트에 쿠키로 전송합니다.
      • 클라이언트는 이후의 요청에서 이 세션 ID를 서버로 전송합니다.
      • 서버는 세션 ID를 확인하여 해당 사용자의 세션 정보를 조회하고, 사용자 인증을 처리합니다.
    • 장점:
      • 보안: 서버에 세션 정보를 저장하기 때문에 세션 하이재킹에 강한 편입니다.
      • 세션 관리: 서버 측에서 세션 상태를 관리하기 때문에 세션 만료, 로그아웃 등의 관리가 용이합니다.
    • 단점:
      • 서버 부담: 모든 사용자 세션을 서버 메모리에 저장해야 하므로, 많은 사용자를 처리할 때 서버 자원 소모가 큽니다.
      • 확장성 문제: 세션 정보가 서버에 저장되므로, 서버를 여러 대로 확장할 때 세션 동기화 문제가 발생할 수 있습니다.
  • 토큰 기반 인증 (Token-Based Authentication)
    • 동작 원리:
      • 사용자가 로그인하면 서버는 사용자를 인증하고, JWT (JSON Web Token) 또는 OAuth 토큰과 같은 토큰을 생성하여 클라이언트에 전송합니다.
      • 클라이언트는 이후의 요청에서 이 토큰을 포함하여 서버로 전송합니다.
      • 서버는 토큰을 검증하여 사용자 인증을 처리합니다. JWT의 경우 서버는 토큰을 디코딩하고 서명 검증을 통해 인증을 확인합니다.
    • 장점:
      • 무상태성: 서버는 사용자의 상태를 저장하지 않으므로 서버 부하가 적고, 확장성이 좋습니다.
      • 유연성: 다양한 클라이언트(웹, 모바일 앱 등)에서 동일한 토큰을 사용할 수 있습니다.
      • 확장 용이: 서버를 여러 대로 확장할 때 세션 동기화가 필요 없으므로, 분산 시스템에 적합합니다.
    • 단점:
      • 보안: 토큰이 클라이언트에 저장되기 때문에, 토큰 유출 시 보안 문제가 발생할 수 있습니다.
      • 토큰 관리: 토큰의 만료, 재발급 등의 관리가 필요합니다. 특히, JWT는 만료 전까지 유효하므로, 서버 측에서 토큰을 강제로 무효화하기 어렵습니다.
  • 비교 요약:
    • 세션 기반은 서버 메모리에 사용자 상태를 유지하며, 주로 작은 규모의 애플리케이션에 적합합니다.
    • 토큰 기반은 클라이언트가 상태를 유지하고, 무상태성을 가지므로 대규모 분산 시스템에서 효율적입니다.

 

JWT, Refresh, Access Token에 대해서 설명해주세요.

  • JWT (JSON Web Token)
    • JWT는 JSON 객체를 안전하게 압축하고 서명하여 정보를 교환하는 웹 표준입니다.
    • 기본 구조는 세 부분으로 구성됩니다: 헤더(Header), 페이로드(Payload), 서명(Signature).
    • 헤더(Header): 토큰의 유형과 서명 알고리즘 정보를 포함합니다.
    • 페이로드(Payload): 사용자 정보나 만료 시간(exp) 등 클레임(Claim)을 포함합니다.
    • 서명(Signature): 헤더와 페이로드를 결합하여 비밀 키로 서명한 값으로, 토큰의 무결성을 검증합니다.
    • 특징:
      • 자체 포함(self-contained): 사용자 정보와 권한 정보를 모두 포함하고 있어, 서버 측에서 별도의 세션 저장소가 필요 없습니다.
      • 확장성: 클라이언트와 서버 간에 안전하게 데이터를 전송할 수 있으며, 다양한 클라이언트(웹, 모바일 등)에서 사용 가능합니다.
      • 무상태성(stateless): 서버는 토큰 자체만으로 인증을 처리하므로, 확장성이 뛰어납니다.
  • 액세스 토큰 (Access Token)
    • 액세스 토큰은 사용자 인증 후 서버가 클라이언트에게 발급하는 토큰으로, 주로 자원에 대한 접근 권한을 제어합니다.
    • 보통 JWT 형식으로 발급되며, 유효 기간이 짧습니다 (예: 15분~1시간).
    • 특징:
      • 단기 유효성: 짧은 유효 기간으로 보안성을 높입니다. 만료되면 새로 발급받아야 합니다.
      • 자원 접근 제어: API 호출 시 토큰을 함께 전송하여 권한을 검증받고 자원에 접근합니다.
  • 리프레시 토큰 (Refresh Token)
    • 리프레시 토큰은 액세스 토큰의 유효 기간이 만료되었을 때, 새로운 액세스 토큰을 발급받기 위해 사용하는 토큰입니다.
    • 일반적으로 액세스 토큰보다 긴 유효 기간을 가집니다 (예: 수일~수개월).
    • 특징:
      • 장기 유효성: 긴 유효 기간을 가지며, 유효한 동안 여러 번 액세스 토큰을 재발급받을 수 있습니다.
      • 보안 고려 사항: 리프레시 토큰이 유출되면 장기적으로 보안 문제가 발생할 수 있으므로, 안전하게 저장하고 사용할 필요가 있습니다.
      • 재인증 최소화: 사용자는 리프레시 토큰을 통해 자주 재인증할 필요가 없습니다.
  • 비교 및 사용 시나리오:
    • JWT: 정보 교환의 안전성과 무결성을 보장하며, 주로 액세스 토큰의 형태로 사용됩니다.
    • 액세스 토큰: 단기적으로 자원에 접근할 때 사용되며, 보안 강화를 위해 짧은 유효 기간을 가집니다.
    • 리프레시 토큰: 액세스 토큰을 재발급받기 위해 사용되며, 클라이언트는 이를 통해 지속적인 인증을 유지할 수 있습니다.
  • 동작 예시:
    1. 사용자가 로그인하면 서버는 액세스 토큰과 리프레시 토큰을 발급합니다.
    2. 클라이언트는 API 요청 시 액세스 토큰을 사용하여 인증을 받습니다.
    3. 액세스 토큰이 만료되면, 클라이언트는 리프레시 토큰을 사용하여 새로운 액세스 토큰을 요청합니다.
    4. 서버는 리프레시 토큰을 검증한 후 새로운 액세스 토큰을 발급합니다.

 

OAuth에 대해서 설명해주세요.

  • OAuth (Open Authorization) 개요
    • OAuth는 웹 애플리케이션이나 모바일 애플리케이션이 사용자 자원에 대한 접근 권한을 제3자 애플리케이션에게 부여할 수 있게 해주는 표준 인증 프레임워크입니다. OAuth는 두 가지 주요 버전이 존재합니다: OAuth 1.0a와 OAuth 2.0. 여기서는 더 널리 사용되는 OAuth 2.0을 중심으로 설명하겠습니다.
  • OAuth 2.0 주요 개념
    • 리소스 소유자 (Resource Owner):
      • 일반적으로 사용자로, 자신의 자원에 대한 접근 권한을 가지고 있습니다.
    • 클라이언트 (Client):
      • 사용자 자원에 접근하려는 애플리케이션으로, 보통은 웹 애플리케이션이나 모바일 애플리케이션입니다.
    • 리소스 서버 (Resource Server):
      • 보호된 사용자 자원이 저장된 서버입니다. 이 서버는 액세스 토큰을 받아 자원 요청을 승인하거나 거부합니다.
    • 인증 서버 (Authorization Server):
      • 클라이언트가 액세스 토큰을 얻기 위해 인증을 수행하는 서버입니다. 이 서버는 사용자를 인증하고, 클라이언트에게 액세스 토큰을 발급합니다.
    • 액세스 토큰 (Access Token):
      • 클라이언트가 리소스 서버에 자원 접근을 요청할 때 사용하는 토큰입니다. 짧은 유효 기간을 가지며, 일반적으로 JWT 형식을 사용합니다.
    • 승인 코드 (Authorization Code):
      • 사용자가 클라이언트를 승인한 후 클라이언트가 인증 서버로부터 받는 일회성 코드입니다. 이 코드는 액세스 토큰을 교환하는 데 사용됩니다.
  • OAuth 2.0 인증 흐름
    • OAuth 2.0에는 다양한 인증 흐름이 있지만, 가장 일반적인 Authorization Code Grant 흐름을 설명합니다.
    • 사용자 승인 요청:
      • 클라이언트는 사용자에게 인증 서버의 승인 페이지로 리디렉션합니다.
      • 사용자에게 클라이언트가 접근하려는 범위(scope)와 함께 승인을 요청합니다.
    • 사용자 승인:
      • 사용자는 인증 서버에서 자신의 자격 증명을 입력하고 클라이언트를 승인합니다.
    • 승인 코드 수신:
      • 사용자가 승인을 완료하면, 인증 서버는 클라이언트에게 승인 코드를 발급하고, 이를 클라이언트의 리디렉션 URI로 전송합니다.
    • 액세스 토큰 요청:
      • 클라이언트는 승인 코드를 사용하여 인증 서버에 액세스 토큰을 요청합니다. 이 요청에는 클라이언트 ID, 클라이언트 비밀, 승인 코드, 리디렉션 URI가 포함됩니다.
    • 액세스 토큰 발급:
      • 인증 서버는 클라이언트의 요청을 검증한 후 액세스 토큰을 발급합니다.
    • 자원 요청:
      • 클라이언트는 액세스 토큰을 사용하여 리소스 서버에 사용자 자원 접근을 요청합니다.
  • OAuth의 장점과 보안 고려사항
    • 장점:
      • 보안 강화: 사용자는 애플리케이션에 비밀번호를 제공하지 않고도 자원 접근을 허용할 수 있습니다.
      • 사용자 경험 개선: 사용자는 여러 애플리케이션에서 동일한 자격 증명을 재사용할 수 있습니다.
      • 권한 제어: 사용자는 특정 범위에 대한 접근 권한을 부여하거나 취소할 수 있습니다.
    • 보안 고려사항:
      • 리디렉션 URI의 안전성: 클라이언트가 리디렉션 URI를 정확하게 검증해야 합니다.
      • 액세스 토큰의 보호: 액세스 토큰이 노출되지 않도록 HTTPS를 사용하고, 토큰 저장 및 전송에 주의해야 합니다.
      • CSRF 공격 방지: 인증 흐름 중 CSRF 공격을 방지하기 위한 보안 메커니즘을 사용해야 합니다

 

HTTP 상태코드에 대해서 설명해주세요.

HTTP 상태 코드는 서버가 클라이언트의 요청을 처리한 결과를 나타내는 3자리 숫자 코드입니다. 이 코드는 클라이언트가 요청에 대한 결과를 이해하고 적절히 처리할 수 있도록 도와줍니다. 상태 코드는 크게 다섯 가지 범주로 나뉩니다:

  • 1xx (정보 응답):
    • 100 Continue: 클라이언트가 요청을 계속해야 함을 나타냅니다. 서버가 요청의 일부를 받고, 나머지를 계속 전송해도 좋다는 응답을 의미합니다.
    • 101 Switching Protocols: 서버가 클라이언트의 프로토콜 전환 요청을 수락했음을 나타냅니다.
  • 2xx (성공):
    • 200 OK: 요청이 성공적으로 처리되었음을 나타냅니다. 요청에 대한 정상적인 응답입니다.
    • 201 Created: 요청이 성공적으로 처리되었으며, 새로운 리소스가 생성되었음을 나타냅니다.
    • 204 No Content: 요청이 성공적으로 처리되었으나, 반환할 콘텐츠가 없음을 나타냅니다.
  • 3xx (리다이렉션):
    • 301 Moved Permanently: 요청한 리소스가 영구적으로 다른 URL로 이동되었음을 나타냅니다. 클라이언트는 앞으로 새로운 URL을 사용해야 합니다.
    • 302 Found: 요청한 리소스가 임시로 다른 URL에 위치하고 있음을 나타냅니다. 클라이언트는 현재의 URL을 계속 사용해도 됩니다.
    • 304 Not Modified: 요청한 리소스가 수정되지 않았음을 나타냅니다. 클라이언트는 캐시된 버전을 사용해야 합니다.
  • 4xx (클라이언트 오류):
    • 400 Bad Request: 서버가 요청을 이해할 수 없거나 잘못된 문법을 포함하고 있음을 나타냅니다.
    • 401 Unauthorized: 인증이 필요하거나 인증이 실패했음을 나타냅니다.
    • 403 Forbidden: 서버가 요청을 이해했지만, 권한 문제로 요청을 거부했음을 나타냅니다.
    • 404 Not Found: 요청한 리소스를 찾을 수 없음을 나타냅니다. URL이 잘못되었거나 리소스가 삭제되었을 수 있습니다.
  • 5xx (서버 오류):
    • 500 Internal Server Error: 서버가 요청을 처리하는 중에 예기치 않은 오류가 발생했음을 나타냅니다.
    • 501 Not Implemented: 서버가 요청된 기능을 지원하지 않음을 나타냅니다.
    • 502 Bad Gateway: 서버가 게이트웨이 또는 프록시 역할을 하는 동안 상위 서버로부터 잘못된 응답을 받았음을 나타냅니다.
    • 503 Service Unavailable: 서버가 일시적으로 과부하 상태이거나 유지보수 중임을 나타냅니다.

HTTP 상태 코드는 웹 통신에서 서버와 클라이언트 간의 의사소통을 돕는 중요한 요소입니다. 상태 코드를 통해 클라이언트는 요청의 성공 여부를 판단하고, 필요한 경우 적절한 조치를 취할 수 있습니다. 올바른 상태 코드를 사용함으로써 클라이언트와 서버 간의 효율적인 상호 작용을 보장할 수 있습니다.

 

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

CI/CD (Continuous Integration / Continuous Deployment or Delivery)

  • Continuous Integration (CI)
    • 개념:
      • CI는 개발자가 빈번하게 소스 코드를 중앙 저장소에 통합하는 프로세스입니다.
      • 통합된 코드는 자동화된 빌드와 테스트를 거쳐 코드의 일관성과 품질을 유지합니다.
    • 주요 목적:
      • 빠른 피드백: 코드 변경 사항에 대한 신속한 피드백을 제공하여 문제를 조기에 발견하고 수정할 수 있습니다.
      • 품질 향상: 지속적인 테스트와 빌드를 통해 코드의 품질과 안정성을 높입니다.
    • 주요 단계:
      • 코드 커밋: 개발자가 변경된 코드를 버전 관리 시스템(VCS)에 커밋합니다.
      • 자동화 빌드: 커밋된 코드는 자동으로 빌드됩니다.
      • 자동화 테스트: 빌드된 코드에 대해 자동화된 테스트가 실행됩니다.
      • 피드백 제공: 빌드 및 테스트 결과에 대한 피드백이 개발자에게 제공됩니다.
  • Continuous Deployment (CD)
    • 개념:
      • CD는 자동화된 테스트를 통과한 코드 변경 사항을 프로덕션 환경에 자동으로 배포하는 프로세스입니다.
      • 모든 변경 사항이 즉시 프로덕션에 배포됩니다.
    • 주요 목적:
      • 빠른 배포: 코드 변경 사항을 신속하게 사용자에게 제공할 수 있습니다.
      • 효율성 향상: 수동 배포의 필요성을 없애고, 배포 프로세스를 자동화하여 효율성을 높입니다.
    • 주요 단계:
      • 자동화 테스트: 모든 코드 변경 사항은 철저한 자동화 테스트를 거칩니다.
      • 자동 배포: 테스트를 통과한 코드는 자동으로 프로덕션 환경에 배포됩니다.
  • Continuous Delivery (CD)
    • 개념:
      • Continuous Delivery는 코드 변경 사항을 프로덕션 환경에 배포할 준비가 된 상태로 유지하는 프로세스입니다.
      • 자동화된 배포 파이프라인을 통해 언제든지 프로덕션 배포가 가능합니다.
    • 주요 목적:
      • 안정적인 배포: 코드가 언제든지 프로덕션에 배포될 수 있도록 안정적이고 검증된 상태를 유지합니다.
      • 사용자 신뢰: 정기적인 배포를 통해 사용자에게 신뢰를 줍니다.
    • 주요 단계:
      • 자동화 테스트: 코드 변경 사항에 대해 철저한 자동화 테스트를 수행합니다.
      • 준비 상태 유지: 테스트를 통과한 코드를 프로덕션 배포 준비 상태로 유지합니다.
      • 수동 배포 트리거: 배포는 자동화된 도구를 통해 수동으로 트리거됩니다.
  • CI/CD의 장점
    • 빠른 피드백 루프: 코드 변경에 대한 신속한 피드백으로 문제를 조기에 식별하고 해결할 수 있습니다.
    • 높은 품질: 지속적인 통합과 테스트를 통해 코드의 품질과 안정성이 높아집니다.
    • 효율성 향상: 자동화된 빌드, 테스트, 배포를 통해 개발 및 배포 프로세스의 효율성이 증가합니다.
    • 신뢰성 향상: 자동화된 프로세스를 통해 배포의 신뢰성과 일관성이 향상됩니다.
  • 주요 도구
    • CI 도구: Jenkins, Travis CI, CircleCI, GitLab CI/CD, GitHub Actions 등.
    • CD 도구: Spinnaker, Argo CD, Flux, Octopus Deploy 등.
  • CI/CD 파이프라인 예시
    • 코드 커밋: 개발자는 코드를 버전 관리 시스템에 커밋합니다.
    • 빌드 트리거: 커밋 후 CI 도구가 자동으로 빌드를 시작합니다.
    • 자동화 테스트 실행: 빌드된 코드에 대해 자동화 테스트가 실행됩니다.
    • 결과 피드백: 테스트 결과가 개발자에게 피드백됩니다.
    • 배포 준비: 테스트를 통과한 코드는 프로덕션 배포 준비 상태로 유지됩니다.
    • 자동 배포 (Continuous Deployment의 경우): 준비된 코드는 자동으로 프로덕션에 배포됩니다.

 

TDD에 대해서 설명해주세요.

TDD (Test-Driven Development)

  • TDD의 개념
    • Test-Driven Development는 소프트웨어 개발에서 테스트 코드를 먼저 작성하고, 그 테스트를 통과하기 위한 코드를 작성하는 반복적인 개발 방식입니다. 이 접근 방식은 Kent Beck이 제안한 익스트림 프로그래밍의 핵심 관행 중 하나입니다.
  • TDD의 사이클 (Red-Green-Refactor)
    • Red (실패하는 테스트 작성):
      • 새로운 기능을 추가하거나 수정할 때, 해당 기능이 정상적으로 동작하는지 검증하기 위한 테스트를 먼저 작성합니다.
      • 이 단계에서는 아직 기능이 구현되지 않았기 때문에, 테스트는 실패(Red)합니다.
    • Green (테스트 통과를 위한 코드 작성):
      • 작성된 테스트를 통과하기 위해 최소한의 코드를 작성합니다.
      • 이 단계에서는 테스트가 성공(Green)해야 합니다.
    • Refactor (리팩토링):
      • 테스트를 통과하는 코드를 작성한 후, 코드의 중복을 제거하고 구조를 개선하는 리팩토링을 진행합니다.
      • 리팩토링 후에도 테스트는 여전히 통과해야 합니다.
  • TDD의 장점
    • 코드 품질 향상:
      • 테스트를 먼저 작성함으로써, 코드의 설계와 구현이 테스트 가능하고 이해하기 쉽게 개선됩니다.
      • 불필요한 코드를 줄이고, 단순하고 명확한 코드 작성이 촉진됩니다.
    • 빠른 피드백 제공:
      • 코드 변경 후 즉시 테스트를 실행하여 코드의 올바름을 빠르게 확인할 수 있습니다.
      • 초기 단계에서 버그를 발견하고 수정할 수 있어, 문제를 조기에 해결합니다.
    • 향상된 유지보수성:
      • 테스트가 코드의 동작을 명확하게 정의하므로, 코드 변경 시에도 기존 기능의 올바름을 쉽게 검증할 수 있습니다.
      • 리팩토링 시에도 테스트를 통해 기능의 안정성을 유지할 수 있습니다.
    • 신뢰성 증가:
      • 자동화된 테스트는 기능의 신뢰성을 높이고, 배포 전에 문제가 발생하지 않도록 보장합니다.
      • 코드의 변경 사항이 예상대로 동작하는지 지속적으로 확인할 수 있습니다.
  • TDD의 한계
    • 초기 투자 비용:
      • 테스트를 작성하는 데 추가적인 시간이 필요하므로, 초기 개발 속도가 느릴 수 있습니다.
      • 복잡한 테스트 케이스를 작성해야 하는 경우, 개발 부담이 증가할 수 있습니다.
    • 테스트 유지보수:
      • 코드가 변경될 때마다 테스트 코드도 함께 수정해야 하므로, 테스트 유지보수 비용이 발생할 수 있습니다.
    • 테스트 품질에 의존:
      • 테스트 코드의 품질이 낮거나, 테스트가 충분하지 않으면, TDD의 효과를 충분히 얻기 어렵습니다.
  • TDD의 주요 단계 예시
    • 요구사항 분석:
      • 구현할 기능의 요구사항을 명확히 이해하고, 이를 기반으로 테스트 케이스를 설계합니다.
    • 테스트 작성:
      • 구현할 기능의 가장 기본적인 테스트 케이스를 작성합니다. 예를 들어, 함수의 입력과 예상 출력을 정의합니다.
    • 코드 작성:
      • 작성된 테스트를 통과할 최소한의 코드를 구현합니다. 이 단계에서는 복잡한 로직보다는 테스트를 통과하는 것에 초점을 맞춥니다.
    • 리팩토링:
      • 코드의 중복을 제거하고, 가독성과 유지보수성을 높이기 위해 코드를 정리합니다. 리팩토링 후에도 모든 테스트가 통과해야 합니다.
  • TDD와 BDD 비교
    • TDD (Test-Driven Development):
      • 구현할 기능의 세부 사항에 초점을 맞추며, 개발자가 테스트 코드를 먼저 작성합니다.
      • 테스트는 주로 단위 테스트(Unit Test)로 구성됩니다.
    • BDD (Behavior-Driven Development):
      • 시스템의 동작과 사용자의 요구사항에 초점을 맞추며, 비즈니스 가치를 강조합니다.
      • 테스트는 주로 시나리오 기반으로 작성되며, Given-When-Then 패턴을 사용합니다.

 

프로세스와 쓰레드에 대해서 설명하고 그 차이에 대해서 설명해주세요.

프로세스와 쓰레드의 개념

  • 프로세스 (Process):
    • 정의: 프로세스는 실행 중인 프로그램의 인스턴스로, 자체 메모리 공간과 시스템 자원을 갖고 독립적으로 실행됩니다.
    • 특징:
      • 독립적인 메모리 공간: 각 프로세스는 독립적인 주소 공간을 가집니다.
      • 자원 관리: 프로세스는 CPU 시간, 메모리, 파일 핸들 등의 자원을 관리합니다.
      • 안전성: 한 프로세스의 문제는 다른 프로세스에 영향을 미치지 않습니다.
  • 쓰레드 (Thread):
    • 정의: 쓰레드는 프로세스 내에서 실행되는 경량 프로세스로, 프로세스의 자원을 공유하면서 동시에 실행됩니다.
    • 특징:
      • 공유 메모리 공간: 같은 프로세스 내의 쓰레드는 동일한 주소 공간을 공유합니다.
      • 빠른 생성과 종료: 쓰레드는 프로세스보다 생성과 종료가 빠릅니다.
      • 자원 공유: 쓰레드는 메모리, 파일 핸들 등을 공유하여 자원 소모가 적습니다.

프로세스와 쓰레드의 차이점

  • 메모리와 자원 관리:
    • 프로세스:
      • 독립적인 메모리 공간과 자원을 가집니다.
      • 다른 프로세스와 메모리 공간을 공유하지 않습니다.
    • 쓰레드:
      • 같은 프로세스 내에서 메모리와 자원을 공유합니다.
      • 동일한 데이터에 접근할 수 있어, 데이터 공유가 용이하지만 동기화가 필요합니다.
  • 운영 체제 자원 소비:
    • 프로세스:
      • 생성과 종료 시 운영 체제의 오버헤드가 큽니다.
      • 문맥 전환 시에도 오버헤드가 큽니다.
    • 쓰레드:
      • 상대적으로 적은 오버헤드로 생성되고 종료됩니다.
      • 문맥 전환 시 오버헤드가 작습니다.
  • 실행 단위:
    • 프로세스:
      • 독립적인 실행 단위로, 다른 프로세스와 별개로 실행됩니다.
    • 쓰레드:
      • 프로세스 내의 실행 단위로, 같은 프로세스의 다른 쓰레드와 협력하여 실행됩니다.
  • 통신 및 데이터 공유:
    • 프로세스:
      • 프로세스 간 통신(IPC, Inter-Process Communication)을 통해 데이터를 주고받아야 합니다.
      • 예: 파이프, 소켓, 공유 메모리, 메시지 큐 등.
    • 쓰레드:
      • 프로세스 내의 모든 쓰레드가 메모리를 공유하므로, 데이터 공유가 간단하지만 동기화가 필요합니다.

장단점 비교

  • 프로세스의 장점:
    • 안전성: 한 프로세스의 장애가 다른 프로세스에 영향을 미치지 않습니다.
    • 강한 격리: 독립적인 메모리 공간으로 인해 높은 보안과 안정성을 제공합니다.
  • 프로세스의 단점:
    • 높은 오버헤드: 프로세스 생성, 종료, 문맥 전환 시 많은 자원이 소모됩니다.
    • 복잡한 통신: 프로세스 간의 통신이 복잡하고, 성능 저하가 있을 수 있습니다.
  • 쓰레드의 장점:
    • 빠른 실행: 쓰레드는 가볍고, 생성 및 종료가 빠릅니다.
    • 효율적인 자원 사용: 메모리와 자원을 공유하여 효율적으로 사용할 수 있습니다.
    • 쉬운 데이터 공유: 동일한 메모리 공간을 공유하므로, 데이터 공유가 용이합니다.
  • 쓰레드의 단점:
    • 동기화 문제: 데이터 공유 시 동기화 문제로 인해 교착 상태(Deadlock)나 경쟁 조건(Race Condition)이 발생할 수 있습니다.
    • 안정성 문제: 한 쓰레드의 문제가 프로세스 전체에 영향을 미칠 수 있습니다.

사용 사례 예시

  • 프로세스 사용 예시:
    • 독립적인 애플리케이션: 웹 서버와 데이터베이스 서버 등 독립적인 애플리케이션은 각각의 프로세스로 실행됩니다.
    • 안전이 중요한 시스템: 보안과 안정성이 중요한 경우, 독립적인 프로세스가 선호됩니다.
  • 쓰레드 사용 예시:
    • 병렬 처리: 다중 쓰레드를 사용하여 작업을 병렬로 처리하는 경우, 예를 들어 멀티쓰레드 웹 서버는 각 클라이언트 요청을 별도의 쓰레드로 처리합니다.
    • 경량 작업: 가벼운 작업이나 빠른 응답이 필요한 작업에서 쓰레드가 유용합니다.

 

멀티프로세스와 멀티쓰레드의 특징에 대해 설명해주세요.

멀티프로세스 (Multiprocessing)와 멀티쓰레드 (Multithreading)의 특징

  • 멀티프로세스 (Multiprocessing)
    • 개념:
      • 멀티프로세스는 여러 개의 독립된 프로세스를 생성하여 병렬로 작업을 수행하는 방식입니다.
    • 특징:
      • 독립된 메모리 공간:
        • 각 프로세스는 별도의 주소 공간을 가지고, 메모리를 독립적으로 사용합니다.
      • 안전성:
        • 한 프로세스의 장애가 다른 프로세스에 영향을 미치지 않기 때문에 안정성이 높습니다.
      • 운영 체제의 자원 사용:
        • 프로세스 생성, 종료 및 문맥 전환 시 운영 체제의 자원을 많이 소모합니다.
      • 복잡한 프로세스 간 통신 (IPC):
        • 프로세스 간 통신이 필요하며, 파이프, 소켓, 공유 메모리, 메시지 큐 등을 사용합니다.
    • 장점:
      • 강한 격리: 프로세스 간에 메모리와 자원이 독립적이므로, 보안과 안정성이 높습니다.
      • 병렬 처리 가능: 여러 CPU 코어에서 병렬로 작업을 처리할 수 있습니다.
    • 단점:
      • 높은 오버헤드: 프로세스 생성과 문맥 전환이 비용이 많이 들고, 느릴 수 있습니다.
      • 복잡한 통신: 프로세스 간 데이터 공유 및 통신이 복잡하고, 성능 저하가 발생할 수 있습니다.
    • 사용 사례:
      • 독립적인 작업: 서로 독립적이고 격리된 작업이 필요한 경우, 예를 들어 웹 서버와 데이터베이스 서버와 같은 경우.
      • 고안정성 요구: 안정성이 중요한 시스템에서 멀티프로세스가 적합합니다.
  • 멀티쓰레드 (Multithreading)
    • 개념:
      • 멀티쓰레드는 하나의 프로세스 내에서 여러 쓰레드를 생성하여 병렬로 작업을 수행하는 방식입니다.
    • 특징:
      • 공유 메모리 공간:
        • 같은 프로세스 내의 쓰레드는 동일한 주소 공간을 공유합니다.
      • 효율적인 자원 사용:
        • 쓰레드는 메모리와 자원을 공유하여 자원 소모가 적습니다.
      • 빠른 쓰레드 생성 및 문맥 전환:
        • 쓰레드는 프로세스보다 생성과 종료가 빠르고, 문맥 전환도 비용이 적습니다.
      • 동기화 필요:
        • 데이터 공유 시 동기화가 필요하여, 경쟁 조건(Race Condition)이나 교착 상태(Deadlock)이 발생할 수 있습니다.
    • 장점:
      • 빠른 응답성: 쓰레드 간 문맥 전환이 빠르고, 응답성이 높습니다.
      • 효율적인 자원 공유: 동일한 메모리 공간을 공유하여, 자원 사용이 효율적입니다.
      • 경량화: 쓰레드는 가볍고, 시스템 자원을 적게 사용합니다.
    • 단점:
      • 동기화 문제: 동기화 오류로 인한 교착 상태나 경쟁 조건이 발생할 수 있습니다.
      • 안정성 문제: 하나의 쓰레드가 문제가 생기면, 전체 프로세스에 영향을 미칠 수 있습니다.
    • 사용 사례:
      • 빠른 데이터 처리: 빠른 응답과 실시간 처리가 필요한 애플리케이션, 예를 들어 멀티쓰레드 웹 서버.
      • 자원 공유가 필요한 작업: 자원 공유가 빈번한 경우에 유리합니다.
  • 멀티프로세스와 멀티쓰레드 비교 요약
    • 메모리 관리:
      • 멀티프로세스: 각 프로세스는 독립된 메모리 공간을 가집니다.
      • 멀티쓰레드: 모든 쓰레드는 동일한 메모리 공간을 공유합니다.
    • 안전성:
      • 멀티프로세스: 하나의 프로세스에 문제가 발생해도 다른 프로세스에 영향을 주지 않습니다.
      • 멀티쓰레드: 하나의 쓰레드 문제는 전체 프로세스에 영향을 줄 수 있습니다.
    • 통신:
      • 멀티프로세스: 복잡한 IPC를 통해 통신해야 합니다.
      • 멀티쓰레드: 메모리 공간을 공유하여 통신이 간단합니다.
    • 자원 사용:
      • 멀티프로세스: 자원 소모가 많고, 문맥 전환 비용이 큽니다.
      • 멀티쓰레드: 자원 소모가 적고, 문맥 전환이 빠릅니다.
    • 오버헤드:
      • 멀티프로세스: 프로세스 생성 및 종료 오버헤드가 큽니다.
      • 멀티쓰레드: 쓰레드 생성 및 종료 오버헤드가 작습니다.

 

쿼리 최적화에 대해 설명해주시고 방법에 대해 설명해주세요.

쿼리 최적화는 데이터베이스의 성능을 향상시키기 위해 쿼리의 실행 계획을 개선하는 과정입니다. 최적화된 쿼리는 데이터 검색 속도를 높이고 시스템 리소스 사용을 최소화할 수 있습니다. 다음은 쿼리 최적화에 대한 설명과 구체적인 방법들입니다.

  • 쿼리 최적화의 중요성
    • 성능 향상: 응답 시간을 줄이고 데이터 처리 속도를 높입니다.
    • 리소스 효율성: CPU, 메모리, 디스크 I/O와 같은 시스템 리소스를 효율적으로 사용합니다.
    • 확장성: 데이터베이스의 확장성을 높여 더 많은 데이터와 트래픽을 처리할 수 있습니다.
    • 사용자 경험 개선: 빠른 응답 시간을 통해 사용자 만족도를 높입니다.
  • 쿼리 최적화 방법
    • 인덱스 사용
      • 적절한 인덱스: 빈번하게 검색되는 컬럼에 인덱스를 생성합니다.
      • 복합 인덱스: 여러 컬럼을 조합하여 인덱스를 생성, 검색 속도를 개선합니다.
      • 인덱스 사용 주의: 인덱스가 너무 많으면 삽입/수정 성능이 저하될 수 있으므로 필요한 경우에만 생성합니다.
    • 쿼리 리팩토링
      • 단순화: 복잡한 쿼리를 단순화하여 실행 계획을 최적화합니다.
      • 서브쿼리 최소화: 서브쿼리 대신 조인을 사용하여 성능을 향상시킵니다.
      • 불필요한 컬럼 제외: SELECT 문에서 필요한 컬럼만 조회하여 데이터 전송량을 줄입니다.
    • 조인 최적화
      • 적절한 조인 순서: 조인 순서를 최적화하여 필요한 데이터만 빠르게 가져옵니다.
      • 조인 조건 최적화: 조인 조건에 인덱스를 사용하여 성능을 개선합니다.
      • 필터링 조건: 조인 후에 필터링하는 대신, 가능한 한 조인 전에 필터링합니다.
    • 쿼리 계획 분석
      • EXPLAIN 사용: 쿼리의 실행 계획을 분석하여 병목 지점을 식별합니다.
      • 실행 계획 이해: 인덱스 사용 여부, 조인 방식, 쿼리 비용 등을 분석합니다.
    • 캐싱
      • 쿼리 결과 캐싱: 자주 사용되는 쿼리 결과를 캐시하여 데이터베이스 부하를 줄입니다.
      • 프레임워크 캐싱: Hibernate나 MyBatis와 같은 ORM 프레임워크의 캐시 기능을 활용합니다.
    • 파티셔닝
      • 데이터 파티셔닝: 대용량 테이블을 작은 파티션으로 나누어 쿼리 성능을 개선합니다.
      • 범위 파티셔닝: 날짜나 범위 기준으로 테이블을 분할합니다.
      • 해시 파티셔닝: 해시 함수를 사용하여 균등하게 분할합니다.
    • 데이터베이스 튜닝
      • 파라미터 조정: 데이터베이스 설정 파라미터를 조정하여 성능을 최적화합니다.
      • 하드웨어 자원: CPU, 메모리, 스토리지 등 하드웨어 자원을 업그레이드합니다.
    • 거버넌스
      • 쿼리 리뷰 프로세스: 새로운 쿼리 도입 시 리뷰 프로세스를 거쳐 최적화 여부를 검토합니다.
      • 자동화 도구 사용: 쿼리 성능을 모니터링하고 자동으로 최적화하는 도구를 사용합니다.

쿼리 최적화는 데이터베이스 성능을 극대화하기 위한 필수적인 과정입니다. 다양한 최적화 기법을 활용하여 시스템의 효율성을 높이고, 사용자에게 빠르고 안정적인 서비스를 제공하는 것이 목표입니다. 최적화 과정에서는 쿼리의 특성과 데이터베이스의 구조를 잘 이해하고, 지속적인 모니터링과 튜닝을 통해 성능을 유지하는 것이 중요합니다.

 

DB 로직 최소화를 하려면 어떻게 해야 할까요?

데이터베이스(DB) 로직을 최소화하는 것은 애플리케이션의 성능 최적화와 유지보수 용이성을 위해 중요한 전략입니다. 이를 위해 몇 가지 핵심적인 방법을 고려할 수 있습니다:

 

  • 비즈니스 로직의 애플리케이션 레이어 이동
    • 설명: 비즈니스 로직을 데이터베이스에서 애플리케이션 레이어(서비스 또는 도메인 레이어)로 이동시킵니다.
    • 이유: 데이터베이스는 데이터 저장 및 기본 CRUD 작업에 집중하고, 복잡한 비즈니스 로직은 애플리케이션에서 처리합니다.
    • 방법:
      • Stored Procedure나 Trigger에 있는 비즈니스 로직을 Java, Python 등 애플리케이션 코드로 이동.
      • ORM을 사용하여 엔티티와 관련된 비즈니스 로직을 서비스 계층으로 구현.
  • ORM 활용
    • 설명: ORM(Object-Relational Mapping) 프레임워크를 사용하여 데이터베이스와 객체 간의 매핑을 처리합니다.
    • 이유: 데이터베이스와 객체 간의 매핑을 자동화하여 개발 생산성을 높이고, 쿼리 작성 부담을 줄입니다.
    • 방법:
      • Hibernate, JPA와 같은 ORM 도구 사용.
      • QueryDSL과 같은 동적 쿼리 작성 도구 활용.
  • 데이터베이스 트리거와 스토어드 프로시저 최소화
    • 설명: 데이터베이스 내에서의 복잡한 트리거와 스토어드 프로시저 사용을 최소화합니다.
    • 이유: 데이터베이스에 종속적인 로직을 줄이고, 코드의 가독성과 유지보수성을 높입니다.
    • 방법:
      • 비즈니스 로직이 포함된 트리거를 애플리케이션 코드로 이전.
      • 복잡한 스토어드 프로시저를 서비스 계층의 로직으로 대체.
  • 데이터 접근 레이어 추상화
    • 설명: 데이터베이스 접근 로직을 추상화하여 데이터베이스 종속성을 줄입니다.
    • 이유: 데이터베이스 종속성을 줄여 데이터베이스 변경 시의 영향을 최소화합니다.
    • 방법:
      • Repository 패턴을 사용하여 데이터 접근 로직을 추상화.
      • DAO(Data Access Object) 패턴으로 데이터 접근을 모듈화.
  • 명령형 쿼리 최소화
    • 설명: SQL 쿼리의 사용을 최소화하고, ORM의 고수준 API를 활용합니다.
    • 이유: SQL 쿼리의 직접적인 사용을 줄여 데이터베이스 종속성과 복잡성을 낮춥니다.
    • 방법:
      • JPQL이나 Criteria API를 사용하여 쿼리 작성.
      • Named Query를 활용하여 복잡한 쿼리를 ORM 설정 파일에 정의.
  • 데이터 정규화 및 모델링 개선
    • 설명: 데이터 모델을 정규화하여 중복을 최소화하고, 데이터 무결성을 유지합니다.
    • 이유: 데이터베이스 구조를 단순화하여 비즈니스 로직을 애플리케이션 레이어로 이동하기 쉽게 만듭니다.
    • 방법:
      • 정규화 규칙을 준수하여 데이터 모델링.
      • 필요 시 데이터 중복을 최소화하는 방식으로 정규화.
  • 로깅 및 모니터링 도구 활용
    • 설명: 데이터베이스 로직의 사용 빈도와 성능을 모니터링합니다.
    • 이유: 불필요한 데이터베이스 로직의 사용을 식별하고, 애플리케이션 로직으로 이전할 기회를 포착합니다.
    • 방법:
      • APM(Application Performance Management) 도구를 사용하여 데이터베이스 쿼리 모니터링.
      • 로그 분석 도구로 쿼리 성능 및 빈도 분석.
  • 캐싱 전략 활용
    • 설명: 자주 사용되는 데이터에 대해 캐싱을 활용하여 데이터베이스 부하를 줄입니다.
    • 이유: 데이터베이스 호출을 줄이고, 애플리케이션 성능을 향상시킵니다.
    • 방법:
      • Ehcache, Redis와 같은 캐시 솔루션 사용.
      • 애플리케이션 코드에서 데이터 캐싱 로직 구현.

DB 로직을 최소화하기 위해서는 비즈니스 로직을 애플리케이션 레이어로 이동하고, 데이터 접근을 추상화하며, ORM을 적극 활용하는 것이 중요합니다. 이를 통해 데이터베이스의 부담을 줄이고, 애플리케이션의 유지보수성과 확장성을 높일 수 있습니다. 지속적인 모니터링과 최적화를 통해 데이터베이스와 애플리케이션 간의 이상적인 균형을 유지하는 것이 핵심입니다.

 

테스트코드에 대해서 아는대로 설명해주시고 활용 경험에 대해서 답변해주세요.

테스트 코드는 소프트웨어의 특정 기능이나 모듈이 의도한 대로 작동하는지 검증하기 위해 작성된 코드입니다. 테스트 코드를 작성하면 코드의 품질을 높이고, 버그를 조기에 발견하며, 리팩토링 시에도 기능이 정상 작동하는지 확인할 수 있습니다.

  • 테스트 코드의 유형
    • 단위 테스트 (Unit Test)
      • 목적: 개별 함수나 메서드의 동작을 검증합니다.
      • 특징: 테스트 대상 코드의 가장 작은 단위를 테스트하며, 외부 종속성 없이 독립적으로 실행합니다.
      • 도구: JUnit, TestNG 등.
    • 통합 테스트 (Integration Test)
      • 목적: 여러 모듈이 통합되어 올바르게 작동하는지 확인합니다.
      • 특징: 데이터베이스, 파일 시스템 등 외부 시스템과의 상호작용을 포함하여 테스트합니다.
      • 도구: Spring Test, TestContainers 등.
    • 기능 테스트 (Functional Test)
      • 목적: 시스템의 기능적 요구사항을 검증합니다.
      • 특징: 사용자 시나리오를 기반으로 테스트합니다.
      • 도구: Selenium, Cucumber 등.
    • 회귀 테스트 (Regression Test)
      • 목적: 기존 기능이 새로운 변경 사항에 의해 영향을 받지 않았는지 확인합니다.
      • 특징: 새로운 기능 추가나 버그 수정 후 전체 시스템의 안정성을 검증합니다.
    • 시스템 테스트 (System Test)
      • 목적: 시스템의 전체적인 동작을 검증합니다.
      • 특징: 실제 사용 환경을 모사하여 테스트합니다.
      • 도구: JMeter, Gatling 등.
    • 성능 테스트 (Performance Test)
      • 목적: 시스템의 성능, 반응 시간, 안정성을 검증합니다.
      • 특징: 부하 테스트, 스트레스 테스트 등이 포함됩니다.
      • 도구: JMeter, LoadRunner 등.
  • 테스트 코드의 장점
    • 신뢰성 향상: 코드의 신뢰성을 높여줍니다.
    • 버그 조기 발견: 개발 초기 단계에서 버그를 발견할 수 있습니다.
    • 리팩토링 안전성: 리팩토링 후에도 기능이 정상 동작함을 보장합니다.
    • 문서화 역할: 코드의 사용법을 문서화하는 역할을 합니다.
  • 테스트 코드 작성 원칙
    • 독립적 실행: 테스트는 서로 독립적이어야 합니다.
    • 재현 가능성: 테스트 결과는 언제나 동일해야 합니다.
    • 빠른 실행: 테스트는 빠르게 실행되어야 합니다.
    • 명확한 결과: 테스트는 성공 또는 실패를 명확하게 나타내야 합니다.

프로젝트 : 인디안 개구리

목적 : 인디언 포커 게임의 웹 서비스

역할 : 게임 로직 구현, 모니터링 설정

 

단위 테스트 경험

  • 사용 도구 : JUnit, Mockito
  • 내용
    • 주요 게임 로직에 대해 단위 테스트를 작성했습니다.
    • Mock 객체를 사용해 외부 의존성을 최소화하고, 서비스 계층의 메서드들을 검증했습니다.
    • 게임 시작 시 카드 분배, 베팅 금액 설정, 베팅 액션 로직, 라운드 종료, 게임 종료 로직 검증을 수행했습니다.

 

Array, LinkedList에 대해 설명해주시고 각각 어떻게 사용하는지 말씀해주세요.

Array와 LinkedList의 개념 및 사용 방법

  • Array (배열)
    • 개념:
      • Array는 동일한 데이터 타입의 요소들이 연속된 메모리 공간에 저장되는 자료 구조입니다.
      • 요소들은 인덱스를 통해 직접 접근할 수 있습니다.
    • 특징:
      • 정적 크기:
        • 배열의 크기는 초기화 시에 결정되며, 이후에는 변경할 수 없습니다.
      • 빠른 접근 속도:
        • 인덱스를 이용한 임의 접근(random access)이 가능하여, 접근 속도가 매우 빠릅니다 (O(1)).
      • 연속된 메모리:
        • 메모리 상에 연속적으로 저장되므로, 캐시 효율성이 높습니다.
    • 장점:
      • 빠른 데이터 접근: 인덱스를 이용해 O(1) 시간 복잡도로 접근할 수 있습니다.
      • 단순한 구현: 구조가 단순하여 사용하기 쉽습니다.
    • 단점:
      • 고정 크기: 배열의 크기를 미리 지정해야 하므로, 메모리 낭비가 발생할 수 있습니다.
      • 삽입 및 삭제 비용: 중간에 요소를 삽입하거나 삭제할 때, 다른 요소들을 이동시켜야 하므로 비용이 큽니다 (O(n)).
    • 사용 예시:
      • 고정 크기의 데이터: 예를 들어, 주어진 크기의 데이터를 처리하는 경우.
      • 빈번한 읽기 작업: 데이터 접근이 빈번하고, 데이터의 추가/삭제가 적은 경우.
  • LinkedList (연결 리스트)
    • 개념:
      • LinkedList는 노드들이 포인터를 통해 연결된 형태의 자료 구조입니다. 각 노드는 데이터와 다음 노드를 가리키는 포인터를 포함합니다.
      • 주요 형태로는 단일 연결 리스트(Singly Linked List), 이중 연결 리스트(Doubly Linked List), 원형 연결 리스트(Circular Linked List)가 있습니다.
    • 특징:
      • 동적 크기:
        • 필요에 따라 크기가 동적으로 조정될 수 있습니다.
      • 순차 접근:
        • 노드들을 순차적으로 접근해야 하며, 임의 접근이 어렵습니다.
    • 장점:
      • 유연한 크기 조정: 데이터의 추가 및 삭제가 용이하여, 크기를 유연하게 조정할 수 있습니다.
      • 빠른 삽입 및 삭제: 중간에 요소를 삽입하거나 삭제할 때, 포인터만 변경하면 되므로 비용이 적습니다 (O(1) - 특정 위치를 알고 있는 경우).
    • 단점:
      • 느린 접근 속도: 특정 위치에 접근하려면 순차적으로 탐색해야 하므로, 접근 속도가 느립니다 (O(n)).
      • 추가 메모리 사용: 포인터를 저장하기 위한 추가 메모리가 필요합니다.
  • 사용 예시:
    • 빈번한 데이터 추가/삭제: 데이터의 삽입 및 삭제가 빈번한 경우, 예를 들어 대기열(Queue)나 스택(Stack) 구현.
    • 동적 데이터 관리: 데이터의 크기가 동적으로 변하는 경우.
  • 비교 요약
    • 메모리 사용:
      • Array: 연속된 메모리 공간을 사용.
      • LinkedList: 포인터를 포함한 노드들로 구성.
    • 데이터 접근:
      • Array: 인덱스를 통한 임의 접근이 빠름 (O(1)).
      • LinkedList: 순차 접근이 필요함 (O(n)).
    • 삽입 및 삭제:
      • Array: 중간 삽입/삭제가 비효율적 (O(n)).
      • LinkedList: 중간 삽입/삭제가 효율적 (O(1) - 특정 위치를 알고 있는 경우).
    • 크기 조정:
      • Array: 고정 크기, 크기 변경이 어렵다.
      • LinkedList: 동적 크기, 크기 변경이 용이하다.
  • 사용 사례 비교
    • Array 사용 시기:
      • 데이터의 크기가 고정되어 있고, 빠른 데이터 접근이 필요한 경우.
      • 예: 배열 기반의 해시 테이블 구현, 고정 크기의 데이터 저장.
    • LinkedList 사용 시기:
      • 데이터의 삽입 및 삭제가 빈번하고, 크기가 동적으로 변하는 경우.
      • 예: 링크드 리스트 기반의 큐, 스택, 연결된 데이터 구조.

 

AWS S3, EC2를 사용하는 이유와 사용 경험에 대해서 답변해주세요.

AWS S3(Simple Storage Service)와 EC2(Elastic Compute Cloud)는 AWS의 핵심 서비스로, 다양한 프로젝트에서 널리 사용됩니다. 각 서비스의 사용 이유와 경험에 대해 상세히 설명드리겠습니다.

  • AWS S3 사용 이유
    • 안정성과 내구성
      • 설명: S3는 높은 내구성(99.999999999%, 11 9’s)을 제공하여 데이터 손실 위험이 거의 없습니다.
      • 활용 예시: 프로젝트에서 중요한 로그 파일과 백업 데이터를 S3에 저장하여 데이터 안정성을 확보했습니다.
    • 확장성
      • 설명: 자동으로 확장되는 스토리지 시스템으로, 용량 제한 없이 데이터를 저장할 수 있습니다.
      • 활용 예시: 대량의 사용자 업로드 이미지와 동영상 파일을 S3에 저장하여 확장성 있는 스토리지 솔루션을 구현했습니다.
    • 보안 기능
      • 설명: 데이터 암호화, 액세스 제어, 버전 관리 등 강력한 보안 기능을 제공합니다.
      • 활용 예시: S3 버킷 정책과 IAM 역할을 활용하여 민감한 데이터를 안전하게 저장하고, 필요에 따라 액세스를 제어했습니다.
    • 비용 효율성
      • 설명: 사용한 만큼만 지불하는 종량제 요금 구조로, 비용 효율적입니다.
      • 활용 예시: 자주 사용되지 않는 데이터는 S3 Glacier로 이동하여 비용을 절감했습니다.
    • 다양한 통합 기능
      • 설명: 다양한 AWS 서비스와 쉽게 통합됩니다.
      • 활용 예시: Lambda와 연동하여 S3에 파일이 업로드될 때 자동으로 이미지 리사이징 작업을 수행했습니다.
  • AWS EC2 사용 이유
    • 유연한 컴퓨팅 리소스
      • 설명: 다양한 인스턴스 타입을 선택하여 필요에 맞는 컴퓨팅 파워를 제공합니다.
      • 활용 예시: 웹 서버, 데이터베이스 서버 등 다양한 용도로 EC2 인스턴스를 설정하여 사용했습니다.
    • 자동 확장과 로드 밸런싱
      • 설명: Auto Scaling과 Elastic Load Balancing(ELB)을 통해 자동으로 트래픽을 분산하고 확장할 수 있습니다.
      • 활용 예시: EC2 Auto Scaling을 설정하여 트래픽 증가 시 자동으로 인스턴스를 추가하고, ELB를 통해 부하를 분산했습니다.
    • 유연한 네트워킹 옵션
      • 설명: VPC, 서브넷, 보안 그룹 등 네트워크 설정을 세밀하게 제어할 수 있습니다.
      • 활용 예시: VPC 내에서 EC2 인스턴스를 구성하고, 보안 그룹을 설정하여 애플리케이션의 네트워크 보안을 강화했습니다.
    • 고가용성 및 지역 분산
      • 설명: 여러 가용 영역(AZ)과 리전에서 인스턴스를 배포하여 고가용성을 확보할 수 있습니다.
      • 활용 예시: 중요 애플리케이션을 여러 AZ에 걸쳐 배포하여 장애에 대한 내성을 높였습니다.
    • 비용 관리
      • 설명: 예약 인스턴스, 스팟 인스턴스를 통해 비용 절감이 가능합니다.
      • 활용 예시: 예측 가능한 워크로드에는 예약 인스턴스를 사용하고, 비상시에는 스팟 인스턴스를 활용하여 비용을 절감했습니다.

사용경험

Spring Boot로 개발한 애플리케이션을 AWS EC2를 사용하여 웹 환경에 배포 후 유저 테스트를 진행하여 피드백에 따라 애플리케이션을 개선했습니다.

AWS S3를 사용해 유저 프로필 이미지를 업로드, 수정할 수 있도록 했습니다.

 

정렬 알고리즘에 대해서 아는대로 설명해주세요.

정렬 알고리즘은 데이터를 특정 순서대로 정렬하는 알고리즘을 말하며, 주로 오름차순 또는 내림차순으로 정렬합니다. 주요 정렬 알고리즘에는 버블 정렬, 선택 정렬, 삽입 정렬, 퀵 정렬, 병합 정렬, 힙 정렬 등이 있습니다.

  • 버블 정렬 (Bubble Sort):
    • 설명: 인접한 두 요소를 비교하여 필요에 따라 교환하는 방식으로, 가장 큰 요소가 차례로 제자리로 이동합니다.
    • 복잡도: 평균 및 최악의 경우 시간 복잡도는 O(n²).
    • 특징: 단순하지만 비효율적이며, 작은 데이터셋에 적합합니다.
  • 선택 정렬 (Selection Sort):
    • 설명: 주어진 리스트에서 가장 작은 요소를 찾아 맨 앞의 요소와 교환하는 과정을 반복합니다.
    • 복잡도: 평균 및 최악의 경우 시간 복잡도는 O(n²).
    • 특징: 단순하지만 비효율적이며, 데이터 이동 횟수가 비교적 적습니다.
  • 삽입 정렬 (Insertion Sort):
    • 설명: 정렬된 부분에 새 요소를 올바른 위치에 삽입하는 방식으로 진행합니다.
    • 복잡도: 평균 및 최악의 경우 시간 복잡도는 O(n²), 최선의 경우 O(n).
    • 특징: 작은 데이터셋이나 거의 정렬된 데이터에 효율적입니다.
  • 퀵 정렬 (Quick Sort):
    • 설명: 피벗을 기준으로 작은 요소와 큰 요소로 분할하여 정렬하는 분할 정복 알고리즘입니다.
    • 복잡도: 평균 시간 복잡도는 O(n log n), 최악의 경우 O(n²).
    • 특징: 평균적으로 매우 빠르며, 대부분의 경우 효율적입니다.
  • 병합 정렬 (Merge Sort):
    • 설명: 리스트를 반으로 나누고 각각을 정렬한 후 합치는 분할 정복 알고리즘입니다.
    • 복잡도: 시간 복잡도는 항상 O(n log n).
    • 특징: 안정적인 정렬이며, 큰 데이터셋에도 효율적입니다.
  • 힙 정렬 (Heap Sort):
    • 설명: 힙 자료 구조를 이용하여 정렬하는 방식으로, 최대 힙 또는 최소 힙을 사용합니다.
    • 복잡도: 시간 복잡도는 항상 O(n log n).
    • 특징: 비교 기반 정렬 알고리즘 중 하나이며, 추가적인 메모리 공간이 거의 필요 없습니다.

'항해 99' 카테고리의 다른 글

OAuth  (0) 2024.05.20
WIL-15  (0) 2024.05.19
CS / 알고리즘 공부 1 - 운영 체제  (0) 2024.05.14
기술면접 준비 4주차 정리  (0) 2024.05.09
SSL / TLS  (0) 2024.05.08

'항해 99' Related Articles

티스토리툴바