CS 지식 질문

HTTP METHOD에 대해 설명해 보세요.

 

HTTP (Hypertext Transfer Protocol)는 웹 브라우저와 웹 서버 간 통신을 위한 프로토콜입니다. HTTP 메서드는 웹 브라우저가 서버에게 요청을 보내는 방법을 나타내는 방식으로, 다양한 기능을 수행할 수 있습니다.

 

가장 일반적으로 사용되는 HTTP 메서드는 다음과 같습니다.

- GET: 서버로부터 정보를 요청할 때 사용됩니다. 예를 들어, 웹 페이지를 열거나 이미지를 다운로드할 때 사용됩니다.
- POST: 서버로 데이터를 보낼 때 사용됩니다. 예를 들어, 회원 가입 양식을 작성하거나 데이터베이스에 정보를 업데이트할 때 사용됩니다.
- PUT: 서버에 새로운 데이터를 업로드하거나, 기존 데이터를 업데이트할 때 사용됩니다.
- DELETE: 서버에서 데이터를 삭제할 때 사용됩니다.
- PATCH: PUT 메서드와 유사하지만, 서버의 데이터 일부를 업데이트하는 데 사용됩니다.
- HEAD: GET 메서드와 유사하지만, 서버에서 헤더 정보만 반환합니다.
- OPTIONS: 서버에서 사용 가능한 메서드 및 리소스에 대한 정보를 요청합니다.

 

HTTP 메서드를 올바르게 사용하면, 웹 어플리케이션을 효과적으로 설계하고 구현할 수 있습니다. 또한, 보안 문제를 예방하고 데이터 무결성을 유지할 수 있습니다.

 

 

---

HTTP 상태 코드에 대해 아는 대로 말해보세요.

 

HTTP 상태 코드는 웹 서버가 클라이언트 요청에 대해 응답할 때 반환되는 3자리 숫자 코드입니다. 상태 코드는 클라이언트에게 요청이 성공적으로 처리되었는지, 오류가 발생했는지 또는 다른 작업이 필요한지 등의 정보를 제공합니다.

 

가장 일반적으로 사용되는 상태 코드는 다음과 같습니다.

- 1xx (Informational): 요청이 받아들여졌으며 처리가 진행 중임을 나타냅니다.
- 2xx (Success): 요청이 성공적으로 처리되었음을 나타냅니다. 예를 들어, 200 OK 상태 코드는 요청이 성공적으로 처리되었음을 나타냅니다.
- 3xx (Redirection): 클라이언트가 요청한 리소스가 새로운 위치로 이동되었거나, 추가 작업이 필요함을 나타냅니다. 예를 들어, 301 Moved Permanently 상태 코드는 요청한 리소스가 새로운 위치로 옮겨졌음을 나타냅니다.
- 4xx (Client Error): 클라이언트 측의 오류가 발생했음을 나타냅니다. 예를 들어, 404 Not Found 상태 코드는 요청한 리소스가 존재하지 않음을 나타냅니다.
- 5xx (Server Error): 서버 측의 오류가 발생했음을 나타냅니다. 예를 들어, 500 Internal Server Error 상태 코드는 서버 측에서 오류가 발생했음을 나타냅니다.

 

HTTP 상태 코드를 이해하면, 백엔드와 프론트엔드 개발자 사이에서 소통이 원활하게 이루어집니다. 예를 들어 프론트 엔드는 쪽에서 상태 코드 마다 적절한 페이지를 배치하여 사용자 경험을 향상시킬 수 있습니다. 구체적으로 예를 들면 401. 403 상태 코드를 적절하게 처리하는 것은 보안 문제를 예방하고 만약에 400 상태가 반환되면 올바른 데이터를 다시 요청함으로써 데이터 무결성을 유지하는 데 도움이 됩니다.

 

 

 

---

RESTful API란?

 

RESTful API는 클라이언트와 서버 간의 상호작용 방식을 정해놓은 규칙 입니다. 이 규칙을 따르는 API 디자인 방식을 사용하면, 클라이언트는 서버와의 상호작용을 단순하게 할 수 있습니다.

 

RESTful API에서는 URI를 이용하여 자원을 명시하고, HTTP Method를 이용하여 해당 자원에 대한 CRUD 작업을 수행합니다. 예를 들어, GET 메소드를 이용하면 해당 자원을 조회하고, POST 메소드를 이용하면 새로운 자원을 생성합니다.

