ChatGPT Work + Codex Tutorial: My Complete System at OpenAI | Jason Liu

URL: https://www.youtube.com/watch?v=ydTeb_I0b94 날짜: 2026-07-27 채널: Peter Yang (게스트: Jason, OpenAI Codex 팀)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

OpenAI Codex 팀의 Jason이 자신의 실제 업무 시스템을 공개하며 던지는 핵심 메시지는 ==이제 코딩은 해결된 문제이고, 남은 유일한 스킬은 "내가 무엇을 마음에 안 들어하는지 이해하고 그것을 말로 표현해 AI에게 전달하는 능력"==이라는 것이다.

• ChatGPT Work는 Codex의 코딩 경험을 UX만 다르게 감싼 것으로, 코드 diff·PR 같은 기술적 디테일을 숨기고 업무 생산성 툴처럼 보이게 만든 뷰(view)다
• Jason은 스레드를 "하트비트(heartbeat)"로 만들어 하루 3번(9시/13시/17시) 이메일·Slack·Linear를 스스로 체크하고 우선순위를 알려주는 "비서(Chief of Staff)" 자동화를 운영한다
• 스킬(Skill)은 계속 손봐야 하는 살아있는 도구이며, Codex 스스로 과거 세션을 되짚어 어떤 스킬이 안 쓰이는지, 어떤 피드백이 반복되는지 찾아내 자가 개선하게 만든다
• 브라우저/컴퓨터 사용(computer use) 기능으로 로그인 상태를 유지한 채 자율적으로 웹 작업을 수행시키는 것이 그의 최애 기능이다

전체적으로 이 영상은 "AI 에이전트를 잘 쓰는 사람의 실제 운영체제(OS)"를 낱낱이 보여주는 튜토리얼이며, 특정 기능 소개보다 Jason이 어떻게 자신의 업무·개인 생활 전체를 Codex 중심으로 재편했는지에 초점을 맞춘다.

---

1. ChatGPT Work vs Codex — 기본 개념

ChatGPT Work는 별도의 제품이 아니라 Codex 경험을 다르게 보여주는 UX 레이어에 가깝다.

1.1. Work와 Codex의 차이

1. UX 레이어링
   1. Codex의 원래 뷰: git 히스토리, pull request, 코드 변경사항을 그대로 보여준다 — 개발자에게 익숙한 화면
   2. Work의 뷰: 슬라이드를 만들 때처럼 "내가 파이썬 코드 20줄을 썼다"는 사실을 볼 필요가 없는 비개발 업무를 위해 그 디테일을 뒤로 숨긴다
2. 좋은 코딩 에이전트 = 좋은 업무 툴의 출발점
   1. 설계 철학: "정말 좋은 업무 생산성 툴을 만들려면 정말 좋은 코딩 에이전트에서 출발하는 게 맞다"는 것이 Jason의 관점
   2. Jason 본인의 사용 패턴: 요즘은 코드 리뷰를 거의 하지 않기 때문에 실제 업무 대부분을 Work에서 처리한다 (Peter도 "요즘 다들 코드 리뷰 안 하지 않냐"고 맞장구)

1.2. 모델/이펏(effort) 레벨 선택 기준

1. 평상시 업무 — Medium
   1. 적용 범위: Slack 읽기, 캘린더 세팅, 회의 스케줄링 등 일상 업무 대부분은 최고 지능이 필요 없어 "sole medium"을 기본값으로 쓴다
2. 프로토타입 빌드 — Extra High / Ultra
   1. 적용 범위: 드럼 연습용 앱처럼 복잡한 목표를 세우고 몇 시간 동안 Codex가 알아서 작업하게 둘 때는 Extra High나 Ultra로 올린다

---

2. 스레드/프로젝트 조직 방식

2.1. 핀(pinned) 스레드 중심의 운영

1. DX(Developer Experience)팀 업무 특성
   1. 운영 성격: Jason의 업무 절반은 외부에서 벌어지는 일을 관리하는 것 — Reddit, Twitter, LinkedIn을 읽어 피드백과 이슈를 파악하는 자동화가 여러 개 돌아간다
   2. Chief of Staff 스레드: 일간/주간 단위로 무엇에 집중해야 하는지 알려주는 스레드가 따로 있고, 각각 다른 자동화 루프 주기로 돈다
