반복되는 작은 불편 때문에 매번 범용 앱의 메뉴를 뒤지고 있다면, 필요한 기능 하나만 가진 개인용 앱이 매력적으로 느껴질 수 있습니다. AI에게 자연어로 요구를 설명하는 방식은 이런 도구를 만드는 진입 장벽을 낮출 가능성이 있습니다. 다만 만들 수 있다는 것과 계속 믿고 쓸 수 있다는 것은 별개의 문제입니다.
왜 개인용 앱 이야기가 다시 나올까
Thomas Ptacek은 2026년 9월 25일 「What Even Is An OS Now?」에서 한두 명을 위한 소프트웨어가 늘어날 미래를 이야기하며, 관련 휴대전화 프로젝트를 추진한다고 밝혔습니다. 이는 자신의 사업과 연결된 전망입니다. 이미 완성된 기기가 출시됐다거나 기존 앱과 운영체제가 사라졌다는 소식은 아닙니다.
이 글은 Hacker News 토론으로도 이어졌습니다. 2026년 9월 29일 확인한 페이지에는 308포인트와 댓글 468개가 표시됐습니다. 관심과 논쟁이 있다는 신호지만, 조회수나 사용자 채택률을 뜻하지는 않습니다.
개인 개발자에게 더 실용적인 질문은 “모든 앱을 직접 만들까?”보다 “내가 반복해서 겪는 어떤 불편을 작은 도구로 줄일까?”입니다. 아래는 이 글에서 구성한 설계 예시입니다.
만들기 전에 정할 다섯 가지
| 항목 | 너무 넓은 요구 | 확인할 수 있는 요구 |
| 사용 순간 | 문서를 편하게 관리 | 매주 금요일 이번 주 PDF 목록 확인 |
| 입력 범위 | 내 파일 전부 | 내가 선택한 폴더의 파일 이름·수정일 |
| 결과 | 알아서 정리 | 분류 제안과 이유를 목록으로 표시 |
| 변경 권한 | 필요하면 수정 | 첫 버전은 원본 이동·삭제 없이 조회 |
| 유지 기준 | 잘 동작하게 | 오류·데이터 위치·마지막 점검일 기록 |
목표를 좁히면 원하는 결과인지 확인하기 쉽습니다. 이 표는 제품이 제공하는 기능 목록이 아니라, 개인용 도구를 구상할 때 사용할 수 있는 요구사항 예시입니다.
예시: 이번 주 문서만 모아 보여주는 앱
가상의 첫 버전은 사용자가 폴더를 고르면 그 안의 PDF 중 지정한 기간에 수정된 파일만 보여줍니다. 화면에는 파일 이름, 수정일, 원래 위치를 표시하고 정렬만 제공합니다. 내용 요약이나 자동 이동은 나중에 추가할 수 있습니다.
여기서 먼저 결정할 것은 ‘이번 주’의 뜻입니다. 월요일 00:00부터 지금까지인지, 최근 7일인지에 따라 목록이 달라집니다. 아래 예시는 기기에 설정된 시간대에서 월요일 00:00부터 조회 시점까지를 범위로 삼습니다. 파일 수정일은 문서 내용이 작성된 날짜와 다를 수 있다는 설명도 화면에 붙입니다.
| 입력 상황 | 기대 동작 |
| 기간 안에 수정된 PDF | 목록에 표시 |
| 기간 밖의 PDF | 제외 |
| 이름은 같지만 위치가 다른 두 파일 | 각각 표시하고 경로로 구별 |
| 대상 폴더에 PDF가 없음 | ‘해당 기간의 PDF 없음’ 표시 |
| 폴더를 읽을 수 없음 | 빈 결과로 숨기지 않고 오류 표시 |
| 하위 폴더의 PDF | 이번 버전에서는 제외한다고 명시 |
이 여섯 사례를 먼저 합의하면 “대충 잘 찾아주는 앱”보다 완료 여부가 분명해집니다. 아직 만들지 않은 앱의 예상 동작이며 실제 실행 후기나 성능 측정 결과는 아닙니다.
기존 앱으로 할 일과 직접 만들 일을 나누세요
한 번만 필요한 작업이라면 이미 있는 검색·정렬 기능으로 끝날 수 있습니다. 반복 빈도가 높고 매번 같은 기준을 적용하며, 결과를 쉽게 확인할 수 있는 작업은 작은 도구의 후보가 됩니다.
예를 들어 월말마다 파일 목록을 같은 형식으로 정리한다면 재사용할 가치가 있습니다. 반대로 요구가 매번 완전히 달라지고 예외가 많다면 도구를 고치는 시간이 절약한 시간보다 커질 수 있습니다. 처음에는 제작 시간뿐 아니라 한 달 동안 수정·확인한 시간까지 기록해 보세요.
복사해서 쓰는 개인용 앱 요청문
목적: 매주 선택한 폴더에서 이번 주 수정된 PDF 목록을 확인한다.
기간: 기기 시간대의 월요일 00:00부터 조회 시점까지.
입력: 사용자가 직접 선택한 폴더. 하위 폴더는 제외한다.
출력: 이름, 수정일, 원래 경로가 있는 목록.
첫 버전: 원본 파일 이동·삭제·업로드 기능은 넣지 않는다.
빈 결과와 읽기 실패를 서로 다른 상태로 보여준다.
실제 구현 전에 모호한 조건을 나열하고, 대표 입력별 기대 결과를 정해줘.이후 이동 기능을 추가한다면 같은 이름의 파일을 어떻게 처리할지, 이동 전 경로를 어떻게 기록할지부터 정합니다. 작은 앱이라고 해서 동작 범위를 암묵적으로 넓힐 필요는 없습니다.
한 달 뒤에도 쓰려면 남길 기록
설치·실행 방법, 필요한 환경, 설정과 데이터의 위치를 짧게 남겨두세요. 오류가 났을 때 확인할 기록과 마지막 정상 동작 날짜도 유용합니다. API를 연결했다면 어떤 자료가 어디로 전송되는지 확인할 수 있어야 합니다.
대표 입력 여섯 개를 작은 시험 폴더로 남겨두면 기능 추가 후 이전 동작이 유지되는지 다시 살펴볼 수 있습니다. 개인용 앱의 가치는 기능 개수보다, 특정한 불편을 반복해서 줄여주는지에 달려 있습니다.
자주 묻는 질문
코딩을 몰라도 만들 수 있나요? AI의 도움을 받을 수 있지만 결과를 확인하는 기준은 필요합니다. 원하는 입력·출력과 예외를 설명하는 것부터 시작해 보세요.
로컬에서 실행하면 자료가 외부로 나가지 않나요? 실행 위치만으로 판단할 수 없습니다. 외부 API 호출·동기화·로그 전송 여부는 별도로 확인해야 합니다.
기존 운영체제가 필요 없어진다는 뜻인가요? 아닙니다. 개인용 앱 확대 전망과 운영체제의 자원·접근 관리 역할은 구분해야 합니다.
참고 자료
확인일: 2026년 9월 29일. 외부 전망·토론 반응과 자체 설계 예시를 구분했습니다.