코딩 모르는데 앱 만들기, Big Calendar처럼 ‘보기만 하는 앱’부터 시작해 볼까요?

핵심 요약 (TL;DR)

새 캘린더를 만든다고 반드시 일정 입력부터 동기화까지 전부 구현해야 하는 것은 아닙니다. 9월 18일 Show HN에 소개된 Big Calendar는 iPhone에 이미 있는 일정을 크게 보여 주는 앱입니다. 제작자는 글씨가 작아 불편해서 만들었으며, VS Code와 Xcode에서 Claude를 사용했다고 밝혔습니다. 이는 제작자의 공개 경험이며 개발 시간을 독립적으로 검증한 사례는 아닙니다. 앱 자체의 첫 출시도 이날이라는 뜻은 아닙니다. 초보자가 눈여겨볼 지점은 도구보다 ‘보기만 한다’는 작고 선명한 범위입니다.

읽기 불편하다는 문제가 어떻게 앱이 될까요?

제작자가 설명한 불편은 일정 관리 전체가 아니라 작은 글씨였습니다. 앱 소개도 큰 글씨와 주 단위 화면, 일정 상세 보기, 표시할 캘린더 선택을 강조합니다. App Store 설명에는 현재 보기 전용이라고 명시돼 있습니다. 기존 계정과 일정을 버리고 새 서비스로 이사하는 대신, 이미 가진 정보를 다르게 보여 주는 접근입니다.

여기서 ‘나도 모든 캘린더 기능을 만들어야겠다’고 받아들이면 출발점이 커집니다. 내게 자주 오는 긴 배송 안내, 한눈에 안 들어오는 예약 명단, 글씨가 작은 가계부처럼 이미 존재하는 정보의 불편을 먼저 찾아보세요. 새로운 데이터를 수집하지 않아도, 읽는 순간의 어려움을 덜어 주는 앱은 만들 수 있습니다.

첫 프롬프트에는 무엇을 빼야 할까요?

연습이라면 실제 일정 연결보다 가짜 일정으로 시작하는 편이 좋습니다. ‘샘플 일정 목록을 큰 글씨로 보여 주세요. 긴 제목은 여러 줄로 표시하고, 오늘을 쉽게 찾게 해 주세요. 일정 추가·수정·삭제와 로그인은 만들지 마세요’처럼 요청해 보세요. 이는 Big Calendar의 실제 제작 프롬프트가 아니라, 사례에서 가져온 학습용 제안입니다.

첫 화면이 생기면 직접 읽어 보세요. 긴 한국어 제목이 잘리는지, 같은 날 일정이 몰리면 무엇이 가려지는지, 일정이 없는 날에도 날짜를 구분할 수 있는지 확인합니다. AI에게는 ‘더 예쁘게’ 대신 막힌 화면과 기대한 결과를 함께 전달하세요. 글자를 키웠는데 화면에 필요한 정보가 사라졌다면, 문제를 해결한 것이 아니라 다른 불편으로 옮긴 셈입니다.

실제 데이터는 언제 연결하면 될까요?

샘플 화면에서 읽기 흐름을 확인한 뒤 연결하세요. Big Calendar는 기기에 추가된 캘린더를 읽는다고 설명하며, iOS 설정에 연결된 Google 캘린더도 그 경로에 포함됩니다. 앱이 별도의 Google 동기화 서비스를 새로 제공한다고 이해하면 안 됩니다.

내 앱에도 같은 구분이 필요합니다. 원본이 어디에 있고, 어떤 권한으로 읽으며, 새로고침 뒤 무엇이 바뀌는지 적어 두세요. 보기 전용이어도 일정 제목에는 민감한 정보가 있을 수 있습니다. 권한을 거절했을 때의 안내와 빈 화면을 확인하고, 공개 시연에는 실제 개인 일정 대신 샘플을 쓰는 편이 안전합니다.

기능을 더하기 전에는 사용자가 원본 화면보다 이 화면을 다시 열고 싶어 하는지 물어보세요. 보기 전용 MVP의 성과는 버튼 개수가 아니라, 특정한 순간에 더 편하게 읽히는지로 판단할 수 있습니다. 이번 글은 공개 소개를 검토한 것이며 앱을 설치해 사용성을 시험한 후기는 아닙니다.

FAQ: 제작자가 코딩을 몰랐던 사례인가요?

그렇게 확인되지는 않았습니다. 확인한 것은 Claude를 사용했다는 제작자의 설명입니다. 초보자가 따라 할 수 있는 범위 설계와 제작자의 경력은 구분해야 합니다.

FAQ: GitHub에 있으니 코드를 가져와도 되나요?

제작자는 오픈소스가 아니라고 밝혔습니다. 공개 저장소 링크가 있다는 이유만으로 앱 소스나 재사용 권한이 공개됐다고 판단하면 안 됩니다.

출처: https://news.ycombinator.com/item?id=49753106
제품 확인: https://apps.apple.com/us/app/big-calendar-see-every-event/id6801043934
관찰 시점: 2026-09-19 KST