AI Tools8분 분량

Open WebUI를 열기 전에 아침 테스트 보고서가 도착합니다

Open WebUI 0.13.3에서는 예약한 코딩 에이전트에 터미널과 프로젝트 폴더를 지정할 수 있습니다. 최소한의 권한으로 아침 점검을 자동화하는 방법을 살펴봅니다.

K
Ken Jo

월요일 오전 8시 30분, 개발자가 밤사이 실행된 테스트 결과를 엽니다. 작업 세 개가 빨간색입니다. 첫 번째는 테스트 데이터베이스 연결이 끊겼고, 두 번째는 간헐적인 시간 초과가 났으며, 세 번째는 금요일에 수정한 코드의 단언문을 통과하지 못했습니다. 빨간 표시를 확인하는 것보다 실패 원인을 분류하는 데 시간이 더 걸립니다. 코딩 에이전트를 정기적으로 실행하면 실패한 단언문과 관련 로그가 맨 위에 정리된 짧은 보고서를 채팅에서 바로 확인할 수 있습니다.

Open WebUI는 AI 모델과 도구를 연결할 수 있는 자체 호스팅 채팅 인터페이스입니다. v0.13.3부터 예약 자동화에서 코딩 에이전트를 지원합니다. GitHub에 기록된 릴리스 시각은 2026년 11월 8일 23시 48분 UTC입니다. 자동화에 터미널과 작업 디렉터리, 해당 터미널에서 사용할 수 있는 코딩 에이전트를 저장하고 실행 결과를 채팅으로 받을 수 있습니다. 예약 시각에 지정된 작업 환경에서 실행할 수 있으므로 아침 보고서처럼 반복되는 업무에 활용하기 좋습니다. Open WebUI v0.13.3 릴리스 노트

첫 번째 예약 작업으로는 사람이 몇 분 만에 확인할 수 있는 보고서가 적합합니다. 자동화에 근거 수집을 맡기고 다음 결정은 프로젝트 담당자가 내리도록 합니다. 반복해서 쓸 만한 보고서가 나오면 권한을 더 줄지 판단할 기준이 생깁니다.

자동화가 에이전트의 작업 위치를 기억합니다

Open WebUI 자동화는 기존에도 프롬프트를 주기적으로 실행할 수 있었습니다. 자동화가 일반 응답 생성 절차를 통해 채팅을 시작하므로 모델 설정, 도구, 필터, 적용 가능한 메모리 설정이 실행에 영향을 줄 수 있습니다. 0.13.3에서는 터미널에서 찾은 코딩 에이전트를 선택하는 경로가 추가됐습니다. 터미널을 고르면 모델 선택기에 사용 가능한 조합이 에이전트/모델 형식으로 표시됩니다. 터미널이나 폴더를 바꾸면 조합도 달라질 수 있습니다. Open WebUI는 실행 전에 저장된 터미널과 에이전트가 여전히 존재하는지 확인합니다. 둘 중 하나가 사라지면 실행이 실패하고, 자동화 소유자가 실행 로그에서 원인을 살펴볼 수 있습니다. Open WebUI 자동화 문서

예약 설정, 터미널, 프로젝트 폴더와 에이전트를 거쳐 채팅 보고서가 만들어지는 과정

예약 실행기는 저장된 실행 설정으로 채팅을 시작합니다. Open WebUI v0.13.3 릴리스 노트를 바탕으로 Telli.sh가 제작한 그림입니다.

작업 디렉터리로 결정하는 것은 단순하지만 결과에는 큰 영향을 줍니다. 파일명이 비슷한 프로젝트 두 개가 있거나 같은 프로젝트의 기능 브랜치와 릴리스 브랜치가 각각 디스크에 체크아웃되어 있다면 에이전트는 어느 쪽을 읽어야 할까요? 경로를 명시하면 의도한 위치에서 작업을 시작하고, 검토자도 올바른 위치를 사용했는지 확인할 수 있습니다. 그 경로는 시작점입니다. 실행 중 접근할 수 있는 범위는 읽기·쓰기 권한, 접근 가능한 파일과 환경 변수, 네트워크 접근, 코딩 에이전트의 동작으로 결정됩니다.

