Claude Opus 4.5와 Obsidian으로 만드는 진짜 AI 직원 워크플로

코딩 에이전트에서 'AI 직원'으로 진화한 Claude Code

요즘 개발자든 기획자든, "AI가 진짜 일을 좀 대신 해주면 좋겠다"는 생각 한 번쯤은 해봅니다. 채팅창에 질문 던지면 답은 잘 나오는데, 막상 프로젝트 단위로 일을 맡기는 수준까지 가면 어딘가 어설픈 경우가 많습니다. 이 지점에서 Claude Opus 4.5와 Claude Code 조합이 흥미로워집니다. 더 이상 "코드를 잘 짓는 챗봇"이 아니라, 로컬 폴더 전체를 하나의 작업공간으로 인식하고 스스로 구조를 만들고 유지하는 쪽으로 진화하고 있기 때문입니다.

에이전트의 본질은 '기억 구조'에 있다

이번 사례의 핵심은 거창한 모델 성능보다도, Obsidian과 Claude Code를 엮어서 하나의 "에이전트 워크스페이스"를 만든 구조에 있습니다. 로컬 디스크에 Obsidian 볼트를 만들고, 그 폴더를 Claude Code가 바라보는 코드베이스로 등록하니, AI가 읽고 쓰는 대상이 단순 텍스트가 아니라 프로젝트 전체가 됩니다. README를 최상위 규칙서로 두고, 광고, 콘텐츠, 리서치, 전략 문서를 폴더로 나누는 순간, 이 에이전트는 매번 대화를 새로 시작하는 챗봇이 아니라, 회사 인트라넷에 상주하는 신입 마케터에 가까운 존재로 바뀝니다.

여기서 많이들 놓치는 부분이 있습니다. 똑같이 GPT나 Claude에 설명을 길게 붙여 쓰면 비슷한 결과가 나오겠지라고 생각하기 쉽습니다. 그런데 매 세션마다 온보딩을 반복하는 구조와, README와 예시 문서가 계속 쌓이는 워크스페이스를 기반으로 돌리는 구조는 생산성 곡선 자체가 다릅니다. 제 기준에서는 이 차이가 "AI가 도와주는 업무"와 "AI에게 맡기는 업무"를 가르는 분기점에 가깝습니다.

README는 에이전트의 뇌, 예시는 성격이다

이 워크플로에서 README는 단순 설명문이 아니라, 에이전트의 장기 기억과 역할 인식을 규정하는 뇌에 가깝습니다. 회사가 무엇을 하는 곳인지, 이 볼트가 어떤 직무를 위한 공간인지, 어떤 폴더에 어떤 유형의 산출물이 들어가야 하는지, 참고해야 할 외부 문서는 어디인지가 이 파일에 담깁니다. 예를 들어 Vibe Code라는 앱의 공식 문서를 링크하고, 이 앱이 어떤 문제를 푸는지 두 단락으로 요약해 두니, 이후에 광고나 스크립트를 만들 때마다 모델이 같은 세계관 안에서 사고하기 시작합니다.

여기에 고수들이 챗봇에게 스타일을 학습시킬 때 쓰던 기법이 그대로 들어옵니다. 경쟁사의 잘 먹혔던 광고 스크립트를 모아 "고성능 광고 예시"라는 문서를 만들고, 인기 유튜버의 장문의 스크립트를 "고품질 콘텐츠 예시"로 정리해 두는 방식입니다. 저라면 이 예시 구축 단계에 시간을 제일 많이 쓰겠습니다. 모델이 한 번에 천재가 되지는 않지만, 예시와 README를 통해 "이 팀이 원하는 글의 톤과 깊이"를 배울 수 있기 때문입니다.

Obsidian 워크스페이스가 사실상 팀 인트라넷이 되는 순간

많은 팀이 Notion이나 구글 문서로 지식 관리를 해도, 정작 AI가 그 구조를 온전히 이해해서 함께 일하는 경험까지는 잘 못 갑니다. 로컬 기반인 Obsidian과 Claude Code 조합은 이 간극을 줄이는 데 꽤 적합한 선택지입니다. 특히 국내 환경에서는 클라우드에 민감한 데이터 올리기 꺼려하는 팀에게 더욱 의미가 있습니다.

로컬 폴더를 통째로 '업무 컨텍스트'로 쓰는 방식