2. 핀 스레드 = 워크스페이스
   1. 구조: dev day 기획, 미션 비디오 작업, agents API 관련 스레드, 드럼 개인 프로젝트, 슬라이드 작업 등 거의 모든 것이 "핀 스레드" 하나로 관리된다
   2. compaction의 역할: 수백 개의 백그라운드 스레드를 두는 게 아니라, 핀 스레드 각각이 compaction(압축)으로 관리되는 하나의 지속되는 워크스페이스라서 이전 맥락을 잃지 않는다
3. 중요한 건 기록, 부가 작업은 서브에이전트
   1. 노트 저장: 중요하다고 판단되면 모델에게 notes 디렉토리에 저장하라고 지시한다
   2. 서브에이전트 위임: 메인 스레드에 부가 작업을 시키는 대신 서브에이전트를 띄우도록 지시 — Ultra 모드에서는 자동으로 되지만 Jason은 서브에이전트를 띄우는 데는 좀 더 신중한 편이다

2.2. Vault(Obsidian) 중심 구조

1. 프로젝트 구성
   1. Vault = 유일한 메인 프로젝트: 거의 모든 맥락을 옵시디언 vault에 기록해두기 때문에 사실상 하나의 큰 프로젝트만 존재한다
   2. Animate Codex = 사이드 프로젝트: Codex를 모션 그래픽에 활용해보는 별도 사이드 프로젝트
2. 다른 코드베이스와의 연결
   1. 출발점은 항상 vault: 모노레포나 데모 프로젝트 등 다른 코드베이스가 있어도 전부 vault에서 시작하고, GitHub에 있으니 클라우드로 옮길 때도 그 레포를 pull해서 시작하면 된다
3. 왜 굳이 Obsidian인가
   1. 가끔의 시각적 이점: 이미지 렌더링, 크로스링크 탐색이 필요할 때는 Obsidian을 직접 열어보는 게 낫다
   2. 주 용도는 에이전트 컨텍스트: 실제로는 거의 직접 열어보지 않고, 에이전트가 참고하는 컨텍스트 용도가 대부분이다
   3. 그냥 마크다운 파일 모음: 데이터베이스가 아니라 프로젝트별/사람별/노트별 디렉토리 + 데일리 노트 + 개인 preferences로 구성된 순수 마크다운 파일들이다

---

3. Chief of Staff — 하루 3번 자동 브리핑

3.1. 데일리 루틴 설정

1. 실행 주기: 오전 9시, 오후 1시, 오후 5시에 자동 실행되는 자동화
2. 체크 대상
   1. Slack 전체: 모든 메시지를 읽는다
   2. Twitter DM: computer use를 이용해 트위터 DM까지 읽는다
   3. 미응답 이메일: 답장하지 않은 이메일 전부
   4. Linear 보드: 상태 업데이트가 필요하면 Codex가 직접 정리해준다
3. 실제 사례
   1. 여행 리마인더: 곧 브라질에 가야 한다는 걸 스스로 파악해 처리할 일을 알려줌
   2. 택배 픽업 알림: 소포를 찾아와야 한다는 것도 알려줌
   3. 항공권 체크인 자동화: 예약 티켓과 예약번호(reference number)를 발견하면 Codex가 알아서 체크인하고 개인 휴대폰으로 탑승권을 문자로 보내준다 (업무용 노트북과 별개로)
   4. 회의 준비: Linear 티켓 기반으로 회의 노트를 미리 준비, 마케팅팀과의 후속 회의 관련 피드백 정리
   5. 캘린더 자동 등록: 토론토에서 프로덕션 이슈가 있다는 얘기를 들으면 스크린샷을 찍어 캘린더에 반영

3.2. 처음 세팅하는 방법 (비개발자 기준)

1. 최초 프롬프트
   1. 기본형: "이 스레드를 하트비트로 만들어줘. 이메일, Slack, Linear를 필요할 때마다(9시/13시/17시) 체크하고 무엇을 우선순위로 둬야 할지 알려줘"
   2. 효과: 이것만으로도 해야 할 일에 대한 꽤 괜찮은 개요를 얻을 수 있다
