Codex가 더 이상 개발자만을 위한 도구가 아니게 된 이유

OpenAI는 이번 달 재미있는 수치를 발표했습니다. 매주 500만 명 이상의 사람들이 Codex를 사용하고 있으며, 그중 100만 명 이상은 소프트웨어 개발 이외의 업무를 위해 이를 사용하고 있습니다.

두 번째 수치가 흥미로운 지점입니다.

변호사, 채용 담당자, 재무 분석가, 제품 담당자 또는 영업 팀이 갑자기 소프트웨어 엔지니어가 되고 싶어 하기 때문이 아닙니다. 대부분은 그렇지 않습니다. 그들 중 일부는 이미 평생 쓸 Jira 티켓을 충분히 겪어봤을 것입니다.

흥미로운 부분은 소프트웨어 형태의 자동화(software-shaped automation)가 엔지니어링 영역 밖으로 흘러나가고 있다는 점입니다.

Codex는 코딩 에이전트(coding agent)로 시작했습니다. 하지만 이제 OpenAI는 Codex가 컨텍스트(context)를 수집하고, 도구들을 활용하며, 파일을 편집하고, 스프레드시트를 준비하며, 작은 앱을 구축하고, 문서를 업데이트하며, 워크플로우(workflow)를 점검하고, 몇 시간 동안 작업에 머무르는 업무 방식을 설명하고 있습니다. 이것은 단순히 "Python을 위한 자동 완성"이 아닙니다. 이것은 채팅 인터페이스를 입은 백그라운드 워커(background worker)입니다.

그리고 비개발자들이 소프트웨어 형태의 업무를 위임할 수 있게 되면, 모든 기업은 동일하고 난처한 질문에 직면하게 됩니다:

모두가 기계에게 플랫폼을 만들어 달라고 요청할 수 있을 때, 그 플랫폼의 소유권은 누구에게 있는가?

automation intensifies

이것은 사실 코딩에 관한 것이 아닙니다

게으른 반응은 "좋아, 이제 누구나 코딩할 수 있겠군"이라고 말하는 것입니다.

저는 그것이 올바른 프레임(frame)이라고 생각하지 않습니다.

대부분의 비즈니스 팀은 코드를 쓰고 싶어서 잠에서 깨지 않습니다. 그들은 다섯 단계의 복사-붙여넣기 과정이 필요 없는 월간 보고서를 원합니다. 월요일 회의 전까지 정리된 리드(lead) 목록을 원합니다. 데이터 팀에 간청할 필요가 없는 대시보드를 원합니다. 지저분한 메모 폴더를 고객, 감사인, 관리자 또는 규제 기관이 실제로 읽을 수 있는 무언가로 바꾸길 원합니다.

코드는 종종 그저 성가신 중간 과정일 뿐입니다.

수년 동안 기업들은 스프레드시트, 매크로 (macros), 내부 도구, BI 대시보드 (BI dashboards), Zapier 워크플로우 (workflows), 섀도우 스크립트 (shadow scripts), 그리고 어떻게든 위험할 정도로 SQL을 어느 정도 알고 있는 재무팀의 그 한 사람을 통해 이 문제를 처리해 왔습니다. 모든 조직에는 이러한 계층이 존재합니다. 이것은 공식적인 소프트웨어 엔지니어링 (software engineering)은 아니지만, 명백히 소프트웨어입니다.

그것은 입력값 (inputs), 출력값 (outputs), 자격 증명 (credentials), 비즈니스 규칙 (business rules), 의존성 (dependencies), 그리고 장애 모드 (failure modes)를 가지고 있습니다.

지금의 차이점은 에이전트 (agents)가 이 계층을 더 쉽게 만들 수 있게 해준다는 것입니다.

이는 유용합니다. 또한, 아무도 모르는 사이에 작은 편의 기능이 운영 시스템 (operational system)으로 변모하는 방식이기도 합니다.

대화하는 법을 배운 섀도우 IT (shadow it learned to talk)

섀도우 IT (Shadow IT)는 과거에 17개의 탭과 final_final_really_final.xlsm이라는 이름의 매크로가 달린 스프레드시트처럼 보였습니다.

이제 그것은 Slack을 읽고, CRM을 확인하고, 예측치를 생성하고, 발표 자료 (deck)를 업데이트하며, 팀에 이메일을 보내는 반복적인 에이전트 작업 (agent task)처럼 보일 수 있습니다.

물론 발전입니다.

