Nobody Laid Out The Five Kinds Of Software You Can Make. So I Did.

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Nobody Laid Out The Five Kinds Of Software You Can Make. So I Did.를 중심으로, 기술이나 AI 빌더부터 선택하지 말고, 사용할 사람·실행 장치·필요한 데이터·자동화 조건을 기준으로 다섯 가지 소프트웨어 형태 중를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 기술이나 AI 빌더부터 선택하지 말고, 사용할 사람·실행 장치·필요한 데이터·자동화 조건을 기준으로 다섯 가지 소프트웨어 형태 중 필요한 형태를 먼저 구분해야 한다.
2. 한 컴퓨터에서만 처리하는 작업에는 로컬 도구가 가장 단순하고, 여러 기기나 사용자가 기록을 공유하되 휴대전화 고유 기능이 필요하지 않다면 비공개 웹 앱이 기본 선택지다.
3. Lovable·Replit·Bolt 같은 호스팅형 AI 빌더는 개발과 게시를 빠르게 시작하게 해주지만, GitHub 연결과 외부 데이터베이스 분리를 통해 코드·데이터 소유권과 이전 가능성을 확보해야 한다.
4. 푸시 알림·블루투스·백그라운드 위치에는 네이티브 앱, 일정·이벤트 기반 자동화에는 백그라운드 서비스, 센서·카메라·무선 신호에는 하드웨어 프로젝트가 필요하다.
5. project.md·decisions.md·scenarios.md·도구별 지침 파일로 목표와 선택 근거를 보존하고, 공개·유료·파괴적 작업은 사람의 승인과 실제 기기에서의 시나리오 검증을 거쳐야 한다.

🧩 배경과 문제 정의

• AI로 만들고 싶은 아이디어가 있어도 이를 휴대전화·컴퓨터·가정용 장치에서 실제로 작동하는 소프트웨어로 바꾸는 경로는 비개발자에게 불분명하다.
• 개인의 생활에 꼭 맞춘 작은 도구는 대중용 앱보다 범위가 좁지만, 반복되는 불편을 직접 해결한다는 점에서 실용적 가치가 크다.
• 필요한 소프트웨어의 형태를 먼저 결정하면 개발 도구·데이터 저장소·배포 방식의 선택지를 크게 줄일 수 있다.
• 가장 단순한 구조로 시작하되 데이터 소유권·비용·보안·이식성에 영향을 주는 결정은 사람이 이해하고 통제해야 한다.

🕒 시간순 섹션별 상세정리

1. 개인 소프트웨어가 해결하는 생활 속 문제

• 만들고 싶은 결과를 실제 장치에서 작동시키려면 로컬 도구·웹 앱·네이티브 앱·백그라운드 서비스·하드웨어 프로젝트 가운데 필요한 형태부터 구분해야 한다. [00:12]
• 암스테르담의 한 사용자는 부정확한 페리 시간표와 고가의 상용 위치 정보 대신, 선박이 의무적으로 송출하는 AIS 신호를 약 200유로의 수신기·안테나·라즈베리 파이로 직접 수집했다. [01:35]

2. 원하는 변화에서 기술적 구조 도출하기

• 페리 프로젝트는 외부 무선 신호를 수신하고 최근 위치 데이터를 저장한 뒤 휴대전화 화면이나 알림으로 전달하면 되며, 소수의 가정 사용자만 쓰기 때문에 앱스토어나 대규모 계정 시스템은 불필요하다. [02:53]
• 주택 관리 프로젝트는 라벨·설명서·사진·서비스 날짜를 저장하고 두 사람이 같은 기록을 휴대전화에서 갱신해야 하므로, 공유 데이터베이스와 사진 저장소를 갖춘 비공개 웹 앱이 적합하다. [03:57]

3. 대부분의 요구를 포괄하는 다섯 가지 소프트웨어 형태

• 로컬 도구는 한 컴퓨터의 파일이나 소형 데이터베이스만 사용하므로 문서 정리·개인 연구·사진 이름 변경처럼 웹사이트와 로그인이 필요 없는 작업에 가장 단순하다. [04:53]
• 웹 앱은 하나의 버전으로 노트북과 휴대전화에서 실행되고 앱스토어 등록 없이 가족이나 동료와 공유할 수 있어, 특별한 기기 기능이 필요하지 않은 개인 소프트웨어의 기본 선택지다. [05:14]

