개인 개발에서 '무엇을 만들지 모를 때' 아이디어 발상법의 접근 방식

개인 개발(個人開発)을 시작하고 싶어도, 처음에 부딪히는 것은 구현 자체가 아니라, '무엇을 만들어야 할지 모른다'라는 문제일 수 있습니다. (저 자신도 이 벽에 부딪히고 있습니다.)

기술을 시험하기 위해 만드는 것도 즐겁지만, 가능하다면 누군가에게 사용될 만한 것을 만들고 싶습니다. 하지만 '세상에 없는 혁신적인 아이디어'를 찾기 시작하면 손이 잘 움직이지 않습니다.

이 글에서는 개인 개발의 아이디어를 생각할 때 사용할 수 있는 접근 방식을 정리합니다. 아울러, 제가 만들고 있는 '프로젝트 매니저 시험 논문 첨삭 AI'를 예로 들어, 이 접근 방식을 어떻게 기획으로 구체화하는지 소개하겠습니다.

아이디어는 번뜩임을 기다리는 것보다는, 과제를 보는 각도를 늘려 찾을 수 있는 것이라고 생각합니다.

개인 개발의 아이디어를 생각할 때, '아직 아무도 만들지 않은 것'을 찾으려는 경향이 있습니다.

하지만 완전히 새로운 것을 처음부터 목표로 삼으면 다음과 같은 상태가 되기 쉽다고 생각합니다.

• 이미 비슷한 서비스가 있다는 것을 알고 아이디를 버린다.
• 대상자나 이용 상황이 모호한 채 기능만 늘어난다.
• 정답을 알 수 없어 구현에 착수하지 못한다.

기존 서비스가 존재한다는 것이 반드시 나쁜 것은 아닙니다. 적어도, 그곳에는 누군가의 과제가 존재할 가능성이 있습니다.

중요한 것은, 누가, 어떤 상황에서, 무엇에 어려움을 겪고 있는지를 구체화하는 것입니다. 이를 바탕으로 '기존 방법보다 조금 더 쉽게 할 수는 없을까?', '특정 사람에게 더 적합한 형태로 만들 수 없을까?'를 생각하면, 만들 것의 윤곽이 보이기 쉬워집니다.

아래에서는 아이디어의 씨앗을 찾는 5가지 접근 방식을 소개합니다.

1. 일상이나 업무 속에서 반복적으로 발생하는 작은 불편함을 관찰합니다.

• 매번 같은 형식으로 데이터를 정리한다.
• 여러 서비스를 비교하며 정보를 수집한다.
• 전사(転記), 집계, 확인을 수작업으로 한다.
• 조사한 내용을 다음 기회에 다시 조사한다.

자신이 겪는 어려움은 같은 입장의 사람도 겪고 있을 가능성이 있습니다. 특히 번거롭지만 '수작업으로 어떻게든 할 수 있는' 작업은 미루어지기 쉽지만, 도구를 통한 개선 여지가 있습니다.

이 접근 방식에서는 다음과 같이 적어내기 쉬워집니다.

〇〇을 할 때마다 △△하는 것이 번거롭다.

□□할 수 있다면 이 수고를 줄일 수 있지 않을까?

예를 들어, '청구서를 받을 때마다 필요한 항목을 스프레드시트에 전사하는 것이 번거롭다'는 관찰에서 OCR로 항목을 읽어 들여 확인 후 등록할 수 있는 도구 아이디어로 이어집니다.

2. 사람이 '이것으로 맞는 걸까?' 하고 확인할 필요가 생기는 장면에도 아이디어의 씨앗이 있습니다.

예를 들어, 다음과 같은 타이밍입니다.

• 서류나 리포트를 제출하기 전
• 코드나 설정을 운영 환경에 반영하기 전
• 시험이나 발표 직전
• 신청 내용을 전송하기 전

이러한 장면에서는 이용자가 원하는 것이 반드시 '정답을 모두 대신 만들어주는 것'은 아닙니다. 누락 확인, 개선해야 할 부분 지적, 다음에 무엇을 해야 할지에 대한 방향만 있어도 불안감을 줄일 수 있습니다.

