Personal Brand OS — 주간 빌드업 공유

2026-03-28 ~ 04-03 | 삽질의 기록과 인사이트

이 문서의 목적

단순히 “뭘 만들었다”가 아니라, 어떤 시행착오를 거쳤고 → 거기서 뭘 배웠고 → 앞으로 어떻게 적용할 건지를 시간순으로 공유합니다.

프로젝트 한 줄 요약

Obsidian 노트 / 직접 입력 / 사진 폴더를 멀티에이전트 파이프라인으로 처리해 LinkedIn·네이버 블로그 콘텐츠를 생성하는 시스템.

현재 아키텍처

타임라인별 삽질과 인사이트

Day 1 (03-28~29) — v1 Python 파이프라인 완성

한 것: Python + Claude SDK로 6개 에이전트 순차 파이프라인 구현

Source Reader → Content Strategy → LinkedIn Writer → Brand Voice → QA → 파일 저장

삽질: Claude SDK가 rate_limit_event라는 아직 파싱 못하는 메시지 타입을 보내서 파이프라인이 터짐. 원인 찾는 데 시간을 꽤 썼는데, 결국 SDK 버그였고 try/except로 우회.

인사이트: SDK의 미문서화된 동작은 항상 존재한다. 방어적 예외 처리가 프로덕션 안정성의 기본.

적용 계획: SDK 업데이트 시 해당 핸들링이 여전히 필요한지 정기 체크.

Day 2 (03-31) — v2 서브에이전트 전환 + 콘텐츠 품질 문제 발견

