세모노트

블로그 이사했습니다

hojongs — Sun, 22 Jan 2023 14:42:40 +0900

(2025.01.27) https://hojongs.medium.com/

이사 간 블로그 주소: https://hojongs.github.io/

Tech Blog by hojongs

Spring Boot, Kotlin, Kubernetes, Docker, DevOps 등에 호기심이 많은 한 서버 개발자의 문서 저장소

hojongs.github.io

블로그 이사한 이유: https://hojongs.github.io/posts/reasons-for-migrating-blog-from-medium/

Medium 블로그를 이사온 이유, 블로그 플랫폼 비교

왜 2년동안 사용하던 Medium을 버리고 github.io로 이사온 이유를 개발자로서 이야기하려 한다.

hojongs.github.io

일상 주제 : medium으로 이사가자! velog도 괜찮네

hojongs — Wed, 17 Feb 2021 23:53:39 +0900

medium 포스트 작성 UX가 전반적으로 티스토리보다 퀄리티가 높고

draft들이 리스트로 보이는 UI가 맘에 들어서, medium으로 옮기기로 마음먹게 되었다.

medium 외에 velog라는 블로그 서비스도 알게 되었다 우연히.

velog는 개발자들을 위한 블로그 서비스고, 국내의 벨라포트라는 프론트엔드 개발자가 만드셨다고 한다.

github 로그인 연동도 되고 markdown을 지원하고 UI가 마음에 들었지만, medium과 velog를 동시에 운영하고 싶지는 않았다..

medium에 Tech Blog용 계정과 이 글처럼 잡다한 포스팅용 계정 2개를 운영해야겠다.

약간 브레인 스토밍 느낌으로.

https://hojongs.medium.com/

Jongho Jeon – Medium

Read writing from Jongho Jeon on Medium. Server developer at TossBank. Done is better than perfect. Every day, Jongho Jeon and thousands of other voices read, write, and share important stories on Medium.

hojongs.medium.com

https://github.com/hojongs/

hojongs - Overview

Lazy Software Engineer who wants to be a small giant - hojongs

github.com

2월17일자 생각 : 블로그 medium 이사 고민, 업무 비효율 및 대책

hojongs — Wed, 17 Feb 2021 00:55:51 +0900

24시간 생각이 끊이지 않는 성격이라, 이 생각들을 글로 남겨두려고 한다. 잊어버리면 아까우니까.

대부분은 크게 중요하지 않은, 의미없는 생각들이겠지만 하나라도 기발한 생각이 남지 않을까.

이게 요즘 블로그에 다시 포스팅을 이어나가고 있는 이유이다.

또다른 이유는, 머릿 속으로 생각하는 것보다 말, 글, 또는 그림으로 생각을 표현하는 게 더 잘 정리가 되고, 이해가 되기 때문이다.

오늘은 특별한 주제없이, 그냥 생각이라는 것 자체를 주제로 글을 남겨보려고 한다.

---

주제를 벗어나는 이야기지만, 지난 포스팅에서 티스토리 말고 다른 블로그 플랫폼을 찾는다는 말을 썼었다.

조금 찾아보니,
네이버 블로그는 네이버 검색 최적화 외에는 큰 메리트를 느끼지 못 했고
medium은 원래 고려하지 않고 있었고 (한글 가독성 최악이라는 평도 있었음)
brunch는 가입해보니, 지금처럼 가벼운 글을 쓰는 플랫폼은 아니어서 PASS
wordpress는 세팅 귀찮음 (편의성이 지금 나에겐 최고 중요)
github io, notion은 나에게 적합하지 않았다

이 글을 쓰다보니 이글루라는 곳도 있었던 게 생각났는데, 여기도 큰 메리트가 있을 것 같지는 않다.

instagram, facebook, twitter와 같은 SNS는 이 글처럼 떠오르는 생각을, 짧게 쓰기에는 적합하지만
내가 쓰게 될 주제가 다양하고 긴 내용의 글도 있을 것 같아서 안될 것 같다.

결론은 다른 플랫폼을 찾기 전까지는 tistory를 유지할 것 같다.
검색 최적화는 안돼있을 것 같지만, 뭐 노출보다는 내 생각 정리해놓는 게 1순위니까.

markdown WYSIWIG이 지원되는 블로그 플랫폼 또 없나.. (어쩔 수 없이 medium으로 가야하나..)

아무튼, 딴 소리가 길었다. (곧 medium 계정 하나 더 만들어서 옮기게 될 것 같다 ㅋㅋ)

---

