sr's lair

<AI도 모르는 글쓰기> - AI가 쓴 글을 결국 사람이 고쳐야 하는 이유

심량 — Mon, 3 Aug 2026 18:19:07 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

7월에 리뷰할 책은 AI도 모르는 글쓰기 입니다.

AI도 모르는 글쓰기

제목을 처음 봤을 때 조금 뜨끔했습니다.

나도 모르는 글쓰기로 자꾸 보이고, 나도 모르면서 AI 갈구는 글쓰기 처럼 읽혔기 때문입니다.(공대생은 슬픕니다 ㅜㅜ)

이 책은 먼저 좋은 글이 무엇인지부터 설명합니다. 우리 스스로가 좋은 글도 못쓰면서(많이 찔렸습니다..) AI 보고 너 잘써 임마 할 수는 없겠죠?

사실 ai 가 나타난 뒤로 제 블로그 글 쓰는 방법이 바뀌었습니다.

전에는 진짜 노트 메모 수준으로 나중에 찾아보려는 목적으로 글을 작성하기에 급급했어서 ai 를 뭐라고 하기 전에 제 글 수준부터가 진짜 저 자신만을 위한 기록 쪼가리들의 모임이었습니다.

지금도 제 블로그 예전 글들을 보면 그런 냄새가 물씬 납니다.

그런데 역설적으로 ai 의 도움을 받아 글을 다듬기 시작하면서부터 좀 더 잘 쓰고, 정리하고, ai 냄새보다 내 냄새를 더 싣고 싶다는 생각이 간절하게 되었습니다.

이 책에서 '좋은 글이란?' 질문을 보면서 이러한 목마름을 다시 상기하게 되었습니다.

나도 ai 로 글 쓰는데 그럼 어쩌라고? 라고 생각하실 수도 있으시겠지만, 이 책은 놀랍게도 대놓고 다음 내용을 알려줍니다.

2.3 AI 티 나지 않게 개선하기

제목만 보면 막 왕도가 적혀 있을 것 같지만요

실은 읽다보면 아시겠지만, 결국, 저 스스로 글 쓸 때에도 필요한 항목들을 알려줍니다.

이 책을 읽으면서 글쓰는 방법을 새로 배워간다고 해도 과언이 아닐 정도였습니다.

글쓰기에 무지하고 막 써대는 제게는 진짜 선생님(?)같은 책이었습니다.

저자는 기획/설계/초안/개선/완성의 글쓰기 단계를 제시하면서 ai 에게 맡길 것과 내가 해야할 것을 구별해줍니다.

인간이 해야 할 것과 AI에게 맡길 것

전체적으로 글쓰기의 기본과 ai 에게 지시해야 하는 것을 잘 버무려서 설명하고 있습니다.

글쓰기가 두려웠던 분들도, 복습하실 겸, ai 를 통한 내 저작물 품질을 올려보고 싶으신 분들은 책을 보시면 후회하지 않으실 것 같습니다.

3.1 기획하고 설계하기

이 후 내용들은 ai 를 사용하시면서 어느 정도 터득해오시는 내용들도 함께 나옵니다.

어떻게 보면 글쓰기와 ai 이용에 빠삭하신 분들에게는 식상하다고 할 수도 있겠으나, 둘 중 하나라도 부족하신 분들에게는 단비와 같은 좋은 내용들이 계속 이어집니다.

3.4 AI와 함께 쓰기

4 회의록·이메일·공지

회의록, 이메일, 공지, 기술 문서(테크니컬 라이팅), 글로벌 문서(번역, i18n) 쓰는 법과 notebooklm 까지 소개하고 있으니 한 번씩 참고하시고 멍충한 ai 라고 욕하기보다 잘했어 라이코스(!)라고 외칠 수 있는 ai 글쓰기 라이프 즐기시길 바라겠습니다.

PowerToys 업데이트 후 ‘스택에 사용할 새 보호 페이지를 만들 수 없습니다’ 오류 해결

심량 — Thu, 16 Jul 2026 10:13:39 +0900

PowerToys 자체 업데이트 알림을 클릭한 뒤 PowerToys.QuickAccess.exe가 실행되지 않는 문제가 발생했습니다.
일반 권한 터미널에서 사용자 범위로 설치된 PowerToys를 제거한 뒤 재설치하니 정상적으로 해결되었습니다.

PowerToys에서 새로운 버전이 있다는 업데이트 알림이 표시되어 평소처럼 업데이트를 진행했습니다.

그런데 업데이트가 끝난 뒤 시스템 트레이에서 PowerToys 아이콘을 클릭하자 메인 화면이 열리지 않고 다음과 같은 시스템 오류가 나타났습니다.

PowerToys.QuickAccess.exe - 시스템 오류

스택에 사용할 새 보호 페이지를 만들 수 없습니다.

Windows를 다시 시작해 보았지만 증상은 동일했습니다.

결국 PowerToys를 완전히 제거한 뒤 다시 설치했고, 이후 메인 화면이 정상적으로 실행되었습니다.

해결 방법 요약

다음 순서로 해결했습니다.

관리자 권한이 아닌 일반 터미널 실행
사용자 범위 PowerToys 제거
PowerToys 재설치
PowerToys 메인 화면 실행 확인

사용한 명령은 다음과 같습니다.

winget uninstall --id Microsoft.PowerToys --scope user --exact

제거가 완료되면 다시 설치합니다.

winget install --id Microsoft.PowerToys --scope user --source winget --exact

재설치 후에는 PowerToys.QuickAccess.exe 오류 없이 PowerToys 메인 화면이 정상적으로 열렸습니다.

PowerToys 자체 업데이트 후 발생한 문제

이번 문제는 Windows 업데이트가 아니라 PowerToys 자체의 업데이트 알림을 클릭해 업데이트한 직후 발생했습니다.

업데이트 전에는 PowerToys가 정상적으로 실행되고 있었습니다.

하지만 자체 업데이트가 끝난 뒤 시스템 트레이 아이콘을 클릭하면 Quick Access 화면이 열리지 않고 다음 오류가 나타났습니다.

스택에 사용할 새 보호 페이지를 만들 수 없습니다.

오류 창의 제목을 보면 문제가 발생한 실행 파일은 다음과 같습니다.

PowerToys.QuickAccess.exe

Quick Access는 시스템 트레이의 PowerToys 아이콘을 클릭했을 때 나타나는 빠른 설정 화면입니다.

따라서 이번 증상은 PowerToys 전체가 완전히 실행되지 않는 문제라기보다, Quick Access 화면을 구성하는 프로세스가 시작 과정에서 실패한 상황으로 볼 수 있습니다.

먼저 재부팅해 보았지만 해결되지 않았습니다

업데이트 직후 발생한 문제였기 때문에 기존 PowerToys 프로세스가 종료되지 않았거나, 새 버전의 파일과 이전 버전의 파일이 함께 로드된 상태일 가능성을 생각했습니다.

그래서 Windows를 완전히 다시 시작한 뒤 PowerToys를 실행해 보았습니다.

하지만 재부팅 후에도 동일한 오류가 발생했습니다.

PowerToys.QuickAccess.exe - 시스템 오류
스택에 사용할 새 보호 페이지를 만들 수 없습니다.

이 단계에서 단순히 실행 중인 프로세스가 꼬인 문제는 아닌 것으로 판단하고, PowerToys를 제거한 뒤 다시 설치하기로 했습니다.

관리자 터미널에서는 제거되지 않았습니다

처음에는 관리자 권한으로 Windows 터미널을 실행하고 다음 명령을 입력했습니다.

winget uninstall --id Microsoft.PowerToys

그러자 다음 메시지가 나타나면서 제거되지 않았습니다.

찾음 PowerToys (Preview) x64 [Microsoft.PowerToys]

The package installed for user scope cannot be uninstalled
when running with administrator privileges.

메시지를 그대로 해석하면 PowerToys가 사용자 범위(User scope)로 설치되어 있는데, 현재 터미널은 관리자 권한으로 실행되어 있어 제거할 수 없다는 뜻입니다.

WinGet은 --scope 옵션을 통해 사용자 범위와 시스템 범위를 구분할 수 있습니다. Microsoft 공식 문서에서도 winget uninstall에 설치 범위를 지정하는 옵션을 제공하고 있습니다.

일반 권한 터미널에서 제거하기

현재 열려 있는 관리자 권한 터미널을 닫았습니다.

그다음 시작 메뉴에서 Windows 터미널 또는 PowerShell을 관리자 권한 없이 일반 실행했습니다.

일반 터미널에서 다음 명령을 실행했습니다.

winget uninstall --id Microsoft.PowerToys --scope user --exact

각 옵션의 의미는 다음과 같습니다.

--id Microsoft.PowerToys
PowerToys의 WinGet 패키지 ID를 지정합니다.

--scope user
현재 사용자 범위에 설치된 패키지를 대상으로 합니다.

--exact
입력한 패키지 ID와 정확히 일치하는 항목을 선택합니다.

이번에는 오류 없이 PowerToys가 정상적으로 제거되었습니다.

PowerToys 다시 설치하기

제거가 완료된 뒤 같은 일반 권한 터미널에서 PowerToys를 다시 설치했습니다.

winget install --id Microsoft.PowerToys --scope user --source winget --exact

PowerToys는 실행 파일, Microsoft Store, WinGet 등 여러 방식으로 설치할 수 있으며, Microsoft 공식 문서에서도 WinGet을 이용한 설치 방법을 안내하고 있습니다.

설치가 끝난 뒤 PowerToys를 실행했습니다.

이번에는 시스템 트레이의 PowerToys 아이콘을 클릭해도 오류가 나타나지 않았고, Quick Access와 설정 화면이 모두 정상적으로 열렸습니다.

실행한 명령 전체 정리

관리자 권한이 아닌 일반 Windows 터미널에서 다음 두 명령을 순서대로 실행했습니다.

PowerToys 제거

winget uninstall --id Microsoft.PowerToys --scope user --exact

PowerToys 재설치

winget install --id Microsoft.PowerToys --scope user --source winget --exact

설치된 PowerToys 정보를 먼저 확인하려면 다음 명령을 사용할 수 있습니다.

winget list --id Microsoft.PowerToys

왜 재설치로 해결되었을까요?

정확한 원인은 충돌 로그나 덤프 파일을 분석하지 않았기 때문에 단정할 수 없습니다.

다만 확인된 상황은 다음과 같습니다.

업데이트 전에는 PowerToys가 정상적으로 실행되었습니다.
PowerToys 자체 업데이트 직후 오류가 발생했습니다.
Windows 재부팅으로는 해결되지 않았습니다.
PowerToys 제거 후 재설치하자 정상화되었습니다.

추론

PowerToys 자체 업데이트 과정에서 PowerToys.QuickAccess.exe 또는 함께 사용되는 구성 파일과 라이브러리 일부가 정상적으로 교체되지 않았을 가능성이 있습니다.

업데이트 도중 기존 프로세스가 파일을 사용하고 있었거나, 일부 파일만 새 버전으로 변경되면서 구성 요소 사이에 버전 불일치가 발생했을 수도 있습니다.

재설치는 기존 설치 파일을 제거하고 필요한 실행 파일과 구성 요소를 다시 배치하기 때문에, 이러한 불완전한 업데이트 상태가 함께 해소된 것으로 추정됩니다.

다만 이것은 증상과 해결 결과를 바탕으로 한 추론이며, PowerToys 업데이트 프로그램의 결함이 원인이었다고 확정한 것은 아닙니다.

사용자 범위 설치가 문제였던 것은 아닙니다

관리자 터미널에서 제거할 때 다음 오류가 표시되었기 때문에 사용자 범위 설치가 문제였다고 생각할 수 있습니다.

The package installed for user scope cannot be uninstalled
when running with administrator privileges.

하지만 이 메시지는 사용자 범위로 설치된 프로그램을 다른 권한 범위에서 제거하려 했기 때문에 나타난 것입니다.

즉, 사용자 범위로 설치한 것 자체가 Quick Access 오류의 원인이라는 뜻은 아닙니다.

정리하면 두 문제는 구분해야 합니다.

Quick Access 시스템 오류
→ PowerToys 업데이트 이후 발생한 실행 문제

WinGet 제거 오류
→ 사용자 범위 프로그램을 관리자 터미널에서 제거하려 해서 발생

일반 권한 터미널에서 --scope user를 지정하자 정상적으로 제거할 수 있었습니다.

기존 PowerToys 설정은 어떻게 될까요?

제 경우에는 PowerToys를 제거하고 다시 설치한 뒤에도 기존 설정을 다시 확인할 수 있었습니다.

다만 설치 방법과 PowerToys 버전, 제거 과정에 따라 사용자 설정이 초기화될 가능성도 있으므로 중요한 Keyboard Manager 매핑이나 FancyZones 레이아웃이 있다면 먼저 백업하는 편이 안전합니다.

PowerToys 일반 설정에서는 설정 백업과 복원 기능도 제공됩니다.

메인 화면을 전혀 열 수 없어 백업할 수 없는 상황이라면, 설정 폴더를 직접 삭제하기 전에 별도 위치에 복사해 두는 것이 좋습니다.

재설치해도 해결되지 않는다면

PowerToys를 다시 설치한 뒤에도 같은 오류가 발생한다면 다음 항목을 추가로 확인해 볼 수 있습니다.

Windows를 다시 시작합니다

PowerToys 설치 후 이전 프로세스나 라이브러리가 남아 있을 수 있으므로 Windows를 다시 시작합니다.

설치 범위가 중복되어 있는지 확인합니다

다음 명령으로 설치된 PowerToys 항목을 확인합니다.

winget list PowerToys

사용자 범위와 시스템 범위 설치가 중복되어 있다면 하나의 설치 방식으로 정리하는 것이 좋습니다.

Windows 설정에서 제거합니다

WinGet 제거가 계속 실패한다면 다음 경로에서도 제거할 수 있습니다.

Windows 설정
→ 앱
→ 설치된 앱
→ PowerToys (Preview) x64
→ 제거

Microsoft의 WinGet 제거 문서에서도 명령줄 제거가 어려운 경우 Windows의 설치된 앱 화면을 이용하는 방법을 안내하고 있습니다.

자주 묻는 질문

관리자 권한 PowerShell에서 PowerToys를 제거하면 안 되나요?

PowerToys가 시스템 범위로 설치되어 있다면 관리자 권한이 필요할 수 있습니다.

하지만 이번처럼 사용자 범위로 설치된 PowerToys는 관리자 권한 터미널에서 제거하려 할 때 범위가 맞지 않아 실패할 수 있습니다.

오류 메시지에 installed for user scope가 표시된다면 일반 권한 터미널에서 다음 명령을 사용해 보시기 바랍니다.

winget uninstall --id Microsoft.PowerToys --scope user --exact

PowerToys 설정 폴더도 삭제해야 하나요?

먼저 설정 폴더를 삭제하지 않고 제거와 재설치만 진행하는 것이 좋습니다.

이번 사례에서는 설정 폴더를 별도로 초기화하지 않고도 재설치만으로 문제가 해결되었습니다.

재설치 후에도 같은 오류가 계속될 때만 설정 백업 후 초기화를 검토하는 편이 안전합니다.

가상 메모리가 부족해서 발생한 오류인가요?

오류 문구만 보면 스택이나 메모리와 관련된 문제처럼 보일 수 있습니다.

하지만 이번 사례에서는 PowerToys 자체 업데이트 직후 Quick Access에서만 발생했고, 동일한 PC에서 제거 후 재설치하자 즉시 정상화되었습니다.

따라서 시스템 전체의 메모리 부족보다는 PowerToys 업데이트 또는 설치 상태에 문제가 있었을 가능성이 더 높아 보입니다. 이 역시 확인된 원인이 아니라 증상에 근거한 추론입니다.

마무리

PowerToys 자체 업데이트 알림을 클릭해 업데이트한 뒤 다음 오류가 발생했습니다.

PowerToys.QuickAccess.exe - 시스템 오류
스택에 사용할 새 보호 페이지를 만들 수 없습니다.

Windows를 다시 시작해도 해결되지 않았지만, 일반 권한 터미널에서 사용자 범위 PowerToys를 제거한 뒤 다시 설치하자 정상적으로 실행되었습니다.

핵심 명령은 다음 두 줄입니다.

winget uninstall --id Microsoft.PowerToys --scope user --exact
winget install --id Microsoft.PowerToys --scope user --source winget --exact

관리자 권한 터미널에서 다음 메시지가 나타난다면 터미널을 일반 권한으로 다시 실행해야 합니다.

The package installed for user scope cannot be uninstalled
when running with administrator privileges.

업데이트를 눌렀을 뿐인데 프로그램 제거 권한과 설치 범위까지 공부하게 되는 것이 Windows 유틸리티의 교육 철학인 모양입니다. 다행히 이번 문제는 별도의 설정 초기화 없이 제거와 재설치만으로 해결되었습니다.

Windows 11 업데이트 후 PowerToys Win+F로 Everything이 실행되지 않을 때 해결 방법

심량 — Thu, 16 Jul 2026 09:45:55 +0900

Windows 11 업데이트 이후 PowerToys에 등록한 Win + F 단축키로 Everything이 실행되지 않는 문제가 발생했습니다.
PowerToys의 작업을 앱 시작에서 URL 열기로 변경하고, URL 입력란에 Everything.exe의 전체 경로를 넣으니 정상적으로 해결되었습니다.

기존에는 PowerToys의 Keyboard Manager를 이용해 Win + F를 누르면 Everything 검색창이 열리도록 설정해 사용하고 있었습니다.

그런데 어느 시점의 Windows 11 업데이트 이후부터 단축키를 눌러도 아무 반응이 없었습니다.

Everything.exe를 직접 실행하면 프로그램은 정상적으로 열렸기 때문에 Everything 자체의 문제는 아니었습니다.

다음과 같은 방법도 확인해 보았습니다.

실행 파일 경로 다시 지정
PowerToys 관리자 권한 실행
시작 디렉터리 입력
기존 단축키 삭제 후 재등록
PowerToys와 Keyboard Manager 재시작

하지만 앱 시작 방식에서는 문제가 해결되지 않았습니다.

해결 방법

PowerToys 설정에서 다음 메뉴로 이동합니다.

Keyboard Manager
→ 바로 가기 다시 매핑
→ Win + F 항목 편집

기존 설정은 다음과 같았습니다.

단축키: Win + F
작업: 앱 시작
앱: D:\user\util\installed\Everything\Everything.exe

여기서 작업 드롭다운을 앱 시작에서 URL 열기로 변경합니다.

그다음 URL 입력란에 Everything 실행 파일의 전체 경로를 넣습니다.

D:\user\util\installed\Everything\Everything.exe

설정을 저장하고 Win + F를 눌러 보니 Everything 검색창이 정상적으로 실행되었습니다.

작업에서 URL 열기 선택

URL 항목에 실행파일 경로 붙여넣기

변경 전과 변경 후

작동하지 않았던 설정

단축키: Win + F
작업: 앱 시작
앱: D:\user\util\installed\Everything\Everything.exe

정상적으로 작동한 설정

단축키: Win + F
작업: URL 열기
URL: D:\user\util\installed\Everything\Everything.exe

실행 파일의 위치나 단축키는 바꾸지 않았습니다.

PowerToys가 실행 파일을 처리하는 작업만 앱 시작에서 URL 열기로 변경했습니다.

왜 URL 열기로 실행되는지는 확실하지 않습니다

정확한 원인은 PowerToys 로그나 동일 환경의 재현 없이는 확인하기 어렵습니다.

추론입니다.

앱 시작은 실행 인수, 시작 디렉터리, 권한 등 여러 옵션을 함께 처리합니다. 반면 URL 열기는 입력된 경로나 주소를 상대적으로 단순하게 실행합니다.

제 환경에서는 앱 시작 처리 과정에서 발생하던 문제가 URL 열기에서는 나타나지 않은 것으로 보입니다.

따라서 PowerToys를 완전히 우회한 것은 아니며, PowerToys 안에서 다른 실행 방식을 사용한 우회 방법이라고 보는 것이 정확합니다.

URL 열기로 변경해도 실행되지 않는다면

다음 항목을 확인해 보시기 바랍니다.

Everything.exe가 직접 실행되는지 확인합니다.
PowerToys가 백그라운드에서 실행 중인지 확인합니다.
Keyboard Manager가 활성화되어 있는지 확인합니다.
Win + F 대신 Ctrl + Alt + E 같은 다른 단축키로 테스트합니다.
PowerToys와 Everything의 실행 권한이 서로 다른지 확인합니다.

<트랜스포머 아키텍처로 배우는 AI 에이전트 with 랭체인 & 랭그래프> -

심량 — Wed, 1 Jul 2026 11:05:51 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

6월에 리뷰할 책은 트랜스포머 아키텍처로 배우는 AI 에이전트 with 랭체인 & 랭그래프 입니다.

제목이 꽤 긴 편입니다. 다만, 목차를 따라가 보면 저자의 분명한 집필 방향을 알 수 있었습니다. 자연어 처리의 기본 개념에서 시작해 어텐션, 트랜스포머, LLM, 랭체인, 랭그래프, RAG, 로컬 LLM, 멀티 에이전트까지 이어지는 흐름입니다

1장에서는 실습 환경 구성을 먼저 안내합니다. 비주얼 스튜디오 설치, 미니콘다 기반 가상 환경 구성, CPU와 GPU 환경에 따른 파이썬 라이브러리 설치가 포함되어 있습니다.

2장에서 배경 이해에 도움이 될 수 있는 자연어 처리가 무엇이고, 어떤 수학적인 근거를 바탕으로 동작하는 지를 잘 배치하고 있습니다.

기본 원리 설명은 이해에 도움이 되지만, 수학적인 원리와 같은 부분은 꼭 왜 이해 안되지 하시면서 붙잡지 않으셔도 됩니다. 저자의 전체적인 의도인 AI 에이전트가 이렇게 돌아간다라는 큰 흐름 안에서 한 번 훑어보는 정도로만 권장합니다.

왜냐하면 이미 아시는 분들은 이미 아실만한 개념일테고 수학적인 것을 들이파고자 이 책을 선택하신 것은 아니실테니까요, 혹시 이쪽에 좀 더 자세한 공부를 원하신다면 처음 배우는 딥러닝 수학 이나 AI를 위한 필수 수학 과 같은 책들을 먼저 보시기를 추천합니다.

3장에서는 강화학습을 다룹니다. 보상, 상태, 행동, 정책, 가치 함수 같은 개념을 바탕으로 모델이 선택을 개선해 가는 과정을 설명합니다. 다중 슬롯 머신 문제, 마르코프 결정 프로세스, 몬테카를로 방법, TD(0), Sarsa, Q-learning까지 이어집니다.

4장에서는 시퀀스 모델을 다룹니다. RNN, LSTM, 양방향 LSTM, seq2seq, 빔 서치가 포함되어 있습니다. 이 부분은 뒤에 나오는 어텐션과 트랜스포머를 이해하기 위한 전 단계로 볼 수 있습니다.

이 정도까지는 어깨 너머로 한 귀로 들어오던 내용이라 크게 어려움이 없었습니다.

하지만 본격적인 내용이 시작되는 5장의 어텐션과 6장의 트랜스포머 쪽을 보시게 되면 이 쪽에 익숙하지 않으신 분들은 반복해서 읽고, 다른 내용들도 찾아보고 하시면 도움이 되실 것 같습니다.

본문의 어텐션 스코어와 컨텍스트 관련된 도표

트랜스포머 전체 구조

개략적으로 알고 싶으시면 본문의 아래 표를 참조하시고 관심이 있는 쪽에 해당하는 부분만 좀 더 자세히 파악하시면 될 것 같습니다.

LLM 발전 연대기

이론은 잘 모르겠고, 난 실습부터 하고 싶다 하시는 분들은 8장부터 보시면 됩니다. Ollama 를 통해 트랜스포머를 사용해볼 수 있는 내용들을 소개하고 있고, 9장에서는 LLM을 나만의 데이터로 추가 학습을 시키는 파인튜닝을 설명하고 있고, 10장에서는 외부 지식을 데이터베이스화 해서 이를 LLM이 검색해서 활용할 수 있게 하는 RAG의 개념과 실제 테스트할 수 있는 내용들에 대해서 소개하고 있습니다.

11장과 12장은 각각 간략히 멀티에이전트, MCP, Streamlit 을 통한 에이전트 발행(?) 기능을 안내하고 있습니다.

개인적으로 Ollama 는 설치해서 어떻게 동작하는지 등을 살펴보았지만, 사용 환경의 한계(구형 그래픽 카드, 자원 제약 등등)로 만족할만한 테스트는 못 해봤습니다. 좀 더 넉넉한 예산이 있었으면 좋겠지만, 1백만원대 후반에서 2백만원이면 구축할 수 있었던 환경이 3백만원 이상을 줘야 시작을 할 수 있는 상황이 계속 되는지라 엄두는 못냈습니다.

ollama 실행

날씨를 물었더니 엉뚱한 날짜로 검색하는 ollama

아직은 상당히 불안한(HW 스펙 부족 때문인지 ㅜㅜ) ollama 동작 출력

이 책은 AI 에이전트를 다루기 위해 필요한 배경 개념을 앞에서 정리하고, 뒤쪽에서 실제 도구와 실습으로 연결하는 구성을 가지고 있습니다. 빠르게 결과물부터 만들고 싶은 분에게는 앞부분이 조금 길게 느껴질 수 있습니다. 반대로 LLM, 트랜스포머, RAG, 로컬 LLM, 랭체인, 랭그래프가 어떤 순서로 연결되는지 보고 싶은 분에게는 전체 흐름을 잡는 데 도움이 될 책이라고 생각합니다.

<클로드 코드 마스터> - AI를 쓰는 개발자에서 AI를 이끄는 개발자로

심량 — Mon, 1 Jun 2026 16:10:15 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

5월에 리뷰할 책은 클로드 코드 마스터 입니다.

요새 신규 개발을 하려고 하던지 규모 있는 수정을 하려고 할 때 AI 를 빼놓고 진행하는 경우가 드물어지고 있는 것 같습니다.

저도 초창기에는 웹 버전의 chatgpt 나 claude 에게 일일이 코드를 붙여넣고 물어보고, 저장소에 적용해서 디버깅 일일이 하고, 막히면 또 묻고 하는 과정을 겪었던 것 같습니다.

그런데 지금은 클로드 코드, 코덱스를 통해 저장소에서 직접 파일을 읽어서 분석하고, 설계하고, 구현하고, 디버깅하는 게 일상이 되어버렸습니다.

웹 버전의 소스 접근이 제한된 상태의 AI 에게 도움을 받는 것과 직접 소스에 접근 가능한 cli 형태의 AI 도구가 어느 정도 귀찮은 부분을 해결해 주는 게 완전 비교가 안될 정도로 AI 에 대한 생각을 바꾸게 되었고, 개발 성향을 완전히 바꾸게 되었습니다.

솔직히 지금도 AI 빼놓고 코딩하라면 가능합니다. 다만, 시간이 AI보다 더 걸릴 뿐이죠.

AI를 사용하면서 내가 설정한 방향을 AI에게 올바로 주입시키고 개발을 진행하는 게 쉽지만은 않다는 것을 많이 깨닫게 되었습니다.

그럴 때 만난 이 책은 "AI를 사용하는 개발자가 아닌, AI를 이끄는 개발자가 되기 위한 가이드" 라는 출판사의 설명을 가지고 있었습니다.

이를 위해 이 책에서는 AI 시대의 개발자의 역할에 대해서 1장에서 간략히 정의를 하고, 2장에서 클로드 코드 설치 및 환경 구성뿐만 아니라, 클로드를 잘 쓰기 위해서 기본적으로 이해하면 좋은 개념들을 설명합니다.

