오늘도 끄적끄적

느리더라도 꾸준하게

Subnet

서브넷이란 Sub Network, 네트워크의 서브, 메인 네트워크를 쪼갰다고 보면 된다.
AWS 관점에서 봤을 때 메인 네트워크는 VPC라고 보면 된다.

Public Subnet

Public Subnet이란 외부에서 접근이 가능한 네트워크 정도로 이해하면 될 것 같다.

더 읽어보기 »

자세한 내용을 보고 싶으면 Amazon VPC란 무엇인가?를 참고하면 된다.

VPC(Virtual Private Cloud)란?

가상의 네트워크라고 보면 된다.
네트워크는 분산되어 있는 컴퓨터 자원들끼리 통신이 가능하게 끔 구축되어있는 환경 정도로 이해하면 될 것 같다.
즉, 네트워크에는 네트워크 외부와 통신이 가능한 인터넷 뿐만 아니라 네트워크 내부에서만 통신이 가능한 인트라넷 등등이 있다.
그 앞에 가상이 붙었다 싶이 물리적으로 네트워크를 구성한 게 아니라 논리적인 단위로 네트워크를 구성한 것이다.
이렇듯 클라우드 컴퓨팅은 많은 레이어들을 추상화 해놓고, 자동화 해놓음으로써 물리적으로 구축하기 힘든 환경을 손쉽게 제공해준다는 장점이 존재한다.

VPC 생성

더 읽어보기 »

이번 포스트에서는 평문의 데이터를 암호화/복호화 하는 방법에 대해서 이해해보자.
사람이 알아볼 수 있는 데이터를 평문(plain text)라고 말하고, 평문을 암호화한 걸 암호문(cipher text)라고 부른다.
수학적 원리를 알아보는 것도 아니기 때문에 간단하게만 정리해봤다.

키(KEY)

암호화/복호화 할 때 핵심 역할을 한다.
예를 들면 알파벳 순서를 3칸 땡겨라와 같은 키가 있을 때 키는 두 가지 관점에서 바라볼 수 있다.

  1. 알파벳 순서를 땡겨라/밀어라 - 알고리즘
    암호화 할 때 땡겨라 였으면 복호화 할 때는 밀어라 가 된다.
  2. 3칸 - 비밀번호
    비밀번호에 따라서 동일한 알고리즘이지만 암호화 했을 때 다른 값이 나온다.
더 읽어보기 »

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
여기서부터는 백엔드도 딱히 몰라도 되는 내용인 것 같다.

더 읽어보기 »

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
여기서부터는 프론트는 딱히 몰라도 된다고 생각하는 내용이므로 목차 뒤에 F/B를 구분해서 달지 않겠다.

더 읽어보기 »

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
각 목차 뒤에 F(ront), B(ack)을 적어놨으니 자신의 직군에 맞춰 딥하게 볼지 그냥 흐름만 볼지, 아예 안 볼지 판단하길 바란다.

더 읽어보기 »

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
각 목차 뒤에 F(ront), B(ack)을 적어놨으니 자신의 직군에 맞춰 딥하게 볼지 그냥 흐름만 볼지, 아예 안 볼지 판단하길 바란다.

더 읽어보기 »

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
각 목차 뒤에 F(ront), B(ack)을 적어놨으니 자신의 직군에 맞춰 딥하게 볼지 그냥 흐름만 볼지, 아예 안 볼지 판단하길 바란다.

더 읽어보기 »

문제의 발단

가끔 현재 시간을 기준으로 코드를 짜야할 때가 있다.
이런 경우에 자바의 경우에는 LocalDate, LocalTime, LocalDateTime 등등의 클래스에 있는 static 메서드인 now 메서드로 현재 시간을 구한다.
아래와 같이 말이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class App {
// 테스트 하기 어렵게 하기 위해서 일부러 메소드가 메소드를 계속해서 호출하는 형태로 작성함.
// 현재 시간이 오전인지 알아내는 메소드
public static boolean isAM() {
return method();
}

private static boolean method() {
return method2();
}

private static boolean method2() {
return method3();
}

private static boolean method3() {
return LocalTime.now().isBefore(LocalTime.of(12, 0));
}
}

하지만 이렇게 현재 시간에 의존하는 코드를 테스트하기란 매우 어렵다.

더 읽어보기 »

일반적인 테이블 구조의 문제점

일반적인 DB 테이블 구조에 맞춰 엔티티를 만들다보면 아래와 같이 만들게 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
@Entity
public class Deal {
@Id
private Long id;

@Column
private LocalDate saleStartDate;

@Column
private LocalDate saleEndDate;

@Column
private int normalPrice;

@Column
private int discountPrice;

public Long getId() {
return id;
}

public void setId(Long id) {
this.id = id;
}

public LocalDate getSaleStartDate() {
return saleStartDate;
}

public void setSaleStartDate(LocalDate saleStartDate) {
this.saleStartDate = saleStartDate;
}

public LocalDate getSaleEndDate() {
return saleEndDate;
}

public void setSaleEndDate(LocalDate saleEndDate) {
this.saleEndDate = saleEndDate;
}

public int getNormalPrice() {
return normalPrice;
}

public void setNormalPrice(int normalPrice) {
this.normalPrice = normalPrice;
}

public int getDiscountPrice() {
return discountPrice;
}

public void setDiscountPrice(int discountPrice) {
this.discountPrice = discountPrice;
}
}

객체 지향 관점에서 봤을 때 판매 시작/종료 날짜와 일반가/할인가는 전혀 관련이 없는 데이터이다.
응집력이 낮은 데이터들끼리 모여있으므로 테이블을 아래와 같이 설계하는 게 더 응집도 높은 엔티티가 될 것 같다.

더 읽어보기 »
0%