개발 블로그를 좀 더 쉽게 써보자 - Cowork로 흩어진 개발 맥락 모으기

Cowork로 Cursor 대화 기록 3,074개와 흩어진 소스를 모아 초안을 만들었다.
하지만, 최종본은 결국 내 손으로 썼다!
AI 시대, 자동 생성된 글과 직접 쓴 글, 그 사이 균형점은 무엇일까?

Claude - Cowork

왜 개발 블로그를 쓰기 어려운가

사이드 프로젝트를 하면서, 항상 마음 한 켠에는 이런 생각을 한다.

'아 여기까지만 개발하고, 한 턴 끊은 다음에 개발블로그 써야지'

 

하지만... 개발을 멈추기도 싫고 (개발은 관성이잖아!)

그렇다고 여기서 더 나아가면 개발 블로그 정리할 거리는 j curve로 늘어난다.

 

겨우 마음을 먹고 자리에 앉아도,

맥락을 정리하는 게 정말 어렵다!!

아 내가 이 버그는 cursor한테 물어봤었지
근데, 해결은 claude가 준 아이디어로 했어
이거 에셋 생성은 gpt로 했지...
근데 그 에셋 아이디어는 claude가 줬어...

 

개발할 때는 여러 AI model을 넘나들며 몰입하지만,

돌아서서 흐름을 정리하려고 하면, 맥락이 너무 방대해져 있다.

 

그렇다고, 정리를 하지 않으면,

내가 얻은 인사이트들이 내 기억 저장소 어딘가로 흩어져버린다.

 

Lesson&Learn을 해야하는데 Lesson만 기억 파편에 가득하면 성장하기 어렵다.

그래서 휘발되지 않는 문자로 그 Learn들을 정리해서 다시 읽어봐야 한다.

---

Cowork를 써볼까?

26년 2월 2일, 사내 데브 세션에서 ai rule 세팅을 발표했다.

AI 홍수 시대, 프론트엔드 개발자가 Rule을 설계해야 하는 이유: https://developer-dreamer.tistory.com/210

 

이 세션 다음 날, 시니어 백엔드 개발자분이 나에게 질문을 던지셨다.

 

"수연님 혹시 Claude에서 나온 Cowork도 써보셨어요?"

 

최근 Claude 데스크톱 앱에서 'Cowork' 탭을 새로 출시했다면서,

자꾸 hover로 클릭을 유도했던 게 기억났다.

 

"오, 아직이요! 써보고 인사이트 얻으면 공유드릴게요!"

---

자리에 돌아오자마자,

'그래 어디 한 번 써보자'하는 마음으로 앱을 켰다.

 

내 파일 시스템의 열람 권한을 주고, 브라우저 권한까지 줬다

 

이들이 제시한 예제는

'나의 일주일 캘린더와 스케줄을 정리하기'였다.

 

내 대부분의 맥락은 구글 캘린더나 노션보다는

슬랙에 존재했다.

 

하지만 회사 슬랙 채널 대화를 전부 뽑아내는 건 권한이 제한되어 있었고,

노션 mcp로 slack 검색을 통해 우회 접근하는 방법이 최선이었다.

 

모든 권한을 줬는데,

생각보다 드라마틱한 요약본이 나오지 않자 실망했다.

메시지 응답 속도도 일반 llm ai에 비해 느렸다.

"너, 느려"

 

솔직하게 피드백했더니, Cowork가 이런 방향을 제시했다.

제가 진짜 빛을 발하는 건 사람이 하면 귀찮고 시간 걸리는 작업을 자동으로 처리하는 거예요!

 

난 이 말을 듣자 개발 블로그가 떠올랐다.

 

개발 블로그는 이미 내 로컬 스토리지에 소재가 흩어져있다.

AI와의 대화, 내가 생성한 에셋, 깃허브 커밋 기록 등

