이번 글에서는 이 메시지의 의미와, 필요할 경우 무료 개인 구독을 등록하는 방법을 정리해보겠다.

내가 확인한 메시지는 다음과 같다.

ubuntu@instance-1:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Get another security update through Ubuntu Pro with 'esm-apps' enabled:
  rclone
Learn more about Ubuntu Pro at https://ubuntu.com/pro
The following upgrades have been deferred due to phasing:
  fwupd libjcat1 libxmlb2
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
ubuntu@instance-1:~$

눈에 띄는 부분은 이 문장이다.

Get another security update through Ubuntu Pro with ‘esm-apps’ enabled: rclone

이 메시지는 현재 시스템에 설치된 rclone 패키지에 대해 추가 보안 업데이트가 준비되어 있지만, 그 업데이트는 Ubuntu Pro의 esm-apps를 활성화해야 받을 수 있다는 뜻이다.

참고로 바로 아래의 The following upgrades have been deferred due to phasing는 별개의 메시지다. fwupd, libjcat1, libxmlb2가 단계적 배포(phasing) 때문에 잠시 보류되었다는 의미이지, Ubuntu Pro와 직접 관련된 것은 아니다.

Ubuntu Pro는 Canonical이 제공하는 확장 보안 유지보수 서비스다. 공식 문서 기준으로 개인 사용자는 최대 5대까지 무료로 사용할 수 있고, Ubuntu Community Member라면 최대 50대까지 무료 혜택을 받을 수 있다. 필수는 아니므로 그냥 넘어가도 된다. 다만 보안 업데이트 범위를 넓히고 싶다면 등록해두는 편이 좋다.

먼저 Ubuntu Pro 페이지에 접속해서 Get Ubuntu Pro now 버튼을 클릭한다.

Ubuntu Pro의 주요 기능은 다음과 같다.

• esm-infra: Ubuntu Main 저장소 패키지에 대한 보안 유지보수 기간 연장
• esm-apps: Universe 저장소를 포함한 더 넓은 범위의 패키지 보안 업데이트 제공
• livepatch: 재부팅 없이 커널 보안 패치 적용 가능
• 각종 보안 컴플라이언스, 감사, 관리 도구 제공

즉, 기본 LTS 지원만으로는 놓칠 수 있는 패키지까지 보안 업데이트 범위를 넓혀주는 서비스라고 이해하면 된다.

Ubuntu One 계정으로 로그인한 뒤 구독 대상을 Myself로 선택하고 Register를 클릭한다. 계정이 없다면 먼저 계정 생성이 필요하다.

등록이 끝나면 토큰과 함께 Command to attach a machine 명령어가 나온다. 이 명령어를 복사해서 우분투 서버에서 실행하면 된다.

실행 결과는 다음과 비슷하다.

ubuntu@instance-1:~$ sudo pro attach C###@@@!!!###$$$%%%&&&((()))##
Enabling Ubuntu Pro: ESM Apps
Ubuntu Pro: ESM Apps enabled
Enabling Ubuntu Pro: ESM Infra
Ubuntu Pro: ESM Infra enabled
This machine is now attached to 'Ubuntu Pro - free personal subscription'

SERVICE          ENTITLED  STATUS       DESCRIPTION
anbox-cloud      yes       disabled     Scalable Android in the cloud
esm-apps         yes       enabled      Expanded Security Maintenance for Applications
esm-infra        yes       enabled      Expanded Security Maintenance for Infrastructure
fips-updates     yes       disabled     FIPS compliant crypto packages with stable security updates
landscape        yes       disabled     Management and administration tool for Ubuntu
realtime-kernel* yes       disabled     Ubuntu kernel with PREEMPT_RT patches integrated
usg              yes       disabled     Security compliance and audit tools

 * Service has variants

NOTICES
Operation in progress: pro attach

For a list of all Ubuntu Pro services and variants, run 'pro status --all'
Enable services with: pro enable <service>

     Account: test@gmail.com
