레루루의 경험 기록장

자바 시작하기 — JVM과 바이트 코드, 그리고 개발 환경

레루루 — Sun, 19 Jul 2026 13:07:35 +0900

자바 시작하기 — JVM과 바이트 코드, 그리고 개발 환경

프로그래밍 언어는 사람의 언어와 기계어 사이를 잇는 다리입니다. 사람 쪽에 가까운 고급 언어와 기계 쪽에 가까운 저급 언어가 나뉘어 있고, 자바는 그중 고급 언어에 속합니다.

이 글은 2021년 6월 기준 기록입니다.

자바는 한 번 작성해서 어디서나 실행하려고 만들어졌다

자바는 썬 마이크로시스템즈에서 발표한 언어입니다. 다양한 서버 운영체제에서 단 한 번의 작성으로 모든 곳에서 실행 가능한 언어는 자바뿐이었기 때문에, 공공기관 웹 애플리케이션 구축용 언어로 성장했습니다.

이 "한 번 작성"이라는 성질이 자바의 첫 번째 특징인 이식성입니다. 자바로 개발된 프로그램은 소스 파일을 다시 수정하지 않아도, 자바 실행 환경(JRE)이 설치되어 있는 모든 운영체제에서 실행됩니다.

두 번째는 객체 지향 언어라는 점입니다. 부품에 해당하는 객체들을 먼저 만들고, 이것들을 하나씩 조립하고 연결해서 전체 프로그램을 완성하는 기법을 객체 지향 프로그래밍(OOP)이라고 합니다. 자바는 캡슐화, 상속, 다형성 기능을 완벽하게 지원합니다.

세 번째는 함수적 스타일 코딩 지원입니다. 함수적 프로그래밍을 위해 자바 8부터 람다식을 지원합니다. 람다식을 사용하면 컬렉션의 요소를 필터링, 매핑, 집계 처리하기가 쉬워지고 코드가 매우 간결해집니다.

네 번째는 메모리 자동 관리입니다. 객체를 생성할 때 자동으로 메모리 영역을 찾아서 할당하고, 사용이 완료되면 Garbage Collector를 실행시켜 사용하지 않는 객체를 자동으로 제거합니다.

다섯 번째는 다양한 애플리케이션 개발이 가능하다는 점입니다. 콘솔 프로그램에서부터 윈도우 애플리케이션, 서버용 웹 애플리케이션, 모바일 안드로이드 앱까지 개발할 수 있습니다. 다양한 운영체제에서 사용할 수 있는 개발 도구와 API를 묶어 에디션(Edition) 형태로 정의하고 있습니다.

여섯 번째는 멀티 스레드(Multi-Thread)를 쉽게 구현할 수 있다는 점입니다. 스레드 생성 및 제어와 관련된 라이브러리 API를 제공합니다.

일곱 번째는 동적 로딩 지원입니다. 애플리케이션이 실행될 때 모든 객체가 생성되지 않고, 객체가 필요한 시점에 클래스를 동적으로 로딩해서 객체를 생성합니다.

이식성은 JVM이 대신 짊어진다

자바 프로그램이 컴파일되어 나오는 것은 완전한 기계어가 아니라 중간 단계의 바이트 코드입니다. 그래서 이것을 해석하고 실행할 가상의 운영체제가 필요한데, 그것이 자바 가상 기계(JVM)입니다. JVM은 실제 운영체제를 대신해서 자바 프로그램을 실행하는 가상의 운영체제 역할을 합니다.

여기서 관계가 뒤집혀 있다는 점이 중요합니다. 바이트 코드는 모든 JVM에서 동일한 실행 결과를 보장하지만, JVM 자체는 운영체제에 종속적입니다. 운영체제마다 다른 JVM이 설치되고, 그 JVM들이 똑같은 바이트 코드를 각자의 기계어로 번역합니다. 개발자가 이식성을 신경 쓰지 않아도 되는 이유는 JVM이 그 차이를 대신 흡수하기 때문입니다. JVM은 JDK 또는 JRE를 설치하면 자동으로 설치됩니다.

다만 대가가 있습니다. JVM에 의해 기계어로 번역되고 실행되기 때문에, C와 C++의 컴파일 단계에서 만들어지는 완전한 기계어보다는 속도가 느립니다.

JDK는 JRE를 품고, JRE는 JVM을 품는다

자바 개발 도구를 고를 때 먼저 마주치는 것은 에디션 구분입니다.

JAVA SE(Standard Edition) — 자바 프로그램 개발에 필수적인 도구와 라이브러리 API를 정의합니다.
JAVA EE(Enterprise Edition) — 분산 환경에서 서버용 애플리케이션을 개발하기 위한 도구 및 라이브러리 API를 정의합니다.

그다음이 JRE와 JDK의 관계입니다. 둘은 대등한 선택지가 아니라 포함 관계입니다.

JRE = JVM + 표준 클래스 라이브러리
JDK = JRE + 개발에 필요한 도구

JDK를 설치하면 기본 위치에 bin 디렉토리가 있고 그 안에 java 명령어들이 들어 있습니다. 이 명령어들을 어느 디렉토리에서든 사용하려면 Path 환경 변수에 bin 위치를 등록해야 합니다. 통상 JAVA_HOME으로 JDK가 설치된 경로를 설정한 뒤, Path에 %JAVA_HOME%bin을 설정합니다.

한편 자바 프로그램을 개발하려면 JDK에서 제공하는 표준 클래스 라이브러리를 반드시 사용해야 합니다. 이 클래스들을 API(Application Programming Interface)라고도 부릅니다. API가 매우 방대하기 때문에 쉽게 찾아볼 수 있도록 API 도큐먼트가 제공됩니다.

소스에서 실행까지는 세 단계다

자바 프로그램은 확장자가 .java인 파일을 작성하는 것에서 시작합니다. 전체 흐름은 다음 세 단계입니다.

자바 소스 파일(.java)을 작성합니다.
컴파일러(javac.exe)로 컴파일하면 확장자가 .class인 바이트 코드 파일이 생성됩니다.
JVM 구동 명령어(java.exe)로 실행하면, 바이트 코드 파일이 JVM에서 해석되고 해당 운영체제에 맞는 기계어로 번역됩니다.

클래스 이름은 파일 이름과 대소문자까지 같아야 한다

소스 파일의 뼈대는 클래스입니다. 클래스는 필드 또는 메소드를 포함하는 블록이고, 중괄호 {부터 그와 짝을 이루는 }까지가 클래스 블록입니다.

클래스 이름은 개발자가 마음대로 정할 수 있지만 제약이 있습니다.

소스 파일명과 대소문자가 일치해야 합니다.
숫자로 시작할 수 없고, 공백을 포함해서는 안 됩니다.
일반적으로 대문자로 시작하도록 약속되어 있습니다.

클래스 블록 안에는 메소드가 들어갑니다. 메소드는 어떤 일을 처리하는 실행문들을 모아 놓은 블록이며, 반드시 클래스 블록 내부에 작성되어야 합니다. 메소드 이름 역시 개발자가 정할 수 있지만 main() 메소드만은 이름을 바꾸면 안 됩니다. java.exe로 JVM을 실행시키면 제일 먼저 main() 메소드를 찾아서 실행시키기 때문입니다.

세미콜론이 실행문의 끝을 정한다

주석은 프로그램 실행과 상관없이 코드에 설명을 붙인 것입니다. 컴파일 과정에서 주석은 무시되고 실행문만 바이트 코드로 번역됩니다. 자바의 주석은 세 가지입니다.

// — 행 주석. //부터 라인 끝까지를 주석으로 처리합니다.
/* ~ */ — 범위 주석. /*와 */ 사이에 있는 모든 범위를 주석으로 처리합니다.
/** ~ */ — 도큐먼트 주석. javadoc.exe 명령어로 API 도큐먼트를 생성하는 데 사용됩니다.

실행문은 변수 선언, 값 저장, 메소드 호출에 해당하는 코드를 말합니다. 실행문의 마지막에는 반드시 세미콜론(;)을 붙여서 실행문이 끝났음을 표시해야 합니다.

여기서 한 가지가 따라 나옵니다. 컴파일러는 세미콜론이 나올 때까지 실행문이 계속 연결된 것으로 보기 때문에, 줄바꿈은 실행문의 경계가 아닙니다. 한 실행문이 여러 줄에 걸쳐 있어도 되고, 한 줄에 여러 개의 실행문이 있어도 됩니다.

이클립스는 워크스페이스에 작업 환경을 기억한다

이클립스는 자바 프로그램 개발을 위한 통합 개발 환경(IDE)입니다. 프로젝트 생성, 자동 코드 완성, 디버깅 기능을 제공합니다.

이클립스 자체가 자바 언어로 개발된 툴이기 때문에, 이클립스를 실행하려면 JVM이 필요합니다. 즉 JDK를 먼저 설치한 후 이클립스 사이트(www.eclipse.org)에서 받아서 설치합니다. 순수 자바만 다룬다면 Eclipse IDE for Java Developers를, 웹 애플리케이션 등 엔터프라이즈 환경에서 실행되는 자바 애플리케이션을 개발하려면 Eclipse IDE for Java EE Developers를 받아야 합니다.

워크스페이스(Workspace)는 이클립스에서 생성한 프로젝트가 기본적으로 저장되는 디렉토리입니다. 이클립스는 실행될 때 적용되는 메타데이터를 워크스페이스의 하위 디렉토리인 .metadata에 저장하고, 동일한 워크스페이스에서 재시작할 경우 이전에 작업한 환경으로 복원합니다. 반대로 이클립스를 초기 상태로 돌리고 싶다면 .metadata 디렉토리를 강제로 삭제하고 재시작하면 됩니다.

화면 구성은 퍼스펙티브와 뷰로 이루어집니다. 뷰(view)는 이클립스 내부에서 사용되는 작은 창이고, 퍼스펙티브(Perspective)는 프로젝트를 개발할 때 유용하게 쓰는 뷰들을 묶어 놓은 것입니다. Eclipse IDE for Java EE Developers는 기본적으로 Java EE 퍼스펙티브를 보여 줍니다. 가장 많이 사용하는 뷰는 프로젝트를 관리하고 자바 소스 파일을 생성·삭제하는 Package Explorer 뷰이고, Console 뷰는 프로그램에서 콘솔로 출력하는 내용을 보여 줍니다.

프로젝트 생성과 컴파일

자바 소스 파일을 작성하려면 우선 자바 프로젝트를 생성해야 합니다. 프로젝트는 기본적으로 워크스페이스의 하위 디렉토리로 생성됩니다. 생성 시 지정하는 JRE는 프로젝트를 실행할 때 사용할 버전을 말합니다. Project layout에는 자바 소스 파일(.java)과 컴파일된 바이트 코드 파일(.class)을 분리 저장하도록 설정되어 있어서, 소스 파일은 src에, 바이트 코드 파일은 bin 디렉토리에 기본 저장됩니다.