하지만 또한: 만약 아무도 그 에이전트가 어떤 데이터에 접근했는지, 어떤 가정을 했는지, 워크플로우 (workflow)의 어떤 버전이 실행되었는지, 혹은 왜 지난 목요일에 숫자가 바뀌었는지 모른다면, 감사 (audit) 중에 이를 설명하는 데 행운을 빌어야 할 것입니다.

이 지점이 바로 Codex 채택 신호가 중요한 이유입니다. 만약 백만 명 이상의 사람들이 소프트웨어 개발 이외의 분야에서 Codex를 사용하고 있다면, 이 카테고리는 "개발자 생산성 도구"에서 "범용 업무 실행 환경 (general work execution environment)"으로 넘어간 것입니다.

이는 기존의 개발 도구 관련 질문들만으로는 충분하지 않음을 의미합니다.

새로운 질문들은 플랫폼 (platform)에 관한 질문들입니다:

에이전트가 어떤 도구에 접근할 수 있는가?
어떤 파일이 입력값 (input)으로 허용되는가?
어떤 작업에 승인이 필요한가?
작업 이력 (task history)은 어디에 저장되는가?
출력값 (output)을 어떻게 검토하는가?
반복적인 워크플로우가 조용히 잘못된 일을 저질렀을 때, 누구에게 호출 (paged)이 가는가?

네, 영업 대시보드 (sales dashboard) 때문에 호출이 간다고 말했습니다.

죄송합니다. 운영 환경 (Production)은 항상 방법을 찾아내기 마련이니까요.

하네스 (the harness)가 곧 제품이다

OpenAI와 Microsoft는 모두 에이전트 (agents)와 관련하여 "하네스 (harness)"라는 단어를 사용해 왔으며, 저는 이 단어가 올바른 방향으로 지루하다는 점이 마음에 듭니다.

모델 (model)이 제품의 전부는 아닙니다.

제품은 이를 둘러싼 시스템입니다: 신원 (identity), 권한 (permissions), 도구 (tools), 상태 (state), 평가 (evaluation), 로그 (logs), 롤백 (rollback), 리뷰 (review), 그리고 비용 제어 (cost control)입니다. 모든 직원을 작은 플랫폼 팀 (platform team)으로 만들지 않고도 작업을 실행할 수 있게 해주는 것 말입니다.

개발자들에게 이것은 익숙한 일입니다. 우리는 이미 스크립트가 소유권 (ownership), 모니터링 (monitoring), 배포 (deployment), 비밀 정보 (secrets), 테스트 (tests), 그리고 사무실 전체를 마비시키지 않고 실패할 수 있는 방법까지 갖추기 전까지는 서비스 (service)가 아니라는 점을 배웠습니다.

비개발자용 에이전트 워크플로 (agent workflows) 역시, 설령 친숙한 채팅창에서 시작된다 하더라도 동일한 처우가 필요합니다.

만약 에이전트가 고객 분석을 준비한다면, 유용한 질문은 단지 "답변이 좋았는가?"만이 아닙니다.

다음과 같은 질문들이 필요합니다:

어떤 고객 기록을 읽었는가?
승인된 소스 (approved sources)를 사용했는가?
재현 가능한 결과물 (repeatable artifact)을 생성했는가?
누군가가 추론 과정 (reasoning trail)을 검사할 수 있는가?
워크플로를 일시 중지, 버전 관리 또는 삭제할 수 있는가?
입력 스프레드시트가 저주받았다는 이유로 확신에 찬 숫자를 지어내지는 않았는가?

마지막 질문은 이론적인 것이 아닙니다. 모든 스프레드시트는 열 헤더 (column headers)가 있는 범죄 현장입니다.

review time

비개발자에게 필요한 것은 훈계가 아니라 가드레일 (guardrails)입니다

엔지니어들은 때때로 이러한 도구들에 대해 지나치게 문지기 (gatekeeping) 역할을 하려 합니다.

"비즈니스 사용자는 워크플로를 구축해서는 안 됩니다."

제발요. 비즈니스 사용자들은 언제나 워크플로를 구축해 왔습니다. 단지 엔지니어들이 월말 결산이 실패할 때까지 못 본 척 정중하게 대해주었던 도구들을 사용했을 뿐입니다.

정답은 사람들에게 업무 자동화를 멈추라고 말하는 것이 아닙니다. 정답은 보이지 않는 운영 시스템 (production systems)을 만들지 않는 경로를 제공하는 것입니다.