Subscription: Ubuntu Pro - free personal subscription
ubuntu@instance-1:~$

여기까지 나오면 등록은 끝난다. 이후 sudo apt upgrade를 다시 실행하면, 앞서 Ubuntu Pro 안내만 표시되던 패키지가 실제 업데이트 대상에 포함되는 것을 확인할 수 있다.

정리하면 apt upgrade 중 Ubuntu Pro 관련 문구가 보인다고 해서 시스템에 문제가 생긴 것은 아니다. 기본 LTS 보안 지원 범위를 넘어서는 추가 보안 업데이트가 있다는 뜻이다. 개인 서버나 개인 프로젝트용 우분투를 운영 중이라면 무료 구독만으로도 충분히 활용할 만하다.

오늘은 Git 저장소에 쌓인 잔재와 미사용 대용량 캐시를 한 번에 정리해 저장소 용량을 최적화하는, 이른바 “Git 대청소 명령어 조합”을 소개한다.

한 줄로 실행하는 Git 대청소 명령어

프로젝트의 Git 루트 폴더에서 아래 명령어를 실행하면 된다.

git reflog expire --expire=now --all && git fetch && git pull && git gc --prune=now && git lfs prune

각 명령어가 실제로 어떤 역할을 하는지 순서대로 살펴보자.

명령어 상세 분석

1) 연결 고리 끊기: git reflog expire

git reflog expire --expire=now --all

Git은 git reset이나 브랜치 삭제 이후에도 reflog에 작업 이력을 일정 기간(기본 약 90일) 보관한다. 문제는 이 기록이 디스크 용량을 계속 차지한다는 점이다.

--expire=now --all은 이 보관 이력을 즉시 만료 처리한다. 즉, 아직 객체는 남아 있어도 “더 이상 되살릴 근거가 없는 상태”로 만들어 이후 정리 단계에서 제거 가능하게 만든다.

2) 최신 상태 동기화: git fetch + git pull

git fetch && git pull

본격적인 정리 전에 원격 저장소 기준 최신 상태로 동기화하는 단계다. 정리 직전 기준점을 맞춰두면, 불필요한 불안 요소를 줄이고 작업 안정성을 높일 수 있다.

3) 물리적 삭제 및 압축: git gc

git gc --prune=now

Git의 GC(Garbage Collection)를 강제 실행한다. 앞 단계에서 만료 처리된 객체 중 도달 불가능한 데이터들을 실제 디스크에서 삭제하고, 남은 객체들은 packfile로 재정렬/압축한다.

결과적으로 .git 용량 감소뿐 아니라 저장소 성능(객체 조회, 전송 효율)에도 도움이 된다.

4) 대용량 파일 캐시 정리: git lfs prune

git lfs prune

Git LFS를 사용하는 저장소라면 사실상 필수 단계다. 과거 체크아웃에서 내려받은 대용량 LFS 객체 로컬 캐시가 누적되어 용량을 크게 잡아먹기 때문이다.

git lfs prune은 현재 기준으로 더 이상 필요 없는 오래된 LFS 로컬 객체를 정리한다. 원격 LFS 저장소 데이터가 지워지는 것은 아니므로, 일반적인 사용에서는 안전하다.

실행 전 주의사항 (필독)

아래 항목은 반드시 확인하고 실행하자.

1. 복구 불가능성 reflog를 만료하고 gc --prune=now까지 실행하면, 실수로 지운 커밋/브랜치를 되살릴 여지가 크게 줄어든다. 사실상 로컬 타임머신을 비우는 작업이다.

2. 미푸시 작업 백업 원격에 올리지 않은 커밋이 있다면 먼저 git push로 보호하자. 중요한 변경은 별도 백업 브랜치/태그를 만들어 두는 것을 권장한다.

