에반, 어른반

Kubernetes 씹어먹기 - 0. 쿠버네티스를 커리어에 끼얹자.

에반황 — Mon, 15 Jan 2024 22:59:00 +0900

01 들어가며

안녕하세요. 에반황이에요. 이전에 블로그를 다시 시작하다. 포스팅에서 다뤘듯 최근에 직무를 변경했는데요. 제일 중요한 직무 중 하나인 쿠버네티스(Kubernetes)를 내 커리어에 적을 수 있을 정도로 공부해보려 해요.

시리즈 이름이 씹어먹기인 이유

02 얻고자 하는 것

쿠버네티스를 씹어 먹고 나선 다음의 목표를 달성하고 해요:

팀 내에서 '쿠버네티스 좀 아는 놈' 포지션 잡기
CKA 자격증 취득하기

이 두 가지를 이루면 올해 목표인 커리어의 성숙을 어느 정도 달성하는 것 아닐까 생각해요.

03 포스팅 계획

새로운 파트장이 본인은 새로운 공부를 할 때, 설명을 할 때 다음의 차례로 진행한다고 했어요.

전체 아키텍처 분석
개별 엔티티 구성요소 분석
엔티티 별로 구성요소 분석
각자의 동작 원리 순서 분석

이 방법이 너무 괜찮아 보여 저도 다음과 같은 목차로 진행하려고 해요.

쿠버네티스 클러스터 전체 아키텍처 알아보기
쿠버네티스 구성 요소 핵심 컨셉 알아보기
각 구성 요소의 개념 정리
각 구성 요소의 동작 원리 정리

"다음 포스팅은 쿠버네티스 클러스터 전체 아키텍처 알아보기로 돌아오겠습니다!"

블로그 다시 시작하다.

에반황 — Sun, 7 Jan 2024 00:40:50 +0900

01 들어가며

안녕하세요! 약 2년 만에 돌아온, 아무도 기다리지 않았던 블로그의 주인장예요. 다시 블로그를 시작하기 앞서 왜 시작했고, 왜 쉬었으며, 어떻게 운영할지에 대한 정리를 해보고자 글을 써요.

반겨주세요. 제발.

02 왜 시작했나

무려 2016년에 시작한 첫 포스팅

블로깅의 첫 시작의 목적은 여느 취준생과 다르지 않았어요. '취업' 때문이었죠. 카카오에 인턴으로 취업하게 되었고 리더로부터 안드로이드에 대한 핵심 개념들을 매일 작성하는 과제를 받아서 '자의' 반 '타의' 반으로 시작하게 되었어요.

블로그를 하며 "나도 블로거야"라며 으쓱하기도 했었죠.

02 성과

악바리로 리더의 과제를 수행하다 보니 리더에게도 인정받았어요. 이에 멈추지 않고 저는 블로깅을 계속했어요. 그 원동력은 바로 성과였죠. 두 꼭지로 구분해 보았는데요. '함께 자라기', '수치로 보이는 성장'예요.

함께 자라기

새로운 지식을 남이 이해할 수 있게 정리한다는 것에 대한 뿌듯함 + 성장하는 즐거움이 느껴졌어요. 제 글을 읽고 성장하는 분들이 생긴 것이었죠. 여태껏 배우기만 해 왔던 내가 누군가의 성장에 도움을 줄 수 있다는 게 굉장한 희열이었어요.

수치로 보이는 성장

물론 수치적으로도 방문자가 꾸준히 늘었어요. 막상 사회를 나와보면 나를 평가할 수 있는 수단이 많지 않다고 느끼는데, 마치 게임 스탯처럼 내가 하는 만큼 는다는 기분을 느낄 수 있는 몇 안 되는 기회였다고 생각해요.

물론 구글애드센스를 통해 외화를 벌어오는 민간 외교관 역할도 정말 색다른 경험이었어요.

돈... 돈으로 사게나!

03 왜 쉬었나

블로그를 제일 열심히 했던 시기는 2017~2019였어요. 이 시기 이후 왜 쉬었는지는 저의 커리어패스와도 연관이 있어요.

2016년 취업 이후, 저는 빨리 월요일이 되어 출근하고 싶던 패기롭던 신입이었죠. 저 때 했던 업무를 간략하게 설명드리자면 웹을 구현하는데 필요한 기술인 HTML5, Javascript 등을 가지고 웹 게임을 만드는 나름 새로운 길을 개척하는 업무였어요. 하지만 몇 개월 업무를 진행하니 기술적인 도전도 없었고 동기를 제외하곤 가르쳐줄 시니어도 없어 동기부여가 되지 않는 상황이었죠.

블로깅이 이때를 버티게 해 주었어요. 기술적 도전이 없다고는 했지만, 블로깅을 하려니 어느 정도의 딥-다이브는 필요했고 그것 역시 도전의 일종이었기 때문이에요.

저만의 노력으로는 효율성이 너무 떨어진다고 생각했기 때문에 시너지를 내기 위해 그 당시 저에겐 기술적 도전이 매우 많았던 백엔드 개발자로 전직을 요청했어요. 그리고 당시 주니어들에게 대중적이었던 기술들을 하기 시작해요. Spring, AWS, MySQL, Redis 등이었죠.

이후 저로썬 기술적 도전을 해결 및 업무에 적용하기에도 바빴으며 그 내용을 적기엔 내 실력이 너무나 부족하다 느꼈어요. 다른 개발자 분들의 실력은 깊게 파놓은 우물처럼 보였죠. 결국 이 때는 내가 바쁘게 업무 하니까 늘겠거니라는 착각과 함께 더딘 성장을 하게 돼버렸네요.

끝이 보이지 않는 깊이.. (실제론 인피니티 미러라는 것 )

내 눈엔 노력은 안보이고 깊게 파인 우물만 보여

04 왜 돌아왔나

커리어 전환

이 또한 커리어패스와 연관이 있는데요. 여러 가지 이유로 카카오에 약 2년 만에 손뼉 치고 이동이라는 사내 이동 시스템이 다시 부활했고 현재 이동하게 된 조직의 공고가 떴어요. 키워드는 AI, Cloud, MLOps 등 내 길이 아니라고 부정해 왔던 굉장히 기술적 도전이 많이 필요해 보였던 용어들이었어요. 그러나 모르는 것이 있어야 업무에 활력이 생기는 저라서 이번에도 도전했죠.

막상 들어가니 웬걸 조직도를 보지도 않고 왔네요. 이동한 조직 구성도는 다음과 같아요.

기술부문 > 클라우드플랫폼실 > 클라우드컴퓨팅팀 > AI클라우드플랫폼파트 > AI에이전트플랫폼셀

역시나 이번에도 조직원들이 파놓은 우물은 너무나 깊어 보였어요. 이러한 고민을 새로운 리더에게 공유하니 다음 얘기를 해주셨어요. "남들이 깊게 파놓은 우물은 한 번에 판 게 아니에요, 절대 그렇게 팔 수 없어요. 깊이가 깊어지려면 옆을 더 파야해요."

머리를 땅 얻어맞는 듯한 깨달음이었어요. "과거 나는 깊게 파기 위해 옆을 야금야금 파서 하나의 포스팅을 완성했었구나". 다시 그 기억을 살려 블로그와 함께 깊은 우물을 만들어나가려 해요.

다시 느끼고 싶은 성과

사회생활을 하니 아는 사람은 많아지지만 나의 사회는 점점 작아지는 것을 느껴요. (물론 제가 의도적으로 선택과 집중을 하는 것도 있지만요.) 위에서 얘기했던 성과를 통해 느꼈던 기쁨에는 '함께 자라기'와 누군가 나의 성과를 '수치적으로 평가'가 있었죠. 현실적으로 오프라인의 좁은 사회에서의 평가는 한계를 느끼지만, 블로그 사회에선 좀 더 넓게 영향을 미치는 사람이 되고 싶어요.

커리어적 성숙

업무를 진행하다 보면 당연히 아는 것이 늘어나지만, 그와 함께 까먹는 것도 너무 많다는 걸 요즘 느끼고 있어요. 이를 위해 올해부턴 처음으로 업무 일지도 작성하기 시작했어요.

앞으로 기록을 통해 나의 지식을 정리하고, 이를 남에게 설명할 수 있을 정도로 만들고자 해요. 이게 가능해야 제가 시니어가 될 수 있다고 생각해요.

05 운영 계획

디자인 변경

아이티 마이닝이라는 블로그명은 IT 지식에 대해 삽질(광부로서)을 하자는 포부였어요. 이제는 좀 더 저를 브랜딩 할 수 있는 에반이 포함된 이름으로 (당장은 에반, 어른반) 바꾸려고 해요.
스킨도 더 이쁘게 바꿔보려고 해요. Velog가 딱 제 취향인데 구글애드센스를 포기할 수가 없군요.

방향성

성과 파트에서 블로그의 즐거움을 느꼈기 때문에 함께 자라기, 수치적으로 보이는 성장 두 가지를 더 발전시키려고 해요. 댓글로 더 소통하고 수치적으로도 어떻게 성장하고 있는지 기록할까 해요.
나의 성장 기록도 남기려고 해요.
개발 스킬만이 아닌 회고, 일기 등 여러 갈래의 이야기를 다뤄볼까 해요.

잘부탁드립니다!

Java Enum 기본

에반황 — Wed, 27 Nov 2019 16:55:02 +0900

데이터 중에는 몇 가지로 한정된 값만을 갖는 경우가 흔히 있다. 예를 들어 계절은 봄, 여름, 가을, 겨울 그리고 요일은 월, 화, 수, 목, 금, 토, 일이라는 한정된 값을 가진다. 이렇게 한정된 값만을 가지는 데이터 타입이 열거 타입(Enumeration type)이다.

열거 타입의 장점

문자열과 비교해 IDE의 지원을 받을 수 있다. (자동완성, 오타 검증, 텍스트 리팩토링)
허용 가능한 값들을 제한
리팩토링 시 변경 범위가 최소화 된다. (내용 추가가 필요해도 Enum 코드 외에 수정할 필요가 없다.)

해당 장점은 모든 언어가 Enum에서 얻을 수 있는 장점이다. 더 나아가 Java Enum의 경우 C/C++과 다르게 Enum이 int 값이 아니라 완전한 기능을 가진 클래스이다. 이를 기반한 장점이 더 있다.

열거 타입 선언

열거 타입 선언을 위해서는 먼저 열거 타입의 이름을 정하고 열거 타입 이름으로 소스 파일(.java)를 생성해야 한다. 관례상 첫 문자를 대문자로 하고 나머지는 소문자로 구성한다. 두 단어 이상으로 구성됬다면 단어의 첫 문자를 대문자로 한다.

