방향을 정할 때 읽는 글
1단계 사업 검토 요약
문제·고객·해결 방법을 한 편으로 묶은 요약입니다. 단톡방 공지의 무엇이 문제인지가 다섯 줄로 갈라져 적혀 있습니다.
2,582자 · 전문 읽기 →
소규모 기구 필라테스 스튜디오 · 예약과 대기 운영
정원 여덟 명짜리 기구 수업을 단톡방으로 받던 원장이 “대기를 걸어둔 순서대로 가야 맞는데 지켜지지가 않아요”라고 적어 냈습니다. 그 한 문장이 대기 순번·응답 마감·회원권 차감 예외까지 규칙으로 정리되어, 실제로 도는 서비스까지 갔습니다. 넷 중 처음으로 수정 요청이 화면에 반영되는 데까지 끝까지 간 사례입니다.
동네에서 소규모 기구 필라테스 스튜디오를 2년째 혼자 운영하는 원장. 개발자는 없고 예약은 단톡방, 노쇼 기록은 수첩에 있습니다.
들어간 것
아래는 손대지 않은 원문입니다. 개발 용어는 한 마디도 없고, 그 일을 하며 겪는 것만 적혀 있습니다.
동네에서 소규모 필라테스 스튜디오를 2년째 하고 있습니다. 기구 수업이라 한 타임에 여덟 명이 최대인데 예약은 아직 단톡방으로 받습니다. 제일 힘든 게 취소예요. 수업 두세 시간 전에 취소가 나오면 제가 단톡방에 "자리 하나 났어요" 하고 올리는데, 늦게 본 사람은 이미 찼냐고 다시 묻고 결국 빨리 본 사람만 계속 가져갑니다. 대기를 걸어둔 순서대로 가야 맞는데 지켜지지가 않아요. 회원권이 10회 20회 이런 횟수제라서 취소 시점에 따라 횟수를 깎을지 말지를 제가 매번 손으로 판단하는 것도 일입니다. 수업 12시간 전까지는 안 깎는 게 원칙인데 11시간 남기고 취소한 분이 사정을 얘기하면 봐주게 되고, 그러면 나중에 다른 회원이 알고 서운해합니다. 노쇼도 남겨두고 싶은데 지금은 제 수첩에만 있습니다.
나온 것
전문을 그대로 읽을 수 있습니다. 요약본이 아니라 실제로 AI 개발 에이전트에게 넘어간 원본입니다.
사람이 손댄 곳은 이게 전부입니다
전체 모습을 볼 때 읽는 글
무엇을 만드는지, 누가 쓰는지, 첫 개발의 완료 기준이 무엇인지 한 편으로 묶었습니다.
16,173자 · 전문 읽기 →
만들 사람이 기준으로 삼는 문서
요구사항마다 주체·시작 조건·정상 흐름·예외 흐름·완료 조건을 적었습니다. 12시간 기준과 그 예외를 어떻게 남기는지가 여기 있습니다.
20,886자 · 전문 읽기 →
화면을 그릴 때 읽는 문서
화면 10개가 각각 무슨 일을 맡고 어디서 어디로 이어지는지 적었습니다. 문자 링크로 들어온 사람이 인증 뒤 원래 보려던 화면으로 돌아가는 길도 여기 있습니다.
20,981자 · 전문 읽기 →
데이터를 다룰 때 읽는 문서
가장 두꺼운 문서입니다. 예외를 봐준 기록을 원본 위에 덮어쓰지 않고 따로 남기는 구조가 여기서 나왔습니다.
34,665자 · 전문 읽기 →
화면과 서버를 이을 때 읽는 문서
어떤 요청이 오가고 무엇이 돌아오는지, 무엇이 아직 안 정해졌는지 적었습니다.
25,706자 · 전문 읽기 →
전체 얼개를 볼 때 읽는 문서
화면·서버·저장소가 각각 무엇을 맡는지 적었습니다.
11,655자 · 전문 읽기 →
보이는 것을 정할 때 읽는 문서
“남은 시간만 보여 주지 말고 날짜가 포함된 마감 시각을 같이 적는다” 같은 기준이 여기 있습니다. 본문 최대 폭 1280px 도 여기서 정해졌습니다.
13,507자 · 전문 읽기 →
개발 전에 사람에게 물어야 하는 것
문서가 정할 수 없어 사람에게 넘긴 것들입니다. 발신 번호 권한처럼 원장이 밖에서 처리해야 하는 것까지 누구에게 물어야 하는지 적혀 있습니다.
1,166자 · 전문 읽기 →
화면 목록
이 목록이 다음 단계 목업의 원본이 되고, 그대로 개발로 넘어갑니다. 여기 없는 화면은 만들어지지 않습니다.
회원용 휴대폰 인증 화면
회원이 휴대폰 번호와 인증번호로 본인 확인을 한다.
회원용 수업 목록·예약·대기 신청 화면
회원이 수업을 골라 예약하거나 대기를 신청한다.
회원용 내 예약·대기 순번·취소 화면
회원이 본인 수업의 예약·대기 순번을 확인하고 취소한다.
문자 링크에서 여는 빈자리 수락 화면
대기 회원이 빈자리를 수락하거나 응답하지 않는다.
원장용 날짜별 수업·예약 인원·대기 현황 화면
원장이 날짜별 수업과 예약 인원, 대기 현황을 관리한다.
원장용 회원별 회원권 횟수·취소 예외·노쇼 기록 화면
원장이 회원별 회원권 횟수, 취소 예외, 노쇼 기록을 확인하고 처리한다.
원장용 수업 등록·수정 화면
원장이 수업 날짜, 시작·종료 시각, 수업명, 정원 5~15명, 예약·대기 가능 상태를 등록하고 수정한다.
원장용 빈자리 수락 승인 화면
회원의 빈자리 수락 내용, 회원권 잔여 횟수, 예외 여부, 응답 시각, 승인 대기 좌석을 확인하고 최종 승인 또는 반려한다.
원장용 오류 수정·조정 이력 화면
중복 예약, 대기 순서 누락, 잘못된 취소·노쇼·회원권 횟수 처리를 찾고 원본 기록을 보존한 채 수정 사유와 조정 이력을 남긴다.
원장용 회원·회원권 초기 등록 화면
기존 회원의 이름과 휴대폰 번호를 등록하고 서비스 밖에서 결제한 횟수제 회원권의 총 횟수, 잔여 횟수, 시작일, 만료일을 입력한다.
만들어진 것
실제로 도는 서비스입니다. 앞선 세 사례는 저장소에 연결되기 전 단계의 화면이라 데이터가 샘플이었지만, 여기 화면은 실제 데이터베이스에 들어 있는 기록을 읽어 그린 것입니다. 예약을 누르면 저장되고, 다시 열면 그대로 있습니다.
수정 요청을 전달한 뒤 반영된 화면까지 20분
9월 1일 세 수업이 시간순으로 놓여 있습니다. 10:00 모닝 리포머는 정원 8명에 6명, 19:00 그룹 리포머는 8명이 다 차고 대기가 2명입니다. 처음 적어 낸 글의 “한 타임에 여덟 명이 최대인데 예약은 아직 단톡방으로 받습니다”가 여기까지 왔습니다. 위쪽 거르개가 ‘처리 필요·대기 있음·빈자리 있음·승인 대기’로 나뉘어 있는 것은, 원장이 수업 사이에 휴대폰으로 볼 것을 먼저 본다는 디자인 가이드의 기준에서 나온 것입니다.

