에이전트가 코드를 짜는 팀에서, 엔지니어는 무엇을 해야하는가

지난 2월, OpenAI 엔지니어링 블로그에 글 하나가 올라왔습니다.

제목은 "Harness Engineering: leveraging Codex in an agent-first world." 내용은 이것이었습니다.

3명으로 시작한 팀이 Codex 에이전트와 함께 5개월 동안 제품을 만들었습니다.

결과물은 약 100만 줄의 코드, 1,500개의 풀 리퀘스트. 그리고 이 과정에서 인간이 직접 작성한 코드는 한 줄도 없었습니다.

팀은 이것을 철학으로 삼았습니다. "인간은 코드를 쓰지 않는다."

 

그렇다면 엔지니어는 무엇을 했을까요.

처음에는 속도가 느렸습니다. 에이전트가 무능해서가 아니었습니다. 환경이 충분히 갖춰지지 않아서였습니다.

에이전트는 자신이 맥락 안에서 볼 수 있는 것만 다룰 수 있습니다. Slack 스레드에 있는 결정, Google Docs에 정리된 설계, 사람의 머릿속에 있는 판단 기준, 이것들은 에이전트에게 존재하지 않는 것과 같습니다.

 

그래서 엔지니어들은 코드를 쓰는 대신 다른 일을 했습니다.

에이전트가 참조할 수 있도록 지식을 레포지토리 안에 구조화했습니다. 아키텍처 규칙을 문서가 아니라 린터와 CI로 강제했습니다.

에이전트가 실행 중인 애플리케이션을 직접 볼 수 있도록 로그와 UI를 에이전트에게 연결했습니다.

 

무언가 실패했을 때, 해결책은 "더 잘 해봐"가 아니었습니다.

항상 "무엇이 부족한가, 그리고 어떻게 에이전트가 그것을 알 수 있게 할 것인가"였습니다.

이 일을 OpenAI는 '하네스 엔지니어링(Harness Engineering)'이라고 불렀습니다.

하네스는 말을 통제하는 마구(馬具) 전체를 뜻합니다. 말은 빠르고 강하지만 방향을 스스로 결정하지 않습니다.

하네스가 그 힘을 원하는 방향으로 이끕니다. 에이전트와 인간의 관계를 이보다 잘 표현한 단어를 저는 아직 찾지 못했습니다.

 

이 변화에서 저는 두 가지가 눈에 들어옵니다.

1. 희소 자원이 바뀌었습니다. 기존 소프트웨어 개발에서 병목은 개발자의 구현 속도였습니다.

에이전트가 들어오면 코드 생성 속도는 문제가 되지 않습니다. 새로운 병목은 사람의 시간과 판단입니다.

OpenAI 팀도 같은 경험을 했습니다. 코드 처리량이 늘어날수록 병목은 사람의 검토 용량이었습니다.

그래서 그들은 사람의 검토를 줄이기 위해 에이전트가 애플리케이션 UI와 로그를 스스로 볼 수 있게 만들었습니다.

2. 아키텍처 규율이 더 중요해졌습니다. 에이전트는 코드베이스에 있는 패턴을 좋은 패턴도, 나쁜 패턴도 그대로 반복하고 증폭합니다.

문서로 작성된 규칙은 에이전트가 따르지 않습니다. 린터와 CI로 기계적으로 강제된 규칙만 일관되게 작동합니다.

OpenAI 팀은 레이어드 도메인 아키텍처를 설계하고, 그 의존성 방향을 CI 수준에서 검증했습니다. 린터 자체도 Codex가 작성했습니다.

 

저는 이 흐름이 개발팀을 운영하는 관점에서도 중요한 질문을 던진다고 생각합니다.

우리 팀에서 에이전트가 참조할 수 있는 지식이 어디에 있는지 생각해볼 필요가 있습니다. 설계 결정이 문서화되어 있는지, 아키텍처 규칙이 권고가 아니라 실제로 강제되고 있는지를요.

에이전트를 잘 쓰는 팀과 그렇지 못한 팀의 차이는 모델 선택이 아닙니다.

에이전트가 일할 수 있는 환경을 얼마나 잘 만들었는가입니다.

하네스 없이 말에 올라탄다고 더 빨리 가지 않습니다. 방향을 잃을 뿐입니다.

 

더 자세한 내용은 OpenAI가 공개한 아래 글에서 확인할 수 있습니다.

https://openai.com/index/harness-engineering/