제 여동생은 자기 차로 강아지 산책 사업을 하고 있습니다. 고객 14명, 세 사람이 엉망으로 편집하는 공유 구글 캘린더, 그리고 다음 차례 강아지 주인에게 "가는 중이에요!"라고 문자를 보내는 습관이 있는데, 이걸 두 번이나 깜빡해서 민망한 전화를 받아야 했습니다. 목요일에 여동생이 "별거 없는 앱"을 부탁하며 다음 주 월요일까지 나왔으면 좋겠다고 했습니다. 저는 일요일 밤까지는 뭔가 만들어보겠다고 말했습니다. 이건 제가 남긴 기록입니다. 나중에 실제로 뭐가 시간을 잡아먹었는지, 그리고 시간이 걸릴 거라고만 생각했던 게 뭔지 알고 싶었거든요.
금요일 오후 8시 40분 — 프롬프트
빈 에디터를 열지 않았습니다. 저는 채팅을 열고 그냥 사업을 설명했습니다: 1인 강아지 산책 사업자, 정기 고객 14명, 고객들이 산책 당일 아침에 자동 알림 문자를 받아야 하고, 대개 누군가의 진입로에 서 있는 상태로 작업하기 때문에 30초 안에 새 고객과 강아지 이름을 추가할 수 있는 간단한 페이지가 필요하다고 했습니다. "예약 앱"이라는 말을 한 번 했다가 바로 취소했습니다 — 이건 예약 앱이 아니라 알림 트리거가 달린 고객 목록입니다. 그것이 무엇이 아닌지를 정확히 말하는 것이, 그것이 무엇인지를 설명하는 것보다 더 중요했던 것으로 드러났습니다.
금요일 오후 9시 5분 — 계획이 돌아오다
계획에는 제가 요청하지 않았지만 잊어버렸을 세 가지가 포함되어 있었습니다:
- 산책을 완료로 표시하는 방법, 알림이 두 번 발송되지 않도록
- 규정 준수를 위한 SMS 수신 거부 링크
- 캘린더 그리드 대신 단순한 일별 보기 — 전화 화면에 14개 항목이 든 캘린더 그리드는 그냥 작은 글씨 벽일 뿐이니까요
그다음 20분 동안 계획을 세 번이나 다시 썼는데, 대부분 다시 쓸 필요가 없는 표현을 고쳤을 뿐이었습니다. 돌이켜보면 그건 순전히 긴장감 때문이었습니다 — 계획 에이전트는 이미 첫 시도에서 구조를 제대로 잡았고, 저는 본질이 아니라 문장을 편집하고 있었던 거죠.
금요일 오후 9시 40분 — 첫 실행
시작해서 에이전트 팀이 고객 모델, 일별 보기 페이지, 알림 작업을 처리하는 것을 지켜봤습니다. 디자인은 수의사 병원 접수 양식처럼 나왔는데, 사실 이건 대상 사용자에게 딱 맞았습니다 — 제 여동생의 고객들은 40대, 50대 강아지 주인들이지 시리즈 A 피치덱을 볼 사람들이 아니니까요. 습관적으로 비주얼 스타일에 반대하려다가, 이게 제가 골랐을 그 어떤 것보다 실제 사용자에게 더 맞는다는 걸 깨달았습니다.
금요일 오후 10시 30분 — 첫 번째 걸림돌
SMS 부분은 실제로 뭔가를 보내려면 실제 제공업체 키가 필요했는데, 이건 정상적인 동작이지 버그가 아니었지만, 저는 아직 설정하지 않았다는 걸 깜빡했습니다. 다른 모든 것은 계속 작동했습니다 — 앱은 그냥 실제로 보냈을 내용을 발송하는 대신 로그로 남겼고, 덕분에 금요일 밤 10시 30분에 Twilio 가입에 막히지 않고 계속 빌드를 진행할 수 있었습니다. 그리고 잤습니다.
토요일 오전 8시 — 진짜 걸림돌
이게 실제로 시간을 잡아먹은 부분입니다. 저는 알림이 "당일 아침"에 나가야 한다고 요청했는데, 첫 버전은 이걸 모든 고객에 대해 고정된 오전 7시 발송으로 해석했습니다. 오전 9시 산책에는 괜찮지만, 오후 4시 산책에는 쓸모가 없었습니다. 채팅으로 돌아가서 직접 이렇게 말했습니다:
알림은 고정된 시계 시간이 아니라, 각 산책의 예정 시간 기준으로 정해진 시간 전에 발송되어야 합니다.
수정은 한 번의 대화로 끝났습니다. 교훈은 도구에 관한 것이 아니라 제 자신의 프롬프트에 관한 것이었습니다: "당일 아침"은 말하는 사람에게는 정확하게 느껴지지만, 12시간 후의 저를 포함해서 다른 모든 사람에게는 완전히 모호한 표현이라는 것입니다.
토요일 오전 11시 15분 — 검증 기록 읽기
다른 걸 건드리기 전에, 빌드가 스스로 무엇을 기준으로 확인했는지 먼저 확인했습니다:
- 고객 양식이 올바르게 저장되는지
- 알림 작업이 테스트 일자의 예약에 대해 실행되는지
- 수신 거부 링크가 실제로 테스트 번호의 구독을 해지하는지
아무것도 문제가 없었습니다. 저는 스스로 문제를 찾아 나서기 전에 이걸 먼저 읽는 습관을 들였습니다. 무작정 여기저기 클릭하며 잘못된 것을 발견하기를 바라는 대신, 실제로 어디에 주의를 기울여야 할지 알려주기 때문입니다.
토요일, 오후 2시 — SMS, 이번엔 진짜로
제공업체 계정을 만들고, 키를 넣고, 나에게 테스트 알림을 보내봤다.
사소한 것 같지만, 이 순간이 바로 프로젝트가 데모에서 벗어나 실제로 세상에 존재하는 무언가가 되는 순간이다.
토요일, 오후 4시 20분 — 도메인 대기 시간
그녀의 실제 도메인을 연결한 뒤, DNS가 반영되길 기다리며 두 시간 동안 별다른 일을 하지 않았다. 그 시간을 실제 고객 14건의 데이터를 그녀 대신 직접 입력하는 데 썼는데, 돌이켜보면 이번 주말 전체에서 가장 잘 쓴 시간이었다 — 아무도 요청하지 않은 불필요한 꾸밈보다는, 볼품없어도 데이터 입력을 해두는 게 낫다.
일요일, 오전 9시 — 하마터면 과하게 만들 뻔한 부분
그녀가 주간 요약본 — 완료한 산책, 노쇼, 매출 — 을 원할 거라는 생각이 들어서, 월요일 아침마다 자동으로 요약본을 보내는 기능을 요청하기 시작했다. 설명을 절반쯤 하다가 멈췄다. 그녀는 고객이 14명뿐이고 장부도 직접 노트에 적는다. 요약 기능은 아직 존재하지도 않는 문제에 대한 해결책이다. 빼기로 했다. 정말로 필요해지는 주에 5분이면 추가할 수 있고, 그 전까지는 그저 뭔가 잘못될 여지만 늘릴 뿐이다.
일요일, 오후 1시 10분 — 링크를 보냈다
그녀는 주차장에 서서 휴대폰으로 고객을 추가했는데, 그게 내가 직접 확인했던 그 어떤 것보다 중요한 진짜 테스트였다.
일요일, 오후 6시 40분 — 다음번엔 건너뛸 것들
다음번엔 건너뛸 것들:
- 아무것도 바꾸지 못한 세 번의 계획 재작성
- 설정도 시작하기 전에 SMS 제공업체를 두 시간 동안 걱정한 것
- 거의 만들 뻔한 요약 대시보드 — 주말 전체에서 가장 빨랐던 30분은 내 아이디어를 직접 만드는 대신 스스로에게 "안 돼"라고 답한 그 30분이었다
실제로 시간이 든 부분은 전부 내 요청 자체의 진짜 모호함이거나, 남의 DNS 서버를 기다릴 수밖에 없는 시간뿐이었다. 다음 빌드에서는 프롬프트를 한 번만 쓰고, 남이 쓴 것처럼 다시 읽어보고, 지금보다 첫 번째 계획을 더 신뢰할 생각이다.
