심심한 개발공부

셀레니움 삽질 안하고 바로 쓰는 방법

susong — Mon, 23 Sep 2024 01:52:50 +0900

들어가면서

셀레니움으로 설치할 때마다 삽질 하기를 벌써 수 백번, 이번에는 AMD64에서 쓰던 스크립트를 라즈베리파이(ARM64)로 옮기면서 또 고장이 났다. 문제는 Chrome Driver.. 되도록이면 로컬에서 ARM64용 드라이버를 설치해서 쓰려고 했는데, 아쉽게도 구글에서는 공식으로 제공해주지 않고.. 그렇다고 사용자들이 만든걸 쓰려다보니까 버전이 안맞는다..

사용자들 껏을 쓰면 크롬 버전을 낮춰야되는데 하다가 고장나고.. 또 맞춰보니 드라이버가 안돌고.. 미쳐버리기 직전에 누가 컨테이너 만들어두지 않았을까? 생각이 들었고, 그래서 가져다가 썼다.

결과는 대만족! 그리고 컨테이너를 쓰면, 어떤 플랫폼, 아키텍트, OS라도 삽질 안해도 된다는 생각에 글로 남겨둔다.

(혹시 셀레니움 설정에 30분 이상 삽질을 했다면, 아래 방법을 강추한다)

하는 방법

1. 도커를 설치한다

sudo apt install docker.io

2. 도커에 필요한 권한들을 설정해둔다.

sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker

3. 설치한다(아래 명령어는 크롬 버전)

docker run -d -p 4444:4444 -p 7900:7900 --shm-size="2g" selenium/standalone-chrome

이 명령어를 치면 SHA값이 하나 뜨면서 컨테이너가 떴다고 뜰 것이다.

그러면 모든 준비는 끝났다!

띠용? 이게 왜 끝난거지 싶을 수 있지만 이제 당신은 Selenium을 잘 돌려주는 외부 대리인(컨테이너)를 만들어낸 것이다. 이제 모든 셀레니움 요청은 저 컨테이너로 보내면 된다.

예시코드

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.chrome.options import Options

# Set Chrome options
chrome_options = Options()

# Connect to the Selenium Grid running in the Docker container
driver = webdriver.Remote(
    command_executor='http://localhost:4444/wd/hub',
    options=chrome_options
)

# Open a web page
driver.get("https://www.google.com")

print(driver.title)

# Close the browser
driver.quit()

이제 이렇게 코드를 치면 내 PC에서 돌고 있는 컨테이너에게 "셀레니움 돌려!"

라고 시키는 명령을 하게 된다.

그리고 우리는 저 컨테이너가 열심히 돌려온 것의 결과만 잘 받아보면 된다.

복잡한 설정이나 문제들은 모두 컨테이너 안에서 다 해결해줬다.

컨테이너님이 다 해결해주신다.

앞으로는 직접 설치 하려고 하지말고, 컨테이너 쓰자

https://github.com/SeleniumHQ/docker-selenium

GitHub - SeleniumHQ/docker-selenium: Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Docker, mak

Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Docker, making it easier to perform browser automation - SeleniumHQ/docker-selenium

github.com

삽질 기록

https://github.com/SergeyPirogov/webdriver_manager

GitHub - SergeyPirogov/webdriver_manager

Contribute to SergeyPirogov/webdriver_manager development by creating an account on GitHub.

github.com

Selenium을 사용하기 위해서는 다 아시다싶이, 브라우저 + 드라이버가 필요하다.

브라우저는 설치하기 쉽지만, 드라이버는 조금 까다로운 경우가 있다(브라우저랑 버전 맞춰야함.. ARM 지원 안하는 곳도 있음.. 브라우저에 맞는 드라이버는 뭔지 확인.. 등등)

이런 모든 경우를 다 해결해주는 것이 저 webdriver_manager이다. 나도 사용한지 몇 년 되어왔고, 지속적으로 관리가 잘되는 프로젝트라 믿을 수 있다. 이번에 문제를 해결하면서, Solved Issue에 ARM64 지원 부분이 있기에 하라는 대로 했는데 잘 안되었다.

ARM64라서 안되었던 것일 수도 있어서 혹시 다른 버전이라면(특히 Windows에서 귀찮으신 분들)이라면 webdriver을 이용해서 돌려보는 것도 추천한다.

예시코드

# selenium 4
from selenium import webdriver
from selenium.webdriver.chrome.service import Service as ChromeService
from webdriver_manager.chrome import ChromeDriverManager

driver = webdriver.Chrome(service=ChromeService(ChromeDriverManager().install()))

[Palworld] Palworld 서버 최적화하기(서버 내부에서)

susong — Sun, 4 Feb 2024 17:19:12 +0900

Palworld(이하 팔월드) Dedeicated 서버를 운영하고 있다면, 가장 신경 쓰이는 부분은 게임 서버의 퀄리티일 것이다. 특히, 현재 팔월드 게임은 콘텐츠는 알차나 게임의 기술적인 완성도를 보면 만들어졌다고 보기 어렵기 때문에 더더욱 그렇다. 메모리 누수는 기본에, 멀티쓰레딩도 제대로 처리되고 있는지 확신이 들지 않을 정도이다.

이런 상황이지만, 게임을 잘 만들어서 즐기고 싶으니, 그리고 또 내 서버에 온 플레이어들이 재미있게 즐길 수 있게 하기 위해서 여러가지 최적화 방법을 고민해 봤고, 그 과정을 공유해보고자 한다. 아래 내용은 모두 리눅스(정확히는 우분투)를 기준으로 구성되어 있다. 윈도우도 파일 위치나 큰 내용적인 부분에서 차이가 없기 때문에 OS 간 차이를 이해하고 있다면 쉽게 따라 할 수 있을 것이라고 본다.

주말에 잠깐 사람 없을 때 한 컷 평균적으로 저정도 나온다(서울 내 접속시)

Engine.ini 설정 변경을 통한 네트워크 최적화

Linux에 팔월드를 설치했다면, 팔월드가 설치된 위치가 있을 것이다. $(팔월드 서버 위치)/Saved/Config/LinuxServer로 들어가면, 현재 운영하고 있는 서버의 Config값들을 볼 수 있는데, 이 방법은 Config 중 Engine.ini의 값을 바꾸는 테크닉이다. Config중 Engine.ini에 들어가면 여러 경로들이 보이는데 대충 아래와 같은 내용들을 확인할 수 있을 것이다.

// 위에 추가적인 내용들 있음
Paths=../../../Engine/Plugins/VirtualProduction/LiveLinkCamera/Content
Paths=../../../Engine/Plugins/VirtualProduction/Takes/Content
Paths=../../../Engine/Plugins/Web/HttpBlueprint/Content
Paths=../../../Pal/Plugins/DLSS/Content
Paths=../../../Pal/Plugins/EffectsChecker/Content
Paths=../../../Pal/Plugins/HoudiniEngine/Content
Paths=../../../Pal/Plugins/PPSkyCreatorPlugin/Content
Paths=../../../Pal/Plugins/PocketpairUser/Content
Paths=../../../Pal/Plugins/SpreadSheetToCsv/Content
Paths=../../../Pal/Plugins/Wwise/Content
// 마지막 줄(이 위치에 아래 내용 복붙하면 된다)

우리가 해야되는 일은 마지막 줄인

Paths=../../../Pal/Plugins/Wwise/Content에 이어서 아래 값들을 넣어주는 것이다.

; Online Subsystem Utils Configuration
; Adjusting tick rates for LAN and Internet servers to enhance the frequency of game state updates, 
; leading to smoother gameplay and less desynchronization between server and clients.
[/script/onlinesubsystemutils.ipnetdriver]
LanServerMaxTickRate=120  ; Sets maximum ticks per second for LAN servers, higher rates result in smoother gameplay.
NetServerMaxTickRate=120  ; Sets maximum ticks per second for Internet servers, similarly ensuring smoother online gameplay.

; Player Configuration
; These settings are crucial for optimizing the network bandwidth allocation per player, 
; allowing for more data to be sent and received without bottlenecking.
[/script/engine.player]
ConfiguredInternetSpeed=104857600  ; Sets the assumed player internet speed in bytes per second. High value reduces chances of bandwidth throttling.
ConfiguredLanSpeed=104857600       ; Sets the LAN speed, ensuring LAN players can utilize maximum network capacity.

; Socket Subsystem Epic Configuration
; Tailoring the max client rate for both local and internet clients, this optimizes data transfer rates, 
; ensuring that the server can handle high volumes of data without causing lag.
[/script/socketsubsystemepic.epicnetdriver]
MaxClientRate=104857600          ; Maximum data transfer rate per client for all connections, set to a high value to prevent data capping.
MaxInternetClientRate=104857600  ; Specifically targets internet clients, allowing for high-volume data transfer without restrictions.

; Engine Configuration
; These settings manage how the game's frame rate is handled, which can impact how smoothly the game runs.
; Smoother frame rates can lead to a better synchronization between client and server.
[/script/engine.engine]
bSmoothFrameRate=true    ; Enables the game engine to smooth out frame rate fluctuations for a more consistent visual experience.
bUseFixedFrameRate=false ; Disables the use of a fixed frame rate, allowing the game to dynamically adjust frame rate for optimal performance.
SmoothedFrameRateRange=(LowerBound=(Type=Inclusive,Value=30.000000),UpperBound=(Type=Exclusive,Value=120.000000)) ; Sets a target frame rate range for smoothing.
MinDesiredFrameRate=60.000000 ; Specifies a minimum acceptable frame rate, ensuring the game runs smoothly at least at this frame rate.
FixedFrameRate=120.000000     ; (Not active due to bUseFixedFrameRate set to false) Placeholder for a fixed frame rate if needed.
NetClientTicksPerSecond=120   ; Increases the update frequency for clients, enhancing responsiveness and reducing lag.

이 내용을 설명하면, 아래와 같다.

LanServerMaxTickRate: 이 설정은 로컬 영역 네트워크(LAN) 서버를 위한 것입니다. 서버가 초당 처리하는 업데이트 또는 "틱"의 최대 수를 지정합니다. 높은 틱률(여기서는 120으로 설정)은 서버가 더 자주 업데이트되어 LAN 설정에서 게임플레이가 더 부드럽고 플레이어의 동작에 대한 응답이 더 즉각적이 될 수 있음을 의미합니다.

NetServerMaxTickRate: LAN 설정과 유사하지만 인터넷 기반 서버를 위한 것입니다. 이것도 서버의 최대 틱률을 120로 설정합니다. 이 높은 틱률은 지연을 줄이고 인터넷을 통해 연결하는 플레이어들에게 게임의 전반적인 반응성을 향상시키는 데 유리합니다.

ConfiguredInternetSpeed: 이 설정은 각 플레이어의 네트워크 대역폭 할당을 최적화하는 데 중요합니다. 플레이어들에게 높은 가정 인터넷 속도(100 Mbps)를 설정하여 네트워크 대역폭 제한의 가능성을 줄입니다. 이는 서버가 각 플레이어가 고속 인터넷 연결을 가지고 있다고 가정하고 그에 따라 데이터를 송수신하며, 지연을 줄이는 데 도움이 될 수 있습니다.

ConfiguredLanSpeed: 인터넷 속도 설정과 유사하지만 LAN에 있는 플레이어들을 위한 것입니다. 이는 LAN에 있는 플레이어들이 게임 서버에 의해 부과된 인위적인 제한 없이 네트워크의 최대 용량을 활용할 수 있도록 보장합니다.

MaxClientRate와 MaxInternetClientRate: 이 설정들은 클라이언트(플레이어)의 데이터 전송 속도를 최적화하기 위한 것입니다. 둘 다 같은 높은 값(100 Mbps)으로 설정되어 서버가 높은 데이터량을 처리할 수 있도록 하여 지연을 방지합니다. 이는 플레이어 활동이 많거나 게임이 대량의 데이터를 전송하는 상황에서 특히 중요합니다.

bSmoothFrameRate: 이 설정은 게임 엔진이 프레임률의 변동을 부드럽게 하도록 합니다. 이를 통해 더 일관되고 시각적으로 안정된 게임 경험을 제공하려고 합니다. 프레임률 스무딩은 게임 성능과 시각적 품질 사이의 균형을 유지하는 데 특히 유리합니다.

bUseFixedFrameRate: 설정에서 'false'로 설정된 이 옵션은 게임이 고정값에 프레임률을 잠그는 대신 동적으로 프레임률을 조정할 수 있게 합니다. 이 동적 조정은 게임이 다양한 처리 요구에 적응할 수 있게 하여 전반적인 성능을 향상시킬 수 있습니다.

SmoothedFrameRateRange: 이는 부드러운 프레임률의 목표 범위를 설정하며, 하한은 30 FPS이고 상한은 120 FPS입니다. 게임은 이 범위 내에서 프레임률을 유지하려고 시도하며, 프레임률의 급격한 상승이나 하락을 부드럽게 하여 일관된 게임플레이를 유지합니다.

MinDesiredFrameRate: 이는 프레임률의 최소 임계값으로, 60 FPS에서 설정됩니다. 이는 게임이 최소한 이 프레임률에서 부드럽게 실행되도록 보장하는 기준선입니다.

NetClientTicksPerSecond: 초당 클라이언트 업데이트의 빈도를 120으로 증가시킨 이 설정은 게임 상태가 더 자주 새로고침되게 합니다. 더 자주 업데이트되는 것은 게임플레이의 반응성을 향상시키고 특히 빠른 진행 상황에서 지연을 줄일 수 있습니다.

일단 위와 같은 방식을 적용하기 전/후로 평균적으로 10 프레임 정도의 성능 향상을 확인했으나, 이게 꼭 저것 때문인지 다른 이유인지는 확인되지는 않다. 하지만, 다수의 해외 커뮤니티 의견을 토대로 보면 효과기 있는 것으로 보인다.

* 당연히 서버는 끈 상태에서 변경해 줘야 된다! 또, 설정을 바꾸기 전에 백업은 필수!

원글 링크

서버 자동으로 끄고 키기

(놀랍게도..) 제작사에서도 권하고 있는 방법으로, 현재는 서버를 운영할 때 필수적으로 하는 설정이다. 나 같은 경우에는 매 6시간마다 Restart를 해주고 있으며, 리스타트를 할 때 동시에 서버 업데이트를 확인 + 설치하는 것까지 병행하고 있다.

서버를 운영하는 방법으로는 여러 가지 방법이 있겠지만, 나는 개인적으로 선호하는 Systemd를 이용해서 운영하고 있다. 해당 방법을 이용하면, 서버가 켜졌을 때 지속적으로 해당 프로세스가 띄워져 있는 것을 보장할 수 있다. 간단하게 하는 방법을 설명하면 아래와 같다. 우분투에서 시스템 데몬 파일들은 정해진 스크립트들을 따라서 백그라운드에서 실행되는데, 그 위치는 /etc/systemd/system/이다.

(Name)@(ServerName):/etc/systemd/system$ cat palserver.service 
[Unit]
Description=Pal Server

[Service]
User=$(USER)
WorkingDirectory=/home/$(USER)/Steam/steamapps/common/PalServer
ExecStart=/home/$(USER)/Steam/steamapps/common/PalServer/PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS
Restart=always
RestartSec=180
ExecStopPost=/bin/bash -c '/home/$(USER)/update_palserver.sh'

[Install]
WantedBy=multi-user.target

$(USER)은 자신의 상황에 맞게 작성해면된다. 일반적으로, 위에 (Name)이라고 있는 내용으로 대체하면 된다. 간단하게 스크립트를 설명하면, PalServer가 설치된 곳에 들어가서 팔 서버를 실행시키라는 의미다. 그리고 개발사에서 하라고 하는 여러 옵션들(스레드 쓰기 등등)도 포함되어 있다.

나 같은 경우에 껐다 킬 때마다 Update 쉘을 돌리고 싶어서 해당 내용도 포함해 두었다. 서버가 갑작스럽게 종료되면 업데이트를 자동적으로 진행한다. 그리고 업데이트는 평균 90초 정도 걸려서, 업데이트 시간의 2배의 시간을 줌으로써 안전하게 업데이트하도록 설정해 두었다.

그리고 자동적으로 꺼지게 하고 싶다면 아래 스크립트를 만들고 CRON에 등록하면 된다.(해당 스크립트는 RCON이 설치되어 있어야 하며, 스크립트와 RCON 클라이언트가 같은 위치에 있어야 한다)

#!/bin/sh

RCON_PORT=(본인이 설정한 포트)
ADMIN_PASSWORD=(비밀번호)

echo 'broadcast Auto_Reboot_Initialized_Time_to_take_Rest' | ./RCON -P $RCON_PORT -p $ADMIN_PASSWORD
echo 'save' | ./RCON -P $RCON_PORT -p $ADMIN_PASSWORD
echo "shutdown 300 Server_is_going_to_reboot_in_5_minutes" | ./RCON -P $RCON_PORT -p $ADMIN_PASSWORD

해당 내용은 broadcast로 서버 인원들에게 곧 종료된다고 알린 후 -> 저장 -> 그리고 5분 후에 종료하는 스크립트이다.

해당 내용을 crontab -e를 입력해서 6시간마다 돌리도록 만들면 된다. 대강 모습은 아래와 같을 것이다.

# Cron 기본적은 설명들~~

0 */6 * * * $(해당 스크립트 위치)

위 명령은 모든 날, 요일, 매 6시간마다 0분일 때(정각일 때) 해당 스크립트를 실행시키라는 뜻이다. 우리는 위에 종료를 지시하는 스크립트를 실행시켰기 때문에, 서버는 6시간마다 5분 후 종료될 것이다. 하지만, 걱정 마시라 종료되고 3분 후에 우리는 데몬에 의해서 알아서 다시 서버가 구성될 것이니까.

메모리 누수를 만드는 게임 특성 제거하기

위의 Engine.ini 파일의 위치에 들어가면, PalWorldSettings.ini설정 또한 있다. 해당 파일에서는 서버 내 게임 특성을 변경/제거할 수 있는데 그 내용은 오른쪽 팔월드 공식 사이트에 들어가면 확인할 수 있다. 팔월드 설정파일(Official)

이 중에서 현재 메모리 누수로 가장 주목받는 부분은 기지 습격인데, 해당 부분을 False로 바꿔준다. 즉, bEnableInvaderEnemy=False로 설정을 바꿔준다. ~~(놀랍게도 해당 Config 설정들이 공식 사이트에 설명되어 있지 않다..)~~

또, bIsMultiplay을 True로 변경해 준다. (bIsMultiplay=True, 기본은 False임) 그리고 그 외에, 서버 메모리를 많이 잡아먹는 주범인 아이템 숫자를 제한해 준다. DropItemMaxNum=1500 서버 바닥에 떨어져 있는 아이템 수를 제한하는 것이라 플레이어 입장에서 불편함을 느끼지 않을 것이다. 또, ServerPlayerMaxNum도 자신의 서버가 감당할 수 있을 정도로 제한하자.

커뮤니티나, 서버 운영자들 사이에서 일반적으로 받아들여지는 RAM당 인원은 기본 8G + (인당 2G)이다. 본인의 서버가 12명 정도 상시 들어온다고 하면, 32기가 정도의 렘을 쓰자 그러면 쾌적하게 운영할 수 있을 것이다.

맺으며

이렇게 까지 해도 서버가 최적화가 안된다면.. 어쩔 수 없다. 업데이트를 기다리자.. 현재 서버 프로그램을 살펴보면 Core도 다 사용하지 않고, 멀티코어 지원도 잘 안되며, 절대 나면 안 되는 메모리 누수는 기본은 덤이고 등등 등등 정말 문제가 많다. 하지만, 이번에 돈을 왕창 벌었으니까 앞으로는 어느 정도 해결될 것이라고 본다.

나는 현재 GCP에서 서버를 구성하고 있으며, N2D(4 Core, 24GB) 기준 위와 같은 최적화 및 기타 인프라 설정을 통해 RTT 40, Jitter 4, Packet Loss 0을 평균을 기록하고 있다. 열심히 서버 구성하는 모든 분들에게 도움이 되었기를!

나는 책을 읽으며 살고 싶다

susong — Sun, 19 Nov 2023 21:33:38 +0900

어느 날부터 책을 읽을 수 있는 능력을 잃어버렸다

나는 스스로 독서량이 적다고 생각해오지 않았었다. 그래도 매주 1권 이상 내가 관심 있는 분야의 책을 읽어왔고, 그래서 내 정서적 인내력 혹은 독서능력에 대해서 크게 생각해오지 않았던 것 같다. 하지만, 최근 긴 여행을 다녀오면서 또 회사에 다니면서 나의 여유시간들은 유튜브와 웹서핑이 차지하게 되었고 독서와 반년이상 거리를 두게 되었다.

'출퇴근하니까 지하철에서 어쩔 수 없이' 혹은 '여행 중인데 책을 어떻게 읽어?'같은 생각들이 독서와 나 사이를 이간질했고, 그렇게 나는 책을 읽지 않게 되었다. 그리고 며칠 전 오래간만에 내 생각을 정리할 겸 자유론을 꺼냈는데 하나도 읽을 수 없었다. 글의 문장이 이해가 안 되는 것은 아니었으나, 책의 내용이 머릿속에 들어오지 않았고 매 5분마다 책을 덮을지 말지 고민하는 내 모습을 발견하게 되었다.

혹시 책이 너무 어려워서 그런 것은 아닐까? 라는 자기 위안을 하며 다른 책들도 집어보았지만 상황은 같았다. 나는 집중하지 못했고, 책의 내용은 내 머릿속으로 들어가기보다는 허공에서 맴돌기만 했다. 결국 집중하지 못한 나는 바로 옆에 있는 내 스마트폰에 정신이 팔려버렸고, 나는 책의 서문에 갇혀 본문으로는 들어가 보지도 못하는 바보가 되어버렸다.

도대체 왜 그런걸까?

내게 독서는 크게 특별한 일이 아니었다. 책 읽기가 좋아서 철학과에 갔고, 가서도 특정 분야가 아니라 온갖 지식들을 닥치는대로 읽어왔다. 덕분에, 세상을 보는 눈이 틔였고 인생도 더 재미있게 살고있다고 자신한다. 그렇게 책읽기가 멀지 않았기에 그런 능력을 잃어버렸다는 것에 더욱 충격을 받을 수밖에 없었다. 나의 소중한 부분을 잃고 나서야 나는 도대체 왜 그런 것인지에 대해 찾기 시작했다.

그리고, 왜를 고민하던 중 나는 이전에 읽었던 한 책을 생각해 내게 된다. 책의 이름은 '생각하지 않는 사람들' 내가 20살이었던 2015년 학교 수업 철학명저 읽기에서 첫 번째로 읽었던 책이다. 그때 인터넷을 많이 하면 바보가 된다는 책의 내용은 내가 생각해 오던 진실과 거리가 멀었기 때문에 비판적으로 에세이를 썼던 기억이 났다. 그리고 8년이 지난 지금. 나는 책에 나오는 사람이 되어버리고 말았다.

결과적으로, 나는 자극에 너무나도 익숙해져 버렸다. 무언가에 집중하기 위해서는 하나에 몰두할 수 있어야 하는데, 나는 주변에서 내게 주는 자극에 너무 익숙해져 버린 나머지 하나에 몰두하기보다는 자극을 좇는데 집중했다. 책을 보면서도 내 휴대전화를 5분에 한 번씩 쳐다봐줘야 하고, 나는 그럴 때마다 다시 책의 내용으로 돌아가기 위해서 많은 정신적인 자원을 쓸 수밖에 없었다. 그리고 반복적인 재-집중 자원의 낭비는 나로 하여금 독서를 포기하게 하는 큰 요인으로 발전했다.

나는 책을 읽으며 살고 싶다.

원인이 있으면 해결책도 있는 법. 나는 20살 이후 읽지 않았던 그 책을 다시 손에 잡았다. 그리고 힘들었지만 책을 완독 하고자 큰 노력을 기울였다. 휴대전화는 다른 방에 두었으며 내 집중을 방해할 노래도 듣지 않은 상태에서 독서를 시작했다. 내게 자극을 줄 수 있는 것들을 최대한 배제한 채 독서할 수 있는 환경을 꾸리는데 집중했다. 그렇게, 책을 완독 했고 나는 책을 통해서 앞으로 어떻게 살아야 할지에 대해 다시 고민했다.

나는 원래 SNS랑 담쌓은 사람이었다. 1년 전까지만 해도 인스타 스토리가 뭔지도 몰랐고, 또 인스타에 부메랑 동영상이 뭔지 알게 된 것도 얼마 되지 않았다. 하지만, 너무 모르다 보니까 대화 주제에서 거리가 계속 벌어졌고 한번 이 간극을 메우고자 최근 여행을 가면서 몇몇 SNS들을 시작했다. 아주 본격적으로 한 것들은 아니었지만, 내 일상을 가끔 올리고 친구들의 일상도 살펴봤다.

SNS를 시작하니 누구나 그러하듯, 누가 좋아요를 누르고 누가 내 글을 봤는지 신경 쓰게 되었으며 그것 때문에 SNS에 신경이 집중된 내 모습도 볼 수 있었다. 내 행동은 지극히 자연스러운 인간의 사회적인 행동들이지만, 나는 이런 행동들이 나를 망치고 있다는 것을 깨달았다. 이런 자극들로부터 해방되는 것만이 내가 무언가에 집중할 수 있는 능력을 키울 길이라고 생각한 것이다.

나는 상자의 동물이 되기 싫다.

이전에 스키너의 심리상자라는 책을 읽은 적이 있다. 책은 행동주의 심리학자 스키너가 가진 오해들에 대해서 이야기를 하는데, 가장 인상 깊었던 것은 스키너가 인간의 행동을 어떻게 설명하는지였다. 도구적 조건형성, 즉 처벌과 강화를 통해서 인간의 행동을 설명하는데 나는 최근 내 SNS 하는 모습을 보면서 내가 스키너가 연구를 위해 키운 상자의 동물들이 된 것 같다는 생각이 들었다.

좋아요를 통해서 나를 자극하고, 이를 통해 내가 더욱 좋아요를 갈망하도록 만드는 현대 앱들의 모습은 너무나도 스키너의 상자와 닮아있다. 아무 생각도 하지 않으면 그 앱에서 즐거운 시간을 보낼 수 있지만, 우리는 그 즐거움들 그리고 자극들을 위해 우리가 가장 소중하게 여겨야 할 집중력과 사고력을 내놓고 있는 것이다.

나는 집중하는 사람으로 살고 싶다. 누군가의 가벼운 좋아요보다는 힘들지만 독서를 통해 얻는 지식이 더 좋다. 누군가가 내 삶을 알아주기보다는 내가 내 삶에 대해 더 알고 싶다. 그래서 다시 한번 힘을 내서 SNS와 휴대폰이 주는 자극을 없애보려고 한다.

Bjarne Stroustrup(C++ 창시자)의 C++ Q & A(1)

susong — Sat, 28 Oct 2023 21:41:45 +0900

해당 글은 C++의 창시자인 Bjarne Stroustrup의 블로그 글 중 C++ Q&A를 번역할 글이며, 아래 글의 모든 내용은 링크에서 확인할 수 있습니다. 글을 읽으며 흥미로운 질의응답만을 번역해봤습니다.

코딩 표준을 추천해줄 수 있나요?

추천해주는 코딩 표준

추천하는 코딩 표준은 C++ 코어 가이드라인입니다. 이는 사람들을 효과적인 최신 C++ 스타일로 안내하고 그 규칙을 지원하는 도구를 제공하기 위한 야심찬 프로젝트입니다. 이 프로젝트는 성능 저하나 장황함을 추가하지 않으면서도 완전히 유형 및 리소스 안전성이 보장된 언어로 C++를 사용하도록 권장합니다. 가이드라인 프로젝트를 설명하는 동영상이 있습니다.

(현재 404표시됨, 원래 주소 )

C++ 코딩 표준의 요점은 특정 환경에서 특정 목적을 위해 C++를 사용하기 위한 일련의 규칙을 제공하는 것입니다. 따라서 모든 용도와 모든 사용자를 위한 하나의 코딩 표준은 존재할 수 없습니다. 특정 애플리케이션(또는 회사, 애플리케이션 영역 등)에 대해 좋은 코딩 표준은 코딩 표준이 없는 것보다 낫습니다. 반면에 나쁜 코딩 표준이 코딩 표준이 없는 것보다 나쁘다는 것을 보여주는 많은 사례를 보았습니다.

C++용으로 약간 수정되었더라도 C 코딩 표준을 사용하지 말고, 당시에는 좋았다고 해도 10년 전의 C++ 코딩 표준을 사용하지 마세요. C++는 C가 아니며 표준 C++는 표준 이전의 C++가 아닙니다.

왜 빈 클래스의 사이즈가 0이 아닌가요?

서로 다른 두 객체의 주소가 달라지도록 하기 위해서입니다. 같은 이유로 "new"는 항상 서로 다른 객체에 대한 포인터를 반환합니다.

class Empty { };

void f()
{
    Empty a, b;
    if (&a == &b) cout << "impossible: report error to compiler supplier";
    Empty* p1 = new Empty;
    Empty* p2 = new Empty;
    if (p1 == p2) cout << "impossible: report error to compiler supplier";
}

멤버 함수가 기본적으로 가상이 아닌 이유는 무엇인가요?

많은 클래스가 기본 클래스로 사용하도록 설계되지 않았기 때문입니다. 예를 들어 클래스 복합체를 참조하세요.

또한 가상 함수가 있는 클래스의 객체는 가상 함수 호출 메커니즘에 필요한 공간(일반적으로 객체당 한 단어)을 필요로 합니다. 이러한 오버헤드는 상당히 클 수 있으며, 다른 언어(예: C 및 Fortran)의 데이터와의 레이아웃 호환성을 방해할 수 있습니다.

더 많은 설계 근거는 C++의 설계와 진화를 참조하세요.

소멸자가 기본적으로 가상함수가 아닌 이유는 무엇인가요?

많은 클래스가 베이스 클래스로 사용하도록 설계되지 않았기 때문입니다. 가상 함수는 파생 클래스의 객체에 대한 인터페이스 역할을 하는 클래스(일반적으로 힙에 할당되고 포인터나 참조를 통해 액세스됨)에서만 의미가 있습니다.

그렇다면 언제 소멸자를 가상으로 선언해야 할까요? 클래스에 가상 함수가 하나 이상 있을 때마다. 가상 함수가 있다는 것은 클래스가 파생 클래스에 대한 인터페이스로 작동하도록 되어 있으며, 이 경우 파생 클래스의 객체는 베이스에 대한 포인터를 통해 소멸될 수 있음을 나타냅니다.

class Base {
    // ...
    virtual ~Base();
};

class Derived : public Base {
    // ...
    ~Derived();
};

void f()
{
    Base* p = new Derived;
    delete p;	// virtual destructor used to ensure that ~Derived is called
}

Base의 소멸자가 가상이 아니었다면 Derived의 소멸자가 호출되지 않았을 것이며, Derived이 소유한 자원이 해제되지 않는 등 나쁜 영향을 미쳤을 가능성이 높습니다.

왜 가상 생성자가 존재하지 않나요?

가상 호출은 부분적인 정보가 주어졌을 때 작업을 수행하는 메커니즘입니다. 특히 '가상'을 사용하면 객체의 정확한 유형이 아닌 인터페이스만 알고 함수를 호출할 수 있습니다. 객체를 생성하려면 완전한 정보가 필요합니다. 특히 생성하려는 객체의 정확한 유형을 알아야 합니다. 따라서 "생성자에 대한 호출"은 가상이 될 수 없습니다.

객체를 생성하도록 요청할 때 인다이렉션을 사용하는 기술을 흔히 "가상 생성자"라고 합니다. 이를 위해서는 TC++PL3 15.6.2를 참조하세요.

순수 가상함수란 무엇인가요?

순수 가상 함수는 파생 클래스에서 재정의해야 하며 정의할 필요가 없는 함수입니다. 가상 함수는 "=0" 구문을 사용하여 "순수" 함수로 선언됩니다.

class Base {
public:
    void f1();		// 가상함수 아님
    virtual void f2();	// 가상함수이나 순수하지 않음
    virtual void f3() = 0;	// 순수 가상함수
};

Base b;	// error: pure virtual f3 not overridden

여기서 Base는 추상 클래스이므로(순수 가상 함수를 가지고 있기 때문에) Base 클래스의 객체를 직접 생성할 수 없습니다: Base는 (명시적으로) 베이스 클래스를 의미합니다.

class Derived : public Base {
    // no f1: fine
    // no f2: fine, we inherit Base::f2
    void f3();
};

Derived d;	// ok: Derived::f3 overrides Base::f3

추상 클래스는 인터페이스를 정의하는 데 매우 유용합니다. 실제로 순수한 가상 함수만 있는 클래스를 흔히 인터페이스라고 부릅니다.

// 순수가상함수 만드는 방법
Base::f3() { /* ... */ }

이것은 때때로 매우 유용하지만(파생 클래스에 대한 간단한 공통 구현 세부 사항을 제공하기 위해), 일부 파생 클래스에서는 여전히 Base::f3()을 재정의해야 합니다.

파생 클래스에서 순수 가상 함수를 재정의하지 않으면 해당 파생 클래스는 추상화됩니다:

class D2 : public Base {
    // no f1: fine
    // no f2: fine, we inherit Base::f2
    // no f3: fine, but D2 is therefore still abstract
};

D2 d;	// error: pure virtual Base::f3 not overridden

JAVA에서처럼 "new"를 사용해도 되나요?

하지만 무턱대고 그렇게 하지 마세요. 더 나은 대안이 있는 경우가 많습니다.

void compute(cmplx z, double d)
{
	cmplx z2 = z+d;	// c++ style
	z2 = f(z2);		// use z2

	cmplx& z3 = *new cmplx(z+d);	// Java style (assuming Java could overload +)
	z3 = f(z3);
	delete &z3;	
}

z3에 "new"를 서투르게 사용하는 것은 지역 변수(z2)를 관용적으로 사용하는 것과 비교하면 불필요하고 느립니다. 같은 범위에서 해당 객체를 "삭제"하는 경우 객체를 생성할 때 "new"를 사용할 필요가 없으며, 이러한 객체는 지역 변수여야 합니다.

생성자에서 가상 함수를 호출할 수 있나요?

예, 하지만 주의하세요. 예상한 대로 작동하지 않을 수 있습니다. 생성자에서는 파생 클래스에서 재정의가 아직 일어나지 않았기 때문에 가상 호출 메커니즘이 비활성화됩니다. 객체는 "파생되기 전 베이스"에서 베이스 위로 구성됩니다.

사람들이 내 클래스로부터 파생하는 것을 막을 수 있나요?

네, 하지만 왜 그러고 싶으신가요? 일반적인 대답은 두 가지입니다
- 효율성을 위해: 내 함수 호출이 가상이 되지 않도록 하기 위해
- 안전성을 위해: 내 클래스가 베이스 클래스로 사용되지 않도록 하기 위해

제 경험에 비추어 볼 때, 효율성의 이유는 대개 잘못된 두려움입니다. C++에서 가상 함수 호출은 매우 빠르기 때문에 가상 함수로 설계된 클래스를 실제로 사용해도 일반 함수 호출을 사용하는 대체 솔루션에 비해 측정 가능한 런타임 오버헤드를 발생시키지 않습니다. 가상 함수 호출 메커니즘은 일반적으로 포인터나 참조를 통해 호출할 때만 사용된다는 점에 유의하세요. 명명된 객체에 대해 함수를 직접 호출할 때는 가상 함수 클래스 오버헤드를 쉽게 최적화할 수 있습니다.

가상 함수 호출을 피하기 위해 클래스 계층 구조를 "제한"할 필요가 정말로 있다면, 애초에 왜 해당 함수를 가상으로 만들었는지 의문을 가질 수 있습니다. 저는 성능에 중요한 함수를 "우리가 보통 그렇게 하는 방식"이라는 이유만으로 아무런 이유 없이 가상으로 만든 사례를 본 적이 있습니다.

왜 C++는 이종 컨테이너를 지원하지 않나요?

C++ 표준 라이브러리는 유용하고 정적으로 형식이 안전하며 효율적인 컨테이너 세트를 제공합니다. 벡터, 리스트, 맵(map)이 그 예입니다

vector<int> vi(10);
vector<Shape*> vs;
list<string> lst;
list<double> l2
map<string,Record*> tbl;
map< Key,vector<Record*> > t2;

이러한 컨테이너는 모든 좋은 C++ 교과서에 설명되어 있으며, 특별한 이유가 없는 한 배열 및 "홈 쿠킹" 컨테이너보다 선호되어야 합니다.
이러한 컨테이너는 동질적입니다. 즉, 동일한 유형의 요소를 담습니다. 컨테이너에 여러 다른 유형의 요소를 담으려면 이를 합집합으로 표현하거나 (일반적으로 훨씬 더 나은) 다형성 유형에 대한 포인터의 컨테이너로 표현해야 합니다. 고전적인 예는 다음과 같습니다

vector<Shape*> vi;	// vector of pointers to Shapes

여기서 vi는 Shape에서 파생된 모든 유형의 요소를 담을 수 있습니다. 즉, vi는 모든 요소가 Shape(정확히 말하면 Shape에 대한 포인터)라는 점에서 동질적이고, 원, 삼각형 등과 같은 다양한 Shape의 요소를 포함할 수 있다는 점에서 이질적입니다.

따라서 컨테이너를 사용하려면 사용자가 의존할 수 있는 모든 요소에 대한 공통 인터페이스가 있어야 하므로 어떤 의미에서 모든 컨테이너(모든 언어)는 동질적입니다. 이질적인 것으로 간주되는 컨테이너를 제공하는 언어는 모두 표준 인터페이스를 제공하는 요소의 컨테이너를 제공할 뿐입니다. 예를 들어 Java 컬렉션은 객체(참조)의 컨테이너를 제공하며, 사용자는 (공통) 객체 인터페이스를 사용하여 요소의 실제 유형을 검색할 수 있습니다.

C++ 표준 라이브러리는 동종 컨테이너를 제공하는데, 이는 대부분의 경우 사용하기 가장 쉽고, 컴파일 시 오류 메시지를 가장 잘 제공하며, 불필요한 런타임 오버헤드가 발생하지 않기 때문입니다.

C++에서 이기종 컨테이너가 필요한 경우 모든 요소에 대한 공통 인터페이스를 정의하고 해당 요소로 컨테이너를 만드세요

class Io_obj { /* ... */ };	// the interface needed to take part in object I/O

vector<Io_obj*> vio;		// if you want to manage the pointers directly
vector< Handle<Io_obj> > v2;	// if you want a "smart pointer" to handle the objects

표준 컨테이너들은 왜 이렇게 느린가요?

그렇지 않습니다. 아마도 "무엇과 비교해서?"라는 질문이 더 유용한 대답일 것입니다. 사람들이 표준 라이브러리 컨테이너 성능에 대해 불평할 때, 저는 보통 세 가지 진짜 문제(또는 많은 오해) 중 하나를 발견합니다

- 복사 오버헤드가 발생한다.
- 조회 테이블의 속도가 느립니다.
- 수작업으로 코딩한 list이 std::list보다 훨씬 빠릅니다.

최적화를 시도하기 전에 성능에 진짜 문제가 있는지 고려하세요. 저에게 보내온 대부분의 경우 성능 문제는 이론적이거나 가상의 문제입니다: 먼저 측정한 다음 필요한 경우에만 최적화합니다.

이러한 문제를 차례로 살펴봅시다. 종종 벡터<X>가 누군가의 특수한 My_container<X>보다 느린 경우가 있는데, 그 이유는 My_container<X>가 X에 대한 포인터의 컨테이너로 구현되기 때문입니다. 표준 컨테이너는 값의 복사본을 보관하고 컨테이너에 값을 넣으면 값을 복사하기 때문입니다. 이는 기본적으로 작은 값에는 문제가 없지만 거대한 객체에는 상당히 부적합할 수 있습니다:

vector<int> vi;
vector<Image> vim;
// ...
int i = 7;
Image im("portrait.jpg");	// initialize image from file
// ...
vi.push_back(i);	// put (a copy of) i into vi
vim.push_back(im);	// put (a copy of) im into vim

이제 portrait.jpg가 몇 메가바이트이고 이미지에 값 의미론(즉, 복사 할당 및 복사 구조가 복사본을 만드는 것)이 있는 경우 vim.push_back(im)은 실제로 비용이 많이 듭니다. 하지만 속담처럼 너무 아프면 그냥 하지 마세요. 대신 핸들 컨테이너나 포인터 컨테이너를 사용하세요.

예를 들어 Image에 참조 시맨틱이 있다면 위의 코드는 복사 생성자 호출 비용만 발생하며, 이는 대부분의 이미지 조작 연산자에 비하면 사소한 비용일 것입니다. Image와 같은 일부 클래스에 정당한 이유로 복사 시맨틱이 있는 경우 포인터 컨테이너가 합리적인 해결책이 될 수 있습니다

vector<int> vi;
vector<Image*> vim;
// ...
Image im("portrait.jpg");	// initialize image from file
// ...
vi.push_back(7);	// put (a copy of) 7 into vi
vim.push_back(&im);	// put (a copy of) &im into vim

당연히 포인터를 사용하는 경우 리소스 관리에 대해 생각해야 하지만, 포인터 컨테이너는 그 자체로 효과적이고 저렴한 리소스 핸들이 될 수 있습니다(종종 "소유된" 객체를 삭제하기 위해 소멸자가 있는 컨테이너가 필요합니다).

두 번째로 자주 발생하는 실제 성능 문제는 많은 수의 (문자열,X) 쌍에 map<string,X>(이하 맵)을 사용하는 경우입니다. 맵은 비교적 작은 컨테이너(예: 수백 개 또는 수천 개의 요소 - 10000개의 요소로 구성된 맵의 요소에 액세스하려면 약 9번의 비교가 필요함)에 적합하며, 그보다 작으면 비용이 적게 들고 좋은 해시 함수를 구성할 수 없는 경우에 적합합니다. 문자열이 많고 해시 함수가 좋은 경우 해시 테이블을 사용하세요. 표준 위원회의 기술 보고서에서 나온 unordered_map은 현재 널리 사용 가능하며 대부분의 사람들이 직접 만든 것보다 훨씬 낫습니다.

때로는 (문자열,X) 쌍이 아닌 (const char*,X) 쌍을 사용하여 속도를 높일 수 있지만, <는 C 스타일 문자열에 대해 사전 비교를 수행하지 않는다는 점을 기억하세요. 또한 X가 크면 복사 문제도 발생할 수 있습니다(일반적인 방법 중 하나로 해결).

Intrusive lists는 정말 빠를 수 있습니다. 그러나 목록이 꼭 필요한지 생각해 보세요. 벡터는 더 콤팩트하므로 삽입과 지우기를 할 때에도 많은 경우 더 작고 빠릅니다. 예를 들어, 논리적으로 몇 개의 정수 요소로 구성된 목록이 있는 경우 벡터가 목록(모든 리스트)보다 훨씬 빠릅니다. 또한 내장형 리스트는 내장형을 직접 보유할 수 없습니다.

따라서 정말로 목록이 필요하고 모든 요소 유형에 대해 링크 필드를 제공할 수 있다고 가정해 보겠습니다. 기본적으로 표준 라이브러리 목록은 할당 후 요소를 삽입하는 각 연산에 대한 복사(그리고 요소를 제거하는 각 연산에 대한 할당 해제)를 수행합니다. 기본 할당자를 사용하는 std::list의 경우 이 작업이 중요할 수 있습니다. 복사 오버헤드가 크지 않은 작은 요소의 경우 최적화된 얼로케이터를 사용하는 것이 좋습니다. 목록과 마지막 1온스의 성능이 필요한 경우에만 수작업으로 만든 침입형 목록을 사용하세요.

사람들은 때때로 std::벡터의 비용이 점진적으로 증가하는 것에 대해 걱정합니다. 저도 그런 걱정을 하곤 했고, reserve()를 사용해 증가를 최적화했습니다. 코드를 측정하고 실제 프로그램에서 reserve()의 성능 이점을 찾는 데 반복적으로 어려움을 겪은 후, 반복자 무효화(제 코드에서는 드문 경우)를 피하기 위해 필요한 경우를 제외하고는 사용을 중단했습니다. 다시 한 번 강조하지만 최적화하기 전에 측정하세요.

"friend" 는 캡슐화에 위반되나요??

아니요, 그렇지 않습니다. "친구"는 멤버십과 마찬가지로 접근 권한을 부여하기 위한 명시적인 메커니즘입니다. 표준 준수 프로그램에서는 소스를 수정하지 않고 클래스에 대한 액세스 권한을 직접 부여할 수 없습니다.

class X {
    int i;
public:
    void m();		// grant X::m() access
    friend void f(X&);	// grant f(X&) access
    // ...
};

void X::m() { i++; /* X::m() can access X::i */ }

void f(X& x) { x.i++; /* f(X&) can access X::i */ }

왜 C++은 포인터와 레퍼런스 둘 다 가지고 있나요?

C++는 C에서 포인터를 상속받았기 때문에 심각한 호환성 문제를 일으키지 않고는 포인터를 제거할 수 없었습니다. 참조는 여러 가지 용도로 유용하지만, C++에서 참조를 도입한 직접적인 이유는 연산자 오버로딩을 지원하기 위해서였습니다. 예를 들어

void f1(const complex* x, const complex* y)	// without references
{
    complex z = *x+*y;	// ugly
    // ...
}

void f2(const complex& x, const complex& y)	// with references
{
    complex z = x+y;	// better
    // ...
}

보다 일반적으로 포인터의 기능과 참조의 기능을 모두 갖고 싶으면 C++에서처럼 두 개의 다른 유형이 필요하거나 단일 유형에 대해 두 개의 다른 연산 집합이 필요합니다. 예를 들어 단일 유형에서는 참조된 객체에 할당하는 연산과 참조/포인터에 할당하는 연산이 모두 필요합니다. 이 작업은 별도의 연산자를 사용하여 수행할 수 있습니다(Simula에서와 같이). 예를 들어

Ref<My_type> r :- new My_type;
r := 7;			// assign to object
r :- new My_type;	// assign to reference

또는 타입 검사(오버로딩)에 의존할 수도 있습니다:

Ref<My_type> r = new My_type;
r = 7;			// assign to object
r = new My_type;	// assign to reference

Call-by-value를 써야하나요? 아니면 Call-by-reference를 써야하나요?

이는 달성하려는 목적에 따라 다릅니다
- 전달된 객체를 변경하려면 참조로 호출하거나 포인터를 사용하세요(예: void f(X&) 또는 void f(X*));
- 전달된 객체를 변경하고 싶지 않고 크기가 큰 경우, 상수 참조로 호출합니다(예: void f(const X&));
- 그렇지 않으면, 값으로 호출합니다; 예: void f(X);

"크다"는 게 무슨 뜻일까요? 두 단어보다 큰 모든 것을 의미합니다.

인자를 변경해야 하는 이유는 무엇인가요? 그래야 하는 경우도 있지만, 새로운 값을 생성하는 대안이 있는 경우도 많습니다. 생각해봅시다

void incr1(int& x);	// increment
int incr2(int x);	// increment

int v = 2;
incr1(v);	// v becomes 3
v = incr2(v);	// v becomes 4

독자의 입장에서는 incr2()가 더 이해하기 쉽다고 생각합니다. 즉, incr1()은 실수와 오류로 이어질 가능성이 더 높습니다. 따라서 새 값을 생성하고 복사하는 데 비용이 많이 들지 않는 한 값을 수정하는 스타일보다 새 값을 반환하는 스타일을 선호합니다.

인수를 변경하고 싶은데 포인터를 사용해야 하나요, 아니면 참조를 사용해야 하나요? 확실한 논리적 이유를 모르겠습니다. '객체가 아닌 것'(예: 널 포인터)을 전달하는 것이 허용되는 경우 포인터를 사용하는 것이 합리적입니다. 제 개인적인 스타일은 객체를 수정하고 싶을 때 포인터를 사용하는 것인데, 어떤 상황에서는 포인터를 사용하면 수정이 가능하다는 것을 더 쉽게 알아차릴 수 있기 때문입니다.

또한 멤버 함수의 호출은 본질적으로 객체에 대한 참조 호출이므로 객체의 값/상태를 수정하려는 경우 멤버 함수를 사용하는 경우가 많다는 점에 유의하세요.

C++에서 "this"가 참조가 아닌 이유는 무엇인가요?

"this"는 참조가 추가되기 전에 C++에 도입되었기 때문입니다(실제로는 클래스가 있는 C에 도입되었습니다, 최초의 C++ 원형). 또한 (나중에) Smalltalk에서 "self"를 사용하는 대신 Simula 사용법을 따르기 위해 "this"를 선택했습니다.

나의 첫 취업준비 기록

susong — Fri, 1 Sep 2023 01:02:24 +0900

내 첫 번째 취직의 결과는 25 지원, 12 서류 합격, 9 면접 참여, 9 합격으로 마무리되었다.

나의 첫 취준을 회고하며

내가 내 첫 이력서를 작성한 지 8주가 지났다. 내 첫 이력서는 프로그래머스에서 작성한 이력서인데, 지금 다시 한번 살펴보니 얼기설기 불필요한 말들이 잔뜩 들어가 있는 불필요한 이력서인 것이 이제는 보인다.(이런 이력서를 봐주고 조언해 주신 멘토님 한 분 한 분에게 정말 감사드린다) 폭풍 같았던 8주 간 나는 25곳의 회사에 나를 뽐냈고, 12곳에서 나를 만나보고 싶다고 이야기했으며, 면접 일정상 9곳의 면접을 진행했다. 또, 최종적으로는 9곳의 최종 오퍼를 받아 회사를 선택할 수 있게 되었다. 오늘 글을 통해 짧았지만, 폭풍 같았던 나의 취준 이야기를 풀어보려고 한다.

한파에 내동겨쳐지다.

올해 취직은 유독 추웠다. 구직 시장에 채용 공고가 작년에 비해 너무 없어서 기사를 살펴보면 암울한 기사들만 가득하고, '아 지금이 겨울인가 겨울에 잘못 걸렸다 내 인생!' 하는 생각만 가득 들게 하는 한 해였다. 특히, 올해 신입 채용 시장은 정말 추웠던 것 같다. 모두 경력직만 원하고 신규는 원하지 않는 세상. 연봉 1억 보장→3500만 원… ‘개발자 우대’ 옛말 된 까닭 기사 제목만 봐도 암울한 채용시장을 알 수 있는 것 같다. 저 기사에 나오는 부트캠프 출신 A가 나인 것 같고 힘이 날만한 기적적인 일들은 거의 없었다.

'아 세상이여 왜 이때 내가 42 서울 멤버를 달게 하셨습니까!' 2년 아니 1년만 빠르게 멤버를 달았어도 훨씬 좋은 조건에서 구직을 할 수 있었을 텐데! 왜 내가 딱 멤버를 달고 개발자로 세상에 나서니 세상이 이렇게 추운 것인지 정말 세상이 원망스러웠다. 분명 내가 원하는 직군에서 작년에 사람인, 원티드를 켜면 넘쳐나던 공고는 모두 자취를 감추고 조건 몇 개만 달면 한 자릿수로 떨어지는 공고의 수는 스스로를 심적으로 위축되게 했다. '진짜 딱 1년만 빨랐어도.. 아니 내가 군대를 안 갔다면 아니 내가 장교를 안 갔다면?' 하는 부정적인 감정에 스스로를 가두었던 순간들도 분명히 있었다.

하지만, 그렇다고 절망하기에는 내 20대가 아깝지 않은가. 나는 불만은 구석에 두고 빠르게 내 살 길을 찾기 시작했다. 이력서를 쓰기 시작했고, 또 내 장점이 무엇인지 확인하기 시작했다. 내 지나온 인생을 정리하고 내가 남들보다 뭐가 돋보일까 혹은 내가 무엇을 잘하는지 하나하나씩 적어가기 시작했다. 분명 하늘이 무너져도 솟아날 구멍은 있을 텐데, 아무리 힘들어도 어떻게든 해낼 수 있을 것이라는 자신감 하나로만 준비를 시작했다.

나는 무엇이 장점인가?

'지피지기면 백전불퇴라' 내가 어떤 일을 성공하기 위해서는 '나'라는 인물을 객관적으로 볼 필요가 있다. 과연 나는 어떤 장점이 있을까? 또, 내 장점 중에 개발자로서 매력적인 것들은 무엇이 있을까? 하는 고민은 일주일 동안 진행했다. 물론, 이 과정은 혼자 진행하지 않았다. 42 서울에서 이제는 멘토링을 진행하지 않으시지만, 우리 교육생들에게 관심이 많은 여러 멘토분들의 도움을 받아서 진행할 수 있었다. (이 글을 빌어 한날 멘토님, 배권한 멘토님, 루비 멘토님에게 큰 감사를 드린다)

멘토링과 별개로도 신입 개발자를 뽑을 때 어떤 점들을 중점적으로 보는지 선배 지인 개발자들의 이야기를 들었고, 또 그 이야기를 바탕으로 내 캐릭터 중 어떤 것들을 깊이 있게 서술할지 정했다. 여러 고민의 결과, 나는 크게 5가지를 이용하여 내 장점을 서술하기로 마음먹었고 그 특징들은 다음과 같다.

1. 한양대 출신이며, 그렇기 때문에 어느 정도 성실성은 보장되는 사람이다. - 성실함

2. 철학과 출신이자 인문 소프트웨어 출신이다. 나는 인공지능 윤리를 공부하다가 기술 그 자체에 매력을 느껴 소프트웨어를 다중전공한 융합형 인재이다. 나는 일을 할 때 기술뿐만 아니라 왜?라는 것에 집중할 수 있는 사람이다. - 융합형

3. 나는 장교(여단급 참모과장) 출신이며, 그렇기 때문에 리더십 및 팔로어십 모두를 갖추고 있는 사람이다. 또, 장교이기 때문에 신분이 보장된 사람이다.(학폭, 범죄자는 장교 불가능) - 리더십, 팔로우십

4. 나는 7개 웹 프로젝트를 리딩해봤고, 해당 프로젝트는 모두 MAU가 충분히 나오는 현재 사용 중인 프로젝트이다. 그 프로젝트들은 내가 불편해서 만들었고, 모든 프로젝트는 기획부터 개발, 운영까지 모두 진행했다. - 문제 해결 능력

5. 나는 42 서울의 멤버다. 즉, 나는 기술을 배울 줄 아는 사람이다. 나는 가져다 쓰기만 하는 사람이 아니다. 시스템콜부터 바닥부터 구현할 줄 알고 또 어떤 기술이든 주어지면 빠르게 익혀서 바로 쓸 줄 아는 사람이다. - 자기 주도적, 기술적 완성도

외부인으로서 나를 마주하는 경험

나도 나를 관조하는 긴 시간이 아니었다면, 나를 꾸미는 방법을 알 수 없었을 것 같다. 하지만, 나는 여러 멘토님들의 도움 그리고 동료 카뎃, 멤버들의 도움 덕분에 '나'라는 사람을 살펴볼 수 있었다. 내가 생각한 나와 남이 생각하는 나는 다르다. 그 간극을 줄이고 나를 객관적으로 살펴보는 것이 취준생으로서는 가장 먼저 해야 하는 일 같다. 살펴보면 어떤 사람은 충분한 능력을 갖추고도 자신이 너무 부족하다고 느껴 면접에 주눅 드는 반면, 어떤 사람은 아무것도 하지 않고 자신감만 가득 찬 사람들도 있는 것 같다.

위의 두 자세는 취직할 때 좋은 자세는 아니라는 생각이 든다. 내가 생각하기에 가장 중요한 것은 나를 제대로 마주하는 것이다. 내가 누군지 알아야 나를 남에게 소개할 수 있다. 스스로도 모르면서 스스로를 어떻게 남에게 소개하고 팔 수 있을 것인가? 스스로를 아는 과정은 너무나도 고통스럽지만 그 과정에서 나는 얻은 것이 많다고 생각한다.

나를 스스로 평가하는 것 그리고 그 과정에 나에 대한 정보를 외부에 공개하는 것 모두 용기가 있어야만 진행할 수 있다. 솔직히 나도 내 자소서를 보여주고 다닐 때 그리고 나에 대해 이야기하고 스스로를 평가받을 때 너무 부끄러웠다. 누군들 부끄럽지 않으랴. 또 누군들 스스로를 그렇게 내보이고 싶을까. 나에 대해 남에게 평가받는 순간은 마치 나체로 누군가를 마주하는 것과 같다. 하지만, 그 과정은 필요하고 꼭 한 번은 해야 스스로를 알 수 있다. 나를 내보이고 또 평가받아라 그래야 나의 자아와 타인이 보는 나를 동기화할 수 있다.

세상에 의연해지자

취준을 하면서 스스로 가장 느꼈던 것들은 스스로의 의연함을 길러야 된다는 것이다. 운 7기 3이라는 말도 있지 않은가? 취직의 과정도 똑같다고 생각된다. 아무리 내가 좋은 사람이라도 그 회사에 맞지 않으면 거절될 수 있는 것이고 또 아무리 내가 부족한 사람이라도 나를 필요로 하는 회사라면 뽑힐 수 있다. 결과에 너무 민감 해하지 말자.

나는 인생 처음으로 넣은 자소서를 아무도 읽어주지 않았다. 여러 취업 공고를 고르고 골라서 내가 가장 가고 싶은 회사 단 하나에 넣었는데 일주일이 지나도 열람되자 않는 그 기분. 마치 열심히 포장한 내 선물을 그 누구도 열어주지 않는 기분. 일주일이 지나고 자동적으로 내 이력서가 취소되었을 때, 그날 저녁 아쉬움과 원망을 삼키기 위해 부지런히 술을 마셨다. 내 이력서를 아무도 열어주지 않았다는 소외감. 그리고 그 회사에 대한 원망을 술에 담느라 그날 저녁은 술맛도 모르고 열심히 마셨다.

첫 이력서를 그렇게 보내고 이후에도 지속적으로 읽히지 않은 이력서들은 존재했다. 하지만, 그 이후에는 크게 개의치 않았다. 원래 첫 아픔이 가장 아프고 그 뒤는 무뎌진다고 하지 않는가? 그냥 그러려니 했다. 최종적으로 내 25개의 이력서 지원중 8개는 끝까지 읽히지 않았다. 내게는 소중한 순간순간의 지원이었지만, 아마도 그 지원서들은 네트워크상의 쓰레기 데이터로 남겨졌으리라. 하지만, 이제는 그러려니 한다. 취준의 기간들이 나를 이렇게 의연하게 만들어준다.

서류에 탈락한다고, 서류가 읽히지 않는다고 너무 슬퍼하지 말자. 그 회사는 어차피 나랑 안 맞는 신 포도였을 뿐이리라

나를 증명하는 것은 내가 보여줄 수 있는 것이다.

서류에 합격하고, 면접에 나서면서 가장 많이 느낄 수 있었던 것은 '나를 표현하는 방법을 더 길러야 되겠다'라는 것이다. 면접관은 나를 모른다. 나도 면접관을 모른다. 면접은 마치 하나의 소개팅 장소처럼 서로 간을 보면서 상대에 대해 평가하는 순간들인 것이다. 물론 그 소개팅 자리의 운동장은 매우 기울어져있을지언정 말이다.

나를 표현하기 위해서는 내가 가지고 있는 무기가 강해야 된다. 다행히도 나는 주소창만 치면 바로 볼 수 있는 수많은 웹서비스라는 +7강 무기를 가지고 있었고, 나의 수많은 발표 경험들 그리고 그 모든 것들이 남아있는 유튜브 채널은 나의 갑옷처럼 받쳐주었다. 결국 나를 증명하기 위해서는 말 그 이상이 필요한 것이다. 나는 다행히도 경력이 없는 1 렙 뉴비였지만, 수많은 무기 제련에 성공하였고 덕분에 대부분의 면접은 즐거움만이 가득할 수 있었다.

내가 어떤 사람인지 설명하기보다 내가 어떤 사람인지 보여주는 것이 좋다고 생각된다. 백문이 불여일견이라고 하지 않는가. 한참 동안 내가 얼마나 대단한 사람이고 당신 팀에 기여할 수 있는지 떠드는 것보다 내가 어떤 것을 했고, 이를 바탕으로 팀에서 어떤 것을 할 수 있는지 말하는 것이 훨씬 도움이 된 것 같다. 많은 서비스를 만들어보고 또 코드를 치자. 결국 내가 증명할 수 있는 것은 내가 보여줄 수 있는 것이기에

내가 다르다면 그것은 장점이 될 수도 있다.

나는 장교출신이고 본 전공은 문과다. 문과 출신인 사람은 여럿 봐왔지만, 장교출신은 크게 많지 않았다. 42 서울에서도 2명 정도만 알고 지내는 것 같다. 사실 개발직군을 선택한 사람 중에 장교출신은 거의 없기 때문에 장교 출신의 개발자를 보는 것이 힘든 것도 당연하다.(대부분의 컴공 전공자들은 장교가 아닌 전문연, 대체근무를 선택한다)

처음에 나는 이 장교라는 경력을 어떻게 사용해야 될지 몰라서 내 이력서 한복판에 작게 작성했었다. 장교출신 개발자들은 많지 않았고, 그렇기 때문에 이 경력이 크게 도움이 되지 않을 것이라고 판단했기 때문이다. 하지만 웬걸, 취직 필드에 나가보니 내 장교라는 이력은 생각보다 많은 관심을 받게 되었다.

아주아주 가끔이었지만, 장교 선배 개발자가 면접에 들어오는 경험도 가질 수 있었고, 또 대부분의 사람들은 내가 장교를 하고 나서 개발자로 전직한 것에 대해서 상당한 관심을 기울였다. 덕분에 나는 면접관의 관심을 끌기에 시간을 많이 쓰지 않아도 되었고, 나 스스로를 뽐내는 것에 면접시간 대부분을 할애할 수 있었다.(면접관의 흥미를 끌기 위해 노력하는 면접자와 다르게 말이다)

스스로가 너무 다르다고 생각하면, 다른 점에서 좋은 점을 잘 찾아보자. 나는 개발과 완전 관련 없어 보이는 장교라는 출신에서 내 장점을 뽑아내려 노력했다. 내 마지막 면접에서 CTO가 했던 질문이 특히 기억에 남는다. "장교라는 경험이 우리 회사에서 어떻게 발현될 수 있을까요?"라는 질문을 받았고 나는 '참모과장으로 해왔던 경험은 리더의 의도를 파악하고 실행하는데 매우 능숙하다. 또, 사람들을 이끌고 리더가 하고 싶으나 할 수 없는 말을 할 수 있다'라는 방식으로 스스로 어필했고 덕분에 합격했다. 내가 너무 다르다고 주눅 들지 말자 다른 것은 스스로의 경쟁력이 될 수 있다.

기억에 남는 면접관들

면접을 여러 군데를 다니면서 기억에 남는 면접관 분들이 많다. 취직을 준비하면서 인사팀은 몰라도 면접관은 늘 좋았던 것 같다. 요즘 회사에서 사람을 많이 뽑아주지 않다 보니 사람 한 명을 뽑더라도 좀 잘 뽑아보려고 하는 모습을 많이 봤던 것 같다. 또, 단순히 면접을 의무감으로 하는 것보다 '나'라는 면접자의 인생에 공감하고 맥락을 이해하려고 해 주셨던 많은 면접관 분들에게 감사한다.

특히, 회사 포지션 제안은 고사했지만 아직도 계속 연락이 되는 많은 면접관분들에게 감사한다. 특히 자신의 회사가 마음에 안 든다면 다른 회사라도 오퍼 받아주겠다고 하셨던 분들도 계셨는데, 이럴 때 보면 참 인복이 많았다고 생각이 든다. 특히, 회사에서는 면접비를 안 챙겨준다면서 사비로라도 면접비를 챙겨주셨던 모 회사의 이사님께는 늘 감사드린다.

면접을 보기 위해 회사를 다니면서, 또 실제 사회의 요구에 맞닿으면서 여러 면접관분들에게 많은 것들을 배울 수 있었다. 면접관이기 이전에, 현업에 계신 선배이자 개발자로서 감사드린다.

한 면접이 끝나고 최종오퍼를 고사한 다음날 면접관 한분에게 연락을 받은 기억이 있다. 면접을 진행하면서, 면접관을 적대하지 않고 배우려는 모습이 좋아 보여서 뽑았는데 왜 안 오냐는 전화였는데, 사실 면접관분이 전화 올 줄은 몰라서 당황했던 기억이 난다. 또 기억을 살펴보면, 그 면접은 면접이 아니라 하나의 수업으로 기억이 남는 것에서 또 당시에는 가고 싶었던 회사였던 점에서 더욱 답변하기 어려웠던 기억이 난다. 개인적인 사정을 말씀드리고 아쉬움과 함께 전화통화는 좋게 마무리되었지만, 그 강렬한 통화와 면접은 아직도 기억에 남는다.

나 또한 계속 일을 하다 보면, 언젠가 면접관으로 들어가게 될 텐데 나도 그때 그 면접과 불처럼 누군가의 기억에 남는 좋은 면접관으로 성장해야겠다는 하나의 목표를 가지게 되었다. 그리고 언젠가 다시 한번 면접을 볼 때면 더욱 긴장하지 말고, 적대하지 말고 좋은 동료가 될 사람으로서 면접을 봐야겠다는 생각을 했다.

내가 원하는 것은 무엇인가?

왜 돈을 버는 걸까? 단순히 돈을 벌기 위해서 돈을 버는가? 혹은 생존을 위해서?

나는 직장생활은 단순히 돈 버는 것 이상 이어야 된다고 생각한다. 그래서 나는 외국계 대기업을 선택했다. 사실 내가 선택한 이 회사보다 돈 많이 준다는 곳, 또 복지가 더 좋은 곳도 있었다. 하지만, 나는 돈 혹은 복지보다 내 5년 후를 생각해서 지금 계약한 회사를 선택하게 되었다.

구직을 시작할 때는 '일단 회사! 나를 원하는 곳으로 들어가자!'라고 생각하지만 이곳저곳 붙기 시작하면 '그래서 내가 원하는 게 뭐지?'에 대해 고민하게 된다. 나는 우리나라만이 아닌 외국에서도 일하고 싶었고, 또 한국사회가 아닌 다른 사회의 사람들과도 소통하고 싶었다. 그래서 이 회사를 선택했고, 결정하게 되었다. 취준을 시작할 때는 아니더라도 내가 왜 일을 하는지에 대해서는 다들 고민해 보면 좋을 것 같다. 스스로의 의도와 의지가 함께하면 더 즐겁게 일할 수 있지 않겠는가?

쓰고 싶은 이야기는 많지만

글이 너무 길어지는 것은 지양하고 싶기에 글을 이만 줄이려고 한다. 8주의 길다면 길고, 짧다면 짧은 취준생활. 사회가 요구하는 것이 무엇인지 그리고 학생으로서 그리고 취준생으로서 필요한 것이 무엇인지 정확하게 배울 수 있는 배움의 시간이었던 것 같다.

또, 취직기간은 나 스스로 거절에 스트레스받지 않고 의연하게 대처할 수 있게 스스로를 성장시킬 수 있는 하나의 기회였다. 내 주변의 많은 능력 좋은 동료들도 모두 좋은 소식만 함께하기를 간절히 바라며 취준 기간 동안 스스로를 응원하기 위해서 수없이 들었던 노래 한 곡과 함께 글을 마친다.

42 내 공유우산 프로젝트 회고(42OpenUmbrella)

susong — Fri, 11 Aug 2023 15:20:12 +0900

또 하나의 프로젝트를 마치며

42 내에서 진행한 프로젝트가 벌써 6개가 되었다. 하나하나 다들 사랑받는 서비스로 성장하고 있어서 뿌듯하면서도, 요즘은 너무 많이 개발했나?라는 생각도 들곤 한다. 특히, 요즘 몇몇 분들이 내게 '42 내에서 몇 개의 서비스를 했냐고' 묻지 않고 '몇 개의 서비스에 참여하지 않았냐고' 물어볼 때는 깜짝 놀라기도 했다. 그래서 막상 세보니 42 내부에서 작동하는 웹서비스 9개 중 5개에 리딩 혹은 인볼브 한 흔적이 있어서, 정말 많이 참여했구나라는 생각과 동시에 잘 살았구나 하는 생각이 들었다.

이번 프로젝트는 장마 기간에 공유우산을 42 일원들에게 제공해주자는 생각으로 진행된 프로젝트였다. 42 내에는 좋은 커뮤니티 일원들이 많고, 그중 jmaing님이 자신의 사비를 들여서 클러스터(42에서는 센터를 클러스터라고 부른다)에 공유우산 50개를 기부해 주셨다. 하지만, 공유지의 비극이라는 말처럼 이 공유우산에 적절한 관리수단이 없으면 고장 날 것은 당연지사. 이 공유우산이 잘 사용될 수 있도록 웹 서비스로 관리 서비스를 만드는 것이 우리의 목표였다.

Nest에서 Fast API로

가장 자신있는 백엔드 프레임워크가 뭐야!라고 물으면 Nest.JS를 대답할 수 있을 것 같다. 해당 프레임워크로 깔끔하게 서비스도 여러 번 제작해 보았고, 또 여러 번 해봤기 때문에 어떻게 써야 편하게 쓸 수 있는지 알기 때문이다. 또한, 플로우가 비슷하다면 이전에 사용했던 코드들을 가져다가 쓸 수 있기 때문에 사실 Nest로 개발했다면 정말 빠르게 개발할 수 있었을 것이다. 하지만, 나는 그렇게 하기 싫었다.

42의 후보생 과정을 거치면서 내가 얻은 가장 소중한 지식은 '새로운 것을 배우는 방법에 대한 앎'이다. 42에서는 어떤 기술이든 배우고 싶을 때 빠르게 배울 수 있도록 하는 소프트스킬과 접근법 등을 모두 제공해주었는데, 이 방법을 사용하지 않는 것은 낭비라고 생각이 들었기 때문이다. 그래서 나는 Nest로 약 80% 정도 개발을 하다가 마지막에 가서 갑자기 FAST API로 프레임워크를 엎어버렸다. 이번 프로젝트는 같이 개발하는 팀원이 없었고, 나 혼자 개발하고 있다 보니까 그 오버헤드를 나만 감당하면 되었기에 할 수 있었던 선택이었던 것 같다.

그래서, 고작 그런 이유로 Fast API로 개발하게 되었다. 새로운 것을 배우고 싶다는 열망을 통해서 이미 개발하던 것을 엎어버린 것이다. 지금 생각해도 별종같은 판단이었지만, 그렇기 때문에 많이 배울 수 있었다.

위는 Fast API 레포지토리, 아래는 Nest.js 레포지토리

새로운 기술로의 도전

Python으로 백엔드를 개발하는 것은 쉽지만은 않았다. 일단 가장 먼저 다가온 벽은 파이썬에 대한 벽이었다. 다행히도, 나는 지금까지 알고리즘 문제를 풀 때 파이썬으로 풀었기 때문에 파이썬 기본문법에 대해서는 잘 알았지만 그 이상은 잘 몰랐다. 조금이라도 파이썬의 고급기능을 쓰려고 하면 그것들은 모두 다 배워야 할 것들이었고, 그렇기 때문에 개발은 쭉 달리지 못하고 조금 가다가 배우느라고 걷는 시간이 반복되었다. 또한, Fast API는 써본 적이 없기 때문에 다큐먼트를 하나하나 처음부터 다 읽어야 했고, 이 과정에서 생각보다 많은 시간이 걸렸다.

하지만, 이 과정에서 하나 깨달은 것은 기술문서를 바라보는 나의 모습이 옛날과는 다르다는 것이다. 이전에 내가 대학에 다닐 때 라이브러리 혹은 프레임워크 기술문서들은 내게 하나의 어려움으로 다가오는 문서였다. 특히, 조금이라도 불친절하거나 튜토리얼이 충분하지 않은 기술문서들은 이해하기가 어려웠고, 그렇기 때문에 중도에 포기하는 경우도 많았다. 그런데 42 과정을 거치며 RFC와 POSIX에 적응을해서인가 Fast API의 기술문서는 너무나도 친절했고 읽기에도 편안했다. 과장 조금 섞어서, 그냥 소설책 읽는 것처럼 기술 문서를 읽을 수 있었다.

Fast API기술문서는 대체적으로 튜토리얼과 예문들로 구성되어 있었는데, 이 문서들을 앞에서부터 차근차근 읽어보니 전체적인 프레임워크의 플롯을 확인할 수 있었고 덕분에 빠르게 구현을 마무리할 수 있었다. Nest로 개발했을 때 약 일주일이라는 시간이 걸렸었는데, 내가 자신있는 걸로 일주일 걸렸으니 처음 써보는 것으로는 2주 정도 걸릴 것이라고 생각했다. 하지만, 막상 결과를 바라보니 3일 만에 개발을 마무리할 수 있었다.

OAuth 플롯, 그리고 HTTP 엔드포인트, 백엔드 프레임워크 구조에 대한 이해가 높아져서 그런것도 있겠지만 기술문서를 받아들이는 나의 태도와 속도가 정말이지 많이 달라졌다는 것을 깨달았다. 42가 내게 준 가장 귀한 선물인 '배우는 방법을 아는 것'이 가장 잘 발휘된 순간이지 않았나 싶다.

운영되는 서비스

태풍 카눈이 한반도를 할퀸 날 공유 우산은 불티나게 나갔다. 대부분의 우산들에 새로운 대여기록이 만들어졌고, 또 모든 우산들은 대여에 대한 반납기록도 가지게 되었다. 여러 커뮤니티에서 공유우산이 도입되고 그것이 어떻게 무너지는지 바 왔던 내게 이 프로젝트가 만들어낸 결실은 뜻깊게 다가오는 것 같다. 앞으로도 이렇게 내가 개발한 것이 실제 문제를 해결해 주는 그런 개발을 해내고 싶다.

012

실제 작동하는 사이트

사이트 주소는 https://openumbrella.site로 접속해서 사용해볼 수 있다.

(**42서울 교육생 혹은 직원 계정 필요!!**)

"인프라 올 인원" 프로젝트(쿠버네티스)

susong — Tue, 25 Jul 2023 14:52:23 +0900

들어가면서

지난 8개월 동안 여러 프로젝트를 진행하면서, 관리하게 된 인프라의 수가 기하급수적으로 늘고 있다. 문제는 그때마다 AWS에 있는 EC2를 이용해서 관리를 진행했는데, 프로젝트가 진행됨에 따라서 관리의 난이도가 기하급수적으로 높아진 것이다. 내가 42 내부에서만 관리하는 프로젝트만 해도 총 5가지인데, 아래와 같이 관리하고 있다.

42 내부에서 관리 중인 인프라

42 모글 - EC2, 서울 리전, T3.micro (링크)

평가지표 사이트 - EC2, 서울 리전, T3.small (링크)

42 베네핏 공식 사이트 - EC2, 파리 리전, T3.micro (링크)

42 공지 알람이, 개발자 구직 공고 알림이방(카톡, 슬렉) - EC2, 서울 리전, T3.micro (링크)

42 내부 공유우산 관리 사이트 - EC2, 서울 리전, T3.small (오픈준비 중)

문제는, 하나하나 다른 네트워크 정책과 보안 정책들 때문에 문제가 발생할 때마다 그때마다 설정을 다시 처음부터 확인해야 되는 어려움이 있었고, 또 내가 봤을 때 초기 EC2들은 내가 잘 모를 때 만든 것들이라 보안 취약점들도 있었다. 물론, 나중에 개선했지만 근본적인 문제는 아니라고 생각했고 늘 개선해야겠다는 마음만 품고 있었다.

또한, 42 내부 프로젝트의 경우 42 OAuth에 접근하기 위한 API Secret 키가 2주마다 갱신되는데, 그것을 캐치 업하기가 너무 까다로웠다. 그래서 조금 보안적인 열세를 두더라도 각각 VM에서 셀레니움을 이용해 키값 갱신이 가능하도록 만들어두었는데, 문제는 42 인프라 UI가 너무 자주 바뀐다는 것이다. UI가 바뀔 때마다 하나하나 VM에 들어가서 코드를 수정해 주는 것이 여간 힘든 일이 아니었다. 나중에는 Github에 수정된 코드를 올리고 Ansible을 이용해서 한 번에 해당 툴을 관리하는 방법을 썼지만, 이 또한 완벽한 해결법은 아니라고 생각했다.

그래서, 이 모든 문제를 한 번에 해결할 수 있는 방법인 쿠버네티스에 이 모든 인프라를 넣기로 했다.

쿠버네티스의 로고, 배의 조타 모양이다

쿠버네티스를 선택한 이유

가장 큰 이유로는 VM에 지쳐버렸다.. 대충 다뤄도 언제나 제 역할을 해주는 도커와 다르게, VM은 내가 세세하게 다뤄줘야 되는 것도 많고 유사 육아처럼 하나하나 챙겨줘야 되는 것에 지쳐버렸다. 프로젝트 때마다 VM에 들어가서 하나하나 설정해 주는 것에 지쳤고, 나중에는 골든 이미지를 기반으로 어느 정도 편안해지긴 했지만 그래도 개복치처럼 터져버릴 때는 정말 한숨만 나왔다.

또한, 트래픽이 몰리는 경우나 유사 상황에 대비하기가 너무 어려웠다. 특히, 오픈 날 이럴 때나 평가가 많은 날 수많은 새로고침은 micro가 가끔은 감당하기 힘든 트래픽을 만들어냈다. 때문에 백엔드 최적화와 프런트는 CDN으로 빼는 등 다양한 방법으로 문제를 해결해 냈으나, 사실 가장 좋은 방법은 쿠버네티스의 HPA와 같이 수평적 확장을 하는 것이다. 물론, EC2에 오토스케일링이 있지만 내가 해둔 투박한 설정들 때문에 사용하기가 쉽지 않았고, 결정적으로 로드밸런서 가격 때문에 포기했다.

또, 로깅과 모니터링에서도 어려움을 겪었다. 특히, 로그가 서버마다 다르게 기록되다 보니까 보려면 하나하나 찾아봐야만 했고, 그 때문에 로그가 일정정도 쌓이면 S3에 넣는 방식으로 구성을 해두긴 했으나 이 또한 완벽한 해결방법은 아니었다. 또한, 모니터링도 EC2가 제공하는 모니터링 툴로는 내가 원하는 값들을 추산하기 어려웠고, 그렇다고 하나하나 모니터링 툴을 달기에는 일이 너무 많아질 것 같았다.

마지막으로는, Secret값 관리에도 지쳐버렸다. VM이 계속 늘어나니(지금 관리하는 VM에 9개이다) 처음에는 사소했지만, 점점 하기가 벅차왔다. 내가 서버관리만 하고 있으면 크게 상관이 없는데, 다른 공부들과 프로젝트와 병행하다 보니까 이제 이 Secret값 수정에서 해방되고 싶었다.

그래서 이런 문제들을 완벽하진 않지만, 꽤나 해결해 줄 수 있는 방법을 찾았고 최근 쿠버네티스를 깊이 있게 공부하다가 쿠버네티스를 이용하면 문제가 해결될 것이라고 판단해서 이 프로젝트를 기획했다.

쿠버네티스에게 기대하는 역할

1. 조금 더 편한 업데이트

업데이트할 때 직접 하나하나 해줘야 되는 것이 아닌, 혹은 프로젝트마다 다르게 CICD를 구축해야 되는 것이 아닌, 쿠버네티스가 제공하는 방식으로 업데이트를 하고 싶다. 특히, 롤링 업데이트와 그린/블루 배포 방식을 구성할 때 들어가는 품을 쿠버네티스를 이용해서 줄이고 싶은 것이 크다.

2. 오토 스케일링 및 에러핸들링

더 이상 내가 만들어놓은 VM의 AZ가 문제가 발생했을 경우를 가정하고 싶지 않다. 사실 잠시 서비스를 중단한다고 크리티컬 한 일이 발생하지는 않겠지만, 그런 경우의 수까지 고민해서 설계를 구성하는 것에 품을 그만 쓰고 싶다. 쿠버네티스를 이용하면 여러 AZ에 노드들을 두고 사용하고 문제가 발생하면 파드들을 알아서 띄워주니까 이런 걱정에서 해결될 것이라고 기대하고 있다.

3. 하나로 다하는 로드 밸런싱

로드 밸런서를 하나로 구성해서 여러 서비스에 모두 적용해보려고 한다. 사실 완전히 가능한지는 잘 모르겠다 아직 안 해봐서 그렇긴 하지만, 가능하다면 하나의 로드밸런서로 모든 서비스로 구성해볼까 한다. 내가 관리하고 있는 도메인이 지금 서브 도메인 포함해서 20개가 넘어가고 있는데, 하나의 엔드포인트로 설정해서 관리를 편하게 해보려고 한다.

4. 이 외에도 여러 기능들

시크릿 관리나 내부 DNS를 이용한 편안한 관리 등등 여러가지가 있지만, 크게는 위의 3가지가 가장 크게 와닿는다. 근데 저 것들을 관리하는 품이 더 크지 않을까 생각할 수도 있다. 그래서 이번에는 그냥 관리형 쿠버네티스(내가 선택한 것은 EKS)를 이용하려고 한다.

앞으로의 계획

현재, EKS를 구현 내부에 있는 파드, 서비스들을 어떻게 구성할지 정하고 있다. 사실 쿠버네티스는 선언형 관리툴이라 '어떻게 해줘!'라고만 하면되지만, 안에 모니터링이나 로깅같은 부분을 어떻게 할지 그리고 리소스를 어떻게 분배할지를 고민하고 있다. 42재단으로부터 EKS 비용지원도 얻어내서 정말 극한의 효율화보다는 조금 여유가 있게 구성할 수 있게 되었지만, 각각 서비스에 들어오는 트래픽과 필요한 컴퓨팅 용량을 잘 계산해내서 구성해보려고 한다.

쿠버네티스의 간단한 세팅과 앞으로의 전략은 나왔다. 이제 기다려야되는 것은 내가 만들지 않은 서비스들의 컨테이너화다. 이것까지 마무리 되면 바로 컨테이너를 끼우고, 내가 만든 42API 시크릿 관리툴 그리고 그라파나 같은 모니터링 툴을 탑재해서 바로 서비스를 시작하려고 한다. 이 것이 마무리 되면, 이제 담당자가 졸업해버려서 사라지는 프로젝트는 없어질 것이고 또한 새로운 프로젝트를 준비하는 사람은 인프라는 고민하지 않고 컨테이너만으로도 서비스를 시작할 수 있게될 것이다.(야호!)

프로젝트를 하면서 시간 관계상 아직 시험을 보지는 못했지만, CKA를 따기위해 준비한 공부가 빛을 발하고 있다. 프로젝트까지 잘 마무리하고 CKA까지 따서 유종의 미를 거둬야겠다.

간단하게 슬렉 봇 만드는 방법

susong — Mon, 24 Jul 2023 20:17:51 +0900

들어가면서

42서울에는 달리기 기록을 올리는 채널이 있다. 그런데 잘 살펴보면 이 채널에 사람이 매일 날짜를 올리고 그 아래에 쓰레드를 통해서 사람들이 자신의 달리기 기록을 인정받는다. 개인적으로 날짜 치는 것이 귀찮을 것이라고 생각했고, 그래서 채널을 위해서 간단한 날짜 봇 및 날씨를 알려주는 봇을 만들었다. 이번에는 다른 회고와 다르게 실제로 어떻게 만드는지도 설명해볼까 한다.

간단하게 슬렉 봇 만들기

준비물 : 파이썬에 대한 간단한 지식, Slack Bot TOKEN, 파이썬이 설치된 PC

아래 방법은 LINUX 및 MAC 기준입니다.

1. 가장 먼저 필요한 라이브러리를 설치해줍니다.

pip3 install slack_sdk
pip3 install request

2. 필요한 파일들을 만듭니다. (main.py, .env)

touch main.py
touch .env

3. 원하시는 IDE로 파일을 엽니다(VSC 추천)

code main.py
# 혹은 VIM 유저는 vim main.py로 여시면 됩니다.

4. 필요한 라이브러리 가져오기

from datetime import datetime
from slack_sdk import WebClient
from slack_sdk.errors import SlackApiError
from dotenv import load_dotenv
import os
import requests
import json

5. .env 설정하기

# SLACK BOT
SLACK_TOKEN=(TOKEN 유출안되게 조심하세요!)
SLACK_ERROR_URI=(이 것은 선택!)
SLACK_CHANNEL=(보내고 싶은 채널명)

# WEATHER
# https://openweathermap.org/api 여기에 회원가입 후에 API_KEY복사 붙여넣기 하면 됩니다.
WEATHER_API_KEY=(유출 안되게 조심하세요!)

6. 환경변수 가져오기

load_dotenv()  # .env 파일에서 환경 변수를 로드합니다.

slack_bot_token = os.getenv("SLACK_TOKEN")
slack_channel = os.getenv("SLACK_CHANNEL")
apiKey = os.getenv("WEATHER_API_KEY")

7. 슬렉에 메시지 보내는 함수 제작

def send_slack_message(message):
    # WebClient 인스턴스 초기화
    client = WebClient(token=slack_bot_token)
    try:
        response = client.chat_postMessage(
            channel=slack_channel,
            text=message,
            blocks=[
                {
                "type": "section",
                "text": {
                "type": "mrkdwn",
                "text": message,
                }
            },
            ]
        )
    except SlackApiError as e:
        print(f"Error sending message: {e}")

8. 날씨 가져오기 위한 세팅

# 초기세팅
city = "Seoul" # 원하는 도시 설정
lang = 'kr' # 언어 설정
units = 'metric' # 단위 설정(섭씨)

# API 요청보낼 곳 설정
api = f"https://api.openweathermap.org/data/2.5/weather?q={city}&appid={apiKey}&lang={lang}&units={units}"

# API 요청
result = requests.get(api)
result = json.loads(result.text)

# 나온 데이터 중 필요 데이터 구분
name = result['name']
lon = result['coord']['lon']
lat = result['coord']['lat']
weather = result['weather'][0]['description']
temperature = result['main']['temp']
humidity = result['main']['humidity']

9. 출력문 만들기

# 출력문 만들기
now = datetime.now() # 현재 시간을 얻습니다.
date_time = now.strftime("[*%m월 %d일, 오늘의 달리기 기록*]") # 문자열로 변환합니다.
message = date_time + f"\n\n오늘의 날씨: {weather}(기온: {temperature}, 습도: {humidity})\n * 기준: 서울, 경도: {lon}, 위도: {lat}"

10. 발송!

send_slack_message(message)

이렇게 간단하게 슬렉 봇을 만들 수 있다. 실행시켜보면 바로 아래와 같이 봇이 메시지를 보낸다.

매일 특정시간에 보내기

매일매일 내가 서버에 들어가서 저것을 보낼 수는 없지않은가? 컴퓨터에게 알아서 특정 시간에 돌리도록 해보자

1. crontab 스케쥴러 편집에 들어간다.

crontab -e

2. 해당 파일을 특정 시간에 돌리라고 명령해둔다.

# ...기존에 작성되어있는 안내문

# 매일 오전 9시에 실시하겠다는 의미다.
0 9 * * * python3 (해당 .py 파일 경로, 이 때에는 절대경로로!)

3. 이렇게 작성하고 esc -> :wq 입력 -> 엔터를 진행하면 crontab이 설정된다.

TIP: 9시가 아닌 다른 시간에 작동합니다 -> 해당 서버의 기준 시간을 확인해보세요 date를 입력하면 됩니다. UTC 기준으로 설정되어있다면, KST로 변경하는 과정을 거치면 정상적으로 9시에 해당 파일이 실행되게 됩니다.

진짜 끝!

토이 프로젝트 확장(42JOBS, 이제는 카톡으로도!)

susong — Mon, 24 Jul 2023 19:49:24 +0900

들어가면서

슬렉으로 완전하게 만들기를 하루, 간단한 사이드 프로젝트였지만 에러를 유발할 수 있는 부분(네트워크)과 엣지 케이스들(용량 이슈 혹은 사진 크기 등등)에 대한 처리 로직도 포함하다 보니까 생각보다 시간이 길어졌다. 42 서울에서 가장 중요하게 여기는 것이 완전하게 돌아가는 프로그램을 만드는 것이다보니까, 이런 부분은 몸에 배는 것 같다. 아주 습관이라 하기 싫어도 알아서 하게 된다(특히, C언어에서 malloc이 안되었을 경우 등에 대한 처리 등등...)

만들고 보니, 이렇게 애정을 쏟은 프로젝트를 그냥 42슬렉에서만 쓰게 하기에는 너무 아쉬웠다. 그래서 이것을 카톡으로도 확장하면 좋겠다고 생각했고, 오늘 점심 먹다가 이 생각을 하게 되어서 저녁까지 마무리했다. 이 프로젝트를 하면서 몇 가지를 더 배워봤는데 그 부분을 중심으로 프로젝트를 회고해보려고 한다.

어떻게 구성할 것인가?

카카오톡 봇은 만들기가 생각보다 까다롭다. 왜 그렇냐면, 카카오톡에서 제공해주는 공식 카카오톡 봇 SDK는 상당히 제한적인 기능만을 수행할 수 있기 때문인데, 이 봇 SDK는 기능은 많지만 쓸모 있는 기능은 많지 않다. 특히, 무료로 쓸 수 있는 기능은 제한적이고 또 사용자에게 알람을 띄우는 기능은 법적인 문제로 시간, 비용적 제한이 있다. 이런 공식 툴을 사용해서 카톡으로 알람을 주는 것은 상당히 노력과 비용을 소모할 것이라고 판단했고, 나는 이전에 해본 방식을 사용하기로 했다.

내가 사용한 방식은 매우 간단하다. 원래는 리눅스에 안드로이드를 에뮬레이팅해서 거기서 나오는 이벤트 리스너를 바탕으로 실행하려 했었는데, 잘 찾아보니까 그런 기능을 어플로 누가 구현해 놓아서 그냥 그것을 쓰기로 했다. 내가 선택한 것은 메신저봇 R이고, 이 녀석은 공기계에서 JavaScript를 이용해서 봇을 만들 수 있게 제공해준다. 간단하게 카톡 알람이 뜨면, 그 알람에 대한 답장을 설계할 수 있는 프로그램인데, 내게는 이것만으로 충분했기 때문에 바로 제작에 돌입했다.

카카오톡 봇 구성

간단하게 설명하면 이런식이다.

이 과정에서 새롭게 배운 것은 Python FAST API인데, 이게 정말정말 놀라울 정도로 간단하다. 향후 프로젝트에서도 사용할 수 있을 것 같을 정도로 간단함에 매료되었고, 놀라울 정도로 성능도 준수하다. 혹시 API 그냥 급하게 만들어야 할 때는 이걸로 만들 것 같다. 약 9줄만으로 필요한 GET 요청에 대한 응답을 해낼 수 있다는 것이 놀라웠고, FAST API에서 제공하는 커스터마이징도 놀라울 정도로 다양했다. 꼭 한번 추천한다.

파일은 DB연결까지 진행할까 하다가, 그냥 빠르게 만들기 위해서 가장 최신을 유지하는 파일 2개를 만들고(root_path은 웰컴 html이다) 해당 파일의 내용들을 Response로 보내도록 제작하였다. 이렇게 간단한 방식으로 나는 두 회사의 가장 최신 공고를 언제나 응답해주는 API 2개를 만들어넀다.

간단한 폰 로직 구현

그렇게 잘 만들어진 API를 이제는 폰에서 간단한 로직을 통해서 사용한다. 물론 안에 Response 객체 등등 여러 가지 알아야 될 것들이 있지만, 머리 아프니까 그런 것 말고 크게 크게만 설명해 보겠다. 공기계 안에 있는 챗봇은 위의 다이어그램처럼 간단하게 제작되어 있다. JavaScript의 Thread를 사용해서 시간 인터벌(1분)을 구현했고, 이를 바탕으로 지속적으로 내 서버에 접속, 데이터를 가져오게 된다. 가져온 데이터는 공기계 내부에 있는 DB에 저장되며, 마지막에 가져온 값과 이번에 새롭게 가져온 값이 다를 때에만 오픈 채팅방에 올리는 방식이다.

새로운 것은 늘 즐겁다

C랑 C++을 깊이 있게 이해하고, CS 및 웹에 대해 이해하고 있으니 새로운 것을 배우는 것은 매우 쉽다. RFC와 POSIX로 다져져있다 보니까, 요즘은 기술문서를 읽어도 즐겁다. 특히, 최근에는 쿠버네티스를 공부하고 있는데, RFC 읽다가 읽어서 그런지 몰라도 정말 너무 친절하고 문서 작성자분들께 감사하다. 사실상 이번에 새롭게 배운 것은 사실상 Fast API 밖에 없는데, 이 Fast API를 배울 때에는 잘 만들어진 다큐멘트 덕분에 빠르게 구현할 수 있었다.

다 만들고 보니까, 거의 스피드런을 한 것 같다. 서버 설정, API 2개, 챗봇 로직, DB설정까지 3~4시간 만에 마친 것 같다. 그렇게 만들어진 카톡방에는 현재 30명 정도가 들어와 있는데, 첫 베타테스터 입장임을 고려하면 많은 사람들이 이용하고 있다고 생각한다. 언젠가 이 카톡방이 커져서 많은 사람들에게 도움이 되는 툴이 되었으면 한다.

신입개발자 수도권 공고 모음방

요즘 채용 솔루션 회사들에 돈이 몰리고 있는 것 같다. 내가 취준을 하다 보니까 실제로 많은 회사들이 상시채용으로 채용을 진행하고 있었고, 이 과정에 많은 인력들이 갈려나가고 있는 것을 직접 보았다. 그렇기 때문에 채용솔루션들 특히 상시채용과 관련된 필요가 증대하고 있는 것 다. 이런 과정에서 두들린 같은 회사에서 만든 채용자들을 위한 솔루션들이 시장에 많이 소개되었고 받아들여졌다.

하지만 피고용인을 위한 플랫폼은 아직 미약한 것 같다. 피고용인들은 다양한 플랫폼(잡플래닛, 사람인, 원티드 등등)에 들어가서 날짜를 확인하고, 각각의 구직 사이트마다 이력서를 등록하고, 연락 왔는지 확인하기 위해서 모든 플랫폼을 다 돌아야 된다. 나의 이번 프로젝트는 그런 부분에서의 문제를 해결하기 위해서 제작되었다. 이번에 제작한 내 카카오톡 봇이 나 같은 신입 개발자들(특히, 수도권, 1~3년 차, 개발직군을 희망하는 개발자)에게 조금 더 채용에서 힘을 빼는데 도움이 되었으면 좋겠다.

카카오톡 입장 링크(비번: 4242)

https://open.kakao.com/o/gm6D4Lwf

토이프로젝트 후기(42JOBS, 42슬렉 취업공고 채널 봇)

susong — Sat, 22 Jul 2023 17:40:09 +0900

들어가면서

무엇이든, 내가 필요해서 만드는 토이 프로젝트가 최고인 것 같다. 이번과 같은 경우 내가 취준생이다 보니까 계속 취업공고 사이트를 들락날락해야만 했는데 그 과정에서 너무 큰 시간소모를 하고 있었다. 이 시간소모가 나뿐만 아니라 42커뮤니티 모두가 느낄 것이라고 생각했고, 그래서 나는 우리 커뮤니티를 위해 42슬렉 취업공고 봇을 하나 만들어야겠다고 생각했다.

저녁 먹다 시작한 개발

취업공고 봇을 만들기 위해서 필요한 것은 크게 3가지 정도였다. 첫 번째로는, 해당 프로그램을 돌릴 서버에 대한 이해(프로세스, VM, CRONJOB 등에 대한 이해) 두 번째로는, 크롤링에 대한 이해(동적, 정적 사이트 가리지 않고 긁어올 수 있는 능력, 또한 HTTP Request에 대한 이해) 마지막으로는, Slack SDK 및 챗봇에 대한 이해였다.

다행히도, 세 가지 모두 다 능숙한 분야였고 덕분에 저녁 먹으면서 고민한 일을 그날 집에 가기 전에 마무리할 수 있었다. 서버는 기존에 서비스하고 있는 서버 중에 CPU utilization이 50% 미만이라서 근 시일 내에 인스턴스 유형을 내리려고 했던 서버를 이용했다. 해당 서버에는 Selenium, Python과 같은 필수적인 패키지들이 모두 존재했기 때문에 즉시 개발이 가능했다. 역시 잘 관리해 놓은 VM은 언제나 사용하기 편한 것 같다(물론, 컨테이너가 훨씬 좋다.. 말이 좋은 것이지 까탈스러운 VM들..)

개발 과정

가장 먼저 정해야 되는 것은 어떤 사이트를 긁어올지 정하는 것이었다. 개인적으로 가장 양질의 공고는 Wanted로 가는 대신 Wanted에는 공고의 수가 적고, 나머지 사람인과 잡플래닛은 공고수는 많으나 필터링이 많이 필요하다고 생각했다. 그래서 가장 먼저 Wanted부터 개발하기로 마음먹고 원티드부터 개발해 냈다.

가장 먼저 올린 공고

가장 먼저는 일단 돌아가게만 만들었다. 일단 원티드를 긁어왔으나 사실 저 정보는 어떤 가치도 없는 정보라고 생각한다. 왜냐하면, 결국 이 공지를 보는 것은 내가 이 회사에 관심을 지원할지에 대해 판단할 정보를 접촉하는 것에 있기 때문이다. 하지만, 저 정도의 정보는 어떤 영향도 끼칠 수 없기에 나는 바로 다음 스텝으로 필수적인 정보들을 추가하기 시작했다.

발전된 원티드 공고 아직 수정해야되는 부분이 보인다.

이후 어떻게 어떤 정보가 필요할지에 대해 깊이 있게 고민했고, 채용공고를 읽을 때 내가 하는 행동을 기준으로 삼기로 했다. 나 같은 경우 원티드에 올라온 공고는 일단 들어가 보고 그 후에, 주요 업무와 요구사항을 확인한다. 그리고 그 내용이 나와 부합하다면 그때 지원여부에 대해 고민한다. 이런 나의 행동을 기반으로 원티드에서는 필요한 정보 모두를 추출해서 제공하기로 마음먹었다.

원티드를 해냈으니 그다음은 사람인 차례였다. 사람인의 경우에는 공고가 많으나 42 커뮤니티 일원들의 구미에 당기는 공고는 자주 올라오지 않는다. 특히, 지역이 매우 산발적이고 연차에 대한 것들도 조건이 다양하다 보니까 나는 필요한 정보를 구분하는 과정을 거쳐야만 했다. 내가 생각했을 때 42 커뮤니티 일원들에게 필요한 정보는 다음과 같았다. 첫 번째, 수도권일 것 두 번째, 신입 혹은 경력무관 혹은 1~3년 차까지 지원이 가능할 것 마지막 조건으로는 당연하게 개발직군일 것이다.

간단하게 조건을 넣어서 걸러줬다.

해당 조건을 충족한 공고만 커뮤니티 일원들이 볼 수 있도록 조건을 변경하였고, 덕분에 불필요하게 많은 공고들이 올라오는 상황을 방지할 수 있었다. 또한, 원티드와는 다르게 훨씬 많은 공고가 올라오는 특성을 반영하여 공고를 올리는 방식에도 변경점을 두었다. 데이터를 살펴보니 원티드에 공고 1개가 올라올 때, 위의 조건을 통과한 사람인 공고는 3~4개 정도가 올라오게 된다. 그렇기 때문에 사람인 공고가 너무 길 경우 채널이 불필요한 정보로 둘러싸일 것을 우려했고 아래와 같은 양식으로 제작하였다.

사람인 공고 양식

조금 힘들었던 잡플래닛

잡플래닛은 한 가지 차이점이 있었는데, 위 두 사이트와 다르게 URL단에서 조건을 넣어줄 수 없다는 것이다. 잡플래닛은 하나의 도메인에서 안에 있는 컴포넌트만 변경하는 방식으로 사이트가 설계되어 있는데, 그렇기 때문에 다른 사이트들에서 진행한 것과 다르게 복잡한 과정을 거쳐야만 했다.

위의 조건을 하나하나 눌러줘야만한다.

가장 먼저, 직군에 대한 탭을 클릭한 후, 개발 탭을 선택 후 클릭 그리고 개발 전체를 선택 후 클릭하는 과정을 거쳐야 한다. 그리고 동일한 방식으로 고용 경력을 조건에 넣어줘야만 했다. 경력과 같은 경우에는 셀렉트가 아니라 바 형태로 제작되어 있었는데 해당 부분도 여러번의 테스트를 거치며 조건에 집어넣었다.

이후, 잡플래닛의 장점이라고 생각되는 평점 시스템을 도입하여 2점 미만의 기업들은 공고를 내보내지 않도록 했다. 일단 데이터베이스에는 넣어놓지만 해당 공고들은 42 커뮤니티 일원들이 크게 바라지 않을 것이라고 판단하여 넣지 않는 것으로 결정했다. 그리고 사진과 함께 양식을 제작하여 아래와 같이 잡플래닛에 대한 공지를 올릴 수 있게 하였다.

개발 과정 중 어려움

개발 전체에 12시간도 안 쓰고 어려움에 대하여 말하자니 좀 웃기긴 하지만 일단 꼽자면 동적 페이지에 대한 크롤링에서 오는 부담감이 있는 것 같다. 간단하게 request로 진행하는 정적 페이지 크롤링과 다르게 동적 크롤링은 랜더링 과정 또한 고려해줘야 하고 또 성능에 대해서도 고민해 줘야 되는 부분이 많았다. 나 같은 경우 이번 프로젝트를 Selenium으로 진행했는데, 크롤링 과정에서 성능이슈를 이겨내기 위해서 노력해야만 했다.

또한, 회사들 입장에서 크롤링하는 것을 좋아할 리 없기에 요청 수에 대해서도 고민해야만 했다. 이번 프로젝트는 크롤링한 정보를 통해서 뭔가 새로운 비즈니스를 하는 것이 아니라 취준생들에게 해당 구직 사이트로 쉽게 가도록 해주는 것이기 때문에 진행했다. 하지만, 분명히 지속적인 크롤링은 서버에 부담일 것이기 때문에 되도록이면 적은 숫자의 요청에 여러 개의 공고를 가져올 수 있도록 설계했다. 최소한의 요청으로 최대한의 정보를 가져오는 방식으로 설계를 진행한 것이다.~~(물론 저정도의 사이트 서버가 시간당 4~50번이 부담일리는 없겠지만..)~~

마지막으로는, 로깅 설정에서의 난맥이 있을 것 같다. 세 사이트를 하나의 로그에서 진행하자니 그것은 나중에 가독성이 없을 것 같았고, 또 어떤 레벨로 로깅을 할지에 대해서도 고민해야만 했다. 이번의 경우에는 하루가 지날 때마다 당일 날짜를 기준으로 하는 로그파일을 제작, 기록하도록 제작하였고 로깅 레벨은 INFO, ERROR 두 가지만 이용해서 진행했다. ERROR 로그가 작성되면 내게 슬렉으로 DM이 오도록 해서 에러처리에서도 빠르게 대응할 수 있도록 했다.

개발 후 반응

42 커뮤니티에는 약 1400명이 소속되어 있고, Slack 커뮤니티에 활동적인 인원은 100명 내외이다. 이번 프로젝트의 경우에는 24시간 안에 100명 이상이 내가 만든 프로그램을 사용하고 싶어 했고, 그렇게 수많은 유저를 바로 획득할 수 있었다. 심지어 개발 프로토타입 때부터 많은 사람들이 관심을 가졌고, 덕분에 입소문을 바탕으로 많은 사람들이 애용하는 서비스를 하나 더 만들어볼 수 있었다.

솔직히 개발의 난이도나 기술적 완성도가 높은 프로젝트는 아니었지만, 사용자의 니즈를 파악해서 그에 맞는 프로그램을 제작했다는 것에서 이번 프로젝트는 의미가 있는 것 같다. 좋은 프로그램이란 가장 기술적으로 훌륭한 프로그램이 아니라, 가장 사용자를 만족시켜 줄 수 있는 프로그램이지 않을까? 사람들이 사랑해 주는 프로그램을 만드는 것은 늘 즐거운 것 같다 :)

서비스 개발 과정중에 희망자를 받았다.

42베네핏 개발기 발표 회고(benefit.42seoul.link)

susong — Thu, 13 Jul 2023 22:15:42 +0900

들어가면서

모든 발표를 만족스럽게 할 수는 없지만, 나는 발표는 최대한 내 발표를 들으러 와주신 모든 분들의 시간이 아깝지 않게 하려고 노력하고 있다. 하지만, 이번 발표는 내가 만든 원칙에 충분하지 않았다고 생각한다. 발표를 마친 후, 잘 들었다고 이야기해 주는 많은 분들이 계셨지만 그 말을 들으면서도 마음이 편하지는 않았다. 집에 와서도 나는 '도대체 내가 왜 그렇게 발표를 했을까?'라고 하루종일 자책했다. 오늘은 내 자책에 대한 이야기를 해보려고 한다.

발표영상

42베네핏 개발기 발표

충분하지 못한 준비

나는 원래 발표를 하기 전에 내 발표를 들으러 와주시는 분들의 시간 만큼 발표를 준비한다. 예를 들어 50명이 내 30분짜리 발표를 들으러 와준다면 최소한 25시간은 발표를 준비해야 되는 것이다. 원래는 그런 원칙을 지켜서 발표를 준비해 왔는데, 이번 발표 때에는 그렇게 하지 못했다.

당시 나는 트센(ft_transcendence)라는 42서울 마지막 과제를 진행하고 있었는데, 이 과제에 너무 많은 시간을 쏟았다. 아침에 눈을 뜨고 밥 먹는 시간을 제외하면 해당 프로젝트에 몰입해 있었고, 어떤 주에는 주 80시간에 가까운 시간을 코드 치는 것에 할애하기도 했었다. 코딩에 몰입하는 놀라운 경험을 하며 프로그래밍 실력과 경험치는 높아졌지만, 그것을 위해 너무 많은 시간과 체력을 쏟아버렸다.

해당 발표는 발표일 4주전에 예정해 두었는데, 나는 발표 준비를 시작해야 되는 2주 전에도 트센 과제에만 집중하느라 제대로 된 발표 준비 시간을 할애하지 못했다. 결국 발표 2일 전에 가서야 팀원들에게 양해를 구하고(팀원들은 흔쾌히 동의해 주었다) 발표를 준비했지만, 충분한 체력이 없는 상태에서 준비한 발표는 내 기준에 충족되지 않았다. 하지만, 이런 시간적인 문제는 핑계고 아래 내용이 진짜 내가 제대로 발표하지 못한 이유다.

발표를 잘한다고 생각한 착각

이번 발표가 만족스럽지 않게 나온 이유는 내가 발표를 잘한다고 생각한 착각 때문인 것 같다. 원래도 발표를 즐겼던 나는 학창시절부터 여러 무대에서 발표할 기회가 많았다. 하지만, 내 발표 인생에서 아직도 잊을 수 없는 2번의 순간이 있는데, 그 순간들은 각각 20살 때 사회적 기업 공모전 중간발표를 위해 장, 차관님들 앞에서 한 발표, 그리고 23살 때 업비트 컨퍼런스 발표 때 했던 발표다.

첫 번째인, 20살의 발표 떄 나는 너무 어리고 경험도 없었다. 해봤자 학교나 교육기관에서 내 또래들을 앞에 두고 한 발표는 실제 사회에서 조금밖에 도움이 되지 않았다. 내가 못해도 빵긋빵긋 웃어주는 친구도 없었고, 발표장소에는 내 발표를 보고 있는 차가운 눈동자들과 내 발표 내용에 부족한 부분이 있으면 움직이는 펜대들뿐이었다. 어찌어찌 20분 간 사회적 기업과 관련된 발표를 장, 차관님 그리고 예하 사무관, 서기관님들 앞에서 했지만 지금도 나는 발표 당시에 대해 기억나는 부분이 잘 없다.

얼마나 떨었는지, 발표를 마치고 나서 그 하루는 아무것도 할 수 없을정도로 힘이 빠졌었다. 분명히 발표 전에는 자신감이 있었는데 막상 발표를 하는 순간에는 백치가 되는 경험을 한 것이었다. 나는 이때 이후로 어떤 순간에도 발표를 망치지 않게 하기 위해서 더 많은 준비를 하겠다 마음먹었었다. 그리고 그렇게 내가 스스로에게 만든 기준이 발표 준비시간은 발표를 경청해 주는 모든 사람의 시간보다 커야 된다는 것이었다. 물론, 준비가 반드시 발표순간의 긴장을 막아주지는 않지만, 최소한 충분한 시간에서 오는 자신감은 발표에 큰 도움이 되어왔다.

두 번째 잊지 못하는 발표는 나의 업비트 컨퍼런스 발표였다. 그때는 해커톤을 마치고 발표하는 형식이었는데 해커톤 중 밤을 새웠기 때문일까 나는 발표직전 몸이 너무 좋지 않다는 것을 깨달았다. 이미 발표 내용은 내가 작성했고 피피티도 내게 맞추어 준비된 상황, 발표자를 바꿀 수도 없었기 때문에 나는 그냥 발표를 진행했다. 하지만, 몸이 좋지 않으니 수많은 눈동자들 앞에서 내 정신까지 망가져버렸다. 결국 나는 내가 하려고 했던 발표내용의 반절정도 간신히 마치고 내려올 수 있었다.

발표를 잘하기 위해선 높은 자존감과 자신감이 필요하다. 그리고 두 가지는 자신의 몸 상태가 큰 영향을 미친다. 몸 상태가 좋지 않으면, 사람은 위축되고 그런 위축은 평소에는 의도적으로 숨길 수 있지만 무대에서는 큰 도움이 되지 않는다. 가슴을 피고 당당한 모습으로 최대한 자존감을 높여보려고 해도 낮은 체력은 높은 자존감을 만들어주지 못한다. 이렇게 나는 충분한 준비만이 능사가 아니라는 것을 값진 경험을 통해 뼈저리게 느꼈다.

발표란 무엇일까

나에게 있어서 발표는 나 혹은 내 팀을 뽐낼 수 있는 무대다.

내가 스스로 혹은 팀원들과 해온 성취들을 사람들에게 이야기하고, 그 과정에서 나는 성취감에 도취된다. 그리고 발표를 통해 얻은 높은 성취감은 내가 더 높은 목표를 향할 수 있게 도와줬었다. 그렇게 지속적으로 앞으로 나아가다 보니, 나는 나도 모르게 이 성취감에 도취되어 버린 것 같다. 지금까지 내가 잘해올 수 있었던 것은 내가 잘하기 때문이 아니라, 이전에 값지게 배운 경험이 두 번 같은 실수를 하지 않도록 도와줬기 때문이었음을 이번 발표를 통해 다시 한번 깨달을 수 있었다.

살다 보면 나 혹은 내 팀이 해온 것들에 대해서 사람들에게 자랑해야 하는 순간들이 있다. 또, 내가 하고자 하는 방향을 위해 많은 사람들을 설득해야 할 순간도 있다. 이런 중요한 순간이 왔을 때, 또 이런 실수를 하지 않도록 이번 발표를 마음에 새겨야겠다. 다음에는 같은 실수를 반복하지 않을 것이다.

ARM64에서 만든 컨테이너 AMD64에서 안 올려질 때

susong — Fri, 30 Jun 2023 22:49:11 +0900

컨테이너가 안올라가진다..

평화롭던 어느날 언제나와같이 쿠버네티스를 파드를 만들고 있었는데, 내가 방금 만든 컨테이너가 지속적으로 FAIL하는 문제가 발생했다. 분명 내가 바로 앞에서 MAC으로 빌드하고, 그것을 바로 Docker Repository에 push하고 해당 이미지로 실행시켰는데도 안되는 문제였다.

1시간정도 고민 끝에 모든 것을 다 해결하고도 혹시나 싶어서 한 부분이 맞아서 해당 해결방법을 서술하기 위해서 작성해본다.

처절한 BackOff의 흔적

해결의 실마리

이번 문제의 실마리는 kubectl logs <파드 이름>이 작동하지 않는 것이었다.

어떻게든 문제 원인을 찾고싶어서 kubectl logs를 사용하는데 지속적으로 entrypoint를 잡지 못했다. 이런 경우는 거의 없기에 혹시나 이런 가능성을 야기할 수 있는 시스템적인 차이에 주목했고, 내가 사용하는 맥북은 ARM64 그리고 내가 현재 접속한 클라우드 서버(MASTER 노드)는 AMD64라는 것에 주목했다.

해결방법

docker에는 docker buildx라고 하는 Docker CLI플러그인이 존재하는데 이 녀석은 빌드 타임 때 멀티 아키텍처 이미지를 만드는 기능을 포함하고 있다. 그리고 이 녀석을 사용하면 docker build 간에 멀티 클라우드를 지원하게 할 수 있다.

해당 문제 해결을 위해서 나 또한 docker buildx를 사용했고, 해당 방법을 사용한 결과 현재는 쿠버네티스에 원하는 POD를 잘 띄울 수 있게 되었다.

사용방법

가장 먼저 본인의 도커 버전이 19.03 이상인지 확인해야된다. (19.03이상의 버전에는 buildx가 포함되어있다.) 그리고 그 후에 buildx를 활성화시켜야된다. 아래 명령어를 입력하면 buildx가 활성화된다.

docker buildx install

두번째로, 새로운 builder instance를 설치해야된다.

# docker buildx create --name <원하는 이름> --use
docker buildx create --name newbuilder --use

세번째로, 빌더 인스턴스를 시작해야된다.

docker buildx inspect --bootstrap

마지막으로, buildx를 이용해서 원하는 도커 이미지를 빌드하면된다.

docker buildx build --platform linux/amd64,linux/arm64 -t <your-image-name>:<tag> --push .

위와같은 방법으로 아키텍처 차이로인한 원인모를 에러에서 벗어날 수 있다.

내 컴퓨터가 M1 혹은 M2라면 늘 주의하자!(~~나 처럼 1시간 날리지 말고!~~)

AWS 중복 계정 이슈 발생시 해결방법

susong — Thu, 22 Jun 2023 18:41:44 +0900

해당 문제를 해결하기 위해 나눈 대화들..

혹시 AWS Skill builder와 같은 서비스를 이용하다가 갑자기 다른 계정으로 로그인된 경험이 있다면, 높은 확률로 중복 계정 이슈 때문일 것이다. 나는 아마존 Skill Builder Support와 나눈 수 많은 대화를 통해서 해당 문제가 발생할 수 있다는 것을 알았는데, 혹시 다른 누군가도 해당 문제를 겪을 수 있을까봐 해결방법을 작성해본다.

문제 원인

해당 문제는 당신이 여러 아마존 계정을 한 이메일로 가지고 있을 때 발생한다.

위 말은 그냥 들으면 말도 안되는 소리라고 생각이 될 수 있지만, 실제로 아마존에서는 가능한 문제이다. 왜냐하면, 아마존은 국제 서비스를 제공하고 있고 각 국가마다 새롭게 회원가입을 진행해야하기 때문이다.

당신이 a@naver.com으로 미국에서 가입을 했더라도, 일본에서 a@naver.com으로 회원가입을 할 수 있다.

이런 경우 각 국가 아마존 홈페이지에서 로그인을 할 때에는 큰 문제가 발생하지 않지만, skill builder나 aws같은 글로벌 서비스를 이용할 때에는 확실하게 문제가 될 수 있다.

대부분의 아마존 서비스들은 아마존 SSO를 이용하게되는데(아마존 아이디를 이용해서 다른 곳에서 로그인) 이 경우 내가 미국 계정과 일본 계정을 가지고 있다면 하나의 이메일에 두개의 비밀번호를 입력해도 둘 다 로그인이 되는 무시무시한 일이 발생하게 된다.

즉, 내가 미국에서 a@naver.com으로 가입하고 비밀번호를 1234 라고 했고, 일본에서 a@naver.com로 가입하고 비밀번호를 12345로 했다면, 나는 아마존 글로벌 서비스에서 a@naver.com를 1234로도 로그인 할 수 있고, 12345로도 로그인 할 수 있다.

하나의 이메일에 두개의 비밀번호가 있고, 각각 다른 계정으로 연결되어있다는 (이상한) 사실을 깨닫는다면 해결방법도 바로 알 수 있다.

해결방법 1

AWS측에서 제시한 방법은 새롭게 회원가입을 하는 것이다.

이전까지 사용한 Amazon아이디가 아닌 새로운 아이디로 글로벌 서비스에 회원가입을 하면 아마존 측에서 이전에 사용하고 있던 계정의 정보들을 해당 아이디로 병합해준다. 그냥 원래 아이디 2개를 병합해달라고 요청하면 어차피 데이터를 옮기기만 할 뿐 진짜 우리가 생각하는 병합이 아니기 때문에 진정한 의미에서의 해결은 아니다.

물론, AWS에서는 해당 방법을 권장하지만, 내게는 큰 메리트가 없어서 나는 해당 방법을 선택하지 않았다.

해결방법 2

이건 사실 문제점을 알기 전에는 해결하기 힘들지만, 문제를 인식하고 나면 해결이 쉽다.

내가 병합 옵션을 거절한 이유는 해당 방법이 복잡하기도하고, 새로운 아마존 계정을 또 만들기 싫었기 때문이다. 대신, 하나의 아이디에 두 개의 비밀번호가 존재할 수 있다는 것을 알았기 때문에 알맞은 비밀번호를 선택해서 로그인 하는 방식으로 문제를 해결했다.

나는 한 계정에서는 유로 구독을 해두고, 다른 계정으로 실제 자격증을 취득했다보니까 둘 다 필요해서 고민이였는데 비밀번호를 다르게 치면 각각 아이디로 로그인된다는 것을 알고는 필요에 따라서 취사선택하여 로그인하고 있다. 처음에는 크롬 자동완성으로 로그인 하다보니 랜덤인줄 알았는데 비밀번호를 정확하게 다르게 치면 각각 아이디로 잘 로그인이 된다.(여전히 신기하긴 하다..)

도대체 왜 아마존은 이런식으로 로그인을 만들어놔서, 이런 불편함을 만들까 싶었지만 생각해보니 아이디와 비밀번호같은 중요한 개인정보들이 한 국가 내에 있어야되는 규제 때문에 이렇게 했을 수도 있겠다 싶었다. 글로벌 기업의 SSO를 진행할 때 발생할 수 있는 문제(?)이기 때문에 혹시나 나와 같은 문제를 겪는데 해결방법도 감이 안잡힐 누군가를 위해서 글을 작성해둔다. 끝

TOPCIT 후기(수준 3)

susong — Tue, 20 Jun 2023 22:41:33 +0900

앞의 번호들은 크게 문제없을 것 같아서 지우지 않았다.

이번에 내가 소속된 이노베이션 아카데미가 IITP 예하였기 때문에, 무료 응시기회를 얻을 수 있어 생각지도 못하게 TOPCIT에 응시할 수 있게 되었다. 사실 존재만 어렴풋하게 알고 있었지, 어떤 시험인지에 대해서는 하나도 모르고 있었기 때문에 응시해볼 생각이 전혀없었는데, 재단에서 무료로 보게해주겠다고 하니까 '횡재했다!'라는 마음으로 응시하게 되었다.

처음에, 응시를 할 때만해도 미리 준비를 하고 가야겠다고 마음 먹었으나, 사람 일정이라는 것이 마음대로 되지 않아서 준비는 고사하고 전날 잠도 제대로 못자고 응시하게 되었다. 사실, TOPCIT 관련되어서 인터넷에 검색해봐도 별로 자료도 안나온다. 그래도 시험인데, 뭐가 나오는지는 알고가야겠다고 생각해서 새벽같이 일어나 아침 내내 유튜브, 블로그들을 뒤적거렸으나 도움받을만한 자료는 일체 나오지 않았다.

결국 알게된 것은, 이 시험이 전반적인 프로그래밍 능력 및 실무 능력을 평가하는 지표이고 몇몇 대학에서 레벨2 이상이면 졸업논문을 대체해주는 권위있는 시험이라는 것만을 알게되었다. 결국, 시험 내용은 아무것도 모르고 들어갔으나 결과는 나쁘지 않았기에 한번 글로 남겨본다.

시험이 끝나자마자 하고있던 프로젝트에 다시 집중해서 시험 결과도 한달이 지난후에야 검색해봤지만, 기억에 남는 것이 없는 것은 아니었다. 일단 시험 중에 가장 많이 했던 말은 '이게 맞나?'였다.

시험 내용중 많은 부분이 친한 동료들로부터 술자리에서 들었던 SI 업체 이야기들을 많이 가져다가 넣어놨다. 특히, 일 분배 방식에 대해 묻거나, 비용 산출같은 부분은 더더욱 그랬다. '이거 분명히 술자리에서 그 분이 이래서 문제라고 했던 것 같은데..' 싶으면 답에 그 내용이 있었다. 또 인상 깊었던 부분은 나는 서버 및 웹개발을 하는 사람인데 시험 문제에는 앱 개발 관련된 문제가 있던 것이었다. 특히, 안드로이드 SDK에 대해서 물을 때는 '이걸 내가 어떻게 알아..'라는 생각밖에 들지 않았다.~~(Flutter는 써봤는데 안드로이드는.. 몰라요)~~

만약에 시험을 준비하는 분들이 계신다면, 개인적으로는 대학교 공부를 한번 되돌아보고 가는 것을 추천드린다. 특히, DB와 네트워크 부분에서는 대학생 때 배웠던 내용들이 많이 나온다. 최근 DB설계를 몇 번 해보았거나 DB 수업을 들었다면 해당 부분은 문제가 없을 것이다. 코드 짜는 부분은 쉬우니 코드 보다는 다양한 개념적인 부분을 짚고 넘어가는 것이 좋을 것 같다.(특히 네트워크나 컴구 등등 기본적이고 개념적인 것들이 좀 나왔던 것 같다.)

또한, 문제가 객관식도 있지만 대부분 배점 높은 것들은 서술형이다. 꼭! 뭐라도 쓰자. 내 생각에는 뭐라도 써야 점수를 주는 것 같았다. 특히, 내가 알 수 없는 개념적인 것들에 대한 단어들을 쓰라고 하는 경우가 많았는데 '~~때문에 발생하는 문제라 프로젝트 중 겪어봤는데.. 이걸 한 단어로 정의한다고?' 싶은 것들이 좀 있었다. 나는 경험적으로 해결해봤던 문제인데 그 문제를 지칭하는 단어가 있다는 것도 놀래서 나는 서술형으로 쓰는 곳에 '그 문제를 어떻게 한 단어로 표현할지는 모르곘지만 ~한 원인이고 ~ 해결한다'라는 식으로 서술했는데, 점수가 낮지 않은 것을 보면 어느정도 참작해주었나 싶다.

객관식은 점수가 낮고, 서술형은 문제당 배점이 높으니 서술형에 되도록 집중하자.

이러거나 저러거나, 나는 일단 레벨 3의 성적을 받았고, 아래 추가적으로 주는 데이터에 따르면 상위 10%에 준하는 성적이라고 한다. 사실 나는 그정도의 사람이 아니라고 생각하는데, 일단 좋은 점수를 받은 것에 대해서는 매우 기쁘긴하다. 준비를 하나도 하지 못하고 받은 점수라 조금 머쓱하긴 하지만, 나중에는 한번 준비해서 봐도 좋겠다 싶다. TOPCIT 후기 끝!

AWS Certified Cloud Practitioner 합격 회고

susong — Wed, 14 Jun 2023 17:38:36 +0900

백, 인프라, 프론트 엔드 개발자로서 다양한 프로젝트를 경험한 이후, 나는 인프라 특히 클라우드 엔지니어가 되어야겠다고 판단했다. 하지만, 이 판단에는 한 가지 문제점이 있었으니, 바로 클라우드 직군은 신입을 잘 안 뽑는다는 것이었다. 실제로, 여러 프로젝트를 기반으로 6개 정도의 회사에 서류를 넣었으나 결과는 바로 광탈.. DevOps 직군으로 넣었지만 모두 회사의 기준에 나는 알맞지 않았다. 운이 좋게도 내가 어떤 부분이 부족해서 탈락했는지 알 수 있는 기회가 있었는데, 결국은 내가 신입이라서 불가능하다는 이야기였다.

여러 프로젝트 리딩 및 개발 경험은 높게 평가하지만, 내가 신입으로 지원을 했기 때문에 당장 프로젝트에 투입할 수 있을지 의문이 들고 회사로서는 현재 시장 상황상 모험을 할 수 없기 때문에 신입은 뽑지 않는다고 했다. 내가 부족함도 있겠지만, 이 경험적인 부분을 도대체 어떻게 메워야 할까 고민이 되었고, 그 고민의 결과로 나는 AWS 자격증을 선택하였다.~~(다 경력을 원하면 신입은 어디서 시작하냐고..!!)~~

내가 가고싶은 분야는 DevOps고 특히 클라우드 분야에서 특화된 데브옵스니 내가 많이 써 본 AWS 기준으로 DevOps 자격증을 따두면 신입으로서도 그리고 나중에 커리어 간에도 큰 이점이 될 것이라고 판단했다. 그렇게 나는 첫 AWS 자격증으로 가장 낮은 등급인 CLoud Practitioner을 선택하였다.

자격증 선택

첫 자격증으로 Cloud Practitioner을 선택한 이유는 2가지였다. 첫 번째로는, 시험이 어떻게 구성되었는지 알고 싶었다. 일단 시험센터에서 평가를 보기로 마음을 먹었는데 시험센터는 어떤 분위기인지 또, 평가는 어떻게 진행되는지 정확하게 알고 싶었다. 두 번째로는, 자격증을 합격하게 되면 다음 자격증에 사용할 수 있는 50% 할인 쿠폰을 제공해 주는데 이렇게 되면 2개 따는 비용과 1개 따는 비용이 크게 차이가 없기 때문이다. (Practitioner $100 + Associate $75(50% 할인) == 2개 $175 혹은 Associate 1개 $150)

향후 시험을 위해 시험을 경험도 해보고, 또 자격증 수도 늘린다는~~(4X AWS Crtificate을 쓰기위해서..)~~ 점에서 Practitioner을 선택하게 되었고, 현재까지는 이 판단이 나쁘지 않았다고 생각한다.

평가과정

나는 평가장소로 가장 최신의 시설을 가지고 있다고 소문난 선정릉의 SRTC를 선택했고, 실제로 가보니까 센터는 새 거 같다는 느낌이 충분히 났다. 위치 또한 선정릉역에서 5분 정도만 걸으면 되는 위치라 위치도 좋았고, 또 주변에 스타벅스도 존재해서 시험 보기 전에 대기하기도 충분할 것 같았다.

시험장 내부는 독서실처럼 되어있고, 경주마 눈가리개처럼 생긴 테이블로 구성되어 있다. 모든 자리 천장에는 나를 찍고 있는 CCTV가 존재했으며, 또한 사각을 줄이기 위한 별도의 CCTV도 위치하고 있었다. 내가 갔을 때는 약 5명 정도가 평가를 보고 있었는데, 나이대가 20대부터 50~60대까지 다양한 연령이 다양한 시험을 보고 있는 것을 확인했다. 다들 어떤 평가를 보고 있었는지는 알 수 없었으나, CFA나 토플도 평가를 하는 곳인 만큼 다들 인생을 걸고 열심히 평가를 받고 있는 것 같았다.

나는 11:30 평가이기 때문에 약 20분 전인 11:10에 평가 장소에 도착했고, 미리 별도로 필요한 사항이 있는지 확인했다. 나 같은 경우 영어로 이름을 설정했기 때문에 내 영문이 들어간 여권을 소지하였고, 해당 여권을 바탕으로 자기 신원 확인을 진행했다. 여권, 내 이름으로 된 신용카드(카드 내에 내 영문이름이 있어야 된다) 두 가지를 기준으로 내 신원 확인 절차는 진행되었고, 신원확인 후 감독관의 지시에 따라서 시험장에 입장하였다.

시험장은 큰 통창으로 구성되어 시험장이 내려다보이는 제어실과 그것보다 약간 낮은 곳에 위치한 독서실로 구성되어 있었다. 입장을 위해서는 감독관이 있는 제어실에 내 모든 짐을 맡겨야 했고, 그 이후에는 감독관의 지시에 따라서 모든 주머니가 비어있는 것을 확인했다. 또한, 팔과 발목 같은 곳에 어떤 물건이 있을 수 있으니 해당 부분에 대한 확인 절차도 진행했다.

이렇게 내 몸에 아무 물건이 없다는 것을 확인한 후에, 내 얼굴을 촬영하고, 또다시 한번 내 얼굴과 신분증 상의 얼굴을 대조한 후 입장하겠다는 서류에 서명했다. 해당 서명 이후에서야 시험장에 입장할 수 있었고, 감독관은 내가 평가를 진행할 수 있도록 자리까지 동행해 주었다.

평가 내용

그렇게 평가는 진행되었고, 평가는 크게 어렵지 않았다. 나 같은 경우 덤프는 풀지 않았지만, AWS Skill builder에서 제공하는 모의고사를 한번 봐 본 상황이었고, 해당 AWS Skill builder와 유사한 UI를 가진 화면에서 평가를 진행했다. 솔직히, 컴퓨터가 좋은 사양이 아니어서 중간중간 로딩 때마다 렉 걸린 것 아닌가 의심이 들었지만 1분 정도 기다리면 화면이 진행되기에 그냥 프로그램이 조금 무거운 것 같다고 판단했다.

평가는 시험 설명과 동일하게 65문제로 진행되었으며, 나는 약 30분 정도 이후에 평가를 마치고 나올 수 있었다. 입문자를 위한 평가답게 평가 자체에 크게 함정도 없었고, 문제 자체의 난이도도 낮았다. 대부분 '~의 상황에서 적절한 서비스는?' 혹은 '공유 책임 모델에서의 각자의 책임' 혹은 '클라우드의 장점' 등을 이야기하는 부분이었다. 대부분의 문제들은 한 번 이상 AWS를 이용하여 서비스를 배포해봤다면 쉽게 풀 수 있는 문제들이었다.

30분 정도 풀고 나니, 헷갈리는 문제가 5개 정도 있어서 그 부분만 다시 한번 확인을 했고(Flag를 지정해서 마지막에 확인할 수 있다) 5개 모두 다 틀리더라도 합격이기에(70% 이상이면 합격이다) 가벼운 마음으로 평가를 마무리했다. 잠깐의 설문조사를 마치고 나면, 내가 PASS인지 아닌지 확인할 수 있는데, 그 부분에 PASS가 적혀있었고 빠르게 시험을 마무리하고 나올 수 있었다.

PASS인 것은 확실한 상황이지만, 자격증 합격 내용에 대한 확인을 받기 위해서는 AWS의 결과 메일을 받아야되는 구조였다. 시험장 화면을 통해 5 영업일 내에 평가에 대한 결과를 메일로 보내준다는 안내를 받았는데, 해당 메일이 오면 그것을 기반으로 다음 시험을 예약할 예정이다. 다음 평가는 아마도 Associate등급의 Developers일 것 같다. DevOps 자격증을 딸 때까지 파이팅..!

합격증은 금방 날라왔다.

쿠버네티스에 대한 흥미로운 사실들 24가지

susong — Thu, 8 Jun 2023 19:53:30 +0900

1. AWS는 너무나도 시장 지배적이었고, 구글은 클라우드 시장에서 자신들만의 차별점을 만들어내고 싶어했다.

2. 구글은 자신들만의 정교한 인프라 전문지식을 가지고 있었고, 이를 클라우드에 적용하는 과정을 지속적으로 진행하고 있었다.

3. 컨테이너 기술은 도커 이전에도 존재했었고, 대부분의 개발자들은 몰랐지만 소수의 개발자들은 컨테이너 기술을 사용해왔다.

4. 컨테이너 기술이 도커에 와서야 대중화된 것은 도커가 컨테이너 기술을 매우 쉽게 추상화하는 것에 성공했기 때문이다.

5. '누구나 도커를 사용할 수 있다'라는 점 그리고 소프트웨어 패키징 개념은 도커가 컨테이너 기술의 표준이 될 수 있도록 도와줬다.

6. 도커 이전에도 대규모 트래픽 처리를 위한 좋은 프레임워크는 많았지만, 이들 대부분은 대기업들만이 사용 가능했다.

7. 구글이 도커 이전에 사용한 컨테이너 툴의 이름은 Borg이다.

8. AWS를 따라잡아야한다는 구글의 열망과 2013년 혜성같이 나타난 도커의 등장은 쿠버네티스 개발의 가장 큰 원동력이다.

9. 첫 쿠버네티스 개발은 총 3인이서 시작하였다.(oe Beda, Brendan Burns, and Craig McLuckie)

10. 쿠버네티스 오픈소스를 결정한 이후, 구글 경영진들에게 오픈소스에 대한 정당성을 설명하는데 상당한 시간을 소요했다.

11. 쿠버네티스는 2014년 도커콘에서 발표되었다.

12. 2014년 도커콘에는 쿠버네티스 외에도 다양한 컨테이너 오케스트레이션 툴들이 발표되었다. 그 중 하나로 페이스북에서 발표한 typperware라는 것이 있다.

13. 도커도 훌륭하지만, 엔터프라이즈 레벨에서 쿠버네티스가 가진 강점은 압도적이었고, 이 때문에 도커는 2013년 발표당시보다 많은 위상을 잃었다.

14. 처음부터 쿠버네티스가 오케스트레이션 툴의 표준처럼 작동한 것은 아니었고, 오히려 초반에는 다른 프로젝트들에 밀리는 경향이 있었다.

15. mesos 혹은 docker swarm은 각자 다른 장점을 가지고 있었고, 넷플릭스와 같은 대형 IT회사는 초반에 mesos를 선택했다.

16. 2016년이 될 때까지 쿠버네티스 코어 개발자들은 아주 고강도의 개발을 진행했고, 그 때문에 번아웃 직전의 상황에 몰렸었다. 그렇게 개발한 이유에는 코어 개발자들이 각자 다른 매니저에게 보고를 해야되는 상황이 있었다.

17. 2016년이 되어서, 쿠버네티스는 하나의 팀으로 구성되었고 새로운 매니저는 지속가능한 개발을 위해 사람들을 끌여들이고, 각자에게 책임감을 부여하는 방식으로 지속적인 개발을 꾀했다.

18. 쿠버네티스는 초기에 '구글의 라이센스(Apache License 2.0)'였고, 이 때문에 상당히 많은 개발자들은 오픈소스 개발 참여를 꺼렸다. 특히, Apache License 개발 참여에 반대하는 기업문화를 가진 개발자들은 참여가 어려웠다.

19. 해당 문제점의 해결책으로 쿠버네티스는 구글 산하가 아닌 CNCF(Cloud Native Computing Foundation)으로 소속을 옮겼고, 더 많은 개발자들이 개발에 참여할 수 있도록 독려했다.

20. 2016년 발표된 포켓몬 고는 쿠버네티스 위에서 작동하도록 설계되었고, 포켓몬 고의 폭발적인 성공과 그를 뒷받침하는 쿠버네티스의 성능은 쿠버네티스가 성공적인 툴이라는 것을 증명해냈다.

21. 당시 포켓몬 고가 만들어내는 트래픽은 당초 회사가 예측한 것의 50배 이상이었다. 쿠버네티스는 50배가 넘는 트래픽을 받아내었다.

22. 2017년, 아마존이 AWS에 쿠버네티스를 사용한 EKS 툴을 발표함으로써 컨테이너 오케스트레이션 툴 간의 경쟁은 종료되었다.

23. 쿠버네티스가 승리할 수 있었던 가장 큰 원인은 수많은 개발자 군단에 있다. 다른 툴들에 비해서도 압도적인 커밋양을 바탕으로 빠르고 안정적인 개발을 해낼 수 있었다.

24. 쿠버네티스가 성공할 수 있었던 중요한 키 포인트는 개발자 커뮤니티를 만들어냈다는 것에 있다. 개발자 커뮤니티와 생태계를 만들어냄으로써 코드 기여뿐만 아니라 수많은 피드백들을 받을 수 있었다.

출처 : Kubernetes: The Documentary [part1] [part2]

42Benefit 개발 회고

susong — Fri, 28 Apr 2023 15:53:30 +0900

또 하나의 프로젝트가 성공적으로 마무리되었다.

이번 프로젝트는 내가 기획하고 제안하여 개발까지 완료했는데, 결과가 예상보다 훨씬 좋아 매우 기분이 좋다. 프로젝트를 성공적으로 마무리한 기념으로, 이 글을 통해 개발 과정에 대한 생각과 타임라인을 정리해보려 한다.

개발하게 된 계기

42서울은 교육생들에게 다양한 교육 혜택을 제공한다. 구름EDU, 프로그래머스 등 강력한 혜택이 준비되어 있지만, 아쉽게도 이를 알 수 있는 방법은 매우 제한적이었다. 따라서, 몇몇 혜택들은 이용되지 않는 상태였고, 이로 인해 업체들도 혜택 제공에 소극적인 악순환 구조가 형성되어 있었다.

사실 42서울에는 이전에 베네핏 페이지가 있었다. 2020년에는 42베네핏이라는 사이트가 존재하여 42서울 교육생들이 혜택을 확인할 수 있었다. 그러나 담당자의 퇴사로 인해 사이트는 폐쇄되어 42베네핏은 점차 잊혀졌다.

그럼에도 불구하고, 일부 교육생들은 이전에 잘 작동하던 혜택 시스템을 그리워하였고, 이러한 요구가 지속적으로 제기되었다. 42서울 내부에는 신문고라는 제도가 있어 교육생들이 의견을 제시할 수 있는데, 이곳에서도 베네핏 관련 글들이 자주 올라왔다. 하지만, 문제점은 지속적으로 개선되지 못했는데, 내가 생각한 이유는 재단 내부의 인력 부족 등으로 인해 직접 베네핏 사이트를 제작하기 어렵다는 것이었다.

그래서 내가 직접 이 문제를 해결해보려고 생각했다.

개발 제안과 시작

위 글을 보는 순간 나는 내가 해야겠다고 생각했고 그 즉시 Doosoo 팀장님께 '내가 개발하겠습니다!'라는 취지로 DM을 보냈다. DM을 보낸 날 바로 팀장님과 미팅이 성사되었고, 나는 해당 프로젝트에 대한 내 생각과 열의를 열심히 이야기했다. 사실 처음에는 재단이 아닌 교육생이 중심이 되어서 개발하는 것에 대해서 우려가 있었다. 특히, 이전에 담당자가 사라지자 사이트도 사라진 전례가 있었기 때문에 더욱 조심스러울 수 밖에 없는 일이었다.

나 또한 그런 문제에 대해서 깊이 있게 공감했고 해당 문제는 내게도 적용되는 문제이기에 나는 다음과 같은 방법을 제안 드렸다. 일단 개발은 내가 진행하되, 개발 후에는 최대한 오픈소스로 코드를 공개함으로써 지속적으로 관리 접근성을 높이겠다고 제안 드렸다. 또한, 혹시 모른 사태를 막기위해 관리자쪽에서 노션을 제작하여 투트랙으로 서비스를 제공할 것을 제안드렸다.

이런 투트랙 정책에 대하여 어느정도 합의가 도출되어 다행히도 나는 이 개발건을 공식적으로 맡게 되었다. 프로젝트를 시작했다는 마음이 들자마자 나는 어떤 사람과 함께 이 일을 하는 것이 좋을지 생각하기 시작했다. 이 프로젝트를 어떻게 짜 갈 것인지에 대해서 고민한 후 어떤 동료와 함께 이 프로젝트를 해야 성공적으로 마무리할 수 있을지 고민했고, 그 결과 이전에 스터디를 함께 했고, 3D관련되어서 관심이 많았던 선글과 함께 프로젝트를 하게 되었다.

어떻게 개발할 것인가?

선글에게 이런 재미있는 프로젝트가 있는데 함께할지에 대해서 물어보니, 선글은 고맙게도 바로 승낙해주었고 승낙하자마자 바로 당일날 바로 어떻게 개발할 것인지에 대해서 논의를 진행했다. 일단 내가 원하는 것은 한페이지 짜리이면서, 기존의 틀을 깬 사이트여야했고, 구체적으로는 three.js를 이용해서 인터렉티브하게 제작된 사이트를 원했다.

고맙게도, 내 생각에 선글은 많은 부분 동의해주었고 우리는 3D를 기반으로한 프로젝트를 어떻게 디자인할지에 대해서 논의하기 시작했다. 가장 먼저 확인한 것은 three.js에서 공식적으로 제공하는 레퍼런스들을 기반으로 확인했는데 정말 좋은 레퍼런스들이 많이 있었지만, 정말 참조하고싶은 레퍼런스들은 참조하기 쉽지않았다.

가장 하고싶었던 것은 POLA에서 만든 어머니의 날 기념 페이지였는데 구현방법에대해서 논의하다 도저히 안되겠다고 생각해서 포기했다. 디자인에 대해서 고민을 하며, 우리는 42가 어떤 곳인지에 대해서 다시 생각했고 42일원은 은하수를 여행하는 히치하이커라는 컨셉을 다시 상기하게 되었다.

우리가 히치하이커이니, 길을 잃은 우리에게 단서를 주는 컨셉을 가지자!라고 판단한 직후 바닷물을 표현하는 레퍼런스를 찾게되었고 이 레퍼런스를 기준으로 개발하기로 마음먹었다. 그렇게 우리는 바닷물 한가운데에 단서를 두고 우리 42일원들(표류하는 여행자)이 이 단서를 찾아 앞으로 나아가는 의미를 담아서 개발하게 되었다.

개발 결과

https://benefit.42seoul.link

구체적인 개발 과정에 대해서는 나중에 발표를 통해서 언급할 예정이라, 이 글을 통해서는 진행하지 않았다. 다만, 이번 개발을 통해서 느낀 것들이 더욱 많았는데 가장 크게 2가지를 뽑으라면, 네트워크의 중요성과 새로운 기술에 대한 호기심이었다.

먼저, 프로젝트 제안을 흔쾌히 승낙해준 동료 선글에게 감사한다. 그리고 이번 기회를 통해 좋은 동료를 곁에 두는 것이 얼마나 중요한 일인지에 대해서 다시한번 깨달았다. 큰 일은 혼자 할 수 없기에, 좋은 동료와 함께 해야되는데 만약 내게 이런 좋은 동료가 없었다면 이번 프로젝트를 성공적으로 마무리할 수 없었을 것이다. 기회라는 것은 언제 어떻게 올지 모르는 것이기에, 늘 좋은 동료를 많이 사귀고 주변에 두어야겠다고 생각했다.

두번째로는, 새로운 기술에 대한 지속적인 관심은 필수적이라는 것이다. 내가 발전하는 개발자로서 앞으로 남은 생을 살 예정이라면 반드시 새로운 기술을 향해서 고개를 돌려놓아야된다고 생각했다. 이번 프로젝트는 기존에 해보지 않았던 three.js를 통해서 진행한 프로젝트였는데, 만약 내가 이 기술에 대해서 평소에 관심을 가지지 않았다면 이번 프로젝트에 이 기술을 가용하지 않았을 것이다. 새로운 기술에 늘 관심을 가지고 있었기에 적용할 수 있었고, 덕분에 할 수 있는 것이 하나 더 늘었다.

결과적으로 이번 프로젝트는 매우 성공적이었다.

실제로 커뮤니티에서도 뜨거운 관심을 받았고, 또 지나가는 사람들마다 내가 사이트를 개발한 것을 알아주고 또 멋지다고 많은 칭찬을 들을 수 있었다. 사소한 문제일지라도 기술을 통해 문제를 해결해나가고 그것을 많은 사람들에게 경험하는 것은 늘 짜릿하다.

내가 공부하고 있는 이 프로그래밍이 취업이나 먹고살기위한 기술이 아닌, 내 상상을 현실로 만들어주는 도구임을 늘 상기하고 살아야겠다. 회고 끝.

PS) 개발한 사이트의 접속자 수를 보는 것은 늘 즐겁다.

크롤러의 함정: 42Noti 서비스에서 발생한 401 에러와 그 해결 과정

susong — Mon, 10 Apr 2023 19:39:04 +0900

4.10. 갑자기 나타난 Noti 에러

상용 서비스에 크롤러가 포함되어있다면 늘 주목하자

내가 서비스하고 있는 프로그램 중에서 42Noti가 오늘 갑자기 에러를 뿜어내기 시작했다. 나는 내 프로그램들에 문제가 발생하면 즉각적으로 알 수 있도록 Slack WebHook을 걸어두는데, 이 웹 훅에 401에러가 지속적으로 발생하기 시작한 것이다. 401 코드를 보아하니 권한에서 문제가 생긴 것 같은데.. 도대체 무엇이 문제일까 직접 한번 확인을 해봐야만 했다. 그러면서 머리를 스치고 지나가는 것이 최근에 내가 크롤링하는 부분이 문제가 되었나 싶었다. 최근에 크롤링 하는 사이트의 UI가 변경되면서 문제가 되었을 것이라는 추측을 했다.

401에러의 원인

결과적으로 예상은 적중했다. 내 42Noti는 3주마다 갱신해야되는 Secret를 셀레니움으로 제작한 42API_RENEW 패키지를 이용해서 진행하는데, 이 코드가 문제가 된 것이었다. 시크릿을 정상적으로 갱신해주지 못하니, Noti가 API Request를 하기 전에 인증하는 과정에서 에러가 발생한 것이다. 그래서 왜 이 셀레니움 코드가 정상적으로 작동하지 않았는지 확인해보니, 예상했던대로 UI변경으로 인하여 기존 로직이 정상적으로 작동하고 있지 않았다.

42Intra에 로그인하는 과정에서 UI 컴포넌트의 Depth가 하나 더 생겼으며 로그인 버튼의 이름이 변경되었다. 42는 언제나 갑작스럽게 UI를 변경하는데 최근에는 변경하지 않아서 안심하고 있던 내 실수였다. 다행히도 내가 작성한 코드라서 바로 문제를 해결할 수 있었고, 몇가지 수정사항을 덧붙여 시스템을 복구시켰다.

얻을 수 있었던 교훈

일단 크롤러를 사용하는 서비스는 안심할 수 없다는 것을 확인했다. 명세가 정해진 API와 같은 경우에는 명세가 변경되기 전에 충분히 인지할 수 있는 시간이 있는 반면, 크롤러는 내가 그냥 긁어오는 것이기 때문에 서비스 제공자에게 알려달라고 하기 어렵다. 이런 경우 그냥 내가 잘 주목하고 있다가 문제가 되자마자 빠르게 변경해야되는데, 크롤링 코드의 수명주기가 정말 짧다는 것을 다시한번 인지했다.

또한, 인프라의 바닥에서 사용하는 도구를 만들 경우 하나의 도구가 여러 서비스를 마비시킬 수 있다는 것을 인지했다. 내가 만든 42API_RENEW는 이 NOTI에서만 작동하는 것이 아니라 여러 42 서비스에서 작동하고 있다. 인프라의 밑바탕에 있는 서비스가 마비되니까 다른 모든 서비스가 마비되는 것을 확인헀고, 그렇기에 바탕이 되는 서비스의 중요성을 다시 한번 느꼈다.

마지막으로, 에러를 감지할 수 있는 방법을 늘 곁에 두어야된다는 것을 절실히 확인했다. 이번에 만약 Slack 알람으로 에러 로그를 찍고있지 않았다면 우리 팀원들 그 누구도 해당 문제가 발생했는지 알 수 없었을 것이다. 아마 여러 알림이 안 올라오고 나서 즉, 문제가 발생한 후에야 해당 문제를 인지하고 수정할 시도를 했을 것이다. 하지만, 이번에는 에러를 감지할 수 있는 수단에 접근성이 높았고 덕분에 실제로 문제가 발생하기 전에 문제를 해결해 낼 수 있었다.

이번에 얻은 교훈을 바탕으로 앞으로는 개발을 진행할 때 모니터링을 할 수 있는 비용을 최소로 하고 늘 내가 알람을 받을 수 있도록 환경을 구성해야겠다.

프로그래밍으로 사령관 표창 받은 이야기

susong — Sun, 9 Apr 2023 20:24:07 +0900

보안일일결산 자동연결 프로그램 제작이 오늘의 이야기 주제다.

군대는 왜 이렇게 비효율적일까?

군대에서의 생활은 언제나 비효율적이라는 생각이 들었다. 군대라는 조직의 특성과 프로그래밍에 대한 접근성 등 여러 제약적인 요인들이 있었지만, 그럼에도 군대의 일 처리 방식은 상당히 비효율적으로 느껴졌다. 규율과 질서를 유지하기 위해 꼭 필요해 보이지 않은 일들도 해야 했고, 이 때문에 불필요한 업무가 많았다.

그중에서도 보안 일일 결산은 특히 주목할 만했다. 이 일일 결산은 크게 보안적인 향상을 가져오지 못하는 것 같지만, 매일매일 해야 하는 일이었다. 게다가 이 일일 결산은 각 부서별로 얼마나 잘 수행했는지가 부대 지휘관의 인사 고과에 영향을 미치기 때문에, 지휘관들은 이에 매우 민감했다. 실무자들은 이를 잘 수행하지 않으면 성과 상여금이 깎일 수 있어서 꼭 해야만 했다.

그런데, 심각한 문제는 이 보안 일일 결산이 모든 사람들에게 동기부여가 되지 않았다는 것이다. 간단한 체크만 하고, 보안을 잘 지키겠다는 다짐을 복사 붙여 넣기 하는 것이기 때문에, 대부분의 사람들은 이것을 왜 해야 하는지에 대해 납득하지 못했다. 납득하지 못하니, 자주 놓쳤고, 이로 인해 지휘관들도 상황을 이해하면서도 답답해했을 것이다.

어차피 매번 같은 시간에 하는 거 자동화 알람을 만들면 어떨까?

그래서 나는 이 괴리를 프로그램으로 해결해보려고 결심했다. 현재 상황을 분석한 뒤, 제작 기간 2일이 걸린 보안 일일 결산 자동 연결 프로그램을 만들었다. 정해진 시간에 원하는 프로그램을 작동시킬 수 있는 쉘 프로그램을 제작했고, 간단한 HTML, CSS, JS를 이용해 해당 시간에 보안 일일 결산 타이머를 화면에 띄우도록 했다. 또한, 바로 보안 일일 결산 사이트로 연결될 수 있도록 리다이렉션을 여러 곳에 설정했다.

아주 간단하지만이 문제를 해결해낼 수 있는 프로그램이 완성되었고, 이 프로그램은 우리 보안 담당관을 통해 상급 부대 사령부까지 전달되었다. 그 결과 얼마 지나지 않아 보안 상점과 함께 사령관의 표창을 받게 되었다. 더욱이, 나중에 우리 부대에 사령관님이 방문하셨을 때는 프로그램을 잘 만들었다며 격려의 말씀까지 해주셨다.

이렇게 간단한 프로그램을 통해 군대에서 겪었던 비효율적인 문제를 개선할 수 있었다. 프로그램을 사용하게 되면서 보안 일일 결산을 놓치지 않게 되었고, 이로 인해 부대 전체의 보안 수준이 향상되었다. 또한, 이러한 프로젝트를 통해 프로그래밍이 실생활에서 얼마나 큰 도움이 될 수 있는지를 몸소 느낄 수 있었다.

군대와 같은 조직에서 비효율적인 문제를 해결하기 위해 프로그래밍을 활용하는 것은 이제 선택이 아닌 필수라고 생각된다. 이를 통해 조직의 업무 프로세스를 개선할 수 있으며, 개개인의 생산성을 높일 수 있다. 그리고 이러한 경험을 통해 프로그래밍 역량을 강화하고, 더 나은 소프트웨어를 개발할 수 있는 기회가 된다.

군대에는 프로그램이 더욱 필요하다.

내 생각에 따르면 군대의 발전 방향은 더 이상 인간의 노력에 의존하는 것이 아니라, 정교한 알고리즘을 통해 문제를 해결하는 방식이어야 한다. 굳이 인간이 수행하지 않아도 되는 불필요한 행정 작업들은 프로그램을 통해 대체되어야 하며, 전투와 같은 핵심 분야만 인간이 수행해야 할 것이다. 현재 우리나라 육군의 업무 방식은 인력 중심적으로 구성되어 있다.

단순하게 반복되는 작업조차도 사람이 직접 수행해야 하는 이런 방식은, 인구가 줄어들고 있는 21세기 대한민국에서는 더 이상 지속 가능하지 않다. 이번 프로그래밍을 통한 문제 해결을 통해, 이렇게 해결할 수 있는 방법이 얼마나 많은지 상상조차 가지 못했다. 특히 인력 관리와 군수와 관련된 부분에서는 프로그램의 필요성이 더욱 부각되어야 한다.

군대에서 인력 관리 카카오톡 봇 등 여러 가지 도구들을 직접 만들어 사용해 본 경험이 있고, 덕분에 높은 고과를 받을 수 있었다. 앞으로 우리 군에도 더 많은 프로그래머들이 투입되어 인간이 직접 하지 않아도 되는 부분은 프로그램이 대신하고, 전투력과 관련된 중요한 부분만 인간이 직접 수행하는 선진 군이 되기를 기대한다. 이렇게 하면 진정한 의미의 육군 아미타이거가 될 수 있을 것이라고 생각한다.

Python Sumy 사용법 및 후기(파이썬 요약 라이브러리)

susong — Tue, 4 Apr 2023 17:32:21 +0900

사용방법

1. 일단 Sumy를 사용하기 위해서는 JDK가 필요하다 먼저 JDK를 설치하도록 하자

sudo apt install openjdk-17-jdk

java -version # 잘 설치되었는지 확인하자

2. 필요한 라이브러리를 설치하자

#반드시 python과 pip은 설치되어있어야한다
pip3 install sumy # pip3 혹은 pip
pip3 install konlpy # konlpy는 한국어를 사용하기 위한 형태소분석기이다.

3. 예제 코드 작성

from sumy.summarizers.lex_rank import LexRankSummarizer
from sumy.nlp.tokenizers import Tokenizer
from sumy.parsers.plaintext import PlaintextParser
from konlpy.tag import Kkma

with open("test.txt", "r", encoding="utf-8") as f:
    document = f.read()

tokenizer = Tokenizer(language='ko')
parser = PlaintextParser.from_string(document, tokenizer)
summarizer = LexRankSummarizer()
summary = summarizer(parser.document, sentences_count=3)

for sentence in summary:
    print(sentence)
    
# 결과물 (입력은 https://simsimhamstudy.tistory.com/51 내용을 넣었다)
ubuntu:~/BlogBoost$ python3 test.py 
섬뜩한 Github Action 오류 창 어느 날 언제와 같이 로컬에서 개발을 한 후, Develop에서 확인을 하고 그 다음에 릴리즈 브랜치로 내 프론트 코드를 옮겼는데 위와 같은 오류가 나타나 버렸다.. Develop도 아니고 Release에서 오류 라니.. 식은땀이 나고 온 몸이 저려 온다.
디테일을 확인하니 아래와 같은 내용을 확인할 수 있었다.
결과 문제 해결! 아래 사진과 같이 문제없이 작동하는 것을 볼 수 있다!

평가 : 쓸만하지는 않다.. 일단 요약은 해줌

동일한 Input 값을 ChatGPT에 넣으면?

Github에서 더 이상 18.04 버전을 제공하지 않아 에러가 발생했습니다.
문제 해결을 위해 Github Action build를 변경해야 합니다.
.yml 파일에서 runs-on 부분을 'ubuntu-latest'로 수정하여 문제를 해결할 수 있습니다.

# SUMY로 돌린 결과 상당한 차이가 있는 것을 볼 수 있다..
섬뜩한 Github Action 오류 창 어느 날 언제와 같이 로컬에서 개발을 한 후, Develop에서 확인을 하고 그 다음에 릴리즈 브랜치로 내 프론트 코드를 옮겼는데 위와 같은 오류가 나타나 버렸다.. Develop도 아니고 Release에서 오류 라니.. 식은땀이 나고 온 몸이 저려 온다.
디테일을 확인하니 아래와 같은 내용을 확인할 수 있었다.
결과 문제 해결! 아래 사진과 같이 문제없이 작동하는 것을 볼 수 있다!

결론 : GPT 쓰자(무엇을 요약했는지 확인하고 싶다면 링크 클릭)

섬뜩한 Github Action 에러 해결방법(Build image deprecated)

susong — Mon, 3 Apr 2023 22:09:40 +0900

섬뜩한 Github Action 오류창

어느날 언제와 같이 로컬에서 개발을 한 후, Develop에서 확인을 하고 그 다음에 릴리즈 브랜치로 내 프론트 코드를 옮겼는데 위와 같은 오류가 나타나 버렸다.. Develop도 아니고 Release에서 오류라니.. 식은땀이 나고 온 몸이 저려온다.

일단, 가장 먼저 한 행동은 git revert를 한 후 commit을 진행했다.

하지만, 동일한 문제가 또 발생하였고 그때가 되어서야 문제를 확인하고 해결해야겠다고 생각했다.

그래서 문제는?

결론은 내 코드의 문제는 아니었다.(괜히 겁 집어먹고 revert시켰는데.. 다시 돌려야겠다..)

문제는 마침 오늘부터 Github에서 build 에서 18.04 버전을 제공하지 않았기 때문이었다. (23.4.3부터..)

그래서 아래와 같은 에러가 찍힌 것이었다.

deploy

The ubuntu-18.04 environment is deprecated, consider switching to ubuntu-20.04 or ubuntu-22.04 (ubuntu-latest). For more details, see https://github.com/actions/runner-images/issues/6002

deploy

GitHub Actions has encountered an internal error when running your job.

디테일을 확인하니 아래와 같은 내용을 확인할 수 있었다.

Breaking changes

We have started the deprecation process for Ubuntu 18.04. While the image is being deprecated, You may experience longer queue times during peak usage hours. Deprecation will begin on 2022/08/08 and the image will be fully unsupported by 2023/04/03

결론은? Github Action build 부분을 변경된 부분에 맞게 변경하면 된다.

해결방법

1. 루트 디렉토리에 가서 .github로 들어간다.

2. workflow에서 문제가 된 .yml 파일을 선택한다.

3. 문제가 되는 부분을 수정한다.

- 나 같은 경우 아래에 있는 jobs : deploy : runs-on 의 내용이 ubuntu18.04였다.

- 테스트 결과 ubuntu-latest에서도 문제가 없어서 현재는 latest로 바꾸어두었다.

- 바꿀 때 꼭 해당 버전에서도 문제없는지 확인하고 바꾸자!

결과

문제 해결! 아래 사진과 같이 문제없이 작동하는 것을 볼 수 있다!

AWS IAM 계정 별칭 지정하는 방법

susong — Mon, 3 Apr 2023 21:15:55 +0900

모자이크 한 부분이 계정 ID이다.

프로젝트를 진행하다보면, 내 계정에서 프로젝트를 진행하는 경우도 많지만 어쩔 수 없이 여러 IAM 계정을 이용하게 된다. 특히 IAM 계정이 가지고 있는 권한 제어에 대해 이해하면 할 수록 ROOT는 초기에만 사용하는 계정이 되고 내가 해야되는 역할에 따라서 각기 다른 IAM 계정을 이용하게 되는 것 같다.

하지만, 큰 문제점 저기에 있는 계정 ID를 외우기가 너무 어렵다.

숫자 12개로 구성되어있다보니까, 외우기도 어렵고 크롬 자동완성에 의존하자니 다양한 계정이 어떤 ROOT에 대응하는지 확인할 방도가 없다.

그래서 AWS에서 제공하는 서비스가 계정 별칭이다. 그러면 어떻게 설정하는지 알아보자

1. IAM 계정으로 로그인한다.(이 때 해당 계정은 반드시 IAM설정할 수 있는 권한이 있어야된다.

2. IAM DashBoard로 들어간다.

오른쪽 AWS 계정에 주목하자

3. 계정 별칭에서 편집을 눌러서 내가 원하는 계정으로 별칭을 설정해준다.

4. 앞으로 로그인 할 때는 해당 별칭을 기준으로 로그인하면 된다.

- 예) https://{당신의 계정 별칭}.signin.aws.amazon.com/console

5. 이제 간단하게 로그인하자!

최종 결과물

EC2(Ubuntu) 가상 메모리 설정하는 방법

susong — Mon, 3 Apr 2023 20:16:51 +0900

가끔 서버에서 빌드를 하다가 서버가 죽어버리는 경우가 있다.

이런 경우 대부분의 케이스는 메모리가 부족해서 벌어지는 일인데, 평소에 우리가 사용하는 OS들에서는 메모리가 부족한 경험을 하기도 어려울 뿐더러 가상메모리가 설정되어있어서 부족하다고 멈추는 경우는 없다.

하지만, 우리가 EC2를 사용하는 경우에는 1기가 혹은 많아야 2기가의 렘으로 사용하게 되는데, 이런 경우에 평소 서비스할 때에는 서비스 볼륨에 따라 문제가 없는 경우가 많지만 빌드나 특정 초기작업에서 문제가 생길 수 있다.

나 같은 경우에는 EC2를 마이크로 혹은 small을 자주 사용하는데, 그렇기 때문에 서비스를 시작할 때는 꼭 아래와 같은 과정을 거친다.

1. EC2 Instance를 제작할 때 용량을 조금 더 추가한다

- 많이는 필요없고, 내가 제공할 서비스에 맞춰서 설정하면된다.

- 나같은 경우에는 설계에서 필요한 데이터양 + 2GB정도를 한다.

- EC2에서 SSD를 추가하는 경우 gp2 기준으로 월 $0.1가 추가된다.

2. 다음과 같은 명령어를 순차적으로 실행한다.

# 먼저, swap 파일을 생성해야 한다. 아래 명령어로 먼저 /swapfile을 만들자
# 모든 명령은 shell에서 진행하면 된다.
# 미리 해당 계정 아이디에 sudo 권한을 주자 혹은 루트로 해도 된다.
sudo fallocate -l 2G /swapfile

# 생성된 swap 파일의 권한을 설정한다.
# 여기에서 권한은 반드시 600으로 해야된다. 
# swapfile의 읽기 쓰기 권한을 root에게만 제공해서 불필요한 보안 문제를 야기하지 말자
sudo chmod 600 /swapfile

# swap 파일을 포맷한다.
sudo mkswap /swapfile

# swap 파일 활성화.
sudo swapon /swapfile

3. 원하는 대로 swapfile 우선순위를 설정한다.

sudo sysctl vm.swappiness=10

나는 개인적으로 메인메모리가 가득차면 바로 가상메모리를 끌고오는 경우가 많다.

- 이 것은 내가 제공하는 서비스가 메인메모리를 넘어섰다면 지속적으로 넘어서는 경우가 많아서이다.

- 서비스의 목적에 따라서 설정하자

- 10이면 메인메모리가 다 차면 바로 가상메모리를 사용한다.(범위는 0 ~ 100이다)

- 당연하지만 가상메모리는 메인메모리보다 훨씬 느리기 때문에, 10보다 아래값을 사용하는 것은 지양하자

4. 간단한 가상메모리 설정 끝! 이후 보안문제들을 해결하면된다(비밀번호 등)

15분이면 충분하다 배포방법(AWS EC2, Vercel)

susong — Fri, 31 Mar 2023 16:40:43 +0900

15MinIsEnough 서비스 배포구조

배포 고려사항

1. (해커톤 상황 고려)내가 잘 아는 기술 스텍을 이용하자

- EC2, Vercel 이용하기로 결정, Amazon RDS 이용은 고려하였으나 해커톤 기간 중에는 EC2 안에 마리아 DB사용하기로 결정

2. CORS, HTTPS문제는 최대한 간편하게 해결하자

- Nginx를 리버스 프록시로 이용, 해당 문제 편안하게 해결

- CertBot 및 nginx.conf 수정을 통해서 해당 문제 해결

3. 백 서버가 정상작동하지 않아도, 프론트서버에서 백 서버가 정상작동하지 않고있음을 알려줄 수 있도록 하자

- Front, Back 이원화(Vercel, Nginx-Tomcat)

4. 서버는 대한민국에 존재해야하며, 네트워크 응답시간은 최소화시켜야된다.

개발 고려사항

1. DB정규화는 최소화(빠른 개발 필요, 향후 데이터 정규화 재실시)

2. 모든 프로세스는 데몬화, 언제나 정상작동함을 보장해야함

3. 데이터 업데이트는 걸리는 시간 고려하여 최적화

- 현재 업데이트 로직은 42API의 물리적 위치(파리) 및 엔드포인트 제한(초당 2회)로 인하여 전체 로직 30분 소요

- 업데이트 로직은 새벽 4시 CronJOB으로 실시

4. 평가 데이터양(15만 이상)을 적절하게 다룰 수 있을 것

- Query 당 걸리는 시간 최소화

CI/CD 구조

CI/CD 고려사항

1. 개발간 프론트 로컬 테스트 허용할 것

- Nginx Conf에서 map으로 CORS 헤더 추가(localhost)

2. Github Action 이용, Backend 자동 적용

- Gradle 이용하여 빠르게 개발환경 구축 및 빌드

3. Vercel - Github Integration 이용하여 push시 자동으로 프론트 적용

4. 개발 과정은 Organization project에 공유(ToDo, In Progress, End)

5. Secret 키는 Vercel Secret 및 Github Action Secret으로 관리할 것

배포 결과물 : 링크

'15분이면 충분하다' 프로젝트 회고(42 코알리숑 해커톤)

susong — Fri, 24 Mar 2023 00:28:08 +0900

들어가면서

언제나 카뎃을 위해 힘써주시는 폴베님. 늘 감사합니다

42 이너서클을 끝내기까지 남은 과제 단 2개! 이제 정말 끝이 다가오니, 42에 대한 생각이 많아졌다. 이 곳에서 배운 것들이 너무 많아 앞으로 할 프로젝트에 있어서 자신감도 많이 붙었고, 앞으로 무엇을 해야할지에 대해서도 확신이 생겼다. 이제 내게 남은 것은 배운 것들을 갈고 닦는 시간이라고 생각할 무렵, 42내에 코알리숑 해커톤 공지가 올라왔다. 실력을 갈고닦을 순간이 필요했던 내게 이 해커톤은 좋은 기회가 될 것 같았고 우승을 목표로 이번 해커톤에 참여하게 되었다.

조별 만남

일주일 간 동고동락한 팀원들

'인사가 만사'라는 말이 있듯, 나는 해커톤에서 어떤 팀원을 만나냐가 결과물을 결정한다고 생각한다. 이번 해커톤은 내 의사가 반영되지 않는 완전한 랜덤으로 조별 매칭이 이루어졌고, gehan님과 sungwook님 이렇게 3명이서 팀을 이루게 되었다. 우리의 첫 인상은 매우 담백했던 것 같다. 다른 팀원들은 누가 조장을 할 것인지, 어떤 주제로 해커톤을 할 것인지 혹은 어떤 역할을 맡을 것인지에 대해서 하루종일 이야기하는 반면에, 우리팀의 경우에는 이 모든 것을 결정하는데 1시간밖에 걸리지 않았다.

처음만난 사람과 해커톤을 하면서 그렇게 빠르게 의사결정이 가능한가? 싶을 수 있지만, 이렇게 빠른결정이 가능했던 것을 보니 우리의 팀워크가 잘 맞을 것이 예고되었던 것 같다. 우리는 내가 조장을 맡고, 서로 2개씩 생각했던 아이디어를 이야기 한 후 이 중 가장 괜찮았던 '평가 데이터 기반 솔루션'을 제작하기로 했다. 또, 역할에 있어서는 1주일이라는 시간을 고려 각자 잘하는 것을 하기로 했는데(1주일은 새로운 것을 배워서 적용하기에는 너무 촉박하다고 생각했다), 나 같은 경우에는 평가 데이터를 가져와서 DB에 넣는 역할 그리고 CI/CD 구축, 인프라 구축(DNS, CORS등 과같은 문제 해결)을 하기로 했다.

가장 최근에 42.gg를 하면서 프론트 경험이 있으셨던 sungwook님은 프론트 작업을, 최근에 42mogle 프로젝트를 하면서 CICD 및 배포에 관심이 많았던 나는 인프라 및 데이터를 가져오는 일을, 그리고 gehan님은 최근에 JAVA spring을 살려 백엔드 API를 설계 및 구현해주셨다. 모두 관심사와 하고싶은 것들이 다르기에 빠르게 팀을 구성하고 팀웍을 살릴 수 있었던 것 같다.

우여곡절의 개발과정과 교통사고

우리는 Github를 통해 개발을 공유했고, 진행과정은 Project와 레포별 Issue를 이용했다.

해커톤이 시작되고 다음날 주제와 관련하여 각자 생각을 발전시킨 후, 우리는 모여서 우리가 어떻게 일할 것인지부터 결정했다. 우리에게 가장 친숙한 Github가 당연하게도 우리의 코드 보관소 역할을 하기로 결정되었고, 또한 우리는 Github를 통해서 일정을 결정하기로 합의했다. 자신이 하고 있는 모든 일들은 Projects를 통해서 관리되었고, 각각은 레포의 Issue를 통해서 설명되었다. 그렇게 서로가 지금 어떤 일을 하고 있는지 즉각적으로 알 수 있게 함으로써, 서로의 템포를 맞추며 개발을 해 나갔다.

가장 먼저 두각을 들어냈던 것은 Sungwook님의 프론트 분야였다. 피그마를 몇 번 다뤄보신적이 없다고 하셨는데 능숙하게 피그마를 통해서 자신이 생각하는 UI에 대해서 이야기해주셨다. 그렇게 우리는 공용 전자칠판에 UI를 띄우고 앞으로 어떤 데이터가 필요할지 그리고 어떤 API가 필요할지에 대한 이야기를 나누었다. 그렇게 프론트 분야에서 먼저 사용자에게 제공될 데이터를 사용자경험에 비추어서 제시해주니 그 다음은 정말 쉽게 풀리는 부분이 있었다.

데이터가 필요한 이유는 결국 사용자가 그것을 쓰기 위함인데, 다른 프로젝트들을 진행할 때에는 프론트와 DB가 따로 작업을 했던 것 같아서 이번 경험을 통해 많이 배울 수 있었다. 데이터가 왜 필요할까? 에 대해서 깊이있게 고민해보고, 결국 사용자를 위해 필요한 데이터이기 때문에 그것에 맞춰 DB를 짜는 것이 중요하다는 것을 깨달은 순간이었다.

그렇게 우리는 7일간 아주 몰입한 환경에서 코딩을 진행했다. 하지만, 몰입 6일차 그날도 해커톤을 위해 개포로 가고 있던 내게 안좋은 일이 발생했다. 개포를 거의 다 와가던 수서역 인근에서 내 뒷차가 전방주시태만으로 나를 뒤에서 쳐버린 것이다. 시속 2~30의 그렇게 빠른 속도는 아니었지만, 누적된 피로의 상황에서 뒤에서 받아버리니 내 몸은 내부에서 망가져버렸다. 하지만, 일단은 토요일이고 해커톤이 다음날이기 때문에 배포를 위해서라도 나는 타이레놀과 함께 남은 해커톤을 진행했다.

배포! 그 황홀한 순간

배포 글 쓰는 순간이 가장 즐겁다.

일요일에 배포를 목표로 둔 우리는 임무를 완수해냈다. 일요일 오후 5시 11분 우리는 42서울을 대상으로 우리 서비스가 정식으로 배포되었음을 안내하였고, 해커톤 프로젝트 중 일주일만에 배포를 해낸 팀은 우리밖에 없었기 때문에 엄청나게 큰 관심을 받았다. 스크린 샷에도 나와있듯, 수많은 반응과 댓글을 통해 많은 사람들이 우리 서비스에 대한 흥미를 표현했다.

실제로, 내가 봐도 우리 서비스는 일주일만에 한 프로젝트라고는 보기힘들만큼 훌륭했다. 각자 맡은 역할에 책임감있게 임해서 그런 것일까, 너무나도 멋진 결과물이 나왔고 우리는 우리가 우리 코알리숑 대표로서 선정될 것이라고 믿어 의심치 않았다. 지금도 우리 서비스는 접근해서 이용해볼 수 있는데, 프로젝트 링크 들어가면 우리가 한 결과물을 확인할 수 있다. 처음 페이지에 나오는 접속 코드에는 '평가풍년'을 작성하면 된다.

우리가 이 서비스를 기획한 이유는 평가에 대한 데이터적인 접근이 부재함 때문이었다. 42서울은 동료평가를 통해 학습을 진행된다. 또 그 평가의 모든 기록들은 하나하나 자세하게 데이터베이스에 쌓여있다. 하지만, 이런 데이터를 가공해서 어떤 가치나 흥미를 만들어 낸 사람이 지금까지 없었기 때문에 우리는 이것을 직접해내보기로 마음먹었다.

배포후에 42일원들은 자신들의 평가성향을 데이터를 통해 보았고, 이에 열광했다. 건물에 있는 많은 화면들에서 우리의 사이트가 보였고 지나가는 복도와 엘리베이터에서도 우리가 만든 서비스에 대한 이야기가 주를 이루었다. 늘 막연하게 주먹구구식으로 평가 스타일을 들어왔던 사람들이 데이터로 나타나는 자신의 모습을 보며 흥분하는 모습은 우리의 선택이 옳았음을 증명해주었다.

배포 후

배포 당일 발생한 트래픽(각각 데스크탑과 모바일)

배포를 한 후 우리는 많은 연락과 관심을 받았다. 우리의 서비스를 경험한 많은 사람들이 우리 서비스를 이용한 실제 경험을 바탕으로 우리에게 피드백을 주었다. 우리의 서비스는 하루에만 약 2500명의(중복 포함) 트래픽을 발생시켰고, 실제로 우리 서비스를 사용하며 즐거워하는 모습을 보며 우리는 즐거운 마음으로 더욱 서비스를 발전시켜나갔다.(42서울 일원은 약 1400명이다 즉, 모든 인원이 약 2번정도 우리 서비스에 접속했다)

하지만 아쉽게도 1차 심사에서 우리는 우리 코알리숑 대표로서 본선에 진출하지 못하게 되었다. 여러가지 이유가 있겠지만, 일단 우리 경쟁상대가 매우 잘한 것도 있고, 또 이번 해커톤은 세일즈가 매우 중요한 요소였는데 내가 교통사고 후유증으로 인하여 입원을 하게되면서 그런 부분에 있어서 인력이 부족했던 것도 있었다. 정말 열심히 했기에 기대가 컸고 그렇기에 아쉬움은 더욱 컸지만, 우리는 다음을 기약하기로 하고 승리팀을 축하해주는 시간을 가졌다.

해커톤이 끝났지만, 우리 서비스에 대한 관심은 여전했다.

해커톤이 끝나도 우리 서비스에 대한 니즈는 여전했고, 많은 사람들이 서비스를 유지해달라는 요청을 했다. 우리는 해커톤을 끝으로 잠시 정비를 위해 서버를 끈다고 이야기했었지만, 잠시만 종료하였을 뿐 21일부터는 공지하지 않고 서비스를 재개하고 있었다. 잠시 서버를 정지했던 이유는 GoogleGA를 적용하기 위함이었는데, 그전까지는 Vercel을 통해 얻을 수 있는 분석에 의존했는데 이것이 부족하다고 느꼈기 때문이다. 무료인 이상 하루가 넘어가는 기록은 모두 소실되었고, 또 퍼포먼스 체크는 가능했지만 사용자들의 실제 이벤트들은 추적이 제한되었기 때문에 우리는 분석도구가 꼭 있어야겠다고 판단했다.

그렇게 우리는 우여곡절 끝에 GoogleGA를 포함해서 다시 배포하였고, 이를통해 우리 서비스를 사용하는 사람들이 어떻게 우리 서비스를 이용하는지 알 수 있게 되었다. 내가 만든 서비스를 사용해주는 사람들을 통계로 마주하는 것은 또 색다른 경험이었다. 실제로 내가 만든 서비스에게 저렇게 많은 사람들이 흥미를 느낌을 알게되었다. 나의 서비스가 잘됨에 기뻐하는 내 모습을 보며 나는 또 내가 걷기 시작한 이 길이 옳았음을 확신하게 되었다.

해커톤은 끝났지만, 우리 팀은 다시한번 더 높은 서비스 퀄리티를 위하여 도전을 할 예정이다. 이번 해커톤은 실 사용자들에게 우리 서비스를 검증하는 과정이었다고 생각한다. 아쉽게도 수상에 있어서는 고배를 마셨지만, 수많은 사용자들과의 상호작용을 통해 우리 서비스의 부족함과 장점들을 알 수 있었다. 우리는 이를 통해 여러 버그들을 없애고 사용자가 원하는 기능을 넣어 42에서 가장 대중적인 서비스로 발돋음 시킬 예정이다. 또, 단순히 우리나라에서만 사용하는 기능이 아니라 전세계 42커뮤니티에서 다 사용할 수 있는 그런 국제적인 서비스로 발전시켜보려 한다.

지금까지 해낸 것만큼 앞으로 해낼 일에 더욱 설레는 나날이다.

간단하게 API 스트레스 테스트 하는 법

susong — Sun, 19 Mar 2023 19:32:34 +0900

사용하고 있는 아파치 서버 배포 직전, 과연 이 서버가 얼마나 버텨줄지 궁금해졌다.

현재 배포중인 서비스는 얼만큼의 스트레스를 버텨줄 것인가?

1. apaceh2-utils를 설치한다.

sudo apt install apache2-utils

2. 원하는 스트레스 테스트 양을 설정후 던진다

ab -n 1000 -c 100 http://evaluation.42seoul.link/
// 100개의 클라이언트에서 1000개의 요청을 던져라! 라는 뜻

3. 결과를 확인한다.(프론트 요청)

Vercel로 작동하는 프론트 배포는 매우 성공적이다.

[알 수 있는 정보]

1. 99% 요청이 451ms안에 처리되었으니 엣지케이스에서도 성능이 준수하게 나옴을 알 수 있다(가장 긴 요청시간은 749ms으로 특수케이스임을 감안했을 때 인내할 수 있다고 판단된다)

2. 평균 요청 처리 시간은 260.476ms이다.

3. 초당 평균 383개의 요청을 처리할 수 있다.

4. 요청 간 실패는 없었다.

내가 아키텍처를 구성하는 것이 아니기에 크게 걱정되는 부분은 없었다. Vercel의 성능은 돈을 주면 더 올라가기에, 이 부분은 돈으로 해결할 수 있는 문제이니 크게 고려할 사항이 아니라고 판단하였다.

4. 특정 API에 요청 던져보기

ab -n 1000 -c 100 https://evaluation.42seoul.link/API_LINKS
// 특정 API에 100개의 클라이언트에서 1000개의 요청을 던져라! 라는 뜻

결과 : 비공개

이렇게 간단하게 스트레스 테스트를 하는 방법에 대해서 알아보았다 :)

비용을 아끼자(모닝글로리 웹페이지 제작 5)

susong — Fri, 17 Mar 2023 22:22:33 +0900

돈이 너무 많이 나간다!!

배포 2개월차 12월의 비용 총 54.91달러가 지출되었다.

42모글의 서비스 볼륨은 결코 크지 않다. 분명히 작은 간단한 출석용 사이트인데.. 비용이 너무 많이 나간다. 첫 달은 도메인 등록 비용을 고려해서 많이 나갔다고 해도 2번째 달부터는 변명의 여지가 없었다. 내 첫 배포 프로젝트라서 일단 어떻게든 서비스를 올리겠다는 일념으로 올리긴 했지만, $55는 용납할 수 있는 범위를 넘었다. 일단 서비스가 안정되었으니 어떻게든 가격을 줄이는 방법을 찾아야만했다.

42서울에서는 클라우드 공부를 독려하기 위해서 AWS크레딧을 내부 재화로 구매하게 해준다. 덕분에 나는 지금 200만원 이상의 크레딧을 보유하고 있지만, 이 속도라면 2년 후면 서비스를 내려야했다. 내가 엄청나게 크고 많은 컴퓨팅 용량을 이용하는 서비스를 하면서 2년을 유지한다면 대단한 일이지만, 이런 간단한 서비스를 2년도 유지못한다는 것은 스스로조차도 납득할 수 없었다.

그래서 나는 이 비용을 줄이기로 마음먹었다.

비용을 줄이기 위한 노력들

가장 먼저 실시한 것은 쓸데없는 서비스들을 없애는 것이었다. 처음에는 아무것도 모르고 VPC 등등 이것 저것 다 건드려봤었는데, 그 때 만들어둔 서비스 하나하나가 다 비용으로 돌아왔다. 그래서 일단 16.89의 비용을 지불하고 있는 EC2-기타를 제거하기로 마음먹었다.

첫번째 목표 퍼블릭 IP들

Cloud 내부에서 작동하는 EC2들에게 기본적으로 제공되는 IP들은 고정적이지 않다. 즉, EC2를 껏다가 키면 바뀌는 동적인 IP주소들이다. 그러면, DNS에 등록해야되는 서비스들은 어떻게 도메인을 등록할 수 있을까? 그건 바로 Elastic IP를 이용하면 된다. Elastic IP는 EC2 1개당 (EC2에 묶여있고, 해당 인스턴스가 켜져있을 경우) 무료다. 즉, 만들어놓고 인스턴스를 끄거나 바인딩해두지 않으면 비용이 나간다.

나는 처음에 이 Elastic IP에 대한 개념이 없어서, 사용하지도 않는 IP들을 받아두고 낭비하고 있었다. 그래서 가장먼저 바로 제거할 수 있는 이 친구들부터 없앴다. ~~(공짜인줄알고 막 만들었던 것 같다..)~~

내가 지금 사용하고 있는 인스턴스 유형들(4개의 서비스를 운영중이다)

두번째로는, 인스턴스를 낮췄다. 처음에 t2.micro를 이용하다가 몇 가지 문제들이 발생해서 인스턴스를 높은 수준으로 높였는데, 이는 전혀 필요없는 돈낭비였다. 물론 수업비라고 치면 저렴했지만, 이것 또한 불필요한 낭비였기에 바로 t2.micro로 변경하였다.

내게 발생했던 문제는 리액트 프로젝트 인스턴스 멈춤 현상이었는데, 이는 렘이 부족해서 발생하는 문제였다. 처음 이 문제를 인지했을 때 프로젝트 빌드 중에 렘이 부족하다는 것을 알았고 즉시 인스턴스를 키움으로써 문제를 해결했다. 하지만, 생각해보니 해당 메모리는 늘 사용해야되는 메모리가 아니었고, 프로젝트 빌드같은 특수한 상황에서만 부족한 것이었다. 그런데도 불구하고 전체적인 렘을 늘리는 것은 1차원적인 상황판단이었다.

일반적으로 2기가로 설정해두고 있다.

해당 문제는 가상메모리로 해결할 수 있는 문제라고 판단하였고 가상메모리를 설정 후에 다시 인스턴스를 내렸다. t2.small이 t2.micro에 비해서 가격이 2배정도가 되니, 간단한 판단으로 비용의 50%를 아낄 수 있었다.

오후 6시 ~ 오전 6시에는 해당 화면이 나온다.

세번째로는, 서버 이용시간을 줄였다. 내가 작동시키는 서비스 42Mogle은 아침 출석사이트이다. 즉 대부분의 트래픽은 아침에 발생한다. 그렇다면 이 서비스를 심야시간과 새벽시간에 작동시킬 필요가 있을까? 나는 없다고 판단했고, 해당 판단을 우리 개발팀 및 운영팀과의 공유 후에 저녁 6시 ~ 오전 6시 시간에는 작동을 멈추기로 했다.

저녁 6시까지 작동시킨 이유는 우리 출결 사이트 데이터 통계를 볼 수 있는 사이트가 작동하고 있었기 때문이다. 보컬(42운영진) 입장에서는 이 데이터를 출근한 시간에 확인할 수 있어야했기 때문에 해당시간에는 접속할 수 있도록 조치했다. 그렇게 또 40%정도의 돈을 아꼈다(서버가 꺼지면서 Elastic IP가격이 조금 나가긴 했지만.. 받아들였다 나중에는 해결하겠노라 마음먹으며)

마지막으로는, ELB(Elastic Load Balancer)를 제거했다. 처음 ELB를 사용한 이유는 아마존에서 제공하는 TLS를 이용하기 위해서 사용했다. 로드밸런서에 대한 이해가 결여된 상태에서 마치 이것이 TLS를 적용해주는 장치라고만 생각하고 적용시켰었다. 이렇게 사용해봄으로써 실력은 AWS에 대한 이해는 넓어졌지만, 이는 너무나도 큰 낭비였다. 심지어 약 17달러! 거의 30%에 해당하는 예산을 낭비하는 셈이었다.

그렇게 ELB를 제거하기로 마음먹고 로드밸런서에 대하여 깊이있게 공부하기 시작했다. 그 결론으로, Nginx를 ELB대용으로 사용하기로 마음먹었고 지금은 Nginx를 통해서 TLS/SSL 문제가 해결되었다. Nginx는 EC2 내부에서 Proxy 서버로써 작동하고 있다.

비용을 절약하고 보니

덮어놓고 쓰다보면 거지꼴을 못 면한다는 말처럼, 클라우드는 정말 엄청나게 편리한 도구이지만 막 쓰다보면 돈이 줄줄 샌다는 것을 알 수 있었다. 또한, 이렇게 부담없이 클라우드를 사용할 수 있는 환경에서 공부하는 것이 참으로 행운이라는 생각도 많이했다. 많이 낭비해봤기 때문에 다음에는 어떻게 해야 낭비하지않을 수 있을지에 대해 부딪치면서 배울 수 있었고, 덕분에 AWS 자체에 대한 이해도 넓어졌다. 이번 낭비를 통해 AWS에 있는 기능들을 하나하나 다 알기에는 너무 넓지만, 이렇게 하나씩 정복해가다보면 불가능하지 않겠다는 자신감도 얻었다.

결론적으로, 원래 $55에 달했던 비용은 현재 $9선에서 유지되고 있다. 42모글 서비스를 마무리한 후에 3개의 프로젝트를 더 하게 되면서 지금은 4개의 서비스를 운영하고 있지만, 현재도 내 예산은 40 안팎으로 유지되고있다.

결론 : 클라우드를 쓸 때는 늘 예산에 집중하자. 그리고 참 좋은 경험이었다.

Request를 최소로 해야되는 이유

susong — Wed, 15 Mar 2023 14:12:38 +0900

최근에 42서울에 있는 모든 사람들의 유저 데이터를 가져와야되는 이유가 생겼다. 그래서 42API로 전체를 가져오는 로직을 제작하고 있었는데, 이 과정에서 너무 많은 시간이 걸리는 것을 인지하고 최적화에 나섰다.

처음 시도한 방법은 기본적인 API요청을 기반으로 요청을 작성하였는데, 기본적인 페이지 사이즈는 30이었다. 즉, 한번 GET요청을 던지면 서버에서는 30명의 정보를 내게 리턴해주는 방식으로 작동하였다. 사실 30명이라는 사이즈가 그렇게 크지는 않았지만 전체인원(42를 그만두거나 블랙홀에 빠진 인원)을 포함하여 모두를 가져오다보니, 총 요청이 270번 정도 작동하는 문제가 있었다.

컴퓨터에서 비용은 레지스터 << 캐시 <<< 메인 메모리 <<<< 저장공간 <<<<<<<<<<< 네트워크 순으로 큰데, 이 네트워크 비용을 약 270번이나 지불해야된다는 것은 큰 제약이었다. 다행히도, 찾아보니 42API에서는 쿼리를 기반으로 더 많은 데이터를 한번에 요청할 수 있었고, 이를 기반으로 100명의 인원을 가져오도록 로직을 변경하였다.

30명씩 요청하는 경우 약 8분 39.43초가 걸린다.

100명씩 요청하는 경우 약 4분 54초가 걸린다.

데이터 전처리, 데이터베이스와의 연결 등등 다른 요소들도 많지만, 이 로직 하나 변경이 전체 프로그램 성능 향상에 크게 기여하는 것을 확인할 수 있었다. 즉, 큰 놈을 가장 작게 줄여야 가장 효과가 좋다는 것을 확인할 수 있다.

한국에서 보낸 API 서버로 보낸 핑

내 파리 서버에서 API서버로 보낸 핑

사실, 더 최적화를 하고 싶으면 네트워크 패킷 자체의 총 이동 거리를 줄이는 방법이 효율적이다. 파이에 있는 서버에서 API요청을 실시하고 이를 모아서 한번에 내 서울에 있는 데이터베이스에 넣어주는 방법을 이용하면 가장 효율적으로 데이터 모으는 로직을 실행시킬 수 있다. 한국에서 해당 서버에 접속하는데 드는 비용보다 파리에서 해당 서버에 접속하는 비용이 약 200배정도 빠르기 때문이다.

하지만, 이 방법은 내 파리 서버에 남은 메모리 용량이 크지 않아서 보류하기로 했다. 현재 파리 서버에서는 배포된 서비스가 돌아가고 있는데, 이 서비스가 아직 컨테이너에 들어가있지 않아 내가 이 데이터를 모으는 과정에 패키지가 꼬인다거나 하는 문제가 생기면 큰일나기 때문이다.

이렇게, 오늘도 최적화를 진행 할 때에는 최대한 큰 녀석부터 최적화를 진행해서 전체 프로세스를 효율화해야된다는 것을 확인했다.

전체 데이터를 가져오는 로직(RUBY)

RFC7230 요약(HTTP 아키텍처)

susong — Sun, 12 Mar 2023 16:48:14 +0900

본 내용은 RFC7230을 기반으로 작성되었습니다.
영문판을 기반으로 해석을 통해 작성하였으며, 틀린 내용 댓글로 알려주시면, 수정할 수 있도록 하겠습니다.

HTTP란?

HTTP는 HyperText Transfer Protocol의 약자로, 네트워크를 기반으로 작동하는 무상태 어플리케이션 레벨 요청/응답 프로토콜을 말한다. 이 응답 프로토콜이 사용하는 것으로는 네트워크 기반 하이퍼 텍스트 정보시스템과 유연한 상호작용을 위한 확장 가능한 메시지 페이로드를 포괄하고 있다.

처음 들으면, 무엇인지 이해하기 힘든데, 중요한 키워드 2가지 무상태와 어플리케이션 레벨만 정리하고 넘어가자

첫번째로, 무상태란 무엇일까?

무상태를 설명하기 위해서는, 그 전에 Connectionless(비연결성)에 대해서 설명해야된다. 비연결성이란, 서버와 클라이언트가 한번 연결을 맺고, 클라이언트가 요구한 자료를 서버가 다 보내고 나면 연결을 끊어버리는 성격을 의미한다. 연결성을 유지하면, 서버는 지금 요청한 클라이언트가 누군지 지속적으로 기억할 수 있고 이를 통해 작업의 맥락을 이어나갈 수 있다.(내가 지금 로그인하면 서버는 지금 통신하고 있는 클라이언트가 내가 로그인한 것을 기억하고 데이터를 유지한다) 하지만, 이렇게 하지 않는 것은 연결성을 유지하는 것이 너무나도 큰 비용이 들기 때문이다. 서버에 접속하는 모든 클라이언트에 대해서 연결성을 유지하면, 그 수만큼 오버헤드가 커지기 때문이다.

커넥션을 유지한다는 것은, 해당 클라이언트에 대해서 서버가 지속적으로 데이터를 가지고 통신을 연결해야하는 부담이 생기는데, 이것은 서버가 다수의 연결을 받아들이는 것이 큰 부담을 준다. 이런 문제를 해결하기 위해, HTTP는 비연결성을 지향하고 이 때문에 우리는 HTTP 연결을 할 때마다 연결을 복구하는 비용을 들여야한다. HTTP가 연결을 끊고 다시 연결되기 위해서는, HTTP을 지탱하고 있는 프로토콜인 IP, TCP 프로토콜을 매번 작동시켜야되는 것이다. 그리고 이런 비연결성의 특징은 무상태 프로토콜과 연관된다.

무상태란? Connectionless로 인해 서버가 클라이언트를 식별할 수 없는 것을 무상태라고 한다. 예를들어, 내가 서버에 로그인을 하더라도, 내가 다시 GET 요청으로 index.html을 가져오면 서버는 아까 로그인 한 '나'와 지금 index.html을 요청한 '나'를 별개의 존재로 인식한다. 요청할 때마다 새롭게 통신을 구축하기 때문에 이렇게 무상태성이 생기게 된다.(물론, KeepAlive와 쿠키를 통해서 위에 있었던 모든 예시와 다르게 작동시킬 수 있지만, 기본적인 것은 이렇게 작동한다)

두번째로, 어플리케이션 레벨이란 무엇일까?

이 중 HTTP는 Application에 해당된다.

CS를 공부하다가 보면, OSI 7계층이라는 것을 자주 보게 된다. 네트워크가 작동하는 계층을 7가지로 나눈 것인데, 이를 말로 간단하게 표현하면 이렇게 표현할 수 있겠다. 내가 사용하는 프로그램은 문으로 포트라는 것을 가지고 있고, 컴퓨터는 자신의 이름으로 IP를 가지고 있으며, 이 데이터는 물리 계층에서 LAN카드를 통해서 이루어진다. 모든 HTTP통신은 자신의 포트를 이용하여, TCP 통신을 통해 안전성을 확보하고, IP를 통해서 상대를 찾아 나서며, LAN카드를 통해서 실제 전기 신호를 밖으로 보낸다.

HTTP는 TCP, IP에 의존하고 있고, 이는 HTTP 통신을 할 때마다 IP와 TCP 프로토콜이 작동된다는 것을 의미한다. 우리가 브라우저에 있는 어떤 URI에 데이터를 요청하면(GET 요청) 이는 물리계층으로 갈 때까지 각각의 프로토콜에 의해서 Warp된다. 그리고 이를 작동시킬 때 꼭 필요한 것들이 포트라고 생각하면 된다.

HTTP 아키텍처

본 문 내용은 대부분 RFC7230에 의존하고 있습니다. 내용중 중요하다고 생각하는 해석을 작성하되, 설명이 필요한 내용만 추가적으로 설명할 예정입니다.

1. HTTP는 신뢰성 있는 전송 계층(TCP) 또는 세션 계층의 메시지 교환에 의해 작동되는 상태없는 요청/응답 프로토콜이다.

2. HTTP 클라이언트(브라우저 등)는 하나 이상의 HTTP 요청들을 전송하기 위한 목적으로 커넥션을 서버에 설립하는 프로그램이다. 반대로, HTTP 서버(Nginx 등)은 HTTP 응답을 전송함으로써 HTTP 요청을 처리하기 위해 커넥션을 허용하는 프로그램이다.

3. Origin Server(오리진 서버)라는 용어는 제시된 특정 대상 리소스에 대답할 수 있는 권한 있는 응답을 할 수 있는 서버를 의미한다. (그렇기 때문에 Proxy 서버는 오리진 서버가 아니다)

4. Sender(발신자)와 Recipient(수신자)는 각각 주어진 메시지를 발송하고 전달받기위해 구현된 것들을 의미한다.

5. HTTP는 로소스와 리소스들간의 관계에 있어서는 RFC3986에 의존한다.

6. 클라이언트는 HTTP요청을 할 때, 서버에 메시지 형식, Method, URI 그리고 프로토콜 버전을 토함하고 있는 REQUEST-LINE을 시작으로, request modifier, 클라이언트 정보, 표현 메타데이터 등을 통함하는 헤더필드로 이어지며, 헤더필드의 끝은 빈 줄로 나타낸다. 그 이후에는 Body를 포함한다.

해당 문장은 HTTP Request 문장이 어떻게 구성되어야하는지를 이야기하며, 모든 HTTP 요청은 위와 같은 형식을 갖추어 작성되어야한다. 반대로 서버에서 클라이언트에 응답을 할 때에도 비슷한 규칙이 있다.

7. 서버는 클라이언트에게 HTTP응답 메시지를 작성할 때, 각각의 프로토콜 버전, 성공 혹은 에러 코드, 원문 그 자체의 상태코드를 포함한 status-line(예: 200 OK) 그리고 가능하다면 서버정보, 리소스의 메타데이터와 표현 메타 데이터를 포괄하는 헤더 필드 그리고 헤더 필드 다음에는 끝을 의미하는 빈 줄을 포함해야한다. 또, 마지막으로는, 페이로드 바디를 포함한 메시지 본문으로 작성되어야한다.

서버와 클라이언트가 HTTP 통신을 할 때에는 위와 같은 방식으로 요청과 응답을 작성해야된다. 이런 정의된 형식을 바탕으로 Connection은 다수의 요청/응답 교환을 위해 사용될 수 있다.

HTTP 요청 예시
GET /objectserver/restapi/alerts/status HTTP/1.1
Accept: application/json
Authorization: Basic dGVzdHVzZXIwMTpuZXRjb29s
Host: localhost
Connection: keep-alive
HTTP 응답 예시
HTTP/1.1 200 OK
Cache-Control: no-cache
Server: libnhttpd
Date: Wed Jul 4 15:32:03 2010
Connection: Keep-Alive:
Content-Type: application/rdf+xml
Content-Length: 24860
// 이하 생략(BODY)

8. HTTP를 설계 할 때, 모든 사용자 에이전트들이 범용 브라우저들이고 모든 원 서버(Origin Server)들이 큰 규모의 공용 웹사이트라고 생각하기 쉽다. 하지만, 보통의 HTTP 사용자 에이전트(Client)들은 체중계, 음향기기들 같이 다양한 모양과 크기의 통신 기기들을 포함한다. 마찬가지로 대부분의 HTTP 원 서버들은 홈 자동화 장치, 사무용 기계, 뉴스 피드 등등을 포괄한다.

9. HTTP는 중개자을 이용하여 커넥션을 충족시킬 수 있다. 즉, 프록시(Proxy), 게이트웨이, 터널 등을 이용하여 통신을 연결할 수 있다.

10. 통신의 방향은 UPSTREAM과 DOWNSTREAM으로 구성되어있으며, 모든 메시지들은 UPSTREAM에서 DOWNSTREAM으로 흐른다. INBOUND와 OUTBOUND는 요청 라우트의 관계에서 방향을 설명하기 위해 사용한다. INBOUND는 원서버로 향하는 메시지를 의미하며, OUTBOUND는 사용자 에이전트로 향하는 것을 의미한다.

11. 프록시(PROXY)란? 클라이언트에의해 선택되고, 일반적으로는 로컬 구성 규칙들을 통해 일부 절대 URI의 유형을 처리하기 위해 만들어진 메시지 전송 에이전트다. 프록시는 HTTP와 HTTP 간의 중개자 역할을 하며, 다른 어플리케이션 레벨 프로토콜 간에 변화도 가능하다. 프록시는 주로, 보안적 이익 혹은 공유 캐시 등등을 위한 공통 중개자로써 집단의 HTTP요청들을 그룹화 하는 것에 자주 사용된다.

12. 게이트웨이(GATEWAY)란? 아웃바운드 커넥션을 위한 원서버의 역할을 하기도 하지만, 수신된 요청을 다른 서버로 변환하여 인바운드로 전송하는 중간 서버 역할도 한다. 게이트웨이는 오래되거나 신뢰할 수 없는 정보들을 캡슐화하는 것에 사용되며, 서버 성능 개선을 위한 캐싱 혹은 파티셔닝 등도 수행할 수 있다. 또, 여러 시스템 간의 HTTP 로드 밸런싱을 할 수 있게 해준다.

13. 터널(TUNNEL)란? 메시지 변경 없이 2개의 커넥션에 숨겨진 중개자로써 역할을 하는 존재이다. 터널이 활성화 되면, 터널은 HTTP 통신의 당사자로 고려되지 않는다. 또, 두 끝점에서 전달하는 커넥셙이 종료되면 터널은 더 이상 존재하지 않게 된다.

14. HTTP는 무상태 프로토콜로 정의되어있으며, 이는 각 요청 메시지는 개별적으로 이해해야된다는 것을 의미한다. 따라서, 서버는 (커넥션이 보안되어 있고, 해당 에이전트를 특정하지 않는 한) 동일한 커넥션에 대한 두개의 요청이 동일한 사용자 에이전트에서 온 것으로 가정해서는 안된다. 만약 이를 위반한다면, 이는 보안 및 상호작용에서 문제를 일으킬 것이다.

15. 캐시(CACHE)란? 이전 응답 메시지의 로컬 보관소이고, 메시지의 저장 검색 삭제를 관리하는 서브 시스템이다. 캐시는 캐시 가능한 응답을 저장하여 향후 동일한 요청에 대한 응답 시간과 네트워크 대역폭 사용을 줄일 수 있다. 어떤 서버도 캐시를 포함할 수는 있지만, 캐시는 서버가 터널 역할을 하는 동안에는 사용될 수 없다.

16. 캐시의 효과는 요청/응답 간에 적용할 수 있는 캐시가 있는 경우 전체적인 프로토콜 체인이 단축되는 효과를 준다. 만약, A-C간의 연결 내에 프록시가 4개 있는 경우, 첫번째 프록시에 캐시가 있다면 총 5번의 연결이 필요한 통신이 1번으로 단축되는 효과를 발생시킬 수 있다.

17. WWW와 여러 대규모 조직에 의해 배치된 캐시의 설계와 구성은 매우 다양한다. 대양(예컨데, 태평양)을 횡단하는 대역폭을 아끼기 위한 국가 계층의 프록시 등등 다양한 종류의 캐시가 존재할 수 있다.

18. HTTP 구현과 관련하여서, HTTP에 맞는 규칙들과 관련된 모든 요구사항을 충족한다면 해당 구현은 적합한 것으로 간주한다. 적합함에는 다음과 같은 예시들이 있을 수 있다. 첫째, 발신자는 발신자가 거짓이라는 의미를 전달하는 프로토콜 요소를 생성하면 안된다. 둘째, 발신자는 ABNF 규칙에 대응하는 문법과 맞지 않는 프로토콜을 생성하면 안된다. 셋째, 주어진 메시지에서, 발신자는 다른 약할의 참가자만 생성할 수 있는 프로토콜 요소나 구문 대안을 생성해서는 안된다.

19. HTTP는 구현의 문맥 배치와 목적에 따라서 적절하다고 판단되는 길이가 다양할 수 있기 때문에, 대부분의 프로토콜 요소에 있어서 특정 길이 제한을 두고 있지 않다. 따라서, 프로토콜 요소의 적절한 길이는 수/발신자 간의 공유된 예상에 의존한다.

20. 최소한, 수신자는 동일한 프로토콜의 다른 메시지에 대하여 프로토콜 요소 길이를 구문분석하고 처리할 수 있는 능력을 갖춰야한다.

21. HTTP는 <메이저 버전>.<마이너 버전> (예 : 1.1)으로 구성되어있고, 이는 프로토콜의 버전을 표시하기 위해 사용한다.(RFC7230은 HTTP 1.1을 정의한다)

22. HTTP1.1 메시지가 HTTP1.0 수신자 혹은 알 수 없는 수신자에게 전달될 경우, HTTP1.1은 유효한 HTTP1.0 버전으로 해석될 수 있도록 구성된다.

23. 새로운 헤더 필드는 프로토콜 버전을 변경하지 않고도 도입될 수 있다. 새로운 헤더 필드의 정의는 그것을 인식(알고있지) 못하는 수신자들에 의해 완전하게 무시될 수 있다.

24. HTTP 메시지를 처리하는 중개자(PROXY 등) 은 전달된 메시지로 자산의 HTTP 버전을 전송해야된다. 중개자는 메시지의 프로토콜 버전이 메시지 수신과 발신 모두에 적합한 버전인지 확인하지 않고, 메시지의 첫번째 줄을 맹목적으로 전달하는 것을 허용하지 않는다.

25. 클라이언트의 메이저 버전(HTTP 2 혹은 1)이 서버가 지원하는 가장 높은 버전보다 높지 않고, 클라이언트가 가장 높은 버전을 호환하는 것으로 확인된다면, 클라이언트는 가장 높은 버전의 방식으로 요청을 전송해야된다. 또한, 클라이언트는 적합하지 않은 버전의 요청을 보내서는 안된다.

26. 서버가 HTTP 규격을 잘못 구현한 것으로 확인되어도, 클라이언트는 하나의 정상적인 요청을 시도한 후, 서버가 잘못된 응답 상태 코드 혹은 헤더필드를 보내는 것을 확인 후에만, 클라이언트는 하위 버전으로 요청을 보낼 수 있다.

27. 반대로, 클라이언트가 HTTP 사양을 잘못 구현한 것으로 확인되거나, 의심되는 경우 서버는 요청에 대해 HTTP1.0으로 응답을 보낼 수 있다. 하지만, 이런 다운그레이드는 클라이언트의 요청 헤더에 있는 한 개 이상의 특정 값들이 에러가 있다고 확인되지 않으면 실행되어서는 안된다.

28. URI는 리소스를 식별하는 수단으로, HTTP 통신 전체에서 사용된다. URI는 타겟 지정, 리다이렉트 표시, 관계 정의에 사용된다.

29. 지정된 포트에서 TCP 커넥션을 청취하는(LISTEN) HTTP 원서버에 의해 관리되는 식별자를 해석하기 위한 목적으로, HTTP URI 문법이 정의되어 있다. ( http-URI = "http:" "//" authority path-abempty ["?" query] ["#" fragment]

30. 호스트 식별자가 IP주소로 제공되는 경우, 원 서버는 해당 IP주소의 지정된 TCP포트에서 청취하고 있는 대상이 된다. 포트 하위 구성 요소가 비어있거나 지정되지 않은 경우 TCP 포트 80이 기본값이다. (HTTPS는 443)

31. 물론, 주어진 권한 구송요소와 URI가 있다고 해서, 해당 호스트 및 포트가 항상 HTTP통신을 대기중인 것은 아니다.

32. HTTP는 전송 프로토콜과 독립적이지만, HTTP 문법은 이름 위임 프로세스가 TCP에 의존하기 때문에, TCP 기반 서비스에서만 사용된다.(1.1 기준)

33. HTTPS URI 스키마 또한, 계층적으로 관리된 네임 스페이스의 ㅇ녀계에 따라 식별자를 만들기 위한 목적으로 정의된다. HTTPS의 스키마는 HTTP의 스크마의 요구조건을 계승하며, 포트 443을 기본값으로 가진다. 사용자 에이전트(CLIENT)는 첫번째 HTTP 요청을 보내기 전에 강력한 암호화 사용을 통해 원 서버에 대한 커넥션이 안전한지 확인해야만 한다.

34. 포트가 스키마의 기본포트와 같다면(HTTP는 80, HTTPS는 443) 일반적인 형태는 포트 하위 구성요소를 생략한다. 예컨데, http://songseungwoon.com 와 http://songseungwoon.com:80은 동일하다.

나의 몽골 여행기(3, 대자연의 위대함과 함께)

susong — Mon, 6 Mar 2023 22:42:32 +0900

몽골의 자연은 상상을 뛰어넘는다

차강 소브라가(하얀 불탑) 아래에서

세상은 넓고 볼 것은 많다고 하지 않는가? 몽골은 그 볼 것이 너무나도 많은 곳이었다. 끝없이 펼쳐진 국토에 사람은 많이 살지 않다 보니, 몽골에 멋있는 대자연은 다른 나라의 자연과 궤를 달리하는 경우가 많았다. 이곳에서 관광지라고 이름이라도 내밀기 위해서는 다른 나라 1 티어 자연관광지는 데리고 와야 했다. 내가 2년 이상 본적을 옮겼던 단양의 자연도 이곳에서는 그저 지나가면 있는 관광지정도였다. 그 정도로 이 몽골이라는 곳의 대자연은 넓고 광활했다

0123

차강 소브라가 위에서 찍은 사진들

아름답고 또 아름다운 모습들의 향연이 바로 이곳이다.

인간이 만들어낸 그 어떤 건축물도 대자연이 수 천년 간 빚어낸 작품에 비할 수 없다는 말을 본 적이 있었는데, 그때는 다 헛소리라고 생각했다. 인간에게 가장 감명을 줄 수 있는 것은 인간이 만들어낸 것이라고 그때는 순수하게 생각했기 때문이다. 또, 한 때는 왜 도대체 인간이 자연을 갈구하며 살아가는지 이해하지 못했던 적도 있다. '왜 내가 공부한 도가 철학자들은 자연을 그렇게나 사랑할까? 자연이 그렇게 편안한 것도 아닌데..'라고 생각할 때도 있었다.

이제 와서 생각해보니 그 사람들은 대자연이 주는 감동을 너무 잘 이해한 사람들이 아니었을까 싶은 생각도 든다. 나는 서울에서 태어나 서울에서 자랐기 때문에 인간이 만든 사회와 건물이 내게 가장 큰 익숙함이지만, 그분들이 지금까지 이어오는 철학을 만들었을 때는 그렇지 않았을 테니 말이다. 그래도 이번 체험을 통해서 어느 정도 그 사람들의 마음을 이해할 수 있는 갈피를 잡았다. '대자연은 정말 아름답고 황홀하기에 그렇게 흠모하는구나'라고 말이다.

012

광활한 초원 앞에서

모든 곳이 자연공원인 이곳

Rock N Roll, 여행은 즐거움의 연속이다

저 드넓은 자연에, 저 넓은 공간에 사람이 우리밖에 없다는 것이 이해가 가는가? 몽골에서는 자연스러운 일이었다. 이 넓은 자연에 사람이 없으니 즐거움은 극에 달할 수밖에 없었다. 온전히 자연을 즐기는 것에만 신경 쓸 수 있었고, 다른 사람 눈치 보면서 사진을 찍을 일도 없었다. 그저 가다가 찍고 싶은 곳이 있으면 멈춰 서서 찍으면 되는 그런 곳이 바로 이곳 몽골이다.

온전히 자연을 즐겨보고 싶다면 한 번쯤 오면 좋을 곳이다. 여행을 하며, 자연을 사랑하는 아버지 한번 모시고 와야겠다고 생각했다. 도가 철학에 푹 빠진 아빠가 이 광경을 봤다면 얼마나 행복해하셨을까? 더 늦기 전에 한번 모시고 와야겠다.

012

차타고 지나가던 곳에서 한 컷

동물도 정말 많은 이곳

여기서는 양떼 목장을 갈 필요가 없다. 모든 길에 양들이 있기에..

동물과의 교감도 자주 나누었던 것 같다. 서울에서 양이나 말들을 보고 싶으면 특정 목장에 시간을 내서 보러 가야 하는 경우가 많은데, 이곳에서는 어디에서나 볼 수 있기에 동물을 마주할 상황도 아주 많았다. 유목 민족의 후예답게 수도를 제외한 지역에 사는 대부분의 사람들은 목축업에 종사하고 있었고, 이 양과 말 그리고 낙타들을 기르면서 생계를 이어나가고 있었다. 한 가족당 기르는 가축의 양이 적게는 수 백 마리에서 수 천마리까지 기르는 모습을 자주 목격할 수 있었다.

우리나라에서 가축 수백 마리면 엄청난 부자겠지만, 아쉽게도 여기에서는 크게 그렇지 않은 것 같았다. 양 한 마리의 가격은 내가 생각했던 것보다 훨씬 저렴했고, 이들의 노동은 크게 인정받지 못했다. 수 백의 가축을 매일매일 관리한다는 것이 얼마나 큰 노동일까 생각하면서도 왜 이들의 노동가치가 인정받지 못할까를 고민해 봤는데, 결국 나라의 부가가치와 연결 지었던 것 같다. 우리나라에 중공업을 살리고 반도체를 살려 내가 사는 대한민국의 부가가치를 높여준 우리 선배 산학역군분들께 감사한다. 그들이 아니었다면, 내가 하는 노동도 크게 인정받지 못했을 것이다.

01234

동물에 두려움이 없다면, 이곳에서는 원 없이 만지고 교감해 볼 수 있는 곳이었다.

모두 귀엽고 즐거웠지만 솔직히 나도 낙타는 무서웠다.. 특히 쌍봉은 더더욱.. 심지어 탔을 때 너무 높아서 깜짝 놀랐던 기억이 강렬하다. 사진을 보면 알겠지만 발이 엄청나게 높게 뜨는 것을 볼 수 있다.(내 키는 186이다..)

나의 몽골 여행기(2, 칭기즈 칸의 흔적을 찾아서)

susong — Mon, 6 Mar 2023 22:01:48 +0900

몽골의 길에는 낭만이 있다.

몽골의 동반자 푸르공과 함께

낭만과 고생은 함께온다고 생각한다. 나는 20대에 몽골에 온 것을 정말 잘한 선택이라고 생각했다. 몇 년만 지나서 왔다면 허리가 아파서 저 차에 그렇게 오랜시간 앉아있지 못했을 것이다. 푸르공은 정말 재미있는 차다. 정말 작아보여서 내가 저기에 들어갈 수 있을까 싶다가도, 안에 앉아있으면 꽤 아늑해서 타고다니기 좋다. 또, 와 저런 곳을 차가 갈 수 있을까? 싶은 곳을 아무렇지도 않게 달려나간다. 이 황량한 땅에서 일어나 세계를 호령한 몽골 제국의 기병이 연상되는 차이다. 작지만, 강하다.

몽골 여행을 계획하고 있다면, 저 차 안에 최소 가는날 * 6시간 정도는 탑승한다고 생각하면 좋다. 도로의 85% 이상이 비포장 도로이기 때문에, 저 차를 타고 ATV를 버틴다고 연상하면 적절할 것 같다. 하지만, 인간은 적응의 동물이 아닌가? 금방 적응할 수 있다. 또, 푸르공도 깔끔한 새 차량이 당첨되면 매우 편안하게 탈 수 있다. 우리 차는 뽑은지 이제 2년이 막 되어가는 따끈따끈한 새 푸르공이어서 특히 더 만족스러웠다.

칭기즈 칸을 만나다

이 사람의 흔적이 보고 싶어서 나는 몽골에 왔다.

역사상 가장 위대한 정복자를 뽑으라고 하면 나라마다 다른 사람이 나올 것이다. 유럽에서는 프랑스의 나폴레옹 황제, 마케도니아의 알렉산더 대왕 혹은 이슬람에서는 우마르 칼리프 등등 정복자라고 하면 이 세상이 이름을 내걸 수 있는 사람이 많이 있다고 생각한다. 하지만, 이 사진의 뒤에 있는 이 사람 앞에서는 모두 작아질 수 밖에 없을 것 같다. 나는 우리나라를 9회에 걸쳐 침략한 대 원제국을 세운 칭기즈칸의 동상에 방문했다. 우리나라 역사를 통해 보면 좋아할 수 없는 사람이지만, 개인적으로는 정말 대단한 사람이라고 생각하고 또 존경하는 인물이다.

동상의 크기에서 몽골인들의 생각을 엿볼 수 있다.

실제로, 몽골에서 칭기즈 칸은 단순한 역사의 인물이 아니다. 이 나라가 가장 사랑하는 인물이자 가장 존경하는 인물이다. 마치 몽골인들을 구원한 신같은 존재가 바로 징기즈칸이다. 그런 사랑은 이 사람의 동상 크기에서 엿볼 수 있는데, 징기스칸을 상징하는 저 동상의 크기는 상상을 초월한다. 동상의 크기는 그 나라가 그 사람을 얼마나 사랑하는지를 엿볼 수 있는 방법이라고 하는데, 몽골인들이 칭기즈 칸을 얼마나 사랑하는지는 동상의 크기로 바로 말할 수 있을 것 같다.

우리나라와의 역사를 잠시 덮어두고, 개인으로서는 존경하지 않을 수 없는 인물이기에 나 또한 동상을 보며 많은 생각이 들었다. 한 개인으로 태어나 세계 역사에 한 획을 긋는 업적을 쌓은 저 사람은 얼마나 큰 책임과 권한을 지고 살았을까 한번 생각해볼 수 있는 곳이었다. 이 척박한 땅에서 저 사람만큼의 업적을 쌓은 것은 이 세상에 단 한 사람뿐이기에 더 크게 와닿은 것 같다. 과연 나는 저 사람이 짊어진 무게를 감당할 수 있을까? 아마 아닐 것이다.

0123

드넓은 몽골의 자연으로

웅장한 몽골 역사는 뒤로 하고 이제는 몽골의 자연과 마주할 차례이다. 우리는 푸르공을 타고 달리고 달려 테를지로 향했다. 그리고 나는 이때부터 푸르공만 타면 잠들었던 것 같다. 아마 몽골여행을 쾌적하게 하는 최고의 방법은 잘 자는 것이다. 특히, 덜컹거리는 푸르공에서 잠들 자신만 있다면, 몽골 여행은 정말 꿀같을 것이다. 나는 머리만 닿으면 잠드는 스타일이라 여행이 너무나도 쾌적했다. (물론 다른 동료들은 푸르공의 시간들을 좋아하지만은 않았다)

푸르공 내부에서 한 컷, 즐거운 동지들과 함께

우리의 다음 목적지는 거북이 바위, 사실 나는 무슨무슨 바위라고 하면 크게 기대하지 않는다. 우리나라에 있는 여러 이름있는 바위들을 봤을 때 크게 감명 받은적이 없어서, 이번 거북이 바위도 그냥 큰 원같은 돌을 보면서 거북이라고 이야기하지않을까? 라고 생각했다. 물론, 도착했을 때 내 생각은 산산조각났다. 그리고 '몽골 생각보다 만만치 않은 동네구나'라고 생각했다.

0123

거북바위는 진짜 거북바위다. 정말 말 그대로 거북이 그자체였다.

여행 직전 다녀온 터키, 그 전에 방문한 장가계나 미국의 대자연들을 보며 느꼈던 장엄함이 이 곳에는 널려있다. 다른점이 하나 있다면, 여기에는 사람이 비교적 적다. 특히, 내가 간 가을은 비수기라 이런 크고 멋진 자연들 앞에 사람이 한명도 없었다. 덕분에 마치 전세 낸 듯이 놀러다닐 수 있어서 정말 좋았던 것 같다. 다른 나라같았으면, 이런 곳에 적어도 여행 팀이 3~4팀 있었을 텐데, 우리는 이 때부터 우리와 동선 겹치는 팀을 한번도 볼 수 없었다. 정말 날짜를 잘 잡았던 것 같다.

몽골의 아픈 기억 티베트 불교로

티베트 불교 아르야발 사원에서

몽골 역사에서 티베트 불교는 들을 수록 슬픈 기억이다. 소련 예하에서 공산국가였던 몽골은 공산주의 정책 중 종교 말살정책을 펼쳤고, 그 과정에서 수많은 승려분들이 살해당하셨다고 한다. 가이드분께 듣기로는, 처음부터 그랬던 것은 아니고 공산정책에 반발하는 지식인들이 많아지고 그 중 국민들의 존경을 받는 승려들도 많다보니 참사가 발생했다고 한다. 당시 정부는 지식인들과 승려들을 살해해서라도 그들의 입을 막고싶었기에, 빠르게 티베트 불교를 말살하는 정책을 펼쳤다고 한다. 몽골을 달리다보면, 아직 몽골인들의 티베트 불교에 대한 존경을 엿볼 수 있었지만 한편으로는 아픔도 느낄 수 있었다. 몽골의 슬픈 역사에서 오는 한이구나 라고 생각했다.

몽골의 아픔에 공감하면서도 나는 우리의 불편한 이웃, 북한에 있던 절들은 어떻게 되었을지 궁금해지기도 했다. 공산국가 아니 독재국가인 북한에 있는 종교의 흔적들은 어떻게 되었을까? 광개토대왕 때 지었던 광법사(평양에 위치)는 아직 존재할까? 그곳의 승려분들은 공산정권이 설립될 때 과연 어떻게 되었을까? 몽골의 역사를 보면서 우리나라 역사 한켠을 살펴볼 수 있는 대목이었다. 이들의 아픔이 마치 남의 일이라고만 생각되지는 않았다.

01234

몽골의 절들에는 아픔이 서려있다.

하루의 마무리

말과 함께

몽골에서 말은 이동수단이자 동료이자 삶이다. 모든 곳에 말이 있기 때문에, 우리나라에서 말을 탈 때와 다르게 매우 저렴한 가격에 말을 탑승할 수 있었다. 제주도에서 15분정도 말에 타면 2~3만원을 지불해야했던 것과 다르게 이 곳에서는 1시간 이상 탑승했음에도 불구하고 절반도 안되는 가격에 말을 탔던 것 같다.

이 곳의 말들은 우리가 아는 멋있는 말들과 많이 다르다. 다리는 짧고, 몸도 길쭉길쭉하지 않다. 우리가 영화에서 보는 백마 탄 왕자님이 타고 나오는 말이랑은 매우 다르다. 하지만, 이 말들은 그 말들과 다르게 쉽게 지치지도 않고, 인내력도 강하다. 외연과는 다른 강한 인내와 힘이야 말로 몽골을 상징하는 말이지 않을까? 그런 점에서 이 몽골의 말들은 그 이미지에 매우 부합하는 것 같다. 또, 이 말들의 조상들은 이 지구에서 그 어떤 말들도 하지 못했던 일들을 해낸 대단한 말의 후손들이다. 바로 세계정복 말이다.

0123

저녁은 늘 맛있는 보드카와 함께했다.

다음 글에서 계속

나의 몽골 여행기(1, 울란바토르로 떠나다.)

susong — Mon, 6 Mar 2023 21:11:43 +0900

들어가면서

근 10일간 함께한 투어 동지들과 함께

터키를 다녀오고 1달이 지난 시점, 나는 아직 여행이 목말랐다. 군에서 보낸 2년 4개월의 갇혀있던 시간은 3주 정도의 터키여행으로 갈음하기에는 너무 컸고, 나는 그 여행에 대한 목마름을 충족시킬 어딘가를 찾아다녔다. 인도와 스탄 국가들을 제외하고 거의 모든 아시아 국가를 다 가본 나로서는 몽골은 아직 가보지 않은 미지의 땅이었고, 나는 이 갈증을 채워줄 곳으로 몽골을 선택했다.

몽골을 가기로 마음 먹은 후, 여러 리뷰들을 비교하며 어떻게 갈까를 생각해 봤다. 개인적으로 가장 선호하는 여행 방법은 충분한 조사를 바탕으로 한 개인여행이지만, 몽골은 그런 부분이 매우 제한적이라는 것을 조사를 통해 알 수 있었다. 실제로, 가장 유명하고 볼 것이 많은 여행지들은 수도에서 비포장 도로를 15시간 이상 달려야 하는 곳이 대부분이었고, 이런 부분은 개인이 간다면 얻기에는 많이 힘든 교통수단이기 때문이다. 그렇게 나는 몽골에 대한 가장 많은 정보가 있는 네이버 카페인 러브몽골에서 동료를 구하기로 마음먹었다.

글을 읽고 모집인이 좋은 사람이라고 생각했고, 이 팀에 참여하기를 희망했다.

실제로 러브몽골 카페에 가면 수 많은 구인글들이 하루에도 몇 십 개씩 올라오고 그 안에서 수많은 팀들이 자신의 동행자들을 구한다. 나는 2일 정도 이 카페에 수시로 들어가서 구인글들을 확인했는데, 우리 팀의 모집글을 보고 '아 이 팀은 가고 싶다'라는 생각이 들어서 바로 연락을 취했다. 사실 내 일정에 더 맞는 팀도 있었고 내가 원하는 일정에 더 맞는 팀들도 있었지만, 이 팀의 글을 보고 모집인이 충분히 준비를 한 사람이구나라는 생각이 들어 이 팀으로 선정하게 되었다. 또, 글을 통해 사람의 인격을 본다고 모집인이 충분히 좋은 사람일 것이라는 인상을 받았기 때문도 있었다. 물론, 그 추측은 여행을 통해서 맞았다는 것을 확인할 수 있었다.

여행을 출발하기 전에

나는 여행에 있어서 충분한 마음의 준비가 되지 않은 상태였다. 꼭 몽골에 가고싶어!라는 마음이 가득하기보다는 그냥 여행의 갈음을 채워줄 곳이 필요했고, 그 욕망을 채워줄 곳으로 몽골을 선택했기 때문이다. 나는 어딘가에 여행을 갈 때에는 그 나라의 문화와 역사가 궁금해서 갈 때가 많다. 실제로, 여행을 가기 전에 꼭 그 나라의 역사책을 읽고 가는 것도 같은 맥락이다. 하지만, 몽골 여행은 문화나 역사적 건축물보다는 드넓은 자연과 별들에 초점이 맞춰져 있기 때문에 마음에 확신을 가지지 못했던 것 같다.

하지만, 가기로 마음을 먹었고 또! 팀도 구했으니 꼭 가야겠다! 라고 생각했던 것 같다. 만약에 내가 팀을 안 구했다면 몽골에 갔을까? 잘 모르겠다.

고맙게도 우리 모집인은 필요한 모든 것들을 알려주었다.

나는 여행짐을 설렁설렁 싸는 편이다. 여행에서 얻은 경험들은 즐겁거나 고생이거나 모두 좋은 경험이라고 생각하기 때문이다. 그래서 역사, 문화, 언어 등 여행에 필요한 지식적인 부분은 모두 철저하게 준비하지만 물건은 크게 신경 쓰지 않아 왔다. 물론 이런 성격 때문에 여행 중에 낭패를 볼 때도 많았지만 그때마다 나는 '아 좋은 경험이다'라고 생각하고 넘겨왔었다. 이전까지는 그 부족한 짐 준비를 여행지에서 해결할 수 있는 경우가 많았기 때문인데, 만약 그렇게 이번 몽골도 갔다면 매우 힘들어질뻔했다..

몽골에서 공산품을 구하는 것은 한국보다 힘든 일이다. 특히, 내가 원하는 종류의 것을 얻을 확률은 매우 낮았다. 내가 수도의 가장 쇼핑하기 좋은 백화점 옆에 숙소를 받았음에도 불구하고 내가 사고싶은 것을 구하는 것은 어려웠다. 몽골 여행을 보면 모두 어떤 히잡 같은 모자 겸 망토를 쓰고 있는 것을 자주 볼 수 있는데, 나는 특히 이것을 미리 준비하지 않은 것을 끝까지 후회했다. 그냥 가서 사면 되겠지라고 생각한 게으름의 말로라고 하면 그렇다고 할 수 있다.

그래도, 우리 모집인이 어떤 것들은 그래도 준비해야되는지 알려주어서 덕분에 큰 위생, 생활상 문제는 없이 여행을 마무리할 수 있었다. 혹시, 몽골 여행을 준비하는 사람이라면 꼭 기억해라 몽골에 갈 때는 챙길 수 있는 것은 모두 챙겨라. 가서 부족할 일은 잘 없다. 이걸 가져가? 말아? 싶으면 챙겨라 가서 필요할 수 있다.

짐을 싸고, 같이 가는 동행인들과 한번의 술자리를 진행한 후 나는 몽골로 가는 비행기에 몸을 실었다. 어떤 여행이 펼쳐질지에 대한 호기심과 설렘을 가득 안고 그렇게 비행기를 타고 울란바토르로 향했다.

그렇게 몽골에 도착했다.

몽골 도착 직전 창가에서 찍은 사진

몽골은 매우 추웠다. 정말이지 내 생각보다 훨씬 추운 곳이었다. 다행히 날씨를 보고 가서 다행이지 그냥 갔다면 얼어죽었을 것이다. 나중에 확인해 보니 몽골의 수도 울란바토르가 세계에서 가장 추운 수도였는데, 가서 느낀 것은 '이런 곳에 도대체 어떻게 사람이 사나?'싶었다. 물론, 울란바토르는 약과였다. 나중에 간 사막들의 저녁은 너무나도 추웠다. 가을과 초봄에 몽골 여행을 계획하는 사람이라면 내복을 꼭 챙기기를 바란다. 입 돌아갈 수 있다.

울란바토르 공항입구에서 한 컷

공항은 그 나라의 입구이자 첫 인상이라고 하지 않는가? 몽골의 공항의 첫인상은 조그마하고 아늑하다였다. 실제로 이 공항은 그렇게 작은 공항은 아닌데, 그럼에도 불구하고 몽골의 가장 큰 공항이 생각보다 크지 않아서 작게 느껴진 것 같다. 하지만, 이 아늑함은 도대체 어디에서 온 것일까? 나는 그 이유를 금방 확인할 수 있었다. 곳곳에 한국에서 매우 익숙한 점포들이 존재했기 때문이다. 내 눈이 닿는 모든 곳에 한국 브랜드가 1개 이상은 있었다. CU, GS25, 카페베네 등등..

여긴 한국인가 몽골인가?

이 CU와 GS25는 몽골 수도 모든 사거리에 존재한다.

그렇게 나의 몽골에 대한 첫 인상은 아늑함으로 시작했다. 어디에나 한국에서 자주 보던 상표들이 있었고, 많은 사람들은 실제로 한국말도 잘했다. 내가 어눌한 몽골어로 물어보고 있으면 옆에서 어떤 사람이 한국말로 대답을 해주는 경험을 자주 할 수 있었다. 나중에 가이드님을 통해 몽골에 우리나라어를 할 줄 아는 사람이 그렇게 많다는 것을 알게 되었다. 실제로, 몽골에서 많은 젊은 사람들은 낮은 임금과 산업의 부족 때문에 한국으로 일하러 많이 온다고 한다.

마치, 우리나라 60~70년대에 파독근로자분들께서 우리나라로 외화를 벌어오셨듯, 이 나라의 젊은이들은 우리나라로 외화를 벌기 위해 오는 것이다. 그 과정에서 많은 사람들이 한국어를 배우고, 한국 문화에 익숙해진다고 한다. 실제로 많은 몽골 사람들은 우리가 한민족이라는 것에 즐거움을 느끼는 것 같았다. 여러 몽골분들을 통해 우리가 한 민족이라는 이야기를 들었고, 즐거워하셨다. 나는 그분들이 우리나라를 이렇게 좋게 생각해 주시는 것에 감사하고 덩달아 기분 좋았었다.

이 나라는 콜라에도 한국 국기가 있다(도대체 왜!!?)

실제로 우리 가이드분도 한국에서 10년 이상 거주하신 경험이 계셨고, 그 체류 기간 중에 딸 아이도 한국에서 낳으셨다고 한다. 덕분에 유창한 한국어 실력을 가지셨고, 이 경험을 살리셔서 고향에서 가이드를 하고 계셨다. 나는 특히, 우리 가이드분이 우리나라를 좋게 생각해 주셔서 감사했다. 그분께서 우리나라를 언급할 때 늘 좋은 이야기가 나오는 것을 보고 내가 몽골에 대해 너무 무지하지 않았는가? 에 대해 후회하기도 했었다. 실제로, 몽골에 가서 보면 너무 많은 사람들이 한국에 관심을 가지고 알고 싶어 한다. 또, 몽골 어디를 가도 한국 브랜드와 제품들이 자리를 차지하고 있다. 우리나라 사람들은 대부분 상상하지 못하는 일이겠지만 말이다.

한국 문화와 몽골역사

건물만 보면 공산권 국가가 맞다.

광장, 딱딱한 건물 그리고 네모네모함. 완전 공산권 국가 그 자체인데, 생각보다 몽골의 사회는 한국의 근현대사와 닮아있다. 이 나라는 재미있게도 세계에서 가장 낮은 인구밀도를 가졌음에도 불구하고 인구 절반 이상이 이 작은 올란바토르 수도에서 살고 있다. 그 과정에서 지방소외, 환경오염, 그리고 빈부격차 등 우리나라가 80 ~ 90년대에 겪었던 수많은 문제들을 그대로 겪고 있다. 다른 점이라고 하면 우리나라는 그때 적절한 리더십과 냉전을 통해 얻은 이득 등이 있었다는 점이다. 아쉽게도 우리나라와 발전상은 닮지 않았지만, 우리가 겪었던 문제를 겪고 있는 몽골은 어떻게 보면 진짜 형제의 나라가 아닌가 싶다. (심지어 내몽골 / 외몽골로 분리된 것도 비슷하고 생각했다)

0123

실제로 이 사람들이 먹는 음식들을 봐도 우리와 닮아있다. 수도를 벗어나면 당연히 우리나라 음식이 퍼져있지 않지만, 수도 내에서는 우리나라 음식을 찾는 것이 매우 쉬웠다. 고개를 90도만 돌려도 한국음식점을 찾을 수 있었을 정도였으니 더 말할 필요도 없을 것 같다. 한류가 물들인 동남아를 가봐도 우리나라를 이렇게 사랑하고 우리나라 음식을 찾는 곳은 없을 것 같다. 우리나라와 가장 가까운 문화를 공유하는 곳은 몽골이지 않을까?

다음글에서 계속

[42서울] 인셉션을 마치고(Docker, LXC)

susong — Sat, 4 Mar 2023 21:22:52 +0900

들어가면서

5서클에 올라오자마자 가장 만만한 친구를 고르자면 아마도 (내게는)이 인셉션이다. 이 과제는 내가 정한 리눅스 내에 가상머신의 꿈 속의 꿈을 구현해내는 과제인데, 이 과정에서 Docker을 통한 가상화를 깊이있게 학습하게 된다. 나는 지금도 3개 이상 팀에서 웹 서비스 배포를 담당하고 있다보니, 이러한 작업에 익숙해졌고 덕분에 편안하게 과제를 잘 마무리할 수 있었다. 과제의 총 소요기간은 약 5일정도였으며, 나는 과제에서 필수적으로 요구하는 PHP, DB, NGINX 외에도 추가적인 서비스들을 구축하여 보너스 점수를 얻을 수 있었다.

내가 총 구현한 도커 컨테이너는 10개로 각각은 다음과 같다.

필수 구현 : MariaDB, Nginx, WordPress

보너스 구현 : Redis, adminer, vsftpd, react(site), grafana, prometheus, cadvisor

* 이 중 grafana와 그 것을 위해 필요한 prometheus, cadvisor는 특히 필수가 아니지만 나중에 K8s 공부할 때 유용하게 써먹을 수 있을 것 같아서 설치해봤다.

첫 인상

과제를 들어가면 잘생긴 디카프리오 형님이 맞아주신다.

사실 5서클에 보면 컨테이너라는 과제가 있어서 인셉션이라는 과제를 보고 도커를 공부해야된다고 인식하기는 어려웠다. 컨테이너 과제를 하기 전에는 왜 인셉션 과제를 보고 바로 컨테이너를 떠올리지 못하게 했을까하는 의문도 있었다. 하지만, Docker가 작동하는 방식을 좀 알고나니 그리고 컨테이너 과제가 만드는게 진짜 STL의 컨테이너임을 알고나서는 납득했다.

과제의 이름의 유래와 내가 곧 도커를 공부한다는 것을 알고나서 나는 매우 흥분한 상태에서 공부를 진행했다. 가장 좋은 공부는 내가 그 필요성을 온 몸으로 체감할 때가 가장 좋다고 하지 않는가? 그 때의 나는 도커에 매우 목마른 상태였다. 나는 인셉션을 진행하기 직전, 3개의 EC2 인스턴스를 관리하고 있었는데, 이 인스턴스들은 모두 비슷한 역할을 하는 가상머신들이었다. 하지만, 내가 도커와 컨테이너 기술에 대한 지식이 부족하여 조금 더 효율화 할 수 없음이 늘 안타까웠다.(서비스들을 배포하기 위해 하나의 인스턴스를 그대로 사용해야했다. 이 과정에서 내 인스턴스에는 낭비되는 컴퓨팅 능력이 많았다) 그런 와중에 내가 해야되는 과제로 도커가 내게 찾아오다니!! 나는 과제를 하면서 정말 운이 좋다고 생각했다.

과제를 끝내고 바로 내 모든 서비스에 적용하겠다는 마음가짐과는 살짝 다르게, 과제를 끝낸 지금도 내 모든 인스턴스들에 도커가 적용되지는 않았다. 한 개의 서비스정도는 이 과정에서 배운 Docker-compose를 이용하여 배포를 완료했지만, 다른 녀석들은 나중에 조금 더 공부를 하고 하기로 남겨두었다. Docker를 공부하다보니, Docker-compose가 얼마나 편한지 알게되었는데 과연 쿠버네티스는 얼마나 편할까? 라는 생각이 들었기 때문이다. 곧 이너서클을 마치고 아우터로 가게되면 바로 쿠버네티스 과제를 진행할 예정인데, 그때 공부를 마치면 바로 적용해볼까 싶다. 그때는 AWS에 있는 컨테이너와 쿠버네티스 서비스를 이용해서 배포할 예정이다.

과제를 통해 알 수 있는 것은?

과제를 통과한지 벌써 한달이다. 그 때 바로 작성했다면 참 좋았을텐데.. 너무 늦어버려서 지금은 정말 세세하게 내가 어떤 것들을 배웠는지 말하기 쉽지않다. 지금 누군가가 내게 도커에 대해 물어본다면 성실히 답변해줄 수 있지만, 그 지식이 이 과제를 하면서 얻은 것인지 아니면 그 후에 더 공부하면서 배운 것인지 구분하기 어렵다. 하지만 인셉션을 통해서 얻은 지식은 아래와 같다.

내가 이 과제를 통해서 답하거나 할 수 있게된 것은?

1. 기존 가상머신 및 격리 기술과 이 도커가 다른 것은? 격리기술 발전사는 어떻게 되는가?

2. 도커가 의존하고 있는 리눅스의 기술들은 무엇이고 그것들은 어떻게 작동하는가?

3. 도커의 생명주기는 어떻게 되고, 각각의 과정을 직접 해낼 수 있는가?

4. 도커를 작동시키는 명령어들은 무엇이고 그것을 실제로 사용할 수 있는가?

5. 컨테이너에 볼륨을 설정해줘야하는 이유는 무엇인가?

6. 컨테이너간 네트워크는 어떻게 작동하는가?

7. 왜 도커 컴포즈라는 기술이 나왔고, 작성할 수 있는가?

8. 도커 컨테이너를 제작하기 위해 필요한 문서 혹은 명령어들을 작성할 수 있는가?

9. 컨테이너를 모니터링하는 툴들은 어떻게 작동하는가?

10. PID 1의 의미는 무엇이며, 그것이 하는 역할은 무엇인가? 또한, 커널은 프로세스 관리를 어떻게 하는가?

위의 질문정도는 확실히 인셉션을 위해서 공부한 내용인 것 같다. 나는 위 질문들에 대한 대답을 평가자에게 해주면서 평가를 받았고, 많은 평가자들은 내 평가에 매우 만족하는 평가 의견을 제출해주었다. 실제로, 하루에 3번의 평가를 모두 받았는데 마지막에 갈 때는 처음에는 2시간 걸린 설명보다 훨씬 유려하게 1시간만에 평가를 받는 기염을 토했다.

과제는 컴포즈와 필요한 명령들을 포함하는 파일들만 올리고 컴포즈 단일 파일을 이용하여 컨테이너를 제작하는 절차를 밟게되는데, 이 과정에서 실제 명령어가 창에 나올 때마다 이게 실제로 컴퓨터 내에서 작동하는 것을 그림으로 보여주면서 설명했다. 특히 네트워크 같은 부분은 설명에 있어서 그림이 매우 효과적이었는데, 나 또한 도커 네트워크는 그림을 그려서 스스로 이해했기 때문에 나의 경험에 미루어 상대에게 설명하는 것이 매우 효과적이었던 것 같다.

평가가 끝난 후

세 분의 고객님(평가자)들은 매우 만족해하셨다.

도커를 깊이있게 한번 찍어 먹어보니, 매우 재미있었고 이게 내 길인가 싶었다. 안그래도 몇몇 서비스를 기획하고 만들고 또 운영하면서 '아! 나는 이 배포 + 운영쪽이 매우 잘 맞는걸?'과 같은 생각을 해왔는데, 이번 과제를 통해서 내 갈 길에 더욱 확신을 가지게 되었다. 이전까지는 인프라 서버 개발 혹은 프론트 개발자를 생각하고 있다가, 이번 과정을 통해서 DevOps쪽이 나랑 맞는 것 같다고 확신했다.

철학과와 컴퓨터 공학을 전공함으로써 얻은 인문학적 소양 그리고 컴퓨터 관련 핵심지식, 10명이상의 고3 과외 경험과 장교로서의 경험을 통해 얻어낸 커뮤니케이션 스킬들이 한번에 섞여서 내게 커리어적으로 갈 길을 제시해주었다. 물론, 나는 내가 DevOps가 뭔지 정확히 아는지 잘 모르겠다. 실제로 관심이 생긴 후 '이걸 지향해야겠다!' 라고 생각은 했지만, 아쉽게도 아직 실제 현업에서 활동하고 계신 데브옵스 개발자분을 만나뵙지는 못했다. 내가 생각하는 그리고 인터넷에 작성된 업무내용이 실제와 같은지 확인하지 못하는 것은 아쉬운 부분이다. 원래 42에 있었던 비상근 멘토분들이 유지되었다면 만나뵐 수 있었을 텐데 조금만 더 빨리 이 길을 찾았으면 어땠을까.. 하는 아쉬운 마음이 있다.

하지만, 이제 목표를 잡았으니 앞으로는 달리기만 하면될 것 같다는 생각도 있다. 지금은 42에서 해야하는 이너서클을 모두 끝내야하지만, 그것을 모두 마치게 된다면 나는 AWS자격증 공부 및 쿠버네티스 공부를 할 예정이다. 공부는 원래도 좋아했지만, 이 두 단어는 내게 설렘으로 다가오는 것을 보면 내가 정말 이 기술들에 큰 기대를 하고 있는 것 같다. 빨리 이너가 끝나고 이것들을 더 공부하고 싶고, 이런 마음은 내게 더 큰 열정을 불러일으켜주고 있다. 이렇게 내 사고가 확장시켜준 인셉션 과제에게도 감사하다.

[42서울] 5서클 ft_container을 보내며(Generic Programming)

susong — Fri, 3 Mar 2023 10:22:20 +0900

들어가면서

드디어! 5서클의 ~~악명높은~~ 컨테이너 과제를 성공적으로 마쳤다. 처음 이 과제를 마주했을 때에는 도대체 내게 무엇을 원하는 것인지 몰라서 절망한 순간들도 있었지만, 이렇게 과제를 다 마치고 나니 이 과제를 통해서 정말 많은 것들을 배웠던 것 같다. 이제는 42서울 과제 난이도 조정으로 인하여 이너서클의 필수과제가 아니게 되었지만, 옛날에 존재했던 이 컨테이너라는 과제가 도대체 무엇이었을지 궁금할 수 있는 카뎃분들과 내가 이 과제를 통해서 어떤 것들을 배웠는지 남기기 위해서 글로 흔적을 남겨본다.

컨테이너?

컨테이너라고 하면 모두들 어떤 것이 생각나는가? 대부분의 사람들은 부두에서 볼 수 있는 네모네모한 상자들을 생각해낼 것이다. 나는 그래도 프로그래머라고 도커를 가장 먼저 생각했다. 하지만, 이 과제는 도커 과제가 아니다. 이 과제에서 말하는 C++에 있는 STL의 컨테이너이다. 즉, 천재 프로그래머들이 이미 열심히 만들어둔 C++의 표준 자료구조형을 가르키고 있는 것이다. 문제가 가르키는 것이 명확하다는 것은 곧 내가 그것을 해야된다는 것이다. 그렇다 이 과제를 통과하기 위해서는 바로 그 엄청난 자료구조들을 모두 만들어야 한다.

너무 한거 아니냐고 컨테이너!!

과제를 간단하게 설명하면 아래와 같은 조건을 만족시켜야된다.

1. 사용할 수 있는 외부함수 : 거의 없다. 필요하면 직접만들어라

2. 사용하는 언어 : C++98 11이나 17에서 제공하는 아름다운 기능들은 모두 제한된다.

3. 만들어야되는 것 : Iterator, Vector, Stack, RedBlackTree, Map, Set

* 당연한 이야기지만 해당 컨테이너에 있는 모든 메소드를 구현해야한다.

4. 하면서 느낀점 : 선배 개발자님들 정말정말 감사합니다.. 저도 앞으로 받은만큼 기여하겠습니다...

과제를 마치기 위해서는 총 4개의 컨테이너를 만들어내야된다.

일반적으로는 구현하는 순서는 아래와 같은데, 실제로 나도 아래와 같은 순서로 구현했다.

1. std::vector를 이용하여 stack 제작 이후 enable if 등 필수 메타함수 제작

2. Iterator Traits와 iterator제작을 위해 필요한 필수적인 알고리즘 제작, pair등 map을 위해 필요한 요소 제작

3. RandomAccessIterator, Bidirecton Iterator , Reverse Iterator 제작

4. 자신만의 vector를 구현한 후 stack에 적용된 std::vector를 my::vector로 대체

5. RedBlackTree를 구현(구현과정에 나중에 map과 set에 사용될 수 있도록 설계 필요)

6. 제작된 Tree를 기반으로 map, set 구현

나 같은 경우 이 모든 과정에 소요된 시간은 공부 시간 포함 170시간 이상이 소요되었다. 공부를 하다보니 Template프로그래밍과 SFINE등등에 대해 정확히 어떻게 작동하는지 확인하기 위해 컴파일러를 뜯어보는 시간이 소요되었고, 특히 제네릭 프로그래밍이 어떻게 작동하는지 이해하기 위해서 시간이 더 소요된 것같다. 그렇게 약 14일의 과정을 통해 모든 구성요소를 제작했고, 1~2일의 테스트케이스 제작 및 확인 그리고 디버깅을 통해 과제를 완성할 수 있었다.

과제를 통해서 얻은 것들

평가(과제 디펜스)를 위해 준비한 질문들. 나는 작성해둔 질문을 따라가면서 평가자를 납득시켰다.

'나를 죽이지 못하는 고통은 나를 강하게 만든다'라는 말이 있듯, 컨테이너도 나를 강하게 만들어주는 스트레스였다. 특히, 이번 컨테이너 과제는 남은 것들이 정말 많은 과제였는데 나는 이 과제를 통해 정말 많은 깨달음을 얻었기 때문이다. 일단 이번 과제를 통해 내가 대답할 수 있게 된 것들이 많아졌다. 그 중에 몇 가지 대표적인 것들을 써보자면 아래와 같다.

1. C++에서 컨테이너란 무엇인가?

- 컨테이너와 iterator와의 상관관계는 무엇인가?

- Template 프로그래밍이란 무엇이고 이는 어떻게 작동하는가?

- 템플릿 특수화는 어떻게 할 수 있고 어떻게 작동하는가? 우선순위는 어떻게 되는가?

- 오버로딩과 오버라이딩의 정확한 차이가 무엇인지 알고있는가?

- 왜 Iterator가 필요한가?

2. Generic Programming이란 무엇인가?

- 원시자료형을 쓰지않는 언어의 내부는 어떻게 작동하는가?

- SFINE란 무엇이고 무엇을 의미하는가? 알았다면 왜 그것이 필요한가?

- Container, Iterator, Algorithm간의 상관관계는 무엇이고 이렇게 만든 이유가 무엇인가?

- 컨테이너 과제를 통해서 알 수 있는 추상화란 무엇인가?

3. 시퀀스 컨테이너란 무엇이고 연관형 컨테이너는 무엇인가?

- 이 둘을 구분짓는 이유는 무엇인가?

- 시퀀스 컨테이너(Vector, Stack)은 어떤 자료구조형을 가지는가?

- 연관형 컨테이너(Map, Set)은 어떤 자료구조형을 가지는가?

- 그 둘이 가지는 자료구조가 만든 장단점은 어떤 것들이 있는가?

- 해당 컨테이너들이 가지고 있는 메소드들은 자료구조와 어떤 연관성이 있는가?

- Tree형 자료구조의 장점과 단점은 무엇인가?

- 컨테이너들의 메소드들은 어떻게 구현되어있는가?

- 각각 컨테이너는 어떤 상황에 사용해야되는가?

4. Iterator의 Traits란 무엇인가? 그것은 왜 제작되었고 어떻게 사용되는가?

5. RedBlackTree란 무엇인가?

- 다른 BST들과는 어떠한점이 다른가?

- 특히 DB에 많이 쓰는 B-Tree와는 무엇이 다른가?

- 이 트리의 성능은 어떠하고 어떤 특징을 가지는가?

- 이 트리의 삽입과 삭제는 어떤 과정을 통해서 작동하는가?

- 성능을 측정하는 빅 O의 계산은 어떻게 하고 왜 이것이 중요한가?

42서울 내에서 과제의 완성은 디펜스이다. 주어지는 평가지에 따라서 피 평가자는 평가자를 납득시킬 의무가 있는데, 나는 위의 질문을 하나하나 짚어가면서 평가자를 납득했다. 필요하다면 기본 컴파일러 코드를 보면서 설명했고, 예시가 필요한 부분은 미리 만들어둔 예시를 통해서 설명했다. 한 사람당 평가를 할 때 거의 90분 내외로 걸리다보니 힘들 때도 많았지만, 여러번 반복하면서 설명하다보니 마지막에 가서는 눈 감아도 개념을 설명할 수 있는 지경이 이르렀다.

컨테이너를 보내며

처음에는 과제의 막연함에 화가났고, 처음 참고하기 위해 들어간 gcc의 헤더파일들은 막막했으며, 쳐야하는 코드의 양에 답답함을 느꼈던 컨테이너라는 과제가 끝났다. 미운정이야 말로 인간이 느끼는 강한 정이라고 하지않는가? 나도 이 컨테이너라는 과제에 많이 정든 것같다. 이 과제가 이제 사라져 Deprecated된다는 것에 마음 한켠이 아쉽다. ~~내 뒷 기수도 이 고통을 맛봐야되는데..~~

그래도 나는 이 과제 덕분에 이제 헤더파일 보는 것이 두렵지 않게 되었다. 과제 덕분에 #include <vector>처럼 컴파일러가 제공하는 코드들은 이제 친숙하고, 또 덕분에 오픈소스 코드를 읽어도 더 이상 주눅들지 않을 수 있게 되었다. 그리고 가장 중요하게는, 앞으로 사용할 상위레벨 프로그래밍 언어가 어떻게 동작하는지에 대한 단초를 얻었다. 대학생 시절 많이 쓰던 Python의 자료구조형들은 어떻게 되어있을까 많이 궁금했었다. 그 궁금증은 42에 와서 원시 자료형을 주로 사용하다보니 더 커져갔는데, 이번 기회에 어느정도 단서를 찾은 것 같아서 행복하다.

물론, 이 과제를 통해서 얻을 수 있었던 것은 단초일 뿐이다. 이 단초를 어떻게 발전시켜서 내 것으로 만들지는 나의 몫이라고 생각한다. 나는 이 자신감을 바탕으로 앞으로 내가 주력할 언어인 JS와 TS의 코드 구조를 한번 살펴보려고 한다. 어차피 앞으로 많이 쓸 녀석이라면 어떻게 쓰는지만 아는 것이아니라 어떻게 작동하는지까지 알면 좋지 않겠는가?

세상에 하나뿐인 나만의 Vector 중 일부

2월의 성장 포인트, Container. 미운 녀석이지만 덕분에 많이 배우고, 많이 성장했다 고맙다

[42서울] 23년 2월 Top Contributor가 되다

susong — Thu, 2 Mar 2023 22:00:35 +0900

42서울의 Top Contributor

1월의 Top Contributor Yooh님과 함께 시상식에서

42서울에는 코알리숑이라는 제도가 있다. 이 제도는 (마치 해리포터의 그리핀도르, 스미드린 처럼) 42서울 내 구성원들 간에 팀과 소속감을 가지고 서로 선의의 경쟁을 부추기기 위해 존재한다. 나는 건곤감리 중 곤의 소속으로 곤 내부에서 특별한 자리를 차지하고 있지는 않았다. 이 그룹에 소속된 인원들은 자신의 소속에 애착을 가지고, 더 높은 코알리숑 점수를 얻어 다른 코알리숑을 이기는 경험을 할 수 있다. 이번 달 우승한 코알리숑은 건(노랑색)이었지만, 2월에 42서울 전체중에서 가장 많은 코드를 치고 활동을 한 인원은 나여서 덕분에 이런 영광스러운 자리에 수상을 받을 수 있었다.

그냥 열심히 하고 있었는데

사실 나는 이런 탑 컨트리뷰터 제도가 존재하는지도 몰랐다. 나는 그저 열심히 코드를 치고있었을 뿐인데, 갑자기 어느날 아침에 일어나 하루를 계획하며 42사이트에 들어가니 내 얼굴이 크게 팝업으로 떴다. 사실 이 때는 무슨 일인가 싶어서 그냥 그러려니하고 넘겼는데, 알고보니 이게 내가 이번달에 가장 많은 활동을 한 인원이라는 뜻이었다.

그래서 생각해보니 이번달에는 정말 많은 시간 코드를 치는 것에만 몰두했던 것 같다. 주말 중 하루를 제외하면 거의 모든 시간(아침 8시부터 저녁 11시까지) 계속 컴퓨터 앞에 코드를 치곤 했으니 말이다. 덕분에 남들이 2달 걸릴 것이라고 하는 과제들을 2주에 깨버리는 기염을 토할 수 있었지만, 나는 이게 뭔가 내가 대단한 사람이라서 그런 것이 아니라 시간을 많이 투입해서라고 생각한다.

우리 42내에 있는 과제들은 권장되는 학습시간이라는 것이 있다. 대체로 뒤쪽 과제일 수록 집중하는 시간 기준으로 140 ~ 200 시간의 권장 시간을 가지는데, 나 같은 경우에는 하루에 집중시간이 10시간 이상이었으니 어떻게 보면 정석적인 속도로 나아갔다고 할 수 있다. 내가 특별해서 상을 받았기보다는 그냥 꾸준함에 대한 보상인 것 같다.

마무리로 가는 42서울 이너서클

대망의 이너서클의 끝까지 이제 2개의 과제만 남았다.

하나의 과제는 C++로 작은 Nginx를 만들어보는 웹서브 프로젝트, 그리고 남은 하나는 TS와 여러 상용프로그램들(디비나 백엔드 노드 등)을 이용하여 실시간 채팅 서버 및 핑퐁게임을 만드는 트렌센던스 프로젝트이다. 군 휴학을 한 상태에서 제천 군부대에 갇혀 하염없이 저걸 언제 다 해낼 수 있을까? 혹은 내가 잘할 수 있을까? 했던 순간이 어제같은데 벌써 마지막이다.

지금까지 잘해왔지만, 어떤 일이든 끝이 좋아야 다 좋다고 생각한다. 남은 두 과제도 이전 과제들처럼 많은 것들을 남겨서 내 인생에 좋은 밑거름이 되도록 노력해야겠다. 남은 2달만 더 지금처럼 쉬지않고 몰입하는 환경을 유지하면 될 것 같다.

멋진 상품들

탑 컨트리뷰터가 되면 많은 부상이 따라온다.

상으로 받는 것중에 많은 사람들에게 받은 축하만큼 좋은 것은 없지만, 그래도 부상도 꽤나 좋은 것들만 받았다. 양말, 스티커, 42서울 옷 등등을 받았지만 그 중에 가장 좋았던 것은 중앙에 있는 Top Contributor 뱃지였다. 뭔가 어깨를 올려주는 매력이 있달까.. 바로 받자마자 이 뱃지만큼은 가방에 달아두었다. 나중에 ~~누가 내 가방을 봐도 이 가방은 탑 컨트리뷰터의 것이라는 것을 알도록..~~

42에서는 늘 좋은 추억이 쌓이는 것 같다.

공부도 시켜주고 돈도 주고 즐거움도 가득하다. 42서울에 들어오기를 참 잘했다는 생각이 다시한번 드는 하루다.

42모글 개발기 발표 회고(안되면 될 때까지)

susong — Wed, 1 Mar 2023 12:39:46 +0900

발표 영상

내 발표 순서는 14:30부터(발표는 순서대로 mgo, susong, joonhan, minsukan)

우당탕탕!

정말 말 그대로 안되면 될 때까지 밀어붙일 수 있는 열정의 사나이들이 드디어 프로젝트를 마치고 그 후일담을 발표하게 되었다. 오늘은 우리의 프로젝트의 마침점인 발표에 대해서 한번 이야기해보려고 한다.

무엇을 개발하려고 했는가?

42내에서 공부는 자율과 책임을 강조하는 42커뮤니티답게 자신의 스케쥴에 맞춰서 진행되게 되는데, 대부분의 사람들이 그러하듯 이 스케쥴이라는 것이 자율로 하게하면 잘 작동하지 않는 부분이 많다. 자신에게 스스로 지속적인 자극을 주지 못한다면 게을러지는 것은 어쩔 수 없는 것은 인간이 가진 게으름의 형태이기 때문이다. 또한, 학교처럼 어떤 유대를 맺어주는 그룹을 형성해주지 않는 42특성상 다양한 사람을 만날 기회는 많지만, 오히려 만나는 사람만 만나는 단점도 있다. 정말 다양한 사람들이 있어 많은 인사이트를 얻을 수 있는 커뮤니티이지만, 그것을 잘 활용하기가 쉽지는 않은 것이다.

이러한 단점들을 극복해내기 위해서 42내에는 모닝글로리라는 존재한다. 모닝글로리는 말 그대로 ~~아침의 영광~~ 아침 일찍 오는 사람들의 모임이다. 이 동아리에 소속된 인원들은 매일 아침 08:30까지 개포 클러스터 1층에 모여서 오늘 하루 자신들이 할 일들을 이야기하고, 자신의 공부에서 힘든 부분을 이야기하는 시간을 가진다. 이렇게 함으로써, 아침형인간이 되는 것은 물론이고 자신의 막힌점을 도와줄 수 있는 동료를 찾을 수도있다. 그 과정에, 다양한 사람들과 인생을 만나며 자신의 인사이트를 넓히는 것은 덤이다.

하지만, 이러한 장점에도 불구하고 이 모닝글로리는 그 자체로만 작동하기 매우 어렵다. 아무래도, 아침에 일찍 나오겠다고 다짐해내는 사람의 숫자도 적을뿐만 아니라 그것의 수를 지속적으로 유지하는 것도 힘들기 때문이다. 또한 사람들이 많이 나와야 작동하는 동아리 특성상 사람의 수가 너무 가변적이라면 지속되기 힘들다. 어느날에는 사람이 10명이 나오고 어느날에는 2~3명만 나오고 한다면 그런 동아리에 나가려는 사람이 몇명이나 있을 것인가?

그렇게 이 동아리는 하나의 인센티브를 제공한다. 42내에는 월렛이라는 제도가 있는데, 이 월렛을 파격적인 조건으로 제공한다.(월렛은 교회 다니신분들은 달란트 마켓에서 쓸 수 있는 달란트라고 생각하면 된다.) 다른 동아리들은 10월렛이 최대 한계인데 반해, 모닝글로리는 완주시! 즉, 모든 평일에 개근할 시에 30월렛을 제공하고 이를 통해 42에서 제공하는 교육관련 재화들을 구매할 수 있다. 나 또한, 42에서 월렛으로 구매할 수 있는 AWS크레딧을 통해 많은 공부를 이어나가고 있다.

그런데, 이렇게 인센티브가 생기면 그 것을 어떻게 관리할 것인가?에 대한 문제가 생기게 된다. 특히, 이 개근자들을 어떻게 파악할 것인가? 또, 이 사람들에게 월렛을 제공하는 과정을 어떻게 효율적으로 진행할 것인가? 에 대한 문제가 발생하게 된다.

인센티브 관리를 위한 노력

내가 42커뮤니티에 들어오기 전부터 모닝글로리는 동아리는 유지되고 있었기 때문에, 이 동아리도 다양한 방법을 통해서 이 인센티브를 관리해왔다는 것을 들을 수 있었다.

테이블 어딘가에 종이가 있다..!

가장 먼저 진행한 방식은, 종이로 기록하는 방식이다. 매일 아침에 사람들이 제 시간에 출석하면 모인사람들을 대상으로 한땀한땀 수기로 이름을 적고 싸인을 진행하는 방식으로 인원을 기록했다고 한다. 하지만, 당연하게 느껴지지만 이 방법은 여러 단점을들 가지고 있었다. 가장 먼저, 이 종이로 된 기록을 유지하는 것 그리고 글씨를 인식하는 노력 또, 기록을 종합해서 인센티브를 제공해야하는 품이 드는 등등 수많은 문제점들이 발생하게 되었고, 그렇게 다른 방법을 찾아 나섰다.

내가 들어왔을 때는 이 방법으로 사용했다.

두번째 방식은 구글 폼을 사용하는 방법이었다. 이 방법을 통해 사람들의 수를 효율적으로 파악할 수 있었고, 분실의 위험과 인식의 문제는 조금 줄었다(인식의 문제는 여전히 존재했다. 특히 오타를 내거나하면 스프레트 시트 함수식에 인식이 안되는 문제 등등..) 해당 자료는 스프레드 시트를 통해 유지가 되었고, 어느정도 첫번째 문제를 해결한 상태에서 잘 진행되는 것처럼 보였다. 하지만, 개월수가 늘어나며 다루어야하는 데이터가 많아지고, 특히 인트라 ID오타나 오늘의 단어 오타로 인하여 소수의 진행자들에게 많은 일손이 부여되었다. 이렇게 소수의 진행자들이 고생하는 모습을 보며 많은 사람들은 진행자들을 자처하기 꺼려했고, 모닝글로리에 애착을 가지고 있는 사람들은 문제를 해결할 방법을 찾기로 결심한다.

작고 귀여운 모닝글로리 프로젝트 디자이너는 없어서 MUI를 열심히 활용했다.(3.1. 월초라 데이터가 없다)

그렇게 내가 참여한 방법인 웹서비스 방법이 고안되었다. 가장 먼저 프로젝트장 mgo님이 사람들을 모았고, 총 5명 프론트 개발자 2명, 백엔드 개발자 3명이 이 개발과정에 참여하게 되었다. 나는 처음에는 프론트 개발자로 참여하게 되었고, 그렇게 프로젝트는 1달 이상의 시간을 쏟은 끝에 잘 마무리하게 되었다. 인사가 만사라고, 사람들이 좋으니 개발능력이 떨어지는 것은 크게 문제가 되지 않고 잘 마무리할 수 있었다. 1달 이상의 시간을 지하 강의실(우리는 이곳을 지하갱도라고 불렀다)에서 시간가는줄 모르고 개발했고, 결국 잘 마무리할 수 있었다.

출석 사이트 말고도, 통계를 확인할 수 있는 대쉬보드도 제작하여 운영진의 피로도가 줄었다.

원래 우리가 해결하려고 했던 문제들은 모두 해결되었다. 우리 사이트는 이제 매일매일 자신의 Intra ID를 입력해야되는 방식에서 자신의 아이디로 로그인하여 출석하는 방식으로 변경되었고, 오늘의 단어는 이제 정확하게 작성되지 않으면 제출되지 않도록 변경되었다. 기존 구글 폼이 가지고 있는 한계를 웹서비스로 극복한 것이다. 또한, 대쉬보드를 제작하여 이번달에 누가 개근했는지 그리고 누적 개근횟수는 몇번인지(5회 이상이면 마스터 칭호를 주기에 필요하다) 한 눈에 확인할 수 있게 되었다. 또한, 수정이 필요할시 해당 인원의 이름을 검색 DB를 바로 수정할 수 있도록 변경되었다.

덕분에, 모닝글로리는 기존의 운영상 불편함을 딛고 편안하게 운영될 수 있게 되었다.

무엇을 말하고 싶었는가?

우리의 개발과정은 매우 스무스했다. 중간에 힘든 일이 없었냐고 말하면 절대아니지만..(특히 기술적인 어려움이 많았다) 사람이 좋으면 힘든 일도 그저 추억의 일부일 뿐이다. 그리고 엎어지는 수 많은 프로젝트들과 다르게 우리 프로젝트장은 심지가 굳은 사람이었고 덕분에 끝까지 모든 사람들이 프로젝트에 참여해서 마무리할 수 있었다. 재단주도가 아닌 카뎃(42학생)들이 자발적으로 한 프로젝트가 이렇게 잘 마무리되는 경우는 없기 때문에 우리는 우리의 성공담을 통해 다른 사람들에게 여러분들도 할 수 있다는 것을 이야기해주고 싶었다.

또, 다른 카뎃들도 우리의 발표에 크게 관심을 기울였는데 그들이 원했던 내용들 또한 우리가 하고싶은 내용과 같았다. '너희는 어떻게 끝까지 해낼 수 있었냐? 중간에 힘들지는 않았느냐? 중간에 가장 고민되었던 부분은 어떤 것들이냐?' 등등, 우리는 사람들이 듣고싶어하는 이야기들을 들려주기 위해 노력했다. 각자 맡은 부분에서 했던 커뮤니케이션적인 부분과 기술적인 어려움 그리고 그것을 우리가 어떻게 극복해서 결국 해냈는지 이야기를 했다.

결국, 우리가 하고 싶었던 이야기는 '당신들도 할 수 있다' 라는 이야기였다. 개발자로 살다보면, 회사일로만 혹은 돈을 벌기 위해서만 개발하는 것은 낭비가 아닐까 싶다. 여유가 된다면 언제든, 세상에 필요한 그리고 내가 해결해보고 싶은 문제를 직접 개발로 해결해보는 것이야말로 개발자가 얻을 수 있는 가장 큰 성취가 아닐까 싶다. 나는 그리고 우리 팀원들은 우리에게 돌아오는 것은 아무 것도 없는 이 문제를 단순히 개발로 해결해보고 싶다는 생각으로 해결해냈다. 그리고 망설이고 있는 우리의 동료들에게 용기를 줄 수 있기를 바라며 이 발표를 준비했다.

발표를 마치고

발표가 끝나고 팀원들과 함께

발표에는 고맙게도 50명이 넘는 인원들이 참여해주었다. 50명이 넘는 동료들은 1시간이 넘는 우리의 발표를 처음부터 끝까지 집중해주었고, 마지막에는 우리의 발표와 관련되어서 여러 질문도 해주었다. 특히, 앞으로 우리와 같이 커뮤니티를 위한 프로젝트를 준비하고 있는 카뎃들이 제일 열정적으로 질문해주었다.

발표를 마치고, 이번 발표에 대해 우리 동료 카뎃들은 어떻게 생각할지 궁금해서 피드백을 찾아보게 되었다. 피드백들을 보니 다행히도 우리가 의도한 것들을 이루었다는 생각을 많이 했는데, 대부분 '자신들도 프로젝트를 해볼 열의가 생겼고 사이드 프로젝트라도 한번 해봐야겠다는 생각을 했다' 라는 내용이었다.

나는 이번 프로젝트를 통해 정말 많은 것들을 배웠다. 단순히 교재와 실습을 통해 배운 것보다 내가 만들고 싶은 것들을 몰입해서 만드는 경험은 나를 몇 배 더 성장시켜 주었다. 특히, 프론트 개발자로 프로젝트에 참여했지만 나중에는 인프라, CI/CD를 담당하고 있는 내 모습을 보면서 아 나는 이게 더 재미있구나! 라는 것을 알 수 있게 해주었다. 어떻게 보면 향후 내가 어떤 방향으로 나아갈지 한번 다 경험해보는 귀한 경험이었던 것 같다.

42모글 서비스는 이제 운영하기 시작된지 4개월차에 접어들었다. 조직 - 기획 - 개발 - 운영까지 모두 경험해보는 프로젝트를 경험해보는 것은 정말 귀중한 경험인 것 같다. 내가 42커뮤니티에 속해있는 동안 내가 지속적으로 관리하게 될텐데, 앞으로도 재미있는 그리고 흥미로운 아이디어를 내 소중한 프로젝트에 적용해보고 싶다.

마지막으로, 이 글을 통해 프로젝트를 잘 마무리할 수 있게 해준 백엔드, 프로젝트장 MGO, 프론트 대장 Joonhan, 백엔드 귀염둥이 Minsukan, 백엔드 마스터 Samin님에게 감사의 말씀 드린다.

이노베이션 컨퍼런스 발표 후기(42서울은 피라미드를 쌓는 곳이다)

susong — Tue, 28 Feb 2023 21:53:38 +0900

발표영상

2022.12.15.(목) 이노베이션 아카데미 성과 공유 컨퍼런스

발표 제목 42서울은 피라미드를 쌓는 곳이다(송승운)

들어가면서

2022. 12. 15.(목) 재단의 요청을 받아 이노베이션 컨퍼런스에서 발표를 하게 되었다.

발표를 하고 나서 생각했던 것들 그리고 그 뒷 이야기들을 오늘 한번 해볼까 한다.

처음 발표를 하게 된 계기는 간단했다. 발표를 통해서 내가 가지고 있는 생각과 의견을 나누는 것이 즐거운 나는 이번 이노콘도 당연히 발표 하나쯤은 해볼까? 하는 생각을 가지고 있었다.

42서울에서 사용하고 있는 커뮤니케이션 툴인 Slack에 이노콘 두달 전 연사를 구한다는 이야기가 올라왔고, 나는 이 연사 지원에 42서울에 대해서 하고싶은 말들을 주제로 신청을 했다. 그런데, 신청을 하고 연사 신청에 대한 결과가 나오기도 전에, 나는 재단으로부터 평소 연단에 자주 올라가는 사람들은 발표에 참여해달라는 연락을 받았고, 그렇게 바로 연사로서 참여가 확정되게 되었다.

처음 발표하고 싶었던 주제는 '내게 42서울이 가지는 의미'였다.

나는 42서울에 들어온지 아주 오래되었다. 나는 이 기관이 처음 창설되고 처음 뽑은 기수인 1기 1차 합격생이었고, 또 이 재단 최초의 군 휴학자였다.(내가 들어오기 전에는 군 휴학 개념이 존재하지 않았었다) 그렇기 때문에 2019년부터 2022년까지 3년이 넘어가는 기간동안 인연을 이어온 이 기관에 내가 어떤 애정을 가지는지 그리고 생각을 하는지 사람들에게 공유하고 싶었다.

그리고 '2년 4개월동안 장교로서 군 생활을 하면서 다른 기관을 준비하거나, 다른 커리어를 준비할 수 있지 않았느냐'는 주변의 질문에 발표로서 대답을 하려고 했었다. 하지만, 재단은 그 주제도 좋지만 조금만 변형을 가해서 42서울에 대한 생각을 42서울이 어떤 곳인지에 대한 카뎃의 인식을 발표해달라는 요청을 했다. 그렇게 원래 가지고 있던, '42서울이 특별한 이유'라는 제목은 지금의 제목 '42서울은 피라미드를 쌓는 곳'이라는 주제로 변경되었다.

발표의 내용

나는 42서울의 교육이 피보나치 수열이라고 생각한다.

42서울이 어떤 곳인지 누가 물어본다면 1시간 넘는 시간동안 이곳이 교육철학의 우수함에 대해서 이야기해줄 수 있다. 하지만, 발표에서 내게 주어진 시간은 5분이었고 이 시간도 딱 맞춰줘야 전체적인 컨퍼런스가 유려하게 진행될 수 있었다. 그래서, 5분 동안 어떤 이야기를 해야 사람들이 내가 애정하는 이 기관에 대해서 알아보고 싶을까에 대해서 고민하기 시작했다.

42서울은 어떤 곳인가?

오랜 고민을 통해 내가 내린 결론은 42서울은 바닥부터 만들어보는 곳이다.

철학과 학생으로 입학한 학교에서 인문소프트웨어학부 다중전공 그리고 삼성트랙(구 : SCSC)를 할 수 있었던 것은 정말 내 인생에 크나큰 행운이었다. 하지만, 이 행운들도 내게 프로그래밍적인 자신감을 주기에는 부족할 뿐이었다. 운영체제, 자료구조, 알고리즘, 데이터베이스,네트워크 등등등등 많은 컴공 학생들이 듣는 수업을 같이 들었지만 나는 자신감이 없었다.

늘 그래서 어떻게 하라는거지? 라는 의문이 함께 따라다녔고, 내가 배운 자료구조, 알고리즘들이 실제로 어떻게 쓰이는지 알 수가 없었다. 그저 하라는대로 배우고 머리 속에 집어넣고 시험을 보는 시간들의 반복이었다. 프로젝트를 해보면 안되냐고 물어볼 수 있지만, 그것도 인적네트워크가 필요하다는 것을 깨달았다. 혼자할 수 있는 프로젝트는 충분히 크지 못했고, 많이 배울 수가 없었다. 더군다나, 학교를 다니며 학비를 벌고 내 본전공까지 커버하고 있는 내게 프로젝트는 언감생신일 뿐이었다.

그렇게, 나는 실천없는 이론의 공허함을 3년동안 뼈저리게 깨달았다. 내가 배운 지식들이 실제로 어떻게 쓰이는지 모르는 그 상황은 정말 막막하고 답답함 그자체다. 처음에는 의욕이 넘쳐서 배우던 CS지식들도 필요성에 대한 의문이 커질수록 나의 공부에 대한 의지는 반비례하는 것을 실시간으로 느낄 수 있었다.

그렇게 나를 납득하지 못하는 공부를 해왔던 나는 이곳에 와서 뼈 속에 세겨진 한이 풀리는 경험을 할 수 있었다. 이곳에서는 C언어가 왜 중요하고, 그리고 C언어가 얼마나 강력한지 넘치는 과제와 예제 그리고 실습으로 알 수 있었고 이를 통해 나는 내가 배운 이론들이 실제로 어떻게 적용되는지 알 수 있었다. 그렇게 나는 내가 배운 지식들의 쓰임과 중요성을 학교를 졸업한지 3년차가 되는 2022년에 와서야 납득하게 되었다.

학창시절, '왜 이제는 잘 쓰지도 않는 C로 이렇게 수업을 할까?' 라는 바보같은 생각도 이곳에 와서 모두 깨졌다. 내가 만들어낸 그래픽 과제는 조잡할지라도 그래픽의 바닥이 C와 C++라는 것을 알 수 있게해주었고, C++ 로도 웹서버를 만들 수 있다는 것을 알게 되었다. 또! 내가 배웠던 고수준의 프로그래밍 언어들(파이썬 등)에서 내가 원시 자료형을 쓰지않아도 되는 것이 Generic프로그래밍 덕분이라는 것도 알게되었다. 또, 그 알게되는 것들도 단순히 지식을 보는 것이 아니라 막막하게 느껴졌던 <vector>나 <set>,<map>같은 gcc의 헤더를 내 방식법대로 직접! 구현하면서 완전히 익힐 수 있게되었다.

내가 배운 지식들이 실제로 살아나는 경험은 정말이지 생각이상으로 황홀하다.

나는 42에서 내 머리 속에 죽어있다고 생각한 지식들이 살아나는 경험을 했고, 42 교육 과정에 완전한 믿음을 가지게 되었다.

벽에 막혔기에만 알 수 있었던 것들

42서울 내에서 커뮤니티 활동을 하다보면 많은 42서울 카뎃들 또한 내가 생각한 이런 장점들을 알고있었지만, 어떤 분들은 이 교육과정의 필요성에 대해서 어렴풋하게만 알고 있는 사람들도 많았다. 실제로, 어떤 분들은 왜 C를 해야되는지 모르겠다고 힘들게 들어온 42서울의 문을 박차고 나가는 사람도 있었다.

그렇기에 한번은 꼭 이런 주제로 많은 사람들에게 이야기하고 싶었다.

이론은 반쪽이고, 그것을 완성하는 것은 끊임없는 연속이라는 것을 나와 같이 공부하는 동료들에게 말하고 그리고 설득하고 싶었다. '당신과 내가 하고 있는 이 교육과정은 절대 헛된 것이 아니라는 것을' 그리고 '이 과정을 통해서 당신과 나는 꼭 좋은 프로그래머가 될 수 있을 것이라고' 그렇게 말하고 싶었다.

그래서 이번 주제에 나는 42서울은 피라미드를 쌓는 곳이라는 이름을 붙였다.

언젠가 42서울에서 공부한 나와 내 동료들이 머리 속에 프로그래밍이라는 피라미드를 쌓아서, 긴 시간동안 이어나갈 수 있는 지식을 가진 프로그래머가 되기를 바라며 발표를 준비했다.

5분의 발표가 다른 카뎃들에게 어떤 의미로 와닿았을지는 잘 모르겠다. 하지만, 우리가 하고 있는 이과정에 대해서 다시한번 생각해볼 수 있다면 그것만으로도 내 발표는 큰 의미가 있을 것 같다. 그리고 지금 나처럼 내 동료들도 필요성을 느끼고 필사적으로 매진했으면 좋겠다.

곧 얼마후에는..

발표를 마치고, 언제나와 같이 발표를 다시보는 나는 발표가 마음에 들지 않았다. 하고싶은 내용들은 많은데 반해 할 수 있는 시간은 짧다보니 발생한 문제였지만, 그래도 더 많은 이야기를 다시해야겠다는 생각이 들었다.

나는 지금 42서울에 복학한지 6개월을 향해 달려가고 있다. 집중하는 시간 기준으로 매주 60~70시간은 코드를 치려고 노력하고 있는데, 이 노력을 유지할 수 있다면 곧 8개월차 즈음 42서울의 정식 멤버가 될 수 있을 것 같다.(42서울은 이너서클을 모두 통과한 인원을 멤버라고 부른다)

그렇게 멤버가 되면, 다시한번 이야기해보고 싶다. 내가 이너에서 무엇을 배웠고 그것이 내게 어떤 의미였는지를

그렇게 하기 위해서 오늘도 한줄이라도 코드를 정성껏 쳐야겠다 :)

주석 : 내가 배운 CS지식이 왜 필요한지 납득하지 못해 답답해하는 2019년의 나(문돌이 개발자 실패기)

KF-21보라매 도메인 구입기

susong — Sun, 26 Feb 2023 21:03:25 +0900

왜 구매했는가?

[단독]"현대차보다 불에 탄 포르쉐 탈 것"…선 넘은 'K방산' 견제

[아시아경제 양낙규 군사전문기자]최근 수년간 승승장구한 ‘K-방산'에 대한 글로벌 견제가 심각한 수준인 것으로 드러났다. 세계 경쟁 방산기업들이 한국 무기명과 동일한 도메인을 선점해 악

v.daum.net

시작은 아주 간단한 이유였다.

어느 기사에 우리나라 국방 무기들의 도메인들이 다른 나라에 점유되어 홍보에 어려움을 겪고 있다는 소식. 그것이 나를 도메인 구입으로 이끌었다. 웹 배포 경험이 여러번 있고, 도메인도 5개 이상 보유하고 사용하고 있는 사람의 입장에서 도메인 하나 더 구매하는 것은 큰 문제가 아니었고, ~~(애국을 위해)~~ 이번 기회에 하나 더 추가하기로 마음먹었다.

우리나라에서 지금 가장 핫한 무기는 당연 폴란드로 가고 있는 K2흑표이지만, 앞으로 가장 유망한 무기로는 KF21이 아닐까 싶다. 이번에 가장 최신으로 소개되기도 했고, 또 앞으로 더 발전할 길이 많은 무기이니 내가 타겟으로 삼는 것은 당연했다. 어떤 도메인을 살까 고민하며 KF21.com 혹은 KF-21.com을 확인했으나 짧은 알파벳 + 숫자의 특성상 이미 누군가가 가져간 이후였고, 그렇게 KF-21boramae.com을 구매하게 되었다.(KF21의 공식 풀 네임은 KF-21 boramae 이다)

구매 과정

도메인의 구매 과정은 매우 간단하다.

1. 원하는 도메인 등록 업체를 선정한다.

- 나의 경우에는 평소 AWS Route53을 통해 도메인을 관리하기 때문에 AWS로 선택했다.

2. 등록업체에 내가 희망하는 도메인이 구매 가능한지 확인한다.

- 이 과정에서 KF-21.com 등 더 짧은 도메인들은 구매 불가능 하다는 것을 확인했다.

3. 내 신상을 등록하고 결제를 진행한다.

4. 이전 방지 및 자동 갱신 등록을 진행한다.

이 간단한 과정을 마치면, 이 도메인은 앞으로 내가 결제한 기간만큼 내 소유가 된다.(현재 kf-21boramae.com은 1년 동안 내 소유지만, 자동갱신 및 이전방지가 되어있기 때문에 내가 희망하는 기간만큼 사용할 수 있다. 기간만 잘 놓치지 않고 재결제만 진행하면 된다.)

즉, 이 기간동안은 내 마음대로 할 수 있는 것이다.

이 도메인을 naver.com같은 이미 상용 서비스에 연결해둘 수도 있고, 아니면 내 개인 블로그로 연결해놓아도 된다.

나는 이 도메인을 구매했지만 당장은 쓸 일이 없고, 그렇다고 놀리기도 애매해서 일단 내 도메인에 등록해두었다.

간단한 방법 소개

글을 이렇게 마치면 너무 아쉬우니까 간단하게 어떻게 등록하는지 AWS를 통해서 소개해보고자 한다.

1. AWS에 회원가입을 진행, 자기가 앞으로 진행할 카드를 등록한다.

- 해당 부분은 안내를 따라서 진행하면 된다.

- 회원가입과 돈 내는 방법은 매우 친절하게 설명해주니 AWS의 가이드에 따라서 진행하자.

2. Route 53으로 들어간다.

- 아래 사진처럼 위의 검색을 통해서 손쉽게 들어갈 수 있다.

위 쪽을 보면 검색창이 있다. 유용하게 사용하자.

3. Route53에 들어가서 오른쪽 도메인 등록에 파란색 도메인 글씨를 클릭한다.

아래를 보면, 내가 등록한 kf-21boramae.com의 등로고가 이전잠금 로그를 볼 수 있다.

4. 왼쪽 상단의 파란색 도메인 등록 버튼을 누른다.

내가 이 계정에 가지고 있는 도메인들을 편하게 관리할 수 있다.

5. 희망하는 도메인들을 확인하고 장바구니에 추가한다.

- 이 과정에서 내가 희망하는 도메인을 잘못 입력했는지 꼭 확인이 필요하다!

- 잘못된 도메인을 결제해버리면 돌이키기 힘들 수 있다.. 괜히 돈 날리지 말고 꼭 2번 확인하자

kf-21boramae.com은 내가 구매했기 때문에 사용할 수 없다.

6. 자신의 연락처를 입력(회사라면 회사 정보를 입력) 후 계속 진행하면된다.

- 이 도메인은 나중에 TLS/SSL인증 혹은 도메인 소유자 확인을 위해 이용될 수 있으니 잘 작성하자.

- DNS 인증을 하면 되긴하지만, 가끔 TLS/SSL email 인증을 진행할 때 메일을 잘못쓰면 낭패를 볼 수 있다.

7. 이제 다 되었다! 결제까지 완료했다면, 이제 이 도메인은 완전히 당신의 것이다.

이제 당신은 이 드 넓은 인터넷 세계에 자신의 소유가 된 이름 하나를 얻게 되었다.

이 도메인을 이용해서 자신의 블로그에 연결을 할 수도있고 아니면 새로운 서비스를 만들어 볼 수도있다.

향후 이 도메인의 사용처

그러면 나는 이 도메인 kf-21boramae.com을 어떻게 쓸 예정인가?

지금은 이 도메인이 쓸 일이 잘 없지만, 나중에 우리나라 자랑스러운 KF-21이 수출궤도에 오르게 되면 홍보사이트를 한번 만들어볼까 싶다.

최근에 4번째 Next.js 프로젝트를 배포하면서 웹서비스 배포를 편안하게 할 수 있게 되었다.

배운 지식으로 사이트 만들어서 애국! 한번 해볼 생각이다.

~~하지만 내심 방산 관계자분들이 예산들여서 사가시면 더욱 행복할 것 같다.~~

크롬은 어떻게 작동하는가? 발표 회고(2022. 12.)

susong — Wed, 21 Dec 2022 16:56:20 +0900

들어가면서

발표의 부담감을 어깨를 짓눌러도 웃어야 긴장이 풀린다.

2022.11월 내 Slack에는 하나의 부탁이 찍혔다.

다름이 아니라, 42 재단에서 수요지식회를 주제로 박람회를 여는데 거기에서 발표를 부탁한다는 내용이었다.

배움의 나눔이라는 것에 충실한 나는 여러 번 42에서 발표를 진행했었고, 재단 담당자도 그런 나를 좋게 봤던 것 같다.

당연하게도 바로 승낙하려고 했는데, 내용이 조금 이상했다.

내가 철학과를 전공한 것을 바탕으로 철학을 강연해줬으면 하신단다..

그 제안은 즉시 거절, 하지만 그때 당시 프론트를 처음 접하며 궁금했던 브라우저에 대하여 발표하기로 했다. 리액트를 익히며 최적화하는 코드들에 지속적으로 관심을 가졌으나, 브라우저의 작동원리가 결여된 상태에서는 이해하기 힘든 부분이 많았기 때문이다.

그렇기 때문에 나는 브라우저에 대해서 하나도 모르면서 브라우저에 대해 발표하기로 했다.

공부를 위해 발표를 잡는다니 참으로 무모하면서도 효율적인 공부방법이다.

많은 지식과 레퍼런스

나는 아무것도 몰랐지만, 다행히도 브라우저와 관련되어서는 많은 정보들이 인터넷에 있었고 나는 여러 브라우저들 중에 크롬을 중심으로 발표를 진행해야겠다고 마음먹었다.

왜 크롬인가?

첫 번째로, 내가 크롬을 쓴다! 내가 쓰는 것에 대해 이해하는 것이라면, 내가 발표를 혹여나 안 하더라도 의미 있는 시간이 될 것이라고 믿었다.

두 번째로, 많은 사람들이 크롬을 쓴다! 즉, 내가 나중에 개발할 웹페이지들도 대부분의 사람들이 크롬으로 들어올 것이라는 뜻이다. 공부해 두면, 나중에 내가 짤 프로그램의 최적화에서 많은 이점을 얻을 수 있을 것이라고 판단했다.

마지막으로, 정보가 많다! 크롬의 핵심인 크로니움은 오픈소스기반이다. 즉 지금도 누구나 크롬의 핵심은 확인할 수 있다! 또, 오픈소스기에 많은 사람들이 관련되어 기고해주었고 나는 그 양질의 내용들을 우리 커뮤니티에 나누고자 했다. (크로니움 링크)

위의 내용들 말고도 많은 크롬 개발자들의 기고들이 발표를 위한 길을 열어주었다.

브라우저 아키텍처에 대한 이해가 결여되어있을 때, Mariko Kosaka의 Inside Look at modern web browser(part 1 ~ 4)은 내 발표의 근간을 이루어 주었고 이 외에도 크롬 개발자들이 기여한 많은 글 그리고 영상들이 내 발표의 뼈대가 되었고 그리고 과실이 되었다. 당시 참조한 레퍼런스들은 링크 참조

아무것도 모르던 처음에는 당연히 막연했지만, 여러 글을 읽으며 그리고 겹치는 개념들을 반복학습하면서 브라우저의 각 부분이 어떻게 작동하는지 이해했고, 또 왜 그렇게 제작했는지를 이해했다.

내가 기존에 알고 있던 간단한 의문들(왜 script들은 아래에 쓰는 것이 빠를까?) 등 여러 가지 의문들이 공부를 통해 해소되었고, 앞으로 코드를 작성할 때도, 브라우저의 입장을 배려할 수 있게 되었다.

후배들을 위해서, 그리고 자신의 창조물들을 설명해주기 위해서 많은 글들을 작성해준 선배 프로그래머들에게는 늘 감사하다.

발표영상

총 100명 이상이 참석해준 내 발표 영상

발표는 성공적이었다. 이전 세션 인원보다 훨씬 더 많은 인원들이 들어오느라 시간이 많이 지연되었지만, 나는 주어진 상황에서 최선을 다했다. 주어진 현실에서 늘 최고의 결과를 만들기 위해 노력하는 것, 그것이 프로그래머의 기본자세 아니겠는가?

원래 발표는 30분 진행될 예정이었으나, 예상보다 더 많은 인원들이 들어오느라 시작이 10분 이상 지연되었고, 나는 뒤 연사를 위해 마지막에는 최대한 빠르게 발표를 마무리해야만 했다.

내 발표가 15분을 넘어가던 중 앞에 박람회 기획자의 다급한 '끝내주세요' 신호가 보였고, 나는 남은 15분의 내용을 8분에 압축해야만 했다. 만족스럽진 않았지만, 그래도 어느 정도 이야기하고 싶은 내용은 다 이야기했다고 생각한다.

발표가 마치고, 많은 사람들이 내게 와서 너무 좋은 발표 잘 들었고, 고맙다는 이야기를 해줬다. 발표는 이런 간단한 감사에 감동받는 것 같다.

나는 발표하기 전에 최소 10회 이상의 리허설을 한다. 즉, 이 발표도 못해도 5시간 이상 혼자 떠드는 시간을 포함한다는 것이다. 21살 멋모르던 내가 발표에 대한 오만함을 기반으로 중기부 장, 차관님 앞에서 발표를 절어버린 기억이 있다. 나는 그때 이후로 절대로 발표에서 실수하지 않으려 강박적으로 리허설을 진행한다.

연사는 내 발표를 듣기 위해 와주는 모두의 시간보다 더 많이 준비해야 된다고 생각한다. 이번 발표는 원래 50명을 대상으로 30분 하기로 기획되었으니 나는 중간에 넘치는 열정이 아니었다면 최소인 25시간 정도 투자했을 것이다. 물론, 결과적으로 나는 내 욕심 때문에 그것보다 훨씬 더 많은 시간을 투자했지만 말이다.

그렇게 발표는 성공적으로 마무리되었고, 언제나와 같이 2번은 안 해야겠다는 마음을 가득 안고 나는 일상으로 복귀했다.

수많은 피드백들

42에서 발표하면 좋은 점은, 이곳이 동료평가를 기반으로 하는 커뮤니티이기 때문에 발표도 평가를 받는다는 점이다.

이번 발표도 예외는 없다. 내 강의를 보러 온 모든 사람은 나에 대해 평가할 수 있었고, 나는 5.0점 만점에 5.0의 점수를 받았다. 피드백 중에 인상 깊었던 내용들은 아래와 같다.

모든 내용들을 가져올 수는 없지만, 50개의 피드백 모두 좋은 내용들을 포함하고 있었다.

발표가 끝나고, 조마조마한 마음을 안고 피드백 하나하나를 살표 보았다. 또, 내가 한 발표 내용도 다시 보며 '아 저기에서 이렇게 말할걸' 혹은 '이 내용은 하지 말걸'같은 스스로에 대한 피드백도 진행했다.

발표에는 언제나 미련이 남지만, 볼 때마다 이전보다 조금 더 발전한 내 모습에 늘 감사한다.

앞으로의 계획은

이 발표를 마치고, 이번에는 이노콘(이노베이션아카데미 컨퍼런스)에서 발표를 부탁받았다.

이번에는 5분이지만, 사실 5분 발표가 30분보다 더 힘들다. 하나의 실수조차도 비중이 크고 또 하고 싶은 이야기를 농축적으로 이야기해야 되기 때문이다. 나는 42서울의 교육과정에 대해 발표할 생각이다.

42 교육과정은 매우 단단한 기초를 만들어내는 것이 특징인데, 이것을 어떤 비유와 상징 그리고 논리로 청자를 납득시킬지 고민해봐야 될 것이다.

발표할 내용을 정하고, 발표기법을 고민하고 나누는 순간은 행복하다.

앞으로도, 새로운 것이 나오면 배우고 익히고 그리고 나누는 프로그래머가 되고 싶다.

끝까지 파보는 HTTPS

susong — Mon, 5 Dec 2022 21:35:15 +0900

HTTPS 누구냐 넌!

HTTPS == HTTP + SECURE

말 그대로, HTTPS는 보안이 되는 HTTP 프로토콜이다.

(영문으로, HyperText Transfer Protocol Secured)

HTTPS가 생긴 것을 보면 기존 HTTP는 보안이 취약했는가?

맞다.

기존의 HTTP 프로토콜 예하에서 진행된 통신들은 보안 측면에서 문제가 있었기 때문에 이것을 보완하기 위해서 HTTPS 프로토콜이 만들어졌다.

그렇다면 HTTPS 프로토콜은 어떤 장점들이 있을까?

HTTPS 프로토콜이 필요한 이유 3가지

1. 개인정보를 보호받을 수 있다.

- 개인정보가 보호받을 수 없으면, 내가 서버로 보내는 내용을 누군가가 가로채서 읽을 수 있다.

- 네트워크단에서 내가 보내는 HTTP패킷을 누군가가 읽을 수 있는 위험으로부터 안전하다.

2. 무결성이 유지된다.

- 누군가가 내 패킷을 가로챌 수 없기 때문에, 내가 보내는 패킷이 변형되지 않음을 보장받는다.

- 내 Client와 서버간의 통신이 변형되지 않는다.

3. 서버를 식별할 수 있다.

- 내가 제대로 된 사람과 통신하고 있는 것인지 확인할 수 있다.

- 메시지에 포함되어있는 TLS(구 : SSL)을 통해 해당 사이트가 내가 의도한 곳이 맞음을 보장받는다.

이런 3가지 이유로 HTTPS는 선택이 아닌 필수가 되었다.

~~(HTTPS가 대중화 된 이유는 브라우저가 HTTP사이트 들어가면 경고를 보내서 그렇다)~~

그러면 이제 어떻게 HTTPS는 HTTP와 다르게 이런 장점을 가질 수 있었는지 알아보자

암호화 매커니즘 2가지

들어가기에 앞서, HTTPS가 사용하는 암호화 메커니즘 2가지를 알아보고 가자.

2 매커니즘은 각각 대칭키 암호화 그리고 비대칭키 암호화라고 불린다.

대칭키 암호화

내용을 특정한 키를 통해 암호화한다. 이렇게 암호화된 내용은 동일한 키로만 열 수 있다.

이 대칭키 암호화는 발신자와 수신자가 동일한 키를 가지고 있어야 내용을 통신할 수 있다. 이 방법은 이 특정한 키를 공유할 때 문제가 발생한다. 키를 보내는 과정은 암호화하기 힘들기 때문에, 그 과정에서 키를 탈취당하게 되면 암호화된 내용을 제삼자가 읽을 수 있기 때문이다.

비대칭키 암호화

대칭키는 키를 공유할 때 너무나도 위험하기 때문에 똑똑한 사람들은 비대칭키 암호화라는 방법을 만들어넀다.

이 방법에서 키는 2가지가 있는데 하나는 공개키(Public Key) 나머지는 개인키(Private Key)이다. 공개키는 내용을 암호화하는 것에 사용되며, 특정 공개키로 암호화된 내용은 짝이 되는 개인키로만 복호화가 가능하다.

이 중에 공개키는 공유해도 되지만, 개인키만은 공유하면 안 되는 내용이다. 비대칭키 암호화 방식은 발신자에게 공개키를 제공, 내용을 공개키로 암호화하도록 한다. 이후, 수신자는 개인키로 해당 내용을 복호화 해서 통신을 진행한다.

이렇게 되면 한 쌍의 일방향 통신밖에 안되는 것이라 너무 비효율적이지 않냐고 생각하는 사람도 있을 것이다. 조금만 기다리시라 HTTPS는 이 두 암호화 기법을 이용하여 매우 효율적인 신뢰구조를 만들어냈다.

핸드쉐이크!

이제 위에서 본 두 암호화 메커니즘을 사용하는 방법을 보여주겠다.

서버와 브라우저 간에 신뢰가 구축하는 과정을 우리는 핸드쉐이크라고 부른다. 그 과정을 한번 찬찬히 살펴 가보자

1. 웹 브라우저는 서버에게 자신이 가지고 있는 SSL 그리고 TLS 버전과 암호화 알고리즘 목록을 보낸다.

2. 서버는 브라우저가 보낸 SSL, TLS 버전과 암호화 알고리즘 중 서버의 선호에 맞는 녀석을 선택한다. 그리고 그에 맞춰 서버가 가지고 있는 공개키와 인증서(SSL 혹은 TLS)를 보낸다.

3. 웹 브라우저는 서버가 보낸 인증서가 믿을만한지 확인한다. 만약, 서버가 보낸 인증서가 믿을 수 있는 종류라면 브라우저는 PreMaster Key를 생성한 후 서버가 보낸 공개키로 이를 암호화한다.

4. 서버는 클라이언트가 보낸 PreMaster Key를 개인 키를 이용하여 복고화한다.

이렇게 함으로써! 서버와 웹 브라우저는 동일한 키를 안전하게 소유할 수 있게 되었다. 이제부터 진행되는 통신은 이 대칭키를 기반으로 암호화될 예정이다! 이렇게 함으로써, 서버와 브라우저 간 쌍방향 소통을 편안하게 실시할 수 있게 된다.

SSL? TLS?

위의 과정은 정말 신기하지 않은가?

비대칭 방식을 이용하여 대칭키 암호화 방식을 가능하게 하는 HTTPS 프로토콜 방식은 정말 명석한 방법이라고 생각된다.

그런데, 계속 나오는 저 SSL 혹은 TLS은 도대체 뭐하는 녀석들일까?

SSL TLS 둘 다 보안을 위해 태어난 프로토콜이며 꼭 HTTPS이 아닌 다른 프로토콜에서도 사용할 수 있는 녀석들이다. 이렇게만 말하면 이 녀석들이 왜 생겨났는지 잘 이해할 수 없으니까, 이 둘을 태어난 순으로 한번 살펴보자

SSL의 시작

SSL이 세상에 공개된 것은 1995년 2.0 버전부터이다. 1.0은 만들어졌으나 보안적인 문제 때문에 세상에 공개되지 않고 업데이트되어버렸다. 이 SSL들은 넷스케이프 1.1 브라우저에 탑재되면서 세상에 알려졌는데, 이 인증서는 해당 존재가 믿을만한지를 알기 위해서 제작되었다.

인증서의 3가지 종류

인증서는 총 3가지 종류로 이루어져 있는데, 각각은 보장하는 범주에서만 차이를 보인다.

첫 번째 인증서는 도메인만 확인하는 인증서이다. 이 인증서는 해당 도메인을 소유하고 있는 존재가 맞는지만 확인한다.

두 번째 인증서는 도메인을 확인한 후 실제로 해당 사이트를 운영하는 조직이 있는지 확인한다.

마지막 인증서는 앞의 인증서가 한 인증을 진행한 후 해당 사업의 비즈니스까지 확인하는 인증서이다.

이 인증서를 가지고 있고, 보내는 사이트는 제대로 된 녀석이라는 것을 따로 말하지 않아도 인증받을 수 있다.

그러면 TLS는 무엇인가?

TLS는 SSL의 새로운 이름이다. SSL을 만들어낸 넷 스케이프는 3.0 버전을 마지막으로 ITEF로 SSL 프로토콜 제어권을 남겼는데, 제어권을 넘겨받은 ITEF는 SSL의 이름을 TLS로 변경했다. 이렇게 이름을 변경했지만, 모든 사람의 기억에서 바꿀 수는 없는 법. 아직도 SSL이라고 기억하는 사람들이 많아 현재까지도 TLS와 SSL는 같이 사용되고 있다.

TLS의 역사

TLS는 1999년 발표된 이후, 2006년 1.1 버전 그리고 2008년에 1.2 버전이 배포되었다. 하지만, 2013년이 되어서야 브라우저들이 1.2 버전을 적용하기 시작했고, 현재는 2018년에 발표된 1.3 버전이 최신 버전으로 사용되고 있다.

TLS는 위에서도 밝혔듯, 꼭 HTTPS 프로토콜뿐만 아니라 FTP, SMTP와 같은 다른 프로토콜에서도 적용할 수 있다.

Thank You HTTPS

HTTPS가 있기에 내 블로그를 들어오기 위해 입력한 링크가 다른 곳으로 가지 않았음을 보장받을 수 있다.

또, 내가 비밀스럽게 나누고 싶은 이야기들도 가능한 한 보장받으며 나눌 수 있게 되었다.

Thank You!

브라우저는 어떻게 작동하는가? (주소창에 엔터를 누르면 생기는 일)

susong — Mon, 5 Dec 2022 20:40:52 +0900

1 단계 : 우리가 브라우저 주소창 내용을 입력하면 어떻게 될까?

브라우저는 내용에 따라 다른 모습을 보여준다.

웹 브라우저는 당신이 원하는 것이 무엇인지 알고 있다.

웹 브라우저는 사용자가 주소 표시줄에 입력한 내용이 URL인지 검색어인지 확인하여 그게 알맞은 인터페이스를 보여준다. 검색어일 경우에는 바로 설정된 검색 엔진으로 검색하는 기능을, 그리고 사이트인 경우에는 해당 사이트로 넘어갈 수 있도록 조치해준다.

이 과정에서, 브라우저는 미리 준비된 DNS 혹은 서버와 통신함으로써 해당 내용이 URL인지 확인해낸다.

(주소창에 입력 된 내용을 준비된 서버로 보내 내용이 URL인지 검색어인지 확인)

2단계 : 사이트의 진짜 주소를 알아낸다.

페이지의 모든 데이터들은 서버에서 오고, 그 서버는 IP주소로 되어있다.

하지만, 18.67.51.57 이런식으로 구성되어있는 IP주소는 인간 친화적이지 않고 외우기가 너무 어렵다. 오른쪽에 있는 사진은 내가 최근에 완료한 프로젝트 42mogle.com에 패킷을 날리는 명령어를 찍은 것이다.

분명히 나는 42mogle.com에 ping을 날렸지만, 돌아오는 대답은 18.67.51.57로부터 온다.

즉, 42mogle.com은 가명이고 진짜 이름은 저 아이피인 것이다! (~~놀랍지 않은가?~~)

가명을 쓰면 무엇이 좋을까?

우리가 Google.com을 외우는 것이 쉬울까? 아니면 172.217.161.46를 외우는 것이 쉬울까?

아주 간단한 문제이다. 사용자가 외우기 쉽게 하기 위해서 만들어진 것이다.

그렇다면, 이 사이트 주소들은 어디에 저장되어있는가? 이들은 DNS(Domain Name Server)이라는 곳에 저장되어있다.

이 서버 안에서 각각의 사이트들은 자신의 진짜 주소인 IP주소와 매칭되어있다. (Google.com : 172.217.161.46)

그렇기 때문에, 웹 브라우저는 해당 사이트로 접근하기 전에, DNS에 접근하여 그 사이트의 진짜 주소 알아낼 수 있다.

그리고 이렇게 알아낸 주소는 우리가 해당 사이트에 접근하는 것에 사용된다.

3단계 : 사이트와의 연결을 구축한다(HTTPS)

그렇게 도착한 주소는 과연 안전할까? 해당 아이피까지 가는 길에 나의 패킷은 중간에 강도당하지 않았을까? HTTP로 연결하면 보안을 위한 절차가 생략되어있기 때문에 내 패킷이 제대로 된 곳으로 도착했는지 알 수 없다.

그렇기 때문에, 현재 대부분의 사이트들은 HTTPS라는 프로토콜을 이용, 사이트 - 클라이언트 간 소통을 안전하게 만들어준다.

그렇다면 이 HTTPS는 어떤 것들이 특별할까?

1. HTTPS를 이용하면 개인정보 보호가 가능하다. 즉, 내가 서버로 보내는 내용을 남이 가로채서 읽을 수 없다.

2. 무결성이 보장된다! 내가 서버로 보내는 내용을 가로챌 수 없기 때문에 내가 보낸 내용과 서버가 받는 내용이 동일함을 보장한다.

3. 식별이 가능하다. TLS(옛 이름 : SSL)을 통해 내가 받은 데이터가 내가 생각하는 곳에서 왔음을 보장한다.

이렇게 좋은 것이 있다면, 당연히 해야겠지만 과연 이 장점들은 어떻게 만들어지는 것일까?

그것은 해당 글에서 계속

이렇게 핸드쉐이크 등등 여러 방법을 통해 얻어낸 신뢰는 이 브라우저 탐색의 다음단계로 이어진다.

4단계 : 사이트에서 보낸 응답을 확인한다.

해당 파일이 html이라고 주장하고 있다!

사이트의 진짜 주소도 알았고, 그 녀석과 안전한 통신망도 구축했다.

이제는 그 서버에게 내가 원하는 것을 요구할 차례이다.

내 클라이언트에서 출발한 패킷은 높은 확률로 서버의 80(HTTP) 혹은 443(HTTPS)포트로 향할 것이고 그 포트를 통해 자극받은 서버는 정해진 규칙에 따라 데이터를 클라이언트에게 보내줄 것이다.

이렇게 서버가 내용을 보내주면 클라이언트는 그 내용이 진짜 어떤 내용인지 확인한다.

일반적으로 그쪽에서 보내준 데이터에는 자신이 어떤 데이터라고 표시되어있지만, 브라우저는 이를 확인하기는 하지만 완전히 믿지는 않는다.(정보가 없거나, 잘못된 정보가 있을 가능성을 대비하기 위하여)

그렇게 브라우저는 아래에 있는 내용을 조금 살펴본다.

안에 있는 내용이 렌더링 엔진이 처리할 수 있는 내용이라고 판명되면(HTML,CSS 등) 해당 내용을 렌더러 프로세스에게 전달한다. 하지만, 해당 내용이 PDF이거나 ZIP과 같은 파일일 경우 해당 파일 내용에 맞는 방식을 취한다. PDF일 경우 문서를 바로 표시하고, ZIP일 경우에는 다운로드 매니저를 실행시킨다.

또한, 브라우저는 이 과정에서 CORB 기능도 작동한다 (당신이 자주 보던 CORS의 Cross-Origin Read가 맞다!)

5단계 : 그릴 준비를 완료한다.

인터페이스 프로세스는 우리가 주소창에 엔터를 누르는 순간부터 미리 렌더러 프로세스를 준비시켜놓는다.

분명 사이트를 옮길 것이지만, 네트워크 통신은 (상대적으로) 긴 시간을 요구하기 때문에, 미리미리 렌더러 프로세스를 준비시켜놓음으로써 그 응답이 도착하는 대로 상태에따라 바로 그릴 수 있도록 준비하는 것이다. 이렇게 미리 렌더러 프로세스를 준비해놓지 않으면, 데이터를 받고도 렌더러 프로세스가 준비되기를 기다려야되기 때문에 웹브라우저를 만든 프로그래머들은 미리미리 해놓는 효율적인 최적화를 진행시켜두었다.

마침내, 이렇게 확인이 완료된 데이터는 미리 준비하고 있던 렌더러 프로세스에게 넘겨진다.(이 과정은 IPC를 통해 이루어진다. 둘 다 프로세스니까!)

이 과정에서, 주소 표시줄에 있는 내용도 업데이트가 된다.

보안표시가 업데이트되며(HTTPS면 잠금 표시 아니면 깨진 잠금!) 사이트 주소도 변경된다. 또한, 뒤로가기 버튼이 활성화되며 이전 사이트의 정보를 담고 있으며 해당 세션이 닫히더라도 나중에 다시 킬 수 있도록 세션 기록도 드라이브에 저장된다.

이런 과정을 거치면 드디어 웹브라우저는 렌더러 프로세스를 이용, 화면에 내용을 그리기 시작한다.

드디어 웹 브라우저가 화면을 그리는 내용이 이어진다.

다음 글에서 계속

브라우저는 어떻게 작동하는가? (브라우저의 프로세스)

susong — Mon, 5 Dec 2022 18:06:34 +0900

모든 프로그램은 프로세스를 가지고 있다

프로세스는 여러가지를 담고있는 식판같은 친구다(메모리 코드 등)

모든 프로그램은 프로세스를 가지고 있다.

Linux를 깔면 당연하게 나오는 CLI의 Shell 조차도 프로세스다.

그렇다면, 웹 브라우저도 프로그램이니 프로세스를 가지고 있을텐데 이 녀석의 아키텍처는 어떻게 될까?

하나의 프로그램이니까 하나의 프로세스만 가지고 있을까? 혹은 두개?

사실 브라우저가 몇 개의 프로세스를 사용하는지는 알 수가 없다.

왜냐하면, 이것은 브라우저마다 작성하기 나름이기 때문이다.

하나의 표준으로 만들어진 아키텍처는 없고, 각각의 브러우저들은 각기 다른 아키텍처를 가지고 있다.

어떤 웹 브라우저는 스레드를 많이 사용하는 프로세스 조금으로 만들어져있기도 하고, 어떤 녀석은 스레드를 조금 만들고 프로세스를 많이 만들어 IPC로 통신하며 작동하기도 한다. 브라우저마다 구현하는 방법의 차이이기 때문에 어떤 녀석이 이렇다!라고 할 수는 없다.

하지만, 그렇게만 넘어가면 아쉽기 때문에, 이 글에서는 크롬을 기준으로 설명하려한다.

크롬의 아키텍처를 살펴보기 전에 브라우저의 구성요소부터 살펴보자

브라우저의 구성요소

출처 : d2.naver.com/helloworld/59361

브라우저는 총 7가지로 구성되어있다.

오른쪽 사진에 보이는 그 7가지가 모두 모여 상호작용하면서 우리가 아는 이 브라우저의 역할을 해내는데, 그 역할을 하나하나 나열하면 아래와 같다.

1. 사용자 인터페이스 : 이 블로그로 들어올 수 있게 하는 주소 표시줄 그리고 이전 사이트로 돌아갈 수 있는 이전 / 다음 메뉴, 북마크 등등 요청한 사이트를 보여주는 곳을 제외한 기능할 하는 구성요소이다.

2. 브라우저 엔진 : 브라우저 엔진은 사용자 인터페이스와 렌더링 엔징 사이에서 중재자 역할을 한다. 사용자 인터페이스에서 들어온 명령(예 : 새로고침)을 이해하고 렌더링 엔진에게 명령하는 존재이다.

3. 렌더링 엔진 : 렌더링 엔진은 HTML CSS JS를 읽고 그 결과물을 토대로 사용자가 보는 페이지를 그려내는 역할을 한다. 크롬의 경우 원래는 Safari의 Webkit를 이용했었고 현재는 Webkit을 기반으로 제작한 Blink를 이용한다. 구체적으로 렌더링 엔진의 작동방법은 이후에 따로 설명할 예정이다.

4. 통신 : 통신 레이어는 HTTP, HTTPS 프로토콜을 통해 리소스를 가지고 올 때 사용된다.

5. 자바스크립트 해석기 : 페이지에 작성된 JS를 해석하고 실행하는 역할을 한다. 크롬의 경우 V8이 탑재되어있다.

6. UI 백엔드 : 브라우저가 작동하고 있는 운영체제의 인터페이스를 따르는 UI를 처리하는 역할을 한다.

7. 자료 저장소 : 쿠키, 세션과 같이 로컬에 저장이 필요한 자원들을 하드 디스크에 저장하는 역할을 한다.

브라우저의 프로세스들

출처 : developer.chrome.com/blog/inside-browser-part1/

위의 구조를 바탕으로 브라우저는 크게 4개의 프로세스로 구성되게 된다.

1. 브라우저 프로세스 : 사용자 인터페이스, 통신, 자료 저장소 등이 하는 역할을 진행한다. 사용자가 읽고싶어서 들어간 페이지를 제외한 다른 부분에 대한 역할을 전반적으로 진행하는데, 그 내용으로는 주소 표시줄, 앞 그리고 뒤로 가기 등등 우리가 사용하는 브라우저 위쪽에서 제공하는 기능들을 포함한다.

2. 렌더러 프로세스 : 브라우저의 탭 내부에 표시되는 부분에 대해서 제어한다. 크롬은 각각의 탭마다 프로세스를 둠으로써 하나의 탭이 고장났을 때 다른 탭들이 기능을 멈추는 것을 방지했다.

3. 플로그인 프로세스 : 웹 사이트에서 사용하는 플러그인들을 제어한다.(캡쳐 플러그인,OneTab 등등)

4. GPU프로세스 : GPU 작업을 다른 프로세스와 격리해서 처리한다. 여러 탭에 있는 렌더러들이 GPU를 통해 렌더링을 부탁하기 때문에 별도 프로세스로 분리되어 있다. 우리가 '하드웨어 가속'이라고 부르는 것은 이렇게 CPU가 아닌 자원 예컨데(GPU)를 이용하여 프로그램 성능을 높이는 방법이고, GPU 프로세스는 이런 것들을 위해 존재한다.

크롬은 하나지만, 프로세스는 여러개다

프로그래밍 과제를 하다보면 Fork하며 여러 프로세스로 만드는 경우도 있지만, 대부분은 단일 프로세스로 처리되는 일들이 많다.(특히 C언어와 같은 절차형 프로그램들은 더더욱!) 그렇다보니 크롬도 당연히 하나의 프로세스로 구성되어 있을 것이라고 생각했지만, 오히려 수많은 프로세스로 구성되어있다는 것에 충격을 받았다.

크롬은 탭마다 프로세스를 만든다는 것을 보며 웹브라우저가 여러 프로세스라고 해봤자 한 두개만 만들고 안에서 다중 쓰레드로 돌릴 것이라고 생각했던 내 예상이 크게 어긋났음을 알았다. 우리에게 대중적으로 서비스되는 프로그램들이 얼마나 깊은 고민을 한 결과물임을 알 수 있는 대목이다.

다음글(브라우저에 엔터를 누르면 일어나는 일)에서 계속

브라우저는 어떻게 작동하는가?

susong — Mon, 5 Dec 2022 17:14:37 +0900

들어가면서

현대인들이 가장 많이 사용하는 프로그램은 무엇일까?

단순히 프로그램이라고 하면, 사용하는 휴대전화의 OS를 가장 많이 사용하겠지만, 응용단에서 가장 많이 쓰는 프로그램은 아마도 브라우저 일 것이다.

하지만, 웹 브라우저가 어떻게 돌아가는지 아는 사람은 몇 명이나 있을까?

나는 최근에 프론트로서 프로젝트에 참여하면서 이 신기하고 오묘한 웹브라우저라는 친구에게 꽂혀버렸다.

내가 만든 아주 바보 같은 코드들도 철석같이 알아듣고 내가 원하는 대로 그려주는 이 친구에게 개인적으로 호감이 생겼고, 이런 호감은 이 녀석이 어떻게 작동하는지 알아봐야겠다는 생각으로 이어졌다.

그런 마음을 바탕으로, 나는 웹 브라우저에 대해 잘 알지도 못했지만 수요지식회에 "브라우저는 어떻게 작동하는가?"라는 주제로 발표를 잡아버렸고, 오늘 발표를 위해 준비한 내용들을 글로 작성해보려 한다.

자료 준비 과정

자료는 대부분 인터넷을 통해서 얻었다.

~~인터넷을 작동시키는 녀석이니까 인터넷에서 자료를 얻는게 맞을 것이다~~

대부분 Chrome Developers와 web.dev 등 크롬 개발자들이 남겨놓은 좋은 글들을 바탕으로 학습하였고, https 그리고 DNS과 같은 개념들은 해당 서비스를 제공하는 업체들(CloudFlare 등)에서 설명해놓은 친절한 글들을 바탕으로 학습하였다.

최대한 믿을 수 있는 사람의 글들을 골랐고, 이를 바탕으로 대략적으로 브라우저의 구조에 대해 이해하는 것이 가능했다.

글의 신뢰성을 높이기 위해 뒤에 이어질 내용들의 출처를 미리 작성하려 한다.

레퍼런스

Chrome Developer “Inside look at modern web browser (part 1 ~ 4)”

HTML Living Standard

HTML : https://html.spec.whatwg.org/
Parsing : https://html.spec.whatwg.org/multipage/parsing.html
Overview of parsing model : https://html.spec.whatwg.org/multipage/parsing.html#overview-of-the-parsing-model

Chromium

Basic CSS : https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css
Process Model : https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md

How browsers work

https://web.dev/howbrowserswork/

HTTPS

https://howhttps.works/ko/

So how does browser actually rendser a website (JSConf EU 2015)

https://youtu.be/SmE4OwHztCc

Critical Rendering Path

https://web.dev/critical-rendering-path/

How browsers work (JSConf 2017)

https://youtu.be/0IsQqJ7pwhw

Rendering on the Web

https://web.dev/rendering-on-the-web/

How DNS work (CloudFlare)

https://www.cloudflare.com/ko-kr/learning/dns/what-is-dns/

Behind the Browser

https://dzone.com/articles/behind-browser-basicspart-1

브라우저는 어떻게 동작하는가?

https://d2.naver.com/helloworld/59361

웹 브라우저의 동작원리를 알아보자

https://velog.io/@thyoondev

자 그럼 즐거운 웹브라우저 작동원리로 들어가 보자 (브라우저의 프로세스)

개발을 해보니 알 수 있는 아쉬움(모닝글로리 웹페이지 제작 4)

susong — Tue, 29 Nov 2022 19:42:30 +0900

시도하기 전에는 당신이 무엇을 할 수 있는지 결코 알 수 없다. - 윌리엄 코베트

해보지 않으면 알 수가 없다

나의 첫 리액트 프로젝트, 시작하기 전에는 느낄 수 없었던 것들이 프로젝트가 어느정도 궤도에 오르니 보이기 시작했다.

백문이 불여일견이고 백견이 불여일행이라

역시 한번 해보는 것만큼 좋은 경험과 배움은 없는 것 같다.

이번에 배웠던 것들을 다음번에는 잘 써먹을 수 있게 하기위해서 기럭을 남겨본다.

늘 협업을 중점에 두자

스스로 위대해질 수 있는 사람은 없다.

프로그래밍을 할 때 협업이 가장 중요한 이유는 프로그램은 혼자 만들 수 없기 때문이다.

간단한 쉘을 만들거나 예제 프로그램을 만드는 것은 혼자서 할 수 있을지 몰라도 이렇게 누군가에게 제공해야되는 서비스를 제작할 때 혼자하는 것은 거의 불가능하다.

프론트 팀은 그래도 어느정도 협업에 대해 신경을 쓰고 코딩을 했다고 생각했지만, 나중에 보니 사실 그렇지 못했다.

우리는 CamalCase 그리고 컴포넌트/페이지로 구분해서 관리하는 방법을 정하고 이 방법대로 코딩했지만, 이는 충분하지 않았다.

우선, Components에 우리가 만든 모든 jsx파일을 밀어 넣음으로써 이 컴포넌트들은 어디에서나 쓸 수 있는 인상을 주었다.

이렇게 함으로써 컴포넌트 간의 의존성을 정확하게 인지시킬 수 없었고, 제작된 컴포넌트들의 이름은 충분히 명확하지 않았다.

만약 바로 옆에서 코드를 친 동료에게 물을 수 없는 상황이라면 읽는 이에게 혼란을 주기에 충분한 네이밍 및 관리방식이었다.

우리는 개발을 함에 있어서 LiveShare 방식을 취했기 때문에 즉각적인 소통이 가능해 실수하지 않을 수 있었지만 앞으로 모든 코딩을 LiveShare로 할 수 없지 않은가?

나와 우리팀원 주한님은 둘 다 리액트 초보였고, 그렇기 때문에 하나하나 물어가며 공부하는 과정을 이어나갈 수 있었다.

비슷한 수준의 팀원과 하나하나 지식을 쌓아나간다는 것은 매우 큰 행운이라고 생각한다. 만약 나보다 못하는 사람이거나 나보다 잘하는 사람이라면 '이거 물어봐도 괜찮을까?'라는 생각으로 코딩할 수 없었을지도 모른다.

우리는 비슷한 수준이었기 때문에 서로에게 묻는 비용이 적었고, 덕분에 리액트 시작부터 공부 - 4개 페이지 개발까지 1주일 안에 끝낼 수 있었다.

과연 이번같은 행운이 또 있을 수 있을까? 나는 그럴 수 없다고 확신한다.(~~이런식으로 다 할 수 있었다면 github가 왜 있겠는가?~~)

코드는 어떻 작성해야되는가?

코딩 규약의 중요성

다음번에는 이번처럼 LiveShare로 같이 코딩하는 행운이 없을 것이라고 생각해야겠다.

이번에 할 때는 학습과 병행했기에 너무나도 좋은 방법이었지만 생산성은 그렇게까지 높지 않았다.

이번에는 우리가 하나하나 배우면서 서비스를 만들어나갔기에 그런 것일 수도 있지만 과연 월급주는 회사에서도 이런 상황을 받아들여줄까? 내가 사장이어도 이런 방식으로 협업하는 개발자는 환영하지 않을 것 같다.

GitHub 그리고 PeerReview

우리의 코드는 깊고 한눈에 안보인다..

왜 선배 개발자들이 주니어는 돈을 좇기보다는 PR을 잘해주는 회사로 가라고 조언해주는지 정확하게 알았다.

PeerReview, 해보니까 너무나도 어렵다. 다른이의 코드를 읽고 이해하는 것은 내 코드 치는 것만큼의 노력을 내게 요구했다.

왜 우리의 PR은 어려웠을까 생각해보면, 네이밍에 있어서 내공이 부족했다. 그리고 리액트의 depth을 다룸에 있어서도 부족한 내공이 우리의 리뷰들을 방해했다.

우리가 사용한 변수들은 2번 생각해야 어떻게 사용하는 것인지 알 수 있었고, 가끔 작성한 리액트 코드들의 depth는 너무 깊어 한눈에 이게 어떤 내용인지 알아보기 쉽지 않았다.

왜 변수 네이밍 그리고 한눈에 보이는 코드가 중요한 것인지 알 수 있었던 대목이다.

누군가가 알아보지 못하는 코드는 1주일 후의 나도 알아보지 못한다.

알아보지 못하면 관리할 수 없다. 그런 코드는 좋은 코드가 아니다.

다음에는 이렇게 해보자!

1차적으로 릴리즈 후 멘토 소플님께 멘토링을 받으면서 받았던 조언을 바탕으로 나는 많은 것들을 깨달았다.

1. 컴포넌트들은 폴더별로 분리하여 컴포넌트의 의존성을 명확하게 명시하자

- Table 내부에 쓰는 Component는 Table에서만 쓸 수 있도록 구분해서 보관하자

2. 중요한 내용들은 .env에 보관하여 관리하자

- 이번에는 zustand상태에 다 밀어넣어놨었다

3. 공백을 잘 활용하자

- 90년대 컴퓨터가 아니다! 이제는 동료가 잘 볼 수 있도록 코딩하자

- 중요한 것은 공백, 빈줄 줄이기가 아닌 동료가 잘 알아볼 수 있는 코드다

4. Import를 할 때에도 잘보이게 하자!

- 비슷한 출처를 가진녀석들을 모아서 import하자

- 컴포넌트 사이즈가 큰 것부터 순서대로 import하자

5. function 하나를 쓰더라도 어떻게 작성할 것인지 정해놓자

- 작은 것도 하나하나 정해서 규칙에 맞게 작성하자

6. 디자인 패턴은 다 이유가 있어서 세상에 나온 것이다

- 아토믹 디자인 패턴을 익히고 잘 써먹자

7. API관리들도 하나로 모아서 해주자(예: APIManager)

8. Bool Type을 가리는 함수는 isGood 처럼 is를 붙여서 작성해주자

이 외에도 수많은 조언들을 해주셨지만, 다 담기에는 내용이 많아 이정도만 추려본다.

우리끼리 코딩을 하면서는 어렴풋하게 이게 중요한건가? 싶었던 부분들을 왜? 와 함께 짚어주시니 '아 저게 필요한 것이었구나!' 라면서 바로바로 이해할 수 있었다.

직접 코딩해보며 어렴풋하게 느꼈던 필요성들과 멘토님의 친절한 설명이 함께하며 앞으로 내가 어디로 가야되는지 파악한 순간이었다.

저녁 10시가 넘어서까지도 멘토링해주신 소플 멘토님 감사합니다.

어떻게 배포할 것인가?(모닝글로리 웹서비스 제작 3)

susong — Tue, 29 Nov 2022 16:00:47 +0900

안녕 AWS

작은 서비스를 배포하기 위해서 가장 좋은 방법은 무엇일까?

작은 서버를 사서, 처음부터 올리는 것도 좋은 공부가 되겠지만, 많이 배울 수는 있어도 나중에 써먹기는 힘들다.

프로그래밍의 분야가 세분화되고 있는 지금 그렇게까지 리눅스를 파서 공부할 필요가 있을까? 오히려 클라우드를 경험해보는 것이 더 좋지 않을까? 물론 아키텍처쪽으로 지망하면 처음부터 올려보는 것이 좋겠지만, 나는 웹 백 혹은 프론트할 생각이고 다른 팀원들도 아키텍처는 관심이 없다.

고맙게도, 42서울은 훌륭한 보상제도(발표 혹은 봉사시 주는 달러)를 가지고 있고, 그 보상제도 안에는 AWS 크레딧이 존재한다.

GCP, Azure 등등 거의 모든 클라우드 플랫폼의 크레딧을 구매할 수 있지만, 우리는 접근성 및 학습을 이유로 AWS을 사용하기로 마음을 먹었다.

우리는 42서울이라는 뒷배를 잘 이용하여 100만원짜리 크레딧을 얻었고, AWS 구축에 열을 올렸다.

어떻게 구축할 것인가?

여러 고민 끝에 처음으로 구상한 방법

우리의 고객들(Client)의 수는 어떻게 되는가?

우리의 고객은 매일 이용하며, 오전 9시에 50 ~ 150회의 접속이 이루어지고, 오후에는 간혈적으로 접속이 이루어질 것이라고 생각된다.

동시 접속자는 최대 50명 이내일 예정이다.

DNS서비스는 어떻게 정할 것인가?

감비아와 같이 DNS 대행 업체들이 존재하지만, 우리가 사용하고 있는 AWS에서도 제공해준다.

더욱이 가지고 있는 크레딧을 DNS에 사용할 수 있기에 우리는 Route53을 선택했다.

(가격은 조금 더 비싸다, 다른 곳은 3년에 2만원 선이지만 이곳에서는 12개월에 12~15달러선)

인스턴스 IP는 어떻게 할 것인가?

AWS에서 제공하는 Elastic IP로 설정하여 DNS와 연결할 것이다. 인스턴스 IP는 종료후 재 시동할 때마다 변경되기 때문

어떤 OS를 사용할 것인가?

42서울 인원들은 모두 Born2BeRoot라는 프로젝트를 통해 VM에 데비안을 올려본 경험들이 있다.(소수는 레드햇OS)

AWS에서 제공하는 OS중에 Ubuntu는 내가 실제로 2017년 한 해동안 사용해본 경험이 있고, 데비안 유저들도 쉽게 사용할 수 있을거란 판단이 들었다. 그래서 아키텍처 담당으로서 전체 구성원들의 사용편의성을 위해 Ubuntu로 결정했다. (~~맥OS가 있어서 잠깐 혹했다~~)

어떤 데이터베이스를 사용할 것인가?

우리는 ERD를 경험해보고 공부도 할 요량으로 Postgresql을 골랐다.

서버는 몇 개를 쓸 것인가?

서버는 처음에는 EC2 2개를 이용하려고 했다. 왜냐하면 일반적인 프로덕션 레벨에서 프론트 서버와 백엔드 서버가 구성되어있기 때문이다.

로드밸런서를 이용, Route53에 들어오는 요청을 적절하게 분배해줌으로써 기능을 하려고 했다. 하지만 결국 EC2 1개를 사용했다.

그렇다면 왜 2개로 하지않았는가?

첫번째로는 비용의 문제가 있었다. AWS의 철학 OnDemand에 따라 2개를 쓰면 비용도 2배로 는다. 게다가 이 새로운 계정은 프리티어도 적용되어있어서 EC2 1개를 쓰면 비용도 나오지 않는다. 프로젝트에서 예산을 아낄 수 있다면 아끼는 것이 좋겠다고 생각해서 1개 쓰는 방법을 고민했다.

두번째로는 네트워크 비용에 대한 고민이 있었다. 42서울 과정을 밟다보면 IO과정 그리고 네트워크의 비용이 얼마나 큰지 느낄 수 있다. 이 곳에서 사용하는 C언어들은 워낙 빠르기 때문에 OS단에서 이루어지는 느린 일들(Page Fault, I/O, Network 통신) 등등에 대해 매우 민감하게 반응하도록 사람이 바뀐다. 그래서 서버가 2개면, 둘 간의 통신하는 비용이 발생할 것이라고 생각하여 그것을 없애기 위해 하나의 서버에서 해볼까라는 고민을 했다.~~(멘토링 후에는 기업들이 괜히 2개로 하는 것이 아니라는걸 알았다)~~

왜 상용서비스를 이용하지 않았는가?

AWS에서 제공하는 RDS 혹은 S3 아니면 Vercel과 같은 방식으로 구축하면 더 쉬웠을 수 있는데, 이 방법을 취한 이유는 학습때문이었다.상용서비스를 이용하더라도 그것이 실제로는 어떻게 돌아가는지 직접 이해하고 싶었고, 그렇기 때문에 하나하나 올려보는 과정을 거쳐봤다.실제로 올려보니 패키지 의존성 및 포트와 라우팅 문제등 하나하나 핸들링 하기 정말 힘들었지만, 그래도 어찌 돌아는 갔다.

향후 어떻게 할 것인가?

엎어버리고 상용 서비스 사용할 예정이다.(S3 + Route53 + EC2 + RDS)

실패록

너무많은 실수들이 있었다.

나는 2016~2017년 학교에서 진행한 프로젝트들 그리고 해커톤에 나갈 때마다 사용해본 AWS경험들이 있었지만, 또 다시 하려니 쉬운일은 아니었다. 매번 할 떄마다 '이걸 왜 실수하지?!' 라고 외치지만 또 하고 있는 내 모습은 내가 봐도 신기하다.

첫 실수 "아 리전 잘못 정했다"

AWS에는 2가지 중요한 영역이 있다.

리전(Region)과 가용역역(AZ)이 그것인데 이 둘은 내 서버가 위치할 공간을 의미한다.

하나의 리전에는 여러 물리 서버들이 존재하는데, 이 것들을 지정함으로써 내 서버의 위치를 지정할 수 있다.

내가 서울 리전을 지정하면 내 서버는 목동에 있을 수도 일산에 있을 수도 있지만, 하여튼간에 일단 서울 주변에 있다.

그래서 리전이 틀리면 뭐가 안좋은데?

첫째로, 가장 중요하게도 네트워크 응답속도가 느리다!

내가 만들 서비스의 주 사용자들은 개포동 42학생들인데, 이 사람들이 클릭할 때마다 도쿄리전을 찍고오게할 수 없지않은가?

서비스를 쓸 때마다 굳이 가까운 슈퍼마켓 두고 먼 슈퍼마켓으로 보내는 격이다(실제로 파는 것은 동일한데도 불구하고!!)

그렇기 때문에 이건 당장 바꿀 수 밖에 없는 실수였다.

게다가, 서울 리전을 써야 서울 리전에서 다른 서비스들을 이용할 수 있는데, 만약 도쿄로 하면 그 동네에서 다른 서비스들도 다 써야되기 때문에 향후에도 꾸준히 문제를 야기할 것이다. 왜냐하면, 서버는 서울에 두고 도쿄에 데이터베이스를 두면 쿼리 날릴 때마다 얼마나 코스트가 크겠는가? 서버를 서울에 열어야 나중에 다른 것들 붙일 때도 서울에서 만들 수 있다.

옛날에는 분명 리전 옮기려면 온갖 오류가 다 나서 그냥 처음부터 올려버렸던 것 같은데

불행 중 다행히도 이미지로 구워서 다시 서울 리전에서 인스턴스 생성함으로써 해결했다.

두번째 실수 "Nginx가 왜 API 요청을 안하지..?"

리액트를 "npm run build" 한 후 Nginx 위에 올려두었더니 이 충실한 웨이터는 내가 잘 만들어둔 프론트 컴포넌트들을 고객님들께 서빙해줬다. 근데 문제가.. 이 친구는 프론트 컴포넌트만 서빙을 해주는 외골수라는 것이다.

Nginx가 POST를 안해요..

42서울 과제 중에 Nginx만드는 과제가 있어 기본적인 개념을 이해하고 있어서 나는 당연히 될줄 알았다. 하지만, 모든 것이 잘 되어가면 꼭 의심해보라는 선조들의 말씀답게 이 Nginx는 백엔드 API를 이악물고 무시했다. Nginx는 80(HTTP), 443(HTTPS) 포트만 듣고 3000으로 들어가는건 백엔드로 가라고 해놨더니 문 가장 앞에서 다 자기가 먹고있다. API로 가야되는 요청들을 Nginx가 가로챈다음 '이게 뭔지 모르겠으니 안함~'혹은 '이건가? 리액트 받아라!!'하고 있으니 복창터지는건 어쩔 수 없었다.

결국 conf 파일들어가서 온갖것들을 하나하나 수정함으로써 수정을 해냈지만, 장기적으로는 관리가 불가능할 것이라고 판단.

아예 아키텍처 전반을 엎어버리는 것으로 결론냈다.

자잘한 실수들

자잘한 실수들은 너무 많아서 셀 수도 없다.

처음에는 사실 VPC와 로드밸런서도 써보고 싶어서 온갖것들을 다 만져봤지만, 결국 나의 기술부채 문서만 추가할 뿐이었고

초창기 네트워크 포트 설정을 서버에서만 하고 AWS 방화벽은 안건드려서 반나절 고민한 적도 있었다.

SSL 설정은 인증서도 다 받았는데, EC2님 입맛에 안맞으셨는지 하도 뱉으셔서 결국 CertBot으로 선회해서 적용했다.

너무많은 실수들이 있었지만, 너무나도 고통스러운 기억이기에 머리 속에 깊이 남았다.

앞으로 어떻게 할 것인가?

- 돌아가는 것에 대해서 잘 배우자!

- Nginx만드는 Webserver 잘 만들어보자

- 네트워크 정확하게 이해하자

- 패키지 매니징 및 코드 관리 신경쓰자

- 상용 서비스 잘 이용하자

아직 배포못한 서비스는 S3 + EC2 + Route53 혹은 Vercel로 보내야겠다

구해줘 카뎃 대표를 맡으며

susong — Thu, 17 Nov 2022 16:18:23 +0900

구해줘 카뎃이란?

구해줘 카뎃(SaveCadet)이란 42 서울 구성원을 구하는 모임이다

(42 교육생을 카뎃이라고 부름)

원래 코로나 시절 집에서 원격공부를 하는 카뎃들이 공부에 집중을 못해서 그런 사람들을 구하기 위해 만든 동아리이다.

동아리 룰은 오전 10시 그리고 오후 5시 반에 Gather 42 서울 플랫폼에서 서로 오전에는 무엇을 할지 이야기하고, 저녁에는 오늘 무엇을 했는지 그리고 오늘 공부한 내용을 발표하는 건설적인 룰을 가지고 있다.

나는 8월 군복학 후 어느곳이라도 소속되고 싶다는 마음으로 홍보물을 보고 가입하게 되었다.

어쩌다가 대표를 맡게 되었는가?

내가 본 구해줘 카뎃은 매우 포텐셜이 높은 동아리였다. 하지만, 동아리의 생명은 점점 꺼져가는 상태였다.

내가 들어간 8월에도 인원은 적은편이었으나 9월 그리고 10월을 거치면서 동아리의 불씨는 거의 사라지기 직전의 상황이 되었다.

20명 정도였던 구성원은 10명을 거쳐 한자리수로 줄어들었고, 참여하는 인원이 적으니 진행이 힘들어지는 악순환이 반복되었다.

구해줘 카뎃에는 운영진이라는 개념이 따로 없었고, 동아리에 애정을 많이 가지고 계신 gyeon님을 중심으로 인원 유지만 하는 상황이었다.

나는 내가 처음 적을 둔 이 동아리가 진심으로 망하지 않았으면 좋겠다고 생각했고, 동아리의 혁신 혹은 부활을 위해 전체인원 소집을 제안했다.

다행히도, 아직 동아리에 애정이 많았던 구성원들은 대부분 모여주셨고 나는 그자리에서 이 동아리를 한번 살려보고 싶다는 포부와 함께 어떻게 해나가자는 이야기를 했다.

내가 생각한 동아리의 문제점

구해줘 카뎃은 코로나 시국에 만들어진 동아리다보니, 온라인을 기반으로 진행되었다.

하지만, 오프라인이 제한되던 시기가 지난 지금 온라인이 줄 수 없는 소속감은 이제 동아리의 존속을 위협하기 시작했다.

소속감 혹은 동료라는 인식을 줄 수 없는 동아리는 인기가 시들했고, 사람들의 기억에서 잊히기 시작했다.

내가 생각한 정확한 문제점들은 이런 것들이 있었다.

1. 소속감 혹은 동료라는 인식을 주지 못하는 현 체제

2. 소수의 희생으로 진행되는 시스템

3. 적은 인센티브(42 내 자체 화폐 및 업적 등)

나는 이런 요소들을 바꿔야된다고 생각했고 아래와 같은 혁신안을 제안했다.

1.a. 5클러스터에 모여앉음으로써 동료학습 강화

1.b. 매주 목요일 점심 티타임 및 저녁 식사 자리 제안

1.c. '무엇을 구하는 것인가'에 대한 동아리의 철학 확립(현 체제는 관리해줘 카뎃에 가까움)

2. 머슴(출석관리자)가 없이 작동하는 동아리, 사람이 아닌 시스템에 의해 돌아가는 동아리

3. 더 많은 인센티브(교육팀 담당자 설득)

그 결과 나는 동아리 구성원들의 동의를 얻어 구카 대표로서 역할을 부여받았다.

어떤 것들을 바꿀 것인가?

대표가 되어서 구성원들의 마음을 얻기 위해서는 이 사람이 믿을 수 있다는 것을 보여줘야 된다.

나는 앞으로 내 행보에 원동력을 얻기에 가장 좋은 3번 인센티브를 공략했다.

기존의 구카 인센티브는 아래와 같았다.

1. 전체 출석 시 : 10 월렛

2. 머슴 : 1주일 1 월렛

3. 출석 개근자 : 2 월렛

나는 이 정도로는 충분한 동기를 부여받을 수 없다고 생각했고, 담당자 폴라베어님과 면담을 신청했다.

약 30분 정도 내가 생각하는 구카의 혁신방안을 PPT20장에 발표했고 그 내용은 아래와 같았다.

구해줘 카뎃 혁신 안이라는 제목을 가진 PPT는 아래 내용을 포함하고 있었다.

1. 구카는 42 서울 교육철학과 맞닿아있는 동아리임 (필요성 역설)

- 동료학습 강화

- 42의 3 무(교재, 교수, 학비)로 인해 어려움을 겪는 인원 구제

2. 현재의 인센티브로 인해 겪고 있는 문제점들 (현 상황)

- 타 동아리에 비해 적은 인센티브

- 구성원들에게 더 높은 요건을 요구하기 위해서는 더 큰 인센티브 필요

3. 앞으로 어떻게 개선해 나갈 것인지? (향후 계획)

- 오프라인 활동 강화

- 구해줘 카뎃에 이름에 맞게 동료를 구제하는 활동 신설

- 모두의 요람이 될 수 있는 동아리로 변혁

- 지속 가능한 동아리 시스템 확립

4. 지원해줬으면 하는 부분 (협조 내역)

- 인센티브(월렛 강화)

그 결과 30분 정도 들은 담당자님은 매우 만족스러워하시며 내가 요청한 것 그 이상으로 지원을 약속하셨다.

할 일이 너무 많다.

있는 조직을 고치는 것은 조직을 처음부터 올리는 것보다 배는 힘들다.

왜냐하면, 원래 있던 구성원들의 이해관계를 잘 풀어내가는 과정이 필요하기 때문이다.

우리 구카에는 기존에 lms를 개발하던 개발팀이 별도로 존재한다.

문제는 운영팀이 없기 때문에 구카가 필요한 방향이 아닌 개발팀이 원하는 방향으로만 개발이 되고 있었다.

현 시스템은 spring으로 개발되고 있었는데, 나는 이 기술 스택도 우리가 공부하는 내용과 맞닿아야 된다고 생각했다.

현재 진행하는 방식인 spring은 취업이나 공부 요점에서는 충분히 좋은 방법이지만! 우리의 42 서울 최종 과제가 nest.js로 진행되기 때문에 관리 입장에서 인원 모집이 매우 어려운 구조였다.

나는 개발팀을 직접 만나 설득했고, 그 결과 기술 스택도 변화시키는 것에 동의를 받았다.

구카_회의 (1).pdf

0.21MB

조직을 바꾸기 위해서는 바꾸기로 원하는 사람이 큰 그림을 계속 그려줘야 된다.

나는 구해줘 카뎃이라는 의미 확대, 오프라인, 지속 가능한 구조이 3요소를 가지고 구성원들을 설득했고,

모든 구성원들은 감사하게도 내 입장을 이해해줬다.

오늘까지 나는 개발팀을 포함한 구성원 모두를 설득했다.

한 명 한 명 내가 가진 포부를 이해해줬고, 앞으로의 길을 응원해줬다.

몇몇 분들은 감사하게도 운영진을 자처해주시기도 했다.

앞으로의 계획

변화를 위한 초석은 모두 닦았다.

이제 앞으로만 나아가면 된다.

내가 생각하는 우리 동아리의 미래는 모든 42 사람들의 요람이다.

배의 방향을 바꿔서 나아가는 것은 힘든 일이지만 내가 이곳에 있는 동안만큼은 이 동아리가 소속된 모두에게 이익이 될 수 있도록 최선을 다하고 싶다.

대표로서 해야되는 가장 중요한 일은 구성원들이 내 생각을 언제나 알 수 있는 것이다.

어떻게 개발할 것인가?(모닝글로리 웹서비스 제작2)

susong — Thu, 17 Nov 2022 13:52:57 +0900

첫 회의 이후

우리 팀은 고뇌를 거쳐 어떻게 API를 만들 것인지 설계했다.

우리는 제작자이면서도 가장 열성적인 사용자가 될 것이기에, 어떻게 제작해야 인원 확인(페이지의 목적)을 잘 처리할 수 있을지 고민했고, FIGMA에 오른쪽 사진처럼 열심히 구현하려 노력했다.

모두 좋은 계획에 좋은 제품이 나온다고 믿었기에, 계획을 짜는 과정은 매우 순조로웠다. 주 3회 이상 총 7회의 회의를 진행했고 운영진의 입장과 사용자의 입장에서 가장 효율적이고 인지하기 쉬운 디자인을 짜냈다.

아직 완벽하지는 않지만, 사용하면서 더욱 더 잘 해낼 수 있을 것이라 믿으며 우리 팀은 UI/UX에 대한 논의를 마쳤고, 이제는 어떻게 짤 것인가에 대한 고민으로 넘어갔다.

어떻게 구현할 것인가?

목표는 이제 정해졌다.

그렇다면 백엔드/프론트엔드 각각 팀들은 각각 목표를 위해 어떻게 달려 나갈 것인가?

백엔드에는 JAVA의 Spring 혹은 express 아니면 js에 있는 다양한 백엔드 프레임워크, 혹은 파이선의 장고 등등 여러 가지 선택지 중에 어디로 갈지에 대한 고민이 시작되었고,

프론트는 TypeScript에는 이견이 없었지만, 바닐라로 할 것인지 아니면 Vue 혹은 React에 대한 고민이 이어졌다.

고민의 과정에서 백엔드는 Nest.js를 사용하는 것으로 그리고 프론트는 React를 사용하는 것으로 결정되었다.

DBMS는 Postgresql로 결정되었다.

왜 이것들로 결정했는가?

프레임워크 혹은 라이브러리를 결정함에 있어서 우리에게 가장 중요한 요소는 '학습의 지속성'이었다.

앞으로 커리어를 이쪽으로 나갈 사람들로서 이번에 배운 것이 향후 우리에게 어떤 영향을 줄 수 있을 것인가?

혹은 이번에 배운 것을 다른 방향으로 이어나갈 수 있을 것인가?

이 간단한 질문을 기반으로 도구를 정하니 쉽게 정할 수 있었다.

모두가 42서울이라는 하나의 공동체에서 Inner라는 학습코스를 밟고 있기에 우리의 마지막 과제인 트센(온라인에 핑퐁게임 배포하기)에 사용할 수 있는 도구를 원했고, 또 공부한 내용으로 다른 것들을 만들기 쉬워야 했다.

우리가 만드는 사이트는 정적인 기반이기에, 프론트 담당으로서 Vue를 선택하는 것이 더 좋은 선택지일 수 있지만 더많은 레퍼런스와 커뮤니티가 있는 React가 첫 프론트 라이브러리로는 적합할 것이라고 생각했고, 동료 분도 존중해주셨다.

DB는 RDMBS에 대한 학습 차원 및 우리의 데이터가 유저를 기반으로 Relation을 가진다는 점에 착안해서 Postgres로 결정되었다.

실제로 나는 대학교 수업 때 해당 DBMS를 이용해본 경험도 있어서, 더욱 편안하게 할 수 있을 것 같다.

앞으로 무엇을 하는가?

생각하는 DB구조를 설명하는중

앞으로 우리는 각자 영역에서 충분한 학습을 하고 개발을 진행할 것이다.

개발에 필요한 룰들은 모두 충분한 회의를 통해 정립되었고, 이제 공부만 할 차례다.

정해진 룰들

- Git commit은 어떻게 할 것인가?

- 소스 관리는 어떻게 할 것인가?

- 배포 및 배포 일정은 어떻게 할 것인가?

나 또한, React에 대한 내용을 충분히 학습해서 바로 개발할 수 있을 정도로 수준을 높일 예정이고, 또 나는 AWS아키텍처를 담당하게 되어서 그 부분에 대해서도 고민하고 있다.

AWS를 여러 번 다루어봤지만, EC2 및 IP정도만 다루어보고 다른 툴들은 사용해보지 않아서, 많은 공부를 해야 될 것 같다.

100명 내외의 인원에게 제공되는 서비스인 만큼 스케일링에 유의하며 개발해보려 한다.

우리의 배포 일정은 12.1 우리에게는 시간이 많이 남지 않았다.

수 많은 회의 중 하나 상단에 "오늘의 목표"인 오목이 작성되어있다.

다음 글에서 계속

JSX란 무엇인가? (React 기초)

susong — Thu, 17 Nov 2022 09:17:09 +0900

JSX 변종인가!?

const element = <h1>Hello, world!</h1>;

위의 코드를 보면 무슨 생각이 드는가?

오른쪽만 보면 평범한 HTML코드이다.

그런데, 언제부터 HTML을 변수에 집어넣을 수 있었지?!

나와 같은 의문을 품었다면, 당신도 나와같은 동류다.

~~(??? : 도대체 왜 마크업 언어를 변수에 집어넣는거야!!)~~

이렇게 의문을 품었더라도, 이 글을 다 읽을 때 쯤 아 그래도 JSX가 뭔지 알겠다 싶을 수 있도록 아래 열심히 설명해보겠다.

그래서 JSX가 뭐냐

JSX == JavaScript + XML

말 그대로, JSX는 JavaScript에 XML을 얹은 친구이다.

XML이 무엇인지 궁금한 분들은 이 링크를 한번 읽고오면 좋다.

그렇다면, 이 친구는 어떤 특징 그리고 장단점을 가지고 있을까?

특징

1. React 쓸 때 꼭 사용해야되는 것은 아니지만..! 쓰면 엄청 편해서 매우 권장됨

2. JSX는 XML규칙을 따른다.

3. JSX를 통해서 우리는 React element를 만들 수 있다.

4. Expression을 쓸 때는 JS처럼 {}으로 묶으면되며, 큰 블록을 넣을 때에는 ( )으로 묶어주면 된다.

5. 컴파일 된 후, JSX Expression은 일반적인 JS 함수처럼 사용된다.

6. 이름 지을 때에는 camelcase로 작성해야된다.(helloWorld from simSimHamStudy blog)

- 맨 앞글자를 소문자로 그리고 뒤에 붙는 단어의 맨 앞글자는 대문자로 표시한다!

장점

1. 앞에 작성한 것처럼 React 사용할 때 매우매우 편해진다

2. HTML 태그들을 쉽게 React element로 변환할 수 있다.

3. 그냥 JS보다 빠르다!(정말?!)

4. DOM에 appendChild() 혹은 createElement()를 쓰지 않고도 넣을 수 있다.

5. JSX expression 안에서 제어문들(if, for 등등)을 사용할 수 있다.

6. XSS(cross-site-scripting)공격을 막아준다!!(XSS란? 링크)

7. type-safe하기 때문에 대부분의 오류들은 컴파일할 때 잡을 수 있다!

단점

1. HTML이 정확하지 않으면 에러를 뱉는다.(태그 잘 닫아주고 element로 잘 감싸줘야된다)

장점은 많고, 단점은 적은(사실 이건 버그 줄일 수 있어서 단점인가 싶지만) JSX 어떻게 쓰는지도 한번 알아보자

간단한 JSX 실습

const name = 'Josh Perez';
const element = <h1>Hello, {name}</h1>;

짜잔, 우리는 jsx파일에서 이 간단한 2줄로 이름을 바꾸며 element를 만들어낸 간단한 JS객체를 만들어봤다.

React에는 Component와 Element라는 두 친구가 존재하는데, 이 친구들은 붕어빵틀과 붕어빵 이 친구들의 관계와 같다.

Component는 이 Element를 찍어내는 틀인 것이다.

(React는 이 컴포넌트에서 계속 다른 친구들을 찍어냄으로써 브라우저 내용을 바꾼다)

여기에서는 "Hello, {특정 이름}" 의 Element를 찍어내는 것을 볼 수 있다.

또, JSX안에서는 자식을 둘 수도 있다.(div 안에 h1 혹은 h2같은 태그)

const element = (
  <div> //div시작
    <h1>Hello!</h1> //div의 자식들
    <h2>Good to see you here.</h2> //div의 자식들
  </div> //div 끝!
);

JSX는 매우매우 간단하게 이런 element를 만드는 틀을 우리에게 제공해줍니다.

한발자국 더 나아간 실습

function formatName(user) {
  return user.firstName + ' ' + user.lastName;
}

const user = {
  firstName: 'Harper',
  lastName: 'Perez'
};

const element = (
  <h1>
    Hello, {formatName(user)}!  </h1>
);

이런식으로 작성하면, 우리는 JS를 통해서 마크업 언어를 그리고 React element를 효과적으로 변경할 수 있습니다.

이 element 친구는

1. user의 데이터를 formatName함수로 변환시키고

2. 그 변환된 이름(여기에서는 Harper Perez)를 Hello, {이름 위치}에 넣고

3. 그 후 Hello, Harper Perez라는 React element로 만들어 DOM에 넣어줍니다.

이것저것 많이 보긴했지만, 잘 모르시겠다고요?

그렇다면 아직 DOM, Component, Element 등등 React 갈길이 멀어서 그렇습니다.

[헷갈리는 당신을 위한 JSX 한 줄 요약]

React element를 편하게 만들 수 있게 도와주는 JS + XML 툴

(필수는 아니나, 쓰면 매우 편안하다)

React 개발환경 구성(Create React App, React기초)

susong — Wed, 16 Nov 2022 16:46:38 +0900

들어가며

모든 프로그래밍 언어를 배울 때 가장 귀찮은 것은 바로 개발환경 구성이다.

하지만, 그 귀찮음도 React에서는 예외일 것이다.

아주 간단하게 React를 키는 과정을 한번 살펴보겠다.

설치과정은 npm 설치(node.js 설치) -> Create React App 설치 -> 개발환경 구성 순으로 진행하겠다.

1. Node.js 설치

가장 먼저 Node.js에 들어가서 Node.js를 설치하자 Node.js 설치링크

Node.js에는 npm이라는 패키지 관리자가 포함되어 있는데,

우리는 npm을 사용하기 위해 그것을 포함하고 있는 node.js를 설치할 예정이다.

왼쪽의 LTS를 설치하자

설치를 할 때에는 LTS설치를 권장한다.

LTS란, Long Term Support를 의미하는데 즉, 이 버젼을 설치하면 장기간에 걸쳐 지원하도록 고안된 소프트웨어 버젼이다.

또한, 최신의 버전보다 안정화되어 에러나 버그가 적으니 완전 최신의 버전에 포함된 신기술이 필요한 것이 아니라면 되도록 LTS를 설치하자.

2. Create-react-app 설치

npm이 설치되었다면, CLI를 한번 켜보자(windows는 cmd, Mac은 iTerm, Linux는 이걸 쓸 정도면 CLI는 알 것이다)

그곳에 아래와 같이 작성하면된다.

npx create-react-app <당신이 생각하는 프로젝트 이름>
// 사용법

npx create-react-app myBlog
// myBlog라는 리액트 앱 만드는 명령

npx는 execute npm package binaries라는 뜻으로 해당 패키지를 설치한 후 바로 실행시키라는 뜻이다.

이렇게 하면 당신의 파일시스템에 리액트 실행을 위한 모든 개발환경이 구성되었다.

cd <당신의 프로젝트 이름>
npm start

당신이 아까 작성한 프로젝트로 들어가서 (나의 경우에는 myBlog)

npm start를 입력해보자

이제 당신이 리액트를 공부하기위한 모든 준비는 끝났다.

REACT란 무엇인가?(REACT 기초)

susong — Wed, 16 Nov 2022 16:31:34 +0900

들어가며

무엇을 공부하거나 알아볼 때 가장 중요한 것은 자신이 배우는 것에 대한 개괄적인 그림을 그리고 들어가는 것이다.

React는 뭐라고 정의할 수 있을까? 라이브러리? 인터페이스를 위한 도구?

둘 다 맞는 말이지만 정확하게 표현하면 아래와 같다.

사용자 인터페이스를 구축하기 위한 선언적이고 효율적이며 유연한 JavaScript 라이브러리
- 리액트 Tutorial 중

처음 컴퓨터를 공부하는 사람들을 위해서 조금 풀어서 해석하면 아래와 같다.

사용자 인터페이스 (UI, UserInterface 즉, 당신이 보고 있는 이 웹브라우저 환경)을 구축하기 위한

선언적이고 (React는 어떻게가 아니라 무엇을 정의하는 프로그래밍이다)

효율적이고 유연한 JS 라이브러리이다! (그걸 위해 미리 만들어 놓은 JS에서 쓰는 레고블럭들이다!)

라이브러리 : 단순 활용 가능한 도구들의 집합(레고 블록)
프레임워크 : 뼈대와 기반구조를 가지고 있는 기술, 프레임워크는 라이브러리를 포함한다

리액트의 특징

리액트는 3가지 특징을 가지고 있는데 각각을 이렇게 부른다.

선언형, 컴포넌트 기반, 재사용성

출처 : https://ko.reactjs.org/tutorial/tutorial.html

이제 이 친구들을 하나하나 간단하게 찍어먹어 보자

선언형 프로그래밍

선언형 프로그래밍이 있으면 다른 프로그래밍도 있는가? 있다! 명령형 프로그램이 이 선언형과 비교 가능한 개념이다.

그렇다면, 이 둘이 어떻게 차이점이 있기에 React 친구를 선언형으로 만들었는가?

선언형 vs 명령형

선언형은 내가 무엇을 할 것인가를 기술하고

명령형 프로그램은 내가 어떤 일을 어떻게 할 것인지를 기술한다.

물론 이렇게만 말하면 잘 이해가 가지 않을 수 있다. 그래서 한번 예를 들어보자

[음식점에 가서 자리에 앉아야 되는 상황]
선언형 인간 : 저희 일행(6명) 자리 주세요
명령형 인간 : 저기 주방 앞에 자리 빈 것 같은데 저희 저기로 걸어가서 테이블에 앉을게요;

느낌이 조금 오는가?

선언형 방식은 내가 지금 원하는 것이 무엇인지만 관심이 있다. 여기에서는 일행이 앉을자리가 필요하다고 외치고 있다.

반면에, 명령형은 내가 어떻게 앉을 것인지에 집중한다. 그러다 보니 그 과정(절차)에 집중한다.

C나 C++, JAVA에 익숙한 사람이라면 늘 절차적으로 프로그래밍을 하게 된다.

그런 사람들은 당연하게 하나의 의문이 생기는데, '아니 저렇게 "주세요!"만 하면 그 안의 과정은 도대체 어떻게 처리하라고!'라는 의문이 생길 수 있다.

당연한 의문이다. 왜냐하면 컴퓨터는 '알아서 해주는 것'이 없으니까

이 물음에 대해 나는 선언적 방식의 기저에는 명령형 방식으로 작성된 How가 기술되어있기 때문이다.라고 대답하겠다.

'자리 주세요'라는 것은 매우 추상화되어있는 물음일 뿐이다.

그 예하에는 '내가 저기를 보고', '저 자리 쪽으로 걸어갈 것이며', '너는 지금 빈자리를 확인해서 내게 알려주고' 등등과 같은 문제 해결을 위한 절차가 다 포함되어 있다.

즉, 선언적 접근방식 아래에는 명령적 추상화가 존재한다.

이미 다 구성되어있기에 우리는 원하는 것만 말하면 되는 것이다.

선언형 프로그래밍 예시

function double (arr) {
  let results = []
  for (let i = 0; i < arr.length; i++){
    results.push(arr[i] * 42)
  }
  return results
}
// 절차형 프로그래밍

function double (arr) {
  return arr.map((item) => item * 42)
}
// 명령형 프로그래밍

내가 다니고 있는 42를 기념하여, 모든 수에 42를 곱한다고 생각해보자

이때 C와 같은 절차형 프로그래밍을 한 사람들은 대부분 위와 같이 함수를 선언할 것이다.

하지만, 선언형은 아래처럼 짧게 작성할 수 있다.

저 코드에서도 볼 수 있듯, 위의 배열 선언 그리고 for문 모두가 이미 map을 통해서 구현되어있다고 생각한다.

프로그래머는 그냥 원하는 것만 말하면 원하는 것을 쟁취해낼 수 있는 것이다.

그렇다면 왜 이렇게 선언적으로 쓰는 것일까?

누군가에게는 컴퓨터의 작동을 모델로 삼아서 절차를 따라가는 것이 익숙할 텐데, 선언형 프로그래밍을 하는 이유는 매우 간단하다.

이 방법은 프로그램을 기계를 중심으로 하는 것이 아닌 개발자의 두뇌를 중심으로 개발할 수 있게 하기 때문이다.

물론 이렇게까지 당신이 이해하려 하지 않아도 당신은 선언형을 이미 쓰고 있다(아마도)

정규표현식이 바로 이 선언형 프로그램이다

(안에서 어떻게 돌아가는지는 모르지만, 내가 원하는 바를 표현식에 맞게 쓰면 알아서 처리해주는 착한 친구)

컴포넌트란 무엇인가?

컴포넌트는 리액트에서 만든 앱을 이루는 최소한의 단위를 이야기한다.

젠가가 잘 작동하기 위해서는(게임을 하기 위해서는) 젠가의 블록들을 하나하나 쌓아서 하나의 탑을 만들어내야 된다. 똑같이 리액트에서도 하나의 앱 혹은 페이지를 만들기 위해서는 이 컴포넌트들을 쌓아 올려야 한다.

젠가의 블록들처럼 이 컴포넌트들은 다른 젠가 탑에서도 재사용이 가능하다.

또, 이 젠가 친구들은 props라는 입력을 통해서 각각 다른 색깔 들고 가질 수 있는데, 더 깊은 내용은 다른 페이지에서 깊이 있게 다루겠다.

재사용성이란 무엇인가?

리액트의 컴포넌트는 젠가의 블록 같다고 이야기했다.

이 젠가의 블록들은 아주 작은 단위로도 만들 수 있고, 또 6개 9개 단위로 작은 탑을 만들어볼 수도 있다.

이렇게 젠가를 쪼개고 모으고 집합을 만들면서, 우리는 계속 다양한 곳에서 쓸 수 있다.

이름 목록을 만드는 과정을 한번 살펴보자

이름 목록 : 이름 + 사진 + 아바타 + 기본정보

이런 식으로 하나의 컴포넌트들을 다른 이미 만들어진 컴포넌트들로 묶어서 만들 수 있다.

즉, 컴포넌트 한번 잘 만들면 같은 필요가 있는 곳에서 쭉 다시 쓸 수 있다는 것이다.

왜 REACT를 공부하는가?

The Most Popular Front-end Frameworks in 2022

위의 이유 때문에, 리액트는 5년 연속 가장 각광받는 Front-end 라이브러리가 되었다.

많이 쓰인다는 것은 에러Case에 대한 결과도 많고, 또 지속적으로 관리된다는 뜻이다.

또, 리액트는 Meta(구 페이스북)이라는 든든한 지원군도 있다.

즉, 지금도 유지관리가 좋은데 앞으로도 어느 정도 이 정도의 관리유지가 보장된다는 뜻이다.

혹자는 남들이 다 쓰니까 나는 안 쓸래!라고 말할 수 있다. 나는 그럴 수 있다 생각한다.

하지만, 그런 사람은 프로그래밍하면서 가장 중요한 구글이라는 도구 사용에 제한적이고 수많은 에러를 혼자 헤쳐나가는 역경은 스스로 감내해야 될 것이다.

많이 쓰는 것에는 다 이유가 있다.

내가 생각하는 라이브러리 사용 요건 1순위이다.