생각. 지금 나는 개발자로 일한 지 1년 4개월 정도 됐다.
그리고 요즘, 커뮤니케이션으로 대부분의 시간을 보내고 개발 업무에는 거의 집중력&효율성이 바닥인 상태이다.
왜 이렇게 커뮤니케이션 코스트가 높은걸까? 이건 다음 포스팅에서 정리해야겠다.
그래서 오늘 든 생각은, 업무 효율성에 관한 것이다.

---

업무 강도가 매우 높다보니, 업무 효율이 매우 떨어지고 눈앞의 업무를 해결하기에 급급해졌다.

퇴근 후 이런저런 생각을 하다가, 디자인(설계)에는 거의 신경을 쓰지 않고 있는 나 자신을 보게 되었다.

나는 종종 눈앞의 업무에 치여서, 좋은 디자인을 소홀히 하는 경험을 자주 하였다.

그리고 이건 부메랑처럼 돌아와, 곧 (1달도 채 되지 않는 시간이 지나서) 더 많은 업무 병목을 만들어냈다.

그래서 나는 대책을 생각했다. 크게 2가지다.

1. 하루 업무시간 중 4시간(절반)은 업무 집중시간으로, slack notification을 꺼놓고, 내 업무에만 집중하는 것이다. 예전에 잠깐 활용된 적 있는 방법이었는데 자연스럽게 잊혀졌었다.
2. 그리고 이 시간에, 개발 업무를 할 수도 있지만 일종의 Research를 하는 것이다. 다른 회사의 기술 블로그를 보고 내 Tech Blog에 읽은 내용 및 생각을 정리하거나, 좀더 넓은 시야에서 우리 회사 아키텍처를 바라보는 것이다.
전에는 나의 성장을 위한 접근법이라고 생각했지만 회사와 나 모두가 win-win하는 방법이라고 보인다.

커뮤니케이션만 생각하면 머리가 지끈거린다.
커뮤니케이션을 한 곳이 아니라 4~5가지의 주제로 10댓명과 비동기적으로 하다보니, 머리가 지끈거린다. (이 와중에 US 팀이랑 영어로도 이야기하고..)
ㅋㅋ 하루 중 절반이라도 개발만 할 수 있다면 개발 업무 속도가 회복될 것이다 (지금보다 4~5배는 빨라질 것이다..)
그리고 노후되어 가는 우리 코드의 아키텍처도 다시 한 번 돌아보고, 중장기적인(2주 혹은 1개월 이상 관점) 업무에도 다시 신경쓸 수 있게 될 것이다.

최근에 느낀 비효율적인 업무 방식에 대한 생각에 대한 내용을 정리해보았다.

---

업무를 비효율적으로 하다보니 가장 문제가 되었던 것 "생각이 정리되지 않는 것"이었다.
다른 사람들이 하는 말도 잘 이해 못 하게 되고, 문제 상황에 대한 정리 및 해결방안이 전혀 생각나지 않았다.
거의 머리 회전이 안되는 수준으로 느껴져서... 빠른 해결책이 필요했다. (그 해결책은 위에 써놓은 2가지를 시도해보려고 한다.)

---

오늘은 여러 가지 생각들을 적어보았다. 적다보니 내용이 다소 길어졌다.

갤럭시 탭에서 tistory 앱으로 포스트를 작성해보고 있는데, 별점 2.5점 정도 수준이다.
기본 기능은 하는데 불편한 게 좀 있고, 쓰다보면 더 많이 느껴질 듯.
medium으로도 포스팅해보고 차이가 크면 medium으로 빨리 옮겨야겠다.

백준 알고리즘 10250번 : ACM 호텔

hojongs — Mon, 15 Feb 2021 23:45:34 +0900

www.acmicpc.net/problem/10250

10250번: ACM 호텔

프로그램은 표준 입력에서 입력 데이터를 받는다. 프로그램의 입력은 T 개의 테스트 데이터로 이루어져 있는데 T 는 입력의 맨 첫 줄에 주어진다. 각 테스트 데이터는 한 행으로서 H, W, N, 세 정수

www.acmicpc.net

심심한 김에, 포스팅 하나 더 올린다.

설명만 길 뿐, 아주 단순한 문제다.

101,201,301, ... 102,202,302, ... 순서대로 방에 들어가는 아주 단순한 규칙만 찾으면 된다.

H=6일 때 10번째 손님은 402호에 배정된다.

402호라는 숫자를 어떻게 얻어낼 수 있을지 생각해보자.

101~601

102~402

1번째 손님 = 101호

6번째 손님 = 601호

boundary의 규칙만 잘 파악하면 전체 규칙을 파악할 수 있다. 이 때의 boundary는 601호 -> 102호로 흘러가는 타이밍이다.

7번째 손님 = 102호

YY=01

XX=02

자세한 설명은 다소 생략하고,

