cs - 객체지향,restful,시간공간복잡도,nosql,함수형프로그래밍,https,GIL,devops,git branch 전략

1. 캡슐화, 상속, 다형성이란 무엇이며, 이들이 객체 지향 프로그래밍에서 어떤 역할을 하는지 설명해 주시겠어요?

 

캡슐화는 객체의 속성과 행동을 하나로 묶고, 실제 구현 내용 일부를 외부에 감추어 은닉하는 것입니다. 이는 객체의 상태를 직접 변경하는 것이 아니라, 객체의 메서드를 통해서만 변경할 수 있도록 하는 것입니다. 이를 통해 객체의 내부 구조를 보호하고, 외부에서의 접근을 제어할 수 있습니다.

 

상속은 클래스간의 코드를 공유하는 방법으로, 기존 클래스의 특성을 재사용하고 확장할 수 있게 해줍니다. 부모 클래스(슈퍼 클래스)에서 정의된 속성과 메서드를 자식 클래스(서브 클래스)가 물려받아 사용하는 것입니다. 이를 통해 코드의 재사용성을 높이고, 중복된 코드를 최소화할 수 있습니다.

 

다형성은 하나의 인터페이스나 클래스가 다양한 형태로 동작하는 것을 의미합니다. 이를 통해 동일한 인터페이스를 가지지만 다르게 동작하는 객체를 생성할 수 있습니다. 다형성은 코드의 유연성과 확장성을 증가시켜 줍니다.

 

이 세 가지 원칙은 객체지향 프로그래밍의 중요한 핵심 개념이며, 코드의 재사용성, 유연성, 확장성 등을 증가시켜 주고, 코드의 복잡성을 줄여주는데 큰 역할을 합니다.

 

2. restful api란 무엇일까요?

 

RESTful API는 Representational State Transfer의 약자로, 웹의 장점을 최대한 활용할 수 있는 아키텍처 중 하나입니다. REST는 네트워크 아키텍처 원리의 모음으로서, 자원(URI)에 대한 CRUD 연산을 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 수행할 수 있도록 하는 것이 핵심입니다.

 

RESTful API를 디자인하는 핵심 원칙은 다음과 같습니다:

 

1. **Uniform Interface:** 이 원칙은 API가 간단하고 일관된 인터페이스를 가져야 한다는 것입니다. 이를 통해 API를 쉽게 사용하고 이해할 수 있습니다.

2. **Stateless:** 클라이언트의 상태 정보를 서버에 저장하지 않습니다. 즉, 각 요청은 서버가 클라이언트의 상태를 이해하는 데 필요한 모든 정보를 포함해야 합니다.

3. **Client-Server:** 클라이언트와 서버는 독립적으로 진화할 수 있어야 합니다. 즉, 클라이언트는 클라이언트 로직에, 서버는 서버 로직에 집중할 수 있습니다.

4. **Cacheable:** 클라이언트는 응답을 캐싱할 수 있어야 합니다. 이를 통해 클라이언트가 재요청 없이 응답을 재사용할 수 있게 합니다.

5. **Layered System:** 클라이언트는 직접 서버와 통신할 수도, 중간 서버를 거칠 수도 있습니다. 중간 서버는 로드 밸런싱이나 공유 캐시 등을 제공할 수 있습니다.

 

따라서, RESTful API란 REST 원칙을 따르는 웹 서비스를 지칭하며, 이를 통해 서비스 간에 상호작용을 할 수 있습니다.

 

3. 공간 복잡도와 시간 복잡도에 대해 설명해주세요. 어떤 상황에서 어떤 복잡도를 우선적으로 고려해야 할까요?

 

 

시간 복잡도와 공간 복잡도는 알고리즘의 효율성을 측정하는 두 가지 중요한 지표입니다.

시간 복잡도는 입력의 크기에 따라 알고리즘이 실행되는 데 걸리는 시간을 나타냅니다. 이는 주로 Big O 표기법을 사용하여 표현되며, 작업을 수행하는 데 필요한 단계의 수를 나타냅니다. 예를 들어, 선형 검색의 시간 복잡도는 O(n)으로 표현됩니다. 이는 검색하려는 항목의 수에 비례하여 시간이 증가한다는 것을 의미합니다.

공간 복잡도는 알고리즘이 실행되는 동안 사용하는 메모리 양을 나타냅니다. 공간 복잡도는 변수, 상수, 임시 변수 등 알고리즘이 실행되는 동안 필요한 공간을 모두 포함합니다.

일반적으로, 알고리즘은 시간 복잡도와 공간 복잡도 사이의 균형을 찾아야 합니다. 즉, 더 빠른 실행 시간을 얻기 위해 더 많은 메모리를 사용하거나, 반대로 더 적은 메모리를 사용하면서 실행 시간을 늘리는 경우가 종종 있습니다. 이러한 결정은 알고리즘의 특성, 사용 가능한 리소스 및 애플리케이션의 요구 사항에 따라 달라집니다.

 