소스 파일은 [New] - [Class]를 선택해 New Java Class 대화 상자에서 만듭니다. 여기서 말하는 Package는 클래스를 포함하는 그룹명 정도로 생각하면 됩니다. 에디터의 행 번호를 보고 싶다면 [Window] - [Preferences]에서 [General] - [Editors] - [Text Editors]를 선택한 후 [Show line numbers]를 체크합니다.

작성한 소스를 저장하면 내부적으로 javac가 자동 실행되어 컴파일을 수행합니다. 컴파일이 성공하면 bin 디렉토리에 바이트 코드 파일이 생성됩니다. bin 디렉토리는 Package Explorer에서는 보이지 않으므로, 확인하고 싶다면 [Window] - [Show View] - [Navigator]를 선택합니다.

실행은 Package Explorer 뷰에서 실행할 소스 파일을 선택하고 우클릭 후 [Run As] - [Java Application]을 클릭하거나, 툴바의 실행 버튼을 클릭하면 됩니다.

소스를 쓰고, 바이트 코드로 컴파일하고, JVM이 그것을 각자의 운영체제 위에서 실행한다 — 자바를 시작하며 잡아야 할 그림은 이 한 줄로 정리됩니다.

README.md - 소개

레루루 — Sat, 18 Jul 2026 23:52:49 +0900

md 파일 여는 프로그램이 없어서 직접 만들었습니다 — 오프라인 마크다운 에디터 README.md

메모장으로 열리던 .md 파일이 답답해서, 결국 리더를 하나 만든 이야기입니다.

깃허브에서 받은 프로젝트 폴더를 열고 README.md 를 더블클릭했더니, 메모장이 떴습니다. # 과 * 과 백틱이 날것 그대로 박힌 화면. 분명 누군가는 이 문서를 예쁘게 조판된 모습으로 보라고 썼을 텐데, 제 화면에는 기호만 잔뜩이었습니다.

VS Code 를 켜자니 문서 하나 읽자고 켜는 게 과했고, 웹 마크다운 에디터는 편했지만 제 글을 남의 서버에 올려야 했습니다. 회사 문서든 개인 메모든, 붙여 넣기 전에 한 번씩 손이 멈추더군요.

마땅한 게 없어서 직접 만들었고, 그게 README.md 입니다.

이름이 곧 사용법입니다 — 앱 이름은 README.md

네, 앱 이름이 README.md 입니다. 마크다운이라는 형식을 세상에서 가장 많이 만나게 되는 파일 이름을 그대로 가져왔습니다. 풀어 읽으면 "read me" — 읽어 달라는 뜻이기도 하고요.

솔직히 말하면 여기까지 오는 데 이름을 두 번 갈아엎었습니다. 처음엔 밋밋하게 md-reader, 다음엔 한글로 "결". 둘 다 며칠을 못 갔습니다. 설명이 필요한 이름은 이미 진 이름이라는 생각이 들어서요. README.md 는 개발자라면 설명이 필요 없습니다.

대신 대가를 치렀습니다. 이름에 점이 들어간 앱을 만들면 설치 파일 이름부터 꼬이거든요. 그 뒷이야기는 언젠가 따로 쓰겠습니다.

왼쪽에 쓰면 오른쪽에 조판됩니다

핵심은 단순합니다. 왼쪽 창에 마크다운을 쓰면, 오른쪽 창에 조판된 문서가 타이핑하는 즉시 나타납니다.

왼쪽 에디터에 마크다운을 쓰면 오른쪽 미리보기에 조판된 문서가 실시간으로 나타납니다

그런데 "미리보기"라는 말이 종종 반쪽짜리인 게 문제였습니다. 표는 되는데 각주가 안 되고, 코드는 나오는데 색이 없고, 수식은 아예 포기해야 하는 도구들을 여럿 거쳤습니다. 그래서 이것들을 처음부터 다 넣었습니다.

코드 문법 하이라이트 — 언어를 알아서 잡아 색을 입힙니다
수식 — KaTeX 로 렌더링합니다. LaTeX 문법 그대로 쓰시면 됩니다
다이어그램 — Mermaid 를 지원합니다. 순서도·ER·클래스·상태·시퀀스 다이어그램을 글로 써서 그립니다
각주 · 표 · 콜아웃 · 체크리스트 — GitHub 에서 보던 그 모양 그대로

특히 Mermaid 는 제가 가장 아끼는 기능입니다. 다이어그램 툴을 따로 켜지 않고, 문서 안에 flowchart LR 한 줄 적고 화살표를 잇는 것만으로 그림이 나옵니다. 그림 파일이 아니라 글이라서, 나중에 고치는 것도 한 줄 고치면 끝입니다.

인터넷을 아예 쓰지 않습니다 — 100% 오프라인

이 앱은 네트워크를 쓰지 않습니다. 계정도 없고, 로그인도 없고, 분석 SDK 도 없습니다.

"수집하지 않습니다"라고 말로만 하는 건 저도 여러 번 봤습니다. 그래서 말 대신 구조로 막았습니다. 앱에 하드닝된 CSP 를 걸어서 원격 http·https 요청 자체를 차단해 뒀습니다. 제가 나중에 마음이 바뀌어 추적 코드를 넣고 싶어도, 그 요청이 앱 밖으로 나가지 못합니다.

문서를 열고, 읽고, 쓰고, 내보내는 모든 과정이 당신의 디스크 안에서만 일어납니다. 그리고 그렇게 쓴 글의 모든 권리는 당신 것입니다 — 개인이든 업무든, 상업적으로 쓰셔도 됩니다.

흩어진 문서를 한자리에 — 워크스페이스

문서가 두세 개일 땐 아무 도구나 괜찮습니다. 문제는 서른 개가 넘어가면서부터죠.

폴더를 통째로 열면 왼쪽에 트리가 뜨고, 탭으로 여러 파일을 동시에 열어 둘 수 있습니다. 여기까진 흔한 이야기입니다. 제가 정말 필요했던 건 그다음이었습니다.

가상 폴더 — 디스크 여기저기 흩어진 문서를 원본은 그대로 둔 채 드래그해서 제가 원하는 구조로 묶습니다. 프로젝트 A 의 설계서와 프로젝트 B 의 회의록을 한 폴더에 나란히 두는 식으로요
전역 전문검색 — 워크스페이스 전체에서 본문을 검색합니다. 파일 이름이 아니라 내용을요
전역 찾기·바꾸기 — 정규식을 지원하고, 바꾸기 전에 파일별로 미리 보고 고를 수 있습니다
명령 팔레트 Ctrl+Shift+P · 퀵오픈 Ctrl+P — 손을 키보드에서 떼지 않아도 됩니다
아웃라인 · 즐겨찾기 — 긴 문서 안에서 길을 잃지 않도록

다 쓴 문서는 파일 하나로 — HTML·PDF 내보내기

다 쓴 다음이 늘 문제였습니다. 마크다운 파일을 그대로 보내면 상대방도 마크다운 뷰어가 있어야 하니까요.

그래서 자기완결 HTML 로 내보냅니다. 이미지도, 폰트도 파일 안에 통째로 박아 넣어서 .html 파일 하나만 보내면 상대방 브라우저에서 제가 본 그대로 열립니다. 이미지 폴더를 같이 압축해 보낼 필요가 없습니다. PDF 로도 저장할 수 있고요.

읽는 환경도 여러 갈래로 준비했습니다. 에디터를 접고 문서에만 집중하는 리딩 모드, 문서를 그대로 슬라이드로 띄우는 프레젠테이션 모드, 그리고 눈이 편한 쪽으로 고르는 라이트·다크·페이퍼 세 가지 테마.

다크 테마 — 밤에 문서를 읽을 때 쓰는 화면입니다

페이퍼 테마는 종이 질감을 흉내 낸 것인데, 만들 땐 반쯤 장난이었다가 지금은 제가 가장 오래 켜 두는 테마가 됐습니다.

페이퍼 테마 — 종이 위에서 읽는 느낌을 흉내 냈습니다(지금은 조금 덜 노랗습니다)

설치하기

Microsoft Store 에서 무료로 받으실 수 있습니다. 게시자는 SlnU, Windows 10 이상이면 동작합니다. 설치하면 .md·.markdown 파일이 자동으로 연결되니, 그다음부터는 그냥 더블클릭하시면 됩니다.

▶ Microsoft Store 에서 README.md 설치하기

이제 README.md 를 더블클릭하면, 메모장 대신 읽으라고 쓰인 그 문서가 열립니다.

[AI] 000 - 개요

레루루 — Sat, 18 Jul 2026 20:47:30 +0900

AI 엔지니어링 공부, 밑바닥부터 시작합니다

요즘 AI 없이 일한 날이 거의 없습니다. 개인적으로도 쓰고, 회사에서도 지원을 받아 적극적으로 쓰고 있습니다. 주로 AI 에이전트에게 애플리케이션 설계와 개발, 데이터 분석, 자료 정리를 맡깁니다. 특히 난이도가 높지는 않은데 번거롭고 시간만 잡아먹는 일 — 거기서는 정말 압도적인 효율을 체감합니다.

그런데 얼마 전에 문득 이런 생각이 들었습니다.

이렇게 잘 쓰고 있는데, 정작 이 안에서 무슨 일이 벌어지는지 저는 설명하지 못합니다.

쓰는 것과 아는 것 사이

SNS와 인터넷에는 에이전틱 AI 관련 정보와 경험 글이 매일 쏟아집니다. ChatGPT가 크게 주목받던 시기부터 지금까지, 변화 속도가 점점 빨라진다고 느낍니다. 저도 그 흐름 위에서 도구를 갈아타며 따라왔습니다.

문제는 그 따라감이 전부 표면에서 일어났다는 것입니다. 프롬프트를 다듬는 법은 늘었는데 모델이 왜 그렇게 답하는지는 모릅니다. 에이전트에 도구를 붙일 줄은 아는데, 그 에이전트를 굴리는 모델 안에서 어텐션(attention)이 무슨 일을 하는지는 설명하지 못합니다. 잘 쓰는 것과 아는 것은 다른 능력이었습니다.

물론 최근 몇 개월의 체감이 개발자라는 위치 때문에 유난히 클 수도 있습니다. 다만 그렇다 해도, 도구가 이만큼 빠르게 바뀌는 시기에 표면만 따라가는 방식이 오래 버틸 것 같지는 않았습니다.

그래서 밑바닥부터

그래서 ai-engineering-from-scratch라는 오픈소스 커리큘럼을 처음부터 훑기로 했습니다. 20개 Phase, 435개 레슨, 약 320시간 분량입니다. 선형대수에서 시작해 자율 에이전트와 프로덕션 인프라까지 이어집니다.

이걸 고른 이유는 하나입니다. 프레임워크보다 원리를 먼저 시킵니다. 역전파(backpropagation)도, 토크나이저도, 어텐션도, 에이전트 루프도 전부 맨손으로 한 번 구현한 뒤에야 PyTorch가 등장합니다. 라이브러리 사용법은 검색하면 나오지만, 그 안에서 무슨 일이 벌어지는지는 한 번 만들어 봐야 남는다고 생각했습니다.