Season.java
Week.java

Season.java

소스 파일의 내용은 다음과 같이 열거 타입 선언이 온다. public enum 키워드는 열거 타입을 선언하기 위한 키워드이다.
열거 타입을 선언했다면 이제 열거 상수를 선언하면 된다. 열거 상수는 열거 타입의 값으로 사용되는데, 관례적으로 모두 대문자로 작성한다. 여러 단어일 경우는 LOGIN_SUCCESS, LOGIN_FAILED와 같이_로 연결하는 것이 관례다.

public enum Season {
  SPRING,
  SUMMER,
  AUTUMN,
  WINTER
}

열거 타입 변수

열거 타입 선언 후 사용하는 방법에 대해 알아보자. 열거 타입도 하나의 데이터 타입이므로 변수를 선언하고 사용해야한다.
다음은 열거 타입 변수를 선언하는 방법이다.

열거타입 변수;
Season season;
Season weddingSeason;

열거 타입 변수를 선언했다면 다음과 같이 열거 상수를 저장할 수 있다.

열거타입 변수 = 열거타입.열거상수;
Season weddingSeason = Season.AUTUMN;

열거 타입 변수는 다음과 같이 null을 저장할 수 있는데, 열거 타입도 참조 타입이기 때문이다.

Season season = null;

참조 타입 변수는 객체를 참조하는 변수로 알고 있는데 열거 상수는 객체일까? 그렇다. 열거 상수는 열거 객체로 생성된다. 열거 타입 Season의 경우 SPRING에서 WINTER까지 4개의 Season 객체로 생성된다. 그리고 메소드 영역에 생성된 열거 상수가 해당 Season 객체를 각각 참조하게 된다.

그렇다면 다음 코드를 어떻게 이해하면 좋을까?

Season season = Season.SPRING;

열거 타입 변수 season은 스택 영역에 생성된다. season에 저장되는 값은 Season.SPRING 열거 상수가 참조하는 객체의 번지이다. 따라서 열거 상수 Season.SPRING과 season 변수는 서로 같은 Season 객체를 참조하게 된다.
그렇기 때문에 season 변수와 Season.SPRING 상수의 == 연산 결과는 true가 된다.

season == Season.SPRING // true

열거 객체의 메소드

name()

열거 객체의 문자열 리턴

Season season = Season.SPRING;
String name = season.name(); // "SPRING"

ordinal()

열거 객체가 몇 번째인지를 리턴

public enum Season {
  SPRING, // 0
  SUMMER, // 1
  AUTUMN, // 2
  WINTER  // 3
}

Season season = Season.AUTUMN;
int ordinal = season.ordinal(); // 2

compareTo()

매개값으로 주어진 열거 객체를 기준으로 전 후로 몇 번째 위치하는지 비교

Season season1 = Season.SPRING; // 0
Season season2 = Season.WINTER; // 3
int result1 = season1.compareTo(season2); // -3
int result2 = season2.compareTo(season1); // 3

valueOf()

매개값으로 주어지는 문자열과 동일한 문자열을 가지는 열거 객체를 리턴한다.
외부로부터 문자열을 받아 열거 객체로 변환할 때 유용하다.

Season season = Season.valueOf("SPRING")

values()

열거 타입의 모든 열거 객체들을 배열로 만들어 리턴

Season[] seasons = Season.values();
for(Season season : seasons) {
  System.out.println(season);
}

열거 상수를 다른 값과 연결하기

열거 상수 각각이 열거 객체이므로 열거 객체에 생성자를 사용해서 다음과 같이 열거 상수에 다른 값을 할당할 수 있다.

public enum Type {
    // 상수("연결할 문자")
    WALKING("워킹화"), 
    RUNNING("러닝화"),
    TRACKING("트래킹화"), 
    HIKING("등산화");

    final private String name;

    private Type(Stirng name) { // enum에서 생성자 같은 역할
        this.name = name;
    }
    public String getName() { // 문자를 받아오는 함수
        return name;
    }
}
public class Shoes {
    public static void main(String[] args) {
        for(Type type : Type.values()){
            System.out.println(type.getName());
        }
    }
}

결과

워킹화
러닝화
트래킹화
등산화

클래스의 static final 이용해 열거 타입 선언하기

class Type {
    static final String WALKING = "워킹화";
    static final String RUNNING = "러닝화";
    static final String TRACKING = "트래킹화";
    static final String HIKING = "등산화";
}

public class Shoes {
    public static void main(String[] args) {
        String w = Type.WALKING;
        System.out.println(w);
    }
}

결과

워킹화

참고

[웹사이트] 생활코딩
[웹사이트] 우아한형제들 기술 블로그
[서적] 이것이 자바다

Spring Jackson 프로퍼티 Naming Strategy

에반황 — Tue, 26 Nov 2019 14:52:06 +0900

1. 개요

Jackson은 Java Object를 Json으로 변환하는 가장 유명한 라이브러리입니다. POJO를 JSON으로 바꾸는 동안 프로퍼티명은 키로서 사용됩니다. 하지만 때때로 우리는 프로퍼티명을 다른 방식으로 사용하고 싶을 때가 있죠. Jackson은 이를 위해 여러가지 네이밍 전략을 제공하고 있습니다.
(SnakeCaseStrategy, PascalCaseStrategy, LowerCaseStrategy, KebabCaseStrategy)

EmployeeController.java

spring boot 어플리케이션에 Employee라는 POJO를 응답으로 반환하는 RestController를 만들어봅시다. 응답은 자동으로 Jackson의 기본 네이밍 전략에 의해 JSON 형식으로 날아갈 겁니다.

@RestController
public class EmployeeController {
    @GetMapping("/getEmployee")
    public Employee getEmployees() {
        Employee employee=new Employee();
        employee.setEmployeeId(19);
        employee.setEmployeeName("Harry");
        employee.setEmployeeRole("DEVELOPER");
        return employee;
    }
}

Employee.java

Employee라는 프로퍼티명이 CamelCase인 POJO 객체를 만듭니다.

public class Employee {

    private int employeeId;
    private String employeeName;
    private String employeeRole;

    public int getEmployeeId() { return employeeId; }

    public void setEmployeeId(int employeeId) { this.employeeId = employeeId;}

    public String getEmployeeRole() { return employeeRole; }

    public void setEmployeeRole(String employeeRole) { this.employeeRole = employeeRole; }

    public String getEmployeeName() { return employeeName; }

    public void setEmployeeName(String employeeName) { this.employeeName = employeeName; }
}

2. Spring Jackson 프로퍼티 네이밍 전략

spring boot 어플리케이션은 application.properties 또는 application.yml 내에 있는 spring.jackson.property-naming-strategy 설정하고

spirng boot 어플리케이션이 아니거나 spring MVC 어플리케이션이라면 Jackson2ObjectMapperBuilder 를 빈으로 등록하고 네이밍 전략과 관련 있는 configuration을 정의합니다.

하단에 Jackson이 지원하는 다섯가지 전략이 있습니다 :

LOWER_CAMEL_CASE
LOWER_CASE
SNAKE_CASE
UPPER_CAMEL_CASE
KEBAB_CASE

EmployeeContollerTest.java

이를 테스트하는 간단한 테스트를 만들어 확인해 봅시다. 해당 테스트를 생략하고 하단의 결과만 보셔도 무방합니다.

@RunWith(SpringRunner.class)
@SpringBootTest
@AutoConfigureMockMvc
class EmployeeControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void get_employees() throws Exception {
        mockMvc.perform(get("/getEmployee"))
                .andDo(print())
                .andExpect(status().isOk());
    }
}

1. LowerCamelCase

application.properties

spring.jackson.property-naming-strategy=LOWER_CAMEL_CASE

또는

@Bean
public Jackson2ObjectMapperBuilder jacksonBuilder() {
     Jackson2ObjectMapperBuilder b = new Jackson2ObjectMapperBuilder();
     b.propertyNamingStrategy(PropertyNamingStrategy.LOWER_CAMEL_CASE);
     return b;
}

결과:

{
    "employeeId": 19,
    "employeeName": "Harry",
    "employeeRole": "DEVELOPER"
}

2. LowerCaseStrategy

application.properties

spring.jackson.property-naming-strategy=LOWER_CASE

또는

@Bean
public Jackson2ObjectMapperBuilder jacksonBuilder() {
     Jackson2ObjectMapperBuilder b = new Jackson2ObjectMapperBuilder();
     b.propertyNamingStrategy(PropertyNamingStrategy.LOWER_CASE);
     return b;
}

결과:

  {
    "employeeid": 19,
    "employeename": "Harry",
    "employeerole": "DEVELOPER"
  }

3. SnakeCaseStrategy

application.properties

spring.jackson.property-naming-strategy=SNAKE_CASE

또는

If we do not have application.properties file than create a bean with following configurations.

@Bean
public Jackson2ObjectMapperBuilder jacksonBuilder() {
     Jackson2ObjectMapperBuilder b = new Jackson2ObjectMapperBuilder();
     b.propertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);
     return b;
}

결과:

{
  "employee_id": 19,
  "employee_name": "Harry",
  "employee_role": "DEVELOPER"
}

4. UpperCamelCaseStrategy

application.properties

spring.jackson.property-naming-strategy=UPPER_CAMEL_CASE

또는

@Bean
public Jackson2ObjectMapperBuilder jacksonBuilder() {
     Jackson2ObjectMapperBuilder b = new Jackson2ObjectMapperBuilder();
     b.propertyNamingStrategy(PropertyNamingStrategy.UPPER_CAMEL_CASE);
     return b;
}

결과:

{
  "EmployeeId": 19,
  "EmployeeName": "Harry",
  "EmployeeRole": "DEVELOPER"
}

5. KebabCaseStrategy

application.properties

spring.jackson.property-naming-strategy=KEBAB_CASE

또는

@Bean
public Jackson2ObjectMapperBuilder jacksonBuilder() {
     Jackson2ObjectMapperBuilder b = new Jackson2ObjectMapperBuilder();
     b.propertyNamingStrategy(PropertyNamingStrategy.KEBAB_CASE);
     return b;
}

결과:

{
  "employee-id": 19,
  "employee-name": "Harry",
  "employee-role": "DEVELOPER"
}

3. 결론

이 포스트에서 우리는 자바 오브젝트를 JSON으로 변환하여 응답으로 전달할 때 프로퍼티명을 다양한 네이밍 규칙을 통해 바꾸어 보았습니다. application.properties 또는 Jackson2ObjectMapperBuilder 빈을 통해서 설정하는 방법도 다뤘습니다.

