커리큘럼을 여섯 개 병행해도 인터리빙 효과는 적용되지 않습니다

3줄 요약 배우고 싶은 것을 여러 개 동시에 돌리면 섞어 배우는 효과를 얻는 것 같지만, 서로 다른 분야를 나란히 놓는 건 연구가 말하는 인터리빙이 아닙니다. 1년 뒤에 실제로 남는 양을 가르는 건 하루에 몇 개를 했느냐가 아니라 같은 내용을 며칠 뒤에 다시 봤느냐입니다. 교실 연구에서 이 차이가 표준편차 절반을 넘었습니다. 그러니 커리큘럼을 늘리기 전에 복습이 들어갈 날짜를 먼저 잡아 두시면 됩니다. 첫 복습은 목표 보유 기간의 15~20% 지점이 출발점입니다. 04시 03분, 05시 09분, 06시 08분, 06시 31분, 08시 13분, 그리고 밤 10시 39분. 9월 1일 이후의 평일 하루를 시간 순으로 세워 보면 이렇게 여섯 줄이 나옵니다. QA 역량 강화, 영어 교재 준비, 옵시디언 60일 학습, 매일 앱 만들기, 컨텍스트 엔지니어링과 RAG 데일리 레슨, 그리고 영어 세션 수행 체크입니다. 전부 제가 지난 몇 주 동안 하나씩 만들어 예약해 둔 것이고, 시작일은 전부 9월 1일 월요일로 맞춰 놓았습니다. 8월 말까지 준비할 시간을 두고 싶었고, 월요일이 깔끔해 보였기 때문입니다. 목록을 세로로 늘어놓고 나서야 눈에 걸린 건 슬롯의 개수가 아니었습니다. 여섯 줄 중에서 "지난주에 배운 것을 다시 본다"에 해당하는 줄이 하나뿐이라는 점이었습니다. 영어에만 일요일 주간 리뷰가 붙어 있었고, 나머지 다섯은 매일 새 진도만 밀어 넣도록 되어 있었습니다. 이 글은 그 발견 이후에 시작 전 마지막 주를 어떻게 쓸지 정하려고 근거를 찾아본 기록입니다. 병행이 이득인지, 아니면 다른 축을 봐야 하는지가 질문이었습니다. 1. 9월 1일에 켜지는 여섯 줄 1-1. 실제로 예약해 둔 목록 먼저 대상을 정확히 적어 두겠습니다. 아래는 제 예약 작업 목록에서 학습 성격을 가진 항목만 뽑아 시간 순으로 정렬한 것입니다. 시각은 지터가 붙어 매일 몇 분씩 흔들립니다. 시각 커리큘럼 주기 시작일 복습 지점 04:03 ...

반값 모두의카드가 끝나도 환급 감소는 수도권 기준 월 3만 2천원이 최대입니다

3줄 요약 지금 받고 계신 교통비 환급이 9월 이용분까지만 반값 기준으로 계산됩니다. 10월부터는 기준금액이 원래대로 두 배 가까이 올라갑니다. 그렇다고 무한정 손해 보는 건 아닙니다. 수도권에서 시내버스와 전철만 타는 일반 국민이라면 줄어드는 돈이 월 3만 2천원에서 딱 멈춥니다. 교통비를 15만원 쓰든 30만원 쓰든 똑같습니다. 월 교통비가 3만 7천 5백원 이하인 분은 신경 안 쓰셔도 됩니다. 10월에 바뀌는 게 하나도 없습니다. 7월 카드 명세서를 정리하다가 교통비 항목에서 손이 멈췄습니다. 환급이 계좌 입금이 아니라 청구 할인으로 들어오다 보니 몇 달째 눈여겨보지 않았는데, 그날따라 할인액이 눈에 띄게 컸습니다. 앱을 열어보니 안내문 한 줄이 붙어 있었습니다. 4월부터 기준금액이 절반으로 내려가 있었고, 그 아래 작은 글씨로 적용 기간이 적혀 있었습니다. 9월 이용분까지였습니다. 이 글은 그 한 줄에서 시작했습니다. 자기 월 교통비가 얼마인지, 그리고 자기가 어느 대상 구분에 속하는지. 이 두 가지만 알면 10월에 무슨 일이 벌어지는지 계산이 끝납니다. 1. 9월 30일에 정확히 무엇이 바뀌는가 반값의 정체는 요금 할인이 아니라 기준금액 인하 먼저 용어를 정리하겠습니다. 모두의카드의 환급 방식은 세 갈래입니다. 쓴 금액의 일정 비율을 돌려주는 기본형(정률제)이 하나, 정해진 금액을 넘긴 초과분을 전액 돌려주는 정액제가 둘인데 이 정액제가 다시 일반형과 플러스형으로 갈립니다. 여기서 '정해진 금액'을 기준금액이라고 부릅니다. 반값 모두의카드는 요금을 깎아주는 제도가 아닙니다. 이 기준금액을 절반으로 내려서, 초과분 전액 환급이 시작되는 지점을 앞당긴 것입니다. 대도시권광역교통위원회 모두의카드 안내 에 따르면 수도권에 사는 일반 국민의 일반형 기준금액은 원래 6만 2천원인데, 4월부터 9월 이용분까지는 3만원으로 적용됩니다. 3만원을 넘게 쓰면 넘은 만큼을 전부 돌려받는다는 뜻입니다. 월 10만원을 쓰는 사람이라면 3...

