0%

나는 요즘 엄청난 자린고비로 살고 있다.
소비를 최소화하고, 최대한 저축하고, 돈이 들어가는 행위는 최대한 피하고 있다. (그로 인해 집에서 폐인처럼 지내는 나날이 많다.)
그러다보니 언제까지 이렇게 희생하며 살아야할까… 이렇게 산지 1년 조금 넘었는데 언제까지 이렇게 살아야하지? 계속 이렇게 산다고 해서 미래에 부자가 돼있을까? 란 생각이 강하게 들었다.
또한 이렇게 살다가 가짜 부자(돈이 있어도 항상 불안해서 돈을 쓰지 못하는)가 되는 건 아닐까 걱정도 됐다.
반면 부자들을 보면 내 생각보다 돈을 아끼지 않는 것 같은데도 부자가 된 사람들이 있는 것 같았다. (부모로부터 유산을 물려받은 경우를 제외하고)
과연 그들은 어떻게 부자가 되었으며, 나는 어떻게 하면 그들처럼 덜 희생하면서도 진짜 부자가 될 수 있을까 너무 궁금했다.
더 해빙을 통해 조금이나마 그 실마리가 풀린 것 같다.

Having이란…?

책의 제목에도 나오는 Having은 ‘지금 가지고 있음을 느끼는 것’이라고 한다.
Having을 돈에 접목시켜서 얘기하자면 ‘돈을 쓰는 이 순간 가지고 있음충만하게 느끼는 것’이다.
또한 Having은 지금 여기에서 출발해야한다.
현재 자신에게 있는 돈을 대상으로 삼아야지, 미래형이 아니라고 한다.
사소하게 밥을 사 먹을 때도 ‘식비 아깝다’가 아닌 ‘식비를 사먹을 돈이 있다‘, 즉 돈이 있음을 느끼면 Having을 한 것이다.

이렇게 보면 그냥 Having은 부정적인 마인드를 긍정적인 마인드로 바꾸는 것에 불과한 듯한 느낌이 들기도 한다.
하지만 단순히 그냥 마인드를 고쳐먹는다고 생각하면 뭐하는 짓인가… 이게 효과가 얼마나 있나… 싶은 생각이 들 수 있다.
그래서 책에서는 Having의 효과를 증폭시킬 수 있는 Having 노트에 대해 설명하고 있다.
지금 이순간 일시적으로 Having을 하면 그 효과는 그 때뿐이겠지만, Having에 대해 기록을 하면 마치 무수한 점들을 이은 것 마냥 그 흐름을 볼 수 있게 된다.
이 흐름 중에 좋은 흐름을 잘 포착하면 인생에 있어서 퀀텀 점프를 뛸 수 있다고 한다.

Having 노트에 적는 문장은 단순한 것이 좋다. (책에서는 한 주에 3~4회 정도 쓰는 걸 권장하고 있다.)

더 읽어보기 »

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

  1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
  2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
  3. Refactoring - 모든 중복제거(2번에서 수행한 죄악들을 청산)

해당 포스트는 프랑(CHF, 스위스 통화)을 달러($)로 변환하는 간단한 테스트를 작성하는 것부터 시작한다.

프랑에서 달러로 변환하기

아래와 같은 간단한 코드들을 이번 예제에서 사용해보자.

더 읽어보기 »

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

  1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
  2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
  3. Refactoring - 모든 중복제거(2번에서 수행한 죄악들을 청산)

책에서는 달러($)와 프랑(CHF, 스위스 통화)의 연산에 대한 조그만 테스트를 시작으로 두 통화 사이의 중복을 제거해나갔다.
해당 포스트는 클라이언트에 영향 없이 상속 구조를 마음껏 고칠 수 있는 방법에서 제거하지 못한 중복인 plus 메서드를 제거하는 것으로 시작한다.
(기본적으로 코틀린, JUnit5, kotest를 사용했다)
기본적인 내용은 내가 감명깊게 느낀 부분을 설명하기 위해 TDD로 진행해나가는 과정이고 실제 이 포스트의 핵심은 마치며를 보면 된다.

각 하위 클래스에 있는 plus 메서드 제거하기

기본적으로 소스 코드는 아래와 같다.

더 읽어보기 »

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

  1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
  2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
  3. Refactoring - 모든 중복제거(2번에서 수행한 죄악들을 청산)

책에서는 달러($)와 프랑(CHF, 스위스 통화)의 연산에 대한 조그만 테스트를 시작으로 두 통화 사이의 중복을 제거해나갔다.
해당 포스트도 위 두가지 통화에 대해 덧셈 연산을 테스트 하는 작은 코드로 시작한다.
(기본적으로 코틀린, JUnit5, kotest를 사용했다)
기본적인 내용은 내가 감명깊게 느낀 부분을 설명하기 위해 TDD로 진행해나가는 과정이고 실제 이 포스트의 핵심은 하위 클래스의 직접적인 참조 줄이기를 보면 된다.

Dollar 클래스 구현하기

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class DollarTest {
@Test
fun `$5 + $2 = $7`() {
// Given
val five = Dollar(5)
val two = Dollar(2)

// When
val actual = five + two

// Then
val expected = Dollar(7)
actual shouldBe expected
}
}
더 읽어보기 »

themes/next/_config.yml을 보면 아래와 같이 기본적으로 ‘더 읽어보기’가 세팅돼있다.

1
2
3
4
5
6
7
8
9
# Automatically excerpt (Not recommend).
# Use <!-- more --> in the post to control excerpt accurately.
auto_excerpt:
enable: true
length: 150

# Read more button
# If true, the read more button would be displayed in excerpt section.
read_more_btn: true