만석인 19:00 수업의 대기열입니다. 1번 최민재는 8월 30일 20:00 에, 2번 김수아는 같은 날 21:14 에 신청했습니다. 신청한 시각 순서가 그대로 순번이고, 등록 순번 2001·2002 가 함께 남아 있어 나중에 순서를 두고 말이 갈리지 않습니다. “대기를 걸어둔 순서대로 가야 맞는데 지켜지지가 않아요”라는 처음 문장이 이 화면 하나로 답이 됐습니다. 휴대폰 번호는 010-27**-**44 처럼 가려져 있는데, 이것도 개발문서가 정한 것입니다.

같은 19:00 수업을 회원 쪽에서 연 것입니다. “현재 내 대기 순번 2번 · 전체 2명” 이라고 적혀 있고, 원장 화면의 2번 김수아와 같은 사람입니다. 맨 위에는 “20회 회원권 잔여 14회”가 함께 있습니다. 눈여겨볼 것은 마감 표시입니다. 19:00 수업의 무료 취소 마감이 ‘2026년 9월 1일 07:00’ — 정확히 12시간 전으로, 남은 시간이 아니라 날짜가 붙은 시각으로 적혀 있습니다. “수업 12시간 전까지는 안 깎는 게 원칙인데”라는 처음의 문장이 규칙이 되어 화면에 박힌 자리입니다.