3. 깨끗한 작업 상태 권장 정리 작업은 충돌 요인이 적은 상태에서 하는 것이 좋다. 가능하면 작업 중인 변경이 없는 클린 상태에서 실행하자.

마무리

이 명령어 조합을 주기적으로 사용하면 비대해진 .git 폴더가 눈에 띄게 줄어드는 경우가 많다. 특히 CI/CD 빌드 서버 디스크가 빠듯하거나, 대용량 에셋 교체가 잦은 프로젝트를 운영한다면 꽤 체감이 크다.

필요할 때마다 아래 한 줄만 기억해도 된다.

git reflog expire --expire=now --all && git fetch && git pull && git gc --prune=now && git lfs prune

문제의 코드는 대략 이런 형태였다.

RzVoid RzBuffManager::DetachPropBuff( const RzBool bOnlyPropBuff, RzKeySet& outCooltimeKeySet, RzKeySet& outBuffKeySet )
{
    static const RzBuffDeleteHandler handler = [bOnlyPropBuff]( const RzBuffDeleteParamInfo& paramInfo, const RzBuffPtr& spBuff )
    {
        if ( bOnlyPropBuff )
        {
            // blah blah...
        }
        return true;
    };

    doAnything();
}

겉으로 보기에는 큰 문제가 없어 보인다. Visual Studio 2019에서도 컴파일이 잘 되고, 실행 중에도 별다른 오류가 발생하지 않는다. 하지만 실제 동작은 기대와 달랐다.

핵심은 handler가 static이라는 점이다. 이 람다는 지역 정적 변수로 한 번만 초기화되며, 그 시점에 캡처한 bOnlyPropBuff 값도 함께 고정된다.

즉, 처음 함수가 호출될 때 bOnlyPropBuff가 true였다면 이후 호출에서 false를 넘겨도 람다 내부에서는 계속 처음 값만 사용하게 된다. 반대로 첫 호출이 false였다면 그 뒤로도 계속 false처럼 동작한다.

나는 매 호출마다 람다가 현재의 bOnlyPropBuff 값을 받아서 동작하길 기대했다. 하지만 static으로 선언된 순간, 이 람다는 “매번 새로 만들어지는 함수 객체”가 아니라 “처음 한 번 만들어진 뒤 계속 재사용되는 객체”가 되어버린다.

이런 종류의 버그가 까다로운 이유는 다음과 같다.

• 컴파일 에러가 없다.
• 런타임 크래시도 없다.
• 코드만 얼핏 보면 캡처한 값이 매번 바뀔 것처럼 보인다.

결국 해결 방법은 단순하다. 호출마다 다른 값을 반영해야 하는 람다라면 static을 제거해야 한다. 반대로 static을 유지하고 싶다면, 호출마다 변하는 값을 캡처에 의존하지 않도록 구조를 바꿔야 한다.

작은 차이처럼 보여도, static 지역 변수와 람다 캡처가 만나면 꽤 교묘한 버그가 만들어질 수 있다. 비슷한 패턴을 사용하고 있다면 한 번쯤 다시 점검해 보는 것이 좋겠다.

게임 패치를 위해 퍼블리셔에게 DB 패치 스크립트를 한데 묶어 전달했다. 서버 업데이트 당일, 모든 스크립트는 정상적으로 처리됐지만… 단 하나의 스크립트에서 모든 샤드에서 에러가 발생했다.

퍼블리셔 Tech PM이 전달해준 5천 줄짜리 로그를 샅샅이 뒤져보던 중, 눈에 띄는 메시지를 발견했다.

