8부 42장. 스킬이란 무엇인가

매번 길게 설명하는 삶에서 벗어나기

AI를 처음 쓸 때 사람들은 대개 이렇게 일한다. 하고 싶은 일을 떠올리고, 그때그때 긴 설명을 붙인다. 배경을 적고, 원하는 형식을 적고, 주의사항을 적고, 예시를 붙이고, 마지막에 "이런 톤으로 써 줘"까지 덧붙인다. 한두 번은 괜찮다. 하지만 같은 종류의 일을 여러 번 반복하기 시작하면 금방 피곤해진다.

예를 들어 매주 회의록을 정리한다고 해 보자. 회의 내용을 요약하고, 결정 사항을 뽑고, 담당자별 액션 아이템을 정리하고, 다음 회의 전에 확인할 항목까지 묶어 달라고 매번 길게 써야 한다면 어떨까. 분명 AI를 쓰고 있는데, 이상하게 내가 더 바빠진 느낌이 든다.

이때 필요한 것이 바로 스킬이다. 스킬은 한마디로 말해, 반복해서 쓰는 일하는 방식을 재사용 가능한 형태로 묶어 놓은 것이다. 매번 처음부터 설명하지 않아도, AI가 "아, 이 일은 이런 순서와 기준으로 하면 되는 거지" 하고 익숙하게 움직이게 만드는 장치라고 생각하면 된다.

스킬은 저장된 프롬프트보다 크다

스킬을 단순히 "저장해 둔 프롬프트" 정도로 생각하면 반만 맞다. 물론 스킬 안에는 프롬프트가 들어갈 수 있다. 하지만 스킬은 대개 그보다 조금 더 크다.

저장된 프롬프트가 "이렇게 말해 달라"에 가깝다면, 스킬은 "이 일을 이런 절차로 처리하라"에 가깝다. 다시 말해 스킬은 문장 하나가 아니라, 작업 방식의 묶음이다.

예를 들어 "블로그 글 초안을 써 줘"는 요청이다. "제품 소개 글을 쓸 때는 먼저 독자 수준을 확인하고, 핵심 문제를 한 문단으로 요약한 뒤, 기능 설명보다 사용 장면을 먼저 보여 주고, 마지막에는 행동 유도 문장을 넣어라"는 작업 방식이다. 후자가 스킬에 가깝다.

그래서 스킬은 보통 이런 것들을 함께 담는다.

• 어떤 상황에서 이 스킬을 쓰는가

• 목표가 무엇인가

• 어떤 입력이 필요하고 무엇이 부족하면 먼저 물어봐야 하는가

• 어떤 순서로 처리해야 하는가

• 결과를 어떤 형식으로 내야 하는가

• 마지막에 무엇을 점검해야 하는가

즉, 스킬은 말하자면 AI에게 주는 작업 카드, 작은 운영 매뉴얼, 혹은 자주 쓰는 레시피다.

도구와 스킬은 다르다

앞 장에서 우리는 파일, 데이터베이스, 검색, 캘린더, 문서 같은 도구 연결을 보았다. 여기서 많은 사람이 헷갈린다. "도구를 연결했으면 그게 곧 스킬 아닌가요?" 비슷해 보이지만 둘은 다르다.

도구는 AI가 사용할 수 있는 손과 발에 가깝다. 파일을 읽고, 검색하고, 문서를 만들고, 일정을 잡는 능력이다. 반면 스킬은 그 손과 발을 어떤 순서와 기준으로 움직일지 정해 주는 일하는 방식이다.

망치가 있다고 집이 저절로 지어지지 않는 것과 비슷하다. 망치는 도구다. "먼저 치수를 재고, 자재를 확인하고, 순서대로 조립하고, 마지막에 흔들림을 점검한다"는 것은 작업 방식이다. 스킬은 바로 그 작업 방식을 AI가 반복해서 재현하도록 만드는 것이다.

같은 도구를 연결해 두어도 스킬이 없으면 AI는 매번 다른 방식으로 일할 수 있다. 어떤 날은 너무 길게 요약하고, 어떤 날은 핵심을 빼먹고, 어떤 날은 형식이 들쭉날쭉할 수 있다. 반대로 스킬이 잘 잡혀 있으면, AI는 비슷한 품질과 구조로 결과를 내기 쉬워진다.