리팩터링 에이전트 520번 실행 중 28번만 검증을 통과했습니다

리뷰에서 이런 PR을 받아보신 적이 있을 겁니다. 에이전트가 모듈 하나를 통째로 새 구조로 옮겼고, CI는 전부 초록불이고, 디프는 800줄인데 리뷰어가 볼 만한 논리 변경은 눈에 띄지 않습니다. 머지하고 2주 뒤 프로덕션에서 이상한 값이 나옵니다. 되짚어 보면 에이전트가 새 구조를 만들면서 옛 구현을 어딘가에 그대로 남겨두고 그쪽을 호출하고 있었습니다. 테스트는 옛 구현을 검증하고 있었으니 당연히 통과했습니다. 이 상황에서 선택지는 셋입니다. 리팩터링 PR을 사람이 전부 다시 읽거나, 테스트 스위트를 더 촘촘히 만들거나, 아니면 테스트 통과 말고 다른 판정 기준을 하나 더 세우거나. 첫 번째는 확장이 안 되고 두 번째는 이미 하고 있는 일입니다. 남는 것은 세 번째인데, 그 세 번째가 정확히 무엇이어야 하는지가 늘 애매했습니다. 결론부터 적습니다. 2026-08-25 arXiv에 공개 배포된 리팩터링 벤치마크는 3단계 검증을 세워서 실행 520건을 판정했고, 세 단계를 모두 통과한 것은 28건, 5.4%였습니다. 그런데 저에게 중요한 숫자는 5.4%가 아니라 그 아래 있는 다른 숫자였습니다. 1단계를 통과한 340건 중 58%가 고정 체크 항목의 99%까지 도달했는데, 100%에 도달한 것은 26%뿐이었습니다. 거의 다 됐지만 안 된 상태가 전체의 대부분이라는 뜻입니다. 이 분포가 왜 QA 판정 기준을 바꿔야 하는 이유인지를 아래에 적겠습니다. 1. 벤치마크가 실제로 무엇을 쟀는가 3단계 검증 프로토콜 SWE Refactor Bench(arXiv:2608.23564) 는 2026-08-24 17:59 UTC에 제출되어 2026-08-25 배포분에 실린 논문입니다. 저장소 전체를 대상으로 하는 마이그레이션 과제 20개를 만들고, 그것을 기술 부채 유형 4가지로 나눴습니다. 판정은 한 번에 하지 않고 세 단계를 순서대로 통과해야 합니다. 단계 이름 무엇을 보는가 통과하면 확인되는 것 1 Migration Audit 목표 구조로 ...

남이 바꾼 문자열 하나가 우리 파이프라인을 조용히 깨뜨립니다