N번째 손님에 대해

(XX-1) * H + YY = N라는 규칙이 있음을 알 수 있다

검증)

102호 : (2-1)*6+1 = 7번째 손님

402호 : (2-1)*6+4 = 10번째 손님

이걸 코드로 표현하면 끝인 것이다.

아, 위에서는 X,H,Y를 가지고 N을 구하는 식을 작성했다.

우리가 해야할 일은 N을 가지고 X,Y를 구하는 것이다.

삽질..

N=10,H=6으로 다시 생각해보면

N/H=1과 나머지 4

배정 호 수는 402호이므로

YY=(나머지)

XX=(N/H)+1

임을 알 수 있다

검증)

N=3,H=6

배정 호 수 = 301

YY=3

XX=(3/6)+1=1

YYXX=301

간단한 문제라고 급하게 풀다가 실수만 하지말자.

testcase = int(input())

for i in range(testcase):
    s = input().split()
    h,w,n = map(int, s)

    yy = n%h
    xx = n//h+1
    if xx < 10:
        yyxx = str(yy)+'0'+str(xx)
    else:
        yyxx = str(yy)+str(xx)
    print(yyxx)

loop 방식이 비효율적이고 생각해서 n/h 방식으로 접근했다가, n/h == 0인 edge case가 문제가 되었다.

그래서 loop 방식으로 다시 접근해보았다.

testcase = int(input())

for i in range(testcase):
    s = input().split()
    h,w,n = map(int, s)
    
    temp_n = n
    xx = 1
    while temp_n > h:
        xx += 1
        temp_n -= h
    yy = temp_n
    
    if xx < 10:
        yyxx = str(yy)+'0'+str(xx)
    else:
        yyxx = str(yy)+str(xx)
    print(yyxx)

티스토리.. 코드블럭 기능이 추가되었다 했더니 코드블럭 밑에서 한글이 안 나오는 버그가 있나보다. (바로 입력하면)

아무튼, 다소 효율적인 코드는 아니지만 문제를 해결할 수 있었다

www.acmicpc.net/source/26406155

로그인

www.acmicpc.net

다음 포스팅은 tistory를 대신할 블로그 플랫폼을 찾는 글이 될 것 같다..

백준 알고리즘 14681번 : 사분면 고르기

hojongs — Mon, 15 Feb 2021 22:42:07 +0900

www.acmicpc.net/problem/14681

14681번: 사분면 고르기

점 (x, y)의 사분면 번호(1, 2, 3, 4 중 하나)를 출력한다.

www.acmicpc.net

몸풀이 if문 문제다

설명이 필요없다

소스는 여기에

www.acmicpc.net/source/26402990

---

마지막 포스팅 날짜가 2019.06월로, 1년 반만에 포스팅이다.

블로그 포스팅을 다시 시작해보려 한다. 단, 본격적인 Tech Blog는 medium에 올리려 한다 (UI/UX 및 검색 노출?)

medium.com/jongho-developer

jongho-developer – Medium

Jongho’s Tech Blog.

medium.com

여기는 좀더 일상적이고, 간단한, 가벼운, 한국 사람들에게 노출&소통하고 싶은(관심있어할 만한) 내용을 포스팅해보려 한다.

하다 못해 이런 알고리즘 문제풀이 포스팅이라도 남기려 한다.

새삼스럽지만 티스토리 포스팅 UI 참... 떠나고 싶게 만든다.. ㅋㅋㅋㅋ

카테고리 설정 어디에 있는거야..

[Web Dev] Back-end Languages 종류,특징

hojongs — Mon, 24 Jun 2019 14:46:33 +0900

웹 개발 언어는 크게 2가지로 분류할 수 있다

프론트엔드 언어와 백엔드 언어

프론트엔드 언어는 클라이언트에서, 백엔드 언어는 서버에서 실행된다

# 프론트엔드 언어

프론트엔드는 기본적으로 HTML/CSS/JS로 구성되지만, 이 세 언어를 기반으로 한 Framework들을 이용하여 생산성을 높이는 방향으로 발전하고 있다

# 백엔드 언어

백엔드 언어는 서버에서만 실행되며, DB 연동 등의 데이터 처리를 주로 담당한다

백엔드 언어는 php, java(Spring, Servlet, JSP), Node.js, python(Django, Flask) 등 다양하게 존재한다

이 post에서는 백엔드 언어의 종류별 차이/특징을 아는대로 정리해보려 한다.

# php

php는 빠른 개발속도를 장점으로 알고 있다.

기본적인 개발환경 세팅이 비교적 간단하다

MVC 패턴 구조를 취하지 않아도 되기 때문에, 개발 자체는 빠르지만 유지보수를 고려하지 않고 개발하면