4. 참조

[Spring Boot] Pagination과 Sort

에반황 — Thu, 11 Jul 2019 14:52:13 +0900

1. 개요

Pagination은 큰 데이터를 표현할 때 도움이 됩니다. 또한 어떠한 기준으로 데이터를 정렬하며 페이징해야할 수 있습니다.
이번 튜토리얼은 Spring Data Jpa를 사용하여 페이징하는 방법에 대해 알아보도록 하겠습니다.

2. 초기 셋업

첫 째로, Product 라는 entity를 다음과 같이 만들어봅시다:

@Entity
public class Product {

    @Id
    private long id;
    private String name;
    private double price; 

    // constructors, getters and setters 

}

우리의 도메인 클래스입니다. 각 Product 인스턴스는 유니크 식별자로 id를 사용하고 name과 price를 가지고 있습니다.

3. Repository 생성

우리가 만든 Product 에 접근하기 위해 ProductRepository 를 만들어봅시다.

public interface ProductRepository extends PagingAndSortingRepository<Product, Integer> {

    List<Product> findAllByPrice(double price, Pageable pageable);
}

PagingAndSortingRepository를 확장 함으로써, 페이징과 정렬을위한 findAll(Pageable Pageable)과 findAll (Sort sort) 메소드를 사용할 수 있습니다. 일단 PagingAndSortingRepository를 확장하면 위 코드의 findAllByPrice 처럼 Pageable, Sort 파라미터를 사용할 수 있게 됩니다. 또는, 우리는 PagingAndSortingRepository 를 확장한 JpaRepository 를 대신 사용하여도 됩니다.

4. Pagination

일단 우리의 repository를 PaginAndSortingRepository 를 통해 확장한 후에 다음을 하면 됩니다:

Pageable 인터페이스를 구현한 PageRequest 객체를 만들거나 얻습니다.
PageRequest 객체를 repository 메소드에 우리가 의도한데로 인자로 전달합니다.

PageRequest 객체는 요청된 페이지 숫자와 페이지 사이지를 넘김으로서 만듭니다. (페이지 숫자는 0부터 시작합니다):

Pageable firstPageWithTwoElements = PageRequest.of(0, 2);

Pageable secondPageWithFiveElements = PageRequest.of(1, 5);

Spring MVC에서는 Spring Data Web Support 를 이용해 Pageable 객체를 가져올 수도 있습니다.
PageRequest 객체가 있으면 repository 메소드를 호출하며 전달할 수 있습니다.

Page<Product> allProducts = productRepository.findAll(firstPageWithTwoElements);

List<Product> allTenDollarProducts = 
  productRepository.findAllByPrice(10, secondPageWithFiveElements);

findAll(Pageable pageable) 메소드는 기본적으로 Page 객체를 리턴합니다.
그러나, 우리는 또한 커스텀 메소드를 통해 페이지네이션된 데이터를 Page , Slice 또는 List 의 타입으로 받을 수 있습니다.

Page 인스턴스는 Product 의 목록 뿐 아니라 페이징할 수 있는 전체 목록의 숫자도 알고 있습니다. 이를 실행하기 위해 추가적으로 쿼리 작업이 들어갑니다. 이러한 작업에 대한 비용을 방지하기 위해, 우리는 대신 Slice나 List로 반환 받을 수 있습니다. Slice 는 단지 다음 slice가 가능한지 아닌지만 알고 있습니다.

5. Pagination과 Sorting

유사하게, 우리의 쿼리 결과를 정렬하기 위해선 Sort 객체를 메소드에 전달하면 됩니다.

Page<Product> allProductsSortedByName = productRepository.findAll(Sort.by("name"));

만약, 정렬과 페이지네이션을 둘다 하고 싶다면 어떻게해야할까요?

정렬에 대한 디테일 정보를 PageRequest 객체에 전달하면 됩니다.

Pageable sortedByName = 
  PageRequest.of(0, 3, Sort.by("name"));

Pageable sortedByPriceDesc = 
  PageRequest.of(0, 3, Sort.by("price").descending());

Pageable sortedByPriceDescNameAsc = 
  PageRequest.of(0, 5, Sort.by("price").descending().and(Sort.by("name")));

6. 결론

이번 튜토리얼에선, 어떻게 Spring Data JPA를 통해 쿼리된 데이터를 페이지네이트하고 정렬하는지 알아봤습니다.
이에 대한 튜토리얼은 Github 에서 찾아볼 수 있습니다.

[Django] 장고 웹서비스의-이해

에반황 — Mon, 17 Jun 2019 10:24:44 +0900

django 프로젝트 구성

장고를 이용해 웹서비스를 구성할 때 보통 다음과 같은 구조를 가진다고 합니다. 기본적으로 WSGI Web Application Server 하단 부분을 구현하게 되는데, 상단의 웹 서버와 웹 애플리케이션 서버에 대한 궁금증으로 조사해본 결과를 공유합니다.

Web Server가 뭔데?

웹서버는 다른 말로 HTTP Server라고도 부른다. 웹브라우저의 카운터 파트너로서 서버 쪽에서 정보를 제공하는 소프트웨어를 의미한다. 클라이언트로부터의 HTTP요청을 받아 정적인 페이지/파일을 돌려준다. (동적인 부분은 WSGI가 담당. 아래에서 다룹니다.) 가벼움과 높은 성능을 목표로 한다. 웹 서버, 리버스 프록시 및 메일 프록시 기능을 가진다. 대표적인 웹서버는 Apache, Nginx가 있다.

Nginx가 뭐지?

NGINX는 차세대 웹서버로 불린다. 위의 그래프를 통해서 알 수 있듯이 Apache의 독주에 제동을 걸고 있다. NGINX의 특징은 한마디로 정의하면 아래와 같다.

더 적은 자원으로 더 빠르게 데이터를 서비스 할 수 있다.

NGINX와 Apache의 관계

Apache는 웹의 산증인이라고 해도 과언이 아니다. 위의 그래프에 따르면 1996년 이래로 한번도 1등의 자리를 놓친적이 없다. 오픈소스이고, 무료로 사용할 수 있는 소프트웨어인 아파치가 웹을 지탱하고 있다고해도 과언이 아니다. 하지만, 아파치는 오래전에 만들어진 소프트웨어다. 아파치가 만들어진 시대의 요구사항이 이제는 유효하지 않은 것도 있고, 새로운 요구사항과 충돌하는 것도 있을 것이다. 그렇다고 과거의 유산을 청산하고 마냥 새로운 시대의 요구사항만 쫒아갈수는 없는 것이다.

NGINX는 새로운 시대의 요청에 부응해서 만들어진 웹서버이다. 개발의 모든 목적이 높은 성능에 맞춰져 있다. 그리고 잘 사용하지 않는 기능은 과감하게 제외했다. 덕분에 폭발적인 증가세에 있는 인터넷 서비스를 지탱하는데 적합하다.

Django는 웹 서버야?

장고는 장고만의 웹서버를 사용한다. 개발 목적으로 python으로 짜여진 가벼운 wsgi(web server gateway interface)를 사용한다. 그렇다. 장고도 웹서버인 것이다. (정확하게 얘기하자면, 장고 자체는 웹 프레임워크이고 runserver를 통해 웹 서버와 웹 애플리케이션 서버 역할을 하는 것.) 하지만 프로덕션 과정에서는 사용하지 않는 것을 추천한다.

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (We’re in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.) 이 서버를 프로덕션 세팅에서 사용하지마라. 이것은 보안 검수나 퍼포먼스 테스트를 통과하지 않았다. (우리는 웹 서버를 만드려는게 아니고 웹 프레임워크를 만들었고, 그렇기 때문에 프로덕션 환경에서 서버를 향상시키고 싶다면 장고 외의 서버를 사용하라. )

WAS(Web Application Server)는 뭔데?

간단하게 말해 웹 서버 위에 서버 어플리케이션을 얹은 것. 동적 리소스 처리를 위해 사용. (정적 처리도 가능하긴 함) 웹 서버(Nginx)와 웹 애플리케이션(Django)간의 연결을 중계 (Nginx에서 받은 요청을 Django에서 처리하기 위한 중계인 역할을 해준다.) Nginx는 Python을 모르기 때문에 uWSGI는 HTTP 요청을 python으로, Django로 부터 받은 응답을 Nginx가 알 수 있도록 변환해준다.

WSGI 서버는 뭔데?

웹서버와 파이썬을 사용한 웹 어플리케이션 개발환경 간의 인터페이스에 대한 표준 규칙. 파이썬의 웹 어플리케이션 서버! 파이썬으로 선택할 수 있는 웹 프레임워크에서 사용할 수 있는 기존 웹서버는 CGI, FastCGI, mod_python, 또는 커스텀으로 만들어진 API 등으로 상당히 제한되어 있었다. 또 반대로 웹서버를 선택하는 것이 파이썬 웹개발환경을 제한하기도 하였다. 이를 위해 표준으로 나온 것이 WSGI이다.

WSGI는 웹서버와 웹 어플리케이션(또는 프레임워크) 간에 호환성있는 웹 어플리케이션 개발환경을 만들기 위해 로우-레벨 인터페이스로 만들어졌다.

WSGI는 보통 서버 사이드와 게이트웨이 사이드(Nginx, Apache 등)를 가진다. 그리고 어플리케이션 또는 프레임워크 사이드와 통신한다. WSGI 요청을 처리하기 위해서 서버사이드는 어플리케이션을 실행하고 환경정보를 제공하며, 콜백 함수를 어플리케이션 사이드에 전달한다. 그러면 어플리케이션은 요청을 실행하고 전달받은 콜백 함수를 통하여 응답을 서버사이드에 넘겨준다.

서버와 어플리케이션 사이에서, 양방향의 API를 실행할 수 있는 WSGI 미들웨어 (이하 미들웨어, middleware)가 사용되기도 한다. 서버는 클라이언트의 요청을 받아 미들웨어에 넘겨준다. 미들웨어가 요청을 처리한 후에는 요청을 어플리케이션에 보낸다. 어플리케이션에서 나온 응답은 다시 미들웨어를 통해 서버와 궁극적으로 클라이언트 측에 전달된다. WSGI 친화적인 어플리케이션에서는 이러한 미들웨어 여러 개가 스택을 이루어 사용될 수 있다.

Web Server와 Web Application Server