Obsidian 볼트와 Claude Code 프로젝트 폴더를 일치시키는 순간, AI는 코드뿐 아니라 모든 마크다운 문서를 하나의 코드베이스처럼 다룹니다. 새로운 광고 아이디어를 적어 둔 문서를 생성해 두고, AI에게 "이 파일을 참고해서 5개의 광고 시나리오를 써 달라"고 지시하면, 에이전트는 해당 파일을 열어 참고하고, 결과물은 자동으로 Ads 폴더 아래 날짜별 하위 폴더로 나누어 저장합니다. 그 과정에서 폴더가 없으면 새로 만들고, README에 "광고는 모두 이 경로에 정리한다"는 규칙까지 스스로 추가합니다.

여기서 중요한 포인트는 사람이 해야 할 일의 성격이 조금 바뀐다는 점입니다. 예전에는 매 요청마다 "이런 스타일, 이런 길이, 이런 대상, 이런 메시지"를 자세히 설명해야 했다면, 이제는 워크스페이스 구조와 규칙을 설계하는 쪽이 핵심 업무가 됩니다. 저라면 이걸 작은 내부 개발자 포털이나 브랜드 북을 만든다는 느낌으로 접근하겠습니다.

웹 리서치, 스타일 모사, 문서 정리까지의 일관된 흐름

흥미로운 부분은 웹 검색과 리서치도 같은 흐름 안에 들어온다는 점입니다. 에이전트에게 경쟁 앱의 광고를 조사하게 하고, 잘 나가는 브랜드들의 캠페인 각도와 메시지를 분석한 뒤, 이를 "리서치 리포트"라는 마크다운 파일로 Research 폴더에 쌓아 두게 만들 수 있습니다. 이어서 이 리포트를 기반으로 추가 광고 스크립트를 발주하면, AI는 방금 작성한 문서를 스스로 참고 자료로 사용합니다.

장문 콘텐츠도 비슷합니다. 인기 유튜버의 AI 관련 영상을 트랜스크립트로 가져와서 예시로 정리하고, 그 스타일을 분석하게 한 다음, 동일한 톤과 구조를 유지한 채 자사 제품을 주제로 한 긴 스크립트를 써 달라고 요청합니다. 이렇게 보면 "에이전트에게 과제를 주고, 에이전트가 자료를 모으고, 워크스페이스 안에 정리하고, 그걸 다시 참고해서 새로운 산출물을 만드는 사이클"이 완성됩니다. 여기까지 오면 단순 자동 완성 도구와는 다른 차원의 경험이 됩니다.

콘텐츠·마케팅 팀이 얻는 실질적 이득과 함정

이런 세팅이 가장 먼저 빛을 발하는 곳은 개발팀보다 콘텐츠와 마케팅 조직입니다. 특히 소규모 스타트업, 1인 크리에이터, 소수의 정규직과 여러 외주 인력이 섞여 있는 팀에게는 꽤 현실적인 레버리지입니다. 반대로 이미 매뉴얼이 잘 정리된 대기업 조직에서는 생각보다 파급력이 제한적일 수도 있습니다.

누가 이득을 보고, 누구에게는 과장된 약속인가

페르소나 관점에서 보면, 업무의 상당 부분이 텍스트 기반 산출물인 사람에게 특히 유리합니다. 광고 문구, 영상 스크립트, 기획안, 리포트, FAQ 문서처럼 결국 문서로 귀결되는 일이 많고, 동시에 팀 내에 "문서 구조와 규칙을 설계할 사람"이 최소 한 명은 있는 조직이 대상입니다. 국내 환경에서는 앱 서비스 스타트업의 C레벨, 1인 유튜버, 교육 콘텐츠 제작자, 소규모 마케팅 대행사가 여기에 해당합니다.

반대로 이미 업무 시스템이 정형화되어 있고, 사내 보안 규정이 까다로운 금융권, 공공기관에서는 도입 난이도가 훨씬 높습니다. 로컬에 두더라도 정책상 외부 AI가 문서를 읽는 것 자체가 막히는 경우가 많기 때문입니다. 또 업무의 대부분이 전화, 대면, 현장 대응처럼 비정형 커뮤니케이션에 치우친 직무에게는 이 구조가 큰 의미를 주기 어렵습니다. 저라면 이런 팀에는 SEO 콘텐츠나 이메일 캠페인처럼 문서 기반 부문부터 별도 워크스페이스로 분리해 시범 적용하겠습니다.