또한, RESTful API에서는 HTTP 요청과 응답 메시지가 자원을 표현하는 데 필요한 모든 정보를 포함합니다. 이를 자기 서술적 메시지라고 부릅니다.

RESTful API의 장점은 클라이언트와 서버 간의 상호작용을 단순화시키고, 확장성과 재사용성을 높일 수 있다는 점입니다. 또한, 다양한 플랫폼과 언어를 지원하며, 개발 및 유지보수 비용을 절감할 수 있습니다.

 

 

---

TDD란?

TDD(Test-Driven Development)는 소프트웨어 개발 방법론으로, 개발자가 테스트를 작성하고 해당 테스트를 통과시키는 코드를 작성하는 방식입니다. TDD의 핵심 개념은 "Red-Green-Refactor" 사이클로 이루어져 있습니다. 이 사이클은 다음과 같은 단계로 진행됩니다:

 

- Red (빨강): 새로운 기능을 추가하거나 기존 기능을 변경하기 위한 테스트를 작성합니다. 이 테스트는 아직 작성한 코드에 의해 실패해야 합니다. 이 단계에서는 최소한의 코드만 작성하고, 테스트가 실패하도록 유지합니다.
- Green (초록): 작성한 테스트를 통과시키기 위한 최소한의 코드를 작성합니다. 이 코드는 테스트를 통과시킬 정도로만 구현합니다. 목표는 테스트가 성공적으로 통과되는 것입니다.
- Refactor (리팩토링): 작성한 코드를 개선하고 리팩토링합니다. 중복 코드를 제거하고 읽기 쉽고 유지보수 용이한 코드로 개선하는 작업을 수행합니다. 이 과정에서 테스트를 통과하는지 다시 확인합니다.

 

위의 사이클을 반복하면서 새로운 기능을 추가하거나 기존 기능을 변경할 때마다 테스트를 작성하고 테스트를 통과시키는 코드를 작성하게 됩니다. 이를 통해 개발자는 안정적인 테스트 스위트를 유지하면서 코드의 동작을 확신할 수 있습니다.

TDD의 주요 장점은 다음과 같습니다:

 

- 결함 감소: 테스트가 코드의 예상 동작을 검증하므로 결함을 빠르게 감지하고 수정할 수 있습니다.
- 유연성 및 유지보수 용이성: 테스트 케이스를 작성하고 코드를 작은 단위로 분리하여 모듈화하면 코드의 유연성과 유지보수 용이성이 향상됩니다.
- 문서화와 명세화: 테스트 케이스는 기능 요구사항을 문서화하고 명세화하는 역할을 합니다.
- 디자인 개선: 작은 단위의 테스트 케이스를 작성하면서 코드의 결합도와 응집도를 개선하고, 좀 더 모듈화된 방식으로 설계할 수 있습니다.
- 자신감 향상: 테스트가 성공하면 코드의 동작에 대한 자신감이 생깁니다.

 

TDD는 소프트웨어의 품질과 안정성을 향상시키는 데 도움을 주는 방법론으로, 개발자들에게 널리 사용되고 있습니다.

 

 

 

---

라이브러리와 프레임워크 차이점

 

라이브러리(Library)와 프레임워크(Framework)는 소프트웨어 개발에서 서로 다른 개념을 나타냅니다. 다음은 라이브러리와 프레임워크의 주요 차이점을 설명합니다

 

1. 제어 흐름의 주도성:
- 라이브러리: 라이브러리는 개발자가 코드의 흐름과 제어를 직접 관리합니다. 개발자는 필요에 따라 라이브러리의 함수 또는 기능을 호출하여 사용할 수 있습니다.
- 프레임워크: 프레임워크는 제어의 역전(Inversion of Control) 개념을 적용합니다. 개발자는 프레임워크가 제공하는 특정한 규칙과 구조를 따라야 합니다. 프레임워크는 개발자의 코드를 호출하고 실행하는 동안 제어 흐름을 가지게 됩니다.

 

2. 개발 방식:
- 라이브러리: 라이브러리는 개발자가 필요한 기능을 선택적으로 사용할 수 있습니다. 개발자는 필요한 라이브러리를 프로젝트에 추가하고, 필요한 함수 또는 클래스를 호출하여 사용합니다.
- 프레임워크: 프레임워크는 개발자에게 일정한 구조와 규칙을 강제합니다. 개발자는 프레임워크의 규칙에 따라 코드를 작성해야 하며, 프레임워크가 제공하는 특정한 방식으로 작업을 수행합니다.

 

