AWS AgentCore와 n8n 연동: 기억과 비용부터 확인하기

n8n으로 고객 문의를 처리하다 보면 다음 실행에서도 앞 대화를 이어 가고 싶어집니다. 이때 필요한 것은 ‘기억하는 모델’이 아니라 무엇을 저장하고, 누구의 대화인지 구별하고, 언제 다시 읽을지 정하는 구조입니다.

Amazon Bedrock AgentCore는 AI 에이전트의 실행 환경과 도구, 기억을 관리하는 AWS 서비스입니다. AWS는 아마존의 클라우드 서비스이고, Amazon Bedrock은 여러 AI 모델을 골라 쓰는 AWS 서비스입니다. AgentCore는 그 모델로 만든 에이전트를 운영하는 데 필요한 기능을 맡습니다.

이 글은 AgentCore가 n8n 기본 기능과 무엇이 다른지, 기억이 어떤 값으로 이어지는지, 연결 준비와 첫 실행, 비용 순서로 설명합니다. 실제 AgentCore 실행에는 AWS와 모델 사용 요금이 붙습니다.

n8n이 처음이라면 기본 구조는 비개발자를 위한 n8n 설명에 정리해 두었습니다. 노드(node)는 작업 하나를 맡는 구성 요소이고, 워크플로는 노드를 순서와 조건에 맞게 이은 자동화입니다.

n8n 기본 기능으로는 기억할 수 없나요?

기억할 수 있습니다. n8n의 AI Agent 노드에 Postgres 같은 저장소를 연결하면 실행이 달라도 대화 기록이 남습니다. Postgres는 데이터를 보관하는 데이터베이스입니다.

코드 실행이나 브라우저 작업도 n8n에서 노드와 운영 환경을 갖추면 할 수 있습니다. 그래서 AgentCore를 고를지는 기능이 있느냐 없느냐가 아니라, 격리된 실행 환경과 기억 저장소를 직접 운영할지 AWS의 관리형 기능에 맡길지로 정해집니다.

같은 일을 n8n과 AgentCore에서 맡을 때 볼 설정

필요한 일	n8n 기본 기능직접 연결하고 운영	AgentCoreAWS 관리형
대화 기록 보관	연결한 메모리 저장소 세션 설정	기억 모드 사용자와 세션 구분
코드 실행	실행 노드 언어와 실행 환경	격리된 코드 실행 도구 권한
브라우저 조작	브라우저 연결 노드 운영 환경	관리형 브라우저 도구 접근 범위
오래 걸리는 작업	워크플로 실행 제한	호출 제한 세션 수명

‘관리형’은 서비스 제공자가 서버 운영의 일부를 맡는다는 뜻입니다. 에이전트에 넣을 자료, 권한 범위, 결과를 통과시킬 기준은 여전히 운영하는 쪽이 정합니다.

harness와 런타임은 무엇인가요?

harness는 모델, 도구, 기억을 묶어 구성하고 에이전트 실행을 관리하는 AgentCore의 기능입니다. 런타임(runtime)은 에이전트가 실제로 실행되는 환경입니다. AWS는 CreateHarness로 구성을 만들고 InvokeHarness로 호출하는 API를 제공합니다. API는 프로그램이 서비스에 요청을 보내고 응답을 받는 연결 방식입니다. 호출에 쓰는 API는 두 개지만, 그 전에 AWS 계정과 권한, 모델 접근을 준비해야 합니다.

위 그림은 AWS가 공개한 구조도입니다. 모델은 답변을 만들고, 도구는 브라우저나 코드 실행 같은 작업을 하며, 메모리는 대화와 필요한 정보를 보관합니다. 스킬은 특정 업무의 지식과 절차를 담은 자료입니다.

그림의 기능이 모두 n8n 노드에서 바로 켜지지는 않습니다. 예를 들어 웹 검색은 노드에 검색 도구를 따로 연결해야 합니다. 검색용 MCP 서버를 붙이는 방법도 있습니다. MCP는 AI 앱과 외부 도구를 연결하는 규약입니다.

기억을 결정하는 세 가지 값

세션(session)은 이어지는 한 대화를 구분하는 단위입니다. 같은 사용자라도 새 주제로 시작한 대화는 다른 세션으로 둘 수 있습니다. 기억은 아래 세 가지 값으로 정해집니다.