기록을 남기는 방식

공부한 내용은 레슨마다 한국어로 정리해 올릴 예정입니다. 원문 번역만 옮기는 대신, 직접 돌려서 나온 실제 출력과 그 과정에서 걸린 문제·해결법을 함께 남깁니다. 특히 윈도우 환경에서만 터지는 것들이 꽤 있어서, 같은 데서 막힐 분들에게는 그 부분이 제일 쓸모 있을 것 같습니다.

지어낸 내용은 넣지 않으려 합니다. 안 돌려 본 코드의 출력은 적지 않고, 재현하지 못한 문제는 "이럴 수 있습니다"로 얼버무리지 않기로 했습니다. 제가 어떤 식으로 AI를 활용하고 있는지는 별도 카테고리에서 따로 다루겠습니다.

ShotLog - 자기 자신을 찍는 캡처 프로그램

레루루 — Thu, 16 Jul 2026 20:00:09 +0900

앱에게 시켰습니다 — 자기 스크린샷을 직접 찍으라고

테스트 프로젝트가 0개인 앱이 스스로를 검증하고 릴리스 에셋까지 만드는 법 — CLI 훅 네 개.

UI 를 한 줄 고쳤습니다. 옵션 하나가 늘어서 창에 행이 하나 추가됐을 뿐입니다.

그런데 그 한 줄 때문에 스토어 리스팅 스크린샷을 여덟 장 다시 찍어야 했습니다. 한국어 넷, 영어 넷. 앱을 띄우고, 언어를 바꾸고, 그럴듯한 샘플 데이터를 손으로 채워 넣고, 창 크기를 맞추고, 캡처하고, 배경을 지우고, 1366×768 캔버스에 앉히고… 여덟 번.

세 번째 릴리스에서 손이 멈췄습니다. 이건 제가 할 일이 아니라는 생각이 들더군요. 화면을 찍는 앱을 만들면서, 정작 그 앱의 스크린샷은 제가 손으로 찍고 있었습니다.

그래서 앱에게 시켰습니다.

창을 열지 않고 회귀를 잡습니다 — `--selftest`

먼저 고백부터. 이 프로젝트엔 테스트 프로젝트가 없습니다. xUnit 도, NUnit 도, 목 프레임워크도요.

변명이 아니라 판단이었습니다. 이 앱의 핵심 위험은 로직이 아니라 파이프라인에 있습니다. 화면을 잡고 → PNG 로 저장하고 → 메모를 사이드카 .md 로 쓰고 → 여러 캡처를 묶어 Markdown 문서로 내보내는 흐름. 이게 깨지면 앱이 무너집니다. 그런데 이 흐름은 GDI 와 파일 시스템에 발을 담그고 있어서, 유닛 테스트로 잘라 내면 정작 위험한 부분은 전부 목으로 대체됩니다. 테스트는 통과하는데 앱은 망가지는 그림이 눈에 선했습니다.

그래서 반대로 갔습니다. 앱 자신에게 그 파이프라인을 한 번 통째로 걷게 합니다.

dotnet run --project src/ShotLog/ShotLog.csproj -- --selftest

--selftest 인자를 받으면 앱은 창을 하나도 띄우지 않고, 임시 폴더에서 캡처 → 저장 → 사이드카 → 내보내기 → 단축키 파서까지 실제로 돌린 뒤, 생성된 마크다운 본문까지 통째로 %APPDATA%\ShotLog\selftest.log 에 적고 종료합니다. 마지막 줄엔 RESULT=OK 나 RESULT=FAIL 이 남고요.

두 가지가 중요했습니다. 진짜 저장소를 건드리지 않는다는 것(전부 Path.GetTempPath() 아래), 그리고 결과물을 눈으로 볼 수 있다는 것. 통과/실패만 알려 주는 초록 불보다, 실제로 나온 마크다운을 읽는 쪽이 훨씬 많은 걸 잡아냅니다.

화면 밖 -10000 에 창을 띄웁니다 — `--screens`

그리고 처음의 그 문제, 스크린샷입니다.

--screens <폴더> [ko|en] 을 주면 앱이 이렇게 움직입니다. 언어를 그 언어로 갈아 끼우고, 그럴듯한 가짜 캡처 네 건을 시드합니다("대시보드 로딩 지연 — 첫 로딩이 3초+ 걸림. 캐시 미스 의심." 같은, 프리셋과 태그까지 붙은 것들). 그리고 인박스·글쓰기·설정·빠른 메모 창을 차례로 띄워 렌더한 뒤, 각각을 1366×768 다크 캔버스 한가운데에 앉혀 저장합니다.

핵심은 창을 화면 밖 (-10000, -10000) 에 띄운다는 것입니다. 작업 표시줄에도 안 뜨고, 사용자 화면을 가리지도 않고, 그냥 좌표계 저 바깥에서 조용히 그려집니다. 그걸 RenderTargetBitmap 으로 굽습니다.

하나의 실행 파일이 네 갈래 CLI 훅으로 갈라져 검증 로그와 릴리스 에셋을 스스로 만듭니다

여기서 한 번 데였습니다. Show() 하고 바로 렌더하면 덜 그려진 프레임이 나옵니다. 레이아웃이 아직 확정되지 않았거든요. 그래서 이렇게 두 번 펌핑합니다.

w.Show();
afterShow?.Invoke();
w.UpdateLayout();
w.Dispatcher.Invoke(() => { }, DispatcherPriority.Loaded);   // Loaded 까지 큐를 비운다
w.UpdateLayout();                                            // 그러고 나서 다시 재기

가운데 한 줄이 전부입니다. 디스패처 큐를 Loaded 우선순위까지 밀어내서 "레이아웃이 다 끝났다"를 보장한 뒤, 한 번 더 확정합니다. 이걸 빼면 아무 오류 없이 살짝 어긋난 스크린샷이 나옵니다 — 가장 알아채기 어려운 종류의 실패죠.

지금은 UI 를 고치면 명령 두 줄이면 됩니다. 한국어 넷, 영어 넷, 여덟 장이 다시 나옵니다.

인박스 — 이 스크린샷도 제가 찍은 게 아니라, 앱이 --screens 로 스스로 렌더한 것입니다

이 글에 붙은 저 스크린샷도 마찬가지입니다. 제가 찍은 게 아니라 앱이 찍은 겁니다.

타일 52종을, 반올림 하나 때문에

스토어에 앱을 올리려면 아이콘이 한 장으로 안 끝납니다. 타일·로고·스플래시가 크기별로 있고, 각각에 배율 변형(scale-100 · 125 · 150 · 200 · 400)이 붙습니다. 전부 세면 52장입니다.

이걸 손으로 만들 생각은 처음부터 없었습니다. --genassets 가 코드로 그려서 내보냅니다. 그런데 처음 MSIX 패키징을 돌렸을 때 APPX1619 로 검증이 터졌습니다.

범인은 정수 나눗셈이었습니다.

MSIX 는 각 배율 에셋의 크기를 반올림(원본 × 배율/100) 으로 검증합니다. 그런데 제 코드는 정수 나눗셈으로 계산하고 있었고, 정수 나눗셈은 소수점을 잘라 버립니다.

71 × 125% = 88.75 → 89 여야 하는데, 제 코드는 88 을 냈습니다.

1 픽셀. 그 1 픽셀 때문에 패키징이 통째로 거부됐습니다. 고친 건 Math.Round(..., MidpointRounding.AwayFromZero) 한 줄이고요.

그리고 여기가 이 방식의 진짜 값이 나온 지점입니다. 에셋이 코드니까, 한 줄 고치고 --genassets 를 다시 돌리면 52장이 전부 새로 나옵니다. 이미지 편집기로 만들어 뒀다면 저는 그날 52장을 손으로 다시 뽑고 있었을 겁니다. (스토어 업데이트가 거부됐던 그날 이야기에서 이 에셋들이 잠깐 등장하는데, 그때 제가 태연할 수 있었던 이유가 이겁니다.)

테스트가 없는 게 아니라, 다른 데 있었습니다

정리하면 실행 파일 하나가 네 갈래로 갈라집니다. --selftest 는 파이프라인을 검증하고, --screens 는 리스팅 스크린샷을, --genassets 는 타일 52종과 프로모 아트를, --genicon 은 아이콘을 만듭니다. 전부 앱 자신의 코드로요.

이 방식엔 공짜로 딸려 오는 성질이 하나 있습니다. 에셋과 앱이 절대 어긋나지 않습니다. 스크린샷은 실제 창을 렌더한 것이고, 타일은 앱 아이콘을 그리는 바로 그 코드가 그린 것이며, 셀프테스트가 뱉는 마크다운은 사용자가 내보내기를 눌렀을 때 나오는 바로 그 마크다운입니다. 릴리스 자료가 낡을 수가 없습니다 — 낡으려면 앱이 먼저 낡아야 하니까요.

그래서 저는 "이 프로젝트엔 테스트가 없다"는 말을 이제 이렇게 고쳐 씁니다. 테스트가 없는 게 아니라, 테스트가 다른 데 있었습니다. 별도 프로젝트가 아니라 실행 파일 안에, 플래그 뒤에.

돌아보면 이건 도구를 만드는 사람의 아주 기본적인 게으름이었습니다. 같은 일을 세 번 반복하는 순간, "이거 코드가 하면 되잖아"가 떠오르는 그 게으름.

다만 이번엔 조금 더 낯 뜨거운 구석이 있었습니다. 스크린샷 도구가 자기 스크린샷을 못 찍는다면, 그건 좀 부끄러운 일 아닙니까.

▶ Microsoft Store 에서 ShotLog 설치하기

ShotLog - 예외 처리의 중요성

레루루 — Wed, 15 Jul 2026 20:00:31 +0900

절대 죽지 않게 만들었더니, 조용히 지웠습니다

예외를 삼키는 코드가 데이터를 지우는 방식 — fail-soft 의 뒷면.

안전하려고 세운 규칙이 사실은 가장 위험한 코드였다는 걸 뒤늦게 아는 순간이 있습니다. 저는 그걸 catch 블록 하나에서 겪었습니다.

제 앱에는 규칙이 하나 있습니다. 핫키와 저장소 IO 에서는 절대 예외를 던지지 않는다. 프로젝트 문서 맨 아래 "함정" 항목에 제가 직접 적어 둔 문장이고, 나름 근거도 분명했습니다. 그래서 모든 Load() 와 Save() 를 try/catch 로 감쌌습니다. 앱은 무슨 일이 있어도 죽지 않았고, 저는 그걸 잘한 일이라고 생각했습니다.

그런데 그 규칙을 순진하게 지킨 코드가 사용자의 캡처 기록을 통째로, 아무 소리 없이 지울 수 있다는 걸 나중에 알았습니다. 예외를 삼키라는 원칙이, 어느새 아무것도 알리지 말라는 뜻으로 변질돼 있었던 겁니다.

핫키는 절대 죽으면 안 된다 — 그래서 세운 규칙

먼저 규칙이 왜 필요했는지부터.