3. 제어 범위:
- 라이브러리: 라이브러리는 보통 특정한 기능 또는 작업을 수행하기 위한 도구의 집합입니다. 개발자는 필요한 라이브러리를 선택하여 사용하고, 여러 라이브러리를 조합하여 개발할 수 있습니다.
- 프레임워크: 프레임워크는 일반적으로 애플리케이션의 구조와 흐름을 제어하는 데 사용됩니다. 프레임워크는 여러 개의 라이브러리와 도구로 구성되어 있으며, 개발자는 프레임워크의 구조에 맞게 코드를 작성하고 확장해야 합니다.

 

4. 추상화 수준:
- 라이브러리: 라이브러리는 일반적으로 낮은 추상화 수준을 가지고 있습니다. 개발자는 라이브러리의 구체적인 함수나 클래스를 직접 호출하여 사용합니다.
- 프레임워크: 프레임워크는 일반적으로 높은 추상화 수준을 가지고 있습니다. 개발자는 프레임워크가 제공하는 추상화된 개념과 인터페이스를 사용하여 애플리케이션을 개발하고 확장합니다.

 

이러한 차이점으로 인해 라이브러리는 개발자에게 유연성과 선택의 여지를 제공하며, 개발자는 필요한 라이브러리를 선택하여 자유롭게 사용할 수 있습니다. 반면에 프레임워크는 개발자에게 구조와 규칙을 부과하고, 개발자는 프레임워크의 규칙을 따라 코드를 작성해야 합니다. 프레임워크는 개발자가 프레임워크의 정의한 규칙에 따라 개발을 진행하면서 일관성과 재사용성을 보장해줍니다.

 

 

---

List와 Queue 성능 차이

 

코딩 테스트하면서 똑같은 구성인데 하나는 시간 초과가 나고 다른 하나는 통과해서 의문이 들었다. List는 가변 배열로 배열의 크기가 자주 바뀌면 기존 배열을 새로운 크기로 복사하는 작업을 수반하므로 비용이 크게 들 수 있다. 따라서 배열 크기가 자주 바뀌는 작업은 LinkedList로 구현하는 Queue를 사용하자.

 

 

 

 

---

RESTful API와 GraphQL의 차이점은 무엇인가요? 어떤 경우에 어떤 것을 선택하는 것이 좋을까요?

 

RESTful API와 GraphQL은 모두 클라이언트와 서버 간의 데이터 통신을 위한 방법이지만, 다음과 같은 주요 차이점이 있습니다:

1. 데이터 요청 방식:
- RESTful API: 클라이언트는 미리 정의된 엔드포인트에 요청을 보내고, 서버는 해당 엔드포인트에서 정의된 데이터를 반환합니다. 클라이언트는 종종 여러 번의 요청을 통해 여러 엔드포인트로부터 데이터를 수집합니다.
- GraphQL: 클라이언트는 단일 GraphQL 엔드포인트에 쿼리를 보내고, 요청된 데이터 필드 및 관계만을 반환받습니다. 클라이언트가 필요한 데이터 구조를 정확하게 지정할 수 있어 불필요한 데이터를 받지 않을 수 있습니다.

 

2. 오버 패칭 및 언더 패칭:
- RESTful API: 클라이언트가 필요한 데이터보다 더 많은 데이터를 받는 경우를 오버 패칭이라고 하며, 반대로 필요한 데이터를 여러 번 요청해야 하는 경우를 언더 패칭이라고 합니다.
- GraphQL: 클라이언트가 필요한 데이터를 직접 지정하므로 오버 패칭과 언더 패칭의 문제가 크게 발생하지 않습니다.

 

3. 네트워크 요청 수:
- RESTful API: 여러 엔드포인트로부터 데이터를 가져와야 할 때, 여러 번의 네트워크 요청이 필요할 수 있습니다.
- GraphQL: 단일 쿼리 요청으로 모든 필요한 데이터를 한 번에 가져올 수 있습니다.
타입 시스템:

4. RESTful API: 데이터의 구조나 필드 이름 변경 시, 클라이언트나 서버의 변경이 필요합니다.
- GraphQL: 스키마를 사용하여 데이터 모델을 정의하고, 변경 시 스키마를 업데이트함으로써 변경에 대한 유연성을 제공합니다.

 