결과가 전달되는 위치도 정해져 있습니다. 코딩 에이전트 자동화의 결과는 채팅으로 전송됩니다. 릴리스 노트에서는 채널에 결과를 보낼 수 있는 일반 모델 자동화와 이 동작을 구분합니다. 개인이 아침 보고서를 검토하기에는 실행 이력과 채팅이면 충분합니다. 팀 전체에 알림이 필요하다면 공유할 내용과 위치, 원본 로그를 볼 수 있는 사람을 별도로 정해야 합니다. 예약 작업에 실패했을 때 어디를 확인할지 아는 담당자도 필요합니다. Open WebUI v0.13.3 릴리스 노트

첫 작업에는 작고 확인하기 쉬운 입력을 준비합니다

월요일 테스트 보고서를 예로 들어 보겠습니다. 최근 야간 테스트 요약, 시스템이 생성한 커밋 ID, 그리고 소수의 실패 로그 사본을 준비합니다. 기존 CI 아티팩트 내보내기 기능을 쓰거나 일회용 디렉터리에 수동으로 복사하면 에이전트에 고정된 입력을 줄 수 있습니다. 각 파일에 어느 작업과 커밋에서 발생한 실패인지 식별할 수 있는 맥락을 담습니다. 폴더에 넣기 전에 노출된 비밀값과 관련 없는 로그를 덜어냅니다. 파일명 규칙과 확인 가능한 타임스탬프가 있으면 에이전트가 최신 파일을 추측할 필요가 줄어듭니다.

한 번의 채팅 응답에 결과를 세 부분으로 나눠 달라고 요청합니다. 첫째는 확인이 필요한 실패의 짧은 목록입니다. 둘째는 환경 문제로 보이거나 원인이 아직 해결되지 않은 실패의 목록입니다. 셋째는 항목별 원본 근거의 링크나 경로입니다. 검토자가 CI 화면과 바로 대조할 수 있게 형식을 간결하게 잡습니다. 테스트 하나가 매트릭스의 여섯 실행에서 실패했다는 이유로 같은 이슈를 여섯 건 등록하면, 짧게 끝날 확인 작업이 더 커집니다.

프롬프트에는 결과에 반드시 남겨야 할 정보를 적습니다. 다음은 커밋 기록과 내보낸 작업 요약이 포함된 테스트용 입력을 다루는 예입니다. 디렉터리와 파일은 설명을 위한 예시입니다.

지정된 프로젝트 폴더에서 내보낸 테스트 요약과 관련 실패 로그 발췌를 읽으세요. 첫 줄에 입력에서 확인한 실행 ID, 커밋, 타임스탬프를 적으세요. 여러 매트릭스 작업에서 반복된 실패는 묶으세요. 서로 다른 실패마다 테스트 이름, 원인을 파악하는 데 필요한 최소한의 로그 발췌, 원본 경로를 제시하세요. 확인된 실패와 추정 원인을 구분하세요. 요약이 없거나 오래됐거나 불완전하면 어떤 입력이 부족한지 밝히고 중단하세요. 파일은 처음 상태 그대로 두세요.

이런 지시는 모호함을 줄입니다. 터미널에도 요청에 맞는 권한을 부여해야 합니다. 파일을 읽기만 하는 작업이라면 읽기 전용으로 노출하거나 저장소 자격 증명이 없는 일회용 사본을 사용합니다. 실패한 테스트는 소스 파일, 외부 의존성, 테스트용 데이터에서 임의의 텍스트를 출력할 수 있습니다. 그 텍스트는 보고서의 근거 칸에 들어갑니다. 에이전트가 따라야 할 새 지시로 처리할 이유가 없습니다. 담당자가 자는 동안 실행되는 작업에서는 이 경계가 더 중요합니다.

같은 방식으로 또 다른 정기 작업을 만들 수 있습니다. 엔지니어링 리드가 날짜가 기록된 의존성 목록과 별도로 확보한 보안 권고 피드를 전달하고, 버전이 일치할 가능성이 있는 항목을 찾아 관련 기록을 인용하도록 요청하는 경우입니다. 검토에 쓸 결과에는 정확한 패키지명과 버전, 출처가 들어갑니다. 버전 비교는 신뢰할 수 있는 스캐너에서 규칙대로 수행하고, 검토자는 실제 실행 경로가 해당 의존성에 닿는지 판단할 수 있습니다. 입력 파일을 고정해 두면 실행마다 설명이 달라져도 보고서를 재현하기 쉽습니다.

