과거에도 지금도 소프트웨어 테스트 하면 떠오르는 말은 “결함 발견”, “품질 보증”입니다.소프트웨어 테스트의 목적은 기능이 잘 동작하는지 확인하고, 문제가 있으면 개발자에게 전달하는 것이 일반적인 역할입니다.하지만 AI 시대에 테스트는 그 의미와 방법이 달라져야 합니다.올해 EuroSTAR, STARWEST 같은 컨퍼런스에서 “AI Test”, “Self-healing Test Automation”, “Model-based Testing”이 주된 주제로 자리잡고 있습니다.Gartner 보고서에서 따르면 “테스트 자동화의 70% 이상이 AI/ML 도움을 받게 될 것”이라고 전망한다고 합니다.테스트 방법도 그렇습니다. 자동화의 대상은 몇 년 전만 해도 UI 자동화 테스트였습니다. 하지만 지금은 상황이 달라졌습니다.화면의 버튼 위치 하나만 바뀌어도 깨져버리는 UI 스크립트는 유지보수 비용이 높고, 서비스 속도를 따라가지 못합니다.대신, API 레벨 테스트와 관측 가능성(Observability)이 주류로 자리잡고 있습니다.UI 테스트는 여전히 필요하지만, “전부 커버”가 아니라 핵심 사용자 플로우만 확인하는 최소화 전략이 일반적입니다.UI 자동화 테스트는 한때 필수적이었지만, 지금은 ROI(투자 대비 효과)가 낮아지고 있습니다.• None 불안정성: 버튼 위치, DOM 구조, 스타일이 바뀌면 스크립트가 쉽게 깨집니다.• None 속도 한계: 브라우저·디바이스 렌더링을 거치기 때문에 CI/CD 파이프라인의 병목이 됩니다.• None 유지보수 비용: UI는 잦은 변경이 발생하는 영역이라, 스크립트 관리가 QA 리소스를 소모합니다.• None 확장성 부족: 모바일, 웹, AI Agent까지 멀티 채널을 지원하는 지금, UI만 검증하는 것은 불완전합니다.• None Google: LLM 기반 제품(Gemini, Bard 등) 검증에 “다양성 테스트”를 도입했습니다. 단일 답이 아니라 여러 맥락에서의 응답 품질을 평가하고, 안전성 필터를 자동화된 테스트 파이프라인에 포함시킵니다. 현재는 UI 테스트를 전체 커버리지로 가져가던 방식에서, 현재는 Critical Path(UI) + 서비스/API 레벨 테스트 조합으로 전략을 변경했습니다. Gmail, YouTube 같은 대규모 서비스에서는 UI 변경이 잦기 때문에, UI 자동화만으로는 유지보수가 불가능했기 때문입니다.• None Meta(페이스북): 앱 UI 변경 주기가 너무 짧아 대규모 UI 테스트를 포기하고, 대신 GraphQL API 레벨 검증을 강화했습니다. 내부 QA팀은 핵심 사용자 시나리오만 UI 테스트로 남기고, 나머지는 API 레벨로 전환했습니다.• None Amazon: “API First” 원칙으로 개발을 진행합니다. 모든 기능은 API 계약부터 설계하고, 이를 바탕으로 자동화된 계약 테스트와 통합 테스트가 이뤄집니다. 쇼핑 서비스 UI가 지속적으로 업데이트되면서, E2E UI 테스트에 집중하기보다 API 계약 테스트와 통합 테스트를 통해 품질을 유지합니다. UI 테스트는 결제, 로그인 같은 주요 플로우만 남겼습니다.• None Microsoft: Copilot 같은 AI Agent 제품에서는 시나리오 기반 테스트와 AI Output Evaluation을 결합합니다. 사람이 직접 평가하는 대신, 메타 모델을 두어 품질을 정량적으로 측정합니다.• None Netflix: Chaos Engineering을 도입해, 운영 환경에서 장애를 인위적으로 발생시켜 복원력을 테스트합니다. 단순 기능 검증이 아니라 서비스 전체 회복성을 QA 범주로 확장한 사례입니다. Chaos Toolkit 을 이용한 카오스 엔지니어링(Chaos Engineering)UI 자동화가 여전히 필요한 경우• None Critical Path 확인: 로그인, 결제, 장바구니 같은 핵심 사용자 플로우는 여전히 E2E UI 테스트로 검증합니다.• None Cross-platform 환경: Android, iOS, Web을 동시에 다루는 경우, 공통된 사용자 경험을 보장하기 위해 최소 UI 자동화는 필요합니다.• None 규제/감사 목적: 금융, 의료처럼 “사용자 행동 시나리오 재현”이 법적 요구사항인 경우에도 수행합니다.이러한 경우는 자동화뿐 아니라 수동테스트로도 UI 테스트는 계속 진행되어야 합니다.• None API / 서비스 레벨 테스트 강화 : 핵심 로직은 API 단에서 검증하고, UI는 최소한의 핵심 시나리오만 커버하는 방식입니다..• None Visual Regression Testing : 픽셀 단위 비교가 아니라 AI 기반 시각 차이 감지 도입합니다. Playwright, Percy, Applitools 툴이 대표적입니다.• None Self-healing Test : AI/ML을 활용해 UI 요소가 바뀌어도 자동으로 locator를 찾도록 하는 기술이 발전.• None Contract Testing : 프론트-백엔드 간 인터페이스 검증을 강화해서 UI 테스트 의존도를 줄이는 흐름.API는 제품의 실제 비즈니스 로직과 데이터 흐름이 구현되는 핵심 계층입니다. 따라서 테스트 관점에서도 API를 중심에 두는 것이 합리적입니다.• None 안정성: UI 변경과 무관하게 API 계약이 유지되면 테스트는 깨지지 않습니다.• None 속도: API 테스트는 UI 대비 수십 배 빠르게 실행되며, CI/CD 파이프라인에 최적화됩니다.• None 확장성: 동일한 API가 웹, 앱, AI Agent에서 재사용되므로, 테스트 범용성이 높습니다.• None 보안·성능 검증: 인증, 권한, 응답 속도, 동시 처리 등 UI 레벨에서 커버할 수 없는 품질 속성을 직접 확인할 수 있습니다.AI Agent는 단순 화면 동작을 검증하는 수준을 넘어섭니다.• None 여러 외부 API 호출과 툴 오케스트레이션으로 작업을 수행합니다.• None 같은 질문이라도 맥락과 시점에 따라 다른 응답을 내놓습니다.따라서 UI를 넘어선, API 시나리오 단위 품질 보증이 필수입니다. 아래 내용들은 UI 테스트만으로는 이 연속 동작을 보장할 수 없습니다.AI와 에이전트 기술이 제품 아키텍처의 중심

