링크드인 Ep.2 캡션 패키지 「AI를 실무에 붙인다는 것의 의미」

🟡 status: draft — 대표 승인 대기. /linkedin-post 스킬의 첫 적용 산출물. 캡션 패키지만 포함하며 카드 비주얼·장별 구성은 도윤(brand-content-designer) 소관으로 이번 범위 밖이다. 규칙 정본은 knowledge/marketing/linkedin-playbook.md.

0. 판정 (스킬 ① 단계)

핵심 메시지(하나): AI를 실무에 붙일 때 병목은 모델 성능이 아니라, 우리가 명시하지 않고 넘어간 규칙이다.

1. 캡션 본문 (한국어)

AI가 실수한 줄 알았습니다. 확인해 보니, 규칙을 적어둔 문서가 아예 없었습니다.

저희는 콘텐츠를 만들 때 AI를 실무에 붙여 씁니다. 초안을 잡고, 검토하고, 다시 고치는 과정에 함께 들어옵니다.

지난주 게시물 하나에서 링크를 잘못된 자리에 넣었습니다. 원인을 찾으려고 저장소를 통째로 검색했습니다. 그 규칙을 적어둔 문장은 0건이었습니다. 반대로 다른 규칙 하나는 서로 다른 문서 네 곳에 복사돼 있었고, 값이 조금씩 달랐습니다.

사람에게 일을 맡길 때는 이런 공백이 잘 드러나지 않습니다. 경험으로 메우니까요. AI는 그 자리를 메우지 않습니다. 비어 있으면 비어 있는 대로 작동합니다.

그래서 저희가 고친 건 프롬프트가 아니라 문서였습니다. 규칙을 한 곳에 모으고, 나머지 문서는 그곳을 가리키게 했습니다. 어긋나면 자동으로 걸리도록 검사도 붙였습니다.

AI를 실무에 붙인다는 건 모델을 고르는 일이 아니었습니다. 그동안 말로만 공유해 온 것들을, 글로 옮겨 적는 일에 가까웠습니다.

AI와 함께 일하는 방식, 그 자체를 만들고 있습니다.

— Hunexia, 2026년 7월

AI에게 일을 맡겼다가, 우리가 안 적어둔 것 때문에 어긋난 적 있으신가요?

관련 링크는 첫 번째 댓글에 남겨두었습니다.

설계 노트

• 훅(§2.1): "A가 아니라 B" 대비를 첫 2줄 안에서 완결했다 — A(AI의 실수) ↔ B(우리가 안 적어둔 것). 3번째 줄부터는 "무슨 규칙? 어떤 실수?"가 남아 "더 보기"를 누를 이유가 유지된다.
• 수치(§2.1·[B] 5번): 0건 · 네 곳을 본문에 넣어 주장 대신 근거로 말한다.
• 1인칭 복수 전환(§2.7): "우리가 무엇을 했다"가 아니라 "우리가 무엇을 겪었고 무엇을 배웠다" 구조. 주어 "저희/우리"는 유지하되 동사가 결과가 아니라 과정·배움을 가리킨다.
• 한계를 함께 말한다: "AI는 그 자리를 메우지 않습니다"는 브랜드 권장 표현(가능성과 한계를 함께)이자 지양 표현("AI가 모든 것을 해결")의 정확한 반대편이다.
• 내부 용어 비노출: SSOT·스킬·게이트 같은 내부 명칭을 쓰지 않고 "한 곳에 모으고 / 가리키게 하고 / 검사를 붙였다"로 풀었다. "AI가 구성했다" 류 금지 프레이밍(launch-promotion-strategy.md:21)도 회피했다.

2. 해시태그 한 줄 (게시물 말단 별도 배치)

#휴넥시아 #ClaudeCode #RAG #컨텍스트엔지니어링

총 4개(상한 5 이하 ✅). 본문에 넣지 않고 게시물 말단에 별도 한 줄로 배치한다(§2.3.6-1).

⚠️ #RAG의 내용 정합성이 이번 회차에서 약하다. 이 게시물은 RAG를 다루지 않는다. 규칙(§2.3.4)이 Pillar 고정 태그를 내용이 아니라 Pillar로 붙이도록 설계돼 있어 그대로 따랐다. 첫 적용에서 이미 마찰이 났으므로 §5.1에 규칙 재검토 항목으로 올린다. 임의 이탈은 하지 않았다 — 첫 회차에 조용히 어기면 규칙이 검증될 기회를 잃는다.

3. 첫 댓글 문안 (대표 게시용 — 게시 직후)

게시 직후 대표가 첫 댓글로 등록한다(§2.4 절차 3단계). 아래를 그대로 복사한다.

본문에서 줄인 부분을 조금 더 적어둡니다.

