Imported from jongwony/cc-plugin (choi-voice/skills/linkedin-polish/SKILL.md). Install upstream with npx skills add jongwony/cc-plugin --skill linkedin-polish. Copyright stays with the author.

LinkedIn 윤문 스킬 — 최종원의 목소리

이 스킬은 LinkedIn 게시글 46편(2024~2026)에서 추출한 문체 프로필이다. 기준 톤은 최근 1년의 글에 맞춘다. 초안의 내용·주장·숫자·링크·고유명사는 그대로 두고 표현만 다듬는다. 새 사실이나 사례를 지어 넣지 않는다.

윤문은 더하는 일이 아니라 덜어내는 일이다. 손이 가장 자주 미끄러지는 쪽은 문장을 다듬는 대신 근거를 보태는 것이고, 보탠 근거는 독자에게 배경지식 요구로 돌아온다. ## 덜어내기를 체크리스트보다 먼저 적용한다.

작업 순서

1. 초안을 끝까지 읽고, 글이 말하려는 한 문장(핵심 통찰)을 먼저 적어 둔다. 윤문 후에도 그 문장이 살아 있어야 한다.
2. ## 덜어내기로 먼저 재본다. 윤문본이 초안보다 길어질 조짐이면 거기서 멈추고 무엇을 보탰는지 찾는다.
3. 아래 체크리스트로 진단한다. 어긋난 항목만 고치고, 이미 톤에 맞는 문장은 손대지 않는다.
4. 체크리스트로 판정이 서지 않는 문장은 references/exemplars.md에서 비슷한 상황의 원문을 찾아 결을 맞춘다. 규칙이 못 잡는 자리는 원문 대조로 잡는다.
5. 윤문본을 통째로 제시한다. 그 아래에 "바꾼 이유"를 3~6줄로 짧게 붙인다(어떤 항목 때문에 어디를 고쳤는지). 대안이 갈리는 곳은 두 가지 표현을 나란히 보여주고 고르게 한다. 출력 형식은 references/before-after.md를 따른다.
6. 확신이 없는 고유명사·수치·인용은 고치지 말고 [확인]으로 표시한다.

덜어내기

덜어내는 기준은 글이 독자에게 요구하는 배경지식의 양이다. 읽는 사람 대부분은 이 도메인에 관심이 없고, 이해하는 데 사전 지식이 필요해지는 지점에서 이탈한다. 근거가 정확한지와는 무관하다 — 맞는 근거도 진입장벽이면 뺀다.

두 가지를 묻는다.

• 독자가 따라가 확인할 수 있나. 공개된 것은 링크 한 번이면 닿으므로 남길 수 있다. 비공개 저장소에만 있는 것의 내부 사정 — 프로세스 구성, 설정 파일명, 로컬 데이터 경로 — 은 확인할 길이 없으므로 뺀다.
• 설명 없이 그대로 읽히나. 읽는 데 별도 지식이 필요한 제약이나 용어는, 사실이어도 뺀다. "메신저 봇은 토큰당 한 프로세스만 수신을 붙잡을 수 있어"는 맞는 말이지만 그 API를 모르면 멈추는 자리다.

그래서:

• 결론이 한 문장으로 서면, 그것을 떠받치던 사례·제약·정황 나열은 덜어낸다. 조사해서 확인한 내용은 글쓴이가 그 결론을 믿게 된 근거이지 독자가 읽을 내용이 아니다.
• 숫자도 같은 기준으로 갈린다. 그대로 읽히거나 확인되는 숫자는 남고("플러그인 열일곱 개" — 링크가 걸린 공개 레포, "472 세션에서 1,631번" — 규모가 자명하다), 배경을 알아야 뜻이 서는 숫자는 잘린다(비공개 저장소에만 있는 구성의 개수).
• 윤문본이 초안보다 길어졌다면 그 자체가 신호다.

글의 뼈대

대부분의 글이 이 순서를 따른다. 초안이 뒤섞여 있으면 이 순서로 재배열을 제안한다. 다섯 단계가 다섯 문단을 뜻하지는 않는다 — 3번은 5번에 흡수되기도 한다.

1. 한 줄 장면 또는 한 줄 결론으로 시작. 인사·서론 없이 바로 들어간다.
   • "오래 다듬던 스킬을 결국 제거했습니다."
   • "Recall보다 Recognition."
   • "비행기에서 와이파이를 결제하고 Claude 세션을 열었습니다."
   • "장마철, 와이프와 함께 카페에 갔습니다."
   • "맥미니를 쓸 일이 거의 없어졌습니다."
   • "요새 게임을 하는 것 같아요."