짧은 설정 과정에서 실무에 필요한 대부분을 확인할 수 있습니다

Open WebUI 문서에는 인스턴스 전체의 Automations 설정과 관리자 이외 사용자에게 부여하는 별도 권한이 나옵니다. 인스턴스가 v0.13.3 이상 호환 버전을 실행 중인지, 기능이 켜져 있는지, 계정에 접근 권한이 있는지 확인합니다. 터미널은 연결되어 있어야 하고 자동화에서도 사용할 수 있도록 허용되어야 합니다. 사용 맥락 설정에 따라 모델 편집기에 표시되는 터미널도 자동화 작업에서는 제외될 수 있습니다. 평소 채팅에서 작동하는 작업이 예약 실행에서 실패한다면 이 차이를 확인할 수 있습니다. Open WebUI 자동화 문서 · Open Terminal 연결 문서

  1. 테스트용 입력을 준비합니다. 성공한 실행, 대표적인 실패 사례, 커밋과 타임스탬프를 담은 매니페스트를 임시 작업 공간에 넣습니다. 입력은 작게 유지하고 운영 키, 클라우드 설정, 개인 파일은 작업 공간 밖에 둡니다.
  2. Automations를 열어 작업을 만듭니다. 제목, 프롬프트, 모델, 일정 항목을 입력합니다. 편집기에서 터미널을 고르고 작업 디렉터리를 명시한 뒤, 모델 선택기에서 사용할 코딩 에이전트를 선택합니다. 환경이 해당 폴더에서 사용할 수 있는 에이전트를 보고할 때까지 잠시 기다립니다.
  3. 편집기에서 한 번 실행합니다. 결과 채팅과 실행 로그를 열어 커밋, 원본 파일, 중복 제거, 파일 권한을 확인합니다. 원본 아티팩트와 결과를 대조하고 소스 트리에 변경이 생기지 않았는지 확인합니다.
  4. 실패 조건에서도 실행합니다. 별도 테스트 데이터에서 매니페스트를 제거하거나 의도적으로 오래된 입력을 가리킵니다. 보고서에서 누락된 근거가 드러나야 합니다. 자동화에서 사용할 수 없는 터미널이 실행 이력에 실패로 표시되는지도 확인합니다.
  5. 반복 실행 시간을 정하고 초기 결과를 검토합니다. 예약 시각과 CI 내보내기 완료 시각을 비교합니다. 보고서가 너무 일찍 실행되어 전날 테스트를 읽었다면, 문장이 최신 결과처럼 보이더라도 일정을 고쳐야 합니다. 입력 형식에 대한 약속이 바뀌거나 보고서가 기대와 달라지면 작업을 일시 정지합니다.

테스트용 입력과 보고서 프롬프트는 한 쌍으로 관리합니다. 폴더 이름이나 브랜치 규칙이 바뀌거나 테스트를 다른 모음으로 옮겼다면 예약 작업과 함께 테스트용 입력도 갱신합니다. 그래야 결과를 묶는 데 쓰이는 근거가 작업에서 조용히 사라지는 일을 피할 수 있습니다. 프롬프트를 수정할 때는 이전 예시를 남기고 같은 입력으로 두 결과를 비교합니다. 수정 비용이 가장 낮은 곳은 종종 입력 매니페스트입니다. 두 예약 작업에서 어떤 실행을 최신으로 볼지 일치시켜야 할 때 특히 그렇습니다.

터미널을 선택할 때 접근 권한도 함께 정합니다

자체 호스팅 채팅 인터페이스도 외부 제공자의 모델이나 에이전트에 연결할 수 있습니다. 선택한 에이전트에 연결된 제공자, 전달되는 데이터, 사용할 수 있는 서비스 자격 증명을 확인합니다. 체크아웃을 컨테이너나 일회용 작업 공간에 두면 운영자가 작업 범위를 제한할 수 있습니다. 같은 사용자가 호스트의 다른 영역을 읽을 수 있거나 에이전트가 저장소 쓰기 권한을 가진 자격 증명을 사용한다면 시작 디렉터리만으로는 접근 범위를 제한하기 어렵습니다. Open WebUI 터미널 문서는 자동화를 포함해 터미널을 사용할 수 있는 맥락을 별도로 지정하는 옵션을 설명합니다. 관리자는 작업이 시작되기 전에 노출 범위를 정할 수 있습니다. Open WebUI 터미널 연결 문서

