그 틈을 치고 트위터를 대체하겠다는 소셜 플랫폼이 치고 올라오고 있다. 대부분이 탈중앙화Decentralization 페디버스Fediverse를 외치고 있는데 뭐 자세한건 모르겠고. 벌써 개발된지 몇 년 된 Mastodon, 그리고 트위터에서 파생 프로젝트로 시작되었다는 Bluesky를 써 봤다.

tl;dr - 둘 다 전성기의 트위터를 따라잡기에는 부족하다. 기능 면에서도 그렇고 사용자 면에서도 그렇고.

일단 Mastodon. ActivityPub 프로토콜을 기반으로 사용하고 있다. 하루만에 3천만명 사용자를 모았다는 Meta Threads도 조만간 ActivityPub을 지원하여 페디버스와 연합을 지원할 거라고 하는데, 언제 할 지는 모르겠다. 가입자 끌어모으는데 도움되는 건 아니니까 아마 느긋하게 할 거다.

여튼 Mastodon은 독립된 서버 개설이 상대적으로 쉬운 탓에(그리고 이걸 장려하고 있고), 트위터마냥 거대하게 운영되는 서버는 손으로 꼽을 정도고 대부분이 개인이 운영하는 영세 서버이다. 여기에서 문제가 발생하는데, 내가 쓰고 있는 서버가 언제든 샷다 내리고 망할지도 모른다는 불안감을 가지고 서비스를 이용해야 한다. 오픈 플랫폼이니만큼 데이터 백업해서 타 서버로 이주할 수 있다고는 하지만, 아직까지 그런 이주가 잘 된 사례를 본 적은 없다. 사업자가 안정되게 운영하는 서버는 가입이 막혀있기 일쑤고.

그럼 내가 직접 서버를 운영하면 되는거 아닌가? 그래서 나도 직접 서버를 파서 운영하고 있다. 오라클 클라우드의 무료 서비스를 최대한 활용하면, 스토리지 비용으로 한달 3.00 SGD, 약 3천원 미만 금액만 지불하면 운영 가능할 것으로 보인다. 다만 이건 서버 운영 관련 지식이 좀 있어야 가능하고, 적은 돈이더라도 서버 비용이 지출되는 것도 사실이다. 도메인 비용도 1년에 몇 만원 정도 별도로 나가고.

ActivityPub은 W3C에 의해 표준화되어 있고, 복수 플랫폼이 이 프로토콜을 지원하여 서로 소통할 수 있게 되어 있다. Mastodon 외에도 Misskey가 존재하며, Misskey를 이용한 서버 또한 손쉽게 개설이 가능하다. 위에서 기술한 것처럼 Meta Threads도 조만간(언제가 될 지는 모르지만) ActivityPub을 지원할 예정이라고 한다. 이렇게 서로 다른 서비스지만 표준에 의해 상호 소통할 수 있기 때문에, 서로 다른 서버 사이에서도 의사소통이 가능하다. 물론 서버마다 기능이 다르고 정책이 다르기 때문에 완전 통합은 안 되지만, 여하튼 이렇게 여러 서버가 연계할 수 있다는 점은 매력이다. 참고로 이렇게 여러 서버가 느슨하게 연계한 소셜 네트워크를 연합 우주(Fediverse - Federation + Universe)라고 부른다.

Mastodon / Misskey는 내가 팔로우하는 유저들의 툿/노트만을 모아두는 타임라인, 각 서버 내에서의 공개 타임라인, 그리고 연합 우주의 공개 타임라인이 별도로 존재하며 이 부분을 이해하는데 조금 시간이 걸릴 수 있다.

다음으로 Bluesky. 블록체인 기반의 AT 프로토콜을 바탕으로 하고 있다. 트위터의 사내 프로젝트에서 시작해서 아예 회사 차리고 새로 나갔다고 한다. 여하튼 프로토콜이 다른 탓에 ActivityPub 기반의 Mastodon이나 Misskey 서버와는 통신할 수 없다. 이 부분은 감점요소라고 해야 하겠다. 과연 얼마나 호환성 넘치게 생태계를 구축할 수 있을지 의문이다. 내가 아는 한 현재로서는 서버 구현체가 Bluesky PDS뿐이 없다. 그래서 내가 쓴 포스트 데이터가 어디에 저장되는지? 블록체인이라고는 하지만 구현체가 Bluesky 뿐이니 결국은 Bluesky 서버에 저장된다고 볼 수밖에 없다. 이거 참... 이래서야 트위터 버전2밖에 안 되잖아.

Bluesky의 인터페이스와 기능은 트위터와 매우 흡사하며, 서버/글로벌 타임라인은 존재하지 않고 대신 내가 원하는 컨텐츠를 구독할 수 있는 Feed 기능이 존재한다. 이를테면 트위터의 추천 탭과 유사한 기능인데, 트위터와 달리 Feed는 아무나 서버를 생성해서 공급이 가능하다. 즉슨 추천 탭의 컨텐츠 공급 알고리즘을 내 마음대로 선택할 수 있다는 것이다. 트위터가 이거로 욕을 좀 많이 먹긴 했지... 다만 아직까지 마음에 쏙 드는 Feed는 발견하지 못했다. 서비스 초창기라서 그러려나.

Bluesky의 핸들 네임은 기본값으로 [username].bsky.social 을 쓸 수 있고, 소유중인 도메인으로 변경할 수도 있다. 일장일단이 있겠지만 일단은 도메인 소유권만 확실하다면 핸들네임을 탈취당할 염려는 없다는 점은 좋다고 봐야겠다. 대신 설정이 좀 불편하다. DNS TXT 필드를 특정 값으로 설정해 줘야 하는데, 이게 무슨 소리인지 모르겠다면 스스로 설정하기에는 좀 많이 어려운 상태라고 보면 된다.

Bluesky의 최대 단점은 바로 아직 베타 서비스 중이라는 점이다. 아무나 가입할 수 없고 기존 가입자의 초대장을 받아야만 가입할 수 있다. 락인 효과가 있는(=사용자 수가 깡패인) SNS의 특성상, 우수수 떨어져 나오는 트위터 유저를 빠르게 흡수해야 하는데, 초대장이 너무 큰 장벽이다. 이사갈 데를 찾는 주변 트위터 유저들은 초대장이 없어서 Bluesky 계정을 못 만들고, 정작 Bluesky 내에서는 사용자가 없어서 타임라인이 심심한 상황이다.

다행히 일요일 라이브는 오후 4시에 시작하니 8시에는 끝날 것으로 예상되고, 신칸센으로 신오사카에서 도쿄(시나가와)까지는 약 2시간 20분이 걸린다. 시나가와에서 하네다공항 가는 막차는 23시 42분이다. 환승 시간까지 여유있게 고려하여, 신오사카에서 21시 15분에 출발하여 시나가와에 23시 32분에 도착하는 신칸센을 예약했다. 에끼넷에서.

도카이도/산요 신칸센은 JR동일본 관할의 에끼넷 사이트, 그리고 JR도카이-JR서일본-JR규슈 관할의 스마트EX 사이트에서 모두 가능하다. 한국으로 치자면 코레일 홈페이지에서 SRT도 예약이 가능하고 그 거꾸로도 가능한 것이다.

문제는, 열차이용구간은 통합 예약이 가능하지만, 그 예매내역을 가지고 티켓을 발권하는 것은 (기본적으로) 자사 역에서만 가능하다는 점이다. JR동일본 관할인 에끼넷에서 예매한 티켓은 이용구간에 관계없이 도쿄 등 JR동일본 관할역에서만 발권이 가능하다. 반대로 스마트EX에서 예약한 티켓은 이용구간에 관계없이 JR도카이, JR서일본, JR규슈 관할역에서만 발권이 가능하다. ... 어?

내가 이용하는 구간은 신오사카에서 출발하여 시나가와까지 가는 신칸센이고, 라이브는 대판민국에서 열린다. 근데 티켓을 어디서 예약했다고? 에끼넷. 에끼넷은 JR동일본 관할이다. 즉슨 시나가와 도착해야 발권 가능 ㅋㅋㅋㅋㅋㅋㅋ 아니 신오사카에서 시나가와 가는 표를 시나가와 도착해야 발권 가능한게 무슨 말이야 빙구야 ㅋㅋㅋㅋㅋㅋ

물론 이런 황당무계한 상황에 대해 최소한의 구제 대책은 있으니, 도카이도 신칸센 주요 정차역에 설치된 신칸센 자동 발권기를 이용하면 JR도카이 관할 구역 내에서도 에끼넷 예약 티켓을 발권할 수 있다. 그리고- 도카이도 신칸센은 신오사카까지 포함한다. 그렇게, 신오사카 역에 가면 에끼넷 예약분도 발권이 가능하다는 이야기이다.

저녁때는 시간이 없을 것이 뻔하기 때문에 미리 발권을 받아둬야겠다는 생각에서, 일요일 아침부터 신오사카 역에 쫒아갔다. 신오사카 역이 오사카 시내, JR서일본의 관할지역에 위치함에도 불구하고, 3층 신칸센 타는 곳 만큼은 JR도카이 관할이고 신칸센 자동 발권기도 JR도카이가 관리한다.

다만 설치되어 있는 모든 자동 발권기에서 에끼넷 발권을 지원하는 것도 아니더라. 신용카드 전용 발권기에서 에끼넷 전용 메뉴를 눌러서 들어가야 한다. 카드-현금 겸용 기기에는 이 메뉴가 없다. 이걸 몰라서 줄도 여러번 되돌아 서고 진땀을 뺐다.

나중에 안 사실이지만, 그나마 내가 예약한 티켓이 할인을 받지 않은 정가 티켓이어서 JR도카이에서 발권이 가능했다고 한다. JR동일본 고유의 할인을 받은 티켓은 JR동일본 관할 내의 역에서만 발권 가능하며, JR도카이 관할에서는 절대 발권 불가랜다.

또한 JR도카이 관할 구역은 신오사카 까지이다. 그 서쪽으로 넘어가면? JR서일본 관할로 넘어가는데, 이쪽은 에끼넷 예약 티켓을 발권할 수 있는 구제 방법이 없다.......... 진짜 없다. 예를 들어, 후쿠오카에서 신고베까지 이동하는 신칸센을 에끼넷에서 예약했다면? 이를 도쿄에서 발권받은 다음 출발해야 문제가 없다. 예약번호만 들고 현지에 가면 어떤 수를 써도 "발권 불가"로 신칸센을 탈 수 없게 되는 대참사가 벌어진다.

그리고 이러한 모든 사항이 에끼넷에서 예약할 때 시뻘건 안내문으로 뜬다. 그저 나는 그걸 놓치고 넘어갔을 뿐이지... 하...