워크플로와 스킬도 다르다

스킬은 워크플로와도 구분해서 이해할 필요가 있다. 둘은 가깝지만 크기가 다르다.

워크플로는 보통 일 전체의 흐름을 말한다. 예를 들어 시장 조사를 하고, 비교표를 만들고, 시사점을 뽑고, 발표 자료로 바꾸고, 회의 후 액션 아이템을 정리하는 큰 흐름이다. 반면 스킬은 그 안에서 반복적으로 쓰이는 작은 기능 단위에 가깝다.

예를 들어 이런 식으로 볼 수 있다.

• 워크플로: 고객 인터뷰 분석부터 보고서 작성까지의 전체 흐름

• 스킬: 인터뷰 기록에서 반복되는 불만 패턴만 뽑아 정리하는 방식

• 도구: 인터뷰 파일을 읽고 결과를 문서로 저장하는 연결 기능

이 차이를 이해하면 머리가 훨씬 맑아진다. 도구는 능력, 스킬은 방식, 워크플로는 흐름이다. 셋이 합쳐질 때 비로소 AI가 일을 잘한다.

스킬은 AI를 '익숙한 동료'처럼 만든다

스킬의 가장 큰 장점은 속도보다도 익숙함이다. AI가 매번 낯선 사람처럼 굴지 않고, 어느 정도 팀의 방식에 맞춰 일하기 시작한다.

사람끼리 일할 때도 비슷하다. 처음 함께 일하는 동료에게는 하나부터 열까지 설명해야 한다. 하지만 몇 번 같이 일하고 나면 "이번에도 지난번 방식으로 정리해 주세요"라는 말만 해도 통한다. 스킬은 바로 그 통하는 부분을 AI에게 만들어 준다.

그래서 스킬이 쌓이면 요청도 짧아진다. 예전에는 "첨부한 회의록을 읽고, 핵심 결정 사항과 미결 이슈를 구분하고, 담당자별 액션 아이템을 표로 정리하고, 경영진용 한 문단 요약도 함께 써 줘"라고 길게 써야 했다면, 이제는 "회의 정리 스킬로 처리해 줘"라고 말할 수 있다.

물론 실제 시스템에서는 그 한마디 뒤에 이미 많은 것이 숨어 있다. 어떤 문서를 읽어야 하는지, 무엇을 우선순위로 봐야 하는지, 출력 형식은 어떤지, 누락되면 안 되는 항목은 무엇인지가 스킬 안에 담겨 있기 때문이다.

좋은 스킬에는 구조가 있다

스킬은 감으로 만들면 금방 무너진다. 이름만 멋지고 실제로는 결과가 들쭉날쭉한 경우가 많다. 좋은 스킬에는 최소한의 구조가 필요하다.

가장 기본이 되는 구조는 다음과 같다.

• 목적: 이 스킬은 무엇을 위해 존재하는가

• 입력: 어떤 자료나 정보가 들어와야 하는가

• 절차: 어떤 순서로 처리하는가

• 출력: 결과를 어떤 형식으로 내는가

• 점검 기준: 마지막에 무엇을 확인해야 하는가

이 다섯 가지가 분명하면 스킬은 훨씬 안정적이 된다. 반대로 이 중 하나라도 흐리면 문제가 생긴다. 목적이 흐리면 쓸데없이 넓게 일하고, 입력이 흐리면 엉뚱한 자료를 참고하고, 절차가 흐리면 매번 다른 방식으로 처리하고, 출력이 흐리면 결과를 다시 손봐야 하며, 점검 기준이 없으면 그럴듯하지만 위험한 결과가 나온다.

스킬을 만들 때는 거창하게 생각할 필요가 없다. "우리 팀은 회의 정리를 어떻게 하는가", "나는 자료 조사 후 메모를 어떤 형식으로 남기는가", "초안을 쓴 뒤 무엇을 기준으로 다듬는가" 같은 익숙한 습관을 문장으로 꺼내기만 해도 좋은 출발이 된다.

예시로 보면 더 쉽다

가장 단순한 비교를 해 보자.

먼저 스킬이 없는 상태다. 사용자는 이렇게 말한다.