이 접근 방식의 핵심은, 이용자가 느끼는 불안함을 구체적인 확인 항목으로 분해하는 것입니다.

3. 이미 존재하는 서비스를 사용하면서 느끼는 불만족도 훌륭한 출발점입니다.

• 가격이 비싸서 부담 없이 시도하기 어렵다.
• 결과가 나올 때까지 시간이 오래 걸린다.
• 기능이 너무 많아서 필요한 작업에 도달할 수 없다.
• 전문 지식이 없으면 설정할 수 없다.
• 한국어나 특정 업무 흐름에 맞지 않는다.

여기서 목표는 대형 서비스를 통째로 대체하는 것이 아닙니다. 대상자나 이용 상황을 좁힘으로써, '이 사람에게는 기존 서비스보다 사용하기 쉽다'라는 가치를 만들 수 있습니다.

예를 들어, '문장 첨삭 서비스'라는 큰 범주에서 경쟁하기보다는, '논술식 시험 답안을 시험에서 의식해야 할 관점에 맞춰 검토하는 것'이라는 상황으로 좁히면 필요한 기능을 명확하게 할 수 있습니다.

자신이 당사자가 아닌 영역에서는 경쟁자인 기존 서비스의 고객 리뷰를 읽는 것도 효과적입니다. 리뷰에는 이용자가 실제로 느낀 불만이나 어려움이, 이용자 자신의 언어로 쓰여 있습니다.

특히 다음과 같은 표현을 메모해 두면 과제 가설을 만들기 쉽습니다.

• '〇〇가 되면 계속 쓰고 싶다'
• '△△하는 데 시간이 오래 걸린다'
• '초보자에게는 이해하기 어렵다'
• '이 용도에는 적합하지 않다'

단, 1건의 리뷰만으로 수요가 있다고 판단할 수는 없습니다. 여러 서비스나 리뷰를 비교하며 같은 불만이 반복적으로 나타나는지 확인하는 자료로 사용합니다.

생성AI, 음성 인식, OCR, 이미지 인식 등 새로운 기술은 개인 개발의 선택지를 넓히고 있습니다.

다만, 출발점을 'AI를 사용하고 싶다'에 두면, 기술 자체를 위해 과제를 찾는 경향이 생기기 쉽습니다. 다음 질문으로 대체하면 기획하기가 더 쉬워집니다.

지금까지 '비용이 많이 든다', '시간이 걸린다', '전문가가 아니면 어렵다'고 여겨졌던 것을, 좀 더 간편하게 할 수는 없을까?

기술과 과제를 결합한 예시입니다.

'누구나 사용할 수 있는 것'을 목표로 하면, 누구에게 무엇이 편리한지 모호해지기 쉽습니다.

처음에는 대상을 좁게 정하는 것이 과제, 필요한 기능, 전달할 말을 구체화하기가 더 쉽습니다.

또한, 대상을 좁히면 기업이 큰 시장으로는 우선시하기 어려운 니치한 영역을 노리기 쉬워집니다. 사용자 수는 많지 않아도, 어려움이 명확하고 기존 선택지가 적다면 개인 개발로도 의미 있는 가치를 전달할 수 있습니다.

지금까지의 관점을 사용하여 실제 기획을 정리해 보겠습니다.

제가 만들고 있는 것은 '프로젝트 매니저 시험 논술 첨삭 AI'입니다. IPA의 프로젝트 매니저 시험에서 논술 답안을 AI를 사용해 반복적으로 검토할 수 있는 학습 앱입니다.

문제문을 확인하며 답안을 작성하고, 채점 후에는 관점별 피드백을 보고 다음 개선으로 연결할 수 있도록 했습니다.

이 주제를 선택한 이유는 저 자신이 프로젝트 매니저 시험 응시를 생각했고, '스스로 사용하고 싶다'고 느꼈기 때문입니다. 개인 개발에서는 자신이 당사자인 과제부터 시작하면, 곤란한 상황이나 필요한 기능을 구체적으로 상상하기가 쉽습니다.

