Does Your Computer Belong To Codex? I Went To OpenAI To Ask.

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenAI 방문 대화가 보여주는 Codex 시대의 변화는 컴퓨터 조작을 에이전트에 맡기고, 사람이 업무의 목적과 결과를 판단하는 방식으로의 전환이다.

📌 핵심 요점

1. 컴퓨터 사용 능력은 API·MCP가 제공되지 않는 작업까지 자동화 범위를 넓힌다. 전용 커넥터는 속도와 토큰 효율에서 여전히 가치가 있어, 화면 조작과 상호 보완적으로 쓰인다.
2. 도입의 관건은 모델의 능력과 업무 맥락에 대한 접근성이다. OpenAI 내부에서는 연결된 업무 도구의 정보를 종합하며, 직무별 확산도 필요한 자료에 접근할 수 있는지에 영향을 받았다.
3. 비개발자의 결과물이 문서에서 지속적으로 개선하는 업무용 앱으로 확장된다. 재무·사업 팀의 사이트 제작 사례는 개인의 자동화를 팀이 재사용하는 도구로 연결할 가능성과 버전 관리 지원의 필요성을 함께 보여준다.
4. 생성이 쉬워질수록 문제 선정, 결과 검증, 제품의 일관성을 판단하는 역량이 중요해진다. 실행 중 확인 질문과 방향 수정은 사용자의 의도를 구체화하고 불필요한 작업을 줄이는 수단이다.
5. 효율은 토큰 단가보다 업무 한 단위를 완료하는 비용으로 평가해야 한다. 모델별 역할 분담은 비용 절감 실험이며, 선제적 제안은 근거·확신도·실행 비용까지 검증해야 가치를 인정받을 수 있다.

🧩 배경과 문제 정의

• AI가 질문에 답하는 챗봇에서 컴퓨터를 조작하고 업무를 수행하는 에이전트로 확장하면서, 사람이 직접 처리할 일과 에이전트에 맡길 일의 경계가 달라지고 있다.
• 지식 업무 자동화에는 모델의 지능뿐 아니라 문서·앱·조직 정보에 대한 접근성이 필요하다. API나 MCP가 없는 업무까지 연결하는 컴퓨터 사용 능력이 중요한 변수다.
• 결과물을 만드는 비용이 낮아질수록 문제 선정, 결과 검증, 일관된 제품으로 통합하는 판단력이 중요해진다. 토큰 비용과 선제적 제안의 품질도 함께 관리해야 한다.
• OpenAI 내부의 활용 경험과 외부 사례를 바탕으로 업무 방식과 인터페이스의 변화를 살핀다. 향후 성능 향상과 제품 방향에 관한 기대는 확정된 결과와 구분한다.

🕒 시간순 섹션별 상세정리

1. 3D 생성이 실생활의 의사결정 도구로 확장된다

• Astra의 두드러진 활용 사례로 Blender를 통한 3D 환경과 게임 제작이 꼽힌다. 내부에서 가장 유용하게 쓰던 분야는 아니었지만, 사실적인 공간을 만드는 외부 사용자들의 반응은 예상보다 컸다 [03:54]
• 한 가족 구성원은 주택 개조 도면 PDF로 둘러볼 수 있는 3D 모델을 만들고 실제 변경 사항을 결정했다. 전문 사용자의 실험을 넘어 생활 속 의사결정을 지원한 사례다 [04:35]

2. 지식 업무 인터페이스는 실행 과정과 신뢰 사이의 균형이 필요하다

• 지식 업무에서는 에이전트의 세부 작동을 추상화하되, 결과를 신뢰할 만큼의 정보는 남기는 설계가 접근성을 높였다 [05:08]
• 개발자에게는 실행 스크립트와 클릭 대상 정보를 보여줄 수 있었지만, 더 넓은 사용자층에는 사용 중인 앱과 화면 속 동작을 작은 화면과 포인터로 보여주는 방식이 필요했다. 내부의 코딩 에이전트 능력은 유사해도 사용자에게 드러내는 표현은 달라진다 [05:58]

3. 컴퓨터 사용 능력이 API와 MCP의 빈틈을 메운다