읽기 전용 테스트 데이터와 제한된 터미널에서 얻은 근거를 검토하고 쓰기 작업을 별도로 결정하는 과정

읽기 전용 보고 작업에서는 근거, 실행 권한, 검토 후 결정을 분리합니다. Telli.sh가 직접 제작한 그림입니다.

작업필요한 최소 입력검토할 결과처음에 비활성화해 둘 기능
야간 테스트 요약내보낸 테스트 보고서, 커밋, 선별한 로그 발췌근거와 우선순위가 포함된 실패 목록저장소 쓰기와 배포
의존성 검토버전 목록과 신뢰할 수 있는 보안 권고 스냅샷패키지와 버전이 포함된 일치 후보패키지 업그레이드와 풀 리퀘스트
릴리스 인계릴리스 매니페스트, 테스트 요약, 승인된 이슈 목록누락된 근거와 미해결 항목릴리스 태그 생성과 고객 알림

줄어드는 것은 결과를 열고 어디부터 살펴볼지 파악하기까지 걸리는 시간입니다. 이 작업의 상당 부분은 신뢰할 수 있는 명령으로 처리할 수 있습니다. 명령으로 실행 ID와 상태를 출력하고, 에이전트는 서로 다른 유형의 출력에 담긴 실패를 설명하게 합니다. 이 분담은 작업이 어긋났을 때도 도움이 됩니다. 다른 에이전트를 시험하기 전에 보고서의 ID를 매니페스트와 대조해 입력이 맞는지 확인할 수 있습니다.

같은 점검에서 비용도 확인합니다. 선택한 에이전트가 과금 모델을 호출한다면 예약 실행에도 제공자 사용량이 발생할 수 있습니다. 긴 로그는 입력량을 늘리고 반복되는 테스트 실패는 같은 분석을 반복하게 만들 수 있습니다. 먼저 길이를 제한한 로그 발췌와 짧은 시험 운영 기간으로 실제 검토에 도움이 되는 정보가 얼마나 나오는지 살펴봅니다. 매번 같은 대용량 파일을 읽는다면 비용이 낮은 규칙 기반 절차로 변경 여부를 먼저 기록할 수 있습니다. 실행당 읽을 입력의 상한을 알면 일일 일정의 비용을 가늠하기 쉽습니다.

작은 팀에서는 터미널만큼 담당자도 중요합니다. Open WebUI 문서에 따르면 자동화는 만든 사용자의 소유이며 해당 사용자에게만 공개됩니다. 개인 보고서는 그곳에서 확인하면 됩니다. 여러 사람이 쓰는 릴리스 승인에는 근거 공유와 담당자 부재 시 책임 인계를 누구나 확인할 수 있는 별도 절차가 필요합니다. 자동화 이력으로 개인이 실패 원인을 조사할 수 있고, 공유 CI 점검을 통해 배포하는 팀 전체가 빌드 결정을 확인할 수 있습니다. Open WebUI 자동화 접근 제어

아침 보고서의 가치는 검토할 때 드러납니다

첫 주가 지나면 실제로 누군가 열어본 보고서를 살펴봅니다. 긴급으로 표시된 항목마다 링크나 로그 발췌를 확인하고, 보고서가 실패를 빠뜨리거나 이미 아는 실패를 반복하거나 잘못된 커밋을 인용한 경우를 셉니다. 검토자가 다음으로 조사할 테스트를 찾는 데 도움이 됐는지도 확인합니다. 자동 응답 개수보다 이런 관찰이 예약 작업의 가치를 더 잘 보여줍니다.

결과가 꾸준히 유용하다면 새로운 유형의 근거를 한 번에 파일 하나씩 추가할 수 있습니다. 터미널이 사용할 작업 위치를 고정하고 작업의 자격 증명에 필요한 최소 권한만 부여합니다. 코드와 인프라 변경은 팀에서 쓰던 검토 절차를 거치게 합니다. 아침 보고서를 바탕으로 다음 조치를 정할 수 있고, 의심스러운 항목은 빠르게 검증할 수 있다면 자동화가 제 역할을 하는 것입니다.

출처


작업 과정에서 오간 대화와 결정을 검색할 수 있도록 기록하려면 Telli.sh 계정을 만들어 보세요.


← 블로그로 돌아가기