제가 만든 ShotLog 는 트레이에 상주하는 캡처 도구입니다(어떤 앱인지는 따로 소개한 글에 있습니다). 창이 없으니 사용자는 앱이 살아 있는지 죽었는지 알 방법이 없습니다. 트레이 아이콘이 조용히 사라질 뿐이죠.

그런 앱에서 단축키 하나 눌렀다고 프로세스가 죽으면 그건 재앙입니다. 사용자는 Ctrl+Alt+S 를 눌렀을 뿐인데, 다음에 누를 땐 아무 일도 일어나지 않습니다. 왜냐고요? 앱이 없어졌으니까요. 그러니 캡처 핸들러는 무슨 일이 있어도 예외를 밖으로 내보내면 안 됩니다.

저장소 IO 도 마찬가지입니다. 설정 파일이 잠겨 있다고, 디스크가 꽉 찼다고 앱이 시작조차 못 하면 곤란합니다. 어떻게든 계속 굴러가는 게 낫다 — 이게 fail-soft 입니다.

여기까진 옳았습니다. 문제는 그다음이었습니다.

빈 리스트가 진실이 되는 순간

캡처 기록은 captures.json 한 파일에 들어 있습니다. 어떤 PNG 에 어떤 메모와 태그가 붙어 있는지를 잇는, 이 앱의 유일한 원장입니다.

Load() 는 이렇게 생겼습니다. 파일을 읽고, 파싱하고, 실패하면 삼킵니다. 삼킨 다음엔? 빈 리스트로 시작합니다. 던지지 않기로 했으니 달리 할 게 없거든요.

그리고 앱은 아주 건강하게 돌아갑니다. 사용자가 캡처를 하나 더 찍습니다. Save() 가 호출됩니다. 그 순간 메모리에 있는 빈 리스트가 파일에 그대로 덮어써집니다.

원장이 지워졌습니다. 에러도, 경고도, 빨간 글씨도 없이.

손상된 captures.json 을 순진하게 삼키면 빈 리스트가 되고, 다음 Save 가 이력을 영구히 덮어씁니다. 고친 뒤에는 원본을 .bak 으로 대피시킵니다

여기서 무서운 건 파일이 손상됐다는 사실이 아닙니다. JSON 이 반쯤 쓰이다 만 건 흔한 일이고, 그래서 복구도 가능합니다. 무서운 건 손상이 삭제로 승격되는 경로입니다. 되돌릴 수 있던 사고를, 제 코드가 되돌릴 수 없는 사고로 바꿔 놓고 있었습니다.

그리고 이건 첫 실행과 구별되지 않습니다. 파일이 없어서 빈 리스트인 것과, 파일이 깨져서 빈 리스트인 것 — 코드에서는 똑같이 new() 입니다. 앱은 사용자를 처음 보는 사람처럼 맞이합니다. 사실은 그 사람의 지난 몇 달을 방금 지웠으면서요.

던지지 말고, 옆으로 치워 둡니다

해법이 "예외를 던지자"가 아니라는 게 이 이야기의 핵심입니다.

던지면 어떻게 될까요. 앱이 시작하다 죽습니다. 사용자는 captures.json 이 뭔지도 모르는데 앱이 안 켜집니다. 규칙은 여전히 옳습니다 — Load() 는 절대 throw 하면 안 됩니다.

고쳐야 할 건 예외 처리가 아니라 catch 안에서 무엇을 하느냐였습니다. 지금은 이렇게 합니다.

먼저 대피시킵니다 — 파싱에 실패한 파일을 captures.corrupt-20260705-143052.bak 으로 복사해 둡니다. 시간이 박힌 이름이라 덮어쓸 일도 없습니다.
그다음 빈 리스트로 시작합니다 — 앱은 예전처럼 조용히 계속 굴러갑니다.
대피도 best-effort 입니다 — 백업을 뜨다 실패해도 삼킵니다. 원칙은 원칙이니까요.

바뀐 건 딱 한 줄짜리 동작입니다. 그런데 사고의 성격이 완전히 달라집니다. 데이터는 여전히 거기 있고, 손상된 JSON 은 사람 손으로 열어서 살릴 수 있습니다. 앱이 못 읽는 것과, 세상에서 사라지는 것은 다른 일입니다.

fail-soft 의 올바른 정의는 "조용히 성공한 척"이 아니라 "조용히 훼손하지 않기"였습니다.

언제 침묵하고, 언제 말을 걸까

같은 시기에 하나 더 고쳤습니다. 이번엔 반대 방향입니다.

캡처가 실패했을 때, 제 코드는 전부 침묵하고 있었습니다. 전부 catch { } 였거든요. 그런데 곰곰이 보니 캡처 실패는 두 종류였습니다.

핫키로 찍는 즉시 캡처·클립보드 캡처 — 사용자는 지금 다른 일에 몰입해 있습니다. 알림은 방해입니다. 여기선 침묵이 맞습니다. 코드 주석에도 그렇게 적었습니다 — *"a hotkey never nags"*.
메모·영역·활성 창 캡처 — 사용자가 의도적으로 시작한 동작입니다. 창이 뜨기를 기다리고 있습니다. 여기서 조용히 실패하면, 사용자는 자기가 뭘 잘못 눌렀나 한참을 헤맵니다.

그래서 뒤쪽 셋에만 트레이 알림을 붙였습니다. 삼키되, 사용자가 기다리고 있을 때는 말을 겁니다. 예외를 삼킬지 말지가 아니라, 누가 지금 답을 기다리고 있는가로 갈랐습니다.

재미있는 건, 이 글을 쓰려고 코드를 다시 읽다가 똑같은 병을 하나 더 찾았다는 겁니다. 단축키를 등록하는 코드가 RegisterHotKey 의 반환값을 아예 보지 않고 있었습니다. 다른 앱이 이미 그 조합을 쓰고 있으면 Windows 는 예외도 콜백도 없이 그냥 false 를 돌려줍니다. 사용자 눈에는? 단축키를 눌렀는데 아무 일도 안 일어납니다. 앱이 자기를 무시하는 것처럼 보이죠. 지금은 어떤 단축키가 물렸는지 이름을 대며 알려 줍니다.

세 군데 다 같은 실수였습니다. 실패를 처리하는 것과, 실패를 없었던 일로 만드는 것을 헷갈린 것.

돌아보면 catch { } 라는 두 글자는 참 유혹적입니다. 저기에 뭘 적을지 고민하는 대신 그냥 비워 두면, 앱은 절대 죽지 않고 로그도 깨끗하고 사용자도 아무 말이 없습니다.

다만 그 조용함이, 잘 돌아가고 있다는 뜻은 아니었습니다. 죽지 않는 것과 괜찮은 것은 다릅니다.

ShotLog - 스토어 배포 중 발생한 문제

레루루 — Tue, 14 Jul 2026 20:11:55 +0900

겉은 1.2.0.0, 속은 1.1.0.0

첫 게시는 한 번이지만, 업데이트는 계속됩니다 — 두 번째 제출에서 만난 함정들.

세 파일의 버전을 전부 1.2.0.0 으로 맞췄습니다. ShotLog.csproj, app.manifest, Package.appxmanifest. 이건 제가 제 문서에 손수 적어 둔 규칙이라, 체크리스트를 보면서 한 줄씩 확인까지 했습니다. 빌드하고, 업로드하고, 커피를 한 잔 내리고 돌아왔더니 화면에 빨간 줄이 하나 떠 있더군요.

"패키지 전체 이름이 이미 존재합니다 — SlnU.ShotLog_1.1.0.0_X64_…"

1.1 이라니. 방금 세 군데를 다 고쳤는데요. 파일 이름조차 1.2.0.0 이라고 적혀 있는 그 패키지를, 스토어는 1.1 이라고 읽고 있었습니다.

앱을 스토어에 처음 올리던 날의 이야기는 지난번에 다른 앱으로 한 번 했습니다 — 미서명 실행 파일 앞에 서던 파란 경고창, 그걸 지우려고 Microsoft 에게 서명을 맡긴 이야기요. 오늘은 그 뒤의 이야기입니다. 첫 게시는 인생에 한 번이지만, 업데이트는 계속 돌아옵니다. 그리고 업데이트 레인에는, 첫 게시 때는 한 번도 만난 적 없는 함정들이 기다리고 있었습니다.

(ShotLog 가 어떤 앱인지는 따로 소개한 글이 있으니 여기선 접어 두겠습니다. 화면을 찍고 그 자리에 메모를 남기는, 트레이에 사는 작은 도구입니다.)

세 곳을 고쳤는데, 네 번째가 있었습니다

문제는 그 버전이 한 군데 더 있다는 것이었습니다. 제가 모르던 곳에.

MSIX 번들은 러시아 인형 같은 구조입니다. .msixupload 안에 .msixbundle 이 들어 있고, 그 번들 안에 개별 패키지가 다시 들어 있습니다. 그리고 겉껍질에도, 안의 각 패키지에도 버전이 따로 적혀 있습니다. 제가 고친 버전은 겉껍질까지는 잘 도달했습니다. 파일명도 1.2.0.0, 번들 Identity 도 1.2.0.0. 그런데 안쪽 개별 패키지의 <Package Version> 은 — 옛날 값 그대로였습니다.

범인은 증분 빌드 였습니다. MSBuild 는 "안 바뀐 건 다시 안 만든다"는 아주 합리적인 원칙으로 움직입니다. 그런데 그 판단이 패키지 Identity 에까지 미치면, 매니페스트의 버전을 바꿔도 직전에 구워 둔 개별 패키지를 그대로 재사용해 버립니다. 겉은 새로 포장하고, 속은 창고에 있던 걸 그대로 담는 셈입니다.

세 매니페스트를 1.2.0.0 으로 고쳐도, 증분 빌드는 번들 겉껍질만 새 버전으로 쓰고 안쪽 개별 패키지는 캐시된 1.1.0.0 을 재사용합니다

Partner Center 는 겉이 아니라 속을 봅니다. 그래서 이미 게시된 1.1.0.0 과 같은 패키지 전체 이름이 올라왔다고 판단하고 거부한 겁니다. 거절 사유는 정확했습니다. 다만 제가 그 문장을 읽을 준비가 안 돼 있었을 뿐이죠.

해법은 허무합니다. 클린 리빌드. src\ShotLog\{obj,bin} 과 src\ShotLog.Package\{obj,bin,AppPackages} 를 지우거나, msbuild … /t:Rebuild 로 다시 굽습니다. 그게 전부였습니다. 그래서 저는 이 한 줄을 출시 문서 §8 에 ⚠️ 를 달아 박아 뒀습니다 — "버전 올릴 땐 반드시 클린 리빌드."

패키지를 열어 봐야 압니다

여기서 진짜 교훈은 "클린 리빌드를 하세요"가 아닙니다. 그건 대증요법이고요.

진짜 교훈은 이겁니다. 빌드 산출물이 조용히 거짓말을 할 수 있다면, 나에겐 그걸 열어 볼 방법이 있어야 한다. 파일명이 1.2.0.0 이라는 건 아무 증거도 아니었습니다. 파일명은 그냥 파일명입니다.