2. 점진적 개선
   1. 피드백 축적: 처음엔 링크를 안 넣어줬다가 "링크 꼭 포함해줘"라고 하나씩 알려주며 개선
   2. Linear 도입: 상황이 복잡해지면서 "Linear를 쓰자"고 결정
   3. 초안 작성까지 발전: 시간이 지나며 이메일이 왔다고 알려주는 수준을 넘어 Slack 답장·이메일 초안을 미리 써두고 링크만 열어 다듬어 보내는 수준까지 발전
3. 자동 발송 여부는 상황에 따라 다름
   1. 자동 발송하는 경우: 코드 작업 중 "PR 만들고 테스트 통과하면 Andrew에게 Slack DM으로 PR 링크와 프리뷰 URL 보내줘" 같은 명확한 조건이 있을 때
   2. 자동 발송 안 하는 경우: 하트비트 스레드는 이메일 40개, Slack 메시지 100개를 읽기 때문에 좀 더 신중하게(surgical) 처리하고 싶어한다

---

4. 스킬(Skill) 시스템 — 나를 대신 말하게 하기

4.1. "Write Me" 스킬 — 내 목소리 학습시키기

1. 제작 방법
   1. 초기 학습: Codex에게 "Slack 커넥터를 써서 지난 1주일 내가 쓴 메시지를 읽고, 내 말투를 파악하는 스킬을 만들어줘"라고 요청
   2. 세분화: 외부 사용자에게 말할 때와 팀원에게 말할 때, 임원에게 말할 때와 동료에게 말할 때 어조를 다르게 하도록 지시
2. 지속적 편집
   1. 초기 버전: 처음엔 그냥 말투를 흉내내는 수준
   2. 시간에 따른 발전: 계속 스킬 파일을 수정해가며 다듬는다 — 이메일에도 동일한 방식 적용
3. Jason의 개인 스킬 목록 (개인 저장소 repo에 보관)
   1. write me: 글쓰기 스킬
   2. email me: 이메일 답장 스킬
   3. tweet me: 트윗 작성 스킬
   4. voice-to-blog: 음성 트랜스크립트를 블로그 포스트로 변환
   5. video-to-essay: 자신이 나온 영상을 비디오 에세이로 변환

4.2. 스킬 정리(clean up)와 자가 개선

1. 정기 정리 프로세스
   1. 세션 데이터베이스 활용: 모든 세션이 어딘가 데이터베이스에 저장되어 있어서(정확히 어딘지 Jason도 모름), "지난 400개 세션을 보고 어떤 스킬이 한 번도 안 쓰였는지 찾아서 정리해줘, 나를 인터뷰해줘"라고 지시하면 잘 처리한다
   2. 실제 사례: 잘 안 쓰는 데이터 분석 스킬은 삭제하고 필요할 때 재설치 제안 / 여러 Slack 스킬을 통합 제안 / write me·slack me·email me를 하나로 합칠지 검토
2. 채용 비유
   1. 핵심 관점: 스킬을 만드는 건 "첫날 출근한 사람에게 정보를 잔뜩 알려주고, 계속 피드백을 주면서 시간이 지나며 나아지게 하는 것"과 다르지 않다 — 처음부터 영원히 완벽하게 도는 스킬을 기대하지 않는다
   2. 정리 주기의 변화: 예전엔 정기적으로 정리 태스크를 예약해뒀지만 요즘은 그때그때 "지금쯤 정리할 때가 됐다"고 판단해서 처리 (worktree 정리 포함)
3. 자가 개선(self-improve) 스킬
   1. 개발 배경: 4개월 전에 만든 "self-improve" 스킬 (개인 repo에는 아직 안 올림, 그 사이 많이 바뀜)
   2. 작동 방식: 가장 많이 호출된 스킬들의 세션을 훑어보고 반복되는 피드백이 있었는지 찾아낸다
   3. 글쓰기 스킬 개선 예시: "지난 2주간 업데이트 안 됐으니 최근 슬랙 메시지 200개, 최근 트윗 200개, 최근 블로그 포스트 몇 개를 읽고 반영해줘"라고 요청
   4. Slack 스킬 개선 실사례: Slack에서 뭔가 요청받아 Codex에게 처리시킬 때마다 "처리 후 Slack에 답장해줘"라고 매번 말해야 했는데, self-improve 스킬이 이 패턴을 발견한 뒤로는 "내부 요청을 대신 처리해달라고 부탁받으면, 끝난 뒤 알아서 답장한다"는 규칙을 스스로 학습해 마찰을 줄였다