저희가 실제로 한 조치는 세 가지였습니다.

1. 흩어진 규칙을 한 문서로 모으고, 나머지 문서는 그 문서를 가리키게만 했습니다.
2. "무엇이 규칙인가"와 "어떻게 작업하는가"를 분리했습니다. 규칙이 바뀌면 한 곳만 고치면 됩니다.
3. 규칙을 어기면 자동으로 걸리도록 검사를 붙였습니다. 사람이 매번 기억하지 않아도 되도록요.

회사가 정리해 가는 지식은 위키에 공개해 두고 있습니다. 한국어와 영어 모두 열려 있습니다.

hunexia.com

• 첫 댓글이 링크 투척으로 끝나지 않게 설계했다. 본문에서 의도적으로 줄인 실행 항목 3가지를 여기 담아 댓글 자체가 읽을 가치를 갖게 했다. 링크는 그 끝에 자연스럽게 붙는다.
• URL 확정 필요: 기본값을 hunexia.com으로 두었다(Ep.5에서 실제 사용된 주소). 위키 경로 (hunexia.com/wiki/)로 딥링크할지는 §5.1에서 대표·보라 확인이 필요하다.

4. DoD 자체 점검 (playbook §5)

4.1 캡션 체크리스트 (§5.2)

4.2 미통과·N/A 항목 — 숨기지 않고 보고

#13 — 고정 태그 일관성 검증 불가 (N/A, 미통과 아님)

Ep.1=Pillar A · Ep.4=C · Ep.5=A. Ep.2가 우리 첫 Pillar B 게시물이라 대조할 직전 동일 Pillar 게시물이 없다. 즉 이번 회차는 검증받는 쪽이 아니라 기준선을 만드는 쪽이다. 이후 Pillar B 게시물은 이 세트 (#휴넥시아 + #ClaudeCode #RAG)와 글자 단위로 일치해야 한다.

#3 — 조항 문자와 목적의 어긋남 (규칙 결함 발견) → ✅ 2026-07-20 개정 완료, 본 문서 2026-07-22 반영

§2.8-3은 "직전 2회가 발표형이면 이번 회차는 다른 유형이어야 한다"고 적혀 있다. 직전 2회(Ep.4·Ep.5)가 발표형이므로 조항이 발동한 상태이고, 이번 회차를 지식·조언형으로 잡아 조항을 충족했다.

다만 체크리스트 §5.2 #3의 종전 문장은 "직전 2회가 발표형이 아니다"로 적혀 있어, 조항을 지켰는데도 체크가 ✗로 읽혔다. 체크리스트 문장이 규칙(§2.8-3)을 잘못 옮긴 것이었다. 규칙이 아니라 체크리스트가 틀렸다.

✅ 해소 완료. playbook §5.2 #3은 2026-07-20 정정됐다 — "이번 회차가 발표형일 때만 확인한다. 직전 2회가 모두 발표형이면 다른 유형으로 전환(§2.8-3). 이번 회차가 발표형이 아니면 이 항목은 N/A다" (marketing-linkedin-playbook.md:664, 정정 사유에 *"Ep.2 첫 적용에서 미래가 발견"*이 명기됐다). 따라서 위 §4.1 #3의 판정은 ⚠️ 가 아니라 N/A이며, 본 문서 §5.1-3의 결정 대기 항목도 종결됐다 (2026-07-22 반영). 규칙이 먼저 고쳐졌는데 발견 문서가 미해결로 남아 있으면, 다음 사람이 이미 닫힌 문제를 다시 연다.

4.3 게시 운영 체크리스트 (§5.3) — 게시 시점 담당자용

미래 소관 밖 항목이 다수라 상태만 표기한다.

5. 확인 필요 (대표·이든)

5.1 결정 대기 3건

5.2 영문 캡션을 만들지 않은 이유 (판단 근거)

만들지 않았다. playbook §3.3이 ko/en 근접 게시의 중복 리스크를 미해결 열린 질문으로 두고 "데이터 없이 ko/en 정책을 바꾸지 않는다"고 명시하고 있다. Ep.5가 ko/en 2게시물을 같은 날 올린 결과를 지안이 아직 관측 중이므로, 측정 결과가 나오기 전에 같은 패턴을 반복하면 Ep.5 관측 자체가 오염된다.

• Ep.5 관측 결과가 "잠식 없음"이면 → Ep.2 영문판을 후행 게시하거나, Ep.3부터 ko/en을 재개한다.
• "잠식 있음"이면 → 시차 게시(24~48시간) 또는 언어 단일화를 검토한다.
• 어느 쪽이든 대표가 지금 영문을 원하시면 만들 수 있다. 그 경우 §3.3 예외로 사유 1줄을 기록한다(§5.4).

변경 이력