Workspace Studio 10월 새 기능 답장 제외와 중첩 조건 준비
2026년 10월 12일 KST 확인. Google은 새 기능을 10월 13일부터 순차 배포하며 표시까지 최대 15일 걸릴 수 있다고 안내해요. 적용 전 최신 공지와 계정 화면을 확인하세요.
Workspace Studio의 메일 흐름에서 첫 문의와 이후 답장을 다르게 처리하고 싶다면, 10월 새 기능의 Gmail Skip Replies와 중첩 조건을 서로 다른 용도로 살펴보세요. 답장 제외는 시작할 메일을 가르는 기능이고, 중첩 조건은 시작한 흐름 안에서 여러 단계로 판단하는 기능이에요. 문서를 찾는 새 단계도 함께 발표됐지만 오늘 모든 계정에서 쓸 수 있다고 단정할 수는 없어요.
이 글은 10월 9일 발표된 기능을 적용하기 전에 정할 조건과 확인할 결과를 설명해요. 새 기능의 실제 편집 화면을 실행하거나 테스트 메일을 보낸 기록은 아니에요. 그림의 메일·분기·문서 상황은 기능의 용도를 구분하기 위한 자체 설계 예시예요.
발표일과 계정 적용일은 달라요
Google의 발표에는 Nested Conditionals, Gmail Skip Replies, Meet Calendar Outputs, Search for a Doc이 포함돼요. Rapid Release와 Scheduled Release 도메인 모두 10월 13일부터 순차 배포가 시작되고, 기능이 보이기까지 최대 15일이 걸릴 수 있어요. 따라서 10월 12일에 편집기에서 새 항목을 못 찾는다는 사실만으로 계정 설정 오류라고 볼 수 없어요.
발표와 순차 배포 시작을 구분한 일정 도해 · 실제 계정 적용 기록 아님
대상은 Workspace Studio에 접근할 수 있는 Google Workspace 고객과 Workspace Individual 구독자예요. 이 문장을 모든 개인 Gmail 계정에서 같은 기능을 바로 쓸 수 있다는 뜻으로 넓히지 마세요. 사용 중인 계정으로 Studio에 접근할 수 있는지와 새 기능이 배포됐는지는 각각 확인할 항목이에요.
기능은 기본으로 켜지는 방식이지만 조직의 Studio 정책을 따라요. 새 배포를 기다리기 위해 기존에 잘 실행되던 흐름을 지우거나 다시 만드는 것은 필요하지 않아요. 먼저 어떤 기능이 보이지 않는지, 어느 계정인지, 확인한 날짜가 언제인지 기록하고 공식 배포 안내와 비교하세요.
첫 수신과 후속 답장 구분
Gmail Skip Replies는 Gmail 스레드 시작 조건에서 후속 답장을 무시하고 최초 수신 메일만으로 흐름이 시작되게 설정할 수 있는 기능이에요. 예를 들어 안내 요청 한 통 뒤에 같은 스레드로 ‘감사합니다’와 추가 확인 답장이 이어졌을 때, 첫 요청을 한 번 처리하려는 업무에서 검토할 수 있어요.
최초 수신과 후속 답장의 처리 기대값 예시 · 실제 실행 화면 아님
이것은 이미 보낸 메일을 취소하거나, 모든 중복 원인을 자동으로 없애는 기능이 아니에요. 같은 요청이 별도의 새 메일로 다시 들어오거나 서로 다른 흐름 두 개가 같은 최초 메일을 처리하는 상황은 후속 답장 제외와 다른 문제예요. 처음 처리할 사건이 ‘스레드의 최초 메일’인지 ‘추가 질문이 담긴 모든 메일’인지부터 정하세요.
후속 답장에 필요한 추가 정보가 들어오는 업무도 있어요. 예를 들어 첫 문의에는 모델명이 없고 다음 답장에 모델명이 온다면, 답장을 모두 무시하는 설정이 목표와 맞지 않을 수 있어요. 최초 접수 알림 흐름과 추가 문의 검토 업무를 구분해 어느 쪽에서 후속 메일을 읽을지 정하는 편이 좋아요.
기존 Gmail 시작 조건에는 다른 흐름이 만든 이벤트를 기본으로 무시하는 별도 동작이 있어요. 다른 흐름이 보낸 메일을 포함하는 옵션과 새 답장 제외를 같은 설정으로 생각하지 마세요. 하나는 이벤트를 만든 흐름과의 관계이고, 다른 하나는 메일 스레드의 후속 답장 여부를 가르는 조건이에요.
중첩 조건은 판단을 단계별로 나눠요
중첩 조건은 흐름 안에 여러 층의 조건 분기를 만들 수 있게 하는 기능이에요. ‘안내 요청인가?’를 확인한 뒤 그 안에서 ‘제품명이 충분히 적혔는가?’를 다시 판단하는 식으로 생각할 수 있어요. 두 질문을 각각 적으면 어느 조건에서 처리 방향이 달라졌는지 읽기 쉬워요.
기존 Check if는 앞 단계의 변수에 contains나 starts with 같은 연산자를 적용하고 AND·OR로 조건을 묶을 수 있어요. AND는 필요한 조건을 함께 만족해야 한다는 뜻이고, OR는 정한 조건 중 어느 하나에 해당하는 경우를 다루는 방식이에요. 중첩 분기 설계와 이 논리식을 한꺼번에 바꾸기보다 각 조건이 뜻하는 자료부터 정하세요.
예를 들어 제품 안내 요청이 아니면 담당자 검토 대상으로 남기고, 안내 요청인데 제품명이 비어 있으면 정보를 더 확인하는 경로로 나눌 수 있어요. 요청 종류와 제품명 유무를 같은 질문으로 묶으면 무엇이 부족한지 설명하기 어려워요. 이 예시는 설계 원리이며 실제 새 편집기의 버튼 위치나 변수 이름을 보여 주는 것은 아니에요.
AI가 요청을 분류하도록 할 때도 조건을 읽어 보세요. Google의 Decide 단계는 내용을 바탕으로 참·거짓 판단을 만들고 Check if로 이어갈 수 있어요. 결과가 참이라는 이유만으로 특정 금액이나 처리 기한까지 확인된 것으로 받아들이면 안 돼요. 분류가 맞는지와 초안에 들어갈 사실이 맞는지는 다른 검사예요.
문서 검색의 예외도 준비하세요
Search for a Doc은 검색 조건에 따라 관련 Google Drive 문서를 동적으로 찾는 새 단계예요. 매번 고정된 문서 하나를 지정하는 구성과 달리, 요청 내용에 맞는 문서를 찾는 작업에 사용할 수 있다는 취지로 발표됐어요. 다만 발표문은 모든 검색 필드·출력 변수·정렬 규칙을 자세히 설명하지 않으므로 실제로 제공되는 항목은 계정 화면에서 확인해야 해요.
검색어를 정할 때는 제품명만 있는 자료와 제품명·버전이 함께 있는 자료를 구분해 보세요. 이름이 비슷한 과거 매뉴얼과 현재 매뉴얼이 있다면 ‘무언가 찾았다’는 사실만으로 바로 답장을 만들기 어려워요. 문서 제목, 적용 대상, 버전이 요청과 맞는지 확인하는 검토 항목을 미리 정하세요.
요청 분류와 찾은 문서 검토를 나눈 설계도 · 새 편집기 UI 아님
문서를 못 찾은 경우, 적합한 문서를 한 개 확인한 경우, 후보가 여러 개라 결정하지 못한 경우의 기대 결과를 각각 적어 보세요. 검색 결과가 한 개라는 이유로 적합성이 보장되는 것은 아니고, 여러 개라는 이유로 첫 항목이 늘 정답인 것도 아니에요. 새 단계가 제공하는 출력으로 확인 가능한 범위와 사람이 검토할 범위를 나누어 구성하세요.
첫 적용에서는 실제 고객에게 바로 보내는 단계보다 검토 가능한 초안이나 본인 확인 대상으로 결과를 읽는 편이 좋아요. Search for a Doc이 문서를 찾아 준다는 사실과 그 문서의 내용을 외부에 공유해도 된다는 판단은 같지 않아요. 해당 문서의 적용 대상과 조직의 정보 공유 기준을 함께 확인하세요.
미표시와 실행 오류 구분
새 항목이 안 보일 때는 배포 시점, Studio 접근 여부, 해당 Workspace 서비스 사용 여부, 조직 정책을 순서대로 확인하세요. Google 관리자 안내는 사용자가 해당 서비스에 접근할 수 있어야 그 서비스의 시작 조건과 단계를 쓸 수 있다고 설명해요. Gmail이나 Drive 사용 조건이 다르면 같은 템플릿도 계정마다 다르게 보일 수 있어요.
업무·학교 계정에서는 사용자가 보안 정책을 임의로 풀어 해결하지 마세요. 관리자에게 계정과 조직 단위, 보이지 않는 기능 이름을 전달해 현재 허용 범위를 확인하면 돼요. 배포 전후 화면 차이를 남겨 두면 단순 배포 대기와 정책상 제한을 구분하는 데 도움이 돼요.
새 기능이 보이는 것과 흐름이 의도한 대로 실행되는 것도 달라요. Activity에서 실행 시작 시간과 개별 단계의 결과를 확인하고, 실제로 만들어진 초안이나 문서와 대조하세요. 첫 메일에서 시작했는지, 후속 답장을 건너뛰었는지, 조건별 경로가 기대와 맞는지 각각 확인해야 해요.
시험 자료별 기대 결과
시험 자료는 최초 요청, 같은 스레드 후속 답장, 별도의 새 요청으로 나누어 준비해 보세요. 각 자료에 대해 ‘시작함·시작하지 않음’과 ‘어느 경로로 감’이라는 기대 결과를 따로 적으면 답장 제외와 중첩 조건의 역할을 구분할 수 있어요. 실제 메일 주소나 고객 문서를 예제로 공개할 필요는 없어요.
Google 도움말의 Test run은 화면만 미리 보여 주는 기능이 아니라 흐름을 즉시 실행해 결과를 확인하는 기능이에요. 실행 전에 마지막 단계가 초안 생성인지 실제 발송인지, 문서 이동이나 행 추가가 포함됐는지 읽어 보세요. 새 기능을 시험한다는 이유로 기존 실제 업무 결과가 반복되도록 해서는 안 돼요.
실행 완료 표시가 나오더라도 결과의 대상과 내용을 직접 읽어 보세요. 메일 한 통이 왔다면 흐름 실행은 몇 번 시작됐는지, 초안은 어느 스레드에 생성됐는지, 찾은 문서는 요청의 제품·버전에 맞는지 확인하는 식이에요. 새 기능에 맞춘 작은 시험이 끝난 뒤 필요한 범위로 확대하세요.
답장과 새 문의의 경계 기록
같은 발신자가 어제 문의에 답장을 보낸 경우와 오늘 다른 건으로 새 메일을 보낸 경우는 구분해 둘 필요가 있어요. 발신자 이름만 같다는 이유로 둘을 같은 상황으로 묶으면 답장 제외의 확인 목적이 흐려져요. 배포 전에는 실제 고객 정보를 옮기지 말고 문의 식별자와 메일 종류를 가상 목록으로 정리할 수 있어요.
설계 목록에는 첫 문의, 그 문의의 후속 답장, 별도 새 문의를 다른 행으로 적어 보세요. 기대하는 시작 여부와 흐름 안에서 필요한 판단을 분리해 쓰는 방식이에요. 이 목록은 실제 Studio가 그렇게 실행됐다는 기록이 아니며, 기능이 배포된 뒤 Activity와 목적지 결과를 대조할 때의 기준이에요.
중첩 조건을 수정하려면 어느 바깥 조건이 먼저 적용되는지와 안쪽 조건의 예외를 같이 기록하세요. 예를 들어 첨부가 있는 문의 안에서 담당 문서를 찾는 설계라면 첨부 없는 문의가 그 안쪽 단계까지 들어갈 필요가 있는지부터 정해야 해요. 조건을 두 개 만들었다는 사실만으로 처리 대상이 좁아졌다고 판단하지 않아요.
설계와 실제 실행이 다르면 처음부터 모든 단계를 고치기보다 시작 대상, 첫 분기, 문서 검색 결과 중 어디부터 어긋났는지 순서대로 비교해요. 실제 외부 발송 단계가 있는 흐름이라면 원래 전송 내용을 확인한 뒤 필요한 변경 범위를 정하세요. 새 기능 배포는 기존 발송을 취소하거나 되돌리는 기능으로 안내된 것이 아니에요.
