CHAPTER 2

반복은 지겹다 — 자동화의 본능

돌도끼에서 AI 스킬까지, 인간의 위대한 귀찮음

일러스트 2-1: 도구 진화 타임라인

민수의 월요일 아침

민수 씨는 스타트업에서 일하는 3년 차 마케터예요. 능력 있고, 성실하고, 회사에서 인정받는 사람이죠. 근데 민수 씨에게는 비밀이 하나 있어요.

매일 아침 45분을 "쓸데없는 일"에 쓰고 있다는 것.

출근하면 이런 루틴을 반복합니다:

  1. 어제 광고 성과 데이터를 스프레드시트에서 복사 (5분)
  2. 팀 슬랙 채널에 일간 리포트 양식 붙여넣기 (3분)
  3. 숫자 바꾸고 문장 살짝 수정 (7분)
  4. 경쟁사 블로그 3개 확인하고 요약 정리 (15분)
  5. 오늘 할 일 목록 정리해서 팀장님께 공유 (10분)
  6. 자동 발송 이메일 3개 내용 확인 및 수정 (5분)

합계: 45분. 매일. 월요일부터 금요일까지.

한 달이면 15시간. 1년이면 180시간. 거의 23일 치 근무 시간을 "복붙 + 숫자 바꾸기"에 쓰고 있는 거예요.

민수 씨는 어느 날 아침, 스프레드시트를 열며 이렇게 중얼거렸어요.

"아... 진짜 이거 자동으로 안 되나? 로봇이 대신 해줬으면 좋겠다."

민수 씨는 자기가 원하는 게 정확히 뭔지 알고 있었어요. 그냥 실행하는 방법을 몰랐을 뿐이죠.

이번 챕터에서는 민수 씨 같은 사람들의 이야기, 그리고 인간이 태초부터 가지고 있던 "자동화 본능"에 대해 이야기할 거예요.

인간의 위대한 귀찮음

진지하게 물어볼게요. 인류 역사상 가장 위대한 발명의 원동력이 뭐였을까요?

호기심? 도전 정신? 생존 본능?

다 맞지만, 저는 하나 더 추가하고 싶어요.

귀찮음.

귀찮음이 만든 발명품들

바퀴: "이 무거운 거 들고 다니기 귀찮아" → 굴리자!
인쇄술: "책을 손으로 베끼기 귀찮아" → 찍자!
세탁기: "손빨래 귀찮아" → 기계가 돌리자!
엑셀: "계산기로 하나하나 더하기 귀찮아" → 자동 계산!
AI 스킬: "매번 같은 프롬프트 치기 귀찮아" → 한 번 만들어서 재사용하자!

보이시나요? 도구의 역사는 곧 "반복을 줄이는 역사"예요.

원시인이 돌도끼를 만든 건 맨손으로 나무를 자르기 귀찮아서였어요. 매번 손이 아프고, 시간이 오래 걸리고, 비효율적이니까. "한 번 만들어두면 계속 쓸 수 있는 도구"를 만든 거죠.

그 본능이 수천 년을 지나 지금까지 이어지고 있는 거예요.

디지털 시대의 도구들

컴퓨터가 나온 뒤로, 자동화의 속도는 미친 듯이 빨라졌어요.

  • 단축키 — Ctrl+C, Ctrl+V. 마우스로 메뉴 찾아 클릭하기 귀찮아서 만든 거예요.
  • 매크로 — 같은 동작을 녹화해서 반복 실행. 엑셀 매크로 써본 분은 아실 거예요. "와, 내가 30분 걸리는 일을 3초에?" 하는 그 쾌감.
  • 스크립트 — 프로그래머들이 쓰는 자동화 도구. "이 명령어를 이 순서로 실행해" 하면 컴퓨터가 척척.
  • 앱 자동화 — IFTTT, Zapier 같은 서비스. "이메일 오면 자동으로 슬랙에 알려줘" 같은 것.

근데 이 도구들에는 한계가 있었어요. 정해진 패턴만 자동화할 수 있었다는 거예요.

"A가 오면 B를 해" — 이건 잘함.
"상황 봐서 적절하게 판단해" — 이건 못함.

엑셀 매크로는 "A1 셀의 숫자를 B1에 복사"는 할 수 있지만, "이 데이터를 분석해서 인사이트를 뽑아줘"는 못하잖아요.

그런데 생성형 AI가 등장하면서, 드디어 그 벽이 무너졌어요.

일러스트 2-2: 자동화 도구 계단

왜 스킬을 만들게 됐는가 — 진짜 이야기

이 책을 쓰게 된 배경에는 실제 이야기가 있어요.

어떤 개발자가 있었어요. 매일 같은 업무를 반복하고 있었죠. 코드 리뷰하고, 배포하고, 테스트하고, 문서 정리하고. 하나하나는 어렵지 않은데, 매번 같은 순서로 같은 판단을 반복하는 게 너무 지겨웠어요.

"코드 리뷰할 때 확인하는 체크리스트가 있는데, 이걸 매번 머릿속으로 돌리는 게 피곤해."

