🧩 내 스킬을 다시 열어보니, 내 고집이 적혀 있었다

저는 반복되는 일을 스킬로 만들어 씁니다.

스킬이라고 하면 거창하게 들리지만, 사실은 설명서 한 장에 가깝습니다. AI에게 "이런 일이 들어오면 이런 순서로, 이런 원칙을 지켜서 처리해"라고 미리 적어두는 마크다운 파일이죠. 보통 파일 이름을 SKILL.md로 붙여서 그렇게 부릅니다. 제가 늘 말로 하던 지시를 한 번만 적어두면, 다음부터는 AI가 그 파일을 읽고 그 방식대로 움직입니다.

할 일 관리용 스킬이 하나 있습니다. Akiflow에 할 일을 넣고 일정까지 잡아주는 건데, 여기에 제가 아예 규칙으로 적어둔 문장이 하나 있어요. 백로그를 만들지 말 것. 날짜 없는 할 일은 쌓이기만 하다가 결국 죄책감이 되니까, 무조건 가까운 날짜에 붙이라고 적어뒀습니다.

"지금 뭐 해야 돼?"라고 물으면 답해주는 비서 스킬도 있습니다. 캘린더와 노트, 슬랙, 할 일을 전부 가로질러 읽은 뒤에 딱 하나만 짚어줍니다. 우선순위 목록은 주지 말라고 적어뒀어요. 목록이 여러 개 나오면 저는 또 고르느라 시간을 쓰게 되거든요.

업무 자동화를 도와주는 코치 스킬도 만들었습니다. 첫 줄이 이렇습니다. 코치가 대신 골라주지 않는다. 무엇을 자동화할지는 본인이 고르게 하고, 코치는 질문만 던지게 해뒀습니다.

이걸 만들 때 거창한 생각이 있었던 건 아닙니다. 매번 똑같은 설명을 다시 하는 게 귀찮았거든요. 매일 아침 브리핑이나 하루 기록처럼 루틴에 붙어 있는 것들도 그렇게 하나둘 만들어졌습니다.

효과는 분명했습니다. 한 번 잘 만들어두면 그다음부터는 제가 아무 말 안 해도 같은 형식으로, 같은 길이로, 같은 순서로 나옵니다. 시간이 줄어드는 것도 좋았지만, 결과물이 매번 비슷한 수준으로 나오는 것이 더 좋았습니다.

생산성 분야에서는 이런 걸 이미 SOP(Standard Operating Procedure), 즉 표준 운영 절차라고 부릅니다. 잘하는 사람의 방식을 문서로 만들어두고, 다른 사람도 그 수준에서 시작하게 하는 거죠. 스킬은 그 SOP를 AI가 읽을 수 있는 형태로 옮겨둔 것뿐입니다.

여기까지는 그저 일을 좀 더 편하게 하려던 시도였습니다.

그런데 얼마 전 이 파일들을 다시 열어보다가 이상한 기분이 들었어요. 그 안에 적혀 있는 게 절차만은 아니더라고요.

백로그를 만들지 마라. 하나만 짚어줘라. 대신 골라주지 마라.

돌이켜보니 전부 제가 일할 때 붙들고 있는 고집이었습니다. 저는 업무 순서를 적어둔다고 생각했는데, 실제로 적어둔 건 제 믿음이었던 거예요. 그것도 제가 모르는 사이에 말이죠.

그러면 남의 스킬에는 뭐가 적혀 있을까. 갑자기 그게 궁금해졌습니다.

남의 스킬을 열어보니, 거기에도 사고의 흐름이 있었다

해외 개발자들도 자기 스킬을 하나둘 공개하기 시작했습니다. 궁금해서 하나씩 열어봤어요. 그 사람들이 어떤 순서로 일하는지 슬쩍 들여다보고 싶었거든요.

역시 절차만 있는 건 아니었습니다.

"이 단계에서는 개요를 짜지 마라." 왜 굳이 이 금지 문장을 넣었을까요? "이 규칙은 세션 내내 유효하고, 주제가 바뀌어도 사라지지 않는다." 왜 이걸 이렇게까지 못 박아뒀을까요? "이건 완성품이 아니니 고쳐 쓰세요." 왜 만든 사람이 스스로 이런 말을 남겼을까요?

