OpenAI가 공개한 AI 코딩 에이전트 작동 원리, 어디까지 밝혔나

AI 코딩 에이전트는 “그냥 코드 잘 짜는 챗봇”이 아니라, 사용자의 목표를 받아 도구(셸, 테스트, 검색 등)를 돌려가며 스스로 일을 끝내는 작은 자동화 시스템에 가깝습니다. 최근 OpenAI는 Codex CLI를 오픈소스로 공개해, 이런 에이전트가 실제로 어떤 방식으로 프롬프트를 만들고 도구를 호출하는지 꽤 구체적인 힌트를 제공했습니다. 흥미로운 점은, 웹에서 쓰는 ChatGPT 같은 인터페이스는 여전히 닫혀 있는데, 터미널에서 돌아가는 “에이전트형 클라이언트”는 코드로 들여다볼 수 있다는 사실입니다.¹

이 글에서는 OpenAI가 공개한 핵심인 “에이전트 루프(agent loop)”를 중심으로, 프롬프트가 어떻게 조립되고, 도구들이 어떻게 연결되며, 개발자가 무엇을 배울 수 있는지까지 쉽게 풀어보겠습니다.

왜 Codex CLI만 오픈소스일까: ‘껍데기’와 ‘엔진룸’의 차이

웹 채팅 UI는 기능도 많고 운영 인프라도 복잡해서, 공개 범위를 정하기가 어렵습니다. 반면 CLI는 상대적으로 단순합니다. 사용자의 로컬 환경에서 “어떻게 프롬프트를 만들고, 어떤 도구를 어떤 규칙으로 부르고, 결과를 어떻게 다시 모델에게 먹이는지” 같은 작동 원리를 보여주기에 딱 좋은 형태죠.

개발자 입장에서는 이게 꽤 큽니다. 보통 에이전트 제품은 “대충 이런 식으로 돌아가요” 수준의 설명만 제공되는데, Codex CLI는 실제 코드를 통해 내부 동작을 확인할 수 있으니 역공학이 아니라 정공법으로 학습이 가능합니다.¹

에이전트 루프란 무엇인가: “생각→실행→보고→재질문”의 반복

에이전트의 핵심은 한 번 답하고 끝나는 채팅이 아니라, 반복 사이클입니다. 흐름을 사람 일처럼 바꿔 말하면 이렇습니다.

먼저 사용자가 “이 기능 고쳐줘” 같은 요청을 던집니다. 그러면 에이전트는 바로 코드를 고치는 대신, 모델이 이해하기 좋게 프롬프트를 정리해서 보냅니다. 모델은 두 가지 중 하나로 답합니다. 하나는 “최종 답변(설명/코드 제안)”이고, 다른 하나는 “도구 좀 쓰게 해줘(툴 호출)”입니다.

툴 호출이 나오면 에이전트는 셸 명령을 실행하거나, 테스트를 돌리거나, 검색을 하거나, 계획 도구에 체크리스트를 업데이트합니다. 그리고 그 결과(로그, diff, 에러 메시지)를 다시 프롬프트에 붙여 모델에게 재질문합니다. 이 과정을 모델이 “이제 도구 호출 그만, 사용자에게 정리해서 알려줄게”라고 멈출 때까지 반복합니다.

이 반복 구조가 바로 ‘에이전트’가 단순 생성기를 넘어 “일을 끝내는 쪽”으로 진화하는 이유입니다. 말로만 코드를 짜는 게 아니라, 실제 실행 결과를 받아서 다시 수정하는 루틴이 들어가니까요.

프롬프트는 레고처럼 조립된다: 시스템/개발자/사용자 우선순위

흥미로운 지점은 “프롬프트를 어떻게 만들까?”입니다. Codex는 OpenAI의 Responses API에 처음 요청을 보낼 때, 프롬프트를 한 덩어리로 휙 던지지 않습니다. 시스템, 개발자, 사용자, 어시스턴트 같은 역할(role) 조각을 쌓아 올리듯 구성하고, 그 사이에 우선순위를 둡니다.

쉽게 말해, 시스템은 가장 위에 있는 헌법 같은 규칙이고, 개발자 지침은 그다음의 제품 사용 설명서, 사용자는 오늘의 요청서입니다. 이런 레이어 구조 덕분에 “항상 지켜야 할 규칙(보안, 톤, 금지사항)”과 “이번 작업에만 필요한 목표”를 섞지 않고 관리할 수 있습니다.

현업에서 에이전트를 만들다 보면, 사용자 요청이 길어질수록 원래 지켜야 할 규칙이 흐려지는 문제가 자주 생기는데, 역할 기반 조립은 이 혼선을 줄이는 전형적인 설계입니다.

도구(tool) 필드는 에이전트의 ‘손과 발’이다: 셸부터 MCP까지