5. 특정 도메인에 적합한 경우:
- RESTful API: 단순한 데이터 요청이나 CRUD 작업에 적합하며, 이미 정의된 엔드포인트 구조를 활용할 수 있는 경우에 유용합니다.
- GraphQL: 복잡한 데이터 요청이나 다양한 데이터 구조를 요구하는 경우에 적합하며, 클라이언트가 데이터 구조를 더욱 세밀하게 제어하고 싶을 때 유용합니다.

 

어떤 것을 선택해야 하는지는 프로젝트의 요구 사항과 복잡성에 따라 달라집니다. RESTful API는 단순한 요청-응답 패턴을 따라야 하며, 이미 정의된 엔드포인트를 사용하는 것이 효과적일 수 있습니다. GraphQL은 데이터 요청의 유연성과 효율성을 필요로 하는 복잡한 애플리케이션에 적합하며, 클라이언트와 서버 간의 강력한 커뮤니케이션을 위해 사용될 수 있습니다.

 

 

 

 

---

마이크로서비스 아키텍처와 모놀리틱 아키텍처의 장단점은 무엇인가요?

 

마이크로서비스 아키텍처와 모놀리틱 아키텍처는 두 가지 다른 소프트웨어 설계 접근 방식입니다. 각각의 아키텍처는 장단점을 가지고 있으며, 어떤 상황에서 어떤 아키텍처를 선택할지는 프로젝트의 목표와 요구사항에 따라 달라집니다.

모놀리틱 아키텍처:

 

- 장점:
간단한 구조: 초기에는 구성이 간단하며, 개발 및 배포가 단순합니다.
통합이 쉬움: 하나의 코드베이스와 데이터베이스를 가지고 있기 때문에 데이터 흐름이 단순합니다.
개발과 디버깅이 용이: 코드 베이스가 작고 단일한 언어나 기술 스택을 사용하기 때문에 개발과 디버깅이 상대적으로 쉽습니다.

- 단점:
확장 어려움: 모놀리틱 아키텍처에서는 전체 시스템을 함께 확장해야 하기 때문에 특정 기능만 확장하기 어렵습니다.
높은 결합도: 하나의 큰 코드베이스에서 작업하기 때문에 변경 사항이 다른 부분에 영향을 주기 쉽습니다.
배포의 복잡성: 하나의 큰 애플리케이션을 배포하므로 배포가 복잡해질 수 있습니다.

 

 

마이크로서비스 아키텍처:

 

-장점:
모듈화와 독립성: 각 마이크로서비스는 특정 기능을 수행하므로 모듈화가 용이하며 개발과 유지보수가 편리합니다.
확장성: 특정 기능만 필요할 때 해당 마이크로서비스만 확장할 수 있습니다.
다양한 기술 선택: 각 마이크로서비스는 독립적이므로 필요한 기술을 선택하여 사용할 수 있습니다.

 

- 단점:
복잡성: 여러 개의 서비스를 관리하고 연결해야 하므로 운영적인 복잡성이 증가할 수 있습니다.
테스팅과 디버깅이 어려울 수 있음: 분산된 서비스 간의 상호작용을 테스트하고 디버깅하는 것이 어려울 수 있습니다.
팀과 커뮤니케이션의 중요성: 각 마이크로서비스는 독립적으로 운영되므로 팀 간의 커뮤니케이션이 중요합니다.

 

어떤 아키텍처를 선택할지는 프로젝트의 복잡성, 확장성 요구, 개발 팀의 구성 등을 고려하여 결정되어야 합니다. 중요한 것은 프로젝트의 목표와 요구사항에 가장 잘 맞는 아키텍처를 선택하는 것입니다.

 

 

 

 

---

OSI 7계층에 대해 설명해보시오.

네트워크 통신을 할 때 7개의 계층으로 나눠서 각자 다른 기능을 담당합니다. 이렇게 다른 기능을 담당하므로써 서로의 계층에 영향을 끼치지 않고 통신할 수 있습니다.

 

1계층은 물리계층으로 통신 장비나 실제 케이블 기능을 담당합니다.

 

2계층은 데이터 링크 계층으로 주로 같은 네트워크 안에서 이동할 때 MAC 주소를 이용해서 통신합니다.

 