"다음 문서를 읽고 핵심 내용 요약해 주고, 중요한 숫자 뽑고, 위험 요소도 정리해 주고, 마지막에는 팀장에게 보고할 수 있게 5줄 요약을 따로 써 줘."

이 요청은 나쁘지 않다. 하지만 다음번에는 문장이 조금 달라지고, 또 다음번에는 출력 형식이 바뀌고, 어떤 날은 위험 요소를 빼먹고, 어떤 날은 숫자 기준이 달라질 수 있다.

이번에는 스킬이 있는 상태를 보자. "리서치 브리프 정리 스킬"이 이미 만들어져 있다고 하자. 이 스킬은 긴 문서를 읽을 때 핵심 주장, 근거 숫자, 위험 요인, 의사결정용 요약을 일정한 형식으로 정리하도록 설계되어 있다. 그러면 사용자는 이렇게만 말해도 된다.

"이 문서를 리서치 브리프 정리 스킬로 처리해 줘."

짧아졌지만, 실제로는 오히려 더 정교해진 것이다. 왜냐하면 AI가 이미 익숙한 절차를 따라가기 때문이다.

이런 식의 스킬은 다양한 분야에서 쓸 수 있다. 회의 정리, 인터뷰 분석, 보고서 초안, 이메일 답장 초안, 코드 리뷰 요약, 장애 보고 정리, 학습 노트 생성, 강의 내용 복습, 콘텐츠 변환 같은 일은 스킬로 만들기 좋다.

스킬은 조직의 '숨은 노하우'를 꺼내는 방법이기도 하다

스킬의 진짜 흥미로운 점은 개인 생산성에만 있지 않다. 스킬은 조직 안에 숨어 있는 일하는 방식을 밖으로 꺼내는 도구이기도 하다.

많은 팀에는 암묵지가 있다. 누군가는 회의록을 유난히 잘 정리하고, 누군가는 고객 인터뷰에서 중요한 부분만 쏙쏙 뽑아내며, 누군가는 복잡한 자료를 경영진용 한 장으로 아주 잘 압축한다. 그런데 그 능력이 머릿속 감각으로만 남아 있으면, 다른 사람은 따라 하기 어렵다.

스킬은 그 감각을 언어로 바꾸게 만든다. "무엇을 먼저 보고, 무엇을 버리고, 무엇을 남기며, 어떤 기준으로 정리하는가"를 적어 두면, 그것은 더 이상 개인의 비밀 기술이 아니다. 팀이 함께 쓰는 작업 방식이 된다.

이 점에서 스킬은 단순한 자동화 도구가 아니다. 잘하는 사람의 일하는 법을 재사용 가능한 형태로 정리하는 과정이기도 하다. 그래서 스킬을 만들다 보면, 오히려 내가 평소 어떻게 일하는지 더 잘 보이기도 한다.

스킬이 있으면 프롬프트는 더 짧아지고, 품질은 더 안정된다

스킬의 효과는 꽤 실용적이다. 가장 먼저 체감되는 것은 프롬프트 길이가 줄어든다는 점이다. 같은 설명을 반복하지 않아도 되기 때문이다.

하지만 더 중요한 변화는 결과 품질의 안정성이다. 매번 길게 설명해도 사람은 빠뜨린다. 어떤 날은 제약 조건을 빼먹고, 어떤 날은 형식을 말하지 않고, 어떤 날은 중요한 기준을 잊는다. 스킬은 이런 흔들림을 줄여 준다.

또 하나의 장점은 협업이다. 내가 잘 쓰는 방식을 혼자만 갖고 있지 않고, 팀 안에서 공유할 수 있기 때문이다. 새로 들어온 사람도 긴 노하우를 처음부터 배우기보다, 이미 정리된 스킬을 통해 일정 수준의 결과를 빠르게 낼 수 있다.

결국 스킬은 AI에게 편한 기능인 동시에, 사람에게도 편한 장치다. 설명 비용을 줄이고, 반복 피로를 줄이고, 결과의 모양을 맞춰 준다.

그렇다고 모든 것을 스킬로 만들 필요는 없다

여기서 한 가지 오해를 조심해야 한다. 반복된다고 해서 무조건 스킬로 만들 필요는 없다.

스킬은 비슷한 구조가 자주 반복되는 일에 특히 잘 맞는다. 반대로 매번 목표가 크게 다르고, 판단 기준이 자주 바뀌고, 창의적 방향 전환이 핵심인 일은 지나치게 스킬화하면 오히려 답답해질 수 있다.