유지보수할 수 없는 코드가 되어버린다

하나의 파일에 HTML/CSS/JS 코드와 php 코드가 섞여 있으므로, 코드가 길어지면 코드를 읽기가 힘들어진다

중소규모 프로젝트에 적합할 것이다

웹개발을 시작하거나 중소규모 웹개발 프로젝트에 추천,

# java

Java 언어 자체가 Pure OOP 언어이므로, 다른 언어보다는 유지보수가 용이하도록 코드를 작성하게 될 것이다

대규모 프로젝트에 적합하며, 그만큼 개발환경 세팅이 다른 언어보다 비교적 복잡하다

Spring Framework는 MVC 패턴, Dependency Injection 패턴을 사용하는 구조인 것으로 알고 있다

Servlet, JSP 파일 등으로 구분하여 View는 JSP, Servlet은 Control, 그 외 Model class를 작성하여 Model 역할로 나누어 MVC 패턴을 준수하는 구조일 것이다

웹개발 경험이 있는 사람에게, 대규모 웹개발 프로젝트에 추천.

Spring F/W는 책으로 공부하는 것을 추천, (워낙 방대해서)

# Node.js

프론트엔드 언어인 자바스크립트 문법을 사용함으로써, 프론트엔드 개발자가 풀스택 개발을 하기에 가장 쉽다

가장 큰 특징인 Async(비동기) 처리 방식으로, throughput(시간당 처리량)이 가장 높다

하지만 처리시간에 오래 걸리는 서비스에는 적합하지 않다

callback을 이용한 비동기 처리 방식과 자바스크립트 문법이 개인적으로 굉장히 복잡하게 느껴졌다

높은 throughput을 요구하는 (=요청이 많은) 웹개발에 추천

예를 들면 모바일 앱, 게임 백엔드 서버

# python

python이 웹 개발 언어가 아닌 범용 언어이므로, python을 사용하던 사람들에게 좋은 접근성을 제공한다

python의 장단점들을 모두 가져올 수 있다는 특징이 있다

Flask framework는 중소규모 프로젝트에, Django framework는 대규모 프로젝트에 적합하다

필자는 python 언어가 자유도가 높다고 생각하나, 그럼에도 불구하고 Django 프레임워크를 처음 사용할 때는 제한이 많다고 느꼈다

python을 좋아하는 사람들에게 추천

Spring F/W처럼 Django도 책을 가지고 공부하길 추천

아주 간단한 웹개발이라면 Flask, 이후에 프로젝트가 커질 것을 생각하면 Django를 추천

그 외에 무슨 언어들이 있었지?

지금 생각나는 것들은 이 정도.

[Utility] URL 인코딩된 파일이름 URL 디코드

hojongs — Mon, 17 Jun 2019 23:09:11 +0900

인터넷에서 파일을 다운로드 받을 때, 파일이름이 URL decode 되지 않은채로 다운로드되는 경우가 있다

파일 사용 자체에는 문제 없지만, 파일이름을 알아보기 힘들다는 문제점이 있다

그런 파일들이 많을 때는 더 문제다

그래서 특정 디렉토리 내의 파일들의 이름을 url-decode하는 코드를 작성해봤다.

실행에는 python3가 필요하다

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
"""
Filename : urldecode.py
Python version : 3
Usage example : python urldecode.py C:\\my_dir
"""
import os
import argparse
from pathlib import Path
from urllib.parse import unquote
 
parser = argparse.ArgumentParser(description='특정 디렉토리의 url-encoded 파일이름들을 decode하는 프로그램')
parser.add_argument('dirpath', type=str, help='url-encoded 파일들이 위치한 디렉토리 경로')
args = parser.parse_args()
 
dirpath = Path(args.dirpath)
 
filenames = [x for x in dirpath.iterdir() if x.is_file()]
for x in filenames:
    print(x)
yn = input('rename all? (Y/n) : ').lower()
if yn != 'y':
    exit(0)
 
for old in filenames:
    new = Path(unquote(old.name))
    if new == old:
        continue
 
    print('Renamed {old} -> {new}'.format(old=old, new=new))
    old.rename(new)
 
Colored by Color Scripter
cs

[Algorithm/Data Structure] Tree C/C++ example code (+ Mirror Tree)

hojongs — Sun, 16 Jun 2019 21:31:25 +0900

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
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
#include <stdio.h>
#include <stdlib.h>
 
typedef int Element;
 
class Node
{
public:
    int id;
    Element elem;
    Node* left;
    Node* right;
 