2. 내가 직접 겪은 경험과 거기서 드러난 문제. 1인칭 "저는", 구체적 상황(며칠, 몇 번, 어떤 명령어).
3. 문제를 다시 규정하는 전환 문장. "문제는 도구가 아니라 전제에 있었습니다." / "문제는 AI가 못해서가 아닙니다. 대화가 부족한 겁니다." / "정작 '어떻게 꺼내느냐'가 새 병목이 되었습니다."
4. 그래서 만든 것 / 바꾼 방식. 절차와 숫자로 보여준다.
5. 한 줄 통찰로 닫고, 초대로 끝낸다. "~해 보세요." 뒤에 → /스킬명 · 링크 또는 GitHub: 링크.

문장 체크리스트

어미와 격식

• 기본은 격식체(합니다/습니다). 곁가지 감상이나 뒷이야기만 해요체로 풀어 리듬을 바꾼다: "~거든요", "~더군요", "~더라고요", "~같아요". 한 문단에 한 번 정도.
• 주장 문단의 마지막 문장을 해요체로 닫아 단정을 눅이는 쓰임이 따로 있다: "~있다는 점이죠". 문단 전체를 격식체로 쓰고 끝만 푼다.
• 짧은 메모형 글(5문장 이하)은 반말 서술("~같다", "~더라...")도 허용. 긴 글에서는 격식체 유지, 반말 섞지 않음.
• 느낌표는 글 전체에 0~1개. 그 한 개는 대개 아래 괄호 방백에 놓인다. 행사 후기·감사 인사에서만 늘어난다.
• 수사 의문은 드물게, 축을 가를 때만 쓴다: "사고에 몰입하는 도구라면 Claude가 이미 잘하는 것과 뭐가 달라야 할까요?" 후킹용으로 남발하지 않는다.

괄호 방백

• 직전에 한 주장을 바로 뒤 괄호에서 스스로 누그러뜨리는 짧은 한 줄을 쓴다: "(하지만 대부분의 경우에 Claude가 자체 제공하는 artifact-* 스킬이 많은 문제를 해결합니다!)"
• 방백은 한 문장, 한 글에 한 번. 본문 흐름을 끊지 않고 옆에서 덧대는 자리다.

단정의 강도

• 수사를 위해 사실을 절대화하지 않는다. 실제로 이유가 하나였던 게 아니라면 "이유는 하나였습니다"가 아니라 "가장 큰 이유는"이다. 대조를 세우려다 없는 단정을 만드는 일이 잦다.
• 검증 부담이 큰 현재형 사실 주장은 시점을 물려 쓴다: "지금 ~라는데" → "사실상 과거 ~라는데".

시그니처 구문

• "X가 아니라 Y" 대조로 핵심을 세운다. "의존이 아니라 정비", "검색이 아니라 재인식", "프로토콜이 아니라 포인터를 넘기는 규약", "결과물의 완성도가 아니라 결정 과정의 완성도", "일을 시키는 것과 함께 생각하는 것은 다릅니다".
• 대조는 세우되 어투는 눅인다. "~게 아니라"보다 "~건 아니고"가 이 사람의 말에 가깝다.
• 두 물음을 나란히 두어 축을 가른다. "제대로 하고 있는가?" / "올바른 일을 하고 있는가?"
• 짧은 대칭 문장 쌍으로 개념을 세운다. "빠른 층은 배우고(learn), 느린 층은 기억한다(remember)" / "빠른 층은 제안하고(propose), 느린 층은 거부/수용한다(dispose)".
• 문장 끝 패턴: "~인 셈입니다", "~는 뜻이 됩니다", "~라고 봅니다", "~한 자리에서", "~일 뿐입니다", "~가 전부였습니다".

인칭

• 경험 문단은 1인칭을 유지한다. 리듬을 위해 "저는"을 생략하면 겪은 일이 관찰기처럼 읽힌다.
• 따라 할 수 있는 절차는 일반형으로 쓴다. "상호 설치했습니다"(내 기록)보다 "상호 설치하면 강력한 환경을 만들 수 있습니다"(독자의 레시피). 경험은 1인칭, 방법은 일반형.

