회고에서 리뷰 봇 지적 하나를 오탐으로 분류했는데, 며칠 뒤 그 코멘트를 쓴 동료가 오탐이 아니라고 알려줬다. 채택해놓고 오탐으로 적은 것이었고, 원인은 현재 파일의 줄 번호로 과거 코멘트를 판정한 것이었다.
[Read More]
에러 메시지가 두 가지 일을 하고 있었다
장애 때 사용자 화면에 내부 진단 문자열이 노출됐다. 에러의 message를 로그와 화면이 함께 읽고 있었고, 백 곳이 넘는 수정에서는 파서보다 실행 가능한 완료 조건을 만드는 일이 더 어려웠다.
[Read More]
AI Native는 모델이 아니라 운영 능력이다
좋은 모델을 빠르게 도입하는 것만으로 조직이 AI Native가 되지는 않는다. AI 도구를 바꾸고 스킬 사용 기록을 살펴본 경험에서, 모델이 바뀌어도 남겨야 할 판단과 검증의 기준을 짚어 본다.
[Read More]
남겨둔 기준이 일주일 만에 도구 세 개가 됐다
버그 하나를 도구로 남긴 뒤 일주일. 같은 모양의 회전이 세 번 돌았다 — 회고가 규칙이 되고, 그 규칙이 자기 리뷰를 통과하고, 앱 계약 문의가 그날 진단 절차가 됐다. 반복을 만든 것은 대단한 자동화가 아니라 판정 어휘 하나와 세는 단위였다.
[Read More]
버그를 고친 과정을 다음 리뷰의 도구로 남겼다
리뷰를 통과한 버그를 고친 뒤, 그 과정에서 사용한 판단을 다음 리뷰에서도 반복할 수 있는 작은 도구로 정리했다. 자동화할 것과 사람에게 남길 질문을 나누고, 실제 작업 흐름에 연결하기까지의 기록이다.
[Read More]
리뷰를 세 번 통과한 버그 — diff보다 범위가 문제였다
1년 넘게 이어진 세 개의 PR이 각각 리뷰를 통과했다. 각 변경은 자기 티켓 안에서는 타당해 보였지만, 결과는 특정 OS에서만 보이는 레이아웃 버그였다. 리뷰가 놓친 것은 문법이 아니라 그 코드가 적용되는 범위였다.
[Read More]
전역 Axios에 요청별 인증정보를 얹지 마라 — 사람 리뷰보다 정적 분석이 먼저 볼 문제
SSR에서 요청별 인증정보를 전역 Axios defaults에 얹으면 요청 간 자격증명이 섞이고, 외부 URL 프록시와 결합하면 토큰이 외부로 전송될 수 있다. 이 위험을 어디까지 정적 분석으로 앞당기고 어디부터 사람이 판단해야 하는지 정리했다.
[Read More]
PR 리뷰 대응을 승인까지 이어가는 review-response-loop
리뷰 지적에 답한 뒤 재요청과 상태 확인이 끊기면 PR은 쉽게 멈춘다. 답변·스레드 정리·재요청·감시를 한 라운드로 묶고, 종료 조건을 증거로 판정하는 작성자용 워크플로를 소개한다.
[Read More]
URL의 ID를 바꿔도 되는가: 프런트엔드 개발자의 BOLA 대응법
다른 사용자의 객체 ID를 넣었을 때 데이터가 보인다면 화면 문제가 아니라 서버의 객체 단위 인가 문제다. 프런트엔드 개발자가 BOLA 의심 지점을 발견하고 백엔드의 빠른 검증과 수정을 돕는 방법을 정리한다.
[Read More]
사실이 고정된 일은 맡기고, 움직이는 일은 지켜본다
에이전트에게 어디까지 맡길지는 작업의 난이도가 아니라 사실의 안정성으로 갈린다. 28개 앱 모노레포의 보안 패치를 함께 끝내고 그날 세션 기록을 세어 봤다. 자동 검사가 전부 통과한 뒤에 사람이 결함 세 건을 찾았고, 내 판단이 잠깐 꺼진 순간에는 예전에 적어 둔 규칙이 대신 판단했다.
[Read More]
설정을 복사하지 않고 AI 작업 환경을 다시 세우기
공개 스킬 저장소를 새 기기에서도 다시 쓸 수 있도록 사용자 규칙, 공용 스킬, 로컬 환경값을 분리했다. 설정 전체를 백업하는 대신 안전하게 작업 환경을 재구성하는 부트스트랩 계약을 정리한다.
[Read More]
Agent Skill Garden에 프론트엔드 리뷰 팩을 추가했다
PR의 현재 diff를 읽고 필요한 리뷰 관점만 선택하는 프론트엔드 리뷰 팩을 공개 저장소에 추가했다. 오케스트레이터와 React·TypeScript·Next.js·저장소 위생 리뷰가 어떻게 구성되는지 소개한다.
[Read More]