• 진행자는 초기 컴퓨터 조작이 불안정했던 경험 때문에 기계에는 API나 MCP 같은 인터페이스가 필요하다고 봤으나, 성능 향상의 잠재력을 과소평가했다고 인정한다. 컴퓨터 조작이 충분히 좋아지자 별도 연동이 없는 정부 서류 같은 작업도 처리할 수 있게 됐다 [07:03]
• MCP는 더 빠르고 토큰 효율적인 경우가 많지만, 모든 작업에 MCP가 제공되지는 않는다. 컴퓨터 사용은 이 빈틈을 연결하는 범용 수단이 된다 [07:24]

4. 복잡한 앱 조작을 위임하고 필요한 결과를 요청한다

• 진행자는 음성으로 에이전트에 지시하는 동안 커서가 여러 창에서 UX·사용자 수용 테스트를 수행하는 상황을 겪는다. 컴퓨터를 직접 사용하는 경험이 에이전트의 작업을 지휘하는 경험으로 바뀌고 있다 [08:24]
• 수십 년간 쌓인 웹사이트, 앱, PDF, 팩스는 일상적인 서류 처리도 복잡하게 만들었다. 에이전트가 사이트 탐색과 문서 확인·보관을 맡고, 사용자는 예방접종 기록을 찾아 캠프에 보내 달라는 식으로 목적을 요청하는 방향을 기대한다 [10:03]

5. 모델의 도구 활용 능력이 좋아질수록 연동의 가치도 커진다

• 커넥터와 플러그인은 이전부터 있었지만 모델이 항상 잘 활용하지는 못했다. 최근 약 6개월 사이 활용 능력이 전환점을 맞으면서, 사용자가 허용한 정보와 도구에 접근시키는 일이 제품의 효용을 크게 높이기 시작했다는 평가다 [11:11]
• 연동 개발은 외부 서비스의 도구를 폭넓게 제공하고, 안정적으로 작동하며, 빠르고 토큰 효율적으로 실행되도록 하는 데 집중한다. 컴퓨터 사용이 발전하더라도 더 나은 전용 커넥터에는 계속 투자할 이유가 있다 [11:35]

6. 자동화를 먼저 시도하는 습관과 업무 맥락 접근성이 도입을 좌우한다

• 발표자료 수정이나 이메일 작성이 생겼을 때 직접 시작하기 전에 Codex나 ChatGPT에 먼저 맡겨 보는 습관이 중요하다. 모든 일을 스스로 처리하던 방식에서 자동화를 출발점으로 삼는 방식으로 넘어가는 것이 큰 전환이다 [12:31]
• OpenAI 내부는 일반적인 외부 업무 도구를 잘 연결해 두고, 질문을 통해 Slack과 Google 문서 등에 흩어진 정보를 종합하도록 구성했다 [13:10]

7. 비개발자도 문서의 한계를 넘어 업무용 앱을 만든다

• 재무·사업 팀 일부는 Excel 대신 사이트 형태의 앱을 만들고 공유하며 버전을 갱신하고 있다. 사실상 개발 업무를 수행하지만 Git과 버전 관리 같은 지원 도구가 부족해, 이를 보완할 필요가 드러났다 [16:07]
• 문서·슬라이드·스프레드시트에 담기 어려운 상호작용이나 지속성이 필요한 결과물은 사이트로 구현할 수 있다. 엔지니어처럼 요구사항을 표현하지 못하더라도 문제를 설명해 앱을 만드는 방식이 지식 노동자의 표현 범위를 넓힐 것으로 기대한다 [17:19]

8. 각 직무의 전문성이 지속적으로 개선하는 내부 제품이 된다

• 내부 사이트를 만드는 과정도 고객에게 제품을 제공하고 개선하는 개발 주기와 닮아간다. 예를 들어 인사팀의 인재 발굴 사이트는 동료를 고객으로 삼아 전문성을 제공하고 유지하는 제품이 된다 [18:33]
• 내부 도구는 사용자 규모가 작고 대규모 서비스의 하위 호환성 부담도 적어 더 빠르게 개선할 수 있다. 이런 팀들의 반복 속도가 오히려 소프트웨어 개발자에게 교훈을 주기도 한다 [18:54]

9. 성능 향상 이후의 병목은 아이디어와 검증 능력이다

