AI는 이제 "채팅창"보다 "제품 안의 에이전트"로 들어가고 있다

AI의 다음 변화는 더 큰 모델이 아니라, 실제 제품 안에서 상태를 기억하고 도구를 쓰며 일을 끝내는 에이전트로 이동하는 흐름이다.

들어가며 — 왜 지금 이 주제인가

한동안 AI 이야기는 "어떤 모델이 더 똑똑한가"에 집중되어 있었습니다. 벤치마크 점수, 컨텍스트 길이, 멀티모달 성능 같은 것들이 주된 화제였습니다.

그런데 최근 흐름은 조금 달라졌습니다. 이제 관심은 "AI를 어디에 붙일 것인가"로 옮겨가고 있습니다. 더 정확히는, 제품 안에서 AI가 어떤 일을 맡고, 어떤 도구를 쓰며, 어디까지 자동으로 처리할 수 있는지가 중요해지고 있습니다.

Google은 I/O 2026에서 "agentic Gemini era"를 전면에 내세웠습니다. AI가 단순한 응답 도구를 넘어 더 많은 제품 경험 안으로 들어가는 방향을 보여준 셈입니다. Google I/O 2026 발표

IBM도 2025년 AI 트렌드에서 모델 성능 자체보다 추론 비용, 디지털 자원 부담, 프라이버시와 개인화의 긴장, AI 동료 같은 현실적인 이슈를 따로 짚었습니다. IBM AI trends

즉, 질문이 바뀌고 있습니다.

"AI가 얼마나 똑똑한가?"에서

"AI를 실제 업무 안에 넣었을 때, 비용과 책임을 감당할 수 있는가?"로요.

AI-first보다 중요한 것은 "AI가 제품 안에서 무엇을 하느냐"다

"AI-first"라는 말은 여전히 유효합니다. 하지만 그 표현만으로는 부족해졌습니다. 이제는 AI를 전면에 내세우는 것보다, 사용자가 이미 쓰고 있는 제품 안에서 AI가 어떤 역할을 맡는지가 더 중요합니다.

IBM은 AI 트렌드에서 몇 가지 현실적인 문제를 제시했습니다. 추론 비용, 디지털 자원 소모, 프라이버시와 개인화 사이의 균형, 그리고 AI coworkers, 즉 함께 일하는 AI라는 주제입니다. IBM AI trends

이 목록이 흥미로운 이유는 기술 자랑보다 운영 문제에 가깝기 때문입니다. AI를 한두 번 데모로 보여주는 것과, 매일 수천 번 호출되는 제품 기능으로 넣는 것은 완전히 다른 일입니다.

추론 비용이 낮아진다고 해도 공짜는 아닙니다. AI 기능이 많아질수록 서버, 데이터, 보안, 권한, 감사 로그 같은 문제도 따라옵니다. 개인화된 경험을 만들려면 사용자 맥락이 필요하지만, 그만큼 프라이버시 문제도 커집니다.

그래서 앞으로의 AI 제품 경쟁은 "모델을 붙였다"에서 끝나지 않을 가능성이 큽니다. 실제로는 이런 질문을 버텨야 합니다.

• 이 기능은 반복 사용해도 비용 구조가 맞는가?
• 사용자의 민감한 맥락을 어디까지 저장하는가?
• AI가 한 작업을 사람이 추적하고 되돌릴 수 있는가?
• 실패했을 때 책임은 누구에게 있는가?

AI가 제품 안으로 들어간다는 말은, 단순히 버튼 하나가 추가된다는 뜻이 아닙니다. 제품의 상태 관리, 권한 설계, 비용 계산, 보안 검토 방식이 함께 바뀐다는 뜻에 가깝습니다.

에이전트는 "대화"보다 "상태와 도구"가 중요해지고 있다

AI 에이전트 이야기를 할 때 흔히 챗봇을 떠올립니다. 하지만 최근 발표들을 보면 핵심은 대화창이 아닙니다. 상태를 유지하고, 백그라운드에서 실행되며, 여러 도구를 조합하는 구조입니다.

Google은 Gemini Interactions API의 정식 출시를 발표하며 모델과 에이전트를 위한 단일 엔드포인트, 서버 측 상태 관리, 백그라운드 실행, 도구 조합을 언급했습니다. Gemini Interactions API GA

이 방향은 꽤 중요합니다.

기존 챗봇은 사용자가 입력하면 답을 반환하는 구조에 가까웠습니다. 반면 에이전트는 일을 이어서 처리해야 합니다. 중간 상태를 기억해야 하고, 사용자가 창을 닫아도 작업이 계속될 수 있어야 하며, 필요하면 외부 도구도 호출해야 합니다.