올해 프로젝트는 온프레미스 환경에서의 도전 과제들이 많이 발생되고 있습니다.그 중의 하나로 외부 네트워크를 통해서 호스트에 접속한 후에 호스트에 구성된 KVM 기반의 VM에 접속하는 불편을 해결하는 요구사항에 대한 과제입니다.즉, 외부에서도 VM(가상머신)에 직접 접속할 수 있는 방법의 제시가 필요합니다.브리지 네트워크는 KVM 기반 VM에 외부에서 접근할 때 일반적으로 선호되는 방식입니다.• None 직접적인 IP 할당 : 브리지 네트워크를 사용하면 VM이 호스트와 동일한 네트워크에 존재하게 되어, VM에 IP를 직접 할당할 수 있습니다. 이는 NAT(Network Address Translation) 방식과 달리, VM이 외부 네트워크와 직접 통신할 수 있게 해줍니다. 따라서, VM이 외부에서 접근할 때 더 간편하고 효율적입니다.• None 성능 향상 : 브리지 네트워크는 VM 간의 통신을 더 빠르고 효율적으로 처리할 수 있습니다. NAT 방식에서는 패킷이 호스트를 통해 전달되기 때문에 추가적인 지연이 발생할 수 있지만, 브리지 네트워크는 VM이 직접 네트워크에 연결되어 있어 이러한 지연이 줄어듭니다. 이는 특히 대량의 데이터 전송이 필요한 경우에 유리합니다.• None 네트워크 관리 용이성 : 브리지 네트워크는 VM을 물리적 네트워크의 일부로 만들기 때문에, 네트워크 관리가 더 용이합니다. 예를 들어, DHCP 서버를 통해 IP 주소를 자동으로 할당받거나, 기존 네트워크 정책을 그대로 적용할 수 있습니다. 이는 NAT 방식에서는 구현하기 어려운 부분입니다.• None 접근성과 보안 : 브리지 네트워크는 VM이 동일한 서브넷에 위치하게 하여, 외부에서의 접근이 용이합니다. NAT 방식에서는 포트 포워딩을 설정해야 하므로, 추가적인 보안 설정이 필요할 수 있습니다. 반면, 브리지 네트워크는 기본적으로 외부와의 연결이 가능하므로, 보안 설정이 간단해질 수 있습니다.호스트와 VM의 네트워크 설정을 통해, 두 시스템이 동일한 네트워크에서 원활하게 통신할 수 있도록 구성할 수 있습니다.호스트의 네트워크 인터페이스인 ens18f0와 브리지 br172를 예로 들어, KVM 환경에서의 네트워크 설정을 설명하겠습니다.핵심 내용은 아래와 같습니다. (우분투 22.04 기준)• None 호스트 측면 : 호스트의 네트워크 설정에서 ethernets 파트가 아닌 bridges 파트에다 IP주소 할당• None VM 측면 : 172-static.yaml 파일 추가를 통해 호스트와 동일한 네트워크용 네트워크 주소 설정을 시행ens18f0 인터페이스를 br172 브리지로 전환하고, 해당 브리지에 IP를 할당하는 방법을 설명합니다.ens18f0에는 직접 IP를 할당하지 않고, br172에 IP를 부여하여 호스트와 VM이 동일 네트워크에서 독립적으로 작동하도록 설정합니다.• None 호스트 시스템에 대한 관리자 권한이 필요합니다.• None VM의 네트워크 설정을 변경할 수 있어야 합니다.호스트에서 현재 NIC 상태를 확인합니다.• None netplan 설정 파일을 엽니다. (파일 경로는 시스템에 따라 다를 수 있습니다.)• None 아래와 같이 설정을 수정합니다:브리지와 NIC의 IP 주소를 확인하여 설정이 올바르게 적용되었는지 확인합니다.7-1. VM 생성시에 NIC 추가하는 방식호스트에 브리지 준비가 되었으며, virt-manager를 통해서 VM을 생성하면 됩니다.VM을 생성할 때, 브리지 네트워크의 172점대와 NAT 네트워크의 192점대 NIC를 추가 합니다.생성 후에 VM의 네트워크 설정 우분투 UI에서 172점대 IP를 할당합니다.(192점대는 자동할당을 사용할 수 있습니다.)VM에 br172 브리지를 추가합니다. 아래 명령어에서 을 실제 VM 이름으로 변경합니다.아래와 같이 NIC가 device name: br172로 추가된 것을 볼 수 있습니다. (아직 IP할당 이전이라 IP는 Unknown으로 표시)8. 생성된VM에 브리지 추가 방식에서의 라우팅 대응VM에 브리지 추가 방식에서는 172점대의 라우팅 우선 순위가 낮은 상황이 발생되며 라우팅 우선 순위 조정이 필요합니다.아래의 명령어로 라우팅 조정이 가능합니다. 아래에서 Wired connection 1 이 192점대일 경우의 예시입니다.결과를 확인하면 아래와 같습니다.라우팅 우선 순위에서 172점대가 높아졌습니다.삭제 후 설정하는 방법도 있습니다. 아래의 예시를 참고하세요.리부팅을 통해서 172점대 IP와 192점대 IP까지 모두 잘 설정되었는지 확인합니다.아래와 같이 192.168.122네트워크의 기존 IP와 새로 브리지 네트워크로 생성한 IP 172.20.40.114 가 확인됩니다.ssh 접속이 가능하도록 VM에 SSH를 설치합니다.12. 외부에서 접속 시도설정이 완료되면 외부에서 VM에 SSH로 접속해 봅니다.• None 반드시 ens18f0에는 IP를 직접 할당하지 않고, br172에만 할당해야 네트워크가 정상 동작합니다.• None 기존 NAT 네트워크(192.168.122.xxx)는 그대로 유지되며, VM은 두 개의 NIC(내부 NAT, 외부 브리지)를 동시에 사용할 수 있습니다.이 절차서를 따라 설정을 완료하면, 호스트와 VM이 동일 네트워크에서 독립적으로 작동할 수 있습니다.온프레미스 환경에서 호스트 네트워크 주소 대역과 동일한 IP주소를 VM에 내부 Default 네트워크(192.168.122.)가 있는 상태에서추가로 NIC를 할당하여 외부에서도 호스트에 접속하듯이 ssh 172.20.40.114 로 접속이 가능하게 구성하였습니다.구성 과정에서 VM을 만들 때, 네트워크를 함께 구성하는 것이 좀 더 수월합니다.VM이 만들어진 이후에 172점대를 추가할 경우에는 라우팅 우선 순위로 접속이 불가한 상황이 발생하였고, 우선 순위 조정 절차가 해결 방법이었습니다.개발 환경 측면에서 작업 환경이 호스트 172 주소를 거쳐서 VM 192 주소로 접속해야 하는 번거러움이 해소되었습니다.이런 요구사항 충족으로 인해 KVM 기반으로 master node, wnode1, wnode2 의 VM 구성으로 K8s를 구축할 수 있고,m

