커리어 도구 아이디어를 바로 코딩하지 않고, 판단 기준과 금지 사항을 Markdown 명세로 먼저 고정했다. Codex로 MCP 서버와 React 위젯을 만들고 ChatGPT의 실제 실행 환경까지 연결하면서, 명세와 로컬 테스트만으로는 잡히지 않던 빈 화면도 발견했다.
[Read More]
관측은 두 번 알려줬다, 틀린 건 번역이었다
폐기 예정 API를 닫기 전에 트래픽은 분명히 봤다. 남은 호출 비율도, 마지막 호출자의 콘텐츠 ID도 정확히 짚어냈다. 그런데 '이 호출은 누구 것인가'를 사람에게 물었고, 답할 수 없는 사람이 답했다. 관측이 판정으로 자동 변환되지 않는 자리에 대한 기록.
[Read More]
에러 화면은 있었는데 로그가 없었다: 처리된 실패가 두 시간 넘게 보이지 않은 이유
외부 API 가 사라지자 SSR 페이지는 곧바로 친절한 오류 화면으로 바뀌었고, 그 상태로 두 시간 넘게 아무 알림도 없었다. 실패를 처리하는 코드와 실패를 알리는 코드는 다른 것이며, 200 으로 내려가는 fallback 은 모니터링에 잡히지 않는다.
[Read More]
교차 검증도 같은 시점을 보면 함께 틀린다
회고에서 리뷰 봇 지적 하나를 오탐으로 분류했는데, 며칠 뒤 그 코멘트를 쓴 동료가 오탐이 아니라고 알려줬다. 채택해놓고 오탐으로 적은 것이었고, 원인은 현재 파일의 줄 번호로 과거 코멘트를 판정한 것이었다.
[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]