• 앞으로 결과물의 품질, 사용자 의도 이해, 맥락 수집과 정확한 출처 인용이 나아질 것으로 예상한다. 이 전망이 실현될수록 무엇을 만들지 결정하는 아이디어가 중요한 병목이 된다 [19:51]
• 에이전트에게 결과물을 만들게 하고, 자신이나 동료에게 유용한지 검증한 뒤 다시 개선을 요청하는 능력이 지속적으로 중요하다. 성능이 좋아지면 반복 주기가 짧아지고 병렬로 수행할 수 있는 일도 늘어날 수 있다 [20:22]

10. 쉽게 만드는 능력보다 선택하고 통합하는 판단이 중요해진다

• 결과물이 쏟아지면 여러 아이디어를 집중도 높고 일관된 제품으로 묶는 안목이 병목이 된다. 만들 수 있는 것의 범위가 넓어질수록 실제로 무엇이 필요한지 명확히 판단해야 한다 [21:20]
• 진행자는 반복적인 잡무를 에이전트에게 넘기면서, 남은 시간에 어떤 아이디어와 결정을 내릴지 더 직접적으로 묻게 됐다고 한다. 자동화는 스스로 방향을 정해야 하는 부담도 키운다 [22:13]

11. 모델별 역할 분담으로 장시간 작업의 토큰 비용을 줄인다

• 진행자는 Luna를 높은 추론 설정의 오케스트레이터로, Astra와 하위 에이전트를 실행 담당으로 쓰는 구성을 실험했다. 장기 조율 맥락은 Luna에 두고 별도 Astra에는 전체 맥락을 넘기지 않은 채 주도성과 작업 범위를 간헐적으로 점검하게 해, 토큰 효율이 높았다고 평가한다 [23:45]
• OpenAI 측도 비슷한 활용이 늘고 있다고 한다. Astra가 이전 모델보다 한 자릿수 규모 이상 효율적인 일부 사례와 컴퓨터 사용의 코드 모드를 언급하며, 모델별 역할 분담을 기본 작동 방식에 더 반영하려 한다 [24:46]

12. 효율은 토큰 단가보다 완료한 업무의 비용으로 평가한다

• 배포하는 스킬과 에이전트 실행 환경, 컴퓨터 사용의 코드 모드에서도 필요한 토큰을 줄이는 최적화를 진행하고 있다 [25:11]
• 비용에 민감한 사용자에게 중요한 지표는 시간당 토큰 수보다 원하는 업무 한 단위를 끝내는 데 든 비용이다. Astra의 토큰당 가격이 더 높더라도 수행 효율이 높을 수 있으므로, 토큰 사용량뿐 아니라 실제 성과 대비 비용을 평가해야 한다 [25:55]

13. 데이터 분석은 질의 작성에서 개선 기회 발견으로 이동한다

• 유지율이 낮거나 온보딩이 느린 집단을 찾으려면 과거에는 데이터 테이블 탐색, SQL 작성, 대시보드 구축과 재작업에 며칠이 걸렸다. 이제는 개선 기회를 정리한 보고서를 받아 팀과 공유하는 방식으로 활용한다 [26:54]
• 실험한 모든 활용이 제품으로 제공할 준비가 된 것은 아니며, 일반 사용자는 내부 연구자만큼 탐색할 시간도 없다. 데이터 질문과 보고서 생성을 간소화하는 데이터 플러그인은 이런 활용법을 제품에 담으려는 사례다 [27:25]

14. 선제적 제안에는 더 높은 신뢰도와 비용 기준이 필요하다

• 사용자가 모든 질문을 직접 입력하는 대신, 담당 업무에서 놓친 문제를 먼저 알려주는 방향을 지향한다. 오전 9시 보고서로 유지율 담당자가 살피지 않은 이탈 집단을 짚어주는 것은 다음에 해결하려는 과제의 예시다 [28:00]
• 선제적으로 행동하려면 맥락뿐 아니라 발견한 사실, 해석 방향, 확신의 정도를 검증해야 한다. 어떤 근거로 사실이라 판단하고 어떤 행동을 권하는지 설명할 수 있어야 한다 [28:24]

15. 음성 입력 확산에는 기능 발견과 사용 습관의 전환이 필요하다

