기획부터 AI 개발까지, 프로젝트 맥락을 이어가는 방법

AiNecto Blog

2026-10-16

AI로 개발을 빠르게 시작하기 전에 먼저 해야 할 일이 있습니다. 만들려는 서비스의 목표와 사용자, 흐름과 정책을 사람과 Agent가 함께 기획하고, 그 결과를 다음 작업에서 다시 사용할 수 있는 프로젝트 맥락으로 남기는 일입니다.

많은 팀이 기획 문서를 완성한 뒤 개발을 시작한다고 생각합니다. 하지만 실제 기획은 한 번에 끝나는 문서가 아닙니다. 사업 아이디어를 검토하고, 사용자의 문제를 정리하고, 흐름을 그려보고, 요구사항과 정책을 정하면서 조금씩 구체화됩니다.

화면을 만들어보면 문서에서 보이지 않던 질문이 발견되고, 데이터와 API를 설계하면 상태와 권한의 빈칸이 드러납니다. 중요한 것은 매 단계의 결과가 흩어지지 않고 다시 기획의 기준으로 돌아오는 것입니다.

기획 문서부터 Agent와 함께 만듭니다

AiNecto를 사용하기 위해 완성된 기획 문서를 먼저 준비할 필요는 없습니다. 평소 사용하는 Agent에 AiNecto를 연결한 뒤, 만들고 싶은 서비스나 해결하려는 문제를 설명하는 것부터 시작할 수 있습니다.

AGENT에게 이렇게 시작할 수 있습니다

AiNecto에 ‘반려동물 건강관리 서비스’ 프로젝트를 만들어줘.
먼저 이 서비스의 고객, 해결하려는 문제, 제공할 가치와
확인해야 할 위험을 정리한 사업 검토 문서를 만들어줘.
확실하지 않은 내용은 사실처럼 쓰지 말고 질문으로 남겨줘.

Agent가 만든 첫 문서는 정답이 아니라 함께 검토할 출발점입니다. 사람은 실제 고객과 사업의 우선순위를 확인하고, Agent는 수정된 판단을 프로젝트 문서에 반영합니다. 이렇게 정리된 목표와 범위가 이후 다이어그램과 요구사항의 기준이 됩니다.

다이어그램으로 구조와 흐름을 먼저 확인합니다

문장만으로는 서비스의 전체 구조와 빠진 연결을 알아보기 어렵습니다. 사용자와 운영자가 누구인지, 어떤 정보가 이동하는지, 사용자가 목표를 완료하기까지 어떤 단계를 거치는지를 다이어그램으로 그려보면 기획의 빈칸이 더 빨리 보입니다.

이 단계에서 다이어그램은 보기 좋은 장식이 아닙니다. “구매 후 취소는 어디에서 처리하는가”, “전문가 검토가 끝나기 전에 결과를 볼 수 있는가”, “운영자는 어떤 예외를 직접 해결해야 하는가”처럼 요구사항으로 이어질 질문을 발견하는 도구입니다.

문서를 흐름으로 바꾸는 요청

방금 만든 사업 검토 문서를 바탕으로
핵심 사용자와 운영자의 역할을 보여주는 다이어그램을 만들어줘.
사용자가 처음 들어와 목표를 완료할 때까지의 흐름도 함께 그려줘.
흐름이 끊기거나 사람이 결정해야 하는 부분은 질문으로 표시해줘.

기획 문서, 다이어그램과 요구사항은 따로 끝나는 산출물이 아니라 다음 화면과 개발의 기준으로 이어집니다.

요구사항은 문서와 다이어그램 사이에서 구체화됩니다

요구사항은 처음부터 완벽하게 작성되는 목록이 아닙니다. 사업 검토에서 정한 우선순위와 다이어그램에서 발견한 흐름을 함께 보면서 무엇이 첫 번째 버전에 꼭 필요한지 정리합니다.

이때 기능 이름만 나열하지 않고 사용 조건과 완료 조건까지 함께 적는 것이 좋습니다. 누가 사용할 수 있는지, 어떤 정보가 필요한지, 성공하면 무엇이 바뀌는지, 실패하거나 취소하면 어디로 돌아가는지를 확인하면 Agent가 임의로 채워야 하는 빈칸이 줄어듭니다.

• 사용자와 목적: 누가 어떤 일을 끝내려는가
• 시작 조건: 무엇이 준비되어 있어야 하는가
• 주요 흐름: 사용자가 어떤 순서로 행동하는가
• 상태와 권한: 언제 무엇이 바뀌고 누가 볼 수 있는가
• 예외와 복구: 실패·취소·재시도는 어떻게 처리하는가

화면 프로토타입은 기획을 검토하는 도구입니다

기획 문서와 다이어그램, 요구사항이 정리되면 Agent에게 핵심 화면의 HTML 프로토타입을 요청할 수 있습니다. 여기서 목적은 곧바로 제품 코드를 만드는 것이 아니라, 정리한 기획이 실제 사용 장면에서도 자연스럽게 이어지는지 확인하는 것입니다.