3계층은 네트워크 계층으로 라우터 간에 라우팅 기능을 담당합니다.

 

4계층은 전송 계층으로 TCP, UDP 방식을 결정합니다.

 

5계층은 세션 계층으로 세션을 맺고 끊음을 담당합니다.

 

6계층은 표현 계층으로 암복호화를 담당합니다.

 

7계층은 Application 계층으로 실제 사용자들이 사용하는 프로그램들이 7계층에 속합니다.

 

 

 

 

---

미들웨어란 무엇인가? Web WAS에 대해서 설명해보시오.

미들웨어란 프로그램들 사이에서 서로 통신하고 상호작용하도록 도와주는 프로그램입니다.

 

기존의 웹 서버는 정적인 웹 페이지를 제공하지만, was는 웹 애플리케이션 서버로 사용자에게 동적인 웹 페이지를 제공하는 역할을 합니다.

 

 

 

 

 

 

---

오버로딩과 오버라이딩 차이점

 

오버로딩이란

 

오버로딩은 같은 이름의 함수를 여러 개 정의하는 것을 말합니다. 함수의 이름은 같지만, 매개변수의 개수나 데이터 타입이 다르게 정의됩니다.

 

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public double add(double a, double b) {
        return a + b;
    }
}

 

 

오버라이딩이란

 

오버라이딩은 상위 클래스의 메서드를 하위 클래스에서 재정의하는 것을 말합니다. 오버라이딩은 메서드의 구현을 변경하거나 확장할 수 있는 기회를 제공합니다.

 

class Animal {
    public void makeSound() {
        System.out.println("Animal makes a sound");
    }
}

class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Dog barks");
    }
}

 

 

 

 

---

이벤트 버블링이란?

 

이벤트 버블링은 HTML 문서에서 이벤트가 발생했을 때, 현재 요소에서부터 시작하여 부모 요소로 순차적으로 전파되는 현상을 말합니다.

 

 

 

 

 

---

프로세스와 쓰레드란?

프로세스는 실행 중인 프로그램으로, 운영 체제에서 할당받은 자원(메모리, 파일, I/O 장치 등)을 사용하며 독립적으로 실행됩니다. 각 프로세스는 독립된 메모리 공간을 가지며, 서로 영향을 주지 않습니다. 프로세스는 자신만의 주소 공간을 가지고 있기 때문에 여러 프로세스 간에 데이터 공유가 복잡하고 느립니다.

쓰레드는 프로세스 내에서 실행되는 작은 실행 단위입니다. 프로세스 내에서 공유된 자원을 사용하며, 같은 프로세스 내의 쓰레드들은 메모리 공간을 공유하므로 데이터 공유가 간단하고 빠릅니다. 쓰레드는 독립적으로 실행되지만, 같은 프로세스에 속한 다른 쓰레드와 자원을 공유하므로 주의가 필요합니다.

쓰레드 풀은 여러 쓰레드를 관리하는 자원 풀입니다. 쓰레드 풀을 사용하면 쓰레드의 생성과 소멸을 효율적으로 관리할 수 있습니다. 풀에 있는 쓰레드들은 작업이 생기면 해당 작업을 수행하고, 작업이 완료되면 풀로 돌아가 대기합니다. 이렇게 함으로써 반복적으로 쓰레드를 생성하고 제거하는 오버헤드를 줄일 수 있습니다.

 

 

 

 

---

데드락이 발생하는 상황은?

 

만약 a, b 프로세스가 있고 1, 2 데이터가 있다고 가정할 때 a 프로세스가 1을 선점하고 있고 2를 기다리는 상태이고 b 프로세스가 2를 선점하고 있고 1을 기다리는 상태라면 서로가 서로를 기다리는 상태가 되면서 데드락이 발생하게 됩니다. 따라서 주기적으로 그래프에 사이클이 형성되는지 확인하고 형성되는 경우 각 자원의 우선순위를 부여하여 해결할 수 있습니다.

 

 

 

 

---

그래프를 구현하는 방법은?

 

정방 행렬 또는 연결 리스트로 구현하면 된다.

 

예를 들어서 정방 행렬의 경우에는 간선이 존재하면 해당 노드에 1을 입력하고 없는 경우에는 0을 입력하면 된다. 연결 리스트의 경우에는 A와 연결되어 있는 노드를 A의 연결리스트에 추가하면 된다.