AI 아키텍처 기술 블로그

많은 조직이 이슈 트래커 (Issue Tracker)에 매일의 업무 흔적을 남깁니다. 이슈가 생성되고, 상태가 바뀌고, 담당자가 배정되고, 코멘트와 작업 시간이 기록됩니다. 그런데 정작 "지난 한 주 동안 우리 팀이 무엇을 했는가"를 한 장으로 정리하려고 하면, 사람이 화면을 열어 필터를 걸고 숫자를 손으로 옮겨 적습니다. 매일 반복되는 이 작업은 지루할 뿐 아니라, 사람마다 집계 방식이 달라 숫자가 미묘하게 어긋납니다.이 글은 이슈 트래커를 MCP (Model Context Protocol) 호환 브리지로 AI Agent에 연결하고, 활동 데이터를 수집·집계해 신뢰할 수 있는 운영/경영 리포트를 자동 생성한 경험을 일반화해 정리합니다. 핵심은 "API를 호출해 데이터를 긁어오는 것"이 아니라, 그 숫자..

기업용 AI 백엔드는 한 언어로만 만들어지지 않는 경우가 많습니다. 인증과 테넌트 정책을 담당하는 Java 17 / Spring Boot 기반 Security Gateway가 앞에 있고, Agent·RAG·모델 조율을 담당하는 Python / FastAPI 기반 Orchestrator가 뒤에 있는 구조를 종종 사용합니다. 이 두 서비스의 책임을 어떻게 나눌지는 이미 별도 글(Java Security Gateway와 Python AI Orchestrator의 책임 분리)에서 다뤘습니다.이 글은 그 다음 질문을 다룹니다.두 서비스가 서로 다른 언어로 짜여 있는데, 같은 토큰·같은 서명·같은 해시를 정말 똑같이 계산하고 있다는 것을 어떻게 증명하는가?책임 분리는 설계 문제이지만, 이 질문은 정확성 (Corre..

AI 에이전트에게 지식을 주는 방법은 하나가 아닙니다. 사내 회의 녹취를 검색 가능한 지식으로 만드는 파이프라인은 이전 글에서 다뤘습니다(회의 오디오 → RAG). 이 글은 성격이 전혀 다른 지식원, 즉 공개 웹 문서를 대상으로 한 검색 증강 생성 (Retrieval-Augmented Generation, RAG)을 다룹니다.이 글은 구현 회고가 아니라 설계 가이드입니다. 아래에 나오는 코드는 대부분 개념을 보여주기 위한 개념 코드이며, 특정 버전·실행 환경에서 측정한 검색 품질·성능 수치를 제시하지는 않습니다. 대신 "공개 웹을 지식원으로 붙일 때 무엇을 어떻게 결정해야 하는가"에 대한 설계 지침에 집중합니다.제안하는 파이프라인의 골격은 이렇습니다. 공개 웹 페이지를 수집(Crawl)하고, 본문을 추출..

검색 증강 생성 (Retrieval-Augmented Generation, RAG)에서 청킹 (Chunking, 문서를 검색 단위 조각으로 나누는 작업)은 가장 눈에 띄지 않으면서도 검색 품질에 큰 영향을 주는 단계입니다. 물론 파싱 품질, 원문 데이터, 임베딩, 질의 변환, 하이브리드 검색, 재순위화도 검색 품질을 좌우합니다. 다만 경계에서 손실된 문맥은 후단 검색기만으로 보완하기 어렵다는 점에서, 애초에 어떤 경계로 문서를 잘랐는지는 임베딩 (Embedding) 모델 선택과 함께 설계하되 검색기 (Retriever) 튜닝보다는 먼저 검증해야 하는 결정입니다.영어 중심 자료의 청킹 예제는 대부분 마침표와 공백으로 문장을 나누고 고정 토큰 수로 자르는 방식을 전제합니다. 한국어는 교착어 (Agglutin..

하나의 거대한 AI Agent (AI 에이전트)에게 회의록 검색, 웹 조사, 초안 작성, 사실 검증, 최종 편집을 모두 시키면 초기 개발은 빠릅니다.문제는 이 에이전트에게 붙는 권한이 시간이 지날수록 계속 늘어난다는 점입니다.단일 거대 에이전트가 갖게 되는 권한 → 회의 지식베이스 읽기 → 웹 지식베이스 읽기 → 외부 검색 도구 호출 → 파일 업로드·삭제 도구 호출 → 요약 재생성·저장 도구 호출 → 그리고 위 모든 것을 하나의 System Prompt로 통제권한이 한곳에 모이면 두 가지가 동시에 나빠집니다. 첫째, 프롬프트 한 줄이 오작동하면 그 파급 범위 (Blast Radius)가 모든 도구와 모든 지식베이스로 번집니다. 둘째, "이 작업에는 이 도구가 정말 필요한가"를 판단할 수 있는 ..

회의록 제품에서 가장 자주 오해되는 지점 하나는, "음성 인식만 좋으면 화자 구분도 자연스럽게 따라온다"는 가정입니다.실제로는 그렇지 않습니다. 무엇을 말했는지를 맞히는 문제와 누가 언제 말했는지를 맞히는 문제는 같은 원음에서 출발할 수 있지만, 최적화 목표·출력·평가 지표가 다르며 대개 별도 모듈로 구현되고, 다른 방식으로 실패합니다. 두 결과를 하나의 자막으로 합치려면 별도의 정렬(alignment) 단계까지 필요합니다.이 글은 실시간 STT를 이미 갖춘 시스템에 화자 정보를 붙일 때, 화자 분리(Speaker Diarization)를 하나의 독립된 설계 대상으로 다루는 방법을 정리합니다. 그리고 순수 diarization에 그치지 않고, 익명 화자 라벨을 실제 참석자에 연결하는 화자 귀속(attri..

AI Agent를 처음 만들 때 대부분은 클라우드 LLM API로 시작합니다. 키를 발급받고, SDK를 붙이고, 프롬프트를 넣으면 최신 모델이 응답합니다. 서버도, GPU도, 모델 파일도 필요 없습니다.그런데 그 시스템을 실제 조직에 넣으려는 순간, 기술과는 무관한 질문이 먼저 들어옵니다.회의 녹취록과 계약서 초안이 외부 API로 나가도 되는가?인터넷이 차단된 망분리 (Air-gap) 구간에서도 같은 기능이 동작해야 하는가?트래픽이 늘면 월 API 비용이 예측 가능한 수준으로 유지되는가?특정 국가·산업 규제상 데이터가 국경을 넘어도 되는가?이 질문들의 답은 모델 품질 벤치마크로 결정되지 않습니다. 데이터 주권 (Data Sovereignty), 규제, 망분리 요구, 개인정보·기밀, 지연 (Latency)..

STT(Speech-to-Text, 음성 인식)를 실서비스에 붙이면 가장 먼저 나오는 요구는 대개 하나입니다.“우리 회사 용어를 잘 못 알아들어요. 정확도를 올려 주세요.”이 요구를 “더 큰 모델로 바꾸자”거나 “파인튜닝을 하자”로 곧장 번역하면 대부분 실패합니다. 정확도는 하나의 손잡이가 아니라 여러 계층의 문제이기 때문입니다. 어떤 오류는 입력 오디오 문제이고, 어떤 오류는 파라미터로 해결되며, 어떤 오류는 인식 이후의 텍스트 교정으로만 안전하게 다룰 수 있습니다. 그리고 그중 일부만이 파인튜닝이 필요한 문제입니다.이 글은 인식 후 교정(post-recognition)을 중심으로, 거기서 필요해지는 디코딩 시점 힌트(용어 사전)와 파인튜닝까지 연결해 정확도를 끌어올리는 방법과 도메인 적응(Domain..

AI Agent에게 다음과 같이 요청했다고 가정해 보겠습니다.“지난 회의의 결정 사항을 찾아 후속 업무를 등록해 줘.”Agent는 한 문장을 여러 단계로 실행할 수 있습니다.사용자 요청 → 회의 검색 → 녹취록·요약 조회 → 업무 후보 생성 → 사용자 승인 → 업무 생성 Tool 호출 → Database Commit → 외부 알림 발송운영 중 문제가 생기면 단순한 Application Log만으로는 다음 질문에 답하기 어렵습니다.실제 사용자는 누구였는가?어느 Agent와 Service가 대신 실행했는가?어떤 정책 Version이 Tool 호출을 허용했는가?승인한 내용과 실제 실행 인자가 같았는가?Tool이 성공 응답만..

파일 업로드 기능은 단순해 보입니다.Client가 파일 선택 → Server 또는 Object Storage에 전송 → 업무 Pipeline이 파일 처리하지만 업로드된 파일은 사용자가 보낸 데이터이면서, 동시에 Parser·미리보기·OCR·STT·RAG·변환기 같은 여러 실행 경로를 통과하는 입력입니다.파일 이름과 Content-Type만 믿고 바로 처리하면 다음 문제가 생길 수 있습니다.실행 파일을 문서로 위장확장자와 실제 형식 불일치Parser 취약점을 노리는 조작된 파일악성 Macro·Script·Embedded ObjectZIP Bomb·중첩 Archive로 CPU·Memory·Disk 고갈경로 조작으로 기존 파일 덮어쓰기같은 Presigned URL 재사용검사 이후 같은 Object Ke..