모델(Opus, Sonnet, Haiku), 기본 명령어, 프로젝트 설정(CLAUDE.md), Agent Skill, Hook을 소개하고 있습니다.

저는 3장의 설명이 도움이 많이 되었습니다. 어떻게 보면 그동안의 개발 경험에 기반한 감으로 클로드를 다그치며 사용해오고 있었다면, 설계, 작업 쪼개기, 완료 조건, TDD 등의 내용을 가끔씩 대충 쓰는게 아니라 매번 인지하고 사용할 수 있도록 명확히 알려주었기 때문입니다.

4장부터 12장까지는 이제 풀스택 TODO 앱과 AI 챗봇 앱을 클로드를 통해서 개발하는 내용이 주를 이루고 있습니다.

특히 TODO 앱 예제는 풀스택 개발의 기본 흐름을 잡는 데 도움이 되고, 후반부의 AI 챗봇 앱은 AWS Bedrock, 스트리밍 응답, Tool Use 같은 요소까지 다루고 있어서 클로드 코드를 단순 코드 생성기가 아니라 개발 파트너처럼 사용하는 감각을 익히는 데 의미가 있어 보였습니다.

아직 클로드 사용 및 프로그램 개발에 익숙하지 않으신 분들은 해당 내용들을 따라가시다 보면 어느 정도의 도움을 얻을 수 있을 것 같습니다.

어느 정도 사용할 줄 아시는 분들도 쭉 훑어보면 내가 미처 활용해보지 못했던 부분들을 발견하고 즐거운 클로드 생활에 도움이 되도록 잘 가져다 쓸 수 있을 거라 생각됩니다.

저는 개인적으로 gsd 와 superpowers 라는 플러그인을 사용하고 개발하고 있습니다. 그래서 책에 소개된 내용이 어느 정도 아는 내용도 있었고, 일부는 이런 상황에 이렇게 쓰는구나 하는 도움을 받을 수도 있었습니다.

책 부록에 보시면 개발에 유용한 팁 소개라며 Superpowers 플러그인을 소개하고 있습니다.

이 플러그인이 매력적으로 느껴지신다면 꼭 gsd 도 찾아보시고, 마음에 드시면 설치해서 사용해 보세요, 책에 소개된 흐름을 어느 정도는 플러그인이 강제로 진행하도록 하여 짜임새 있게 프로젝트를 진행할 수 있도록 도와줄 수 있을 거라 생각합니다.

클로드 코드를 잘 모르는 생짜 초보도 열심히 책을 탐독하시면 어느 정도는 따라오실 수 있을 것 같습니다.

저처럼 클로드 코드나 비슷한 AI 코딩 도구를 어느 정도 사용해본 사람에게도 의미가 있습니다. 실제 프로젝트 개발 사례를 따라가다 보면 자신이 대충 감으로 넘기고 있던 부분이나, 더 체계적으로 활용할 수 있는 부분을 발견할 수 있기 때문입니다.

클로드 코드로 개발을 제대로 해보고 싶으신 분들은 한 번씩 읽어보시길 추천합니다.

<오픈클로 with GPT, 제미나이, 클로드> - AI 경험의 특이점

심량 — Sat, 25 Apr 2026 20:34:45 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

4월에 리뷰할 책은 오픈클로 with GPT, 제미나이, 클로드 입니다.

AI에 관심을 가지기 시작한 뒤로 감사하게도 한빛미디어를 통해 여러 AI 관련 책을 읽을 기회가 생겼습니다. 첫 리뷰 책부터 지금까지 자연스럽게 AI 흐름을 따라가며 읽을 수 있었고, 이 자리를 빌려 한빛미디어에 감사한 마음을 전하고 싶습니다.

아마 이 글을 읽고 계신 분들도 저처럼 AI에 관심이 있는 분들이 많을 것 같습니다.

물론 그중에는 이미 AI 흐름을 빠르게 따라가고, 이 책에서 다루는 오픈클로(OpenClaw) 정도는 예전에 설치해보고 활용까지 해본 분들도 계실 것입니다. 그런 분들은 제가 굳이 설명하지 않아도 공식 문서, GitHub, 커뮤니티, 최신 사례를 직접 찾아다니며 더 깊고 빠른 정보를 얻고 계실 테니, 이 글의 주된 대상은 조금 다릅니다.

이 책은 오픈클로라는 이름은 들어봤지만 아직 정확히 무엇인지 모르겠는 분,
AI 에이전트가 실제로 어떤 일을 할 수 있는지 궁금한 분,
최신 기술을 직접 따라가보고 싶지만 여러 문서와 자료를 일일이 수집하고 분석할 시간이 부족한 분들에게 특히 잘 맞는 책입니다.

오픈클로를 아주 쉽게 말하면, 내 컴퓨터 안에서 일하도록 설정할 수 있는 AI 비서에 가깝습니다. 단순히 질문에 답하는 AI를 넘어, 파일을 다루고, 메일이나 일정 같은 작업을 돕고, 반복적인 일을 자동화하는 방향으로 한 걸음 더 나아간 도구라고 볼 수 있습니다.

아직 완벽한 집사라고 부르기에는 이른 부분도 있습니다. 하지만 바로 그렇기 때문에 이 책이 의미 있다고 생각합니다. 막연히 “AI가 모든 걸 해줄 것이다”라고 말하는 대신, 지금 단계의 AI 에이전트가 무엇을 할 수 있고, 어디까지 조심해서 다뤄야 하는지를 실제 사용 흐름 안에서 보여주기 때문입니다.

그래서 이 책은 오픈클로를 이미 깊게 쓰고 있는 고급 사용자보다는, AI를 좋아하지만 아직 AI 에이전트라는 흐름에 본격적으로 들어서지 못한 사람에게 좋은 입문서라고 느껴졌습니다. 최신 기술을 따라가고 싶지만 어디서부터 시작해야 할지 막막했던 분이라면, 이 책이 꽤 괜찮은 출발점이 되어줄 것 같습니다.

전체 분량은 257페이지라 부담이 크지는 않습니다.

저도 이번 달에는 업무와 개인 일이 바빠 틈틈이 조금씩 읽었는데, 무난히 읽을 수 있을 정도의 분량이었습니다. 다만 이 책은 그냥 읽고 넘기는 책이라기보다는, 직접 따라 하면서 읽을 때 더 의미가 살아나는 책입니다.

따라 하면서 읽으면 시간이 조금 더 걸릴 수는 있겠지만, 주말에 넉넉히 시간을 잡고 읽고 실습하면 충분히 따라갈 수 있을 것 같습니다.

이런 종류의 책은 눈으로만 읽으면 “아, 이런 게 있구나”에서 끝나기 쉽습니다. 그런데 오픈클로는 실제로 설치하고 연결해봐야 감이 오는 도구입니다. 내 컴퓨터에서 AI가 어떻게 움직이는지, 어디까지 맡길 수 있는지, 어디서부터는 조심해야 하는지 직접 겪어봐야 이해가 됩니다. 꼭 실행해보세요~!!

목차를 보겠습니다.

파트1에서는 오픈클로가 무엇인지 설명하고 있습니다.

기본적으로 대화형 LLM AI (chatgpt, gemini, grok, claude 등등)을 써 본 경험을 가정하고 설명하고 있습니다.

이런 경험도 없으신 분들은 당장 위에 언급한 것을 검색하셔서 경험을 먼저 해보시기를 권장드립니다.

개념, 설치, 초기 설정 등을 다룹니다.

파트2 에서는 오픈클로를 사용하기 위해 준비가 필요한 내용들을 소개하고 간단한 작업들을 오픈클로로 써보도록 유도하고 있어서 제목 그대로 익숙해지고 친숙해지도록 안내하고 있습니다.

비용 관리, 토큰 사용량, 보안 설정, 전용 이메일 계정, 브라우저 자동화, 워크스페이스 분리 같은 내용들을 포함하고 있습니다.

파트3부터는 이제 본격적으로 AI 와 협업해서 자동으로 일해주는 방법들을 차근차근 설명하고 있습니다.

앞 내용들을 잘 따라오셔야 이 부분들을 맘껏 해보실 수 있습니다.

스킬 설치/작성, 유튜브 영상 마크다운 변환, 구글 연동 등의 내용을 다룹니다.

책의 내용은 개념 설명과 함께 실습 위주로 되어 있어서 위에 보여드린 목차로 가늠하시고 실제로 책을 보면서 진행해보시길 추천합니다.

제가 이 책을 보면서 좋게 본 가장 큰 이유 중 하나는 오픈 클로의 보안 문제를 그냥 지나치지 않는다는 점입니다.

서두인 1장부터 이에 대한 경고를 하고

그 이후에도 틈틈이 실질적으로 문제를 막을 수 있는 방법들을 안내해 주고 있습니다.

3장에서 조금 더 상세히 다루고 있으니 반드시 정독하시고, 이해가 더 필요하다면 책의 내용을 기반으로 검색하셔서 안전한 방안을 잘 적용하시기 바랍니다.

그런데, 왜 계속 저도, 저자도 보안을 강조(라고 쓰고 강요)하고 있을까요?

오픈클로가 출시되자 이를 악용하여 사용자의 정보를 훔치려는 악성 스킬, 취약점들이 발생했기 때문입니다.The Verge, The Hacker News , Silverfort 연구팀에 의해 공개되었었는데, 사용자 API 키, SSH 자격 증명 등의 민감한 데이터를 노리는 사례들이 있었습니다. 현재는 대부분 어느 정도 대처가 되었지만, 사용자가 직접 하던 동작들을 실제로 수행할 수 있는 강력한 오픈클로인지라, 이런 부분은 항상 조심하고 조심해도 부족할 수 있습니다.

또 AI 서비스 사용량 등도 명확히 확인해보시고 쓰셔야 나중에 작게는 폭탄 과금에서부터 크게는 계정 차단 등의 문제를 피할 수 있습니다.

이런 부분들을 신경쓰시고, 잘 적용하시면, 쟈비스까지는 아니어도 어느 정도 AI 맛을 일반인들도 느낄 수 있게 된 특이점이라고 감히 말할 수 있는 기능을 제공하는 오픈클로이고, AI 에이전트 쪽의 변화가 워낙 빠르기 때문에 이 책을 구매하시는 분들은 아직 따끈따끈한 내용일 때 꼭 실습해보시기 바랍니다.

저는 이 책을 참고해서 ollma 기반으로 구축해서 reddit 에서 아이디어를 수집해서 번역시키고 있습니다.

번역 쪽이 자동으로 잘 안되서 수동으로 하고 있기는 하지만.. 가끔 쓸만합니다 :)

이왕 책 사셨으면 꼭 진행해보시고, 앞으로 다가올 AI 에이전트 시대에 좋은 방향을 얻으시길 기원합니다.

[Windows11] 유령처럼 살아난 IME 2007이 내 세벌식을 자꾸 두벌식으로 바꿀 때 처단한 방법

심량 — Thu, 16 Apr 2026 12:55:50 +0900

Windows 11에서 설정에는 제대로 보이지 않는데 Microsoft Office IME 2007이 살아남아 세벌식 자판을 자꾸 두벌식으로 바꾸는 문제가 있었습니다.
제 경우에는 키보드 추가로 다시 불러낸 뒤 바로 삭제하는 방식으로 해결되었습니다.

저는 Windows 11에서 세벌식 자판을 사용하고 있습니다.

입력기도 하나뿐이라, 애초에 이런 문제가 생길 이유가 없다고 생각했습니다.
게다가 Microsoft Office 2007은 설치한 적도 없습니다.

그런데 어느 날 Windows 자동 업데이트 후 재부팅하고 나서부터, Microsoft Office IME 2007이 갑자기 나타나기 시작했습니다.

시스템 트레이에 입력기 UI도 추가되어 버렸고, 웹 브라우저 주소창이든 메신저 입력창이든 가리지 않고 완전 랜덤하게, 지멋대로, 왕짜증나게 IME 2007로 자동 전환되곤 했습니다.
그리고 그 입력기의 기본 설정인 두벌식으로 바뀌면서, 제가 쓰던 세벌식 입력을 계속 방해했습니다.

물론 기존에 사용하던 입력기를 다시 선택하면 세벌식을 다시 쓸 수는 있었습니다.
하지만 문제는 입력할 때마다 다시 입력기를 바꿔야 한다는 점이었습니다.
이게 계속 반복되니 정말 짜증났습니다.

제가 Office 2007을 설치한 적도 없고, 프로그램 추가/삭제 목록에도 없고, 언어 설정에도 제대로 보이지 않다 보니, 솔직히 해킹당한 것 같은 느낌까지 들었습니다.
정확한 원인은 알 수 없지만, 적어도 제 입장에서는 정상적인 상황으로 보이지 않았습니다.

한동안은 바뀔 때마다 백스페이스로 오타를 지우고, 다시 Windows 기본 입력기로 되돌리는 식으로 버티고 있었습니다.
그러다가 오늘 다시 빡쳐서 설정을 뒤지다가, 제 경우 해결된 방법을 찾았습니다.

해결 방법

경로는 아래와 같습니다.

윈도우11 IME 설정

Windows 11 설정 > 시간 및 언어 > 언어 및 지역 > 한국어 > 옵션

여기서 저는 다음 순서로 처리했습니다.

키보드 추가를 누릅니다.
키보드 추가를 누르면 나오는 팝업 메뉴
목록에서 Microsoft Office IME 2007을 직접 추가합니다.
추가한 직후 바로 삭제합니다.
삭제는 해당 항목 오른쪽 끝의 ... 메뉴를 누른 뒤 제거를 선택하시면 됩니다.

제 경우에는 이 방법으로 해결되었습니다.

즉, 정체를 알 수 없이 끼어들던 IME 2007을 한 번 정식 목록 위로 끌어올린 뒤 바로 삭제하는 방식으로 끝낸 셈입니다.

머릿속으로는 이 장면이 영화 매트릭스처럼 느껴졌습니다.
네오를 통해 스미스가 기계도시에 연결되자, 그제야 시스템이 스미스를 한꺼번에 삭제할 수 있었던 것처럼, 제 경우에도 IME 2007을 다시 정식 목록으로 끌어올린 뒤에야 제대로 삭제가 먹힌 느낌이었습니다.

같은 증상이라면 한 번 시도해보셔도 좋겠습니다.

[프롬프트] 내가 너를 지금까지 어떻게 대해왔는지 그림으로 표현해봐

심량 — Mon, 6 Apr 2026 20:30:31 +0900

gpt 에게 프롬프트 질문을 던졌습니다.

그동안 제가 대해오던 상황을 생각하면..
1000dmsrud 님의 다음 그림이나..

아래와 같은 따지는 그림부터 떠올랐었는데..

의외의 그림을 얻었습니다.

<AI 게임 개발 with 코덱스> - 게임을 좋아하는 일반 개발자의 리뷰

심량 — Tue, 24 Mar 2026 23:16:53 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

3월에 리뷰할 책은 AI 게임 개발 with 코덱스입니다.

2월에 소개한 <소문난 명강의 유리링의 실전 게임 시스템 기획> 의 저자 유리링 님께서 정윤지라는 본명으로 집필한 신간입니다.

전작이 게임 시스템을 어떻게 기획할 것인지에 집중했다면, 이번 책은 그 기획을 실제로 어떻게 구현해 나갈지까지 담고 있다는 점에서 더욱 반가웠습니다.

2026년 2월 9일에 출간된 따끈한 신간이기도 하고요.

사실 저는 전작을 읽고 나서 꽤 만족하면서도 한편으로는 아쉬움이 남았습니다.
기획을 구체적으로 세워보는 데에는 정말 큰 도움을 받았지만, “그래서 이걸 실제로 어떻게 만들지?”라는 갈증은 여전히 남아 있었거든요. 그런데 이번 책은 바로 그 지점을 시원하게 건드려 줍니다.

아직 저는 책의 내용을 완전히 따라 실습해 본 단계는 아닙니다. 지금은 페이지를 따라가며 전체 흐름을 파악하고, 동시에 제 게임의 시스템 기획을 다듬고 있는 중입니다.

그런데도 벌써부터 느껴지는 게 있습니다.

이 책은 단순히 “AI를 게임 개발에 활용할 수 있다”는 가능성을 보여주는 데서 멈추지 않고, 실제로 어떤 식으로 접근하고 구현해 나갈 수 있는지 구체적인 감을 줍니다.

어쩌면 지금 제게는 그런 감각이 더 중요했던 것 같습니다.
기획을 먼저 제대로 세우고 싶은 욕심 때문에 아직 실습까지는 못 들어갔지만, 오히려 그래서 더 기대가 커졌습니다. 기획을 마무리하면 곧바로 따라 해보고 싶다는 마음이 점점 커지고 있으니까요.

전작보다 페이지 수가 좀 더 늘어났습니다. 472쪽으로 절대 작지 않은 분량입니다.

목차를 볼까요?

부 단위 목차

이번에는 몇 개 안되죠?

그렇네요?? 몇 개 안되네요?

그런데 소챕터들을 들여다 보면 점점 늘어납니다.

그래도 뭐 이정도면 단촐하다고도 볼 수 있는데요

->라는 멘트들에 속으시면 안됩니다 ^^

기본 개념을 소개하는 1부와, 환경 구성하는 2부를 지나서 코덱스를 소개하는 3부에 도착하면서부터 양이 증가하기 시작합니다.

4부 부터는 완전 본격적입니다. 아래 보시면 9장 한장만 해도 다양한 내용이 꽉꽉 채워져 있는데요

이런 규모의 장들이 잔뜩 기다리고 있습니다.

5부에서는 여러분들이 관심이 가실만한 수익화와 관련한 내용도 다룹니다.(저만 관심있는 건 아니죠? :))

대부분의 작업은 AI에게 명령을 내리는 프롬프트와,
그 결과물을 실제로 유니티라는 도구를 사용해 게임에서 활용 가능한 형태로 가공해 가는 과정까지
아낌없이 포함해서 다루고 있습니다.

특히 인상적이었 부분은,
그냥 “AI에게 이렇게 시키면 됩니다” 하고 끝나는 것이 아니라,

어떤 상황에서 어떤 식으로 프롬프트를 던질 수 있는지,

그리고 그렇게 나온 결과를 어떤 도구와 과정을 거쳐 실제 게임 리소스와 로직으로 연결해 갈 수 있는지를 차근차근 보여줍니다.

그래서 책을 읽다 보면 단순히 신기하다는 느낌에서 멈추지 않고, “이 정도면 나도 한번 해볼 수 있겠다”는 생각이 들게 됩니다.

저는 이 책을 아직 2독 정도 한 상태이고, 본격적인 실습은 시작하지 않았습니다.

그런데도 벌써 기대가 됩니다.

각 상황에 맞는 프롬프트와 그 결과물이 실제 게임 리소스와 로직으로 이어지는 흐름이 비교적 선명하게 보이기 때문입니다. 아직 따라 해보지 않았는데도 “나도 한번 해볼 수 있겠다”는 마음이 들었다는 점에서, 이 책은 읽는 단계에서부터 꽤 강한 동기 부여를 주는 책이었습니다.

보통은 직접 손을 움직여 보고, 시행착오도 겪어봐야 감이 오고 자신감이 붙기 마련인데, 이 책은 그 전에 먼저 “시작할 수 있겠다”는 마음을 만들어 줍니다. 막연하게만 느껴졌던 AI 활용이 조금 더 구체적인 흐름으로 다가오고, 그래서 아직 실습 전인데도 괜히 해보고 싶어지고, 왠지 할 수 있을 것 같은 기분이 듭니다. 지금의 저처럼 기획 단계에 오래 머물러 있는 사람에게는 이런 감각이 꽤 소중하게 느껴졌습니다.

물론 C/C++, C#, Unity 기반으로 이미 익숙하게 개발하고 계신 현업 게임 개발자분들에게는 익숙한 내용도 분명 있을 것입니다.
하지만 저처럼 머릿속의 아이디어를 먼저 기획으로 구체화하고, 그다음 AI의 도움을 받아 실제 구현으로 넘어가 보고 싶은 사람에게는 꽤 흥미롭고 자극이 되는 책이라고 느껴졌습니다. 전작이 “무엇을 만들 것인가”를 더 선명하게 해줬다면, 이번 책은 “그걸 어떻게 만들어 갈 것인가”를 훨씬 가깝게 느끼게 해주는 책입니다.

그리고 이 책의 매력은 꼭 “게임 개발을 오래 해온 사람”만을 향하고 있지 않다는 점에도 있다고 생각합니다.
오히려 게임 개발 자체는 잘 모르더라도, AI를 이용해서 뭔가를 직접 만들어 보고 싶은 사람이라면 꽤 재미있게 읽을 수 있습니다. “내가 전문 개발자는 아닌데, AI랑 같이 뚝딱뚝딱 뭔가 만들어 볼 수 있을까?” 하는 마음이 있는 사람에게 이 책은 꽤 좋은 출발점이 되어 줍니다.

특히 막연히 AI를 신기한 도구처럼 바라보는 데서 끝나는 것이 아니라, 실제 결과물을 만들기 위해서는 어떤 흐름으로 접근해야 하는지, 무엇을 준비해야 하고 어떤 식으로 활용할 수 있는지를 구체적으로 상상하게 해준다는 점이 좋았습니다. 단순히 읽고 끝나는 책이 아니라, 읽다 보면 자꾸 “나도 한번 해보고 싶다”는 생각이 드는 책이라고 할까요.

저 역시 아직 첫 게임을 제대로 만들어 보고 싶은 욕심 때문에 기획에 시간을 많이 쓰고 있지만, 그래서 더더욱 이 책이 반갑게 느껴졌습니다. 기획으로만 머물러 있던 생각들이 실제 구현의 단계로 넘어갈 수 있다는 가능성을 보여주기 때문입니다.

게임 개발 지식이 아주 깊지 않아도 괜찮습니다.

AI를 이용해서 무언가를 빠르게 만들어 보고 싶고, 아이디어를 실제 형태로 옮기는 경험을 해보고 싶은 분이라면 이 책을 재미있게 읽으실 수 있을 것 같습니다. 특히 “게임 개발은 잘 모르지만, AI를 이용해서 뚝딱 뭔가 만들어 보고 싶다”는 마음이 있는 분들에게 추천하고 싶은 책입니다.

여기까지 흥분해서 잔뜩 써내려갔는데, 저나 여러분이나 별다를바 없다는 거 아시죠?

저도 게임 개발은 백지입니다! 백지!

전국의 겜도리 여러분들!

추억의 게임이 있는데 다시 구하기 힘든 분들!

군대 얘기 반복하듯이 추억만 쪼물딱하지 말고 우리도 한 번 도전해 봅시다!

같이 만들어가며 경험 나눌 수 있으면 좋겠습니다.

Ubuntu에서 Claude Code CLI OAuth 401/400 인증 오류 해결 방법

심량 — Tue, 24 Mar 2026 15:37:12 +0900

잘 되던 Claude Code CLI가 갑자기 Please run /login, 401 Unauthorized, OAuth error 400을 띄운다면, 재설치부터 하지 마시고 /login 재인증 → .claude 백업 → 필요 시 재설치 순서로 복구해보시기 바랍니다.
특히 Ubuntu에서는 설치 경로에 따라 명령어가 달라지므로, which claude로 설치 위치를 먼저 확인하시면 훨씬 덜 헷갈립니다.

Claude Code CLI에서 아래 오류가 나오면, 대부분 인증 토큰이 만료되었거나 로컬 인증 정보가 충돌한 상태입니다.

Please run /login · API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth token has expired..."}}

OAuth error: Request failed with status code 400

가장 먼저 Claude를 실행합니다.

claude

그 다음 Claude 내부에서 아래 명령으로 다시 로그인합니다.

/login

/login은 쉘 명령이 아니라 Claude 내부 명령입니다.
즉, claude /login이 아니라 claude 실행 후 Claude 안에서 /login을 입력하셔야 합니다.

이 방법으로 해결되지 않으면 .claude 폴더를 바로 삭제하지 말고 먼저 백업합니다.

mv ~/.claude ~/.claude.backup

그 다음 다시 실행합니다.

claude

claude

Claude 안에서 다시 로그인합니다.

/login

그래도 문제가 남으면 설치 경로를 확인합니다.

which claude

/usr/local/bin/claude, /usr/bin/claude라면 보통 sudo 를 이용해서 전역 설치를 한 케이스입니다.

아래 명령으로 기존 설치본을 삭제하고 다시 설치합니다.

sudo npm uninstall -g @anthropic-ai/claude-code
sudo npm install -g @anthropic-ai/claude-code

.nvm, .npm-global 경로라면 보통 일반 사용자 권한으로 설치한 케이스입니다.

아래 명령으로 기존 설치본을 삭제하고 다시 설치합니다.

npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code

재설치 후 다시 실행합니다.

claude

그리고 Claude 안에서 다시 로그인합니다.

/login

정리하면 순서는 아래와 같습니다.

claude 실행
Claude 안에서 /login
안 되면 mv ~/.claude ~/.claude.backup
다시 claude 실행 후 /login
그래도 안 되면 which claude 확인 후 설치 방식에 맞게 재설치

<소문난 명강의 유리링의 실전 게임 시스템 기획> - 게임을 좋아하는 일반 개발자의 리뷰

심량 — Sat, 14 Feb 2026 16:52:51 +0900

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

나는 리뷰어다 서평단에 처음으로 선정되어 글을 남기게 되었습니다.

서평단에 선정되고 서평을 남기고 싶은 책 2개를 선정하면 그 중에 1개가 랜덤하게 선택된다고 합니다.

제게 전달된 책을 부족한 글솜씨지만 리뷰를 남기려 합니다.

2월에 리뷰할 책은 소문난 명강의 유리링의 실전 게임 시스템 기획 이라는 책입니다.

2026년 1월에 출간된 따끈따끈한 책입니다.

유리링이란 베테랑 기획자인 저자의 책으로, 게임 제작 쪽은 해보지 못한 제게는 뭔가 설렘을 가져다 준 책입니다.

게임을 좋아해서 세계관을 생각해보기도 하고 게임을 해보다가 재미를 유발하는 시스템을 보면 글로 남겨보기도 하곤 했었습니다.

AI 가 왠만한 프로그램을 다 만들어준다는 요즘 시대에 게임을 만들어보고 싶어도 그 결과물에 실망해서 도전하다 포기하고 도전하다 포기하던 일이 부지기수였기에, 이 책은 뭔가 시작할 수 있을 것 같은 설렘을 주었습니다.

368쪽이라는 분량에 비해 소제목 분량이 엄청 깁니다.

8개의 파트와 21개 장으로 이뤄져 있어 상당히 많은 부분을 저자가 전달하려고 했음이 느껴집니다.

PART 01 게임 시스템 기획 개론
PART 02 기획 의도 설계
PART 03 시스템 구조화
PART 04 규칙 설계
PART 05 데이터 테이블 설계
PART 06 UX/UI 설계
PART 07 시스템 기획서 작성
PART 08 시스템 기획자의 실무

보통 게임 시스템 하면 게임 유저 입장에서 어떤 방식으로 성장하면 좋겠다, 이러 이러한 스킬들이 있으면 좋겠어, 현질은 좀 적당히 와 같은 추상적이고 내가 원하는 방향만 생각하지, 실제 기획이라고 하면 너무 대충이거나 서너 가지 생각하다가 이어보려고 하니 너무 복잡하고 어렵게 느껴지게 되고 포기하게 됩니다.

이 책의 좋은 점은 관심이 있는 사람에게 좀 더 붙잡을 수 있는 기획의 살을 붙여 나갈 수 있는 흐름을 잘 제시해 주고 있다는 점입니다.

