[2025.07.25 주간 개발 트렌드] GitHub Spark 정리 (앱 생성, Repository 연결, 검증할것)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# AI Agent를 만들고나면 끝일까

AI Agent 예제를 보면 생각보다 간단해보인다. 모델을 연결하고 사용할 도구 몇개를 등록하면 질문에 맞춰 API도 호출하고 답변도 만들어준다.

그런데 이걸 실제 서비스로 올리려고하면 할일이 갑자기 많아진다.. 사용자가 늘어나면 어디에서 실행할지, 대화는 어디에 저장할지, 외부 서비스의 권한은 어떻게 관리할지 정해야한다.

이번주 7월 16일에 [Amazon Bedrock AgentCore](https://aws.amazon.com/blogs/aws/introducing-amazon-bedrock-agentcore-securely-deploy-and-operate-ai-agents-at-any-scale/)가 Preview로 공개됐다. 이번주 개발트렌드로 어떤 부분을 도와주는지 정리해보려고 한다.

Agent를 실행하고 운영할때 필요한 기반 기능을 관리형 서비스로 제공한다는게 핵심이다. 새 모델을 하나 더 발표한것과는 다르다.

# 1. 우선 어떤 기능이 있는지 살펴보자

AgentCore는 한개의 기능만 제공하는 서비스가 아니다. 필요한 구성요소를 각각 사용하거나 함께 연결할 수 있는 형태다.

| 구성요소 | 하는 일 |
| --- | --- |
| Runtime | Agent 실행 환경과 세션 격리 |
| Memory | 대화 맥락과 장기 기억 관리 |
| Identity | Agent의 인증과 외부 서비스 접근 관리 |
| Gateway | API나 Lambda를 Agent용 도구로 연결 |
| Browser | 웹 작업에 사용할 관리형 브라우저 |
| Code Interpreter | 생성한 코드를 실행할 격리 환경 |
| Observability | Agent 실행 과정 관찰과 문제 분석 |

기존에는 이 기능들을 직접 만들거나 여러 서비스를 조합해서 붙여야했다. AgentCore는 그중 반복되는 기반 작업을 줄이려는 방향으로 볼 수 있다.

특정 프레임워크로 Agent 코드를 전부 다시 작성해야하는 구조도 아니다. 발표에서는 여러 프레임워크와 모델을 사용할 수 있다는 점을 강조했다.

다만 기존 코드를 가져올 수 있다는것과 아무 설정 없이 운영된다는것은 다르다. 실행 진입점, 접근 권한, 데이터 저장 범위는 서비스에 맞춰 정해야한다.

# 2. 주문 조회 Agent로 생각해보면

예를 들어 사용자가 배송 상태를 물어보는 Agent를 만든다고 해보자.

```text
사용자 질문
    ↓
Agent가 필요한 작업 판단
    ↓
주문 조회 도구 호출
    ↓
주문 서버에서 권한 확인 후 데이터 반환
    ↓
Agent가 답변 작성
```

데모에서는 주문번호를 넣고 데이터를 가져오면 끝일 수 있다. 실제 서비스에서는 다른 사용자의 주문번호를 넣었을때도 확인해야한다.

모델이 주문번호를 알아냈다는 이유만으로 조회를 허용하면 안된다. 로그인한 사용자가 해당 주문을 볼 수 있는지는 주문 서버에서 검증해야한다.

AgentCore가 실행 환경과 인증 연결을 도와줘도 업무 데이터의 접근 규칙까지 대신 정해주는것은 아니다. **도구가 호출됐다는 사실과 그 작업을 허용해도 된다는 판단은 따로 봐야한다.**

이 부분은 Agent를 붙이기 전부터 API에 있어야하는 규칙이기도 하다. AI를 연결했다고 기존 서버의 권한 검사를 생략할 이유는 없다.

# 3. Memory가 있다고 전부 기억시키면 될까

대화를 이어가려면 앞에서 무슨 이야기를 했는지 알아야한다. 사용자가 배송을 물어본 뒤 “그럼 언제 도착해?”라고하면 앞에서 조회한 주문과 연결해야한다.

Memory는 이런 세션 안의 대화 맥락과 여러 세션에 걸쳐 유지할 정보를 다룬다. 단기 기억과 장기 기억은 사용 목적이 다르다. [Memory 동작 설명](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html)

그런데 대화를 저장하는것과 모델을 다시 학습시키는것은 다르다. 저장한 정보를 필요한 시점에 찾아서 맥락으로 전달하는 구조를 구분해서 봐야한다.

기억할 수 있다고 모든 내용을 오래 저장하는것도 좋은 방법은 아닐것 같다.

1. 이번 대화에서만 필요한 정보인지 확인한다.
2. 다음 대화에서도 사용할 정보인지 구분한다.
3. 사용자별로 조회 범위를 나눈다.
4. 오래되거나 잘못 저장된 정보를 정리할 방법을 둔다.

특히 배송 상태처럼 바뀌는 정보는 예전 대화를 기억하는것만으로 답하면 안된다. 기억은 사용자가 무엇을 물어봤는지 이해하는데 쓰고, 현재 상태는 주문 서버에서 다시 확인하는게 맞다.

# 4. 실패했을때 무슨 일이 있었는지 알아야한다

일반적인 API는 요청과 응답을 따라가면 흐름이 비교적 분명하다. Agent는 중간에 어떤 도구를 선택했는지, 몇번 호출했는지까지 봐야할때가 있다.

예를 들어 사용자는 답변이 느리다고하는데 원인이 모델인지 외부 API인지 바로 알기 어려울 수 있다.

```text
질문 처리 시작
 → 모델 응답 대기
 → 주문 API 호출
 → 타임아웃
 → 재시도
 → 최종 답변 생성
```

이런 흐름을 확인하려면 요청과 세션을 구분할 식별자, 도구 호출 시간, 성공 여부 등을 연결해서 남겨야한다.

그리고 재시도는 생각보다 조심해야한다. 조회는 다시 해도 괜찮을 수 있지만 주문 취소나 환불처럼 상태를 바꾸는 작업은 같은 요청이 두번 처리되면 문제가 된다.

이때는 작업 식별자로 중복 실행을 막거나 실행 전에 확인 단계를 두는 식으로 설계해야한다. AgentCore를 쓴다고 이런 업무 규칙까지 자동으로 생기지는 않는다.

운영 도구의 가치는 실행 과정을 볼 수 있게 해주는 데 있고, 무엇을 성공으로 볼지는 개발자가 정해야한다.

# 5. 그러면 Lambda나 Kubernetes는 필요없어지는건가

기존 환경을 무조건 버릴 필요는 없다. 이미 짧은 작업을 Lambda로 잘 처리하고 있거나 조직에 Kubernetes 운영 체계가 있다면 그걸 활용하는 선택도 가능하다.

비교할 부분은 Agent를 올릴 수 있느냐보다 **Agent 운영 때문에 새로 만들어야하는것이 얼마나 많은가**인것 같다.

- 실행 환경만 필요한가, 기억과 외부 서비스 인증도 필요한가?
- 세션별로 분리해야할 상태가 있는가?
- 브라우저나 코드 실행처럼 별도 격리가 필요한가?
- 지금 운영 방식보다 문제를 추적하기 쉬워지는가?

관리형 기능을 사용하면 직접 운영하는 범위를 줄일 수 있다. 대신 서비스의 제약과 비용 구조를 알아야하고, 다른 환경으로 옮길때 필요한 작업도 생각해야한다.

지금은 Preview 단계라 필요한 기능이 제공되는지도 확인해야한다. 예를 들어 VPC 전용 연결은 아직 제공 예정으로 안내되어있다. 실제 환경에 붙이기 전에 이런 제약부터 살펴보는게 좋겠다.

# 마무리

개인적으로 이번 발표에서 눈에 들어오는건 Agent를 만드는 과정 다음의 문제를 다루기 시작했다는 점이다.

모델이 답변을 잘하는지도 중요하지만 서비스에서는 누가 어떤 권한으로 실행했고, 무엇을 기억했고, 실패했을때 어디서 막혔는지도 알아야한다.

처음 검토한다면 주문 조회처럼 읽기 작업 하나로 시작해서 사용자 분리, 대화 유지, 도구 실패 처리까지 확인해보면 좋겠다. 기능이 작아도 실제로 운영할때 필요한 조건을 같이 넣어보는것이다.

Agent 예제는 금방 만들 수 있어보이는데 운영까지 생각하면 확인할게 정말 많다.. 결국 관리형 서비스를 선택하는 기준도 우리 서비스에서 반복되는 일을 얼마나 줄여주는지에 달려있는것 같다.


[2025.07.18 주간 개발 트렌드] Amazon Bedrock AgentCore 정리 (Agent 실행, 기억, 권한 관리)

독자의 메모