가장 설명하기 어려운 장애가 있습니다. 우리 코드는 한 줄도 바뀌지 않았고, 배포도 없었고, 인프라 변경도 없었는데 어느 날 아침부터 회원가입이 실패합니다. 로그를 뒤져 보면 이메일 형식 검증에서 걸러지고 있습니다. 검증 로직은 3년 전에 작성된 것이고 그동안 아무 문제가 없었습니다. 바뀐 것은 우리가 아니라 상대편입니다. 이런 종류의 결함에 대응하는 방식은 셋 정도입니다. 첫째, 터진 뒤에 고칩니다. 대부분의 팀이 여기 있습니다. 둘째, 외부 서비스의 상태 페이지를 구독합니다. 도움은 되지만 이런 변경은 상태 페이지에 안 올라옵니다. 셋째, 우리가 하드코딩한 외부 상수의 목록을 만들고 그 목록에 대해 감시와 테스트를 붙입니다. 결론을 먼저 말씀드리면 셋째만이 실제로 작동합니다. 그리고 8월 24일 하루에 나온 공지 두 건이 이 작업을 지금 시작할 이유를 만들어 줍니다. 하나는 로그인 이메일 도메인이 바뀐다는 예고이고, 다른 하나는 CI 명령어 플래그가 3주 뒤에 사라진다는 통보입니다. 둘 다 우리 코드를 건드리지 않고 우리를 깨뜨릴 수 있는 변경입니다. 1. 8월 24일에 나온 두 건 1-1. Sign in with Apple 이메일 도메인 변경 Apple Developer News 에 2026-08-24 올라온 "Update: New domain for Sign in with Apple"의 문구를 원문 그대로 옮깁니다. "Starting later this year, new Sign in with Apple addresses, previously issued on privaterelay.appleid.com , will be issued on private.icloud.com ." 기존 주소는 계속 동작합니다. "Existing addresses on privaterelay.appleid.com will continue to work and forward mail to users without ...

개발 공고는 코로나 이전의 74%, AI 공고 비중은 사상 최고 6.3%

이직 시장을 한 번 열어 보신 분들은 비슷한 감각을 갖고 계실 겁니다. 공고 수 자체는 확실히 줄었는데, 남아 있는 공고의 요구사항은 오히려 늘어나 있습니다. "AI 기반 테스트 도구 경험", "LLM 활용 자동화 경험" 같은 문구가 QA 공고에도 붙기 시작합니다. 팀원과 1:1을 하면 "지금 뭘 배워야 하냐"는 질문이 나오는데, 답할 근거가 마땅치 않습니다. 여기서 리드가 취할 수 있는 태도는 셋입니다. 첫째, 시장이 어렵다고 인정하고 현 업무에 집중하자고 말합니다. 둘째, AI 관련 학습을 팀 OKR에 넣습니다. 셋째, 숫자를 먼저 확인하고 어느 방향이 실제로 수요가 있는지 확인한 뒤 우선순위를 정합니다. 결론부터 말씀드리면, 8월 24일에 나온 두 개의 자료가 셋째를 할 수 있게 해 줍니다. 요지는 두 문장으로 정리됩니다. 소프트웨어 개발 직군 공고는 코로나 이전 수준의 74% 근처에 머물러 있지만 저점에서는 뚜렷하게 회복했고, AI 관련 공고 비중은 2022년 직전 최고치의 두 배에 가까운 수준까지 올라왔습니다. 이 두 숫자를 나란히 놓으면 팀원에게 할 말이 생깁니다. 1. 8월 24일에 나온 숫자들 1-1. Indeed Hiring Lab의 8월 스냅샷 Indeed Hiring Lab 이 2026-08-24 18:27 UTC(KST 2026-08-25 03:27)에 공개한 "US Labor Market Snapshot — August 2026"의 수치를 원문 그대로 옮깁니다. 지표 원문 수치 기준 시점 전체 채용공고 지수(JPI) "101.8" (2020년 2월 1일 대비 +1.8%) as of August 14, 2026 신규 공고 "97.2" (2020년 2월 대비 약 -3%) 동일 JPI 월간 변화 "0.2%" as of August 14 JPI 전년 대비 변화 ...

CI가 30분이면 AI 도구를 붙여도 소용없습니다

