Are you really still using the CLI?!

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

CLI는 여전히 클라이언트 작업에 쓰지만, 일상 개발의 중심은 작업 과정을 확인하고 개입할 수 있는 T3 Code로 이동하고 있다.

📌 핵심 요점

1. CLI와 T3 Code는 용도에 따라 병행한다. CLI는 클라이언트 작업에 유지하고, 일상적인 제작은 T3 Code에서 주로 처리한다. 선택의 핵심은 작업 가시성이며, T3에서 만든 저장소를 Clear Mud HQ로 넘겨 후속 작업을 이어가기도 한다.
2. 인터페이스와 실제 실행 환경을 구분해야 한다. T3 Code는 작업에 접근하는 인터페이스이고, 에이전트 도구와 로그인은 각 컴퓨터에 필요하다. 작업은 시작한 컴퓨터에 남으므로 장시간 작업은 VM, 짧은 작업은 노트북에서 실행하는 구성을 고려한다. 원격 연결은 Tailscale을 선호하지만 T3 Connect의 실제 보안 사고를 제시한 것은 아니다.
3. AI 영상 편집의 구현 경로는 작업 기록으로 확인했다. 처음에는 Hyperframes의 기여를 추정했지만, 실제 제작은 자체 FFmpeg 파이프라인을 사용했다. 최종 렌더링도 Mac에서 수행됐다. 컷 편집은 좋아 보였으나 시청 지속률 검증은 없고, 화면 잘림·재렌더링·발열 문제가 남았다.
4. 편집 자동화의 목표는 녹화 시간을 확보하는 것이다. 화면 구성, 브랜드 스타일, 음향, 첫 3초 설계를 재사용 가능한 스킬로 정리하려 한다. AI 역사 교육 채널 ABC Vault에는 OpenClaw 에이전트 팀을 활용할 계획이지만, 제작 체계 구축과 콘텐츠의 독창성 확보는 앞으로의 과제다.
5. Terra의 속도와 낮은 비용은 요구사항 충족 여부와 함께 평가한다. 두 실무 과제에서는 빠른 처리와 10센트 미만의 비용이 강점으로 언급됐지만, 요구사항을 생략하는 경향도 관찰됐다. 이를 계기로 개인 도구와 데모 제작에도 PRD를 다시 적용하고, 동일한 도구 조건에서 노력 수준별 결과를 비교하려 한다.

🧩 배경과 문제 정의

• 클라이언트 작업에는 여전히 CLI를 사용하지만, 일상적인 개발 작업은 T3 Code 중심으로 옮겨가고 있다. 작업 과정을 얼마나 투명하게 확인하고 제어할 수 있는지가 도구 선택의 기준이다.
• 영상 편집에 드는 시간을 줄여 더 많은 영상을 녹화하려 한다. 초기 AI 편집 결과는 긍정적이지만, 기존 편집보다 나은지 판단할 시청 지속률 데이터는 없다.
• 장편 영상 편집 과정을 재사용 가능한 스킬로 정리하려 한다. 화면 구성, 브랜드 일관성, 음향, 도입부 설계를 실제 편집본에 적용하며 개선하는 단계다.
• AI 역사와 기업을 다루는 교육형 채널도 구상하고 있다. 제작 자동화를 확대하되 콘텐츠의 독창성과 흥미를 확보해야 한다는 과제가 남아 있다.

🕒 시간순 섹션별 상세정리

1. Clear Stream의 송출 상태와 댓글 표시 문제

• Clear Stream을 개발하는 과정에서 버그가 발생했다. X 송출 실패 오류는 방송을 늦게 시작한 것과 관련된 것으로 파악했고, 댓글 수신과 고정한 댓글을 회색으로 표시하는 기능은 작동했다. [00:40]
• 방송 화면에 댓글을 자동으로 표시하는 기능을 추가했지만, 화면 왼쪽 아래 공간을 너무 많이 차지해 크기와 표시 방식을 조정할 필요가 있었다. [03:13]

2. 클라이언트 작업에는 CLI를 유지하고 일상 작업은 T3 Code로 이동

• CLI는 주로 Herder를 통한 클라이언트 작업에 계속 사용한다. 그 밖의 작업은 대부분 T3 Code에서 처리하고 있어, 영상 제목의 CLI 사용 여부 질문은 농담에 가깝다. [03:23]
• 방송 댓글은 한 줄 중심으로 간결하게 표시하고, 배경 오버레이를 없애거나 그림자로 대체하는 방향을 검토한다. 화면 점유 면적을 줄이는 것이 목적이며, 이 시점에는 계획만 요청했다. [04:18]

3. 장편 영상 편집 스킬은 구현보다 조사와 요구 정리부터 시작

