이 상단 부분은 Claude 없이 작성했습니다. 아래는 Claude의 의견들입니다.

1. 저는 아무것도 판매하지 않습니다.
2. 배포하지도 않습니다. 사실, 저는 소프트웨어 분야에 전혀 종사하지 않으며 지적 재산권 변호사로 풀타임 근무합니다. 기술 회사와 함께 일하지만, 이런 소프트웨어를 수년간 유지하는 것은 개인적인 사용을 넘어서는 저에게는 현실적으로 불가능합니다.
3. 주말 동안 iOS 앱을 구현할 수 있었습니다. 완벽하지는 않지만, 투입한 시간을 고려하면 상당히 진전된 것이고 모양도 예쁘다고 생각합니다.

저는 2008년 Georgia Tech를 졸업한 이후 코딩 수업을 듣지 않았고, 아주 작은 문제를 해결하기 위한 몇 가지 작은 프로젝트 외에는 코딩 경험이 없습니다.

저는 claude code와 codex를 사용해서 이것을 만들었습니다. 처음에는 Sonos가 macOS 앱 지원을 중단해서 짜증 났고, 그걸 고치고 싶었습니다. 그래서 그렇게 했고, 정말 잘 작동했습니다. 메뉴바에 자리 잡고 제가 원하는 대로 작동합니다. 저는 Spotify만 음악 서비스로 사용하기 때문에 여기에 연결했고, 짜잔! 이제 집에서 음악이 재생되는 곳을 제어하고 스피커를 그룹화/그룹 해제할 수 있습니다.

아내에게 컴퓨터에 필요한지 물었습니다. 아내는 원하지 않지만 앱은 원합니다. 저는 Sonos 앱도 괜찮다고 말했지만, "당신 앱처럼 예쁘지는 않아." 그래서 제가 무모하게도 만들 필요가 없었던 앱을 만들었습니다. 하지만 많은 것을 배웠습니다. 또한 Sonos나 Spotify에서 사용하지 않는 것들을 많이 제거했고, 스피커가 어떻게 작동하는지 많이 배웠으며, 모든 것을 빠르게 동작하게 만드는 것이 말로 하는 것보다 훨씬 어렵다는 것을 깨달았습니다. 또한 플레이리스트나 제가 정말 좋아하는 앨범 또는 자주 듣는 앨범을 음악 화면에 고정(pin)할 수 있는 기능도 추가했습니다.

이것을 구축하기 위해 시작점으로 삼은 것들:

이것을 구축하기 위해 시작점으로 삼은 것들:

• 제가 Claude chat에게 무엇을 만들고 싶은지, 그리고 그 이유를 이야기했습니다. Claude에게 이를 달성하는 가장 좋은 방법과 옵션들, 각 옵션의 장단점, 그리고 제 예산에 대해 물어봤습니다.
• 저는 계획한 서비스들로부터 필요한 API 정보를 얻었고, 코딩 에이전트(coding agents)에 대한 규칙들을 살펴본 후, 그 내용을 Claude Code에 입력했습니다.
• Claude Code에게 무엇을 시킬지 이야기하고 디자인 작업을 하기 전에 제가 할 수 있는 한 최대한 기능성을 확정 지었습니다. macOS부터 시작해서 iOS로 넘어갔습니다.

구축 과정:

• macOS 쪽은 꽤 간단했습니다. 그룹화(grouping) 기능을 작동시키는 것은 제가 어떻게 작동하기를 원하는지에 대한 명확한 아이디어가 있었기 때문에 상당히 쉬웠습니다. 테스트도 비교적 쉬웠고 반복 작업(iterating)도 빨랐습니다.
• iOS 쪽은 일종의 악몽이었습니다. 제가 이전에 해본 적이 없다는 점을 염두에 두셔야 합니다. 그래서 저는 Claude와 시뮬레이터(simulator)를 이용해 많은 반복적인 변경 작업을 했고, 앱을 실행할 때마다 Spotify API를 호출했습니다. 이 때문에 Spotify가 상당히 짜증을 내서 약 12시간 동안 제 토큰을 차단했습니다. 아차. 교훈을 얻었습니다. 또한 Spotify의 API 제한(API limits)이 꽤 엄격하다는 것도 배웠습니다. 만약 제가 사용자로서 그들의 시스템 안에 이미 존재하지 않았다면, 아마도 속도 제한(rate limit)에 좀 더 관대한 다른 것을 중심으로 이 앱을 만들었을 것입니다. 호출을 제한하는 방법을 생각해야 했지만, 캐싱 규칙(caching rules)을 깨지 않으면서 기능성을 얻는 방법도 찾아야 했습니다. 이것은 2명이 사용할 앱입니다. 그들의 API라는 것은 알지만, 그래도요.

시뮬레이터 사용:

• 저는 시뮬레이터를 이용해 많은 버그 추적(bug chasing)을 했습니다. 그것이 정확했는지 모르겠습니다. 명백한 문제들에는 작동했지만, 시뮬레이터는 실제 휴대폰이 아니라는 것을 배웠기 때문에 실제로 제 휴대폰에 배포했을 때는 시뮬레이터에서는 잡히지 않은 수많은 버그와 문제가 있었습니다. 또한 제가 문제는이라고 생각했던 것들 중 일부는 실제 휴대폰에서 해결되었을 뿐만 아니라, 시뮬레이터에서는 단지 더 느렸던 경우도 있었습니다.