여하튼 그렇게 개고생해서 새벽2시 비행기를 타고 귀국에 성공했고 외근도 잘 마치고 어쩌고저쩌고 잘먹고잘살았다는 이야기.

그래서 얻은 교훈은, 신칸센을 예약할 때는 출발역에 따라서 예약하는 사이트를 선택하자 정도. 참고로 스마트EX 사이트는 가입할 때 일본현지번호 인증을 요구한다. 에라이 퉤퉤.

RUIFAN

제품정보 > https://ruifan.co.jp/products/

멀티컬러 펜라이트의 대명사 격 되는 킹블레이드 (약칭 킹블) 시리즈의 제조사이다. 그 외에도 펜라이트 중앙제어 시스템인 RAVE 시스템 등을 보유중이다.

TurnON

제품정보 > https://turnon.co.jp/series/

펜라이트만 전문으로 생산하는 회사. LR44 제품군을 비교적 오래 전부터 출시해서 아이마스 겐바에서 사용자를 드물지 않게 볼 수 있다. 별모양, 하트모양 헤드스틱을 판매해서 아이돌 겐바 쪽에 OEM으로 납품되는 경우가 있는 것 같다.

제품군이 다양하지만 크게 24컬러/2버튼, 30컬러/3버튼으로 구분할 수 있으며 사용하는 배터리에 따라 구분된다. 그 외에 기능상 차이는 없으므로 다음 표를 참고하자.

이 중 아이마스 겐바에 반입 가능한 제품은 오롯이 PRO / PRO-III 제품 뿐이다. MOIW2023에서 명시적으로 USB 충전식 제품도 반입 금지를 공지하였다.

LUMICA

대섬광 시리즈로 잘 알려진 루미카에서도 펜라이트를 만들고 있다. 대섬광 블레이드 시리즈인데, 캐미컬 라이트 대비해서는 상대적으로 유명세는 떨어지는 모양이다. 다만 국내에서는 유일하게 정식으로 수입 유통되는 브랜드인 탓에 꽤 팔리는 모양이다.

콘솔 로그인 화면에 IP주소가 표시되면 편리할 것이다.

/etc/issue 파일을 다음과 같이 편집한다. 루트권한으로 작업해야 한다.

Ubuntu 22.04.1 LTS \n \l

IPv4 : \4
IPv6 : \6

네트워크 인터페이스가 여러 개 있다면 \4{enp0s3} 식으로 어떤 인터페이스의 IP를 표시해 줄 지 명시할 수 있다. 인터페이스 이름은 ip 명령어로 확인하시라.

개발 환경을 빠르게 구축하는 것이 목적이므로, 최대한 기본 저장소에서 제공하는 패키지를 설치한다. 최신 안정 버전으로 잘 깔리더라. MySQL을 사용할지 MariaDB를 사용할지는 본인 선택이다.

우분투 설치 (PC, VM, Cloud)

Ubuntu 설치 과정은 직관적이므로 생략한다.

X11 GUI를 사용하지 않을 예정이라면 부트 타깃을 멀티유저로 바꿔주면 좋다. 한 번만 해 주면 된다.

# systemctl set-default multi-user.target

X11 GUI로 되돌리려면 부트 타깃을 graphic으로 바꿔준다.

# systemctl set-default graphic.target

우분투 패키지 저장소 추가하기

Ondrej Sury라는 저명한 개발자가 운영하는 PPA(Personal Package Archive)를 설정해 준다. 이렇게 하면 apt 명령어를 이용해서 Ondrej가 업로드 하는 최신 빌드의 Nginx와 PHP를 설치할 수 있다. 이 사람이 만든 빌드가 데비안의 공식 저장소에도 올라가니까 믿고 써도 된다.

# add-apt-repository ppa:ondrej/nginx
# add-apt-repository ppa:ondrej/php

Ondrej Sury가 제공하는 다른 패키지를 확인하려면 Ondrej의 Launchpad 웹사이트를 방문하면 된다. Apache2 등 다른 패키지도 빌드하여 제공하고 있다.

데비안 설치 (Raspberry Pi)

Raspberry Pi OS는 Debian 기반으로, Ubuntu 기반 빌드를 제공하는 PPA와 호환되지 않는다. 다행히, Ondrej는 Debian 기반 빌드 또한 제공하고 있다.

전용 이미지 프로그램을 이용하면 간단히 SD카드에 Raspberry Pi OS를 설치할 수 있다. 첫 부팅 완료 후 계정 생성, SSH 접속 설정 등 기본 설정 단계를 수행한다.

데비안 패키지 저장소 추가

아직 Debian에서는 Ubuntu PPA 만큼 편리하게 개인 저장소를 추가하는 기능은 제공하지 않고 있다. 수동으로 추가를 해 줘야 하는데, Ondrej가 제공하는 스크립트를 이용하면 상대적으로 손쉽게 이를 수행할 수 있다.

NginX - https://packages.sury.org/nginx/
PHP - https://packages.sury.org/php/

두 개의 패키지 저장소에서 README.txt 파일을 참고하여 저장소를 설정한다.
#으로 시작하는 주석을 제외한 나머지 내용을 긁어서 쉘에 붙여넣기 하면 된다.

MariaDB

MariaDB의 저장소를 추가해 준다. 공식 저장소 안내 페이지에서 리눅스 배포판과 설치하려는 MariaDB 버전, 그리고 지리적으로 가까운 미러서버를 선택한 다음 지시대로 따르면 된다.

패키지 업데이트

매번 하는 apt update && apt upgrade 과정이다. 커널 업데이트 등으로 재부팅이 필요하면 해 준다.

구형 패키지를 apt autoremove --purge 명령어로 정리해 준다.

VM을 사용한다면 이 정도에서 스냅샷을 하나 떠 두는 것도 좋은 선택지이다.

패키지 설치

PHP 확장 패키지 목록은 Cafe24 호스팅에서 지원하는 확장을 기준으로 설치하였다. 버전이 여러 개라고 오류 나면 php8.2-dba 식으로 버전을 붙여주면 된다.

# apt update
# apt install ssh nginx mariadb-server php-fpm
# php --version
PHP 8.2.9 (cli) (built: Aug 16 2023 19:49:37) (NTS)
...
# apt install php-bcmath php-bz2 php-curl php-dba php-gd php-imagick php-intl php-mbstring php-mysql php-sqlite3 php-soap php-xml php-xmlrpc php-xsl php-zip

MariaDB 초기 설정

초기 설정 스크립트를 이용해서 유닉스 소켓 인증(사용안함 권장), 루트계정 암호 설정(강력한 암호 설정 권장), 루트계정 외부접속 차단(사용 권장), 테스트DB 삭제 등등의 절차를 수행한다.

# mysql_secure_installation
...
Enter current password for root (enter for none):
...
Switch to unix_socket authentication [Y/n] n
...
Change the root password? [Y/n] y
New password: 
Re-enter new password: 
...
Remove anonymous users? [Y/n] y
...
Disallow root login remotely? [Y/n] y
...
Remove test database and access to it? [Y/n] y
...
Reload privilege tables now? [Y/n] y

사용자와 DB를 추가하고 권한을 할당해 준다. 나중에 Adminer 같은거로 해도 된다.

# mysql -u root -p
Password:
MariaDB[]> create user `username`@`%` identified by `password`;
MariaDB[]> create database `userdb`;
MariaDB[]> grant all privileges on `userdb`.* to `username`@`%`;
MariaDB[]> flush privileges;
MariaDB[]> exit;

NginX - php-fpm 연동

# nano /etc/nginx/sites-enabled/default

해당 파일에서 index 로 시작하는 구문을 찾는다. 디렉터리 주소만 요청을 받았을 때 기본적으로 보여줄 파일명을 지정하는 구문이다. index.php 를 적당히 추가해 준다.