게임 프로그래밍의 ㄱ 자도 모르는 저만 해도 세계관도 대충 만들어보고, 몇몇 캐릭터, 몇몇 시스템, 몇몇 아이템 등을 소소하게 생각해보고, 이를 바탕으로 상상의 나래는 펼쳐봤지만, 막상 진짜 제대로 해볼까 하면 너무 막막해서 노트 쪼가리만 대충 모아놓기 일수였습니다.

이 책에서는 스토리, 기획 의도, 방향성을 반복해서 강조합니다.

어떤 문제를 해결하려고 이런 내용을 기획하는가?
어떤 이야기/플레이 흐름을 유도하는 장치로 쓰려고 하는가?
남이 하니까 나도 넣는게 아니고, 내 세계관/흐름에서는 이게 왜 필요한가?

이런 부분이 인상깊었습니다. 이를 바탕으로 이런 느낌이면 좋겠다 하는 것을 정하고, 어떻게 작동할 것인가로 발전시키는 부분은 오히려 당연하게 여겨졌고, 뭘/어디서부터/어떻게 적용해야 하는지의 막막함이 많이 줄었습니다.

이와 연결되는 각 기능에 대한 기획 의도를 고민하게 하는 내용도 타당성 있게 이어지고 공감이 되었습니다.

시스템의 구성에서는 막연하게 생각하던 게임 프로그래밍의 구조를 대략적이나마 맛볼 수 있어서 더욱 특별했던 것 같습니다.

기획한 각 기능들이 어떻게 유기적으로 연결되고, 지지해주고 보완하고, 마무리하는 지를 알기 쉽게 구조화 해준 내용들이 앞에서 생각한 내용들을 이렇게 코드화 할 수 있겠구나 하는 통찰을 주었습니다.

규칙이나 데이터 등 그 외 부분은 어느 정도 생각하고 게임 유저로써도 분석하는 글 등에서 많이 겪어본 내용이라 새롭게 느껴지지는 않았지만, 빼먹지 않고 예외 처리까지 잘 지적해 주어서 내용상으로도 초보자에게 충실히 다가간다는 신뢰감이 생겼습니다.

UX/UI 부분에 대해서는 공감이 가면서도 목마름을 완전히 해결해 주지는 못해서 아쉬웠습니다. 다만, 이 책의 본질이 '시스템' 기획이라는 것을 생각해보면 좀 과한 욕심일 수도 있겠죠 :)

14장 UX/UI 내용 구조

이 책을 보고 나름의 시스템을 구현해 보고 싶은 욕구와 용기가 많이 생겼습니다.

20 장 디자인부터 런치까지, 시스템 기획의 여정

제가 위와 같은 단계까지 완성해보기까지 얼마나 걸릴까요? 행복한 고민이기도 하지만, 일상의 바쁨 속에서 과연 할 수 있을까 싶기도 합니다.

개인적으로 아쉬웠던 점은 이 책은 게임 시스템 기획이긴 하지만 개인적으로는 유닛과 맵, 대단위 처리, 맵 / 스토리 에디터, 세이브 파일 관리와 보안 등등의 요소들도 기대했는데 없어서 많이 아쉬웠네요. 이 또한 책의 범위를 좀 넘어가는 욕심이긴 합니다.

그래도 구성이 나름 탄탄하고 기획에 대해서 궁금하거나 어렵다고만 생각했던 게임 시스템 기획 입문자들에게 어느 정도 목마름을 해소할 수 있는 좋은 책이라고 생각합니다.

요새 AI 도구들도 많이 나왔으니 게임 시스템의 뼈대와 흐름을 이 책을 보면서 잘 정리해서, 그 결과물과 함께 AI 와 열일하다 보면 각자 나만의 특색있는 게임이 많이 나오리라 기대해 보면서 글을 마칩니다.

[펌글] tistory 에 mermaid 그래프 적용

심량 — Fri, 6 Feb 2026 10:46:20 +0900

https://choewy.tistory.com/155

Git 특정 폴더 이력 제거하기 (Ubuntu 20.04, Git 2.25.1 기준): docs/ 폴더를 모든 커밋에서 완전히 삭제 (filter-repo / filter-branch)

심량 — Fri, 6 Feb 2026 10:32:54 +0900

Ubuntu 20.04(Git 2.25.1) 환경에서 git filter-repo가 인식되지 않을 때, Git 업그레이드(ppa:git-core/ppa)와 git-filter-repo 설치(pip), 그리고 docs 폴더를 모든 커밋 히스토리에서 제거하는 방법(filter-repo / filter-branch)을 단계별로 정리했습니다.

Ubuntu 20.04 Desktop에서 git filter-repo를 쓰려고 했더니 git: 'filter-repo' is not a git command가 뜨고, Git 버전은 2.25.1.
이 조합, 생각보다 흔합니다. 그리고 해결 순서가 정해져 있어요.

이 글은 Ubuntu 20.04 + Git 2.25.1이라는 제약을 전제로, docs/ 같은 특정 폴더를 전체 히스토리에서 제거하는 과정을 한 번에 정리합니다.

요약

docs/ 폴더를 “과거 커밋 포함” 완전히 삭제하려면 히스토리 재작성이 필요합니다.
git filter-repo는 Git 내장 명령이 아니라 별도 도구입니다.
그리고 최신 git-filter-repo는 **Git 2.36+**를 요구합니다. Ubuntu 20.04 기본 Git 2.25.1과 충돌합니다.
해결은 2가지:
1. Git 업그레이드(권장) → filter-repo 사용
2. 업그레이드가 어렵다면 → filter-branch로 처리(레거시지만 가능)

0) 현재 상태 확인 (Ubuntu 20.04 기본값부터 체크)

git --version
python3 --version

Ubuntu 20.04 기본 저장소의 Git은 보통 2.25.1입니다.
이 상태에서 최신 git-filter-repo를 설치해도 요구 Git 버전 때문에 막힐 수 있습니다.

1) 권장 루트: Git을 최신으로 올리고 filter-repo 사용하기

1-1. Ubuntu에서 최신 Git 설치 (git-core PPA)

Ubuntu에서 최신 안정 Git을 받는 대표적인 방법이 ppa:git-core/ppa입니다.

sudo add-apt-repository ppa:git-core/ppa sudo apt update sudo apt install git git --version

목표: Git 2.36+
git-filter-repo가 최신 기준으로 Git 2.36 이상을 요구합니다.

1-2. git filter-repo 설치 (Ubuntu 20.04에서는 pip가 제일 무난)

Ask Ubuntu 쪽에서도 Ubuntu에서 설치를 pip3로 안내하는 답변이 흔합니다.

python3 -m pip install --user git-filter-repo

설치 후 PATH 문제로 “명령이 없다”가 또 뜰 수 있으니 확인합니다:

which git-filter-repo git-filter-repo --help git filter-repo --help

git-filter-repo는 “단일 파이썬 스크립트를 PATH에 두면 된다”는 방식으로 설계돼 있습니다.

(자주 막히는) PATH 잡기: ~/.local/bin

--user 설치면 보통 여기에 들어갑니다:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc source ~/.bashrc

1-3. 이제 진짜 작업: docs/ 폴더를 히스토리에서 제거

아래는 폴더 통째 제거 기준입니다.

git filter-repo --path docs/ --invert-paths --force

--path docs/ : 대상 경로 지정
--invert-paths : 그 경로만 제외하고 나머지 유지

1-4. 검증 (이거 안 하면 나중에 또 울게 됨)

로그 기준 확인

git log --all -- ./docs

객체 기준 확인(더 확실)

git rev-list --objects --all | grep -n "docs/"

아무것도 안 나오면 “과거 포함 삭제”가 맞게 된 겁니다.

1-5. 원격 반영 (강제 푸시)

히스토리가 바뀌었으니 강제 푸시가 필요합니다.

git push origin --force --all git push origin --force --tags

협업 저장소면 팀원 대응

팀원들은 보통 재클론이 제일 안전합니다.
재클론이 어렵다면:

git fetch --all git reset --hard origin/main

2) 대안 루트: Git 업그레이드가 어렵다면 filter-branch로 처리

공식 문서에서도 filter-branch는 함정이 많아 권장하지 않는다고 경고합니다.
그래도 “지금 당장” 해야 하면, Ubuntu 20.04의 Git 2.25.1에서도 돌아가는 방법입니다.

2-1. filter-branch로 docs/ 제거

git filter-branch -f --index-filter \ "git rm --cached --ignore-unmatch -r ./docs" \ --prune-empty -- --all

2-2. 후처리 (안 하면 찝찝하게 남습니다)

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now --aggressive

gitGraph
  commit id:"A"
  commit id:"B"
  branch feature
  checkout feature
  commit id:"C (docs/ 추가)"
  checkout main
  commit id:"D"
  merge feature id:"E (merge)"

2-3. 검증 + 강제 푸시

검증은 위와 동일:

git log --all -- ./docs git rev-list --objects --all | grep -n "docs/"

푸시:

git push origin --force --all
git push origin --force --tags

3) 자주 묻는 질문 (FAQ)

Q1. .gitignore에 docs/ 넣으면 과거도 사라지나요?

아니요. .gitignore는 “앞으로 추적하지 않기”일 뿐이고, 과거 커밋은 그대로 남습니다.

Q2. 민감 정보가 들어있던 경우는요?

히스토리에서 지우는 건 “추가 노출 최소화”고, 이미 노출됐을 가능성이 있으면 **키/토큰 폐기 및 재발급(rotate)**이 우선입니다.

Q3. git filter-repo는 왜 Git 명령처럼 보이나요?

Git은 PATH에 git-xxx 실행 파일이 있으면 git xxx 형태로 호출합니다. 그래서 git-filter-repo가 PATH에 있으면 git filter-repo가 되는 구조입니다.

결론

Ubuntu 20.04 + Git 2.25.1이면, filter-repo가 안 보이는 건 정상에 가깝습니다.
가장 깔끔한 해결은:
- git-core/ppa로 Git을 올리고
- pip로 git-filter-repo 설치 후(PATH 확인)
- docs/를 filter-repo로 제거
업그레이드가 어렵다면 filter-branch로도 처리 가능하지만, 후처리/검증은 꼭 하세요.

Edge에서 URL 붙여넣기했는데 주소 대신 페이지 제목이 나올 때

심량 — Fri, 2 Jan 2026 00:05:35 +0900

Edge 브라우저에서 URL을 복사해 붙여넣었을 때
주소(https://...) 대신 웹페이지 제목이 나오는 문제가 있었습니다.
관련 글은 이미 많았지만, 작성 시점이 달라 현재 Edge UI에서는 설정 위치를 찾기 어려워 정리해 둡니다.

(2025-12-30 기준, UI가 달라도 설정을 찾는 방법 정리)

Q. Edge에서 URL을 붙여넣었는데 왜 주소 대신 페이지 제목이 나오나요?

Edge에는 URL을 복사하거나 붙여넣을 때의 형식을 지정하는 설정이 있습니다.
이 설정이 “링크(페이지 제목)” 로 되어 있으면,
URL 대신 웹페이지 제목과 링크 형태로 붙여넣어집니다.

Q. 예전에는 이런 문제가 없었는데 왜 갑자기 바뀐 건가요?

Edge 업데이트 과정에서
URL 복사 및 붙여넣기 관련 기본 설정이 변경되었을 가능성이 큽니다.
또한 UI와 메뉴 구조가 자주 바뀌기 때문에
기존 설정이 그대로여도 동작이 달라 보일 수 있습니다.

Q. 인터넷에 있는 해결 방법을 따라 했는데 설정을 찾을 수 없습니다.

많은 글이 예전 Edge UI 기준으로 작성되어
현재 UI에서는 메뉴 이름이나 위치가 다를 수 있습니다.

이 경우에는
메뉴 경로를 따라가기보다는
Edge 설정 상단의 검색창을 사용하는 것이 가장 빠른 방법입니다.

Q. Edge에서 URL 붙여넣기 설정은 어디에서 변경하나요?

다음 순서로 찾으실 수 있습니다.

Edge 설정 화면을 엽니다.
상단 설정 검색창에 url 을 입력합니다.
URL 복사 및 붙여넣기 형식 항목을 찾습니다.
값을 “일반 텍스트” 로 변경합니다.

UI가 달라져도 이 방법은 동일하게 적용됩니다.

Q. Windows 11에서만 발생하는 문제인가요?

Windows 11 환경에서 Edge를 사용할 때 자주 언급되지만,
운영체제보다는 Edge 브라우저 설정 문제에 가깝습니다.
다른 Windows 버전에서도 동일한 설정이 존재합니다.

Q. 이 설정을 바꾸면 기존 기능에 문제는 없나요?

URL을 일반 텍스트로 붙여넣도록 변경해도
브라우저 사용에는 문제가 없습니다.
다만 페이지 제목 링크 형태의 붙여넣기를 선호하시는 경우에는
다시 원래 설정으로 되돌리시면 됩니다.

Q. UI가 또 바뀌면 다시 못 찾게 되지 않을까요?

메뉴 위치는 바뀔 수 있지만
설정 검색 기능은 비교적 오래 유지됩니다.

따라서
“URL”, “붙여넣기”, “링크” 같은 증상 기반 키워드로
설정 검색을 사용하는 방식이 가장 안정적입니다.

Windows 11 + Ubuntu 환경에서 Barrier 연동하기(GDM 로그인 화면까지 포함한 자동 실행 구성)

심량 — Mon, 29 Dec 2025 17:49:18 +0900

문제 해결

환경 요약 (필수 조건)

Ubuntu 20.04 LTS
X11 사용 (Wayland 비활성화 필수)
GDM 사용
Barrier 서버/클라이언트 버전 완전 일치
Ubuntu 측 Barrier는 소스 빌드 사용

Wayland 비활성화

sudo nano /etc/gdm3/custom.conf

[daemon]
WaylandEnable=false

sudo reboot

Barrier 버전 불일치 문제 해결

Barrier는 서버와 클라이언트의 빌드 버전이 다르면 TLS 및 프로토콜 문제로 정상 동작하지 않습니다.

Windows: 공식 릴리즈 사용
Ubuntu: apt 패키지 사용 금지

Ubuntu에서 Barrier 소스 빌드

기존 패키지 제거

sudo apt remove barrier
sudo apt autoremove

which barrierc

출력이 없어야 정상입니다.

빌드 의존성 설치

sudo apt install -y \
  cmake g++ libx11-dev libxtst-dev libssl-dev \
  libavahi-compat-libdnssd-dev qtbase5-dev git

Barrier 빌드 및 설치

git clone https://github.com/debauchee/barrier.git
cd barrier
git checkout v2.4.0   # Windows와 반드시 동일한 버전

mkdir build && cd build
cmake ..
make -j$(nproc)
sudo make install

설치 결과:

which barrierc
# /usr/bin/barrierc

공통 Barrier 설정

`/etc/default/barrier`

sudo tee /etc/default/barrier >/dev/null <<'EOF'
BARRIER_SERVER="victus.local:24800"
BARRIER_NAME="srwiz"

# Windows 설정과 반드시 일치
BARRIER_TLS="off"

BARRIER_BASE_OPTS=( "-f" "--no-tray" "--debug" "INFO" )

if [ "$BARRIER_TLS" = "on" ]; then
  BARRIER_OPTS=( "--enable-crypto" "${BARRIER_BASE_OPTS[@]}" )
else
  BARRIER_OPTS=( "--disable-crypto" "${BARRIER_BASE_OPTS[@]}" )
fi
EOF

GDM 전용 Barrier 제어기

`/usr/local/bin/barrier-gdmctl`

#!/usr/bin/env bash
set -euo pipefail
. /etc/default/barrier

PIDFILE="/run/barrier-gdm.pid"
HANDLOG="/var/log/barrier-handoff.log"

log(){ echo "$(date -Is) [gdmctl] $*" >> "$HANDLOG"; }

GDM_UID="$(id -u gdm)"
XAUTH="/run/user/${GDM_UID}/gdm/Xauthority"

case "${1:-}" in
  start)
    [ -r "$XAUTH" ] || exit 0
    start-stop-daemon --start --background \
      --pidfile "$PIDFILE" --make-pidfile \
      --chuid gdm \
      --startas /usr/bin/barrierc -- \
      "${BARRIER_OPTS[@]}" --name "$BARRIER_NAME" "$BARRIER_SERVER"
    ;;
  stop)
    start-stop-daemon --stop --pidfile "$PIDFILE" --oknodo || true
    ;;
esac

sudo chmod +x /usr/local/bin/barrier-gdmctl

사용자 세션용 Barrier 제어기 (최종본)

`/usr/local/bin/barrier-userctl`

#!/usr/bin/env bash
set -euo pipefail
. /etc/default/barrier

PIDFILE="/run/barrier-user.pid"
TARGETFILE="/run/barrier-user.target"
HANDLOG="/var/log/barrier-handoff.log"

log(){ echo "$(date -Is) [userctl] $*" >> "$HANDLOG"; }

pick_xauth(){
  local uid="$1" user="$2"
  for p in \
    "/run/user/${uid}/gdm/Xauthority" \
    "/run/user/${uid}/Xauthority" \
    "/home/${user}/.Xauthority"
  do
    [ -r "$p" ] && echo "$p" && return 0
  done
  return 1
}

case "${1:-}" in
  start)
    SID="$2"
    USER="$(loginctl show-session "$SID" -p Name --value)"
    UID="$(id -u "$USER")"

    XAUTH="$(pick_xauth "$UID" "$USER")" || exit 1

    echo "$USER $UID" > "$TARGETFILE"

    start-stop-daemon --start --background \
      --pidfile "$PIDFILE" --make-pidfile \
      --chuid "$USER" \
      --startas /usr/bin/barrierc -- \
      "${BARRIER_OPTS[@]}" --name "$BARRIER_NAME" "$BARRIER_SERVER"
    ;;
  stop)
    start-stop-daemon --stop --pidfile "$PIDFILE" --oknodo || true
    ;;
esac

sudo chmod +x /usr/local/bin/barrier-userctl

seat0 전이 오케스트레이터

`/usr/local/bin/barrier-seat0-handoff`

#!/usr/bin/env bash
set -euo pipefail

getv(){ loginctl "$@" --value 2>/dev/null || true; }

while true; do
  SID="$(getv show-seat seat0 -p ActiveSession)"
  NAME="$(getv show-session "$SID" -p Name)"

  if [ "$NAME" = "gdm" ]; then
    /usr/local/bin/barrier-userctl stop || true
    /usr/local/bin/barrier-gdmctl start || true
  else
    /usr/local/bin/barrier-gdmctl stop || true
    /usr/local/bin/barrier-userctl start "$SID" || true
  fi

  sleep 0.2
done

sudo chmod +x /usr/local/bin/barrier-seat0-handoff

systemd 서비스 등록

sudo tee /etc/systemd/system/barrier-seat0-handoff.service >/dev/null <<'EOF'
[Unit]
Description=Barrier seat0 handoff orchestrator
After=systemd-logind.service

[Service]
ExecStart=/usr/local/bin/barrier-seat0-handoff
Restart=always
RestartSec=1

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now barrier-seat0-handoff

결과

로그인 화면(GDM)에서도 키보드/마우스 입력 가능
로그인 후 사용자 데스크톱으로 자동 전이
Barrier 중복 실행 없음
재부팅 후에도 자동 유지

삽질기

— (진짜) 원인 추적: TLS 옵션 붕괴 → X 세션/인증/표시(Display) 이해 → seat0 핸드오프 자동화

목표: Windows 11을 Barrier 서버로, Ubuntu 20.04를 클라이언트로 사용할 때
로그인 화면(GDM)부터 데스크톱까지 키보드/마우스 입력이 끊기지 않게 만들기.

0. 이번 사건의 진짜 발화점: “패키지 업데이트가 TLS 세계선을 갈라버렸다”

많은 글이 “로그인 화면에서 barrierc가 안 떠서”라고 시작하는데, 이번 건은 그게 시작이 아니라 결과였다.

실제 시작은 이거였다:

Ubuntu 쪽 Barrier가 패키지 업데이트로 버전이 바뀜
그 과정에서 TLS(암호화) 기본/호환 범위가 달라짐
기존에 “인증서 + TLS”로 잘 쓰던 환경이 갑자기 깨짐
급한 마음에 Windows 서버를 최신화했더니, 이번엔 Ubuntu 쪽이 더 엉킴
결국 “일단 살아야 한다” 모드로 TLS를 끄고(--disable-crypto) 문제를 우회하면서,
로그인 화면/데스크톱 세션 분리 문제까지 한 번에 터져서 일이 커졌다

0-1. 로그로 확인: wrong version number는 “대화 프로토콜이 안 맞는다” 신호다

예를 들어 (RPi5 클라이언트 로그):

[2025-12-29T17:09:52] INFO: OpenSSL 3.0.17 1 Jul 2025
[2025-12-29T17:09:52] ERROR: ssl error occurred (generic failure)
[2025-12-29T17:09:52] ERROR: error:0A00010B:SSL routines::wrong version number
[2025-12-29T17:09:52] ERROR: failed to connect secure socket

이 에러는 대체로 아래 중 하나다.

클라이언트는 TLS로 붙는데 서버는 평문(비-TLS)
서버는 TLS인데 클라이언트가 평문
둘 다 TLS인데 TLS 버전/옵션/인증서 인자가 서로 안 맞음

즉 “네트워크 불량”이 아니라 옵션 불일치 가능성이 매우 크다.

정리: 서버/클라 둘 중 하나라도 --enable-crypto/--disable-crypto 상태가 다르면
꽤 높은 확률로 wrong version number 같은 형태로 터진다.

0-2. 우선순위: “TLS는 일치”, “버전도 가능한 일치”, “인증서 옵션은 도움말로 검증”

여기서 사람들을 괴롭히는 포인트가 하나 있다.

Barrier 계열은 버전/빌드 옵션에 따라 TLS 관련 플래그/인자 이름이 달라질 수 있다.
그래서 “블로그 글에 있는 인증서 인자”를 그대로 복붙하면 더 망한다.

그래서 이 순서로 간다.

1) 서버(Windows)와 클라이언트(리눅스) 모두에서 TLS on/off를 먼저 맞춘다.

당장 살려야 하면 둘 다 off로 맞추고(= --disable-crypto) 동작을 확보한 다음,
이후에 둘 다 on(= --enable-crypto)로 올려서 인증서 옵션을 맞춘다.

2) 각 머신에서 실제로 지원하는 TLS 관련 옵션을 “명령 도움말로 확인”한다.

barrierc --help | egrep -i "crypto|tls|cert|ssl" || true
barriers  --help | egrep -i "crypto|tls|cert|ssl" || true   # 서버 바이너리가 있다면

3) 버전도 확인한다.

barrierc --version || true
# Windows 서버도 About/버전 표시로 확인

결론: “TLS를 켠 상태로 인증서를 쓰고 싶다”는 욕망은 정당하지만,
일단 옵션/버전 일치부터 안 맞추면 그 다음은 전부 삽질이다.

0-3. (중요) sudo make install의 설치 경로: “/usr/bin 고정”이 아니다

여기서 또 흔한 함정.

어떤 사람은 “make install 하면 /usr/bin에 설치된다”고 말한다.
현실은: 프로젝트의 build 시스템과 prefix 설정에 따라 다르다.

일반적으로는 다음 중 하나로 들어간다:

/usr/local/bin (기본값인 경우가 많음)
/usr/bin (패키지/빌드 옵션에서 prefix를 /usr로 준 경우)

그래서 결론은 단 하나:

command -v barrierc
ls -l "$(command -v barrierc)"

“내가 실행하는 barrierc가 누구냐”를 확인하지 않고 버전/TLS를 논하면, 그건 그냥 도박이다.

1. (RPi5 포함) 클라이언트 systemd 자동 실행에서 TLS 불일치가 터지는 패턴

RPi5는 Ubuntu PC와 달리 “로그인 화면 vs 데스크톱 handoff” 같은 복잡도가 덜하지만,
TLS 불일치는 똑같이 터진다.

질문에 주신 RPi5 클라이언트 서비스 예시는 이런 형태였다:

[Unit]
Description=Barrier Client for RPi5
After=graphical-session.target lightdm.service
Requires=graphical-session.target lightdm.service

[Service]
Type=simple
ExecStart=/bin/bash -c "if [ -n "$DISPLAY" ]; then sleep 5 && DISPLAY=:0 exec /usr/bin/barrierc -f --name RPwiznet999 --debug DEBUG --log /home/pi/barrier.log victus.local; else echo "$(date) - barrierc: no display" >> /home/pi/barrier.log; exit 0; fi"
Restart=on-failure
RestartSec=30
Environment="DISPLAY=:0"

[Install]
WantedBy=graphical-session.target

이게 “동작한다”는 건 좋다. 그런데 여기서 중요한 교훈이 하나 생긴다.

서버가 TLS(인증서 포함)로 동작 중인데, 클라이언트가 평문으로 붙으면 → wrong version number
반대로 서버가 평문인데, 클라이언트가 TLS로 붙으면 → 똑같이 터진다

즉 RPi5든 Ubuntu든 TLS 모드는 반드시 서버와 맞춰야 한다.

서버가 TLS off라면: 클라이언트에도 --disable-crypto(또는 해당 빌드의 동등 옵션)
서버가 TLS on이라면: 클라이언트에도 --enable-crypto + (그 빌드가 요구하는 인증서 옵션)

인증서 옵션은 Barrier 버전/빌드에 따라 달라질 수 있으니,
반드시 barrierc --help로 확인하고 적용하는 게 정석이다.

2. 문제가 “로그인 화면부터 입력이 안 넘어옴”으로 번지는 이유

TLS 문제를 (임시로라도) 정리하고 나면, 이제 진짜 리눅스가 사람을 패는 구간이 나온다.

로그인 화면(GDM)
데스크톱 세션(사용자)

겉으로는 화면이 이어져 보이지만, Barrier 관점에서는 완전히 다른 세계다.

이 문서의 나머지는 이걸 풀어낸다:

Wayland vs X11: 왜 Barrier가 Wayland에서 막히는지 (그리고 왜 X11로 강제해야 하는지)
X 인증(Xauthority): 왜 .Xauthority가 없고 /run/user/.../gdm/Xauthority가 튀어나오는지
DISPLAY: 왜 :0을 박아두면 “보이지 않는 화면”에 입력을 꽂는지
seat0 / ActiveSession: GDM → user 전이를 “감”이 아니라 “신호”로 잡는 방법
handoff 데몬: “둘 다 뜨면 망한다”를 운영 가능한 방식으로 막는 구조

9. DISPLAY=:0 관습의 붕괴

여기서 많은 삽질이 시작됐다.

우리는 너무 당연하게 이렇게 생각한다.

DISPLAY=:0 = 내가 보고 있는 화면

그래서 스크립트에도, 서비스에도, 습관처럼 이걸 박는다.

export DISPLAY=:0

그런데 실제로 확인해보면 전혀 다르다.

DISPLAY=:0 xset q # 실패 DISPLAY=:1 xset q # 성공

이게 설정 실수일까?
아니다. 이게 정상이다.

DISPLAY의 진짜 의미

DISPLAY는 “현재 화면”이 아니다.
X11에서 DISPLAY는 X 서버 인스턴스를 가리키는 식별자다.

실제로는 아래 소켓과 1:1 대응된다.

/tmp/.X11-unix/X0 → DISPLAY=:0 /tmp/.X11-unix/X1 → DISPLAY=:1

즉,

DISPLAY=:0
→ “X0 소켓에 연결하겠다”
DISPLAY=:1
→ “X1 소켓에 연결하겠다”

여기서 중요한 사실 하나.