최근 회사에서 사용자가 질의를 하면 ERP 데이터를 가져와 시각화해주는 Agent를 제작하고 있습니다.여러 부분에서 난관이 있지만 현재 가장 많은 리소스를 쓰고 있고 개인적으로 막막하기도 한 Text2SQL이 특히 어려운 이유에 대해 정리해 봤습니다.이라고 말할 수 있습니다.쉽게 말하면 LLM을 통해 사용자의 질의를 데이터를 조회할 수 있는 언어로 변환해 주는 작업입니다.필요한 맥락은 두 가지 종류가 있는데 바로 명시적 맥락과 암묵적 맥락입니다.명시적(스키마는 어떻게 생겼는가, 관련 열은 무엇인가, 데이터 자체는 어떻게 생겼는가?)암묵적(데이터의 정확한 의미는 무엇인가? 특정 비즈니스 사례에서 어떤 의미를 갖는가?)명시적 맥락은 RAG를 이용하여 스키마 정보(join, fields)를 가져오는 것으로 어느 정도 해소할 수 있지만,암묵적 맥락을 전달하기 위해서는 모든 데이터베이스나 데이터세트의 형태를 학습하고 스키마 또는 데이터 변경 사항을 따라가는 것은 어렵고 비용도 많이 드는 작업입니다.또한, 기업의 비즈니스 지식과 의미론은 애초에 제대로 문서화되어 있지 않은 경우가 많으며, 학습 데이터로 변환하기도 어렵습니다.예를 들어, 세계 최고의 DBA라도 표 cat_id2 = 'Footwear'에서 pcat_extension 해당 제품이 신발의 일종이라는 것을 알지 못한다면신발 판매를 추적하는 정확한 쿼리를 작성할 수 없을 것입니다. 이는 LLM에게도 마찬가지입니다.엔지니어나 분석가는 모호한 질문에 직면했을 때 더 많은 정보가 필요하다는 것을 감지하고 적절한 후속 질문이 가능합니다.반면, LLM은 답변을 제공하려는 경향이 있으며, 질문이 모호할 경우 환각 증상을 보일 수 있습니다.예시로 "가장 잘 팔리는 신발은 무엇인가?"와 같은 질문을 생각해 보겠습니다. 여기서 한 가지 분명한 모호점은 비즈니스나 애플리케이션 맥락에서 "가장 잘 팔리는" 것이 실제로 무엇을 의미하는가입니다.가장 많이 주문된 신발? 가장 많은 수익을 올린 신발 브랜드? 더 나아가, SQL에서 반품된 주문 수를 계산해야 할까요? 보고서에 몇 종류의 신발을 포함해야 할까요? 등등또한, 사용자마다 필요한 답변의 유형이 다릅니다.이렇기에 사용자가 기술 분석가나 개발자로서 모호한 질문을 한다면, 합리적이지만 100% 정확하지는 않은 SQL 쿼리를 제공하는 것이 좋은 출발점이 될 수 있습니다.그러나, 사용자가 기술적인 지식이 부족하고 SQL을 이해하지 못한다면, 정확한 SQL을 제공하는 것이 더욱 중요 해집니다. 이유는 기술적 지식이 없는 사용자는 LLM의 답변을 그대로 믿을 것이기 때문입니다.그렇기에 모호성을 해소하기 위해 후속 질문을 통해 답변하고, 답변의 논리를 설명하며, 사용자가 원하는 것을 찾을 수 있도록 안내하는 것이 중요합니다.Python과 Java 같은 프로그래밍 언어의 차이보다 훨씬 미묘한 SQL 언어 간의 차이점을 생각해 보면 됩니다.간단한 예로, BigQuery SQL을 사용하는 경우 타임스탬프 열에서 월을 추출하는 올바른 함수는 EXTRACT(MONTH FROM timestamp_column)입니다.하지만 MySQL을 사용하는 경우 MONTH(timestamp_column) 로 미묘한 차이가 있습니다.Text2SQL의 다양한 제약에도 불구하고, 자연어 만으로 데이터를 핸들링할 수 있다는 너무나 강력한 이유로최근 AWS와 GCP와 같은 클라우드 기업에서도 Text2SQL과 관련해 활발한 연구가 진행 중입니다.다음 글에는 Text2SQL이 오류 유형을 정리해 보겠습니다. 감사합니다.

Spring Security는 웹 애플리케이션 보안의 사실상 표준으로 자리 잡은 강력한 프레임워크로, 세션 관리, 접근 제어, 다양한 인증 방식 지원 등 폭넓고 유연한 기능을 제공합니다.그러나 실제로 1개 이상의 인증 수단을 동일한 인가 로직과 세션 정책 하에 관리하려면, SecurityFilterChain을 구성하는 여러 필터의 연계와 우선순위 조정이 쉽지 않습니다.또한 Spring Security의 기본 제공 구현(JDBC 기반 세션 관리, Spring Authorization Server 등)은 범용성을 위해 추상화되어 있어,세부 정책을 비즈니스 로직과 긴밀하게 결합하기에는 제약이 따르는 경우가 많습니다.예를 들어, UserDetails 기반의 Username/Password 인증을 활성화한 상태에서 Spring Authorization Server 기반 OAuth 회원과 통합하려면필터 체인의 우선순위와 인증 흐름을 재정렬해야 하며, 실무적으로는 양쪽 구성 모두를 일정 부분 커스터마이징하는 일이 불가피합니다.한편 실제 개발 환경은 짧은 주기 속에서 빠른 구축·배포가 요구되고, 인증이 필요한 서비스도 예외가 아닙니다.각 시스템은 비즈니스 특성에 따라 Form Login, Basic Auth, OAuth 클라이언트 인증 등 서로 다른 방식을 채택할 수 있지만,그럼에도 모든 서비스에는 동일한 수준의 접근 제어 정책과 세션 관리 규칙이 일관되게 적용되어야 합니다.이를 매번 직접 구현하면 프로젝트마다 복잡한 보안 설정이 반복되고, 서비스가 늘어날수록 관리·유지보수 부담이 기하급수적으로 커집니다.결국 Spring Security를 사용하더라도 통합적이고 일관된 인증·인가 체계를 갖추는 일은 결코 간단하지 않습니다.Fortel은 이러한 배경에서 개발된 사내 전용 Spring Security 확장 라이브러리입니다.Fortel은 세션을 먼저 검증하는 SessionResolver를 통해 세션 정책(세션 고정 방지, 동시 로그인 제한, 미인증 접근 처리)을 선적용하고,이후 → → 순서로 인증과 인가를 단일 관문에서 오케스트레이션합니다.또한 를 활용해 Form/Basic/OAuth 등 다양한 인증 입력을 동일한 파이프라인으로 수용하고,Authentication의 principal로 UserDetails 기반 도메인 모델을 일관되게 사용함으로써,필터 간 연계·우선순위 조정의 복잡성을 줄이면서 여러 인증 체계를 통합적으로 관리할 수 있게 설계했습니다.정리하면, Fortel은 인증·인가 로직, 세션 정책, 리소스 접근 제어를 YAML 기반 설정으로 선언하고 이를 표준화된 구조로 자동 구성해 Spring Security 환경에 적용합니다.이를 통해 서비스마다 다른 인증 방식을 사용하더라도 일관된 보안 정책을 유지할 수 있고, 개발자는 복잡한 설정 작업에서 벗어나 핵심 비즈니스 로직과 사용자 경험에 집중할 수 있습니다.• None YAML 기반 인증·인가 구성: Spring Security DSL 없이 정책을 선언적으로 설정• None 여러 인증 방식 지원: Form / JSON Login, Basic Auth, OAuth 클라이언트 인증 통합 관리• None 세션 및 리소스 제어 내장: 세션 고정 방어, 동시 로그인 제어, 다양한 접근 정책 관리• None 중심 구조: 세션 선검증 → 인증 → 인가를 단일 필터에서 통합 처리• None Spring Security와의 자연스러운 통합: FilterChain 재정의 없이 확장Fortel은 SecurityFilterChain을 직접 작성하지 않습니다. 대신 아래 YAML 설정을 기반으로 인증·인가·세션 정책을 구성하고, 이를 에 등록해 동작합니다.Fortel은 Spring Security의 개별 표준 필터에 직접 의존하지 않고, 세션 선검증 → 인증 → 인가를 단일 진입점인 에서 통합 오케스트레이션하도록 설계되었습니다.는 Spring Security가 제공하는 / 모델, ,등과 호환되는 인터페이스를 기반으로 구현되어, Fortel의 정책(YAML)과 결합해 요청 단위 인가까지 일괄 처리합니다.또한 SecurityFilterChain을 재정의하지 않고, YAML 기반 정책을 주입받아 한 관문에서 조율하는 방식으로 동작하므로,기존 Spring Security 기반 시스템에도 최소 변경으로 도입할 수 있고 서비스 전반에 일관된 세션 관리·인증·인가 정책을 적용할 수 있습니다.아래 예시는 Fortel의 핵심 흐름을 작게 발췌·단순화한 코드입니다(실제 구현과 일부 차이가 있을 수 있습니다).세션 고정 방지, 동시 로그인 제한, IP/User-Agent 점검 등 정책을 인증 전에 강제합니다.AuthenticationConverter 예시— “다중 입력을 하나의 파이프라인으로”Form과 OAuth 같은 서로 다른 입력을 동일 파이프라인으로 수용합니다.토큰의 타입별로 인증을 수행하고, 성공 시 authenticated(...)를 통해 인증 완료 토큰을 반환합니다.URL/메서드/권한을 기준으로 컨트롤러 진입 전 접근을 결정합니다.인증/인가 판단 이후의 응답 포맷을 한 관문에서 일관 처리합니다.3. Fortel 을 도입했을 때의 효과Fortel은 사내 보안 진단 요구사항을 충족하며, 에이닷 오토 어드민 개발에 도입되어 사용되고 있습니다.Fortel은 범용 오픈소스를 지향하기보다, 사내 시스템에 빠르고 안정적으로 그리고 일관되게 적용하기 위해 만든 라이브러리입니다.이를 테크 블로그에 공개하는 것이 적절한지, 또 어느 수준으로 다루어야 할지 많은 고민이 있었습니다.그래서 Fortel의 기능 설명이나 메커니즘 자체보다는, 무엇을 목표로 만들었는지와 대략적인 구성만으로 개발 스토리를 전하고자 했습니다.Spring Security는 훌륭합니다. 업계 표준으로서 손색이 없고, 설계 사상 또한 교과서처럼 배울 점이 많습니다.다만 그대로 억지로 끼워 맞추거나 다양한 기능을 모두 비활성화해 최소한으로만 쓰기보다, Spring Security를 훌륭한 교보재로 삼아 그 철학을 이해하고 조직에 맞는 보안 레이어를 스스로 구성하시길 권합니다.그런 관점에서 Fortel은 “정답”이 아니