한 것: Python 코드 대신 .claude/agents/*.md 마크다운으로 에이전트를 정의하는 v2 구조로 전환. 동시에 네이버 블로그 파이프라인 설계.

삽질 — 콘텐츠 할루시네이션:

첫 E2E 테스트에서 충격적인 결과. “회고”를 주제로 글을 생성했는데, 오프닝이 “비행기 안에서 글이 더 잘 써진다” — 회고와 전혀 관계없는 다른 노트의 내용이 섞여 들어옴.

원인을 추적해보니:

LinkedIn Writer가 “눈에 띄는 소재”에 끌려 주제와 무관한 디테일을 오프닝에 사용
Brand Voice(톤 검수)와 QA(포맷 검수)만 있고, “소스와 일치하는가”를 검증하는 단계가 없었음

해결: content-reviewer 에이전트를 새로 만들어 Writer와 Brand Voice 사이에 삽입. 4축 검증:

소스 충실도 — 소스에 없는 내용이 추가되었는가?
서사 일관성 — 오프닝→본문→마무리가 하나의 흐름인가?
할루시네이션 — 창작된 사실이 있는가?
주제 집중도 — 글이 한 주제에 집중하는가?

인사이트: 톤 검수만으로는 콘텐츠 품질을 보장할 수 없다. AI는 “그럴듯한” 소재에 끌린다. 생성과 검증은 반드시 분리해야 한다 — 코드 리뷰처럼.

적용 계획: 모든 콘텐츠 파이프라인에 독립 검증 게이트를 기본 구조로 포함.

Day 3 (04-01) — 네이버 블로그 실전 테스트, 3가지 폭탄

실제 사진 폴더로 네이버 블로그 글을 생성하는 E2E 테스트. 하루에 3가지 문제가 동시에 터짐.

폭탄 1: 사진 할루시네이션 (55% 오류율)

22장 중 12장의 사진 분석이 틀림. “미나리”, “후추” 등 사진에 없는 음식이 등장.

원인 추적: 앞서 분석한 기존 블로그 글(“순삼이네미나리삼겹살”)의 컨텍스트가 Photo Analyzer를 오염시킴. 오케스트레이터가 “편의상” 서브에이전트 없이 직접 분석하면서 컨텍스트 격리가 무너진 것.

해결: 2층 방어

소프트 방어: 프롬프트에 “전수 Read 강제, 파일명 추측 금지, 외부 정보 반영 금지” 명시
하드 방어: Photo Analyzer를 반드시 별도 서브에이전트로 실행 (컨텍스트 격리)

결과: 재테스트에서 22/22장 정확 (55% → 0% 오류율)

인사이트: 편의상 직접 수행하면 설계 의도가 무너진다. 테스트도 실전과 같은 조건이어야 한다. 방어는 프롬프트(소프트)와 구조(하드) 두 층으로.

폭탄 2: 네이버 차단 (Research Agent 무력화)

“오바마연탄구이” 가격을 검색하려는데, WebSearch/WebFetch가 네이버 robots.txt에 막혀서 한국 로컬 정보를 아예 못 가져옴.

해결: Playwright MCP 설치. 실제 브라우저로 네이버 지도 직접 접근하는 폴백 경로 확보.

인사이트: 도구의 제약은 설계 시점에 파악해야 한다. 한국 로컬 서비스는 글로벌 크롤러와 상성이 나쁘다. 폴백 전략 필수.

폭탄 3: 파이프라인 과설계 (6단계 → 3단계)

설계: Photo → Research → Strategy → Writer → Voice → QA (6단계) 실전: Photo → Writer(Strategy+Voice 내장) → QA (3~4단계)

Strategy ↔ Writer를 분리하면 맥락 전환 비용이 이점보다 컸고, Brand Voice도 Writer가 이미 수행하고 있었음.

해결: 실전을 공식화. 기본 흐름을 3~4단계로 축소하고, 분리된 에이전트 파일은 복잡한 케이스용으로 보존.

추가 개선:

Writer 질문 6개 → 3개 제한 (“스스로 해결 가능한 질문 금지”)
파일명: YYYY-MM-DD_HH:MM_{type}.md → YYYY-MM-DD_{장소명}_{type}.md (실용성)

인사이트: 설계와 실전은 다르다. 실전이 이긴다. 과설계를 인정하고 실전 흐름을 공식화하는 유연함이 필요하다.

Day 4 (04-02) — 패러다임 전환: “소재 기반” → “정체성 기반”

계기: 외부 프로젝트(Polysona — 심리학 기반 다중 페르소나 프레임워크) 분석 중 우리 파이프라인의 근본적 전제 문제 발견.

두 시스템의 차이:

	우리 (Personal Brand OS)	Polysona
원천	소재 (노트, 사진)	정체성 (페르소나)
흐름	소재 → 가공 → 콘텐츠	정체성 → 소재 필터링 → 콘텐츠
결과	글이 소재를 닮는다	글이 사람을 닮는다

우리 시스템은 소재가 좋으면 글이 좋고, 소재가 평범하면 글도 평범. “이 사람이라면 이 주제를 어떻게 볼까?”라는 관점이 빠져있었음.

선택지 분석:

A) Polysona 방식 그대로: 10개 심리학 프레임워크 인터뷰, 3.5~4시간 셋업 → 품질 4.9점
B) 하이브리드: 부트스트랩 인터뷰 30분 → 4.0점 시작, 점진 축적으로 4.9점 수렴
C) 현재 유지: 근본 문제 미해결

선택: B (하이브리드)

근거: Polysona 시뮬레이션에서 10개 프레임워크 중 3개(McAdams, IFS, Clean Language)가 90% 기여. 셋업 7배 차이 vs 품질 0.9점 차이라면, 적은 투자로 시작해서 점진 축적이 현실적.

구현: personas/hminn/ 디렉토리에 3개 파일 생성

personas/hminn/
├── profile.md          ← 3-Layer 정체성 (others-see-me, want-to-be-seen, conscious-ideal)
├── tension_hooks.md    ← 내적 갈등 → 콘텐츠 각도 변환
└── signature_phrasing.md ← 선호/회피 표현, 톤

플랫폼별 차등 적용:

LinkedIn/에세이: 전체 참조 (정체성 투영 필요)
네이버 블로그: signature_phrasing.md만 참조 (톤 일관성만 유효)

인사이트: 품질 천장은 개별 에이전트가 아니라 파이프라인의 전제가 결정한다. 같은 시스템만 들여다보면 개선만 반복하게 됨. 완전히 다른 전제를 가진 시스템과 비교해야 우리 시스템의 맹점이 보인다.

적용 계획: 부트스트랩 인터뷰를 진행하고, 대화 과정 자체에서 드러나는 의사결정 패턴(제안 수용 전 트레이드오프 질문, 예외 케이스 본능적 체크 등)을 페르소나 데이터로 역류시키는 피드백 루프 구축.

종합 인사이트 (Cross-Cutting Lessons)

1. 생성과 검증을 분리하라

같은 에이전트가 쓰고 검증하면, 자기 글의 문제를 발견하기 어렵다. 코드 리뷰처럼 독립 에이전트가 검증해야 한다.

2. 컨텍스트 격리가 할루시네이션을 막는다

“편의상 직접” = 컨텍스트 오염. 서브에이전트 격리는 귀찮아서가 아니라 정확도를 위해 존재한다.

3. 실전이 설계를 이긴다

6단계가 실전에서 3단계로 수렴했을 때, 설계를 고집하는 대신 실전을 공식화하는 유연함이 필요하다.

4. 품질 천장은 전제가 결정한다

개별 에이전트를 아무리 개선해도, “소재 기반”이라는 전제 자체가 한계면 천장에 부딪힌다. 다른 전제를 가진 시스템과 비교해야 맹점이 보인다.

5. 다층 방어가 필수다

프롬프트 제약(소프트) + 구조적 격리(하드). 한 층이 무너질 가능성을 항상 고려.

6. 도구의 한계는 설계 시점에 파악하라

“되겠지”로 넘어간 도구 제약이 실전에서 터진다. 폴백 전략은 설계 단계에서 확보.

7. 반복 2회 = 자동화 신호

같은 작업을 두 번 했으면, 세 번째는 자동화해야 한다. 프로토타입 검증 후 전역 승격이 리스크를 최소화한다.

Next Steps

우선순위	항목	상태
P0	Polysona 부트스트랩 인터뷰 (30분) → personas/ 데이터 강화	예정
P0	네이버 파이프라인 축소 구조 E2E 재검증	예정
P1	대화 패턴 → 페르소나 역류 피드백 루프	설계 중
P1	에세이/브런치 포맷 확장 (Persona 데이터 활용)	대기
P2	Content Reviewer → 네이버 파이프라인 통합	대기

이 문서는 Personal Brand OS 프로젝트의 주간 빌드업 기록입니다. Architecture diagram: docs/personal-brand-os-architecture.png

2026 04 03 weekly share