2026. 08. 16.•품질검증
AX CASE STUDY이미 다 돼 있는 걸 다시 만들 뻔한 걸 막았습니다
"새로 만들기 전에, 진짜 빠진 한 조각만 찾았다"
개발 여정과 기록을 모아놓은 빌드 로그입니다.
"새로 만들기 전에, 진짜 빠진 한 조각만 찾았다"
"완성된 스키마와 RPC, 그 사이를 잇는 조립만 남아 있었다"
"이미 작동하는 기능이 눈에 안 보이면, 없는 기능처럼 느껴진다"
"검증은 완성됐는데, 그걸 통과할 방법이 없었던 반쪽짜리 기능"
"Structured는 Step CRUD, Visual은 연결만 — 역할을 분리했다"
"두 저장 사이 간격 없이 눌러도 CONFLICT가 안 나는지가 검증의 핵심"
"Node position만 바꿔도 CASCADE로 하위 데이터가 통째로 삭제됐다"
"무엇을 저장할지와 어디로 이동할지는 다른 관심사다"
"메모리가 말하는 것과 실제 파일 상태는 다를 수 있다"
"진짜 문제는 유저 생성이지 픽스처 공유가 아니다"
"이상 징후가 보여도 감이 아니라 같은 검증 도구로 확인한다"
"막을 수 있는 걸 일부러 안 막았다는 걸 증명하는, 보통과는 반대 방향의 검증"
"테스트가 통과했다고 mock이 현실을 반영하는 건 아니다"
"unit test가 통과해도 눌러보기 전까진 모른다"
"문자열이 남아있다고 로직이 맞는다는 뜻은 아니다"
"삭제해도 되는가 전에, 이게 뭔지부터 알아야 한다"
"커밋됐다는 것과 원격에 반영됐다는 건 다른 사실이다"
"Sign-off는 코드가 아니라 기록이 완성되는 순간 끝난다"
"같은 명령도 실행 환경에 따라 다르게 동작한다"
"텍스트 파일이 텍스트가 아니게 된 사고의 증거는 한 줄이었다"
"테스트 통과 보고와 실제 DB 반영은 다른 이야기다"
"시나리오를 몰아넣으면 실패할 때 반드시 대가를 치른다"
"AI가 만든 결과물을 검증 없이 받아들이지 않는다"는 원칙은, 코드뿐 아니라 결제 청구서에도 똑같이 적용된다.
"만들 수 있다는 것과 만들 가치가 있다는 건 다른 문제입니다. 이번엔 만들어놓은 기능이 실제로 쓸만한지, 제가 직접 써보면서 확인했습니다."
"헤더로 추측하지 말고, 사용자가 직접 신호를 보내게 하라."
"쿠키 하나가, 캐싱 전체를 무력화시키고 있었다."
"코드가 실수해도, DB가 마지막 방어선이 되어준다."
계획서 없이 코드부터 짜지 않는다
동작한다와 쓸 수 있다는 다른 문제입니다.
AI는 거짓말하지 않았습니다. 다만 말하지 않았을 뿐입니다.