개발자 입장에서는 이 차이가 큽니다. 단순 API 호출 하나로 끝나는 문제가 아니기 때문입니다.

예를 들어 에이전트가 문서를 읽고, 이슈를 만들고, 코드를 수정하고, 테스트를 실행한다고 해보겠습니다. 이때 필요한 것은 모델 응답만이 아닙니다.

• 작업 상태를 어디에 저장할 것인가
• 어떤 도구를 호출할 수 있게 할 것인가
• 실패한 작업을 어떻게 재시도할 것인가
• 사용자가 중간에 개입하면 어떻게 반영할 것인가
• 최종 결과를 어떻게 검토하게 할 것인가

결국 에이전트 개발은 "프롬프트를 잘 쓰는 법"만으로는 부족해지고 있습니다. 작은 워크플로우 엔진, 권한 시스템, 로그 시스템, 리뷰 체계가 함께 필요해지고 있습니다.

개발 워크플로우도 "여러 에이전트를 관리하는 문제"로 바뀐다

개발자 도구 쪽 변화는 더 직접적입니다.

GitHub는 Copilot app을 "agent-native desktop experience"로 소개하면서 여러 에이전트 작업, worktree 격리, Agent Merge, 리뷰와 CI 흐름을 다뤘습니다. GitHub Copilot app

여기서 중요한 것은 "AI가 코드를 짜준다"가 아닙니다. 그보다 더 현실적인 문제는 이것입니다.

여러 에이전트가 동시에 작업하면, 사람은 무엇을 해야 할까요?

한 에이전트는 버그를 고치고, 다른 에이전트는 테스트를 추가하고, 또 다른 에이전트는 리팩터링을 할 수 있습니다. 생산성만 보면 좋아 보입니다. 하지만 실제 팀에서는 곧바로 관리 문제가 생깁니다.

• 작업 단위는 어떻게 나눌 것인가
• 각 에이전트의 변경 사항은 어떻게 격리할 것인가
• 충돌이 생기면 누가 판단할 것인가
• 리뷰와 CI는 어느 시점에 붙일 것인가
• 사람이 이해하지 못한 코드를 병합해도 되는가

GitHub가 worktree 격리나 Agent Merge 같은 흐름을 이야기하는 이유도 여기에 있습니다. 에이전트가 많아질수록 개발자의 역할은 단순 작성자에서 지휘자와 리뷰어에 가까워집니다.

보안 업무도 비슷한 방향으로 움직이고 있습니다. GitHub는 코드 스캔 알림을 수정하는 agentic autofix public preview와 Copilot app 안의 /security-review public preview를 공개했습니다. agentic autofix, security reviews in Copilot app

다만 이 부분은 조심해서 봐야 합니다. 기능이 공개되었다는 사실과, 실제 조직의 코드베이스에서 탐지 품질과 수정 품질이 충분하다는 것은 다른 문제입니다. 실제 품질은 각 팀의 언어, 프레임워크, 보안 기준, 코드 구조에 따라 검증이 필요합니다.

바이브 코딩은 쉬운 개발이 아니라, 책임의 위치를 바꾸는 개발이다

최근 "바이브 코딩(vibe coding)"이라는 말도 자주 보입니다.

Merriam-Webster는 vibe coding을 AI에게 원하는 것을 말하고 결과물을 만들게 하는 최근 용어로 설명하며, 2026년 6월 4일 업데이트를 표시했습니다. Merriam-Webster: vibe coding

Ars Technica는 Karpathy의 2025년 X 발언을 인용하며, 바이브 코딩이 낮은 진입장벽을 만든다는 점과 실제 애플리케이션 신뢰성에 대한 의문을 함께 다뤘습니다. Ars Technica

바이브 코딩의 매력은 분명합니다. 아이디어를 말하면 결과물이 나옵니다. 코드를 한 줄씩 이해하지 못해도 프로토타입을 만들 수 있습니다. 개발 경험이 적은 사람에게는 진입장벽을 낮춰주는 도구가 될 수 있습니다.

하지만 여기에는 불편한 질문이 따라옵니다.

만든 사람은 결과물을 이해하고 있을까요?

테스트는 충분할까요?

보안 문제를 알아볼 수 있을까요?

사용자에게 영향을 주는 장애가 나면 누가 책임질까요?

AI가 코드를 대신 써줄수록, 사람은 더 이상 "내가 직접 썼으니 안다"고 말하기 어려워집니다. 대신 "내가 검토했고, 테스트했고, 운영 가능한 상태라고 판단했다"고 말해야 합니다.

