사용자와 작은 문제

누구의 어떤 어려움을 줄이는가

AI에게 “학습 앱을 만들어 주세요”라고 요청하면 실행 가능한 파일을 빨리 받을 수도 있습니다. 그러나 파일이 열리는 것만으로 오늘 해야 할 공부를 기록하고 끝낸 일을 구분할 수 있는지는 알 수 없습니다. 교육 담당자가 신입에게 먼저 확인하는 것은 도구 이름보다 사용자의 하루입니다. 사용자가 언제 무엇을 하고 어떤 결과를 확인하려는지 말할 수 있어야 구현 결과를 판단할 기준이 생깁니다.

이 트랙의 사용자는 혼자 공부하는 개인입니다. 공부를 시작할 때 “조건문 복습”을 적고, 끝낸 뒤 완료 표시를 하고, 목록에서 남은 일을 확인하려 합니다. 지금의 어려움은 메모에 적힌 제목과 실제 완료 상태가 섞여 있다는 점입니다. 따라서 첫 목표는 학습 할 일의 생성·조회·완료 세 행동을 일관되게 제공하는 것입니다. 추천 학습 계획이나 팀 협업을 이번 목표에 포함하지 않습니다.

사용자 이야기는 사용자, 상황, 행동, 얻을 결과를 연결한 짧은 설명입니다. “개인 학습자로서 공부 시작 전에 할 일을 적어, 끝난 일과 남은 일을 구분하고 싶습니다”라고 적습니다. 이 설명은 모든 세부 규칙을 담는 문서가 아닙니다. 구현이 필요한 이유를 남기는 출발점입니다. 다음 레슨에서 제목 길이와 식별자 같은 결과를 가르는 선택을 계약으로 보완합니다.

신입이 자주 쓰는 “누구나 편하게 사용합니다”는 대상과 관찰할 행동이 빠져 있습니다. 편하다는 평가를 버릴 필요는 없지만 첫 작업에서는 관찰 가능한 문장으로 바꿉니다. “제목 하나를 추가하고 반환된 번호로 완료한 뒤 목록에서 완료 여부를 확인합니다”라면 확인자가 같은 절차를 따라갈 수 있습니다. 사용자의 직업이나 나이를 불필요하게 상상하기보다 입력과 확인 행동에 영향을 주는 상황을 적습니다.

사용자가 하는 행동과 프로그램을 만드는 사람이 하는 행동도 구분합니다. 개인 학습자는 공부할 일을 추가합니다. 개발자는 명세를 작성하고 예시의 기대 결과를 확인합니다. “개발자가 테스트를 통과하고 싶습니다”는 작업 목표이지만 학습자의 문제를 설명하지 못합니다. 사용자 이야기에 검증 담당자의 편의를 섞으면 쓰기 쉬운 앱보다 테스트하기 쉬운 앱만 만들 위험이 있습니다.

작게 만드는 범위의 기준

범위는 이번 결과에 포함할 행동의 목록입니다. 이 프로젝트는 생성, 전체 조회, 식별자로 완료를 포함합니다. 생성된 항목은 번호, 정리된 제목, 완료 여부를 갖습니다. 시작할 때 목록은 비어 있고 실행 중 메모리에 유지됩니다. 이런 선택을 적으면 첫 앱을 완성하기 전에 데이터베이스나 계정 관리까지 고민하는 일을 줄일 수 있습니다. 기능마다 사용자가 어떤 결과를 볼지 한 줄씩 붙여 작성합니다.

제외 범위는 이번에 만들지 않기로 결정한 행동입니다. 로그인, 영속 저장, 삭제, 제목 수정, 마감일, 배포, 화면 디자인을 제외합니다. 제외했다는 말은 그 기능이 쓸모없다는 뜻이 아닙니다. 이번 학습 목표를 확인하는 데 필요하지 않아서 뒤로 미루는 결정입니다. “간단하게”라는 형용사 대신 이 목록을 적어 두면 AI가 멋진 화면이나 저장 기능을 추가하더라도 범위 밖임을 설명할 수 있습니다.

상태를 어디까지 유지하는지는 사용자 기대를 크게 바꿉니다. 지금은 재시작하면 할 일이 사라집니다. 이 사실을 사용자 시나리오에 적어 두어야 데이터를 보존하는 학습 기록 도구로 오해하지 않습니다. 개인 정보나 실제 장기간 계획을 이 실습에 넣지 않고 예제 제목만 사용합니다. 메모리 상태로 세 행동을 익힌 뒤에도 영속 저장은 이 트랙 프로젝트의 제외 범위로 남습니다.