예를 들어 매주 같은 형식으로 회의 정리를 하는 일은 스킬화하기 좋다. 하지만 아직 문제 정의도 안 된 새로운 사업 아이디어를 탐색하는 초기 단계라면, 너무 이른 스킬화가 사고를 좁힐 수 있다. 그때는 열린 대화와 탐색이 더 중요하다.

또 스킬은 한번 만들고 끝나는 것도 아니다. 현실의 일은 바뀐다. 보고 형식이 바뀌고, 팀의 기준이 바뀌고, 사용하는 도구가 바뀌고, 중요하게 보는 지표도 바뀐다. 스킬도 함께 업데이트해야 한다. 오래된 스킬은 익숙하지만 위험하다. 마치 예전 양식으로만 일하는 베테랑처럼, 빠르지만 현재 기준과 어긋날 수 있다.

스킬은 사람을 대체하는 것이 아니라, 사람의 판단을 더 중요한 곳에 남긴다

스킬 이야기를 하면 종종 "그럼 사람은 뭘 하죠?"라는 질문이 나온다. 오히려 반대다. 스킬은 사람의 일을 없애기보다, 사람의 판단을 더 중요한 곳에 남기게 만든다.

반복적이고 형식적인 설명은 AI에게 넘길 수 있다. 하지만 어떤 관점을 택할지, 무엇을 우선순위로 볼지, 어떤 결과를 실제로 실행할지는 여전히 사람이 정해야 한다. 스킬은 그 사이에서 다리 역할을 한다.

즉, 사람은 기준을 정하고, 스킬은 그 기준을 반복 가능한 절차로 바꾸고, AI는 그 절차를 빠르게 실행한다. 이 구조가 잡히면 AI 활용이 훨씬 편안해진다. 모든 것을 일일이 지시하지 않아도 되지만, 그렇다고 통제력을 잃는 것도 아니기 때문이다.

앞으로 점점 중요해질 이유

AI가 더 많은 도구와 연결되고, 더 긴 작업을 수행하고, 더 복잡한 워크플로 안에서 움직일수록 스킬의 중요성은 더 커진다. 이유는 간단하다. 능력이 커질수록 방식이 더 중요해지기 때문이다.

아무리 똑똑한 AI라도, 어떤 기준으로 일해야 하는지 모르면 힘만 센 초보자에 가깝다. 반대로 스킬이 잘 정리된 AI는 훨씬 믿을 만하다. 파일을 읽고, 검색하고, 문서를 만들 수 있는 능력 위에, "우리 방식대로 일하는 법"까지 얹히기 때문이다.

그래서 앞으로 AI를 잘 쓰는 사람은 단지 프롬프트를 잘 쓰는 사람에 머물지 않는다. 반복되는 작업을 관찰하고, 그 안의 절차를 뽑아내고, 그것을 스킬로 정리할 줄 아는 사람이 된다. 그 사람은 AI를 한 번 잘 부리는 것이 아니라, 계속 잘 일하게 만든다.

이 장의 핵심 정리

스킬은 반복 가능한 작업 절차를 재사용 가능한 단위로 묶어 놓은 것이다. 매번 긴 프롬프트를 다시 쓰지 않아도, AI가 익숙한 방식으로 일하게 만드는 장치라고 할 수 있다.

도구가 AI의 손과 발이라면, 스킬은 그 손과 발을 어떻게 움직일지 정하는 작업 방식이다. 그리고 워크플로가 일 전체의 흐름이라면, 스킬은 그 안에서 자주 반복되는 작은 기능 단위다.

좋은 스킬은 목적, 입력, 절차, 출력, 점검 기준을 분명히 담고 있다. 이런 구조가 있어야 프롬프트는 짧아지고, 결과는 더 안정되며, 팀의 노하우도 공유하기 쉬워진다.

결국 스킬의 핵심은 거창한 기술이 아니다. AI에게 매번 처음부터 설명하지 않고도, 익숙하게 일하게 만드는 방법이다. 그리고 바로 그 지점에서 AI 활용은 "잘 물어보는 단계"를 넘어 "잘 일하게 만드는 단계"로 넘어간다.