오픈AI, 인간의 주의가 병목이라며 에이전트가 스스로 관리하는 시스템 구축

OpenAI가 발표한 Symphony 스펙은 AI 코딩 에이전트의 운영 패러다임을 근본적으로 뒤집는 시도다. 기존에는 개발자가 Codex나 Claude Code 같은 여러 에이전트 세션을 동시에 띄워놓고 각각의 진행 상황을 감시·조율해야 했지만, Symphony는 에이전트가 Linear 같은 이슈 트래커에서 직접 티켓을 가져와 작업을 끝낼 때까지 자율적으로 실행하도록 설계되었다. 기술적으로는 에이전트가 이슈 트래커 API와 직접 연동되어 우선순위가 매겨진 작업 큐에서 티켓을 풀(pull)하고, 컨텍스트(요구사항·관련 코드·과거 PR 등)를 스스로 수집한 뒤 코드 작성, 테스트 실행, PR 생성까지 한 사이클을 완결하는 구조로 추정된다. OpenAI가 "human attention is the bottleneck"이라고 선언한 것은, 이제 모델 성능보다는 **사람이 동시에 감독할 수 있는 에이전트 수의 한계**가 생산성 천장을 결정한다는 진단에서 출발한다.

실무 관점에서 이 변화는 개발자의 역할을 "코드를 짜는 사람"에서 "이슈 트래커를 잘 관리하는 사람"으로 이동시킨다. 즉 티켓의 명세 품질, 수용 기준(acceptance criteria), 의존성 정의가 곧 에이전트 결과물의 품질과 직결되는 시대가 된다. 한국 SI/SaaS 환경처럼 Jira·Linear·GitHub Issue 사용이 일반화된 팀에서는, 그동안 "대충 적어두고 회의에서 채우던" 티켓 작성 관행이 더 이상 통하지 않게 된다. 또한 PR 리뷰의 부담은 폭증할 가능성이 높다. 에이전트 N개가 병렬로 PR을 던지는 환경에서는 사람이 모든 코드를 줄 단위로 검토하기 어렵고, 자연히 **자동화된 리뷰·테스트·정적 분석·정책 게이트**의 중요성이 폭발적으로 커진다.

개발자가 지금 당장 점검해야 할 항목은 명확하다. 첫째, 자사의 이슈 트래커가 에이전트가 읽기 좋은 구조(명확한 요구사항·테스트 케이스·완료 정의)로 운영되고 있는지를 점검해야 한다. 둘째, CI 파이프라인에 자동화된 보안 검사(SAST·시크릿 탐지·의존성 취약점 스캔)와 정책 기반 머지 가드를 강화해 자율 에이전트가 만든 PR이 무비판적으로 반영되지 않도록 막아야 한다. 셋째, 에이전트가 운영 환경에 직접 영향을 줄 수 있는 권한(프로덕션 DB 접근, 시크릿, 인프라 변경)에 대해서는 반드시 휴먼 인 더 루프(human-in-the-loop) 게이트를 유지해야 한다. 자율성이 높아질수록 사고 한 건의 폭발 반경(blast radius)이 커지기 때문이다.

마지막으로 커리어 관점에서 이 흐름은 "에이전트를 잘 부리는 시니어"와 "혼자 코드를 잘 짜는 주니어" 사이의 격차를 가속할 가능성이 크다. Symphony 같은 자율 에이전트 워크플로가 표준이 되면, 시스템 설계·도메인 모델링·코드 리뷰 안목·운영 리스크 판단처럼 **위임할 수 없는 역량**이 시장 가치의 핵심으로 남는다. 반대로 단순 티켓 처리·CRUD 구현 같은 영역은 에이전트로 흡수될 가능성이 높으므로, 한국 개발자들도 지금부터 자신의 일을 "에이전트에게 위임 가능한 부분"과 "사람만 할 수 있는 부분"으로 분류해보고, 후자에 시간을 더 투자하는 전환을 시작할 시점이다.