Taxbit Assist: A grounded, role-aware AI agent on Amazon Bedrock AgentCore
Quick Summary
Taxbit Assist는 Amazon Bedrock AgentCore를 기반으로 출처 인용, 사용자 권한 확인, 지역별 데이터 상주 요건을 결합한 제품 지원 AI이며, 개발팀은 답변 신뢰도를 높이기 위해 지식베이스 정제와 검색 개선에 집중했다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약
Taxbit Assist는 Amazon Bedrock AgentCore를 기반으로 출처 인용, 사용자 권한 확인, 지역별 데이터 상주 요건을 결합한 제품 지원 AI이며, 개발팀은 답변 신뢰도를 높이기 위해 지식베이스 정제와 검색 개선에 집중했다.
📌 핵심 요약
- Taxbit은 분산된 제품 지식을 대시보드에서 제공하기 위해 Taxbit Assist를 구축했다. Taxbit 내부 운영 분석에 따르면 Assist에 질문한 사용자 중 55% 이상이 24시간 이내에 다시 질문한다.
- Taxbit Assist는 열람 가능한 출처 제시, 역할·조직별 접근 권한 확인, 세무 조언 제한을 요구사항으로 삼았다. 현재 고객 세무 데이터를 읽을 수 없으며, 쓰기 작업은 호출자 본인의 지원 티켓으로 한정된다.
- Strands Agents SDK 애플리케이션이 Amazon Bedrock AgentCore에서 실행되며, Amazon Bedrock Guardrails의 입력 검사와 개인정보 마스킹, 지식 검색, 모델 추론, 권한 확인, 응답 스트리밍을 연결한다. AgentCore memory는 대화 맥락을 유지하고 OpenTelemetry 추적은 Amazon CloudWatch로 전달된다.
- 검색 품질 개선의 핵심은 마케팅 콘텐츠 제외, 코드에서 생성한 제품 문서와 수작업 콘텐츠 보충, 청크별 제목·적용 범위 추가였다. 검색은 후보 75개를 재정렬한 뒤 상위 12개에서 문서당 청크 2개로 제한하고 최종 5개를 모델에 전달하며, 고객이 열 수 있는 공개 출처만 인용한다.
- EU 배포의 추론은 EU 안에서, US 배포의 추론은 US 안에서 처리하며, BYOK 계정의 대화 기록 등 고객 데이터 저장소는 고객의 AWS KMS 키로 암호화한다. Taxbit은 모델을 학습하거나 미세 조정하지 않으며, Amazon Bedrock도 프롬프트나 완성 응답을 모델 학습에 사용하지 않는다고 설명한다.
🧩 주요 포인트
- 관리형 실행 환경·대화 메모리·세션 격리를 채택해 소규모 팀의 인프라 운영 부담을 줄이고, 제품 지식 검색과 안전성에 개발 역량을 집중했다.
- Cohere Embed English v3의 입력 한도 512토큰에 맞춰 문맥 접두부 약 128토큰과 본문 최대 384토큰을 배분했다. 운영 점검에서 청크 약 28%가 385~512토큰 구간에 있었던 만큼, 적용 범위 보존과 잘림 방지를 함께 고려한 설계다.
- 검색 후보 75개 확보와 재정렬은 벡터 순위 20~50위의 권위 있는 문서를 끌어올리고, 문서당 청크 2개 제한은 출처 편중을 줄인다. 모델이 신원 값을 지정하지 못하도록 도구에 신원을 결합하고 공개 출처만 인용하도록 코드에서 제한해, 권한과 출처 경계를 구현했다.
🧠 상세 정리
1. 분산된 제품 지식과 규제 고객의 요구
2018년 설립된 Taxbit은 거래소, 결제 서비스, 브로커 등이 손익을 계산하고 세무 서류를 수집하며 대규모 정보 신고를 수행하도록 돕는 디지털 자산 세무·회계 규정 준수 플랫폼이다. 대시보드 사용에 필요한 지식은 공개 웹사이트, API 문서, 도움말에 흩어져 있었고 문서로 남지 않은 내용도 상당해, 고객은 양식 상태 같은 질문에도 직접 자료를 찾거나 지원 티켓을 제출해야 했다. Taxbit Assist는 이 지식을 제품 안에서 제공하며, 내부 운영 분석에서는 질문한 사용자의 55% 이상이 24시간 이내에 다시 질문한 것으로 나타났다. 신고 판단에 쓰이는 답변은 사용자가 열람할 수 있는 출처로 추적 가능해야 하고, 모르는 내용은 모른다고 밝혀야 하며, 사용자의 조직과 역할에 맞는 작업만 안내해야 했다. 또한 원가 기준을 계산하는 제품 동작 설명과 어떤 방식을 선택할지 권하는 세무 조언을 구분하고, 단일 코드베이스에서 지역별 데이터 상주와 운영 중 품질 측정을 지원해야 했다.
2. AgentCore 기반 실행 구조와 요청 처리
소규모 개발팀은 에이전트 실행 루프, 대화 상태 저장소, 세션 격리를 직접 구축·운영하는 부담을 줄이기 위해 Amazon Bedrock AgentCore를 선택했다. 관리형 런타임과 내장 AgentCore memory, 세션별 격리를 활용하면서 개발 역량을 검색과 안전성 개선에 집중할 수 있었다. 애플리케이션은 Strands Agents SDK를 사용하는 작은 Python 프로그램으로, 시스템 프롬프트와 모델, 도구 8개로 구성되며 Amazon ECR의 ARM64 컨테이너 이미지로 배포되어 수요에 따라 확장된다. 대시보드의 스트리밍 채팅 API는 검증된 이메일, 조직 ID, 역할과 함께 질문을 전달하고, Amazon Bedrock Guardrails는 개인정보를 마스킹하며 차단된 입력에 대해서는 모델을 호출하지 않는다. 이후 Amazon Bedrock Knowledge Bases에서 후보 문서를 검색·재정렬하고 모델이 검색 내용과 기능·역할 접근 권한을 확인한 뒤 출처 링크가 포함된 답변을 스트리밍한다. AgentCore memory가 여러 차례의 대화 맥락을 유지하며, 모든 요청의 OpenTelemetry 추적은 평가 도구에 연결되는 Amazon CloudWatch로 전송된다.
3. 좁게 제한한 도구와 신원 처리
에이전트의 도구 8개는 지식베이스 검색 1개, 조직의 기능 이용 자격과 사용자 대시보드 역할을 확인하는 접근 검사 2개, 본인 지원 티켓의 생성·조회·수정·종료 도구 4개, 하루보다 세밀한 시각이 필요한 질문을 위한 현재 시각 도구 1개로 구성된다. 현재 버전은 고객 세무 데이터를 읽을 수 없고 제품 지식으로 답하며, 수행할 수 있는 쓰기 작업도 호출자 자신의 지원 티켓으로 한정된다. 보안 설계의 핵심은 모델이 신원 값을 다루지 않는다는 것으로, 이메일과 조직 ID, 역할은 신뢰할 수 있는 호출 서비스가 제공하고 모델에 도구를 노출하기 전에 클로저를 통해 결합한다. 따라서 모델은 권한 검사를 할지 결정할 수 있지만, 검사 대상의 신원을 매개변수로 지정할 수는 없다. 사용자 입력은 경계에서 정제되어 프롬프트 인젝션이 신뢰된 컨텍스트 행을 흉내 내지 못하도록 하며, 모델의 도구 선택과 도구가 사용할 신원 사이에 경계를 둔다.
4. 지역별 추론, 고객 키 암호화와 비용 관리
에이전트는 Amazon Bedrock의 기반 모델을 교차 리전 추론 프로필로 호출하며, 배포 리전에서 도출한 지리적 접두부가 붙은 프로필 ID로 추론 지역을 정한다. 이 방식으로 EU 배포의 추론은 EU 안에, US 배포의 추론은 US 안에 유지한다고 설명하며, 특정 단일 리전 안에서만 추론한다고 주장하는 것은 아니다. BYOK 계정에서는 대화 기록과 그 밖의 고객 데이터 저장소를 고객 소유 AWS Key Management Service 키로 암호화한다. 비용을 파악하기 위해 각 배포는 시스템 추론 프로필을 태그가 있는 애플리케이션 추론 프로필로 감싸며, 모든 모델 호출에 비용 할당 태그를 붙여 AWS Cost Explorer에서 워크로드별로 확인할 수 있게 한다. 지연 시간과 토큰 비용을 줄이는 Amazon Bedrock 프롬프트 캐싱도 사용하며, 모든 요청에서 바이트 단위로 동일한 시스템 프롬프트 끝에 캐시 체크포인트를 둔다. 요청별 컨텍스트는 사용자 메시지에 실어 정적 접두부를 사용자 간에 캐시할 수 있게 하지만, 원문에는 구체적인 비용 절감률이나 지연 시간 개선 수치가 제시되지 않는다.
5. 공개 문서·제품 코드·보완 자료의 수집
지식베이스는 Amazon S3 Vectors를 저장 기반으로 사용하고, Cohere Embed English v3로 생성한 1,024차원 float32 벡터를 코사인 거리로 비교하며, 팀이 별도 벡터 데이터베이스를 운영할 필요가 없는 관리형 구성이다. 수집 자료는 단일 Amazon S3 버킷 안에서 공개 콘텐츠, 제품 코드 기반 문서, 수작업 콘텐츠의 세 종류로 나뉘며, 공개 웹사이트·API 문서·도움말은 예약된 AWS Lambda 함수가 수집한다. 사이트맵의 최종 수정 시각과 콘텐츠 해시를 활용해 변경된 자료만 처리하는데, 사이트맵의 대략 400개 이상 URL 가운데 답변용 자료에 해당하는 것은 약 70개 이상이고 /blogs/에는 마케팅 페이지가 300개 넘게 있었다. 이런 캠페인 자료가 규정 준수 질문에서 도움말과 인용 출처 자리를 다투었기 때문에, 이를 제외한 작업은 모델 변경 없이 얻은 가치 높은 검색 개선이었다. 별도 Lambda 함수는 제품 소스 코드에서 대시보드 경로, 권한 조건, 양식 적격성 로직, 보고 설정을 Markdown 문서로 생성하고, 수작업 기사와 승인된 수정 내용은 자동 수집이 놓친 부분을 보완한다. Amazon EventBridge가 야간·주간 주기를 엇갈리게 예약하고 변경이 있을 때만 인제스트를 실행하며, 수집기 9개는 product-public/, product-internals/, curated/ 접두부에 따라 데이터 소스 3개로 묶인다.
6. 청크마다 적용 범위를 보존한 문맥 보강
검색 시험에서 고정 크기 분할보다 성능이 좋았던 의미 기반 청킹을 선택했지만, 문서 중간의 청크는 문서 전체의 주제나 적용 범위를 잃는 문제가 있었다. 세무 보고에서는 비미국 신고 제도에만 해당하는 문단이 IRS Form 1099 질문에 검색되면 오해를 유발하므로, 적용 범위 자체가 답변의 정확성을 좌우한다. 이를 해결하기 위해 POST_CHUNKING Lambda 사용자 정의 변환으로 각 청크 앞에 문서의 H1 제목과 도입 문단을 붙였고, 이 접두부를 제목 80자와 적용 범위 300자를 기준으로 약 128토큰 이내로 제한했다. Cohere Embed English v3의 입력 한도가 512토큰이므로 본문은 최대 384토큰으로 제한했으며, 운영 점검에서는 청크 약 28%가 385~512토큰 구간에 있어 접두부를 추가하면 끝부분이 조용히 잘릴 수 있는 상태였다고 설명한다. 작성자는 적용 범위가 첫 청크에만 머물지 않고 각 청크와 함께 벡터 인덱스에 들어가게 된 변화를 가장 영향이 큰 검색 개선으로 평가한다. 구현 시 변환용 중간 저장소는 데이터 소스와 별도 버킷이어야 하고 같은 버킷의 다른 접두부는 허용되지 않으며, 기존 데이터 소스에 사용자 정의 변환을 활성화하면 교체가 발생하므로 전체 재수집이 필요하다.
7. 넓게 검색한 뒤 재정렬하고 인용을 제한
질의 시에는 벡터 검색으로 후보 청크 75개를 확보하고, 같은 Retrieve 호출 안에서 서버 측 Cohere Rerank 3.5를 적용해 상위 12개를 추린다. 이어서 원본 문서당 청크를 최대 2개로 제한하고 최종 상위 5개를 모델에 전달해, 많이 분할된 문서 하나가 제공 문맥을 독점하지 않도록 한다. 후보를 넓게 잡는 이유는 권위 있는 문서가 벡터 검색에서는 20~50위에 자주 머물다가 재정렬 후에야 상위로 올라오기 때문이며, 재정렬은 Amazon Bedrock 내부에서 처리되어 별도 서비스 호출 구간을 추가하지 않는다. 답변 근거로 사용하는 자료와 고객에게 인용할 수 있는 자료도 구분하며, 인용 가능 여부는 프롬프트 지시가 아니라 출처 유형을 검사하는 코드로 강제한다. 고객이 실제로 열 수 있는 URL이 있는 공개 웹사이트, API 문서, 도움말만 인용을 허용하고, 코드에서 생성한 문서와 수작업 콘텐츠는 답변의 근거로 활용하되 열 수 없는 링크를 제공하지 않는다. 이 구조는 후보 확보, 순위 개선, 문서 편중 완화, 출처 접근성이라는 서로 다른 문제를 각각 다루지만, 제공된 원문에는 각 단계의 정량적 정확도 개선 결과가 없다.
8. 안전성·준수 체계와 제공된 원문의 한계
Taxbit은 Assist를 AI 관리 시스템 국제 표준인 ISO/IEC 42001에 맞춰 개발·운영한다고 설명하며, 별도로 ISO/IEC 27001과 ISO/IEC 27701 인증 및 SOC 2 Type II 보고서를 보유한다고 밝힌다. 모델을 직접 학습하거나 미세 조정하지 않고, Amazon Bedrock도 프롬프트나 완성 응답을 모델 학습에 사용하지 않는다는 점을 데이터 처리 설명에 포함한다. 원문 마지막의 안전성 절에서는 한 테넌트의 데이터가 다른 테넌트 세션에 들어가지 않게 하는 경계 세 가지를 소개하기 시작하며, 첫 번째로 지식베이스에는 테넌트별 콘텐츠가 없고 공개 문서·코드 기반 제품 참고자료·수작업 기사만 있다고 명시한다. 그러나 제공된 본문은 두 번째 경계를 설명하려는 문장 중간에서 끊겨 있어, 해당 절의 나머지 경계나 후속 결론을 확인할 수 없다. 운영 중 품질 측정은 요구사항으로 제시되고 모든 요청의 추적이 평가 도구에 전달된다는 설명도 있지만, 제공 범위에는 평가 절차나 품질 점수의 상세 결과가 없으며 재질문 비율 55% 이상은 별도의 이용 행태 지표로 제시된다.
🧾 핵심 주장 / 시사점
- 작성자가 가장 영향이 컸다고 평가한 검색 개선은 모델 변경이 아니라 각 청크에 제목과 적용 범위를 보존한 작업이었다. 마케팅 자료 제외 사례도 답변 품질에서 자료의 선별과 문맥 구성이 중요했음을 보여준다.
- 신원을 도구에 미리 결합하고 인용 가능한 출처를 코드로 제한한 설계는 권한과 출처의 경계를 모델의 판단에만 맡기지 않도록 한다.
- 24시간 내 재질문 비율 55% 이상은 반복 사용을 보여주지만, 제공된 원문에는 답변 정확도나 세무 조언 제한의 준수율을 직접 확인할 정량 결과가 없다.
✅ 액션 아이템
- Cohere Embed English v3의 512토큰 한도에 맞춰 문맥 접두부 약 128토큰과 본문 최대 384토큰의 배분 및 잘림 가능성 점검.
- Taxbit Assist의 역할·조직별 접근 권한 확인, 세무 조언 제한, 호출자 본인 지원 티켓에 한정된 쓰기 범위 검증.
- EU·US 배포별 추론 지역과 BYOK 계정의 AWS KMS 키 기반 고객 데이터 암호화 적용 확인.
❓ 열린 질문
- Taxbit Assist의 24시간 내 재질문 비율 55% 이상은 답변의 유용성이나 문제 해결 정도와 어떤 관계가 있는가?
- 검색 후보 75개, 재정렬 상위 12개, 문서당 청크 2개, 최종 5개라는 설정은 검색 품질에 각각 얼마나 기여하는가?
- 청크 약 28%가 385~512토큰 구간에 있었던 상황에서 본문 최대 384토큰 제한과 문맥 접두부 추가는 답변 품질에 어떤 변화를 가져왔는가?