그래서 이제는 업로드 전에 패키지를 뜯어봅니다. 어렵지 않습니다 — MSIX 는 그냥 zip 이니까요.

.msixupload 의 압축을 풉니다 → 안에서 .msixbundle 이 나옵니다.
그 .msixbundle 을 다시 풉니다 → AppxMetadata/AppxBundleManifest.xml 이 있습니다.
그 XML 을 열어 모든 <Package Version> 이 목표 버전인지 확인합니다. 하나라도 옛 값이면 거기서 멈춥니다.

"모든" 이라는 말이 핵심입니다. 하나만 보고 넘어갔다면 저는 겉껍질만 확인하고 안심했을 겁니다. 정확히 그래서 처음에 당한 거고요.

익숙한 종류의 버그이긴 합니다 — 캐시가 틀린 답을 자신 있게 내놓는 것. 다만 그게 제 코드가 아니라 빌드 시스템 안에서 일어나니, 소스를 아무리 들여다봐도 답이 없었던 겁니다. 문제가 소스에 없을 때는, 산출물을 열어 보는 수밖에요.

서명해야 검사할 수 있는데, 서명하면 안 되는 패키지

제출 전에 한 번 돌리는 검사가 있습니다. WACK(Windows App Certification Kit) — 스토어 인증에서 볼 항목들을 내 PC 에서 미리 돌려 보는 도구입니다. 그런데 이걸 돌리려는 순간, 앞뒤가 안 맞는 요구 두 개가 정면으로 부딪힙니다.

WACK 는 앱을 실제로 설치해서 검사합니다. 그러니 관리자 권한이 필요하고, 무엇보다 설치 가능한 = 서명되고 신뢰된 패키지를 요구합니다.
스토어 업로드본은 반드시 미서명이어야 합니다. Microsoft 가 대신 서명해 줄 거니까요. 그게 애초에 스토어로 옮긴 이유이기도 하고요.

서명해야 검사할 수 있는데, 서명하면 안 되는 패키지. 매듭을 푸는 길은 하나였습니다 — 검사용과 배포용을 분리하는 것.

scripts\run-wack.ps1 이 그 일을 합니다. 일회용 자체서명 인증서를 만들어 테스트 번들에만 서명하고, 신뢰 저장소에 잠깐 넣어 설치를 허용하고, appcert.exe 를 돌린 뒤, finally 블록에서 임시 신뢰와 인증서를 전부 걷어냅니다. 배포용 .msixupload 는 처음부터 끝까지 손대지 않습니다. 검사 하나 하자고 제 PC 의 신뢰 저장소에 쓰레기를 남길 순 없으니까요.

여기 함정이 하나 숨어 있습니다. 인증서의 주체(Subject)가 패키지 Publisher 와 글자 하나까지 같아야 합니다 — ShotLog 라면 CN=1398342C-A2D7-4B4A-BFE2-34D8CCFD7FBA. 안 맞으면 설치 단계에서 그냥 거부됩니다.

결과는 OVERALL_RESULT = PASS. 다만 선택 항목 하나가 FAIL 로 떴는데, 이게 재미있습니다. "차단된 실행 파일" — 앱 안에 cmd, reg, CreateProcess, ShellExecute 같은 호출이 들어 있다는 겁니다. 저는 그런 코드를 쓴 적이 없습니다.

범인은 self-contained .NET 런타임 이었습니다. 런타임을 통째로 안고 배포하다 보니 그 안의 DLL 들이 저 문자열들을 상수로 품고 있고, 스캐너가 문자열 검색으로 잡아낸 겁니다. 알려진 오탐이고 OPTIONAL 이라 제출을 막지는 않습니다. 사용자에게 "실행하려면 런타임부터 까세요"라고 하지 않는 대가로, 스캐너에게 한 번 의심받는 셈이죠. 남는 장사라고 봤습니다.

내가 배포한 것의 상태를, 내가 모르고 있었습니다

기술적인 함정은 여기까지입니다. 그런데 이날 제가 저지른 가장 큰 실수는, 사실 빌드 시스템과 아무 상관이 없었습니다.

릴리스 노트를 쓰면서 저는 이렇게 생각했습니다. *"1.1.0.0 은 스토어에 안 올렸으니까, 이번 업데이트가 1.0.0.0 이후 첫 업데이트네. 그럼 1.1 때 개선한 것들도 What's new 에 다 넣어야겠다."* 그래서 인박스 개편도, 렌더링 미리보기도, 주석 에디터도 전부 이번 버전의 변경사항인 것처럼 적어 넣었습니다.

1.1.0.0 은 이미 게시돼 있었습니다.

기록을 다시 확인하고서야 알았습니다. 사용자가 이미 몇 주 전에 받아서 쓰고 있던 기능들을, "이번에 새로 나왔습니다" 하고 또 소개할 뻔한 겁니다. 급히 되돌렸습니다. What's new 는 실제로 바뀐 것만 안내하고, v1.1.0 항목은 "이전 버전" 각주로 내렸습니다. 한국어와 영어, 양쪽 다요.

이게 앞의 세 함정보다 뼈아팠습니다. 버전 캐시는 빌드 시스템이 틀린 거지만, 이건 제가 틀린 겁니다.

혼자 만들면 개발자이면서 동시에 릴리스 매니저입니다. 코드의 상태는 git log 가 알려 주지만, "내가 세상에 무엇을 내보냈는가"는 아무도 알려 주지 않습니다. 그건 제 저장소 밖, Partner Center 라는 다른 세계에 있는 사실이니까요. 저는 그걸 제 기억에 맡기고 있었고, 기억은 3주를 못 버텼습니다. 그래서 지금은 출시 문서 맨 위에 게시 이력을 적습니다. 어떤 버전이 언제 인증을 통과해 게시됐는지 — 커밋 메시지가 아니라, 다음번의 제가 가장 먼저 열어 볼 자리에.

내가 만든 것과, 내가 내보낸 것

돌아보면 이날 배운 세 가지는 한 문장으로 묶입니다. 세 매니페스트를 고쳤다고 패키지가 그 버전인 건 아니고, 파일명이 그렇다고 속까지 그런 건 아니고, 기능을 만들었다고 사용자가 그걸 받은 것도 아닙니다. 그 사이엔 매번 빌드 캐시가, 번들 껍질이, 제 흐릿한 기억이 끼어듭니다. 그러니 확인하는 수밖에요 — 압축을 풀어서, 문서를 열어서, 눈으로.

파란 경고창은 한 번 지우면 끝입니다. 하지만 내가 뭘 올렸는지 아는 일은, 매번 새로 해야 하더군요.

▶ Microsoft Store 에서 ShotLog 설치하기

ShotLog - 소개

레루루 — Sun, 12 Jul 2026 19:32:29 +0900

캡처와 기록 사이의 틈

화면을 찍는 순간, 그 생각도 같이 붙잡아 두는 도구를 만들었습니다.

스크린샷 폴더를 열어 봅니다. Screenshot (47).png, Screenshot (48).png, 스크린샷 2026-06-12 143052.png… 스무 장, 서른 장. 분명 하나하나 이유가 있어서 찍었을 겁니다. 그런데 지금 그 이유를 한 장도 기억하지 못하겠더군요.

이상한 일입니다. 화면은 픽셀 하나 안 틀리고 그대로 남아 있는데, 왜 찍었는지만 사라졌습니다. 이 오류가 재현된다는 걸 알리려던 건지, 이 UI 가 마음에 들어서였는지, 이 문단을 나중에 인용하려던 건지. 남은 건 증거뿐이고, 증언은 없습니다.

생각해 보면 당연했습니다. 캡처는 0.1초 만에 끝나는데, 그걸 기록으로 만드는 일 — 이름 붙이고, 폴더 나누고, 왜 찍었는지 적어 두는 일 — 은 몇 분이 걸립니다. 그래서 아무도 안 합니다. 저도 안 했고요. 찍는 건 공짜지만 남기는 건 비싸다는 이 비대칭이, 제 폴더를 이유 없는 이미지 무덤으로 만들고 있었습니다. 마땅한 게 없어서 직접 만들었고, 그게 ShotLog 입니다.

ShotLog 는 트레이에 상주하는 Windows 캡처·메모 도구입니다. WPF · .NET 8, 그리고 네트워크 호출이 단 하나도 없는 완전 로컬 앱. 하는 일은 한 문장으로 줄어듭니다 — 단축키로 화면을 잡고, 그 자리에서 생각을 적고, 나중에 읽을 수 있는 문서로 꺼냅니다.

찍는 순간이, 맥락이 가장 선명한 순간입니다

이 앱의 전제는 하나입니다. "왜 찍었는지"를 가장 잘 아는 건 찍은 직후의 나라는 것.

그 순간 저는 이미 문제를 보고 있고, 이미 그 이유를 머릿속에 갖고 있습니다. 10초 뒤면 다음 창으로 넘어가 버릴 그것을요. 하루가 지나면 복원 비용은 수십 배가 되고, 일주일이 지나면 복원이 아예 불가능해집니다. 캡처와 기록 사이의 그 짧은 틈 — 도구가 개입할 수 있는 자리는 거기뿐이었습니다.

그래서 ShotLog 는 캡처가 끝나면 곧바로 메모 카드를 띄웁니다. 파일 탐색기를 열지도, 이름을 물어보지도 않습니다. 그냥 한 줄 쓸 자리를 눈앞에 갖다 놓습니다. 안 쓰고 닫아도 그만이지만, 그 자리에 있느냐 없느냐가 결국 전부더군요.

그 자리에서 한 줄 — 빠른 메모 카드

빠른 메모 — 캡처 직후 떠오르는 카드에 메모와 태그를 그 자리에서 적습니다

단축키를 누르면 화면이 잡히고, 그 위로 작은 카드가 뜹니다. 메모 한 줄, 태그 몇 개, 그리고 프리셋 칩. 엔터를 치면 사라집니다. 5초면 끝나는 일입니다.

여기서 제가 특히 아끼는 게 프리셋 입니다. 프리셋은 저장 폴더 · 강조 색상 · 기본 태그를 한 덩어리로 묶어 둔 것입니다. 버그 프리셋을 고르면 버그 폴더로 가고 bug 태그가 자동으로 붙고, 학습 프리셋을 고르면 학습 폴더로 갑니다. 캡처할 때 칩 하나만 누르면 분류가 이미 끝나 있습니다. 나중에 정리하겠다는 약속은 지켜진 적이 없으니, 아예 나중을 만들지 않기로 한 겁니다.

저장 전에 화면 위에 그려 넣을 수도 있습니다. 펜, 형광펜, 화살표, 사각형, 텍스트. "여기요, 이 버튼이요"를 말로 설명하는 것보다 빨간 동그라미 하나가 빠를 때가 있으니까요. (이미 저장한 캡처도 인박스에서 다시 열어 고칠 수 있습니다.)

나중의 나를 위한 받은 편지함

인박스 — 최근 캡처를 썸네일로 모아 보고, 메모와 태그를 그 자리에서 고칩니다