같은 대화의 후속 질문에는 같은 세션 값과 사용자 값을 넣습니다. 두 번의 실행이 이어지는 모습을 노드 입력값과 함께 놓으면 이렇습니다.

n8n, AgentCore 노드 실행 두 번

1회차 입력
Actor ID = customer-a
Session ID = a-1

> 주문번호는 1234입니다. 배송 문의입니다.

2회차 입력
Actor ID = customer-a
Session ID = a-1

2회차에 1회차와 같은 두 값을 넣어야 같은 대화로 이어집니다

> 제 주문번호가 몇 번이었죠?

주문번호는 1234입니다.

기억은 모델을 새로 학습시키는 것과 다릅니다. 저장한 대화나 거기서 추출한 정보를 다음 요청에서 다시 참고하는 방식입니다. 기억에는 짧은 대화 이력과, 여러 대화에 걸쳐 꺼내 쓰는 장기 기억이 따로 있습니다. 새 세션에서 과거 정보가 나올지, 어디까지 나올지는 장기 기억에 설정한 전략과 검색 조건이 정합니다.

n8n 노드 문서는 기억 모드와 세션 ID를 따로 설명합니다. Session ID가 비어 있으면 실행마다 새 대화가 만들어지고, 사용자를 나누려면 Actor ID도 넣어야 합니다. Actor ID는 로그인한 사용자 정보에서 가져와야 하고, 고객이 입력창에 다른 사람의 값을 넣을 수 있게 만들면 다른 사람의 기억을 불러올 수 있습니다.

실제 연결 전에 준비할 것

n8n Cloud는 n8n이 서버를 운영해 주는 서비스이고, 자체 호스팅은 직접 서버를 운영하는 방식입니다. 어느 쪽이냐에 따라 노드를 설치할 사람과 권한이 다릅니다. 준비는 아래 순서로 합니다.

AgentCore 노드를 연결하기 전 준비 순서

1. 11. n8n 환경커뮤니티 노드를 설치할 수 있는지
   설치 담당자는 누구인지
2. 22. AWS 리전AgentCore와 쓸 모델이
   그 리전에서 지원되는지
3. 33. 호출자 권한n8n이 AWS에 요청할 때
   쓰는 자격 증명의 권한
4. 44. 실행 역할AgentCore가 실행 중
   모델과 리소스에 접근할 권한
5. 55. 모델 접근고른 리전에서
   접근이 허용된 모델
6. 66. 비용 한도시험 횟수, 토큰과 시간 제한
   볼 청구 항목

IAM은 AWS의 사용자와 권한을 관리하는 기능입니다. 3단계의 호출자 권한은 n8n이 AWS를 부를 때 쓰는 자격 증명에 붙고, 4단계의 실행 역할은 AgentCore가 작업하는 동안 맡는 권한 묶음입니다. 실행 역할은 ARN이라는 AWS 리소스 주소로 지정하며, 호출자의 자격 증명과는 다른 값입니다.

AWS 보안 문서도 호출자 권한과 실행 역할을 나눠 설명합니다. 실행 역할에는 그 역할을 누가 맡을 수 있는지 정하는 신뢰 정책도 붙여야 합니다. 오류가 난다고 모든 기능의 권한을 한꺼번에 넣지 말고, 쓸 모델과 기능에 맞춰 필요한 권한만 줍니다.

n8n에서 첫 응답까지의 순서

화면 이름은 노드 버전에 따라 바뀔 수 있으므로 공식 Quickstart를 함께 열어 둡니다.

