원문 제목: Codex-맥싱
원문 작성자: Jason Liu
번역: Peggy

편집자 주: AI 에이전트는 "코딩하는 도구"에서 새로운 작업 운영 체제로 변화하고 있습니다.

본문 작성자 Jason Liu(OpenAI Codex 팀 엔지니어)는 Codex를 사용한 경험을 바탕으로, 이런 변화가 어떻게 일어나는지를 기록했습니다: 고정된 스레드, 음성 입력, 공유된 기억부터 브라우저 제어, 원격 조작, Heartbeats 자동 루프 및 사이드바, Codex는 더 이상 프롬프트를 기다리는 채팅 창이 아니라 작업을 수행하고 컨텍스트를 기억하며 생성물을 생성하고 작업을 계속 이끌어 나가는 공간으로 변모하고 있습니다.

가장 주목할 만한 점은 Codex가 더 나은 코드를 작성할 수 있는지 여부가 아니라, 그것이 "작업이 어떻게 조직되는가"를 변화시키고 있다는 것입니다. 과거에는 AI 사용이 종종 "질문-대답" 수준에 머물렀습니다: 사용자가 요구를 제시하면 모델이 결과를 제공하고 대화가 끝나면 작업이 중단되었습니다. 그러나 이 새로운 작업 흐름 구성에서는 스레드가 지속되고, 기억이 파일로 축적되며, 작업이 정기적으로 자동으로 수행되고, 사용자가 언제든지 개입하고 검토하고 수정할 수 있으며, 마지막으로 작은 실행 루프를 형성합니다.

이는 Agent의 가치가 "능력"에서 "연속성"으로 변하고 있다는 것을 의미합니다. 그것은 단순히 사람이 특정 작업을 완료하는 데 도움을 주는 것이 아니라 다양한 도구, 파일, 브라우저, Slack, Gmail, 캘린더 및 로컬 애플리케이션 간의 연결을 구축하여 작업이 사용자가 떠난 후에도 계속 진행되도록 합니다. 지식근로자에게 있어서, 이는 AI 도구가 실제로 일상적인 생산 프로세스로 진입하는 중요한 단계일 수 있습니다: 특정 동작을 대체하는 것이 아니라 더 많은 작업이 프롬프트 후에 멈추지 않도록 하는 것입니다.

아래는 원문입니다:

Codex는 코드를 작성하는 것뿐만 아니라 작업 흐름을 인수

Codex가 나타나기 전에, 나는 이미 프로그래밍 에이전트를 대규모로 사용해 왔습니다. 그러나 대부분의 시간에는 그들을 프로그래밍 작업에 특화된 인터페이스에서 사용했습니다: 차이 생성, 코드 저장소 수정, 코드 전달.

약 11월부터, 나는 이들을 지식 작업 환경으로 밀어 넣기 시작했습니다. Slidev를 사용하여 프레젠테이션을 만들고, Agent를 음성 입력 기능을 갖춘 비서로 사용하며, 프로그래밍 에이전트가 생성에 도움을 줄 수 있는 다른 것들을 찾아왔습니다: index.html, PDF, 스프레드시트, 프레젠테이션 세트.

코덱스 앱의 최신 업데이트는 나에게 보다 폭넓은 업무 방식이 "네이티브"로 느껴지게 하는 첫 번째 제품이었습니다. 코덱스는 여전히 코드 작성에 능숙하지만, 더 흥미로운 변화는 나에게 일을 "놓아둘(안에서 작업할 수 있는)" 공간을 제공하기 시작했다는 점입니다.

내 사용 습관을 진정으로 바꾼 것은 업무를 실행하는 루프를 설정하는 방법을 배운 것이었습니다: 장기 저장 가능한 스레드, 공유된 기억, 컴퓨터를 제어할 수 있는 도구, 언제든 개입하고 작업을 복구할 수 있는 방식, 그리고 생성물 자체를 직접 검토할 수 있는 인터페이스를 갖추었습니다.

영속적인 스레드

내 행동을 변화시킨 첫 번째 기능은 컨텍스트 압축입니다.