    Node() : Node(0, 0, nullptr, nullptr) {};
    Node(int id, Element elem) : Node(id, elem, nullptr, nullptr) {};
    Node(int id, Element elem, Node* left, Node* right) : id(id), elem(elem), left(left), right(right) {}
    virtual ~Node() 
    {
        printf("Node %d Deleted \n", id);
        delete left;
        delete right;
    }
    void preorder()
    {
        printf(" %d", elem);
        if (left) left->preorder();
        if (right) right->preorder();
    }
    void inorder()
    {
        if (left) left->preorder();
        printf(" %d", elem);
        if (right) right->preorder();
    }
    void postorder()
    {
        if (left) left->preorder();
        if (right) right->preorder();
        printf(" %d", elem);
    }
    Node* search_child(int id)
    {
        if (this->id == id)
            return this;
 
        Node* node = nullptr;
        if (left != nullptr)
            node = left->search_child(id);
        if (node == nullptr && right != nullptr)
            node = right->search_child(id);
 
        return node;
    }
};
 
Node* mirror_tree(Node* node)
{
    Node* left = nullptr;
    if (node->right)
        left = mirror_tree(node->right);
 
    Node* r = nullptr;
    if (node->left)
        r = mirror_tree(node->left);
 
    return new Node(node->id, node->elem, left, r);
}
 
int main()
{
    // init tree (bottom-to-top)
    const int NODE_LEN = 6;
    Node* node[NODE_LEN];
    for (int i = 0; i < NODE_LEN; i++)
        node[i] = nullptr;
 
    node[4] = new Node(4, 4);
    node[5] = new Node(5, 5);
    node[2] = new Node(2, 2);
    node[3] = new Node(3, 3, node[4], node[5]);
    node[1] = new Node(1, 1, node[2], node[3]);
    Node* root = node[1];
 
    // test preorder()
    printf("preorder : ");
    root->preorder();
    printf("\n");
 
    // test preorder() of mirror_tree
    Node* mirror_root = mirror_tree(root);
    printf("preorder : ");
    mirror_root->preorder();
    printf("\n");
 
    // test search_child()
    Node* child = nullptr;
    child = root->search_child(2);
    if (child != nullptr)
        printf("id : %d \n", child->id);
    else
        printf("id : null \n");
 
    child = root->search_child(5);
    if (child != nullptr)
        printf("id : %d \n", child->id);
    else
        printf("id : null \n");
    
    child = root->search_child(6);
    if (child != nullptr)
        printf("id : %d \n", child->id);
    else
        printf("id : null \n");
 
    printf("Delete original tree \n");
    delete root;
    printf("Delete mirror_tree \n");
    delete mirror_root;
    return 0;
}
/*
original tree : 
  1
2   3
   4 5
preorder : 12345

mirror_tree : 
   1
 3   2
5 4
preorder : 13542
*/
 
Colored by Color Scripter
cs

알고리즘 문제 해결 전략 - 사탕 나눠주기 문제

hojongs — Wed, 27 Mar 2019 23:57:43 +0900

Intro

알고리즘 문제 해결 전략 책을 읽다가, 흥미로운 문제가 있어서 보충설명을 추가하여 정리하였다.
문제는 아래 링크에서 발췌하였다. (정오표의 틀린 내용도 보완하여 발췌하였다)
http://book.algospot.com/candy.html

사탕 나눠주기 문제

예제 문제를 하나 풀면서 점진적인 개선을 어떻게 적용할 수 있나 살펴봅시다. N(N≤30)개의 사탕을 세 명의 어린이에게 가능한 공평하게 나눠 주려고 합니다. 공평함의 기준은 받는 사탕의 총 무게가 가장 무거운 어린이와 가장 가벼운 어린이 간의 차이로 합시다. 사탕의 무게는 모두 20 이하의 정수입니다. 가능한 최소 차이는 얼마일까요?

이 문제를 푸는 가장 단순한 방법은 사탕을 나눠 주는 모든 방법을 하나씩 만들어 보는 것입니다. 각 사탕마다 셋 중 어느 어린이에게 줄 지를 결정한다고 하면 3^N, 즉 최대 205조 개의 방법을 만들어 보게 됩니다. 이는 죽기 전에 다 세어볼 수 있을까 엄두가 나지 않는 큰 수이지만, 사실 이 때 우리는 엄청나게 많은 수를 중복으로 세고 있습니다. 실제로 받은 사탕들이 서로 다르더라도 그 무게가 같다면 이 문제의 답은 같다는 점을 무시했기 때문입니다.