1. 노드 설치: 노드 추가에서 Amazon Bedrock AgentCore를 찾습니다. 패키지 이름은 @aws/n8n-nodes-agentcore이고, n8n Cloud에서는 인스턴스 소유자가 처음 설치합니다. 노드 목록에 AgentCore가 보이면 설치된 것입니다.
2. 자격 증명 연결: Credentials → New → Amazon Bedrock AgentCore API에서 AWS 자격 증명, 리전, 실행 역할 ARN을 넣습니다. 비밀값은 자격 증명 저장 기능에만 넣고 프롬프트나 공유 화면에 붙이지 않습니다.
3. 워크플로 만들기: 새 워크플로에 Manual Trigger와 AgentCore 노드를 잇습니다. Manual Trigger는 직접 눌러 실행하는 시작 노드입니다.
4. 모델과 입력 정하기: 모델 제공사, 접근이 허용된 모델 ID, 에이전트 이름을 정합니다. System Prompt에는 응답 규칙을, Prompt에는 실제 문의 한 건을 넣습니다. 처음에는 브라우저, 코드 실행, 자동 반복을 붙이지 않습니다.
5. 한 번 실행: 반복 횟수와 시간 제한을 정한 뒤 한 번 실행합니다. 출력의 response에 답변이 나오면 연결은 된 것입니다.

첫 입력은 결과가 맞는지 바로 알 수 있는 문의로 고릅니다.

n8n, AgentCore 노드 첫 실행

> Prompt = 주문번호 1234 배송이 언제 오나요? 이 문의를 유형과 주문번호로 한 줄 정리해 주세요.

response = 배송 문의, 주문번호 1234

문의 유형과 주문번호가 원문 그대로인지 봅니다

실행이 성공으로 표시돼도 주문번호가 바뀌었거나 유형이 틀렸다면 내용 검수에서는 실패입니다.

Harness ARN을 비워 두면 첫 실행에서 AWS 리소스를 새로 만듭니다. 이미 만든 harness를 지정하는 방식과는 동작이 다르고, 첫 생성에는 시간이 걸리므로 응답이 늦어도 연속으로 다시 실행하지 않습니다. 남이 만든 예제 워크플로를 가져왔다면 노드, 도구, 외부 주소, 실행 조건부터 봅니다.

첫 응답을 확인한 뒤 기억을 시험합니다

도구 없는 짧은 응답이 맞게 나오면, 같은 harness에서 기억이 사용자별로 나뉘는지 시험합니다. 노드의 Memory Mode에서 저장 방식을 보고, 꺼져 있으면 기억을 쓰는 설정으로 바꿉니다. 기본값은 설치한 버전과 생성 방식에 따라 다르므로 화면에 표시된 값을 기준으로 삼습니다. 관리형 기억은 저장과 조회에 요금이 붙습니다.

시험은 시험용 식별값으로 합니다. 고객 A의 두 요청에는 같은 Actor ID와 Session ID를 넣고 Prompt만 바꿉니다. 고객 B를 시험할 때는 두 값을 모두 새로 정합니다. 실행마다 넣은 값과 출력에 돌아온 세션 값을 적어 두면, 결과가 이상할 때 어느 값이 문제였는지 찾을 수 있습니다.

넣은 값에 따라 기대하는 기억 동작

다음 요청에 넣은 값	앞 대화가 이어짐	다른 고객 정보가 나옴
같은 Actor ID, 같은 Session ID	제공	제공하지 않음
같은 Actor ID, 새 Session ID	장기 기억 설정에 따라	제공하지 않음
다른 Actor ID	제공하지 않음	제공하지 않음

새 세션을 만든다고 같은 사용자의 장기 기억이 지워지지는 않습니다. 실제 운영에서는 잘못 저장된 정보를 고치는 방법, 보관 기간과 삭제, 사용자별 접근 범위도 정해 둡니다. 기억을 오래 남길수록 좋은 것은 아니고, 남기는 만큼 관리할 정보와 비용이 늘어납니다.

응답과 실행 기록을 읽는 법

노드 출력에는 답변 말고도 여러 항목이 나옵니다. 항목마다 알려 주는 것과 알려 주지 않는 것이 다릅니다.

토큰은 모델이 입력과 출력을 처리하는 데이터 조각입니다. 답변 한 번을 만드는 동안에도 모델이나 도구가 여러 번 호출될 수 있습니다.

위 화면은 AWS가 공개한 예시이고, 화면의 숫자도 예시 값입니다. CloudWatch는 AWS의 로그와 측정값을 모아 보는 서비스이고, 이 화면에서는 어떤 작업이 몇 번 실행됐는지 봅니다. 개별 실행의 추적 기록은 CloudWatch Transaction Search에서 검색하므로, 기록이 보이지 않으면 Transaction Search 설정부터 봅니다. 실제 청구 금액은 Cost Explorer 같은 비용 조회 도구에 나옵니다.

