AI에게 일을 '맡긴다'는 것의 실제 의미
'AI를 활용한다'는 말이 흔해졌지만, 대부분은 여전히 AI를 '스마트한 검색창'으로 쓰고 있다. 질문을 던지고, 답을 복사하고, 다음 질문으로 넘어간다. dev.to의 Richard Lemon은 이 패턴을 정확히 짚어낸다—"당신은 AI에게 묻는 게 아니라 일을 줘야 한다(You do not ask AI. You give it a job)." 문제 정의, 기존 자산, 제약 조건, 아웃풋 형식, 그리고 그 결과를 내가 다음에 어떻게 쓸지까지 포함된 '티켓'을 쓰는 것이 진짜 위임이다. 질문하면 모델이 원하는 것을 추측하지만, 위임하면 모델은 더 큰 시스템 안에서 자신의 역할을 인식한다.
OpenAI가 공개한 하네스 엔지니어링 사례는 이 위임 개념을 팀 단위·조직 단위로 밀어붙인 실험이다. 수동으로 코드를 한 줄도 작성하지 않고 내부 베타 제품을 출시하는 것이 목표였다. Codex 에이전트가 리포지터리 스캐폴드(CI 구성, 패키지 매니저, 프레임워크)를 직접 설정하고, PR을 열고, 에이전트 리뷰어들의 검증을 통과할 때까지 반복한다. 엔지니어는 거의 모든 상호작용을 프롬프트로만 처리한다. 핵심은 '에이전트가 스스로 문제없이 작동하게끔 환경을 설계하는 것'이었다.
컨텍스트는 희소 자원이다: AGENTS.md를 백과사전으로 쓰면 망한다
하네스 팀이 초기에 시도한 방식은 하나의 거대한 AGENTS.md에 모든 지침을 집어넣는 것이었다. 결과는 예측 가능하게 실패했다. 컨텍스트가 넘치면 에이전트는 주요 제약 조건을 놓치거나 잘못된 제약 조건에 맞춰 최적화를 시작한다. 모든 것이 '중요'하다고 선언되면 정작 아무것도 중요하지 않게 된다. 그리고 거대한 단일 파일은 빠르게 낡은 규칙들의 무덤이 된다—사람도 에이전트도 무엇이 여전히 사실인지 알 수 없게 된다.
팀이 택한 대안은 AGENTS.md를 '백과사전'이 아닌 '목차'로 재정의하는 것이다. 실제 깊이 있는 정보는 ARCHITECTURE.md, FRONTEND.md, SECURITY.md, product-specs/, design-docs/ 같은 전용 문서에 분산 배치하고, AGENTS.md는 "이 주제가 궁금하면 이 문서를 봐라"는 안내판 역할만 한다. 계획(plan)도 코드나 문서처럼 정식 산출물로 관리된다. 그리고 이 지식 베이스의 유지보수를 '사람의 성실함'에 기대지 않고 기계적으로 강제한다. 에이전트의 관점에서 실행 중 컨텍스트 내에서 접근할 수 없는 것은 사실상 존재하지 않는 것이기 때문이다.
불변 조건은 문서가 아닌 린트로 강제한다
문서를 아무리 잘 정리해도 에이전트가 만든 코드베이스가 저절로 일관성을 유지하지는 않는다. Codex는 리포지터리 안에 이미 존재하는 패턴을 그대로 따라 하는 경향이 있는데, 그 패턴이 고르지 못하거나 최적이 아니어도 그대로 복제한다. 나쁜 패턴이 누적되기 시작하는 것이다.
하네스 팀의 해법은 세세한 구현까지 간섭하는 대신 '절대 어겨선 안 되는 불변 조건만 강제로 지키게 만드는 것'이었다. 각 비즈니스 영역은 타입→설정→저장소→서비스→실행→UI 순서로만 데이터가 흐르도록 강제했고, 인증·로깅 같은 횡단 관심사는 반드시 단일 통로(Providers)를 거치게 했다. 로깅 형식, 네이밍 규칙, 파일 크기 제한은 맞춤형 린트로 잡되, 오류 메시지에 '어떻게 고쳐야 하는지'까지 담아 에이전트가 스스로 수정할 수 있게 했다. 그리고 Codex의 백그라운드 작업이 주기적으로 돌면서 규칙을 벗어난 부분을 찾아내고, 품질 점수를 갱신하며, 필요하면 리팩터링 PR을 스스로 열었다. 기술 부채를 매일 조금씩 갚아나가는 구조다.
에이전트가 '눈'을 갖게 하면 피드백 루프가 닫힌다
하네스 팀이 구축한 또 하나의 핵심 장치는 에이전트가 시스템을 직접 들여다보고 검증할 수 있는 환경이다. git worktree별로 앱 인스턴스를 독립 실행할 수 있게 해서 Codex가 변경사항마다 하나의 환경을 제어할 수 있도록 했다. Chrome DevTools Protocol을 에이전트 런타임에 연결해 DOM 스냅샷, 스크린샷, 탐색 스킬을 추가했다. 이로써 Codex는 버그를 재현하고, 수정사항을 검증하고, UI 동작에 대해 직접 추론할 수 있게 됐다. 시스템을 에이전트가 직접 관찰하고 수정할 수 있는 형태로 만들수록 에이전트의 효율은 크게 오른다는 것이 이 실험의 핵심 발견이다.
병합 철학도 바뀐다: '꼼꼼히 막기'에서 '빠르게 흘려보내기'로
에이전트가 코드를 생산하는 속도를 사람이 검증하는 속도로 따라갈 수 없다. 하네스 팀은 '병합 전에 꼼꼼히 막아서 확인하는' 전통적인 개발 규범이 발목을 잡기 시작했다는 걸 인식하고, PR을 빠르게 처리하고 테스트가 간헐적으로 실패해도 다음 실행에서 다시 확인하는 방식으로 병합 철학 자체를 전환했다. '일단 빠르게 진행하고 문제가 생기면 그때 고친다'—이 방향이 항상 옳은 것은 아니며 유기적으로 변화해야 하지만, 에이전트 주도 개발에서는 검증 루프의 위치와 밀도를 재설계하는 것이 불가피하다.
되찾은 시간을 처리량으로 채우면 에이전트 도입은 실패한다
에이전트가 시간을 돌려줬을 때, 조직이 그 시간으로 무엇을 했는지가 더 큰 문제다. dev.to에서 엔지니어링 리더 Phani Saripalli는 이 함정을 솔직하게 고백한다. AI 도입 후 스프린트에 여섯 장의 티켓이 들어가던 자리에 여덟 장이 들어가기 시작했다. 3일 만에 데모가 나오자 3일 주기가 새로운 기준이 됐다. 속도가 바닥이 됐고, 팀원들은 조용해졌다. 효율과 처리량을 동의어로 쓰는 순간 찾아오는 결과다.
그가 제안하는 재투자 방향은 네 가지다. 첫째, 생각할 시간—AI는 코드를 빠르게 쓰지만 무엇을 만들어야 하는지는 말해주지 않으며, 잘못된 것을 자신 있게 만드는 데 기꺼이 협조한다. 둘째, 깊이—에이전트 덕분에 이해하지 못한 코드베이스에 빠르게 배포할 수 있지만, 그것은 새벽 2시 장애가 날 때까지만 통한다. 셋째, 성장 설계—주니어가 배우던 지루한 작업을 AI가 흡수해버리면 성장의 사다리도 함께 사라진다. 성장은 이제 일의 부산물로 자동으로 따라오지 않는다. 설계해야 한다. 넷째, 회복—속도를 영구적인 기본값으로 만드는 것은 번아웃 스케줄에 좋은 브랜딩을 붙인 것과 다르지 않다.
프론트엔드 개발자에게 남는 시사점
이 세 가지 사례를 종합하면 패턴이 보인다. 에이전트에게 일을 맡기는 것은 프롬프트 하나를 잘 쓰는 기술이 아니다. 그것은 구조 설계의 문제다. 컨텍스트를 어떻게 분산하고 노출할지, 불변 조건을 어떻게 코드로 강제할지, 피드백 루프를 어떻게 닫을지—이 세 층위가 맞물려야 에이전트가 안정적으로 작동한다. 그리고 에이전트가 확보해준 시간은 더 많은 티켓이 아니라 더 깊은 이해, 더 나은 설계, 더 건강한 팀에 써야 복리 효과가 생긴다.
프론트엔드 개발자 입장에서 지금 당장 할 수 있는 것은 명확하다. AGENTS.md를 목차로 만들고, 디자인 시스템과 컴포넌트 컨벤션을 린트 규칙으로 박아 넣고, Chrome DevTools Protocol처럼 에이전트가 UI를 직접 볼 수 있는 피드백 채널을 열어두는 것. 그리고 에이전트가 무언가를 잘못 해내면 그것을 탓하기 전에 '도구나 가이드, 문서 중에 뭐가 빠졌길래 이런 일이 생겼나'를 먼저 묻는 습관을 팀 문화로 만드는 것이다. 많은 투자 없이는 원하는 아웃풋이 나오지 않는다—이것이 하네스 엔지니어링이 남긴 가장 솔직한 결론이다.