---

5. 스킬 vs 플러그인

5.1. 개념 구분과 배포

1. 관계 정의
   1. 스킬은 플러그인의 한 구성요소: 플러그인은 MCP 서버 여러 개 + 스킬 여러 개 + 각종 리소스·스크립트의 묶음이다
   2. 예시: write 스킬, slack 스킬, email 스킬을 팀에 공유하려면 "better writing"이라는 단일 플러그인으로 묶어서 배포하는 게 맞는 방식
2. 플러그인 디렉토리 개방
   1. 지난주부터 시행: 누구나 자신의 플러그인을 Codex 플러그인 디렉토리에 제출할 수 있게 됐다
   2. 심사 절차 차등화: 스킬만 있는 제출물은 빠르게 검토되고, MCP가 포함된 경우 보안 감사를 위해 좀 더 절차를 거친다

---

6. 브라우저 & 컴퓨터 사용 — Jason이 가장 좋아하는 기능

6.1. 자전거 라이딩 중 벌어진 실화 (대표 사례)

1. 상황 발생
   1. 계기: 자전거를 타던 중 동료가 Slack으로 "이 비디오 자막이 이상한데 다시 익스포트해줄 수 있어? GitHub 접근이 필요해서 검토해달라"고 요청
   2. 원격 제어: 휴대폰으로 맥북을 원격 제어해서 Codex에게 "컴퓨터 사용으로 이 비디오가 어디 있는지, 어떤 툴로 익스포트됐는지 찾아서 편집하고 Slack에 다시 올려줘"라고 문자로 지시
2. 결과
   1. 20분 후: 수정 사항이 반영된 새 비디오가 Slack 스레드에 올라옴
   2. 후속 지시: "30분마다 Slack 스레드를 확인해서 피드백이 오면 V2, V3, V4를 계속 익스포트해줘"라고 추가 지시
   3. 최종 결과: 집에 돌아왔을 때 이미 컨펌(green lit)까지 끝나 "migrate to Codex" 런칭 비디오로 확정됨
3. 투명성 문제
   1. 상대방 인지 여부: 피드백을 준 지 40분 후에 새 버전이 올라오는 패턴 때문에 시간상으로는 사람이 아니라 Codex라는 걸 알아채기 어려웠을 것

6.2. 브라우저 사용 팁

1. 로그인 상태 유지
   1. 핵심 포인트: Codex 내부 브라우저는 OAuth로 쿠키를 가져올 수 있어 로그인된 상태로 훨씬 더 많은 정보에 접근 가능하다
2. 멀티탭 제어
   1. 활용법: 리서치나 비교 작업, 리뷰 준비 등에 매우 효과적
   2. 쇼핑 리서치 실사례: 마크다운 파일로 추천 목록을 만들게 하는 대신 "리서치 후 추천 상품마다 각각 별도 탭으로 열어줘"라고 요청 — 커피 타러 갔다 오니 탭 4개가 열려 있었고, 리뷰를 각각 읽고 마음에 드는 것에 체크아웃을 눌렀다
   3. 아직 안 하는 것: 자동 체크아웃까지는 아직 못 맡기지만, 탭으로 정보를 보여주는 방식 자체는 매우 유용했다고 평가
3. 신뢰 수준에 대한 논의
   1. 주식 거래 사례: 누군가는 컴퓨터 사용으로 주식 거래까지 한다고 하는데, Peter는 아직 그 정도로 신뢰하지 않는다고 언급
4. 인앱 브라우저 vs Chrome / Computer Use의 범위
   1. 기본 원칙: AI 전용 브라우저에 직접 로그인해서 대부분의 사이트 작업은 그 안에서 처리
   2. 컴퓨터 사용의 역할: 애플리케이션 레벨의 설정 제어가 필요할 때만 사용, 웹사이트 작업은 되도록 브라우저 안에서 유지
   3. 실사용 예시: Jason은 오픈소스 프로그램 신청서가 Airtable로 들어오는데, CSV를 열고 다운로드 버튼 누르고 다른 드라이브로 옮기는 반복 작업을 자동화 — 이제는 그냥 알아서 작동함. 그 외엔 주로 앱 테스트 용도