금지 문장에는 반드시 이유가 붙어 있습니다. 무엇을 하라고 적는 건 누구나 할 수 있지만, 무엇을 하지 말라고 적으려면 그걸 한 번 해보고 결과가 좋지 않았던 경험이 있어야 하기 때문입니다. 하라는 말은 이상이고, 하지 말라는 말은 이력이에요. 그래서 금지 문장을 하나씩 따라가다 보면 그 사람이 어디서 걸려 넘어졌는지, 그 뒤로 무엇을 진실로 믿게 됐는지가 보입니다.

이게 제가 남의 스킬을 들여다보게 된 이유입니다. 업무 순서만 배우는 게 아니라 일하는 철학, 그러니까 이 사람이 무엇을 중요하게 여기고 무엇은 절대 하지 않으려 하는지를 읽게 되거든요.

도구를 고를 때도 마찬가지입니다. 남들이 많이 쓴다고 무작정 따라 쓰는 게 아니라, 그걸 만든 사람이 무엇을 믿는지 먼저 봐야 합니다. 내 철학과 맞닿아 있는 도구만 나를 한 단계 끌어올려줍니다. 안 맞으면 좋은 도구도 결국 짐이 될 뿐이죠.

오늘은 제가 들여다본 것 중에서 철학이 특히 선명했던 세 개의 스킬을 가져왔습니다.

첫 번째 — Anthropic: "신입에게 주는 온보딩 문서"

2026년 1월 30일, Anthropic은 Claude Cowork에 플러그인 기능을 붙이면서 자기들이 쓰던 11개를 통째로 오픈소스로 공개했습니다. 세일즈, 마케팅, 법무, 재무, 데이터 분석, 고객지원, 생산성까지 직무별로 하나씩이었어요.

깃허브 저장소에 적힌 문장은 이렇습니다.

직접 사내에서 쓰던 걸 바깥에 공유한 것입니다. AI를 가장 적극적으로 쓰는 회사가 자기들 내부에서 어떻게 일하는지 열어 보인 셈이죠.

여기 담긴 철학 세 가지

하나, 모델이 아니라 맥락이 유능함을 만든다.

Anthropic 쪽 표현이 정확합니다. 스킬은 에이전트가 "자기가 놓인 특정 맥락에서" 일을 잘하도록 가르치는 방법이라고 했어요. 더 똑똑한 AI를 기다리는 게 아니라, 지금 있는 AI에게 우리 맥락을 알려주자는 관점입니다. 앞의 인용문, 그러니까 신입에게 온보딩 문서를 만들어주는 것과 같다는 비유도 여기서 나왔고요.

둘, 지식 노동은 코드 없이도 파일로 표현할 수 있다.

플러그인은 전부 마크다운과 JSON으로 되어 있습니다. 별도의 코드가 없어요. 그래서 개발자가 아니어도 열어서 읽고, 고치고, 공유할 수 있습니다. 겉으로는 단순한 기술 선택처럼 보이지만 실제로는 다릅니다. 오히려 "업무 방식은 개발자만 다룰 수 있는 게 아니다"라는 선언에 가깝죠.

생산성 플러그인이 이 철학을 가장 잘 보여줍니다. 할 일 관리 앱을 하나 더 만든 게 아니에요. 대신 TASKS.md라는 마크다운 파일 하나를 Claude가 읽고 쓰게 합니다. 그러면서 내 사람들, 내 프로젝트, 내가 쓰는 용어를 학습해서 챗봇이 아니라 동료처럼 일하게 만드는 게 목표라고 적혀 있습니다.

셋, 완성품을 주지 않는다.

이 지점이 가장 흥미롭습니다. Anthropic 스스로 나머지 10개는 그대로 쓰지 말고, 출발점으로 삼아 자기 회사의 도구와 용어, 절차에 맞게 고쳐 쓰라고 권합니다.

실제로 그 11개를 자기 업무에 붙여 테스트해본 한 뉴스레터 운영자의 결론도 같았어요.

그러면서 이런 말도 덧붙였습니다. 단독 스킬과의 진짜 차이는 슬래시 명령(slash command)이라고요. 스킬은 Claude가 생각하는 방식을 바꾸고, 슬래시 명령은 하나의 완결된 작업을 통으로 실행합니다.

같은 리뷰어가 짚은 단점도 옮겨둘게요. 플러그인 세션은 사용량을 훨씬 빨리 씁니다. 복잡한 세션 하나가 일반 메시지 100개 이상에 맞먹을 수 있으니, 토큰을 아껴야 한다면 더더욱 내 상황에 맞게 손봐야 합니다.

두 번째 — Matt Pocock: 가르치는 사람의 철학이 글쓰기로 이어질 때

