Codex open agent harness 공개: 사내 도구에 코딩 에이전트를 붙이는 방식이 달라진다

요약: OpenAI가 Codex를 단순한 CLI나 IDE 확장이 아니라 제품 안에 넣을 수 있는 open agent harness로 설명하기 시작했다. 검색 의도는 명확하다. 'Codex SDK를 어디에 써야 하나', '사내 운영 도구에 AI 에이전트를 어떻게 붙이나', 'MCP와 approval을 제품 안에서 어떻게 다루나'를 찾는 개발자에게 필요한 내용이다.

이번 변화의 핵심은 모델이 아니라 실행 루프다. 많은 팀이 AI 기능을 붙일 때 프롬프트와 모델 선택부터 본다. 하지만 실제 업무 자동화에서 자주 깨지는 지점은 모델 답변이 아니라 주변 시스템이다. 컨텍스트를 어디서 읽을지, 어떤 도구를 호출할지, 실패하면 어떻게 복구할지, 쓰기 작업 전에 누가 승인할지, 진행 상황을 어디에 보여줄지 같은 문제가 남는다. Codex open agent harness는 이 부분을 제품 구성 요소로 분리해 보겠다는 신호다.

무엇이 새로워졌나

OpenAI 개발자 블로그의 설명을 보면 Codex는 앱, CLI, IDE Extension 뒤에서 같은 harness를 사용한다. 이 harness는 대화 상태를 유지하고, 도구 사용을 스트리밍하고, sandbox와 approval policy를 적용하고, 여러 턴에 걸친 작업을 이어간다. 공개된 구성 요소는 Codex CLI, app-server, Codex SDK다.

개발자 입장에서 중요한 점은 '챗봇 하나 더 만들기'가 아니다. 기존 업무 화면에 agent loop를 꽂을 수 있다는 점이다. 예를 들어 보안 분석가는 alert queue와 affected service를 보면서 에이전트에게 원인 조사를 맡길 수 있다. 운영 담당자는 shipment dashboard에서 지연 배송을 선택하고, 에이전트가 recovery option을 비교한 뒤, 재예약 같은 쓰기 작업은 승인 후 실행하게 만들 수 있다.

여기서 UI는 장식이 아니다. 사용자가 어떤 record를 보고 있는지, 어떤 action이 위험한지, 어떤 시스템이 source of truth인지 알려주는 실행 컨텍스트다. 범용 채팅창으로 모든 것을 밀어 넣으면 오히려 정보가 사라진다. Codex harness 접근은 채팅을 제품으로 바꾸는 게 아니라 제품 안의 특정 workflow에 agent loop를 붙이는 쪽에 가깝다.

왜 실무팀에 중요한가

첫째, agent integration의 책임 경계가 더 선명해진다. 모델과 harness가 task execution, tool call, approval event, sandbox execution을 맡고, 애플리케이션은 업무 도메인, 화면 상태, record, 권한 정책을 맡는다. 이 구조를 잡지 않으면 AI 기능이 커질수록 프롬프트와 백엔드 라우터가 뒤섞인다.

둘째, MCP 서버를 제품 소유 도구로 다룰 수 있다. 애플리케이션이 MCP service를 노출하면 에이전트는 필요한 데이터와 action에 접근하되, 모든 권한을 일반 API key 하나에 몰아주지 않아도 된다. 운영 대시보드에서는 조회 tool과 변경 tool을 분리하고, 변경 tool에는 approval을 요구하는 식으로 설계할 수 있다.

셋째, 관찰 가능성이 중요해진다. 사용자가 'AI가 뭘 했는지 모르겠다'고 느끼면 내부 도구라도 채택이 느려진다. app-server 방식은 thread 생성, turn 시작, event 수신, approval request 처리를 제품 쪽에서 볼 수 있게 한다. 이 이벤트 로그는 디버깅뿐 아니라 감사, 비용 분석, 프롬프트 개선에도 쓰인다.

