우리는 AI로 salty.poker를 구축했습니다. 아무도 못 본 그 부분.

10일 동안 22번의 빌드 세션.

각 세션마다 Claude Code 에이전트가 100페이지 사양서를 기반으로 작업했습니다 — 코드베이스의 현재 상태를 읽고, 할당된 사양 모듈을 가져와 코드를 작성하고, 서비스를 연결하고, 마이그레이션을 실행하고, 커밋했습니다. 추정 회의 없음. 범위 논의 없음. 회의실에서 논쟁하는 Jira 티켓 없음.

그 세션들의 결과물은 20개의 마이크로서비스, 실시간 테이블 엔진, 토너먼트 관리, 이중 장부, KYC 인증, 사기 탐지, 그리고 애니메이션 카드와 칩 스택이 있는 PixiJS 렌더링 포커 테이블이었습니다.

체인지로그는 출시된 것들을 다룹니다. 이 포스트는 그 이후에 일어난 일에 관한 것입니다.

코드가 작성된 후 실제로 일어나는 일

올바른 코드를 작성하는 것과 작동하는 시스템을 갖추는 것은 두 가지 다른 일입니다. 코드는 단위 테스트를 통과합니다. 서비스는 격리 상태에서 올바르게 작동합니다. 하지만 모든 것을 연결하면 — 웹 앱, 테이블 엔진, 실시간 연결, 인증, 데이터베이스 — 실패 가능성의 표면적은 어떤 테스트 스위트도 완전히 예상할 수 없을 만큼 빠르게 증가합니다.

지난주가 바로 그 단계였습니다. 엔드-투-엔드 테스팅. 실제 로그인, 실제 로비, 실제 테이블, 실제 플레이어가 자리를 잡습니다.

테이블 뷰가 로드되었지만 좌석이 있어야 할 곳에 빈 캔버스가 표시되었습니다. 바이인 대화 없음. 로비로 돌아갈 방법 없음. 포커 게임이 있어야 할 곳에 빈 화면.

로비에는 전체 페이지 높이를 채우도록 늘어난 테이블 카드가 있었습니다. 하나의 CSS 기본값 — 행에 항목이 하나만 있고 stretch 동작을 재정의하지 않았을 때 CSS Grid가 작동하는 방식일 뿐입니다.

이 버그들 중 어느 것도 인간이 작성하지 않았습니다. AI 세션이 테이블 뷰를 작성했습니다. AI 세션이 로비를 작성했습니다. 그래도 버그였습니다. 찾아야 하고, 근본 원인을 추적하고, 수정해야 했습니다.

왜 이것이 여전히 더 나은 길인가

어떻게 부서졌는지 이야기하기 전에: 10일 만에 엔드-투-엔드 테스팅 단계에 있다는 사실이 바로 그 이야기입니다.

이전 두 회사가 전통적인 방식으로 얼마나 오래 걸리는지 가르쳐 주었습니다. 테스트할 것이 생기기 전에 몇 달. 최종 제품과 닮은 것을 테스트하기 전에 몇 달 더.

우리는 그 격차를 10일 만에 좁혔습니다. 테스팅 단계가 어려운 부분입니다. 우리는 그 안에 있습니다.

이 시리즈에서 다음에 오는 것

이것은 4개 중 첫 번째 포스트입니다. 다음 주에 걸쳐, 우리가 테스팅 중 실제로 발견한 것들을 살펴볼 것입니다 — 전체 스택이 실행될 때까지 보이지 않는 라우팅 버그, 코드 변경을 조용히 무시하는 개발 환경, 모든 탐색 시도를 리디렉션 루프로 보내는 인증 가드.

더 깊은 방법론을 위해서는 The Salty Korean에서 다루고 있습니다.

Stay salty.