이제, 모든 중요한 작업 흐름에 대해 상단에 고정된 스레드를 유지합니다:

제 체프스테프 스레드

에이전트 SDK

OpenAI CLI

오픈 소스용 코덱스

트위터를 모니터링하기 위한 전용 스레드

이들은 대화가 아닙니다. 이것들은 이미 몇 달 동안 압축해 놓은 거대한 스레드입니다. 그들은 지속적으로 히스토리, 선호도, 이전 결정을 쌓아올리며, 이 정보들을 매번 되풀이해야 하는 것을 원치 않습니다.

상단 스레드 바로 가기

Command-1부터 Command-9로 상단 스레드로 바로 이동할 수 있습니다.

여기서는 물론 희생이 따릅니다. 장기 실행되는 스레드는 무료가 아닙니다. 나중에 다시 그들을 열면 대화가 캐시에 없을 가능성이 높기 때문에, 새로운 짧은 스레드를 연 다는 것보다 비용이 더 들 수 있습니다. 그러나 내가 정말로 중요시하는 작업 흐름에 대해선 연속성이 가치 있습니다.

음성 입력

음성 입력은 코덱스가 내 진정한 사고 과정을 더 많이 이해하도록 돕습니다.

그 이점은 속도에 있지 않고, 에이전트가 편집되지 않은 사고의 원천을 얻을 수 있다는 점에 있습니다. 코덱스에는 음성 입력 기능이 내장되어 있지만, Wispr Flow도 사용합니다. 시스템 수준의 음성 인식은 내가 다른 도구에 맥락을 입력하는 방식을 변경합니다. 작업을 계획하고 있을 때 "나는 슬랙에 벤이라는 사람이 이야기한 것을 기억하는데, 구체적으로 무엇인지 기억 안 나네, 확인 좀 해봐."라고 말할 수도 있습니다. 이 문장을 입력하면 흐림과 성가신 느낌이 나지만, 말하면 매우 자연스럽습니다.

전사 텍스트도 마찬가지입니다. 제가 기사를 쓰고 싶다면 누군가에게 전화해서 대화를 녹음하거나 Granola 앱을 사용해 오프라인 대화를 기록한 다음 전사를 출발점 자료로 사용할 수 있습니다. 많은 계획이 더 나아지는 이유 중 하나는 모델이 내 혼돈스럽지만 실제 아이디어를 받아들이기 때문입니다. 그것이 내가 갈취한 버전뿐만 아니라는 것입니다.

Steering: 지속적인 유도

음성 입력은 Steering과 결합될 때 더 유용해집니다.

Steering을 사용하면 한 번의 도구 호출 후에도 다음 메시지를 계속해서 주입할 수 있습니다. 예를 들어, 웹 사이트를 검토하는 동안 다음과 같이 이야기할 수 있습니다:

이 부분을 작게 만들어 줘

이 문구는 틀렸어

이 두 요소 사이 간격이 안 좋아

작업을 마치고 PR을 엽니다

미리보기 배포를 기다려

Slack에서 검토해야 할 사람에게 미리보기 링크를 보내

매 단계가 끝날 때마다 다음 단계를 결정해야 하는 것이 아닙니다. Agent가 작업 중일 때도 의도를 계속 추가하고 이미 대기 중인 작업을 가지고 떠날 수 있습니다.

그러면 Heartbeats는 제가 떠난 후에도 PR이나 Slack 스레드를 계속 모니터링할 수 있습니다. 작업 단위는 더 이상 "명령 하나, 응답 하나"가 아니라 작은 실행 루프가 됩니다.

기억

한 번 스레드가 장기간 존재하기 시작하면 단일 코드 저장소에 의존하지 않는 공유 기억이 필요해집니다.

그냥 메시지 기록을 저장하는 것만큼 중요하지 않습니다. 장기 스레드는 물론 많은 정보를 기억할 수 있지만, 그 유용한 정보가 어딘가에 지속 가능한 위치에 직렬화되지 않으면 그 안에 갇히게 됩니다. 기억 시스템의 목적은 스레드에서 배운 것들을 검토, 편집, diff 비교 및 재사용할 수 있는 형태로 변환하는 것입니다.