• 기존 테스트 디렉터리의 영상을 간단한 프롬프트로 두 차례 수정한 결과는 예상보다 좋았다. 이 편집 접근을 장편 영상용 스킬로 정리할 가치가 있는지 검토하려 한다. [06:03]
• 곧바로 스킬을 만들기보다 먼저 대화로 방향을 정하고, 참고 저장소와 추가 조사를 바탕으로 출발점을 찾도록 요청했다. [06:33]

4. T3 Code의 장점은 CLI와 이어지는 작업 가시성

• 일반적인 채팅형 도구는 작업 내용을 숨기거나 사용자가 개입하기 어렵게 만든다는 시청자 의견에 동의했다. T3 Code에서는 작업 내용을 확인할 수 있어 CLI의 연장처럼 느끼며, 세션 상태를 알 수 없는 제약은 아직 경험하지 못했다. [08:02]
• T3 Code를 주력으로 사용하지만 전체 기능을 충분히 시험한 상태는 아니다. 새 MacBook과 서버 랙의 재활용 노트북에 설치했고, VM에도 설치할 예정이다. [08:38]

5. 원격 환경 연결은 T3 Connect보다 Tailscale을 선호

• 여러 T3 Code 환경은 T3 Connect 대신 Tailscale로 연결할 계획이다. NAS의 간편 연결 기능을 예로 들며, 편리한 원격 연결 기능이 향후 보안 문제로 이어질 가능성을 우려했다. [09:01]
• 네트워크의 장치가 침해되면 T3 Connect에 부여한 시스템 접근 권한이 피해를 키울 수 있다고 본다. 실제 사고를 확인한 주장은 아니며, 편의 기능에 의존하기보다 직접 연결 환경을 구성하려는 선택이다. [09:48]

6. AI 편집 결과는 유망하지만 성과 검증은 남아 있음

• 새 편집본은 컷 편집이 더 나아 보였지만, 시청 지속률 데이터는 없어 실제 성과를 판단할 근거가 부족하다. [12:08]
• 당일 영상 두 편을 녹화할 계획이며, 그중 하나를 AI로 편집해 다음 날 게시하고 반응을 확인하는 방안을 고려한다. 영상 주제와 실행 여부는 아직 확정되지 않았다. [12:20]

7. Hyperframes 활용 추정은 실제 작업 기록으로 정정

• 처음에는 Hyperframes가 Opus 5.5의 영상 편집 결과를 좋게 만든 핵심일 수 있다고 추정했고, 기존 테스트 영상에도 사용됐다고 생각했다. [13:34]
• 작업 기록을 확인하자 Hyperframes의 스킬 문서와 버전만 확인했을 뿐, 실제 영상은 자체 FFmpeg 파이프라인으로 제작한 것으로 드러났다. Hyperframes가 렌더링한 부분은 없었고, 재사용한 것은 자막 전사용으로 캐시된 Whisper 모델뿐이었다. [15:11]

8. 편집본의 가독성과 브랜드 일관성을 구체적으로 수정

• 검토 중인 영상의 약 36초 지점부터 화면 공유 위에 놓인 글자가 배경에 묻혀 읽기 어려웠다. [18:28]
• 인물 영상을 모서리가 크게 둥근 세로 직사각형으로 잘라 왼쪽에 배치하고, 오른쪽에는 화면 공유를 놓으며 기존 배경을 활용하는 구성을 제안했다. 모서리 반경은 약 55를 예로 들었다. [18:50]

9. 배경음악을 빼고 첫 3초를 썸네일처럼 설계

• 일반 영상에는 평소 배경음악을 넣지 않으므로, 편집본에서도 음악을 제거하고 효과음에 집중하도록 했다. [20:36]
• 유튜브에서는 썸네일에 관심을 가진 시청자가 미리보기까지 보게 되므로, 영상 첫 몇 초도 썸네일처럼 설계해야 한다고 본다. 첫 3초에는 세 가지 요소에 집중하는 원칙을 적용하려 한다. [20:53]

10. 편집 스킬 개선의 목적은 제작 시간 단축

• FFmpeg 스킬을 Puddle에 추가할 필요가 있다고 판단했다. 평소에는 영상보다 썸네일을 먼저 완성하지만, 이를 편집 절차에 어떻게 반영할지는 추가 설명을 미뤘다. [22:09]
• 편집에 많은 시간이 들어 녹화량이 제한되고 있다. 스킬과 제작 과정을 다듬어 편집 시간을 줄이면 더 많은 영상을 녹화할 수 있을 것으로 기대한다. [22:46]

11. ABC Vault는 AI 역사를 다루는 자동화 지향 채널

• ABC Vault는 AI Business Chronicles를 뜻하며, 겨울 공개를 계획하고 있다. 첫 게시일은 아직 정해지지 않았다. [23:07]
• AI와 관련 기업의 역사를 다큐멘터리·교육 형식으로 다루며, OpenAI의 역사와 창립 멤버 등이 소재가 될 수 있다. 얼굴이 나오지 않는 채널로 구상하고 있고, 직접 내레이션을 할지는 미정이다. [23:27]

