레루루의 경험 기록장

앱에게 시켰습니다 — 자기 스크린샷을 직접 찍으라고테스트 프로젝트가 0개인 앱이 스스로를 검증하고 릴리스 에셋까지 만드는 법 — CLI 훅 네 개.UI 를 한 줄 고쳤습니다. 옵션 하나가 늘어서 창에 행이 하나 추가됐을 뿐입니다. 그런데 그 한 줄 때문에 스토어 리스팅 스크린샷을 여덟 장 다시 찍어야 했습니다. 한국어 넷, 영어 넷. 앱을 띄우고, 언어를 바꾸고, 그럴듯한 샘플 데이터를 손으로 채워 넣고, 창 크기를 맞추고, 캡처하고, 배경을 지우고, 1366×768 캔버스에 앉히고… 여덟 번.세 번째 릴리스에서 손이 멈췄습니다. 이건 제가 할 일이 아니라는 생각이 들더군요. 화면을 찍는 앱을 만들면서, 정작 그 앱의 스크린샷은 제가 손으로 찍고 있었습니다. 그래서 앱에게 시켰습니다.창을 열지 않고 회귀..

절대 죽지 않게 만들었더니, 조용히 지웠습니다예외를 삼키는 코드가 데이터를 지우는 방식 — fail-soft 의 뒷면.안전하려고 세운 규칙이 사실은 가장 위험한 코드였다는 걸 뒤늦게 아는 순간이 있습니다. 저는 그걸 catch 블록 하나에서 겪었습니다. 제 앱에는 규칙이 하나 있습니다. 핫키와 저장소 IO 에서는 절대 예외를 던지지 않는다. 프로젝트 문서 맨 아래 "함정" 항목에 제가 직접 적어 둔 문장이고, 나름 근거도 분명했습니다. 그래서 모든 Load() 와 Save() 를 try/catch 로 감쌌습니다. 앱은 무슨 일이 있어도 죽지 않았고, 저는 그걸 잘한 일이라고 생각했습니다. 그런데 그 규칙을 순진하게 지킨 코드가 사용자의 캡처 기록을 통째로, 아무 소리 없이 지울 수 있다는 걸 나중에 알았..

겉은 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 이라고 읽고 있었습니다. 앱을 스토어에 처..

캡처와 기록 사이의 틈화면을 찍는 순간, 그 생각도 같이 붙잡아 두는 도구를 만들었습니다.스크린샷 폴더를 열어 봅니다. Screenshot (47).png, Screenshot (48).png, 스크린샷 2026-06-12 143052.png… 스무 장, 서른 장. 분명 하나하나 이유가 있어서 찍었을 겁니다. 그런데 지금 그 이유를 한 장도 기억하지 못하겠더군요. 이상한 일입니다. 화면은 픽셀 하나 안 틀리고 그대로 남아 있는데, 왜 찍었는지만 사라졌습니다. 이 오류가 재현된다는 걸 알리려던 건지, 이 UI 가 마음에 들어서였는지, 이 문단을 나중에 인용하려던 건지. 남은 건 증거뿐이고, 증언은 없습니다. 생각해 보면 당연했습니다. 캡처는 0.1초 만에 끝나는데, 그걸 기록으로 만드는 일 — 이름 붙이고..