• 일부 초기 사용자는 책상에 여러 마이크를 두고 하루 종일 에이전트와 음성으로 소통하지만, 이런 사용 방식이 모두에게 퍼지지는 않았다 [29:46]
• 제품은 음성 기능의 존재를 더 쉽게 발견하도록 해야 하며, 사용자가 타이핑이나 터치에서 말하기로 전환하도록 도울 필요가 있다 [29:59]

16. 음성 입력과 시각적 출력을 결합하는 인터페이스

• 음성 인터페이스를 통해 AI를 어디서나 활용할 가능성은 이미 열려 있지만, 이를 누구나 자연스럽게 쓰도록 만드는 제품 경험과 활용 방식의 전달은 충분하지 않다. 새로운 인터페이스 개발과 함께 기존 음성 기능의 확산이 과제로 남는다 [30:28]
• 음성은 맥락을 빠르게 입력하는 데 효율적이고, 읽기는 듣기보다 빠르다는 관점에서 음성 입력과 생성형 시각 출력의 조합이 유망하다. 시각화 기능과 생성형 UI를 일부 시도했지만 아직 큰 성과를 낸 단계는 아니라는 평가다 [30:58]

17. 짧은 확인 질문과 실행 중 개입이 작업의 질을 높인다

• 확인 질문 하나가 불필요한 토큰 사용을 줄이고 결과를 개선할 수 있으며, Astra는 이전 모델보다 질문을 더 많이 한다. 긴 작업에서는 사용자가 자리를 비웠더라도 다른 기기로 짧은 예·아니요 질문을 보내 작업을 진행시키는 방식이 유용할 수 있다 [32:17]
• 실행 중간 메시지를 읽고 방향을 바로잡거나, 중간 결과를 다른 에이전트에 넘겨 검토받은 뒤 원래 작업에 반영하는 사용 방식이 나타난다. 작업 시간이 길어지면서 실행 도중 검토와 수정이 가능해진다 [33:07]

18. 의도 탐색에는 반복적인 거절과 제한된 실험이 필요하다

• AI의 아이디어를 여러 차례 거절하는 과정 자체가 사용자의 의도를 구체화할 수 있다. 무엇을 원하는지 알아가는 탐색과 이미 정한 목표를 실행하는 작업은 서로 다른 모드이며, 두 방식 모두 필요하지만 탐색에 적합한 인터페이스는 아직 뚜렷하지 않다 [34:58]
• 계획을 수행할 때 일정한 무작위성과 실험을 허용하면 국소적인 최적점에 갇히는 것을 피하는 데 도움이 될 수 있다. 모델도 지시를 따르면서 약간의 탐색 여지를 갖게 하자는 구상이지만, 추가 시간과 비용을 감수할 구체적인 구현 방식은 아직 정해지지 않았다 [36:15]

19. 개인의 AI 활용을 팀이 재사용하는 도구로 확장한다

• 조직의 초기 AI 도입에서는 열성 사용자, 적응 중인 사용자, 필요성을 느끼지 못하는 사용자 사이에 차이가 생긴다. 적극적인 사용자의 성과도 개인 생산성에 집중되기 쉬워, 이를 팀 전체의 성과로 연결하는 문제가 뒤따른다 [37:04]
• 팀이 반복적으로 겪는 문제를 초기 사용자가 해결하고 그 결과를 공유하는 방식이 효과적인 사례로 꼽힌다. 2주마다 갱신하는 재무 모델을 다른 사람도 사용할 수 있는 사이트로 만들거나, 이탈한 사용자 집단의 버그를 Slack에 자동 게시해 팀이 활용하도록 하는 식이다 [37:44]

20. 플랫폼별 네이티브 앱을 동시에 유지하는 목표는 아직 미완성이다

• 여러 플랫폼에서 각각 네이티브 앱을 유지하면서 기능을 같은 속도로 발전시키는 일은 기술뿐 아니라 조율의 문제다. 빠른 개발 속도 때문에 기능을 보조 맞추기 어려워 크로스플랫폼 방식을 사용하고 있다 [39:41]
• 장기적인 목표는 각 플랫폼에 가장 적합한 형태로 앱을 다시 작성하면서도 기능을 동기화하는 것이다. 아직 그 수준에는 도달하지 못했지만, 새 모델마다 Codex 앱 재작성을 시도하고 있으며 Astra는 여러 재작성 시도에서 꽤 좋은 결과를 냈다는 평가다 [40:14]