# [tid:19][ERROR] (1205, b'Transaction (Process ID 155) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.DB-Lib error message 20018, severity 13:\nGeneral SQL Server error: Check messages from the SQL Server\n') 201703
Exception in thread Thread-13:
Traceback (most recent call last):
  File "src/pymssql.pyx", line 448, in pymssql.Cursor.execute
  File "src/_mssql.pyx", line 1064, in _mssql.MSSQLConnection.execute_query
  File "src/_mssql.pyx", line 1096, in _mssql.MSSQLConnection.execute_query
  File "src/_mssql.pyx", line 1294, in _mssql.MSSQLConnection.get_result
  File "src/_mssql.pyx", line 1639, in _mssql.check_cancel_and_raise
  File "src/_mssql.pyx", line 1683, in _mssql.maybe_raise_MSSQLDatabaseException
_mssql.MSSQLDatabaseException: (1205, b'Transaction (Process ID 148) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.DB-Lib error message 20018, severity 13:\nGeneral SQL Server error: Check messages from the SQL Server\n')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/infra/py/woodstock/execute_batch_sql/execute_batch_all_sql_use_thread_mssql.py", line 209, in process_restore
    p_db.cursor.execute(query)
  File "src/pymssql.pyx", line 468, in pymssql.Cursor.execute
pymssql.OperationalError: (1205, b'Transaction (Process ID 148) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.DB-Lib error message 20018, severity 13:\nGeneral SQL Server error: Check messages from the SQL Server\n')

클래식한 데드락 에러였다. 조금 더 자세히 보면 다음과 같은 pymssql 예외 트레이스백도 확인할 수 있었다.

테스트할 땐 멀쩡했는데?

문제의 스크립트는 내부 QA 테스트에서는 아무런 문제가 없었다. 직접 SSMS에서 한 번에 실행했을 때는 에러도 없고, 처리 시간도 양호했다.

하지만 퍼블리셔 환경은 달랐다.
그들은 젠킨스에서 파이썬 스크립트 (pymssql)로, 멀티스레드로 동시에 각 샤드에 SQL을 실행하고 있었던 것 같다. (정확히는 확인할 수 없지만 정황상 꽤 유력하다.)

알고 보니 내가 작성한 쿼리는 다음과 같은 데드락 발생 조건을 잔뜩 갖추고 있었다:

• UPDATE ... JOIN 구문
• 여러 테이블을 동시에 수정
• UDF (사용자 정의 함수) 호출

단일 세션에서는 잘 돌아가지만, 멀티세션/멀티스레드 상황에서는 충돌이 일어날 수밖에 없었다.

해결책은 의외로 간단했다

쿼리를 리팩터링해서 테이블 접근 순서를 맞추거나, 복잡한 힌트를 주는 방법도 고려했지만…

가장 간단하고 확실한 해결책은 단독 실행이었다.

퍼블리셔 측에 “이 쿼리만은 병렬 실행하지 말고 단독으로 실행해 달라”고 요청했다. 그리고 실제로 그렇게 하자 문제는 바로 해결되었다.

마무리

데드락은 언제나 예상치 못한 상황에서 등장한다. 특히 멀티스레드 + 복잡한 쿼리 조합은 사고가 나기 쉬운 구조다.

테스트할 땐 멀쩡했는데 실서버에서만 문제가 생긴다면, “이 쿼리가 병렬 실행될 가능성은 없었을까?” 한 번쯤 되짚어보는 것도 좋은 습관이다.

병렬 프로그래밍을 조사하던 중 정렬 알고리즘에서도 최적화 여지가 있다는 것을 알게 되어 테스트해보았다.

기존 코드는 std::sort를 사용하고 있었다. 이를 concurrency::parallel_sort로 바꿀 수 있었지만, PPL은 비표준인 데다 Windows에서만 동작하는 코드였다. ChatGPT는 concurrency::parallel_sort 대신 std::sort에 std::execution::par를 조합하는 방식을 추천해주었다. (C++17 이상에서만 유효하다.)

테스트 코드

기존의 std::sort와 std::sort + std::execution::par를 비교하는 코드를 작성했다.

#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <vector>
#include <string>
#include <random>
#include <chrono>
#include <execution>
#include <iostream>
#include <locale>

