“이제 성능은 대부분 충분하다.
차이는 운영 경계와 검증 습관에서 난다.”
[Read More]
PR은 쪼개고, 규칙은 ~/.cursor에 — 레거시 API 에픽과 Cursor 스킬
내부 private monorepo 작업을 바탕으로 썼다. Jira·Slack 채널 ID·private PR URL은 일반화했고, /cb:* 스킬 규칙은 거의 그대로 둔다.
[Read More]
임시 기능에서 과공용화로 번진 날: AI 리뷰 추종의 비용 회고
“리뷰를 열심히 반영했는데 왜 장애 대응 PR이 연달아 생겼을까?”
[Read More]
프론트엔드 알람 대응 30분 점검표
“어느 주, 모니터링을 보다가 장바구니 p99가 비정상적으로 높게 잡혀 있었다.
그때부터 알람 직후 30분을 따로 점검하기 시작했다.”
[Read More]
리뷰어가 먼저 읽는 횡단 PR — 코드보다 의도를 먼저 합의하기
“좋은 PR은 코드를 설명하지 않는다.
무엇을 같게 만들었는지와 무엇을 다르게 남겼는지를 먼저 합의한다.”
[Read More]
샘플링 1% 미만에서 p99를 읽는 법 — 장바구니 tail 지표가 튀었을 때
“p99는 숫자가 아니라 태도다.
평균이 멀쩡한 날에도, 가장 느린 1%를 제품의 진실로 다루겠다는 태도.”
[Read More]
생산성은 어디에서 생기나 — 에이전트 이전과 이후, 횡단 작업을 기준으로
“속도는 키보드에서 나지 않는다. 맥락을 싸 들고 계단을 오를 힘에서 난다.
에이전트는 그 가방을 잠깐 들어 준 짐꾼에 가깝다. 방향은 여전히 내가 잡는다.”
[Read More]
SSOT(Single Source of Truth)가 합법성이 되는 순간 — 문서 중심주의의 그림자
“무거운 비유는 조심한다.
다만 조직 안에서 문서가 하는 일에는, 가끔 같은 문법이 반복된다.”
[Read More]
Cursor 완벽(?) 가이드 — 코드 생성기가 아니라 작업 운영체제로 쓰기
“AI가 코드를 써 준다”는 말은 맞지만, 너무 작다.
내가 Cursor를 쓰며 얻은 더 큰 감각은 이쪽이다.
티켓, 코드, 채팅, 브라우저, 터미널, 문서를 한 흐름으로 이어 주는 작업 운영체제.
[Read More]
헤드라인 두 개를 같이 읽기 — 대체가 아니라 재배치
“뉴스는 사건을 잘 옮긴다. 다만 한 기사가 곧 세계의 전부는 아니다.
나는 요즘, 서로 다른 헤드라인을 나란히 놓고 읽는 연습을 한다.”
[Read More]
티켓, 브랜치, 채팅을 한 줄로 잇기 (성과 정리용 루프)
“계획은 이슈 트래커에, 실행은 저장소에, 합의는 채팅에 남는다.
그 사이를 메우는 건 도구가 아니라, 내가 들고 있는 문맥이다.”
[Read More]
작은 프론트엔드 수정이 긴 리뷰로 번질 때
“작은 수정은 빠르게 끝날 줄 알았다.
그런데 진짜 시간은 구현보다 리뷰에서 더 많이 들었다.”
[Read More]