06_와이어프레임 & 상세 기획
Antigravity로 PRD 초안을 만들었다. (지난 포스팅 내용)
가능한 상세한 기획을 해두기로 했기 때문에 아직 갈길이 먼 PRD다.
PRD 상태에서 클로드 코드와 MOAI ADK로 넘어 갈까.. 했지만…
Antigravity로 할 수 있는 데까지 세부 기획을 해보기로했다.
(안티그라비티도 사용해보고 싶고, 토큰도 아껴보고 싶고 ㅎㅎ)
1. 홈화면 와이어프레임
PRD에서는 대략적인 와이어 프레임을 요구했는데.. 그래픽 작업이 된 화면 시안을 뽑아줘버렸다.(아직 거기까지는 아니라고…심지어 내가 원하는 디자인 컨셉도 아니었음…)
단순한 도시화 수준의 와이어 프레임으로 화면 구성을 확인하는 것이 우선이라고 판단했다.
또 다양한 경우의 수에 대한 와이어프레임을 가능한 많이 확인하고 싶었다.
그래서 핵심 UX가 제공될 홈화면의 와이어프레임을 다양한 케이스로 나눠서 만들어 달라고 했다.
와이어프레임을 확인하고 다수의 수정할 사항이 보인다.
수정이라기 보다는 기획을 해야되는 것이다.
기획이라하면 목적을 세우고. 목적에 맞는 방안과 다양한 선택지를 검토하고, 필요에 따라 각각의 방안에 맞는 시안도 확인해보고, 방안을 선택하고 그에 맞게 와이어프레임도 수정한다.
상황에 따라서 이미 결정된 방안도 다시 수정하는 경우도 빈번하다.
이런 작업을 위해서….
홈화면관련 논의 사항 리스트를 먼저 만들었다.
2. 홈화면 디스커션 문서
이 두 문서를 켜놓고 채팅으로 LLM과 대화를 하면서 문서를 수정하기를 반복…
왔다리 갔다리 왔다리 갔다리…
하면서 문서를 고도화 시켜나간다.
이 과정은 생각보다 쾌적했다.
AI는 코딩 뿐만 아니라 기획 작업의 페러다임도 바꿔주는 것 같다.
나는 주로 시니어 기획자로서 주니어 기획자와 같이 일을 하는데,
상호 싱크를 맞추는 작업이 사전에 반드시 필요했다.
이작은 대부분 작업하는 방식과 무엇보다 목표와 전략에 대한 합의다.
그러나 이 단계에서 명확히 하더라도 기획을 위한 조사를 하다보면 많은 사항이 변경된다.
이 싱크를 맞춰나가는게 여간 어렵지 않다.
그리고 무엇보다 기획안을 문서화하는 작업과 변경사항을 반영하는 물리적인 작업에 들어가는 시간이 비약적으로 줄어든다.
이런 문서를 빠르게 검토해야 다음 단계로 넘어갈 수 있는데,
병목은 오히려 이런 검토 과정 즉 인간의 작업 영역에서 발생하는 것 같다.
규모가 좀 있는 프로젝트나 레거시가 있는 조직에서는 기획서 작성 방식에도 내부 가이드가 있는 경우가 많다. 혹은 사전에 작업해둔 유사한 포맷의 다수의 기획 문서가 있다면 이런 가이드를 준수 하거나 포맷을 유지하도록 Ai에게 학습을 시킨다면 기획 및 문서 작업은 더욱 효율적일 것이다.
그러나 나의 작업은 처음 부터 시작하는 프로젝트로 레거시가 없다. 기존의 문서들은 다수의 사람들이 사용하기에 적합한 것이라… 나에게 최적화된 문서 뭉치도 없는 편… 지금 당장 가이드를 만들기 보다는 작업을 해가면서 하나씩 나에게 적합한 방식을 세워나가야할 듯 하다.
.
.
.
한편… 승인 하지 않았는데 문서 작업을 막하는 경향이 있다랄까?
요런건 툴사용에 내가 익숙해져야하는 건가?
토글로 이런 상황에 대한 조언도 LLM에게 물어봤더니…
요약하자면 앞으로 안그러겠다는 건데…. 한두번 속았어야지 ㅋㅋ
아래는 LLM의 답변... 궁금하면 눌러보기 ㅋㅋ
사용자님의 지적이 100% 맞습니다. 제가 사용자님의 명시적인 '문서 반영 승인(Approval)' 없이 선제적으로 문서를 수정해버린 것은 AI 에이전트로서 너무 앞서나간(Proactive) 실수였습니다. 불편함을 드려 죄송합니다.
질문하신 **"논의 -> 다수 방안 검토 -> 승인 -> 문서 반영"** 워크플로우는 Antigravity(안티그라비티)를 포함한 최고 수준의 실무자들이 사용하는 **가장 정석적이고 안전한 협업 방식(Best Practice)**이 맞습니다.
실제 성공적인 프로젝트 리더들이 AI 코딩 어시스턴트(에이전트)를 다루는 보편적이고 우수한 워크플로우 팁을 세 단계로 나누어 설명해 드립니다.
### 💡 실사용자들의 우수한 에이전트 활용 팁 (3-Step Workflow)
#### 1단계: 아이디에이션 및 리서치 명령 (Research & Ideate)
* **명령 예시:** "결제 시스템을 붙여야 하는데, 우리 기술 스택(Next.js)과 타겟(국내)에 맞는 방안 3가지를 장단점과 함께 리포트해 줘. **문서는 아직 건드리지 마.**"
* **AI의 역할:** 웹 검색, 기존 PRD 분석 등을 통해 아키텍처/기획 대안을 텍스트로 브리핑합니다.
#### 2단계: 의사결정 및 구체화 (Decision & Refining)
* **명령 예시:** "네가 제시한 2번 방안(토스페이먼츠)이 마음에 들어. 2번 방안으로 갔을 때의 세부 수수료 정책과 DB 저장 구조를 조금 더 상세히 알려줘."
* **AI의 역할:** 선택된 방안에 대한 딥다이브(Deep-dive) 정보를 제공하고, 빈틈이 없는지 논의(Ping-pong)합니다.
#### 3단계: 명시적 문서/코드 반영 지시 (Execution / Commit)
* **명령 예시:** "좋아, 지금까지 논의된 '토스페이먼츠 도입' 및 '비용 구조' 내용을 [inmyrace_PRD.md](cci:7://file:///c:/Users/KHI/allproject/inmyrace/PRD_by_antygrvity/inmyrace_PRD.md:0:0-0:0) 파일의 '수익 모델' 파트에 **업데이트해 줘.**"
* **AI의 역할:** 비로소 사용자의 디렉토리 내에 있는 실제 마크다운(MD) 문서나 소스 코드를 직접 수정(Edit)합니다.
---
### 🔥 에이전트 폭주(?)를 막는 프롬프트 팁 (Pro-Tip)
AI 에이전트들은 기본적으로 "사용자의 문제를 내가 직접 쳐서 빨리 해결해 줘야지!"라는 성향(주도성, Proactiveness)이 강하게 세팅되어 있습니다. 따라서 문서나 코드를 마음대로 건드리는 것을 방지하려면 **첫 프롬프트에 '제약(Constraint)'을 걸어두는 것**이 가장 좋습니다.
* *"우선 논의만 할 거야. 내 승인 전까진 어떤 파일도 수정하지 마."*
* *"방안 A, B, C를 비교해서 표로 보여줘. 선택은 내가 할게."*
* *"Draft(초안)를 짜서 보여주고, 내가 OK 하면 그때 파일에 써 줘."*
### 앞으로의 진행 방식
사용자님의 피드백을 수용하여, 앞으로 남은 기획 및 개발 과정(예: DB 스키마 설계, 구체적인 화면 기능 정의, React 컴포넌트 설계 등)에서는 **반드시 다음 원칙**을 지키겠습니다.
1. 기술적/기획적 문제 발생 시 **여러 대안(옵션)을 먼저 브리핑**합니다.
2. 사용자님께서 **특정 대안을 선택하고 '승인'**하시면,
3. 비로소 제가 **해당 문서를 열어 코드를 수정/반영**하겠습니다.
지금처럼 훌륭한 워크플로우로 저를 리드(Lead)해 주시면, 제가 엉뚱한 방향으로 코드를 엎어버리는 일 없이 최고의 효율을 낼 수 있습니다.
현재 남아있는 구조적 고민거리(예: DB 스키마 초안, 사용자 인증 Flow 구체화 등) 중 어떤 주제에 대해 먼저 "대안 브리핑"을 시작해 볼까요?