올해 AWS Summit Seoul의 가장 큰 화두는 단연 AI 에이전트였습니다. 작년까지 생성형 AI의 ‘도입’이 주제였다면, 올해는 에이전트를 통해 AI를 실제 업무와 조직 운영에 어떻게 확산시킬 것인가, 즉 AX(AI Transformation) 전환이 핵심 키워드로 자리 잡았습니다.
이번 글에서는 에이전트 트렌드를 가장 압축적으로 보여준 “에이전트의 진화” 세션(Anthropic, 발표자: 장동진 Applied AI Architect)의 내용을 중심으로, AWS 환경에서 AX 전환을 준비하는 기업이 참고할 만한 내용을 정리합니다.
1. 소프트웨어, 도구에서 동료로
소프트웨어와 인간의 관계는 시간이 지나며 근본적으로 변화해 왔습니다.
2000년대부터 2020년대 초반까지 소프트웨어는 시장 규모와 성능 면에서 압도적인 성장을 이뤘고, 업무 생산성 역시 꾸준히 향상되어 왔습니다. 다만 이 시기의 소프트웨어는 어디까지나 지시를 내리면 따르는 도구(Tool)였습니다.
| 구분 | 과거 (2000년대~2020년대 초) | 현재 |
|---|---|---|
| 소프트웨어의 위상 | 도구(Tool) | 동료(Colleague) |
| 상호작용 방식 | 툴에 지시 → 단순 응답 | 골(Goal)을 공유 → 엔드 투 엔드 결과 |
| 사람의 역할 | 명령을 내리는 사람 | 방향을 제시하는 사람 |
현재는 툴에 지시를 내리고 단순 응답을 받는 것이 아니라, 목표(Goal)를 AI와 공유하고 특정 태스크에 대한 엔드 투 엔드 결과를 기대하는 방식으로 바뀌었습니다. 소프트웨어가 함께 일하는 동료(Colleague)가 된 것입니다.
이러한 변화 자체는 이미 흔히 관찰되는 사실입니다. 중요한 것은 그 다음 질문입니다. 소프트웨어가 동료가 된 시점에서, 기업은 무엇을 준비하고 어떻게 대응해야 하는가.
2. 에이전트의 동작 원리 : Plan, Act, Reflect
LLM이 단순 질의응답 도구를 넘어 동료가 될 수 있었던 핵심 기술은 에이전트(Agent)입니다.
에이전트는 태스크를 입력받으면 다음 세 단계를 반복하며 동작합니다.
| 단계 | 설명 |
|---|---|
| 🗂️ Plan (계획) | 입력받은 태스크를 가장 잘 처리할 수 있는 방식으로 잘게 분할하고 실행 순서를 설계 |
| ⚙️ Act (실행) | 분할된 태스크를 독립된 프로세스로 각각 실행 |
| 🔁 Reflect (반성) | 결과가 유저의 의도에 부합하는지 검증하고, 부족한 부분이 있으면 스텝 백하여 재실행 |
이 세 가지 루프 덕분에 단순 질의응답만 가능했던 LLM이 복잡한 태스크에 대해 엔드 투 엔드 결과를 만들어낼 수 있게 되었습니다. 올해 AWS Summit 전반에서 에이전트가 중심 주제가 된 이유이기도 합니다.
다만 에이전트라는 키워드가 범람하는 것과 별개로, “에이전트 없이는 일을 못 하겠다”고 느낄 만큼의 임팩트를 실제로 경험한 조직은 아직 많지 않습니다. 그러나 특정 분야에서는 이미 명확한 성공 사례가 만들어졌습니다.
3. 에이전트가 가장 먼저 성공한 분야 : 코딩
에이전트가 실질적인 임팩트를 만들어낸 첫 번째 분야는 코드 어시스턴트입니다. 원하는 작업을 자연어로 입력하면 코드 형태로 결과를 받을 수 있고, 수많은 개발자들이 이를 기반으로 생산성을 향상시키고 있습니다.
📈 코드 어시스턴트 성장 타임라인
| 시점 | 변화 |
|---|---|
| 2024년 중반 | “LLM으로 코딩할 만해졌다”는 인식이 확산되기 시작. 당시 워크플로는 코드 복사 → AI에 붙여넣기 → 결과 복사 → IDE에 붙여넣기의 반복으로, 번거롭지만 직접 작성하는 것보다 효율적이었던 단계 |
| 2025년 3월 | 에이전트형 코딩 도구(Claude Code) 등장. 터미널에서 코드 작성·파일 조작·작업 실행까지 지원하며 복사-붙여넣기 과정이 사라지고 사용성이 대폭 개선 |
| 2025년 11월 | 모델 성능의 지속적 개선으로 개발자 개인의 생산성을 넘어 조직 전체의 생산성에 영향을 미치기 시작 |
| 현재 | 해외 유수 기업들을 중심으로 개발자가 직접 코딩하지 않고 방향 수립 + 결과 검토 역할로 전환 |
이러한 역할 전환은 일부 기업에 국한된 현상이 아니라 글로벌 기업 전반에서 공통적으로 관측되고 있으며, Anthropic은 이를 “AX 전환을 위한 성공 패턴”으로 정의했습니다.
4. AX 전환의 성패를 가르는 것 : 유저의 역할 변경
코딩 분야는 왜 성공할 수 있었을까요? 모델 성능이나 좋은 도구도 이유지만, 가장 결정적인 요인은 따로 있습니다.
유저의 역할을 바꿨기 때문입니다.
동일하게 생산성 향상을 위해 AI를 도입한 두 회사를 비교하면 차이가 명확해집니다.
🔍 회사 A vs 회사 B
| 구분 | 회사 A | 회사 B |
|---|---|---|
| AI에게 맡긴 것 | 함수 작성, 리팩토링 등 보조 업무 | 기존에 사람이 하던 코드 작성 전체 |
| 사람의 역할 | 기존과 동일 (코드 작성) | 방향 수립 + 결과 판단으로 변경 |
| 결과 | 제한적 개선 | ✅ AX 전환 성공 |
회사 A는 AI를 도입하면서도 유저의 역할을 그대로 유지했고, 회사 B는 AI에게 역할을 넘기고 사람이 새로운 포지션을 맡았습니다. 결과는 B의 성공이었습니다. 확보된 시간으로 추가 프로젝트를 진행하고 다른 영역에 기여할 수 있었기 때문입니다.
즉, AX 전환의 성패는 AI에게 무엇을 보조시키느냐가 아니라, 무엇을 맡기고 사람이 어떤 새로운 역할을 가져가느냐에서 갈립니다. 이는 클라우드 기반으로 AI 도입을 검토하는 모든 기업에 동일하게 적용되는 원칙입니다.
5. 에이전트의 다음 타깃 : 지식 근로자(Knowledge Worker)
코딩이 핵심 비즈니스가 아닌 기업에게 이 성공 패턴은 먼 이야기처럼 들릴 수 있습니다. 하지만 에이전트의 적용 범위는 이미 개발자를 넘어 확장되고 있습니다. 에이전트 엔진이 뒷단에서 동작하되, 앞단은 CLI가 아닌 일반 유저용 인터페이스를 제공하는 형태의 제품들이 등장하고 있기 때문입니다.
대표적인 예가 다음 두 가지 제품입니다.
🖥️ Claude Cowork : 업무를 통째로 맡기는 데스크탑 에이전트
Cowork는 여러 단계로 이뤄진 복잡한 업무를 한 번에 맡기고 완성된 결과물을 받는 데스크탑 에이전트입니다. 동작 방식을 “회의록을 요약하고 후속 할 일(액션 아이템)을 정리해달라”는 업무를 예로 들어 풀어보면 다음과 같습니다.
- 사용자가 자연어로 업무를 요청하면, 에이전트가 작업에 필요한 작업 공간(폴더 등)을 스스로 준비합니다.
- 요청이 모호한 부분이 있으면 곧바로 실행하지 않고, 먼저 사용자에게 되물어 요구사항을 명확히 합니다.
- 그다음 전체 작업 계획을 세우고, 계획한 순서대로 단계를 하나씩 처리해 나갑니다.
- 작업 도중에 사용자가 새로운 지시를 끼워 넣어도 흐름이 끊기지 않고, 할 일 목록에 추가해 이어서 처리합니다.
- 완성된 결과물은 문서 형태로 정리되어 저장되고, 사용자는 그 결과를 검토한 뒤 피드백만 주면 됩니다.
핵심은 사용자가 중간 과정을 일일이 지시하는 것이 아니라 목표를 던지고 결과를 검토하는 역할만 한다는 점입니다. 앞서 살펴본 ‘코딩에서의 역할 변경’이 사무 업무에서도 똑같이 재현되는 셈입니다.
🎨 Claude Design : 대화로 디자인하는 캔버스
Design은 대화만으로 브랜드 이미지, 슬라이드, 프로토타입 등을 만드는 디자인 도구입니다. 디자인 툴 사용법을 몰라도, 만들고 싶은 것을 말로 설명하면 결과물이 생성되고 다시 말로 수정할 수 있습니다. 실제로 다음과 같은 작업이 가능합니다.
- “회전하는 지구본 위 도시들을 빛나는 경로로 잇는 이미지를 만들어줘”라고 요청하면 해당 이미지를 생성하고, “각 지점을 표시하는 보기 옵션을 추가해줘”처럼 이어서 다듬을 수 있습니다.
- 화면 여러 개로 구성된 간단한 앱(프로토타입)을 만들고, 클릭으로 색상을 바꾸거나 자연어로 수정사항을 반영할 수 있습니다.
- 사진을 세부 조건에 맞춰 편집하거나 그래프를 만들고, 완성된 결과물을 원하는 형식으로 내보낼 수 있습니다.
두 제품의 공통점은 개발자가 아닌 일반 지식 근로자를 위한 도구라는 점입니다. 즉 이 제품들이 전하는 핵심은 특정 기능이 아니라 다음 한 문장입니다.
개발자 이후 에이전트의 다음 타깃은 지식 근로자(Knowledge Worker)다.
코딩 분야에서 검증된 성공 패턴이 이제 일반 사무 업무 전반으로 확산되는 단계이며, 이는 곧 모든 산업의 기업이 AX 전환의 대상이 된다는 의미입니다.
6. AX 전환의 적용 전략, 그리고 AWS 활용
그렇다면 기업은 AX 전환을 어디서부터, 어떻게 시작해야 할까요. AX 전환을 위한 적용 전략과, 이를 이미 AWS를 사용 중인 기업이 어떻게 활용할 수 있는지를 함께 정리했습니다.
🎯 어디에 적용할 것인가 (3가지 적용점)
| 적용 대상 | 설명 |
|---|---|
| 👥 직원 (People) | 직원들이 각자 에이전트 팀을 구성해 일하는 구조. 생산성 향상의 출발점 |
| 🔄 프로세스 (Process) | 아무도 하기 싫어하는 반복 업무가 좋은 후보. 예를 들어 한 글로벌 제약사는 임상 문서 작성에 10주가 소요되었는데, 원인은 사람이 아닌 프로세스 자체였음. 이를 자동화하면 완전히 다른 결과를 만들 수 있음 |
| 📦 제품 (Product) | 직원 업무에만 적용할 이유가 없음. 자사 제품에 직접 적용하면 고객이 더 큰 임팩트를 경험 |
🛠️ 어떻게 적용할 것인가 (3가지 실행 원칙)
| 원칙 | 설명 |
|---|---|
| 🔲 Bounded Problem 설정 | 어려운 문제부터 풀려고 하지 말 것. 목표와 기준이 명확한 문제를 선택해야 AI가 일하고 사람이 평가하는 구조, 즉 역할 변경이 가능해짐 |
| 🔍 맥락(Context)에 투자 | 풀고자 하는 문제에 회사 내부 지식을 활용할 수 없다면 아무리 좋은 모델도 소용없음. MCP를 통한 자사 데이터 커넥터 구축이 필수 |
| ☁️ 인프라는 익숙한 환경에서 | 새 인프라를 구축할 필요 없이, 이미 사용 중인 AWS 같은 클라우드 환경에서 검증된 모델과 엔터프라이즈 제품을 바로 활용 가능 |
☁️ 이미 AWS를 쓰고 있다면
AX 전환을 위해 반드시 특정 클라우드가 필요한 것은 아닙니다. 다만 이미 AWS를 사용 중인 기업이라면 별도의 인프라를 새로 구축하지 않고 기존 환경 위에서 시작할 수 있다는 점이 강점입니다.
- AWS Marketplace — Claude for Enterprise를 비롯한 엔터프라이즈용 AI 제품을 Marketplace를 통해 도입할 수 있습니다. 기존 AWS 계약·빌링 체계 안에서 구매와 비용 관리가 가능하다는 것이 장점입니다.
- Claude 플랫폼과 AWS 연동 — 최근 Claude 플랫폼을 AWS와 연동해 엔터프라이즈 환경에 통합할 수 있게 되었습니다.
- Amazon Bedrock — Claude를 포함한 다양한 파운데이션 모델을 AWS의 보안·거버넌스 체계 안에서 API로 활용할 수 있어, 사내 데이터와 결합한 에이전트 워크로드 구축의 기반이 됩니다.
7. 마치며
지금까지의 내용은 세 가지 메시지로 요약됩니다.
- 소프트웨어는 도구에서 동료로 진화했고, 그것을 가능하게 한 것은 에이전트다.
- 에이전트는 코딩에서 먼저 성공했으며, 성공의 비결은 유저의 역할 변경이다.
- 다음 타깃은 지식 근로자다.
AX 전환을 고민하는 조직이라면 “AI에게 무엇을 보조시킬 것인가”가 아니라 “AI에게 무엇을 맡기고, 사람은 어떤 역할을 새로 가져갈 것인가”로 질문을 바꾸는 것에서 출발할 수 있습니다. 그 첫걸음은 목표와 기준이 명확한 문제(Bounded Problem)를 선정하고, 사내 데이터를 에이전트가 활용할 수 있는 환경을 갖추는 것입니다.
에이전트는 더 이상 먼 미래의 키워드가 아니라, 이미 일하는 방식 자체를 바꾸고 있는 현재진행형 기술입니다. 남은 질문은 이 변화를 언제, 어떻게 우리 조직의 것으로 만들 것인가입니다.
SA 원성연