Photo by Daniil Komov on Unsplash
Sonos 공식 앱이 macOS 지원을 끊자, IP 변호사가 Claude로 앱 만들기에 도전해서 주말 이틀 만에 Mac + iOS 앱을 동시에 완성했어.
배경: Sonos가 앱 접었고, 아내는 예쁜 걸 원했거든
Sonos가 공식 macOS 앱 지원을 종료하면서 문제가 생겼어. 집 안 스피커 제어가 안 되니까 직접 만들기로 했고, Mac 앱을 뚝딱 만들었더니 아내가 "나도 iOS 앱 갖고 싶은데, 근데 그것보다 예뻐야 해"라고 한 거야. 그래서 필요도 없는 앱을 추가로 만드는 상황이 됐어. 만든 사람은 2008년 이후로 코딩 수업을 한 번도 들은 적 없는 지식재산권 전문 변호사야.
Claude로 앱 만들기: 실제로 어떤 순서로 접근했나
시작 방식이 꽤 체계적이었어. 먼저 Claude Chat에 "이걸 만들고 싶은데, 방법 옵션과 각각의 장단점, 비용을 알려줘"라고 물어봤어. 방향이 잡히면 Sonos·Spotify API 문서를 직접 읽고 규칙을 확인한 다음 Claude Code에 먹였어. 기능을 먼저 다 잡고 나서 디자인 작업을 시작했고, Mac 앱 → iOS 앱 순서로 진행했어.
버그 추적도 독특하게 했는데, Claude에게 "프로젝트 매니저 역할 해줘. 버그 찾는 브리프 문서 작성해"라고 지시하고 코드베이스 폴더를 넘겼어. 변경사항마다 BRIEF-*.md 파일로 범위를 명확히 정의하고 '완료 기준'을 써넣는 방식이었거든. 이게 "찍어보고 고치기" 루프에서 "진단하고 패치하기" 루프로 바뀌는 핵심이었어.
결과: 완벽하지 않지만 실제로 동작해
최종 결과물은 Swift/SwiftUI 기반 약 12,200줄짜리 코드야. iOS 앱, macOS 메뉴바 앱, 공유 프레임워크 세 덩어리로 나뉘어. 완벽하진 않지만 실제로 작동하고, 아내도 예쁘다고 했어. Spotify API 429 오류로 토큰이 12시간 막히는 사고도 있었고, 시뮬레이터에서 안 잡히던 버그가 실제 폰에서 터지는 경험도 했어. 근데 그게 다 배움이었어.
따라할 수 있는 포인트
- 순서가 중요해: 기능 확정 → API 문서 확인 → 디자인 순서 지켜야 삽질이 줄어들어
- Claude를 PM으로 써: 코딩만 시키지 말고 "버그 찾는 브리프 써줘"처럼 관리 역할도 줘봐
- 시뮬레이터 맹신 금지: 실제 기기에 올려봐야 진짜 버그가 나와
- API 호출 수 미리 계산해: rate limit은 공식 문서보다 실제가 훨씬 빡빡하거든
Claude로 앱 만들기, 코딩 몰라도 '무엇을 어떻게 만들지'를 설명할 수 있으면 출발점은 충분해.
댓글
댓글 쓰기