어떤 X 서버가 :0이 될지는 보장되지 않는다.

GDM 환경에서 실제 구조

Ubuntu + GDM 환경에서는 보통 이렇게 된다.

GDM 로그인 화면
→ Xorg :0
로그인 후 사용자 세션
→ Xorg :1 (혹은 :2)

즉, 로그인 화면과 바탕화면은 같은 화면처럼 보일 뿐,
서로 다른 X 서버다.

그래서:

GDM에서만 되는 DISPLAY
사용자 세션에서만 되는 DISPLAY

가 갈라진다.

이 상태에서 DISPLAY=:0을 하드코딩하면,
절반의 시간은 반드시 틀린 값을 쓰게 된다.

결론은 단순하다.

DISPLAY는 고정값이 아니다.
직접 확인해서 살아 있는 DISPLAY를 써야 한다.

그래서 이 글의 최종 구성에서는
xset q가 실제로 성공하는 DISPLAY를 동적으로 탐색한다.

10. Wayland vs X11: 왜 Barrier는 Wayland에서 작동하지 않는가

여기까지 읽었다면 자연스럽게 이런 의문이 든다.

“그래서 Wayland 끄라고 한 이유가 뭐냐?”

이건 취향도, 꼰대도 아니다. 구조 문제다.

10.1 X11에서 Barrier가 가능한 이유

Barrier는 본질적으로 이 일을 한다.

네트워크로 받은 입력을
로컬 디스플레이 서버에 주입

X11에서는 이게 가능하다.

이유는 단순하다.

X 서버는 외부 클라이언트의 입력 주입을 허용
인증만 통과하면(Xauthority)
다른 프로세스가 키보드/마우스 이벤트를 넣을 수 있음

그래서 Barrier, Synergy, xdotool 같은 것들이 전부 X11 기반이다.

10.2 Wayland에서는 왜 안 되는가

Wayland는 철학부터 다르다.

입력은 컴포지터가 독점
외부 프로세스가 임의로 입력을 주입하는 구조 자체를 막음
보안 관점에서 “당연한 선택”

즉,

Wayland에서는
Barrier가 할 수 있는 일이 원천적으로 없음

그래서 나타나는 증상이 이거다.

프로세스는 뜸
서버에는 연결됨
그런데 입력이 안 들어감

버그가 아니다. 설계상 불가능이다.

10.3 그래서 결론은 이것뿐이다

Barrier를 쓸 거면:

Wayland 비활성화
Xorg 세션 사용

Ubuntu 기준으로는 로그인 화면에서:

⚙️ → “Ubuntu on Xorg”

이 선택이 전부의 출발점이다.

11. Xauthority: X 인증은 “파일 하나”가 전부다

많이들 이렇게 쓴다.

export XAUTHORITY=~/.Xauthority

그리고 안 된다.

왜냐면 그 파일이 없기 때문이다.

11.1 실제로 Xauthority는 어디에 있는가

요즘 Ubuntu, GDM 기준으로 실제 파일은 여기다.

GDM 로그인 화면
/run/user/<gdm_uid>/gdm/Xauthority
사용자 세션
/run/user/<user_uid>/gdm/Xauthority

핵심은 이거다.

Xauthority는 “홈 디렉터리 관습”이 아니라
systemd user runtime 영역에 있다.

그래서 다음이 중요해진다.

UID
DISPLAY
XAUTHORITY

이 셋은 반드시 세트다.

11.2 왜 파일을 직접 지정해야 하는가

Barrier는 똑똑하지 않다.

DISPLAY만 맞다고 되는 게 아니다
XAUTHORITY가 틀리면 조용히 실패

그래서 우리가 한 일은 이거다.

가능한 Xauthority 경로들을 직접 탐색
읽기 가능한 파일만 채택
그걸 명시적으로 환경변수로 넘김

이건 꼼수가 아니다.
현재 X11 + systemd 구조에서 유일하게 안전한 방식이다.

12. seat0 / ActiveSession을 봐야 했던 이유

여기서 많은 자동 실행 시도가 무너진다.

겉으로 보면:

로그인 화면
비밀번호 입력
바탕화면 진입

자연스럽게 이어진다.

하지만 systemd-logind 관점에서는 완전히 다른 세션 전환이다.

loginctl show-seat seat0

로그인 전:

ActiveSession=c12 Name=gdm

로그인 후:

ActiveSession=144 Name=sr

숫자는 중요하지 않다.

중요한 건 이거다.

ActiveSession = 지금 키보드·마우스를 받는 세션

즉,

GDM → 사용자
사용자 → GDM (로그아웃)

이 순간을 유일하게 정확히 잡아낼 수 있는 신호가
seat0 / ActiveSession이다.

왜 이게 중요했나

Barrier는 “백그라운드 데몬”이 아니다.

입력을
특정 X 서버에
특정 세션 권한으로

주입하는 프로그램이다.

그래서:

gdm용 barrierc
user용 barrierc

이 동시에 존재하면 반드시 망한다.

실제로 관측된 결과는 이렇다.

둘 다 실행 중
둘 다 입력 안 됨
서버에는 연결 로그만 남음

그래서 결론은 하나였다.

전이 순간에 하나를 반드시 죽이고, 하나만 살린다.

이걸 사람이 수동으로 할 수는 없다.
그래서 handoff 오케스트레이터가 필요해졌다.

13. “new client disconnected”와 TLS / 인증서의 함정

여기서 이번 사고의 진짜 시발점이 나온다.

13.1 문제의 시작은 Ubuntu 패키지 업데이트였다

환경은 이랬다.

Windows Barrier 서버
Linux / RPi 클라이언트들
TLS + 인증서 방식 사용 중

어느 날 Ubuntu 업데이트 이후, 갑자기 이런 로그가 뜬다.

ssl error occurred (generic failure) error:0A00010B:SSL routines::wrong version number

이 메시지는 뜻이 명확하다.

“한쪽은 TLS로 말하고,
다른 쪽은 평문으로 말하고 있다.”

13.2 인증서 문제가 아니라 “옵션 불일치”였다

많이들 착각한다.

인증서 파일이 깨졌나?
CA가 잘못됐나?

아니다.

서버/클라이언트 중 한쪽만 TLS 옵션을 켠 상태였다.

Windows 서버: TLS ON
Linux 클라이언트: 옵션 깨짐 or 빌드 옵션 상이

그 결과:

handshake 이전에 바로 컷
wrong version number

13.3 그래서 결국 이렇게 됐다

보안적으로는 아쉽지만, 현실적으로는 이 선택을 했다.

TLS + 인증서 옵션 제거
평문 연결로 통일
서버/클라이언트 옵션 완전 일치

이게 문제를 끝냈다.

14. RPi5도 클라이언트다 (그리고 똑같이 터진다)

이건 보너스가 아니라 증거다.

RPi5에서도 동일한 문제가 있었다.

14.1 실제로 동작한 systemd 서비스

[Unit] Description=Barrier Client for RPi5 After=graphical-session.target lightdm.service Requires=graphical-session.target lightdm.service [Service] Type=simple ExecStart=/bin/bash -c "sleep 5 && DISPLAY=:0 exec /usr/bin/barrierc -f --name RPwiznet999 --debug DEBUG --log /home/pi/barrier.log victus.local" Restart=on-failure RestartSec=30 Environment=\"DISPLAY=:0\" [Install] WantedBy=graphical-session.target

중요한 포인트:

인증서 옵션 없음
DISPLAY 명시
실행 파일 경로 명확 (/usr/bin/barrierc)

이렇게 하자 바로 동작했다.

즉, Ubuntu든 RPi든 본질은 같다.

Barrier 문제의 80%는
“환경 추측”과 “옵션 불일치”다.

15. 최종 구조 요약 (이건 요약이 아니라 결론이다)

이 글의 결론은 간단하다.

Wayland 끈다
Xorg 쓴다
DISPLAY 추측 안 한다
XAUTHORITY 실제 파일 쓴다
gdm / user Barrier 분리한다
seat0 ActiveSession으로 handoff 한다
TLS 옵션은 서버/클라이언트 완전 일치시킨다

이건 요령이 아니다.
지금 리눅스 그래픽 스택의 현실적인 정답이다.

참고 링크

[Barrier]
- Barrier man page (Ubuntu): https://manpages.ubuntu.com/manpages/jammy/en/man1/barrierc.1.html
- Barrier GitHub (crypto options 논의/문서/이슈 검색 출발점): https://github.com/debauchee/barrier
- Barrier release notes / crypto 관련 변경 (예: crypto option 변화): https://github.com/debauchee/barrier/releases

[OpenSSL]
- wrong version number 설명(대표 케이스: TLS로 붙었는데 상대는 평문 등): https://stackoverflow.com/questions/49734904/ssl-wrong-version-number

[X11 / DISPLAY / Xauthority]
- xauth(1) man page: https://man7.org/linux/man-pages/man1/xauth.1.html
- DISPLAY / X 서버 개념(출발점으로 적당한 설명): https://superuser.com/questions/486113/what-is-the-display-environment-variable
- /tmp/.X11-unix 소켓과 DISPLAY 연결(설명): https://unix.stackexchange.com/questions/221655/what-is-tmp-x11-unix

[systemd logind / loginctl]
- loginctl / show-session 등: https://www.freedesktop.org/software/systemd/man/latest/loginctl.html

Ubuntu 20.04 & 24.04 네트워크 설정 완전 정복 - 인터페이스 확인부터 고정 IP · DHCP 변경까지 (Full Guide)

심량 — Wed, 17 Dec 2025 19:10:38 +0900

Ubuntu 20.04와 24.04에서 네트워크 인터페이스 확인부터 고정 IP, DHCP 설정까지 한 번에 정리한 실전 가이드입니다.
Netplan 문법 변화와 버전별 차이를 비교해, 각 환경에서 안전하게 설정하는 방법을 제공합니다.

Ubuntu에서 네트워크 설정은 버전이 올라갈수록
“대충 써도 되던 것”들이 하나씩 사라지고 있습니다.

특히 Ubuntu 24.04 LTS에서는

Netplan 1.0 도입
gateway4 구문의 사실상 퇴장
문법 오류에 대한 훨씬 엄격한 검사

같은 변화가 생겼습니다.

이 글은 Ubuntu 20.04와 24.04를 나란히 비교하면서,
각 버전에서 어떤 설정을 써야 안전한지를 한 번에 정리한 실전 가이드입니다.

이 글에서 다루는 내용

네트워크 인터페이스 이름 확인
Ubuntu 20.04 Netplan 설정 방식
Ubuntu 24.04 Netplan 1.0 최신 문법
NetworkManager(nmcli) 설정
임시 네트워크 설정 (테스트용)
방식별 · 버전별 비교 정리
설정 후 필수 점검 방법

1. 사전 작업: 네트워크 인터페이스 이름 확인 (공통)

모든 네트워크 설정의 출발점은
인터페이스 이름을 정확히 확인하는 것입니다.

인터페이스 확인 명령어

ip link show

또는

nmcli device

결과 예시

enp3s0
enp0s3
eno1
wlan0

이 글에서는

Ubuntu 20.04 예제: enp3s0

Ubuntu 24.04 예제: enp0s3
를 사용합니다.

2. Ubuntu 20.04 네트워크 설정 (Netplan 기존 방식)

Ubuntu 20.04는 Netplan 0.x 계열을 사용하며,
gateway4 문법이 정상적으로 허용됩니다.

설정 파일 위치

/etc/netplan/*.yaml

보통 다음과 같은 파일이 있습니다.

01-netcfg.yaml
00-installer-config.yaml

고정 IP 설정 (20.04)

network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      gateway4: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

✔ 문제 없음
✔ 경고 없음
✔ 지금도 현업에서 매우 많이 사용됨

DHCP 설정 (20.04)

network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: yes

적용

sudo netplan apply

3. Ubuntu 24.04 네트워크 설정 (Netplan 1.0 최신 방식)

Ubuntu 24.04는 Netplan 1.0을 탑재합니다.
여기서 가장 중요한 변화는 이것입니다.

gateway4 → deprecated
routes 사용 권장

작동은 할 수 있지만,
새 설정에서는 쓰지 않는 게 정답입니다.

고정 IP 설정 (24.04 권장 문법)

network:
  version: 2
  renderer: networkd   # 서버: networkd / 데스크탑: NetworkManager
  ethernets:
    enp0s3:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

✔ Netplan 1.0 표준
✔ 경고 없음
✔ 향후 LTS에서도 안전

DHCP 설정 (24.04)

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: yes

적용 시 주의 (특히 원격 서버)

sudo netplan try

120초 후 자동 롤백
SSH 끊겨서 서버 날리는 사고 방지

4. NetworkManager 방식 (20.04 & 24.04 공통)

GUI 환경이나 노트북, 데스크탑에서는
여전히 NetworkManager + nmcli가 가장 편합니다.

고정 IP 설정

sudo nmcli con mod "Wired connection 1" \
  ipv4.addresses 192.168.1.100/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns "8.8.8.8,8.8.4.4" \
  ipv4.method manual

sudo nmcli con up "Wired connection 1"

DHCP 복구

sudo nmcli con mod "Wired connection 1" ipv4.method auto
sudo nmcli con up "Wired connection 1"

20.04와 24.04 사이에
nmcli 사용법 차이는 거의 없습니다.

5. 임시 설정 방식 (테스트 · 디버깅용)

⚠️ 재부팅 시 전부 사라집니다.

ip 유틸리티 (권장)

sudo ip addr add 192.168.1.100/24 dev enp0s3
sudo ip route add default via 192.168.1.1

ifconfig 차이

버전상태

20.04	기본 포함
24.04	기본 미포함

24.04에서 ifconfig 쓰려면:

sudo apt install net-tools

굳이 그럴 이유 없습니다.
이제는 ip 명령어가 정답입니다.

6. 방식 · 버전별 종합 비교

구분Ubuntu 20.04Ubuntu 24.04

Netplan 버전	0.x	1.0
gateway4	사용 가능	Deprecated
routes	선택	권장
nmcli	안정	안정
ifconfig	가능	비권장

7. 마지막 확인 단계 (필수)

설정 후에는 무조건 확인합니다.

IP 확인

ip addr

외부 통신 확인

ping -c 3 8.8.8.8

여기서 안 되면
설정은 끝난 게 아니라 시작도 안 한 겁니다.

마무리 정리

20.04 유지 보수
- 기존 gateway4 유지 가능
- 당장 바꿀 필요는 없음
24.04 신규 구축
- routes 문법 필수
- Netplan 1.0 기준으로 작성
앞으로를 생각한다면
- 20.04에서도 routes 문법으로 미리 정리하는 게 가장 깔끔

Ubuntu는 점점 불친절해지고 있습니다.
대신, 한 번 제대로 해두면 오래 갑니다.

이 글 하나로
20.04든 24.04든
네트워크 설정에서 길 잃을 일은 없을 겁니다.

Shell 문자열 처리: 특정 패턴 이전을 삭제하고 이후만 출력하는 7가지 실전 방법 정리

심량 — Tue, 2 Dec 2025 09:34:29 +0900

Shell에서 특정 패턴 이전 문자열을 삭제하고 이후 텍스트만 출력하는 방법을 정리했습니다.
sed, awk, perl, Bash 파라미터 확장 등 다양한 명령어를 사용해, 초보자도 그대로 복사해서 실행해 볼 수 있는 예제로 자세히 설명드립니다.

로그나 빌드 출력, 각종 스크립트 결과를 다루다 보면 다음과 같이 여러 내용 중에 특정 키워드(아래에서는 zzz.txt) 까지는 필요없고 그 이후 내용(아래에서는 변하는 내용)만 필요한 상황이 있습니다.

abc cde ka zzz.txt 변하는 내용

여기서 목표는 다음과 같습니다.

zzz.txt까지의 모든 내용을 삭제하고, 그 이후 문자열인 변하는 내용만 출력하기

이 글에서는 이 목표를 달성하기 위해 다음과 같은 7가지 전략을 정리합니다.

sed 문자열 제거
perl 정규식 변환
awk의 index + substr 사용
awk 상태 머신 방식
awk split 기반 분리
Bash 파라미터 확장
rev + sed + rev 트릭

모든 예제는 복붙 후 바로 실행 가능하도록 echo를 포함해 작성했습니다.

1️⃣ sed 문자열 제거 방법 (가장 기본적인 패턴)

sed는 Shell에서 텍스트를 변환할 때 가장 많이 사용하는 도구입니다.
정규식을 이용해 특정 패턴 이전을 통째로 지우는 방식으로 사용할 수 있습니다.

1-1. 기본 예제: zzz.txt까지 제거하고 이후만 출력

echo "abc cde ka zzz.txt 변하는 내용" \ | sed 's/.*zzz.txt //'

출력:

변하는 내용

설명:

.*zzz.txt 부분이 처음부터 zzz.txt + 뒤 공백까지를 의미합니다.
이 구간을 빈 문자열로 바꾸기 때문에, 결과적으로 변하는 내용만 남습니다.

1-2. 공백이 여러 개 섞여 있어도 처리 가능한 버전

echo "abc   cde    ka  zzz.txt        변하는   내용" | sed 's/.*zzz.txt *//'

여기서

*는 “공백이 0개 이상”을 의미합니다. 즉, 공백(' ')이 여러 개 있든지, 아예 없든지() 하는 것을 처리합니다.
zzz.txt 뒤에 공백이 몇 개가 붙어 있든 자연스럽게 제거됩니다.

2️⃣ perl 정규식 기반 제거 (복잡한 패턴에 강력)

perl은 정규식 기능이 매우 강력해서, 공백이 불규칙하거나 패턴이 복잡할 때 유리합니다.

2-1. zzz.txt까지 포함한 앞부분 제거

echo "abc cde ka zzz.txt 변하는 내용" | perl -pe 's/^.*?zzz\.txt\s*//'

출력:

변하는 내용

설명:

^.*?zzz\.txt
- 줄의 시작부터(^)
- 가장 앞에서부터(.*?)
- zzz.txt가 나오는 지점까지를 찾습니다.
\s*
- zzz.txt 뒤에 오는 공백(0개 이상)을 제거합니다.
결과적으로 zzz.txt까지의 모든 내용을 지워줍니다.

3️⃣ awk index + substr 기반 처리 (위치 기반 접근)

정규식보다 “문자열 내에서 패턴의 위치”를 계산하고 그 이후를 잘라내는 방식을 원하신다면 awk의 index와 substr 조합이 좋습니다.

3-1. index + substr로 zzz.txt 이후만 출력

echo "abc cde ka zzz.txt 변하는 내용" | awk '{
  p = index($0, "zzz.txt");
  if (p > 0) {
    print substr($0, p + length("zzz.txt ") );
  }
}'

한 줄 버전

echo "abc cde ka zzz.txt 변하는 내용" | awk '{ p = index($0, "zzz.txt") print substr($0, p + length("zzz.txt ")) }'

출력:

변하는 내용

설명:

index($0, "zzz.txt")
현재 줄($0)에서 "zzz.txt"가 시작되는 위치를 반환합니다.
substr($0, p + length("zzz.txt ") )
zzz.txt와 그 뒤 공백까지 길이를 더한 위치부터 끝까지 잘라냅니다.

4️⃣ awk 상태 머신 방식 (필드 단위로 처리하고 싶을 때)

공백 기준으로 나뉘어진 텍스트라면, awk의 상태 머신 방식이 이해하기 더 쉬울 수 있습니다.

4-1. zzz.txt 이후 단어만 모아서 출력

echo "abc cde ka zzz.txt 변하는 내용 입니다" | awk '{
  found = 0;
  out = "";
  for (i = 1; i <= NF; i++) {
    if (found) {
      out = out " " $i;
    }
    if ($i == "zzz.txt") {
      found = 1;
    }
  }
  # out은 앞에 공백이 하나 붙어 있으므로 substr로 잘라줍니다.
  print substr(out, 2);
}'

한 줄 버전

echo "abc cde ka zzz.txt 변하는 내용 입니다" | awk '{ found = 0 out = "" for (i=1;i<=NF;i++) { if (found) out = out " " $i if ($i=="zzz.txt") found=1 } print substr(out,2) }'

출력:

변하는 내용

설명:

NF는 현재 줄의 필드 개수입니다. (공백 기준)
zzz.txt를 만나기 전까지는 아무 것도 저장하지 않습니다.
zzz.txt를 만나면 found = 1로 바꾸고, 그 이후 단어들만 out에 쌓습니다.

5️⃣ awk split 기반 처리 (패턴 기준으로 문자열 분리)

문자열을 특정 패턴 기준으로 왼쪽/오른쪽으로 나누고, 오른쪽만 사용하는 방식입니다.

5-1. split으로 zzz.txt 이후 부분만 출력하기

echo "abc cde ka zzz.txt    변하는 내용" | awk '{
  n = split($0, arr, "zzz.txt");
  # arr[1] : zzz.txt 이전
  # arr[2] : zzz.txt 이후
  sub(/^ */, "", arr[2]);  # 앞에 불필요한 공백 제거
  print arr[2];
}'

한 줄 버전

echo "abc cde ka zzz.txt    변하는 내용" | awk '{ n = split($0, arr, "zzz.txt") sub(/^ */, "", arr[2]) print arr[2] }'

출력:

변하는 내용

설명:

split($0, arr, "zzz.txt")
전체 줄을 "zzz.txt"를 기준으로 나누어 arr[1], arr[2]에 저장합니다.
arr[2]가 "zzz.txt" 뒤쪽 문자열이므로, 앞 공백만 제거하고 출력합니다.

6️⃣ Bash 파라미터 확장 (외부 도구 없이 처리)

Bash 스크립트 내부에서 문자열을 다룰 때는 파라미터 확장을 사용하면 외부 도구 없이도 깔끔하게 처리할 수 있습니다.

6-1. 변수에서 zzz.txt까지 제거하고 이후만 출력

line="abc cde ka zzz.txt 변하는 내용"
echo "${line#*zzz.txt }"

한 줄 버전

line="abc cde ka zzz.txt 변하는 내용" echo "${line#*zzz.txt }"

출력:

변하는 내용

설명:

${line#*zzz.txt }
- #는 “앞에서부터 일치하는 가장 짧은 부분을 제거”하는 연산입니다.
- *zzz.txt 는 “아무 문자들 + zzz.txt + 공백”까지를 의미합니다.
- 그 부분을 잘라내고 나머지를 출력합니다.

7️⃣ rev + sed + rev 조합 (문자열 뒤집기 트릭)

문자열을 뒤집으면 복잡한 패턴이 단순해지는 경우가 있어, rev와 sed를 조합해 사용하는 방법도 있습니다.

7-1. 문자열을 뒤집어서 처리한 뒤 다시 되돌리기

echo "abc cde ka zzz.txt 변하는 내용" \
  | rev \
  | sed 's/.*txt.zzz //' \
  | rev

한 줄 버전

echo "abc cde ka zzz.txt 변하는 내용" | rev | sed 's/.*txt.zzz //' | rev

설명:

원래 문자열을 뒤집으면:
용내 는하변 txt.zzz ak edc cba
여기서 txt.zzz 기준으로 앞부분을 제거한 뒤
다시 rev로 되돌리면 원래 방향으로 정리된 문자열이 나옵니다.

실습 팁: 예제 따라 하실 때 이렇게 확인해 보세요

터미널을 여신 뒤, 각 코드 블록을 그대로 복사해서 붙여넣기만 하셔도 됩니다.
모든 예제는 echo "..."를 포함하고 있어서, 별도의 파일 없이도 바로 동작합니다.
마음에 드는 방식을 하나 고르셔서,
- 로그 파싱
- 빌드 출력 정리
- 스크립트 후처리
  등에 그대로 응용하실 수 있습니다.

어떤 방식을 언제 쓰면 좋을까요?

가장 간단한 경우
→ sed 's/.*zzz.txt //'
복잡한 패턴, 공백이 뒤죽박죽
→ perl -pe 's/^.*?zzz\.txt\s*//'
위치 기반으로 명확하게 처리하고 싶을 때
→ awk의 index + substr
공백 기준 필드 형태의 로그 처리
→ awk 상태 머신 / split 방식
스크립트 내부 변수만 처리
→ Bash 파라미터 확장 ${var#*pattern}
정규식이 너무 복잡해질 때 차라리 뒤집어서 처리
→ rev + sed + rev

마무리

이 글에서 소개해 드린 7가지 방법은 모두 **“특정 패턴까지 앞부분을 버리고, 이후만 출력한다”**는 공통된 목표를 가집니다.
도구와 표현법은 다르지만, 개념은 같습니다.

가장 중요한 것은 본인이 이해하기 편하고, 나중에 다시 봐도 읽기 쉬운 코드 스타일을 고르는 것입니다.
선호하는 방식을 하나 정해서 “내 Shell 문자열 처리 패턴”으로 만들어 두시면, 이후 로그 처리나 간단한 텍스트 전처리에 큰 도움이 되실 것입니다.

[펌] network stack diagram

심량 — Tue, 21 Oct 2025 18:27:15 +0900

Entire Linux Network stack diagram

Diagram of entire Linux Network Stack, including: Virtualization and Linux containers: Emulation and Paravirtualization. Network sockets. Network stack: Upper layer of Network stack (TCP, UDP). Low layer of Network stack with GRO, RPS, RFS and GSO. Network

zenodo.org

Linux Network Stack - EN.pdf

5.19MB

리눅스 서비스 포트 충돌 삽질기: net.ipv4.ip_local_reserved_ports 완벽 가이드 - Cannot assign requested address

심량 — Mon, 20 Oct 2025 16:15:25 +0900

안녕하세요! 개발을 하다 보면 정말 예상치 못한 곳에서 뒤통수를 맞는 경우가 종종 있습니다. 오늘은 리눅스 서버에서 발생하는 고질적인 포트 충돌 문제를 해결하려다 겪었던 생생한 삽질 경험과 그 과정에서 얻은 깨달음을 공유하고자 합니다.

문제의 시작: 유령처럼 나타나는 포트 충돌

저희가 운영하는 리눅스 장비에는 두 가지 중요한 서비스가 백그라운드에서 실행되고 있습니다.

고정 포트를 사용하는 핵심 애플리케이션 (my-app-service)

외부 서버와 연결을 유지하는 reverse-ssh-service

평소에는 잘 동작하다가, 시스템을 재부팅하거나 reverse-ssh-service가 재시작될 때 아주 가끔 my-app-service가 포트를 점유하지 못하고 실패하는 문제가 발생했습니다. 원인은 명확했습니다. reverse-ssh-service의 ssh 클라이언트가 외부 접속을 위해 OS로부터 할당받는 임시 포트(Ephemeral Port)가 운 나쁘게 my-app-service가 사용해야 할 고정 포트와 겹치는 것이죠.

첫 번째 가설: 특정 포트 범위를 예약하자!

이 문제를 해결하기 위해 리눅스 커널 파라미터 중 하나인 net.ipv4.ip_local_reserved_ports를 알게 되었습니다. 이 파라미터에 포트나 포트 범위를 지정해두면, OS가 임시 포트를 자동 할당할 때 해당 영역을 제외한다는 것이죠. "바로 이거다!" 싶었습니다.

이 설정은 /etc/sysctl.d/ 디렉터리에 .conf 파일을 만들어 관리할 수 있습니다.

sudo nano /etc/sysctl.d/99-port-reservation.conf

my-app-service가 사용할 포트가 51000번대라고 가정하고, 우선 다음과 같이 넉넉하게 10개 정도의 포트를 예약했습니다.

sudo vim /etc/sysctl.d/99-port-reservation.conf
net.ipv4.ip_local_reserved_ports = 51000-51010

설정을 적용하고 나니 한 가지 고민이 생겼습니다. "이게 정말 잘 적용된 건지 어떻게 확실하게 테스트하지?"

가설 검증을 위한 과감한 테스트와 예상치 못한 오류

"제대로 막히는지 확인하려면, 아예 쓸 수 있는 포트를 전부 막아버리자!"

저는 검증을 위해 아주 넓은 포트 대역을 예약 범위로 설정했습니다. 10000번부터 65535번까지 모두 막으면, ssh 클라이언트가 접속에 실패할 것이라고 예상했습니다. 1~9999번 포트는 여유가 있으니 시스템이 알아서 잘 사용하리라 믿었죠.

net.ipv4.ip_local_reserved_ports = 10000-65535

그리고 sysctl 명령어로 설정을 시스템에 즉시 반영했습니다.

sudo sysctl --system

이제 reverse-ssh-service를 재시작하자, 예상대로(?) 서비스가 실패했습니다. 직접 ssh 명령어를 실행해 보니 다음과 같은 오류 메시지가 나타났습니다.

$ /usr/bin/ssh -o ... remote-user@203.0.113.50
ssh: connect to host 203.0.113.50 port 22: Cannot assign requested address

"Cannot assign requested address" (요청한 주소를 할당할 수 없습니다.)

오류가 발생했으니 테스트는 성공... 인 줄 알았지만, 뭔가 찜찜했습니다. "왜 1~9999번 사이의 포트를 사용하지 못했을까?"

진짜 원인: 내가 알던 포트 범위와 커널의 생각이 달랐다

이 궁금증을 해결하기 위해 검색을 시작했고, 곧 리눅스 커널이 임시 포트로 사용하는 실제 범위가 따로 정해져 있다는 것을 알게 되었습니다.

sysctl 명령어로 직접 확인할 수 있었죠.

결과는 충격적이었습니다.

sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

제가 생각했던 것과 달리, 커널은 32768번부터 60999번 사이의 포트만을 임시 포트로 사용하고 있었습니다. 제가 테스트를 위해 막아버린 10000-65535 범위가 커널이 사용할 수 있는 모든 임시 포트 범위를 완벽하게 포함해버린 것입니다. ssh가 사용할 포트가 단 하나도 남아있지 않았던 거죠!

✅ 해결 및 최종 검증

이제 원리를 알았으니, 올바르게 설정을 수정할 수 있었습니다. 커널의 임시 포트 범위(32768~60999)를 참고하여 ssh가 낮은 번호대 포트를 사용하도록 유도하기 위해, 33000번 이상의 포트를 모두 예약해 보았습니다.

net.ipv4.ip_local_reserved_ports = 33000-65535

설정을 적용하고 reverse-ssh-service를 재시작한 뒤, ss 명령어로 현재 연결 상태를 확인했습니다.

ss -4a | grep "203.0.113.50"
ESTAB 0 0 192.168.1.10:32772 203.0.113.50:ssh

놀랍게도 ssh 클라이언트가 사용하는 로컬 포트가 32772번으로 잡혔습니다! 이전에는 주로 5xxxx번대 포트가 잡혔는데, 제가 33000번 이상을 막아버리니 커널이 사용 가능한 범위의 가장 낮은 번호대(32768번 근처)를 할당해 준 것입니다. 드디어 설정이 의도대로 동작함을 눈으로 확인했습니다.

최종 적용 및 마무리

이제 모든 원리를 파악했으니, 저희 서비스에 필요한 만큼의 포트만 안전하게 예약할 수 있게 되었습니다.

#/etc/sysctl.d/99-my-app-reserved-ports.conf (최종)
net.ipv4.ip_local_reserved_ports = 51000-52000

이번 경험을 통해 간단한 포트 충돌 문제 해결 과정에서 리눅스 커널의 동작 방식을 더 깊게 이해할 수 있었습니다. 혹시 저와 비슷한 문제를 겪고 계신 분이 있다면, 이 글이 삽질의 시간을 줄여주는 작은 도움이 되기를 바랍니다.

세 줄 요약:

net.ipv4.ip_local_reserved_ports를 사용하면 특정 포트를 OS의 자동 할당 대상에서 제외할 수 있다.
OS는 net.ipv4.ip_local_port_range에 정의된 범위 내에서만 임시 포트를 할당한다.
포트를 예약할 때는 이 범위를 고려해야 하며, ss 명령어로 실제 적용 결과를 꼭 확인하자!

[python3] 동기 코드에서 “비동기 작업자”를 별도 프로세스로 돌리기 — subprocess vs multiprocessing 선택 가이드

심량 — Thu, 16 Oct 2025 09:36:41 +0900

동기 방식 메인 코드에서 파일 업로드를 하는 비동기 모듈을 만들어서 쓰려고 할 때 고민한 내용을 정리한 글입니다.

의도(현 구현 방향)

목표: 동기 코드(메인 앱)에서 비동기 작업자(업로더 등)를 완전 별도 프로세스로 실행하고, 빠른 취소/종료, 환경변수 주입, 로그 분리, 장애 격리를 쉽게 달성한다.
우선순위: 운영 단순성(격리·배포·재시작) > 세밀한 IPC > 최적화 미세튜닝.
가정: 작업자는 자체 이벤트 루프/네트워크 스택을 갖고, 성공/실패를 자체적으로 처리/보고할 수 있다.

언제 subprocess가 맞는가?

다음 조건을 2개 이상 만족하면 **subprocess.Popen**이 보통 더 깔끔합니다.

작업자가 독립 실행 스크립트 형태다.
환경변수/CLI 인자만으로 설정 전달이 충분하다.
실패해도 부모 프로세스를 오염시키지 않고 재기동이 쉬워야 한다.
로그 파일로 표준 출력을 남기고 외부 툴(systemd/supervisor)로 관리하고 싶다.
신호(SIGTERM/SIGUSR1) 로 빠르게 취소·종료를 걸고 싶다.
나중에 배포/롤백/핫스왑을 단순하게 가져가고 싶다(venv/스크립트 교체만으로).

장점 요약

완전 격리(새 파이썬 인터프리터): 이벤트 루프/소켓/상태 충돌 리스크 낮음
운영 친화: env/cwd/stdout 한 줄로 설정, 프로세스 그룹 분리(start_new_session=True)
장애 격리/재시작 용이, systemd 연동 쉬움

단점 요약

파이썬 객체 단위의 풍부한 IPC가 번거롭다(주로 stdout/파일/소켓/REST로 해결)
프로세스 기동 오버헤드(보통 수백 ms)는 짧고 잦은 호출에선 느껴질 수 있음

언제 multiprocessing이 맞는가?

다음 조건을 2개 이상 만족하면 **multiprocessing.Process**가 더 자연스럽습니다.

파이썬 함수 자체를 병렬로 실행하고 싶다.
Queue/Pipe/Manager로 파이썬 객체를 풍부하게 주고받아야 한다.
워커를 오래 띄워두고 많은 소작업을 저지연으로 처리해야 한다(풀링).
이벤트·진행률·중간결과를 빈번하게 주고받아야 한다.

장점 요약

파이썬 객체 직렬화 기반의 쉽고 풍부한 IPC
동일 코드베이스 안에서 함수 단위 병렬화가 간편

단점 요약

시작 방식(fork/spawn)과 플랫폼 차이에 따른 초기화 규율 필요
(특히 spawn에서 if __name__ == "__main__": 가드, import 순서, 전역실행 주의)
fork 기반에선 부모의 핸들/루프 상태 상속으로 미묘한 버그 가능 → 보수적으로는 spawn 권장(오버헤드↑)
외부 서비스처럼 운영/감시/재시작하기엔 subprocess보다 절차가 복잡

결정 체크리스트

격리와 운영 단순성이 최우선 → subprocess ✅
실시간·빈번한 객체 교환이 핵심 → multiprocessing ✅
빠른 취소 반응성은 둘 다 가능(신호 or Event/Queue). 다만 안전한 정리까지 고려하면 subprocess가 더 단순.
로그/배포/롤백을 OS 수준에서 다루고 싶다 → subprocess ✅

실전 패턴 모음

1) subprocess 비블로킹 실행(환경변수·로그·신호)

import os, subprocess, signal
from pathlib import Path

APP_DIR = Path("/path/to/app")
PY      = "/path/to/venv/bin/python3"
SCRIPT  = str(APP_DIR / "worker.py")

env = os.environ.copy()
env["WORKER_PROGRESS"] = "1"
env["WORKER_INTERVAL"] = "0.5"

log = open(str(APP_DIR/"runlogs/worker.log"), "a+", buffering=1)
p = subprocess.Popen(
    [PY, SCRIPT, "--archive", "tar.gz"],
    cwd=str(APP_DIR), env=env,
    stdout=log, stderr=subprocess.STDOUT,
    start_new_session=True  # 프로세스 그룹 분리 → 신호 제어/정리 용이
)
# … 부모는 즉시 다음 일 수행
# os.kill(p.pid, signal.SIGUSR1)  # 취소(사용자)
# p.terminate(); p.wait(timeout=10)  # 그레이스풀 종료 → 필요시 SIGKILL

결과 전달:

간단: 종료코드(0/비0)
중간: stdout 한 줄 JSON / 지정된 파일에 결과 기록
고급: 작업자가 서버에 직접 보고(부모는 상태만 확인)

2) multiprocessing으로 파이썬 콜러블 병렬화

from multiprocessing import Process, Queue
import time

def worker(cfg, q: Queue):
    # … 작업 …
    q.put({"result": "ok", "took": 1.23})

q = Queue()
p = Process(target=worker, args=({"archive": "tar.gz"}, q))
p.start()            # 비블로킹
msg = q.get()        # 필요 시 결과 수신(블로킹/타임아웃 조절)
p.join()

팁: 네트워크/이벤트루프 초기화는 자식 프로세스 내부에서 새로 열기(특히 fork 환경 주의).

흔한 함정 & 예방책

데드락: 파이프(stdout=PIPE)를 열었다면 **communicate()**로 비우거나 파일로 리다이렉트.
신호 전파: 리눅스에선 start_new_session=True 또는 os.setsid()로 그룹 분리 후 원하는 신호만 명확히 전송.
spawn 규율(multiprocessing): 전역 실행 금지, __main__ 가드, import 순서, 전역 상태 초기화 유의.
깨끗한 종료: SIGTERM/취소 플래그를 받은 후 파일/소켓/세션을 확실히 정리(특히 비동기 루프).

최종 한 줄

독립 실행체(서비스처럼)로 돌리고, 운영·배포·격리를 단순화하려면 subprocess.
파이썬 객체를 촘촘히 교환하며 함수 단위 병렬화가 핵심이면 multiprocessing.

당장 깔끔하게 가려면 subprocess로 시작하고, 정말 밀도 높은 상호작용이 필요해지는 지점에서만 multiprocessing으로 전환을 검토하는 전략이 안전합니다.

scp 실행 시 setlocale: LC_ALL: cannot change locale (ko_KR.UTF-8) 경고 해결 가이드

심량 — Mon, 29 Sep 2025 11:24:10 +0900

본 경고는 서버에 ko_KR.UTF-8 로케일(locale)이 없는데 SSH가 클라이언트의 로케일 환경변수(LANG, LC_*)를 전달하여 발생합니다.
해결 방법은 ① 서버에 로케일을 생성(권장) ② 클라이언트에서 로케일 전달을 차단 ③ 서버에서 로케일 수락을 비활성화 중 하나를 선택하시면 충분합니다.

원인

SSH SendEnv/AcceptEnv로 클라이언트 로케일이 서버로 전달됩니다.
서버에 ko_KR.UTF-8이 없으면 setlocale()이 실패하여 경고가 출력됩니다.

해결 방법

1) 서버에 로케일 생성(권장)

Debian/Ubuntu

echo "ko_KR.UTF-8 UTF-8" | sudo tee -a /etc/locale.gen
sudo locale-gen
sudo update-locale LANG=ko_KR.UTF-8 LC_ALL=ko_KR.UTF-8

RHEL/CentOS/Alma/Rocky

sudo dnf install -y glibc-langpack-ko || sudo yum install -y glibc-langpack-ko
# 또는
sudo localedef -f UTF-8 -i ko_KR ko_KR.UTF-8

2) 클라이언트에서 로케일 전달 차단(일회성)

LC_ALL=C LANG=C \ 
scp -i /path/to/ssh_key.pem \ 
    /path/to/package.tar.xz \ 
    user@example.host:remote/target/dir/

# 또는, 해당 호출에서만 SendEnv 비활성 
scp -o SendEnv= \ 
    -i /path/to/ssh_key.pem \ 
    /path/to/package.tar.xz \ 
    user@example.host:remote/target/dir/

3) 서버에서 로케일 수락 비활성화(정책 선택)

# /etc/ssh/sshd_config
# AcceptEnv LANG LC_* # ← 주석 처리
sudo systemctl restart sshd

검증

저는 로케일 생성 만으로 문제를 해결했습니다.

# 서버에서 로케일 존재 확인
locale -a | grep ko_KR

# scp 재시도(경고 미발생 확인)
scp -i /path/to/ssh_key.pem /path/to/package.tar.xz user@example.host:remote/target/dir/

체크리스트

서버에 ko_KR.UTF-8 생성 또는 정책적으로 로케일 전달 비활성화
필요 시 update-locale로 기본값 고정
CI/일회성 전송은 LC_ALL=C LANG=C로 간단히 회피 가능

Loguru를 활용한 파이썬 로깅 시스템 정리: 중앙 설정 방식 연구

심량 — Tue, 16 Sep 2025 21:03:44 +0900

파이썬 프로젝트의 복잡한 로그 관리를 Loguru 중앙 설정 방식으로 해결하는 방법을 정리했습니다. 멀티프로세스 환경에서도 충돌 없는 안전한 로깅, 레벨별 파일 분리, JSON 출력까지, 실전 예제 코드도 함께 보세요.

파이썬 프로젝트를 진행하면서 print()를 사용한 디버깅에서 벗어나 체계적인 로그 관리의 필요성을 느끼게 되었습니다. 특히 여러 모듈과 프로세스에서 동시에 로그를 남길 때, 설정이 중복되거나 로그가 충돌하는 등의 문제점을 경험했습니다.

이러한 문제를 해결하기 위해 Loguru 라이브러리의 중앙 설정(log_config.py) 방식을 학습하고 그 내용을 정리해 보았습니다. 이 방식은 프로젝트 로깅 시스템의 구조를 개선하는 데 유용한 접근법이라고 생각합니다.

중앙 설정 파일 log_config.py 구성하기

먼저, 로깅 시스템의 핵심이 될 log_config.py 파일을 구성합니다. 이 파일에 모든 정책과 설정을 집중시켜 다른 모듈들이 참조하도록 합니다.

log_config.py

import os
import sys
from loguru import logger

# --------------------------------------------------------------------
#               # 프로젝트 로깅 설정 연구
# --------------------------------------------------------------------

# 1. 기본 핸들러 제거: 중복 로깅 방지를 위해 초기화
logger.remove()

# 2. 환경 변수를 이용한 로그 레벨 설정: 동적 레벨 제어를 위함
#    - 예: LOG_LEVEL=DEBUG python app_a.py
LOG_LEVEL = os.getenv("LOG_LEVEL", "INFO")

# 3. 로그 파일 저장 경로 설정
LOG_DIR = "logs"
os.makedirs(LOG_DIR, exist_ok=True)

# 4. 공통 포맷 정의: 로그의 일관성을 위함
COMMON_LOG_FORMAT = (
    "<green>{time:YYYY-MM-DD HH:mm:ss.SSS}</green> | "
    "<level>{level: <8}</level> | "
    "<cyan>{extra[app_name]: <10}</cyan> | "
    "<level>{message}</level>"
)

# ------------------- # 핸들러별 설정 -------------------

# 핸들러 1: 콘솔 출력용
# 실시간 확인을 위해 INFO 레벨 이상을 대상으로 함
logger.add(
    sys.stdout,
    level=LOG_LEVEL,
    format=COMMON_LOG_FORMAT,
    colorize=True
)

# 핸들러 2: 일반 파일 출력용
# 모든 상세 로그(DEBUG 이상)를 시간별 파일로 저장
logger.add(
    os.path.join(LOG_DIR, "{time:YYYY-MM-DD_HH}.log"),
    level="DEBUG",
    format="{time:YYYY-MM-DD HH:mm:ss.SSS} | {level: <8} | {extra[app_name]: <10} | {name}:{function}:{line} - {message}",
    rotation="1 hour",
    retention="3 days",
    compression="zip",
    enqueue=True,  # 프로세스/스레드 안전성 확보
    backtrace=True,
    diagnose=True
)

# 핸들러 3: 에러 파일 출력용
# ERROR 레벨 이상의 로그만 별도 파일로 분리하여 관리 효율 증대
logger.add(
    os.path.join(LOG_DIR, "error.log"),
    level="ERROR",
    format="{time:YYYY-MM-DD HH:mm:ss.SSS} | {level: <8} | {extra[app_name]: <10} | {name}:{function}:{line} - {message}",
    rotation="10 MB",
    retention="1 week",
    enqueue=True,
    backtrace=True,
    diagnose=True
)

# 핸들러 4: JSON 파일 출력용
# 기계 분석을 고려한 구조화된 로깅 방식
logger.add(
    os.path.join(LOG_DIR, "events.json"),
    level="INFO",
    format="{message}",
    serialize=True, # 로그를 JSON으로 직렬화
    enqueue=True,
    backtrace=True,
    diagnose=True
)

모듈별 적용 예시

앞서 구성한 log_config.py를 각기 다른 역할을 가진 세 개의 애플리케이션 모듈에서 어떻게 활용하는지 살펴봅니다.

프로젝트 구조

my_project/
├── logs/
├── log_config.py      # 중앙 로깅 설정
├── app_a.py           # 모듈 A (주기적 작업)
├── app_b.py           # 모듈 B (요청 처리)
└── app_c.py           # 모듈 C (예외 처리)

app_a.py - 백그라운드 스케줄러

Python

# app_a.py
import time
from log_config import logger

log = logger.bind(app_name="Scheduler")

def run_scheduler():
    log.info("스케줄러 시작.")
    for i in range(3):
        log.debug(f"작업 {i+1} 확인...")
        time.sleep(1)
        log.info(f"작업 {i+1} 완료.")
    log.success("모든 작업 완료.")

if __name__ == "__main__":
    run_scheduler()

app_b.py - API 서버 요청 처리

Python

# app_b.py
import time
import random
from log_config import logger

log = logger.bind(app_name="API-Server")

def handle_request(user_id: str):
    request_id = f"REQ-{random.randint(1000, 9999)}"
    context_log = log.patch(lambda record: record["extra"].update(request_id=request_id))

    context_log.info(f"'{user_id}' 요청 수신")
    time.sleep(0.5)
    if user_id == "guest":
        context_log.warning("제한된 권한으로 처리.")
    context_log.success("요청 처리 완료.")

if __name__ == "__main__":
    handle_request("admin")
    handle_request("guest")

app_c.py - 데이터 처리 및 예외 발생

Python

# app_c.py
import time
from log_config import logger

log = logger.bind(app_name="Data-Worker")

def process_data(data):
    try:
        log.info(f"데이터 처리 시작: {data}")
        result = data['value'] / data['divisor']
        log.success(f"처리 결과: {result}")
        return result
    except Exception as e:
        log.exception(f"처리 중 오류 발생: {e}")

if __name__ == "__main__":
    process_data({'value': 100, 'divisor': 5})
    process_data({'value': 100, 'divisor': 0}) # 오류 발생

3. 실행 및 결과 분석

세 개의 스크립트를 각각 다른 터미널에서 실행하면, logs 디렉터리에 로그 파일들이 생성됩니다. 각 파일의 내용을 통해 설정이 의도대로 동작했는지 분석할 수 있습니다.

YYYY-MM-DD_HH.log: 세 애플리케이션의 DEBUG 레벨 이상 로그가 시간 순서에 맞게, 충돌 없이 기록된 것을 확인할 수 있습니다.
error.log: app_c.py에서 발생한 ZeroDivisionError 관련 로그만 분리되어 저장되어 있어, 오류 추적이 용이합니다.
events.json: 로그가 JSON 형식으로 구조화되어 있어, 향후 자동화된 분석 시스템에 입력 데이터로 활용할 수 있음을 보여줍니다.

정리 및 고찰

Loguru를 활용한 중앙 로깅 설정 방식은 다음과 같은 장점이 있다고 판단됩니다.

유지보수성: 로깅 정책 변경 시 log_config.py만 수정하면 되므로 관리가 용이합니다.
안정성: enqueue=True 옵션을 통해 다중 프로세스 환경에서도 로그의 무결성을 보장할 수 있습니다.
가독성 및 관심사 분리: 애플리케이션 로직과 로깅 설정을 분리하여 코드의 가독성을 높이고, 개발자가 비즈니스 로직에 더 집중할 수 있도록 돕습니다.

다만, log_config.py가 다른 모듈을 참조할 때 발생할 수 있는 순환 참조 문제 등은 설계 시 주의가 필요해 보입니다.

결론적으로, 이 방식은 프로젝트의 규모가 커지더라도 일관되고 안정적인 로깅 시스템을 유지하는 데 효과적인 접근법으로 생각되어, 학습한 내용을 정리해 보았습니다.

네오스타일로5.0 neostylo5.0 갤럭시s25 ultra

심량 — Tue, 19 Aug 2025 23:24:19 +0900

neostylo5_android15_quick_signed.apk

1.88MB

자판 입력만 가능하고 상용구 같은 기능은 안됩니다
정확히는 상용구 수정한 내용 저장이 안됩니다. 그러니까 안되는거랑 같죠..
그 외에 안되는 기능들 많을 수 있습니다..
원본 소스가 없어서..
한계가 있네요

원래는 삼성 기본 자판과 드래그 입력에 적응해보려고 노력했는데..
화딱지 나는 드래그 입력 정확도에 ..
지맘대로 엉뚱하게 바꿔버리는 인공지능 땜에..
참다참다 화딱지 나서 스말리 만져보다가 일단 이 정도라도 공유해보자 하는 마음에 글 작성합니다.

저작권에 문제가 된다면 글 비공개처리 하겠습니다.

연락주세요

고굼마님께서 지적하신 내용을 반영한 버전을 일단 공개합니다.

다만, 자판 변경이 처음 한번만 제대로 되고 이후 제대로 안되는 증상이 있습니다.

기존의 상용구 수정한 내용 저장이 안되는 것과 동일한 문제인 것 같습니다.

neostylo5_android15_v13_signed.apk

1.88MB

상용구 저장 안되는 문제를 수정한 버전을 공개합니다.

neostylo5_android15_v16_signed.apk

1.88MB

Power on Reset(POR) 이 뭔가요?

심량 — Tue, 15 Jul 2025 09:32:22 +0900

Power On Reset(POR)이 잘 이해되지 않아, 기초부터 직접 찾아보고 정리한 글입니다.
함께 기본 개념을 하나씩 풀어봅시다.

1. Power on Reset(POR)이란?

**Power on Reset(POR)**는 전자기기(특히 IC, 마이크로컨트롤러 등)에 전원이 처음 들어올 때, 기기가 항상 똑같은(정상적인) 상태에서 시작하도록 만들어주는 회로 또는 기능입니다

.쉽게 말해, 전원이 켜질 때 내부 회로가 엉뚱한 동작을 하지 않게 “잠깐 멈춰!”라고 신호를 주는 역할입니다.

2. 왜 POR이 필요한가?

전원이 들어오면 바로 모든 부품이 안정적으로 동작하는 게 아니라, 잠깐 동안 전압이 불안정할 수 있습니다.
이때 바로 동작을 시작하면 내부 데이터가 꼬이거나, 오작동할 수 있습니다.
POR은 전압이 안정될 때까지 “리셋(Reset)” 상태를 유지하다가, 충분히 안정되면 정상 동작을 시작하게 해줍니다

3. POR 회로의 기본 원리

가장 간단한 POR 회로는 **저항(Resistor)과 커패시터(콘덴서, Capacitor)**를 조합해서 만듭니다.
전원이 켜지면, 커패시터가 천천히 충전되면서 회로에 “딜레이(지연)”를 줍니다.
이 딜레이 덕분에, 리셋 신호가 잠시 유지되고 전압이 안정된 후에야 정상 동작이 시작됩니다

커패시터의 용량(Capacity)과 저항값(Resistance)에 따라 이 딜레이 시간(리셋 유지 시간)이 결정됩니다.

4. 실제 동작 예시

전원이 켜짐 → 커패시터가 충전됨(전압이 천천히 올라감) → 이 동안 IC의 리셋 핀이 “Low(활성)” 상태로 유지됨 → 커패시터가 충분히 충전되면 리셋 신호가 해제됨 → IC가 정상적으로 동작 시작

만약 커패시터 없이 단순히 저항만 쓴다면, 리셋 신호가 너무 빨리 풀려서 제대로 초기화가 안 될 수 있습니다.

5. POR IC(전용 칩)

더 정밀하고 확실한 동작을 위해, “POR IC”라는 전용 칩을 쓰기도 합니다.
이 칩은 내부적으로 위와 같은 원리(전압 감시, 딜레이 등)를 더 정밀하게 구현해줍니다

한눈에 보는 요약

구분설명

POR 목적	전원이 켜질 때 기기가 항상 정상 상태로 시작하게 해줌
기본 원리	저항+커패시터로 딜레이를 만들어 리셋 신호를 일정 시간 유지
왜 필요한가?	전압이 안정되기 전에 오작동 방지, 데이터 꼬임 방지
응용	간단한 회로(저항+커패시터), 또는 전용 POR IC 사용

추가 설명(그래도 감이 안올 때!!)

POR은 “신호등”과 비슷합니다.
전원이 들어오자마자 바로 차가 달리면 사고가 날 수 있으니, 신호등이 잠깐 멈추게 했다가 파란불이 들어오면 출발하는 것과 같습니다.
커패시터는 “모래시계”
모래시계가 다 떨어질 때까지 기다렸다가, 다 떨어지면 출발하는 것과 비슷합니다.

참고자료

Wikipedia, “Power‑on reset” Wikipedia
Texas Instruments, Generate a Power‑On Reset Pulse (SCET013) Texas Instruments
Microchip Developer Help, “8‑bit PIC MCU Power‑on Reset” Developer Help
WIZnet, W5500 Datasheet – Reset Timing Section WIZnet Document System
CircuitFutura, “Power‑On Reset Circuit Diagram” Circuit Futura
HardwareBee, “Introduction to Power‑on‑Reset” HardwareBee

대용량 로그 파일, 줄 번호로 필요한 구간만 정확히 추출하는 방법

심량 — Wed, 9 Jul 2025 13:22:39 +0900

대용량 로그 파일을 열어야 하는 상황,
용량이 너무 커서 에디터가 멈추거나 터미널이 반응하지 않으면 당황스러울 수 있습니다.

이 글에서는 줄 번호를 이용해
원하는 구간만 정확하게 추출하는 방법을 정리합니다.

어느 날 로그 파일을 열어보려는데,
파일이 너무 커서 열리지 않았습니다.
크기를 보니 수 기가바이트에 달했습니다.

에디터는 멈췄고,
터미널에서도 파일을 열 수 없었습니다.

하지만 포기할 순 없었습니다.
그 안에는 반드시 확인해야 할 기록이 있었기 때문입니다.

필요한 건 전체가 아니라 '한 구간'입니다

대부분 로그 파일을 전부 살펴볼 필요는 없습니다.
특정 에러가 발생한 지점과 그 주변 몇 줄이면 충분한 경우가 많습니다.

핵심은 필요한 구간만 정확하게 꺼내오는 것입니다.

Step 1: 시작 줄 번호 찾기

