AI-native workflow 설계법: Codex 스킬을 반복 업무 자동화로 옮길 때 필요한 기준

검색 의도: AI-native workflow 설계, Codex 스킬 업무 자동화, AI 에이전트 업무 프로세스, agent workflow 운영법

OpenAI가 공개한 Enterprise Signals 사례에서 눈에 띄는 숫자는 frontier firms, 즉 AI 사용 상위 10% 기업이 일반 기업보다 active user당 output token을 8.3배 더 많이 만든다는 점이다. 1월의 2.6배에서 격차가 커졌다고 한다. 하지만 토큰을 많이 쓰는 것이 목표는 아니다. 핵심은 AI를 질문 답변 도구가 아니라 반복 가능한 workflow로 바꾼 기업이 더 깊은 업무를 맡기기 시작했다는 점이다.

OpenAI가 든 사례는 세 가지다. Basis는 직원 온보딩을 Codex와 회사별 onboarding skill로 바꿔 첫날 설정 시간을 2시간에서 30분으로 줄였다. Clay는 account별 persistent workspace와 subagent를 두고 매일 deal context를 갱신한다. Exa Labs는 “Exa everywhere”라는 개발자 생태계 확장 목표를 위해 Codex가 통합 기회를 찾고, context를 모으고, PR을 만들고, 테스트를 실행하고, 주간 업데이트를 준비하게 했다.

이 글은 그 사례를 개발팀 운영 관점에서 풀어쓴다. AI-native workflow는 프롬프트를 잘 쓰는 일이 아니다. 반복 업무를 트리거, context, 도구, 권한, 평가, 사람 승인 지점으로 분해하는 일이다.

질문을 workflow로 바꾸는 기준

대부분의 팀은 AI 도구를 “필요할 때 물어보는 창”으로 시작한다. 이 단계에서는 생산성이 들쭉날쭉하다. 어떤 사람은 잘 쓰고, 어떤 사람은 거의 쓰지 않는다. 다음 단계로 가려면 반복 업무를 골라야 한다. 기준은 네 가지다. 자주 발생하는가, 성공 기준이 비교적 명확한가, 필요한 context가 모을 수 있는가, 실패했을 때 사람이 멈출 수 있는가.

온보딩은 좋은 예다. 매번 비슷한 계정 설정, 도구 설치, 회사 개념 설명, 자주 묻는 질문이 반복된다. deal context 정리도 반복성이 있다. 매일 CRM, 이메일, Slack, 회의록을 확인하고 우선순위를 뽑는다. 개발자 ecosystem monitoring도 반복된다. repo나 문서를 감시하고 통합 기회를 찾고 PR을 만든다. 이런 업무는 “한 번 물어보고 끝”이 아니라 agent job description으로 바꾸기 좋다.

스킬에는 무엇을 넣어야 하나

Codex skill이나 agent skill을 만들 때는 지시문만 넣으면 부족하다. 최소한 다섯 가지가 필요하다. 첫째, trigger다. 언제 이 workflow가 시작되는지 정한다. 둘째, source list다. 에이전트가 읽어야 할 문서, repo, 티켓, CRM, Slack 채널을 지정한다. 셋째, allowed actions다. 읽기만 가능한지, PR 생성까지 가능한지, 외부 메시지 초안만 작성하는지 정한다. 넷째, definition of done이다. 산출물이 무엇이면 완료인지 적는다. 다섯째, stop condition이다. 불확실하거나 위험한 경우 어디서 사람에게 넘길지 정한다.

예를 들어 “신규 개발자 온보딩 스킬”은 계정 생성 자체를 에이전트에게 맡기기보다, 체크리스트 안내, 환경 점검, 권한 요청 초안, 설치 검증, FAQ 답변까지 맡기는 편이 안전하다. “거래처 갱신 스킬”은 고객에게 자동으로 메시지를 보내기보다, 근거가 붙은 우선순위와 초안을 만들고 account owner가 승인하게 해야 한다.

Persistent context가 필요한 순간