사용하지 않으면 비용이 항상 0원인가요?

아닙니다. harness 자체에는 추가 이용료가 없지만, 실행 자원, 모델 호출, 기억 저장과 조회, 도구, 로그, 연결한 저장소에 각각 요금이 붙습니다.

microVM은 실행을 서로 격리하는 작은 가상 머신입니다. vCPU는 가상 CPU의 용량 단위이고, GB 시간은 메모리 용량에 사용 시간을 곱한 단위입니다. 2026년 10월 4일 공식 가격표의 Runtime microVM v1 단가로 짧은 실행 한 번을 계산하면 이렇습니다.

Runtime microVM v1 단가와 짧은 실행 한 번의 요금

• 0.0895달러CPU 단가vCPU 시간당
• 0.00945달러메모리 단가GB 시간당
• 0.000149달러CPU 1 vCPU를 6초 쓴 경우6 ÷ 3,600 × 0.0895
• 0.0001575달러메모리 1GB를 60초 쓴 경우60 ÷ 3,600 × 0.00945

CPU와 메모리는 측정 기준이 다릅니다. 실행이 60초 걸렸다고 CPU를 60초 내내 같은 양만큼 쓴 것은 아니므로, CPU 요금과 메모리 요금은 각각의 사용량으로 따로 계산합니다. 오래 보관한 기억과 로그에는 대화를 호출하지 않는 동안에도 보관 요금이 붙습니다. n8n 요금이나 직접 운영하는 서버 비용은 이와 별개입니다.

첫 시험에서는 실제로 쓸 기능만 켜고 반복 횟수, 시간, 토큰 제한을 정합니다. 사용 기록 화면의 숫자는 최종 청구액이 아니므로, 정한 예산을 넘을 것 같으면 자동 실행을 멈추고 어느 항목이 늘었는지 비용 조회 도구에서 봅니다.

결과가 틀리거나 연결이 막히면

증상마다 먼저 볼 곳은 다음과 같습니다.

다른 사용자의 정보가 보이면 실제 고객 자료로 시험을 이어 가지 않습니다. 시험용 식별값으로 돌아가 사용자 분리 설정을 고치고, 같은 대화와 다른 사용자 두 경우를 다시 시험합니다.

시험이 끝나면 아래 순서로 정리합니다. 워크플로를 멈춰도 저장된 기억과 로그는 남기 때문에 따로 지워야 합니다.

시험이 끝난 뒤 정리 순서

1. 11. 자동 실행 끄기n8n 워크플로의
   트리거 비활성화
2. 22. AWS 리소스 확인첫 실행에서 생긴
   harness와 관련 리소스
3. 33. 남길 자료 구분보존할 기록과
   지울 기록 나누기
4. 44. 기억과 로그 정리서비스별 보관과
   삭제 절차 적용

다음 업무로 넓히기 전에 세 가지를 적어 둡니다. 어떤 대화를 이어 갈지, 누구와 누구를 분리할지, 어떤 결과를 통과로 볼지입니다. 이 기준이 있어야 실패했을 때 설정과 원인을 짚을 수 있습니다.

Sources

• n8n Postgres Chat Memory 문서
• AWS n8n-nodes-agentcore 저장소
• n8n AgentCore 노드 Quickstart
• Amazon Bedrock AgentCore harness 정식 출시 (AWS 블로그)
• AgentCore harness 기억 동작
• AgentCore harness 보안과 접근 제어
• AgentCore harness 관측과 비용 제어
• AgentCore 가격표

3줄 요약

1. AgentCore는 AI 에이전트의 실행 환경과 기억, 도구를 관리하는 AWS 서비스이며 n8n에서는 @aws/n8n-nodes-agentcore 전용 노드로 연결합니다.

2. 같은 대화를 이어 가려면 기억을 켜고 같은 Session ID와 Actor ID를 넣어야 하며 Session ID가 비어 있으면 실행마다 새 대화가 만들어집니다.

3. harness 자체에는 추가 이용료가 없어도 실행 자원과 모델 호출, 기억 저장과 로그에 각각 요금이 붙고 Runtime microVM v1의 CPU는 vCPU 시간당 0.0895달러입니다.