위 그림은 실제로 떠 있던 화면을 그대로 찍은 것입니다. 데모가 떠 있는 동안에는 위 버튼으로 직접 들어가 볼 수 있고, 자리가 옮겨 가면 버튼은 사라집니다.
고쳐 가는 과정
화면이 나온 뒤에 눈에 띄는 곳을 말로 적어 보내면, 검토를 거쳐 반영됩니다. 아래는 이 사례에서 실제로 오간 것을 그대로 옮긴 것입니다.
화면이 만들어져 떠 있었고 휴대폰 폭에서는 멀쩡했습니다. 그런데 노트북으로 열면 글이 한 글자씩 세로로 흐르고, 카드가 손가락만큼 좁은 기둥이 되어 아래로 한참 늘어났습니다. 오른쪽은 넓게 비어 있었습니다.
보낸 요청
노트북과 데스크톱에서 열면 글이 한 글자씩 세로로 흐르고, 카드가 손가락만큼 좁은 기둥이 되어 아래로 한참 늘어납니다. 오른쪽은 넓게 비어 있는데 본문만 왼쪽 220px 정도 되는 칸에 갇혀 있습니다. 원장용 화면과 회원용 화면 모두 그렇습니다. 휴대폰 폭으로 줄이면 오히려 읽을 만합니다.
돌아온 검토
요청한 수정은 기존 서비스 목표와 화면 목적에 맞습니다. 문서에 별도의 왼쪽 메뉴가 명시되어 있지 않으므로 빈 메뉴 영역을 위해 공간을 남기지 않고 본문이 사용 가능한 너비를 쓰도록 수정하는 것이 적절합니다. 데스크톱에서는 관련 카드가 여러 열로 배치되고, 휴대폰에서는 현재처럼 한 열로 읽을 수 있어야 합니다.
바뀐 것 · 본문 폭이 220px 에서 1280px 로 돌아왔습니다. 디자인 가이드가 처음부터 ‘최대 콘텐츠 폭 1280px’ 이라고 정해 두었던 값입니다. 덧붙일 것이 있습니다. 이 수정은 한 번 반영된 뒤 다시 사라졌습니다. 고친 코드를 기준 코드로 합치려다 다른 파일에서 겹침이 생겼는데, 그때 “처음부터 다시 만듭니다”라고만 적고 그 수정 없이 다시 만들어 배포했습니다. 화면은 멀쩡히 떠 있었기 때문에 아무도 몰랐습니다. 지금은 합치지 못하면 멈추고 그 사실을 화면에 띄웁니다. 없어진 줄 모르는 것보다 멈추는 편이 낫다고 보았습니다.
기능이 다 붙고 실제 데이터베이스에 연결된 뒤에 열어 보니, 원장으로 시작을 누르자마자 오류 문구가 떴습니다. 화면 맨 위에 적힌 시험용 번호로 회원 로그인을 해도 “등록되지 않은 휴대폰 번호입니다”가 나왔습니다. 열어 볼 수 있는 화면이 하나도 없었습니다.
보낸 요청
원장으로 시작을 누르면 수업 현황 화면에서 "현재 선택한 기구 필라테스 스튜디오 정보를 찾을 수 없습니다" 가 뜹니다. 다시 불러오기를 눌러도 같습니다. 회원으로 시작해서 화면에 적힌 번호 010-1234-5667 을 넣으면 "등록되지 않은 휴대폰 번호입니다" 가 뜹니다. 화면 맨 위에는 그 번호로 들어가면 된다고 적혀 있는데 정작 들어가지지 않습니다. 수업도 회원도 하나도 없어서 아무 화면도 열어볼 수가 없습니다.
돌아온 검토
원장 화면은 스튜디오 연결 정보가 없어 열리지 않고, 회원 화면은 안내된 테스트 번호가 등록되지 않아 핵심 흐름 전체를 확인할 수 없는 상태입니다. 검토를 막는 오류이므로 우선 복구해야 합니다. 다만 예시 데이터는 실제 운영 데이터와 분리된 데모 스튜디오에만 만들고, 배포 과정에서 기존 기록을 삭제하거나 덮어쓰지 않도록 범위를 조정해야 합니다. (되물은 것) 미리보기 환경은 앞으로 실제 운영 기록도 함께 입력하는 공간인가요, 아니면 실제 운영과 완전히 분리된 데모 전용 공간인가요? (되물은 것) 화면에 안내된 테스트 번호는 실제 문자를 받는 번호인가요, 아니면 미리보기에서만 고정 인증번호를 사용하는 테스트 번호인가요?
바뀐 것 · 검토는 바로 고치러 가지 않고 두 가지를 되물으며 막았습니다. 답을 달자 세 번째로 되물었고, 그 사이 “고정 인증번호를 설정으로 끄고 켤 수 있으면 좋겠다”는 이쪽 제안을 되밀었습니다. 화면 설정으로 인증을 끄고 켜면 실서비스에서 인증이 우회될 수 있으니 서버 설정으로만 갈라야 한다는 것이었습니다. 맞는 지적이라 그대로 따랐습니다. 답이 다 모이자 “개발문서에 없던 것을 새로 만드는 요청이라 범위를 먼저 정해야 합니다”라며 범위 상담으로 넘겼고, 정해진 범위가 개발문서에 반영된 뒤에야 개발로 전달됐습니다. 원인은 만드는 쪽에 있었습니다. 배포 환경은 데이터 구조 변경만 실행하는데, 개발 지시서는 그와 별개로 “시드 스크립트로 데모 데이터를 채우라”고 시키고 있었습니다. 한 자리에서 두 가지를 다르게 말한 것입니다. 그래서 556줄짜리 시드 파일이 만들어졌고, 그 파일은 한 번도 실행되지 않았습니다. 지금은 처음 보일 데이터를 데이터 구조 변경에 함께 넣도록 시키고, 여러 번 돌아도 결과가 같아야 하며 이미 쌓인 기록은 지우지 못하게 못 박았습니다.
가입하면 사업 검토 5회를 먼저 드립니다. 개발문서까지 만들어 본 뒤에 개발을 결정해도 됩니다.