Clay 사례의 핵심은 매일 새로 묻는 챗봇이 아니라 account별 persistent workspace다. enterprise sales처럼 context가 계속 변하는 업무는 매번 모든 자료를 다시 붙여 넣을 수 없다. 고객별 폴더, 최신 상태 요약, 근거 링크, 미해결 질문, 다음 액션을 남겨야 한다. 그래야 에이전트가 어제의 판단과 오늘의 변화를 비교할 수 있다.

개발팀도 마찬가지다. 큰 리팩터링, 장기 마이그레이션, 보안 개선 프로젝트는 하루짜리 프롬프트로 운영하기 어렵다. 프로젝트별 context 파일을 두고 decision log, blocker, test result, open question을 계속 갱신해야 한다. 그렇지 않으면 에이전트가 매번 새로 추론하고, 팀은 같은 설명을 반복한다. AI-native workflow는 장기 기억이 아니라 작업 상태 파일에서 시작한다.

도구 실행은 테스트와 함께 묶어야 한다

Exa Labs 사례에서 중요한 부분은 Codex가 단순히 기회를 찾는 데서 끝나지 않고 PR을 만들고 테스트를 실행한다는 점이다. 하지만 여기에도 조건이 있다. 사람이 어떤 기회가 중요한지 결정하고, 외부 관계나 공개 발표는 사람이 관리한다. 에이전트는 signal을 tested artifact로 옮기는 중간 구간을 맡는다.

개발 업무에 적용하면 기준은 명확하다. 에이전트가 코드를 수정할 수 있다면 반드시 테스트, lint, typecheck, screenshot, diff inspection 중 하나 이상의 검증을 붙여야 한다. 검증 없이 PR만 만들면 사람 리뷰어가 QA 엔진이 된다. 반대로 테스트 결과와 변경 근거가 붙은 PR은 리뷰 비용을 낮춘다. 에이전트 자동화의 품질은 “얼마나 많이 했나”가 아니라 “검증 가능한 산출물을 만들었나”로 봐야 한다.

측정 지표는 토큰이 아니라 업무 결과다

OpenAI의 8.3배 output token 격차는 흥미로운 신호지만, 내부 KPI로 쓰기에는 위험하다. 토큰을 많이 쓰게 만들면 긴 답변과 불필요한 반복이 늘 수 있다. workflow의 성과는 cycle time, 재작업률, 사람이 승인한 산출물 비율, 예외 발생률, 비용 대비 완료 작업 수로 봐야 한다.

온보딩이라면 첫날 설정 완료 시간, HR 반복 질문 감소, 신규 직원 self-serve 완료율을 본다. 계정 관리라면 놓친 follow-up 감소, deal next step 생성률, 사람이 채택한 추천 비율을 본다. 개발 ecosystem monitoring이라면 발견한 integration opportunity 수보다 merged PR 수, 테스트 통과율, maintainer 응답률이 더 중요하다.

실행 체크리스트

• 반복 업무 후보를 5개 적고 빈도, 성공 기준, context 접근성, 실패 비용으로 점수화한다.
• 하나의 workflow만 골라 trigger와 definition of done을 문서화한다.
• 에이전트가 읽을 source list와 접근 권한을 최소 범위로 정한다.
• allowed actions와 stop condition을 분리해서 쓴다.
• 프로젝트별 workspace에 state, evidence, open question을 남기게 한다.
• 코드 변경 workflow에는 테스트나 diff 검증을 필수로 붙인다.
• 토큰 사용량보다 cycle time, 채택률, 재작업률, 예외율을 본다.
• 성공한 workflow는 skill, Plugin, template 형태로 재사용 가능하게 만든다.

AI-native workflow 설계의 핵심은 더 똑똑한 모델을 찾는 것이 아니다. 안정적인 업무를 골라 context와 도구를 붙이고, 사람이 승인해야 할 경계를 정하고, 성공한 과정을 다음 팀이 재사용할 수 있게 포장하는 것이다. 프롬프트는 시작점일 뿐이고, 운영 가능한 workflow가 진짜 자산이다.