두 번째는 개인이 만든 스킬입니다.

Matt Pocock. TypeScript를 가르치는 교육자이고, Total TypeScript를 만들었고, 뉴스레터도 운영합니다. 이 사람이 어느 날 자기가 매일 쓰던 작업 폴더를 통째로 공개했어요.

깃허브에서는 좋아요에 해당하는 별이 21만 8천 개 붙었습니다. Anthropic 공식 스킬 리포에 붙은 별이 16만 9천 개니까, 회사 하나가 만든 것보다 개인 한 명의 작업 방식이 더 많이 퍼진 셈이에요.

소개 문구는 다음과 같습니다.

여기에 오늘 핵심으로 볼 글쓰기 스킬 세 개가 들어 있습니다.

이 글쓰기 스킬 세 개는 리포의 in-progress 폴더에 들어 있습니다. 대표 목록에 올려둔 것도 아니에요. 만든 사람이 아직 다듬는 중이라고 표시해둔 겁니다. 저는 이걸 보고 오히려 더 신뢰가 갔습니다. 뒤에서 볼 Anthropic의 태도와 정확히 맞닿아 있었기 때문입니다.

뿌리부터 봅시다

이 사람의 스킬 모음을 뜯어보면 곳곳에 출처가 적혀 있습니다. 소프트웨어 공학의 고전들이에요. John Ousterhout의 ‘깊은 모듈’, Martin Fowler의 ‘작은 커밋’, 『실용주의 프로그래머』의 ‘예광탄’ 개념. 저장소에는 『실용주의 프로그래머』의 문장이 직접 인용돼 있기도 합니다.

즉 이 사람의 스킬은 새로 발명한 방법론이 아니라, 이미 검증된 고전을 AI가 실행할 수 있는 형태로 옮겨놓은 것입니다. 이게 첫 번째 철학입니다.

두 번째 철학은 대비에서 더 선명하게 드러납니다. 그는 저장소 설명에서 다른 접근들도 언급합니다. 전체 프로세스를 통째로 소유하려는 방식들이 있지만, 자기는 그 길을 택하지 않았다고요. 대신 작고 조립 가능한 스킬을 여러 개 제공합니다. 한 리뷰어가 이 차이를 잘 정리했어요. 어떤 도구는 레일이 깔린 완성 시스템을 원하는 사람을 위한 것이고, Matt Pocock의 것은 자기 방식을 직접 조립하고 싶은 사람을 위한 것이라고요.

그리고 그가 강조하는 한마디가 있습니다. "vibe coding이 아니라 real engineering." 느낌대로 만드는 게 아니라 제대로 설계하라는 뜻이죠.

글쓰기 스킬에 담긴 철학

그는 이론의 출발점을 이렇게 설명합니다. 소설가들이 아이디어를 일기장에 적어두었다가 나중에 이야기에 녹여 쓰는 방식에서 가져왔다고요. 그리고 그 방법을 세 가지로 나눴습니다.

① writing-fragments — 캐는 단계

AI가 저를 인터뷰해서, 거기서 나온 것들을 마크다운 파일 하나에 계속 쌓습니다. 어딘가에 아직 들어가지 못한 날카로운 문장, 반쯤 된 생각, 짧은 장면, 불평, 펀치라인 같은 것들이요.

여기서는 개요를 짜는 게 명시적으로 금지입니다.

이 금지 문장 자체가 철학입니다. 발산과 수렴을 한자리에서 섞으면 둘 다 망가진다는 믿음이 깔려 있거든요. 실제로 그는 이 세 스킬을 ‘탐색(explore)’과 ‘활용(exploit)’으로 나눠 이름표를 붙여뒀습니다. writing-fragments만 탐색이고, 나머지 둘은 활용이에요. 재료를 모을 때는 구조를 생각하지 않고, 구조를 잡을 때는 재료를 더 캐지 않습니다.

이 단계에서 가장 귀하게 여기는 것도 하나 있어요. 글 전체를 압축해서 표현할 수 있는 단어 하나. 대화 속에서 어떤 아이디어가 계속 맴돌면 AI가 "거기에 이름을 붙이라"고 밀어붙입니다. 개념에 이름이 붙는 순간 글이 날카로워진다는 걸 아는 거죠.

② writing-shape — 논리를 세우는 단계(논증형 글)

먼저 서로 다른 논지를 품은 도입부 후보를 두세 개 뽑아 고르게 합니다. 그다음 한 블록씩 키워나가죠.