이걸 각 부분에서 긁어모아 조립하는게 가장 시간이 많이 드는 일이었다.

 

시험삼아 matter.js를 처음 사용해보며 얻었던 인사이트를 정리한 노션 링크를 먹였다.

 

Cowork는 좋은 소재라며,

어떤 식으로 글의 흐름을 바꾸면 좋을지, 타겟 독자가 명료하면 좋겠다던지, 이런 피드백을 줬다.

 

'이야, 이거다!'

 

내가 점점 히스토리가 방대해져 엄두도 내지 못했던,

<집중요정 슬랙봇> 사이드 프로젝트 개발기를 너와 함께 작성해봐야겠다!

---

그래서, Cowork가 뭐죠?

Claude 데스크톱 앱에는 Cowork 모드라는 기능이 있다.

내 컴퓨터 파일 시스템에 직접 접근할 수 있다.

 

폴더를 선택해서 권한을 주면, 그 안의 파일을 읽고 쓸 수 있고,

터미널 명령어 실행, 브라우저 자동화, 슬랙/노션 같은 외부 도구 연동(MCP)도 가능하다.

 

이거라면, 내 Cursor IDE의 대화 기록도 읽을 수 있겠구나!

Cowork 출시 관련 공식 글: https://www.anthropic.com/news/introducing-anthropic-labs

---

실전 활용기

1. Cursor 대화 기록 추출

개발 블로그를 쓰려면, 개발 과정의 맥락이 필요하다.

나는 집중요정을 만들면서 Cursor에서 Claude(Opus 4.5)와 많은 대화를 나눴다.

 

그런데 Cursor는 대화 내보내기 기능을 공식적으로 지원하지 않는다.

 

여기서 Cowork 파일 시스템 접근이 등장한다!

 

'너 로컬 레포지토리의 Cursor 세션도 읽을 수 있냐?'

 

cursor 세션 데이터 탐색 과정

Cowork가 직접 Cursor의 데이터 디렉토리를 탐색하기 시작했다.

~/Library/Application Support/Cursor/User/workspaceStorage/{hash}/state.vscdb

 

{hash}는 프로젝트별로 다른 값이다.

state.vscdb는 SQLite DB이고, cursorDiskKV 테이블에 대화 데이터가 JSON으로 저장된다.

 

Cowork가 SQLite 쿼리를 직접 실행해서 cursorDiskKV 테이블에서 대화 데이터를 추출했다.

SELECT key FROM cursorDiskKV WHERE key LIKE 'composerData%';

 

집중요정 프로젝트의 대화 세션을 찾아냈고,

그 안에 3,074개의 대화 버블(메시지)이 들어있었다!

이제 UI로 접근할 때는 만료되어서 안나오는 대화들도 데이터로는 고스란히 남아있었던 것이다.

(단, 붙여넣은 스크린샷은 이곳에 저장되지 않음)

 

어떤 기능을 어떤 순서로 개발했는지,

어떤 버그를 만나서 어떻게 해결했는지,

AI와 어떤 대화를 나눴는지 시간 순으로 복원할 수 있었다.

---

2. 흩어진 소스 자료 종합

개발 블로그의 소재는 한 곳에 모여있지 않다.

 

Cursor 대화 기록: 코드 작성 과정, 버그 해결 과정
Claude.ai 대화 기록: 프로젝트 초기 아이디어 구상, 첫 코드 작성
chatGPT: 컨셉 이미지 생성, 도트 이모지 생성
슬랙 스레드: 프로젝트의 발단(팀원의 한 마디), 기능 제안, 버그 제보, 출시 반응
GitHub 레포: 이슈, PR, 커밋히스토리, README

 

Cowork에게 이 자료를 하나씩 전달했다.

 

슬랙 대화를 붙여넣었을 때,

'이 부분이 서론에 들어가면 좋겠다'라는 제안을 하는 등

글의 구조에 맞게 배치하는 것도 제안해줬다.

 