찍어 둔 것들은 인박스 로 흘러갑니다. 메일함처럼요.

이름을 이렇게 지은 데엔 이유가 있습니다. 스크린샷 폴더는 창고입니다. 한번 들어가면 다시 안 열어 봅니다. 반면 받은 편지함은 처리하려고 여는 곳입니다. 열어서, 보고, 지우거나 답하거나 보관합니다. 저는 캡처가 창고가 아니라 편지함에 쌓이길 바랐습니다.

그래서 인박스에서 할 수 있는 일은 전부 "처리"에 관한 것들입니다.

인라인 편집 — 썸네일 옆에서 메모와 태그를 바로 고칩니다. 캡처할 땐 급해서 못 쓴 말을, 여유 있을 때 채워 넣습니다.
검색과 필터 — 메모·태그로 찾고, 프리셋으로 좁힙니다. "그때 그 오류 화면"을 이름이 아니라 말로 찾습니다.
정리 — 다중 선택해서 지우거나, 다른 프리셋으로 옮기거나, 클립보드로 복사하거나, 탐색기에서 엽니다.

그리고 원하면 PNG 옆에 같은 이름의 .md 사이드카 를 함께 남겨 둘 수 있습니다. 앱을 지워도, 탐색기에서 파일만 봐도 메모가 거기 있습니다. 제가 만든 앱에 제 기록을 인질로 잡아 두고 싶지 않았습니다.

쌓인 캡처를, 읽을 수 있는 문서로

글쓰기 내보내기 — 태그와 기간으로 고르고, 렌더링 미리보기를 보며 Markdown 으로 내보냅니다

여기가 이 앱이 진짜로 하고 싶었던 일입니다.

캡처 스무 장에 메모가 붙어 있으면, 그건 이미 글의 재료입니다. 버그 리포트든, 사용법 문서든, 학습 노트든, 회의 기록이든. 필요한 건 그걸 사람이 읽는 물건으로 조립하는 마지막 한 걸음뿐입니다.

글쓰기 내보내기 는 그 한 걸음입니다. 태그 · 프리셋 · 기간으로 걸러 담을 것을 고르면, 시간순으로 엮인 Markdown 문서 한 벌과 그 옆에 images/ 폴더가 나옵니다. 옆 창에는 렌더링된 미리보기가 실시간으로 뜨니, 나오기 전에 어떻게 생겼는지 다 보입니다. 이미지마다 시각을 섹션 제목 으로 올릴지, 캡션 으로 밑에 깔지, 아예 감출지 도 고를 수 있고요. 급할 땐 마크다운만 복사하거나, 파일 하나로 완결된 HTML 로 뽑아도 됩니다.

내보내는 Markdown 은 일부러 아무 데도 소속되지 않게 썼습니다. Obsidian 의 위키링크도, 특정 앱의 확장 문법도 쓰지 않습니다. 이미지는 그냥 ![설명](images/이름.png) 상대경로이고, 폴더째로 옮겨도 안 깨집니다. 그래서 GitHub 에 올리면 GitHub 에서 그려지고, Obsidian 에 넣으면 Obsidian 에서 열리고, VS Code 로 열면 VS Code 에서 보입니다.

이게 제 나름의 예의입니다. 언제든 떠날 수 있어야, 머물 마음이 생깁니다.

필요한 만큼만 꺼내 쓰는 캡처

설정 — 프리셋과 단축키, 내보내기 기본값, 그리고 한국어 · English 전환

캡처라고 다 같은 캡처가 아니더군요. 어떤 건 생각할 틈도 없이 지나가고, 어떤 건 붙잡아 두고 한참 봐야 합니다. 그래서 꺼내는 길을 다섯 개로 냈고, 전부 전역 단축키 로 어떤 앱 위에서든 동작합니다.

즉시 캡처 — 커서가 있는 모니터를 찍어 활성 프리셋에 바로 저장합니다. 창도 안 뜨고 포커스도 안 뺏습니다. 흐름을 끊지 않고 증거만 남길 때.
캡처 + 메모 — 찍고 곧바로 메모 카드. 기본이자 이 앱의 본론입니다.
영역 선택 — 드래그로 잘라냅니다. 끄는 동안 크기가 픽셀로 표시됩니다.
활성 창 — 지금 보고 있는 창만 깔끔하게.
클립보드로 — 파일로 남기지 않고 클립보드에만. 채팅창에 바로 붙여 넣고 끝낼 일이면 굳이 기록할 필요가 없으니까요.

단축키는 전부 설정에서 바꿉니다. 그리고 한국어 · English — 설정에서 고르면 재시작 없이 그 자리에서 UI 가 바뀝니다.

무엇보다, 이 모든 게 내 PC 안에서만 일어납니다. 스크린샷과 메모는 내 폴더와 %APPDATA%\ShotLog 안의 JSON 몇 개에 담길 뿐, 업로드도 분석도 추적도 없습니다. 애초에 네트워크를 쓰는 코드가 앱 안에 존재하지 않습니다. 화면을 찍는 앱일수록 그게 중요하다고 생각했습니다 — 보낼 곳이 없으면, 샐 것도 없습니다.

설치하기

ShotLog 는 Microsoft Store 에서 게시자 SlnU 로 설치할 수 있습니다. 설치와 업데이트가 자동으로 관리되고, 관리자 권한도 필요 없습니다. Windows 10 (1809) 이상.

▶ Microsoft Store 에서 ShotLog 설치하기

이제 제 폴더엔 Screenshot (47).png 가 없습니다. 대신 그날 제가 무슨 생각을 하고 있었는지가, 화면 옆에 한 줄씩 남아 있습니다.

Pulsar - 켠 김에 타이머

레루루 — Sat, 11 Jul 2026 23:20:46 +0900

상주하니까, 타이머도 됩니다

항상 트레이에 떠 있는 앱의 두 번째 정체성 — Pulsar 의 타이머 이야기입니다.

“25분만 집중하자” 하고 타이머를 켜려는데, 그 타이머가 어디 있죠? 폰은 책상 저쪽에 엎어져 있고, 브라우저에 열어 둔 뽀모도로 탭은 어느새 스무 개째 탭 뒤로 밀려나 있고, 주방 타이머는… 주방에 있습니다. 정작 하루 종일 제 눈앞에 켜져 있는 건 이 PC 인데, 그 PC 에는 마땅한 타이머가 없더군요. 게다가 폰 타이머를 끄러 손을 뻗는 순간 그 폰이 저를 유튜브로 데려가는 것도, 솔직히 한두 번이 아니었습니다.

지난 글에서 즐겨찾기를 네 가지 방식으로 꺼내는 런처 Pulsar 를 소개했습니다. 그런데 이 앱을 만들다 문득 이런 생각이 들었습니다. “얘는 어차피 항상 켜져 있잖아?” 트레이에 상주하며 단축키만 기다리는 앱이라면, 타이머 하나쯤은 공짜로 얹을 수 있겠다고요. 그렇게 Pulsar 는 런처이면서 타이머가 됐습니다.

다만 "항상 켜져 있는 타이머"가 쓸모 있으려면, 넘어야 할 문턱이 하나 있었습니다. 믿을 수 있어야 한다는 것.

끝나는 '시각’을 붙잡아 둡니다 — 잠들어도, 시계를 바꿔도

평범한 카운트다운은 초를 하나씩 세어 내려갑니다. 문제는 노트북이 잠들거나 앱이 잠깐 멈칫하면 그 세던 숫자가 어긋난다는 것. 옆에서 숫자를 세어 주던 사람이 잠깐 졸면 카운트가 틀어지는 것과 똑같습니다.

그래서 Pulsar 는 초를 세지 않습니다. 대신 **“이 타이머는 2시 47분에 끝난다”**는, 끝나는 시각을 적어 둡니다. 그리고 그저 시계를 힐끗 봅니다 — 남은 시간은 언제나 ‘끝나는 시각 − 지금’. 노트북이 한 시간을 자다 깨어나도, 깨어나는 그 순간 시계를 보고 정확한 남은 시간을 다시 셈합니다. 어긋날 틈이 없습니다.

시스템 시계를 손으로 바꾸거나 절전에서 돌아올 때는 알람을 조용히 다시 무장합니다. 엉뚱한 순간에 울리거나, 울려야 할 때 침묵하는 일이 없도록요. 덤으로, 그래서 앱을 껐다 켜도 타이머는 살아 있습니다. 끝나는 시각을 알고 있으니 다시 열면 그때까지 얼마 남았는지 스스로 되찾거든요. 초를 세는 대신 시각을 붙잡아 둔 덕분입니다.

라면과 빨래와 회의를 한꺼번에 — 세 가지 얼굴

타이머 하나로는 삶이 안 굴러갑니다. 라면 3분, 빨래 40분, 회의까지 12분 — 이것들은 동시에 흘러야죠. 그래서 Pulsar 는 여러 타이머를 한꺼번에 돌리고, 각각을 색과 이름으로 구분합니다.

그리고 타이머는 세 가지 얼굴을 가집니다.

카운트다운 — “3분 뒤” 같은, 그냥 지정한 시간.
뽀모도로 — 집중 25분 → 휴식 5분 → 다시 집중… 을 알아서 넘어갑니다. 네 번 돌면 긴 휴식 15분. (다 기본값이고, 전부 바꿀 수 있습니다.)
알람 — 벽시계 시각에 맞춘 알림. “매일 09:00”, “월–금 09:00” 처럼 요일 반복도 됩니다.

자주 쓰는 건 프리셋으로 저장해 한 번에 시작합니다 — 집중 25:00, 휴식 5:00, 그리고 제가 특히 아끼는 라면 3:00 까지. 네, 진짜 라면 타이머 맞습니다.

“25분” 이라고 치면 됩니다 — 말로 거는 타이머

1편에서 소개한 명령 팔레트 기억하시나요. 여기에 타이머를 얹었습니다. Ctrl+Alt+Space 를 누르고 그냥 “25분” 이라고 치면 25분 카운트다운이 걸립니다. “뽀모도로” 라고 치면 뽀모도로가 시작되고, “알람 7:00” 이면 7시 알람이 추가됩니다. 프리셋 이름을 치면 그 프리셋이 후보로 뜨고요.

타이머를 걸겠다고 마우스로 버튼을 찾아 헤맬 필요가 없습니다. 검색하듯 말하면 됩니다.

거슬리지 않게, 딱 필요한 만큼만 — 조용한 타이머

타이머 앱의 흔한 실수는 존재감이 너무 크다는 것입니다. 트레이 아이콘에 숫자를 박고, 작업표시줄에 진행 막대를 깔고, 큼직한 토스트를 연신 띄우고… 저는 일부러 반대로 갔습니다.

트레이 아이콘에는 남은 시간 숫자를 넣지 않았습니다. 아이콘은 그저 소환 버튼입니다.
작업표시줄 진행 막대도 쓰지 않습니다.
타이머는 지금 쓰는 모드에 자연스럽게 얹힙니다 — 고정 위젯이면 목록으로, 커서 모드면 커서를 따라다니는 작은 알약으로(클릭은 그대로 밑으로 통과합니다), 독이면 바 끝의 칩으로.
다 되면 시끄러운 시스템 토스트 대신 앱 안의 작은 플라이아웃으로 알립니다.