이 아이디어를 이용해 모든 방법을 만들어 보는 완전 탐색(6장) 대신 각 어린이가 가진 사탕의 총량을 상태 공간으로 하는 너비 우선 탐색(29장)으로 문제를 풀 수 있습니다. 이 때 각 상태는 세 어린이가 가진 사탕의 양을 표현하는 세 개의 정수입니다. 우리는 어떤 어린이에게도 사탕이 없음을 나타내는 (0, 0, 0)에서 시작해, 사탕을 하나 줄 때마다 그 어린이가 가진 사탕의 양을 늘립니다. 이렇게 하면 실제로 가진 사탕들이 다르더라도 그 무게가 같은 경우 하나의 상태로 취급해, 중복을 제거할 수 있습니다. 이 상태 공간의 크기는 얼마일까요? 사탕의 최대 무게는 20이므로, 각 어린이가 가진 사탕의 양은 0에서 20×N 사이입니다. 따라서 각 상태에 대해 방문 여부를 저장하려면 크기가 (20×N+1)3≤601^3(대략 2억)인 배열을 잡아야 합니다.

2억은 대개 시간 제한 안에 탐색할 수 있는 크기입니다만, 이 문제의 답이 최대 얼마인지 생각해 보면 이 방법을 더 최적화할 수 있습니다. 사탕을 가장 많이 받은 어린이와 가장 적게 받은 어린이의 차이가 20 이상이었다고 가정해 봅시다. 사탕의 최대 무게는 20이므로, 이때 사탕을 가장 많이 받은 어린이가 가장 적게 받은 어린이에게 사탕을 하나 준다면 이 둘이 가진 사탕의 양의 차이는 항상 감소합니다. 이렇게 하면 항상 원래보다 더 공평한 답을 얻을 수 있기 때문에, 차이가 20 이상인 경우는 절대로 최적의 답이 될 수 없다는 것을 알 수 있지요. 따라서 넉넉잡아도 사탕을 가장 많이 받은 어린이가 (20×N)/3+20 넘게 사탕을 받는 경우는 무시해도 됩니다. 그러면 실제로 할당해야 하는 배열의 크기는 (20×N^3+20)^3≤220^3(대략 1000만)으로 줄어듭니다.

이 정도면 충분히 문제를 풀 수 있을 것 같지만, 문제를 푸는 더 빠른 방법이 있습니다. 세 어린이 중 누가 가장 사탕을 적게 받고, 누가 가장 많이 받는지는 중요하지 않기 때문입니다. 세 어린이의 사탕의 총량이 (180, 190, 200)이건 (200, 190, 180)이건 우리의 답은 변하지 않지요. 따라서 세 어린이의 사탕의 총량이 항상 오름차순으로 정렬되어 있는 경우만을 탐색하도록 합시다. 서로 다른 세 수를 여섯 가지의 방법으로 나열할 수 있으므로, 이렇게 하면 경우의 수는 다시 대략 1/6으로 줄어듭니다. 결과적으로 대략 200만 개 이하의 경우의 수만을 탐색해 문제를 해결할 수 있지요. 이 과정에서 천재만이 떠올릴 수 있는 번뜩이는 영감은 필요없었지만, 처음에 생각했던 방법에 비해 검사해야 할 상태의 수가 1억분의 1로 줄어들었음을 알 수 있습니다.

보충설명

1

예제 문제를 하나 풀면서 점진적인 개선을 어떻게 적용할 수 있나 살펴봅시다. N(N≤30)개의 사탕을 세 명의 어린이에게 가능한 공평하게 나눠 주려고 합니다. 공평함의 기준은 받는 사탕의 총 무게가 가장 무거운 어린이와 가장 가벼운 어린이 간의 차이로 합시다. 사탕의 무게는 모두 20 이하의 정수입니다. 가능한 최소 차이는 얼마일까요?

문제는 다음과 같다.
최대 30개의 사탕을 3명의 어린이에게 나누어주려고 한다.
사탕의 무게는 1~20의 정수이다.
받은 사탕 무게의 합이 가장 큰 어린이와, 가장 가벼운 어린이의 무게 차는 최소 얼마일까?

2

이 문제를 푸는 가장 단순한 방법은 사탕을 나눠 주는 모든 방법을 하나씩 만들어 보는 것입니다. 각 사탕마다 셋 중 어느 어린이에게 줄 지를 결정한다고 하면 3^N, 즉 최대 205조 개의 방법을 만들어 보게 됩니다. 이는 죽기 전에 다 세어볼 수 있을까 엄두가 나지 않는 큰 수이지만, 사실 이 때 우리는 엄청나게 많은 수를 중복으로 세고 있습니다. 실제로 받은 사탕들이 서로 다르더라도 그 무게가 같다면 이 문제의 답은 같다는 점을 무시했기 때문입니다.