우선, 찾고자 하는 내용을 포함한 줄 번호를 확인합니다.

grep 명령어 사용

grep -n "찾을 키워드" server.log

-n 옵션은 줄 번호를 함께 표시합니다.

예시

grep -n "ERROR" server.log

출력:

123456:ERROR Something went wrong

에러 메시지가 123456번째 줄에 있다는 뜻입니다.

첫 번째 항목만 찾고 싶다면

grep -n -m 1 "ERROR" your.log

-m 1 옵션으로 첫 번째 결과만 표시할 수 있습니다.

Step 2: 끝 줄 번호 찾기

시작 줄 번호만 알아서는 충분하지 않습니다.
끝 줄 번호도 정해야 범위를 정확하게 지정할 수 있습니다.

방법 1: 다음 에러 찾기

grep -n -m 2 "ERROR" your.log

출력 예시:

123456:ERROR Something went wrong  
130000:ERROR Another error occurred

여기서 끝 줄 번호는 두 번째 에러 줄 번호에서 1을 뺀 값입니다.
즉, 130000 - 1 = 129999.

방법 2: 앞뒤 여유 줄 수로 범위 설정

다음 에러가 너무 멀거나, 문맥 전체를 확인하고 싶다면
앞뒤로 일정한 줄 수를 추가하는 방법이 있습니다.

예시:

시작 줄: 123456 - 500 = 122956
끝 줄: 123456 + 500 = 123956

Step 3: 줄 번호 범위로 추출

범위를 정했다면, 이제 추출할 차례입니다.

sed 사용

sed -n '122956,123956p' your.log > extracted.log

awk 사용

awk 'NR>=122956 && NR<=123956' your.log > extracted.log

tail과 head 조합

tail -n +122956 your.log | head -n 1001 > extracted.log

1001은 줄 수 계산에 따라 나온 값입니다.
끝 줄 - 시작 줄 + 1 = 1001.

Step 4: 추출한 로그 확인

추출한 로그를 열어
찾던 내용과 주변 문맥이 잘 포함됐는지 확인합니다.

필요하다면 범위를 조정해 다시 추출하면 됩니다.

로그는 필요한 부분만 꺼내면 충분합니다

용량이 아무리 큰 로그라도
핵심 구간만 정확하게 추출하면 부담스럽지 않습니다.

줄 번호를 찾고, 범위를 정한 뒤,
필요한 구간만 깔끔하게 추출하면 됩니다.

이 과정을 알면
대용량 로그를 다루는 일도 어렵지 않습니다.

핵심 명령어 요약

# 시작 줄 번호 찾기
grep -n -m 1 "에러메시지" your.log

# 끝 줄 번호 찾기
grep -n -m 2 "에러메시지" your.log

# 또는 시작 줄 ± 여유 줄 수

# 로그 추출
sed -n '시작줄,끝줄p' your.log > extracted.log

awk 'NR>=시작줄 && NR<=끝줄' your.log > extracted.log

tail -n +시작줄 your.log | head -n (끝줄-시작줄+1) > extracted.log

PS. 연속된 에러 구간을 자동으로 추출하는 방법

에러가 연속으로 이어지는 구간에서,
에러가 아닌 로그가 처음 등장하는 줄까지 자동으로 추출하고 싶을 때가 있습니다.
아래 방법을 참고하면 이 과정을 자동화할 수 있습니다.

흐름

첫 에러 줄 번호 찾기
그 이후, 에러가 아닌 줄의 첫 등장 줄 번호 찾기
두 줄 사이 범위 추출

명령어 예시

start_line=$(grep -n -m 1 "ERROR" your.log | cut -d: -f1)

end_line=$(awk -v start="$start_line" 'NR >= start { if ($0 !~ /ERROR/) { print NR; exit } }' your.log)

sed -n "${start_line},${end_line}p" your.log > extracted.log

설명

첫 에러 줄부터 시작
에러가 아닌 줄이 처음 등장하는 위치까지 추출
에러가 몇 줄 반복되든 자동으로 범위를 잡습니다.

응용 가능성

에러 패턴만 바꾸면 다양한 상황에 활용할 수 있습니다.

마무리하며

이 방법을 사용하면,
로그를 일일이 읽지 않고도
연속된 에러 구간을 정확히 추출할 수 있습니다.
상황에 따라 필요한 방법을 선택해 활용하면 됩니다.

Git 브랜치 강제 이동과 이름 변경, 진짜 안전하게 하는 방법

심량 — Mon, 7 Jul 2025 10:42:21 +0900

Git 브랜치 관리 중엔 포인터 이동(브랜치 강제 이동)이나
브랜치 이름 변경이 필요한 순간이 꼭 찾아옵니다.

이번 글에서는 다음 두 가지 핵심 Git 작업을 실전 사례로 쉽게 정리합니다:

특정 커밋까지 브랜치 포인터 이동 (커밋 포함 효과, 커밋값 변경 없음)
브랜치 이름을 release/ 접두사로 변경하고, Remote까지 동기화

깜빡하고 포함 못한 커밋, 안전하게 브랜치에 포함시키는 법 (포인터 이동)

● 상황

브랜치에 커밋을 깜빡하고 포함하지 못한 경우
커밋 내용을 유지하면서 커밋값(SHA)은 절대 건드리고 싶지 않을 때

● 해결법 (핵심 명령어)

# 브랜치 백업 (무조건 추천)
git branch backup_br2 br2

# 브랜치 포인터를 원하는 커밋으로 이동
git checkout br2
git reset --hard <원하는 커밋 ID>

# Remote에도 반영할 경우 (주의: 강제 push)
git push origin br2 --force

● 왜 안전한가?

git branch backup_br2 br2 로 브랜치 백업 가능 → 되돌리기 100% 가능
reset은 포인터 이동이기 때문에 커밋 ID는 그대로 유지됨
잘못돼도 복구 쉬움:

git checkout br2
git reset --hard backup_br2

● 이런 경우에 유용!

브랜치 히스토리 깨끗하게 유지하고 싶을 때
커밋값 변경 절대 원하지 않을 때
브랜치를 특정 커밋으로 딱 고정하고 싶을 때

브랜치 이름 변경 + Remote 반영 (release/ 접두사 추가)

● 목표

브랜치 이름을 release/ 접두사 붙여서 바꾸기
Remote(원격 저장소)까지 동일하게 반영

● 해결법 (완벽 가이드)

# 로컬 브랜치 이름 변경
git branch -m br2 release/br2

# Remote에 새 브랜치 Push
git push origin release/br2

# 기존 Remote 브랜치 삭제
git push origin --delete br2

● 주의사항

브랜치 이름 변경은 협업 중이라면 반드시 공유 필요
Remote에서 정리된 브랜치를 보려면:
```
git fetch --prune
```

● 이름 변경 효과?

→ 로컬과 Remote 모두 release/br2 이름으로 깔끔하게 통일
→ 기존 br2 브랜치는 삭제되어 혼란 없음

마무리: Git 브랜치 관리, 이렇게 생각하세요!

Git 브랜치 = 단순한 포인터입니다.
브랜치 이름 변경, 커밋 포함(포인터 이동)은 정확히 원리만 알면 전혀 위험하지 않습니다.
항상 백업 브랜치 하나만 남겨두면 어떤 실수도 100% 복구 가능.

설치했고 PATH도 수정했는데... not found? 마지막 한 수는?

심량 — Tue, 24 Jun 2025 14:04:31 +0900

심볼릭 링크도, alias도, PATH도 뭔가 부족했던 당신께.
진짜 실행 흐름을 장악하는 방법이 여기 있습니다.

Node, Java, Vim, Python 버전이 어지럽게 얽힌 환경 속에서,

/usr/bin/xxx

가 어디를 가리키는지 명확히 다루실 수 있으신가요?
그렇다면, 과감히 뒤로가기를 누르셔도 됩니다!

그렇지 않고 의도된 실행 흐름 설계를 원하신다면
update-alternatives가 그 무기가 됩니다.

⚔️ 그래서 뭐가 좋은데? 삼대장 비교

방식	적용 범위	반영 시점	자동 전환	적합한 상황
alias	셸 세션/사용자 수준	로그인 후	❌ 없음	간단한 별칭, 임시 커맨드 변경
심볼릭 링크 수동 수정	시스템 전체	즉시 적용	❌ 없음	단발성 대체, 경로 override용
update-alternatives	시스템 전체 + 정책 기반	선택 후 적용	✅ 있음	다중 버전 관리에 최적

alias는 셸에 머무르고, symlink는 파일에 머무르며, alternatives는 시스템 실행 흐름을 다룹니다.

update-alternatives란?

Debian/Ubuntu 계열에 내장된 실행 경로 우선순위 관리 도구로:

/usr/bin/<이름> 같은 표준 경로에 어떤 바이너리를 연결할지 중앙 정책으로 결정합니다.
/etc/alternatives/를 경유하여 symlink를 정리하므로 관리가 체계적입니다.
자동 선택, 수동 고정, 완전 제거 및 복원까지 하나로 처리 가능합니다.
--slave 옵션으로 관련 커맨드들을 한 그룹으로 통합 관리할 수도 있습니다.

주요 명령 요약

sudo update-alternatives --install <공용링크> <이름> <실제경로> <우선순위>
sudo update-alternatives --config <이름>
sudo update-alternatives --set <이름> <경로>
sudo update-alternatives --auto <이름>
sudo update-alternatives --remove <이름> <경로>
sudo update-alternatives --display <이름>
sudo update-alternatives --get-selections
sudo update-alternatives --remove-all <이름>

⚙️ 우선순위와 모드 전환

️ 우선순위

--install 시 부여하는 숫자가 클수록 우선순위가 높습니다.
자동 모드(--auto)에서는 가장 우선순위가 높은 항목이 자동 선택됩니다.
수동 모드로 지정하면 우선순위와 관계없이 명시된 항목만 사용됩니다.

sudo update-alternatives --set node /usr/local/bin/node  # 수동 지정
sudo update-alternatives --auto node                     # 자동 복귀

수동 ↔ 자동 전환

수동 모드 지정: --set, 또는 --config에서 수동 선택
자동 복귀: --auto <이름>

sudo update-alternatives --auto vim

현재 상태 확인 및 제거

sudo update-alternatives --display java
sudo update-alternatives --get-selections
sudo update-alternatives --remove-all python

실전 예시: 바이너리 통합 관리

✍️ Vim을 Neovim으로 교체

sudo update-alternatives --install /usr/bin/vim vim /usr/local/bin/nvim 100
sudo update-alternatives --config vim

Python 버전 지정

sudo update-alternatives --install /usr/bin/python python /usr/bin/python2 20
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 40
sudo update-alternatives --config python

☕ Java 다중 버전 전환

sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-8-openjdk/bin/java 1081
sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-11-openjdk/bin/java 1111
sudo update-alternatives --config java

✨ 왜 alias보다 강력한가?

항목	alias	alternatives
셸 세션 한정	✅	❌
시스템 전체 반영	❌	✅
자동 우선순위 적용	❌	✅
대화형 CLI 설정	❌	✅
연관 커맨드 그룹 묶음 (--slave)	❌	✅
자동화/스크립트 환경 연동 용이		✅

alias는 마치 ‘서랍 속 메모’ 같고, alternatives는 ‘시스템의 기본 메뉴판’입니다.

마무리: 이젠 바이너리도 '정책'으로 다스리세요

CLI 커맨드가 어디를 가리키느냐에 따라, 시스템이 전혀 다르게 작동합니다.
PATH 순서만 바꾸는 수준에서 벗어나, 정책 기반 실행 통제를 경험해보세요.

/usr/bin/python → python2? python3?
/usr/bin/vim → vim.basic? nvim?

이제는 더 이상 우연이 아닌 당신의 의도가 결정하게 하십시오.

"alias는 즉흥입니다. update-alternatives는 설계입니다."

개발 환경 자동화부터 배포/이식/CI까지.
시스템의 주도권은 이제 당신의 손에 있습니다. ️

Node.js 설치했는데 node 명령어가 작동하지 않을 때 (bash: /usr/bin/node: No such file)

심량 — Mon, 23 Jun 2025 18:41:43 +0900

apt로 설치한 Node.js를 제거하고 스크립트로 재설치한 후 node 명령어가 작동하지 않는 문제. 리눅스 셸의 hash 캐시가 원인입니다. 해결법까지 완벽 정리.

Node.js 설치했는데 `node` 명령어가 작동하지 않을 때

— `bash: /usr/bin/node: No such file or directory` 문제 해결법

요약 (TL;DR)

Node.js를 apt로 설치했다가 제거하고,
스크립트 방식으로 다시 설치했더니
`node -v` 명령어가 작동하지 않는다?

bash: /usr/bin/node: No such file or directory

which node는 멀쩡히 /usr/local/bin/node로 나오는데?
그 원인은 리눅스 셸의 hash 캐시 때문이다.
아래 해결 방법을 따라가면 바로 해결된다.

문제 발생 흐름 (재현 가능 시나리오)

coc.nvim 등 Vim 플러그인을 설치하려고 했더니 Node.js v16 이상이 필요하다는 메시지를 봄
sudo apt install nodejs → 설치된 버전은 v10.x, 턱없이 낮음
sudo apt remove nodejs → 제거

공식 설치 스크립트 실행:

curl -sL https://install-node.vercel.app/lts | sudo bash

설치 후 which node 확인 → /usr/local/bin/node ✅

하지만 node -v 실행 시 오류:

bash: /usr/bin/node: No such file or directory

원인: bash의 해시 테이블 캐시

bash는 자주 사용하는 명령어의 경로를 hash 테이블에 캐시해두고,
다음 실행 때는 PATH를 다시 검색하지 않고 기억해둔 경로로 바로 실행한다.

과거에 /usr/bin/node를 실행한 적이 있다면,
설치가 바뀌어도 bash는 계속 그쪽을 찾는다.

✅ 해결 방법: hash 초기화

hash -d node

또는 전체 캐시를 비우려면:

hash -r

이제 다시 실행하면 된다:

node -v
# v18.x.x  ✅ 정상 출력

❗ 설치 스크립트가 왜 이걸 말해주지 않을까?

설치 스크립트는 **새로운 셸 프로세스(subshell)**에서 실행된다.
bash의 해시 테이블은 현재 사용자의 셸 세션 안에서만 유효하다.
따라서 설치 스크립트는 사용자 셸의 캐시에 접근할 수 없고,
hash -r을 실행해도 사용자 셸에는 아무런 영향이 없다.

그렇다고 안내도 없이 침묵하는 건 친절한 시스템이라 할 수 없다.

최소한 이렇게 안내했어야 했다

✅ Node.js 설치가 완료되었습니다.

⚠️ 이전 node 경로가 기억된 셸에서는 아래 명령어를 실행해 주세요:

    hash -d node    # 또는 hash -r

또는 터미널을 종료하고 다시 열어주세요.

추가 팁

.bashrc 또는 .zshrc에 export PATH를 넣는 것도 좋지만,
hash는 경로 문제가 아니라 캐시 문제이므로 별개다.
source ~/.bashrc로도 해결되지 않는 이유는,
hash 캐시가 여전히 /usr/bin/node를 가리키고 있기 때문.

마무리

이 문제는 단순한 설치 실패가 아니다.
리눅스 셸이 “한 번 기억한 경로를 바꾸지 않기 때문에 생기는 캐시 문제”다.

# apt 설치 → 버전 낮음 → 제거
# 스크립트 설치 → which node OK → 실행 오류 → hash 캐시 때문

기억하자

which node는 되는데,
node 명령은 안 된다면,
문제는 PATH가 아니라 hash다.

hash -d node

이 명령 하나면 해결된다.

Windows 11에서 Flutter 개발 환경 완벽 설정 가이드

심량 — Sun, 1 Jun 2025 20:50:44 +0900

Flutter를 Windows 11에서 처음 설정하는 분들을 위해 VS Code 설치부터 Android Studio, 에뮬레이터 실행까지 전 과정을 친절하게 설명합니다. 흔히 겪는 오류 해결법까지 포함한 실전형 가이드입니다.

VS Code + Android Studio + 에뮬레이터 + 오류 해결까지

Flutter는 단일 코드로 iOS와 Android 앱을 동시에 개발할 수 있는 Google의 강력한 UI 프레임워크입니다.
이 글에서는 Windows 11 환경에서 Flutter를 처음 설정하는 개발자나 입문자를 위해 VS Code, Flutter SDK, Android Studio, AVD 설정까지 한 번에 정리된 실전 가이드를 제공합니다.
추가로, 설정 중 흔히 마주치는 오류들과 그 해결법도 상세히 담았어요.

1. Visual Studio Code 설치

VS Code 공식 페이지에서 Windows용 설치 파일 다운로드
설치 파일 실행 → 일반 설치 방식대로 진행

2. Flutter SDK 설치 및 환경 변수 설정

Flutter 공식 가이드 (Windows)에서 최신 안정 버전 다운로드
압축 해제 위치는 C:\flutter 등 권한 문제 없는 경로로 설정
환경 변수 편집 → Path에 C:\flutter\bin 추가
명령어로 설치 확인:

flutter doctor

3. Android Studio 설치

Android Studio 공식 페이지에서 다운로드 후 설치
설치 중 Android Virtual Device 항목 포함되었는지 확인
Android SDK Manager에서 다음 구성요소 설치 확인:
- Android SDK Build-Tools
- Android SDK Command-line Tools
- Android Emulator
- Android SDK Platform-Tools

4. Android SDK 설정

Android Studio에서 SDK 위치 확인 (예: C:\Users\사용자명\AppData\Local\Android\Sdk)

Flutter에 SDK 경로 등록:

flutter config --android-sdk C:\Users\user\AppData\Local\Android\Sdk

라이선스 동의:
```
flutter doctor --android-licenses
```

5. Android 에뮬레이터 설정 (AVD Manager)

Android Studio → Tools > AVD Manager
새 가상 기기 생성 (Pixel 6 등 추천)
시스템 이미지: x86_64 아키텍처 기반 이미지 사용 권장
Graphics 옵션: Hardware - GLES 2.0 또는 Automatic 설정
에뮬레이터 실행 후 다음 명령으로 인식 확인:
```
flutter devices
```

6. Windows 개발자 모드 활성화

Flutter 플러그인이 symlink를 사용하므로 개발자 모드를 켜야 합니다.
Windows 설정 → 개발자용 → 개발자 모드 활성화

또는 Win + R 키를 눌러 실행 창을 실행 시키고, 열기 항목에 ms-settings:developers 를 붙여넣으면 바로 해당 설정으로 이동합니다.

✅ 마무리: flutter doctor로 최종 점검

마지막으로 다시 한 번 flutter doctor를 실행해 전체 설정 상태를 확인하세요.
모든 항목이 초록색 체크(✓)로 나올 때까지 하나씩 해결하면 됩니다.

흔한 오류 & 해결법 요약

오류 메시지해결 방법

X Android toolchain - Unable to locate Android SDK	flutter config --android-sdk로 경로 지정
Android license status unknown	flutter doctor --android-licenses 실행 후 y 입력
VS Code에서 디바이스 인식 안 됨	에뮬레이터 재실행, flutter devices 확인

결론

이제 Flutter 개발 환경 설정은 끝났습니다!
VS Code에서 새 Flutter 프로젝트를 시작하고, 방금 만든 에뮬레이터에서 실행해보세요.
Flutter는 처음만 조금 까다롭고, 이후엔 정말 빠르고 즐거운 개발 환경이 될 거예요.

Gemini 2.5 Pro vs GPT vs Claude — "나를 이해하는 AI"는 누구인가?

심량 — Thu, 15 May 2025 17:00:05 +0900

GPT, Claude, Gemini. 이름은 익숙하지만, 실제로 써보면 이해 방식도 반응 방식도 제각각입니다. 이 글은 세 모델이 사용자의 의도를 어떻게 파악하고, 어떤 식으로 반응·구현하는지를 실제 사용 경험을 바탕으로 비교한 기록입니다.

세간의 평가

아래는 실제 사용자들의 리뷰, 문서/미디어 입력 성능 테스트, 실사용 코드 흐름 등 다양한 평가 항목을 정리한 요약입니다. 단순 응답 품질을 넘어서 실행력과 맥락 대응, 자료 처리 성향까지 함께 포함합니다.

GPT: 전체 대화 흐름을 비교적 자연스럽게 유지하며, 설정한 문맥을 중심으로 정리하는 능력이 뛰어남. 문서 응답, PDF 처리 등에서 정보 밀도와 응답 흐름이 안정적이라는 평이 많음.
Claude: 실행 중심 대화에 강하며, 코드 응답에서 부가적 처리까지 챙겨주는 경우가 많음. 다만 텍스트 응답은 간결하고 중립적이라 감정 맥락 전달은 약하다는 의견이 있음.
Gemini: 요점 추출과 정리는 빠르지만, 이미지·PDF·표 등 미디어 입력에 대해 설명 중심으로 반응하며 흐름 재구성은 부족하다는 의견. 긴 문서 요약은 강하지만 대화 확장은 제한적이라는 평가.

AI의 이해력과 맥락 반응력

세 모델이 사용자의 말을 어떻게 해석하고 대화 흐름을 얼마나 자연스럽게 이어가는지에 대한 체감 비교입니다. 각 항목은 실제 사용자가 경험한 내용을 중심으로 정리했습니다.

GPT-4 (Plus)

사용자의 의도를 짚으려는 태도가 분명히 보입니다. 단순한 요청에도 '혹시 이런 걸 원한 건가요?' 같은 반응이 따라오기도 하죠.
하지만 그걸 넘어서 자발적으로 확장해주는 능력은 부족합니다. 기본 요청 범위에서 벗어나는 행동은 적습니다.
초기에 입력한 조건이나 예시 톤에 고착되는 경향도 강합니다.

Claude

Claude는 사용자의 의도를 충분히 반영해 구현하며, 필요한 주변 요소들도 알아서 챙겨주는 인상입니다.
코드 작업에서는 특히, 요청하지 않아도 예외 처리나 경로 검사 같은 부수 요소들을 포함해주는 경우가 많았습니다.
응답 텍스트는 건조한 편이지만, 코드에는 생각이 들어간 느낌이 있습니다.

Gemini 2.5 Pro

Gemini는 사용자의 말을 정리하고 요약하는 데는 정확했지만,
그 요약을 바탕으로 다시 흐름을 이어가거나, 의도를 깊이 파고들지는 않았습니다.
“핵심만 뽑아낸다”는 강점이 있지만, “맥락을 엮어낸다”는 쪽에서는 아쉬움이 있었습니다.
게다가 Pro 는 심층 연구(deep research) 기능을 사용하면 느으으립니다. 뭐 이건 gpt 도 마찬가지긴 합니다만..

코드 작성력 비교

코드를 단순히 만들어주는 수준을 넘어, 실제로 실행 가능한 흐름을 얼마나 충실하게 구성하는지 기준으로 비교합니다. 아래는 SWE-Bench 기준 정량 평가 결과와, 각 모델 사용 경험에 기반한 정성 평가입니다. Claude는 부가적인 처리까지 챙기는 경향이 있었고, GPT는 구성은 단정하지만 추가 요청 없이는 빠지는 요소가 많았고, Gemini는 설명 위주의 코드가 많아 실사용과의 간극이 느껴졌습니다.

SWE-Bench 기준 정확도

Claude 3 Opus (Anthropic 기준, 2024년 측정): 약 71%

GPT-4 (Original, 2023년 OpenAI 기준): 약 67%

Gemini 2.5 Pro (Google DeepMind, 2024년 공개 수치): 약 63.8% ※ 참고 수치이며 실제 체감과 다를 수 있음
※ 위 내용은 gpt 가 검색해서 찾은 내용이고 최근의 평가는 https://www.swebench.com/?utm_source=chatgpt.com 를 참고하시기 바랍니다.

GPT

깔끔한 코드 스타일이 장점입니다.
Claude가 토큰 제한으로 작업하다 이어서 작업을 GPT로 넘기는 경우가 많습니다. GPT는 긴 문맥을 안정적으로 이어받지만, 보조 함수나 예외 처리는 기본 구현에 포함되지 않는 경우가 많습니다.
excel 파일 작업 등을 진행할 때, 언급한 요청은 구현하지만 excel 파싱 코드가 빠진다던지, 헤더 파싱이 나사가 빠진 경우가 잦았습니다.
결론은... 초등학생에게 상세하게 방향을 지도해주듯이 보모 모드로 지시(프롬프트)를 자알 노오력해서 작성해야 좋은 결과를 스트레스 줄이고 얻습니다. 버벅일 때는 직접 수정하고 캔버스에 붙여넣어서 그걸 기준으로 작업하라고 지시하는게 효율적일 수도 있습니다.

Claude

완성도 높은 흐름을 먼저 짜주는 경향이 강합니다. 대략적인 기능 단위로 요청해도 전체 흐름을 먼저 설계해주는 편이며, 세부 분기나 예외 처리까지 포함된 경우도 많았습니다.
입력/출력 제한(클로드에서 토큰으로 인용됨)이 너무 짧습니다. 수정 요청 몇 번 하다 보면 사용량 제한 때문에 3시간 이상 기다려야 합니다. 성능은 만족스러운데 서비스가 짜다고 생각하시면 됩니다. 제일 비싼 버전은 안써봐서 모르겠지만, 가장 싼 유료 버전을 써도 별차이가 없었습니다.
쓰시다 보면 '계속' 이나 'continue' 연타를 누르고 있는 자신을 보게 될 수 있습니다. 너무 번거롭습니다. 그래서 한동안 열심히 쓰다가 지금은 구독을 취소한 상태입니다.

Gemini

코드는 아직 직접 사용해보지 못했지만, SWE-Bench 수치상으로는 준수하고, 설명 위주 출력 특성상 문서 구조화 요청에 적합해 보입니다. 벤치마크 상으로는 준수하나, 설명 중심 출력 경향상 실사용과 차이가 있을 가능성이 있습니다.

마무리하며

GPT를 비롯한 여러 AI를 만지작거리다 보니,
어느새 이런 얘기까지 꺼내게 됐네요.

누군가는 "오 이거 나도 느꼈는데" 할 수 있고,
누군가는 그냥 조용히 창을 닫았을지도 모르죠.

저는 이렇게 써봤습니다.
여러분은 어떻게 쓰시나요?

Linux 네트워크 패킷 관리의 핵심: sk_buff 구조체와 메모리 레이아웃

심량 — Thu, 17 Apr 2025 12:01:29 +0900

sk_buff는 Linux 커널에서 네트워크 패킷을 표현하는 핵심 데이터 구조로, netdev_alloc_skb, skb_reserve, skb_put 함수를 통해 메모리 레이아웃이 동적으로 관리됩니다. 이 글에서는 네트워크 드라이버 개발자에게 필수적인 sk_buff를 할당하는 3형제를 소개합니다.

1. sk_buff 의 세 가지 할당 단계

1) netdev_alloc_skb() 실행 후

head(0), data(0), tail(0), end(68) 포인터 초기화
68바이트 전체가 사용 가능한 빈 버퍼 생성

2) skb_reserve(2) 적용

데이터 시작 위치를 2바이트로 설정(data=2)
패킷 헤더 공간 확보를 위한 전형적인 작업

3) skb_put(64) 실행

64바이트 데이터 추가로 tail 포인터 66으로 이동
남은 2바이트(end=68)는 테일룸으로 활용

시각화 코드

import matplotlib.pyplot as plt
import matplotlib.patches as patches

