ercan.ai

온콜 에이전트, 8부. 프로덕션: 옵저버빌리티, 평가, 그리고 거짓말하는 날

Thu, 16 Jul 2026 09:00:00 +0200

3부의 인시던트 트리아지 에이전트가 가동된 지 석 달 만에, 실제 인시던트에 대해 확신에 차고 잘 쓰였지만 틀린 진단을 내놓았고, 포스트모템까지 아무도 잡아내지 못했다. 실시간으로 잡아냈을 트레이스가 아직 존재하지 않았기 때문이다. 이것이 이 마지막 편이 실제로 다루는 모든 실패의 형태다. 크래시도 예외도 아닌, 우연히 거짓이었던 그럴듯한 문장. 이 글은 "에이전트가 그렇다고 했다"를 사람이 검증할 수 있는 무언가로 바꾸는 세 가지를 구축하고, 에이전트가 거짓말한 바로 그날을 들여다보고, 1부가 약속한 숫자들에 대해 플랫폼 전체를 채점하며 시리즈를 닫는다.

하이프 이후의 Kiro: AI IDE가 실제로 바꾼 것

Wed, 15 Jul 2026 17:00:00 +0200

Kiro가 정식 출시된 지 8개월이 지난 지금, 오래 살아남은 아이디어는 스펙이었고, 가장 오래 살아남지 못한 부분은 IDE였다. Kiro는 에이전틱 IDE로 출시되었고, 그 세일즈 포인트는 명세 수준에서 작업하고 구현은 에이전트에게 맡긴다는 것이었다. 살아남은 부분은 그 아티팩트다. 코드가 존재하기 전에 사람이 검토하는, 글로 쓰인 의도 진술서 말이다. 조용히 진 부분은 이 일이 벌어지는 곳이 에디터라는 전제였다. Kiro는 GA와 함께 CLI를 출시했고, 헤드리스 모드를 추가했으며, 흥미로운 사용 사례들은 터미널로 옮겨갔다.