자동화의 달콤함 뒤에 숨은 현실적인 함정들

여기서 많이들 놓치는 부분은 "AI 직원"이라는 표현이 주는 과도한 기대입니다. README와 예시를 잘 쌓아 두면 분명히 산출물 품질과 일관성이 올라갑니다. 하지만 에이전트는 여전히 지시를 잘 받은 만큼만 움직입니다. 폴더를 잘못 나누거나, 규칙을 모호하게 쓰거나, 참고 예시의 수준이 낮으면, 그 오류와 저품질이 워크스페이스 전체에 증폭되어 쌓입니다.

또 한 가지 함정은 컨텍스트 관리 비용입니다. 워크스페이스가 커질수록 README가 길어지고, 예시 문서와 리서치 리포트가 수십, 수백 개로 늘어납니다. 이때 "무엇을 참고하고, 무엇을 무시해야 하는지"를 명시하지 않으면 모델이 과거 문서에 과도하게 끌려가서 새로운 실험을 방해하는 경우도 생깁니다. 제 기준에서는 분기마다 한 번씩 README와 폴더 구조를 리팩터링하는 의식 같은 것을 운영 프로세스에 집어넣는 편이 더 현실적입니다.

누구에게 중요한 전략인가

국내 팀 기준으로 이 전략이 특히 의미 있는 사람은, 적어도 하나의 제품이나 채널을 장기적으로 운영 중인 경우입니다. SaaS 서비스든, 교육 플랫폼이든, 유튜브 채널이든, "브랜드 세계관과 톤을 꾸준히 이어가야 할 대상"이 있을 때 에이전트 워크스페이스가 진가를 발휘합니다. 반대로 단기 캠페인 위주로 프로젝트가 자주 갈리는 프리랜서나 에이전시는 프로젝트마다 새로 세팅하는 오버헤드가 더 크게 느껴질 수도 있습니다. 이럴 때는 공통 예시와 템플릿만 묶어 둔 "마스터 워크스페이스"를 하나 만들고, 개별 프로젝트는 여기에 얹는 방식이 현실적입니다.

저라면 처음부터 회사 전체를 덮는 거대한 에이전트를 꿈꾸기보다, 한 명의 CMO, 한 명의 콘텐츠 리드가 자신의 작업을 자동화하는 개인 워크스페이스로 시작하겠습니다. 작게 시작해도 README와 예시 문서가 쌓이면, 나중에 팀 단위로 확장할 때 훨씬 덜 고통스럽기 때문입니다.

현실적 제약과 첫 번째 행동

이 구조를 도입할 때 가장 현실적인 제약은 세 가지 정도로 정리됩니다. 첫째, Obsidian과 코드 에디터, Claude Code 확장을 같이 돌릴 정도의 기본적인 도구 친화력이 필요합니다. 둘째, 모델 비용입니다. Opus 4.5급 모델을 메인 에이전트로 쓰면 리서치와 장문 생성에서 확실히 차이가 나지만, 사용량이 늘면 비용도 빠르게 쌓입니다. 셋째, 조직 내 합의입니다. 어느 폴더에 무엇을 두고, 어떤 톤을 표준으로 삼을지 합의되지 않은 상태에서 에이전트를 돌리면, 사람 사이의 불일치를 AI가 더 증폭할 가능성이 큽니다.

그래서 첫 행동은 거창한 자동화가 아닙니다. 지금 쓰고 있는 업무 문서 가운데 한 영역만 고르는 것이 좋습니다. 예를 들어 "영상 광고 스크립트" 혹은 "제품 기능 소개 블로그 글"처럼 하나를 고르고, Obsidian 볼트를 새로 만든 뒤, README에 역할과 규칙을 한 페이지로 적습니다. 이어서 이미 잘 나왔던 과거 결과물 10개 정도를 예시로 모아서 Examples 폴더에 넣고, Claude Code에게 이 구조를 설명한 뒤, "같은 톤으로 새로운 아이디어 5개를 써 달라"고 지시해 보는 것입니다. 그 결과물을 검토하면서 README와 폴더 구조, 예시 구성을 다듬다 보면, 어느 순간 "AI 직원"이라는 말이 과장이 아니라, 꽤 현실적인 표현으로 느껴질 가능성이 높습니다.

출처 및 참고 :