필요할 땐 곁눈에 걸리고, 아닐 땐 없는 듯이. 하루 종일 떠 있는 앱이 지켜야 할 예의라고 생각했습니다.

설치하기

Pulsar 는 Microsoft Store 에서 PulsarDock(게시자 SlnU)으로 설치할 수 있습니다. 설치와 업데이트가 자동으로 관리되고, 별도 관리자 권한도 필요 없습니다.

▶ Microsoft Store 에서 PulsarDock 설치하기

돌아보면 타이머는 따로 큰맘 먹고 만든 기능이 아니라, 항상 켜져 있는 앱이 자연스럽게 갖게 된 두 번째 정체성이었습니다. 라면 물을 올리고 이 글을 닫는 지금 이 순간에도, 3분짜리 하나가 어딘가에서 조용히 돌고 있습니다.

Pulsar - 소개

레루루 — Fri, 10 Jul 2026 21:20:34 +0900

취향을 못 골라서, 네 개를 다 만들었습니다

하나의 데이터, 네 개의 성격 — 제가 만든 데스크톱 런처 Pulsar 이야기입니다.

즐겨찾기, 어디에 두고 사세요? 누구는 바탕화면 구석에 아이콘 바를 띄워 두고, 누구는 단축키를 눌러 목록을 불러내고, 누구는 그냥 검색창에 이름 몇 글자를 칩니다. 저도 런처를 하나 만들어 보려고 앉았는데, 정작 첫 줄부터 막히더군요. 기능이 아니라 “그래서 이걸 어떻게 꺼낼 건데?” 에서요.

주변에 물어봤더니 답이 다 달랐습니다. macOS 를 쓰던 친구는 화면 아래 독이 없으면 허전하다 하고, 어떤 분은 화면을 가리는 건 질색이라 커서 옆에 잠깐 떴다 사라지길 원하고, 키보드에서 손을 떼기 싫은 개발자는 "그냥 검색해서 엔터"면 된다 합니다. 취향은 하나로 안 모였습니다. 한참을 고르다가, 결국 안 골랐습니다. 네 개를 다 만들었거든요. 그게 Pulsar(스토어 이름 PulsarDock)입니다.

Pulsar 는 자주 쓰는 앱·파일·폴더·링크와 타이머를 하나로 묶어 두는, 트레이에 상주하는 Windows 데스크톱 런처입니다. WPF · .NET 8, 그리고 100% 로컬. 특별한 건, 같은 즐겨찾기를 네 가지 방식으로 꺼낼 수 있다는 점입니다.

하나로 못 골라서, 그래서 안 골랐습니다 — 하나의 데이터, 네 개의 화면

네 가지를 각각 따로 만들면, 그건 그냥 앱이 네 개입니다. 즐겨찾기를 네 군데에 등록하고, 하나 바꾸면 네 번 고치고… 생각만 해도 지치는 일이죠.

그래서 처음부터 원칙을 하나 세웠습니다. 데이터와 엔진은 하나, 갈아끼우는 건 화면뿐. 즐겨찾기 트리도, 타이머도 밑바닥에선 딱 한 벌만 존재합니다. 그 위에 "어떻게 보여 줄지"만 DisplayMode 하나로 바꿔 끼웁니다. 그러니 내 즐겨찾기를 한 번만 정리해 두면, 오늘은 독으로 꺼내 쓰다가 내일은 방사형으로 바꿔도 그대로 따라옵니다. 취향은 화면의 문제이지, 데이터의 문제가 아니니까요.

네 개의 성격을 하나씩 소개하겠습니다.

늘 거기 있는 대시보드 — 고정 위젯

항상 눈에 보여야 안심이 되는 분을 위한 모드입니다. 화면 한켠에 패널을 띄워 두면 즐겨찾기 계층과 지금 돌아가는 타이머가 늘 거기 있습니다. 투명도를 낮춰 배경에 은은하게 깔아 둘 수도, 항상 위로 고정할 수도, 그냥 손으로 끌어다 원하는 자리에 놓을 수도 있습니다. "위젯"이라는 말이 가장 잘 어울리는, 상주형 대시보드입니다.

커서 옆으로 불러내는 방사형 — 커서추적

반대로, 화면을 뭔가가 차지하고 있는 걸 못 견디는 분도 있습니다. 이 모드는 평소엔 아무것도 없다가 Ctrl+Space 한 번이면 커서 바로 그 자리에 동심원 메뉴가 확 펼쳐집니다. 그룹으로 들어가면 안쪽 링은 그대로 둔 채 바깥으로 링이 하나 더 돋는 식이라, 내가 어느 갈래를 타고 들어왔는지 시선을 잃지 않습니다. 가운데는 오직 닫기(✕) 하나뿐 — 원하는 걸 고르면 스르륵 사라집니다. 필요할 때만 나타나는 런처를 좋아한다면 이쪽입니다.

가장자리에 착 붙는 아이콘 바 — 독

macOS 의 독이 손에 익은 분이라면 이 모드가 집처럼 편할 겁니다. 화면 가장자리(아래·위·좌·우 어디든)에 아이콘 바가 착 붙고, 마우스가 다가오면 그 자리를 지키며 아이콘이 부드럽게 부풀어 오릅니다. 자동 숨김을 켜 두면 평소엔 살짝 숨어 있다가 가장자리로 커서를 가져갈 때만 슬며시 올라옵니다. 바 끝에는 지금 돌아가는 타이머가 칩으로 붙고요.

손이 키보드를 안 떠나는 사람에게 — 명령 팔레트

그리고 네 번째. 사실 이건 위 세 모드와 나란한 게 아니라 직교합니다. 어떤 표시 모드를 쓰고 있든, Ctrl+Alt+Space 를 누르면 화면 한가운데에 검색창이 뜹니다. 앱 이름 몇 글자를 치면 퍼지 검색으로 후보가 좁혀지고, 엔터 한 번에 실행. Spotlight 나 PowerToys Run 이 손에 익은 분에게, 마우스는 거들 뿐입니다. (여기 검색창은 타이머 명령도 알아듣는데, 그 얘기는 다음 편으로 아껴 두겠습니다.)

취향은 더 잘게 갈라집니다

꺼내는 방식만 취향인 건 아니더군요. 그래서 결을 몇 겹 더 뒀습니다.

두 개의 다른 얼굴 — 라이트는 Windows 11 의 Fluent, 다크는 Linear 계열로, 두 테마를 아예 다른 인상으로 그렸습니다. 어디서 많이 본 "generic 한 AI 앱 느낌"을 피하고 싶었거든요. 시스템 강조색도 자연스럽게 따라옵니다.
아이콘도 내 마음대로 — 파일에서 자동 추출하거나, 이모지 하나( ), 직접 넣은 이미지, 아니면 글자 한두 개의 모노그램까지. 네 가지 중에 고릅니다.
한국어 · English — 설정에서 언어를 바꾸면 재시작 없이 그 자리에서 UI 가 바뀝니다.

설정 화면에 제가 붙여 둔 캡션이 하나 있는데, 이 글의 정신을 그대로 옮긴 말이라 좋아합니다 — “내 방식대로, 세밀하게.”

모드를 바꿔도, 내 즐겨찾기는 그대로

돌아보면, 네 개를 만든 것보다 하나로 묶은 것이 더 중요한 결정이었습니다. 모드는 설정에서 한 줄로 바꾸는 스위치일 뿐이라, 오늘의 기분과 지금 하는 일에 따라 성격만 갈아입힙니다. 그래도 밑에 깔린 내 즐겨찾기와 타이머는 흔들리지 않고요.

그리고 이 모든 건 내 PC 안에서만 일어납니다. 설정도 즐겨찾기도 타이머도 %APPDATA%\Pulsar 안 JSON 몇 개에 담길 뿐, 수집도 전송도 네트워크도 없습니다. 취향을 잔뜩 등록해 두는 앱일수록, 그 취향이 밖으로 안 나가는 게 중요하다고 생각했습니다.

설치하기

Pulsar 는 Microsoft Store 에서 PulsarDock(게시자 SlnU)으로 설치할 수 있습니다. 설치와 업데이트가 자동으로 관리되고, 별도 관리자 권한도 필요 없습니다.

▶ Microsoft Store 에서 PulsarDock 설치하기

취향을 하나로 못 고른 건, 돌아보니 약점이 아니라 이 앱의 생김새가 됐습니다. 당신의 취향은 넷 중 무엇인가요 — 아니면, 그날그날 다른가요?

파란 경고창을 지우기까지 — Atlas 를 Microsoft Store 에 올린 이야기

레루루 — Thu, 9 Jul 2026 20:00:33 +0900

내가 만든 앱을 세상에 내놓는 방법을 다시 정한 이야기 — GitHub 릴리스에서 Microsoft Store 로.

몇 달을 매달려 만든 앱을 처음으로 누군가에게 건넸을 때, 제가 마주한 건 고맙다는 말이 아니라 파란 전체 화면이었습니다. “Windows 의 PC 보호 — 게시자를 알 수 없는 앱입니다.” 굵은 경고 아래, 작게 접혀 있는 “실행” 버튼. 제 몇 달치 작업이 화면 위에서는 조심해야 할 무언가처럼 보였습니다. 더 뼈아팠던 건 — 이게 안전하다는 걸, 만든 저조차 증명할 방법이 없었다는 것입니다.

이건 Atlas 라는 앱을 처음 어떻게 세상에 내놓았고, 저 파란 경고창이 왜 그렇게 마음에 걸렸으며, 결국 그 경고가 뜨지 않는 선반 위로 앱을 통째로 옮긴 이야기입니다. (Atlas 가 어떤 앱인지는 따로 소개한 글이 있으니 여기선 접어 두고, 오늘은 "어떻게 건넸나"만 이야기하겠습니다.)

처음엔, 압축 파일 하나로 — GitHub 릴리스

첫 배포는 가장 손쉬운 길을 골랐습니다. 빌드해서 나온 Atlas.exe 와 화면 파일을 zip 하나로 묶어 GitHub 릴리스에 올리고, 사람들이 받아서 압축을 풀고 실행하는 방식. 서버도, 설치 절차도 없이 파일 하나만 건네면 되니 1인 개발자에게는 딱 맞아 보였습니다.

여기에 곧 살을 붙였습니다. Inno Setup 으로 설치 파일(Atlas-Setup-*.exe)을 만들어 더블클릭 한 번으로 깔리게 하고, 앱이 스스로 새 버전을 확인하도록 인앱 업데이터도 넣었습니다. 앱이 GitHub 의 최신 릴리스 태그를 제 버전과 비교해서, 새 게 있으면 알려 주고 받아 오는 식입니다. 관리자 권한도 필요 없는 사용자 폴더 설치라, 부담 없이 깔 수 있었죠.

