이번 주에 무언가 변화가 일어났습니다. AI 코딩 도구들은 더 이상 더 똑똑한 자동 완성(autocomplete) 기능으로 홍보되지 않습니다. 대신 작업이 실제로 일어나는 장소로 홍보되고 있습니다. Google은 I/O 2026을 통해 에이전트 중심의 개발자 미래와 확장된 Antigravity 플랫폼에 대해 이야기했습니다. OpenAI와 Dell은 Codex를 하이브리드 및 온프레미스(on-prem) 기업 환경으로 가져오기 위한 협업을 발표했습니다. 또한 Codex가 모바일의 ChatGPT를 통해 사용 가능해질 것이라는 보고도 나왔습니다. 기업마다 방식과 패키징은 다르지만 방향은 같습니다. 코딩 어시스턴트가 사이드바(sidebar)를 벗어나 워크플로(workflow)의 중심으로 이동하고 있습니다.

개발자들이 왜 유혹을 느끼는지 이해합니다. 훌륭한 에이전트는 버그를 추적하고, 지루한 테스트 스캐폴딩(test scaffolding)을 작성하며, 로그를 검사하고, 풀 리퀘스트(pull request)를 생성하며, 당신이 이메일에 답장하는 동안에도 작업을 계속할 수 있습니다. 처음 작동할 때는 마법처럼 느껴집니다. 하지만 거의 작동할 뻔했을 때는 위험하게 느껴지기도 합니다.

IDE는 위임 계층(delegation layer)으로 변하고 있습니다. 수년 동안 IDE는 코드를 타이핑하는 곳이었습니다. 그 후 문서를 검색하고, 테스트를 실행하며, 차이점(diffs)을 검토하고, 컨테이너를 관리하며, Copilot이나 ChatGPT와 대화하는 곳이 되었습니다. 이제 다음 단계는 위임입니다. 작업을 설명하고, 저장소(repo)를 넘겨주면 에이전트가 계획을 세우게 하는 것입니다. 이는 개발자의 업무를 미묘한 방식으로 변화시킵니다. 당신은 여전히 코드에 대한 책임을 지지만, 첫 번째 초안을 작성한 사람이 당신이 아닐 수도 있습니다. 당신은 리뷰어, 디버거, 아키텍트, 그리고 상황을 통제하는 책임자(adult in the room)가 됩니다. 이는 훌륭한 거래가 될 수 있습니다. 저는 에이전트가 프로젝트 전체의 필드 이름을 변경하거나, 간단한 통합 테스트(integration test)를 추가하거나, 이미 이해하고 있는 마이그레이션(migration) 초안을 작성하도록 기꺼이 허용할 것입니다. 하지만 제 프롬프트(prompt)가 모호하고 제가 피곤하다는 이유로, 에이전트가 제 인증(auth) 시스템의 구조를 조용히 결정해 버리는 것은 원치 않습니다.

기업의 도입이 이를 빠르게 정상화할 것입니다. OpenAI와 Dell의 발표가 중요한 이유는 지루하지만 중요한 문제를 지적하기 때문입니다. 많은 기업이 사적인 코드를 퍼블릭 클라우드(public cloud) 워크플로에 그냥 던져 넣고 법무팀의 승인을 기다릴 수는 없습니다. 하이브리드 및 온프레미스 설정은 AI 코딩 에이전트가 데모를 넘어 기업의 기본 설정(defaults)으로 이동하는 방식입니다.

그렇게 되면 사회적 압박(social pressure)의 성격이 변합니다. 오늘날 에이전트(agents)를 사용하는 것은 여전히 선택 사항처럼 느껴질 수 있습니다. 하지만 곧 에이전트는 기업의 툴체인(toolchain)에 내장되고, 대시보드(dashboards)로 측정되며, 스프린트 계획(sprint planning)에서 당연한 전제로 간주될 것입니다. 바로 이 지점에서 팀에게 필요한 것은 더 요란한 홍보(hype)가 아니라 더 나은 습관입니다. 질문은 에이전트가 코드를 작성할 수 있느냐가 아닙니다. 작성할 수 있습니다. 질문은 여러분의 팀이 코드가 잘못되었을 때 이를 식별할 수 있느냐입니다. 검토(review) 없는 속도는 그저 더 빠른 추측일 뿐입니다.

AI 에이전트는 그럴듯한 작업물을 만들어내는 데 탁월합니다. 이것은 가치인 동시에 함정입니다. 디프(diff)는 깔끔해 보일 수 있습니다. 테스트(tests)는 통과(green) 상태일 수 있습니다. 커밋 메시지(commit message)는 자신감 있게 들릴 수 있습니다. 하지만 아무도 확인하지 않은 단 하나의 가정 때문에 동작이 어긋날 수 있습니다. 워크플로(workflow)에 에이전트를 도입하고 싶다면, 먼저 지루한 부분들을 엄격하게 관리하십시오. 테스트를 코드와 가깝게 유지하십시오. 풀 리퀘스트(pull requests)를 더 작게 만드십시오. 실제 수락 기준(acceptance criteria)을 포함하는 이슈 설명(issue descriptions)을 작성하십시오. 중요한 결정 사항들을 기록(log)하십시오. 생성된 코드는 마치 부끄러움을 느끼지 못하고, 강요하지 않는 한 불확실성을 절대 인정하지 않는 주니어 개발자의 코드처럼 취급하십시오. 가혹하게 들릴 수도 있지만, 이는 동시에 자유를 줍니다. 도구를 두려워할 필요는 없습니다. 도구를 관리해야 할 뿐입니다.

이번 주에 제가 할 일: 만약 여러분의 팀이 코딩 에이전트를 실험 중이라면, 하나의 좁은 작업 범주(task class)를 정해 정직하게 측정해 보십시오. 예를 들어, 불안정한 테스트(flaky test) 분류, 의존성 업그레이드(dependency upgrades), 문서 수정, 또는 작은 UI 리팩토링(refactors) 등이 있습니다. 아키텍처(architecture)부터 시작하지 마십시오. 결제(payments)부터 시작하지 마십시오. 강력한 검토 게이트(review gates)를 이미 갖추고 있지 않다면 보안에 민감한 흐름(security-sensitive flows)부터 시작하지 마십시오. 또한 에이전트가 건드려서는 안 되는 영역을 결정하십시오. 그 경계가 중요합니다. 무엇이든 편집할 수 있는 도구는 결국 여러분이 편집하지 않기를 바랐던 무언가를 편집하게 될 것입니다.

다음 단계에서 승리하는 개발자는 생성된 모든 패치(patch)를 맹목적으로 수용하는 사람이 아닙니다. 명확하게 위임하고, 무자비하게 검토하며, 에이전트가 길을 잃었을 때도 여전히 시스템을 이해하고 있는 사람입니다. 이것이 제가 계속해서 강조하는 부분입니다. AI는 타이핑(typing)의 더 많은 부분을 대신할 수 있습니다.

AI는 제품에 대한 책임을 질 수 없습니다. 그 책임은 여전히 우리에게 있습니다. 소스 신호 확인 날짜 2026년 5월 20일: 지난 5일간의 Google News 검색 결과에 따르면, Google I/O 2026의 개발자 커버리지에서 Antigravity 및 에이전트형 AI (agentic AI), OpenAI와 Dell의 Codex 기업용 발표, 그리고 ChatGPT를 통한 모바일에서의 Codex 사용 가능성에 대한 보고가 나타났습니다. 원문 게시 위치: https://blog.jenuel.dev/blog/ai-agents-new-ide-hands-on-wheel