"배포 전에 확인할 것들이 12개인데, 가끔 하나씩 빠뜨려서 사고가 나."

"새로운 팀원이 오면 같은 설명을 또 해야 해. 매번 같은 말을."

그러다 Claude Code를 쓰게 됐어요. 처음엔 그냥 채팅하듯 AI에게 일을 시켰죠. "이 코드 리뷰해줘", "배포 전 체크리스트 확인해줘" 하면서요.

근데 문제가 있었어요.

매번 같은 프롬프트를 치는 것도 귀찮더라

"코드 리뷰해줘. 보안 이슈 확인하고, 성능 문제 체크하고, 테스트 커버리지 보고, 코드 스타일도 확인해줘. 그리고 결과는 마크다운으로..." 이걸 매번 치고 있었던 거예요. 귀찮음을 없애려고 AI를 쓰는데, AI에게 시키는 것도 귀찮아진 거죠!

그래서 생각했어요.

"이 프롬프트를 한 번 잘 만들어서 저장해두면, 다음부터는 한 마디로 실행할 수 있지 않을까?"

바로 그 순간이 "스킬"의 시작이었어요.

스킬이란 뭔가?

드디어 이 책의 핵심 개념이 등장합니다.

스킬(Skill)은 간단히 말하면 이거예요:

스킬 = AI에게 주는 레시피 카드

여러분이 AI에게 특정 작업을 시키기 위한 상세한 지시서예요.
한 번 잘 만들어두면, AI가 그 레시피대로 매번 정확하게 실행합니다.

요리 비유가 딱 맞아요. 자세히 비교해볼게요.

요리사와 레시피

여러분 집에 요리를 엄청 잘하는 셰프가 왔다고 상상해보세요. 이 셰프는 어떤 요리든 만들 수 있어요. 한식, 양식, 일식, 중식 — 뭐든요. 근데 한 가지 특징이 있어요. 직접 메뉴를 정하지 않는다는 거예요.

여러분이 "김치찌개 해줘"라고 하면 김치찌개를 만들고, "파스타 해줘"라고 하면 파스타를 만들어요.

자, 이 상황에서 두 가지 방법이 있어요:

방법 1: 매번 상세하게 설명하기

"김치찌개 해줘. 김치는 2주 숙성된 거 쓰고, 돼지고기는 목살로, 두부는 부침용 말고 찌개용으로, 물은 쌀뜨물 사용하고, 고춧가루 한 스푼 추가하고, 끓이는 시간은 20분이고, 마지막에 대파 송송 썰어서 올려줘."

매번 이걸 말해야 해요. 매일 김치찌개를 먹고 싶으면, 매일 이 긴 설명을 반복해야 하죠.

방법 2: 레시피 카드를 만들어두기

"냉장고에 '우리집 김치찌개' 레시피 붙여놨으니까, 그거 보고 해줘."

끝. 한 마디면 돼요. 레시피에 모든 게 적혀 있으니까.

AI 스킬이 바로 이 "레시피 카드"예요.

  • AI = 만능 셰프
  • 프롬프트 = 주문
  • 스킬 = 레시피 카드
  • 스킬 실행 = "이 레시피대로 해줘"

구체적으로 어떤 모습일까?

실제 예를 하나 볼게요. 아까 개발자 이야기에서 나온 "코드 리뷰" 스킬을 상상해봅시다.

스킬 없이 매번 하는 방법:

"이 코드를 리뷰해줘. 보안 취약점이 있는지 확인하고, 성능 문제가 있으면 알려주고, 에러 처리가 빠진 곳을 찾아주고, 코드 스타일이 일관적인지 확인하고, 테스트가 충분한지 평가해줘. 결과는 심각도 순으로 정리하고, 각 항목에 수정 제안을 포함해줘."

스킬을 만든 후:

"/review"

이 한 단어가 위의 긴 프롬프트 전체를 대신해요. 스킬 안에 모든 지시사항이 들어 있으니까요.

이해되시나요? 긴 설명을 한 번 잘 써두고, 짧은 명령어로 실행하는 것. 이게 스킬의 핵심이에요.

다시 민수 씨 이야기

아까 매일 45분을 루틴 업무에 쓰던 민수 씨, 기억하시죠?

만약 민수 씨가 스킬을 만들 수 있다면 어떨까요?

  • /daily-report 스킬: 광고 데이터를 분석하고, 전날과 비교하고, 팀 슬랙에 올릴 리포트를 자동 생성
  • /competitor-scan 스킬: 경쟁사 블로그를 확인하고, 주요 내용을 요약
  • /today-plan 스킬: 캘린더와 이전 업무를 바탕으로 오늘 할 일 목록 생성

45분이 5분으로 줄어듭니다.

그리고 남은 40분? 민수 씨가 진짜 잘하는 일 — 창의적인 마케팅 전략을 짜는 데 쓸 수 있어요.

핵심 인사이트