기획을 화면으로 확인하는 요청

현재 프로젝트의 기획 문서, 다이어그램과 요구사항을 읽고
핵심 사용자가 목표를 완료하는 HTML 화면 프로토타입을 만들어줘.
처음부터 완료까지 버튼을 눌러 흐름을 확인할 수 있게 하고,
빈 상태, 실패와 취소 상황도 보여줘.
기획에서 정하지 않은 내용은 임의로 확정하지 말고 표시해줘.

화면을 직접 따라가 보면 질문이 구체적으로 바뀝니다. 이 버튼은 누가 볼 수 있는지, 저장 전에 확인이 필요한지, 실패했을 때 입력값을 유지할지, 운영자가 개입해야 하는 시점은 언제인지 확인할 수 있습니다.

사람이 화면에서 빠진 결정을 확인하면 Agent는 그 내용을 요구사항과 다음 작업에 다시 반영합니다.

화면에서 발견한 내용을 다시 기획에 반영합니다

프로토타입 검토가 끝나면 화면만 수정하고 넘어가서는 안 됩니다. 새로 정한 권한, 상태, 예외 처리와 문구를 요구사항과 사용자 흐름에도 반영해야 합니다. 그래야 다음 Agent나 개발자가 화면만 보고 서로 다른 해석을 하지 않습니다.

기획 문서 → 다이어그램 → 요구사항 → 화면 → 사람의 검토 → 기획 업데이트. 이 순환이 반복될수록 프로젝트의 기준은 더 구체적이고 재사용 가능해집니다.

데이터와 API는 기획에서 확인한 결정을 구조로 만듭니다

화면 흐름과 상태, 권한이 확인되면 데이터와 API 설계도 자연스럽게 이어집니다. 화면의 입력 항목을 그대로 테이블로 옮기는 것이 아니라, 계정·주문·동의·검토 같은 핵심 개념이 어떤 관계를 갖고 어떤 상태로 변하는지 살펴본 뒤 ERD를 만듭니다.

OpenAPI도 단순한 코드 생성 파일이 아닙니다. 사용자의 행동과 운영자의 처리를 API 작업으로 옮기면서 입력값, 권한, 오류, 재시도와 충돌 처리의 경계를 확인할 수 있습니다.

이 단계에서도 Agent가 모든 결정을 대신하지는 않습니다. 개인정보, 보안, 고객과의 약속, 결제와 취소 같은 중요한 정책은 사람이 확인하고, Agent는 확인된 결정을 ERD와 API 명세에 일관되게 반영합니다.

이제 Agent가 같은 맥락으로 개발을 이어갑니다

기획과 화면, 데이터와 API가 같은 AiNecto 프로젝트에 연결되어 있으면 개발을 맡은 Agent는 긴 설명을 다시 듣는 대신 현재 기준을 읽고 시작할 수 있습니다. 구현 중 새로운 문제가 발견되면 관련 문서와 화면을 함께 수정하고, 검토된 결과를 다시 프로젝트에 남깁니다.

AiNecto 내부의 아동심리검사 서비스 검증에서도 사업 검토와 인터뷰에서 시작해 IA, 화면 프로토타입, 상태와 권한, ERD와 OpenAPI까지 같은 프로젝트 맥락으로 이어갔습니다. 그 과정에서 운영자 화면의 회원·상품 관리, 보호자 흐름의 검사 선택과 구매처럼 초기에 빠졌던 일을 개발 전에 발견했습니다.

결과적으로 25개 테이블과 35개 관계의 ERD, 86개 경로와 98개 작업의 OpenAPI가 만들어졌습니다. 중요한 것은 숫자가 아니라, 앞에서 확인한 사용자와 정책이 화면·데이터·API에서 같은 의미로 이어졌다는 점입니다.

작은 사용자 흐름 하나부터 시작해보세요

1. 사용 중인 Agent에 AiNecto를 연결하고 새 프로젝트를 만듭니다.
2. 사업 아이디어와 고객 문제를 설명하고 첫 기획 문서를 만듭니다.
3. 사용자와 운영자의 구조, 핵심 흐름을 다이어그램으로 확인합니다.
4. 첫 번째 버전의 요구사항과 중요한 정책을 정리합니다.
5. 화면 프로토타입을 만들어 사람이 직접 흐름을 검토합니다.
6. 확정한 결정을 문서에 반영한 뒤 ERD·API와 개발로 이어갑니다.

처음부터 전체 제품을 설계할 필요는 없습니다. 가입, 구매, 예약처럼 중요한 흐름 하나를 골라 문서와 다이어그램부터 만들어보세요. 사람과 Agent가 확인한 결과를 같은 프로젝트에 계속 남기면, 기획은 개발 앞에서 멈추는 문서가 아니라 다음 작업을 움직이는 기준이 됩니다.

AiNecto · One shared project memory for every person and AI agent.