그렇다면 WAS만 쓰면 되지 어째서 웹서버를 따로 쓰느냐는 의문이 생길 수 있다. 그 이유는 목적이 다르기 때문이다. 웹 서버는 정적인 데이터만 처리하는 서버이다. 이미지나 단순 html파일과 같은 리소스를 제공하는 서버는 웹 서버를 통하면 WAS를 이용하는 것보다 빠르고 안정적이다. WAS는 동적인 데이터를 처리하는 서버이다. DB와 연결되어 데이터를 주고 받거나 프로그램으로 데이터 조작이 필요한 경우에는 WAS를 활용 해야 한다. 실무에서는 둘 다를 연동해서 사용한다. 정적 처리는 웹서버에서, 동적 처리는 WAS에서 처리한다.

참고

python 웹 서비스 개요

WSGI란 무엇인가?

WSGI, WAS, CGI 이해

[c#] async / await 사용 예시

에반황 — Wed, 27 Mar 2019 12:53:28 +0900

C# async await

예제

// 3가지 주의해야할 Signiture가 있음:
//  - 메소드는 async 수식어가 있어야한다.  
//  - return type은 Task나 Task<T>여야 한다.
//    여기서는, integer를 반환하기 때문에 Task<int>를 반환한다.
//  - 메소드의 이름은 Async로 끝나야한다.
async Task<int> AccessTheWebAsync()  
{   
    using (HttpClient client = new HttpClient())  
    {  
        // GetStringAsync는 Task<string>을 리턴. 
        // 기다리면 문자열을 얻는다는 뜻이다. (urlContents).
        Task<string> getStringTask = client.GetStringAsync("https://docs.microsoft.com");  
  
        // GetStringAsync로부터 얻는 string 값과 관계 없는 작업을 여기서 진행한다. 
        DoIndependentWork();  
  
        // await 연산자는 AccessTheWebAsync를 지연시킵니다. 
        //  - getStringTask가 완료되기 전에 AccessTheWebAsync를 진행할 수 없습니다.
        //  - 그동안 제어권은 호출자인 AccessTheWebAsync로 넘어갑니다.
        //  - getStringTask가 완료되면 제어가 다시 시작됩니다.
        //  - await 연산자는 getStringTask로부터 문자열 결과를 가져옵니다.
        string urlContents = await getStringTask;  
  
        // return 구문은 integer 결과를 명시합니다.
        // AccessTheWebAsync를 기다리는 모든 메서드는 length 값을 가져옵니다.
        return urlContents.Length;  
    }  
}

async / await의 개념은 위의 예제를 통해 이해할 수 있습니다. Async한 작업을 하는 메서드 내에서는 다음과 같은 일을 하게 됩니다.

Async 메서드 호출
Async 작업과 관련 없는 작업 진행
완료를 기다림

만약 2번의 과정이 필요 없다면 다음과 같이 코드를 단순화 할 수 있습니다.

string urlContents = await client.GetStringAsync("https://docs.microsoft.com");

메서드는 일반적으로 비동기 작업이 완료될 때까지 메서드가 계속될 수 없는 지점을 표시하는 하나 이상의 대기 표현을 포함하고 있습니다. 한편, 메서드가 일시 중단되고 컨트롤이 메서드의 호출자로 반환됩니다. 이 항목의 다음 단원은 일시 중단 지점에서 발생하는 상황을 보여줍니다.

비동기 메서드에서 수행되는 작업

비동기 프로그래밍을 이해하는 데 있어 가장 중요한 점은 메서드에서 메서드로 제어 흐름을 이동하는 방법입니다. 다음 다이어그램이 과정을 안내합니다.

다이어그램의 번호는 다음의 순서로 진행됩니다.

이벤트 처리기가 호출되어 AccessTheWebAsync 비동기 메서드를 기다립니다.
AccessTheWebAsync는 HttpClient 인스턴스를 만들고 GetStringAsync 비동기 메서드를 호출하여 웹 사이트의 내용을 문자열로 다운로드합니다.
GetStringAsync에서 특정 작업이 발생하여 진행이 일시 중단됩니다. 웹 사이트에서 다운로드 또는 다른 차단 작업을 수행할 때까지 기다려야 할 수 있습니다. 리소스를 차단하지 않기 위해 GetStringAsync는 해당 호출자인 AccessTheWebAsync에 제어 권한을 양도합니다.

GetStringAsync는 TResult가 문자열인 Task를 반환하고 AccessTheWebAsync는 getStringTask 변수에 작업을 할당합니다. 이 작업은 작업이 완료될 때 실제 문자열 값을 생성하기 위한 코드와 함께 GetStringAsync를 호출하는 지속적인 프로세스를 나타냅니다.
getStringTask가 아직 대기되지 않았으므로 AccessTheWebAsync가 GetStringAsync의 최종 결과에 무관한 다른 작업을 계속할 수 있습니다. 이 작업은 동기 메서드 DoIndependentWork를 호출하여 나타냅니다.
DoIndependentWork는 작업을 수행하고 호출자에게 반환하는 동기 메서드입니다.
AccessTheWebAsync에 getStringTask 결과 없이 수행할 수 있는 작업이 없습니다. 다음으로 AccessTheWebAsync는 다운로드한 문자열의 길이를 계산하여 반환하려 하지만, 메서드가 문자열을 확인할 때까지 해당 값을 계산할 수 없습니다.

따라서 AccessTheWebAsync는 await 연산자를 사용해서 해당 프로세스를 일시 중단하고 AccessTheWebAsync를 호출한 메서드에 제어 권한을 양도합니다. AccessTheWebAsync는 Task<int>를 호출자에게 반환합니다. 작업은 다운로드한 문자열의 길이인 정수 결과를 만든다는 약속을 나타냅니다.

참고

GetStringAsync가 대기하기 전에 getStringTask(및 AccessTheWebAsync)가 완료되면 AccessTheWebAsync에 컨트롤이 유지됩니다. 일시 중단 및 AccessTheWebAsync의 반환 비용은 호출된 비동기 프로세스(getStringTask)가 이미 완료되었고 AccessTheWebSync가 최종 결과를 기다릴 필요가 없다면 낭비됩니다.

호출자(이 예제의 이벤트 처리기) 내에서 처리 패턴이 계속됩니다. 호출자가 해당 결과를 기다리거나 즉시 기다리기 전에 AccessTheWebAsync에서 결과에 의존하지 않는 다른 작업을 수행할 수 있습니다.AccessTheWebAsync에 대한 이벤트가 대기 중이며 AccessTheWebAsync가 GetStringAsync를 대기 중입니다.
GetStringAsync가 완료되고 문자열 결과를 생성합니다. GetStringAsync를 호출할 경우 문자열 결과가 예상대로 반환되지 않습니다. (메서드가 이미 3단계에서 작업을 반환했습니다.) 대신 문자열 결과가 메서드 getStringTask의 완료를 나타내는 작업에 저장됩니다. await 연산자가 getStringTask에서 결과를 검색합니다. 할당 문은 검색된 결과를 urlContents에 할당합니다.
AccessTheWebAsync에 문자열 결과가 있는 경우 메서드가 문자열 길이를 계산할 수 있습니다. 그런 다음 AccessTheWebAsync 작업도 완료되고 대기 이벤트 처리기를 다시 시작할 수 있습니다. 이 항목 뒷부분의 전체 예에서는 이벤트 처리기가 길이 결과 값을 검색하고 출력하는지 확인할 수 있습니다. 비동기 프로그래밍을 처음 접하는 사용자인 경우 동기 동작과 비동기 동작의 차이점을 살펴보세요. 동기 메서드는 작업이 완료될 때 반환되지만(5단계) 비동기 메서드는 작업이 일시 중단될 때 반환됩니다. 비동기 메서드가 해당 작업을 완료하면 작업이 완료된 것으로 표시되고 결과가 있을 경우 작업에 저장됩니다.

스레드

비동기 메서드는 비차단 작업입니다. 비동기 메서드의 await 식은 대기한 작업이 실행되는 동안 현재 스레드를 차단하지 않습니다. 대신에 이 식은 메서드의 나머지를 연속으로 등록하고 제어 기능을 비동기 메서드 호출자에게 반환합니다.

async 및 await 키워드로 인해 추가 스레드가 생성되지 않습니다. 비동기 메서드는 자체 스레드에서 실행되지 않으므로 다중 스레드가 필요하지 않습니다. 메서드는 현재 동기화 컨텍스트에서 실행되고 메서드가 활성화된 경우에만 스레드에서 시간을 사용합니다. Task.Run을 사용하여 CPU 바인딩 작업을 백그라운드 스레드로 이동할 수 있지만 백그라운드 스레드는 프로세스를 지원하지 않고 결과를 사용할 수 있을 때까지 기다립니다.

비동기 프로그래밍에 대한 비동기 기반 접근 방법은 거의 모든 경우에 기존 방법보다 선호됩니다. 특히, 이 접근 방식은 코드가 더 간단하고 경합 조건을 방지할 필요가 없기 때문에 I/O 바인딩 작업의 BackgroundWorker 클래스보다 효과적입니다. 비동기 프로그래밍은 코드 실행에 대한 조합 세부 정보를 Task.Run가 스레드 풀로 변환하는 작업과 구분하기 때문에 Task.Run 메서드를 함께 사용하는 비동기 프로그래밍은 CPU 바인딩 작업을 위한 BackgroundWorker보다 효과가 뛰어납니다.

전체 예제

다음 코드는 이 항목에서 설명하는 WPF(Windows Presentation Foundation) 애플리케이션의 MainWindow.xaml.cs 파일입니다. 비동기 샘플: "Async 및 Await를 사용하는 비동기 프로그래밍"의 예제에서 샘플을 다운로드할 수 있습니다.

C#복사

using System;  
using System.Collections.Generic;  
using System.Linq;  
using System.Text;  
using System.Threading.Tasks;  
using System.Windows;  
using System.Windows.Controls;  
using System.Windows.Data;  
using System.Windows.Documents;  
using System.Windows.Input;  
using System.Windows.Media;  
using System.Windows.Media.Imaging;  
using System.Windows.Navigation;  
using System.Windows.Shapes;  
  
// Add a using directive and a reference for System.Net.Http;  
using System.Net.Http;  
  
namespace AsyncFirstExample  
{  
    public partial class MainWindow : Window  
    {  
        // Mark the event handler with async so you can use await in it.  
        private async void StartButton_Click(object sender, RoutedEventArgs e)  
        {  
            // Call and await separately.  
            //Task<int> getLengthTask = AccessTheWebAsync();  
            //// You can do independent work here.  
            //int contentLength = await getLengthTask;  
  
            int contentLength = await AccessTheWebAsync();  
  
            resultsTextBox.Text +=
                $"\r\nLength of the downloaded string: {contentLength}.\r\n";
        }  
  
        // Three things to note in the signature:  
        //  - The method has an async modifier.   
        //  - The return type is Task or Task<T>. (See "Return Types" section.)  
        //    Here, it is Task<int> because the return statement returns an integer.  
        //  - The method name ends in "Async."  
        async Task<int> AccessTheWebAsync()  
        {   
            // You need to add a reference to System.Net.Http to declare client.  
            using (HttpClient client = new HttpClient())  
            {  
                    // GetStringAsync returns a Task<string>. That means that when you await the  
                    // task you'll get a string (urlContents).  
                    Task<string> getStringTask = client.GetStringAsync("https://docs.microsoft.com");  
  
                    // You can do work here that doesn't rely on the string from GetStringAsync.  
                    DoIndependentWork();  
  
                    // The await operator suspends AccessTheWebAsync.  
                    //  - AccessTheWebAsync can't continue until getStringTask is complete.  
                    //  - Meanwhile, control returns to the caller of AccessTheWebAsync.  
                    //  - Control resumes here when getStringTask is complete.   
                    //  - The await operator then retrieves the string result from getStringTask.  
                    string urlContents = await getStringTask;  
  
                    // The return statement specifies an integer result.  
                    // Any methods that are awaiting AccessTheWebAsync retrieve the length value.  
                    return urlContents.Length;  
            }  
        }  
  
        void DoIndependentWork()  
        {  
            resultsTextBox.Text += "Working . . . . . . .\r\n";  
        }  
    }  
}  
  
// Sample Output:  
  
// Working . . . . . . .  
  
// Length of the downloaded string: 25035.

[C#] CS0120: non-static field 에러

에반황 — Tue, 19 Mar 2019 11:43:29 +0900

Error 메시지

error CS0120: An object reference is required for the non-static field, method, or property

발생 상황

class Program
{
    void TestMethod() 
    {    
        // Process
    }

    static void Main(string[] args)
    {
        TestMethod();
    }
}

TestMethod()를 진행하려고 하는데, 위와 같은 에러 메시지가 떴다.

해결 방법1

class Program
{
    static void TestMethod() 
    {    
        // Process
    }

    static void Main(string[] args)
    {
        TestMethod();
    }
}

말 그대로 non-static field인 메서드를 실행하려고 했기 때문에 났던 에러이다. static을 사용하면 인스턴스를 생성하지 않아도 사용할 수 있는 정적메서드가 된다. 메서드에 static을 붙여주면 해결 완료.

해결 방법2

class Program
{
    void TestMethod() 
    {    
        // Process
    }

    static void Main(string[] args)
    {
        Program p = new Program();
        p.TestMethod();
    }
}

static한 메서드로 사용하고 싶지 않다면, 해당 객체를 생성한 후 접근하면 해결 완료.

[C#] TCP/IP 프로토콜과 소켓 프로그래밍

에반황 — Mon, 18 Mar 2019 14:02:55 +0900

경고!!
제가 아는 부분에 대해서 공유드리는 목적의 발표입니다. 이 부분에 대해 빠삭하지 않기 때문에 질문에 대한 답을 당장은 드릴 수 없을 수 있지만, 추후에 공부를 통해서 답을 드리겠습니다.

네트워크 프로그래밍

저희가 목표로 하는 통신 기능이 있는 C# 코드를 구현하기 전에 네트워크 프로그래밍이 무엇인지 감을 잡도록 하겠습니다.

인터넷의 유래

최초의 컴퓨터는 프로그램을 입력받고 실행한 뒤 결과를 출력하는 정도가 전부였습니다. 이 시기의 컴퓨터는 다음 그림처럼 중앙 컴퓨터에 더미 터미널 여러개를 연결했다고 합니다.

더미 터미널은 연산 능력은 없고, 입력(키보드)와 출력(모니터)만 할 수 있었습니다. 이 터미널은 지능은 없었지만 중앙 컴퓨터와 데이터를 주고 받는 기능을 가지고 있었습니다.

냉전이 한창이던 1957년 소련은 위성을 하늘에 쏘았고, 이는 미국을 자극했습니다. 자국보다 앞선 우주 기술을 가지고 있다는 것에 충격을 받았고, 각 분야는 빠르게 발전했습니다.

그 중 하나인 DARPA라는 기관은 군대를 위한 신기술을 개발하기 시작했습니다. 냉전 시대에 설립된 이 기관은 막대한 예산을 지원받으며 미군을 위한 연구를 진행했죠. DARPA의 본부는 알링톤에 있었고, 프로젝트는 상당수가 대학이나 외부 연구소에서 진행되었습니다. 각 연구기관의 축적된 연구 자료를 본부에 전달할 수 있는 유일한 방법은 택배였습니다. 믿을만한 요원에게 연구자료를 맡겨야했죠.

DARPA는 이를 해결하기 위해 네트워크와 네트워크를 연결하는 방법을 마련하기 위해 연구를 진행했습니다. 네트워크와 네트워크가 연결되면 한쪽 네트워크에 접속한 사용자는 다른 네트워크에 있는 컴퓨터에 접근할 수 있게 됩니다. 또 네트워크를 통해 다른 네트워크로 접속할 수 있게 됩니다. 이 방식을 이용해 DARPA는 연구기관을 잇는 회선을 일일히 구축하지 않고 연구소들의 컴퓨터를 연결했습니다. 이른바 DARPANET이라 불리던 이 네트워크는 점점 더 많은 연구기관으로 연결되고 세계로 연결되더니 1980년대 말에 이르러서는 인터넷이라는 국제 통신망을 형성하게 되었습니다.

TCP/IP 스택

컴퓨터끼리 네트워크에서 데이터를 주고 받기 위해 그 네트워크에서 사용하는 규칙인 프로토콜을 따라야합니다. 컴퓨터들이 네트워크를 통해 데이터를 주고 받기 위한 통신 규약을 의미합니다. 인터넷은 전 세계 네트워크 표준으로 자리 잡았고, 인터넷의 통신 프로토콜로 사용되는 TCP/IP는 실질적으로 인터넷 표준 프로토콜로 자리잡았습니다.

위의 그림은 TCP/IP의 규칙의 종류를 보여주고 있습니다. 이처럼 TCP/IP 프로토콜은 굉장히 많은 규칙의 집합입니다. 이 네트워크는 물리적인 통신선으로 어떤 재질로 만들어야 하는가에 대한 규칙. 1:1, 1:N 그리고 N:N 네트워크에서 대화 상대를 어떻게 판단하는가에 대한 규칙. 데이터 송수신할 때의 바이트 오더에 대한 규칙 등등이 그 예입니다. TCP/IP는 표준 프로토콜로, 인터넷에서 데이터를 주고 받는데 필요한 일련의 프로토콜 모음입니다. TCP/IP는 다음과 같이 4개의 계층으로 구성되어있으며, 계층이 포개져있는 형태때문에 TCP/IP 스택이라고 부릅니다.

계층을 분리할 때 여러가지 방식이 있는데 대표적으로 OSI 7계층(open system interconnection)이나, RFC 1122 4계층으로 나누는 방식이 있습니다. TCP/IP 프로토콜은 4계층으로 나누고 있습니다. 웹 브라우저, 메신저, 팟캐스트 등 어플리케이션의 데이터들은 모두 이 4계층을 오르내리고 있습니다.

왜 이렇게 계층으로 나누었을까요?

DARPANET에 기반한 인터넷은 점점 커졌고, 각 기능에 대한 요구사항을 해결하기 위해 전체 프로그램을 수정하였습니다. 이러한 비용을 줄이기 위해 프로그램을 계층으로 나누었습니다. 각각의 요구사항 해결할 때 다른 계층에 영향 미치지 않도록 각 계층은 인터페이스를 정의하게 됩니다. 계층의 내부는 인터페이스에 맞춰 요구사항을 해결하고, 각 계층의 통신은 인터페이스를 통해 이뤄지도록 구현하였습니다.

애플리케이션 계층

어떤 매체로 피자를 주문할지(프로토콜 지정 - 여기선 핸드폰 주문)와 어떤 언어로 주문(암호화, 복호화)할지 통화를 연결(세션 생성)하는 것까지를 포함해서 어플리케이션 계층에서 진행.

이 계층은 응용 프로그램 즉 개발자가 작성한 어플리케이션에 프로토콜들을 제공하는 계층입니다. 크롬이나, 파이어폭스, 이메일들의 응용 프로그램이 이 계층에 속하는 것이 아닌 어플리케이션이 사용하는 프로토콜들이 모여있는 계층입니다. 원격 로그인을 위한 TELNET, 파일 전송을 위한 FTP, 메일 전송을 위한 SMTP 그리고 웹 데이터를 주고 받기 위한 HTTP 등이 존재합니다. 각각의 프로토콜들은 하부 계층의 TCP나 UDP에 기반하여 동작합니다.

트랜스포트 계층

프로토콜에 따라 의심쩍은 피자를 검사하여 괜찮은 피자만 배달거나 피클이 빠졌을 때 다시 배달을 하는 것과 같은 신뢰성 작업을 합니다.

이름 그대로 패킷의 운송을 담당합니다. 그 중에서도 TCP(Transmission Control Protocol)은 보내는 쪽과 받는 쪽 간의 연결성을 제공하여, 신뢰할 수 있는 패킷 전송 서비스를 제공합니다(이를 Stream 방식으로 부르기도 합니다). 여러 개의 패킷을 보낼 때 순서를 보장하며, 패킷이 손실되거나 유실되면 그 부분을 재전송해주기도 합니다. TCP/IP에서 TCP가 바로 이 프로토콜을 가리키는 것이며, TCP는 IP가 제공하지 않는 연결성, 신뢰성을 제공합니다. HTTP를 비롯한 여러 프로토콜이 이 TCP와 IP 프로토콜 위에서 동작합니다.

이러한 TCP 프로토콜에 정의되어 있는 규칙을 조금 더 파보자면 다음의 4가지로 나눌 수 있습니다.

세션 관리(연결성)
- TCP는 세션 관리를 통해 각 연결의 흐름을 제어하도록 정의되어 있습니다. 여기서 말하는 세션이란 서버가 해당 클라이언트와 데이터 통신을 하기 위해 제공하는 전용 통로라고 생각 하시면 됩니다.
  일반적으로 클라이언트가 서버에 접속하기 위해서는 TCP 연결을 요청하게 되며, 서버쪽에서는 연결을 요청한 클라이언트를 위한 세션이 생성됩니다. 이 세션은 해당 클라이언트만 사용할 수 있는 유일한 통로가 됩니다. 이미 연결 되어 있는 클라이언트 외에 다른 클라이언트가 연결을 요청하면 해당 클라이언트를 위한 새로운 세션을 생성하게 됩니다. 생성되어 있는 세션은 해당 클라이언트와 통신하기 위해서 사용하며 다른 클라이언트가 사용하는 세션은 사용 할 수 없습니다. 이렇게 각각의 클라이언트에 따라 구분되어 있는 연결 관리는 서로 다른 클라이언트에서 전송한 패킷이 충돌되는 것을 방지함으로써 인터넷에서 데이터의 전송을 안전하게 보장 해 줍니다.
핸드 셰이크(신뢰성)
- TCP는 핸드셰이크(HandShake)라 불리는 기법을 이용하여 인터넷에서 데이터가 유실되는 것을 방지하도록 정의되어 있습니다. 이는 TCP에서 데이터 전송 후 해당 데이터를 잘 받았다는 메시지를 받고, 알았다는 메시지를 보내 정의 되어 있는 것이 마치 악수하면서 인사하는 것과 비슷하다고 해서 유래된 이름입니다.
  핸드셰이크는 일정한 시간이 흐른 후에도 데이터를 잘 받았다는 메시지가 도착하지 않으면 데이터가 유실되었다고 판단하여 데이터를 재전송 하게 됩니다. 이렇게 꼼꼼하게 데이터의 확인 과정을 거치면서 네트워크 상황이 좋지 않아서 중간에 데이터가 유실되는 상황이 벌어지더라도 데이터의 신뢰성을 확보 할 수 있습니다.
  네트워크 상에서 패킷을 전송할 때 패킷의 유실 위험을 막기 위해 데이터를 전송하고 응답 패킷(ACK)이 올 때까지 기다렸다가 또 다음 패킷을 보내고 응답 패킷(ACK)을 받는 방법입니다. TCP는 이런 방법을 통해서 데이터의 유실을 막고 신뢰성 있는 데이터 전송을 보장해 줍니다.

패킷 순서 조합
- 핸드셰이크 같이 데이터를 하나씩 전송하고 확인하는 과정을 거치면 데이터의 신뢰성을 보장할 수 있는 장점이 생기지만 데이터 전송 속도가 떨어지는 문제점이 발생할 수 있습니다. 아무리 데이터의 신뢰성이 보장되더라도 데이터 전송 속도가 너무 떨어지면 사용하기에 불편한 프로토콜이 될 것입니다.
  이렇게 전송 속도가 떨어지는 문제점을 보완하기 위해 나온 것이 패킷의 순서 조합입니다. 이는 데이터에 번호를 부여한 다음에 메시지의 전송 속도가 떨어지는 것을 막기 위해 여러 개의 데이터를 한 번에 보내는 방법입니다. 데이터를 받은 곳에서는 데이터의 순서에 맞추어 데이터를 정렬하고 데이터를 잘 받았다는 메시지를 전송해줍니다.

포트를 이용한 서비스 다중화
- 네트워크를 통한 장치에서 인터넷을 사용하기 위해 설정하는 것은 IP 주소 밖에 없습니다. 그렇다면 단 하나의 IP 주소를 통하여 여러 가지 프로그램은 어떻게 동작할 수 있을까요? 그 정답은 TCP 프로토콜에 있는 포트라는 개념입니다.
  TCP에서 IP는 주소 외에도 포트라는 개념이 있어 우리가 사용하는 애플리케이션 포트를 하나씩 할당해 줍니다. 각각의 애플리케이션은 자신에게 할당 된 포트를 이용하여 통신할 데이터를 주고 받게 됩니다.
  
  포트가 필요한 이유?
  유스페이스 A동(IP주소)에 호수(포트번호)라고 이해하면 편합니다. 유스페이스 A동에 만약 피자집만 존재한다면 유스페이스 A동을 통해서 주문을 해도 될 겁니다. 하지만 치킨 집, 곱창 집이 들어오게 되면 각 호수에 대한 주소가 따로 필요하겠죠. 이를 위해 존재하는 것이 포트번호입니다.

하지만 TCP 프로토콜에는 장점만 있는 것이 아닙니다. 데이터가 작을 경우 하나의 데이터만 보내도 되며 이 경우 순서 보장에 대한 이슈는 사라지게 됩니다. 또한 꼭 받아야하는 데이터가 아닌 경우 재전송이 필요없겠죠. 작고, 신뢰성을 요구하지 않는 데이터는 필요 없는 기능이 붙어 전송이 더뎌지게 됩니다.

트랜스포트 계층은 이런 문제를 해결하기 위해 또 다른 프로토콜인 UDP(User Datagram Protocol)을 제공합니다. 이는 연결성, 순서, 신뢰성 모두 제공하지 않지만 성능이 더 우수합니다(이를 데이터그램 방식이라고 부르기도 합니다).

네트워크(인터넷) 계층

네비게이션을 키고 가장 빠른 길을 찾아서 찾아가는 것과 같습니다.

네트워크 계층은 패킷을 수신해야할 상대의 주소를 지정하고, 나가는 패킷에 대해서 적절한 크기로 분할하며 들어오는 패킷에 대해서는 재조립을 수행합니다. 이 계층에서 사용되는 규약이 바로 IP(Internet Protocol)입니다. TCP/IP에서 한 부분을 차지하는 중요한 부분이죠.

IP는 내보낸 패킷을 상대방이 잘 수령했는지에 대해 보장하지 않습니다. 택배로 비유하여 소포가 배달 중 문제가 생겨 파손되거나 분실되도 전혀 책임을 지지 않는 악덕 택배회사죠. 택배를 잘 수령했는지 여부를 파악하는 기능 자체가 없습니다. 그저 트랜스포트 계층에서 내려온 패킷에 주소를 붙여 링크 계층으로 보낼 뿐입니다. 이 때문에 여러 개의 소포를 보낼 때 순서대로 도착하지 않아도 이상할 것이 없습니다.

링크(네트워크 인터페이스) 계층

TCP/IP는 네트워크 물리적 구성으로부터 독립적인 프로토콜입니다. 컴퓨터가 네트워크에 물리적으로 전화선 모뎀으로 연결되던, LAN에 이더넷 케이블로 연결되던, Wi-Fi로 연결되어 있던 신경쓰지 않습니다. 이 것은 링크계층에서 네트워크의 물리적인 연결 매체를 통해 패킷을 주고받는 작업을 담당해주기 때문입니다.

가령 어떤 패킷이 네트워크를 통해 들어오면 먼저 이 링크 계층에 들어오게 됩니다. 링크 계층은 이 패킷에서 물리적 데이터 전송에 사용되던 부분(패킷의 헤더나 푸터)를 제거하고 인터넷 계층에 넘깁니다. 이렇게 함으로서 네트워크 계층에서는. 어떤 물리적인 장치로 패킷이 넘어왔던 신경쓰지 않고 처리를 시작할 수 있게 됩니다.

패킷이란?

패킷은 "소포"라는 뜻의 영단어입니다. 네트워크를 통해 오고가는 데이터를 패킷이라고 부릅니다. 그 이유는 "내용물"인 데이터를 애플리케이션 계층, 트랜스포트 계층, 네트워크 계층, 링크 계층에서 각각 필요한 정보들을 포장해서 보내기 때문입니다. 그리고 받을 때도 각 계층에서는 포장지를 한겹 한겹 벗겨서 데이터를 얻어내죠.

더 많은 정보는 다음의 유튜브 동영상을 확인하세요.

Socket 프로그래밍

소켓이란?

네트워크는 간단하게 말해서 네트워크에 연결되어 있는 서로 다른 두 컴퓨터가 데이터를 주고 받는 것 입니다. 이것이 전부입니다! 이를 위해선 물리적 연결이 우선 필요합니다. 하지만 대부분의 컴퓨터는 이미 물리적 연결이 이루어져 있으므로 신경쓰지 않도록 합니다. 그 다음으로는 물리적 연결을 기반으로 하는 소프트웨어적인 데이터 송수신 방법을 고민하면 됩니다. 하지만 운영체제에서 이미 소켓이라는 것을 제공하기 때문에 데이터 송수신의 원리를 잘 몰라도 소켓을 통해서 데이터를 주고 받을 수 있습니다. 그래서 네트워크 프로그래밍을 소켓 프로그래밍이라고도 하죠.

그렇다면 왜 소켓이라는 말을 쓸까요? 우리는 전력망으로부터 전기를 공급 받기 위해 소켓을 꽂죠. 마찬가지로 멀리 떨어져있는 컴퓨터와 데이터를 송수신 하기위해 인터넷이라는 네트워크망에 연결을 해야합니다. 프로그래밍에서의 소켓은 네트워크 망에 연결하는 도구가 되는 것입니다.

소켓의 유형

소켓의 유형에는 TCP/IP 프로토콜 기반의 Stream 방식과 UDP/IP 프로토콜 기반의 Datagram 방식이 있습니다.

Stream 방식
- 가장 큰 특징은 양방향 연결이 필요하다는 것입니다. 또한 보낸 곳에서 받는 곳까지 데이터가 소실되거나 변하지 않게 보장해 주며 보낸 순서대로 받을 수 있게 해줍니다. 하지만 보낸 한 개의 패킷을 여러 개로 나누어 받거나 반대로 여러 개의 패킷을 한 개로 뭉쳐서 받을 수 있으니 그에 대한 적절한 처리를 따로 해주어야 합니다.
Datagram 방식
- 스트림 방식과는 달리 양방향 연결이 필요 없고 보낸 데이터가 중간에 소실 될 수 있다는 특징을 가지고 있습니다. 언제 어떻게 소실될지는 여러 가지 이유로 달라 질 수 있으므로 에측하기 어렵습니다. 또한 먼저 보낸 데이터를 나중에 보낸 데이터보다 늦게 받을 수 있으며, 한 개의 데이터는 여러개로 쪼개짐 없이 받을 수 있습니다.

이번 스터디에서는 Stream을 다뤄보도록 하겠습니다.

소켓 통신 과정

자 그럼 소켓을 이용해 어떤 절차를 가지고 데이터를 주고 받는지 알아보도록 하겠습니다. (Stream Socket을 기반으로 한 설명입니다.)

전화기의 통신 과정

소켓은 전통적으로 전화기를 빗대어 많이 설명을 합니다. 네트워크의 통신도 전화기 통신과 마찬가지이기 때문에 유사하게 동작하는 것이죠. 일반적으로 전화기를 통해 통화를 할 때 다음과 같은 절차를 거칩니다.

소켓의 통신 과정

소켓의 통신은 위에서 다룬 전화기의 통신 방식과 거의 동일합니다.

실제 코드

실제 코드에서는 다음과 같이 사용합니다.

소켓 통신 들여다보기

1. server 소켓 생성과 listen

서버에서 전화를 받기 위해 전화기를 생성하고 전화번호를 192.168.1.102:80으로 부여한 후 네트워크에 연결하여 listen 상태로 만듭니다.

그림

코드

// Server 1. 전화기 생성
Socket socket = new Socket (AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.TCP);

// Server 2. 상대방에게 연결되기 위해 전화 번호를 부여
var endpoint = new IPEndPoint (IPAddress.Parse ("192.168.1.102"), 80);
socket.Bind (endpoint);

// Server 3. 전화를 통신망에 케이블로 연결
socket.Listen (backlog);

2. connect을 위한 client 소켓 생성

이제 전화를 거는 클라이언트에서 전화기를 생성합니다.

그림

코드

// Client 1. 전화기 생성
Socket socket = new Socket (AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.TCP);
var endpoint = new IPEndPoint(IPAddress.Parse("192.168.1.102"), 80);

3. client 소켓에서 server 소켓으로 메시지 전송

이제 클라이언트 전화기에서 서버 전화기로 연결 요청을 합니다.

그림

코드

// Client 2. 상대방에게 연결하기 
socket.Connect(endpoint);

4. server에서 새로운 소켓 생성 후 처리

서버가 클라이언트의 요청을 받으면 통신을 위한 새로운 소켓을 생성합니다. 그리고 이 소켓은 클라이언트 소켓의 IP 주소와 포트번호를 사용합니다. 이제 TCP 연결 세션이 생성되었습니다.

그림

코드

// Server 4. 수화기를 들어 전화 받기
var newClient = socket.Accept();

5. server Socket에서 client 소켓으로 메시지 전송

이제 서버와 클라이언트가 서로 소켓을 이용해 통신(읽기, 쓰기)를 합니다.

6. 소켓 Close

모든 통신이 끝나면 소켓을 종료합니다.

그림

코드

// 종료
socket.Close();

다음 주제

오늘 배워본 TCP 프로토콜을 사용하는 소켓 통신을 각자 구현해봅시다. 링크

python unittest assertion 종류

에반황 — Mon, 11 Feb 2019 19:14:40 +0900

python test assertion

TestCase 클래스는 값을 검사하고 실패를 보고하기 위해 몇 개의 assert 메서드를 제공합니다. 다음 표는 보통 많이 사용되는 메서드들입니다(더 많은 assert 메서드는 표 아래를 보십시오):

메서드	검사하는 내용	추가된 버전
`assertEqual(a, b)`	`a == b`
`assertNotEqual(a, b)`	`a != b`
`assertTrue(x)`	`bool(x) is True`
`assertFalse(x)`	`bool(x) is False`
`assertIs(a, b)`	`a is b`	3.1
`assertIsNot(a, b)`	`a is not b`	3.1
`assertIsNone(x)`	`x is None`	3.1
`assertIsNotNone(x)`	`x is not None`	3.1
`assertIn(a, b)`	`a in b`	3.1
`assertNotIn(a, b)`	`a not in b`	3.1
`assertIsInstance(a, b)`	`isinstance(a, b)`	3.2
`assertNotIsInstance(a, b)`	`not isinstance(a, b)`	3.2

모든 assert 메서드는 msg 인자를 받을 수 있습니다, 만약 그것이 전달된다면 실패 시 에러 메시지로 사용됩니다(longMessage 도 참고하십시오). assertRaises(), assertRaisesRegex(), assertWarns(), assertWarnsRegex()는 컨텍스트 관리자로서 사용될 때만 그들에게 msg 키워드 인자를 전달할 수 있다는 점을 주의하십시오.

assertEqual(first, second, msg=None)
first와 second가 같은지 테스트합니다. 비교한 값이 같지 않으면 테스트는 실패할 것입니다.추가로, 만약 first와 second가 정확히 같은 형(type)이고 list, tuple, dict, set, frozenset, str 이거나 addTypeEqualityFunc()에 등록된 서브 클래스 형 중 하나일 경우 더 유용한 기본 에러 메시지를 생성하기 위해 형-특화(type-specific) 동등성 함수가 불릴 것입니다(형-특화 메서드 목록을 참고하십시오).버전 3.1으로 변경: 형-특화 동등성 함수가 자동으로 불리도록 추가버전 3.2으로 변경: 문자열 비교를 위해서 assertMultiLineEqual()를 기본 형-특화 동등성 함수에 추가

assertNotEqual(first, second, msg=None)
==first와 second가 같지 않은지 테스트==합니다, 비교한 값이 같으면 테스트는 실패할 것입니다.

assertTrue(expr, msg=None)
assertFalse(expr, msg=None)
expr이 참(또는 거짓)인지 테스트합니다.이것은 bool(expr) is True와 동등하고 expr is True와 동등하지 않다는 것에 주의하십시오(후자를 위해선 assertIs(expr, True)를 사용하십시오). 더 구체적인 메서드를 사용할 수 있을 때는 이 메서드를 지양해야 합니다(예, assertTrue(a == b) 대신에 assertEqual(a, b)), 왜냐하면 실패의 경우에 구체적인 메서드가 더 나은 에러 메시지를 제공하기 때문입니다.

assertIs(first, second, msg=None)
assertIsNot(first, second, msg=None)
first와 second가 같은 객체로 평가되는지(아닌지) 테스트합니다.버전 3.1에 추가.

assertIsNone(expr, msg=None)
assertIsNotNone(expr, msg=None)
expr이 None 인지(아닌지) 테스트합니다.버전 3.1에 추가.

assertIn(first, second, msg=None)
assertNotIn(first, second, msg=None)
==first가 second 안에 있는지(아닌지) 테스트==합니다.버전 3.1에 추가.

assertIsInstance(obj, cls, msg=None)
assertNotIsInstance(obj, cls, msg=None)
==obj가 cls(isinstance()가 지원하는 것처럼 클래스 또는 클래스의 튜플)의 인스턴스인지(아닌지) 테스트==합니다. 정확한 형 검사를 위해서는 assertIs(type(obj), cls)를 사용하십시오.버전 3.2에 추가.

다음의 메서드를 사용하여 예외, 경고, 로그 메시지의 발생을 검사할 수 있습니다:

메서드	검사하는 내용	추가된 버전
`assertRaises(exc, fun, args, *kwds)`	`fun(args, kwds)`가 exc*를 발생
`assertRaisesRegex(exc, r, fun, args,*kwds)`	`fun(args, kwds)`가 exc*를 발생하고 메시지가 정규식 r에 일치	3.1
`assertWarns(warn, fun, args, *kwds)`	`fun(args, kwds)`가 warn*을 발생	3.2
`assertWarnsRegex(warn, r, fun, args,*kwds)`	`fun(args, kwds)`가 warn*을 발생하고 메시지가 정규식 r에 일치	3.2
`assertLogs(logger, level)`	`with` 블록이 최소 level로 logger에 로그를 남김	3.4

assertRaises(exception, callable, args*, *kwds*)
assertRaises(exception, ***, msg=None)
assertRaises()에 전달된 어떤 위치 또는 키워드 인자와 함께 callable이 호출되었을 때 예외가 발생하는지 테스트합니다. exception이 발생하면 테스트를 통과하고, 다른 예외가 발생하면 에러이고, 아무 예외도 발생하지 않으면 실패입니다. 여러 예외 모음을 잡기 위해서 예외 클래스를 포함한 튜플을 exception으로 전달해도 좋습니다. 만약 선택적인 msg와 함께 오직 exception 인자만 전달된다면, 테스트할 코드를 함수가 아닌 인라인으로 작성할 수 있도록 컨텍스트 관리자를 반환합니다:
```
with self.assertRaises(SomeException):
    do_something()
```
컨텍스트 관리자로 사용되면, assertRaises()는 추가적인 키워드 인자인 msg를 받을 수 있습니다.컨텍스트 관리자는 잡은 예외 객체를 exception 어트리뷰트에 저장할 것입니다. 이것은 발생한 예외에 대해서 추가적인 검사를 수행하려는 경우에 유용할 수 있습니다:
```
with self.assertRaises(SomeException) as cm:
    do_something()

the_exception = cm.exception
self.assertEqual(the_exception.error_code, 3)
```
버전 3.1으로 변경: assertRaises()를 컨텍스트 관리자로 사용할 수 있도록 기능 추가.버전 3.2으로 변경: exception 어트리뷰트 추가.버전 3.3으로 변경: 컨텍스트 관리자로 사용될 때 msg 키워드 인자 추가.

assertRaisesRegex(exception, regex, callable, args*, *kwds*)
assertRaisesRegex(exception, regex, ***, msg=None)
assertRaises()와 비슷하지만 발생한 예외의 문자열 표현이 regex에 일치하는지 테스트합니다. regex는 정규식 객체나 re.search()에 사용되기 적합한 정규식 문자열이 될 수 있습니다. 예:
```
self.assertRaisesRegex(ValueError, "invalid literal for.*XYZ'$",
                       int, 'XYZ')
```
또는:
```
with self.assertRaisesRegex(ValueError, 'literal'):
   int('XYZ')
```
버전 3.1에 추가: assertRaisesRegexp 라는 이름으로.버전 3.2으로 변경: assertRaisesRegex()으로 이름 변경.버전 3.3으로 변경: 컨텍스트 관리자로 사용될 때 msg 키워드 인자 추가.

assertWarns(warning, callable, args*, *kwds*)
assertWarns(warning, ***, msg=None)
assertWarns()에 전달된 어떤 위치 또는 키워드 인자와 함께 callable이 호출되었을 때 경고(warning)가 발생하는지 테스트합니다. warning이 발생하면 테스트를 통과하고, 그렇지 않으면 실패입니다. 예외가 발생하면 에러입니다. 여러 경고 모음을 잡기 위해서 경고 클래스를 포함한 튜플을 warnings로 전달해도 좋습니다.
만약 선택적인 msg와 함께 오직 warning 인자만 전달된다면, 테스트할 코드를 함수가 아닌 인라인으로 작성할 수 있도록 컨텍스트 관리자를 반환합니다:
```
with self.assertWarns(SomeWarning):
    do_something()
```
컨텍스트 관리자로 사용되면, assertWarns()는 추가적인 키워드 인자인 msg를 받을 수 있습니다.
컨텍스트 관리자는 잡은 경고 객체를 warning 어트리뷰트에 저장하고, 경고를 발생한 소스코드 줄을 filename과 lineno에 저장할 것입니다. 이것은 발생한 경고에 대해서 추가적인 검사를 수행하려는 경우에 유용할 수 있습니다:
```
with self.assertWarns(SomeWarning) as cm:
    do_something()

self.assertIn('myfile.py', cm.filename)
self.assertEqual(320, cm.lineno)
```
이 메서드는 호출될 때 적용될 경고 필터와 관계없이 작동합니다.
버전 3.2에 추가.
버전 3.3으로 변경: 컨텍스트 관리자로 사용될 때 msg 키워드 인자 추가.

assertWarnsRegex(warning, regex, callable, args*, *kwds*)
assertWarnsRegex(warning, regex, ***, msg=None)
assertWarns()와 비슷하지만 발생한 경고의 메시지가 regex에 일치하는지 테스트합니다. regex는 정규식 객체나 re.search()에 사용되기 적합한 정규식 문자열이 될 수 있습니다. 예:
```
self.assertWarnsRegex(DeprecationWarning,
                      r'legacy_function is deprecated',
                      legacy_function, 'XYZ')
```
또는:
```
with self.assertWarnsRegex(RuntimeWarning, 'unsafe frobnicating'):
    frobnicate('/etc/passwd')
```
버전 3.2에 추가.
버전 3.3으로 변경: 컨텍스트 관리자로 사용될 때 msg 키워드 인자 추가.
assertLogs(logger=None, level=None)
최소한 level로 logger나 그 자식들에 최소한 1개의 메시지가 기록되는지 테스트하는 컨텍스트 관리자입니다.
logger가 주어졌다면, logging.Logger 객체이거나 로거의 이름인 str이어야 합니다. 기본값은 모든 메시지를 잡을 루트 로거입니다.
level이 주어졌다면, 로그 수준의 숫자 값이거나 그에 대응하는 문자열이어야 합니다(예를 들어 "ERROR"이거나 logging.ERROR). 기본값은 logging.INFO입니다.
만약 with 블록 안에서 logger와 level 조건을 만족하는 최소한 1개의 메시지가 나왔다면 테스트는 성공하고, 그렇지 않으면 실패합니다.
컨텍스트 관리자에 의해 반환되는 객체는 조건에 일치하는 로그 메시지를 추적하기 위한 기록 도우미입니다. 이것은 2개의 어트리뷰트를 가지고 있습니다:
- records
  조건에 일치하는 메시지의 logging.LogRecord 객체 목록.
- output
  조건에 일치하는 메시지의 포맷 출력인 str 객체 목록.
예:
```
with self.assertLogs('foo', level='INFO') as cm:
   logging.getLogger('foo').info('first message')
   logging.getLogger('foo.bar').error('second message')
self.assertEqual(cm.output, ['INFO:foo:first message',
                             'ERROR:foo.bar:second message'])
```
버전 3.4에 추가.

더 구체적인 검사를 수행하기 위한 또 다른 메서드가 있습니다, 아래와 같이:

메서드	검사하는 내용	추가된 버전
`assertAlmostEqual(a, b)`	`round(a-b, 7) == 0`
`assertNotAlmostEqual(a, b)`	`round(a-b, 7) != 0`
`assertGreater(a, b)`	`a > b`	3.1
`assertGreaterEqual(a, b)`	`a >= b`	3.1
`assertLess(a, b)`	`a < b`	3.1
`assertLessEqual(a, b)`	`a <= b`	3.1
`assertRegex(s, r)`	`r.search(s)`	3.1
`assertNotRegex(s, r)`	`not r.search(s)`	3.2
`assertCountEqual(a, b)`	순서와 상관없이 a와 b가 같은 개수의 같은 요소를 가졌는지	3.2

assertAlmostEqual(first, second, places=7, msg=None, delta=None)
assertNotAlmostEqual(first, second, places=7, msg=None, delta=None)
first와 second가 근사하게 같은지(또는 근사하게 같지 않은지) 테스트합니다. 이는 값 차이를 계산하고, 주어진 소수 자릿(places)수(기본값 7)로 반올림한 뒤, 0과 비교하는 것으로 이루어집니다. 이 메서드는 값을 유효 숫자 자릿수(significant digits)가 아닌 주어진 소수 자릿수(decimal places)(즉, round() 함수와 같이)로 반올림합니다.만약 places 대신에 delta가 주어진다면 first와 second의 값 차이는 반드시 delta보다 작거나 같아야(또는 커야) 합니다.delta와 places가 동시에 주어지면 TypeError가 발생합니다.버전 3.2으로 변경: assertAlmostEqual()은 같다고 비교되는 거의 동등한 객체를 자동으로 고려합니다. assertNotAlmostEqual()은 객체가 같다고 비교되면 자동으로 실패합니다. delta 키워드 인자를 추가.

assertGreater(first, second, msg=None)
assertGreaterEqual(first, second, msg=None)
assertLess(first, second, msg=None)
assertLessEqual(first, second, msg=None)
first를 second와 비교해서 각각 메서드 이름에 해당하는 >, >=, <, <= 인지 테스트합니다. 그렇지 않으면 테스트는 실패합니다:>>>>>> self.assertGreaterEqual(3, 4) AssertionError: "3" unexpectedly not greater than or equal to "4"버전 3.1에 추가.

assertRegex(text, regex, msg=None)
assertNotRegex(text, regex, msg=None)
regex 검색이 text에 일치하는지(아닌지) 테스트합니다. 실패의 경우, 에러 메시지는 패턴과 text(또는 패턴과 예상과 달리 일치한 text의 부분)를 포함할 것입니다. regex는 정규식 객체나 re.search()에 사용되기 적합한 정규식 문자열이 될 수 있습니다.버전 3.1에 추가: assertRegexpMatches 라는 이름으로.버전 3.2으로 변경: assertRegexpMatches() 메서드가 assertRegex()로 이름 변경되었습니다.버전 3.2에 추가: assertNotRegex().버전 3.5에 추가: assertNotRegexpMatches이름은 assertNotRegex()의 폐지된 에일리어스입니다.

assertCountEqual(first, second, msg=None)
first 시퀀스가 순서에 상관없이 second와 같은 요소를 포함하는지 테스트합니다. 그렇지 않은 경우, 시퀀스들의 차이를 나열한 에러 메시지가 생성됩니다.first와 second를 비교할 때 중복된 요소는 무시하지 않습니다. 두 개의 시퀀스에 각 요소가 같은 수 만큼 있는 것을 확인합니다. assertEqual(Counter(list(first)), Counter(list(second)))와 같지만 해시 불가능한(unhashable) 시퀀스에도 작동합니다.버전 3.2에 추가.

assertEqual() 메서드는 같은 형의 객체의 동등성 검사를 다른 형-특화 메서드에게로 보냅니다. 이러한 메서드들은 대부분의 내장 형에 대해서 이미 구현되어 있지만, addTypeEqualityFunc()을 사용하여 새로운 메서드를 등록하는 것도 가능합니다:

addTypeEqualityFunc(typeobj, function)
정확히 같은 (서브 클래스가 아닌) typeobj 형의 두 객체가 같은지 비교 검사하기 위해 assertEqual()한테 불리는 형-특화 메서드를 등록합니다. function은 반드시 2개의 위치 인자를 받아야 하고 assertEqual()이 그러한 것처럼 msg=None 키워드 인자를 세 번째로 받아야 합니다. 이것은 처음 2개의 매개변수가 같지 않은 것이 확인될 경우 self.failureException(msg)을 반드시 발생시켜야 합니다 -- 에러 메시지에 유용한 정보를 제공하고 비동등성을 자세히 설명할 수 있을 것입니다.버전 3.1에 추가.

assertEqual()에서 자동으로 사용하는 형-특화 메서드 목록은 다음 표에 정리되어 있습니다. 보통은 이 메서드를 직접 부를 필요가 없다는 것을 기억하십시오.

메서드	을 비교하기 위해	추가된 버전
`assertMultiLineEqual(a, b)`	문자열	3.1
`assertSequenceEqual(a, b)`	시퀀스	3.1
`assertListEqual(a, b)`	리스트	3.1
`assertTupleEqual(a, b)`	튜플	3.1
`assertSetEqual(a, b)`	집합 또는 불변 집합	3.1
`assertDictEqual(a, b)`	딕셔너리	3.1

assertMultiLineEqual(first, second, msg=None)
여러 줄 문자열인 first와 second가 같은지 테스트합니다. 같지 않을 경우 에러 메시지에 다른 부분이 강조된 두 문자열의 차이가 포함됩니다. 이 메서드는 assertEqual()에서 문자열을 비교할 때 기본적으로 사용됩니다.버전 3.1에 추가.

assertSequenceEqual(first, second, msg=None, seq_type=None)
2개의 시퀀스가 같은지 테스트합니다. seq_type이 전달된 경우, first와 second 둘 다 seq_type의 인스턴스이어야 하고 그렇지 않은 경우 실패가 발생합니다. 시퀀스가 다른 경우, 에러 메시지는 2개 사이의 차이점을 보여주게 됩니다.이 메서드는 assertEqual()에서 직접 호출되진 않지만, assertListEqual()와 assertTupleEqual()을 구현할 때 사용됩니다.버전 3.1에 추가.

assertListEqual(first, second, msg=None)
assertTupleEqual(first, second, msg=None)
2개의 리스트나 튜플이 같은지 테스트합니다. 만약 같지 않다면 에러 메시지는 2개 사이의 차이점만 보여주게 됩니다. 매개변수 중 하나가 잘못된 형인 경우 에러가 발생합니다. 이 메서드는 assertEqual()에서 리스트와 튜플을 비교할 때 기본적으로 사용됩니다.버전 3.1에 추가.

assertSetEqual(first, second, msg=None)
2개의 집합이 같은지 테스트합니다. 같지 않은 경우 에러 메시지는 집합 사이의 차이를 나열하게 됩니다. 이 메서드는 assertEqual()에서 집합이나 불변 집합을 비교할 때 기본적으로 사용됩니다.first와 second 중 하나가 set.difference() 메서드를 가지고 있지 않으면 실패합니다.버전 3.1에 추가.

assertDictEqual(first, second, msg=None)
2개의 딕셔너리가 같은지 테스트합니다. 같지 않은 경우 에러 메시지는 딕셔너리 사이의 차이를 보여주게 됩니다. 이 메서드는 assertEqual()에서 딕셔너리를 비교할 때 기본적으로 사용될 것입니다.
버전 3.1에 추가.