6-1. 스킬이 안 불려오는 이유
스킬을 만들어 자리에 두었다. 확인도 됐다. 그런데 며칠 뒤 관련 요청을 던졌더니, 매번 지켜지던 형식이 결과에 빠져 있다. 시키지 않아도 반영되던 조건들이 이번에는 하나도 걸리지 않았다. 스킬은 분명히 있는데, 불려 나오지 않은 것이다.
설명을 고치기 전에 먼저 환경부터 확인한다. 스킬이 현재 계정이나 프로젝트에 설치되어 있는가. 지금 쓰는 제품은 자동 선택을 지원하는가, 아니면 이름으로 직접 호출해야 하는가. 조직 관리자가 스킬 사용을 제한하지 않았는가. 이 셋 중 하나가 원인이면 설명을 아무리 고쳐도 해결되지 않는다. 설치와 권한, 선택 방식을 확인했는데도 자동 선택이 어긋날 때 비로소 설명을 본다.
이럴 때 흔히 드는 생각은 AI가 스킬을 게을리 챙긴다는 것이다. 만들어 두었는데 왜 안 쓰느냐는 답답함이 앞선다. 그러나 원인은 대개 다른 곳에 있다. AI가 이 스킬을 지금 써야 하는지 판단할 근거를, 우리가 충분히 주지 않은 것이다. 그 근거가 담기는 자리가 설명이다. AI 입장에서 보면 이해가 쉽다. 눈앞에 스킬이 여럿 걸려 있고, 각각의 설명만 훑어 지금 요청에 맞는 것을 골라야 한다. 그런데 어느 설명도 이번 요청과 또렷하게 맞물리지 않으면, 아무것도 켜지 않고 그냥 요청에 답한다. 게을러서가 아니라 근거가 없어서다. 근거를 주는 일은 우리 몫이다.
4장에서 설명은 무엇을 하며 언제 쓰는지를 적는 자리라고 했다. 자동 선택을 지원하는 환경에서는 요청과 설명이 맞물려야 스킬이 선택된다. 설명이 흐릿하면 맞는 스킬이 있어도 지나칠 수 있다. 설치와 권한 문제가 아니라면, 자동 선택 문제의 첫 점검 자리는 설명이다.
이 구조를 알면 마음이 한결 편해진다. 스킬이 안 켜지는 것을 AI의 변덕으로 여기면 손쓸 방법이 없다. 그러나 원인이 설명에 있다면, 그것은 우리가 고칠 수 있는 자리다. 안 켜진다는 것은 우리가 발동 조건을 충분히 말하지 않았다는 신호이고, 신호를 받았으면 조건을 채워 넣으면 된다. 발동은 운이 아니라 설명의 문제이므로, 설명을 다루는 법을 익히면 대부분 통제할 수 있다.
한 가지 미리 못 박아 둘 것이 있다. 설명을 아무리 잘 써도 언제나 백 번 다 켜진다고 장담할 수는 없다. 요청은 매번 조금씩 다르고, 표현도 사람마다 다르다. 이 장이 목표하는 것은 완벽한 발동이 아니라, 안 켜지는 흔한 원인을 걷어 내 발동을 안정시키는 것이다. 대부분의 미발동은 설명을 원칙대로 손보는 것으로 사라진다.
이 장을 트리거 설계라 부르는 이유가 여기 있다. 트리거는 스킬을 켜는 방아쇠, 곧 발동 조건이다. 그 조건을 담는 것이 설명이다. 스킬을 만드는 일이 절반이라면, 그 스킬이 제때 켜지도록 설명을 다듬는 일이 나머지 절반이다. 지침을 아무리 잘 써도 스킬이 안 켜지면 소용이 없으니, 어떤 면에서는 설명이 먼저다. 처음 스킬을 만들 때 사람들은 대개 지침에 공을 들인다. 어떻게 할지를 꼼꼼히 적는 데 시간을 쓰고, 언제 쓸지를 적는 설명은 한두 줄로 대충 넘긴다. 그런데 발동을 좌우하는 것은 그 대충 넘긴 설명이다. 공들인 지침이 빛을 보려면 먼저 스킬이 켜져야 하고, 켜지게 하는 것은 설명이다. 힘을 쏟을 자리가 뒤바뀌어 있는 셈이다.
이 장에서는 두 가지 문제를 다룬다. 하나는 필요할 때 안 켜지는 미발동이고, 다른 하나는 엉뚱할 때 켜지는 오발동이다. 두 문제는 반대 방향이지만 뿌리는 같다. 설명이 발동 조건을 제대로 말하지 못한 것이다. 미발동은 조건을 덜 말해서 생기고, 오발동은 조건을 너무 넓게 말하거나 경계를 안 그어서 생긴다. 방향은 반대라도 손보는 자리는 같으니, 하나를 이해하면 다른 하나도 함께 잡힌다. 먼저 설명을 어떻게 써야 하는지 원칙을 세우고, 그다음 실제 사례로 고쳐 본다. 마지막으로 오발동을 다스리는 법을 짚는다. 참고로 이 장은 발동 문제 전담이다. 잘 쓰던 스킬이 시간이 지나며 낡아 고장 나는 경우는 성격이 다른 문제라, 9장에서 따로 다룬다.
6-2. 설명문 작성 원칙 네 가지
발동을 살리는 설명에는 네 가지 원칙이 있다. 하나씩 짚고, 원칙마다 좋은 예를 하나씩 붙인다. 네 원칙은 따로 노는 규칙이 아니라, 설명을 발동 신호로 만드는 한 가지 목표를 네 방향에서 받치는 것이다. 순서대로 언제를 세우고, 그 언제를 실제 어휘로 적고, 언제의 경계를 긋고, 언제가 하나로 또렷하도록 스킬을 다듬는다.
첫 번째 원칙은 무엇을 하는지보다 언제 쓰는지를 먼저 적는 것이다. 설명이라는 말에 이끌려, 이 스킬이 무슨 일을 하는지부터 쓰기 쉽다. 그런데 발동을 판단하는 근거는 언제 쓰는지다. 그래서 설명의 첫머리에는 이 스킬이 활약할 상황이 와야 한다. 나쁜 예는 개조식 보고서를 작성한다이고, 좋은 예는 매주 월요일 팀 주간 보고 초안을 만들 때 사용한다이다. 앞은 기능을 말하고, 뒤는 상황을 말한다. 무엇을 하는지는 상황 뒤에 덧붙이면 된다. 순서만 바꿔도 발동이 나아진다. 이 원칙이 왜 첫째인가 하면, 나머지 세 원칙이 모두 이 언제를 더 정확하게 다듬는 방법이기 때문이다. 언제를 어떤 어휘로 적을지, 언제의 경계를 어디까지 그을지, 언제가 하나로 또렷한지가 뒤따르는 세 원칙이다. 그러니 먼저 설명을 언제의 진술로 세워 놓아야 한다. 이 첫 단추를 잘못 끼우면, 뒤의 세 원칙을 아무리 정성껏 적용해도 발동이 잡히지 않는다.
두 번째 원칙은 사용자가 실제로 칠 문장의 어휘로 적는 것이다. AI는 요청 문장과 설명을 맞춰 본다. 그런데 설명을 만든 사람만 쓰는 용어로 적어 두면, 정작 요청할 때 쓰는 말과 어긋나 안 걸린다. 나쁜 예는 정기 보고 산출물을 표준화한다처럼 격식 있는 용어로 적는 것이다. 좋은 예는 주간 보고 만들 때, 이번 주 보고 정리할 때처럼 실제로 던질 법한 말로 적는 것이다. 평소에 이 일을 시키며 어떻게 말하는지를 떠올려, 그 말을 설명에 담는다. 설명은 문서가 아니라 신호라, 실제 어휘에 가까울수록 잘 잡힌다. 사람은 설명을 쓸 때 무의식적으로 격식을 차리는 경향이 있다. 문서처럼 보이려고 딱딱한 용어를 고르는 것이다. 그러나 설명의 독자는 사람이 아니라 요청을 맞춰 볼 AI다. 그러니 보고서를 쓰듯 격식을 차릴 것이 아니라, 평소 말투 그대로 적는 편이 발동에 유리하다. 한 업무를 여러 표현으로 부른다면, 자주 쓰는 표현 두엇을 설명에 함께 담아 두어도 좋다.
세 번째 원칙은 범위의 경계를 밝히는 것이다. 언제 쓰는지만큼 언제 쓰지 않는지도 중요하다. 경계가 없으면 비슷해 보이는 다른 요청에까지 끌려 나온다. 그래서 좋은 설명은 이럴 때는 쓰지 않는다를 한 줄 담는다. 좋은 예는 주간 보고 초안을 만들 때 쓴다, 월간 실적 보고나 회의록에는 쓰지 않는다처럼, 쓰는 상황과 안 쓰는 상황을 함께 적는 것이다. 경계 한 줄이 미발동과 오발동을 동시에 줄인다. 어디까지가 이 스킬의 영역인지가 분명해지기 때문이다. 경계를 정할 때는 이 스킬과 헷갈릴 만한 이웃 업무를 떠올리면 쉽다. 주간 보고 옆에는 월간 실적 보고가 있고, 회의록 정리가 있다. 그 이웃들을 안 쓰는 상황으로 적어 두면, 스킬이 자기 자리를 넘어 옆으로 넘어가지 않는다. 경계가 없는 설명은 문을 활짝 열어 둔 것과 같아서, 지나가던 요청까지 안으로 끌어들인다.
네 번째 원칙은 한 스킬에 한 역할만 담는 것이다. 앞서 말한 최소 단위가 여기서 다시 나온다. 하나의 스킬이 여러 업무를 담으면, 설명도 여러 상황을 가리키게 되어 어느 것에도 또렷하지 않다. 나쁜 예는 각종 문서를 정리한다처럼 넓게 잡는 것이다. 좋은 예는 주간 보고 하나만 가리키는 설명이다. 업무가 하나면 설명도 한 상황을 또렷하게 말할 수 있고, 그만큼 발동이 정확해진다. 설명이 자꾸 여러 상황을 담게 된다면, 그것은 설명의 문제가 아니라 스킬을 쪼개야 한다는 신호다. 이 원칙은 앞의 세 원칙과 층위가 조금 다르다. 앞의 셋은 설명을 어떻게 쓰는지에 관한 것이고, 이 넷째는 애초에 스킬을 어떤 크기로 만드는지에 관한 것이다. 설명을 아무리 다듬어도 스킬 자체가 여러 역할을 안고 있으면 발동이 또렷해지지 않는다. 그럴 때는 설명을 손보기 전에 스킬을 나누는 것이 먼저다.
네 원칙은 결국 한 방향을 가리킨다. 설명을 이 스킬이 정확히 언제 켜지고 언제 안 켜지는지를 말하는 신호로 만드는 것이다. 무엇을 하는지만 적는 데서 멈추지 않고, 발동 조건까지 함께 적으면 대부분의 미발동이 풀린다.
네 원칙을 한 문장으로 압축하면 이렇게 된다. 이 스킬을 언제 쓰는지를, 실제로 쓰는 말로, 경계까지 함께, 하나의 상황으로 적는다. 이 한 줄을 설명을 쓸 때마다 떠올리면 된다. 대단한 기교가 필요한 것이 아니라, 기능 소개에 상황 안내를 얹는 관점의 전환이다. 관점이 바뀌면 같은 스킬이라도 설명이 달라지고, 설명이 달라지면 발동이 달라진다.
6-3. Before/After 세 세트
원칙을 실제 설명에 대 보면 감이 잡힌다. 서로 다른 업무로 세 세트를 본다. 같은 업무를 반복하면 원칙이 그 업무에만 붙는 요령처럼 보이므로, 일부러 매번 다른 업무를 골랐다. 각 세트는 흔한 실수 하나와 그 수정을 보여 준다. 세 실수는 각각 앞의 원칙 하나에 대응한다. 고치기 전과 후를 나란히 두고, 무엇이 발동을 막았고 무엇이 발동을 살렸는지 짚는다.
첫 번째 세트는 기능만 나열한 설명을 발동 조건이 있는 설명으로 바꾸는 경우다. 고객 응대 메일을 정중한 톤으로 다듬는 스킬을 예로 든다.
Before: 이메일을 정중한 존댓말로 교정하고 문장을 다듬는다.
After: 고객에게 보내는 사과나 안내 메일을 쓸 때 사용한다. 정중한 존댓말로 다듬고 문장을 매끄럽게 고친다.
Before의 문제는 무엇을 하는지만 있고 언제 쓰는지가 없다는 것이다. 그래서 AI가 지금 요청이 이 스킬을 부를 상황인지 판단할 근거가 없다. 정중하게 다듬는다는 기능은 여러 상황에 두루 걸릴 수 있어서, 정작 고객 메일이라는 특정 상황을 콕 집어 주지 못한다. After는 첫머리에 고객 메일을 쓸 때라는 상황을 넣어 발동 근거를 만들었다. 첫 번째 원칙을 적용한 것이다. 기능은 그대로 두되 그 앞에 상황을 얹은 것뿐인데, AI가 이 요청이 그 상황인지 아닌지 판단할 수 있게 됐다.
두 번째 세트는 만든 사람만 아는 용어를 사용자 어휘로 바꾸는 경우다. 여러 줄의 데이터를 표로 정리하는 스킬을 예로 든다.
Before: 비정형 데이터를 정형화하여 표 형식으로 구조화한다.
After: 뒤섞인 숫자나 목록을 표로 깔끔하게 정리할 때 사용한다.
Before의 문제는 정형화, 구조화 같은 말이 정작 요청할 때 쓰는 어휘와 멀다는 것이다. 실제로는 이거 표로 정리해 줘라고 말하지, 정형화해 줘라고 말하지 않는다. 그래서 요청과 설명이 어긋나 안 걸린다. Before의 설명은 그 자체로는 정확하고 전문적으로 보인다. 바로 그 점이 함정이다. 전문적으로 보이려는 용어가 실제 요청 어휘에서 멀어지면, 보기에는 그럴듯해도 발동은 되지 않는다. After는 표로 정리한다는 실제 어휘로 바꿔 요청과 맞물리게 했다. 두 번째 원칙을 적용한 것이다. 설명이 덜 있어 보여도, 걸리는 설명이 안 걸리는 설명보다 낫다. 자기 설명이 이 함정에 빠졌는지 확인하는 방법은 간단하다. 그 설명 문장을, 이 일을 부탁할 때 실제로 이렇게 말하는지 소리 내어 읽어 본다. 입에 붙지 않는 딱딱한 말이 있으면, 그 자리를 평소 말투로 바꾼다.
세 번째 세트는 만능형 설명을 경계가 있는 설명으로 바꾸는 경우다. 긴 문서를 요약하는 스킬을 예로 든다.
Before: 모든 종류의 문서를 요약한다.
After: 회의 자료나 리포트처럼 긴 글을 핵심 위주로 요약할 때 사용한다. 짧은 메시지나 한두 문단짜리 글에는 쓰지 않는다.
Before의 문제는 모든 종류라는 말 때문에 경계가 없다는 것이다. 넓게 잡으면 많은 상황을 잡을 것 같지만, 실제로는 반대다. 경계가 없으면 이 스킬이 어디에 특화됐는지가 흐려져, 정작 긴 문서 요약이라는 본래 상황에서도 다른 스킬과 뒤섞인다. 게다가 한 문장만 다듬어 달라는 요청에도 튀어나와 오발동을 일으킨다. After는 긴 글에 쓰고 짧은 글에는 안 쓴다는 경계를 넣어, 켜질 상황과 안 켜질 상황을 함께 그었다. 세 번째 원칙을 적용한 것이다. 넓힐수록 강해지는 것이 아니라, 좁힐수록 또렷해진다. 경계를 그을 때 안 쓰는 상황은 두루뭉술한 반대말이 아니라, 실제로 헷갈릴 만한 이웃을 적어야 한다. 짧은 글에는 쓰지 않는다처럼, 이 스킬이 잘못 끼어들 법한 구체적 상황을 짚어 두는 것이다. 그래야 경계가 실제로 작동한다.
세 세트를 나란히 보면 공통점이 드러난다. 고치기 전 설명은 모두 무엇을 하는지에 머물렀고, 고친 뒤 설명은 언제 쓰는지와 언제 안 쓰는지를 담았다. 세 세트 모두, 담긴 기능 자체는 크게 바뀌지 않았다. 바뀐 것은 그 기능을 감싸는 상황의 유무다. 기능 서술만으로는 발동 근거가 약하고, 상황 진술이 붙을 때 스킬이 제때 켜진다.
고치는 방법은 앞 장들과 같다. 대화로 부탁하면 된다. 이 스킬이 잘 안 켜진다고 말하고, 설명을 발동 조건 중심으로 다시 써 달라고 하면 AI가 원칙에 맞게 다듬어 준다. 다듬은 설명을 확인하고 저장한 뒤, 이름을 부르지 않고 평소처럼 요청을 던져 켜지는지 본다. 한 번에 안 되면 상황 표현을 조금 바꿔 다시 시도한다. 설명을 손보고 확인하기를 두어 번 반복하면 대개 안정된다.
6-4. 오발동 다스리기
미발동의 반대편에 오발동이 있다. 엉뚱한 상황에서 스킬이 튀어나오는 경우다. 회의록을 부탁했는데 주간 보고 스킬이 끼어들거나, 짧은 메모를 다듬으려는데 긴 문서 요약 스킬이 발동하는 식이다. 결과가 안 나오는 것도 곤란하지만, 안 맞는 스킬이 끼어드는 것도 그만큼 성가시다. 오발동은 미발동보다 알아채기 어려운 면이 있다. 안 켜지면 조건이 빠진 것이 눈에 보이지만, 엉뚱하게 켜지면 결과가 그럴듯해 보여 문제를 지나치기 쉽다. 회의록을 부탁했는데 주간 보고 형식이 섞인 결과가 나와도, 형식이 나름 갖춰져 있어 그냥 넘어가는 것이다. 그래서 오발동은 결과가 요청과 정말 맞는지 한 번 더 살펴야 드러난다.
오발동의 원인은 크게 둘이다. 하나는 설명이 지나치게 넓은 경우다. 앞의 세 번째 세트에서 본 모든 종류의 문서 같은 설명이 여기 해당한다. 이럴 때는 경계 문장을 더한다. 이럴 때는 쓰지 않는다를 설명에 넣어, 스킬이 자기 영역 밖으로 나가지 않게 막는다. 세 번째 원칙을 오발동 쪽에서 다시 쓰는 셈이다. 흥미로운 것은, 미발동을 고치려 설명을 넓게 늘리다 오발동을 부르는 경우가 많다는 점이다. 안 켜지니까 이것저것 상황을 더 담다 보면, 경계가 무너져 엉뚱한 데서 켜진다. 그래서 설명은 넓히는 방향이 아니라 또렷하게 하는 방향으로 손봐야 한다. 상황을 더 담는 것과 경계를 지우는 것은 다르다.
다른 하나는 두 스킬의 영역이 겹치는 경우다. 비슷한 일을 하는 스킬이 둘 있으면, AI가 어느 것을 부를지 헷갈려 엉뚱한 쪽을 켠다. 이럴 때는 두 스킬의 경계를 설명에 명시하고, 이름을 더 구체적으로 갈라 준다. 보고 정리라는 두루뭉술한 이름 둘 대신, 주간 보고 정리와 월간 실적 정리로 이름과 설명을 갈라 두면 겹침이 줄어든다. 이때 두 스킬의 설명을 각각 손보는 것이 중요하다. 한쪽만 좁히고 다른 쪽을 그대로 두면, 넓은 쪽이 여전히 좁은 쪽의 영역까지 끌어당긴다. 겹치는 둘은 함께 다뤄야 경계가 제대로 선다. 서로에게 저쪽은 이럴 때 쓰고 나는 이럴 때 쓴다고 알려 주는 셈이다.
겹침이 자꾸 반복된다면, 이름과 설명을 손보는 것으로는 부족하다는 신호이기도 하다. 그럴 때는 두 스킬이 실은 하나로 합쳐야 할 것을 억지로 나눈 것이거나, 반대로 하나에 두 역할이 섞여 자꾸 부딪히는 것이다. 최소 단위로 돌아가, 한 스킬에 한 역할이 되도록 다시 나눈다. 발동 문제의 상당수는 결국 스킬을 적정한 크기로 손보는 것으로 풀린다. 설명을 다듬어도, 이름을 갈라도 겹침이 남는다면, 문제는 표현이 아니라 스킬의 구획에 있다.
여기까지가 발동 문제다. 미발동은 설명에 발동 조건을 채워 풀고, 오발동은 설명에 경계를 그어 푼다. 둘 다 손대는 자리는 설명이다. 두 문제가 반대 방향처럼 보여도 같은 자리를 손본다는 점이, 이 장을 트리거 설계라는 한 주제로 묶는 이유다. 다만 지금 다룬 것은 스킬을 처음 만들거나 얼마 안 됐을 때의 발동 문제다. 오래 잘 쓰던 스킬이 어느 날부터 결과가 어긋나거나, 지침이 자꾸 불어나 무거워지는 것은 발동이 아니라 노후의 문제다. 그것은 축적된 다음에야 나타나는 후기 고장이라, 9장에서 따로 다룬다. 지금 스킬이 안 켜지거나 엉뚱하게 켜진다면, 그 답은 이 장 안에 있다. 설명을 발동 신호로 다듬는 것, 그것이 이 장이 건네는 도구다.
