실제 서비스 만들기

 지금까지는 아이디어를 서비스의 구조로 정리하는 과정에 대해 이야기했습니다. 막연한 생각을 문장으로 정리하고, 누가 언제 사용하는지 생각해 보고, 서비스 플로우를 그리고, MVP 범위를 정리하고, 요구사항을 정리하는 과정까지 살펴보았죠. 그래서 이제는 이런 상태라고 가정해보겠습니다. 노션이든 엑셀이든, 어딘가에 이런 내용을 정리하셨다 라고요.

 

 이 서비스는 누구를 위한 것인지, 사용자는 언제 이 서비스를 쓰는지, 사용자가 어떤 흐름으로 서비스를 사용하는지, 첫 버전에서 필요한 기능은 무엇인지 같은 것들요. 즉, 기획서가 이미 하나 만들어져 있는 상태라고 가정해 봅시다. 이 단계까지 왔다면 사실 가장 막막했던 구간은 이미 지나온 셈입니다. 그래서 이제 하나의 질문으로 귀결됩니다.

 

 '이걸 실제 서비스로 어떻게 만들기 시작할까요?'

 

 

출처 : Brunoepicki

기획서는 개발 설명서입니다.

 집을 한 채 짓는 상황을 떠올려보죠. 누군가 '집 하나 지어주세요' 라고 말한다고 해서 바로 공사가 시작되는 것은 아닙니다. 집의 크기는 어느 정도인지, 방은 몇 개인지, 주방은 어떤 구조인지, 창문은 어디에 있는지 같은 것들이 먼저 정리되어야 합니다.

 

 그래서 보통 집을 짓기 전에 도면을 만듭니다. 건축가는 그 도면을 보고 집의 구조를 이해하고, 어디에 벽이 서고, 어디에 창문이 들어가는지 확인합니다. 전기나 수도 같은 설비도 그 도면을 기준으로 계획됩니다. (이 이상은 저도 자세히는 모르겠어요. ^^) IT 서비스 개발에서의 기획서는 이 도면와 비슷한 역할을 합니다. 예를 들어 기획서에 이런 내용이 있다고 생각해 보겠습니다.

 

• 사용자는 회원가입을 한다.
• 오늘의 콘텐츠를 확인한다.
• 콘텐츠를 보고 완료 버튼을 누른다.
• 기록이 저장된다.
• 이전 기록을 다시 확인할 수 있다.

 

 이런 문장들은 겉으로 보면 단순하지만, 개발자의 입장에서 보면 이미 꽤 많은 정보가 들어 있습니다.

 

• 회원가입 화면이 하나 필요합니다.
• 콘텐츠를 보여주는 화면이 필요합니다.
• 사용자의 기록을 저장하는 데이터 구조가 필요합니다.
• 그리고 그 기록을 다시 보여주는 화면도 필요합니다.

 

 즉 이 문장들은 어떤 시스템을 만들어야 하는지를 설명하는 구조가 됩니다. 여기서 한 가지 재미있는 점이 있습니다. 제가 제 직업을 설명해야 할 때 주로 쓰는 비유인데요. 대부분의 사람들은 집을 짓고 싶다고 말할 때 도면을 그려서 오지 않습니다. '세 식구가 살 집이에요', '예산은 어느 정도이고요', '거실이 좀 따뜻한 분위기였으면 좋겠어요'. 보통은 이렇게 이야기하시죠?

 

 이 말들은 틀린 말이 아닙니다. 하지만 이 상태로는 바로 집을 지을 수 없습니다. 그래서 건축가들은 이런 말을 듣고, 아마도 이런 질문을 던지실 겁니다. '방은 몇 개가 필요할까요?', '주방은 거실과 붙어 있는 구조가 좋을까요', '아이 방은 어디에 두는게 좋을까요' 같은 질문들이요. 이 질문들을 하나씩 정리하면서 의뢰인의 생각이 도면으로 바뀝니다.

 

 서비스 기획자도 비슷한 역할을 합니다. 도면이 없는 집과 비슷한 상태에서, 구체적인 질문을 통해 하나씩 정리하다 보면, 막연한 아이디어는 점점 구조를 갖게 됩니다. 그리고 그 구조가 바로 개발을 시작할 수 있는 기획서가 됩니다. 집을 짓는 데 도면이 필요하듯이, 서비스를 만드는 데는 이런 설명서가 필요합니다. 그리고 그 설명서를 만드는 과정이 서비스 기획의 역할에 가깝습니다.

 

 어떤 상황에 어떤 질문이 필요한지 아는 것만으로도 아이디어가 훨씬 선명해집니다. 물론 항상 서비스 기획자를 곁에 두고 시작하실 수 있는 것은 아니겠지요. 그런 경우라면 제가 이전 화에서 이야기했던 질문들을 한 번 다시 떠올려 보셔도 좋겠습니다. 집을 짓기 전에 도면이 만들어지듯이, 서비스도 이런 질문들을 통해 조금씩 형태를 갖추게 됩니다.

 

 

 

요즘은 이 문서를 AI에게 보여주기도 합니다

 예전에는 이런 기획서를 가지고 개발자와 회의를 시작했어요. 전통적인 기획서의 종류로는 이런 것들이 있습니다. 요구사항 정의서(PRD), 정보 구조도(IA - Information Architecture), 이벤트 로그, 엣지 케이스, 유저 시나리오, 스토리보드 같은 것들이요. 이런 문서들을 기획자가 만들어서, 개발자와 회의를 시작합니다. 지금도 이 방식은 여전히 사용됩니다.

 

 하지만 최근에는 조금 다른 방식도 많이 등장합니다. AI에게 먼저 설명해 보는 방식입니다. 바이브코딩 이라고 부르기도 하죠. AI에게 먼저 설명해 보는 방식입니다. 예를 들어 이런 식입니다.

 