---

7. 앱 빌딩 사례 연구 — 드럼 연습 앱

7.1. 문제 정의와 접근

1. 배경
   1. 계기: 드럼 세트를 주문하고 배송 대기 중 루디먼트(rudiments, 손동작 패턴)와 손발 협응(coordination)을 배워야 한다는 걸 알게 됨
   2. 학습법: 콜앤리스폰스(call and response) — 누군가 드럼 비트를 치면 그대로 따라 치는 방식이 가장 좋다고 판단
2. 앱 사양
   1. 1차 요청: "루디먼트 라이브러리가 있고 템포를 바꿀 수 있는 앱 만들어줘" — 이후 새 개념을 배울 때마다 앱에 추가
   2. 확장 기능: 유튜브 영상을 업로드하면 드럼 파트를 추출하고, 드럼과 함께 연주하거나 드럼을 다시 넣어 연습할 수 있는 커스텀 학습 앱으로 발전
3. 개발 기간과 태도
   1. 실제 소요: "스크래치부터"가 아니라 약 1주일간의 반복 작업으로 완성 — 몇 시간 goal을 돌린 데모 자체보다 "시간이 지나며 키워나갈 수 있다는 것"이 핵심이라고 강조

7.2. Goal / Plan / Worklog 체계 — "Ultra Goal" 스킬

1. 선행 작업 — 긴 대화로 요구사항 도출
   1. 방법: 드럼을 배우고 싶다는 긴 대화를 Codex와 나누고, 루디먼트·손발 협응을 설명하는 유튜브 영상들을 참고자료로 넣음
   2. 탐색: 필요한 핵심 스킬이 뭔지 파악하기 위해 서브에이전트 약 300개를 활용
2. 세 가지 산출물
   1. goal.md (성공 기준): "유튜브 URL을 붙여넣으면 드럼 파트를 추출할 수 있어야 한다"처럼 달성 여부가 명확한 성공 기준. 이걸 만족할 때까지 계속 작업이 이어진다
   2. plan.md (구현 상세): React로 작성, 탭 2개 구성, 특정 기술스택 사용, 모르는 기술은 문서를 읽고 진행하라는 식의 실행 지침
   3. worklog (작업 로그): compaction 때문에 모든 메시지를 다 읽을 수 없는 상황에서, "권한 문제에서 막혀 있다"는 식으로 진행 상황과 도구의 한계를 파악하는 용도
3. Goal 작성의 원칙
   1. 직접 쓰지 않기: 좋은 goal을 만들려면 goal을 직접 쓰지 말고, 원하는 성공 기준을 설명한 뒤 "이걸 달성하기 위한 goal을 스스로 세워라"라고 지시하는 게 훨씬 낫다
   2. 범위 확장의 유연성: goal을 md 파일로 관리하면 범위가 넓어질 때 파일만 수정해도 되고 작업 자체를 중단할 필요가 없다
   3. 검증 포함 필수: goal은 단순히 "멋진 드럼 앱을 만들어줘"가 아니라 "컴퓨터 사용으로 앱을 열어서 이 유튜브 영상을 업로드하고 데이터를 뽑아낼 수 있어야 한다"는 식으로 반드시 검증 절차가 포함되어야 한다
4. 디자인/프론트엔드 관련
   1. 이미지 생성 목업 불필요: GPT-5.5 시절엔 필요했지만 GPT-5.6부터는 프론트엔드 품질이 충분히 좋아져서 굳이 이미지 생성으로 목업을 만들 필요가 없다
   2. 대신 도구 지정: Tailwind, Shadcn 같은 도구만 지정해주면 충분하다