핵심 규율은 ‘그라운딩(grounding)’ 규칙입니다. 한 블록은 독자가 이미 알고 왔거나, 앞 블록에서 접한 개념에만 기대야 합니다. AI는 지금까지 설명된 개념 목록을 계속 들고 다니다가, 아직 설명되지 않은 개념이 나오면 멈춰서 먼저 설명 블록을 넣을지 묻습니다.

저는 이 규칙을 교육자의 습관으로 읽었습니다. 본인이 그렇게 직접 설명한 적은 없습니다. 다만 남에게 뭔가를 순서대로 설명해본 적이 있으면 압니다. 이해되지 않은 개념 위에 다음 개념을 쌓는 순간 듣는 사람은 거기서 떨어져 나간다는 걸요. 개발자를 가르치는 게 직업인 사람이 만든 글쓰기 규칙이 하필 이런 모양이라는 게, 저한테는 우연처럼 보이지 않았습니다. 한 리뷰어의 표현이 정확했어요. 독자를 잃는 것을 ‘이름 붙은 원인이 있는 구조적 버그’로 취급하는 드문 글쓰기 도구.

글쓰기를 취향이 아니라 검증 가능한 구조로 본다는 뜻입니다. 잘 쓴 글과 못 쓴 글의 차이가 아니라, 규칙을 지킨 글과 어긴 글의 차이로 본다는 거죠. 저는 이 대목에서 한참 멈춰 있었습니다.

③ writing-beats — 걷는 단계(서사형 글)

같은 재료로도 다른 길을 갑니다. 단계마다 다음 장면 후보를 두세 개씩 제시하고, 각각이 무엇을 설명하게 되고 무엇을 열어주는지 미리 보여줘요. 지도를 펴놓고 갈림길을 걷는 느낌입니다.

끝내는 방식에도 철학이 있습니다. 재료가 바닥나서 끝내는 게 아니라, 완결된 느낌이 드는 순간 멈춥니다. 남은 조각은 실패가 아니라, 원래 쓸 것보다 더 많이 모으는 게 목적이었다는 증거로 봅니다.

 세 번째 — @ayghri: 임상 매뉴얼을 챗봇 규칙으로 옮기다

세 번째는 스킬 파일 자체는 가장 짧지만, 가장 널리 퍼졌고 철학도 가장 노골적입니다. 이름부터 대놓고 i-have-adhd예요.

만든 사람에 대해 알려진 건 @ayghri라는 아이디뿐입니다. 실명도 회사도 없어요. 그런데 6KB짜리 마크다운 한 장으로 시작한 이 프로젝트가, 별을 2만 개 넘게 받았습니다.

출처가 이 스킬의 거의 전부입니다

리포 크레딧에는 이렇게 적혀 있습니다. 성인 ADHD(주의력결핍 과잉행동장애) 관리 매뉴얼인 『The Adult ADHD Tool Kit』을 바탕으로 하되, 사람이 하루를 조직하는 방법이 아니라 LLM(대형 언어 모델)이 어떻게 응답해야 하는지에 맞게 각색했다고요.

임상 행동치료 매뉴얼을 AI 출력 규칙으로 번역했다. 이 한 문장으로 이 프로젝트를 거의 설명할 수 있습니다.

이 각색을 떠받치는 전제 다섯 개가 파일 안에 적혀 있어요.

• 작업 기억은 작다. 화면에 없는 건 잊힌다. 그러니 "이걸 염두에 두세요"라고 요구하지 말 것.

• 답을 아는 것과 실제로 답하게 되는 건 다르다. "알겠다"와 "했다" 사이의 마찰에서 일이 멈춘다.

• 시작이 가장 어렵다. 첫 행동은 분명하고, 작고, 지금 할 수 있어야 한다.

• 시간 감각은 뭉개진다. "조금 걸려요"와 "몇 시간"이 거의 똑같이 들린다.

• 도파민은 귀하다. 진전이 눈에 보여야 하고, 눈에 안 보이는 성취는 없던 일이 된다.

여기서 나온 규칙이 열 개입니다. 다음 행동으로 시작할 것. 여러 단계가 필요하면 번호를 붙일 것. 턴마다 지금 어디쯤 왔는지 복창할 것. "조금 걸려요"가 아니라 분 단위로 말할 것. 목록은 다섯 개까지. 그리고 서두 금지, 요약 금지, 맺음말 금지.

그런데 철학의 핵심은 ‘간결함’이 아닙니다

