I Built an App That Watches Me Work (Insane Focus)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

I Built an App That Watches Me Work (Insane Focus)를 중심으로, Bluey는 남는 iPhone을 Mac과 연결해 마우스를 따라보고 화면을 가리키는 캐릭터 앱이며, 이번 작업에서는 집중을 돕는 동를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. Bluey는 남는 iPhone을 Mac과 연결해 마우스를 따라보고 화면을 가리키는 캐릭터 앱이며, 이번 작업에서는 집중을 돕는 동반자로 목적을 좁힌다.
2. 사용자가 음성으로 작업과 시간을 정하면, Mac이 30초마다 화면을 캡처해 작업 내용·경과 시간·유휴 시간·최근 판정 이력과 함께 decisions API에 보낸다.
3. API는 작업 중·작업 이탈·불확실 가운데 상태를 선택한다. 앱은 확률과 누적 이력을 활용해 짧은 우회 활동과 반복적인 이탈을 구분하도록 설계한다.
4. 개입은 매번 즉시 발생시키지 않는다. 높은 확신의 이탈이 최소 2분 이어지거나 확신이 낮은 상태가 더 오래 지속될 때 알리고, 알림 사이에는 대기 시간을 두도록 요청한다.
5. Codex로 기존 앱을 수정한 뒤 실제 기기에서 연결·타이머·이탈 알림·세션 기록을 시연한다. 다만 개발자 모드로 시간을 빠르게 진행한 데모이므로 일상적인 집중 개선 효과까지 입증한 것은 아니다.

🧩 배경과 문제 정의

Bluey는 사용하지 않던 iPhone을 Mac의 보조 화면이자 작은 동반자로 활용하려는 아이디어에서 출발했다. 기존 버전은 마우스를 따라보고 음성 요청에 따라 화면을 가리키거나 짧은 의견을 남길 수 있었지만, 제작자는 용도가 모호하다고 느꼈다.

이번 영상의 문제는 이 캐릭터를 구체적인 집중 지원 도구로 바꾸는 것이다. 사용자가 하려는 일을 먼저 말하면 앱이 화면을 주기적으로 확인하고, 짧은 우회는 허용하면서 반복적인 작업 이탈에는 복귀를 권하도록 설계한다. 누군가 곁에 있을 때 집중하기 쉽다는 제작자의 경험이 동기이며, 의료적 효과를 검증하는 영상은 아니다.

🕒 시간순 섹션별 상세정리

1. 화면 속 캐릭터를 집중 동반자로 바꾸려는 이유

• 제작자는 컴퓨터와 연결되고 마우스를 따라보는 iOS 앱 Bluey를 소개하며, 자신의 ADHD와 작업 집중을 돕는 방향으로 바꾸겠다고 보여준다. 기존 기능·새로운 목적·decisions API·앱 제작 순서로 진행할 계획이다. [00:37]
• 사용하지 않던 휴대폰을 재미있는 보조 화면으로 활용하려는 발상에, 누군가 곁에 있을 때 집중하기 쉽다는 개인적 경험을 결합했다. 기존 앱은 길게 눌러 질문하면 화면을 가리키고 짧은 의견과 소리를 내는 방식이다. [01:18]

2. 기존 기능과 iPhone·Mac 연결 구조

• 화면의 대상을 가리키거나 간단한 조사를 요청하는 모습을 보여준다. 발화자는 기존 음성 상호작용에 OpenAI Realtime API와 음성 전사 기능을 사용한다고 보여준다. [02:33]
• iOS 앱과 Mac 앱을 QR 코드로 연결하고, Mac에서 전달한 위치 정보로 캐릭터가 마우스를 따라보게 한다. 두 앱의 코드는 하나의 공개 저장소에 들어 있다. [03:43]

3. 목적을 좁히고 작은 판단용 API를 선택

• 제작자는 기존 Bluey가 귀엽지만 목적이 모호하다고 평가하며, 실용적인 집중 동반자로 바꾸겠다고 한다. decisions API는 문맥과 질문을 받아 앱의 다음 행동에 필요한 작은 결정을 내리는 도구로 묶인다. [04:42]
• 발화자는 출력 비용이 없다고 설명하고, 참일 확률을 추정하는 predicate, 정해진 선택지 중 고르는 choice, 지정 척도로 평가하는 score를 구분한다. 이번 앱에는 choice를 사용한다. [05:59]

4. 작업 선언과 30초 단위 화면 판정 설계

• 사용자가 휴대폰을 길게 눌러 할 일을 말하면 작업명과 타이머를 표시한다. Mac은 30초마다 화면을 캡처하고 프롬프트와 함께 API로 보내도록 구상한다. [06:48]
• 판정은 작업 중·작업 이탈·불확실로 나눈다. 한 번의 이탈 판정마다 끼어들기보다 판정 이력과 선택지별 확률을 누적해 개입 시점을 정하려 한다. [07:46]

5. 관련 활동을 허용하면서 비용을 추산

• 대본 작성 중 관련 주제를 조사하는 상황을 예로 들며, 직접 글을 쓰지 않는 화면도 작업에 필요할 수 있다고 보여준다. 명백한 이탈이 지속될 때 복귀를 권하는 것이 목표다. [08:18]
• 발화자는 화면 확인 100회에 약 1센트, 30초 간격으로 8시간 사용하면 약 9~10센트라고 추산한다. 이어 API 문서 링크와 기존 저장소를 포함한 Codex용 수정 프롬프트를 보여준다. [09:08]

6. 맥락 입력과 알림 기준을 프롬프트로 구체화

• 기존 구조와 기능을 재사용하면서, 화면 캡처에 작업 내용·경과 시간·유휴 시간·최근 확인 이력을 함께 보내도록 요청한다. 관련 튜토리얼 시청은 작업을 지원할 수 있다는 예시로 맥락 판단을 강조한다. [10:15]
• 확신이 매우 높은 이탈은 최소 2분, 확신이 낮으면 3~4분 정도의 반복을 고려하도록 제안한다. 짧은 우회를 허용하고 알림 사이에 대기 시간을 두는 알고리즘까지 구현하도록 요청한다. [10:54]

7. 앱 수정 실행과 실제 기기 연결

• 프롬프트를 넣고 두 앱을 수정·테스트해 컴퓨터와 휴대폰에서 실행하도록 요청한다. 제작자는 약 18분 동안 작업한 뒤 결과를 확인한다. [11:30]
• iPhone과 Mac을 연결하고 음성으로 앱 제작 작업을 시작한다. 일시정지·종료·집중 관련 조작과 작업 상태가 표시되는 모습을 보여준다. [12:42]

8. 타이머 중심으로 화면을 다듬고 테스트 가속

• 5분 작업을 설정한 뒤 타이머가 너무 작다고 지적한다. 오른쪽 아래에 큰 흰색 타이머를 놓고 조작 버튼은 왼쪽 아래의 작은 아이콘으로 바꾸도록 요청한다. [13:32]
• 빠른 검증을 위해 시간이 4배속으로 진행되는 개발자 모드를 추가했다고 보여준다. 다시 앱 제작 작업을 시작하고 첫 판정이 작업 중으로 표시되는지 확인한다. [14:12]

9. Twitter 이탈 알림과 세션 기록 확인

• 작업에서 벗어나 Twitter로 이동하자 앱이 현재 활동이 선언한 작업과 달라 보인다며 복귀를 권한다. 제작자는 이를 통해 이탈 알림이 작동하는 모습을 확인한다. [14:41]
• 세션을 종료하자 표시된 7분 30초 동안의 상태 기록과 구간별 이탈 내역이 나온다. 제작자는 앱이 기본적으로 30초마다 API로 작업 여부를 판단한다고 다시 보여준다. [15:07]

10. 책상 위 최종 사용 모습과 공개 안내

• 휴대폰을 모니터 아래에 설치하고 에세이를 20분간 쓰겠다고 말해 타이머를 시작한다. 개발자 모드가 켜진 상태에서 Twitter로 이동하자 에세이 초안으로 돌아가자는 알림이 나온다. [16:05]
• 세션 요약에서 작업 중은 초록색, 이탈은 갈색으로 표시되는 모습을 보여준다. QR 코드 연결의 간편함을 강조하고 변경 사항을 GitHub에 올려 시청자도 자신의 Bluey를 만들 수 있게 하겠다고 마무리한다. [16:38]

🧾 결론

• 핵심 변화는 기능을 계속 추가하는 대신, 범용 캐릭터 앱에 ‘현재 작업으로 돌아오도록 돕는다’는 구체적인 역할을 부여한 것이다.
• 화면 한 장의 판정보다 작업 맥락, 반복된 이탈, 확신도, 개입 간격을 함께 다루는 설계가 사용자 경험의 중심에 놓인다.
• 영상에서는 Twitter로 이동했을 때 복귀를 권하는 동작과 세션별 상태 기록을 확인한다. 장기적인 생산성 향상이나 ADHD 증상 개선은 별도 검증이 필요하다.

📈 투자·시사 포인트

• 발화자는 100회 화면 확인에 약 1센트, 8시간 사용에 약 9~10센트라는 추산을 제시한다. 작은 판단을 반복하는 기능의 비용 가능성을 보여주지만, 전체 운영비나 수익성을 검증한 자료는 아니다.
• 남는 스마트폰과 기존 Mac을 연결하는 방식은 별도 전용 기기를 만들지 않고도 화면 밖의 캐릭터 동반자 경험을 구현하는 사례다.
• 제품의 차별점은 상태 분류 자체뿐 아니라 언제 개입하고 얼마나 기다릴지를 정하는 로직에도 있다. 관련 자료 조사까지 이탈로 오인하면 사용성이 떨어질 수 있다.
• 기존 앱 구조와 기능을 재사용하고 Codex로 수정한 과정은 구체적인 사용 목적을 빠르게 시제품으로 옮기는 사례다. 영상에는 시장 규모·유료 전환·유지율 등 투자 판단에 필요한 사업 지표는 제시되지 않는다.

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

• decisions API의 제공 범위, 언급된 모델명, 출력 비용 무료 정책과 화면 확인 단가는 영상 속 설명이다. 실제 사용 전 공식 문서와 적용 조건을 확인해야 한다.
• 화면과 작업 맥락을 함께 보도록 요청했지만, 관련 자료 조사와 무관한 활동을 얼마나 정확하게 구분하는지에 대한 정량 평가나 오탐률은 제시되지 않는다.
• 시연에는 4배속 개발자 모드가 사용된다. 화면에 표시된 세션 시간과 알림 발생 속도를 일반 모드의 실제 경과 시간으로 해석하면 안 된다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 공개 저장소와 연결된 프롬프트를 확인하고, Mac·iOS 앱의 실행 조건과 OpenAI API 키 설정 방법을 점검한다.
• decisions API의 실제 입력 형식·선택 결과·확률 제공 방식·요금을 공식 문서에서 확인한다.
• 작업 선언, 30초 화면 확인, 세 가지 상태 판정, 반복 이탈 알림, 알림 후 대기 시간이 실제 구현에서 어떻게 연결되는지 확인한다.
• 일반 모드에서 작업 수행·관련 자료 조사·무관한 오락·유휴 상태를 각각 시험하고, 잘못된 개입과 놓친 이탈을 기록한다.

❓ 열린 질문

• 관련 영상 시청이나 자료 조사를 작업의 일부로 인정하려면, 사용자가 작업 목표를 어느 정도 구체적으로 설명해야 할까?
• 높은 확신에서 최소 2분, 낮은 확신에서 3~4분이라는 개입 기준은 실제 사용에서도 적절하며 개인별 조정이 가능할까?
• 캐릭터의 존재감과 복귀 알림은 장기간 사용했을 때 집중을 돕는가, 아니면 익숙해지거나 방해 요소가 되는가?