내 장기 스레드 대부분은 Obsidian 보우트에서 시작됩니다:

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

최상위에서 AGENTS.md 지침을 유지하고 있을 겁니다. 더 많은 내용을 알게 되거나 프로젝트를 추진하거나 할 일 루프를 닫으면 해당 페이지를 업데이트하라는 내용이 포함되어 있습니다.

이 vault는 Agent가 「거주」하는 곳이며, 어떠한 단일 프로젝트에도 독립적입니다. 코드 저장소에는 코드가 저장되어 있고, vault에는 내 작업 주변에 있는 롤링 컨텍스트가 저장됩니다: 캐릭터, 의사 결정, 미완료된 사항, 일일 노트, 프로젝트 상태, 그리고 스레드 간에 쉽게 잊어버릴 수 있는 이해.

나는 이 vault를 GitHub 저장소로도 유지할 것입니다. 이렇게 함으로써 두 가지 이점이 있습니다:

클라우드에서 실행할 수 있음;

차이가 검토 메모리의 인터페이스가 됨.

Agent가 vault를 업데이트할 때, 나는 diff를 읽어 어떤 내용이 중요하다고 생각해 외워질 가치가 있는지 볼 수 있습니다. 이 검토 단계는 매우 중요합니다. 나는 영구적인 스레드가 대화 기록에서 모호한 '느낌'을 서서히 축적하지 않기를 원합니다. 사건이 실제로 변한 내용, 이 사람이 선호하는 것, 이 프로젝트가 무엇을 기다리고 있는지, 이 결정이 내려졌고, 이 루프가 닫힌 것을 적어 두기를 원합니다.

이것이 왜 나는 기억을 파일로 만드는 것을 좋아하는지도 입니다. 파일은 Agent가 경험을 스레드에서 벗어나서 계속 존재할 수 있는 형태로 압축하도록 강제합니다. 스레드가 사라지고, 압축이 매우 나쁘며, 계속해서 의존하면 너무 비쌌을 때도, 유용한 지식은 여전히 그 자리에 있습니다.

이 단계에 이르면, 고정 스레드는 더 이상 채팅 창 같지 않고, 서로 다른 직원이 동일한 노트북을 읽는 것처럼 보입니다.

Codex에서는 설정 > 개인 설정 > 기억 에서 일차 기억 기능을 제공합니다. 내가 이해한 바로는 이것이 로컬 리콜 레이어로 작용함: 안정적인 선호, 반복 작업 흐름, 프로젝트 관례 및 알려진 함정을 기록하는 데 적합하지만, 저장소로 제출된 명령이나 명시적인 vault를 대체할 수 없습니다. 이 곳에서 Chronicle이 특히 흥미로운데, 최근 스크린 컨텍스트를 활용하여 기억을 구축하는 데 도움을 줄 수 있습니다. 나는 아직 진지하게 사용하지 않았으며, 문서는 명시적으로 이 기능이 연구 미리보기로 활성화되어야 하며 권한, 속도 제한, 팁 삽입 및 암호화되지않은 로컬 기억 파일 등의 영역에서 실제로 타협해야 한다고 설명하고 있습니다. 그러나 방향적으로 보면, 내가 관심 있는 것을 가리 키는 것이 분명합니다: 작업은 구조화된 기억을 남겨야 하며, 단순히 더 긴 채팅 기록만 남겨서는 안됩니다.

컴퓨터 및 브라우저 사용

한번 스레드가 기억을 소유하면, 다음 질문은: 그것이 무엇에 접근할 수 있는가?

내 자신의 이해에 따르면, 가장 유용한 구별은 다음과 같습니다:

$browser: 로컬 웹 페이지 인터페이스를 검사하고 주석을 달고자 할 때 사용하는 것

@chrome: 로그인된 브라우저 상태 및 여러 탭을 위해 사용하는 것

@computer: 그래픽 인터페이스를 통해서만 수행할 수 있는 작업을 위해 사용하는 것

