‘답하는 AI’에서 ‘일을 끝내는 AI’로: 경계선이 어디서 바뀌나
2025년을 지나며 AI 업계의 언어가 ‘생성’에서 ‘실행’으로 이동했다. 기존 생성형 AI는 질문에 그럴듯한 답을 돌려주는 데서 멈췄다. 사람이 그 답을 받아 코드를 붙여넣고, 문서를 다듬고, 시스템에 입력해야 비로소 하나의 ‘일’이 완결됐다. 마이크로소프트가 빌드(Build)에서 강조한 ‘오픈 에이전틱 웹(open agentic web)’, 앤트로픽(Anthropic)이 내세운 에이전틱(agentic) 모델 라인업이 공통으로 겨냥하는 지점이 바로 이 마지막 간극이다. 답을 만드는 데서 그치지 않고, 목표를 받아 여러 단계를 계획하고 외부 도구와 API를 직접 호출해 결과물까지 마무리하는 ‘행위 주체’로 AI의 역할을 끌어올리겠다는 것이다.
대화형과 에이전트형을 가르는 기준은 딱 하나, ‘실행 권한’이다. 대화형이 “이렇게 하세요”라고 설명한다면, 에이전트형은 “실제로 그 작업을 수행”한다. 판단의 실용적 기준은 이렇게 잡으면 된다. 사람이 출력물을 복사해 다음 시스템에 옮겨야 한다면 아직 대화형이고, AI가 그 옮기는 행위까지 대신한다면 에이전트형이다. 여기서 초보자가 가장 자주 하는 오해가 에이전틱을 곧 ‘무인 완전 자동화’로 읽는 것이다. 현실의 도입 대부분은 사람이 목표와 경계를 정하고, AI가 반복·조립 단계를 처리한 뒤, 사람이 검토·승인하는 사람 개입(human-in-the-loop) 구조다. 자율성은 0이냐 100이냐의 스위치가 아니라 슬라이더이며, 그 눈금을 어디에 둘지가 곧 리스크 설계 그 자체다.
왜 같은 도구를 써도 성과가 갈리나: 생산성 패러독스의 실체
삼성SDS의 분석이 짚은 ‘AI 생산성 패러독스’는 실무자가 가장 먼저 부딪히는 벽이다. 같은 챗GPT(ChatGPT)·클로드(Claude)·제미나이(Gemini)를 붙여도 어떤 팀은 확연히 빨라지고 어떤 팀은 오히려 시간을 더 쓴다. 원인은 도구의 성능 차이가 아니라 ‘사용 역량’과 ‘업무 설계’에 있다. 구체적으로 세 갈래에서 갈린다. 첫째, 프롬프트에 맥락·제약·예시 형식까지 담아 구조화하는가, 한 줄로 던지고 마는가. 둘째, 출력을 검증하는 절차가 팀의 워크플로에 박혀 있는가, 개인의 눈대중에 맡기는가. 셋째, AI가 강한 일(초안·요약·형식 변환·반복 처리)과 사람이 쥐어야 할 일(판단·책임·최종 승인)을 나눠 배분하는가.
이걸 실행 가능한 절차로 바꾸면 첫 단추는 ‘기준선(baseline) 측정’이다. 보고서 초안에 평균 3시간이 걸렸다는 숫자를 도입 전에 기록해두지 않으면, ‘빨라진 것 같다’는 체감은 검증할 방법이 없고 예산 승인 근거도 되지 못한다. 두 번째 함정은 ‘숨은 검수 비용’이다. 생성은 5분에 끝나지만 사실관계·수치·톤을 바로잡는 데 40분이 든다면 순효과는 절반 아래로 떨어진다. 특히 환각(hallucination)은 그럴듯할수록 잡아내기 어려워 검수 부담을 키운다. 그래서 성과를 내는 팀은 ‘AI에게 시킬 일’만큼 ‘AI에게 절대 맡기지 않을 일’을 먼저 문서로 못 박는다. 규제 문구, 대외 공식 발표, 법적 책임이 걸린 문서는 초안까지만 AI에 맡기고 확정은 사람이 전담하는 식의 경계선이 생산성 곡선을 가른다.
직무 역량과 업무 방식은 어떻게 재편되나
에이전틱 AI가 퍼지면 직무가 사라지기보다 ‘작업 구성’이 재편된다. 개발 영역이 가장 먼저 이 변화를 체감하는 현장이다. 전자신문이 소개한 7월 AI 네이티브 교육 과정에 ‘클로드 코드’, ‘하네스(harness) 엔지니어링’, ‘AI 거버넌스’가 나란히 편성된 점이 그 방향을 압축해 보여준다. 코드를 한 줄씩 손으로 치는 능력의 비중은 줄고, AI 에이전트에게 작업을 정확히 위임하도록 실행 환경을 설계하고(하네스), 그 산출물을 검증·통합하며, 조직 차원의 위험을 관리하는(거버넌스) 능력이 새 핵심 축으로 올라오고 있다. 신입 개발자에게 걸리는 기대치가 ‘코드를 생산하는 사람’에서 ‘AI 산출물을 읽고 판단·조율하는 사람’으로 옮겨간다는 뜻이다.
다만 기대와 현실의 눈금을 맞춰야 한다. ‘AI가 개발자를 대체한다’는 서사는 아직 실제 도입 범위를 앞질러 있다. 지금의 에이전트는 명세가 뚜렷한 반복 작업, 정형 변환, 기존 코드 기반 수정에서 강하고, 모호한 요구사항 해석·아키텍처 트레이드오프 판단·이해관계 조율에서는 약하다. 그래서 실무자가 준비할 체크포인트는 세 가지로 압축된다. (1) 내 업무에서 정형·반복이 차지하는 비중을 냉정하게 계량한다. 이 비중이 높을수록 위임 여지가 크고, 낮을수록 당장의 자동화 효과는 제한적이다. (2) AI 출력을 걸러낼 ‘내 분야의 판단력’을 오히려 더 키운다. 검증할 실력이 없으면 자동화의 수혜가 아니라 잘못된 산출물의 위험을 그대로 떠안는다. (3) 6개월~2년 관점에서 팀 워크플로가 어떻게 바뀔지 시나리오를 그린 뒤, 전면 전환이 아니라 좁은 파일럿부터 측정하며 넓힌다.
실행 권한을 주기 전 설계할 것: 비용·보안·책임
에이전틱 AI는 실행 권한을 쥐기 때문에 대화형과는 리스크의 종류 자체가 다르다. 첫째는 비용 구조다. 에이전트는 한 작업을 끝내려고 모델을 여러 번 반복 호출하고 도구를 연쇄로 실행한다. 단순 질의응답이 1회 호출이라면 계획→도구 호출→중간 판단→재시도를 거치는 에이전트는 수 배에서 수십 배의 토큰·API 사용량으로 불어날 수 있다. 그래서 검토 단계에서 ‘건당 예상 호출 횟수 × 단가 × 월 처리 건수’로 상한선을 러프하게라도 계산하고, 예산 상한(budget cap)과 사용량 모니터링·알림을 먼저 붙여야 한다. 파일럿에서 비용 추정을 건너뛴 조직이 뒤늦게 청구서를 보고 놀라는 패턴이 반복되는 이유가 여기에 있다.
둘째는 보안과 책임인데, 여기서 원칙은 하나로 요약된다. 에이전트가 ‘접근할 수 있는 범위’가 곧 사고가 터졌을 때의 ‘피해 반경’이다. 따라서 읽기/쓰기 권한을 업무에 꼭 필요한 최소 범위로 좁히는 최소 권한 원칙이 출발점이고, 외부에서 들어온 데이터에 숨은 명령이 섞여 에이전트를 조종하는 ‘프롬프트 주입(prompt injection)’을 상수로 가정해 입력을 신뢰하지 않는 설계가 뒤따라야 한다. 여기에 AI가 자동 실행한 결과가 어긋났을 때의 책임 소재와 롤백 절차를 미리 문서로 정해둔다. 흔한 오해는 ‘유명 벤더 모델을 쓰니 보안은 알아서 처리된다’는 생각인데, 데이터 접근 권한 설정·로그 보관·승인 흐름 같은 운영 책임은 도입 조직의 몫으로 남는다. 결국 이 기술은 ‘좋다/나쁘다’로 판정할 대상이 아니라, ‘어떤 조건에서 의미가 있고 어디까지 맡길지’를 조직이 직접 설계하는 도구다. 작게 시작해 측정하고, 검증 체계와 함께 넓히는 조직만이 패러독스의 함정을 비껴간다.
자주 묻는 질문
에이전틱 AI와 챗봇(대화형 AI)의 가장 큰 차이는 무엇인가요?
핵심은 ‘실행 권한’입니다. 대화형 AI는 답을 생성하고 실제 실행은 사람이 하지만, 에이전틱 AI는 목표를 받아 작업을 여러 단계로 쪼개고 외부 도구·API를 직접 호출해 결과물까지 마무리합니다. 판단 기준은 간단합니다. 사람이 출력물을 다음 시스템으로 옮겨야 하면 대화형, AI가 그 행위까지 대신하면 에이전트형입니다.
같은 AI 도구를 도입했는데 팀마다 성과가 다른 이유는?
도구 성능보다 사용 역량과 업무 설계 차이가 큽니다. 프롬프트에 맥락·제약까지 담아 구조화하는지, 출력 검증 절차가 워크플로에 박혀 있는지, AI가 강한 일과 사람이 쥐어야 할 일을 나눴는지가 성과를 가릅니다. 도입 전 소요 시간 기준선을 기록하지 않으면 효과 검증도, 예산 근거도 만들 수 없습니다.
에이전틱 AI가 개발자를 대체하나요?
현시점에선 도입 범위를 앞선 과장입니다. 에이전트는 정형·반복 작업과 기존 코드 수정에 강하지만 모호한 요구 해석·아키텍처 판단·이해관계 조율에는 약합니다. ‘대체’보다 역할 기대치가 코드 생산에서 ‘AI 산출물의 판단·조율’로 이동하는 재편으로 보는 편이 정확합니다.
도입 시 비용은 무엇을 주의해야 하나요?
에이전트는 한 작업에 계획·도구 호출·재시도를 거치며 모델을 여러 번 부르므로, 단순 질의응답보다 사용량이 수 배에서 수십 배로 늘 수 있습니다. ‘건당 호출 횟수 × 단가 × 월 처리 건수’로 상한을 추산하고, 예산 상한과 사용량 모니터링·알림을 먼저 설계해야 청구서 충격을 피합니다.
보안 측면에서 가장 먼저 챙길 것은?
에이전트가 접근 가능한 범위가 곧 사고 반경입니다. 최소 권한 원칙으로 접근을 좁히고, 외부 데이터에 숨은 명령이 섞이는 프롬프트 주입을 상수로 가정해 입력을 신뢰하지 않는 설계를 하며, 자동 실행 결과에 대한 책임 소재와 롤백 절차를 미리 정해야 합니다. 벤더가 보안을 다 해준다는 생각은 위험합니다.