4. 관계형 데이터베이스와 NoSQL 데이터베이스의 차이점을 설명해주세요. 각각 어떤 상황에서 사용하면 좋을까요?

 

 

관계형 데이터베이스(RDBMS)와 NoSQL 데이터베이스는 두 가지 주요한 데이터베이스 유형으로, 각각의 특성에 따라 서로 다른 사용 사례에 적합합니다.

 

관계형 데이터베이스는 테이블의 형태로 데이터를 저장하며, 각 테이블은 행과 열로 구성되어 있습니다. 테이블 간의 관계를 설정하여 데이터 간의 연결을 표현할 수 있습니다. RDBMS는 엄격한 스키마를 가지며, 트랜잭션의 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 보장합니다. 이로 인해 금융, 보건관리, 운송 등과 같이 정확성과 일관성이 중요한 애플리케이션에서 주로 사용됩니다.

 

반면에, NoSQL 데이터베이스는 스키마가 없거나 유연하며, 키-값 쌍, 원시 문서, 그래프 등 다양한 데이터 모델을 지원합니다. 이는 NoSQL이 대량의 비정형 데이터를 처리하거나, 빠르게 변화하는 애플리케이션에 적합하게 만듭니다. 또한, NoSQL 데이터베이스는 수평 확장이 가능하므로, 대규모 데이터를 처리하는 데 유용합니다.

 

하지만 NoSQL이 RDBMS보다 항상 나은 것은 아닙니다. 어떤 데이터베이스를 선택할지는 애플리케이션의 요구 사항, 데이터의 특성, 예상되는 트래픽 패턴 등 다양한 요소를 고려하여 결정해야 합니다.

 

5. 함수형 프로그래밍이란 무엇이며, 그 특징과 장단점에 대해 설명해주세요.

 

 

함수형 프로그래밍은 프로그램의 동작을 수학적 함수의 평가로 보는 프로그래밍 패러다임입니다. 함수형 프로그래밍의 핵심 원칙 중 하나는 불변성(immutability)입니다. 이는 함수의 입력이 같다면 출력도 항상 같아야 하며, 함수가 외부 상태를 변경하거나 영향을 받지 않아야 함을 의미합니다. 이로 인해 함수형 프로그래밍은 버그를 줄이고 테스트와 디버깅을 쉽게 만들 수 있습니다.

 

또한, 함수형 프로그래밍은 '일급 함수(first-class functions)'의 개념을 도입했습니다. 이는 함수를 다른 함수의 인자로 전달하거나, 함수에서 함수를 반환하고, 변수에 함수를 할당할 수 있음을 의미합니다. 이를 통해 고차 함수(higher-order functions)와 같은 고급 개념을 구현할 수 있습니다.

 

함수형 프로그래밍은 사이드 이펙트를 최소화하여 프로그램의 예측 가능성을 높이고, 복잡성을 관리하는 데 도움을 줍니다. 이로 인해 병렬 처리와 비동기 프로그래밍에 특히 유용합니다. 그러나 함수형 프로그래밍은 습득하기 어렵고, 특정 문제에 대한 직관적인 해결책을 제공하지 않을 수 있는 점에서 단점이 있습니다.

 

6. HTTP와 HTTPS의 차이에 대해 설명해주세요. HTTPS의 동작 방식에 대해서도 설명해주시면 좋겠습니다.

 

 

HTTP는 Hypertext Transfer Protocol의 약자로, 웹 서버와 클라이언트(브라우저) 사이의 통신 규약을 의미합니다. 그러나 HTTP는 텍스트 기반으로 정보를 전송하므로 중간에서 정보를 가로채는 '중간자 공격(Man-in-the-Middle Attack)'에 취약합니다.

 

HTTPS는 HTTP over Secure Socket Layer 혹은 HTTP over Transport Layer Security라고 불리며, HTTP에 보안 기능을 추가한 프로토콜입니다. HTTPS는 SSL(Secure Sockets Layer) 또는 그 후속 기술인 TLS(Transport Layer Security)를 이용해 통신을 암호화합니다.

 

HTTPS의 동작 방식은 다음과 같습니다:

 

1. 클라이언트가 서버에게 접속하면 서버는 클라이언트에게 SSL 인증서를 제공합니다.

2. 클라이언트는 이 인증서를 확인하고, 인증서가 신뢰할 수 있는 경우 서버에게 암호화에 사용할 공개키를 요청합니다.

3. 서버는 공개키를 클라이언트에게 제공하고, 클라이언트는 이를 이용해 통신 내용을 암호화하여 전송합니다.

4. 서버는 자신만이 가지고 있는 비밀키를 이용하여 암호화된 통신 내용을 복호화합니다.

 