“회원가입 기능이 있고, 오늘의 콘텐츠를 보여주며, 사용자가 완료 버튼을 누르면 기록이 저장되는 간단한 학습 기록 웹 서비스를 만들고 싶습니다.”

 

 이렇게 설명하면 AI는 기본적인 구조를 만들어주기도 합니다. 화면 구조를 제안하기도 하고 간단한 코드나 데이터 구조를 만들어주기도 합니다. 물론 완벽한 서비스가 바로 만들어지는 것은 아닙니다. 하지만 생각보다 많은 부분이 이 단계에서 이미 작동하기 시작합니다.

 

 예전에는 개발을 시작하기 위해 여러 사람이 모여야 했다면, 지금은 혼자서도 작은 서비스 하나를 시작해볼 수 있는 환경이 만들어지고 있습니다.

 

 

 

기획이 명확할수록 개발이 쉬워집니다

 개발이 어려워지는 이유는 대부분 기술 때문이 아니라 방향 때문입니다. 정말 실력있는 개발자 분들 많으시거든요. 그런데 무엇을 만들어야 하는지 명확하지 않으면 개발이 계속 멈춥니다.

 

• 로그인 기능을 만들고 있는데 갑자기 소셜 로그인 이야기가 나오고,
• 콘텐츠 화면을 만들고 있는데 추천 알고리즘 이야기가 나오고,
• 관리자 기능을 만들고 있는데 권한 체계가 다시 바뀝니다.

 

 이런 상황이 반복되면 개발은 계속 뒤로 밀립니다. 코드를 쓰는 시간보다 무엇을 만들기 다시 정하는 시간이 더 길어지기 때문입니다. 그래서 개발자들이 가장 먼저 묻는 질문은 기술적인 것들이 아닙니다.

 

• 로그인은 어떤 방식인가요?
• 회원가입은 어디까지 필요한가요?
• 관리자는 어떤 정보를 볼 수 있나요?
• 첫 번째 버전에서 꼭 필요한 기능은 무엇인가요?

 

 이 질문들은 사실 모두 기획에 대한 질문입니다. 반대로 기획이 명확하면 개발은 훨씬 단순해집니다. 어떤 화면이 필요한지, 어떤 기능이 필요한지, 어떤 데이터가 저장되어야 하는지가 이미 정리되어 있기 때문입니다. 예를 들어 '사용자가 콘텐츠를 보고 완료 버튼을 누르면 기록이 저장된다' 는 문장이 있다면, 개발자는 이미 여러 가지를 이해합니다. 기록을 저장할 데이터가 필요하고, 완료 버튼이 있는 화면도 필요하고, 사용자의 기록을 다시 확인하는 화면도 필요하다고요. 이 정도 정보만 있어도 개발은 시작할 수 있습니다.

 

 그래서 서비스를 만들 때 가장 어려운 일은 코드를 작성하는 일이 아니라 무엇을 만들지 결정하는 일이라고 생각합니다. 기획이 명확해질수록 개발은 오히려 단순해집니다.

 

 

 

이제 한 번 만들어 보세요

 대부분의 서비스는 거창한 시작으로 만들어지지 않습니다. 작은 질문에서 시작하고, 작은 구조로 정리되고, 작은 기능 하나로 작동하기 시작합니다. 그리고 그 작은 시작이 조금씩 서비스를 만들어 갑니다.

 

 이미 기획서를 하나 만드셨다면, 이제 그 다음 단계로 넘어가 보셔도 좋겠습니다. AI와 함께 바이브 코딩을 하시거나, 전문 개발자의 도움을 받으셔서요. 생각보다 많은 것들이 이미 준비되어 있을지도 모릅니다. 혹시 AI에게 프로토타입 개발을 요청한다면, 이런 식으로 요청해보세요.

 

회원가입이 있고, 오늘의 콘텐츠를 보여주며, 완료 버튼을 누르면 기록이 저장되는
간단한 학습 기록 웹 서비스를 만들고 싶습니다.
React + Supabase 기반으로 간단한 MVP 구조를 만들어 주세요.

 

 아주 단순하게 작성한 프롬프트입니다. 하지만 기획이 명확할수록 이런 요청은 훨씬 정확해지고, 나중에 여러 차례 수정하지 않아도 됩니다. AI도 결국 사람이 설명한 내용을 바탕으로 구조를 만드니까요.

 

 그래서 저는 요즘 이런 생각을 자주 합니다. 아이디어보다 더 중요한 것은 아이디어를 질문과 답변으로 풀어내는 과정이라는 생각이에요. 제가 개발하고 있는 서비스도 이 지점에서 출발했습니다. 코드나 기술적인 지식이 없어도, 질문에 답하다 보면 자연스럽게 서비스 기획서나 개발 프롬프트가 만들어지도록 돕는 도구를 만들고 있습니다.

 

 아이디어는 누구나 떠올릴 수 있습니다.

 하지만 질문을 통해 구조를 만들면, 그 아이디어는 훨씬 현실에 가까워집니다.

 그리고 그 구조가 바로 서비스가 시작되는 지점입니다.