만일 로컬 앱을 고도화하는 중이라면 $browser를 사용하고 싶을 것입니다. 만일 로그인된 브라우저 세션에서 작업을 수행해야 한다면 @chrome을 사용하고 싶을 것입니다. 만일 작업을 수행하는 유일한 방법이 특정 데스크톱 앱을 클릭하는 것이라면 @computer가 필요할 것입니다.

제 작업용 컴퓨터에서는 Twitter가 Safari에 로그인되어 있습니다. @computer에게 Twitter를 읽도록 했을 경우 Safari를 사용할 수 없게 됩니다. 그리고 인증된 여러 탭을 동시에 사용하고 싶지만 현재 작업 중인 앱 전체를 이관하고 싶지 않은 경우, @chrome이 더 적합할 것입니다.

커넥터는 이 능력을 제 실제 작업의 다른 부분으로 확장시킵니다. 제가 가장 자주 사용하는 것은 $slack, $gmail 및 $calendar인데, 이는 많은 작업이 코드가 되기 전에 먼저 Slack 스레드, 이메일 및 캘린더에 나타날 때가 많기 때문입니다.

Skills는 반복 작업 흐름을 재사용할 수 있게 합니다. Skill Creator 및 Skill Installer이 좋은 시작점입니다. Skill Installer을 통해 OpenAI가 권장하는 스킬을 직접 composer에서 추가할 수 있습니다. Codex Pets가 출시된 후, 저는 Hatch Pet 스킬을 설치하는 데 사용했지만 정말 가치 있는 것은 이러한 일반적인 패턴입니다: 유용한 작업을 한 번 성공적으로 수행한 후에는 일반적으로 그것을 패키지로 만들어 Codex가 전체 과정을 다시 배우지 않고도 그 작업을 다시 수행할 수 있게 합니다.

작업 전진

원격 제어

원격 제어를 통해 이러한 더 긴 작업 흐름을 휴대 가능하게 만들 수 있습니다.

Codex는 이미 귀하의 파일, 권한 및 로컬 환경을 보유하고 있는 기기에서 계속 작업할 수 있으며, 당신은 진행 상황을 모니터링하고 발견한 것을 검토하거나 질문에 답변하고 다음 단계를 승인하거나 방향을 변경할 수 있는 스마트폰을 통해 접근할 수 있습니다. OpenAI는 이를 언제 어디서든 Codex와 협업할 수 있는 방식으로 설명합니다.

만일 Codex가 긴 작업을 수행 중이고 계속해서 진행 상황을 유지하고 싶다면, 이것이 가장 중요합니다. 작업을 시작하고 떠나면서 작업을 진행할 수 있으며, 결정이 필요한 지점에 도달하면 스마트폰을 사용하여 안내할 수 있습니다.

이는 고정 스레드, 음성 입력 및 Heartbeats가 중요한 이유와 동일합니다: 교체된 위치로 인해 더 이상 작업이 중단되지 않습니다. 스레드는 계속 실행될 수 있고, 저는 그것이 다음 단계를 진행하는 데 충분히 적은 관심을 기울이기만 하면 됩니다.

Heartbeats

고정 스레드는 유용하지만 여전히 명령을 기다립니다. Heartbeats는 그들이 주기적으로 실행될 수 있도록 합니다.

Heartbeat는 스레드의 지역 자동화입니다. "몇 시간마다 이것을 확인해 주세요"라고 말할 수 있습니다. 그런 다음 스레드는 자체 스케줄을 설정할 수 있습니다. 스레드에는 여러 일정이 있을 수 있으며, 어떤 조건이 충족될 때까지 계속 실행하거나 실행 빈도를 시간에 따라 조정할 수도 있습니다.

총무장군

내 총무장군 스레드는 매 30분마다 실행됩니다:

매 30분마다 Slack과 Gmail을 확인하여 내가 주의를 기울여야 할 메시지가 있는지 확인합니다.
가장 중요한 일을 판단하는 데 도움을 줍니다.
누군가 질문을 하면 가능한 깊이 답변을 조사하고 대답 초고를 작성하지만 전송하지는 않습니다.

