# 프로젝트 명세는 끝났습니다. 이번 주에는 무엇을 완성할 건가요?

Canonical: https://specscore.md/ko/articles/weekly-delivery/

명세가 완성되어도 프로젝트는 제자리일 수 있습니다. 요구사항은 명확하고 에이전트에게는 계획이 있지만 할 일만 늘어납니다. 어쩌면 더 작은 결정이 빠진 것일 수 있습니다. 이번 주에 어떤 유용한 결과를 완성하며, 그 시간을 마련하려면 무엇을 그만둘 것인가요? 동료, 멘토 또는 노트 한 권과 함께 아래 검토를 진행할 수 있습니다.

## 작업 더미가 아니라 사용자 결과를 선택하세요

인수 기준 하나를 골라 짧은 시연으로 바꾸세요. CSV 가져오기에서 “파서 구현”은 작업을 설명합니다. “사용자가 올바른 파일을 가져오고 레코드를 보며, 잘못된 행에는 유용한 오류를 받는다”는 확인 가능한 결과입니다. 오류 경로도 약속에 포함하세요. 일정 때문에 이를 빼면 약속한 내용이 바뀝니다.

SpecScore는 팀과 에이전트가 읽을 수 있는 파일에 요구사항과 인수 기준을 정리합니다. 주간 메모에서 그 기준을 참조하세요. 올바른 동작의 정의는 명세에 두고, 메모에서는 감당할 수 있는 부분을 선택합니다. 명세의 복사본이나 새로운 프로젝트 관리 시스템은 필요하지 않습니다.

## 실제 일정에 맞춰 시간을 배정하세요

검토와 통합을 포함해 실제로 집중할 수 있는 시간을 적으세요. 이틀 저녁은 근무일 닷새가 아닙니다. 전체 사용자 여정을 테스트하고 예상 밖 문제 하나를 해결할 시간을 남기세요. 결과가 그 안에 들어가지 않으면 시작 전에 더 작지만 완결된 여정을 선택합니다.

통제할 수 없는 의존성도 적으세요. “운영 환경 접근 권한 대기”에는 담당자와 결정 시점이 필요합니다. 수요일에도 권한이 없다면 로컬 시연이 유용할지 결정하세요. 결과를 정확히 구분해야 합니다. 로컬 데모는 운영 준비가 끝났다는 증거가 아닙니다. 금요일에 성공의 정의를 조용히 바꾸지 마세요.

## 에이전트의 작업 범위를 정하고 결정은 맡으세요

어떤 문제가 중요한지 고민하는 동안 에이전트는 여러 구현을 만들 수 있습니다. 그래서 하위 작업을 더 많이 끝내도 원래 목표는 그대로일 수 있습니다. 각 작업에 구체적인 기준, 허용 범위, 제출할 증거를 정하세요. 전체 사용자 여정을 인수할 책임은 한 사람이 맡아야 합니다.

새 아이디어가 떠오르면 자동으로 시작하지 말고 기록하세요. 현재의 어떤 약속을 대체할지 물어보세요. 자신의 최종 검토를 기다리는 결과를 하나로 제한해 볼 수도 있습니다. 이는 집중을 위한 실험이지 보편적 생산성 법칙이 아닙니다. 유용한 일을 늦춘다면 조정하세요.

## 이야기보다 증거를 먼저 검토하세요

검토할 때 실제 산출물부터 여세요. 동작하는 가져오기, 잘못된 입력을 검사하는 테스트, 게시된 문서가 될 수 있습니다. 사용자와 같은 순서로 진행하고 선택한 기준과 비교하세요. 커밋 수, 작업 시간, 자신감 넘치는 에이전트 요약은 배경 정보이지 인수 증거가 아닙니다.

구현된 것, 테스트된 것, 의도한 환경에서 사용자가 이용할 수 있는 것을 구분하세요. 검토자에게 실패할 수 있는 방법 하나를 찾아달라고 요청하세요. 필요한 정보만 공유합니다. 합성 예제나 민감한 정보를 지운 시연으로 충분한 경우가 많습니다. 약속을 점검한다고 고객 데이터, 비밀 정보, 비공개 저장소를 공개할 필요는 없습니다.

## 지키지 못한 약속에는 새로운 결정이 필요합니다

시연이 실패하면 가장 짧고 유용한 설명을 남기세요. 몰랐던 의존성, 과한 범위, 중단된 작업 시간, 틀린 가정 등이 있습니다. 추정 실패를 자신의 인격에 대한 평가로 바꾸지 마세요. 다음 범위를 줄이거나, 의존성을 해결하거나, 접근법을 바꾸거나, 프로젝트를 의도적으로 중단하는 구체적 대응을 선택합니다.

습관적으로 같은 약속을 바꾸지 않은 채 다음 주로 넘기지 마세요. 다음에 관찰할 수 있는 결과와 검토 날짜를 정하세요. 몇 차례 반복한 뒤 예상과 실제 완성된 결과를 비교합니다. 기록의 가치는 더 나은 결정에 있으며, 지켜야 할 연속 성공 기록에 있지 않습니다.

## 복사해서 쓰는 다섯 줄 주간 검토

- 결과: 검토 날짜까지 사용자는 무엇을 할 수 있나요?
- 증거: 어떤 기준과 시연으로 증명하나요?
- 시간: 언제 만들고, 테스트하고, 검토하나요?
- 제약: 무엇을 미루며, 어떤 의존성에 결정이 필요한가요?
- 검토: 누가 언제 결과를 보고, 이후 어떤 결정을 내리나요?

## 내 결정에 다른 사람의 시선을 더하세요

무슨 일이 있었는지 묻고 다음 선택을 함께 살펴줄 사람과 이 메모를 사용하세요. CommittedMe는 사람이 제공하는 멘토링과 약속 점검에 초점을 둡니다. 개발자와 창업자를 위한 페이지에서 이 접근법을 소개합니다. 명세는 저장소에 두고, 기밀 업무를 공개하지 않아도 이야기할 수 있는 목표를 가져오세요.

[CommittedMe 알아보기(영어)](https://committedme.com/en/for/builders/?utm_source=specscore&utm_medium=ecosystem_referral&utm_campaign=committedme_cross_promotion&utm_content=article_footer)

YouTube, TikTok, Instagram 또는 블로그에서 이미 개발자를 가르치고 있나요? 선택의 이유와 테스트를 설명하면 자신의 가정을 발견할 수 있습니다. 다른 사람이 성장하는 동안 그들의 질문은 나도 계속 배우도록 도울 수 있습니다. 이런 대화에 관심이 있다면 멘토 역할을 읽어보세요.

[멘토 역할 알아보기(영어)](https://committedme.com/en/become-a-mentor/?utm_source=specscore&utm_medium=ecosystem_referral&utm_campaign=committedme_cross_promotion&utm_content=article_mentor)

CommittedMe는 같은 생태계의 다른 제품입니다. 이 글은 검토 실천법을 설명하며 SpecScore와의 기술적 통합을 뜻하지 않습니다.

## 결과를 검증 가능하게 만들기

[검증 가능한 인수 기준 작성법](https://specscore.md/ko/articles/acceptance-criteria/)