범위를 작게 만드는 데에는 연결된 행동을 함께 보는 판단이 필요합니다. 생성만 있고 조회가 없으면 추가 결과가 목록에 남았는지 확인하기 어렵습니다. 완료만 있고 번호를 얻는 행동이 없으면 어떤 항목을 완료할지 설명하기 어렵습니다. 따라서 첫 명세는 세 행동을 함께 정의합니다. 구현은 이후 모듈에서 나누어 진행하므로 모든 기능을 한 번의 AI 요청으로 작성할 필요는 없습니다.

초기 이야기에는 “같은 제목은 하나만 허용하나요?” 같은 미결정 사항이 생깁니다. 이 질문은 결과를 바꾸므로 결정 기록에 남깁니다. 이번 계약에서는 같은 제목도 서로 다른 항목으로 허용합니다. “함수 이름을 무엇으로 할까요?”는 사용자 결과를 바꾸지 않는 내부 선택이므로 같은 수준의 요구사항으로 늘리지 않습니다. 아직 판단할 자료가 없으면 미확인이라고 쓰고 구현 전에 확인할 항목을 지정합니다.

문서를 실제 작업으로 연결하기

명세 파일은 대화의 요약을 저장하는 곳을 넘어 다음 사람이 구현을 시작할 기준입니다. 미션 starter의 spec.md를 열어 사용자와 목적, 범위, 제외 범위를 채웁니다. 사용자와 목적에는 앞서 만든 이야기와 재시작 시 초기화되는 제약을 적습니다. 범위에는 R1 생성, R2 조회, R3 완료처럼 식별자를 붙입니다. 이 번호는 뒤에서 사례와 확인 방법을 연결할 때 사용합니다.

요구사항 번호는 문서 위치가 바뀌어도 의미를 찾기 위한 표식입니다. R1을 “예쁜 화면”처럼 여러 판단이 섞인 말로 정하지 않고 “유효한 제목으로 미완료 항목을 생성합니다”로 씁니다. R2는 “전체 목록을 생성 순서로 조회합니다”, R3은 “식별자로 지정한 항목을 완료합니다”로 적습니다. 조건이 늘어나면 사례에서 어떤 요구를 확인하는지 한 번 더 대조할 수 있습니다.

문서를 다 쓴 뒤 사용자 행동을 소리 내어 따라가 봅니다. 비어 있는 목록에서 제목을 추가하면 어떤 번호를 얻는지, 그 번호를 완료하면 무엇을 보는지, 다시 조회하면 어떤 값이 남는지 질문합니다. 답이 나오지 않는 부분은 코드를 작성해서 추측할 자리가 아니라 다음 레슨에서 입력과 출력으로 정할 자리입니다. 한 장을 길게 채우기보다 중요한 빈칸을 발견하는 데 목적을 둡니다.

AI는 초안을 검토하는 역할로 사용할 수 있습니다. “사용자 이야기와 범위를 읽고 결과가 달라질 모호한 점을 세 개 이하로 알려 주세요. 저장과 로그인은 제외되어 있습니다”라고 요청합니다. AI 도구가 없어도 제공된 명세와 직접 비교하여 같은 작업을 합니다. AI가 추천한 기능은 곧바로 범위에 넣지 않고 사용자의 목적에 필요한지 본인이 결정합니다. 결정한 이유를 한 문장으로 남기면 다음 세션에도 선택을 이해할 수 있습니다.

흔한 실수는 기능 목록만 있고 사용자가 확인할 결과가 없는 문서입니다. 이 문서에는 프로그램 오류 메시지가 아직 나오지 않으므로 “결과를 알 수 없습니다”라는 검토 의견 자체가 보완 신호입니다. 문서 검사에서 TODO가 남았다고 나오면 임의로 단어만 지우지 말고 결정한 내용이나 미확인 사항으로 바꿉니다. 파일을 찾지 못한다면 내려받은 폴더와 파일 이름을 먼저 확인합니다. 명세의 내용과 실행 환경의 문제를 분리해서 읽습니다.

이번 레슨의 제출물은 사용자 이야기 한 문장과 포함·제외 기능표입니다. 후속 계약의 세부 사항을 미리 전부 구현할 필요는 없습니다. 생성·조회·완료를 통해 무엇을 해결하는지, 재시작 시 상태가 사라진다는 점, 어떤 요구가 이번 범위 밖인지 설명할 수 있으면 목표를 수행한 것입니다. 일반적인 AI 요청 작성 원리는 더 읽기에서 확인하고 여기서는 자신의 프로젝트 결정에 집중합니다.