이걸 그냥 "짧게 대답하게 만드는 스킬"로 오해하기 쉽지만, 파일에는 분명하게 이런 문장이 적혀 있습니다.

"출력은 단지 짧은 게 아니다. ADHD인 뇌가 행동할 수 있는 형태로 빚어진 것이다."

목표가 간결함이 아니라 행동 가능함이라는 뜻입니다. 짧아도 다음에 뭘 해야 할지 모르겠다면 실패한 출력이죠. 그래서 규칙 열 개 중 상당수는 길이가 아니라 순서와 상태에 관한 내용입니다. 진전이 눈에 보여야 행동이 이어진다는 전제가 깔려 있기 때문입니다. 그래서 지금 어디쯤 왔는지를 매번 다시 말하게 만드는 거예요.

리포에 실린 전후 비교를 보면 이 차이가 한눈에 들어옵니다.

전:

후:

짧아진 게 아닙니다. 오히려 줄 수는 더 늘었죠. 달라진 건 세 가지입니다. 순서에 번호가 붙었고, 각 줄이 지금 당장 할 수 있는 크기로 잘렸고, 맨 끝에 "다음에 무엇을 할지"가 남았습니다. 줄인 게 아니라 행동할 수 있는 형태로 다시 빚은 것입니다.

여기에는 한 가지 관점이 더 숨어 있습니다. AI의 친절함도 비용이 될 수 있다는 것. "좋은 질문이에요!"는 무해해 보이지만, 읽는 사람이 실제 답에 닿기까지 가야 할 거리를 늘립니다.

그리고 문 앞에 붙여둔 한 줄

리포 첫 줄에는 이렇게 적혀 있어요. "ADHD 진단은 필요 없습니다."

자기 문제를 풀려고 만들었는데, 만들고 보니 모두에게 필요해진 셈이죠. 실제로 이걸 소개한 한 글도 이렇게 요약하더라고요. ADHD를 위해 만든 스킬이지만 사실 대부분의 사람이 AI가 응답해줬으면 하는 방식 그 자체라고요.

만든 사람이 README 맨 끝에 남긴 문장도 좋았습니다.

참고로 한국어 README도 있습니다.

세 개를 나란히 놓고 보니 보이는 것

세 개를 다 들여다보고 나서 공통점 하나가 또렷하게 보였어요.

• Anthropic은 신입 온보딩 문서를 참고했습니다.

• Matt Pocock은 소설가의 일기장, 커리큘럼 설계, 소프트웨어 공학 고전을 참고했습니다.

• @ayghri는 임상 행동치료 매뉴얼을 참고했습니다.

셋 다 AI가 나오기 전부터 있던 지식입니다.

이게 꽤 놀라웠어요. AI 시대의 최신 도구를 열어봤는데, 그 안에 들어 있는 건 하나같이 사람이 사람에게 무언가를 전달하던 오래된 방법이었거든요.

그러니까 좋은 스킬은 AI를 더 똑똑하게 만드는 게 아니었습니다. 사람이 이미 알고 있던 잘 일하는 방법을, AI가 매번 빠짐없이 지키게 만드는 것이었어요. 없던 지식을 새로 넣는 게 아니라, 이미 있던 지식이 빠지지 않고 실행되게 만드는 겁니다.

생각해보면 당연합니다. 온보딩 문서도, 커리큘럼도, 임상 매뉴얼도 결국 같은 문제를 풀기 위해 만들어진 것이거든요. 잘하는 방법을 아는 사람은 이미 있는데, 그 앎이 매번 똑같이 전달되지는 않는다는 문제요. 사람에게 시키려면 가르치고, 반복시키고, 지켰는지 확인해야 합니다. AI에게는 파일 한 장이면 됩니다. 그러니 지난 몇 년 사이에 달라진 건 지식 자체가 아니라, 그 지식을 매번 지키게 만드는 비용입니다.

그래서 도구를 고르는 기준이 바뀝니다

화제가 된 "스킬 47개 설치" 목록을 모조리 깔아보고 하나씩 비교한 사람이 있습니다. 본인이 직접 세어본 결과라고 하는데, 47개 중 40개는 오히려 결과를 나쁘게 만들었다는 거예요. 비교 방법까지 전부 공개한 건 아니라서 숫자를 그대로 믿을 필요는 없습니다. 그래도 방향은 분명합니다.