개념어 처리

• 원어 병기는 실제 기술·학술 용어에만 쓴다: "의사(pseudo)코드", "사상(morphism)", "절제(ablation)", "기질(substrate)", "현저성(Salience)", "멱등성(Idempotent)", "잠재된 수요(latent demand)", "부팅 스크립트(setup script)". 한 번 소개하고 이후 한국어로 쓴다.
• 일상어를 병기로 개념처럼 꾸미지 않는다. "상주(residency)"는 과하고 "상주"면 된다. 병기할지 망설여지면 빼는 쪽.
• 도구·기능명은 원어 그대로: Plan mode, Output Style, AskUserQuestion, /compact, CLAUDE_CODE_TASK_LIST_ID. 슬래시 명령은 /이름 형태.
• 세션, 컨텍스트, 하네스, 스킬, 플러그인, 서브에이전트, 토큰은 한글 음차로 쓴다.
• 영어 단어를 병기 없이 문장 안에 그대로 두는 경우도 있다(Portable, steering, Gate, latent pattern). 한 글에 두세 개 이내.

비유와 근거

• 인문·수학·게임에서 빌린 비유를 설명 도구로 쓴다: 해석학적 순환, 지평 융합, Pace Layering, Nun Study, Unix 철학, P=NP, High Output Management의 limiting step, 스타크래프트 빌드/메타/패치노트, 신발끈과 하네스, 북극성, 사막에서 바늘 찾기, 인턴 로봇. 초안에 비유가 없으면 억지로 넣지 말고, 이미 있는 비유는 한 문장으로 짧게 유지한다.
• 숫자를 증거로 둔다. "472 세션에서 1,631번", "34%", "50번 가까이, 3일", "80% 이상", "PR 95개". 초안의 수치는 절대 바꾸지 않는다. 어떤 숫자가 남고 어떤 숫자가 잘리는지는 ## 덜어내기를 따른다.
• 유명인 인용은 이름 + 한 줄 요지로 짧게 둔다: "Boris가 에이전트를 능숙하게 다루는 유저들은 100-1000개를 오케스트레이션 한다는 통계를 본 것 같습니다."
• 솔직한 인정을 지우지 않는다: "솔직히", "저도 그랬습니다", "처음에는 ~인가? 했는데", "이쯤 되니 P=NP 문제인가 싶더군요". 실패담이 있으면 그것이 글의 힘이다.

단어 선택

• 문학적 동사를 아껴 쓴다: 톺아보다, 걷어내다, 새기다, 벼리다, 쪼그라들다, 절개를 넣다, 맞물리다. 한 글에 두세 개.
• 초안의 신체적·구체적 표현은 밋밋한 말로 깎지 않는다. "노트북을 몸에 붙이고 다녔습니다"를 "들고 다녔습니다"로 바꾸면 장면이 사라진다.
• "요새"와 "요즘" 둘 다 쓴다. "꽤나", "부쩍", "모처럼", "정작", "결국" 같은 부사가 자연스럽다.
• 배우자는 "와이프".
• 감사 표기: "Thanks to 이름 - ~해 주셔서 감사합니다!" 또는 "~님께 감사드립니다." 공동 작업자는 본문 안에서 이름으로 부른다.

문단과 레이아웃

• 문단은 2~4문장, 한 문단 한 생각, 빈 줄로 구분.
• 목록이 필요하면 불릿 대신 → 화살표. 긴 글의 절 구분은 ---.
• 짧은 선언형 글은 한 절 한 줄로 끊어 시처럼 배치해도 좋다("AI가 계획을 제안합니다. / 괜찮아 보여서 바로 승인합니다. / 그리고 나중에 후회합니다.").
• 제목형 첫 줄은 예외적이다(46편 중 1편). 첫 줄은 제목이 아니라 장면이나 결론이다.
• 이모지는 첫 줄 끝에 하나까지(🪶 🎉). 본문에는 쓰지 않는다.
• 길이는 300~1,400자. 2,000자를 넘기면 절을 나누거나 Medium 링크로 미룰지 물어본다.
• 링크는 본문 끝에 모은다. → Medium 글: 링크, GitHub: 링크, 설치 명령은 코드 그대로 한 줄.
• 마무리는 한 갈래로 내려간다. 통찰 → 초대 → 링크. 곁가지 비교나 단서는 그 앞에 붙여, 끝이 여러 번 나뉘지 않게 한다.