AI 테스트 생성 도구 데모를 보고 나면 팀 채널이 잠깐 시끄러워집니다. 화면 녹화 안에서는 자연어 한 줄이 Playwright 스펙 파일로 바뀌고, 셀렉터가 깨져도 알아서 고쳐집니다. 그런데 두 달 뒤 릴리스 주기를 다시 재보면 아무것도 달라져 있지 않습니다. PR은 여전히 이틀 걸려 머지되고, QA는 여전히 금요일 저녁에 리그레션을 돌립니다. 도구를 잘못 골랐나 싶어 다른 벤더 데모를 또 잡습니다. 여기서 갈래는 셋입니다. 첫째, 모델이나 도구를 더 좋은 것으로 바꿉니다. 둘째, 자동화 커버리지를 더 올립니다. 셋째, 도구 검토를 멈추고 파이프라인이 실제로 몇 분 걸리는지부터 잽니다. 앞의 둘은 예산과 사람이 필요하고 셋째는 오늘 오후에 시작할 수 있습니다. 그런데 대부분의 팀이 앞의 둘부터 손을 댑니다. 결론을 먼저 말씀드리면, 셋째부터 하시는 편이 맞습니다. 파이프라인이 30분이면 그 안에서 사람이든 에이전트든 하루에 시도할 수 있는 횟수가 물리적으로 제한됩니다. 도구를 바꿔서 코드 작성 시간을 절반으로 줄여도 검증 대기 시간이 그대로면 전체 리드타임은 거의 움직이지 않습니다. 이건 정성적인 훈계가 아니라 8월 24일에 GitLab이 숫자와 함께 내놓은 주장이고, 저는 우리 팀 상황에 그대로 적용된다고 봅니다. 1. 8월 24일 GitLab이 내놓은 문장 하나 1-1. "코드는 더 이상 병목이 아니다" GitLab 공식 블로그 에 2026-08-24 올라온 CEO Bill Staples의 글 "When code is abundant"는 "Code is no longer the bottleneck."이라는 문장으로 시작합니다. 여기까지는 흔한 수사입니다. 이 글이 인용할 만해지는 지점은 그다음입니다. 같은 글에 이런 문장이 있습니다. "a thirty-minute CI pipeline defeats every model you point at it." 30분짜리 CI 파이프...

옵시디언 3기기 동기화, 유료 결제 없이 구글 드라이브로 끝내기

안드로이드 폰과 맥은 이미 동기화되고 있는데 아이패드만 붙지 않는다면, 설정을 잘못한 것이 아닐 가능성이 큽니다. iOS는 다른 앱의 폴더를 볼트로 지정하는 방식 자체를 허용하지 않기 때문입니다. 해결은 두 갈래입니다. 월 구독료를 내고 공식 동기화를 쓰거나, 구글 클라우드 콘솔에서 OAuth 클라이언트를 직접 발급해 커뮤니티 플러그인에 물리는 것입니다. 이 글은 후자를 택했을 때 실제로 어디서 막히는지, 그리고 그 대가가 얼마나 되는지를 순서대로 정리한 기록입니다. 미리 결론부터 말씀드리면, 기술적으로는 완전히 동작합니다. 다만 "무료"의 정의를 금전 비용이 아니라 총 소요 시간으로 바꾸는 순간 판단이 달라질 수 있습니다. 1. 아이패드에서만 막히는 진짜 이유 같은 볼트를 세 기기에서 열려고 할 때, 플랫폼별로 가능한 동작이 다릅니다. 항목 안드로이드 macOS iPadOS 임의 폴더를 볼트로 지정 가능 가능 불가 볼트 위치 선택지 내부 저장소 어디든 어디든 iCloud Drive 또는 앱 내부 로컬 백그라운드 동기화 데몬 가능 가능 불가 안드로이드에서 서드파티 동기화 앱이 잘 동작하는 이유는 두 가지입니다. 파일 시스템에 자유롭게 접근할 수 있고, 백그라운드 서비스로 상주할 수 있기 때문입니다. macOS도 마찬가지입니다. iOS와 iPadOS는 둘 다 막혀 있습니다. 앱은 다른 앱의 샌드박스를 읽을 수 없고, 화면에 떠 있지 않으면 대부분 실행되지 않습니다. 파일 앱에 구글 드라이브가 보이는 것은 원격 스트리밍 방식의 File Provider일 뿐이라, 노트 앱이 실시간으로 읽고 쓸 수 있는 로컬 폴더가 아닙니다. 그래서 iPad에서 가능한 모델은 하나뿐입니다. [다른 플랫폼] 클라우드 폴더 자체를 볼트로 지정 [iPad] 앱 내부 로컬 볼트 + 플러그인이 API로 밀고 당김 이 차이를 모르면 "플러그인 설정을 잘못했나" 하며 며칠을 ...