5. 데모 내용
   1. 4지(four-limb) 그리드: 왼손/왼발/오른발/오른손을 각각 표시하고 카운트인을 해주는 화면
   2. 폴리리듬 연습: 한 손으로 5박, 다른 손으로 2박을 치는 폴리리듬 학습 기능까지 확장
   3. 전통적 학습법과의 차이: 원래는 유튜브 영상을 보거나 강좌를 듣지만, 이번엔 자기 자신을 가르치는 인터랙티브 앱을 직접 만든 것

---

8. 비개발자를 위한 조언과 철학

8.1. "이제 코딩은 해결됐다면 무엇을 배워야 하나?"

1. 대학생들이 자주 묻는 질문
   1. Jason의 답변 비유: "입맛(taste)을 가지려면 직접 먹어봐야 한다" — 이제 중요한 스킬은 원하는 것과 언어를 만들어내는 능력
   2. 핵심 태도: 도구를 미리 다 알아두는 것도 좋지만, 결과물의 품질에 불만족할 줄 알고 무엇이 문제인지 표현할 어휘를 배우는 게 훨씬 값지다
2. 막연한 지시의 한계
   1. 실패 패턴: "더 좋게 만들어줘"를 20번 반복해도 좋은 결과가 나올지 알 수 없다
   2. 구체적 피드백의 예시: 키보드 단축키를 어떻게 더 잘 만들지, 색깔로 구분을 더 잘 할 수 있는지, 원 대신 왼손/오른손 표시로 바꿀 수 있는지 등 구체적으로 원하는 개선점을 짚어야 한다
3. 핵심 결론
   1. 남은 유일한 일: 무엇이 마음에 안 드는지 이해하고 그것을 말로 표현해서 AI에게 전달하는 것 — 이것이 지금 시대에 남은 유일한 스킬이라는 것이 Jason의 결론

8.2. "우리는 모두 매니저가 된 걸까?" — 철학적 마무리 대화

1. Peter의 문제 제기
   1. 공감되는 불안: 다들 AI에게 피드백만 주는 매니저가 된 것 같고, 가끔 직접 코드를 만지거나 트윗을 손보는 손맛(craft)이 그립다고 고백
2. Jason의 반박
   1. 자기 인식: 스스로를 매니저라고 생각하지 않고, 열심히 일하는 것 자체로 보상받는다고 여기지도 않는다 (OpenAI에서는 다들 열심히 일한다)
   2. 차별화 포인트: 결과물이 얼마나 좋은지 신경 쓰고, 그것이 만들어낼 결과(outcome)에 신경 쓰는 사람이 돋보인다
   3. 자신의 기준: 드럼 앱이 좋은 앱인 이유는 (1) 실제로 드럼 실력이 늘었기 때문에 (2) 공유 가능해서 다른 사람도 배울 수 있기 때문에 (3) 작은 커뮤니티가 만들어질 수 있기 때문 — 코드가 어떻게 생겼는지는 이 결과물들에 비하면 부차적이다

8.3. OpenAI 팀 문화

1. top-down 문화
   1. 핵심 인물: Tibo가 커뮤니티와 진심으로 소통하는 태도가 팀 전체로 스며든다고 Jason은 설명
2. 투명성의 가치
   1. Peter의 코멘트: 너무 코퍼레이트하게 보도자료만 내는 방식은 커리어 내내 봐왔지만 잘 안 통했다 — 사람들은 결국 사람 얼굴과 대화하고 싶어한다

---

9. 마무리 — 다음 방향

1. 연락처: Jason은 트위터 @JXNLCO, 더 큰 업데이트는 OpenAI devs 계정에서 확인 가능
2. 로드맵 힌트
   1. 데스크톱 → 클라우드로 이동: 지금까지 Codex는 데스크톱 중심이었지만 점점 ChatGPT Work의 클라우드 경험으로 자동화들을 옮기는 중
   2. 핵심 비전: "노트북을 닫는다고 일이 멈추면 안 된다" — 이 조건이 충족될수록 더 기대된다고 강조
   3. 라이브 콜링 기능: Codex에게 직접 전화를 걸어 음성으로 지시하는 기능도 예고됨 (음성/받아쓰기 활용이 앞으로 더 발전할 영역)

---

주요 발언 모음

"The only job left is to like understand what you don't like about something and put it into words and like tell the AI." (남은 유일한 일은 뭐가 마음에 안 드는지 이해하고 그걸 말로 표현해서 AI에게 전달하는 것이다.)

