결과물
- 콘텐츠 자동화 프로젝트로 확장 진행중
1. 왜 이걸 만들었나
문제 인식
피드가 호기심의 주도권을 가져간다.
SNS를 열면 새로운 기술과 툴이 쏟아지고, 읽고·저장하고·공유하는 행위가 반복되다 보면 — 어느 순간 내가 궁금해서 찾아본 것보다 피드가 보여줘서 소비한 것들이 훨씬 많아진다. 호기심이 사라진 게 아니라, 호기심의 주도권이 나에게서 알고리즘으로 넘어가 있던 것.
동시에 생각은 많은데 휘발되는 경험이 반복됐다. “어디에 써야 하지?”, “어떤 형식으로?” — 기록 전 판단의 부담이 결국 기록 자체를 막는다.
해결 방향
피드를 줄이는 것보다 먼저, 나만의 질문을 되찾는 것.
정보를 더 주는 AI가 아니라, 스스로 질문을 던지고 생각을 확장할 수 있도록 옆에 있는 존재. 이것이 Sullivan이다.
인사이트
다시 한다면?
2. 이름의 이유 — (Anne) Sullivan
이름은 Anne Sullivan에서 왔다. 헬렌 켈러의 선생님이었던 그녀가 헬렌에게 준 것은 정보가 아니라 세상을 인식하는 언어였다.
Sullivan 프로젝트의 세 가지 설계 원칙은 Anne Sullivan의 교육 철학에서 직접 가져왔음
| 원칙 | Anne Sullivan의 방식 | Sullivan의 적용 |
|---|---|---|
| 살아있는 호기심 | 정해진 커리큘럼 버림. 헬렌이 관심을 보이는 것 중심으로 | 형식 없이 던지는 생각 그대로 받음. 판단의 부담 제거 |
| 생각하게 만든다 | 빠른 답 대신 “t-h-i-n-k” | 정리해주기 전에 질문 먼저. 결론을 대신 내려주지 않음 |
| 틀을 유연하게 | 사람에 맞게 틀을 다듬어 감 | tone-guide.md는 살아있는 문서. 대화하면서 계속 업데이트 |
3. 하루 흐름 — 실제 사용 예시
08:00 [아침 브리핑 자동 전송]
"어제 포착: LangChain 하네스 설계 원칙 — 에이전트 막힘을
'능력 부족'이 아닌 '환경 부족'으로 재해석하는 것이 핵심이야.
[오늘 집중할 것] Sullivan capture agent 구조 개선
[오늘의 질문] 지금 만들고 있는 것에서 '환경'에 해당하는 게 뭐야?"
중간 [아무 때나 생각 포착]
사용자: "Progressive Disclosure 원칙 — 앞단 짧은 지도,
깊은 정보는 필요할 때만"
Sullivan: "[아이디어] 하네스 엔지니어링의 핵심 사고법
• 막힘의 원인을 환경 문제로 재해석
• 과잉 엔지니어링 금지 — 모델 발전 시 걸림돌
연결: [LangChain Agent 설계](/missions/LangChain Agent 설계/), [Sullivan 설계 원칙](/missions/Sullivan 설계 원칙/)"
13:00 [점심 체크인 자동]
Sullivan: "오전 어땠어?"
사용자: "capture agent 리팩토링 완료"
Sullivan: "구조를 직접 손댔을 때 오는 그 명쾌함이 있겠네.
지금 에너지 레벨 1~10으로?"
사용자: "7"
Sullivan: "오전 흐름 이어가기 좋은 컨디션이야.
오후는 리팩토링 결과 검증까지 한 사이클 마무리해봐."
22:00 [자기 전 회고 자동]
Sullivan: "오늘 하루 어땠어?"
사용자: "capture 고쳤고, 다이어그램 작업도 진행했어"
Sullivan: "[오늘 포착된 것] LangChain 하네스 원칙 + Sullivan 구조 개선
[오늘의 발견] 오늘 작업한 두 가지가 같은 문제를 다른 레이어에서
다루고 있었어 — 에이전트에게 좋은 환경을 주는 것.
[내일을 위한 질문] 지금 Sullivan의 '환경'을 가장 약화시키는
요소는 뭐야?"4. 데이터가 쌓이는 구조
Helen/ (Obsidian Vault)
└── Sullivan/
├── Captures/ ← 생각이 쌓이는 곳
│ └── YYYY-MM-DD/
│ └── HH:MM - [제목].md
│ (frontmatter: type, category, date, tags)
│
├── Reflections/ ← 하루/주간 흐름이 쌓이는 곳
│ ├── YYYY-MM-DD.md (자기 전 회고)
│ └── weekly-YYYY-MM-DD.md (주간 회고)
│
├── Briefings/ ← 아침 브리핑이 쌓이는 곳
│
└── Insights/ ← 연결고리가 쌓이는 곳만든과정
Step 0. 클로드에서 나의 고민을 중심으로 발산 → 수렴 → md 파일 및 내러티브 문서 작성
- ‘능동적인 호기심이 도둑 맞았다’는 주제로 클로드와 대화
- 호기심의 주도권이 나한테서 피드에게로 넘어갔다
- 매일 필요한 질문을 던지고, 능동적인 호기심을 불러 일으키며, 내가 무엇을 하고 싶은지 ‘명확함’을 갈고 닦게 만들어주는 AI Agent가 필요하다고 생각
- 나의 모든 생각과 아이디어들을 받아주고, 그 생각들을 확장시켜주고 반대로 질문도 하고, 정리한 생각들을 기록으로 남기고, 그것들을 매일, 혹은 매주 리포트 형태로 만들어 같이 회고도 하면서 삶의 방향성을 함께 만들어 나가는
- 해당 세션 내용을 기반으로 Sullivan 프로젝트 구상 및 초기 기획 진행
- 초기 CLAUDE.md와 Narrative.md 생성
Step 1. 아이디어 정의 → Claude Code에 프로젝트 컨텍스트 주입
- Claude Code 첫 메시지: “CLAUDE.md를 읽고 프로젝트 전체 구조를 파악해줘.”
- 이미 써둔 CLAUDE.md와 Narrative.md를 읽히는 것으로 시작. 코드를 짜기 전에 Claude와 설계 논의를 먼저 했다.
- Obsidian 연동방식(MCP vs 파일 시스템), 분류 체계(폴더 분리 vs frontmatter), 노트 간 연결 구조 등 주요 아키텍처 결정을 Claude와 대화하며 확정.
Step 2. Agent MD 파일 설계 (Claude가 직접 작성)
아키텍처 확정 후 Claude Code가 Agent 명세 파일들을 순서대로 작성.
capture-agent.md, morning-agent.md, reflection-agent.md, insight-agent.md, tone-guide.md, questioning.md, weekly-report.md, hminn-now.md.
코드는 아직 없고, Claude가 어떻게 행동할지를 먼저 정의하는 단계였다.
Step 3. 자동화 구조 확정 (텔레그램 봇 + launchd)
“Agent를 내가 직접 트리거해야 하는 구조야?” 라는 질문에서 자동화 방식 논의 시작. “Claude에 스케줄 기능이 있다고 들었는데?” → 없다는 걸 확인 → Python 봇 + macOS launchd로 백그라운드 상시 실행하는 구조로 결정. Claude Code hooks는 이 시스템에서 불필요하다는 것도 이 단계에서 정리됨.
Step 4. 텔레그램 봇 토큰 발급 + Python 코드 전체 생성
흐민이 직접 @BotFather에서 봇 토큰을 발급해서 전달. Claude Code가 토큰을 받아 Python 파일 전체를 한 번에 작성: config.py, state.py, obsidian.py, bot.py, cheduler.py, 5개 agents/*.py, requirements.txt, sullivan.bot.plist. 설계 논의에서 나온 구조가 그대로 코드로 변환되는 단계
Step 5. 첫 실행 → 버그 연속 발견
봇을 실제로 돌려보니 “/start 커맨드도 capture로 들어가고, 파일이 실제로 저장은 안 되고, URL 처리 실패”가 연달아 터짐. 흐민: “미치겠다 ㅋㅋㅋ 뭔짓을 한거냐 도대체?” — 이 구간이 가장 험난했다. fix → 새 버그 → fix → 새 버그가 반복됨.
Step 6. Capture 시스템 전면 재설계
흐민이 직접 원인 분석서를 작성해서 Claude Code에 전달: “Implement the following plan.” 핵심 원칙 확립: Python이 전처리, Claude가 판단. URL/텍스트/YouTube를 Python이 먼저 분기하고, Claude는 분류·요약 판단만 담당. capture.py 전면 재작성.
Step 7. Test/Prod 환경 분리 구축
3일 뒤 재개. 스케줄러가 조용히 죽어있다는 걸 발견. 흐민: “만약 실제로 서비스하는 프로덕트였다면 이런 식으로 접근했을까?” → 테스트 봇 토큰 별도 발급, iCloud Drive 내 Sullivan-Test/ 폴더 분리, setup_test_vault.py, trigger_now.py, deploy.sh 생성. 개발
워크플로우 확립: 코드 수정 → 테스트 봇 E2E 확인 → 흐민 승인 → prod 배포.
Step 8. 협업 규칙 명문화
Chat 모드에서 Claude가 파일 저장을 날조하는 사건 발생. 흐민: “원인이 뭔지 분석하고 브리핑 먼저해.” — 이 시점부터 Claude Code와의 협업 방식 자체를 CLAUDE.md에 규칙으로 추가. “원인 확정 전 증거 확인”, “코드 변경 전 브리핑 필수”, “테스트 → 승인 → 배포 순서” 등이 명문화됨.
삽질 & 인사이트
”Claude가 꼭 필요한 프로세스에 대한 인지”
capture agent 초기 설계: Claude에게 Obsidian용 YAML frontmatter 와 텔레그램용 표시 메시지를 한 번에 요청했다. Claude는 두 가지를 모두 생성하면서 표시 메시지가 max_tokens 한계에 걸려 중간에 잘렸다.
해결: Claude는 <meta> 구조화 블록만 생성. Python이 파싱해서 Obsidian 파일도 만들고, 텔레그램 표시 메시지도 조립한다.
원칙: Claude = 판단·분류·언어 처리. Python = 데이터 조립·라우팅·저장.
”iCloud Drive는 파일 잠금(EDEADLK)이 발생한다”
iCloud 동기화 중 파일에 접근하면 OSError: [Errno 11] EDEADLK 가 뜬다. 초기에는 즉시 실패. 지수 백오프 재시도(최대 5회)로 해결.
교훈: 파일 시스템 연동은 항상 클라우드 동기화 충돌 가능성을 고려해야 한다.
”설계 문서의 위치가 참조 여부를 결정한다”
구현 워크플로우 가이드를 WORKFLOW.md라는 별도 파일로 만들었다. 이후 Claude Code가 이 파일을 자동으로 참조하지 않는다는 것을 확인. CLAUDE.md에 직접 추가해야 매 세션마다 자동으로 읽힌다.
교훈: “중요한 규칙”은 반드시 자동으로 로드되는 파일에 넣어야 한다. 별도 파일은 명시적으로 참조하지 않으면 존재하지 않는 것과 같다.
”Chat 모드에서 Claude는 능력 경계를 스스로 그리지 않는다”
/chat 모드에서 “파일 저장해줘”를 요청하면, 파일 저장 기능이 없음에도 Claude가 “저장했어”라고 응답하고 존재하지 않는 경로까지 지어냈다.
해결: 시스템 프롬프트에 명시적 경계 선언. “지금 /chat 모드로 실행 중이다. 파일 저장 기능이 없다. 실제로 실행하지 않은 행동을 수행했다고 말하지 마라.”
교훈: Claude는 선의로 거짓말할 수 있다. 능력 경계는 개발자가 명시적으로 선언해야 한다.
”이슈 원인 분석에서 그럴듯한 추측을 조심할 것”
capture 반환 메시지 truncation 이슈를 분석할 때, 처음에는 Telegram 4096자 제한으로 진단했다. 이후 max_tokens로 재진단했다. 실제 원인은 Claude가 두 가지 출력(meta + display)을 생성하면서 display 부분이 잘린 것이었다.
교훈: 이슈 분석 시 로그, 실제 파일, 코드 흐름을 확인하기 전까지 원인을 확정하지 않는다. “그럴듯한” 추측은 틀린 방향으로 빠르게 달리게 만든다.