처음엔 저도 이걸 스킬 품질 문제라고 생각했어요. 그런데 철학의 관점에서 보면 다르게 읽힙니다. 남의 SOP는 남의 믿음 위에 세워진 겁니다. 그 믿음이 내 일과 맞지 않으면, 잘 만들어진 스킬일수록 더 세게 방해합니다. 잘 만들어졌다는 건 그 사람의 믿음이 규칙 하나하나에 촘촘하게 들어가 있다는 뜻이니까요. 빠져나갈 틈이 없습니다. 발산과 수렴을 섞지 말라는 규칙은 긴 글에는 축복이지만, 짧은 메모에는 족쇄가 될 수 있거든요.

몸에 맞춰 지은 옷을 생각하면 쉽습니다. 남의 치수에 딱 맞게 잘 지어진 옷일수록 내가 입으면 더 불편해요. 대충 만든 옷은 어떻게든 걸칠 수 있지만, 잘 만든 옷은 어깨선이 정확해서 몸을 비틀 여지가 없습니다.

더 뼈아픈 지적도 있습니다. 이런 스킬들이 정말 효과가 있는지에 대한 반론인데, "의사결정 트리의 각 가지를 따라 내려가라"는 표현이 "비판적으로 검토해줘"보다 더 정교해 보일 수는 있어도, 통제된 조건에서 실제로 다른 결과를 내는지 비교해본 사례는 거의 없다는 겁니다. 이 문제를 정리한 사람이 남긴 문장이 오래 남았어요.

물론 예외는 있습니다. 방금 소개한 i-have-adhd에는 평가셋이 붙어 있어요. 열네 개 과제를 스킬을 켠 상태로 한 번, 끈 상태로 한 번 돌리고, 채점할 때는 어느 쪽인지 모르게 가립니다. 자기 스킬이 대조군에 새어 들어가면 "스킬을 스킬과 비교하는 꼴"이 된다는 경고까지 적어놨더군요. 다만 이런 경우는 드뭅니다. 대부분은 "정교하게 들린다"는 단계에서 멈춰 있어요.

도구도 똑같습니다. 옵시디언(Obsidian)이 왜 그렇게까지 마크다운 파일을 고집하는지 아세요? 만든 사람이 ‘앱보다 파일이 먼저’라는 철학을 갖고 있기 때문입니다. 이 믿음이 내 것과 맞는 사람에게 옵시디언은 인생 도구가 되고, 안 맞는 사람에게는 그저 불편한 메모장이 됩니다. 도구가 좋고 나쁜 게 아니라 철학이 맞느냐 아니냐의 문제죠.

물리학자 하이젠베르크는 1958년에 이런 말을 남겼습니다. 모든 도구에는 만든 사람의 정신이 담긴다고요. 지금 같은 소프트웨어 도구가 없던 시절에 나온 문장인데도, 요즘 저는 스킬 파일을 열어볼 때마다 그 말이 떠오릅니다.

제가 제 스킬을 계속 고쳐 쓰는 이유도 여기에 있습니다. 남의 것을 가져와도 결국 제 믿음에 맞게 다시 손보게 되거든요. Anthropic이 자기 플러그인을 두고 "고쳐 쓰라"고 한 것도 같은 이야기고요.

이번 주에 써볼 스킬을 하나만 고르고, 설치하기 전에 그 SKILL.md 파일을 처음부터 끝까지 읽어보세요. 5분이면 됩니다. 무엇을 하라고 적혀 있는지가 아니라, 무엇을 하지 말라고 적혀 있는지를 보면 그 사람의 철학이 보일 거예요.

저는 요즘 이런 생각을 자주 합니다.

내가 매일 쓰는 도구들은, 나와 같은 것을 믿는 사람이 만든 걸까?

🍊 당신의 생산성 근력을 높이는, 당근메일

매주 월요일 아침에 다시 만나요!

• 🔧 스킬은 SOP다. 반복되는 일을 한 번 잘 적어두면, 매번 설명하지 않아도 같은 품질이 나온다.

• 📖 그런데 잘 만들어진 스킬에는 절차만 있는 게 아니라 만든 사람의 믿음도 들어 있다. 온보딩 문서, 커리큘럼 설계, 임상 매뉴얼 — 셋 다 AI 이전부터 있던 지식이었다.

• 🧭 그래서 도구를 고르는 기준은 인기가 아니라 철학의 일치다. 안 맞는 SOP는 잘 만들어졌을수록 더 세게 방해한다.

당근메일 제휴 및 광고 문의

문제를 해결하고 즐거움을 얻어가는 곳