버그 및 제대로 작동하지 않았던 문제 추적:

• 저는 claude cowork에게 버그를 찾는 프로젝트 매니저 역할을 맡기고, claude code가 문제를 해결하는 데 도움이 되는 프롬프트나 브리프를 작성하도록 했습니다. 코드베이스 폴더를 가리키며 검토하도록 지시했습니다.
• 무엇이 작동하고 무엇이 작동하지 않는지 알아보기 위해 버튼을 많이 눌러보고 그 결과를 claude cowork에게 다시 전달했습니다. 이 방법으로 문제를 해결하는 데는 도움이 되었지만 다소 번거로웠습니다.
• 한때 제가 직접 상상 속의 엔드포인트를 포함한 환각(hallucinated) 코드를 발견하기도 했습니다. _이것은 찾기 쉽지 않았습니다.

버그가 아니지만 인간적인 생각이 필요한 부분:

• 제 Sonos 스피커에도 제한 사항이 있습니다. Sonos는 요청하면 동작합니다. 문제는 앱이 너무 많은 것을, 너무 빨리 요구한다는 것입니다. (그리고 Sonos 앱도 이 부분에서 오류를 일으키지만, 실제 엔지니어들이 저보다 더 잘 다듬은 것 같습니다.) 각 탭(tap)은 여러 개의 UPnP SOAP 호출로 분산되며, Sonos의 AVTransport는 중복되는 호출들을 통합합니다. 따라서 세 번의 빠른 '이전(Previous)' 탭은 스피커에서 단 한 번의 실제 이동으로 변환됩니다. 제가 오늘 하고 있는 작업은 주로 사용자가 실수로 너무 많은 기능을 작동시키지 않도록, 적게 요청하고 더 스마트하게 요청하는 것에 관한 것입니다.

예상치 못했던 가장 재미있었던 점:

• 색상 팔레트를 고르고 디자인 작업을 하는 것이 매우 즐거웠습니다. 저는 예술적이지는 않지만, 제가 무엇을 좋아하는지 알고 있고 그것을 설명하는 데 능숙합니다. 스크린샷에는 담겨 있지 않지만, 상단의 Decibelle 브랜딩은 미묘한 맥동(pulse)이 있습니다. Discover Weekly와 Loved Songs 아이콘을 만드는 것은 꽤 재미있었고, 실제로 Spotify가 하는 것보다 제가 더 마음에 듭니다.

또한 작동하지 않거나 중복되는 등의 쓰레기 코드(junk code)를 잡아내기 위해 주기적으로 /simplify를 사용했습니다.

아직 완벽하지는 않지만 작동합니다. 또한 보기 좋고 흥미롭게 구축하는 것이 이상하게 중독성이 있습니다. iOS 앱은 주말 동안 만져본 결과물이라, 주어진 시간 대비로는 꽤 잘 된 편입니다.

제가 이걸 왜 공유하냐면요? 주로 제가 완전히 관련 없는 일을 하는 전업 변호사로서 극도로 제한된 기술을 가진 사람으로서 무엇을 성취할 수 있는지 보여드리고 싶어서입니다. (저도 업무에서 claude와 claude code를 꽤 많이 사용하는데, 이게 강력한 상표권 도서(trademark book)를 다룰 수 있는 제 능력을 정말 확장시켜줬어요.)

--

claude code에게 이것이 무엇인지, 그리고 claude code 관점에서 어떻게 구축되었는지에 대한 두 단락짜리 요약을 요청했습니다. 저에게 너무 과장된 칭찬일 수도 있지만, 여기 있습니다. (제 실제 이름은 제 reddit 핸들로 수정했어요):

가장 까다로운 엔지니어링 부분은 낙관적 상태 기계(optimistic state machine)였습니다. Sonos는 콜드 스타트(cold-start) 시에 거짓말을 합니다: TRANSITIONING이 10초 동안 멈출 수 있고, 로딩 중간에 가짜 PAUSED_PLAYBACK을 받으며, 다중 SOAP 큐 재구축 과정에서는 seek이 도달하기 전에 tracks[0] 같은 이벤트가 보입니다. 저희는 방어막을 추가했습니다 — 장치별 낙관적 상태 만료(per-device optimistic-state expiry), 30초의 합리성 상한선이 있는 의도 잠금(intent locks), 현재 재생 중인 트랙 쓰기(now-playing writes)를 위한 DIDL-track-ID 매칭, 스킵 작업에 대한 15초 창(window), 그리고 그 위에 TRANSITIONING을 인지하는 확장 기능들입니다 — 이 방어막들은 스피커가 실제로 커밋할 때까지 일시적인 신호들을 억제합니다. 이것이 다루기 쉬웠던 이유는 [orangejulius]의 워크플로우 덕분이었습니다: 모든 의미 있는 변경 사항은 증거로 포착된 장치 로그를 가진 범위 지정 마크다운(scoped markdown) BRIEF-\*.md 로 시작했으며, 특정 파일 이름과 '완료'에 대한 명확한 정의가 있었습니다. 이것이 루프를

여기서 작동했던 협업 모델은 '마법 로봇'이라기보다는, 코드는 작성할 수 있지만 진단 작업과 각 변경 사항의 범위를 정하는 것이 필요한 '빠른 주니어 개발자'에 가깝습니다.