스킬은 반복적인 일을 자동화해서, 여러분이 진짜 중요한 일에 집중할 수 있게 해줘요. AI가 사람을 대체하는 게 아니라, 사람이 더 사람다운 일을 할 수 있게 도와주는 거예요.

일러스트 2-3: Before/After

더 큰 그림: 도구를 만드는 사람이 되라

여기서 한 가지 중요한 구분이 있어요.

세상에는 두 종류의 사람이 있어요:

  1. 도구를 쓰는 사람 — 다른 사람이 만든 도구를 잘 활용하는 사람
  2. 도구를 만드는 사람 — 자기에게 필요한 도구를 직접 만드는 사람

둘 다 훌륭해요. 하지만 도구를 만들 줄 아는 사람은 한 차원 다른 자유를 가집니다.

"이런 기능 있으면 좋겠다" → 기다리지 않고 직접 만든다.
"이 작업 자동화하고 싶다" → 누군가에게 부탁하지 않고 직접 만든다.
"우리 팀 업무 효율을 높이고 싶다" → 스킬을 만들어서 팀에 공유한다.

예전에는 "도구를 만드는 사람 = 프로그래머"였어요. 코드를 짤 줄 알아야 했으니까.

근데 AI 스킬은 달라요. 한국어로 글을 쓸 줄 알면 만들 수 있어요.

왜냐하면 스킬의 핵심은 코드가 아니라 "AI에게 주는 지시문"이거든요. 좋은 프롬프트를 잘 구조화해서 정리한 것 — 그게 스킬이에요.

이것만 기억하세요

글을 쓸 줄 알면, 스킬을 만들 수 있어요.
프로그래밍 실력이 아니라, "내가 뭘 원하는지 명확하게 표현하는 능력"이 핵심이에요.

사실 이 능력은 직장에서든, 일상에서든, 가장 중요한 능력 중 하나이기도 하죠.

"그냥 AI한테 매번 물어보면 되지 않나요?"

좋은 질문이에요. 맞아요, 매번 AI에게 상세하게 물어봐도 결과는 나와요. 근데 스킬을 만드는 게 훨씬 나은 이유가 있어요.

1. 일관성

사람은 매번 다르게 말해요. 오늘은 "자세하게 리뷰해줘"라고 하고, 내일은 "빠르게 확인해줘"라고 하죠. 그러면 결과도 매번 달라요. 스킬은 항상 같은 기준으로 실행되니까 결과가 일관적이에요.

2. 시간 절약

긴 프롬프트를 매번 치는 것도 시간이에요. 스킬 이름 한 단어 vs 200자 프롬프트 — 뭐가 더 빠른지는 명확하죠.

3. 공유 가능

이게 가장 중요해요. 여러분이 만든 좋은 프롬프트를 다른 사람에게 공유하려면? "이거 복붙해서 써"라고 할 수도 있지만, 스킬로 만들면 누구나 한 단어로 실행할 수 있어요.

4. 개선 가능

"아, 이 부분이 좀 부족한데?" 하면 스킬을 수정하면 돼요. 한 번 고치면, 그 다음부터는 개선된 버전으로 실행되니까요.

결국 스킬은 "좋은 프롬프트를 체계화하고 재사용 가능하게 만든 것"이에요.

실제로 만들어진 스킬들

이론만 말하면 재미없으니까, 실제로 만들어진 스킬 이야기를 해볼게요.

conductor라는 스킬이 있어요. 이름 그대로 "지휘자"예요. 새로운 프로젝트를 시작할 때, 마치 오케스트라 지휘자처럼 전체 과정을 이끌어주는 스킬이에요.

목표를 정리하고, 팀을 구성하고, 계획을 세우고, 실행하고, 리뷰하는 전 과정을. "프로젝트 시작하자" 한 마디면 conductor가 하나하나 물어보면서 이끌어줘요.

이 스킬이 탄생한 이유? "새 프로젝트 시작할 때마다 같은 과정을 반복하기 귀찮아서."

gstack이라는 스킬도 있어요. 이건 AI가 웹 브라우저를 사용할 수 있게 해주는 스킬이에요. 웹사이트를 열고, 버튼을 클릭하고, 스크린샷을 찍고, 상태를 확인하는 — QA(품질 검사) 작업을 자동화해줘요.

탄생 이유? "배포할 때마다 브라우저 열어서 하나하나 클릭해보기 귀찮아서."

보이시나요? 패턴이.

모든 스킬의 탄생 공식

"이거 매번 하기 귀찮다" + "AI가 대신할 수 있을 것 같다" = 스킬 탄생

여러분도 이미 일상에서 "이거 자동화되면 좋겠다" 싶은 게 있을 거예요. 그게 바로 여러분의 첫 번째 스킬이 될 수 있어요.

다음 챕터에서는...

"내가 만든 유용한 도구를 왜 남에게 공짜로 줘야 하지?"
오픈소스라는 아름다운 문화에 대해 이야기합니다.
리눅스에서 위키피디아까지, 그리고 AI 스킬까지 — 공유의 힘이 어떻게 세상을 바꾸는지 알아봐요.