4. 호스팅형 AI 빌더와 데이터 소유권

• Lovable·Replit·Bolt 같은 호스팅형 빌더는 개발 환경·미리보기·게시 기능을 준비해 두므로, 프로그래밍 언어나 명령줄을 설치하지 않고도 설명에서 작동하는 웹 인터페이스까지 빠르게 이동할 수 있다. [07:15]
• 처음부터 GitHub를 연결하면 소스 코드와 변경 이력을 별도로 보관할 수 있어, 특정 빌더에 의존하지 않고 프로젝트를 다른 환경으로 옮길 가능성이 커진다. [07:54]

5. 통합형 서비스와 모듈형 개발 환경의 차이

• Replit과 Bolt는 실행 환경·데이터베이스·인증·스토리지·배포를 한 서비스에 통합해 편리하지만, 코드와 데이터의 위치 및 서비스를 떠날 때 필요한 이전 절차를 미리 확인해야 한다. [09:36]
• 더 많은 통제권이 필요하면 Codex 또는 Claude Code를 GitHub Desktop·Supabase·Vercel과 조합해 코드, 데이터, 배포를 분리할 수 있으며 한 구성요소만 독립적으로 교체하기 쉬워진다. [10:28]

6. 물리 세계와 연결되는 하드웨어 경로

• AIS 수신 프로젝트에서는 라즈베리 파이가 무선 신호를 계속 해독하고 SQLite가 최근 선박 위치와 도착 계산을 저장하며, 비공개 웹 페이지와 Tailscale이 승인된 가정용 기기에 결과를 전달한다. [13:33]
• 기존 조명·온도조절기·플러그는 Home Assistant로 연결하고, 단일 온도·동작·습도 센서라면 ESP32와 ESPHome을 사용해 맞춤형 하드웨어 개발 범위를 줄일 수 있다. [14:16]

7. 네이티브 앱이 필요한 조건과 비용

• 네이티브 앱은 코딩 에이전트·Expo·Supabase를 조합하면 하나의 프로젝트에서 iOS와 Android 빌드를 만들 수 있지만, 공개 배포에는 Apple·Google 개발자 계정과 심사가 추가로 필요하다. [15:57]
• 휴대전화 고유 기능이 아이디어의 핵심이 아니라면 비공개 웹 앱으로 수요를 먼저 검증해야 하며, 앱스토어 절차와 비용은 실제 필요성이 확인된 뒤 감수하는 편이 효율적이다. [16:25]

8. 모델의 선택을 통제하는 네 개의 프로젝트 파일

• 모델이 비용·공개 범위·데이터 저장소를 임의로 선택하지 않게 하려면 마법 같은 단일 프롬프트보다, 중요한 선택과 근거를 공개하는 협업자 역할을 부여해야 한다. [16:46]
• project.md는 사용자·현재 상태·목표 상태·실행 위치·비공개 정보를, decisions.md는 비용·데이터·접근·배포·이식성에 영향을 주는 선택지와 결정 근거를 보존한다. [17:27]

9. 중요한 결정을 드러내는 지속적 협업 방식

• 데이터·비용·개인정보·이식성·배포·유지보수에 영향을 주는 선택에서는 현실적인 대안과 추천안을 비교하고, 공개·유료·파괴적 작업은 실행 전에 사람의 승인을 받아야 한다. [18:51]
• 비밀 키는 코드와 GitHub에서 분리하고, 완성 선언 대신 실제 실행 결과를 사용 시나리오와 대조해 검증해야 초기 바이브 코딩에서 반복됐던 보안·품질 문제를 줄일 수 있다. [19:17]

10. 인터페이스부터 통합까지 소프트웨어 구성요소 이해하기