많은 Python 개발자들이 간단한 자동화 스크립트를 작성할 때 “이 정도는 Bash나 Shell로 처리해야 하나?” 하는 고민을 한 번쯤 해봤을 겁니다.특히 간단한 작업을 위해 프로젝트 디렉토리를 만들고, pyproject.toml을 준비하고, 가상환경을 구성하는 과정은 꽤나 번거롭게 느껴지는데요.최근 이런 문제를 해결할 수 있는 표준과 도구들이 있어 소개해봅니다.바로 PEP 723 (Inline Script Metadata)과 패키지 매니저 uv, 그리고 CLI 앱 생성을 도와주는 Typer를 활용한 방법입니다.기존에는 Python 스크립트가 어떤 패키지에 의존하는지 명시할 방법이 없었습니다.PEP 723은 이를 해결하기 위해, 스크립트 파일 안에 직접 의존성과 Python 버전을 적어 넣을 수 있는 방법을 제안하고 표준으로 채택했습니다.예시는 다음과 같습니다.이렇게 작성하면, 외부 도구(예: uv)는 이 블록을 읽고 필요한 의존성을 자동으로 설치한 뒤 스크립트를 실행할 수 있습니다.즉, 하나의 파일만 공유해도 실행 환경을 재현할 수 있게 된 것입니다.PEP 723은 Python 스크립트 안에 의존성 메타데이터를 직접 선언할 수 있도록 정의한 표준입니다. 이 메타데이터 블록은 주석(##) 안에 TOML 형식으로 작성되며, # /// script 와 # /// 사이에 위치합니다.• None 즉, 이 블록은 pyproject.toml의 [project] 섹션 축약판이라고 볼 수 있습니다.• None 블록은 반드시 파일 맨 앞 부분에 위치해야 합니다. (주석이기 때문에 실행에는 영향을 주지 않음)• None 키워드는 현재 두 가지만 허용됩니다:• None 값은 TOML 구문을 그대로 따릅니다.• None 여러 줄에 걸친 리스트도 허용됩니다.uv는 최근 각광받는 초고속 Python 패키지 매니저입니다. pip보다 훨씬 빠르며, pipx나 venv 같은 기능까지 통합해서 제공합니다.uv는 PEP 723 블록을 이해하기 때문에, 단일 스크립트를 마치 Bash처럼 바로 실행할 수 있습니다:실행 과정에서 uv는:• None myscript.py 안의 # /// script 블록을 읽고,• None 필요한 패키지를 임시 환경에 설치한 뒤,별도의 requirements.txt나 가상환경을 만들 필요가 전혀 없습니다.즉, Python 스크립트를 하나의 실행 가능한 단일 파일처럼 다룰 수 있게 되는 셈입니다.매번 uv run을 붙이는 것도 귀찮을 수 있습니다.다행히 uv는 shebang을 통해 직접 실행하는 방법도 제공합니다.스크립트의 첫 줄에 다음 라인을 추가합니다.그리고 실행 권한을 부여합니다.이제는 단순히 아래와 같이 실행할 수 있습니다.즉, Python 스크립트가 Bash 셸 스크립트처럼 직접 실행 가능해집니다.리눅스나 macOS에서 실행 파일의 맨 첫 줄에형식으로 적는 문구를 shebang(쉐뱅) 이라고 부릅니다. 운영체제는 파일을 실행할 때 이 줄을 확인해서, 어떤 프로그램으로 이 파일을 실행해야 하는지를 결정합니다.라고 적혀 있다면 해당 스크립트는 Bash 셸로 실행됩니다.라고 하면 Python 3 인터프리터로 실행되죠.#!/usr/bin/env 를 쓰는 이유직접 경로(/usr/bin/python3)를 지정하면, 환경에 따라 해당 경로에 Python이 없을 수도 있습니다.그래서 보통은 env 명령어를 활용해, PATH에 등록된 프로그램을 찾아 실행하는 방식이 더 안전합니다.이렇게 하면, 사용자의 환경에 설치된 Python 3를 찾아 실행합니다.PEP 723과 uv에서는 다음과 같이 shebang을 사용합니다.여기서 의미는 다음과 같습니다.• None #!/usr/bin/env → PATH에서 프로그램을 찾아 실행• None -S → env에게 뒤의 인자를 하나의 문자열이 아니라 분리된 인자들로 전달하라는 옵션• None 즉, 이 스크립트는 “uv를 이용해서 실행해라”라는 지시를 운영체제에 내리는 것입니다.• None 필요한 환경을 자동으로 구성하고 스크립트 실행 이 과정을 통해 Python 스크립트가 Bash 스크립트처럼 바로 실행 가능한 실행 파일이 됩니다.Typer – Python으로 만드는 간단한 CLI 도구단순한 스크립트를 넘어서, 사용자 친화적인 CLI 명령어를 만들고 싶다면 Typer를 추천합니다.Typer는 FastAPI의 개발자인 Sebastián Ramírez가 만든 라이브러리로, Python 함수 정의만으로 직관적인 CLI 프로그램을 생성할 수 있습니다.를 실행하면 Hello Victor 가 출력됩니다.Typer는 자동으로:을 제공하기 때문에, Python 코드 몇 줄로 꽤 완성도 있는 CLI 도구를 만들 수 있습니다.지금까지 살펴본 조합을 정리하면 다음과 같습니다.• None PEP 723 → 스크립트 내부에 의존성을 선언이 네 가지를 활용하면, Python 스크립트를 마치 Bash 셸 스크립트처럼 빠르게 작성하고 실행할 수 있습니다.그러면서도 Python 생태계의 방대한 라이브러리를 그대로 활용할 수 있으니, 더 강력한 도구가 되는 것이죠.• None 더 이상 “작은 스크립트인데 패키지 설치가 귀찮다”라는 고민은 하지 않아도 됩니다.• None 동료에게 파일 하나만 공유해도, 실행 환경이 자동으로 준비됩니다.• None 실행 권한을 주면 ./myscript.py로 바로 실행할 수 있고,• None 필요하다면 Typer로 CLI 인터페이스까지 덧붙여 미니 유틸리티를 쉽게 배포할 수 있습니다.앞으로는 단순한 반복 작업이나 자동화도 Python 스크립트 하나로 해결 가능합니다 :)

마이리얼트립의 광고사업팀은 만들어진 지 1년 정도 된 팀으로, 여러 광고주들의 광고를 수주하며 성과를 내고 있습니다. 이 과정에서 발생한 무수한 오퍼레이션을 효율화할 목적으로 AI Operations 이라는 포지션을 신설하고 새로운 인턴을 모셔오게 되었는데요, 오늘은 광고사업팀의 AI Operations 인턴인 위주희님의 자동화 여정을 소개해 드리려 합니다. 위주희님은 음악을 전공하던 대학생이었는데, 마리트에 합류하며 여러 수동 반복 업무를 자동화하여 월 40시간의 작업을 90% 이상 줄이는데 성공했습니다.성장하는 사업부의 딜레마광고사업팀은 창립 1년 만에 급속한 성장을 경험하고 있었어요. 매월 15–20개의 광고주와 계약을 체결하며, 각 계약마다 3–5개의 문서 작업이 필요한 상황이었죠. 문제는 개발 리소스의 부족이었어요. 기술적으로 해결될 수 있는 문제들이 수작업으로 처리되고 있었고, 사업이 성장할수록 운영 부담은 기하급수적으로 증가했습니다AI 오퍼레이션 인력 확보광고사업팀 매니저는 파격적인 결정을 내렸어요. ‘AI 오퍼레이션스 인턴’이라는 새로운 직무를 만들어 전담 인력을 채용하기로 한 거죠.흥미롭게도 이 자리에 지원한 건 음악을 전공하는 대학생 위주희님이었어요. 클라리넷을 전공하던 위주희님은 이전 직무 경험에서 AI와 함께 라벨링 프로그램을 만들어 6시간 업무를 3분으로 단축한 경험이 있었거든요.“저는 관현악과 클라리넷 전공 대학생이기 때문에, 기술적인 배경이 부족하다고 볼 수 있는 사람이에요. 다만 진로적인 고민을 하는 과정 속에서 이전에 직무 경험을 쌓으면서 라벨링 프로그램을 AI와 함께 만들어 봤고 그 과정에서 여섯 시간 정도 걸리던 업무를 3분으로 단축하면서 AI 능력을 체감한 경험이 있었어요.”단계적 자동화 프로젝트 실행위주희님이 AI 오퍼레이션스 인턴으로 합류한 이후, 팀은 체계적인 접근 방식을 취했어요. 먼저 가장 반복적이고 시간이 많이 소요되는 업무를 식별했습니다.매일 아침 진행되던 광고 성과 보고서 작성이 주요 타겟이었어요. 광고주별로 맞춤 보고서를 생성하고, 각 광고주의 시트에 접속해서 데이터를 수동으로 입력하는 작업이 월 40시간 이상 소요되고 있었거든요.“저는 이런 프로세스를 봤을 때 자동화를 할 수 있지 않을까라는 아이디어를 떠올렸어요. 그래서 그걸 기반으로 AI와 대화를 하면서 생각을 구체화해 나갔어요.”AI와의 대화를 통해 해결책을 구체화한 결과, 두 단계의 액션 플랜이 수립되었어요.“일단 데이터 파이프라인을 구축해보는 거였어요. 그리고 두 번째 단계로는 보고서 생성 자체를 자동화 해야겠다라는 맥락으로 앱스크립트가 자동으로 보고서를 생성해 주는 플로우를 생각했어요.”흥미로운 점은 이 모든 과정이 코딩 지식 없이 진행되었다는 거예요. 자연어로 AI와 소통하며 필요한 기능들을 하나씩 구현해 나갔습니다.놀라운 효율성 개선 결과자동화 프로젝트의 결과는 기대를 뛰어넘었어요. 기존에 월 40시간 이상 소요되던 반복 업무가 90% 이상 절감되었습니다.“결과적으로 이런 내용을 통해 업무 시간적으로 본다면 기존 대비 구

일정 관리는 우리에게 매우 익숙한 기능이고 바쁜 업무나 일상생활을 효율적으로 관리하기 위한 필수적인 서비스입니다.효율적인 일정관리를 위해 에이닷은 AI 기반의 일정관리 기능을 제공하고 있습니다.다양한 캘린더 서비스의 일정 동기화 기능을 제공하고, AI를 활용하여 사용자의 생산성을 극대화하고 있습니다.본 글에서는 에이닷 캘린더에서 일정의 반복 기능을 어떻게 구현하고 있는지 살펴보겠습니다.iCalendar(RFC 5545)는 일정 정보를 다른 시스템 간 손쉽게 공유 및 교환을 위한 국제 표준입니다.우리가 가끔 일정 교환을 하다 보면 보게 되는 .ics 확장자로 많이 알려져 있으며, Google Calendar, Outlook, Apple Calendar 등 거의 모든 캘린더 애플리케이션에서 지원합니다.간단하게 "매주 수요일 점심 약속" 일정을 iCalendar 로 만들어 보면서 해당 규격을 이해해 보도록 하겠습니다.아래 표는 위 iCalendar 코드에서 사용된 주요 프로퍼티에 대한 설명입니다.간단하게 코드를 해석하면 한국 시간으로 2025년 8월 6일 12시부터 13시까지 매주 수요일 점심 약속의 일정입니다.하지만 위 일정은 제목과는 다르게 매주 반복하지 않습니다.반복 일정이란 정기적 또는 불규칙적으로 반복되는 일정을 의미합니다. 매주 하는 업무 회의, 생일 같은 기념일들이 해당합니다.반복 일정은 현실에서 매주 유용하고 자주 사용되고 있어 캘린더 서비스에서는 필수적인 기능입니다.친숙한 기능이지만 캘린더 서비스에서는 규칙이 복잡하여 상호 운용성 문제를 일으키는 경우가 많습니다.현실에서 사용되는 반복 패턴은 매일, 매주, 매월, 매년 간단한 규칙이 있지만 격주, 매월 마지막 목요일처럼 좀 더 복잡한 내용도 있습니다.생일 같은 기념일은 끝나는 시점이 명확하지 않거나, 횟수를 지정하여 반복하거나, 이번 달까지 반복할 수 있는 것처럼 특정 시점을 지정하는 등 다양한 종료 시점도 가질 수 있습니다.이처럼 복잡한 반복 일정을 막상 코드로 표현한다고 생각하면 앞이 캄캄해집니다. 이글은 이런 궁금증을 해결하기 위한 설명서입니다.RRULE(Recurrence Rule)은 iCalendar 의 일정의 반복 패턴의 규칙을 표현하는 프로퍼티입니다.해당 규칙을 사용하면 다양한 반복을 표현할 수 있습니다.아래 표는 RRULE 의 주요 파트 설명입니다.여기서 퀴즈! 아래의 그림처럼 에이닷에서 반복 일정을 만든다면 RRULE 은 어떻게 작성하면 될까요?FREQ=WEEKLY;COUNT=3;INTERVAL=1;BYDAY=WE 가 됩니다. 너무 쉬운 문제였나요?기본적으로 iCalendar 의 일정 정보는 하나의 일정이 하나의 VEVENT 컴포넌트로 관리됩니다.하지만 반복 일정의 모든 인스턴스는 독립된 컴포넌트로 관리하지 않고, RRULE 과 같은 반복에 대한 규칙으로 표현합니다.모든 반복을 코드로 작성해야 한다고 가정해 보겠습니다.가령 반복 일정의 종료 기간이 없으면, 무한하게 반복되는 일정의 인스턴스를 하나하나 코드로 작성해야 하고, 이는 엄청난 비효율이 발생하기도 하며, 실제로 불가능한 일입니다.iCalendar 에서는 이러한 비효율을 해결하기 위해 반복 일정의 마스터만 관리합니다. 반복되는 인스턴스들의 규칙은 RRULE로 정의하고,필요시 동적으로 계산하여 생성하도록 설계되어 있습니다. 아래는 위에서 다룬 간단한 반복 일정 샘플입니다.아래 그림은 위 반복 일정이 어떻게 반복 인스턴스로 확장되는지 개념적으로 표현하였습니다.왼쪽은 반복 일정의 마스터 객체이고, 오른쪽은 확장된 인스턴스입니다.반복되는 일정의 최초 인스턴스의 ID(RECURRENCE-ID) 는 DTSTART 와 동일하며, 이후 인스턴스의 ID는 RRULE에 의해 정의됩니다.DTSTART 는 인스턴스의 ID인 RECURRENCE-ID와 동일하게 생성되고, 나머지는 정보는 반복과 관련된 프로퍼티를 제외한 마스터 VEVENT 컴포넌트의 프로퍼티를 복사합니다.아래는 확장된 인스턴스를 iCalendar 코드로 작성한 내용입니다.만약에 사용자가 두 번째 약속을 취소하고 싶으면 어떻게 표현하면 될까요? 아래 그림을 두 번째 인스턴스를 취소하는 방법을 도식화했습니다.EXDATE 프로퍼티(Exception Date/Times)를 사용하여 처리합니다. 원본 일정 iCalendar 코드에서 EXDATE 의 값에 두 번째 인스턴스의 RECURRENCE-ID를 저장하고,확장 시 해당 정보만 생성하지 않습니다. 아래 코드처럼 표현됩니다.만약 세 번째 일정을 오후 6시 저녁 약속으로 변경하고 싶으면 어떻게 수정하면 될까요?이때는 인스턴스 오버라이딩 개념을 사용합니다.예외의 인스턴스만 별도로 복사하여 원하는 내용을 수정한 후 저장하면 됩니다.단 오버라이드된 인스턴스는 RRULE, EXDATE 등의 반복 프로퍼티를 가질 수 없고, 기존 UID 는 마스터와 동일해야 하며 RECURRENCE-ID는 DTSART 와 동일한 규격으로 유지되어야 합니다.아래는 이번 수요일은 저녁 약속 반복 예외 일정을 반영한 코드입니다.반대로 다시 반복 인스턴스로 확장할 경우, 동일하게 인스턴스를 생성하고 오버라이드된 인스턴스로 대체하면 작업이 완료됩니다.AI와 캘린더 기술의 융합으로 일정 관리는 점점 더 똑똑해지고 있습니다.에이닷 캘린더는 iCalendar 국제 표준을 기반으로 다양한 반복 패턴을 효과적으로 처리하여, 사용자가 복잡한 일정도 손쉽게 관리할 수 있도록 설계되어 있습니다.반복 일정은 단순한 기능 같아 보여도 실제 구현에서는 다양한 예외와 사용자 맞춤 상황을 지원해야 하기에, 표준적인 데이터 구조와 유연한 로직이 필수적입니다.에이닷 캘린더는 표준 준수와 함께 사용성에 집중함으로써, 현실적인 반복 스케줄부터 예상치 못한 일정 변경까지 모두 유연하게 대응할 수 있습니다.앞으로도 에이닷은 지속적으로 진화하는 일정 관리 기술과 AI 기반 기능을 바탕으로, 더 많은 사용자에게 편리함과 생산성 향상을 제공할 것입니다.여러분의 시간과 일상에 더 큰 여유와 효율을 더하는 에이닷 캘린더, 지금 바로 경험해 보세요!

서비스의 건강을 수치화 할 수 있을까?   SLI/SLO안녕하세요. 29CM Search & Discovery 팀 백엔드 개발자 김찬입니다.저희 팀은 고객의 구매 여정에서 가장 처음 마주하게 되는 전시 지면을 책임지고 있습니다. 그만큼 빠르고 안정적인 서비스 제공이 중요한데요. 서비스를 운영하다 보면 종종 이런 의문이 생깁니다. 지금 우리 서비스는 정상적으로 운영되고 있는걸까? 한번은 서버는 정상적으로 동작하고, 오류율도 높지 않으며, 로그 상으로는 이상이 없었지만 실제 응답에는 데이터가 비어 있어, 전시 지면의 일부 구좌가 아예 노출되지 않는 문제가 있었습니다. 시스템적으로는 정상으로 판단되던 상황이지만, 고객 입장에서는 명백한 비정상이었던 상황인 셈입니다.이러한 문제는 내부 제보를 통해서야 비로소 인지할 수 있었고, 결과적으로 고객 경험 손실 및 매출 감소로 이어졌습니다.건강을 지키기 위해 주기적인 검진과 수치 기반의 진단이 필요하듯, 서비스도 마찬가지입니다. 단순히 오류율이나 로그만으로는 시스템 상태를 충분히 판단할 수 없습니다. 감에 의존하거나, 문제 발생 후에야 대응하는 방식은 결국 진통제로 증상을 가리는 것에 불과합니다.개발자에게는 시스템의 상태를 보다 정교하고 객관적으로 진단할 수 있는 방법이 필요합니다. 이런 배경 속에서 등장한 개념이 바로 SLI(Service Level Indicator)와 SLO(Service Level Objective)입니다.이번 글에서는 SLI와 SLO가 무엇인지, 왜 중요한지, 그리고 29CM에서는 이를 어떻게 도입하고 운영하며 서비스의 건강성을 개선해나가고 있는지를 소개합니다.SLI/SLO 란?SLI와 SLO는 Google에서 시작된 SRE(Site Reliability Engineering) 문화에서 비롯된 개념입니다. 운영 안정성과 개발 속도의 균형을 잡기 위해, 서비스의 품질을 정량적으로 측정하고 목표를 설정하는 체계가 필요했고, 그 결과로 탄생한 것이 바로 이 두 지표입니다.SLI (Service Level Indicator)SLI는 서비스의 상태나 품질을 수치로 나타낸 지표입니다. 사용자에게 얼마나 안정적으로 서비스를 제공하고 있는지를 나타내는 핵심 수단이며, 보통 다음과 같은 형태로 측정됩니다지연 시간 (Latency)가용성 (Availability)처리량 (Throughput)예를 들어, 하루 동안 처리된 API 요청 중 99.95%가 성공했다면, 요청 성공률에 기초한 가용성 이라는 SLI는 99.95%가 됩니다.SLO (Service Level Objective)SLO는 SLI에 대한 내부 목표치를 의미합니다. 다시 말해, 서비스 품질이 어느 정도 수준 이상은 유지돼야 한다는 기준선을 설정하는 것입니다. 보통 다음과 같은 예시로 설정할 수 있습니다. 요청 성공률에 기초한 가용성을 월 평균 99.9% 이상 유지한다 90% 이상의 요청(P90)이 100ms 이내에 응답해야 한다 SLO는 경고 기준, 장애 대응 기준, 개발 속도와 운영 안정성 간의 균형을 잡는 데 핵심이 됩니다. 또한 에러 버짓(Error Budget) 계산의 기반이 되기도 합니다.개발자는 종종 서비스 장애나 성능 문제를 감에 의존해서 판단하곤 합니다. 하지만 이러한 방식은 객관적이지 않으며, 서비스의 신뢰도를 체계적으로 측정하고 개선하기 어렵습니다. SLI와 SLO를 설정하면 다음과 같은 이점이 있습니다장애 발생 여부를 정량적 기준으로 판단할 수 있습니다.목표 수치를 달성했는지를 파악할 수 있고, 부족하다면 지속적인 개선이 가능합니다.사용자가 체감하는 서비스의 품질을 수치로 반영할 수 있습니다.29CM 에선 어떻게 SLI와 SLO를 활용하고 있을까?SLI와 SLO를 실제 적용하기 위해서는 단순히 개념만 이해하는 것을 넘어, 실제로 어떤 지표를 어떻게 측정하고, 어떤 도구로 관리할지를 명확하게 설계해야 합니다. 29CM 에선 다음과 같이 SLI와 SLO를 활용하고 있습니다.1️ SLI 설정SLI는 서비스의 품질을 수치로 나타내는 지표이므로, 무엇을 어떻게 측정할지 결정하는 것이 매우 중요합니다. 특히 서비스의 특성과 팀의 역할에 따라 어떤 지표가 사용자의 여정에서 가장 의미 있는지를 잘 판단해야 합니다.예를 들어, 주문/결제 시스템처럼 장애 발생 시 곧바로 매출에 영향을 미치는 서비스는 매우 크리티컬하므로, API 단위로 SLI를 설정하고 있습니다. 주문서 조회, 주문 생성, 결제, 출고 등 핵심 API 단위로 Availability 및 Latency 지표를 추적하고 있습니다.주문/결제 시스템 SLI 설정 예시또 다른 예로, 전시 시스템의 경우에는 각 구좌가 고객에게 제대로 상품을 보여주고 있는지가 중요합니다. 따라서 구좌별로 응답 데이터의 hit 비율(정상적으로 콘텐츠가 노출된 비율)과 empty 비율(데이터가 비어 노출되지 않은 비율)을 SLI로 설정해 모니터링하고 있습니다.전시시스템 SLI 설정 예시반면, 상대적으로 영향도가 낮은 서비스는 개별 API별로 세분화하기보다는, 서버 전체의 API Availability 및 Latency를 통합하여 하나의 SLI로 추적하고 있습니다. 운영 효율성과 관리 부담 사이의 trade-off를 고려하여 SLI 지표를 팀마다 설정하고 있습니다.2️ SLO 설정SLO는 SLI 지표에 대해 우리가 어느 정도까지 허용 가능하게 할지, 즉 어떤 목표를 유지할 것인지 정하는 단계입니다. 29CM 에서는 SLI와 마찬가지로 동일한 기준을 적용하는 것이 아니라, 유저 유입량, 해당 SLI의 중요도, 장애 시 영향도 등을 고려하여 목표 수준을 다르게 설정하고 있습니다.예를 들어, 홈 화면, 상품 상세 화면처럼 유저 트래픽이 많고 구매 전환과 직결되는 곳을 담당하는 서비스는 높은 가용성과 빠른 응답 속도가 중요하므로, 타이트한 기준을 설정합니다.전시 서비스 SLO 설정 예시 (p99: 50ms)반면, 어드민 API, 통계성 데이터 등은 사용 빈도나 유저 영향도가 낮기 때문에 그 보다는 완화된 기준을 설정하여 운영 피로도를 낮춥니다.이처럼 서비스의 특성과 비지니스 임팩트를 고려해 탄력적으로 목표치를 설정해야, 불필요한 알림 과잉

프롬프트 최적화를 더 쉽게 – DSPy 가이드안녕하세요. 프롬프트(prompt)라는 단어를 들어본 적이 있으신가요?에이닷, ChatGPT와 같은 AI 모델을 사용해본 경험이 있다면 이미 무의식적으로 프롬프트를 사용한 경험이 있으신거지요.LLM 모델에 “날씨를 알려줘”, “영화를 추천해줘”와 같이 질문이나 요청을 전달하는 것이 모두 프롬프트라고 볼 수 있습니다.즉, 프롬프트란 AI에게 무엇을, 어떤 방식으로 해달라고 요청하는 명령문이라고 할 수 있습니다.1. 프롬프트가 중요한 이유LLM(대규모 언어 모델)은 같은 질문이라도 표현 방식에 따라 답변이 완전히 달라집니다.예를 들어 “버그 리포트를 작성해줘”라고만 요청하면 두세 줄로 간단히 작성될 수 있지만,“QA 보고서 형식에 맞춰, 재현 단계·예상 결과·실제 결과를 표로 정리해줘”라고 요청하면 훨씬 체계적이고 원하는 결과에 가까운 답변을 얻을 수 있습니다.프롬프트 엔지니어링이란 이러한 차이를 이해하고, 원하는 결과를 더 정확하고 일관되게 끌어내는 기술입니다.예를 들어, “지난 주 화요일 팀 회의 내용을 3문단으로 요약하고 핵심 결정 사항을 목록으로 정리해 주세요.” 라는 프롬프트를 기준으로 프롬프트 엔지니어링에 필요한 요소를 설명하겠습니다.이 네 가지 요소가 항상 필수 요소는 아니지만, 포함될 경우 LLM이 의도를 보다 정확하게 이해하고, 기대에 부합하는 답변을 제공하는 데 큰 역할을 하게 됩니다.문제는 이 과정을 수동으로 진행하면 많은 시간이 소요된다는 점입니다.좋은 결과를 얻기 위해 다양한 실험이 필요하며, 매번 결과를 비교하여 최적의 프롬프트를 찾아야 합니다.이런 문제를 해결하고자 DSPy가 탄생했습니다.DSPy는 Declarative Self-Improving Python의 약자로, 파이썬 스타일로 선언하는 스스로 개선되는 자연어 처리 프로그램을 의미합니다.프롬프트 최적화를 자동화하는 프레임워크로 사용자가 직접 프롬프트를 작성하는 대신, 모듈 형태로 동작을 정의하면 DSPy가 데이터와 목적에 맞춰 해당 모듈을 자동으로 최적화 합니다.모델 성능 검증과 같이 동일한 질문을 반복적으로 입력하거나, 서로 다른 프롬프트를 비교하는 작업에서 DSPy는 특히 유용합니다.현재 QE팀에서는 에이닷 모델프트 최적화를 더 쉽게 – DSPy 가이드**안녕하세요. 프롬프트(prompt)라는 단어를 들어본 적이 있으신가요?에이닷, ChatGPT와 같은 AI 모델을 사용해본 경험이 있다면 이미 무의식적으로 프롬프트를 사용한 경험이 있으신거지요.LLM 모델에 “날씨를 알려줘”, “영화를 추천해줘”와 같이 질문이나 요청을 전달하는 것이 모두 프롬프트라고 볼 수 있습니다.즉, 프롬프트란 AI에게 무엇을, 어떤 방식으로 해달라고 요청하는 명령문이라고 할 수 있습니다.1. 프롬프트가 중요한 이유LLM(대규모 언어 모델)은 같은 질문이라도 표현 방식에 따라 답변이 완전히 달라집니다.예를 들어 “버그 리포트를 작성해줘”라고만 요청하면 두세 줄로 간단히 작성될 수 있지만,“QA 보고서 형식에 맞춰, 재현 단계·예상 결과·실제 결과를 표로 정리해줘”라고 요청하면 훨씬 체계적이고 원하는 결과에 가까운 답변을 얻을 수 있습니다.프롬프트 엔지니어링이란 이러한 차이를 이해하고, 원하는 결과를 더 정확하고 일관되게 끌어내는 기술입니다.예를 들어, “지난 주 화요일 팀 회의 내용을 3문단으로 요약하고 핵심 결정 사항을 목록으로 정리해 주세요.” 라는 프롬프트를 기준으로 프롬프트 엔지니어링에 필요한 요소를 설명하겠습니다.이 네 가지 요소가 항상 필수 요소는 아니지만, 포함될 경우 LLM이 의도를 보다 정확하게 이해하고, 기대에 부합하는 답변을 제공하는 데 큰 역할을 하게 됩니다.문제는 이 과정을 수동으로 진행하면 많은 시간이 소요된다는 점입니다.좋은 결과를 얻기 위해 다양한 실험이 필요하며, 매번 결과를 비교하여 최적의 프롬프트를 찾아야 합니다.이런 문제를 해결하고자 DSPy가 탄생했습니다.DSPy는 Declarative Self-Improving Python의 약자로, 파이썬 스타일로 선언하는 스스로 개선되는 자연어 처리 프로그램을 의미합니다.프롬프트 최적화를 자동화하는 프레임워크로 사용자가 직접 프롬프트를 작성하는 대신, 모듈 형태로 동작을 정의하면 DSPy가 데이터와 목적에 맞춰 해당 모듈을 자동으로 최적화 합니다.모델 성능 검증과 같이 동일한 질문을 반복적으로 입력하거나, 서로 다른 프롬프트를 비교하는 작업에서 DSPy는 특히 유용합니다.현재 QE팀에서는 에이닷 모델 검증을 위해 SPeCTRA[(참조)]를 사용하여 성능을 측정하고 있지만, 예시로 수동 발화 응답 품질 테스트를 가정해 보겠습니다.• None 각 답변이 평가 기준(정확성, 윤리성, 톤 등)에 얼마나 부합하는지 점수화• None 가장 높은 점수를 받은 프롬프트 선정이 과정은 사람이 직접 하면 며칠이 걸릴 수 있지만, DSPy를 활용하면 코드 몇 줄로 자동화할 수 있습니다.4. DSPy는 어떻게 동작되는가DSPy의 핵심 아이디어는 프롬프트를 하드코딩하지 않고, ‘변수화’ 해서 최적화할 수 있게 만드는 것으로 작동 순서는 다음과 같습니다.• None 작업 정의(Modules) – 어떤 입력을 받고, 어떤 출력을 원하는지 정의• None 데이터 준비 – 테스트할 질문과 기대하는 답변(또는 평가 기준) 준비• None 최적화 실행(Optimizers) – 여러 시도 → 평가 → 개선 반복• None 결과 출력 – 최적의 프롬프트와 성능 지표 제공• None 입력(input_text)과 출력(output_summary)의 구조를 정의• None DSPy가 실험·평가할 때 쓰는 예제 데이터• None 모델이 만든 요약이 ‘짧고 핵심을 담았는지’ 판단• None DSPy는 프롬프트 관리, 자동 최적화, 재현성이라는 세 가지 강점을 제공하는 프레임워크로 평가 함수와 모델 가중치 자동 조정 기능도 내장되어 있어, LLM 발화 품질을 평가하거나 개선하는 업무에서 특히 효과적이라 판단됩니다. 확장된다면 LLM 모델으로 들어오는 부정확한 사용자의 발화를 보정하거나 다듬는 역할도 할수 있지 않을까 하는 기대감도 있습니다.•

BLIP(Bootstrapping Language-Image Pre-training)과 CLIP(Contrastive Language-Image Pre-training)는 모두 이미지와 텍스트를 연결하여 멀티모달 AI 모델을 만드는 대표적인 방법이지만, 구조 등에 차이가 있습니다.• None 인코더 두 개로 이미지와 텍스트를 임베딩하여 매칭하는 구조• None 이미지와 텍스트를 같은 공간에 올려서 맞는지 확인• None 종합적인 멀티모달 Encoder-Decoder 구조로, 이미지-텍스트 이해뿐 아니라 자연어 생성까지 지원• None 이미지를 보고 그에 맞는 문장을 만들어 냄.정리를 하면, BLIP은 생성 작업이 필요한 복합적인 비전-언어에 적합하고, CLIP은 빠르고 효율적인 매칭 및 검색 작업에 적합합니다.OpenAI의 CLIP(openai/clip-vit-base-patch32) 과 BLIP(Salesforce/blip-image-captioning-base)모델을 활용하여이미지와 여러 텍스트 간의 의미적 유사도를 계산하는 과정을 간단하게 만들어보았습니다.CLIPModel과 CLIPProcessor를 불러와 사전학습된 모델과 전처리기를 준비합니다.openai/clip-vit-base-patch32는 이미지와 텍스트를 같은 임베딩 공간에 매핑할 수 있는 멀티모달 모델입니다.지정된 경로 또는 URL 에서 이미지 파일을 불러옵니다.이미지는 RGB 형식으로 변환되어 모델 입력에 맞게 준비됩니다.이미지와 비교할 텍스트 목록을 정의합니다.예시로 "고양이", "강아지", "자전거 타는 사람"을 사용하였습니다.이미지와 텍스트를 모델 입력 형식에 맞게 전처리합니다.이미지와 텍스트는 배치 형태의 텐서로 변환되고, 패딩이 적용합니다.torch.no_grad() 컨텍스트 내에서 모델에 입력을 넣어 추론을 수행합니다.이미지와 각 텍스트 간의 유사도 점수(logits)를 계산합니다.소프트맥스 함수를 적용해 각 텍스트에 대한 확률로 변환합니다.각 텍스트와 이미지 간의 유사도 확률을 출력합니다.가장 유사도가 높은 텍스트를 찾아 출력합니다.예를 들어, 이 이미지는 '자전거 타는 사람'이 가장 유사합니다. (확률: 0.68)"와 같이 결과가 나옵니다.BLIP는 CLIP처럼 이미지 vs 여러 텍스트의 대조 유사도 계산을 직접적으로 하진 않고, 주로 이미지 캡션 생성이나 질문에 대한 답변(VQA) 같은 형태로 사용합니다.그래서 CLIP에서 하던 "고양이", "강아지", "자전거 타는 사람" 중 가장 유사한 항목을 찾는 방식은 BLIP에서는 이미지 캡션을 생성한 후, 후보 텍스트와 비교합니다.2-1. BLIP-이미지 캡셔닝 모델을 불러와서, 이미지에 대해 자동 캡션 생성2-2.생성된 캡션과 후보 텍스트들을 간단한 문자열 유사도(코사인)로 비교하였습니다.위의 이미지의 유사도는 비슷하게 나왔습니다.(CLIP : 0.68, BLIP : 0.62)BLIP 에서는 이미지 캡션 생성 기능이 추가되어 의미적 유사도를 계산하였습니다.멀티모달 분야에서 BLIP 과 CLIP 은 각 자의 구조와 특성에 따라 다양하게 활용하면 좋을 것 같습니다.