기존 방식과 비교

기존에는 세 가지 선택지가 많았다. 하나는 Slack bot이나 chat UI를 만들어 모든 업무를 자연어로 처리하는 방식이다. 빠르게 시작할 수 있지만 사용자가 보고 있던 화면과 모델 컨텍스트가 분리된다. 둘째는 각 업무마다 별도 스크립트를 작성하는 방식이다. 신뢰성은 높지만 예외 처리가 많아질수록 자동화 비용이 커진다. 셋째는 RPA처럼 화면을 조작하는 방식이다. 레거시 시스템에는 쓸 수 있지만 상태와 권한을 명시하기 어렵다.

Codex harness 방식은 이 셋의 중간에 있다. 자연어와 도구 호출을 쓰되, 제품 화면이 컨텍스트를 제공하고, approval과 sandbox를 harness에서 관리한다. 완전 자동화가 아니라 '검토 가능한 반자동 실행'에 가깝다. 그래서 고객지원, 보안, 운영, QA처럼 쓰기 작업의 책임이 큰 영역에 맞다.

도입 전에 정해야 할 것

가장 먼저 정할 것은 에이전트가 실제로 끝낼 수 있는 업무 단위다. '운영을 도와줘'는 너무 넓다. '지연 배송 한 건의 원인을 확인하고 대체 경로 3개를 비교한 뒤 승인 요청을 만든다'처럼 record 중심으로 자르는 편이 낫다.

다음은 tool boundary다. 조회, 분석, 초안 작성, 외부 변경을 같은 권한으로 묶으면 사고가 난다. 조회 tool은 넓게, 변경 tool은 좁게, destructive action은 approval 필수로 두는 구조가 안전하다. 특히 내부 DB write, 티켓 생성, 고객 발송, 결제, 배포는 모델 단독 실행을 기본값으로 두면 안 된다.

마지막은 실패 처리다. agent loop는 오래 걸리는 작업에서 값이 나온다. 오래 걸린다는 것은 중간 실패가 많다는 뜻이다. timeout, retry, partial result, human handoff, event log가 설계에 들어가야 한다. 이 부분 없이 데모만 붙이면 첫 주에는 멋있고 둘째 주에는 운영 부담이 된다.

작은 PoC 설계 예시

사내 버그 triage 도구에 붙인다고 가정하자. 화면에는 이슈 제목, 최근 배포, 에러 로그, 관련 PR, 담당 서비스가 있다. 사용자가 '원인 후보 정리' 버튼을 누르면 애플리케이션은 현재 이슈 ID와 관련 로그 링크를 Codex thread에 넣는다. 에이전트는 read-only MCP tool로 로그와 PR을 확인한다. 결과는 원인 후보, 재현 단계, 추가로 필요한 정보, 권장 담당자로 나뉜다. Jira comment 작성은 draft까지만 만들고, 실제 등록은 사용자가 승인한다.

이 정도 범위면 성공 여부를 측정할 수 있다. 평균 triage 시간, 사람이 다시 물어본 횟수, 잘못된 담당자 지정률, 승인 없이 시도한 write action 수를 보면 된다. 모델 성능보다 workflow 설계가 먼저 검증된다.

실행 체크리스트

• agent를 붙일 화면을 먼저 고른다. 채팅창부터 만들지 않는다.
• 업무 단위를 record 중심으로 자른다. 예: 주문 1건, 이슈 1건, alert 1건.
• 조회 tool과 변경 tool을 분리한다.
• 변경 tool에는 approval event를 필수로 둔다.
• MCP tool은 필요한 데이터와 action만 노출한다.
• thread, turn, tool call, approval, final result를 로그로 남긴다.
• PoC 지표는 시간 절감보다 재작업률과 승인 품질을 같이 본다.
• 성공하면 범용 챗봇이 아니라 다음 workflow로 확장한다.