하지만 NexT Theme 7.6.0 이상의 버전에서는 위와 같이 설정이 돼있어도 ‘더 읽어보기’가 나오지 않는다.
이럴 때는 hexo-excerpt 플러그인을 설치해주면 해결된다. 🎉
https://github.com/theme-next/hexo-theme-next/issues/1245#issuecomment-558486354

If you are using NexT 7.6.0 and later, please install the plugin: https://github.com/chekun/hexo-excerpt

npki라는 디렉리토리 안에 보관돼있는 공인인증서의 공개키(*.der)와 비밀키(*.key)

인증서는 왜 쓸까

A가 데이터를 보냈는데 이게 진짜 A가 보낸 건지 아닌지를 검증할 수가 없다.
인증서는 A라는 사람이라는 것을 보증해주는 문서라고 보면 된다.
따라서 A한테 메세지가 올 때 A의 인증서가 오지 않는다면 A라고 취급을 하지 않으면 된다.
하지만 개나소나 인증서를 발급할 수 있으면 A 행세를 아무나 낼테니까 인증된 기관(CA, Certificate Authority)으로부터 적절한 절차를 거쳐 인증서를 발급받을 수 있다.

구글에서 사용 중인 인증서
우리가 알고 있는 TLS 인증서(https 도메인마다 발라져있는) 같은 경우에도 이런 절차를 거쳐 발급된다.
그리고 이런 인증서들은 X.509(공개키 인증서 포맷의 표준)라는 표준을 준수한다.

공인인증서는 왜 나왔을까

더 읽어보기 »

막연하게 양방향 암호화 하면 당연스레 AES를 떠올리고, 제대로 모른 채로 사용했다.
이제부터라도 조금은 알고 써야겠다는 생각이 들어서 살짝 정리해봤다.

양방향/단방향 암호화

양방향 암호화는 암호화 및 복호화가 가능하다는 소리다.
휴대폰 번호 등등 민감한 개인정보는 암호화 해서 저장해야하는데 고객 정보를 식별하기 위해선 복호화도 가능해야한다.
혹시나 키와 DB가 털린다면 복호화가 가능하므로 적어도 개인정보는 마스킹 한 후에 암호화해서 저장해야한다.
양방향 암호화 알고리즘에는 DES(보안에 취약), AES, SEED(국내에서 개발, 공인인증서에 사용됨) 등등이 있다.

단방향 암호화는 암호화만 가능하고 복호화는 불가능하다는 소리다.
비밀번호와 같이 암호화 한 값들끼리 단순히 비교만 하면 되고, 복호화 할 필요가 없는 정보들은 단방향 암호화 해야한다.
혹시나 키와 DB가 털려도 복호화가 불가능하기 때문에 암호화된 값만 알 수 있지 원본 비밀번호는 알 수 없기 때문에 양방향 암호화 보다는 좀 더 안전하다.
이런 특성 때문에 비밀번호 찾기 대신에 비밀번호 재설정 기능 밖에 지원 할 수 없다. (비밀번호 찾기를 지원해주는 사이트는 보안이 매우 안 좋은 사이트이다.)
단방향 암호화 알고리즘에는 해시 알고리즘이 사용되며 SHA256, SHA512, MD5(무작위 대입 공격에 약함) 등등이 있다.

더 읽어보기 »

코틀린의 장점을 하나 꼽자면 Non-null 타입을 지원한다는 것이다.
모든 곳에 null을 없앨 수 있는데(100% 순수 코틀린 코드로만 짠다면)
통제할 수 없는 부분은 클라이언트로부터 받는 Request이다.

그래서 Request에는 어떤 타입을 써야할지 삽질을 해봤다.

기본값을 사용하자.

1
2
3
4
5
6
7
class DTO(val name: String? = null)

@RestController
class Controller {
@PostMapping
fun test(@RequestBody dto: DTO) {}
}

위와 같을 때 request body의 name에 아무런 내용도 입력하지 않으면 name에 기본값 null이 잘 세팅된다.
기본값이 전부 존재하면 default constructor가 생성돼서 객체를 손쉽게 생성할 수 있다보니 테스트 할 때 용이하다.

더 읽어보기 »

연차 대비 너무너무 느린 개발 속도를 향상시키기 위해 나만의 Cheetsheet를 하나씩 만들어야겠다.
처음 접하는 코틀린 환경에서 자바에서는 좀 할만했던 DTO의 (De)Serialize 관련해서 적어보았다.
모든 설명은 JSON으로 request와 response를 주고받는 HTTP API 기반으로 진행하기 때문에 엄밀히 따지면 부정확한 내용들이 많다.

용어 설명

간단하게 용어들을 집고 넘어가자.

DTO(Data Transfer Object)

데이터를 전송하는데 사용하는 객체

더 읽어보기 »

돈으로부터 자유로워지려면 어떻게 해야할까?
월급을 얼마를 받던 상관없이 내가 원하는 삶을 살 수는 없을까?
지금은 내가 일을 해서 돈을 벌지만, 내가 일을 못하게 되면 어떤 삶을 살아야할까?
그렇다면 평생 일을 할 수 있다면, 죽을 때까지 계속해서 일을 해야하는 걸까?

사람마다 일과 삶(Working & Life), 그리고 돈에 대한 가치가 다 다르겠지만 내 스스로 기준을 정하고 내가 원하는 삶으로 이끌어나가기 위해서 책을 읽은 내용을 토대로 좀 정리해봤다.

자산과 부채

로버트 기요사키의 부자 아빠, 가난한 아빠에서는 다음과 같이 설명하고 있다.

자산은 내 지갑에 돈을 넣어주고, 부채는 내 지갑에서 돈을 꺼내간다.

더 읽어보기 »