Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 코딩 과정에서 개발 방향이 흐트러지는 '드리프트'를 방지하기 위해, 프로젝트 시작 전 반드시 정리해야 할 6가지 항목을 제시합니다. PRD, 기술 요구사항(TRD), 화면 흐름 등 체계적인 문서화를 통해 목적과 범위를 명확히 하고 일관성을 유지하는 것이 핵심입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AI 코딩으로 '작동했으니, 다음 기능도'라며 진행하다 보면, 처음에 만들고자 했던 것에서 벗어나게 됩니다. 이러한 드리프트(drift)를 방지하기 위해, 개발 전에 정리해 두면 좋은 것이 6가지 있습니다.
사람 간에는 대화로 보충되던 배경 지식도 AI에게는 말로 공유하고 싶습니다. 구현이 빠를수록 인식의 차이는 커집니다. 목적(目的), 전제(前提), 제약(制約)을 맞추고, 문서는 정본(正本)을 결정하여 연결해야 합니다. 변경 사항이 생기면 관련된 내용도 업데이트합시다. (Anthropic 설명)
아래 6가지는 작은 개발이라면 Markdown 한 장으로 충분합니다. 먼저 작성하고, 만들면서 발전시켜 나갑니다.
PRD(Product Requirement Document, 제품 요구사항 정의서)에는 '누구의 어떤 문제를 해결하며, 어떻게 되어야 성공인가'를 작성합니다. 이는 기능을 추가할 때 판단 기준이 됩니다.
| 번호 | 항목 | 작성 내용 |
|---|---|---|
| 1 | 개요 | 누가, 어떤 과제를 해결하는가. |
| ... | ||
| 예를 들어 '작업 중에 떠오른 태스크를 잊기 전에 기록하고 싶다'는 문제라면, 처음에 만들 것은 등록과 목록 표시로 충분합니다. 팀 공유는 대상에서 제외하고, '설명 없이 30초 이내에 등록 가능'을 가상의 성공 기준으로 삼아 이용자에게 테스트하게 합니다. |
기술 이름 목록뿐만 아니라, 필요한 조건과 그것을 충족하는 설계를 작성합니다. 여기서는 TRD(Technical Requirement Document)나 기술 설계서에 적는 내용을 종합적으로 다룹니다.
| 번호 | 관점 | 작성 내용 |
|---|---|---|
| 1 | 대상・제약 | 웹인지 모바일인지, 대응 환경, 기존 시스템, 예산・체계. |
| ... | ||
| Docs에는 기술의 역할・채택 이유와 설정 파일로의 링크를 남깁니다. 의존 패키지나 버전은 설정・락 파일을 정본으로 하여 이중 관리를 피해야 합니다. |
예를 들어 '통신에 실패해도 등록을 다시 할 수 있다'면, 이렇게 구체화합니다.
성능 역시 단순히 '빠르게 한다'가 아니라, 예상 데이터량・부하・응답 시간을 결정합니다. 필요하다면 구성도나 API 사양을 첨부합시다.
전체에 관련된 선택은 배경・선택지・채택 이유・영향을 ADR (Architecture Decision Record, 아키텍처 결정 기록)에 남깁니다. 이는 '지금 가장 쉬운 방법'이 전체 목적에도 맞는지 되돌아보기 위함입니다. [ADR 작성법]
유저 저니(User Journey)는 이용 전후를 포함한 경험이고, 앱 플로우(Appflow)는 앱 내의 조작과 화면 연결을 의미합니다. 우선 화살표나 목록 형태로 정리합시다. 두 가지의 차이점 [두 가지의 차이점]
태스크 등록이라면, 기본 흐름은 '목록 → 신규 입력 → 저장 → 목록에 반영'입니다. 이 흐름에 분기(branching)와 돌아가는 방법(return path)을 추가합니다.
| 번호 | 관점 | 태스크 등록 예시 |
|---|---|---|
| 1 | 진입점과 도달점 | 목록에서 등록을 시작하여, 저장한 태스크를 확인한다. |
| ... |
시각적인 공통 규칙은 **스타일 가이드(Style Guide)**에 모아둡니다. 경험의 목적이나 화면별 사양은 다음과 같이 나누면 정리하기 쉽습니다. [디자인 브리프 설명]
| 번호 | 자료 명칭 | 작성 내용・표현 방식 |
|---|---|---|
| 1 | 디자인 브리프 | 누구에게 어떤 경험을 전달할 것인가. 문장으로 목적과 제약을 작성한다. |
| ... | ||
스타일 가이드는 Markdown으로도 괜찮으며, DESIGN.md는 작성법・파일 이름의 예시입니다. 예를 들어 '주요 조작 버튼은 같은 색상, 여백은 8px 단위'와 같이 결정합니다. 재사용하는 UI 부품이나 운영 방침까지 정리하면 디자인 시스템으로 이어집니다. |
화면도만으로는 전달되지 않는 동작(behavior)은 화면 사양으로 보충해야 합니다.
## 태스크 등록 화면
- 경험의 목표: 적은 입력으로, 떠오른 태스크를 기록할 수 있다.
- 입력: 제목은 필수. 기한은 선택.
...
이 '재시도 가능한 경험'이 제2장의 중복 등록을 방지하는 설계로 이어집니다.
저장할 정보와 관계・제약을 결정합니다. 관계를 그림으로 그린 것이 **ER 다이어그램(ER図)**이고, 테이블・열・형・제약 등의 정의가 **DB 스키마(DBスキーマ)**입니다. [DB 스키마 설명]
| 번호 | 관점 | 태스크 관리 앱 예시 |
|---|---|---|
| 1 | 데이터와 속성 | 이용자, 태스크, 제목, 기한, 완료 상태. |
| ... | ||
| 화면에 필요한 정보를 꺼낼 수 있는지, 조작으로 무엇이 변하는지 확인하고, 구체적인 타입・키・제약으로 녹여냅니다. |
PRD의 목적을 작업에 녹입니다. 특히, 이번 범위(Scope)를 결정하는 것과, 그 이후 순서를 보여주는 로드맵은 세트로 업데이트하고 싶습니다.
| 번호 | 정리할 것 | 작성할 내용 |
|---|---|---|
| 1 | 스코프(Scope) | 이번에 할 일과 하지 않을 일. 최소한 어디까지 작동해야 가치를 전달할 수 있는지. |
| ... |
태스크 관리의 경우, 먼저 등록 및 목록 표시를 하고, 다음으로 기한이나 필터링을 설정하며, 그 이후는 사용 방식을 보고 결정한다. 권한이나 저장 실패/재시도 확인은 처음부터 완료 조건에 포함시켜야 한다.
추가 기능은 '이번에 할 것인지, 다음으로 미룰 것인지'를 정하고 계획을 업데이트한다. 기간 추정치 역시 검증하면서 재검토해야 한다.
요구사항이나 ADR(Architecture Decision Record)에 대한 참조 위치, 지속적으로 지켜야 할 규칙은 Steering과 같은 지시 파일에서 추적할 수 있도록 해두어야 한다.
중요한 것은 목표 → 경험 → 기술/데이터 → 구현이 연결되는 것이다. 눈앞의 수정이라도 전체적으로 무엇을 목표로 하는지에 되돌아가야 한다.
6가지 구분과 태스크 관리 앱 예시는 본 기사에서의 정리 및 예시이다. 웹 자료 참조일: 2026년 10월 29일.