12. 오래 준비한 채널 구상에도 독창성과 흥미가 필요

• 초기 AI 활용은 영상과 사진 등 창작 중심이었고 Stable Diffusion도 중요한 도구였다. 당시에는 기술이 충분하지 않았다고 느꼈으며, 오래 보유한 채널 구상을 이제 실행하려 한다. [25:05]
• 유튜브가 이런 유형의 콘텐츠에 대한 단속을 강화하고 있다고 보므로, 독창적이고 흥미로우며 복제한 콘텐츠처럼 느껴지지 않게 만들어야 한다고 판단한다. 유사한 채널이 있는지는 아직 조사하지 않았다. [25:38]

13. 영상 제작 저장소는 기능과 악성 요소를 함께 검토

• Remotion은 이미 보유하고 있으며, FFmpeg 관련 자료를 포함한 여러 도구와 저장소를 추가로 살펴본다. 모든 링크를 직접 검토하기보다는 관련 게시물을 에이전트에 전달하는 방식을 택했다. [26:31]
• 저장소들에서 배울 만한 내용을 찾는 동시에 악성 요소가 있는지도 검사하도록 요청했다. 이 구간에는 검사 결과가 나오지 않는다. [27:35]

14. 포르투갈어는 사용 경험이 쌓여도 계속 학습 중

• 포르투갈을 떠난 지 6개월이 지나 언어 감각이 조금 무뎌졌다고 느낀다. 매년 방문할 때마다 대화가 더 자연스러워지지만, 이해하지 못하는 표현은 가족과 지인에게 물어본다. [28:50]
• 간단하게 표현할 말을 찾지 못해 다른 말로 풀어 설명할 때도 있다. 일상적인 의사소통은 가능하지만 학습은 계속하고 있으며, ‘Tuga’라는 표현도 이번 대화에서 처음 접했다. [29:04]

15. 대기 중 Puddle의 새 브랜치 작업으로 전환

• 다른 작업의 결과를 기다리는 동안 Puddle을 수정하는 쪽으로 관심을 돌렸고, 새 브랜치를 통합하고 있다고 언급했다. 처리 구간은 이 설명 도중 끝나므로 구체적인 변경 내용이나 결과는 확인되지 않는다. [29:59]

16. Puddle에 에이전트 간 인계 문서 동기화를 구상한다

• 한 시스템에서 쌓인 대화 맥락을 인계 문서로 작성해 Puddle의 agents 디렉터리에 넣고, 다른 시스템이나 서버의 에이전트가 동기화된 문서를 읽도록 하는 방식이다. 수동 복사와 붙여넣기를 줄이는 것이 목적이다 [30:09]
• 이 인계 계층은 아직 시험하지 않았으며, 실제로 얼마나 유용할지는 사용하면서 확인해야 한다 [30:50]

17. T3 환경마다 작업을 유지하고 실행 위치를 선택한다

• T3 Code가 주로 사용하는 도구가 됐지만 특정 용도에서는 여전히 CLI를 사용한다 [32:02]
• 각 T3 환경은 작업, 프로젝트 폴더, 로그인을 자체적으로 보관한다. 작업은 시작한 컴퓨터에 남고 해당 컴퓨터가 잠들면 함께 멈추며, 코드는 GitHub에 push하고 다른 환경에서 pull하는 방식으로 옮긴다 [33:05]

18. T3 Connect의 접속 제한과 Tailscale 대안을 검토한다

• T3 Connect를 공개된 진입점으로 설명하며, 메시지가 Cloudflare의 중간 지점을 거친다고 보여준다. 무료 이용에서 기기 또는 환경을 세 개보다 많이 연결하려면 유료 이용이 필요하다고 이해했지만, 정확한 가격은 확인하지 않았다 [35:41]
• Tailscale을 이용하면 T3 Connect를 거치지 않는 구성이 가능하다고 본다. NAS의 간편 접속 기능에서 발생하는 취약점 문제를 떠올리며 공개 접속 경로를 우려하지만, T3에서 실제 사고가 발생했다고 주장하지는 않는다 [36:06]

19. 환경별 에이전트 설치와 접근 권한을 분리한다

• T3 Code는 작업에 접근하는 인터페이스이고 실제 작업은 에이전트 도구가 수행한다. 각 컴퓨터에 필요한 도구를 설치하고 해당 환경에서 로그인해야 하며, 업무용과 개인용 로그인도 별도 폴더로 함께 유지하는 구성을 보여준다 [36:42]
• 터널 규칙으로 다른 서버 접근을 막고, VM에는 필요한 키만 제공한다. 페어링 링크와 비밀번호를 공유하거나 화면에 노출하지 않으며, T3를 업데이트하고 root 대신 일반 사용자로 실행하는 원칙을 확인한다 [37:12]

