1장 코드를 고치기 전에 인수한다

고장 난 프로젝트를 받으면 바로 파일을 수정하고 싶어진다. 첫날의 목표는 수정이 아니라 경계 확정이다. 무엇이 제품이고, 어떤 데이터가 들어가며, 어떤 외부 행동이 가능한지 모르면 좋은 수정과 위험한 수정도 구분할 수 없다.

먼저 저장소의 사실을 한 장에 적는다.

• 시작 명령과 필요한 런타임 버전
• 사용자 역할과 핵심 여정
• 데이터 저장 위치와 초기화 방법
• 외부 서비스와 실제 비용이 발생하는 행동
• 이미 알려진 오류와 아직 확인하지 못한 영역
• 성공을 판단할 테스트·화면·로그

RoomRelay의 첫 인수 메모는 간단하다. Node.js로 실행되며 공간 예약을 메모리에 저장한다. start/booking.mjs는 시작 시각이 같은 예약만 중복으로 판단한다. 10시부터 11시 예약이 있어도 10시 30분부터 11시 30분 요청은 통과한다. ID가 난수라 동일 요청을 재전송하면 예약이 두 개 생긴다. 요청과 확정도 한 단계라 운영자 확인이 없다.

중요한 것은 결함의 개수가 아니다. 독자가 직접 재현할 수 있는 문장으로 바꾸는 것이다.

조건: room-a에 10:00~11:00 예약이 존재한다.
행동: 다른 사용자가 10:30~11:30을 요청한다.
기대: OVERLAP으로 거부한다.
현재: 새 confirmed 예약을 만든다.

이 문장이 첫 테스트가 된다. “예약이 가끔 겹쳐요”라는 보고는 고칠 수 없지만, 입력과 기대가 있는 보고는 코드와 대조할 수 있다.

첫날에 하지 않을 일

패키지를 전부 최신 버전으로 올리지 않는다. 화면을 새로 디자인하지 않는다. 데이터베이스를 교체하지 않는다. AI에게 “전체적으로 리팩터링해 줘”라고 하지 않는다. 이 작업은 원인과 변경을 섞어 비교를 어렵게 만든다. 첫날에는 실행, 재현, 범위, 안전장치만 만든다.

장 실습

examples/roomrelay/start/booking.mjs를 읽고 세 가지 결함을 재현 문장으로 적는다. 아직 고치지 않는다. 문장마다 조건, 행동, 기대, 현재 결과가 있는지 확인한다.