많은 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 스크립트 하나로 해결 가능합니다 :)

일정 관리는 우리에게 매우 익숙한 기능이고 바쁜 업무나 일상생활을 효율적으로 관리하기 위한 필수적인 서비스입니다.효율적인 일정관리를 위해 에이닷은 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 은 각 자의 구조와 특성에 따라 다양하게 활용하면 좋을 것 같습니다.

첫 ‘체험형’ 과제, 페이스페이언더커버 사일로에서 페이스페이 편은 처음으로 단일 과제, 그리고 체험형 문제가 출제된 회차였어요. 이전의 인플로우나 만보기 사일로는 특정 서비스나 기능을 맞히는 문제였던 반면, 이번에는 챌린저들이 직접 UI를 만들어야 했죠. 그래서 챌린저 중 일부는 페이스페이를 써봤음에도 불구하고, 처음부터 가설을 세워서 UI에 접근해야만 했습니다. 이 과정을 보시는 시청자분들도 ‘나라면 어떻게 만들었을까?’ 함께 고민해보시면, 우리가 일상에서 무심코 쓰는 UI에 얼마나 깊은 고민이 담겨 있는지 발견하는 재미를 느끼실 수 있을 겁니다.페이스페이는 많은 고객분들이 낯설어하는 결제 방식입니다. 유저분들은 개인정보 제공에 민감하게 반응할 수밖에 없고, 솔직히 이 서비스를 처음 제공한다고 했을 때 팀 내에서도 의견이 정말 많았습니다.첫 번째 질문은 “이거 정말 편리한 수단 맞아?” 였고, 두 번째는 “그 많은 카페나 식당에 어떻게 디바이스를 보급할 건데? 예산이 얼마나 드는 거야?” 같은 내부적인 의심들이었죠.저희 사일로는 우선 ‘이게 정말 편리한가?’라는 질문을 검증하기 위해, 저희가 만든 제품들을 사내에서 먼저 사용할 수 있게 제공했어요. 예를 들어 사내 카페에서 페이스페이로 음료를 주문할 수 있고 , 저희 업무 환경으로 들어올 때는 페이스패스를 통해 출입할 수 있게끔 하고 있죠. 그런데 처음에는 긴가민가한 시각을 가졌던 분들도, 딱 한 번 사용하고 나면 그 편리함을 바로 느끼시더라고요. 일례로는, 저희가 오피스를 확장하면서 새로운 공간에서는 페이스패스를 쓸 수 없게 되자, ‘여기서도 편리하게 입장하고 싶으니 빨리 설치해달라’는 의견을 주시는 것을 보면서 확신했습니다. 정말로 한 번만 사용하면 그 편리함을 누구나 느낄 수 있을 거라고요.얼굴 등록의 ‘어색함’을 없애기 위한, 보상 없는 이벤트서비스가 만들어지고 나서, 저희가 처음 시도했던 건 ‘사전 신청’ 방식이었어요. “새로운 결제 수단이 나오니, 미리 등록했다가 나중에 써보세요”라는 접근이었죠. 하지만 얼굴을 확인하는 단계에서 정말 많은 사용자분들이 이탈하셨습니다.이유를 알기 위해 설문을 진행해보니, 생각보다 많은 분들이 얼굴 인증 자체에 ‘생소함’과 ‘어색함’을 느끼고 계셨어요. 아이폰 유저분들과 달리 갤럭시 휴대폰 유저분들께는 더 낯선 경험이었죠. 심지어 ‘아직 마음의 준비가 안 됐다’거나 ‘수염을 안 깎아서 준비가 안 됐다’는 솔직한 답변도 있었습니다.저희의 목표는 명확해졌습니다. 바로 이 ‘어색함’을 없애고, 얼굴을 인식하는 경험 자체를 익숙하게 만드는 것이었죠. 소셜 프루프나 혜택 제공 같은 다른 방법도 있었지만, 저희는 ‘자주 노출해서 익숙하게 만들자’는 방식을 택했습니다.여기서 중요한 원칙이 하나 있었는데, 바로 ‘보상 없는 이벤트’여야 한다는 점이었어요. 만약 ‘얼굴 등록하면 1천 원을 드린다’고 했다면, 사용자들이 자신의 개인정보를 판다고 느낄 수 있었을 테니까요. ‘이런 걸 굳이 해야 해?’ 같은 거부감을 주지 않는, 즐거운 경험이어야만 했습니다.그래서 저