다시 Slack으로 돌아가면 대답 중 많은 것이 이미 초고에 있습니다. 전송할 내용을 여전히 결정하지만 가장 힘든 컨텍스트 수집은 이미 완료되었습니다.

피드백 모니터링

동일한 패턴은 리뷰 주기에도 적용됩니다. Heartbeat는 Google 문서 댓글, 풀 리퀘스트 댓글 또는 Slack 답글을 모니터링하고 피드백이 나타날 때 작업을 계속 진행합니다.

내가 가장 좋아하는 예 중 하나는 애니메이션 프로젝트에서 나온 것입니다. Slack에 비디오를 게시하고 Codex에게 매 15분마다 스레드를 확인해 피드백이 있는지 확인하도록 했습니다. 댓글이 있으면 새 버전을 다시 렌더링하고 해당 스레드에 답글을 작성하여 리뷰어를 언급했습니다. Slack MCP 서버는 파일을 업로드할 수 없어 Agent가 @computer를 사용하여 "파일 추가" 버튼을 클릭하고 수정된 렌더 파일을 올렸습니다.

흥미로운 점은 15분마다 Slack을 확인하는 것뿐만 아니라,이 루프가 여러 도구 경계를 가로질러 확장된다는 것입니다: Slack은 피드백을 수집하는 데 사용되고, Remotion은 렌더링에 사용되며, @computer 사용하여 업로드합니다. Heartbeats, 커넥터 및 컴퓨터 작업이 결합되면 더 이상 독립적인 기능으로 보이지 않고 제자리에 앉아 있지 않아도 계속되는 피드백 루프가 됩니다.

환불 요청

최근에 제가 송장을 도난당했습니다. Amazon은 실제 상담원과 연락하려면 대략 25분이 걸릴 것이라고 말했습니다. 그래서 저는 @computer가 있는 스레드를 만들었고, 다음과 같이 알려주었습니다:

매 5분마다 상담원이 이 대화에 참여했는지 확인하십시오.
참여한 경우 최대한 환불을 요청해주세요.
상대방이 회신하면 분 단위로 확인하도록 변경하여 신속히 대응하십시오.

샤워를 하고 나왔을 때, 환불이 이미 처리되어 있었습니다.

많은 Heartbeats들도 제 Obsidian 보물창고를 업데이트하여 명시적인 기억으로 삼습니다.

목표

저는 최신 기능인 Goals을 더 잘 활용하기 위해 공부 중입니다.

보다 야심찬 목표를 설정해야 합니다. 약한 목표는 "이 Markdown 파일의 계획 실행"입니다. 강력한 목표는 실제 성공 기준이 있어야 하며, Agent가 이를 계속 추진할 수 있어야 합니다.

지난 주에는 Python Rich 라이브러리를 Rust로 이관해 보았습니다. 원래 프로젝트 자체에 방대한 단위 테스트가 이미 있기 때문에 이와 같은 목표를 설정할 수 있었습니다: Rich를 Rust로 이관하는데, 그것은 원래 Python 라이브러리의 모든 단위 테스트를 통과해야 합니다.

이 테스트 세트는 실행에 대한 실제 판단 기준을 제공합니다. Rust 버전은 Python 원본 라이브러리와 동일한 테스트를 통과해야만 완료로 간주됩니다.

이는 장기적인 대화를 AI와 나누는 것, Markdown 계획을 축적한 후 마지막에 "실행하십시오."라고 말하는 것과 다릅니다. 실행 효과의 상한선은 목표와 검증 방식에 달려 있습니다. 확인되지 않은 야망은 소망에 불과합니다.

AI가 실제로 업무 흐름에 참여하기

사이드바

제게 가장 설레는 Codex의 부분은 사이드바입니다.

사람들은 이를 발생한 곳의 미리보기로 쉽게 이해합니다. 그러나 이해는 이를 과소평가합니다. 사이드바는 더는 Codex가 단순한 채팅 애플리케이션일 뿐이 아니라 작업이 발생하는 곳이 되기 시작한다는 것을 의미합니다.

제게 있어서, 이는 제품을 확인하고, 웹 인터페이스를 조작하며, 변경 사항을 검토하는 세 가지 역할을 수행합니다. 이 세 가지 경우에도 Agent가 조작 중인 동일한 객체를 보고 검토할 수 있습니다.