이렇게 HTTPS는 정보를 암호화하여 통신하는 과정에서 정보의 기밀성을 보장하며, 인증서를 통해 서버의 신원을 확인함으로써 정보의 신뢰성을 보장합니다. 이러한 이유로, 개인정보를 다루는 웹사이트나 결제를 요구하는 웹사이트 등에서는 HTTPS를 사용하는 것이 필수적입니다.

 

7. Python의 GIL(Global Interpreter Lock)에 대해 설명해주세요. 이것이 멀티스레딩에 어떤 영향을 미치는지도 말씀해주시기 바랍니다.

 

 

GIL(Global Interpreter Lock)은 파이썬이 싱글 코어에서만 동작하도록 제한하는 메커니즘이며, 이로 인해 파이썬은 여러 쓰레드를 사용하여도 실질적으로 병렬처리를 하지 못합니다.

 

파이썬의 GIL은 메모리 관리를 안전하게 하기 위해 존재합니다. 파이썬은 참조 카운팅 방식으로 메모리를 관리하는데, 만약 GIL이 없다면 동시에 여러 쓰레드가 참조 카운트를 변경하려고 할 때 동기화 문제가 발생할 수 있습니다. 이로 인해 메모리 누수 또는 여타 다른 문제가 발생할 수 있습니다.

그러나 이 GIL 때문에, CPU 바인딩 작업에서 파이썬의 성능이 제한됩니다. 따라서, CPU 집중적인 작업에서는 다른 언어나 멀티 프로세싱 등의 방법을 고려해야 합니다.

 

8. DevOps가 무엇인지, 그리고 DevOps의 주요 도구나 기술에는 어떤 것들이 있는지 설명해주세요.

 

DevOps는 개발(Development)과 운영(Operations)을 합친 용어로, 소프트웨어 개발과 인프라 운영을 지속적으로 통합하고 자동화하여 더욱 빠르고 효율적인 제품 개발과 배포를 가능하게 하는 개발 방식입니다. 이를 통해 품질과 안정성을 유지하면서 개발과 배포 속도를 높이는 것을 목표로 합니다.

 

DevOps에서 주로 사용하는 도구와 기술은 다음과 같습니다:

 

1. 버전 컨트롤 시스템(VCS): Git과 같은 도구를 사용하여 코드의 버전 관리를 합니다.
2. CI/CD(지속적 통합/지속적 배포): Jenkins, Travis CI, CircleCI 등의 도구를 통해 코드의 통합과 테스트, 배포를 자동화합니다.
3. 컨테이너화: Docker와 같은 도구를 사용하여 애플리케이션과 그 의존성을 패키징하고, 실행 환경을 일관되게 유지합니다.
4. 구성 관리: Ansible, Chef, Puppet과 같은 도구를 사용하여 인프라의 구성을 코드화하고 자동화합니다.
5. 모니터링 및 로깅: Prometheus, ELK Stack(Elasticsearch, Logstash, Kibana) 등의 도구를 사용하여 시스템의 성능을 모니터링하고 로그를 관리합니다.
6. 클라우드 서비스: AWS, Google Cloud, Azure 등의 클라우드 서비스를 활용하여 인프라를 관리하고 확장합니다.

 

9. Git의 브랜치 전략에 대해 설명해주세요. 또한, Git Flow와 GitHub Flow의 차이점에 대해서도 설명해주시기 바랍니다.

 

Git에서 브랜치 전략은 코드베이스의 여러 버전을 동시에 관리하고, 팀원들이 협업을 할 수 있도록 하는 방식을 말합니다. 이는 보통 'master' 또는 'main' 브랜치에서 새로운 기능을 개발하거나 버그를 수정하기 위한 'feature' 브랜치를 분기하고, 작업이 완료되면 다시 'master' 브랜치로 병합(merge)하는 방식을 취합니다.

 

Git Flow와 GitHub Flow는 두 가지 대표적인 브랜치 전략입니다.

 

1. Git Flow: Git Flow는 'master', 'develop', 'feature/', 'release/', 'hotfix/' 등 다양한 종류의 브랜치를 활용하는 전략입니다. 'master'는 항상 배포 가능한 상태를 유지하며, 'develop'에서는 다음 배포를 위한 개발이 이루어집니다. 새로운 기능을 개발할 때는 'feature/' 브랜치를 분기하고, 배포 준비를 할 때는 'release/' 브랜치를 사용하며, 긴급한 버그 수정은 'hotfix/' 브랜치에서 진행합니다.
2. GitHub Flow: GitHub Flow는 더 간단한 방식을 취합니다. 'master' 브랜치에서 새로운 작업을 위한 브랜치를 분기하고, 해당 브랜치에서 모든 작업을 완료한 뒤에 Pull Request를 통해 코드 리뷰를 받습니다. 코드 리뷰 후 문제가 없다면 'master' 브랜치로 병합하고 바로 배포합니다.

 

이 두 전략 중 어느 것을 선택할지는 팀의 개발 환경과 필요성에 따라 달라집니다.