시험 대비를 조사해 보면, 오전에 객관식 문제를 다루는 사이트는 많이 찾을 수 있습니다. 반면, 오후의 논술형 문제에 대해 답안을 반복적으로 검토할 수 있는 지원은 상대적으로 적다고 느꼈습니다. 오후 대비에 초점을 맞춤으로써, 범용적인 학습 서비스와는 다른 관점을 만들 수 있다고 생각했습니다.

시장 규모는 크지 않지만, 니치하기 때문에 오히려 고려해 볼 가치가 있습니다. IPA가 공개한 레이와 7년도 통계 자료에 따르면, 프로젝트 매니저 시험 응시자는 13,540명, 응시자는 8,511명이었습니다. 매년 1만 명 전후가 시험을 의식하는 영역이라고 본다면, 개인 개발로 가설을 검증할 대상으로는 충분하다고 판단했습니다.

이 기획을 앞서의 관점에 대입하면 다음과 같습니다.

응시자가 알고 싶은 것은 단순한 오탈자뿐만 아니라, 제문에 답하고 있는지, 경험이나 근거가 구체적인지, 답안 전체에 일관성이 있는지와 같은 점입니다. 시험에 임하는 사람이 불안함을 느끼는 상황에 초점을 맞춤으로써, 범용적인 문서 첨삭과는 다른 지원을 생각할 수 있습니다.

기획 단계에서 처음부터 다기능으로 만들 필요는 없습니다. 이 앱이라면, 첫 버전은 다음 흐름만으로도 가치를 검증할 수 있습니다.

• 응시자가 답안을 입력한다
• AI가 관점별로 좋은 점과 개선 힌트를 반환한다
• 응시자가 답안을 다시 작성한다

'첨삭이 맞는지'뿐만 아니라, '개선해야 할 부분이 파악되어 다음 답안 작성을 진행할 수 있는지'를 보는 것이 중요합니다.

후보가 생기면, 다음 질문에 답해봅니다.

누구를 위한 것인가? 한 문장으로 구체적으로 설명할 수 있는가 -
그 사람은 정말 곤란한가? 상상뿐 아니라 자신의 경험이나 관찰이 있는가 -
무엇이 어떻게 편해지는가? 이용 전과 이용 후의 차이를 설명할 수 있는가 -
작게 만들 수 있는가? 첫 버전으로 가치의 핵심만 시험해 볼 수 있는가 -
다시 사용할 이유가 있는가? 일회성이 아니라, 지속적으로 사용하는 장면이 있는가

모두에 처음부터 명확한 답을 내놓지 못해도 괜찮습니다. 답이 모호한 부분이 바로 실제로 만들어서 확인해야 할 가설입니다.

개인 개발에서는 처음부터 '절대 사용될 정답'을 찾을 필요는 없습니다. (찾으려고 해도 불가능합니다.)

우선, 주변에서 불편함을 느끼는 점, 불안감이 생기는 상황, 기존 서비스에 대한 불만, 새로운 기술로 개선할 수 있는 부분, 그리고 특정 대상에게 초점을 맞춥니다. 이러한 관점에서 후보를 도출하고, 가장 작은 형태로 만들어봅니다. 그 반응을 바탕으로 기획을 발전시켜 나가는 것이 현실적이라고 생각합니다.

저 자신도 '만들고 싶은 것이 없다'고 느낄 때는 영감을 기다리기보다는, 자신이나 주변 사람이 느꼈던 불편함을 하나씩 적어보는 편입니다. 거기서 다음에 만들 것의 씨앗이 발견될 수도 있다고 생각합니다.

• 개인 개발자의 기술 노트. — 개인 개발에서의 시행착오나 기술적인 학습을 기록하는 블로그
• 프로젝트 매니저 시험 논문 첨삭 AI — 본 기사에서 기획 예시로 소개한 학습 앱
• IPA: 통계 정보(응용정보기술자시험, 고급시험, 정보처리안전확보지원사시험) — 프로젝트 매니저 시험 지원자 및 응시자 수를 확인한 통계 자료