21. 풍부한 맥락의 연결과 실물 제작에서 체감되는 진전

• 이메일·브라우저·커넥터를 연결한 절약 자동화는 약 두 달 동안 유용한 결과를 찾지 못하다가, 최근 세금의 상당한 오류를 찾아 수천 달러를 절약한 사례를 만들었다. 여러 해 전의 정보까지 연결해야 하는 일이었으며, 충분한 맥락이 주어지면 개인이 혼자 해내기 어려운 결과를 얻을 수 있다는 경험으로 이어졌다 [41:24]
• 레고 제작 과제는 몇 달 전 10개나 50개 수준의 조각 수에서 한계를 보였지만, Astra에서는 1,000개 조각의 세트도 가능해졌다는 개인적 사례가 드러난다 [41:48]

🧾 결론

• 사용자의 역할은 직접 앱을 조작하는 데서 에이전트에 목표를 전달하고 실행을 검토하는 쪽으로 이동하고 있다.
• 업무 자동화의 실효성은 모델 성능, 정보 접근성, 연동 품질, 사용자의 검증 능력이 함께 결정한다.
• 개인의 성공 사례를 동료가 반복해서 사용할 수 있는 도구로 만들 때 조직 차원의 활용으로 확장할 수 있다.
• 음성 입력과 시각적 출력, 선제적 제안, 플랫폼별 네이티브 앱 유지 등은 제시된 방향이며 완성된 성과와 구분해야 한다.

📈 투자·시사 포인트

• 에이전트 제품을 평가할 때는 모델 성능과 함께 커넥터의 범위·안정성, 업무 자료 접근성, 실제 작업 완료 능력을 살필 필요가 있다.
• 가격 경쟁력은 토큰당 가격만으로 판단하기 어렵다. 원하는 결과를 얻기까지의 수행 효율과 완료 비용이 더 직접적인 비교 기준이다.
• 비개발자의 앱 제작 확산은 공유·버전 관리·지속적 개선을 지원하는 도구의 필요성을 드러낸다.
• 선제적 분석의 가치는 제안 수보다 근거의 신뢰도와 실행 가능성에 달려 있다. 제시된 경험만으로 기업의 수익성이나 투자 수익을 판단할 수는 없다.

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

• 컴퓨터 조작의 속도, 세금 오류 발견, 레고 제작 등은 발언자들의 경험 사례다. 일반적인 성공률이나 다른 업무에서의 재현성은 제시되지 않았다.
• Luna·Astra 역할 분담의 효율과 Astra의 성능 개선은 특정 실험·일부 사례에 대한 평가다. 동일한 작업 조건의 비용 및 품질 비교가 필요하다.
• 선제적 보고서, 생성형 시각 출력, 탐색을 위한 실험 허용, 플랫폼별 앱 동기화는 개발 방향이나 미완성 과제를 포함한다. 현재 제공 범위와 구분해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복 업무 하나를 골라 원하는 결과와 검증 기준을 정하고, 에이전트에 먼저 맡겨 본다.
• 필요한 문서·앱·조직 정보를 정리하고, 허용된 접근 범위에서 커넥터와 화면 조작이 각각 필요한 구간을 확인한다.
• 작업별 완료 비용, 소요 시간, 수정 횟수와 결과 품질을 기록해 자동화의 실효성을 비교한다.
• 긴 작업에는 짧은 확인 질문과 중간 검토 지점을 두고, 요청 변경을 결과에 반영한다.

❓ 열린 질문

• 컴퓨터 사용이 전용 커넥터보다 유리해지는 작업 조건은 무엇이며, 두 방식을 어떻게 배분해야 하는가?
• 선제적 제안은 어느 정도의 정확성과 실행 가치를 보여야 추론 비용과 사용자의 검토 시간을 정당화할 수 있는가?
• 비개발자가 만든 내부 앱의 유지보수와 버전 관리를 누가 맡아야 팀의 지속적인 자산이 되는가?