돌아보면 그건 봉투에 담아 직접 건네는 방식이었습니다. 릴리스 페이지에 zip 과 설치 파일을 손수 올려 두고, “여기서 받으세요” 하고 내미는. 작동은 잘 했습니다. 딱 하나, 받는 사람 쪽 화면만 빼면요.

파란 경고창 앞에서 — “게시자를 알 수 없음”

문제의 정체는 단순했습니다. 제 설치 파일에는 코드 서명이 없었습니다. 서명 없는 실행 파일을 Windows 의 SmartScreen 이 만나면, “알 수 없는 게시자” 라며 파란 벽을 세웁니다. 악성이라서가 아니라, 누가 만들었는지 증명된 도장이 없어서입니다.

여기엔 사연이 있습니다. 코드 서명 인증서는 돈이 드는 데다, 설령 사서 도장을 찍어도 한동안은 경고가 그대로입니다. Windows 가 "이 게시자, 믿어도 되나"를 판단할 평판이 쌓이기 전까지는요. 그러니 개인 개발자에게 그 벽은, 돈을 낸다고 바로 사라지지도 않는 벽이었습니다.

정말 뼈아팠던 건 기술적인 부분이 아니라 그 감각이었습니다. 제가 만든 앱인데, 제가 만들었다는 걸 보여 줄 도장이 없다. 받는 사람 입장에선, 낯선 사람이 문 앞에 두고 간 정체불명의 봉투처럼 보이는 겁니다. 앱을 열기도 전에 “이거 괜찮은 거 맞아?” 부터 물어야 하는. 그 첫인상이 계속 마음에 걸렸습니다.

증명을 Microsoft 에 맡기다

길을 찾다가 도착한 곳이 Microsoft Store 였습니다. 핵심은 이 한 줄입니다 — 스토어에 올린 앱은 Microsoft 가 서명합니다. 제가 서명하지 않은 패키지를 올리면, 검수를 거쳐 Microsoft 의 인증서로 서명해서 배포해 줍니다. 그러니 사용자 화면엔 파란 경고창 대신, 앱 이름과 게시자 이름(SlnU)이 뜹니다.

말하자면 "이 게시자, 믿어도 되나"라는 질문의 답을 이제 Microsoft 가 대신 보증해 주는 셈입니다. 낯선 봉투가 아니라, 매장 선반 위에 정품으로 놓인 물건. 제가 몇 달을 매달려 만든 것이, 드디어 그렇게 보일 수 있게 됐습니다.

설치도, 업데이트도, 그냥 되게 — 게다가 대부분 Windows 앱이라

경고창만 사라진 게 아니었습니다. 스토어로 옮기니 그동안 제가 손으로 챙기던 것들을 Store 가 대신 해 줬습니다.

설치 — 스토어 페이지에서 클릭 한 번. 압축을 풀 필요도, 관리자 권한도 없습니다.
업데이트 — Store 가 알아서 최신으로 유지합니다. 그래서 스토어 빌드에서는 앱 안의 자체 업데이터를 아예 꺼 뒀습니다. 두 개가 서로 밀치지 않게.
런타임 — 화면을 그리는 WebView2 같은 의존성도 Store 가 함께 챙깁니다. "실행하려면 뭘 더 깔라"는 안내가 필요 없습니다.

그리고 제겐 결정적인 이유가 하나 더 있었습니다. 제가 만드는 건 대부분 Windows 데스크톱 앱입니다. 그렇다면 Windows 가 가장 잘 아는 통로, 사람들이 이미 앱을 찾으러 들르는 그 선반에 올려 두는 게 자연스러웠습니다. 애써 배포 페이지를 알리지 않아도 스토어 안에서 발견되는 것은 덤이고요.

옮기는 데엔 잔손이 많이 갔습니다

솔직히 말하면, 스토어로 다시 포장하는 일은 생각보다 잔손이 많았습니다. 포터블 zip 을 만들던 파이프라인과 달리 MSIX 라는 스토어용 패키지로 다시 싸야 했고, 그 과정에서 챙길 게 줄줄이 딸려 나왔습니다.

라이선스 정비 — 소스 라이선스를 정리하고, 스토어 바이너리에는 별도의 사용권(EULA)을 붙였습니다.
업데이터 분기 — 앱이 "나 지금 스토어 패키지로 돌고 있네"를 스스로 감지해, 그럴 때만 자체 업데이트 기능을 접도록 했습니다.
웃픈 함정 하나 — 첫 제출이 대뜸 "헤드리스 앱"이라며 거부됐습니다. 알고 보니 함께 넣은 명령줄 도구(atlas-cli·atlas-mcp)를 시작 메뉴에서 숨기려고 준 설정을, 스토어가 "이건 화면 없는 앱이잖아?"로 오해한 거였죠. 숨김을 포기했더니 통과됐습니다.

이런 잔손들. 그래도 한 번 길을 닦아 두니, 그다음부터는 publish.ps1 -Msix 한 줄이면 제출본이 나옵니다. 처음의 번거로움은, 매번 파란 경고창을 설명하지 않아도 되는 값으로 되돌아왔습니다.

한 선반에 나란히 — Atlas 만이 아니라서

사실 이 고민은 Atlas 하나로 끝나지 않았습니다. 제가 만드는 게 대부분 Windows 데스크톱 앱이다 보니, “저 파란 경고창을 어떻게 지우지” 는 새 앱을 낼 때마다 돌아오는 질문이었습니다. 그래서 만드는 것들을 아예 같은 선반에 나란히 올리기로 했습니다.

ShotLog — 화면을 찍고, 바로 그 자리에 메모를 남겨, 받은 편지함에 모아 두는 도구. 캡처와 기록 사이의 틈을 없앴습니다.
PulsarDock — 즐겨찾기와 타이머를 커서 주변·화면 가장자리·작은 위젯으로 불러내는 런처. 자주 여는 것들을 손 닿는 곳에 둡니다.
README.md — 이름 그대로, 가볍게 읽고 쓰는 마크다운 리더 겸 에디터.

셋 다 Atlas 와 같은 원칙 — 로컬 우선, 내 PC 안에서 — 으로 만들었고, 셋 다 같은 Microsoft Store 선반 위에 있습니다. 누구에게 건네도 파란 경고창부터 마주하지 않는, 그런 선반 위에요.

이제 제가 만든 걸 누군가에게 건넬 때, 첫 화면은 조심하라는 경고가 아닙니다. 앱 이름과, 그 아래 제 이름. 별것 아닌 것 같아도 — 만든 사람에겐 그 한 줄이, 파란 경고창과 정확히 반대편의 무게로 다가옵니다.

▶ Microsoft Store 에서 Atlas 설치하기

레루루의 경험 기록장

자바 시작하기 — JVM과 바이트 코드, 그리고 개발 환경

자바 시작하기 — JVM과 바이트 코드, 그리고 개발 환경

자바는 한 번 작성해서 어디서나 실행하려고 만들어졌다

이식성은 JVM이 대신 짊어진다

JDK는 JRE를 품고, JRE는 JVM을 품는다

소스에서 실행까지는 세 단계다

클래스 이름은 파일 이름과 대소문자까지 같아야 한다

세미콜론이 실행문의 끝을 정한다

이클립스는 워크스페이스에 작업 환경을 기억한다

프로젝트 생성과 컴파일

README.md - 소개

md 파일 여는 프로그램이 없어서 직접 만들었습니다 — 오프라인 마크다운 에디터 README.md

이름이 곧 사용법입니다 — 앱 이름은 README.md

왼쪽에 쓰면 오른쪽에 조판됩니다

인터넷을 아예 쓰지 않습니다 — 100% 오프라인

흩어진 문서를 한자리에 — 워크스페이스

다 쓴 문서는 파일 하나로 — HTML·PDF 내보내기

설치하기

[AI] 000 - 개요

AI 엔지니어링 공부, 밑바닥부터 시작합니다

쓰는 것과 아는 것 사이

그래서 밑바닥부터

기록을 남기는 방식

ShotLog - 자기 자신을 찍는 캡처 프로그램

앱에게 시켰습니다 — 자기 스크린샷을 직접 찍으라고

창을 열지 않고 회귀를 잡습니다 — --selftest

화면 밖 -10000 에 창을 띄웁니다 — --screens

타일 52종을, 반올림 하나 때문에

테스트가 없는 게 아니라, 다른 데 있었습니다

ShotLog - 예외 처리의 중요성

절대 죽지 않게 만들었더니, 조용히 지웠습니다

핫키는 절대 죽으면 안 된다 — 그래서 세운 규칙

빈 리스트가 진실이 되는 순간

던지지 말고, 옆으로 치워 둡니다

언제 침묵하고, 언제 말을 걸까

ShotLog - 스토어 배포 중 발생한 문제

겉은 1.2.0.0, 속은 1.1.0.0

세 곳을 고쳤는데, 네 번째가 있었습니다

패키지를 열어 봐야 압니다

서명해야 검사할 수 있는데, 서명하면 안 되는 패키지

내가 배포한 것의 상태를, 내가 모르고 있었습니다

내가 만든 것과, 내가 내보낸 것

ShotLog - 소개

캡처와 기록 사이의 틈

찍는 순간이, 맥락이 가장 선명한 순간입니다

그 자리에서 한 줄 — 빠른 메모 카드

나중의 나를 위한 받은 편지함

쌓인 캡처를, 읽을 수 있는 문서로

필요한 만큼만 꺼내 쓰는 캡처

설치하기

Pulsar - 켠 김에 타이머

상주하니까, 타이머도 됩니다

끝나는 '시각’을 붙잡아 둡니다 — 잠들어도, 시계를 바꿔도

라면과 빨래와 회의를 한꺼번에 — 세 가지 얼굴

“25분” 이라고 치면 됩니다 — 말로 거는 타이머

거슬리지 않게, 딱 필요한 만큼만 — 조용한 타이머

설치하기

Pulsar - 소개

취향을 못 골라서, 네 개를 다 만들었습니다

하나로 못 골라서, 그래서 안 골랐습니다 — 하나의 데이터, 네 개의 화면

늘 거기 있는 대시보드 — 고정 위젯

커서 옆으로 불러내는 방사형 — 커서추적

가장자리에 착 붙는 아이콘 바 — 독

손이 키보드를 안 떠나는 사람에게 — 명령 팔레트

취향은 더 잘게 갈라집니다

모드를 바꿔도, 내 즐겨찾기는 그대로

설치하기

파란 경고창을 지우기까지 — Atlas 를 Microsoft Store 에 올린 이야기

처음엔, 압축 파일 하나로 — GitHub 릴리스

파란 경고창 앞에서 — “게시자를 알 수 없음”

증명을 Microsoft 에 맡기다

설치도, 업데이트도, 그냥 되게 — 게다가 대부분 Windows 앱이라

옮기는 데엔 잔손이 많이 갔습니다

한 선반에 나란히 — Atlas 만이 아니라서

창을 열지 않고 회귀를 잡습니다 — `--selftest`

화면 밖 -10000 에 창을 띄웁니다 — `--screens`