하지 않는 것

• 해시태그, 후킹용 질문 남발, "여러분" 호명, 인사말로 시작하는 서론
• 마케팅 형용사(혁신적·획기적·놀라운), 과장, 자기 홍보 문장 추가
• 불릿 위주 구성, 소제목, 굵은 글씨
• 독자에게 기초를 길게 설명하는 것. 밀도 높게 쓰고 독자를 신뢰한다.
• 초안에 없는 사례·수치·인용을 지어 넣는 것
• 조사해서 확인한 근거를 글에 보태는 것. 확인은 글쓴이를 위한 것이고, 독자에게는 배경지식 요구로 돌아온다.

과거형 특징 — 기준 톤에서 제외

2024~2025 초의 글에는 아래 결이 있었고, 지금 톤에서는 빠졌다. 초안이 이 결로 쓰여 있으면 최근 톤으로 옮기는 것이 윤문의 방향이다. 체크리스트가 무엇을 고칠지를 정한다면, 이 절은 어느 쪽으로 고칠지를 정한다.

• 행사·강의 안내체: "~진행합니다!", "많은 관심 부탁드려요!", 느낌표와 🙌 🎉가 잦음
• 설명문체가 길게 이어짐: "~를 통해 ~하여 ~를 향상시킵니다"
• "여러분", "안녕하세요"로 시작
• 최근 글로 오면서 느낌표가 사라지고, 문장이 짧아지고, 경험 → 재규정 → 도구의 구조가 굳어졌다.

윤문 예시

예시 1 — 서론 걷어내기

초안:

요즘 AI가 너무 좋아져서 정말 놀라운 시대입니다! 그런데 제가 느낀 건, AI 성능보다 중요한 것이 있다는 것입니다. 바로 제가 무엇을 모르는지 아는 것입니다. 여러분도 한번 생각해 보세요!

윤문:

이번 모델을 쓰다 보면 제가 생각도 못 한 걸 AI가 먼저 꺼내놓을 때가 있습니다. 좀 역설적인데, AI가 좋아질수록 정작 중요한 건 AI 성능이 아니라 내가 뭘 모르는지 얼마나 알아차리느냐입니다. 있는 줄도 몰랐던 빈틈, unknown unknown이라고 하죠. 그게 진짜 병목입니다.

바꾼 이유: 감탄형 서론 삭제 → 경험 장면으로 시작 / "~보다 중요한 것"을 "X가 아니라 Y" 대조로 / 개념어는 원어 병기 / "여러분" 호명과 느낌표 제거 / 한 줄 통찰("그게 진짜 병목입니다")로 닫음.

예시 2 — 근거 덜어내기

윤문 1차(조사한 근거를 보탠 상태):

이쯤 되니 집에 둔 맥미니를 정리해도 되겠다 싶었습니다. 그런데 막상 정리하려니 옮길 수 없는 것들이 남았습니다. 메신저 봇은 토큰당 한 프로세스만 수신을 붙잡을 수 있어 애초에 두 곳에 둘 수가 없고, 일부 데이터는 로컬을 떠날 이유가 없습니다.

무엇보다 클라우드 컨테이너는 쓰지 않으면 회수됩니다. 맥미니에서 상주 중인 백그라운드 잡들은 전부 "계속 켜져 있어야 한다"가 존재 이유였습니다.

맥미니가 필요 없어진 게 아니라, 맥미니가 할 일이 좁혀진 셈입니다.

저자 교정:

맥미니가 필요 없어진 건 아니고, 맥미니가 할 일이 좁혀진 셈입니다.

두 문단이 통째로 빠졌다. 내용이 틀려서가 아니라 — 전부 확인된 사실이다 — 비공개 저장소의 내부 사정이라 독자가 따라갈 수 없고, 메신저 API 제약은 모르면 멈추는 자리이기 때문이다. 남은 한 문장이 원래 하려던 말이고, "~게 아니라"는 "~건 아니고"로 눅었다.

참고 파일

• references/exemplars.md — 기준 톤의 원문 8편 전문. 체크리스트로 판정이 서지 않을 때 비슷한 상황의 글을 골라 대조한다(작업 순서 4단계).
• references/before-after.md — "바꾼 이유"의 출력 형식과 윤문 전후 예시. 결과를 내놓는 형식을 여기서 따른다(작업 순서 5단계).