20. 교육용 도식에 브랜드 스타일을 반영하는 스킬을 구상한다

• 교육 자료와 흐름도를 위한 새 스킬을 만들고, 기존 CM 프로젝트와 프런트엔드 스킬에서 브랜드 성격과 시각 스타일을 가져오려 한다. 기존 스타일이 창의성을 제한해서는 안 된다는 조건도 붙인다 [41:11]
• 기존 학습용 그래픽을 다시 만들되 이모지는 사용하지 않고 아이콘이나 다른 그래픽으로 대체하도록 요구한다 [42:02]

21. 영상 편집 작업의 진행 상태와 음성 분석 방식을 확인한다

• 장문 영상 편집 작업은 약 20분이 지난 시점에도 끝나지 않았다. 해당 편집에는 실제로 CLI에서 Claude Code를 실행한 경로도 사용했다 [42:18]
• 검토 중인 편집 접근에는 단어별 타이밍을 얻기 위한 Parakeet MLX가 포함되며, 35분 분량의 영상에 약 40초가 걸린다는 설명이 나온다. 자막에서 상당수 추임새가 빠지므로 제거할 추임새는 오디오에서 직접 감지해야 한다는 점도 강조한다 [43:44]

22. 롤링 채팅의 표시 시간과 시각 요소를 단순화한다

• 채팅 항목은 60초 뒤 사라지도록 하되, 메시지가 빠르게 쌓여 위로 밀려나면 타이머가 끝나기 전에도 자연스럽게 사라지는 동작을 선호한다 [44:36]
• 사용자별 프로필 사진 대신 YouTube 같은 채팅 출처의 로고만 표시하는 방향을 제안한다. 처음에는 시청자 의견을 구하며 유보적으로 판단했지만, 이후 동의 의견을 확인한다 [45:02]

23. 새 BRB 화면에서 마이크 입력 문제를 확인한다

• 수동으로 장면을 구성하는 대신 코딩으로 만든 새 BRB 화면을 사용한다 [46:12]
• BRB 장면의 마이크가 오래된 BRB 루프 입력을 가리키는 것으로 보여 음성 전달을 점검한다. 입력을 조정한 뒤 시청자에게 소리가 들리는지 확인하며 문제를 좁혀 간다 [47:32]

24. 플로팅 툴바로 방송 중 조작을 줄인다

• 플로팅 바에서 화면 전환, 댓글 고정 해제, 감사 카드 표시 등을 빠르게 실행한다. 감사 카드는 이전 채팅을 다시 찾아 올라가는 수고를 줄이고, 마우스 따라가기 기능은 단축키로 켜고 끌 수 있다 [48:37]
• 툴바를 이용하면 OBS에 직접 들어가지 않고도 조작할 수 있다. 평소에는 자신의 화면에만 보이도록 사용하고, 필요할 때 방송과 녹화에도 표시한다 [49:18]

25. 오디오 소스 재사용과 장면별 제거 기능을 요구한다

• BRB 화면용으로 추가한 마이크 입력이 모든 장면에 들어가면서 음성이 달라지는 문제가 발생한다. 중복 입력을 제거하는 과정에서 오디오 소스 관리의 문제를 발견한다 [50:03]
• BRB 장면에는 기존 마이크와 노이즈 감소 필터가 적용된 입력이 없었고, 다른 장면의 기존 소스를 선택하는 기능도 쉽게 찾지 못했다. 새 하드웨어 입력을 추가하는 기능과 저장된 소스를 재사용하는 기능을 모두 요구한다 [51:09]

26. BRB 중 음악 유지와 데스크톱 소리 노출을 함께 고려한다

• BRB 상태에서도 음악이 계속 재생되기를 원하지만, 데스크톱 오디오를 그대로 사용하면 자리를 비운다고 알린 뒤 컴퓨터에서 하는 다른 작업의 소리까지 방송될 수 있다. 적절한 처리 방식은 추가 검토 대상으로 남긴다 [53:35]

27. 추가 도구 도입을 보류하고 기존 의존성을 정비한다

• 가격을 제시하지 않은 채 에이전트 크레딧을 쓰도록 유도한다는 검토 내용을 받아들여, 관련 항목을 채택하지 않기로 한다 [54:25]
• Impeccable은 설치하지 않고 ComfyUI도 건너뛰며, Blender용 MCP는 당분간 보류한다. Playwright가 이미 담당하는 기능도 중복 도입하지 않는다 [54:45]

28. 영상 3차 편집본의 렌더링 위치를 확인하려 한다

• 3차 편집본은 전체 318개 세그먼트 중 47개를 렌더링한 상태다. 렌더링이 자신의 로컬 하드웨어에서 실행되는지 확신하지 못해 설명을 요청하며, 이 시점에는 실행 위치가 확인되지 않는다 [55:33]

29. 오버레이 편집과 방송 노출 상태를 조정한다

• 오버레이 외형을 수정하는 화면을 마련했으며, 서로 같은 모양으로 표시되는 아이콘은 바꾸려 한다. 설정을 해제해 해당 화면이 방송에서 사라지도록 조정한다 [56:26]
• 오버레이가 너무 많다는 피드백에 따라 불필요한 표시를 제거한다. 개선한 새 댓글 영역은 아직 실제 방송에 적용할 수 없는 상태다 [57:35]

30. 방송 종료 버튼에 길게 누르기와 툴바 표시 제어를 추가한다

• 플로팅 툴바의 방송 종료 버튼을 실수로 누를 가능성에 대비해 확인 동작을 요구한다. 팝업 확인과 길게 누르기를 비교한 뒤, 몇 초간 누르면 진행 막대가 차오르는 방식을 선택한다 [58:14]
• 툴바 오른쪽에는 방송 노출 여부를 빠르게 바꾸는 눈 모양 제어를 추가하려 한다. 기본 숨김 상태는 빗금 친 눈으로 나타내고, 필요할 때 즉시 표시할 수 있게 한다 [58:51]

31. 한쪽 채널로만 들리는 오디오를 다시 점검한다

• 왼쪽 스피커에서만 소리가 난다는 피드백을 받고 실수로 남아 있던 다른 입력을 제거한다. 조정 후에는 정상화됐을 것으로 판단하지만, 자막에는 최종 확인 결과가 제시되지 않는다 [59:17]

32. 보류했던 ComfyUI를 다시 살펴보려 한다

• 앞서 도입을 건너뛴 ComfyUI를 다시 살펴보고 직접 시험해 보려 한다. 처리 구간 끝까지 실제 실행 결과나 채택 여부는 나오지 않는다 [59:47]

33. ComfyUI를 새 MacBook에 설치하고 에이전트로 학습하기

• ComfyUI 학습과 실행에 Claude Code의 도움을 활용할 계획이며, 설치 위치는 서버보다 새 MacBook Pro가 적합하다고 판단한다. [1:00:28]
• ComfyUI의 커스텀 노드를 직접 만들거나 에이전트에게 제작을 맡길 수 있다는 점을 활용하려 한다. [1:01:04]

34. 채팅 작성자를 계정 이름으로 표시하기

• 채팅 메시지의 작성자가 계정 이름 대신 ‘you’로 표시되는 문제를 발견한다. [1:01:22]
• 스크린샷을 근거로 실제 계정 이름을 표시하도록 수정 요청을 남긴다. [1:01:35]

35. Qwen 모델의 비교 기준과 하드웨어 요구량 확인하기

• 관심을 끄는 Qwen 모델을 찾고 하드웨어 요구 사항을 확인하려 하지만, 자막에서 모델명이 불명확하게 표기된다. [1:02:13]
• 성능 비교 대상으로 제시된 Opus 4.6보다 Opus 5.5와의 비교가 필요하다고 지적한다. [1:02:38]

36. Apple Silicon과 MLX를 기준으로 구형 Mac의 활용 가능성 검토하기

• Nvidia 기준의 요구량만으로는 판단하기 어려워 Apple Silicon에서의 실행 조건을 추가로 찾는다. [1:03:25]
• MLX의 의미와 실행 방식에 대한 이해가 부족하며, 기존 M1 Max MacBook을 Qwen 모델 제공용으로 활용할 수 있을지 궁금해한다. M1에 관한 정보가 보이지 않아 실행 가능성은 확정하지 않는다. [1:04:28]

37. 128GB MacBook에서 로컬 모델을 시험할 계획

• 새로 개봉한 128GB 메모리 장비를 언급하고, 모델 실행 시 초당 토큰 처리량도 확인하려 한다. 구체적인 처리 속도는 자막에 제시되지 않는다. [1:05:18]
• 이 MacBook에서 시도할 로컬 모델은 대부분 MLX를 사용하게 될 것으로 이해한다. [1:05:50]

38. 영상 렌더링은 클라우드가 아닌 Mac에서 수행된다

• 진행 중인 영상 편집의 최종 렌더링은 전부 사용자의 Mac에서 이루어지며, 클라우드로 보내지 않는다는 답변을 확인한다. [1:06:52]
• 렌더링 작업에는 원본 카메라·화면 녹화의 디코딩, 자르기, 확대, 위치 조정, 그래픽 합성이 포함되며, 진행 상태는 약 절반이다. [1:07:14]

39. 고객 업무에 맞춰 방송 시작 시간을 조정하기

• 미국에서는 고객 업무와 리테이너 계약에 따른 돌발 대응 때문에 아침 일정이 흔들려 방송 시작이 늦어졌다. [1:07:30]
• 최근 시작 시간은 태평양 시간 오전 10시부터 정오 사이이며, 포르투갈 복귀 후에는 태평양 시간 오전 10시, 현지 오후 6시 무렵으로 일정하게 맞출 가능성이 높다. 여러 나라에서도 비슷한 시간대를 유지하려는 선택이다. [1:07:53]

40. CLI는 계속 사용하지만 T3 Code의 비중이 커진다

• CLI를 여전히 사용하지만, T3 Code와 비교하면 사용 빈도가 훨씬 낮아졌다고 드러낸다. CLI 사용자를 공격하려는 취지는 아니라는 설명도 덧붙인다. [1:08:32]

41. Qwen과 Gemma 기반의 추가 모델 탐색하기

• ‘Ornith 1.5’로 언급되는 모델을 살펴보며, Qwen과 Gemma를 기반으로 개발됐다는 정보를 확인한다. [1:09:02]
• 직접 테스트할 대상으로 남겨 두고 Hugging Face 홈페이지의 인기 모델도 살펴보려 한다. 실제 성능 검증 결과는 제시되지 않는다. [1:10:04]

42. Clear Stream의 BRB 오디오와 미검증 기능을 수정 목록에 넣기

• BRB 화면에서 음성이 왼쪽 채널로만 들린다는 피드백을 받는다. 수정하려면 앱을 닫아야 하므로 방송이 끝난 뒤 처리할 할 일 목록에 기록한다. [1:11:07]
• 방송 전에 충분히 테스트하지 못한 추가 기능이 있으며, 처음에는 방송 중 확인하기 어렵다고 판단해 금요일 테스트를 고려한다. [1:11:28]

43. 방송 중 설정 저장을 시험하고 YouTube 반영을 확인하기

• 방송 관리 기능에서 설정 저장을 시도한 결과, YouTube에는 저장됐지만 X에는 저장되지 않았다고 확인한다. 이어 YouTube에서 실제 반영 여부를 점검한다. [1:11:53]
• YouTube 설정 변경이 적용된 것을 확인하며, Clear Stream이 이미 상당한 시간을 절약해 준다고 평가한다. [1:12:47]

44. 수확기에는 방송을 잠시 쉬어야 할 가능성

• 수확기 동안에는 라이브 방송을 잠시 중단해야 할 수도 있다. 수확이 끝나면 대체로 기존 일정을 유지할 계획이다. [1:13:08]

45. 번거로운 업무에도 AI 도움을 확대하기

• Claude나 ChatGPT로 번거로운 일을 처리할 생각을 하지 못했다는 반응에, 그런 업무에도 AI를 더 적극적으로 활용하라고 권한다. 구체적인 처리 절차나 성과는 제시되지 않는다. [1:14:11]

46. T3 Code에서 프로젝트별 필터와 고정 기능 활용하기

• T3 Code의 왼쪽 목록은 프로젝트별로 필터링하고 전환할 수 있으며, 표시 방식도 조정할 수 있다. 현재 목록이 복잡한 이유는 여러 프로젝트를 동시에 진행하며 전체 프로젝트를 표시하고 있기 때문이다. [1:14:25]
• 자주 사용하는 프로젝트는 위에 고정하고, 완료되거나 이미 운영 중인 작업은 정리하는 방식으로 관리한다. [1:14:54]

47. 교육용 그래픽의 배치를 중앙 정렬로 수정하기

• 새 그래픽에는 애니메이션까지 생성됐지만, 중앙에 배치되지 않았고 CM 프로젝트의 스타일을 지나치게 가져왔다고 판단한다. [1:15:14]
• 교육용 설명과 흐름도에서는 한쪽으로 치우친 정렬보다 중앙 정렬이 적합하다고 보고 재작업을 요청한다. 문서를 읽는 상황과 시각적으로 흐름을 이해하는 상황을 구분한 요구다. [1:15:46]

48. BRB 화면을 시험하며 편집 완료를 기다리기

• 어머니에게 다시 전화하기 위해 잠시 자리를 비우면서 새 BRB 화면을 시험한다. 약 5분 뒤 돌아올 예정이며, 그동안 영상 편집도 끝나기를 기대한다. [1:16:29]

49. 버전 3 미리보기 실패와 이전 버전 대체

• 렌더링이 끝나지 않아 새 미리보기가 로드되지 않는다. 버전 3을 불러오지 못하면서 버전 2가 기본으로 표시된다. [1:32:26]

50. 렌더링 중 발열과 M1 장비의 성능 한계

• 영상 지연과 함께 M1 노트북이 만지기 뜨거울 정도로 달아오른다. 덮개를 열고 선풍기로 공기 흐름을 늘리지만, 방송이 안정됐는지는 확실하지 않다. [1:35:42]
• 장비가 조금씩 식기 시작한다. 부하가 클 때는 덮개를 열어 두는 편이 낫다는 경험을 바탕으로, M5도 도킹할 때 덮개를 열어 보조 화면으로 활용할 계획이다. [1:36:20]

