투자자와 심사위원
- 말로만 있을 때
- 가정을 놓고 평가합니다. “그래서 진짜 되나요?”
- 눌러 볼 수 있을 때
- 직접 열어 보고 실행력으로 평가합니다.
플랫폼 소개
‘개발’을 몰라도,
눌러 볼 수 있는 서비스까지.
이 페이지는 개발을 한 번도 해 본 적 없는 분을 위해 썼습니다. 서버, 배포, API 같은 말을 몰라도 괜찮습니다. 왜 만들어 봐야 하는지부터, 아이디어가 접속 가능한 주소가 되기까지 무슨 일이 일어나는지 적어 두었습니다.
왜 만들어 봐야 하나
말로 설명할 때와 직접 눌러 보게 할 때, 상대의 반응은 다릅니다.
아이디어가 좋은지 나쁜지는 설명만으로 판가름 나지 않습니다. 직접 써 볼 수 있는 것이 있으면, 대화의 기준이 가정에서 사실로 옮겨 갑니다.
고객
- 말로만 있을 때
- 관심은 생겨도 써 볼 수가 없습니다.
- 눌러 볼 수 있을 때
- 가입하고 써 본 뒤 진짜 반응을 남깁니다.
같이 일하는 사람
- 말로만 있을 때
- 같은 말을 듣고 각자 다른 화면을 상상합니다.
- 눌러 볼 수 있을 때
- 같은 화면을 보며 같은 곳을 고칩니다.
나 자신
- 말로만 있을 때
- 맞는지 틀린지 알 방법이 없습니다.
- 눌러 볼 수 있을 때
- 어디서 막히는지 눈으로 확인됩니다.
배포가 뭔가요
식당을 여는 일과 같습니다.
개발에서 쓰는 말은 낯설 뿐이지 어려운 개념이 아닙니다. 아는 것으로 바꿔 보면 이렇습니다.
코드
레시피
무엇을 어떻게 만들지 적어 둔 글입니다. 글만으로는 아무도 먹을 수 없습니다.
서버
주방
내 노트북이 아니라, 24시간 켜져 있는 다른 컴퓨터입니다. 여기서 서비스가 실제로 돌아갑니다.
배포
개업
손님이 들어올 수 있게 문을 여는 일입니다. 이것이 ‘배포’입니다.
주소(URL)
가게 주소
누구나 찾아올 수 있는 인터넷 주소입니다. 링크를 보내면 바로 들어옵니다.
그래서 제가 정할 것은 어디까지인가요
아래 표의 가운데 칸만 답하시면 됩니다. ‘없음’으로 적힌 줄은 신경 쓰지 않으셔도 됩니다.
| 말 | 내가 정할 것 | 시스템이 할 일 |
|---|---|---|
| 프론트엔드 — 눈에 보이는 화면 | 어떤 화면이 필요한지 | 화면 목록과 눌러 볼 수 있는 목업 |
| 백엔드 — 화면 뒤에서 저장하고 계산하는 부분 | 무엇을 기록해 두어야 하는지 | 기능과 데이터 설계, 구현 |
| 데이터베이스 — 정보를 담아 두는 창고 | 어떤 정보를 남길지 | 저장 구조 설계와 구현 |
| 서버 — 항상 켜져 있는 컴퓨터 | 없음 | 준비와 실행 |
| 배포 — 인터넷에 문을 여는 일 | 없음 | 자동으로 진행 |
| 빌드·점검 — 코드를 돌아가는 형태로 조립하고 확인하는 일 | 없음 | 자동으로 진행 |
| 도메인 — 서비스의 인터넷 주소 | 원하는 이름 (운영 단계에서) | 확인용 미리보기 주소 제공 |
| MVP — 가설을 확인하기 위한 최소한의 서비스 | 무엇부터 확인할지 | 범위 제안과 구현 |
진행 순서
여섯 단계로 나뉩니다
필요한 단계만 골라도 됩니다. 앞을 건너뛰면 다음 단계가 그것을 감안해서 묻습니다.
01선택
Ideation
사업 검토
아이디어를 여러 갈래로 펼쳐 보고, 누구의 어떤 문제를 푸는지 항목별로 정리합니다.
Ideation 자세히 보기 →02선택
Planner
사업계획서
심사와 설명에 쓸 사업계획서·신청서·발표 자료를 만들고, 여러 관점으로 다시 봅니다.
Planner 자세히 보기 →03핵심
DevDocs
개발문서
기능·화면·데이터·완료 기준을 개발이 그대로 따라갈 수 있는 문서로 만듭니다.
DevDocs 자세히 보기 →04
Builder
화면과 웹 개발
화면 목업을 확인한 뒤, 실제로 눌러 볼 수 있는 웹 서비스와 접속 주소를 준비합니다.
Builder 자세히 보기 →05
Manager
직접 써 보고 수정
직접 써 보고 불편한 곳을 말하면 문서 근거와 함께 고칩니다.
Manager 자세히 보기 →06선택
전문 개발자 참여
실제 사용자를 받기 전에 사람이 코드를 살피고 외부 연동과 인수를 맡습니다.
주소가 열리기까지
승인을 누른 뒤에 일어나는 일
여섯 가지 중 내가 하는 것은 처음과 마지막 둘뿐입니다. 나머지는 기다리시면 됩니다.
- 01내가 함
목업 승인
화면과 흐름을 눌러 보고 “이대로 만들어 주세요”를 누릅니다.
- 02자동
AI 개발
승인한 목업과 개발문서를 기준으로 실제 코드를 작성합니다.
- 03자동
코드 보관
작성된 코드가 온라인 코드 보관함에 기록으로 쌓입니다.
- 04자동
자동 점검·조립
코드가 실제로 돌아가는 형태로 조립되고, 문제가 없는지 검사합니다.
- 05자동
배포 서버 실행
점검을 통과한 결과물을 늘 켜져 있는 서버가 받아 실행합니다.
- 06내가 함
내 주소 열림
브라우저 주소창에 넣으면 바로 열리는 미리보기 주소를 받습니다.
다른 방법과의 차이
만드는 방법은 여럿입니다.
어느 쪽이 절대적으로 낫다는 뜻은 아닙니다. 지금 가진 자원과 감당할 수 있는 범위에 따라 답이 달라집니다.
| 외주 개발사 | 개발자 합류 | 노코드 도구 | AI 코딩 도구 직접 | 프로메테온 | |
|---|---|---|---|---|---|
| 시작하려면 필요한 것 | 정리된 요구사항과 예산 | 함께할 사람과 지분·급여 조건 | 도구 사용법을 익힐 시간 | 도구 설치·계정·실행 환경 | 아이디어 한 문장 또는 기존 사업계획서 |
| 내가 알아야 하는 것 | 원하는 것을 개발 용어로 설명하는 법 | 기술 판단이 맞는지 확인할 기준 | 도구 안에서의 화면 구성과 연결 | 프롬프트, 오류 읽기, 서버와 배포 | 내 사업에 대한 답. 개발 지식은 필요 없음 |
| 비용이 정해지는 방식 | 견적 단위. 범위가 바뀌면 재협의 | 인건비 또는 지분. 매달 발생 | 월 구독료. 사용자가 늘면 증가 | 쓴 만큼 사용량 요금 | 단계별 정액. 시작 전에 확인 |
| 방향이 틀렸을 때 | 변경마다 추가 비용과 일정 협의 | 사람의 여유에 따라 달라짐 | 도구가 지원하는 범위 안에서는 빠름 | 매번 처음부터 다시 설명해야 함 | 문서와 화면을 근거로 수정 요청 |
| 끝났을 때 남는 것 | 완성된 서비스. 이후 수정은 다시 의뢰 | 팀과 코드. 다만 사람에 의존 | 그 도구 안에서만 도는 서비스 | 코드만 남고, 왜 그렇게 만들었는지는 남지 않음 | 사업계획서·개발문서·목업·작동하는 서비스·소스 코드 |
개발 범위 사전 점검
안 된다고 끝내지 않고, 가능한 개발 경로를 먼저 찾습니다.
자동 개발에 바로 맞는 범위는 곧바로 진행하고, 추가 조건이 있으면 상담을 통해 필요한 계약·자료·전문가 역할을 정합니다. 실제 개발 전에 확인하므로 뒤늦게 전부 다시 만드는 위험도 줄어듭니다.
01
바로 개발
현재 자동 개발 방식에 잘 맞는 웹 서비스는 승인한 문서와 목업을 기준으로 곧바로 만듭니다.
02
상담 후 개발
외부 API, 앱, 고난도 디자인처럼 준비 조건이 있는 경우 계약·자료·전문가 역할을 먼저 정하고 개발을 이어갑니다.
03
범위 조정 후 재검토
현재 방식과 맞지 않는 부분은 가능한 웹 범위나 전문 개발 경로를 제안하고, 정리된 범위로 다시 확인합니다.
잘 맞는 것
이런 서비스를 만들기 좋습니다.
아이디어를 확인하는 첫 서비스
핵심 고객이 실제로 쓸 기능부터 골라 웹으로 만들고 반응을 봅니다.
신청·예약·문의 같은 업무 흐름
사용자가 넣고 운영자가 확인·처리하는 반복 업무를 화면과 관리 기능으로 잇습니다.
회원마다 달라지는 화면
로그인, 내 정보, 진행 상태, 결과 확인처럼 사람마다 다른 것을 보여 주는 서비스.
이미 쓴 사업문서가 있는 개발
사업계획서·발표 자료·화면 그림을 올리면 그 의도를 잃지 않게 개발문서로 옮깁니다.
먼저 이야기할 것
이런 것은 시작 전에 범위를 먼저 정합니다.
안 된다는 뜻이 아니라, 무엇이 변수가 되는지 미리 알고 시작하자는 뜻입니다.
심미적 요소가 매우 중요한 시스템
자동화 개발은 정해진 디자인 가이드를 일관되게 구현하는 데 강합니다. 반면 독창적인 아트 디렉션·브랜드 감성·고유 그래픽·복잡한 움직임처럼 주관적 판단과 반복 조율이 핵심이면 자동화만으로 기대 수준을 맞추기 어렵습니다. 브랜드 자료나 디자이너 결과물을 준비해 상담하면 역할과 범위를 정해 개발로 연결할 수 있습니다.
앱스토어 출시와 기기 기능
앱 화면과 개발문서는 준비할 수 있지만, 카메라·푸시 알림 같은 기기 기능과 앱스토어 심사는 별도로 협의합니다.
결제·지도·문자 같은 외부 연동
업체 계약과 심사, 사용료가 걸려 있습니다. 계정 상태를 확인한 뒤 범위를 정합니다.
장애가 크게 번지는 서비스
의료·금융 판단, 대규모 실시간 처리처럼 잘못됐을 때 영향이 큰 것은 전문 검증이 따로 필요합니다.
디자인은 왜 따로 이야기하나요
기능은 문서로 정확히 옮길 수 있지만, 브랜드는 취향이 걸립니다. 말로만 주고받으면 서로 다른 것을 상상하게 됩니다.
무엇을 준비하면 좋나요
로고와 브랜드 가이드, 좋아하는 사례와 피하고 싶은 사례, 직접 그린 스케치. 구체적일수록 정확해집니다.
어떻게 진행하나요
핵심 화면의 방향을 목업으로 먼저 확인하고 승인합니다. 고유 그래픽과 복잡한 움직임은 범위와 비용을 따로 정합니다.
자료가 전혀 없다면요
업계 조사와 기본 디자인 계약으로 기능 중심의 첫 버전을 만들 수 있습니다. 심미적 완성도가 사업의 핵심이라면 상담을 통해 디자이너가 맡을 부분과 자동 개발할 부분을 먼저 나눕니다.
마지막 단계
사람 손이 필요한 곳에는 사람이 들어갑니다
AI가 만든 것을 실제 사용자에게 열기 전에, 전문 개발자가 이어받아 살펴보는 단계를 따로 둘 수 있습니다. 전부 맡기는 것이 아니라 필요한 곳만 사람이 맡습니다.
코드 검토
개발문서를 기준으로 실제로 그렇게 만들어졌는지 확인합니다.
열기 전 점검
실사용자를 받기 전에 손봐야 할 곳을 정리합니다.
외부 연동
결제·문자·지도처럼 계약이 필요한 연동을 맡습니다.
인계
코드 전체를 넘겨 드립니다. 소유권은 전적으로 고객에게 있으며, 이후 개발을 저희에게 계속 맡기실 의무도 없습니다.
내 아이디어가 여기 맞는지 보려면
한 줄 적어 보시면 지금 어느 단계부터 하면 되는지, 무엇을 먼저 정해야 하는지 알려 드립니다.