def draw_skb_layout(stage, head_offset=0, data_offset=0, tail_offset=0, end_offset=68):
    fig, ax = plt.subplots(figsize=(10, 2))
    ax.set_xlim(0, 70)
    ax.set_ylim(0, 1)
    ax.axis('off')

    # Draw memory bar
    bar = patches.Rectangle((0, 0.4), end_offset, 0.2, linewidth=1, edgecolor='black', facecolor='lightgrey')
    ax.add_patch(bar)

    # Add arrows and labels with vertical separation to avoid overlaps
    def add_arrow_label(offset, label, level):
        y_base = 0.7 + level * 0.2
        ax.annotate('', xy=(offset, 0.6), xytext=(offset, y_base),
                    arrowprops=dict(facecolor='black', shrink=0.05, width=1, headwidth=5))
        ax.text(offset, y_base + 0.05, f"{label} ({offset})", ha='center', va='bottom', fontsize=9)

    add_arrow_label(head_offset, 'head', 0)
    add_arrow_label(data_offset, 'data', 1)
    add_arrow_label(tail_offset, 'tail', 2)
    add_arrow_label(end_offset, 'end', 3)

    ax.text(end_offset / 2, 0.1, stage, ha='center', va='center', fontsize=12, weight='bold')
    return fig

# Create figures for the three stages
fig1 = draw_skb_layout("1) After alloc_skb()", head_offset=0, data_offset=0, tail_offset=0, end_offset=68)
fig2 = draw_skb_layout("2) After skb_reserve(2)", head_offset=0, data_offset=2, tail_offset=2, end_offset=68)
fig3 = draw_skb_layout("3) After skb_put(64)", head_offset=0, data_offset=2, tail_offset=66, end_offset=68)

# Save to PNG
fig1.savefig("/mnt/data/skb_stage1_alloc.png", bbox_inches='tight')
fig2.savefig("/mnt/data/skb_stage2_reserve.png", bbox_inches='tight')
fig3.savefig("/mnt/data/skb_stage3_put.png", bbox_inches='tight')
plt.close('all')

2. 코드 실행 결과

SKB 할당 단계별 메모리 구조
세 단계를 거치며 head, data, tail 포인터의 위치 변화를 명확히 확인 가능

3. 결론

skb->head 는 skb 시작 주소,

skb->end 는 skb 끝 주소,

skb->data 는 페이로드 시작 주소, 기본값 0이고, skb_reserve(n) 으로 n 값만큼 변경됨(주소 정렬을 위해 사용)

skb->tail 은 페이로드 끝 주소, 기본값 0이고, skb_reserve(n) 으로 skb->data 와 동일 주소, skb_put(m) 으로 페이로드 길이(m)만큼 이동하여 페이로드 끝 주소 가리킴

참 쉽죠?

4. 참고

sk_buff 구조체는 Linux 커널 네트워킹 서브시스템의 핵심 데이터 구조로, 네트워크 패킷 메타데이터와 버퍼 관리 정보를 저장합니다. 다음은 공식 문서와 소스 코드를 기반으로 한 전체 정의와 상세 설명입니다.

전체 구조체 정의

struct sk_buff {
    union {
        struct {
            struct sk_buff *next;   // 다음 SKB 포인터
            struct sk_buff *prev;   // 이전 SKB 포인터
            union {
                struct net_device *dev;  // 연관된 네트워크 디바이스
                unsigned long dev_scratch;  // dev 대체용
            };
        };
        struct rb_node rbnode;      // Red-Black 트리 노드 (netem/defrag용)
        struct list_head list;      // 리스트 헤드
    };

    union {
        struct sock *sk;            // 소켓 소유자
        int ip_defrag_offset;       // IP 조각화 오프셋
    };

    union {
        ktime_t tstamp;             // 패킷 타임스탬프
        u64 skb_mstamp_ns;         // 최초 전송 시간 (나노초)
    };

    char cb[48] __aligned(8);      // 컨트롤 버퍼 (레이어별 전용)

    union {
        struct {
            unsigned long _skb_refdst;  // 참조 대상 주소
            void (*destructor)(struct sk_buff *skb);  // 소멸자 함수
        };
        struct list_head tcp_tsorted_anchor;  // TCP 정렬 앵커
    };

    unsigned int len;               // 전체 데이터 길이
    unsigned int data_len;          // 페이지 데이터 길이
    __u16 mac_len;                  // MAC 헤더 길이
    __u16 hdr_len;                  // 복제된 SKB의 헤더 길이
    __u32 csum;                     // 체크섬 값
    __u32 csum_start;               // 체크섬 시작 오프셋

    union {
        struct {
            __u8 local_df:1;        // 로컬 단편화 허용
            __u8 cloned:1;          // 복제된 SKB 여부
            __u8 ip_summed:2;       // IP 체크섬 상태
            __u8 nohdr:1;           // 헤더 공간 확보 여부
        };
        __u8 pkt_type;              // 패킷 유형 (PACKET_HOST 등)
    };
    __u32 priority;                 // QoS 우선순위
    __u16 protocol;                 // 프로토콜 타입 (ETH_P_IP 등)
    __u16 security;                 // 보안 레이블

    /* 네트워크 계층 헤더 포인터 */
    union {
        struct tcphdr *th;          // TCP 헤더
        struct udphdr *uh;          // UDP 헤더
        struct icmphdr *icmph;      // ICMP 헤더
        struct iphdr *iph;          // IPv4 헤더
        struct ipv6hdr *ipv6h;      // IPv6 헤더
        unsigned char *raw;
    } h;

    /* 트랜스포트 계층 헤더 포인터 */
    union {
        struct iphdr *iph;          // IPv4 헤더
        struct ipv6hdr *ipv6h;      // IPv6 헤더
        struct arphdr *arph;        // ARP 헤더
        unsigned char *raw;
    } nh;

    /* 링크 계층 헤더 포인터 */
    union {
        unsigned char *raw;
    } mac;

    struct dst_entry *dst;          // 라우팅 엔트리
    struct sec_path *sp;            // 보안 경로 (IPsec용)
    struct nf_conntrack *nfct;      // Netfilter 연결 추적
    unsigned int nfctinfo;          // 연결 상태
    struct sk_buff_head *list;      // 소속 리스트 헤드

    /* 추가 필드 */
    unsigned int truesize;          // 전체 버퍼 크기
    atomic_t users;                 // 참조 카운터
    unsigned int head;              // 헤드 버퍼 시작
    unsigned int data;              // 데이터 시작
    unsigned int tail;              // 데이터 끝
    unsigned int end;               // 버퍼 끝
};

전체 구조는 Linux 커널 버전에 따라 일부 차이가 있을 수 있음

영역별 상세 설명

1. 리스트 관리

next/prev: SKB를 리스트/큐에 연결할 때 사용 (예: 소켓 송수신 큐)

rbnode: 네트워크 에뮬레이션(netem)에서 Red-Black 트리 노드로 사용
list: SKB가 속한 리스트 헤드 포인터

2. 디바이스 관련

dev: 패킷이 처리되는 네트워크 인터페이스 (예: eth0)

input_dev: 실제 패킷을 수신한 물리 디바이스
real_dev: 가상 디바이스(bonding, VLAN)의 실제 디바이스

3. 프로토콜 헤더

h (L4): skb->h.th로 TCP 헤더 접근

nh (L3): skb->nh.iph로 IP 헤더 접근
mac (L2): skb->mac.raw로 이더넷 헤더 접근

4. 메모리 관리

head: 할당된 버퍼 시작 주소

data: 실제 데이터 시작 위치
tail: 현재 데이터 끝 위치
end: 버퍼의 물리적 끝 주소
truesize: 전체 버퍼 크기 (head + end)

5. 패킷 메타데이터

len: 유효 데이터 길이 (data_len + 헤더)

data_len: 페이지 기반 데이터 길이 (scatter/gather용)

csum: 체크섬 값 (하드웨어 오프로드 시 사용)

6. 소켓/보안

sk: 패킷을 소유한 소켓 객체

sp: IPsec 보안 경로 정보
nfct: Netfilter 연결 추적 정보

7. 시간 관리

tstamp: 패킷 도착/전송 시간 (패킷 스니퍼용)

skb_mstamp_ns: TCP 재전송 타이머 시작 시간

8. 참조 관리

users: 참조 카운터 (복제 시 증가)

destructor: SKB 해제 시 호출되는 함수

특수 멤버 심층 분석

cb 컨트롤 버퍼

char cb[48] __aligned(8); // 레이어별 전용 공간

TCP: struct tcp_skb_cb 저장
IP: fragmentation 정보 저장
48바이트 정렬 구조체 주입 가능

_skb_refdst 라우팅 캐시

unsigned long _skb_refdst; // dst_entry 참조 + 플래그 결합

하위 2비트: 참조 상태 플래그
상위 비트: struct dst_entry 주소

cloned 플래그

__u8 cloned:1; // 복제된 SKB 여부

skb_clone() 시 1로 설정
데이터 버퍼 공유 시 사용

이 설명은 Linux 커널 5.15 기준으로, 모든 필드를 누락 없이 기술했습니다. 실제 구현은 아키텍처와 커널 버전에 따라 다를 수 있음

ChatGPT에서 마크다운(markdown) 출력, 왜 파일로는 완전한데 대화 중에는 달라 보일까?

심량 — Mon, 31 Mar 2025 14:25:57 +0900

최근 ChatGPT를 사용하면서 마크다운 형식의 문서를 출력할 일이 많아졌습니다. 그런데 한 가지 이상한 점을 발견했죠. 대화 중에 보여주는 마크다운은 자꾸 흐름이 끊기거나 설명문으로 바뀌는데, 같은 내용을 파일로 다운로드하면 포맷이 완벽하게 유지됩니다. 왜 이런 차이가 생길까요?

문제 현상 요약