다음으로 location ~ \.php$ { 로 시작하는 블럭을 찾아서 주석을 풀어준다.

fastcgi_pass 구문이 두 개가 있을 건데, 우리는 php-fpm을 사용한다. TCP 소켓으로 되어 있는 줄은 다시 주석처리 해 준다.

마지막으로 php7.4-fpm.socks 로 되어 있는 것을 php8.2-fpm.socks 식으로 PHP 버전에 맞게 바꿔 준다. 경로는 건들지 않아도 된다.

nginx를 재시작한다.

# systemctl restart nginx

테스트

/var/www/html 디렉터리에 다음 내용으로 phpinfo.php 파일을 만들어 준다.

<?php
phpinfo();
?>

다른 컴퓨터에서 접속해 본다. It should work!

지난 글에서 hub and spoke (a.k.a. star) 토폴로지 형태의 VPN을 구성했다. 클라우드에 서버를 한 대 두고, 이 서버에 연결하면 마치 다른 VPN 클라이언트와 허브로 연결된 것처럼 서로 통신할 수 있게 되는 구조이다.

사실 Wireguard는 L3에서 동작하고, 흔히 쓰는 스위칭 허브는 L2에서 동작하므로 정확하게 같은 기능을 수행하지는 않는다. L2TP나 OpenVPN tap모드, Softether VPN의 Virtual L2 switch가 이에 해당한다.

여하튼. 그렇게 서버로 전달된 패킷을 우리가 원하는 목적지로 보내려면 서버에서 패킷을 재차 어딘가로 전달해 주어야 한다. 이렇게 패킷을 던지고 던지고 던져서 목적지로 찾아가는 과정을 라우팅(Routing)이라고 한다. 영어단어 그대로 경로를 찾아가는 과정이다. 이 부분을 조금 더 손 볼 수 있다면 조금 더 재미있는 구성이 가능해진다.

위 토폴로지에서 서버와 연결된 클라이언트는 라우터이다. 라우터는 그 이름에서 알 수 있듯 패킷 라우팅을 수행해주는 장비이고, 따라서 위와 같은 경로로 두 대의 검정색 PC는 흰색 PC와 통신할 수 있다. 별도의 VPN 터널을 형성하지 않아도.

이러한 구성을 site-to-site VPN이라고 한다. 사실 point-to-site VPN과 site-to-site VPN이 뒤섞여 있다. 우측처럼 라우터 단에서 패킷을 중계하면서, 네트워크 전체가 투명하게 VPN에 접속하게 되는 경우 site-to-site VPN이라고 한다.

AllowedIPs 설정

Wireguard에서 라우팅은 [Peer] 섹션의 AllowedIPs 항목으로 제어한다. 이 항목은 방화벽의 AllowFrom 역할과 동시에 라우팅 테이블의 Route 역할을 한다.

예를 들면, Wireguard 설정에서 기본적으로 AllowedIPs = 10.10.0.0/24 식으로 잡곤 하는데,  VPN의 상대방 서버에서 보내오는 패킷의 src 주소가 10.10.0.0/24 서브넷일 때에만 패킷을 수신하겠다는 방화벽 설정이자, 동시에 내가 보내는 패킷의 dst 주소가 10.10.0.0/24 서브넷이면 상대방 서버로 보내겠다는 라우트 테이블의 역할을 같이 하는 것이다. 양방향 통신을 전제하므로 이렇게 하나의 세팅으로 퉁치는 것이 가능하게 된다.

spoke에 해당하는 개별 클라이언트는 서브넷 전체를 잡아야 하고, hub에 해당하는 서버에서는 AllowedIPs = 10.10.0.8/32 식으로 개별 IP를 할당해 주어야 한다. 왜 그런지 이해가 된다면 네트워크 구성에 감각이 있는 것이다.

Site-to-site VPN 설정

위 예에서 흰색 PC와 라우터 서브넷 사이에서 site-to-site VPN을 구성하려면 어떻게 해야 할까? 설정이 조금 복잡해지므로 단계별로 알아보자.

네트워크 플래닝

우선 네트워크 플래닝부터 해야 한다. 어느 사이트(지점)에 어떤 IP를 깔아 줄 것인지를 미리 구성하고 최적화하는 것이다. 예를 들어 다음 그림처럼 3개의 site (원격접속 하고자 하는 사무실)와 1개의 개별 클라이언트 (아마도 카페에서 일하고 있을 독자의 노트북)가 존재하는 상황을 가정해 보자.

Wg로 구축할 VPN은 관습적으로 10.10.0.0/24 서브넷을 사용한다. 나는 여기에 몇 가지 룰을 추가하여 IP를 할당하였다. 물론 이는 내 상황에 맞추어 임의로 설정한 것이므로, 네트워크 설정을 할 줄 안다면 굳이 이 룰을 따를 이유는 없다.

• 허브가 되는 중앙 VPN서버는 관례상 10.10.0.1 을 사용한다.
• 중앙 VPN서버에 단독으로 접속하는 개별 클라이언트는 10.10.0.[2-127] 을 사용한다. 따라서 최대 126개 클라이언트가 접속할 수 있다.
• 다른 서브넷을 대표하여 접속하는 site VPN 클라이언트는 10.10.0.[192-207] 을 사용한다. 따라서 최대 16개 site가 붙을 수 있다.
• site VPN 클라이언트에 연동되는 지점망은 192.168.[192-207].0/24 서브넷을 사용하며, 관리 편의를 위해서 의도적으로 지점망 서브넷의 세 번째 자리와 VPN IP의 네 번째 자리를 같은 값으로 사용한다.

단독 클라이언트

이제 서버와 각 클라이언트 마다 AllowedIPs 항목을 설정해 주어야 한다. 우선 단독 클라이언트부터 생각해 보기로 하자.

단독 클라이언트는 VPN터널 너머로 큰 테두리 안에 있는 네트워크 전체와 통신하고 싶을 것이다. 그렇다면 단독 클라이언트의 AllowedIPs 항목을 어떻게 설정해야 할까.

우선 VPN 클라이언트 사이의 통신을 위해 10.10.0.0/24 는 들어가야 함은 명백하다.그리고...

• 첫 번째(M=192) 지점망 내부의 PC와 통신하기 위해서 192.168.192.0/24 서브넷이 추가되어야 한다.
• 두 번째(M=193) 지점망 내부의 PC와 통신하기 위해서 192.168.193.0/24 서브넷이 추가되어야 한다.
• ...
• 16번째(M=207) 지점망 내부의 PC와 통신하기 위해서 192.168.207.0/24 서브넷이 추가되어야 한다.

총 16개 설정이 주루룩 추가되어야 한다. 그런데 잘 보니 해당 서브넷들은 서로 연달아 붙어 있는 특정한 범위에 포함된다. 해당 서브넷을 계산해 보면 192.168.[192-207].0/24 범위로 표기되는데, 이는 192.168.192.0/20 서브넷과 정확하게 일치한다. 따라서 위의 16개 설정은 단순히 하나의 설정으로 통합할 수 있다. 이를테면 CIDR 의 prefix aggregation을 고려해서 M의 범위를 할당해 주어야 한다는 것이다.

최종적으로 단독 클라이언트의 AllowedIPs = 10.10.0.0/24, 192.168.192.0/20 으로 계산할 수 있다.

Site VPN 클라이언트

다음으로 site VPN 클라이언트의 경우를 살펴보자. 예를 들어 N=193으로 가정해 보자.

단독 클라이언트와 별반 다르지 않다. VPN 클라이언트 사이의 통신을 위해 10.10.0.0/24 는 들어가야 함은 명백하다. 그리고...

• 첫 번째(M=192) 지점망 내부의 PC와 통신하기 위해서 192.168.192.0/24 서브넷이 추가되어야 한다.
• 두 번째(M=193) 지점망 내부의 PC와 통신하기 위해서 192.168.193.0/24 서브넷이 추가되어야 한다. 어 잠깐만?
• 세 번째(M=194) 지점망 내부의 PC와 통신하기 위해서 192.168.193.0/24 서브넷이 추가되어야 한다.
• ...
• 16번째(M=207) 지점망 내부의 PC와 통신하기 위해서 192.168.207.0/24 서브넷이 추가되어야 한다.

단독 클라이언트와 같은 라우팅 테이블 최적화 과정을 거치다 보니 문제가 발생한다. 지점망 내부의 라우팅 테이블과 Wg의 라우팅 테이블이 중복된다. 어떻게 해야 하지?

• 확실한 방법은 Wg의 AllowedIPs 항목을 쪼개서 수동으로 기재해 주는 이다. 15개만 써 주면 된다.
• 라우터 설정을 바꿀 수 있다면 라우팅 테이블의 우선 순위를 조절하는 방법을 택할 수 있다. 여러 라우팅 테이블의 항목이 겹친다면 Metric 값에 따라 우선 순위가 매겨진다. 내부 지점망의 Metric값을 더 큰 값으로 주어 우선 순위를 높여주면 된다.
• 같은 Metric을 갖는 라우팅 테이블은 More Specific → Less Specific 순서로 적용된다. 지점망의 CIDR은 24이고 Wg의 CIDR은 20이므로 그냥 무대뽀로 적용해 본다.

네트워크의 안정성과 관리 편의성 사이에서 적절히 선택하자. 나는 세 번째를 선택했다. lol!

최종적으로 site VPN 클라이언트 또한 AllowedIPs = 10.10.0.0/24, 192.168.192.0/20 으로 계산할 수 있다.

VPN 서버

마지막으로 VPN 서버 설정도 해 주어야 한다.

위 예시를 기준으로 VPN 서버 입장에서 보면 4개의 Peer 항목이 존재할 것이다. 음...

각 Peer 사이에서는 겹치는 라우팅이 발생하면 안 된다. 이를테면 중앙 우체국에서 편지를 분류함에 있어서 혼란이 있으면 안 되니까.

우선 10.10.0.A 주소를 사용하는 단독 클라이언트부터 생각해 보자. 이 클라이언트에서 받고 싶은 발신인 주소, 그리고 이 클라이언트로 보내야 하는 수신인 주소는 딱 10.10.0.A 하나 뿐이다. AllowedIPs = 10.10.0.A/32 확정.

다음으로 10.10.0.M 주소를 사용하는 site VPN 클라이언트를 생각해보자. 이 클라이언트에서 받고 싶은 발신인 주소는? 10.10.0.M 과 더불어 192.168.M.0/24 서브넷이 포함된다. 지점망에 붙어 있는 모든 PC도 이 VPN을 쓸 수 있으니까. 이 클라이언트로 보내고 싶은 수신인 주소는? 동일하다. AllowedIPs = 10.10.0.M/32, 192.168.M.0/24 확정. 중복 문제는 발생하지 않는다.

이러한 기준으로 모든 Peer 섹션을 구성해 주면 된다.

패킷 포워딩 설정

Wg 설정 자체는 위 과정을 거치면 끝난다. 다만 몇 가지 추가 설정을 해 주어야 하는 부분이 남아 있다.

우선 지난 글에서 언급한 것처럼 VPN 서버에서 wg0 in - wg0 out 패킷에 대해서 포워딩 설정을 해 주어야 한다. 다음으로 각 site VPN 클라이언트에서도 eth0 - wg0 사이에 포워딩 설정을 해 주어야 한다. 이 설정을 하지 않으면 지점망 PC가 보낸 패킷이 라우터 단에서 드롭되므로 VPN 내부까지 전달되지 않는다.

이러한 설정은 각 라우터의 설정방법에 따라 진행하면 된다. OpenWRT의 경우, eth0 과 wg0 을 같은 방화벽 구역(Zone)에 두고, Forward 설정을 accept 로 바꿔주면 된다.

Site VPN 클라이언트 기능을 지원하는 라우터

사실 이게 가장 구하기가 어려웠다. 국내에서 판매중인 공유기 중 VPN 클라이언트 기능을 지원하는 모델은 없다시피 하다. 그나마 최근 들어 ipTIME 제품 중 일부가 OpenVPN 클라이언트 기능을 지원하기 시작했다.

2022년 3월 현재 Wireguard를 지원하는 모델은 없다는 의미이다.

다행히도 OpenWRT를 올리면 Wireguard 클라이언트 확장기능을 설치할 수 있다. 그리고 ipTIME 제품 중 A1004ns를 포함해서 일부 제품에 OpenWRT를 설치할 수 있다. 나는 중고가 2만원 정도에 구매해서 그냥 펌웨어 엎어버렸다.

휴일

주휴일, 공휴일, 근로자의 날은 "휴일"이다. 보통 일요일을 주휴일로 하지만 꼭 그러는 것은 아니다. 도서관은 보통 월요일 또는 수요일 휴관하는 것처럼 말이다.

휴일은 근로의무가 없다. 즉, 휴일근로는 애당초 예정에 없던 근로이다. 따라서 휴일근로의 기본급 또한 수당으로 지급할 수밖에 없다. 반면 어느 날이 휴일인지는 미리 알 수 있으므로 유급 휴일 수당은 월급에 미리 계산해서 넣을 수 있다. 따라서 다음과 같이 급여와 수당이 책정된다. 소정근로시간=하루 8시간으로 가정하자.

월급에 이미 포함되어 있음
- (유급 휴일인 경우) 유급 휴일 수당 (기본급 100% * 소정근로시간)

수당으로 지급
- 휴일근로 기본급 (기본급 100% * 휴일근로시간)
- 휴일수당 (근로의무가 없음에도 근로한 보상) (기본급 50% * 휴일근로시간)
- 연장근로수당 (기본급 50% * (휴일근로시간 중 소정근로시간 초과분))
- 야간근로수당 (기본급 50% * (휴일근로시간 중 22시~06시 근로분))

따라서 월급쟁이가 2022년 대선 선거일에 출근해서 낮시간 8시간을 근무했다면 수당으로 기본급 8시간분의 150%가 지급된다.

휴무일

주5일제가 시행되면서 "휴무일"이 새로 생겼다. 법적으로 정해진 개념은 아니라고 한다. 보통 토요일을 휴무일로 하지만 꼭 그러는 것은 아니다.

휴일과 달리 휴무일은 근로의무가 있다. 단지 주5일제를 시행하면서 휴무일은 소정근로시간이 0이 되며, 따라서 근로의무를 면제한 것(=쉬기로 한 것=휴무)이다. 애당초 근로의무가 있는 것을 쉬기로 한 것이므로 휴일 수당이 지급되지도 않으며, 소정근로시간이 0이므로 따로 정하지 않는 이상 무급이다.

주5일제에 따라 나머지 근로일을 모두 정상 근로했다면, 휴무일 근로는 무조건 연장근로가 된다. 따라서 토요일 근로시간은 모두 연장근로로 계산해야 한다.

월급에 이미 포함되어 있음
- 기본급 (기본급 100% * 0시간) = 0

수당으로 지급
- 근로의무가 있으므로 휴일수당은 없다.
- 기본급 (기본급 100% * 연장근로시간)
- 연장근로수당 (기본급 50% * 연장근로시간)
- 야간근로수당 (기본급 50% * (연장근로시간 중 22시~06시 근로분))

반대로, 나머지 근로일 중 빵꾸를 내서 소정근로시간을 채우지 못해 토요일에 출근해 벌충하는 경우라면 기본급 외에는 다른 수당이 없다. 지각 조퇴를 토요일 출근으로 메꾸는 경우라면 주말 특근 수당은 받을 생각 하지 말자.

어째서 이런 일이 필요한가?

회사 건물의 네트워크 구조가... 좀 거지같다.

건물 인터넷으로 KT 기업용 회선이 깔려 있는데, 공유 오피스 5개 층에 공인IP를 모두 할당해 주면 돈이 너무 많이 나가는 모양이다. 얹혀 사는 입장에서는 군소리 할 계제가 없다.

층 당 포트 40개 정도 설치되어 있으니, 5개 층이면 포트가 200개 쯤 될 거다. 여하튼 건물 내부에서 인터넷을 연결하면 사설IP가 할당되고, KT에서 깔아준 방화벽이 그 앞을 틀어 막고 있다. 외부에서 접속은 막혀 있고, D-NAT (흔히 말하는 포트 포워딩) 열어 달라고 은근슬쩍 관리 사무실에 물어보니 "그게 모에요?" 하는 걸 보고 말끔히 포기.

근데 그렇다고 외근이나 재택근무를 피할 수도 없으니, 회사 컴퓨터에 원격 접속은 꼭 필요하다. 그럼 이걸 어떻게 뚫어?

역방향으로 VPN을 굴리자

결론부터 말하면 외부에 적당한 VPN 서버를 두고, 회사 컴퓨터에서 상시 접속 상태를 유지하면 된다.

실제 구축 사례를 보자. VPN 소프트웨어는 WireGuard (WG)를 이용하였다.

위 그림과 같은 방식이다. 외부에 WG 서버를 두고, 회사 컴퓨터와 외부 컴퓨터가 모두 VPN에 접속하면 된다. 그러면 서로 VPN 내부의 사설IP 주소로 원격 접속을 할 수 있게 된다. 이런 구성을 Hub and Spoke model 이라고 하는 모양이다.

물론 여기에서 설명이 빠진 부분이 존재한다. 기본적으로 VPN은 점 대 점(Point-to-Point) 연결이기 때문에, 외부 컴퓨터에서 쏘는 패킷은 서버로 전달되며, 회사 컴퓨터로는 전달되지 않는다. 반대 경로도 마찬가지이다. 둘 사이에 직접적인 연결이 없기 때문이다.

그렇다면 WG 서버가 둘 사이의 패킷을 중계해 주도록 해야 한다. 슬슬 눈치챘을 것이다. WG 서버에서 net.ipv4.ip_forward 설정을 켜고, 넷필터 에서도 FORWARD 룰을 설정해 주어야 한다.

넷필터 룰 자체는 간단하다. 입력=출력=wgX 인터페이스인 경우 ACCEPT로 잡아주면 된다. 다만 WG 가상 인터페이스가 생기고 없어질 때마다 룰을 재설정 해 주는게 귀찮을 따름이다.

마침 wg-quick에는 PreUp/PostUp , PreDown/PostDown 훅이 존재하고, 여기에서 %i 예약어를 인터페이스 이름으로 대체해 준다. 따라서 WG 서버에서 사용하는 wg-quick 설정 파일에 다음과 같이 설정해 주면 서비스를 올리고 내릴 때마다 알아서 포워딩 룰을 잡아준다. 손에 익은게 iptables라 이걸 사용하고 있는데, 어째 요즘은 nftables를 더 많이 사용하는 모양이다.

PreUp=sysctl -w net.ipv4.ip_forward=1
PostUp=iptables -I FORWARD -i %i -o %i -j ACCEPT
PostDown=iptables -D FORWARD -i %i -o %i -j ACCEPT

이제 지속적으로 WG서버와 회사 컴퓨터 사이에 통신이 오가도록 해서, 방화벽의 S-NAT 설정을 유지해야 한다. WG는 UDP 연결을 사용하는데, 오랫동안(보통 30초) 트래픽이 없으면 방화벽은 통신 종료로 간주하여 S-NAT 설정을 날려버리고, 그럼 VPN 접속이 끊어진다. 이걸 복구하려면 회사 사무실에 가서 다시 VPN을 켜 줘야 하니, 원격 접속을 하겠다는 목적은 말짱 도루묵이 되어 버린다.

WG의 PersistentKeepalive 설정을 이용하면 손쉽게 몇 초 마다 PING을 날려서 연결을 유지해 준다. 회사 컴퓨터의 WG 설정에 다음과 같이 추가해 주면 된다. 예를 들어 15초마다 Ping을 날리도록 하려면 15를 설정해 준다.

PersistentKeepalive = 15

WG서버 마련하기

이제 문제는 24/7 구동되는 WG 서버를 마련하는 것이다.

집에 놀고 있는 라즈베리파이 같은 싱글보드 컴퓨터(SBC)가 있다면 서버로 설정해서 사용할 수도 있을 것이다. 다만 요즘 반도체 대란으로 전반적으로 SBC 구매가 쉽지 않은 편이며, 그 외에도 전기 및 인터넷 요금도 내가 부담해야 하니 조금 아쉬울 수 있다.

이럴 때 쓰라고 있는게 클라우드 서비스에서 제공하는 VPC이다. 동시 접속자 두서너 명 정도의 WG 서버는 그렇게 고성능 서버를 요구하지 않기 때문에, 클라우드 서비스의 무료 맛보기 티어 정도만 되어도 충분하다.

클라우드 서비스의 대표 주자인 AWS는 아쉽게도 VPC 서비스의 무료 티어가 제한적이다. 계정 생성 후 12개월 동안만 제공하고 이후로는 돈을 내야 한다. GCP나 OracleCloud는 Always Free 인스턴스를 제공하므로 이 쪽을 이용해 봄 직 하다.

XPEnology라고, 시놀로지 하드웨어를 에뮬레이트 해 주는 부트로더가 있다. 이걸 이용하면 DSM을 아무 하드웨어에서나 구동할 수 있어서 흔히 해놀로지(해킹된 시놀로지)라고 부른다. 법적으로 문제되는지 여부는 사실 잘 모르겠다. 써 볼 지 어쩔지는 이 글을 읽고 있는 독자 본인의 선택이다.

여하튼. 정석적인 설치 방법은 NAS로 활용할 전용 PC를 준비하고 USB에 부트로더를 설치하여 구동하는 것이다. 다만 이런저런 이유로 전용 PC 준비가 어려운 경우 VMware 같은 가상화 솔루션을 이용하여 XPEnology를 구동해 볼 수 있다. VMware에서 가상 USB를 지원하지 않기 때문에 설정 방법이 조금 더 복잡해진다.

VMware 설치 방법은 생략한다. 2022년 1월 현재 VMware Workstation 30일 무료판을 이용할 수도 있고, 개인용으로 무료인 VMware Player를 이용할 수도 있다. 가상 머신을 생성하는데 Linux, Other 5.x kernel (64bit) 로 진행하면 된다. DSM 자체가 꽤 사양을 요구하기 때문에, XPEnology 구동할 가상 머신은 2코어, 램 2GB 이상으로 설정하는게 좋다. 가상 디스크는 저장소로 사용할 디스크를 SATA 형식으로 생성한다. ~100GB 정도는 되어야 쓸만할 것이다.

XPEnology 포럼에서 부트로더를 다운로드 한다. DSM 6.2 버전의 부트로더는 다음 링크에서 다운로드할 수 있다. DS918+ v1.04b 를 다운로드하면 된다.

https://xpenology.com/forum/topic/12952-dsm-62-loader/

다운받은 파일의 압축을 해제하면 50MB의 synoboot.img 파일만 덜렁 나올 것이다. 참 불친절하지만 개인 개발자가 돈도 안 받고 만들어 올려주는 것에 불만을 갖지 말자.

부트로더를 다운로드 받았으면 이제 설정을 약간 손봐야 한다. 윈도우에서 osfmount 툴을 사용하거나, 리눅스에서 루프 마운트를 이용해서 파티션을 마운트 할 수 있다. 해당 이미지 안에는 3개의 파티션이 있는데, 그 중 첫 번째 파티션을 마운트 한다. 리눅스라면 다음 명령어 비슷하게 입력하면 될 것이다.

$ fdisk -l ./synoboot.img
Disk ./synoboot.img: 50 MiB, 52428800 bytes, 102400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 52173969-41B8-4EDB-9190-B1CE75FCFA11

Device          Start    End Sectors Size Type
./synoboot.img1  2048  32767   30720  15M EFI System
./synoboot.img2 32768  94207   61440  30M Linux filesystem
./synoboot.img3 94208 102366    8159   4M BIOS boot
$ sudo mount -o loop,offset=$((2048*512)) ./synoboot.img ./temp
$ cd ./temp/grub
$ sudo nano grub.cfg

이제 grub.cfg 파일을 수정해 준다. 주로 수정할 부분은 다음과 같다.

• 22-23번 라인: vid=와 pid=를 설정하는 부분이다. 실제 PC에서 USB 부팅으로 사용한다면 이 부분을 USB의 값에 맞도록 수정해 주어야 한다. 가상머신 에서는 반영되지 않으므로 기본값을 그대로 두어도 된다.
• 24번 라인: sn=기기 시리얼 번호를 설정한다. 자리수가 동일하도록 적당히 숫자만 고쳐 준다.
• 25번 라인: mac1= 이더넷 MAC 주소를 변경해 준다. 가상머신의 MAC 주소는 가상머신 콘솔의 Devices 에서 Network Adapter 더블클릭하여 설정창을 연 뒤 Advanced... 버튼을 클릭하면 확인할 수 있다.

• 실제 PC에서 랜카드가 여러 개라면 이 줄 다음에 이어서 mac2, mac3, mac4 까지 추가해 주면 된다.
• 34번 라인: sata_args= SATA 설정을 변경해 준다. 가상머신에서 작동할 때 이 부분 설정이 중요한데, SataPortMap=44 DiskIdxMap=0010 으로 입력해 주면 대체로 문제없이 작동한다.
  SataPortMap=44 부분은 한 자리씩 잘라서, 첫 번째 SATA 컨트롤러의 포트가 4개, 두 번째 컨트롤러의 포트가 4개라고 강제로 인식시키는 명령어이다. DiskIdxMap=0010 부분은 두 자리씩 잘라서, 첫 번째 SATA 컨트롤러의 포트가 0x00=0번으로 인식되고, 두 번째 컨트롤러의 포트는 0x10=16번으로 인식되도록 한다.
  이후 가상머신에서 데이터 디스크는 첫 번째 컨트롤러에, 부팅 디스크는 두 번째 컨트롤러에 설정할 것이다. DSM에서 하드디스크는 0~15번 까지만 인식하므로, 부팅 디스크를 16번으로 설정하여 인식에서 제외시키는 것이다. 이 작업을 해 주지 않으면 부팅 디스크를 데이터 디스크로 인식하면서 DSM 초기 설치시 오류가 발생하게 된다.
• 실제 하드웨어에서도 컨트롤러를 여러 개 연결하여 하드 디스크를 십수개 씩 연결하는 경우, 이 부분을 컨트롤러 환경에 맞도록 설정해야 한다. 특히 HBA를 사용하여 SAS 인터페이스를 사용하는 경우, SasPortMap, SasIdxMap 파라미터를 지정해 주어야 한다.
• 37번 라인: timeout= 부트 메뉴 대기 시간이다. 기본값 1초는 너무 짧으므로 3초나 5초 정도로 수정한다.

이제 grub.cfg 파일을 저장하고, synoboot.img 파일을 가상 디스크 VMDK 포맷으로 바꾸어 주어야 한다. img파일은 raw disk image이므로, 그냥 50MB짜리 Pre-allocated VMDK 파일을 만들고 데이터 파일만 바꿔주면 된다. 굳이 서드파티 툴을 사용할 필요가 없다. VMware를 기본 디렉터리에 설치했다면 명령 프롬프트를 열고 다음과 같이 실행하면 된다. -t 2 부분이 Preallocated VMDK 파일을 만들라는 옵션이다.

"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -c -s 50MB -t 2 synoboot.vmdk

이제 synoboot.vmdk, synoboot-flat.vmdk 파일이 생성되었을 것이다. flat 파일을 삭제하고, synoboot.img 파일을 해당 이름으로 바꿔주면 된다.

생성한 부트로더 파일을 가상머신에 추가해 준다. 이 때 SATA로 추가해 준 다음, SATA node를 변경해 주어야 한다. 가상머신 콘솔의 Devices 에서 추가된 디스크의 Hard Disk  X (SATA) 를 선택한 뒤, Advanced... 에서 node를 1:0 으로 바꿔 준다. 두 번째 컨트롤러의 첫 번째 장치로 바꾸어 주는 것이다.

이제 가상머신 전원을 켠다. 부트로더에서 세 번째 항목을 선택해야 함을 잊지 말자. Happy hacking. 메시지가 뜨면 30초 정도 기다렸다가 http://find.synology.com/ 에 접속해서 초기 설정을 진행하면 된다.

시스템 설치시 DSM 설치 파일은 6.2.3 버전을 수동으로 설치해 주어야 한다. 자동 설치를 선택하면 6.2.4를 다운로드 하는데, 이 버전에는 부트로더 파손되는 문제가 있어서 설치를 권장하지 않는다. 다음 URL에서 구 버전을 다운로드 받을 수 있다. DS918+ 로 검색해서 다운로드 받으면 된다.

https://archive.synology.com/download/Os/DSM/6.2.3-25426

설치 후 다음 포럼 글에 따라 FixSynoboot.sh 를 설치해 주면 DSM 6.2.3-Update3 까지 업데이트가 가능하게 된다. 포럼 가입이 필요한데 이메일 주소만 있으면 된다. 귀찮다면 그냥 업데이트 안 하고 써도 된다.

https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/

휴대폰 본인인증은 대충 다음과 같은 플로우로 이루어진다.

1. 웹페이지에 hidden form 데이터로 가맹점 정보 및 콜백 URL을 담고, 이 페이지를 클라이언트에게 보여준다. 이 페이지는 document.onload에서 PG사에서 제공하는 Javascript 함수를 호출하여, form 데이터를 PG사의 Endpoint에 submit 시킨다.
2. PG사의 Endpoint에서는 휴대폰 본인인증이 진행되며, 이 과정이 완료되면 PG사는 인증 정보를 hidden form 데이터로 담아 클라이언트에게 보여준다. 그리고 이 데이터를 콜백 URL로 submit 시키도록 Javascript 함수를 호출한다.
3. 개발자는 콜백 URL의 핸들러에서 form 데이터를 받아서 이케이케 쓰면 된다.

흔히 보는 OAuth 연동과정과 유사하다. 단지 300 Redirect를 쓰는지, 아니면 전달할 데이터를 form에 담아 POST 찌르도록 하는 방법을 쓰는지 다를 뿐이다. CSRF니 어쩌니 해서 복잡한 문제가 있지만, 이 포스팅의 관심범위 밖이니까 일단 넘어가자.

연동 자체는 큰 문제 없이 이루어졌지만, 문제는 데이터 자체에 에 있었다. 다른 필드들은 별 문제가 없지만 개인정보와 관련된 부분(이름, 생일, 휴대폰번호, 고유식별번호 등)은 의무적으로 암호화 되어 전달된다. TLS 쓰면 되지 않을까 생각이 들지만, 여하튼 의무적으로 암호화해야 한댄다.

암호화 된 데이터가 온다면 복호화 하면 된다. 그리고 KG모빌리언스에서는 복호화 모듈을 포함한 콜백 URL 핸들러 샘플 코드를 제공한다. 그런데 이게 ASP, JSP, PHP로만 제공된다. 파이썬? 그런거 없다. 야이씨... 하릴없이 소스를 뜯어야 하는데 그나마 내가 만질 줄 아는 코드는 PHP니까 그 코드를 까 봤다. 그리고 당당히 등장하는 그 이름, SEED.

SEED 알고리즘이 나오게 된 계기에 대해서는 넘어가기로 하고, 여하튼 KG모빌리언스는 개인정보 암호화에 KISA에서 만든 SEED-128를 사용한댄다. 추측컨대 다른 PG사도 똑같이 SEED를 사용할 것이다. PHP 샘플 코드에 포함된 SEED 구현체를 까 보니, C 라이브러리를 사용하는 것도 아니고 진짜로 바이트 연산을 일일이 PHP 문법으로 코딩해 둔 생짜 구현체이다. 속도 문제는 둘째치고, 이걸 파이썬으로 포팅해야 하나? 내가 직접?

다행히도(?) SEED 알고리즘은 RFC4269로 공개되어 있고, 최신 버전의 OpenSSL에도 그 구현체가 포함되어 있다. 그리고 파이썬에는 OpenSSL 기반으로 데이터 암호화 기능을 제공하는 Cryptography 패키지가 존재한다. 문서를 뒤지고 뒤져보니 Cryptography에서도 SEED 알고리즘을 지원한다. 아 일단 다행이다.

데이터를 복호화 하려면 두 가지 값을 알아야 한다. 하나는 SEED-128 Preshared key이고, 다른 하나는 PG사에서 보내준 ciphertext 이다. 전자는 PG사 관리자 페이지에 미리 등록해 준 16글자 영숫자 문자열이고, ciphertext는 바이너리 데이터를 hexstring으로 보내주므로 이를 다시 바이너리 형태로 바꿔줘야 한다. 그럼 이제 복호화를 해 보자.

from cryptography.hazmat.primitives.ciphers import Cipher
from cryptography.hazmat.primitives.ciphers.algorithms import SEED
from cryptography.hazmat.primitives.ciphers.modes import ECB

SEED_PRESHARED_KEY = b"SUPERSECRET23456"
cipher = Cipher(SEED(SEED_PRESHARED_KEY), ECB())


def pg_decode(ciphertext: str) -> bytes:
    ciphertext = bytes.fromhex(ciphertext)
    decryptor = cipher.decryptor()
    plaintext = decryptor.update(ciphertext)
    plaintext += decryptor.finalize()
    return plaintext


def pg_callback(form_data):
    # some mysterious code block
    auth_name = pg_decode(form_data.get("Name"))
    auth_phone = pg_decode(form_data.get("Number"))
    # some mysterious code block

그렇게 Endpoint를 대충 꾸리고, 연동 테스트를 해 보았다. 한 방에 잘 되었다면 이 글을 쓰지도 않았을 것이다. 당연히 안 된다. 아이씨 뭐야. 샘플 PHP 코드를 디깅 시작해 보자. 참고로 오픈 태그를 <? 사용하는 10년은 더 묵은 예제 코드다.

Preshared key

SEED-128 Preshared key는 PG사에 미리 등록한 16글자 문자열이다. 그런데 이걸 바로 사용하지 않는다. 앞 바이트부터 순서대로 [1, 2, ..., 16]을 XOR 처리하여 사용한다. 웨?...

여하튼 그렇게 되어 있으니 바꿔야지. 코드를 고쳤다.

from cryptography.hazmat.primitives.ciphers import Cipher
from cryptography.hazmat.primitives.ciphers.algorithms import SEED
from cryptography.hazmat.primitives.ciphers.modes import ECB

MCASH_PRESHARED_KEY = b"SUPERSECRET23456"
SEED_PRESHARED_KEY = b"".join(
    map(lambda c, m: c ^ m,
        MCASH_PRESHARED_KEY,
        range(1, len(MCASH_PRESHARED_KEY)+1)
    )
)
cipher = Cipher(SEED(SEED_PRESHARED_KEY), ECB())


def pg_decode(ciphertext: str) -> bytes:
    ciphertext = bytes.fromhex(ciphertext)
    decryptor = cipher.decryptor()
    plaintext = decryptor.update(ciphertext)
    plaintext += decryptor.finalize()
    return plaintext


def pg_callback(form_data):
    # some mysterious code block
    auth_name = pg_decode(form_data.get("Name"))
    auth_phone = pg_decode(form_data.get("Number"))
    # some mysterious code block

위 코드에서 SEED_PRESHARED_KEY 값과 PHP SEED 구현체에 입력되는 Key 값이 같음을 확인했다. 이제 잘 되겠지? 당연하지만 안된다. 아니 씨 또 왜!

Endian swap

위 코드에서 ciphertext와 PHP SEED 구현체로 입력되는 ciphertext도 같은 값임을 확인했다. 그럼 이제 구현체 내부에 무언가가 있다는 이야기이다. OpenSSL 코드 중 SEED 구현 부분과 PHP SEED 구현체를 side-by-side로 띄워두고 찬찬히 비교해 보기 시작했다.

그러다 좀 이상한 부분을 발견했는데, PHP SEED 구현체는 입력된 Preshared key와 바이너리 데이터를 4바이트 단위로 잘라서는 int32 형태로 패킹하고, 리틀 엔디안인 경우 int32값에 엔디안 스왑을 진행한 뒤 복호화 라운드를 시작하는 것이다. 엥?

KISA 참조문서를 확인해 보면, SEED 알고리즘은 x86 구조를 기본으로 하여 리틀 엔디안을 고려하여 설계되어 있다고 되어 있긴 하다. 근데 이건 어디까지나 각종 상수값들이 저장되는 방식, 내지는 라운드 내에서 int32 단위로 bitwise 연산을 할 때 적용되는거지... 입력 데이터는 바이트 스트림이라 엔디안 고려할 필요가 없는데? 아니 게다가 기본값이 리틀 엔디안인데, 리틀 엔디안일 때 바이트 스왑을 한다? 대체 뭐야 혼란스럽기 끝이 없다.

결국 생각을 관두기로 하고, 구현체에 되어 있는 그대로 옮기기로 했다. Preshared key와 입력 바이너리 데이터를 4바이트 단위로 잘라서 flip하고 다시 묶어서 cryptography 패키지에 넘겨주도록 코드를 수정하였다.

from cryptography.hazmat.primitives.ciphers import Cipher
from cryptography.hazmat.primitives.ciphers.algorithms import SEED
from cryptography.hazmat.primitives.ciphers.modes import ECB


def endian_flip(_in: bytes) -> bytes:
    return b"".join(_in[i:i + 4][::-1] for i in range(0, len(_in), 4))


MCASH_PRESHARED_KEY = b"SUPERSECRET23456"
SEED_PRESHARED_KEY = b"".join(
    map(lambda c, m: c ^ m,
        MCASH_PRESHARED_KEY,
        range(1, len(MCASH_PRESHARED_KEY)+1)
    )
)
cipher = Cipher(SEED(endian_flip(SEED_PRESHARED_KEY)), ECB())


def pg_decode(ciphertext: str) -> bytes:
    ciphertext = endian_flip(bytes.fromhex(ciphertext))
    decryptor = cipher.decryptor()
    plaintext = decryptor.update(ciphertext)
    plaintext += decryptor.finalize()
    return endian_flip(plaintext)


def pg_callback(form_data):
    # some mysterious code block
    auth_name = pg_decode(form_data.get("Name"))
    auth_phone = pg_decode(form_data.get("Number"))
    # some mysterious code block

그 결과 복호화 성공. 물론 이렇게 복호화 된 문자열은 EUC-KR (내지는 MS CP949) 인코딩이므로, 이를 별도로 UTF-8로 변환해 줘야 한다. 다행히 파이썬에서는 bytes.decode("euc-kr") 한 줄이면 해결 가능하다.

웨 이렇게 표준과 어긋나게 만든 구현체를 아직까지 쓰는지 도통 알 수 없는 일이며, 더 좋은 알고리즘이 나왔는데도 그냥 SEED-128에 안주하는지도 알 수 없는 일이다. 2021년에 PHP 5.x 시절의 문법으로 만들어진 예제 코드가 제공되는 것이라던지, 예제 코드가 ASP JSP PHP만 제공되는 것이라던지 여전히 EUC-KR을 사용하는 부분이라던지, 여하튼 한국 IT시스템의 지하7층 20년간 열어본 적 없는 관리패널을 뜯어 본 기분이었다.

그나마 이런 삽질을 12시간 넘어가기 전에 끝마친 나 자신에게 위로의 말을 한 마디 해 주면서 기록을 마친다.

** 본 문서에서 제공되는 코드는 참조 목적으로만 사용해야 하며, 저자는 본 문서에서 제공되는 코드가 문제 없이 작동함을 보증하지 않습니다. 본인 책임 하에 사용하십시오.

다행히 요즘 나오는 거의 모든 메인보드와 공유기는 Wake-on-LAN 기능을 지원한다. 기술적 원리는 넘어가기로 하고, 여하튼 24/7 켜져 있는 공유기 관리자 페이지에서 버튼 몇 번만 클릭하면 컴퓨터 전원을 켤 수 있다.

그런데 이게 안 된다. 메인보드 설정에서 WOL 관련 기능을 모두 켜 주고, 윈도우에서 LAN카드 드라이버도 최신으로 바꿔주고, WOL 설정도 다 체크해 봤지만 안 된다. 허허 뭐가 문제일까.

일단 절전 모드에서는 WOL 기능이 작동한다. 그런데 내가 원하는 건 시스템 종료 상태에서도 WOL 기능이 작동하는 것이다. 왜 안될까... 하고 컴퓨터 뒷면을 관찰해 보니, 절전 모드에서는 LAN카드의 LED가 반짝거리지만, 시스템 종료 상태에서는 LAN카드가 꺼진다. 전원이 완전히 차단된다는 것이다. 윈도우 7 시절에는 그러지 않았던 것 같은데?

검색을 조금 해 보니, 윈도우 10은 전원 설정에서 빠른 시작을 꺼 줘야 WOL이 작동한댄다. 허허 진짜? 하고 빠른 시작을 껐더니 어 된다. 전원 종료 상태에서도 LAN카드의 LED가 켜져 있고, WOL 기능도 작동한다. 일단 증세는 해결. 대부분은 여기에서 끝나겠지만, 뭐가 원인인지 궁금하여 검색을 좀 더 해 봤다.

윈도우 트러블슈팅 사이트에서 Wake on LAN (WOL) behavior in Windows 10 라는 글을 발견했다. 왜 이런 문제가 발생하는지 자세히 설명이 되어 있다.

요약하면 다음과 같다.

1. 윈도우 10에서 빠른 시작이 켜져 있을 때 시스템 종료를 누르면 하이브리드 셧다운(S4) 상태로 진입하게 된다. 이 상태는 사용자 세션은 종료되지만, 윈도우 커널은 하이버네이트 상태로 살아 있는 상태이다.
2. 사용자가 시스템 종료를 선택하는 목적은 완전한 전원 끄기(전원을 분리해도 되는 상태) 이므로, 의도치 않은 시스템 재시작을 방지하기 위해 하이브리드 셧다운 상태에서는 명시적으로 WOL 기능을 꺼 버린다.
3. 따라서 윈도우 10에서는 절전 모드(S3)나 최대 절전 모드(S4) 에서만 공식적으로 WOL을 지원한다.
4. 위 2항과 같은 이유로, 종래의 셧다운(S5) 단계에서 윈도우는 WOL 기능을 지원하지 않는다. 다만, S5 단계에서는 윈도우 커널이 완전히 종료된 상태이므로, 메인보드 설정에 따라 대기 전력이 LAN카드에 공급될 수 있고, 이 경우 (윈도우와는 무관하게) WOL이 작동할 수 있다.

허허... 좀 이해가 안 되긴 하지만, 여하튼 윈도우는 시스템 종료 상태에서는 WOL을 지원하지 않는다는 것이다. 다만 빠른 시작을 사용하지 않으면, 메인보드 기능에 따라 WOL을 쓸 수는 있다고 한다. 그래서 빠른 시작을 끄면 WOL이 된다는 결론이다.

굳이 빠른 시작을 켜 둔 상태로 WOL을 사용하고 싶다면, 시스템 종료 대신 절전 모드나 최대 절전 모드를 쓰면 된다. 빠른 시작을 ON/OFF 해 보면서 체감 성능차이를 보고 결정하면 되겠다.

우선 일반적인 방법으로 사용자 계정을 생성한다. 이 때 입력하는 암호는 임시로 쓸 암호로, 나중에 지울거다.

# adduser nopassuser
Adding user `nopassuser' ...
Adding new group `nopassuser' (1001) ...
Adding new user `nopassuser' (1001) with group `nopassuser' ...
Creating home directory `/home/nopassuser' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for nopassuser
Enter the new value, or press ENTER for the default
        Full Name []: No Password
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] y

이제 해당 유저로 로그인 해서 키 쌍을 생성하고, 공개키 방식으로 로그인 할 수 있도록  authorized_keys 파일도 만들어 준다. 왜인지 모르겠지만 윈도우에서 openssh 포맷 인식이 잘 안 되어, pem 포맷을 사용하였다.

# su -l nopassuser
nopassuser@host$ ssh-keygen -t rsa -m pem
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nopassuser/.ssh/id_rsa):
Created directory '/home/nopassuser/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nopassuser/.ssh/id_rsa
Your public key has been saved in /home/nopassuser/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:~~~~ nopassuser@host
The key's randomart image is:
+---[RSA 3072]----+
|.................|
+----[SHA256]-----+
nopassuser@host$ cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

이제 개인키 파일(~/.ssh/id_rsa)을 적당히 안전한 장소에 복사해 둔다. 패스워드 날리고 나면 그 유저는 잠긴 상태가 되고, 비밀번호를 재설정 해야 다시 사용할 수 있다. 뭐 루트 권한이 있는데 못 볼 것도 없긴 하다.

이제 로그아웃 하고, 해당 유저의 패스워드를 날리고, 패스워드 만료 설정을 해 준다.

nopassuser@host$ logout
# passwd --delete --expire nopassuser
passwd: password expiry information changed.

이제 해당 사용자는 패스워드가 없으므로(--delete) 패스워드 인증으로는 로그인 불가하며, 공개키 인증으로만 로그인할 수 있다. 또한 패스워드가 만료되었으므로(--expire) 다음 번 로그인 할 때 반드시 암호를 변경해야 한다. 이제 개인키 파일을 계정 사용자에게 전달해 주면 된다.

이렇게 설정된 계정에 로그인 하면 어떤 일이 벌어질까? 직접 해 보자.

$ ssh -i id_rsa nopassuser@host
You are required to change your password immediately (administrator enforced)
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-62-generic x86_64)

 * Documentation:  <https://help.ubuntu.com>
 * Management:     <https://landscape.canonical.com>
 * Support:        <https://ubuntu.com/advantage>

8 updates can be installed immediately.
0 of these updates are security updates.
To see these additional updates run: apt list --upgradable

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

WARNING: Your password has expired.
You must change your password now and login again!
New password:
Retype new password:
passwd: password updated successfully
Connection to host closed.

패스워드가 만료되었으니 강제로 패스워드 설정이 진행되며, 기존 패스워드가 없으므로 새 패스워드만 물어본다. 강제로 접속이 끊어지지만 다시 접속하면 된다.

몇 달간 잘 쓰던 VirtualBox가 갑자기 작동을 안 한다. 우분투 ISO를 넣고 전원을 켜면 파일 검사를 완료한 뒤 얼어버린다. 뭐가 문제냐 하고 Safe mode로 부팅해 보니 커널 패닉이 뜬다. 알아볼 수 있는 메시지는 딱 한 줄 뿐...

kernel panic not syncing fatal exception

이래저래 검색해 본 결과, VirtualBox NEM (Native Execution Manager)을 사용하면 문제가 생긴댄다. 이걸 구분하는 방법은 가상 머신 창 아래쪽을 보면 된다. 아래 그림처럼 V자 모양을 등에 단 거북이 모양이 보인다면 NEM을 사용하는 상태이다.

Native Execution 이라고 되어 있지만 사실 NEM은 VBox에서 제공하는 가상화 엔진이 아니다. OS에서 제공하는 네이티브 엔진이며 윈도우에서는 Hyper-V가 이에 해당한다.

그럼 왜 VBox 자체 엔진 냅두고 NEM으로 실행될까? 찾아보니 WSL2가 Hyper-V를 이용하기 때문에 문제가 된다고 한다. WSL2 커널을 실행시키기 위해 Hyper-V가 Type-1 하이퍼바이저로 작동하여, 윈도우 커널부터 가상 머신 위에서 돌린다는 모양이다. Hyper-V가 중첩 가상화를 지원하는지는 모르겠지만, 여하튼 이미 Hyper-V가 가상화 기능을 점유한 상태이기 때문에 VBox나 VMware의 자체 가상화 엔진을 사용할 수 없다.

이 문제를 해결할 수 있도록, WHP (Windows Hypervisor Platform)를 지원한다고 한다. 이를 이용하면 서드파티 소프트웨어 에서도 Hyper-V 엔진으로 가상 머신을 작동시킬 수 있다는 것이고, 이게 VBox에서는 NEM이라는 이름으로 구현된 것이다. 참고로 VMware와 Docker Windows도 WHP를 이용하여 Hyper-V 엔진으로 가상 머신을 작동시킬 수 있다.

그러고 보니 회사 컴퓨터를 세팅할 때부터 WSL2를 깔아 두었고, VBox에서는 계속 거북이 아이콘만 봐 왔던 것 같다. 여하튼 NEM을 사용하는 경우, 안정성이 영 구린 것인지 잘 쓰던 가상 머신이 어느 날 갑자기 커널 패닉을 일으킬 수 있다고 한다. 게스트 OS로 윈도우를 써도 원인모를 프리징이 발생한다니 뭐... 별 수 있나.

그럼 어떻게 해야 VBox 엔진을 다시 사용할 수 있을까? 결론부터 말하자면 Hyper-V 를 끄면 된다. 그렇게 하면 VBox가 CPU 가상화 기능을 사용할 수 있게 되어, NEM을 사용할 필요가 없어진다. 거북이 아이콘도 CPU 가상화를 뜻하는 V 아이콘으로 돌아온다.

1. 설정 - 앱 및 기능 메뉴에 들어가서 우선 설치되어 있는 WSL 리눅스 배포판을 모두 삭제한다.
2. 위 메뉴에서 선택적 기능 - 기타 Windows 기능을 선택한다. 또는 실행 메뉴에서 OptionalFeatures.exe 을 실행해도 된다.
3. 다음 항목에 있는 체크박스를 모두 해제한다.
   - Hyper-V
   - Linux용 Windows 하위 시스템
   - 가상 머신 플랫폼
4. 확인을 누르면 윈도우에서 Hyper-V 관련 기능이 모두 삭제된다. 삭제 과정이 완료되면 재부팅한다.

다만 이렇게 하면, WHP에 의존하는 WSL2나 Docker Windows는 사용할 수 없게 된다. VMware야 자체 엔진이 있으니 상관없지만.

파이썬 가상 환경?

시작하기 전에 파이썬 가상 환경이 무엇인지 정의하고 넘어가자. 파이썬 공식 문서의 용어 설명을 보면 다음과 같이 정의되어 있다.

A cooperatively isolated runtime environment that allows Python users and applications to install and upgrade Python distribution packages without interfering with the behaviour of other Python applications running on the same system.

• 상호 협조적으로 격리된 런타임 환경
• 파이썬 사용자와 애플리케이션이 파이썬 배포 패키지를 설치하거나 업그레이드 할 수 있게 함
• 이 과정에서 같은 시스템에 설치된 다른 파이썬 애플리케이션의 동작을 방해하지 않음

즉, 가상 환경이란 다른 가상 환경과 영향을 주고받지 않도록 격리된 파이썬 실행 환경을 의미한다. 실행 환경에는 1)특정 버전의 파이썬 실행 파일과 기본 라이브러리, 그리고 2)사용자 코드 또는 애플리케이션이 요구하는 특정 버전의 패키지 및 모듈이 포함된다.

물론 더 넓은 범위로는 시스템에 설치된 외부 시스템 라이브러리 등도 포함되겠지만, 여기까지 관리하려면 docker 같은 프로세스 수준 컨테이너를 사용해야 한다.

파이썬 가상 환경의 원리

파이썬 인터프리터를 실행할 때, 각종 패키지를 불러오는 경로는 sys.path 변수에 저장된다. 이 목록에는 기본으로 진입점 스크립트(.py 파일)의 경로와 PYTHONPATH 환경 변수에 지정된 경로, 그리고 파이썬 기본 라이브러리 경로와 패키지 디렉터리(site-packages 디렉터리) 경로를 포함하게 된다.

그렇다면 site-packages 디렉터리 경로를 적절히 변경해 주면 어떻게 될까. 예를 들어 A 프로젝트를 실행할 때에는 A/lib/site-packages 디렉터리를 사용하고, B 프로젝트를 실행할 때에는 B/lib/site-packages 디렉터리를 사용하는 것이다. 두 디렉터리는 서로 다른 경로이므로 서로 영향을 주지 않는다. 위에서 기술한 대로 가상 환경이 되는 것이다. 즉, 파이썬 가상 환경 구현의 기본은 sys.path 환경 변수를 조작하는 작업이다.

sys.path 환경 변수를 애플리케이션 진입점 스크립트에서 직접 조작할 수도 있다. 파이썬 1.x 때, 패키지라는 개념 없이 외부 의존성을 모조리 프로젝트 내부에 때려 넣었던 시절에 쓰던 방법이다. 파이썬 버전이 올라가면서 패키지 디렉터리 개념이 도입되고, 이를 자동으로 sys.path 에 추가해 주는 site 모듈이 도입되었다.

이후 파이썬 인터프리터 자체에서 pyvenv.cfg 를 이용한 가상 환경 지원이 추가되어 현재에 이르고 있다. 현재는 최소한의 파이썬 실행 파일을 복사하고, 전용 site-packages 디렉터리를 생성한 뒤 pyvenv.cfg 파일을 만들어서 파이썬 가상 환경을 구성할 수 있다.

하나의 파이썬 버전에서 가상 환경 만들기

시스템에 설치된 파이썬 설치본을 바탕으로, 가상 환경을 여러 개 만들어서 사용하려는 경우이다.

관리해 주는 툴 : virtualenv, python-venv, virtualenvwrapper, pipenv, conda

tl; dr

pipenv 쓰자.

virtualenv / python-venv

virtualenv 는 파이썬에서 가상 환경을 지원하기 전부터 개발되어 온 가상 환경 관리 애플리케이션이다. 파이썬 버전 관리 애플리케이션을 파이썬으로 만들다니 일종의 순환 참조라 할 수 있겠다. (이런 순환 참조의 최초 설치 과정을 부트스트래핑이라고 한다.)

virtualenv 가 파이썬 개발자에게 거의 상식처럼 통용되다 보니, 파이썬에서 가상 환경에 대한 지원을 추가하면서 virtualenv 의 핵심 기능을 따온 python-venv 시스템 모듈을 만들었다. 둘 다 pyvenv.cfg 에 의존하기에, 어느 것을 사용하건 가상 환경 생성이라는 핵심 기능에는 차이가 없다.

아래에 나오는 virtualenvwrapper 와 pipenv 는 가상 환경을 생성할 때 내부적으로  virtualenv 를 사용한다.

virtualenvwrapper

virtualenv 로 가상 환경을 만든 건 좋은데, 사용 하다 보니 불편한 점이 발생한다. 프로젝트 디렉터리 아래에 가상 환경을 생성하게 되면, IDE나 버전 관리에서 이를 수동으로 제외해 주어야 한다. 프로젝트 디렉터리에 진입할 때마다 수동으로 activate 스크립트를 실행해야 한다. 현재 생성해 둔 가상 환경의 목록을 한 번에 확인할 방법이 없다. 기타등등...

virtualenvwrapper 는 이런 불편함을 해소해 주는 쉘 스크립트이다. 가상 환경을 홈 디렉터리 아래의 일정한 경로(기본값으로 ~/.virtualenvs/)에 생성하고, 가상 환경 활성화와 동시에 프로젝트 경로로 이동하는 workon {venv} 명령어를 제공하는 등 편의 기능을 구현하고 있다.

pipenv

virtualenv 는 가상 환경을 관리하고, pip 는 패키지를 관리한다. 그런데 가상 환경이 패키지 목록을 포함하는 개념인데, 굳이 두 개의 툴을 나누어 사용할 필요가 있을까?

그 둘을 합친게 pipenv 이다. 가상 환경 관리와 패키지 버전 관리 기능을 동시에 제공한다. 가상 환경은 virtualenvwrapper 와 같이 ~/.virtualenvs/ 디렉터리로 모아 주며, 프로젝트의 경로를 해싱을 사용해서 가상 환경을 자동으로 선택해 준다. 가상 환경을 활성화 하려면 프로젝트 디렉터리 내에서 pipenv shell 명령어를 사용하면 된다. 연결되는 가상 환경 이름을 지정하지 않아도 되므로 편리하다.

또한 pip 에서는 지원하지 않는 패키지 버전 잠금(locking)을 지원하므로, 가상 환경을 다시 만들 때 의존성 패키지 버전을 완전히 재현할 수 있다.

파이썬 버전을 여러 개 써야 할 때

관리해 주는 툴 : 시스템 패키지 관리자, pyenv

개발을 하다 보면 파이썬 버전 자체를 여러 개 설치해야 하는 때가 있다. 예를 들어 라이브러리 패키지를 개발하는 경우, 여러 파이썬 버전에서 잘 작동하는지 테스트 해야 하니 파이썬 버전이 서로 다른 가상 환경이 필요하다.

tl; dr

pyenv-virtualenv 를 쓰거나, pyenv + pipenv 쓰자.

패키지 관리자 / 직접 파이썬 빌드하기

데비안 계열 배포판은 apt, 레드햇 계열 배포판은 yum 등의 패키지 관리자를 사용하여 미리 빌드된 파이썬을 손쉽게 설치할 수 있다. 이 때 버전을 명시하여 파이썬 버전을 여러 개 설치할 수 있다. 원하는 파이썬 버전이 제공되지 않는다면 소스 코드를 직접 다운로드 받아서 빌드하는 방법도 있다.

이렇게 시스템에 여러 버전의 파이썬이 설치된 경우, 특정 버전의 파이썬을 실행하고자 한다면 pythonX.Y 명령어로 실행할 수 있다. 예를 들어 파이썬 3.9를 명시하여 실행하려면 python3.9 로 실행하면 된다.

다만 패키지 관리자를 사용하려면 시스템 관리자 권한을 필요로 하며, 또 직접 빌드한 실행 파일을 /usr/local 아래에 설치하는 경우 시스템 전역에서 접근 가능하게 된다. 즉, 다른 애플리케이션에 영향을 줄 수 있다. 이렇게 설치한 파이썬 설치본은 가상 환경이 아니므로 주의하자.

시스템에 파이썬 버전이 여러 개 설치되어 있는 경우, virtualenv 또는 pipenv 에 옵션으로 파이썬 버전을 명시하여 가상 환경을 생성할 수 있다. python-venv 는 애당초 파이썬 모듈로 실행되니까 버전을 명시할 수밖에 없다.

pyenv

pyenv 는 여러 파이썬 버전을 설치하는 과정을 안전하게 자동화 해 준다. 홈 디렉터리 아래(기본값 ~/.pyenv/versions)에 여러 버전의 파이썬을 설치할 수 있으며, 파이썬 버전을 자유롭게 선택하여 사용할 수 있다.

또한 PATH 환경 변수를 조작하는 activation 과정이 필요 없다. 파이썬 실행 명령어를 중간에 낚아 채서 어느 버전을 실행할 지 결정하기 때문이다. 이런 방법을 shim 이라고 한다.

프로젝트 디렉터리 내에 .python-version 파일을 만들어 파이썬 버전을 지정해 두면 자동으로 이를 인식하여 적절한 파이썬 버전을 선택해 준다. .python-version 파일이 지정된 디렉터리로 진입하면 자동으로 설정이 반영되는 것을 볼 수 있다.

pyenv 자체는 쉘 스크립트로 작성되어 부트스트래핑이 필요 없다. 그리고 쉘 스크립트라 윈도우에서는 작동하지 않는다. 이를 윈도우 용으로 포팅한 pyenv-win 프로젝트가 따로 존재한다.

pyenv-virtualenv

pyenv 는 파이썬 버전을 여러 개 설치할 수 있게 해 줄 뿐, 가상 환경을 만들어 주지는 않는다. 파이썬 버전별로 가상 환경까지 관리하려면 pyenv-virtualenv 플러그인을 사용하면 된다.

pyenv-virtualenv 는 파이썬 버전별로 envs 디렉터리를 만들고 그 밑에 가상 환경을 만들어 주므로, 깔끔하게 정돈된 결과를 얻을 수 있다. 또한 .python-version 파일에 가상 환경 이름을 지정해 두면 해당 디렉터리로 진입할 때 이를 인식하여 잘 반영해 준다. 아주 편리하다. pyenv-virtualenv 는 가상 환경을 생성하는데 virtualenv 와 python-venv 를 모두 지원한다.

pyenv-win 은 아직 pyenv-virtualenv 플러그인을 지원하지 않는다. 윈도우 사용자는 아직 손가락 빨면서 기다려야 한다.

pyenv-virtualenvwrapper

virtualenvwrapper 쉘 스크립트가 pyenv 와 함께 작동할 수 있도록 해 주는 플러그인이다. pyenv-virtualenv 나 pipenv 로 이전하는 걸 권장한다.

pyenv + pipenv

pyenv 가 설치되어 있으면 pipenv 는 자동으로 이를 인식하여 연동한다. 파이썬 버전을 지정하여 가상 환경을 생성할 때, 해당 버전이 아직 설치되지 않았다면 pyenv 를 이용하여 설치할 지 물어본다.

pyenv 를 지원하지만, pipenv 로 생성한 가상 환경은 여전히 ~/.virtualenvs 디렉터리에 생성된다. 따라서 pipenv 를 사용한다면 일관되게 pipenv shell 명령어를 사용하면 된다. .python-version 파일로 가상 환경을 지정할 수 없다.

pipenv 자체는 윈도우에서도 작동하지만, pyenv-win 과 호환되지는 않는다. 윈도우 사용자는 아직 손가락 빨면서 기다려야 한다.

conda

Anaconda Inc.에서 배포하는 파이썬/R(통계학 언어) 패키지 매니저이다. 일단은 오픈소스로 배포되지만, 일부 확장 기능이나 유료 패키지는 유료 구독에 가입해야 사용할 수 있다. 여하튼, 파이썬 가상 환경 관리와 패키지 매니저 기능은 오픈 소스로 누구나 쓸 수 있다.

conda 명령어를 이용하여 가상 환경을 생성하면서, 파이썬 버전을 지정해 줄 수 있다. 이 때 Anaconda Inc. 에서 배포하는 버전이 설치된다. 사실 conda 는 파이썬의 pyvenv.cfg 를 이용한 가상 환경을 사용하지 않고, 그냥 파이썬 설치본을 통째로 복사하여 가상 환경을 만든다. 이건 파이썬이 pyvenv.cfg 를 지원하기 전에 사용하던 방법이다.

가상 환경은 ~/.conda/envs 디렉터리에 모아서 관리되며, 별도의 메타데이터를 이용하여 파이썬 버전과 패키지를 모두 관리해 준다. 가상 환경 활성화는 conda activate {venv} 명령어를 사용하여 수동으로 진행하여야 한다.

Anaconda Inc. 에서 저장소를 관리하기 때문에, 일부 패키지가 없거나 또는 오래된 버전이 설치될 수 있다. 그리고 conda 패키지 관리자와 pip 가 서로 충돌을 일으키는 경우도 있다. 대체로 문제가 발생하지는 않지만, 일단 문제가 발생하면 해결이 참 어렵다. 그냥 가상 환경을 삭제하고 새로 만드는게 편할 정도다.

참고로 Anaconda에서 배포하는 파이썬 버전도 pyenv 를 이용해서 설치할 수 있고, 그 안에서 conda 명령어를 사용할 수도 있다. pyenv 로 설치한 파이썬 인터프리터에서 virtualenv 를 사용할 수 있는 것과 같은 원리다. 물론 그렇게 써서 얻는 이득은 별로 없다.

윈도우 환경에서 파이썬 버전을 여러 개 설치하려면 아직은 conda 가 가장 편리하다. pyenv-win 이 제약이 많기 때문이다. WSL은 리눅스 환경이니까 별도로 생각하자.

docker

파이썬 가상 환경을 관리하는데 도커는 별로 인기가 없다.  파이썬 애플리케이션 개발에서 도커를 이용한 격리는 주로 배포 단계에서 파이썬 환경까지 통째로 배포하려는 목적으로 사용하는 것 같다.

물론 개발 환경으로 못 쓰는 것도 아니다. 프로세스 수준에서 격리가 이루어지며, 파일 시스템도 완전히 격리가 이루어지므로 가장 깔끔한 환경을 얻을 수 있다. 다만 호스트와 연동이 잘 안 되어 IDE 연동이나 디버거 사용이 잘 안 될 수 있다. 역시 도커는 배포용이다.

우선 마운트 하려는 파티션의 시작 위치를 찾아야 한다. fdisk를 이용하여 이미지 파일 내부의 파티션 구조를 출력한다. 예제로 사용한 파일은 라즈베리파이OS 라이트 버전(2020년 12월)이다. GPT 방식으로 배포되는 이미지는 gdisk 를 사용하면 된다.

$ fdisk -l path/to/image/2020-12-02-raspios-buster-armhf-lite.img
Disk 2020-12-02-raspios-buster-armhf-lite.img: 1.75 GiB, 1858076672 bytes, 3629056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x067e19d7

Device                                    Boot  Start     End Sectors  Size Id Type
2020-12-02-raspios-buster-armhf-lite.img1        8192  532479  524288  256M  c W95 FAT32 (LBA)
2020-12-02-raspios-buster-armhf-lite.img2      532480 3629055 3096576  1.5G 83 Linux

여기에서 논리 섹터의 크기, 그리고 마운트 하려는 파티션의 시작 섹터(Start) 위치를 확인한다. 예를 들어, 위 이미지에서 논리 섹터 크기는 512 bytes이고, 첫 번째 파티션은 8192번 섹터에서 시작한다. 계산기를 두드려 보아도 좋고, 후술할 방법으로 쉘 문법으로 바로 계산해 넣을 수도 있다.

이제 마운트 명령어를 주면 된다. 이 때 옵션으로 loop mount를 주고, offset으로 파티션의 오프셋 값을 주면 된다. 8192는 위에서 확인한 시작 섹터 위치이며, 512는 논리 섹터의 크기이다.

$ sudo mount -o loop,offset=$((8192*512)) path/to/image_file.img /mnt/boot

두 번째 파티션을 마운트 하려면 다음처럼 주면 된다. 원리는 같다.

$ sudo mount -o loop,offset=$((532480*512)) path/to/image_file.img /mnt/sdroot