AI가 화면을 직접 수정하고, AI 검색에서 우리 서비스가 언급되는지 확인하고, 반복되는 운영 업무까지 처리하는 시대입니다.
이번에는 새로운 도구를 무작정 소개하기보다, 실제로 서비스를 만들고 운영하는 입장에서 어디에 활용할 수 있을지 생각해 볼 만한 이야기 세 가지를 모았습니다.
이번 호에서 다룰 이야기
Builder Agent-Native — AI가 수정한 결과를 사용자가 바로 이어서 편집할 수 있을까요?
Bing Topics Portfolio — AI 검색에서 우리 사이트는 얼마나 노출되고 있을까요?
Linear Loops — 매주 반복되는 운영 업무, AI에게 어디까지 맡겨도 될까요?
01. AI가 수정한 화면, 사용자가 바로 이어서 편집할 수 있을까요?
Builder Agent-Native · 2026.10.14 공개
AI에게 고객 목록을 정리해 달라고 요청한 뒤, 결과를 보다가 특정 항목 하나만 직접 수정하고 싶은 경우가 있습니다. 그런데 AI가 처리한 결과와 실제 서비스 화면이 따로 움직인다면 어떨까요? 결과를 다시 확인하고, 수정할 항목을 찾아 직접 고쳐야 하는 번거로움이 생깁니다.
AI 기능을 서비스에 적용할 때는 답변의 품질뿐 아니라 사용자가 그 결과를 어디서 확인하고 어떻게 수정할 수 있는지도 함께 고민할 필요가 있습니다.
Builder가 2026년 10월 14일 공개한 Agent-Native 베타는 이런 문제를 해결하기 위해 만들어진 오픈소스 TypeScript 프레임워크입니다. 핵심은 사용자가 화면에서 실행하는 동작과 AI 에이전트가 실행하는 동작을 하나로 연결하는 것입니다.
기능을 한 번 정의해 두면 화면뿐 아니라 에이전트, HTTP API, CLI, MCP, A2A에서도 같은 기능을 사용할 수 있다고 합니다. 화면과 AI가 동일한 데이터와 현재 선택 상태를 공유할 수도 있고요.
Builder Agent-Native 베타 공식 발표 이미지
작은 운영 도구부터 적용해 보면 어떨까요?
예를 들어 고객 피드백을 관리하는 SaaS를 만든다고 가정해 보겠습니다. 처음부터 복잡하게 만들 필요는 없습니다. '피드백 조회', '분류 수정', '답변 초안 저장' 정도의 기능만으로 시작해 봐도 좋을 것 같습니다.
사용자가 화면에서 피드백 분류를 변경하든, AI에게 "결제 관련 요청만 따로 묶어줘"라고 요청하든 같은 기능을 사용하도록 만드는 겁니다. 이렇게 구성하면 입력값 검증이나 접근 권한 같은 공통 규칙을 한곳에서 관리하기도 수월해집니다.
화면에는 고객이 남긴 원문과 분류, 답변 초안을 나란히 보여주면 좋겠죠. AI가 먼저 분류한 내용을 사람이 확인하고, 잘못된 부분만 직접 수정하는 방식입니다. 여기에 사용자가 선택한 피드백 정보를 AI도 알 수 있도록 연결하면 "이 요청은 버그가 아니라 기능 제안이야"처럼 간단한 대화만으로도 작업을 이어갈 수 있습니다.
물론 이런 고객지원 도구가 기본으로 제공된다는 뜻은 아닙니다. Agent-Native를 활용해 구성해 볼 수 있는 하나의 예시입니다.
공식 GitHub 저장소에서는 defineAction()으로 기능을 정의하고 React에서 호출하는 예제를 확인할 수 있습니다. 로컬 개발용 PGlite와 실제 운영에 사용할 PostgreSQL 구성도 안내하고 있습니다. 기존 React 앱에 에이전트 패널을 추가하는 방법도 소개되어 있고요.
관심이 있다면 공식 예제를 먼저 실행해 보고, 자신의 서비스에 필요한 데이터 구조와 권한 규칙을 조금씩 적용해 보는 것도 좋겠습니다.
실제 서비스에 적용하기 전에 확인할 것들
다만 AI와 사용자가 같은 기능을 실행할 수 있게 만든다고 해서 모든 동작을 자유롭게 허용해도 되는 건 아닙니다. 먼저 데이터를 조회하는 기능과 수정하는 기능을 구분해야 합니다. 고객 목록을 확인하는 것과 실제 고객에게 답변을 보내거나 계정을 삭제하는 것은 전혀 다른 문제니까요. 중요한 작업에는 별도의 확인 과정이 필요할 수 있습니다.
또 한 가지는 동시 수정 문제입니다. 사용자가 어떤 항목을 편집하는 동안 AI도 같은 데이터를 수정한다면 어떤 결과를 우선해야 할까요? 이런 상황도 미리 테스트해야 합니다.
같은 작업을 다시 실행했을 때 초안이나 데이터가 중복 생성되지 않는지도 확인할 필요가 있습니다. 아직 베타 버전이라는 점도 고려해야 합니다. 인증이나 권한, 협업 기능이 제공되더라도 실제 서비스에 적용할 때는 별도의 보안 검증이 필요합니다. 모델 사용료나 데이터베이스, 배포 비용도 구성에 따라 달라질 수 있고요.
자동 분류 결과를 확인하고, 잘못된 항목만 수정하는 흐름
개인적으로 이런 기술을 도입할 때는 AI가 얼마나 많은 일을 처리했는지보다, 잘못된 결과를 사용자가 얼마나 쉽게 발견하고 수정할 수 있는지가 더 중요하다고 생각합니다.
처음부터 모든 작업을 자동화하기보다는 작은 기능에 적용해 보고, 실제 처리 시간과 사용자의 수정 횟수를 비교해 보면 좋겠습니다. 그 결과를 바탕으로 다음에 어떤 작업을 자동화할지 판단하는 편이 더 현실적인 접근이 아닐까 싶습니다.
참고 자료: Builder 공식 발표 · GitHub 저장소
02. AI 검색에서 우리 사이트는 얼마나 노출되고 있을까요?
Bing Topics Portfolio · 2026.10.13 공개
서비스를 운영하면서 소개 글이나 블로그 콘텐츠를 꾸준히 작성하다 보면, 어느 순간부터 어떤 주제로 글을 써야 할지 고민될 때가 있습니다. 특히 요즘처럼 AI 검색까지 신경 써야 하는 상황이라면 생각할 것이 더 많아집니다.
사람들이 어떤 질문을 하고 있는지, 그 질문에 대한 AI의 답변에 우리 사이트가 등장하는지, 아니면 다른 사이트만 소개되고 있는지 확인할 수 있다면 콘텐츠를 기획하는 데 꽤 도움이 되겠죠.
Microsoft Bing이 2026년 10월 13일 발표한 Bing Webmaster Tools의 Topics Portfolio 베타가 바로 이런 정보를 제공하는 기능입니다. Topics Portfolio는 AI Performance에 추가된 기능으로, AI가 답변의 근거를 찾을 때 사용하는 질문인 'grounding query'를 주제별로 묶어서 보여줍니다.
각 주제에 대해 전체 인용 규모를 나타내는 Topic Size, 인용된 사이트 수인 Sites Cited, 관련 질문 수 등을 확인할 수 있습니다. 다만 이 수치들은 정확한 집계값이라기보다는 근사치라는 점을 알아둘 필요가 있습니다.
재미있는 부분은 여기서부터입니다. 각 주제에 포함된 질문 중 우리 사이트가 실제로 인용된 질문과, 다른 사이트는 인용됐지만 우리 사이트는 빠져 있는 질문(Opportunity Queries)을 구분해서 확인할 수 있습니다.
단순히 인기 검색어를 보여주는 것보다 실제 우리 서비스와 관련된 콘텐츠를 기획하는 데 더 유용한 정보가 될 수 있겠다는 생각이 듭니다.
다만 확인할 점도 있습니다. AI Performance 공식 안내에 따르면 집계 대상은 Microsoft Copilot, Bing의 AI 요약, 일부 파트너 서비스입니다. 따라서 이 데이터를 ChatGPT나 Google AI 검색 전체의 노출 현황으로 생각하면 안 됩니다.
또한 10월 13일은 새로운 기능이 발표된 날짜이고, 실제 화면에 표시되는 수치는 사용자가 선택한 조회 기간을 기준으로 합니다.
Bing이 공개한 Topics Portfolio 베타 화면 예시
질문 하나를 실제 제품 경험과 연결해 보기
예를 들어 예약 관리 SaaS를 운영한다고 가정해 보겠습니다. '예약 관리 프로그램' 같은 큰 주제만 보고 관련 글을 계속 작성하는 것보다는, 실제 사용자들이 궁금해하는 구체적인 질문을 찾아보는 편이 좋겠습니다.
만약 '시간대가 다른 고객의 예약은 어떻게 관리하나요?'라는 질문을 발견했다면 어떨까요? 단순히 우리 서비스가 시간대 설정을 지원한다고 소개하는 것보다, 실제 설정 방법과 화면에 표시되는 시간, 설정을 변경할 때 주의해야 할 점까지 한 페이지에 정리하는 겁니다.
물론 이 질문은 설명을 위한 예시이며, 실제 Bing 보고서에 등장한 질문이라는 뜻은 아닙니다.
활용 방법도 크게 복잡하지 않습니다. Bing Webmaster Tools의 AI Performance에서 Topics Portfolio가 표시되는지 확인한 뒤, 최근 1~3개월 정도의 조회 기간을 선택합니다.
먼저 우리 사이트가 인용되고 있는 주제를 살펴보고, 그 안에서 아직 인용되지 않은 질문들을 확인해 보는 겁니다. 그중 우리 제품과 관련이 있고, 실제로 답변할 수 있는 질문 세 개 정도만 골라도 충분할 것 같습니다.
이후 기존 도움말이나 서비스 소개 페이지에서 해당 내용을 제대로 설명하고 있는지 확인하면 됩니다. 이미 관련 페이지가 있다면 굳이 새로운 글을 만들 필요는 없습니다. 설명이 부족한 부분을 보완하거나, 오래된 화면을 교체하고, 빠져 있는 조건을 추가하는 방법도 있겠죠.
실제 서비스의 설정 화면이나 사용 예시를 추가하고, 사용자가 해당 기능을 바로 이용할 수 있도록 링크까지 연결해 두면 더 좋겠습니다.
결국 AI 검색에 노출되는 것도 중요하지만, 그 글을 찾아온 사람이 실제로 자신의 문제를 해결할 수 있어야 한다고 생각합니다.
숫자만 보고 판단하면 안 되는 이유
Topics Portfolio는 아직 베타 기능입니다. Bing에서도 AI의 주제 분류가 정확하지 않을 수 있고, 경쟁사 브랜드와 관련된 질문이 기회 항목으로 표시될 수 있다고 안내하고 있습니다.
또한 데이터가 충분하지 않은 작은 사이트에서는 표시되는 주제가 적거나 기능 자체가 보이지 않을 수도 있습니다. 따라서 관련 메뉴가 보이지 않는다고 해서 우리 사이트의 콘텐츠가 부족하거나 품질이 낮다고 판단할 필요는 없습니다. 경쟁사 이름이 등장한다고 무조건 비교 글을 작성하는 것도 좋은 접근은 아닐 것 같고요.
실제로 콘텐츠를 수정했다면 어떤 질문을 기준으로 수정했는지, 언제 수정했는지 기록해 두는 것도 좋겠습니다. 이후 비슷한 조회 기간을 기준으로 인용 현황이 어떻게 달라졌는지 확인해 보는 겁니다.
물론 AI 검색에서 인용이 늘어났다고 해서 실제 방문자나 가입자가 늘었다는 뜻은 아닙니다. 유입과 가입, 문의 같은 지표는 별도로 확인해야 합니다.
개인적으로 이 기능에서 가장 기대되는 부분은 단순히 AI 검색 노출 수치를 확인하는 것이 아닙니다. '이번에는 어떤 글을 써야 할까?'라는 막연한 고민을 '우리 서비스가 답할 수 있는데 아직 제대로 설명하지 못한 질문은 무엇일까?'라는 구체적인 문제로 바꿀 수 있다는 점입니다.
서비스를 직접 만들고 운영하는 입장에서는 이런 정보가 콘텐츠를 기획하는 데 꽤 유용하게 쓰일 수 있을 것 같습니다.
참고 자료: Topics Portfolio 공식 발표 · AI Performance 공식 안내
03. 매주 반복되는 운영 업무, AI에게 어디까지 맡겨도 될까요?
Linear Loops · 2026.10.13 활용 원칙 공개
서비스를 운영하다 보면 매주 비슷한 업무가 반복됩니다. 고객이 남긴 버그 제보를 정리하고, 중복된 요청을 찾아보고, 다음 회의에서 다룰 내용을 준비하는 일들이 그렇습니다. 작은 팀이라고 이런 업무가 적은 것도 아닙니다. 오히려 인원이 적을수록 반복되는 운영 업무에 들어가는 시간이 부담스러울 수 있습니다.
그렇다면 이런 일들을 AI에게 맡기면 어떨까요? 물론 자동화 자체는 가능하겠지만, 중요한 건 AI가 어떤 자료를 참고하고 어디까지 수정할 수 있도록 허용할 것인지를 정하는 일입니다. 잘못 분류된 요청이 담당자 배정이나 고객 알림으로 바로 이어진다면, 오히려 문제를 수습하는 데 더 많은 시간을 써야 할 수도 있으니까요.
Linear가 2026년 10월 13일 공개한 Loops를 사용하는 다섯 가지 원칙은 이런 부분을 고민할 때 참고할 만한 글입니다. Loops는 자연어로 원하는 업무를 설명하고, 정해진 일정이나 특정 이벤트에 맞춰 Linear Agent가 작업을 실행하도록 만드는 기능입니다.
참고로 이번 글은 Loops의 새로운 출시 소식은 아닙니다. Loops는 2026년 7월 20일 처음 공개됐고, 이번에 올라온 글은 개발자가 실제로 사용하면서 자동화 범위와 책임을 어떻게 넓혀갔는지에 대한 경험을 공유한 내용입니다.
Linear 공식 블로그에 소개된 반복 업무 개선 사례 이미지
처음부터 모든 걸 맡길 필요는 없습니다
글에서 눈여겨볼 만한 사례는 오래된 코드를 정리하는 자동화 과정입니다. 작성자는 처음부터 AI에게 코드를 삭제하거나 여러 이슈에 담당자를 한꺼번에 배정하도록 맡기지 않았습니다. 먼저 정리가 필요한 코드의 후보를 찾게 하고, 어떤 기준으로 판단했는지 확인하면서 규칙을 다듬었습니다.
이후 담당자를 추천하는 이유를 함께 작성하도록 하고, 한 번에 생성하는 이슈도 최대 다섯 개로 제한했습니다. 그렇게 결과를 충분히 확인한 뒤에야 담당자 배정과 에이전트 위임까지 자동화 범위를 넓혔습니다. 이 과정에서도 AI가 만든 PR은 엔지니어가 직접 검토하도록 했고요.
이런 접근은 소규모 SaaS를 운영할 때도 충분히 참고할 수 있을 것 같습니다. 예를 들어 매주 접수된 고객 피드백을 정리한다고 가정해 보겠습니다. 처음부터 중복 요청을 합치거나 담당자를 배정하도록 지시하는 것보다는 다음과 같이 시작하는 겁니다.
이번 주 접수된 요청 중 중복으로 보이는 항목을 찾아서 원문 링크와 판단 이유를 정리해 줘. 담당자나 상태는 변경하지 마.
이 정도만 맡겨도 반복 업무를 줄이는 데 도움이 될 수 있습니다. 몇 차례 실행해 보면서 서로 다른 요청을 중복으로 판단하지는 않았는지 확인하고, 결과가 안정적이라면 검토용 이슈 생성까지 맡기는 방식입니다. 고객에게 실제 답변을 보내거나 업무 상태를 변경하는 단계는 그다음에 고민해도 늦지 않습니다.
Linear의 공식 문서에서도 먼저 Linear Agent와의 채팅에서 원하는 결과를 만든 뒤, 이를 Loop로 전환하는 방식을 권장하고 있습니다. 처음부터 반복 실행을 설정하기보다는 한 번의 실행에서 참고할 자료와 결과 형식을 충분히 맞춰보라는 의미로 이해할 수 있습니다.
실행 기록을 확인하거나 루프 설정을 이전 게시 버전으로 복원하는 방법, 작업 범위와 권한을 검토하는 방법도 문서에 안내되어 있습니다.
반복 실행에는 비용도 고려해야 합니다
자동화할 때는 단순히 어떤 일을 할지만 정해서는 부족합니다. 대상 프로젝트는 무엇인지, 어떤 채널의 자료를 참고할지, 결과를 어디에 남길지, 어떤 항목까지 변경해도 되는지 구체적으로 정할 필요가 있습니다.
그리고 생각보다 놓치기 쉬운 부분이 하나 있습니다. 바로 새로운 내용이 없을 때 어떻게 처리할 것인지입니다.
매번 실행할 때마다 특별한 내용이 없다는 알림이 쌓이면 자동화가 오히려 불편해질 수도 있습니다. 새로운 요청이 없거나 변경된 내용이 없다면 결과만 기록하고 알림은 보내지 않도록 구성하는 것도 방법입니다.
자동화가 제대로 작동하는지 확인할 때는 성공한 결과만 볼 것이 아니라 누락된 요청이나 중복으로 생성된 이슈가 없는지도 살펴봐야 합니다. 실행할 때마다 어느 정도의 비용이 발생하는지도 확인해야 하고요.
접근할 수 있는 데이터의 범위도 중요합니다. Linear 공식 문서에 따르면 기본 Slack 통합에서는 비공개 채널이나 DM 기록을 읽을 수 없습니다. 만약 중요한 제보가 그런 공간에만 남아 있다면 AI가 정리한 내용이 전체 상황을 반영한다고 생각해서는 안 됩니다.
Loops는 현재 유료 플랜에서 제공되고 있으며, Linear Agent를 사용하는 실행에는 AI 크레딧이 소비됩니다. 크레딧이 소진되면 추가 구매나 자동 충전 설정에 따라 실행이 중단될 수도 있으니 운영 비용도 함께 고려해야 합니다.
결국 중요한 건 자동화의 범위입니다
AI에게 많은 일을 한 번에 맡기면 편할 것 같지만, 실제 서비스를 운영하는 입장에서는 결과를 검토하고 문제가 생겼을 때 대응하는 일까지 생각해야 합니다. 처음에는 작은 업무 하나만 맡겨보고, 실행 결과를 확인하면서 문제가 없는 부분부터 자동화 범위를 넓히는 편이 더 안전하다고 생각합니다.
그리고 생성된 이슈 수나 처리 건수만으로 자동화가 잘되고 있는지 판단하기는 어려울 것 같습니다. AI가 처리한 결과를 사람이 다시 수정하는 일이 얼마나 줄었는지가 더 의미 있는 기준이 될 수 있겠죠.
이런 방식은 Linear뿐 아니라 다른 AI 자동화 도구에도 적용할 수 있습니다. 다음에 반복 업무를 자동화한다면, 처음부터 모든 일을 맡기보다는 'AI가 실수하더라도 사람이 쉽게 확인하고 바로잡을 수 있는 가장 작은 작업은 무엇일까?'부터 생각해 보면 좋겠습니다.
작게 시작하고, 결과를 검토하고, 검증된 부분만 조금씩 넓혀가는 방식이 실제 서비스 운영에서는 더 현실적이지 않을까 싶습니다.
참고 자료: Linear 활용 원칙 · Loops 공식 문서 · Loops 최초 출시