int main( void )
{
	std::vector<int> vec;

	for ( auto i = 0; i < 1000000; ++i )
		vec.push_back( i );

	std::random_device rd;
	std::mt19937 engine( rd() );
	std::shuffle( vec.begin(), vec.end(), engine );

	std::vector<int> vec1 = vec;
	std::vector<int> vec2 = vec;

	{
		// 시간 측정 시작
		auto start = std::chrono::high_resolution_clock::now();

		std::sort( vec1.begin(), vec1.end(), []( auto lhs, auto rhs )
		{
			return lhs < rhs;
		} );

		// 시간 측정 끝
		auto end = std::chrono::high_resolution_clock::now();

		// 경과 시간 계산 (단위: 마이크로초)
		auto duration = std::chrono::duration_cast<std::chrono::microseconds>( end - start );

		std::cout << "실행 시간: " << duration.count() << " 마이크로초" << std::endl;
	}

	{
		// 시간 측정 시작
		auto start = std::chrono::high_resolution_clock::now();

		std::sort( std::execution::par, vec1.begin(), vec1.end(), []( auto lhs, auto rhs )
		{
			return lhs < rhs;
		} );

		// 시간 측정 끝
		auto end = std::chrono::high_resolution_clock::now();

		// 경과 시간 계산 (단위: 마이크로초)
		auto duration = std::chrono::duration_cast<std::chrono::microseconds>( end - start );

		std::cout << "실행 시간: " << duration.count() << " 마이크로초" << std::endl;
	}

	return 0;
}

배열에 int 값을 여러 개 넣고 섞은 후 다시 정렬하는 데 걸리는 시간을 측정하는 코드이다.

테스트 결과

단위는 마이크로초(μs)이다.

테스트 환경은 Intel Core i5-12400F 2.5GHz, 64GB 메모리, Visual Studio 2019 x64이다.

표를 보면 원소 개수가 300개 이하일 때는 기본 std::sort가 더 빠르다. 500개 정도부터 std::execution::par의 효과가 나타나기 시작하고, 1,000개에서는 약 절반, 10,000개 이상에서는 약 1/10 수준으로 시간이 줄어든다.

결론

원소 개수 300개 미만은 std::sort, 300개 이상은 std::sort + std::execution::par를 사용하는 것이 좋다.

아래와 같은 템플릿 함수를 만들어 사용 중이다. std::sort와 동일한 인터페이스를 유지하면서 원소 개수에 따라 정렬 전략을 자동으로 선택한다.

template<class RandomIt, class Compare>
void RzSort( RandomIt first, RandomIt last, Compare comp )
{
	auto size = std::distance( first, last );
	if ( size <= 0 )
		return;

	if ( size < 1000 )
		std::sort( first, last, comp );
	else
		std::sort( std::execution::par, first, last, comp );
}

퍼포스에는 이 기능을 담당하는 Obliterate Files 기능이 있는데, 문제는 수동으로만 동작한다는 점이다. 특정 리비전 범위를 지정해서 삭제할 수 있지만, 파일마다 일일이 처리해야 한다.

처음에는 파일을 하나씩 직접 처리했지만, 관리해야 할 파일이 많아지면서 자동으로 처리하는 배치 파일을 만들었다.

files_program.txt에 정리할 파일 목록을 넣어두면 가장 최근 5개 리비전만 남기고 나머지를 삭제한다.

Obliterate 명령은 한 번 실행하면 절대 되돌릴 수 없다. 배치 파일을 실행하기 전에 코드를 충분히 파악하고, 반드시 테스트 파일로 먼저 검증한 뒤에 실행하길 바란다.

@echo off
setlocal enabledelayedexpansion

rem 파일 목록이 저장된 파일 경로 설정
set FILE_LIST=files_program.txt