N개의 사탕을 3명의 어린이에게 나누어주는 경우의 수는 3^N개이다 (중복순열)
N=30일 경우 경우의 수는 약 205조 개가 된다
여기서 간과한 점은 각 어린이가 어떤 사탕들을 받았느냐가 아닌, 각 어린이가 받은 사탕 무게의 합이 중요하다는 점이다
받은 사탕의 개수나 각 사탕의 무게는 별도로 카운팅할 필요 없다

3

이 아이디어를 이용해 모든 방법을 만들어 보는 완전 탐색(6장) 대신 각 어린이가 가진 사탕의 총량을 상태 공간으로 하는 너비 우선 탐색(29장)으로 문제를 풀 수 있습니다. 이 때 각 상태는 세 어린이가 가진 사탕의 양을 표현하는 세 개의 정수입니다. 우리는 어떤 어린이에게도 사탕이 없음을 나타내는 (0, 0, 0)에서 시작해, 사탕을 하나 줄 때마다 그 어린이가 가진 사탕의 양을 늘립니다. 이렇게 하면 실제로 가진 사탕들이 다르더라도 그 무게가 같은 경우 하나의 상태로 취급해, 중복을 제거할 수 있습니다. 이 상태 공간의 크기는 얼마일까요? 사탕의 최대 무게는 20이므로, 각 어린이가 가진 사탕의 양은 0에서 20×N 사이입니다. 따라서 각 상태에 대해 방문 여부를 저장하려면 크기가 (20×N+1)3≤601^3(대략 2억)인 배열을 잡아야 합니다.

30개의 사탕을 3명의 어린이에게 나눠주는 방법이 아닌, 3명의 어린이가 받은 사탕 무게의 합의 경우의 수를 카운팅할 것이다
각 어린이가 가진 사탕 무게의 합이 될 수 있는 범위는, 0 ~ (20xN)이다 (20xN인 경우는 무게가 20인 모든 사탕을 다 받았을 경우)
즉, 20xN+1개의 경우의 수이다
어린이가 3명이므로, (20xN+1)^3개의 경우의 수가 존재하고, 최대 601^3 (약 2억)개가 될 수 있다
205조 개에서 2억 개로 경우의 수를 줄인 것은 굉장히 큰 차이라고 할 수 있겠다.
연산시간 관점에서나, 메모리 사용 관점에서나 모두.

4

2억은 대개 시간 제한 안에 탐색할 수 있는 크기입니다만, 이 문제의 답이 최대 얼마인지 생각해 보면 이 방법을 더 최적화할 수 있습니다. 사탕을 가장 많이 받은 어린이와 가장 적게 받은 어린이의 차이가 20 이상이었다고 가정해 봅시다. 사탕의 최대 무게는 20이므로, 이때 사탕을 가장 많이 받은 어린이가 가장 적게 받은 어린이에게 사탕을 하나 준다면 이 둘이 가진 사탕의 양의 차이는 항상 감소합니다. 이렇게 하면 항상 원래보다 더 공평한 답을 얻을 수 있기 때문에, 차이가 20 이상인 경우는 절대로 최적의 답이 될 수 없다는 것을 알 수 있지요. 따라서 넉넉잡아도 사탕을 가장 많이 받은 어린이가 (20×N)/3+20 넘게 사탕을 받는 경우는 무시해도 됩니다. 그러면 실제로 할당해야 하는 배열의 크기는 (20×N^3+20)^3≤220^3(대략 1000만)으로 줄어듭니다.

이 부분이 바로, 이 글을 포스팅하게 만든 부분이다.
2억 가지의 경우의 수 중, 무게 차가 20 이상인 경우에 대해서 생각해보자.
사탕의 총 무게가 가장 무거운 어린이를 A, 가장 가벼운 어린이를 C라고 하자.
사탕의 최대 무게는 20이므로, A가 C에게 사탕을 하나 주면 무게 차는 항상 감소한다고 한다. (사실은 동등 또는 감소)
예시를 통해 검증해보자.

무게 차가 20 이상인 경우는 카운팅 할 필요 없다는 사실을 확인하기 위한 과정을 묘사하는 중이다.
A의 무게가 100, C의 무게가 80이라고 가정하자. 이 때 무게 차는 20이다.
A가 C에게 무게 20의 사탕을 1개 줬다면, A의 무게는 80, C의 무게는 100이 된다.
이 때도 무게 차는 20으로 변동없다. (무게 크기 관계는 역전됐지만)

만약 A가 C에게 무게 1의 사탕을 1개 줬다면, A의 무게는 99, C의 무게는 81이며 무게 차는 18로 감소한다.
사탕의 무게가 1~20이므로, 무게 차가 20인 경우에는 A가 C에게 사탕을 1개 주더라도 무게 차가 동등 또는 감소한다는 사실을 확인했다.