"I actually do a lot of my work in work now because I don't have to review... I don't really review most of the code I write." (요즘은 Work에서 일을 많이 하는데, 내가 쓴 코드 대부분을 리뷰하지 않기 때문이다.)

"If you are trying to build good goals, don't write the goals yourself... tell Codex what you want, describe what the success criteria is and then just say, great, now set your own goal." (좋은 goal을 만들고 싶다면 직접 쓰지 마라 — 원하는 것과 성공 기준을 설명하고 Codex 스스로 goal을 세우게 하라.)

"My expectation is never that AI will solve my problem at the first step, because I don't expect humans to know what I want unless I really knew what I want." (AI가 첫 시도에 문제를 완벽히 풀어줄 거라 기대하지 않는다 — 나 자신도 내가 원하는 걸 정확히 모르는데 사람에게도 그걸 기대하지 않으니까.)

"The work shouldn't have to stop because you close your laptop. Once that's the case, I'm even more excited for what's possible." (노트북을 닫는다고 일이 멈춰선 안 된다. 그게 실현되면 더 기대된다.)

핵심 데이터 & 수치

• 자동화 실행 주기: Chief of Staff 자동화는 하루 3회(9시/13시/17시) 이메일·Slack·Linear를 점검
• 서브에이전트 활용 규모: 드럼 앱의 핵심 스킬 도출 과정에서 서브에이전트 약 300개를 활용
• 세션 데이터 규모: 스킬 정리를 위해 과거 세션 약 400개를 분석 대상으로 삼음
• 개발 기간: 드럼 학습 앱은 "스크래치"가 아니라 약 1주일간의 반복 작업으로 완성
• 모델 버전 변화: GPT-5.5 → GPT-5.6로 오면서 프론트엔드 품질이 좋아져 이미지 생성 목업이 불필요해짐

결론 및 시사점

1. 업무 자동화는 "Chief of Staff" 패턴으로 시작하라: 이메일/Slack/Linear를 정해진 시간에 체크하는 heartbeat 스레드부터 만들고, 시간이 지나며 세부 규칙(링크 포함, Linear 사용, 사전 초안 작성)을 하나씩 추가해가는 방식이 현실적이다.
2. 모든 걸 자동화하지 말고 신뢰 수준에 따라 구분하라: 조건이 명확한 경우(PR 테스트 통과 후 DM)는 완전 자동화하되, 대량의 메시지를 다루는 하트비트 스레드는 사람이 검토하는 여지를 남겨두는 게 안전하다.
3. 스킬은 "채용한 직원"처럼 계속 피드백을 주고 다듬어야 한다: 처음부터 완벽한 스킬을 기대하지 말고, 정기적으로(혹은 자가 개선 스킬을 만들어) 과거 세션의 피드백 패턴을 되짚어 개선하라.
4. Goal/Plan/Worklog을 분리하라: Goal(성공 기준·검증 포함) → Plan(구현 상세) → Worklog(진행 로그)로 나누면 장시간(몇 시간) 자율 작업을 안전하게 맡길 수 있고, 범위가 바뀌어도 파일만 수정하면 된다.
5. Goal은 직접 쓰지 말고 Codex에게 세우게 하라: 성공 기준만 설명하고 goal 자체는 모델이 스스로 정의하게 하는 편이 결과가 더 좋다.
6. 컴퓨터 사용/브라우저 자동화는 "로그인 상태 유지"와 "멀티탭"이 핵심 지렛대: 리서치·비교 작업에서 탭을 여러 개 열어 결과를 병렬로 보여주게 하면 사람이 최종 판단만 내리면 된다.
7. 이제 진짜 스킬은 "취향(taste)과 표현력"이다: 도구를 몰라도 괜찮다. 결과물에 불만족할 줄 알고 그 불만족을 구체적인 언어로 표현하는 능력이 AI 시대에 남은 핵심 역량이다.
8. 본인의 성과 기준을 코드가 아니라 결과(outcome)에 두라: 코드가 얼마나 우아한지보다, 실제로 문제가 해결됐는지·다른 사람에게도 도움이 되는지가 진짜 평가 기준이어야 한다.