51. 덮개 개방 이후 커진 마이크 소음

• 같은 오디오 인터페이스를 사용하는데도 바람 소리가 크게 들어온다. 화면과 BRB 장면을 전환해 확인하지만, 소음은 바람 터널처럼 들릴 정도로 심하다. [1:39:41]
• 덮개를 닫는 시점의 오디오를 다시 확인한 결과, 덮개를 열면서 마이크가 활성화된 것으로 추정한다. 선풍기 위치는 그대로였으며, 이후에는 덮개를 닫아 두기로 한다. [100:59] [1:39:56]

52. CLI·T3 Code·HQ의 역할 분담

• CLI는 여전히 클라이언트 작업에 사용하지만 일상적인 기본 작업 도구로는 쓰지 않는다. T3 Code에서 무언가를 만든 뒤 저장소를 Clear Mud HQ에 넘겨 후속 작업을 이어가는 방식이다. [102:28] [1:40:11]
• 필요하면 T3에서 HQ 소스 코드를 수정하고, 기존 작업의 빠른 수정에는 내부 빌드 탭도 자주 사용한다. 빌드 벤치를 더 직관적으로 개선하려는 목적이며, T3가 HQ를 대체하는 관계는 아니다. [102:58] [1:40:26]

53. Terra의 속도·비용과 요구사항 누락 문제

• Terra 평가에는 소규모·중견 기업, 개인 사업자, 창업자를 겨냥한 두 가지 실무 과제가 쓰인다. 오래된 기존 웹사이트를 다시 만드는 작업과 도구 모음을 구축하는 작업이며, 빠른 속도와 10센트 미만의 비용이 강점으로 드러난다. [104:28] [1:40:41]
• Terra는 빠르고 효율적이지만 요구사항을 생략하는 경향이 있다는 평가다. 모델 자체가 퇴보했다는 뜻보다는 프롬프트를 더 구체적으로 작성할 필요가 있다는 의미이며, 기본 프롬프트와 PRD 기반 프롬프트의 차이를 시험하고 있다. [105:18] [1:40:49]

54. 노력 수준을 비교하기 위한 벤치마크 조건

• 자체 제작한 벤치마크 도구에서 하나의 프롬프트로 여섯 가지 노력 수준을 비교한다. 어떤 모델과 노력 수준이 작업에 적합한지 판단하는 것이 목적이다. [106:18] [1:40:59]
• 메모리, 스킬, Claude·Agents 관련 지침 파일의 영향을 제외한 초기 상태에서 시작한다. 파일 읽기·쓰기, 인터넷에 접근할 수 있는 셸, 웹 검색과 웹 가져오기를 동일하게 제공한다. [106:45] [1:42:49]

55. 편집 영상의 도입부 구성과 화면 공유 잘림

• 버전 3은 이전보다 낫지만, 첫 화면은 원래 촬영 구도로 시작한 뒤 확대·축소와 슬라이드 효과를 거쳐 왼쪽 인물 배치로 전환하는 구성이 더 적합하다. 테두리가 있는 인물 화면 등에는 그림자도 추가필요가 있다. [107:42] [1:42:54]
• 화면 공유를 크롭하면서 중요한 부분이 잘린다. 도입부에서 Clearbench 왼쪽 영역이 많이 사라지는 문제가 반복되므로, 작업 중인 화면 공유 컨테이너의 범위를 감지해 잘림을 줄여야 한다. [108:16] [1:43:51]

56. 재생 중이던 버전 3의 재렌더링

• 버전 3을 보던 중 파일 크기가 다시 0으로 돌아가고 렌더링이 재시작된다. 나뉜 조각을 다시 렌더링하며 자체 문제를 해결하는 과정으로 보이지만, 정확한 상황은 확정되지 않는다. [109:04] [1:44:48]

57. T3 실행 환경을 VM으로 분리하려는 이유

• T3 Code에는 실행 환경의 전체 디스크 접근 권한을 주고 싶지만, 의존도가 높은 HQ에 같은 권한을 직접 부여하는 것은 부담스럽다. HQ의 안정성이 우선이므로 바로 적용하지 않고 있다. [109:49] [1:45:03]
• T3를 별도 VM에서 실행하고 그 웹 GUI를 HQ 안에 넣는 구상을 검토한다. 연결된 다른 기기에서도 해당 환경에 접근해, T3나 HQ를 별도로 열지 않고 작업할 수 있게 하려는 방향이다. [110:14] [1:48:32]

58. PRD 사용 범위 재검토와 방송 종료

