개인 블로그에서 잘 쓰던 스킬을 공개 저장소로 옮기면서 개인 설정 대신 재사용 가능한 워크플로와 초기화 절차를 남겼다. 각 사용자가 자기 블로그의 로컬 프로필을 만들고, 초안·점검·발행의 경계를 지키며 운영하는 구조를 정리한다.
[Read More]
내 사용 통계가 내 폴더 이름에 달려 있었다
AI 사용 기록을 분류하는 스크립트가 요청이 아니라 그 요청이 놓인 환경을 채점하고 있었다. 경로, 링크, 에디터가 붙인 컨텍스트, 그리고 도구 이름 자체가 카테고리를 결정했다. 무엇을 채점하면 안 되는지 정리한다.
[Read More]
E2E 검증을 설계와 실행으로 나눈 이유
브라우저 E2E는 실행보다 먼저 무엇을 확인하고 어떤 근거로 통과시킬지 정해야 한다. 테스트 설계와 실행을 두 스킬로 분리하고, 성공을 추정하지 않는 검증 계약을 공개 저장소에 추가했다.
[Read More]
빌드는 초록이었고, 컨테이너는 부팅하자마자 죽었다
타입 체크·빌드·배포 워크플로가 전부 성공했는데 컨테이너는 기동 직후 죽었다. 번들러가 복사한 파일과 런타임이 찾는 파일이 달랐기 때문이다. 자동화가 못 잡은 실패를 사람이 먼저 발견했고, 그다음에 지면 전수 검증을 자동화했다.
[Read More]
브랜치 2,001개 중 지우면 안 되는 건 3개였다
브랜치가 쌓여도 당장은 아프지 않아서 계속 미루게 된다. 공유 저장소와 로컬에서 각각 무엇이 나빠지는지 재보고, 안전하게 지우는 기준을 스킬로 굳힌 기록이다.
[Read More]
my-cursor는 잘 작동했지만, Agent Skill Garden으로 다시 시작했다
개인 AI 설정을 백업하고 동기화하는 방식은 도구가 바뀔수록 또 하나의 원본을 만들었다. 설정 파일이 아니라 반복 업무의 판단과 검증 절차를 공개 가능한 구조로 다시 설계한 과정을 정리한다.
[Read More]
그럴듯한 설명이 측정을 대신할 때
버그 제보가 개발자에게 도착했을 때 원인은 사라지고 해법만 남아 있었다. 나도 AI도 그 해법부터 구현했다. 방향을 되돌린 건 논증이 아니라 브라우저를 직접 몰아서 잰 숫자였다.
[Read More]
일곱 번 다, 확인한 대상이 틀렸다
에디터 버그 하나를 고치는 데 엿새가 걸렸다. 시간은 대부분 소스를 검색하고, 서버를 찔러보고, 리뷰를 여섯 라운드 받은 자리에 갔다. 전부 확인은 했는데 전부 엉뚱한 것을 확인했다. AI는 지정한 대상을 정확하게 확인하기 때문에, 대상이 틀리면 정확하게 틀린 답을 준다.
[Read More]
일정은 관리됐지만 기술은 관리되지 않았다
Engineering Manager가 직접 코드를 쓰지 않아도 괜찮다. 다만 기술 판단의 주체와 우선순위, 실행할 시간을 확보하지 않으면 그 책임은 결국 몇몇 개인의 책임감 위에 쌓인다.
[Read More]
diff만 보고 쓴 검증 항목이 스펙이 되었다
코드 변경만 읽고 '이렇게 동작할 것'이라 적은 검증 항목 한 줄 때문에, 검증 담당자가 정상 동작을 결함으로 등록했다. 그 오탐을 파고들다 진짜 버그가 나왔고, 결국 고친 것은 코드가 아니라 항목을 쓰는 절차였다.
[Read More]
자동리뷰 프롬프트를 복사하지 않고 동기화하는 법
자동리뷰 프롬프트를 한 번 복사하면 원본 계약과 개인 규칙이 곧 갈라진다. 실행 로그에서 계약만 복원하고 개인 정책은 별도 계층으로 유지하는 동기화 구조를 정리했다.
[Read More]
취소선도 결과다: 착수 전에 코드를 읽어야 하는 이유
두 가지 수정 요청을 받은 뒤 코드를 확인하자 하나는 이미 전제가 달랐고 다른 하나는 별도 설계가 필요한 일이었다. 코드를 쓰지 않고 범위를 줄이는 것도 개발의 중요한 결과다.
[Read More]