• 인터페이스는 사용자가 접하는 부분이고 데이터베이스는 모델 번호·서비스 날짜·작업 같은 구조화된 정보를 기억하며, 인증은 사용자의 신원을 확인하고 권한 부여는 각 사용자가 볼 수 있는 정보와 변경 범위를 제한한다. [20:26]
• 호스트는 소프트웨어를 계속 실행하고, 통합은 날씨·선박 신호·캘린더·이메일·AI 모델처럼 외부 데이터를 앱으로 가져오지만 모든 프로젝트에 이 구성요소가 전부 필요한 것은 아니다. [21:13]

11. 데이터베이스 선택과 배포의 실질적 기준

• 최고의 데이터베이스를 찾기보다 필요한 사람에게 데이터를 전달하는 가장 단순한 방식을 선택해야 하며, 개인용인지 다중 사용자용인지가 저장 구조를 가르는 핵심 조건이다. [22:53]
• 배포는 소프트웨어를 계속 실행되는 위치에 두고 대상 사용자가 접근하게 만드는 과정이며, Lovable의 게시 버튼부터 GitHub·Vercel의 미리보기와 프로덕션 전환까지 다양한 수준으로 구현할 수 있다. [23:09]

12. 비공개 기본값과 데이터 접근 통제

• 앱은 비공개를 기본값으로 두고 꼭 필요할 때만 인터넷에 공개해야 하며, 자체 비밀번호 저장 기능을 만들기보다 검증된 관리형 로그인 시스템을 사용해야 한다. [24:17]
• API 키와 비밀번호는 호스트의 비밀 설정에 저장해야 하고 웹페이지·코드·스크린샷·대화 기록·GitHub에는 포함하지 않아야 한다. [24:41]

13. 백업과 위험 수준에 맞춘 보안

• 중요한 데이터는 백업 파일을 만드는 데서 끝나지 않고 실제 복원 후 내용이 정상인지 검증해야 하며, 중요도가 낮은 개인 북마크와 핵심 생활 기록에는 서로 다른 기준을 적용할 수 있다. [25:45]
• 결제·아동·의료·법률 정보는 오류와 유출의 피해가 크므로 실제 사용 전에 별도 검토가 필요하고, 첫 개인 앱은 민감하지 않은 데이터로 시작해 보안 난도를 단계적으로 높이는 편이 안전하다. [26:09]

14. 실제 사용 시나리오와 사람의 최종 검증

• 테스트 전문 용어보다 중요한 상황을 먼저 적고 실제 사용할 기기에서 확인해야 하며, 가전제품 사진 등록·모델 번호 보존·두 휴대전화 간 작업 동기화·읽을 수 없는 사진 같은 정상 및 실패 경로를 함께 시험해야 한다. [26:42]
• 코딩 에이전트나 AI 빌더의 완료 응답만으로 품질을 확정할 수 없으며, 사람이 직접 결과를 사용하고 의도한 상황에서 실제로 작동하는지 판단해야 한다. [27:43]

15. 장기 협업과 다중 에이전트를 위한 선택적 시스템

• Open Engine은 여러 도구·에이전트·사람 사이에서 전체 맥락을 반복 설명하지 않고 작업을 넘기는 체계이며, 단순한 첫 앱보다 여러 도구가 수개월간 유지하는 프로젝트에 적합하다. [29:28]
• Ringer는 여러 에이전트가 동시에 시스템을 수정할 때 변경 정의, 업무 분배, 비용 절감, 결과 검증과 소유자 보고를 한곳에서 관리하지만, 다중 에이전트 운영에 익숙하지 않은 첫 프로젝트에는 과도하다. [29:53]

16. 첫 한 시간의 문제 정의와 구축 환경 선택

• 오래 만들고 싶었던 한 가지를 고른 뒤 현재 상태와 원하는 상태, 필요한 신호나 정보, 결과가 나타날 화면과 사용자, 실패 시 위험을 구체적으로 적어야 한다. [30:53]
• 첫 비공개 웹 앱은 설정이 적은 Lovable과 관리형 백엔드로 시작할 수 있고, 데이터 이동성이 중요하면 Supabase를 고려하며, 더 많은 통제가 필요하면 Codex나 Claude Code와 Vercel 같은 서비스를 조합할 수 있다. [31:23]

17. 생활 문제를 직접 해결하는 개인용 소프트웨어