그것은 승인된 커넥터 (approved connectors), 명확한 데이터 경계 (data boundaries), 일반적인 워크플로를 위한 템플릿 (templates), 리뷰 상태 (review states), 변경 이력 (change history), 소유권 메타데이터 (ownership metadata), 일회성 자동화에 대한 만료일 (expiration dates)을 의미합니다. 즉, 에이전트가 건드릴 수 있도록 허용된 것들에 대한 지루한 목록 말입니다.

또한 이는 플랫폼이 거친 개인적 도움 (personal help)과 공유된 운영 업무 (shared operational work)를 구분해야 함을 의미합니다.

회의 내용을 요약해 주는 에이전트는 매주 금요일마다 신뢰할 수 있는 예측치 (source-of-truth forecast)를 업데이트하는 에이전트와는 다릅니다. 하나는 보조 (assistance)이고, 다른 하나는 비즈니스적 결과 (business consequences)를 수반하는 워크플로 (workflow)입니다.

이 둘은 동일한 제어 권한 (controls)을 가져서는 안 됩니다.

이 부분은 많은 기업이 고통을 겪으며 깨닫게 될 지점입니다. 첫 번째 파도는 열광입니다. 사람들은 유용한 것들을 빠르게 만들어낼 것입니다. 두 번째 파도는 혼란입니다. 아무도 '무언가를 업데이트하는 무언가'를 누가 만들었는지 기억하지 못할 것입니다. 세 번째 파도는 거버넌스 (governance)입니다. 왜냐하면 충분한 마법이 '핵심 프로세스 (critical process)'라는 이름으로 재명명된 후에 일어나는 일이 바로 거버넌스이기 때문입니다.

검토의 부담이 옆으로 이동한다

엔지니어가 에이전트를 사용할 때, 우리는 보통 코드 리뷰 (code review)에 대해 이야기합니다.

비개발자가 에이전트를 사용할 때, 검토 문제는 사라지지 않습니다. 그것은 옆으로 이동합니다.

재무팀은 숫자를 검토합니다. 법무팀은 문구와 리스크를 검토합니다. 채용팀은 후보자와의 커뮤니케이션을 검토합니다. 영업팀은 계정 계획 (account plans)을 검토합니다. 운영팀은 체크리스트를 검토합니다. 제품팀은 고객의 클레임을 검토합니다.

이 팀들은 에이전트가 JavaScript를 작성했는지, 스프레드시트 수식을 생성했는지, CRM에 쿼리를 날렸는지, 아니면 브라우저를 클릭하며 돌아다녔는지에는 관심이 없을 수도 있습니다. 그들은 출력값 (output)이 행동에 옮길 수 있을 만큼 충분히 사실인지에 관심을 가집니다.

그러기 위해서는 증거 (evidence)가 필요합니다.

신비로운 신뢰도 점수 (confidence score)가 아니라, 증거가 필요합니다.

출처를 보여주세요. 변경된 행 (rows)을 보여주세요. 가정을 보여주세요. 무시된 레코드 (records)를 보여주세요. 400명의 고객에게 이메일을 보내기 전의 승인 요청을 보여주세요. 지난주 이후 무엇이 바뀌었는지 보여주세요.

검토 증거 없이 다듬어진 결과물 (artifacts)만을 만들어내는 에이전트는 매우 지루한 방식으로 위험합니다. 그것들은 보안 사고처럼 보이지 않습니다. 그저 누구나 전달하게 될, 숫자 하나가 틀린 멋진 발표 자료 (deck)처럼 보일 뿐입니다.

그것이 더 나쁩니다. 왜냐하면 그 영향 범위 (blast radius)가 비즈니스 캐주얼을 입고 있기 때문입니다.

개발자는 여전히 중요하다, 짜증 나게도

이것이 재미있는 부분입니다.

Codex가 더 광범위해질수록, 엔지니어링 외부에서도 개발자적 본능 (developer instincts)이 더욱 중요해집니다.

모든 사람이 React나 Kubernetes를 배워야 하기 때문이 아닙니다. 영업팀에게 Kubernetes를 배우게 하지는 마세요. 그들은 이미 충분히 고생했습니다.

하지만 소프트웨어 엔지니어링 (software engineering)의 습관들은 유용해집니다:

입력(inputs)과 출력(outputs) 정의
초안(drafts)과 운영(production) 분리
중요한 작업 로그(log) 남기기
워크플로우(workflows) 버전 관리
알려진 사례(known cases)로 테스트
되돌릴 수 없는 변경 전 검토(review)
시스템 소유자(owners) 지정
아무도 소유하지 않는 것은 삭제