Cursor의 Design Mode는 이 흐름을 더 넓게 보여줍니다. Cursor는 UI 요소 선택, 드로잉, 음성 지시로 에이전트에 코드 수정 맥락을 제공한다고 설명했습니다. Cursor Design Mode

다만 실제 팀 생산성 개선 폭은 독립 검증이 필요합니다. 공개된 제품 설명만으로 "얼마나 좋아졌다"고 단정하기는 어렵습니다.

그럼에도 방향은 보입니다. 개발 지시는 텍스트 프롬프트에서 멈추지 않을 가능성이 큽니다. 화면을 가리키고, 그림을 그리고, 말로 설명하면서 에이전트에게 맥락을 주는 방식으로 확장되고 있습니다.

코딩은 점점 더 "작성"보다 "지시와 검토"의 비중이 커지는 쪽으로 움직이고 있습니다.

실무 적용 포인트

개발자나 실무자 입장에서 지금 당장 중요한 것은 새로운 도구를 모두 따라가는 일이 아닙니다. 오히려 AI와 에이전트를 업무에 넣을 때 필요한 기준을 세우는 일입니다.

첫째, 에이전트가 할 일과 사람이 할 일을 나눠야 합니다.

반복적이고 되돌릴 수 있는 작업은 에이전트에게 맡기기 좋습니다. 문서 초안, 테스트 초안, 코드 검색, 간단한 수정, 보안 알림의 1차 패치 같은 작업이 여기에 가깝습니다. 반대로 아키텍처 결정, 권한 정책, 민감 데이터 처리, 배포 승인처럼 책임이 큰 결정은 사람이 검토해야 합니다.

둘째, 에이전트 작업에는 로그와 리뷰가 필요합니다.

상태 유지와 백그라운드 실행이 가능해질수록 편리해지지만, 동시에 "무슨 일이 일어났는지" 알기 어려워질 수 있습니다. 에이전트가 어떤 파일을 읽었고, 어떤 도구를 호출했고, 어떤 판단으로 변경했는지 추적할 수 있어야 합니다.

셋째, 바이브 코딩 결과물은 반드시 테스트 가능한 형태로 다뤄야 합니다.

AI가 만든 코드는 그럴듯해 보일 수 있습니다. 하지만 그럴듯함은 품질이 아닙니다. 최소한 실행 가능한 테스트, 리뷰 가능한 diff, 되돌릴 수 있는 변경 단위가 있어야 합니다.

넷째, 보안 에이전트는 보조자로 봐야 합니다.

GitHub의 agentic autofix나 /security-review 같은 흐름은 보안 업무가 개발 도구 안으로 들어오고 있음을 보여줍니다. 하지만 탐지 품질과 수정 품질은 환경별 검증이 필요합니다. 보안 리뷰를 자동화하더라도 최종 책임 구조는 분명히 남겨야 합니다.

다섯째, 비용을 기능 설계 단계에서 같이 봐야 합니다.

IBM이 추론 비용과 디지털 자원 부담을 AI 트렌드로 언급한 것은 가볍게 넘길 부분이 아닙니다. AI 기능은 데모에서는 멋져 보이지만, 실제 제품에서는 호출량과 응답 시간, 데이터 저장, 인프라 비용이 모두 문제가 됩니다. AI 기능을 넣을 때는 "사용자가 좋아할까?"와 함께 "계속 운영할 수 있을까?"도 같이 물어야 합니다.

마무리 + 생각해볼 질문 1개

AI는 더 이상 별도의 채팅창에만 머무르지 않습니다. 제품 안으로 들어가고, 개발 도구 안으로 들어가고, 보안 리뷰와 코드 수정 흐름 안으로 들어가고 있습니다.

이 변화는 편리합니다. 동시에 부담스럽습니다. AI가 일을 많이 할수록 사람은 더 적게 작성할 수 있지만, 더 많이 검토해야 할 수도 있습니다. 코드를 직접 치는 시간은 줄어들 수 있지만, 책임이 사라지는 것은 아닙니다.

앞으로의 경쟁력은 AI를 많이 쓰는 데서 끝나지 않을 것 같습니다. 에이전트가 한 일을 이해하고, 검토하고, 운영 가능한 방식으로 묶어내는 팀이 더 강해질 가능성이 큽니다.

생각해볼 질문은 하나입니다.

AI 에이전트가 만든 결과물을 우리는 "내가 만든 것"이라고 말할 수 있을 만큼 충분히 이해하고 있을까요?