무게가 20 초과인 경우는 직관적으로, A가 C에게 사탕을 1개 주면 무게 차가 항상 감소한다는 사실을 알 수 있을 것이다.

문제에서 원하는 답은, 무게 차의 최소값이다.
하지만 무게 차가 20 이상인 경우는 최소 무게 차가 될 수 없다.
무게 차가 더 작은 경우가 항상 존재하기 때문이다.
무게 차가 더 작은 경우란, 무게 차가 20 이상인 경우에서 A가 C에게 사탕을 1개 준 것과 동일한 경우를 의미한다.

그러므로 무게 차가 20 이상인 경우는 카운팅 할 필요 없다.
문제에 나와있듯이 각 어린이의 사탕 총 무게가 (20×N)/3+20 이상인 경우는 카운팅할 필요 없다.
무게 차가 최소값이 될 수 없는 경우니까.
N=30인 경우 이 무게는 최대 220이 된다 (모든 사탕의 무게가 20)

사탕 총 무게가 가장 무거운 어린이가 220일 때, 가장 가벼운 어린이는 최대 180이 될 수 있다 (나머지 한 어린이는 200)
3명의 무게 합은 600이고, 무게 차는 40이 된다

필자의 생각으로는, 220^3가지의 경우의 수는, 무게 차가 40인 경우를 제외한 모든 경우의 수로 보인다
무게 차가 20 이상인 경우를 모두 제외하면 경우의 수를 더 줄일 수 있지 않을까 생각이 든다 (개선의 여지)
정리하여, 또다시 경우의 수를 획기적으로 감소시켰다.
이미 문제를 푸는 데에는 문제가 없는 수준까지 개선시켰다고 할 수 있겠다.

5

이 정도면 충분히 문제를 풀 수 있을 것 같지만, 문제를 푸는 더 빠른 방법이 있습니다. 세 어린이 중 누가 가장 사탕을 적게 받고, 누가 가장 많이 받는지는 중요하지 않기 때문입니다. 세 어린이의 사탕의 총량이 (180, 190, 200)이건 (200, 190, 180)이건 우리의 답은 변하지 않지요. 따라서 세 어린이의 사탕의 총량이 항상 오름차순으로 정렬되어 있는 경우만을 탐색하도록 합시다. 서로 다른 세 수를 여섯 가지의 방법으로 나열할 수 있으므로, 이렇게 하면 경우의 수는 다시 대략 1/6으로 줄어듭니다. 결과적으로 대략 200만 개 이하의 경우의 수만을 탐색해 문제를 해결할 수 있지요. 이 과정에서 천재만이 떠올릴 수 있는 번뜩이는 영감은 필요없었지만, 처음에 생각했던 방법에 비해 검사해야 할 상태의 수가 1억분의 1로 줄어들었음을 알 수 있습니다.

3명 중 누구의 사탕 총 무게가 가장 무거운지는 중요하지 않다.
그러므로 3명을 무게 순으로 오름차순 배치하여 경우의 줄일 수 있다.
3명의 어린이를 배치하는 방법은 순열 P(3,3) = 3x2x1 = 6가지 이고
이 중 오름차순 배치만 카운팅 하면 되므로, 경우의 수는 1/6배가 된다.
최종 경우의 수는 220^3 / 6가지가 되었다.

구현 코드

코드 하이라이팅 출처 : https://colorscripter.com/

3^N 카운팅 코드

[GoF Design Pattern] Abstract Factory

hojongs — Thu, 21 Jun 2018 16:40:20 +0900

직역하면 추상적인 공장

공장은 Object를 생성하는 공장이고

추상적인 공장이라 함은 생성하는 Object가 추상화되어 있다는 것이다

책에 있는대로 Object는 Maze를 예로 들겠다

Abstract Factory는 시스템에게, EnhancedMaze를 생성하는 factory인지, BoomMaze를 생성하는 factory인지에 대하여 추상화 되어있다
시스템(Client라고도 할 수 있다)은 어떤 Maze가 생성되는 지 모른다

그저 Factory를 통해서 어떤 Maze 생성을 수행한다

이것이 추상화의 의미

--- 효과 ---

Abstract Factory를 사용하면 Object와 시스템의 의존성을 제거함으로서 재사용성을 높일 수 있다

EnhancedMaze를 사용하는 System이 이미 있을 때, 이 시스템을 재사용하여 BoomMaze를 사용하는 System을 손쉽게 구현할 수 있다는 것이다

Clean Code에서는(197p) Abstract Factory를 이용하여 Application이 object 생성 시점을 결정(lazy initialization와 같은)하되, Object를 생성하는 코드는 애플리케이션(앞에서 시스템이라고 언급했던)이 모르게 한다고 되어있다