시간순으로 엮어서 하나의 스토리라인을 정리해줬다.

---

3. 팩트 체크

초고를 다 쓴 후, Cowork에게 전달했다.

그런데, Cowork가 GitHub 레포에 직접 접근해서 실제 데이터를 확인하기 시작했다.

초안 팩트 체크

이슈 개수나, PR 개수, 구현한 커맨드 개수 등을 바로잡았다.

 

글의 신뢰도는 사소한 숫자 오류에서도 쉽게 잃을 수 있는데,

먼저 내가 제안하지 않았는데도 이런 점을 미리 캐치한다는 점이 놀라웠다.

 

---

4. 글의 주축은 항상 '사람'이, 'AI'는 보조도구로

Cowork는 수집한 데이터를 바탕으로 집중요정 개발기 초안을 써줬다.

하지만, 내 글처럼 느껴지지 않았다.

 

나는 여러 개발 블로그를 읽을 때

'어 이거 AI로 자동 생성했나?'라고 느껴지는 지점에서 이질감을 느낀다.

 

AI는 방대한 지식과 데이터를 가지고 있어서,

유려하고 화려한 글을 얼마든 빠르게 잘 뽑아낼 수 있다.

하지만, 그게 나의 지식은 아니다.

 

적어도 내 블로그에는 내가 아는 범위 내에서 나의 언어로 글을 쓰고 싶다.

내가 이해하지 못한 상태에서 쓴 글은, 상대방도 이해하지 못할 것이다.

독자로부터 내가 작성한 글에 대한 신뢰를 얻는 것 역시 중요하다.

 

그래서, Cowork가 준 글을 복사 붙여넣기 하지 않고,

그 흐름만 참고하여 내가 다시 하나씩 재구성해서 타이핑했다.

자연스럽게 나의 말투도 묻어나오고, 나의 유머(...ㅎㅎ)도 적재적소에 껴넣을 수 있었다.

 

난 개발 블로그를 쓴 후에 몇 번이고 다시 내 글을 읽어본다.

나의 언어로 정리된 지식을 반복해서 읽으며 체득하는 것을 좋아하기 때문이다.

그래서 더더욱 AI가 쓴 초안을 그대로 블로그에 낼 수 없다.

 

결국 블로그의 생명은 '나의 목소리'이다.

뼈대는 내가 세우고, AI는 보조도구로 쓰자.

---

결론

개발할 때 나는 '무엇을 성공적으로 만들어내는 것'에 몰입해 있다.

'왜 이런 결정을 했는지'는 매 순간 생각하지만, 의식적으로 별도 문서에 기록하진 않았다.

 

하지만, 그 고민의 흔적은 AI 대화 기록, 슬랙 스레드, GitHub 커밋 히스토리에 고스란히 남아있었다.

Cowork로 이 흔적을 모으면서, 흐름을 복원할 수 있었다.

 

'AI로 시간을 단축해놓고, 최종본은 직접 쓰라는 게 무슨 의미인가!'

이렇게 생각할 수 있다.

 

하지만 이 방법으로 글을 작성함으로써, 이미 시간이 1/3 이상 단축됐다.

머릿속에 흩어져 있던 글 조각이 한 데 모여서, 해상도가 높은 완성본으로 출력된다.

거기서부터 내 손으로 다시 쓰면 된다.

 

최종 결정과 판단은 인간의 손에 있고, 그것이 인간의 힘이다.

---

이 글에서 다룬 집중요정 개발기 >
쓰던 봇이 유료 전환? 그럼 직접 만들지 - 집중요정 슬랙봇 개발기: https://developer-dreamer.tistory.com/217

---

사실, 이번에 쓴 건 Cowork가 할 수 있는 일의 일부에 불과하다.

다음에는 좀 더 능동적으로 써본 후, 후속글로 돌아오겠다.

 

작성: 2026.02.18. 15:22