rem files.txt 파일을 한 줄씩 읽어서 처리한다.
for /f "delims=" %%a in (%FILE_LIST%) do (
	set "TARGET_FILE=%%a"
	
	rem echo !TARGET_FILE!
	
    rem 가장 마지막 리비전 번호를 구한다.
    for /f "tokens=3" %%b in ('p4 fstat -T headRev !TARGET_FILE! 2^>nul ^| find "headRev"') do set LATEST_REVISION=%%b

    rem echo !LATEST_REVISION!
	
	rem 마지막 5개 리비전이 5 초과일 때만 처리한다.
	if !LATEST_REVISION! gtr 5 (
        
	    set /a LATEST_REVISION -= 5
	    
	    rem echo !LATEST_REVISION!
	    
		rem obliterate 명령 실행
	    rem echo "p4 obliterate -T !TARGET_FILE!#1,#!LATEST_REVISION!"
	    
	    p4 obliterate -y -T !TARGET_FILE!#1,#!LATEST_REVISION!
    )
)

endlocal

files_program.txt 파일은 아래와 같이 작성한다.

//depot/Project/Server/TestServer1.pdb
//depot/Project/Server/TestServer2.pdb

//depot/Project/Server/TestServer3.pdb
//depot/Project/Server/TestServer4.pdb

Return-path: <root@debian>
Envelope-to: root@debian
Delivery-date: Sat, 25 Mar 2023 15:47:09 +0900
Received: from root by debian with local (Exim 4.94.2)
        (envelope-from <root@debian>)
        id 1pfxgD-00FRcJ-EF
        for root@debian; Sat, 25 Mar 2023 15:47:09 +0900
Subject: SMART error (CurrentPendingSector) detected on host: debian
To: <root@debian>
X-Mailer: mail (GNU Mailutils 3.10)
Message-Id: <E1pfxgD-00FRcJ-EF@debian>
From: root@debian
Date: Sat, 25 Mar 2023 15:47:09 +0900
X-UID: 60
Status: O

This message was generated by the smartd daemon running on:

   host name:  debian
   DNS domain: [Empty]

The following warning/error was logged by the smartd daemon:

Device: /dev/sdc [SAT], 4 Currently unreadable (pending) sectors

Device info:
SAMSUNG HD250HJ, S/N:S0UTJDWQ117986, WWN:5-0000f0-0db117986, FW:FH100-06, 250 GB

For details see host's SYSLOG.

You can also use the smartctl utility for further investigation.
The original message about this issue was sent at Fri Jan 27 14:47:09 2023 KST
Another message will be sent in 24 hours if the problem persists.

이 디스크는 2008년에 생산된 삼성 250GB 하드디스크다. 2023년 말 기준으로 대략 15년간 동작한 셈이다. 내가 나눔받아 사용하기 시작한 것이 2015년 초였고, 그 이후 절반 이상의 기간은 거의 24시간 가동 상태였다. 이 정도면 불량 섹터가 생기는 것도 당연한 일이었다.

집에 돌아와 해당 디스크의 파일을 모두 지우고 NAS에서 분리했다.

S3에 백업하려면 기본적인 사용법을 알아야 한다. 버킷의 개념이나 CLI 설정 등이 선행되어야 하지만, 준비가 되었다면 아래 스크립트 하나로 동기화가 가능하다.

NAS의 사진 디렉토리와 S3 버킷을 동기화할 수 있도록 다음 스크립트를 작성해서 생각날 때마다 한 번씩 실행하고 있다. (NAS는 리눅스 서버이다.)

기본 스크립트

aws s3 sync /disk3/BackupTargetDirectory s3://backup-bucket \
        --storage-class STANDARD_IA \
        --exclude "*" \
        --include "backup1/*" \
        --include "backup2/*" \
        --include "backup3/*"

이 스크립트의 핵심은, 디렉토리 안에 백업 대상이 아닌 자료들이 섞여 있을 때 전체를 제외(--exclude "*")하고 원하는 디렉토리만 선택적으로 포함(--include)해서 업로드한다는 점이다.

저장 등급 (Storage Class)

