왜 이 저장소를 프로젝트로 넣는가
다른 프로젝트 10건은 전부 비공개이거나 발주처 자산이다. 읽는 사람 입장에서는 결국 서술을 믿는 수밖에 없다. 이 저장소만 라이브 사이트와 공개 저장소, 전체 커밋 이력과 PR 토론이 모두 열려 있다. 여기 적은 문장 하나하나를 직접 대조할 수 있다는 것이 이 카드의 유일한 목적이다.
사이트는 산출물이고, 본체는 개발 방식이다. 그래서 "지금 보고 있는 이 페이지가 그 산출물"이라는 자기참조가 이 카드에서는 어색함이 아니라 근거가 된다.
도구를 세 번 바꾼 이유
설계는 Codex로 시작했다. 구조를 잡고 나서는 Antigravity로 옮겨 기본 틀을 쌓아 올리며 개발을 이어갔다. 그러다 Antigravity가 쓰는 Gemini의 성능이 이 작업에 충분하지 않다고 판단해 Claude Code로 옮겼고, 지금까지 그 위에서 진행하고 있다.
도구를 바꾼 것 자체는 성과가 아니다. 다만 무엇이 부족해서 옮겼는지를 판단하고 그 시점을 기록으로 남긴 것은 남는다.
AI가 쓴 코드를 어떻게 믿을 것인가
이 프로젝트의 코드 작성 주체는 AI다. 그러면 사람의 일은 코드를 치는 것이 아니라, 산출물과 진단을 검증하는 것이 된다. 여기서 배운 것은 자동 검사를 통과했다는 사실이 옳다는 뜻은 아니라는 것이다.
시각 회귀 테스트가 그 예다. 비교 허용치가 5%라, 스크롤 리빌이 발화하지 않아 요소가 통째로 빠진 화면도 허용치 안에 들어가 통과했다. 그렇게 한번 기준 이미지로 굳으면 이후의 진짜 회귀까지 같은 이미지와 비교되어 계속 통과한다. 카드 8장 중 3장만 찍힌 이미지와, 2행으로 깨진 배치가 각각 정답으로 굳어 있었다.
처음에는 대기 시간을 늘리는 쪽으로 접근했다. 결과는 3장이 2장으로 줄어드는 것이었고, 시간 문제가 아니라는 사실이 그때 드러났다. 기다리는 대신 촬영 전에 페이지 끝까지 스크롤해 관찰자를 모두 발화시키는 쪽으로 바꿨고, 오염된 기준 이미지는 폐기했다.
틀린 진단을 지우지 않기
같은 이유로 틀렸던 판단도 남겨 두었다. 스냅샷이 깨진 원인을 처음에는 mix-blend-mode로 진단했지만 사실이 아니었다. 실제로는 페이지 로더 오버레이가 함께 찍힌 것이었다. CI가 반복해서 멈춘 것도 처음에는 일시적인 문제로 봤지만, 실측해 보니 미러 대역폭이 원인이었고 그 판단은 철회해야 했다.
두 경우 모두 원래 진단을 지우고 결론만 남길 수 있었다. 그렇게 하지 않은 이유는, 무엇을 얼마나 확인하고 판단했는지가 결론보다 더 많은 것을 말해 준다고 봤기 때문이다.