에이전트는 모델 혼자서 세상을 바꾸지 못합니다. 파일을 읽고, 수정하고, 테스트를 돌리고, 웹에서 정보를 가져오는 건 결국 도구가 합니다. 그래서 프롬프트에는 “모델이 호출할 수 있는 기능 목록”이 함께 딸려가는데, 이게 tool 필드입니다.

여기엔 셸 명령 실행 같은 기본 도구뿐 아니라, 계획/태스크 관리용 도구, 웹 검색, 그리고 MCP(Model Context Protocol) 서버를 통한 커스텀 도구까지 들어갈 수 있습니다. 즉 회사마다 “우리 조직용 버튼”을 만들어 모델에게 쥐여줄 수 있는 구조입니다.

재밌는 포인트는, 에이전트가 강해질수록 모델 성능만큼이나 “도구 설계”가 중요해진다는 사실입니다. 어떤 버튼을 주느냐에 따라 에이전트의 행동 반경이 달라지고, 안전장치의 방식도 바뀌니까요.

입력(input) 필드에 숨어 있는 현실감: 권한, 작업 폴더, 환경 컨텍스트

또 하나 중요한 건 input 필드입니다. 여기에는 단순히 “사용자 메시지”만 들어가지 않습니다. 샌드박스 권한(얼마나 마음대로 실행 가능한지), 선택적 개발자 지침, 그리고 “지금 어디서 작업 중인지(현재 디렉토리 등)” 같은 환경 컨텍스트가 함께 들어갑니다.

이게 왜 중요하냐면, 에이전트는 실제로 로컬에서 실행되며 ‘상황’을 먹고 자라기 때문입니다. 같은 “테스트 돌려줘”라도, 어떤 폴더에 있는지, 어떤 권한으로 실행 가능한지에 따라 결과가 완전히 달라집니다. Codex CLI가 터미널이라는 표면(surface)을 선택한 이유도 여기에 있습니다. 터미널은 이미 작업 위치와 파일 접근이라는 맥락을 가지고 있으니까요.²

컨텍스트는 계속 불어난다: 세션 저장과 압축(컴팩트)의 의미

에이전트 루프의 부작용은 컨텍스트가 계속 커진다는 점입니다. 실행 로그, 테스트 결과, 파일 diff가 대화에 덕지덕지 붙으니까요. 그래서 실전 에이전트는 보통 “요약/압축” 메커니즘이 필요합니다.

Codex CLI 사용자 경험에서도 이런 흔적이 보입니다. 예를 들어 세션을 로컬에 저장해 이어서 작업(resume)하거나, 대화가 길어졌을 때 압축(/compact)으로 토큰을 정리하는 식의 기능이 등장합니다.² 결국 에이전트는 ‘기억을 어떻게 관리하느냐’가 비용과 속도를 결정하는 구조이고, 이건 앞으로 어떤 에이전트를 쓰든 피해갈 수 없는 과제입니다.

마지막으로, 장기적으로 유용한 팁 하나. 프로젝트에 AGENTS.md 같은 “에이전트 전용 안내서”를 두면, 매번 같은 규칙을 반복해서 말하지 않아도 됩니다. CLI 기반 흐름은 이런 파일들을 버전 관리하기 쉽다는 장점도 있습니다.²³

시사점: 개발자가 지금 당장 얻을 수 있는 실용적인 힌트

OpenAI가 이번에 던진 메시지는 단순히 “우린 에이전트를 만들어요”가 아니라, “에이전트는 이렇게 설계하면 됩니다”에 가깝습니다. 핵심은 반복 루프, 역할 기반 프롬프트 조립, 도구 목록의 명시, 그리고 환경/권한 컨텍스트의 포함입니다.

만약 팀에서 자체 코딩 에이전트를 만들거나, Codex/Claude 같은 도구를 더 잘 쓰고 싶다면 이렇게 접근해보면 좋습니다. 첫째, 사람이 반복하는 검증 루틴(테스트, 린트, 포맷)을 도구 호출로 ‘버튼화’하세요. 둘째, 프로젝트 규칙은 대화에 섞지 말고 파일(예: AGENTS.md)로 빼서 지속 지침으로 만들면 재사용성이 올라갑니다. 셋째, 권한과 샌드박스 범위를 명확히 두세요. 에이전트는 똑똑할수록 “할 수 있는 일”이 늘고, 그만큼 “하면 안 되는 일”도 정해줘야 안전합니다.

에이전트는 결국 ‘모델’만의 게임이 아니라, 모델이 일할 수 있게 만드는 “루프 + 도구 + 컨텍스트”의 종합예술입니다. Codex CLI 오픈소스 공개는 그 엔진룸을 직접 볼 수 있는 드문 기회고, 앞으로 에이전트 시대에 경쟁력이 되는 지식은 이런 구조를 이해하는 데서 나온다고 봅니다.

참고

¹Unrolling the Codex agent loop | Hacker News

²First few days with Codex CLI | amanhimself.dev

³OpenAI’s Codex Redefines the AI-Native Engineering Workflow