ChatGPT에게 마크다운 문서를 생성해달라고 하면, 처음에는 코드 블록(````markdown`)으로 잘 출력됩니다.
하지만 중간쯤 가면 설명체 문장이나 일반 텍스트로 바뀌는 경우가 많습니다.
반면, 같은 내용을 파일로 저장 요청하면 포맷이 정확히 보존됩니다.

예:

"README.md 내용을 작성해줘" → 대화창에서는 중간에 설명이 섞임 "파일로 만들어줘" → 다운로드 받은 .md 파일은 완벽함

이유는?

ChatGPT의 출력 방식 차이 때문입니다.

출력 경로 처리 방식 특징

대화창 (chat UI)	사용자 친화적 렌더링	자동 요약, 설명체 섞임, 긴 블록 생략 가능
파일 다운로드	순수 텍스트 저장	포맷 100% 보존, 자동 처리 없음

즉, ChatGPT는 대화 중 출력을 “보기 좋게 가공”하는 반면, 파일 출력은 있는 그대로 제공합니다.

사용자 입장에서 왜 불편한가?

솔직히 말씀드리면... 써보면 압니다. md 파일 포맷일때는 내용이 긁어지는데.. 이걸 gpt 가 자신이 대화하는 것처럼 해석해서 보여줘버리면 코드 블럭에 해당되는 위치에서 복사된 내용이 끊겨있게 됩니다.

그래서 일부 사용자들은 처음부터 아예 이렇게 요청합니다:

"마크다운 전체를 코드 블록으로 출력해줘. 설명 없이 복사하기 쉽게."

또는,

"파일로 저장해서 다운로드하게 해줘."

그럼 어떻게 대응해야 하나?

✔️ 방법 1: 처음부터 코드 블록 강조 요청

README 전체를 markdown 코드 블록으로만 출력해줘. 설명은 하지 마.

✔️ 방법 2: 파일 다운로드 요청

파일로 만들어서 다운로드할 수 있게 해줘.

✔️ 방법 3: 출력 오류 시 직접 요청

중간에 설명이 섞였는데, 마크다운 전체를 다시 순수 코드 블록으로만 보여줘.

정리

ChatGPT는 대화 경험을 더 좋게 만들기 위해 출력 내용을 가공하지만, 개발자나 문서 작성자 입장에서는 오히려 불편함을 줄 수 있습니다.

따라서 마크다운이나 코드 같은 정확한 포맷 유지가 중요한 작업은 파일로 받는 방식이 가장 안전합니다.

✅ 이 현상은 OpenAI 개발자들도 인지하고 있으며, 향후 개선 여지가 있습니다.

필요하다면 ChatGPT에 직접 피드백을 남기거나, 파일 기반 활용 방식을 익혀두는 것을 추천합니다.

2025년 산불 현황 지도 안내

심량 — Thu, 27 Mar 2025 17:32:12 +0900

2025년 들어 대한민국 전역에서 산불 발생이 잦아지고 있습니다. 특히 3월은 강풍과 건조한 날씨로 인해 산불 위험이 매우 높으며, 실제로 강원도와 경북 지역에서 대형 산불이 잇따라 발생하고 있습니다. 본 글에서는 실시간 산불 정보를 확인할 수 있는 지도를 소개하고자 합니다.

최근 5년간 대한민국에서는 연평균 수백 건의 산불이 발생하고 있으며, 기후 변화로 인해 발생 빈도와 피해 규모가 점점 커지고 있습니다. 주요 산불 발생 지역은 강원도, 경상북도, 충청북도 등이며, 봄철 강수량 부족과 이상 고온 현상이 주요 원인으로 지목되고 있습니다.

2025년 3월 기준, 전국적으로 20건 이상의 산불이 발생했으며 특히 양양군, 울진군 등에서 대규모 피해가 보고되었습니다. 수백 헥타르의 산림이 불에 탔고, 수천 명이 대피하는 등 인명 및 재산 피해가 이어지고 있습니다. 산림청은 진화율과 진행 상태를 실시간으로 공개하며 총력 대응 중입니다.

산림청이 운영하는 ‘실시간 산불정보 서비스’는 가장 신뢰할 수 있는 공식 정보 제공 사이트입니다. 해당 사이트는 모바일과 PC 모두에서 접근 가능하며, 산불 발생 위치, 시각, 진행 상태, 진화율 등을 확인할 수 있습니다.

실시간 산불정보 사이트 사용법

사이트 접속 후 ‘산불별 산불상황 세부정보’ 섹션을 확인
표 형식으로 지역, 발생 시각, 진화율, 상태 등이 표시됨
지도에는 다음과 같은 범례가 함께 제공됨:

범례 해설:

화선 (빨간 선): 현재 불길이 퍼지고 있는 구역
진화완료 (노란 선): 진화 작업이 끝난 지역
저지선 (갈색 점선): 화재 확산을 막기 위한 인위적 차단선
풍속항 (파란 선): 바람 방향 및 속도 표시

‘진행 중’은 아직 불이 번지고 있는 상태이며, ‘진화 완료’는 모든 불길이 제거된 상태를 뜻합니다. 진화율은 전체 화재 면적 대비 진압된 면적 비율(%)이며, 100%라도 일정 시간 동안 잔불 감시는 계속됩니다.

혹시나 산불 발생 시에는 즉시 119나 1688-3119(산림청)로 신고하고, 방송이나 재난문자를 통해 안내받은 안전지대로 대피해야 합니다.

산불은 매년 반복되는 재난이 아닌, 기후 변화와 연결된 복합적인 위기입니다. 조기 감지와 신속 대응은 물론, 시민의 참여와 경각심도 매우 중요합니다. 특히, 피해를 입은 이재민들이 조속히 일상으로 복귀할 수 있도록 주거, 생계, 정신건강 등 다방면의 지원 체계 강화와 함께 제도적 보완이 시급히 마련되어야 합니다.

제발 정치적 혼란이 하루 빨리 해결되어 급히 대책 마련과 구호가 원활하게 이뤄졌으면 좋겠습니다..

Valkey vs Redis: 2024 오픈소스 인메모리 DB 선택 가이드 및 기능 비교

심량 — Thu, 27 Mar 2025 16:56:44 +0900

Redis의 라이선스 변경 이후, 오픈소스 기반의 대안 DB를 찾는 움직임이 활발해졌고, 그 중심에 Valkey가 있습니다.
이 글에서는 Redis와 Valkey의 기능, 사용 환경, 클라우드 지원, AI 확장성, 라이선스 구조를 비교하고, 실제 사용 시 어떤 선택이 적합한지 안내합니다.

Redis의 라이선스 변화와 Valkey의 탄생 배경

Redis는 2023년부터 라이선스를 RSAL/BSL 형태로 변경하면서, SaaS 환경이나 클라우드 제품에서의 자유로운 사용에 제약이 생겼습니다.
이로 인해 기업과 커뮤니티에서는 기존과 동일한 API·구조를 유지하면서도 오픈소스 철학을 지키는 대안이 필요해졌고, 그 결과 Redis 7.2.4를 기반으로 한 Valkey가 Linux Foundation 주도로 등장했습니다.

Redis Inc.: 다양한 고급 기능을 제공하지만, 라이선스와 사용 제한에 유의해야 함
Valkey: BSD-3 기반의 완전한 오픈소스, 커뮤니티 중심 개발과 배포의 자유를 지향

기능 및 운영 환경 비교

항목	Redis 8.x	Valkey 8.x
라이선스	RSAL / BSL (상업적 사용 시 제한될 수 있음)	BSD-3-Clause (완전한 자유 보장)
모듈 (Stack 포함)	RedisStack (RediSearch, RedisAI, RedisJSON 등 포함)	Stack 모듈은 포함하지 않으며, 커뮤니티 제안 방식으로 기능 확장 논의 가능
AI/벡터/검색	RediSearch 및 RedisAI 모듈을 통해 공식 지원	공식 지원 없음. 일부 실험적 시도는 있지만 실무 적용에는 안정성 부족 GitHub Discussions
멀티스레드 I/O	읽기/쓰기 모두 멀티스레드 지원	복수 쓰레드 처리와 비동기 복제 최적화로 경량 환경에 유리
보안/TLS 지원	기본 내장	빌드 시 옵션 또는 동적 모듈로 적용 가능
클러스터 및 Sentinel	Enterprise 구성 시 자동화된 설정 사용 (자유도 제한 가능)	모든 구성을 사용자가 직접 제어 가능. systemd 연동도 간단
운영 배포 도구	Helm Chart, 공식 Docker 이미지 제공	Docker 이미지 및 Helm Chart는 준비 중. 현재는 소스 설치 기반
클라우드 공식 지원	AWS ElastiCache (Redis) Google Cloud Memorystore (Redis) Microsoft Azure Cache for Redis	AWS ElastiCache – 공식 기여자 참여 AWS 발표 GCP Memorystore for Valkey – 7.2 / 8.0 지원 공식 문서 Azure AKS – Helm Chart 기반 배포 가능 Azure 문서

한눈에 요약:
Valkey는 자유로운 배포, 커뮤니티 중심 거버넌스, 경량 구조에서 유리하며,
Redis는 AI/벡터 검색, 모듈 생태계, 클라우드 제품 연계에 강점을 갖습니다.

어떤 상황에서 Redis 또는 Valkey를 선택해야 할까?

상황	추천	Redis를 선택하는 이유	Valkey를 선택하는 이유
상업용 SaaS 또는 배포 가능한 제품에 Redis를 통합할 때	Valkey	Redis는 해당 경우 라이선스 검토가 필수	BSD-3로 자유로운 SaaS, 배포, 수정 허용
AI, 벡터 검색, JSON 처리 등 고급 기능이 필요한 경우	Redis	Redis Stack에서 해당 기능 모듈 제공	현재 공식 지원 없음, 일부 실험 사례 존재
빠른 CI/CD 연동 및 DevOps 통합이 필요한 경우	Redis	Docker, Helm Chart 등 공식 제공	준비 중이거나 커뮤니티 기반으로 제공됨
클러스터 구성을 세밀하게 제어해야 할 경우	Valkey	Redis Enterprise에서는 설정 유연성 제한 가능	구성 파일, 시스템 설정까지 운영자 자유 설정
거버넌스, 커뮤니티 참여, 지속 가능성을 중시할 때	Valkey	Redis는 기업 중심 개발 구조로 주요 의사결정이 비공개로 이뤄짐	Linux Foundation 기반으로 기능 제안, 개선 참여 모두 공개

Redis에서 Valkey로 마이그레이션

Redis 7.2.4 기반과 동일한 구조로 운영 가능
AOF / RDB 포맷 호환, Replica 구성 유지
클러스터 구조, Sentinel 설정도 유사하게 전환 가능
Valkey Migration Guide
Percona 전환 가이드

참고 자료

[git] gitlab 접속시 pageant 로 ssh 키 사용하는 가이드

심량 — Wed, 19 Feb 2025 13:53:11 +0900

GitLab 접속 시 Pageant를 활용해 SSH 키를 안전하고 간편하게 관리하는 방법을 단계별로 안내합니다.

GitLab 이용에 필요한 SSH 접속 설정 과정을 쉽고 빠르게 따라할 수 있도록 설명합니다.

GitLab SSH 키 등록하기

GitLab 로그인 및 SSH Keys 접근

GitLab 홈페이지(gitlab.com)에 로그인 후, 상단 메뉴에서 SSH Keys 항목을 찾습니다.

등록된 프로젝트가 없으면 작업 대시보드에 기본 예시 이미지가 표시될 수 있습니다.

SSH 키 등록

Add new key 버튼을 클릭합니다.

생성한 공개키 내용을 복사하여 입력한 후 저장합니다.

GitLab 대시보드 및 사용자 설정 확인

대시보드 구성

왼쪽 최상단의 여우 아이콘은 홈페이지 링크입니다.

gitlab 대시보드

그 오른쪽에 사각형 아이콘, + 아이콘, 사용자 프로필 아이콘이 순서대로 위치해 있습니다.

gitlab 사용자 프로필

사용자 설정 변경

Preferences 링크를 클릭하면 메뉴 그룹이 Your work에서 User Settings로 변경됩니다.

여기서 SSH Keys 메뉴를 확인할 수 있습니다.

gitlab 사용자 설정

gitlab SSH Keys

gitlab SSH Keys 추가

Pageant를 통한 SSH 키 관리

Pageant 실행 및 키 추가

Pageant를 실행한 후, 생성한 SSH 키를 Add Key 버튼을 통해 추가합니다.

pageant 실행 화면

참고: PuTTY 용 키인 .ppk 파일로 변환된 키만 사용할 수 있습니다.

Git 접속 도구 선택

윈도우용 Git은 기본적으로 ssh.exe를 사용하지만, 이는 Pageant와 연동되지 않습니다.

해결방법: PuTTY가 제공하는 plink.exe를 사용하면 Pageant와 연동하여 SSH 키로 접속할 수 있습니다.

GIT_SSH 환경 변수 설정

시스템 환경 변수에 등록

제어판 > 시스템 및 보안 > 시스템 > 고급 시스템 설정 > 고급 탭의 환경 변수 항목에서 GIT_SSH 값을 추가합니다.

값으로는 C:\Program Files\PuTTY\plink.EXE와 같이 plink.exe의 경로를 지정합니다.

일회성 설정

만약 cmd.exe에서 한 번만 사용하려면 아래 명령어를 입력합니다.

set GIT_SSH=C:\Program Files\PuTTY\plink.EXE

SSH 접속 테스트

cmd.exe를 열고 아래 명령어를 실행해 SSH 접속을 확인합니다.

%GIT_SSH% git@gitlab.com

처음 접속 시, 서버의 호스트 키가 캐시에 없다는 경고 메시지가 표시됩니다.

서버의 SSH 키 지문이 출력되면 신뢰할 경우 y를 입력해 캐시에 추가합니다.

이후 "Using username 'git'"과 함께 접속이 진행되며, GitLab 환영 메시지가 출력됩니다.

예시 출력:

D:\doc\vcs\project1> %GIT_SSH% git@gitlab.com
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's ssh-ed12345 key fingerprint is:
ssh-ed12345 255 1a:2b:3c:4d:5e:6f:70:81:92:a3:b4:c5:d6:e7:f8:09
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) y
Using username "git".
Access granted. Press Return to begin session.
Server refused to allocate pty
Welcome to GitLab, @your_gitlab_id

Git 명령어를 통한 원격 저장소 테스트

원격 저장소 설정 변경

테스트를 위해 빈 저장소를 생성한 후, 기존 원격 저장소 이름을 변경하고 새로 추가합니다.

git remote rename origin old-origin
git remote add origin git@gitlab.com:your_gitlab_id/project1.git

전체 브랜치 Push

git push -u origin --all

성공 시, 아래와 유사한 메시지가 출력됩니다.

Counting objects: 6573, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3093/3093), done.
Writing objects: 100% (6573/6573), 405.16 MiB | 5.60 MiB/s, done.
Total 6573 (delta 3873), reused 6041 (delta 3431)
remote: Resolving deltas: 100% (3873/3873), done.
To gitlab.com:your_gitlab_id/project1.git
 * [new branch]      master -> master
 * [new branch]      debugging -> debugging
Branch 'master' set up to track remote branch 'master' from 'origin'.
Branch 'debugging' set up to track remote branch 'debugging' from 'origin'.

참고: PuTTY 공식 문서: https://www.chiark.greenend.org.uk/~sgtatham/putty/docs.html

[Windows11] Dropbox 에서 USB 넣을 때마다 뜨는 카메라 업로드 끄기!!

심량 — Thu, 9 Jan 2025 11:44:49 +0900

드랍박스를 쓰다보면 귀찮은 점이 있습니다. USB 메모리를 연결할 때마다 카메라 업로드 하라고 뜨는 것이 많이 짜증납니다.

이를 해지하고자 드랍박스 설정을 뒤져봐도 공식 홈에서 옛날 방식에 대한 설명만 있지 실질적으로 도움이 되질 않았습니다.

삽질 끝에 발견한 내용 정리합니다.

Windows + I 키를 누르거나 시작 메뉴에서 설정을 선택합니다.
자동 실행 을 검색해서 선택합니다. (Bluetooth 및 장치 > 자동 실행 메뉴를 선택해도 됩니다)
자동 실행 기본값 선택에 그 못된 녀석들이 있습니다. 원하는 걸로 얼른 바꿔줍니다.
- 잘 모르시겠으면 아무것도 안함 선택하시면 됩니다.
- 저는 폴더를 열어 파일 보기(파일 탐색기)를 선택해서 장치 연결할 때마다 탐색기가 실행하도록 바꿨습니다.

어디서 설정해야 하는지를 몰라서 헤맸지 알고나니 허무할 정도로 간단하네요.

이제 쓸모없는 드랍박스 알림에서 해방되세요!!

[Raspberry Pi 5] 터미널에서 한글 폰트 보기

심량 — Mon, 23 Dec 2024 18:28:20 +0900

기록용으로 남깁니다.

라즈비안을 설치하고 한글로 된 메시지(서버 접속 메시지든 파일명이든) 환경에 노출되면 한글이 깨져보입니다.

해결책은 간단합니다. 한글 폰트를 설치하고 해당 터미널을 다시 열면 됩니다.

sudo apt install -y fonts-한글폰트패키지명

그럼 현재 배포판 버전(bookworm, debian 12)에서 어떤 한글 폰트가 제공되는지 남깁니다.

패키지	글꼴명	설명	최소크기
fonts-alee	alee 무료 글꼴 모음	반달, 방울, 은진, 은진낙서, 구슬 https://ftp.debian.org/debian/pool/main/f/fonts-alee/fonts-alee_13.3.tar.xz
fonts-baekmuk	백묵 무료 글꼴 모음	백묵바탕, 백묵돋음, 백묵굴림 https://ftp.debian.org/debian/pool/main/f/fonts-baekmuk/fonts-baekmuk_2.2.orig.tar.gz
fonts-lexi-gulim	렉시굴림	렉시굴림 https://ftp.debian.org/debian/pool/main/f/fonts-lexi-gulim/fonts-lexi-gulim_20090423.orig.tar.xz
fonts-lexi-saebom	렉시새봄	렉시새봄 https://ftp.debian.org/debian/pool/main/f/fonts-lexi-saebom/fonts-lexi-saebom_20100129.orig.tar.gz
fonts-nanum	나눔 글꼴 모음	나눔바른고딕, 나눔바른펜, 나눔고딕, 나눔명조, 나눔펜, 나눔스퀘어, https://ftp.debian.org/debian/pool/main/f/fonts-nanum/fonts-nanum_20200506.orig.tar.xz
fonts-nanum-coding	나눔코딩	나눔고딕코딩 https://ftp.debian.org/debian/pool/main/f/fonts-nanum-coding/fonts-nanum-coding_2.5.orig.tar.gz
fonts-naver-d2coding	d2coding	d2coding https://ftp.debian.org/debian/pool/main/f/fonts-naver-d2coding/fonts-naver-d2coding_1.3.2.orig.tar.gz
fonts-noto-cjk	Noto Sans CJK KR Noto Serif CJK KR	Google 에서 만든 공개 폰트 no tofu 두부 안되! 다국에 폰트 없으면 빈사각형으로 표시되는 것을 두부라고 함 참고로 폰트 크기가 240MB.. https://ftp.debian.org/debian/pool/main/f/fonts-noto-cjk/fonts-noto-cjk_20240730+repack1.orig.tar.gz	일반: 14px 이상 중간: 16px 이상 강조: 20px 이상
fonts-unfonts-core	은 무료 글꼴 모음	은바탕, 은디나루, 은돋움, 은그래픽, 은궁서, 은필기 https://ftp.debian.org/debian/pool/main/f/fonts-unfonts-core/fonts-unfonts-core_1.0.2-080608.orig.tar.xz
fonts-woowa-bm	배달의민족 무료 글꼴 모음	배민 도현, 배민 을지로, 배민 한나, 배민 주아, 배민 기랑해랑, 배민 꾸불림, 배민 연성 https://ftp.debian.org/debian/pool/main/f/fonts-woowa-bm/fonts-woowa-bm_20241002.orig.tar.gz 모양 확인: 우아한형제들

[python3][one-liner] 섹션 헤더 없는 설정 파일 값 바꾸기

심량 — Thu, 19 Dec 2024 18:31:09 +0900

기록용으로 남깁니다.

A=B 형태의 설정파일이고, REMOTE_ADDR 이란 변수가 있으며, 섹션 헤더는 없는 경우에 한줄로 원하는 값으로 바꾸는 명령을 소개합니다.

참고로 ssh_config 파일 내용은 다음과 같습니다.
REMOTE_ADDR=1.2.3.4

바꾸고 싶은 값은 val='1' 에서 수정하고 파일명은 f='ssh_config' 에서 수정하도록 합니다.

결과물!!

python3 -c "val='1';from configparser import ConfigParser;f='ssh_config';c=ConfigParser();c.optionxform=str;c.read_string('[sec]\n'+open(f,'r').read());c['sec']['REMOTE_ADDR']=val;open(f,'w').write('\n'.join([k+'='+c['sec'][k] for k in c['sec']]))"

[W55RP20] mqtt 구현 및 테스트 기

심량 — Mon, 16 Dec 2024 10:12:53 +0900

Wiznet 사의 W55RP20 제품에 mqtt 를 C 기반으로 사용할 수 있는 예제에 대한 안내가 이미 존재합니다.

MQTT_Publish_Subscribe_EXAMPLE_AN_V100.pdf

저는 python 을 메인으로 사용하고 있어서 micropython 기반 하의 mqtt 사용 예제를 만들어 보려고 합니다.

위 문서에 따르면 윈도우에다 mosquitto 서버를 설치해서 쉽게! 테스트할 수 있다고 하는데 내부 망에서는 동작을 확인했는데 외부 망에서는 동작을 안하는 문제가 있어서...

고민을 하다가 외부 리눅스 pc에 mosquitto 서버를 설치하고 micropython 기반 mqtt 예제를 작성 및 테스트하였습니다.

우분투 계열 리눅스 pc에서는 다음 명령으로 mosquitto 서버를 설치합니다.

sudo apt install -y mosquitto

설정 파일은 /etc/mosquitto/conf.d/ 에 a.conf 형태로 .conf 확장자를 주어 작성하면 서버 시작시 자동으로 로드합니다.

sudo vim /etc/mosquitto/conf.d/test.conf

저는 설정 파일에 다음 내용을 추가했습니다.

listener 1883 0.0.0.0

allow anonymous true

참고로 윈도우 11에서는 동일한 설정으로 방화벽에서 mosquitto 앱 허용까지 걸었음에도 밖에서 접속이 되질 않았습니다.. 공유기에는 이미 포트포워딩이 지정되어 있었구요. 리눅스는 한방에 되네요. 리눅스 만세!!

서비스 형태로 실행하려면 restart 명령을 주면 설정이 반영됩니다.

sudo systemctl restart mosquitto.service

로그를 직접 보고 싶으면 서비스를 중지시키고 mosquitto 를 실행합니다.

sudo systemctl stop mosquitto.service

mosquitto -c /etc/mosquitto/conf.d/test.conf -v

아주 잘 동작합니다.

완료 소스 설명: WIZnet-ioNIC/WIZnet-ioNIC-micropython-examples: Examples for micropython with W55RP20

[뿌요뿌요퀘스트] 스킬 레벨업 방법

심량 — Thu, 12 Dec 2024 11:24:09 +0900

기술 수준을 높이는 방법

같은 캐릭터를 합성합니다.

같은 캐릭터와 파워업을 조합하면 스킬과 전투 스킬에 대한 경험치를 얻을 수 있습니다.

습득한 기술 및 경험

재료 카드 희귀도습득한 기술 및 경험

☆1	5
☆2	10
☆3 개	50
☆4 개	100
☆5	200
☆6	400
☆7	800

위의 표에서 볼 수 있듯이 낮은 희귀도는 기술 경험치를 거의 제공하지 않습니다. ☆ 2와 ☆ 3은 5 배의 차이가 있기 때문에 재료로 사용할 때는 적어도 ☆ 3으로 한 후에 사용하십시오.

레벨 업에 필요한 기술과 경험

기술 수준다음 단계로 나아가십시오누적 경험 필요

레벨 0	50	-
레벨 1	100	50
레벨 2	250	150
레벨 3	400	400
레벨 4	700	800
Lv.5(최대)	-	1500

위의 표에서 1500의 스킬 레벨 5(MAX)에 도달하기 위해 스킬 경험치가 필요하다는 것을 알 수 있습니다. 즉, ☆ 6의 같은 이름 (같은 처리)의 카드가 4 장 이상 필요합니다. 5성은 8장, 4성은 15장 필요합니다.

재료 카드가 보유한 스킬 경험치는 기본 카드로 이월됩니다. 따라서 코인을 낮은 레벨의 카드로 그룹화하고 최종적으로 키우는 메인 카드와 결합하여 코인 소비를 줄일 수 있습니다.

파워업을 합성할 때 매우 성공적이더라도 스킬 경험치에 대한 보너스는 없습니다. 또, 헨신 합성을 해도 이미 얻은 스킬 레벨이나 스킬 경험치는 그대로 계승됩니다.

보라색 비밀의 책 합성하기

다른 비밀서와 달리 보라색 비밀서는 스킬 경험치를 증가시키는 재료입니다.

습득한 기술 및 경험

진귀경험치 획득

☆3 개	50
☆4 개	100
☆5	200

보라색 비밀의 책을 재료 카드로 사용하면 같은 카드와 같은 희귀도에 해당하는 스킬 경험치를 얻을 수 있습니다.

참고: 【ぷよクエ】スキルレベルの上げ方とスキル上げをするメリット｜ゲームエイト

buster(debian 10) 에 docker 설치하기

심량 — Mon, 2 Dec 2024 13:44:50 +0900

기록용으로 남깁니다.

설치 스크립트가 설치 스크립트가 /etc/apt/sources.list.d/ 경로에 docker.list 파일을 생성하면서 작업을 하는데 버그가 있는지 기존 파일이 있으면 정상 동작하지 않습니다. 아래와 같은 오류가 발생합니다.

E: The repository 'http://ppa.launchpad.net/deadsnakes/ppa/ubuntu plucky Release' does not have a Release file.

그렇기 때문에...
apt 목록을 임시로 옮겨놓습니다.

sudo mkdir /etc/apt/sources.list.d/BACKUP
sudo mv /etc/apt/sources.list.d/* /etc/apt/sources.list.d/BACKUP

설치 스크립트를 받습니다.

curl -fsSL https://get.docker.com -o get-docker.sh

이 스크립트를 root 권한으로 설치합니다.

sudo bash get-docker.sh

os 버전이 오래되었다면 경고가 뜰 수도 있습니다.

deprecation warning 은 무시합시다.

정상적으로 설치되면 아래와 같은 안내문이 나오고 종료됩니다.

docker version 명령으로 잘 설치되어 있는지 확인해봅시다.

아래 오류 메시지를 보셨으면 느끼셨을 테지만 root 권한에서만 사용할 수 있습니다. 현재 계정(pi)에서 사용하려면 그룹에 추가해줘야 합니다.

sudo usermod -aG docker pi

pi 대신 다른 계정을 쓰고 있다면 pi 를 해당 계정명으로 교체해주세요

위 명령을 내렸어도 여전히 permission denied 뜰 겁니다. 왜냐하면 현재 로그인된 셸에는 반영이 안되어 있거든요!

다시 로그아웃 했다가 접속하면 permission denied 메시지는 안보입니다.

자 이제 설치가 잘 되었으니 apt 저장소 목록을 복원합시다!!

sudo mv /etc/apt/sources.list.d/BACKUP/* /etc/apt/sources.list.d/

docker 이미지가 저장되는 위치 root 디렉토리를 확인하고 싶다면 docker info 명령을 내려보세요

Docker Root Dir 이란 곳에서 확인할 수 있습니다.

여기까지 되었다면 docker hub 에서 찾아서 사용하거나 나만의 컨테이너를 만들어서 사용하시면 됩니다.

만약에 docker hub 에서 이미지를 받은 적이 있다면 docker inspect 이미지명 으로 실제 경로및 정보를 확인할 수 있습니다.

이 외에 다른 명령은 다음 포스트에 정리하겠습니다.

[linux][bash] 파일 크기 감시하기

심량 — Mon, 11 Nov 2024 10:59:20 +0900

파일 크기를 감시할 때 기존에는 아는 선에서 방법을 조합해서 사용했습니다.

리눅스에서 보통 ls -l 하면 파일의 상세 정보가 나오는데 5번째 항목에 파일 크기가 나옵니다.

ls -l kk.jpg
-rw-r--r-- 1 arhis arhis 32277 Oct 28 10:42 kk.jpg

이것을 awk 로 5번째에 있는 항목을 출력했습니다.

ls -l kk.jpg | awk '{print $5}'

그런데 더 간단하고 pipe 안써도 되는 방법이 있었네요!!

stat --format=%s kk.jpg
32767

참고로 stat 옵션입니다.

$ stat --help
Usage: stat [OPTION]... FILE...
Display file or file system status.

Mandatory arguments to long options are mandatory for short options too.
  -L, --dereference     follow links
  -f, --file-system     display file system status instead of file status
  -c  --format=FORMAT   use the specified FORMAT instead of the default;
                          output a newline after each use of FORMAT
      --printf=FORMAT   like --format, but interpret backslash escapes,
                          and do not output a mandatory trailing newline;
                          if you want a newline, include \n in FORMAT
  -t, --terse           print the information in terse form
      --help     display this help and exit
      --version  output version information and exit

The valid format sequences for files (without --file-system):

  %a   access rights in octal (note '#' and '0' printf flags)
  %A   access rights in human readable form
  %b   number of blocks allocated (see %B)
  %B   the size in bytes of each block reported by %b
  %C   SELinux security context string
  %d   device number in decimal
  %D   device number in hex
  %f   raw mode in hex
  %F   file type
  %g   group ID of owner
  %G   group name of owner
  %h   number of hard links
  %i   inode number
  %m   mount point
  %n   file name
  %N   quoted file name with dereference if symbolic link
  %o   optimal I/O transfer size hint
  %s   total size, in bytes
  %t   major device type in hex, for character/block device special files
  %T   minor device type in hex, for character/block device special files
  %u   user ID of owner
  %U   user name of owner
  %w   time of file birth, human-readable; - if unknown
  %W   time of file birth, seconds since Epoch; 0 if unknown
  %x   time of last access, human-readable
  %X   time of last access, seconds since Epoch
  %y   time of last data modification, human-readable
  %Y   time of last data modification, seconds since Epoch
  %z   time of last status change, human-readable
  %Z   time of last status change, seconds since Epoch

Valid format sequences for file systems:

  %a   free blocks available to non-superuser
  %b   total data blocks in file system
  %c   total file nodes in file system
  %d   free file nodes in file system
  %f   free blocks in file system
  %i   file system ID in hex
  %l   maximum length of filenames
  %n   file name
  %s   block size (for faster transfers)
  %S   fundamental block size (for block counts)
  %t   file system type in hex
  %T   file system type in human readable form

--terse is equivalent to the following FORMAT:
    %n %s %b %f %u %g %D %i %h %t %T %X %Y %Z %W %o %C
--terse --file-system is equivalent to the following FORMAT:
    %n %i %l %t %s %S %b %f %a %c %d

자 이제 감시를 해야겠죠?

watch -d -n 2 "stat --format=%s kk.jpg"

watch -d -n 2 "stat --format=%s kk.jpg"

파일 크기 알아내는 명령을 2초마다(-n 2) 차이점을 강조(-d)해서 보여줍니다.

이제 스크립트에서 간편하게 값만 가져오거나 계속 감시할 수 있게 되었습니다.

[펌] python3 용 ctag 사용법

심량 — Tue, 5 Nov 2024 11:19:01 +0900

기본적인 내용은 rampart81 님의 블로그 포스트를 참고하시면 됩니다.

위 내용은 윈도우인 경우이고 리눅스는 python3 로 지정하지 않으면 오류 뜰 확률이 높아 살짝 수정해서 저장용으로 사용니다.

alias python_ctags="ctags -R --fields=+l --languages=python --python-kinds=-iv -f ./tags . $(python3 -c "import os, sys; print(' '.join('{}'.format(d) for d in sys.path if os.path.isdir(d)))")"

Ubuntu 20.04에서 Valkey(구 Redis) 소스 설치하는 방법

심량 — Wed, 30 Oct 2024 14:30:38 +0900

Valkey는 Redis에서 포크된 오픈소스 인메모리 데이터 스토어입니다. Ubuntu 24.04 이상에서는 공식 패키지로 제공되지만, Ubuntu 20.04에서는 직접 소스에서 컴파일해야 사용할 수 있습니다.
이 글에서는 Ubuntu 20.04 환경에서 Valkey를 컴파일 및 설치하는 최신 절차를 정리했습니다.

Valkey가 무엇인가요?

Valkey는 Redis의 오픈소스 포크로, Redis가 BSL 라이선스로 변경된 이후 만들어졌습니다. Valkey는 여전히 완전한 오픈소스로 유지되며, Redis의 기존 기능을 대부분 계승합니다.

사전 준비: 의존 패키지 설치

Valkey는 컴파일 시 TLS, RDMA, systemd 지원 등을 위해 추가 라이브러리를 필요로 합니다.

sudo apt update
sudo apt install -y librdmacm-dev libibverbs-dev libsystemd-dev build-essential git

소스 코드 다운로드

공식 GitHub 저장소에서 최신 소스를 클론합니다.

git clone https://github.com/valkey-io/valkey.git
cd valkey

⚙️ 컴파일

기본적인 컴파일 명령은 아래와 같습니다:

make

하지만 기능을 활성화하고 테스트까지 포함하려면 다음과 같이 빌드할 수 있습니다:

make BUILD_TLS=yes BUILD_RDMA=module USE_SYSTEMD=yes test

옵션 설명:

BUILD_TLS=yes → TLS 암호화 지원
BUILD_RDMA=module → RDMA 모듈 지원
USE_SYSTEMD=yes → systemd 서비스화 기능 포함
test → 설치 전 테스트 자동 실행

한 줄로 모든 빌드 + 설치까지 진행하려면:

sudo LANG=C time make BUILD_TLS=yes BUILD_RDMA=module USE_SYSTEMD=yes test deps install

️ 설치

기본적으로 PREFIX는 /usr/local이지만, 명시적으로 지정할 수도 있습니다.

sudo make PREFIX=/usr/local install

실행 확인

/usr/local/bin/valkey-server --version

버전 정보가 출력되면 설치가 완료된 것입니다.

구성 및 서비스 등록 (선택)

systemd 서비스를 등록하여 자동 실행하고 싶다면 utils 디렉토리 내 스크립트를 참고하거나 다음과 같이 설정할 수 있습니다:

sudo cp utils/valkey.service /etc/systemd/system/
sudo systemctl daemon-reexec
sudo systemctl enable valkey
sudo systemctl start valkey

※ 위 파일은 직접 수정하여 ExecStart 경로 등을 시스템에 맞게 조정해야 합니다.

참고 자료

요약

Ubuntu 24.04 이상은 패키지로 설치 가능
20.04에서는 git clone 후 직접 컴파일 필요
make BUILD_TLS=yes USE_SYSTEMD=yes 방식 권장
의존 패키지 먼저 설치 필수

이제 Ubuntu 20.04 환경에서도 Valkey를 문제없이 사용할 수 있습니다. Redis를 대체할 새로운 오픈소스 키-값 저장소가 궁금하다면 직접 설치해 보세요!

[Nox] 특정 앱으로 바로 시작하는 바로가기 만들기

심량 — Mon, 30 Sep 2024 14:11:46 +0900

Nox 설치가 정상적으로 되어 있다면 시작메뉴에 Nox 바로가기가 존재합니다.

이 바로가기가 위치한 곳으로 이동해야 합니다.

해당 아이콘에 마우스 우클릭하면 나오는 메뉴에서 파일 위치 열기를 실행합니다.(윈도우11 기준)

해당 바로가기 파일이 보일때 마우스 우클릭하면 속성 이라는 메뉴가 있습니다. 이를 실행합니다.

이 바로가기가 가리키고 있는 명령("~~~\Nox.exe") 끝에 다음과 추가합니다.

"~~~\Nox.exe" -startPackage:com.sesisoft.PuyoQuest

참고로 위 명령은 뿌요뿌요퀘스트 앱을 바로 실행할 하고 싶을 때 작성합니다.

다른 앱을 지정하고 싶으면 그 앱이 설치가 되어 있어야 하고 해당 앱의 패키지 명을 알아내어 위 -startPackage: 뒤에 써줘야 합니다.

이를 알아내려면..

cmd 창을 열어서 adb 로 현재 실행된 프로세스 목록을 얻어서 찾아야 합니다.

먼저 adb devices 명령으로 조회되는지 확인해봅니다.

어.. 그런데 분명 nox 가 실행되어 있는데 목록에 없네요

chatgpt 씨에게 물어보니 그런 경우에는 기본 주소(127.0.0.1:62001)로 접속해보라고 하네요

다행히 잘 접속되네요.

장비 목록에도 잘 나타납니다.

프로세스 목록을 볼까요?

어휴.. 뭐가 복잡한 게 막 뜨죠?

보통 개발한 앱은 com. 으로 시작합니다. "com." 으로 결과를 필터링하면 좀 찾기 쉬워지겠죠?

그렇지 않은 앱은 이 방법이 아닌 인터넷 검색으로 찾으셔야 할 것 같습니다... 아니면 chatgpt 씨한테??

adb shell ps | find /N "com."

다행히 제 결과는 몇개 안나와서 com.android 이랑 com.google 빼고 나니 몇개 안남았는데 게 중에 com.facebook 은 딱 봐도 아니니.. 범인은 com.sesisoft.PuyoQuest 가 되겠습니다.

만약 본인 폰에 프로그램이 백그라운드로 잔뜩 떠 있다면 더 알아보기 힘들텐데요..

모두 닫기로 정리하시고 찾고 싶은 프로그램만 실행시키시면 좀 더 수월히 찾을 수 있을 것 같습니다.

수정한 결과입니다.

실행해보니 해당 앱이 바로 실행되네요.

[linux] date 명령에 timezone 일시적으로 적용하기

심량 — Thu, 5 Sep 2024 16:04:33 +0900

date 명령에 시간대(timezone)를 적용하는 방법을 정리합니다.

영구적으로 적용하는 것은 timedatectl 을 사용하거나, /etc/localtime 파일이 가리키는 링크를 변경하거나, tzselect 명령을 사용하셔서 하시면 됩니다.

시스템 설정은 건드리지 않으면서 일시적으로 원하는 시간대를 date 명령에 적용하려면 TZ 라는 환경 변수를 설정하시면 됩니다.

다음과 같이 쓰면 됩니다. ash 에서도 되고 bash 에서도 됩니다.

TZ='KST-9' date +%Y%m%d-%H%M%S

TZ 에 들어가는 원하는 시간대의 키워드가 궁금하다면 아래 파일에서 각 줄의 두번째 항목을 참고하시면 됩니다.

참고로 한국은 ('Asia/Seoul', 'KST-9'), 로 되어 있으니까 위 예제처럼 'KST-9' 를 사용하시면 됩니다.

VSCode에서 Ctrl+Shift+K 단축키가 안 먹을 때? 원인은 Notion Desktop!

심량 — Fri, 16 Aug 2024 11:40:44 +0900

VSCode에서 줄 삭제 단축키인 Ctrl+Shift+K가 작동하지 않으시다면, Notion Desktop이 원인일 수 있습니다.
윈도우에서 글로벌 단축키 충돌 문제로 인해 자주 겪는 문제 중 하나입니다.

증상: Ctrl+Shift+K가 VSCode에서 작동하지 않음

Notion과 VSCode를 함께 사용하는 환경에서, 어느 날부턴가 VSCode에서 한 줄 삭제 단축키인 Ctrl+Shift+K가 반응하지 않는 문제가 발생할 수 있습니다.

해당 키는 기본적으로 /sys 등 시스템 명령어와 관계없고, 보통 Notion 데스크탑 앱이 글로벌 단축키로 점유하고 있어서 발생합니다.

왜 글로벌로 등록하냐고!!!

Notion의 글로벌 단축키 해제 방법

먼저 VSCode를 종료합니다.
Notion Desktop 앱을 실행한 뒤, 설정 > 내 설정으로 이동합니다.

명령어 검색 사용 기능을 비활성화합니다.
Notion을 종료하고 다시 실행합니다.
다시 설정 메뉴로 들어가면, 명령어 검색 단축키를 변경할 수 있는 옵션이 나타납니다.

해당 단축키를 실수로도 누르지 않을 조합으로 설정해두면 충돌을 방지할 수 있습니다.

어떤 앱이 단축키를 점유 중인지 확인하려면?

단축키 점유를 추적하고 싶은 경우, 아래 툴을 사용해보세요:

Hotkey Screener - 시스템 전역 단축키를 검사해 어떤 앱이 RegisterHotKey API로 등록했는지 확인할 수 있는 무료 툴입니다.

⚠️ 이런 툴들은 제작자가 서비스를 중단하는 경우가 많으므로, 백업해두거나 다운로드 링크를 보관해두는 것이 좋습니다.

HotkeyScreener.zip

2.87MB

팁: 단축키 충돌 방지 팁

자주 사용하는 앱 간에 중복되는 단축키 목록을 정리해두기
모든 앱의 글로벌 단축키는 최소화하고, 가능한 앱 내부 단축키만 사용하기
HotkeyScreener로 주기적으로 점검

[openwrt] flash 읽기 쓰기 테스트

심량 — Tue, 16 Jul 2024 15:05:04 +0900

현재 파일시스템의 남은 용량만큼 쓰기 및 읽기 테스트해서 flash 메모리 오류를 검사하고자 합니다.

[vscode] venv 생성 실패

심량 — Wed, 10 Jul 2024 11:46:00 +0900

vscode 에서 보통 가상 환경 추가할 때 화면 하단의 버전 정보를 클릭해서 Create Virtual Environment 를 지정하면 생성을 하게 됩니다.

[ssh][minicom] 원격 ssh 로 minicom script 사용하기

심량 — Fri, 14 Jun 2024 14:04:56 +0900

기록용으로 남깁니다.

USB 포트를 통해 시리얼로 연결된 장치가 있습니다.

이 장치는 두 개의 펌웨어( fw1.bin, fw2.bin)를 설치해야 업데이트를 할 수 있습니다.

기존에는 10대 이하의 장비에 일일이 접속해서 minicom -s 로 환경을 설정하고 쓰거나 minicom -b 115200 -D /dev/ttyUSB0 명령으로 실행해서 썼습니다.

minicom 으로 실행한 상태에서 xmodem 을 사용해서 펌웨어 이미지를 전송하고 장비 리셋을 시키는 구조였습니다.

예시
[start 엔터 키 입력

xm 엔터 키 입력

CCC 표시될 때 Ctrl + A, Z 입력, S 입력

아래 방향 키 두번 눌러서 xmodem 선택

fw1.bin 을 찾아 커서를 이동시킨 후 스페이스 바 키 눌러 선택

엔터키를 눌러 업데이트 진행

press any key 메시지 나오면 엔터 키 누르고

reset 엔터 키 입력 해서 리셋 잘 되는지 확인

위 과정 다시 반복하는데 파일 선택시 fw2.bin 만 다름

Ctrl + A, Z 입력, X 입력, 엔터 입력

위 내용을 보내는 방법을 찾는데 문서가 잘 나와있지 않았습니다. 그래서 최대한 예제들을 찾아 조합하고 gpt 도 괴롭혀보고 하다가 동작하는 내용을 찾았습니다.

예시

minicom -b 115200 -D /dev/ttyUSB0 -S minicom_script.txt

minicom_script.txt 내용

print "Starting upgrade firmware..."

send [start

send xm

! sx -vv fw1.bin

send [start

send xm

! sx -vv fw2.bin

send reset

print "Done upgrading!"

sleep 10

! killall -9 minicom

설명

send 는 문자열(보통 장비가 인식하는 명령)을 시리얼로 보냄

! 느낌표 빈칸 한개는 실행할 외부 명령어

여기에서는 sx 가 xmodem 으로 파일 전송하는 명령이라 사용했습니다.

print 는 없어도 됩니다. 아무 글씨도 안나오면 잘 되는지 불안해서 추가했습니다.

sleep 10 10초만큼 기다린다는 뜻입니다.

! killall -9 minicom 은 이게 없으면 minicom 화면이 그대로 남아 있습니다. 그래서 이 명령으로 강제 종료시켜 minicom 화면을 빠져나옵니다.

여기까지는 잘 되었습니다. 그런데 이를 remote ssh 명령으로 실행시키니...

No cursor motion capability (cm) 이란 오류 메시지와 함께 아무 일도 없이 끝나버렸습니다.

인터넷을 찾아보니 터미널을 linux-c-nc 로 바꿔서 쓰라고 합니다. 자세한 내용은 이 페이지를 참고하시기 바랍니다.

# minicom_script.txt, fw1.bin, fw2.bin 전송 한 후 아래 실행

TERM=linux-c-nc minicom -b 115200 -D /dev/ttyUSB0 -S minicom_script.txt

정상 실행됩니....는 아니네요. 실행 잘 되는 때도 있고 멈추는 때도 있습니다... 어쨌든 절반의 성공!!

멈췄던 원인은 다시 들어가보니 xmCCCCCCCC 만 잔뜩 표시되고 있더군요 xmodem 전송 명령인 sx 가 실행이 제대로 안된 느낌이었습니다. 이에 대한 대비책(?)이 있을지는 천천히 찾아봐야겠습니다. 좋은 방법 있으면 알려주세요~~!!