이것들은 "코딩 기술"이 아닙니다. 이것은 운영 위생 (operational hygiene)입니다.

개발자들이 이를 배운 이유는 컴퓨터가 잘못된 일을 대규모로 수행하는 데 매우 능숙하기 때문입니다. 이제 에이전트(agents)들이 그 재능을 모든 부서에 전파하고 있습니다.

축하합니다, 이제 모두가 아주 작은 분산 시스템 (distributed system)을 갖게 되었습니다.

내가 가장 먼저 구축할 것

만약 내가 회사 내부에서 이 일을 책임지게 된다면, 거창한 에이전트 전략 데크 (strategy deck)부터 시작하지 않을 것입니다. 나는 레지스트리 (registry)부터 시작할 것입니다.

공유 시스템에 영향을 미치는 에이전트 워크플로우 (agent workflows)를 기록하는 지루한 레지스트리 말입니다:

이름
소유자
목적
연결된 도구 (connected tools)
접촉하는 데이터
일정 또는 트리거 (trigger)
승인 규칙
마지막 실행
마지막 검토 날짜
롤백 (rollback) 또는 비활성화 경로

그런 다음 승인된 템플릿 세트를 소량 추가할 것입니다. 월간 보고서, 리드 (lead) 정리, 릴리스 준비 상태 요약, 계약 비교, 지원 트렌드 요약 등과 같은 것들 말이죠. 사람들이 이미 수동으로 하고 있으며 싫어하는 평범한 작업들입니다.

목표는 모든 사람의 속도를 늦추는 것이 아닙니다. 목표는 유용한 자동화가 구전 설화 (folklore)처럼 떠도는 것을 방지하는 것입니다.

왜냐하면 그것이 바로 진짜 위험이기 때문입니다. 비개발자들이 갑자기 나쁜 코드를 작성하게 되는 것이 위험이 아닙니다. 나쁜 코드는 견딜 수 있습니다. 우리에게는 그것을 처리하는 산업이 이미 존재합니다.

진짜 위험은 팀들이 아무도 찾을 수 없고, 검사할 수 없으며, 버전 관리나 폐기가 불가능한 비즈니스 로직 (business logic)을 만들어내는 것입니다.

핵심 (the punchline)

Codex가 소프트웨어 개발 외부에서도 유용해진다는 것은 단순한 어시스턴트 기능의 추가보다 훨씬 더 큰 이야기입니다.

이는 에이전트 런타임 (agent runtime)이 엔지니어링 조직을 벗어나고 있음을 의미합니다.

그것은 좋은 현상입니다. 많은 지식 노동 (knowledge work)은 반복적이고 구조화되어 있으며, 더 나은 자동화 (automation)를 간절히 기다리고 있습니다. 사람들은 중세 시대의 스프레드시트 수도사들처럼 일주일의 절반을 도구 간에 데이터를 옮기는 데 소비해서는 안 됩니다.

하지만 에이전트 (agent) 작업이 공유 데이터, 반복적인 워크플로 (workflows), 고객 커뮤니케이션, 재무 수치 또는 운영 결정에 닿는 순간, 그것은 더 이상 개인적인 생산성 기술에 머물지 않습니다.

그것은 플랫폼 작업 (platform work)이 됩니다.

그러니 맞습니다, 개발자가 아닌 사람들에게도 강력한 에이전트를 부여하십시오. 그들이 지루한 업무를 자동화하게 하십시오. 엔지니어링 팀이 결코 우선순위에 두지 않을 작은 내부 도구들을 그들이 직접 만들게 하십시오. 그들이 더 빠르게 움직이게 하십시오.

다만, 채팅창이 책임 소재 (ownership)를 없애준다고 가장하지는 마십시오.

Codex의 미래는 단지 개발자들이 코드를 더 빨리 작성하는 것에만 있지 않습니다.

그것은 모든 사람이 소프트웨어 형태의 작업 (software-shaped work)을 위임하는 것입니다.

그리고 소프트웨어 형태의 작업에는 여전히 경계 (boundaries), 검토 (review), 로그 (logs), 권한 (permissions), 그리고 "왜 이것이 매주 금요일마다 실행되고 있는 거죠?"라고 말할 수 있는 누군가가 필요합니다.

마법은 즐겁습니다.

하지만 감사 로그 (audit log)야말로 성숙함이 시작되는 지점입니다.

the scheduler has entered the chat

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면 이 링크를 사용하세요.

Insights