검사 생성물

Markdown, 스프레드시트, CSV, PDF 및 프레젠테이션은 모두 여기에 배치할 수 있습니다.

Markdown은 주석이 가능합니다. 스프레드시트는 수식을 렌더링하고 셀 편집을 지원하며, 저는 Codex 오픈 소스 프로젝트를 관리하는 데 사용하겠습니다. CSV는 텍스트가 아닌 표로 표시되며, PDF는 직접 렌더링되어 특히 LaTeX에 유용합니다. 프레젠테이션도 완전히 응용 프로그램을 벗어나지 않고 생성 및 검토할 수 있습니다.

중요한 것은 Codex가 이러한 생성물을 생성할 수 있는 것뿐만 아니라, 제가 루프를 방해하지 않고 이들을 확인하고 주석을 달 수 있는 것입니다.

웹 인터페이스 조작

내장 브라우저는 더 재미있습니다. 에이전트는 그것을 볼 수 있으며, $browser를 통해 JavaScript를 사용하여 제어할 수 있으며, 나는 바로 내가 보고있는 콘텐츠에 주석을 달 수 있습니다.

지금 이 방식으로 자주 사용하는 몇 가지 웹 인터페이스가 있습니다:

index.html, 경량 정적 생성물용;

Storybook, UI 구성 요소 검토용;

Remotion Studio, 프로그래밍 방식 애니메이션용;

Slidev, 프레젠테이션용;

Streamlit, 데이터 애플리케이션용.

최소한의 버전이 종종 가장 좋습니다. 모델을 사용하여 JavaScript 및 CSS가 포함된 단일 파일 index.html을 만들어 사이드 패널에서 열고 즉시 상호 작용을 시작할 수 있습니다. 서버가 필요하지 않습니다. 저는 항상 시간이 지남에 따라 정적인 index.html을 Heartbeats로 업데이트하려고 노력하고 있으며, 이렇게 하면 스레드로 돌아갈 때마다 새로운 생성물이 기다리고 있습니다.

Thariq는 Markdown 대신 HTML을 출력 형식으로 선호하는 이유에 대해 좋은 글을 썼습니다. 이 직관이 옳다고 생각합니다. 출력물이 문서가 아닌 소규모 응용 프로그램이 되면, 사람과 생성물 간의 관계가 변경됩니다.

더 무겁게 할 필요가 있으면 Vite 앱을 사용할 수도 있지만, 그럴 경우 서버를 유지해야 합니다. 순수 index.html이 훨씬 더 영속적입니다.

애니메이션을 만들 때, 저는 종종 Storybook과 Remotion Studio를 나란히 열어 둡니다. "이것을 살짝 튕기게 해주세요" 또는 "이것은 조금 더 크게"와 같은 주석을 남길 수 있으며, 에이전트는 현재 보고있는 브라우저 상태를 확인할 수 있습니다. 이 상태에는 현재 프레임의 애니메이션이 포함됩니다.

발표 자료를 준비할 때, 저는 주로 Slidev를 사용합니다. Codex는 슬라이드를 검사하고 잘린 콘텐츠를 찾아내며 페이지 간 전환을 하며 제 리뷰시 주석에 응답합니다.

저는 또한 이러한 방식이 향후 Streamlit 및 Jupyter와 같은 도구에서 더 유용해지기를 기대합니다. 사람들이 다른 응용 프로그램 안에서 살아가고 있으니까요. Codex는 저희들이 살고 있는 곳으로 더욱 많이 들어가고 있습니다.

Codex가 기억하고 다시 방문하며 검토하고 조치할 수 있는 곳을 가지기만 할수록, 제 업무는 한 번 끊임 없는 프롬프트 사이에서 죽어가는 것이 덜해집니다. 이것이 제가 실제로 걱정하는 변화입니다: 에이전트가 제 대신 코드를 작성할 수 있는 것이 아니라, 제가 떠난 뒤에도 더 많은 일이 진행될 수 있기를 원합니다.

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia