Experiments with Kieran, OpenAI Live Voice inside Compound Engineering

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Compound Engineering에 OpenAI Live Voice를 연결해 말·클릭·그림을 에이전트의 수정 작업으로 이어가는 실험이며, 전체 피드백 루프의 설계와 구현 착수까지 다루지만 완성 결과는 확인되지 않았다.

📌 핵심 요점

1. polish에 실시간 대화를 결합한다. 웹사이트를 보며 말하고 클릭하거나 그림을 그리면, 에이전트가 의도를 파악해 백그라운드에서 수정하는 경험을 목표로 한다. 첫 적용 범위는 Compound Engineering 내부 사용이다.
2. 피드백 수집과 수정 실행을 분리한다. 브라우저의 라이브 에이전트가 요청을 수집해 보드에 보여주고, 적절한 작업 묶음이 만들어지면 코딩 에이전트에 전달하는 방식을 선호한다. 즉시 실행·스마트 판단·실행하지 않기 등의 모드는 작업 위험도에 따라 선택하는 구상이다.
3. riffre를 ZIP 수집에서 스트리밍으로 확장한다. 기존 기록 방식과 라이브 모드를 나누고, prototype의 서버·리스너 패턴을 참고한다. 스트림 계약은 공개 API로 검토하며, 원격 서버와 다른 머신의 브라우저 사이에서도 터널을 통해 정보가 전달돼야 한다.
4. 요청에 붙일 증거와 드로잉 구현을 구체화한다. 스크린샷·DOM·이벤트·구조화된 데이터를 활용하되, 정보가 많아질수록 실제 이해가 좋아지는지는 실험으로 확인할 계획이다. 드로잉은 tldraw 검토 후 perfect-freehand 기반의 얇은 커스텀 레이어를 만드는 제안을 받아들인다.
5. 같은 접근을 지식 업무로 넓히되 독립성을 지향한다. Compound Work는 독립 사용과 Compound Engineering과의 병행 사용을 모두 지원하는 별도 플러그인으로 구상한다. 캡처·요약·계획·전략뿐 아니라 배운 내용을 추출해 축적하는 기능도 검토한다.

🧩 배경과 문제 정의

• Compound Engineering의 작업 방식을 비개발자의 지식 작업과 실험으로 확장하는 구상과 함께, 기존 polish 명령에 실시간 피드백 기능을 추가하는 실험을 진행한다.
• AI가 유용하게 작업하려면 사용자의 중요한 발언뿐 아니라 화면, 클릭 위치, DOM 요소 등 의도를 이해할 근거를 확보해야 한다. 기존 riffre는 이를 수집하지만 실시간 전달 방식은 아니다.
• 목표는 웹사이트를 사용하며 말하고, 클릭하고, 그리는 피드백을 에이전트의 수정 작업으로 연결하는 것이다. 작업 실행 시점, 자동화 수준, 라이브러리의 책임 범위, 전달할 증거의 양은 아직 설계 중이다.

🕒 시간순 섹션별 상세정리

1. Compound Engineering에서 비개발자용 작업 방식으로 확장

• 새 플러그인 버전에는 주석을 활용하는 prototype 기능, 더 유연하고 작아진 slop fighter, packs 등이 포함된다. prototype은 기존 작업에 추가 반복 개선을 거친 기능이다 [01:30]
• 가칭 ‘compound work’는 엔지니어링뿐 아니라 지식 작업과 실험에도 적용할 작업 프레임워크다. Compound Engineering과 별도로 단독 사용하거나 함께 사용할 수 있는 실험적 구상이다 [02:14]

2. riffre의 기록 기능과 실시간 피드백의 간극

• AI 활용의 어려움 중 하나는 사용자의 가치 있는 발언이나 경험에서 좋은 정보를 확보하는 일이다. riffre는 화면과 클릭, DOM 요소 등을 기록하고 묶어 전달하는 React 패키지지만 실시간으로 작동하지는 않는다 [03:21]
• 호흡 코치 앱에 OpenAI의 라이브 오디오 기능을 사용한 경험을 바탕으로, 웹사이트를 보고 반응하거나 클릭하고 그리는 동안 에이전트가 즉시 작업을 시작하는 방식을 구상한다 [04:11]

3. polish에 대화형 라이브 모드를 추가하는 구상

• Codex의 라이브 모드 등을 활용할 가능성도 있지만, 우선 Compound Engineering의 polish에 라이브 모드를 확장하는 실험을 고려한다. 서버를 시작하고 사용자가 결과물을 보면서 실시간으로 개선하는 방식이다 [04:42]
• 아이디어의 출발점은 하이킹 중 Monologue에 음성으로 쏟아낸 메모다. 이 내용을 Cursor에 넣어 후속 작업의 재료로 사용한다 [05:29]

4. 브레인스토밍으로 첫 사용자와 적용 범위를 좁히기

• Cursor Projects는 클라우드와 로컬 작업을 연결한다는 점에서 유용하게 평가된다. 입력한 메모를 바탕으로 브레인스토밍을 실행하고 관련 저장소를 조사한다 [06:22]
• riffre는 앱의 일반 사용자에게 피드백을 받는 용도로도 쓰일 수 있지만, 이번 첫 버전은 Compound Engineering 내부 사용에 초점을 맞추도록 범위를 조정한다 [07:36]

5. 피드백 수집과 코딩 에이전트 실행 시점 분리

• “색을 바꿔 달라”는 요청이 나오면 즉시 수정할지, 사용자가 전송 버튼을 누르게 할지, 여러 요청을 모아 보낼지가 핵심 설계 질문이다 [08:23]
• 브라우저의 라이브 에이전트가 요청을 빠르게 수집해 보드에 보여주고, 적절한 작업 경계나 묶음이 생기면 코딩 에이전트에 전달하는 방식을 선호한다. 앞단 에이전트가 도구 호출로 전송 시점을 결정하는 방안도 고려한다 [09:04]

6. 작업 위험도에 따라 자동 실행 수준을 전환

• 코딩 에이전트가 요청 묶음을 받았을 때 분류만 할지, 작은 수정만 구현할지, 모두 병렬로 구현할지, 항목별로 판단할지를 검토한다. UI에서 즉시 실행·스마트 판단·아무 작업도 하지 않는 모드를 선택하는 구상이 나온다 [09:39]
• 디자인을 다듬는 단계에서는 폭넓은 자동 수정을 허용할 수 있지만, 큰 변경이나 서로 충돌할 수 있는 리팩터링에서는 사용자가 다른 모드로 전환할 수 있어야 한다 [10:27]

7. polish의 사용 경험과 실행 요건 구체화

• Compound Engineering의 polish 명령에서 라이브 방식과 기존 방식 중 하나를 선택하도록 통합하는 방향을 잡는다 [11:15]
• polish는 AI가 만든 결과물을 직접 보며 위치를 옮기거나 여러 버전을 시도해 완성도를 높이는 작업이다. 라이브 모드는 웹사이트와 대화하는 동안 백그라운드에서 수정이 진행되는 경험을 목표로 하며, 저장소에 riffre를 설치하는 방식을 구상한다 [13:13]

8. ZIP 수집과 스트리밍을 riffre의 서로 다른 모드로 분리

• 기존 riffre는 수집 결과를 ZIP 파일로 묶었지만, 새 기능은 스트리밍 전달을 요구한다. 이 차이 때문에 기능을 riffre에 둘지 Compound Engineering에 직접 둘지가 설계 쟁점이 된다 [15:38]
• riffre에 별도 모드로 추가하면 Compound Engineering에 모든 기능을 몰아넣지 않으면서, 향후 코딩 이외의 세션에서도 ZIP 대신 스트리밍을 활용할 수 있다는 방향을 선호한다 [16:11]

9. prototype의 서버·리스너 패턴 재사용

• polish의 통신 구조는 Compound Engineering의 prototype 스킬에 있는 유사한 서버·리스너 패턴을 참고하도록 한다 [16:42]
• 최신 prototype에는 가벼운 웹 서버를 시작하고 연결을 수신하는 기능이 있다. 브라우저에서 발생한 정보를 에이전트로 전달하고, 에이전트가 그 정보에 따라 행동하는 구조를 이미 제공한다 [17:05]

10. 장기 활용 범위를 먼저 보고 라이브러리 경계 결정

• AI가 좁고 보수적인 설계를 제안할 수 있으므로, 먼저 여러 활용 방식과 장기 프로젝트의 관점에서 방향을 넓힌 뒤 현재 구현 범위로 좁히는 접근을 선호한다. 이 과정이 라이브러리와 스크립트 중 무엇이 적합한지 판단하는 데 도움이 된다 [18:14]
• 라이브러리는 수정하기가 상대적으로 어려워 AI가 기존 인터페이스를 사용하게 하고, 책임도 명확히 분리한다. 여러 프로젝트에서 재사용하며 점진적으로 성장시키는 방식을 선호한다 [18:50]

11. 드로잉 도구와 스트림 계약 검토

• riffre의 라이브 모드에 스트리밍, 오버레이, 드로잉 레이어를 두는 구상에서 드로잉 구현 후보로 tldraw SDK를 검토한다 [19:55]
• 기존 ZIP 스키마처럼 스트림 계약이 새로운 공개 API가 된다. 전송 방식이 폴링인지, prototype은 어떻게 구현했는지 확인하면서 단순한 구조를 유지하려 한다 [20:33]

12. 단순 캡처 도구에서 빠르게 반응하는 AI 도구로 확장

• riffre를 ‘수집만 하고 지능은 포함하지 않는 도구’로 두었던 초기 전제를 재검토한다. OpenAI 실시간 기능과 API 키 사용을 받아들이더라도, AI가 사용자 가까이에서 빠르고 즉각적으로 반응하는 경험이 중요하다는 판단이다 [21:14]
• 프레임워크에 종속되지 않는 구조와 일반 스크립트 삽입 방식도 검토하지만, 당장은 자신의 앱 대부분이 React라는 점을 근거로 React 대상 구현을 수용한다 [22:00]

13. 요청마다 화면과 구조적 증거를 충분히 전달

• 화면 상태를 계속 포착할 필요는 있지만, 영상은 너무 클 수 있어 특정 시점의 스크린샷을 고려한다. 색 변경 요청이나 창 위의 그림을 에이전트가 이해하도록 구조화된 데이터, 이벤트, DOM 정보도 활용할 수 있다 [23:46]
• 각 요청 단위에는 가능한 한 풍부한 증거, 특히 스크린샷을 포함하는 방향을 선호한다. 라이브 영상은 제외할 가능성을 두고, 추가 정보가 이해를 돕는지 오히려 혼란을 주는지는 후속 실험으로 확인하려 한다 [26:19]

14. 드로잉 구현 후보를 perfect-freehand로 전환

• 검토 결과에서는 패키지 내부 오버레이에 tldraw를 사용하는 데 부정적인 권고와 함께, 라이선스 키 및 무료 취미용 키의 워터마크 조건이 드러난다 [28:19]
• 대신 tldraw 작성자의 perfect-freehand를 기반으로 얇은 커스텀 레이어를 만드는 제안을 받아들인다 [28:44]

15. 원격 환경에서도 동작하는 피드백 전달 경로 확보

• 스트림 계약을 다시 검토하며, 테스트 중인 웹사이트의 정보를 코딩 에이전트까지 전달하는 경로를 확인한다 [29:04]
• 서버가 원격 머신에서 실행되고 브라우저는 다른 머신에서 열릴 수 있으므로, 터널을 통해서도 동작해야 한다는 요구를 추가한다. prototype에 유사한 지원이 있는 것으로 보고 같은 방식으로 작동하도록 요청한다 [29:30]

16. 첫 버전부터 전체 작업 루프를 지향한다

• 다음 주에 쓸 첫 버전을 단일 기능으로 제한하자는 제안 대신, 처음부터 전체 루프를 원한다. 에이전트가 범위를 줄이도록 반문하는 것은 유용하지만, 목표가 명확하고 조건이 잘 갖춰졌다면 더 넓은 작업도 맡길 수 있다는 판단이다 [30:47]

17. 상세한 브레인스토밍으로 구현 중 시행착오를 줄인다

• 초기 생각을 포함한 브레인스토밍에 대략 한 시간에서 한 시간 반이 걸렸다고 추정한다. 요구사항을 명확하고 상세하게 정리하면 에이전트가 한 번에 실행하기 쉬워져, 반복 수정과 잘못된 방향으로 파고드는 시간을 줄일 수 있다 [31:36]

18. 여러 저장소에 걸친 작업 범위를 두 곳으로 좁힌다

• 프로젝트는 원래 네 개 저장소에 걸쳐 있었지만 Compound Engineering과 riffrec 두 곳으로 범위를 줄였다. 향후 사용자를 위한 다른 저장소에도 구현을 확장할 가능성은 열어 둔다 [32:12]

19. 시험 사용자는 신뢰와 제품 이해도를 기준으로 고른다

• 모든 사람의 피드백이 똑같이 유용하지는 않다는 관점에서, 신뢰하는 사람·내부 구성원·파워 유저·최상위 요금제 사용자에게 먼저 접근 권한을 주는 방안을 제시한다. 디자인과 제품에 대한 판단력이 중요한 선정 기준이다 [34:19]
• 피드백이 좋은 아이디어인지, 제품을 원하는 방향으로 움직이는지 평가하는 절차도 필요하다. 우선 자신과 파워 유저가 쉽게 피드백을 제공할 수 있게 만드는 것을 첫 단계로 본다 [35:05]

20. 실시간 피드백을 사용자의 제품 개선 참여로 확장한다

• 사용자가 실시간으로 피드백하면 실제 제품 수정으로 이어지는 방식을 지향한다. 소스코드를 다루는 공학적 역량에 크게 의존하는 기존 오픈소스보다, 제품 사용법을 아는 사람이 직접 개선에 참여할 수 있는 형태를 전망한다 [35:34]
• 구체적인 해답은 아직 없으며, 변경이 개인과 회사의 목표에 부합하는지 확인하는 장치를 개발 중이다 [36:24]

21. 실행 중인 에이전트에 개입하고 여러 작업을 조율한다

• 에이전트는 클라우드나 컴퓨터 등에서 실행할 수 있고, 실행 화면에 들어가 진행 중인 작업의 방향을 조정할 수 있다 [41:56]
• 여러 작업을 지시하면서 이미 실행 중인 에이전트를 조정하거나 재시작하는 기능도 활용할 수 있다 [42:41]

22. 문서 검토에서 저장소별 계획과 병렬 구현으로 연결한다

• 문서 검토에서 나온 질문을 확인하고, 적절한 해결책이 있으면 자동으로 처리하도록 요청한다. 검토가 끝나면 Compound Engineering의 계획 단계를 실행해 작업 단위와 각 작업이 속할 저장소를 구분하려 한다 [43:08]
• 계획 이후에는 작업 단위마다 LFG 흐름을 별도로 실행하고 가능한 한 병렬화하도록 요청한다. 이 시점의 내용은 실행 지시이며, 구현 완료 결과는 아니다 [43:42]

23. 지식 업무용 Compound Work를 별도 플러그인으로 구상한다

• Compound Work는 Compound Engineering의 접근을 지식 업무에 적용하려는 구상이며, 로컬에서 실행하는 버전이 있다. 여러 구성원이 각자 다른 방식을 사용하므로 서로 참고하거나 자신만의 워크플로를 만들 수 있다 [46:22]
• 비개발자의 업무는 개발 업무와 형태가 다르기 때문에 별도 플러그인으로 분리하는 쪽에 기운다. Compound Engineering의 브레인스토밍이 필요하면 두 플러그인을 함께 설치하는 방식을 고려한다 [47:03]

24. 큰 설계 결정은 직접 검토하고 독립성과 호환성을 명확히 한다

• 작은 기능 추가는 곧바로 실행을 맡기기도 하지만, 큰 기능의 계획은 직접 검토한다. 중요한 설계 결정을 확인하면서 자신이 원하는 형태를 구체화하는 과정이기도 하다 [47:57]
• Compound Work를 단독으로 쓸 수 없다는 표현은 수정이 필요하다. 독립적으로 사용할 수 있으면서 Compound Engineering과도 함께 작동하는 관계가 의도에 맞는다 [49:05]

25. 캡처와 요약 스킬의 역할을 점검한다

• Capture는 원본 자막이나 회의 기록을 처리해 적절한 위치에 넣는 역할로 드러난다 [50:43]
• Dream은 내용을 요약하는 기능으로 이해하고 있지만, 실제 역할과 작동 방식은 더 살펴봐야 한다고 판단한다. 스킬 구성은 아직 검토 중이다 [51:00]

26. 전략 수립과 학습 축적을 지식 업무의 기능으로 보강한다

• 기존 사례를 참고해 일간·주간 계획 기능과 지식 업무용 전략 기능을 추가하는 방안을 검토한다. 실험 기능이 필요한지는 확신하지 않는다 [51:42]
• 중요한 누락으로 KW Compound를 지적한다. Dream이나 Review 과정에서 무엇을 배웠는지 추출하고 지식을 축적하는 기능이 필요하다는 구상이다 [52:23]

27. 독립 실행에 필요한 기능을 찾되 기존 기능의 복제를 피한다

• Compound Engineering의 Ideate를 활용해 Compound Work에 빠진 스킬이 있는지 점검하려 한다. 완전히 독립적으로 작동할 수 있어야 하지만, 두 플러그인을 함께 사용할 수도 있으므로 기존 기능을 그대로 복제하는 것은 피하려 한다 [52:42]

28. Live Voice 구현은 실행을 시작했으며 결과 확인은 남아 있다

• Compound Engineering 안에서 Live Voice를 구현하는 작업을 시작했고, LFG를 통해 전체 구현이 진행될 것으로 예상한다. 실제로 무엇이 만들어졌는지는 아마 다음 날 후속 방송에서 확인할 계획이며, 제공된 자막에는 완료 결과가 나오지 않는다 [53:39]

29. ‘폴더가 에이전트’라는 관점을 되짚으며 방송 종료를 예고한다

• 앞서 쓴 글의 핵심인 ‘폴더가 곧 에이전트’라는 관점을 다시 언급한다 [53:54]
• 배터리가 얼마 남지 않았다는 지적에, 배터리가 다하면 라이브 방송을 종료하겠다고 말한다 [54:09]
• 제공된 발췌는 작업 중이라는 말에서 끊겨, 실제 영상 끝의 결론이나 마무리 논지는 확인되지 않는다 [54:24]

🧾 결론

• 이 실험의 핵심은 음성 입력 자체보다 사용자 의도를 담은 증거를 수집하고, 작업으로 묶어 전달해 실제 수정까지 이어가는 전체 루프다.
• 자동화 수준은 변경의 성격에 맞춰 조정하는 방향이다. 디자인 다듬기와 충돌 가능성이 있는 큰 리팩터링에는 서로 다른 실행 판단이 필요하다고 본다.
• 상세한 브레인스토밍과 주요 설계의 직접 검토를 통해 구현 중 잘못된 방향으로 진행하는 시간을 줄이려 한다. 영상 말미의 병렬 구현 요청은 완료 보고가 아니라 실행 지시다.
• 장기적으로는 소스코드를 직접 다루지 않는 사용자도 제품 개선에 참여하는 방식을 지향하지만, 참여자 선정과 목표 부합 여부를 판단하는 장치는 아직 개발 중이다.

📈 투자·시사 포인트

• 제품 관점에서는 음성·화면·클릭·드로잉을 수정 작업에 연결하는 흐름이 관찰 대상이다. 다만 실제 품질 향상이나 작업 시간 단축 수치는 제시되지 않았다.
• 라이브러리 관점에서는 riffre의 스트리밍 모드와 공개 API가 여러 프로젝트 및 코딩 이외의 세션으로 재사용될 가능성이 제시된다. 실제 채택과 확장 결과는 후속 확인이 필요하다.
• 사용자 참여 관점에서는 피드백의 양보다 제품 이해도와 판단력이 중요하게 다뤄진다. 내부 구성원과 파워 유저부터 접근 권한을 주고, 제안이 제품 목표에 맞는지 평가하는 운영 방식이 제시된다.
• 지식 업무 확장은 별도 플러그인과 학습 축적 기능의 가능성을 보여준다. 자료에는 매출·가격·시장 규모 등 투자 판단에 필요한 사업 지표가 없어, 현재는 제품 및 작업 방식의 실험으로 해석하는 것이 적절하다.

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

• Live Voice 구현은 착수했지만 제공된 내용에는 완성된 기능의 동작 결과가 없다. LFG가 전체 구현을 진행할 것이라는 기대와 실제 완료 여부를 구분해야 한다.
• 요청을 즉시 보낼지, 사용자 전송을 기다릴지, 여러 요청을 묶을지와 자동 실행 모드별 판단 기준은 확정되지 않았다.
• 스크린샷의 촬영 주기와 DOM·이벤트 정보의 적정량은 실험 과제다. 증거 추가가 이해를 돕는지 혼란을 늘리는지도 확인되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 후속 결과에서 음성·클릭·드로잉 수집부터 요청 전달과 코드 수정까지 전체 루프가 실제로 동작하는지 확인한다.
• 작은 디자인 수정과 큰 리팩터링을 구분해 즉시 실행·스마트 판단·실행하지 않기 모드의 적용 기준을 정리한다.
• 같은 요청에 스크린샷·DOM·이벤트 정보를 추가하거나 제거하면서 에이전트의 이해와 수정 결과를 비교한다.
• 개발 서버, 브라우저 감시 CLI, OpenAI API 키, 마이크 등 제시된 실행 요건을 점검하고 원격 서버·터널 환경에서도 전달 경로를 확인한다.

❓ 열린 질문

• 라이브 에이전트는 어떤 기준으로 하나의 요청 묶음이 끝났다고 판단하고 코딩 에이전트에 전달해야 하는가?
• 여러 수정이 동시에 진행될 때 충돌 가능성과 변경 규모를 어떻게 판단해 자동 실행 수준을 조정할 것인가?
• 요청별 스크린샷과 구조화된 정보는 어느 정도까지 제공해야 의도 전달을 개선하면서 혼란을 줄일 수 있는가?