• 개인용 소프트웨어는 문제와 당사자 가까이에서 함께 진화하며, 생활 문제를 아는 사람과 기술을 가진 사람이 분리돼 있던 과거와 달리 이제는 당사자가 원하는 해결책을 직접 만들고 소유할 수 있다. [33:11]
• 오래 원했지만 시중 제품으로 해결되지 않았던 소프트웨어를 가장 단순한 형태로 정의하고, Lovable 같은 구축 파트너와 작은 시도부터 시작하는 것이 실천 과제다. [33:59]

🧾 결론

• 소프트웨어 형태를 먼저 결정하면 개발 도구·저장소·배포 방식의 불필요한 선택지를 줄일 수 있다.
• 특별한 기기 기능이 없다면 비공개 웹 앱으로 수요를 검증하고, 네이티브 앱과 앱스토어 비용은 필요성이 확인된 뒤 감수하는 편이 효율적이다.
• AI 빌더의 편의성과 장기적인 통제권은 별개의 문제이므로 코드 위치, 데이터 위치, 서비스 이전 절차를 처음부터 확인해야 한다.
• AI의 완료 선언은 품질 보증이 아니며, 실제 사용자가 정상 경로와 실패 경로를 직접 시험한 결과가 최종 판단 기준이다.

📈 투자·시사 포인트

• 통합형 AI 빌더는 개발 환경·인증·스토리지·배포를 묶어 초기 진입 장벽을 낮추지만, 서비스 종속성과 이전 절차가 채택 판단의 핵심 변수가 된다.
• GitHub·Supabase·Vercel처럼 코드·데이터·배포를 분리하는 모듈형 구성은 편의성보다 이식성과 구성요소별 교체 가능성을 중시하는 수요에 대응한다.
• 개인용 소프트웨어가 늘어날수록 관리형 로그인, 데이터베이스, 비공개 배포, 비밀 관리처럼 소규모 프로젝트도 안전하게 운영하게 하는 기반 서비스의 중요성이 커진다.
• Home Assistant·ESP32·ESPHome·Raspberry Pi처럼 물리 장치와 소프트웨어를 연결하면서 맞춤 개발 범위를 줄이는 생태계는 개인 자동화의 실용적인 진입 경로가 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상은 호스팅형 빌더, 데이터베이스, 배포 서비스의 구체적인 요금과 제한을 비교하지 않으므로 실제 선택 전 최신 비용과 무료 한도를 별도로 확인해야 한다.
• 페리 추적과 주택 관리 사례의 구조가 다른 프로젝트에도 그대로 적합하다고 단정할 수 없으며, 사용자 수·데이터 민감도·장애 위험에 따라 설계가 달라질 수 있다.
• 비공개 기본값과 관리형 인증을 권장하지만, 제시된 구성의 보안 수준이 독립적인 감사나 침투 테스트로 검증됐다는 근거는 제공되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 만들고 싶은 한 가지 문제에 대해 현재 상태, 원하는 상태, 사용자, 실행 장치, 필요한 신호와 실패 시 위험을 적는다.
• 로컬 도구·웹 앱·네이티브 앱·백그라운드 서비스·하드웨어 프로젝트 중 가장 단순하게 요구를 충족하는 형태를 하나 선택한다.
• project.md, decisions.md, scenarios.md를 만들고 비용·데이터·접근·배포·이식성에 영향을 주는 선택과 근거를 기록한다.
• 호스팅형 AI 빌더를 사용한다면 GitHub 연결, 데이터 내보내기, 서비스 이전 절차와 비밀 키 저장 방식을 확인한다.

❓ 열린 질문

• 이 아이디어에는 웹 앱으로 충족할 수 없는 푸시 알림·블루투스·백그라운드 위치·NFC 같은 휴대전화 고유 기능이 실제로 필요한가?
• 데이터와 코드 중 무엇을 외부 서비스에서 독립시켜야 장기적인 이전 가능성을 충분히 확보할 수 있는가?
• 데이터 손실·유출·오작동의 피해 수준에 맞춰 어느 정도의 백업 복원 검증과 별도 보안 검토가 필요한가?