• 클라이언트 작업에는 계속 PRD를 사용해 왔지만, 데모·일상적인 제작·개인 도구 개발에서는 한동안 생략했다. Terra를 계기로 이러한 작업에도 PRD를 적용해 볼 필요성이 다시 생겼다. [110:41] [1:48:37]
• 재렌더링에 앞으로 약 30분이 더 걸릴 것으로 예상되면서 방송을 마무리하기로 한다. 렌더링 중 영상은 불안정하지만 오디오는 정상이라는 피드백을 확인한다. [111:53] [1:49:34]

59. 감사 카드의 가변 너비가 만드는 조작 문제

• 감사 카드의 이름 길이에 따라 컨테이너 너비가 바뀌고 좌우 화살표 위치도 움직인다. 여러 카드를 넘기려면 마우스를 계속 옮겨야 하므로, 카드 크기와 관계없이 가운데를 클릭하면 다음 카드로 순환하도록 개선필요가 있다. [112:55] [1:49:49]

60. 커뮤니티 안내와 마무리

• clear.link 랜딩 페이지 상단의 커뮤니티 항목에서 Discord로 이동할 수 있다. [113:57] [1:53:45]
• 다음 방송은 금요일 같은 시간으로 예정돼 있으며, 마지막에는 Clear Stream에서의 성과에도 긍정적인 평가를 남긴다. [114:15] [1:54:00]

🧾 결론

• 제목의 도발적인 질문은 CLI를 버리라는 선언보다, 기본 작업 도구가 T3 Code로 바뀌었다는 경험을 담고 있다.
• 작업 내용을 볼 수 있는지와 실행 위치·접근 권한을 통제할 수 있는지가 도구 선택의 중요한 기준으로 드러난다.
• 자동화는 결과물을 한 번 생성하는 것으로 끝나지 않는다. 편집 품질, 렌더링 안정성, 요구사항 충족 여부를 반복해서 확인해야 한다.
• 도구의 기여는 추정보다 작업 기록으로 판단해야 한다. Hyperframes 사용 여부를 FFmpeg 실행 기록으로 정정한 장면이 이를 보여준다.

📈 투자·시사 포인트

• 개발 도구를 평가할 때 작업 가시성, 프로젝트 관리, 기존 CLI·내부 도구와의 연결이 실제 사용 비중을 바꾸는지 살펴볼 만하다.
• AI 제작 도구의 효율은 생성 비용뿐 아니라 수정 시간과 렌더링 부담까지 함께 봐야 한다. 이 사례에서는 로컬 장비의 발열과 재렌더링이 제작 과정의 제약으로 나타났다.
• 저비용 모델의 실무 가치는 요구사항 충족률과 함께 평가해야 한다. Terra의 빠른 속도와 낮은 비용만으로 최종 작업 효율을 확정하기는 어렵다.
• 콘텐츠 자동화의 성과를 판단하려면 제작 시간 절감과 시청 지속률을 함께 확인해야 한다. 영상에는 자동화 확대 계획이 제시되지만 성과 데이터는 아직 없다.

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

• T3 Code의 전체 기능을 충분히 시험한 상태는 아니다. Tailscale 연결과 T3의 별도 VM 실행·HQ 내 GUI 통합도 검토 또는 구성 계획으로 구분해야 한다.
• T3 Connect에 대한 보안 우려는 실제 침해 사례를 확인한 주장이 아니다. 연결 개수 제한, 정확한 가격, 휴대전화 푸시 알림 조건도 추가 확인이 필요하다.
• AI 편집본의 시청 지속률과 최종 품질은 검증되지 않았다. 버전 3은 재렌더링이 진행됐고, 방송 종료 시점에도 완료된 최종 결과는 제시되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 클라이언트 작업과 일상 개발에서 CLI·T3 Code·HQ를 각각 언제 사용할지 정리하고, 작업 확인과 개입이 필요한 지점을 비교한다.
• 장시간 작업의 실행 컴퓨터와 절전 조건을 확인하고, VM에 제공할 키와 다른 서버로의 접근 범위를 필요한 수준으로 제한한다.
• T3 Connect의 요금·연결 제한·알림 조건을 확인하고, Tailscale 대안이 필요한 기능을 충족하는지 시험한다.
• AI 편집본에서 첫 3초, 자막 가독성, 화면 공유 잘림, 브랜드 스타일, 오디오를 점검하고 제작 시간과 게시 후 시청 지속률을 기록한다.

❓ 열린 질문

• T3 Code의 작업 가시성은 어떤 업무에서 CLI보다 편리하며, 어떤 업무에서는 CLI를 계속 사용하는 편이 나을까?
• 장시간 작업을 VM으로 옮기면 노트북의 렌더링·방송 부하와 작업 중단 문제를 얼마나 줄일 수 있을까?
• 편집 스킬이 실제 수정 시간과 전체 제작 시간을 줄이면서 시청 지속률도 유지하거나 높일 수 있을까?