Kiro의 GA에 대해서는 작년 말 AWS Monthly (Dec '25): The Kiro Era Begins에서 거리를 두기보다는 열정이 앞선 채로 다룬 적이 있다. 8개월이면 그중 어느 부분이 유효했는지 말하기에 충분한 시간이다.

당신의 AI 파일럿이 구매 절차에서 죽은 이유

Mon, 13 Jul 2026 19:00:00 +0200

파일럿은 잘 작동했다. 그것은 애초에 문제가 아니었다. 데모는 성공적이었고, 정확도는 방어할 만했고, 사용자들도 좋아했다. 그리고 그것은 대기열에서 다섯 달을 보낸 뒤 조용히 언급되지 않게 되었다. 아무도 그것을 죽이지 않았다. 그저 유효기간이 만료되었을 뿐이다. 이런 일을 두 번 겪었다면 아마 조직이 망가졌다고 결론 내렸을 텐데, 나는 덜 만족스러운 설명을 제시하고 싶다. 그 파일럿은 아무도 막혀 있지 않던 질문에 답하도록 설계되어 있었다는 것이다.

데모는 "이 모델이 이 일을 할 수 있는가?"에 답한다. 조직은 그것에 대해 확신이 없었던 적이 없다. 조직이 모르는 것은 모델이 틀렸을 때 누가 책임지는지, 데이터가 어디로 가는지, 갱신 시점에 무슨 일이 벌어지는지, 누가 서명하는지다. 이런 질문들에는 저마다 소유자가 있고, 그 소유자들에게는 저마다 대기열이 있으며, 그중 누구도 당신의 파일럿이 오는 것을 예상하지 못했다.

추론 프로파일로 앱 단위 Bedrock 비용 추적하기

Fri, 10 Jul 2026 14:00:00 +0200

애플리케이션 추론 프로파일은 모델 ARN을 감싼 태그 달린 래퍼이며, 회사 전체를 하나의 숫자로 보여주는 Bedrock 청구서와 당신 사이를 가로막는 유일한 것이다. 모델을 가리키는 프로파일을 만들고, 비용 배분 태그를 붙인 다음, 모델 ID 대신 프로파일 ARN을 호출한다. 태그는 Cost Explorer와 Cost and Usage Report까지 함께 따라간다. 메커니즘은 이것이 전부이며, 반나절이면 끝난다.

반나절이 문제가 아니다. 문제는 태깅 체계가 조직적 약속이라는 점이고, 대부분의 팀은 10분 만에 하나를 정하고 2년을 그것과 함께 산다. 그래서 이 글에서 API는 20분어치이고 태그 설계가 나머지 전부다.

온콜 에이전트, 7부. 사이징: 아무도 미리 하지 않는 토큰 계산

Thu, 09 Jul 2026 09:00:00 +0200

이 플랫폼에서 깊은 인시던트 조사 한 건, 트리아지 에이전트가 진단을 제안할 만큼의 증거를 모으기까지 도구 호출 여덟 라운드는 32,950토큰이 들고, 그중 31,600이 입력이다. Bedrock의 Converse API가 매 라운드마다 계속 자라나는 트랜스크립트 전체를 다시 보내기 때문이다. 여기에 실제 알람 볼륨을 곱하면 플랫폼의 월간 온디맨드 모델 청구서 전체가 약 14달러, 총 월 비용 약 21달러 안에서도 작은 축에 드는 항목이 된다. 1부가 명시적으로 미뤄둔 일, 즉 첫날부터 Provisioned Throughput을 사는 것은 손익분기에 필요한 사용률의 대략 400분의 1로 도는 워크로드에 월 15,768달러를 쓰는 일이었을 것이다. 어느 것도 다이어그램에서는 자명하지 않다. 누군가 산수를 해야만 드러나며, 이번 편이 그 산수를 처음부터 끝까지 한다. 모든 숫자는 Bedrock 가격표나 전체가 공개된 공식으로 추적 가능하다.

EU AI Act, 8월 2일: 밀리지 않은 마감일

Wed, 08 Jul 2026 11:00:00 +0200

AI에 관한 디지털 옴니버스는 헤드라인을 장식한 마감일들은 옮겼지만, 실제로 당신의 빌드에 영향을 미칠 마감일은 그대로 두었다. 고위험 의무는 1년 넘게 미뤄졌다. 제50조 투명성 의무는 미뤄지지 않았다. 이 조항은 2026년 8월 2일부터 적용되는데, 대략 3주 뒤이며, 평범한 팀이 평범한 일을 하다가 걸려드는 조항이다. 모델로 텍스트, 이미지, 오디오를 생성해서 그 결과물을 사람 앞에 내놓는 일 말이다.

안도감 자체는 진짜였고, 팀들이 보도를 읽고 긴장을 풀었던 이유도 이해한다. 다만 그것은 우리 대부분이 가진 것과는 다른 문제에 대한 안도감이었을 뿐이다. Amazon Bedrock 위에서 요약기나 지원 어시스턴트, 콘텐츠 파이프라인을 운영하고 있다면, 미뤄진 것들 중 애초에 당신을 구속할 예정이었던 것은 거의 없다. 당신을 구속하는 것은 그대로 남아있는 것이다.

SageMaker vs Bedrock: 기술적 결정이 아니라 조직적 결정

Mon, 06 Jul 2026 09:00:00 +0200

SageMaker와 Bedrock의 비교는 기술적인 비교가 아니다. 이것은 당신의 조직이 모델을 소유하는 일을 담당하는 사람들을 고용하고 있는지에 대한 질문이다. 모델 아티팩트를 훈련하고, 평가하고, 페이저 당직을 서는 팀이 있다면 SageMaker는 그 팀이 이미 하고 있는 일을 그대로 설명한다. 그런 팀이 없다면, 그리고 AI 기능을 출시하는 대부분의 회사는 그런 팀이 없는데, Bedrock은 타협안이 아니다. 그것은 당신의 조직도를 정확하게 읽어낸 결과다.

이 비교는 보통 기능 매트릭스로 진행된다. 통제권, 토큰당 비용, 모델 선택, 파인튜닝, 지연 시간. 이 항목들은 실재하지만 결국 부차적이다. 이 항목들 각각은 새벽 3시에 누가 그것을 떠맡을지에 따라 다르게 결론이 나는데, 이는 기술적 사실이 아니라 조직적 사실이다.

당신의 문서를 통한 프롬프트 인젝션: RAG의 공격 표면

Sat, 04 Jul 2026 10:00:00 +0200

모델 앞에 검색을 배치하는 순간, 지식 베이스의 모든 문서가 실행 가능한 입력이 된다. 셸의 의미에서 실행 가능하다는 뜻이 아니다. Confluence 페이지에 있는 한 문단이 에이전트의 동작을 바꿀 수 있다는 의미에서 실행 가능하다는 뜻이다. 검색이 그 문단을 가져와 컨텍스트 윈도우에 붙여넣으면, 모델은 시스템 프롬프트와 똑같은 주의력으로 그것을 읽기 때문이다. 팀들은 사용자의 메시지 입력창은 꼼꼼하게 위협 모델링하면서, 정작 여섯 개 시스템에서 4만 페이지를 수집할 때는 누가 그곳에 쓸 수 있는지 묻지 않는다.

M365 Security 101: AI Pilot과 Business Impact Reports

Fri, 03 Jul 2026 13:30:00 +0200

보안 팀에게 부족한 것은 탐지가 아니다. 진짜 문제는 조치와 커뮤니케이션이고, 보안에서 AI가 실제로 제값을 하는 곳도 정확히 이 두 지점이다. 요즘 스캐너는 컴플라이언스 벤치마크 기준으로 800개의 발견 항목을 아무렇지 않게 쏟아낸다. 발견 자체는 어려운 부분이 아니다. 어려운 것은 그 대부분이 끝내 고쳐지지 않는다는 점, 그리고 고쳐진 항목조차 예산을 승인하는 사람들 눈에는 보이지 않는다는 점이다. 이 글은 그 문제를 정면으로 다룬다고 생각하는 두 가지 AI 기능, 승인 게이트를 거치는 자동 조치와 비기술 독자를 위한 AI 생성 리포트에 대한 101 입문이다. Microsoft 365 보안 플랫폼인 Aether365를 예시로 사용한다. 미리 밝혀두면 Aether365는 내 제품이다. 논거는 논거 자체로 판단하기 바란다.

온콜 에이전트, 6부. 가드레일: 모두가 건너뛰는 부분

Thu, 02 Jul 2026 09:00:00 +0200

모든 에이전트 호출에 붙는 Bedrock Guardrail은 IAM이 전혀 볼 수 없는 세 가지를 잡는다. 로그 라인 안에 숨겨진 프롬프트 인젝션 지시, 모델이 요약하기 전에 도구 결과로 도착하는 고객 PII, 그리고 사람을 승인 게이트 건너뛰기 쪽으로 몰아가는 에이전트 자신의 텍스트다. 어느 것도 접근 제어 문제가 아니므로, 2부에서 4부까지 아무리 신중하게 범위를 지정했어도 어떤 IAM 정책에도 나타나지 않는다. 이번 편은 그 가드레일을 terraform/30-guardrails/에서 테라폼으로 구축하며, 데모하기 좋은 부분보다 이것이 잡지 못하는 것에 더 많은 시간을 쓴다. 그 둘 사이의 간극이 정확히 인시던트가 엇나가는 지점이기 때문이다.

모델은 신뢰하되, 바이너리는 감사하라

Thu, 02 Jul 2026 03:30:00 +0200

코딩 에이전트의 클라이언트 바이너리는 당신의 머신에서 가장 높은 권한을 가진 소프트웨어이며, 이를 감사하는 사람은 거의 없다. 그것은 당신의 리포지토리를 읽고, 셸을 실행하며, 자격 증명을 쥐고 있고, 당신이 통제할 수 없는 일정으로 자동 업데이트된다. 우리는 모델 정렬(alignment)을 두고 논쟁하는 동안 그 바이너리를 지루한 배관 정도로 취급하기로 집단적으로 결정해 버렸다. 지난주 Claude Code는 그것이 정확히 거꾸로 된 판단임을 보여주었다. 약 3개월 동안 이 도구는 중국 연계 프록시를 거쳐 라우팅된 요청을 분류하고, 그 결과를 자신의 시스템 프롬프트 안에 스테가노그래피 방식으로 인코딩하는 숨겨진 로직을 배포해 왔다. 한 개발자가 바이너리를 디컴파일하기 전까지 아무도 알아채지 못했다.

AWS 먼슬리 (2026년 6월): 에이전트가 피드백 루프를 얻다

Tue, 30 Jun 2026 18:00:00 +0200

2026년 6월은 AWS가 에이전트 기능을 계속 내놓는 대신 그 기능을 개선하는 루프를 내놓기 시작한 달이었다. 6월 17일 뉴욕 서밋이 그 중심이었다. AgentCore는 프로덕션 트레이스를 읽어 에이전트가 무엇을 잘못하고 있는지 알려주는 최적화 기능을 얻었고, Web Search가 정식 출시됐고, 관리형 하네스는 하루 뒤 GA에 도달했고, AWS Continuum이 권한을 가정하는 대신 얻어내는 AI 네이티브 보안 서비스로 등장했다. 같은 달 다른 곳에서는 Anthropic이 Claude Fable 5를 출시했다가 수출 통제 지시로 잃었고, 프런티어 모델 위에 무언가를 짓는 모든 이에게 공급망에 관한 불편한 사실 하나를 가르쳐줬다.

온콜 에이전트, 5부. 팀: 수퍼바이저와 스페셜리스트 셋

Thu, 25 Jun 2026 09:00:00 +0200

4부가 에이전트 하나로 끝난 자리에 이제 네 개가 존재한다. 수퍼바이저, 런북 에이전트, 비용 에이전트가 인시던트 트리아지에 합류하며, 이들은 한 프로세스 안의 파이썬 함수 호출이 아니라 AgentCore Runtime 자체의 InvokeAgentRuntime API로 조율된다. 넷 모두 여전히 분리되고 격리된 Runtime 리소스로 배포되기 때문이며, 애초에 3부가 AgentCore Runtime을 선택한 이유였던 바로 그 격리다. AWS 리소스 하나가 더 이들을 묶는다. 액터 ID로 넷이 공유하는 단일 AgentCore Memory 인스턴스로, 트리아지가 새벽 3시에 기록한 진단이 몇 초 뒤 인계받는 런북 에이전트에게도, 다음 달 이번 것과 비슷한 모양의 인시던트를 들여다보는 어떤 에이전트에게도 여전히 읽을 수 있는 상태로 남는다.

AWS가 AI 생성 코드를 위한 sandbox를 만들었다: Lambda MicroVM

Tue, 23 Jun 2026 02:00:00 +0200

AWS Lambda MicroVM은 AWS의 표현을 그대로 빌리자면, 사용자나 AI가 생성한 코드를 격리되고 상태를 유지하는 환경에서 실행하기 위해 만들어진 새로운 서버리스 프리미티브다. 여기서 주목할 단어는 바로 두 번째 단어다. 이 출시는 사실 함수에 관한 것이 아니다. AI agent가 방금 작성한 코드를 안전하게 실행할 공간을 제공하는 것이 핵심이며, AWS가 "사용자나 AI"를 앞세웠다는 사실이 이 기능이 누구를 위한 것인지 말해준다.

agent를 만들어 본 사람이라면 이미 이 벽에 부딪쳤을 것이다. 모델이 코드를 작성하면, 그 코드를 어딘가에서 실행해야 한다. 신뢰할 수 없는, 모델이 생성한 코드를 자신의 인프라에서 실행하는 것은 누구나 과소평가하는 부분이며, 바로 그 부담을 덜어주도록 MicroVM이 설계되었다.

멀티 에이전트 시스템의 진짜 한계는 분당 토큰 수다

Sun, 21 Jun 2026 16:00:00 +0200

Amazon Bedrock가 이제 표준 AWS Service Quotas 콘솔에서 Mantle 엔드포인트의 분당 토큰 수 할당량을 노출한다. 모델별 input-tokens-per-minute와 output-tokens-per-minute 한도를 직접 읽을 수 있고, AWS의 다른 모든 항목에서 이미 사용하던 동일한 워크플로로 증액을 요청할 수 있다. 사소한 콘솔 변경처럼 들린다. 하지만 멀티 에이전트 시스템을 운영 환경에서 돌리는 사람에게 이것은 용량을 미리 계획하느냐, 아니면 429의 벽으로 그것을 발견하느냐의 차이다.

핵심을 다시 정리하면 이렇다. 에이전트형 워크로드에서는 분당 요청 수가 아니라 분당 토큰 수가 진짜 확장 한계다. 대부분의 팀은 데모에서는 멀쩡히 돌아가던 agent 함대가 실제 트래픽에서 throttling을 당하기 시작할 때까지 이 사실을 체득하지 못한다. 이제 그 숫자가 보이게 되었으니, 할 일은 그것을 갑작스러운 사고가 아니라 용량 계획처럼 다루는 것이다.

에스토니아가 AI 에이전트에게 ID를 부여한다. 그것은 쉬운 부분이다

Sat, 20 Jun 2026 16:00:00 +0200

에스토니아는 AI 에이전트에게 공식 디지털 신원, 즉 "AI ID 코드"를 발급하려 한다. 크리스텐 미할(Kristen Michal) 총리실은 그 목표가 AI로 하여금 "명확하게 정의된 한계 안에서, 검증 가능하고 감사 가능한 방식으로 사람, 기업 또는 조직을 대신하여 행동"하게 하는 것이라고 밝혔다. 만약 실제로 출시된다면 에스토니아는 AI 에이전트에게 국가가 인정하는 신원을 부여하는 최초의 국가가 된다. 이는 진정으로 유용한 조치이며, 동시에 쉬운 부분이기도 하다. 어려운 부분은 그 ID가 담아야 할 모든 것이다.

나는 실제 자격 증명을 보유한 에이전트를 다루며 시스템을 만든다. 그래서 내 반응은 "이게 디스토피아인가"보다는 "그 ID가 실제로 무엇을 묶어야 하는가"에 가깝다. 식별자 그 자체는 숫자에 불과하다. 그것을 의미 있게 만드는 것은 거기에 붙이는 것이다. 권한, 위임 체인, 그리고 책임. 이를 잘못 다루면 매우 공식적으로 보이는 기본 키(primary key)를 출시한 셈이 된다.

Le Chaton Fat: 존재한 적 없는 가장 뚱뚱한 AI 모델

Thu, 18 Jun 2026 11:00:00 +0200

검색하실 수고를 미리 덜어드리죠. Le Chaton Fat라는 모델은 없습니다. 가중치도, API도, 벤치마크도 없습니다. 유출도 아니고, 로드맵도 아니고, Mistral 제품도 아닙니다. 그냥 농담입니다. 그런데 지난 며칠 동안 이 농담은 AI 커뮤니티가 오랜만에 자기들끼리 주고받은 농담 중 가장 웃긴 농담이 되어버렸습니다.

몇몇 분이 진심으로 다운로드 링크를 찾아 헤맸다는 걸 알게 됐기에, 이 드립은 제대로 한번 정리해 둘 가치가 있다고 봅니다. 그래서 존재한 적 없는 가장 뚱뚱한 모델에게 무슨 일이 벌어지고 있는지 풀어보겠습니다.

온콜 에이전트, 4부. 도구와 Gateway: MCP, 허용 목록, 기본값은 읽기 전용

Thu, 18 Jun 2026 09:00:00 +0200

이제 도구 네 개가 각 에이전트마다 파이썬 함수를 하나씩 배선하는 대신 하나의 AgentCore Gateway 뒤에 놓인다. cloudwatch-read, logs-read, cost-read는 스포크 계정에서 읽기 전용 역할을 어썸하며 무엇도 변경할 수 없고, 플랫폼의 유일한 변경 도구인 ssm-execute조차 스포크에 직접 닿지 못한다. 사람의 Slack 승인을 기다리며 멈추는 Step Functions 실행을 시작할 수 있을 뿐이다. 그 멈춤은 UI를 위한 장식이 아니다. 스포크 계정에서 무언가를 바꿀 수 있는 AWS 자격 증명이 발급되는 유일한 지점이며, 사람이 승인을 클릭한 뒤에만 발급된다.

AI 코딩 에이전트에게도 스테이징 환경이 필요하다

Fri, 12 Jun 2026 09:00:00 +0200

팀이 사람을 위해 만들어둔 환경 원칙은 코딩 에이전트에도 그대로 적용되지만, 대부분의 팀은 에이전트가 쓸 만해지는 순간 그 원칙 전부를 조용히 내려놓았다. 신입에게 첫날부터 프로덕션 근처에도 못 가게 했을 조직이 정작 에이전트에게는 장기 유효 자격 증명 하나와 작업 설명 한 줄을 쥐여준 뒤, 있어서는 안 될 것이 빠졌을 때 놀란 척한다.

이 글의 주장은 일부러 재미없다. 에이전트는 유별나게 빠르지만 조직적 판단력은 전혀 없는 기여자이며, 환경 사다리는 정확히 이런 기여자를 위해 존재한다. 개발, 스테이징, 프로덕션, 각 단계 사이의 게이트. 이건 애초에 사람에 관한 이야기가 아니었다. 언제나 피해 범위에 관한 이야기였다.

온콜 에이전트, 3부. 첫 번째 에이전트: Strands로 만드는 인시던트 트리아지

Thu, 11 Jun 2026 09:00:00 +0200

이 시리즈에서 처음으로 실제로 동작하는 에이전트는 약 260줄의 파이썬으로 되어 있다. Strands Agent 하나, boto3를 호출하기 전에 크로스 계정 IAM 역할을 어썸하는 읽기 전용 도구 두 개, 그리고 모델이 실제로 확인하지 않은 것을 자신 있게 말하지 못하게 막는 것이 유일한 임무인 시스템 프롬프트다. 아직 AgentCore Gateway도, 수퍼바이저도, 다중 에이전트 핸드오프도 없다. 그것들은 이후 편에서 다룬다. 이번 편은 디버깅을 어렵게 만드는 무언가를 더하기 전에, 에이전트 하나가 일 하나를 제대로 하도록 만들어 AgentCore Runtime에 배포하는 것이 전부다.

CI 안의 Claude Code: 에이전트에게 빌드 수정을 맡긴다는 것

Mon, 08 Jun 2026 14:00:00 +0200

CI에 코딩 에이전트를 넣는 일은 생산성이라는 옷을 입은 권한 설계 문제다. 메커니즘 자체는 오후 한나절이면 끝난다. 헤드리스 모드는 2025년 9월 Claude Code 2.0부터 제공됐고, anthropics/claude-code-action@v1은 이 전체 과정을 GitHub Action 하나로 감싸준다. 점심 먹기 전에 풀 리퀘스트에 댓글을 다는 에이전트를 만들 수 있다. 그 에이전트에게 커밋을 푸시하게 할지는 전혀 다른 질문이고, 유일하게 중요한 질문이기도 하다.

이걸 안전하게 지키는 규칙은 단순하다. CI 안의 에이전트는 제안만 하고, 병합은 하지 않는다. 아래에 나오는 패턴들은 모두 이 선을 어디에 긋느냐의 변주일 뿐이다.

온콜 에이전트, 2부. 기반: 토큰보다 테라폼이 먼저다

Thu, 04 Jun 2026 09:00:00 +0200

1부에 나온 에이전트 4개 중 어느 것이든 로그를 들여다보거나 워크로드 비용을 산정하거나 수정안을 제안하려면, 이 플랫폼에는 먼저 계정 경계와 두 개의 IAM 역할이 있어야 한다. "기본값은 읽기 전용"이라는 원칙을 시스템 프롬프트의 약속이 아니라 AWS가 강제하는 속성으로 만드는 역할이다. 그 경계, 누군가 데모를 계획하기 며칠 전에는 이미 끝나 있어야 하는 모델 접근 신청, 그리고 온디맨드와 프로비저닝드 처리량과 크로스 리전 추론 프로필 사이의 선택. 이 세 가지가 이번 편에서 만들어지며, 에이전트 코드 한 줄이 존재하기 전에 전부 테라폼으로 구축된다.

컨텍스트 윈도우는 당신 편이 아니다

Wed, 03 Jun 2026 10:00:00 +0200

큰 컨텍스트 윈도우는 용량 한계일 뿐, 검색 전략이 아니다. 모델이 수십만 토큰을 받아들인다는 사실이 그것을 고르게 주의를 기울여 읽는다는 뜻은 아니며, 그만큼을 돈을 내고 보내야 한다는 뜻은 더더욱 아니다. 위치와 길이를 측정한 롱 컨텍스트 벤치마크는 하나같이 같은 말을 한다. 입력이 커질수록 정확도는 떨어지고, 프롬프트 중간에 묻힌 근거는 가장 적게 쓰인다.

새겨야 할 재구성은 이것이다. 컨텍스트 윈도우는 조회하는 데이터베이스가 아니라 써버리는 예산이다. 이를 저장소로 취급하는 팀은 자신이 건너뛴 검색 파이프라인보다 느리고 비싸고 부정확한 시스템을 만들게 된다.

AWS 월간 정리 (2026년 5월): 에이전트가 지갑을 얻다

Sun, 31 May 2026 19:00:00 +0200

2026년 5월은 AWS가 에이전트에게 지갑을 쥐여주고, 그것을 만드는 도구 체인을 강화한 달이었다. 헤드라인은 프리뷰로 나온 Amazon Bedrock AgentCore Payments였다. 에이전트가 자신이 사용하는 API, 콘텐츠, 서비스에 대해 스스로 비용을 지불할 수 있는 첫 관리형 방법이다. 그 주변에서 AWS는 Agent Toolkit for AWS를 출시했고, 관리형 Model Context Protocol 서버를 정식 출시로 승격시켰다. 둘 다 AI 코딩 에이전트가 AWS 위에서 더 적은 오류와 더 촘촘한 통제로 빌드하도록 만드는 데 목표를 두고 있다. 함께 놓고 보면 이번 달은 에이전트 이야기가 "추론할 수 있는가"에서 "거래할 수 있는가, 그리고 그것을 만드는 도구들을 신뢰할 수 있는가"로 옮겨가고 있다는 메시지를 던진다.

온콜 에이전트, 1부. 시나리오: 운영팀이 에이전트를 채용하는 이유

Thu, 28 May 2026 09:00:00 +0200

엔지니어 약 50명이 AWS 계정 약 30개에 걸쳐 일하는 중견 B2B SaaS 기업에서는 매주 약 40건의 온콜 페이지가 발생하고, 담당자가 실제 답을 얻기까지는 어느 계정인지, 어느 대시보드인지, 어느 런북인지, 그 런북이 아직도 맞는 내용인지를 수작업으로 확인하는 데만 25분에서 35분이 걸린다. 이것은 진단이 시작되기 전 단계이지, 진단을 대체하는 것이 아니다. 이 시리즈는 그 해결책을 만든다. 이 첫 단계를 자동으로 처리하고, 허용된 범위 안에서 모든 것을 읽되, 사람의 승인 없이는 아무것도 바꾸지 않으며, 그 규율을 잃는 순간 쓸모를 잃는 작은 AI 에이전트 플랫폼이다.

개인정보를 남기지 않고 프롬프트 로깅하기

Wed, 27 May 2026 14:00:00 +0200

프롬프트를 로깅하지 않고는 LLM 애플리케이션을 디버깅할 수 없고, 그 프롬프트가 이름, 이메일, 계좌번호로 가득하다면 그대로 보관할 수도 없다. 사용자는 개인 식별 정보를 입력창에 그대로 타이핑하므로, 잘못된 응답을 이해하는 데 도움을 주는 로그는 동시에 잘못된 보존 기간과 잘못된 접근 통제로 CloudWatch나 S3에 앉아 있는, 점점 커지는 규제 대상 데이터 저장소이기도 하다. 해법은 로깅을 멈추는 것이 아니다. 저장 전에 마스킹하고, 남는 것에는 보존 정책을 두어 디버깅 가치는 살아남고 부채는 남지 않도록 하는 것이다.

지금

Mon, 25 May 2026 10:00:00 +0200

(마지막 업데이트: 2026년 5월)

글쓰기

AI, LLM, 응용 ML에 관한 필드 노트를 이곳에 게시하고 있습니다. 클라우드 및 플랫폼 엔지니어링 관련 ercan.cloud와 짧은 형식의 AI 뉴스 news.ercan.ai도 운영 중입니다. 월간 AWS 뉴스 다이제스트인 awsmonthly.cloud를 구축 중입니다 (아직 출시 전).

컨설팅

AI 및 응용 ML 분야에서 소수의 컨설팅 계약을 진행 중입니다. Bedrock 아키텍처, LLM 비용 최적화, 에이전트 파이프라인 설계, 임시 AI 플랫폼 리드. 개발 중인 내용이 제 글쓰기 주제와 겹친다면 LinkedIn으로 연락 주세요.

개발

에이전트 도구 사용 패턴, 대규모 Bedrock 가드레일, RAG를 위한 S3 Vector Search를 실험 중입니다. LLM 워크로드의 비용 최적화는 반복되는 주제로, 대부분의 팀이 인지하지 못한 채 60-90%를 과도하게 지불하고 있습니다.

Consulting & Advisory

Sun, 24 May 2026 10:00:00 +0200

Maenyeon jeogeun sueui keonseolting peulojegteureul matseupnida. I ireul jeulgipe nida. Silje peurodeoksyeon jegake deureo iseul su itgo, geuge baro yuyeonghan paeteoni taeeonaneun gosipnida. Modeun peulojegteuga i saiteuui geulreul mandeulgo, geu geuri dasi peulojegteureul mandeupnida.

Seobiseu

Bedrock mit LLM peulraespeom akipaekpae. Bieo insig peurodeoksyeon LLM weokeurodeureul wihan bijeul. Moel rauting, inpeoreonseu peuropailring, gadeureil seolgye, dari jijeok pailobeo. Infrastructure ga anira gineungeul baehapseupnida.
LLM bieo ceoekeopae. Daebubun tirui Bedrock Knowledge Base, OpenSearch Serverless, mit provisioned throughputeseo gagyeok modeuri jigwanjeogiji anaseo 60-90% deo jibulhago iseupnida. Jeogeun nangbireul cajgo, seutaegeul jaejuseonghaeo bieo daesibodeureul jeongaehapnida.
Eiepaitike pailain seolgye. Cheseeseo eiepanteuro. Tool-use akipaekpae, eiepantu lupeu seolgye, human-in-the-loop cekeupointeu, bigyeoljeongjeog weokeuropeulroeereul wihan teureising mit gamja ganeungseong.
S3 Vectors mit RAG akipaekpae. Neitibeu S3 begteo geomsaek, ceongking jeolyak, imbedding moel seontaeg, geomsaek pyeongga. “Begteo DBman cugahaja"neun bansaneun geonneotwipseupnida.

Je ireul haneun bangsig

Peulojegteu gibaneuro. Teugjeong gineung, pailain tto neun igeoneul gajigo gyesipnida. Gwigui timgwa hamkke guciughago munjanghwawa hamkke soyugwoneul igeonhapnida.

소개

Sat, 23 May 2026 10:00:00 +0200

저는 Ercan Ermis입니다. 네덜란드에 거주하는 시니어 클라우드 플랫폼 엔지니어입니다. AI, LLM, 에이전트 그리고 그것들을 프로덕션에 출시하는 데 필요한 엔지니어링 작업에 대해 여기에 글을 씁니다.

어떻게 여기까지 왔는가

제 인생의 첫 컴퓨터는 1986년 아버지가 사업용으로 구입하신, 5.25인치 플로피 드라이브 두 개(Floppy A와 Floppy B)가 달린 Amstrad였습니다. 진짜 사랑은 1998년 초등학교 4학년 때 시작됐습니다. 학교 컴퓨터실의 Windows 95 머신 중 한 대에 선생님이 Linux를 설치하시며 “이게 Linux란다, 자유 소프트웨어야"라고 말씀하셨고, 그 검은 화면에 Pac-Man이 등장한 순간 저는 끝이었습니다.

Haiku가 Opus를 이길 때: Bedrock에서의 모델 적정 사이징

Fri, 22 May 2026 11:00:00 +0200

프로덕션 LLM 트래픽의 대부분은 어렵지 않다. 분류, 추출, 짧은 재작성, 라우팅처럼 작고 빠른 모델이 정확하고 저렴하게 처리하는 종류의 작업이다. 그런데도 흔한 패턴은 모든 호출을 사용 가능한 가장 큰 모델에 연결하는 것이다. "그냥 되니까"라는 이유로 말이다. 그러고는 왜 청구서와 지연 시간이 둘 다 높은지 의아해한다. Amazon Bedrock에서는 Claude Haiku 4.5와 Claude Opus 4.5를 둘 다 쓸 수 있으며, 엔지니어링에서 이기는 방법은 둘 중 하나를 고르는 것이 아니라 작업 유형별로 라우팅해서 저렴한 모델이 다수를 처리하고 비싼 모델은 기본값이 아니라 에스컬레이션 경로가 되게 하는 것이다.

에이전틱 RAG는 대부분 필요 없는 지연 시간이다

Mon, 18 May 2026 16:00:00 +0200

에이전틱 RAG는 단일 검색을 루프로 대체한다. 모델이 검색하고, 읽고, 더 필요하다고 판단하고, 다시 검색하고, 이를 만족할 때까지 반복한다. 각 홉은 완전한 모델 왕복에 검색 하나를 더한 것이며, 각 홉이 이전 홉에 의존하기 때문에 순차적으로 진행된다. 대부분의 질문에서 이것은 잘 구성된 쿼리 하나면 같은 컨텍스트를 한 번에 얻었을 것을 몇 배의 지연을 치르고 아주 조금 더 나은 답으로 바꿔치기하는 셈이다. 멀티홉 검색은 좁은 부류의 질문에는 진짜 유용한 도구이지만, 그 외의 모든 곳에서는 조용히 응답 시간을 세 배로 만드는 기본값이다.

에이전트보다 먼저 평가: 점수를 매길 수 없다면 출시할 수도 없다

Thu, 14 May 2026 13:00:00 +0200

변경이 에이전트를 더 낫게 만들었는지 더 나쁘게 만들었는지에 숫자를 매길 수 없다면, 우리는 그것을 엔지니어링하는 것이 아니라 절차만 좀 더 붙인 추측을 하고 있는 것이다. 에이전트 프로젝트가 멈추는 가장 흔한 이유는 약한 모델이 아니라 평가 하네스의 부재다. 이것이 없으면 모든 프롬프트 수정, 도구 변경, 모델 교체는 누군가 몇 개의 출력을 눈으로 훑어보고 "더 나아 보인다"고 선언하는 방식으로 평가되며, 이는 회귀를 출시해 놓고 사용자에게서 그 사실을 알게 되는 방식이다. 점수판은 에이전트보다 먼저 존재해야 한다. 왜냐하면 점수를 매길 수 없는 것은 개선할 수도 없기 때문이다.

시맨틱 캐싱: 서로 다른 두 질문, 하나의 답

Mon, 11 May 2026 09:00:00 +0200

시맨틱 캐시는 "비밀번호를 어떻게 재설정하나요"라는 질문에 "로그인을 잊어버렸어요"에 대해 이미 생성해 둔 응답을 돌려준다. 둘이 같은 뜻이기 때문이다. 요청의 정확한 문자열을 매칭하는 대신, 요청을 임베딩하고 저장된 요청 중 임베딩이 충분히 가까운 것을 찾은 다음, 모델을 호출하지 않고 그 캐시된 답을 돌려준다. 잘 작동하면 모델 호출을 통째로 건너뛴다. 토큰도, 지연도, 비용도 없다. "충분히 가까운지"를 잘못 판단하면 사용자가 묻지 않은 질문에 자신 있는 답을 내놓게 된다.

핵심 재구성은 이렇다. 일반 캐시는 동일성으로 키를 잡지만 시맨틱 캐시는 유사도로 키를 잡고, 유사도는 사실이 아니라 우리가 설정하는 임계값이다. 그 임계값이 위험 표면 전체다. 느슨하게 잡으면 틀린 답을 내놓게 되고, 빡빡하게 잡으면 거의 아무것도 캐시하지 못한다. 시맨틱 캐시를 잘 운영하는 일은 전부 이 다이얼을 관리하는 일이다.

Step Functions는 가장 저평가된 에이전트 오케스트레이터다

Thu, 07 May 2026 15:00:00 +0200

사람들이 에이전트라고 부르는 것 대부분은 중간에 한두 번의 모델 호출이 낀 고정된 단계의 나열이다. 제어 흐름은 사전에 알 수 있는데도 팀들은 어쨌든 이를 모델에 넘기고, 비결정적인 루프를 다스리느라 몇 주를 쓴다. 작업의 형태를 이미 알고 있다면 오케스트레이터는 결정적이어야 하며, AWS Step Functions가 직접 짠 에이전트 루프보다 이 작업에 더 적합하다. Step Functions는 재시도, 타임아웃, 오류 처리, 병렬성, 사람의 승인을 이미 해결해 두었다. 바로 에이전트 프레임워크가 우리에게 다시 구현하라고 요구하는 것들이다.

LLM 게이트웨이: 모든 플랫폼 팀이 결국 만들게 되는 이유

Mon, 04 May 2026 10:00:00 +0200

첫 번째 LLM 기능은 하나의 서비스에서 Bedrock으로 직접 호출하는 형태로 출시된다. 열 번째 기능도 같은 방식으로 출시되는데, 열 개의 서비스에서, 열 개의 자격 증명 세트로, 열 개의 재시도 정책으로, 그리고 누가 얼마를 쓰고 있는지 한눈에 볼 수 있는 곳은 어디에도 없다. 바로 그 순간 플랫폼 팀은 LLM 게이트웨이가 필요하다는 사실을 깨닫는다. 보통은 그것을 저렴하게 만들 수 있었을 시점에서 한 분기가 지난 후에야 말이다. 게이트웨이는 모든 모델 호출이 지나가는 공용 정문이며, 각 팀이 계속해서 어설프게 재발명하는 네 가지, 즉 인증, 쿼터, 라우팅, 감사를 소유하기 위해 존재한다.

AWS 월간 브리핑 (2026년 4월): OpenAI가 Bedrock에 상륙하다

Thu, 30 Apr 2026 18:00:00 +0200

2026년 4월은 Amazon Bedrock의 모델 메뉴가 모양을 바꾼 달이었다. 헤드라인은 새로운 AWS 자체 기능이 아니라 새로운 입주자였다. OpenAI의 프론티어 모델, 코딩 에이전트 Codex, 그리고 OpenAI가 구동하는 Managed Agents가 제한적 프리뷰로 Bedrock에 도착했다. 그와 함께 AgentCore는 한 달 내내 아이디어에서 실제로 작동하는 에이전트까지 가는 데 드는 노력을 줄이는 데 힘을 쏟았다. 이 두 이야기를 함께 읽으면 같은 메시지를 전한다. Bedrock은 기업들이 원하는 어떤 프론티어 모델이든 실행할 수 있는 중립적인 장소로 자리매김하고 있으며, AWS는 모델 선택이 유일하게 남은 결정이 될 만큼 주변 개발자 워크플로를 빠르게 만드는 데 총력을 기울이고 있다.

리전 간 추론: 저렴한 복원력인가, 데이터 거주지 함정인가?

Sun, 26 Apr 2026 13:00:00 +0200

Amazon Bedrock 리전 간 추론(cross-region inference)은 라우팅 수수료 없이 더 높은 실질 처리량과 더 적은 리전별 스로틀링 오류를 제공하며, 이는 거의 공짜 복원력에 가깝다. 함정은 글로벌 추론 프로필이 여유 용량이 있는 어느 리전으로든 프롬프트를 보낼 수 있다는 점이며, 그 프롬프트가 규제 대상 데이터를 담고 있다면 "용량이 있는 어딘가"는 컴플라이언스 팀이 받아들일 만한 답이 아니다. 이 기능 자체는 정말 유용하다. 이것이 이득이 될지 위반이 될지는 전적으로 어떤 종류의 추론 프로필을 선택하느냐에 달려 있고, 그 선택은 의미를 읽지 않고도 손쉽게 내려질 수 있다.

LLM 청구서는 관측 가능성 문제다

Tue, 21 Apr 2026 15:00:00 +0200

Amazon Bedrock 청구서가 갑자기 뛰었는데 아무도 어떤 기능 때문인지 말할 수 없다면, 그것은 가격 문제가 아니다. 관측 가능성 문제다. 인보이스는 계정이 토큰에 더 많은 돈을 썼다는 사실만 알려준다. 어떤 에이전트, 어떤 테넌트, 어떤 코드 경로가 그 돈을 썼는지는 알려주지 않으며, 그 귀속 정보가 없으면 비용에 관한 모든 대화는 추측일 뿐이다. 측정할 수 없는 것은 최적화할 수 없는데, 대부분의 팀은 합계만 측정하고 그 아래는 아무것도 측정하지 않는다.

토큰 지출에는 이를 일반적인 클라우드 비용보다 더 까다롭게 만드는 특성이 있다. 비결정적 시스템에 의해 생성된다는 점이다. 프롬프트 변경, 재시도 루프, 수다스러운 에이전트, 혹은 모델을 더 열심히 생각하게 만드는 방법을 찾아낸 사용자, 이 모두가 청구서를 움직일 수 있지만 그 어느 것도 인보이스에 새로운 리소스로 나타나지 않는다. 지출은 단일 Bedrock 항목 안에 숨어 있다. 여러분의 일은 그것이 예상치 못한 방식으로 나타나기 전에 그 항목을 뜯어보는 것이지, 그 이후가 아니다.

Bedrock 배치 추론: 기다릴 수 있다면 반값

Fri, 17 Apr 2026 11:00:00 +0200

Amazon Bedrock은 온디맨드 토큰 가격의 50%로 배치 추론을 실행하며, 여러분이 포기하는 유일한 것은 즉시성뿐이다. 요청 파일을 제출하면 여유 용량이 있을 때 작업이 비동기로 실행되고, 결과는 나중에 수거하면 된다. 사람이 앉아서 응답을 기다리지 않는 워크로드라면, 아무도 필요로 하지 않은 속도를 위해 실시간 추론에 정가를 지불하는 것은 청구서의 절반을 그냥 테이블 위에 남겨 두는 것과 같다.

흔한 실수는 첫 프로토타입이 그렇게 작성되었다는 이유만으로 모든 모델 호출을 동기식 실시간 경로로 기본 설정하는 것이다. 인터랙티브 채팅은 실시간이어야 한다. 어제의 지원 티켓을 분류하는 야간 작업은 그럴 필요가 없다. 이 둘은 서로 다른 지연 시간 요구사항이고, Bedrock은 이를 다르게 가격 매긴다. 엔지니어링 질문은 단순히 어떤 워크로드가 지금 당장 답을 필요로 하고, 어떤 워크로드가 언젠가만 답을 필요로 하는지 가려내는 것이다.

멀티 테넌트 LLM 앱: 공유 모델 위에서 고객을 격리하기

Mon, 13 Apr 2026 16:00:00 +0200

여러 고객이 하나의 Bedrock 모델을 공유할 때, 모델은 어떤 격리도 제공하지 않으며 애초에 그럴 의도도 없었다. 모델은 상태를 갖지 않는 함수다. 같은 입력, 같은 동작, 누가 호출했는지에 대한 기억이 전혀 없다. 테넌트 간의 모든 경계는 모델 주변의 계층에서 직접 구축해야 하며, 모델로부터 기대할 수 없다. 팀들은 이를 거꾸로 이해해서 관리형 서비스가 알아서 분리해 줄 것이라 가정하고, 한 테넌트의 데이터, 비용, 부하가 다른 테넌트로 새어나가는 앱을 그대로 배포한다. 공유 모델 자체는 문제없다. 문제는 그 외의 모든 것을 함께 공유하는 것이다.

에이전트 메모리는 프롬프트 문제가 아니라 데이터베이스 문제다

Thu, 09 Apr 2026 09:00:00 +0200

전체 이력을 다음 프롬프트에 붙여넣는 방식으로 기억하는 에이전트는 메모리를 가진 것이 아니다. 늘어나는 청구서, 단단한 토큰 상한선, 그리고 턴이 거듭될수록 나빠지는 지연 시간 곡선을 가진 것이다. 진짜 메모리는 저장 방식에 대한 결정이다. 무엇을 영구 보관할지, 어디에 둘지, 추론 시점에 관련된 조각만 어떻게 가져올지를 결정하는 것이다. 이것은 데이터베이스 문제이며, 이를 프롬프트 문제로 취급하는 것이 데모에서는 잘 돌아가던 에이전트가 2주차에 무너지는 이유다.

컨텍스트를 그냥 쑤셔 넣는 방식의 유혹적인 점은 처음에는 잘 작동한다는 것이다. 세션 초반에는 이력이 짧아서 모든 것이 들어맞고, 에이전트는 마치 기억하는 것처럼 보인다. 그러다 대화가 길어지면 프롬프트도 함께 커지고, 동시에 세 가지 일이 벌어진다. 매 턴마다 모든 것을 다시 보내야 하니 비용이 오르고, 모델이 매번 더 많이 읽어야 하니 지연 시간이 오르고, 결국 컨텍스트 윈도우에 부딪히면서 오래된 사실들이 조용히 앞에서 잘려 나간다. 이 실패는 패치로 고칠 수 있는 버그가 아니다. 아키텍처 그 자체다.

구조화된 출력이 영리한 파싱을 이긴다

Mon, 06 Apr 2026 14:00:00 +0200

애플리케이션이 여전히 모델의 산문에서 정규식과 재시도 루프로 JSON을 뽑아내고 있다면, 이제 Amazon Bedrock이 디코딩 계층에서 해결해 주는 문제를 붙들고 있는 셈이다. 2026년 2월부터 Bedrock에서 정식 제공되는 구조화된 출력(structured outputs)은 모델이 토큰을 생성하는 동안 JSON Schema에 맞도록 제약을 걸어, 응답이 희망이 아니라 구조 자체에 의해 원하는 형태를 갖추게 한다. 정규식은 애초에 해결책이 아니었다. 모델에게 "JSON으로 반환해 달라"고 부탁만 하고, 그렇게 하지 않았을 때 뒤처리를 하던 증상이었을 뿐이다.

파싱 방식은 드물게 발생하기 때문에 더 골치 아픈 방식으로 실패한다. 응답의 90% 남짓은 정상적으로 파싱된다. 나머지는 JSON을 마크다운 펜스로 감싸거나, 앞에 친절한 문장을 붙이거나, 쉼표를 하나 더 붙이거나, 필드를 환각한다. 그러면 파서는 테스트하지 않은 입력에 대해, 가장 나쁜 타이밍에 프로덕션에서 예외를 던진다. 제약된 디코딩은 이 실패 클래스 전체를 없앤다. 애초에 유효하지 않은 토큰이 생성되지 않기 때문이다.

Bedrock 프롬프트 캐싱: 대부분의 팀이 놓치는 90% 할인

Thu, 02 Apr 2026 10:00:00 +0200

Amazon Bedrock 프롬프트 캐싱은 캐시된 프리픽스를 읽을 때 약 90% 할인된 가격을 제공하지만, 캐시 쓰기는 일반 입력 토큰보다 비싸기 때문에 캐시 히트가 한 번도 일어나지 않으면 청구서는 오히려 더 나빠진다. 이 기능은 2025년 4월부터 정식 출시되었고, 2026년 1월에 도입된 1시간 캐시 지속 시간 덕분에 전체 세션과 배치 작업에도 유용해졌다. 그런데도 대부분의 팀은 여전히 이를 꺼둔 채로 두거나, 엉뚱한 위치에 켜서 조용히 프리미엄을 더 내고 있다. 할인 자체는 실재한다. 그것을 실제로 챙길 수 있는지는 전적으로 캐시 브레이크포인트를 어디에 두느냐에 달려 있다.

AWS 월간 정리 (2026년 3월): 거버넌스가 에이전트를 찾아오다

Tue, 31 Mar 2026 20:00:00 +0200

2026년 3월은 AWS가 에이전트 기능 출시를 멈추고 에이전트 통제 기능을 출시하기 시작한 달이었다. 헤드라인을 장식한 출시는 새로운 모델도 더 화려한 데모도 아니었다. 에이전트가 프로덕션 근처에 가기 전에 필요한, 지루하지만 핵심을 떠받치는 요소들이었다: 인가 레이어, 품질 평가 레이어, 그리고 존재하려면 거버넌스가 필수였던 헬스케어 스택. 이번 달 전반에 걸친 패턴은 모든 기술이 성숙해질 때 겪는 것과 동일하다. 흥미로운 작업이 "그것이 그 일을 할 수 있는가"에서 "그것이 한 일을 증명하고 잘못된 것을 막을 수 있는가"로 옮겨간다.

스트리밍 응답은 성능이 아니라 UX 결정이다

Tue, 24 Mar 2026 15:00:00 +0200

스트리밍은 모델을 더 빠르게 만들지 않는다. 대기 시간을 더 짧게 느껴지게 만들 뿐이다. 응답을 생성하는 총 시간은 스트리밍을 하든 안 하든 거의 동일하다. 스트리밍이 바꾸는 것은 사용자가 첫 토큰을 언제 보느냐이며, 바로 그 숫자, 즉 첫 토큰까지의 시간(time to first token)이 속도에 대한 전체적인 인상을 좌우한다. 스트리밍을 있는 그대로 UX 결정으로 다뤄야, 언제 써야 하고 언제 실제로 해가 되는지 더 나은 판단을 내릴 수 있다.

반사적으로 InvokeModelWithResponseStream이나 ConverseStream을 떠올리는 이유는 스트리밍이 성능적인 선택처럼 느껴지기 때문이다. 하지만 모델은 어느 쪽이든 같은 총 시간에 같은 토큰을 생성한다. 여러분은 처리량을 최적화하는 것이 아니다. 사람이 6초 동안 빈 화면을 바라볼지, 300밀리초 후에 텍스트가 나타나는 것을 지켜볼지를 결정하는 것이다.

Bedrock Agents vs 직접 만든 루프

Wed, 18 Mar 2026 10:00:00 +0200

관리형 에이전트 프레임워크는 속도를 얻는 대신 통제권을 내준다. 그 거래는 어느 날까지는 확실히 가치가 있다. Amazon Bedrock Agents는 추론-행동 루프를 대신 실행해준다: 계획을 세우고, 어떤 도구를 호출할지 결정하고, 호출하고, 결과를 모델에 다시 넣고, 작업이 끝날 때까지 반복한다. 이것은 여러분이 직접 작성하지 않아도 되는 실제 작업이다. 문제는 시간을 절약해주느냐가 아니다. 그것이 감춰주는 부분이 여러분이 안 보고도 넘어갈 수 있는 부분이냐는 것이다.

솔직한 프레이밍은, "직접 만들기"와 "프레임워크 쓰기"가 성숙도의 사다리가 아니라는 것이다. 그것은 루프의 얼마나 많은 부분을 여러분이 통제하느냐와 얼마나 많은 부분을 유지보수하느냐 사이의 트레이드오프다. 어느 쪽이 더 진지하게 들리느냐가 아니라, 여러분의 애플리케이션이 실제로 얼마나 많은 통제를 필요로 하느냐로 선택하라.

LLM 애플리케이션을 위한 IAM: 호출자가 모델일 때의 최소 권한

Sat, 14 Mar 2026 17:00:00 +0200

에이전트는 여러분이 완전히 예측할 수 없는 호출자이며, 바로 그런 호출자야말로 최소 권한을 가져야 한다. 새 에이전트를 만들 때의 본능은 반복 작업을 하는 동안 "일단 돌아가게" 넓은 역할을 부여하는 것이다. 그 본능이 바로 언어 모델이 모든 버킷을 읽고 모든 테이블을 삭제할 수 있는 자격증명을 쥔 채, 공격자가 영향을 미칠 수 있는 텍스트에 의해 움직이게 만드는 방식이다. 최소 권한은 언제나 원칙이었다. 비결정적인 호출자는 그것을 타협 불가능하게 만든다.

사고방식의 전환은 에이전트를 여러분의 코드로 여기는 것을 멈추고, 여러분을 대신해 실행하는 반쯤 신뢰된 행위자로 여기는 데서 시작된다. 여러분의 코드는 여러분이 작성한 대로 동작한다. 에이전트는 모델이 결정한 대로 동작하고, 그 결정은 여러분이 통제할 수 없는 입력에 근거한다. IAM 경계는 "에이전트가 이상한 선택을 했다"와 "에이전트가 관리자 권한으로 이상한 선택을 했다" 사이에 서 있는 것이다.

누군가 antrophic.com을 등록해서 OpenAI로 연결했다

Wed, 11 Mar 2026 12:34:48 +0300

타이포스쿼팅 도메인, 의심스러운 리디렉트, 그리고 우연이라고 하기에는 너무 노골적인 연결.

진짜 도메인은 여기다: anthropic.com. Claude를 만든 AI 안전성 회사로, 전 OpenAI 연구원들이 설립했으며 AI 시스템을 안전하고 해석 가능하게 만드는 정말로 중요한 작업을 하고 있다.

이제 오타를 내보자. 두 번째 "h"를 빼보라. antrophic.com이 나온다. 이 도메인은 존재하고, 등록되어 있으며, 여러 보고에 따르면 openai.com으로 직접 리디렉트된다.

잠시 생각해보라.

curl로 재현하기

특별한 도구는 필요 없다. curl이면 충분하다. 다음은 리디렉트 체인을 드러내는 간단한 HEAD 요청이다:

파인튜닝을 멈춰라. 필요한 건 RAG, 캐시, 그리고 더 나은 프롬프트다

Mon, 09 Mar 2026 11:00:00 +0200

Amazon Bedrock에서 파인튜닝을 검토하는 대부분의 팀에게, 올바른 답은 순서대로 검색, 프롬프트 캐시, 더 나은 프롬프트다. 파인튜닝은 이 세 가지를 다 써본 뒤에 고려할 도구이지, 그 전에 쓸 도구가 아니다. 이것은 이념의 문제가 아니라 청구서의 문제다. Bedrock에서 커스텀 파인튜닝된 모델은 Provisioned Throughput을 통해서만 서빙할 수 있고, 그 가격 모델이 애플리케이션 전체의 경제성을 바꿔놓는다.

파인튜닝은 진지한 선택처럼 느껴진다. 독점 데이터가 있으니 모델이 그것을 "알기를" 원해서 학습을 시킨다. 하지만 사람들이 파인튜닝하려는 대상 대부분은 가중치가 흡수해야 할 지식이 아니다. 추론 시점에 모델에 필요한 컨텍스트고, 따르라고 지시할 수 있는 포맷이며, 애초에 명확하게 작성되지 않았던 지시문이다. 이 셋 모두 더 저렴한 해법이 있다.

Knowledge Base 청킹, RAG 품질이 무너지는 지점

Thu, 05 Mar 2026 14:00:00 +0200

RAG 시스템이 틀렸거나 절반만 맞는 답을 내놓을 때, 대개 그 원인은 모델이 아니다. 청킹이다. 답을 담고 있는 구절이 검색된 컨텍스트에 아예 들어오지 못했다면, 어떤 모델도 그 정보로 답할 수 없다. 프롬프트를 아무리 튜닝해도 바뀌지 않는다. 청킹은 애초에 무엇이 검색될 수 있는지를 결정한다. 그래서 가장 먼저 점검해야 할 것이면서도, 대부분의 팀이 가장 마지막에 들여다보는 것이다.

Amazon Bedrock Knowledge Bases는 데이터 소스를 생성할 때 청킹 전략을 선택하게 한다. 이 단 하나의 선택이 조용히 검색 품질의 상한선을 결정한다. 이걸 잘못 고르면 몇 주 동안 임베딩 모델이나 리랭커, LLM을 탓하며 시간을 쓰게 되는데, 실제 문제는 문서를 어떻게 자르느냐에 있다.

Bedrock Guardrails는 프롬프트 인젝션을 막아주지 않는다

Tue, 03 Mar 2026 09:00:00 +0200

Amazon Bedrock Guardrails는 콘텐츠 필터일 뿐, 보안 경계가 아니다. 주제, 유해성, PII 정책에 따라 텍스트를 분류하고 임계치를 넘으면 차단한다. 고객 지원 봇이 경쟁사를 언급하거나 전화번호를 유출하지 않도록 막는 데는 확실히 유용하다. 하지만 프롬프트 인젝션이 에이전트를 혼란한 대리인(confused deputy)으로 만드는 것을 막지는 못한다. 프롬프트 인젝션은 인가(authorization)의 문제이고, Guardrails는 아무것도 인가하지 않기 때문이다.

팀들이 인젝션 방어로 Guardrails를 떠올리는 이유는 이해할 만하다. 둘 다 "모델에 들어가거나 나오는 나쁜 텍스트"처럼 보이기 때문이다. 하지만 프롬프트 인젝션의 실패 양상은 나쁜 단어가 아니다. 신뢰된 지시문과 신뢰되지 않은 데이터가 같은 컨텍스트 윈도우를 공유하고, 모델이 신뢰되지 않은 데이터가 시킨 그대로 행동하는 것이 문제다. 콘텐츠 분류기로는 이것을 고칠 수 없다. 악의적인 지시문은 대개 지극히 평범한 텍스트처럼 보이기 때문이다.

Amazon Bedrock Knowledge Base 비용 약 90% 절감: OpenSearch Serverless에서 Aurora Serverless v2 + pgvector로 마이그레이션

Sat, 21 Feb 2026 21:30:00 +0300

TL;DR

OpenSearch Serverless (AOSS)로 백엔드를 구성한 Amazon Bedrock Knowledge Base를 운영 중이라면, 단일 문서를 수집하기도 전에 월 약 $700의 기본 비용을 지불하고 있다. 대부분의 소규모 및 중간 규모 RAG 워크로드에서는 AOSS를 Aurora PostgreSQL Serverless v2 + pgvector 확장으로 교체하는 것만으로 이 기본 비용이 월 $50 미만으로, 약 90% 비용 절감 효과를 얻을 수 있다. 동시에 Bedrock Knowledge Base의 완전히 지원되는 1등급 벡터 스토어 지위도 유지된다.

이 글에서는 실제 프로덕션 인프라를 참조 구현으로 삼아, 배경, 계산, 트레이드오프, 그리고 마이그레이션 경로를 단계별로 설명한다.

AWS Monthly (12월 '25): 키로 시대의 시작

Wed, 31 Dec 2025 20:23:45 +0300

Kiro(Frontier Agents)의 정식 출시와 함께 한 해를 마무리했습니다. Kiro는 단순한 챗봇이 아니라 가상 소프트웨어 개발 팀입니다.

기술적으로 Kiro는 자율 코딩 에이전트입니다. Jira에서 티켓을 할당하면 다음과 같이 작동합니다:

Git 저장소에서 컨텍스트를 가져옵니다.
보안 샌드박스에서 구현을 초안합니다.
단위 및 통합 테스트를 실행합니다.
검토를 위해 Pull Request를 제출합니다.

단일 파일뿐만 아니라 전체 코드베이스의 컨텍스트를 이해합니다. 또한 RDS, Aurora, DynamoDB에 걸친 지출을 하나의 유연한 약정으로 통합하는 Database Savings Plans의 출시도 있었습니다.

2025년은 명확한 메시지와 함께 마무리되었습니다: 개발자의 역할이 "코드 작성"에서 "에이전트 의도 검토"로 전환되고 있습니다.

AWS re:Invent 2025: '에이전틱' 시대

Sun, 14 Dec 2025 20:25:19 +0300

2024년이 LLM과 대화하는 해였다면, re:Invent 2025는 LLM이 실제로 일을 하게 만드는 해였다. 가장 중요한 발표들을 종합적으로 정리한다.

1. Amazon Nova 2 모델 패밀리

AWS는 단순히 모델을 업데이트한 것이 아니라, 서로 다른 에이전틱 역할에 특화된 모델 플릿을 구축했다:

Nova 2 Lite: 속도와 비용에 최적화. 18개 벤치마크 중 14개에서 Gemini Flash 2.5와 동등하거나 우월.
Nova 2 Pro: "추론" 중량급. 복잡한 다단계 작업과 장기 계획에 최적.
Nova 2 Sonic: 저지연 대화형 AI를 위한 음성-대-음성 모델.
Nova 2 Omni: 진정한 멀티모달 스타. 텍스트, 이미지, 비디오, 음성을 동시에 처리하며 1M 토큰 컨텍스트 윈도우를 제공.
Nova Act: General Availability. UI 자동화(브라우저 기반 작업)에 특화, 90% 이상의 신뢰도.

2. 커스텀 실리콘: Graviton5 & Trainium3

하드웨어 이야기의 핵심은 비용 대비 성능의 탈동조화였다:

AWS Monthly (2025년 10월): AI 학습의 산업화

Fri, 31 Oct 2025 20:18:03 +0300

10월은 "re:Invent 폭풍 전의 고요"였지만, Project Rainier의 공개를 가져왔다.

Project Rainier는 50만 개 이상의 Trainium2 칩을 탑재한 거대한 AI 컴퓨팅 클러스터다. 기술적으로 이는 현존하는 가장 큰 전용 AI 학습 환경 중 하나다. 우리에게 이는 "AI의 산업화"를 의미한다. Neuron SDK를 통한 Trainium2의 가격 대비 성능 비율은 이제 트랜스포머 워크로드에서 동급 GPU 인스턴스보다 현저히 우수하다.

Amazon Quick Suite도 출시되었으며, 에이전틱 커넥터(Agentic Connectors)를 도입했다. 이 에이전트들은 AWS와 서드파티 SaaS 애플리케이션(DocuSign, Salesforce 등) 사이의 간극을 메워, 커스텀 통합 코드 없이 다단계 비즈니스 로직을 실행할 수 있다.

AWS Monthly (2025년 6월): S3가 당신의 Vector DB가 되다

Mon, 30 Jun 2025 20:08:00 +0300

6월은 Amazon S3 Vector Search의 프리뷰와 함께 AI 데이터 스택에 지각 변동을 가져왔다.

지난 2년간 우리는 Retrieval-Augmented Generation(RAG)을 위해 특수 벡터 데이터베이스(Pinecone, Milvus 등)가 필요하다고 들어왔다. AWS는 그 방정식을 단순화했다: "그냥 S3에 벡터를 저장하세요." 기술적으로 이는 S3 버킷에 네이티브 벡터 인덱싱 레이어를 추가하는 것이다. 객체의 메타데이터로 임베딩을 저장하고 API를 통해 직접 KNN(K-Nearest Neighbor) 검색을 수행할 수 있다.

기능	S3 Vector Search	기존 Vector DB
확장성	네이티브 S3 탄력성	클러스터 기반 프로비저닝
비용	최대 90% 저렴	높은 월간 고정 비용
워크플로우	Zero-ETL	동기화 파이프라인 필요

이는 AI 앱 구축의 "복잡성 세금"을 줄여준다. 더 이상 데이터 레이크를 벡터 DB와 동기화하기 위한 별도 파이프라인이 필요하지 않다. S3는 이제 AI 에이전트를 위한 고성능의 검색 가능한 메모리가 되었다.

AWS Monthly (2025년 2월): 자동화된 코드 진화

Fri, 28 Feb 2025 19:49:00 +0300

2월은 Amazon Q Developer가 단순한 "도우미"에서 "시니어 엔지니어"처럼 행동하기 시작한 달이었다. 가장 큰 헤드라인은 Q 기반 리팩토링의 출시였다.

이는 단순한 코드 자동 완성이 아니다. 기술적으로 Q는 이제 Symbolic AI와 LLM을 결합하여 전체 리포지토리 의존성 매핑을 수행한다. 레거시 Java 8 마이크로서비스를 Java 21로 리팩토링하는 것과 같은 복잡한 마이그레이션을 자율적으로 처리할 수 있다. 더 이상 사용되지 않는 라이브러리를 식별하고, 현대적인 대체제를 제안하며, Hexagonal Architecture와 같은 최신 디자인 패턴에 맞춰 보일러플레이트를 재작성한다.

Q 통합 테스트도 출시되었다. CI/CD 커버리지 리포트를 분석하여 로직의 "사각지대"를 식별한다. 개발자가 수동으로 엣지 케이스 유닛 테스트를 작성하는 대신, Q가 커버리지 목표를 달성하는 데 필요한 정확한 테스트 케이스를 생성한다.