저장 등급은 --storage-class 옵션으로 지정할 수 있다. 자주 접근하지 않는 파일이라면 비용을 절감할 수 있는 STANDARD_IA나 GLACIER 등을 활용하는 것이 좋다.

주요 옵션에 대한 설명은 아래 참고자료 링크를 참조하면 된다.

• STANDARD
• REDUCED_REDUNDANCY
• STANDARD_IA
• ONEZONE_IA
• INTELLIGENT_TIERING
• GLACIER
• DEEP_ARCHIVE
• GLACIER_IR

참고자료

• https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html

이 제품은 IKEA의 UPPSTA라는 고리 쌓기 장난감이다.

프로그래머나 개발자라면 저 장난감이 ‘하노이의 탑’ 문제와 완전히 같다는 것을 한눈에 알 것이다.

영유아 장난감 하나로도 알고리즘을 이야기할 수 있고 흥미로운 문제를 떠올릴 수 있다. 그런데 굳이 어린 나이부터 코딩 학원이나 코딩 교육이 필요한 걸까? 그런 것은 고등학교나 대학교에서 배워도 늦지 않다고 생각한다. 어릴 때는 오히려 흔한 장난감을 통해 문제를 생각해보는 경험, 즉 ‘코딩’보다 ‘문제 풀이’라는 개념 자체에 자연스럽게 접근해나가는 것이 더 올바른 방향이 아닐까 싶다.

워드프레스를 쓰기 시작한 건 대략 15년 정도 된 것 같다. 정확히 언제였는지는 기억이 잘 나지 않는다. 처음에는 태터툴즈(지금의 티스토리 전신)를 썼었고, 이후 무버블타입(MT3)이나 soojung이라는 파일 기반 블로그 툴을 고민하다가 결국 가장 많이 사용되는 워드프레스를 선택했다. 그렇게 10여 년이 훌쩍 흘렀다.

단점과 해킹

PHP로 만들어진 워드프레스는 막강한 기능을 자랑하지만, 그 기능 때문에 너무나 복잡했다. 한 군데라도 잘못 건드리면 사이트가 먹통이 되기 일쑤라, 뭔가 고쳐보려 할 때마다 망설여지는 시스템이었다.

최근 트렌드는 HTML 기반의 정적(static) 사이트가 대세다. 이를 곰곰이 고민하다가 직접 내 사이트부터 전환해보았다. PHP를 쓰지 않으니 관리가 훨씬 편했다. 관리자 모드도 없어졌고, GitHub + Netlify를 통한 배포 방식이 정말 마음에 들었다.

아내의 비즈니스용 웹사이트는 워드프레스로 구축되어 AWS Lightsail 위에서 작동하고 있었는데, 얼마 전 들어가봤더니 해킹당한 것을 알게 되었다.

구글 서치콘솔에 가보니 알 수 없는 35만 개의 페이지가 생성되어 있었다.

URL을 보니 PHP 취약점 등을 이용해 자동으로 생성된 페이지였다.

사이트 자체는 접속이 되지 않는 상태였지만, 다행히 관리자 모드는 들어갈 수 있어서 자료를 살릴 수 있었다. 어차피 정적 자료를 관리하는 사이트라 PHP가 더 이상 필요하지 않다고 판단했다. 자료를 백업하고 Jekyll + Netlify 기반으로 재구축해 기존 자료를 다시 옮기는 데 3일이 걸렸다.

Netlify

GitHub + Netlify의 간단하고 편리한 사이트 빌드 시스템은 정말 마음에 든다.

정적 HTML 사이트로 전환하고 나니 해킹 위험은 거의 없어졌다. 워드프레스가 나쁜 건 아니었지만, 편하게 쓰기에는 너무 복잡했고 이런 해킹 위험까지 감수할 만큼 매력적인 시스템도 아니었다.

이제 Netlify 유료 플랜을 고민해볼 차례다.